I'll search for US patent 7454496 in the USPTO database and any CAFC 2026 docket references.

Let me run additional targeted searches for the claims text and any CAFC litigation.

Based on my searches of Google Patents, Justia, and other sources, here is a concise summary of US Patent 7454496.

Note on methodology: My searches returned results for exactly this patent number (US7454496B2 / application 10/732,736) and did not surface any CAFC 2026 docket entries involving this patent — I found no Federal Circuit litigation record for 2026 (or otherwise) in the results. The patent's legal status on Google Patents is listed as Active, expires 2026-05-28 (adjusted expiration), with current assignee PayPal Inc. (after assignments from IBM → eBay Inc. (2012) → PayPal, Inc. (2015)).

Bibliographic Data

Abstract (as published)

A method monitors data resources of a data processing network on behalf of a new consumer. The method comprises determining monitoring requirements of the new consumer. The monitoring requirements include: a list of data resources monitored for the new consumer; metrics of the monitoring data for the new consumer; a data format for monitoring data provided to the new consumer; a time interval between periods of sending the monitoring data to the new consumer; and actions taken during failure of the data resource. The method also includes comparing the monitoring requirements of the new consumer with monitoring capabilities of a plurality of monitoring entities to identify at least one monitoring entity, including monitoring capabilities matching the monitoring requirements of the new consumer.

Independent Claims — Plain-Language Overview

The granted patent follows the classic IBM method/system/computer-readable-medium claim set. Based on the granted patent text and the claim language visible in the Justia records (claims 9, 12, 13 shown) and the pre-grant publication US 2005/0132041 (claims 1–14), the independent claims are approximately:

Claim 1 — Method (the core method claim).
A method of monitoring data resources of a data processing network on behalf of a new consumer. Steps: (a) determine the new consumer's monitoring requirements — specifically a list of data resources to be monitored, the metrics of the monitoring data, the data format for delivering monitoring data, the time interval between periodic data deliveries, and the actions to be taken if the data resource fails; (b) compare those requirements against the monitoring capabilities of multiple monitoring entities (the entities monitor the data resources), where capabilities include which resources are currently being monitored, which resources each entity can monitor, which metrics are currently monitored / can be monitored, the current monitoring period, and data-format capabilities; (c) identify at least one entity whose capabilities match; (d) select one or more identified entities and bind the new consumer to them — binding means establishing a connection, sending the consumer's requirements description to the selected entity, and configuring the entity to perform the requirements; and (e) if no entity matches all requirements, initiate a negotiation between the consumer and the entities to select the best match based on quality-of-service (QoS) parameters. (In plain terms: automatically match a new monitoring-data customer to the right monitoring agent, wire them together, and fall back to QoS-based negotiation when no perfect match exists.)

Claim 9 — Data processing system (system claim mirroring claim 1).
A data processing system comprising a data storage unit (storing the consumer's monitoring requirements and each monitoring entity's capabilities, as listed above) and a monitoring manager that, responsive to the new consumer's requirements: compares requirements against the stored capabilities to identify a matching entity; in response to a match, selects and binds the consumer to the entity (connection establishment + sending requirements + configuring the entity); and in response to no full match, initiates QoS-based negotiation to select the best-fit entity.

Claim 12 — Distributed data processing system.
A distributed system comprising: a set of data processing apparatuses each having at least one resource; a set of apparatuses each having at least one consumer requiring monitoring data for a resource; at least one data storage unit storing a repository of consumer monitoring requirements and monitoring-entity capabilities (same requirement/capability lists as claim 1); and a monitoring manager that compares the new consumer's requirements against stored capabilities, identifies and binds a matching monitoring entity, and falls back to negotiation if no entity matches all requirements. (In plain terms: the same matching/binding/negotiation logic, but spread across multiple networked data processing apparatuses rather than a single system.)

Claim 13 — Computer storage device (computer-program-product claim).
A computer storage device tangibly storing instructions executable by a computer to perform the method of claim 1 — i.e., determining the new consumer's monitoring requirements (resources, metrics, format, interval, failure actions), comparing them with monitoring-entity capabilities, identifying/selecting/binding a matching entity (connection + requirement transmission + configuration), and initiating QoS-based negotiation when no full match exists.

Dependent claims (visible in the publication and Justia records) add details such as: comparing against currently active capabilities (cl. 3), metric capabilities (cl. 4), monitoring-period capabilities (cl. 5), granularity capabilities (cl. 6), data-format capabilities (cl. 7); publishing requirements/capabilities to a repository (cl. 8); the monitoring manager having registration/de-registration, selector, and connection-manager components (cl. 10); a resource optimizer (cl. 11); and use of a common sub-expression finder (cl. 14).

