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 .
Status of the Claims
Claims 1-20 are presented for examination. Examiner has established objections to claims 1-20 and § 101 rejection for claims 1-20in the instant Office action.
Claim Objections
Claims 1-20 are objected to because of the following numerous informalities (NOTE: Examiner is marking the suggested changes with bolding and usual markings for amendments):
Claim 1: A method for leveraging artificial intelligence (AI) to employ historical data to generate and enforce a tripartite smart contract, the tripartite smart contract configured to regulate execution of a transaction, the method comprising:
operating a contract executor on a processor, the processor including an AI engine, the contract executor configured to :
receive a command from an applicant to generate a tripartite smart contract between the applicant and a beneficiary;
in response to receiving the command, generate :
an applicant profile using data associated with the applicant;
a beneficiary profile using data associated with the beneficiary; and
a first set of input fields that request a first set of information from the applicant;
receive first inputs from the applicant in the first set of input fields;
assess the first inputs, the applicant profile and the beneficiary profile to determine whether to request additional information from the applicant;
in response to a determination to request additional information, generate a second set of input fields that request a second set of information from the applicant;
receive second inputs from the applicant in the second set of input fields;
identify , in a first repository storing successfully executed tripartite smart contracts, one or more successfully executed tripartite smart contracts that include data determined to correspond to the first inputs and the second inputs within a predetermined threshold level of accuracy;
generate a tripartite smart contract template using terminology associated with the identified successfully executed tripartite smart contracts, the tripartite smart contract template including placeholders for loading the first inputs and the second inputs;
store the tripartite smart contract template in a second repository associated with a third-party entity;
generate an executable tripartite smart contract by loading the placeholders with the first inputs and the second inputs;
transmit the executable tripartite smart contract to the beneficiary for review;
receive a reviewed executable tripartite smart contract from the beneficiary including suggested changes;
verify that the suggested changes are in accordance with the identified successfully executed tripartite smart contracts;
in response to verifying the suggested changes, update the executable tripartite smart contract and the tripartite smart contract template stored in the second repository with the verified suggested changes;
transmit the updated executable tripartite smart contract to the applicant, the beneficiary and the [[a]] third-party entity associated with the contract executor for signing;
in response to receiving a signature from the applicant, a signature from the beneficiary and a signature from the third-party entity, generate an issued tripartite smart contract; and
store the issued tripartite smart contract in the second repository.
Claim 2: The method of claim 1, further comprising:
using the beneficiary profile, identifying:
a jurisdiction in which the beneficiary operates;
an industry related to the beneficiary; and
a financial status of the beneficiary; and
determining first input fields corresponding to the identified jurisdiction, industry and financial status.
Claim 3: The method of claim 1, further comprising:
using the applicant profile, identifying:
a jurisdiction in which the applicant operates;
an industry related to the applicant; and
a financial status of the applicant; and
determining first input fields corresponding to the identified jurisdiction, industry and financial status.
Claim 4: The method of claim 1, further comprising:
deleting the executable tripartite smart contract in response to failing to receive the [[a]] signature from each of the applicant, the beneficiary and the third-party entity within a given timeframe.
Claim 5: The method of claim 1, further comprising:
transmitting a failure-to-issue notification to the applicant in response to failing to receive the [[a]] signature from each of the applicant, the beneficiary and the third-party entity within a given timeframe, the failure-to-issue notification requesting the applicant to review and amend the executable tripartite smart contact.
Claim 6: The method of claim 5, further comprising:
transmitting the failure-to-issue notification to the beneficiary in parallel to transmitting the failure-to-issue notification to the applicant.
Claim 7: The method of claim 1, further comprising:
transmitting the executable tripartite smart contract to the applicant for review in parallel to transmitting the executable tripartite smart contract to the beneficiary for review; and
merging the suggested changes received from the beneficiary and suggested changes received from the applicant.
Claim 8: The method of claim 1, wherein in response to a notification that the beneficiary and the applicant have completed the transaction, storing the issued tripartite smart contract in the first repository as a successfully executed tripartite smart contract.
Claim 9: The method of claim 8, wherein in response to storing the issued tripartite smart contract in the first repository, deleting the issued tripartite smart contract from the second repository.
Claim 10: The method of claim 1, wherein in response to receiving a suggested change that is in accordance with the identified successfully executed tripartite smart contracts, updating any pending tripartite smart contract being regulated by the third-party entity that includes data relating to the suggested change.
Claim 11: Apparatus for leveraging artificial intelligence (AI) to employ historical data to generate and enforce a tripartite smart contract, the tripartite smart contract configured to regulate execution of a transaction, the apparatus comprising:
a first repository configured to store successfully executed tripartite smart contracts;
a contract executor operating on a processor, the processor including an AI engine, wherein the contract executor is associated with a third-party entity, wherein the contract executor is configured to manage the tripartite smart contract, and wherein the contract executor is configured to:
receive a command from an applicant to generate the tripartite smart contract between the applicant and a beneficiary;
in response to receiving the command, generate:
an applicant profile using data associated with the applicant;
a beneficiary profile using data associated with the beneficiary; and
a first set of input fields that request a first set of information from the applicant;
receive first inputs from the applicant in the first set of input fields;
assess the first inputs, the applicant profile and the beneficiary profile to determine whether to request additional information from the applicant;
in response to a determination to request additional information, generate a second set of input fields that request a second set of information from the applicant;
receive second inputs from the applicant in the second set of input fields;
identify, in the first repository, one or more successfully executed tripartite smart contracts that include data determined to correspond to the first inputs and the second inputs within a predetermined threshold level of accuracy; and
generate a tripartite smart contract template using terminology associated with the identified successfully executed tripartite smart contracts, the tripartite smart contract template including placeholders for loading the first inputs and the second inputs; and
a second repository configured to store the tripartite smart contract template, wherein the second repository is configured to be in electronic communication with the contract executor,[[;]] and wherein the contract executor is further configured to:
generate an executable tripartite smart contract by loading the placeholders with the first inputs and the second inputs;
transmit the executable tripartite smart contract to the beneficiary for review;
receive a reviewed executable tripartite smart contract from the beneficiary including suggested changes;
verify that the suggested changes are in accordance with the identified successfully executed tripartite smart contracts;
in response to verifying the suggested changes, update the executable tripartite smart contract and the smart contract template stored in the second repository with the verified suggested changes;
transmit the updated executable tripartite smart contract to the applicant, the beneficiary and the third-party entity for signing;
in response to receipt of a signature from the applicant, a signature from the beneficiary and a signature from the third-party entity associated with the contract executor, generate an issued tripartite smart contract; and
store the issued tripartite smart contract in the second repository.
Claim 12: The apparatus of claim 11, wherein the contract executor is further configured to:
use the beneficiary profile to identify:
a jurisdiction in which the beneficiary operates; and
a financial status of the beneficiary; and
determine first input fields corresponding to the identified jurisdiction and financial status.
Claim 13: The apparatus of claim 11, wherein the contract executor is further configured to:
use the applicant profile to identify:
a jurisdiction in which the applicant operates; and
a financial status of the applicant; and
determine first input fields corresponding to the identified jurisdiction and financial status.
Claim 14: The apparatus of claim 11, wherein the contract executor is further configured to:
delete the executable tripartite smart contract in response to failing to receive the [[a]] signature from each of the applicant, the beneficiary and the third-party entity within a given timeframe.
Claim 15: The apparatus of claim 11, wherein the contract executor is further configured to:
transmit a failure-to-issue notification to the applicant in response to failing to receive the [[a]] signature from each of the applicant, the beneficiary and the third-party entity within a given timeframe, the failure-to-issue notification configured to request the applicant to review and amend the executable tripartite smart contact.
Claim 16: The apparatus of claim 15, wherein the contract executor is further configured to:
transmit the failure-to-issue notification to the beneficiary in parallel with transmission of the failure-to-issue notification to the applicant.
Claim 17: The apparatus of claim 11, wherein the contract executor is further configured to:
transmit the executable tripartite smart contract to the applicant for review in parallel to transmission of the executable tripartite smart contract to the beneficiary for review; and
merge the suggested changes received from the beneficiary and suggested changes received from the applicant.
Claim 18: The apparatus of claim 11, wherein in response to receipt of a notification that the beneficiary and the applicant have completed the transaction, the contract executor is further configured to:
store the issued tripartite smart contract in the first repository as a successfully executed tripartite smart contract.
Claim 19: The apparatus of claim 18, wherein in response to storage of the issued tripartite smart contract in the first repository, the contract executor is further configured to:
delete the issued tripartite smart contract from the second repository.
Claim 20: The apparatus of claim 11, wherein in response to receipt of a suggested change that is in accordance with the identified successfully executed tripartite smart contracts, the contract executor is further configured to:
update any pending tripartite smart contract being regulated by the third-party entity that includes data related to the suggested change.
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 USC § 101 because they are directed to non-statutory subject matter. The rationale for this finding is explained below.
The Supreme Court in Mayo laid out a framework for determining whether an applicant is seeking to patent a judicial exception itself or a patent-eligible application of the judicial exception. See Alice Corp., 134 S. Ct. at 2355,110 USPQ2d at 1981 (citing Mayo, 566 U.S. 66, 101 USPQ2d 1961). This framework, which is referred to as the Mayo test or the Alice/Mayo test (“the test”), is described in detail in Manual of Patent Examining Procedure (”MPEP”) (see MPEP § 2106(III) for further guidance). The step 1 of the test: It need to be determined whether the claims are directed to a patent eligible (i.e., statutory) subject matter under 35 USC § 101. Step 2A of the test: If the claims are found to be directed to a statutory subject matter, the next step is to determine whether the claims are directed to a judicial exception i.e., law of nature, natural phenomenon, and abstract idea (Prong 1). If the claims are found to be directed to an abstract idea, it needs to be determined whether the claims recite additional elements that integrate the judicial exception into a practical application (Prong 2). Step 2B of the test: If the claims are directed to a judicial exception, the next and final step is to determine whether the claims recite additional elements that amount to significantly more than the judicial exception.
Step 1 of the Test:
When considering subject matter eligibility under 35 USC § 101, it must be determined whether the claim is directed to one of the four statutory categories of invention, i.e., process, machine, manufacture, or composition of matter. Here, the claimed invention of claims 1-10 is a series of steps, which is method (i.e., a process) and, thus, one of the statutory categories of invention. Further, the claimed invention of claims 11-20 is a system, which is also one of the statutory categories of invention.
Conclusion of Step 1 Analysis: Therefore, claims 1-20 are statutory under 35 USC § 101 in view of step 1 of the test.
Step 2A of the Test:
Prong 1: Claims 1-20, however, recite an abstract idea of regulating an execution of a transaction. The creation of regulating an execution of a transaction, as recited in the independent claims 1 and 11 belongs to certain methods of organizing human activity (i.e., commercial or legal interactions) that are found by the courts to be abstract ideas. The limitations in independent claims 1 and 11, which set forth or describe the recited abstract idea, are found in the following steps:
“generating, in response to receiving the command: an applicant profile using data associated with the applicant; a beneficiary profile using data associated with the beneficiary; and a first set of input fields that request a first set of information from the applicant” (claims 1 and 11);
“assessing the first inputs, the applicant profile and the beneficiary profile to determine whether to request additional information from the applicant” (claims 1 and 11);
“generating, in response to a determination to request additional information, a second set of input fields that request a second set of information from the applicant” (claims 1 and 11);
“identifying one or more successfully executed tripartite smart contracts that include data determined to correspond to the first inputs and second inputs within a predetermined threshold level of accuracy” (claims 1 and 11);
“generating a tripartite smart contract template using terminology associated with the identified successfully executed tripartite smart contracts, the tripartite smart contract template including placeholders for loading the first inputs and the second inputs” (claims 1 and 11);
“generating an executable tripartite smart contract by loading the placeholders with the first inputs and the second inputs” (claims 1 and 11);
“verifying that the suggested changes are in accordance with the identified successfully executed tripartite smart contracts” (claims 1 and 11);
“updating, in response to verifying the suggested changes, the executable tripartite smart contract and the tripartite smart contract template stored with the verified changes” (claims 1 and 11); and
“generating, in response to receiving a signature from the applicant, the beneficiary and the third-party entity, an issued tripartite smart contract” (claims 1 and 11).
Prong 2: In addition to abstract steps recited above in Prong 1, independent claims 1 and 11 recite additional elements:
“a contract executor associated with a third-party entity operating on a processor” (claims 1 and 11);
“the processor including an AI engine” (claims 1 and 11);
“a first repository” (claims 1 and 11);
“a second repository associated with the third-party entity” (claim 1); and
“a second repository in electronic communication with the contract executor” (claim 11).
These additional elements are recited at a high level of generality (e.g., as a generic processor performing a generic computer functions) such that they amount to no more than mere instructions to apply the exception using a generic computer components. Further, the following limitations recite insignificant extra solution activity (e.g., data gathering):
“receiving a command from an applicant to generate a tripartite smart contract between the applicant and a beneficiary” (claims 1 and 11);
“receiving first inputs from the applicant in the first set of input fields” (claim 1);
“receiving second inputs from the applicant in the second set of fields” (claim 1);
“storing successfully executed tripartite smart contracts” (claims 1 and 11);
“storing the tripartite smart contract template” (claims 1 and 11);
“transmitting the executable tripartite smart contract to the beneficiary for review” (claims 1 and 11);
“receiving a reviewed executable tripartite smart contract from the beneficiary including suggested changes” (claims 1 and 11);
“transmitting the updated executable tripartite smart contract to the applicant, the beneficiary and a third-party entity associated with the contract executor for signing” (claims 1 and 11); and
“storing the issued tripartite smart contract” (claims 1 and 11).
These additional limitations do not integrate the abstract idea into a practical application because they do not impose a meaningful limit on the judicial exception. The additional elements/limitations of independent claims 1 and 11 here do not render improvements to the functioning of a computer or to any other technology or technical field (see MPEP § 2106.05(a)), nor do they integrate the abstract idea into a practical application under MPEP § 2106.05(b) (particular machine); MPEP § 2106.05(c) (particular transformations); or MPEP § 2106.05(e) (other meaningful limitations).
Conclusion of Step 2A Analysis: The limitations in independent claims 1 and 11, which set forth or describe the recited abstract idea are not patent eligible either alone or in combination. The additional elements/limitations in independent claims 1 and 11 are not patent eligible either alone or in combination. Further, the combination of these additional elements/limitations and the limitations which set forth or describe the recited abstract idea is no more than mere instructions to apply the exception using a generic device. Accordingly, even in combination, these additional elements/limitations and the limitations which set forth or describe the recited abstract idea do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. Therefore, independent claims 1 and 11 are non-statutory under 35 USC § 101 in view of step 2A of the test.
Step 2B of the Test: The additional elements of independent claims 1 and 11 (see above under Step 2A – Prong 2) are described by Applicant’s Specification in following terms:
[0048] The first repository may be used for long-term data storage. The second repository may be used for short-term data storage. The first repository may be a structured repository . . . The first repository may be linked to the second repository.
[0060] The apparatus may include a processor. The processor may execute a contract executor. The contract executor may be associated with the third-party entity. The processor may include an artificial intelligence (“AI”) engine. The processor may be included in a computing device. The computing device may be a desktop computer, a server, a laptop, a tablet, a mainframe computer, a smartphone and/or any other suitable computing device.
[0110] Computer 501 may include processor 503 for controlling the operation of the device and its associated components, and may include RAM 505, ROM 507, input/output (“I/O”) 509, and a non-transitory or non-volatile memory 515. Machine-readable memory may be configured to store information in machine-readable data structures. Processor 503 may also execute software running on the computer. Other components commonly used for computers, such as EEPROM or flash memory or any other suitable components, may also be part of computer 501.
[0111] Memory 515 may include any suitable permanent storage technology, such as a hard drive. Memory 515 may store software including the operating system 517 and application program(s) 519 together with any data 511 needed for the operation of the system 500. Memory 515 may also store videos, text and/or audio assistance files. The data stored in memory 515 may also be stored in cache memory and/or any other suitable memory.
[0119] The invention may be operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well-known computing systems, environments, and/or configurations that may be suitable for use with the invention include, but are not limited to, personal computers, server computers, hand-held or laptop devices, tablets, mobile phones, smart phones and/or other personal digital assistants (“PDAs”), multiprocessor systems, microprocessor-based systems, cloud-based systems, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.
This is a description of general-purpose computer. Thus, individually, the additional elements of independent claims 1 and 11 are well-understood, routine, and conventional elements that amount to no more than implementing the abstract idea with a computerized system. Further, the additional limitations of “transmitting,” “receiving,” and “storing” information amount to no more than mere instructions to apply the exception using generic computer components. For the same reason these additional limitations are not sufficient to provide an inventive concept. The additional limitations of “transmitting,” “receiving,” and “storing” information were considered as insignificant extra-solution activity in Step 2A - Prong 2. Re-evaluating here in Step 2B, they are also determined to be well-understood, routine, and conventional activity in the field. Similarly to OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network), and buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network), the additional limitations of independent claims 1 and 11 “receive” or “transmit” information in a merely generic manner. Further, similarly to Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015) and OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93, the additional limitations of independent claims 1 and 11 “store” information in memory. The courts have recognized “transmitting,” “receiving,” and “storing” information functions as well-understood, routine and conventional when claimed in a merely generic manner. Therefore, the additional limitations of independent claims 1 and 11 are well-understood, routine, and conventional. Further, taken as combination, the additional elements/limitations add nothing more than what is present when the additional elements/limitations are considered individually. There is no indication that the combination provides any effect regarding the functioning of the computer or any improvement to another technology.
Conclusion of Step 2B Analysis: Therefore, independent claims 1 and 11 are non-statutory under 35 USC § 101 in view of step 2B of the test.
Dependent Claims: Dependent claims 2-10 depend on independent claim 1; and dependent claims 12-20 depend on independent claim 11. The elements in dependent claims 2-10 and 12-20, which set forth or describe the abstract idea, are:
“using the beneficiary profile, identifying: a jurisdiction in which the beneficiary operates; an industry related to the beneficiary; and a financial status of the beneficiary; and determining first input fields corresponding to the identified jurisdiction, industry and financial status” (claims 2 and 12: further narrowing the recited abstract idea);
“using the applicant profile, identifying: a jurisdiction in which the applicant operates; an industry related to the applicant; and a financial status of the applicant; and determining first input fields corresponding to the identified jurisdiction, industry and financial status” (claims 3 and 13: further narrowing the recited abstract idea);
“deleting the executable tripartite smart contract in response to failing to receive a signature from each of the applicant, the beneficiary and the third-party entity within a given timeframe” (claims 4 and 14: further narrowing the recited abstract idea);
“transmitting a failure-to-issue notification to the applicant in response to failing to receive a signature from each of the applicant, the beneficiary and the third-party entity within a given timeframe, the failure-to-issue notification requesting the applicant to review and amend the executable tripartite smart contact” (claims 5 and 15: insignificant extra solution activity);
“transmitting the failure-to-issue notification to the beneficiary in parallel to transmitting the failure-to-issue notification to the applicant” (claims 6 and 16: insignificant extra solution activity);
“transmitting the executable tripartite smart contract to the applicant for review in parallel to transmitting the executable tripartite smart contract to beneficiary for review; and merging suggested changes received from the beneficiary and suggested changes received from the applicant” (claims 7 and 17: where “transmitting” step is insignificant extra solution activity; and where “merging” step is further narrowing the recited abstract idea);
“in response to a notification that the beneficiary and the applicant have completed the transaction, storing the issued tripartite smart contract in the first repository as a successfully executed tripartite smart contract” (claims 8 and 18: insignificant extra solution activity);
“in response to storing the issued tripartite smart contract in the first repository, deleting the issued tripartite smart contract from the second repository” (claims 9 and 19: further narrowing the recited abstract idea); and
“in response to receiving a suggested change that is in accordance with the identified successfully executed tripartite smart contracts, updating any pending tripartite smart contract being regulated by the third-party entity that includes data relating to the suggested change” (claims 10 and 20: further narrowing the recited abstract idea).
Conclusion of Dependent Claims Analysis: Dependent claims 2-10 and 12-20 do not correct the deficiencies of independent claims 1 and 11 and they are, thus, rejected on the same basis.
Conclusion of the 35 USC § 101 Analysis: Therefore, claims 1-20 are rejected as directed to an abstract idea without “significantly more” under 35 USC § 101.
Examiner’s Remarks Regarding Prior Art
The closest prior art reference located by Examiner is Feng (US 2020/0193428 A1) disclosing the following claim limitations found in instant independent claims 1 and 11 in [0058]-[0063]:
a first repository configured to store successfully executed tripartite smart contracts;
a contract executor operating on a processor, the processor including an artificial intelligence (AI) engine, the contract executor being associated with a third-party entity, the contract executor configured to manage the tripartite smart contract, the contract executor configured to:
receive a command from an applicant to generate the tripartite smart contract between the applicant and a beneficiary;
in response to receiving the command, generate:
an applicant profile using data associated with the applicant;
a beneficiary profile using data associated with the beneficiary; and a first set of input fields that request a first set of information from the applicant;
a second repository configured to store the tripartite smart contract template, the second repository configured to be in electronic communication with the contract executor;
transmit the executable tripartite smart contract to the beneficiary for review;
receive a reviewed executable tripartite smart contract from the beneficiary including suggested changes;
verify that the suggested changes are in accordance with the identified successfully executed tripartite smart contracts;
in response to a verification of the suggested changes, update the executable tripartite smart contract and the smart contract template stored in the second repository with the verified changes;
transmit the updated executable tripartite smart contract to the applicant, the beneficiary and the third-party entity for signing;
in response to receipt of a signature from the applicant, a signature from the beneficiary and a signature from the third-party entity associated with the contract executor, generate an issued tripartite smart contract; and
store the issued tripartite smart contract in the second repository.
Feng alone, or in combination with other prior art references, does not teach the following claim limitations found in independent claims 1 and 11 as an ordered combination of steps:
receive first inputs from the applicant in the first set of input fields;
assess the first inputs, the applicant profile and the beneficiary profile to determine whether to request additional information from the applicant;
in response to a determination to request additional information, generate a second set of input fields that request a second set of information from the applicant;
receive second inputs from the applicant in the second set of fields;
identify, in the first repository, one or more successfully executed tripartite smart contracts that include data determined to correspond to the first inputs and the second inputs within a predetermined threshold level of accuracy;
generate a tripartite smart contract template using terminology associated with the identified successfully executed tripartite smart contracts, the tripartite smart contract template including placeholders for loading the first inputs and the second inputs; and
generate an executable tripartite smart contract by loading the placeholders with the first inputs and the second inputs.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Viswanath (US 2023/0419313 A1) discloses: “Methods, apparatuses, or computer program products provide for managing a digital asset repository associated with a distributed ledger system based on an event stream related to an application framework. A candidate transaction associated with one or more application components of an application framework is detected based at least on monitoring an event stream. A candidate transaction data structure for the candidate transaction is also generated in accordance with one or more candidate transaction attributes of the candidate transaction. Based on a comparison between the one or more candidate transaction attributes and smart contract rules for the smart contract, execution of a smart contract of a distributed ledger is caused to add the candidate transaction data structure to the distributed ledger in accordance with a distributed ledger consensus protocol. Adding the candidate transaction data structure to the distributed ledger results in an increase of a total micro-digital asset count.”
Padmanabham (US 2023/0368291 A1) discloses: “A designated smart contract representation may be determined based on configuration information provided by a first database system account. The designated smart contract representation may include a binary executable representation of a smart contract template. Access to the designated smart contract representation may be provided via an application exchange in an database system. The database system may provide computing services to a plurality of entities via the internet. The plurality of entities may include a first entity associated with the first database system account and a second entity associated with a second database system account. The application exchange may provide access to a plurality of smart contract representations including the designated smart contract representation. A selection of the designated smart contract representation may be received in association with the second database system account. The binary executable representation may be deployed to a blockchain.”
Turgman (US 2020/0380624 A1) discloses: “Embodiments described herein are configured to generate a smart contract deployed to a distributed ledger platform. In particular, a first party and a second party select a smart contract template and a user interface user interface is thereafter presented to the parties for inclusion of negotiable contract elements. Upon agreement, a smart contract is thereafter generated by augmenting smart contract template programming code to include the included contract elements, and the code is compiled and deployed to a smart contract platform such as, for example, a blockchain. Embodiments include meta-instructions in the smart contract programming code that at least in part determines how the specified contract elements are included in the smart contract programming code. In embodiments, the meta-instructions are embedded in comments in the smart contract programming code.”
Zhang, Qing, et al. "FutureText: A blockchain-based contract signing prototype with security and convenience." Proceedings of the 3rd ACM International Symposium on Blockchain and Secure Critical Infrastructure. 2021, disclosing: “[T]o follow the legitimacy and compliance, we put forward methods for both authentication and signature of tripartite contracts.”
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VIRPI H. KANERVO whose telephone number is 571-272-9818. The examiner can normally be reached on Monday - Friday, 10 am - 6 pm, EST. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor Abhishek Vyas can be reached on 571-270-1836. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the 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). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/VIRPI H KANERVO/Primary Examiner, Art Unit 3691
Prosecution Insights