IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`
`Ex Parte Reexamination of
`
`U.S. Patent No. 8,352,730
`
`Inventor: John J. Giobbi
`
`Assignee: Proxense, LLC
`
`Control No. 90/015,052
`
`Issue Date: Jan. 8, 2013
`
`Confirmation No. 9657
`
`Art Unit: 3992
`
`Examiner: Tarae, Catherine Michelle
`
`Title: BIOMETRIC PERSONAL DATA KEY (PDK) AUTHENTICATION
`
`Mail Stop Ex Parte Reexam
`Attn: Central Reexamination Unit
`Commissioner for Patents
`United States Patent and Trademark Office
`P.O. Box 1450
`Alexandria, VA 22313-1450
`
`
`RESPONES UNDER 37 C.F.R. § 1.111
`
`
`
`
`
`Dear Commissioner:
`
`This Response is being filed in response to the Office Action mailed September 12, 2024,
`
`in regard to the above-identified proceedings.
`
`This Response contains the following sections:
`
`Notice of Prior or Concurrent Proceedings, beginning on page 2;
`
`Interview Summary, beginning on page 3; and
`
`Remarks, beginning on page 4.
`
`
`
`
`
`Patent Owner Exhibit 2020, Page 1 of 21
`
`

`

`Application No. 90/015,052
`Response under 37 C.F.R. § 111
`October 9, 2024
`
`NOTICE OF PRIOR OR CONCURRENT PROCEEDINGS
`
`Pursuant to 37 C.F.R. § 1565, Patent Owner informs the Office of the following prior and
`
`concurrent proceedings in which the Patent at issue is or has been involved.
`
`- Proxense, LLC v. Samsung Electronics, Co., Ltd. et al., No. 6.21-CV-00210 (W.D. Tex.
`
`March 5, 2021)
`
`- Proxense, LLC v. Google LLC, No. 6:23-cv-00320 (W.D. Tex. May 2, 2023)
`
`- Proxense, LLC v. Microsoft Corporation, No. 6.23-CV-00319 (W.D. Tex. May 2, 2023)
`
`- Proxense, LLC v. LG Electronics, Inc. et al, No. 6:24-cv-00302 (W.D. Tex. May 31,
`
`2024)
`
`- Proxense, LLC v. Apple, Inc, No. 6:24-cv-00143 (W.D. Tex. March 18, 2024)
`
`- Samsung Electronics American, Inc. v. Proxense, LLC, IPR2021-01444 (PTAB Aug. 26,
`
`2021)
`
`- Google LLC v. Proxense, LLC, IPR2024-00232 (PTAB Jan. 17, 2024)
`
`- Microsoft Corporation v. Proxense, LLC, IPR2024-00775 (PTAB April 19, 2024)
`
`- Microsoft Corporation. v. Proxense, LLC, IPR2024-01326 (PTAB Aug. 20, 2024)
`
`- Apple Inc. v. Proxense LLC, IPR2024-013333 (PTAB Aug. 20, 2024)
`
`
`
`
`
`Patent Owner Exhibit 2020, Page 2 of 21
`
`

`

`INTERVIEW SUMMARY
`
`Patent Owner thanks the Office for Interview held October 3, 20224.
`
`The Interview was conducted on behalf of the Office by Reexamination Specialist C.
`
`Michelle Tarae, Examiner Jeffery D. Carlson, and Supervisory Patent Reexamination Specialist
`
`Andrew J. Fischer.
`
`During the Interview, Patent Owner was represented by their counsel, James A. Zak and
`
`David Hecht.
`
`During the Interview, the construction of “third-party trusted authority” was discussed
`
`with regards to the explicit language of the claims. In particular, Patent Owner noted the claims
`
`recite a transaction between a user and an application, and thus require the “third-party trusted
`
`authority” be a third with respect to a user and application.
`
`Additionally, it was discussed why Ludtke (U.S. Patent No. 7,188,110) fails to disclose a
`
`“third-party trusted authority” because the Ludtke’s Transaction Privacy Clearing House (TPCH)
`
`is: 1) not an entity other than the principals involved in the transaction of accessing an
`
`application, but rather is the application being accessed; and 2) does not send access message
`
`allowing the user access to an application.
`
`Finally, during the Interview Patent Owner noted that the structure for the “authentication
`
`unit” is fully recited (i.e., manifested) in claim 15.
`
`At the end of the Interview, Reexamination Specialist Tarae stated the points and
`
`arguments raised by the Patent Owner would be considered if formally presented in a Response,
`
`which Patent Owner has done with the filing of this response.
`
`
`
`
`
`
`
`
`
` 3
`
`Patent Owner Exhibit 2020, Page 3 of 21
`
`

