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 .
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 the claimed invention is directed to a judicial exception, namely an abstract idea, without reciting additional elements that integrate the judicial exception into a practical application or amount to significantly more than the judicial exception.
Step 1: Statutory category
Claims 12–20 recite methods and therefore fall within the statutory category of a process. Claim 21 recites an apparatus and therefore nominally falls within the statutory category of a machine. Accordingly, the claims satisfy Step 1 of the eligibility analysis.
Step 2A, Prong One: The claims recite an abstract idea
Claim 12 recites managing the assignment, acquisition, and implementation of vehicle-function configurations through uniquely assigned digital tokens. More particularly, claim 12 recites:
recording and minting a vehicle-function schema as an NFT in a predetermined number;
assigning the NFT to a vehicle and limiting the NFT to assignment to at most one vehicle;
encoding requirement data and parameter data in the NFT;
selecting or acquiring the NFT; and
implementing the NFT-defined vehicle-function configuration.
These limitations recite a commercial or legal interaction involving the creation, controlled assignment, acquisition, and exercise of a token-based entitlement to a vehicle-function configuration. Accordingly, the limitations fall within the “certain methods of organizing human activity” grouping of abstract ideas, particularly commercial or legal interactions involving agreements, licensing, entitlements, sales, or other transactions. See MPEP § 2106.04(a)(2)(II).
The limitation of applying the vehicle-function schema “based on the selected or acquired NFT” is part of the identified abstract idea. It implements the entitlement or configuration represented by the selected or acquired token. Stated differently, claim 12 recites creating a limited number of digital tokens representing vehicle-function configurations, assigning or acquiring one of the tokens, and implementing the configuration represented by the token.
The requirement data and parameter data do not alter this conclusion. The requirement data identifies equipment characteristics needed to support the configuration, while the parameter data represents the settings associated with the configuration. These limitations define the informational content managed by the claimed token-based system.
The Federal Circuit has repeatedly held that collecting, organizing, analyzing, and using information does not cease to be abstract merely because the information concerns a particular technological environment. See Electric Power Group, LLC v. Alstom S.A., 830 F.3d 1350, 1353–55 (Fed. Cir. 2016); BSG Tech LLC v. BuySeasons, Inc., 899 F.3d 1281, 1285–86 (Fed. Cir. 2018).
Accordingly, claim 12 recites an abstract idea under Step 2A, Prong One.
Step 2A, Prong Two: No integration into a practical application
The additional elements of claim 12 include:
digitally recording and minting the schema in a DLT system;
an NFT;
a vehicle;
equipment features of the vehicle; and
adjusting settings of the equipment features according to the parameter data.
Considered individually and in combination with the identified abstract idea, these elements do not integrate the abstract idea into a practical application.
The DLT system and NFT provide the computer environment used to create, store, and enforce the unique assignment of the digital vehicle-function schema. Claim 12 does not recite a particular distributed-ledger architecture, consensus mechanism, cryptographic verification process, ledger-storage technique, or improvement in the operation or security of a DLT system. The DLT system is instead invoked as a tool for performing the abstract token-assignment and recordkeeping functions.
Limiting the abstract idea to vehicle-function configurations does not provide integration into a practical application. The vehicle and its equipment identify the field in which the token-based configuration-management process is used. Merely limiting an abstract idea to a particular technological environment does not make the claim eligible. See Alice Corp. Pty. Ltd. v. CLS Bank International, 573 U.S. 208, 222–23 (2014); Bilski v. Kappos, 561 U.S. 593, 610–11 (2010); MPEP § 2106.05(h).
Claim 12 further recites:
“applying, based on the selected or acquired NFT, the assigned vehicle function schema to the vehicle by adjusting settings of the equipment features of the vehicle according to the parameter data.”
This limitation does not recite a particular technological mechanism for configuring the vehicle. The claim does not specify:
the vehicle equipment being adjusted;
the particular setting being changed;
a vehicle controller that performs the adjustment;
a particular control or communication protocol;
an ECU, domain controller, vehicle bus, or hardware-security module involved in the adjustment;
a verification or safety sequence performed before configuration;
a particular physical operation resulting from the adjustment; or
how the adjustment improves vehicle operation, configuration security, or another technology.
Under the broadest reasonable interpretation, “adjusting settings” encompasses changing configuration values in software or memory. The limitation therefore states the desired result of implementing the NFT-defined configuration without reciting a particular technical process by which that result is accomplished.
Merely instructing that the abstract token-based entitlement or configuration be applied using generic vehicle-configuration functionality does not integrate the abstract idea into a practical application. See ChargePoint, Inc. v. SemaConnect, Inc., 920 F.3d 759, 768–70 (Fed. Cir. 2019) (use of networked charging equipment did not render an abstract communication and control concept eligible where the claim did not recite an improvement in the charging equipment); Two-Way Media Ltd. v. Comcast Cable Communications, LLC, 874 F.3d 1329, 1337–39 (Fed. Cir. 2017) (result-oriented functional limitations did not provide a specific technological means for achieving the claimed result).
Nor does claim 12 recite an improvement to the functioning of a computer, DLT system, OTA system, vehicle controller, or other technology. The claim does not identify a technological problem and recite a particular claimed solution to that problem. Instead, it applies token-based assignment and acquisition to the field of configurable vehicle functions.
The claim also is not rendered eligible merely because its performance may ultimately affect vehicle equipment. The relevant inquiry is whether the claim recites a particular application of the exception, not whether the abstract process is associated with a physical machine. See ChargePoint, 920 F.3d at 770; MPEP §§ 2106.05(b) and 2106.05(h).
Accordingly, claim 12 does not integrate the abstract idea into a practical application and is directed to the abstract idea under Step 2A.
Step 2B: No significantly more
The additional elements, considered individually and as an ordered combination, do not amount to significantly more than the identified abstract idea.
The DLT system performs its ordinary information-recording and token-assignment functions. The NFT serves as a digital record representing the vehicle-function schema. The requirement data and parameter data constitute the information stored or represented by the NFT. Selecting or acquiring the NFT represents the transaction or entitlement step. The vehicle equipment and its adjustable settings provide the environment in which the acquired configuration is implemented.
The claim does not recite unconventional programming, specialized vehicle-control hardware, an improved data structure that changes computer operation, or a particular technological arrangement for applying the NFT data. Instead, the claim uses computer and vehicle-configuration components as tools to perform the abstract sequence of creating a tokenized configuration, assigning or acquiring the token, and applying the corresponding configuration.
Generic computer implementation, data storage, electronic communication, and execution of instructions do not supply an inventive concept. See Alice, 573 U.S. at 221–24; Electric Power Group, 830 F.3d at 1355–56. Nor does limiting the use of an abstract idea to a particular technological environment amount to significantly more. Alice, 573 U.S. at 222–23.
Considered as an ordered combination, the elements perform the same abstract process in a logical sequence:
create a limited digital representation of a vehicle-function configuration;
assign or acquire the representation;
obtain its requirement and parameter information; and
implement the represented configuration.
The ordered combination does not recite a technological arrangement that operates differently from the individual elements performing their ordinary functions. It therefore does not transform the abstract idea into patent-eligible subject matter.
Accordingly, claim 12 does not recite significantly more than the abstract idea.
Dependent claims 13–20
Claims 13–20 incorporate the limitations of claim 12 and are directed to the same abstract idea. Their additional limitations do not integrate the abstract idea into a practical application or amount to significantly more.
Claim 13
Claim 13 recites that the requirement data includes a special-equipment code, hardware version, or software version. These limitations further define the informational content used to determine whether the vehicle supports the selected configuration. Merely specifying the type or content of information being collected, stored, or evaluated does not provide a practical application or inventive concept. See Electric Power Group, 830 F.3d at 1353–55.
Claims 14 and 15
Claim 14 recites parameters for visually perceptible staging of a vehicle interior, while claim 15 recites parameters for audio or sound playback in or around the vehicle.
These limitations identify the type of vehicle function represented by the NFT and the intended content or result of the configuration. They do not recite a particular lighting controller, display, speaker arrangement, signal-processing operation, or control sequence. Nor do they require a particular physical change beyond the generalized adjustment of unspecified settings inherited from claim 12.
Accordingly, claims 14 and 15 merely limit the abstract token-based configuration scheme to particular types of content or vehicle functions.
Claim 16
Claim 16 recites determining, using the identity of the vehicle, whether the NFT is compatible with the vehicle. This limitation adds a comparison between NFT requirements and vehicle-identification or configuration information. It remains part of the abstract process of determining whether a tokenized configuration may be assigned or applied to a particular vehicle.
The limitation does not recite how compatibility is technically determined, what vehicle components are queried, or how the determination improves the operation or security of the vehicle. It therefore does not provide a practical application or inventive concept.
Claims 17 and 18
Claim 17 recites determining a list of compatible NFTs and offering at least one compatible NFT for selection. Claim 18 recites storing the list in a vehicle head unit.
Filtering available configurations according to compatibility and presenting the resulting selections are information-evaluation and presentation activities that further the token-acquisition process. Storing the list in a vehicle head unit merely places the information in a particular technological environment and uses the head unit as a generic storage device.
Neither claim recites an improvement to the operation of the head unit, the DLT system, or the vehicle.
Claim 19
Claim 19 recites:
assigning equipment features to a vehicle and storing the assignment;
creating a list of minted NFTs;
selecting an NFT from the list; and
determining whether the selected NFT is compatible with the vehicle.
These limitations add record creation, storage, selection, and comparison steps used to administer the same token-based configuration process. The recited configuration-management system is described according to the result it performs and is not limited to a particular technological structure or operation.
Accordingly, claim 19 does not cure the eligibility deficiency of claims 12 and 16.
Claim 20
Claim 20 recites:
generating a first hash value based on requirement data;
generating a second hash value based on parameter data;
creating and locally storing in the vehicle a first list containing the first hash values; and
creating and storing in a distributed cloud a second list containing the second hash values.
Generating hash values constitutes mathematical processing of the requirement and parameter data. Creating lists containing those values and storing the lists in different locations constitute organization and storage of information.
Claim 20 does not recite using either hash value to authenticate an NFT, verify data integrity, detect unauthorized modification, authorize installation, determine compatibility, prevent an unsafe vehicle configuration, or improve computer or network operation. The claim therefore recites the generation and storage of mathematical representations without a particular technological application of those representations.
Performing mathematical operations and storing or presenting their results using generic computing components does not provide eligibility. See SAP America, Inc. v. InvestPic, LLC, 898 F.3d 1161, 1167–70 (Fed. Cir. 2018). Distributing the storage between the vehicle and a cloud does not alter the result because the claim does not recite a particular distributed-storage improvement or explain how the divided storage changes the operation of the vehicle, cloud, or DLT system.
Accordingly, claim 20 does not integrate the judicial exception into a practical application or recite significantly more.
Claim 21
Claim 21 recites an apparatus configured to perform the method of claim 12 and adds “at least one DLT system configured for access via an Over-The-Air (OTA) network.”
Claim 21 is directed to the same abstract idea as claim 12 because it claims an apparatus according to the functions of the ineligible method. Recasting an abstract method as a functionally defined apparatus does not change the eligibility analysis. See Alice, 573 U.S. at 226–27.
The DLT system and OTA network perform generic recordkeeping, access, and communication functions. Claim 21 does not recite a particular OTA protocol, authentication process, transmission structure, vehicle-controller interface, update sequence, fault-recovery process, or technical improvement in OTA or DLT operation. Instead, the OTA network provides the communication environment through which the abstract NFT-based configuration process is performed.
Accordingly, claim 21 does not integrate the abstract idea into a practical application and does not recite significantly more than the abstract idea.
Examiner 101 Conclusion
Claims 12–21 are directed to managing the creation, assignment, acquisition, compatibility, and implementation of vehicle-function configurations through uniquely assigned digital tokens. The claims use DLT, NFT, cloud, head-unit, OTA, and vehicle-configuration components as tools for carrying out that abstract process but do not recite a particular technological mechanism or improvement that meaningfully limits the judicial exception.
Claims 12–21 are therefore ineligible under 35 U.S.C. § 101. This eligibility rejection is based on the claims as a whole and is separate from any questions of novelty, obviousness, written description, enablement, definiteness, or proper dependent-claim form.
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, 15, 16, 17, 18, 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 individually assigning at least one vehicle function schema,
See at least:
“It may be appreciated that while an entitlement may apply to a number of instances of a product, e.g. 1000 autos as in the example described above with reference to FIGS. 11A-B, that each individual auto, i.e. each instance, is tracked.” [0193]
Rationale: Wright expressly teaches individually tracking automobiles and their associated entitlement-controlled configurations. An entitlement defining the authorized configuration of an individual vehicle corresponds to the claimed vehicle function schema.
describing a configuration of at least one vehicle function,
See at least:
“The container mechanism is used to derive configuration data by traversing the associated entitlements and usage over time along a blockchain.” [0194]
“The current configuration may be considered as the entitlements within a container that are in-force, i.e. those that have not expired or been revoked.” [0194]
Rationale: Wright expressly teaches that the entitlement records describe the product’s current configuration, including the functions or features presently authorized for use.
to a vehicle,
See at least:
“For example, the entitlement transaction may include vehicle identification numbers (VINs) for each of the autos covered by each entitlement.” [0193]
Rationale: Wright expressly associates entitlement transactions and their corresponding configurations with identified vehicles through their VINs.
the method comprising:
See at least:
“Each time a lifecycle entitlement event occurs a transaction executes and is stored in ledger 918.” [0152]
Rationale: Wright teaches the subsequently recited operations for creating, recording, acquiring, verifying, and using entitlement-controlled vehicle configurations.
digitally recording and minting the at least one vehicle function schema as a non-fungible token (NFT)
See at least:
“At a minimum, EMS 940 creates a new EUID for the add-on entitlement, specifies the type of transaction being requested, and identifies the EUID of the base entitlement being extended.” [0204]
“Smart contract 916 adds the new, add-on, entitlement block to ledger 918 with an appropriate link to the most recently block in the container.” [0205]
“EMS 940 provides the add-on entitlement to vendor 930 along with an EUID that is used henceforth to reference the entitlement.” [0206]
Rationale: Wright creates an individualized digital entitlement record having a unique EUID and registers that record as an entitlement block in the blockchain ledger. The applicant defines “minting” as the individualization and registration of a digital data record in a DLT system [0008]. Under that express construction, Wright’s uniquely identified and blockchain-registered entitlement record corresponds to the claimed minted NFT. The applicant’s specification is used only to construe the claim.
in a predetermined number
See at least:
“Of the 2000 vehicles, 1000 have a base configuration plus one feature package, referred to as F1, and 1000 vehicles have a base configuration plus a different feature package F2.” [0188]
“It may be appreciated that while an entitlement may apply to a number of instances of a product, e.g. 1000 autos as in the example described above with reference to FIGS. 11A-B, that each individual auto, i.e. each instance, is tracked.” [0193]
“For example, the entitlement transaction may include vehicle identification numbers (VINs) for each of the autos covered by each entitlement.” [0193]
Rationale: Wright expressly teaches establishing a predetermined quantity of 1,000 vehicles for each entitlement-controlled feature configuration and individually tracking every vehicle within that quantity. Wright does not expressly mint 1,000 separate entitlement records. It would nevertheless have been PHOSITA-obvious to instantiate the selected vehicle function schema as a predetermined number of uniquely identified entitlement records corresponding to the predetermined number of authorized vehicle instances. This would preserve Wright’s per-vehicle tracking while permitting the entitlement status and usage of each vehicle instance to be managed independently.
in a distributed ledger technology (DLT) system,
See at least:
“Blockchain 910 is a platform for distributed ledger solutions.” [0136]
“Blockchain fabric 912 provides some or all of the following features: a transaction service 916 that uses smart contracts 916 to implement entitlement transactions and logic, a distributed ledger 918 that may be replicated across many network participants and which stores data for each transaction 918, also referred to as a block.” [0136]
Rationale: Wright expressly creates and stores entitlement records in a replicated blockchain distributed ledger.
wherein the DLT system assigns the NFT to the vehicle
See at least:
“For example, the entitlement transaction may include vehicle identification numbers (VINs) for each of the autos covered by each entitlement.” [0193]
“Further, usage against an entitlement is tracked for each instance.” [0193]
Rationale: Wright expressly records vehicle-identifying VINs in entitlement transactions and tracks entitlement usage for each vehicle instance. When the PHOSITA-obvious separate entitlement record is created for each VIN, recording that relationship in Wright’s blockchain assigns the individualized entitlement record to the corresponding vehicle.
and the NFT is assigned to at most one vehicle,
See at least:
“It may be appreciated that while an entitlement may apply to a number of instances of a product, e.g. 1000 autos as in the example described above with reference to FIGS. 11A-B, that each individual auto, i.e. each instance, is tracked.” [0193]
“Further, usage against an entitlement is tracked for each instance.” [0193]
Rationale: Wright does not expressly restrict one entitlement record to one vehicle; its disclosed entitlement may cover multiple automobiles. It would nevertheless have been PHOSITA-obvious to assign each separately instantiated entitlement record to no more than one VIN to implement Wright’s individual-vehicle tracking at the entitlement-record level. A one-entitlement-to-one-VIN relationship would predictably prevent simultaneous use of the same individualized entitlement by multiple vehicles and permit accurate vehicle-specific activation, usage accounting, transfer, and revocation.
wherein the configuration is described by the assigned vehicle function schema,
See at least:
“The base entitlement of a container typically corresponds to the base configuration element of a product or service.” [0183]
“Additional features, such as a GPS package or music service would be add-on entitlements that are linked to the base entitlement.” [0183]
Rationale: Wright expressly uses base and add-on entitlement records to describe the product’s base configuration and additional functions. The entitlement record therefore functions as the assigned schema describing the vehicle-function configuration.
wherein the parameter data describes settings of the at least one vehicle function schema,
See at least:
“The container mechanism is used to derive configuration data by traversing the associated entitlements and usage over time along a blockchain.” [0194]
“The current configuration may be considered as the entitlements within a container that are in-force, i.e. those that have not expired or been revoked.” [0194]
Rationale: Wright expressly teaches configuration data defining which vehicle functions or features are presently authorized or active. Those configuration values correspond to parameter data describing settings of the entitlement-controlled vehicle function schema. This is consistent with the applicant’s definition of parameter data as data describing settings of the vehicle function schema [0015].
selecting or acquiring at least the NFT for the vehicle;
See at least:
“At step 1202 end-user 960 initiates the transaction to create a requested add-on entitlement.” [0197]
“Or, end-user 960 may wish to purchase additional features or capabilities to add additional rights.” [0197]
“At step 1226 vendor 930 provides the add-on entitlement information, including the EUID, to end-user 960.” [0206]
Rationale: Wright expressly teaches requesting, purchasing, and receiving an add-on entitlement that provides an additional product feature or capability.
Claim Limitations Not Explicitly Taught by Wright
After Wright has been reviewed, the following claim limitations remain not explicitly taught:
wherein the NFT encodes technical requirements required to implement a configuration of the at least one vehicle function,
wherein the NFT comprises requirement data and parameter data,
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.
and applying, based on the selected or acquired NFT, the assigned vehicle function schema to the vehicle
by adjusting settings of the equipment features of the vehicle according to the parameter data.
Examiner Note: Wright teaches configuration prerequisites:
“However, in this example, configuration rules require that feature package F2 must be present before F3 can be added.” [0190]
“For F3 to be entitled there may be a technical requirement that F2 is necessary or it make be a market-based decision.” [0191]
“Further, a container may be used to enforce a set of configuration rules, such as the rule from the previous example, described with reference to FIGS. 11A-B, that feature F3 can only be added if feature F1 is already present.” [0195]
Wright therefore recognizes technical and configuration prerequisites. Wright does not, however, clearly establish that its vehicle entitlement record encodes data describing the particular vehicle hardware, software, actuators, sensors, or control devices required to implement the configured function. Wright also does not expressly apply the selected entitlement by adjusting those vehicle-equipment settings. Kreuz supplies these remaining technical implementation teachings.
Disclosure by Kreuz
Kreuz teaches:
wherein the NFT encodes technical requirements required to implement a configuration of the at least one vehicle function,
See at least:
“These rules and conditions may, for example, comprise technical restrictions used to ensure compatibility among specific control devices or strategic marketing restrictions.” (col. 5, lines 1–9)
“The selection of the hardware or control devices required to realize the desired function and the selection and combination of the required software modules are made automatically.” (col. 5, lines 28–39)
Rationale: Kreuz expressly teaches technical restrictions and configuration data identifying the hardware, control devices, and software modules required to realize a desired vehicle function. Incorporating Kreuz’s technical requirements in Wright’s uniquely identified entitlement record renders obvious an NFT encoding the technical requirements needed to implement the associated configuration.
wherein the NFT comprises requirement data and parameter data,
See at least:
“Thus, the actual configuration data describe all electrical and electronic hardware and software components of the respective vehicle, including their component relationships.” (col. 6, lines 35–39)
“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 55–61)
Rationale: Kreuz expressly teaches vehicle-configuration data identifying the hardware and software components needed to execute a function and information defining the function’s implementation. Incorporating those data in Wright’s entitlement record provides requirement data identifying necessary equipment and parameter data defining the authorized function configuration.
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.
See at least:
“The selection of the hardware or control devices required to realize the desired function and the selection and combination of the required software modules are made automatically.” (col. 5, lines 28–39)
“In addition to internal details and the implemented software, the 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, lines 43–50)
Rationale: Kreuz expressly identifies control devices, actuators, sensors, connections, software modules, and computing resources required to realize a desired vehicle function. These vehicle-equipment characteristics correspond directly to requirement data describing the equipment features needed to implement the function according to its configuration parameters.
and applying, based on the selected or acquired NFT, the assigned vehicle function schema to the vehicle
See at least:
“Using the approved configurations Ca, the optimally appointed configuration co corresponding to a requested and ordered vehicle is now determined on the sales end, based on the customer’s needs, using computer-assisted automatic configuration.” (col. 5, lines 15–24)
“In production, the actual configuration ci of the vehicle electrical system is derived from the ordered configuration co during the assembly of the vehicle from individual components.” (col. 5, lines 24–29)
Rationale: Kreuz expressly applies a requested and ordered vehicle configuration to the corresponding vehicle through computer-assisted automatic configuration and implementation of the resulting actual configuration. In the combined system, Wright’s selected or acquired entitlement supplies the requested configuration applied through Kreuz’s configuration process.
by adjusting settings of the equipment features of the vehicle according to the parameter data.
See at least:
“To this end, in particular, the appropriate hardware components, i.e., primarily the various control devices, are selected and the necessary hardware is implemented, for which the required software modules are suitably combined during configuration and are preferably transferred to the vehicle by means of flash software.” (col. 5, lines 28–39)
Rationale: Kreuz expressly implements the selected configuration by selecting the appropriate control devices, combining the required software modules, and transferring the configured software to the vehicle through flash programming. This teaches adjusting the operative configuration of the vehicle equipment according to the selected configuration 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 encode Kreuz’s vehicle-specific hardware, software, actuator, sensor, and control-device requirements together with the corresponding function-configuration data in Wright’s uniquely identified blockchain entitlement record, verify that the identified vehicle possesses the required equipment, and apply the acquired entitlement by configuring the vehicle equipment according to the entitlement data. Wright teaches creating, purchasing, recording, and assigning blockchain-managed vehicle-feature entitlements to individually identified automobiles. Kreuz teaches identifying the vehicle equipment required to realize a desired function and automatically implementing the selected configuration through control-device selection, software-module combination, and flash transfer. Combining these complementary teachings would have predictably prevented activation of functions on vehicles lacking the necessary equipment and enabled the authorized function to be implemented reliably using the vehicle’s installed hardware and software.
As to the predetermined number and one-vehicle assignment, it would have been obvious to instantiate the selected vehicle function schema as a predetermined number of uniquely identified blockchain entitlement records corresponding to the predetermined number of authorized vehicle instances and associate each record with no more than one VIN. Wright expressly teaches predetermined quantities of vehicles having particular feature configurations and separately tracking each vehicle and its entitlement usage. Creating one uniquely identified entitlement record per tracked VIN would have been a predictable implementation of Wright’s per-instance tracking, providing vehicle-specific activation, usage accounting, transfer, and revocation while preventing the same individualized entitlement record from being exercised by multiple vehicles.
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 teaches:
wherein the requirement data comprises a special equipment code, a hardware version, or a software version
See at least:
“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.... The tag may also contain a reference to entitlements that specify rights to use the component in some fashion.” [0032]
“[I]f an Entitlement is to be associated with an item of hardware with a specific identifier such as IP address or hardware serial number, this would be defined in the Create Entitlement command ... along with a unique identifier for the item of hardware in the data field.” [0165]
Rationale:
Wright teaches storing a version attribute for an entitlement-associated software component and a unique identifier for hardware associated with an entitlement. Wright therefore teaches version and equipment-identification information generally. Wright does not, however, expressly identify the version as requirement data describing a vehicle equipment feature required to implement the vehicle-function schema.
Claim Limitation Not Explicitly Taught by Wright
After Wright has been exhausted, Wright does not explicitly teach the complete limitation:
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:
wherein the requirement data comprises a special equipment code, a hardware version, or a software version
See at least:
Figure 8 identifies requested vehicle equipment or functions using numerical codes, including “551 Burglary and Theft W.,” “472 Electronic Stabilities,” “873 Front Seat Heating System,” “581 Automatic Climate Control,” and “404 Multi-Contour Seat, Left.” (Figure 8)
“Different versions of hardware and/or software components are often developed during the life of the vehicle....” (col. 12, lines 31–34)
Rationale:
The applicant explains that requirement data may comprise an optional equipment code, also identified as an SA code, a hardware version, or a software version of an equipment feature [0018]. The applicant further explains that an SA code identifies a specific optional vehicle equipment feature and that requirement data may identify the hardware or software development stage of a vehicle subsystem [0043].
Kreuz Figure 8 expressly identifies requested vehicle equipment features using numerical equipment codes. Kreuz additionally teaches different hardware and software component versions. Because Claim 13 is disjunctive, disclosure of any one of the recited alternatives is sufficient. Kreuz’s equipment codes and component-version information correspond to the alternatives described by the applicant in [0018] and [0043].
of at least one of the equipment features.
See at least:
“Permissible hardware and software modules for each control device type are selected and/or newly defined.... For every individual control device with its corresponding software, the suitable references to corresponding documentation types are stored.” (col. 9, lines 12–21)
“[D]ifferent versions of hardware and/or software components are often developed during the life of the vehicle....” (col. 12, lines 31–34)
Rationale:
Kreuz expressly ties the numerical codes to particular vehicle equipment or functions and ties hardware and software versions to vehicle control devices and software modules. Kreuz therefore teaches that the recited code or version identifies at least one equipment feature.
Motivation to Combine Wright and Kreuz for Claim 13
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 include Kreuz’s vehicle equipment codes and hardware or software version information in the requirement data associated with Wright’s blockchain vehicle-feature entitlement.
Wright teaches verifying whether a selected entitlement-defined feature is acceptable based on configuration information and teaches storing version and hardware-identification information in entitlement-associated records. Kreuz teaches identifying vehicle equipment through numerical equipment codes and tracking the hardware and software versions of vehicle control devices.
A PHOSITA would have used Kreuz’s equipment codes and component-version information to determine whether the particular vehicle contains the equipment and development version required to support Wright’s selected entitlement-defined feature. Doing so would have predictably improved compatibility screening, prevented installation of unsupported configurations, and facilitated reliable automatic vehicle reconfiguration.
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 teaches relevant entitlement-controlled audio subject matter. See at least:
“Additional features, such as a GPS package or music service would be add-on entitlements that are linked to the base entitlement.” [0183]
Rationale: Wright expressly identifies a music service as an add-on entitlement linked to the base configuration of an automobile. Wright therefore teaches using its blockchain entitlement system to authorize a vehicle-related audio service. Wright does not expressly teach that the associated schema records technical settings controlling how the audio is played.
Claim Limitations Not Explicitly Taught by Wright
After Wright has been reviewed, the following claim limitation remains not explicitly taught:
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 records parameters of audio or sound playback in an interior or in surroundings of the vehicle.
See at least:
“Examples of what is displayed include an electro-hydraulic brake EHB on 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, lines 1–10)
“The selection of the hardware or control devices required to realize the desired function and the selection and combination of the required software modules are made automatically.” (col. 5, lines 28–39)
Rationale: Kreuz expressly identifies a radio and CD player as configurable vehicle components and teaches selecting the hardware and software needed to realize a desired function. In view of Wright’s add-on music-service entitlement, it would have been obvious to record conventional playback settings—such as source, volume, balance, speaker selection, or sound profile—as part of the configuration used to operate Kreuz’s interior audio equipment. The applicant defines a vehicle function schema as a configuration or set of parameters or functional settings of a vehicle function [0012]. Because the claim recites playback “in an interior or in surroundings,” teaching interior playback satisfies the alternative 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 include conventional audio-playback settings in the configuration associated with Wright’s add-on music-service entitlement and apply those settings to Kreuz’s configurable vehicle radio or CD-player equipment. Wright expressly identifies a music service as an add-on vehicle entitlement, while Kreuz teaches selecting the hardware and software required to realize a vehicle function and expressly identifies interior audio-reproduction equipment. Recording the applicable playback settings with the authorized music-service configuration would have predictably enabled the selected audio function to be reproduced consistently through the vehicle’s interior audio system.
After Wright and Kreuz have been reviewed, all limitations of Claim 15 are taught or rendered obvious.
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 a minimum, EMS 940 creates a new EUID for the add-on entitlement, specifies the type of transaction being requested, and identifies the EUID of the base entitlement being extended.” [0203]
“Smart contract 916 adds the new, add-on, entitlement block to ledger 918 with an appropriate link to the most recently block in the container.” [0205]
Rationale: Wright creates a uniquely identified entitlement data record and registers that record as an entitlement block in the blockchain ledger. The applicant defines “minting” as the individualization and registration of a digital data record in a DLT system [0008] and explains that NFTs are minted and managed in the DLT system [0009]. Under that construction, Wright’s EUID-identified entitlement block is a registered NFT. The applicant’s specification is used only to construe the claim.
the method further comprising:
See at least:
“At step 1210 EMS 940 submits the configuration information to vendor 930 for verification.” [0199]
Rationale: Wright performs an additional configuration-verification operation before the requested add-on entitlement is created and provided.
determining, using an identity of the vehicle, a compatibility of the NFT with the vehicle.
See at least:
“It may be appreciated that while an entitlement may apply to a number of instances of a product, e.g. 1000 autos as in the example described above with reference to FIGS. 11A-B, that each individual auto, i.e. each instance, is tracked.” [0193]
“For example, the entitlement transaction may include vehicle identification numbers (VINs) for each of the autos covered by each entitlement.” [0193]
“At step 1212 vendor 930 verifies that the new configuration being requested is acceptable, i.e. vendor 930 determines that the configuration policy, or rules, allows end-user 960 to purchase the requested add-on entitlement given the entitlements currently in-force.” [0200]
Rationale: Wright expressly identifies individual vehicles through their VINs and determines whether a requested add-on entitlement is acceptable in view of the vehicle’s existing entitlement configuration. Wright therefore teaches vehicle-identity-based entitlement compatibility. Wright does not expressly determine whether the identified vehicle possesses the specific hardware and software required to implement the add-on function.
Claim Limitations Not Explicitly Taught by Wright
After Wright has been reviewed, the following aspect of the claim limitation remains not explicitly taught:
determining, using an identity of the vehicle, a compatibility of the NFT with the vehicle, to the extent “compatibility” requires determining whether the identified vehicle possesses the hardware and software equipment needed to implement the NFT-associated vehicle function schema.
Disclosure by Kreuz
Kreuz teaches the remaining technical-compatibility aspect of:
determining, using an identity of the vehicle, a compatibility of the NFT with the vehicle.
See at least:
“These rules and conditions may, for example, comprise technical restrictions used to ensure compatibility among specific control devices or strategic marketing restrictions.” (col. 5, lines 1–9)
“As is evident in the figure, the actual configuration data in this case comprise vehicle identification information, information about the owner of the vehicle, information on technical specifications, such as power, vehicle dimensions, etc., which are useful in the event of resale, maintenance-related data, such as the most recent oil change, as well as data relating to the actual vehicle electrical system, such as data on existing data buses and existing hardware and software components.” (col. 7, lines 35–46)
Rationale: Kreuz expressly stores vehicle-identification information together with the vehicle’s existing hardware and software components and applies technical restrictions to ensure compatibility among the components. Applying Kreuz’s technical-compatibility assessment to Wright’s requested entitlement determines whether the entitlement-controlled function is implementable by the identified vehicle. This corresponds to the applicant’s description of compatibility as implementability using the vehicle’s hardware and software [0020].
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 use the VIN of the individual vehicle in Wright’s entitlement transaction to retrieve the corresponding vehicle-specific configuration information taught by Kreuz and compare the vehicle’s existing hardware and software with the technical requirements of the requested add-on entitlement before providing or activating the associated function. Wright already teaches VIN-based tracking and verification of requested vehicle add-on entitlements, while Kreuz teaches maintaining vehicle-specific hardware and software information and applying technical compatibility restrictions. The combination would have predictably prevented activation of a function on a vehicle lacking the equipment needed to implement it, thereby improving configuration reliability and avoiding incompatible installations.
After Wright and Kreuz have been reviewed, all limitations of Claim 16 are taught or rendered obvious.
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:
determining a selection list of NFTs
See at least:
“The configuration information includes information about the base entitlement and any add-on and renewal entitlements linked to the base entitlement as well as information about the add-on entitlement that end-user 960 has requested to purchase.” [0199]
“At step 1212 vendor 930 verifies that the new configuration being requested is acceptable, i.e. vendor 930 determines that the configuration policy, or rules, allows end-user 960 to purchase the requested add-on entitlement given the entitlements currently in-force.” [0200]
Rationale: Wright expressly retrieves multiple base, add-on, and renewal entitlement records and evaluates whether a requested add-on entitlement is acceptable. Wright does not expressly call the acceptable results a selection list. Applying the disclosed verification to available add-on entitlements and collecting the acceptable results into a list would have been a predictable filtering operation that facilitates presentation and selection of available entitlements.
and offering the vehicle at least one NFT in the selection list of NFTs for selection.
See at least:
“Typically, the response is either that the proposed add-on purchase is acceptable or not. In certain embodiments, vendor 930 may propose a modified add-on entitlement that it deems to be acceptable.” [0202]
“Finally, at step 1226 vendor 930 provides the add-on entitlement information, including the EUID, to end-user 960.” [0206]
Rationale: Wright expressly proposes an acceptable add-on entitlement and provides the entitlement information, including its unique EUID, to the end user. Once the acceptable entitlement records are collected into the PHOSITA-obvious selection list, proposing and providing at least one listed entitlement for user selection is the predictable implementation of Wright’s disclosed purchase process.
Claim Limitations Not Explicitly Taught by Wright
After Wright has been reviewed, the following claim limitation remains not explicitly taught:
compatible with the vehicle;
Examiner Note: Wright determines whether an add-on entitlement is acceptable under the applicable entitlement or configuration policy, but does not expressly determine whether the particular vehicle possesses the hardware and software equipment required to implement the entitlement-controlled function.
Disclosure by Kreuz
Kreuz teaches:
compatible with the vehicle;
See at least:
“These rules and conditions may, for example, comprise technical restrictions used to ensure compatibility among specific control devices or strategic marketing restrictions.” (col. 5, lines 1–9)
“The selection of the hardware or control devices required to realize the desired function and the selection and combination of the required software modules are made automatically.” (col. 5, lines 28–39)
“Thus, the actual configuration data describe all electrical and electronic hardware and software components of the respective vehicle, including their component relationships.” (col. 6, lines 35–39)
Rationale: Kreuz expressly maintains the particular vehicle’s hardware and software configuration, identifies the equipment required to realize a desired function, and applies technical restrictions to ensure compatibility. Applying Kreuz’s vehicle-specific criteria when Wright evaluates the available entitlement records limits the resulting selection list to NFTs whose associated functions are technically implementable by 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 evaluate Wright’s available add-on entitlements using Kreuz’s vehicle-specific hardware, software, and technical-compatibility information, collect the acceptable entitlements into a selection list, and offer at least one listed entitlement for selection. Wright teaches retrieving and verifying multiple entitlement records, proposing an acceptable entitlement, and providing its uniquely identified information to the end user. Kreuz teaches determining whether the particular vehicle possesses the equipment required to realize the desired function. Combining these complementary teachings would have predictably prevented incompatible functions from being offered or activated and improved the reliability and efficiency of the entitlement-selection process.
Regarding Claim 18,
The combination of Wright and Kreuz establishes the method of claim 17, which is the basis for claim 18.
Disclosure by Wright
Wright teaches relevant storage and communication of entitlement information. See at least:
“EMS 940 initiates a transaction with blockchain 910 to request information about the base entitlement and any linked add-on entitlements.” [0199]
“Blockchain 910 returns the requested entitlement information.” [0199]
“Finally, at step 1226 vendor 930 provides the add-on entitlement information, including the EUID, to end-user 960.” [0206]
Rationale: Wright retrieves entitlement information from the blockchain and provides the entitlement information to the end user. Wright does not expressly teach storing the resulting compatible-entitlement selection list in a vehicle head unit.
Claim Limitations Not Explicitly Taught by Wright
After Wright has been reviewed, the following claim limitation remains not explicitly taught:
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:
“As depicted in FIG. 2, in addition to the remaining hardware components ECU1, ECU2, . . . , the onboard actual configuration is achieved with an additional central control device CECU, which contains a flash memory component or an additional electronic memory, which functions as the actual configuration data memory ECO where the exact actual configuration is stored or, more precisely, where the minimum data required to determine the actual configuration is stored.” (col. 3, lines 15–24)
“The additional central control device CECU functions as a gateway between the vehicle and the environment outside the vehicle.” (col. 3, lines 25–28)
“Thus, with the external system 1 the actual configuration data stored in the actual configuration data memory ECO of the gateway control device CECU can be accessed and, using a suitable browser, displayed in the desired form.” (col. 3, lines 35–40)
Rationale: Kreuz expressly stores vehicle-configuration data in flash or other electronic memory of an onboard central control device and permits the stored data to be accessed and displayed. Kreuz does not expressly call the CECU a “head unit” or expressly store a compatible-NFT selection list. Nevertheless, storing Wright’s compatible-entitlement list in a vehicle head unit would have been an obvious implementation of Kreuz’s onboard storage and display teachings. The applicant defines a head unit as a central vehicle control unit having a user interface and controlling vehicle functions [0021]. Storing the list at that location would predictably support local presentation and selection of compatible vehicle functions. The applicant’s specification is used only to construe “head unit.”
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 store the compatible-entitlement selection list resulting from the method of claim 17 in the memory of Kreuz’s onboard central control device, implemented in or operatively associated with a vehicle head unit. Wright teaches retrieving entitlement information from the blockchain and providing that information to the end user, while Kreuz teaches locally storing vehicle-configuration data in an onboard central controller and displaying the stored data through a browser. Local storage of the compatible selections in the vehicle head unit would have predictably facilitated presentation and selection of available functions, reduced repeated network retrieval, and maintained correspondence between the offered functions and the vehicle’s current configuration.
After Wright and Kreuz have been reviewed, all limitations of Claim 18 are taught or rendered obvious.
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:
“FIGS. 11A-B illustrate an example embodiment of the use of containers for representing the association of entitlements.” [0188]
Rationale:
Wright teaches additional entitlement-listing, selection, association, and configuration-verification operations.
assigning, by a configuration management system, equipment features assigned to a vehicle
See at least:
“Container A 1100 includes the initial two entitlements, EUID 1-2, for the base vehicle and feature F1. Container B 1105 includes the two entitlements, EUID 3-4, that cover the second group of 1000 vehicles.” [0188]
“EMS 940 manages entitlements that are sold or otherwise provided [to] end-user 960 by vendor infrastructure 930.” [0140]
Rationale:
Wright’s entitlement-management service and blockchain containers associate feature packages F1 and F2 with the corresponding base vehicles. Wright therefore teaches maintaining assignments between vehicles and entitlement-defined equipment or functional features. Wright does not, however, expressly store the vehicle’s complete actual hardware and software equipment configuration in the entitlement-management system.
and storing the assignment;
See at least:
“[D]istributed ledger 918 ... stores data for each transaction.... Thus, ledger 918 maintains a history of all transactions.” [0136]
“The current configuration may be considered as the entitlements within a container that are in-force.... Since blockchain 910 immutably tracks all transactions configuration and status information can be determined for any particular instance.” [0194]
Rationale:
Wright stores the entitlement transactions associating the vehicle with its feature entitlements in the distributed ledger. The stored records preserve the entitlement-level feature assignment. Wright does not expressly store the complete actual vehicle-equipment assignment required for technical compatibility analysis.
creating a list of all NFTs minted in the DLT system;
See at least:
“Blockchain—as used herein means a continuously growing list of records, called blocks, which are linked and secured using cryptography.” [0042]
“[D]istributed ledger 918 ... stores data for each transaction.... Thus, ledger 918 maintains a history of all transactions.” [0136]
“Entitlements are referenced using an entitlement unique identifier (EUID).” [0151]
Rationale:
The applicant explains that a list of all NFTs registered in the DLT system is created and that at least one NFT is selected from that list for compatibility evaluation [0024]. Wright’s distributed ledger stores the complete history of entitlement transactions, identifies every created entitlement by a unique EUID, and distinguishes create-entitlement transactions from other transaction types.
Wright does not expressly generate a separate entitlement-only list containing every created entitlement. It would nevertheless have been obvious to a PHOSITA to query ledger 918 for its create-entitlement transaction type and enumerate the corresponding EUIDs. Such a query would have been a routine use of Wright’s stored transaction types and unique identifiers and would have predictably produced the entitlement population needed for selection and compatibility evaluation.
selecting at least one NFT from the list of all NFTs;
See at least:
“At step 1210 EMS 940 submits the configuration information to vendor 930 for verification. The configuration information includes ... information about the add-on entitlement that end-user 960 has requested to purchase.” [0199]
“[T]here is a question as to whether F3 should be added to the thousand units of Container A 1100 or the thousand units of Container B 1105.... Thus, F3 must be added ... to the vehicles covered by the entitlements of Container B 1105.” [0190]
Rationale:
Wright teaches selecting a requested add-on entitlement for configuration evaluation and determining the vehicle-entitlement container to which it may be added. Selecting the entitlement identified by its EUID from the ledger-derived entitlement population would have been the ordinary operation required to retrieve its data and initiate the disclosed verification process.
and determining, by the configuration management system for the at least one selected NFT,
See at least:
“At step 1210 EMS 940 submits the configuration information to vendor 930 for verification. The configuration information includes information about the base entitlement and any add-on and renewal entitlements linked to the base entitlement as well as information about the add-on entitlement that end-user 960 has requested to purchase.” [0199]
Rationale:
Wright teaches using entitlement-management service 940 and the vendor’s configuration-verification functionality to evaluate the selected entitlement against the existing entitlement-defined configuration. Wright therefore teaches performing an entitlement-level determination for the selected NFT.
a compatibility with the vehicle.
See at least:
“At step 1212 vendor 930 verifies that the new configuration being requested is acceptable, i.e. vendor 930 determines that the configuration policy, or rules, allows end-user 960 to purchase the requested add-on entitlement given the entitlements currently in-force.” [0200]
Rationale:
Wright teaches entitlement-level compatibility based on the vehicle’s existing feature entitlements and applicable configuration rules. Wright does not expressly determine compatibility using the vehicle’s complete actual hardware and software equipment assignment.
Claim Limitations Not Explicitly Taught by Wright
After Wright has been exhausted, Wright does not explicitly teach the complete technical scope of:
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, by a configuration management system, equipment features assigned to a vehicle
See at least:
“[T]he actual configuration data ... comprise vehicle identification information ... as well as data relating to the actual vehicle electrical system, such as data on existing data buses and existing hardware and software components.” (col. 7, lines 35–46)
Rationale:
Kreuz’s vehicle configuration-management system associates the identified vehicle with its installed data buses, hardware components, software components, actuators, sensors, and other equipment features. Kreuz therefore teaches assigning equipment features to a vehicle in a configuration-management system.
and storing the assignment;
See at least:
“The configuration system ... contains a central actual configuration data memory arranged in the vehicle. The actual configuration data set that characterizes the actual configuration is centrally filed therein....” (col. 2, lines 35–43)
Rationale:
Kreuz expressly stores the vehicle’s actual equipment assignment in the central actual-configuration memory.
and determining, by the configuration management system for the at least one selected NFT,
See at least:
“When the vehicle configuration system component is activated, the system triggers an essentially or entirely automatic configuration of an optimal vehicle electrical system ... on the basis of relevant target specifications....” (col. 3, lines 26–39)
Rationale:
Kreuz’s configuration-management system evaluates a selected target configuration against the stored vehicle topology, hardware, and software information. In the proposed combination, Wright’s selected entitlement NFT supplies the target vehicle-function configuration evaluated by Kreuz’s system.
a compatibility 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, lines 49–52)
Rationale:
Kreuz expressly determines technical compatibility using the vehicle’s stored hardware and software configuration. Applied to Wright’s selected entitlement NFT, the configuration-management system determines whether the NFT-defined vehicle-function schema can be implemented with the vehicle’s actual equipment.
Motivation to Combine Wright and Kreuz for Claim 19
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 query Wright’s complete blockchain transaction history to create a list of the uniquely identified entitlement NFTs registered in the DLT system, select a requested entitlement from that list, and use Kreuz’s configuration-management system and stored vehicle-equipment assignment to determine whether the selected entitlement-defined configuration is compatible with the vehicle.
Wright teaches a distributed ledger containing the complete history of entitlement transactions, unique EUIDs identifying created entitlements, selection of an add-on entitlement, and verification of requested configurations. Kreuz teaches storing the hardware and software equipment assigned to an identified vehicle and assessing the technical compatibility of a proposed configuration with that equipment.
A PHOSITA would have been motivated to generate an entitlement-only list from Wright’s ledger because the ledger already distinguishes entitlement-creation transactions and assigns a unique EUID to each entitlement. The list would permit efficient searching and selection of available feature entitlements. Applying Kreuz’s compatibility process to the selected entitlement would have predictably prevented purchase or activation of vehicle functions that could not be implemented with the vehicle’s installed equipment and would have improved automation, accuracy, and usability.
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 discloses:
the apparatus comprising:
See at least:
“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:
Wright expressly identifies the components comprising its entitlement-management apparatus.
at least one DLT system
See at least:
“Blockchain 910 is a platform for distributed ledger solutions.... [D]istributed ledger 918 ... may be replicated across many network participants and ... stores data for each transaction....” [0136]
Rationale:
Wright’s blockchain 910 and distributed ledger 918 expressly constitute at least one DLT system.
configured for access via an Over-The-Air (OTA) network.
See at least:
“Wireless network 822 may include any of a variety of wireless networks that provide a connection for client devices 802-4. Such networks may include the wireless Internet, mesh networks, wireless LAN (WLAN) networks, cellular networks, or the like.” [0122]
“Generally, it is assumed that vendor infrastructure 930, EMS 940, entitled product 950, and end-user 960 refer to computer systems that exchange data messages and are inter-connected on the same business network.... The network may be the public Internet, a private network or other network.” [0145]
Rationale:
Wright expressly discloses accessing and exchanging entitlement-management data through wireless Internet, WLAN, mesh, and cellular networks. In Wright’s automobile implementation, accessing blockchain 910 from the vehicle or vehicle-associated computing equipment through the disclosed wireless or cellular network constitutes OTA access.
Motivation to Combine Wright and Kreuz for Claim 21
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 Wright’s blockchain entitlement-management apparatus for OTA access through Wright’s disclosed cellular or wireless Internet network and to use the apparatus with Kreuz’s onboard vehicle-configuration memory and external-system gateway to implement the entitlement-defined vehicle configuration.
Wright teaches a distributed-ledger entitlement system, wireless and cellular communication networks, vehicle-feature entitlements, and network communication of entitlement and activation information. Kreuz teaches an onboard actual-configuration memory, a vehicle control device functioning as a gateway between the vehicle electrical system and an external system, and transfer of software modules to configure the vehicle.
A PHOSITA would have recognized that Wright’s wireless network provides a technically compatible communication path between the remote DLT infrastructure and Kreuz’s onboard configuration gateway. The combination would have predictably permitted remote entitlement verification, feature activation, and delivery of configuration information without requiring a wired service connection, thereby improving the efficiency and availability of vehicle-function deployment.
Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over Wright, in view of Kreuz, 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.
Claim Limitations Not Explicitly Taught by Wright
After Wright has been reviewed, the following claim limitation remains not explicitly taught:
wherein the vehicle function schema records parameters of visually perceptible staging of a vehicle interior of the vehicle.
Examiner Note: Wright teaches entitlement-controlled vehicle configurations and add-on functions, but does not expressly teach parameters defining visually perceptible staging of a vehicle interior.
Disclosure by Kreuz
Kreuz teaches relevant vehicle-interior configuration subject matter. See at least:
“Examples of what is displayed include an electro-hydraulic brake EHB on 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, lines 1–10)
Rationale: Kreuz expressly teaches that the vehicle configuration encompasses components located in and associated with the vehicle interior. Kreuz does not, however, teach a visually perceptible sequence of interior-lighting stages or parameters defining such staging.
Claim Limitations Not Explicitly Taught by the Combination of Wright and Kreuz
After Wright and Kreuz have been reviewed, the following claim limitation remains not explicitly taught:
wherein the vehicle function schema records parameters of visually perceptible staging of a vehicle interior of the vehicle.
Disclosure by Prodin
Prodin teaches:
wherein the vehicle function schema records parameters of visually perceptible staging of a vehicle interior of the vehicle.
See at least:
“In Welcome Stage 1, all or some subsets of the lights in at least one of the pre-determined zones are illuminated at a reduced or partial intensity to facilitate entry of a driver and/or passengers into the vehicle.” [0022]
“For example, in a possible embodiment, Welcome Stage 1 includes illumination at one-half intensity of all lights included in zones 1 and 3, the lights of zone 2 remaining off.” [0022]
“Welcome Stage 2 lighting may, for example, comprise full intensity illumination of all lights in all interior lighting zones.” [0023]
Rationale: Prodin expressly defines successive vehicle-interior lighting stages by selected lighting zones and different illumination intensities. The zone selections, intensity values, and progression between Welcome Stage 1 and Welcome Stage 2 are parameters defining visually perceptible staging of the vehicle interior. This is consistent with the applicant’s definition of a vehicle function schema as a configuration or set of parameters or functional settings of a vehicle function [0012]. The applicant’s specification is used only to construe the claim.
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 lighting-stage parameters into the entitlement-controlled vehicle-function configuration taught by Wright and implement that configuration through the vehicle-configuration architecture taught by Kreuz. Wright teaches managing and providing add-on vehicle functions through blockchain-recorded entitlements; Kreuz teaches configuring vehicle-interior hardware and software components; and Prodin teaches a known vehicle-interior function defined by successive lighting stages, selected lighting zones, and different intensities. The modification would have been the predictable use of Prodin’s known interior-lighting configuration in Wright and Kreuz’s configurable vehicle system, enabling consistent application of the authorized lighting sequence to compatible vehicle equipment.
After Wright, Kreuz, and Prodin have been reviewed, all limitations of Claim 14 are taught or rendered obvious.
Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over Wright, in view of Kreuz, and in view of Schaaf (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:
“A container includes all linked entitlement and usage blocks.” [0182]
Rationale: Wright teaches additional data-management operations performed on the linked entitlement records underlying the NFT list established in Claim 19.
wherein the parameter data describes the settings of the vehicle function schema,
See at least:
“The container mechanism is used to derive configuration data by traversing the associated entitlements and usage over time along a blockchain.” [0194]
“The current configuration may be considered as the entitlements within a container that are in-force, i.e. those that have not expired or been revoked.” [0194]
Rationale: Wright expressly teaches that the in-force entitlement records define the product’s current configuration. The configuration data therefore describe the operative settings or enabled features of the vehicle function. This construction is consistent with the applicant’s definition of parameter data [0015].
Claim Limitations Not Explicitly Taught by Wright
After Wright has been reviewed, the following claim limitations remain not explicitly taught:
assigning each NFT of the list of NFTs 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;
and creating and storing in a cloud a second list
comprising the second hash values
is created and distributed
and is stored in a cloud in a distributed manner,
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:
“As depicted in FIG. 2, in addition to the remaining hardware components ECU1, ECU2, . . . , the onboard actual configuration is achieved with an additional central control device CECU, which contains a flash memory component or an additional electronic memory, which functions as the actual configuration data memory ECO where the exact actual configuration is stored or, more precisely, where the minimum data required to determine the actual configuration is stored.” (col. 6, lines 25–35)
“In this system, documents are stored hierarchically and are machine-readable. Thus, for example, tree structures can be stored and their contents interpreted by computers.” (col. 7, lines 15–21)
“As depicted in FIG. 3, based on the example of a vehicle with a specific identification number ‘12345,’ the file’s structural and/or grammatical information is defined, together with the actual configuration data stored in XML format, in a DTD (Document Type Definition) file, which is stored in the vehicle together with the XML file.” (col. 7, lines 22–29)
Rationale: Kreuz expressly creates a hierarchical, machine-readable vehicle-configuration data structure and stores it locally in onboard vehicle memory. The hierarchical XML or tree structure is capable of storing the entries constituting the claimed first list. Kreuz does not teach that those entries are content-derived hash values.
and wherein the requirement data describes the equipment features of the vehicle required for implementing the vehicle function schema according to the parameter data.
See at least:
“The selection of the hardware or control devices required to realize the desired function and the selection and combination of the required software modules are made automatically.” (col. 5, lines 28–39)
“In addition to internal details and the implemented software, the 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, lines 43–50)
Rationale: Kreuz expressly teaches configuration data describing the control devices, actuators, sensors, connections, software modules, and computing resources required to realize a desired vehicle function. These data correspond directly to the claimed equipment-feature requirement 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 maintain the vehicle-equipment requirement information associated with Wright’s entitlement-controlled functions in Kreuz’s onboard hierarchical configuration structure. Wright teaches using linked entitlement records to represent vehicle-feature configurations, while Kreuz teaches locally storing the particular vehicle’s actual hardware and software configuration in a machine-readable structure. The combination would have predictably allowed the vehicle to compare the requirements of each entitlement-controlled function against its actual installed equipment without requiring continuous access to the remote ledger.
Claim Limitations Not Explicitly Taught by the Combination of Wright and Kreuz
After Wright and Kreuz have been reviewed, the following claim limitations remain not explicitly taught:
assigning each NFT of the list of NFTs 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;
and creating and storing in a cloud a second list
comprising the second hash values
is created and distributed
and is stored in a cloud in a distributed manner,
Disclosure by Schaaf
Schaaf teaches or renders obvious:
assigning each NFT of the list of NFTs a first hash value
See at least:
“The method also comprises generating a hash value based on the first information, the second information and software content of the one or more software components, and providing the hash value as an ID for the equipped status (with regard to hardware and software) of the vehicle.” [0019]
Rationale: Schaaf expressly generates a content-derived hash value representing vehicle hardware and software information. Applying Schaaf’s disclosed hash-generation operation to each uniquely identified NFT record in Wright’s list would predictably assign each NFT a corresponding first hash. This mapping does not rely on Wright’s blockchain hash pointer.
based on requirement data
See at least:
“The method comprises determining a first information on one or more available software components and their software versions and determining a second information on one or more available hardware components and their hardware versions.” [0019]
“By additionally using the hardware information, for example IDs of the electronic control units, the hardware may also be verified, and an exchange of the hardware but with the same software may also be recognized.” [0019]
Rationale: Schaaf expressly calculates its equipped-status hash using hardware components, hardware versions, software components, software versions, and ECU identifiers. Those data correspond to the equipment requirements identified by Kreuz. Hashing those data produces the first hash based on requirement data.
and a second hash value
See at least:
“In doing so, a plurality of information that are available as hash may be combined so that the individual components nonetheless remain distinguishable.” [0020]
“In doing so, external parameters may for example be incorporated, hashed and saved as well as compared with the backend of the vehicle.” [0022]
Rationale: Schaaf expressly contemplates plural information components available as hashes and separately teaches hashing external vehicle parameters. Schaaf does not expressly label this parameter-derived value a second hash. It would nevertheless have been PHOSITA-obvious to preserve the separately identified equipment information and parameter information as separate hashes because Schaaf expressly seeks to keep the hashed components distinguishable, permitting independent verification when either the vehicle equipment or function settings change.
based on parameter data is assigned to each NFT of the list of NFTs;
See at least:
“In some exemplary embodiments, generating the hash value may furthermore be based on one or more elements of the group consisting of a vehicle configuration, a point in time of generation, a vehicle parameter, a maximum speed, an activation of an adaptive distance alert, and an activation of a vehicle-related service.” [0022]
“Exemplary embodiments may accordingly permit the incorporation of other parameters that are then also verifiable.” [0022]
“In doing so, external parameters may for example be incorporated, hashed and saved as well as compared with the backend of the vehicle.” [0022]
Rationale: Schaaf expressly hashes vehicle-configuration information, vehicle parameters, function settings, and activation states. Applying that disclosed operation to the parameter data associated with each NFT in Wright’s list assigns each NFT a parameter-derived second hash.
comprising the first hash values;
See at least:
“In this case, the method 10 is executed locally in the vehicle 100, for example in the event of each start attempt, and a hash value/ID is calculated.” [0040]
“To accomplish this, the vehicle 100 transfers the locally generated hash value to a controlling network component 200 that performs the comparison and pursues corresponding measures depending on the result.” [0040]
Rationale: Schaaf expressly generates the equipment-status hash locally in the vehicle. Repeating this operation for the requirement data of each NFT in Wright’s list produces the first hash values stored in Kreuz’s onboard list.
and creating and storing in a cloud a second list
See at least:
“On the left side, FIG. 2 shows an exemplary embodiment of a vehicle 100 with such a device that is coupled to a backend via the Internet.” [0037]
“The backend is used in this case for saving.” [0039]
Rationale: Schaaf expressly saves vehicle hash information in an Internet-connected backend. Repeating the backend-storage operation for the parameter-derived hash associated with each NFT in Wright’s list creates a remote collection of the second hash values. Implementing Schaaf’s Internet-connected backend using cloud computing resources would have been a conventional and predictable implementation.
comprising the second hash values
See at least:
“In doing so, external parameters may for example be incorporated, hashed and saved as well as compared with the backend of the vehicle.” [0022]
Rationale: Schaaf expressly hashes vehicle parameters and saves the resulting hash information for backend comparison. Performing this operation for the parameter data of each NFT produces a backend list comprising the second hash values.
is created and distributed
See at least:
“The saving may in some embodiments include distributing identical copies of the ID to a network with several members.” [0024]
Rationale: Schaaf expressly distributes copies of its hash-based ID across multiple network members. Applying that operation to the collection of parameter-derived NFT hashes creates and distributes the second list.
and is stored in a cloud in a distributed manner,
See at least:
“The term ‘decentralized database’ means that, in contrast to centralized saving under the control of an individual network component, saving is decentralized under the control of a plurality of network components and to a plurality of network components.” [0042]
“These data are then saved in a distributed manner on the participating network components.” [0042]
Rationale: Schaaf expressly stores hash information through a decentralized network of participating backend components. Because Schaaf’s backend is accessed through the Internet [0037], implementing those network resources as a distributed cloud was a conventional and predictable arrangement.
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 apply Schaaf’s content-derived hashing to each NFT-based entitlement record in Wright’s list, calculate a first hash from the vehicle-equipment requirement information taught by Kreuz, calculate a separately distinguishable second hash from the vehicle-function parameters expressly identified by Schaaf, store the requirement-data hashes in Kreuz’s onboard configuration structure, and store and distribute the parameter-data hashes through Schaaf’s Internet-connected decentralized backend.
This modification is supported by Schaaf’s express separation of two technically different input categories: hardware/software equipped-status information [0019] and vehicle-configuration, vehicle-parameter, and function-activation information [0022]. Schaaf further teaches that plural hashed information components may remain distinguishable [0020], calculates equipped-status information locally in the vehicle [0040], hashes external parameters for backend comparison [0022], and distributes saved hash information across multiple network members [0024], [0042].
Maintaining separate hashes for the two independently changing categories would have been a predictable data-integrity design. A hardware or software equipment change could be verified through the requirement-data hash without changing the function-setting hash, while a parameter or activation-setting change could be verified through the second hash without representing that the underlying vehicle equipment had changed. Local storage of the equipment-requirement hashes would permit direct comparison against Kreuz’s onboard actual-configuration data, while distributed backend storage of the function-setting hashes would facilitate remote synchronization, verification, and tamper detection. The modification therefore follows Schaaf’s stated objective of preserving distinguishability and verifiability of the different information components and does not depend solely on the claimed arrangement as a roadmap.
Response to Applicant’s Arguments
Applicant’s arguments have been fully considered but are not persuasive.
Corresponding OEE Claims
Applicant states that Claims 12–21 sufficiently correspond to allowable or granted claims in an Office of Earlier Examination (“OEE”) application. The disposition of claims in another jurisdiction or application does not control patentability under United States law. Patentability in this application is determined independently under the claims presently before the Office, the prior art of record, and the requirements of 35 U.S.C. 101 and 103. Applicant has not identified a specific OEE finding that establishes error in the factual findings or legal conclusions set forth in this action. Accordingly, the status of the corresponding OEE claims does not warrant withdrawal of the present rejections.
Rejection Under 35 U.S.C. § 101
Applicant argues that amended Claim 12 integrates the alleged abstract idea into a practical application because it applies the assigned vehicle function schema by adjusting vehicle-equipment settings according to the parameter data.
The argument is not persuasive.
Step 2A, Prong One
Claim 12 recites managing an entitlement to a vehicle function through the following limitations:
minting the vehicle function schema as an NFT in a predetermined number;
assigning the NFT to a vehicle and limiting the NFT to at most one vehicle;
encoding requirement and parameter information in the NFT;
selecting or acquiring the NFT; and
conditioning application of the vehicle function schema on the selected or acquired NFT.
Considered together, these limitations recite management of rights or entitlements governing access to and use of a vehicle function. The creation, assignment, acquisition, limitation, and enforcement of such an entitlement fall within certain methods of organizing human activity, including commercial or legal interactions and management of contractual or licensing rights.
The requirement data and parameter data specify the informational content used to define the entitlement-controlled configuration. Those data limitations do not, by themselves, recite a technological improvement or remove the entitlement-management concept from the identified abstract-idea grouping.
The rejection does not rely on an undifferentiated mental-process theory for Claim 12. The identified exception is the entitlement and rights-management process recited by the claim.
Step 2A, Prong Two
The claim must be considered as a whole, including:
“applying, based on the selected or acquired NFT, the assigned vehicle function schema to the vehicle by adjusting settings of the equipment features of the vehicle according to the parameter data.”
This limitation contemplates a physical effect on vehicle equipment. The presence of a physical effect, however, does not by itself establish integration into a practical application. The relevant inquiry is whether the claim imposes a meaningful technological limitation on the judicial exception or merely states the result that follows from the entitlement determination.
Claim 12 does not identify:
the vehicle equipment whose settings are adjusted;
the setting or operating value that is changed;
an ECU, actuator, domain controller, or hardware-security module performing the adjustment;
a vehicle-bus or communication protocol;
a control algorithm or sequence for applying the configuration;
a cryptographic validation mechanism between the DLT system and the vehicle; or
a technical improvement in the operation of the vehicle, DLT system, or configuration process.
Instead, the claim functionally states that, after the NFT has been selected or acquired, the corresponding configuration is applied by adjusting unspecified settings of unspecified vehicle equipment. The adjustment therefore constitutes the generally recited implementation of the entitlement result rather than a specifically claimed improvement in vehicle-control technology.
The DLT system and vehicle likewise do not constitute a meaningful particular-machine limitation merely because the entitlement process is performed in a vehicle environment. The claim uses the DLT system for its ordinary recordation and assignment functions and uses the vehicle as the field in which the entitlement-controlled configuration is consumed. It does not recite a particular technological interaction between those systems that improves their operation.
Accordingly, the claim does not integrate the identified abstract idea into a practical application under Step 2A, Prong Two. See MPEP §§ 2106.04(d) and 2106.05(a)–(c), (f)–(h).
Step 2B
The additional elements, individually and as an ordered combination, do not amount to significantly more than the identified exception. The claim uses a DLT system to create and record a uniquely identified entitlement, associates the entitlement with a vehicle, stores information defining the authorized configuration, and applies that information through existing vehicle equipment.
The claim does not recite an unconventional DLT architecture, improved consensus mechanism, new cryptographic operation, particular vehicle-authentication procedure, or specific equipment-control technique. Rather, the claim uses DLT recordation, data association, data retrieval, and vehicle configuration according to their established functions. The ordered combination therefore implements the entitlement-management process through conventional technological components without adding an inventive technological concept.
Applicant’s argument establishes that the amended claim recites a physical implementation step, but does not identify how that step, as claimed, improves vehicle or DLT technology. The § 101 rejection is therefore maintained.
Claims 13–20 add equipment identifiers, software or hardware versions, content categories, compatibility determinations, selection lists, storage locations, and hash values. These limitations further specify the information processed or the manner in which the information is organized, compared, hashed, or stored, but do not recite a technological improvement that cures the deficiencies of Claim 12. Claim 21 functionally recites an apparatus performing the method through a DLT system accessible via an OTA network, but does not recite an improvement to the OTA network or DLT system.
Rejection Under 35 U.S.C. 103
Applicant argues that Wright and Kreuz do not teach or suggest:
an NFT comprising parameter data describing settings of a vehicle function schema; or
applying the assigned schema by adjusting vehicle-equipment settings according to the parameter data.
The argument is not persuasive because it evaluates the references individually and does not address what their combined teachings would have suggested to a person of ordinary skill. Nonobviousness cannot be established by attacking references individually where the rejection relies on a combination. In re Keller, 642 F.2d 413, 425, 208 USPQ 871, 881 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 1097, 231 USPQ 375, 380 (Fed. Cir. 1986); MPEP § 2145.
Wright’s Entitlement and Configuration Data
Applicant correctly observes that Wright manages entitlements through blockchain technology. That is the reason Wright is relied upon for creating, uniquely identifying, recording, assigning, acquiring, and managing the vehicle-function entitlement.
Wright is not limited to recording ownership. Wright teaches an entitlement implemented as a data structure containing the terms and conditions, including usage conditions, of the order [0168]. Wright further teaches that a base entitlement corresponds to a base product configuration and that GPS and music-service functions may be represented by linked add-on entitlements [0183]. Wright derives configuration data by traversing the associated entitlements and identifies the in-force entitlements as the product’s current configuration [0194].
These disclosures teach that Wright’s entitlement records contain terms and values defining the authorized configuration and feature state of the product. Under the broadest reasonable interpretation consistent with the specification, “parameter data” is not limited to a particular numeric format, calibration value, communication message, or control protocol. The specification defines parameter data broadly as data describing settings of the vehicle function schema [0015]. Wright’s entitlement terms, values, selected features, and current-configuration information therefore teach or suggest data describing the authorized settings or state of the vehicle-function schema.
Kreuz’s Vehicle-Configuration Teachings
Applicant characterizes Kreuz as merely documenting installed hardware and software components. That characterization does not account for Kreuz’s configuration and implementation teachings.
Kreuz states:
“To this end, in particular, the appropriate hardware components, i.e., primarily the various control devices, are selected and the necessary hardware is implemented, for which the required software modules are suitably combined during configuration and are preferably transferred to the vehicle by means of flash software.” (col. 5, lines 28–39)
Kreuz thus teaches selecting appropriate hardware and control devices, implementing the necessary hardware, combining the required software modules during configuration, and transferring those modules to the vehicle through flash software. The rejection relies on this actual language, not the previously paraphrased sentence concerning hardware required to “realize” a function.
Kreuz also teaches that the requested and ordered vehicle configuration is determined using computer-assisted automatic configuration, col. 5, lines 15–24, and that technical restrictions may be used to ensure compatibility among specific control devices, col. 5, lines 1–9. Its stored configuration data identify the hardware, software, actuators, sensors, connections, bus identifiers, memory resources, and CPU utilization associated with the vehicle. See col. 7, lines 38–50. The stored data further contain the information needed to locate the control devices and software modules involved in executing a given functionality. See col. 7, lines 55–61.
The passage stating that the actual-configuration data describe the vehicle’s hardware and software components and their component relationships appears at col. 6, approximately lines 35–39. Applicant’s reference to col. 6, lines 33–37 identifies the same general passage. Any minor line-number variation does not affect the substance of the cited disclosure.
The component-description passage is not relied upon in isolation as expressly disclosing every aspect of the claimed parameter data. It is considered together with:
Wright’s entitlement terms, values, and current-configuration data;
Kreuz’s requested and ordered configurations;
Kreuz’s technical compatibility restrictions;
the selection and implementation of appropriate hardware;
the combination of required software modules; and
transfer of the configuration to the vehicle through flash software.
Requirement Data and Parameter Data in the NFT
The rejection does not contend that Kreuz independently teaches an NFT. Wright supplies the uniquely identified blockchain entitlement data structure. Kreuz supplies the vehicle-specific equipment requirements and technical configuration information incorporated into that structure.
Wright already evaluates configuration prerequisites and determines whether a requested add-on entitlement is acceptable in view of the existing configuration [0190]–[0195], [0199]–[0202]. Kreuz supplies the known vehicle-specific hardware and software information needed to determine whether the requested function can be implemented by the particular vehicle.
It would have been obvious to include Kreuz’s equipment requirements and corresponding function-configuration information in Wright’s entitlement data structure so that the entitlement system could determine whether the identified vehicle possesses the equipment required to implement the acquired function. The resulting entitlement would include:
requirement data identifying the hardware, control devices, software modules, actuators, sensors, and resources required for implementation; and
parameter data identifying the authorized vehicle-function configuration or settings.
This modification combines complementary teachings and predictably prevents an entitlement-controlled function from being activated on an incompatible vehicle. The rejection does not require bodily incorporation of Kreuz’s entire system into Wright. The relevant inquiry is what the combined teachings would have suggested to a person of ordinary skill. See KSR International Co. v. Teleflex Inc., 550 U.S. 398, 417 (2007).
Applying the Schema by Adjusting Vehicle-Equipment Settings
Wright teaches requesting or acquiring an add-on entitlement for an additional feature or capability [0197], recording the entitlement in the blockchain [0204]–[0205], providing the entitlement information to the end user, and allowing the end user to use the entitled product under the add-on entitlement [0206].
Kreuz teaches determining the requested vehicle configuration, selecting and implementing the appropriate hardware, combining the required software modules, and transferring those modules to the vehicle by flash software. See col. 5, lines 15–39.
In the proposed combination, Wright’s acquired entitlement identifies and authorizes the selected vehicle-function configuration, and Kreuz’s configuration process applies that configuration to the vehicle equipment. The claim does not require a particular setting, numerical adjustment, bus instruction, ECU command, or runtime-control sequence. Applying the selected software configuration to the corresponding vehicle control devices through Kreuz’s configuration and flash-transfer process therefore teaches or renders obvious adjusting vehicle-equipment settings according to the configuration data.
Applicant has not identified a technical incompatibility, teaching away, lack of reasonable expectation of success, or unexpected result. Wright manages and authorizes the vehicle-function entitlement; Kreuz determines and implements the corresponding technically compatible vehicle configuration. Combining those teachings would have produced the predictable result of authorizing and implementing an available vehicle function only when the vehicle possesses the necessary equipment.
Dependent Claims 13–21
Applicant argues that Claims 13, 16, 19, and 21 are patentable by virtue of their dependency and that Prodin and Schaaf do not cure the alleged deficiency in Claim 12.
The argument is not persuasive. Wright and Kreuz establish the subject matter of Claim 12 for the reasons explained above. Dependency alone does not establish patentability. Each dependent claim is separately evaluated with its additional limitations, and the action provides corresponding findings for those limitations.
Prodin and Schaaf are not relied upon to cure a deficiency in Claim 12. They are relied upon only for the further limitations of the applicable dependent claims:
Prodin supplies the visually perceptible vehicle-interior staging of Claim 14.
Wright and Kreuz supply the additional audio, compatibility, selection-list, and onboard-storage subject matter of Claims 15–18 as specifically mapped.
Schaaf supplies the content-derived hashing, local hash generation, backend hash storage, and distributed-storage teachings applied to Claim 20.
Claim 21 is addressed by the DLT-system and OTA-network findings stated in the rejection.
Applicant does not separately identify error in the findings directed to the additional limitations of Claims 13–21. The general assertion that the additional references do not cure the alleged deficiency in Claim 12 does not rebut the separate findings for those dependent limitations.
Examiner Conclusion
The amendment and arguments have been fully considered. Amended Claim 12 does not recite a sufficiently specific technological implementation or improvement to overcome the rejection under 35 U.S.C. 101. The 103 arguments address Wright and Kreuz separately and do not persuasively rebut their combined teachings, the articulated reason to combine, or the reasonable expectation of success. The dependent-claim arguments do not identify a separate deficiency in the findings directed to their additional limitations.
Accordingly, Applicant’s request for withdrawal of the rejections and allowance of Claims 12–21 is denied. The rejections under 35 U.S.C. 101 and 103 are maintained.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to 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
Prosecution Insights