DETAILED ACTION
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 .
Information Disclosure Statement
The information disclosure statements (IDS) submitted on August 25,2025 is being considered by the examiner.
Status of the Claims
This is a non-final rejection prepared in response to U.S. Patent Application 19/159,414 filed on
August 25, 2025.
Claims 1-27 are pending.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-27 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an
abstract idea without significantly more.
Step 1: Claims 1-9 are directed to a are directed to computer-implemented method (i.e., process). Claims 10-19 are directed to a system (i.e., machine, and manufacture). Claims 19-27 are directed to a computer-storage media (i.e., manufacture). Therefore, these claims fall within the four statutory categories of invention and thus must be further analyzed at Step 2A to determine if the claims are directed to a judicial exception (See MPEP 2106.03, subsection II).
Step 2A Prong One: Claim 1, recites (i.e., sets forth or describes) an abstract idea. More specifically, the following bolded claim elements recite abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
A computer-implemented method comprising:
distributing a software development kit (SDK) including at least one software function to establish a secure connection between a client-side application running the SDK and a remote server computer;
in response to receiving a request from a merchant application incorporating the SDK, transmitting, to the merchant application, at least one key value;
receiving a transaction request associated with a transaction, the transaction request initiated through the merchant application;
in response to receiving the transaction request, transmitting an authentication request to the merchant application;
receiving encrypted data from the merchant application, the encrypted data generated with the at least one key value and based on device data associated with a user device initiating the transaction;
generating an authentication decision for the transaction based on determining whether the encrypted data is valid; and
updating, via the secure connection and in the merchant application, the at least one key value to replace the at least one key value with at least one updated key value.
Claim 1, recites (i.e., sets forth or describes) a method for determining whether a transaction is valid. The claim achieves this by receiving an encryption key, receiving a transaction request via a merchant, sending an authentication request to the merchant, receiving data encrypted with the received encryption key in response to the authentication request, generating an authentication decision based on determining that the received encrypted data is valid and then updating the encryption key with a new encryption key. Claim 10 and 19 are significantly similar to claim 1. As such claim 10 and 19 also recite an abstract idea. Specifically, the claim under its broadest reasonable interpretation recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas (i.e., commercial interactions) and “mental processes”.
Further, in regard to “the encrypted data generated with the at least one key value and based on device data associated with a user device initiating the transaction” the examiner finds this to further recite an abstract idea of “mathematical concept”. Claims 10 and 19 are significantly similar to claim 1. As such claim 10 and 19 also recite an abstract idea.
Step 2A Prong Two: Because the claim recites abstract ideas, the analysis proceeds to
determine whether the claim recites additional elements that recite a practical application of the
abstract ideas. Here, the additional elements of a software development kit (SDK), a secure connection, a client-side application, a remote server computer, a merchant application and a user device merely serve as a tool to perform the abstract idea (MPEP § 2106.05(f)). Further, the additional element “computer- implemented” generally links the use of the judicial exception to a particular technological environment (MPEP § 2106.05(h)). Therefore, the claim as a whole fail to recite a practical application of the abstract ideas.
Step 2B: Determines whether the claim as a whole amount to significantly more than the exception itself. Evaluating additional elements to determine whether they amount to an inventive concept requires considering them both individually and in combination to ensure that they amount to significantly more than the judicial exception itself. Here, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. As discussed previously with respect to Step 2A, the additional elements merely serve as a tool to perform an abstract idea. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Dependent Claims: Claims 2-9, 11-18 and 20-27 have also been analyzed for subject matter
eligibility. The claims recite bolded claim elements as abstract ideas and non-bolded claim elements, if
any, as additional elements according to MPEP 2106.04(a). Accordingly, claims 2-9, 11-18 and 20-27 also fail to recite patent eligible subject matter for the following reasons:
Claims 2, 11 and 20 recite:
the transaction request is associated with a payment transaction between a user associated with the user device and a merchant associated with the merchant application, the user device being a mobile device of the user.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” and “mental processes” grouping of abstract ideas. The non-bolded additional elements of a user device, a merchant application and a mobile device fail to recite a practical application or significantly more than the abstract idea because they merely serve as tools to perform the abstract idea (MPEP §2106.05(f)). Further, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Claims 3, 12 and 21 recite:
determining whether the encrypted data is valid comprises decrypting the encrypted data by applying at least one second key value and determining whether the decrypted data is valid, the at least one second key value and the at least one first key value forming a key pair.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity”, “mental processes” and “mathematical concepts” grouping of abstract ideas. The claim does not recite any additional elements for consideration under Step 2A prong two and Step 2B. Therefore, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Claims 4, 13 and 22 recite:
the authentication decision represents that the encrypted data is not valid, the computer- implemented method further comprising initiating a challenge protocol in response to determining that the encrypted data is not valid, the challenge protocol comprising:
transmitting a public key generated by an authentication server to the merchant application, the authentication server retaining a private key, the public key and the private key forming a key pair;
receiving second encrypted data from the merchant application generated with the public key and based on challenge data;
transmitting a challenge request to the authentication server, the challenge request comprising the second encrypted data; and
receiving a challenge response from the authentication server, the challenge response validating the second encrypted data based on decrypting the second encrypted data by applying the private key to the second encrypted data.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity”, “mental processes” and “mathematical concepts” grouping of abstract ideas. The non-bolded additional elements of an authentication server and a merchant application fail to recite a practical application or significantly more than the abstract idea because they merely serve as tools to perform the abstract idea (MPEP §2106.05(f)). Further, the additional element “computer- implemented” generally links the use of the judicial exception to a particular technological environment (MPEP § 2106.05(h)). Furthermore, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Claims 5, 14 and 23 recite:
updating the at least one key value comprises transmitting via the secure connection the at least one updated key value to the merchant application to cause the at least one updated key value to be cached in the merchant application.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional elements of a secure connection and a merchant application fail to recite a practical application or significantly more than the abstract idea because they merely serve as tools to perform the abstract idea (MPEP §2106.05(f)). Further, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Claims 6, 15 and 24 recite:
in response to receiving the encrypted data from the merchant application, determining an authentication server associated with the transaction request;
generating a request comprising the encrypted data, and based on the determined authentication server,
transmitting the request to the authentication server to cause the authentication server to determine whether the encrypted data is valid.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” and “mental processes” grouping of abstract ideas. The non-bolded additional elements of a merchant application and an authentication server fail to recite a practical application or significantly more than the abstract idea because they merely serve as tools to perform the abstract idea (MPEP §2106.05(f)). Further, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Claims 7, 16 and 25 recite:
the at least one key value is updated in response to receiving the transaction request
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The claim does not recite any additional elements for consideration under Step 2A prong two and Step 2B. Therefore, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Claims 8, 17 and 26 recite:
the at least one key value and the at least one updated key value are not hardcoded into the SDK.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional element of an SDK fails to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Claims 9, 18 and 27 recite:
updating the at least one key value does not comprise modifying code of the SDK.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional element of an SDK fails to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
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.
Claims 1-3, 5, 10-12, 14, 19-21 and 23 are rejected under 35 U.S.C. 103 as being unpatentable over Li (US 20210075589 A1) in view of Wang (US 20190228190 A1).
Regarding claims 1, 10 and 19, Li discloses:
distributing a software development kit (SDK) including at least one software function to establish a secure connection between a client-side application running the SDK and a remote server computer; (¶0054, Alternatively, the online platform may provide software development kits (SDKs) that can be integrated into applications of the business entity for directly performing operations related to DIDs and VCs. ¶0084, The code libraries may be packaged into one or more SDKs and be used to perform functionalities such as DID authentication, interactions with the blockchain 300, or interfacing with blockchain contracts 331. ¶0086, The user-side system 310 may use one or more SDKs 312 for managing DIDs that are compatible with methods associated with the DIDs. The SDKs 312 may be integrated with one or more applications used by the user-side system 310. ¶0088, The user-side system 310 may comprise an SDK 312 for performing the various operations. The SDK 312 may also manage various interactions between the user-side system 310 and various interfaces provided by the service-side system 320.)
in response to receiving a request from a merchant application incorporating the SDK, transmitting, to the merchant application, at least one key value; (¶0095, The method illustrated in FIG. 6B may start at step 642, the user may provide one or more inputs to the identity management application 533 in order to request creation of a DID for the user. ¶0097, At step 670, the identity management application 533 may provide a notification comprising information associated with the created DID and DID document for display to the user.)
receiving a transaction request associated with a transaction, the transaction request initiated through the merchant application; (¶0099, In some embodiments, a verifier 532 (e.g., a service provider needing to verify information of a customer) may initiate a DID authentication process using an SDK 312. At step 702, the verifier 532 may obtain the DID provided by a purported owner. ¶0131, The method illustrated in FIG. 13 may start at step 1311, where the purported DID owner may provide a DID to the verifier 532.)
in response to receiving the transaction request, transmitting an authentication request to the merchant application; (¶0099, At step 718, the verifier 532 may use the SDK 312 to send the challenge to the DID authentication services associated with the DID. ¶0100, In some embodiments, after obtaining the DID authentication challenge from the verifier 532, the DID authentication services may obtain consent from the owner for such authentication request at step 720. ¶0131, In response to obtaining the DID, the verifier 532 may begin the authentication process for the DID. At step 1312, the verifier 532 may provide to the purported DID owner a DID authentication challenge.
receiving encrypted data from the merchant application, the encrypted data generated with the at least one key value and based on device data associated with a user device initiating the transaction; (¶0134, At step 1319, the service-side system 320 may return the digital signature on the plaintext to the user-side system 310a. The user-side system 310a may generate a response to the DID authentication challenge based on the digital signature and send the response to the purported DID owner at step 1320. The response may comprise information associated with the DID (e.g., the DID), information associated with the DID authentication challenge (e.g., an identifier of the DID authentication challenge), the plaintext included in the DID authentication challenge, the digital signature, other suitable information, or any combination thereof. Then, at step 1321, the purported DID owner may provide the response to the verifier 532.
generating an authentication decision for the transaction based on determining whether the encrypted data is valid; and (¶0100, If the owner provides consent or permission for the identity authentication, the DID authentication services may call its version of the SDK 312 to create a response to the DID authentication challenge at step 722. In some embodiments, the response to the DID authentication challenge may comprise plaintext that is the result of decrypting the ciphertext in the challenge using the private key associated with the DID. The SDK 312 may return the response to the DID authentication services at step 724, which may then send the response to the network address provided by the verifier 432 at step 726. Upon receiving the response to the DID authentication challenge, the verifier 532 may call its SDK 312 at step 728 to check the response. At step 730, the SDK 312 may determine whether the response proves that the user providing the DID is the owner of the DID. In some embodiments, the SDK 312 may check the response by comparing decrypted text in the response with the original text that was used to create the DID authentication challenge. If the response is determined to be correct, the SDK 312 may return a message to the verifier 532 indicating the DID is a valid proof of identity of the user at step 732. At step 734, the verifier 532 may notify the user as to the validity of the DID. ¶0135, After receiving the response to the DID authentication challenge from the purported DID owner, the verifier 532 may initiate a process for authenticating the ownership of the DID based on the response. ¶0137, At step 1326, the service-side system 320 may verify the digital signature based on the plaintext and the public key. In one embodiment, the service-side system 320 may determine, based on the obtained public key and the plaintext, whether the digital signature on the plaintext is created based on a private key corresponding to the DID. For example, the service-side system 320 may calculate a hash value of the plaintext and decrypt the digital signature using the public key to obtain a decrypted value. The service-side system 320 may compare the calculated hash value and the decrypted value to determine whether they are the same. If so, the service-side system 320 may determine that the digital signature is created based on the private key corresponding to the public key. At step 1327, the service-side system 320 may return a result of authentication to the user-side system 310b (the sender of the request for authenticating the DID). If the service-side system 320 determines that the digital signature on the plaintext is created based on the private key corresponding to the DID, the service-side system 320 may generate and send a message confirming authentication of the DID. This confirms that the purported DID owner is the actual owner of the DID. Otherwise, the service-side system 320 may generate and send a message indicating that the authentication of the DID has failed. At step 1328, the user-side system 310b may forward the result to the verifier 532, the creator of the DID authentication challenge. Alternatively, the service-side system 320 may directly return the result to the verifier 532, the creator of the DID authentication challenge.)
Li does not disclose, however Wang teaches:
updating, via the secure connection and in the merchant application, the at least one key value to replace the at least one key value with at least one updated key value. (¶0041, In some embodiments, the intermediate server 140 can update the encryption key every time after the transaction is completed so the network transmission between the intermediate server 140 and the internet dongle 120 can be secured.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of
the claimed invention to have modified the system of Li with the teaching of Wang. One of ordinary skills in the art would have been motivated to combine these common elements in order to maintain a secure transaction process by having updated cryptographic keys.
Further, in the method claim, the claim limitation “in response to receiving a request from a merchant application incorporating the SDK, transmitting, to the merchant application, at least one key value” is a conditional limitation which means that the claim limitation is only required when the stated condition is met.
Furthermore, the claimed limitation “to…” in “distributing a software development kit (SDK) including at least one software function to establish a secure connection between a client-side application running the SDK and a remote server computer” consists of language disclosing an intended use, so it is considered but given no patentable weight. (see MPEP 2111.05, MPEP 2114 and authorities cited therein). The reference is provided for the purpose of compact prosecution.
Regarding claims 2, 11 and 20, the combination of Li and Wang further disclose:
the transaction request is associated with a payment transaction between a user associated with the user device and a merchant associated with the merchant application, (¶0067, For example, the blockchain transaction A may comprise information such as nonce (e.g., transaction serial number), from (e.g., a blockchain address of the user), to (e.g., empty if deploying a blockchain contract), transaction fee, signature (e.g., signature of the server end 118, signature of the user managed by the server end 118), value (e.g., transaction amount), data (e.g., the blockchain contract), etc. ¶0068, The blockchain transaction B may comprise information such as nonce, from, to, transaction fee, value, signature, data, etc. Node B may send the blockchain transaction B to one or more blockchain nodes of the blockchain system 112 through a remote procedure call (RPC) interface 223 for execution.)
the user device being a mobile device of the user. (¶0056, In some embodiments, Node C may be implemented by an entity (e.g., website, mobile phone Application, organization, company, enterprise), which has various local accounts (e.g., local accounts assessed from Node A1, Node A2, Node A3). For example, a mobile phone Application may have millions of end-users accessing the Application's server from respective user accounts.)
Further, the claimed limitation “the user device being a mobile device of the user” only describe characteristics of the user device which are non-functional descriptive material and these characteristics are not processed or used to carry out any functionality that specifically relies on these particular characteristics.
Regarding claims 3, 12 and 21, the combination of Li and Wang further disclose:
determining whether the encrypted data is valid comprises decrypting the encrypted data by applying at least one second key value and determining whether the decrypted data is valid, the at least one second key value and the at least one first key value forming a key pair. (¶0137, At step 1326, the service-side system 320 may verify the digital signature based on the plaintext and the public key. In one embodiment, the service-side system 320 may determine, based on the obtained public key and the plaintext, whether the digital signature on the plaintext is created based on a private key corresponding to the DID. For example, the service-side system 320 may calculate a hash value of the plaintext and decrypt the digital signature using the public key to obtain a decrypted value. The service-side system 320 may compare the calculated hash value and the decrypted value to determine whether they are the same. If so, the service-side system 320 may determine that the digital signature is created based on the private key corresponding to the public key.)
Further, the claimed limitation “the at least one second key value and the at least one first key value forming a key pair” only describe characteristics of the at least one second key value and the at least one first key value which are non-functional descriptive material and these characteristics are not processed or used to carry out any functionality that specifically relies on these particular characteristics.
Regarding claims 5, 14 and 23, the combination of Li and Wang disclose:
updating the at least one key value comprises transmitting via the secure connection the at least one updated key value to the merchant application to cause the at least one updated key value to be cached in the merchant application. (¶0023, Furthermore, to ensure the security of the transaction process, the intermediate server 140 and the internet dongle 120 can encrypt and decrypt the transmission message with one or a combination of the transport layer security (TLS) protocol, the secure sockets layer (SSL) protocol, the advanced encryption standard (AES) algorithm, and the Rivest-Shamir-Adleman (RSA) encryption algorithm to ensure transmission security through the internet in some embodiments. For example, in the aforementioned embodiments, the first transaction message A1, the second card reader operation message D2, and the second operation confirmation message E2 can be encrypted by the aforementioned protocols and algorithms. ¶0024, For example, the internet dongle 120 can be registered in the intermediate server 140 in advance, and the internet dongle 120 can be connected to the intermediate server 140 when booting up and obtain the corresponding encryption key after verification to make the network transmission more secure. See claim 5)
It would have been obvious to one of ordinary skill in the art before the effective filing date of
the claimed invention to have modified the combination of Li and Wang with the additional teaching of Wang. One of ordinary skills in the art would have been motivated to combine these common elements in order to maintain a secure transaction process by having updated cryptographic keys.
Further, the claimed limitation “to…” in “updating the at least one key value comprises transmitting via the secure connection the at least one updated key value to the merchant application to cause the at least one updated key value to be cached in the merchant application” consists of language disclosing an intended use, so it is considered but given no patentable weight. (see MPEP 2111.05, MPEP 2114 and authorities cited therein). The reference is provided for the purpose of compact prosecution.
Claims 4, 13 and 22 are rejected under 35 U.S.C. 103 as being unpatentable over Li and Wang as applied to claims 1, 10 and 19 above, in view of Siddiqui (US 20190207936 A1), in further view of Sheets (US 20150019443 A1).
Regarding claims 4, 13 and 22, the combination of Li and Wang do not disclose, however Siddiqui teaches:
the authentication decision represents that the encrypted data is not valid, the computer- implemented method further comprising initiating a challenge protocol in response to determining that the encrypted data is not valid, the challenge protocol comprising: (¶0048, At step 320, a check is performed to determine whether the response message has been successfully validated. The processor 202 retrieves the validation status from the memory 212, and determines the validation of the response message. If at step 320, it is determined that the response message has been successfully validated, then control flows to step 334. However, if at step 320, it is determined that the response message has not been successfully validated, then control flows to step 322. ¶0049, At step 322, the second challenge for challenging the authentication of the user device 104 is generated.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of
the claimed invention to have modified the combination of Li and Wang with the teaching of Siddiqui. One of ordinary skills in the art would have been motivated to combine these common elements in order to provide an additional opportunity to authenticate the transaction instead of instantly terminating the transaction process and reduce false rejection.
The combination of Li, Wang and Siddiqui do not disclose, however Sheets teaches:
transmitting a public key generated by an authentication server to the merchant application, the authentication server retaining a private key, the public key and the private key forming a key pair; (¶0090, Mobile payment application 123 may include a certificate associated with the remote key manager 140, which may be used to encrypt payment information and other communications using a public key associated with remote key manager 140. ¶0115, In some embodiments, mobile payment application 123 may determine the remote key manager public key using a remote key manager certificate stored on mobile device 120, may request a certificate from the mobile key manager, or may obtain the remote key manager public key on the secure element 122 or general memory of the mobile device 120. Where the remote key manager key is a symmetric key, the symmetric key may be stored securely with the mobile payment application 123. ¶0204, 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. ¶0206, The remote transaction application encryption key may include any suitable encryption key based on the key provisioned or used by the mobile payment application 1023 to encrypt the payment information. The key may be symmetric or a private key associated with the public key used to encrypt the payment information from the mobile payment application 1023.)
receiving second encrypted data from the merchant application generated with the public key and based on challenge data; (¶0115, At step 503, mobile payment application 123 encrypts the payment information using a remote key manager key. ¶0116, At step 504, mobile payment application 123 sends the encrypted payment information to merchant application 121. It should be noted that because the remote key manager private key is not known by merchant application 121, the encrypted payment information cannot be deciphered by the merchant application 121. ¶0117, At step 505, merchant application 121 receives the encrypted payment information and generates a payment request including the encrypted payment information, the received encrypted payment information, any other transaction data (e.g., transaction amount, merchant identifier, product identifiers, etc.) associated with the payment transaction that was not included in the encrypted payment information, a merchant certificate associated with the merchant computer 130, and a signature generated using the merchant computer private key. ¶0204, 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. ¶0205, At step 1105, the mobile payment application 1023 sends the payment information (either encrypted or not) to the remote transaction application 1025. ¶0206, At step 1106, the remote transaction application 1025 may determine whether the payment information is encrypted and if so, may obtain an encryption key for decrypting the encrypted payment information. Either way, the remote transaction application 1025 decrypts the encrypted payment information (if it is encrypted) and obtains the payment information including the payment credentials. Additionally, the remote transaction application 1025 may re-encrypt the decrypted payment information with a third party server computer public encryption key (e.g., mobile wallet provider computer encryption key) so that the sensitive payment information may be securely sent to the mobile wallet provider. The remote transaction application 1025 may have a third party encryption public key provisioned into the secure element 1022 or may use a public key certificate or other information in order to obtain the correct encryption key. Accordingly, the payment information may be encrypted with a third party server computer public key (e.g., mobile wallet provider public key) and the encrypted payment information may be sent to the third party service provider server computer (e.g., mobile wallet provider) for further remote transaction processing.)
transmitting a challenge request to the authentication server, the challenge request comprising the second encrypted data; and (¶0117, At step 505, merchant application 121 receives the encrypted payment information and generates a payment request including the encrypted payment information, the received encrypted payment information, any other transaction data (e.g., transaction amount, merchant identifier, product identifiers, etc.) associated with the payment transaction that was not included in the encrypted payment information, a merchant certificate associated with the merchant computer 130, and a signature generated using the merchant computer private key. The merchant application 121 may then transmit the payment request to the remote key manager 140. ¶0207, At step 1107, the encrypted payment information may then be sent to the remote transaction SDK 1024 or other remote transaction application 1025 on the mobile device 1020 that is capable of communicating the encrypted payment information to the third party server platform. The remote transaction SDK 1024 may then send the encrypted payment information to the third party server platform 130. It should be noted that because the third party private key is not known by the remote transaction SDK 1024, the merchant application 1021, the remote transaction application 1025, the mobile payment application 1023, or any other application or program located on the mobile device 1020, the encrypted payment information cannot be deciphered by any program on the mobile device 1020.)
receiving a challenge response from the authentication server, the challenge response validating the second encrypted data based on decrypting the second encrypted data by applying the private key to the second encrypted data. (¶0118, At step 506, the remote key manager 140 receives the payment request, may decrypt the payment request using the session key, and parses the encrypted payment information, non-encrypted transaction data, the merchant certificate, and the signature from the payment request. The remote key manager 140 may validate the signature. Typically, the signature may be validated using the public key included in the merchant certificate. ¶0119, At step 507, remote key manager 140 decrypts the encrypted payment information using a remote key manager key stored at the remote key manager 140. The remote key manager key may include a symmetric or a private key of a public/private key pair. In embodiments using the remote key manager private key, the private key is configured to decrypt information that has been encrypted with a corresponding remote key manager public key and the public key is meant to be stored securely at the remote key manager 140 so that only the remote key manager 140 may be capable of decrypting information encrypted with the remote key manager public key. Similarly, the symmetric key may be stored at the remote key manager 140 and used to decrypt the encrypted payment information. ¶0121, At step 509, the remote key manager 140 generates and sends a transaction response including the re-encrypted payment information to the merchant application 121 of the mobile device 120. In some embodiments, the re-encrypted payment information may be further encrypted using the previously established session key for secure communication between the remote key manager 140 and the mobile device 120. ¶0208, At step 1108, the third party server platform 130 may receive the encrypted payment information and may decrypt the payment information using the stored third party private key. Only the third party server system 130 may have access to the third party private key. Further, the third party server system 130 may validate the received payment information by checking to ensure that the correct third party public key was used to encrypted the payment information, that aspects of the payment information are correct (e.g., that the merchant identifier is associated with a registered merchant), and any other suitable validation that may ensure the encrypted payment information is being sent by a legitimate payment application, mobile device 1020, etc.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of
the claimed invention to have modified the combination of Li, Wang and Siddiqui with the teaching of Sheets. One of ordinary skills in the art would have been motivated to combine these common elements in order to maintain the information encrypted and only accessible to the authentication server.
Further, the claimed limitation “the authentication decision represents that the encrypted data is not valid”, “the authentication server retaining a private key”, “the public key and the private key forming a key pair” and “the challenge response validating the second encrypted data based on decrypting the second encrypted data by applying the private key to the second encrypted data” only describe characteristics of the authentication decision, the authentication server, the public and private key and the challenge response which are non-functional descriptive material and these characteristics are not processed or used to carry out any functionality that specifically relies on these particular characteristics.
Furthermore, in the method claim, the claim limitation “initiating a challenge protocol in response to determining that the encrypted data is not valid, the challenge protocol comprising…” is a conditional limitation which means that the claim limitation is only required when the stated condition is met.
Finally, in the method claim, the claim limitation “initiating a challenge protocol in response to determining that the encrypted data is not valid, the challenge protocol comprising…” is a conditional limitation which means that the claim limitation is only required when the stated condition is met.
Claims 6, 15 and 24 are rejected under 35 U.S.C. 103 as being unpatentable over Li and Wang as applied to claims 1, 10 and 19 above, in view of Sheets (US 20150019443 A1).
Regarding claims 6, 15 and 24, the combination of Li and Wang do not disclose, however Sheets teaches:
generating the authentication decision comprises: in response to receiving the encrypted data from the merchant application, determining an authentication server associated with the transaction request; (¶0113, Additionally, the payee information may include a type of transaction identifier informing the mobile payment application 123 that the request is associated with a remote payment transaction. Accordingly, the mobile payment application 123 may select the appropriate public encryption key in which to encrypt the payment information (e.g., remote key manager public key), the appropriate destination or routing address for the remote key manager 140, and the correct communication protocol or message format for communicating with the remote key manager 140.)
generating a request comprising the encrypted data, and based on the determined authentication server, (¶0114, At step 502, mobile payment application 123 uses the received payee information to retrieve and/or generate payment information from the secure element 122 of the mobile device 120. "Payment information" may include payment card data (e.g., a payment account number (PAN) and expiration date), a cryptogram (such as a dynamic card verification value (dCVV or dCVV2) or other dynamically generated data), or any other information suitable to conduct a remote payment transaction. ¶0115, At step 503, mobile payment application 123 encrypts the payment information using a remote key manager key. ¶0117, At step 505, merchant application 121 receives the encrypted payment information and generates a payment request including the encrypted payment information, the received encrypted payment information, any other transaction data (e.g., transaction amount, merchant identifier, product identifiers, etc.) associated with the payment transaction that was not included in the encrypted payment information, a merchant certificate associated with the merchant computer 130, and a signature generated using the merchant computer private key.)
transmitting the request to the authentication server to cause the authentication server to determine whether the encrypted data is valid. (¶0117, The merchant application 121 may then transmit the payment request to the remote key manager 140. In some embodiments, the payment request may be encrypted using a session key established between the remote key manager 140 and the mobile device 120. The session key may be established and communicated through any suitable manner. ¶0118, At step 506, the remote key manager 140 receives the payment request, may decrypt the payment request using the session key, and parses the encrypted payment information, non-encrypted transaction data, the merchant certificate, and the signature from the payment request. The remote key manager 140 may validate the signature. Typically, the signature may be validated using the public key included in the merchant certificate. Alternatively, in some embodiments, the public key may be registered and stored at the remote key manager as being associated with the merchant certificate. If the signature is not validated, then the remote key manager 140 indicates to the merchant application 121 that the signature is invalid, and the method halts. Otherwise, the method proceeds to step 507. ¶0119, At step 507, remote key manager 140 decrypts the encrypted payment information using a remote key manager key stored at the remote key manager 140. The remote key manager key may include a symmetric or a private key of a public/private key pair. In embodiments using the remote key manager private key, the private key is configured to decrypt information that has been encrypted with a corresponding remote key manager public key and the public key is meant to be stored securely at the remote key manager 140 so that only the remote key manager 140 may be capable of decrypting information encrypted with the remote key manager public key.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of
the claimed invention to have modified the combination of Li and Wang with the teaching of Sheets. One of ordinary skills in the art would have been motivated to combine these common elements in order to route the request to the correct authentication server for validation.
Further, the claimed limitation “to…” in “transmitting the request to the authentication server to cause the authentication server to determine whether the encrypted data is valid” consists of language disclosing an intended use, so it is considered but given no patentable weight. (see MPEP 2111.05, MPEP 2114 and authorities cited therein). The reference is provided for the purpose of compact prosecution.
Claims 7, 16 and 25 are rejected under 35 U.S.C. 103 as being unpatentable over Li and Wang as applied to claims 1, 10 and 19 above, in view of Kocher (US 6,539,092 B1).
Regarding claims 7, 16 and 25, the combination of Li and Wang do not disclose, however Kocher teaches:
the at least one key value is updated in response to receiving the transaction request. (Col 1 lines 63-67, In such methods, the client repeatedly applies a cryptographic function to its internal secret between or during transactions, such that information leaked in each of a series of transactions cannot be combined to compromise the secret. col2 lines 22-30, In one embodiment, a cryptographic client device (e.g., a smartcard) maintains a secret key value as part of its state. The client can update its secret value at any time, for example before each transaction, using an update process that makes partial information that may have previously leaked to attackers about the secret no longer (or less) usefully describe the new updated secret value. (Information is considered useful if it can help or enable an attacker to implement an actual attack.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of
the claimed invention to have modified the combination of Li and Wang with the teaching of Kocher. One of ordinary skills in the art would have been motivated to combine these common elements in order to maintain the system secured against any possible leak of information.
Further, the claimed limitation “the at least one key value is updated in response to receiving the transaction request” only describe characteristics of the at least one key value which are non-functional descriptive material and these characteristics are not processed or used to carry out any functionality that specifically relies on these particular characteristics.
Claims 8, 17 and 26 are rejected under 35 U.S.C. 103 as being unpatentable over Li and Wang as applied to claims 1, 10 and 19 above, in view of Douglas (WO 2018157247 A1).
Regarding claims 8, 17 and 26, the combination of Li and Wang do not disclose, however Douglas teaches:
the at least one key value and the at least one updated key value are not hardcoded into the SDK. (¶00119, In some embodiments, ACM to Application Shield leverages a SDK Signing technique which does not contain any hardcoded encryption keys and file writing functions to offer user inherent protection against memory leaks/injections, SQL injections, and process override.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of
the claimed invention to have modified the combination of Li and Wang with the teaching of Douglas. One of ordinary skills in the art would have been motivated to combine these elements in order to prevent the encrypted data from being recovered by malicious users (¶00119).
Further, the claimed limitation “the at least one key value and the at least one updated key value are not hardcoded into the SDK.” only describe characteristics of the at least one key value and the at least one updated key value which are non-functional descriptive material and these characteristics are not processed or used to carry out any functionality that specifically relies on these particular characteristics.
Claims 9, 18 and 27 are rejected under 35 U.S.C. 103 as being unpatentable over Li and Wang as applied to claims 1, 10 and 19 above, in view of Lounsberry (US 20220083643 A1).
Regarding claims 9, 18 and 27, the combination of Li and Wang do not disclose, however Lounsberry teaches:
updating the at least one key value does not comprise modifying code of the SDK. (¶0003, The secrets are initially deployed, for example on a node or virtual machine running the service, after which, dSMS can automatically renew the secrets according to the specified rollover policy, and polling agents for an associated service can fetch updates from dSMS. In this manner, secrets can be automatically renewed without manual orchestration and/or the need to redeploy services. ¶0038, For example, a service model and/or corresponding configuration file does not need to be updated, and autonomous secrets rollover can occur without redeploying the services which use the secrets, thereby avoiding outages and security non-compliances resulting from conventional practices)
It would have been obvious to one of ordinary skill in the art before the effective filing date of
the claimed invention to have modified the combination of Li and Wang with the teaching of Lounsberry. One of ordinary skills in the art would have been motivated to combine these elements so human intervention is not required, therefore reducing processing time and human error and improving system efficiency.
Relevant Prior Art
The following prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20210194672 A1 to Narayanam discloses: An example operation may include one or more of receiving blocks of a blockchain from one or more of a neighboring blockchain peer and an ordering service node, identifying two or more blocks from among the received blocks that belong to a same slot within the blockchain, validating the two or more identified blocks in parallel via execution of the two or more identified blocks at a same time, and in response to validation of the two or more identified blocks, storing the two or more identified blocks on a local blockchain ledger of a blockchain peer.
US 20210406889 A1 to Montiani discloses: A computer-implemented method comprising receiving a transaction request from a merchant server. In response to receiving the transaction request, the method includes requesting authentication from a computing device associated with a user payment account and a requesting that a merchant re-submit the transaction request. The method includes receiving an authentication parameter from the computing device, and determining that the authentication parameter matches an authentication parameter of the user payment account. The method includes receiving a re-submission of the transaction request from the merchant server and, based on the determination that the authentication parameter received from the computing device matches the authentication parameter associated with the user payment account, approving the transaction request.
US 20130262317 A1 to Collinge discloses: A method for generating and provisioning payment credentials to a mobile device lacking a secure element includes: generating a card profile associated with a payment account, wherein the card profile includes at least payment credentials corresponding to the associated payment account and a profile identifier; provisioning, to a mobile device lacking a secure element, the generated card profile; receiving, from the mobile device, a key request, wherein the key request includes at least a mobile identification number (PIN) and the profile identifier; using the mobile PIN; generating a single use key, wherein the single use key includes at least the profile identifier, an application transaction counter, and a generating key for use in generating a payment cryptogram valid for a single financial transaction; and transmitting the generated single use key to the mobile device.
EP 0151491 A2 to Tamada discloses: A data processing terminal device is on-line connected to a host computer and records on journal paper journal data obtained as a result of communication with the host computer. Data is encrypted, and encrypted data is exchanged between the terminal device and the host computer. The encrypted journal data is printed together with the normal journal data on the journal paper. By comparing the Journal data with its encrypted data, journal data alteration can be easily detected.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JANICE LOZA whose telephone number is (571)270-3979. The examiner can normally be reached Monday - Friday 7:30am - 5:00pm.
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) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Patrick McAtee can be reached at (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 published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/J.L./Examiner, Art Unit 3698
/STEVEN S KIM/Primary Examiner, Art Unit 3698