`

`REMARKS
`
`Claim Interpretation
`
`I.
`
`Third-Party Trusted Authority Required to be a third-party with Respect to User
`and an Application
`
`The Rejections under 35 U.S.C § 103 are based on the premise that “Ludtke illustrate
`
`‘Commerce General Architecture’ in which a consumer and vendor are the principals involved in
`
`a transaction. The transaction privacy clearing house (TPCH) is the one other than the principals
`
`involved in the transaction.” Office Action mailed September 12, 2024, page 30. The Office
`
`Action has thus construed the term “third-party trusted authority” as a third-party with respect to
`
`a user and merchant. However, express language of the independent claims 1, 8, 12, and 15 does
`
`not permit the recited “third-party trusted authority” to be a third-party with respect to a transaction
`
`between a merchant and user. Rather, the express language of the claims requires the “third-party
`
`trusted authority” to be third party with resect to a user and application being accessed.
`
`While the specification may detail such embodiments, it also details embodiments, such as
`
`shown in FIG. 7, in which the parties to the transaction are the user and the application. See Google
`
`LLC, v. Proxense, LLC, IPR2024-00232, Paper 10 at 11 (PTAB July 23, 2024) (“Fig. 7. Although
`
`the trusted key authority in this example is not a principal party to the transaction (here, the parties
`
`are the user and the application), it is an active participant in facilitating the transaction.”)
`
`(emphasis added). The claims are directed solely to such embodiments.
`
`Claims 1 and 15 each recite “receiving an access message from the agent allowing the user
`
`access to an application.” Similarly, claim 8 recites “receives an access message from the agent
`
`allowing the user access to an application.” Likewise, claim 12 recites “receiving an access
`
`message from the agent; and in response to a positive access message, allowing the biometrically
`
`verified user access to an application.” The independent claims of the 730 Patent each recite three
`
` 4
`
`Patent Owner Exhibit 2020, Page 4 of 21
`
`

`

`participants: the user; the third-party trusted authority; and the application the user is allowed to
`
`access. The Office Action asserts the proper interpretation of a “third-party trusted authority” is
`
`“One other than the principals involved in a transaction” Office Action Mailed September 12,
`
`2025, page 5. The PTAB, on multiple occasions, has similarly interpreted third-party trusted
`
`authority to mean “a trusted authority that is an entity separate from the parties to a transaction.”
`
`IPR2024-00232, Paper 10 at 12 (“Accordingly, we adopt the Samsung DDI’s construction without
`
`Patent Owner’s modifications. On the current record, a ‘third-party trusted authority’ is ‘a trusted
`
`authority that is an entity separate from the parties to a transaction.”). The third-party trusted
`
`authority, therefore, is not a party or principal to the transaction. This only leaves the user and the
`
`application the user is allowed to access as the parties to the transactions. Thus, the claims
`
`explicitly require the parties to the transaction be the user and the application, and that the
`
`transaction is the user gaining access to the application. The “third-party trusted authority,”
`
`therefore, is required by the express language of the claims to be a third-party with respect to the
`
`user and the application being accessed.
`
`Should there be any doubt, that a transaction in which the parties are a merchant and user
`
`is excluded by the explicit language of the claims, with referenced to Fig. 7 of the Patent, the PTAB
`
`observed “Although the trusted key authority in this example is not a principal party to the
`
`transaction (here, the parties are the user and the application), it is an active participant in
`
`facilitating the transaction.” IPR2024-00232, Paper 10 at 11 (PTAB July 23, 2024) (emphasis
`
`added). As shown by the below table, independent claims 1, 8, 12 and 15 directly map to FIG. 7.
`
` 5
`
`Patent Owner Exhibit 2020, Page 5 of 21
`
`

`

