US 6798786

I'll search for authoritative records on this specific patent.

USPTO / docket search — US 6,798,786

Searches run against Google Patents (USPTO full-text mirror), the USPTO Official Gazette issue 1286-4 entry, the Unified Patents litigation/patent portal, and general docket-oriented queries. Important caveat up front: I did not find any Court of Appeals for the Federal Circuit (CAFC) 2026 docket entry naming this patent. My docket-oriented queries returned zero results, so I cannot authoritatively confirm the absence of 2026 CAFC activity — only that no such entry surfaced in my searches. Likewise, I did not retrieve the full 32‑claim set from an authoritative full-text source; the remarks on independent claims below are grounded in the issued claim 1 as reprinted in the Official Gazette plus the patent's own SUMMARY and detailed description.

I did not auto-correct any identifier. Everything below is reported literally as it appears in the sources.

Bibliographic data

Assignment chain (per Google Patents reassignment records): Nortel Networks Corporation (1999-08-20) → Rockstar Bidco, LP (2011-10-28) → Rockstar Consortium US LP (2014-03-10) → RPX Clearinghouse LLC (2015-02-09). A security agreement to JPMorgan Chase Bank, N.A. as collateral agent was recorded 2016-03-09 and released 2018-01-02.

Litigation found: Delaware District Court case 1:07-cv-00507, filing date 2007-08-16, status closed (Nortel Networks Ltd among the parties). No 2025–2026 litigation or CAFC appeal surfaced.

Related family members (per Google Patents priority links): US 7,260,060 B1 ("Call admission control," priority 2000-05-23); EP 1079573 B1; CA 2316435 C.

Abstract (verbatim)

"A method and system of managing calls over a data network includes determining an available bandwidth of the data network. After a call request is received for establishing a call between at least two network terminals, one or more of a plurality of resource elements are selected in response to the call request based on the bandwidth of the data network. The resource elements, which can include codecs (coders/decoders), packet sizes (for carrying audio data), and others, are used in the requested call between the at least two network terminals. Further, a plurality of communities may be defined each including one or more terminals. One or more usage threshold values may be assigned to a link or links between communities, and a call request is processed based on the one or more usage threshold values. The processing includes at least one of determining whether to admit the call request and selecting resource elements to be used during a call between terminals over the link."

⚠️ Discrepancy worth flagging: the abstract says "available bandwidth," but the SUMMARY and issued claim 1 say "usage information." Do not treat these as interchangeable when reading the claims.

Independent claim 1 (verbatim, per Official Gazette issue 1286-4)

"1. A method of managing calls over a data network, comprising:
determining usage information of the data network;
receiving a call request for establishing a call between at least two network terminals; and
selecting one or more of a plurality of resource elements as candidates for use in the requested call in response to the call request based on usage information of the data network, wherein the resource elements define one or more characteristics of data exchanged between the network terminals,
wherein the selecting includes selecting one or more resource elements based on usage policy set by a policy server."

Plain-language overview of the inventive aspects described as "independent"

The specification's SUMMARY frames the disclosure around two independent aspects, and the description supports a corresponding apparatus/system counterpart. Because I could not retrieve the full printed claim set, I give the substance and flag numbering uncertainty:

1. Claim 1 — resource-element selection method (confirmed independent). A call server receives a call request between two terminals, determines how much of the data network is being used (usage information), and then picks which codec / packet size / other "resource element" candidates are eligible for the call based on that usage. The resource elements are the things that define characteristics of the data exchanged (e.g., codec, frames-per-packet). The claim specifically requires that the selection be based on a usage policy set by a policy server — a separate policy server is queried and its policy prunes the candidate list. Notably, claim 1 does not require querying a network monitor for delay/loss; that is an optional, separately described embodiment (FIGS. 7A–7B, 8).

2. "Communities" / call-admission method (independent aspect per SUMMARY; claim number not confirmed). The system is divided into "communities" — groups of terminals joined by high-bandwidth links (e.g., LANs). Thresholds are assigned to each community and to each inter-community link: L (bandwidth limit), M (threshold at which resource re-selection kicks in), N (threshold at which outgoing calls are blocked), and T (measured traffic). A new call request is processed against those thresholds, and processing includes deciding whether to admit the call over the link (and/or to restrict the resource elements allowed). Denial occurs when, e.g., traffic exceeds N (community) or L_IJ (link).

