US 6772205

I'll search for current litigation/docket information on this specific patent number before summarizing.

Let me run additional targeted searches on the docket and assignment history.

One more round of searches to check for any litigation history or PTAB activity.

US 6,772,205 B1 — Summary

Sourcing note: The bibliographic and full-text details below come from the patent document itself (Google Patents rendering at https://patents.google.com/patent/US6772205/en, fetched 2026-09-24). I ran targeted searches against public litigation/docket aggregators and the USPTO/PTAB-facing sources I could reach for this exact number ("6772205" and "6,772,205"). I found no CAFC 2026 docket entry, no PTAB/IPR proceeding, and no infringement suit asserting this specific patent. I cannot rule out an unreported or non-indexed matter, so treat the "no litigation found" statement as a search result, not a verified absence.

---

1. Bibliographic data

Priority chain: This patent is a continuation-in-part of US 09/522,332 (issued as US 7,433,941 B1, "Method and apparatus for accessing network information on a network device," filed 2000-03-09), which claims benefit of provisional US 60/124,047, filed 1999-03-12. Note that 1999-03-12 is the provisional's date; substantive support for the proxy-conversion subject matter in a CIP would ordinarily be measured from the CIP's own 2000-08-08 filing unless it is present in the earlier filings. That is my analysis, not something the face of the document states.

Family / foreign: AU counterpart AU3740500A (listed as not active / abandoned). PCT work appears in the file as PCT/US00/06479 (International Search Report dated 2000-08-17).

Term/status caveat: The record is internally inconsistent on expiry. The legal events list a maintenance-fee reminder (2016-03-11) followed by lapse for failure to pay maintenance fees (2016-08-03), status "patent discontinued" (2016-08-29) and "Lapsed due to failure to pay maintenance fee" (2016-09-20). Separately, the front-page metadata shows "Adjusted expiration 2021-07-11" and "expires 2021-07-11." The fee lapse in 2016 is the operative event for enforceability; the nominal 20-year/PTA date ending ~2021 is moot. Prefer the legal-events record.

Prosecution references cited: EP 0 831 617 A2; US 5,911,776; US 5,961,595; US 6,055,243; US 6,058,103; US 6,292,829; US 6,337,601; US 6,487,590. Non-patent: Covaci et al. (1997), Liotta et al. (1998), Susilo et al. (1998).

---

2. Abstract (as printed)

A method processes an object-oriented application on a target network device by identifying a proxy network device capable of processing the object-oriented application, transmitting the object-oriented application to the proxy network device, generating one or more non-object-oriented instructions using the proxy network device corresponding to the object-oriented application, and transmitting the non-object-oriented instructions generated using the proxy network device to the target network device for processing. A corresponding system is also described.

---

3. Plain-language overview of each independent claim

Claim 1 — Method (proxy conversion, capability gate).
A network management server (NMS) performs object-oriented network management processing to determine use of network resources on networked devices. It determines whether the target device can process the object-oriented management application. If it cannot, the NMS: (a) identifies a proxy device (also on the network) that can process it, (b) sends the application to the proxy, (c) the proxy generates non-object-oriented network management instructions corresponding to the application, and (d) the proxy sends those instructions to the target device for processing. Mechanism: compile/invoke the app where the runtime exists, and drive a legacy device with primitive commands.

Claim 2 — Method (adds the load-the-application request and the direct path).
Same as claim 1, plus: the NMS first requests that the target device load the application and perform at least some of the management processing; and the claim explicitly branches — if the target is capable, the application is sent to the target for processing; if not, the proxy route above is used. This is the fullest method formulation and is the parent for dependent claims 3–12.

Claim 13 — Apparatus (server + processor + memory instructions).
The claim-2 logic implemented as a machine: an NMS with a processor and memory holding instructions that transmit the load-request, make the capability determination, and then either send the application to the target or to a proxy that converts it into non-object-oriented instructions forwarded to the target.

Claim 19 — Apparatus in "module for" form.
The same steps of claim 2, but recited as a set of functional modules (module for performing NMS processing; module for transmitting the load request; module for determining capability; module(s) for the direct-send path; module for identifying a proxy; module for transmitting to the proxy; module for generating non-object-oriented instructions; module for transmitting them to the target). Functionally a parallel rendering of claim 2 drafted to cover module-based/software architectures.

Claim 20 — Computer program product.
A program tangibly stored on a computer-readable medium whose instructions cause a programmable processor to perform the claim-2 steps (NMS processing, load request to target, capability determination, direct-send or proxy-convert-and-forward).

Claim 21 — Apparatus in "means for" form.
The claim-2 steps recited as means-plus-function elements. Notably, the generating step is recited as "means for generating one or more non-object-oriented network management instructions using the proxy network device," i.e., the proxy is named inside the means element.

Claim 22 — System.
A combination claim: (i) an NMS performing object-oriented network management processing; (ii) a target network device that can process non-object-oriented network management instructions and send information across a network; (iii) a proxy network device that can process object-oriented instructions and convert them into non-object-oriented instructions the target can process; and (iv) the network that carries the converted instructions from proxy to target so the target generates information corresponding to the results the object-oriented application would produce. This is the system-level counterpart of claim 1 and does not recite the capability-determination or identify-proxy steps as such.

---

4. Notable dependent claims (context for scope)

• Locale selection (3–6): the proxy is chosen by "locale criteria," including relative geographic distance (claim 4), measured processor capabilities (5), or comparison of load across proxies (6).
• Capability determination (7): made by accessing stored information describing the target device's features.
• Proxy mode (8–9): a determination that target and proxy are in "proxy mode," supported by searching stored information about both devices.
• Protocol (10): the non-object-oriented instructions are SNMP-compatible.
• Trigger condition (11–12): proxy mode is used when the stored info indicates the target lacks a virtual machine for executing object-oriented bytecodes, and those bytecodes are Java-compatible.

---

5. Drafting/consistency flags (literal readings, no auto-correction)

• Claim 4 recites "the local criteria" where claim 3 and claims 5–6 use "locale criteria." Read literally, that is a wording inconsistency between a dependent claim and its parent.
• Claim 16 contains the phrase "non-object oriented network management commands instructions."
• The FIG. 8 description states "Target network device 806 cannot process non-object-oriented instructions," which contradicts the rest of the specification (the target is by definition the device that processes SNMP/non-object-oriented commands). This appears to be a typographical inversion in the printed document; I am reporting it rather than correcting it.
• Claim 1 lacks the "request the target device to load the application" step present in claims 2, 13, 19, 20 and 21 — claims 1 and 22 are the broader, differently-scoped independent claims.

---

6. What I could not confirm

• No verified litigation or CAFC activity in 2026 for US 6,772,205. The Rockstar Consortium / Constellation / RPX "Nortel portfolio" litigation I did locate (e.g., Google v. Rockstar Consortium US LP, N.D. Cal. 5:13-cv-05933; the E.D. Tex. "Halloween actions" against ASUS, HTC, Huawei, LG, Pantech, Samsung, ZTE) asserted other Nortel patents (e.g., 5,838,551; 6,037,937; 6,128,298; 6,333,973; 6,463,131; 6,765,591; 6,937,572; 6,128,649; 6,845,389; 6,901,048) — not this number.
• I could not directly query USPTO Patent Center or the CAFC oral-argument/opinion dockets within this session; the status data above is from the patent record and public aggregators.

I'll research litigation involving US patent 6772205 (the "Executing applications on a target network device using a proxy network device" patent, originally assigned to Nortel Networks, later RPX Clearinghouse LLC).

Let me search the litigation databases directly.

Let me try more targeted searches on litigation-tracking sites.

Litigation Search Results: US Patent 6,772,205

Bottom line

I could not identify any known litigation specifically asserting US Patent 6,772,205 in the sources I was able to search. I want to be explicit about the limits here: my searches did not surface a docket, complaint, or case caption naming this patent as an asserted patent, but I also was unable to fully load/query the litigation-specific databases (Unified Patents portal, Docket Alarm, PACER, CourtListener, RPX) with a clean, confirmed "no results" response for this exact number. So treat the finding as "no litigation found in the searches performed" rather than a verified negative.

What I searched and found

• "US patent 6772205 litigation" – returned only a non-legal patent profile page (TelecommNet) and unrelated results; no docket or case.
• "6772205" patent lawsuit defendant – no relevant litigation; hits were false positives (e.g., a Lithuanian company registry "Pranešimo Nr. 6772205," unrelated to the patent).
• RPX Clearinghouse / Rockstar / Nortel patent 6772205 – surfaced extensive background on the Rockstar portfolio acquisition (see below) but no case asserting '205.

No case caption, plaintiff, defendant, jurisdiction, case number, filing date, or outcome for US 6,772,205 was found.

Relevant context from the patent record (not litigation)

The patent's prosecution/ownership history is well documented and helps explain why assertion litigation is unlikely:

Several points bear on litigation risk/activity:

1. RPX Clearinghouse is a defensive patent aggregator. When RPX Clearinghouse completed its purchase of the Rockstar patents (announced Feb. 3, 2015), RPX stated it would make the assets available "for license to all other interested companies under fair, reasonable, and non-discriminatory (FRAND) terms," and that eight litigations against 16 companies would be dismissed, including cases against Cisco and Google. Those dismissals were of pre-existing Rockstar-initiated suits; there is no indication in the material I retrieved that '205 itself was the patent-in-suit.
2. The patent lapsed for failure to pay maintenance fees in 2016 and shows a current status of "Expired – Fee Related." A lapsed/expired patent is generally not a viable subject for an ongoing infringement action.

Why I could not confirm a definitive negative

• The Unified Patents litigation caselist, PACER, CourtListener/RECAP, and Docket Alarm pages did not return a clean, loadable result tied to this exact patent number in my searches; several queries timed out or returned only tangential PTAB/RPX material.
• Note that none of the "Cited By," "Citations," "Family," or "Legal Events" sections in the Google Patents record for '205 lists any litigation (Google Patents typically lists litigated patents with a "Litigation" section — its absence here is consistent with, but not proof of, no litigation).

Recommendation for a definitive answer

To confirm conclusively whether '205 was ever asserted, I'd recommend running the number directly in these litigation databases (which I could not fully query here):

• Unified Patents litigation caselist – portal.unifiedpatents.com/litigation
• Docket Alarm – docketalarm.com (search by patent number)
• CourtListener/RECAP – courtlistener.com
• PACER – for any district court docket
• RPX's own litigation data (as current assignee coinciding with the Rockstar acquisition)

If those return nothing, the correct characterization is: no known litigation involving US Patent 6,772,205. I did not find any, and I am not aware of any, but I cannot certify the negative as verified.

I'll verify the structured block's "no proceedings" signal against public sources before concluding.

Initial results are noise from unrelated patents. Let me target the patent by title and check known litigants/aggregators.

Let me run more targeted queries on the exact patent number variants and known aggregator databases.

Proceedings overview

Zero AIA trial proceedings on file. The canonical structured block states the USPTO Open Data Portal returns no AIA trial proceedings for US 6,772,205, and my independent web checks corroborated that: I found no IPR, PGR, or CBM petition, no institution decision, no Final Written Decision, and no Federal Circuit appeal involving this patent. That means the defensive posture is not "the patent is hardened by surviving IPRs" and not "claims 1–5 are canceled" — it is a third, more favorable posture: all 22 claims are legally untested at the Board, but the patent has lapsed for nonpayment of maintenance fees (effective 2016-08-03) and is expired, so a demand letter citing any of claims 1–22 now reaches only past-damages exposure, not an injunction or ongoing royalty.

---

Per-proceeding detail

Not applicable — there are no proceedings to detail. Rather than pad this section with a fabricated docket, here is what I affirmatively verified:

No PTAB proceeding exists under this patent number. Searches on the exact number in multiple formats ("6772205", "US6772205", "6,772,205", "US 6,772,205") combined with IPR / PTAB / CBM terminology returned no petition or decision. The Google Patents page for US 6,772,205 likewise shows no PTAB proceeding entries in its "Legal Events" or "Cited By" tables, only re-assignments and maintenance-fee events.

Do not conflate the similarly numbered patents that did surface in search. My queries returned hits for patents whose numbers are visually or numerically close but legally unrelated — e.g. US 8,874,677 (a messaging patent challenged in a separate IPR, petitioner's brief served on Browdy and Neimark), US 6,721,705 (IPR2022-00279, Samsung), and US 6,502,135 / 7,921,211 (VirnetX, Kiuchi-based IPRs). None of these are US 6,772,205, and any defendant-facing memo that cites them as this patent's PTAB history would be wrong.

No CAFC appeal located. Because no Board decision issued, there is no appeal of a Board decision to the Federal Circuit. I could not rule out unrelated district-court litigation in which the patent was asserted; I found no evidence of one, and I am explicitly not asserting that none exists.

---

Strategic summary

Claim status: all 22 claims UNTESTED, and all now expired. No claim of US 6,772,205 has been canceled, confirmed, or construed by the PTAB. Claims 1–22 (independent claims 1, 2, 13, 19, 20, 21, 22 and their dependents) retain their issued scope as a matter of record — with one important qualification: the patent lapsed for failure to pay maintenance fees, with the lapse effective 2016-08-03 (USPTO event codes LAPS/STCH/FP; "PATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362"). Google Patents' header simultaneously labels the status "Expired – Fee Related" with an "adjusted expiration" of 2021-07-11, which appears to reflect the nominal PTA-adjusted term rather than the actual lapse. Flag this inconsistency in the record rather than relying on the 2021 date. Either way, the patent is not in force today.

Estoppel landscape: effectively empty. Because no IPR/PGR was ever instituted against this patent, 35 U.S.C. § 315(e)(2) estoppel never attached to anyone. No petitioner, real party in interest, or privy is barred from raising any § 102/§ 103 ground. For a defendant being asserted against today, the entire prior-art universe is open — including the eight references already cited on the face of the patent (US 5,911,776; US 5,961,595; US 6,055,243; US 6,058,103; US 6,292,829; US 6,330,601; US 6,487,590; EP 0 831 617 A2) plus the non-patent literature cited by the examiner (Covaci, Liotta, and Susilo mobile-agent papers, IEEE, 1997–1998) and anything else a competent searcher finds. Note that § 315(b)'s one-year bar is also irrelevant absent a served complaint; if a complaint has been served, that clock governs any petition you might file — though see below on why filing one is probably pointless here.

Pattern signals. Ownership track: Nortel Networks Ltd → Rockstar Bidco, LP (assignment effective 2011-07-29, recorded 2011-10-28) → Rockstar Consortium US LP → RPX Clearinghouse LLC (assignment effective 2015-01-28). RPX Clearinghouse is a defensive-aggregator vehicle, and its arrival in the chain of title is consistent with the patent being warehoused rather than actively asserted — which dovetails with the total absence of PTAB challenges. There is no Unified Patents participation in this patent's chain that I could find, and no serial-petitioner pattern, because there is no petitioner at all. The patent is pre-AIA (priority 1999-03-12 via provisional 60/124,047; CIP filed 2000-08-08), so it would also have been CBM-eligible only if it met the "financial product or service" and "technological invention" tests — a poor fit for network-management proxy technology even if the patent were still alive.

Family note. US 6,772,205 is a continuation-in-part of US 09/522,332 (US 7,433,941, "Method and apparatus for accessing network information on a network device," filed 2000-03-09, granted 2008-10-07). The prompt's structured block covers only the '205 patent; if the troll's portfolio includes the '941 parent, that patent needs its own PTAB check — I did not verify it here.

---

Recommended next steps

• Lead with expiry, not with prior art. If you are a defendant facing assertion, the threshold response is that US 6,772,205 lapsed effective 2016-08-03 for failure to pay maintenance fees and is not enforceable for ongoing conduct. Confirm the lapse via USPTO Patent Center (https://patentcenter.uspto.gov) and by retrieving the fee-history/transaction record, and pin the nominal-term inconsistency against the Google Patents page (https://patents.google.com/patent/US6772205/en) in your file.
• Cap the damages theory at six years of past conduct. With the patent expired and no PTAB proceeding in existence, there is no FWD to link and no disposition to quote — so the defense is not "claims canceled" but "35 U.S.C. § 286 lookback plus no injunctive exposure." There is also no § 315(e) estoppel record to mine, because no IPR occurred.
• Do not file an IPR reflexively. An IPR against an expired patent yields no meaningful commercial relief, and the Board has nevertheless adjudicated expired patents when a live controversy warranted it. Spend the budget on invalidity contentions and § 101/§ 112 positions in district court instead, where no estoppel or one-year bar constrains you.
• Verify the litigation record and standing chain directly. My searches surfaced no district-court assertion of this patent, but a negative search is weaker evidence than a docket check. Before relying on "no litigation," pull the assignment chain (Nortel → Rockstar Bidco → Rockstar Consortium US LP → RPX Clearinghouse LLC) in USPTO Assignment and confirm RPX Clearinghouse's current standing — and watch for any newly recorded transfer that revives assertion interest.
• Cross-check related patents. Run the same PTAB/expiry screen on the '941 CIP parent and any other Nortel-origin members of the same family, since a portfolio assertor may pivot to a sibling once the '205 patent's expired status is raised. PTAB decisions and E2E filings are public at https://www.uspto.gov/patents/ptab/decisions and https://ptacts.uspto.gov/ptabweb/, and any Federal Circuit opinions are docketed at https://www.courtlistener.com/.

Confidence. High that no AIA trial proceeding is on file for US 6,772,205, given the structured ODP block plus four corroborating search passes. Moderate on the precise lapse date mechanics (the record shows both an adjusted expiration of 2021-07-11 and a 2016 lapse — reconciled above in favor of the lapse). Lower on the absence of any past or present district-court assertion; that is a documented negative, not a verified one, and should be docket-checked before it is relied on.

I'll start by pulling what I can from public sources on this patent's chain and the key correspondents involved.

Let me dig into litigation history for this specific patent and the correspondents of record.

Ownership Reconstruction — US 6,772,205 B1

Patent: Executing applications on a target network device using a proxy network device
App. No. 09/634,046 · Filed 2000-08-08 · Granted 2004-08-03
Priority 1999-03-12 (Prov. 60/124,047; CIP of 09/522,332 → US 7,433,941 B1)
Assignee of record on issue: Nortel Networks Limited · Current assignee of record: RPX Clearinghouse LLC

Provenance note (read before using): the reel/frame numbers, execution dates and recording dates below are drawn from the USPTO assignment records as mirrored in the Google Patents legal-events table for this patent (https://patents.google.com/patent/US6772205/en). I was not able to open the Assignment Center UI itself in this session, and the correspondent-of-record field is not exposed in any mirror I could reach. Rather than guess at attorney names, that field is marked unresolved in Signal 3. Everything else below is sourced to a specific reel/frame or a cited public filing.

---

Inventors

Pattern notes. The confirmatory assignment on Reel 012288/0647 was executed after filing — signing dates 2000-12-10 to 2001-06-24 for an application filed 2000-08-08 (and a priority chain opening 1999-03-12). That is a late confirmatory/employment assignment, not a red flag by itself, but it does mean title was technically incomplete for roughly the first 17 months of prosecution.

I found no evidence that either inventor departed Nortel within 12 months of filing; the "all inventors exit early" pre-fire-sale pattern does not apply here. Both continued to appear on Nortel-originated filings for years (Lavian on US 7,317,608; US 8,782,230; US 6,972,054, etc., frequently with co-inventors such as Olivier Swedor and Robert F. Jaeger). Their current employment status is indeterminate from the sources available and I will not speculate.

---

Original assignee

Nortel Networks Limited (Canada) — recorded on Reel 012288/0647 as NORTEL NETWORKS LIMITED, CANADA. Google Patents' header renders the original assignee as "Nortel Networks Ltd"; the address-change recording at Reel 013046/0006 (2002-07-02) is the same entity and is administrative only. The variance is a naming/rendering difference, not a second assignee.

• Line of business: carrier-grade telecommunications and data networking equipment (switches, routers, optical, wireless) plus the Preside network-management product line. This patent sits squarely in Nortel's Java-enabled network-device / network-management-software work.
• Product embodying the claims: partially determinable. The claims are directed to running an object-oriented (Java/bytecode) network-management application against a device that only understands non-object-oriented commands such as SNMP — i.e., the exact architecture Nortel was marketing in its mobile-agent / Java network-device management stack of that era. I could not confirm with high confidence that a specific Nortel SKU shipped implementing claims 1–22; treat "shipped an embodying product" as not established rather than affirmed.
• Current status: in bankruptcy and liquidated. Nortel Networks Inc. filed Chapter 11 in January 2009 (In re Nortel Networks Inc., Bankr. D. Del. No. 09-10138). The portfolio was auctioned and sold to Rockstar Bidco, LP for $4.5 billion, approved by the U.S. and Canadian courts at a joint hearing on 2011-07-11 (see the Ontario court's allocation reasons, https://kmlaw.ca/wp-content/uploads/2010/07/USAllocationOpinion_Reasons_12May15.pdf). Nortel's US estate has been winding down since; its counsel confirmed in 2014 that no employees with technical knowledge of these patents remain.

Family note: the AU counterpart AU 3740500 A is recorded as abandoned/not-active, consistent with the portfolio being monetized rather than productized.

---

Assignment timeline

Full chain, chronological by recording date. Every ownership hop after 2011 runs through the Nortel bankruptcy estate.

2000-12-10 → 2001-06-24 (executed) / recorded 2001-10-19 — Reel 012288/0647

• Conveyance: Assignment of assignors' interest
• Assignor: Tal Isaac Lavian; Robert James Duncan
• Assignee: Nortel Networks Limited (Canada)
• Correspondent: not retrieved — see Signal 3
• Context: Original inventor-to-employer confirmatory assignment; signed after filing (filing 2000-08-08).

2000-12-10 → 2001-06-24 (executed) / recorded 2002-07-02 — Reel 013046/0006

• Conveyance: Change of Assignee Address
• Assignor: Tal Isaac Lavian; Robert James Duncan
• Assignee: Nortel Networks Limited (Canada)
• Correspondent: not retrieved
• Context: Administrative only — change of assignee address, no transfer of ownership.

2011-07-29 (effective) / recorded 2011-10-28 — Reel 027164/0356

• Conveyance: Assignment
• Assignor: Nortel Networks Limited
• Assignee: Rockstar Bidco, LP (New York)
• Correspondent: not retrieved
• Context: Bankruptcy fire-sale — the Nortel estate's court-approved $4.5B patent portfolio auction to the Apple/Microsoft/RIM/Ericsson/Sony/EMC consortium.

2012-05-09 (effective) / recorded 2014-03-10 — Reel 032422/0919

• Conveyance: Assignment
• Assignor: Rockstar Bidco, LP
• Assignee: Rockstar Consortium US LP (Delaware)
• Correspondent: not retrieved
• Context: Internal reorganization of the acquisition vehicle. Google's 2013 opposition brief describes this step as a "transaction that remains murky" and notes Rockstar Consortium's general partner was a "mail drop at a Midtown Manhattan law firm" (N.D. Cal. 5:13-cv-05933, Dkt. 79).

2015-01-28 (effective) / recorded 2015-02-09 — Reel 034924/0779

• Conveyance: Assignment
• Assignor: Rockstar Consortium US LP; Rockstar Consortium LLC; Bockstar Technologies LLC; Constellation Technologies LLC; MobileStar Technologies LLC; NetStar Technologies LLC
• Assignee: RPX Clearinghouse LLC (California)
• Correspondent: not retrieved
• Context: Transfer to a defensive aggregator — the RPX clearinghouse purchase ($25M deposit 2014-12-22 + $875M at closing; RPX's own ~$35M contribution), per RPX's 8-K of 2014-12-23 and press release of 2015-02-03.

2016-02-26 (effective) / recorded 2016-03-09 — Reel 038041/0001

• Conveyance: Security Agreement (not an ownership transfer)
• Assignor: RPX Corporation; RPX Clearinghouse LLC
• Assignee: [JPMorgan Chase Bank, N.A., as Collateral Agent](/asserters/jpmorgan-chase-bank-n-a-as-collateral-agent)
• Correspondent: not retrieved
• Context: Securitization — blanket collateral lien granted over RPX assets; encumbers but does not convey title.

2017-12-22 (effective) / recorded 2018-01-02 — Reel 044970/0030

• Conveyance: Release
• Assignor: JPMorgan Chase Bank, N.A.
• Assignee: RPX Corporation; RPX Clearinghouse LLC
• Correspondent: not retrieved
• Context: Release of the Reel 038041/0001 security interest — clears the lien; no change in ownership.

Non-assignment legal events worth noting (Google Patents legal events, no reel):

• 2016-03-11 maintenance-fee reminder; 2016-08-03 lapse for failure to pay maintenance fees; 2016-08-29 patent discontinued under 37 CFR 1.362; 2016-09-20 lapsed. Status remains Expired – Fee Related, with an adjusted expiration of 2021-07-11. The patent went abandoned for non-payment of the 12-year maintenance fee while owned by RPX Clearinghouse — i.e., the clearinghouse deliberately did not keep it alive.

---

Timeline diagram

timeline
    title Ownership of US 6772205
    1999 : Priority provisional filed
    2000 : CIP application filed
         : Inventors assign to Nortel
    2002 : Nortel address change recorded
    2004 : Patent issued as US 6772205
    2009 : Nortel files Chapter 11
    2011 : Nortel portfolio sold to Rockstar Bidco
         : Reel 027164 frame 0356 recorded
    2012 : Rockstar Consortium US LP takes title
    2014 : RPX agrees to buy Rockstar patents
    2015 : RPX Clearinghouse closes purchase
    2016 : JPMorgan security agreement recorded
         : Patent lapses for unpaid maintenance fee
    2018 : Security interest released

---

NPE / troll-pattern signals

1. Shell-entity transfer — PRESENT (with a caveat).
Nortel, an operating telecom-equipment company, transferred title to Rockstar Bidco, LP (Reel 027164/0356, effective 2011-07-29), a single-purpose acquisition vehicle formed by six operating companies solely to hold the Nortel portfolio. The downstream entity was characterized in sworn litigation filings as a "patent licensing business" that "produces no products, but exists solely to assert its patents" (Google opposition, N.D. Cal. 5:13-cv-05933 Dkt. 79). The caveat: the terminal link lands at RPX Clearinghouse LLC, a wholly-owned subsidiary of NASDAQ-listed RPX Corporation — a public operating company, not an anonymous Delaware shell.

2. Known asserter in the chain — PRESENT for a prior link; NOT PRESENT for the current owner.
Rockstar Consortium US LP was a high-frequency plaintiff in 2013–2014 (the "Halloween actions" filed 2013-10-31 in E.D. Tex., plus Constellation/Bockstar suits). It is not on the enumerated lists (Acacia, Marathon, IV, IPNav, Wi-LAN, Mosaid/Conversant, Vringo, Pendrell, Innovatio, MPHJ, Lumen View, Round Rock, etc.), but it matches the catch-all "high-frequency plaintiff." Critically, US 6,772,205 is not one of the asserted patents — the Rockstar/Constellation asserted sets I reviewed ('649, '389, '048, '879, '917, '299, '474, '862, '197, '990, '893, '397, '253, '551, '937, '298, '973, '131, '591, '572) do not include the '205. No complaint naming US 6,772,205 was located.

3. Repeat correspondent across the chain — UNCLEAR (data not retrievable).
This is the one signal I cannot responsibly score. The Assignment Center correspondent field was not reachable in this session, and no mirror of the assignment records I could access (Google Patents legal events, Espacenet, Global Dossier) reproduces the correspondent of record. I am not inferring a name. If you pull the seven recordings listed above (reels 012288/0647, 013046/0006, 027164/0356, 032422/0919, 034924/0779, 038041/0001, 044970/0030) directly through Assignment Center, the correspondent column on the three Rockstar/RPX links is the field worth comparing against Unified Patents' and RPX's high-frequency-plaintiff attribution lists.

4. Cascading transfers — PRESENT.
Four changes of title in about 42 months: Nortel → Rockstar Bidco (2011-07-29) → Rockstar Consortium US LP (2012-05-09) → RPX Clearinghouse (2015-01-28), with the security/release pair (2016, 2018) further churning the record. The first two hops are within ~9.5 months of one another, satisfying the "<24 months through chained entities" formulation. The final hop arrived simultaneously with a multi-seller assignment deed naming six Rockstar-family assignors (Rockstar Consortium US LP, Rockstar Consortium LLC, Bockstar Technologies LLC, Constellation Technologies LLC, MobileStar Technologies LLC, NetStar Technologies LLC) on a single reel — a classic consolidated-cleanup recording.

5. Pre-litigation transfer — NOT PRESENT.
No infringement suit naming this patent was found, so the "assignment within 6 months before suit" test cannot be satisfied. Note the direction of travel is the opposite of the usual pattern: the 2015-01-28 transfer to RPX Clearinghouse preceded the dismissal of eight Rockstar litigations against 16 companies, including Cisco and Google (RPX press release, 2015-02-03).

6. Bankruptcy fire-sale — PRESENT.
Textbook. Nortel filed Chapter 11 in January 2009 (In re Nortel Networks Inc., Bankr. D. Del. 09-10138). After a four-day auction in New York in June 2011, the portfolio sold to Rockstar Bidco, LP for $4.5 billion, approved 2011-07-11 — the sale that produced Reel 027164/0356. The estate's own later filings confirm it retained "no employees remaining with technical knowledge sufficient to identify relevant documents" about these patents.

7. Privateering — PRESENT at portfolio level; NOT PRESENT as to this patent.
The $4.5B buyer was a consortium of Apple, Microsoft, RIM/BlackBerry, Ericsson, Sony and EMC — three of them direct Google/Android competitors. The consortium then extracted licensing revenue and litigated against Android OEMs. That is the privateering fact pattern. But US 6,772,205 was never asserted, so at the individual-patent level I score this not present.

8. Defensive aggregator (anti-NPE) — PRESENT.
The chain terminates at RPX Clearinghouse LLC, which acquired the Rockstar assets with backing from a syndicate of 30+ licensees (including Cisco and Google), granted them non-exclusive licences, and offered the rest of the market FRAND terms (RPX 8-K 2014-12-23; press releases 2014-12-23 and 2015-02-03). The patent then lapsed in 2016 for failure to pay the maintenance fee — the strongest possible evidence it was acquired to neutralize, not to assert.

---

Verdict

Defensive / non-asserting.

The chain terminates at a defensive aggregator: RPX Clearinghouse LLC took title by Reel 034924/0779 (effective 2015-01-28, recorded 2015-02-09) as part of a syndicated clearinghouse purchase that simultaneously dismissed eight Rockstar litigations against 16 companies, and the patent was then allowed to lapse in August 2016 for non-payment of maintenance fees rather than maintained for assertion. The chain does contain two genuine NPE-flavoured signals — the Nortel bankruptcy fire-sale (Reel 027164/0356, portfolio sold for $4.5B, approved 2011-07-11) and a cascading transfer series through Rockstar Bidco → Rockstar Consortium US LP → RPX within ~42 months — and Rockstar Consortium US LP is a bona fide high-frequency plaintiff of 2013–2014, but that entity's asserted patent set does not include US 6,772,205, and no suit naming this patent was located. Caveat on confidence: Signal 3 (repeat correspondent) is unresolved because the Assignment Center correspondent field was not retrievable in this session; if the Rockstar and RPX reel entries share a single recording attorney, the case for an assertion-oriented chain would strengthen — but the terminal RPX link and the 2016 lapse still point to neutralization.

Verify at: https://assignmentcenter.uspto.gov/ (search patent number 6772205) or https://assignment.uspto.gov/patent/index.html — retrieve reels 012288/0647, 013046/0006, 027164/0356, 032422/0919, 034924/0779, 038041/0001 and 044970/0030, and record the correspondent column that I could not obtain here.

I'll research the prior art references cited on the face of US 6,772,205. Let me pull details on each patent citation.

Prior-Art Analysis — US Patent 6,772,205 B1

Identification/scope note. This analysis is for US 6,772,205 B1 ("Executing applications on a target network device using a proxy network device," Lavian & Duncan; filed 2000-08-08; granted 2004-08-03; CIP of US 09/522,332 → US 7,433,941 B1; provisional 60/124,047; priority 1999-03-12). I am not reporting on any look‑alike number. My source for the patent and its citation lists is the authoritative Google Patents/USPTO record (https://patents.google.com/patent/US6772205/en), supplemented by FPO, EveryPatent, Justia, uspto.report, and patentimages for the individual cited references.

This builds on the previously generated litigation summary (which found no known assertion litigation and noted the patent lapsed for non‑payment of maintenance fees on 2016‑08‑03). That finding does not affect the prior‑art analysis below; I flag one date discrepancy in the earlier artifact at the end.

Important framing: every reference below is a reference cited by the examiner on the face of '205 (8 patent citations + 7 non‑patent citations). That means each is presumptively prior art, and the applicant overcame all of them during prosecution. Consequently the correct characterization is not "these reference(s) invalidate the claims," but rather "these are the references the examiner/patentee regarded as closest, and here is how far each gets against the claim language." I state §102 anticipation candidly: no single cited reference discloses every element of any independent claim, because the independent claims require the combination of (a) determining whether the target device can process the object‑oriented (OO) application, (b) identifying/selecting a proxy device, (c) transmitting the OO application to the proxy, (d) the proxy generating non‑OO (SNMP) network‑management instructions corresponding to that application, and (e) transmitting them to the target. Below, for each reference, I identify the claim(s) it most closely touches and the missing elements that defeat a §102 mapping.

---

Part 1 — Patent citations (the 8 references on the face of '205)

P1 — US 6,055,243 A (US West) — object‑oriented translators

Full citation: Vincent, A.W.; Hall, C.S.; "System and associated method for re‑engineering a telecommunications support with object‑oriented translators," US 6,055,243, granted Apr. 25, 2000 (divisional of 08/491,002, filed Jun. 14, 1995, now US 5,903,731).
Description: Standardizes network‑management data processing by inserting "object translator" means that translate network‑management information between a nonstandard "function oriented protocol" and a standardized object‑oriented message protocol, with a network information manager maintaining an object‑oriented model (claims 1–16; PDF: patentimages US5903731 and EveryPatent pat6055243).
§102 mapping: Most relevant to the proxy/translator concept of independent claims 1, 2, 22 — i.e., a first component that sits between two network‑management representations and translates between an OO protocol and a non‑OO protocol. Defeats its own anticipation: it does not disclose (i) determining whether a target network device can process an OO application, (ii) identifying/selecting a proxy among network devices, (iii) transmitting an OO application to a proxy for execution, or (iv) generation of SNMP "get/set/test"-style non‑OO instructions corresponding to the application. Its translators translate running network‑management traffic, not execute an application on behalf of a target. → §103 combination material, not §102 anticipation.

P2 — US 6,058,103 A (MCI) — network management system

Full citation: Henderson, G.S.; Perry, W.B.; Franklin, T.D.; Sanders, E.J.; Cooley, V.A.; "Network management system," US 6,058,103, granted May 2, 2000, MCI Communications Corp.
Description: A network‑management architecture with a GUI workstation function, a TMN subsystem holding a run‑time object model of the network, a current/future database, and an object request broker (ORB) that translates objects from a first object‑oriented paradigm to a second object‑oriented paradigm (EveryPatent pat6058103; searchlight.law/doc/US6058103).
§102 mapping: Touches claim 1 (and the program‑product/system claims 20, 22) only insofar as it teaches object↔object translation. Defeats anticipation: the translation is OO→OO (paradigm mapping for a GUI), not OO→non‑OO/SNMP instruction generation, and there is no target‑capability determination, no proxy selection, and no transmission of an OO application to a device for proxy execution.

Date discrepancy to flag: the face of '205 lists P2's prior‑art date as 1996‑02‑22, while secondary sources (radaris inventor index; FPO) show Appl. No. 09/032,778 filed 1998‑03‑06 and granted 2000‑05‑02. I could not reconcile this to a single value; treat the 1996‑02‑22 date as unverified.

P3 — US 5,961,595 A (NEC) — the closest single reference on the conversion element

Full citation: NEC Corporation, "Network management system with a hardware resource management module shared between networks," US 5,961,595, granted Oct. 5, 1999 (filed 1996‑06‑21).
Description: A manager 101 ↔ agent 102 (via standard protocol 104, e.g., CMIP/SNMP) ↔ function‑oriented resource manager 103 (via a device‑specific interface 105). Because the resource‑manager program is written function‑oriented (non‑OO) while the manager issues object‑oriented operation requests, the agent includes a protocol/message converter 121 that converts an object‑oriented operation request into function‑oriented commands (e.g., GET/SET‑type basic operations) for the legacy resource manager (PDF: patentimages US5961595; Google Patents US5961595).
§102 mapping: This is the single reference that most closely reads on the "generate one or more non‑object‑oriented network management instructions corresponding to the object‑oriented application" element common to claims 1, 2, 13, 19, 20, 21, 22 — it explicitly converts OO operation requests into non‑OO (function‑oriented/basic‑command) network‑management commands addressed to a non‑OO managed component. Defeats anticipation of the independent claims: NEC's converter is a pre‑configured, static agent feature; there is no step of determining whether a target is capable of processing the OO application, no identification/selection of a proxy device, no transmission of the OO application itself to a proxy for execution, and no claim‑2 "request the target to load the application." NEC converts individual requests, not an application executed on the target's behalf. A §102 anticipation argument would fail on those missing limitations; P3 is best used as the primary §103 reference.

P4 — EP 0 831 617 A2 (DEC) — flexible SNMP trap mechanism

Full citation: Digital Equipment Corp., "Flexible SNMP trap mechanism," EP 0 831 617 A2, published Mar. 25, 1998 (filed 1996‑09‑19).
Description: A mechanism for flexible handling/generation of SNMP traps.
§102 mapping: Relevant only as background to the SNMP limitation of claim 10 ("non‑object oriented network management instructions are compatible with SNMP commands") and to the SNMP context of the spec. It does not address OO applications, proxies, conversion, or target‑capability determination, so it anticipates no claim.

P5 — US 5,911,776 A (Unisys) — automatic format conversion

Full citation: Unisys Corp., "Automatic format conversion system and publishing methodology for multi‑user network," US 5,911,776, granted Jun. 15, 1999 (filed 1996‑12‑18).
Description: A system/methodology for automatic conversion of data formats for distribution to multiple users on a network.
§102 mapping: Generic "convert one format to another" teaching; at most background to the conversion step of claims 1/2/13/19/20/21/22. It discloses no OO application, no OO→SNMP command generation, no proxy/target relationship. Anticipates no claim.

P6 — US 6,292,829 B1 (Nortel) — method and device for network management

Full citation: Nortel Networks Limited, "Method and device for network management," US 6,292,829 B1, filed Jul. 15, 1998, granted Sep. 18, 2001.
Description: Network‑management method/device (Google Patents sitemap H04L12; limited full‑text detail retrieved). Same assignee family as '205.
§102 mapping: Because it granted after the '205 filing date (2000‑08‑08) but was filed before it (1998‑07‑15), it is §102(e) prior art as of its filing date. On the material retrieved, it is network‑management subject matter potentially touching claims 1/2/22 at a high level, but I could not retrieve claim text sufficient to map its OO/SNMP/proxy elements; I therefore cannot substantiate any §102 anticipation and flag it as unverified.

P7 — US 6,487,590 B1 (Lucent) — controlling a network element from a remote workstation

Full citation: Lucent Technologies Inc., "Method for controlling a network element from a remote workstation," US 6,487,590 B1, filed Oct. 30, 1998, granted Nov. 26, 2002.
Description: Remote‑workstation control of a network element (remote management/agent exchange).
§102 mapping: §102(e) art (pre‑'205 filing). Directed to remote control/management of a network element, which is conceptually adjacent to claims 2, 13, 22 ("transmitting a request from the network management server to a target network device"), but there is no teaching of an OO application, a proxy that converts OO to non‑OO, or target‑capability determination. Anticipates no claim on the record retrieved.

P8 — US 6,330,601 B1 (Nortel) — multi‑level communication network management — second‑closest reference

Full citation: Nortel Networks Limited, "Management system for a multi‑level communication network," US 6,330,601 B1, filed Dec. 22, 1998, granted Dec. 11, 2001 (uspto.report/patent/grant/6330601).
Description: An interface module 105 bridges a data‑network management system 100 and a transport‑network management system 110. It contains a conversion functional block 330 that "reads the packet in CORBA format, accesses the MIB 305 and builds new data packets in the SNMP format," and an SNMP agent 315 that exposes the transport network to the data‑network manager via traps/polls.
§102 mapping: Material to the OO(CORBA)→SNMP conversion element of claims 1, 13, 19, 20, 21, 22 — it is one of the few cited references that expressly converts an object‑oriented (CORBA) representation into SNMP packets. Defeats anticipation: the interface module is a fixed representation/proxy layer for a transport network; there is no determination of whether a target device can process an OO application, no proxy‑device identification/selection (with locale criteria), no transmission of an OO application to a proxy, and no execution of an application to produce the SNMP instructions. §102 fails; §103 combination with P3 is the realistic route.

---

Part 2 — Non‑patent citations (7) — arguably the more on‑point art for the "application execution" aspect

The following were cited as NPL references (Google Patents "Non‑Patent Citations"). They are printed publications under §102(b) (all dated 1997–2000, before the '205 filing):

N1–N3 are the references that best explain the mobile‑agent/"executing applications on a network device" premise that the '205 background builds on (the spec itself references mobile agents, Java/JVM, Java Beans, JINI, COM/DCOM). But none of them discloses the distinguishing element of the '205 independent claims — a proxy converting an OO application into non‑OO SNMP instructions for a legacy target device that cannot process OO.

---

Part 3 — Ranking of most relevant prior art, and §102 bottom line

Most → least relevant on the face of '205:

1. US 5,961,595 A (NEC, P3) — closest on the OO→non‑OO network‑management instruction conversion element (claims 1, 2, 13, 19–22). Missing: target‑capability determination, proxy identification/selection, transmission/execution of the OO application.
2. US 6,330,601 B1 (Nortel, P8) — express CORBA→SNMP conversion in a network‑management proxy layer (claims 1, 13, 19–22). Same missing limitations.
3. US 6,055,243 A (US West, P1) — OO↔function‑oriented translators in network management (claims 1, 2, 22).
4. US 6,058,103 A (MCI, P2) — ORB object‑paradigm translation (claims 1, 20, 22), but OO→OO only.
5. US 6,487,590 B1 (Lucent, P7) — remote control of a network element (claims 2, 13, 22), §102(e).
6. US 6,292,829 B1 (Nortel, P6) — network management, §102(e); insufficient detail retrieved.
7. US 5,911,776 A (Unisys, P5) — generic format conversion.
8. EP 0 831 617 A2 (DEC, P4) — SNMP‑trap background only.
9. NPL N1 Covaci / N3 Susilo / N2 Liotta — mobile‑agent/Java network‑management background.

§102 bottom line. On the record retrieved, none of the eight patent citations (or the NPL) discloses all elements of any independent claim (1, 2, 13, 19, 20, 21, 22), so I do not assert §102 anticipation by any single reference. The potentially anticipatory elements are confined to the "convert object‑oriented request into non‑object‑oriented/SNMP network‑management command" limitation — best disclosed by P3 (NEC) and P8 (Nortel) — and the "object‑oriented network management application / mobile agent" premise — best disclosed by N1–N3. The claim‑distinguishing limitations that no cited reference supplies are: (i) determining whether the target device can process the OO application (claims 1, 2, 7, 11, 12); (ii) identifying/selecting a proxy device (claims 1–6, with the locale/load/processor criteria of claims 3–6); (iii) transmitting the OO application to the proxy and having the proxy generate the non‑OO instructions corresponding to that application (claims 1, 2, 13, 19–22); and (iv) the proxy‑mode data‑store determination (claims 8, 9, 14, 15). Any invalidity attack on the independent claims would most plausibly be a §103 combination (e.g., NEC or Nortel '601 for the OO→SNMP conversion, in view of a mobile‑agent reference such as Covaci/Susilo for application distribution), not a §102 anticipation.

---

Caveats and contradictions

• Provenance/limits: The 8 patent citations' bibliographic data and abstracts were verified across Google Patents, FPO, EveryPatent, Justia, uspto.report, and patentimages where available. For US 6,292,829 (P6) I could only obtain bibliographic/classification data, not claim text; its §102 assessment is therefore unverified and should not be relied on.
• Date discrepancy (P2, US 6,058,103): the '205 face shows a 1996‑02‑22 prior‑art date; secondary sources show a 1998‑03‑06 filing date. Unresolved here; prefer the actual printed patent if a date is critical.
• §102(e) nuance: P6, P7, P8 granted after the '205 filing date (2000‑08‑08) but were filed before it (1998), so they are prior art only under §102(e) as of their U.S. filing dates — not under §102(a)/(b). P1–P5 and EP‑P4 pre‑date the filing (and, excepting details, the 1999‑03‑12 priority).
• Contradiction check vs. the earlier litigation section: none identified — the earlier section's "no known litigation" and the 2016 lapse finding are consistent with this prosecution‑history‑based prior‑art analysis. One item to correct/clarify from the earlier artifact: it cites the patent's "Adjusted expiration" as 2021‑07‑11 while also noting the 2016‑08‑03 maintenance‑fee lapse; those two figures are internally tension‑y in the Google Patents record and should be reported with that caveat rather than as a settled expiration date.

Because '205 is a continuation‑in‑part of US 09/522,332 (US 7,433,941 B1), the closest art for the CIP‑added proxy/conversion subject matter is the pair P3 (NEC '595) and P8 (Nortel '601); the parent's own prosecution art (see the ISR in PCT/US00/06479, N4) is the art already searched against the shared disclosure.

I'll ground this analysis by pulling what I can on the specific prior-art references of record, then build the §103 combinations.

Let me pull the remaining references of record — the Nortel reference, the mobile-agent NPL (Covaci/Liotta/Susilo), and the remaining U.S. patents.

Obviousness Analysis — US 6,772,205 B1 under 35 U.S.C. § 103

Sourcing note: This analysis is built on (a) the patent text and reference list reproduced in the authoritative record above (Google Patents, fetched 2026-09-24), and (b) live web retrieval of the reference documents summarized below. Where I could retrieve only a title/abstract rather than full text, I say so and downgrade the confidence of any combination resting on it. I am not rendering a legal conclusion of invalidity.

---

1. Which statute applies, and the effective filing date problem

The application was filed 2000-08-08 as a continuation-in-part of US 09/522,332 (filed 2000-03-09), which claims benefit of provisional US 60/124,047 (filed 1999-03-12). Pre-AIA § 103(a) governs. That matters for three reasons:

1. Pre-AIA § 103(c) is available as a shield. Two references of record — US 6,292,829 and US 6,337,601 — are Nortel-assigned, as is the '205 application. To the extent each qualifies only as 102(e) art (both issued 2001, long after any filing date here), common ownership at the time of invention would disqualify them as § 103 art. They are therefore the weakest of the eight references and should not be counted on in any primary combination.
2. § 103(c) does not help against the third-party art (US 6,055,243 / US West; US 6,058,103 / MCI; US 6,487,590 / Lucent; US 5,911,776 / Unisys; US 5,961,595 / NEC; EP 0 831 617 A2 / DEC) or against the three NPL items. Those are the art that carries the analysis.
3. The priority chain shifts several references from avoidable to unavoidable art. The proxy-conversion subject matter appears in the '205 CIP specification; whether it is supported in the 2000-03-09 parent or the 1999-03-12 provisional determines the effective date for the claims at issue. If it is not so supported (the more likely reading, and the point flagged in the earlier summary), the effective date is 2000-08-08 — which makes EP 0 831 617 A2 (pub. 1998-03-25), US 5,911,776 (iss. 1999-06-15) and US 5,961,595 (iss. 1999-10-05) more than one year old and therefore § 102(b) art that cannot be sworn behind. All eight patents qualify at minimum as § 102(e) art (each was filed before 1999-03-12), and US 6,055,243 in particular is only § 102(e) art (filed 1995-06-14, issued 2000-04-25).

Practical consequence: a challenger is not limited by the 1999 date, and the two expired/§ 102(b) references cannot be antedated. But note the patent lapsed for non-payment of maintenance fees effective 2016-08-03, so the realistic venues are a district-court validity defense or ex parte reexamination, not an IPR.

---

2. Person of ordinary skill in the art (PHOSITA)

A practitioner with a B.S. in computer science or electrical engineering and roughly two to three years of experience in network management (SNMP/MIB, CMIP, element management systems) plus object-oriented and distributed programming (Java/JVM, CORBA/ORB, applets, mobile code) — or equivalent. This is the level at which the references below would have been read, and it is the level at which "convert an OO management application into SNMP get/set/test commands" would have been a routine engineering task, not an inventive leap. The '205 specification is itself evidence of that: it describes the conversion as accomplished "according to a lookup table listing equivalent object-oriented and non-object oriented instructions."

---

3. What the references of record actually teach

---

4. Combination 1 (primary): US 6,487,590 + US 6,055,243 (+ US 6,058,103)

Why this combination, and why it is not hindsight: 6,487,590 is a complete OO-management-over-SNMP system that stops one step short of the '205's framing — its OO client code stays at the workstation and it is the commands (not the application) that travel. 6,055,243 is a complete OO-to-legacy translator architecture that stops one step short in the other direction — its OO layer is an object model/OSS, not a downloadable application. Both are in the same field (management of heterogeneous/legacy network elements), address the same problem (making modern OO management architecture work with devices that cannot participate in it), and the combination is the substitution of one known intermediary ("EM server/object server" per 6,487,590) for another ("translator 340" per 6,055,243) within the other's architecture.

Assessment: Grounds 1, 20 and 22 (method, CPP, system) are the most exposed; grounds 2, 13, 19 and 21 inherit the same mapping plus the "request the target to load the application" step, which is supplied by the mobile-code NPL or by 6,487,590's per-session client registration model. Claim 1 is the broadest and easiest target, because it omits the load-request step entirely.

---

5. Additional combinations worth pressing

• Combination 2 — Mobile-code NPL + 6,487,590. Covaci, Liotta and Susilo teach distributing management code to network nodes; 6,487,590 teaches converting management commands to SNMP at an intermediary. Together they read on the "transmit the object-oriented application to the proxy network device" step more directly than 6,487,590 alone. Provisional pending verification of the NPL texts.
• Combination 3 — 6,055,243 + NPL only. A translator architecture for legacy elements plus a mobile-agent delivery mechanism; covers claims 1/2/22 without needing 6,487,590.
• Combination 4 — 6,058,103 + 6,487,590. Covers the NMS preamble, object model, device-information store (claims 7, 9, 15) and the SNMP conversion, but needs 6,055,243 or the NPL for the non-OO direction. Best used as a supplement, not a standalone ground.
• Combination 5 (corroborative only) — 5,961,595 or 5,911,776 + 6,487,590. Adds "shared module" and "format conversion" flavor; not necessary.

---

6. Motivation to combine (KSR rationales)

1. Express statement of the problem and the goal in the art. 6,055,243's background catalogues three options for network providers — (3.1) forgo new technology, (3.2) build parallel OSSs, (3.3) "flash cut" — states "none of the above options has proven to be viable," and proposes incremental introduction "without (a) prematurely retiring current network elements." That is a direct teaching, in the references themselves, to make an OO management layer interoperate with legacy devices through translation. This is the strongest motivation rationale available.
2. Design incentive to hide the device protocol. 6,487,590 states the interface "hides the implementation details associated with the element manager platform" and that "clients do not need to know the underlying protocol to the network elements." Placing conversion in an intermediary is the stated design intent, not a hindsight construct.
3. Predictable, mechanical result (KSR "combination of familiar elements"). Converting an OO management call into SNMP get/set/test is a lookup-table mapping — the '205 specification says so itself ("according to a lookup table listing equivalent object-oriented and non object oriented instructions"). No new technique is required, and no unexpected result is reported.
4. Known, finite, predictable set of options. Two translators, two servers, one SNMP library: a POSITA chooses among a small number of known intermediaries. KSR ("obvious to try") applies.
5. Art-recognized interchangeability. 6,055,243 and 6,487,590 both use translators/servers as OO-to-legacy bridges; substituting one bridge for the other is a "mere substitution of one known element for another" yielding predictable results.
6. Design driver for offloading. The '205 specification's own stated rationale — reduce NMS load and network traffic by pushing processing to distributed devices — is also the stated object of 6,058,103's distributed overlay and of the mobile-agent NPL. This supplies the "why" for sending the application out rather than executing it centrally.

---

7. Dependent claims

---

8. Where the patent's strongest non-obviousness case lies

• The capability-determination gate (claims 1, 2, 13, 19–21). None of the four strongest references expressly discloses deciding, as a precondition, whether the target device can process the OO application and branching on that decision. A patentee would argue this is the inventive "routing" concept and that the references merely show unconditional translation. A challenger must meet this with 6,055,243's legacy-incapability teaching, 6,487,590's heterogeneity premise, or art not of record showing capability discovery/negotiation.
• Claims 3–6 (locale criteria). No of-record reference appears to select a proxy by geographic distance, processor capability, or relative load. A challenger likely needs art outside the record — see §9.
• Transmitting the application itself (not just commands) to the proxy. 6,487,590 sends commands, not the app. This is the step the mobile-code NPL must supply, and I have not verified those texts.

---

9. Art not of record that would materially strengthen the §103 case

These were surfaced in my searches but are not in the '205's reference list; I flag them as supplemental so they are not confused with the of-record art:

• US 5,438,614 (proxy agent receiving SNMP requests, translating them into a different management protocol (MBP), sending them to remote legacy devices, translating responses back to SNMP) — a near-perfect structural analogue of the "conversion + forward to a non-capable target" concept, and it even recites software download to those devices.
• US 6,003,077 (Web/SNMP proxy agent converting client requests into SNMP packets for remotely located SNMP agents, with a MIB compiler).
• JPH1168745A (proxy manager relaying SNMP requests/responses between a manager and an agent).
• Lucent's EP 0 963 076 family (Java running "on both the management computer and the managed elements").

If a challenger is restricted to the record (as in ex parte reexam), the record art is thinner; if these are available (district court, IPR), the §103 case becomes considerably stronger, particularly for the capability-gate and proxy-selection limitations.

---

10. Secondary considerations

Nothing in the record supplies a nexus. There is no evidence of commercial success, licensing, industry praise, copying, or long-felt-but-unsolved need tied to these claims; the patent lapsed for failure to pay maintenance fees on 2016-08-03, and the earlier sections found no litigation, IPR or CAFC proceeding asserting this number. Objective indicia therefore do not rebut the prima facie case in this record.

---

11. Caveats and what I could not verify

1. I could not retrieve full texts for Covaci 1997, Liotta 1998, Susilo 1998, or for US 5,911,776, US 5,961,595, US 6,292,829, US 6,337,601, EP 0 831 617 A2. Those entries are characterized from titles, abstracts, and the examiner's citation. Any combination relying on them is provisional.
2. I have not read the file history (office actions and responses). I do not know which limitations the examiner relied on to allow the claims over these same references. Because all eight references are of record, a challenger must show either examiner error or a new combination — and in an IPR, art already of record in a new combination is permitted but weighed accordingly.
3. The 102(e)/103(c) status of the two Nortel references is a legal question I flag rather than resolve; it depends on ownership facts at the time of invention.
4. The claim-4 "local"/"locale" wording and claim 16's "commands instructions" are literal-reading defects flagged in the earlier section; they affect how the prior art must be mapped, and a narrowing construction of claim 4 could help the patentee.
5. This is an obviousness analysis, not a validity opinion. I have not been asked to, and cannot, certify invalidity.

---

12. Bottom line

• Strongest ground: US 6,487,590 in view of US 6,055,243 (optionally with US 6,058,103 and the Java mobile-agent NPL). This combination maps nearly every limitation of claims 1, 22, 13, 19, 20 and 21, and with the NPL, claim 2 and its dependents 7–18. The motivation is unusually well documented inside the references themselves (6,055,243's legacy-migration mandate; 6,487,590's protocol-hiding design goal), and the conversion step is a lookup-table mapping by the patent's own admission.
• Medium-confidence ground: the capability-determination gate and the "transmit the application to the proxy" step, which depend on the unverified NPL texts or on supplemental art like US 5,438,614 / US 6,003,077.
• Weakest claims against the of-record art: dependent claims 3–6 (locale-based proxy selection), which are not clearly addressed by any reference of record but are addressed by ordinary load-balancing/server-selection knowledge and could fall to common-knowledge reasoning with a suitable secondary reference.
• Practical note: because the patent lapsed in 2016 with no litigation found to date, a § 103 challenge is most likely to arise as a defense or in reexamination rather than as an affirmative IPR, and the two § 102(b)-class references (EP 0 831 617 A2; US 5,911,776; US 5,961,595) cannot be antedated if the claims are measured from 2000-08-08.