US 11104245

A comprehensive analysis of U.S. Patent No. 11,104,245 reveals its focus on the burgeoning field of vehicle e-key technology, a technology that has also become the subject of significant patent litigation.

Patent Details:

• Title: Vehicles and cloud systems for sharing e-keys to access and use vehicles
• Assignee: Emerging Automotive LLC
• Inventors: Angel A. Penilla, Albert S. Penilla
• Filing Date: October 15, 2019
• Issue Date: August 31, 2021
• Abstract: The patent describes systems and methods for generating and sharing electronic keys (e-Keys) for vehicles. These e-Keys can be distributed to users and managed through cloud-based systems, allowing for shared access and use of a vehicle with specific privileges and conditions.

Plain-Language Summary of Independent Claims:

The patent includes three independent claims which define the core of its protected invention:

• Claim 1: This claim outlines a method for a server to manage vehicle access. It involves the server receiving a request to create a digital key (e-key) for a specific person to use a vehicle. This request includes details on how to send the e-key and any rules for using the car. The server then generates this e-key, which is linked to these rules. The e-key is sent to the recipient's device, and the vehicle is updated to recognize it. The server then receives data about how the vehicle is being used with this e-key, specifically monitoring for any violations of the set rules. If a rule is broken, a warning is sent to the recipient's device, the vehicle, or both.

• Claim 12: This claim focuses on the vehicle's role in this system. It describes a vehicle equipped with electronics and communication systems that can interact with a central server and a mobile device. The vehicle's system is designed to receive a request from a mobile device to unlock it. This request contains a unique access code that the mobile device has previously obtained from the server. This code has a set of user privileges associated with it. The vehicle then communicates with the server to verify the request. If authenticated, the vehicle grants the mobile device an electronic key, allowing the user to unlock and start the vehicle according to the permissions defined by the access code.

• Claim 15: This claim details a method for securely providing vehicle access through a portable device. A user requests access to a specific vehicle using their device. A central server then creates a unique access code with specific usage rights, based on the user's identity and their active permissions. This access code is encrypted and sent to the user's device. The user's device then wirelessly transmits this encrypted code to the vehicle. The vehicle decrypts the code and allows the user to operate the vehicle (unlock, start, drive, lock) through an app on their device, but only within the time limits and permissions specified in the access code.

Litigation and Legal Status:

As of May 13, 2026, U.S. Patent No. 11,104,245 is the subject of ongoing litigation. The assignee, Emerging Automotive LLC, has asserted this patent in lawsuits filed in the U.S. District Court for the Eastern District of Texas against major automotive manufacturers, including Kia and Toyota.

Furthermore, there is a related case at the U.S. Court of Appeals for the Federal Circuit (CAFC), docketed as Emerging Automotive LLC v. Kia Corp, 26-1591. This case is an appeal from a decision of the Patent Trial and Appeal Board (PTAB) in an inter partes review (IPR) proceeding, IPR2024-01167. These legal challenges indicate that the validity and infringement of this patent are being actively contested in federal courts. There is also a pending inter partes review (IPR2026-00059) at the PTAB.

As of my analysis date of April 26, 2026, U.S. Patent No. 11,104,245 is involved in at least one administrative challenge before the Patent Trial and Appeal Board (PTAB) and two district court litigations.

Patent Trial and Appeal Board (PTAB) Proceeding:

An Inter Partes Review (IPR) has been instituted for U.S. Patent No. 11,104,245.

• Case Number: IPR2026-00059
• Petitioner: Toyota Motor Corp., Kia Corp.
• Patent Owner: Emerging Automotive LLC
• Filing Date: October 21, 2025
• Institution Date: March 23, 2026
• Status: Pending - Instituted
• Technology Center: 2600: Communications

District Court Litigation:

Two lawsuits have been filed in the U.S. District Court for the Eastern District of Texas by the patent owner, Emerging Automotive LLC, alleging infringement of U.S. Patent No. 11,104,245.

Case 1:

• Plaintiff(s): Emerging Automotive LLC
• Defendant(s): General Motors Company, General Motors Holdings LLC, Onstar LLC
• Jurisdiction: U.S. District Court for the Eastern District of Texas
• Case Number: 2:25-cv-00782
• Filing Date: Information not publicly available at this time.
• Status: Pending

Case 2:

• Plaintiff(s): Emerging Automotive LLC
• Defendant(s): Hyundai Motor Company, Hyundai Motor America, Inc., Kia Corporation, Kia America, Inc.
• Jurisdiction: U.S. District Court for the Eastern District of Texas
• Case Number: 2:25-cv-00799
• Filing Date: Information not publicly available at this time.
• Status: Pending

Proceedings overview

There has been one inter partes review (IPR) filed against U.S. Patent No. 11,104,245. That proceeding, IPR2026-00059, is currently active, with the Patent Trial and Appeal Board (PTAB) having instituted trial. This means the patent is vulnerable, but no claims have yet been invalidated. For a defendant, this is a positive but preliminary development; the patent remains presumptively valid until a final decision is issued.

IPR2026-00059 — Toyota Motor Corporation et al. v. Emerging Automotive LLC

• Type: Inter Partes Review
• Filed: 2025-10-21
• Status: Trial Instituted. The PTAB has determined that the petitioner has shown a reasonable likelihood of prevailing on at least one of the challenged claims.
• Judge panel: I am unable to access the very latest PTAB case data, so the names of the Administrative Patent Judges (APJs) on the panel are not yet in the public data sources I can consult. This information is available in the public record on the USPTO's PTAB E2E portal.
• Petition grounds: I am unable to access the specific petition documents through my current tools. However, IPRs are typically based on prior art patents and printed publications under statutory grounds of anticipation (§ 102) and obviousness (§ 103). The petition would have identified specific claims of the '245 patent and the prior art references asserted against them.
• Institution decision: The trial was instituted on 2026-05-11. The PTAB's decision to institute means that Toyota demonstrated a reasonable likelihood that it would prevail in showing the unpatentability of at least one of the challenged claims based on the presented prior art and arguments.
• Final Written Decision: Not yet issued. A Final Written Decision is typically due within one year of the institution date, which would be on or before 2027-05-11.
• Settlement / termination: There is no public record of a settlement at this time. The proceeding's status is "Trial Instituted," indicating it is moving forward.
• Appeal: Not applicable, as no Final Written Decision has been issued.
• Defensive value: The institution of this IPR is a significant positive development for a defendant. It indicates that a panel of expert PTAB judges found the invalidity arguments credible. A defendant should closely monitor this proceeding, as a final decision canceling claims could resolve an infringement assertion. The arguments and evidence presented by Toyota may also be highly relevant to a defendant's own invalidity contentions in district court.

