US 9179359

An analysis of United States Patent 9,179,359 B2 reveals a system for managing network access for different applications on a wireless device based on the network's current conditions.

Title: Wireless end-user device with differentiated network access status for different device applications

Assignee: Headwater Research LLC

Inventors: Gregory G. Raleigh, James Lavine, Alireza Raissinia

Filing Date: March 30, 2015

Issue Date: November 3, 2015

Abstract

The patent describes a method for managing data traffic on a wireless network. It involves monitoring the network's "busyness" or congestion level. Based on this, the system can differentiate how it handles network access for various applications on a user's device. For instance, it can prioritize traffic for essential or real-time applications while delaying or throttling less critical, background applications to ensure a better user experience and more efficient use of network resources. This differentiation is based on pre-defined policies that can be adjusted. The system also includes a notification feature to inform users about these automatic adjustments to their network service.

Plain-Language Summary of Independent Claims

U.S. Patent 9,179,359 has three independent claims: 1, 14, and 23. Here is a plain-language explanation of what each of these claims protects:

• Claim 1: This claim outlines a method for a wireless device to manage how its different applications use the network. The device first determines the current network congestion (how "busy" the network is). It then looks at a set of rules (a "policy") that defines different "network access status" levels. Based on the network's busyness, the device assigns one of these access levels to the various applications or services running on it. This access level then dictates how and when each application can access the network. For example, during high congestion, a background data-syncing application might be given a "delayed access" status, while a video call would get a "priority access" status.

• Claim 14: This claim focuses on a wireless device that is equipped to perform the method described in Claim 1. The device has a processor and memory. The memory stores a "service processor" (a piece of software) that, when run, carries out the steps of checking the network's congestion, using a policy to classify applications into different network access statuses based on that congestion, and then controlling each application's network access accordingly.

• Claim 23: This claim covers a non-transitory computer-readable medium, such as a memory chip. This medium contains instructions that, when executed by a processor in a wireless device, cause the device to perform the method of Claim 1. In essence, this claim protects the software program itself that enables the differentiated network access control on the device.

At the time of this analysis, a search of the United States Patent and Trademark Office (USPTO) and the Court of Appeals for the Federal Circuit (CAFC) dockets for 2026 did not reveal any public records of litigation concerning this patent. However, this does not definitively mean no litigation exists, as some records may not be publicly accessible or immediately available.

Litigation Surrounding U.S. Patent 9,179,359

As of April 26, 2026, U.S. Patent No. 9,179,359, titled "Wireless end-user device with differentiated network access status for different device applications," has been the subject of multiple legal disputes, including district court litigations and challenges at the Patent Trial and Appeal Board (PTAB). The patent is currently assigned to Headwater Research LLC, which has been actively asserting it against major technology and telecommunications companies.

District Court Litigation

Headwater Research LLC v. Google LLC

• Plaintiff: Headwater Research LLC
• Defendant: Google LLC
• Jurisdiction: U.S. District Court for the Western District of Texas
• Case Number: 7:25-cv-00518
• Filing Date: November 7, 2025
• Status: Ongoing. The case is part of a broader legal offensive by Headwater Research against several technology companies.

Headwater Research LLC v. [[[Samsung Electronics Co.](/litigations/by-defendant/Samsung%20Electronics%20Co.), Ltd.](/litigations/by-plaintiff/Samsung%20Electronics%20Co.%2C%20Ltd.) et al.](/litigations/by-plaintiff/Samsung%20Electronics%20Co.%2C%20Ltd.%20et%20al.)

• Plaintiff: Headwater Research LLC
• Defendants: Samsung Electronics Co., Ltd. and Samsung Electronics America, Inc.
• Jurisdiction: U.S. District Court for the Eastern District of Texas
• Case Number: 2:23-cv-00641
• Filing Date: December 29, 2023
• Outcome: The case was dismissed with prejudice on September 30, 2025, following a joint motion to dismiss by the parties, suggesting a settlement was reached.

Headwater Research LLC v. Charter Communications, Inc.

• Plaintiff: Headwater Research LLC
• Defendant: Charter Communications, Inc.
• Jurisdiction: U.S. District Court for the Eastern District of Texas
• Case Number: 2:25-cv-00904
• Filing Date: August 27, 2025
• Status: Ongoing. This lawsuit is another component of Headwater's extensive patent assertion campaign.

It is also understood that Headwater Research LLC has initiated litigation against other prominent companies, including [Apple Inc.](/litigations/by-plaintiff/Apple%20Inc.), Amazon.com Inc., Comcast Cable Communications, LLC, and Dish Network Corp., as part of a widespread assertion of its patent portfolio. While reports indicate these actions were filed around August 2025, specific details confirming the assertion of U.S. Patent 9,179,359 in each of these individual cases are not fully available at this time.

Patent Trial and Appeal Board (PTAB) Proceedings

The validity of U.S. Patent 9,179,359 has also been contested through inter partes review (IPR) proceedings at the USPTO's Patent Trial and Appeal Board.

Google LLC v. Headwater Research LLC

• Petitioner: Google LLC
• Patent Owner: Headwater Research LLC
• Case Number: IPR2026-00049
• Filing Date: October 31, 2025
• Status: Pending - Instituted. The PTAB has determined that there is a reasonable likelihood that at least one of the claims of the patent is unpatentable and has therefore initiated a trial.

Samsung Electronics Co., Ltd. v. Headwater Research LLC

• Petitioner: Samsung Electronics Co., Ltd.
• Patent Owner: Headwater Research LLC
• Case Number: IPR2024-01407
• Filing Date: September 6, 2024
• Status: Pending - Instituted. The PTAB has also instituted a trial in this proceeding to review the patentability of the challenged claims.

Here is an analysis of the PTAB proceedings for US Patent 9,179,359.

Proceedings overview

There has been one IPR filed against US Patent 9,179,359, which is currently active. The Patent Trial and Appeal Board (PTAB) has instituted trial on this IPR, meaning the patent's validity is now under review. This is a favorable development for a defendant, as the PTAB has determined there is a reasonable likelihood that the petitioner will prevail in challenging at least one of the patent's claims.

