DETAILED ACTION
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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on December 22, 2023 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Drawings
The drawings submitted on December 22, 2023 are acceptable.
Claim Objections
Claims 1 and 2 objected to because of the following informalities:
In clam 1, the term “the template” lack of antecedent basis. For example, “a contract template” was previously claimed and there is no consistency in the terminology.
In clam 2, the term “a user wallet” should clearly indicate that they are a first user wallet and a second user wallet.
Appropriate correction is required.
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.
Claims 1-3 are 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 1 recite, in part, “the system hashing the contract to create a hash value and the system…”. However, there is no a system being claimed.
Claim 2 recite, in part, “… to transmit a contract completed message to the system …”, “…a user wallet within the system…” and “…the system transferring assets from…”. However, there is no a system being claimed.
Claim 2 recite, in part “…the second user to transmit a contract completed”. It is not clear it if the same contract as claim 1 (a) or not.
Claim 3 recite, in part “… the system confirming or declining …”. However, there is no a system being claimed.
In claim 3, the term “the system registry” lack of antecedent basis. Appropriated correction is required.
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 are rejected under 35 U.S.C. 101 because the claimed invention recites and is directed to a judicial exception to patentability (i.e., an abstract idea) and does not provide an integration of the recited abstract idea into a practical application nor include an inventive concept that is “significantly more” than the recited abstract idea to which the claim is directed. MPEP §2106.
In determining subject matter eligibility in an Alice rejection under 35 U.S.C. §101, it is first determined as Step 1 whether the claims are directed to one of the four statutory categories of an invention (i.e., a process, a machine, a manufacture, or a composition of matter). MPEP §2106.03.
Here, the claims are directed to the statutory category of a process (Claims 1-3). Therefore, we proceed to Step 2A, Prong 1. MPEP §2106.
Under a Step 2A, Prong 1 analysis, it must be determined whether the claims recite an abstract idea that falls within one or more enumerated categories of patent ineligible subject matter that amounts to a judicial exception to patentability. MPEP §2106.04. Independent Claim 1 is selected as being representative of the independent claims in the instant application. Claim 1 recites:
A method for the creation of smart contracts, asset registration and block chain
integration, the method comprising the steps of:
a) using a contract database (110) enabling a first user to select a contract
template with the template keyed to a selected jurisdiction;
b) enabling the first user to add data to the contract template and saving the
contract template into a registry (120);
c) enabling the first user to send invitations to other parties to sign the contract,
the selection including a consensus order;
d) enabling a second user to sign the contract;
e) the system hashing the contract to create a hash value and the system
storing the hash value in a blockchain.
Here, the claims recite an abstract idea, or combination of abstract ideas, of securing and storing an edited multi-party signed contract and selected from a contract templates. This concept/abstract idea, which is identified in the bolded sections seen above, falls within the Certain Methods of Organizing Human Activity grouping because it describes a commercial or legal interactions (e.g., including agreements in the form of contracts).
Accordingly, it is determined that the claims recite an abstract idea since they fall within one or more of the three enumerated categories of patent ineligible subject matter. MPEP §2106.04.
Since it is determined that the claim(s) contain a judicial exception, it must then be determined, under Step 2A, Prong 2, whether the judicial exception is integrated into a practical application of the exception. MPEP §2106.04. In order to make this determination, the additional element(s) are analyzed to determine if the claim as a whole integrates the recited judicial exception into a practical application of that exception. Here claim 1 recites the additional elements of smart contracts, blockchain, a contract database, a registry and a system. These additional elements are all recited at a high-level of generality such that they amount to no more than mere instructions to apply the exception, or a portion thereof, using a generic computer component. See MPEP 2106.05(f). Additionally, Examiner finds no indication in the Specification, that the operations recited in the independent claims require any specialized computer hardware or other inventive computer components, i.e., a particular machine, invoke any allegedly inventive programming, or that the claimed invention is implemented using other than generic computer components to perform generic computer functions. Furthermore, there is no indication in the claim(s) that the use of smart contracts, blockchain, a contract database, a registry and a system in combination with the abstract idea leads to an improvement of the processor, memory, another technology, or to a technical field. Accordingly, the additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. Looking at the elements as a combination does not add anything more than the elements analyzed individually. Examiner further notes that even though the claims may not preempt all forms of the abstraction, this alone, does not make them any less abstract.
When analyzed under step 2B, the claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional element of using a generic computing component (e.g., smart contracts (e.g., executable code/rules) , blockchain (e.g., database), a contract database, a registry and a system.) to implement the abstract idea amounts to no more than mere instructions to apply the exception using a generic computer component. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept or significantly more than the judicial exception. Considered as an ordered combination, the additional elements recited in the claim(s) add nothing that is not already present when the steps are considered separately.
Therefore, claim 1 is rejected under 35 U.S.C. §101 and are not patent eligible. Dependent claims 2-3 when analyzed are held to be patent ineligible under 35 U.S.C. §101 because the additional recited limitation(s) fail to establish that the claim(s) is/are not directed to an abstract idea.
Dependent claim 2 further refines the abstract idea by indicating that users can transmit a contract completed message to the system and further indicate the creation of a user wallet. This claim fails to include any new additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Dependent claim 3 further refines the abstract idea by indicating that the user can create templates and registration of these templates to the system. This claim fails to include any new additional elements that integrate the abstract idea into a practical application or provide 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 ideas 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 dependent claims are also not patent eligible.
Accordingly, it is determined that all claims are directed to non-statutory subject matter under 35 U.S.C. 101 and are ineligible.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The 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-2 is/are rejected under 35 U.S.C. 103 as being unpatentable over Turgman (US 2020/0364813 A1) in view of Ponceleon, (US 2020/0387910 A1), in view of Kurani (US 12,282,903 B1)
Regarding claim 1: Turgman disclose:
A method for the creation of smart contracts, asset registration and block chain integration, the method comprising the steps of:
a) using a contract database (110) enabling a first user to select a contract template with the template;(See at least Turgman, [Abs.; Fig. 1; [0008-0009]; [0037]; [0062]. Where using a contract database (i.e., smart contact template library) a user is enabled to select a contract template (i.e., select a smart contract template).)
b) enabling the first user to add data to the contract template and saving the contract template into a registry (120); (See at least Turgman, [0047]; [0050]; [0067-0068]. where the first user is enabled to add data to the contract template (i.e., user-fillable or definable fields) and the contract template is saved into a registry (i.e., the smart contract may be deployed to blockchain network 112).
c) enabling the first user to send invitations to other parties to sign the contract, the selection including a consensus order; (See at least Turgman, Fig. 9A; [0067]; Users may collaboratively fill out smart contract template via a communication session (e.g., via phone, chat, video chat, etc.), where each user is enabled to specify the terms of smart contract template 402 based on the conversation between the users.)
d) enabling a second user to sign the contract; (See at least Turgman, Fig. 9A; Fig. 9B; Fig.; 11; Fig; 14-15; [0024] all the parties have signed the contact.)
Turgman disclose a user selecting a contract template, adding data to the contact template, enjambed parties to sign the contract and deploy the contract to blockchain. (Turgman, [0037]; [0047]; [0050]; [0067]). However, Turgman does not explicitly disclose a contract template with the template keyed to a selected jurisdiction.
Ponceleon, on the other hand teaches disclose a contract template with the template keyed to a selected jurisdiction. (See at least Ponceleon, Abs.; [0006-0008]; [0035]; select a smart contract from a smart contract repository based on the system policy data and the jurisdiction policy parameters.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Turgman’s invention and include Ponceleon’s teachings in order to have the specific contract the user needs depending on where they live or which specific type of contract the user is selecting.
The combination of Turgman and Ponceleon disclose a method where the user selects a template of a smart contract. Turgman, Abs. However, the combination does not specifically disclose the system hashing the contract to create a hash value and the system storing the hash value in a blockchain.
Kurani, on the other hand teaches that it was known in the art creating a hash value of a smart contract and storing hash values on blockchain. See at least Kurani, Col. 9 lines 57-67; Col. 11 lines 30-38.
Therefore, 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 above combination and include Kurani’s teachings in order to enhance the security of the system/process.
Regarding claim 2: The combination of Turgman, Ponceleon and Kurani disclose the method of claim 1. The combination further disclose:
a) enabling the first user and the second user to transmit a contract completed message to the system; (See at least Turgman, Fig. 3; [0080] event notification of a completed state of the smart contract)
transferring assets upon receipt of the contract complete message. (See at least Turgman, Fig. 2; Upon signing the contract, the consumer transfers a refund amount of).
Kurani further disclose:
b) enabling the first user to create a user wallet within the system; (See at least Kurani, Col. 8 lines 29-39; 40-58; )
c) enabling the second user to create a user wallet within the system; (See at least Kurani, Col. 8 lines 29-39; 40-58; )
d) the system transferring assets from one wallet to the other. (See at least Kurani, Col. 10 lines 55-67; Fig. 3; The request token transmission 302 can be responsive to an action by the request interface 230 to transmit the request token 232 to the wallet container 210.)
Therefore, 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 above combination and include Kurani’s teachings in order to enhance the security of the system/process and to provide accountability.
Claim 3 is/are rejected under 35 U.S.C. 103 as being unpatentable over Turgman, Ponceleon and Kurani as applied to claims 1 and 2 above, and further in view of Mulaosmanovic (US 2018/0039934 A1).
Regarding claim 3: Turgman, Ponceleon and Kurani disclose the method of claim 2. The combination further disclose the steps of:
a) enabling the first user to retrieve a system template for asset registration; (See at least Kurani, Fig. 7; Col. 2 lines 4-44.)
b) enabling the first user to enter data into the system template for asset registration; (See at least Kurani, Fig. 7; Col. 2 lines 4-44.)
Therefore, 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 above combination and include Kurani’s teachings in order to enhance the security of the system/process.
The combination of Turgman, Ponceleon and Kurani disclose the method of claim 2. However, the combination does not explicitly disclose c) the system confirming or declining the data of the first user entered into the system template for asset registration; d) in the case of the confirmation of the data of the first user entered into the system template for asset registration, the confirmed asset status is recorded in the system registry.
Mulaosmanovic, on the other hand teaches c) the system confirming or declining the data of the first user entered into the system template for asset registration; (See at least MULAOSMANOVIC, [0014]; [0056]; [0069-0071]) d) in the case of the confirmation of the data of the first user entered into the system template for asset registration, the confirmed asset status is recorded in the system registry. (See at least MULAOSMANOVIC, [0014]; [0056]; [0069-0071])
Therefore, 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 above combination and include Mulaosmanovic’s teachings in order to provide a trustworthy and reliable system where assets registered are confirmed before they are added to the registry.
Applicant is reminded that the action of the confirmed asset status is recorded in the system registry does not have to happen in the claims because the action only occurs if a condition happens. Therefore, this phrase does not have patentable weight.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Wylie (US 20210201318 A1) Disclosed is an example of a method that includes a step of accessing, by a contract-creating computing device, a smart contract library. The smart contract library may include a number of templates of different legal contracts implementable as a smart contract between respective parties in the smart contract. Each template of the number of templates includes a number of sections having different contractual terms and conditions and fillable fields for specific contract terms. Each respective section of the number of sections includes programming code operable to enforce conformance with specific section-related contractual terms and conditions of the respective section and with any specific contract terms input to a fillable field of the respective section. A selection of a template of a smart contract may be received from the plurality of templates for implementation as a finalized smart contract. A private cryptographic key assigned to a first user of the contract-creating computing device may be obtained. The private cryptographic key may be associated with a public cryptographic key. A first user address associated with the contract-creating computing device in a private blockchain may be generated. The first user address may be based on the private cryptographic key and may be associated with the first user in the private blockchain. A smart contract address may be generated for the finalized smart contract using the first user address and a nonce value. A smart contract hash value may be generated using a value related to the programming code of the smart contract as an input into a hash function. The smart contract hash value may be stored as a transaction in the private blockchain. The transaction may be associated with the smart contract hash value and the first user address in the private blockchain. Wylie, [0004].
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KARLYANNIE M GARCIA whose telephone number is (571)272-6950. The examiner can normally be reached Monday - Friday 7:30am - 4:30-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, Patrick McAtee can be reached at (571) 272-7575. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/K.G.M/Examiner, Art Unit 3698
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698