DETAILED ACTION
Status of Application
This action is a Non-Final Rejection. This action is in response to the request for continued examination filed on July 16, 2026.
Claim 1 has been amended.
Claims 1-20 are pending and rejected.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . 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 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.
Response to Arguments
Regarding the rejection under 35 U.S.C. § 101, Applicant points to Example 42 and asserts that the instant claims are eligible for similar reasons. Remarks at 11-12. Claim 1 of Example 42 was determined to be eligible because “the additional elements recite[d] a specific improvement over prior art systems by allowing remote users to share information in real time in a standardized format regardless of the format in which the information was input by the user.” Applicant has not shown that the instant claims recite a similar type of technological improvement. Instead, the instant claims are more similar to claim 2 of Example 42, which used a computer as a tool to perform an existing medical records update process.
Applicant further points to the CosmoKey decision and asserts that the instant claims similarly integrate the abstract idea into a practical application because “the entire transaction is performed using a distributed ledger, improving payment security.” Remarks at 12. Per the Federal Circuit in CosmoKey, the “the ‘903 patent discloses a technical solution to a security problem in networks and computers.” On the other hand, the instant application provides an allegedly improved method of sending digital cash using NFTs. The alleged improvement is not to technology such as a network, a computer, blockchain, etc. Instead, the abstract idea is being allegedly improved.
Applicant further argues that “the claims are ‘significantly more’ than the alleged abstract idea and provide an inventive concept, as they are limited to very unique and inventive, namely, creating from scratch and providing unique, singular NFTs to payers and payees. In addition, typical NFTs do not include smart contracts, while the claimed NFTs do include smart contracts.” Remarks at 12-13. However, Applicant has not shown that the claims provide an improvement to NFT or smart contract technology. Instead, they are being used to implement the abstract idea.
As such, the rejection under 35 U.S.C. 101 is maintained.
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-20 are rejected under 35 U.S.C. § 101 as being directed to non-statutory subject matter because the claimed invention is directed to an abstract idea without significantly more.
Step 1: Does the Claim Fall within a Statutory Category? (see MPEP 2106.03)
No, with respect to claims 1-18, which recite “[a]n e-cash payment computer program product, the computer program product comprising executable instructions stored on non-transitory memory of a computer system.” Although “stored on non-transitory memory of a computer system” was added to the claim, the non-transitory memory is not positively recited. Instead, the executable instructions are positively recited and described as stored on a non-transitory memory. Therefore, broadest reasonable interpretation of the claimed computer program product includes software and signals. Therefore, claims 1-18 are directed to software per se and signals per se. Because software and signals are not a statutory category, these claims are ineligible. To overcome this rejection, the claims should positively recite hardware or the non-transitory memory. Although these claims are ineligible at step 1, they are being analyzed below with respect to the other steps.
Yes, with respect to claim 19, which recites a method and, therefore, is directed to the statutory class of process.
Yes, with respect to claim 20, which recites an apparatus and, therefore, is directed to the statutory class of machine or manufacture.
Step 2A, Prong One: Is a Judicial Exception Recited? (see MPEP 2106.04(a))
The following claims identify the limitations that recite the abstract idea in regular text and that recite additional elements in bold:
1. An e-cash payment computer program product, the computer program product comprising executable instructions stored on non-transitory memory of a computer system, the executable instructions when executed by a processor on a computer system:
assign, to each of two or more users, a separate wallet on a distributed ledger, wherein:
each user comprises a computer device running the computer program product; and
at least one of the two or more users is a payee and at least one of the two or more users is a payor;
establish, over a computer network, a connection between each computer device;
receive, via the connection and from one of the two or more users, one or more payment terms;
initiate a payment from the payor according to the one or more payment terms;
mint a non-fungible token (“NFT”) comprising metadata and one or more smart contracts within the wallet assigned to the payor;
transmit, via the connection, an option to the payee to accept or reject a transfer of the NFT;
when the payee accepts the transfer of the NFT, transfer, via the connection and after receiving an authorization from the payor, the NFT to the wallet assigned to the payee;
confirm receipt of the NFT at the payee distributed ledger wallet; and
convey the e-cash as instructed by the payee; and
permanently record the payment on the distributed ledger;
wherein:
the e-cash comprises a digital representation of a portion of funds available to the payor;
the NFT is singular;
the one or more payment terms comprise:
an identity of the payor;
an identity of the payee;
an amount of the payment;
the e-cash; and
one or more options to convey the e-cash selectable by the payee; and
the one or more smart contracts comprise code created by:
a request intent extractor configured to determine an intent for the one or more smart contracts;
an intelligent feature processor configured to:
determine which one or more features located within a central feature catalog corresponds with the intent and are compatible with the distributed ledger; and
transmit the determined one or more features to a multi-module real-time intelligent feature bundler; and
the multi-module real-time intelligent feature bundler is configured to:
receive the one or more determined features;
extract source code corresponding to the one or more determined features from a store of source code; and
bundle the extracted source code to create the one or more smart contracts.
2. The e-cash payment computer program of claim 1 wherein one or more of the one or more payment terms are encrypted.
3. The e-cash payment computer program of claim 1 wherein the NFT is encrypted.
4. The e-cash payment computer program of claim 1 wherein the payee distributed ledger wallet and the payor distributed ledger wallet are located on one distributed ledger.
5. The e-cash payment computer program of claim 1 wherein the one or more payment terms are accessed through a hyperlink.
6. The e-cash payment computer program of claim 1 wherein the NFT is machine-readable.
7. The e-cash payment computer program of claim 1 wherein the program transmits a report to the payor when one or more of the following occurs:
1) the NFT is viewed; and
2) the payment is conveyed.
8. The e-cash payment computer program of claim 1 wherein one or more of: the request intent extractor; the intelligent feature processor; and the multi-module real-time intelligent feature bundler utilize one or more artificial intelligence/machine learning (“AI/ML”) algorithms.
9. The e-cash payment computer program of claim 8 wherein the one or more AI/ML algorithms analyze the one or more payment terms, historical data of the payor, historical data of the payee, and metadata.
10. The e-cash payment computer program of claim 1 wherein the NFT expires after a pre-determined amount of time.
11. The e-cash payment computer program of claim 10 wherein the pre-determined amount of time is set by the payor.
12. The e-cash payment computer program of claim 10 wherein the pre-determined amount of time is determined automatically through one or more AI/ML algorithms.
13. The e-cash payment computer program of claim 10 wherein when the NFT expires, all e-cash unused by the payee is returned to the payor.
14. The e-cash payment computer program of claim 1 wherein the computer network is wi-fi based.
15. The e-cash payment computer program of claim 1 wherein the computer network is li-fi based.
16. The e-cash payment computer program of claim 1 wherein one of the one or more options to convey the e-cash selectable by the payee comprises an option to convert from one currency to another currency.
17. The e-cash payment computer program of claim 1 wherein the e-cash is automatically converted from one currency to another currency.
18. The e-cash payment computer program of claim 1 wherein when the payee fails to select one of the one or more options within a predetermined amount of time, the NFT is automatically returned to the wallet assigned to the payor.
19. A method for utilizing a non-fungible token (“NFT”) for e-cash payment, the method comprising:
assigning, to each of two or more users, a separate wallet on a distributed ledger, wherein:
each user comprises a computer device; and
at least one of the two or more users is a payee and at least one of the two or more users is a payor;
establishing, over a computer network, a connection between each computer device;
receiving, via the connection and from one of the two or more users, one or more payment terms;
initiating a payment from the payor according to the one or more payment terms;
minting a non-fungible token (“NFT”) comprising metadata and one or more smart contracts within the wallet assigned to the payor;
transmitting, via the connection, an option to the payee to accept or reject a transfer of the NFT;
when the payee accepts the transfer of the NFT, transferring, via the connection and after receiving an authorization from the payor, the NFT to the wallet assigned to the payee;
confirming receipt of the NFT at the payee distributed ledger wallet; and
conveying the e-cash as instructed by the payee;
wherein:
the e-cash comprises a digital representation of a portion of funds available to the payor;
the NFT is singular;
the one or more payment terms comprise:
an identity of the payor;
an identity of the payee;
an amount of the payment;
the e-cash; and
one or more options to convey the e-cash selectable by the payee; and
the one or more smart contracts comprise code created by:
a request intent extractor configured to determine an intent for the one or more smart contracts;
an intelligent feature processor configured to:
determine which one or more features located within a central feature catalog corresponds with the intent and are compatible with the distributed ledger; and
transmit the determined one or more features to a multi-module real-time intelligent feature bundler; and
the multi-module real-time intelligent feature bundler is configured to:
receive the one or more determined features;
extract source code corresponding to the one or more determined features from a store of source code; and
bundle the extracted source code to create the one or more smart contracts.
20. An apparatus for e-cash payment utilizing distributed ledger technology, the apparatus comprising:
one or more computers running a distributed ledger;
a database comprising:
a central feature catalog; and
a store of source code;
a payor computer device comprising:
a payor communication link;
a payor processor;
a payor non-transitory memory configured to store at least:
an operating system; and
an e-cash payment computer program; and
a payee computer device comprising:
a payee communication link;
a payee processor;
a payee non-transitory memory configured to store at least:
an operating system; and
the e-cash payment computer program;
wherein:
the e-cash comprises a digital representation of a portion of funds available to the payor;
a wallet on the distributed ledger is assigned to the payor;
a wallet on the distributed ledger is assigned to the payee;
a connection, over a computer network, is established between the payor computer device and the payee computer device;
the payee computer device transmits, via the connection, one or more payment terms comprising: an identity of the payor, an identity of the payee, an amount of the payment, a location of one or more assets comprising the payment, and one or more options to convey the e-cash selectable by the payee;
the payor computer device receives, via the connection, the one or more payment terms;
the payor computer device initiates a payment according to the one or more payment terms;
the e-cash payment program:
mints a singular non-fungible token (“NFT”) comprising metadata and one or more smart contracts within the wallet assigned to the payor;
transmits, via the connection, an option to the payee to accept or reject a transfer of the NFT;
when the payee accepts the transfer of the NFT, transfers, via the connection and after receiving an authorization from the payor, the NFT to the wallet assigned to the payee;
confirms receipt of the NFT at the payee distributed ledger wallet; and
conveys the e-cash as instructed by the payee; and
the one or more smart contracts comprise code created by:
a request intent extractor configured to determine an intent for the one or more smart contracts;
an intelligent feature processor configured to:
determine which one or more features located within a central feature catalog corresponds with the intent and are compatible with the distributed ledger; and
transmit the determined one or more features to a multi-module real-time intelligent feature bundler; and
the multi-module real-time intelligent feature bundler is configured to:
receive the one or more determined features;
extract source code corresponding to the one or more determined features from a store of source code; and
bundle the extracted source code to create the one or more smart contracts.
Yes. But for the recited additional elements as shown above in bold, the remaining limitations of the claims recite certain methods of organizing human activity. The claims are directed to payments. This type of method of organizing human activity is a fundamental economic practice because it involves the processing of payments and a commercial interaction such as agreements in the form of contracts, legal obligations, sales activities or behaviors, and business relations. Thus, the claims recite an abstract idea.
Step 2A, Prong Two: Is the Abstract Idea Integrated into a Practical Application? (see MPEP 2106.04(d))
No. The claims as a whole merely use a computer as a tool to perform the abstract idea. The computing components (i.e., additional elements that are in bold above) are recited at a high level of generality and are merely invoked as a tool to implement the steps. For example, only a programmed general purpose computing device is needed to implement the claimed process. Simply implementing the abstract idea on a generic computer is not a practical application of the abstract idea. Furthermore, the abstract idea is merely being linked to a particular technological environment, i.e., a distributed ledger environment. Employing well known technology within a distributed ledger environment to execute the abstract idea, even when limiting the use of the abstract idea to this environment, does not integrate the exception into a practical application or add significantly more. Additionally, there is no improvement to the functioning of a computer or technology. Therefore, the abstract idea is not integrated into a practical application.
Step 2B: Does the Claim Provide an Inventive Concept? (see MPEP 2106.05)
No. As discussed with respect to Step 2A, Prong 2, the additional elements in the claims, both individually and in combination, amount to no more than tools to perform the abstract idea. Merely performing the abstract idea using a computer cannot provide an inventive concept. Therefore, the claims do not provide an inventive concept.
As such, the claims are not patent eligible.
Note Regarding Prior Art
The instant claims do not include a rejection under 35 U.S.C. 102 or 103. Although individual limitations and concepts are known in the art, the claimed embodiment was not found in or made obvious by the prior art.
Relevant Prior Art
The following references are relevant to Applicant’s invention:
Irizarry, U.S. Patent Application Publication Number 2024/0378606 A1. This reference teaches NFT ownership authentication and distribution.
Zamora et al., U.S. Patent Number 12,288,207 B2. This reference teaches a digital checking system that uses NFTs.
Revankar et al., U.S. Patent Application Publication Number 2020/0119905 A1. This reference teaches a smart contract platform for generating and customizing smart contracts.
Rice, U.S. Patent Application Publication Number 2019/0392536 A1. This reference teaches creating and managing a smart contract on a distributed ledger.
Email Communications
Per MPEP 502.03, Applicant may authorize email communications by filing Form PTO/SB/439, available at https://www.uspto.gov/sites/default/files/documents/sb0439.pdf, via the USPTO patent electronic filing system.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ELIZABETH H ROSEN whose telephone number is (571) 270-1850 and email address is elizabeth.rosen@uspto.gov. The examiner can normally be reached Monday - Friday, 10 AM ET - 7 PM ET.
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, Michael Anderson, can be reached at 571-270-0508. 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.
/ELIZABETH H ROSEN/Primary Examiner, 3693
Prosecution Insights