UNITED STATES PATENT AND TRADEMARK OFFICE
`
`______________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`______________________
`
`CANON U.S.A., INC.
`Petitioner
`
`v.
`
`CELLSPIN SOFT, INC.
`Patent Owner
`
`______________________
`
`Patent No. 9,258,698
`Inter Partes Review No. 2019-00127
`
`______________________
`
`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.
`
`Canon U.S.A., Inc. (“Petitioner” or “Canon”) filed a Petition (Doc 1,) to institute
`
`an inter partes review of claims 1-22 (“challenged claims”) of U.S. Patent No. 9,258,698 (“’698
`
`patent”). Ex. 1001. The Petition is supported by the first declaration of Dr. Vijay Madisetti, which
`
`is Ex. 1003. The Patent Trial & Appeal Board (“PTAB” or “Board”) instituted inter parties review
`
`(Doc 7, “Institution Decision”). The Patent Owner Cellspin Soft, Inc. (“Cellspin”) filed its
`
`Preliminary Response (Doc 6) on January 30, 2019. Cellspin filed its Response (Doc 17) on July
`
`22, 2019, along with my prior declaration at Exhibit 2009. Canon filed its Reply (Doc 24) on
`
`October 22, 2019. Canon’s Reply is supported by the Second Declaration of Dr. Madisetti, which
`
`is Ex. 1043. Unless specifically indicated otherwise herein, references herein to Dr. Madisetti’s
`
`contentions or to his “Declaration” are directed at his Second Declaration at Ex. 2043. Cellspin
`
`filed objections (Doc 28) to Canon’s Reply and to the Madisetti Declaration on October 28, 2019.
`
`3.
`
`I have been asked by Cellspin to provide my opinions and analysis responsive to
`
`issues raised by in Canon’s Reply and/or the Strawn Declaration at Ex. 2043. 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
`
`Ph.D. in EE from Arizona State University.
`
`
`
`2
`
`CELLSPIN
`EX. 2026, Page 2
`
`

`

`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.
`
`7.
`
`In addition to the points made in my original declaration at Ex. 2009, Canon’s Reply and
`
`the Madisetti Declaration highlight that at least these key points which are not shown in or
`
`rendered obvious by any of the Canon materials in which I have reviewed:
`
`• Paired wireless connection between a digital camera and a mobile device;
`
`• Cryptographic authentication of the mobile device by the camera;
`
`• Using HTTP to upload received media file along with user information;
`
`• GUI’s in general and specifically not for image deletion on the wirelessly connected
`
`digital 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).
`
`8.
`
`In the analysis that follows, I supplement any prior pertinent analysis, focusing on
`
`responding to the Reply and Madisetti Declaration, and present my detailed analysis 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.
`
`
`
`3
`
`CELLSPIN
`EX. 2026, Page 3
`
`

`

`II.
`
`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 declaration. I have
`
`received my understanding of legal standards, but not factual matters, from Counsel for Cellspin.
`
`Without limitation, this Declaration uses the same definition of “POSITA” as my prior
`
`Declaration, the claim construction positions set forth in this declaration are also based upon the
`
`same broadest reasonable interpretation (“BRI”) standard, and this Declaration is also written from
`
`the perspective of a POSITA at the time of the ‘698 invention in late 2007.
`
`III. RESPONSE TO CANON’S INTRODUCTORY REMARKS
`
`10.
`
`The introduction to Canon’s Reply contends that Cellspin has “narrowed” and
`
`“rewritten” terms. Canon complains specifically about a “paired wireless connection” providing
`
`for encrypted data exchange and including a communication link that can be disconnected and
`
`reconnected without having to repeat pairing. Canon’s complaints are unfounded. My
`
`constructions of “paired wireless connection” and the other terms noted, which is also what
`
`Cellspin has advocated, are from the BRI perspective of a POSITA, as explained in my original
`
`Declaration at Exhibit 2009.
`
`11.
`
`The introduction to Canon’s Reply also contends that my prior Declaration “cherry
`
`picked allegedly “optional” features from the Bluetooth specification and imported them into the
`
`plain claim language.” These contentions are also unfounded. Although pairing itself is optional
`
`in the Bluetooth specification, to a POSITA, for there to be pairing, the connection must provide
`
`for encrypted data exchange and there must be a communication link that can be disconnected and
`
`reconnected without having to repeat pairing, as explained in my original Declaration. Without
`
`these minimal requirements, there can be two-way communications but pairing does not occur. As
`
`
`
`4
`
`CELLSPIN
`EX. 2026, Page 4
`
`

`

