PTAB
IPR2026-00070
Toyota Motor Corp v. Emerging Automotive LLC
Key Events
Petition
Table of Contents
petition
1. Case Identification
- Case #: IPR2026-00070
- Patent #: 12,337,716
- Filed: October 21, 2025
- Petitioner(s): Toyota Motor Corp.
- Patent Owner(s): Emerging Automotive LLC
- Challenged Claims: 1-13
2. Patent Overview
- Title: Cloud-Based System for Interfacing with Vehicles
- Brief Description: The ’716 patent describes methods and systems for customizing vehicles using server-stored user profile settings. The system uses cloud services to transfer a user’s profile settings to a vehicle, enabling automatic synchronization and application of configurations when the user enters the vehicle.
3. Grounds for Unpatentability
Ground 1: Claims 1-11 are obvious over Rector, Kleve, and Xiao.
- Prior Art Relied Upon: Rector (Application # 2011/0137520), Kleve (Application # 2014/0129053), and Xiao (Application # 2012/0164989).
- Core Argument for this Ground:
- Prior Art Mapping: Petitioner argued that Rector disclosed the foundational cloud-based architecture, including a settings server and database that stores user profiles and transmits permitted settings to a vehicle to control its functions. Kleve was asserted to supplement Rector by teaching server-side credential verification and the application of personal settings (e.g., seat position, radio presets) after a user is authenticated in a cloud computing environment. Finally, Petitioner contended that Xiao taught the missing element of determining setting compatibility, disclosing a server that uses a vehicle’s ID to retrieve or generate "appropriate command codes," ensuring that only settings compatible with the specific vehicle are transmitted.
- Motivation to Combine: A Person of Ordinary Skill in the Art (POSA) would combine Rector's server-managed profile system with Kleve's remote credential verification to create a more secure and robust system for applying user settings. It would have been a simple, predictable improvement to add Kleve’s server-side authentication step before Rector’s system transfers settings. A POSA would further incorporate Xiao's vehicle-specific compatibility check to enhance the safety and reliability of the combined system, as it addresses the known problem of applying settings across a fleet of different vehicle types with varying capabilities.
- Expectation of Success: A POSA would have a reasonable expectation of success because the references describe technologically complementary subsystems that operate over standard network protocols. The integration of server-side verification (Kleve) and compatibility filtering (Xiao) into a server-based profile system (Rector) represents a predictable combination of known elements to improve a known system.
Ground 2: Claims 12-13 are obvious over Rector, Kleve, and Xiao, further in view of Patenaude.
- Prior Art Relied Upon: Rector (Application # 2011/0137520), Kleve (Application # 2014/0129053), Xiao (Application # 2012/0164989), and Patenaude (Application # 2006/0136106).
- Core Argument for this Ground:
- Prior Art Mapping: This ground built upon the combination of Rector, Kleve, and Xiao by adding Patenaude to address the "learning engine" limitation in claims 12 and 13. Petitioner argued that Patenaude disclosed a method for learning a user's preferences by monitoring in-vehicle inputs (e.g., entertainment selections) over time, detecting patterns in those inputs, and using those patterns to generate or update a user profile. This process of deriving patterns from user behavior to predict and apply settings was alleged to constitute the claimed "learning engine."
- Motivation to Combine: A POSA, seeking to improve the convenience and safety of the base Rector/Kleve/Xiao system, would have been motivated to incorporate Patenaude's learning functionality. Adding a learning engine would reduce driver distraction by automatically predicting and applying user settings based on learned patterns, a known goal in the art. The combination would predictably result in a system that not only authenticates a user and applies compatible settings but also intelligently adapts those settings based on the user's behavior.
- Expectation of Success: Success would be expected as implementing a software-based learning algorithm, as taught by Patenaude, into the server of the base combination is a straightforward software adjustment. A POSA could have readily performed the pattern-detection processing on the server, using vehicle-provided input data, to update the user's cloud-stored profile.
Ground 3: Claims 5-6 are obvious over Rector and Kleve, further in view of Hayashi.
- Prior Art Relied Upon: Rector (Application # 2011/0137520), Kleve (Application # 2014/0129053), and Hayashi (Japanese Application # 2012-076627).
- Core Argument for this Ground:
- Prior Art Mapping: This ground was presented as an alternative to using Xiao for the compatibility limitations of claims 5 and 6. Petitioner argued that Hayashi disclosed a server with a database that explicitly maps operating methods for various vehicle functions to specific vehicle models. This database demonstrated compatibility by storing specific methods for each model and indicating "none" where a function was incompatible. Petitioner asserted this system constituted a "mapping engine" to identify incompatible settings (claim 5) and provided a "translation metric" by selecting the correct operating method for a given function on a specific vehicle model (claim 6).
- Motivation to Combine: A POSA would have been motivated to combine Hayashi with Rector and Kleve for the same reasons as combining Xiao: to solve the known problem of ensuring that user settings are compatible with the target vehicle. Hayashi provided a clear, database-driven solution for managing setting compatibility across different vehicle models, which would have been a logical and useful addition to the Rector/Kleve system.
- Expectation of Success: A POSA would expect success in this combination because Hayashi's server-side database lookup is a routine and predictable way to implement compatibility checks within the established cloud-based architecture of Rector and Kleve.
4. Relief Requested
- Petitioner requested institution of an inter partes review and cancellation of claims 1-13 of the ’716 patent as unpatentable.
Analysis metadata