US 7710885

I'll run targeted searches for this specific patent number, including any litigation activity.

Let me check specifically for litigation or CAFC activity involving this patent, and verify the USPTO record.

US 7,710,885 B2 — "Routing monitoring"

Search scope and caveat

I searched for the literal string 7710885 / 7,710,885 across patent databases, PatentCenter-type records, PTAB filings, and CAFC/docket aggregators. No CAFC 2026 docket and no district-court case asserting US 7,710,885 was found. The only litigation-adjacent hits for this number are as cited prior art in PTAB proceedings involving third-party (Centripetal Networks) patents — e.g., the exhibits filed in IPR2021‑01152 (Palo Alto Networks v. Centripetal Networks) and IPR2018‑01512 (re U.S. 9,565,213), where "7710885 / linicki et al. / 2010‑05‑04" appears in the list of U.S. patents cited against those patents. That is a citation role, not an assertion role.

I do not have direct API access to USPTO PatentCenter or the CAFC CM/ECF docket, so the litigation-negative finding is based on indexed public sources, not a native docket query. I flag that as a limitation rather than a certainty. I also deliberately did not fold in nearby numbers (e.g., 7,721,084 Salminen et al., which appears adjacent to it in one docketalarm exhibit table).

Bibliographic data

Abstract (as granted)

"A routing monitor is disclosed comprising at least one communication tap, wherein each of the at least one communication taps is positioned in a line of communication between two routers and a protocol emulator for reassembling routing protocol messages captured by the at least one communication tap and opening a routing protocol connection with a network device using the reassembled routing protocol messages in response to a request for connection received from the network device."

Plain-language overview of the independent claims

Claim 1 — Routing monitor (apparatus). Three cooperating elements:

1. Communication tap(s) placed inline on a link between two routers (passive interception, e.g., a line tap or a router/switch mirroring port).
2. A protocol emulator that rebuilds the routing-protocol messages from the tapped traffic and then opens/establishes a routing-protocol session with a separate network monitoring device (e.g., a route server), feeding it the rebuilt messages — so the monitoring device sees what looks like a real peering router.
3. A transport protocol module that rebuilds the underlying transport stream (e.g., TCP), with the emulator opening the transport connection and establishing the routing session over it using those rebuilt transport messages — i.e., the emulator terminates/re-originates the transport layer rather than merely forwarding packets.

Claim 24 narrows claim 1 by requiring that the messages be captured without establishing any session between the routing monitor and either of the two routers — this is the "non-invasive" heart of the disclosure.

Claim 13 — Method. Steps: tap the link between two routers → replicate the packets on that link → send the replicas to a session emulator → reconstruct routing-protocol messages (with a protocol emulator) → establish a routing-protocol session with a network monitoring device. Claim 25 adds that the method establishes no session with either of the two routers.

Claim 19 — Computer program product. Code for talking to an eavesdropping device between two routers and re-assembling the routing-protocol messages it receives; plus code to open a transport connection and emulate a routing-protocol session with a network monitoring device using the re-assembled transport messages. Claim 26 adds that the product contains no code for establishing any session with either of the two routers.

Dependent-claim coverage (brief)

• Web delivery: convert reassembled messages / RIB to Web-accessible format and display via Web interface (claims 2, 8, 11, 14, 17, 20) — the "Looking Glass" function.
• Tap types: mirroring port or line-tap device (claim 3); tap interface module between tap and emulator performing attribute filtering (claim 4).
• Filter attributes: IP address, protocol ID, destination port (claims 5, 15, 22).
• Reconstruction targets: build a RIB (claim 6) or a routing table (claims 7, 18, 21).
• Emulator internals: a routing-protocol reconstruction module plus a protocol session emulator (claim 9).
• Co-location/integration: emulator and monitoring device in one device (claim 10); emulator + monitoring device + Web server in one device (claim 11).
• Protocols named: BGP, RIP, OSPF, ISIS (claim 12); transport-session reconstruction and emulation (claims 16, 23).

Analyst notes and uncertainties

• Abstract vs. claim language mismatch. The granted abstract recites "opening a routing protocol connection … in response to a request for connection received from the network device." Independent claims 1, 13 and 19 recite establishing/emulating a session but do not contain the "in response to a request for connection received from the network device" limitation. This reads like a prosecution artifact (abstract carried over from an earlier claim set / examiner-required abstract) and is a point worth checking in the file wrapper if claim scope is being analyzed.
• Term/expiration. Filing 2003‑08‑29 implies a nominal 20-year term to 2023‑08‑29, but the record lists an adjusted expiration of 2029‑01‑19 (roughly a 5.4-year adjustment). That is unusually large for PTA. I could not independently verify the PTA/terminal-disclaimer basis for that date; treat it as record-reported, not confirmed.
• Assignee chain. The 2026-date reassignment entries in the underlying record (Wells Fargo security interests dated 2025-10-21 and 2025-11-14) are lien/security recordings, not ownership transfers; ownership remains with Viavi Solutions Inc.
• "Cited By" volume. The large Centripetal Networks citation family reflects Centripetal's patents citing '885 as prior art in their own prosecution, not a Viavi–Centripetal dispute over '885.

Sources: Google Patents full text and legal-status record — https://patents.google.com/patent/US7710885/en; uspto.report mirror — https://uspto.report/patent/grant/7710885; PTAB prior-art citation via docketalarm exhibit (IPR2021‑01152 / IPR2018‑01512 file histories).

If you want, I can now pivot to a specific angle — e.g., an element-by-element mapping of claim 1 against a named competitor product, or a comparison of '885's non-session tap-and-emulate approach against the cited Labovitz (US 2003/0037136) and Fujinaga et al. references.

I'll run targeted searches for litigation involving this specific patent number, including the Unified Patents litigation portal.

Let me check the Unified Patents portal and other litigation-specific sources directly.

Let me try a few more litigation-focused searches to be thorough.

Litigation search for U.S. Patent No. 7,710,885

Bottom line

I found no known litigation — district court, ITC, or Federal Circuit — in which U.S. Patent No. 7,710,885 ("Routing monitoring," Ilnicki et al., currently recorded to Viavi Solutions Inc.) was asserted as a patent-in-suit, or in which it was the subject of a validity/infringement judgment.

Because you asked for case-level detail, the answer is not a table of cases — there is nothing to populate it with. What I can give you is (a) the searches I ran, (b) the two kinds of false positives that surface for this number, and (c) the confidence limits on the negative finding.

What I searched

• General web/patent-litigation queries on the literal strings 7710885 and 7,710,885 paired with "patent litigation," "lawsuit," "asserted," "infringement," "complaint."
• Assignee-side queries pairing the number with Viavi Solutions, Agilent Technologies, and JDS Uniphase — the three recorded owners across the chain (Agilent → JDS Uniphase Corp., effective 2010-04-30 → change of name to Viavi, effective 2015-07-31).
• Queries targeting the Unified Patents litigation portal (portal.unifiedpatents.com/litigation/caselist), CourtListener/RECAP, PTAB docket aggregators, and the docketalarm PTAB document set.
• Title/reference queries ("routing monitoring" + litigation) to catch cases pleaded by patent title rather than number.

None returned a case in which '885 is a patent-in-suit.

The two false positives you must not mistake for litigation

These are the only "hits" that reliably appear for this number, and neither is litigation over '885:

1. NL 7710885 A — an unrelated Dutch laid-open application (H.H. Robertson Company, energy-absorbing bumpers, filed 4 October 1977, laid open 6 April 1978). This is a different patent numbering authority entirely. If you search the bare number "7710885" without the US prefix, this document is the dominant result. Do not treat it as U.S. 7,710,885. It is the classic auto-correct trap your instruction warns against.

2. PTAB prior-art citation (not an assertion). U.S. 7,710,885 appears in the file history/exhibit set for IPR2018-01512 (Inter Partes Review of U.S. Patent No. 9,565,213), filed by the petitioner on 2018-08-21 — Exhibit 1002 is the file history of the '213 patent, and '885 is listed among the U.S. patent references cited on the face of that patent's file history, adjacent to U.S. 7,721,084. That is '885 in a cited-references role, cited against a Centripetal Networks patent. Similarly, the large "Cited By" cluster on '885's Google Patents page is dominated by Centripetal Networks patents whose own prosecution cited '885 — again, Centripetal citing '885 as prior art, not Viavi and Centripetal litigating over '885. I explicitly flag that these are citation-role hits and should not be reported as litigation involving '885.

Confidence and limitations (state these if you rely on the negative)

• I do not have native, authenticated API access to PACER or the Federal Circuit CM/ECF docket, nor a paid Westlaw/Lexis/Docket Navigator seat. The negative finding is therefore based on indexed public sources (Google Patents legal-status, Unified Patents portal, RPX, CourtListener/RECAP, PTAB document repositories) rather than an exhaustive docket-level query. I state that as a limitation, not a certainty.
• A patent can be asserted in litigation that is sealed, settled pre-appearance, or pleaded in a complaint that is not OCR-indexed; such a case would evade the searches above.
• The '885 record shows the patent granted 2010-05-04, an original assignee of Agilent Technologies, Inc., and no recorded patent-specific transfer to a litigation vehicle/PAE. Ownership stayed inside the Agilent → JDS Uniphase → Viavi corporate line. The only post-2010 reassignment entries are security interests (Wells Fargo, 2020-05-21; 2025-10-21 and 2025-11-14) and their terminations (2022-01-05) — liens, not ownership changes. That ownership profile is consistent with a portfolio-rights asset rather than an asserted patent, which corroborates (but does not prove) the negative litigation finding.
• The record lists the patent as "Active" with an adjusted expiration of 2029-01-19. If '885 is being evaluated for freedom-to-operate or validity risk, note the earlier-section flag that this PTA date is unusually large (≈5.4 years) and record-reported, not independently verified.

If you need a definitive answer

To convert this from a high-confidence negative to a verified one, run the number through a PACER-authenticated docket search (all district courts + Federal Circuit + ITC EDIS) and Docket Navigator or Lexis Litigation Profile, filtered on "patent-in-suit = 7,710,885." I can draft the exact query strings/parameters for those systems, or pivot to a claim-chart against a specific accused product, if that is more useful.

I'll verify the structured-block finding with targeted searches before writing the report.

Let me run a few more targeted checks before concluding.

Proceedings overview

Total AIA trial proceedings on US 7,710,885: 0 (zero). The structured "PTAB proceedings on file" block — sourced from the USPTO Open Data Portal, the canonical list — returns no IPR, PGR, or CBM for this patent, and targeted web searches surfaced none either. There is therefore no "claims invalidated / claims sustained / settled / institution denied" breakdown to report: nothing is canceled, nothing is sustained, and nothing is settled, because no trial was ever instituted and no petition appears to have ever been filed. The bottom-line defensive posture for a defendant is the inverse of a hardened patent: this is an untested, unreviewed patent. All 26 claims — including independent claims 1, 13 and 19 and the "no session with either router" narrowing claims 24–26 — stand exactly as they issued on 2010-05-04, with no PTAB record of validity or invalidity and no § 315(e)(2) estoppel running against anyone. You would be filing on virgin ground.

Important caveat on the negative finding. I do not have native API access to PTAB E2E / PTAB Trial Statistics; the negative result rests on (a) the ODP structured block and (b) indexed public search, not a direct docket query. Verify before relying on it by running the patent number against PTAB E2E at https://e2e.ptab.uspto.gov/ and the PTAB decision archive at https://www.uspto.gov/patents/ptab/decisions.

---

No proceedings to itemize

There are no entries to render in the per-proceeding template. Rather than fabricate proceeding numbers, here is what the searches did return and why each hit is not an AIA trial against '885:

I found no ex parte reexamination, no inter partes reexamination, no PTAB FWD, and no Federal Circuit appeal involving '885.

---

Strategic summary

Claim status: all 26 claims UNTESTED. Claims 1, 13 and 19 (independent) and 2–12, 14–18, 20–26 (dependent) have never been construed by the Board in an AIA trial. The claim set is intact as granted. The narrowing claims — 24 (apparatus captured "without establishing any session between the routing monitor and either of the two routers"), 25 (method establishes no session with either router) and 26 (CPP contains no such code) — were added late (they are the sorts of claims added during prosecution to distinguish the cited Labovitz US 2003/0037136 and Fujinaga et al. art), and those limitations are exactly the kind of thing that makes an IPR both worthwhile and non-trivial: the tap-and-emulate architecture of claim 1 is the vulnerability, while the "no session with the routers" negative limitations of 24–26 are the moat.

Estoppel landscape: clean slate. Because no IPR was ever instituted, § 315(e)(2) estoppel attaches to no one. Any defendant — including a defendant already sued on '885, and including a competitor who previously filed and lost or abandoned a petition (none appears to exist) — is free to file a fresh IPR on any § 102/§ 103 ground without an estoppel bar. Two structural constraints do apply: (1) PGR is unavailable — '885 was filed 2003-08-29, long before the 2013-03-16 AIA cutoff, so PGR (and pre-AIA-style CBM, which sunset for new petitions on 2020-09-16) are off the table; (2) IPR is the only AIA vehicle, and IPR is limited to § 102/§ 103 grounds on patents and printed publications — no § 112 or § 101 theories, notwithstanding the abstract/claim mismatch flagged in the earlier section (that mismatch is a litigation argument, not an IPR ground).

Pattern signals: none — and that itself is the signal. No petitioner has challenged this patent, no patent owner has had to defend it at the Board, and there is no defensive aggregator (Unified Patents, RPX, etc.) in the chain. That is notable: '885 is a 2003-filed, now-23-year-old networking patent held by Viavi Solutions, a large operating company — not an NPE assertion vehicle. The absence of IPRs is consistent with the patent never having been asserted offensively in a way that triggered a validity challenge. For a defendant, this means there is no roadmap: no Board construction of any term, no FWD reasoning to borrow, and no petitioner-side expert work product in the public record.

---

Recommended next steps

1. Verify the zero count natively before you build a defense on it. Run 7,710,885 and 7710885 through:

   • PTAB E2E: https://e2e.ptab.uspto.gov/
   • PTAB decisions search: https://www.uspto.gov/patents/ptab/decisions
   • PTAB Trial Statistics (for the general rate context): https://www.uspto.gov/patents/ptab/statistics
   • CourtListener dockets (to confirm no CAFC appeal exists): https://www.courtlistener.com/?q=7710885

