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 14-22, 24-30 are pending. Claims 14, 25 are independent. Claims 14, 19, 21, 24, and 25 are amended. Claim 23 is canceled. Claims 27-30 are new. Amendments to the claims have been accepted.
Response to Arguments
Applicant’s arguments, see pp. 7-8 (pp. 1-2 of Remarks), filed 04/02/2026, with respect to the rejection(s) of claim(s) 14, 15, 22, and 24-26 under 35 U.S.C. § 102 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of 35 U.S.C. § 103 (Brook in view of Rueckriemen).
Applicant's arguments with respect to dependent claims 17-21 filed 04/02/2026 have been fully considered but they are not persuasive.
Applicant's arguments do not comply with 37 CFR 1.111(c) because they do not clearly point out the patentable novelty which he or she thinks the claims present in view of the state of the art disclosed by the references cited or the objections made. Further, they do not show how the amendments avoid such references or objections.
Applicant argues that Rueckriemen, Luciano, Matheson, and English do not remedy the deficiencies of Brook and Leise with respect to amended independent claim 14, such that they are patentably distinguishable. However, applicant does not clearly point out how the amendments avoid Rueckriemen, Luciano, Matheson, and English. Additionally, Rueckriemen teaches the limitations of the amended independent claim 14 (Rueckriemen, ¶123-¶124, see 103 rejection below for additional details). Accordingly, the argument is not persuasive.
Claim Rejections - 35 USC § 103
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claim(s) 14-16, 22, 24-26, 28, and 30 is/are rejected under 35 U.S.C. 103 as being unpatentable over Brook (Brook et al., US 20220292463 A1, cited in prior office action) in view of Rueckriemen (RUECKRIEMEN et al., US 20210273819 A1, cited in prior office action).
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 (¶40, "… a set of vehicle condition data may be collected at several time intervals over a time period (e.g., a day)… "), preparing, by a vehicle-internal or a vehicle-external aggregation device, at least the subset of stored raw data as prepared 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." ¶42, "The transaction 112 may include the vehicle condition data or a cryptographic hash value corresponding to the vehicle condition data.". A set of vehicle data is collected (stored) several times in a time period, aggregated, then cryptographically hashed so that it can be turned into a transaction on the blockchain); converting, by a vehicle-internal conversion device, the prepared data into NFT input data; transmitting, by a vehicle-internal transmission device, the NFT input data to a vehicle-external minting device; and minting, by the vehicle-external minting device, a second NFT that incorporates the NFT input data in an unchanged form (¶42, "… generate a transaction 112 including a representation of the vehicle condition data wherein the transaction 112 is stored in the blockchain 18, and transmit, the transaction 112 to at least one other participant in a distributed ledger network of participants") 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).
Although Brook teaches the manufacturer being involved in the blockchain (¶21, "For example, a distributed ledger may be maintained by nodes, such as computing devices associated with vehicle manufacturers… "), Brook does not explicitly teach but, in an analogous are, Rueckriemen teaches minting, for a vehicle by a vehicle-external minting device during production of the vehicle, a first non-fungible token (NFT) (¶123, "In particular, the vehicle manufacturer will be able to initialise the vehicle or personalise the program module. Initial vehicle data of the vehicle may be entered in the blockchain.") that includes a vehicle identification number and a combination of selected configurable properties for producing the vehicle (¶124, " According to embodiments, the fourth data record comprises technical vehicle specifications… In particular, such an entry is not able to be subsequently manipulated. For example, the data record may comprise a chassis number, an engine number, information regarding vehicle properties and/or a hash of the registration certificate, i.e. registration certificate part I and/or II, of the vehicle… The information regarding vehicle properties may include, for example, the information contained in the registration certificate part I and/or II, such as date of first registration, vehicle category, type of bodywork, vehicle identification number, make, type/variant/version,"), wherein the minted first NFT includes a unique combination of the selected configurable properties (¶89, "For example, the vehicle computer system requests identifiers of components of the vehicle electronics, such as series, type and/or manufacturer identifiers, which are saved in the components of the vehicle electronics. According to embodiments, an identifier of the vehicle may be calculated from the identifiers of the individual components. This identifier is a characteristic of this vehicle, which defines the specific composition of its components and thus the condition of the vehicle. In a sense, it is a “fingerprint” of the vehicle.", ¶97: "This identifier may therefore be, for example, an identifier assigned to the individual vehicle, which represents a characteristic of the vehicle defined by the specific combination of electronic components.") and further minting of a NFT having the unique combination of the selected configurable properties is prevented (¶144, "Personalisation may be implemented by using attributes which identify the corresponding vehicle. For example, these attributes, either individually or in combination with each other, uniquely identify the vehicle.", the combination of attributed uniquely identify the vehicle, such that no other vehicle made for the production of a vehicle will have the same set of properties). 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 Rueckriemen to mint a first NFT during the production of the vehicle to include the vehicle identification number and a set of properties that uniquely identify the vehicle because it would allow people with access to the blockchain information about the basic properties of the vehicle, where the information can't be manipulated (Rueckriemen, ¶123, ¶124, "Embodiments may have the advantage that such a data record provides information regarding the basic properties of the vehicle. In particular, such an entry is not able to be subsequently manipulated."), and because it allows for easy recognition of when the basic properties of the vehicle are forcibly changed (Rueckriemen, ¶98, "Therefore, the electronic components themselves may be understood as sensors for detecting a composition of electronic components in the vehicle. According to embodiments, the vehicle data comprise a plurality of identifiers of individual electronic components. According to embodiments, if an identifier assigned to a plurality of electronic components changes, the vehicle data comprise identifiers of individual electronic components of the plurality of electronic components that have changed.") (see also Rueckriemen, ¶252)
Regarding claim 15, Brook in view of Rueckriemen teaches the method of claim 14, wherein at least one vehicle- external recording device is also involved in the preparing of the prepared data (Brook, 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 16, Brook in view of Rueckriemen teaches the method of claim 14. Rueckriemen further 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 obvious to one of ordinary skill in the art to further modify Brook in view of Rueckriemen 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 (Rueckriemen, ¶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.").
Regarding claim 22, Brook in view of Rueckriemen 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 (Brook, ¶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 in view of Rueckriemen 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 being reached or a fixed duration of time passing (Brook, ¶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 being present or absent in the vehicle; or a vehicle performance by the vehicle exceeding or falling short of 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 in view of Rueckriemen. Brook further teaches a central computer (Brook, Fig. 1, vehicle condition report server 80).
Regarding claim 26, Brook in view of Rueckriemen teaches the information technology system of claim 25, further comprising: a mobile device coupled directly or indirectly to the vehicle via the central computer (Brook, 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 (Brook, 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 28, and substantially claim 30, Brook in view of Rueckriemen teaches the method of claim 14. Rueckriemen further teaches that the selected configurable properties include a motorization of the vehicle, a selected chassis of the vehicle (Rueckriemen, ¶124, "For example, the data record may comprise a chassis number…"), a selected paint of the vehicle (Rueckriemen, ¶124, "… colour of the vehicle"), or selected special equipment for the vehicle (see claim 14 for motivation to combine).
Claim(s) 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Brook in view of Rueckriemen as applied to claim 14 above, and further in view of Luciano (US 20220245976 A1, cited in prior office action).
Regarding claim 17, Brook in view of Rueckriemen teaches the method of claim 14. Brook in view of Rueckriemen 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 in view of Rueckriemen 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 in view of Rueckriemen 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 in view of Rueckriemen as applied to claim 14 above, and further in view of Matheson (Matheson et al., US 20230079195 A1, cited in prior office action).
Regarding claim 18, Brook in view of Rueckriemen 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 (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 (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 in view of Rueckriemen 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 in view of Rueckriemen 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 Rueckriemen and 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 Rueckriemen and 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 in view of Rueckriemen as applied to claim 14 above, and further in view of English (US 20250104051 A1, cited in prior office action).
Regarding claim 21, Brook in view of Rueckriemen 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 in view of Rueckriemen 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) 27, 29 is/are rejected under 35 U.S.C. 103 as being unpatentable over Brook in view of Rueckriemen as applied to claim 14 and 25 above, and further in view of Hopkins (Hopkins, III., US 10521780 B1).
Regarding claim 27, and substantially claim 29, Brook in view of Rueckriemen teaches the method of claim 14. Brook in view of Rueckriemen does not teach but, in an analogous art, Hopkins teaches that the vehicle identification number is stored in the first NFT (4:28-32, the VIN is stored in the blockchain, where the VIN is unique to the vehicle) as plain text (5:45-57, the blockchain is populated with text as original data. 4:14-21, the blockchain has already been populated with information before the buyer meets with the seller).
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 in view of Rueckriemen using Hopkins to store the VIN in the first NFT as plain text because it would allow someone with access to the blockchain to identify the VIN of the vehicle the NFT represents at a glance.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Ashkinazi (US 20240056297 A1) teaches that a distributed ledger associates each vehicle with a VIN, along with one or more properties such as a model, manufacturer, color, chassis serial number, engine serial number, etc. (¶47, ¶96)
Gebreab ("NFT-Based Traceability and Ownership Management of Medical Devices,", 2022) teaches a manufacturer creating an NFT for a medical device using metadata, the metadata including attributes related to device details and unique device identifier code (p.8, V. IMPLEMENTATIONDETAILS, "To initiate the tokenization process a manufacturer submits on the chain a link of the desirable product metadata URI (e.g., IPFS link) and requests to create an NFT for the medical device (e.g., cardiac pace maker).The submitted metadata includes attributes related to the device details and unique device identifier (UDI) code.")
Ryu (Ryu et al., US 20220114845 A1) teaches that, for a de-identified version of a VIN, digits other than a production serial number are plain text (¶73)
Kikinis (US 20200099512 A1) teaches that the blockchain is associated with the vehicle's VIN, which incorporates the vehicle's manufacturer and model information into an encoded string that uniquely described the vehicle's manufacture in detail and cannot be altered (¶139).
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 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
/David Garcia Cervetti/Primary Examiner, Art Unit 2409
Prosecution Insights