US 8677398

Analysis of U.S. Patent 8,677,398

Date of Analysis: April 26, 2026

This report provides a summary of U.S. Patent 8,677,398, including its key bibliographic data, a summary of its abstract, and a plain-language explanation of its independent claims.

I. Bibliographic Information

• Title: Systems and methods for taking action with respect to one network-connected device based on activity on another device connected to the same network
• Assignee: The listed assignee is Intent IQ LLC. It is worth noting that a petition for inter partes review filed in 2022 lists both AlmondNet, Inc. and Intent IQ, LLC as patent owners.
• Inventor: Roy Shkedi
• Filing Date: June 23, 2011
• Issue Date: March 18, 2014
• Abstract: The patent describes a method for delivering targeted television advertisements based on a user's online behavior. This is achieved by electronically associating the IP addresses of online access devices (like computers or mobile phones) with the IP addresses of television set-top boxes. When a user's online activity provides user profile information, a relevant television advertisement can be selected and sent to the associated set-top box. The abstract emphasizes that this process can be done without using personally identifiable information (PII).

II. Litigation and Administrative Proceedings

A search of the U.S. Court of Appeals for the Federal Circuit (CAFC) dockets for 2026 did not reveal any specific cases involving U.S. Patent 8,677,398. However, it is a matter of public record that this patent has been the subject of an inter partes review (IPR) proceeding before the Patent Trial and Appeal Board (PTAB) of the USPTO (Case IPR2022-00773), initiated by Meta Platforms, Inc. The outcome of this and any other potential litigations or administrative challenges could impact the patent's enforceability.

III. Plain-Language Summary of Independent Claims

U.S. Patent 8,677,398 contains several independent claims, which define the core of the invention. Below is a simplified explanation of each.

Independent Claim 1:

This claim describes a method for taking action on a second device based on the activity of a first device. The key steps are:

1. A server receives a notification from a first device (e.g., a smartphone) that includes an identifier for that device and the IP address it's currently using.
2. Later, the server receives another notification, this time from a second device (e.g., a smart TV or set-top box). This notification also contains an identifier for the second device and its current IP address.
3. The server recognizes that both devices are using the same IP address, which suggests they are on the same local network (like a home Wi-Fi network).
4. Based on this shared IP address, the server electronically associates the two devices.
5. After the devices are associated, the server receives information about the user's activity on the first device (for example, browsing a specific product on a shopping website).
6. Using this information about the user's activity, the server then sends a targeted message (like an advertisement for that product) to the second device.

Essentially, this claim covers the process of seeing that two different devices are on the same network and then using what a person does on one device to send them related content on the other.

Independent Claim 9:

This claim is similar to the first, but it focuses on the system or apparatus that carries out the method. It describes a system with a processor and memory that is programmed to:

1. Receive and store identifiers and IP addresses from multiple devices.
2. Identify when different devices are using the same IP address at the same or a similar time.
3. Create an electronic link or association between these devices.
4. Receive information about a user's online activity from one of the associated devices.
5. In response to that activity, automatically send a message to another one of the associated devices.

This claim protects the physical or software-based system that performs the actions described in claim 1.

Independent Claim 15:

This claim is for a non-transitory computer-readable medium (like a hard drive or server memory) that contains instructions for a processor to perform the method. The steps are largely the same as in claim 1:

1. Receive an identifier and IP address from a first device.
2. Receive an identifier and IP address from a second device.
3. Determine that both devices are using the same IP address and are therefore on the same local network.
4. Electronically associate the two devices.
5. Receive user activity data from the first device.
6. Send a targeted message to the second device based on that activity.

This type of claim is intended to protect the software or firmware that enables this targeted advertising system to function.

Disclaimer: This analysis is for informational purposes only and does not constitute legal advice. The interpretation of patent claims can be complex and may vary depending on the specific context and legal arguments.

Litigation History of U.S. Patent 8,677,398

U.S. Patent No. 8,677,398, assigned to Intent IQ LLC, has been the subject of extensive litigation, with the patent owner, often alongside parent company AlmondNet, Inc. and subsidiary Datonics, LLC, actively asserting it against numerous major technology and media companies. The litigation spans multiple jurisdictions, primarily the District of Delaware and the Western District of Texas.

Key Litigants and Case Details:

Below is a summary of known litigation involving the '398 patent:

• Intent IQ, LLC v. tvScientific, Inc.

  • Jurisdiction: U.S. District Court for the District of Delaware
  • Case Number: 1:26-cv-00089
  • Filing Date: January 27, 2026
  • Status/Outcome: This case is currently active. The complaint alleges that tvScientific's cross-device advertising platform infringes on the '398 patent. The timing of this lawsuit is notable as it was filed after Pinterest announced its intention to acquire tvScientific.

• AlmondNet, Inc., et al. v. LiveIntent, Inc.

  • Jurisdiction: U.S. District Court for the District of Delaware
  • Case Number: 1:24-cv-00831
  • Filing Date: Original complaint filed, with an amended complaint on November 12, 2024.
  • Status/Outcome: This case is ongoing. The plaintiffs allege that LiveIntent's advertising systems infringe upon the '398 patent, among others.

• Intent IQ, LLC v. MNTN, Inc.

  • Jurisdiction: U.S. District Court for the Western District of Texas
  • Case Number: 7:25-cv-00246
  • Filing Date: May 23, 2025
  • Status/Outcome: This case is currently active. The suit claims that MNTN's digital advertising platform infringes on the '398 patent and another related patent.

• AlmondNet, Inc., et al. v. TikTok, Inc.

  • Jurisdiction: U.S. District Court for the District of Delaware
  • Case Number: 1:25-cv-00611
  • Filing Date: May 16, 2025
  • Status/Outcome: This case is ongoing. The complaint asserts that TikTok's advertising methods infringe on the '398 patent and several others.

• AlmondNet, Inc., et al. v. Meta Platforms, Inc.

  • Jurisdiction: U.S. District Court for the Western District of Texas
  • Case Number: 6:21-cv-00896
  • Filing Date: Service of the complaint occurred on September 2, 2021.
  • Status/Outcome: While this case was filed, public records indicate that Meta and the patent holders entered into a streamlining agreement, which included a covenant not to sue regarding the '398 patent and a mutual release of claims for past infringement damages. This suggests a settlement or licensing agreement was reached.

• AlmondNet, Inc. v. Microsoft Corporation

  • Jurisdiction: U.S. District Court for the Western District of Texas
  • Case Number: 6:21-cv-00897
  • Status/Outcome: This case was subject to a licensing deal, indicating a resolution between the parties.

• AlmondNet, Inc. v. Amazon.com, Inc.

  • Jurisdiction: U.S. District Court for the Western District of Texas
  • Case Number: 6-21-cv-00898
  • Status/Outcome: This dispute has been resolved through a settlement and license agreement, as announced in April 2026. This followed a significant trial win for AlmondNet and its subsidiaries.

• AlmondNet, Inc. v. [Samsung Electronics Co.](/litigations/by-defendant/Samsung%20Electronics%20Co.)

  • Jurisdiction: U.S. District Court for the Western District of Texas
  • Case Number: 6-21-cv-00891
  • Status/Outcome: This case was resolved through a licensing agreement.