2. If you are being asserted against, IPR is wide open. Recommend a § 102/§ 103 petition now, grounded in art the examiner already had and art the examiner didn't reach. The two most promising entry points, both named in '885's own IDS:

   • Labovitz, US 2003/0037136 (Method and system for monitoring control signal traffic over a computer network) — cited against '885, and squarely about passive monitoring of routing control traffic.
   • Fujinaga, Hotta, Asami, "A Tool for Monitoring Routing Information in the Internet," Proc. 1999 Int'l Workshops on Parallel Processing, pp. 274–279 — a non-patent printed publication cited in the IDS; a strong primary reference for the tap-and-reconstruct concept.
   • Kamizuru & Amagai, "Distributed Inter-AS Route Monitor — Distributed Internet Route Eye (DIRE)," ICPADS 1998, pp. 533–540 (XP010318667) — also cited in the IDS and directly on point for distributed passive BGP monitoring. (These are the examiner-cited references; § 325(d) discretion is a real risk when using them, so pair a primary reference with art the examiner never saw, or frame the combination to avoid § 325(d) being invoked.)
   • Note the timestamping / conflicting-update-resolution disclosure at the end of the '885 specification — claims 6/8/17 (RIB construction) and the timestamp discussion are a distinct vulnerability if you can find art on timestamped BGP update logging (the spec itself disparages Zebra's inability to log without tearing down the session).

3. No trial-stage milestones to track. There is no institution deadline, no scheduled oral hearing, and no statutory 1-year FWD clock running on this patent, because no proceeding exists. The only clock that matters is your own petition-filing decision and any § 315(b) one-year bar triggered by service of a district-court complaint on you.