`Wirelessly Receive The Code
`710
`
`RequestAuthentication
`Of The Code
`720
`
`Code Authenticated?
`730
`
`
`
`
`
`
`
`
`
`Send Access Message To The Application
`
`Authentication
`Failed
`750
`
`FIG.7
`
`
`
`
`
`
`
`
`
` 6
`
`Patent Owner Exhibit 2020, Page 6 of 21
`
`Patent Owner Exhibit 2020, Page 6 of 21
`
`

`

`
`
`FIG. 7
`710 – Wirelessly
`Receive the Code
`
`720 – Request
`Authentication of
`the Code
`
`Claim 1
`“persistently storing
`biometric data of
`the user and a
`plurality of codes
`and other data
`values … in a
`tamper proof format
`written to a storage
`element”
`
`Code thus received
`from storage
`element
`“sending one or
`more codes from
`the plurality of
`codes and the other
`data values for
`authentication by an
`agent that is a third-
`party trusted
`authority”
`
`Claim 8
`“a memory stores
`biometric data of a
`user and a plurality
`of codes and other
`data values … a
`verification unit, in
`communication with
`the memory”
`
`Code thus received
`from memory
`
`“sends one or more
`codes from the
`plurality of codes
`and the other data
`values for
`authentication by an
`agent that is a third-
`party trusted
`authority”
`
`730 – Code
`Authenticated? Yes /
`No
`
`740 – Send Access
`Message to the
`Application
`
`“responsive to
`authentication of
`the one or more
`codes … receiving
`an access message
`from the agent”
`“an access message
`from the agent
`allowing the user
`access to an
`application”
`
`“responsive to the
`agent authenticating
`the one or more
`codes … receives an
`access message from
`the agent”
`“an access message
`from the agent
`allowing the user
`access to an
`application”
`
`
`
`Claim 12
`“receiving one or
`more codes from a
`plurality of codes
`and other data
`values”
`
`Claim 15
`“receives the
`plurality of codes
`and the other data
`values”
`
`“requesting
`authentication of
`the one or more
`codes and the other
`data values by the
`agent”
`
`Note: in previous
`limitation is stated
`“an agent that is a
`third-party trusted
`authority”
`
`“receiving an
`access message
`from the agent; and
`in response to a
`positive access
`message”
`“in response to a
`positive access
`message, allowing
`the biometrically
`verified user access
`to an application,”
`
`“send the plurality
`of codes and the
`other data values to
`agent for
`authentication to
`deter mine whether
`the one or more
`codes and the other
`data values are
`legitimate, wherein
`the agent is a third-
`party trusted
`authority”
`“responsive to the
`device ID code
`being authenticated
`… receiving an
`access message
`from the agent”
`“an access message
`from the agent
`allowing the user to
`access an
`application”
`
`As all the independent claims directly map to an embodiment in which the parties to the
`
`transaction are the user and the application, the claims of the patent expressly require the parties
`
`to the transaction be the user and the application, and that the transaction is the user gaining access
`
`to the application. The “third-party trusted authority,” therefore, is expressly required to be a third-
`
`party with respect to the user and the application being accessed.
`
` 7
`
`Patent Owner Exhibit 2020, Page 7 of 21
`
`

