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.
Status of Claims
The following is a FINAL Office Action in response to Applicant’s amendments filed on 03/18/2026.
a. Claims 1, 10, 18 are amended
Overall, Claims 1-20 are pending and have been considered below.
Claim Rejections - 35 USC § 112(a):
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-20 rejected under 35 U.S.C. 112(a) first paragraph, as failing to comply with the written description requirement. The claims contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claim 1 recites “cause an application to automatically enable and move from a background of the electronic device to a foreground of the electronic device such that a user interface of the application is automatically invoked without user input requesting the user interface to be displayed”. The amended language is not disclosed in the original disclosure of the application. The specification filed on 06/07/2023 of the current application does not discloses movement from background to a foreground. Additionally, the speciation does not disclose whether it automatically displays without the user input. Thus, claim 1 have no coverage and therefore the amended elements in the claim are new matter.
Claim 10, 18 recites similar limitation to claim 1, and thus are rejected for the same reason as above.
The remainder of the claims are rejected by virtue of dependency.
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).
Regarding Claims 1, 10. Upadhye discloses:
one or more processors; and [see at least (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: [see at least (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; [see at least (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); [see at least (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 an application to automatically enable and move from a background of the electronic device to a foreground of the electronic device such that a user interface of the application is automatically invoked without user input requesting the user interface to be displayed, wherein the approval request causes 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;
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; [see at least (0071) the platform server 312 may receive a wallet confirmation query from the merchant server 304 requesting the platform server 312 confirm the contents of the customer's wallet.]
determining the user associated with the wallet ID based at least in part on referencing a wallet ID database; [see at least (0071) the platform server 312 may receive a wallet confirmation query from the merchant server 304 requesting the platform server 312 confirm the contents of the customer's 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 to include the elements of Matheson. One would have been motivated to do so, in order to determine transaction information based on query. Upadhye discloses registering a wallet. Matheson teaches querying to determine transaction information in the same or similar context. Because both registering a wallet, as well as querying to determine transaction information are implemented through specific computer program to register and authenticate user. The devices of Upadhye are analogous to the devices of Matheson that performs authentication user and could themselves be implemented to carry out the function as taught by Matheson. 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.
Upadhye, Matheson discloses determining user, however, 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 an application to automatically enable and move from a background of the electronic device to a foreground of the electronic device such that a user interface of the application is automatically invoked without user input requesting the user interface to be displayed, wherein the approval request causes 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;
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.
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 an application to automatically enable and move from a background of the electronic device to a foreground of the electronic device such that a user interface of the application is automatically invoked without user input requesting the user interface to be displayed, wherein the approval request causes 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; [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.]
Note: The above combination of Upadhye, Matheson, Ortiz does not expressly disclose wherein the approval request causes 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; However this limitation represents non-functional descriptive material and does not affect how the claimed method functions (i.e., the descriptive material does not have any claim function in the claimed method; see MPEP 2106.01). A “wherein” clause does not function to actively limit the claim language. Therefore, the claim element is considered, but given no patentable weight. (MPEP 2111.05). The reference is provided for the purpose of compact prosecution.
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.]
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 [see at least 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]
sending a message to the third-party indicating the verification status. [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]
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.
Regarding Claims 6, 15. Upadhye, Matheson, Ortiz 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 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 discloses verifying transaction information. Ortiz 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 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 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 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, as applied to claims [1, 10] above, in further view of Winklevoss et al (US 11282139 B1).
Regarding Claims 2, 11. Upadhye, Matheson, Ortiz discloses the limitations of Claims 1, 10. Upadhye, Matheson, Ortiz discloses transaction information, however, Upadhye, Matheson, Ortiz 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 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 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 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, 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/Winklevoss.
Regarding Claims 3, 12. Upadhye, Matheson, Ortiz discloses the limitations of Claims 1, 10. Upadhye, Matheson, Ortiz discloses transaction information, however, Upadhye, Matheson, Ortiz 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 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 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 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 discloses the limitations of Claim 1. Upadhye, Matheson, Ortiz discloses transaction information, however, Upadhye, Matheson, Ortiz 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. [see at least (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 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 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 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, 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, 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, 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, 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. Upadhye, Matheson, Ortiz discloses transaction information, however, Upadhye, Matheson, Ortiz 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. [see at least (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 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 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 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, Winklevoss discloses the limitations of Claims 7, 16. Winklevoss further discloses:
wherein the referencing the wallet ID database includes accessing the token [see at least (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, 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, 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, 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. Upadhye, Matheson, Ortiz discloses transaction information, however, Upadhye, Matheson, Ortiz 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. [see at least (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 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 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, 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. Upadhye, Matheson, Ortiz discloses transaction information, however, Upadhye, Matheson, Ortiz 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, 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, 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, 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 et al (US20230230067A1), in view of Winklevoss et al (US 11282139 B1), in further view of Matheson et al (US 20230079195 A1), in further view of Ortiz et al (US 11354651 B2).
Regarding Claim 18. Upadhye discloses:
receiving input data requesting to register a wallet identification (ID) associated with a user; [see at least (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 an application to automatically enable and move from a background of the electronic device to a foreground of the electronic device such that a user interface of the application is automatically invoked without user input requesting the user interface to be displayed, wherein the approval request causes 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;
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; [see at least (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 do so, in order to disclose the types of information associated with user information. Upadhye discloses registering a wallet. Winklevoss teaches types of information associated with the user input. Because both verifying registering a wallet and the type of information associated with the user input are implemented using a computer program on an electronic device. The devices of Upadhye 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, 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.
Upadhye, Winklevoss discloses inputting information associated with the user, however, 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 an application to automatically enable and move from a background of the electronic device to a foreground of the electronic device such that a user interface of the application is automatically invoked without user input requesting the user interface to be displayed, wherein the approval request causes 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;
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; [see at least (0071) the platform server 312 may receive a wallet confirmation query from the merchant server 304 requesting the platform server 312 confirm the contents of the customer's wallet.]
determining transaction information associated with the wallet ID based at least in part on referencing the token; [see at least (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 … 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 … The store access token 354 may further include the algorithmically generated unique token identifier, as well as the hash of the purchase receipt token 352 and a new hash.]
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 do so, in order to determine transaction information based on query. Upadhye, Winklevoss discloses registering and determining types of associated with user information. Matheson teaches querying to determine transaction information in the same or similar context. Because both registering and determining types of associated with user information, as well as querying to determine transaction information are implemented through specific computer program to register and authenticate user. The devices of Upadhye, Winklevoss are analogous to the devices of Matheson that performs authentication user and could themselves be implemented to carry out the function as taught by Matheson. 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.
Upadhye, Winklevoss, Matheson discloses determining user and utilizing machine learning model, however, 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 an application to automatically enable and move from a background of the electronic device to a foreground of the electronic device such that a user interface of the application is automatically invoked without user input requesting the user interface to be displayed, wherein the approval request causes 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;
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, 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 an application to automatically enable and move from a background of the electronic device to a foreground of the electronic device such that a user interface of the application is automatically invoked without user input requesting the user interface to be displayed, wherein the approval request causes 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; [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.]
Note: The above combination of Upadhye, Winklevoss, Matheson, Ortiz does not expressly disclose wherein the approval request causes 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; However this limitation represents non-functional descriptive material and does not affect how the claimed method functions (i.e., the descriptive material does not have any claim function in the claimed method; see MPEP 2106.01). A “wherein” clause does not function to actively limit the claim language. Therefore, the claim element is considered, but given no patentable weight. (MPEP 2111.05). The reference is provided for the purpose of compact prosecution.
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.]
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. [see at least (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.
Regarding Claim 19. Upadhye, Winklevoss, Matheson, Ortiz discloses the limitations of Claim 18. Upadhye further discloses:
wherein the third-party comprise a governmental agency. [see at least (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, Matheson, Ortiz 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.]
Response to Amendments/Arguments
With respect to Applicant’s Remarks as to the claims being rejected under 35 USC § 112(a).
Applicant submits: “Claims 1-20 stand rejected under 35 U.S.C. § 112(a), as allegedly failing to comply with the written description requirement. Applicant respectfully traverses this rejection. Nevertheless, for the sole purpose of expediting allowance and without commenting on the propriety of the Office's rejections, Applicant herein amends claims 1, 10, and 18 as shown above. Applicant respectfully submits that these amendments render the § 112(a) rejections moot.”
Examiner response:. Notwithstanding applicant’s remarks, the rejection has been reconsidered in view of the amendments, and has been withdrawn. However, the examiner emphasizes a new 112(a) rejection has been filed based on the amendment.
With respect to Applicant’s Remarks as to the claims being rejected under 35 USC § 112(b).
Applicant submits: “Claims 1-20 stand rejected under 35 U.S.C. § 112(b), as allegedly being indefinite. Applicant respectfully traverses this rejection. Nevertheless, for the sole purpose of expediting allowance and without commenting on the propriety of the Office's rejections, Applicant herein amends claims 1, 10, and 18 as shown above. Applicant respectfully submits that these amendments render the § 112(b) rejections moot.”
Examiner response: Notwithstanding applicant’s remarks, the rejection has been reconsidered in view of the amendments, and has been withdrawn.
With respect to Applicant’s Remarks as to the claims being rejected under 35 USC § 103.
Applicant submits: “Claims 1, 6, 10, 13, and 15 stand rejected under 35 U.S.C. § 103 as allegedly being obvious over a combination of Upadhye in view of Matheson and further in view of Ortiz. Applicant respectfully traverses the rejection. Nevertheless, solely in the interest of expediting allowance, Applicant herein amends claims 1, 10, and 18 as shown above. Applicant respectfully requests reconsideration in light of the amendments presented herein. Applicant herein amends claim 1 to recite these previously unrecited features of claim 1. As such, the Office has not specifically examined these features. However, a thorough reveal of the combination of references reveals that the combination does not teach or suggest at least these features of amended claim 1. For at least the reasons presented herein, claim 1 would not have been obvious in view of Upadhye, Matheson, and Ortiz. Accordingly, Applicant respectfully requests that the Office withdraw the § 103 rejection of claim 1. For at least the reasons presented herein, claim 10 would not have been obvious in view of Upadhye, Matheson, and Ortiz. Accordingly, Applicant respectfully requests that the Office withdraw the § 103 rejection of claim 10.”
Examiner response: Examiner has fully considered, but doesn’t find Applicant’s argument persuasive. Examiner respectfully disagree with the applicant, the applicant’s arguments are directed towards the amended claim language and not original set of claims. Applicant argues the office action does not teach amended claim limitation. However, the examiner has reconsidered the combination of Upadhye, Matheson, and Ortiz in view of the amendments and finds that this combination discloses the amended claim language of claims 1, 10. See the rejection above. Thus the rejection is proper and has been maintained.
Applicant submits: “Claims 6, 13, and 15 ultimately depend from independent claims 1 and 10. As discussed above, claims 1 and 10 are allowable over the cited documents. Therefore, claims 6, 13, and 15 are allowable over the cited documents of record for at least their dependency from an allowable base claim, and also for the additional features that each recites. Accordingly, Applicant respectfully requests that the Office withdraw the § 103 rejection of claims 6, 13, and 15.”
Examiner response: Examiner has fully considered, but doesn’t find Applicant’s argument persuasive. Examiner respectfully disagree with the applicant, the applicant’s arguments are directed towards the amended claim language and not original set of claims. Additionally, dependent claims 6, 13, 15 remain rejected as their independent claims are also rejected. See the rejection above. Thus the rejection is proper and has been maintained.
Applicant submits: “Claims 2-5, 7-9, 11, 12, 14, 16, and 17 stand rejected under 35 U.S.C. § 103 as allegedly being obvious over a combination of Upadhye in view of Matheson in view of Ortiz and further in view of Winklevoss. Applicant respectfully traverses the rejection. Nevertheless, solely in the interest of expediting allowance, Applicant herein amends claims 1 and 10 as shown above. Applicant respectfully requests reconsideration in light of the amendments presented herein. Claims 2-5, 7-9, 11, 12, 14, 16, and 17 ultimately depend from independent claims 1 and 10. As discussed above, claims 1 and 10 are allowable over the combination of Upadhye, Matheson, and Ortiz. The Office cites Winklevoss as allegedly teaching the respective features of dependent claims 2-5, 7-9, 11, 12, 14, 16, and 17. Without conceding the propriety of the combination of Upadhye, Matheson, Ortiz, and Winklevoss, the combination fails to teach or suggest one or more features of independent claims 1 and 10. Therefore, claims 2-5, 7-9, 11, 12, 14, 16, and 17 are allowable over the cited documents of record for at least their dependency from an allowable base claim, and also for the additional features that each recites.“
Examiner response: Examiner has fully considered, but doesn’t find Applicant’s argument persuasive. Examiner respectfully disagree with the applicant, the applicant’s arguments are directed towards the amended claim language and not original set of claims. As mentioned in the previous response, independent claims 1, 10 are rejected, and thus dependent claims 2-5, 7-9, 11, 12, 14, 16, and 17 remain rejected. See the rejection above. Thus the rejection is proper and has been maintained.
Applicant submits: “Applicant herein amends claim 18 to recite these previously unrecited features of claim 18. As such, the Office has not specifically examined these features. However, a thorough reveal of the combination of references reveals that the combination does not teach or suggest at least these features of amended claim 18. For at least the reasons presented herein, claim 18 would not have been obvious in view of Upadhye, Winklevoss, Ortiz, and Ortiz. Accordingly, Applicant respectfully requests that the Office withdraw the § 103 rejection of claim 18. Dependent Claims 19 and 20 Claims 19 and 20 ultimately depend from independent claim 18. As discussed above, claim 18 is allowable over the cited documents. Therefore, claims 19 and 20 are allowable over the cited documents of record for at least their dependency from an allowable base claim, and also for the additional features that each recites. Accordingly, Applicant respectfully requests that the Office withdraw the § 103 rejection of claims 19 and 20”
Examiner response: Examiner has fully considered, but doesn’t find Applicant’s argument persuasive. Examiner respectfully disagree with the applicant, the applicant’s arguments are directed towards the amended claim language and not original set of claims. Additionally, the combination of Upadhye, Winklevoss, Matheson, Ortiz discloses the amended claim limitation of claim 18 and claim limitation of claims 19-20. See the rejection above. 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