DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Information Disclosure Statement
The information disclosure statement(s) (IDS) submitted on 12/12/2025 is(are) in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Response to Amendment
The amendment filed January 5, 2026 has been entered. Claims 1-2, 4-16, and 18-20 remain pending in the application.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
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.
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.
Claim(s) 1-2, 4-16, and 18-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Lu (US 20210291691 A1) in view of Leise (US 10719501 B1).
Regarding Claims 1, 8, and 15, Lu teaches A computer-implemented method for generating one or more smart contracts for deployment onto a blockchain, the method comprising (Lu: Paragraph(s) 0040, 0042): A computer system for generating one or more smart contracts for deployment onto a blockchain, the computer system comprising: one or more processors; a non-transitory program memory coupled to the one or more processors and storing executable instructions that, when executed by the one or more processors, cause the computer system to (Lu: Paragraph(s) 0040, 0042, 0007, 0116): A tangible, non-transitory computer-readable medium storing executable instructions for generating one or more smart contracts for deployment onto a blockchain, that when executed by one or more processors of a computer system, cause the computer system to (Lu: Paragraph(s) 0040, 0042, 0007, 0116):
receiving, at one or more processors, vehicle sensor data generated from sensors mounted on or within a vehicle, wherein the plurality of sensors include a radio detection and ranging (RADAR) sensor, and/or light detection and ranging (LIDAR) sensor (Lu: Paragraph(s) 0041-0042, 0093, 0101 teach(es) The vehicle needs may be monitored via one or more sensors which report sensed data to a central controller computer device in the vehicle, which in turn, is forwarded to a management server for review and action; A sensor may be located on one or more of the interior of the transport, the exterior of the transport, on a fixed object apart from the transport, and on another transport near to the transport; The sensor may also be associated with the transport's speed, the transport's braking, the transport's acceleration, fuel levels, service needs, the gear-shifting of the transport, the transport's steering, and the like); generating, by the one or more processors and for each of one or more parametric events, a corresponding smart contract that is configured to (i) receive a transaction from a computing device, and (ii) automatically execute on the blockchain when the transaction indicates that a parametric event corresponding to the smart contract has occurred (Lu: Paragraph(s) 0042, 0093, 0095 teach(es) A smart contract may be used to provide compensation, quantify a user profile score/rating/review, apply vehicle event permissions, determine when service is needed, identify a collision and/or degradation event, identify a safety concern event, identify parties to the event and provide distribution to registered entities seeking access to such vehicle event data; Within the blockchain, one or more smart contracts may exist that define the terms of transaction agreements and actions included in smart contract executable application code, such as registered recipients, vehicle features, requirements, permissions, sensor thresholds, etc.; when a service event occurs and a user is riding in the vehicle, the sensor data monitoring may be triggered, and a certain parameter, such as a vehicle charge level, may be identified as being above/below a particular threshold for a particular period of time, then the result may be a change to a current status which requires an alert to be sent to the managing party (i.e., vehicle owner, vehicle operator, server, etc.) so the service can be identified and stored for reference); analyzing, by the one or more processors, the vehicle sensor data to determine an extent of damage to the vehicle (Lu: Paragraph(s) 0042, 0093 teach(es) sensor information may be used to identify whether the vehicle is operating safely and whether the occupant user has engaged in any unexpected vehicle conditions, such as during the vehicle access period); determining, by the one or more processors, that the parametric event has occurred based upon the extent of damage to the vehicle, wherein the parametric event is associated with a severity level based at least in part upon …, and wherein the severity level is included in a group of at least three severity levels (Lu: Paragraph(s) 0041-0042 teach(es) service centers may offer services to vehicles in a nearby area based on the vehicle's current route plan and a relative level of service requirements (e.g., immediate, severe, intermediate, minor, etc.); A smart contract may be used to provide compensation, quantify a user profile score/rating/review, apply vehicle event permissions, determine when service is needed, identify a collision and/or degradation event, identify a safety concern event, identify parties to the event and provide distribution to registered entities seeking access to such vehicle event data); and executing, by the one or more processors, the smart contract based upon the determined severity level (Lu: Paragraph(s) 0039, 0042, 0066, 0093 teach(es) Smart contract executable code invocations execute entries against the current state data of the ledger; A smart contract may be used to provide compensation, quantify a user profile score/rating/review, apply vehicle event permissions, determine when service is needed, identify a collision and/or degradation event, identify a safety concern event, identify parties to the event and provide distribution to registered entities seeking access to such vehicle event data).
However, Lu does not explicitly teach deploying, by the one or more processors, the smart contract at a particular address on the blockchain, and a severity level based at least in part upon whether damage is isolated or extensive.
Leise from same or similar field of endeavor teaches deploying, by the one or more processors, the smart contract at a particular address on the blockchain (Leise: Col. 4, lines 4-19; 9/26-48 teach(es) The Blockchain Registry may be used in conjunction with smart contracts that govern the vehicles, including autonomous or semi-autonomous vehicles. For instance, the smart contracts may relate to maintenance, warranties, vehicle loans, service contracts, UBI, trip-insurance, auto insurance policies, vehicle titles, vehicle salvage, total loss vehicles, etc.; one or more transactions or events may relate to smart contracts associated with the vehicle or a VIN (Vehicle Identification Number), or vehicle owner or driver. The smart contracts may relate to vehicle financing, vehicle ownership, vehicle title and registration, vehicle maintenance or repair, and other vehicle-related events or transactions; a smart contract may be stored on the blockchain. The smart contract may include terms of a contract for vehicle financing, the payor and payee of the contract, actions to be performed related to the contract, and any other related items to the contract. The smart contract may be found on the blockchain via the vehicle identifier), and determining, by the one or more processors, that the parametric event has occurred based upon the extent of damage to the vehicle, wherein the parametric event is associated with a severity level based at least in part upon whether damage is isolated or extensive (Leise: 11/40-54; 21/60-63; 26/24-46 teach(es) the repair facility identifies potential areas of prior damage/betterment, develops a repair plan, and prepares a repair estimate. The repair facility may request parts from suppliers, finalize any parts orders, update the estimate accordingly, and generally manage the repair of the vehicle. As part of the repair process, the repair facility may provide photographic evidence of the damage done to the vehicle. These photographs may then be uploaded to the blockchain after they have been hashed so as to ensure that any private information is protected, but also that the photographs provided are valid; the information detailing the insurance claim may include information identifying the insured, the insured asset, a policy number, an insurance provider, or an amount of damage).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the teachings of Lu to incorporate the teachings of Leise for deploying, by the one or more processors, the smart contract at a particular address on the blockchain, and a severity level based at least in part upon whether damage is isolated or extensive.
There is motivation to combine Leise into Lu because Leise’s teachings of amount of damage and smart contracts would automate the governing of the vehicles (Leise: 4/4-19; 11/40-54; 21/60-63; 26/24-46).
Regarding Claims 2, 9, and 16, the combination of Lu and Leise teaches all the limitations of claims 1, 8, and 15 above; and Lu further teaches wherein generating the corresponding smart contract includes generating the corresponding smart contract to define the parametric event as any one of: (i) theft involving the vehicle; (ii) a collision involving the vehicle; or (iii) total loss of the vehicle (Lu: Paragraph(s) 0042, 0093 teach(es) A smart contract may be used to provide compensation, quantify a user profile score/rating/review, apply vehicle event permissions, determine when service is needed, identify a collision and/or degradation event, identify a safety concern event, identify parties to the event and provide distribution to registered entities seeking access to such vehicle event data).
Regarding Claims 4, 11, and 18, the combination of Lu and Leise teaches all the limitations of claims 2, 9, and 16 above; however the combination does not explicitly teach wherein generating the corresponding smart contract includes generating the corresponding smart contract to define an action including any one of: (i) initiating an instantaneous notice of loss (INOL); (ii) communicating with an insurer entity; (iii) communicating with an emergency response entity; (iv) communicating with a towing service entity; (v) communicating with a taxi or ride-share service entity; (vi) communicating with a vehicle repair service entity; or 50(vii) communicating with a vehicle salvage entity.
Leise further teaches wherein generating the smart contract includes generating the smart contract to define an action including any one of: (i) initiating an instantaneous notice of loss (INOL); (ii) communicating with an insurer entity; (iii) communicating with an emergency response entity; (iv) communicating with a towing service entity; (v) communicating with a taxi or ride-share service entity; (vi) communicating with a vehicle repair service entity; or 50(vii) communicating with a vehicle salvage entity (Leise: Col. 9, lines 26-48; Col. 24, lines 47-52; Col. 25, lines 21-48; Col. 28, lines 36-48).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the teachings of the combination of Lu and Leise to incorporate the teachings of Leise for wherein generating the smart contract includes generating the smart contract to define an action including any one of: (i) initiating an instantaneous notice of loss (INOL); (ii) communicating with an insurer entity; (iii) communicating with an emergency response entity; (iv) communicating with a towing service entity; (v) communicating with a taxi or ride-share service entity; (vi) communicating with a vehicle repair service entity; or 50(vii) communicating with a vehicle salvage entity.
There is motivation to combine Leise into the combination of Lu and Leise because Leise’s teachings of smart contracts would facilitate to perform the actions for events specified by the smart contracts (Leise: Col. 9, lines 33-48).
Regarding Claims 5, 12, and 19, the combination of Lu and Leise teaches all the limitations of claims 4, 11, and 18 above; and Lu further teaches further comprising: receiving, at the one or more processors, supplemental data generated from one or more sources; and analyzing, by the one or more processors, the supplemental data to determine the one or more parametric events (Lu: Paragraph(s) 0091, 0065, 0042 teach(es) The vehicle may engage with another vehicle to perform various actions such as to share, transfer, acquire service calls, etc. when the vehicle has reached a status where the services need to be shared with another vehicle).
Regarding Claims 6, 13, and 20, the combination of Lu and Leise teaches all the limitations of claims 5, 12, and 19 above; however the combination does not explicitly teach further comprising: updating the smart contract based upon analyzing the supplemental data.
Leise further teaches further comprising: updating the smart contract based upon analyzing the supplemental data (Leise: Col. 15, lines 37-41; Col. 25, lines 9-19 teach(es) the vehicle identifier may be used to access the blockchain and identify a smart contract associated with the vehicle. The vehicle identifier, and the vehicle loss history, may be used to update the smart contract).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the teachings of the combination of Lu and Leise to incorporate the teachings of Leise for updating the smart contract based upon analyzing the supplemental data.
There is motivation to combine Leise into the combination of Lu and Leise because Leise’s teachings of smart contracts would facilitate to perform reporting and tracking events related to a vehicle (Leise: Col. 13, lines 35-54).
Regarding Claims 7 and 14, the combination of Lu and Leise teaches all the limitations of claims 5 and 12 above; and Lu further teaches wherein the one or more sources includes any one or more of: smart infrastructure sensor; an environmental conditions sensor; an electronic device located in the vehicle; a camera located in an area in which the vehicle is located; or a third-party server (Lu: Paragraph(s) 0065, 0042, 0091 teach(es) The transport may determine the estimated temperature of the location by determining the temperature of the vehicle at that moment and imputing a temperature delta based on historical precedent, or, the transport may look at the current weather conditions for the specific zip code identifier and upload the data from the internet; The notion of a sensor may also be a device, such as a mobile device).
Regarding Claim 10, the combination of Lu and Leise teaches all the limitations of claim 9 above; and Lu further teaches wherein the transaction includes the vehicle sensor data generated from the sensors mounted on or within the vehicle (Lu: Paragraph(s) 0042, 0041, 0093, 0103 teach(es) A sensor may be located on one or more of the interior of the transport, the exterior of the transport, on a fixed object apart from the transport, and on another transport near to the transport).
Response to Arguments
Applicant's arguments filed January 5, 2026 have been fully considered but they are not persuasive.
Regarding applicant’s argument under Claim Rejections - 35 USC § 103 that “Lu's "relative level of service requirements" relates to scheduling vehicle services based upon urgency of maintenance needs, not to determining that a parametric event has occurred based upon an extent of damage to the vehicle. Lu's service levels (immediate, severe, intermediate, minor) describe when a vehicle needs routine service, such as charging or maintenance, not severity levels associated with vehicle damage that trigger smart contract execution,” examiner respectfully argues that the features are taught by the combination of Lu and Leise (See at least (Lu: Paragraph(s) 0041-0042, and Leise: 11/40-54; 21/60-63; 26/24-46). The "relative level of service requirements" must be associated with the extent or severity level of damage by combining Lu and Leise.
Regarding applicant’s further argument that “Lu does not disclose executing a smart contract based upon a determined severity level of damage. Lu's smart contracts are used for purposes such as providing compensation, quantifying user profile scores, and applying vehicle event permissions, but Lu does not link smart contract execution to a severity level determination based upon extent of vehicle damage,” examiner respectfully argues that Lu teaches that the smart contract are associated with a collision and/or degradation event (Lu: Paragraph(s) 0039, 0042, 0066, 0093).
It is recommended for the applicant to amend the claims further with more technical details and contexts of parametric events, sensor data, damage, severity level, smart contracts, for example.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Deshpande (US 20200122773 A1) teaches System And Method For Rear Collision Avoidance, including trigger or activate a communication to a response team (e.g., emergency response team, tow company, emergency contact person, etc.) in the event that the vehicle 10 is involved in a collision, and sensor data.
Wright (US 9311271 B2) teaches Method And System For Logging Vehicle Behavior, including logging driving information associated with a vehicle.
Bryant (US 20210264526 A1) teaches Distributed Ledger System For Use With Vehicle Sensor Data And Usage Based Systems, including using a distributed ledger for use with vehicle sensor data and usage based systems.
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 CLAY LEE whose telephone number is (571)272-3309. The examiner can normally be reached Monday-Friday 8-5pm EST.
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, Neha Patel can be reached on (571)270-1492. 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.
/CLAY C LEE/Primary Examiner, Art Unit 3699