DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013 is being examined under the AIA first inventor to file provisions.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 06/11/2026 has been entered.
Status of Claims
The following is a Non-Final Office Action in response to Applicant’s amendments filed on 06/11/2026.
a. Claims 1, 10, 18 are amended
Overall, Claims 1-20 are pending and have been considered below.
Claim Rejections - 35 USC § 103
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 (i.e., changing from AIA to pre-AIA ) 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.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or non-obviousness.
Claims 1, 6, 10, 13, 15 are rejected under 35 U.S.C. 103 as being unpatentable over Upadhye (US 20230230067 A1) in view of Matheson (US 20230079195 A1), in further view of Ortiz (US 11354651 B2), in further view of Raleigh (US 20200045519 A1).
Regarding Claims 1, 10. Upadhye discloses:
one or more processors; and [(0021) the computing device 102 includes at least one processor 108, a memory 104 that includes the computer-executable instructions 106, and a user interface 110.]
non-transitory computer-readable media storing computer-executable instructions that, when executed by the one or more processors, cause the one or more processors to perform operations comprising: [(0021) the computing device 102 includes at least one processor 108, a memory 104 that includes the computer-executable instructions 106, and a user interface 110.]
receiving input data requesting to register a wallet identification (ID) associated with a user; [(0038) the consumer wallet includes a client-side interface of the virtual wallet server 203. The consumer, or virtual, wallet application enables a user to input, remove, update]
determining an entity associated with wallet (ID); [ (0041) the digitization platform 205 interfaces with the virtual wallet server 203 and a third-party business entity 209 to process a transaction via the ID token 207, update personal data of a user of the virtual wallet server 203 with the third-party business entity 209 via the ID token 207, or instruct the third-party business entity 209 to recycle personal data associated with the ID token 207]
Upadhye discloses inputting information associated with the user, however, Upadhye does not disclose:
receiving a blind query from a third-party regarding a transaction between the user and the third-party, the blind query including an indication of the wallet ID and transaction information associated with the transaction;
determining the user associated with the wallet ID based at least in part on referencing a wallet ID database;
sending an approval request to an electronic device associated with the user, wherein the approval request includes at least a portion of the transaction information associated with the transaction and is configured to cause a selectable option to approve or disapprove the transaction to be presented automatically on a user interface of the electronic device as a notification such that the electronic device is woken up from a sleep mode and the notification is presented to the user on top of an existing application being accessed by the user at the time the approval request was received;
receiving a response to the approval request from the electronic device associated with the user;
determining a verification status associated with the transaction based at least in part on referencing the wallet ID database and the response to the approval request; and
sending a message to the third-party indicating the verification status.
Nonetheless, Matheson analogous in art uses computer program to determine information associated with the user, discloses:
receiving a blind query from a third-party regarding a transaction between the user and the third-party, the blind query including an indication of the wallet ID and transaction information associated with the transaction; [(0066) The DB memory 322 of the platform database 314 may contain the recipient data records, transaction data records, and/or merchant data records. The platform server 312 may issue queries to the platform database 314 and updates based upon, for example, merchant transaction records or new user records (e.g., new buyer, new recipient) of the ecommerce platform 310. The platform database 314 further stores various types of data received from customer devices 302 or merchant servers 304. The DB memory 322 of the platform database 314 may store various types of information about the customers, merchants, and transactions (i.e., transaction information), which the platform server 312 or merchant server 304 may access when performing certain operations. The platform server 312 may query the customer's wallet (or other nodes of the system 300) to determine whether the customer's wallet contains the particular store access tokens 354 (i.e., wallet ID), as indicated by the confirmation query.]
determining the user associated with the wallet ID based at least in part on referencing a wallet ID database; [(0071) The platform server 312 may query the customer's wallet (or other nodes of the system 300) to determine whether the customer's wallet contains the particular store access tokens 354 (i.e., wallet ID), as indicated by the confirmation query. The platform server 312 may send a response to the merchant server 304 indicating whether the customer's wallet contains the particular store access tokens 354, triggering the merchant server 304 to grant or deny access to product (reads on: determine if the user’s wallet proper authorization based on the store access token (i.e., wallet ID)) webpages accordingly.]
determining a verification status associated with the transaction based at least in part on referencing the wallet ID database and the response to the approval request; and [(0071) The platform server 312 may query the customer's wallet (or other nodes of the system 300) to determine whether the customer's wallet contains the particular store access tokens 354 (i.e., wallet ID), as indicated by the confirmation query. The platform server 312 may send a response to the merchant server 304 indicating whether the customer's wallet contains the particular store access tokens 354, triggering the merchant server 304 to grant or deny access to product (reads on: determine if the user’s wallet proper authorization based on the store access token (i.e., wallet ID)) webpages accordingly.]
Note: Applicant’s specification recites “At block 220, the process 200 may include the registry system sending a verification status to the third-party marketplace system 124 and at block 222, the process may include the third-party marketplace system 124 receiving the verification status. For example, once the wallet ID has been verified by the registry system and/or the registry system receives approval from the user, the registry system may send an indication to the third-party marketplace and/or a purchaser indicating a verification of the legitimacy of the wallet ID and/or the wallet to be used in the transaction.” (See paragraph 0066). Additionally, the Matheson reference discloses verifying if the customer’s wallet contain the particular wallet access token (i.e., the appropriate wallet ID). And, based on wallet access token, access can be granted or denied. One of skill in the art can conclude based on the applicant’s specification, and the Matheson reference that determining verification status to determine its legitimacy is similar to granting/denying access based on the particular wallet access token. (See Matheson paragraphs 0071)
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Upadhye to include the elements of Matheson. One would have been motivated to combine the steps of authentication in Matheson using the user’s wallet in Upadhye, in order to verify if the user has proper authorization. Upadhye discloses registering a wallet. Matheson teaches querying to determine transaction information. Moreover, since the elements disclosed by Upadhye, as well as Matheson would function in the same manner in combination as they do separately, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Upadhye/Matheson.
The above combination of Upadhye in view of Matheson discloses determining user with, however, the above combination of Upadhye, Matheson does not disclose:
sending an approval request to an electronic device associated with the user, wherein the approval request includes at least a portion of the transaction information associated with the transaction and is configured to cause a selectable option to approve or disapprove the transaction to be presented automatically on a user interface of the electronic device as a notification such that the electronic device is woken up from a sleep mode and the notification is presented to the user on top of an existing application being accessed by the user at the time the approval request was received;
receiving a response to the approval request from the electronic device associated with the user;
sending a message to the third-party indicating the verification status.
However, Ortiz analogous in art uses device to verify the user, discloses:
sending an approval request to an electronic device associated with the user [(10/13-17) in response to being queried by the merchant application, in some cases, a virtual wallet application may cause presentation on an output screen of the requesting communication device of a user interface soliciting authorization to proceed (a 'prompt' for confirmation of authorization).]
wherein the approval request includes at least a portion of the transaction information associated with the transaction [see at least Figs. 14B-14E and (42/8-17) a user 190 of a mobile device 110′ has been provided with a GUI 1407 showing, at 1471, portions of a corresponding requested transaction data set, in the form of a list comprising information identifying at least one item to be purchased (a Bosch 30″ smooth top range), along with a price associated with the item. The user has also been provided with an icon 1408 representing a first payment option, in the form of a transaction payment source identified as a credit account “RBC VISA AVION” administered by a trusted FI 120, 160.]
and is configured to cause a selectable option to approve or disapprove the transaction to be presented automatically on a user interface of the electronic device … being accessed by the user at the time the approval request was received; [see at least (10/13-17) in response to being queried by the merchant application, in some cases, a virtual wallet application may cause presentation on an output screen of the requesting communication device of a user interface soliciting authorization to proceed (a 'prompt' for confirmation of authorization). (10/18-22) the virtual wallet is storing tokens or payment credentials for more than one method of payment (i.e., source of funding for a transaction), the virtual wallet may also prompt the user for a selection of one or more of the stored payment options for use with the current transaction.]
receiving a response to the approval request from the electronic device associated with the user; [see at least [10/34-37] Following selection by the user of the requesting device, or by the virtual wallet, of one or more payment options, the virtual wallet may respond to the merchant application, via communications subsystems of the requesting device. [34/7-11] the wallet application is able to verify the certificate, the wallet application 112, 622 may respond with an indication or signal that merchant application 114, 630 is authorized to access payment credential(s) stored therein.]
sending a message to the third-party indicating the verification status. [(10/34-37) Following selection by the user of the requesting device, or by the virtual wallet, of one or more payment options, the virtual wallet may respond to the merchant application, via communications subsystems of the requesting device]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Upadhye, Matheson to include the elements of Ortiz. One would have been motivated to do so, in order to verify transaction information associated with the user. Upadhye, Matheson discloses determining transaction information based on a query. Ortiz teaches verifying transaction information in the same or similar context. Because cited features of Upadhye, Matheson and Ortiz are implemented in an electronic device to authenticate user. Additionally, the devices of Upadhye, Matheson are analogous to the devices of Ortiz that perform authenticating the user and could themselves be programmed to carry out that function as taught by Ortiz. Moreover, since the elements disclosed by Upadhye, Matheson, as well as Ortiz would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Upadhye, Matheson/Ortiz.
The above combination of Upadhye in view of Matheson, in further view of Ortiz discloses determining user, however, The above combination of Upadhye, Matheson, Ortiz does not disclose:
… as a notification such that the electronic device is woken up from a sleep mode and the notification is presented to the user on top of an existing application …
However, Raleigh discloses:
… as a notification such that the electronic device is woken up from a sleep mode and the notification is presented to the user on top of an existing application … [see at least Fig. 250 and (1223) the notification message displays in the foreground on top of an application and requires the user of the mobile wireless communication device 100 to select a button,]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Upadhye, Matheson, Ortiz to include the elements of Raleigh. One would have been motivated to do so, in order to verify transaction information associated with the user. Upadhye, Matheson, Ortiz discloses determining transaction information based on a query. Raleigh teaches user receiving notification and the notification being displayed on top of an application. Because cited features of Upadhye, Matheson and Ortiz are implemented in an electronic device to authenticate user. Additionally, one of skill in the art would be motivated to combine the authenticating user and user confirming transaction request as taught by Upadhye, Matheson, Ortiz with the electronic device receiving notification of Raleigh to provide a seamless way for user to accept or reject transaction request. Moreover, since the elements disclosed by Upadhye, Matheson, Ortiz as well as Raleigh would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Upadhye, Matheson, Ortiz/ Raleigh.
Note: The combination of Upadhye, Matheson, Ortiz, Raleigh does not expressly disclose the limitation the electronic device is woken up from a sleep mode. However, this part of the limitation would be non-function descriptive material, as the device being in sleep mode prior to the user receiving the notification does not impact the user’s response to the sent notification. Additionally, applicant specification discloses “The request may cause a selectable option to approve or disapprove the transaction via a user interface of the electronic device associated with the user. In some cases, the selectable option may be presented automatically on the user interface. For instance, the selectable option may be presented to the user as a notification such that the electronic device is woken up from a sleep mode and/or the notification is presented to the user on top of an existing application being accessed by the user at the time the approval request was received. In this case the user may approve or deny the request. In this way, the registry system provides a second factor of authentication or protection should a wallet holders account be compromised.” Based on the applicant’s specification, one of skill in the art under broadest reasonable interpretation can conclude that the functional part would be the user receiving the notification to approve or deny the request, and the electronic device being in sleep mode prior to receiving the notification does not impact whether the notification being sent nor how the user respond to the notification (i.e., approving or denying the transaction request).
Regarding Claims 6, 15. Upadhye, Matheson, Ortiz, Raleigh discloses the limitations of Claims 1, 10. Ortiz further discloses:
wherein the verification status indicates that the user is authorized to use a wallet associated with the wallet ID and the message includes an approval identifier. [see at least (77/49-55) the transaction processor 1750 can generate and route … a transaction payment authorization verification or confirmation data set … authorizing generation and/or release of the dynamic card token for payment to the merchant 130.]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Upadhye, Matheson, Ortiz, Raleigh to include additional features of Ortiz. One would have been motivated to do so, in order to authorizing payment based on verification of user transaction information. Upadhye, Matheson, Ortiz, Raleigh discloses verifying transaction information. Ortiz further teaches authorizing transaction for payment an electronic device. Since the subject matter is a combination of old elements, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
Regarding Claim 13. Upadhye, Matheson, Ortiz, Raleigh discloses the limitations of Claim 10. Ortiz further discloses:
receiving the response to the approval request from the electronic device associated with the user; and [see at least [10/34-37] Following selection by the user of the requesting device, or by the virtual wallet, of one or more payment options, the virtual wallet may respond to the merchant application, via communications subsystems of the requesting device. [34/7-11] the wallet application is able to verify the certificate, the wallet application 112, 622 may respond with an indication or signal that merchant application 114, 630 is authorized to access payment credential(s) stored therein.]
determining the verification status associated with the transaction based at least in part on receiving the response to the approval request from the electronic device associated with the user. [see at least [29/37-41] the token comprising a certification data set which may be looked up in a database 125, along with associated user and/or account information, for use in processing payments and other transactions]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Upadhye, Matheson, Ortiz, Raleigh to include additional features of Ortiz. One would have been motivated to do so, in order to verify transaction information associated with the user. Upadhye, Matheson, Ortiz, Raleigh discloses determining transaction information based on a query using the electronic device. Ortiz teaches verifying transaction information using the electronic device. Since the subject matter is a combination of old elements, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
Claims 2-5, 7-9, 11-12, 14, 16-17 are rejected under 35 U.S.C. 103 as being unpatentable over the combination of Upadhye, in view of Matheson, in further view of Ortiz, in further view of Raleigh, as applied to claims [1, 10] above, in further view of Winklevoss (US 11282139 B1).
Regarding Claims 2, 11. Upadhye, Matheson, Ortiz, Raleigh discloses the limitations of Claims 1, 10. The combination of Upadhye, Matheson, Ortiz, Raleigh discloses transaction information, however, the above combination of Upadhye, Matheson, Ortiz, Raleigh does not disclose:
wherein the wallet ID database is associated with at least one insurer associated with at least one of the user or a wallet associated with the user.
Nonetheless, Winklevoss discloses insurer associated with the information:
wherein the wallet ID database is associated with at least one insurer associated with at least one of the user or a wallet associated with the user. [see at least (86/51-53) data 3335 can also include information relating to a stored or insured digital wallet. (139/20-24) insurers 2042 may be private insurance companies. Insurers 2042 may also provide digital asset insurance, which may cover private key loss and/or theft and/or digital asset losses or thefts.]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Upadhye, Matheson, Ortiz, Raleigh to include the elements of Winklevoss. One would have been motivated to do so, in order to disclose types of information contained in the data. Upadhye, Matheson, Ortiz, Raleigh discloses verifying transaction information associated with the user. Winklevoss teaches the types of information associated with the wallet ID database in the same or similar context. Because both verifying transaction information and the type of information associated with the transaction information are implemented using a computer program on an electronic device. The devices of Upadhye, Matheson, Ortiz, Raleigh are analogous to the devices of Winklevoss that performs identifying types of information and could themselves be implemented to carry out the function as taught by Winklevoss. Moreover, since the elements disclosed by Upadhye, Matheson, Ortiz, Raleigh, as well as Winklevoss would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Upadhye, Matheson, Ortiz, Raleigh/Winklevoss.
Regarding Claims 3, 12. Upadhye, Matheson, Ortiz, Raleigh discloses the limitations of Claims 1, 10. The combination of Upadhye, Matheson, Ortiz, Raleigh discloses transaction information, however, the above combination of Upadhye, Matheson, Ortiz, Raleigh does not disclose:
wherein the input data is received via the application which is associated with at least one insurer associated with at least one of the user or a wallet associated with the user.
Nonetheless, Winklevoss discloses insurer associated with the information:
wherein the input data is received via the application which is associated with at least one insurer associated with at least one of the user or a wallet associated with the user. [see at least (139/20-24) insurers 2042 may be private insurance companies. Insurers 2042 may also provide digital asset insurance, which may cover private key loss and/or theft and/or digital asset losses or thefts. (144/29-32) user profile module 2174 can store user data (e.g., name, contact information, address, telephone number, email address, social security number, government ID information]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Upadhye, Matheson, Ortiz, Raleigh to include elements of Winklevoss. One would have been motivated to do so, in order to disclose types of information contained in the data. Upadhye, Matheson, Ortiz, Raleigh discloses verifying transaction information associated with the user. Winklevoss teaches types of information associated with the wallet. Because both verifying transaction information and the type of information associated with the transaction information are implemented using a computer program on an electronic device. The devices of Upadhye, Matheson, Ortiz, Raleigh z are analogous to the devices of Winklevoss that performs identifying types of information and could themselves be implemented to carry out the function as taught by Winklevoss. Moreover, since the subject matter is a combination of old elements, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
Regarding Claim 4. Upadhye, Matheson, Ortiz, Raleigh discloses the limitations of Claim 1. The combination of Upadhye, Matheson, Ortiz, Raleigh discloses transaction information, however, the above combination of Upadhye, Matheson, Ortiz, Raleigh does not disclose:
wherein wallet ID identifies a wallet associated with the user and the transaction.
Nonetheless, Winklevoss discloses determining information associated with the identifier:
wherein wallet ID identifies a wallet associated with the user and the transaction. [(16/9-12) digital asset account identifier and/or a digital wallet identifier may … be used to identify an account in transactions]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Upadhye, Matheson, Ortiz, Raleigh to include elements of Winklevoss. One would have been motivated to do so, in order to disclose types of information contained in the data. Upadhye, Matheson, Ortiz, Raleigh discloses verifying transaction information associated with the user. Winklevoss teaches types of information associated with the wallet. Because both verifying transaction information and the type of information associated with the transaction information are implemented using a computer program on an electronic device. The devices of Upadhye, Matheson, Ortiz, Raleigh are analogous to the devices of Winklevoss that performs identifying types of information and could themselves be implemented to carry out the function as taught by Winklevoss. Moreover, since the subject matter is a combination of old elements, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
Regarding Claims 5. Upadhye, Matheson, Ortiz, Raleigh, Winklevoss discloses the limitations of Claims 4. Winklevoss further discloses:
wherein the wallet comprises a custodial wallet associated with a certified custodian, the input data being received via an insurer providing insurance for multiple custodial wallets associated with the certified custodian. [see at least (19/47-48) a digital wallet may be a custodial digital wallet. (86/51-53) data 3335 can also include information relating to a stored or insured digital wallet]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Upadhye, Matheson, Ortiz, Raleigh, Winklevoss to include elements of Winklevoss. One would have been motivated to do so, in order to disclose types of information contained in the data. Upadhye, Matheson, Ortiz, Raleigh, Winklevoss discloses verifying transaction information associated with the user. Winklevoss teaches types of information associated with the wallet (i.e. custodial wallet). Because both verifying transaction information and the type of information associated with the transaction information are implemented using a computer program on an electronic device. The devices of Upadhye, Matheson, Ortiz, Raleigh, Winklevoss are analogous to the devices of Winklevoss that performs identifying types of information and could themselves be implemented to carry out the function as taught by Winklevoss. Moreover, since the subject matter is a combination of old elements, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
Regarding Claims 7, 16. Upadhye, Matheson, Ortiz discloses the limitations of Claims 1, 10. The combination of Upadhye, Matheson, Ortiz, Raleigh discloses transaction information, however, the above combination of Upadhye, Matheson, Ortiz, Raleigh does not disclose:
generating, in response to receiving the input data, a token associated with the user, wherein the token includes user information including at least one of an age of the user, tax information associated with the user, employment information associated with the user, residence information associated with the user, or citizenship information associated with the user.
Nonetheless, Winklevoss discloses type of information associated with the input data:
generating, in response to receiving the input data, a token associated with the user, wherein the token includes user information including at least one of an age of the user, tax information associated with the user, employment information associated with the user, residence information associated with the user, or citizenship information associated with the user. [(144/29-32) user profile module 2174 can store user data (e.g., name, contact information, address, telephone number, email address, social security number, government ID information]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Upadhye, Matheson, Ortiz, Raleigh to include elements of Winklevoss. One would have been motivated to do so, in order to disclose types of information contained in the data. Upadhye, Matheson, Ortiz, Raleigh discloses verifying transaction information associated with the user. Winklevoss teaches types of information associated with the user input. Because both verifying transaction information and the type of information associated with the user input are implemented using a computer program on an electronic device. The devices of Upadhye, Matheson, Ortiz, Raleigh are analogous to the devices of Winklevoss that performs identifying types of information and could themselves be implemented to carry out the function as taught by Winklevoss. Moreover, since the subject matter is a combination of old elements, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
Regarding Claims 8, 17. Upadhye, Matheson, Ortiz, Raleigh, Winklevoss discloses the limitations of Claims 7, 16. Winklevoss further discloses:
wherein the referencing the wallet ID database includes accessing the token [(0071) The platform server 312 may query the customer's wallet (or other nodes of the system 300) to determine whether the customer's wallet contains the particular store access tokens 354, as indicated by the confirmation query. The platform server 312 may send a response to the merchant server 304 indicating whether the customer's wallet contains the particular store access tokens 354, triggering the merchant server 304 to grant or deny access to product webpages accordingly]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Upadhye, Matheson, Ortiz, Raleigh, Winklevoss to include additional elements of Winklevoss. One would have been motivated to do so, in order to link the token with the wallet ID. Upadhye, Matheson, Ortiz, Raleigh, Winklevoss discloses verifying transaction information associated with the user. Winklevoss teaches accessing token to determine validity in an electronic device. Because the devices of Upadhye, Matheson, Ortiz, Raleigh, Winklevoss are analogous to the devices of Winklevoss that performs identifying types of information and could themselves be implemented to carry out the function as taught by Winklevoss. Moreover, since the subject matter is a combination of old elements, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
Regarding Claim 9. Upadhye, Matheson, Ortiz discloses the limitations of Claim 1. The combination of Upadhye, Matheson, Ortiz, Raleigh discloses transaction information, however, the above combination of Upadhye, Matheson, Ortiz, Raleigh does not disclose: wherein the transaction information associated with the transaction includes at least one of a transaction amount, a product description, at least one line item, a purchase order number, or an invoice number.
Nonetheless, Winklevoss discloses types of information associated with transaction information:
wherein the transaction information associated with the transaction includes at least one of a transaction amount, a product description, at least one line item, a purchase order number, or an invoice number. [(27/13-15) the exchange computer system may receive validation transaction information, which may include a transaction amount, date, and/or time. (Reads on: transaction amount is included in the transaction information)]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Upadhye, Matheson, Ortiz, Raleigh to include elements of Winklevoss. One would have been motivated to do so, in order to link the token with the wallet ID. Upadhye, Matheson, Ortiz, Raleigh discloses verifying transaction information associated with the user. Winklevoss teaches types of information associated with transaction information in an electronic device. Because the devices of Upadhye, Matheson, Ortiz, Raleigh, Winklevoss are analogous to the devices of Winklevoss that performs identifying types of information and could themselves be implemented to carry out the function as taught by Winklevoss. Moreover, since the subject matter is a combination of old elements, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
Regarding Claim 14. Upadhye, Matheson, Ortiz discloses the limitations of Claim 13. The combination of Upadhye, Matheson, Ortiz, Raleigh discloses transaction information, however, the above combination of Upadhye, Matheson, Ortiz, Raleigh does not disclose:
wherein the wallet ID identifies a wallet associated with the user and the wallet comprises a custodial wallet associated with a certified custodian, the input data being received via an insurer providing insurance for multiple custodial wallets associated with the certified custodian.
Nonetheless, Winklevoss discloses types of information associated with transaction information:
wherein the wallet ID identifies a wallet associated with the user and the wallet comprises a custodial wallet associated with a certified custodian, the input data being received via an insurer providing insurance for multiple custodial wallets associated with the certified custodian. [see at least (19/47-48) a digital wallet may be a custodial digital wallet. (86/51-53) data 3335 can also include information relating to a stored or insured digital wallet]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Upadhye, Matheson, Ortiz, Raleigh, Winklevoss to include elements of Winklevoss. One would have been motivated to do so, in order to disclose types of information contained in the data. Upadhye, Matheson, Ortiz, Raleigh, Winklevoss discloses verifying transaction information associated with the user. Winklevoss teaches types of information associated with the wallet (i.e. custodial wallet). Because both verifying transaction information and the type of information associated with the transaction information are implemented using a computer program on an electronic device. The devices of Upadhye, Matheson, Ortiz, Raleigh, Winklevoss are analogous to the devices of Winklevoss that performs identifying types of information and could themselves be implemented to carry out the function as taught by Winklevoss. Moreover, since the subject matter is merely a combination of old elements, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
Claims 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Upadhye (US20230230067A1), in view of Winklevoss (US 11282139 B1), in further view of Matheson et al (US 20230079195 A1), in further view of Ortiz (US 11354651 B2), in further view of Raleigh (US 20200045519 A1).
Regarding Claim 18. Upadhye discloses:
receiving input data requesting to register a wallet identification (ID) associated with a user; [(0038) the consumer wallet includes a client-side interface of the virtual wallet server 203. The consumer, or virtual, wallet application enables a user to input, remove, update]
Upadhye discloses inputting information associated, however, Upadhye does not disclose:
generating, in response to receiving the input data, a token associated with the user, wherein the token includes user information including at least one of an age of the user, tax information associated with the user, employment information associated with the user, residence information associated with the user, or citizenship information associated with the user;
receiving a blind query from a third-party regarding at least one transaction associated with a wallet associated with the user, the blind query including an indication of the wallet ID;
determining transaction information associated with the wallet ID based at least in part on referencing the token;
sending an approval request to an electronic device associated with the user, wherein the approval request includes at least a portion of the transaction information associated with the transaction and is configured to cause a selectable option to approve or disapprove the transaction to be presented automatically on a user interface of the electronic device as a notification such that the electronic device is woken up from a sleep mode and the notification is presented to the user on top of an existing application being accessed by the user at the time the approval request was received;
receiving a response to the approval request from the electronic device associated with the user;
determining an authorization of the third-party to access the transaction information associated with the wallet ID based on the response to the approval request; and
sending the transaction information associated with the wallet ID to the third-party based at least in part on the authorization.
Nonetheless, Winklevoss discloses the types of information associated with use:
generating, in response to receiving the input data, a token associated with the user, wherein the token includes user information including at least one of an age of the user, tax information associated with the user, employment information associated with the user, residence information associated with the user, or citizenship information associated with the user; [(144/29-32) user profile module 2174 can store user data (e.g., name, contact information, address, telephone number, email address, social security number, government ID information]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Upadhye to include the elements of Winklevoss. One would have been motivated to combine the information associated with the user in Winklevoss with the wallet of Upadhye in order to securely authenticate the user using those information. Upadhye discloses registering a wallet. Winklevoss teaches types of information associated with the user input. Moreover, since the elements disclosed by Upadhye, as well as Winklevoss would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Upadhye /Winklevoss.
The combination of Upadhye, in view of Winklevoss discloses inputting information associated with the user, however, the above combination of Upadhye, Winklevoss does not disclose:
receiving a blind query from a third-party regarding at least one transaction associated with a wallet associated with the user, the blind query including an indication of the wallet ID;
determining transaction information associated with the wallet ID based at least in part on referencing the token;
sending an approval request to an electronic device associated with the user, wherein the approval request includes at least a portion of the transaction information associated with the transaction and is configured to cause a selectable option to approve or disapprove the transaction to be presented automatically on a user interface of the electronic device as a notification such that the electronic device is woken up from a sleep mode and the notification is presented to the user on top of an existing application being accessed by the user at the time the approval request was received;
receiving a response to the approval request from the electronic device associated with the user;
determining an authorization of the third-party to access the transaction information associated with the wallet ID based on the response to the approval request; and
sending the transaction information associated with the wallet ID to the third-party based at least in part on the authorization.
However, Matheson analogous in art uses computer program to determine information associated with the user, discloses:
receiving a blind query from a third-party regarding at least one transaction associated with a wallet associated with the user, the blind query including an indication of the wallet ID; [(0066) The DB memory 322 of the platform database 314 may contain the recipient data records, transaction data records, and/or merchant data records. The platform server 312 may issue queries to the platform database 314 and updates based upon, for example, merchant transaction records or new user records (e.g., new buyer, new recipient) of the ecommerce platform 310. The platform database 314 further stores various types of data received from customer devices 302 or merchant servers 304. The DB memory 322 of the platform database 314 may store various types of information about the customers, merchants, and transactions (i.e., transaction information), which the platform server 312 or merchant server 304 may access when performing certain operations. The platform server 312 may query the customer's wallet (or other nodes of the system 300) to determine whether the customer's wallet contains the particular store access tokens 354 (i.e., wallet ID), as indicated by the confirmation query.]
determining transaction information associated with the wallet ID based at least in part on referencing the token; [(0066) The DB memory 322 of the platform database 314 may contain the recipient data records, transaction data records, and/or merchant data records. The platform server 312 may issue queries to the platform database 314 and updates based upon, for example, merchant transaction records or new user records (e.g., new buyer, new recipient) of the ecommerce platform 310. The platform database 314 further stores various types of data received from customer devices 302 or merchant servers 304. The DB memory 322 of the platform database 314 may store various types of information about the customers, merchants, and transactions (i.e., transaction information), which the platform server 312 or merchant server 304 may access when performing certain operations. The platform server 312 may query the customer's wallet (or other nodes of the system 300) to determine whether the customer's wallet contains the particular store access tokens 354 (i.e., wallet ID), as indicated by the confirmation query.]
determining an authorization of the third-party to access the transaction information associated with the wallet ID based on the response to the approval request; and [(0071) The platform server 312 may query the customer's wallet (or other nodes of the system 300) to determine whether the customer's wallet contains the particular store access tokens 354 (i.e., wallet ID), as indicated by the confirmation query. The platform server 312 may send a response to the merchant server 304 indicating whether the customer's wallet contains the particular store access tokens 354, triggering the merchant server 304 to grant or deny access to product (reads on: determine if the user’s wallet proper authorization based on the store access token (i.e., wallet ID)) webpages accordingly.]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Upadhye, Winklevoss to include the elements of Matheson. One would have been motivated to combine the steps of authentication in Matheson using the user’s wallet in Upadhye in view of Winklevoss, in order to verify if the user has proper authorization. Upadhye, Winklevoss discloses registering and determining types of associated with user information. Matheson teaches querying to determine transaction information. Moreover, since the elements disclosed by Upadhye, Winklevoss as well as Matheson would function in the same manner in combination as they do separately, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Upadhye, Winklevoss/Matheson.
The combination of Upadhye, in view of Winklevoss, in further view of Matheson discloses determining user, however, the above combination of Upadhye, Winklevoss, Matheson does not disclose:
sending an approval request to an electronic device associated with the user, wherein the approval request includes at least a portion of the transaction information associated with the transaction and is configured to cause a selectable option to approve or disapprove the transaction to be presented automatically on a user interface of the electronic device as a notification such that the electronic device is woken up from a sleep mode and the notification is presented to the user on top of an existing application being accessed by the user at the time the approval request was received;
receiving a response to the approval request from the electronic device associated with the user;
sending the transaction information associated with the wallet ID to the third-party based at least in part on the authorization.
However, Ortiz analogous in art uses device to verify the user, discloses:
sending an approval request to an electronic device associated with the user, wherein the approval request includes at least a portion of the transaction information associated with the transaction [see at least (10/13-17) in response to being queried by the merchant application, in some cases, a virtual wallet application may cause presentation on an output screen of the requesting communication device of a user interface soliciting authorization to proceed (a 'prompt' for confirmation of authorization). (10/18-22) the virtual wallet is storing tokens or payment credentials for more than one method of payment (i.e., source of funding for a transaction), the virtual wallet may also prompt the user for a selection of one or more of the stored payment options for use with the current transaction.]
and is configured to cause a selectable option to approve or disapprove the transaction to be presented automatically on a user interface of the electronic device … being accessed by the user at the time the approval request was received; [see at least (10/13-17) in response to being queried by the merchant application, in some cases, a virtual wallet application may cause presentation on an output screen of the requesting communication device of a user interface soliciting authorization to proceed (a 'prompt' for confirmation of authorization). (10/18-22) the virtual wallet is storing tokens or payment credentials for more than one method of payment (i.e., source of funding for a transaction), the virtual wallet may also prompt the user for a selection of one or more of the stored payment options for use with the current transaction.]
determining an authorization of the third-party to access the transaction information associated with the wallet ID based on the response to the approval request; and [see at least (10/34-37) Following selection by the user of the requesting device, or by the virtual wallet, of one or more payment options, the virtual wallet may respond to the merchant application, via communications subsystems of the requesting device. (29/37-41) the token comprising a certification data set which may be looked up in a database 125, along with associated user and/or account information, for use in processing payments and other transactions. (34/7-11) the wallet application is able to verify the certificate, the wallet application 112, 622 may respond with an indication or signal that merchant application 114, 630 is authorized to access payment credential(s) stored therein.]
sending the transaction information associated with the wallet ID to the third-party based at least in part on the authorization. [(10/34-37) Following selection by the user of the requesting device … The merchant application may then transmit the received token or credential to the merchant server along with other information needed to complete the transaction.]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Upadhye, Winklevoss, Matheson to include the features of Ortiz. One would have been motivated to do so, in order to verify transaction information associated with the user. Upadhye, Winklevoss, Matheson discloses determining transaction information based on a query. Ortiz teaches verifying transaction information in the same or similar context. Because cited features of Upadhye, Winklevoss, Matheson and Ortiz are implemented in an electronic device to authenticate user. Additionally, the devices of Upadhye, Winklevoss, Matheson are analogous to the devices of Ortiz that perform authenticating the user and could themselves be programmed to carry out that function as taught by Ortiz. Moreover, since the elements disclosed by Upadhye, Winklevoss, Matheson, as well as Ortiz would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Upadhye, Winklevoss, Matheson/Ortiz.
The above combination of Upadhye in view of Winklevoss, in further view of Matheson, in further view of Ortiz discloses determining user, however, The above combination of Upadhye, Winklevoss, Winklevoss, Ortiz does not disclose:
… as a notification such that the electronic device is woken up from a sleep mode and the notification is presented to the user on top of an existing application …
However, Raleigh discloses:
… as a notification such that the electronic device is woken up from a sleep mode and the notification is presented to the user on top of an existing application … [see at least Fig. 250 and (1223) the notification message displays in the foreground on top of an application and requires the user of the mobile wireless communication device 100 to select a button,]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Upadhye, Winklevoss, Winklevoss, Ortiz to include the elements of Raleigh. One would have been motivated to do so, in order to verify transaction information associated with the user. Upadhye, Winklevoss, Winklevoss, Ortiz discloses determining transaction information based on a query. Raleigh teaches user receiving notification and the notification being displayed on top of an application. Because cited features of Upadhye, Winklevoss, Winklevoss, and Ortiz are implemented in an electronic device to authenticate user. Additionally, one of skill in the art would be motivated to combine the authenticating user and user confirming transaction request as taught by Upadhye, Winklevoss, Winklevoss, Ortiz with the electronic device receiving notification of Raleigh to provide a seamless way for user to accept or reject transaction request. Moreover, since the elements disclosed by Upadhye, Winklevoss, Winklevoss, Ortiz as well as Raleigh would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Upadhye, Winklevoss, Winklevoss, Ortiz/ Raleigh.
Regarding Claim 19. Upadhye, Winklevoss, Winklevoss, Ortiz, Raleigh discloses the limitations of Claim 18. Upadhye further discloses:
wherein the third-party comprise a governmental agency. [(0043) the third-party business entity 209 can be a business processing a transaction, an insurance company, a financial institution, a government entity]
Regarding Claim 20. Upadhye, Winklevoss, Winklevoss, Ortiz, Raleigh discloses the limitations of Claim 18. Ortiz further discloses:
sending the token to an electronic device associated with the user [see at least (10/13-17) in response to being queried by the merchant application, in some cases, a virtual wallet application may cause presentation on an output screen of the requesting communication device of a user interface soliciting authorization to proceed (a ‘prompt’ for confirmation of authorization). (10/18-22) the virtual wallet is storing tokens or payment credentials for more than one method of payment (i.e., source of funding for a transaction), the virtual wallet may also prompt the user for a selection of one or more of the stored payment options for use with the current transaction.]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Upadhye, Winklevoss, Matheson, Ortiz, Raleigh to include additional elements of Ortiz. One would have been motivated to do so, in order to perform transaction securely. Upadhye, Winklevoss, Matheson, Ortiz, Raleigh discloses types of information associated with the transaction information. Ortiz teaches storing token associated with the user. Because the cited feature of Upadhye, Winklevoss, Matheson, Ortiz, Raleigh and Ortiz are implemented in an electronic device to store token associated with user. Additionally, Upadhye, Winklevoss, Matheson, Ortiz, Raleigh are analogous to the devices of Ortiz that perform storing token and could themselves be programmed to carry out that function as taught by Ortiz. Moreover, since the subject matter is merely a combination of old elements, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
Response to Amendments/Arguments
With respect to Applicant’s Remarks as to the claims being rejected under 35 USC § 112(a).
Applicant submits: “Accordingly, Applicant respectfully requests that the Examiner withdraw the rejection of claims 1-20 under 35 U.S.C. § 112(a).
Examiner response: Applicant’s arguments, see pages 1-2, filed 06/11/2026, with respect to 1-20 have been fully considered and are persuasive. The 35 USC § 112(a) rejection has been withdrawn.
With respect to Applicant’s Remarks as to the claims being rejected under 35 USC § 103.
Applicant submits: “As an initial matter, the Examiner has alleged that the limitation regarding the approval request causing "the electronic device to wake from a sleep mode and present a selectable option to approve or disapprove the transaction on top of an existing application being accessed by the user" represents "non-functional descriptive material" that "does not affect how the claimed method functions." Office Action, page 8. Applicant respectfully submits that this characterization is incorrect.”
Examiner response: Examiner has fully considered, and the examiner has updated the rejection. However, claims 1, 10, and 18 remain rejected under 35 USC § 103. Additionally, new cited Raleigh references discloses the receiving notification on the electronic device, where the notification is on top of the application (see Raleigh [1223]). Thus the rejection is proper and has been maintained.
Applicant submits: “Ortiz does not disclose or suggest: (1) waking an electronic device from a sleep mode; (2) presenting a notification on top of an existing application being accessed by the user; or (3) doing so automatically at the time the approval request was received. The Examiner has not identified any teaching in Ortiz, or in any of the other cited references, that would suggest these specific features. Moreover, the Examiner has not provided any motivation or rationale for why one of ordinary skill in the art would modify the combination to include these specific features. Accordingly, Applicant respectfully requests that the Examiner withdraw the rejections of claims 1-20 under 35 U.S.C. § 103.”
Examiner response: Applicant's arguments filed 06/11/2026 have been fully considered but they are not persuasive. The applicant’s argue the cited Ortiz reference does not disclose the amended claim limitation. However, the examiner would like to emphasize, as stated in the above rejection, the cited Ortiz reference disclose the user answering the prompt. Additionally, the applicant amended claims 1, 10 and 18 recites “selectable option to approve or disapprove the transaction to be presented automatically on a user interface” The Ortiz reference discloses “in response to being queried by the merchant application, in some cases, a virtual wallet application may cause presentation on an output screen of the requesting communication device of a user interface soliciting authorization to proceed”. In summary, due to the merchant application requiring the authorization, a request is presented to user. The applicant further argues the cited references discloses user is interacting with the merchant application. However, the examiner would like to emphasize, the process of receiving the notification, and the user making a selection is the same, as an entity is required to initiate process. The applicant’s specification discloses “process 600 may include the registry system sending an approval request to an electronic device associated with the user, wherein the approval request includes at least a portion of the transaction information and is configured to cause the electronic device to automatically generate a selectable option on a user interface of the electronic device.” (see para 0091). Lastly, the notification being presented on top of the electronic device; the newly cited Raleigh reference discloses the receiving notification on the electronic device, where the notification is on top of the application (see Raleigh [1223]). Thus the rejection is proper and has been maintained.
Relevant Prior Art Not Relied Upon
The prior art made of record and not relied upon which, however, is considered pertinent to applicant's disclosure:
US 20170124565 A1 Arora; Hemant et al. METHODS AND APPARATUS FOR PROCESSING AND AUTHENTICATING MOBILE PAYMENT TRANSACTIONS - A computer implemented method of processing a mobile payment transaction is disclosed. The method comprises: receiving a mobile payment authorization request, the mobile payment authorization request indicating authentication information and an identifier of a payment card associated with the transaction, the authentication information comprising a device identifier of a payer device; comparing authentication information with stored authentication information associated with the payment card; and generating an authorization message for the mobile payment if the authentication information matches the stored authentication information associated with the payment card.
US 20200013045 A1 Spalding; Tyler Robert et al. STAKE POOL FOR A SECURE AND TRUSTED DATA COMMUNICATION SYSTEM - A method includes receiving a request from a computing device requesting that a digital wallet rendered by a digital wallet application executed on the computing device be recognized and accepted within a secure and trusted data communication system for purposes of financial transactions using a first cryptocurrency. The method further includes verifying that the first cryptocurrency is a valid form of cryptocurrency in accordance with a validation protocol. When the first cryptocurrency is valid, the method further includes establishing a per unit value of the first cryptocurrency based on a per unit value of a known and trusted cryptocurrency of the system, obtaining a set of units of collateral cryptocurrency for a plurality of units of first cryptocurrency based on the established per unit value of the first cryptocurrency, and storing the set of units of collateral cryptocurrency in a secure stake pool for transactions utilizing the first cryptocurrency.
US 20220255754 A1 ISHIDA; Tatsuro et al. CONTROL APPARATUS, DATA REGISTRATION SYSTEM, AND CONTROL PROGRAM - A data registration system of the present embodiment includes a control device 20 and a cooperating device 30. The control device 20 includes a communication unit 21 that receives a data registration request to which an electronic signature of a user is added, a verification unit 22 that verifies identity of the user, a transaction generation unit 23 that, if identity of the user is verified, takes out data included in the data registration request, transmits the data to the cooperating device 30 to store the data in the cooperating device 30, generates a transaction based on the data registration request, and adds an electronic signature to the transaction, the transaction including information for accessing the data stored in the cooperating device 30, and a blockchain control unit 24 that issues the transaction to a blockchain network. The cooperating device 30 includes a communication unit 31 that receives the data and a storage unit 33 that stores the data in association with the transaction.
US 20200364356 A1 Yan; Wenyuan et al. BLOCKCHAIN AUTHORIZATION - A computer-implemented method includes: receiving, by a server storing one or more blockchain ledgers, an authorization request from a client, in which the authorization request includes a service end identifier and a user identifier; generating, based on the authorization request, a database authorization instruction corresponding to the authorization request and a ledger identifier corresponding to the authorization request; authorizing a service end corresponding to the service end identifier as a user in a blockchain ledger corresponding to the ledger identifier; configuring a permission value of the user in the blockchain ledger, in which the permission value determines a degree to which the service end can operate the blockchain ledger; and sending authorization information including the user identifier and the ledger identifier to the service end.
US 20130110658 A1 Lyman; Daniel J. et al. SYSTEMS AND METHODS FOR ENABLING MOBILE PAYMENTS - Systems, devices, and methods for processing payment transactions are provided. In some embodiments, payment account information is stored in a mobile wallet by a configuration portal server, and payment tokens are transmitted to a mobile device. A payment token may be submitted by the mobile device to a merchant point-of-sale device as part of a transaction. The payment token may be transmitted to a mobile wallet registry system, which may use the payment token to obtain the payment account information or otherwise complete the transaction. In some embodiments, more than one payment account may be stored in a mobile wallet, and more than one payment account may be associated with a given payment token.
US 20170352024 A1 KLENOFF; Nili et al. METHOD AND SYSTEM FOR INTELLIGENT ROUTING FOR ELECTRONIC WALLET REGISTRATION AND USAGE - A method for intelligent routing for electronic wallet registration includes: storing, in a wallet database of a processing server, a plurality of wallet profiles, wherein each wallet profile includes a structured data set related to at least one electronic wallet including at least one or more wallet identifiers and one or more identification numbers; receiving, by a receiving device of the processing server, a wallet request from a computing device, wherein the wallet request includes at least a primary account number; executing, by a querying module of the processing server, a query on the wallet database to identify a specific wallet profile where one of the included one or more identification numbers corresponds to the primary account number; electronically transmitting, by a transmitting device of the processing server, at least one of the one or more wallet identifiers included in the identified specific wallet profile to the computing device.
US 20210097588 A1 MILLER T Method for enabling data activity visibility for entities, involves providing dashboard data to authorized entity device for rendering at authorized entity device that includes data regarding transaction in association with customer - The method involves receiving registration data regarding a customer. The customer is registered in association with a set of customer data based on the registration data. An identifier that encrypts the set of customer data is generated. The identifier is transmitted to a front-end device (154). An executed transaction report containing the identifier and relating to a transaction is received from an exchange (156). The set of customer data is determined from the identifier of the executed transaction report. A dashboard request is received from an authorized entity device (158). The dashboard data is provided to the authorized entity device for rendering at the authorized entity device that includes data regarding the transaction in association with the customer.
US 20200380701 A1 BUIBAS; Marius et al. SELF-CLEANING AUTONOMOUS STORE - An autonomous store that tracks shopper movements and actions, and performs store cleaning actions based on analysis of shopper activity. Cleaning actions may include disinfecting the store or regions within the store using radiation, fogging or spraying, or ventilation. Cleaning actions may be targeted; for example, zones where shoppers linger or congregate may be cleaned more frequently or intensively, or shelves or items that shoppers touch may be cleaned after these interactions. Shopper activity information may be used to limit the number of shoppers in a store at once, for example by denying entry when the store is at capacity. The density of shoppers in regions of the store may be communicated to shoppers so that they can limit their interactions with other shoppers. Shopper activity history may be used for contact tracing by identifying other shoppers that may have been exposed to an individual who was in the store.
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 concerning this communication or earlier communications from the examiner should be directed to MD S HYDER whose telephone number is (571)270-1820. The examiner can normally be reached Monday - Friday 8:30am - 6: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.
/M.S.H./Examiner, Art Unit 3698
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698
Prosecution Insights