`noted in my prior Declaration, mere two-way wireless communication, for example
`
`communication between
`
`two devices simply exchanging capabilities,
`
`is not paired
`
`communications.
`
`12.
`
`The introduction to Canon’s Reply also points out that “paired” in the ‘698 patent
`
`is not limited to Bluetooth pairing. My prior Declaration did not assume or contend that “paired”
`
`was limited to Bluetooth pairing, and this Declaration does not either.
`
`A. Canon’s NEW theory that use of “Bluetooth” renders obvious paired connections
`is meritless, nor does it address the steps in the claims, for example, uploading
`media files over an already paired connection
`
`13.
`
`The theory of pairing in Canon’s Petition was that Hiroishi and Hollstrom disclosed
`
`two-way communications which allegedly disclosed pairing. Canon and Dr. Madisetti’s new
`
`theory in Canon’s Reply appears to be that use of Bluetooth renders obvious paired connections.
`
`This new theory, like Canon/Madisetti’s prior theory, is incorrect. The only disclosure of Hiroishi
`
`and Hollstrom is that they utilize “Bluetooth,” without providing any details of what specific
`
`Bluetooth options or profiles they would utilize out of the multitude of options set forth in the
`
`lengthy Bluetooth specification(s).
`
`B. Canon and Dr. Madisetti fail to cite prior disclosure of a device in Hiroishi or
`Hollstrom that has performed any claimed method or a device that would be
`capable of the claimed functions
`
`Notably, Canon and Dr. Madisetti fail to cite prior disclosure of a device in Hiroishi
`
`14.
`
`or Hollstrom that has performed any claimed method or a device that would be capable of the
`
`claimed functions. Further, Canon and Dr. Madisetti fail to cite prior disclosure of any device that
`
`has performed any claimed method or any device that would be capable of the claimed functions.
`
`C. To the extent that Canon assumes that all “Bluetooth” devices are capable of
`performing every function described in the Bluetooth specification, that is
`incorrect
`
`
`
`5
`
`CELLSPIN
`EX. 2026, Page 5
`
`

`

`15.
`
` To the extent that Canon assumes that all “Bluetooth” devices are capable of
`
`performing every function described in the Bluetooth specification, that is incorrect. Even if the
`
`devices taught by Hiroishi and Hollstrom 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. Rather, if a Bluetooth complaint
`
`device performed processes within the scope of the Bluetooth specification, for example optional
`
`pairing or cryptographic authentication, then such pairing or cryptographic authentication would
`
`need to occur in accordance with the Bluetooth specification.
`
`16.
`
`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 Hiroishi, Hollstrom, Ando, Nozaki 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.
`
`17.
`
`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):
`
`
`
`
`
`6
`
`CELLSPIN
`EX. 2026, Page 6
`
`

`

