Obviousness

Obviousness Analysis of U.S. Patent 9,313,101 under 35 U.S.C. § 103

This analysis evaluates whether the independent claims of U.S. Patent 9,313,101 would have been obvious to a Person Having Ordinary Skill in the Art (PHOSITA) at the time of the invention, based on the prior art references detailed in the preceding section. An invention is considered obvious if the differences between the claimed invention and the prior art are such that the subject matter as a whole would have been obvious to a PHOSITA.

The central concept of the '101 patent is a network policy system where traffic rules are based on a combination of packet data (tuple information) and a time-based condition. The patent's claims are distinguished by the specific architectural component responsible for determining when the time condition is met: the Policy Server (PS) in claim 1, the Policy Management System (PMS) in claim 3, or the Policy Execution Equipment (PEE) in claim 6.

---

Analysis of Independent Claim 1

Claim 1: A method where a Policy Server (PS) determines if a policy's execution time has arrived and, if so, transmits the policy to a Policy Management System (PMS).

Obviousness Combination: U.S. Patent 6,859,841 B2 ('841) in view of engineering principles and knowledge common to a PHOSITA.

Reasoning:

1. Base Teachings of '841: U.S. Patent 6,859,841 B2 discloses a comprehensive policy management system. Crucially, it teaches a policy server that manages rules which can be defined with a "rule lifetime including start date and time and end date and time." This directly teaches the creation of time-based policies that combine network rules with a time condition, as required by claim 1. The '841 patent's server provides these rules to distributed "policy targets" for enforcement.

2. The Missing Element: Claim 1 requires a specific implementation detail: the PS must determine that the start time has arrived before transmitting the policy. The '841 patent describes a server managing time-based rules but does not explicitly forbid sending the policy to the target before its start time (i.e., sending the policy along with its "lifetime" metadata for the target to handle).

3. Motivation to Modify '841: A PHOSITA, when designing a system based on '841, would have been presented with a finite and predictable set of implementation choices for handling the "rule lifetime."

   • Option A: Send the policy and its lifetime metadata to the policy target and let the target manage the activation time.
   • Option B: Have the central policy server manage the activation time and only push the policy to the target when it is time for it to be active.

   Choosing Option B, which is the method of claim 1, would have been an obvious design choice for several compelling reasons:

   • Centralized Control: Managing policy activation at the server simplifies the logic required at the potentially numerous and less-powerful policy targets (the PEEs).
   • Resource Management: It prevents the network and the policy targets from being burdened with policies that are not yet active. The server only sends what is necessary at the time it is needed.
   • Simplified Auditing: A central server that logs exactly when it pushes each policy provides a simpler and more reliable audit trail for policy activation.

Therefore, modifying the system of '841 to have the server determine the execution time and transmit the policy only upon that time arriving is not an inventive step, but rather a predictable design choice to enhance centralization and efficiency. This would have been obvious to a PHOSITA.

---

Analysis of Independent Claims 3 and 6

Claim 3: A method where a Policy Management System (PMS) downloads a policy, determines if its execution time has arrived, and then transmits it to the Policy Execution Equipment (PEE).

Claim 6: A method where the Policy Execution Equipment (PEE) downloads a policy and determines for itself whether the execution time has arrived before enforcing it.

Obviousness Combination: U.S. Patent Application 2008/0316922 A1 ('922) alone or in view of the known functions of network management systems. The same argument can be made using KR 2003-0003593 A or US 2008/0225708 A1 as the primary reference.

Reasoning:

1. Base Teachings of '922: US 2008/0316922 A1 explicitly discloses the core of claims 3 and 6. It teaches a system where a policy rule has a "trigger," which can be a "time-of-day or a day-of-week." The application unequivocally states, "The policy client evaluates the trigger condition" before enforcing the rule.

2. Obviousness of Claim 6: The "policy client" of the '922 application is functionally identical to the "policy execution equipment" (PEE) of claim 6. Both are network devices that download a policy containing a time-based condition and are responsible for checking the current time to determine if the policy should be active. The method described in claim 6 is therefore directly taught by and would have been obvious in light of the '922 application.

3. Obviousness of Claim 3: Claim 3 introduces the intermediate Policy Management System (PMS) as the component that performs the time check. The three-tier PS-PMS-PEE architecture is a well-understood model for scalable network management. A PMS serves as a middle-management layer, aggregating policies from a central server and distributing them, often in a parsed or vendor-specific format, to numerous enforcement points.

   A PHOSITA, tasked with implementing the system of '922 in a large-scale network, would have found it obvious to instantiate the "policy client" function on a PMS. The motivation for this is clear:

   • Scalability: Having a PMS perform the time check for a whole group of PEEs is more efficient than requiring every single PEE to perform this check independently.
   • Abstraction: The PMS can abstract the policy logic from the PEEs. The PMS determines when a policy is active and then pushes a simple "execute now" command to the PEE, which might not need to be time-aware itself, thereby simplifying PEE hardware and software requirements.

   Therefore, applying the client-side time-check taught by '922 to the well-known PMS layer of a standard three-tier policy architecture would have been an obvious combination for a PHOSITA seeking to build a scalable and efficient policy enforcement system.