`

` By their express language, or when read considering the specification, the claims of the
`
`patent are explicitly limited to instances in which the third-party trusted authority is a third party
`
`with respect to a user and an application, and in which the transaction is accessing the application
`
`by the user. The claims, therefore, expressly require the third-party trusted authority be an entity
`
`of than the application being accessed.
`
`
`
`II.
`
`35 U.S.C. § 112, Sixth Paragraph, Does not Apply to Claims 8 and 15
`
`In Claim 8: The Algorithm for a “Verification Unit” Is Fully Defined in the Claim
`
`The Office Action asserts on page 7 that the term “verification unit” invokes 35 U.S.C. §
`
`112, sixth paragraph, and the corresponding structure/algorithm is disclosed in column 4, lines 13-
`
`23, and FIG. 2. Patent Owner recognizes that term “unit” can be indicative of an intention to
`
`invoke § 112, sixth paragraph, but that is not the case here. The algorithm is fully manifested in
`
`the claim 8, as well as the other independent claims of the patent.
`
`As an initial matter, Patent Owner believes the algorithm is presented in FIG. 6, which the
`
`730 Patent describes as “illustrating a method for verifying a subject presenting the biometric key
`
`according to one embodiment of the present invention.” 730 Patent, 2:51-53; see also 6:65-67
`
`(“FIG. 6 is a flow chart illustrating a method 600 for verifying a subject presenting the biometric
`
`key according to one embodiment of the present invention.”). The following discussion of FIG. 6
`
`is provided in specification:
`
`“FIG. 6 is a flow chart illustrating a method 600 for verifying a Subject presenting
`the biometric key according to one embodiment of the present invention. In
`response to an authentication request, a user scan is requested 610 (e.g., by a
`blinking LED). Once the Subject provides a fingerprint, Scan data is received 620.
`Scan data is compared for a match 630 to previously-stored biometric data. If there
`is no match, then verification fails 650.
`
` 8
`
`Patent Owner Exhibit 2020, Page 8 of 21
`
`

`

`If there is a match, the subject is verified 640 as the user. The code indicating a
`Successful verification is wirelessly sent 650 from the biometric key (e.g., by RF
`communication module 230).” 730 Patent, 6:65-7:9
`
`Accordingly, the algorithm for a verification unit is presented in FIG. 6 and the
`
`accompanying discussion within the specification. As shown in the below tables, both FIG. 6
`
`and the accompanying discussion are fully manifested in claim 8 and the other independent
`
`Claim 1
`receiving scan data
`from a biometric
`Scan
`
`Claim 8
`receives scan data
`from a biometric
`scan
`
`Claim 12
`a biometrically
`verified user,
`
`Claim 15
`if scan data can be
`verified as being
`from the use
`
`claims.
`
`6:65-7:9
`“Once the Subject
`provides a
`fingerprint, Scan data
`is received 620.” 7:2-
`3
`“scan data is
`compared for a
`match 630 to
`previously-stored
`biometric data.” 7:3-
`4
`“If there is a match,
`the subject is verified
`640 as the user. The
`code indicating a
`successful
`verification is
`wirelessly sent 650
`from the biometric
`key (e.g., by RF
`communication
`module 230).” 7:6-9
`
`comparing the scan
`data to the biometric
`data to determine
`whether the scan
`data matches the
`biometric data
`“sending one or
`more codes from the
`plurality of codes
`and the other data
`values for
`authentication by an
`agent that is a third-
`party trusted
`authority”
`
`for comparison
`against the biometric
`data
`
`“sends one or more
`codes from the
`plurality of codes
`and the other data
`values for
`authentication by an
`agent that is a third-
`party trusted
`authority”
`
`by comparing the
`scan data to the
`biometric data
`
`“requesting
`authentication of
`the one or more
`codes and the
`other data values
`by the agent”
`
`Note: in previous
`limitation is stated
`“an agent that is a
`third-party trusted
`authority”
`
`“send the plurality
`of codes and the
`other data values
`to agent for
`authentication to
`deter mine whether
`the one or more
`codes and the
`other data values
`are legitimate,
`wherein the agent
`is a third-party
`trusted authority”
`
`
`
`
`
`
` 9
`
`Patent Owner Exhibit 2020, Page 9 of 21
`
`

`

`
`
`
`
`FIG. 6
`“Receive Scan Data
`From a Subject 620”
`
`“Scan Data Match
`Biometric Data?
`630”
`
`“Subject Is Verified
`As The Registered
`User 640”
`“Wirelessly Send
`Code Indicating
`Successful
`Verification of User
`650”
`
`Claim 1
`receiving scan data
`from a biometric
`Scan
`comparing the scan
`data to the biometric
`data to determine
`whether the scan
`data matches the
`biometric data
`
`“sending one or
`more codes from the
`plurality of codes
`and the other data
`values for
`authentication by an
`agent that is a third-
`party trusted
`authority”
`
`Claim 12
`a biometrically
`verified user,
`
`Claim 8
`receives scan data
`from a biometric
`scan
`for comparison
`against the biometric
`data
`
`Claim 15
`if scan data can be
`verified as being
`from the use
`by comparing the
`scan data to the
`biometric data
`
`“sends one or more
`codes from the
`plurality of codes
`and the other data
`values for
`authentication by an
`agent that is a third-
`party trusted
`authority”
`
`“requesting
`authentication of
`the one or more
`codes and the
`other data values
`by the agent”
`
`Note: in previous
`limitation is stated
`“an agent that is a
`third-party trusted
`authority”
`
`“send the plurality
`of codes and the
`other data values
`to agent for
`authentication to
`deter mine whether
`the one or more
`codes and the
`other data values
`are legitimate,
`wherein the agent
`is a third-party
`trusted authority”
`
`In Claim 15: The Algorithm for an “Authentication Unit” Is Fully Defined in the Claim
`
`The Office Action asserts on pages 7-8 that the term “authentication unit” invokes 35
`
`U.S.C. § 112, sixth paragraph, and the corresponding structure/algorithm is disclosed in column 5,
`
`lines 8-6, and FIG. 3. Patent Owner recognizes that term “unit” can be indicative of an intention
`
`to invoke § 112, sixth paragraph, but that is not the case here. The algorithm is fully manifested
`
`in the claim 15, as well as the other independent claims of the patent. As the below table shows,
`
`the language from the specification identified by the Office Action as corresponding to the
`
`“authentication unit” maps to each independent claim of the patent.
`
`
`
`
`
` 10
`
`Patent Owner Exhibit 2020, Page 10 of 21
`
`

`

`Claim 12
`“receiving one or
`more codes from a
`plurality of codes
`and other data
`values”
`
`Claim 15
`“receives the
`plurality of codes
`and the other data
`values”
`
`“requesting
`authentication of
`the one or more
`codes and the
`other data values
`by the agent”
`
`Note: in previous
`limitation is stated
`“an agent that is a
`third-party trusted
`authority”
`
`“send the plurality
`of codes and the
`other data values
`to agent for
`authentication to
`deter mine whether
`the one or more
`codes and the
`other data values
`are legitimate,
`wherein the agent
`is a third-party
`trusted authority”
`“responsive to the
`device ID code
`being
`authenticated …
`receiving an access
`message from the
`agent”
`“an access
`message from the
`agent allowing the
`user to access an
`application”
`
`
`
`5:8-26
`“Authentication
`module 310 is
`coupled in
`communication with
`biometric key via
`line 311 (i.e., a
`wireless medium
`such as EM
`signals).” 5:8-10
`
`“[A]uthentication
`module 310 provides
`the code to trusted
`key authority 320 in
`order to verify that it
`belongs to a
`legitimate key.”
`5:20-22
`
`Claim 1
`“persistently storing
`biometric data of the
`user and a plurality
`of codes and other
`data values … in a
`tamper proof format
`written to a storage
`element”
`
`Code received from
`communicatively
`coupled storage
`element
`“sending one or
`more codes from the
`plurality of codes
`and the other data
`values for
`authentication by an
`agent that is a third-
`party trusted
`authority”
`
`Claim 8
`“a memory stores
`biometric data of a
`user and a plurality
`of codes and other
`data values … a
`verification unit, in
`communication with
`the memory”
`
`Code received from
`communicatively
`coupled memory
`
`“sends one or more
`codes from the
`plurality of codes
`and the other data
`values for
`authentication by an
`agent that is a third-
`party trusted
`authority”
`
`“[R]esponsive to a
`successful
`authentication by
`trusted key authority
`320.” 5:25-26
`
`“responsive to
`authentication of the
`one or more codes
`… receiving an
`access message from
`the agent”
`
`“responsive to the
`agent authenticating
`the one or more
`codes … receives an
`access message from
`the agent”
`
`“receiving an
`access message
`from the agent;
`and in response to
`a positive access
`message”
`
`“an access message
`from the agent
`allowing the user
`access to an
`application”
`
`“an access message
`from the agent
`allowing the user
`access to an
`application”
`
`“in response to a
`positive access
`message, allowing
`the biometrically
`verified user
`access to an
`application,”
`
`“Authentication
`module 310 can send
`a message to
`application 330, or
`otherwise allow
`access to the
`application,
`responsive to a
`successful
`authentication by
`trusted key authority
`320.” 5:23-26
`
`
`
`Every independent claim of the patent recites the function of authentication unit / module
`
`(310) sending a code to a trusted key authority (320) for verification and allowing access to an
`
` 11
`
`Patent Owner Exhibit 2020, Page 11 of 21
`
`

`

`application (330) in response to successful authentication of the code by the trusted key authority
`
`(320). Furthermore, each of the independent claims recite some form of biometric verification by
`
`a biometric key (100). Thus, all the independent claims correspond to the embodiment of FIG. 3,
`
`which depicts a system “for providing authentication information for a biometrically verified user”
`
`that includes an application (330) and a trusted key authority (320).
`
`It is further noted that FIG. 7, which the PTAB observes present an embodiment in which
`
`the principal parties are the user and the application, maps to the “structure/algorithm in the
`
`specification” that the Office Action identifies as corresponding to the “authentication unit” of
`
`claim 15, as shown by the below figure.
`
`As FIG. 7 maps to the portions of the specification the Office Action has identified as
`
`disclosing the algorithm for an “authentication unit, table presented above with regards to FIG. 7
`
`further evidences the algorithm for the “authentication unit” is full manifested in the claim 15 and
`
`all the other independent claims.
`
`
`
` 12
`
`Patent Owner Exhibit 2020, Page 12 of 21
`
`

`

`Claim Rejection – 35 U.S.C. § 103
`
`Claims 1, 2, 4-9, 11, 12, and 14-17 are rejected under 35 U.S.C. § 103 for allegedly being
`
`rendered obvious by Ludtke (U.S. Patent No. 7,188,110) in view of Okereke (U.S. Publication No.
`
`2003/019608).
`
`Claims 3, 10 and 13 are rejected under 35 U.S.C. § 103 for allegedly being rendered
`
`obvious by Ludtke (U.S. Patent No. 7,188,110) in view of Okereke (U.S. Publication No.
`
`2003/019608) and Robinson (U.S. Publication No. 2003/0177102).
`
`Patent Owner respectfully traverses the rejections to they extent they are maintained in
`
`view of the following remarks.
`
`
`
`I.
`
`Ludtke’s Transaction Privacy Clearing House (TPCH) is Not a Third-Party Trusted
`Authority
`
`Independent claims 1, 8, 12, and 15 each recite the recite a “third-party trusted authority,”
`
`The Office Action mailed September 12, 2024, equates the recited “third-party trusted authority
`
`with Ludtke’s Transaction Privacy Clearing House (TPCH). To qualify as a “third-party trusted
`
`authority” Ludtke’s Transaction Privacy Clearing House (TPCH) must:
`
`1) Send an access message allowing the user access to an application; and
`
`2) Be an entity other than the principals involved in the transaction of accessing the
`
`application – i.e., not be the application being accessed.
`
`Ludtke’s TPCH fails both requirements.
`
`
`
`
`
`
`
` 13
`
`Patent Owner Exhibit 2020, Page 13 of 21
`
`

