PTAB
IPR2025-01183
Google LLC v. Secure Communication Technologies LLC
Key Events
Petition
Table of Contents
petition
1. Case Identification
- Case #: IPR2025-01183
- Patent #: 11,687,971
- Filed: July 2, 2025
- Petitioner(s): Google LLC
- Patent Owner(s): Secure Communication Technologies, LLC
- Challenged Claims: 1-8, 10, 12-16, 18-19, 22-23, 26-30, 34-44, 46, 48-59, 62, 64-68, 72, 75-76, and 79-81
2. Patent Overview
- Title: Mobile Communication Architecture
- Brief Description: The ’971 patent discloses a mobile communication architecture for exchanging information between wireless devices. A first device uses short-range communication (e.g., Bluetooth) to detect an identifier from a nearby second device and reports this detection to a remote server using long-range communication (e.g., cellular), which may then facilitate further interaction based on stored policies.
3. Grounds for Unpatentability
Ground 1: Obviousness over Eagle, Behrens, and Olkkonen - All Challenged Claims are obvious over Eagle in view of Behrens and Olkkonen.
- Prior Art Relied Upon: Eagle (Application # 2005/0250552), Behrens (Application # 2010/0138481), and Olkkonen (Patent 7,590,086).
- Core Argument for this Ground:
- Prior Art Mapping: Petitioner asserted that the combination of Eagle, Behrens, and Olkkonen teaches every limitation of the challenged claims. Eagle taught the foundational architecture: a “Requester Device” detects a nearby “Identified Device” via a short-range protocol (Bluetooth) and notifies a remote server via a long-range cellular network. The server then compares user profiles and sends an alert back to facilitate communication. However, Petitioner argued Eagle did not explicitly disclose certain security and efficiency features that are trivial additions from other prior art.
- To address the claims’ requirement for changing identifiers over time (e.g., different MAC addresses and unique identifiers received from the same device in different time periods), Petitioner relied on Behrens. Behrens taught using multiple or changing unique identifiers (UIDs), which could include MAC addresses, to enhance user privacy and prevent tracking based on static identifiers. Petitioner argued a POSITA would have integrated Behrens’s changing UIDs into Eagle’s system to address known security risks in short-range wireless communications.
- To address the claims’ requirement for filtering beacon transmissions based on a "beacon service identifier," Petitioner relied on Olkkonen. Olkkonen taught that Bluetooth devices could filter inquiry responses based on service class or device class information to identify relevant networks or services (e.g., a collaborative game) and ignore irrelevant ones (e.g., a printer). Petitioner argued this directly corresponds to the ’971 patent’s filtering concept, making Eagle’s system more efficient by not reporting every nearby device to the server. Dependent claims reciting various "actions" (e.g., multiplayer gaming, receiving ads) were argued to be disclosed by the broad applications taught in Eagle, or as obvious alternatives taught by the collaborative functions in Olkkonen and Behrens.
- Motivation to Combine: A POSITA would combine these references for predictable results. The primary motivation to combine Eagle with Behrens was to improve the privacy and security of Eagle's social introduction system. By incorporating Behrens’s teaching of changing UIDs, a POSITA could prevent malicious tracking of users via their static Bluetooth identifiers, a well-known problem. The motivation to add Olkkonen’s teachings to the Eagle/Behrens system was to improve efficiency and conserve resources (e.g., battery life, server load). A POSITA would recognize the inefficiency of Eagle’s device reporting every nearby Bluetooth device to the server and would apply Olkkonen’s known filtering techniques to ensure only relevant devices (i.e., those participating in the same service) are processed.
- Expectation of Success: Petitioner argued a POSITA would have had a reasonable expectation of success. Implementing changing UIDs from Behrens into Eagle’s system would involve ordinary software coding skills, as Behrens provided techniques for synchronizing these UIDs with a server. Similarly, implementing Olkkonen's filtering would involve processing standard data fields (e.g., service class and device class) already present in Bluetooth inquiry responses, requiring no more than conventional data processing skills. The combination was a simple application of known techniques to improve a known system.
- Key Aspects: Petitioner contended that the Patent Owner is collaterally estopped from challenging the core teachings of Eagle and Behrens. This is because the PTAB, in final written decisions on related patents in the ’971 patent’s family, had already established that Eagle taught the basic device-server architecture and that Behrens taught the use of changing UIDs for privacy.
4. Relief Requested
- Petitioner requests institution of an inter partes review and cancellation of claims 1-8, 10, 12-16, 18-19, 22-23, 26-30, 34-44, 46, 48-59, 62, 64-68, 72, 75-76, and 79-81 of the ’971 patent as unpatentable.
Analysis metadata