4. Litigation-side fallbacks worth preserving (since IPR can't reach them): the abstract-vs-claim mismatch (the granted abstract recites "in response to a request for connection received from the network device," which appears nowhere in independent claims 1, 13 or 19) and the § 112 support question for the "protocol emulator" terms — both should be preserved in invalidity contentions even if your IPR focuses on § 102/§ 103.

Bottom line: there is no PTAB history on US 7,710,885, so there is no FWD to link and no canceled claim to quote. The patent is fully live and fully untested at the Board. If a demand letter cites claims 1, 13 or 19, those claims have never been adjudicated — and they are cancellable by any competent petitioner, with no estoppel standing in the way. This is a patent you challenge on offense, not one you defend around.

I'll research the assignment record for this patent.

Assignment Chain Analysis — US 7,710,885 B2 ("Routing monitoring")

Source note. The reel/frame data below is taken from the patent-specific legal-events record (Google Patents mirror of the USPTO assignment data) at https://patents.google.com/patent/US7710885/en, cross-checked against the previously generated bibliographic section. I could not execute a native Patent Assignment Search query (assignmentcenter.uspto.gov / assignment.uspto.gov) within this session. The correspondent-of-record field was not exposed in any index I could reach for this patent, so Section 3 of the NPE framework (repeat correspondent) is answered as unclear rather than answered by inference — see the explicit gap note before the verdict.

---

Inventors

Employer is determinable with high confidence: all three are the assignors of record on the original assignment, reel 014204/0277, executed 2003-09-12 to 2003-09-15 and recorded 2003-12-17, naming "AGILENT TECHNOLOGIES, INC., COLORADO" as assignee.

Notable patterns:

• No adverse inventor pattern. The classic fire-sale precursor — all inventors departing the original assignee within ~12 months of filing — cannot be observed here because no post-2003 inventor-side assignments appear in the record at all. There is no evidence of departure, and none of the three inventors re-appears as an assignor anywhere in the '885 chain.
• Signing dates trail the filing date by ~2 weeks (filed 2003-08-29; executed 2003-09-12 to 2003-09-15). This is an ordinary post-filing confirmatory employment assignment, not a red flag.
• Team continuity. Alexander L. Tudor is also the named inventor on US 2004/0196841 ("Assisted port monitoring with distributed filtering," App. Ser. No. 10/407,719, filed 2003-04-04), which the '885 specification expressly incorporates by reference and which carries the same original assignee. This is a coherent in-house Agilent network-test R&D cluster, not a one-off filing farmed to an outside entity.

---

Original assignee

Agilent Technologies, Inc. (Colorado corporation; principal offices Palo Alto/Santa Clara, CA at the relevant time).

• Primary line of business: test and measurement — electronic measurement, chemical analysis, and life sciences — following its 1999 spin-off from Hewlett-Packard. The business unit relevant to this patent was Agilent's communications/network test operation, which sold network and protocol test and monitoring equipment into carrier and enterprise networks.
• Did it ship a product embodying the claims? Unverified. The claimed subject matter (a line tap plus a transport-reconstruction and BGP-session-emulation proxy feeding a route server / Looking Glass) is squarely consistent with Agilent's communications-test product line, and the specification's discussion of Zebra, Looking Glass, and route-server deployments reads as product-engineering background rather than academic text. However, I could not identify a named Agilent product SKU documented as practicing claim 1, and I am not going to assert one. Treat "shipped an embodying product" as probable-but-unconfirmed.
• Current status: operating and publicly traded (NYSE: A). It no longer owns '885 — it divested the relevant business line in 2010 (see timeline).

Current owner: Viavi Solutions Inc., also operating and publicly traded (NASDAQ: VIAV). Its Network and Service Enablement segment sells network test, assurance, and monitoring platforms — the same commercial space the patent occupies. Again, no product-level mapping to claim 1 was verified.

---

Assignment timeline

Every recorded event on the patent. Seven recordings total; only the first three are ownership events — the last four are liens and a lien release.

• 2003-09-12 → 2003-09-15 (executed) / recorded 2003-12-17 — Reel 014204/0277

  • Conveyance: Assignment (Assignment of Assignors' Interest)
  • Assignor: Ilnicki, Slawomir K.; Tatman, Lance A.; Tudor, Alexander L.
  • Assignee: Agilent Technologies, Inc., Colorado
  • Correspondent: not retrievable — the correspondent block was not exposed in the index I could reach. No flag possible.
  • Context: Original inventor-to-employer assignment; standard confirmatory filing after the 2003-08-29 priority filing.

• 2010-04-30 (effective) / recorded 2010-05-25 — Reel 024433/0138

  • Conveyance: Assignment
  • Assignor: Agilent Technologies, Inc.
  • Assignee: JDS Uniphase Corporation, California
  • Correspondent: not retrievable — same gap.
  • Context: Corporate divestiture / business-line acquisition, not a fire-sale. The April 30, 2010 effective date aligns with the closing of the sale of Agilent's network test business to JDSU. Note the record itself shows only the assignment instrument; I did not retrieve the underlying asset purchase agreement or a specific SEC exhibit confirming that '885 was transferred as part of a going-concern business sale rather than a bare patent sale. The grouping of the whole portfolio under one reel/frame is consistent with a portfolio-wide transfer accompanying a business disposition.

• 2015-07-31 (effective) / recorded 2015-11-06 — Reel 037057/0627

  • Conveyance: Change of Name (not an assignment)
  • Assignor: JDS Uniphase Corporation
  • Assignee: Viavi Solutions Inc.
  • Correspondent: not retrievable.
  • Context: Internal reorg / change of name only. No change in beneficial ownership. JDSU was renamed Viavi Solutions and its communications/optical components business was spun out to Lumentum in the same July–August 2015 window; the '885 patent stayed with the renamed entity.

• 2020-05-19 (effective) / recorded 2020-05-21 — Reel 052729/0321

  • Conveyance: Security Interest (Security Agreement)
  • Assignor: Viavi Solutions Inc.; 3Z Telecom, Inc.; Acterna LLC; Acterna WG International Holdings LLC; JDSU Acterna Holdings LLC; Optical Coating Laboratory, LLC; RPC Photonics, Inc.; TTC International Holdings, LLC; Viavi Solutions LLC
  • Assignee: Wells Fargo Bank, National Association, as Administrative Agent, Colorado
  • Correspondent: not retrievable.
  • Context: Securitization. Blanket grant of a security interest by the Viavi consolidated group to its lending agent. Not an ownership transfer; Viavi remained the owner.

• 2021-12-29 (effective) / recorded 2022-01-05 — Reel 058666/0639

  • Conveyance: Termination / Release of Security Interest (expressly "terminations of security interest at reel 052729, frame 0321")
  • Assignor: Wells Fargo Bank, N.A., as Administrative Agent
  • Assignee (releasor direction): Viavi Solutions Inc., California; RPC Photonics, Inc., New York
  • Correspondent: not retrievable.
  • Context: Lien release on payoff or refinancing. Confirms the 2020 recording was collateral, not a conveyance.

• 2025-10-16 (effective) / recorded 2025-10-21 — Reel 073189/0873

  • Conveyance: Security Agreement
  • Assignor: Inertial Labs, Inc.; Viavi Solutions Inc.; Viavi Solutions Licensing LLC
  • Assignee: Wells Fargo Bank, National Association, as Administrative Agent, California
  • Correspondent: not retrievable.
  • Context: Securitization under a new/renewed Wells Fargo credit facility.

• 2025-11-13 (effective) / recorded 2025-11-14 — Reel 073571/0137

  • Conveyance: Security Interest
  • Assignor: Viavi Solutions Inc.; Viavi Solutions Licensing LLC; Inertial Labs, Inc.
  • Assignee: Wells Fargo Bank, National Association, as Agent, California
  • Correspondent: not retrievable.
  • Context: Securitization — companion recording to the October 2025 facility, filed one month later against the same co-obligor group. The near-duplicate pair in Oct/Nov 2025 is a recording artifact of a financing, not cascading ownership transfers.

Cross-reference flag. The previously generated bibliographic section characterized the 2025 Well Fargo entries as lien/security recordings and stated that ownership remains with Viavi Solutions Inc. That is confirmed: post-2015 there is not a single conveyance-type recording (Assignment, Merger, or otherwise) on this patent. The only entity whose name resembles an NPE shell anywhere in the record is Viavi Solutions Licensing LLC, and it appears solely as a co-grantor of security interests in 2025 — there is no recorded conveyance of '885 to it, and its role is that of a group co-obligor, not an owner.

On the substantive value of the security recordings: these blanket security instruments are recorded against large Viavi portfolio schedules. Google Patents attributes them to this patent, which implies '885 appears on the schedules, but I did not retrieve the property schedules themselves to confirm the patent is individually listed. Treat the attachment of these liens to '885 as record-reported, not document-verified.

---

Timeline diagram

timeline
    title Ownership of US 7710885
    2003 : Inventors assign to Agilent Technologies
    2010 : Agilent transfers business to JDS Uniphase
    2015 : JDSU renamed Viavi Solutions
    2020 : Security interest to Wells Fargo
    2022 : Wells Fargo security interest released
    2025 : New Wells Fargo security agreement
         : Companion Wells Fargo security interest

---

NPE / troll-pattern signals

1. Shell-entity transfer — not present. No conveyance to any licensing-only LLC is recorded. The ownership chain is Agilent → JDSU → Viavi, all operating corporations. Reel 037057/0627 is a Change of Name, which the framework's own definition excludes from the shell-transfer pattern (no change in beneficial ownership). Viavi Solutions Licensing LLC appears only as a co-obligor on the 2025 security recordings (073189/0873, 073571/0137) and never as assignee of '885.

2. Known asserter in the chain — not present. No assignee at any link matches Acacia, Marathon, Intellectual Ventures, IPNav, Wi-LAN, Mosaid/Conversant, Vringo, Pendrell, Innovatio, MPHJ, Lumen View, Round Rock, Document Generation Corp, or any Spangenberg entity. Current assignee Viavi Solutions Inc. is an operating manufacturer with a large organic portfolio (roughly 710 U.S. grants in the 2016–2025 window per PatentsView-derived tallies) — the profile of a practicing company, not an assertion vehicle.

3. Repeat correspondent across the chain — unclear / not assessable. This is a genuine data gap, not a negative finding. The correspondent-of-record was not exposed for any of the seven recordings in the sources available to me this session, so I have no attorney name or firm to test for recurrence. I will not manufacture one. If the correspondent field is material to the conclusion, it must be pulled directly from assignmentcenter.uspto.gov using the reel/frame pairs listed above — that is a five-minute manual lookup and the only route to a defensible answer on this signal.

4. Cascading transfers — not present. The three ownership events are spaced 2003 → 2010 → 2015, i.e., 6.7 and 5.3 years apart. There is no chain of LLC-to-LLC transfers inside 24 months, and no shared registered-agent address or common principals are visible.

5. Pre-litigation transfer — not present. No assignment falls within 6 months before any infringement suit, because no infringement suit naming '885 was located (consistent with the litigation-negative finding in the previous section). The last ownership change (2015-07-31, effective) predates the present day by over a decade.

6. Bankruptcy fire-sale — not present. No Chapter 7/11 of Agilent, JDSU, or Viavi appears in the record or the corporate history. The 2010 transfer was a going-concern business-line disposition, and the 2015 step was a rename plus a spin-off of different assets (Lumentum), not a distress sale of this patent. (Caveat: I did not retrieve the 2010 asset purchase agreement; this call rests on the deal's April 30, 2010 closing date and general corporate history, not on the instrument.)

7. Privateering — not present. The operating parent retains ownership of '885 through the entire chain. There is no transfer to a third-party asserter, and no SEC filing or third-party report surfaced indicating Viavi funded or directed assertion of '885 on its behalf.

8. Defensive aggregator (anti-NPE) — not present. The chain does not terminate at RPX, AST, LOT Network, Unified Patents, or OIN. It terminates at Viavi Solutions Inc.

---

Verdict

Operating-company assertion — with an explicit caveat that the assertion half of the label is unevidenced.

Justification. Every substantive ownership link is between large operating corporations: reel 014204/0277 (inventors → Agilent), reel 024433/0138 (Agilent → JDS Uniphase, effective 2010-04-30), and reel 037057/0627 (JDS Uniphase → Viavi, a Change of Name effective 2015-07-31). The four later recordings — reels 052729/0321, 058666/0639, 073189/0873, and 073571/0137 — are collateral liens and a lien release that leave Viavi as owner throughout. Zero of the eight NPE signals are present, and the patent has never left operating-company hands.

Fit limitation, stated plainly. The taxonomy supplied for this task has no bucket for "operating company holds the patent and has never asserted it." I selected Operating-company assertion over Defensive / non-asserting because the latter is defined by the chain terminating at a defensive aggregator, which is factually false here. But readers should read the verdict as "operating-company-held, no NPE signal, no assertion observed" — not as a finding that Viavi has sued anyone over this patent. No suit was located, and the assertion element is unproven.

Residual gap. If confirmation is required, the two things to pull from the native system are (i) the correspondent of record for each of the seven reel/frame entries, and (ii) the property schedules attached to reels 052729/0321, 073189/0873, and 073571/0137, to confirm '885 is individually listed as collateral.

Verification link: https://assignmentcenter.uspto.gov/ — search by patent number 7710885, or by the reel/frame pairs above.

I'll research the cited prior-art references to give you grounded descriptions and § 102 analysis. Let me run targeted searches on the key references.

Let me get details on the remaining cited references.

I've gathered enough to produce the analysis. Note: my searches were cut off after the step limit, so for three references (US 6,157,644; WO 02/046947; US 2006/0083511) I rely primarily on the titles/assignee/date data in the authoritative patent record rather than a full-text read — I flag that where relevant.

Prior art analysis — US 7,710,885 B2 ("Routing monitoring")

Scope note on the search

I confirmed the bibliographic record against the USPTO-derived full text (Google Patents mirror at https://patents.google.com/patent/US7710885/en), consistent with the previously generated sections: app. 10/652,286; filed/priority 2003-08-29; granted 2010-05-04; inventors Ilnicki, Tatman, Tudor; original assignee Agilent Technologies. I did not return or fold in near numbers (e.g., NL 7710885 A, US 7,721,084). Everything below is drawn from '885's own "Patent Citations (11)" and "Non-Patent Citations (3)" tables, which are the examiner-cited references of record.

Critical framing for the § 102 question: the task asks which claims each reference "potentially anticipates" under 35 U.S.C. § 102. Anticipation requires a single reference disclosing every element of a claim as arranged. As shown below, none of the eleven patent references and neither substantive non-patent reference appears to anticipate independent claims 1, 13, or 19. The distinguishing element that each reference lacks is the combination of: (i) passive capture between two routers, (ii) reassembly of the routing-protocol messages, and (iii) emulating a routing-protocol session with a separate network monitoring device using those reassembled messages — with the negative limitations of claims 24/25/26 (no session with either monitored router). Everything cited is best characterized as a § 103 obviousness reference (or mere background), not a § 102 anticipation reference. I state that explicitly rather than forcing an "anticipation" label onto references that don't support one.

---

A. Patent citations (11)

1. US 6,157,644 A — "Method and apparatus for accelerating OSI layer 3 routers"

• Assignee: Northern Telecom Limited
• Filed / granted: 1997-10-07 / 2000-12-05
• Description: Routing performance/acceleration for OSI Layer-3 routers (route-lookup/caching acceleration). General router-operation background.
• § 102 relevance: None. Does not disclose passive tapping of a link between two routers, routing-protocol message reassembly, or session emulation. Background art only. No claim anticipated.

2. US 6,421,319 B1 — "Network traffic monitoring system"

• Inventor / assignee: Junko Iwasaki / NEC Corporation
• JP priority / US filed / granted: 1997-10-31 / 1998-10-29 / 2002-07-16
• Description: Monitors Internet traffic on a physical line between a terminal adaptor and a digital service unit; collects/totalizes traffic statistics by subnet mask. It is a line-monitoring system, not a routing-protocol monitor.
• § 102 relevance: Its "traffic monitoring means for monitoring Internet traffic on a physical line" is superficially analogous to the tap element of claim 1 / step of claim 13, but it monitors packet traffic for statistics, not routing-protocol messages, and there is no reassembly or session emulation with a monitoring device. Does not anticipate claims 1/13/19. At most § 103 evidence that line-tapping for monitoring was known.

3. WO 02/046947 A1 — "System for proactive management of network routing"

• Assignee: Rensselaer Polytechnic Institute
• Filed / published: 2000-12-04 / 2002-06-13
• Description: Proactive network-routing management (routing policy/table management). Per the authoritative record only — I did not retrieve full text.
• § 102 relevance: No disclosure of tap + routing-protocol reassembly + emulated session to a monitoring device. Background/§ 103 only. No claim anticipated.

4. US 2002/0131369 A1 — "Traffic monitoring method and traffic monitoring system"

• Assignee: KDDI Corporation
• Filed / published: 2001-03-19 / 2002-09-19
• Description: General traffic monitoring method/system.
• § 102 relevance: No routing-protocol message reassembly or emulation. Background. No claim anticipated.

5. US 2002/0141378 A1 — "Methods, apparatuses, and systems facilitating deployment, support and configuration of network routing policies"

• Inventor: Bays, Robert James
• Filed / published: 2001-03-28 / 2002-10-03
• Description: Deployment/configuration of routing policies.
• § 102 relevance: Directed at policy configuration, not passive monitoring. No claim anticipated.

6. US 2002/0163934 A1 — "Apparatus and method for network analysis"

• Inventor: Moore, Todd A.
• Filed / published: 2001-04-30 / 2002-11-07
• Description: Network-analysis apparatus/method — the "analysis engine" genre (cf. the NIDS discussion in '885's background).
• § 102 relevance: Relevant generically to analyzing captured network data, but discloses neither the two-router tap nor the emulated routing-protocol session to a monitoring device. § 103 background. No claim anticipated.

7. US 2003/0037136 A1 — "Method and system for monitoring control signal traffic over a computer network" — closest reference

• Inventors / applicant: Craig H. Labovitz; Scott Iekel-Johnson / Arbor Networks, Inc.
• Filed / published: 2002-06-27 (provisional 2001-06-27) / 2003-02-20
• Description (retrieved): A router monitor receives a plurality of control signals (i.e., BGP routing control traffic) and related information from the network, processes them to detect control-signal anomalies (e.g., DoS/route-hijack attacks), stores the control signals in a database, and generates alerts; a controller tracks anomaly attributes to a source and blocks them. Claim 1 of that publication: "receiving … at least one control signal … and storing the at least one control signal in a database."
• § 102 relevance: This is the most substantive reference and maps onto several themes of '885 — monitoring BGP control-signal traffic and detecting routing-protocol attacks (the "by-product" of '885's Fig. 4 discussion). It is the strongest candidate for a § 103 primary reference, and portions could be argued against dependent-claim-type subject matter (monitoring control-signal traffic and analyzing it). However, as published it does not disclose the claim-1 combination: passive capture between two routers, reassembly of routing-protocol messages, and emulation of a routing-protocol session with a separate network monitoring device using those reassembled messages. It therefore does not anticipate claims 1, 13, or 19; treat it as the primary § 103 reference.

8. EP 1 289 191 A1 — "Monitoring communications networks"

• Assignee: Agilent Technologies, Inc. (same corporate family as '885's original assignee)
• Filed / published: 2001-09-03 / 2003-03-05
• Description (retrieved): Uses a router's multicast function to generate a copy of data travelling in an LSP and forward it to a probe, expressly "without the need for physical taps," with selective monitoring of chosen LSPs and filtering of unwanted data. It is a copy/replicate-in-the-router approach.
• § 102 relevance: Relevant to the notion of obtaining a copy of traffic for monitoring and to reducing monitoring overhead, but it is deliberately non-tap and is not a routing-protocol (BGP) reassembly/emulation system. No claim anticipated. Also note it is a commonly-owned Agilent document (see § 103(c) note below).

9. US 2005/0064820 A1 — "Network analyzing method and apparatus for optimal performance of network…"

• Inventor: Park, Sang Jin
• Priority / published: 2001-12-07 / 2005-03-24
• Description: Network analysis for performance optimization.
• § 102 relevance: General network analysis; no two-router tap/reassembly/emulation. Background. No claim anticipated.

10. US 2006/0083511 A1 — "Network tap module"

• Assignee: Xyratex Technology Limited
• Priority / published: 2002-12-17 / 2006-04-20
• Description: A network tap module — i.e., hardware for physically tapping a network link. Per the authoritative record only; I did not retrieve full text.
• § 102 relevance: Directly relevant to the tap element (claim 1; claim 3 "line tap device"; the tapping step of claim 13). But a tap module, standing alone, discloses nothing about routing-protocol message reassembly or session emulation. It cannot anticipate any independent claim; it is § 103 background for the tap structure and could support a § 103 combination for claims 1/3/13's tap element.

11. US 2004/0196841 A1 — "Assisted port monitoring with distributed filtering"

• Inventor: Tudor, Alexander L. — a named co-inventor of '885; assignee Agilent Technologies
• Filed / published: 2003-04-04 / 2004-10-07
• Description: Aggregating multiple physical taps serving each interface on a router's line card, with distributed filtering. This is the commonly-assigned co-pending application Ser. No. 10/407,719 that '885's specification expressly incorporates by reference ("ASSISTED PORT MONITORING WITH DISTRIBUTED FILTERING").
• § 102 relevance: Relevant to the tap-interface/filtering subject matter (claim 4, and the tap element of claims 1/13). It is not a routing-protocol reassembly/emulation reference, so it cannot anticipate claims 1/13/19.
• Important caveat: Because it is commonly owned by Agilent and shares an inventor (Tudor) with '885, its availability as prior art is limited. Under pre-AIA 35 U.S.C. § 103(c), commonly-owned/obligated-assignment subject matter cannot be used for obviousness; and where the inventive entity overlaps, § 102(e) status is also impaired (the earlier application is not "by another" as to the common inventor's contribution). So this reference should be treated with care — it is effectively applicant's own related work rather than independent prior art.

---

B. Non-patent citations (3)

N1. EP Search Report dated Nov. 3, 2006

This is the European search report in the EP 1511219 family, not prior art. It is not a § 102 reference. Its significance is procedural: it identifies the EPO examiner's cited art for the same invention — notably EP‑A‑1 289 191, US 6,421,319, WO‑A‑02/46947, and the Kamizuru/DIRE paper (these appear on the face of EP 1511219 B1).

N2. Fujinaga, Hotta & Asami, "A Tool for Monitoring Routing Information in the Internet"

• Citation: M. Fujinaga, T. Hotta, T. Asami (KDD R&D Laboratories), Proc. 1999 International Workshops on Parallel Processing (ICPPW '99), IEEE Computer Society, pp. 274–279 (1999). DOI 10.1109/icppw.1999.800073.
• Description (full text retrieved): A BGP monitor consisting of a "BGP Listener" that establishes a BGP session ("peers") with the AS border router, obtains routing information, logs every BGP message with a timestamp to a disk file for off-line analysis, and maintains an internal routing table for on-line analysis. Explicitly notes that CLI queries "consume precious CPU time of the border routers."
• § 102 relevance: Discloses BGP-message logging with timestamps and internal routing-table construction — thematically related to '885's claims 6/7 (RIB/routing-table construction) and the timestamping discussion in '885's Fig. 4 description. It does not disclose a two-router passive tap nor session emulation with a monitoring device, and — critically — it peers with the monitored router, i.e., it is the exact invasive approach '885 disclaims. It therefore does not anticipate claims 1/13/19, and it teaches away from the no-session limitations of claims 24/25/26. Best treated as a § 103 reference for the message-logging/RIB facet.

N3. Kamizuru & Amagai, "Distributed Inter-AS Route Monitor — Distributed Internet Route Eye (DIRE)"

• Citation: Y. Kamizuru, Y. Amagai (NTT), Proc. 1998 International Conference on Parallel and Distributed Systems (ICPADS '98), IEEE Computer Society, pp. 533–540, Tainan, Taiwan, Dec. 14–16, 1998. DOI 10.1109/ICPADS.1998.741129.
• Description (full text retrieved): A distributed agent architecture for inter-AS route monitoring: monitor agents (MAs) record detailed BGP route updates; operator agents (OAs) query multiple MAs and infer flap sources/causes. The MA "processes the minimum subset of BGP functionality needed to set up a BGP session and get BGP messages from a peer" — i.e., each MA establishes a BGP session with the target router. Route transitions are recorded with time information, and multipoint monitoring across ASs is described.
• § 102 relevance: Discloses multi-point BGP route monitoring, distributed querying, and timestamped transition logging — relevant background to the monitoring-log/timestamps and distributed aspects. But like Fujinaga, it requires a BGP session with the monitored router and does not disclose passive tapping between two routers or emulating a session to a separate monitoring device. Does not anticipate claims 1/13/19; teaches away from claims 24/25/26. § 103 reference. (The EPO examiner cited this paper on EP 1511219 B1 and in EP 1 158 723.)

---

C. Summary table — § 102 / § 103 mapping

---

D. Analyst conclusions and caveats

1. No reference anticipates the independent claims. The novelty of '885 lives in the combination — passive interception between two routers, routing-protocol message reassembly, and emulation of a routing-protocol session with a separate monitoring device in lieu of peering with the monitored routers. The two closest academic references (Fujinaga; DIRE) achieve monitoring by opening a BGP session with the monitored router, which is the very approach '885 frames as its problem — so they do not disclose, and in fact cut against, the negative limitations in claims 24/25/26.

2. Labovitz (US 2003/0037136) is the strongest candidate, but for § 103, not § 102 — it addresses BGP control-signal monitoring and routing-protocol attack detection (matching '885's stated "by-product") without the two-router-tap-and-emulate architecture.

3. Co-owned references are compromised as art. EP 1 289 191 (Agilent) and US 2004/0196841 (Tudor — a '885 co-inventor, Agilent) are commonly owned by the '885 assignee and, for US 2004/0196841, share an inventor. Under pre-AIA § 103(c) / § 102(e), these are subject to disqualification or "not by another" issues and should not be relied on as independent prior art for obviousness of '885. (Given '885's 2003 filing date, the pre-AIA framework applies.)

4. Prosecution-artifact flag (carried from the earlier section, not repeated). The granted abstract recites opening a routing-protocol connection "in response to a request for connection received from the network device," which the independent claims do not contain — worth checking the file wrapper when assessing which references the examiner actually relied on, since that language could bear on a "monitoring device initiates connection" reading that some of these references touch.

5. Limitations of this pass. I could not retrieve full text for US 6,157,644, WO 02/046947, or US 2006/0083511 within the search budget; my descriptions for those are title/assignee/date-based (authoritative record) and are marked as such. A complete § 102/§ 103 chart would require reading the specification and claims of US 2003/0037136 and the two academic papers element-by-element against each of claims 1–26, which I can do next if useful.

Sources: US 7,710,885 full text and citation tables — https://patents.google.com/patent/US7710885/en; US 2003/0037136 A1 abstract/claims — https://patents.google.com/patent/US20030037136 (and RPX record https://insight.rpxcorp.com/patent/US20030037136A1); US 6,421,319 — https://patents.google.com/patent/US6421319; EP 1 289 191 A1 — https://patents.google.com/patent/EP1289191A1/en; EP 1 511 219 B1 front page (cited refs) — https://patentimages.storage.googleapis.com/b5/82/d1/831e07e4a3f10f/EP1511219B1.pdf; Fujinaga et al. (1999) ICPPW full text (Semantic Scholar / IEEE DOI 10.1109/icppw.1999.800073); Kamizuru & Amagai (1998) DIRE, ICPADS, pp. 533–540 (IEEE DOI 10.1109/ICPADS.1998.741129).

Would you like me to build the element-by-element claim chart (claim 1 vs. Labovitz + Fujinaga/DIRE, and claim 1 vs. the Xyratex tap module + a session-emulation reference), or pull the '885 file-wrapper prosecution history to see which art the examiner actually applied?

I'll research the prior art references cited on the '885 page before building the § 103 combinations.

I have partial detail on several references and hit the search-step limit on others. Here is the § 103 analysis built from the Prior Art section of the US 7,710,885 page (the 11 "Patent Citations" and 3 "Non-Patent Citations"), plus the reference content I was able to retrieve.

---

Obviousness analysis of US 7,710,885 under 35 U.S.C. § 103

0. Governing law and framing (applies throughout)

• Which § 103 applies. US 7,710,885 was filed 2003‑08‑29 and claims that date as priority. It is therefore governed by pre‑AIA § 103(a) and the pre‑AIA § 102 categories (§ 102(a), (b), (e)), not the AIA's § 102(a)(1)/(a)(2)/§ 103. The controlling obviousness case law is Graham v. John Deere and KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007) (a combination is obvious where the improvement is "the predictable use of prior art elements according to their established functions," and where "there is a design need or market pressure … and there are a finite number of identified, predictable solutions").
• Person of ordinary skill in the art (POSA). For '885's 2003 priority date: a network engineer with a bachelor's in EE/CS and ~2–3 years of experience designing, configuring, or monitoring IP networks, including working familiarity with BGP‑4, TCP session handling, route servers/route reflectors, and network taps or SNMP/Telnet/"Looking Glass" monitoring.
• Claim scope assumptions. I apply the granted claim language literally, consistent with the earlier section's caution about the abstract/claim mismatch (the "in response to a request for connection received from the network device" language in the abstract appears nowhere in claims 1, 13 or 19, so it is not a limitation to be met).

Bottom line up front: No single reference anticipates any of claims 1, 13 or 19. But claims 1–23 are, in my assessment, strongly vulnerable to a § 103 challenge built from the references the examiner already had — most damagingly Labovitz (US 2003/0037136) in view of NEC (US 6,421,319) and Fujinaga et al. and/or Kamizuru & Amagai (DIRE), all of which are on the face of the patent. The negative-limitation claims 24–26 are the one place where the $103 case is meaningfully weaker and where the patent owner would concentrate its defense.

---

1. The prior-art arsenal (from the '885 "Prior Art" section)

The most important "prior art" of all is inside '885's own specification. The Background (§ Description) makes three admissions that map directly onto claim elements:

1. Taps/sniffers already captured routing messages off a link: "Taps and sniffers are devices that actually tap into a communication line between two or more routers … Such tapping methods typically capture the routing information and display it as formatted BGP data." → admitted tap + capture + Web-display.
2. Taps/sniffers did so without a session: "such tapping/sniffing methods allow for passively capturing or recovering routing information without establishing a BGP session with the monitored routers." → this is squarely the claim 24–26 negative limitation, admitted as known.
3. Software already implemented BGP/RS/RR and reconstructed routing tables: "Zebra is a routing software that captures BGP traffic via established BGP sessions … and reconstructs routing tables … Zebra may be used to implement a router, RS, or RR." → admitted capability to terminate/re-originate BGP sessions in software and to build tables.

These admissions collapse much of the distance between the prior art and the claims.

---

2. Element-by-element mapping of independent claim 1

Every element has a home. The only question is whether the combination was obvious — which is where the motivation analysis (§ 4) does the work.

---

3. The primary § 103 combinations

Combination A — Labovitz + NEC + Fujinaga (the "plug the tap into the existing monitor" combination)

• What each contributes: NEC supplies the passive line tap between two network elements (claim 1(a)); Fujinaga supplies the routing-information reconstruction from passively monitored routing traffic (claim 1(b) reassembly); Labovitz supplies the monitoring architecture — a BGP-aware collector that reconstructs/stores/timestamps routing messages and serves them to a central monitoring device and a Web front end (claim 1(b) "network monitoring device" + claims 2/8).
• What remains: framing the "network monitoring device" as the entity with which the emulator opens a TCP/BGP session rather than merely a database it writes to. This is supplied by the Zebra/RS/RR admission in '885's own Background (software can act as an RS/RR and open BGP-over-TCP sessions) and by Labovitz's own disclosure of the collector maintaining BGP peering sessions over TCP.

Combination B — Fujinaga (or DIRE) + NEC (or Xyratex) + Zebra/RS (as admitted art)

• Fujinaga/DIRE teach passive capture and BGP message reconstruction with timestamps; NEC/Xyratex teach the tap; Zebra/RS teach the software BGP stack that re-originates a session to a consumer device. Any one of these pairings lands within claim 1.
• DIRE adds an express teaching that a monitor can run "the minimum subset of BGP functionality needed to set up a BGP session and get BGP messages from a peer" — i.e., a partial BGP stack on a monitoring box, which is the very "protocol emulator" concept.

Combination C — Labovitz + Xyratex + EP 1 289 191

• Substitutes a hardware tap module (Xyratex) and Agilent's monitoring framework for NEC, reaching the same claim 1 structure. Useful primarily as an alternative if the patent owner attacks NEC's line-monitoring context (TA/DSU rather than router-to-router).

---

4. Why a POSA would have been motivated to combine — the KSR case

1. The problem and its solution are stated in the '885 specification itself. The Background identifies the exact deficiency to be solved: "Establishing and running a BGP session with the monitored router drains the monitored router's CPU cycles"; "The establishment of such BGP sessions is very invasive"; and the cascade-of-resets problem when such sessions fail. The predictable solution — stop opening sessions with the monitored routers (NEC/Fujinaga passive tap) and obtain the same routing information from a tap — is the identified need. KSR: a design need supplies the motivation.
2. The second half of the problem supplies the second half of the combination. '885 also wants to keep using the route server + Looking Glass pipeline ("Similarly to network 10, network 20 is configured with route server 205 … via Looking Glass Web server 206"). To avoid reconfiguring/replacing that infrastructure, the reconstructed data must reach the route server in a form it accepts — i.e., as a BGP session. Labovitz's monitor-plus-central-device architecture and the Zebra/RS admission show the mechanism (a software BGP peer on the monitoring side).
3. All the pieces are known, off-the-shelf, and individually conventional in the same field (network management/routing monitoring), which KSR treats as a strong indicator of obviousness. TCP reassembly, BGP message parsing, timestamped logging, opening a TCP socket to port 179, and Web/Looking-Glass presentation were all standard.
4. Predictable results / reasonable expectation of success. Fujinaga and DIRE had already built working BGP monitors that reconstruct routing information; Labovitz had built a working BGP-aware collector; Zebra had already demonstrated a working software BGP/RS/RR stack. Combining a working passive capture/parse front end with a working software BGP stack to feed an existing RS is a mechanical integration with no new physics — the "predictable use of prior art elements according to their established functions."
5. "Finite number of identified, predictable solutions." Given the stated problem (avoid router-CPU-draining sessions), the universe of solutions was essentially: (i) poll the router (SNMP/Telnet — admitted), (ii) peer with it (Zebra/RS — admitted), or (iii) tap the link and reconstruct (taps/sniffers — admitted). Selecting option (iii) and rendering its output to an existing RS is the finite, predictable answer.
6. "No router configuration changes" as a further motivation. '885's own stated benefit — "they teach non-invasive information capturing and may not require router configuration changes" — is a classic design incentive, and the tap technology (NEC/Xyratex) already delivered it.

---

5. Dependent-claim obviousness (summary)

---

6. The hard question: claims 24–26 (the "no session with either router" negative limitations)

These are the only limitations that meaningfully distinguish the claims from Labovitz/DIRE, both of which do open sessions:

• Labovitz: collector "maintain[s] BGP peering sessions with BGP routers" and sends Keepalives (i.e., a session, albeit a "passive" one).
• DIRE: the MA explicitly "set[s] up a BGP session" with the target router.

The § 103 case for 24–26 nonetheless survives, but on a different footing — admission + explicit art:

1. '885's own admission. The specification states that "tapping/sniffing methods allow for passively capturing or recovering routing information without establishing a BGP session with the monitored routers." Under In re Fout and the admission-against-interest line of cases, this is prior art that can be combined. It teaches the negative limitation directly.
2. NEC teaches monitoring traffic on a line without any session with the monitored elements (branch-cable tap), so the "no session" character is supplied.
3. Why a POSA would preserve sessionlessness while adding emulation. The entire motivation identified in § 4 — eliminating router-CPU drain and the invasiveness of peering — makes "don't session with the monitored routers, only session with the monitoring/route-server side" the point of the combination, not an unexpected twist. KSR: where the motivation is to avoid sessions on one side, delimiting the claimed method to not have sessions on that side is the natural result of applying the known technique.

Where the patent owner will (and should) fight: it can argue that Labovitz's "passive peering session" and DIRE's MA session are affirmative teachings away from the negative limitation — i.e., the art the examiner relied on perceived value in at least a lightweight session, so a POSA would not have been prompted to eliminate it entirely. That is a real, but not fatal, argument: the '885 Background's own admission that sessionless sniffing was known, combined with the express "avoid the router CPU drain" motivation, supplies the missing link. Claims 24–26 should be treated as the strongest claims in the set and the focus of any validity defense (consistent with the earlier sections' characterization of 24–26 as "the moat").

---

7. Anticipation is not available — go § 103

No single reference discloses all elements of claim 1/13/19:

• Labovitz lacks the tap positioned in a line between two routers (it peers with routers) and does not describe the emulator re-originating a session to a separate network monitoring device.
• NEC lacks BGP/routing-protocol reconstruction and session emulation.
• Fujinaga/DIRE lack the re-originated session to a separate route server (both peer with/collect from routers directly).

So the challenge is a § 103 combination, not § 102. This matters for how the petition/contention is framed.

---

8. Claim-by-claim summary of the § 103 challenge

---

9. Risks, counterarguments, and caveats for the challenger

1. § 325(d) is the biggest practical threat to a PTAB petition. Labovitz, Fujinaga, DIRE, NEC, EP 1 289 191, and Tudor were all before the examiner (they appear on the '885 face / IDS). The Board routinely exercises discretion to deny petitions that rely on "the same or substantially the same art previously presented." To avoid this, a petitioner should anchor on new art the examiner never saw — most promisingly art on TCP stream reassembly + connection re-origination (TCP proxy / NIDS-reassembly) to supply claim 1's "opens a transport protocol connection using reassembled transport messages," and on route-server/route-reflector session re-origination, none of which is in the 11-reference list.
2. § 103(c) (pre‑AIA) may disqualify some combination references. Tudor US 2004/0196841 and the Agilent EP 1 289 191 sit in the same corporate family as '885's assignee. Pre‑AIA § 103(c) bars use of § 102(e)/(f)/(g) art "commonly owned" as of the invention for obviousness purposes. Tudor's US published application is § 102(e) art, so it may be unavailable for the combination (though it could still be cited for what a POSA knew). EP 1 289 191 published 2003‑03‑05 and thus qualifies under § 102(a)/(b) as a printed publication; § 103(c) does not reach § 102(b) art, so it stays available. This asymmetry should be checked in the file wrapper and assignment records before relying on Tudor.
3. Patent owner's "teaching away" arguments. DIRE's and Labovitz's affirmative use of sessions (albeit "passive"/lightweight) can be argued as teaching away from the fully sessionless claims 24–26. Counter with the '885 admission and the express anti-session motivation.
4. I could not retrieve full text for Fujinaga, Moore (US 2002/0163934), Xyratex (US 2006/0083511), EP 1 289 191, or WO 02/046947. Their characterization above rests on titles, bibliographic data, and citation context. Before filing anything, obtain and read the full documents — particularly Fujinaga, since my Combination A/B analysis leans on it as the primary "tap-and-reconstruct" reference.
5. The § 112 issues are not § 103 issues. The abstract-vs-claims mismatch ("in response to a request for connection received from the network device") and the definiteness of "protocol emulator" are litigation/§ 112 arguments, not IPR grounds (IPR is limited to § 102/§ 103 on patents and printed publications). Preserve them separately, as the earlier section recommended.
6. Cross-reference/consistency check: the earlier sections flagged the abstract/claim mismatch and the "24–26 = moat" framing. This analysis is consistent with both; it does not contradict them. The one nuance to flag is that the earlier PTAB section characterized claims 24–26 as indicating the patent is hard to attack; on a pure obviousness reading the rest of the claim set (1–23) is the more exposed part, and 24–26 are the residual defense. Those are compatible statements — 24–26 are the last line, not the first.

---

10. Conclusion

US 7,710,885's independent claims 1, 13 and 19 recite a passive tap + routing-protocol/transport reassembly + re-originated routing-protocol session to a separate monitoring device. Each element is disclosed in art already on the patent's face — Labovitz (US 2003/0037136) for BGP-aware capture/reconstruction and the monitoring-device/Web pipeline, NEC (US 6,421,319) for the in-line passive tap, Fujinaga (1999) and Kamizuru & Amagai / DIRE (1998) for routing-information reconstruction — with the "software BGP stack that opens a session to a route server" element supplied by '885's own admitted Zebra/RS/RR prior art and by Labovitz's session-maintaining collector. The motivation is not speculative; it is stated in '885's own Background: avoid the CPU drain and invasiveness of BGP sessions with monitored routers while preserving the existing route-server/Looking-Glass pipeline. That is a textbook KSR combination of known elements performing their established functions with predictable results.

Claims 1–23 are highly vulnerable; claims 24–26 are the defensible core. A challenge should be built as a § 103 combination with new, non-cumulative art (TCP reassembly/re-origination and route-server session emulation) to sidestep § 325(d), and it should be prepared to meet the "teaching away from sessionless monitoring" argument on claims 24–26 head-on using the '885 specification's own admissions.

Key sources: '885 full text and citation list — https://patents.google.com/patent/US7710885/en ; Labovitz US 2003/0037136 — https://patents.google.com/patent/US20030037136 and https://www.patentsencyclopedia.com/app/20110296005 ; NEC US 6,421,319 — https://patents.google.com/patent/US6421319 and https://www.freepatentsonline.com/[6421319](/patent/6421319).html ; Fujinaga et al. (1999) — https://ieeexplore.ieee.org/document/[4019911](/patent/4019911)/references ; Kamizuru & Amagai DIRE (1998) — https://ieeexplore.ieee.org/document/[741129](/patent/741129) ; EP 1 511 219 B1 (family member, showing examiner-cited art) — https://patents.google.com/patent/EP1511219B1/en.