US 6182136

I'll verify current status via search, then summarize from the authoritative text provided.

US 6,182,136 B1 — Automated Service Elements Discovery Using Core Service Specific Discovery Templates

1. Search scope and confidence note

I searched for the identifier 6182136 as instructed. Findings:

• The US grant US 6,182,136 B1 is confirmed and corroborated across Google Patents, FreePatentsOnline, uspto.report, and EveryPatent.
• I found no CAFC 2026 docket (or any Federal Circuit docket) naming US 6,182,136 as an asserted patent. The CAFC June 2026 scheduled-cases PDF, the July 2026 Gibson Dunn Federal Circuit update, the Patterson Sheridan week-ending May 1 2026 summary, and other 2026 Federal Circuit materials I retrieved contain no reference to this patent number. I cannot rule out a docket I did not retrieve, but I have no authoritative evidence of litigation, IPR, or appeal activity in 2026.
• ⚠️ Do not conflate identifiers: searches for "6182136" also return JP 6182136 B2 (a Japanese grant, publication 2017-08-16, family member of WO 2013/003358 A2 on matrix metalloproteinase inhibitors). That is a different, unrelated document that merely shares digits. Per the literal-ID rule, I am treating these as two distinct documents and am not merging them. Similarly, the string "6182136" appears in various PTAB petition search-history tables as a cited reference, not as the subject patent.

2. Bibliographic data (from the authoritative grant text)

Note the patent is pre-AIA (filed 1998), so the AIA §102/§103 framework does not apply directly; the on-sale-bar/public-use case law referenced in 2026 Federal Circuit decisions (e.g., Definitive Holdings v. Powerteq) would be the relevant pre-AIA law had this patent been litigated — but I found no such litigation.

3. Abstract (as issued)

"A method and system for modeling services available via a network include selecting a core service that is to be modeled, forming a discovery template that is specific to the selected core service, and automatically discovering the elements which cooperate to provide the core service. The discovery template includes instructions for implementing automated techniques for discovering service elements, and preferably services, which are anticipated as being cooperative in executing the core service. The system includes a number of discovery modules for generating outputs indicative of the services and service elements. A discovery engine is responsive to the discovery template to invoke the modules that are identified in the template as being relevant to discovering specified services and service elements. The template also identifies dependencies among the modules, so that the proper sequence of processing can be determined. In one embodiment, the discovery template is organized into sections, with each section (1) being specific to a type of service or service element, (2) specifying at least one discovery routine for identifying the specified type of service or service elements, and (3) specifying dependencies of the identified discovery routine on outputs of other discovery routines. Preferably, each section also includes instructions for configuring the data that is output from the identified discovery routine."

4. Plain-language overview of the independent claims

Confidence caveat, stated plainly: the full claim set was not reproduced in the authoritative text I was given (it ends mid-specification). I have verbatim text for dependent claims 20 and 21, and from those I can identify claim 18 as an independent system claim. I do not have verbatim text of claim 1 or claim 18 and will not invent it. What follows is a plain-language reconstruction grounded in the abstract, the Summary of Invention, and the surviving claim language, with the level of certainty flagged for each item.

Independent claim 1 — Method (presumed independent, method form)

Confidence: high that a method independent claim exists and maps to the Summary of Invention; moderate on exact wording and on whether claim 1 is that claim vs. another number.

Plain language: A method of discovering the elements that cooperate to perform a "core service" offered over a network, comprising:

1. Selecting the core service of interest (e.g., "Read Mail").
2. Forming a discovery template specific to that core service — i.e., a data specification naming the types of services and service elements anticipated to cooperate in executing the core service, naming the discovery routines/modules to be used for each type, and specifying the dependencies of those routines on one another's outputs. Critically, the template is service-specific but not network-specific (it is a schema, not an instance).
3. Automatically discovering instance information by having a discovery engine read the template, deploy the identified discovery modules in a dependency-determined order, and collect their outputs.
4. Optionally/commonly, using the instance information to map dependencies among the actual services and service elements in the network of interest (execution, component, inter-service, and organizational dependencies), and to build a service model instance/graph of interlinked nodes.

The specification describes the template as organized into INI-style sections, one per service/service-element type, each with module, arguments, outputs, instanceKey, and dependencies variables.

Independent claim 18 — System (means-plus-function)

Confidence: high that claim 18 is an independent system claim on the basis of verbatim dependent claims 20 and 21. The element list below is my reconstruction, not verbatim.

Plain language: A system for discovering elements cooperating to perform a core service, comprising:

• Means (e.g., memory) for storing a discovery template specific to the selected core service, the template identifying a plurality of service elements and discovery module means for detecting them, plus dependencies among those discovery module means; and
• Discovery engine means coupled to the template for accessing it, selectively invoking the identified discovery module means according to the template, and receiving/storing their outputs as instance information (the "discovered instance").

Two verbatim dependent claims confirm this reading and the claim's §112(f) phrasing:

• Claim 20 (verbatim): "The system of claim 18 wherein said discovery engine means determines a sequence of invoking said selected discovery module means, said sequence being at least partially determined by said dependencies."
• Claim 21 (verbatim): "The system of claim 18 wherein said discovery module means cooperate to determine a sequence of generating said outputs, said sequence being at least partially determined by said dependencies."

Claims 20 and 21 map directly to the specification's three disclosed sequencing approaches: (i) template ordering, (ii) discovery-engine-determined ordering (claim 20), and (iii) module-cooperative/event-driven ordering, including peer-to-peer registration without the engine (claim 21).

Other independent claims

Confidence: low — I could not verify their existence or scope. The record shows at least 21 claims, and claim 18 is independent, implying at least two independent claims (one method, one system). I cannot reliably identify any additional independent claim without the full claim set.

5. Technical substance (for context)

• Two-phase discovery is the core disclosed methodology: Phase 1 (external) uses DNS — zone transfers, NS records, MX records, round-robin A-record groups — to find hosts, application servers, service groups, mail servers, terminal servers/POP sites, and to derive execution, component, and organizational dependencies. Phase 2 (internal) fills the "holes" in the partial service model to find inter-service dependencies (e.g., mail FES → NFS, mail FES → authentication) using either network probes (packet-header snooping) or special-purpose discovery agents (config-file parsing, registry inspection, netstat connection monitoring), which may be forward-looking or backward-looking.
• Extensibility is the stated point of novelty: the discovery engine is deliberately service-agnostic; adding a new service requires only a new discovery module plus new template entries, with no changes to the engine. This is what the patent says distinguishes it from the monolithic prior art (Besaw et al., US 5,276,789; Wu, US 5,185,860) and from Hellerstein's measurement navigation graph.
• Related, separately-numbered family member: US 6,336,138 (filed 1998-08-25, app. 09/139,959, "Template-driven approach for generating models on network services," Hewlett-Packard) cites US 6,182,136 and shares several inventors (Caswell, Ramanathan, Neal). These are distinct patents and should not be merged.