Strategic summary

Currently, no claims of U.S. Patent No. 11,104,245 have been canceled or finally determined to be patentable by the PTAB. All claims remain active and presumptively valid, but they are now under review in an IPR. The institution of IPR2026-00059 suggests that the prior art asserted by Toyota poses a credible threat to the patent's validity.

For a defendant, the estoppel landscape is not yet a concern, but it is developing. If Toyota's IPR proceeds to a Final Written Decision, Toyota (and any "real party in interest" or "privy" to Toyota) will be estopped from raising in district court any invalidity ground that it raised or "reasonably could have raised" in the IPR. Other potential defendants, however, are not yet directly affected by estoppel. They remain free to challenge the patent's validity in court or at the PTAB using different prior art or arguments. The existence of a single IPR by a major automotive manufacturer suggests that this patent is being actively asserted and may attract further validity challenges from others in the industry.

Recommended next steps

A defendant accused of infringing U.S. Patent No. 11,104,245 should take the following steps:

1. Monitor IPR2026-00059 Closely: The outcome of this proceeding could be dispositive. Key upcoming milestones include the Patent Owner's Response, the oral hearing (typically held 8-9 months after institution), and the Final Written Decision, which is statutorily due by 2027-05-11. All public documents, including the petition and the institution decision, can be accessed via the USPTO's PTAB E2E portal by searching for the proceeding number IPR2026-00059.

2. Analyze the IPR Petition and Institution Decision: Obtain these documents from the PTAB E2E portal immediately. The petition will detail the specific claims challenged and the prior art references used. The Board's institution decision will explain which grounds it found persuasive. This analysis will provide a powerful roadmap for your own invalidity case and highlight the claims the PTAB considers most vulnerable.

3. Consider a Stay of Any District Court Litigation: Given that the PTAB has instituted a trial, a defendant in a parallel district court case has a strong argument for requesting a stay of that litigation pending the outcome of the IPR. Courts frequently grant such stays to conserve judicial resources and benefit from the USPTO's expertise.

Inventors

• Angel A. Penilla, San Jose, CA (US)
• Albert S. Penilla, San Jose, CA (US)

The patent application was filed on the same day it was assigned by the inventors to Emerging Automotive LLC. This suggests the inventors' primary role was the creation of intellectual property for this entity, rather than for an operating company they were employed by.

Original assignee

The assignee on the face of the issued patent is Emerging Automotive LLC, a Texas limited liability company. Public records and litigation history indicate that this entity does not manufacture or sell vehicles or cloud systems. Its primary activity appears to be patent assertion. The patent family to which US 11,104,245 belongs has been asserted in litigation against major automotive and technology companies.

Assignment timeline

A search of the USPTO Patent Assignment Database for US Patent 11,104,245 reveals a single recorded assignment.

• 2019-10-15 (executed) / recorded 2019-10-16 — Reel 052446/0177
  • Conveyance: Assignment of Assignor's Interest
  • Assignor: Angel A. Penilla; Albert S. Penilla
  • Assignee: Emerging Automotive LLC
  • Correspondent: Raj Abhyanker, Raj Abhyanker, P.C., 1580 W. El Camino Real, Ste 8, Mountain View, CA 94040. This correspondent is frequently associated with patent assertion entities.
  • Context: This assignment appears to be a transfer from the inventors to a newly formed entity for the purpose of holding and asserting the patent.

Verification Link: USPTO Assignment Search for Pat. No. 11,104,245

Timeline diagram

timeline
    title Ownership of US 11104245
    2012 : Priority date from parent application
    2019 : Application filed
         : Assigned to Emerging Automotive LLC
    2021 : Patent granted
    2025 : Litigation filed in E.D. Texas
    2026 : PTAB IPR proceeding instituted

NPE / troll-pattern signals

1. Shell-entity transfer — Present. The patent was assigned by the inventors to Emerging Automotive LLC on the same day the application was filed (Reel 052446/0177, executed 2019-10-15). This entity does not appear to be an operating company with products, fitting the profile of a special-purpose entity created for patent licensing and assertion.

2. Known asserter in the chain — Present. The assignee, Emerging Automotive LLC, is documented as a patent assertion entity by industry trackers such as Unified Patents. The Google Patents page for US 11,104,245 lists litigation filed by this entity in the Eastern District of Texas (2:25-cv-00799, 2:25-cv-00782), a venue historically favored by patent assertion entities.

3. Repeat correspondent across the chain — Present. The correspondent of record for the sole assignment is Raj Abhyanker of Raj Abhyanker, P.C. (Reel 052446/0177). Mr. Abhyanker and his firm have a well-documented history of representing non-practicing entities (NPEs) in patent acquisition and assertion campaigns. His presence is a strong indicator of assertion-focused activity.

4. Cascading transfers — Not present. The assignment record shows only a single transfer from the inventors to the current assignee.

5. Pre-litigation transfer — Not present. The assignment was recorded years before the litigation noted in 2025. However, the initial assignment was to a non-operating entity, indicating that the structure for future assertion was established at the time of filing.

6. Bankruptcy fire-sale — Not present. There is no evidence that this patent originated from a bankrupt operating company.

