DETAILED ACTION
Status of the Claims
The following is a non-final Office Action in response to amendments and remarks filed 25 June 2026.
Claims 1, 5, 7-8, 12, 14, and 18 have been amended.
Claim 20 has been cancelled.
Claim 21 has been added.
Claims 1-19 and 21 are pending have been examined.
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 15 June 2026 and 19 June 2026 are being considered by the Examiner.
Response to Arguments
Applicant's arguments filed 18 March 2017 have been fully considered but they are not persuasive.
Applicants argue that the 35 U.S.C. 101 rejection under the Alice Corp. vs. CLS Bank Int’l be withdrawn; however the Examiner respectfully disagrees. The Examiner notes that in order to be patent eligible under 35 U.S.C. 101, the claims must be directed towards a patent eligible concept, which, the instant claims are not directed. Contrary to Applicants’ assertion that the claims are not a certain method of organizing human activity, the Examiner notes that managing and executing contracts is a function that lawyers, accountants, clearing houses, escrows etc. have traditionally performed/provided for users. Next, the claims are not directed to a practical application of the concept. The claims do not result in improvements to the functioning of a computer or to any other technology or technical field. They do not effect a particular treatment for a disease. They are not applied with or by a particular machine. They do not effect a transformation or reduction of a particular article to a different state or thing. And they are not applied in some other meaningful way beyond generally linking the use of the judicial exception (i.e., managing and executing contracts) to a particular technological environment (i.e., electronically with the use of smart contracts and generic computing components). Here, again as noted in the previous rejection, mere instructions to apply an exception using a generic computer component cannot provide an inventive concept - MPEP 2016.05(f). The claims recitation of the “...smart contract deployed to a blockchain maintained by a computing platform... and “database” only generally linking the use of the judicial exception to a particular technological environment or field of use – see MPEP 2106.05(h). The claim(s) is/are not patent eligible. As such, this argument is not persuasive and the rejection not overcome.
Applicant’s arguments appear to be whether or not the use of computer or computing components for increased speed and efficiency is an inventive concept; however the Examiner respectfully disagrees. Nor, in addressing the second step of Alice, does claiming the improved speed or efficiency inherent with applying the abstract idea on a computer provide a sufficient inventive concept. See Bancorp Servs., LLC v. Sun Life Assurance Co. of Can., 687 F.3d 1266, 1278 (Fed. Cir. 2012) (“[T]he fact that the required calculations could be performed more efficiently via a computer does not materially alter the patent eligibility of the claimed subject matter.”); CLS Bank, Int’l v. Alice Corp., 717 F.3d 1269, 1286 (Fed. Cir. 2013) (en banc) aff’d, 134 S. Ct. 2347 (2014) (“[S]imply appending generic computer functionality to lend speed or efficiency to the performance of an otherwise abstract concept does not meaningfully limit claim scope for purposes of patent eligibility.” (citations omitted)). As such, this argument is not persuasive and the rejection not overcome.
Applicant’s remarks with respect to the prior art have been fully considered but are moot on grounds of new rejection, as necessitated by amendments.
In response to arguments in reference to any depending claims that have not been individually addressed, all rejections made towards these dependent claims are maintained due to a lack of reply by the Applicants in regards to distinctly and specifically pointing out the supposed errors in the Examiner's prior office action (37 CFR 1.111). The Examiner asserts that the Applicants only argue that the dependent claims should be allowable because the independent claims are unobvious and patentable over the prior art.
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-19 and 21 is/are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claims are directed to a process (an act, or series of acts or steps), a machine (a concrete thing, consisting of parts, or of certain devices and combination of devices), and a manufacture (an article produced from raw or prepared materials by giving these materials new forms, qualities, properties, or combinations, whether by hand labor or by machinery). Thus, each of the claims falls within one of the four statutory categories (Step 1). The claims recite a system, method (process) and apparatus, however, the claim(s) recite(s) queries regarding the states of contracts which is an abstract idea of organizing human activities.
The limitations of “receive an event notification..., the event notification specifying a state of the smart contract; transmit a first query to a server for information associated with the smart contract; receive the information associated with the smart contract...the information comprising a smart contract method corresponding to a function of the smart contract and an inline comment of programming code of the smart contract; transmit a second query to the function, the second query identifying a first user and specifying the state of the smart contract, said transmitting the second query causing the function to determine a user interface element to be presented in a user... associated with the first user; receive an indication of the user interface element from the function,” as drafted, is a process that, under its broadest reasonable interpretation, covers organizing human activities--fundamental economic principles or practices (including hedging, insurance, mitigating risk); commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations); managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions) but for the recitation of generic computer components (Step 2A Prong 1). That is, other than reciting “A system comprising: a processor; and a memory device storing computer program logic structured to cause the processor to:,” (or “A method performed by a computing device comprising:” in claim 8 or “A computing device comprising: a processor; a memory device comprising programming instructions executable by the processor, the programming instructions comprising:” in claim 14) nothing in the claim element precludes the step from the methods of organizing human interactions grouping. For example, but for the “cause the processor to” “performed by a computing device,” “the programming instructions comprising...” language, “receive,” “transmit,” “receive,” “transmit,” “receive,” and “cause” in the context of this claim encompasses the user manually managing contracts and statuses thereof which are a business relation/fundamental economic practice/commercial or legal interaction i.e. contract management. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation as a certain method of organizing human activities, but for the recitation of generic computer components, then it falls within the “Certain Methods of Organizing Human Activities” grouping of abstract ideas. Accordingly, the claim(s) recite(s) an abstract idea (Step 2A, Prong One: YES).
This judicial exception is not integrated into a practical application (Step 2A Prong Two). The “memory device” “server,” are only used for extrasolution data gathering (storage) and the “generate a representation of the user interface element present the representation of the user interface element in the user interface” and “user interface generator” are simply elements for insignificant post solution output of the abstract idea. Next, In particular, the claim only recites one additional element – using a processor or computing device to perform the steps. The processor or computing device in the steps is recited at a high-level of generality (i.e., as a generic processor performing a generic computer function of electronic data query, storage and retrieval) such that it amounts no more than mere instructions to apply the exception using a generic computer component. Specifically the claims amount to nothing more than an instruction to apply the abstract idea using a generic computer or invoking computers as tools by adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.04(d)(I) discussing MPEP 2106.05(f). The claims recitation of the “...smart contract deployed to a blockchain maintained by a computing platform...” is only generally linking the use of the judicial exception to a particular technological environment or field of use – see MPEP 2106.04(d)(I) discussing MPEP 2106.05(h). Accordingly, the combination of these additional elements does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea, even when considered as a whole (Step 2A Prong Two: NO).
The claim does not include a combination of additional elements that are sufficient to amount to significantly more than the judicial exception (Step 2B). As discussed above with respect to integration of the abstract idea into a practical application (Step 2A Prong 2), the combination of additional elements of using a processor or computing device to perform the steps 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. * Reevaluating here in step 2B, the “memory device” “server,” are only used for extrasolution data gathering (storage) and the “generate a representation of the user interface element present the representation of the user interface element in the user interface” and “user interface generator” in the step(s) which are insignificant extrasolution activities are also determined to be well-understood, routine and conventional activity in the field. The Symantec, TLI, and OIP Techs court decisions in MPEP 2106.05(d)(II) indicate that the mere receipt or transmission of data over a network is well-understood, routine, and conventional function when it is claimed in a merely generic manner (as is here). Therefore, when considering the additional elements alone, and in combination, there is no inventive concept in the claim. As such, the claim(s) is/are not patent eligible, even when considered as a whole (Step 2B: NO).
Claims 2-4, 6, 9-11, 13, 15-17, and 19 recite(s) the additional limitation(s) further including when to send notifications, which is still directed towards the abstract idea previously identified and is not an inventive concept that meaningfully limits the abstract idea. Again, as discussed with respect to claims 1, 8, and 14, the claims are simply limitations which are no more than mere instructions to apply the exception using a computer or with computing components. Accordingly, the additional element(s) does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. Even when considered as a whole, the claims do not integrate the judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B.
Claims 5, 12, and 18 recite(s) the additional limitation(s) further limiting the technical environment for the programming code to include inline items (i.e. notes or annotations within the contract) which is not an inventive concept that meaningfully limits the abstract idea. Again, as discussed with respect to claims 1, 8, and 14, the claims are simply limitations which are no more than mere instructions to apply the exception using a computer or with computing components. Accordingly, the additional element(s) does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. Even when considered as a whole, the claims do not integrate the judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B.
Claims 7 and 20-21 recite(s) the additional limitation(s) further limiting the technical environment which includes a display device that only provides the post solution output which is not an inventive concept that meaningfully limits the abstract idea. Again, as discussed with respect to claims 1, 8, and 14, the claims are simply limitations which are no more than mere instructions to apply the exception using a computer or with computing components. Accordingly, the additional element(s) does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. Even when considered as a whole, the claims do not integrate the judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B.
Claims 1-19 and 21 are therefore not eligible subject matter, even when considered as a whole.
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, 5, 7-9, 12, 14-15, 18, and 20-21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hunn et al. (US PG Pub. 2019/0122317, hereinafter Hunn’317) and further in view of Gray (US Patent No. 10,749,687).
As per claims 1, 8, and 14, Hunn’317 discloses a system comprising: a processor; and a memory device storing computer program logic structured to cause the processor to:; a method performed by a computing device comprising:; and a computing device comprising: a processor; a memory device comprising programming instructions executable by the processor, the programming instructions comprising: a user interface generator that (Fig. 1, system, Hunn’317 ¶8, ¶54; computer executable components, server, device, smartphone, hardware, software, readable media, ¶225):
receive an event notification from a smart contract deployed to a blockchain maintained by a computing platform, the event notification specifying a state of the smart contract (record of contract event, Hunn’317 ¶38-¶41; Events from external resources (e.g., freight being shipped, delivered, signed-for, etc.) are exposed to the contract. Events that pertain to the contract are preferably stored as content addressed objects that act as inputs. Such objects are exposed to the runtime as data inputs through an integration architecture such as a data layer (see FIG. 14). These events are routed to the logic to perform an appropriate action. In this example, the action is to calculate the penalty amount if delivery is late and signal whether the buyer may terminate the contract, ¶76; blockchain/distributed ledger, ¶29-¶30);
transmit a first query to a server for information associated with the smart contract (The requests represent events of significance to the clause from external resources (e.g. deliveries such as depicted in FIG. 17 delivered via resource interfaces as depicted in exemplary fashion in FIGS. 14 and 15) 106. The Execution Engine preferably invokes the logic of the programmable clause, passing in the parameterization data, a context object, and the incoming request. The Execution Engine validates the response and then returns it to the caller. The structure of the response may be modeled in the data model 107 as shown in exemplary fashion in FIG. 16. FIG. 12 provides a graphical representation of an input request and output response object of a preferred data-driven contract embodiment. Each execution cycle takes and state as input and returns a (possibly new) state as well as any external actions/side effects. FIG. 17 provides exemplary request, response, state, and side effect object data for a late delivery and penalty programmable clause, Hunn’317 ¶61);
receive the information associated with the smart contract from the server, the information comprising a smart contract method corresponding to a function of the smart contract (perform function calls, function in a clause of the smart contract, Hunn’317 ¶40-¶41; In this example, a request modeled in the data model (see FIG. 16) is sent to the Execution Engine after being triggered from an inbound adapter (see FIG. 14) such as IoT or API event. A response is computed, providing the penalty due as a result of the ‘delivery’ input, and a new state object is generated based upon the computation. A ‘payment obligation’ side effect object is also generated. The payment obligation object provides that based upon the computation of the clause, a payment is owed from one contracting party to another contracting party, taking account of the computed penalty. The objects are added to the object graph as outlined herein (see e.g. FIGS. 4 and 8). The payment obligation data may then be used to inform one or more of the contracting parties in an interface of a contract management system, to trigger an operation on a web service API (e.g. through an outbound adapter as depicted in FIG. 14), or other appropriate operation, ¶62);
transmit a second query to the function, the second query identifying a first user and specifying the state of the smart contract, said transmitting the second query causing the function to...(For example, a BDL transaction may be configured for execution as a result of a contracting party receiving the external action event (e.g. B1) and displayed to the user for authorization to complete (e.g. by signing the proposed BDL transaction with the user's private key as depicted in FIG. 18), Hunn ¶224);
receive an indication of the user interface element from the function (Subsequently, as part of the execution cycle, the parties may determine who is responsible to perform the external action (i.e. the BDL transaction). Preferably, a BDL transaction is executed using a mechanism similar to FIG. 18; where the system and method is implemented as part of, or in conjunction with, a contract management system (see FIG. 14 and FIG. 15). A user interface of the CMS may be configured to provide notifications to the user of the CMS to perform or approve such actions. In one variation, these external actions may be ‘queued up’ in a task manager, requiring a user of the CMS to authorize their execution. For example, a BDL transaction may be configured for execution as a result of a contracting party receiving the external action event (e.g. B1) and displayed to the user for authorization to complete (e.g. by signing the proposed BDL transaction with the user's private key as depicted in FIG. 18), Hunn’317 ¶224); and
generate a representation of the user interface element (The contract, when executed, functions to update the state of the contract and the object graph. The execution can additionally request external actions (“side effects”) as depicted in FIG. 12. External actions are preferably used to trigger actions on external systems (e.g., updating blockchain and distributed ledger systems, sending emails, updating accounting systems etc.) through resource integrations as depicted in FIG. 14 and FIG. 15. The external actions may utilize data emitted from execution of a clause, such as specific contract objects (such as obligations or responses as shown in FIG. 17), clause state, and similar, Hunn’317 ¶55; Subsequently, as part of the execution cycle, the parties may determine who is responsible to perform the external action (i.e. the BDL transaction). Preferably, a BDL transaction is executed using a mechanism similar to FIG. 18; where the system and method is implemented as part of, or in conjunction with, a contract management system (see FIG. 14 and FIG. 15). A user interface of the CMS may be configured to provide notifications to the user of the CMS to perform or approve such actions. In one variation, these external actions may be ‘queued up’ in a task manager, requiring a user of the CMS to authorize their execution. For example, a BDL transaction may be configured for execution as a result of a contracting party receiving the external action event (e.g. B1) and displayed to the user for authorization to complete (e.g. by signing the proposed BDL transaction with the user's private key as depicted in FIG. 18), ¶224; API event notifications, ¶32);
present the representation of the user interface element in the user interface (The contract, when executed, functions to update the state of the contract and the object graph. The execution can additionally request external actions (“side effects”) as depicted in FIG. 12. External actions are preferably used to trigger actions on external systems (e.g., updating blockchain and distributed ledger systems, sending emails, updating accounting systems etc.) through resource integrations as depicted in FIG. 14 and FIG. 15. The external actions may utilize data emitted from execution of a clause, such as specific contract objects (such as obligations or responses as shown in FIG. 17), clause state, and similar, Hunn’317 ¶55; Subsequently, as part of the execution cycle, the parties may determine who is responsible to perform the external action (i.e. the BDL transaction). Preferably, a BDL transaction is executed using a mechanism similar to FIG. 18; where the system and method is implemented as part of, or in conjunction with, a contract management system (see FIG. 14 and FIG. 15). A user interface of the CMS may be configured to provide notifications to the user of the CMS to perform or approve such actions. In one variation, these external actions may be ‘queued up’ in a task manager, requiring a user of the CMS to authorize their execution. For example, a BDL transaction may be configured for execution as a result of a contracting party receiving the external action event (e.g. B1) and displayed to the user for authorization to complete (e.g. by signing the proposed BDL transaction with the user's private key as depicted in FIG. 18), ¶224; API event notifications, ¶32).
Hunn’317 does not expressly disclose an inline comment of programming code of the smart contract; determine, based on the inline comment, a user interface element to be presented in a user interface associated with the first user .
However, Gray teaches an inline comment of programming code of the smart contract; determine, based on the inline comment, a user interface element to be presented in a user interface associated with the first user (Utility cryptlets may provide discrete functionality like providing external information, e.g., market prices, external data from other systems, or proprietary formulas. These may be called “blockchain oracles” in that they can watch and inject “real world” events and data into blockchain systems. Smart contracts may interact with these using a Publish/Subscribe pattern where the utility cryptlet publishes an event for subscribing smart contracts. The event triggers may be external to the blockchain (e.g., a price change) or internal to the blockchain (e.g., a data signal) within a smart contract or operation code. In some examples, these cryptlets can also be called directly by other cryptlets within the fabric and expose an external or surface level API that other systems can call. For example, an enterprise Customer relationship management (CRM) system may publish an event to a subscribing cryptlet that in turn publishes information to a blockchain in blockchain network 450 based on that information. Bi-directional integration may be provided to smart contracts and blockchains through Cryptlet Fabric 460 in this way, Gray Col. 10 lines 26-45) (Examiner notes the ability to have cyptlets that are code functions within the smart contract as the functional equivalent to inline comments of programming code which will have functionality as described in the specification).
Both the Hunn’317 and Gray references are analogous in that both are directed towards/concerned with smart contract creation and management. Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to use Gray’s ability to utilize cryptlets within smart contracts in Hunn’317’s system to improve the system and method with reasonable expectation that this would result in a smart contract management system that is able to create and execute smart contracts that have an internal functionality that can handle triggers and other events.
The motivation being that there may be a need to change a smart contract, such as changing the logic of the smart contract due to a bug, a change in one of the counterparties due to assignment of the contract, or some other reason. However, in some examples, if the smart contract itself is changed, it will no longer register as valid. In some examples, instead of changing the smart contract itself, the smart contract remains unchanged, while creating a new version of the contract. In some examples, creating a new version of the smart contract may require the agreement of all counterparties to the smart contract, unless, for example, the previously agreed-upon terms of the smart contract allow for a unilateral change or a change that only needs to be agreed to by a particular subset of the counterparties (Gray Col. 3 lines 29-42).
As per claims 2, 9, and 15, Hunn’317 and Gray disclose as shown above with respect to claims 1, 8, and 14. Hunn’317 further discloses wherein the computer program logic is further structured to cause the processor to query the smart contract for the state; and receive the event notification in response to said querying (Examples of automated stipulated conditions include: taking an action on a specific date, after a specific event occurs, or taking action at some interval(s). Examples of flexible conditions may include a simple majority vote where involved parties may change their minds anytime prior to achieving consensus S310. Another example implementing a majority vote could be where some involved parties have no voting privileges. Alternatively, some involved parties may have multiple votes. In one preferred example, involved parties comprise of nodes of a private peer-to-peer network or distributed ledger, and the stipulated condition is distributed ledger consensus over the peer-to-peer network, Hunn’317 ¶140).
As per claims 5, 12, and 18, Hunn’317 discloses as shown above with respect to claims 1, 8 and 14. Hunn’317 does disclose the use of inline comments (Hunn’317 ¶57) but does not expressly disclose wherein the user interface element is an annotation corresponding to the inline comment.
However, Gray furtther teaches wherein the smart contract comprises programming code, the programming code comprising an inline comment, and to transmit the second query to the function, the computer program logic further causes processor to: cause the function to determine the user interface element based on the inline comment (Cryptlets, blockchains and smart contracts may get registered with the cryptlet fabric registry service. The cryptlet container service may publish the Cryptlet Catalog for on-chain smart contract, front end user interface (UI) and systems integration developers discover and use cryptlets. Developers using the service level APIs may interact with the blockchain via cryptlets and not be concerned or even necessarily know they are working with blockchain data. User Interfaces and Integrations to other systems may interact with cryptlet surface level APIs to rapidly integrate and build applications, Gray Col. 12 lines 17-27).
Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to use Gray’s ability to utilize cryptlets within smart contracts in Hunn’317’s system to improve the system and method with reasonable expectation that this would result in a smart contract management system that is able to create and execute smart contracts that have an internal functionality that can handle triggers and other events.
The motivation being that there may be a need to change a smart contract, such as changing the logic of the smart contract due to a bug, a change in one of the counterparties due to assignment of the contract, or some other reason. However, in some examples, if the smart contract itself is changed, it will no longer register as valid. In some examples, instead of changing the smart contract itself, the smart contract remains unchanged, while creating a new version of the contract. In some examples, creating a new version of the smart contract may require the agreement of all counterparties to the smart contract, unless, for example, the previously agreed-upon terms of the smart contract allow for a unilateral change or a change that only needs to be agreed to by a particular subset of the counterparties (Gray Col. 3 lines 29-42).
As per claims 7 and 20, Hunn’317 and Gray disclose discloses as shown above with respect to claims 1 and 14. Hunn’317 further discloses a display device communicatively coupled to the processor; and wherein to cause the representation of the user interface element to be presented in the user interface, the computer program logic further causes the processor to: cause the display device to display the user interface comprising the user interface element (display to the user, Hunn’317 ¶224; via APIs, ¶32).
As per claim 21, Hunn’317 and Gray disclose discloses as shown above with respect to claim 14. Hunn’317 further discloses wherein the computing device generates the representation of the user interface element without tracking a state of the smart contract (The parameters in the natural language of the clause are marked herein through surrounding asterisks but would preferably be highlighted in some visual manner in a user interface. The natural language for the clause and inserting bindings to the template model, using a markup language. An exemplary marked-up template for the aforementioned clause may be: [0069] In case of delayed delivery[{“except for Force Majeure cases,”:? forceMajeure}] the Seller shall pay to the Buyer for every [{penaltyDuration}] of delay penalty amounting to [{penaltyPercentage}]% of the total value of the Equipment whose delivery has been delayed. Any fractional part of a [{fractionalPart}] is to be considered a full [{fractionalPart}]. The total amount of penalty shall not however, exceed [{capPercentage}]% of the total value of the Equipment involved in late delivery. If the delay is more than [{termination}], the Buyer is entitled to terminate this Contract, Hunn’317 ¶68-¶69).
Claim(s) 3-4, 6, 10-11, 13, 16-17, and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hunn et al. (US PG Pub. 2019/0122317, hereinafter Hunn’317) and further in view of Hunn et al. (US PG Pub. 2017/0287090, hereinafter Hunn’090).
As per claims 3, 10, and 16, Hunn’317 and Gray disclose as shown above with respect to claims 1, 8 and 14. The combination of Hunn’317 and Gray do not expressly disclose wherein the event notification indicates a second user has signed the smart contract and the user interface representation comprises a signature of the second user.
However, Hunn’090 teaches wherein the event notification indicates a second user has signed the smart contract and the user interface representation comprises a signature of the second user (automatically send notifications, Hunn’090 ¶60 and ¶144; see also notifications of any changes, ¶171) (Examiner notes the ability to define the logic or rules for when to send the automated notifications as including the ability to send notifications when users have signed the contract).
The Hunn’317, Gray and Hunn’090 references are analogous in that both are directed towards/concerned with smart contract creation and management. Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to use Hunn’090’s ability to provide notifications in Hunn’317’s system to improve the system and method with reasonable expectation that this would result in a smart contract management system that is able to create and execute smart contracts.
The motivation being that there is a need in the digital contract management field to create a new and useful system and method for data-driven legal contracts that can use and respond to data (Hunn’090 ¶8).
As per claims 4, 11, and 17, Hunn’317 and Gray disclose as shown above with respect to claims 1, 8 and 14. Hunn’317 does not expressly disclose wherein the event notification indicates a deposit of funds associated with the smart contract has been made and the user interface representation comprises a text string indicating the deposit has been made.
However, Hunn’090 teaches wherein the event notification indicates a deposit of funds associated with the smart contract has been made and the user interface representation comprises a text string indicating the deposit has been made (automatically send notifications, Hunn’090 ¶60 and ¶144; notification of a transaction, ¶147; see also notifications of any changes, ¶171).
The Hunn’317, Gray and Hunn’090 references are analogous in that both are directed towards/concerned with smart contract creation and management. Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to use Hunn’090’s ability to provide notifications in Hunn’317’s system to improve the system and method with reasonable expectation that this would result in a smart contract management system that is able to create and execute smart contracts.
The motivation being that there is a need in the digital contract management field to create a new and useful system and method for data-driven legal contracts that can use and respond to data (Hunn’090 ¶8).
As per claims 6, 13, and 19, Hunn’317 discloses as shown above with respect to claims 1, 8 and 14. Hunn’317 does not expressly disclose wherein the user interface element comprises a selectable element corresponding to an alternative term of the smart contract and wherein the computer program logic further causes processor to: receive, from the user interface, an indication a selection of the alternative term; and send a notification to a computing device associated with a second user associated with the smart contract, the notification indicating the selection of the alternative term (‘Programmable components’ are data objects that operate like programmable clauses in that they are programmed to respond in response to data in the manner mentioned herein, but are embedded in natural language contracts (e.g., a ‘price’ object that is programmed to change in response to an event occurring such as if the temperature in shipping container breaches a defined range). ‘Programmable components’ can be embedded into, or otherwise used by, a natural language clause. A natural language clause is preferably a static clause or subsections of a clause that includes natural language content. The natural language content is preferably not dynamic. For example, a ‘price’ component that operates to dynamically adjust the price of a good provided under a supply agreement may be embedded into a pricing natural language clause. Multiple programmable components may be added into a given clause and multiple clauses in a contract may utilize programmable components. Programmable components may be connected, interdependent, or otherwise reference one another in the same clause or across multiple clauses in the same manner as programmable clauses. For example, a price clause may update a warranty clause. A potential benefit of using programmable components is that data-driven functionality (as stated herein) can be introduced into natural language content of data-driven contracts. Such a hybrid clause structure may be more accessible and easier for some users. Programmable components may be used in at least two ways. Firstly, to create or use natural language contract templates that are augmented with data-driven functionality. In one such embodiment, programmable components may be used to generate a data-driven contract with dynamic functionality that users are able to autofill with data and configure. For example, users may set a ‘price’ programmable component to $1000 per unit subject to a metric measurable by an edge computing/IoT device to fall between variable X and variable Y. Programmable components can be configured to update another programmable component based on defined conditions (e.g., for every price decrease of 3%, the warranty period is extended by 2 months). Programmable components could be easily embedded in natural language contracts through drag and drop or other suitable user interfaces. Secondly, programmable components may be used in conjunction with NLP functionalities, Hunn’090 ¶74).
Both the Hunn’317 and Hunn’090 references are analogous in that both are directed towards/concerned with smart contract creation and management. Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to use Hunn’090’s ability to allow different programming languages and functionalities thereof for smart contracts in Hunn’317’s system to improve the system and method with reasonable expectation that this would result in a smart contract management system that is able to create and execute smart contracts.
The motivation being that there is a need in the digital contract management field to create a new and useful system and method for data-driven legal contracts that can use and respond to data (Hunn’090 ¶8).
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the Examiner should be directed to ANDREW B WHITAKER whose telephone number is (571)270-7563. The examiner can normally be reached on M-F, 8am-5pm, EST.
If attempts to reach the examiner by telephone are unsuccessful, the Examiner’s supervisor, Lynda Jasmin can be reached on (571) 272-6782. 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 Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-
automated- interview-request-air-form
/ANDREW B WHITAKER/Primary Examiner, Art Unit 3629
Prosecution Insights