`

`The Transaction Privacy Clearing House (TPCH) Is the Application Being Accessed
`
`Ludtkes transaction privacy clearinghouse (TPCH) is being accessed to perform the
`
`accepted function of a clearing house. A clearing house is “An office where banks exchange
`
`checks and drafts and settle accounts.” American Heritage Dictionary Entry: clearinghouse
`
`(ahdictionary.com),
`
`https://ahdictionary.com/word/search.html?q=clearinghouse
`
`(emphasis
`
`added). Likewise, the Cambridge English Dictionary defines a clearing house as “a central office
`
`used by banks to collect and send out money and checks.” CLEARING HOUSE definition |
`
`Cambridge English Dictionary, https://dictionary.cambridge.org/us/dictionary/english/clearing-
`
`house. Similarly, Merriam-Webster defines a clearinghouse as “an establishment maintained by
`
`banks for settling mutual claims and accounts.” Clearinghouse Definition & Meaning - Merriam-
`
`Webster,
`
`https://www.merriam-webster.com/dictionary/clearinghouse
`
`(emphasis
`
`added).
`
`Accordingly, a clearinghouse’s accepted function is to perform settlement by transferring money.
`
`In accordance with the accepted function of a clearing house, Ludtke states, “The TPCH settles
`
`funds, transferring the appropriate amount into the vendor's account.” Ludtke, 27:66-67.
`
`Furthermore, Ludtke states, “The settlement of funds involves the transfer of the appropriate
`
`financial credit into the vendor's account.” Ludtke, 29:35-36. Ludtke further notes, that the core
`
`functionality of the TPCH is “financial settlement and allocation of payments to internal and
`
`external accounts”. Specifically, Ludtke states, “The TPCH agent 615 handles system
`
`management and policy control, and forms the core functionality of the TPCH 600… Among the
`
`responsibilities handled by the agent include internal system management functions such as data
`
`mining, financial settlement and allocation of payments to internal and external accounts, and
`
`registration of new users joining the system.” Ludtke, 9:43-51 (emphasis added). Accordingly,
`
`the TPCH is accessed by the user to perform the accepted function of a clearing house by
`
` 14
`
`Patent Owner Exhibit 2020, Page 14 of 21
`
`