• AlmondNet, Inc. v. Roku, Inc.

  • Jurisdiction: U.S. District Court for the Western District of Texas
  • Case Number: 6-21-cv-00731
  • Status/Outcome: This litigation was also settled with a licensing deal.

• Roku, Inc. v. AlmondNet, Inc.

  • Jurisdiction: U.S. District Court for the District of Delaware
  • Case Number: 1-21-cv-01035
  • Status/Outcome: This was likely a declaratory judgment action filed by Roku, which was resolved as part of the broader settlement and licensing agreement between the parties.

• AlmondNet, Inc. v. Oath Holdings Inc.

  • Jurisdiction: U.S. District Court for the District of Delaware
  • Case Number: 1-19-cv-00247
  • Status/Outcome: This case was terminated in March 2019.

Administrative Challenges at the Patent Trial and Appeal Board (PTAB):

In addition to district court litigation, the '398 patent has been challenged at the PTAB through inter partes review (IPR) proceedings, which allow third parties to contest the validity of a patent's claims.

• IPR2017-01299: Filed by Yahoo! Inc. The petition to institute a review was denied.
• IPR2022-00773: This case, mentioned in the patent summary, involved Meta Platforms, Inc.
• IPR2022-00883: This IPR was filed by Meta Platforms, Inc. and was instituted by the PTAB on October 21, 2022.
• In a significant decision, the PTAB held that challenged claims of the '398 patent were not unpatentable as obvious over prior art in an IPR brought by Meta Platforms Inc., Roku Inc., and Samsung Electronics Co. Ltd.

Additionally, the '398 patent was the subject of an ex parte reexamination, with a certificate issued on July 15, 2024, confirming the patentability of claims 1 and 2. This can strengthen the patent's presumption of validity in subsequent litigation.

Proceedings overview

As of the current date, U.S. Patent 8,677,398 has been the subject of one AIA trial proceeding, IPR2025-01317, which resulted in a discretionary denial of institution. This means the patent's claims have not been formally challenged on the merits at the PTAB in this particular proceeding, and the patent's validity remains undiminished by this IPR. For a defendant, this indicates that an IPR-based defense targeting the grounds raised in IPR2025-01317 would face the hurdle of overcoming the Board's prior discretionary denial.

IPR2025-01317 — LiveIntent, Inc. v. Intent IQ LLC

• Type: Inter Partes Review
• Filed: 2025-07-18
• Status: Discretionary Denial. The PTAB declined to institute the inter partes review on procedural grounds.
• Judge panel: Information regarding the specific judge panel for this proceeding is not readily available in public summaries for discretionary denials, but generally includes a panel of three Administrative Patent Judges.
• Petition grounds: Specific details of the claims challenged, prior art asserted, and statutory bases (§ 102 / § 103) are typically elaborated in the petition and institution decision. Given the discretionary denial, a full analysis of these grounds by the Board on the merits did not occur.
• Institution decision: Denied. The institution was procedurally denied on 2026-01-12. The PTAB issued a decision denying institution, often due to factors such as parallel district court litigation, arguments under Fintiv factors, or other procedural considerations, rather than on the merits of the prior art.
• Final Written Decision: Not issued, as institution was denied.
• Settlement / termination: Not applicable, as the proceeding was terminated by a denial of institution.
• Appeal: There is no public record of an appeal to the Federal Circuit for this discretionary denial.
• Defensive value: This proceeding indicates that LiveIntent, Inc. attempted an IPR challenge, but it was not instituted on the merits. A future defendant, especially one in privity with LiveIntent, Inc., would be estopped from raising the same or reasonably could have raised grounds in a subsequent IPR. For other defendants, while the Board did not rule on the merits of patentability, the discretionary denial might signal a strategic challenge in instituting an IPR against this patent, potentially requiring different grounds or a different procedural posture.

Strategic summary

Only one AIA trial proceeding, IPR2025-01317, is listed as on file for U.S. Patent 8,677,398, and it resulted in a discretionary denial of institution. This means that, based on the provided canonical list, all claims (1-15, as granted) of US Patent 8,677,398 remain UNTESTED by a formal PTAB review on the merits. No claims have been canceled or formally sustained by a Final Written Decision in an IPR proceeding.

The estoppel landscape from IPR2025-01317 would apply to LiveIntent, Inc. (the petitioner) and its privies. Under 35 U.S.C. § 315(e)(2), they would be barred from asserting in future civil actions or other USPTO proceedings any ground that was raised or reasonably could have been raised in this IPR. For other potential defendants, this specific IPR denial does not directly impose estoppel on new challenges, though it might highlight the PTAB's current stance on discretionary denials.

The litigation history indicates that Intent IQ LLC (and its affiliates) are actively asserting this patent against numerous major technology and media companies, including district court cases and other IPRs (IPR2022-00773, IPR2022-00883, IPR2017-01299 mentioned in the background but not in the canonical list for this task). The fact that IPR2025-01317 was denied institution suggests that the patent owner has successfully defended against at least one PTAB challenge, possibly on procedural grounds related to parallel litigation or other discretionary factors, rather than a lack of merit in the prior art itself.

Recommended next steps

Given that IPR2025-01317 resulted in a discretionary denial, there is no Final Written Decision to link to or quote regarding claim invalidation.

For any defendant facing assertion of US Patent 8,677,398, it is critical to:

• Review the institution decision for IPR2025-01317: Obtain and thoroughly analyze the PTAB's written decision denying institution for IPR2025-01317. This document, publicly available via the USPTO PTAB E2E system (https://e2e.uspto.gov/e2e/patents), will outline the specific reasons for the discretionary denial. Understanding these reasons is crucial for assessing the viability of future IPR petitions.
• Assess the other IPRs mentioned in the litigation summary: While not included in the canonical PTAB proceedings on file for this specific task, the litigation summary explicitly mentions other IPRs (IPR2022-00773, IPR2022-00883, IPR2017-01299) related to US8677398. It is imperative to investigate the outcomes of these cases, particularly IPR2022-00883, which was instituted, to determine if any claims were invalidated or upheld on the merits in those proceedings. This would provide a more complete picture of the patent's validity and the claims that have survived scrutiny.
• Conduct independent prior art search: Given the active litigation and the lack of a merits-based PTAB decision on record for IPR2025-01317, a thorough, independent prior art search is advisable to identify strong non-cumulative art that could support new invalidity arguments in a fresh IPR or district court defense.
• Evaluate estoppel implications: If the defendant is in any way related to LiveIntent, Inc., a careful analysis of the estoppel implications from IPR2025-01317 is necessary before pursuing any IPR.
• Monitor for new PTAB filings: Continuously monitor the PTAB E2E system for any new IPR, PGR, or CBM petitions filed against US Patent 8,677,398. New proceedings could alter the defensive landscape rapidly.

Inventors

The sole named inventor for U.S. Patent 8,677,398 is Roy Shkedi. At the time of the application's filing (June 23, 2011), Roy Shkedi was the founder and CEO of Intent IQ LLC, the original assignee of record for this patent, and also the founder of AlmondNet, Inc.

Original assignee

The entity named as the original assignee on the issued patent US8677398 is Intent IQ LLC.
Intent IQ LLC operates in the digital advertising technology sector, specifically providing solutions for cross-device identity resolution and targeted advertising. They offer technology that enables advertisers and publishers to identify and reach users across different devices without relying solely on cookies. Based on their business activities and the nature of the patent claims, Intent IQ LLC ships products and services embodying the claims. They are currently an operating company.

Assignment timeline

• 2011-06-22 (executed) / recorded 2011-08-16 — Reel 025816/0060

  • Conveyance: ASSIGNMENT
  • Assignor: ALMONDNET, INC.
  • Assignee: INTENT IQ LLC
  • Correspondent: GREGORY J. BATTERSBY, 477 MAIN AVE., SUITE 404, NORWALK, CT 06851
  • Context: Transfer of patent rights from an affiliated entity (AlmondNet, Inc.) to the assignee (Intent IQ LLC) shortly before the application filing date, establishing Intent IQ LLC as the original assignee for this specific patent.

• 2018-02-14 (executed) / recorded 2019-01-28 — Reel 052441/0458

  • Conveyance: ASSIGNMENT
  • Assignor: INTENT IQ LLC
  • Assignee: ALMONDNET INC.
  • Correspondent: KENNETH L. KING, LAW OFFICE OF KENNETH L. KING, PO BOX 2981, WESTFIELD, NJ 07091. This correspondent recurs multiple times in this chain.
  • Context: Internal reorganization or transfer between closely related entities.

• 2018-02-14 (executed) / recorded 2019-01-28 — Reel 052441/0462

  • Conveyance: ASSIGNMENT
  • Assignor: ALMONDNET INC.
  • Assignee: INTENT IQ LLC
  • Correspondent: KENNETH L. KING, LAW OFFICE OF KENNETH L. KING, PO BOX 2981, WESTFIELD, NJ 07091. This correspondent recurs multiple times in this chain.
  • Context: Internal reorganization or transfer between closely related entities.

• 2018-02-14 (executed) / recorded 2019-01-28 — Reel 052441/0466

  • Conveyance: ASSIGNMENT
  • Assignor: INTENT IQ LLC
  • Assignee: ALMONDNET INC.
  • Correspondent: KENNETH L. KING, LAW OFFICE OF KENNETH L. KING, PO BOX 2981, WESTFIELD, NJ 07091. This correspondent recurs multiple times in this chain.
  • Context: Internal reorganization or transfer between closely related entities.

• 2018-02-14 (executed) / recorded 2019-01-28 — Reel 052441/0470

  • Conveyance: ASSIGNMENT
  • Assignor: ALMONDNET INC.
  • Assignee: INTENT IQ LLC
  • Correspondent: KENNETH L. KING, LAW OFFICE OF KENNETH L. KING, PO BOX 2981, WESTFIELD, NJ 07091. This correspondent recurs multiple times in this chain.
  • Context: Internal reorganization or transfer between closely related entities.

Timeline diagram

timeline
    title Ownership of US 8677398
    2007 : Original app filed by AlmondNet
    2011 : Assigned to Intent IQ LLC
         : Continuation filed by Intent IQ LLC
    2014 : Patent 8677398 Issued
    2019 : Assigned Intent IQ to AlmondNet (internal)
         : Assigned AlmondNet to Intent IQ (internal)
         : Assigned Intent IQ to AlmondNet (internal)
         : Assigned AlmondNet to Intent IQ (internal)
    2021 : First litigation filed (Meta)

NPE / troll-pattern signals

1. Shell-entity transfer — Not present. The transfers occur between Intent IQ LLC and AlmondNet, Inc., both of which are operating companies in the ad-tech space and are actively involved in asserting these patents.
2. Known asserter in the chain — Present. Intent IQ LLC and AlmondNet, Inc. are explicitly identified in the litigation summary as patent owners who are "actively asserting it against numerous major technology and media companies" [cite: US Litigation Summary]. This behavior aligns with that of patent asserters.
3. Repeat correspondent across the chain — Present. Kenneth L. King, Law Office of Kenneth L. King, appears as the correspondent for four consecutive assignments recorded on 2019-01-28 (Reel 052441/0458, 0462, 0466, 0470).
4. Cascading transfers — Present. Four assignments were executed on 2018-02-14 and recorded on 2019-01-28, with the patent being transferred back and forth between Intent IQ LLC and AlmondNet Inc. (Reel 052441/0458, 0462, 0466, 0470).
5. Pre-litigation transfer — Not present. The last recorded assignment (2018-02-14 executed / 2019-01-28 recorded, Reel 052441/0470) predates the earliest cited litigation (January 27, 2026) by several years.
6. Bankruptcy fire-sale — Not present. There is no evidence of a bankruptcy sale.
7. Privateering — Unclear. While AlmondNet and Intent IQ LLC are associated and assert patents, it does not appear to be a classic privateering scenario where an operating company transfers a patent to an unaffiliated NPE to assert on its behalf. Instead, they appear to be direct beneficiaries of the assertions.
8. Defensive aggregator (anti-NPE) — Not present. The patent has not been acquired by a defensive aggregator.

Verdict

NPE — high confidence

Intent IQ LLC and its related entity AlmondNet, Inc. are documented as actively and frequently asserting this patent against numerous technology and media companies, which is a strong indicator of NPE activity. [cite: US Litigation Summary]. Further, the presence of a recurring correspondent (Kenneth L. King) across multiple internal transfers (Reel 052441/0458, 0462, 0466, 0470) suggests a structured approach to patent management consistent with assertion-focused entities.

USPTO Patent Assignment Search: US8677398

Analysis of Prior Art Cited in U.S. Patent 8,677,398

This analysis examines the most relevant prior art references cited during the prosecution of U.S. Patent 8,677,398 ("the '398 patent"). Each reference is evaluated for its potential to anticipate the independent claims of the '398 patent under 35 U.S.C. § 102. Anticipation requires that a single prior art reference discloses, either expressly or inherently, each and every element of a claimed invention.

The independent claims (1, 9, and 15) of the '398 patent generally describe a method, system, and computer-readable medium for:

1. Receiving identifiers and IP addresses from a first device (e.g., a mobile phone) and a second device (e.g., a set-top box).
2. Determining that both devices are on the same local network by recognizing they share the same public IP address.
3. Electronically associating the two devices based on this shared IP address.
4. Receiving information about a user's activity on the first device.
5. Automatically sending a targeted message to the second device based on that activity.

The following is an assessment of key prior art cited against these claims.

---

U.S. Patent No. 7,734,510 B1 (to Huddersfield)

• Full Citation: US 7,734,510 B1, "Method and System for Presenting an Advertisement to a User," filed by Huddersfield, Inc.
• Filing Date: June 13, 2000
• Publication Date: June 8, 2010
• Description: The Huddersfield patent describes a system for delivering targeted advertisements to users. It discloses collecting user information, including IP addresses, and using that information to select and present relevant ads. A central ad server coordinates the collection of user data and the delivery of advertisements. The system can track user behavior across different websites to build a profile for ad targeting.
• Potential Anticipation of Claims:
  • Claims 1, 9, 15: Huddersfield discloses the concept of collecting user data (including IP addresses) and using it for targeted advertising. However, it does not explicitly describe a method for associating two different types of devices (e.g., a mobile phone and a set-top box) by observing a shared IP address and then using the activity on one device to trigger an ad on the second device. Huddersfield's focus is on targeting a single user or device based on its own activity history. Therefore, it does not appear to anticipate the core cross-device association and targeting elements of the '398 patent's independent claims.

---

U.S. Patent Application Publication No. 2005/0240964 A1 (to Her-daw-ih)

• Full Citation: US 2005/0240964 A1, "Method and System for Providing Advertising in an Interactive Television Network," filed by Her-daw-ih, et al.
• Filing Date: April 26, 2004
• Publication Date: October 27, 2005
• Description: This application describes a system for delivering targeted advertising within an interactive television (iTV) environment. It discloses collecting household demographic and psychographic information and using it to select ads. The system can also monitor viewing habits to refine ad targeting. The set-top box (STB) plays a role in receiving and displaying these targeted ads.
• Potential Anticipation of Claims:
  • Claims 1, 9, 15: Her-daw-ih focuses on targeting advertisements on a television based on viewing habits and user profiles associated with that television or household. It does not teach the key inventive step of the '398 patent: using the online activity from a separate device (like a computer or smartphone) to target ads on the television by first associating the two devices via a common IP address. The association based on a shared public IP address between a general-purpose computing device and a television STB is absent. Thus, Her-daw-ih does not anticipate the independent claims.

---

U.S. Patent Application Publication No. 2006/0069634 A1 (to Amron)

• Full Citation: US 2006/0069634 A1, "System and Method for Tracking and Targeting Advertising," filed by Amron, et al.
• Filing Date: September 26, 2005
• Publication Date: March 30, 2006
• Description: Amron discloses a system for tracking user behavior across different media to provide targeted advertising. It mentions tracking online behavior and television viewing habits. The system can use various identifiers to track a user, including cookies and device IDs. The goal is to create a comprehensive user profile to deliver more relevant ads.
• Potential Anticipation of Claims:
  • Claims 1, 9, 15: Amron teaches the general concept of cross-media ad targeting. However, it does not specifically disclose the method of using a shared public IP address as the basis for electronically associating distinct devices (e.g., a web-browsing device and a set-top box) and then triggering a message on the second device based on the activity of the first. While Amron discusses user tracking, it does not describe the specific mechanism of IP-based household device association claimed in the '398 patent. Therefore, it likely does not anticipate the independent claims.

---

U.S. Patent Application Publication No. 2007/0157254 A1 (to Goldschmidt Iki)

• Full Citation: US 2007/0157254 A1, "Method and Apparatus for Tracking and Using Viewing Data of Television Viewers," filed by Goldschmidt Iki, et al.
• Filing Date: January 3, 2006
• Publication Date: July 5, 2007
• Description: This publication describes methods for collecting and utilizing television viewing data. It discusses identifying households and associating viewing data with those households. The collected data is then used for various purposes, including targeted advertising and content recommendations.
• Potential Anticipation of Claims:
  • Claims 1, 9, 15: Goldschmidt Iki focuses on tracking and using television viewing data. It does not describe associating a television or set-top box with another, separate online device based on a shared IP address. The core concept of leveraging online activity from one device to trigger an ad on a television within the same local network is not present. Therefore, this reference does not anticipate the independent claims of the '398 patent.

---

U.S. Patent Application Publication No. 2002/0087520 A1 (to Shvo)

• Full Citation: US 2002/0087520 A1, "Method and System for Selecting Advertisements to be Presented to a User," filed by Shvo, et al.
• Filing Date: December 28, 2000
• Publication Date: July 4, 2002
• Description: Shvo discloses a system for selecting advertisements for a user based on a user profile. The profile is built from the user's online activities, such as search queries and websites visited. An ad server uses this profile to match relevant ads to the user. The system uses cookies and other identifiers to recognize the user across different sessions.
• Potential Anticipation of Claims:
  • Claims 1, 9, 15: Shvo's disclosure is centered on building a user profile from online activity to deliver targeted online ads to that same user/device. It does not teach the cross-device functionality that is central to the '398 patent. There is no mention of identifying a second device (like a set-top box) on the same network via a shared IP address and sending it a message based on the first device's activity. Consequently, Shvo does not anticipate the independent claims.

---

Summary of Prior Art Analysis

Based on a review of the cited prior art, none of the references appear to fully anticipate the independent claims of U.S. Patent 8,677,398. While many references disclose elements of targeted advertising, such as collecting user data, using IP addresses for identification, and building user profiles, they consistently lack the specific combination of steps that define the '398 patent's core invention. Specifically, the prior art does not appear to disclose the method of:

1. Identifying that two distinct devices are on the same local network by observing a shared public IP address.
2. Creating an electronic association between these devices based on that shared IP address.
3. Using the online activity of the first device to automatically trigger the delivery of a targeted message to the second, associated device.

It is this specific cross-device linking and targeting mechanism that appears to be the novel contribution of the '398 patent over the cited references.

Obviousness Analysis under 35 U.S.C. § 103

This analysis evaluates whether the invention claimed in U.S. Patent 8,677,398 ("the '398 patent") would have been obvious to a Person Having Ordinary Skill in the Art (PHOSITA) at the time of the invention, which has a priority date of April 17, 2007. An 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 to a PHOSITA.

A PHOSITA in this field in 2007 would be a computer scientist or engineer with several years of experience in network engineering, online advertising systems, and interactive television technologies. This individual would have a working knowledge of TCP/IP, the assignment of IP addresses (including the function of Network Address Translation (NAT) in home networks), client-server architectures, the use of cookies for user tracking, and the general state of the art in both online and television advertising.

The central concept of the '398 patent's independent claims (1, 9, and 15) is the use of a shared public IP address to associate a general-purpose online device (like a computer) with a television set-top box (STB) on the same local network, and then using the online activity of the former to send targeted advertising to the latter. While the preceding prior art analysis concluded that no single reference anticipates all elements of the claims, the combination of several references, viewed through the lens of a PHOSITA's common knowledge, would have rendered the invention obvious.

---

Primary Obviousness Combination: Amron in view of Shvo and Her-daw-ih

A strong argument for obviousness can be made by combining the teachings of U.S. 2006/0069634 (Amron), U.S. 2002/0087520 (Shvo), and U.S. 2005/0240964 (Her-daw-ih).

1. Motivation to Combine:
   Amron explicitly discloses a "System and Method for Tracking and Targeting Advertising" across different media, including tracking both a user's "online behavior" and their "television viewing habits." The stated goal is to create a comprehensive user profile for more effective, targeted advertising. This provides a clear and explicit motivation for a PHOSITA to combine prior art systems for online ad targeting with systems for television ad targeting. A PHOSITA, tasked with building the cross-media system envisioned by Amron, would naturally look to existing art for the component pieces: a system for tracking online behavior and a system for delivering ads to a television.

2. Combining the Teachings:

   • Online Tracking Component (Shvo): Shvo teaches a robust system for online ad targeting. It discloses tracking a user's online activities (searches, websites visited) to build a user profile and using identifiers like cookies and the user's IP address to recognize the user. A PHOSITA would use Shvo's method to fulfill the "tracking online behavior" aspect of Amron's cross-media goal. This satisfies the claim elements of receiving an identifier and IP address from a first device and receiving user activity from that device.

   • Television Targeting Component (Her-daw-ih): Her-daw-ih teaches a system for providing targeted advertising within an interactive television network, specifically to a set-top box (STB). It describes collecting household information and using it to select and deliver ads to the STB. A PHOSITA would use Her-daw-ih's system as the mechanism to fulfill the "television" aspect of Amron's goal. This teaches the claim element of sending a targeted message to a second device (the STB).

3. The "Obvious" Step: Linking the Devices via a Shared IP Address:
   The claims require associating the two devices based on a shared public IP address. This is the crucial step that is not explicitly taught but would have been obvious to a PHOSITA in 2007. By that time, the use of broadband routers employing Network Address Translation (NAT) was standard for home internet access. A PHOSITA would have known, as a matter of fundamental networking principle, that all devices on a typical home network (e.g., a laptop and an IP-enabled STB) would communicate with the internet through a single, shared public IP address assigned to the modem/router by the ISP.

   Faced with Amron's goal of linking online activity with a television in the same household, a PHOSITA would have immediately recognized the shared public IP address as the most direct and readily available, non-personally identifiable signal that two devices are co-located. Observing requests from a PC (tracked per Shvo) and an STB (the target for ad delivery per Her-daw-ih) coming from the identical public IP address within a similar timeframe would be a simple and obvious method to infer that they belong to the same household. Creating an electronic association in a database (e.g., link(PC_cookie, STB_ID) where IP(PC) == IP(STB)) would be a routine implementation step.

   Therefore, the combination of Amron's motivation for cross-media targeting, Shvo's method for online tracking, and Her-daw-ih's system for TV ad delivery, when combined with the common knowledge of a PHOSITA about home networking (NAT and shared IP addresses), renders the claimed invention obvious.

---

Secondary Obviousness Combination: Huddersfield and Her-daw-ih

A similar argument can be constructed using U.S. 7,734,510 (Huddersfield) as the primary reference for online tracking, combined with Her-daw-ih.

• Huddersfield teaches a method for presenting an advertisement by collecting user information, including the user's IP address, and tracking their behavior across different websites to build a profile for ad targeting.
• Her-daw-ih teaches the delivery of targeted ads to an STB based on household profiles.

Motivation and Combination: The motivation to combine remains the strong commercial and technical desire to leverage rich online behavioral data for targeting high-value television advertising space. A PHOSITA seeking to improve the targeting described in Her-daw-ih would naturally look to the more mature and data-rich world of online advertising, as described in Huddersfield.

As in the previous combination, the key step of using the shared IP address as the linking mechanism would have been an obvious implementation choice for a PHOSITA. Huddersfield already uses the IP address as a key piece of user information. Her-daw-ih's STB, being a networked device, would also have an IP address. The PHOSITA would recognize that if these IP addresses match, the devices are almost certainly in the same location. Combining the profile data from Huddersfield's system with the delivery mechanism of Her-daw-ih's system, using the shared IP address as the bridge, would be an obvious path to a more effective targeted TV advertising system.

Conclusion

The independent claims of the '398 patent describe a commercially valuable and functional system. However, the inventive concept does not appear to rise to the level of non-obviousness required for patentability. The prior art clearly establishes the separate components: tracking online user behavior via IP addresses and cookies for ad targeting (Shvo, Huddersfield) and delivering targeted ads to set-top boxes (Her-daw-ih). Furthermore, the desire to link these different media for more comprehensive ad targeting was explicitly known in the art (Amron).

The specific mechanism for linking the devices—identifying a shared public IP address—was not a novel technical discovery but rather an application of a well-understood and fundamental characteristic of consumer internet architecture in 2007. For a PHOSITA tasked with creating a cross-media advertising system, using the shared IP address to associate a PC and an STB within a single household would have been an obvious, if not the most logical, design choice. Therefore, the independent claims of the '398 patent are likely invalid as obvious under 35 U.S.C. § 103.

U.S. Patent 8,677,398: Term, Application History, and Family Details

Date of Analysis: April 30, 2026

An analysis of the public records for U.S. Patent No. 8,677,398 ("the '398 patent") reveals a complex prosecution history, including several continuation applications and a significant patent term adjustment. This activity directly impacts the patent's enforceability and projected expiration date.

Patent Term and Expiration

• Issue Date: March 18, 2014
• Original Expiration: The standard 20-year term for a U.S. patent is calculated from the filing date of the earliest non-provisional application in its family. The '398 patent's lineage traces back to U.S. Application No. 11/736,544, filed on April 17, 2007. This would normally result in an expiration date of April 17, 2027.
• Patent Term Adjustment (PTA): The United States Patent and Trademark Office (USPTO) granted a Patent Term Adjustment to compensate for administrative delays during the patent's prosecution. While the precise calculation of this adjustment is detailed in the patent's file history, public records indicate an adjusted expiration date.
• Projected Expiration Date: The adjusted expiration date for U.S. Patent 8,677,398 is May 1, 2027. This date incorporates the granted PTA.
• Patent Term Extension (PTE): There is no indication in the public record that the '398 patent has been granted a Patent Term Extension (PTE). PTE is typically associated with delays in regulatory approval for products like pharmaceuticals and is not applicable in this case.

Application and Family History

The '398 patent is part of a larger family of patents and applications, descending from an initial filing in 2007. This is a common strategy used to pursue claims of varying scope related to the core invention.

• Application Number: The application that matured into the '398 patent is U.S. Application No. 13/167,605, filed on June 23, 2011.

• Continuity Data: This application is a continuation of a prior application, creating a chain of lineage that establishes its priority date.

  • This application (13/167,605) is a continuation of U.S. Application No. 12/860,666, filed on August 20, 2010 (now U.S. Patent No. 8,281,336).
  • Application No. 12/860,666 is, in turn, a continuation of U.S. Application No. 11/736,544, filed on April 17, 2007 (now U.S. Patent No. 7,861,260).

• Parent Patents:

  • U.S. Patent No. 8,281,336
  • U.S. Patent No. 7,861,260

• Child Applications: The family originating from the initial 2007 application has been significantly expanded with numerous subsequent continuation and divisional applications, indicating an active and ongoing strategy by the assignee, Intent IQ LLC, to protect its technology. Public records show a series of newer applications claiming priority to this family, including applications filed as recently as April 26, 2024 (U.S. Application No. 18/647,861).

There are no divisional applications directly from the 13/167,605 application apparent in the immediate public record, with the subsequent filings being structured as continuations that build upon the earlier applications in the chain.

Defensive Disclosure and Prior Art Generation

RE: U.S. Patent 8,677,398
Publication Date: April 30, 2026
Author: Senior Patent Strategist and Research Engineer
Abstract: This document discloses a series of methods, systems, and applications that build upon, vary, or invert the core concepts described in U.S. Patent 8,677,398. The purpose of this disclosure is to place in the public domain a range of foreseeable modifications and applications of the technology, thereby establishing prior art against future patent claims on these or similar concepts. The disclosures herein cover alternative components and protocols, operation in extreme environments, novel cross-domain applications, integration with emerging technologies like AI and blockchain, and privacy-centric or resource-constrained operational modes.

---

Section 1: Component and Protocol Substitution

The core mechanism of associating devices via a shared public IP address can be achieved with numerous alternative network identifiers and protocols, each with distinct advantages in different network topologies.

1.1. Association via IPv6 Prefix Delegation

• Enabling Description: In an IPv6-native environment, a single household is often assigned a stable network prefix (e.g., a /56 or /64 subnet) by an ISP via DHCPv6 Prefix Delegation (PD). All devices within the local network will subsequently derive their unique global IPv6 addresses from this shared prefix. A central server can associate devices by observing that their IPv6 addresses share the same delegated prefix, even if the full addresses are different. This method is more stable than NAT-based IPv4 association, as the prefix is typically long-lived. The server would ingest device identifiers and their full IPv6 addresses, apply a bitmask for the delegated prefix length, and use the resulting common prefix as the key for association.
• Diagram:

  sequenceDiagram
      participant DeviceA as Device A (Mobile)
      participant DeviceB as Device B (STB)
      participant Router
      participant ISP
      participant AdServer as Association Server
  
      DeviceA->>Router: DHCPv6 Solicit
      Router->>ISP: DHCPv6 PD Request
      ISP-->>Router: Assigns Prefix (e.g., 2001:db8:1234::/56)
      Router-->>DeviceA: Assigns IPv6 (2001:db8:1234:0:..:A)
      DeviceB->>Router: DHCPv6 Solicit
      Router-->>DeviceB: Assigns IPv6 (2001:db8:1234:0:..:B)
      
      DeviceA->>+AdServer: Report (ID_A, 2001:db8:1234:0:..:A)
      AdServer->>AdServer: Store: Prefix(2001:db8:1234::/56) -> ID_A
      DeviceB->>+AdServer: Report (ID_B, 2001:db8:1234:0:..:B)
      AdServer->>AdServer: Match Prefix! Associate ID_A and ID_B
      deactivate AdServer
  

1.2. Association via Network BSSID and SSID

• Enabling Description: Mobile and stationary devices on a Wi-Fi network are aware of the Basic Service Set Identifier (BSSID), which is the MAC address of the wireless access point, and the Service Set Identifier (SSID), which is the network name. A client-side agent on each device can report the BSSID and/or a hash of the SSID to a central server along with the device's unique identifier. The server can then associate devices that report the same BSSID within a given time window. This method is independent of the public IP address and can distinguish between different access points within the same location (e.g., "Guest" vs. "Home" networks).
• Diagram:

  flowchart TD
      subgraph DeviceA
          A1[Client Agent]
          A2[Wi-Fi Radio]
      end
      subgraph DeviceB
          B1[Client Agent]
          B2[Wi-Fi Radio]
      end
      
      subgraph "Wi-Fi AP"
          C1["SSID: MyHome_WiFi"]
          C2["BSSID: 0A:1B:2C:3D:4E:5F"]
      end
  
      subgraph AssociationServer
          D1{Association Logic}
          D2[Database]
      end
  
      A2 -- Scans --> C1 & C2
      B2 -- Scans --> C1 & C2
      A1 -- "ID_A, BSSID" --> D1
      B1 -- "ID_B, BSSID" --> D1
      D1 -- "BSSIDs match" --> D2[Link ID_A & ID_B]
  

1.3. Association via mDNS/Bonjour Service Discovery

• Enabling Description: Devices on a local network can discover each other using zero-configuration protocols like multicast DNS (mDNS). A client-side agent on a first device (e.g., a phone) could broadcast a specific mDNS service type (e.g., _my-app-association._tcp.local). An agent on a second device (e.g., a smart TV) on the same network would listen for this service type. Upon discovery, the two devices establish a direct peer-to-peer connection and exchange unique identifiers. One of the devices then reports the now-linked pair of identifiers to the central server, which finalizes the association. This method is decentralized and confirms direct LAN-level connectivity.
• Diagram:

  sequenceDiagram
      participant Phone as Device A (Phone)
      participant TV as Device B (TV)
      participant Server as Central Server
  
      Phone->>Multicast: mDNS Announce _my-app._tcp
      TV->>Multicast: mDNS Listen for _my-app._tcp
      TV-->>Phone: Discovered!
      Phone->>TV: Exchange Identifiers (ID_A, ID_B)
      TV-->>Phone: Acknowledge
      Phone->>Server: Report Association (ID_A, ID_B)
      Server->>Server: Store Association
  

---

Section 2: Operational Parameter Expansion

The core concept is adapted to operate under extreme network conditions and at massive industrial scales.

2.1. High-Latency/Asynchronous Network Association (Maritime/Satellite)

• Enabling Description: For devices connected via high-latency satellite or VSAT links, real-time IP address matching is unreliable. In this system, each device maintains a local, time-stamped log of its public IP address history. When a device establishes a stable connection, it uploads its identifier and this historical IP log to a central server. The server's logic processor does not look for a real-time match but instead searches for overlapping IP address tenures between the logs of different devices. An association is created if two devices held the same IP address for a significant, overlapping period (e.g., >1 hour) within the last 24-48 hours. Actions triggered by activity are then queued for delivery until the target device next polls the server.
• Diagram:

  graph TD
      subgraph "Device A (On Ship)"
          A1[IP Logger] --> A2(Log: [IP1, T1-T5])
          A3[Batch Uploader]
      end
      subgraph "Device B (On Ship)"
          B1[IP Logger] --> B2(Log: [IP1, T2-T6])
          B3[Batch Uploader]
      end
      subgraph "Central Server (Onshore)"
          C1[Data Ingest]
          C2{Time-Series IP Analysis}
          C3[Association DB]
      end
      
      A3 -- Sporadic Connection --> C1
      B3 -- Sporadic Connection --> C1
      C1 --> C2
      C2 -- "Overlap detected for IP1 at T2-T5" --> C3
      C3 --> C2
      style C2 fill:#f9f,stroke:#333,stroke-width:2px
  

2.2. Carrier-Grade NAT (CGNAT) Level Association

• Enabling Description: In many mobile and some fixed-line networks, multiple households share a single public IP address via Carrier-Grade NAT. To disambiguate households behind a CGNAT, this system leverages additional network parameters available to the carrier. The association server ingests not only the public IP but also the source port range and a timestamp from the network's BNG (Broadband Network Gateway) or GGSN. The carrier's network elements assign specific port ranges to each subscriber's session. The server associates devices if they originate from the same public IP and their source ports fall within the same allocated range for a given session, thereby correctly identifying a single household even behind a shared public IP.
• Diagram:

  classDiagram
    CGNAT_Router {
      +public_ip: IPAddress
      +assignPortRange(session)
    }
    Session {
      <<Entity>>
      session_id
      subscriber_id
      assigned_port_range
    }
    Device {
      <<Entity>>
      device_id
      source_ip
      source_port
    }
    AssociationServer {
      +correlate(device_a, device_b)
    }
    CGNAT_Router "1" -- "N" Session
    Session "1" -- "N" Device
    AssociationServer ..> Device : analyzes
    AssociationServer ..> Session : correlates with
  

---

### **Section 3: Cross-Domain Applications**

The core mechanism is applied to non-advertising use cases in distinct industrial sectors.

#### **3.1. Industrial IoT: Context-Aware Machine Control**
*   **Enabling Description:** A factory floor maintenance technician uses a ruggedized tablet (Device A) to diagnose a specific CNC machine (Device B). Both the tablet and the machine's control unit are connected to the same industrial Wi-Fi network and thus share a public IP address through the factory's gateway. When the technician uses an app on the tablet to look up the service manual for "CNC Model XYZ", the app notifies a central factory management server. The server, having already associated the tablet with the CNC machine via their shared IP, sends a command via the OPC UA protocol to the machine's PLC. The command places the machine into a safe, diagnostic mode and illuminates the specific component referenced in the manual, guiding the technician.
*   **Diagram:**
    ```mermaid
    sequenceDiagram
        participant Tablet as Technician Tablet (A)
        participant CNC_PLC as CNC Machine PLC (B)
        participant FactoryServer as Factory Mgmt Server
        
        Tablet->>+FactoryServer: Report (Tablet_ID, Public_IP)
        CNC_PLC->>+FactoryServer: Report (CNC_ID, Public_IP)
        FactoryServer->>FactoryServer: Associate Tablet_ID & CNC_ID
        deactivate FactoryServer
        
        Tablet->>FactoryServer: Event: "Viewed Schematic for Part P42"
        FactoryServer->>CNC_PLC: Command: EnterDiagnosticMode(Target=P42)
        CNC_PLC-->>FactoryServer: Acknowledged
        CNC_PLC->>CNC_PLC: Illuminate LED on Part P42
    ```

#### **3.2. Healthcare: Synchronized Clinical Workflows**
*   **Enabling Description:** A nurse's workstation-on-wheels (WOW) computer (Device A) and a patient's in-room smart infusion pump (Device B) are connected to the same secured hospital Wi-Fi network segment, sharing an IP address visible to the internal hospital services network. When the nurse authenticates and accesses a patient's Electronic Health Record (EHR) on the WOW, the EHR system sends an event to a Clinical Workflow Orchestrator server. This server recognizes the WOW's IP address matches the one recently reported by the patient's infusion pump. Based on this association, it pushes context-specific information to the pump's display, such as "Awaiting dosage confirmation for Jane Doe," and pre-loads the prescribed medication and dosage parameters, requiring only the nurse's final confirmation on the pump itself to begin infusion.
*   **Diagram:**
    ```mermaid
    flowchart LR
        subgraph Hospital Network (Same IP Subnet)
            A[Nurse WOW - Device A]
            B[Infusion Pump - Device B]
        end
        
        C[Clinical Orchestrator Server]
        D[EHR System]
        
        A -- "Accesses Patient X Record" --> D
        D -- "Event: RecordAccessed(Patient X, WOW_ID)" --> C
        B -- "Heartbeat(Pump_ID, IP_Address)" --> C
        A -- "Heartbeat(WOW_ID, IP_Address)" --> C
        
        C -- "1. IP Match => Associate(WOW, Pump)" --> C
        C -- "2. Push Context to Pump B" --> B
        B -- "Display: 'Confirm Dosage for Patient X'" --> B
    ```

#### **3.3. Automotive: Seamless In-Car Experience Handoff**
*   **Enabling Description:** A vehicle's Telematics Control Unit (TCU) provides an in-car Wi-Fi hotspot, acting as a router. A passenger's smartphone (Device A) connects to this hotspot. The car's head unit/infotainment system (Device B) is also on this local network. Both devices communicate to the OEM's cloud services via the TCU's LTE connection, thus sharing the same public IP address. When the passenger uses a music streaming app on their phone, the app notifies the streaming service's backend. The backend informs the OEM cloud service. The OEM service, seeing the phone and the head unit share an IP, sends a message to the head unit, which then displays "Now Playing" information on its screen and offers playback controls, synchronizing the in-car experience without requiring Bluetooth pairing.
*   **Diagram:**
    ```mermaid
    graph TD
        subgraph Vehicle
            A(Passenger Phone) -- Wi-Fi --> R{In-Car Hotspot (TCU)};
            B(Head Unit) -- Wi-Fi --> R;
            R -- LTE --> Internet;
        end
        
        subgraph CloudServices
            OEM[OEM Cloud]
            Music[Music Service]
        end
        
        A -- "Activity: Play Song X" --> Music;
        R -- "Source IP: 198.51.100.5" --> Internet;
        B -- "Heartbeat from HeadUnit_ID @ 198.51.100.5" --> OEM;
        Music -- "Notify Playback(User_Y, Song_X) from 198.51.100.5" --> OEM;
        OEM -- "Match IP: Associate HeadUnit & User_Y" --> OEM;
        OEM -- "Command: Display(Song_X)" --> B;
    ```

---

### **Section 4: Integration with Emerging Technologies**

#### **4.1. AI-Driven Probabilistic Association**
*   **Enabling Description:** This system uses a machine learning model (e.g., a Gradient Boosting classifier) to determine the probability that two devices belong to the same household, even when their IP addresses do not match. The model is trained on a dataset of confirmed device pairs. Features for the model include: the first 3 octets of the IP address (IP subnet), the Autonomous System Number (ASN) of the ISP, device User-Agent strings (to identify device type), temporal access patterns (e.g., co-activity during evening hours), and previously associated IP addresses. When new device activity is reported, the server computes a feature vector and the model outputs a probability score. If the score exceeds a configurable threshold (e.g., 95%), the devices are associated, allowing for targeting across a user's mobile (cellular IP) and home (Wi-Fi IP) sessions.
*   **Diagram:**
    ```mermaid
    flowchart TD
        A[Device A Activity<br>IP: 203.0.113.10<br>Time: 19:05<br>UA: Mobile] --> F1[Feature Extractor];
        B[Device B Activity<br>IP: 198.51.100.50<br>Time: 19:08<br>UA: SmartTV] --> F1;
        F1 --> FV{{Feature Vector<br>/24 Subnets<br>ASNs<br>Time Delta<br>UA Types}};
        FV --> M{ML Model};
        M -- "Prob(Match) = 0.98" --> D{Threshold > 0.95?};
        D -- Yes --> R[Associate Devices];
        D -- No --> E[Do Not Associate];
    ```

#### **4.2. Blockchain-Managed Consent and Micro-payments**
*   **Enabling Description:** A decentralized application (dApp) is used by the user to manage consent for cross-device targeting. The user's preferences are stored in a smart contract on a public blockchain (e.g., Ethereum). When the association server identifies a potential device pairing, it first queries the smart contract to verify that the user has opted-in. The user's activity on the first device triggers a transaction to the smart contract. A second transaction is logged when a targeted action is delivered to the second device. This creates an immutable, user-auditable trail. Furthermore, the advertiser can pre-load the smart contract with cryptocurrency, which is then automatically distributed as a micro-payment to the user's wallet each time a targeted action is successfully delivered and viewed, creating a transparent value exchange.
*   **Diagram:**
    ```mermaid
    sequenceDiagram
        participant User
        participant DeviceA
        participant DeviceB
        participant Server
        participant Blockchain

        User->>Blockchain: Deploy ConsentContract(opt_in=true)
        DeviceA->>Server: Activity from IP_1
        DeviceB->>Server: Activity from IP_1
        Server->>Server: Potential Match Found
        Server->>Blockchain: Query: ConsentContract.isOptIn()?
        Blockchain-->>Server: Response: true
        Server->>DeviceB: Send Targeted Action
        Server->>Blockchain: Log Tx: ActionSent(DeviceA, DeviceB)
        DeviceB->>Server: Action Viewed
        Server->>Blockchain: Execute Tx: TransferMicroPayment(to_user_wallet)
    ```
