`
` 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
`
`
`
`
`
`
`
`CASE: 2019-00131
`Patent No. 9,258,698
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`SECOND DECLARATION OF DR. JOHN STRAWN
`IN SUPPORT OF
`PETITION FOR INTER PARTES REVIEW
`OF U.S. PATENT NO. 9,258,698
`
`
`
`
`
`IPR2019-00131
`PANASONIC EX. 1024, p. 1 of 32
`
`
`
`
`
`I.
`
`II.
`
`BACKGROUND AND QUALIFICATIONS............................................... 1
`
`INFORMATION PROVIDED TO ME ........................................................ 1
`
`A. My Understanding of the Law Regarding Prior Art...................................... 2
`
`III. CLAIM CONSTRUCTION ......................................................................... 2
`
`A. “Cryptographically Authenticating Identity” Term ...................................... 2
`
`IV. THE CHALLENGED CLAIMS WOULD HAVE BEEN OBVIOUS IN
`VIEW OF MASHITA, ONISHI, AND HIRAISHI ................................................ 4
`
`A. Mashita Describes Bluetooth Pairing, and also Describes Use of PIN and
`Bluetooth Address for Authentication and Data Encryption ................................ 4
`
`B. Hiraishi Does Not Teach Different Applications ........................................ 10
`
`C. Mashita Does Not Teach Away From Using HTTP to Upload the Image
`From the Mobile Phone to the Server................................................................ 14
`
`The Foley Declaration’s citations to Mashita’s Disadvantages Do Not
`1.
`Apply .......................................................................................................... 144
`
`2. Both FTP and HTTP used for Image Transfer....................................... 17
`
`D. Passkey and PIN ........................................................................................ 20
`
`E. Mashita Discloses The Supposedly Missing State Machine ....................... 21
`
`F. Onishi Discloses The GUI .......................................................................... 27
`
`i
`
`IPR2019-00131
`PANASONIC EX. 1024, p. 2 of 32
`
`
`
`
`
`I, Dr. John Strawn, declare as follows:
`
`I.
`
`BACKGROUND AND QUALIFICATIONS
`1.
`
`I am currently an independent consultant working under the aegis of
`
`my corporation S Systems Inc. My curriculum vitae, which includes a more detailed
`
`summary of my background, experience, and publications, was attached to the
`
`Petition as Exhibit 1002. My education and experience were discussed in my
`
`Declaration of October 30, 2018, Exhibit 1001 (“Strawn Declaration”). I incorporate
`
`the Strawn Declaration by reference into this declaration in its entirety, including
`
`exhibits.
`
`2.
`
`In this declaration, I have been asked by counsel for Panasonic to
`
`address certain topics raised by Dr. Michael Foley in his declaration, Exhibit 2009
`
`(“Foley Declaration”). I have not been asked to provide a point-by-point response
`
`to every issue raised by the Foley Declaration, and I do not attempt to do so here.
`
`This does not mean that I agree with Dr. Foley’s opinions on topics that I do not
`
`address; my omission of any topic from this declaration should not be interpreted
`
`that I agree with the Foley Declaration.
`
`II.
`
`INFORMATION PROVIDED TO ME
`3.
`
`In addition to the material listed in the Strawn Declaration, I have been
`
`asked to consider the following documents:
`
`1
`
`IPR2019-00131
`PANASONIC EX. 1024, p. 3 of 32
`
`
`
`
`
`• Cellspin’s Preliminary Response to the Petition (Paper 7) and the Exhibits to
`
`that Preliminary Response, Exhibits 2001-2008.
`
`• Cellspin’s Response to the Petition (Paper 19) and the Exhibits to that
`
`Response, Exhibits 2009-2023.
`
`• The transcript of my deposition taken on June 13, 2019 in this proceeding
`
`(“Strawn Deposition”).
`
`• The transcript of Dr. Foley’s deposition taken on September 19, 2019 in this
`
`proceeding (“Foley Deposition”).
`
`• The other documents identified in this Declaration.
`
`4. My opinion in the Strawn Declaration is unchanged, that is, all
`
`Challenged Claims are unpatentable as obvious over Mashita, Onishi, and Hiraishi.
`
`A more detailed reaffirmation of my opinion is given below.
`
`A. My Understanding of the Law Regarding Prior Art
`5. My understanding is outlined in the Strawn Declaration.
`
`III. CLAIM CONSTRUCTION
`A.
`“Cryptographically Authenticating Identity” Term
`6.
`
`The Foley Declaration points out an inconsistency in the wording of a
`
`proposed construction. Due to an oversight in editing, the noun “secrecy” was
`
`omitted from the text at the Strawn Declaration ¶60 [p. 34].
`
`2
`
`IPR2019-00131
`PANASONIC EX. 1024, p. 4 of 32
`
`
`
`
`
`7.
`
`The Foley Declaration is incorrect when the Foley Declaration states:
`
`“The difference is that Dr. Strawn does not agree with Panasonic that ‘some form of
`
`secrecy’ is sufficient.” [¶38, emphasis original]. I do not disagree with the
`
`construction in the Petition; the difference is again a typographical error. In
`
`understanding various forms of the words related to “cryptography,” I have always
`
`relied on the meaning of “secret” implied by the Greek root “crypt-.” My
`
`understanding is consistent with a POSITA’s understanding of the meaning of this
`
`term.
`
`8.
`
`Consistent with that understanding, the Strawn Declaration draws on
`
`the “secrecy” of the corrected proposed construction: “Thus, entering a secret PIN
`
`into both the camera and the cellular phone constitutes cryptographically
`
`authenticating.” [¶84].
`
`9. My opinion about obviousness is not changed by the fact that the Board
`
`adopted a construction without “secret” [Foley Declaration, ¶48]. As I noted
`
`throughout the Strawn Declaration, Mashita does authenticate the identity of the
`
`cellular phone by use of a shared passkey on the digital camera device and the
`
`cellular phone, matching the Board’s construction.
`
`
`
`3
`
`IPR2019-00131
`PANASONIC EX. 1024, p. 5 of 32
`
`
`
`
`
`IV. THE CHALLENGED CLAIMS WOULD HAVE BEEN OBVIOUS IN
`VIEW OF MASHITA, ONISHI, AND HIRAISHI
`10. As stated in the Strawn Declaration, it is my opinion that each and every
`
`limitation of the Challenged Claims is disclosed by the combination of Mashita,
`
`Onishi, and Hiraishi. Furthermore, it is my opinion that a person of ordinary skill in
`
`the art would have had many reasons to combine, supplement, and/or modify the
`
`teachings of Mashita, Onishi, and Hiraishi to create the systems claimed in the
`
`Challenged Claims. Additionally, because the combination of Mashita, Onishi, and
`
`Hiraishi to create the systems claimed in the Challenged Claims involves using well-
`
`known components and technologies, according to their established functions, with
`
`only minor modifications, a POSITA would have reasonably expected success.
`
`Accordingly, the Challenged Claims would have been obvious in view of Mashita,
`
`Onishi, and Hiraishi.
`
`11. The headings in this declaration are descriptive and not limiting.
`
`A. Mashita Describes Bluetooth Pairing, and also Describes Use of
`PIN and Bluetooth Address for Authentication and Data
`Encryption
`12. The Foley Declaration is incorrect when it states that Mashita discloses
`
`a PIN only for authentication and not pairing [Foley Declaration, e.g., ¶76, ¶104,
`
`¶105, ¶111]. Instead, Mashita’s use of a PIN discloses pairing, in particular
`
`establishing a short-range paired wireless connection between the digital camera
`
`device and the cellular phone, as I discussed in the Strawn Declaration: [¶76]. I
`
`4
`
`IPR2019-00131
`PANASONIC EX. 1024, p. 6 of 32
`
`
`
`
`
`based my understanding first on Mashita: “ ‘First, an identical Personal Identification
`
`Number (PIN) code is input to both the cellular phone 102 and the digital camera
`
`101, and the physical addresses 210 and 311 of both the cellular phone 102 and the
`
`digital camera 101 are used to execute an authentication process for local wireless
`
`connection.’ [Mashita, 0051]” [Strawn Declaration, ¶76]. Furthermore, I based my
`
`understanding on the definition of “paired device” in the Bluetooth Specification:
`
`“A Bluetooth device with which a link key has been exchanged (either before
`
`connection establishment was requested or during connecting phase.” [Exhibit
`
`2018, p. 92]. This definition, coupled with the overall description of pairing in the
`
`Bluetooth Specification, means that if a PIN has been successfully entered (for
`
`example by matching PIN codes), as Mashita discloses, then Bluetooth pairing
`
`occurs. I used this definition of “pairing” when I was analyzing Mashita.
`
`13. My understanding is confirmed for example in the Bluetooth
`
`Specification [Exhibit 2018, pp. 865-867; Figure 3.1, reproduced also Foley
`
`Declaration, ¶1011]. According to the Bluetooth Specification, if a PIN has been
`
`input to both devices, and the connection is successful (by matching the PIN codes),
`
`pairing has happened.
`
`
`1 The Foley Declaration citation to “page 691 of 906” in Exhibit 2018 means
`
`Exhibit 2018, p. 861.
`
`5
`
`IPR2019-00131
`PANASONIC EX. 1024, p. 7 of 32
`
`
`
`
`
`14.
`
`It is true that the Bluetooth Specification describes using a PIN input
`
`during pairing to generate a link key, and then describes incorporating that link key
`
`into authentication and steps that occur after pairing. The fact remains that Bluetooth
`
`pairing necessarily occurs in order for these subsequent steps to occur, contrary to
`
`the Foley Declaration.
`
`15. The PIN, entered by the user during Bluetooth pairing, is combined
`
`with the Bluetooth Device Address BD_ADDR during authentication, generating an
`
`“initialization key:” “When the initialization key is generated, the PIN is augmented
`
`with the BD_ADDR.” [Exhibit 2018, p. 1032]. The initialization key is then used
`
`to create a link key: “When both devices have calculated Kinit [the initialization key]
`
`the link key shall be created, and a mutual authentication is performed.” [Exhibit
`
`2018, p. 412 (emphasis added)]. The link key is generated using an algorithm called
`
`E22, with the PIN and BD_ADDR as inputs [ibid., p. 1032; pp. 1055-1057]. The
`
`output of algorithm E22 is the 128-bit link key [ibid., p. 1055]. For authentication,
`
`the link key is involved: “The link key itself is used in the authentication routine.”
`
`[ibid., p. 1029]. As the Bluetooth Specification states, the “key generating
`
`algorithm” exploits a “cryptographic function.” [ibid., p. 1056].
`
`16. As I outlined in the Strawn Declaration [¶83], this is exactly what
`
`happens in Mashita. The BD_ADDR of the Bluetooth Specification is the “physical
`
`address” of Mashita cited in the Strawn Declaration. The PIN of the Bluetooth
`
`6
`
`IPR2019-00131
`PANASONIC EX. 1024, p. 8 of 32
`
`
`
`
`
`Specification is the PIN of Mashita, and that PIN is used during Bluetooth pairing.
`
`Authentication in Bluetooth [e.g., Exhibit 2018, p. 1048 et seq.] is the “connection
`
`authentication” of Mashita [Strawn Declaration, ¶85].
`
`17. The Foley Declaration mischaracterizes the Bluetooth Specification
`
`illustration (Exhibit 2018, Figure 3.1) discussed above [Foley Declaration, ¶101].
`
`The figure does not show that pairing is optional in Bluetooth across the board. In
`
`the context of that figure (that is, when authentication is desired in Step 7b), pairing
`
`is optional in Step 7a only if pairing had been performed previously. The Bluetooth
`
`Specification confirms: “Step 7b: If a common link key exists between the devices,
`
`then pairing is not needed.” [Exhibit 2018, p. 867]. The common link key can be
`
`retained from a previous pairing generated using PIN input, so the pairing need not
`
`be repeated. This is the only meaning of “optional” in the figure cited in the Foley
`
`Declaration. To clarify, pairing explicitly happens if a PIN is exchanged, as in
`
`Mashita, and the link key required for authentication is then calculated from the PIN.
`
`Furthermore, if pairing happened previously and a link key derived from the PIN
`
`already exists, then the link key is simply provided and pairing need not be repeated
`
`this time.
`
`18.
`
` The Bluetooth Specification further clarifies that the use of PIN input
`
`confirms that pairing has happened. As I noted above, Mashita discloses that “an
`
`identical Personal Identification Number (PIN) code is input to both the cellular
`
`7
`
`IPR2019-00131
`PANASONIC EX. 1024, p. 9 of 32
`
`
`
`
`
`phone 102 and the digital camera 101.” [Mashita, 0051]. Step 7a discussed above is
`
`shown in more detail in another illustration in the Bluetooth Specification, in which
`
`the PIN input step is shown explicitly for both devices as “User Inputs PIN Code”
`
`[Exhibit 2018, p. 866], as disclosed in Mashita. The expanded illustration makes it
`
`clear that if a PIN is input by a user, the devices are performing “Step 7a: Pairing
`
`during connection establishment” in the words of the caption to the illustration [ibid.,
`
`p. 866]. Although this discussion refers to Version 2.1 + EDR, earlier versions of
`
`the Bluetooth Specification documents also described using a PIN input to establish
`
`a paired connection. I discussed this in Strawn Declaration with reference to Version
`
`2.0 + EDR. [Ex. 1001, ¶87, citing Ex. 1017, p. 251]. In addition, the Bluetooth
`
`Specification notes that using a 4-digit PIN for pairing was common for devices
`
`compliant with both Version 2.0 + EDR “and earlier versions.” [Ex. 2018, p. 131].
`
`19. The Foley Declaration provides no support for the following statement:
`
`“Further, even if Mashita did disclose cryptographically authenticating, a POSITA
`
`would understand that with Bluetooth, one may authenticate a device without
`
`pairing.” [Foley Declaration, ¶111, emphasis original]. This is not shown in the
`
`illustration [Exhibit 2018, Figure 3.1] reproduced in the Foley Declaration [¶101],
`
`or in any of the other portions of the Bluetooth Specification documents cited by Dr.
`
`Foley.
`
`8
`
`IPR2019-00131
`PANASONIC EX. 1024, p. 10 of 32
`
`
`
`
`
`20. The Foley Declaration repeatedly asserts that Bluetooth allows for a
`
`connection that is not paired [e.g., ¶101, 106, 110, 146] and uses this possibility to
`
`assert that the connection in Mashita is necessarily not paired. Whether the
`
`Bluetooth Specification allows for a viable connection without pairing is beside the
`
`point. Because Mashita discloses that a PIN is “input to both the cellular phone 102
`
`and the digital camera 101,” with both being Bluetooth devices, and because Mashita
`
`then discloses “an authentication process for local wireless connection,” a POSITA
`
`would understand that Mashita clearly discloses that Bluetooth pairing has in fact
`
`occurred, as I outlined above.
`
`21. The Foley Declaration fails to understand Mashita when it states:
`
`“Mashita doesn’t mention the concept of a link key, let alone the exchange of such
`
`a key.” [¶78, emphasis omitted]. I agree that Mashita does not mention a link key,
`
`but that is because a POSITA understands that calculating link key is a critical step
`
`in the PIN input-based pairing process and authentication, both of which Mashita
`
`describes. Mashita does not need to recite the details of every single step in the
`
`Bluetooth Specification in order for POSITA to understand that a link key is
`
`calculated, derived from the PIN. The fact that Mashita does not mention a link key
`
`has nothing to do with whether Mashita discloses a paired connection.
`
`22.
`
`It is important to distinguish between what happens in Bluetooth with
`
`the PIN during pairing and authentication, and what happens later when data is to be
`
`9
`
`IPR2019-00131
`PANASONIC EX. 1024, p. 11 of 32
`
`
`
`
`
`encrypted. The user input of a PIN generates a link key, as described above, which
`
`can be further incorporated into a later step in which actual data transferred between
`
`the camera and cellular phone, such as image data, is encrypted. This is the separate
`
`step 8 in the illustration (Exhibit 2018, Figure 3.1) reproduced in the Foley
`
`Declaration [¶101]. Encrypted communication in this sense can only follow
`
`authentication which, as I have shown, requires pairing: “If at least one
`
`authentication has been performed encryption may be used.” [Exhibit 2018, p. 418].
`
`As I discussed, the PIN is used to derive the authentication key, which in turn is used
`
`to derive an encryption key for data exchange: “The encryption key is derived from
`
`the authentication key [i.e., link key] during the authentication process.” [Exhibit
`
`2018, p. 1025, see also p. 1026 (noting that the authentication key “is often referred
`
`to as the link key”), p. 1034]. The Challenged Claims do not require encryption of
`
`data passed between camera and cellular phone, such as image data. Even if there
`
`were such a data encryption requirement, a POSITA would understand that the PIN,
`
`device address, pairing, and authentication disclosed in Mashita provide the
`
`prerequisites for such data encryption in Bluetooth.
`
`B. Hiraishi Does Not Teach Different Applications
`23.
`
`In Claim 5 of the ’698 Patent, “a mobile software application” is
`
`“configured to use HTTP to upload the received new-media file along with user
`
`10
`
`IPR2019-00131
`PANASONIC EX. 1024, p. 12 of 32
`
`
`
`
`
`information to a user media publishing website.” [see Strawn Declaration ¶167]. In
`
`my opinion Mashita with Hiraishi discloses this limitation [ibid., ¶¶120-125].
`
`24.
`
`I disagree with the Foley Declaration which sees one single application
`
`being required, and sees HTTP of Hiraishi as a separate application. In the view of
`
`the Foley Declaration, “[i]n the ’698 patent, a single application running on the
`
`cellular phone request images from the digital camera, receive and store said images,
`
`and then transfer the image along with other information via HTTP to a server.”
`
`[Foley Declaration, ¶152, emphasis added]. The Foley Declaration emphasizes that
`
`“[t]he use of a single mobile application was one of the enhancements introduced
`
`with the ’698 patent.” [ibid., ¶130, emphasis added]. This view is confirmed in the
`
`Foley Deposition [e.g., Exhibit 1023 “Foley Deposition”, 79:20-82:7].
`
`25.
`
`I am informed by counsel that as a matter of patent law, as a rule “a”
`
`when used in a patent claim is construed to mean “one or more.” 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.
`
`26. The Foley Declaration states that in Hiraishi, instead “a different
`
`application is utilized to upload the image from the cellular phone to the web site
`
`than that used to transfer the image from the digital camera to the cellular phone.”
`
`[Foley Declaration, ¶130, emphasis added].
`
`11
`
`IPR2019-00131
`PANASONIC EX. 1024, p. 13 of 32
`
`
`
`
`
`27. The ’698 patent teaches that the “Client Application 203” of FIG. 2
`
`consists of several modules, one of which can implement HTTP as one of several
`
`steps. My understanding of module is confirmed by the Foley Deposition [82:8-
`
`83:18].
`
`28.
`
`In the ’698 patent one such “module” is the DATA TRANSFER
`
`PROTOCOL MODULE 203c [’698 patent, FIG. 2] which is responsible for
`
`“implementing the protocol for data transfer.” [Foley Deposition, 83:14-18]. The
`
`protocol in the ’698 patent can be HTTP: “The transport protocol that is used
`
`between the client application 203 and the publishing service 401 may be hypertext
`
`transfer protocol (HTTP)” [’698 patent, 10:9-13]. The HTTP protocol is one of the
`
`steps inside the DATA TRANSFER PROTOCOL MODULE 203c; and a module
`
`can perform several steps such as HTTP: “But let’s be clear. One module could
`
`perform multiple of the steps.” [Foley Deposition, 84:2-7]. Thus, the ’698 patent
`
`teaches that the client application consists of several modules, and each module can
`
`perform several steps, one of which can be HTTP.
`
`29. To a POSITA, this modular programming approach would have been
`
`obvious in view of Mashita combined with Hiraishi. Hiraishi teaches that software
`
`can consist of modules [Strawn Declaration ¶124, citing Exhibit 1009 “Hiraishi”,
`
`0028 (referring to “photo sharing module 105” of the photo site]. Hiraishi teaches
`
`that “the selected image data is automatically transferred by the dedicated image
`
`12
`
`IPR2019-00131
`PANASONIC EX. 1024, p. 14 of 32
`
`
`
`
`
`uploading software.” [Hiraishi, 0026, cited in the Strawn Declaration ¶124, see also
`
`Hiraishi, 0023, cited ibid.]. A POSITA understands Hiraishi’s “dedicated image
`
`uploading software” is not necessarily referring to a separate application, but could
`
`be nothing more than a module in the overall “dedicated software installed in the
`
`PC” [Hiraishi 0017, cited in the Strawn Declaration ¶198]. In Hiraishi one part of
`
`the “dedicated image uploading software” is HTTP: “Then, the selected image data
`
`is automatically transferred by the dedicated image uploading software. In either
`
`case, transfer is executed based on a protocol available on the Internet 104, such as
`
`HTTP or FTP.” [Hiraishi, 0026, cited in the Strawn Declaration ¶124]. A POSITA
`
`understands that an HTTP implementation as described here is not a separate
`
`program; a module implements HTTP, or invokes HTTP like any other subroutine.
`
`30. Thus, even if the claim language required a single application, Mashita
`
`with Hiraishi discloses this limitation [Strawn Declaration, ¶¶120-125]. In any
`
`event, this limitation would have been obvious in view of the combination of
`
`Mashita and Hiraishi. As I noted above, Hiraishi expressly discloses the use of
`
`modular programming. This approach to programming was very well-known to
`
`those skilled in the art as of 2007. The benefits of this programming approach
`
`(versus implementing each different function in a separate application) were well-
`
`known to POSITAs, as exemplified by the use of modular programming dating back
`
`to Hiraishi (2002), years before the ’698 patent. A POSITA would have faced no
`
`13
`
`IPR2019-00131
`PANASONIC EX. 1024, p. 15 of 32
`
`
`
`
`
`particular difficulty in programming the Mashita and Hiraishi combination using a
`
`modular approach. To this end, I note that the ’698 patent specification discloses no
`
`details about how to program the client application 203a with different modules,
`
`implicitly indicating that the patent applicants considered such programming to be
`
`within the capabilities of a POSITA.
`
`C. MASHITA DOES NOT TEACH AWAY FROM USING HTTP
`TO UPLOAD THE IMAGE FROM THE MOBILE PHONE TO
`THE SERVER
`
`31.
`
` Claim 1 reads, “wherein the cellular phone is configured to use HTTP
`
`to upload the received new-media file along with user information to a user media
`
`publishing website.” There is similar language in claims 5, 8, and 13.
`
`1.
`
`THE FOLEY DECLARATION’S CITATIONS TO
`MASHITA’S DISADVANTAGES DO NOT APPLY
`32. The Foley Declaration states “Mashita teaches away from using HTTP
`
`in the digital camera or for image upload to a web site using a cellular phone” [¶149]
`
`and provides citations from Mashita as support [ibid.]. I do agree that Mashita
`
`describes disadvantages of some architectures
`
`that might place HTTP
`
`implementations into the digital camera, but Mashita is not teaching away from
`
`using HTTP in general. Furthermore, contrary to the Foley Declaration, Mashita
`
`does not teach away from using HTTP for image upload to a web site using a cellular
`
`phone.
`
`14
`
`IPR2019-00131
`PANASONIC EX. 1024, p. 16 of 32
`
`
`
`
`
`33. To address the passages cited in the Foley Declaration [¶149]: In
`
`Strawn Declaration, I explained how Mashita teaches inventions (including the two
`
`exemplary embodiments) that could be modified in view of other teachings from
`
`Onishi and Hiraishi to achieve the inventions claimed in the Challenged Claims (and
`
`why that modification would have been obvious to a POSITA). [see, e.g., Strawn
`
`Declaration ¶¶120-126]. The teachings of Mashita regarding its inventions, which I
`
`am relying upon in my obviousness opinion, do not have the digital camera utilize
`
`a “a built-in function such as a protocol, for example, PPP, TCP/IP, or HTTP
`
`included in the cellular phone to transfer data to the server on the Internet” [Mashita,
`
`0007] which Mashita believes would be a disadvantage. Instead, in Mashita it is the
`
`cellular phone itself that initiates the overall data transfer process resulting in the
`
`transfer of the photographs from the cellular phone to the web server [Strawn
`
`Declaration, ¶121].
`
` Thus, the digital camera is not utilizing an HTTP
`
`implementation included in the cellular phone to transfer data, and the disadvantage
`
`cited in the Foley Declaration does not apply.
`
`34.
`
`In Mashita’s invention the cellular phone does not include a
`
`preliminarily built-in application program for file data transfer. In Mashita’s
`
`invention the cellular phone also does not need to store a plurality of application
`
`programs compatible with the model of the digital camera. [Foley Declaration ¶88,
`
`see also Foley Declaration ¶91]. Instead, in Mashita’s invention there is one
`
`15
`
`IPR2019-00131
`PANASONIC EX. 1024, p. 17 of 32
`
`
`
`
`
`application program compatible with each model of a digital camera, and that
`
`application is not preliminarily built-in. [Mashita, 0045; Strawn Declaration ¶101].
`
`Thus, the disadvantage cited in the Foley Declaration does not apply. If anything,
`
`Mashita’s use of an application program downloaded from a server into a mobile
`
`device presages the modern concept of downloading apps from an app store.
`
`35. The Foley Declaration overreaches when it states: “Mashita is pointing
`
`out that the use of these protocols, including HTTP, requires more complexity,
`
`memory and greater cost for the cellular phone.” [Foley Declaration ¶88; similar text
`
`¶89]. Instead, Mashita points out that a certain architecture could require more
`
`complexity, memory and greater cost for the cellular phone, but this is not the
`
`architecture of Mashita’s invention.
`
`36.
`
`In Hiraishi it is again the cellular phone, not the camera, that initiates
`
`the use of HTTP. [Strawn Declaration, ¶124]. So Hiraishi does not disclose the
`
`architecture that Mashita supposedly teaches away from.
`
`37.
`
`In sum, the disadvantageous scenarios envisioned by Mashita and cited
`
`in the Foley Declaration are not relevant to the claims of the ’698 patent. The
`
`disadvantageous scenarios of Mashita cited in the Foley Declaration are not related
`
`to my opinion that the Challenged Claims are rendered obvious by Mashita in light
`
`of Onishi and Hiraishi.
`
`16
`
`IPR2019-00131
`PANASONIC EX. 1024, p. 18 of 32
`
`
`
`
`
`2.
`BOTH FTP AND HTTP USED FOR IMAGE TRANSFER
`38. The Foley Declaration overstates when it asserts: “Neither email not
`
`[sic] FTP are HTTP and nowhere within Machita [sic] is it taught that HTTP can be
`
`used for image transfer to the server.” [¶90]. For the second part of the assertion,
`
`as noted above, Mashita does in fact acknowledge that HTTP can be used for image
`
`transfer to a server, even if certain architectures bring certain disadvantages.
`
`39. As for the first clause, in the context of Mashita, there is no huge gulf
`
`between FTP and HTTP as the Foley Declaration implies. Having disclosed that
`
`HTTP can be used to transfer images, again Mashita goes on to discuss how FTP
`
`can likewise be used for image transfer [Strawn Declaration ¶37, ¶121]. Hiraishi
`
`even uses both FTP and HTTP in the same breath: “In either case, transfer is
`
`executed based on a protocol available on the Internet 104, such as HTTP or FTP.”
`
`[Hiraishi, 0026, cited in Strawn Declaration ¶124]. Hiraishi sees the two as
`
`interchangeable.
`
`40. HTTP and FTP are more closely related than might appear initially,
`
`and, as Hiraishi states, the choice is in many ways one of design, at the
`
`implementer’s discretion. As background, both are protocols, as indicated by “P” in
`
`the abbreviation: HTTP is the HyperText Transfer Protocol, and FTP is the File
`
`Transfer Protocol. Both are part of the larger set of protocols that form the Internet
`
`Protocol (“IP”) suite. The standards documents for the Internet Protocol suite are
`
`17
`
`IPR2019-00131
`PANASONIC EX. 1024, p. 19 of 32
`
`
`
`
`
`maintained by the IETF [www.ietf.org] and are known as “RFC” which stands for
`
`“request for comment.” The current “standard” for FTP is RFC 959.2 HTTP is well
`
`known to users of Internet browsers such as Internet Explorer, Bing, and Safari; the
`
`current standard is RFC 7230.3
`
`41. The protocols in the Internet Protocol suite are grouped into four layers,
`
`named (from the bottom) Link, Internet, Transport, and Application.4 Grouping
`
`networking protocols into layers is a well-established practice in networking. The
`
`canonical division for network layers is given by the Open Systems Interconnection
`
`model (OSI) standardized by the International Standards Organization (ISO)5. The
`
`Internet Protocol suite follows the example of the OSI in spirit. FTP is in the top-
`
`most, or application, layer of the Internet Protocol suite. HTTP is likewise at the
`
`top-most, or application, layer of the Internet Protocol suite. As such, both HTTP
`
`and FTP draw on the same lower transport layer, Internet layer, and link layer of the
`
`Internet Protocol suite. For example, both HTTP and FTP use TCP6, the
`
`
`2 https://tools.ietf.org/html/rfc959 [Exhibit 1026]
` https://tools.ietf.org/html/rfc7230 [Exhibit 1030]
` See, for example, https://tools.ietf.org/html/rfc1122.[Exhibit 1027]
` https://www.iso.org/standard/20269.html [Exhibit 1028]
`
` 3
`
` 4
`
` https://tools.ietf.org/html/rfc793 [Exhibit 1031]
`
`18
`
` 5
`
` 6
`
`IPR2019-00131
`PANASONIC EX. 1024, p. 20 of 32
`
`
`
`
`
`Transmission Control Protocol in the transport layer. Thus, it makes no sense to
`
`conclude that Mashita somehow drives a wedge between HTTP and FTP.
`
`42. HTTP is a well-established standard, going back to the very first
`
`implementation of the World Wide Web. FTP is even older; I first encountered the
`
`pre-Internet version when I arrived at Stanford in 1976, and used it extensively for
`
`my PhD. As such, both HTTP and FTP are widely understood by those who design
`
`and implement applications using the Internet. Again, it makes no sense to conclude
`
`that Mashita somehow drives a wedge between HTTP and FTP.
`
`43. Additionally, I note that Mashita discloses that the cellular phone
`
`includes a browser [Mashita, 0034]. I agree with Dr. Foley’s testimony at his
`
`deposition that browsers use HTTP [Foley Deposition, 17:24-18:1] and that HTTP
`
`is a protocol for wireless communication that could be used over any IP network,
`
`including public networks [Foley Deposition, 18:14-19].
`
`44. The Foley Declaration discusses size limits for attachments such as
`
`images for email systems [¶150], but the conclusion in the Foley Declaration
`
`regarding Mashita is not justified. Mashita discusses using both an email program
`
`and FTP to transfer images from the cellular phone to the server. As discussed in
`
`Strawn Declaration [¶37], Mashita's first embodiment [0015 - 0083] in general
`
`discusses email attachments [e.g., 0034, 0047, 0082, 0133, etc.], and FTP is also
`
`discussed [0082]; and Mashita's second embodiment [0084 - 0132] in general uses
`
`19
`
`IPR2019-00131
`PANASONIC EX. 1024, p. 21 of 32
`
`
`
`
`
`FTP [0082, 0089, 0102, 0107, etc.]. The Strawn Declaration [¶37] draws primarily
`
`from the first embodiment, which incorporates FTP [Mashita, 0082]; and it is clear
`
`that Mashita discloses FTP throughout the second embodiment. The Foley
`
`Declaration [¶150] does not discuss file size limitations for FTP in its discussion of
`
`Mashita. FTP has no known limitation on the size of files that may be transferred
`
`(see, e.g., RFC959 referenced above). Thus, contrary to the Foley Declaration,
`
`Mashita's use of FTP in both embodiments means that there is no file size limitation
`
`such as one that might be enforced by an email server. For this reason, the Foley
`
`Declaration's conclusion that “none of the combinations present overcome this
`
`limitation in a single mobile application” [¶150] is not supported.
`
`
`
`D.
`PASSKEY AND PIN
`45. The Foley Declaration draws a distinction between “passkey” and
`
`“PIN” [¶116] supposedly based on the Bluetooth Specification. Based on this
`
`supposed distinction, the Foley Declaration suggests that the PIN of Mashita does
`
`not meet the “passkey” of the Boa
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
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.
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.
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