`

`transferring money from the user’s account to the vendor’s accounts and is therefore the
`
`application being accessed.
`
`
`
`Ludtke teaches that settlement is carried out by the TPCH issuing transaction
`
`authorizations to a financial processing system (FP) 140. Specifically, Ludtke discloses:
`
`“In one embodiment, the financial processing system (FP) 140 performs tasks of
`transferring funds between the user's account and the vendor's account for each
`transaction… The TPCH 110 issues transaction authorizations to the FP140
`function on an anonymous basis on behalf of the user over a highly secure channel.”
`
`Ludtke, 6:65-7:6. By “issu[ing] transactions authorizations to the FP 140 function” the TPCH is
`
`directing FP 140 to perform the transfer indicated in the authorization. Of course, before the TPCH
`
`can direct FP 140 to perform the transfer, it needs to collect certain information to be able to
`
`formulate a transaction authorization indicating how much to transfer, from what account, and into
`
`which account. Ludtke states that this information is provided to the TPCH by a POS terminal.
`
`“The POS terminal may collect the necessary information from the transaction
`device, e.g., the digital wallet, combine it with the purchase data, and send it to the
`TPCH. The TPCH may then authorize the transaction, store data relevant to the
`transaction in its records and trigger a financial transfer to the vendor's account.
`The POS terminal may then receive verification that the transaction is complete,
`and transfer the wireless receipt to the transaction device.”
`
`Ludtke, 23:50-57 (emphasis added).
`
`The TPCH is thus receiving data from the POS and using that data to formulate a
`
`transaction authorization directing the FP to make requested transfer from the user’s account to the
`
`vendor’s account. Thus, Ludtke’s transaction privacy clearing house is the application being
`
`accessed by the user to settle the transaction by causing the appropriate amount to be transferred
`
`from the user’s account to the vendor’s account.
`
` 15
`
`Patent Owner Exhibit 2020, Page 15 of 21
`
`