Caveats / Uncertainty

• I did not find any CAFC 2026 docket or litigation referencing 7454496 in my searches; that should be treated as "no results found," not confirmation of non-existence.
• The exact granted text of claim 1 was not reproduced verbatim in my search results; my overview of claim 1 is reconstructed from the specification's Summary section (which mirrors it) and the claim structure evident in claims 9–13. The wording of claim 1 in the granted patent should be verified against the USPTO full-text if exact claim language is needed for legal purposes.
• Assignee history (IBM → eBay → PayPal) is from Google Patents assignment records, which Google itself flags as potentially inaccurate (an "assumption," not a legal conclusion).

The initial searches returned no relevant results — only unrelated patents (e.g., 8,723,164; 8,314,547; 9,454,748; 7,463,703). Let me run more targeted searches on litigation databases and docket sources.

Based on my searches, I have no record of any litigation involving US Patent 7,454,496 in the sources I could access. I cannot provide the requested case-by-case table (plaintiff, defendant, jurisdiction, case number, filing date, outcome/status) because no such cases were found — not because the search was ambiguous, but because every query for this specific patent number came back either empty or with unrelated results.

Searches performed (April 26, 2026)

Conclusion

No known litigation involving US Patent 7,454,496 was identified.

• No district-court case (e.g., in E.D. Tex., D. Del., N.D. Cal., or other venues) naming 7,454,496 was found.
• No Federal Circuit (CAFC) appeal, no PTAB/IPR proceeding (though IPR searches weren't separately run as a dedicated query), and no Unified Patents caselist entry referencing this patent was found.
• The only relevant data point from a litigation-focused database (Unified Patents) is a cross-reference to the patent on another patent's page — not a case.

Caveats — please read before relying on this

1. This is "no results found," not proof of non-existence. General web search does not fully index PACER's paywalled docket text, and some docket databases (DocketNavigator, RPX, LexisNexis IP, Westlaw) require subscription access I did not have. A complete negative confirmation would require a paid PACER full-text search across all federal districts, plus searches of the PTAB's IPR database (PTAB docket search at uspto.gov) and the CAFC's own docket system (CIPHER/pacer for the Federal Circuit).
2. No CAFC 2026 docket entry was found — consistent with the earlier analysis in the patent summary, which also found no Federal Circuit litigation for this patent.
3. The patent expired (adjusted) on 2026-05-28 — roughly one month after today's date (2026-04-26). It is currently in its final weeks of term, assigned to PayPal Inc. (IBM → eBay Inc. (2012) → PayPal, Inc. (2015)). Its age (filed 2003, issued 2008) and NPE-inactive owner profile (an operating company, PayPal, that acquired it via the eBay/IBM transfer) may explain the absence of public assertion activity — but that is inference, not verified fact.
4. If you need a definitive answer for a clearance, diligence, or invalidity project, I'd recommend: (a) a paid PACER nationwide party search for "7,454,496" / "7454496"; (b) the USPTO PTAB API/docket search for IPR/PGR/CBM petitions citing it; and (c) the CAFC's electronic docket. I can walk you through drafting those queries if useful.

Bottom line: As of April 26, 2026, I have no knowledge of any pending or concluded litigation (district court, CAFC, or PTAB) involving US Patent 7,454,496, and no case list can be provided because none was found.

Proceedings overview

Total AIA trial proceedings on file: 0 — no IPRs, no PGRs, no CBMs, no derivation proceedings (breakdown by status: active 0 / claims invalidated 0 / claims sustained 0 / settled 0 / institution denied 0). The canonical USPTO Open Data Portal block supplied with this prompt returns no AIA trial proceedings for US 7454496, and my independent web searches (PTAB petition listings, reexamination databases, PTAB trial trackers, and litigation/assignment records) surfaced no public record of any PTAB petition, institution decision, Final Written Decision, or Federal Circuit appeal involving this patent. The defensive bottom line: there is no PTAB history to rely on or to fear — no claim of 7454496 has ever been canceled or even challenged in an AIA trial, and no estoppel has ever been triggered against any petitioner.

There are therefore no per-proceeding sections to report. I will not invent proceeding numbers, panels, or grounds. What follows is the honest strategic read of a clean PTAB docket.

Strategic summary

Claim status — all UNTESTED, none CANCELED, none SUSTAINED. Because the PTAB docket is empty, every claim of US 7454496 (independent claims 1, 9, 12, 13 and the dependent claims) stands exactly as granted on 2008-11-18. There is no Final Written Decision, no partial institution narrowing the issues, and no claim construction from a PTAB panel that a later defendant could exploit. "Untested" is the correct label, but that is a double-edged sword: it means the patent has never been weakened and never been hardened by a Board decision. Anyone telling you "the patent survived IPR, so it's strong" or "claims 1–5 were canceled" is describing a proceeding that does not exist.

Estoppel landscape — § 315(e)(2) is a blank slate. No petitioner has ever filed, so no petitioner (or privy) is barred from raising any § 102/§ 103 ground that was raised or reasonably could have been raised. For a defendant facing assertion today, every prior-art ground remains fully available — in district court (where the Kessler/Commil-era standards and the lack of any Board estoppel mean you can run the full invalidity case) and in a hypothetical future IPR petition. The practical caveat: the window for challenging this patent at the PTAB at all is effectively closed or worthless. The patent's priority date is 2003-12-10, so it is pre-AIA (PGR and CBM are statutorily unavailable — no CBM after the September 16, 2020 sunset, and PGR only for first-inventor-to-file patents). IPR is the only AIA vehicle that could ever have applied, and Google Patents lists the patent's adjusted expiration as 2026-05-28 — which, as of today (2026-08-21), has already passed. An IPR against an expired patent is generally non-instituted or moot absent a live controversy with continuing damages exposure, so the PTAB route is, for practical purposes, dead.

Pattern signals — none. There is no repeat petitioner, no defensive-aggregator presence (no Unified Patents, no OpenSky, no RPX filing on this patent), and no aggressive Patent Owner PTAB posture to study. The assignee chain (IBM → eBay Inc. 2012-12-26 → PayPal, Inc. 2015-07-22) shows the patent moving through the classic IBM divestiture pipeline to a non-practicing-operating hybrid, but that corporate history has produced zero PTAB activity. The absence of IPRs across roughly a decade of heavy assertion-era litigation (2013–2026) is itself a signal worth weighing: either the patent was never asserted in a way that provoked a petition, or challengers concluded the art landscape and claim scope didn't justify the spend — or, most likely given the 2026 expiration, the monetization window simply ran out before a fight became worthwhile.

Recommended next steps

• First, verify expiration before anything else. The single most important fact for a defendant is not the PTAB docket but the patent's term. Google Patents' "Active, expires 2026-05-28" is an estimated adjusted expiration; confirm the actual expiration date (20 years from 2003-12-10 plus any PTA, minus any terminal disclaimers) via USPTO Patent Center for the '736 application. If the patent is expired as of the accused conduct, there is no liability for post-expiration acts, damages are confined to the pre-expiration period (and any laches/§ 286 look-back issues), and an IPR is a waste of money — the PTAB will not institute on an expired patent absent a separately proven ongoing injury.
• If you are nevertheless sued and the accused acts predate expiration, you face a clean invalidity fight in district court with no § 315(e)(2) estoppel and no Board claim constructions to overcome. Run the full § 102/§ 103 case. For a 2003-vintage distributed-monitoring patent, the natural art is network/system-management prior art: HP OpenView, IBM Tivoli, BMC Patrol, SNMP-based RMON, Grid/OGSA monitoring literature, and UDDI/Web-services discovery art (the specification itself cites UDDI and DB2-era monitoring concepts). Given claims 1, 9, 12, 13 recite matching consumer monitoring requirements (resources, metrics, format, interval, failure actions) against entity capabilities and then binding, look for old workload-management and QoS/SLA frameworks with capability-advertisement plus negotiation — that combination was well-worn by 2003.
• If a demand letter cites the PTAB as leverage, call the bluff. There is no PTAB proceeding, no FWD, no estoppel, and no canceled claim — the docket is empty. That is verifiable in seconds on USPTO PTAB E2E (search patent number 7454496) and via the ODP API, and you should cite the zero-result search in any correspondence.
• Do not file an IPR unless (a) the patent is definitively unexpired and (b) you are within the one-year § 315(b) bar from service of a complaint. Otherwise the petition is institution-bait and the $ tens-of-thousands in fees buys nothing.

Honest caveat: This conclusion rests on the ODP structured data in the prompt plus my searches, which returned no PTAB matter. ODP ingestion can lag, and a petition filed in the last few weeks could theoretically exist that neither source has indexed yet — if you have a live dispute, do a same-day PTAB E2E lookup by patent number before relying on this memo. But on everything currently on file: US 7454496 has never been through an AIA trial, every claim remains in force exactly as granted, and the patent appears to have already expired — the PTAB is not where this fight will be won or lost.

I'll research the assignment history for US 7454496, starting with the USPTO assignment records and cross-referencing with other sources.

Let me dig into the specific assignment records for this patent, including the IBM-to-eBay and eBay-to-PayPal transfers.

Let me try more targeted searches on the assignment database records.

I've exhausted my search budget. Before drafting, here's my sourcing note: I could not pull the USPTO Assignment Center records directly (no reel/frame numbers or correspondent names surfaced in my searches), so the assignment dates and parties below come from the Google Patents legal-events feed for US7454496 (which mirrors USPTO-recorded conveyances) and the Unified Patents portal entry. I have not fabricated any reel/frame or correspondent data; where those are unknown, I say so.

Inventors

• Ashish Kundu (Orissa, IN) — sole named inventor. Employer at filing: International Business Machines Corporation, per the 2003-12-10 recorded assignment of assignor's interest (Assignor: KUNDU, ASHISH → IBM), which is the standard employee-invention assignment executed at filing.
• Pattern check: single inventor, no mass-departure or post-filing exodus pattern. No red flag.

Original assignee

• International Business Machines Corporation (IBM) — named on the issued patent (application filed 2003-12-10, granted 2008-11-18).
• Line of business: enterprise hardware, software, and services; at filing this patent sat in IBM's distributed-systems/autonomic-computing research space (the specification tracks IBM's Tivoli/monitoring and grid/autonomic computing messaging). I found no evidence that IBM shipped a specific commercial product embodying these claims; the patent reads as a platform/framework patent.
• Current status: operating (IBM remains a major operating company). IBM divested this patent in December 2012.

