Obviousness

The obviousness analysis under 35 U.S.C. § 103 for US patent 7386630 requires identifying prior art combinations that would have made the claimed invention obvious to a person having ordinary skill in the art at the time of the invention (i.e., before the April 30, 2003 priority date). The patent's core innovation lies in using a policy server to centrally manage and configure Diffserv over MPLS networks, including customer policies, network policies, and mapping policies, and deploying these as device-specific commands to network interfaces.

Here, we consider several combinations of prior art references.

Combinations for Obviousness:

1. Combination of Policy-Based Management with Diffserv and MPLS Concepts:

• Prior Art References:

  • Westerinen, A. et al., "Terminology for Policy-Based Management," RFC 3198 (2001): This document provides a glossary of policy-related terms and explains that policy-based management systems use a policy server to define, store, and configure policies on multiple network elements. It highlights that a centralized server ensures consistent configurations across these elements and simplifies policy provisioning.
  • Faucheur, F.L. et al., "MPLS Support of Differentiated Services," RFC 3270 (2002): This RFC specifically addresses how MPLS can support Differentiated Services, including the use of E-LSP and L-LSP. It discusses mapping Diffserv information to MPLS headers (labels and EXP fields) and tunneling modes (pipe mode and uniform mode) for translating Diffserv information when packets exit the MPLS network.
  • Trimintzios, P. et al., "A Management and Control Architecture for Providing IP Differentiated Services in MPLS-based Network," IEEE Communication Magazine (2001): This article describes a management and control architecture for providing IP differentiated services in MPLS-based networks.
  • Bruce S. Davie, Yakov Rekhter, "MPLS: Technology and Applications," Morgan Kaufmann Publishers (2000): This book provides a comprehensive overview of MPLS, including its applications for traffic engineering and VPN services, and its functionality related to QoS.

• Motivation for Combination and Obviousness:
  A person of ordinary skill in the art (POSITA) would have been motivated to combine the general principles of policy-based management with the known technical details of integrating Diffserv and MPLS.

  • Problem: Prior to US7386630, supporting Diffserv and MPLS concurrently involved "cumbersome mappings" and required administrators to configure edge devices one by one using "device-specific commands" [cite: Google Patents]. The existing solutions lacked a centralized, scalable management approach for Diffserv over MPLS.
  • Motivation: Westerinen (RFC 3198) clearly articulates the benefits of policy-based management, such as simplifying management, ensuring policy consistency across multiple network elements, and automating configurations. Given the known complexities of manually configuring Diffserv over MPLS, a POSITA would recognize the immediate advantage of applying a policy-based management system to this problem.
  • How the combination renders claims obvious:
    • Faucheur (RFC 3270) and Trimintzios et al. describe the technical aspects of integrating Diffserv and MPLS, including the use of EXP-to-PHB mapping and tunneling modes.
    • Davie and Rekhter's book details MPLS traffic engineering and its role in utilizing network resources and supporting various services.
    • A POSITA, familiar with the concepts from Westerinen (policy server, device-neutral policies, device-specific commands, deployment to policy targets) and the technical requirements of Diffserv over MPLS (EXP-to-PHB mapping, tunneling modes, LSP configuration) from Faucheur and Davie/Rekhter, would find it obvious to implement the management of Diffserv/MPLS configurations using a centralized policy server. The "translation" of high-level policies into device-specific commands, and their "deployment" to network interfaces, as described in the patent, are direct applications of the policy-based management paradigm to the specific problem of Diffserv over MPLS.
    • Specifically, Independent Claim 1, 4, 10, 12, and 18, which claim a policy server/apparatus/method for configuring customer policies (with tunnel group identifier and tunneling mode), mapping policies (EXP to PHB), translating these into device-specific commands, and deploying them to interfaces of devices within an MPLS network, would be obvious. The "tunnel group identifier" and "tunneling mode" in the customer policy are directly derived from the Diffserv over MPLS interoperability elements known in the prior art. The "role name" association with interfaces, as described in Westerinen and implied in policy management for scalability, would also be a logical inclusion for managing configurations across numerous devices.

2. Combination of Diffserv/MPLS Traffic Engineering with Policy-Based QoS Management:

• Prior Art References:

  • Akyildiz, I.F. et al., "A New Traffic Engineering Manager for Diffserv/MPLS Networks: Design and Implementation on an IP QoS Testbed," Computer Communications (2003): This paper describes a traffic engineering manager specifically for Diffserv/MPLS networks, focusing on QoS. It acknowledges the complexity of managing Diffserv/MPLS networks.
  • Flegkas, P. et al., "A Policy-Based Quality of Service Management System for IP Diffserv Networks," IEEE Network Magazine (2002): This reference discusses a policy-based QoS management system specifically for IP Diffserv networks. It emphasizes guiding network behavior through high-level declarative directives that are dynamically introduced, checked for consistency, refined, and evaluated, resulting in low-level actions.
  • Jacobson, V. et al., "An Expedited Forwarding PHB," RFC 2598 (1999): This RFC defines the Expedited Forwarding Per-Hop Behavior (EF PHB), a crucial component of Diffserv for providing low-loss, low-latency, low-jitter, and assured bandwidth services.

