throbber
UNITED STATES PATENT AND TRADEMARK OFFICE
`
`____________
`
`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 . . .

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket