US 7295515

I'll search for this specific patent number across USPTO and CAFC records.

Let me run additional targeted searches to check for any litigation or CAFC activity involving this specific patent.

Search results: US Patent 7,295,515

Important caveat up front: My searches of public patent databases and Federal Circuit materials returned no CAFC 2026 docket, appeal, or IPR involving US 7,295,515, and no district-court assertion of this patent that I could locate. I cannot verify this is a complete negative — CAFC dockets are not fully indexed by general web search, and I have no direct access to PACER or the CAFC's own docket system. Treat "no litigation found" as a not-found result, not an affirmative clearance. All bibliographic data below comes from the authoritative full text of the patent provided (Google Patents rendering), which I prefer over search snippets.

Bibliographic data

Family / continuations (all claiming the 2000-08-09 priority date, all Juniper):

• US 11/850,417 → US 7,616,569 B2 (continuation, filed 2007-09-05)
• US 12/571,072 → US 8,213,312 B2 (filed 2009-09-30)
• US 13/492,423 → US 8,542,591 B2 (filed 2012-06-08)
• JP 2000-240546 → JP 3578062 B2

Abstract (as recorded)

A communication network design circuit can derive a path and a necessary link capacity for multiple point communication service permitting arbitrary communication within a predetermined range of communication amount by providing traffic amount of data in-flowing through an ingress node and traffic amount of data flowing out through an egress node. The communication network designing circuit has setting means for setting a mathematical programming problem for deriving the multiple point communication service and optimizing means for solving the mathematical programming problem set by the setting means and obtaining the path for the multiple point communication service.

Plain-language overview of the independent claims

Claim 1 — System (means-plus-function). A system for identifying a path for a "multiple point communication service" in a network of ingress nodes, egress nodes, and connecting links. It recites six functional blocks:

1. means for setting an objective function that minimizes link load in the network;
2. means for setting a first constraint expression for deriving that link load (this corresponds to equation (2): φ ≥ Σ w/c_given);
3. means for generating a second constraint expression for route selection (equation (3), a path-existence/"one path per ingress-egress pair" constraint using the 0/1 variable f);
4. means for generating a third constraint expression for computing link band from the traffic received at the ingress nodes;
5. means for generating a fourth constraint expression ensuring the link capacity limit is not exceeded (equation (6)); and
6. means for identifying the path from the objective function plus all four constraint expressions.

The distinctive added limitation in the granted claim is that the four generating/setting means are "configured to operate in parallel" — this mirrors the specification's statement that the mathematical-programming problem is set "in parallel," with the optimizer then solving the assembled problem.

Claim 3 — Method. The method counterpart of claim 1: the same six steps (set objective function → set first constraint → generate second → generate third → generate fourth → identify path), with the explicit method-step limitation that the four setting/generating steps "are performed in parallel." Because it is a method claim, it does not rely on §112(f) means-plus-function construction.

Claim 5 — System (named-generator form). The same invention recast without "means for" language, using Beauregard-style structural labels: an optimization reference generator (sets the objective function and the first constraint), a route selecting condition generator, a link capacity calculating condition generator, a link including condition generator, and an optimizer to identify the path. Again the four generators are required to "operate in parallel."

Dependent claims (brief)

• Claim 2 (dep. from 1) and Claim 4 (dep. from 3) and Claim 6 (dep. from 5) are substantively parallel: they add that input data rates are associated with the ingress nodes and output data rates with the egress nodes, and that the multiple point communication service permits an arbitrary data rate within a range based on those input and output rates.

Technical substance worth noting

The specification's real novelty is the shift from per-node-pair "fixed-band path" design (the prior art, illustrated in FIG. 4) to a many-to-many (multiple-point) design where the operator supplies only aggregate ingress inflow volumes v_ad and aggregate egress outflow volumes v_zd. The optimization relaxes the traffic matrix and instead bounds each link's required capacity by the downstream egress totals — the worked example shows link (n4,n5) carrying a theoretical 3 Mb/s of inflow but needing only 1 Mb/s of provisioned capacity because node n5 only drains 1 Mb/s. The specification also discloses two alternative objective functions — maximize minimum link vacant capacity, η (eq. 7–8), and minimize total link cost using per-unit-capacity link cost ω (eq. 9) — and an integer-programming formulation of the per-user capacity constraint using a 0/1 variable x_(l,m,k)ad and a big-M constant (eq. 10–13). Note: these alternative objective functions and the integer-programming embodiment appear in the specification but are not recited in the granted independent claims, which claim only the minimize-link-load objective.

Uncertainty flags

• I could not confirm any CAFC 2026 activity; my searches returned unrelated Juniper matters (e.g., Juniper v. Swarm Technology, IPR2021-01445; Monarch Networking v. Juniper; Finjan v. Juniper; Packet Intelligence v. Juniper), none of which involve 7,295,515.
• The 2019 maintenance-fee lapse and 2024 adjusted-expiration date come from the patent's docket listing (an algorithmic status indicator), not from a legal determination. I have not independently confirmed the fee status via USPTO Patent Center.
• The claim text I summarized is the granted, post-certificate-of-correction version. If you need the exact pre-correction wording, that would require the USPTO's official certificate of correction document, which I did not retrieve.

I'll research litigation involving US patent 7295515. Let me search multiple sources.

Let me search more targeted sources.

Let me search additional litigation-specific sources.

Litigation Search Results for US Patent No. 7,295,515

Summary: I found no evidence of any litigation involving U.S. Patent No. 7,295,515.

What I searched

• General web searches for the patent number ("7295515", "7,295,515") in connection with litigation, infringement, lawsuits, and PTAB proceedings.
• Queries targeting litigation aggregators (Unified Patents Portal, Docket Alarm, CourtListener, Justia), PACER/CAFC-style terms, and the patent title "Communication network design."

What I found

• The searches returned no docketed case, complaint, judgment, appeal, or PTAB (IPR/PGR/CBM) proceeding naming US 7,295,515 or the string "7295515" as an asserted patent. The only hits matching "7295515" as a raw number were unrelated Brazilian commercial-registry filings — not patent litigation.
• The Google Patents record for US 7,295,515 contains no litigation section at all. Its "Cited By" and "Families Citing/Cited By" sections list other patent publications (e.g., US20100020692A1, US8213312B2, US8542591B2, US6892169B1), which reflect citation/priority relationships — not court cases.
• The patent's prosecution and post-grant history shows only administrative events: assignment from NEC Corporation (2001) to Juniper Networks, Inc. (recorded 2005-02-15), a certificate of correction (2008), maintenance-fee payments (4-year in 2011; 8-year in 2015), and lapse for non-payment of maintenance fees (dated 2019-12-16; effective 2019-11-13). No litigation events appear.

Important caveats

