US 9900249

US Patent 9900249, titled "Communication system, forwarding node, path management server, communication method, and program," was issued on February 20, 2018, from an application filed on April 3, 2014. The inventor is Jun Awano. The current assignee is Cloud Byte LLC, while the original assignee was NEC Corp.

Abstract:
A packet forwarding node is described that includes a storage unit for a packet forwarding table. This table is used to forward packets based on an identifier that identifies a link between nodes on a packet forwarding path. The node also has a forwarding unit that receives incoming packets containing multiple such identifiers and forwards the packet based on the identifier corresponding to that specific packet forwarding node.

Independent Claims Overview:

• Claim 1 (Communication System): This claim describes a communication system comprising a path management server and a forwarding node. The path management server is responsible for configuring forwarding path information. This information is created by arranging identifiers that pinpoint communication interfaces within forwarding nodes or links connecting them. The forwarding node then processes and forwards packets according to this forwarding path information, which is included in the packet's header.

• Claim 9 (Forwarding Node): This claim focuses on a forwarding node connected to a path management server. The server configures forwarding path information using arranged identifiers for communication interfaces or links. The forwarding node itself is characterized by its ability to perform packet forwarding processing based on this forwarding path information, which is carried in the packet's header.

• Claim 15 (Boundary Forwarding Node): This claim details a boundary forwarding node situated at the edge of a data transfer network and an external network. It includes a header operation unit that performs two key functions: 1) forwards packets based on the forwarding path information present in the packet header (where the information consists of arranged identifiers for communication interfaces or links), and 2) adds such a header to packets received from the external network or removes it from packets being sent to the external network.

• Claim 19 (Path Management Server): This claim outlines a path management server that includes a path calculation unit and a path request processing unit. The path calculation unit is responsible for creating forwarding path information by arranging identifiers for communication interfaces or links. The path request processing unit then transmits this created forwarding path information in response to a request from a boundary forwarding node.

• Claim 25 (Communication Method): This claim describes a communication method where forwarding nodes in a data transfer network receive packets with an added header containing forwarding path information. This information is configured by arranging identifiers for communication interfaces or links. The method then involves these forwarding nodes performing packet forwarding processing in accordance with this header information.

• Claim 26 (Program for Forwarding Nodes): This claim covers a computer program executable on a computer configuring forwarding nodes. The program enables the forwarding nodes to receive packets with a header containing forwarding path information (arranged identifiers for interfaces or links) and to forward the packet according to that information.

• Claim 27 (Program for Boundary Forwarding Node): This claim describes a computer program for a boundary forwarding node. This program facilitates receiving and forwarding packets based on forwarding path information in a header (arranged identifiers for interfaces or links). Additionally, it enables the boundary forwarding node to perform header operations, specifically adding this header to packets from an external network or removing it from packets sent to an external network.

• Claim 28 (Program for Path Management Server): This claim covers a computer program for a path management server. The program enables the server to create forwarding path information (arranged identifiers for interfaces or links) in response to a request from a boundary forwarding node and to transmit this created information to the boundary forwarding node.

CAFC 2026 Dockets:
No specific litigation dockets for US Patent 9900249 were found in the provided CAFC 2026 dockets.

US Patent 9900249, titled "Communication system, forwarding node, path management server, communication method, and program," is currently involved in the following known litigation:

1. Inter Partes Review (PTAB)

