Obviousness

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.