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 .
DETAILED ACTION
This action is in response the application filed January 22, 2025. Claims 1-5 are pending and examined.
Specification
Applicant is required to update the status (pending, allowed, etc.) of all parent priority applications in the first line of the specification. The status of all citations of US filed applications in the specification should also be updated where appropriate.
Information Disclosure Statement
An initialed and dated copy of Applicant’s IDS form 1449 filed 12/22/2025, is attached to the instant Office action.
Examiner’s Note
The examiner did note that Sarkisyan at one point says the provisional application it is claiming priority to was filed Dec. 27, 2022 and in another it says it was filed Dec. 27, 2023 which was five days after the application claiming priority was itself filed. The examiner has confirmed that the provisional application being claimed priority was filed on Dec. 27, 2022.
Claim Rejections - 35 USC § 101 Utility
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–5 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
In sum, claims 1–5 are rejected under 35 U.S.C. §101 because the claimed invention is directed to a judicial exception to patentability (i.e., a law of nature, a natural phenomenon, or an abstract idea) and do not include an inventive concept that is something “significantly more” than the judicial exception under the January 2019 patentable subject matter eligibility guidance (2019 PEG) analysis which follows.
Under the 2019 PEG step 1 analysis, it must first be determined whether the claims are directed to one of the four statutory categories of invention (i.e., process, machine, manufacture, or composition of matter). Applying step 1 of the analysis for patentable subject matter to the claims, it is determined that the claims might be directed to the statutory category of a process (claims 1-5) or a machine (claims 1–5) but fail to meet the elements of either. The process has no structural elements and causes no physical transformation as for being a machine while it is called a “system” it has no structural elements. (See, e.g., MPEP §2106.03). Therefore, we proceed to step 2A, Prong 1.
Under the 2019 PEG step 2A, Prong 1 analysis, it must be determined whether the claims recite an abstract idea that falls within one or more designated categories of patent ineligible subject matter (i.e., organizing human activity, mathematical concepts, and mental processes) that amount to a judicial exception to patentability. Here, the claims recite the abstract idea of payment of commercial transactions comprising:
at least one user interaction block for registering and storing user identification data, identifying users, and receiving and processing user requests;
a block for issuing and/or registering electronic documents (EDs) that confirm certain financial obligations of the user who issues the ED or is designated in the ED to pay to the owner of the ED, under the conditions specified in the ED, the amount of money specified in the ED in the currency specified in the ED, or its equivalent, wherein the issuance block being capable of encrypting and storing information about EDs;
a block for creating, signing, encrypting, and storing smart contracts, including smart contracts for issuing EDs, smart contracts for purchasing EDs, smart contracts for selling EDs, and smart contracts for purchasing and selling EDs, wherein each smart contract has an identification number for accounting and identifying smart contracts by the system and wherein the encrypted data of smart contracts is distributed and stored across multiple electronic storage facilities combined into a single network;
a block for forming a closed chain of smart contracts for the purchase and sale of EDs from corresponding smart contracts for purchasing EDs and smart contracts for selling EDs among at least three users, including at least one smart contract for purchasing EDs and one smart contract for selling EDs in a currency different from the currency of payment for the other smart contracts, wherein the abovementioned block is connected to the block for creating, signing, encrypting, and storing smart contracts
Here, the recited abstract idea falls within one or more of the three enumerated 2019 PEG categories of patent ineligible subject matter, to wit: the category of certain methods of organizing human activity, which includes fundamental economic practices or principles and commercial or legal interactions (e.g., creating a contract even if it is recorded as an electronic document that is registered and or implemented as a smart contract).
Under the 2019 PEG step 2A, Prong 2 analysis, the identified abstract idea to which the claim is directed does not include limitations that integrate the abstract idea into a practical application, since the recited features of the abstract idea are being applied on a computer or computing device or via software programming that is simply being used as a tool (“apply it”) to implement the abstract idea. (See, e.g., MPEP §2106.05(f)). Therefore, the claim is directed to an abstract idea.
Under the 2019 PEG step 2B analysis, the additional elements are evaluated to determine whether they amount to something “significantly more” than the recited abstract idea. (i.e., an innovative concept). Here, the additional elements, such as: a block for creating, signing, encrypting, and storing smart contracts do not amount to an innovative concept since, as stated above in the step 2A, Prong 2 analysis, the claims are simply using the additional elements as a tool to carry out the abstract idea (i.e., “apply it”) on a computer or computing device and/or via software programming. (See, e.g., MPEP §2106.05(f)). The additional elements are specified at a high level of generality to simply implement the abstract idea and are not themselves being technologically improved. (See, e.g., MPEP §2106.05 I.A.).
Dependent claims 2–5 have all been considered and do not integrate the abstract idea into a practical application. Dependent claim recites limitations that further define the abstract idea noted in claim 1 as they describe a block for assigning and recording the status of users and/or electronic documents acquired and/or issued by users. That is tracking the parties to a contract and whether the terms of the contract have been fulfilled. Dependent claim 3 recites limitations that further define the abstract idea noted in claim 1 as they describe block for creating, signing, encrypting, and storing smart contracts is designed to create, sign, encrypt, and store smart contracts for purchasing goods or services by a user of the system and smart contracts for selling goods or services by a user of the system. That is tracking the parties to a contract and whether the terms of the contract have been fulfilled. Dependent claim 4 recites limitations that further define the abstract idea noted in claim 1 as they describe a block for assigning of and accounting for the status of smart contracts. That is tracking the parties to a contract and whether the terms of the contract have been fulfilled. Dependent claim 5 recites limitations that further define the abstract idea noted in claim 1 as they describe block for creating, signing, encrypting, and storing smart contracts is designed to create, sign, encrypt, and store smart contracts for dividing EDs and/or smart contracts for combining EDs and/or smart contracts for the exchange of EDs purchased and/or issued by users of the system. This is the type of generic component being used to carry out the abstract idea noted in claim 1..
The additional elements of the dependent claims merely refine and further limit the abstract idea of the independent claims and do not add any feature that is an “inventive concept” which cures the deficiencies of their respective parent claim under the 2019 PEG analysis. None of the dependent claims considered individually, including their respective limitations, include an “inventive concept” of some additional element or combination of elements sufficient to ensure that the claims in practice amount to something “significantly more” than patent-ineligible subject matter to which the claims are directed.
The elements of the instant process steps when taken in combination do not offer substantially more than the sum of the functions of the elements when each is taken alone. The claims as a whole, do not amount to significantly more than the abstract idea itself because the claims do not effect an improvement to another technology or technical field (e.g., the field of computer coding technology is not being improved); the claims do not amount to an improvement to the functioning of an electronic device itself which implements the abstract idea (e.g., the general purpose computer and/or the computer system which implements the process are not made more efficient or technologically improved); the claims do not perform a transformation or reduction of a particular article to a different state or thing (i.e., the claims do not use the abstract idea in the claimed process to bring about a physical change. See, e.g., Diamond v. Diehr, 450 U.S. 175 (1981), where a physical change, and thus patentability, was imparted by the claimed process; contrast, Parker v. Flook, 437 U.S. 584 (1978), where a physical change, and thus patentability, was not imparted by the claimed process); and the claims do not move beyond a general link of the use of the abstract idea to a particular technological environment (e.g., simply claiming the use of a computer and/or computer system to implement the abstract idea).
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 of this title, 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.
Claims 1-5 are rejected under 35 U.S.C. 103 as being unpatentable over Sheng et al. (USPG 2019/0340,586 A1) in view of Sarkisyan et al. (USPG 2024/0161118 Al).
As per claim 1 Sheng teaches:
A system for the payment of commercial transactions comprising:
a block for issuing and/or registering electronic documents (EDs) that confirm certain financial obligations of the user who issues the ED or is designated in the ED to pay to the owner of the ED, under the conditions specified in the ED, the amount of money specified in the ED in the currency specified in the ED, or its equivalent, wherein the issuance block being capable of encrypting and storing information about EDs; (see at least Sheng paragraphs 33-35 “[0033] FIG. 3 is a diagram of an exemplary screenshot of a user interface 300 on the client computing device. As shown in FIG. 3, the user interface provides a first dropdown 302 box in which the user can select the currency to be withdrawn from his electronic wallet (in this case, BTC) and a second drop-down box 304 in which the user can select the currency to be received into his electronic wallet in exchange (in this case, ETH). For example, the user can maintain one electronic wallet (or multiple electronic wallets) that store information associated with transactions on different blockchains that are associated with the user's cryptocurrency balances. Generally, an electronic wallet (or digital wallet) in this context is a software program that stores public and private cryptography key pairs, which are used by exchanges to withdraw currencies from or deposit currencies to the electronic wallet. The wallet can be stored locally (e.g., on a client device) or in a centralized location (e.g., on a remote server, cloud infrastructure, wallet provider, etc.). A wallet can also be backed up to ensure security of the wallet, typically via an encrypted file that contains all of the private keys.
[0034] In one example, to withdraw funds from an electronic wallet, a computing device that executes the electronic wallet software generates a payment instruction that indicates certain information, such as: currency type, currency amount, and address of the electronic wallet to which the currency will be sent. The computing device then digitally signs the payment instruction using the private key stored in the electronic wallet-which demonstrates ownership of the currency in the electronic wallet. The computing device transmits the signed payment instruction to any of the other computing devices (i.e., a validator node) that comprise the network ( e.g., in a single blockchain or across blockchains ). The other computing device verifies the signed payment instruction both technically and substantively. For example, each computing device analyzes the technical attributes of the payment instruction ( e.g., format, message size, version numbering, and the like) to ensure that the payment instruction complies with the technical requirements of the corresponding blockchain. The other computing device also analyzes the substantive attributes of the payment instruction (e.g., is the destination address valid?, does the wallet have enough currency to make the payment?, has the currency already been spent?) to ensure that the payment instruction can be processed by the blockchain.
[0035] Once both sets of tests noted above are complete and confirmed, the other computing device forwards the payment instruction to all of the other computing devices in the blockchain-and each of these devices runs the same validation tests as set forth above. When this phase is complete, each device stores the payment transaction in a pool of unconfirmed transactions, awaiting the addition of the next block to the blockchain in order to be confirmed.”)
a block for creating, signing, encrypting, and storing smart contracts, including smart contracts for issuing EDs, smart contracts for purchasing EDs, smart contracts for selling EDs, and smart contracts for purchasing and selling EDs, wherein each smart contract has an identification number for accounting and identifying smart contracts by the system and wherein the encrypted data of smart contracts is distributed and stored across multiple electronic storage facilities combined into a single network;
a block for forming a closed chain of smart contracts for the purchase and sale of EDs from corresponding smart contracts for purchasing EDs and smart contracts for selling EDs among at least three users, including at least one smart contract for purchasing EDs and one smart contract for selling EDs in a currency different from the currency of payment for the other smart contracts, wherein the abovementioned block is connected to the block for creating, signing, encrypting, and storing smart contracts. (see at least Sheng paragraphs 96-99 “[0096] Also, it should be appreciated that the prediction techniques described herein can leverage the Etherium Request for Comments (ERC)-20 token standard (e.g., as defined at theetherium.wiki/w/index.php/ERC20_Token_Standard) to better predict how various tokens ( e.g., associated with initial coin offerings (ICOs), altcoins, and the like) will function within a larger blockchain/smart contract system, such as Etherium. ERC-20 defines specific functions and events that token contracts in Etherium have to implement, such as totalSupply( ), balanceOf( ), allowance( ), transfer( ), approve( ), transferFrom( ) functions and Transfer and Approval events. Because each of these tokens complies with the ERC-20 standard, the use of smart contracts to transfer such tokens is uniform and accessible and as such, the movement in token prices for many (if not all) of the tokens will rise and fall somewhat consistently with each other-which makes prediction of such prices easier and more efficient for the system described herein, resulting in consumption of less computing power and resources.
[0097] Turning back to FIGS. 2 and 3, once the cryptocurrency trading module 106e has identified a sequence of currency transactions that has an optimal value, the cryptocurrency trading module 106e executes (208) the identified sequence of currency transactions associated with the optimal value. For example, the user interface 300 of FIG. 3 will reflect the amount of the second currency that represents the optimal conversion (e.g., ETH 6.983664) and the user can select the ' Start Exchange' button to execute the sequence of currency transactions.
[0098] The following exemplary message depicts the sequence of currency transactions that has an optimal value as identified and encoded by the cryptocurrency trading module 106e (in a JSON format): ' exchange' : eg. hitbtc.com 'market': source and target, e.g., LTC -> BTC "amount': in the volume of the source ' price' : predefined price, if left unfilled, taking the market price. ' direction ' : buy or sell
[0099] FIG. 5 is a flow diagram of a computerized method 500 of executing an identified sequence of currency transactions, using the system 100 of FIG. 1. The cryptocurrency trading module 106e of server computing device 106 verifies (502) one or more data elements of the electronic wallet associated with the user of the client computing device 102a. For example, the cryptocurrency trading module 106e can validate specific elements of the wallet such as: user account information (e.g., name, ID number, wallet address), user's cell phone number, two-step confirmation code, and the like. The module 106e can also verify that the user's electronic wallet has sufficient funds in the currency to be converted.” The cryptocurrency transactions are purchasing and selling Electronic Documents because the various cryptocurrencies are Electronic Documents and the complicated path can certainly include at least three users.)
While Sheng is not explicit about registering users identifying them and receiving and processing user requests encryption as part of the blockchain Sarkisyan teaches such functionality as part of an “INTEGRATED SYSTEM AND METHOD FOR SMART CONTRACT CREATION, ASSET REGISTRATION, AND BLOCKCHAIN INTEGRATION WITH CONSENSUS ORDER AND WALLET TRANSACTIONS” (see at least Sarkisyan Title and Paragraphs 109-113, 119, and 132 “(0109] Users can seamlessly register within the system, gaining access to a personalized account. This registration process requires users to verify their identity (using both internal/external verification such as ID.me) and input personal credentials, including, but not limited to, taxpayer IDs. Moreover, users are prompted to upload documentation that substantiates their registration, alongside other personal details like email, registered address, and biometric data, all in alignment with the system's internal protocols and parameters. Users will also need to upload information verifying their business establishment, including TIN, certificate of good standing, and other relevant documents.
[0110] Once registered, a user can draft contracts with fellow users by assembling pre-designed jurisdictional compliant templates, and input the requisite details to finalize the document.
[0111] A user can sign the created document with other users within the system software by issuing an invitation to sign the document. The creation, order of signing, and other document attributes, terms and methods of execution may be dictated by a system consensus scheme.
[0112] Counteroffers, amendments, and comments are uploaded to the contract before signing and sent out for confirmation or edits from the other users.
[0113] Upon signing by all parties, the smart contract is rendered or deemed complete or executed and the smart contracts are stored in the user's personal account along with the entire history of changes that are recorded in the decentralized registry (blockchain). Users can also upload their own agreements and send them to signatories with a bespoke consensus scheme. Both the assembled legal smart contracts and uploaded contracts are stored on the blockchain after all signatures have been completed. The history of document changes can be useful in future disputes regarding the meaning of terms.
[0119] Using hyper-secure encryption and decryption, the executed contract has its own unique code that's stored in the blockchain as NFTs and decrypted into a signed PDF if necessary.
[0132] Advanced Security: All blockchain transactions conducted via the wallet adhere to the AES-256 encryption standard, reinforcing the platform's commitment to secure, reliable, and confidential operations.”) Therefore it would have been obvious to a person of ordinary skill in the art at the time the invention was made to register users and storing their user identification information since it was solving a known problem in a known way with an expectation of success.
As per claim 2 Sheng teaches:
The system for the payment of commercial transactions, according to claim 1, wherein it includes a block for assigning and recording the status of users and/or electronic documents acquired and/or issued by users. (see at least Sheng paragraph 15 “[0015] In some embodiments, withdrawing the amount of the first currency from the electronic wallet and storing the amount of the withdrawn first currency in a temporary cache of the database comprises adding a transaction entry to a blockchain associated with the first currency, the transaction comprising the amount of the first currency and an address of the electronic wallet. In some embodiments, transmitting the amount of the second currency to an address of the electronic wallet associated with the user of the first client computing device comprises adding a transaction entry to a blockchain associated with the second currency, the transaction comprising the amount of the second currency and the address of the electronic wallet.” Recording entries in the blockchains for each user that was involved in the transaction satisfies this element.)
As per claim 4 Sheng teaches:
The system for the payment of commercial transactions according to claim 1, wherein it includes a block for assigning of and accounting for the status of smart contracts. (see at least Sheng paragraph 15 “[0015] In some embodiments, withdrawing the amount of the first currency from the electronic wallet and storing the amount of the withdrawn first currency in a temporary cache of the database comprises adding a transaction entry to a blockchain associated with the first currency, the transaction comprising the amount of the first currency and an address of the electronic wallet. In some embodiments, transmitting the amount of the second currency to an address of the electronic wallet associated with the user of the first client computing device comprises adding a transaction entry to a blockchain associated with the second currency, the transaction comprising the amount of the second currency and the address of the electronic wallet.” Recording entries in the blockchains for each user that was involved in the transaction satisfies this element.)
As per claims 3 and 5 while Sheng is not explicit about creating smart contracts Sarkisyan teaches such functionality as part of an “INTEGRATED SYSTEM AND METHOD FOR SMART CONTRACT CREATION, ASSET REGISTRATION, AND BLOCKCHAIN INTEGRATION WITH CONSENSUS ORDER AND WALLET TRANSACTIONS” (see at least Sarkisyan Title and Paragraphs 109-113, 119, and 132“) Therefore it would have been obvious to a person ordinary skill in the art at the time the invention was made since it was solving known problems in a known way with an expectation of success.
Conclusion
Any inquiry concerning this communication from the examiner should be directed to Scott S. Trotter, whose telephone number is 571-272-7366. The examiner can normally be reached on 8:30 AM – 5:00 PM, 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, Matthew Gart, can be reached on 571-272-3955.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
The fax phone number for the organization where this application or proceeding is assigned are as follows:
(571) 273-8300 (Official Communications; including After Final Communications labeled “BOX AF”)
(571) 273-7366 (Draft Communications)
/SCOTT S TROTTER/Primary Examiner, Art Unit 3696