• Motivation for Combination and Obviousness:
  A POSITA concerned with efficient QoS management in converging Diffserv and MPLS networks would be motivated to combine a specialized traffic engineering manager with policy-based QoS management.

  • Problem: While Akyildiz et al. presented a traffic engineering manager for Diffserv/MPLS, it likely still involved significant manual configuration or lacked the full automation and centralized control offered by a robust policy-based system.
  • Motivation: Flegkas et al. demonstrate the advantages of policy-based management for Diffserv networks, emphasizing its ability to handle complexity and adapt to new service requirements through high-level policies. Given that Diffserv (as detailed in Jacobson's RFC 2598) and MPLS (for traffic engineering, as mentioned in Akyildiz et al.) are both critical for QoS, a POSITA would naturally seek to apply the benefits of policy-based management (from Flegkas et al.) to the combined Diffserv/MPLS environment (from Akyildiz et al.).
  • How the combination renders claims obvious: This combination directly leads to the concept of centrally managing Diffserv over MPLS configurations through policies. The "mapping policy" between an EXP field and a PHB (as in Jacobson et al.) would be a fundamental high-level directive in such a system. The "customer policy" and "network policy" would serve to define and govern the Diffserv treatment and traffic rules, consistent with the policy-based QoS management framework. The translation into device-specific commands and deployment to network interfaces are inherent features of policy-based management.

3. Combination addressing specific MPLS and Diffserv Interoperability Challenges with Policy Management:

• Prior Art References:

  • Faucheur, F.L. et al., "MPLS Support of Differentiated Services," RFC 3270 (2002): This RFC details the interoperability of Diffserv and MPLS, specifically mentioning EXP-to-PHB mapping and tunneling modes (pipe mode, uniform mode) as "essential elements." It also highlights the need to rely on signaling for label and EXP mapping.
  • Westerinen, A. et al., "Terminology for Policy-Based Management," RFC 3198 (2001): As before, this reference provides the foundational understanding of policy-based management systems.
  • Katz, D. et al., "Traffic Engineering Extensions to OSPF," Internet Draft (2001/2002 versions available prior to priority date): These drafts discuss extensions to OSPF for traffic engineering, including advertising multiple metrics for path selection, which are crucial for configuring LSPs.
  • Li, T. et al., "IS-IS Extensions for Traffic Engineering," Internet Draft (2001/2000 versions available prior to priority date): Similar to the OSPF extensions, these drafts provide mechanisms for IS-IS to support traffic engineering, including the definition of multiple routing metrics for LSPs.

• Motivation for Combination and Obviousness:
  A POSITA would be motivated to use policy-based management to simplify the known complexities of Diffserv and MPLS interoperability, particularly with signaling for LSP setup and traffic engineering.

  • Problem: RFC 3270 points out the difficulty in supporting Diffserv and MPLS concurrently due to "cumbersome mappings" and the need for device-specific configurations, including relying on signaling for label and EXP mapping.
  • Motivation: Westerinen provides the solution of a centralized policy server to automate and simplify configurations across multiple network elements. The drafts by Katz et al. and Li et al. detail the routing protocol extensions necessary for MPLS traffic engineering and LSP setup based on various constraints.
  • How the combination renders claims obvious: It would be obvious to a POSITA to use a policy server (Westerinen) to define and deploy the "EXP-to-PHB mapping" and "tunneling mode" (Faucheur) which are explicitly identified as essential for Diffserv/MPLS interoperability. Furthermore, the policy server could logically manage the creation and properties of "MPLS tunnels" (which are LSPs), using the traffic engineering capabilities provided by extensions to routing protocols like OSPF and IS-IS (Katz et al., Li et al.). The concept of a "tunnel group identifier" and "tunneling mode" within a customer policy, as described in US7386630, directly addresses the elements of Diffserv/MPLS interoperability and would be a logical component of a policy-based management system.

In conclusion, the combination of prior art references clearly demonstrates that the core inventive concept of US patent 7386630 – using a policy server for managing and configuring Diffserv over MPLS networks – would have been obvious to a person having ordinary skill in the art. The motivation to combine these elements stems from the recognized difficulties in manually configuring and managing complex Diffserv/MPLS interactions and the known benefits of policy-based management for achieving scalability, consistency, and automation in network administration.