Assignment timeline

Recorded conveyances (per Google Patents legal events; reel/frame not retrieved — see sourcing note):

• 2003-12-10 (executed and recorded same date per event feed) — Reel/frame not retrieved

  • Conveyance: Assignment of Assignor's Interest
  • Assignor: Ashish Kundu
  • Assignee: International Business Machines Corporation
  • Correspondent: not retrieved
  • Context: standard employee-invention assignment at filing (IBM internal; no commercial significance).

• 2012-12-26 (recorded) — Reel/frame not retrieved

  • Conveyance: Assignment of Assignor's Interest
  • Assignor: International Business Machines Corporation
  • Assignee: eBay Inc.
  • Correspondent: not retrieved
  • Context: portfolio divestiture by IBM to eBay; consistent with IBM's practice of monetizing patent portfolios. Deal size/terms not confirmed in available sources.

• 2015-07-22 (recorded) — Reel/frame not retrieved

  • Conveyance: Assignment of Assignor's Interest
  • Assignor: eBay Inc.
  • Assignee: PayPal, Inc.
  • Correspondent: not retrieved
  • Context: corporate spin-off — PayPal Holdings was separated from eBay in July 2015; this recording (5 days after the spin-off became effective) is the standard IP transfer effecting that reorg, not a market transaction.

