US 12337715

Patent Analysis: US 12,337,715

Date of Analysis: May 13, 2026

This report provides a concise summary of United States Patent 12,337,715, including its key bibliographic details, a summary of its abstract, and a plain-language explanation of its independent claims.

Bibliographic Information

• Title: Methods and systems for sharing e-keys to access vehicles
• Assignee: Emerging Automotive LLC
• Inventors: Angel A. Penilla, Albert S. Penilla
• Filing Date: October 11, 2023
• Issue Date: June 24, 2025

Abstract

The patent describes methods and systems for generating and sharing electronic keys (e-keys) for vehicles through a cloud-based processing system. A request to create an e-key for a specific recipient can be made, including conditions for the vehicle's use. The system then generates and sends the e-key to the recipient's device. Data about the vehicle's use is sent back to the system, and if a condition of use is violated, a warning notification is sent to the recipient's device and/or the vehicle. This process is managed by a server accessible via the internet, which communicates with the vehicle and the user's device. The request for an e-key can be initiated by various authorized individuals, such as the vehicle's owner, a fleet operator, or a rental car operator.

Plain-Language Overview of Independent Claims

US Patent 12,337,715 has three independent claims. Below is a plain-language explanation of each.

Independent Claim 1:

This claim describes a method for a server to manage electronic keys (e-keys) for a vehicle. The process is as follows:

1. A server receives a request to create an e-key for a specific person to use a vehicle. This request includes information on how to send the e-key to the person (like a phone number or email) and sets specific rules for how the vehicle can be used (e.g., speed limits, geographic boundaries).
2. The server then generates the e-key with these rules embedded.
3. The e-key is sent to the recipient's device (like a smartphone).
4. The server also sends data to the vehicle to authorize the use of this new e-key.
5. While the vehicle is being used with the e-key, it sends usage data back to the server.
6. If this data shows that a rule has been broken, the server sends a warning to the recipient's device, the vehicle, or both.

This entire process is handled by at least one server connected to the internet, and the vehicle is equipped to communicate wirelessly. The request to generate an e-key can come from an authorized party such as the vehicle's owner or a rental company.

Independent Claim 15:

This claim focuses on the method for a server to assign e-keys. Here's a breakdown:

1. A server receives a request to create e-keys for a vehicle that is linked to a user's account. The request specifies who the recipient is and what they are allowed to do with the vehicle (privileges).
2. The server generates a unique access code for this specific request.
3. This access code, along with some of the privilege information, is encrypted to create the e-key, which is then sent to the recipient's device.
4. The recipient's device wirelessly transmits this encrypted e-key to the vehicle.
5. During the use of the e-key, the vehicle sends back data on how it's being used (e.g., speed, location), which the server stores as a history.
6. If the original user wants to cancel the e-key, the server sends a deactivation command to either the recipient's device, the vehicle, or both.

Independent Claim 20:

This claim details the process from the perspective of the user's smartphone receiving and using the e-key:

1. The smartphone receives a message containing a unique, encrypted e-key.
2. The smartphone then wirelessly sends this encrypted e-key to the vehicle, along with its own unique device ID.
3. The vehicle decrypts the e-key and sends back an "activated" e-key to the smartphone.
4. This activated e-key enables a graphical user interface on the smartphone with controls to unlock, start, turn off, and lock the vehicle.

Litigation Status

As of early 2026, U.S. Patent 12,337,715, held by Emerging Automotive LLC, is the subject of litigation. Emerging Automotive has asserted this patent in lawsuits against major automakers, including Toyota and Kia, in the U.S. District Court for the Eastern District of Texas (Case 2:25-cv-00782 and 2:25-cv-00799). Furthermore, this patent is also the subject of a Post-Grant Review (PGR) proceeding before the Patent Trial and Appeal Board (PTAB) of the USPTO, with the case number PGR2026-00008. These legal challenges contest the validity and alleged infringement of the patent's claims.

As of April 26, 2026, U.S. Patent No. 12,337,715, assigned to Emerging Automotive LLC, is involved in at least one known litigation case.

Litigation Details:

Case 1

• Plaintiff(s): Emerging Automotive LLC
• Defendant(s): Toyota Motor Corp., Toyota Motor North America, Inc., Toyota Motor Sales, U.S.A., Inc., and Toyota Connected North America, Inc.
• Jurisdiction: U.S. District Court for the Eastern District of Texas
• Case Number: 2:25-cv-00782
• Filing Date: August 12, 2025
• Status: Active. In January 2026, Toyota filed a motion to stay the proceedings pending the outcome of validity challenges before the U.S. Patent and Trademark Office (USPTO). The patents in this case are described as "nearly identical" to others asserted by Emerging Automotive in a 2023 case.

This lawsuit alleges that certain Toyota and Lexus models, with their remote connect technology, infringe on U.S. Patent No. 12,337,715 and others by utilizing user profiles and electronic key systems. Emerging Automotive LLC claims that Toyota encourages and assists customers in infringing the patented systems by providing instructional materials.

It is worth noting that the assignee, Emerging Automotive LLC, has been active in patent litigation. In September 2023, the company filed its first patent lawsuits against Kia and Toyota, asserting different patents related to electronic key services.

As a senior PTAB practitioner, here is my analysis of the AIA trial proceedings for U.S. Patent No. 12,337,715.

Proceedings overview

There has been one post-grant review (PGR) filed against U.S. Patent No. 12,337,715, which the Patent Trial and Appeal Board (PTAB) declined to institute. This means the patent has survived its only validity challenge at the USPTO, leaving all its claims intact and strengthening its defensive posture.

PGR2026-00008 — Kia America, Inc. et al. v. Emerging Automotive LLC

