`
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
` ____________
`
`SONY COMPUTER ENTERTAINMENT AMERICA LLC
`Petitioner
`
`v.
`
`APLIX IP HOLDINGS CORPORATION
`Patent Owner
`
`____________
`
`Case No. IPR2015-00729
`Patent 7,280,097
` ____________
`
`
`
`SUPPLEMENTAL DECLARATION OF DR. GREGORY F. WELCH
`
`
`
`
`
`SCEA Ex. 1039 Page 1
`
`
`
`
`
`I, Gregory F. Welch, hereby declare the following:
`1.
`I have been asked to respond to certain issues raised by Patent Owner
`
`(“PO”) and their expert, Mr. Peng Lim, in Patent Owner Aplix IP Holdings
`
`Corporation’s Response to the Petition dated November 2, 2015 (“Paper No. 21”).
`
`All of my opinions expressed in my original declaration dated February 17, 2015
`
`(Ex. 1009) remain the same. I have reviewed the following additional materials in
`
`connection with preparing this supplemental declaration:
`
`•
`
`•
`
`•
`•
`•
`•
`
`•
`
`•
`
`•
`
`•
`
`•
`
`Paper No. 13, Decision Institution of Inter Partes Review dated July
`22, 2015;
`Paper No. 21, Patent Owner Aplix IP Holdings Corporation’s
`Response to the Petition dated November 2, 2015;
`Ex. 2009, Declaration of Peng Lim dated October 31, 2015;
`Ex. 2031, Welch Deposition Transcript dated October 21, 2015;
`Ex. 1041, Lim Deposition Transcript dated January 26-27, 2016;
`Ex. 1032, Mark R. Mine. Exploiting proprioception in virtual-
`environment interaction. PhD thesis, Chapel Hill, NC, USA, 1998.
`UMI Order No. GAX98-03637;
`Ex. 1033, Greg Welch and James P. Williams. The easy chair: A
`microprocessor-controlled wheelchair for children with muscular
`disorders. Purdue University, E.E.T. 490/491 Senior Design Project,
`Final Report, May 1986;
`Ex. 1034, Greg Welch. The infrared touch-pad. Purdue University,
`E.E.T. 421 Report, February 26, 1986;
`Ex. 1035, Greg Welch and James P. Williams. The easy chair: A
`microprocessor-controlled wheelchair for children with muscular
`disorders. Purdue University, E.E.T. 490/491 Senior Design Project,
`Preliminary Report, December 1985;
`Ex. 1036, James Williams and Greg Welch. The pressure sensitive
`touch-pad. Purdue University, E.E.T. 454 Project Report, April 30,
`1985;
`Ex. 1037, Greg Welch. A survey of power management techniques in
`mobile computing operating systems. ACM Operating Systems
`Review (SIGOPS-OSR), 29(4): 47–56, 1995; and
`
`
`
`1
`
`SCEA Ex. 1039 Page 2
`
`
`
`
`
`
`I.
`
`•
`
`Ex. 1038, Buxton, B., “A Directory of Sources for Input
`Technologies,” Input Devices Sources & Resources, Oct. 1, 2003,
`retrieved
`from
`the
`internet
`at
`http://www.billbuxton.com/InputSources.html, on February 15, 2016,
`pp. 1-48.
`
`OPINION
`A. My Working Knowledge of Hand-Held User Input Devices
`2.
`
`In my original declaration, I proposed definition for a person having
`
`ordinary skill in the art, including (among other things), “a working knowledge of
`
`computers - including handheld computing devices, and their processing, storage,
`
`hardware—including input devices, and software.” Ex. 1009 at ¶ 38. It is my
`
`understanding that Patent Owner (PO) has questioned my “working knowledge” of
`
`hand-held user input devices. Paper No. 21 at pp. 7-8. With respect to my
`
`originally proposed characteristics of a person of ordinary skill in the art of the
`
`’097 patent, the PO states that “Aplix generally agrees with this standard provided
`
`that ‘working knowledge’
`
`is construed
`
`in the manner consistent with
`
`Petitioner’s own expert’s testimony.” Id. at p. 8 (emphasis added). The PO then
`
`narrowly mischaracterizes my testimony, saying that “Despite Petitioner’s expert’s
`
`testimony on this point, his CV reflects no such hands-on experience with hand-
`
`held user input device hardware in his long career in virtual reality systems,
`
`apart from two projects that employed off-the-shelf smartphones. . . . It contains no
`
`
`
`2
`
`SCEA Ex. 1039 Page 3
`
`
`
`
`
`evidence that Petitioner’s expert ever designed user interface hardware as did the
`
`‘097 inventors and Aplix’s expert Peng Lim.” Id. (emphasis added).
`
`3.
`
`The PO is referring to my deposition testimony of October 21, 2015
`
`(Ex. 2031) where I discussed “hands-on experience” as it relates to the level of a
`
`person of ordinary skill in the art for the ‘097 Patent. However, the PO is not
`
`considering my entire testimony on the subject. For example, during my
`
`deposition I indicated that “hands-on” does not necessarily mean “physically
`
`manipulating or doing something with hands,” but also “could have involved
`
`working on, say, a project where a student or somebody was involved in
`
`discussions and decisions made about those sorts of devices or needed some
`
`knowledge,” and “it could have involved hardware, software, could have
`
`involved just intellectually being on a team, but --- it's a little hard to describe,
`
`but more than book knowledge, so maybe specific to a real working product or
`
`some real working examples of projects or products.” Ex. 2031 at 29:19-30:12
`
`(emphasis added). The PO’s characterization of my testimony related to hands-on
`
`experience is incomplete and mischaracterizes that testimony. In fact, per my
`
`complete
`
`testimony
`
`I have extensive
`
`relevant hands-on experience, as
`
`characterized in my deposition, including the design of “user interface hardware,”
`
`and much more.
`
`
`
`3
`
`SCEA Ex. 1039 Page 4
`
`
`
`
`
`4.
`
`The Patent Owner seems to focus on a couple of specific experiences
`
`in my Curriculum Vitae (CV) related to their narrow criteria for “working
`
`knowledge.” In light of my complete testimony regarding “working knowledge,”
`
`my relevant experience is much more extensive as I outlined in my initial
`
`declaration and as I testified during my deposition. Ex. 1009; Ex. 2031 at 23:5-12.
`
`Had Patent Owner’s counsel asked me about all of my experiences qualifying
`
`under my complete definition of “working knowledge,” I would have been happy
`
`to explain in detail the experiences listed in my declaration, listed in my CV, and
`
`the many other experiences that are not listed in my CV that also demonstrate my
`
`“working knowledge.”
`
`5. Beyond my undergraduate and graduate education (which included
`
`many aspects of human-computer interaction), I have been involved with the
`
`hands-on development of many real working prototypes of handheld devices and
`
`other input technologies over the years. Each of those devices is either explicitly
`
`listed on or could be classified per Bill Buxton’s “A Directory of Sources for Input
`
`Technologies,” which is cited on the face of the ‘097 Patent. Ex. 1039, Buxton.
`
`This includes at least assistive technologies, touch tablets, digitizing devices, head
`
`and handheld device tracking, and motion capture.
`
`6.
`
`For example, during my senior year of undergraduate studies at Purdue
`
`University in the mid 1980s, I co-developed both resistive and optical touch pads
`
`
`
`4
`
`SCEA Ex. 1039 Page 5
`
`
`
`
`
`as part of a senior project to develop a computer-controlled wheelchair for children
`
`with muscular disorders such as Cerebral Palsy. See, Exs. 1033, 1034, 1035, 1036.
`
`While not intended to be held in the hand (the children in question were unable to
`
`hold anything), the hardware and software design aspects of the touch pad involved
`
`many of the same core design considerations that would be faced in a hand-held
`
`device, including how large to make the input area, what size and how many (soft)
`
`buttons to include, where the buttons should be located (considering the
`
`biomechanics of the users), and how to manage button action priorities. We made
`
`the overall enclosure big enough to mount across arms of wheelchair, and the input
`
`area large enough to accommodate virtual/soft buttons that could be reliably
`
`selected by the children, given their very limited motor skills. Our resistive touch
`
`pad used a two-dimensional array of conductive foam squares that behaved as
`
`variable resistors, and multiplexing circuitry to repeatedly scan the rows and
`
`columns, looking for decreased resistance (an indication of pressure on a square).
`
`For the final prototype we used a two-dimensional optical approach to avoid issues
`
`with the presence of saliva common to some of the children. See for example the
`
`figures below:
`
`
`
`5
`
`SCEA Ex. 1039 Page 6
`
`
`
`
`
`Ex. 1036 at p. 12.
`
`
`
`1
`I
`
`I 1 " " " " " " " "
`
`, ,
`
`t:...l
`
`ME!v
`
`SELECT
`DECODE
`
`I
`
`sees-ss
`MICROCOMPUTER
`
`ROW /CO L
`TOUCH 'Df.TEC.T
`
`I
`
`ME. NV SE.LE C.T
`TOUCH DETECT
`
`TOUCH-PAD
`
`COLUMN
`DECODE.
`
`Ex. 1035 at p. 7.
`
`DUifoN0'LIJ
`FIG:
`DATE: '' /1•/t. I>AA""t;Ew
`
`TITLE:
`
`TOUCH- PAD
`BLOCK DIAGRAM
`
`
`
`
`
`6
`
`SCEA Ex. 1039 Page 7
`
`
`
`
`
`\liE NV
`S£.L£CT
`SXDE
`CUT-AWAY
`
`1 t •ll
`cr
`o
`o o o o o ogogo;;o;:ojjo o o o o o
`\. l _l
`
`MEN \.I
`SELE.C. T
`-...... PA'IRS
`o-lf
`},..
`IT"
`
`COLUMN
`SE.LE.tT
`
`O-F
`
`RCIW
`PAIRS
`
`FIG:
`'I
`DATE:'''''"' OV.>J{,Of/U
`
`TITLE:
`THE TOUI!H PAJ>
`
`
`
`Ex. 1035 at p. 27.
`
`7. We designed the touch pad to allow per-child customization of the
`
`number, sizes and locations of the input regions, based on their individual
`
`biomechanical abilities. For example, for some children we configured the system
`
`such that all of the “go” buttons (slow, medium, fast) were situated at the farthest
`
`side (away from them), and such that release of a button would stop the chair from
`
`moving. For other children, with more limited reach, we placed the “buttons” near
`
`the closer side, sometimes clustered near the left or right, depending on their
`
`handedness. To support per-child customization, we incorporated the ability to
`
`insert paper “menus” into the housing such that the paper laid flat over the surface,
`
`
`
`7
`
`SCEA Ex. 1039 Page 8
`
`
`
`
`
`and drawings on the paper could indicate the locations and types of regions
`
`(“buttons”) for that child. For some children we drew/defined arrows and other
`
`geometric objects, for some children we used animals (e.g., a rabbit for fast, and a
`
`turtle for slow). The template for the overlays incorporated a series of small “menu
`
`select” identifier circles along the top edge (see for example the figures above) that
`
`could be selectively colored in with a pencil or black ink to create a distinct binary
`
`code to identify each distinct menu. The per-child settings matching the specific
`
`paper menu were immediately loaded by the computer when the menu was inserted
`
`into the housing.
`
`8. We developed the wheelchair in collaboration with Prof. George
`
`Karlin (a Special Education Project Coordinator at Purdue University), and
`
`therapists at The Wabash Center in Lafayette, Indiana. (The Wabash Center
`
`opened in 1953, and remains open today: http://www.wabashcenter.com) The
`
`wheelchair apparently remained in use at the Wabash Center for many years, with
`
`support from Prof. Karlin and my project partner James Williams (who both lived
`
`nearby), until some critical components failed and replacement parts were no
`
`longer available.
`
`9. While a graduate student at the University of North Carolina at Chapel
`
`Hill (UNC), I was a member of a project team that developed and then used
`
`various handheld input devices with 6D magnetic tracking (3D position and 3D
`
`
`
`8
`
`SCEA Ex. 1039 Page 9
`
`
`
`
`
`orientation) and buttons to be actuated by the user’s fingers. For example, as
`
`described in the Ph.D. dissertation of fellow UNC graduate student Mark Mine
`
`(now working on 3D user interfaces at Walt Disney Imagineering), “The primary
`
`input device is a modified handle of a commercial joystick with five buttons (only
`
`three are used in the CHIMP system). The secondary input device is a custom built
`
`device with two buttons.” Ex. 1032, Mine at pp. 68-69; see also id. Figure 6.1 and
`
`Figure 6.2 reproduced below:
`
`
`
`
`
`9
`
`SCEA Ex. 1039 Page 10
`
`
`
`
`
`10. Also while a graduate student at UNC, I carried out an independent
`
`study of power management techniques used in mobile computing devices,
`
`including cellular devices. See, Ex. 1037, Welch. Efficient power usage remains
`
`an important factor in mobile devices today, including handheld devices. For
`
`example, it can directly impact the size and weight of the device via battery
`
`requirements.
`
`11. As I mentioned during my deposition, I supervised the development of
`
`a prototype handheld computing device for a project we called 3D Medical
`
`Consultation, which began in October 2003. The development involved careful
`
`consideration of alternative input mechanisms, repeated consultation with a
`
`surgeon, and several prototype iterations to arrive at the final interface. For
`
`example, with respect to biomechanical considerations we considered using
`
`buttons (hard or soft) to control the viewpoint of the remote patient (e.g., pan and
`
`zoom) but decided that a device with a separable device handheld cover that was
`
`tracked by/with respect to the handheld device would offer better alternative. The
`
`two-handed interface was the preferred by our surgeon collaborators.
`
`12. At various times over the years we developed handheld input devices
`
`for various purposes. For example, I worked with students on some experiments
`
`using the (handheld) Nintendo Wii Remote (Ex. 2031 at 105:13-108:24), on
`
`handheld 3D input devices incorporating our HiBall tracking system sensor (which
`
`
`
`10
`
`SCEA Ex. 1039 Page 11
`
`
`
`
`
`we designed for use in tracking heads, hands), and various handheld input devices
`
`for games (e.g., virtual skeet shooting and golf), pointing, selecting, and drawing in
`
`3D. See below for some examples:
`
`
`
`
`
`13. Finally, over the years I have on various occasions been asked to
`
`review submitted manuscripts related to handheld input devices, for venues such as
`
`the Symposium on Virtual Reality Software and Technology (VRST), the
`
`Symposium on Interactive 3D Graphics, and User Interface Software and
`
`Technology (UIST).
`
`
`
`11
`
`SCEA Ex. 1039 Page 12
`
`
`
`
`
`B. Claim Construction
`14.
`
`It is my understanding that PO has offered several proposed claim
`
`constructions for various claims of the ‘097 Patent. I have been asked to evaluate
`
`PO’s constructions. I have been informed that in proceedings before the USPTO
`
`the claims of an unexpired patent are to be given their broadest reasonable
`
`interpretation in view of the specification from the perspective of one skilled in the
`
`art. The broadest reasonable interpretation does not mean the broadest possible
`
`interpretation. Rather, the meaning given to a claim term must be consistent with
`
`the ordinary and customary meaning of the term (unless the term has been given a
`
`special definition in the specification), and must be consistent with the use of the
`
`claim term in the specification and drawings. Further, the broadest reasonable
`
`interpretation of the claims must be consistent with the interpretation that those
`
`skilled in the art would reach. I have been informed that the ‘097 Patent has not
`
`expired. It is also my understanding that no claim terms have been expressly
`
`construed by the Board to date.
`
`“Hand-held host device”
`
`15.
`
`Independent claims 1, 16, and 27 recite the claim term “hand-held host
`
`device.” PO has contended “[t]he broadest reasonable construction of the phrase
`
`‘hand-held host device’ – in the context of the ‘097 patent – includes at least that
`
`the host device must be designed to be used while held in the user’s hand. In other
`
`
`
`12
`
`SCEA Ex. 1039 Page 13
`
`
`
`
`
`words, the phrase includes cell phones, PDAs, and tablets, but excludes laptop
`
`computers and other devices having a keyboard designed to be used with two-
`
`handed typing while the device is resting on a table or lap.” Paper No. 21 at p. 26
`
`(emphasis in original).
`
`16. As support for their construction, PO relies on the opinion of Mr. Lim,
`
`who opines “[t]he background section of the patent says that the input accelerator
`
`device is to be used with ‘cellular phones, personal digital assistants (‘PDAs’),
`
`pocket personal computers, smart phones, handheld game devices, bar code
`
`readers, MP3 players and other similar input devices having a keypad or one or
`
`more input elements . . . . These are all devices used while held in the hand.” Ex.
`
`2009 at ¶ 65 (quoting Ex. 1001 at 1:11-18).
`
`17. However, the ‘097 Patent also explicitly discloses using the input
`
`accelerator device “with a variety of hand-held devices such as a cellular phone,
`
`PDA, pocket PC, smart phone, laptop, or other similar devices through a wired or
`
`wireless communications protocol, such as the Bluetooth wireless protocol.” Ex.
`
`1001 at 14:36-42 (emphasis added). Given this explicit disclosure of a laptop as a
`
`“handheld device” used with the input accelerator device, I see no reason why a
`
`person of ordinary skill would conclude that the claim term “hand-held host
`
`device” must exclude laptops.
`
`
`
`13
`
`SCEA Ex. 1039 Page 14
`
`
`
`
`
`18. Mr. Lim also cites the ‘097 Patent’s identified problem and then opines
`
`that a laptop or “two-handed keyboard touch type” device does not have the same
`
`“cumbersome and inefficient input problem” of handheld devices such as cellular
`
`phones and PDAs. Ex. 2009 at ¶ 67. However, Mr. Lim’s analysis omits part of
`
`the ‘097 Patent’s identified problem. The full citation of the ‘097 Patent’s
`
`identified problem is as follows:
`
`“The present inventors recognized that conventional human interface
`and input systems for hand-held electronic devices tended to be
`relatively inflexible, cumbersome, and inefficient to use, among other
`reasons, because they were not designed to take advantage of the
`biomechanics of the human hand, particularly the advantages
`associated with the opposition of the thumb to the fingers and the
`beneficial attributes of the thumb, e.g., its large range of motion and
`ability to impart large sustained forces, and the beneficial attributes of
`the fingers, e.g., their fine motor control, spatial memory and rapidity
`of motion.
`
`Ex. 1001 at 4:27-37 (emphasis added).
`
`19. A person having ordinary skill in the art at the time of the ‘097 Patent
`
`would appreciate that a laptop computer would have all or most of its input
`
`elements on one surface (i.e., the keyboard and cursor control) and would therefore
`
`not “take advantage of the biomechanics of the human hand, particularly the
`
`advantages associated with the opposition of the thumb to the fingers” as taught by
`
`the ‘097 Patent. As such, a skilled artisan would have appreciated that the input
`
`accelerator device described by the ‘097 Patent could be used to control a laptop
`
`computer in order to better “take advantage of the biomechanics of the human
`
`
`
`14
`
`SCEA Ex. 1039 Page 15
`
`
`
`
`
`hand.” Therefore, I do not agree with Mr. Lim’s conclusion that “[t]he ’097 Patent
`
`problem and solution also show that it was aimed at devices used in the hand.” Ex.
`
`2009 at ¶ 67.
`
`20. Additionally, independent Claim 27 recites “a plurality of hand-held
`
`host devices.” Ex. 1001 at Claim 27. Claim 38, which depends from Claim 27,
`
`recites the limitation “wherein the plurality of host devices comprises at least
`
`one of a cellular phone, a personal digital assistant, a smart phone, a laptop, a
`
`garage door opener, an automobile keyless entry unit, a smartcard, a programmable
`
`RFID keyfob, a universal remote control unit, a digital wristwatch, a compact disc
`
`player or a MP3 player.” Ex. 1001 at Claim 38 (emphasis added). Thus, the
`
`“plurality of hand-held host devices” of Claim 27 must at least include a laptop as
`
`required by Claim 38.
`
`21. Therefore, I agree that the broadest reasonable interpretation of “hand-
`
`held host device” at least includes host devices designed to be used while held in
`
`the user’s hand. However, I do not agree that a person having ordinary skill in the
`
`art would conclude that it excludes laptop computers because of explicit
`
`disclosures to the contrary in the ‘097 Patent claims and specification.
`
`15
`
`
`
`
`
`SCEA Ex. 1039 Page 16
`
`
`
`
`
`“Input controller [being] configured to generate an input signal upon actuation of
`
`at least one of the plurality of input elements”
`
`22.
`
`Independent claims 1, 16, and 27 recite an “input controller [being]
`
`configured to generate an input signal upon actuation of at least one of the plurality
`
`of input elements.” With regard to this limitation, PO contends “[t]he broadest
`
`reasonable interpretation of this phrase requires at least an ‘input controller’ that
`
`can interpret input data and convert it into an input signal ready to be mapped to
`
`control functions of a software application. In other words, it must do more than
`
`merely transmit raw, unstructured input data to the host device.” Paper No. 21 at
`
`p. 27 (emphasis in original). PO also argues, “the input controller must process the
`
`input data into a form (here called an ‘input signal’) that is more than just raw,
`
`unstructured input data. Raw, unstructured input data must undergo at least some
`
`additional ‘interpret[ation]’ before it can be mapped to an application function and
`
`‘used to control execution of it.” Id. at p. 28 (citing Ex. 2009 at ¶¶ 68-70).
`
`23. First, I would note that the phrase “raw, unstructured input data” is
`
`rather ambiguous as that concept is not present in the ‘097 Patent. During his
`
`deposition, PO’s expert, Mr. Lim, opined that “raw, unstructured input data,” is
`
`“Input data that’s generated is not interpreted or reconfigured somehow.” Ex.
`
`1041, Lim Tr. at 137:23-24. Citing to an example from Mollinari, Mr. Lim further
`
`opined that data indicative of the current state of the input elements is “raw” input
`
`
`
`16
`
`SCEA Ex. 1039 Page 17
`
`
`
`
`
`data. Ex. 1041, Lim Tr. at 141:2-142:5 (“Q. . . . How would a person of ordinary
`
`skill in the art objectively determine whether or not input data is raw? A. If the data
`
`is not specifically reassigned or reinterpreted. So I think it was viewed by one of
`
`the references, the word that the reference was viewed, I believe I can read that, is -
`
`- okay, this particular reference is Mollinari. And I cite it in paragraph 92 of my
`
`declaration. And on the second paragraph it starts with: ‘A microcontroller 42
`
`monitors the state of the controlled element, 11, 12, and 13, on the game controller
`
`2C, and sends a command statement representing the current state of the controlled
`
`element and/or the current modification in the state of the controlled element,’ the
`
`‘state’ means 0 or 1, ‘Over a data transmission’ means --and so on. In that
`
`paragraph written by Mollinari? It sounds -- they make it fairly clear that the data
`
`that was available there, just representing the state, which I told you is the switch,
`
`is that on or is that off. Of course it's got to be represented in some kind of a binary
`
`for the computer to understand that. But it represents just the state of the switch. So
`
`that's no value added except representing the state.”).
`
`24. Mr. Lim also suggested that the input signal must be interpreted “based
`
`on the thing that needs by the host system or by the application of the host system”
`
`and essentially pre-mapped to an application function. Ex. 1041, Lim Tr. 146:23-
`
`147:1; 147:9-17 (“Q. Can you give me an example of an input signal that would be
`
`application-dependent? A. I think it says multiple places that the input signal --
`
`
`
`17
`
`SCEA Ex. 1039 Page 18
`
`
`
`
`
`there's one that I provided in Claim 69 says that "input signal can be mapped or
`
`remapped to an application function," and that's what I told you earlier, that
`
`depends on the application. And an application could be an application function. I
`
`mean it depends on the application.”).
`
`25.
`
`I would also note that it appears as though the phrase “raw,
`
`unstructured input data” was derived by PO from testimony I gave during my
`
`deposition with regard to the AT-command interface standard discussed by the
`
`Mollinari reference. With regard to the AT -command interface standard, in
`
`general, I opined “as I recall, it would be things like a character code -- or a code,
`
`an AT command that signals the start of some data, and then as I recall the data
`
`could be unstructured after that, and there might be another command that would
`
`signify the end of the data, so you have both a beginning and an end which allows
`
`you to vary the amount of data in the middle.” Ex. 2031 at 58:7-22 (emphasis
`
`added). I further clarified that by “unstructured” I meant that the amount of data
`
`between the starting character code and the end character code could vary, i.e., the
`
`AT-command interface standard does not place any requirements on the amount or
`
`format of the data being transmitted in between the starting character code and the
`
`end character code. Id. at 58:23-59:18 (“Q. When you said just now that the data
`
`in the middle could be unstructured, what does that mean? A. It means -- and again
`
`I'm going from memory so I could be wrong here, but my memory of this is that it
`
`
`
`18
`
`SCEA Ex. 1039 Page 19
`
`
`
`
`
`could be three characters in the middle, it could be 20 characters in the middle, it
`
`could be 50, it could be different quantities, certainly, of characters that --Because
`
`those chunks of data can come in different sizes and come asynchronously, there
`
`have to be certain commands which signal either the end of the UART system
`
`about a change, like in the -- either the data or the -- now I'm remembering. There
`
`may be --there may be AT commands that signal like – things like I'm ready to
`
`receive, so there might be an AT command that's sent that says I'm ready to receive
`
`data, there might be another command that says -- acknowledges that, there might
`
`be another command that says this is your start of the data, another one that says
`
`here's the end of the data.”). This testimony had nothing to do with the claims of
`
`the ‘097 Patent or the disclosure in the ‘097 Patent. And, I completely disagree
`
`with the way in which PO appears to be incorporating my unrelated testimony into
`
`its interpretation of the claims.
`
`26. With regard to the concept of “raw” data, it appears as though PO has
`
`again taken this language from my deposition testimony regarding Mollinari. In
`
`particular, I opined that the AT interpreter 52 shown in Fig. 9 of Mollinari receives
`
`“raw encoded data in the form of AT commands” from the UART driver 51. Ex.
`
`2031 at 44:13-45:2. Again, this testimony had nothing to do with the ‘097 Patent.
`
`Indeed, a person of ordinary skill would appreciate that a term like “raw” is
`
`completely subjective—it could be applied to almost any data received by almost
`
`
`
`19
`
`SCEA Ex. 1039 Page 20
`
`
`
`
`
`any process or structure, before that process or structure operates on it. The
`
`information/data produced by that process or structure might be considered
`
`“cooked” (the opposite of “raw”) when considered from the perspective of that
`
`process or structure, but that same “cooked” information/data could simultaneously
`
`be considered “raw” from the perspective of the next process or structure to operate
`
`on it. In any case, my testimony had nothing to do with the claims of the ‘097
`
`Patent or any disclosure in the ‘097 Patent.
`
`27. Regarding Mollinari, Mr. Lim opines that the “[t]he microcontroller
`
`sends raw, unstructured command data to the host mobile phone” and that this is
`
`different than what is described in the ‘097 Patent. Ex. 2009 at ¶76; ¶94. I
`
`completely disagree. For one, the concept of “raw, unstructured data” is subjective
`
`and meaningless to a skilled artisan, as I have described. But even further, I note
`
`that the disclosure of Mollinari describes the microcontroller receiving electrical
`
`signals upon actuation of a control element, and transforming it into a
`
`corresponding command statement. Ex. 1003, Mollinari at 7:12-15. These
`
`command statements would not be considered “raw, unstructured data” by a person
`
`of ordinary skill. In fact, this disclosure in Mollinari is the same functionality that
`
`is described in the ‘097 Patent. Ex. 1001 at 11:27-47. Therefore, I disagree with
`
`Mr. Lim’s conclusion that the disclosure in Mollinari is different from disclosed
`
`embodiments in the ‘097 Patent.
`
`
`
`20
`
`SCEA Ex. 1039 Page 21
`
`
`
`
`
`28. PO’s proposed construction is inconsistent with the ordinary and
`
`customary meaning of the claim term “input controller [being] configured to
`
`generate an input signal upon actuation of at least one of the plurality of input
`
`elements.” The plain language of the claim only requires the input controller “to
`
`generate an input signal upon actuation of at least one of the plurality of input
`
`elements.” I see nothing in the claim that would lead a skilled artisan to conclude
`
`that the generated “input signal” must include data that is “reassigned or
`
`reinterpreted” or that it must be interpreted specifically for the application running
`
`on the host device. Also, the plain language of the claim comports with a skilled
`
`artisan’s understanding of the most basic function of an input controller.
`
`29. Claims 1, 16, and 27 each require the input controller to “relay the
`
`input signal to the communication channel for transmission to the hand-held host
`
`device to control execution of the one or more functions of the software application
`
`mapped to the actuated element.” Thus, the claims only require the input signal to
`
`be used “to control execution of the one or more functions of the software
`
`application” on the hand-held host device. A skilled artisan would understand that
`
`an input signal need not include an application-specific interpretation in order for it
`
`to be used “to control execution of the one or more functions of the software
`
`application.” As described by the ‘097 Patent referenced below, the interpretation
`
`of the input signal could be performed by the hand held host device and still
`
`
`
`21
`
`SCEA Ex. 1039 Page 22
`
`
`
`
`
`“control execution of the one or more functions of the software application.” Ex.
`
`1001 at 11:29-46, 11:54-60. Indeed, a person of ordinary skill would understand
`
`that the most common and arguably important task of an input controller is to
`
`unburden the primary processor from the time consuming task of continually
`
`monitoring the various input elements, while simultaneously ensuring that any user
`
`input would be detected and signaled as quickly as possible. The rationale is that
`
`requiring a main processor to do this task would both slow down other tasks and
`
`make the system less responsive to input.
`
`30. Nothing in the ‘097 Patent specification would have led a person
`
`having ordinary skill in the art to conclude that the input controller must “interpret”
`
`the electrical signals from the actuated input element in order to “generate” the
`
`input signals. To the contrary, the ‘097 Patent specification describes an
`
`embodiment where the input controller 316 converts the electric signals produced
`
`by actuation of the input elements into input signals 122, which are then
`
`interpreted by the hand-held host device using mapping software:
`
`The input controller 316, which may include one or more
`processors, receives the one or more electrical signals 312 and
`converts them into input signals 122 which are transmitted to the
`hand-held host device 117 via communication link 111 connecting the
`communication interface 116 of the input accelerator device 100 with
`the communication interface 118 of the hand-held host device 117.
`Similarly, the input signals 122 are transmitted to the hand-held host
`device 117 via
`communication
`link 211
`connecting
`the
`communication interface 216 of the input accelerator device 200 with
`the communication interface 118 of the hand-held host device 117. In
`
`
`
`22
`
`SCEA Ex. 1039 Page 23
`
`
`
`
`
`one implementation the hand-held host device 117 interprets the
`input signals 122 on the fly using software, such as mapping
`software, to execute the function mapped to the actuated input
`element. Alternatively, the input accelerator device 200 may interpret
`the input signals 122 using software stored in the storage unit 210.
`
`Ex. 1001 at 11:29-46 (emphasis added).
`
`The input elements produce one or more electrical signals 312 upon
`actuation of the input elements. The input controller 316, which may
`include one or more processors, receives the one or more electrical
`signals 312 and converts them into input signals 122, which are in
`a form suitable to be received and interpreted by the hand-held
`host device 117. Alternatively the input signal 122 may be interpreted
`by the processor 104 on the input accelerator device 200.
`
`Id. at 11:54-60 (emphasis added).
`
`“input element . . .