6. Explicit uncertainties

1. Claim text of claims 1 and 18 is not independently verified in this analysis; only claims 20 and 21 are verbatim. Any statement about the precise scope of the independent claims should be re-verified against the USPTO PatentCenter or the printed patent column 20+ before being relied upon.
2. No CAFC 2026 activity found. Absence of evidence in the sources I retrieved is not proof of absence of litigation; a Docket Alarm / PACER / PTAB search would be required for a definitive negative.
3. "6182136" is not a unique identifier in the wild (JP 6182136 B2 exists and is unrelated). Queries returning bare "6182136" should be filtered by jurisdiction and kind code.

I'll search for litigation involving US patent 6182136.

Let me search more specifically for litigation records.

Let me check the litigation-specific databases directly.

Litigation Search Results for U.S. Patent No. 6,182,136

Summary: I found no record of any litigation involving U.S. Patent No. 6,182,136.

Based on my searches of patent litigation resources (including the Unified Patents litigation portal, CourtListener/RECAP, PACER-derived docket aggregators like Justia Dockets/UniCourt, and general web search), I was unable to identify any case — district court, ITC, or CAFC — in which U.S. Patent No. 6,182,136 was asserted or challenged.

Important caveat on search reliability

The searches returned only false positives — cases involving different patent numbers that resemble, but are not, 6,182,136. Per your instruction to interpret identifiers literally and not auto-correct them, I am flagging these as non-matches and expressly excluding them:

None of these involves U.S. Patent No. 6,182,136. I did not find any case that matches the number 6,182,136 exactly.

What the record does show about the patent (context, not litigation)

From the patent's public prosecution/assignment record, U.S. Patent No. 6,182,136 has an extensive ownership chain but no litigation filings surfaced:

• Original assignee: Hewlett-Packard Company
• Assignment chain: Hewlett-Packard → Agilent Technologies (2000/2004) → JDS Uniphase Corporation (2013) → Viavi Solutions Inc. (2015, change of name)
• Current assignees listed: HP Inc., Viavi Solutions Inc., Hewlett Packard Development Co. LP
• Priority/filing date: September 8, 1998
• Grant date: January 30, 2001
• Legal status: Expired – Lifetime (anticipated expiration September 8, 2018)

A patent that expired in 2018 and passed through several corporate owners is admittedly the type of asset that NPEs sometimes litigate, so the absence of records is notable but not conclusive.

Recommended next steps for verification

Because I could not confirm a negative with certainty from the sources searched, I recommend directly querying:

1. District court dockets — search the patent number in PACER Docket Search / Bloomberg Law / Lex Machina / Docket Navigator (which support exact patent-number queries), since a single search aggregation may miss cases.
2. ITC — EDIS Section 337 investigations.
3. CAFC — the Federal Circuit's docket and opinion database.
4. USPTO Patent Center / Global Dossier — for any reexamination or IPR/PGR filings (which would not be "litigation" but are related validity challenges).

Bottom line: As of the sources searched on April 26, 2026, no litigation involving U.S. Patent No. 6,182,136 is known. I cannot confirm this is a complete negative, and I flag that the searches were limited and returned only dissimilar-number false matches.

I'll start by verifying the structured block's "no PTAB activity" signal against live web sources, then check for any older or recently-filed proceedings.

Let me run a few more targeted checks to be thorough before concluding.

One more check for litigation/defensive-aggregator activity that might reveal an unindexed challenge.

Proceedings overview

Total AIA trial proceedings on US 6,182,136: 0. Breakdown by status: 0 active, 0 with claims invalidated, 0 with claims sustained, 0 settled, 0 institution denials. The USPTO Open Data Portal structured block returns no AIA trial proceedings, and independent web searches for IPR/PGR/CBM challenges to this patent — including Viavi- and Hewlett-Packard-side dockets, PTAB decision repositories, and defensive-aggregator activity — returned nothing. The bottom-line defensive posture is therefore unusual and worth understanding precisely: this is not a "hardened, survived-IPR" patent and it is not a "claims canceled" patent — it is an untouched patent that ran out of life before the AIA challenge machinery could be brought to bear on it. Absent a maintenance-fee revival or some reissue/continuation in the family (verify — see Next Steps), assertions against a defendant today face no PTAB estoppel or claim-cancellation tailwind, which cuts against a defendant rather than for one. But the same fact pattern — a 1998-filing patent, expired 2018-09-08 — also means the ordinary § 102/§ 103 invalidity playbook is wide open in district court and at the ITC, with no estoppel map to navigate.

I must flag plainly: no §{PROCEEDING_NUMBER} sections follow, because there are no proceeding numbers to report. I will not invent them. What I can do is document the search record and the two false positives that a careless search would have mis-reported as activity on this patent.

Search record and false-positive filtering (why "zero" is a reliable answer here)

• False positive #1 — Viavi patent-owner dockets. Searching on the current assignee surfaced a cluster of real PTAB proceedings involving Viavi Solutions: IPR2021-00631 (Platinum Optics Technology v. Viavi, FWD 2022-10-03, all challenged claims of US 9,354,369 held not unpatentable; appeal dismissed for lack of standing, Fed. Cir. 2023-1227, decided 2024-08-16), IPR2022-01489 (Platinum Optics Technology v. Viavi, FWD 2024-04-11 on US 11,131,794), IPR2022-01281/01183/01184 (Zhejiang Crystal-Optech v. Viavi, institution denied), and IPR2021-00432/00424 (denied). None of these concern US 6,182,136. They involve Viavi's optical-filter patents (hydrogenated-silicon filter stacks / sensor systems) — a completely different technology and patent family. Do not import the optical-filter outcomes onto this patent.
• False positive #2 — collateral prior-art citation. A CBM2013-00024 exhibit (a file history from an unrelated patent) lists "US-6182136" inside a large prior-art search string. That is a citation to the patent as prior art in someone else's proceeding — not a challenge to US 6,182,136.
• The structured ODP block is the canonical list and reports none. Web search found nothing contradicting it.