`
`
`BLlETOOTH SPECIFICA‘HON Version 2.1 4' EDR [vol 0] pogo 15 01' I4
`
`6 Biuetootll'
`Parameter Definitions .............................................................. 313
`
`LMP Encepeueied ................................................................... 323
`Default Values .......................................................................... 324
`
`5.2
`
`5.3
`6.4
`
`3
`7
`
`List oi Figures ..................................................323
`List 01' fillies __________________________________________________323
`
`Part D
`ERROR CODES
`
`Conhnto ......“.--......-..m......-.............-....--.-.....-.-..............................333
`
`1
`
`2
`
`Overview o1 Error Codes .............”.........”..................................335
`
`1.1
`1.2
`1 .3
`
`Usage Descriptions .................................................................. 335
`HCI Commend Errors ............................................................... 335
`
`Llei 01 Error Codes ................................................................ 33B
`
` aim
`
`Error Code Descriptions.............-........-m.............................--.“ 333
`2.1
`Unknown HCI Comend {oxen .............................................. 338
`2.2
`Unknown Comedian identlierioxoz)..."
`.....333
`
`2.3 Haldware Failure (0X03) .......................................................... 333
`2.4
`Page Timeout (0X01) ............................................................... 338
`2.5 Mienliceficn Fella-e (0x05)-..
`
`2.6
`PIN or key Misehg (0X06)...
`2.7 Muncry Capacity Exceeded (axon
`23 ConnectionTimeout (oxoe) ..................
`2.9
`Connection Unit Exceeded (0X09). .........................................
`2.10 Synchronous Conneclon Limit to a Device Exceeded {OXOAJ339
`2.11 ACi. Connection Ahead)! Existe {OXOB}339
`2.12 Commend Diseiicwed (oxoc) .................................................. 339
`2.13 Connection Rejected due to Limited Resources (OXOD)..........339
`2.14 Connection Rejected due I: SecurRy Reasons (OXOE) ...........339
`2.15 Connection Rejected due to Unacceptable BD__ADDR (OXOF)340
`2.16 Connection Accept Timeout Exceeded {0x103340
`2.1? Unsupported Feature orm Value (0x11i....................340
`2.13 inveld i-iCl Commend Paremeiers(0)(12)....
`........-.......340
`2.19 We User Termhated Connection (0x131...
`".3110
`220 Remote Device Tennineted Connection due in Low Resources
`(0X14) ...................................................................................... 341
`2.21 Remote Device Terminated Connection due to Power 011 (0x15)
`................................................................................................. 341
`2.22 Comectien Terminated by Locel Host (OX16)......
`.........341
`
`223 Repeated Atten’ots (0)617}....................................................... 341
`2.24 —(ox1e)..341
`225 Unknown LNP PDU (0x19) ..................................................... 341
`
`“MM?
`
`
`
`
`
`7
`7
`
`CELLSPIN
`EX. 2026, Page 7
`
`CELLSPIN
`EX. 2026, Page 7
`
`

`

`
`
`BLUETOOTH SPECIFICATIONW 2.1 4- EDR [vol 0] page 18 d 74
`
`autumn.
`
`2.26 Unsupported Remote Feature I"Unsrpportod LMP Feature
`(0X1AJ...
`... 341
`2.2? 800 MeetRejected (0X18) 341
`2.28 360 Interval Rejected (0X16): 342
`2.29 SCO Air Mode Rejected (0X10J342
`2.30 Invalid LMP Parameters (0X1EJ... 342
`2.31 Unspecified Error (0X1FJ...
`342
`2.32 Unsupported LMP Parameter Value (0X20) 342
`2.3 Role Change Not Aimed (0X21)... 342
`2.34 LMP Response 11maout (0X22J342
`2.35 LMP Error Transaction Collision (0X23J ..................................
`2.36 LMP PDU Not Mowed (0X24)....
`2.37 Encryption Mode Not Aocepmble(0X25J..
`2.3!! Link Key Can Not be Changed (0X26)...
`2.39 Requested One Not Supported (0X27J ....................................
`2.40 Instant Passed (0X28J...
`
`.
`
`.
`
`.
`
`..
`
`.
`
`%z%%%§%%s:£2%%52%%s
`
`2.41 Pairing with Unit Key Not Supported (0X29)
`2.42 Diflarent Transaction Colislon (0x2aJ....
`2.43 008 Unacceptable Parameter (0X2CJ .....................................
`2.44 008 Rejected (0X2DJ ..............................................................
`2.45 Channel CIasslflcetion Not Supported {0X2EJ
`2.46 Insullicient Security (0X2FJ...
`2.47 Parameter out 01 Mandatory Range (0X30)
`2.48 Role Switch Pending l0X32)...
`2.49 Reserved Slot Violation l0X34J...
`2.50 Rate Swibh Faled (0X35)...
`2.51
`Extended inquiry ResponseToo Large {0x38}
`252 Simple—.vaHost (0X37)
`
`2.53 Host Busy-PathflomL.
`
`Part E
`HOST CONTROLLER INTERFACE FUHCTIOIIAL SPECIFICATION
`
`Contents .............................................................................. .
`
`E
`
`1
`
`2
`3
`
`hh'oducllona ........................................................... 357
`
`1.1
`
`Lower Layers oIthe Bluotoolh Software Stock357
`
`Overview of Host Controller Transport Layer ...................... 350
`Overvlew of Commands and Event: .............................. 300
`
`3.3 Controler Flow Control 362
`3.4 Controler Information362
`
`
`
`
`
`3M3)”
`
`8
`
`
`
`CELLSPIN
`EX. 2026, Page 8
`
`CELLSPIN
`EX. 2026, Page 8
`
`

`

`18.
`
`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 (BIP)
`
`in my prior Declaration and herein illustrates that pairing was not recommended, much less
`
`required, for requesting images from a camera. If a manufacturer did not have any requirement
`
`for Bluetooth pairing for image transfer like that suggested in BIP for image pull then it could
`
`produce Bluetooth compliant devices which lacked any programming or ability to pair.
`
`D. Canon’s NEW routine/design choice arguments are unfounded and mistaken.
`The only obvious choice for a POSITA under Bluetooth at the time of invention
`would have been to use Secure Simple Pairing (i.e., Security Mode 4, the default
`mode) and the Basic Image Profile for image pull, both of which involved unpaired
`and unauthenticated connections
`
` Canon and Dr. Madisetti’s new but incorrect argument that pairing a Bluetooth
`
`
`19.
`
`connection between a camera and a mobile phone was “routine” or merely a “design choice” to a
`
`POSITA at the time of the invention, and further what may be Canon/Madisetti’s implied argument
`
`that the ordered steps (e.g., uploading photos from a camera to a mobile phone over an already
`
`paired Bluetooth connection) of Cellspin’s claimed inventions were somehow “routine” or merely
`
`a “design choice” to a POSITA at the time of the invention, is mistaken. Among other things,
`
`Canon/Madisetti fail to appreciate (1) that transfer of photos from a camera to a mobile phone over
`
`an already paired connection has not been shown to be an existing, much less routine, process at
`
`the time of invention; (2) that pairing had usability problems that mitigated against its use in this
`
`context at the time of invention, and that the obvious choice for a POSITA under Bluetooth at the
`
`time of invention would have been to use the Basic Image Profile (“BIP”) for image pull, which
`
`specified an unpaired and unauthenticated connection. Canon and Dr. Madisetti have failed to
`
`
`
`9
`
`CELLSPIN
`EX. 2026, Page 9
`
`

`

`identify a single device that existed prior to the ‘698 application that transferred, or that was even
`
`capable of transferring, photos from a camera to a mobile phone over an already paired connection,
`
`for it to be routine.
`
`20.
`
`I am informed by counsel for Cellspin that the Nevro decision relied upon by Canon
`
`involved a detachable electrode array being obvious because it was a universal practice at the
`
`critical date, and because it was necessary for implantation of the system in question. Unlike the
`
`issues in the Nevro case, pairing connections between cameras and mobile devices was certainly
`
`not a universal practice at or before the critical date, nor was it necessary for uploading photos
`
`wirelessly from a camera to a phone, including as demonstrated by the BIP. Far from the relevant
`
`functionality being a universal or necessary practice, Canon and Dr. Madisetti have failed to
`
`identify a single device that existed prior to the ‘698 application that transferred photos from a
`
`camera to a mobile phone over an already paired connection.
`
`21.
`
`In the relevant 2007 timeframe, Bluetooth technology had a reputation as being too
`
`difficult for end users to pair devices. If a POSITA was to consider requiring pairing of the cellular
`
`phone and the digital camera described in the ‘698 patent, the POSITA in 2007 would surely look
`
`at v2.1+EDR Bluetooth Core Specification, Secure Simple Pairing, Security Mode 4, the default
`
`mode (unpaired, encrypted, unauthenticated and unauthorized), as the method to implement. Dr.
`
`Madisetti relies on older Security Mode 3, which was excluded from the v2.1+EDR Bluetooth
`
`Core Specification and had earned a bad reputation in the industry as being too difficult for the
`
`end user to successfully perform pairing.
`
`E. The v2.1+EDR Bluetooth Core Specification, and prior versions of the Bluetooth
`core specification, list many optional activities
`
`The v2.1+EDR Bluetooth Core Specification, and prior versions of the Bluetooth
`
`
`22.
`
`core specification, list many optional activities. Among a multitude of optional activities are
`
`
`
`10
`
`CELLSPIN
`EX. 2026, Page 10
`
`

`

`pairing and authentication. The mere mention of a Bluetooth connection in Hiroishi and Hollstrom
`
`does not establish that the connections described in those references are paired or authenticated.
`
`The words “pair,” “paired” or “pairing” does not appear either of those references. See Ex. 1005,
`
`1013. Further, the words “authenticate” or “authenticated” do not appear in Hiroishi and
`
`Hollstrom. See Ex. 1005, Ex. 1013. Further, the only mention of “authentication” in Hiroishi is in
`
`the context of a telephone network authenticating a mobile phone via its caller ID. Ex. 1005, [0048,
`
`0113]. As shown in the figure below [Ex 2006, P. 19], there are 15 optional activities after a
`
`Bluetooth connection is established.
`
`23. With 15 optional activities, there are 215 – 1 = 32,767 total combinations of optional
`
`activities after ACL connection establishment. Even if all the options are not mutually exclusive,
`
`the number of combinations will be reduced from 32,767, but will remain a very large number of
`
`
`
`
`
`11
`
`CELLSPIN
`EX. 2026, Page 11
`
`

`

`possible combinations. The ‘698 patent specification teaches one particular combination from the
`
`large number of available options. It is only through improper hindsight that this one particular
`
`option allegedly appears obvious and would allegedly be a simple design decision in late 2007
`
`when the ‘698 patent was filed.
`
`24.
`
`To focus upon a dichotomy of paired vs. unpaired is an oversimplification of the
`
`Bluetooth connection model. Even when we look at only the security modes described in the
`
`Exhibit 2006, v2.1+EDR Bluetooth Core Specification, which is what a POSITA would have
`
`consulted for Bluetooth in the 2007 timeframe, there are significantly more options than just paired
`
`or unpaired. A more complete list of options is:
`
`Unpaired, unencrypted, unauthenticated and unauthorized
`Unpaired, unencrypted, unauthenticated and authorized
`Unpaired, unencrypted, authenticated and unauthorized
`Unpaired, unencrypted, authenticated and authorized
`Unpaired, encrypted, unauthenticated and unauthorized (default mode)
`Unpaired, encrypted, unauthenticated and authorized
`Unpaired, encrypted, authenticated and unauthorized
`Unpaired, encrypted, authenticated and authorized
`Paired, unencrypted, unauthenticated and unauthorized
`Paired, unencrypted, unauthenticated and authorized
`Paired, unencrypted, authenticated and unauthorized
`Paired, unencrypted, authenticated and authorized
`Paired, encrypted, unauthenticated and unauthorized
`Paired, encrypted, unauthenticated and authorized
`Paired, encrypted, authenticated and unauthorized
`Paired, encrypted, authenticated and authorized
`
`•
`•
`•
`•
`•
`•
`•
`•
`•
`•
`•
`•
`•
`•
`•
`•
`
`Any attempt to oversimplify these connection options as simply paired or not paired, results in an
`
`inaccurate analysis of the Bluetooth specifications and how they are implemented.
`
`25.
`
`Further, the default connection mode described in the v2.1+EDR Bluetooth Core
`
`Specification is for the connection to be unpaired, encrypted, unauthenticated and unauthorize. Ex
`
`2006, p. 1273. Without other requirements in place for a connection to be paired, there is no
`
`substantial reason that a POSITA would not choose the default connection. For example, the most
`
`
`
`12
`
`CELLSPIN
`EX. 2026, Page 12
`
`

`

`widely used application for image transfer currently used is AirDrop provided by Apple. AirDrop
`
`uses a different connection option that does not require entering a passkey or doing a numeric
`
`comparison on either device. AirDrop doesn’t pair the devices exchanging images.
`
`26.
`
`Canon’s Reply contends that I admitted in my deposition that a POSITA would
`
`have been motivated to use pairing and cryptographic authentication in specific situations, such as
`
`transferring confidential media files between a digital camera and cellular phone. The text of the
`
`question and answer cited by Canon is as follows:
`
`Q. That six-digit passkey, is that a required aspect of authentication?
`A. That is how you authenticate it.
`Q. So you can't --
`A. Well, that -- that passkey is put into an algorithm and depending on which mode, it's
`used differently, but it's the shared secret that allows for authentication.
`Q. Is that the only way to authenticate?
`A. You can use [out of] band techniques as well.
`
`Ex. 1040, 65:7-17 (correcting “auto band” to “out of band” due to transcription error).
`
`27.
`
`Canon misunderstands this discussion. This discussion involved the statement in
`
`my prior Declaration that Bluetooth devices utilizing secure simple pairing could provide an
`
`additional security layer by generating a six-digit passkey to avoid man in the middle attacks. A
`
`man in the middle attack refers to when someone intercedes between two devices and intercepts
`
`the communications going between them. A POSITA understands that pairing is not necessary to
`
`avoid man-in-the middle attacks. A POSITA also understands that neither pairing nor
`
`cryptographic authentication are necessary to protect against man in the middle attacks, and that
`
`there are many ways to provide for secure wireless communications which do not involve pairing
`
`or cryptographic authentication.
`
`
`
`
`
`
`
`13
`
`CELLSPIN
`EX. 2026, Page 13
`
`

`

`IV. CELLSPIN’S CLAIM CONSTRUCTIONS ARE PROPER
`
`A.
`
`28.
`
`“Pairing” is different from “Authentication” and both are different from
`“Encryption”
`
`As shown in the figure above [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.
`
`29.
`
`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. Which options to choose are not simply a routine design choice.
`
`B.
`
`30.
`
`Cellspin’s Construction of “Paired Wireless Connection” is Correct
`
`Canon’s Reply appears to 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. Reply, p. 1.
`
`Contrary to what Canon 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.
`
`Canon’s implication that providing for encrypted data equates to requiring it is incorrect.
`
`
`
`14
`
`CELLSPIN
`EX. 2026, Page 14
`
`

`

`31.
`
`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 WiFi 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. [Ex. 2033, p. 13] 1. 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). 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.
`
`32.
`
` This can be seen on the Canon’s own 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
`at
`any
`time
`in
`the
`future.”
`other
`happily
`[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/].
`
`
`
`1 Cellspin’s Exhibit 2033 is a true and correct copy of the Wi-Fi Peer-to-Peer (P2P) Technical
`Specification, Version 1.7.
`
`
`
`
`15
`
`CELLSPIN
`EX. 2026, Page 15
`
`

`

`Ex. 2027, p. 4;2 Ex. 2028, p. 1.3 (emphasis added to both). 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 which creates a better user experience. This is fundamental to pairing, and this
`
`distinguishes paired connections from mere two-way communications.
`
`33.
`
`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. It then goes on to describe the information stored in the pairing table:
`
`34.
`
`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
`
`
`2 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.
`3 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.
`
`
`
`
`16
`
`CELLSPIN
`EX. 2026, Page 16
`
`

`

`[Ex. 2032, p. 8-9].4
`
`35.
`
`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].
`
`36.
`
`The key is stored in the respective pairing tables.” [Ex. 2032, p. 9]. This is the same
`
`key referenced in section 2.4.8.
`
`37.
`
`Thus pairing in Zigbee, as in Bluetooth and WiFi, provides for encrypted data
`
`exchange and stores the connection information such that it can be used in subsequent connections
`
`without having to repeat the pairing process.
`
`C.
`
`38.
`
`Canon’s New Construction of “Paired Wireless Connection” is Vague and
`Incorrect
`
`Canon and Dr. Madisetti have changed their construction of pairing with each
`
`brief and declaration filed. In Canon’s IPR Petition, it states “The connection is paired because it
`
`allows two-way communication between the digital camera 50 and cellular phone 40”. [Petition
`
`pg 22]. Similarly, in Dr. Madisetti’s first declaration he states, “The connection is paired because
`
`it allows two-way communication between the digital camera 50 and cellular phone 40”. [Ex 1003
`
`¶98] This construction states that a paired connection is any connection allowing two-way
`
`communication. This construction is unreasonably broad and too simplistic. It has been shown
`
`that many wireless technologies, including Bluetooth and WiFi allow for two-way communication
`
`without pairing.
`
`39.
`
`Since Canon and Dr. Madisetti’s first construction for pairing was too broad and
`
`simplistic, they migrated to a new construction. Relying upon Dr. Madisetti’s new Declaration at
`
`
`4 Cellspin’s Exhibit 2032 is a true and correct copy of the ZigBee RF4CE Specification Version
`1.01.
`
`
`
`17
`
`CELLSPIN
`EX. 2026, Page 17
`
`

`

`Ex. 1043, in Canon’s Reply Brief, pairing