Obviousness

Obviousness Analysis of US Patent 9560177 Under 35 U.S.C. § 103

This analysis identifies combinations of prior art references that would render the claims of US patent 9560177 obvious to a person having ordinary skill in the art (PHOSITA) at the time of the invention (priority date of February 17, 2011). The primary references considered are Non-Patent Literature 1 ("OpenFlow Switch Specification, Version 1.0.0") and Patent Literature 1 (JP 2005-210518A), both cited in US9560177B2.

Background and Problem Addressed by US9560177B2

US9560177B2 addresses the challenge of tracing network flows in complex environments, particularly when packets pass through network appliances like Network Address Translation (NAT) and Network Address Port Translation (NAPT) units. These "header translating units" modify packet headers, making it difficult to monitor and control end-to-end flows. The patent notes that existing solutions, such as referring to address translation tables or using IP trace-back (as in JP 2005-210518A), typically require modifications to the header translating units themselves, which is often impractical or difficult to realize.

The stated object of US9560177B2 is "to provide a network system and a network flow tracing method in which a packet is encapsulated by using the same header as a current header in a switch, and has two kinds of headers before translation and after the translation after passing through a network appliance" without remodeling the network appliance.

Obviousness Argument

A PHOSITA in 2011 would have been well-versed in network systems, including the emerging concepts of Software-Defined Networking (SDN) and OpenFlow, as well as traditional networking challenges like NAT traversal and flow tracing.

Combination of Non-Patent Literature 1 and General Knowledge of Encapsulation for Solving a Known Problem:

• Non-Patent Literature 1 (NPL1): "OpenFlow Switch Specification, Version 1.0.0" (December 31, 2009)
  NPL1 describes the core components and operations of an OpenFlow network system. This includes a controller that sets rules and actions in flow tables of switches, and switches that process packets based on these rules and actions. NPL1 teaches that OpenFlow switches can perform various actions, including "rewriting a header". This document establishes the foundational programmable network infrastructure.

• General Knowledge of Network Address Translation (NAT/NAPT) and Encapsulation:
  The background of US9560177B2 itself acknowledges that "equipments having a function of NAT (Network Address Translation) and NAPT (Network Address Port Translation) translate a packet header." It also states that "a method of using header translation data retained by the header translating unit is known." The concept of encapsulation (also known as tunneling), where one packet is wrapped inside another packet, was a well-established networking technique for various purposes like creating Virtual Private Networks (VPNs) or enabling communication between incompatible networks. The patent even mentions Generic Routing Encapsulation (GRE) as a method for encapsulation.

• Motivation to Combine:
  A PHOSITA would have been motivated to combine the programmable capabilities of an OpenFlow network (NPL1) with the known techniques of encapsulation to address the recognized problem of tracing flows through header translating units (NAT/NAPT) without requiring modifications to those units. The challenge presented by NAT/NAPT altering headers and breaking end-to-end flow visibility was a known concern in network management.

  Given that NAT/NAPT devices primarily modify the outermost header of a packet, a PHOSITA seeking to preserve the original header information for tracing purposes would find it obvious to encapsulate the original packet within another packet. To effectively link the pre-translation and post-translation flows, the original header (or a critical part of it) would need to be preserved. Duplicating the original header and using it as an inner header within an encapsulated packet would be a logical and straightforward way to achieve this preservation.

  The programmable nature of OpenFlow switches (NPL1), which allows for flexible packet processing and header manipulation (e.g., "rewriting a header"), provides the means to implement such encapsulation and decapsulation operations. The controller (NPL1) could instruct an upstream OpenFlow switch to perform this encapsulation for specific flows identified as needing tracing, and a downstream OpenFlow switch to decapsulate and extract the translation information.

Addressing Independent Claims:

All independent claims (Claim 1, Claim 7, Claim 13, and Claim 19) share the core inventive concept of a switch or method performing the steps of identifying a packet, duplicating part of its header, and encapsulating the packet with the duplicated header.

• "a storage storing a table, the table including rules and actions corresponding to the rules": This is directly taught by OpenFlow specification (NPL1), which describes flow tables, rules, and actions.
• "a controller comprising: a memory storing instructions; and a processor configured to execute the instructions to: receive the rules and the actions from a control apparatus": These are standard components and functionalities of an OpenFlow switch under the control of an OpenFlow controller (NPL1).
• "identify, based on the rules, a received packet": An intrinsic function of an OpenFlow switch (NPL1).
• "duplicate a part of a header of the identified packet as an additional header when the identified packet comprises a target of encapsulation" and "encapsulate the identified packet by the additional header": While NPL1 does not explicitly detail duplicating headers for tracing, a PHOSITA motivated to overcome the NAT/NAPT tracing problem would find this obvious. Knowing that NAT/NAPT modifies the outer header, and that encapsulation is a known way to "hide" or preserve inner packet content, it would be an obvious design choice to duplicate the original header to serve as the inner, untranslated header for an encapsulated packet. This ensures that the original flow information is retained through the NAT/NAPT for later comparison. The OpenFlow switch's ability to "rewrite a header" (NPL1) demonstrates the capability to modify headers for such an encapsulation task.
• "process, based on the actions, the identified packet": A fundamental operation of an OpenFlow switch (NPL1).

Regarding the "sending header information to the control apparatus when the identified packet comprises an encapsulated packet" (Claims 2, 8, 14, 20) and "decapsulate the encapsulated packet" (Claims 4, 10, 16), these would be obvious extensions once the encapsulation mechanism is in place. After a packet passes through the header translating unit, a downstream switch would naturally need to decapsulate it to extract the original header and then transmit this information (along with the newly translated outer header) to the controller for flow tracing.

Conclusion

The core inventive step of US9560177B2—duplicating a packet header for encapsulation within a switch to enable flow tracing across header translating units without modifying those units—would have been obvious to a PHOSITA by combining the known programmable network architecture of OpenFlow (NPL1) with general knowledge of encapsulation and the recognized problem of NAT/NAPT complicating flow tracing. The motivation for such a combination arises from the clear need to achieve end-to-end flow visibility in dynamic networks, a problem that existing solutions like those in JP 2005-210518A failed to solve without requiring modifications to third-party network appliances.