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 .
Claims 1-13 are cancelled. Claims 14 and 25 and independent. Claims 14-26 are new, pending, and rejected. Amendment to the claims have been accepted.
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 8/21/2024 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
The information disclosure statement (IDS) submitted on 4/21/2025 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
The information disclosure statement (IDS) submitted on 5/6/2025 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
The information disclosure statement (IDS) submitted on 9/17/2025 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Objections
Claims 19 and 24 objected to because of the following informalities:
Claim 19: ‘… wherein the generated a configuration data set comprises… ’. Article ‘a’ should not be between ‘generated’ and ‘configuration data set’. Suggested claim revisions include ‘… wherein the generated configuration data set comprises… ’
Claim 24: ‘… a vehicle performance by the vehicle is exceeded or fallen short of compared to to a respective vehicle performance of vehicles of a vehicle fleet… ’. The word ‘to’ is repeated twice, and the term ‘compared to’ is an improper subject for the term ‘fallen short of’. Suggested claim revisions include ‘… a vehicle performance by the vehicle is exceeded or fallen short of a respective vehicle performance of vehicles of a vehicle fleet… ’
Claim 24: 'the minting of the NFT is performed in response to:… a fixed point in time is reached or a fixed duration of time passes… a particular vehicle function is present or absent in the vehicle; or a vehicle performance by the vehicle is exceeded or fallen short of a respective vehicle performance…'. The verbs above should be in present participle form. Suggested claim revisions include 'the minting of the NFT is performed in response to:… a fixed point in time being reached or a fixed duration of time passing… a particular vehicle function being present or absent in the vehicle; or a vehicle performance by the vehicle exceeding or falling short of a respective vehicle performance… '
Appropriate correction is required.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 14, 15, 22, 24-26 is/are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Brook (Brook et al., US 20220292463 A1).
Regarding claim 14, Brook teaches a method comprising: recording, by at least one vehicle-internal recording device of a vehicle, vehicle-related raw data (Fig. 1, Sensors 32, ¶40, "…the vehicle condition data may be interpretations of raw sensor data… "); storing, by a vehicle-internal or a vehicle-external collection device, at least a subset of the recorded vehicle-related raw data, preparing, by a vehicle-internal or a vehicle-external aggregation device, at least the subset of stored raw data as prepared data (¶40, " In other embodiments, a set of vehicle condition data may be collected at several time intervals over a time period (e.g., a day)… which includes the set of vehicle condition data collected over the time period", the vehicle condition data is collected over several time intervals in a time period, aggregating stored sets of vehicle condition data creating the resultant set of vehicle condition data (prepared data), such that the ability to collect data over several time intervals over the time period teaches that at least all but the last set of vehicle condition data over the time intervals were stored to later aggregate over the time period); converting, by a vehicle-internal conversion device, the prepared data into non-fungible token (NFT) input data (¶40, "the vehicle head unit 34 or mobile device 12 may generate and transmit a transaction which includes the set of vehicle condition data collected over the time period", the vehicle head unit generates a transaction (NFT input data) from the prepared data (thus converting the prepared data into the NFT input data)); and minting, by the vehicle-external minting device, an NFT that incorporates the NFT input data in an unchanged form (¶41, the transaction is broadcasted from the vehicle (such that everything past the broadcast is external) and the other network participants store the transaction on the blockchain (minting an NFT incorporating the unchanged NFT input data)) and comprises at least a proof of ownership, usage rights, or properties of the vehicle (Fig. 5, ¶41, the vehicle condition data and identity of the person owning the vehicle are added to the transaction data).
Regarding claim 15, Brook teaches the method of claim 14, wherein at least one vehicle-external recording device is also involved in the preparing of the prepared data (Fig. 1, mobile device 12 contains sensors 42 (at least one vehicle-external recording device) that obtain the vehicle condition data as well).
Regarding claim 22, Brook teaches the method of claim 14, wherein a private key, using which a transaction of the NFT to a third-party can be prompted, is stored in a vehicle-internal hardware wallet or in a wallet to which there is access from the vehicle (¶56-¶57, "Each vehicle head unit 34 and/or mobile device 12 may be assigned a public key/private key pair which is identified in the blockchain network as corresponding to the vehicle head unit 34 and/or mobile device 12. If the validating network nodes receive a transaction regarding vehicle condition data that is not from an authorized vehicle head unit 34 or mobile device 12, the validating network nodes reject the transaction." a private key stored and owned by the vehicle head unit 34/ mobile device 12 used to create a valid transaction (NFT input data)).
Regarding claim 24, Brook teaches the method of claim 14, wherein the minting of the NFT is performed in response to: the vehicle being produced; the vehicle being sold; the vehicle undergoing repair or maintenance; the vehicle stopping at a fixed location; a fixed point in time is reached or a fixed duration of time passes (¶40-¶41, the transaction data (NFT input data) is generated and sent to the other nodes of the network periodically, such as every minute, every hour, or every data); the vehicle covers a fixed distance; a particular vehicle function is present or absent in the vehicle; or a vehicle performance by the vehicle is exceeded or fallen short of compared to a respective vehicle performance of vehicles of a vehicle fleet.
Regarding claim 25, the claimed limitations recite substantially similar limitations of claim 14, and those substantially similar limitations are likewise taught by Brook. Brook further teaches a central computer (Fig. 1, vehicle condition report server 80).
Regarding claim 26, Brook teaches the information technology system of claim 25, further comprising: a mobile device coupled directly or indirectly to the vehicle via the central computer (Fig. 1, mobile device 12 is coupled to the network, which indirectly couples it to the vehicle and the vehicle condition report server (central computer)), wherein the mobile device includes the vehicle-external recording device, the vehicle-external collection device, or the vehicle-external aggregation device (Fig. 1, mobile device 12 contains sensors 42 (at least one vehicle-external recording device) that obtain the vehicle condition data as well).
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.
Claim(s) 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Brook as applied to claim 14 above, and further in view of Rueckriemen (RUECKRIEMEN et al., US 20210273819 A1).
Regarding claim 16, Brook teaches the method of claim 14. Brook does not teach but, in an analogous art, Rueckriemen teaches that the vehicle-internal aggregation device includes at least a first and second vehicle-internal aggregation device respectively preparing raw data recorded by separate first and second vehicle subsystems (Rueckriemen, Fig. 1A, ¶213, sensors 1 to N, 130-170, have respective interfaces, 132-172 (first and second vehicle subsystems), with memories where cryptographically secured readings (prepared data by respective first and second vehicle-internal aggregation devices) are created to be sent to the vehicle's main computer).
It would be obvious to one of ordinary skill in the art prior to the effective filing date of the claimed invention to modify Brook using Rueckriemen to separately prepare the readings by each individual sensor (with respective aggregators) because of the additional layers of security it provides with protecting the data (¶213, "If the sensor readings are to be transmitted to the vehicle computer system 100 in a cryptographically secured manner, i.e. encrypted and/or signed, the sensors 130, 150, 170 also each comprise a memory, possibly with a protected memory area", ¶94, "According to embodiments, timestamps and mileages are saved in unencrypted form, while personal data such as place of departure and/or destination, driver's name or purpose of the journey are encrypted.").
Claim(s) 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Brook as applied to claim 14 above, and further in view of Luciano (US 20220245976 A1).
Regarding claim 17, Brook teaches the method of claim 14. Brook does not teach but, in an analogous art, Luciano teaches that the prepared data is temporarily cached in the vehicle-internal or vehicle-external aggregation device before the prepared data is transmitted to the vehicle-internal conversion device (Luciano, ¶23, Cache and other memory devices may then be cleared/overwritten, perhaps according to a reporting time interval that matches a block time of the blockchain network. Suppose, for example, that the blockchain generates a new block of data every ten (10) minutes. An engine control unit (ECU), therefore, need only have a small memory byte size capable of storing about ten (10) minutes of diagnostic data (e.g., OBDII), maintenance data, and the vehicular data. After a predefined time (say about 9 minutes), and/or when the memory storage is about capacity, the ECU may instruct a wireless interface to upload the collected/caches data from the vehicle to the blockchain network. Once the upload write is complete or verified, the ECU may clear the allocated memory and begin storing new data.").
As the vehicular data is what is stored on the cached memory, it would suggest to one of ordinary skill in the art to modify Brook using Luciano to perform the caching before converting the data into a transaction/NFT input data, as Luciano doesn't teach that the cached data is a transaction, only the stored vehicular data.
It would be obvious to one of ordinary skill in the art prior to the effective filing date of the claimed invention to modify Brook using Luciano to temporarily cache the prepared data before transmitted it vehicle-internal conversion device because it precludes the need for long-term storage (Luciano, ¶23, "Memory bytes, in other words, need not be consumed by long term storage of OBDII data.")
Claim(s) 18-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Brook as applied to claim 14 above, and further in view of Matheson (Matheson et al., US 20230079195 A1).
Regarding claim 18, Brook teaches the method of claim 14, further comprising: a configuration data set comprising a configuration for a respective one of the at least one vehicle-internal recording device, the vehicle-internal collection device, the vehicle-external collection device, the vehicle-internal external aggregation device, the vehicle-external aggregation device, the vehicle-internal conversion device, or the vehicle-internal transmission device, wherein the configuration is read by a respective one of the at least one vehicle-internal recording device, the vehicle-internal collection device, the vehicle-external collection device, the vehicle-internal external aggregation device, the vehicle-external aggregation device, the vehicle-internal conversion device, and the vehicle-internal transmission device to control behavior of the respective device to mint a particular NFT (¶9, " In another aspect, a validating network node for validating vehicle condition data transactions in a distributed ledger network includes a transceiver configured to exchange distributed ledger data with peer network nodes, the distributed ledger data including transactions having vehicle condition data indicative of wear and tear on the vehicle or fuel efficiency of the vehicle.", the transceiver (vehicle-internal transmission device) exchanges distributed ledger data consisting of transactions (NFT input data), and wherein the transceiver is configured to perform such a task (configuration data set comprising a configuration for… or the vehicle-internal transmission device, the configuration is read by… the vehicle-internal transmission device to control behavior of the respective device to mint a particular NFT)).
Brook does not teach but, in an analogous art, Matheson teaches generating, by a configuration device, a configuration data set comprising a configuration for a device, wherein the configuration is read by the device to control behavior of the device to mint a particular NFT (Matheson, ¶68, "The platform server 312 may generate the NFTs or other blocks for a particular purchase transaction according to default configurations or configurations received from the merchant server 304 (or other device of the merchant).", the merchant server (configuration device) transmits configurations (generating the configuration data set with corresponding configuration information in the process) to the NFT-generating platform server which controls how the NFTs are made).
It would be obvious to one of ordinary skill in the art prior to the effective filing date of the claimed invention to modify Brook using Matheson to generate the configuration data set for the device because it allows for the creation of special NFTs that make further operations using the NFTs easier, such as searching the transaction history in the blockchain for special records (Matheson, ¶100)
Regarding claim 19, Brook in view of Matheson teaches the method of claim 18. Matheson further teaches that the generated a configuration data set comprises at least one of: a definition of the NFT input data to be generated; a definition of circumstances when the NFT should be minted (Matheson, ¶68, "The platform server 312 may determine whether a product associated with the purchase transaction requires new NFTs, and which NFTs to generate, according to the configurations corresponding to merchant data or product data stored in the server memory 319 or the DB memory 322.") (see claim 18 for motivation to combine); a definition of the raw data to be recorded; a definition of an aggregation function used by the vehicle-internal or vehicle-external aggregation device to prepare the raw data; or a definition of a conversion function used by the conversion device to convert the prepared data into NFT input data.
Regarding claim 20, Brook in view of Matheson teaches the method of claim 18, wherein the configuration data set is read by a respective one of the at least one vehicle- internal recording device, the vehicle-internal collection device, the vehicle-external collection device, the vehicle-internal external aggregation device, the vehicle-external aggregation device, the vehicle-internal conversion device, and the vehicle-internal transmission device (Brook, ¶9, " In another aspect, a validating network node for validating vehicle condition data transactions in a distributed ledger network includes a transceiver configured to exchange distributed ledger data with peer network nodes, the distributed ledger data including transactions having vehicle condition data indicative of wear and tear on the vehicle or fuel efficiency of the vehicle.", the transceiver (vehicle-internal transmission device) exchanges distributed ledger data consisting of transactions (NFT input data), and wherein the transceiver is configured to perform such a task (the configuration is read by… the vehicle-internal transmission device to control behavior of the respective device to mint a particular NFT)).
Matheson further teaches that the configuration data set is a pre-defined configuration data set generated from a list of predefined configuration data sets by the configuration device (Matheson, ¶68, "according to default configurations or configurations", there is a set (list) of predefined configurations that are sent to the product server from the merchant server (configuration device)) (see claim 18 for motivation to combine).
Claim(s) 21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Brook as applied to claim 14 above, and further in view of English (US 20250104051 A1).
Regarding claim 21, Brook teaches the method of claim 14. Brook does not teach but, in an analogous art, English teaches that a user manually initiates the minting of the NFT or a request to confirm the minting of the NFT is made to the user before the NFT is automatically minted (English, ¶35, the marketplace service creates an NFT on-demand for a user).
It would be obvious for one of ordinary skill in the art prior to the effective filing date of the claimed invention to modify Brook using English to create the NFT on-demand for the user because it would allow for more control over what type of NFT is created for the client (English, ¶38)
Claim(s) 23 is/are rejected under 35 U.S.C. 103 as being unpatentable over Brook as applied to claim 14 above, and further in view of Leise (Leise et al., US 20210042361 A1).
Regarding claim 23, Brook teaches the method of claim 14. Brook does not teach but, in an analogous art, Leise teaches that properties that can be configured to produce a vehicle are included in the NFT (Leise, ¶96, attributes of the vehicle used to produce the vehicle, such as the model for the vehicle and the body style of the vehicle, are used to create the VIN (vehicle identifier) (properties that can be configured to produce a vehicle). ¶126, the entries in the blockchain (NFT) correspond to the VIN of the vehicle related to the car), and for a vehicle having a unique combination of the properties, the minting of a further NFT corresponding to the unique property combination or a production of a further vehicle corresponding to the unique property combination is prevented (Leise, ¶184, vehicles on the blockchain are uniquely identified by the VIN, such that no other vehicles corresponding to the VIN can be entered onto the blockchain).
It would be obvious to one of ordinary skill prior to the effective filing date of the claimed invention to modify Brook using Leise to use a unique identifier respective of the properties used to produce the vehicle as part of the NFT because it allows for the ability to consolidate information and documentary support needed to resolve insurance claims in the wake of a vehicle collision (Leise, ¶184), preventing mistaken evidence that would be raised by having the same identifier map to different vehicles.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Sonnad (Sonnad et al., US 20190073701 A1) teaches recording, by at least one vehicle-internal recording device of a vehicle, vehicle-related raw data (¶20, " At 202 multiple sources of vehicle telemetry data are queried and received by a vehicle valuation system. The vehicle telemetry data can be collected by one or more sensors and data collectors, such as a speedometer, an accelerometer, a position sensor…"); transmitting, by a vehicle-internal transmission device, the data to a vehicle-external minting device; and minting, by the vehicle-external minting device, an NFT that comprises at least a proof of ownership, usage rights, or properties of the vehicle (¶17, ¶23-¶24, the vehicle telemetry data is sent to a valuation database where the value of the car is calculated using the telemetry data, before the value of the car is saved in the blockchain).
Haldenby (HALDENBY et al., US 20170046792 A1) teaches recording, by at least one vehicle-internal recording device of a vehicle, vehicle-related raw data; preparing, by a vehicle-internal or a vehicle-external aggregation device, at least the subset of raw data as prepared data; transmitting, by a vehicle-internal transmission device, the prepared data to a vehicle-external minting device (¶199, integrated sensor data representing current characteristics of the vehicle is aggregated by a processor in a vehicle and sent off to external computing systems); and minting, by the vehicle-external minting device, an NFT that incorporates the prepared data in an unchanged form and comprises at least a proof of ownership, usage rights, or properties of the vehicle (¶201, the receiving systems process the received sensor data to generate a ledger block representing that very data and store it in a blockchain (thus minting an NFT)).
Gorilovsky (GORILOVSKY et al., US 20200273024 A1) teaches aggregating sensor data of a vehicle and store the sensor data in a blockchain (¶287, ¶579, "The system may be one in which the aggregated sensor data is stored using the blockchain system.").
Hayes (HAYES et al., US 20210011908 A1) teaches preparing, by a vehicle-internal or a vehicle-external aggregation device, at least the subset of stored raw data as prepared data (¶64, sensor data is acquired from a plurality of sensor and filtering operations are applied to the data).
Ogawa (OGAWA et al., US 20200151971 A1) teaches acquiring information from a plurality of sensors in a vehicle (¶70) and well as software configuration information (¶71) and sends it to a remote ledger management device which records it in the blockchain (Fig. 3, ¶76).
Bevan (US 20220092532 A1) teaches a plurality of sensors, both internal and external, obtaining information about the state of a vehicle (¶65-¶71) and updating a blockchain on a remote server in response to the generation of the updated information (¶88).
Sharma (Sharma et al., US 20230246835 A1) teaches the generation of a configuration of secure distributed register tokens such as NFTs (¶44, ¶46).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMIR MAHDI HAJIABBASI whose telephone number is (703)756-5511. The examiner can normally be reached M-F 7:30-5 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, Catherine Thiaw can be reached at (571) 270-1138. 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.
/A.M.H./
Amir Mahdi HajiabbasiExaminer, Art Unit 2407
/Catherine Thiaw/Supervisory Patent Examiner, Art Unit 2407 1/8/2026