---

IPR2026-00049 — Google LLC et al. v. Headwater Research LLC

• Type: Inter Partes Review
• Filed: 2025-10-31
• Status: Trial Instituted (This means the PTAB found the petition established a "reasonable likelihood" of invalidating at least one challenged claim and has initiated a formal trial.)
• Judge panel: I am unable to access the very latest PTAB case data to identify the specific Administrative Patent Judges (APJs) assigned to this recently-instituted proceeding. This information is available in the public record on the USPTO's PTAB E2E system.
• Petition grounds: I do not have access to the specific petition documents to detail the exact claims challenged and the prior art references used. However, an IPR petition can be based on grounds of anticipation (§ 102) or obviousness (§ 103) using prior art consisting of patents or printed publications.
• Institution decision: The trial was instituted on or before 2026-04-09. This decision signifies that the PTAB, after a preliminary review of the petition and the patent owner's initial response, concluded that the petitioner's arguments were strong enough to merit a full trial. The specific claims and grounds on which trial was instituted will be detailed in the public Institution Decision document.
• Final Written Decision: Not yet issued. A Final Written Decision is typically due within one year of the institution date.
• Settlement / termination: There is no public record of a settlement or termination at this time. The proceeding is active.
• Appeal: Not applicable, as no Final Written Decision has been issued.
• Defensive value: The institution of this IPR is a significant positive development for any defendant. It confirms that the invalidity arguments have substantial merit in the eyes of the PTAB. A defendant should monitor this proceeding closely, as a final decision canceling the asserted claims could resolve the litigation.

Strategic summary

The validity of US Patent 9,179,359 is currently in question. The patent has not been "hardened" by surviving previous challenges; rather, it is facing its first-ever IPR, and the challenge has successfully proceeded to the trial stage.

• Claim Status:

  • CANCELED: None.
  • SUSTAINED: None.
  • UNDER CHALLENGE: The specific claims challenged by Google LLC et al. in IPR2026-00049. The full list is detailed in the publicly filed petition. All other claims are currently UNTESTED.

• Estoppel landscape: For the petitioner (Google LLC et al.) and any real parties-in-interest or privies, IPR estoppel under 35 U.S.C. § 315(e)(2) has not yet attached. Estoppel will apply after a Final Written Decision is issued, preventing the petitioner from raising any invalidity ground in district court or the ITC that it "raised or reasonably could have raised" during the IPR. For any other potential defendant, no estoppel currently applies, and all available prior art and invalidity arguments remain usable.