• I was unable to complete direct, dedicated queries against the litigation-specific databases you named (Unified Patents Portal litigation case list, PACER, and the CAFC docket) before reaching my tool-call limit. My conclusion rests on general web search results and the Google Patents record, which do not affirmatively report litigation.
• Absence of hits is not the same as proof of absence. A definitive negative requires a direct search of PACER/CAFC dockets and a patent-centric litigation database (e.g., Lexis CourtLink, Westlaw LitAlert, or RPX/Unified Portal) filtered strictly to patent number 7,295,515. I could not run those final, authoritative checks.

Related procedural note (not litigation about '515)

The same patent family includes continuations US 7,616,569, US 8,213,312, and US 8,542,591 (all Juniper Networks, all from the same 2000-08-09 priority). Searching broad Juniper-related results surfaced other Juniper disputes (e.g., Juniper v. Palo Alto Networks, Civ. No. 11-1258-SLR (D. Del.); Finjan v. Juniper, 3:17-cv-05659 (N.D. Cal.); WSOU/Brazos v. Juniper, W.D. Tex.), but none of those cases asserted US 7,295,515 or its family members based on the information retrieved.

Bottom line

Based on the sources I could reach, no litigation is known involving US Patent No. 7,295,515. If you need a court-certified negative, I recommend a direct PACER/CAFC docket search and a Lexis/Westlaw patent-litigation report, which I was not able to run to completion here. I have flagged this limitation rather than implying a certainty I did not verify.

Proceedings overview

Total AIA trial proceedings on file: 0. The USPTO Open Data Portal returns no IPR, PGR, or CBM proceeding against US 7,295,515 — no institutions, no denials, no FWDs, no settlements, and no appeals — so the breakdown is 0 active / 0 claims invalidated / 0 claims sustained / 0 settled / 0 institution-denied, and my independent web searches surfaced no additional or recently-filed proceeding the ODP might not yet have indexed. The defensive posture a defendant gets from this is unusual and, on the facts, favorable in a way that has nothing to do with PTAB: the patent never had to be tested because it lapsed. US 7,295,515 expired for failure to pay maintenance fees, with the lapse recorded at 2019-12-16 and effective 2019-11-13, so there is no live patent to invalidate and no ongoing royalty exposure — only a possible pre-2019-11-13 past-damages theory, which is a much smaller target than a hardened IPR-tested patent.

Proceeding-level detail

No proceeding sections are reproduced here because there are no proceedings to reproduce. I will not generate placeholder numbers. What follows is the record I did verify, plus the adjacent material that a practitioner would otherwise mistake for a proceeding on this patent.

(no proceeding number) — no petitioner v. Juniper Networks, Inc.

• Type: n/a — no Inter Partes Review, Post-Grant Review, or Covered Business Method review was ever filed against US 7,295,515.
• Filed: n/a
• Status: n/a
• Judge panel: none assigned
• Petition grounds: none
• Institution decision: none
• Final Written Decision: none — no claim of this patent has been canceled or confirmed by the Board
• Settlement / termination: n/a
• Appeal: none to the Federal Circuit on this patent
• Defensive value: You cannot rely on a PTAB cancellation of any claim of US 7,295,515, because none exists. Your leverage is the maintenance-fee lapse, the terminal disclaimer tied to the continuation family, and the thinness of the specification's structural disclosure — not an IPR record.

False positives to rule out (these are not proceedings on 7295515)

• IPR2020-01351, Monolithic Power Systems, Inc. v. Volterra Semiconductor LLC — often returned by keyword searches for "7295515" because the respondent patent is US 7,772,955, a different patent. Institution denied 2021-03-04. See https://ipverse.greyb.com/ptab-web/cases/case-details/IPR2020-01351. Not relevant.
• IPR2018-01635, Juniper Networks, Inc. v. Parity Networks, LLC — Juniper here is the petitioner on US 6,553,005, and Juniper also owns US 7,295,515 (acquired from NEC on 2005-02-15). Petitioner-side activity is not a validity challenge to this patent. See https://www.docketalarm.com/cases/PTAB/IPR2018-01635/Juniper_Networks_Inc._v._Parity_Networks_LLC/.
• IPR2021-01445, Juniper Networks, Inc. v. Swarm Technology LLC — same confusion; different patent, different posture. FWD 2023-02-07; Federal Circuit affirmed in part (Swarm Technology LLC v. Amazon.com, Inc., Nos. 2023-2323, 2024-1095, 2025-06-30).

I found no evidence that US 7,295,515 was ever asserted in district court (the well-known Juniper v. Palo Alto Networks litigation, N.D. Cal. No. 11-1258-SLR, asserted the '723, '459, '634, '700, '280, '347, '752, and '612 patents — not this one). The absence of assertion is consistent with the absence of IPRs: this patent was never worth attacking because it was never worth asserting.

Strategic summary

Claim status: all six claims are UNTESTED, and all six are also LAPSED. US 7,295,515 issued 2007-11-13 with six claims — independent system claim 1, independent method claim 3, independent system claim 5, and dependent claims 2, 4, and 6. No claim has been canceled, narrowed by reexamination, or confirmed by the Board. But the maintenance-fee record is dispositive for practical purposes: a maintenance-fee reminder was mailed 2019-07-01, lapse for failure to pay was recorded 2019-12-16, the patent discontinued under 37 C.F.R. § 1.362, and it lapsed effective 2019-11-13. Google Patents separately shows an adjusted expiration of 2024-03-28 reflecting patent-term adjustment and the terminal disclaimer — but a terminal disclaimer and a PTA date do not resurrect a patent that lapsed for nonpayment, and no petition to revive appears on the face of the record. Unless Juniper files a § 1.378 revival petition (and none is shown), the enforceable term ended in November 2019. Note also that the entire continuation family is in the same condition: US 7,616,569, US 8,213,312, and US 8,542,591 are all "Expired - Fee Related," and US 8,542,591 carries an express terminal disclaimer. I did not locate any IPR against those siblings either, but treat that as "no evidence found," not as verified absence for the whole family.

Estoppel landscape: blank slate, and it doesn't matter much. Because no IPR, PGR, or CBM was ever instituted, no § 315(e)(2) estoppel attaches to anyone, and no § 325(e)(1) estoppel attaches at the Office. Any defendant is free to raise every § 102, § 103, § 112, and § 101 ground. That freedom is largely theoretical here: with the patent lapsed, an IPR would be an expensive way to attack a dead right, and the Board's current institution environment — the Director's bifurcated discretionary-then-merits gatekeeping announced 2025-03-26 and the Director-controlled institution memorandum of 2025-10-16 — makes institution on an old, expired, never-asserted patent improbable on discretionary grounds alone. If you are facing a past-damages demand covering pre-2019 conduct, litigate it in district court where invalidity and the six-year damages lookback interact, rather than paying IPR fees.

Pattern signals: none. No petitioner has filed anything against this patent or, on my search, against its three continuations. Juniper has not pursued PTAB appeals on this family because there was nothing to appeal. There is no defensive aggregator (Unified Patents or similar) anywhere in the chain — no third party ever took a free shot at it. The one substantive relationship worth noting is the provenance: originally assigned to NEC Corporation (assignment recorded 2001-08-08, effective 2001-07-23), then assigned to Juniper Networks, Inc. (recorded 2005-02-15, effective 2005-01-17), and a certificate of correction issued 2008-04-01.

Recommended next steps

• If you are a defendant and a demand letter cites US 7,295,515: the absence of any PTAB proceeding is your first point, but lead with the lapse instead. The record shows the patent expired for failure to pay maintenance fees, with the effective lapse date of 2019-11-13 (lapse recorded 2019-12-16; "PATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362"). Because there is no Final Written Decision to cite, do not build an argument on one. Demand that the plaintiff (a) produce evidence of a granted § 1.378 revival petition if it is asserting the patent as live, and (b) identify the pre-2019-11-13 acts and the accrual dates it relies on, since § 286 caps recovery at six years before filing and the patent itself stopped accruing liability in 2019.
• If active proceedings are pending: none are. There are no institution deadlines, no oral hearing dates, and no statutory one-year FWD dates to track, because no trial was ever instituted. If a proceeding surfaces after this writing, the ODP-structured list in the prompt is the canonical source and should be re-pulled; I found nothing on the open web to supplement it.
• If you are evaluating validity anyway: no claim has been tested, so you are not fighting an IPR-hardened record. The claims are drafted almost entirely in means-plus-function form ("means for setting an objective function," "means for generating a second constraint expression," "an optimization reference generator," etc.), which invites a § 112(f) construction limited to the corresponding structure in the specification and its equivalents — a fruitful line given how algorithmic the disclosure is. That is a practitioner observation about the claim language, not a holding by any tribunal, and it should be developed with the intrinsic record rather than asserted as settled.
• Verify before relying: I could not confirm the absence of all family-wide proceedings, litigation, or a later revival petition from the sources available to me. Confirm the current fee/reinstatement status in USPTO Patent Center and re-run the Patent Trial and Appeal Board's E2E docket (https://ptacts.uspto.gov/) plus CourtListener (https://www.courtlistener.com/) before finalizing any opinion letter.

I'll research this patent's assignment record and legal history before reconstructing the chain.

Let me try to pull the actual recorded assignment documents and check for any assertion history.

US 7295515 B2 — Ownership Chain Analysis

Patent: US 7295515 B2 — "Communication network design"
Appl. No.: US 09/924,054 · Filed: 2001-08-08 · Granted: 2007-11-13
Priority: JP 240546/2000 (2000-08-09) → JP 3578062 B2
Status: Expired — fee lapse, 2019-12-16 (37 CFR 1.362)

Sourcing note: The authoritative patent text provided for this analysis (Google Patents legal-events feed) exposes reel/frame numbers and free-format assignment text, but not the recording correspondent (attorney/agent of record). I was unable to retrieve the live USPTO Assignment Center records (assignmentcenter.uspto.gov / assignment.uspto.gov) in this session, and targeted searches for the two reel/frame numbers returned nothing. Where correspondent data is unavailable I say so rather than infer it. No fabricated correspondents appear below.

Inventors

Pattern notes: Single-inventor patent — no multi-inventor departure pattern can arise. There is no evidence in the record of the inventor leaving NEC shortly after filing, and no evidence of a subsequent inventor-side transfer. Nothing anomalous.

Original assignee

Two entities matter here, and the distinction is worth stating precisely:

• Applicant / assignee at filing (2001): NEC Corporation (Tokyo, Japan). The application was filed 2001-08-08 and assigned by the inventor to NEC the same day (Reel 012073/0046).
• Assignee named on the issued patent (2007): Juniper Networks, Inc. (Sunnyvale, CA). NEC assigned the entire interest to Juniper effective 2005-01-17, before the 2007 grant, so Juniper is the assignee of record on the face of the issued patent and remains the current assignee.

NEC Corporation — long-established Japanese ICT/electronics conglomerate (operating company; telecom systems, computing, semiconductors, network equipment). No bankruptcy.

Juniper Networks, Inc. — publicly traded US networking-equipment vendor (routers, switches, security, and network-planning/traffic-engineering software). An operating company that sells products in the relevant market; the patent's subject matter (path computation and link-capacity design for multipoint services) is squarely within Juniper's routing/traffic-engineering domain. No product-embodiment determination is possible from the record, but Juniper is not a licensing-only entity.

Status: Both assignors/assignees are/were operating companies. Juniper still holds the patent; it lapsed in 2019 for non-payment of maintenance fees.

Assignment timeline

Two recorded assignments exist. Neither the origination nor any subsequent link carries an NPE vehicle.

• 2001-07-23 (executed) / recorded 2001-08-08 — Reel 012073/0046

  • Conveyance: Assignment
  • Assignor: Hiroyuki Saito (individual)
  • Assignee: NEC Corporation (Japan)
  • Correspondent: Not exposed in accessible records — Google Patents legal events give the reel/frame and free-format text ("ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:SAITO, HIROYUKI") but omit the recording correspondent; the USPTO Assignment Center page was not retrievable this session, so no correspondent is asserted.
  • Context: Standard inventor-to-employer assignment at filing.

• 2005-01-17 (executed) / recorded 2005-02-15 — Reel 016285/0534

  • Conveyance: Assignment (entire interest)
  • Assignor: NEC Corporation
  • Assignee: Juniper Networks, Inc. (California)
  • Correspondent: Not exposed in accessible records (same limitation as above). No recurrence of a correspondent can therefore be tested.
  • Context: Corporate patent-portfolio transfer — NEC conveying an entire interest in the patent to an operating networking vendor.

No further assignments are recorded after 2005. Juniper (via assignment) is the last recorded owner. The later legal events are not ownership transfers:

• 2008-04-01 — Certificate of Correction (non-ownership)
• 2011-05-13 / 2015-05-13 — Maintenance-fee payments (4-yr, 8-yr)
• 2019-12-16 — Lapse for failure to pay maintenance fees; 2020-01-07 — patent expired

Because assignments do exist (two of them), this is not a "no records, still owned by original assignee" case — but it is also not a chain through any licensing entity.

Timeline diagram

timeline
    title Ownership of US 7295515
    2000 : Priority JP filing by NEC
    2001 : Filed US application
         : Saito assigns to NEC Reel 012073 0046
    2005 : NEC assigns to Juniper Reel 016285 0534
    2007 : Patent granted
    2011 : Maintenance fee paid
    2015 : Maintenance fee paid
    2019 : Lapsed for fee nonpayment

NPE / troll-pattern signals

1. Shell-entity transfer — Not present. The only transfers are (a) inventor → NEC and (b) NEC → Juniper. Neither assignee is an "IP/Holdings/Ventures" entity; both are operating corporations. No single-member LLC, no registered-agent service address appears in Reels 012073/0046 or 016285/0534.

2. Known asserter in the chain — Not present. Neither NEC Corporation nor Juniper Networks matches any public NPE list (Acacia, Marathon, IV, IPNav, Wi-LAN, Mosaid/Conversant, Vringo, Pendrell, Round Rock, etc.). Both are product/service companies.

3. Repeat correspondent across the chain — Unclear (cannot verify). The correspondent of record is not exposed in the sources available to me (see sourcing note). With no correspondent names retrievable for Reel 012073/0046 or Reel 016285/0534, recurrence cannot be tested either way. This should be re-run directly on the USPTO Assignment Center, where the correspondent field is displayed per record.

4. Cascading transfers — Not present. Exactly one post-origination transfer (NEC → Juniper), executed 2005-01-17, with no chained LLCs and no cluster of transfers inside any 24-month window.

5. Pre-litigation transfer — Not present. No infringement suit naming US 7295515 was surfaced. The only transfer (2005) predates grant (2007) by two years and the patent lapsed in 2019, so it cannot be a pre-suit venue/standing maneuver.

6. Bankruptcy fire-sale — Not present. Neither NEC nor Juniper entered Chapter 7/11 proceedings in connection with this patent.

7. Privateering — Not present. The flow is NEC (seller) → Juniper (buyer), i.e., an operating company acquiring from another operating company. There is no evidence NEC is using Juniper to assert against NEC's competitors.

8. Defensive aggregator (anti-NPE) — Not present. The chain terminates at Juniper Networks, an operating vendor — not RPX, AST, LOT, Unified Patents, or OIN. The patent has not been "neutralized" by a defensive aggregator.

Verdict

Operating-company assertion — but read the qualifier carefully.

Justification: The entire recorded chain consists of two ordinary operating-company assignments — Reel 012073/0046 (inventor Saito → NEC, 2001) and Reel 016285/0534 (NEC → Juniper, 2005) — with zero NPE signals (no shell LLC, no known asserter, no cascading/LLC chain, no bankruptcy, no defensive aggregator). The patent resides with Juniper Networks, a networking-hardware vendor whose product market matches the claims. Caveat: the "assertion" element is not evidenced — no lawsuit naming this patent was found, and the patent lapsed 2019-12-16 for non-payment of fees, making future assertion moot. So the accurate characterization is operating-company-owned, non-asserting, which sits closest to the "Operating-company assertion" category given the closed option set. This is not an NPE chain.

Verification links:

• USPTO Assignment Center (search by patent number 7295515): https://assignmentcenter.uspto.gov/
• USPTO Patent Assignment Search (legacy index): https://assignment.uspto.gov/patent/index.html
• Patent full text / legal events: https://patents.google.com/patent/US7295515/en

Open item to close: confirm the correspondent-of-record fields for Reels 012073/0046 and 016285/0534 in the live Assignment Center. Given both parties are known operating companies, this is expected to be routine outside counsel rather than any repeat NPE filer — but it should be checked, not assumed.

I'll research the prior-art references cited on the face of US 7,295,515. Let me run targeted searches on the most substantive cited references.

I have strong data on the key references. Let me verify the two constraint-based routing references and the Japanese NEC references.

Prior-Art Analysis — US 7,295,515 B2 ("Communication network design")

Scope note. This analysis uses the authoritative citation list appearing on the face of US 7,295,515 (Google Patents rendering, fetched 2026-09-29), which lists 13 U.S./foreign patent citations and 2 non-patent citations. Dates below are taken from that record and from corroborating database hits. Where I hit my tool-call limit before completing a dedicated reference-specific search (notably JP 2001-036574 A, US 6,519,693, US 5,440,687, US 4,669,113, US 6,205,117, and US 2004/0085962 A1), I say so and rely on the title/citation record rather than guessing at content.

Threshold date. Pre-AIA framework applies (priority 2000-08-09; filed 2001-08-08). Relevant §102 categories: §102(b) art (printed/published >1 yr before 2001-08-08, i.e., before 2000-08-08), §102(a) (published/known before the invention), and §102(e) (US patents/applications entitled to a filing date before the invention — effective as of their filing date).

The 13 patent citations

Reference-by-reference analysis

1. US 4,669,113 A — AT&T — Integrated network controller for a dynamic nonhierarchical routing switching network

• Dates: filed 1985-04-26; issued 1987-05-26 → §102(b) art.
• Description: A controller for dynamic nonhierarchical routing (DNHR). It computes/adapts call routing across a switching network but does not frame network design as a mathematical-programming problem and does not treat aggregate ingress/egress "multiple-point" flows.
• Claims potentially affected: None as anticipation. At most general background for "identifying a path." No §102 anticipation of claims 1, 3, or 5.

2. US 6,519,693 B1 — Delta Beta Pty Ltd — Program transmission optimization using a redundant transmission sequence

• Dates: 1989-08-23 priority; issued 2003-02-11 (long pendency) → §102(b) art as to priority.
• Description: Optimizes delivery of program/AV content using a redundant transmission sequence — a broadcast/streaming optimization, not packet-network path design or link-band computation. Based on title/citation record; I could not complete a content-specific search.
• Claims potentially affected: None. No §102 anticipation.

3. US 5,440,687 A — IBM — Protocol for handling arbitrarily varying data strides

• Dates: filed 1993-01-29; issued 1995-08-08 → §102(b) art.
• Description: A communication protocol for managing variable data strides in a distributed-processing environment. Unrelated to network topology/path optimization.
• Claims potentially affected: None. No §102 anticipation.

4. US 6,141,318 A — NEC — Network design method (material)

• Dates: filed 1997-01-17; issued 2000-10-31 → §102(e) art as of 1997-01-17.
• Description: Solves a mathematical programming (integer programming) problem for network design. Its claim 1 recites a first constraint under which a total of the path/standby indicators for each demand pair equals 1, and a second constraint under which the total capacity assigned to a link does not exceed the link's capacity; the objective function minimizes cost caused by link capacity. Combination candidates are formed from a working path and standby paths.
• Claim mapping (inventive overlap):
  • The objective function minimizing a link-cost/load quantity and a link-capacity "not-to-exceed" constraint map loosely to claim 1 elements (a) and (e) (objective function; fourth constraint).
  • The "sum of indicators = 1" constraint maps loosely to claim 1 element (c) (route-selection constraint; the patent's eq. (3) Σ f = 1).
• Gap: It is a protection/standby-path design using per-demand capacities, and discloses no aggregate multiple-point (hose) ingress/egress traffic model, no per-ingress "necessary link band" constraint of the kind in the patent's eq. (5), and no "operate in parallel" limitation.
• Conclusion: Not a full §102 anticipator of claims 1/3/5 (missing the parallel-operation and multiple-point limitations). Strong §103 reference, especially combined with #6/#12.

5. US 6,205,117 B1 — Lucent — Distributed precomputation of network signal paths with table-based link capacity control

• Dates: filed 1997-10-29; issued 2001-03-20 → §102(e) art as of 1997-10-29.
• Description: Distributed precomputation of restoration/working signal paths with table-based link-capacity control. Deals with path precomputation and capacity bookkeeping, not a link-load-minimizing design optimization over aggregate flows.
• Claims potentially affected: Peripheral relevance to "selecting a route" and "link capacity." No §102 anticipation.

6. US 6,404,744 B1 — NEC — Method for designing a communication network (closest architecture)

• Dates: filed 1999-01-22; issued 2002-06-11 → §102(e) art as of 1999-01-22. Same inventor (Hiroyuki Saito) and same original assignee (NEC) as US 7,295,515.
• Description: Inputs network data (topology, demands with stochastic requested capacity, path candidates, cost coefficients); generates an objective function representing total node/link cost; generates a set of constraints; converts a stochastic programming problem into an equivalent determinate programming problem; and solves it. Its disclosed architecture uses an "optimization reference generator 101," a "stochastic path accommodation constraint generator 102," a "link accommodation constraint generator 103," a "stochastic node constraint generator 104," an "equivalent determinate programming problem transformer 105," and an "optimization section 106." The constraint family includes a path accommodation constraint (Σ capacities ≥ demand), a link accommodation constraint (Σ path capacities ≤ link capacity), and a node accommodation constraint.
• Claim mapping:
  • "Optimization reference generator 101" ≈ the patent's optimization reference generating means 11 (objective function + constraint).
  • The several constraint generators ≈ the patent's route selecting / link capacity calculating / link including generators (12/13/14).
  • "Optimization section 106" ≈ the patent's optimizing means 15.
  • The link-accommodation constraint (Σ ≤ link capacity λ·d_l) maps to claim 1 element (e).
• Gap: It is a stochastic, per-demand point-to-point design (capacity per requested demand), not the patent's aggregate multiple-point service where only total ingress inflow v_ad and egress outflow v_zd are supplied. It does not disclose the "operate in parallel" limitation, and it does not disclose the patent's eq. (5) per-ingress necessary-link-band formulation.
• Conclusion: This is the most structurally parallel reference and a formidable §103 reference (near-miss for §102). Same-inventor/assignee relationship should be considered under pre-AIA §103(c) common-ownership principles if combined with other NEC references (#7). Does not by itself anticipate claims 1/3/5 because of the parallel-operation and multiple-point gaps.

7. JP 2000-022750 A — NEC — Communication network design circuit and method, and machine-readable recording medium recording program

• Dates: filed 1998-06-30; published 2000-01-21 → §102(a) printed publication (published before the 2000-08-09 priority). Same assignee (NEC).
• Description: The Japanese counterpart to the Saito NEC network-design work (matching the "design circuit + method + recording medium" framing of US 6,404,744 / the 7,295,515 family). Discloses a design circuit that sets an optimization problem and solves it. Content description based on citation record + family relationship; dedicated search not completed.
• Claims potentially affected: Same functional overlap as #6 (objective function + constraint generators + solver). Counts as prior art as a printed publication.
• Conclusion: Relevant §102(a)/§103 reference; like #6, it lacks the multiple-point aggregate model and the "parallel operation" limitation.

8. US 6,795,399 B1 — Lucent — Link capacity computation methods…designing IP networks with performance guarantees

• Dates: filed 1998-11-24; issued 2004-09-21 → §102(e) art as of 1998-11-24.
• Description: Computes link capacity requirements for IP networks supporting VPN bandwidth guarantees; uses optimization (mixed-integer programming in the router-placement aspect) and topology optimization. Focus is on how much capacity a link needs given point-to-point demands and congestion assumptions.
• Claim mapping: Overlaps well with claim 1 element (d) (link-band calculation) and (e) (capacity limit), and marginally with (a) (cost/load optimization).
• Gap: Per-flow/per-demand point-to-point VPN demand model; no aggregate multiple-point (hose) design; no parallel-generator architecture.
• Conclusion: Solid §103 reference for the link-capacity-generation elements; not a §102 anticipator of the independent claims.

9. US 2004/0085962 A1 — Hitachi — Network relaying apparatus and method capable of high-speed routing and packet transfer

• Dates: priority 1999-02-24; published 2004-05-06. Potential §102(e) art only as to its effective U.S. filing date (which post-dates 2000-08-09 on the record shown — timing needs verification against its actual U.S. filing).
• Description: Hardware/firmware for high-speed packet forwarding in a relay apparatus — routing-implementation, not network-design optimization.
• Claims potentially affected: None. No §102 anticipation.

10. JP 2001-036574 A — NEC — Design circuit for communication path having tree structure…

• Dates: filed 1999-07-15; published 2001-02-09.
• ⚠️ Timing flag: On the face of the record, this publication date (2001-02-09) is after the 2000-08-09 priority date of US 7,295,515. As a foreign printed publication it would not qualify as §102(a) or §102(b) prior art to the '515 patent unless the '515 invention date is later than 2001-02-09. It is nonetheless a same-assignee (NEC) reference bearing on the tree/hose-style communication-path design line of work.
• Claims potentially affected: Conceptually relevant to multiple-ingress tree design (background to the "multiple-point" concept). Not prior art on the stated dates; no §102 anticipation.

11. US 6,538,991 B1 — Lucent (Kodialam & Lakshman) — Constraint-based routing between ingress-egress points in a packet network

• Dates: filed 1999-08-03; issued 2003-03-25 → §102(e) art as of 1999-08-03.
• Description: Determines paths for requested LSPs through a packet network between ingress-egress point pairs with guaranteed service levels (MPLS/RSVP), using constraint-based routing and residual-bandwidth tests; a related sibling is US 6,584,071 (linear-programming/maxflow routing with service-level guarantees). Emphasis is online routing of a requested LSP, not offline design of an aggregate multiple-point service.
• Claim mapping: Uses constraints and selects a route between ingress and egress points, touching claim 1 elements (b)/(c)/(e). The related maxflow/LP sibling has a mathematical-programming flavor.
• Gap: Online, per-request LSP routing; no aggregate hose design; no link-load-minimizing objective for a full multiple-point service; no parallel generators.
• Conclusion: Useful §103 reference for the "constraint-based route selection between ingress-egress points" concept; not a §102 anticipator.

12. US 6,721,270 B1 — Lucent (Mitra & Ramakrishnan) — Multicommodity flow method for designing traffic distribution on a multiple-service packetized network

• Dates: filed 1999-08-09; issued 2004-04-13 → §102(e) art as of 1999-08-09. (Note: the same 1999-08-09 date that is the '515 priority date; as §102(e) art it predates the 2001-08-08 filing and is entitled to its 1999-08-09 filing date.)
• Description: Solves Multicommodity Flow (MCF) linear-programming problems to allocate bandwidth among routes and to optimize figures of merit; identifies a "residual network" of unallocated link capacity; includes constraints that flow on a link not exceed link capacity and flow non-negativity/route-set constraints. This is the body of theory most nearly identical to the optimization technique the '515 patent applies.
• Claim mapping: Directly relevant to claim 1 elements (a), (b), (d), (e) — objective function/figure of merit, link-capacity constraint, and a link-based MCF whose link variables can be interpreted as link-band contributions.
• Gap: Uses demand matrices (point-to-point demands T_sσ), not the aggregate ingress/egress "multiple-point" model; solves a revenue/resource-usage objective rather than specifically "minimize link load φ"; no parallel constraint-generator architecture.
• Conclusion: Excellent §103 reference on the mathematical-programming core; a practitioner would combine it with #6/#4/#7 to reach the '515 claims. Not a standalone §102 anticipator.

13. US 6,363,319 B1 — Nortel — Constraint-based route selection using biased cost

• Dates: filed 1999-08-31; issued 2002-03-26 → §102(e) art as of 1999-08-31.
• Description: Selects routes subject to constraints using biased link costs. Concerns route selection, not offline aggregate network design or per-user link-band computation.
• Claims potentially affected: Only the "route selection" notion of claim 1 element (c). No §102 anticipation.

Non-patent citations (2)

NPL-1. "Dynamic Bandwidth-Allocation and Path-Restoration in SONET Self-Healing Networks"

• Description: SONET self-healing-network bandwidth allocation/restoration. §102(b) printed publication.
• Relevance: Background on capacity allocation/restoration; no multiple-point aggregate design. No §102 anticipation.

NPL-2. IEEE INFOCOM '97, Yijun Xiong & Lorne Mason, "Restoration Strategies and Spare Capacity Requirements in Self-Healing ATM Networks," pp. 353-360, Apr. 7-11, 1997, Kobe, Japan

• Description: This is the reference the '515 patent's Background cites as the admitted conventional design method — designing paths between single nodes, determining a communication amount per node pair, and setting a fixed-band path between each pair (illustrated by the patent's FIG. 4).
• Relevance to claims: This is the admitted prior art against which the '515 invention is defined. It maps to the preamble of claims 1/3/5 (path identification between node pairs) but by the patent's own admission fails the "multiple point / arbitrary communication within a range" requirement (see patent's own statement: "it become not possible to design a service in a mode permitting arbitrary communication within a given range"). No §102 anticipation; it is the §103 starting point the patent distinguishes.

Overall conclusions on §102 vs. §103

1. None of the 15 cited references is a clean §102 anticipator of independent claims 1, 3, or 5. Every reference lacks at least one of the two distinguishing limitations that the granted claims added over the cited art:

   • (i) the aggregate "multiple point" traffic model — design driven only by total ingress inflow (v_ad) and total egress outflow (v_zd) rather than a point-to-point demand matrix; and/or
   • (ii) the "configured to operate in parallel" limitation on the four setting/generating means/steps (claims 1, 3, 5), which mirrors the specification's statement that the mathematical-programming problem "is set in parallel."

2. Strongest §103 references (individually or in combination):

   • US 6,404,744 B1 (#6) and JP 2000-022750 A (#7) — same inventor/assignee, disclosing the objective-function-plus-constraint-generator-plus-solver architecture (near-identical to the '515 block diagram) and link-capacity constraints.
   • US 6,721,270 B1 (#12) — multicommodity-flow LP/optimization core.
   • US 6,141,318 A (#4) — integer-programming network design with an "indicator sum = 1" route constraint and a link-capacity constraint.
   • US 6,795,399 B1 (#8) and US 6,538,991 B1 (#11) — link-capacity computation and constraint-based ingress-egress routing.
   • NPL-2 (Xiong & Mason, INFOCOM '97) — admitted prior art establishing the per-node-pair fixed-band design.

3. References with essentially no bearing on the '515 claims: US 4,669,113 (#1), US 6,519,693 (#2), US 5,440,687 (#3), US 2004/0085962 (#9).

4. Claim-level anticipation bottom line: If forced to name which claim elements each reference alone could meet:

   • Claim 1 element (c) (route-selection constraint) — approached by #4 (indicator-sum = 1) and #11.
   • Claim 1 elements (a)/(e) (objective function; capacity-limit constraint) — approached by #4, #6, #8, #12.
   • Claim 1 element (d) (link-band from ingress traffic) — approached by #8, #12, and the '744/#7 link-accommodation family.
   • Claim 1 element (f) (operate in parallel) — not disclosed by any cited reference.
   • Claim 1 element (g) (identify path from objective + constraints) — approached by #6/#7/#12.
     Because no single reference supplies all elements, the references are properly §103 combinations, not §102 anticipators.

Flags and caveats

• Timing anomaly (must verify): JP 2001-036574 A (#10) has a publication date (2001-02-09) after the '515 priority date (2000-08-09). On the listed dates it is not §102 prior art to '515. Treat the citation as background/same-assignee context, not as anticipatory art, unless the '515 invention date is later than 2001-02-09.
• §102(e) vs. §102(a)/(b) characterization for the U.S. patents issued 2002–2004 but filed in 1997–1999 (#4, #5, #6, #8, #11, #12, #13) depends on their effective U.S. filing dates; I have used the filing dates shown. Verify against the actual U.S. application filing dates (some are continuations of earlier applications).
• Same-inventor/common-ownership: #6 (US 6,404,744) and #7 (JP 2000-022750) share inventor Hiroyuki Saito and assignee NEC with US 7,295,515 (which later assigned to Juniper). Consider pre-AIA §103(c) common-ownership effects if these are combined in an obviousness ground against the '515 family.
• Incomplete primary verification: I completed content-level searches for #4, #6, #8, #11, #12 and for the NPL-2 reference, but reached my tool-call limit before running dedicated content searches for #1, #2, #3, #5, #9, #10, and NPL-1. Their descriptions above rest on the citation record and standard knowledge of the titles; I have marked where this is the case and did not fabricate specifics.
• This is a technical prior-art mapping, not a legal opinion. Anticipation requires that a single reference disclose every claim limitation "arranged as in the claim"; nothing above should be read as a conclusion of invalidity. For a court/PTAB-grade determination, the full claim charts and the actual U.S. filing dates for the cited patents should be pulled from USPTO Patent Center / PAIR.

I'll ground my obviousness analysis by pulling details on the key cited references.

Let me ground the two remaining high-relevance references.

Obviousness Analysis — US 7,295,515 B2 under 35 U.S.C. § 103

Patent: US 7,295,515 B2, Communication network design (Saito; NEC → Juniper)
Priority date: 2000-08-09 (JP 240546/2000); filed 2001-08-08; granted 2007-11-13; expired for fee non-payment (effective 2019-11-13).
Claim set analyzed: 6 claims; independents 1 (system, "means for"), 3 (method), 5 (system, named-generator). Dependents 2/4/6.

Note on posture: Earlier sections of this analysis found no litigation, IPR/PGR, or CAFC activity involving '515. Obviousness therefore has no live validity contest attached — this is a retrospective/analytical § 103 assessment built, per your instruction, on the Prior Art section of the patent page (the 13 examiner-cited patent documents and 2 non-patent citations). I do not re-state the bibliographic/claim-summary sections already produced; I build on them.

1. Legal framework

Under Graham v. John Deere Co., 383 U.S. 1 (1966), and KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007), the inquiry is: (a) scope and content of the prior art; (b) differences between the prior art and the claims; (c) level of ordinary skill; and (d) objective indicia. A claim is obvious where "the improvement is [no] more than the predictable use of prior art elements according to their established functions." KSR, 550 U.S. at 417. A motivation to combine may come from the references themselves, the nature of the problem, or "common sense." Id. at 418–21.

Antecedent-date screen (critical, and easy to overlook). All of '515's independent claims carry the 2000-08-09 priority date. I screened each cited reference for whether it is available as § 103 art as of that date:

⚠️ US 6,404,744 caveat — this is the most important screening issue. The search results confirm US 6,404,744 (granted 2002-06-11, filed 1999-01-22) names Hiroyuki Saito — the same inventor as '515 — and is assigned to NEC Corporation, the same original assignee. Under pre-AIA § 103(c) (and § 102(e)'s "by another" requirement), a U.S. patent that qualifies as prior art only under § 102(e), and that was commonly owned at the time the invention was made, is disqualified for § 103. Because '515 is a post-2000-08-09 priority case, the examining corps applied pre-AIA § 102/103. Accordingly, US 6,404,744 is a weak/contested § 103 reference against '515 unless it also qualifies under § 102(a)/(b) (e.g., via its own pre-grant publication or its Japanese counterpart). This is precisely the kind of art that was likely cited but could not carry a rejection. I flag it rather than relying on it.

By contrast, JP 2000-022750 A (NEC, published 2000-01-21) is a published foreign application — § 102(a)/(b) art whose date pre-dates the priority date, not subject to the § 103(c) common-ownership disqualification (which reaches only § 102(e)/(f)/(g) art). I could not retrieve its full text (I exhausted my tool calls), but its title ("Communication network design circuit and method, and machine-readable recording medium recording program"), assignee (NEC), and subject matter make it, on the record available, a highly material primary reference. ⚠️ I flag that I did not independently verify its disclosure.

2. Level of ordinary skill

A POSITA here is a person with a bachelor's (or higher) degree in electrical engineering, computer science, or operations research, and 2–4 years' experience in network traffic engineering and optimization/linear programming — or equivalent. By the 2000 priority date, the field routinely applied linear-programming / multicommodity-flow (MCF) formulations to network dimensioning and routing. The '515 specification itself concedes this: it characterizes the Xiong & Mason INFOCOM '97 paper — which "formulated [the capacity and flow assignment problem] as a linear programming problem ... solved using standard methods" — as the conventional design method. The specification's own equations (1)–(13) are standard LP/MIP constructions.

3. Construing the key claim limitations

• "objective function for minimizing a link load in the network" (claim 1). In light of the specification, φ is the maximum per-link ratio of carried traffic to given capacity (eq. 2), i.e., the utilization of the most-loaded link. Minimizing that is a textbook min-max congestion objective.
• "first constraint expression for deriving the link load" — eq. (2): φ ≥ (Σₐ w)/c_given.
• "second constraint expression for selecting a route for data traffic received by the ingress nodes" — eq. (3): Σ f = 1 over candidate paths per ingress–egress pair.
• "third constraint expression for calculating a link band for the links based on the data traffic received by the ingress nodes" — eq. (5): w = min{v_in, Σ v_out·g·f}.
• "fourth constraint expression to assure that a link capacity limit ... is not exceeded" — eq. (6): Σ w ≤ c_given.
• "configured to operate in parallel" / "are performed in parallel" — the four generators produce independent constraint sets concurrently.
• Claims 2/4/6 — "input data rates ... associated with the ingress nodes and output data rates ... associated with the egress nodes, the multiple point communication service permitting an arbitrary data rate within a range based on the input data rates and the output data rates." This is the hose-model / aggregate-demand limitation: the service is dimensioned from aggregate ingress and egress volumes, not from a fixed pairwise traffic matrix.

4. Reference-by-reference mapping to the claim elements

5. Grounds of rejection

Ground 1 (primary) — Claims 1, 3, 5 obvious over US 6,721,270 in view of US 6,538,991

US 6,721,270 teaches a method for allocating bandwidth to routes through a packetized network of nodes interconnected by links, by solving linear-programming multicommodity-flow problems with (i) an objective function optimizing a figure of merit, (ii) a route-set demand constraint, and (iii) a link-capacity constraint — and expressly suggests the minimize-most-utilized-link objective that is claim 1's "minimize a link load." It further teaches route-based vs. link-based formulations and a flow-decomposition step to recover routes from link flows (i.e., "identifying a path").

US 6,538,991 supplies what '270 does not emphasize: the network framed as ingress points and egress points connected by links in a backbone, with a centralized system that computes and installs the provisioned path — i.e., the "multiple point ... network that includes a plurality of ingress nodes and a plurality of egress nodes," and the path-identification end product.

Together these teach every element of claim 1 (and its method counterpart claim 3, and the generator-form claim 5), except the "operate in parallel" limitation (see §7).

Ground 2 — Claims 1, 3, 5 obvious over US 6,404,744 / JP 2000-022750 A in view of US 6,721,270 and US 6,795,399

If JP 2000-022750 A is confirmed to disclose the same constraint-generator architecture as its apparent U.S. sibling US 6,404,744, then this is the strongest single-reference-plus-secondary case: the JP publication teaches generating an objective function and multiple named constraint generators (path / link / node accommodation) and solving the resulting mathematical programming problem to design the network. US 6,721,270 fills in the link-load objective and route-selection constraint; US 6,795,399 fills in "calculating a link band for the links ... based on ... traffic." ⚠️ Because I could not retrieve JP 2000-022750 A's text, I present Ground 2 as a candidate ground requiring verification; I do not rest the analysis on it.

Ground 3 — Claims 2/4/6 (aggregate ingress/egress "range") obvious over any of the above in view of US 6,721,270 and Xiong & Mason

Xiong & Mason and US 6,404,744 both model the demand as a random variable following a probability distribution (a range, not a point value), and US 6,721,270's demand matrix T_{s,σ} is expressly built from "traffic measurements or predictive models." A POSITA seeking the simplification of provisioning to aggregate ingress/egress volumes would naturally: (a) take the aggregate inflow Σv_in at each ingress and outflow Σv_out at each egress; and (b) bound each link by the downstream egress total, which is a direct application of the flow-conservation/node-balance constraint already present in US 6,721,270 (constraint (ii): flow entering a node equals flow leaving, differing by ±total flow). This is the "necessary link capacity" insight '515 touts in its (n4,n5) worked example (3 Mb/s of inflow provisioned at only 1 Mb/s because n5 drains 1 Mb/s).

⚠️ This is the weakest link in the obviousness case — see §8.

6. Motivation to combine

1. Same field, same problem, same solution technique. All references are in network traffic engineering / capacity planning; each uses linear programming or MCF to route/dimension a packet network. KSR holds that where references "address the same problem" a POSITA has reason to combine. The art does not merely share a field; it shares the equation structure (objective + demand constraint + capacity constraint).

2. Express "alternate objective" teaching. US 6,721,270 itself points to "minimize the usage of the most heavily utilized link" — the exact claim-1 objective — removing any need to speculate about why one would adopt it.

3. Terminological convergence. US 6,538,991 uses "ingress point"/"egress point"; US 6,404,744 uses "constraint generator ... optimization reference generator ... optimization section." These are the very labels in '515's claims — evidence the field had already crystallized the claimed architecture.

4. Known need for computational speed. US 6,721,270 explicitly desires "on-line solutions ... responsive to actual conditions as they occur," noting LP complexity concerns. This motivates both (a) efficient solver formulations and (b) parallelizing constraint generation.

5. Predictable results. Combining an MCF/LP optimizer with ingress-egress path provisioning yields nothing more than the expected result — an optimized path set and link capacities — i.e., "predictable use of prior art elements according to their established functions."

7. The "operate in parallel" limitation

This is the distinctive added limitation in the granted claims and the element the examiner most likely relied on to allow the case. Under KSR, it does not save the claims:

• Parallel execution of independent computations is one of the most familiar techniques in computing. The four generators each consume the same inputs and emit a disjoint constraint set — there is no data dependency between them. Distributing independent sub-problems across multiple processors is a "predictable variation[]" and a "design incentive[]" of the ordinary artisan. KSR, 550 U.S. at 417, 421.
• The references motivate it: US 6,721,270's express concern with computational complexity and on-line speed supplies the "known problem" (runtime) that parallelism addresses — the very template the Federal Circuit/Board applies (compare the EPO Board's reasoning in T 1303/07 that adding a known criterion to a selection process, solving a known problem, lacks inventive step).
• The limitation is result-neutral. The assembled mathematical-programming problem — and therefore the path output — is identical whether the constraints are generated serially or concurrently. Absent an unexpected technical effect (there is none disclosed), parallel execution imparts no patentable weight.
• ⚠️ Internal-consistency flag: the '515 specification states the problem "is set in parallel" (in the passage describing optimizing means 15), yet FIG. 2 depicts a strictly sequential flow (steps S 1→S 7). This tension both (i) weakens the written-description support for "in parallel," and (ii) confirms the limitation is an implementation detail rather than a technical contribution.

Conclusion on this element: obvious as a predictable implementation choice; independently, of questionable patentable significance.

8. Counterarguments a patent owner would raise (and my assessment)

1. "Only aggregate ingress/egress volumes are provided" (the hose model). This is the strongest non-obviousness argument, and it is aimed at claims 2/4/6. Assessment: it could rebut Ground 3; the cited art's demands are largely pairwise (US 6,721,270 uses an N×N demand matrix T_{s,σ}; US 6,404,744 uses demand p between two nodes). If the owner pinned the claims to the pure hose model (dimensioning from Σv_in/Σv_out with no pairwise matrix), the §§ 4–5 mapping to claims 2/4/6 weakens considerably. ⚠️ I could not locate a cited reference that expressly teaches the hose/aggregate formulation, so I flag this as the genuine non-obviousness stronghold.

2. § 103(c) disqualification of US 6,404,744. Assessment: sound for that reference (same inventor/assignee, § 102(e)-only art). This is why Ground 2 depends on the JP publication for its antecedent-date footing.

3. Non-analogous art / different purpose for US 6,672,270's "minimize most-utilized link." Assessment: weak. That statement is within a network-design patent in the same field and is offered as an "alternate approach" — squarely analogous.

4. Teaching away. Assessment: none found. No cited reference disparages LP/MCF network design, aggregate demands, or parallel constraint generation.

9. Secondary considerations

No objective indicia are available on this record: no litigation or IPR/PGR (prior sections), no nexus evidence, and the patent lapsed in 2019 for non-payment of maintenance fees (Google Patents Legal Events: LAPS 2019-12-16, effective 2019-11-13). There is therefore nothing on the record to rebut a KSR-based obviousness case.

10. Bottom line

• Claims 1, 3, and 5 are, in my assessment, likely obvious over US 6,721,270 in view of US 6,538,991 (and/or US 6,795,399), the "operate in parallel" limitation being an obvious, result-neutral implementation choice motivated by the art's own runtime concerns.
• Claims 5 and 6's generator architecture is closely matched by US 6,404,744 — but that reference is disqualified or weak for § 103 owing to common inventorship/ownership, so this ground is stronger if JP 2000-022750 A is confirmed to disclose the analogous architecture.
• Claims 2, 4, 6 (the aggregate ingress/egress "range" limitation) present the hardest obviousness question; the cited art is predominantly pairwise-demand, so a rejection here would rest on (i) the art's own use of probabilistic/range demands (US 6,404,744; Xiong & Mason), (ii) US 6,721,270's demand-from-model teaching, and (iii) flow-conservation as the source of the downstream-egress bound.

Explicit uncertainty flags

1. JP 2000-022750 A — I could not retrieve its text; the Ground-2 mapping is an inference from title/assignee and the apparent US sibling. Verify before relying on it.
2. US 6,404,744 — I did not verify the § 102(a)/(b) publication date of any pre-grant publication or JP counterpart that would cure the § 103(c) issue; the disqualification analysis is legal, not confirmed from the file wrapper.
3. US 6,144,318 A, US 4,669,113 A, US 6,205,117 B1, US 6,363,319 B1, US 5,440,687 A, US 6,519,693 B1 — listed as cited art but not retrieved/verified in this pass; I did not rely on them for any ground.
4. Claim text is the granted, post-certificate-of-correction version (correction dated 2008-04-01); the 2008 certificate's specific change was not retrieved.
5. This is a technical validity assessment, not a legal opinion, and the patent is expired, so any § 103 conclusion is analytical only.