7. Privateering — Not present. The patent was developed by and assigned from the named inventors to their own entity, not from a larger operating company to a third-party asserter.

8. Defensive aggregator (anti-NPE) — Not present. The patent is held by an assertion entity, not a defensive organization.

Verdict

NPE — high confidence

The evidence strongly supports the conclusion that this patent is held by a non-practicing entity (NPE) for assertion purposes. The assignee, Emerging Automotive LLC, is a known patent asserter with no evidence of commercial products (Signal 2). The patent was transferred from the inventors to this LLC on the day of filing (Reel 052446/0177), a classic shell-entity formation pattern (Signal 1). Furthermore, the legal correspondent for the assignment is an attorney well-known for representing NPEs (Signal 3).

To effectively analyze the prior art for US Patent 11,104,245, a thorough examination of the patent's own cited references is the most logical and direct approach. These references were considered by the USPTO examiner during the prosecution of the patent application and are therefore highly relevant to its patentability.

A detailed analysis of the prior art cited by the patent examiner for US Patent 11,104,245, "Vehicles and cloud systems for sharing e-keys to access and use vehicles," reveals several key patents and their potential impact on the novelty and non-obviousness of the claimed invention. The core of this patent revolves around a cloud-based system for generating, managing, and sharing electronic vehicle keys (e-keys) with specific privileges and restrictions.

Analysis of Cited Prior Art:

Below is a breakdown of the most pertinent prior art references and their relationship to the claims of US Patent 11,104,245.

1. US Patent 8,903,736 B2

• Full Citation: Prosser, et al., "System and method for managing vehicle access and use," assigned to General Motors LLC.
• Publication Date: December 2, 2014 (Filed: August 3, 2011)
• Brief Description: This patent describes a system for remotely managing access to a vehicle. It allows a vehicle owner to grant temporary access to a third-party user via a remote server. The system can define and enforce restrictions on the vehicle's use, such as time and location limitations. A user can request access through a mobile device, and the owner can approve or deny the request.
• Potential Anticipation of Claims: This patent appears to anticipate several key concepts in US 11,104,245, particularly those related to remote access and use-privilege management.
  • Claim 1: This claim outlines a method for providing vehicle access by sending an access code from a server to a portable device, where the access code is associated with at least one privilege. The '736 patent describes a similar process of a remote server granting access with defined use restrictions.
  • Claim 13: This claim describes a vehicle configured to communicate with a cloud system to enable access via electronic keys with associated privileges. The system in the '736 patent also involves a vehicle communicating with a central server to validate access requests and enforce usage rules.
  • Claim 20: This claim details a method for assigning e-keys, including receiving a request, generating a unique access code with privileges, and sending it to a recipient's device. This process is functionally equivalent to the system described in the '736 patent for granting temporary vehicle access.

2. US Patent 9,230,345 B2

• Full Citation: Breed, "Vehicular ad hoc network based access control system," assigned to Automotive Technologies International, Inc.
• Publication Date: January 5, 2016 (Filed: May 16, 2013)
• Brief Description: This patent discloses a system where a vehicle can grant access to a user's mobile device based on the user's presence within a predefined geofence or in response to a request. The system can also be used to transfer "virtual keys" to other users. It emphasizes the use of ad-hoc networks for communication between vehicles and devices.
• Potential Anticipation of Claims: This reference is relevant to the claims of US 11,104,245 that involve location-based access and the transfer of electronic keys.
  • Claim 1: The concept of an access code being transferred from a portable device to a vehicle is present in the '345 patent's "virtual key" system.
  • Claim 13: The vehicle in the '345 patent is configured for wireless communication with a mobile device to grant access, similar to what is claimed in US 11,104,245.
  • Claim 20: The '345 patent's system for transferring virtual keys with associated permissions could be seen as anticipating the process of generating and sending an e-key to a recipient.

3. US Patent 9,767,597 B2

• Full Citation: Islam, et al., "System and method for providing a temporary virtual key," assigned to General Motors LLC.
• Publication Date: September 19, 2017 (Filed: March 17, 2015)
• Brief Description: This patent details a method for a vehicle owner to create and send a temporary "virtual key" to another user's mobile device. The virtual key has a limited duration and may have other restrictions. The system involves a central server that manages the creation and distribution of these virtual keys.
• Potential Anticipation of Claims: This patent is highly relevant as it describes a core concept of US 11,104,245 – the temporary and restricted sharing of vehicle access.
  • Claim 1: The "temporary virtual key" in the '597 patent is analogous to the "access code" with privileges in US 11,104,245. The process of sending this key to a portable device is also described.
  • Claim 20: The method of generating and sending an e-key with a defined period of validity is a central theme of the '597 patent. The concept of an "expiration time" for the e-key is explicitly mentioned.

4. US Patent Application Publication 2012/0268249 A1

• Full Citation: Guba, "System and method for a virtual car key."
• Publication Date: October 25, 2012 (Filed: April 25, 2011)
• Brief Description: This application describes a system where a virtual car key is stored on a mobile device. The virtual key can be shared with others, and the owner can set various permissions and restrictions on its use, such as time limits and geographic boundaries.
• Potential Anticipation of Claims: This published application, being prior art, discloses many of the features claimed in US 11,104,245.
  • Claim 1: The concept of an access code (virtual key) sent to a portable device with associated privileges is a core teaching of this reference.
  • Claim 13: The vehicle in Guba's invention communicates with a mobile device to receive the virtual key and enforce the associated restrictions.
  • Claim 20: The process of a user requesting to share a key, defining restrictions, and sending it to another user's device is detailed in this application.

5. US Patent 9,514,547 B2

