UNITED STATES PATENT AND TRADEMARK OFFICE
`
`______________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`______________________
`
`PANASONIC CORPORATION OF NORTH AMERICA, ET AL.
`Petitioners
`
`v.
`
`CELLSPIN SOFT, INC.
`Patent Owner
`
`______________________
`
`Patent No. 9,258,698
`Inter Partes Review No. 2019-00131
`
`______________________
`
`DECLARATION OF DR. MICHAEL FOLEY CONCERNING PATENT OWNER’S
`SUR-REPLY TO PETITIONER’S REPLY
`
`
`
`1
`
`
`
`
` 
`
`CELLSPIN
`EX. 2026, Page 1
`
`

`

`I, Dr. Michael Foley, declare as follows:
`
`I.
`
`INTRODUCTION, BACKGROUND AND QUALIFICATIONS
`
`1.
`
`My name is Michael Foley, and I am currently the CEO of Innovative Yachtter
`
`Solutions, which provides consulting services relating to Internet-of-Things products, for example
`
`products that utilize Bluetooth® Low Energy technology.
`
`2.
`
`Panasonic Corporation and Panasonic Corporation of North America (collectively
`
`“Petitioner” or “Panasonic”) filed a Petition (Doc 1,) to institute an inter partes review of claims
`
`1, 3–5, 7, 8, 10–13, and 15–20 (“challenged claims”) of U.S. Patent No. 9,258,698 (“’698 patent”).
`
`Ex. 1003. The Petition is supported by the first declaration of Dr. John Strawn, which is Ex. 1001.
`
`The Patent Trial & Appeal Board (“PTAB” or “Board”) instituted inter parties review (Doc 11,
`
`“Institution Decision”). The Patent Owner Cellspin Soft, Inc. (“Cellspin”) filed its Preliminary
`
`Response (Doc 7) on January 30, 2019. Cellspin filed its Response (Doc 19) on July 22, 2019,
`
`along with my prior declaration at Exhibit 2009. Panasonic filed its Reply (Doc 24) on October
`
`15, 2019. Panasonic’s Reply is supported by the Second Declaration of Dr. John Strawn, which
`
`is Ex. 1024. Unless specifically indicated otherwise herein, references herein to Dr. Strawn’s
`
`contentions or to his “Declaration” are directed at his Second Declaration at Ex. 2014. Cellspin
`
`filed objections (Doc 25) to Panasonic’s Reply and to the Strawn Declaration on October 22, 2019.
`
`3.
`
`I have been asked by Cellspin to provide my opinions and analysis responsive to
`
`issues raised by in Petitioner’s Reply and/or the Strawn Declaration at Ex. 2014. For this work I
`
`am being compensated at the rate of $400 per hour. The amount of my compensation is not
`
`dependent upon the substance of my opinions or upon the outcome of this matter.
`
`4.
`
`A true and correct copy of my CV is at Ex. 2010. I received a Bachelor of Science
`
`degree in Electrical Engineering (“EE”) from the University of Iowa, and a Master’s degree and
`
` 
`
`2
`
`CELLSPIN
`EX. 2026, Page 2
`
`

`

`Ph.D. in EE from Arizona State University.
`
`5.
`
`From 1999 to 2004, I worked at Microsoft Corporation as a wireless systems
`
`architect, where I worked on integrating wireless technology into Windows® and WinCE®
`
`platforms. I was also the Microsoft representative to several standards groups, including the
`
`Bluetooth Special Interest Group (“SIG”), the WAP Forum, and the Wi-Fi Alliance.
`
`6.
`
`From 2004 to 2012, I worked at the Bluetooth SIG as Executive Director and CEO.
`
`My responsibilities as Director and CEO of the Bluetooth SIG included, but were not limited to,
`
`directing strategy, member relations, operations, and technology development, expanding the
`
`Bluetooth SIG into Europe and Asia, and managing Bluetooth SIG board meetings.
`
`II.
`
`SUMMARY OF OPINIONS
`
`7.
`
`In addition to the points made in my original declaration at Ex. 2009, Panasonic’s
`
`Reply and the Strawn Declaration highlight that at least these key points are not shown in any of
`
`the materials in which I have reviewed:
`
` a paired wireless connection between a camera and a mobile device;
`
` cryptographic authentication of the mobile device by the camera;
`
` none of the proposed combinations disclose limitation G (request from the mobile device)
`
` using HTTP to upload received file and additional data, e.g., Mashita teaches away from a
`
`cellular phone using HTTP;
`
` combining Mashita with Hirashi would not work;
`
` GUI’s in general and specifically not for image deletion on the wirelessly connected
`
`camera; and
`
`
`
`for claims 5 and 8, a single mobile application performing all the required functions (e.g.,
`
`request, store, HTTP media upload, delete using GUI).
`
` 
`
`3
`
`CELLSPIN
`EX. 2026, Page 3
`
`

`

