DETAILED ACTION
This is a non-final office action on the merits and in response to the applicant’s amendment received on 12/16/2025 (“Amendment”).
Claims 2-4 and 15–22 have been canceled.
Claims 1 and 12 are currently amended.
Claims 1, 5-14 and 23-26 are pending.
Notice of Pre-AIA or AIA Status
The present application, filed on or after 16 March 2013, is being examined under the first inventor to file provisions of the AIA .
In the event the determination of the status of the application as subject to AIA 35 U.S.C. § 102 and 103 (or as subject to pre-AIA 35 U.S.C. § 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Claim Rejections - 35 U.S.C. § 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, 5–14 and 23–26 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to an abstract idea without significantly more.
Regarding claims 1–14 and 21–26. In the present application, claims 1and 5–11 are directed to a method (i.e., process) and claims 12–14 and 23–26 are directed to a mobile device (i.e., machine). Thus, the eligibility analysis proceeds to Step 2A.1.
The limitations of independent claim 12, which is representative of independent claim 1, have been denoted with letters by the Examiner for easy reference. The judicial exception(s) recited in claim 12 are identified in bold below:
A mobile device comprising: a processor; and a computer readable medium, the computer readable medium comprising code, executable by the processor to implement a method comprising:
initiating, by a mobile application stored on the mobile device operated by a first user, communication with an access device operated by a second user in a transaction between the first user and the second user;
transmitting, by the mobile application, a request for transaction data to the access device;
receiving, by the mobile application, the transaction data comprising a transaction amount and a second cryptocurrency address associated with the second user from the access device;
receiving, by the mobile application from a token provider computer, an access token and a private cryptographic key, wherein the access token comprises a payment token associated with a first cryptocurrency address;
signing, by the mobile application using the private cryptographic key, the first cryptocurrency address, the second cryptocurrency address, and the transaction amount to create a signed cryptocurrency transaction;
transmitting, by the mobile application, the signed cryptocurrency transaction to a node of a blockchain network;
receiving, by the mobile application, a cryptocurrency transaction identifier from the node;
generating, by the mobile application, a cryptogram using at least an access token on the mobile application and at least some of the transaction data;
transmitting, by the mobile application, at least the cryptogram, the access token, and the cryptocurrency transaction identifier to the access device, wherein the access device generates an authorization request message in an International Organization for Standard (ISO) 8583 format, comprising the access token, the cryptogram, and the transaction data, requesting authorization for the transaction and transmits the authorization request message to the token provider computer, wherein the token provider computer, responsive to the authorization request message, validates the cryptogram, maps the access token to the first cryptocurrency address, extracts the cryptocurrency transaction identifier from the authorization request message, and queries the node in the blockchain network with the first cryptocurrency address and the cryptocurrency transaction identifier to verify that the mobile application previously transmitted the signed cryptocurrency transaction to the node of the blockchain network, and, based on the verified signed cryptocurrency transaction and validated cryptogram, transmits an authorization response message in the ISO 8583 format approving of the transaction to the access device; thereby causing the transaction amount to be transferred from the first cryptocurrency address to the second cryptocurrency address; and
updating, by the mobile application, a recorded balance by decrementing the transferred transaction amount.
The limitations B–H and J-K under the broadest reasonable interpretation recite initiating a transaction between a first user and second user by receiving transaction data including an amount and addresses of the users, the users signing the transaction, transmitting the signed transaction, effectuating the transaction based on the transmitted information including verification that the transaction had been effectuated by the first user, and updating of the recorded balance by decrementing the transferred transaction amount.. These limitations recite an abstract idea that falls under “certain methods of organizing human activity” because they recite a fundamental economic practice, i.e., a process of transferring funds from one user to another based on executed transaction documents.
The limitations I and J also recite an abstract idea that falls under the mathematical concepts grouping because “generating . . . a cryptogram using at least an access token . . . and at least some of the transaction data” is a mathematical process. The broadest reasonable interpretation of “generating . . . a cryptogram” depends on the broadest reasonable interpretation of “cryptogram,” which is simply a piece of encrypted data. Here, where the “generating” covers any encryption, this step is interpreted as applying math to the transaction data to generate the cryptogram, and therefore is an abstract idea.
Per MPEP 2106.04, examiners should apply the same eligibility analysis to all claims regardless of the number of exceptions recited therein. Unless it is clear that a claim recites distinct exceptions, such as a law of nature and an abstract idea, care should be taken not to parse the claim into multiple exceptions, particularly in claims involving abstract ideas. Accordingly, if possible examiners should treat the claim for Prong Two and Step 2B purposes as containing a single judicial exception. Here, the two abstract ideas identified above are not distinct as the mathematical process operates within the fundamental economic practice to advance the purpose of mitigating risk in settling the economic transaction. Accordingly, claims 1 and 12 are treated as reciting an abstract idea and the analysis proceed to Step 2A.2.
The judicial exception is not integrated into a practical application. In particular, the claim recites the additional elements shown in bold below:
A mobile device comprising: a processor; and a computer readable medium, the computer readable medium comprising code, executable by the processor to implement a method comprising:
initiating, by a mobile application stored on the mobile device operated by a first user, communication with an access device operated by a second user in a transaction between the first user and the second user;
transmitting, by the mobile application, a request for transaction data to the access device;
receiving, by the mobile application, the transaction data comprising a transaction amount and a second cryptocurrency address associated with the second user from the access device;
receiving, by the mobile application from a token provider computer, an access token and a private cryptographic key, wherein the access token comprises a payment token associated with a first cryptocurrency address;
signing, by the mobile application using the private cryptographic key, the first cryptocurrency address, the second cryptocurrency address, and the transaction amount to create a signed cryptocurrency transaction;
transmitting, by the mobile application, the signed cryptocurrency transaction to a node of a blockchain network;
receiving, by the mobile application, a cryptocurrency transaction identifier from the node;
generating, by the mobile application, a cryptogram using at least an access token on the mobile application and at least some of the transaction data; and
transmitting, by the mobile application, at least the cryptogram, the access token, and the cryptocurrency transaction identifier to the access device, wherein the access device generates an authorization request message in an International Organization for Standard (ISO) 8583 format, comprising the access token, the cryptogram, and the transaction data, requesting authorization for the transaction and transmits the authorization request message to the token provider computer, wherein the token provider computer, responsive to the authorization request message, validates the cryptogram, maps the access token to the first cryptocurrency address, extracts the cryptocurrency transaction identifier from the authorization request message, and queries the node in the blockchain network with the first cryptocurrency address and the cryptocurrency transaction identifier to verify that the mobile application previously transmitted the signed cryptocurrency transaction to the node of the blockchain network, and, based on the verified signed cryptocurrency transaction and validated cryptogram, transmits an authorization response message in the ISO 8583 format approving of the transaction to the access device; thereby causing the transaction amount to be transferred from the first cryptocurrency address to the second cryptocurrency address; and
updating, by the mobile application, a recorded balance by decrementing the transferred transaction amount.
The additional elements include computing devices that are recited at a high level of generality, consistent with Applicant’s specification at 0118–121 (“The mobile device 600 may be a phone, a tablet, a payment card, and/or any other suitable device configured for communication with an access device.”); at 0024 (“An ‘access device’ may be any suitable device for providing access to an external computer system.”); and 0027 (“A ‘token provider computer’ can include a system that services tokens.”). Limitation G and J introduces a blockchain network but does not incorporate it such that it acts as more than a general repository for storing information, i.e., transaction ledger. These elements as recited in the claim amount to an instruction to “apply it” on generic computers, or only generally link the abstract idea to a computing environment. The recitation of “cryptocurrency” is a non-functional label for the user addresses and does not impact the abstract idea other than suggesting an environment of use. Limitation E recites a step or function in which the mobile device, via the mobile application, receives information from the token provider computer that is used in the mathematical process noted above, i.e., to generate the cryptogram and effectuate the transaction.
Accordingly, when the additional elements are considered both individual and as an ordered combination in claims 1 and 12, the additional element(s) do not integrate the abstract idea into a practical application because they provide only a general link between the abstract idea and the technical environment, which is generically recited. Therefore, the claim is directed to an abstract idea and the analysis proceeds to Step 2B.
The additional elements, both individually and as an ordered combination, do not amount to significantly more than the judicial exception because when the considerations are reevaluated in Step 2B, there is no change to the analysis. As discussed under Step 2A.2, the additional element(s) amount to no more than providing a general link between the abstract idea and the technical environment. This is not enough to provide an inventive concept. Therefore, claims 1 and 12 are not patent eligible.
Note:
The claim has been amended to describe the function(s) of the access device and that of the token provider computer. The examiner finds that the claim(s) are directed to the step(s) performed by the mobile application in the method claims and particularly the mobile device in the apparatus claims. In other words, the functional recitations of the access device and the token provider computer are outside of the scope of the steps performed by the mobile application in the method claims and outside the scope of the mobile device in the apparatus claims.
Dependent claims 2–4 and 21–22 recite:
[2, 21] wherein the access device transmits the authorization request message to a token provider computer, which validates the cryptogram, maps the access token to the first cryptocurrency address, and extracts the cryptocurrency transaction identifier from the authorization request message.
[3, 22] wherein the token provider computer queries the node in the blockchain network with the first cryptocurrency address and the cryptocurrency transaction identifier to verify that the mobile application previously transmitted the signed cryptocurrency transaction to the node of the blockchain network.
[4] wherein the token provider computer transmits an authorization response message approving of the transaction to the access device after the token provider computer queries the node
which elaborates on the abstract idea identified in claims 1 and 12 as shown by the bold text above. The additional elements in these dependent claims are the same as those identified in the independent claims, and play the same role here as they did in the independent claims, i.e., to generally link the abstract idea to the technological or computing environment. Therefore, claims 2–4 and 21–22 are not patent eligible.
Dependent claims 5–6, 9–10, 23–24, and 26 recite:
[5, 23] wherein the second cryptocurrency address is associated with the second user.
[6, 24] wherein the second cryptocurrency address is associated with a third party service provider that is not the second user.
[9, 26] wherein the first cryptocurrency address and the second cryptocurrency address are public keys.
[10] wherein the request for transaction data is included within a processing options data object list (PDOL) message between the mobile device and the access device.
further recite aspects of the information (first and/or second cryptocurrency address, the request) that elaborate on the information being manipulated in the economic transaction or mathematical process and thereby simply elaborate on the abstract ideas identified above. Claim 10 recites that the information is passed between the mobile device and access device and these additional elements again only provide a general link to the technological environment and do not integrate the abstract idea into a practical application. Therefore, claims 5–6, 9–10, 23–24, and 26 are ineligible.
Dependent claim 7 recites:
[7] wherein the node of the blockchain network verifies the signed cryptocurrency transaction with a public key associated with the mobile application, before sending the cryptocurrency transaction identifier to the mobile application.
The limitations of claim 7 do not positively recite a further method step and therefore do not affect the scope of method claim 1. Under the broadest reasonable interpretation, claim 7 has no impact on the analysis.
Dependent claims 8, 11, and 25 recite:
[8, 25] wherein the mobile device is a mobile phone.
[11] the mobile device is a mobile phone with NFC capability.
As noted above, the mobile device is recited at a high level of generality, and further labeling the device as a mobile phone does not impact that result. Similarly, given that device “NFC” capability without using that capability in any positively recited method step or function of the system does not impact the abstract idea identified above; they continue to generally link the abstract idea to the technological environment. Accordingly, these claims also do not integrate the abstract idea into a practical application and they are ineligible.
Dependent claims 13–14 recite:
[13] further comprising a memory storing a limited-use key, wherein the limited-use key is used to generate the cryptogram.
[14] in the method, responsive to receiving the transaction data, the mobile application performs an authentication process of the first user.
The key used to generate the cryptogram in claim 13 recites the information used to carry out the mathematical process of generating the cryptogram and the role of the mobile device as the generic technological element used to store that information does not integrate the abstract idea into a practical application. The authentication process responsive to receiving the transaction data is also an elaboration on the abstract idea of claim 12, specifically to mitigate risk in the economic transaction by using receiving information to authenticate, which is similar to a notarization process. Again, the role of the mobile application is to generally link this abstract idea to a technological environment and fails to integrate the abstract idea into a practical application. Therefore claims 13 and 14 are ineligible.
In summary, the dependent claims considered both individually and as an ordered combination do not provide meaningful limitations to transform the abstract idea into a patent eligible application of the abstract idea such that the claims amount to significantly more than the abstract idea itself. The claims do not recite an improvement to another technology or technical field, an improvement to the functioning of the computer itself, or provide meaningful limitations beyond generally linking an abstract idea to a particular technological environment. Therefore, the claims are rejected under 35 U.S.C. § 101 as being directed to non-statutory subject matter.
Claim Rejections - 35 U.S.C. § 103
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 C.F.R. 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. § 102(b)(2)(C) for any potential 35 U.S.C. § 102(a)(2) prior art against the later invention.
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 of this title, 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 set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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.
Claims 1, 5–9, 11–14, and 23–26 are rejected under 35 U.S.C. § 103 as being unpatentable over as being unpatentable over Wang (US 2019/0363889 A1) in view of Shastry (US 2016/0036790 A1) in view of Soundararajan (US 2020/0045020 A1) in view of Creamer (US 2004/0122768 A1).
Regarding claims 1 and 12. Wang teaches:
initiating, by a mobile application stored on a mobile device operated by a first user, communication with an access device operated by a second user in a transaction between the first user and the second user [0085 “FIG. 4 shows a diagram of a transaction process according to one embodiment of the invention. According to FIG. 4, user 401 may first initiate a transaction by presenting his endpoint device in S401. For example, user 401 may be at a checkout counter at a merchant, and may use his mobile phone to purchase selected items. Once user 401 has presented his endpoint device 410, user 401 may use endpoint device 410 to generate and send a transaction request S402. For example, user 401 may open an application that generates a transaction request when placed in close proximity to an access device. In another example, user 401 may select a “purchase item” or payment icon displayed on endpoint device 410, which may cause it to generate the transaction”; 0103 ];
transmitting, by the mobile application, a request for transaction data to the access device [0085; 0086 “The transaction request S402 may be sent to and received by access device”];
receiving, by the mobile application, the transaction data comprising a transaction amount from the access device [0086; 0087 “access device 430, which may generate interaction data comprising. . .transaction time stamp, transaction amount, merchant data, product data, terms and conditions, disclaimers, terms of service agreements, and/or any other relevant information. . .The interaction data may then be sent to endpoint device 410 in S403. Endpoint device 410 may receive the interaction data”];
signing, by the mobile application using the private cryptographic key, [. . .] and the transaction amount to create a signed cryptocurrency transaction [0087 “Endpoint device 410 may append user’s electronic identity to the interaction record, and may then sign the interaction record using user’s private key”];
transmitting, by the mobile application, the signed cryptocurrency transaction to a node of a blockchain network; [0030; 0088 “The interaction record may then be sent to access device in S406 so that the resource provider may sign the interaction record with their private key.”; 0104];
generating, by the mobile application, a cryptogram using at least [the] access token on the mobile application and at least some of the transaction data; and [0051 “. . .The signed interaction record may be received by endpoint device. . .be encrypted by application. . .using a dynamic set of data . . .the dynamic set of data. . .to generate a transaction cryptogram during an interaction.”; 0057]; and
transmitting, by the mobile application, at least the cryptogram, the access token, to the access device, wherein the access device generates an authorization request message requesting authorization for the transaction and transmits the authorization request message in an ISO 8583 format comprising the access token, the cryptogram, and the transaction data to [the] token provider computer, thereby causing the transaction amount to be transferred [. . .]. [0057 “Access device 130 may then generate an authorization request message comprising the cryptogram and dynamic set of data, and send it to processing server computer 140”; 0090; Processing server computer 440 may receive the verification response and may proceed with authorization of the transaction if the verification yields positive results. Authorization request may comply with ISO 8583 (0096); If the transaction has been authorized, processing server computer 440 may publish the pending interaction record by appending the interaction record to the block chain/distributed ledger. (0099); ];
wherein the token provider computer responsive to the authorization request message, validates the cryptogram, maps the access token … from the authorization request message [0052; 0057; 0058; 0070; 0082]
As shown above Wang teaches that it was known for the mobile device in a transaction to exchange (i.e., send and receive) relevant information with a processing server computer. That information is crucial to enable the mobile device to be used to carry out a transaction. However, Wang does not explicitly teach (in italics):
receiving, by the mobile application from a token provider computer, [the] access token and a private cryptographic key, wherein the access token comprises a payment token associated with a first cryptocurrency address;
signing, by the mobile application using the private cryptographic key, the first cryptocurrency address, the second cryptocurrency address, and the transaction amount to create a signed cryptocurrency transaction;
receiving, by the mobile application, a cryptocurrency transaction identifier from the node;
thereby causing the transaction amount to be transferred from the first cryptocurrency address to the second cryptocurrency address.
Nonetheless, Shastry—which like the present application is directed to the field of authenticating users within a mobile device transaction—teaches:
receiving, by the mobile application from a token provider computer, [the] access token and a private cryptographic key, wherein the access token comprises a payment token associated with a first cryptocurrency address; [The server computer may validate the identity verification cryptogram using the received user data. That is, the server computer may verify that the received identity verification cryptogram is in fact generated using the received user data. The server computer may provide a second payment token and a second cryptographic key (e.g. a limited use cryptographic key) to the second mobile application. (0018)]
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the information being retrieved from the processing server computer by the mobile device in Wang to specifically retrieve a payment token and cryptographic key as taught by Shastry. One of skill would have been motivated to implement this feature as it would enable to user to provision additional mobile devices to be trusted in transactions such that the same user account can be used to make payments from the user’s mobile phone as well as the user’s table computer (Shastry 0018).
The combination of Wang in view of Shastry does not teach (in italics):
signing, by the mobile application using the private cryptographic key, the first cryptocurrency address, the second cryptocurrency address, and the transaction amount to create a signed cryptocurrency transaction;
receiving, by the mobile application, a cryptocurrency transaction identifier from the node;
maps the access token to the first cryptocurrency address, and extracts the cryptocurrency transaction identifier from the authorization request message and queries the node in the blockchain network with the first cryptocurrency address and the cryptocurrency transaction identifier to verify that the mobile application previously transmitted the signed cryptocurrency transaction to the node of the blockchain network;
thereby causing the transaction amount to be transferred from the first cryptocurrency address to the second cryptocurrency address.
Nonetheless, Soundararajan teaches
receiving, by the mobile application, a cryptocurrency transaction identifier from the node; [0089 “. . .transaction ID may be generated by the agent system 300 and provided to the user device 200; 0093].
signing, by the mobile application using the private cryptographic key, the first cryptocurrency address, the second cryptocurrency address, and the transaction amount to create a signed cryptocurrency transaction; and thereby causing the transaction amount to be transferred from the first cryptocurrency address to the second cryptocurrency address. [0093 “. . .user device 200 may receive a request to verify a first blockchain transaction Tx-B1. . .a secured representation of the blockchain address of agent system 300 (RN1-U2), a secured representation of a location blockchain address (RN-Ll), and the off-chain transaction ID (Tx-id).”]
maps the access token to the first cryptocurrency address, and extracts the cryptocurrency transaction identifier from the authorization request message and queries the node in the blockchain network with the first cryptocurrency address and the cryptocurrency transaction identifier to verify that the mobile application previously transmitted the signed cryptocurrency transaction to the node of the blockchain network and based on verification transmits an authorization response message approving of the transaction to the access device [0084; 0093; 0101; 1019-0114; 0118; 0119; 0121; 0126; 0132];
Therefore, it would have been obvious to one of ordinary skill in the art of cryptocurrency accounts, before the effective filing date of the claimed invention to incorporate information such as transaction ID and specific blockchain addresses for sender and recipient as disclosed by Soundararajan to the blockchain transaction method and system taught by the combination of Wang in view of Shastry above. One of skill in the art would have been motivated to incorporate these features to facilitate enhanced privacy and security in blockchain identity systems.
The combination of Wang in view of Shastry in view of Soundararajan does not teach (in italics): the token provider computer transmits an authorization response message in the ISO 8583 format approving of the transaction to the access device.
Nonetheless, as Wang generally teaches ISO 8583 format in communication between the access device to the server, it would have been obvious to one of ordinary skill in the art before the effective filing of instant claim to utilize any known format in format in sending the authorization response message from the server to the access device as the simple substitution producing predictable result.
The combination of Wang in view of Shastry in view of Soundararajan does not teach updating by the mobile application a recorded balance by decrementing the transferred transaction amount.
Nonetheless, Creamer teaches updating by an application a recorded balance by decrementing the transferred transaction amount [0025, the electronic wallet application also can increment, decrement, and maintain a stored balance …]
Therefore, it would have been obvious to one of ordinary skill in the art of cryptocurrency accounts, before the effective filing date of the claimed invention to incorporate maintaining of the wallet balance as disclosed by Creamer to the blockchain transaction method and system taught by the combination of Wang in view of Shastry in view of Soundararajan above. One of skill in the art would have been motivated to incorporate these features to facilitate enhanced usability in allowing user to be able to see the balance of their wallet.
Note:
The applicant is reminded that the method claim is directed to steps performed by the mobile application. As such, the functional recitations of the access device and the functional recitations of the token provider computer do not move to distinguish over the prior art.
Similarly, the apparatus claim is directed to a mobile device. As such, the functional recitations of the access device and the functional recitations of the token provider computer do not move to distinguish over the prior art.
Regarding claims 5 and 23. The combination of Wang in view of Shastry in view of Soundararajan in view of Creamer teaches the limitations of claims 1 and 12 above. Soundararajan further teaches
wherein the second cryptocurrency address is associated with the second user [0051; 0052].
Note that the entity with which the second cryptocurrency address is associated is intended use and does not distinguish the claim from the prior art. However the examiner has mapped Soundararajan for purposes of compact prosecution. The motivation for incorporate this feature of Soundararajan is the same as provided for claims 1 and 12 above.
Regarding claims 6 and 24. The combination of Wang in view of Shastry in view of Soundararajan in view of Creamer teaches the limitations of claims 1 and 12 above. Soundararajan further teaches
wherein the second cryptocurrency address is associated with a third party service provider that is not the second user [0137].
Note that the entity with which the second cryptocurrency address is associated is intended use and does not distinguish the claim from the prior art. However the examiner has mapped Soundararajan for purposes of compact prosecution. The motivation for incorporate this feature of Soundararajan is the same as provided for claims 1 and 12 above.
Regarding claim 7. The combination of Wang in view of Shastry in view of Soundararajan in view of Creamer teaches the limitations of claim 1 above. Soundararajan further teaches
wherein the node of the blockchain network verifies the signed cryptocurrency transaction with a public key associated with the mobile application, before sending the cryptocurrency transaction identifier to the mobile application [0139; 0140].
Note that the actions of the node of the blockchain network are not part of the system of claim 12 nor does claim 7 positively recite a step of the method of claim 1. Accordingly, claim 7 does not distinguish the claim from the prior art. However the examiner has mapped Soundararajan for purposes of compact prosecution. The motivation for incorporate this feature of Soundararajan is the same as provided for claims 1 and 12 above.
Regarding claims 8, 11, and 25. The combination of Wang in view of Shastry in view of Soundararajan in view of Creamer teaches the limitations of claims 1 and 12 above. Wang further teaches
wherein the mobile device is a mobile phone [0047; 0063].
wherein the mobile device is a mobile phone with NFC capability [0054; 0064; 0073].
Regarding claims 9 and 26. The combination of Wang in view of Shastry in view of Soundararajan in view of Creamer teaches the limitations of claims 1 and 12 above. Soundararajan further teaches
wherein the first cryptocurrency address and the second cryptocurrency address are public keys [0055; 0065].
The motivation for incorporate this feature of Soundararajan is the same as provided for claims 1 and 12 above. Additionally, making the first and second addresses public provides a way for other users to locate and interact with those addresses.
Regarding claim 13. The combination of Wang in view of Shastry in view of Soundararajan in view of Creamer teaches the limitations of claim 12 above. Wang further teaches
a memory storing a limited-use key, wherein the limited-use key is used to generate the cryptogram [0051; 0057].
Regarding claim 14. The combination of Wang in view of Shastry in view of Soundararajan in view of Creamer teaches the limitations of claim 12 above. Wang further teaches:
in the method, responsive to receiving the transaction data, the mobile application performs an authentication process of the first user [0087; 0103].
Claim 10 is rejected under 35 U.S.C. § 103 as being unpatentable over Wang in view of Shasry in view of Soundararajan in view of Creamer, as applied to claim 1 above, and in further view of Cleven (US 2010/0036741 A1).
Regarding claim 10. The combination of Wang in view of Shastry in view of Soundararajan in view of Creamer teaches the limitations of claim 1 above. Wang in view of Shastry in view of Soundararajan in view of Creamer does not explicitly teach wherein the request for transaction data is included within a processing options data object list (PDOL) message between the mobile device and the access device.
Nonetheless, Cleven—which like the present invention is directed to transaction processing at point-of-sale terminals—teaches:
wherein the request for transaction data is included within a processing options data object list (PDOL) message between the mobile device and the access device [0044 “an EMV transaction is initiated and if the Integrated Circuit Card (ICC) of the CCPTPD requires terminal resident data to initiate the financial transaction, it will communicate a list of data elements using an EMV-specified data element list ( e.g., the EMV Processing Options Data Object List (PDOL) ).”; 0047].
Therefore, it would have been obvious to one of ordinary skill in the art of digital payments, before the effective filing date of the claimed invention, to integrate the method and system as disclosed by Cleven into the transaction process taught by the combination of Wang, Shasry, and Soundararajan in view of Creamer above to rely on an industry standard technique so that the process can be more universally applicable.
Response to Remarks
The applicant’s arguments in the Amendment have been considered but not persuasive as to the 101 and prior art rejections. Detailed response follows.
On page 9 applicant argues that:
Similarly, here, the Examiner improperly abstracts Applicant’s detailed claims … at an improperly high level of abstraction, untethered from the language of the claims.”
The examiner respectfully disagrees. MPEP 2106.04(a) states:
Examiners should determine whether a claim recites an abstract idea by (1) identifying the specific limitation(s) in the claim under examination that the examiner believes recites an abstract idea, and (2) determining whether the identified limitations(s) fall within at least one of the groupings of abstract ideas listed above.
The rejection establishes that the claim recites an abstract idea by identifying the language in the claim that recites the abstract ideas and then determining which grouping those abstract ideas fall under. As courts have done many times by restating the abstract idea in the claim in a concise manner, the rejection simply provides a short statement to characterize the identified recitations. This is not an overgeneralization or “improperly high level of abstraction” and follows the analytical framework, examples, and court cases. Accordingly, as shown in the reformatted rejection above, the examiner maintains that the claims recite an abstract idea.
On page 10-12, applicant argues that: “the claim techniques improve the functioning of the computing system and the overall process. Accordingly, the claimed steps integrate practical application”.
The examiner respectfully disagrees as the claim does not improve upon the mobile device performing the positively recited step(s) nor the blockchain technology. There is no indication that the claim provides faster or efficient means the way the blockchain works. For example, the blockchain would still require 10 minutes in ledgering of the transaction regardless of the claimed process.
Furthermore, the present invention is not “necessarily rooted in computer technology” as it closely follows, as shown in the rejection, a financial transaction that includes elements of mitigating risk. The technological aspects of the claim are not integral to this process but instead merely provide an environment in which that transaction takes place. This is qualitatively different from and distinguishable from the facts in DDR Holdings.
Additionally, the remarks above do not provide an alternative analysis of the claim to show the applicant’s findings as to where the abstract idea is recited and thereby do not provide an alternative viewpoint of what the additional elements of the claim are. Therefore, the examiner is not inclined to reconsider the analysis provided in the rejection at this time.
Finally, the assertion that the claims provide a technological improvement because it allows for many cryptocurrencies to be used for payments at a point-of-sale without the need to update hardware or software is not persuasive. Again, this assertion is disconnected from any identification of additional elements of the claim to establish that this alleged improvement arises from the claim language itself. It is therefore a general allegation that lacks a nexus to the claim or eligibility analysis and is not persuasive.
On pages 12–13, applicant argues
The applicant asserts that there should be a change to the analysis, because step 2B considers the presence of unconventional operations and/or components.
The examiner respectfully disagrees. Evaluation of additional elements under MPEP 2106.05(d) is not necessary for the present claims in which the additional elements are fully characterized by the principles of MPEP 2106.05(h). Put differently, because none of the additional elements were identified as insignificant extra-solution activity at Step 2A, prong 2, there is no requirement to reevaluate elements and provide evidence of well-understood, routine, and conventional at Step 2B. The rejection does not identify any computer functions outside of the abstract idea that are “well‐understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity.” MPEP 2106.05(d)(II). Therefore, no evidence is needed to support that assertion.
Regards to the 103 rejections, the rejection has been updated as described above in the 103 rejection. Furthermore, the claim amendments mainly focus on the functional recitations of the access device and the token provider computer. The applicant is reminded that the method claim is directed to steps performed by the mobile application. As such, the functional recitations of the access device and the functional recitations of the token provider computer do not move to distinguish over the prior art. Similarly, the apparatus claim is directed to a mobile device. As such, the functional recitations of the access device and the functional recitations of the token provider computer do not move to distinguish over the prior art.
Relevant Prior Art Not Relied Upon
The prior art made of record and not relied upon is considered pertinent to Applicant’s disclosure. The additional cited art, including but not limited to the excerpts below, further establishes the state of the art at the time of Applicant’s invention and shows the following was known:
Mokhasi: discloses a dynamic cryptocurrency aliasing that assigns alias to a cryptocurrency address for each transaction and/or after a predetermined amount of time elapsed;
Dowling: discloses anonymizing of customer’s account that points to the customer’s account wallet address.
Kinagi: discloses tokenization/de-tokenization and use of cryptogram in performing transactions.
Gyllenram: An automotive payment method and system, including: at a cloud system, generating a payment token, signing the payment token using a cloud private key, and sending the payment token to a vehicle system; at the vehicle system, receiving the payment token, signing the payment token using a vehicle private key, and sending the payment token to a mobile device system; and, at the mobile device system, receiving the payment token and sending the payment token to the cloud system to exchange the payment token for a payment to a third party payee that is debited from a ledger associated with the vehicle system in the cloud system. Optionally, the payment to the third party payee is made by, at the cloud system, receiving the payment token from the mobile device system and sending a virtual credit card to the mobile device system that is provided to the third party payee.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to STEVEN S KIM whose telephone number is (571)270-5287. The examiner can normally be reached Monday -Friday: 7:00 - 3:30.
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.
/STEVEN S KIM/Primary Examiner, Art Unit 3698