`

`Ludtke discloses four ways in which the TPCH performs settlement when accessed by the
`
`user. The simplest settlement method disclosed by Ludtke is one in which “the account is managed
`
`completely by the TPCH, and thus the funds transfer is handled completely inside of the TPCH.”
`
`Ludtke, 29:37-39. With this method of settlement, the TPCH simply directs the transfer of funds
`
`from an account held by the TPCH to the vendor’s account.
`
`In the next settlement method disclosed, “the TPCH 110 interfaces to at least one financial
`
`processing system 140 to perform associated financial transactions, such as confirming sufficient
`
`funds to perform the transaction, and transfers to the vendor 125 the fees required to complete
`
`the transaction.” Ludtke, 6:51-55 (emphasis added). In this method the TPCH issues credit to
`
`the user based on the availability of funds in an account registered with the TPCH, and then directs
`
`the transfer of funds from an account held by the TPCH to the vendor’s account. At some point in
`
`time, the user would have to reimburse the TPCH.
`
`The third settlement process disclosed is one in which “the TPCH may issue a funds
`
`settlement request to a third-party financial institution on behalf of the user, causing the necessary
`
`funds to be transferred to the vendor from the user’s account.” Ludtke, 29:43-46. Here, the TPCH
`
`is accessed to provide access to the user’s account. In this instance, however, the transaction
`
`authorization issued by the TPCH would direct the transfer of funds from an account of the user
`
`to the vendor’s account.
`
`The final settlement process disclosed by Ludtke is one in which the TPCH directly charges
`
`an account registered with the TPCH. “[T]he FP140 is contacted by the TPCH requesting a generic
`
`credit approval of a particular account… The TPCH 110 can request the credit using a dummy
`
`charge ID that can be listed in the monthly credit statement sent to the user, so that the user can
`
`reconcile his credit statement.” Ludtke, 7:12-20; accord Ludtke, 29:46-51 (“In yet another
`
` 16
`
`Patent Owner Exhibit 2020, Page 16 of 21
`
`

`

`alternative embodiment, the TPCH may act as a proxy for the user, whereby the TPCH takes the
`
`funds from the user's account as managed by a third party financial institution, and then issues a
`
`funds transfer from the TPCH account to the vendor's account.”). In this process, the TPCH
`
`provides access to a registered account to issue the “dummy charge,” collecting funds from the
`
`user’s account, and transferring funds to the vendor. Accordingly, the transaction authorization
`
`issued by the TPCH directs the transfer of funds from an account held by the TPCH to the vendor’s
`
`account.
`
`In all the foregoing settlement methods, the TPCH is performing the established function
`
`of a clearing house, thereby making the TPCH the application being accessed by the user to settle
`
`the transaction by causing the appropriate amount to be transferred from the user’s account to the
`
`vendor’s account.
`
`
`
`The Transaction Privacy Clearing House (TPCH) Does Not Send an Access Message Allowing
`the User to Access an Application
`
`Independent claims 1, 8, 12, and 15 each recite in response to authentication of a device
`
`ID code by the thirding party trusted authority, receiving an access message from the third-party
`
`trusted authority allowing the user access to an application. Ludtke fails to disclose its transaction
`
`privacy clearing house (TPCH) sends such a message in response to authenticating a device ID
`
`code.
`
`The Office Action fails to identify an access message. The Office Action does identify
`
`various functions on the digital wallet as the “applications”. However, Ludtke does not detail the
`
`TPCH sends an access message allowing the user to access functionality of the digital wallet after
`
`the TPCH successfully authenticates device ID codes sent to the TPCH.
`
` 17
`
`Patent Owner Exhibit 2020, Page 17 of 21
`
`

`

`Assuming, solely for the sake of discussion, the Office Actions was intended to identify
`
`the confirmation returned from the TPCH to the point-of-sale device (POS) as the access message,
`
`the conformation sent from the TPCH to the POS does not enable an application.
`
`The confirmation sent from the TPCH to the POS does not allow access to the POS because
`
`the POS is the used to access the TPCH. As described in Ludtke, “the POS terminal may collect
`
`the necessary information from the transaction device, e.g., digital wallet, combine it with the
`
`purchase data, and send it to the TPCH. The TPCH may then authorize the transaction, store data
`
`relevant to the transaction in its records and trigger a financial transfer to the vendor’s account.”
`
`Ludtke, 23:50-55; see also id., 21:51-57 (“In one embodiment, a POS terminal is the link between
`
`the digital wallet or privacy card and the transaction privacy clearinghouse (TPCH) of the
`
`eCommerce system. The main purpose of the POS terminal is to establish a secure transaction
`
`connection between the transaction device and the TPCH and to transfer transaction data to the
`
`TPCH for completion of the transaction.”). A similar process for web transactions is shown in
`
`Figu