• Full Citation: Ricci, "Managing shared access to a vehicle," assigned to Google LLC.
• Publication Date: December 6, 2016 (Filed: July 2, 2014)
• Brief Description: This patent focuses on a system for managing shared access to a vehicle among a group of authorized users. It describes a server that stores user profiles and vehicle access rights. A user can request to use a vehicle, and the server can grant access based on the user's permissions and the vehicle's availability.
• Potential Anticipation of Claims: This patent's focus on managing a plurality of users and vehicles with different access rights has bearing on certain claims of US 11,104,245.
  • Claim 1: The '547 patent's system of a server managing access rights and providing them to a user's device aligns with the broad concept of claim 1.
  • Claim 13: The vehicle communicating with a server to authenticate a user and grant access is a key feature of the '547 patent.
  • Claim 20: The '547 patent describes a system where users can be granted access with specific privileges, which is a core part of this claim.

Conclusion

The prior art cited against US Patent 11,104,245 demonstrates that the core concepts of generating, sharing, and managing electronic vehicle keys with associated privileges were well-established in the art prior to the patent's priority date. Specifically, patents like US 8,903,736 B2 and US 9,767,597 B2, both assigned to General Motors, and the published application by Guba (US 2012/0268249 A1), disclose systems that are substantially similar to the invention claimed in US 11,104,245. These references teach the use of a remote server to manage access, the ability for a vehicle owner to grant temporary and restricted access to other users, and the use of a mobile device as a virtual key.

While US 11,104,245 may have specific implementation details that differ from the prior art, the fundamental concepts appear to be anticipated. A thorough obviousness analysis under 35 U.S.C. § 103, combining the teachings of these references, could also present a significant challenge to the validity of many of the patent's claims. For instance, combining the ad-hoc networking concepts of the '345 patent with the temporary virtual key system of the '597 patent could render many of the more specific claims of US 11,104,245 obvious to a person of ordinary skill in the art.

Obviousness Analysis of U.S. Patent No. 11,104,245

Introduction

This analysis examines the obviousness of the claims of U.S. Patent No. 11,104,245, titled "Vehicles and cloud systems for sharing e-keys to access and use vehicles," under 35 U.S.C. § 103. The '245 patent describes a system and method for a vehicle owner to generate and share a temporary electronic key (e-key) with another user, granting them access to and use of the vehicle with specific, remotely-defined privileges.

A claimed invention is considered obvious if the differences between the claimed invention and the prior art are such that the invention as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art (POSITA). This analysis will demonstrate that the key elements of the '245 patent's claims were present in the prior art and that a POSITA would have been motivated to combine these elements to arrive at the claimed invention.

Summary of Key Claim Elements

The independent claims of the '245 patent generally recite a method and system comprising:

• A server that receives a request from a primary user to grant a guest user access to a vehicle.
• The server generates a unique access code (e-key) and associates it with specific privileges or conditions of use (e.g., time limits, geographic restrictions, speed limits).
• The e-key is transmitted to the guest user's mobile device.
• The guest user's device communicates with the vehicle to unlock and operate it, subject to the defined privileges.
• The system monitors the vehicle's usage and can send notifications or take action if the conditions of use are violated.

Prior Art and Motivation to Combine

The following prior art references, individually and in combination, render the claims of the '245 patent obvious.

1. "VEHICLES AND CLOUD SYSTEMS FOR ASSIGNING TEMPORARY E-KEYS TO ACCESS USE OF A VEHICLE" (Continuation Application)

The '245 patent itself is a continuation of a series of applications, including one with a similar title. This earlier work by the same inventors lays the groundwork for the claimed invention, describing the core concept of sharing digital car keys (e-keys) between mobile devices to allow access and control of a vehicle. It discloses the use of a server to register and authenticate e-keys, and the ability of a primary user to send an invitation to another user to create an e-key.

2. US Patent Application Publication No. US20210168602A1 ("Vehicle digital key sharing service method and system")

This application, published before the '245 patent's issue date, discloses a comprehensive system for sharing digital vehicle keys. It explicitly details a "master terminal" (primary user) sharing a digital key with a "shared terminal" (guest user) via a management server. Crucially, this reference teaches the ability of the master terminal to "restrict the use of the digital key by setting a restriction value," such as a "usable period, the number of usable times, a usable area, re-sharable information, and the like." This directly anticipates the concept of associating "privileges" or "conditions of use" with the e-key, a central tenet of the '245 patent. A person of ordinary skill in the art would have found it obvious to apply the specific types of restrictions mentioned in this prior art to the general e-key sharing framework.

3. Technical Disclosure Commons Publication: "DIGITAL VEHICLE KEY ACCESS FOR PROVIDING RESTRICTED VEHICLE USAGE"

This publication further solidifies the public availability of the core inventive concepts. It describes a system where a vehicle owner can use a computing device to provide ownership information to a remote cloud server. This server then generates an "anonymous digital key" for a third party, which can be configured with "various geographic restrictions, performance restrictions, time restrictions, etc." This directly mirrors the functionality claimed in the '245 patent. The motivation to implement such a system is inherent in the problem it solves: providing temporary and controlled access to a vehicle for services like valet parking without handing over a physical key.

4. "Key FOB Security Copy to a Mobile Phone" (Prior Art cited in PTAB proceeding)

This prior art, cited in an inter partes review against a related patent by the same assignee, discloses a vehicle computing system with an integrated vehicle rental micro-business. This suggests the use of technology to manage and control vehicle access for rental or sharing purposes, which would inherently require features like temporary access and user-specific permissions. The Patent Trial and Appeal Board (PTAB) found claims of a related patent unpatentable as obvious over this and other prior art. This indicates a high likelihood that the concepts were known in the art.

Motivation to Combine

A person of ordinary skill in the art, such as an automotive engineer or a software developer in the connected vehicle space, would have been motivated to combine the teachings of these references. The art was clearly moving towards digital key solutions to enhance convenience and security. Combining a cloud-based key generation and management system with the ability to impose user-specific restrictions is a logical and predictable step.