3. Apparatus/system counterpart (independent aspect per SUMMARY's "method and system"; claim number not confirmed). The same functionality implemented in a call server / communications system (call processing routines, usage table, network interface layers), i.e., a machine/apparatus claim rather than a method claim.

The disclosed embodiments that are not required by claim 1 include: querying a network monitor for packet delay/jitter/loss; the H.323-style negotiation variants of FIGS. 2–5 (one where the call server queries the destination terminal, another where the destination terminal picks from a ranked candidate list); the merit factor M = W_Q·Q + W_B·B + W_R·R with dynamic weights W_Q = (1−t)·0.8, W_B = t, W_R = (1−t)·0.2; the E-model R-value charts for G.729A and G.723.1; and periodic re-selection mid-call.

Cited prior art (from the Unified Patents record)

US 5,870,561 (network traffic manager / policy-based recommendations); US 5,889,774; US 6,477,143; US 6,069,890; US 6,426,942; US 5,953,322; US 6,426,955; US 6,356,545 (internet telephone with dynamically varying codec); US 6,430,289; US 6,501,736; US 5,883,891; US 6,222,829; US 5,907,610; US 5,115,429; US 6,463,044; US 5,828,666; US 6,373,835. Non-patent literature includes Bernet et al., "A Framework for End-to-End QOS Combining RSVP/Intserv and Differentiated Services" (IETF Internet Draft, Mar. 1998); DataBeam, "A Primer on the H.323 Series Standard"; IBM, "ATM Overview" (1995); Trillium, "IP Quality of Service White Paper" (Apr. 17, 1998); Toga et al., Intel Technology Journal (Q2 1998); RFC 2205 (RSVP).

Uncertainties / items I could not verify

• CAFC 2026 dockets: no hits. Absence of evidence, not evidence of absence.
• Exact numbering of the non-claim-1 independents: not confirmed from an authoritative full claim set; only SUMMARY-level and claim-1-verbatim support is available to me here.
• Current owner of record naming: records show both "Nortel Networks Corp" and "RPX Clearinghouse LLC" as assignee entries, with the OG printing "Nortel Networks Limited." These are inconsistent renderings across sources; treat the recorded reassignments as controlling rather than the summary labels.
• Claim 1's relationship to the abstract's "available bandwidth" language is a real textual mismatch, not a transcription error on my part.

I'll research litigation involving US patent 6798786 using multiple sources.

Let me dig deeper into the specific litigation reference and related searches.

I found a key lead. Let me verify and expand.

Litigation involving U.S. Patent No. 6,798,786

Important number note: U.S. Patent No. 6,798,786 ("6798786" without commas) is the patent at issue — "Managing calls over a data network," invented by Wing F. Lo, Xuewen Li, and Alireza Abaye, filed 1999-08-20, granted 2004-09-28, originally assigned to Nortel Networks Ltd. I treated 6798786 and 6,798,786 as the same patent number, and did not conflate it with similar numbers such as 6,737,989, 6,755,885, 6,346,878, or 8,940,878 that appear in unrelated cases.

1. Vonage Holdings Corp. v. Nortel Networks Inc. and Nortel Networks Ltd. (Nortel's counterclaims asserting the '786 patent)

Details: In the counterclaim, the '786 patent appears as "CLAIM 10: INFRINGEMENT OF U.S. PATENT NO. 6,798,786" (¶¶ 67–70), asserted willfully, with Nortel seeking damages (no less than a reasonable royalty), enhanced damages, injunctive relief, fees, and costs. It was one of 12 Nortel patents asserted against Vonage (alongside, e.g., 6,091,808; 6,445,695; 7,050,861; 6,823,370; 7,035,390; 6,934,279; 6,337,858; 5,991,389; and 6,799,210). The dispute grew out of a 2004 suit by Digital Packet Licensing, Inc. ("DPL") against Nortel in the Northern District of Texas (4:04-cv-00548), which Vonage inherited in 2006 — but note that the '786 patent was not part of the Texas case; that case involved Vonage's '485, '136, and '707 patents and Nortel's '808, '695, and '861 patents. The '786 patent entered the dispute only through Nortel's Delaware counterclaim.

Sources:

• Google Patents litigation entry for US 6,798,786, citing the Delaware District Court case 1:07-cv-00507: https://portal.unifiedpatents.com/litigation/Delaware%20District%20Court/case/1%3A07-cv-00507 (also mirrored at https://patents.google.com/patent/US6798786/en)
• Nortel's December 14, 2007 counterclaim (Case 1:07-cv-00507-GMS, Doc. 28), reproduced at findforms.com
• ZDNet, "Nortel sues Vonage for patent infringement" (Dec. 2007): https://www.zdnet.com/article/nortel-sues-vonage-for-patent-infringement/
• CRN, "Nortel Files Suit Against Vonage": https://www.crn.com/news/networking/204805412/nortel-files-suit-against-vonage
• Communications Daily, "Vonage wants a federal judge to stop Nortel from making infringement claims…" (Aug. 22, 2007): https://communicationsdaily.com/article/2007/08/22/vonage-wants-a-federal-judge-to-stop-nortel-from-making-infringem-0708220120
• The New York Times, "Vonage and Nortel End Skirmish Over Patents" (Jan. 1, 2008): https://www.nytimes.com/2008/01/01/technology/01patent.html
• GovInfo, N.D. Tex. 4:04-cv-00548 (DPL/Nortel–Vonage background): https://www.govinfo.gov/content/pkg/USCOURTS-txnd-4_04-cv-00548/pdf/USCOURTS-txnd-4_04-cv-00548-1.pdf

Other litigation search results

• No other litigation specifically asserting U.S. 6,798,786 was found. I searched the Unified Patents litigation portal content, Google Patents litigation data, and general web/PACER-derived sources. Google Patents' own "litigation" field for US 6,798,786 lists only the Delaware case (1:07-cv-00507) above.
• I found no IPR, PGR, or CBM proceeding naming 6,798,786 as the challenged patent.
• Despite the patent's later ownership chain (Nortel → Rockstar Bidco, LP (2011) → Rockstar Consortium US LP / RPX Clearinghouse LLC (2015)), the Rockstar-era 2013–2014 campaigns and Spherix-related assertions I located involve different patents (e.g., the '048, '551, '572, '937, '298, '973, '131, 6,233,245, 6,684,241, 6,069,895, 5,732,080, 6,636,508, 6,778,653) — not 6,798,786. I therefore found no evidence the '786 patent was asserted by Rockstar/RPX/Spherix.

Caveats / confidence

