DETAILED ACTION
The present application is being examined under the first inventor to file provisions of the AIA .
This Office Action is in response Applicant communication filed on 8/12/2026.
Claims
Claims 1, 3-5, 7, and 8 have been amended.
Claims 1-8 are currently pending in the application.
Information Disclosure Statements
The Information Disclosure Statement (IDS) that was filed on 10/7/2026 has been considered.
Response to Arguments
Objections
The previous rejections are withdrawn due to the claim amendments.
103
In Applicant’s arguments with respect to claim 1 have been considered but are moot because the prior art rejections are based on a new combination of references as necessitated by the applicant’s amendments to the claims.
Rejections under 35 § U.S.C. 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 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.
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 CFR 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.
Claims 1-3 and 5-7 are rejected under 35 U.S.C. 103 as being unpatentable over US 20160117651 A1 (“Davis”) and US 10043174 B1 (“Chikkanna”) and US 20190356641 A1 (“Isaacson”).
Per claims 1 and 5, Davis discloses:
receiving, by the processor, a first user input comprising a natural language transfer command via a conversation interface of the first digital wallet (e.g. According to some embodiments, the message analyzer 212 can analyze natural language. In particular, a user can communicate with one or more other users using natural language phrases in electronic messages. By using natural language detection, the message analyzer 212 can interpret the content of the messages to the other users. If the user sends a request to initiate a payment transaction using natural language, the message analyzer 212 can infer the request from the natural language and provide the option to initiate the payment transaction. Additionally or alternatively, the message analyzer 212 can provide an option to complete an initiated payment transaction) (Section [0095], [0227], and Figs 4C-4H);
parsing the natural language transfer command to identify a recipient and digital asset amount (e.g. While analyzing the messages between the sender and the recipient, the message analyzer 212 can interpret natural language in the messages corresponding to a payment event. Specifically, the messages can include an intention by either the sender or the recipient to initiate a payment transaction using natural language. The message analyzer 212 can interpret the natural language using natural language processing to determine the payment event rather than by performing a rigid, predetermined sequence of operations for initiating and processing the payment transaction. To illustrate, the message analyzer 212 can determine from the messages between the sender and recipient that the recipient is requesting $75 from the sender as a payment event) (Section [0091], [0095], [0227], [0271], and [0272]);
identifying a second digital wallet associated with the recipient… (e.g. To complete a transaction, the payment manager 236 can access or obtain a payment credential for the recipient (such as deposit account information, debit card, credit card, gift card, electronic wallet) and (e.g. After the payment manager 236 receives the payment information, the payment manager 236 can identify the recipient. The payment manager 236 can lookup the recipient in the user profile database 240 to determine if the recipient has registered a payment credential. At this point, the payment manager 236 can initiate the transaction) (Section [0109]-[0111]).
Although Davis discloses an integrated messaging and electronic payment system which parses natural language messages to identify the intent to perform a payment transaction between user wallets, Davis does not specifically disclose:
receiving, by a processor, login credentials from a first user device;
verifying, by the processor, whether the login credentials match login information associated with a first digital wallet;
upon verifying the login credentials, logging the first user device into the first digital wallet;
storing, by the processor, a digital asset balance associated with the first digital wallet in a data store connected to the processor, wherein the data store stores a public key or public address associated with the first digital wallet and does not store a private key associated with the first digital wallet;
…including retrieving a public address associated with the recipient;
constructing, by the processor, based on the parsed natural language transfer command, the public address associated with the recipient, and the digital asset amount, a raw transfer transaction for transferring the digital asset amount to the second digital wallet via the distributed ledger network;
causing, by the processor, the raw transfer transaction to be cryptographically signed using the private key associated with the first digital wallet and stored locally on the first user device;
causing, by the processor, the cryptographically signed raw transfer transaction to be recorded on the distributed ledger network to transfer the digital asset amount form the first digital wallet to the second digital wallet.
However Chikkanna, in analogous art of sending payments via a messaging service, discloses:
receiving, by a processor, login credentials from a first user device (e.g. receiving, by the payment service from the user, an account access request to process the payment associated with the account, wherein the account access request comprises the identifier of the mobile device and the password assigned to the account, validating the account access request based on the identifier of the mobile device and the password assigned to the account, and allowing, in response to the validating, the user to access the account or processing the payment) (Column 2, Ln 27-44);
verifying, by the processor, whether the login credentials match login information associated with a first digital wallet (e.g. receiving, by the payment service from the user, an account access request to process the payment associated with the account, wherein the account access request comprises the identifier of the mobile device and the password assigned to the account, validating the account access request based on the identifier of the mobile device and the password assigned to the account, and allowing, in response to the validating, the user to access the account or processing the payment) (Column 2, Ln 27-44);
upon verifying the login credentials, logging the first user device into the first digital wallet (e.g. receiving, by the payment service from the user, an account access request to process the payment associated with the account, wherein the account access request comprises the identifier of the mobile device and the password assigned to the account, validating the account access request based on the identifier of the mobile device and the password assigned to the account, and allowing, in response to the validating, the user to access the account or processing the payment) (Column 2, Ln 27-44);
storing, by the processor, a digital asset balance associated with the first digital wallet in a data store connected to the processor… (e.g. In one or more embodiments of the invention, the payment service (130) includes software and/or hardware components with the functionality to perform payment tasks based on financial accounts maintained by the payment service (130). Specifically, each individual financial account is maintained by the payment service (130) for recording a balance and deposit/withdrawal activities of the account holder. In one or more embodiments, the balance and deposit/withdrawal activities are based on a non-fungible financial property, such as a virtual currency. In such embodiments, the non-fungible financial property may be the virtual currency created, transferred, and tracked in the peer-to-peer virtual currency network (120). In other embodiments, the balance and deposit/withdrawal activities may be based on a real currency, such as the U.S. dollar) (Column 5, Ln 64 – Column 6, Ln 27).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the messaging/mobile wallet application of Davis to require the use of login credentials to access the messaging/wallet payment application, as taught by Chikkanna, in order to achieve the predictable result of increasing security of the application by requiring information that only the owner would know in order to access the wallet.
Although Davis/Chikkanna discloses logging into a digital wallet and using an integrated messaging and electronic payment system which parses natural language messages to identify a payment amount and recipient for a transaction using digital wallets, Davis/Chikkanna does not specifically disclose:
…wherein the data store stores a public key or public address associated with the first digital wallet and does not store a private key associated with the first digital wallet;
…including retrieving a public address associated with the recipient;
constructing, by the processor, based on the parsed natural language transfer command, the public address associated with the recipient, and the digital asset amount, a raw transfer transaction for transferring the digital asset amount to the second digital wallet via the distributed ledger network;
causing, by the processor, the raw transfer transaction to be cryptographically signed using the private key associated with the first digital wallet and stored locally on the first user device;
causing, by the processor, the cryptographically signed raw transfer transaction to be recorded on the distributed ledger network to transfer the digital asset amount form the first digital wallet to the second digital wallet.
However Isaacson, in analogous art of performing cryptocurrency payments using context from a messaging conversation, discloses:
…wherein the data store stores a public key or public address associated with the first digital wallet and does not store a private key associated with the first digital wallet (e.g. A lightweight client is a standalone email client that connects to a mail server for access to a mailbox. It would store the user's bitcoins, but it needs a third-party-owned server to access the network and make the transaction. Lightweight clients consult a full client to send and receive transactions without requiring a local copy of the entire blockchain (see simplified payment verification—SPV). This makes lightweight clients much faster to set up and allows them to be used on low-power, low-bandwidth devices such as smartphones. When using a lightweight wallet however, the user must trust the server to a certain degree. When using a lightweight client, the server cannot steal bitcoins, but it can report faulty values back to the user. With both types of software wallets, the users are responsible for keeping their private keys in a secure place) and (e.g. here are a number of ways in which payments can be carried out depending on the structure of the cryptocurrency wallet, such as whether the user needs to choose a cryptocurrency as in Coinbase or whether the wallet only carries a single cryptocurrency, such as a social media-based cryptocurrency. For example, if the user has a Coinbase account, and they select bitcoin as their cryptocurrency, the payment request API and/or payment handler API could be used to navigate behind the scenes into coinbase.com, and essentially drill down to a deep link into their bitcoin wallet and interact with the wallet with the data provided about the bitcoin amount, the recipient address, whether it is a public key or an email address that is used, and even enter in the optional message and commit the transaction) (Sections [0112]-[0114] and [0148]); Note: here Isaacson discloses that a wallet account such as a Coinbase account can contain information including a public key for the wallet. Further Isaacson discloses that various types of wallets can be used such as a lightweight wallet were the user would need to securely store their own private key.
…including retrieving a public address associated with the recipient (e.g. A method can include integrating a cryptocurrency wallet into an application, integrating functionality of both the cryptocurrency wallet and the application, presenting objects for interaction by a user of the application, the objects associated with the functions of the cryptocurrency wallet and the objects presented in the context of the application, receiving an interaction with an object from a user, identifying a recipient of value, the recipient either being in a communication (such as a messaging dialog) with the user or being selected by the user and the recipient being registered with the application, coordinating, by the application, a transfer of value from the user to the recipient within the context of the application. In other words, the user does not have to transition to a cryptocurrency wallet to transfer the value. A record of the transaction of the transfer of value is handled as part of a new block in a blockchain system as described herein. The application can automatically identify the giver and the recipient of the value based on a social media communication context, such as two or more users in a messaging dialog) and (e.g. The following is an example of a Bitcoin transaction. Assume Alice (the buyer) wants to use her Bitcoin to buy pizza from Bob (the seller). She would send him, through her bitcoin wallet, her private “key,” a private sequence of letters and numbers, which contains her source transaction of the coins, an amount, and Bob's digital wallet address. Bob's “address” would be another public sequence of letters and numbers. The transaction thus has three pieces of information: An input, which is a record of which bitcoin address was used to send the bitcoins to Alice in the first place (she received them from her friend, Eve); the amount, which is the amount of bitcoins that Alice is sending to Bob; and an output, which is Bob's bitcoin address) (Sections [0019], [0086], and [0138]);
constructing, by the processor, based on the parsed natural language transfer command, the public address associated with the recipient, and the digital asset amount, a raw transfer transaction for transferring the digital asset amount to the second digital wallet via the distributed ledger network (e.g. A method can include integrating a cryptocurrency wallet into an application, integrating functionality of both the cryptocurrency wallet and the application, presenting objects for interaction by a user of the application, the objects associated with the functions of the cryptocurrency wallet and the objects presented in the context of the application, receiving an interaction with an object from a user, identifying a recipient of value, the recipient either being in a communication (such as a messaging dialog) with the user or being selected by the user and the recipient being registered with the application, coordinating, by the application, a transfer of value from the user to the recipient within the context of the application. In other words, the user does not have to transition to a cryptocurrency wallet to transfer the value. A record of the transaction of the transfer of value is handled as part of a new block in a blockchain system as described herein. The application can automatically identify the giver and the recipient of the value based on a social media communication context, such as two or more users in a messaging dialog) and (e.g. The BTC wallet of FIG. 5 enables a person to identify the recipient either by wallet address 502, or by their email address 504. Being in a social media context can also automatically identify the parties to a transaction. FIG. 5 illustrates using the wallet address and the recipient field 506. The user has chosen to withdraw money from their BTC wallet as is shown in field 508. The amount in dollars is shown in 510 as well as in bitcoin in field 512) and (e.g. One benefit of using the payment request API is that the interface, as is shown in FIG. 5 can include prepopulated fields such as the recipient address 506 and the dollar amount 510 and as well as the bitcoin amounts 512) (Sections [0138], [0141], and [0142]);
causing, by the processor, the raw transfer transaction to be cryptographically signed using the private key associated with the first digital wallet and stored locally on the first user device (e.g. The secure element can be embedded in a near field communication (NFC) chip on a device. This number is completely unique to the user device and to the credit and debit cards (or cryptocurrency or other forms of payment) associated with it. For example, a secure element can store a private key which is accessed and used to sign a transaction from a giver to a recipient (from and to their respect wallets) all within a social media entity, i.e., without leaving the social media entity) (Section [0168]).
causing, by the processor, the cryptographically signed raw transfer transaction to be recorded on the distributed ledger network to transfer the digital asset amount form the first digital wallet to the second digital wallet (e.g. An API could be developed between the application and a cryptocurrency wallet or separately to a blockchain network to enable the recordation on the blockchain of a transaction or transfer of value from one user to another user) (Sections [0015], [0086], [0138], and [0213]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the natural language parsing of the messaging/mobile wallet application of Davis/Chikkanna to identify blockchain wallet addresses to be used to perform cryptocurrency payment transactions based on the context of the message conversation between users, as taught by Isaacson, in order to achieve the predictable result of providing convenience to the user by allowing them to easily perform cryptocurrency wallet transactions without having to open their electronic wallet.
Per claims 2 and 6, Davis/Chikkanna/Isaacson discloses all the limitations of claims 1 and 5 above. Chikkanna further discloses:
wherein the login credentials comprise a username and password combination (e.g. receiving, by the payment service from the user, an account access request to process the payment associated with the account, wherein the account access request comprises the identifier of the mobile device and the password assigned to the account, validating the account access request based on the identifier of the mobile device and the password assigned to the account, and allowing, in response to the validating, the user to access the account or processing the payment) (Column 2, Ln 27-44). Note: although Chikkanna discloses the use of a mobile device identifier and password instead of a username and password, the mobile device identifier of Chikkanna is functionally no different than a username and is used the same way as a username which is to authenticate a user to access their account.
The motivation to combine Chikkanna with Davis/Isaacson is disclosed above with reference to claims 1 and 5.
Per claims 3 and 7, Davis/Chikkanna/Isaacson discloses all the limitations of claims 1 and 5 above. Chikkanna further discloses:
wherein parsing the natural language transfer command comprises extracting parts of speech representing an action and data for the transfer and generating key-value pairs representing the extract action and data, wherein the key-value pairs are used in constructing the raw transfer transaction (e.g. Specifically, the text message (352) includes the keyword @bitsy.pay which requests to make a payment to a payee identified by the mobile phone number “919988776655” following the keyword @bitsy.pay. In particular, the payment amount is specified by the numerals “500” following the payee's mobile phone number. In this example, the payee is a registered user of the payment service. Accordingly, the notification text message (353) notifies the payer that 500 satoshis has been sent to the specified payee. In addition, the notification text message (353) includes the current balance of the virtual payer account after the payment amount is debited) (Column 11 Ln 55 – Column 12, Ln 3 and Fig. 3.5).
The motivation to combine Chikkanna with Davis/Isaacson is disclosed above with reference to claims 1 and 5.
Claims 4 and 8 are rejected under 35 U.S.C. 103 as being unpatentable over Davis/Chikkanna/Isaacson, as applied to claims 1 and 5 above, in further view of US 20090099961 A1 (“Ogilvy”).
Per claims 4 and 8, Although Davis/Chikkanna/Isaacson disclose performing a cryptocurrency transaction using blockchain wallets based on context from user messages, Davis/Chikkanna/Isaacson does not specifically disclose:
wherein before causing the cryptographically signed raw transfer transaction to be recorded on the distributed ledger network, the processor requests a confirmation code from a second user device associated with the recipient and causes the digital asset transfer to be completed only in response to receiving a correct confirmation code form the second user device.
However Ogilvy, in analogous art of processing transactions, discloses:
wherein before causing the cryptographically signed raw transfer transaction to be recorded on the distributed ledger network, the processor requests a confirmation code from a second user device associated with the recipient and causes the digital asset transfer to be completed only in response to receiving a correct confirmation code form the second user device (e.g. The device of the payee may request a PIN or other biometric to confirm the transaction) (Section [0192]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the cryptocurrency payment transaction of Davis/Chikkanna/Isaacson to require the use of a confirmation pin to be entered into the payee device, as taught by Ogilvy, in order to increase the security of the cryptocurrency payment by allowing the recipient to verify the transaction.
Non-Statutory Double Patenting Rejection
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP §§ 706.02(l)(1) - 706.02(l)(3) for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 1-3 and 5-7 are provisionally rejected on the grounds of nonstatutory double patenting as being unpatentable over claims 1 and 8 of pending application 18/219,353 in further view of US 10043174 B1 (“Chikkanna”). Although the claims at issue are not identical, they are not patentably distinct from each other because:
Per claims 1 and 5, pending application 18/219,353 discloses:
storing, by the processor, a digital asset balance associated with the first digital wallet in a data store connected to the processor, wherein the data store stores a public key or public address associated with the first digital wallet and does not store a private key associated with the first digital wallet (e.g. storing, by the processor, credential information associated with the digital wallet, including a public key uniquely associated with the digital wallet; storing, by the first user device, a private key for the digital wallet locally on the first user device, wherein the private key is not stored in the data store) (Claims 1 and 8);
receiving, by the processor, a first user input comprising a natural language transfer command via a conversation interface of the first digital wallet (e.g. receiving, by the processor via the conversation interface rendered on a client application of a first user device, a natural language input comprising a transfer request…) (claims 1 and 8);
parsing the natural language transfer command to identify a recipient and digital asset amount (e.g. analyzing, by the processor, the natural language transfer command using one or more speech analysis techniques to: extract one or more parts of speech from the natural language transfer command; extract a transfer intent and a recipient identifier form the one or more parts of speech; and extract a value from the numerical asset quantity) (Claims 1 and 8);
identifying a second digital wallet associated with the recipient, including retrieving a public address associated with the recipient (e.g. retrieving, by the processor, a public address associated with the second user by executing a @map protocol, wherein the @map protocol…; retrieving the public address based on the @name notation, wherein the public address comprises a wallet address for the second user) (Claims 1 and 8);
constructing, by the processor, based on the parsed natural language transfer command, the public address associated with the recipient, and the digital asset amount, a raw transfer transaction for transferring the digital asset amount to the second digital wallet via a distributed ledger network (e.g. constructing, by the processor, a raw transfer transaction using the extracted transfer intent, the extracted value, and the retrieved public address) (Claim 1 and 8);
causing, by the processor, the raw transfer transaction to be cryptographically signed using the private key associated with the first digital wallet and stored locally on the first user device (e.g. executing, by the first user device, a signing operation on the raw transfer transaction using the locally stored private key to generate a signed transaction) (Claims 1 and 8);
causing, by the processor, the cryptographically signed raw transfer transaction to be recorded on the distributed ledger network to transfer the digital asset amount from the first digital wallet to the second digital wallet (e.g. transmitting the signed transaction for recording to ta cryptographic ledger) (Claim 1 and 8).
Although claims 1 and 8 of pending application 18/219,353 disclose parsing natural language in a chat to perform a transaction to a wallet address, claims 1 and 8 of pending application 18/219,353 do not specifically recite:
receiving, by a processor, login credentials from a first user device;
verifying, by the processor, whether the login credentials match login information associated with a first digital wallet;
upon verifying the login credentials logging the first user device into the first digital wallet.
However Chikkanna, in analogous art of sending payments via a messaging service, discloses:
receiving, by a processor, login credentials from a first user device (e.g. receiving, by the payment service from the user, an account access request to process the payment associated with the account, wherein the account access request comprises the identifier of the mobile device and the password assigned to the account, validating the account access request based on the identifier of the mobile device and the password assigned to the account, and allowing, in response to the validating, the user to access the account or processing the payment) (Column 2, Ln 27-44);
verifying, by the processor, whether the login credentials match login information associated with a first digital wallet (e.g. receiving, by the payment service from the user, an account access request to process the payment associated with the account, wherein the account access request comprises the identifier of the mobile device and the password assigned to the account, validating the account access request based on the identifier of the mobile device and the password assigned to the account, and allowing, in response to the validating, the user to access the account or processing the payment) (Column 2, Ln 27-44);
upon verifying the login credentials, logging the first user device into the first digital wallet (e.g. receiving, by the payment service from the user, an account access request to process the payment associated with the account, wherein the account access request comprises the identifier of the mobile device and the password assigned to the account, validating the account access request based on the identifier of the mobile device and the password assigned to the account, and allowing, in response to the validating, the user to access the account or processing the payment) (Column 2, Ln 27-44).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the messaging/mobile wallet payment application of pending application 18/219,353 to require the use of login credentials to access the messaging/wallet payment application, as taught by Chikkanna, in order to achieve the predictable result of increasing security of the application by requiring information that only the owner would know in order to access the wallet.
Per claims 2 and 6, Chikkanna further discloses:
wherein the login credentials comprise a username and password combination (e.g. receiving, by the payment service from the user, an account access request to process the payment associated with the account, wherein the account access request comprises the identifier of the mobile device and the password assigned to the account, validating the account access request based on the identifier of the mobile device and the password assigned to the account, and allowing, in response to the validating, the user to access the account or processing the payment) (Column 2, Ln 27-44).
Per claims 3 and 7, pending application 18/219,353 further discloses:
parsing the natural language transfer command comprises extracting parts of speech representing an action and data for the transfer and generating key-value pairs representing the extracted action and data, wherein the key-value pairs are used in constructing the raw transfer transaction (e.g. retrieving, by the processor, a public address associated with the second user by executing a @map protocol, wherein the @map protocol…; retrieving the public address based on the @name notation, wherein the public address comprises a wallet address for the second user) and (e.g. constructing, by the processor, a raw transfer transaction using the extracted transfer intent, the extracted value, and the retrieved public address) (Claim 1 and 8).
Claims 4 and 8 are provisionally rejected on the grounds of nonstatutory double patenting as being unpatentable over pending application 18/219,353 and Chikkanna, as applied to claims 1-3 and 5-7 above, in further view of US 20090099961 A1 (“Ogilvy”).
Per claims 4 and 8, Although pending application 18/219,353 and Chikkanna disclose performing a cryptocurrency transaction using blockchain wallets based on context from user messages, pending application 18/219,353 and Chikkanna does not specifically disclose:
wherein before causing the cryptographically signed raw transfer transaction to be recorded on the distributed ledger network, the processor requests a confirmation code from a second user device associated with the recipient and causes the digital asset transfer to be completed only in response to receiving a correct confirmation code form the second user device.
However Ogilvy, in analogous art of processing transactions, discloses:
wherein before causing the cryptographically signed raw transfer transaction to be recorded on the distributed ledger network, the processor requests a confirmation code from a second user device associated with the recipient and causes the digital asset transfer to be completed only in response to receiving a correct confirmation code form the second user device (e.g. The device of the payee may request a PIN or other biometric to confirm the transaction) (Section [0192]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the cryptocurrency payment transaction of pending application 18/219,353 and Chikkanna to require the use of a confirmation pin to be entered into the payee device, as taught by Ogilvy, in order to increase the security of the cryptocurrency payment by allowing the recipient to verify the transaction.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry of a general nature or relating to the status of this application or concerning this communication or earlier communications from the Examiner should be directed to TIMOTHY SAX whose telephone number is 571-272-2935. The Examiner can normally be reached on M-F 8-4:30. If attempts to reach the examiner by telephone are unsuccessful, the Examiner’s supervisor, Patrick McAtee can be reached at (571) 272-7575.
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.
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.
/TPS/
Examiner, Art Unit 3698
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698