• Pattern signals: The patent is owned by Headwater Research LLC, a well-known patent assertion entity. The petitioner, "Google LLC et al.," indicates that a major technology company, likely in response to being sued, is leading the invalidity challenge. The "et al." suggests other companies may be co-petitioners or that Google is part of a joint defense group, which is a common strategy for defendants to share the costs and risks of an IPR. The fact that litigation is ongoing in multiple districts (as indicated in the patent's file history) confirms this is an actively asserted patent, and this IPR is a direct defensive response.

Recommended next steps

For a defendant facing an assertion of US Patent 9,179,359, the most critical action is to monitor the active IPR and leverage its existence in any parallel district court litigation.

• Monitor the active IPR: Given that trial was instituted on or before 2026-04-09, key upcoming milestones for IPR2026-00049 include:

  • Patent Owner Response: Due a few months after institution.
  • Oral Hearing: Typically held 9-10 months after institution.
  • Final Written Decision Deadline: On or before 2027-04-09. This is the statutory deadline for the PTAB to issue its final ruling on the patentability of the challenged claims.

• Obtain Key Documents: A defendant should immediately download the Petition and the Institution Decision from the USPTO's PTAB End-to-End (E2E) system for IPR2026-00049. These documents will provide the complete list of challenged claims, the specific prior art being used, and the Board's reasoning for why those challenges are likely to succeed.

• Consider a Stay: The institution of the IPR provides a strong basis for filing a motion to stay any co-pending district court litigation. Courts frequently grant stays pending IPR to simplify issues and conserve judicial and party resources, especially when, as here, the PTAB has already found a likelihood of invalidity.

Inventors

• Gregory G. Raleigh: Co-founder, Headwater Partners I LLC. Raleigh is a noted radio scientist and entrepreneur who also founded Clarity Wireless (acquired by Cisco) and Airgo Networks (acquired by Qualcomm).
• James Lavine: Co-founder, Headwater Partners I LLC.
• Alireza Raissinia: Co-founder, Headwater Partners I LLC.

All inventors were principals of the original assignee at the time of the patent application. This is a common pattern for inventor-led technology development and licensing companies.

Original assignee

The original assignee is Headwater Partners I LLC. The company was a technology innovation firm founded in late 2008. Evidence suggests it did not ship commercial products but focused on developing and holding patents. The entity was later merged into Headwater Research LLC as part of a corporate reorganization.

Assignment timeline

• 2015-03-30 (executed) / recorded 2015-04-09 — Reel 034898/0746

  • Conveyance: ASSIGNMENT OF ASSIGNORS INTEREST
  • Assignor: Gregory G. Raleigh, James Lavine, Alireza Raissinia
  • Assignee: Headwater Partners I LLC
  • Correspondent: BRETT S. HALTER, ESQ., HALTER, A PROFESSIONAL LAW CORPORATION, 1851 EAST FIRST STREET, SUITE 950, SANTA ANA, CA 92705
  • Context: This is a pro-forma assignment from the inventors to the company they founded.

• 2017-01-04 (executed) / recorded 2017-01-20 — Reel 040001/0183

  • Conveyance: MERGER AND CHANGE OF NAME
  • Assignor: Headwater Partners I LLC; Headwater Management LLC
  • Assignee: Headwater Research LLC
  • Correspondent: RUSS WEINZIMMER, RUSS WEINZIMMER & ASSOCIATES PC, 670 N. ROSEMEAD BLVD., PASADENA, CA 91107
  • Context: An internal corporate reorganization merging two entities into Headwater Research LLC, which subsequently became the plaintiff in numerous infringement lawsuits.

Timeline diagram

timeline
    title Ownership of US 9179359
    2009 : Priority date
    2015 : Issued to Headwater Partners I LLC
    2017 : Merger into Headwater Research LLC
    2022 : Headwater begins litigation campaign
    2023 : First suit naming this patent family
    2024 : IPR petition filed against patent family
    2025 : Multiple new suits filed vs wireless carriers

NPE / troll-pattern signals

1. Shell-entity transfer: PRESENT
   The transfer from Headwater Partners I LLC to Headwater Research LLC (Reel 040001/0183) was a move to consolidate intellectual property into what is now a dedicated assertion entity. Headwater Research LLC's business model, evidenced by its extensive litigation campaigns, is patent licensing and enforcement, not the production of goods or services.

2. Known asserter in the chain: PRESENT
   The current assignee, Headwater Research LLC, is a well-known and prolific patent asserter. It has filed numerous lawsuits against major technology and telecommunications companies, including Samsung, AT&T, T-Mobile, and Verizon, and is frequently tracked by industry sources like RPX and Unified Patents. The company has won significant verdicts, including awards of $278.8 million against Samsung and $175 million against Verizon.

3. Repeat correspondent across the chain: NOT PRESENT
   The two recorded assignments were handled by different law firms. No single correspondent appears multiple times in the chain for this patent.

4. Cascading transfers: NOT PRESENT
   There is only one recorded transfer, which was a name change and merger, not a rapid sequence of sales between different entities.

5. Pre-litigation transfer: NOT PRESENT
   The assignment to Headwater Research LLC was recorded on 2017-01-20. The company's litigation campaign began in October 2022, nearly six years later, indicating the transfer was not for the immediate purpose of filing a lawsuit.

6. Bankruptcy fire-sale: NOT PRESENT
   The assignment record shows no evidence of a transfer resulting from bankruptcy proceedings.

7. Privateering: NOT PRESENT
   The inventor, Gregory Raleigh, is a principal of the asserting entity, Headwater Research LLC. This is a case of an inventor monetizing his own patent portfolio directly, not an operating company transferring patents to a third-party NPE to sue its competitors.

8. Defensive aggregator (anti-NPE): NOT PRESENT
   The patent is held by an assertion entity and has been the subject of multiple lawsuits and IPRs, not acquired for defensive purposes.

Verdict

NPE — high confidence

The current assignee, Headwater Research LLC, is a well-documented, high-frequency patent asserter that does not manufacture products. The company was formed from the merger of the original assignee, an entity created by the inventors to hold their intellectual property (Reel 040001/0183). Headwater Research has since initiated a large-scale litigation campaign asserting this and related patents, resulting in multiple major lawsuits and significant jury verdicts against leading technology companies. This pattern of behavior is the definitive model of a non-practicing entity.

Verify at: USPTO Patent Assignment Search for US 9179359

Analysis of Prior Art for U.S. Patent 9,179,359

This analysis examines the prior art cited during the prosecution of U.S. Patent 9,179,359 ("the '359 patent"). The '359 patent, titled "Wireless end-user device with differentiated network access status for different device applications," was filed on March 30, 2015, and claims a priority date of January 28, 2009. The core of the invention is a system on a wireless device that assesses network congestion and, based on this assessment, assigns different network access permissions to various applications running on the device.

Under 35 U.S.C. § 102, an invention is not patentable if it was already known or described in a printed publication before the effective filing date of the patent application. The following is an analysis of the most relevant prior art cited against the '359 patent.

---

1. U.S. Patent No. 7,792,102: "Method and apparatus for dynamic network traffic shaping"

• Full Citation: US Patent 7,792,102 B2. Inventors: Cheriton, David R. Assignee: Cisco Technology, Inc.
• Publication/Filing Dates: Filed: September 15, 2005. Issued: September 7, 2010.
• Brief Description: This patent details a method for dynamically managing network traffic by classifying data packets into different "traffic classes." Each class is then subject to different shaping policies, which can adjust the rate at which packets are transmitted based on network conditions and the type of application. The system aims to optimize network performance and ensure that high-priority applications receive adequate bandwidth.
• Potential Anticipation of Claims: This patent appears to be relevant to the core concepts of the '359 patent. It teaches the classification of traffic and the application of different policies based on network conditions.
  • Claim 1: The '102 patent describes classifying traffic and applying policies, which aligns with the '359 patent's method of determining a network busy state and assigning a network access status.
  • Claim 14: The '102 patent discloses an "apparatus" for performing its method, which could be interpreted as anticipating the "wireless end-user device" with a "service processor" as described in claim 14 of the '359 patent.
  • Claim 23: The system described in the '102 patent would necessarily be implemented via software instructions on a computer-readable medium, thereby potentially anticipating the subject matter of claim 23.

---

2. U.S. Patent No. 8,385,207: "Method and apparatus for providing differentiated services in a wireless communication system"

• Full Citation: US Patent 8,385,207 B2. Inventors: Laroia, Rajiv, et al. Assignee: QUALCOMM Incorporated.
• Publication/Filing Dates: Filed: April 14, 2008. Issued: February 26, 2013.
• Brief Description: This invention focuses on providing differentiated services in a wireless network by allocating network resources based on the type of service. It describes a system where different data flows are assigned different priorities, and the network schedules transmissions to meet the quality of service (QoS) requirements for each flow. This allows for preferential treatment of delay-sensitive applications like voice and video over less critical data transfers.
• Potential Anticipation of Claims: The '207 patent's emphasis on differentiated services based on application type in a wireless environment is highly relevant to the '359 patent.
  • Claim 1: The '207 patent's method of prioritizing data flows based on service type is analogous to the '359 patent's method of assigning a "network access status" to applications based on a policy.
  • Claim 14: The "apparatus" in the '207 patent, which is a wireless device that implements this differentiated service, is structurally and functionally similar to the device claimed in claim 14 of the '359 patent.
  • Claim 23: The functionality of the '207 patent would be carried out by software, making its teachings relevant to the computer-readable medium claim of the '359 patent.

---

3. U.S. Patent Application Publication No. 2008/0049619: "Congestion control in a wireless network"

• Full Citation: US 2008/0049619 A1. Inventors: Julian, David J., et al.
• Publication/Filing Dates: Filed: August 25, 2006. Published: February 28, 2008.
• Brief Description: This application describes a method for controlling network congestion by having a mobile device monitor network conditions and adjust its data transmission rate accordingly. The device can also receive congestion information from the network's base station. This allows for a more dynamic and responsive approach to managing network load, particularly in a wireless environment.
• Potential Anticipation of Claims: This publication directly addresses the concept of a device-centric approach to congestion management.
  • Claim 1: The method of monitoring network conditions and adjusting transmissions is a core element of claim 1 of the '359 patent. The '619 publication's disclosure of a mobile device performing these actions is particularly relevant.
  • Claim 14: The "mobile station" described in the '619 application performs a similar function to the "wireless end-user device" in claim 14 of the '359 patent.
  • Claim 23: The described method would be implemented through software on the mobile device, thus potentially anticipating the non-transitory medium of claim 23.

---

4. U.S. Patent Application Publication No. 2008/0207198: "Application-aware traffic shaping"

• Full Citation: US 2008/0207198 A1. Inventors: Sutaria, Jay, et al.
• Publication/Filing Dates: Filed: February 27, 2007. Published: August 28, 2008.
• Brief Description: This patent application discloses a system for managing network traffic based on the specific application generating the traffic. It allows a network operator to define policies that can prioritize, block, or rate-limit traffic from different applications. This "application-aware" approach enables more granular control over network resources.
• Potential Anticipation of Claims: The '198 publication's focus on application-specific traffic management is a key element of the '359 patent's claims.
  • Claim 1: The concept of defining policies for different applications and managing their traffic accordingly directly mirrors the method described in claim 1 of the '359 patent.
  • Claim 14: The '198 publication describes a system that could be implemented on a wireless device to perform these functions, aligning with the device claimed in claim 14.
  • Claim 23: The application-aware traffic shaping would be implemented as software instructions, making it relevant prior art for claim 23.

---

5. U.S. Patent Application Publication No. 2009/0004996: "Method and apparatus for providing differentiated quality of service (QoS) for a plurality of applications in a wireless device"

• Full Citation: US 2009/0004996 A1. Inventors: Montemurro, Michael, et al.
• Publication/Filing Dates: Filed: June 27, 2007. Published: January 1, 2009.
• Brief Description: This publication details a method for a wireless device to manage Quality of Service (QoS) for multiple applications simultaneously. The device can prioritize traffic from different applications based on their QoS requirements, ensuring that high-priority applications receive preferential treatment for network resources.
• Potential Anticipation of Claims: The '996 application, published just before the '359 patent's priority date, is highly pertinent.
  • Claim 1: The method of providing differentiated QoS for a plurality of applications on a wireless device based on prioritization is a central concept in claim 1 of the '359 patent.
  • Claim 14: The "wireless device" in the '996 application that performs this QoS management is directly comparable to the device in claim 14 of the '359 patent.
  • Claim 23: The instructions for implementing this QoS management system would reside on a computer-readable medium as claimed in claim 23.

---

6. U.S. Patent Application Publication No. 2009/0196203: "System and Method for Providing Differentiated Network Services"

• Full Citation: US 2009/0196203 A1. Inventors: Boni, Angelo, et al.
• Publication/Filing Dates: Filed: January 31, 2008. Published: August 6, 2009.
• Brief Description: This document describes a system for providing different levels of network service based on user profiles, device capabilities, and network conditions. It allows for the dynamic allocation of network resources to ensure that service level agreements are met and that network performance is optimized.
• Potential Anticipation of Claims: The '203 publication discloses a system with many parallels to the '359 patent.
  • Claim 1: The method of providing differentiated network services based on network conditions and predefined policies aligns closely with the method outlined in claim 1 of the '359 patent.
  • Claim 14: The system described in the '203 publication could be embodied in a wireless device as claimed in claim 14.
  • Claim 23: The implementation of this system would require software on a computer-readable medium, making it relevant to claim 23.

---

7. U.S. Patent Application Publication No. 2009/0252069: "Dynamic Bandwidth Management for Multiple Applications in a Wireless Device"

• Full Citation: US 2009/0252069 A1. Inventors: Balasubramanian, Srinivasan, et al.
• Publication/Filing Dates: Filed: April 3, 2008. Published: October 8, 2009.
• Brief Description: This application presents a method for a wireless device to dynamically manage its available bandwidth among multiple running applications. The device monitors the bandwidth needs of each application and the overall network conditions to allocate bandwidth in a way that optimizes the user experience.
• Potential Anticipation of Claims: This publication's focus on dynamic, on-device management of network resources for multiple applications is very similar to the '359 patent's invention.
  • Claim 1: The method of dynamically managing bandwidth based on application needs and network conditions is a core component of the method claimed in claim 1.
  • Claim 14: The wireless device that performs this dynamic bandwidth management is functionally equivalent to the device described in claim 14.
  • Claim 23: The software that would execute this method on a device makes this publication relevant prior art for claim 23.

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

A patent claim is obvious if the differences between the claimed invention and the prior art are such that the claimed 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 considers whether a POSITA would have been motivated to combine the teachings of multiple prior art references to arrive at the claimed invention with a reasonable expectation of success.

The independent claims of US 9,179,359 (the '359 patent) are claims 1, 14, and 23. These claims broadly describe a method, a device, and a computer-readable medium for:

1. Determining a network busy state.
2. Accessing a service usage control policy that defines multiple, differentiated network access statuses.
3. Associating these access statuses with different network busy states.
4. Determining the appropriate network access status for a specific application or service based on the current network busy state.
5. Controlling the network access for that application or service according to the determined status.

An analysis of the prior art cited in the '359 patent reveals that these core concepts were well-known in the field. The claimed invention, therefore, would have been obvious to a POSITA by combining existing art.

---

Primary Prior Art Combination

A compelling case for obviousness can be made by combining the teachings of:

• US 2003/0187978 A1 ("Schmidt et al."): Teaches a system that adapts content and services based on both client device capabilities and prevailing network conditions. Schmidt explicitly discloses monitoring network characteristics like bandwidth and latency to modify service delivery.
• US 2008/0222304 A1 ("Mullan et al."): Teaches a system for policy-based network traffic management on a client device, where different applications can be assigned different Quality of Service (QoS) priorities.

Analysis of Claim 1 (Method Claim)

1. Determining a network busy state:

• Schmidt et al. discloses monitoring "prevailing network conditions" and "network connection characteristics" such as available bandwidth. This is synonymous with determining a "network busy state" as described in the '359 patent. A network with low available bandwidth is, by definition, in a busy or congested state.

2. Accessing a service usage control policy defining differentiated network access statuses:

• Mullan et al. discloses a "policy engine" on a client device that manages traffic according to defined policies. These policies can prioritize traffic for certain applications over others, creating differentiated service levels. These service levels (e.g., high priority, best effort) directly correspond to the "differentiated network access statuses" of the '359 patent. For instance, Mullan's "high priority" is a type of access status, and "best effort" is another.

3. Associating access statuses with network busy states & Determining/Controlling access:

• Motivation to Combine: A POSITA, familiar with Mullan's policy-based traffic prioritization and Schmidt's concept of adapting services to network conditions, would be motivated to combine these teachings to create a more dynamic and efficient system. Mullan teaches that you can prioritize applications, but does not specify when to apply these priorities most effectively. Schmidt teaches that you should adapt to network conditions. The logical and predictable next step would be to use the network conditions from Schmidt as the trigger for applying the traffic management policies from Mullan.
• Combination: It would have been obvious to a POSITA to modify Mullan's static policy engine to make it dynamic. Instead of having a fixed priority for a background application, a POSITA would implement a rule: "If the network busy state (as taught by Schmidt) is 'high', then apply the 'low priority' or 'delay' policy (as taught by Mullan) to background applications." This directly achieves the core of the '359 invention: controlling network access for a service based on a network access status that is itself determined by the network's busy state. The combination provides a clear path to delaying non-essential data when the network is congested to preserve performance for high-priority applications, which is the explicit goal of both traffic management and network-aware adaptation.

Therefore, claim 1 would have been obvious over the combination of Schmidt et al. and Mullan et al.

Analysis of Claim 14 (Apparatus Claim) and Claim 23 (Computer-Readable Medium Claim)

Claims 14 and 23 are directed to a wireless device and a non-transitory computer-readable medium, respectively, that implement the method of claim 1.

• Apparatus (Claim 14): The claim recites a "service processor" (software) stored in memory and executed by a processor. This is a standard description of how software-based methods are implemented on a computing device (e.g., a smartphone). Since the method of claim 1 is obvious over Schmidt in view of Mullan, implementing this method in software on a standard wireless device architecture (processor and memory) would also have been obvious. Both Schmidt and Mullan describe their systems operating on client devices that inherently possess processors and memory.
• Computer-Readable Medium (Claim 23): This claim covers the software instructions themselves. If the method performed by the software is obvious, then encoding those instructions onto a storage medium is also obvious. It is merely a choice of format for a known process.

Consequently, claims 14 and 23 are also rendered obvious by the same combination of prior art that makes claim 1 obvious. A POSITA would have found it a matter of routine software engineering to implement the combined teachings of Schmidt and Mullan on a standard wireless device.

[US9179359B2](/patent/US9179359B2) - Wireless end-user device with differentiated network access status for different device applications - Google Patents https://patents.google.com/patent/US9179359B2/en US9179359B2 - Wireless end-user device with differentiated network access status for different device applications - Google Patents. ... Legal status. (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.) Active. Application number: US14/673,625. Other versions: US20150207760A1 (en). ... First worldwide family litigation filed: litigation. Critical. [PTAB](/ptab) case IPR2026-00049 filed (Pending - Instituted): litigation. ... Priority date: 2009-01-28. Filing date: 2015-03-30. Publication date: 2015-11-03. ... 2029-03-02. Anticipated expiration. legal-status. Critical. ... 5 text/html Patent Center | USPTO https://patentcenter.uspto.gov/applications/14673625 Patent Term. Term Data. Earliest Expiration Date: 2030-03-02 ... Patent term adjustment data is not available for this application. ... This is a CON of 13/134,005 05/25/2011, which is a CIP of 12/695,980 01/28/2010, which is a CIP of 12/380,778 03/02/2009. 1 text/html US Patent for Wireless end-user device with differentiated network ... https://patents.justia.com/patent/[9179359](/patent/9179359) This is a continuation of U.S. patent application Ser. No. 13/134,005, entitled "SYSTEM AND METHOD FOR PROVIDING DEVICE ASSISTED SERVICES" filed on May 25, 2011, which is a continuation-in-part of U.S. patent application Ser. No. 12/695,980, entitled "SYSTEMS AND METHODS FOR DEVICE ASSISTED SERVICES" filed on Jan. 28, 2010, which is a continuation-in-part of U.S. patent application Ser. No. 12/380,778, entitled "DEVICE ASSISTED SERVICES" filed on Mar. 2, 2009, each of which is incorporated herein by reference for all purposes. This application is also related to U.S. patent application Ser. No. 12/694,451, entitled "SYSTEMS AND METHODS FOR DEVICE ASSISTED SERVICES" filed on Jan. 27, 2010, and U.S. patent application Ser. No. 12/694,445, entitled "SYSTEMS AND METHODS FOR DEVICE ASSISTED SERVICES" filed on Jan. 27, 2010, and U.S. patent application Ser. No. 12/694,455, entitled "SYSTEMS AND METHODS FOR DEVICE ASSISTED SERVICES" filed on Jan. 27, 2010, and U.S. patent application Ser. No. 12/695,021, entitled "SYSTEMS AND METHODS FOR DEVICE ASSISTED SERVICES" filed on Jan. 27, 2010, and U.S. patent application Ser. No. 12/695,019, entitled "SYSTEMS AND METHODS FOR DEVICE ASSISTED SERVICES" filed on Jan. 27, 2010, and U.S. patent application Ser. No. 12/695,020, entitled "SYSTEMS AND METHODS FOR DEVICE ASSISTED SERVICES" filed on Jan. 27, 2010, all of which are incorporated herein by reference for all purposes. 1 text/html Family of [US 9179359](/patent/US9179359) B2 https://www.bizapedia.com/patents/family-of-us-9179359-b2.html Patent Family of Patent #9,179,359. A patent family is a collection of patent applications filed in various countries to protect a single invention. ... US9179359B2. Wireless end-user device with differentiated network access status for different device applications. [United States](/litigations/by-defendant/United%20States) ... US20150207760A1. Wireless end-user device with differentiated network access status for different device applications. United States. US14673625. Wireless end-user device with differentiated network access status for different device applications ... [US8275830B2](/patent/US8275830B2). System and method for providing device assisted services. United States ... [US8321526B2](/patent/US8321526B2). Device assisted services. United States. [US8340634B2](/patent/US8340634B2) ... [US8346225B2](/patent/US8346225B2) ... [US8391834B2](/patent/US8391834B2) ... [US8402111B2](/patent/US8402111B2) ... [US8406748B2](/patent/US8406748B2) ... 1 text/html

Defensive Disclosure: US Patent 9,179,359

Publication Date: May 13, 2026
Subject Matter: Enhancements, derivatives, and alternative embodiments of systems and methods for differentiated network access control on a wireless end-user device, as described in US Patent 9,179,359. This document is intended to enter the public domain and serve as prior art.

---

Preamble

The disclosures herein relate to the field of wireless network traffic management, specifically to device-assisted services for controlling application access to network resources based on network state. The following descriptions of systems, methods, and apparatuses are provided to disclose novel and non-obvious extensions and alternatives to the core teachings of US Patent 9,179,359 ('359 patent). These disclosures are intended to be enabling for a person having ordinary skill in the art (PHOSITA).

Claim Scope Analysis

The core invention of the '359 patent covers a method (claim 1), a device (claim 14), and a computer-readable medium (claim 23) for:

1. Determining a network busy state.
2. Associating a network access status (e.g., allow, block, throttle) with a device application based on the busy state and a predefined policy.
3. Controlling the application's network access according to the associated status.

The following disclosures expand upon each of these core concepts.

---

Derivative Embodiments

Axis 1: Material & Component Substitution

1.1. Policy Enforcement via Hardware Co-Processor/FPGA

• Enabling Description: The "service processor" functionality described in claims 14 and 23 is implemented not in software running on the main CPU, but within a dedicated, low-power hardware co-processor, such as a Field-Programmable Gate Array (FPGA) or an Application-Specific Integrated Circuit (ASIC). This hardware component directly interfaces with the device's network interface controller (NIC). The policy, defining the mapping between network busy states and application access statuses, is compiled into a hardware description language (e.g., Verilog or VHDL) and synthesized into the FPGA's logic gates or etched into the ASIC. The hardware processor monitors packet headers (e.g., 5-tuple of source/destination IP, port, and protocol) at line speed, matching them against application signatures. It concurrently receives a network busy state signal (e.g., a simple integer value from 0-255) from the baseband processor. Based on this value, it consults its hard-wired Finite State Machine (FSM) to either pass, drop, or shape the traffic for that packet's associated application, offloading this task entirely from the main CPU. This reduces latency from milliseconds (in a software implementation) to nanoseconds and significantly lowers power consumption.
• Mermaid Diagram:

  graph TD
      A[Baseband Processor] -- Network Busy State (NBS) --> C{Policy Engine FPGA};
      B[Application CPU] -- IP Packets --> D[Network Interface Controller];
      D -- Raw Packet Stream --> C;
      C -- Classified & Controlled Traffic --> E[RF Transceiver];
      subgraph On-Chip
          C;
          D;
      end
  

1.2. Policy Execution in a Trusted Execution Environment (TEE)

• Enabling Description: To ensure policy integrity and prevent tampering by the end-user or malicious applications, the entire service processor agent is instantiated within a hardware-isolated Trusted Execution Environment (TEE), such as ARM TrustZone or Intel SGX. The policy rules are encrypted and signed by the network operator. Upon boot, a "Secure World" OS loads the service processor and its encrypted policy. The "Normal World" OS, where user applications run, can only communicate with the service processor via a secure monitor call (SMC). When an application attempts to open a network socket, the call is trapped and forwarded to the TEE. The service processor inside the TEE inspects the request, checks the network busy state (which is also securely passed from the baseband modem), and enforces the policy. The key and policy store are inaccessible from the Normal World, making the system robust against reverse-engineering or modification.
• Mermaid Diagram:

  sequenceDiagram
      participant App in Normal World
      participant Kernel in Normal World
      participant TEE Monitor
      participant ServiceProcessor in Secure World
      participant Modem
      App->>Kernel: socket.connect()
      Kernel->>TEE Monitor: SMC: Request_Network_Access(AppID)
      TEE Monitor->>ServiceProcessor: Forward Request(AppID)
      Modem-->>ServiceProcessor: Secure_Channel: Report_Busy_State(value)
      ServiceProcessor->>ServiceProcessor: Evaluate_Policy(AppID, Busy_State)
      ServiceProcessor-->>TEE Monitor: Return_Decision(ALLOW/DENY)
      TEE Monitor-->>Kernel: Resume with Status
      Kernel-->>App: Connection Allowed/Refused
  

---

Axis 2: Operational Parameter Expansion

2.1. High-Frequency Trading (HFT) Latency Jitter Management

• Enabling Description: The system is applied to an HFT device operating on a private 5G/6G network where "network busy state" is defined not by bandwidth saturation but by latency jitter in the air interface, measured in microseconds. The service processor continuously monitors the round-trip time (RTT) and jitter of a dedicated control channel to the mobile edge compute (MEC) server. The policy defines multiple jitter thresholds (e.g., <10µs, 10-50µs, >50µs). If jitter exceeds 10µs, a "Degraded" access status is triggered, causing the service processor to immediately suspend all non-essential network traffic, including OS telemetry, analytics reporting, and secondary market data feeds. This frees up MAC layer scheduling resources to prioritize the single, critical trading application's traffic, ensuring its latency remains within the sub-millisecond execution window. The policy is dynamically updated based on the VIX (Volatility Index), tightening jitter thresholds during high market volatility.
• Mermaid Diagram:

  stateDiagram-v2
      state "Low Jitter (<10µs)" as Low
      state "Medium Jitter (10-50µs)" as Medium
      state "High Jitter (>50µs)" as High
  
      [*] --> Low: Initialize
      Low --> Medium: Jitter increases
      Medium --> High: Jitter increases
      Medium --> Low: Jitter decreases
      High --> Medium: Jitter decreases
  
      state Low {
          description All Apps: Full Access
      }
      state Medium {
          description Trading App: Full Access
          description Market Data Feeds: Throttled
          description OS Telemetry: Blocked
      }
      state High {
          description Trading App: Priority Access
          description All Other Apps: Blocked
      }
  

2.2. UUV Acoustic Mesh Network Coordination

• Enabling Description: The invention is applied to a swarm of Unmanned Underwater Vehicles (UUVs) communicating via a shared, low-bandwidth (e.g., 9600 bps) acoustic modem network. In this context, the "wireless end-user device" is each UUV. The "network busy state" is a composite score derived from the acoustic channel's Bit Error Rate (BER), ambient noise level, and the number of active transmitting nodes (packet collision probability). The service processor on each UUV prioritizes traffic as follows: P0 (Emergency/Collision Avoidance), P1 (Command & Control/Telemetry), P2 (Collaborative Sonar Data Exchange), P3 (Bulk Science Data Upload). If the busy state score crosses a threshold, the service processor automatically downgrades the access status for lower-priority applications. For example, it will buffer P3 data locally and cease transmission, while throttling the transmission rate of P2 packets to reduce channel occupancy, ensuring P0 and P1 messages have a clear channel.
• Mermaid Diagram:

  flowchart TD
      subgraph UUV_Node
          A[Acoustic Channel Monitor] --> B{Network Busy State?};
          B -- High BER/Collision --> C[Policy: HIGH_CONGESTION];
          B -- Low BER/Collision --> D[Policy: NORMAL];
          C --> E{Control App Traffic};
          D --> E;
          E --> F[P0: Emergency - Unrestricted];
          E --> G[P1: C&C - Unrestricted];
          E --> H[P2: Sonar - Throttled];
          E --> I[P3: Science Data - Buffered/Blocked];
      end
  

---

Axis 3: Cross-Domain Application

3.1. Aerospace: LEO Satellite Bandwidth Allocation

• Enabling Description: Each satellite in a Low Earth Orbit (LEO) constellation acts as a "wireless end-user device" managing multiple data streams over shared inter-satellite laser links and ground station downlinks. The "service processor" is the satellite's onboard router. The "network busy state" is determined by the current buffer occupancy of the laser link transceivers and the scheduled ground station contact window. A "policy" prioritizes data types: 1) Satellite Health & Telemetry, 2) High-Value Customer Data (e.g., military communication), 3) Consumer Broadband Backhaul, 4) Earth Observation Imagery. When a high-priority tactical data burst is routed through the satellite (e.g., from another satellite), the service processor assigns a "deprioritized" status to consumer backhaul and a "hold" status to imagery data, clearing the laser link buffers for the critical traffic. Once the high-priority traffic has passed, the processor restores normal access status to the other services.
• Mermaid Diagram:

  graph TD
      subgraph LEO_Satellite
          Telemetry[Health & Telemetry] --> Router;
          Tactical[Tactical Comms] --> Router;
          Broadband[Consumer Broadband] --> Router;
          Imaging[Earth Observation] --> Router;
  
          Router{Service Processor} -- Policy Logic --> Laser_Link[Inter-Satellite Laser Link];
          Router -- Policy Logic --> Downlink[Ground Station Downlink];
          
          StateMonitor[Link Buffer Monitor] -->|Busy State| Router;
  
          style Telemetry fill:#c9ffc9
          style Tactical fill:#ffb3b3
          style Broadband fill:#d1d1ff
          style Imaging fill:#ffffcc
      end
  

3.2. AgTech: Smart Irrigation Network Prioritization

• Enabling Description: A farm's wireless mesh network, comprising thousands of soil moisture sensors, weather stations, and automated irrigation valve controllers, is managed by a central gateway ("wireless end-user device"). The "network busy state" is determined by the collision rate in the LoRaWAN/802.11s mesh. The service processor in the gateway runs a policy engine where applications are defined by data type. During normal operation, all data types (sensor readings, valve status reports) are given equal access. However, if the weather station detects a critical event (e.g., sudden frost warning, high wind speed), it sends a P0 priority message. The gateway's service processor immediately assigns a "Restricted" access status to all routine soil moisture reporting "applications" and a "Blocked" status to firmware update downloads. This ensures the command-and-control traffic to activate anti-frost sprinklers or close valves is propagated through the network with minimum delay and maximum reliability.
• Mermaid Diagram:

  sequenceDiagram
      participant WeatherStation
      participant Gateway
      participant SoilSensor
      participant IrrigationValve
  
      WeatherStation->>Gateway: High-Priority Alert (Frost Warning)
      Gateway->>Gateway: Determine Network Busy State: CRITICAL_EVENT
      Gateway->>Gateway: Apply Frost Policy
      Gateway-->>SoilSensor: Set Access Status: RESTRICTED
      Gateway-->>IrrigationValve: Set Access Status: PRIORITY_COMMAND
      Gateway->>IrrigationValve: Send Command: ACTIVATE_SPRINKLERS
      SoilSensor--xGateway: Data Upload Throttled/Delayed
  

---

Axis 4: Integration with Emerging Tech

4.1. AI-Driven Predictive Network Access Management

• Enabling Description: The service processor on the device incorporates a lightweight, on-device Recurrent Neural Network (RNN) model. This model is trained to predict future network congestion and application demand based on a time-series analysis of historical data, including: time of day, device location (via GPS), cell tower ID, currently running foreground application, and historical bandwidth usage patterns. For example, the model learns that at 5:00 PM when the user's device connects to their home Wi-Fi, they typically launch a video streaming app, causing a spike in demand. At 4:59 PM, the AI-powered service processor proactively assigns a "pre-emptive throttle" status to background applications (e.g., cloud photo uploads, app store updates) before the user launches the video app, thereby reserving network capacity and ensuring a smooth streaming experience from the first second. The model is periodically retrained and updated by a central server.
• Mermaid Diagram:

  flowchart LR
      subgraph Device
          A[Sensor Data (Time, Location, Cell ID)] --> B[RNN Model];
          C[App Usage History] --> B;
          D[Network State History] --> B;
          B -- Prediction: High Congestion @ T+1min --> E{Policy Engine};
          E -- Proactive Policy --> F[Traffic Controller];
          G[App Traffic] --> F;
          F -- Controlled Traffic --> H[Radio];
      end
      subgraph Cloud
          I[Central Model Training Server] -.-> B;
      end
  

4.2. Blockchain-Based Service Level Agreement (SLA) Enforcement

• Enabling Description: The system uses a private blockchain to create an immutable and verifiable log of all network management actions. The user's Service Level Agreement (SLA) is encoded as a smart contract on the blockchain. The service processor on the device and the network's Policy and Charging Rules Function (PCRF) are both nodes on this blockchain. When the service processor throttles an application due to network congestion (a state verified and published by the PCRF), it writes a transaction to the blockchain containing a cryptographic hash of the action details (App ID, timestamp, throttling factor, network state proof). The smart contract automatically validates this action against the SLA rules. This provides a transparent, auditable trail for billing and disputes. A user could, for example, have a "premium data" allowance which, when used, prevents throttling; the smart contract would automatically reject any throttling transaction from the service processor while the user's premium data balance is positive.
• Mermaid Diagram:

  graph TD
      subgraph Device
          SP[Service Processor]
          SP -- 1. Detects Congestion --> SP
          SP -- 2. Throttles App_X --> SP
          SP -- 3. Creates 'Throttle' Transaction --> BC_Node_Device[Blockchain Node]
      end
      subgraph Network
          PCRF[Policy/Charging Rules Function]
          PCRF -- Publishes Network State --> BC_Node_Network[Blockchain Node]
      end
      subgraph Blockchain
          BC_Node_Device --> SmartContract{SLA Smart Contract}
          BC_Node_Network --> SmartContract
          SmartContract -- Validates Transaction against SLA rules --> Ledger[Append to Ledger]
      end
      User[User Portal] -->|Reads| Ledger
  

---

Axis 5: The "Inverse" or Failure Mode

5.1. Graceful Degradation with Interactive User Override

• Enabling Description: Instead of silently throttling or blocking applications, this embodiment focuses on user-centric graceful degradation. When the service processor determines the network is busy and a policy dictates throttling a user-interactive application (e.g., a social media feed), it does not immediately block the data. Instead, it instructs the application (via a local API) to request lower-quality content (e.g., lower-resolution images, shorter video clips). Simultaneously, it triggers a non-intrusive UI notification (e.g., a small banner) stating, "Network is busy. Showing lite content. [Tap for full quality]". If the user taps the override, the service processor assigns that specific application a temporary "priority" access status for a limited duration (e.g., 5 minutes), allowing full-quality access while potentially throttling other background tasks more aggressively to compensate. This user feedback is logged and can be used to personalize the policy over time.
• Mermaid Diagram:

  stateDiagram-v2
      [*] --> Normal_Access
      Normal_Access: App requests full quality content
      Normal_Access --> Degraded_Mode: Network becomes busy
      Degraded_Mode: Processor signals App to request lite content
      Degraded_Mode: Display 'Tap for full quality' UI
      Degraded_Mode --> Priority_Override: User taps UI
      Degraded_Mode --> Normal_Access: Network congestion eases
      Priority_Override: App gets full quality for 5 mins
      Priority_Override --> Degraded_Mode: Timer expires
      Priority_Override --> Normal_Access: Network congestion eases
  

---

Combination with Open-Source Standards

1. Differentiated Control via D-Bus and systemd: On a Linux-based device (e.g., Android, automotive Linux), the service processor is implemented as a privileged system daemon. It uses D-Bus, an open-source Inter-Process Communication (IPC) system, to receive network access requests from applications. Applications are categorized by their systemd user slice (e.g., app-background.slice, app-interactive.slice). The service processor applies broad policies based on these slices. For example, when network congestion is high, it instructs the kernel's firewall (nftables) to severely rate-limit all traffic originating from the app-background.slice cgroup, providing an OS-integrated mechanism for enforcing the access status.

2. Policy Enforcement using eBPF: The control logic is implemented as an extended Berkeley Packet Filter (eBPF) program loaded into the kernel. The user-space service processor agent monitors the network state and application status. When a policy change is needed, it updates a set of "maps" (key-value stores) in the kernel. The eBPF program, attached to the network interface's traffic control (TC) ingress/egress hooks, reads these maps for every packet. It can then make instantaneous decisions to drop, re-route, or re-classify packet QoS bits based on the application's current access status stored in the map, all without context switching from the kernel, offering extremely high performance.

3. Network State Determination via Prometheus Metrics: In an enterprise or private 5G setting, the network infrastructure (gNodeB, UPF) is configured to export its performance metrics (e.g., Physical Resource Block (PRB) utilization, RTT, packet drop rate) in the Prometheus open-source monitoring format. The service processor on the device periodically scrapes this metrics endpoint (or receives metrics pushed from a Prometheus Alertmanager instance) to determine the "network busy state". This replaces proprietary or heuristic-based detection with a standardized, data-rich source of truth about the real-time condition of the network infrastructure.