• I could not directly query PACER or the CAFC docket for case 1:07-cv-00507; the docket details above rest on court filings reproduced in secondary sources and contemporaneous news reports, which are consistent with one another.
• The settlement terms (three-for-three cross-license, dropped past-damages and remaining claims) come from news reports and Nortel's statement; I did not review the actual dismissal order. I do not have high confidence on the exact settlement date (reported as on/about Dec. 31, 2007).
• The patent is now expired (Google Patents status: "Expired – Fee Related"; anticipated expiration 2019-08-20), so no active litigation on it is expected.
• If you need a PACER-certified case history, the docket to pull is D. Del. 1:07-cv-00507-GMS, and the related Texas action is N.D. Tex. 4:04-cv-00548 (which did not involve the '786 patent).

I'll verify the structured data's "no proceedings" default against public sources before writing the report.

No PTAB hits yet. Let me run a few more targeted searches to be sure I'm not missing a proceeding indexed under a different caption, plus check the district court matter.

Let me check the Unified Patents patent page and the district court litigation for any challenge history.

Proceedings overview

Total AIA trial proceedings on file: 0. No active proceedings, no claims invalidated, no claims sustained, no settlements, no institution denials — the USPTO Open Data Portal structured block reports no AIA trials, and my independent web searches (PTAB petition/decision documents, Docket Alarm PTAB dockets, Unified Patents' patent page, and litigation coverage) surfaced no IPR, PGR, or CBM petition ever filed against US 6,798,786. The bottom line for a defendant is unusual: this patent has never been stress-tested at the PTAB, so there is no IPR record to lean on — but that is largely academic, because the patent expired on 2019-08-20 (20-year term from the 1999-08-20 filing date) and is recorded as "Expired – Fee Related." The defensive posture is therefore not "hardened by surviving IPRs" but rather "the patent is dead by its own term; any assertion today is damages-barred as a practical matter."

No proceedings to itemize

I cannot populate the per-proceeding template because there are no proceedings. Rather than invent one, here is the complete relevant record I could verify:

Per-proceeding fields (judge panel, petition grounds, institution decision, FWD, settlement, appeal) are N/A — no proceeding exists. I am not reporting a panel, a grounds list, or an FWD for a case that was never filed.

Strategic summary

Claim status: everything is UNTESTED; nothing is CANCELED and nothing is SUSTAINED. Because no AIA trial has ever been instituted, there is no PTAB claim-level adjudication for US 6,798,786. For the record, the patent as displayed in the public claims text appears to carry claims 1–15 (independent claims 1, 2, 3, 5, 8, 11, 12 and 15, per https://www.freepatentsonline.com/[6798786](/patent/6798786).html — I could not confirm the exact count or scope against the USPTO certified copy, so treat that listing as a secondary source and verify it before relying on it). Claim 1 as there recited requires, inter alia, "determining usage information of the data network," "receiving a call request…," "selecting one or more of a plurality of resource elements… based on usage information of the data network," and "wherein the selecting includes selecting one or more resource elements based on usage policy set by a policy server." The community/call-admission threshold subject matter appears in claim 5 and in claim 12 ("assigning at least first and second usage threshold values to a link between communities…"). None of these claims has been narrowed or canceled by the PTAB.

Estoppel landscape: none. Section 315(e)(2) estoppel is triggered only by a petitioner whose IPR was instituted and reached a final written decision. With zero proceedings, no petitioner, no privy, and no real party in interest carries any PTAB estoppel against this patent. That means every prior-art ground remains fully available to a defendant — § 102 and § 103 on patents and printed publications (the only grounds IPR permits), § 102/§ 103/§ 112 in district court or the ITC, and any § 101 challenge. Note the mechanics for this particular patent: it is pre-AIA (effective filing 1999-08-20, priority 1999-06-07 to provisional 60/137,877), so (a) PGR is unavailable — PGR reaches only first-to-file patents; and (b) CBM is effectively unavailable because this is a call-management/telephony-engineering patent, not one claiming "a method or corresponding apparatus for performing data processing or other operations used in the practice, administration, or management of a financial product or service," and in any event the CBM program closed to new petitions on 2020-09-16. Practically, IPR is the only AIA vehicle that would ever have applied — and it is now pointless.

Pattern signals. (1) No serial petitioner: no entity filed one IPR against this patent, let alone multiple. (2) No PTAB appeal activity by the patent owner, because there was nothing to appeal. (3) The ownership chain — Nortel → Rockstar Bidco (2011-10-28) → Rockstar Consortium US (2014-03-10) → RPX Clearinghouse LLC (2015-02-09) — runs squarely through a defensive aggregator. That matters for your case: the 2013–2015 Rockstar assertion campaign against cable MSOs (Charter, WOW, Knology, Suddenlink, Cable One, TWC, Windstream) asserted a different Nortel patent set (the '474, '862, '197, '990, '649, '893, '397, '253, '389, '048, '879, '917, '299 and RE40,999 patents) — US 6,798,786 was not in the Rockstar Asserted Patents list as reported in those complaints. RPX's acquisition of this asset, combined with the substantive expiration in 2019, explains the absence of any post-grant challenge: nobody had financial reason to file one. (4) Low-confidence signal: the patent does appear on Unified Patents' public portal page (https://portal.unifiedpatents.com/patents/patent/US-6798786-B1), which indexes prior art for many patents and does not by itself indicate a Unified Patents challenge. I found no Unified Patents IPR against this patent.

Recommended next steps

1. Lead with the expiration, not the invalidity story. The patent was granted 2004-09-28 and, per the Google Patents legal-status record, reached its "anticipated expiration" on 2019-08-20 and is now "Expired – Fee Related." Confirm the expiration date, any patent term adjustment, and any terminal disclaimer on the USPTO PatentCenter face page before you write this in a brief. If the term is as recorded, a suit filed today (2026-09-28) reaches back only to 2020-09-28 under 35 U.S.C. § 286 — a window that falls entirely after expiration, so there can be no recoverable infringement. Confirm whether any pre-2019-08-20 conduct could still be reached (spoliation/tolling arguments only; the § 286 window on pre-expiration conduct closed on 2025-08-20).
2. If you nevertheless need an invalidity posture, you have a clean slate. No § 315(e) estoppel, no FWD findings to fight, no claim construction to work around. Because no IPR exists, the full § 102/§ 103/§ 112/§ 101 toolkit is available in district court or the ITC, subject only to ordinary pleading and expert-discovery deadlines. Any IPR you file would be discretionary-denial bait given the expired term and zero ongoing damages exposure.
3. Check the current owner before responding to a demand. The recorded assignee is RPX Clearinghouse LLC (assignment recorded 2015-02-09), with a 2016-03-09 security agreement in favor of JPMorgan Chase as collateral agent that was released on 2018-01-02. Verify current chain of title in USPTO Assignment records, then confirm whether the party that sent you anything has standing to enforce.
4. Do not describe this patent to your board as "survived two IPRs" or as "hardened." It has not survived anything — it was never challenged. The accurate characterization is: no AIA trial history; expired by term 2019-08-20; assigned to a defensive aggregator since 2015.

Verification note / caveats: The USPTO ODP ingest reports zero AIA trials for this patent, which I treated as canonical. I supplemented with web searches of PTAB petition documents and decision PDFs, Docket Alarm PTAB dockets, CourtListener dockets for the 2013–2015 Rockstar litigation, and the Unified Patents patent page. I could not run a direct PTAB E2E docket query in this session, and I did not verify the parties or disposition of the 2007 D. Del. case (1:07-cv-00507) — that identifier is reported as-is from the Unified Patents litigation data and predates the AIA, so it is not an AIA proceeding regardless of outcome.

I'll research the assignment record and correspondent details for this patent.

Let me dig deeper into the specific reel/frame records and correspondents.

Let me search for the specific reel/frame records and correspondents for this patent's chain.

Assignment & Ownership Reconstruction — US 6,798,786

Method / caveat on sources. assignmentcenter.uspto.gov and assignment.uspto.gov/patent/index.html are session-based interactive search tools; I could not open the patent-specific result page or its reel/frame detail view programmatically. The chain below is therefore reconstructed from (a) Google Patents' legal-events block for US 6,798,786 (USPTO assignment-data mirror), (b) Espacenet INPADOC assignment entries, (c) the primary patent text itself, and (d) chain-of-title declarations filed in IPR2014-01167 / IPR2014-01180 power-of-attorney exhibits for sibling Nortel/Rockstar patents (US 6,778,653; US 7,154,879; US 7,009,931). Where a reel/frame is known only from a sibling patent's IPR exhibit, I say so — I did not invent reel/frame numbers for the '786 itself. The Assignment Center does have records for this patent, so I proceed past the "stop here" branch.

Inventors

Employer is not inferred from the residence — it is established by the assignment record: the 1999-08-20 conveyance lists assignors "ABAYE, ALIREZA; LI, XUEWEN; LO, WING F." to Nortel Networks Corporation on the filing date. All three were Nortel employees at filing.

Departure pattern — no red flag. I found no evidence that the inventors left Nortel within 12 months of filing. Positive counter-evidence: Xuewen Li appears as a named inventor assigning later Nortel applications to Nortel Networks Corporation (e.g., in the GENBAND chain-of-title document covering US 6,885,658, filed well after 1999). This cuts against the "inventors bail out early → portfolio fire-sale" tell. The eventual fire-sale here was driven by Nortel's bankruptcy, not by inventor attrition.

⚠️ Cross-reference flag: the earlier patent summary reports the OG original assignee as "Nortel Networks Limited," but the assignment record shows the inventors conveyed to "NORTEL NETWORKS CORPORATION." These are two different Nortel legal entities. The inventor→Corporation step is the true root of title; a Corporation→Limited step must therefore exist between 1999 and 2011 (the 2011 Rockstar assignor is "Nortel Networks Limited"). See the timeline caveat below.

Original assignee

Nortel Networks Corporation (root of title) → Nortel Networks Limited (assignor of record to Rockstar in 2011; OG-listed assignee). Nortel was a global telecommunications and data-networking equipment manufacturer — a genuine operating company that shipped packet-voice / VoIP and hybrid PSTN–data-network products squarely within the '786 subject matter (call servers, gateways, codec/bandwidth management). The '786 was, moreover, asserted by Nortel itself in 2007 against Vonage (D. Del. 1:07-cv-00507-GMS, Nortel's Dec. 14, 2007 counterclaim) — i.e., a classic operating-company assertion at the time.

Current status: dissolved through insolvency. Nortel filed for creditor protection in January 2009 (U.S. case Bankr. D. Del. 09-10138-KG), and its patent portfolio — including the '786 — was sold at auction in June 2011 for $4.5 billion to Rockstar Bidco, LP. Nortel no longer exists as an operating entity.

Assignment timeline

Reel/frame retrieval note: The only reel/frame confirmed from this patent's own primary text is 038041/0001 (the JPMorgan security interest and its release). Reels 027164/0356 (Nortel→Rockstar Bidco) and 030094/0370 (Rockstar Bidco→Rockstar Consortium US LP) are the bulk-assignment reels recited in IPR chain-of-title exhibits for sibling Nortel/Rockstar patents (US 6,778,653; 7,154,879); they are likely but not verified for the '786. I could not retrieve the original inventor→Nortel reel/frame or the Rockstar→RPX reel/frame for this patent.

• 1999-08-20 (executed) / recorded 1999-08-20 — Reel not retrieved (origin event)

  • Conveyance: Assignment
  • Assignor: Abaye, Alireza; Li, Xuewen; Lo, Wing F. (the three inventors)
  • Assignee: Nortel Networks Corporation
  • Correspondent: not retrievable from public mirrors. ⚠️ Recurrence check could not be performed.
  • Context: Original employment assignment — inventors convey to their employer on the filing date.

• (date not surfaced) — Nortel Networks Corporation → Nortel Networks Limited

  • Conveyance: Assignment / internal reorganization (inferred; required by the entity mismatch above)
  • Assignor: Nortel Networks Corporation · Assignee: Nortel Networks Limited
  • Correspondent: not retrievable
  • Context: Internal corporate reorg — the OG prints "Nortel Networks Limited" as assignee, and the 2011 Rockstar assignor is "Nortel Networks Limited," so this intra-Nortel hop must exist even though Google Patents omits it for this patent. Treat as a gap, not a confirmed entry.

• 2011-07-29 (executed per Espacenet INPADOC) / recorded 2011-10-28 — Reel 027164/0356 (reel per sibling IPR exhibits — not verified for '786)

  • Conveyance: Assignment
  • Assignor: Nortel Networks Limited · Assignee: Rockstar Bidco, LP
  • Correspondent: not retrievable. ⚠️ Recurrence check could not be performed.
  • Context: Bankruptcy fire-sale / transfer-to-asserter — Rockstar Bidco was the consortium vehicle (Apple, Microsoft, RIM, Ericsson, Sony) that won the June 2011 Nortel auction for ~6,000 assets at $4.5B.

• 2014-03-10 (recorded) — Reel 030094/0370 (reel per sibling IPR exhibits — not verified for '786)

  • Conveyance: Assignment
  • Assignor: Rockstar Bidco, LP · Assignee: Rockstar Consortium US LP
  • Correspondent: not retrievable
  • Context: Internal consortium restructuring — assets re-papered into the operating Rockstar LP entity used for the 2013–2014 assertion campaign.

• 2015-02-09 (recorded) — Reel not retrieved

  • Conveyance: Assignment (Asset Purchase Agreement dated 2014-12-22)
  • Assignor: Bockstar Technologies LLC; Constellation Technologies LLC; MobileStar Technologies LLC; NetStar Technologies LLC; Rockstar Consortium LLC; Rockstar Consortium US LP (the "Sellers" of the RPX transaction)
  • Assignee: RPX Clearinghouse LLC
  • Correspondent: not retrievable
  • Context: Transfer into a defensive aggregator — RPX bought "substantially all" Rockstar assets (~$900M total; $25M deposit + $875M on close), funded by a 30+ company syndicate (incl. Cisco, Google) that took non-exclusive licenses and made the portfolio available on FRAND terms.

• 2016-03-09 (recorded) — Reel 038041/0001 ✅ confirmed from this patent's own text

  • Conveyance: Security Agreement
  • Assignor: RPX Clearinghouse LLC; RPX Corporation · Assignee: JPMorgan Chase Bank, N.A., as Collateral Agent
  • Correspondent: not retrievable
  • Context: Securitization / collateralization of the RPX portfolio — a financing lien, not a change in beneficial ownership.

• 2018-01-02 (recorded) — Reel 038041/0001 (release)

  • Conveyance: Release
  • Assignor: JPMorgan Chase Bank, N.A. · Assignee: RPX Corporation; RPX Clearinghouse LLC
  • Correspondent: not retrievable
  • Context: Lien release — security interest extinguished; title reverts to unencumbered RPX ownership.

Timeline diagram

timeline
    title Ownership of US 6798786
    1999 : Inventors assign to Nortel Networks Corp
         : Provisional 60137877 filed Jun 7
    2011 : Nortel bankruptcy auction to Rockstar Bidco LP
    2014 : Rockstar Bidco to Rockstar Consortium US LP
    2015 : Rockstar entities to RPX Clearinghouse LLC
    2016 : JPMorgan security interest recorded
    2018 : JPMorgan security interest released
    2019 : Patent expires

NPE / troll-pattern signals

Verdict

Defensive / non-asserting — chain terminates at a defensive aggregator.

Justification: The ownership chain ends at RPX Clearinghouse LLC (recorded 2015-02-09), the clearinghouse vehicle of a 30+ member syndicate (incl. Cisco, Google) that bought substantially all Rockstar assets under the Dec. 22, 2014 Asset Purchase Agreement and committed to FRAND licensing — and the patent is now expired (Aug. 20, 2019). The intermediate links nonetheless carry strong NPE signals: a bankruptcy fire-sale out of Nortel (Bankr. D. Del. 09-10138) into Rockstar Bidco, LP (reel 027164/0356, recorded 2011-10-28) and then Rockstar Consortium US LP (reel 030094/0370, 2014-03-10), a recognized privateering consortium. So the honest characterization is: operating-company invention → NPE consortium → neutralized by a defensive aggregator — the last recorded interest (RPX Clearinghouse, subject to a security lien at reel 038041/0001 that was released 2018-01-02) is non-asserting.

Verification: https://assignmentcenter.uspto.gov/ (search patent 6798786) — note that the reel/frame and correspondent fields I could not retrieve (inventor→Nortel; Nortel→Limited; Rockstar→RPX) are exactly the records you should pull directly, since signal #3 (repeat correspondent) is the one open question that could change the confidence call.

Explicit uncertainties I am not hiding: (i) reel/frames for the inventor→Nortel and Rockstar→RPX links were not retrieved for this patent; (ii) the Corporation→Limited intra-Nortel hop is inferred, not evidenced; (iii) no correspondent names were obtainable, so I cannot confirm or deny a repeat-player attorney; (iv) the '786 does not appear on any Rockstar/RPX assertion list I found — the NPE signals attach to the chain, not to a documented assertion of this specific patent.

I'll research the prior art cited against US 6,798,786, verifying each reference's details.

Let me verify details on the key cited references.

Prior-art analysis — US 6,798,786 B1 ("Managing calls over a data network")

Scope note (per your instruction): I searched for the number 6798786 literally and did not substitute similar numbers (e.g., 6,798,796; 6,878,786; 6,737,989; 6,346,878). The hit is confirmed as US 6,798,786 B1, Wing F. Lo / Xuewen Li / Alireza Abaye, app. 09/370,984, filed 1999-08-20, granted 2004-09-28, claiming priority to provisional 60/137,877 filed 1999-06-07. Two independent confirmations:

• Google Patents (USPTO full-text mirror): https://patents.google.com/patent/[US6798786B1](/patent/US6798786B1)/en
• Official Gazette issue 1286-4 reprint (Indiana VDL): https://webapp1.dlib.indiana.edu/virtual_disk_library/index.cgi/[5628977](/patent/5628977)/FID3294/OG/html/1286-4/us06798786-20040928.html

Analytical frame used below:

• Pre-AIA § 102 applies (application filed 1999), so a US patent is prior art as of its US filing date under § 102(e) (the examiner/attorney-cited art set was used in a pre-AIA prosecution).
• Anticipation (§ 102) requires a single reference to disclose every limitation of a claim, arranged as claimed. Obviousness (§ 103) can combine references. I flag which bucket each reference falls in.
• I have claim 1 verbatim, so I can do a true § 102 comparison for it. The other independent claims (the "communities"/call-admission method and the apparatus/system claim) I have only at SUMMARY level with unconfirmed numbering — so those mappings are provisional and marked as such.
• ⚠️ Reminder of the textual mismatch already flagged: the abstract says selection is based on "available bandwidth," while claim 1 / SUMMARY say "usage information." I read the claims, not the abstract.

1. The cited-references set (18 US patents)

Confirmed from the Unified Patents citation record for US-6798786-B1 (https://portal.unifiedpatents.com/patents/patent/US-6798786-B1) and mirrored on Google Patents. Dates are as reported there and on the individual patent pages; I flag where sources disagree.

Every reference here has a US filing date before 1999-06-07, so each is at least § 102(e) prior art regardless of when it issued.

2. Per-reference analysis

Reference 2 — US 5,870,561 A (Novell) — the most probative reference

• Full citation: U.S. Patent No. 5,870,561, "Network traffic manager server for providing policy-based recommendations to clients," filed Mar. 15, 1996, issued Feb. 9, 1999. (Unified/Google list priority as 1996-03-14.)
• Description: A policy-driven network traffic manager server. Application programs, before generating traffic, call the server and describe the proposed traffic; a policy repository stores policies including "time, link cost, latency, congestion and availability"; the server returns a recommendation on whether/when the client should generate the traffic. (RPX record: https://insight.rpxcorp.com/patent/[US5870561A](/patent/US5870561A))
• § 102 mapping: Discloses (a) determining usage/conditions of the network and (d) applying a usage policy set by a separate policy server — the exact "usage policy set by a policy server" limitation of claim 1.
• Does it anticipate? No single-reference anticipation of claim 1. It does not disclose receiving a call request for establishing a call between at least two network terminals, nor selecting one or more of a plurality of resource elements (codecs/packet sizes) that define characteristics of the data exchanged between the terminals. The '561 patent recommends whether traffic should be generated, not which codec/packet size to use for a call.
• Best use: Primary § 103 reference for the "policy server" element of claim 1 and of any claim reciting policy-based gating. Not anticipatory alone.

Reference 9 — US 6,356,545 B1 (Clarent) — the most probative "resource element" reference

• Full citation: U.S. Patent No. 6,356,545 B1, "Internet telephone system with dynamically varying codec," filed Dec. 12, 1997 (priority Aug. 8, 1997), issued Mar. 12, 2002.
• Description: The voice port dynamically changes codec algorithms, packet size, and packet bundling on a packet-to-packet basis in response to a voice-quality/network measurement, to adapt to changing Internet conditions. (RPX: https://insight.rpxcorp.com/patent/[US6356545B1](/patent/US6356545B1))
• § 102 mapping: Discloses selecting codec / packet size / bundling (i.e., resource elements defining data characteristics) based on network conditions — the substance of claim 1's "selecting … resource elements … based on usage information."
• Does it anticipate? No as to claim 1, because claim 1 requires the selection be "based on usage policy set by a policy server," and the '545 patent performs the change at the endpoints (voice ports/gateways) on a self-measured quality basis — no separate policy server. It also changes codecs mid-stream rather than selecting candidates at call setup.
• Best use: Strong § 103 reference against the resource-element-selection aspect; would anticipate a hypothetical narrower independent claim that omitted the policy-server limitation, but I cannot confirm any such independent claim exists (the confirmed claim 1 contains the policy-server clause).

Reference 15 — US 5,115,429 A (Motorola) — earliest "usage → rate" teaching

• Full citation: U.S. Patent No. 5,115,429, "Dynamic encoding rate control minimizes traffic congestion in a packet network," filed Aug. 1, 1990, issued May 19, 1992.
• Description: Dynamically controls encoding rate (a resource characteristic) in response to packet-network congestion.
• § 102 mapping: Maps to claim 1 elements "determining usage information of the data network" (congestion) and "selecting … resource elements … based on usage information" (encoding rate).
• Does it anticipate? No. It is not call-oriented (no "call request … between at least two network terminals"), does not select codec/packet-size candidates, and has no policy server.
• Best use: § 103 — evidence that adjusting a coding parameter based on measured congestion was known well before 1999.

Reference 8 — US 6,426,955 B1 (Transnexus) and Reference 3 — US 5,889,774 A (ITXC)

• Full citations: US 6,426,955 B1, "Internet telephony call routing engine," filed Sep. 15, 1997, issued Jul. 30, 2002; US 5,889,774 A, "Method and apparatus for selecting an Internet/PSTN changeover server for a packet based phone call," filed Mar. 13, 1997, issued Mar. 30, 1999.
• Description: Both select a network element (gateway/routing engine) for an Internet phone call based on criteria (e.g., cost/quality/availability).
• § 102 mapping: Touch the idea of selecting among available network resources for a call, which is the broadest framing of claim 1's "selecting … resource elements."
• Does it anticipate? No. Their "resources" are routing/gateway nodes, not codecs or packet sizes that define characteristics of the data exchanged between terminals as claim 1 requires; neither uses a policy server.
• Best use: § 103; also useful § 102(b)/102(e) background showing call-time resource selection was known.

Reference 4 — US 6,477,143 B1 ("congestion avoidance and control")

• Full citation: filed Jan. 24, 1998, issued Nov. 5, 2002.
• Description: Packet-network congestion avoidance/control (monitoring and reacting to network conditions).
• § 102 mapping: Supports "determining usage information of the data network."
• Does it anticipate? No. No call setup, no codec/packet selection, no policy server. § 103 only.

References 11 — US 6,501,736 B1 (Nokia) and 16 — US 6,463,044 B1 (LG) — admission/load-control cluster

• Full citations: US 6,501,736 B1, "System for increasing the call capacity of a wireless communication system," filed Mar. 18, 1999, issued Dec. 31, 2002; US 6,463,044 B1, "Traffic load control for CDMA mobile communication system," filed May 3, 1998, issued Oct. 8, 2002.
• Description: Load/capacity management and call admission in wireless systems.
• § 102 mapping: Relevant to the "communities"/call-admission independent aspect (deciding whether to admit a call based on usage/load).
• Does it anticipate? Not the community-link aspect. Neither discloses the claimed community-link thresholds (the L/M/N/T parameters applied to inter-community links). They are wireless capacity management, not packet-data-network community admission. § 103 at most; I cannot fully evaluate because I could not confirm the exact wording of the community-method independent claim.

Reference 12 — US 5,883,891 A (ICall/Mailsignal)

• Full citation: filed Apr. 29, 1996, issued Mar. 16, 1999.
• Description: Improving voice quality over the Internet by adapting transmission to network conditions.
• § 102 mapping: Adaptation of voice transmission parameters to network state; loosely relevant to the selection aspect.
• Does it anticipate? No. No policy server, no codec-candidate pruning at call setup. § 103.

Reference 10 — US 6,430,289 B1 (Microsoft)

• Full citation: "System and method for computerized status monitor and use in a telephone network," filed Apr. 12, 1999, issued Aug. 6, 2002.
• Description: Monitoring status/state information in a telephone network.
• § 102 mapping: Monitoring/status — touches "determining usage information."
• Does it anticipate? No. § 103 only.

References 1, 5, 6, 7, 13, 14, 17, 18 — background/architecture cluster

• US 5,526,353 A (Henley), filed 1994-12-20, issued 1996-06-11 — packet audio transport with position-identifier buffering, interpolation/decimation to compensate for variable transmission delay (https://patents.google.com/patent/US5526353). Discloses the problem (time-sensitive audio over packet networks) that the '786 patent addresses; anticipation of any claim? No.
• US 6,069,890 A (Internet telephone service), filed 1996-06-25, issued 2000-05-30; US 6,426,942 B1 (Establishing a call connection, Alcatel), filed 1997-10-16, issued 2002-07-30; US 5,953,322 A (Cellular internet telephone, Qualcomm), filed 1997-01-30, issued 1999-09-14; US 6,222,829 B1 (IP telephony for a mobile station, Ericsson), filed 1997-12-22, issued 2001-04-24; US 5,907,610 A (Networked telephony central offices, Qwest), filed 1996-01-10, issued 1999-05-25; US 5,828,666 A (Access to telecommunications networks in multi-service environment), filed 1995-08-16, issued 1998-10-27; US 6,373,835 B1 (Phone call over an Internet connection, Spice i2i), filed 1997-08-12, issued 2002-04-16.
• § 102 mapping: All are architecture/telephony-connectivity background. They collectively establish that packet telephony, gateways, and call setup were known, but none discloses the combination of (i) usage information, (ii) call-request-driven selection of codec/packet-size resource elements, and (iii) policy-server-set usage policy. No anticipation; § 103/background only.

3. Non-patent literature cited (for completeness)

Cited alongside the patents (per Unified/Google): Y. Bernet et al., A Framework for End-to-End QoS Combining RSVP/Intserv and Differentiated Services (IETF Internet Draft, Mar. 1998); DataBeam, A Primer on the H.323 Series Standard (v2.0); IBM, ATM Overview (1995); Trillium, IP Quality of Service White Paper (Apr. 17, 1998); J. Toga et al., Demystifying Multimedia Conferencing Over the Internet Using the H.323 Set of Standards, Intel Technology Journal (Q2 1998); The Applied Technologies Group, Wireless Enterprise Networking (1998); and RFC 2205 (RSVP, Braden et al.). These are § 102(b) printed publications usable for obviousness in combination with the patents above (e.g., Bernet/RSVP for policy-based QoS, H.323 primers for the negotiation flow).

4. Synthesis — most relevant prior art and § 102 posture

Bottom line: I found no single cited reference that anticipates (§ 102) claim 1 as issued, and I have no confirmed basis to find anticipation of the other independent claims. The cited set reads as a § 103 obviousness collection, which is consistent with the pre-AIA prosecution of a patent that issued without applicant amendments to claim 1's core.

Ranked relevance to the '786 claims:

1. US 5,870,561 (Novell) — closest to claim 1's "usage policy set by a policy server" and "based on usage information." Missing: call request between network terminals and codec/packet-size resource-element selection. → Primary § 103 reference; not anticipatory alone.
2. US 6,356,545 (Clarent) — closest to the resource-element selection substance (codec, packet size, bundling chosen per network/quality conditions). Missing: the policy server, and it operates packet-to-packet, not as call-setup candidate selection. → Primary § 103 reference; no § 102 for claim 1.
3. US 5,115,429 (Motorola) — earliest teaching of adjusting an encoding parameter in response to measured congestion. → § 103; no call/policy-server elements.
4. US 6,426,955 (Transnexus) and US 5,889,774 (ITXC) — call-time selection among network elements for an Internet call. → § 103; the "elements" are gateways/routes, not codecs/packet sizes.
5. US 6,477,143, US 5,883,891, US 6,430,289 — congestion/quality monitoring and adaptation. → § 103 support for "determining usage information."
6. US 6,501,736 (Nokia), US 6,463,044 (LG) — load-based call admission. → Possibly § 103 against the community/call-admission independent aspect; I could not fully test against that claim's actual language.
7. Background cluster (US 5,526,353; 6,069,890; 6,426,942; 5,953,322; 6,222,829; 5,907,610; 5,828,666; 6,373,835) — architecture/setup context; no anticipation of any confirmed claim.

A useful § 103 combination example the examiner's art set supports: US 5,870,561 (policy server gating traffic) + US 6,356,545 (dynamically selecting codec/packet size by network condition) + a call-setup reference (US 6,426,955 or US 6,426,942) → the claim 1 combination. This is an obviousness theory, not anticipation.

5. Caveats and confidence

• Claim coverage limitation: Only claim 1 was retrieved verbatim (Official Gazette 1286-4). The community/call-admission independent claim and the apparatus/system independent claim are known only at SUMMARY level, so my § 102 conclusions for them are provisional. If you can supply the full 32-claim text, I can complete true element-by-element anticipation charts.
• Date provenance: Filed/issued dates are as reported by Google Patents/Unified Patents and cross-checked where possible; I did not obtain certified USPTO file-wrapper or PACER records, and one minor discrepancy exists (US 5,870,561 listed as filed 1996-03-14 vs 1996-03-15 across sources).
• "Anticipates" is a legal conclusion. Nothing here should be treated as an adjudicated § 102 determination; it is a technical mapping of disclosures to claim elements.
• No auto-correction: patent numbers, dates, and titles are reported literally as found.

I'll verify the prior-art references before building the § 103 combinations.

Good — key finding: the EP search report for the family member cites US 5,870,561 as "XY" and WO 99/23799 as "Y". Let me verify the remaining references.

Obviousness Analysis — U.S. Patent No. 6,798,786 under 35 U.S.C. § 103

Prepared: 2026-09-28 · Patent: US 6,798,786 B1, "Managing calls over a data network" (Lo, Li, Abaye; filed 1999-08-20; § 119(e) priority to Prov. 60/137,877 filed 1999-06-07; issued 2004-09-28)
Statute: pre-AIA § 103(a) — the effective filing date precedes 2013-03-16, so KSR/Graham govern and no AIA obviousness provisions apply.

0. Threshold flags before the analysis

0.1 — Claim-set contradiction (unresolved; carried forward, not papered over).
The previously generated sections are internally inconsistent on the claim set:

These cannot both be complete and correct as stated. I am not resolving it. The § 103 analysis below is anchored on the issued claim 1 text as reprinted in the OG, which the prior section reproduced verbatim and which is the only claim text I can treat as authoritative. All dependent-claim treatment is expressly marked as secondary-source-dependent and must be re-verified against the certified copy before it goes in a contention.

0.2 — A new prior-art reference surfaced that is not in the earlier prior-art list.
The EPO search report for the family member EP 1 079 573 A3 (published 2003-04-16), retrieved at http://data.epo.org/gpi/EP1079573A3, cites exactly three references against the same disclosure:

• [XY] US 5870561 A (Jarvis, Novell) — 1999-02-09
• [Y] WO 9923799 A1 (British Telecommunications) — 1999-05-14
• [A] US 5828666 A (Focsaneanu) — 1998-10-27

WO 99/23799 A1 is absent from the earlier prior-art list and is a material omission from the § 103 picture. I could not verify its disclosure in this session (search budget exhausted) — flag as unverified content, verified citation.

0.3 — Verification status of the reference list. I re-verified the full text/claims of US 5,870,561, US 6,356,545, US 6,426,942, US 6,426,955, US 6,069,890 this session. I did not verify the disclosure of US 5,889,774; US 5,953,322; US 5,907,610; US 6,222,829; US 5,883,891; US 5,115,429; US 6,477,143; US 6,430,289; US 6,501,736; US 6,373,835; US 6,463,044; US 5,828,666. Where I cannot ground a statement in verified text, I say so rather than characterize the reference.

1. The claim to be invalidated, element by element

Claim 1 as reprinted in OG 1286-4 (authoritative for this analysis):

"1. A method of managing calls over a data network, comprising:
[A] determining usage information of the data network;
[B] receiving a call request for establishing a call between at least two network terminals; and
[C] selecting one or more of a plurality of resource elements as candidates for use in the requested call in response to the call request based on usage information of the data network, wherein the resource elements define one or more characteristics of data exchanged between the network terminals,
[D] wherein the selecting includes selecting one or more resource elements based on usage policy set by a policy server."

Element [D] is the only limitation that distinguishes this claim from the ordinary 1997–1999 VoIP codec-negotiation art, and it is the element on which the whole § 103 case turns. Note also the abstraction level: element [C] says "resource elements … define one or more characteristics of data exchanged," which the specification expressly ties to codec and frames-per-packet / packet size (see FIGS. 2–5 and the packet-size discussion). It is not limited to a specific selection algorithm, not limited to network-monitor querying, and not limited to any particular ranking scheme.

What claim 1 does not require (per the earlier summary, and I agree): any network-monitor query; the H.323 two-party negotiation flows; the merit factor M = W_Q·Q + W_B·B + W_R·R; the E-model R-value charts; mid-call re-selection; or the community thresholds.

POSITA — proposed definition. For a 1999 priority date: a person holding a B.S. in electrical engineering or computer science (or equivalent) with 2–4 years of experience in packet-switched telephony and network resource management, conversant with ITU-T H.323, the ITU-T G-series codecs (G.711/722/723.1/728/729/729A), RTP/RTCP (RFC 1889/1890), IP, and call/connection admission control. I state this as a proposal; it should be conformed to the court's construction.

2. The reference-by-reference foundation

3. Ground 1 (primary): Jarvis '561 + Vargo '545

This is the combination I would lead with, because it is a two-reference combination in which each reference supplies a complete conceptual half of claim 1, and both are analogous art in the same field.

Why the POSITA would have combined them (the motivation, stated for the record)

1. Same field, same problem, same period. Both address the 1997–1999 engineering problem of running time-sensitive traffic over a best-effort packet network shared with bulk data. Vargo's specification frames it as adjusting codec/packetization "for Internet conditions"; the '786's own background frames the identical problem. Analogous art is presumed combinable (In re Clayton; MPEP 2141.01(a)).
2. Art-recognized deficiency of the endpoint-local approach supplies the "improvement" rationale (MPEP 2143(C)). Vargo's mechanism is end-point/gateway-local and reacts to measured voice quality. Jarvis supplies precisely what Vargo lacks: a network-operator-controlled authority that can constrain whether and in what form the traffic is generated, based on administrative policy rather than the endpoint's own measurement. The '786 itself describes the same architectural choice — a separate policy server (18) that "may set the telephony usage of the data network 20 for different time periods," including "a low usage target for telephony communications" during "business hours." A POSITA seeking operator control over VoIP usage would not have needed to invent this; Jarvis already handed it over, and Jarvis's own time-of-day cost model maps directly onto the '786's "different time periods" teaching.
3. Predictable result (MPEP 2143(A)). Wiring a policy lookup into a call-setup path is a combination of known elements according to their established functions — Jarvis's policy server returning an admissibility/"what may be sent" decision, and Vargo's voice port executing the resulting codec/packet-size choice. No new physical result, no change in principle of operation. Under KSR, "the combination of familiar elements according to known methods is likely to be obvious when it does no more than yield predictable results," 550 U.S. at 416.
4. Design incentive / finite solution space (MPEP 2143(E) & (F)). The set of candidate codecs in 1999 was small and enumerated (G.711, G.722, G.723.1, G.728, G.729, G.729A — the '786 itself enumerates exactly this list), and frames-per-packet was a discrete set (10/20/40 ms). Choosing among them by consulting a policy on network usage is "choosing from a finite number of identified, predictable solutions," which KSR treats as evidence of obviousness.

The § 102 date problem you must plan around (important)

Jarvis is § 102(a)-class art, not § 102(b). It issued 1999-02-09 — after 1998-08-20. That means the patent owner can attempt to antedate it under 37 C.F.R. § 1.131, and — critically — the 1999-06-07 provisional does not help them: 1999-06-07 is later than 1999-02-09. To swear behind Jarvis, the inventors would need corroborated evidence of actual prior invention (conception plus diligence, or actual reduction to practice) before 1999-02-09. That is a factual fight worth forcing.

Practical consequence: do not build the entire invalidity case on Jarvis alone. Run a parallel § 102(b) ground (art published before 1998-06-07, i.e., more than one year before the earliest asserted date) that does not depend on the policy-server timing. The previously listed references US 5,115,429 and US 5,883,891 are the most likely § 102(b) anchors and I could not verify them here — that verification is the single highest-value next step.

4. Ground 2: Jarvis '561 + Vargo '545 + Dalton '955

Adds Dalton to dispose of any reading of [D] that requires the policy server to be a distinct network element from the endpoint and to rank the surviving candidates.

• Dalton's routing engine is a third-party policy server with operator-authored "preferences" and "preference criteria," one of which is "the maximum delay that will be tolerated for the call" — i.e., a usage/QoS policy that prunes the set of eligible call terminations. That is the same function as the '786's policy server 18 pruning the candidate list.
• Dalton expressly returns a "prioritized list," which covers the '786's ranking step (the M = W_Q·Q + W_B·B + W_R·R computation) at the level of the concept; weighted linear scoring against figure-of-merit attributes was a familiar optimization technique, and where the result is a mere selection among known values of a "result-effective variable," the specific weights are an obvious design choice (In re Boesch; In re Aller). The '786's own weights — W_Q=(1−t)·0.8, W_B=t, W_R=(1−t)·0.2 — are a smooth interpolation between "quality matters when idle" and "bandwidth matters when busy," which is exactly the trade-off the POSITA was already managing.
• Motivation: Dalton's engine and Jarvis's traffic manager are two implementations of the same architectural idea (a centralized authority that constrains calls per operator policy), and a POSITA implementing the '786's call server would naturally borrow from both. Note also that both Dalton and the '786 rely on time-of-day as a policy axis.

Caveat: Dalton's policy is directed at gateway/route selection, not codec selection. The patent owner will argue this is a different decision. The response is that element [D] is expressed generically ("usage policy set by a policy server") and the specification itself says the policy server's output "may be in the form of information identifying resource elements that are supported or not supported at the present time" — a generic policy-pruning function, not a codec-specific one.

5. Ground 3 (independent, avoids Jarvis entirely): Vargo '545 + Sienel '942 + Dalton '955 (+ Bernet/RFC 2205)

For the event the § 1.131 antedating fight on Jarvis is lost or the file history shows the examiner allowed over Jarvis:

Motivation: Sienel and Vargo solve the same problem from two directions (network-condition-driven codec/bearer choice vs. voice-quality-driven codec choice); a POSITA would plainly consult both when building a call server that must reduce per-call bandwidth under load. Adding a policy authority to that decision is the known technique of admission/policy control applied to a known device ready for improvement (MPEP 2143(D)), and RFC 2205/Bernet put policy-controlled QoS squarely in front of the 1998–1999 POSITA in the very protocol stack (IP/Intserv/Diffserv) the '786's own specification invokes.

Evidentiary caveat: I did not re-verify RFC 2205's or the Bernet draft's text this session, and their citation in the earlier prior-art list should be independently confirmed (including public-accessibility for the Bernet draft, to establish it as a "printed publication").

6. The EPO search report as formal, third-party motivation evidence

This deserves separate emphasis because it is the strongest single evidentiary artifact located so far. The EPO examiner, examining the same specification, categorized US 5,870,561 alone as [XY] — meaning the examiner considered it relevant both to novelty and to inventive step — and paired it with WO 99/23799 [Y]. A foreign search report is not binding on a US court, but it is powerful corroboration of exactly the proposition this analysis asserts: that a person of ordinary skill, with the '786 disclosure in hand, would regard the policy-server-driven resource-allocation concept as not inventive. It also independently confirms the Jarvis reference as the primary art of record for this family and confirms US 5,828,666 as background art.

7. Other claims and other disclosed features (secondary-source dependent)

Per the earlier summary's caveat, I cannot confirm which of these are actually claimed. Assuming the freepatentsonline listing (claims 1–15; independents 1, 2, 3, 5, 8, 11, 12, 15) is directionally right, the additional subject matter maps as follows:

8. Rationale catalog (mapped to MPEP 2143)

• (A) Known elements combined per known methods → predictable results: Grounds 1–3, principally for [A]+[B]+[C].
• (C) Known technique improving similar devices in the same way: endpoint-local Vargo policy → centralized Jarvis policy server; the '786's own motivation.
• (D) Known technique applied to a known device ready for improvement: policy/admission control applied to a VoIP codec-selection gateway.
• (E) Finite number of identified, predictable solutions: enumerated G-series codec set; discrete 10/20/40 ms frames-per-packet; enumerated bearer choices in Sienel.
• (F) Design incentives / market forces: the '786's background itself recites the incentive — "Voice data sent over a data network has to share the network bandwidth with conventional non-voice data."
• (G) TSM from the references and from third-party examination: the EPO search report supplies an external, contemporaneous motivation finding on this very disclosure.

9. Anticipated rebuttals, and the answer to each

10. What is still open — prioritized

1. Obtain the certified claim set. Resolve the 32-claim vs. 1–15 contradiction (§ 0.1). Nothing in this analysis should be filed until claim 1's issued text is confirmed against the USPTO certified copy.
2. Pull the US file wrapper for 09/370,984. Determine whether Jarvis '561 was applied, cited-but-distinguished, or merely listed; capture any applicant statement about the policy-server limitation (potential prosecution-history disavowal, which helps the defendant).
3. Verify the four unverified-but-likely-critical references: US 5,115,429 and US 5,883,891 (potential § 102(b) anchors — would insulate the case from the § 1.131 fight), WO 99/23799 A1 (the EPO's [Y] reference), and the G.107 E-model publication date.
4. Locate a hierarchical / LAN-to-WAN admission-control reference covering "communities" and per-link L/M/N thresholds. This is the only claim feature for which I cannot presently state a clear § 103 position.
5. Confirm § 102(e) status of Vargo '545, Sienel '942 and Dalton '955 (US filings 1997-12-12 / 1997-10-17 / 1998-09-16 — all before 1999-08-20) and confirm no pre-AIA § 103(c) common-ownership disqualification with Nortel. Clarent, Alcatel, Transnexus and Bell Atlantic show no obvious common ownership with Nortel Networks, but this must be checked in USPTO assignment records rather than assumed.
6. Note the family-member overlap. US 7,260,060 ("Call admission control," application 09/577,292) is in the same family and its claims 33–46 recite "select[ing] one of the one or more network resources as a resource candidate for use in the requested call" and "based on a usage policy of a policy server," plus ranking "according to a merit rating." That is evidence about how the applicant itself split the two SUMMARY aspects — and it raises a double-patenting / obviousness-type double-patenting question worth exploring if the '060, rather than the '786, is asserted. (Note: the earlier section recorded a Google Patents "priority to US09/577,292" link on the '786 page; a later-filed application cannot be a priority document for an earlier patent, so that listing appears to be a Google Patents data artifact. Flagging rather than resolving.)

11. Bottom line

Claim 1 as issued is, on the present record, obvious under pre-AIA § 103(a) over Jarvis '561 in view of Vargo '545, with Dalton '955 as a third reference to close any reading of the "policy server" and "ranking" limitations. The single most load-bearing limitation — "selecting … based on usage policy set by a policy server" — is squarely and independently disclosed by Jarvis, which is a policy server reading policies from a repository and returning an admissibility/"what may be sent" decision. Vargo supplies codec and packet-size selection driven by network conditions. The EPO examiner reached the same conclusion about the same disclosure against the same primary reference.

The two genuine weaknesses are (i) Jarvis's date posture — § 102(a)-class only, and not antedatable via the 1999-06-07 provisional — and (ii) the community/threshold feature, for which I have not verified a clean reference. Both are addressable, and items 3–4 of § 10 are the work to do.

Verification note. Grounded on: Google Patents full text of US 6,798,786 (https://patents.google.com/patent/US6798786/en); OG 1286-4 claim 1 as transcribed in the earlier section; USPTO/EPO full text of US 5,870,561 (https://patents.justia.com/patent/[5870561](/patent/5870561), https://patents.google.com/patent/[US5870561A](/patent/US5870561A)), US 6,356,545 (https://insight.rpxcorp.com/patent/[US6356545B1](/patent/US6356545B1), https://patents.justia.com/patent/[6356545](/patent/6356545)), US 6,426,942 (https://patents.google.com/patent/US6426942), US 6,426,955 (https://patents.google.com/patent/US6426955/en), US 6,069,890 (https://patents.google.com/patent/[US6069890A](/patent/US6069890A)); and the EPO family search report at http://data.epo.org/gpi/EP1079573A3. I did not verify WO 99/23799's disclosure, US 5,828,666's disclosure, RFC 2205, the Bernet IETF draft, ITU-T G.107's publication date, or the twelve references listed as unverified in § 0.3. Where I have not verified a reference's text, I have said so rather than characterize it.