`8.
`
`In the analysis that follows, I supplement any prior pertinent analysis, focusing on
`
`responding to the Reply and Strawn Declaration, and present my detailed analyses providing clear
`
`rational as to why these and other items are not disclosed or rendered obvious by the asserted prior
`
`art. To the extent necessary or appropriate to provide background, context of support to the matters
`
`herein, my prior Declaration at Ex. 2009 is incorporated by reference herein.
`
`III.
`
`LEGAL UNDERSTANDINGS
`
`9.
`
`I am not a lawyer. My initial legal understandings are stated in my prior Declaration
`
`at Ex. 2009. Any other legal understandings are stated in the body of my report. I have received
`
`my understanding of legal standards, but not factual matters, from Counsel for Cellspin.
`
`IV.
`
`PANASONIC’S ASSUMPTIONS ABOUT MY PRIOR DECLARATION ARE
`INCORRECT
`
`10.
`
`Panasonic incorrectly assumes that my Declaration at Ex. 2009 was copied or
`
`“parroted” from Cellspin’s Response. I am the author of my Declaration at Ex. 2009. I never saw
`
`Cellspin’s Response while I was authoring or drafting my prior Declaration. I did not copy, parrot,
`
`paraphrase or even borrow anything from a Response document that I had not seen. The only
`
`Response that I had seen prior to drafting my prior Declaration was Cellspin’s Preliminary
`
`Response (Doc 7). The opinions and analysis expressed in my prior Declaration, and in this
`
`Declaration, are my own. The similarities between Cellspin’s Response and my Declaration are
`
`due to Cellspin’s Response, which was drafted by Cellspin’s counsel, having copied or
`
`paraphrased matters from my Declaration, including as I was close to reaching a final draft of that
`
`Declaration, and also including from the near final and ultimately final draft of the Declaration.
`
`The foregoing process is also being used for this Declaration, namely, that I have not copied,
`
`parroted, paraphrased or even borrowed anything from Cellspin’s Sur-Reply, which I have not
`
`seen as of the completion and signing of this Declaration.
`
` 
`
`4
`
`CELLSPIN
`EX. 2026, Page 4
`
`

`

`V.
`
`CLAIM CONSTRUCTION
`
`A.
`
`11.
`
`“Pairing” is different from “Authentication” and both are different from
`“Encryption”.
`
`As shown in the figure below [Ex 2006, p. 19], there are 15 different optional
`
`activities after a Bluetooth connection is established. Pairing, Authentication and Encryption are
`
`different optional activities. Also, as shown in Figure 3.1 in the v2.1+EDR Bluetooth Core
`
`Specification [Ex. 2006, p. 861] it again clearly shows that the Pairing is different from
`
`Authentication and both of them are different from Encryption.
`
`
`
` 
`
`5
`
`CELLSPIN
`EX. 2026, Page 5
`
`

`

`
`
`
`
`12.
`
`A POSITA would clearly understand that pairing is different from
`
`authentication and both are different from encryption. Which, if any, of these options are
`
`chosen for a connection depends on the requirements of the solution being implemented. In the
`
`Bluetooth family of specifications, Profile specifications are used to describe how to implement a
`
`particular use case or family of related use cases. Petitioner in his petition and in his reply brief
`
`has tried to conflate these three issues.
`
` 
`
` 
`
`
`
`6
`
`CELLSPIN
`EX. 2026, Page 6
`
`