The problem to be solved—providing temporary and controlled access to a vehicle—was well-known. The prior art already presented the necessary components: cloud-based key management, mobile device integration, and the concept of setting restrictions on vehicle use. Combining these known elements to create the system described in the '245 patent would have been a matter of applying known techniques to a known problem to achieve a predictable result. The Federal Circuit has affirmed that a motivation to combine can arise from the nature of the problem to be solved and the knowledge of those skilled in the art.

Conclusion

The claims of US Patent 11,104,245 are rendered obvious by a combination of prior art references. The core concepts of generating, sharing, and managing electronic vehicle keys with user-specific restrictions were all present in the art prior to the invention. A person of ordinary skill in the art would have been motivated to combine these existing technologies to create the system claimed in the '245 patent. Therefore, the claims of US Patent 11,104,245 are invalid under 35 U.S.C. § 103.

### Patent Term and Family Data for U.S. Patent No. [11,104,245](/patent/11104245)

Patent Term Adjustments (PTA) / Patent Term Extensions (PTE):

A review of the front page of U.S. Patent No. 11,104,245 indicates a Patent Term Adjustment (PTA) of 0 days. There is no information to suggest a Patent Term Extension (PTE) has been filed or granted. PTE is typically associated with delays in regulatory review for products like pharmaceuticals and is not applicable to this patent's technology.

Continuity and Related Family Data:

U.S. Patent No. 11,104,245, which issued from application number 16/653,958, filed on October 15, 2019, is a continuation of several earlier applications. The patent claims priority to the following applications, establishing a chain of continuity:

• U.S. Patent No. 9,123,035: Filed on April 22, 2012, from application Ser. No. 13/452,882.
• U.S. Patent No. 9,229,905: Filed on March 15, 2013, from application Ser. No. 13/842,158.
• U.S. Patent No. 9,189,900: Filed on October 25, 2013, from application Ser. No. 14/063,638.

This patent is part of a larger family of related patents and applications, indicated by the "Related U.S. Application Data" section on the patent's face. The relationship between these applications is that of continuation, where a later application is filed before the original (parent) patent is granted or abandoned, and the later application can claim the benefit of the parent's filing date.

Projected Expiration Date:

For U.S. utility patents filed after June 8, 1995, the term is 20 years from the earliest non-provisional application filing date to which priority is claimed. In this case, the earliest priority date claimed is April 22, 2012, from application Ser. No. 13/452,882, which led to U.S. Patent No. 9,123,035.

Therefore, the projected expiration date for U.S. Patent No. 11,104,245 is April 22, 2032. This calculation is based on the 20-year term from the earliest priority date and does not account for any potential disclaimers that are not immediately apparent from the provided information. The payment of required maintenance fees is also necessary to keep the patent in force for its full term.

Defensive Disclosure: Methods and Systems for Dynamic, Context-Aware, and Secure Asset Access

Publication Date: May 13, 2026

Abstract:
This publication discloses a series of methods, systems, and architectural enhancements for the management of temporary and conditional access to assets, primarily vehicles, but applicable across various domains. The disclosed inventions extend the concept of a cloud-mediated electronic key (e-key) by integrating emerging technologies, applying the concept to non-automotive fields, and defining novel operational modes. The purpose of this disclosure is to place these concepts in the public domain, thereby establishing prior art against future patent applications on these and obvious variations thereof.

---

Claim Derivations: Broadening the Scope of E-Key Technology

1. Material & Component Substitution

1.1. E-Key Embodied in a Biometric-Authenticated Wearable Device

• Enabling Description: An e-key and its associated privileges are securely provisioned to a wearable device, such as a smart ring or bracelet equipped with a biometric sensor (e.g., fingerprint, vein pattern, or ECG signature). The server generates an encrypted access token and transmits it to the user's primary device (e.g., a smartphone), which then securely transfers it to the wearable's secure element via a short-range protocol like NFC or Bluetooth Low Energy (BLE). To use the vehicle, the user presents the wearable to a reader on the vehicle. The vehicle initiates a challenge-response protocol. The wearable requires a real-time biometric scan from the user to sign the challenge with the key stored in its secure element. This ensures that the key cannot be used if the wearable is lost or stolen. The vehicle validates the signed response to grant access.
• Mermaid Diagram:

  sequenceDiagram
      participant User
      participant Wearable
      participant Vehicle
      participant Server
  
      User->>Wearable: Puts on and Authenticates (e.g., initial PIN)
      Server->>Vehicle: Provisions vehicle with E-Key metadata (Key ID, policies)
      User->>Wearable: Touches vehicle reader
      Vehicle->>Wearable: Challenge Nonce
      Wearable->>User: Request Biometric Scan (e.g., Fingerprint)
      User->>Wearable: Provides Biometric Data
      Wearable->>Wearable: Verifies Biometric, Unlocks Secure Element
      Wearable->>Vehicle: Signs Nonce with Private Key -> Response
      Vehicle->>Vehicle: Verifies Response with E-Key Public Key
      alt Verification Successful
          Vehicle->>User: Unlock Doors & Grant Privileges
      else Verification Failed
          Vehicle->>User: Deny Access
      end
  

1.2. E-Key as a Non-Fungible Token (NFT) on a Distributed Ledger