Finding: The Assignment Center chain is not empty — there are three recorded events (inventor→IBM, IBM→eBay, eBay→PayPal). If the task's "no records" branch applied, it does not: the patent has moved twice post-issuance, and both moves are between large operating companies. Reel/frame numbers and correspondents must be verified in the USPTO Assignment Center (https://assignmentcenter.uspto.gov/) before any litigation-grade reliance.

Timeline diagram

timeline
    title Ownership of US 7454496
    2003 : Filed by IBM from inventor Kundu
    2008 : Patent issued
    2012 : IBM assigns to eBay Inc
    2015 : eBay assigns to PayPal Inc

NPE / troll-pattern signals

1. Shell-entity transfer — not present. Every assignee (IBM, eBay, PayPal) is a Fortune-level operating company. No "IP / Patents / Licensing / Holdings / Ventures" LLC, no registered-agent address, no single-member Delaware/Texas LLC appears anywhere in the chain.
2. Known asserter in the chain — not present. None of IBM, eBay, or PayPal appears on the RPX / Unified Patents / Patent Progress NPE lists I can access. The Unified Patents portal entry for US-7454496-B2 lists "Paypal Inc" as assignee — that is ownership metadata, not an NPE designation.
3. Repeat correspondent across the chain — unclear / not assessable. I could not retrieve correspondent names from the Assignment Center in my searches, so I cannot test the "the lawyer stays the same, the LLCs change" tell. This is the one signal I could not evaluate, and it is the primary reason I cannot reach a higher-confidence verdict.
4. Cascading transfers — not present. Three transfers over ~12 years (2003 → 2012 → 2015), each separated by years; no chained LLCs, no sub-24-month daisy chain. The 2015 event is a corporate spin-off, not a shell cascade.
5. Pre-litigation transfer — not present. No infringement litigation naming 7454496 was found in any of my searches (including no CAFC 2026 docket entries), so there is no suit for the 2012/2015 transfers to have been timed around.
6. Bankruptcy fire-sale — not present. IBM, eBay, and PayPal have all remained solvent operating companies; no Chapter 7/11 context.
7. Privateering — not present. No evidence that IBM or eBay transferred the patent to an NPE to assert against competitors; the chain stayed inside operating companies throughout.
8. Defensive aggregator (anti-NPE) — not present. The chain terminates at PayPal, an operating company, not at RPX, AST, LOT Network, Unified Patents, or OIN.

