DETAILED ACTION
This is a final office action on the merits. The U.S. Patent and Trademark Office (the Office) has received claims 1 – 49 in application 18/244,721.
Claims 21–49 were cancelled in “Preliminary Amendments” filed on 11/20/2023.
Claims 1 and 11 are amended.
Claims 1-20 are pending and have been examined on the merits.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
35 USC 103
“Token service separate from the computing device”
Applicant asserts the Office Action mapped the “token service” to secure element 122, but Sheets shows secure element 122 is part of the mobile device, so it cannot be “separate from the computing device.”
The rejection does not require “token service” to be mapped to secure element 122. Under the broadest reasonable interpretation, the claimed “token service” reads on a remote network service that issues/manages payment tokens and participates in token processing, such as Sheets’ token registry/payment processing network/third party server system, all of which are separate from the computing device.
Sheets teaches a token registry (remote) issuing tokens to a mobile device (The token registry 1061…where tokens may be issued to a mobile device 1020…processed using tokens instead of primary account numbers/identifiers (PANs) (¶ 0189).
Sheets also teaches remote entities (not on the mobile device) that decrypt/process tokenized payment information, including a third party system (the mobile payment application 1023 sends the encrypted token and the transaction public key to third party server system (¶ 0227). the third party server system decrypts the encrypted payment token. In some embodiments, the payment token may be decrypted using the transaction public key, the server private key, the key derivation function, the elliptic curve and the generator function, and the received encrypted payment token. The decrypted payment token may then be processed by third party server system (¶ 0228)).
Sheets also teaches a payment processing network 160/mobile gateway 190 architecture where sensitive data is securely exchanged between the mobile device and a server computer/network entity, i.e., “separate from the computing device” (sensitive data may be securely shared between the mobile device 120 and the mobile gateway server computer (¶ 0149).
Amended claim 1(a): token service generates inbound predecessor token by digitally signing inbound predecessor data…ephemeral public key provided by computing device.
Sheets teaches the “ephemeral public key” is provided/generated by the computing device. Sheets further teaches that the mobile payment application (on the device) generates a random ephemeral EC key pair, including a transaction public key, and provides it outward (the mobile payment application 1023 generates a random ephemeral elliptic curve (EC) key pair associated with a payment transaction (¶ 0225). mobile payment application 1023 sends the encrypted token and the transaction public key to third party server system (¶ 02227)).
Sheets teaches cryptographic signing concepts used to authenticate/validate payment artifacts. Sheets repeatedly relies on public/private key cryptography (and certificate/signature validation) as core security primitives (The public key may be used for public functions such as encrypting a message to send to the entity or for verifying a digital signature which was supposedly made by the entity. The private key, on the other hand may be used for private functions such as decrypting a received message or applying a digital signature (¶ 0061).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1-20 is/are rejected under 35 U.S.C. 103 as being unpatentable Sheets et al. (US20150019443A1) hereinafter Sheets in view of Sullivan et al. (US20230097712A1) hereinafter Sullivan.
Regarding Claims 1 and 11, Sheets teaches: A method, a system comprising: memory storing instructions; and control circuitry configured to execute the instructions comprising:
receiving, from a computing device, one or more inbound digital payment tokens comprising:
Sheets - a payment credential may include an account identifier (e.g., a token ) (¶ 0039). receiving, by a server computer, a payment request including encrypted payment information (Claim 1). wherein the encrypted payment information includes encrypted payment credentials and unencrypted transaction information (Claim 2).
an inbound predecessor digital payment token previously generated by a token service separate from the computing device, wherein the token service generated the inbound predecessor digital payment token by digitally signing inbound predecessor data including an ephemeral public key provided by the computing device, and
Sheets – A “public/private key pair” may include a pair of linked cryptographic keys generated by an entity. The public key may be used for public functions such as encrypting a message to send to the entity or for verifying a digital signature which was supposedly made by the entity. The private key, on the other hand may be used for private functions such as decrypting a received message or applying a digital signature. The public key will usually be authorized by a body known as a certification authority (i.e., certificate authority) which stores the public key in a database and distributes it to any other entity which requests it (¶ 0061). The token registry 1061…where tokens may be issued to a mobile device 1020…processed using tokens instead of primary account numbers/identifiers (PANs) (¶ 0189). the mobile payment application 1023 sends the encrypted token and the transaction public key to third party server system (¶ 0227). the third party server system decrypts the encrypted payment token. In some embodiments, the payment token may be decrypted using the transaction public key, the server private key, the key derivation function, the elliptic curve and the generator function, and the received encrypted payment token. The decrypted payment token may then be processed by third party server system (¶ 0228). At step 1304, the mobile payment application 1023 generates a random ephemeral elliptic curve (EC) key pair associated with a payment transaction. The key pair may comprise a transaction private key and a transaction public key. In the embodiment of FIG. 13, the key pair may be generated such that the transaction public key is equal to the transaction private key multiplied by the generator function (¶ 0230).
an inbound assignment layer added to the inbound predecessor digital payment token by digitally signing, with an ephemeral private key corresponding to the ephemeral public key in the inbound predecessor data, inbound assignment data including a counterparty public key and the inbound predecessor digital payment token; and
Sheets – A “key pair” may include a pair of linked cryptographic keys. For example, a key pair can include a public key and a corresponding private key. In a key pair, a first key (e.g., a public key) may be used to encrypt a message, while a second key (e.g., a private key) may be used to decrypt the message. Additionally, a public key may be able to verify a digital signature created with the corresponding private key. The public key may be distributed throughout a network in order to allow for verification of messages signed using the corresponding private key. Public and private keys may be in any suitable format, including those based on RSA or elliptic curve cryptography (ECC) (¶ 0031). An “ephemeral key” can include a temporary cryptographic key. An ephemeral key can be an ephemeral public key or an ephemeral private key. An ephemeral key can be generated for each execution of a key establishment process. An ephemeral key can be used one or more times in a session (¶ 0032).
in response to receiving the one or more inbound digital payment tokens from the computing device, extracting the ephemeral public key from the inbound predecessor digital payment token; generating an outbound digital payment token comprising:
extracting the ephemeral public key from the inbound predecessor digital payment token;
Sheets - extract a public key from the validated certificate, re-encrypt the decrypted payment information, and send the re-encrypted payment information to a transaction processor for initiation of a payment transaction. Accordingly, the payment request may include any information relevant to the secure process for transmitting sensitive data to a merchant server for processing a remote transaction (¶ 0037). At step 508, remote key manager 140 re-encrypts the payment information using the determined merchant public key. As explained above, the merchant public key may be included in the merchant application certificate and extracted at any point during the remote transaction processing. The remote key manager 140 may determine the merchant public key in any suitable manner including extracting the public key from the merchant certificate, using a stored merchant public key for merchants registered with the remote key manager 140, etc (¶ 0120).
d) a return assignment layer added to the outbound predecessor digital payment token by digitally signing, with a counterparty private key corresponding to the counterparty public key in the outbound predecessor data, outbound assignment data including the extracted ephemeral public key and the outbound predecessor digital payment token; and
Sheets - Accordingly, the cryptogram validation module 161(B) may validate the dynamic cryptogram generated by the mobile payment application 123 and may return another dynamic cryptogram (e.g., authentication response value) that may be returned to the mobile device 120 and submitted with any authorization request message that is generated for the transaction. Accordingly, the payment processing network 160 may obtain the authentication response value during the transaction processing of the authorization request message and may validate that the authentication response value matches the generated authentication response message originally generated by the payment processing network 160 during the initial processing of the remote payment transaction (¶ 0159).
sending, to the computing device, the outbound digital payment token.
Sheets - sending, by the server computer, a payment response including the re-encrypted payment information to a transaction processor, wherein the transaction processor decrypts the re-encrypted payment information using a transaction processor private key and initiates a payment transaction using the decrypted payment information (Claim 1).
Sheets does not teach, however Sullivan teaches:
c) an outbound predecessor digital payment token generated by digitally signing outbound predecessor data including a counterparty public key, and
Sullivan - generating, by the access device, a session key using at least a private cryptographic key in the access device ephemeral key pair and a public cryptographic key in the user device key pair; and using, by the access device, the session key to secure an ultra-wideband communication channel between the user device and the access device (¶ 0005).
Therefore, it would have been obvious before the effective filing date of the claimed invention of the application to modify a payment credential of Sheets with the user key of Sullivan because doing so allows a single session to be used to not allow the user to be tracked.
Regarding Claims 2 and 12, the combination of Sheets and Sullivan further teaches: The method of claim 1 and the system of claim 11, wherein a plurality of inbound digital payment tokens are received from one or more computing devices, each of the plurality of inbound digital payment tokens further including a tracking payload including a hint of a consumer identifier and the control circuitry;
Sheets - At step 1104, the mobile payment application 1023 may use the received payee information to retrieve and generate payment information using the secure element 1022. For example, the mobile payment application 1023 may access token information from the secure element 1022 and generate a payment request payload (including token data elements) and a dynamic value (e.g., authentication value) using the payee information, the token, and the information associated with the token (e.g., token expiration date) (¶ 0199).
the method further comprising: storing the received hints for each consumer identity; and
Sullivan - The memory 202 can be used to store data and code. For example, the memory 202 can store public/private key pairs, certificates, etc. The memory 202 may be coupled to the processor 204 internally or externally (e.g., cloud based data storage), and may comprise any combination of volatile and/or non-volatile memory, such as RAM, DRAM, ROM, flash, or any other suitable memory device (¶ 0069).
in response to receiving sufficient hints to reveal a consumer identifier, reconstructing, from the stored hints for a consumer identifier, the consumer identifier.
Sheets - At the end of the day, a normal clearing and settlement process can be conducted by the payment processing network 160. A clearing process is a process of exchanging financial details between an acquirer and an issuer to facilitate posting to a customer's payment account and reconciliation of the user's settlement position (¶ 0082).
Regarding Claims 3 and 13, the combination of Sheets and Sullivan further teaches: the method of claim 2 and the system of claim 12, wherein the tracking payload is encrypted, and a control service is arranged in operation to:
decrypt the tracking payload using a cryptographic key;
Trock - Via this propagation, the computer devices are arranged to propose transactions and blocks for addition to the blockchain as well as to validate transactions and blocks. In order to add a block to the blockchain, a node is typically required to solve a cryptographic puzzle; for example, the node may need to determine a combination of a block hash and a nonce that gives a certain value when this combination is hashed. The remaining nodes 5 may receive such a proposed block from a proposing node and may validate and/or propagate this block throughout the network (page 12, lines 1-6).
and perform the storing of the received hints for each consumer, and the reconstructing of the consumer identifier.
Trock - Via this propagation, the computer devices are arranged to propose transactions and blocks for addition to the blockchain as well as to validate transactions and blocks. In order to add a block to the blockchain, a node is typically required to solve a cryptographic puzzle; for example, the node may need to determine a combination of a block hash and a nonce that gives a certain value when this combination is hashed. The remaining nodes 5 may receive such a proposed block from a proposing node and may validate and/or propagate this block throughout the network (page 12, lines 1-6).
Regarding Claims 4 and 14, the combination of Sheets and Sullivan teaches: the method of claim 2 and the system of claim 12, further comprising, in response to reconstructing the consumer identifier, sending a request to a token service to at least reduce the provision of digital payment tokens to the identified consumer.
Sheets -For example, the secure element 122 may be operable to store payment information. Further, a mobile payment application 123 may be provisioned and stored on the secure element 122 to securely access personalized sensitive information (e.g., payment credentials, tokens, account identifiers, etc.) associated with a consumer's financial account (¶ 0088).
Regarding Claims 5 and 15, the combination of Sheets and Sullivan teaches: the method of claim 4 and the system of claim 14, wherein the tracking payload is encrypted, and a control service is arranged in operation to: decrypt the tracking payload using a cryptographic key; and perform the storing of the received hints for each computing device, the reconstructing of the consumer identifier, and the sending of the request to the token service to at least reduce the provision of digital payment tokens to the identified consumer.
Sheets - Further, at step 1104, the mobile payment application 1023 may use a third-party public encryption key to encrypt the remote transaction request payload including the token, token authentication data, and other transaction data. In some embodiments, the mobile payment application 1023 may determine the third-party public key using a third-party certificate stored on the mobile device 1020 or may access the third-party public key through a certificate authority 180 or other database. The public key may be provisioned into the mobile payment application secure element 1022 and the mobile payment application 1023 may have access to the third-party public key. Alternatively or in combination, the mobile payment application 1023 may have an encryption key (either symmetric or a public key of a public/private key pair) associated with the remote transaction application 1025 provisioned into the secure element 1022 and encrypt the payment information using the provisioned key (¶ 0204).
Regarding Claims 6 and 16, the combination of Sheets and Sullivan teaches: the method of claim 1 and the system of claim 11, further comprising receiving from the computing device, an ephemeral certificate in which data comprising the ephemeral public key is signed with a token service private key.
Sullivan - One embodiment is related to a method comprising: forming a communication channel between a user device and an access device; securing the communication channel between the user device and the access device using a user device key pair in the user device and an access device ephemeral key pair in the access device; generating, by the access device, a session key using at least a private cryptographic key in the access device ephemeral key pair and a public cryptographic key in the user device key pair; and using, by the access device, the session key to secure an ultra-wideband communication channel between the user device and the access device (¶ 0005).
Regarding Claims 7 and 17, the combination of Sheets and Sullivan teaches: the method of claim 1 and the system of claim 11, wherein the inbound predecessor digital payment token comprises a digital payment token generated by a token service by digitally signing the ephemeral public key with a token service private key.
Sullivan - One embodiment is related to a method comprising: forming a communication channel between a user device and an access device; securing the communication channel between the user device and the access device using a user device key pair in the user device and an access device ephemeral key pair in the access device; generating, by the access device, a session key using at least a private cryptographic key in the access device ephemeral key pair and a public cryptographic key in the user device key pair; and using, by the access device, the session key to secure an ultra-wideband communication channel between the user device and the access device (¶ 0005).
Regarding Claims 8 and 18, the combination of Sheets and Sullivan teaches: the method of claim 1 and the system of claim 11, wherein the outbound digital payment token comprises the inbound digital payment token and the return assignment layer.
Sullivan – The authorization response message may also include an authorization code, which may be a code that a credit card issuing bank returns in response to an authorization request message in an electronic message (either directly or through the transaction processing computer) to the merchant's access device (e.g., POS equipment) that indicates approval of the transaction. The code may serve as proof of authorization (¶ 0024).
Regarding Claims 9 and 19, the combination of Sheets and Sullivan teaches: the method of claim 1 and system of claim 11, further comprising, in response to receiving the one or more inbound digital payment tokens from the computing device: calculating a return payment amount; and
Sheets - For example, an authentication response value may be generated similarly to the dynamic value above but may be generated using a different shared secret or algorithm such that another entity within the transaction processing eco-system that has access to the shared secret may determine that the message, account, or other information included in the message has been authenticated by an entity. For instance, particular static data elements (e.g., account identifier, expiration date, transaction time, date, etc.) associated with a transaction may be used to generate the authentication response value during the authentication phase and the calculation may be repeated (using the same data elements) during the payment phase after receiving the authorization request message, to validate that the authentication response value (¶ 0055).
obtaining the outbound predecessor digital payment token for the calculated return payment amount.
Sheets - For example, an authentication response value may be generated similarly to the dynamic value above but may be generated using a different shared secret or algorithm such that another entity within the transaction processing eco-system that has access to the shared secret may determine that the message, account, or other information included in the message has been authenticated by an entity. For instance, particular static data elements (e.g., account identifier, expiration date, transaction time, date, etc.) associated with a transaction may be used to generate the authentication response value during the authentication phase and the calculation may be repeated (using the same data elements) during the payment phase after receiving the authorization request message, to validate that the authentication response value (¶ 0055).
Regarding Claims 10 and 20, the combination of Sheets and Sullivan teaches: the method of claim 1 and system of claim 11 further comprising, in response to receiving the one or more inbound digital payment tokens from the computing device: calculating a return payment amount; and
Sheets – The transaction processing module 141(C) may be configured to process a payment request and provide a payment response in return to the payment request, assuming a received or stored public key certificate is valid and active for the transaction. For example, the transaction processing module 141(C) may decrypt received encrypted messages using a remote key manager private key stored in a private key database 141(E) and use the extracted transaction processor public key from the transaction processor certificate (e.g., merchant certificate) to re-encrypt the decrypted message or information from the message for secure delivery to the transaction processor. The transaction processing module 141(C) may further communicate the re-encrypted message (e.g., payment response) to the mobile device interface 141(D) for delivery to the appropriate transaction processor (¶ 0097).
including the calculated return payment amount in the return assignment layer added to the outbound predecessor digital payment token.
Sheets – The transaction processing module 141(C) may be configured to process a payment request and provide a payment response in return to the payment request, assuming a received or stored public key certificate is valid and active for the transaction. For example, the transaction processing module 141(C) may decrypt received encrypted messages using a remote key manager private key stored in a private key database 141(E) and use the extracted transaction processor public key from the transaction processor certificate (e.g., merchant certificate) to re-encrypt the decrypted message or information from the message for secure delivery to the transaction processor. The transaction processing module 141(C) may further communicate the re-encrypted message (e.g., payment response) to the mobile device interface 141(D) for delivery to the appropriate transaction processor (¶ 0097).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Kang et al. (US20080154782A1) - A method, apparatus, and system for protecting personal information are provided. The personal-information-protecting apparatus is a device for protecting personal information using a pseudonym, and includes a pseudonym-generating unit that generates a pseudonym, a pseudo-public key corresponding to the pseudonym, and a pseudo-secret key, and a verifying unit that verifies that the pseudonym included in a rights object is identical to one of the generated pseudonyms. The device stores and manages metering data and billing information. The system includes a device, a rights issuer, and at least one of a pseudonym credential issuer and a paying center.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHRISTINA C whose telephone number is (571)270-7280. The examiner can normally be reached on Monday-Friday from 8am to 5pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Patrick Mcatee, can be reached at telephone number 571-272-7575. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/C.C.S./ Examiner, Art Unit 3698
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698