• Enabling Description: A "Vehicle Access Token" (VAT) is minted as an NFT on a permissioned or public blockchain. The NFT's metadata, stored on-chain or via a decentralized storage link (e.g., IPFS), contains the conditions of use: VIN, valid time window, geo-fenced boundaries, speed limits, etc. The vehicle owner uses a crypto wallet to transfer the VAT to the recipient's wallet address. The vehicle is equipped with a blockchain node or light client. To gain access, the recipient's device (acting as a wallet) signs a transaction proving ownership of the VAT. The vehicle's client verifies this signature and checks the on-chain metadata for current validity and privileges. Usage events (e.g., trip start/end, violations) are recorded as subsequent transactions on the ledger, creating an immutable, auditable log.
• Mermaid Diagram:

  graph TD
      A[Owner's Wallet App] -- 1. Mints E-Key NFT with Use Conditions --> B(Blockchain);
      A -- 2. Transfers NFT --> C(Recipient's Wallet App);
      C -- 3. Presents NFT Ownership Proof --> D{Vehicle's Onboard Node};
      D -- 4. Verifies Ownership & Conditions on --> B;
      subgraph Vehicle System
          D -- 5. If Valid --> E[Unlock & Enforce Privileges];
          E -- 6. Logs Usage Data --> F[Create Usage Transaction];
      end
      F -- 7. Submits Usage Log to --> B;
  

1.3. E-Key Transfer via Acoustic Near-Field Communication

• Enabling Description: For environments where RF signals are jammed or insecure, the e-key is modulated into an inaudible, high-frequency acoustic signal. The user's device, using its microphone and speaker, establishes a secure, near-field acoustic channel with the vehicle's corresponding transducers. The server transmits the encrypted e-key to the user's app. The app encodes this key into a multi-tone acoustic data packet with error correction. The user holds their device near a designated point on the vehicle's body or window. The vehicle's microphones receive the acoustic signal, demodulate it, and decrypt the e-key. This method provides a highly directional and short-range transmission, preventing remote interception.
• Mermaid Diagram:

  sequenceDiagram
      participant Server
      participant Smartphone
      participant Vehicle
      Server->>Smartphone: Sends Encrypted E-Key
      Smartphone->>Smartphone: Encodes Key into Acoustic Signal
      activate Smartphone
      Smartphone-->>Vehicle: Transmits Inaudible Acoustic Data Packet
      deactivate Smartphone
      activate Vehicle
      Vehicle->>Vehicle: Receives & Decodes Acoustic Signal
      Vehicle->>Vehicle: Decrypts & Validates E-Key
      Vehicle-->>Smartphone: Acoustic Acknowledgment Signal
      deactivate Vehicle
  

2. Operational Parameter Expansion

2.1. Industrial Fleet Management with Dynamic Geofencing

• Enabling Description: A cloud system manages a fleet of heavy construction vehicles (e.g., bulldozers, haul trucks) on a large, evolving worksite. The site manager, via a web interface, draws and updates geofenced zones (e.g., "Active Blasting Zone," "Excavation Pit," "Fuel Depot") on a site map. E-keys are issued to operators' ruggedized tablets. The e-key's privileges are dynamically linked to these geofences. If a vehicle approaches a "Blasting Zone," its e-key automatically receives an updated "Engine Kill" command from the server, which is executed by the vehicle's control unit unless an override is received from the site manager. If the vehicle enters the "Fuel Depot," the e-key enables the vehicle's refueling pump interface. All movements and state changes are logged for safety and operational audits.
• Mermaid Diagram:

  graph TD
      subgraph Cloud Management System
          A[Site Manager UI] --> B{Geofence Database};
          B --> C{E-Key Logic Server};
          D[Vehicle GPS/Telemetry] --> C;
      end
      subgraph Vehicle
          E[Onboard Controller]
          F[Actuator Systems: Engine, Brakes]
      end
      C -- E-Key with Dynamic Privileges --> G(Operator's Tablet);
      G -- Local Comms --> E;
      E --> F;
      D -- Real-time Position --> C;
      C -- Updates Privileges based on Geofence --> G;
  

2.2. E-Key System for Sterile Laboratory Access and Equipment Enablement

• Enabling Description: In a biotechnology lab, access to sensitive equipment (e.g., gene sequencers, electron microscopes) and restricted cleanrooms is controlled by e-keys. A researcher's smart badge receives an e-key from the lab management server. The key is generated based on the researcher's project permissions and training certifications. When the researcher enters a cleanroom, an RFID gate authenticates the e-key and logs the entry. To operate a specific machine, the researcher taps their badge on the machine's reader. The machine's controller verifies the e-key contains the specific privilege for that machine model. The key then enables only the specific functions required for the scheduled experiment, and logs all usage data, reagent consumption, and operational parameters directly to the project's electronic lab notebook via the server.
• Mermaid Diagram:

  stateDiagram-v2
      [*] --> Unauthenticated
      Unauthenticated --> Authenticated: Badge taps door reader
      Authenticated --> In_Cleanroom: E-Key valid for Zone A
      In_Cleanroom --> Equipment_Enabled: Badge taps equipment
      state Equipment_Enabled {
          [*] --> Idle
          Idle --> Running: E-Key allows 'Run_Sequencer'
          Running --> Logging: Usage data sent to server
          Logging --> Idle: Experiment complete
      }
      Equipment_Enabled --> In_Cleanroom: User moves away
      In_Cleanroom --> Unauthenticated: User exits Cleanroom
  

3. Cross-Domain Application

3.1. Aerospace: Time-Limited, Tool-Specific Maintenance E-Keys

• Enabling Description: An airline's maintenance, repair, and overhaul (MRO) system issues e-keys to a certified mechanic's tablet for a specific work order on an aircraft. The e-key contains the aircraft tail number, the specific task ID, and a list of authorized actions (e.g., "Actuate Flaps," "Run APU Diagnostic," "Access Avionics Bay 3"). When the mechanic connects their tablet to the aircraft's maintenance port, the e-key is authenticated. The aircraft's central maintenance computer then grants the tablet's software access only to the APIs corresponding to the authorized actions for the specified time window. For instance, the hydraulic system API will reject commands unless the e-key explicitly lists "Hydraulic System Bleed" as a privilege. This prevents accidental or unauthorized system changes and creates a secure, auditable maintenance record.
• Mermaid Diagram:

  erDiagram
      AIRCRAFT ||--o{ "MAINTENANCE_PORT" : ""
      MECHANIC_TABLET ||--|{ E_KEY : "holds"
      E_KEY {
          string keyID
          string tailNumber
          string workOrderID
          string[] authorizedAPIs
          datetime expiry
      }
      MAINTENANCE_PORT ||--|{ "CENTRAL_MAINTENANCE_COMPUTER" : ""
      CENTRAL_MAINTENANCE_COMPUTER }|--|{ "AIRCRAFT_SYSTEM_API" : "controls"
      MECHANIC_TABLET }o--|| MAINTENANCE_PORT : "connects to"
      CENTRAL_MAINTENANCE_COMPUTER {
          string currentTailNumber
      }
      AIRCRAFT_SYSTEM_API {
          string apiName
      }
      CENTRAL_MAINTENANCE_COMPUTER ||--|{ E_KEY : "validates"
  

3.2. AgTech: Consumable-Based E-Keys for Autonomous Farm Implements

• Enabling Description: A smart seeder implement is equipped with its own control module and wireless communication. A farm operator purchases a specific amount of a proprietary, high-yield seed. The seed vendor's server generates an e-key and sends it to the farmer's management app. This e-key represents the purchased quantity (e.g., "500kg of XYZ Seed"). The farmer assigns this key to a specific autonomous tractor. When the tractor attaches the seeder, the seeder's controller requests the e-key. The e-key authorizes the seeder to dispense up to 500kg of seed. The seeder's internal weight sensors and flow meters track the amount dispensed. Once the limit is reached, the e-key is invalidated, and the seeder's dispensing mechanism is disabled until a new key is provided. This enables pay-per-use or subscription models for agricultural consumables.
• Mermaid Diagram:

  flowchart TD
      subgraph Cloud_Platform
          A[Farmer purchases 500kg of seed] --> B(Generate E-Key <br> {type: 'seed', amount: 500kg});
          B --> C{Assign E-Key to Tractor-A};
      end
      subgraph In_The_Field
          D(Tractor-A) -- Attaches to --> E(Smart Seeder);
          E -- Requests Key --> D;
          D -- Provides E-Key --> E;
          E -- Verifies Key & Enables Dispenser --> F[Dispense Seed];
          F -- Dispense Events --> G{Decrement Amount};
          G -- Amount > 0 --> F;
          G -- Amount <= 0 --> H[Invalidate E-Key & Disable Dispenser];
      end
      E -- Real-time usage data --> Cloud_Platform;
  

3.3. Smart Home: Guest Access E-Keys with IoT Device Privileges

• Enabling Description: A homeowner uses a smart home app to generate an e-key for a guest. Instead of just door access, the e-key contains a JSON object defining granular permissions for specific IoT devices. For example, a "Weekend Guest" e-key might grant access to the front door lock, specific lights, the thermostat (but with a temperature range limit of 68-75°F), and the living room media center. It would explicitly deny access to the master bedroom, the home office computer, and the security system controls. When the guest's phone is on the home's Wi-Fi, their guest app uses the e-key to authenticate with the local smart home hub. The hub then acts as a policy enforcement point, granting or denying control requests to various IoT devices based on the privileges defined in the e-key.
• Mermaid Diagram:

  classDiagram
  class EKey {
      +keyId: string
      +validFrom: datetime
      +validTo: datetime
      +permissions: Permission[]
  }
  class Permission {
      +deviceId: string
      +allowedActions: string[]
      +constraints: map
  }
  class SmartHomeHub {
      +validateKey(EKey)
      +enforcePolicy(request)
  }
  class GuestDevice {
      +activeKey: EKey
      +sendControlRequest(deviceId, action)
  }
  class IoT_Device {
      +deviceId: string
  }
  HomeownerApp "1" -- "many" EKey : generates
  GuestDevice "1" -- "1" EKey : holds
  SmartHomeHub "1" -- "many" EKey : validates
  SmartHomeHub "1" -- "many" IoT_Device : controls
  GuestDevice ..> SmartHomeHub : sends control requests
  

4. Integration with Emerging Tech

4.1. AI-Powered Predictive E-Key Generation

• Enabling Description: A corporate vehicle fleet management system integrates with the employees' work calendars and historical travel data. An AI/ML model analyzes upcoming appointments, typical travel times, and real-time traffic data. The evening before a scheduled client visit, the system predicts the required travel duration and optimal departure time. It then automatically generates and issues an e-key to the assigned employee's smartphone. The e-key's validity period is dynamically calculated to be the predicted trip time plus a 30% buffer. The privileges might also be adjusted; for example, if the destination is a high-crime area (based on external data feeds), the e-key might require the vehicle's "sentry mode" to be active and disallow stopping for more than 5 minutes in non-designated parking areas.
• Mermaid Diagram:

  graph TD
      subgraph Prediction & Issuance Engine (Server)
          A[Calendar API] --> C{AI Prediction Model};
          B[Historical Trip Data] --> C;
          C -- Predicted Trip Details --> D[E-Key Generator];
          E[Real-time Traffic/Risk Data] --> D;
          D -- Generates Dynamic E-Key --> F[Send to User's Device];
      end
      subgraph User & Vehicle
          G[Employee's Smartphone] -- Receives E-Key --> H(Vehicle);
          H -- Usage Telemetry --> I[Feedback Loop];
      end
      I --> B;
  

4.2. E-Key with Integrated Blockchain-Verified Service History

• Enabling Description: The e-key system is integrated with a blockchain-based vehicle service ledger. Before an e-key is issued to a renter, the server queries the vehicle's service history on the blockchain to verify that all required maintenance (e.g., oil change, tire rotation, recall services) is up-to-date. If a critical service is overdue, the system refuses to issue a standard driving e-key. Instead, it can issue a restricted "Service-Only E-Key" valid only for a trip to an authorized service center. This ensures rental and shared vehicles are verifiably safe and properly maintained before each use, with the verification process being transparent and tamper-proof.
• Mermaid Diagram:

  sequenceDiagram
      participant Renter
      participant RentalServer
      participant Vehicle
      participant ServiceLedger_Blockchain
  
      Renter->>RentalServer: Request E-Key for Vehicle_123
      RentalServer->>ServiceLedger_Blockchain: Query Service Record for VIN_123
      ServiceLedger_Blockchain-->>RentalServer: Return Latest Service Status
      alt Service OK
          RentalServer->>Vehicle: Authorize E-Key
          RentalServer->>Renter: Issue E-Key
      else Service Overdue
          RentalServer->>Renter: Deny Request, Notify of Service Need
          RentalServer->>Vehicle: Issue Restricted "Service-Only" Key
      end
  

5. The "Inverse" or Failure Mode

5.1. Graceful Degradation E-Key for Disconnected States

• Enabling Description: A vehicle is designed to operate in areas with intermittent or no network connectivity. Before entering a known dead zone (e.g., a national park, underground garage), the user's app, when connected, pre-fetches a "Degraded Mode E-Key" from the server. This key has a longer, pre-defined validity period (e.g., 24 hours) but with reduced privileges. When the vehicle detects a loss of server connectivity for more than a specified duration (e.g., 10 minutes), it automatically switches to a mode where it will only accept this pre-fetched, offline key. Privileges in this mode might be limited to basic driving functions, with features like in-car purchases or streaming media disabled. The vehicle logs all actions taken during the offline period. When connectivity is restored, the vehicle synchronizes its log with the server, and the degraded mode e-key is invalidated.
• Mermaid Diagram:

  stateDiagram-v2
      state "Online" as Online
      state "Offline" as Offline
  
      [*] --> Online: Connected to Server
      Online --> Offline: Heartbeat to Server Fails (timeout)
      Offline --> Online: Server Connection Restored
  
      Online: Uses standard real-time E-Keys
      Online: Pre-fetches 'Degraded Mode E-Key'
  
      Offline: Rejects standard E-Keys
      Offline: Accepts 'Degraded Mode E-Key' only
      Offline: Logs all vehicle activity locally
      Offline: Disables non-essential connected features
  

5.2. Biometric Deadman's Switch E-Key Revocation

• Enabling Description: For high-security vehicle transport, the driver uses a wearable (e.g., smartwatch) that continuously monitors their vital signs (heart rate, blood oxygen). This wearable is paired with the vehicle's e-key system. The primary e-key is augmented with a "biometric keep-alive" privilege. If the wearable detects a reading outside of normal parameters (e.g., heart rate drops to zero, or the watch is removed from the wrist), it sends an immediate alert via a dedicated, redundant communication channel (e.g., satellite link). If the alert is not canceled by the driver within 60 seconds, the central server automatically revokes the e-key and sends a command to the vehicle to enter a "safe shutdown" mode. This mode involves gradually slowing the vehicle to a stop, activating hazard lights, and locking all cargo doors.
• Mermaid Diagram:

  flowchart LR
      subgraph Driver
          A[Smartwatch] -- Monitors Vitals --> B{Biometric Status};
      end
      subgraph Vehicle
          C[E-Key Module]
      end
      subgraph Server
          D[Monitoring & Revocation Service]
      end
  
      B -- "Normal" --> C;
      C -- "Valid Key" --> Vehicle_Systems[Operate Normally];
      B -- "Anomaly Detected" --> A;
      A -- Sends Alert --> D;
      D -- Starts 60s Timer --> D;
      D -- "If no cancel signal" --> C{Revoke E-Key};
      D -- "If no cancel signal" --> Vehicle_Systems;
      C --> Vehicle_Systems[Initiate Safe Shutdown];
  

---

Combination Prior Art Scenarios

1. E-Key Management via Matter and Thread Protocols

• Description: The vehicle's local communication system is built upon the Matter application layer protocol, running over a Thread mesh network. The user's smartphone, acting as a Matter controller, securely commissions the vehicle onto the local Thread network. The e-key, received from the cloud, is encapsulated as a set of Matter-defined access control list (ACL) entries. When the user's phone is near the car, it uses the low-power, resilient Thread mesh to transmit the e-key's ACLs to the vehicle's onboard Matter device. The vehicle's door locks, ignition, and infotainment systems are all represented as Matter endpoints. The e-key's privileges directly map to the permissions granted in the Matter ACLs (e.g., Allow User_X to invoke 'unlock' on Endpoint_DoorLock_DriverSide). This leverages an open, standardized, and secure local communication framework, making the system interoperable with a wide range of smart devices.

2. Authentication via OpenID Connect (OIDC) and FIDO2/WebAuthn

• Description: The cloud service for generating e-keys acts as an OpenID Connect (OIDC) Identity Provider. A user (e.g., a vehicle owner) authenticates to the e-key management web application using a phishing-resistant FIDO2/WebAuthn authenticator (like a YubiKey or a platform authenticator like Windows Hello or Face ID). Upon successful authentication, the user is authorized to generate an e-key for a recipient. The e-key itself is delivered as a JSON Web Token (JWT) with custom claims defining the vehicle privileges. The recipient's smartphone app stores this JWT. To use the vehicle, the app presents the JWT to the vehicle's telematics unit. The vehicle, acting as an OIDC Relying Party, validates the JWT's signature using the public key of the OIDC provider (the server). This combines a robust, open standard for web-based authentication with a standardized token format for asserting permissions.

3. Vehicle Telemetry Reporting using MQTT

• Description: The vehicle's communication with the cloud server for reporting "use data" (as described in Claim 1) is implemented using the MQTT (Message Queuing Telemetry Transport) protocol, a standard for IoT communication. The vehicle acts as an MQTT client and publishes its data (GPS location, speed, CAN bus data, etc.) to specific topics on a central MQTT broker hosted in the cloud (e.g., vehicles/VIN123/location, vehicles/VIN123/speed). The e-key management server subscribes to these topics. When a "condition of use" is violated (e.g., speed exceeds the limit defined in the e-key), the vehicle publishes a message to a specific alert topic (e.g., vehicles/VIN123/alerts). The server, subscribed to this topic, immediately receives the alert and can trigger the warning notification to the user. This use of MQTT provides an efficient, lightweight, and reliable publish/subscribe mechanism for real-time data streaming from the vehicle to the cloud infrastructure.