Why this patent never attracted an AIA trial

Strategic summary

Claim status: entirely UNTESTED. No claim of US 6,182,136 has been canceled, narrowed, or confirmed in any AIA trial. This is materially different from the typical "narrowed through IPR" posture. There is no surviving-claim list to compile, because no panel has ever construed or invalidated any of claims 1–N, and there is no final written decision to quote. If a demand letter cites this patent, the validity question is completely open — there is no PTAB outcome to leverage in either direction.

Estoppel landscape: empty — and that is the whole point. 35 U.S.C. § 315(e)(2) estops only a petitioner (and its real parties-in-interest and privies) that took a challenged claim to a final written decision. With zero petitions, no party is estopped as to US 6,182,136, and no prior-art ground has been "used up." A defendant today retains the full § 102/§ 103 universe: any patents, printed publications, and system-art combinations it can muster, in a district court, the ITC, or a first-ever IPR. Two practical caveats: (1) the patent's expired status means the realistic forum is a damages-only, past-infringement theory (plus, potentially, pre-expiration ITC activity), so weigh whether an IPR is worth the fee when § 282 court invalidity may suffice; and (2) run a § 315(b) clock check from the date your client was served — that one-year bar is live the moment suit is filed, and absent a prior petition there is no § 315(e) protection from the wait.

Pattern signals: none of the usual ones. There is no serial petitioner, no repeat-filer dynamic, no PTAB-appeal history for this patent (nothing to appeal), and no evidence of a defensive aggregator such as Unified Patents in this chain — the searches surfaced no Unified Patents challenge to this number. The absence of any IPR historically is itself the signal: consistent with an expired, pre-AIA, split-ownership infrastructure patent that was never aggressively asserted, rather than a hard-fought NPE campaign target. That distinguishes this patent sharply from the optical-filter Viavi dockets described above.

Recommended next steps

1. Do not describe this patent as "hardened by IPR" or as "narrowed by IPR." Neither is true. State to the client: no AIA trial has ever been filed on US 6,182,136; the ODP canonical list is empty, and web search confirms it. The defensible-sounding phrase here is "validity untested at the PTAB."
2. Verify the live legal status before relying on expiration. The Google Patents record shows "Anticipated expiration 2018-09-08" and "Expired - Lifetime." Confirm directly at USPTO Patent Center for US 6,182,136 and via the USPTO Maintenance Fee / Patent Center record whether any maintenance fee was late-paid or the patent revived, and whether any reissue, continuation, or continuation-in-part in the same family issued with claims still in force. A defendant's exposure may sit in a later-issued family member, not in the '136 patent itself.
3. If an infringement demand or suit is received: (a) calendar the § 315(b) one-year date from service; (b) quantify remaining assertable term (likely zero post-2018-09-08, so damages would be pre-expiration only); (c) assemble § 102/§ 103 art targeting the 1998-09-08 priority date and the pre-AIA claim set — the art space is unencumbered by estoppel; (d) if the theory is past damages and the art is strong, a district-court invalidity or license/royalty negotiation may dominate over an IPR of an expired patent.
4. No PTAB trial milestones apply. There is no institution-deadline, oral-hearing, or statutory one-year FWD due date to track, because there is no proceeding in which to track them.

Confidence and caveats: I am confident in the "zero AIA proceedings" conclusion based on the canonical ODP block plus multiple corroborating searches for IPR/PGR/CBM references tied to this exact patent number and to both the HP/Agilent and Viavi ownership chains. Web search is not a perfect substitute for docket-level completeness, so if you need a courtroom-grade negative, pull the certificate of correction/assignment and litigation docket history via USPTO Patent Center and a Lex Machina / Docket Navigator run on the patent number before filing anything that depends on the negative.

Sources cited: US 6,182,136 on Google Patents (filing/priority 1998-09-08, grant 2001-01-30, "Expired - Lifetime," anticipated expiration 2018-09-08, assignee chain HP → Agilent → JDS Uniphase → Viavi); Platinum Optics Technology Inc. v. Viavi Solutions Inc., No. 2023-1227 (Fed. Cir. Aug. 16, 2024) (appeal dismissed for lack of standing; concerning US 9,354,369, not the '136 patent); IPR2021-00631 FWD (P.T.A.B. Oct. 3, 2022) and IPR2022-01489 FWD (P.T.A.B. Apr. 11, 2024) (both Viavi optical-filter patents, not the '136 patent).

I'll research the assignment record for US 6182136 across the sources I can reach.

Ownership & Assignment Reconstruction — US 6,182,136 B1

Critical sourcing caveat up front. I was unable to complete a live pull of reel/frame numbers, execution dates, or the correspondent of record from the USPTO Assignment Center (assignmentcenter.uspto.gov / assignment.uspto.gov). Those fields are behind a query interface my tools could not reach in this session, and no web-search result surfaced them for this patent. Everything below is reconstructed from the Google Patents legal-events record for US 6,182,136 B1, which does document the conveyances, dates, assignors and assignees — but does not publish reel/frame or correspondent. Where the reel/frame and correspondent fields are called for, I have marked them NOT RETRIEVED rather than inventing them. Please re-run the Assignment Center query by patent number 6182136 to fill those two fields before relying on this for a filing.

Inventors

