PTAB

IPR2020-01605

Samsung Electronics Co Ltd v. Nordic Interactive Technologies LLC

Log In
Key Events
Petition
petition Intelligence

1. Case Identification

2. Patent Overview

  • Title: Device Detection and Service Discovery in Mobile Ad Hoc Network
  • Brief Description: The ’097 patent discloses a system and method for device detection and service discovery in a mobile ad hoc network. The invention aims to reduce power consumption by using a multi-step process wherein a device first inquires if a nearby device may include a "middleware software" before establishing a full connection to confirm its presence and execute applications.

3. Grounds for Unpatentability

Ground 1: Obviousness over Yau-DIPES, BT1.1, and Yau-PC - Independent Claims 1, 19, 37, 45, and 53 are obvious over Yau-DIPES in view of the general knowledge of a POSITA or BT1.1, and further in view of Yau-PC.

  • Prior Art Relied Upon: Yau-DIPES (a 2002 paper on adaptive middleware), Yau-PC (a 2002 follow-up paper), and BT1.1 (the Bluetooth Specification Version 1.1 from 2001).
  • Core Argument for this Ground:
    • Prior Art Mapping: Petitioner argued that Yau-DIPES taught the core inventive concept: using an adaptive middleware ("RCSM") in an ad hoc network to establish a preliminary "handshaking channel" based on proximity before committing to a full, power-intensive data connection. This handshaking inherently requires an inquiry to find nearby devices and an indication from the responding device that it contains compatible middleware. Yau-DIPES disclosed that after the handshake, "both R-ORBs" (the middleware components) perform service discovery, mapping to the patent's "confirming" and "executing" steps.
    • Motivation to Combine: A POSITA would combine Yau-DIPES with BT1.1 because Yau-DIPES expressly suggested using Bluetooth for implementation. It would have been an obvious design choice to use the standard inquiry/response messages defined in BT1.1 to implement the "handshaking channel" taught by Yau-DIPES. Furthermore, Yau-PC, a companion paper to Yau-DIPES, explicitly taught the resource-saving benefit of disconnecting if a compatible middleware partner is not found, providing a clear motivation to implement the "disconnect" limitation of the challenged claims.
    • Expectation of Success: A POSITA would have reasonably expected success in combining the middleware architecture of Yau-DIPES with the well-known, standardized Bluetooth protocol of BT1.1 to create a power-efficient ad hoc network, as this involved applying a known protocol to improve a known system.

Ground 2: Obviousness over Yau-DIPES and BT1.1 - Dependent Claims 2-3, 20-21, 38-39, and 46-47 are obvious over Yau-DIPES in view of the general knowledge of a POSITA or BT1.1, and further in view of Yau-PC.

  • Prior Art Relied Upon: Yau-DIPES, Yau-PC, and BT1.1.

  • Core Argument for this Ground:

    • Prior Art Mapping: Petitioner contended that the additional limitations in the dependent claims were also rendered obvious. For claims requiring specific Bluetooth features (e.g., claim 22 reciting "sending an inquiry request message" and "receiving an inquiry response message"), BT1.1 explicitly disclosed these as standard commands. For claims requiring the "indication" to be the setting of specific bits in a command (e.g., claim 24), BT1.1 described the "Class of Device" field in its inquiry response message, which a POSITA would have found obvious to use for conveying such an indication.
    • Motivation to Combine: The motivation was the same as in Ground 1. A POSITA implementing the Yau-DIPES system using Bluetooth would naturally and obviously use the specific, standardized commands and data fields provided in the BT1.1 specification to carry out the required communication steps, such as inquiry, response, and indication.
    • Expectation of Success: Using the predefined bit fields within a standard Bluetooth message to encode information about device capabilities was a predictable and routine implementation detail with a high expectation of success.

  • Additional Grounds: Petitioner asserted additional obviousness challenges (Grounds 3A/3B) against dependent claims 4-16, 22-34, 40-42, and 48-50 based on the same prior art combinations, arguing that further specific implementations (e.g., paging requests, recognition messages) were also well-known elements of the BT1.1 protocol.

4. Key Claim Construction Positions

  • “middleware software”: Petitioner argued this term should be construed according to the patent’s express definition: “a software layer with an API that negotiates the communication between two applications to help an application find a counterpart application with the correct role.”
  • “an indication that [the device] may include a middleware software”: Petitioner argued this phrase means “an indication that the device possibly includes a middleware software.” This construction was based on the specification’s description of a two-stage process that contrasts the initial "possible" indication during inquiry with a later step that "definitely includes" or "confirms" the presence of the middleware.

5. Key Technical Contentions (Beyond Claim Construction)

  • Effective Filing Date: Petitioner dedicated significant argument to establishing that the ’097 patent is not entitled to its claimed priority date from the ’721 patent. It was argued that the core limitations requiring a two-step "indication" and "confirmation" process constitute new matter not disclosed in the parent application. Therefore, Petitioner asserted the effective filing date is the patent's actual filing date of September 16, 2003, which makes Yau-DIPES and Yau-PC (both published in 2002) available as prior art.

6. Arguments Regarding Discretionary Denial

  • Petitioner argued that discretionary denial under Fintiv would be inappropriate. The key reasons asserted were that the parallel district court case was in its infancy, Petitioner intended to seek a stay if the IPR was instituted, the overlap of issues was minimal (only 6 claims asserted in court vs. 45 challenged in the IPR), and the petition presented strong evidence of unpatentability.

7. Relief Requested

  • Petitioner requested institution of an inter partes review and cancellation of claims 1-16, 19-34, 37-42, 45-50, and 53 of the ’097 patent as unpatentable under 35 U.S.C. §103.