`

`B.
`
`13.
`
`Cellspin’s Construction of “Paired Connection” is Correct.
`
`Panasonic’s Reply appears to at least mainly take issue with two aspects of
`
`Cellspin’s construction, which is of course my construction as well. For simplicity herein I will
`
`refer to my constructions as Cellspin’s constructions. The issues appear to be whether a “paired
`
`connection” must be capable of providing encrypted data exchange, and whether a paired
`
`connection must be capable of being disconnected and reconnected without having to repeat
`
`pairing and authentication. Reply, p. 3. Contrary to what Panasonic has written, Cellspin’s
`
`construction states that a paired connection provides for encrypted data exchange, not that it
`
`requires it. Indeed, a paired connection may be encrypted or unencrypted and even change from
`
`encrypted to unencrypted during a connection. Panasonic’s implication that providing for
`
`encrypted data equates to requiring it is incorrect.
`
`14.
`
`The concept of a paired connection, as established by the Bluetooth SIG became
`
`known and adopted by certain other industry organizations creating wireless technology for device
`
`connections, such as WiFfi Alliance and Zigbee Forum to name but a few. For example, when
`
`WiFi Alliance created WiFi Direct, it adopted the notion of pairing for creating a relationship
`
`between devices. This can be seen on the Canon website when Canon is describing connecting a
`
`digital camera to a personal computer using Canon’s own EOS Utility software, it states as follows:
`
`“Once you’ve paired the camera and the computer via WiFi they should then talk to each
`any
`time
`in
`the
`future.”
`other
`happily
`at
`[https://cpn.canon-
`europe.com/content/product/canon_software/inside_eos_utility_3_0.do]; and
`
`WiFi pairing is like the paring process to get a mobile phone to pair with your car using
`Bluetooth. A camera can pair with multiple different networks and devices, and store
`them. [https://www.p4pictures.com/2014/08/wifi-pairing-eos-camera-utility-3/]
`
`
` 
`
`7
`
`CELLSPIN
`EX. 2026, Page 7
`
`

`

`Ex. 2027, p. 4;1 Ex. 2028, p. 1.2 The reason for storing the pairing information is so that it may be
`
`used again to avoid having to re-pair when communications are recommenced. This is fundamental
`
`to pairing, and this distinguishes paired connections from mere two-way communications.
`
`15.
`
`Similarly, Zigbee also adopted the concept of pairing as defined by Bluetooth SIG.
`
`In the Zigbee RF4CE Fundamentals paper, Ex. 2003, a discovery and pairing process is described
`
`for establishing relationships between devices. In this document it states that, “[b]oth the originator
`
`and recipient will store information about the other node in an entry in its pairing table.” Ex. 2003,
`
`p. 6.
`
`1.
`
`Pairing under BRI as Contrasted with Pairing under Phillips
`
`Thus far I have been discussing the broadest reasonable interpretation (BRI) of the term
`
`“paired connection.” I am informed by counsel for Cellspin that, under the Phillips standard, the
`
`words of a claim are generally given the ordinary and customary meaning that the term would
`
`have to a person of ordinary skill in the art in question at the time of the invention. To make this
`
`determination, one may consider evidence intrinsic to the patent, i.e., the words of the claims
`
`themselves, the remainder of the specification, and the prosecution history, as well as extrinsic
`
`evidence, which consists of all evidence external to the patent and prosecution history, including
`
`expert opinion, dictionaries, and learned treatises. I also understand that claims must be read in
`
`view of the specification, of which they are a part because the specification is the single best
`
`guide to the meaning of a disputed term. I also understand that extrinsic evidence, considered in
`
` 
`1 Cellspin’s Exhibit 2027 is a true and correct printout from the URL at https://cpn.canon-
`europe.com/content/product/canon_software/inside_eos_utility_3_0.do, which was printed to
`PDF on November 23, 2019.
`2 Cellspin’s Exhibit 2028 is a true and correct printout from the URL at
`https://www.p4pictures.com/2014/08/wifi-pairing-eos-camera-utility-3/, which was printed to
`PDF on November 23, 2019.
`
` 
`
`8
`
`CELLSPIN
`EX. 2026, Page 8
`
`

`

`the context of the intrinsic evidence, may help educate the court regarding the field of the
`
`invention and help the court determine what a person of ordinary skill in the art would
`
`understand claim terms to mean.
`
`In addition to the other documents noted in my prior Declaration and further noted
`
`herein, I have also reviewed the prosecution history for the ‘698 patent at Exhibit 1004, as well
`
`as the prior art that was discussed with the examiner during prosecution, including that noted
`
`herein.
`
`My understanding is that at some point in this proceeding, which very recently came to
`
`involve GoPro and Garmin via a joinder ruling, that I may also be allowed to present different,
`
`and potentially narrower, constructions representing the true meaning of terms to a POSITA
`
`under the above Phillips standard. At present, I will only be addressing the term “paired wireless
`
`connection” in summary to illustrate differences between BRI and Phillips. In doing so, a
`
`POSITA following the guidance of Phillips would alter, by narrowing, the BRI construction,
`
`from:
`
`to:
`
`bidirectional communications link between devices which provides encrypted data
`exchange between the devices, and the communication link can be disconnected and
`reconnected without having to repeat pairing or authentication
`
`bidirectional communications link between devices which provides for authentication and
`encrypted data exchange between the devices by generating one or more cryptographic
`keys, and the communication link can be disconnected and reconnected without having to
`repeat pairing or authentication by saving the cryptographic key(s) for reuse in future
`connections.
`
`This definition for “paired wireless connection,” which is how a POSITA would
`
`understand the term to mean in the context of Bluetooth and in the context of the ‘681 patent, has
`
`been widely adopted in the short-range wireless industry by organizations such as Bluetooth SIG,
`
` 
`
`9
`
`CELLSPIN
`EX. 2026, Page 9
`
`

`

`Zigbee Alliance and WiFi Alliance. Over ten billon products will ship in 2019 containing one or
`
`more of these wireless technologies.
`
`My prior analysis of the “encrypted” aspect of “paired wireless connection” is pertinent
`
`here. If we look further at Bluetooth technology, as shown below, the cryptographic key created
`
`and saved during pairing is the link key.
`
`The Zigbee RF4CE specification v1.01 section 2.4.8 Pairing, discuses pairing of devices.
`
`In that section it states that “if the pairing request was successful, both nodes store a pairing link
`
`in their respective pairing tables.” It then goes on to describe the information stored in the
`
`pairing table:
`
`Each entry in the pairing table contains the following information:
`
`Pairing reference
`Source network address
`Destination logical channel
`Destination IEEE address
`Destination PAN identifier
`Destination network address
`Recipient node capabilities
`Recipient frame counter
`Security link key
`
`•
`•
`•
`•
`•
`•
`•
`•
`•
`
`[Ex. 2032, p. 8-9].3
`
`The last item stored is the cryptographic key. This key is further explained in section 2.4.9
`
`Security. There it is stated “A 128-bit cryptographic key is generated by the recipient of the
`
`pairing request and exchanged with the originator. [Ex. 2032, p. 9].
`
` 
`3 Cellspin’s Exhibit 2032 is a true and correct copy of the ZigBee RF4CE Specification Version
`1.01.
`
` 
`
`10
`
`CELLSPIN
`EX. 2026, Page 10
`
`

`

`The key is stored in the respective pairing tables.” [Ex. 2032, p. 9]. This is the same key
`
`referenced in section 2.4.8. The security section also defines the security services available as
`
`follows:
`
`This mechanism provides the following security services:
`
`•
`
`Data confidentiality: To ensure that the data contained in a ZigBee RF4CE transmission
`
`can only be disclosed to the intended recipient.
`
`•
`
`Data authenticity: To ensure that the intended recipient of a ZigBee RF4CE transmission
`
`knows that the data was sent from a trusted source and not modified during transmission.
`
`•
`
`Replay protection: To ensure that a secure transmission cannot simply be repeated by an
`
`attacking device if overheard.
`
`[Ex. 2032, p. 9]. From this it is clear that Zigbee offers all the components in the narrower
`
`construction for paired wireless connection.
`
`Finally, if we look at the WiFi peer-to-peer specification, aka WiFi Direct, we will see
`
`similar features available for connection pairing. WiFi Direct allows two devices to communicate
`
`without the need to go through an access point as opposed to traditional WiFi where stations
`
`connect to an access point to communicate with the Internet and potentially with other devices
`
`connected to the access point. [Ex. 2033, p. 13] 4.
`
`WiFi Direct leverages traditional WiFi and reuses many portions of it to make
`
`implementing the standard easier. This includes reusing many setup and security aspects of WiFi
`
`within WiFi Direct including WiFi Protected Setup (WPS) and WiFi Protected Access (WPA).
`
` 
`4 Cellspin’s Exhibit 2033 is a true and correct copy of the Wi-Fi Peer-to-Peer (P2P) Technical
`Specification, Version 1.7. 
`
` 
`
`11
`
`CELLSPIN
`EX. 2026, Page 11
`
`

`

`Thus, WPS provides an authentication key distribution method enabling devices to
`
`authenticate with each other and join a WiFi Direct connection. WPA provides for creating
`
`encryptions keys from a pre-shared key known to each device. WPA does provide different levels
`
`of security, enterprise and personal, which can be implemented depending on the targeted
`
`environment for the product.
`
`Through the combination of these WiFi specifications, WiFI Direct implements all the
`
`requirements of the narrower construction of paired wireless connection.
`
`Although I have only addressed the Phillips construction above, I do note that the BRI
`
`constructions previously advanced in my prior Declaration and elsewhere herein serve as a
`
`baseline for proper Phillips constructions, inasmuch as the if a limitation is required by BRI then,
`
`at a minimum, it would also be required by Phillips, even though the Phillips construction is
`
`likely broader, as shown by the example of above.
`
`The v2.1+EDR Bluetooth Core Specification list many optional activities. The
`2.
`mere mention of “Bluetooth connection” in Mashita, Onishi or Hiraishi prior art does
`not establish that the connections described in those references are paired.
`
`16.
`
`The v2.1+EDR Bluetooth Core Specification list many optional activities. The
`
`mere mention of “Bluetooth connection” in Mashita, Onishi or Hiraishi prior art does not establish
`
`that the connections described in those references are paired. The words “pair,” “paired” or
`
`“pairing” do not appear in Mashita, Onishi or Hiraishi reference.
`
`17.
`
`Over time, the concept of pairing as defined by the Bluetooth SIG became an
`
`industry accepted term with the meaning set forth in Cellspin’s construction for “paired wireless
`
`connection.” Cellspin’s construction accords with this meaning and serves to distinguish paired
`
`wireless connections from unpaired ones.
`
`
`
` 
`
`12
`
`CELLSPIN
`EX. 2026, Page 12
`
`

`

`18.
`
`Panasonic asserts that Cellspin’s construction of “paired wireless connection” is
`
`intended to encompass a paired Bluetooth connection. That is correct. However, Panasonic has
`
`failed to cite any disclosure in Onishi, Hiraishi or Mashita, of either a device that has performed
`
`Bluetooth pairing or even one that is capable of performing Bluetooth pairing. Panasonic’s
`
`apparent assumption that the mere use of the word “Bluetooth” or “Bluetooth capability” means
`
`that a device is capable of performing every function described in the voluminous Bluetooth
`
`specification is incorrect and unsupported. I am very well-versed in Bluetooth (as noted above, I
`
`previously worked at the Bluetooth SIG as Executive Director and CEO) and I am not aware of
`
`any consumer products which implement each and every feature in the Bluetooth specifications.
`
`Even if the devices taught by Onishi, Hiraishi or Mashita had been disclosed as being Bluetooth
`
`compliant, which they were not, there is no requirement that Bluetooth compliant devices be
`
`capable of pairing with other devices, that they be capable of cryptographic authentication, or that
`
`they be capable of many other features disclosed in the applicable Bluetooth specification. For
`
`example, v2.1+EDR has error codes for when one device attempts to pair with another that does
`
`not allow pairing: (1) Pairing Not Allowed (0X18); AND (2) Simple Pairing Not Supported
`
`(0X37). If a device that claimed to be Bluetooth complaint actually was Bluetooth compliant, and
`
`if its manufacturer gave it the ability to pair and/or the ability to cryptographically authenticate,
`
`then such pairing or cryptographic authentication would need to be compliant with the Bluetooth
`
`specification. There are, in fact, Bluetooth compliant devices that lack the capability to pair or
`
`cryptographically authenticate their connections. For example, in some stores there are, and have
`
`for many years been, devices that broadcast Bluetooth advertisements without pairing or
`
`cryptographic authentication. Further, the discussion of the Bluetooth Basic Imaging Profile in
`
`my prior Declaration and below illustrates that pairing was not recommended, much less required,
`
` 
`
`13
`
`CELLSPIN
`EX. 2026, Page 13
`
`

`

`for requesting images from a camera. If a manufacturer did not have any requirement for Bluetooth
`
`pairing for image transfer like one suggested in BIP for image pull then it could produce Bluetooth
`
`compliant devices which lacked any programming or ability to pair.
`
`C.
`
`19.
`
`Cellspin’s Construction of “Cryptographically Authenticating” is Correct.
`
`Dr. Strawn and Panasonic’s contention that “encryption” is an “unclaimed concept”
`
`from the term “cryptographically authenticating” is unfounded. Including as noted in Cellspin’s
`
`Response and my prior Declaration, cryptography necessarily entails encryption and decryption.
`
`Including as previously noted, for cryptographic authentication to occur, there needs to be at least
`
`one cryptographic algorithm involved which defines the cryptographic means employed by the
`
`devices. Including as noted in Cellspin’s Response and my prior Declaration, the touchstone of
`
`cryptography is that a person intercepting a transmission cannot understand it without having the
`
`cipher, which to POSITA requires an algorithm to encrypt and decrypt. The cryptographic
`
`algorithm(s) utilized may require key exchanges, challenge/response techniques or other methods
`
`to authenticate the devices.
`
`20.
`
`The notion that cryptographically is so broadly interpreted beyond encryption that
`
`it also includes mere secrecy or security is erroneous. The issue of Mashita’s PIN illustrates the
`
`point. Panasonic and Dr. Strawn have no reasoned argument that merely exchanging a four-digit
`
`PIN, which is all that Mashita teaches, is cryptographic. Panasonic and Dr. Strawn’s main
`
`argument for exchanging a PIN being cryptographic is an overbroad construction that includes
`
`mere secrecy. See, e.g., Ex. 1026, ¶8 (“Thus, entering a secret PIN into both the camera and the
`
`cellular phone constitutes cryptographically authenticating.”). To a POSITA, if one intercepted
`
`the PIN, then they would know the PIN, which illustrates why a secret PIN is not cryptographic.
`
`
`
` 
`
`14
`
`CELLSPIN
`EX. 2026, Page 14
`
`

`

`21.
`
`Panasonic’s assertion that Mashita’s entering of a PIN into each of two devices
`
`constitutes cryptographic authentication is, at most, based upon speculation of what might happen
`
`once the PIN was entered. The unstated implication made by Panasonic and Dr. Strawn is that
`
`Mashita’s PIN might theoretically be used to generate encryption keys. To get from Mashita’s
`
`mere PIN entry to cryptographic authentication requires either speculation that the PINs might
`
`theoretically be used in additional cryptographic processes involving cryptographic algorithms, or
`
`it simply requires disregarding the requirement of cryptographic authentication altogether.
`
`22.
`
`Panasonic and Dr. Strawn attempt to side-step their erroneous position on the
`
`construction of “cryptographically authenticating” by constructing an argument that (1)
`
`unspecified prior art “discloses (or at least would have rendered obvious) a paired Bluetooth
`
`connection;” and that (2) Bluetooth pairing uses a cryptographic algorithm for authentication. The
`
`fallacy of argument (1) is addressed in Section IV.A below and otherwise hereon. Argument (2)
`
`is merely an unsupported statement found once in Panasonic’s Reply. Including as explained in
`
`m my prior Declaration, a POSITA understands that, in Bluetooth communications, authentication
`
`and pairing are separate acts, and that two devices could pair without authenticating, or it could
`
`authenticate without pairing.
`
`D.
`
`23.
`
`Cellspin’s Construction of “Graphical User Interface” (i.e., “GUI”) is Correct.
`
`Panasonic and Dr. Strawn make the remarkable assertion that Cellspin’s
`
`construction of GUI errs in distinguishing graphical interfaces from “text-based” interfaces. Here
`
`Panasonic misses the basic point that an important distinction between graphical interfaces and
`
`text-based interfaces is that the former are graphical and the latter are not.
`
` 
`
` 
`
` 
`
`15
`
`CELLSPIN
`EX. 2026, Page 15
`
`

`

`24.
`
`Panasonic’s basic argument is that using keystrokes to highlight different areas of
`
`a character-based interface constitutes GUI. Panasonic’s invalidity positions are based upon this
`
`overbroad notion of text-based interfaces being GUIs. Even if Cellspin’s proposed construction
`
`was rejected in part, an overbroad construction of GUI would not be reasonable or otherwise
`
`correct if it allowed using keystrokes to highlight different areas of a character-based interface to
`
`constitute a GUI.
`
`25.
`
`Panasonic and Dr. Strawn argue that the record does not support a GUI having the
`
`graphics-based requirements in Cellspin’s construction. This erroneous argument fails to
`
`understand that the ‘698 specification incorporates in its entirety U.S. Patent Application No.
`
`11/901,802 (the “802 Application). See Ex. 1002, 1:32-36. In the incorporated ‘802 application,
`
`FIG. 3 exemplarily illustrates the publishing of multimedia content using the client application 202
`
`on the mobile device. Ex. 2021, para. 40-42. The “enter screen” as illustrated on the graphical user
`
`interface (GUI) 202a of the client application 202 provides options for the selection of the medium
`
`for the multimedia content to be created. The user 201 selects the preferred publication websites
`
`or publication virtual spaces 205 using an `add publishers` menu option provided on the enter
`
`screen.
`
`26.
`
`Panasonic argues that the GUI disclosed in Cellspin’s incorporated patent
`
`application does not meet Cellspin’s definition of GUI because the devices allowed user inputs
`
`including a button “click or touch.” See Ex. 2021, Fig. 3, 7:17-20. Panasonic’s reasoning is flawed.
`
`Devices with a GUI can accept keystroke commands, but that does not mean that devices that only
`
`accept keystroke commands have GUIs.
`
` 
`
` 
`
`
`
`16
`
`CELLSPIN
`EX. 2026, Page 16
`
`

`

`  
`
`E.
`
`
`27.
`
`Cellspin’s Construction of “A Software Application” to Refer to One Software
`Application is Correct
`
`Claims 5 and 8 each refers to singular “a mobile software application” and “a
`
`software application,” respectively, and each subsequent reference to “said” or “the” software
`
`application is to the antecedent singular “a” application. Clearly this “application” is required to
`
`perform multiple functions in claims 5, 8 and their dependent claims. When the ‘698 patent refers
`
`to a software or mobile software application, in every instance it refers to a single “client
`
`application 203.” There are numerous references to this application in the specification and all are
`
`to a single application. Furthermore, Figures 2 and 4 of the ‘698 patent depict one box for client
`
`application 203.
`
`
`
` 
`
`PANASONIC
`EX. 1003, Page 4
`
`
`
`17
`
`CELLSPIN
`EX. 2026, Page 17
`
`

`

`
`In both figures 2 and 4, within client application 203, there are multiple boxes
`
`28.
`
`which could be implemented in different modules as Panasonic and Dr. Strawn suggest. Many of
`
`these boxes are even labeled as modules. However, in the figures, those modules are clearly
`
`consolidated into a single application running on the cellular phone.
`
`29.
`
`In his second declaration, Dr. Strawn states “Even leaving aside this rule, from a
`
`technical perspective I do not see a distinction between using a client application composed of
`
`multiple modules and the combination of Mashita and Hiraishi, which would render such an
`
`approach obvious.” [Ex 1024 ¶25] There are both technical and usability aspects as to why this is
`
`incorrect. To teach HTTP uploads to the server, Petitioner is relying on Hirashi. In Hirashi a web
`
`browser is utilized for the image upload and a separate application for obtaining the image from
`
`the camera. Hirashi requires two applications to accomplish obtaining the image from the digital
`
`camera and a web browser to upload the image to the server.
`
` 
`
` 
`
`
`
`18
`
`CELLSPIN
`EX. 2026, Page 18
`
`

`

` 
`
`30. When separate applications are used for obtaining the image from the digital
`
`camera and uploading it to the server, the uploading application must be made aware that there is
`
`a new image ready to be uploaded and where that image resides on the cellular phone. Typically,
`
`this was accomplished by manual steps undertaken by the user. Even with user intervention, due
`
`to the fact that applications were sandboxed in an iPhone it was difficult, if not impossible, to share
`
`images directly between arbitrary applications making the multi-application solution difficult or
`
`impossible to implement. Due to these technical and usability limitations, a POSITA would not
`
`look to implement the single application taught in the ‘698 patent with multiple applications as
`
`would be required when combining Mashita and Hirashi.
`
`
`VI.
`
`
`
` LIMITATION C (I.E., A PAIRED WIRELESS CONNECTION) IS NOT
`DISCLOSED IN MASHITA, ONISHI or HIRAISHI. FURTHER, PANASONIC
`AND DR. STRAWN’S NEW OBVIOUSNESS THEORY IS UNFOUNDED.
`
`A. Mashita, Onishi or Hiraishi Does Not Disclose Establishing a Paired wireless
`connection Between a Cellular Phone and Digital Camera.
`
`Panasonic and Dr. Strawn somehow continue to contend that Mashita authenticates
`
`31.
`
`the identity of the cellular phone by use of a shared PIN which is mischaracterized as a passkey.
`
`See, e.g., Ex. 1024, ¶¶ 9,40 & 94. To the contrary, with only the physical addresses being saved,
`
`future connections would need the PIN to be reentered for authentication to occur. This is opposed
`
`to the proper construction of pairing wherein future connections don’t require the user to enter
`
`information again.
`
`32.
`
`The concept of a passkey isn’t even raised in Mashita, nor is the word “passkey”
`
`found in the text of Mashita. Ex. 1006. As shown below, Mashita states twice that only the physical
`
`device addresses are stored:
`
` 
`
`19
`
`CELLSPIN
`EX. 2026, Page 19
`
`

`

`Reference numeral 208 represents a local wireless unit composed of a wireless protocol, a
`baseband, and a Radio Frequency (RF) unit needed for Bluetooth communication. A
`physical address (a 48-bit address for identification of the portable device 101 in Bluetooth
`communication) 210 is recorded in the local wireless unit 208.
`…
`“The connection authentication leads to establishment of a local wireless link (step
`S901). Here, the physical address 210 of the digital camera 101 is saved in the
`application memory 304 of the cellular phone 102. Furthermore, the physical address 311
`of the cellular phone 102 is saved in the RAM 203 of the digital camera 101.”
`
`Ex. 1006, ¶30 & 94; A link key, or other cryptographically created entity isn’t saved. Ex. 1006,
`
`¶ 30. A 48-bit Physical address is NOT a cryptographically created entity.
`
`33.
`
`In the v2.1+EDR Bluetooth Core Specification, the concept of a PIN and passkey
`
`are very different and not synonymous. For example, the v2.1+EDR Bluetooth Core Specification
`
`states:
`
`“Note that there is a significant difference from a cryptographic point of view between
`Passkey Entry and the PIN entry model used by Bluetooth Core Specification 2.0 + EDR
`and earlier versions. In the Passkey Entry association model, the six digit number is
`independent of the security algorithm and not an input to it, as is the case in the 2.0 + EDR
`security model. Knowing the entered number is of no benefit in decrypting the encoded
`data exchanged between the two devices.”
`
`Ex. 2006,135; The