Verdict

Insufficient data

The recorded chain (Kundu→IBM 2003-12-10; IBM→eBay 2012-12-26; eBay→PayPal 2015-07-22) contains zero NPE signals: no shell LLCs, no known asserter, no cascading transfers, no bankruptcy, no privateering, and no pre-litigation timing — and it terminates at PayPal, a major operating company, with the patent now past its 2026-05-28 adjusted expiration (today: 2026-08-21), making fresh assertion unlikely. However, I could not retrieve the USPTO reel/frame numbers or the correspondent-of-record names (the decisive NPE tell) from the Assignment Center, and I found no evidence either way of PayPal asserting the patent against competitors — so I cannot certify "operating-company assertion" or "defensive" status with confidence. Verify the reel/frame and correspondent fields at https://assignmentcenter.uspto.gov/ (search "7454496") to close the remaining gap.

I was not able to retrieve the complete USPTO "References Cited" list within the available search steps, so I'll give you (a) what the live searches confirmed, (b) what is in the patent's own record that is not prior art, and (c) a technically-grounded prior-art analysis with explicit confidence labels. I have not fabricated a citation list.

1. Search-retrieval limitation (stated plainly)

• The Google Patents full-text snapshot for US7454496B2 (application US10/732,736, filed 2003-12-10, issued 2008-11-18, inventor Ashish Kundu, original assignee IBM, now PayPal) does not reproduce the examiner's "References Cited" section in the page content returned by my searches.
• The USPTO full-text (PatFT/Patent Public Search) record was not directly retrievable via the web-search tool in the steps available.
• Therefore, the complete backward-citation list is not confirmed. Below, everything marked "confirmed" came from the live search results; everything else is labeled as analysis, not verified citation data.

2. Confirmed references from live searches

(a) US 2003/0167270 A1 — Resource Allocation Decision Function for Resource Management Architecture and Corresponding Programs Therefor

• Confirmed association: A Unified Patents record for US-20030167270-A1 lists US-7454496-B2 in its citation neighborhood (the two documents are cross-linked in patent records).
• Full citation (best available): Wookey et al., "Resource Allocation Decision Function for Resource Management Architecture and Corresponding Programs Therefor," US Patent Application Publication 2003/0167270 A1, assignee International Business Machines Corporation.
• Dates: Published 2003-09-04; the application (US 10/090,831) was filed 2002-03-04 — predates the '496 filing date (2003-12-10), so it is § 102(a)/(e) prior art if confirmed as cited or used.
• Brief description: Describes a resource-management architecture with a decision function that selects resource-allocation actions based on workload/QoS requirements and current resource availability — i.e., matching consumer/service requirements against monitored resource capabilities and making a selection decision.
• Potential § 102 mapping (if it is one of the cited references):
  • Claim 1 (method): the determine-requirements → compare-against-entity-capabilities → select-and-bind steps map onto the decision function selecting resources based on requirement/capability matching. The specific "failure actions" and "binding = connection + requirements transmission + configuration" limitations are less clearly disclosed, so anticipation of claim 1 as a whole is doubtful; it is stronger against the capability-comparison sub-limitations.
  • Claim 9 (data processing system with monitoring manager) and Claim 12 (distributed system): the architecture of a manager comparing stored requirements against stored capabilities is structurally similar.
  • Claim 13 (computer storage device): program instructions embodying the same selection logic.
  • Dependent claims 3–8, 10, 11, 14 (active-capability comparison, metric/period/granularity/format capabilities, repository publication, registration/de-registration components, resource optimizer): disclosed only partially; no confirmed anticipation.

(b) Same-family publications (NOT prior art — do not use under § 102)

• US 2005/0132041 A1 (published 2005-06-16) — the pre-grant publication of the '496 patent itself.
• US 2008/0275985 A1 (published 2008-11-06) — continuation US 12/173,854 of the same application, same specification.
• These are the same disclosure and cannot anticipate.

3. Forward citations found (later documents — not prior art, but useful context)

These later patents cite US7454496B2 as background; they are listed here only to show the technology space and should not be used for § 102:

4. Technical prior-art analysis (clearly labeled as analysis, not confirmed citations)