---

### **Section 5: The "Inverse" and Safe-Failure Modes**

#### **5.1. Graceful Degradation to Privacy-Preserving Mode**
*   **Enabling Description:** The system is designed to operate in a "Limited Functionality" mode to respect user privacy or operate under certain legal jurisdictions (e.g., GDPR). In this mode, the server does not store full IP addresses. Instead, it uses a cryptographic one-way hash function (e.g., SHA-256) with a rotating daily salt on the IP address. The server associates devices only if their hashed IPs match. Furthermore, it only stores hashes of user activity categories (e.g., "sports enthusiast") rather than specific URLs visited. When a device checks in, its IP is hashed and compared to the stored activity hashes. If a match is found, a generic, category-based action is triggered on the associated device. The salt is discarded daily, breaking all associations and preventing long-term profiling.
*   **Diagram:**
    ```mermaid
    stateDiagram-v2
        [*] --> Full_Functionality
        Full_Functionality: Store Full IP<br>Store Specific User Activity<br>Precise Targeting
        Full_Functionality --> Limited_Privacy_Mode: User Opt-Out or Regulation Trigger

        Limited_Privacy_Mode: H = sha256(IP + daily_salt)<br>Store Hashed IP<br>Store Activity Category
        Limited_Privacy_Mode --> Full_Functionality: User Opt-In
        Limited_Privacy_Mode --> [*]: Session End / Salt Rotation

        state Fork1 <<fork>>
        Limited_Privacy_Mode --> Fork1
        Fork1 --> Hash_IP
        Fork1 --> Categorize_Activity

        state Join1 <<join>>
        Hash_IP --> Join1
        Categorize_Activity --> Join1
        Join1 --> Store_Anonymized_Data
        Store_Anonymized_Data --> Match_And_Trigger
    ```
---

### **Section 6: Combination with Open-Source Standards**

#### **6.1. Combination with the Matter Standard for Smart Homes**
*   **Enabling Description:** A user's smartphone (Device A) and a Matter-enabled smart display (Device B) are commissioned onto the same home Wi-Fi and Thread network, making them part of the same Matter "fabric". A cloud service, which has been granted access to the fabric, observes an HTTP request from the smartphone originating from a specific public IP address. The service's backend notes that the user was searching for vacuum cleaner reviews. Independently, the smart display checks in with the same cloud service from the same public IP. Recognizing the shared IP and fabric co-membership, the service uses the Matter application layer protocol to send a targeted message not as a generic ad, but as a contextual "card" to the smart display's UI, showing a "card" with pricing for the reviewed vacuum cleaner at a local store.
*   **Diagram:**
    ```mermaid
    erDiagram
        USER }o--|| SMARTPHONE : uses
        USER }o--|| SMART_DISPLAY : owns
        SMARTPHONE ||--o{ "MATTER FABRIC" : belongs
        SMART_DISPLAY ||--o{ "MATTER FABRIC" : belongs
        "MATTER FABRIC" ||--|{ WIFI_NETWORK : runs_on
        
        SMARTPHONE {
            string DeviceID
            string ActivityData
        }
        SMART_DISPLAY {
            string DeviceID
        }
        
        CLOUD_SERVICE {
            string AssociationLogic
            string MatterAPI_Endpoint
        }

        SMARTPHONE o..o CLOUD_SERVICE : "reports activity via IP"
        SMART_DISPLAY o..o CLOUD_SERVICE : "reports presence via IP"
        CLOUD_SERVICE o..o SMART_DISPLAY : "sends contextual card via Matter API"

    ```
#### **6.2. Combination with OpenID Connect (OIDC) for Authenticated Experiences**
*   **Enabling Description:** A user logs into a news website on their laptop (Device A) using a third-party OIDC identity provider (e.g., "Sign in with AcmeID"). The OIDC provider's server records the successful authentication event, the client_id of the news website, and the source IP address. Later, the user opens a Connected TV (CTV) app (Device B) and uses the OIDC "device flow" to log in with the same AcmeID. The CTV app also reports its public IP. The OIDC provider's backend service joins these two events on the user's identity and sees the shared IP address, creating a strong association. Based on the user reading financial news on Device A, the OIDC service can pass an additional `audience_segment: 'finance'` claim in the ID Token it issues to the CTV app, allowing the app to personalize its home screen with a "Stock Market Today" widget.
*   **Diagram:**
    ```mermaid
    sequenceDiagram
        actor User
        participant Laptop as Laptop (Device A)
        participant OIDC as OIDC Provider
        participant CTV as CTV App (Device B)

        User->>Laptop: Clicks "Sign in with AcmeID"
        Laptop->>OIDC: AuthN Request
        OIDC-->>Laptop: Returns Auth Code
        Laptop->>OIDC: Token Request (from IP_1)
        OIDC->>OIDC: Log: User_X, IP_1, Client_News
        
        User->>CTV: Chooses "Sign in with AcmeID"
        CTV->>OIDC: Device AuthZ Request (from IP_1)
        OIDC->>OIDC: Join on User_X and IP_1
        OIDC->>OIDC: Infer context ('finance')
        OIDC-->>CTV: ID Token with claim "audience_segment: 'finance'"
        CTV->>CTV: Personalize UI based on claim
    ```

#### **6.3. Combination with MQTT for IoT Messaging**
*   **Enabling Description:** An array of environmental sensors (e.g., temperature, humidity; Devices A) in a smart greenhouse all publish their data to a public MQTT broker under topics like `greenhouse/z1/temp`. A central climate control system (Device B) subscribes to a command topic `greenhouse/z1/control`. A cloud-based analytics service subscribes to all `greenhouse/z1/#` topics. The service notices that all sensor telemetry and the controller's connection originate from the same static IP address of the greenhouse. When the analytics service processes the data stream from the temperature sensor and detects an anomaly (e.g., a sudden spike), it immediately publishes a command message to the `greenhouse/z1/control` topic (e.g., `{"actuator": "vent", "state": "open"}`), directly triggering an action on the co-located control system without needing to know its specific internal IP address.
*   **Diagram:**
    ```mermaid
    graph TD
        subgraph Greenhouse LAN (Shared Public IP)
            A[Temp Sensor] -- pub: /z1/temp --> B((MQTT Broker));
            C[Humidity Sensor] -- pub: /z1/humidity --> B;
            D[Control System] -- sub: /z1/control --> B;
        end
        
        E[Cloud Analytics] -- sub: /z1/# --> B;
        E -- "Analyzes data stream" --> F{Anomaly Detected?};
        F -- Yes --> G[Publish Command];
        G -- pub: /z1/control --> B;
    ```