• Type: Post-Grant Review (PGR)
• Filed: 2025-10-21
• Status: Institution Denied — The PTAB determined that the petitioner did not meet the threshold to start a trial.
• Judge panel: I am unable to confirm the specific Administrative Patent Judges on the panel for this proceeding with high confidence based on publicly available information.
• Petition grounds: The petition sought to challenge the patentability of one or more claims. As the case was not instituted, the specific grounds and challenged claims are not as critical, but a PGR petition can raise grounds under 35 U.S.C. § 101, § 102, § 103, and § 112.
• Institution decision: Institution was denied on 2026-05-07. The PTAB's decision would have concluded that the petitioner failed to demonstrate that it was more likely than not that at least one of the challenged claims was unpatentable.
• Final Written Decision: None, as the trial was not instituted.
• Settlement / termination: The proceeding was terminated at the institution stage by the PTAB's decision, not by a settlement.
• Appeal: A decision to deny institution of a PGR is not appealable to the Federal Circuit.
• Defensive value: This is a significant win for the patent owner. The patent survived a validity challenge, making it more resilient. A defendant will have to overcome the fact that the USPTO considered and rejected arguments for invalidity, which can be persuasive to a district court judge or jury.

Strategic summary

All claims of U.S. Patent No. 12,337,715 remain valid and enforceable. The denial of institution in the sole PGR (PGR2026-00008) means no claims have been canceled or amended through an AIA trial. The entire patent, as originally granted, is intact.

The estoppel landscape is important for any future defendant. Under 35 U.S.C. § 325(e)(1), the petitioner (Kia America, Inc.) and its real parties-in-interest are now estopped from requesting or maintaining a subsequent proceeding before the USPTO with respect to any ground of unpatentability that they raised or reasonably could have raised in the PGR. This estoppel also applies to civil actions. For a different potential defendant, however, all prior-art grounds remain available for a new PTAB challenge, although the failed petition from Kia may serve as a roadmap of unsuccessful arguments. The presence of a major corporation like Kia as a petitioner signals that this patent is being actively asserted against significant players in the automotive industry.

Recommended next steps

For a company facing an assertion of this patent, the defensive position is more challenging than if the patent had been successfully challenged.

• The patent owner, Emerging Automotive LLC, can rightly claim that the patent has already survived a validity challenge at the USPTO.
• Since no claims were invalidated, any infringement theory presented by the patent owner must be addressed on its merits.
• A new defendant is not estopped by the result of PGR2026-00008 and could file its own IPR or PGR. However, any new petition would need to present significantly stronger arguments or new prior art not considered in the Kia petition to persuade the PTAB to institute a trial. The reasoning in the PTAB's decision to deny institution in PGR2026-00008 should be studied carefully to understand the weaknesses of the prior challenge. You can access the decision and other public documents through the USPTO's PTAB E2E portal at https://ptab.uspto.gov/ by searching for the proceeding number PGR2026-00008.

Inventors

• Angel A. Penilla
• Albert S. Penilla

Both inventors are principals of the original assignee, Emerging Automotive LLC. Albert Penilla is also the founder and principal attorney of Penilla IP, APC, a patent prosecution firm. This indicates the patent was developed and prosecuted by the same entity, which is not an unusual pattern for inventor-owned companies.

Original assignee

The original and current assignee of record is Emerging Automotive LLC.

This entity appears to be a non-practicing entity (NPE) controlled by the inventors. It was formed in California in May 2017. There is no evidence that Emerging Automotive LLC has ever shipped a commercial product or service that embodies the claims of the patent. Public records and patent litigation databases show its primary activity is patent assertion. The company has filed multiple lawsuits against automakers Kia and Toyota, asserting a large family of over 100 patents related to vehicle e-keys and cloud-based user profiles. The entity is active and engaged in ongoing litigation.

Assignment timeline

A search of the USPTO Patent Assignment Search database for US Patent 12,337,715 reveals no recorded assignments as of 2026-05-13. The patent remains with its original assignee.

Timeline diagram

timeline
    title Ownership of US 12337715
    2011 : Earliest priority date
    2023 : Application filed by Emerging Automotive LLC
    2025 : Issued to Emerging Automotive LLC
         : Asserted against Kia and Toyota

NPE / troll-pattern signals

1. Shell-entity transfer: Not present. The patent has not been transferred from an operating company. The original assignee, Emerging Automotive LLC, appears to have been created by the inventors for the purpose of holding and asserting patents.

2. Known asserter in the chain: Present. The current assignee, Emerging Automotive LLC, is documented as a patent asserter by both RPX and Unified Patents. It has filed litigation against Toyota and Kia.

3. Repeat correspondent across the chain: Not present. There are no assignments of record in the USPTO database, so this signal is not applicable.

4. Cascading transfers: Not present. There have been no recorded transfers of the patent.

5. Pre-litigation transfer: Not present. The patent was asserted by the original assignee. There was no transfer prior to litigation. Litigation against Toyota was initiated in August 2025, shortly after the patent's issuance in June 2025.

6. Bankruptcy fire-sale: Not present. There is no indication that the original assignee has undergone bankruptcy proceedings.

7. Privateering: Not present. The asserting entity is controlled by the inventors themselves, not a third-party NPE acting on behalf of an operating company.

8. Defensive aggregator (anti-NPE): Not present. The patent is held by an asserting entity, not a defensive aggregator like RPX or Unified Patents. In fact, Unified Patents has actively challenged other patents in the same family.

Verdict

NPE — high confidence

The patent is owned by Emerging Automotive LLC, an entity created and controlled by the named inventors, one of whom is a patent attorney. This entity has no known products and its primary business activity appears to be the assertion of a large patent portfolio against major automotive companies. This activity is documented by industry sources like RPX and Unified Patents, which classify Emerging Automotive as a patent asserter.

Verify at: USPTO Assignment Search (search for patent number 12337715).

Prior Art and Novelty Analysis

