DETAILED ACTION
Acknowledgements
This Office Action is in response to Applicant’s response/application filed on 05/11/2026.
The Examiner notes that citations to United States Patent Application Publication paragraphs are formatted as [####], #### representing the paragraph number.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
Claim 1 has been canceled.
Claim 2, 5, 6, 7, 8, 9, 12, 13, 14, 15, 16, 20, 21 have been amended.
No claim has been added.
Claims 2-21 are currently pending and have been examined.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103(a) are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 2- 21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Mossoba (US 20190385130), in view of Padmanabhan (US 20230080927), further in view of Quigley (WO 2022204404).
Regarding claim(s) 2, 9, and 16, Mossoba discloses:
a non-transitory machine-readable medium having stored thereon machine-readable instructions ([0054]);
one or more hardware processors ([0088]); and
a non-transitory memory storing instructions, that when executed by the one or more hardware processors ([0088]), cause the one or more hardware processors to perform operations comprising:
detecting, via a user device, an event associated with a first token corresponding to a first reward system (By disclosing, “One or more steps in this exemplary use case may be automated or facilitated by the system. For example, the system 100 (e.g., via merchant POS terminal 130B) may detect entry of customer device 110A within a range of Merchant B's POS location and communicate the detection to the merchant node 120B. In turn, the merchant node 120B may direct the customer device 110A to identify, via the application, whether the customer account associated with the customer device 110A has a sufficient balance of the second virtual currency units (e.g., coffee rewards points) to purchase any goods or one of Customer A's typical purchases at Merchant B.” ([0081]-[0083]));
in response to detecting the event, accessing, within a universal token framework comprising a framework blockchain, a universal token that is linked to the first token based on metadata associated with the universal token, wherein the universal token was generated to link with the first token (By disclosing, “To more freely and securely facilitate transactions and exchanges involving rewards points, some systems have turned to so-called distributed “blockchain” systems that can simultaneously record transaction-related entries in multiple places, and simultaneously.” ([0004]); “In a second, but related exemplary use case in accordance with some embodiments, the first customer (Customer A) may have insufficient second virtual currency units (e.g., coffee rewards points), third virtual currency units (e.g., ice cream rewards points), etc. to conduct a direct A-for-B or A-and-C-for-B transaction with a second customer (Customer B) on the system 100. In such a scenario, the system 100 may (i) involve three or more customers or, separate from or in combination with transactions between the customers, (ii) utilize generic virtual currency units [(universal token)] produced by the authorization node, or with an unaffiliated merchant node authorized by the authorization node 150. That is, Customer A (e.g., via customer device 110A) may trade first virtual currency units [(first token)] for generic virtual currency units as a separate transaction with the authorization node 150 or as part of a transaction with one or more other customers.” ([0081]-[0083]); and “In an alternative embodiment, such a transfer of virtual currency to merchants may be facilitated by a predetermined exchange rate [(metadata associated with the universal token)] utilizing the generic virtual currency issued by the authorization node 150 as an intermediary currency for the exchange.” ([0063]); and
processing a transaction based on the event using the universal token via a logical bridge between the framework blockchain and the first reward system ([0081]-[0085], [0063]).
Mossoba does not disclose:
wrapping the universal token with the metadata that comprises a smart contract; and
wherein the processing the transaction comprises executing the smart contract wrapped in the universal token that converts the universal token to the first token corresponding to the first reward system and performing an action with the first reward system using the first token.
However, Padmanabhan teaches:
wherein the universal token was generated to link with the first token based on wrapping the universal token with the metadata. (By disclosing, “According to various embodiments, the issuer of the designated fungible token template may push the designated fungible token template and/or instances of the designated fungible token to one or more exchanges that are partnered with the database system. In such a configuration, the partner exchange receives information such as the exchange rate, which may be included within metadata in the smart contract instance governing a quantity of tokens, the smart contract template from which the tokens are minted, the database system acting as an oracle, or other such sources. In this way, the partner exchange may enforce the exchange rate.” ([0302], [0286] of Padmanabhan)).
Therefore, it would have been obvious to one of ordinary skill in the art at the effective filing date of the present application to modify the invention of Mossoba in view of Padmanabhan to include techniques of wrapping metadata in a token. Doing so would result in an improved invention because this would allow any system to get the information for the exchange rate and process a transaction based on the exchange rate.
And Guigley teaches:
executing the smart contract wrapped in the universal token that converts the universal token to the first token corresponding to the first reward system and performing an action with the first reward system using the first token. (By disclosing, “In an example operation, a first user may make a trade offer in a smart contract to a second user to exchange one or more tokens for one or more tokens in return.” ([0516] of Quigley); and “In embodiments, a collateral token 2042 may include a smart contract wrapper, such that when an owner of the collateral token (as determined from an ownership record of the collateral token after a loan has been repaid and/or after a liquidation event) redeems the token (as discussed above), the smart contract associated with the collateral token 2042 may provide a notification to the safekeeper of a collateral item represented by th e collateral token 2042 to provide the collateral item” ([0616] of Guigley)).
Therefore, it would have been obvious to one of ordinary skill in the art at the effective filing date of the present application to modify the invention of Mossoba and Padmanabhan, in view of Guigley to include techniques of executing the smart contract wrapped in the universal token that converts the universal token to the first token corresponding to the first reward system and performing an action with the first reward system using the first token. Doing so would result in an improved invention because this would leverage the advantages of using smart contract (e.g. automation, improved efficiency, etc.).
Regarding claim(s) 3, 10, and 17, Mossoba discloses:
wherein the universal token framework is incompatible with the first reward system. ([0060]).
Regarding claim(s) 4, 11, and 18, Mossoba discloses:
wherein the universal token is an intermediate currency between the first token and a second token corresponding to a second reward system (By disclosing, “For example, if Customer A has 1,000 coffee rewards points and 2,000 ice cream rewards points and wishes to obtain 1,500 taco rewards points, another customer who has 1,500 taco rewards points may not be interested in Customer A's coffee rewards points or ice cream rewards points (or the 1,000 coffee rewards points alone may be insufficient). To facilitate and expedite this transaction, the system 100 may (e.g., via authorization node in communication with customer device 110A) prompt Customer A with an option to exchange his 1,500 of the ice cream rewards points for 1,500 generic rewards points, which can in turn be exchanged for Customer B's 1,500 taco rewards points.” ([0083])).
Regarding claim(s) 5, 12, and 19, Mossoba discloses:
wherein the transaction involves exchanging a second token corresponding to a second reward system with the first token based on a predetermined exchange rate (By disclosing, “This exemplary use case may also allow a customer, either manually or via the system 100, to better take advantage of exchange rates between various virtual currency types and the generic currency.” ([0082]-[0085])).
Regarding claim(s) 6 and 13, Mossoba does not disclose, but Padmanabhan teaches:
recording the smart contract on the framework blockchain. (By disclosing, “the smart contract 1700 is a computer program that may be included within a public trust ledger such as a blockchain.” ([0228] of Padmanabhan)).
Therefore, it would have been obvious to one of ordinary skill in the art at the effective filing date of the present application to modify the invention of Mossoba in view of Padmanabhan to include techniques of recording a smart contract on a blockchain. Doing so would result in an improved invention because this would leverage the advantages of using smart contract (e.g. automation, cost efficiency, etc.).
Regarding claim(s) 7, 14, and 20, Mossoba discloses:
generating a second universal token that is linked to the second token (By disclosing, “the authorization node 150 and/or its designated nodes may be exclusively capable of creating and issuing generic virtual currency units within the system 100.” ([0040] of Mossoba); and “the authorization node 150 may create a generic virtual currency and set an exchange value between each merchant-issued virtual currency and the generic virtual currency” ([0060] of Mossoba)); and
wherein the processing the transaction is further based on the second universal token (By disclosing, “The first merchant node may receive a transaction request for exchanging one or more of the first virtual currency units for a second currency type (e.g., second virtual currency units, generic virtual currency units, U.S. dollars, etc.) between the first customer account and a second customer account.” ([0007] of Mossoba)).
Mossoba does not disclose, but Padmanabhan teaches:
obtaining, from a digital wallet of a user of the user device, a second token corresponding to a second reward system (By disclosing, “According to various embodiments, when a request is made by the database system to purchase a token, receiving a JWT from the wallet API 704 allows the database system 702 to interacting with the ledger API 706 to transfer the token from the seller's wallet.” ([0172] of Padmanabhan)); and
wrapping second metadata comprising a second smart contract with the second universal token (By disclosing, “According to various embodiments, the issuer of the designated fungible token template may push the designated fungible token template and/or instances of the designated fungible token to one or more exchanges that are partnered with the database system. In such a configuration, the partner exchange receives information such as the exchange rate, which may be included within metadata in the smart contract instance governing a quantity of tokens, the smart contract template from which the tokens are minted, the database system acting as an oracle, or other such sources. In this way, the partner exchange may enforce the exchange rate.” ([0302], [0286] of Padmanabhan)).
Therefore, it would have been obvious to one of ordinary skill in the art at the effective filing date of the present application to modify the invention of Mossoba in view of Padmanabhan to include techniques of obtaining, from a digital wallet of a user of the user device, a second token corresponding to a second reward system; and wrapping second metadata comprising a second smart contract with the second universal token. Doing so would result in an improved invention because this would allow any system to get the information for the exchange rate and process a transaction based on the exchange rate.
Regarding claim(s) 8, 15, and 21, Mossoba does not disclose, but Guigley teaches:
in response to detecting a second event, executing the second smart contract that converts the second universal token into the second token corresponding to the second reward system. (By disclosing, “In an example operation, a first user may make a trade offer in a smart contract to a second user to exchange one or more tokens for one or more tokens in return.” ([0516] of Quigley); and “In embodiments, a collateral token 2042 may include a smart
contract wrapper, such that when an owner of the collateral token (as determined from an ownership record of the collateral token after a loan has been repaid and/or after a liquidation event) redeems the token (as discussed above), the smart contract associated with the collateral token 2042 may provide a notification to the safekeeper of a collateral item represented by the collateral token 2042 to provide the collateral item” ([0616] of Guigley)).
Therefore, it would have been obvious to one of ordinary skill in the art at the effective filing date of the present application to modify the invention of Mossoba and Padmanabhan, in view of Guigley to include techniques of in response to detecting a second event, executing the second smart contract that converts the second universal token into the second token corresponding to the second reward system. Doing so would result in an improved invention because this would leverage the advantages of using smart contract (e.g. automation, improved efficiency, etc.).
Response to Arguments
Applicant’s arguments with regard to the 35 U.S.C. § 103 rejection have been considered but are moot in view of new grounds of rejection initiated by applicant’s amendment to the claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20180315072 to Rubin for disclosing:
a method of facilitating the issuance, redemption, and management of cryptocurrency-based loyalty points associated with one or more of a product and a service is disclosed. The method may include receiving, using a communication device, a purchase request for obtaining at least one cryptocurrency-based loyalty token to be associated with a user account. Further, the method may include transferring, using the processing device, the at least one cryptocurrency-based loyalty token to a loyalty user wallet associated with the user account based on the purchase request. Further, the method may include storing, using a storage device, token allocation data on a blockchain. Further, the token allocation data may include at least one characteristic associated with each of the user account, the purchase request, transferring of the at least one cryptocurrency-based loyalty token and the loyalty user wallet.
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 DUAN ZHANG whose telephone number is (571)272-4642. The examiner can normally be reached Mon - Fri 10 AM-5 PM.
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, Neha Patel can be reached at 571-270-1492. 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.
/DUAN ZHANG/Primary Examiner, Art Unit 3699
Prosecution Insights