Pattern notes. The four inventors assigned to Hewlett-Packard Company on a single instrument recorded 1999-09-10, roughly 12 months after the 1998-09-08 filing date — an ordinary employment/batch-recording pattern, not a red flag. The specification contains internal HP-only artifacts (e.g., the discovery-module URL host ism-pc2, referencing HP's "Internet Services Management" program), which corroborates that the work was done inside HP rather than by an independent contractor. I could not verify whether any inventor left HP within 12 months of filing — no departure data was retrievable, so that specific fire-sale-precursor pattern is unclear / not determinable here.

Original assignee

Hewlett-Packard Company (original assignee of record; patent granted 2001-01-30).

• Line of business: Computer hardware, systems and software — at filing, HP was mid-way through the build-out of its Internet/network-management product line. The patent's subject matter (automated discovery of ISP service elements and service dependencies) maps to HP's Internet Services Management / service-modeling efforts, a real, shipped product direction rather than a paper portfolio.
• Product embodiment: HP (and later Agilent) did commercialize network/service management software in this family — the disclosed value proposition (auto-discovering DNS, MX-record, host, SMTP/POP3 and NFS dependencies to build a service health model) matches the "measures-of-service" tooling HP drove at the time. I have not independently verified a specific shipping build number, so treat "shipped product embodying the claims" as probable but unverified.
• Current status: Hewlett-Packard Company no longer exists as such — it was split (Hewlett Packard Enterprise / HP Inc., 2015) and, critically for this patent, the network test-and-measurement assets left HP for Agilent long before that. HP Inc. and Hewlett-Packard Development Company, L.P. still appear in Google Patents' "current assignee" field, but that is an artifact of the 2005-03-31 clarification recording, not the operating owner of this family (see below).

Assignment timeline

Recorded events below are from the Google Patents legal-events feed for US 6,182,136 B1. Execution dates were not exposed (only recording dates), and reel/frame and correspondent were not retrievable — flagged on every line.

• executed on/before 1998-09-08 (assumed) / recorded 1999-09-10 — Reel NOT RETRIEVED/NOT RETRIEVED

  • Conveyance: Assignment of interest (inventor-to-employer)
  • Assignor: Deborah L. Caswell; Marc Nijdam; Scott S. Neal; Srinivas Ramanathan
  • Assignee: Hewlett-Packard Company
  • Correspondent: NOT RETRIEVED — Assignment Center correspondent field not accessible; no recurrence determination possible.
  • Context: Standard employment assignment of the four inventors' rights to HP; acquisition (initial vesting).

• executed NOT RETRIEVED / recorded 2000-04-24 — Reel NOT RETRIEVED/NOT RETRIEVED

  • Conveyance: Merger
  • Assignor: Hewlett-Packard Company
  • Assignee: Hewlett-Packard Company
  • Correspondent: NOT RETRIEVED
  • Context: Internal reorg — same-name assignor/assignee signals a corporate restructuring/merger step with no change in beneficial ownership.

• executed NOT RETRIEVED / recorded 2000-08-22 — Reel NOT RETRIEVED/NOT RETRIEVED

  • Conveyance: Assignment of interest
  • Assignor: Hewlett-Packard Company
  • Assignee: Agilent Technologies, Inc.; Hewlett-Packard Company
  • Correspondent: NOT RETRIEVED
  • Context: Corporate spin-off — HP's 1999–2000 separation of its test-and-measurement/healthcare business into Agilent; this measurement-management family moved with it.

• executed NOT RETRIEVED / recorded 2001-01-30 — Patent granted / published (not an assignment)

  • Context: Prosecution event — US 6,182,136 B1 issues to Hewlett-Packard Company.

• executed NOT RETRIEVED / recorded 2004-10-08 — Reel NOT RETRIEVED/NOT RETRIEVED

  • Conveyance: Assignment of interest
  • Assignor: Hewlett-Packard Company
  • Assignee: Agilent Technologies, Inc.
  • Correspondent: NOT RETRIEVED
  • Context: Clean-up/confirmatory transfer — belt-and-suspenders documentation of the HP→Agilent split for this case (four years after the spin-off).

• executed NOT RETRIEVED / recorded 2005-03-31 — Reel NOT RETRIEVED/NOT RETRIEVED

  • Conveyance: Correction / "Clarification to Patent and Patent Application Assignment"
  • Assignor: Hewlett-Packard Company; Agilent Technologies, Inc.; Hewlett-Packard Development Company, L.P.
  • Assignee: Hewlett-Packard Company; Agilent Technologies, Inc.; Hewlett-Packard Development Company, L.P.
  • Correspondent: NOT RETRIEVED
  • Context: Housekeeping correction — three-way clarification of which post-split entity took which applications; this record is the source of the misleading multi-entity "current assignee" listing on aggregator sites.

• executed NOT RETRIEVED / recorded 2013-03-26 — Reel NOT RETRIEVED/NOT RETRIEVED

  • Conveyance: Assignment of interest
  • Assignor: Agilent Technologies, Inc.
  • Assignee: JDS Uniphase Corporation
  • Correspondent: NOT RETRIEVED
  • Context: Portfolio transfer between operating companies — Agilent's service-assurance/network-management patent assets conveyed to JDS Uniphase, an operating competitor in communications test and measurement. I could not identify the specific commercial agreement from the record retrieved.

• executed NOT RETRIEVED / recorded 2015-11-06 — Reel NOT RETRIEVED/NOT RETRIEVED

  • Conveyance: Change of name
  • Assignor: JDS Uniphase Corporation
  • Assignee: Viavi Solutions Inc.
  • Correspondent: NOT RETRIEVED
  • Context: Change of name only — JDSU renamed itself Viavi Solutions in the 2015 Lumentum split; no change in beneficial ownership.

• 2018-09-08 — Anticipated expiration (not an assignment).

  • Context: Term end — 20-year term from filing runs out; patent now expired.

Net effect: the chain is Hewlett-Packard Company → (spin-off) Agilent Technologies, Inc. → (asset transfer) JDS Uniphase Corporation → (rename) Viavi Solutions Inc., terminating in an operating company. Only seven recorded instruments exist; none introduces an LLC, licensing vehicle, or trust.

Timeline diagram

timeline
    title Ownership of US 6182136
    1998 : Application filed by Hewlett-Packard
    1999 : Inventors assign rights to HP
    2000 : HP internal merger recorded
         : Assignment of interest to Agilent
    2001 : Patent granted
    2004 : Further assignment for Agilent
    2005 : Clarification among HP Agilent HPDC
    2013 : Agilent transfers to JDS Uniphase
    2015 : JDS Uniphase renamed Viavi Solutions
    2018 : Patent expires

NPE / troll-pattern signals

1. Shell-entity transfer — not present. Every assignee in the chain (Hewlett-Packard Company, Agilent Technologies, Inc., JDS Uniphase Corporation, Viavi Solutions Inc.) is a long-lived public operating company. No "IP/Holdings/Ventures/Licensing" suffix appears, and no single-purpose Delaware/Texas LLC is present. Source: the seven conveyances recorded 1999-09-10 through 2015-11-06.

2. Known asserter in the chain — not present. I compared the assignee names against the listed NPE set (Acacia, Marathon, Intellectual Ventures, IPNav, Wi-LAN, Mosaid/Conversant, Vringo, Pendrell, Innovatio, MPHJ, Lumen View, Round Rock, Document Generation, Spangenberg entities) — no match at any link. The 2013 transferee, JDS Uniphase, is a communications test-and-measurement manufacturer, not an NPE.

3. Repeat correspondent across the chain — unclear / not determinable. This is the one signal I cannot score honestly, because the correspondent of record was not retrievable for any of the seven recordings (see NOT RETRIEVED markers above). I will not infer a repeat-player attorney from the entity names alone. Action item: pull the correspondent field for each of the seven reel/frame entries in the Assignment Center; if the same firm recurs on the 2000 Agilent spin-off entries and the 2013 JDSU entry, that is still likely ordinary corporate IP-department counsel rather than an NPE operator, since the parties are operating companies on both ends.

4. Cascading transfers — not present. There are two clusters — 2000-04-24 and 2000-08-22 (≈4 months apart, HP reorg + Agilent spin-off) and 2004-10-08 / 2005-03-31 (clean-up pair) — but these are corporate housekeeping between affiliated/successor operating entities, not a run of chained LLCs sharing a correspondent address. The substantive ownership change (2013) sits 13 years after the last previous transfer.

5. Pre-litigation transfer — not present on the record obtained. The last substantive transfer is 2013-03-26; no infringement suit naming US 6,182,136 B1 was surfaced in the sources I could reach, and the patent expired 2018-09-08. I found no assignment dated within 6 months before a first suit.

6. Bankruptcy fire-sale — not present. None of HP, Agilent, JDSU or Viavi went through Chapter 7/11 proceedings that sold this asset; the HP→Agilent and JDSU→Viavi movements were voluntary spin-offs/renames, and the Agilent→JDSU movement was a negotiated portfolio transfer, not a distressed sale.

7. Privateering — not present on the evidence available. The 2013 Agilent→JDSU transfer is operating-company-to-operating-company (JDSU builds network test gear and is a direct commercial rival of the network-management space). There is no SEC/EFF/Patent-Progress evidence in the material retrieved that JDSU took the patent to assert on Agilent's behalf; absent that, this stays not present.

8. Defensive aggregator — not present. The chain terminates at Viavi Solutions Inc., an operating company — not RPX, AST, LOT Network, Unified Patents or OIN. The patent was not neutralized by a defensive aggregator; it simply ran to term.

Verdict

Operating-company assertion — with an explicit evidentiary qualification. The entire chain is operating industrial/technology companies: the inventors assigned to Hewlett-Packard Company (recorded 1999-09-10), the family spun to Agilent Technologies (recorded 2000-08-22; confirmed 2004-10-08 / 2005-03-31), transferred to JDS Uniphase Corporation (recorded 2013-03-26), and finally renamed Viavi Solutions Inc. (recorded 2015-11-06) — a company that builds and sells network test-and-measurement products. Zero of the eight NPE signals is affirmatively present; the only unresolved signal (repeat correspondent) is unresolved purely because the Assignment Center correspondent field could not be pulled, not because of adverse evidence. I flag that the label "assertion" is not itself documented here — no suit naming this patent was found, and the patent expired 2018-09-08 — so read this as "operating-company-owned, non-NPE chain," which is the substance of the finding.

Verify at: USPTO Assignment Center — search patent 6182136 (mirror: assignment.uspto.gov/patent). Retrieve reel/frame and correspondent for the seven entries to close signals 3 and 5.

I'll search for the cited prior art on this patent. Note upfront: your task states "Current Date: April 26, 2026," but the authoritative system date for this analysis is 2026-09-23 (and the previously-generated sections used that date). I'll flag that inconsistency rather than silently reconcile it.

Let me pull the actual "References Cited" front-page data from patent databases.

Let me try to retrieve the front-page "References Cited" list directly from patent aggregators.

I hit the search-step limit while trying to pull the USPTO front-page "References Cited" table. Below is everything I could definitively verify, with the gaps stated plainly rather than filled in.

Prior Art Analysis — US 6,182,136 B1

0. Flags before the substance

0.1 Date contradiction (flagged, not silently reconciled).
Your task instruction says "Current Date: April 26, 2026." The authoritative system date for this analysis and the previously-generated sections is 2026-09-23. I am not picking one silently — the discrepancy is noted per the contradiction-flagging rule. It does not change the substance below (the patent expired 2018-09-08 either way).

0.2 Identifier caution (carried forward).
"6182136" is not a unique identifier. JP 6182136 B2 (publication 2017-08-16, a family member of WO 2013/003358 A2 on matrix metalloproteinase inhibitors) is an unrelated, differently-jurisdictioned document sharing the digits. Queries for the bare string return both. I am treating them as distinct documents and excluding JP 6182136 B2 from this prior-art analysis.

0.3 Retrieval limitation (stated plainly).
I was unable to retrieve the front-page "References Cited" table (examiner-cited U.S. Patent Documents / Other Publications) for US 6,182,136 from Google Patents, FreePatentsOnline, SumoBrain, uspto.report, or Justia within the search budget. I therefore cannot present the complete examiner-cited prior-art list, and I will not fabricate plausible-looking citations (e.g., I deliberately did not assert US 5,913,041, US 5,655,081, US 5,751,964, etc., because I found no evidence tying any of them to this patent). What I can present are the references verified as cited within the patent's own text (the Background Art section), which are also the references the specification affirmatively discusses and distinguishes.

0.4 Litigation/IPR caveat (carried forward). No 2026 CAFC docket, IPR, or litigation activity naming US 6,182,136 was found. The patent is Expired – Lifetime (anticipated expiration 2018-09-08). The §102 exercise below is therefore a retrospective/hypothetical validity analysis, not a live-controversy analysis.

1. Verified references cited in US 6,182,136

These three are confirmed, verbatim, from multiple independent sources (Google Patents, FreePatentsOnline, SumoBrain) — all three appear in the patent's Background Art, where the applicant describes and then distinguishes them. They are applicant-discussed art; whether they also appear on the printed front page as examiner-cited art I could not confirm.

Verbatim grounding for the above (from the specification's Background Art):

"U.S. Pat. No. 5,276,789 to Besaw et al. and U.S. Pat. No. 5,185,860 to Wu, both of which are assigned to the assignee of the present invention, describe such systems."
"Another approach is described by J. L. Hellerstein in an article entitled 'A Comparison of Techniques for Diagnosing Performance Problems in Information Systems: Case Study and Analytic Models,' IBM Technical Report, September, 1994. Hellerstein proposes a measurement navigation graph (MNG)…"

2. §102 analysis — do R1–R3 anticipate?

Statutory frame. US 6,182,136 was filed 1998-09-08 and is pre-AIA. The controlling provisions are pre-AIA §102(a) (known/used by others before invention), §102(b) (patented or described in a printed publication more than one year before the U.S. filing date — i.e., before 1997-09-08), §102(e) (earlier U.S. application/patent), and pre-AIA §103. Anticipation under §102 requires that a single reference disclose every element of the claim, arranged as in the claim. All three references pre-date 1997-09-08, so each is at least §102(b)-eligible art as to its disclosure — the question is whether it discloses the claimed subject matter.

Critical threshold issue — the independent claims require a "discovery template" and a "discovery engine."
As verified below (§3), the system independent claim (claim 15) requires (i) a stored discovery template specific to the core service to be modeled, containing data indicative of selected service elements anticipated as cooperating, and data indicative of selected discovery module means; (ii) discovery engine means connected to access the template and automatically invoke the selected module means; and (iii) a specific control relationship — "said discovery template controls said discovery engine means and … said discovery engine means controls said discovery module means" — with outputs recorded "independently of said discovery template." None of R1–R3 is even alleged to disclose any of that.

Narrower observation on where R1/R2 could touch claim limitations (not anticipation):

• R1 (Besaw '789) relates to two recurring claim concepts: (a) discovering/linking network elements, and (b) generating a graphical representation of interlinked nodes. Those concepts appear as limitations such as the graphical-representation element of claim 17 ("…service model instance engine means for generating a graphical representation of said core service… said graphical representation including nodes representing said service elements…"). Because claim 17 is dependent on claim 16 (which depends on independent claim 15), R1 cannot anticipate it — a dependent claim incorporates every limitation of its parent, and R1 lacks the parent's service-specific-template/engine limitations. At most, R1 is §103 background art directed to the graphical-representation aspect. This is not, and should not be pleaded as, §102 anticipation.
• R2 (Wu '860) is similarly limited to element/host discovery, not service-dependency modeling; no §102.
• R3 (Hellerstein) is the conceptually closest on dependency modeling, but it models measurements, and the patent expressly distinguishes it. No §102.

Bottom line: On the record I can verify, none of R1–R3 anticipates any of claims 1–21 under §102(a)/(b)/(e). They are properly characterized as §103 background/obviousness-type art that the patent distinguishes over. I cannot rule out an examiner-cited reference (unretrieved — §0.3) that might be more on point; see §5.

3. ⚠️ Correction to the previously-generated sections (claim 15 is the independent system claim, not claim 18)

This is a contradiction I must flag explicitly, per the cross-reference rule. The earlier "Patent summary" section stated:

"…I can identify claim 18 as an independent system claim." and "Claim 18 — System (means-plus-function) … Confidence: high that claim 18 is an independent system claim…"

Newly retrieved claim text contradicts this. A SumoBrain capture of the claim set shows:

16. The system of claim 15 wherein at least some of said discovery module means are configured to generate outputs indicative of selected services…
17. The system of claim 16 further comprising a service model instance engine means for generating a graphical representation of said core service…
18. The system of claim 16 wherein said discovery template further includes information indicative of operational dependencies among said discovery module means…
19. The system of claim 18 wherein said discovery template has an arrangement that controls a sequence of invoking said selected discovery module means…
20. The system of claim 18 wherein said discovery engine means determines a sequence of invoking… 21. The system of claim 18 wherein said discovery module means cooperate to determine a sequence…

Conclusion: Claim 15 — not claim 18 — is the independent system claim. Claim 18 is dependent (15 → 16 → 18), and claims 19–21 depend from claim 18. The earlier section's identification of claim 18 as independent, and its "reconstruction" of claim 18's element list, are superseded. The earlier section's verbatim quotes of claims 20 and 21 remain accurate. The dependency chain also means the earlier header "Independent claim 18 — System (means-plus-function)" should be read as "Dependent claims 16–21 (rooted in independent claim 15)."

Verified independent claim 15 (partial verbatim, from SumoBrain; preamble not captured):

"…a stored discovery template that is specific to said core service to be modeled, said discovery template including data indicative of selected said service elements which are anticipated as being cooperative in execution of said core service, said discovery template further including data indicative of selected discovery module means for identifying said selected service elements, said discovery engine means being connected to access said discovery template such that said discovery engine means automatically invokes said selected discovery module means; wherein said discovery template controls said discovery engine means and wherein said discovery engine means controls said discovery module means, said outputs that are indicative of said service elements being recorded for representation of said core service independently of said discovery template."

This matters for the prior-art question: the §102/§103 target for the system side is claim 15, whose "template controls engine, engine controls modules" limitation is the element R1–R3 most clearly lack.

(I still do not have verified text of any method claim (claim 1 or otherwise). The existence of a method independent claim remains inferred from the Summary of Invention, not confirmed.)

4. Forward citations found (NOT prior art — listed only to prevent mischaracterization)

These are later documents that cite US 6,182,136 (i.e., "Cited By"). Because they post-date the 1998-09-08 filing, they cannot be §102 prior art against US 6,182,136. Included so this analysis isn't confused with the earlier "family member" discussion:

• US 2003/0005104 A1 — "Server configuration tool" — cites US6182136B1.
• US 2002/0143905 A1 — "Method and apparatus for discovering network topology" — cites US6182136B1.
• US 7,185,109 — "Recursive discovery of CDP type of nodes…" — lists US 6,182,136 (Ramanathan et al., Jan. 30, 2001) in Referenced Cited.
• US 10,394,527 and US 10,911,314 — also list 6182136 (Ramanathan et al.).
• US 6,336,138 (Hewlett-Packard; "Template-driven approach for generating models on network services") — sibling/related application sharing inventors (Caswell, Ramanathan, Neal); it pre-dates the 6182136 filing (filed 1998-08-25). It is a related family document, not prior art against 6182136 on these facts (common ownership / co-pending), and the earlier section's note that the two should not be merged stands.

5. Explicit uncertainties and what still needs verification

1. The front-page examiner-cited "References Cited" list for US 6,182,136 was NOT retrieved. This is the single material gap. The three references analyzed (Besaw '789, Wu '860, Hellerstein) are verified as cited in the specification's Background Art, but I cannot confirm they are the complete front-page list, nor whether additional examiner-cited U.S. patents exist. Provide the printed front page (or USPTO PatentCenter "References Cited") and I will analyze every remaining citation.
2. US 5,276,789 filing date not verified (issue date Jan. 4, 1994 verified via Justia listing on US 7,185,109). US 5,185,860 issue date (Feb. 9, 1993) is stated with moderate confidence and needs confirmation.
3. No method-claim text verified. Claims 1–14 were not captured; whether claim 1 is the method independent claim is inferred, not confirmed. Any §102 statement about method claims would be speculative.
4. No §102 anticipation found for any claim, on verified art. Do not convert the "§103 background art" characterization of R1–R3 into an anticipation position.
5. Nature of the citations: the specification discusses and distinguishes R1–R3, which is itself evidence the applicant regarded them as the most relevant known art — but "distinguished in the background" ≠ "examiner-cited." Confirm on the front page.
6. Identifier hygiene: continue filtering JP 6182136 B2 out of any "6182136" result set.

Candid overall assessment: Based solely on the references I could verify, the most relevant prior art for US 6,182,136 consists of Besaw '789, Wu '860, and the Hellerstein IBM Technical Report (Sept. 1994) — and none of them anticipates any claim. I could not verify the full examiner-cited set, and I have deliberately declined to name additional references I could not ground.

I'll ground this in the actual prior-art record. A few searches first — note the instruction says "use the results from the Prior Art section of this page," but the fetched page text does not include a prior-art citation table, so I need to retrieve it.

The search returned mostly noise plus the three references I already knew from the spec. Let me pull the actual "References Cited" table and check a few candidate §102/§103 references.

Obviousness Analysis — US 6,182,136 B1 under 35 U.S.C. § 103

Current date for this analysis: April 26, 2026. (Note: the system timestamp on the source page is 2026-09-23. I flag the discrepancy rather than silently reconciling it.)

0. Correction to a previously generated section — flagged per instructions

The prior "Patent summary" section asserted that claim 18 is an independent system claim and that "at least two independent claims (one method, one system)" exist. A retrieved mirror of the printed claims (SumoBrain, https://SumoBrain.com/patents/us/Automated-service-elements-discovery-using/[6182136](/patent/6182136).html) shows that claim 18 is NOT independent:

Claim 15 is the true independent system claim, and its characterizing clause reads: "wherein said discovery template controls said discovery engine means and wherein said discovery engine means controls said discovery module means, said outputs that are indicative of said service elements being recorded for representation of said core service independently of said discovery template."

The verbatim text of claims 20 and 21 quoted in the prior section is confirmed by this source. The prior section's inference as to claim 18 is refuted and should not be relied on. The mirror is a third-party reproduction and should be re-verified against USPTO PatentCenter or the printed columns; claims 1–14 still remain unverified.

1. Evidentiary caveat about "the Prior Art section of this page"

The fetched Google Patents text supplied to me contains only two prior-art fields:

• Prior art keywords: discovery, service, template, services, dependencies
• Prior art date: 1998-09-08

It does not contain the examiner/Google "References Cited" table or the "Cited By" table. I attempted to retrieve that table and was cut off by the search-step limit. Accordingly, I cannot present the actual examiner-cited art. What I can ground with citations is:

Items (a)–(c) are not "references cited by the examiner" — they are the patentee's own identification of the prior art, which under In re Fout / MPEP 2129 is an admission usable for §103. That is the most defensible evidentiary footing I have here.

Everything else below that is not from (a)–(d) is my own identification of field art, and I mark confidence accordingly. I could not verify US 5,996,090's filing date this session, and my attempt to verify RFC 2165 and US 6,336,138 was cut off. I will not assert those dates as fact.

2. Legal framework (pre-AIA, correct for a 1998-09-08 filing)

The patent is pre-AIA (filed 1998-09-08; priority 1998-09-08). The governing test is pre-AIA §103(a) as construed by Graham v. John Deere (scope/content of art; differences; PHOSITA level; objective indicia) and KSR Int'l v. Teleflex. Under KSR, a combination is obvious where (i) elements are known, (ii) combined according to known methods, (iii) to yield no more than predictable results; motivation may come from the nature of the problem, design incentives/market forces, or "a finite number of identified, predictable solutions." Pre-AIA §103(c) common-ownership disqualification is potentially relevant (see §7). The critical date is 1998-09-08.

PHOSITA: a network-management engineer with ~2 years' experience in TCP/IP network management and service-monitoring tooling (DNS BIND, SNMP MIBs, NFS, POP3/SMTP), plus ordinary familiarity with declarative build/specification tooling.

3. Reference-by-reference teaching map (claim 15 elements)

Claim 15 (independent, §112(f)) breaks into: (A) stored discovery template specific to the core service listing anticipated service elements; (B) module means for identifying them; (C) engine means that automatically invokes the modules; (D) template controls engine, engine controls modules; (E) outputs stored independently of the template.

Two points matter:

1. The patent itself concedes that the discovery modules are old. The specification states the host-discovery and DNS techniques are "known in the art," that the two traditional host-discovery approaches are existing practice, and that network probes and special-purpose agents are each "one approach" already available. So (B) is largely admitted art.
2. The patent itself concedes the schema/instance architecture is old, analogizing the template↔instance relationship to "the relationship between the schema and records in a database," and expressly naming DMTF's Common Information Model as an equivalent specification technology. That concession is important: an external, service-specific schema driving a generic engine is presented by the patentee as conventional.

What is not squarely shown by (a)–(c): a template that is specific to a service (rather than to a device/measurement), and template-borne module-to-module dependencies used for sequencing.

4. The core obviousness combinations

Combination 1 (base) — for claims 15 and 16

Besaw '789 + Wu '860 + applicant-admitted DNS/SNMP/ping discovery + a declarative specification-with-dependency-manifest. (The "make"/dependency-manifest and CIM-schema concepts are my additions; the "make" concept is well-established art — Feldman, Make — A Program for Maintaining Computer Programs, 1979.)

• Why combine: The problem the patent itself articulates is extension without redesign — the existing systems "discover and manage service elements in isolation" and are "implemented in a monolithic manner … Adding new discovery and management capabilities … requires extensive redesign." That is a stated design incentive, not hindsight. KSR recognizes exactly this rationale.
• Why the result is predictable: Once you have Besaw's agents populating a node/edge store, and you know (as of 1998) to externalize configuration into a declarative file so a generic driver can read it, moving what to discover out of the engine and into a manifest is the predictable use of known elements for their established functions.
• Claim 16 (some modules also output services, not just elements) is met by the admitted DNS-based inter-service discovery: the applicant concedes MX/NS record processing already yields mail-server↔POP3 server relationships, i.e., service-level outputs, not just element outputs.

Combination 2 — for claim 17 (graphical service model, engine independent of the template)

Combination 1 + Besaw's three-view graphical display.

Besaw expressly discloses "internet view," "network view," and "segment view" of a node/interconnection graph, and periodic re-querying of discovery agents to detect added nodes. Applying that display to a service-oriented graph (nodes = services/elements) is a use of a known technique (topology graphing) to improve a similar device (a service graph) in the same way, which KSR holds obvious. The "service model engine being independent of the discovery template" limitation is squarely taught by US 5,996,090's stated architecture of separating structural knowledge and diagnostic knowledge from the engine, and by the patentee's own schema/records analogy.

Combination 3 — for claims 18, 19, 20 (dependency information in the template; template ordering; engine-determined ordering)

Combination 2 + dependency-manifest scheduling (make-style prerequisite lists) + topological sort (Kahn 1962; PERT/CPM project scheduling).

This is the strongest attack on the claims' asserted point of novelty, because the claims' sequencing limitations (18–20) map function-for-function onto a build system:

• Motivation: network discovery is a multi-stage process with real inter-stage data needs (you cannot probe mail-server↔NFS links until you know which hosts are mail servers — the patent concedes this by making internal Phase-2 discovery consume Phase-1 output). Any PHOSITA presented with "module B needs module A's output" reaches for the standard dependency-ordering solution.
• Predictability: dependency-ordered execution was a "finite number of identified, predictable solutions" — a topological sort — satisfying KSR.

Combination 4 — for claim 21 (modules cooperate to determine sequence)

Combination 3 + event-driven / publish–subscribe notification (interest registration and callback notification, standard in 1990s distributed systems and network management — e.g., SNMP trap/event forwarding, OSI X.700 event-report management, and generic observer patterns).

The patent concedes the mechanism is known and merely "adds complexity," while noting it "allows the modules to execute in parallel." That concession converts the limitation into a known trade-off (parallelism vs. complexity) — the classic KSR "predictable variation" scenario.

Alternative primary combination — for claims 15–16 from a service-discovery starting point

Service Location Protocol, RFC 2165 (Veizades et al., June 1997) — confidence: moderate; I could not re-verify the RFC date this session — plus Besaw and a dependency manifest. SLP already provides per-service-type templates describing service attributes and a discovery architecture (user agents / service agents / directory agents). If the SLP service-template teaching is credited for element (A), then the remaining delta is dependency-driven module sequencing, addressed by Combination 3. I flag this as my own reference identification, not from the page's Prior Art section.

5. Graham-factor scoring (honest assessment)

6. Counter-arguments a patentee would raise, and their strength

1. Non-analogous art (build systems). Under In re Bigio / In re Klein, field-of-endeavor and problem-solved tests apply. A patentee would argue make is software-build art, not network management. Strength: moderate. The counter is that the problem solved (dependency-ordered invocation of plug-ins from a declarative spec) is the same, and KSR's "known technique improves similar devices in the same way" standard is forgiving.
2. "Teaching away" by Besaw/Wu. The patentee calls them monolithic and non-extensible. Strength: weak. That is the applicant's characterization of the problem, not a reference teaching away from the solution; and the patentee's own admission supplies the motivation.
3. No motivation to make the template service-specific. Strength: weak-to-moderate. But the patent's own Background supplies the motivation: ISPs must "measure and manage the QoS of their service offerings," and services are the unit of subscriber-visible degradation.
4. The combination changes the principle of operation of Besaw/Wu (hardware topology → service dependency graph). Strength: weak under KSR, which rejected the rigid "teaching away/maintains operability" formalism.
5. Secondary considerations without nexus. Strength: neutral absent evidence.

7. Secondary legal notes

• Pre-AIA §103(c): US 6,336,138 ("Template-driven approach for generating models on network services," HP) was identified in the prior section as filed 1998-08-25, two weeks before the 6,182,136 filing, sharing inventors and assignee. If the two share a common owner/inventive entity, common-ownership disqualification may remove it as §103 art; if the inventive entity differs, it may qualify as §102(e) art as of its filing date. I could not verify that record this session — treat as open. Also beware double patenting exposure on the same template concept.
• Means-plus-function scope: claim 15's "engine means" is bounded by the disclosed structures — template parser 142, module loader 144, query processor 148, discovery instance generator 150 (FIG. 13). Prior-art engines need only perform the claimed function; for §103 the disclosed structure guides the inquiry but does not narrow the prior-art comparison as much as it narrows infringement.
• The patent expired 2018-09-08. This analysis is retrospective; it matters only for historical validity/valuation or defensive use.

8. Bottom line (confidence-weighted)

Most probable real-world outcome of a §103 challenge: claims 15–21 would be vulnerable on a Bess-style combination of Besaw/Wu (or an analogous topology-discovery patent) in view of an external-representation/declarative-driver reference such as US 5,996,090, in further view of the applicant's own admitted DNS/SNMP discovery techniques, with the dependency-sequencing limitations met by ordinary dependency-ordering practice. The defense would rest on the absence of a service-specific template with module dependencies, which is genuinely narrow and which no retrieved reference squarely teaches.

9. Explicit uncertainties

1. I did not obtain the page's actual Prior Art / References Cited table. Everything above is built from the patent's Background Art admissions plus four identified references. Re-run against Google Patents' "References Cited"/"Cited By" tables, USPTO PatentCenter, and a PTAB/IPR search.
2. Claims 1–14 are unverified, and the claim 15–21 text comes from a third-party mirror, not the printed patent.
3. US 5,996,090's filing date is unverified (my verification attempt was cut off). If it post-dates 1998-09-08 in relevant part, it drops out.
4. RFC 2165 / SLP date and content — moderate confidence only; not verified this session.
5. US 6,336,138's inventive entity and filing date — carried over from the prior section without independent verification; the §103(c) / §102(e) analysis in §7 therefore has an unresolved premise.
6. This is a technical analyst's obviousness assessment, not a legal opinion and not a validity determination.