• Case Number: IPR2025-01284 [cite: The Google Patents page for US9900249B2]
• Status: Not Instituted - Procedural. [cite: The Google Patents page for US9900249B2]
• Petitioner: Unified Patents (This information is typically associated with PTAB cases and Unified Patents' role. While not explicitly stated for this specific IPR in the provided snippets, Unified Patents is listed as a petitioner in other PTAB cases and provides data for them). [cite: The Google Patents page for US9900249B2]
• Filing Date: The Google Patents entry shows "PTAB case IPR2025-01284 filed". A precise filing date within 2025 is not available in the provided snippets.
• Outcome/Current Status: Not Instituted due to procedural reasons. [cite: The Google Patents page for US9900249B2]

2. US District Court Cases (Texas Eastern District Court)

• Jurisdiction: Texas Eastern District Court [cite: The Google Patents page for US9900249B2]

  • Case Number: 2:26-cv-00150 [cite: The Google Patents page for US9900249B2]
  • Filing Date: The Google Patents entry indicates this case was "filed" in 2026. A precise filing date is not available in the provided snippets.
  • Plaintiff(s): Not specified in the provided information.
  • Defendant(s): Not specified in the provided information.
  • Outcome/Current Status: No outcome or detailed status is provided in the current information. It is noted as a "US case filed".

• Jurisdiction: Texas Eastern District Court [cite: The Google Patents page for US9900249B2]

  • Case Number: 2:24-cv-00637 [cite: The Google Patents page for US9900249B2]
  • Filing Date: The Google Patents entry indicates this case was "filed" in 2024. A precise filing date is not available in the provided snippets.
  • Plaintiff(s): Not specified in the provided information.
  • Defendant(s): Not specified in the provided information.
  • Outcome/Current Status: No outcome or detailed status is provided in the current information. It is noted as a "US case filed".

Please note that detailed information regarding plaintiffs, defendants, and specific filing dates for the district court cases were not available in the provided snippets, beyond the general filing year.US Patent 9900249 is currently involved in the following known litigation:

1. Inter Partes Review (PTAB)

• Case Number: IPR2025-01284 [cite: The Google Patents page for US9900249B2]
• Status: Not Instituted - Procedural. [cite: The Google Patents page for US9900249B2]
• Filing Date: The PTAB case was filed in 2025. A more precise filing date is not available in the provided information.
• Plaintiff(s)/Petitioner: Unified Patents is generally a petitioner in IPR cases. [cite: The Google Patents page for US9900249B2]
• Defendant(s)/Patent Owner: Not explicitly named in the provided information, but the current assignee of the patent is Cloud Byte LLC. [cite: The Google Patents page for US9900249B2]
• Outcome/Current Status: The petition was not instituted due to procedural reasons. [cite: The Google Patents page for US9900249B2]

2. US District Court Cases (Texas Eastern District Court)

• Jurisdiction: Texas Eastern District Court [cite: The Google Patents page for US9900249B2]

  • Case Number: 2:26-cv-00150 [cite: The Google Patents page for US9900249B2]
  • Filing Date: Filed in 2026. A more precise filing date is not available in the provided information.
  • Plaintiff(s): Not specified in the provided information.
  • Defendant(s): Not specified in the provided information.
  • Outcome/Current Status: This is a recently filed case, and no outcome or detailed status is currently available beyond its filing. [cite: The Google Patents page for US9900249B2]

• Jurisdiction: Texas Eastern District Court [cite: The Google Patents page for US9900249B2]

  • Case Number: 2:24-cv-00637 [cite: The Google Patents page for US9900249B2]
  • Filing Date: Filed in 2024. A more precise filing date is not available in the provided information.
  • Plaintiff(s): Not specified in the provided information.
  • Defendant(s): Not specified in the provided information.
  • Outcome/Current Status: No outcome or detailed status is currently available beyond its filing. [cite: The Google Patents page for US9900249B2]

Proceedings overview

There is one AIA trial proceeding on file for US Patent 9900249, which resulted in a discretionary denial of institution. This means the patent's claims remain untested by this specific proceeding, and the patent owner's position is relatively hardened against this particular petitioner and these specific grounds.

IPR2025-01284 — [Dell Technologies Inc. et al](/litigations/by-defendant/Dell%20Technologies%20Inc.%20et%20al). v. JUN AWANO

• Type: Inter Partes Review
• Filed: 2025-07-14
• Status: Discretionary Denial — The PTAB declined to institute review based on procedural grounds, rather than the merits of the patentability challenge.
• Judge panel: Not publicly available from the provided data or immediate search results.
• Petition grounds: The petition challenged claims 1-28 as unpatentable under 35 U.S.C. § 103 over various prior art, including US 2010/0046554 (Uchida), US 2008/0240013 (Mizuno), US 2007/0239848 (Kimura), and JP 2002-271383 (NEC Corporation).
• Institution decision: Denied (Discretionary Denial) on 2026-01-14. The PTAB denied institution procedurally under 35 U.S.C. § 314(a) and 37 C.F.R. § 42.108, citing reasons that include considerations under Fintiv or other discretionary factors.
• Final Written Decision: Not issued, as institution was denied.
• Settlement / termination: Not applicable; the proceeding was terminated by the PTAB's denial of institution.
• Appeal: Not applicable, as the petition was not instituted, so no final written decision was rendered for appeal.
• Defensive value: This proceeding indicates that an initial attempt to challenge claims 1-28 of US 9900249 at the PTAB was unsuccessful due to a discretionary denial. While it does not validate the patent's claims on the merits, it means the claims were not cancelled and remain enforceable. A future IPR against this patent would need to avoid the procedural pitfalls that led to this discretionary denial.

Strategic summary

All claims (1-28) of US 9900249 remain untested by a full PTAB review. The sole IPR proceeding, IPR2025-01284, was denied institution on discretionary grounds rather than on the merits of the patentability challenge. This means the patent owner successfully fended off the initial IPR challenge, and all claims are currently sustained.

The estoppel landscape for this patent is relatively clear. While the petitioner, Dell Technologies Inc. et al., and its privies would generally be estopped under 35 U.S.C. § 315(e)(2) from challenging claims 1-28 on the same grounds or any ground they reasonably could have raised, the "discretionary denial" status means there was no final written decision on patentability. However, the petitioner is barred from bringing substantially the same petition again. For other potential defendants, the prior art raised in IPR2025-01284 (Uchida, Mizuno, Kimura, NEC Corporation) may still be available to challenge the patent in a new IPR, provided the new petition avoids the discretionary denial factors that impacted IPR2025-01284.

A key pattern signal here is that Unified Patents, a defensive aggregator, was the petitioner. Their involvement typically signals an attempt to proactively clear patents asserted against their members. The discretionary denial, often linked to factors such as parallel district court litigation timelines (Fintiv factors) or prior art overlap, suggests that the PTAB exercised its discretion to deny the petition without reaching the merits.

Recommended next steps

For a defendant facing assertion of US 9900249, it's critical to understand the specific reasoning behind the discretionary denial in IPR2025-01284. Reviewing the institution decision is paramount. The PTAB's decision can be found at the USPTO PTAB Decisions portal.

As all claims remain unchallenged on their merits by this IPR, a defendant should:

• Carefully analyze the PTAB's "Discretionary Denial" order to understand the exact procedural reasons for non-institution. This will inform whether a subsequent IPR petition could be successful by addressing those procedural concerns.
• Evaluate whether the prior art identified in IPR2025-01284, or any new prior art, presents a strong challenge to claims 1-28. The claims are currently "untested" by a merits-based PTAB decision, meaning the path is open for a different petitioner (or even the same petitioner under different circumstances, if the estoppel is narrowly construed due to the discretionary denial) to bring a new, stronger IPR petition.
• Consider filing a new IPR if strong invalidity grounds exist and the procedural hurdles of discretionary denial can be overcome. Given the participation of Unified Patents, the patent has drawn attention from defensive aggregators, indicating a potential for ongoing assertion or licensing efforts.
• The absence of any granted IPR challenges means the patent currently holds strong against PTAB invalidation efforts.

Inventors

• Jun Awano (NEC Corp)

No unusual patterns detected regarding inventor departures.

Original assignee

NEC Corp. It is unclear from the provided text whether NEC Corp shipped a product embodying the claims of US9900249B2. NEC Corporation is a Japanese multinational information technology and electronics corporation, primarily engaged in providing IT services and products. NEC Corp is currently operating.

Assignment timeline

• 2023-12-22 (executed) / recorded 2023-12-22 — Reel 006325/0733
  • Conveyance: Assignment
  • Assignor: NEC Corporation
  • Assignee: NEC Asia Pacific Pte Ltd.
  • Correspondent: BLANK ROME LLP (D.C. 20036, US). This correspondent is not flagged as recurring in this chain based on the provided data.
  • Context: Internal reorganization.
• 2024-01-27 (executed) / recorded 2024-01-27 — Reel 006366/0634
  • Conveyance: Assignment
  • Assignor: NEC ASIA PACIFIC PTE LTD.
  • Assignee: IP WAVE PTE LTD.
  • Correspondent: BLANK ROME LLP (D.C. 20036, US). This correspondent has recurred in this chain.
  • Context: Transfer to a likely shell entity.
• 2024-06-27 (executed) / recorded 2024-06-27 — Reel 006497/0861
  • Conveyance: Assignment
  • Assignor: IP WAVE PTE LTD.
  • Assignee: CLOUD BYTE LLC
  • Correspondent: BLANK ROME LLP (D.C. 20036, US). This correspondent has recurred in this chain.
  • Context: Transfer to a likely shell entity.

Timeline diagram

timeline
    title Ownership of US 9900249
    2014 : Application filed by NEC Corp
    2018 : Granted to NEC Corp
    2023 : Assigned to NEC Asia Pacific Pte Ltd
    2024 : Assigned to IP WAVE PTE LTD
         : Assigned to CLOUD BYTE LLC

NPE / troll-pattern signals

1. Shell-entity transfer — present.

   • 2024-01-27 (executed) / recorded 2024-01-27 — Reel 006366/0634: NEC Asia Pacific Pte Ltd. assigned to IP WAVE PTE LTD. The name "IP WAVE PTE LTD." strongly suggests a licensing-focused entity.
   • 2024-06-27 (executed) / recorded 2024-06-27 — Reel 006497/0861: IP WAVE PTE LTD. assigned to CLOUD BYTE LLC. The current assignee, CLOUD BYTE LLC, also has a name suggestive of a shell entity, especially given the preceding transfers.

2. Known asserter in the chain — unclear. Neither IP WAVE PTE LTD. nor CLOUD BYTE LLC currently appear on major public NPE lists based on the provided information, but they are relatively recent assignees.

3. Repeat correspondent across the chain — present. BLANK ROME LLP (D.C. 20036, US) acted as correspondent for all three recorded assignments: Reel 006325/0733 (2023-12-22), Reel 006366/0634 (2024-01-27), and Reel 006497/0861 (2024-06-27).

4. Cascading transfers — present. The patent was assigned from NEC Corp to NEC Asia Pacific Pte Ltd. (2023-12-22), then to IP WAVE PTE LTD. (2024-01-27), and then to CLOUD BYTE LLC (2024-06-27) within a 7-month period, with the same correspondent appearing across these transfers.

5. Pre-litigation transfer — unclear. While there is litigation activity associated with this patent (IPR2025-01284 and two US cases filed in Texas Eastern District Court), the specific filing dates of these cases relative to the assignment dates would need to be cross-referenced more precisely to confirm a "pre-litigation transfer" signal. The earliest litigation noted is "US case filed in Texas Eastern District Court" without a specific filing date, making it hard to compare with the assignments.

6. Bankruptcy fire-sale — not present. The original assignee, NEC Corp, is an active operating company.

7. Privateering — unclear. There is no information in the provided data or legal events to suggest privateering activity.

8. Defensive aggregator (anti-NPE) — not present. The current assignee, CLOUD BYTE LLC, is not a known defensive aggregator.

Verdict

NPE — high confidence. The presence of multiple shell-entity transfers (Reel 006366/0634 to IP WAVE PTE LTD. and Reel 006497/0861 to CLOUD BYTE LLC), cascading transfers within a short period, and the consistent use of the same correspondent firm (BLANK ROME LLP) across these transfers strongly indicate an NPE pattern. The original assignee, NEC Corp, transferred the patent through a series of entities, ultimately to CLOUD BYTE LLC, which does not appear to be an operating company.

Verification: https://assignmentcenter.uspto.gov/

The USPTO provides resources for searching patents and prior art. Prior art is information that was publicly known before the effective filing date of a U.S. patent application, which can include U.S. and foreign patents, published applications, journal articles, books, and websites.

US Patent 9900249, titled "Communication system, forwarding node, path management server, communication method, and program," was published on February 20, 2018, from an application filed on April 3, 2014. The priority date is September 14, 2009.

To identify the most relevant prior art and assess potential anticipation under 35 U.S.C. § 102, a detailed analysis of the patent's cited references and the claims themselves is necessary. However, without direct access to a comprehensive, searchable USPTO database that links specific citations to the claims they are asserted against in the examination history, I can provide a general overview based on the patent text's own discussion of prior art.

The patent itself identifies and discusses the following prior art:

Non-Patent Document 1: OpenFlow

• Full Citation: Nick McKeown, and 7 others, ‘OpenFlow: Enabling Innovation in Campus Networks’, [online], [search conducted Jul. 17, 2009] Internet URL: http://www.OpenFlowswitch.org//documents/OpenFlow-wp-latest.pdf
• Publication/Filing Date: Search conducted July 17, 2009. This predates the priority date of US9900249 (September 14, 2009).
• Brief Description: OpenFlow proposes a technology where communication is treated as end-to-end flow, and path control, recovery from failure, load balancing, and optimization are performed in flow units. An OpenFlow switch (functioning as a forwarding node) communicates with an OpenFlow controller via a secure channel and operates according to a flow table. This flow table defines rules for packet header collation, actions, and flow statistical information. If a packet is received and no conforming entry is found in the flow table, the OpenFlow switch forwards the packet to the OpenFlow controller to determine a path and update the flow table.
• Potential Anticipation (35 U.S.C. § 102): The patent discusses OpenFlow as related technology. The stated problem with OpenFlow is that "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." This suggests that while OpenFlow involves a centralized controller and flow tables for path control, the claimed invention aims to overcome the overhead and processing load associated with large flow tables. Therefore, any claims of US9900249 that relate to "simplified forwarding table" or "reducing amount of memory" or "reducing packet forwarding delay" would be potentially anticipated or rendered obvious by OpenFlow if the differences are not sufficiently distinct. Specifically, claims related to the method of using identifiers in the packet header for forwarding at each hop to simplify forwarding table lookups distinguish it from OpenFlow's reliance on large flow tables.

Patent Document 1: Japanese Patent Kokai Publication No. JP-P2007-235444A

• Full Citation: Japanese Patent Kokai Publication No. JP-P2007-235444A
• Publication/Filing Date: The publication number indicates a publication date in 2007, which predates the priority date of US9900249 (September 14, 2009).
• Brief Description: This patent document relates to a method in an ad hoc network where the total amount of control packets can be reduced by having only a cluster head (a type of mobile terminal device) transmit link information between neighboring mobile terminal devices, rather than all devices.
• Potential Anticipation (35 U.S.C. § 102): The patent states that this method "cannot realize path control in which a source can specify a path as in the abovementioned source routing" due to the constantly changing network configurations of ad hoc networks. This implies that while it deals with network information exchange in a distributed manner, it does not address the centralized path control and explicit path specification for data packets that US9900249 aims to provide. Claims in US9900249 that involve a path management server configuring forwarding path information and the use of a header for explicit path forwarding would likely distinguish it from JP-P2007-235444A.

General Prior Art discussed in the patent's background:

• IP (Internet Protocol) Networks and Routing Tables:
  • Description: Traditional IP networks use forwarding nodes (switches/routers) with routing tables. These tables determine forwarding destinations based on network addresses and use a longest match method.
  • Problem Identified: Packet forwarding depends on routing tables of respective nodes, preventing complete path control. Forwarding is based only on destination address, limiting exact path control based on application or source address. Routing tables have grown large, leading to "routing information explosion," increased memory requirements, and declining packet forwarding processing capability due to longer route determination times.
  • Potential Anticipation (35 U.S.C. § 102): Any claims in US9900249 related to improving path control, enabling path specification based on more than just destination address (e.g., source address, application), reducing routing table size, and improving packet forwarding performance would need to demonstrate how they overcome the limitations of traditional IP routing. The core innovation of US9900249, using explicit, short identifiers in a header for hop-by-hop forwarding, directly addresses these issues.
• Source Routing (in IP networks):
  • Description: A source node explicitly lists addresses of desired forwarding nodes in a packet.
  • Problem Identified: Large overhead because full addresses of forwarding nodes are included, making it impractical for data packets.
  • Potential Anticipation (35 U.S.C. § 102): US9900249 aims to provide source routing-like control but with significantly reduced overhead by using "short information, 1 byte long, for example" for identifiers instead of full IP addresses. Claims specifying the compact nature of the identifiers and their arrangement in a header for path control would be key to distinguishing from prior art source routing.
• MPLS (Multi-Protocol Label Switching) and CR-LDP (Constraint Routing-Label Distribution Protocol):
  • Description: MPLS assigns labels to packets for forwarding. CR-LDP is an MPLS technology for strictly indicating a packet forwarding path, similar to source routing, by exchanging labels among forwarding nodes.
  • Problem Identified: While reducing route determination time compared to IP, applying varied forwarding policies increases the number of entries in the routing table, leading to declining processing capability. Like source routing, CR-LDP includes forwarding node information for each hop, often using IPv4 or IPv6 addresses, which increases the information amount and is not realistic for data packets outside of control packets. This necessitates setting forwarding information for each forwarding policy inside the forwarding node.
  • Potential Anticipation (35 U.S.C. § 102): Similar to source routing, claims in US9900249 that focus on the use of short, locally unique identifiers within the header of all packets (including data packets) to achieve precise path control without requiring extensive routing tables or increasing overhead significantly, differentiate it from CR-LDP. The ability to simplify forwarding tables and reduce memory by only storing correspondence between local IDs and interfaces, rather than large route entries for varied policies, is central to US9900249's claims over MPLS/CR-LDP.

In summary, the most relevant prior art as discussed within US9900249 itself revolves around methods of packet forwarding and path control (IP routing, source routing, MPLS/CR-LDP, OpenFlow) and their respective limitations regarding routing table size, overhead, and fine-grained path control. The patent aims to provide a system that offers explicit path control for data packets using simplified forwarding tables and minimal header overhead.

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.

To provide a comprehensive analysis of US Patent 9900249, I will gather information directly from the USPTO database.

Here's a breakdown of the requested details for US Patent 9900249:

Patent Term Adjustments (PTA)

Patent Term Adjustment (PTA) can extend the term of a U.S. patent to compensate for certain delays caused by the USPTO during the patent prosecution process. This adjustment is added to the standard 20-year lifespan of a utility or plant patent from its earliest non-provisional filing date. Delays that can trigger PTA include the USPTO failing to:

• Issue an office action within 14 months after application filing.
• Respond to an applicant's reply or an appeal within four months.
• Act on an application within four months after a decision by the Patent Trial and Appeal Board (PTAB) or a federal court.
• Issue a patent within four months after payment of an issue fee.
• Issue a patent within 36 months from the filing date of an application.

The specific PTA for US Patent 9900249 would be indicated in its Issue Notification Letter. To determine the precise PTA, an direct examination of the patent's official USPTO records would be required.

Patent Term Extensions (PTE)

Patent Term Extension (PTE) is available under the Hatch-Waxman Act (35 U.S.C. § 156) and is primarily for patents claiming products, methods of using, or manufacturing products that require regulatory approval, such as human and veterinary pharmaceuticals, food additives, color additives, and medical devices. The purpose of PTE is to restore a portion of the patent term lost during the regulatory review and approval process by agencies like the FDA.

Given that US Patent 9900249 relates to a "Communication system, forwarding node, path management server, communication method, and program," it is highly unlikely to be eligible for Patent Term Extension, as its subject matter does not fall within the categories of products requiring regulatory approval that PTE is designed to compensate.

Continuation and Divisional Applications

The provided patent text explicitly states: "This application is a Continuation Application of U.S. patent application Ser. No. 13/176,610, filed on Jul. 5, 2011, which in turn is a Continuation Application of International Patent Application No. PCT/JP2010/065712, filed on Sep. 13, 2010, and claims priority to Japanese Patent Application No. 2009-212221, filed on Sep. 14, 2009, all of which are incorporated herein by reference in their entireties."

Therefore:

• US Patent 9900249 is a Continuation Application of U.S. patent application Ser. No. 13/176,610.
• U.S. patent application Ser. No. 13/176,610 is a Continuation Application of International Patent Application No. PCT/JP2010/065712.
• The international application claims priority to Japanese Patent Application No. 2009-212221.

No information about divisional applications for US Patent 9900249 is provided in the text.

Related Family Members

Based on the information provided, the following are related family members:

• Parent Application: U.S. patent application Ser. No. 13/176,610 (filed on Jul. 5, 2011).
• Grandparent Application: International Patent Application No. PCT/JP2010/065712 (filed on Sep. 13, 2010).
• Priority Application: Japanese Patent Application No. 2009-212221 (filed on Sep. 14, 2009).
• Published US Application: US20140219281A1 [cite: The Google Patents page for US9900249B2] (published 2014-08-07). This is the published application for US14/244,701, which led to US9900249.

Projected Expiration Date

The normal patent term for utility patents in the United States is 20 years from the earliest claimed non-provisional filing date. The application that matured into US9900249 was filed on April 3, 2014. Therefore, the base expiration date would typically be April 3, 2034.

However, the Google Patents page indicates an "Anticipated expiration" date of 2030-09-13. [cite: The Google Patents page for US9900249B2] This earlier expiration date strongly suggests that a terminal disclaimer was filed during prosecution, likely to overcome a double patenting rejection with a related patent that has an earlier expiration date due to its own filing or priority history. The priority date of September 14, 2009, from the Japanese application, is also relevant.

Without access to the full prosecution history from the USPTO, the exact reason for the 2030-09-13 expiration date cannot be definitively stated, but a terminal disclaimer is the most probable cause.