The claimed invention (matching a new consumer's monitoring requirements — resources, metrics, format, interval, failure actions — against monitoring-entity capabilities, binding via connection + requirement transmission + configuration, and QoS-based negotiation on no full match) sits at the intersection of four well-developed pre-2003 art areas. If the examiner's citation list follows the typical pattern for this IBM filing, the most likely cited references would come from these groups:

1. Distributed network/service monitoring with configurable agents (e.g., HP OpenView/IBM Tivoli-style monitoring, push/pull metric collection, bundling, per-consumer reporting periods) — strongest against the "monitoring requirements + capabilities" and "binding/configuring monitoring entity" limitations of claims 1, 9, 12, 13.
2. QoS/SLA negotiation and best-match selection — strongest against the "negotiation … based on QoS parameters" limitation of claims 1, 9, 12, 13 and the QoS-dependent claims.
3. Resource-allocation decision functions — US 2003/0167270 A1 (confirmed above) is the representative here.
4. Web-service discovery/registry and binding (UDDI-style repositories, XML requirement documents, binding tables) — relevant to claims 8, 10 (repository publication; registration/de-registration) and the binding-document description in the specification.

Important caveat: Anticipation under § 102 requires each limitation of a given claim to be present in a single reference. Based on the confirmed record alone, I cannot state with confidence that any single reference anticipates claim 1 in its entirety. The strongest candidate from the confirmed data is US 2003/0167270 A1 against the capability-matching/selection portions of claims 1, 9, 12 and 13.

5. Recommendation for verification

To complete the claim-by-claim § 102 table with confidence, the next step is to pull the USPTO full-text of US7454496B2 (PatFT / Patent Public Search, or the "Citations" tab on Google Patents, which was not fully rendered in my searches) and read the "References Cited" section (both US patent documents and NPL). I can do that analysis if you provide the citation list or grant me additional search steps.

The first search surfaced the patent's "References Cited" section from the issued PDF. Let me pull the full reference list and identify the exact titles/subject matter of the most relevant cited references so I can build a grounded § 103 analysis.

Obviousness Analysis — US Patent 7,454,496 B2 (35 U.S.C. § 103)

Scope note. The "Prior Art section" for this patent is the examiner's References Cited list, which I retrieved from the issued patent PDF (Google Patents image copy, US7454496.pdf) and confirmed via a USPTO/patentimages search. I verified the identity/subject matter of the two most important references (Zinky 6,691,148 and Koistinen 6,154,778) and the one non-patent item (de Souza) directly from primary sources. For several other cited references I could confirm only bibliographic data and USPC classification codes, not full titles — I flag those explicitly and do not guess at their content.

1. The prior-art record (examiner-cited references)

U.S. patents and applications cited on the face of the patent (from the PDF, (56) References Cited):

Important caveat. The fact that the examiner allowed the claims over this art is meaningful but not dispositive for a § 103 challenge; my analysis below identifies the strongest combinations a challenger would advance, and the counterarguments the patentee would raise.

2. Claim 1 broken into elements (the roadmap)

1. Determine the new consumer's monitoring requirements, comprising: (i) a list of data resources to be monitored; (ii) metrics of the monitoring data; (iii) a data format for the monitoring data; (iv) a time interval between periodic data sends; and (v) actions to be taken on failure of the data resource.
2. Compare those requirements against the monitoring capabilities of a plurality of monitoring entities (which monitor the network's data resources), where capabilities include: (i) current set of resources being monitored; (ii) set of resources each entity can monitor; (iii) metrics currently monitored; (iv) metrics each entity can monitor; (v) current monitoring period; (vi) data-format capabilities — to identify at least one matching entity.
3. On a match: select at least one identified entity and bind the consumer to it, where binding = (i) establishing a connection; (ii) sending the consumer's requirements description to the entity; (iii) configuring the entity to perform the requirements.
4. On no full match: initiate a negotiation between the consumer and the entities to select the best match based on QoS parameters.

Claims 9 (system), 12 (distributed system) and 13 (computer-readable medium) track claim 1 element-for-element, so the analysis below applies to each independent claim.

3. Primary obviousness combination: Zinky (6,691,148) + Koistinen (6,154,778)

3.1 What Zinky discloses (confirmed from the issued patent, filed 12/24/1998, issued 2/10/2004)

US 6,691,148, "Framework for providing quality of service requirements in a distributed object-oriented computer system" (BBN/Verizon's QuO framework), claim 1 recites:

creating a contract that specifies a level of quality of service required by the client object and a level of quality of service provided by the system; receiving a remote method invocation; updating the contract with a current level of QoS provided by the system; comparing the required level of QoS to the current level; and sending the invocation when the current level satisfies the required level.

Mapping to claim 1:

• Requirements vs. capabilities data model → Zinky's contract pairs a required QoS specification (consumer side) with a provided/current QoS specification (system side) — the functional equivalent of the patent's requirement-description/capability-description pairing. The QuO runtime monitors system conditions (latency, availability, bandwidth) to update the "provided" side — i.e., monitoring entities tracking current resource state and current metrics, which maps to elements 1(i)–(ii) and 2(i)–(v).
• Comparing requirements to current capabilities → Zinky's explicit "comparing the required level to the current level" step is the direct analogue of claim 1's "comparing the monitoring requirements … with monitoring capabilities … to identify at least one monitoring entity" (element 2).
• Failure actions → QuO's contract specifies regions of degraded QoS and triggers adaptive behavior when QoS falls outside the required region — a natural analogue of "actions taken during failure of the data resource" (element 1(v)), since QuO defines what the system does when the measured condition no longer meets the requirement.

What Zinky does not disclose (or discloses only weakly):

• The specific enumerated requirement fields (data format, send interval, failure actions as a consumer-supplied specification).
• Multiple candidate monitoring entities with a selection step.
• Dynamic negotiation fallback when no contract matches — QuO contracts are largely pre-established/deployed, not negotiated at runtime among a pool of providers.
• The explicit bind-and-configure sequence (connection + requirements transmission + configuration).

3.2 What Koistinen adds (confirmed from the issued patent, 11/28/2000)

US 6,154,778, "Utility-based multi-category quality-of-service negotiation in distributed systems," discloses client-agent/server-agent QoS negotiation across multiple QoS categories (performance, reliability, security, etc.), where agents exchange proposed QoS agreements and select the agreement with the highest expected utility — i.e., a best-match selection among alternatives based on QoS parameters.

Mapping to claim 1:

• Element 4 (the negotiation fallback) is Koistinen's entire subject matter: when no single provider fully satisfies a consumer's QoS requirements, agents negotiate to find the best available agreement.
• "Best match, relative to other matches, based on QoS parameters" is Koistinen's utility-maximizing selection criterion.
• Koistinen's agent-based client/server architecture maps onto the patent's "new consumer" ↔ "monitoring entities" negotiation, and the de Souza NPL (multi-agent negotiation in distributed supply-chain simulation) corroborates that agent-negotiation was a routine, well-understood mechanism in 2000.

3.3 Why a PHOSITA would combine them — the motivation

A person of ordinary skill (a distributed-systems/network-management engineer circa 2003) would have a direct, articulated reason to combine Zinky and Koistinen:

1. Complementary gaps. Zinky supplies the contract/requirement-vs-capability comparison and monitoring/adaptation machinery, but its contracts are static/pre-deployed. Koistinen supplies precisely the dynamic, multi-category, utility-based negotiation needed to establish such contracts at runtime when no pre-existing match exists. The patent's own claim 1 stitches these two functions together as a single two-branch flow: "match → bind; no match → negotiate." Combining Zinky's matching/contract model with Koistinen's negotiation engine yields that flow with no inventive leap.
2. Same technical field and same problem. Both references address QoS provisioning in distributed object systems; both use client/consumer and server/provider roles; both use QoS parameters as the selection currency. The overlap in field, problem, and terminology (QoS categories, required vs. provided levels, agent-mediated agreement) makes the combination an "obvious to try" / predictable-variation case under KSR.
3. Standard engineering motivation. The known desire to improve system flexibility — allowing new consumers to be accommodated without manual, static configuration — is exactly the problem Koistinen solves (dynamic negotiation) applied to Zinky's framework (which lacks it). A PHOSITA adding Koistinen's negotiation to Zinky's contract model is using a known technique to improve a similar system in the same way — the classic § 103 paradigm.
4. Corroborating background art. The examiner-cited de Souza NPL and the cluster of 2002–2003 published applications (Guha 2002/0194324, 709/223; Shastri 2002/0065922, 709/227; See 2002/0040441) show that monitoring, capability publication, and agent-based selection/negotiation were all active, crowded fields — supporting a finding that each element was conventional and the combination was a predictable aggregation.

3.4 The residual elements — who supplies them

• Data format capabilities / format requirements (elements 1(iii), 2(vi)): Zinky's contracts specify QoS categories with measurable parameters; format specification was routine in QoS/management protocols of the era. Even if not explicit in Zinky, the examiner-cited 2002/0065922 (Shastri, 709/227) and 2002/0194324 (Guha, 709/223) — network/resource-management applications with capability negotiation — are natural sources for format/interval parameters.
• Time interval between sends (element 1(iv)) and monitoring period (element 2(v)): periodic monitoring and reporting intervals are inherent to Zinky's "updating the contract with a current level of QoS" (which implies periodic system-condition evaluation) and were ubiquitous in network management (SNMP/RMON-style polling). This element would be a routine design choice.
• Bind-and-configure (element 3): establishing a connection, sending a requirements description, and configuring a service provider is the standard client-server service-binding sequence; Koistinen's negotiation culminates in the parties committing to an agreement, and Zinky's framework deploys/instantiates QoS mechanisms to meet a contract. A PHOSITA would implement binding as the routine consequence of a successful match/negotiation.

4. Secondary combinations

Zinky (6,691,148) + Zinky (6,620,126). The second Zinky patent (9/2003, 709/201) addresses the same QuO framework family; using both together strengthens the showing that requirement/capability comparison and QoS monitoring were known in the same framework.

Zinky + Koistinen + resource-discovery/capability-publication reference. If 6,625,643 (Colby, 9/2003, 709/217) is confirmed as an automatic resource/capability discovery reference (I could not verify its title from the search results — flag: unverified), it would supply the "set of data resources which each entity is capable of monitoring" / "metrics each entity is capable of monitoring" capability-inventory elements, with the motivation being the known benefit of discovering available monitoring services rather than hard-coding them.

Ahuja 6,041,307 (3/2000, 705/8). Cited for distributed resource/workflow management; likely discloses monitoring resource state and matching work to capable resources (title unverified). If confirmed, it corroborates the resource-list/metric/period requirement model.

I deliberately do not rely on the post-2003-issue-date references (6,765,873 through 7,307,954) in the primary combination, because I cannot verify their effective filing dates and they may not qualify as § 102(e) prior art; a challenger would need to establish filing dates ≤ 12/10/2003 to use them.

5. Counterarguments — why the claims may survive a § 103 challenge

1. No single reference teaches the complete requirement/capability schema. Claim 1 requires a specific enumerated set of requirement fields (resources, metrics, format, interval, failure actions) and a specific enumerated set of capability fields (current/possible resources, current/possible metrics, period, format). Zinky's contract is about QoS levels, not a monitoring-requirement document with failure-action policies; Koistinen negotiates QoS agreements but never frames the subject matter as monitoring entities with monitoring capabilities for data resources.
2. The two-branch flow may be more than the sum of its parts. The claimed "match → bind; no-match → negotiate" branching with QoS-based best-match selection is a specific control flow. A patentee would argue Zinky (static contracts) and Koistinen (standalone negotiation) are from different design traditions, and that the examiner — who had all of these references before him — allowed the claims, indicating the combination was not obvious as claimed.
3. "Configuring the selected monitoring entity to perform the new consumer's monitoring requirements" is an affirmative, post-selection reconfiguration step. QuO deploys mechanisms at build/deploy time; Koistinen's agents negotiate but do not reconfigure a third-party monitoring service to a new consumer's bespoke requirements. A patentee would argue this dynamic reconfiguration is the crux and is absent from both.
4. Secondary considerations. No evidence of commercial success or long-felt need is in the record before me; but the assignment history (IBM → eBay → PayPal) and continued "Active" status (adjusted expiration 2026-05-28) suggest ongoing commercial relevance that a challenger would need to rebut if the patentee proffers such evidence.

6. Bottom line

• Strongest combination: Zinky 6,691,148 (requirement/capability QoS contract + monitoring + comparison) in view of Koistinen 6,154,778 (multi-category, utility-based QoS negotiation), optionally further in view of a capability-discovery reference (e.g., Colby 6,625,643, subject to title verification) and the de Souza NPL as corroboration of routine agent-based negotiation.
• Realistic assessment: This combination plausibly reads on the "compare → match → bind → negotiate" architecture of claims 1, 9, 12 and 13, and the motivation to combine is strong (same field, complementary gaps, standard engineering practice). The patentee's best defenses are (a) the specific enumerated requirement/capability fields, (b) the post-selection reconfiguration step, and (c) the fact that the examiner already considered this exact reference set and allowed the claims — meaning a challenger would need to present the combination rationale (Zinky+Koistinen) more persuasively than the examiner's individual-reference analysis, and ideally bolster it with expert testimony on the 2003 PHOSITA's routine practice.

Confidence flags: (1) I could verify the full text/titles of only 6,691,148, 6,154,778, and the de Souza NPL from primary sources; titles/contents of 6,041,307, 6,055,307, 6,158,010, 6,625,643, 6,620,126, and the published applications are inferred from classification codes and should be confirmed against the USPTO full-text before being relied on in litigation. (2) I found no CAFC 2026 litigation involving this patent, so this analysis is prospective/analytical, not tied to any pending case. (3) For the post-2003-issue-date references, effective filing dates must be verified to establish § 102(e) status.