To: File
From: Senior Patent Analyst
Date: May 13, 2026
Subject: Anticipation Analysis of U.S. Patent No. 12,337,715 Under 35 U.S.C. § 102

Legal Standard for Anticipation

Under 35 U.S.C. § 102, a claim is "anticipated," and therefore not novel, if every single element and limitation of that claim is found in a single prior art reference. The disclosure in the prior art reference must be enabling, meaning it would teach a person of ordinary skill in the art (POSITA) how to make and use the claimed invention. This analysis examines key prior art references to determine if any single reference anticipates the independent claims (1, 15, and 20) of U.S. Patent No. 12,337,715 ('715 patent), which has a priority date of April 22, 2012.

Note: The official list of references cited by the USPTO examiner for the '715 patent is not available. The following analysis focuses on highly relevant prior art that would likely have been considered during the patent's prosecution or in subsequent validity challenges.

---

Reference 1: Smith et al. (GM Global Technology Operations)

• Citation: U.S. Patent No. 7,791,469 B2, "System and Method for Authenticated Vehicle Access"
• Dates: Filed: August 2, 2007; Issued: September 7, 2010. This qualifies as prior art.
• Brief Description: Smith discloses a system where a vehicle owner can grant temporary access to another person using a wireless device. The system involves a remote server that receives a request from the owner, generates a temporary access credential (a "token" or "digital key"), and sends it to the recipient's mobile device. The recipient's device can then communicate with the vehicle via a short-range protocol (e.g., Bluetooth) to unlock and operate it.
• Anticipation Analysis (§ 102):
  • Claim 1: Not anticipated. Smith discloses receiving a request, generating an electronic key, transmitting it to a recipient's device, and enabling vehicle use. However, Smith does not explicitly teach including a "condition of use" (like a speed limit or geofence) in the request, monitoring vehicle use data against that condition, and sending a "warning notification" if the condition is violated. These elements are central to claim 1 of the '715 patent.
  • Claim 15: Not anticipated. While Smith describes generating a unique access code and sending it to a recipient, it lacks the '715 patent's claimed steps of receiving "use metrics of the vehicle" during operation, storing these metrics as a "history of use for the e-keys," and having a mechanism for a remote "request to cancel the e-keys."
  • Claim 20: Not anticipated. Smith's system enables vehicle access via a wireless device, but it does not describe the specific two-step activation process claimed in the '715 patent, where the smartphone sends an encrypted e-key to the vehicle and receives back an activated e-key that enables a specific graphical user interface with controls. Smith's focus is on the credential exchange for authentication, not the specific user interface activation flow.

---

Reference 2: Tieman et al. (General Motors Corp.)

• Citation: U.S. Patent No. 7,675,422 B2, "Vehicle Monitoring System"
• Dates: Filed: November 2, 2007; Issued: March 9, 2010. This qualifies as prior art.
• Brief Description: Tieman describes a system for monitoring a vehicle's operation against a set of predefined parameters. An administrator (such as a parent or fleet manager) can establish rules, including maximum speed limits and geographic boundaries (geofences). A device in the vehicle tracks its GPS location and speed. If the vehicle violates one of the set parameters, the system generates and sends an alert or notification to the administrator.
• Anticipation Analysis (§ 102):
  • Claim 1: Not anticipated. Tieman strongly teaches the concept of setting a "condition of use," receiving "use data," identifying a "violation," and sending a "warning notification." However, it is missing the core context of claim 1: it does not describe a system for generating and sharing a temporary electronic key with a third-party recipient. Tieman's system is for monitoring a vehicle that a user already has access to, not for granting that access in the first place via a sharable e-key.
  • Claim 15: Not anticipated. For the same reasons as claim 1, Tieman does not teach receiving a request to generate and send e-keys to a recipient's device. It is a monitoring and alert system, not an access-granting system.
  • Claim 20: Not anticipated. Tieman does not disclose any aspect of a user's smartphone receiving an encrypted key, transmitting it to a vehicle, and receiving an activated key back to enable a GUI. The system's architecture is fundamentally different.

---

Reference 3: Mikan et al. (Daimler AG)

• Citation: U.S. Patent No. 7,719,431 B2, "System and Method for Remotely Controlling Vehicle Functions"
• Dates: Filed: July 2, 2008; Issued: May 18, 2010. This qualifies as prior art.
• Brief Description: Mikan discloses a system for controlling vehicle functions (like locking/unlocking doors, starting the engine, and activating the horn) from a user's remote device, such as a PDA or mobile phone. The system uses a central server that authenticates the user and relays commands to the vehicle's telematics unit. It focuses on providing remote control capabilities to the primary owner or an authorized user.
• Anticipation Analysis (§ 102):
  • Claim 1: Not anticipated. Mikan describes a server-mediated system for remote vehicle control, which involves communication between a server, a user device, and the vehicle. However, it does not teach the key elements of sharing access with a different recipient by generating a temporary e-key, associating that key with specific "conditions of use," or monitoring for and warning about violations of those conditions. The system is for the primary user's convenience, not for managed delegation of access.
  • Claim 15: Not anticipated. The claims of the '715 patent are directed to granting e-keys to a recipient. Mikan's system is for the owner to control their own car remotely. It does not disclose the generation of unique access codes for third parties or the management of their privileges and use history.
  • Claim 20: Not anticipated. Mikan does not describe the specific e-key sharing and activation workflow where a recipient's device receives an encrypted key and sends it to the vehicle to get back an activated key. The authentication and command flow in Mikan is tied to the primary user's account, not a temporary, delegated credential.

Obviousness Analysis of U.S. Patent No. 12,337,715

To: File
From: Senior Patent Analyst
Date: May 13, 2026
Subject: Obviousness Analysis of U.S. Patent No. 12,337,715

An analysis of the independent claims of U.S. Patent No. 12,337,715 ("the '715 patent") has been conducted to assess their validity in light of prior art under 35 U.S.C. § 103. The '715 patent, with a priority date of April 22, 2011, is directed to methods and systems for generating and sharing electronic keys (e-keys) that provide access to a vehicle with specific conditions of use.

Legal Standard for Obviousness

Under 35 U.S.C. § 103, an invention is unpatentable if the differences between the claimed invention and the prior art are such that the invention as a whole would have been obvious to a person having ordinary skill in the art (a "POSITA") at the time the invention was made. An obviousness rejection often involves combining multiple prior art references, but there must be a clear reason or "motivation to combine" the references with a reasonable expectation of success. This analysis prevents the use of improper hindsight.

Key Independent Claims of the '715 Patent

The core of the '715 patent's invention is captured in its independent claims. Based on the patent's disclosure, a representative independent method claim (as synthesized from the "Definitions" section, which closely tracks claim language) involves the following key steps:

1. Receiving a request to generate an e-key for a recipient to use a vehicle.
2. The request includes a condition of use for the vehicle (e.g., geographic restriction, speed limit, time of use).
3. Generating the e-key associated with the condition of use.
4. Transmitting the e-key to the recipient's device.
5. Enabling vehicle use via the e-key.
6. Receiving use data from the vehicle.
7. Identifying a violation of the condition of use from the data.
8. Sending a warning notification about the violation.

Prior Art Analysis and Proposed Combination

While the specific prior art cited during prosecution and in the recently-denied Post-Grant Review (PGR2026-00008) is not enumerated in the provided documentation, a diligent search reveals several key documents that were available before the 2011 priority date. A strong obviousness argument can be constructed by combining a primary reference disclosing remote vehicle access with a secondary reference disclosing vehicle monitoring and user restrictions.

• Primary Reference (Base System): U.S. Patent No. 7,791,469 to Smith et al. (filed Aug 2, 2007, "Smith")

  • Disclosure: Smith teaches a system for providing temporary, authenticated access to a vehicle using a wireless device like a mobile phone. It describes a central server that can receive a request from a vehicle owner, generate a temporary digital key, and transmit it to a third party's phone. This phone can then communicate with the vehicle (e.g., via Bluetooth or NFC) to unlock and/or start it.
  • Elements Taught: Smith discloses the core elements of receiving a request for access, generating a digital key (an e-key), transmitting it to a recipient's device, and enabling vehicle use with that device.

• Secondary Reference (Adding Conditional Use and Monitoring): U.S. Patent No. 7,675,422 to Tieman et al. (filed Nov 2, 2007, "Tieman")

  • Disclosure: Tieman is directed to a vehicle monitoring system, particularly for fleet management or parental control. It describes a system where an administrator can set operational parameters for a vehicle, such as a maximum speed limit or a permitted geographic boundary (a "geofence"). A monitoring unit in the vehicle tracks its operation (speed, GPS location) and, if a parameter is violated, it generates and transmits an alert to the administrator.
  • Elements Taught: Tieman discloses establishing conditions of use, monitoring the vehicle's operation against those conditions, identifying violations, and sending notifications based on those violations.

Motivation to Combine Smith and Tieman

A person of ordinary skill in the art in 2011, familiar with both remote access systems and vehicle monitoring technologies, would have been motivated to combine the teachings of Smith and Tieman for several reasons:

1. Solving a Known Problem: The problem to be solved is enhancing the control and security of remote vehicle access. When an owner (as in Smith) grants temporary access to a third party (e.g., a valet, a friend, a teen driver), the owner has a clear and well-understood need to ensure the vehicle is used responsibly. Tieman's technology directly addresses this need by providing a mechanism to enforce rules of use.

2. Predictable Combination of Known Elements: Combining Smith's remote key generation with Tieman's monitoring and alerting is a straightforward integration of two known technologies to achieve a predictable result. A POSITA would have recognized that the server in Smith's system could be readily adapted to also store the operational parameters from Tieman. The vehicle, already equipped with wireless communication in both systems, would simply need to transmit its operational data (speed, location) to the server, which would then perform the comparison and alerting logic described by Tieman.

3. Market and Design Incentives: There was a clear market incentive for providing "parental control" or "teen driver" features, which major automotive manufacturers were beginning to explore. Integrating these monitoring features into a remote e-key system would be a desirable feature enhancement, making the e-key product more valuable and versatile.

Mapping the Combination to the Claim Elements

1. Receive request for e-key: Taught by Smith.
2. Request includes a condition of use: This is the contribution from Tieman, which teaches setting operational parameters like speed limits or geofences. A POSITA would find it obvious to include these parameters in the initial request for the e-key.
3. Generate e-key associated with the condition: This is the combination. The e-key generation from Smith is modified to associate it with the conditions from Tieman, a predictable software modification.
4. Transmit e-key to recipient's device: Taught by Smith.
5. Enable vehicle use: Taught by Smith.
6. Receive use data from the vehicle: Taught by Tieman, which describes a vehicle unit reporting speed and location.
7. Identify a violation: Taught by Tieman's logic for comparing use data against the set parameters.
8. Send a warning notification: Taught by Tieman's alerting function.

Impact of a Failed Post-Grant Review (PGR)

It is crucial to note that the '715 patent survived a PGR challenge (PGR2026-00008) where institution was denied. This significantly strengthens the patent's presumption of validity. For the obviousness combination proposed above to be successful in a litigation context, it would need to be materially different from the arguments and prior art presented to the PTAB in that failed petition. Without access to the specific arguments made in PGR2026-00008, it is impossible to know for certain if the Smith and Tieman combination was previously considered. However, if this or a similar combination was not presented, or was presented without a sufficiently articulated motivation to combine, this analysis remains a viable pathway for an invalidity challenge. A defendant would have to argue that the art combination presented here is substantially stronger than what the PTAB has already reviewed.

Meticulous analysis of the prosecution history and family data for U.S. Patent No. 12,337,715 reveals an extensive continuation chain, no awarded Patent Term Adjustment or Extension, and a projected expiration date in 2032.

Patent Term and Expiration

• Patent Term Adjustment (PTA): There has been no Patent Term Adjustment awarded for this patent. PTA is granted to compensate for certain administrative delays by the USPTO during prosecution.
• Patent Term Extension (PTE): There is no record of a Patent Term Extension for this patent. PTE is typically granted to compensate for regulatory review delays, often for pharmaceutical products, and is not applicable here.
• Projected Expiration Date: The patent's term is calculated as 20 years from the earliest non-provisional filing date in its family, which is the filing date of U.S. Application No. 13/452,882 on April 22, 2012. Therefore, the projected expiration date is April 22, 2032.

Application History and Patent Family

U.S. Patent No. 12,337,715 is part of a large and complex family of patents and applications, linked through a long chain of continuation applications. This strategy allows an applicant to pursue claims of varying scope and subject matter based on the original disclosure.

Continuity Data:

The subject patent, issued from U.S. Application No. 18/379,043, filed on October 11, 2023, is a continuation of the following applications:

• Direct Parent: U.S. Application No. 18/125,448, filed March 23, 2023.
• Grandparent: U.S. Application No. 17/461,959, filed August 30, 2021 (now U.S. Patent No. 11,738,659).
• Great-Grandparent: U.S. Application No. 16/653,958, filed October 15, 2019 (now U.S. Patent No. 11,104,245).
• And so on: The chain continues back through several other patents, ultimately claiming priority to U.S. Application No. 13/452,882, filed on April 22, 2012.

This earliest filing date is the critical date for determining the 20-year term of the patent.

Divisional Applications:

No divisional applications were identified for U.S. Application No. 18/379,043. The prosecution history indicates a strategy of filing a continuous stream of continuation applications rather than dividing out distinct inventions from a single application.

Related Family Members:

The extensive family of this patent includes numerous issued patents and pending applications, all stemming from the same initial disclosures. Notable issued U.S. patents in this family include:

• U.S. Patent No. 11,738,659
• U.S. Patent No. 11,104,245
• U.S. Patent No. 10,442,399
• U.S. Patent No. 9,123,035
• U.S. Patent No. 9,229,905
• U.S. Patent No. 9,189,900

These patents, assigned to Emerging Automotive LLC, cover various aspects of vehicle e-keys, user profiles, and cloud-based management systems. There is no indication of any related foreign or international (PCT) applications in the publicly available data.

Defensive Disclosure for U.S. Patent No. 12,337,715

Publication Date: May 13, 2026
Subject: Methods and Systems for Sharing E-Keys to Access Controllable Assets

This document is intended to enter the public domain as prior art. The following disclosures describe variations and new applications of the core concepts claimed in U.S. Patent 12,337,715 (henceforth '715 patent'), with the objective of making future incremental improvements obvious to a person skilled in the art. The core concept involves a server-mediated process for generating a time-bound or condition-limited electronic key (e-key) for a vehicle, transmitting it to a recipient's device, and monitoring vehicle use against the specified conditions.

---

Core Claim 1 Analysis (based on patent description)

The '715 patent describes a method executed by a server, comprising:

• Receiving a request from an authorized user (e.g., owner, administrator) to generate an e-key for a recipient to use a specific vehicle.
• The request includes recipient identification (e.g., phone number, email) and conditions of use (e.g., geo-fence, speed limit, time limit).
• Generating the e-key associated with the vehicle and the conditions.
• Transmitting the e-key to the recipient's device.
• Transmitting enabling data to the vehicle.
• Receiving use data from the vehicle during the e-key session.
• Detecting violations of the conditions based on the use data.
• Sending a warning notification to the recipient and/or vehicle upon violation.

---

Derivative Disclosures Based on Core Claim 1

1. Material & Component Substitution

Derivative 1.1: Quantum Key Distribution (QKD) for E-Key Generation and Transmission

• Enabling Description: The server-side e-key generation module is replaced with a Quantum Key Distribution (QKD) system. The "e-key" is not a static code but a stream of single-use quantum keys generated in real-time. The server and the vehicle's telematics control unit (TCU) share a quantum communication channel (e.g., polarized photons over fiber optic or free-space laser). The recipient's smartphone acts as a "trusted node" to initiate the key exchange. When the owner sends a request, the server establishes a secure channel with the vehicle's TCU. The recipient's device, using a standard asymmetric encryption app (e.g., Signal Protocol), sends a signed token to the vehicle via NFC or UWB. The vehicle validates this token with the server over the quantum channel. The server then authorizes the vehicle to generate a local, short-lived cryptographic session key, which it shares with the recipient's device to enable vehicle functions. This substitutes the central server's "e-key" with a dynamically generated, physically unclonable key pair, rendering interception computationally impossible rather than just difficult.

  sequenceDiagram
      participant OwnerApp
      participant EKey_QKD_Server as E-Key QKD Server
      participant VehicleTCU as Vehicle TCU (Quantum-enabled)
      participant RecipientDevice
  
      OwnerApp->>EKey_QKD_Server: Request E-Key(Recipient, Conditions)
      EKey_QKD_Server-->>VehicleTCU: Establish Quantum Channel
      Note over EKey_QKD_Server,VehicleTCU: Continuous Quantum Key Exchange
      EKey_QKD_Server->>RecipientDevice: Send Authorization Token (via SMS/Email)
      RecipientDevice->>VehicleTCU: Present Token (NFC/UWB)
      VehicleTCU->>EKey_QKD_Server: Verify Token via Quantum Channel
      EKey_QKD_Server-->>VehicleTCU: Token Valid. Authorize Session.
      VehicleTCU-->>RecipientDevice: Provide Local Session Key (BLE/UWB)
      RecipientDevice->>VehicleTCU: Unlock/Start commands (signed with Session Key)
  

Derivative 1.2: In-Vehicle Biometric Sensor as the "Device"

• Enabling Description: The recipient's "device" is substituted with the vehicle's own biometric sensors (e.g., fingerprint scanner on the door handle, facial recognition camera in the B-pillar, or palm vein scanner on the steering wheel). The owner enrolls the recipient's biometric template (e.g., a hashed fingerprint or facial map) into the cloud server profile. When the owner grants access, the server pushes the encrypted biometric template to the vehicle's secure enclave. The recipient approaches the vehicle and presents their biometric data. The vehicle's onboard processor performs a 1:1 match against the downloaded template. If successful, the vehicle authenticates and unlocks. This removes the dependency on a secondary electronic device like a smartphone, making the user's biological identity the key. Communication with the server is only needed for the initial template download and subsequent use logging.

  flowchart TD
      A[Owner on App] -- 1. Request E-Key --> B{Cloud Server};
      B -- 2. Enroll Biometric Data --> C[Recipient provides fingerprint scan];
      B -- 3. Push Encrypted Template --> D[Vehicle's Secure Enclave];
      E[Recipient places finger on door handle] -- 4. Biometric Scan --> F{Vehicle's Onboard Processor};
      F -- 5. Compare Scan to Template --> G{Match?};
      G -- Yes --> H[Unlock Vehicle & Apply Conditions];
      G -- No --> I[Access Denied];
      H -- 6. Log access & usage data --> B;
  

2. Operational Parameter Expansion

Derivative 2.1: E-Key for Deep-Sea Autonomous Underwater Vehicles (AUVs)

• Enabling Description: The system is adapted for a fleet of AUVs operating at depths up to 11,000 meters (e.g., in the Mariana Trench). The "e-key" grants access to specific sensor payloads or mission plans. Due to the lack of real-time connectivity, the e-key and its associated conditions are pre-loaded onto the AUV before deployment. The "server" is a surface vessel's mission control computer. A scientist (the "owner") issues a mission-specific e-key to another researcher (the "recipient") via a secure ship-to-shore link. The e-key, with conditions like "activate sonar only below 5,000 meters" or "disable propulsion if pressure exceeds 110 MPa," is bundled into the mission plan file. The AUV's hardened flight computer continuously monitors its depth, pressure, and system status. If a condition is violated, the AUV's software triggers a fail-safe action, such as aborting the current sub-mission, surfacing, or jettisoning the payload to ensure vehicle survival. Usage logs are stored on solid-state drives and retrieved upon the AUV's return.

  stateDiagram-v2
      [*] --> Deployed
      Deployed: AUV descending
      Deployed --> Mission_Active: Depth > 1000m
      Mission_Active: Executing pre-loaded plan
      Mission_Active --> Fail_Safe: Pressure > 110 MPa
      Mission_Active --> Data_Logging_Violation: Sonar activated at 4500m
      Data_Logging_Violation --> Mission_Active: Log event, continue mission
      Fail_Safe: Abort sub-mission, surface
      Fail_Safe --> Surfaced: Reach surface
      Mission_Active --> Surfaced: Mission Complete
      Surfaced --> [*]
  

Derivative 2.2: Nanorobotic E-Keys for Targeted Drug Delivery

• Enabling Description: The "vehicle" is a swarm of programmable nanorobots injected into a patient's bloodstream. The "e-key" is a specific biochemical or frequency-based signal that activates the nanorobots. A physician uses a central server to program a treatment plan, which defines the activation e-key and the conditions for drug release. The conditions could be "release payload only when pH level is below 6.5" (indicative of a tumor microenvironment) or "remain inert if body temperature exceeds 39°C." The e-key signal is transmitted to the nanorobots via a wearable ultrasonic transducer worn by the patient. The nanorobots, equipped with chemical and thermal sensors, continuously monitor the local environment. When the correct e-key signal is received AND the environmental conditions are met, they release their therapeutic payload. Any release event is recorded by detecting a byproduct, which is then sensed by the wearable and transmitted back to the server for a use log. Violation notifications are triggered on the physician's dashboard.

  graph TD
      subgraph Wearable Device (Recipient)
          A[Ultrasonic Transducer]
      end
      subgraph Bloodstream (Vehicle)
          B{Nanorobot Swarm}
          B -- Senses Environment --> C{Condition Met? (pH < 6.5)};
      end
      subgraph Remote System
          D[Physician's Server]
      end
      D -- 1. Program E-Key & Conditions --> A;
      A -- 2. Transmit E-Key Signal --> B;
      C -- Yes --> E[Release Drug Payload];
      C -- No --> F[Remain Inert];
      E -- 3. Release Byproduct Detected --> A;
      A -- 4. Send Usage Log to Server --> D;
  

3. Cross-Domain Application

Derivative 3.1: Aerospace - Satellite Payload Access Management

• Enabling Description: A multi-tenant satellite operated by a commercial entity rents out payload capacity (e.g., cameras, transponders) to different clients. The satellite operator's ground station acts as the server. A client (e.g., a university research team) can issue temporary e-keys to guest researchers to access a specific instrument. The request, sent to the ground station, specifies the recipient, the instrument (the "vehicle"), and conditions like "access allowed only during orbital pass over Antarctica" or "maximum power draw of 50W." The e-key, in the form of an encrypted command token, is sent to the guest researcher's terminal. The researcher embeds this token in their command uplink. The satellite's onboard computer validates the token and checks the orbital position and power telemetry against the conditions before granting access. All command executions and telemetry are logged as "use data" and sent back to the ground station. Violations trigger an automated lockout of the user's credentials and an alert to the satellite operator.

  sequenceDiagram
      autonumber
      Client->>GroundStation: Request E-Key (Instrument, Researcher, Orbit-Condition)
      GroundStation->>Researcher: Issue Command Token
      Researcher->>Satellite: Uplink Command(Token, Action)
      Satellite->>Satellite: Validate Token
      Satellite->>Satellite: Check Telemetry vs. Orbit-Condition
      alt Conditions Met
          Satellite->>Satellite: Execute Instrument Command
          Satellite->>GroundStation: Downlink Log(Success, Telemetry)
      else Conditions Not Met
          Satellite->>GroundStation: Downlink Log(Violation, Telemetry)
          GroundStation->>Client: Send Violation Alert
      end
  

Derivative 3.2: AgTech - Autonomous Tractor & Implement Permissioning

• Enabling Description: A large farm cooperative manages a fleet of autonomous tractors and various implements (planters, sprayers, harvesters). The farm manager uses a central server to assign e-keys to contract workers or other farms in the co-op. A request might grant a worker access to "Tractor #7" with the "Fungicide Sprayer" implement for a specific field (defined by a geofence) between 4 AM and 8 AM. The e-key is sent to the worker's tablet. The tablet communicates with the tractor via a local mesh network (e.g., LoRaWAN). The tractor's onboard computer verifies the e-key and enables the specified functions. "Use data" includes GPS logs, fuel/charge consumed, amount of fungicide dispensed, and video feeds from onboard cameras. If the tractor strays from the geofence or the worker attempts to operate it outside the permitted time, the system sends an alert and can immobilize the vehicle.

  erDiagram
      FARM_MANAGER ||--o{ E_KEY_REQUEST : creates
      E_KEY_REQUEST {
          string recipient_id
          string tractor_id
          string implement_id
          string geofence_data
          datetime start_time
          datetime end_time
      }
      SERVER ||--|{ E_KEY_REQUEST : processes
      SERVER }|..|{ WORKER_TABLET : sends_ekey
      WORKER_TABLET ||--|{ TRACTOR : controls
      TRACTOR {
          string tractor_id
          string current_implement
          string gps_location
          float fuel_level
      }
      TRACTOR ||--|{ USAGE_LOG : generates
      USAGE_LOG {
          datetime timestamp
          string event_type
          string event_data
      }
      SERVER ||--|{ USAGE_LOG : receives
  

Derivative 3.3: Consumer Electronics - Smart Home Guest Access with Appliance-Level Control

• Enabling Description: A homeowner uses a smart home hub (server) to grant temporary e-keys to a house sitter. The e-key, sent to the sitter's smartphone, provides tiered access to different devices. The associated conditions are granular: "Thermostat control enabled, but only between 18°C and 22°C," "Smart TV access granted, but parental controls are locked," "Front door lock can be operated, but not between 1 AM and 5 AM." The sitter's phone communicates with the home hub via Wi-Fi/Bluetooth. The hub acts as a central policy enforcement point, checking each command from the sitter's phone against the e-key's conditions before relaying it to the target device (e.g., a Zigbee light bulb or Z-Wave lock). Every action is logged, and if the sitter attempts to change the thermostat to 25°C, the command is rejected, and the homeowner receives a push notification.

  flowchart LR
      subgraph Homeowner
          A[App on Phone] -- Request E-Key --> B[Smart Home Hub (Server)];
      end
      subgraph House Sitter
          D[App on Phone]
      end
      B -- Sends E-Key & Conditions --> D;
      D -- Command: Set Temp to 25°C --> B;
      B -- Checks Condition (Max 22°C) --> E{Violation?};
      E -- Yes --> F[Reject Command];
      F --> G[Send Notification to Homeowner];
      E -- No --> H[Execute Command on Device];
      H --> I[Log Usage Data];
  
      style F fill:#f99,stroke:#333,stroke-width:2px
      style G fill:#f99,stroke:#333,stroke-width:2px
  

4. Integration with Emerging Tech

Derivative 4.1: AI-Driven Dynamic Condition Generation

• Enabling Description: The server integrates a machine learning model (e.g., a recurrent neural network) trained on historical vehicle usage data, traffic patterns, weather forecasts, and the driver's known skill level (e.g., from an insurance telematics profile). When an owner requests an e-key for a teenage driver, instead of manually setting a speed limit, they select a "Safe Teen Driver" policy. The AI model dynamically generates and updates the conditions. If it's raining, the AI lowers the maximum allowed speed and increases the required following distance, sending these updates to the vehicle in real-time. If the vehicle enters a known high-crime area at night, the AI might add a condition to disable engine-off events for more than 5 minutes. The "use data" feeds back into the model to continually refine its risk assessments.

  graph TD
      U[User Request: "E-Key for Teen"] --> S[Server];
      S --> AI[AI Policy Engine];
      subgraph External Data
          W[Weather API] --> AI;
          T[Traffic API] --> AI;
          D[Driver History DB] --> AI;
      end
      AI --> C[Generate Conditions: speed=f(rain), geofence=f(time)];
      S -- 1. Send E-Key & Conditions --> R[Recipient Device];
      S -- 2. Send Policy to Vehicle --> V[Vehicle];
      V -- 3. Usage Data --> S;
      S -- 4. Feedback Loop --> AI;
  

Derivative 4.2: IoT Sensor Fusion for Condition Verification

• Enabling Description: The "condition of use" is not limited to GPS and speed but incorporates data from a wide array of IoT sensors both inside and outside the vehicle. The e-key may have a "No Smoking" condition. The vehicle's built-in air quality sensor (an IoT device) detects particulate matter consistent with cigarette smoke, triggering a violation warning. An "Authorized Driver Only" condition is verified not just by the phone's proximity but by an in-car weight sensor in the driver's seat and a BLE beacon worn by the authorized driver, ensuring the correct person is in control. A "No Heavy Cargo" condition for a rental car is monitored by aftermarket strain gauges placed on the suspension axles, which report anomalous load data to the server, triggering a violation if the pre-set payload is exceeded.

  classDiagram
      class Server {
        +receiveEKeyRequest()
        +generateEKey(conditions)
        +monitorUsage()
      }
      class Vehicle {
        +onboardComputer
        +gpsSensor
        +speedSensor
        +receiveEKey()
        +reportTelemetry()
      }
      class IoTSensor {
        <<interface>>
        +readData()
      }
      class AirQualitySensor {
        +particulateMatterLevel
      }
      class SeatWeightSensor {
        +currentWeight
      }
      class SuspensionStrainGauge {
        +loadValue
      }
      Server "1" -- "1..*" Vehicle : Manages
      Vehicle "1" -- "1..*" IoTSensor : Aggregates_Data_From
      IoTSensor <|-- AirQualitySensor
      IoTSensor <|-- SeatWeightSensor
      IoTSensor <|-- SuspensionStrainGauge
  

Derivative 4.3: Blockchain for Immutable E-Key Auditing (Rental & Fleet)

• Enabling Description: Every e-key issuance, modification, revocation, and vehicle usage event is recorded as a transaction on a private, permissioned blockchain (e.g., Hyperledger Fabric). The server, the vehicle, and the owner's/recipient's devices are all nodes on this network. When an e-key is generated, a smart contract is created on the blockchain that codifies the conditions of use. The vehicle's TCU directly writes telemetry data (signed with its private key) to the blockchain. This creates an immutable, non-repudiable audit trail. This is particularly useful for rental companies to resolve disputes over speeding fines, damages (by correlating accelerometer data with a specific time), or unauthorized usage. The "warning notification" is also a transaction on the chain, providing proof that the user was alerted.

  sequenceDiagram
      participant User
      participant RentalServer
      participant Blockchain
      participant Vehicle
  
      User->>RentalServer: Request E-Key
      RentalServer->>Blockchain: Deploy SmartContract(Conditions)
      RentalServer->>User: Send E-Key (references SmartContract)
      User->>Vehicle: Present E-Key
      Vehicle->>Blockchain: Query SmartContract(Conditions)
      loop While Driving
          Vehicle->>Blockchain: WriteTransaction(Signed Telemetry)
      end
      Vehicle->>Blockchain: DetectViolation()
      Blockchain->>RentalServer: Emit ViolationEvent
      RentalServer->>User: Send Warning Notification
  

5. The "Inverse" or Failure Mode

Derivative 5.1: Fail-Secure "Limp Home" Mode

• Enabling Description: If the vehicle detects a potential security breach of the e-key system (e.g., GPS spoofing, repeated failed authentication attempts, or loss of heartbeat signal from the server for an extended period), it enters a "Limp Home" mode. In this state, functionality is severely restricted based on a pre-loaded policy. For example, the engine power is reduced to 25%, the maximum speed is capped at 30 km/h, the infotainment system is disabled (displaying only a "Security Alert" message), and the climate control is turned off. The vehicle will only permit travel towards a pre-defined "safe address" (e.g., the owner's home or a registered dealer service center), using its last known valid GPS location to determine the correct direction. Any deviation from this route will cause the vehicle to safely coast to a stop and engage its hazard lights.

  stateDiagram-v2
      state "Normal Operation" as Normal
      state "Limp Home Mode" as Limp
      state "Secure Shutdown" as Shutdown
  
      [*] --> Normal
      Normal --> Limp: Security Breach Detected
      Limp --> Limp: Driving towards Safe Zone
      Limp --> Shutdown: Deviates from Safe Route
      Limp --> Normal: Owner remotely authenticates & resets
      Shutdown --> [*]: Manual override by technician
      note right of Limp
          - Max speed: 30 km/h
          - Engine Power: 25%
          - Infotainment: Disabled
          - Route: Locked to Safe Zone
      end note
  

Combination Prior Art Scenarios

1. Combination with OAuth 2.0: The process of granting an e-key is implemented using the OAuth 2.0 Authorization Code Grant flow. The vehicle owner's app acts as the Resource Owner. The vehicle itself is the Resource Server. The server from the '715 patent is the Authorization Server. The recipient's app is the Client. The "e-key" is an access token with custom scopes corresponding to vehicle functions (door:unlock, engine:start) and claims encoding the usage conditions (max_speed:80, geo_fence:polygon(...)). This combines the method of the '715 patent with a widely-used, open standard for delegated authorization, making the implementation obvious to any software engineer familiar with web security.

2. Combination with MQTT (Message Queuing Telemetry Transport): The communication between the server, vehicle, and recipient's device is performed over an MQTT message broker, a standard ISO/IEC 20922 protocol for IoT. The vehicle subscribes to a topic like vehicle/[VIN]/commands. The server publishes e-key authorizations and condition updates to this topic. The vehicle publishes its telemetry to vehicle/[VIN]/telemetry. The recipient's device is granted temporary publish rights to vehicle/[VIN]/user_actions. This combination uses an open-source, lightweight pub/sub protocol to achieve the data transmission steps of the '715 patent, representing a standard and obvious design pattern for IoT device management.

3. Combination with W3C Verifiable Credentials (VC): The e-key is structured as a W3C Verifiable Credential. The server (Issuer) issues a VC to the recipient (Holder). The VC contains claims about the granted permissions (e.g., canOperateVehicle: "VIN123") and nested evidence defining the conditions (validFrom, validUntil, maxSpeed). The recipient's device stores this VC in a digital wallet and presents it to the vehicle (Verifier) as a Verifiable Presentation. The vehicle can then cryptographically verify the issuer's signature and the credential's integrity without a live connection to the server. This combines the method of the '715 patent with an open standard for decentralized identity, making the e-key a portable, interoperable, and self-verifiable piece of data.