DETAILED ACTION
1. Pending claims for reconsideration are claims 1-20.
Response to Arguments
2. Applicant's arguments filed 6/10/2026 have been fully considered but they are not persuasive.
In the remarks, applicant argues in substance:
That- A person of ordinary skill in the art would not have looked to Ford vehicle sensor data compression patent for guidance in determining reportable results or transmitting data to a blockchain. Further, Keiser is not pertinent to the problem faced by the inventor of verifiable off-chain computing with cryptographic guarantees through a decentralized multi-node consensus. Even at a high level of abstraction, one cannot equate vehicle sensor compression with blockchain-based automation. Keiser's problem is memory efficiency, whereas Applicant's problem is verifiable execution in a decentralized network.
In response to arguments – the examiner recognizes that obviousness may be established by combining or modifying the teachings of the prior art to produce the claimed invention where there is some teaching, suggestion, or motivation to do so found either in the references themselves or in the knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988), In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992), and KSR International Co. v. Teleflex, Inc., 550 U.S. 398, 82 USPQ2d 1385 (2007). In this case, The claims were examined in their broadest most reasonable interpretation in light of the applicant’s specification and every element of the claimed language has been mapped to the prior art used. As illustrated below in the 103 rejection, Li discloses “a smart contract automation system comprising: one or more processors configured by machine-readable instructions via the Event warden architecture which consist of blockchain nodes executing smart contract logic, i.e., processors executing machine readable instructions. Li further teaches to: receive, by the smart contract automation system, a log data” via the event warden which employs smart contracts and block chains as illustrated in the Abstract. Lee further discloses “provide, by an upkeep provider, an upkeep payload to a workflow, the upkeep payload comprising one or more active upkeeps” via the event warden which allows a user to create a proxy smart contract that specifies an interested event and … reserves a transaction to release [Abstract], i.e. the reserved transaction + event specification corresponds to the task payload(upkeep definition) supplied by a user). Li additionally discloses “determine, by the proposal workflow, whether the one or more active upkeeps is an eligible upkeep” via the following citation “the reserved transaction can only get released…when the prescribed event has taken place [Abstract]), i.e. The system evaluates whether the event condition has occurred before execution, also corresponding to determining whether the upkeep task is eligible). Keiser was introduced to disclose the limitation “determine, by the smart contract automation system, a reportable result based on the eligible upkeep and the log data” in which a POSITA (person of ordinary skil in the art) would have applied the data processing techniques of Keiser, where a processor determines results from collected data to control system operations( e.g. restoring data and actuating components), to determine a reportable result from the monitored event/log (keiser [par.0044] also see Keiser[Fig.5]). Keiser additionally teaches “and transmit, by the smart contract automation system, the reportable result to a blockchain.” via a computing system transmitting processed data or instructions over a network after determining results from sensor data Keiser[par.0033, and Keiser [par.0045]. A POSITA would therefore have been motivated to transmit the determined reportable result to the blockchain as a transaction or update in the Li system.
That- Keiser fails to teach the aspects of the claims for which it is asserted. Accordingly, the rejection of claims 1, 8, and 12 and their dependents should be withdrawn.
In response to arguments – As stated in the above argument, Keiser was introduced to disclose the limitation “determine, by the smart contract automation system, a reportable result based on the eligible upkeep and the log data” in which a POSITA ( person of ordinary skil in the art) would have applied the data processing techniques of Keiser, where a processor determines results from collected data to control system operations( e.g. restoring data and actuating components), to determine a reportable result from the monitored event/log (keiser [par.0044] also see Keiser[Fig.5]). Keiser additionally teaches “and transmit, by the smart contract automation system, the reportable result to a blockchain.” via a computing system transmitting processed data or instructions over a network after determining results from sensor data Keiser[par.0033, and Keiser [par.0045]. A POSITA would therefore have been motivated to transmit the determined reportable result to the blockchain as a transaction or update in the Li system.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over NPL EventWarden: A Decentralized Event-driven Proxy Service for Outsourcing Arbitrary Transactions in Ethereum-like Blockchains to Chao Li and Balaji Palanisamy (hereafter referenced as Li) in view of Pub.No.: US 2022/0335105 A1 to Keiser et al(hereafter referenced as Keiser).
Regarding claim 1, Li discloses “a smart contract automation system comprising: one or more processors configured by machine-readable instructions (Event warden architecture consist of blockchain nodes executing smart contract logic, i.e., processors executing machine readable instructions) to: receive, by the smart contract automation system, a log data (event warden employs…smart contracts and blockchains [Abstract]); “provide, by an upkeep provider, an upkeep payload to a workflow, the upkeep payload comprising one or more active upkeeps” (event warden allows a user to create a proxy smart contract that specifies an interested event and … reserves a transaction to release [Abstract], i.e. the reserved transaction + event specification corresponds to the task payload(upkeep definition) supplied by a user) ; “determine, by the proposal workflow, whether the one or more active upkeeps is an eligible upkeep”(the reserved transaction can only get released…when the prescribed event has taken place [Abstract]), i.e. The system evaluates whether the event condition has occurred before execution, also corresponding to determining whether the upkeep task is eligible).
Li does not explicitly disclose “determine, by the smart contract automation system, a reportable result based on the eligible upkeep and the log data; and transmit, by the smart contract automation system, the reportable result to a
blockchain.”
However, Keiser in an analogous art discloses “determine, by the smart contract automation system, a reportable result based on the eligible upkeep and the log data” (a POSITA would have applied the data processing techniques of Keiser, where a processor determines results from collected data to control system operations( e.g. restoring data and actuating components), to determine a reportable result from the monitored event/log (keiser [par.0044] also see Keiser[Fig.5]) ; and transmit, by the smart contract automation system, the reportable result to a blockchain.”(Keiser teaches a computing system transmitting processed data or instructions over a network after determining results from sensor data Keiser[par.0033, and Keiser [par.0045]. A POSITA would therefore have been motivated to transmit the determined reportable result to the blockchain as a transaction or update in the Li system.)
Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention was filed to modify Li’s decentralized event driven proxy with Keiser’s enhanced data compression in order to provide additional security. One of ordinary skill in the would have been motivated to combine Li’s event blockchain event-triggered transaction framework with Keiser’s data processing and result determination techniques to improve automated decision making based on monitored data events before submitting results to a blockchain network, yielding predictable results in automated smart contract workflows .
Regarding claim 2 in view of claim 1, the references combined disclose “wherein the one or more processors are further configured by the machine-readable instructions to: receive, by a log event provider, the log data”(i.e. receive collected data from sensors via a vehicle network, corresponding to receiving log data Keiser[par.0032]) ; “provide, by the log event provider, the log data to a trigger workflow; and determine, by the trigger workflow”(i.e. the computer processes the received sensor data through programmed operations such as identifying samples and determining differences, thereby providing data to a processing workflow (Keiser [psr.0039 -0041]) , “an eligible result, the eligible result based on the log data” (i.e. system determined results from the processed data and actuates vehicle components based on restored data [par.0044] also see fig.5]).
Regarding claim 3, in view of claim 2, the references combined disclose “wherein the one or more processors are further configured by the machine-readable instructions to: receive, by a results store, the eligible result; and determine, by the results store, the reportable result based on the eligible result” (store differences in subspaces Keiser[Fig.5/item 520]).
Regarding claim 4, in view of claim 1, the references combined disclose “wherein the determining the reportable result further comprises agreeing, by two or more nodes, an eligible result, wherein each of the two or more nodes determines the eligible result” (determine polynomial approximation Keiser[Fig.5/item 530]).
Regarding claim 5, in view of claim 1, the references combined disclose “wherein the one or more processors are further configured by the machine-readable instructions to: check, by smart contract automation system (system check and verification Li[pg.13]) , a condition associated with the blockchain; trigger, by smart contract automation system, a conditional trigger based on the condition; and execute, by smart contract automation system, a transaction based on the conditional trigger” (network can call the proxy contract to earn the service fee reserved in the contract by proving to the contract that the event has been recorded into blockchain logs, which then automatically triggers the proxy contract to release the reserved transaction Li[pg.10]).
Regarding claim 6, in view of claim 1, the references combined disclose “wherein the one or more processors are further configured by the machine-readable instructions to: store, by the smart contract automation system, the log data in a database; and transmit, by the database, the log data to one or more workflows, the workflows including the proposal workflow.”( Ethereum [2] and smart contracts [3] provides significant potential for new security designs that support a decentralized implementation of ET to overcome the single point of trust issues associated with centralized approaches. Li[pg.10])
Regarding claim 7, in view of claim 1, the references combined disclose “wherein the one or more processors are further configured by the machine-readable instructions to: receive, by a results store, the eligible result and a block reference; and
store, by the results store, the eligible result and the block reference”(the LOG opcodes in Ethereum virtual machine store the event in the transaction’s log, as a part of the transaction receipt [pg.12]).
Regarding claim 8, Li discloses “A method of smart contract automation, comprising: triggering, by a processor, a conditional trigger based on a condition of a blockchain; receiving, by the processor, a verifiable data in response to the conditional trigger”( Upon detecting the occurrence of the event specified in Cproxy, executor E can invoke Cproxy with a function invocation transaction to trigger the release of the reserved transaction in the form of a message [Fig.2]).
Li does not explicitly disclose “determining, by the processor, a recordable transaction based on the verifiable data; agreeing, by the processor and a processor of one or more nodes in a network of nodes, the recordable transaction is agreed to; and executing, by the processor, a smart contract, wherein the smart contract is based on the recordable transaction.
However, Keiser in an analogous art discloses “determining, by the processor, a recordable transaction based on the verifiable data; agreeing, by the processor and a processor of one or more nodes in a network of node” (a POSITA would have applied the data processing techniques of Keiser, where a processor determines results from collected data to control system operations( e.g. restoring data and actuating components), to determine a reportable result from the monitored event/log (keiser [par.0044] also see Keiser[Fig.5]) ; the recordable transaction is agreed to; and executing, by the processor, a smart contract, wherein the smart contract is based on the recordable transaction.”(Keiser teaches a computing system transmitting processed data or instructions over a network after determining results from sensor data Keiser[par.0033, and Keiser [par.0045]. A POSITA would therefore have been motivated to transmit the determined reportable result to the blockchain as a transaction or update in the Li system.)
Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention was filed to modify Li’s decentralized event driven proxy with Keiser’s enhanced data compression in order to provide additional security. One of ordinary skill in the would have been motivated to combine Li’s event blockchain event-triggered transaction framework with Keiser’s data processing and result determination techniques to improve automated decision making based on monitored data events before submitting results to a blockchain network, yielding predictable results in automated smart contract workflows
Regarding claim 9 in view of claim 8, the references combined disclose “wherein the verifiable data comprises a data log” ”(i.e. receive collected data from sensors via a vehicle network, corresponding to receiving log data Keiser[par.0032])
Regarding claim 10 in view of claim 8, the references combined disclose “ further comprising: identifying, by the processor, whether an active upkeep is eligible; and
proving, by the processor, an eligible upkeep, wherein the eligible upkeep is based on the verifiable data” (system check and verification Li[pg.13]),
Regarding claim 11 in view of claim 8, the references combined disclose “wherein the agreeing, by the processor and a processor of one or more nodes, the recordable transaction is agreed to, is based on consensus across the one or more nodes” (determine polynomial approximation Keiser[Fig.5/item 530]).
Regarding claim 12, Li discloses “A smart contract automation system, comprising: a processor, and a tangible, non-transitory memory configured to communicate with the processor, the tangible, non-transitory memory having instructions stored thereon that, in response to execution by the processor, cause the processor to perform operations comprising: polling, by a log poller” (i.e. monitoring blockchain event logs generated by smart contracts to detect when predefined conditions occur [Li event monitoring pg.14]), a log data associated with a blockchain; storing, by the log poller”(i.e. Li disclose that detected blockchain events and related information are maintained by the proxy service for processing and coordination of outsourced transactions , [Concretely, the protocol employs a service hub contract (Chub) to manage all ET service requests, so executors only need to track events released from Chub to get notified about new ET service requests. We next describe the two-phase process in detail.pg.14),
Li does not explicitly disclose “the log data in a database; determining, by one or more workflows, a performable event based on the log data; agreeing, by one or more nodes, a reportable result based on the performable event; and recording the reportable result on the blockchain.”
However, Keiser in an analogous art discloses “the log data in a database; determining, by one or more workflows, a performable event based on the log data” (a POSITA would have applied the data processing techniques of Keiser, where a processor determines results from collected data to control system operations( e.g. restoring data and actuating components), to determine a reportable result from the monitored event/log (keiser [par.0044] also see Keiser[Fig.5]) agreeing, by one or more nodes, a reportable result based on the performable event; and recording the reportable result on the blockchain.”(Keiser teaches a computing system transmitting processed data or instructions over a network after determining results from sensor data Keiser[par.0033, and Keiser [par.0045]. A POSITA would therefore have been motivated to transmit the determined reportable result to the blockchain as a transaction or update in the Li system.)
Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention was filed to modify Li’s decentralized event driven proxy with Keiser’s enhanced data compression in order to provide additional security. One of ordinary skill in the would have been motivated to combine Li’s event blockchain event-triggered transaction framework with Keiser’s data processing and result determination techniques to improve automated decision making based on monitored data events before submitting results to a blockchain network, yielding predictable results in automated smart contract workflows
Regarding claim 13 in view of claim 12, the references combined disclose “further comprising: providing, by an upkeep provider, an upkeep payload to one or more of the workflows, the upkeep payload comprising one or more active upkeeps” (event warden allows a user to create a proxy smart contract that specifies an interested event and … reserves a transaction to release Li[Abstract], i.e. the reserved transaction + event specification corresponds to the task payload(upkeep definition) supplied by a user); determine, by one or more workflow, whether the one or more active upkeeps is an eligible upkeep; and determine, by the smart contract automation system, the reportable result further based on the eligible upkeep.” (the reserved transaction can only get released…when the prescribed event has taken place [Abstract]), i.e. The system evaluates whether the event condition has occurred before execution, also corresponding to determining whether the upkeep task is eligible).
Regarding claim 14 in view of claim 12, the references combined disclose “wherein the one or more processors are further configured to: receive, by a log event provider” (i.e. receive collected data from sensors via a vehicle network, corresponding to receiving log data Keiser[par.0032]), the log data; provide, by the log event provider, the log data to a trigger workflow” (i.e. the computer processes the received sensor data through programmed operations such as identifying samples and determining differences, thereby providing data to a processing workflow (Keiser [psr.0039 -0041]); and determine, by the trigger workflow, an eligible result, the eligible result based on the log data, and the reportable result is further based on the eligible result” (i.e. system determined results from the processed data and actuates vehicle components based on restored data [par.0044] also see fig.5]).
Regarding claim 15 in view of claim 12, the references combined disclose “wherein the one or more processors are further configured to: receive, by a results store, an eligible result; and determine, by the results store, the reportable result based on the eligible result.” (store differences in subspaces Keiser[Fig.5/item 520]).
Regarding claim 16 in view of claim 12, the references combined disclose “wherein the one or more processors are further configured to: agreeing, by two or more nodes, an eligible result, wherein each of the two or more nodes determines the eligible result independently, the reportable result based on the eligible result” (store differences in subspaces Keiser[Fig.5/item 520]).
Regarding claim 17 in view of claim 16, the references combined disclose “wherein the eligible result is the performable event” (a POSITA would have applied the data processing techniques of Keiser, where a processor determines results from collected data to control system operations( e.g. restoring data and actuating components), to determine a reportable result from the monitored event/log (keiser [par.0044] also see Keiser[Fig.5]).
Regarding claim 18 in view of claim 12, the references combined disclose “wherein the one or more processors are further configured by the machine-readable instructions to: check, by smart contract automation system, a condition associated with the blockchain; trigger, by smart contract automation system, a conditional trigger based on the condition; and execute, by smart contract automation system, a transaction based on the conditional trigger.” (network can call the proxy contract to earn the service fee reserved in the contract by proving to the contract that the event has been recorded into blockchain logs, which then automatically triggers the proxy contract to release the reserved transaction Li[pg.10]).
Regarding claim 19 in view of claim 12, the references combined disclose
The system of claim 12, wherein the one or more processors are further configured to:
transmit the log data from the database to the one or more workflows, the workflows
including a proposal workflow.” (the reserved transaction can only get released…when the prescribed event has taken place [Abstract]), i.e. The system evaluates whether the event condition has occurred before execution, also corresponding to determining whether the upkeep task is eligible).
Regarding claim 20 in view of claim 12, the references combined disclose
“wherein the one or more processors are further configured to: sample, by an upkeep sampler, one or more of the workflows” (event warden allows a user to create a proxy smart contract that specifies an interested event and … reserves a transaction to release Li[Abstract], i.e. the reserved transaction + event specification corresponds to the task payload(upkeep definition) supplied by a user.
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 MICHAEL D ANDERSON whose telephone number is (571)270-5159. The examiner can normally be reached Mon-Fri 9am-6pm.
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, Jeffrey Pwu can be reached at (571) 272-6798. 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.
/MICHAEL D ANDERSON/Examiner, Art Unit 2433
/JEFFREY C PWU/Supervisory Patent Examiner, Art Unit 2433
Prosecution Insights