Obviousness

On April 26, 2026, an analysis of US Patent 9,900,249 (hereinafter, '249 patent) for obviousness under 35 U.S.C. § 103 reveals that its claims would likely have been obvious to a person having ordinary skill in the art (PHOSITA) by combining known prior art references. The '249 patent itself details various existing technologies and their shortcomings, providing clear motivations for the claimed invention.

Summary of the '249 Patent's Invention:

The '249 patent aims to provide a communication system, forwarding node, path management server, communication method, and computer program that utilizes a simplified forwarding table and can be applied to path control for data packets [cite: "it is an object of the invention to provide a communication system, a forwarding node, a path management server, a communication method, and a computer program, that can be implemented using a simplified forwarding table, and moreover can also be applied to path control for data packets."]. This is achieved by:

• A path management server that configures forwarding path information by arranging short identifiers (e.g., 1 byte) for communication interfaces or links between forwarding nodes [cite: "a path management server that configures forwarding path information by arranging identifiers for identifying communication interfaces provided in respective forwarding nodes in a forwarding path of a data transfer network or links extending between the respective forwarding nodes and neighboring nodes thereof"].
• Forwarding nodes that perform packet forwarding based on this path information, which is included in a header added to the packet [cite: "a forwarding node that performs packet forwarding processing in accordance with the forwarding path information, with regard to a packet to which is added a header containing the forwarding path information"].
• The use of these short identifiers significantly reduces overhead, making the approach suitable for data packets [cite: "the identifiers forming the forwarding path information in the present invention can be described by short information, 1 byte long, for example, so that the influence on net data amount is minor or insignificant. Accordingly, it is possible to contain information describing the forwarding path for each 1 hop, with regard to not only some control packets, but all packets, such as data packets, and high level forwarding control becomes possible."].
• Forwarding nodes are simplified, only needing to hold "correspondence relationships between the identifiers and communication interfaces of destinations" rather than large routing tables [cite: "the respective forwarding nodes hold correspondence relationships between the identifiers and communication interfaces of destinations, and since there is no necessity to hold a forwarding table such as a routing table mentioned at the start of the specification, having a large number of items, it is possible to reduce the amount of memory. Furthermore, since determination of a destination can be performed simply and quickly, it is possible to reduce packet forwarding delay also. In addition, CPU processing ability of the respective forwarding nodes can be low."].
• "Boundary forwarding nodes" are responsible for adding and removing these path information headers when packets enter or exit the controlled data transfer network [cite: "addition and removal of the header including the forwarding path information described above may be performed as follows, among forwarding nodes, in a forwarding node (boundary forwarding node) disposed at a boundary with an external network"].

Identified Prior Art and Their Problems (as stated in '249 patent):

1. IP Networks (Background): Rely on routing tables, leading to "routing information explosion," increased memory requirements, and declining processing capability. They also lack "exact path control" based on application or source address [cite: "Forwarding nodes based on IP technology, more specifically, routing tables held by switches and routers, have been steadily growing larger, and a problem called routing information explosion has been pointed out. As a result of the increase in routes, the required amount of memory for holding routing tables increases, and, since time is taken for route determination processing, packet forwarding processing capability declines.", "since the forwarding destination is determined by only the destination address, there is a problem in that exact path control is not possible due to differences concerning which application the communication is performed by, or of source address."].
2. Source Routing (Background): A method where a source node explicitly lists forwarding node addresses in a packet. While allowing path specification, it suffers from "a problem in that a net data amount that can be included in a packet decreases" due to large overhead, making it "not suitable for transmission of data packets" [cite: "in the abovementioned source routing, since addresses of forwarding nodes 100 are contained in a packet, there is a problem in that a net data amount that can be included in a packet decreases. Accordingly, source routing is limited to certain applications such as network tests and the like, and is not used in packets (referred to below as ‘data packets’) that are used in communication such as with applications."].
3. CR-LDP (Constraint Routing-Label Distribution Protocol) in MPLS (Background): An MPLS technology for strictly indicating packet forwarding paths (traffic engineering), analogous to source routing. Similar to source routing, it includes forwarding node information (e.g., IPv4/IPv6 addresses) for each hop, leading to increased information and being "not realistic" for data packets outside of control packets. It also necessitates setting forwarding information for each policy inside the forwarding node [cite: "in packets used in CR-LDP, information of forwarding nodes for each forwarding action (for each 1 hop) is included, similar to the source routing in the abovementioned IP routing. As forwarding node information, for example IPv4 addresses or IPv6 addresses are used, but in this case also, when all forwarding node information is listed up within the forwarding path, the information in question increases, so that use outside of control packets is not realistic."].
4. OpenFlow (Non-Patent Document 1: "OpenFlow: Enabling Innovation in Campus Networks"): Proposes centralized path control by an OpenFlow controller, which manages flow tables in OpenFlow switches. When a switch receives a new flow, it asks the controller for path determination, receives a flow entry, and updates its table. The '249 patent, however, notes that "each forwarding node has to refer to a flow table...and it is considered that, accompanying an increase of entries, latency (delay time) occurs and loads are imposed on the nodes" [cite: "Furthermore, in the method of Non-Patent Document 1, each forwarding node has to refer to a flow table, as in the method of referring to the routing table mentioned at the start of this specification, and it is considered that, accompanying an increase of entries, latency (delay time) occurs and loads are imposed on the nodes."].

Obviousness Combination: OpenFlow (Non-Patent Document 1) in view of CR-LDP/Source Routing (Background Art)

A PHOSITA, seeking to overcome the aforementioned problems, would have been motivated to combine the centralized control capabilities of OpenFlow with the explicit path specification of CR-LDP/source routing, while addressing their respective limitations.

Motivation for Combination:

A PHOSITA would recognize that OpenFlow (Non-Patent Document 1) offers a powerful solution for "exact path control" and "varied forwarding policies," which were problems in IP networks [cite: "In OpenFlow, communication is taken as end-to-end flow, and path control, recovery from failure, load balancing, and optimization are performed in flow units."]. The OpenFlow controller already functions as a centralized entity capable of determining optimal paths for packets. However, the '249 patent explicitly highlights the major drawback of OpenFlow: "accompanying an increase of entries [in the flow table], latency (delay time) occurs and loads are imposed on the nodes" [cite: "Furthermore, in the method of Non-Patent Document 1, each forwarding node has to refer to a flow table, as in the method of referring to the routing table mentioned at the start of this specification, and it is considered that, accompanying an increase of entries, latency (delay time) occurs and loads are imposed on the nodes."].

To address this flow table explosion and associated performance degradation in OpenFlow, a PHOSITA would naturally look for ways to offload detailed path information from the forwarding node's internal table. Source routing and CR-LDP (background art) directly provide this concept: placing the explicit forwarding path directly into the packet header [cite: "Source routing is a method in which a node that is a source...explicitly lists up, in a packet to be transmitted, addresses of forwarding nodes 200 that are desired to be in a forwarding path.", "in packets used in CR-LDP, information of forwarding nodes for each forwarding action (for each 1 hop) is included, similar to the source routing in the abovementioned IP routing."]. This would immediately alleviate the burden of large flow tables on individual forwarding nodes.

However, the PHOSITA would then encounter the well-known problem of source routing and CR-LDP: "large overhead" due to listing full network addresses (e.g., IPv4/IPv6 addresses) for each hop, making them "not realistic" for data packets [cite: "in the abovementioned source routing...there is a problem in that a net data amount that can be included in a packet decreases.", "when all forwarding node information is listed up within the forwarding path, the information in question increases, so that use outside of control packets is not realistic."]. To resolve this, a PHOSITA would be motivated to replace the lengthy global addresses with short, locally significant identifiers (e.g., 1-byte link IDs or interface IDs). The use of compact, local identifiers for efficient forwarding within a controlled domain is a known networking technique (e.g., VLAN tags, MPLS labels themselves are shorter than IP addresses). This modification directly overcomes the "large overhead" problem and enables path control for "data packets," a key objective of the '249 patent.

How the Combination Leads to the Claims of US9900249:

1. Path Management Server: The OpenFlow controller already functions as a centralized "path management server" that determines and provides paths [cite: "the OpenFlow switch forwards the received packet to the OpenFlow controller via a secure channel, requests determination of a path of the packet based on source and destination of the received packet, receives a flow entry for realizing this, and updates the flow table."]. It would be obvious to adapt this controller to calculate and provide a sequence of short, local identifiers representing the full path, rather than just individual flow entries.
2. Forwarding Path Information in Packet Header: The explicit teaching of source routing and CR-LDP is to include forwarding path information directly in the packet header [cite: "Source routing is a method in which a node that is a source...explicitly lists up, in a packet to be transmitted, addresses of forwarding nodes 200 that are desired to be in a forwarding path.", "in packets used in CR-LDP, information of forwarding nodes for each forwarding action (for each 1 hop) is included"].
3. Arranging Short Identifiers (local IDs/link IDs/interface IDs): The motivation to address the "large overhead" of CR-LDP and source routing, making them impractical for data packets, would drive a PHOSITA to use compact, locally unique identifiers (e.g., 1-byte link IDs or interface IDs) for each hop, significantly reducing the header size. The '249 patent explicitly states this is a feature differentiating it from traditional source routing [cite: "The identifiers forming the forwarding path information in the present invention, different from source routing mentioned at the start of the present specification, can be described by short information, 1 byte long, for example, so that the influence on net data amount is minor or insignificant."].
4. Simplified Forwarding Table: By placing the explicit path in the packet header using short local IDs, the forwarding nodes no longer require large, complex routing or flow tables. Instead, they only need a simple, reduced memory lookup table mapping a local ID (read from the header) to an output communication interface, as described in the '249 patent [cite: "it is sufficient if the respective forwarding nodes hold correspondence relationships between the identifiers and communication interfaces of destinations, and since there is no necessity to hold a forwarding table such as a routing table mentioned at the start of the specification, having a large number of items, it is possible to reduce the amount of memory."]. This directly resolves the "routing information explosion" and "increase of entries" problems identified in the prior art.
5. Boundary Forwarding Node for Header Operation: MPLS (background art) already teaches the concept of "forwarding nodes arranged at a boundary" that add labels upon entering an MPLS network and remove them when forwarding to an external network [cite: "Assigning the label is performed when, after the packet is received by a forwarding node arranged at a boundary of an MPLS network...When forwarding to an external network by a forwarding node arranged at the boundary of the MPLS network, the label is removed by the forwarding node in question."]. It would be obvious for a PHOSITA to apply this known boundary function for adding and removing the new compact path information header.
6. Direction and Current Offset in Header: Once path information is structured as a list of identifiers in a header, including fields like "Direction" for flexible bidirectional forwarding and "Current Offset" to efficiently indicate the currently active identifier for the next hop are straightforward engineering optimizations for managing packet processing within the header.
7. Path Information Cache (Second Embodiment): OpenFlow switches already learn new flow entries from the controller and update their flow tables to avoid future controller lookups [cite: "receives a flow entry for realizing this, and updates the flow table."]. This concept of caching path-related information is inherent in OpenFlow. A PHOSITA would find it obvious to implement a cache at the boundary forwarding node for frequently used paths or reverse paths to further reduce requests to the centralized path management server, drawing from the existing OpenFlow mechanism for reducing controller interaction for subsequent packets in a flow.

In conclusion, the '249 patent's claimed invention, while addressing valid problems, represents an obvious combination of known elements from OpenFlow and source routing/CR-LDP, motivated by the explicit shortcomings of these prior art systems as identified within the '249 patent itself. The modifications, such as using short, local identifiers and a simplified lookup table, would have been evident engineering choices for a PHOSITA seeking to optimize performance and reduce overhead in such a combined system.