US 6178160

I'll search for authoritative information on this patent number, including any litigation or CAFC activity.

Let me run a couple more targeted searches on the patent and any associated litigation.

Search results summary

I searched for the specific identifier 6178160 (US6178160B1). The authoritative patent text supplied in the prompt matches what the live searches returned (Google Patents, uspto.report, FreePatentsOnline-family listings). Below is the summary, with a note on what I could not verify.

Note on the CAFC/docket portion of your request

I ran targeted searches for 6178160 with "CAFC 2026 docket" and with "litigation." I found no CAFC 2026 docket entry, PTAB proceeding, or district-court litigation involving US6178160. I do not have authoritative information showing this patent has ever been litigated, and I am not able to confirm a negative from general web search alone. Treat the litigation-status item as unverified, not as "no litigation exists." (For context, the searches did surface an unrelated load-balancing case — Cisco's 2014 IPR against C‑Cation Technologies over U.S. 5,563,883 — which is a different patent and should not be confused with this one.)

Discrepancy flag (per your "interpret literally" rule)

One third-party aggregator page (unifiedpatents.com) lists US6178160's priority date as 1997‑12‑22. Google Patents, uspto.report, and the supplied authoritative text all give the application filing/priority date as 1997‑12‑23. I report both, and treat 1997‑12‑23 as the authoritative figure.

Bibliographic data for US 6,178,160 B1

Abstract (as issued): "A plurality of web servers (16, 18, and 20) have a common host name, and their authoritative domain server (24 or 26) responds to requests from a local domain-name server (22) for the network address corresponding to their common host name by making an estimate of the performance costs of adding a further client to each of the web servers and then sending the local domain-name server (22) the network address of the server to which the addition of a further client will result in the least performance cost. The performance cost is defined as the difference in the average number of waiting clients, and it takes into account both the additional response time for existing clients and the projected response time for the prospective new client."

Plain-language overview of the independent claims

There are two independent claims: claim 1 (system) and claim 10 (method). Claims 2–9 depend (directly or indirectly) from claim 1.

Claim 1 — System

A networking system with two cooperating parts:

• (A) Multiple application servers that have different network addresses but all share one common host name (a replicated/clustered web site). Each such server:

  • talks to clients in request/response "transactions";
  • measures the delays between requests and the corresponding responses; and
  • from those measured delays, computes a "performance‑cost estimate" — its estimate of how much adding one more client would increase the average number of clients that are waiting for responses; and
  • transmits that cost estimate over the network.

• (B) A domain‑name server (the authoritative DNS server for the shared name) that:

  • receives those cost estimates from the servers;
  • receives DNS queries for the common host name;
  • chooses among the application servers based on the cost estimates; and
  • answers the DNS query by returning the chosen server's network address.

In short: the servers predict the marginal cost of taking on another client, and the DNS server picks the cheapest one.

Claim 10 — Method

A method for responding to a DNS query for a host name shared by multiple application servers. The steps:

• (A) measure, for each application server, the request‑to‑response delays;
• (B) from those measured delays, determine a performance‑cost estimate for each server — again the estimated increase in the average number of waiting clients caused by adding one more client; and
• (C) choose among the servers based on those cost estimates.

(This is the method counterpart to claim 1; note that the claim as reproduced ends at step C and does not recite an explicit "send the address" step.)

The dependent claims (for context, since they flavor the independent claims)

• Claim 2: the servers estimate cost to existing clients only, and the DNS server adds a projected new‑client latency for each server, then chooses based on the sum.
• Claim 3: servers report transaction rate and average client count; the DNS server computes a total transaction rate, a total average client count, a projected new‑client transaction rate (total rate ÷ total average clients), and projected new‑client latency (that rate × each server's average response time).
• Claims 4–5: cost estimate also depends on number of transactions / transaction‑data volume.
• Claims 6–9: the cost estimate is derived by fitting parameterized models to per‑sample‑period measurements (total latency vs. operational variables), selecting the best‑fitting model, then extrapolating the added latency per unit time from adding a client (claim 6); claim 7 covers the load‑limited model using transaction count and data volume; claim 8 adds a client‑limited model using transaction count, client‑connect time, and data volume; claim 9 covers the model using those three variables.

Uncertainty / confidence notes

• Bibliographic fields, abstract, and claim structure: high confidence — taken directly from the authoritative full‑text you supplied and corroborated by Google Patents and uspto.report.
• Litigation/CAFC status: unverified. I could not find any CAFC 2026 docket, PTAB case, or court proceeding tied to 6178160, and I cannot treat that as proof none exists.
• Priority-date discrepancy (1997‑12‑22 vs. 1997‑12‑23): flagged above; I have not corrected either figure.

I'll search litigation-focused sources for this specific patent number.

Let me run a few more targeted searches to be thorough about any litigation, PTAB, or ITC activity.

Litigation search results for US Patent 6,178,160

Bottom line: I found no litigation — no district-court case, no CAFC appeal, no PTAB proceeding (IPR/PGR/CBM), and no ITC Section 337 action — involving U.S. Patent No. 6,178,160.

What I searched

• The exact identifiers 6178160, 6,178,160, and US6178160 combined with litigation terms: "litigation," "lawsuit," "infringement," "defendant," "district court," "CAFC," "PTAB," "inter partes review," and "courtlistener."
• Unified Patents' patent/litigation portal pages (e.g., the portal.unifiedpatents.com/patents/... and .../litigation/... surfaces), PTAB petition documents on ptacts.uspto.gov, and Federal Circuit materials on govinfo.
• The Google Patents page for US6178160 — which, notably, shows a "Cited By" list of ~123 documents but no litigation/PTAB assertion of the '160 patent itself.

None of these returned any case in which US 6,178,160 was asserted, challenged, or otherwise at issue.

Similar-number results I deliberately excluded (per your "do not auto-correct / do not return similar numbers" rule)

The searches surfaced several different patents whose numbers are easily confused with 6,178,160. I am not reporting these as litigation against your patent:

• U.S. 6,778,160 — AU Optronics v. LG Display (D. Del., 2006–2010), LCD panel patents. Different patent.
• U.S. 8,618,160 ("the '160 patent") — Journey Medical Corp. v. Perrigo Pharma International DAC, No. 1:20-cv-01413 (D. Del.). Different patent (an ANDA/pharma case).
• A Florida not-for-profit annual report listing FEI/EIN number "59-6178160" for "Showfolks of Sarasota, Inc." — a coincidental numeric match in an unrelated corporate filing, not a patent matter.

If any of these had been folded into a result set naively, it would have produced a false positive. To be explicit: none of them involve US 6,178,160.

Status conclusion and caveats

• No known litigation involving US 6,178,160. This is consistent with the patent's lifecycle: filed 1997-12-23, issued 2001-01-23, assigned to Cisco Technology, Inc., and now Expired – Lifetime (anticipated expiration 2017-12-23). Cisco was the assignee of the earlier-cited "Cisco Distributed Director" non-patent reference, and the '160 patent is generally cited as prior art by later load-balancing/DNS-selection patents (e.g., it appears in the references of EP 1660961 B1) rather than being asserted in litigation.
• Confidence: I searched the litigation-focused sources you named plus PTAB and Federal Circuit repositories and found nothing. However, I cannot prove the negative. A single web-search pass cannot exhaust every venue (e.g., older state-court filings, unfiled/settled suits, sealed dockets, or pre-2010 cases not well indexed by the portals above). Treat this as "no litigation found in the searched sources," not as an affirmative certification that none exists.
• This is a change/addendum to the earlier-generated section, which flagged litigation status as "unverified." This round of targeted litigation searches reinforces that finding but still does not verify an absolute negative.

Recommended next steps if you need a definitive litigation clearance

1. USPTO Patent Center / Assignment records for Reel/Frame history (to identify any ownership transfers that could signal assertion campaigns).
2. Unified Patents Portal directly (the /litigation/caselist endpoint you cited), plus Docket Navigator or Lex Machina — these index by patent number and would catch district-court and PTAB assertions that general web search misses.
3. PACER docket search across all districts using the patent number, and the CAFC docket via govinfo/CM-ECF.
4. ITC EDIS for any Section 337 complaint naming the patent.

If you can point me at a specific district or date range, or if you want me to pull the Google Patents "Cited By" entries that cite this patent as prior art (which is often where a null-result patent still shows up), I can narrow further — but on the record available, the answer is: no litigation is known for US 6,178,160.

Proceedings overview

Total AIA trial proceedings on file for US 6,178,160: zero. The structured "PTAB proceedings on file" block — the canonical list drawn from the USPTO Open Data Portal (ODP) — returns no inter partes review, post-grant review, or covered business method review naming this patent, and my independent web searches of PTAB decisions, PTAB E2E/PTABCTS petition downloads, and third-party trackers surfaced no petition, institution decision, final written decision, or appeal either. The breakdown by status is therefore trivially: 0 active / 0 claims invalidated / 0 claims sustained / 0 settled / 0 institution-denied. The bottom-line defensive posture this creates is the mirror image of a "hardened by IPR" patent: the claims of the '160 patent have never been tested at the Board. All ten claims (1–10) remain UNTESTED, i.e., unadjudicated by any AIA tribunal. The absence of PTAB activity is not evidence of claim strength; it is overwhelmingly explained by two objective facts — the patent expired on 2017-12-23 (anticipated expiration, per the bibliographic record) and the practising technology (DNS-based global server load balancing) was largely superseded well before the AIA trial regime reached maturity — rather than by any Board finding of validity.

No per-proceeding entries follow, because there are no proceedings to describe. The sections below are structured as requested for completeness, but the honest answer to "surface every AIA trial proceeding" is that the set is empty.

(No proceedings to report)

There is no IPR20XX-XXXXX, PGR20XX-XXXXX, or CBM20XX-XXXXX to enumerate for US 6,178,160 B1. I will not manufacture a docket number to fill this slot; doing so would violate the no-fabrication constraint and could mislead a defendant into researching a case that does not exist.

What I verified and what I could not:

• Verified — The canonical ODP-derived list supplied in this prompt states: "The USPTO ODP API returns no AIA trial proceedings for this patent as of the most recent ingest." That is the authoritative negative.
• Verified — The patent's legal status is Expired – Lifetime, with an anticipated expiration of 2017-12-23. See the Google Patents record at https://patents.google.com/patent/[US6178160B1](/patent/US6178160B1)/en.
• Could not verify (stated as a limitation, not as a positive finding) — General web search cannot prove a universal negative. My searches did not return any PTAB proceeding tied to 6178160, but a proceeding whose decision text does not quote the number verbatim could theoretically evade keyword search. I am not able to rule that out with certainty from search alone; I defer to the ODP structured record as the canonical answer.
• Disambiguation flag (carried over from the prior section) — Searches for Cisco load-balancing PTAB activity surface a different patent: Cisco's 2014 IPR against C-Cation Technologies over U.S. 5,563,883, and Cisco's later IPR campaign against C-Cation over U.S. 7,602,780 / 7,636,360 / 7,657,628. None of these is US 6,178,160. A defendant should not conflate them. Likewise, "6178160" also resolves to an unrelated PubMed/DATE identifier (DOI 10.1126/science.6178160) and to unrelated corporate EINs — noise, not signal.

Strategic summary

Claim-by-claim status. No claim of US 6,178,160 has been canceled, narrowed, or confirmed by the PTAB. In the vocabulary you asked for: CANCELED = none; SUSTAINED = none; UNTESTED = all of claims 1–10. There is no IPR certificate, no CBM final written decision, and no reexamination certificate (inter partes reexamination included) reflected in the record to point a defendant toward. For reference on what is untested, the two independent claims are claim 1 (system: application servers that measure request→response delay and compute a "performance-cost estimate," plus a domain-name server that chooses among them and answers DNS queries with the chosen server's address) and claim 10 (the corresponding method of measuring delays, determining cost estimates, and choosing among servers). Dependent claims 2–9 refine the cost model (existing-clients-only costing plus new-client latency in claims 2–3; transaction-count and data-volume dependence in claims 4–5; best-fit parameterized models in claims 6–9).

Estoppel landscape. Because there are no petitioners, there is no § 315(e)(2) estoppel against anyone. No party is barred from raising any § 102/§ 103 ground, and no petitioner-privity chain exists to constrain a current defendant. The corollary is that a current defendant also gains no free invalidity judgment to import into district court — there is no FWD to hand the judge and no canceled claim to argue is "dead." A defendant's invalidity case must be built from scratch on prior art, and the practical ceiling is that any IPR now would face steep discretionary-denial headwinds under the Office's settled-expectations/workload-management line of decisions (see, e.g., Dabico Airport Solutions Inc. v. AXA Power ApS, IPR2025-00408, Paper 21; Google v. Sandpiper CDN briefing referencing the March 24, 2025 Fintiv guidance), because the '160 patent has been expired since 2017-12-23 and has been in force for roughly two-and-a-half decades. Note also that the CBM window closed: CBM review was sunset for petitions filed after 2020-09-16, so CBM is no longer an available vehicle regardless of the patent's subject-matter eligibility. Any surviving avenue would be a PGR (unavailable — more than nine months past issuance) or an IPR on § 102/§ 103 grounds, which for an expired patent can still be filed but is very unlikely to be instituted today.

Pattern signals. There is no pattern to observe: no repeat petitioner, no serial petitioning, no joinder, no patent-owner PTAB appeal practice, and no defensive aggregator (e.g., Unified Patents) in the chain for this patent. The publication history the prior sections flagged — 123+ documents citing the '160 patent and a large "cited-by" family — is forward citation activity (later patents building on or citing it), not litigation or challenge activity. The only litigation-adjacent signal found in any search was the unrelated Cisco/C-Cation matter, which does not touch this patent number.

Recommended next steps

• If no PTAB activity exists, say so plainly — and that is the case here. There is no IPR, PGR, or CBM on file for US 6,178,160 B1. Do not represent to a court, a client, or an adversary that any claim of this patent has been invalidated at the Board; it has not. Any suggestion that "claims 1–5 have been canceled" would be affirmatively false for this patent.
• Treat the patent's expiration date as the controlling fact. US 6,178,160 expired 2017-12-23 (anticipated expiration; status "Expired – Lifetime"). Before responding to any demand keyed to this patent, confirm (a) the asserted claims, (b) the accused-product dates, and (c) whether the damages window — at most the six years preceding the complaint under § 286 — intersects any period before expiration. Post-expiration damages for pre-expiration infringement remain theoretically available, but for a patent that has been expired since 2017, the practical and equitable exposure is limited.
• If you nevertheless want a PTAB option, budget for a discretionary-denial fight, not a merits fight. A fresh IPR on an expired, decades-old patent will be measured against the Office's settled-expectations and workload-management factors. Any petition should (i) pre-empt the "expired patent / settled expectations" findings head-on, and (ii) acknowledge that CBM is unavailable (post-2020-09-16 sunset) and PGR is time-barred.
• Do not rely on keyword search alone to clear the "no proceedings" point. The ODP/PTAB structured records are the canonical source. For a belt-and-suspenders check, query the PTAB's public trial listing by patent number and the PTAB E2E docket directly:
  • USPTO PTAB E2E / PTAB public trial listings: https://ptab.uspto.gov and https://ptacts.uspto.gov
  • USPTO Patent Center (assignment and prosecution history): https://patentcenter.uspto.gov
  • CourtListener (to confirm no Federal Circuit appeal exists, since an appeal presupposes an underlying Board decision): https://www.courtlistener.com
  • Google Patents record (copending-status anchor): https://patents.google.com/patent/US6178160B1/en
• Flag the litigation-status caveat inherited from the prior section. As the earlier analysis noted, searches for any court proceeding on US 6,178,160 — including the requested CAFC/docket check — came up empty, and a negative cannot be affirmatively proven from search. It is consistent with, but not proof of, the conclusion that this patent was never litigated. If the operating theory of the matter depends on whether the patent was ever asserted, that point should be confirmed through a litigation database (e.g., Docket Navigator, Lex Machina) rather than general search.

Bottom line for a defendant: US 6,178,160 has no PTAB history whatsoever — all of claims 1–10 are untested, there is no estoppel binding anyone, and there is no FWD to leverage. Your leverage over this patent, if any, runs through its 2017-12-23 expiration and the ordinary invalidity/non-infringement defenses in district court, not through any prior Board ruling.

I'll research the assignment record for US 6178160 from authoritative sources.

Let me dig deeper for the specific reel/frame record and any post-issuance transfers.

Assignment / Ownership Analysis — US 6,178,160 B1

Verification status up front. I was unable to retrieve the underlying USPTO Assignment Center records (reel/frame, correspondent of record) for this patent in the available research session. The USPTO Assignment Search endpoints (assignmentcenter.uspto.gov / assignment.uspto.gov / legacy-assignments.uspto.gov) did not surface a patent-specific record for 6,178,160 in the search results I obtained. What I can verify is the bibliographic legal-events record mirrored on Google Patents, which shows exactly one post-filing ownership event. Everything below is built on that and is explicitly flagged where it is an inference rather than a recorded fact. Do not treat the missing reel/frame as evidence that no record exists — it means I could not pull it, not that it isn't there.

Inventors

• The application (US 08/996,683) was filed 1997-12-23; the assignment to Cisco was recorded 1998-04-13 — a normal ~4-month inventor-to-employer conveyance, consistent with standard "hired-to-invent" practice at Cisco. See Google Patents legal events: https://patents.google.com/patent/US6178160/en
• Unusual-pattern check — no anomaly detected. There is no evidence either inventor departed Cisco within 12 months of filing, and there is no portfolio fire-sale signature here. If anything, later search hits suggest the inventors remained in the Cisco orbit (subsequent patent references to "Agrawal et al." and "Bolton" appear in Cisco-family documents), but I could not confirm continuity of employment, so I flag that as unverified context, not a finding.
• Confidence: moderate on employment (inferred from the assignment, not from an employment record I independently retrieved).

Original assignee

• Entity on the issued patent: Cisco Technology, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 — a California corporation, originally the operating/R&D holding entity of Cisco Systems, Inc.
• Primary line of business: data networking — routers, switches, and network-infrastructure software; specifically, this patent sits in Cisco's DNS-based global server load-balancing work (Cisco's "Distributed Director," which is also one of the two non-patent references cited on the face of the patent).
• Did they ship a product embodying the claims? Yes — Cisco is an operating company that commercialized load balancing. The non-patent citation "Cisco Distributed Director," WWW document posted Feb. 21, 1997, is Cisco's own product documentation and is contemporaneous with this filing. Cisco's DNS/global server load-balancing product line (Distributed Director, and later IOS Server Load Balancing) is the commercial embodiment family. (I did not independently verify that the specific claims read on a shipping unit — flag as reasonable but not proven.)
• Current status: Operating. Cisco Technology, Inc. and Cisco Systems, Inc. remain active, publicly traded (NASDAQ: CSCO), and solvent. There is no bankruptcy, dissolution, or acquisition on the assignee side.

Assignment timeline

⚠️ Important limitation: The USPTO Assignment Center returned no patent-specific record I could pull in this session, so I cannot cite reel/frame numbers or the correspondent of record. The timeline below reflects the single ownership event documented in Google Patents' legal-events data. If you need the reel/frame and recording attorney (which, per your brief, is the key NPE tell), that must be pulled directly from https://assignmentcenter.uspto.gov/ with the patent number — I could not fabricate it.

• 1998-04-13 (recorded) / execution date not retrievable — Reel not retrieved / Frame not retrieved
  • Conveyance: Assignment (Assignment of Interest — see note below)
  • Assignor: Rajesh Agrawal; Derek W. Bolton
  • Assignee: Cisco Technology, Inc. (San Jose, CA)
  • Correspondent: not retrieved
  • Context: Inventor-to-employer initial assignment — the standard first link that puts title in the operating company. Not a shell transfer, fire-sale, or transfer-to-asserter.
  • Note on conveyance type: Google Patents labels the event "reassignment" and the assignment docket language ("ASSIGNMENT OF INTEREST (SEE DOCUMENT FOR DETAILS)") is the standard phrasing for an inventor→company conveyance, not a change of name or security interest.

No further recorded assignments were found. I searched for post-issuance transfers, NPE-style conveyances, and any assignment activity after the 1998 record and surfaced none. This is a substantive finding: absent contrary Assignment Center data, it indicates Cisco Technology, Inc. has remained the owner of record from 1998 to expiration (2017-12-23).

Timeline diagram

timeline
    title Ownership of US 6178160
    1997 : Application filed by Cisco inventors
    1998 : Assigned to Cisco Technology Inc
    2001 : Patent issued
    2017 : Patent expired

NPE / troll-pattern signals

Each signal assessed against the record actually available. Where the record is missing, I mark unclear rather than guess.

Verdict

Insufficient data (only the original inventor→employer assignment is of record).

The sole verifiable ownership event for US 6,178,160 is the 1998-04-13 assignment from Agrawal and Bolton to Cisco Technology, Inc.; no post-issuance assignment, NPE-style conveyance, or defensive-aggregator transfer was found, and the patent expired 2017-12-23 with Cisco as the apparent owner of record throughout. Every NPE signal is therefore either not present (the assignee is an operating company that shipped a load-balancing product, per the cited "Cisco Distributed Director" reference) or unclear because I could not retrieve the reel/frame and correspondent of record. This is a clean operating-company chain — but I cannot fully close the file without the USPTO Assignment Center reel/frame entries, which is why the verdict is "insufficient data" rather than "defensive / non-asserting."

Verify directly at: https://assignmentcenter.uspto.gov/ (search patent number 6178160; also mirrored at https://assignment.uspto.gov/patent/index.html). Pull the reel/frame and correspondent for the 1998 record to fully close this analysis.

Confidence / limitations

• High confidence: the 1998 assignment to Cisco Technology, Inc.; inventor identities; original and current assignee; expiry. (Google Patents legal events + supplied authoritative full text.)
• Unverified: any CAFC 2026 docket, PTAB proceeding, or district-court litigation involving this patent — none found, and a negative cannot be established from search alone. (Carried forward from the earlier summary; no new evidence changes it.)
• Not retrieved: USPTO Assignment Center reel/frame and correspondent of record. I did not fabricate these; the Assignment Center endpoints did not return a patent-specific record in this session.
• Consistency check: no contradiction with the previously generated sections. The earlier bibliographic table likewise lists the 1998-04-13 assignment and the same assignee, and the 1997-12-22 vs. 1997-12-23 priority-date flag still stands (1997-12-23 authoritative).

I'll research the cited prior art references for US 6,178,160. Let me run searches on the specific references.

Let me research the remaining cited references and the non-patent literature.

Let me research the two non-patent literature references cited on the face of the patent.

Prior-Art Analysis for US 6,178,160 B1

Patent under analysis: US 6,178,160 B1 — "Load balancing of client connections across a network using server based algorithms," filed/priority 1997‑12‑23, issued 2001‑01‑23, inventors Bolton & Agrawal, assignee Cisco Technology, Inc.

Method note: Because the application was filed in 1997, the pre‑AIA version of 35 U.S.C. § 102 governs. The references that matter for § 102 are therefore those listed on the face of the '160 patent (the examiner‑cited references). I also include the two non‑patent citations, since they are the cited references most relevant to the DNS‑selection architecture. (The ~123‑entry "Cited By" list is a different thing — later patents that cite the '160 patent as background art — and is not prior art against it.)

Bottom line up front

No reference cited on the face of US 6,178,160 is a strict § 102 anticipation of independent claim 1 or claim 10. Each cited reference is missing at least one element of those claims — most importantly, the limitation that the application servers themselves measure request‑response delays and derive a "performance‑cost estimate" representing the projected increase in the average number of waiting clients caused by adding a further client. The cited references are best characterized as background / analogous art and as § 103 obviousness candidates, not § 102 anticipatory art.

Ranking by relevance to the '160 claims:

1. US 5,530,744 A — AT&T Corp. (method and system for dynamic customized call routing)

• Full citation: US 5,530,744 A, Charalambous, Durinovic‑Johri & Levy, "Method and system for dynamic customized call routing," AT&T Corp. (Appl. No. 08/309,361).
• Dates: Filed 1994‑09‑20; issued 1996‑06‑25. Prior‑art date on the '160 face: 1994‑09‑20 / 1996‑06‑25.
• § 102 category: Issued more than one year before the '160 filing date (1996‑06‑25 < 1996‑12‑23), so it is § 102(b) art (patented more than one year before filing).
• Description: A cooperative network/premises automatic‑call‑distributor (ACD) system. A Customer Routing Point (CRP) receives periodic real‑time status from multiple customer sites via a TOPMS (agents available, calls in queue, average handling time, etc.); a Site Status Predictor projects each site's queue size/delay at the time of an incoming call; a Load Balancer then selects the destination ACD that best balances load / minimizes expected delay, on a call‑by‑call basis.
• § 102 analysis vs. claims 1 & 10: Does not anticipate.
  • It is telephony call routing, not DNS resolution of a common host name to network addresses; there is no domain‑name server, no DNS query, no "network address of the chosen application server."
  • It does not compute a performance‑cost estimate as the projected increase in the average number of waiting clients from adding a further client, based on measured request‑response delays at the application servers. Its "status prediction" is a queue/delay forecast, not the '160 cost metric.
  • It is, however, relevant § 103 art for the general concept of a "load balancer" that selects a destination by predicting a site's status/delay — conceptually adjacent to the projected new‑client latency of dependent claims 2–3.

2. US 5,774,660 A — Resonate, Inc. (world‑wide‑web server with delayed resource‑binding …)

• Full citation: US 5,774,660 A, Brendel, Kring, Liu & Marino, "World‑wide‑web server with delayed resource‑binding for resource‑based load balancing on a distributed resource multi‑node network," Resonate, Inc. (Appl. No. 08/691,006).
• Dates: Filed 1996‑08‑05; issued 1998‑06‑30. Prior‑art date on the '160 face: 1996‑08‑05.
• § 102 category: Issued after the '160 filing date, so it is not § 102(a)/(b) by its issue date. It qualifies under § 102(e) as of its US filing date, 1996‑08‑05, which precedes the '160 filing (1997‑12‑23), and it is "by another" (different inventors / assignee). (Pre‑AIA § 102(e); practical effective date = its US filing date.)
• Description: A web‑site server farm addressed by a single virtual IP address. A load balancer receives all client connections at the virtual address, waits for the URL, then selects an assigned server based on the resource requested and on which server is "least busy," and transfers the connection to that server. (This is the patent asserted in Resonate Inc. v. Alteon Websystems, 338 F.3d 1360 (Fed. Cir. 2003).)
• § 102 analysis vs. claims 1 & 10: Does not anticipate.
  • Selection is made by a front‑end load balancer, not by a domain‑name server responding to a DNS query with the selected server's network address. The '160 claims expressly require a domain‑name server that receives DNS queries and returns the chosen server's address.
  • The selection criterion is resource location + "least busy," not a performance‑cost estimate derived from measured request‑response delays that projects the increase in the average number of waiting clients from adding a client.
  • Relevant § 103 art for the general idea of a replicated‑server site performing load‑based server selection.

3. US 5,867,706 A — International Business Machines Corp. (method of load balancing across the processors of a server)

• Full citation: US 5,867,706 A, Martin et al., "Method of load balancing across the processors of a server," International Business Machines Corp. (family includes GB 2 309 558 A / WO 97/29423).
• Dates: Face prior‑art date 1996‑01‑26; issued 1999‑02‑02. (The corresponding US application US 08/770,142 appears to have been filed 1996‑12‑19; the earlier 1996‑01‑26 date is the priority date. Either date precedes the '160 filing.)
• § 102 category: Issued after the '160 filing, so relies on § 102(e) as of its earlier (priority/US‑filing) date, which precedes 1997‑12‑23.
• Description: A parallel server computer whose multiple processors jointly serve web content. Each processor, when constructing a requested file (web page), dynamically substitutes into that file the addresses of the processors that should serve subsequent objects (e.g., images), based on a load distribution record of periodically measured activity data — thereby spreading load and avoiding a processor being "toasted."
• § 102 analysis vs. claims 1 & 10: Does not anticipate.
  • The "load balancing" is among processors inside a single server, not among distinct application servers having different network addresses that share a common host name and are selected by a domain‑name server.
  • There is no DNS query/response, and no performance‑cost estimate based on measured request‑response delays projecting an increase in waiting clients.
  • Background art only; weak § 103 relevance (dynamic, load‑based address selection).

4. US 5,916,017 A — Minnesota Mining & Manufacturing Co. (preformed ophthalmic lens base block)

• Full citation: US 5,916,017 A, "Preformed ophthalmic lens base block," Minnesota Mining & Manufacturing Co. (3M).
• Dates: Filed 1995‑09‑18; issued 1999‑06‑29.
• § 102 category: Issued after the '160 filing → possible § 102(e) as of its 1995 US filing date only.
• Description: Thermoplastic blocking compositions and a preformed base block for holding ophthalmic lenses during surfacing/grinding — an optical‑lens manufacturing patent.
• § 102 analysis vs. claims 1 & 10: Does not anticipate — and cannot, on any claim.
  • It is wholly unrelated to computer networking, DNS, or load balancing. It discloses none of the elements of claim 1 or claim 10 (no application servers, no host name, no DNS, no response‑delay measurement, no performance‑cost estimate).
  • ⚠️ Discrepancy/flag: The presence of this reference on the face of the '160 patent is almost certainly an examiner/data artifact. It is a 3M optical‑lens patent (B24B 13/29 classification) that has no apparent bearing on the '160 subject matter. I am reporting it literally (per the "do not auto‑correct" rule) but it should be treated as non‑prior art for these claims.

5. Non‑Patent Citation — "Cisco Distributed Director" (WWW document, Feb. 21, 1997)

• Full citation: "Cisco Distributed Director," WWW document posted Feb. 21, 1997, pp. 1–16 (as cited on the face of the '160 patent).
• § 102 category: A printed publication dated Feb. 21, 1997 — less than one year before the '160 filing (1997‑12‑23), so at most § 102(a) (and only if it predates the invention date); not § 102(b).
• Description: Cisco's "Distributed Director" is a product (a modified DNS server, running as a software extension of Cisco IOS) that acts as the authoritative DNS server for a configured host/subdomain. On a DNS query, it uses Cisco's Director Response Protocol (DRP) to poll distributed "DRP server agents" in routers, applies metrics (client‑to‑server network distance, server availability/load), and returns the IP address of the "best" server (and, per some configurations, on a weighted/random balancing basis). It is, in effect, DNS‑based global server selection. (Interesting: the '160 patent's assignee is Cisco — this NPL is Cisco's own prior offering.)
• § 102 analysis vs. claims 1 & 10: Does not anticipate.
  • Architecturally it is the closest cited reference to claim 1(B): a DNS server that answers a query for a shared name with one chosen server's address. But the selection metric is network distance / availability / load via DRP agents in routers, not a "performance‑cost estimate" computed from measured request‑response delays at the application servers (the increase in the average number of waiting clients from adding a client). Claim 1(A) also requires the application servers to measure delays and generate the cost estimate — Distributed Director's agents are in routers, not the servers.
  • Strong § 103 candidate (motivation/architecture), not § 102.

6. Non‑Patent Citation — Schemers, "Lbnamed, a Load‑Balancing Name Server Written in Perl" (WWW document, last modified Sep. 17, 1995)

• Full citation: Roland J. Schemers, "Lbnamed, a Load‑Balancing Name Server Written in Perl," WWW document listed as last modified Sep. 17, 1995, pp. 1–5 (as cited on the face of the '160 patent).
• § 102 category: A printed publication dated Sep. 17, 1995 — more than one year before the '160 filing → § 102(b) art (also available under § 102(a)).
• Description: "lbnamed" is a DNS name server (implemented in Perl) that performs load balancing by returning, in answer to a name lookup, one of several equivalent hosts — specifically the least‑loaded server, based on load information the name server collects/queries from the hosts. It is a DNS‑layer load balancer for replicated services.
• § 102 analysis vs. claims 1 & 10: Does not anticipate.
  • It discloses a DNS server that returns a chosen server's address from among replicated servers — relevant to claim 1's "domain‑name server … responding to DNS queries by sending the chosen application server's network address."
  • However, its selection criterion is the servers' load (system load average), not a performance‑cost estimate derived from the servers measuring their own request‑response delays and projecting the increase in the average number of waiting clients from adding a client. It does not disclose that cost metric at all.
  • Most relevant cited reference to the DNS‑selection aspect; still a § 103 reference, not a strict § 102 anticipation.

Consolidated § 102 / § 103 assessment

Conclusion: For strict § 102 anticipation — which requires a single reference to disclose every element of the claim — none of US 5,530,744, US 5,774,660, US 5,867,706, US 5,916,017, the Cisco Distributed Director document, or the Lbnamed document anticipates independent claim 1 or claim 10, or any dependent claim 2–9, because each lacks at least the core "performance‑cost estimate = projected change in number of waiting clients from measured transaction delays." They are properly treated as § 103 background/analogous art, with the two DNS‑selection NPL references (Lbnamed; Cisco Distributed Director) and US 5,774,660 being the most pertinent.

Flags and caveats

1. US 5,916,017 (3M, ophthalmic lens) is off‑topic — a lens‑blocking patent with no networking content. Reported literally but excluded from any anticipation theory. Likely a citation‑list artifact.
2. § 102(e) dates: US 5,774,660 (issued 1998) and US 5,867,706 (issued 1999) issued after the '160 filing date; they can only be prior art via pre‑AIA § 102(e) and only as of their earlier US filing/priority dates (1996‑08‑05 and 1996‑01‑26/1996‑12‑19, respectively), each of which precedes 1997‑12‑23.
3. Priority‑date discrepancy (carried over from earlier sections): one third‑party aggregator lists 1997‑12‑22; the authoritative figure used here is 1997‑12‑23. This does not change any § 102 conclusion (the margin to each reference's date is months to years).
4. Scope of search: I analyzed the references cited on the face of the '160 patent, as requested. A complete invalidity analysis would also examine non‑cited art from the same era (e.g., the "Dias et al., A Scalable and Highly Available Web Server, COMPCON 1996" paper and HydraWEB materials that US 5,774,660 itself cites, and BIND round‑robin DNS)—an avenue worth pursuing if a full § 102/§ 103 challenge is needed.
5. Confidence: Citations, dates, and claim text are high confidence (from the authoritative '160 text plus Google Patents/uspto.report/FPO corroboration). The § 102/§ 103 legal conclusions are my analytical assessment, not a legal opinion, and are offered with moderate‑to‑high confidence on the "no strict anticipation" bottom line.

Primary sources: Google Patents US6178160 (https://patents.google.com/patent/US6178160/en); US5774660 (https://patents.google.com/patent/[US5774660A](/patent/US5774660A)/en); US5867706 (https://patents.google.com/patent/US5867706; FPO 5867706); US5530744 (https://patents.google.com/patent/[US5530744A](/patent/US5530744A)/en; uspto.report/patent/grant/5530744); US5916017 (https://patents.google.com/patent/US5916017); Cisco Distributed Director documentation (cisco.com, archived).

I'll research the specific prior-art references cited on the face of US 6,178,160 to ground the obviousness analysis.

Obviousness Analysis — U.S. Patent No. 6,178,160 B1

"Load balancing of client connections across a network using server based algorithms"

Analyst report · 35 U.S.C. § 103 · pre‑AIA (filed 1997‑12‑23)

0. Scope, framework, and caveats

Governing law. Because US 6,178,160 was filed 1997‑12‑23 — before the AIA's first‑to‑file provisions took effect — it is governed by pre‑AIA 35 U.S.C. § 103(a) and pre‑AIA § 102. Obviousness is assessed under the Graham v. John Deere, 383 U.S. 1 (1966), factors, as refined by KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007):

1. scope and content of the prior art;
2. differences between the claims and the prior art;
3. level of ordinary skill in the art; and
4. objective indicia of nonobviousness.

The burden of proving invalidity is clear and convincing evidence, and the challenger must articulate a reason to combine with "some rational underpinning" (Innogenetics v. Abbott Labs., 512 F.3d 1363, 1373 (Fed. Cir. 2008)).

Universe of prior art used. Per the task instruction, I confine the analysis to the references appearing on the face of US 6,178,160:

Caveats I must flag up front:

• I am working from the full text of the '160 patent (authoritative, supplied) and from search retrievals of the references, not from the physically certified copies of each reference. Element-by-element mappings below are therefore prima facie and would need to be confirmed against the references' complete disclosures.
• US 5,916,6017 — the "preformed ophthalmic lens base block" — is facially unrelated to network load balancing. I treat it as having no discernible bearing on the § 103 analysis, and I do not silently substitute another number. Its presence on the face of the patent may reflect an examiner/citation artifact.
• The Cisco Distributed Director document is dated Feb 21, 1997 — after Dec 23, 1996, and therefore not a § 102(b) statutory bar to this Dec 23, 1997 filing. It qualifies as prior art only under § 102(a) (publication before the applicant's date of invention) or, if its subject matter was embodied in Cisco products sold earlier, as a § 102(a) "known or used" reference. This is a soft spot in any DD-based combination; lbnamed (Sep 1995), by contrast, is a robust § 102(b) reference. This nuance does not affect the analysis if the invention date is on or near the Dec 1997 filing.
• No litigation is known for US 6,178,160, and the patent expired 2017‑12‑23. There is therefore no adjudicated record of validity or invalidity to build on (see the prior "Litigation summary" section). The following is a prospective invalidity assessment.

1. Level of ordinary skill in the art (PHOSITA)

The claims are directed to distributed-systems/network-server load balancing as of late 1997. A PHOSITA would be a software/systems engineer with (i) a working knowledge of TCP/IP, the DNS protocol (RFCs 1034/1035), HTTP, and SNMP; (ii) familiarity with server-farm/cluster architectures and the prevailing load-balancing products of the era (Cisco Local Director/Distributed Director, Resonate, F5 BIG/ip, IBM's parallel Web server); and (iii) at least a bachelor's degree (or equivalent experience) in computer science/electrical engineering plus ~2–3 years in network server administration or development. This is a relatively high-skill, fast-moving art, which cuts toward finding predictable combinations obvious under KSR.

2. Claim construction of the load-bearing terms

The obviousness dispute turns on two limitations that recur across the independent claims:

The patent's own specification supplies these constructions (e.g., aRTDelta, and Eq. (1): cost = xRate*aRTDelta + rNew*xRateNew). Critically, the "performance-cost estimate" is defined by the patent as a marginal quantity — the change in average number of waiting clients. That is a narrower concept than "current load," and it is the primary target of any nonobviousness argument.

3. Scope and content of each reference

US 5,867,706 (IBM). Discloses a parallel Web server whose processors (e.g., www1/www2/www3.ibm.com) appear to share a common Internet name (www.ibm.com). A name server receives the client's query for the generic name and returns the address of a selected processor; decision logic periodically studies the processors and selects "the least heavily loaded processor" based on a load-distribution record built by "load determining means" (Google Patents, https://patents.google.com/patent/US5867706). It expressly cross-references EP‑A‑0,648,038 for "dynamic load balancing … across the various processors." This reference alone discloses most of the architectural skeleton of claim 1(B).

US 5,774,660 (Resonate). A load balancer receives all requests for a site (single virtual address), determines the requested resource from the URL, and assigns the request to the node "least busy processing requests" (claim 6; Resonate Inc. v. Alteon Websystems, Inc., 338 F.3d 1360 (Fed. Cir. 2003), construing claim 6). Discloses measuring/using server busyness as the selection metric. (Surface source: https://patents.google.com/patent/[US5774660A](/patent/US5774660A)/en.)

US 5,530,744 (AT&T). A "customer routing point" acquires call-load status data from each destination ACD, predicts each ACD's expected status/delay at the time of an incoming call, and a "load balancer means … determin[es] the destination … by optimizing overall ACD status based on the … prediction" (claim 14; https://patents.google.com/patent/[US5530744A](/patent/US5530744A)/en). Although telephony, it is analogous art: routing among plural destination servers so as to optimize a global performance objective (delay) using predicted performance. This is the closest prior-art teaching of prediction-based load balancing.

NPL‑1 — Cisco Distributed Director (Feb 1997). A DNS-delegated appliance ("superintelligent DNS host") that answers A-record queries for a host name shared by multiple servers by returning one IP address of the "best" server, based on measured metrics (DRP, RTT via ICMP/TCP probes, routing distance), with TTL = 0 (see the PC Week Lab review, itweek.ru, and https://lists.isc.org/pipermail/bind-users/2000-June/015293.html). It is treated in the art as a canonical Global Server Load Balancing (GSLB) system (see Radware, Ltd. v. F5 Networks, Inc., N.D. Cal., discussing Cisco DD as GSLB prior art, https://www.courtlistener.com/opinion/[7317089](/patent/7317089)/). This reference discloses claim 1(B)'s DNS-response mechanism almost verbatim.

NPL‑2 — lbnamed (Schemers, 1995). A load-balancing DNS name server: a single name (e.g., elaine.best.stanford.edu) resolves to one of a cluster of hosts; a separate poller daemon periodically collects load from each host, computes a per-host weight formula, and feeds it back to the name server, which returns the best host's IP with TTL=0 (https://www.usenix.org/legacy/publications/library/proceedings/lisa95/full_papers/schemers.pdf). This is a DNS server that selects a host based on measured, dynamically-collected server-side load — i.e., claim 1(B) plus a server-side measurement mechanism, in a single reference, dated > 1 year before the '160 filing.

4. Element-by-element analysis — Claim 1

No single reference anticipated claim 1 — none teaches the marginal "increase in average number of waiting clients" estimate (the "✖" cell across all references). The case is therefore an obviousness case in which the combination must supply that limitation.

5. The combinations and the motivation to combine

Combination A (strongest on the architecture): lbnamed + '706 + '744

What it yields. lbnamed supplies the DNS-name-server-selects-a-host-based-on-dynamically-collected-server-load architecture (element B in full, plus per-host monitoring). '706 supplies the plural servers sharing a common name, load-determining means at the server, and decision logic selecting the least-loaded server. '744 supplies the performance-prediction step — routing decisions driven by a predicted per-destination performance measure (expected delay/queue) and an optimization objective over all destinations.

Motivation. (i) All three are in the same field (distributing client demand among equivalent servers) and address the same known problem — the '160 patent's own background concedes that ping/RTT-based DNS selection "does not balance server load particularly well" and that weighted-random allocation was the fallback. (ii) The references themselves point at each other: '706 expressly ties a name server to load-based processor selection (citing EP‑A‑0,648,038); lbnamed demonstrates that the DNS layer was a recognized point of control; '744 demonstrates that predicting the destination's future performance (rather than reading its instantaneous state) improves routing. (iii) Under KSR, combining "prior art elements according to known methods to yield predictable results" and "use of a known technique to improve similar devices in the same way" are express rationales for combining. Coupling a load-predicting router ('744) with a load-monitoring DNS selector (lbnamed/'706) is such an improvement.

Combination B (strongest if DD is given its proper date): Cisco Distributed Director + '660 (or '706)

What it yields. DD provides the complete DNS-based selection mechanism (common name → chosen best-server IP, TTL=0, metrics collected over the network). '660/'706 provide the server-load/busyness measurement and "least busy" selection criterion.

Motivation. The published record shows the artisan was actively directed to combine DNS-based global selection with server-load balancing: contemporary reviews of Distributed Director expressly warned that it "should be used with [Cisco] Local Director" to balance load, because otherwise a nearby-but-overloaded server would be selected (PC Week Lab review, itweek.ru, 1997). The industry was thus explicitly motivated to marry DNS-level server selection (DD) to load-level server balancing (Local Director/Resonate/IBM). That is precisely the combination the '160 claims. This is a textbook "known problem + known solution → obvious" scenario, and it is corroborated by the Radware v. F5 record treating Cisco DD as GSLB prior art.

Combination C (for the measurement limitation): '744 + '706 (or '660)

For element 1(A)'s "measuring delays between requests and responses," the artisan need only measure what the application server already experiences — the request→response latency — as the load metric. '744 teaches using predicted expected delay and queue size as the metric that determines routing; '706 teaches server-side "activity data" collection. The '160 patent's own background frames the move from ping-based (network-level) latency to true server-side latency as the improvement. That move is a design choice between known measurement points, and the motivation (ping latency "does not necessarily correlate well with the latency that the service's clients experience" — '160 Background, quoted from the authoritative text) is a well-recognized engineering rationale present in the field at the time.

The common gap

The only limitation none of these references supplies is the marginal "increase in the average number of waiting clients that adding a further client will cause" — the model expressed in the '160 patent's Eq. (1)/(3a)/(4a). An obviousness case must therefore rest on the argument that, given '744's prediction/optimization objective, an artisan optimizing a server farm would naturally model the incremental effect of the next client — an application of standard queueing reasoning (e.g., Little's Law and the relationship between utilization and response time). This is the genuinely contestable step and is discussed in § 7.

6. Claim 10 (method) and dependent claims

Claim 10. Tracks claim 1: (A) measure request/response delays per server; (B) determine per-server performance-cost estimates = Δ in average waiting clients from adding a client; (C) choose among servers based on the estimates. The same combinations (A/B/C) apply; claim 10 is broader in that it does not expressly recite the DNS-response step (see prior summary's note that the reproduced claim stops at "making a choice"), but its preamble ties it to "responding to a DNS query." Claim 10 rises or falls with claim 1.

Claim 2 (costs to existing clients only + projected new-client latency, chosen on the sum). Obvious over Combination A: '744 explicitly balances between the benefit to the routed-in customer and the state of existing queues, and computing an expected new-client latency from average response time is routine arithmetic.

Claim 3 (servers report transaction rate and average client count; DNS computes total rate ÷ total clients × average response time). This is an explicitly mathematical limitation. Under Parker v. Flook/§ 103, where the result is a straightforward computation of an average/projected rate from reported statistics, the recitation adds no patentable weight beyond the prior-art combination. Obvious over Combination A/B if the underlying selection is obvious.

Claims 4–5 (cost additionally a function of number of transactions / transaction-data volume). Merely adding further known load variables to the estimate. lbnamed's poller already fuses multiple load variables into its weight formula (users, load average, a "fudge" term), teaching multi-variable load weighting. Obvious.

Claims 6–9 (the model-fitting limitations — sampling periods, parameterized load-limited and client-limited models, selecting the best-fit model by least-mean-square error, and extrapolating added latency). These are the least vulnerable claims. Fitting a parameterized model to per-period samples and selecting the model with lowest mean-square error is a concrete, non-trivial computational method. None of the listed references discloses two-domain modeling or least-squares model selection. A challenger would need additional prior art (e.g., queueing-theory/regression modeling references) not present on the patent's face to mount a credible § 103 attack on claims 6–9. On the record of the six listed references alone, claims 6–9 are the strongest candidates for nonobviousness.

7. Objective indicia and the honest counter-case

• No objective indicia (secondary considerations) are known. There is no record of unexpected results, long-felt need, industry praise, or copying. Absence of evidence is not evidence of nonobviousness, but it means the patent has no affirmative Graham factor 4 support on this record.
• The strongest nonobviousness argument rests on claim 1's "performance-cost estimate = increase in average number of waiting clients." Read with the specification (the two-domain model and Eq. (4a), aRTDelta = b + c*xSize), this is a marginal-cost formulation. The listed references select on current load or current/predicted delay; none frames selection as minimizing the derivative of aggregate waiting. An accused infringer would have to bridge that gap with the "predictable variation / market-pressure" rationales of KSR, supported by '744's prediction-based objective. Whether that bridge is enough is genuinely debatable.
• The strongest obviousness arguments are: (i) claim 1's architecture (common name, DNS selection, load-collection over the network) is squarely disclosed/obvious from lbnamed, DD, and '706; (ii) the motivation to combine DNS selection with server-load measurement is documented in the contemporaneous literature (Cisco DD + Local Director) and in '706's own name-server/load-selection coupling; and (iii) claims 3–5 are routine computations that likely add no weight.
• Likely outcome on this record: claims 1, 2, 4, 5, 10 are plausibly obvious over Combinations A/B/C; claim 3 is obvious as routine computation if the base claim is obvious; claims 6–9 would likely survive a § 103 challenge based on the six listed references alone. This is a prospective assessment only — no tribunal has ruled, and the clear-and-convincing standard applies.

8. Bottom line

Using only the prior art on the face of US 6,178,160:

1. Claims 1 and 10 — no single reference anticipates (none teaches the marginal "average waiting clients" estimate), but the claimed architecture (common host name → DNS selection by performance) is disclosed/obvious from lbnamed + '706 (with '744 for prediction) and from Cisco Distributed Director + '660/'706. Strong motivation to combine exists in the same field, in the references' own cross-citations, and in the contemporaneous Cisco DD + Local Director guidance.
2. Claims 2–5 — obvious extensions (prediction of new-client latency; routine averaging of reported statistics; multi-variable load weighting already in lbnamed).
3. Claims 6–9 — the statistically sophisticated model-fitting / best-fit model-selection limitations are the likely nonobvious core and are not defeated by the listed references alone.
4. US 5,916,6017 (3M ophthalmic lens block) is irrelevant and contributes nothing to the analysis; I have not substituted any similar number for it.
5. Sources: https://patents.google.com/patent/US5774660A/en · https://patents.google.com/patent/US5867706 · https://patents.google.com/patent/US5530744A/en · https://www.usenix.org/legacy/publications/library/proceedings/lisa95/full_papers/schemers.pdf · NPL‑1 Cisco Distributed Director (Feb 1997) · Cisco DD as GSLB prior art: https://www.courtlistener.com/opinion/7317089/radware-ltd-v-f5-networks-inc/ · Resonate v. Alteon, 338 F.3d 1360 (Fed. Cir. 2003).

Confidence: The claim-element mapping and combination rationales are grounded in the reference summaries retrieved above; they are moderately-to-highly confident. Confidence is lower for any finding that depends on details of '706's, '660's, or '744's full specifications that I retrieved only in part, and I explicitly cannot quantify how an art-specific PHOSITA would weigh the "marginal waiting-clients" modeling limitation — which is the crux of any real § 103 contest.