DETAILED ACTION
This is office action on the merits in response to the application filed on 02/03/2026.
Claims 1-16 have been filed by the applicant.
Claims 9-15 are withdrawn from consideration.
Claims 1-8 are elected by the applicant.
Claims 2 and 4 are currently canceled.
Claims 1, 3, 5-8 and 16 are currently pending and have been examined.
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 .
Response to Argument
Rejection under 101:
The applicant argues that the claims provide technical solution to make efficient exchange. The applicant also cited specification [0012] the invention improves for users require to maintain various types of tokens to interact with different parties. The examiner respectfully disagrees. The claims improve the business method instead of technology because neither the tokenization technology or token itself is improved.
The applicant further argues that the additional elements such as “immutable ledger”, “the party-specific tokens” and “the token pool for the consortium” provide improvement in the functioning of computer. The examiner respectfully disagrees. The claims do not recite how these technologies are implemented in a non-conventional manner or how they improve functioning of computer. Instead, these elements are used for their expected purpose, which constitutes generally link the use of the judicial exception to a particular technological environment (MPEP § 2106.05(h)).
The claims recite a process which a user request to exchange tokens, when the token pool does not have sufficient tokens (out of stock), purchase more tokens (restock). The tokens are exchanged for user and recorded. The process of exchanging tokens fits abstract idea of commercial interactions. The additional elements fail to recite a practical application nor significantly more than the abstract idea, but to implement the abstract idea on generic computer or generally link the abstract idea to a particular technological environment.
Rejection under 103:
The applicant argues that Furche does not teach “determining whether token host includes the second token”. Applicant' s arguments have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
The applicant further argues that Veeraraghavan does not teach “consortium of parties”. The examiner respectfully disagrees. Veeraraghavan discloses the consortium consists of a group of sellers [0057], which is equivalent to the claims that the “consortium of parties” consists of multiple parties with tokens.
The applicant further argues that combining Veeraraghavan is deficient because Furche discloses tokens and Veeraraghavan discloses consortium purchases. The examiner respectfully disagrees. Both reference are discussing making transactions, so they are analogous arts and the combination is obvious.
The applicant further argues that combining Veeraraghavan is deficient because does not suggest party specific tokens from ones of the multiple party. The examiner respectfully disagrees. Furche discloses an exchange of a party specific token to another party specific token. Veeraraghavan further discloses a consortium of sellers (i.e., consortium of parties). The combination of Furche and Veeraraghavan suggests a system to exchange party specific tokens within a consortium of parties. Veeraraghavan does not need to disclose a party specific token.
Furche and Veeraraghavan do not teach the specific of the amendment, new prior art is provided, see 103 rejections.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 16 rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 16 recites the limitation "”the distributed ledger" in line 2. There is insufficient antecedent basis for this limitation in the claim.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1, 3, 5-8 and 16 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
In the instant case, claims 1-8 are directed to a method. Therefore, these claims fall within the four statutory categories of invention.
The limitations of independent claim 1 have been denoted with letters by the Examiner for easy reference. The judicial exceptions recited in claim 1 are identified in bold below:
A computer-implemented method for use in token management, the method comprising:
receiving, from a first user, a request to redeem a first token having a first value, the first token issued by a consortium of multiple parties;
in response to the request, identifying, by a computing device of a token host, based on one or more criteria, one of the multiple parties to settle a redemption of the first token, the token host including a token pool, which includes party-specific tokens for ones of the multiple parties;
determining, by the computing device, that the token pool does not include a sufficient quantity of a second token, which is the party-specific token for said one of the multiple parties, to settle the redemption of the first token;
in response to determining that the token pool does not include the sufficient quantity of the second token, automatically purchasing multiple of the second token from said one of the multiple parties into the token pool;
initiating, by the computing device, transfer of the second token, specific to the one of the multiple parties, to an account of the first user, in exchange for the first token; and
recording, by the computing device, an entry indicative of the redemption of the first token to an immutable ledger in communication with the computing device, the entry indicating burning of the first token.
Limitations A, C-D and F under the broadest reasonable interpretation covers steps or functions of commercial interactions. Other than reciting generic computer hardware in limitation A, C-D and F, nothing in the claim element differentiates the limitation from processes of commercial interactions. Therefore, limitations A, C-D and F recite an abstract idea, as highlighted above, that is consistent with the sales activities aspects of certain method of organizing human activities.
Furthermore, limitation G recites “recording an entry of the redemption” which is reciting recordkeeping associated with token redemption/purchasing. Limitation G therefore recites a mental process.
Accordingly, claim 1 recites at least two abstract ideas and the analysis proceed to Step 2A.2.
The judicial exception is not integrated into a practical application. In particular, claim 1 recites the additional elements in bold below:
A computer-implemented method for use in token management, the method comprising:
receiving, from a first user, a request to redeem a first token having a first value, the first token issued by a consortium of multiple parties;
in response to the request, identifying, by a computing device of a token host, based on one or more criteria, one of the multiple parties to settle a redemption of the first token, the token host including a token pool, which includes party-specific tokens for ones of the multiple parties;
determining, by the computing device, that the token pool does not include a sufficient quantity of a second token, which is the party-specific token for said one of the multiple parties, to settle the redemption of the first token;
in response to determining that the token pool does not include the sufficient quantity of the second token, automatically purchasing multiple of the second token from said one of the multiple parties into the token pool;
initiating, by the computing device, transfer of the second token, specific to the one of the multiple parties, to an account of the first user, in exchange for the first token; and
recording, by the computing device, an entry indicative of the redemption of the first token to an immutable ledger in communication with the computing device, the entry indicating burning of the first token.
The additional element(s) in limitation A, C-D and F-G are recited at a high level of generality to implement the abstract idea in a generic computer. As such, when the additional elements are considered individually and as an ordered combination, the claim as a whole amounts to no more than or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea. Accordingly, the additional element(s) do not integrate the abstract idea into a practical application because they do not recite any additional elements indicative of integration into a practical application. Rather, the claim as whole generally links the judicial exception to a technological environment defined by high level recitations of a computer and the Internet. Therefore, the claim is directed to an abstract idea and the analysis proceeds to Step 2B.
The additional elements, both individually and as an ordered combination, do not amount to significantly more than the judicial exception because the outcome of the considerations at Step 2B will be the same when the considerations from Step 2A.2 are reevaluated. As discussed under Step 2A.2, the additional element(s) amount to no more than performing the abstract idea by a generic computer. Because those instructions embody the abstract idea, the claim itself is merely a recitation of the abstract idea and an instruction to “apply it” on a computer. This is not enough to provide an inventive concept. Therefore, claims 1 are not patent eligible.
Dependent claims 3 further defines the first and the second tokens which further recites the abstract idea. The claim does not recite additional elements that integrate the abstract idea to a practical application nor provide significantly more than the abstract idea.
Dependent claims 5 further recite a ledger contract which further recites the abstract idea. The claim further recites additional element of “a smart contract …mints the second token”. The additional generally link the use of the judicial exception to a particular technological environment because the smart contract is used for its expected purpose of self-executing program. The claim does not recite how smart contract improve the computer functionality nor the technology of minting tokens. The additional elements fail to recite a practical application nor significantly more than the abstract idea.
Dependent claims 6 and 7 further defines the criteria which further recites the abstract idea. The claim does not recite additional elements that integrate the abstract idea to a practical application nor provide significantly more than the abstract idea.
Dependent claims 8 further recite initiating transfer which further recites the abstract idea. The claim further recites additional element of “a payment processing network”. The payment processing network is used for its expected purposed of transferring data. The claim does not recite improvement to the processing network itself nor how processing network is implemented to improve the computer functionality. The additional elements fail to recite a practical application nor significantly more than the abstract idea.
Dependent claims 16 further recite recording a second entry indicating transferring of token to the user which further recites the abstract idea. The claim further recites additional element of “distributed ledger”. The distributed ledger is used for its expected purposed of storing data. The claim does not recite improvement to distributed ledger itself nor how distributed ledger is implemented to improve the computer functionality. The additional elements fail to recite a practical application nor significantly more than the abstract idea.
In summary, the dependent claims considered both individually and as an ordered combination do not provide meaningful limitations to transform the abstract idea into a patent eligible application of the abstract idea such that the claims amount to significantly more than the abstract idea itself. The claims do not recite an improvement to another technology or technical field, an improvement to the functioning of the computer itself, or provide meaningful limitations beyond generally linking an abstract idea to a particular technological environment. Therefore, the claims are rejected under 35 U.S.C. § 101 as being directed to non-statutory subject matter.
Claim Rejections - 35 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 for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1, 3, 6-8 and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Furche (US 20170293912 A1), and further in view of Veeraraghavan (US 20080154784 A1) and Zinder (US 20080318670 A1).
With respect to claim 1:
Furche teaches (in italic):
receiving, from a first user, a request to redeem a first token having a first value. (The exchange request module is stored in the memory and executed by the processor to receive a first request from a first client to exchange a first set of Value Tokens of a first respective class redeemable by a first Mint for Value tokens of a second respective class redeemable by a second Mint. Device 1210 makes a request to Exchange 1230 to exchange the class A token for the class B token. [0038 0255])
the first token issued by a […] parties. (Optionally the system may also further include a double spending repository stored in the memory and containing information indicating tokens for which the Mint has issued a newly issued Value Token in exchange. [0038])
in response to the request, identifying, by a computing device of a token host, […], one of the multiple parties to settle a redemption of the first token, the token host including […] party-specific tokens[…]. (The Exchange makes an escrow request for the class B token to the Mint 1250 associated with that token, and receives an escrow confirmation. In this example, each issuer issues a respective class of Value Token using one or more Mints; each Mint may include one or more redemption and/or signing functions. In some cases, a particular Mint may both issue and redeem Value Tokens of a particular Class; in other cases these operations may reside at separate Mints. [0256 0263])
initiating, by the computing device, transfer of a second token, specific to the one of the multiple parties, to an account of the first user, in exchange for the first token. (Upon receipt of the newly issued Value Tokens, the newly issued class B token is sent to user 1's device 1210. [0256])
recording, by the computing device, an entry indicative of the redemption of the first token to an immutable ledger in communication with the computing device, the entry indicating burning of the first token. (accordingly, the swap relies on the Mint causing the previously issued Value Token to be considered invalid, e.g., by updating records in a way that others can determine that the Value Token has already been redeemed. Final (Indelible) transaction In some embodiments, as a token transaction always results in a token swap, a write once ledger may provide an indelible audit trail for such transactions. For example, the state of the system may be modified by appending transactions to a ledger so as to create an indelible record for those transactions. [0107 0422])
Furche does not explicitly teach the following limitations. However,
Veeraraghavan teaches:
a consortium of multiple parties. (Once purchased by a single buyer, or a buyer consortium, the sold consortium contract is divided according to the consortium contract terms agreed between parties. [0057-0058])
identifying, […] based on one or more criteria, one of the multiple parties to settle. (Once purchased by a single buyer, or a buyer consortium, the sold consortium contract is divided according to the consortium contract terms agreed between parties (such as volume of impressions contributed), as well as revenue share agreements (such as percentage of revenue shared for impression contribution), such that the consortium contract is split into sub-contracts between individual sellers and the buyer/buyers. [0057-0058])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system as disclosed by Furche to incorporating a consortium of multiple parties with the technique as disclosed by Veeraraghavan to improve trading efficiency as Veeraraghavan suggested [0006].
Furche in view of Veeraraghavan does not explicitly teach the following limitations. However,
Zinder teaches:
the token host including a token pool, which includes […] tokens for ones of the multiple parties. (Master agent 300 is responsible for ensuring that there is sufficient liquidity of tokens available to the various members in hierarchy 350 so as to enable players to play the casino games. the pool of tokens in circulation [0081-0082])
determining, by the computing device, that the token pool does not include a sufficient quantity of a second token, which is the […] token for said one of the multiple parties, to settle the redemption of the first token; in response to determining that the token pool does not include the sufficient quantity of the second token, automatically purchasing multiple of the second token from said one […] parties into the token pool. (Master agent 300 is responsible for ensuring that there is sufficient liquidity of tokens available to the various members in hierarchy 350 so as to enable players to play the casino games. When the number of issued tokens has reduced sufficiently, master agent 300 may purchase an additional quantity of tokens from issuer 320 so as to inject additional token liquidity into token management system 100. [0081])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system as disclosed by Furche in view of Veeraraghavan to check for balance of tokens and purchase more tokens with the technique as disclosed by Zinder to provide better liquidity as Zinder suggested [0081].
With respect to claim 3:
Furche further teaches:
wherein the first token includes multiple first tokens having the first value and the second token includes multiple second tokens. (A user 1's device 1210 has a token (or multiple tokens in class A) but user 1 wants tokens in class B. [0255])
wherein the multiple second tokens have a second value; wherein the first value of the multiple first tokens is equal to the second value. (For example, user A submits Value Tokens of Class A, issued by Mint A, (of total denomination n), to the Exchange X, and specifies that in return, he wants Value Tokens of Class B, issued by Mint B, (total denomination m). [0248])
With respect to claim 6:
Veeraraghavan further teaches wherein the one or more criteria is based on a percentage of tokens associated with each of the multiple parties. (Once purchased by a single buyer, or a buyer consortium, the sold consortium contract is divided according to the consortium contract terms agreed between parties (such as volume of impressions contributed), as well as revenue share agreements (such as percentage of revenue shared for impression contribution), such that the consortium contract is split into sub-contracts between individual sellers and the buyer/buyers. [0057-0058])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system to set criteria based on percentage own by each party with the technique as disclosed by Veeraraghavan to improve trading efficiency as Veeraraghavan suggested [0006].
With respect to claim 7:
Furche further teaches wherein the one or more criteria relate to an order of minting the first token relative to the second token. (In this example, each issuer issues a respective class of Value Token using one or more Mints; each Mint may include one or more redemption and/or signing functions. In some cases, a particular Mint may both issue and redeem Value Tokens of a particular Class; in other cases these operations may reside at separate Mints. The Mints may be configured to operationally provide either redemption, signing or both capabilities, so that a single Mint may act as a redeemer and a signer.. [0263])
With respect to claim 8:
Furche further teaches wherein initiating the transfer of the second token to the account of the first user includes initiating the transfer, via a payment processing network. (The system may also include escrow services 170, that provide escrow to facilitate exchange of various types of tokens between users, e.g., in a lower risk transaction where token exchanges are “pre-cleared” by having each side place a digital Value Token into escrow before the transaction is completed. The escrow services may be provided by Mints, or may be provided by separate elements that are in communication with the Mints. [0187])
With respect to claim 16:
Furche further teaches recording, by the computing device, a second entry to the distributed ledger indicating transfer of the second token to the first user. (accordingly, the swap relies on the Mint causing the previously issued Value Token to be considered invalid, e.g., by updating records in a way that others can determine that the Value Token has already been redeemed. Final (Indelible) transaction In some embodiments, as a token transaction always results in a token swap, a write once ledger may provide an indelible audit trail for such transactions. For example, the state of the system may be modified by appending transactions to a ledger so as to create an indelible record for those transactions. [0107 0422])
Claim(s) 5 is/are rejected under 35 U.S.C. 103 as being unpatentable over Furche Veeraraghavan and Zinder, and further in view of Lynn (US 20190340607 A1).
With respect to claim 5:
Furche further teaches:
immutable ledger. (accordingly, the swap relies on the Mint causing the previously issued Value Token to be considered invalid, e.g., by updating records in a way that others can determine that the Value Token has already been redeemed. Final (Indelible) transaction In some embodiments, as a token transaction always results in a token swap, a write once ledger may provide an indelible audit trail for such transactions. For example, the state of the system may be modified by appending transactions to a ledger so as to create an indelible record for those transactions. [0107 0422])
wherein the second token […] specific to said one of the multiple parties, through which said one of the multiple parties mints the second token for inclusion in the token pool. (In this example, each issuer issues a respective class of Value Token using one or more Mints; each Mint may include one or more redemption and/or signing functions. In some cases, a particular Mint may both issue and redeem Value Tokens of a particular Class; in other cases these operations may reside at separate Mints. The Mints may be configured to operationally provide either redemption, signing or both capabilities, so that a single Mint may act as a redeemer and a signer.. [0263])
Veeraraghavan further teaches wherein the first token is associated with a ledger contract […] where the ledger contract is specific to the token host. (Once purchased by a single buyer, or a buyer consortium, the sold consortium contract is divided according to the consortium contract terms agreed between parties (such as volume of impressions contributed), as well as revenue share agreements (such as percentage of revenue shared for impression contribution), such that the consortium contract is split into sub-contracts between individual sellers and the buyer/buyers. [0057-0058])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system to form contract with the technique as disclosed by Veeraraghavan to improve trading efficiency as Veeraraghavan suggested [0006].
Furche in view of Veeraraghavan and Zinder does not explicitly teach the following limitations. However,
Lynn teaches:
the token is associated with a smart contract. (This transfer function may then be published on the blockchain such that the smart contract (A managing entity may acquire a physical asset such as an artwork, and generate a plurality of blockchain tokens that adhere to a smart contract to represent a fractional ownership stake in the physical asset. [0024])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system as disclosed by Furche in view of Veeraraghavan and Zinder to associate token with smart contract with the technique as disclosed by Lynn to represent the ownership of tokens as Lynn suggested [0024].
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20220207605 A1: Systems and methods are provided for minting payment loan tokens to conduct digital loan transactions within a blockchain-based digital loan payment network. The payment loan tokens are pegged to fiat currency or digital currency. The computing system is a node in the blockchain-based digital loan payment network. A number of payment loan tokens to be provided to a borrower can be determined based on a digital loan transaction. The borrower is a network participant associated with the blockchain-based digital loan payment network. The number of payment loan tokens can be provided for deposit in a digital wallet associated with the borrower based on the digital loan transaction. Payees that receive payment loan tokens from the borrower can redeem the payment loan tokens as fiat or digital currency. A data record that represents the digital loan transaction can be generated. The data record is posted to a blockchain associated with the blockchain-based digital loan payment network.
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 ZESHENG XIAO whose telephone number is (571)272-6627. The examiner can normally be reached 10:00am-4:30pm M-F.
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 on (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.
/Z.X./Examiner, Art Unit 3698
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698
Prosecution Insights