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 .
Priority
Acknowledgment is made of applicant’s claim for foreign priority under 35 U.S.C. 119 (a)-(d). The certified copy has been filed in parent Application No. DE10 2022 004 820.5, filed on 12/20/2022.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 06/18/2025 was filed. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 12–21 are rejected under 35 U.S.C. § 101 because they are directed to an abstract idea—tokenized configuration-information management—and do not recite additional elements that integrate the abstract idea into a practical application, nor do they provide an inventive concept sufficient to amount to significantly more than the abstract idea.
The claims are directed to tokenized configuration-information management without significantly more. The claim(s) recite(s) minting a vehicle function schema as an NFT in a DLT system, assigning/selecting the NFT for a vehicle, applying the schema based on the NFT, and performing compatibility/list/hash storage steps using requirement and parameter data. This judicial exception is not integrated into a practical application because the claims merely use DLT/NFT, hashing, cloud/head unit storage, and OTA access as generic data handling tools, and “applying” is recited as a result without vehicle-control mechanics. The claims do not include additional elements sufficient to amount to significantly more than the judicial exception because the additional elements are conventional computer/network components performing routine functions, with no specific technological improvement or nonconventional implementation.
Eligibility Analysis
This rejection applies the Alice/Mayo framework as implemented by the USPTO Patent Subject Matter Eligibility Guidance.
Step 1: Statutory category
Claim 12 is a process.
Claim 21 is a machine (apparatus).
Accordingly, the claims fall within statutory categories and the analysis proceeds to Step 2A.
Step 2A, Prong One: The claims recite a judicial exception (abstract idea)
A. The “focus” of Claim 12 is tokenized configuration-information management
Claim 12 recites, in substance:
creating a tokenized record of configuration information (“digitally recording and minting … schema as an NFT … in a DLT system”);
associating that tokenized record to a vehicle (“DLT system assigns the NFT to the vehicle … at most one vehicle”);
selecting/acquiring the tokenized record; and
using the tokenized record to “apply” the configuration (“applying … an assigned vehicle function schema to the vehicle”);
where the token contains two categories of information (“requirement data” describing equipment features; “parameter data” describing settings), and (in dependents) evaluating compatibility, presenting selection lists, and hashing/storing lists locally/in the cloud.
Taken as a whole, the claim language is directed to creating, organizing, associating, evaluating, and using information about vehicle function configurations in token form (NFT/DLT) — i.e., tokenized configuration-information management.
B. Why this is an “abstract idea” under PEG groupings
Under the 2019 PEG, abstract ideas include (among other groupings) mental processes such as evaluations/judgments/comparisons and other information-processing concepts when claimed at a high level.
Here, the claims recite:
encoding requirement/parameter information in a token,
determining compatibility based on identity/requirements (Claims 16, 19), and
hashing and list creation/storage/distribution (Claim 20),
all expressed as high-level functional results (what is achieved), not a specific technical mechanism (how achieved). This is consistent with Federal Circuit precedent treating claims focused on high-level information collection/analysis/organization as abstract.
Accordingly, Claims 12–21 recite an abstract idea (a judicial exception).
Step 2A, Prong Two: The claims are not integrated into a practical application
Under Prong Two, the inquiry is whether additional elements apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit (i.e., integrates it into a practical application), as opposed to merely appending generic computer/network implementation or insignificant extra-solution activity.
A. The “additional elements” are generic environment/implementation labels
The claim’s additional elements include: vehicle, DLT system, NFT, cloud, head unit, OTA network, hash values, and “configuration management system.”
As claimed, these elements function as general-purpose computing/network components and data-integrity techniques used to implement the information management scheme:
“DLT/NFT” are invoked as a storage/recordation/assignment substrate, without reciting a specific improvement to ledger operation (e.g., consensus protocol improvement, storage structure improvement, latency reduction, security mechanism beyond generic hashing).
“cloud,” “head unit,” and “OTA network” are recited as where the data is accessed/stored/communicated, not as a particular technical solution.
“hash values” and “lists” are recited as generic integrity/accounting constructs (compute hash; store list), not as a specific cryptographic protocol or nonconventional verification architecture.
B. “Applying … the schema to the vehicle” is results-oriented and omits vehicle-control mechanics
A central limitation is “applying … an assigned vehicle function schema to the vehicle.” That is claimed as an outcome, not as a vehicle control implementation. The claim does not recite how the vehicle is configured (e.g., ECU flashing procedures, secure boot/attestation chain, rollback/failsafe behavior, messaging protocols, timing constraints, safety interlocks, actuator gating, or any control-loop implementation).
Thus, the claim does not recite a concrete technological procedure for controlling or reconfiguring vehicle systems; it recites using tokenized configuration information to reach a desired result (“apply configuration”), which is characteristic of result-based functional claiming that does not itself supply a practical-application integration. Cf. Federal Circuit criticism of “result-based functional language” that does not describe how the results are achieved in a non-abstract way.
C. Vehicle context is a field-of-use limitation
While the claims are framed in a vehicle setting, the claimed steps remain the same information-centric operations (create token; associate; select; compare; store; hash; list). The vehicle context primarily limits the abstract idea to a technological field without claiming a technical improvement in vehicle operation itself.
Prong Two conclusion
Considering the additional elements individually and as an ordered combination, the claims do not integrate the abstract idea into a practical application; they use generic computing/network constructs (DLT/NFT, cloud/OTA, hashing, lists) to perform tokenized configuration-information management and to achieve the result “apply schema,” without reciting a specific technological improvement or vehicle-control mechanism.
Accordingly, the claims are directed to the abstract idea at Step 2A.
Step 2B: The claims lack an inventive concept (“significantly more”)
At Step 2B, the question is whether any additional element(s), alone or as an ordered combination, amount to significantly more than the judicial exception.
A. No more than generic computer implementation
The Court instructs that merely implementing an abstract idea on generic computer components does not supply an inventive concept.
Here, the claimed implementation uses conventional components/techniques:
token recordation on a networked system (DLT/NFT),
selection/acquisition and association to an identifier,
compatibility evaluation (comparison of requirement data vs equipment features),
hashing and storing/distributing lists,
access via OTA.
These are conventional functions of computer networks, data integrity checks, and distributed storage environments, recited at a high functional level.
B. No nonconventional ordered combination
While an inventive concept can sometimes be found in a nonconventional and non-generic arrangement of conventional components, the claims here do not recite such an arrangement with specific technical detail; rather, they recite routine information-handling steps and generic storage/communication choices (local list vs cloud list; hash values based on categories of data) to implement the abstract idea.
Step 2B conclusion
The claims, considered individually and as an ordered combination, do not add an inventive concept sufficient to transform the abstract idea into patent-eligible subject matter.
Dependent claims (13–21)
Claims 13–21 do not change the eligibility outcome because they further specify:
additional data content (special equipment code; HW/SW versions; lighting/audio parameters) (Claims 13–15),
additional information evaluation/presentation (compatibility; selection lists; storing list in head unit) (Claims 16–18),
additional administrative/list creation and compatibility evaluation by a configuration management system (Claim 19),
additional generic integrity/storage distribution (hashes, local list, cloud distributed list) (Claim 20), and
generic access via OTA (Claim 21),
all of which remain within or add routine computer implementation to the same tokenized configuration-information management concept.
101 Analysis Conclusion
Claims 12–21 are rejected under 35 U.S.C. § 101 because they are directed to an abstract idea—tokenized configuration-information management—and do not recite additional elements that integrate the abstract idea into a practical application (Step 2A), nor do they provide an inventive concept sufficient to amount to significantly more than the abstract idea (Step 2B).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 12, 13, 16, 19, and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Wright US-20180089256-A1), in view of Kreuz (US-7039511-B1).
Regarding Claim 12
Disclosure by Wright
Wright teaches:
A method for
"Methods for managing entitlements of products and services using blockchain are described." (Abstract)
Rationale: Wright explicitly identifies the subject matter as a method for managing product entitlements.
individually assigning at least one vehicle function schema,
"Tagging refers to the operation of associating one or more tags to a client software component or document or piece of information." ([0033]); "Entitled products may include... tangible assets such as automobiles." ([0007])
Rationale: Wright teaches individually assigning a unique tag/entitlement to a software component for an asset, including automobiles. In the combined system, the tag serves as the tokenized entitlement container, while the content of the vehicle function schema (the specific configuration data describing the entitled vehicle functions) is taught by Kreuz, as discussed below.
the method comprising:
"One method includes the steps of..." (Abstract)
Rationale: Wright introduces the subsequent steps as a method comprising specific transactional actions.
digitally recording and minting the at least one vehicle function schema as a non-fungible token (NFT)
"At step 1010 blockchain 910 executes a smart contract that corresponds to the entitlement transaction… The corresponding smart contract creates an entitlement block that includes the entitlement transaction data and adds the entitlement block to ledger 918." ([0169]); "Table 1 below provides an example of the attributes that may be included in a tag…" ([0044]); "A unique identifier for the tagged instance of a client software component." (Table 1, introduced at [0044])
Rationale: Wright explicitly teaches blockchain ledger recording via smart-contract creation of an entitlement block added to the ledger, and further teaches a tag structure with a unique identifier for a tagged instance (Table 1). These verbatim disclosures support the digitally recording and minting aspects, with NFT terminology properly addressed as an obvious implementation choice.
in a predetermined number
"The maximum number of users to which the client software components can be provided, or fulfilled." ([0066])
Rationale: Wright teaches that entitlements can be issued according to a set limit, such as a maximum number of fulfillments. A PHOSITA would find it obvious to implement this limit by minting the NFTs in a predetermined number corresponding to the purchased entitlement quantity.
in a distributed ledger technology (DLT) system,
"blockchain technology to provide an underlying distributed, transactional, database for entitlement management." ([0007])
Rationale: Wright explicitly utilizes a blockchain, which is defined as a distributed ledger technology (DLT) system.
wherein the DLT system assigns the NFT to the vehicle
"Entitled products may include… tangible assets such as automobiles." ([0007]); "Associates an entitlement with an ‘asset (e.g., a computing device, or any other asset…)…" (Table 2, introduced at [0152])
Rationale: Wright expressly identifies automobiles as tangible assets and teaches an entitlement transaction type that associates an entitlement with an asset (Table 2). These verbatim disclosures support that the DLT/blockchain system assigns the entitlement record (the functional equivalent of an NFT) to a vehicle asset.
and the NFT is assigned to at most one vehicle;
"a single tag is maintained for a unique instance of client software component" ([0080]); "A unique identifier for the tagged instance of a client software component." (Table 1); "Associate Entitlement... Associates an entitlement with an 'asset (e.g. a computing device, or any other asset...'" (Table 2)
Rationale: Wright teaches maintaining a single tag for a unique instance of a software component and associating an entitlement with a specific asset. Wright expressly lists automobiles as tangible assets ([0007]). A PHOSITA would understand that associating a unique entitlement token with a single vehicle instance prevents concurrent multi-vehicle assignment, thereby meeting the assigned to at most one vehicle limitation as a predictable entitlement enforcement design.
selecting or acquiring at least the NFT for the vehicle;
"At step 1002 end-user 960 purchases an entitlement to use entitled product 950…" ([0167]); "The EUID henceforth is used to refer to the entitlement." ([0170])
Rationale: Wright expressly teaches acquiring an entitlement via purchase, and identifies an entitlement identifier (EUID) used to refer to the entitlement thereafter—supporting acquisition of the specific entitlement record for the asset (vehicle context supported by [0007]).
wherein the NFT encodes technical requirements.
"Tag — as used herein is a data structure… A tag typically includes static information, or attributes, that describe the nature of the client software component such as the component name, edition, version, etc…" ([0032])
Rationale: Wright expressly teaches a tag data structure containing encoded attributes describing the client software component. This supports the encodes aspect (the mechanism of storing data in the token). For the technical requirements substance required to implement a vehicle configuration, Kreuz provides the detailed disclosure, as discussed below.
Claim Limitations Not Explicitly Disclosed by Wright
Wright does not explicitly disclose:
describing a configuration of at least one vehicle function, to a vehicle
and applying, based on the selected or acquired NFT, an assigned vehicle function schema to the vehicle
required to implement a configuration of the at least one vehicle function
wherein the configuration is described by the assigned vehicle function schema
and wherein the NFT comprises requirement data and parameter data,
wherein the parameter data describes settings of the at least one vehicle function schema,
and the requirement data describes equipment features of the vehicle required to implement the at least one vehicle function schema according to the parameter data.
Disclosure by Kreuz
Kreuz teaches:
describing a configuration of at least one vehicle function, to a vehicle,
"a central actual configuration data storage is provided, which is mounted on the vehicle side, for retrievable storage of an actual configuration data set characterizing the actual configuration of the corresponding electrical installations of the vehicle" (Abstract)
Rationale: Kreuz explicitly teaches an actual configuration data set that characterizes the actual configuration of vehicle electrical installations. This data set, stored in the vehicle, constitutes a description of a configuration of at least one vehicle function, to a vehicle.
and applying, based on the selected or acquired NFT, an assigned vehicle function schema to the vehicle,
"The required software modules can be combined during configuration and downloaded to the vehicle using conventional flash software." (Col. 9, ll. 50-52); "reconfiguration tools are provided with which computer-assisted automatic reconfiguration of a respective vehicle electrical system can be performed..." (Col. 3, ll. 48-51)
Rationale: Kreuz teaches applying a configuration to a vehicle by flashing software to its ECUs based on the customer's ordered configuration (the functional equivalent of an acquired NFT). A PHOSITA would combine this with Wright's blockchain entitlement system such that the acquired NFT triggers Kreuz's reconfiguration process.
required to implement a configuration of the at least one vehicle function,
"the stored configuration data contain all information needed to locate all control devices and software modules involved in the execution of a given functionality." (Col. 7, ll. 56-58)
Rationale: Kreuz teaches that the configuration data identifies the specific control devices and software modules that are required to implement a particular vehicle function's configuration.
wherein the configuration is described by the assigned vehicle function schema,
"a central actual configuration data storage is provided, which is mounted on the vehicle side, for retrievable storage of an actual configuration data set characterizing the actual configuration of the corresponding electrical installations of the vehicle" (Abstract)
Rationale: Kreuz's actual configuration data set is the assigned vehicle function schema, and this data set characterizes the actual configuration, directly teaching that the configuration is described by the assigned vehicle function schema.
and wherein the NFT comprises requirement data and parameter data,
"data on the hardware components include data on... possible resources and resources already in use... CPU utilization...”; (Col. 7, ll. 46-50); “programming resources" (Fig. 3)
Rationale: Kreuz teaches that vehicle configuration data sets contain resource requirements (e.g., CPU, memory) and technical parameters (e.g., programming resources) for vehicle software functions. A PHOSITA incorporating Kreuz's teachings into Wright's blockchain entitlement framework would include this data within the NFT, such that the NFT comprises both requirement data and parameter data.
wherein the parameter data describes settings of the at least one vehicle function schema,
"actual configuration data describe all electrical and electronic hardware and software components... including their component relationships." (Col. 6, ll. 33-37)
Rationale: Kreuz teaches that configuration data defines the specific settings and relationships of software components. A PHOSITA would understand this as the parameter data that describes settings of the vehicle function schema.
and the requirement data describes equipment features of the vehicle required to implement the at least one vehicle function schema according to the parameter data.
"data on the hardware components include data on connectable actuators and sensors, as well as possible resources and resources already in use, such as line connections, connectors, bus identifiers, memory areas, and CPU utilization. This serves as the basis for an examination of hardware and software replacement parts to assess their compatibility with the remainder of the system... Thus, the stored configuration data contain all information needed to locate all control devices and software modules involved in the execution of a given functionality." (Col. 7, lines 42-63)
Rationale: Kreuz explicitly teaches that configuration data includes requirement data in the form of hardware component specifications (actuators, sensors, control devices) and resource allocations. This data describes the specific equipment features (ECUs, buses, connectors) that are required to implement a vehicle function. Furthermore, this equipment is assessed for compatibility according to the parameter data (CPU utilization, memory areas, available resources) to ensure the function can be properly executed.
Motivation to Combine Wright and Kreuz
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Wright and Kreuz before them, to incorporate the vehicle-specific technical requirement and parameter mapping of Kreuz into the blockchain entitlement system of Wright.
Wright teaches a comprehensive method for managing vehicle software entitlements on a blockchain, including creating unique entitlement records (the functional equivalent of NFTs) and associating them with specific vehicle assets. However, Wright lacks the specific technical configuration data needed to verify if a vehicle's physical hardware can actually support a newly entitled function—a critical requirement for implementing such a system in the automotive context.
Kreuz provides the solution by teaching an "actual configuration data set" stored in the vehicle that characterizes the vehicle's configuration, including the specific hardware requirements (ECUs, sensors, actuators) and technical parameters (CPU utilization, memory resources) needed to implement software functions. Kreuz's system assesses hardware compatibility "according to" these technical parameters and teaches the actual application of the configuration to the vehicle via flashing software.
A PHOSITA seeking to implement Wright's blockchain-based entitlement system for automobiles would be naturally motivated to incorporate Kreuz's configuration data set and reconfiguration tools to ensure that any NFT-acquired entitlement is technically compatible with the vehicle's physical hardware and can be properly applied to configure the vehicle's systems. This combination achieves a more reliable and automated reconfiguration process that prevents the activation of functions for which the vehicle lacks the necessary hardware resources—a predictable and desirable result of integrating these complementary teachings.
Regarding Claim 13
The combination of Wright and Kreuz establishes the method of Claim 12, which is the basis for Claim 13.
Disclosure by Wright
Wright does not explicitly disclose:
wherein the requirement data comprises a special equipment code, a hardware version, or a software version of at least one of the equipment features.
Disclosure by Kreuz
Kreuz teaches the remaining elements:
wherein the requirement data comprises a special equipment code, a hardware version, or a software version of at least one of the equipment features.
See at least: "As, particularly in motor vehicles, different versions of hardware and/or software components are often developed during the life of the vehicle, it is advantageous for the reconfiguration system to be capable of approaching the problem of the existence of such different component versions…" (Col. 12, ll. 31-36); "data on the hardware components include data on connectable actuators and sensors, as well as possible resources and resources already in use, such as line connections, connectors, bus identifiers, memory areas, and CPU utilization..." (Col. 7, ll. 46-50); "the actual configuration data in this case comprise... data relating to the actual vehicle electrical system, such as data on existing data buses and existing hardware and software components." (Col. 7, ll. 37-45)
Rationale: Kreuz teaches that the requirement data (the configuration data set) includes specific identifiers and version information for equipment features. The "bus identifiers" are a form of special equipment code uniquely identifying specific vehicle buses. Kreuz expressly teaches that both hardware and software components in motor vehicles have different versions that must be tracked for proper system reconfiguration. Thus, Kreuz teaches that the requirement data comprises a special equipment code (e.g., bus identifiers), a hardware version (explicitly taught), and a software version (explicitly taught) of at least one of the equipment features. Because the claim is written in the disjunctive ("or"), these disclosures collectively satisfy the limitation.
Motivation to Combine Wright and Kreuz
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Wright and Kreuz before them, to incorporate the detailed versioning and equipment tracking taught by Kreuz into the blockchain-based entitlement management system of Wright.
As established in the analysis of Claim 12, a PHOSITA would be motivated to combine Wright's blockchain entitlement framework with Kreuz's vehicle configuration data set to ensure that NFT-acquired entitlements are technically compatible with the vehicle's physical hardware. Kreuz teaches that in the automotive field, hardware and software components evolve through "different versions" over a vehicle's life and must be tracked within a configuration record to ensure system compatibility. A PHOSITA would be motivated to include within the requirement data encoded in Wright's NFT the specific special equipment codes, hardware versions, and software versions taught by Kreuz to enable precise verification that the vehicle's equipment features—identified by specific codes and versions—can support the entitled function. This integration yields the predictable result of a more precise and reliable entitlement verification system that accounts for component versioning throughout the vehicle's lifecycle.
Regarding Claim 16,
The combination of Wright and Kreuz establishes the method of Claim 12, which is the basis for Claim 16.
Disclosure by Wright
Wright teaches:
wherein, the NFT is registered in the DLT system,
See at least: "At step 1010 blockchain 910 executes a smart contract that corresponds to the entitlement transaction… The corresponding smart contract creates an entitlement block that includes the entitlement transaction data and adds the entitlement block to ledger 918." ([0169])
Rationale: “adds the entitlement block to ledger 918” teaches registering the tokenized entitlement record in the distributed ledger technology system.
the method further comprising:
See at least: "At step 1212 vendor 930 generates a verification request… At step 1214 vendor 930 submits the verification request…" ([0200])
Rationale: Wright expressly recites additional steps (1212, 1214) that occur as part of the method, which teaches “the method further comprising” additional operations.
determining,
See at least: "Since blockchain 910 immutably tracks all transactions configuration and status information can be determined for any particular instance." ([0194])
Rationale: Wright uses “can be determined,” which teaches performing a determining operation.
using an identify of the vehicle,
See at least: "the entitlement transaction may include vehicle identification numbers (VINs) for each of the autos covered by each entitlement." ([0193])
Rationale: Wright explicitly uses “vehicle identification numbers (VINs)” as vehicle identity information in the entitlement transaction context.
Claim limitations Not Explicitly Disclosed by Wright
Wright does not explicitly teach:
a compatibility of the NFT with the vehicle.
Disclosure by Kreuz
Kreuz teaches:
a compatibility of the NFT with the vehicle.
See at least: "This serves as the basis for an examination of hardware and software replacement parts to assess their compatibility with the remainder of the system in the event of replacement of a defective component." (Col. 7, ll. 50-53)
Rationale: Kreuz explicitly teaches assessing “compatibility” of hardware/software components with the vehicle system using stored vehicle configuration data; in the Wright+Kreuz combination, the NFT represents the entitled vehicle function schema, and the compatibility assessment is performed to determine whether the NFT-entitled function/schema is compatible with the vehicle system.
Motivation to Combine Wright and Kreuz
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Wright and Kreuz before them, to incorporate Kreuz’s vehicle-system compatibility assessment into Wright’s blockchain/DLT-based entitlement (NFT) registration and vehicle-identity-based entitlement mechanism, so that, after the NFT is registered in the DLT system and associated using a vehicle identity (VIN), the system determines whether the NFT-entitled vehicle function schema is compatible with the particular vehicle’s hardware/software configuration, yielding the predictable result of preventing activation/fulfillment of entitlements that the vehicle cannot technically support.
Regarding Claim 19,
The combination of Wright and Kreuz establishes the method of Claim 16, which is the basis for Claim 19.
Disclosure by Wright
Wright teaches
further comprising:
See at least: “At step 1212 vendor 930 generates a verification request… At step 1214 vendor 930 submits the verification request…” ([0200])
Rationale: Wright expressly recites additional method steps, which teaches further comprising:.
creating a list of all NFTs minted in the DLT system;
See at least: “...blockchain 910 executes a smart contract that corresponds to the entitlement transaction… The corresponding smart contract creates an entitlement block that includes the entitlement transaction data and adds the entitlement block to ledger 918.” ([0169])
Rationale: Wright teaches that entitlement blocks are created and added to “ledger 918,” such that the set of minted entitlement records is maintained in the DLT ledger; a PHOSITA would obtain creating a list of all NFTs minted in the DLT system by enumerating the entitlement blocks stored in the ledger.
selecting at least one NFT from the list of all NFTs;
See at least: “At step 1002 end-user 960 purchases an entitlement to use entitled product 950…” ([0167])
Rationale: Wright teaches acquiring a particular entitlement record via purchase; a PHOSITA would understand this as selecting at least one NFT from the list of all NFTs (i.e., selecting at least one minted entitlement record for acquisition).
Claim limitations Not Explicitly Disclosed by Wright
Wright does not explicitly teach:
assigning,
by a configuration management system,
equipment features assigned to a vehicle
and storing the assignment;
and determining,
by the configuration management system for the at least one selected NFT,
a compatibility with the vehicle.
Disclosure by Kreuz
Kreuz teaches:
assigning,
See at least: “...computer-assisted automatic reconfiguration of a respective vehicle electrical system can be performed...” (Col. 3, ll. 49–51)
Rationale: Kreuz teaches “automatic reconfiguration” of a vehicle electrical system; a PHOSITA would understand reconfiguration necessarily includes assigning configuration items to the vehicle, which teaches assigning,
by a configuration management system,
See at least: “...reconfiguration tools are provided with which computer-assisted automatic reconfiguration of a respective vehicle electrical system can be performed...” (Col. 3, ll. 49–51)
Rationale: Kreuz’s “reconfiguration tools” that perform computer-assisted reconfiguration correspond to a system managing configuration, which teaches by a configuration management system,.
equipment features assigned to a vehicle
See at least: “data on the hardware components include data on connectable actuators and sensors, as well as possible resources and resources already in use, such as line connections, connectors, bus identifiers, memory areas, and CPU utilization.” (Col. 7, ll. 46–50)
Rationale: Kreuz expressly identifies vehicle hardware components (actuators, sensors, buses, etc.), which are equipment features of the vehicle as part of the vehicle configuration, thereby teaching equipment features assigned to a vehicle.
and storing the assignment;
See at least: “a central actual configuration data storage is provided, which is mounted on the vehicle side, for retrievable storage of an actual configuration data set characterizing the actual configuration of the corresponding electrical installations of the vehicle” (Abstract)
Rationale: Kreuz expressly teaches “retrievable storage” of an “actual configuration data set” on the vehicle side, which teaches and storing the assignment;.
and determining,
See at least: “...an examination of hardware and software replacement parts to assess their compatibility with the remainder of the system...” (Col. 7, ll. 47–50)
Rationale: Kreuz teaches assessing compatibility, which requires a determination, thereby teaching and determining,.
by the configuration management system for the at least one selected NFT,
See at least: “Thus, the stored configuration data contain all information needed to locate all control devices and software modules involved in the execution of a given functionality.” (Col. 7, ll. 56–59)
Rationale: Kreuz teaches using stored configuration data to evaluate components for a “given functionality”; when applied to the at least one entitlement/NFT selected in Wright, a PHOSITA would perform the configuration-management evaluation for the selected entitlement/NFT, thereby teaching by the configuration management system for the at least one selected NFT,.
a compatibility with the vehicle.
See at least: “...assess their compatibility with the remainder of the system...” (Col. 7, ll. 47–50)
Rationale: Kreuz expressly teaches assessing “compatibility” with the vehicle system, thereby teaching a compatibility with the vehicle.
Motivation to Combine Wright and Kreuz
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Wright and Kreuz before them, to incorporate Kreuz’s vehicle configuration management (including storing vehicle equipment-feature configuration and performing compatibility assessment against the vehicle system) into Wright’s DLT-based minting/recordation and selection of entitlement records, because both references address vehicle-related functionality controlled by stored entitlement/configuration data, and the combination yields the predictable result that a selected DLT-minted entitlement/NFT is checked for technical compatibility with the vehicle’s stored configuration before (or during) use.
Regarding Claim 21,
The combination of Wright and Kreuz establishes the method of Claim 12, which is the basis for Claim 21.
Disclosure by Wright
Wright teaches:
An apparatus
See at least: "FIG. 9 illustrates an embodiment of a system 900 that performs entitlement management using blockchain technology. System 900 includes a variety of components, including a blockchain 910, a vendor infrastructure 930, an entitlement management service (EMS) 940, one or more entitled products 950, and one or more end-users 960." ([0135])
Rationale: The cited disclosure teaches an apparatus in the form of a system comprising physical and logical components such as a blockchain platform, servers, and management services that collectively constitute the tangible machine configured to perform the claimed method.
configured to perform the method
See at least: "A computer-implemented method for managing entitlements, comprising: storing by a blockchain fabric ... creating, by the entitlement management service, an add-on entitlement ... receiving, by the blockchain fabric, an add-on entitlement transaction request ... adding, by the smart contract, the add-on entitlement to the ledger and linking the add-on entitlement to the most recently added block in the container." (Claim 12)
Rationale: Wright explicitly recites a method for managing entitlements using a blockchain. The apparatus taught by Wright (system 900 in Figure 9) is inherently configured to perform a method, as the specification describes the components (blockchain fabric, EMS, smart contracts, containers) that are specifically designed to execute these steps.
the apparatus comprising: at least one DLT system
See at least: "Blockchain 910 is a platform for distributed ledger solutions. In certain embodiments, blockchain 910 is accessed using a blockchain fabric 912, which is a modular, extensible, software architecture or framework that provides a foundation for developing blockchain applications." ([0136])
Rationale: The cited disclosure explicitly teaches a DLT system, referring to it as a "blockchain" platform for "distributed ledger solutions." The blockchain fabric and its components collectively constitute the claimed "DLT system."
configured for access
See at least: "Components of system 900 interact with blockchain 910 using request-response message pairs. In certain embodiments, each request response pair has a header form that includes a unique transaction (TRX) identifier." ([0158])
Rationale: The cited disclosure teaches that the blockchain is configured for access by other system components (vendor infrastructure, EMS, entitled products) via transaction request-response messages, demonstrating that the DLT system is structured to receive and respond to external communications.
Claim limitations Not Explicitly Disclosed by Wright
Wright does not explicitly teach:
via an Over-The-Air (OTA) network.
Disclosure by Kreuz
Kreuz renders obious:
via an Over-The-Air (OTA) network.
See at least: "The additional central control device CECU functions as a gateway between the vehicle and the environment outside the vehicle. In other words, an external system I located outside the vehicle can be connected to this control device CECU for purposes of data communication with the vehicle. Thus, with the external system I the actual configuration data stored in the actual configuration data memory ECO of the gateway control device CECU can be accessed." (Col. 6, ll. 38-45)
Rationale: While Kreuz does not use the exact acronym "OTA," it teaches a gateway control device that enables wireless communication between an external system and the vehicle for data access and software updates—the functional equivalent of an Over-The-Air network. A PHOSITA would recognize this as OTA communication, which was a well-known term for wireless vehicle communication at the time of the invention.
Motivation to Combine Wright and Kreuz
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Wright and Kreuz before them, to configure the DLT-based entitlement management system of Wright for access via the wireless vehicle communication method taught by Kreuz. Both references are directed to vehicle-related systems—Wright explicitly identifies automobiles as entitled products ([0007]), and Kreuz teaches vehicle electrical system configuration. A PHOSITA seeking to implement Wright's blockchain entitlement system for vehicle functions would naturally incorporate Kreuz's gateway and external system communication to enable Over-The-Air delivery of entitlements and configuration data to vehicles. This combination yields the predictable result of allowing remote, wireless interaction with vehicles to apply NFT-based function schemas without requiring physical connections.
Claims 14, 15, 17, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Wright US-20180089256-A1), in view of Kreuz (US-7039511-B1), and in view of Prodin (US-20120235568-A1).
Regarding Claim 14
The combination of Wright and Kreuz establishes the method of Claim 12, which is the basis for Claim 14.
Disclosure by Wright
Wright does not explicitly disclose:
wherein the vehicle function schema records parameters of visually perceptible staging of a vehicle interior of the vehicle.
Disclosure by Kreuz
Kreuz teaches:
wherein the vehicle function schema records parameters
"data on the hardware components include data on connectable actuators and sensors, as well as possible resources and resources already in use, such as line connections, connectors, bus identifiers, memory areas, and CPU utilization." (Col. 7, ll. 46-50)
Rationale: Kreuz expressly teaches that the vehicle configuration data (the vehicle function schema) records parameters—specific data values such as bus identifiers, memory areas, and CPU utilization—that define how the vehicle's electrical components and systems operate.
of a vehicle interior of the vehicle
"…a vehicle bus, a motor control device MS, a spacing cruise control device ART and an active body control ABC on an engine bus, various interior space-related components on an interior space bus, such as a combination instrument, air bag control device, automatic headlight distance control, roof operation unit, signal capture and triggering module, voice-activated operating system, various components on a KIN/Telematics bus, such as a radio, CD player, and navigation unit, as well as a pneumatic control device and a trailer connection device on an accessories bus." (Col. 9, ll. 1-10)
Rationale: Kreuz expressly identifies interior space-related components located within a vehicle interior of the vehicle, providing the location context for the claimed staging.
Claim Limitations Not Explicitly Disclosed by the Combination of Wright and Kreuz
After combining the teachings of Wright and Kreuz, the following is not explicitly disclosed:
of visually perceptible staging of a vehicle interior of the vehicle.
Disclosure by Prodin
Prodin teaches:
of visually perceptible staging of a vehicle interior of the vehicle.
“A system for staging a vehicle interior lighting may have different stages, where each stage provides a different illumination experience for the vehicle interior.” ([0004]); “These stages may include a welcome stage (e.g., activated by unlocking the vehicle), an ambient stage (e.g., activated while driving the vehicle), and a farewell stage (e.g., activated after parking the vehicle).” ([0005])
Rationale: Prodin expressly discloses “stages” (welcome/ambient/farewell) for interior illumination, which constitutes staging that is visually perceptible, and ties the staging system to “vehicle interior lighting” and “vehicle interior,” thereby teaching staging “of a vehicle interior of the vehicle.”
Motivation to Combine Wright, Kreuz, and Prodin
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Wright, Kreuz, and Prodin before them, to incorporate the vehicle-interior staging teachings of Prodin into the entitlement/token-based vehicle configuration approach of Wright as implemented with the vehicle configuration dataset of Kreuz, so that the assigned vehicle function schema/configuration dataset includes parameters directed to stage-based, visually perceptible vehicle-interior experiences (e.g., interior lighting stages), yielding the predictable result of enabling and applying an entitled interior-experience feature set through vehicle configuration data.
Regarding Claim 15
The combination of Wright and Kreuz establishes the method of Claim 12, which is the basis for Claim 15.
Disclosure by Wright
Wright does not explicitly teach:
wherein the vehicle function schema records parameters of audio or sound playback in an interior or in surroundings of the vehicle.
Disclosure by Kreuz
Kreuz teaches:
wherein the vehicle function schema
See at least: “a central actual configuration data storage is provided, which is mounted on the vehicle side, for retrievable storage of an actual configuration data set characterizing the actual configuration of the corresponding electrical installations of the vehicle” (Abstract)
Rationale: Kreuz teaches a retrievably stored “actual configuration data set” characterizing the vehicle configuration, which corresponds to the vehicle function schema.
records parameters
See at least: “data on the hardware components include data on connectable actuators and sensors, as well as possible resources and resources already in use, such as line connections, connectors, bus identifiers, memory areas, and CPU utilization.” (Col. 7, ll. 46–50)
Rationale: Kreuz teaches configuration data that includes specific values (e.g., “bus identifiers,” “memory areas,” “CPU utilization”), i.e., the schema records parameters.
Claim limitations Not Explicitly Disclosed by the Combination of Wright and Kreuz
After combining the teachings of Wright and Kreuz, the following are not explicitly disclosed:
of audio or sound playback
in an interior or in surroundings of the vehicle.
Disclosure by Prodin
Prodin teaches:
of audio or sound playback
See at least: “This invention is a system for configuring an audio system for a given Space, Such as a room or an interior of a vehicle. The System may analyze any variable or parameter in the audio System configuration that affects the transfer function at a Single listening position or multiple listening positions.” ([0025])
Rationale: Prodin explicitly teaches configuring an “audio system” and analyzing “parameters” for that audio-system configuration, which corresponds to parameters of audio or sound playback.
in an interior or in surroundings of the vehicle.
See at least: “This invention is a system for configuring an audio system for a given space, such as a room or an interior of a vehicle.” ([0025])
Rationale: Prodin expressly recites an “interior of a vehicle,” which satisfies the disjunctive location requirement in an interior (and thus meets in an interior or in surroundings of the vehicle).
Motivation to Combine Wright, Kreuz, and Prodin
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Wright, Kreuz, and Prodin before them, to incorporate Prodin’s vehicle-interior audio-system parameter configuration into the vehicle configuration schema of Kreuz as used with the entitlement/NFT-based distribution framework of Wright, thereby enabling the schema to record parameters specifically for audio/sound playback in the vehicle interior with predictable results (i.e., a configurable in-vehicle audio playback setup governed by recorded configuration parameters).
Regarding Claim 17
The combination of Wright and Kreuz establishes the method of Claim 12, which is the basis for Claim 17.
Disclosure by Wright
Wright teaches:
further comprising: Determining
See at least:
"configuration and status information can be determined for any particular instance." ([0194])
Rationale: Wright expressly discloses determining, because it states that configuration and status information “can be determined.”
of NFTs
See at least: "At step 1010 blockchain 910 executes a smart contract that corresponds to the entitlement transaction… The corresponding smart contract creates an entitlement block that includes the entitlement transaction data and adds the entitlement block to ledger 918." ([0169])
Rationale: Wright expressly discloses creation and ledger-recording of a unique blockchain entitlement (“creates an entitlement block” and “adds the entitlement block to ledger 918”), which a POSITA would recognize as a minting/registration of a unique tokenized entitlement (i.e., an NFT as recited).
Claim Limitations Not Explicitly Disclosed by Wright
Wright does not explicitly teach:
a selection list
compatible with the vehicle;
and offering the vehicle at least one NFT in the selection list of NFTs for selection.
Disclosure by Kreuz
Kreuz teaches:
compatible with the vehicle;
See at least: "This serves as the basis for an examination of hardware and software replacement parts to assess their compatibility with the remainder of the system…" (Col. 7, ll. 50-52)
Rationale: Kreuz expressly discloses assessing compatibility of vehicle hardware/software components “to assess their compatibility with the remainder of the system,” which a POSITA would apply to determining whether the NFT-entitled function/configuration is compatible with the vehicle.
Claim Limitations Not Explicitly Disclosed by the Combination of Wright and Kreuz
After combining the teachings of Wright and Kreuz, the following are not explicitly disclosed:
a selection list
and offering the vehicle at least one NFT in the selection list of NFTs for selection.
Disclosure by Prodin
Prodin teaches:
a selection list
See at least: "Select potential values for sound system parameters." (FIG. 6, step 602)
Rationale: Prodin expressly discloses multiple “potential values” that are selected, which constitutes a selection list of candidate items from which selection is made.
and offering the vehicle at least one NFT in the selection list of NFTs for selection.
See at least: "Select values for the parameters based on the statistical analysis." (FIG. 6, step 608); "Select the number and value of gain settings to be considered…" (FIG. 7, step 712)
Rationale: Prodin expressly discloses presenting multiple candidate choices (“potential values,” and “number and value … to be considered”) and then selecting among them (“Select values”), which corresponds to offering at least one item from the selection list “for selection”; in the combined system, the “items” being offered/selected are the NFTs/entitlements taught by Wright.
Motivation to Combine Wright, Kreuz, and Prodin
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Wright, Kreuz, and Prodin before them, to incorporate (i) Kreuz’s vehicle-side compatibility assessment and (ii) Prodin’s selection-list/selection workflow into Wright’s blockchain NFT entitlement framework to determine a selection list of NFTs that are compatible with a vehicle and to offer at least one NFT from that selection list for selection.
Regarding Claim 18,
The combination of Wright, Kreuz, and Prodin establishes the method of Claim 17, which is the basis for Claim 18.
Disclosure by Wright
Wright does not explicitly teach the following claim limitation:
wherein the selection list of NFTs compatible with the vehicle is stored in at least one head unit of the vehicle.
Disclosure by Kreuz
Kreuz teaches:
wherein the selection list of NFTs compatible with the vehicle is stored in at least one head unit of the vehicle.
See at least: “a central actual configuration data storage is provided, which is mounted on the vehicle side, for retrievable storage of an actual configuration data set characterizing the actual configuration of the corresponding electrical installations of the vehicle” (Abstract)
Rationale: Kreuz expressly discloses “retrievable storage” of a configuration data set in a “central … data storage” that is “mounted on the vehicle side,” i.e., stored in an in-vehicle computing/storage unit. In the context of Claim 17’s “selection list of NFTs compatible with the vehicle,” a PHOSITA would understand the in-vehicle “central … data storage” to be implemented in at least one vehicle head unit (an in-vehicle control/computing unit with memory) so that the selection list is locally available within the vehicle for use by vehicle systems and the user interface.
Motivation to Combine Wright, Kreuz, and Prodin
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Wright, Kreuz, and Prodin before them, to store the selection list of NFTs compatible with the vehicle (as determined and offered for selection in Wright's entitlement framework, informed by Kreuz's compatibility assessment) in the central vehicle-side data storage taught by Kreuz, which a PHOSITA would recognize as being implemented in at least one head unit of the vehicle.
Wright teaches determining a selection list of NFTs (add-on entitlements) compatible with specific vehicles based on configuration rules and offering those NFTs for selection. Kreuz teaches a "central actual configuration data storage mounted on the vehicle side" for "retrievable storage" of vehicle configuration data. A PHOSITA seeking to implement Wright's entitlement system in a vehicle would be naturally motivated to store the compatibility-based selection list in Kreuz's central vehicle-side data storage to make the list locally available within the vehicle. It would have been obvious to implement this central storage in a vehicle head unit, as head units are conventional in-vehicle components for storing and providing vehicle settings, configuration data, and user-customizable options, and for presenting such information to users via an integrated display and interface. This integration yields the predictable result of enabling local, in-vehicle presentation and selection of compatible NFTs without requiring continuous external connectivity.
Claims 20 is rejected under 35 U.S.C. 103 as being unpatentable over Wright US-20180089256-A1), in view of Kreuz (US-7039511-B1), and in view of Shaaf (US-20200162912-A1).
Regarding Claim 20,
The combination of Wright, and Kreuz establishes the method of Claim 19, which is the basis for Claim 20.
Disclosure by Wright
Wright teaches:
further comprising:
See at least: “At step 1212 vendor 930 generates a verification request… At step 1214 vendor 930 submits the verification request…” ([0200])
Rationale: Wright expressly recites additional method steps (1212, 1214) that occur as part of the method, which teaches further comprising:.
assigning each NFT of the list of NFTs
See at least: “each entitlement is given a distinct, unique, EUID” ([0180])
Rationale: Wright expressly teaches each entitlement is given a distinct, unique identifier, which teaches assigning each NFT of the list of NFTs.
and creating and storing in a cloud a second list
See at least: “cloud-based SaaS” ([0046])
Rationale: Wright expressly teaches cloud-based SaaS, which teaches and creating and storing in a cloud a second list.
is created and distributed
See at least: “adding, by the smart contract, an entitlement block to the ledger” ([0016])
Rationale: Wright expressly teaches adding an entitlement block to the ledger via a smart contract, which teaches is created and distributed.
in a distributed manner,
See at least: “blockchain fabric 912 … distributed ledger 918” ([0136])
Rationale: Wright expressly teaches a blockchain fabric including a distributed ledger, which teaches in a distributed manner,.
Claim limitations Not Explicitly Disclosed by Wright
Wright does not explicitly teach:
a first hash value based on requirement data
and a second hash value based on parameter data
is assigned to each NFT of the list of NFTs;
creating and locally storing in the vehicle a first list
comprising the first hash values;
comprising the second hash values
and is stored in a cloud
wherein the parameter data describes the settings of the vehicle function schema,
and wherein the requirement data describes the equipment features of the vehicle
required for implementing the vehicle function schema
according to the parameter data.
Disclosure by Kreuz
Kreuz teaches:
creating and locally storing in the vehicle a first list
See at least: “a central actual configuration data storage is provided, which is mounted on the vehicle side, for retrievable storage of an actual configuration data set characterizing the actual configuration of the corresponding electrical installations of the vehicle” (Abstract)
Rationale: Kreuz expressly teaches retrievable storage in a central actual configuration data storage mounted on the vehicle side, which teaches creating and locally storing in the vehicle a first list.
wherein the parameter data describes the settings of the vehicle function schema,
See at least: “data on the hardware components include data on connectable actuators and sensors, as well as possible resources and resources already in use, such as line connections, connectors, bus identifiers, memory areas, and CPU utilization.” (Col. 7, ll. 46–50)
Rationale: Kreuz expressly teaches resources and resources already in use including bus identifiers, memory areas, and CPU utilization, which teaches wherein the parameter data describes the settings of the vehicle function schema,.
and wherein the requirement data describes the equipment features of the vehicle
See at least: “data on the hardware components include data on connectable actuators and sensors” (Col. 7, ll. 46–48)
Rationale:Kreuz expressly teaches hardware components including actuators and sensors, which teaches and wherein the requirement data describes the equipment features of the vehicle.
required for implementing the vehicle function schema
See at least: “the stored configuration data contain all information needed to locate all control devices and software modules involved in the execution of a given functionality.” (Col. 7, ll. 56–59)
Rationale: Kreuz expressly teaches the stored configuration data contain all information needed to locate all control devices and software modules involved in the execution of a given functionality, which teaches required for implementing the vehicle function schema.
according to the parameter data.
See at least: “possible resources and resources already in use, such as line connections, connectors, bus identifiers, memory areas, and CPU utilization.” (Col. 7, ll. 46–50)
Rationale: Kreuz expressly teaches configuration-relevant resources (including bus identifiers, memory areas, and CPU utilization) as data used to characterize the actual configuration and locate modules for functionality, which teaches according to the parameter data.
Motivation to Combine Wright and Kreuz
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Wright and Kreuz before them, to incorporate Kreuz’s vehicle-side configuration data storage and configuration-based functionality evaluation into Wright’s DLT-based entitlement (NFT) management, so that vehicle functionality/entitlement records are applied using vehicle-stored configuration information and predictable compatibility/configuration outcomes are achieved for vehicle-specific functionality enablement.
Claim limitations Not Explicitly Disclosed by the Combination of Wright and Kreuz
After combining the teachings of Wright and Kreuz, the following are not explicitly disclosed:
a first hash value based on requirement data
and a second hash value based on parameter data
is assigned to each NFT of the list of NFTs;
comprising the first hash values;
comprising the second hash values
and is stored in a cloud
Disclosure by Schaaf
Schaaf teaches:
a first hash value based on requirement data
See at least: “A hash value can be generated based on the first information, the second information and software content of the one or more software components.” ([0032])
Rationale: Schaaf expressly teaches generating a hash value based on the first information and the second information; in the combined teachings, the requirement data (Kreuz’s equipment features of the vehicle) constitutes information used to generate the hash value, which teaches a first hash value based on requirement data.
and a second hash value based on parameter data
See at least: “A hash value generated in the vehicle is combined with a hash value generated by the backend , and the result is saved in the first network version 32 as well as in the second network version 34.” ([0052])
Rationale: Schaaf expressly teaches a hash value generated by the backend in addition to a hash value generated in the vehicle; in the combined teachings, the parameter data (Kreuz’s settings of the vehicle function schema) constitutes information used to generate the backend hash value, which teaches and a second hash value based on parameter data.
comprising the first hash values;
See at least: “the method is executed locally in the vehicle 11 (i.e., without network connection), and a hash value/ID is calculated.” ([0040])
Rationale: Schaaf expressly teaches a hash value/ID calculated locally in the vehicle; in the combined teachings, the locally stored vehicle-side storage would store locally calculated hash values as a first list, which teaches comprising the first hash values;.
comprising the second hash values
See at least: “a hash value generated in the vehicle is combined with a hash value generated by the backend” ([0052])
Rationale: Schaaf expressly teaches a hash value generated by the backend; in the combined teachings, the cloud storage of Wright would store backend-generated hash values as a second list, which teaches comprising the second hash values.
is assigned to each NFT of the list of NFTs;
See at least: “The information in the first metadata (MD¹) may comprise a hash of at least one or more terms and conditions of a contract” ([0026])
Rationale: Wright expressly teaches metadata comprising a hash; in view of Schaaf’s teachings of generating hash values from information and software content, a PHOSITA would assign the generated hash values into metadata associated with each entitlement/NFT record, which teaches is assigned to each NFT of the list of NFTs;.
Motivation to Combine Wright, Kreuz, and Schaaf
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Wright, Kreuz, and Schaaf before them, to incorporate Schaaf’s hash generation (including generating a hash value based on information and combining a vehicle-generated hash with a backend-generated hash) into the combined DLT entitlement management and vehicle configuration data storage/assessment of Wright and Kreuz, so that the requirement data and parameter data associated with vehicle functionality can be represented by hash values for integrity verification with predictable results of tamper-evident vehicle-function configuration/entitlement enforcement while maintaining distributed DLT recordation and vehicle-side storage.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to OLUWABUSAYO ADEBANJO AWORUNSE whose telephone number is (571)272-4311. The examiner can normally be reached M - F (8:30AM - 5PM).
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, Jelani Smith can be reached at (571) 270-3969. 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.
/OLUWABUSAYO ADEBANJO AWORUNSE/Examiner, Art Unit 3662
/JELANI A SMITH/Supervisory Patent Examiner, Art Unit 3662