US 7936738

I'll verify the patent details against live sources and check for any 2026 litigation/PTAB activity.

Let me check for any 2026 CAFC activity and the newer district court cases involving this patent.

Let me do a final check for any Federal Circuit appeal specifically involving this patent.

US 7,936,738 B2 — Verified Summary

Source of record: the authoritative full text at https://patents.google.com/patent/US7936738/en (fetched 2026-09-16), cross-checked against live search results for PTAB and district-court activity.

1. Bibliographic data

Assignee chain of record (Legal Events): HP Development Co LP (filed 2004) → Hewlett-Packard Development Company, L.P. (recorded 2006-03-02, effective 2005-07-19) → Hewlett Packard Enterprise Development LP (2015-11-09) → OT Patent Escrow, LLC (2021-01-26) → Valtrus Innovations Limited, Ireland (2021-08-26).

2. Abstract (verbatim)

"According to one embodiment of the present invention, there is provided a method of storing context information in an outgoing message sent from a node using a protocol stack having at least one layer, comprising: selectively indicating to a layer of the protocol stack that context information should be obtained for that layer; obtaining context information in accordance with the indication; and adding the obtained context information to the outgoing message such that a response to the message contains the context information."

3. Plain-language overview of each independent claim

The patent's core idea: instead of keeping a shared database of "context" (call state) for high-availability failover, the node writes its own state into an outgoing message, so the reply comes back carrying that state — allowing the protocol stack to be rebuilt after a switchover.

• Claim 1 — Storing context (method). A computing device sends an outgoing message from an application down into a protocol-stack layer, where the message is destined for an application on a destination node. The node selectively signals that layer to obtain context information for that layer; the layer obtains it and adds it to the outgoing message — set up so that the response received from the destination node contains that context information. The "selectively" and the response-loop requirement are the load-bearing limitations.

• Claim 11 — Restoring context (method). A device receives a message and decides whether the layer's context should be restored; if so, it checks whether the message carries context information relevant to that layer, and restores the layer using it. Critically, the recited determination includes checking whether the received message is an "initial message" (e.g., a SIP INVITE) — i.e., don't try to restore from a message that starts a new session.

• Claim 17 — Storing context (system). The apparatus counterpart of claim 1: a circuit that passes the outgoing message from the application to a stack layer, "means for indicating" the layer should obtain context, a module that obtains it, and a circuit that adds it to the outgoing message so the response from the destination node carries it.

• Claim 27 — Restoring context (system). The apparatus counterpart of claim 11: receiving means, logic that determines whether the layer's context should be restored, a circuit that detects relevant context information in the message, and restoration means. Again, the logic must be configured to check whether the received message is an initial message.

• Claim 33 — Sending through a layered hierarchy (method). Broader framing of claim 1 (a "hierarchical structure of one or more discreet layers") but with a sharper purpose clause: the response must contain the context information "needed to restore a pre-switchover context of the layer."

• Claim 34 — Restoring across a layered hierarchy (method). Mirrors claim 11 in the "hierarchical structure" framing, including the initial-message check.

Depended-upon concepts: multi-layer context aggregation (cl. 2/18), SIP TAG field (cl. 8/15/24/31), SIP extension header (cl. 9/16/25), and flagging context as potentially inaccurate or incomplete (cl. 10/26 — the billing-accuracy concern discussed in the spec).

4. Notable drafting observation (flagged, not corrected)

Claim 32 as published recites "…using context information stored in a SIP TAG" — identical wording to claim 31, which appears to be a duplicate rather than the extension-header variant that claim 16 uses. I am reporting the text literally; this looks like an apparent error on the face of the claim set, and I cannot confirm the file history's intent from the sources retrieved.

5. Litigation / PTAB posture (as of the retrieved results)

• PTAB — IPR2025-00419, SAP America, Inc. and SAP SE v. Valtrus Innovations Ltd. (patent owner also identified as Key Patent Innovations Ltd.). Filed Jan 15, 2025; challenged claims reported as 1–10 and 33 (one summary says 1–6, 10, 33) on a single obviousness ground over Forissier, US 7,936,763 (note: a different patent number from the '738 — I am quoting the petitioner's cited reference literally). Status: Terminated–Settled, termination decision July 1, 2025 (pre-institution dismissal). Sources: https://ipverse.greyb.com/ptab-web/cases/case-details/IPR2025-00419 and https://ai-lab.exparte.com/case/ptab/IPR2025-00419/doc/summary/1
• District courts: E.D. Tex. 2:24-cv-00021-JRG (Valtrus v. SAP); W.D. Wash. 2:25-cv-01859; and N.D. Cal. 3:26-cv-00363, Google LLC v. Valtrus Innovations Ltd. et al., filed Jan 13, 2026 — a Google declaratory-judgment action whose amended complaint expressly seeks DJ of non-infringement of U.S. Patents 8,379,538; 7,640,332; 7,904,686; and 7,936,738 (https://www.pacermonitor.com/public/case/62460975/, https://dockets.justia.com/docket/california/candce/3:2026cv00363/[462536](/patent/462536)).
• CAFC: I found no 2026 Federal Circuit docket specifically involving US 7,936,738. The March 4, 2026 argument in Google LLC v. Valtrus Innovations Ltd., No. 24-1945, appears to concern different Valtrus patents (the search/CPU-metering family addressed in the Aug. 10, 2026 N.D. Cal. § 101 dismissal order), not the '738.

6. Stated uncertainties

• The IPR case summaries surfaced by search are AI-generated and give varying wordings for the patent title ("Storing Context Information In An Outgoing Message"; "Method and System for Providing Fault Tolerance in Communication Systems"). The title of record is simply "Fault tolerant systems."
• Claim counts challenged in IPR2025-00419 differ between retrieved summaries (1–10 & 33 vs. 1–6, 10 & 33).
• Google Patents' assignee list carries its own accuracy disclaimer; the chain of record above is drawn from the recorded Legal Events, which are more reliable but still not a chain-of-title opinion.
• I could not complete a live PACER/CAFC docket query; the litigation items above come from third-party aggregators and should be confirmed against PACER before reliance.

I'll research the litigation history for US 7936738. Let me run several targeted searches.

Let me dig into the specific case numbers and any additional suits asserting the '738 patent.

Litigation involving U.S. Patent No. 7,936,738

Important framing note: Per the strict-literalism rule, I did not normalize any identifier. Also note that the patent's Google Patents family page itself carries the "Family has litigation" flag and links four matters to this family: PTAB case IPR2025-00419, W.D. Wash. 2:25-cv-01859, E.D. Tex. 2:24-cv-00021, and N.D. Cal. 3:26-cv-00363. Those four, plus the related Federal Circuit mandamus, are the matters I could verify as touching the '738 patent.

The '738 patent (Fault Tolerant Systems; application 10/536,625; inventor Sebastien Bouat; current assignee Valtrus Innovations Ltd) has been asserted/enforced by Valtrus Innovations Ltd. and its co-plaintiff Key Patent Innovations Ltd. — characterised in the record as successors-in-interest to an HP/HPE patent portfolio.

1. District Court Litigation

A. Valtrus Innovations Ltd. v. SAP America, Inc. and SAP SE

Sources: Justia docket 2:24-cv-00021; goldencompass litigation record listing plaintiff Valtrus, defendant SAP, E.D. Tex., Judge Gilstrap, patents incl. 7936738 (link); In re SAP America, Fed. Cir. 25-118; Law360 IP feed, Dec. 9, 2025 (link).

⚠️ Caveat: I could not confirm from the retrieved material whether the Dec. 9, 2025 SAP settlement Law360 reported pertains to 2:24-cv-00021 or to the companion Valtrus–SAP case 2:25-cv-00556 (which asserted different patents — 7,856,420; 8,515,916; 8,379,538; 9,229,984). I therefore cannot state the final disposition of 2:24-cv-00021 with high confidence. What I can confirm is that the '738 IPR brought by SAP was terminated as settled in mid-2025, which strongly signals a negotiated resolution of the '738 dispute.

B. Starbucks Corporation v. Valtrus Innovations Limited et al. (declaratory judgment)

Sources: PacerMonitor docket; Ex Parte complaint analysis, 2:25-cv-01859 (contains the '738 claim-element table).

C. Google LLC v. Valtrus Innovations Ltd. (declaratory judgment)

Sources: Ex Parte complaint analysis, 3:26-cv-00363; Google Patents family page litigation link.

Related but unverified for '738: Valtrus Innovations Ltd. et al v. Google LLC, N.D. Cal. 5:26-cv-02379, in which an order granting a motion to dismiss was entered Aug. 10, 2026 (Judge P. Casey Pitts) on standing/claim-splitting grounds (GovInfo; MLex summary). I could not confirm that the '738 patent was among the patents asserted in that infringement action, so I flag it rather than list it as a '738 case. Similarly, a "NetApp" DJ action is referenced in PTAB papers alongside the Starbucks DJ action, but I could not verify it involves the '738 patent.

2. PTAB — Inter Partes Review

SAP America, Inc. et al. v. Valtrus Innovations Ltd. — IPR2025-00419

• Petitioner: SAP America, Inc. (and, per the PTAB record/related filings, SAP SE)
• Patent Owner: Valtrus Innovations Ltd. (and Key Patent Innovations Ltd.)
• Patent challenged: 7,936,738 (application 10/536,625; Tech Center 2400)
• Filed: January 15, 2025
• Claims challenged: 1–10 and 33
• Ground: Obviousness (pre-AIA §103) over Forissier (U.S. Patent 7,936,763)
• Status/Outcome: Terminated — Settled. Petitioner filed a Motion to Terminate (June 25, 2025); the Board issued a Termination Decision (Pre-DI dismissal) on July 1, 2025; refund of post-institution fees requested July 8, 2025 and approved Aug. 5, 2025. The Google Patents family page labels this event "PTAB case IPR2025-00419 filed (Procedural Termination)."

Sources: IPVerse case page; Ex Parte petition analysis; Ex Parte case tracker.

3. Appellate — Federal Circuit

In re SAP America, Inc., SAP SE, Petitioners — No. 2025-118

• Court: U.S. Court of Appeals for the Federal Circuit
• Filed: February 4, 2025
• Nature: Petition for writ of mandamus to compel transfer of E.D. Tex. 2:24-cv-00021-JRG from the Marshall Division to the Sherman Division and random reassignment
• Outcome: Petition denied (per curiam order, April 10, 2025; panel of Dyk, Prost, and Chen). The court found the district court erred on two factors (reliance on the closed AT&T litigation and the "smoothly proceeding" congestion rationale) but held SAP failed to show the denial was patently erroneous.

Sources: In re SAP America order; Justia CAFC docket 25-118.

Summary Table

Confidence and Limitations

• High confidence: the existence of matters 1–5 above and the IPR termination (settled) and the Federal Circuit mandamus denial.
• Lower confidence / explicitly flagged: (a) whether the Dec. 9, 2025 Law360-reported SAP settlement is the 2:24-cv-00021 case or the companion 2:25-cv-00556 case; (b) whether the '738 patent was asserted in the Valtrus v. Google N.D. Cal. 5:26-cv-02379 infringement action that was dismissed in August 2026; (c) whether the "NetApp" DJ action referenced in PTAB papers involves '738.
• I could not retrieve results directly from the Unified Patents litigation caselist portal or PACER itself during this session; the information above is derived from secondary docket aggregators (PacerMonitor, Justia, CourtListener, GovInfo, RPX, IPVerse, Ex Parte AI trackers) and the Google Patents family page. A PACER pull of 2:24-cv-00021's final docket entries would be needed to state its disposition with certainty.
• I did not auto-correct any patent or case identifiers; all numbers are reproduced as they appear in the sources cited.

I'll research the PTAB proceedings on US 7936738, starting with the proceeding number that surfaced in the patent's own litigation metadata.

I have detailed data on IPR2025-00419. Now let me check whether any other IPRs or appeals exist on this patent.

PTAB Proceedings — U.S. Patent No. 7,936,738 ("Fault Tolerant Systems")

Important reconciliation up front. The structured "PTAB proceedings on file" block drawn from the USPTO Open Data Portal returns no AIA trial proceedings for this patent. That ingest is stale or incomplete. The patent's own Google Patents legal-events record shows an IPR filed 2025-04-01 (event date 2025-01-15), and web sources confirm it. So the correct answer is one proceeding, not zero — I flag the ODP gap rather than treating it as the canonical list. I found no second IPR, no PGR, no CBM, and no ex parte reexam on the '738 patent itself.

Proceedings overview

One AIA trial proceeding has been filed against US 7,936,738 — IPR2025-00419 — and it ended in voluntary pre-institution termination on 2025-07-01 (no claims invalidated, no claims sustained, no institution decision, no FWD, no settlement), which leaves the patent completely untested at the PTAB: every claim (1–34) remains live and enforceable, so a defendant today cannot point to a canceled claim, but it can pick up an unchallenged § 103 theory built on the Forissier reference that SAP had packaged and then abandoned.

Caveat on nomenclature: at least one commercial database (GreyB/ipverse) returns the status "Terminated-Settled." That label is wrong on the facts — the termination motion states: "The parties have not reached a settlement agreement regarding this, or any other, patent." Treat this as a pre-institution dismissal, not a settlement.

IPR2025-00419 — SAP America, Inc. & SAP SE v. Valtrus Innovations Ltd. & Key Patent Innovations Ltd.

• Type: Inter Partes Review
• Filed: 2025-01-15 (Petition filed; accord notice 2025-03-10)
• Status: Structurally: "PTAB case IPR2025-00419 filed (Procedural Termination)" (Google Patents). Commercially reported as: "Terminated-Settled" (GreyB/ipverse) — inaccurate; no settlement occurred. Plain English: petition withdrawn, proceeding closed before the Board ever decided whether to institute.
• Judge panel: Reported as APJs Linda E. Horner, Nabeel U. Khan, and Thomas L. Giannetti (Ai-Lab PTAB case page). Because the case closed pre-institution, no panel authored a merits or institution decision; treat the panel attribution as provisional.
• Petition grounds: Ground 1 — claims 1–10 and 33 unpatentable as obvious under 35 U.S.C. § 103 over Forissier (U.S. Patent No. 7,936,763 to Forissier et al.; supporting EP application 03291191.9, 2003-05-20, Ex. 1106). No § 102 or § 112 ground was asserted. Petitioner's theory: Forissier's load-balancer inserts a "destination identifier"/tag (mapped to the claimed "context information") into an outgoing SIP message such that every response echoes it — allegedly meeting claims 1 and 33, with dependent claims 2, 6, 7–9, and 10 mapped to layer-crossing context, separate field/extension header, SIP TAG use, and the "potentially inaccurate or incomplete" flag respectively. Expert: Declaration of Kevin Almeroth, Ph.D. (Ex. 1103).
  • Discrepancy note: Two AI-generated petition summaries on third-party sites list the challenged claims as "1–6, 10, and 33." The authentic USPTO-filed petition text (CHALLENGED CLAIMS section, PTACTS) reads: "Ground 1: Claims 1-10 and 33 are unpatentable as obvious under 35 U.S.C. § 103 based on Forissier (Ex-1105)." Claims 1–10 and 33 is the operative set.
• Institution decision: None issued. The Board had authorized SAP to move to withdraw on 2025-06-23, before any institution decision was due. Procedurally: PO briefed discretionary denial under § 314(a)/Fintiv (2025-05-09); SAP replied on discretionary denial (2025-06-09); PO filed its preliminary response (2025-06-10); SAP moved to terminate (2025-06-25); Board granted pre-DI dismissal on 2025-07-01; post-institution fees refunded (approved 2025-08-05). No Fintiv analysis, no § 325(d) ruling, no merits reasoning is on the record.
• Final Written Decision: None. No claim of the '738 patent has ever been canceled, confirmed, or adjudicated by the Board.
• Settlement / termination: No settlement. SAP's motion recited that the parties had not settled "this, or any other, patent," that PO did not oppose termination, and that SAP was time-barred under § 315(b) from refiling on the '738 patent because it had been served 2024-01-17 — i.e., SAP burned its one IPR shot to preserve resources for the parallel E.D. Tex. case. SAP's parallel-court stipulation (Ex. 1118, 2025-05-06) that it would drop from the district court case any ground raised or that could have been raised in the IPR was expressly conditioned on institution and therefore never took effect.
• Appeal: None. With no institution and no FWD, there is no appealable Board decision. No CAFC docket, no CourtListener entry.
• Defensive value: For a defendant today, this proceeding is evidence of nothing adjudicated — no estoppel, no invalidation, no estoppel-triggering FWD. Its real value is intelligence: SAP's petition and Almeroth declaration constitute a ready-made, prosecution-clean § 103 attack on claims 1–10 and 33 built on Forissier, a reference Petitioner argued was "never cited, considered, or relied upon by the Examiner." That package is reusable by any party who is not in privity with SAP. Conversely, do not assume the patent is weak because an IPR was filed — it was withdrawn before the Board could say anything.

Relevant linkage in the same family of proceedings (do not conflate with the '738 patent): SAP filed a cluster of IPRs against the Valtrus/HPE portfolio in the same window (see e.g. IPR2025-00416 and IPR2025-00418 in the public dockets, which concern other Valtrus patents); Valtrus's own exhibits are captioned under multiple case numbers. "SAP filed IPRs on Valtrus patents" is true; only IPR2025-00419 is on the '738 patent on the record I could verify.

Strategic summary

Claim status: everything is UNTESTED. There are no CANCELED claims and no SUSTAINED-by-the-Board claims of US 7,936,738. Claims 1–10 and 33 were challenged but never adjudicated — they remain presumptively valid, as do claims 11–32 (the restoration-side method/system claims, including the claim 34 method and the system claims 17–32) and claim 34, which no petitioner has ever touched. Practically, the claims Valtrus actually asserts are narrow: in the SAP litigation, Valtrus's infringement expert Farach-Colton addressed claims 1, 3, and 33 of the '738 patent; Google's N.D. Cal. DJ complaint (3:26-cv-00363, filed 2026-05-04) uses claim 1 as exemplary against Google's Managed Service for Kafka; Starbucks's W.D. Wash. DJ complaint (2:25-cv-01859, filed 2025-09-25) also targets claim 1. So the commercially significant assertions cluster on claims 1, 3, and 33 — exactly the claims SAP charted and then abandoned, and the only set for which a fully drafted petition already exists.

Estoppel landscape is empty — and that cuts both ways. Section 315(e)(2) estoppel attaches only where an IPR "results in a final written decision." IPR2025-00419 produced no FWD, so SAP carries no statutory estoppel from it; the only constraint on SAP is the § 315(b) one-year bar (it was served 2024-01-17 and is now time-barred from filing again on the '738 patent, as SAP itself conceded). For a different defendant, no estoppel whatsoever applies, and the full prior-art field is open — including Forissier (US 7,936,763 / EP 03291191.9) under § 103 against claims 1–10 and 33, plus any art beyond it. Two structural points favor you: (i) the '738 patent is pre-AIA (priority 2003-07-25; filed 2004-07-06), so § 102(e) art and pre-AIA § 103 standards govern; and (ii) Valtrus's own litigation-driven claim narrowing (an exhibit in the record shows a Patent Owner claim-narrowing election in the E.D. Tex. case) means the asserted set may be pared further, and PO has already been forced to brief claim construction on "context information" and "potentially inaccurate or incomplete."

Pattern signals. The petitioner is a practicing-competitor defendant (SAP), not a defensive aggregator — Unified Patents is in the picture on the Valtrus campaign but as a litigation analyst and PATROLL bounty sponsor, and its published contests target other Valtrus patents ('538, '686), not the '738 patent; I found no Unified IPR against the '738 patent. Valtrus/KPI is a high-volume NPE (Google's complaint alleges suits against at least 20 companies, and Valtrus/KPI are the HPE portfolio successors; Valtrus is the trustee, Key Patent Innovations the beneficial owner). There is no PTAB appeal activity by the patent owner on this patent because there has been nothing to appeal. Net: this is a freshly-asserted, never-challenged patent in a broad campaign — a target-rich environment for invalidity work, not a hardened patent.

Recommended next steps

1. Do not tell your client any claim is invalid. Quote the record precisely: the Board's 2025-07-01 pre-DI dismissal closed IPR2025-00419 with no FWD and no canceled claims. If opposing counsel claims "SAP's IPR was settled/ended, so the patent is weak," the accurate response is that the petition was withdrawn before institution on SAP's own motion and that the parties expressly had not settled.
2. If you are not SAP (or in privity with it), file your own IPR on Forissier. The ready-made ground is: claims 1–10 and 33 obvious under § 103 over Forissier (US 7,936,763 / EP 03291191.9, 2003-05-20), with the Almeroth declaration as a model. Statute of limitations: verify your own § 315(b) one-year clock from the service date of the earliest complaint asserting the '738 patent (SAP's clock ran from 2024-01-17). The petition's argument that Forissier was never before the Examiner is a strong § 325(d) posture; expect PO to run Fintiv/§ 314(a) discretionary denial as it did in 2025 (it briefed this on 2025-05-09).
3. Mine the abandoned record. The full petition, exhibit list (Ex. 1101–1117), claim listing, and discretionary-denial briefing are public in PTACTS at the IPR2025-00419 petition landing page: https://ptacts.uspto.gov/ptacts/public-informations/petitions/[1557221](/patent/1557221). The Board's termination paperwork and docket are tracked at https://portal.unifiedpatents.com/ptab/case/IPR2025-00419 and via the Ai-Lab PTAB case page https://ai-lab.exparte.com/case/ptab/IPR2025-00419. Board decisions are publicly posted at USPTO PTAB (https://www.uspto.gov/patents/ptab/decisions); there is no FWD to cite, and I will not pretend otherwise.
4. Plan for the untested claims. Claims 11–32 and 34 have never been challenged in any AIA proceeding. If Valtrus adds them, you have no PTAB roadmap on them — budget independent prior-art work. Likewise, PO's own narrowing election is an exhibit in the record; obtain and analyze it, because it defines the actual asserted set you must beat.
5. Watch the litigation track for PTAB-relevant developments. PO's standing is under attack (SAP moved to dismiss for lack of standing in E.D. Tex. 2:24-cv-00021), and both Google (N.D. Cal. 3:26-cv-00363) and Starbucks (W.D. Wash. 2:25-cv-01859) are running DJ actions on the '738 patent. A standing dismissal or a DJ invalidity holding would be a faster, cheaper kill than an IPR — and either would moot the need to re-file a petition.

Bottom line for a defendant today: No claim is dead. Nothing at the PTAB is pending; nothing was decided. Your leverage is (a) a fully formed, never-instituted § 103 theory on Forissier aimed at claims 1–10 and 33, and (b) the litigation side's unresolved standing, indefinite-claim ("context information") and § 103 exposure. Do not overstate the first proceeding — but do not let anyone tell you it hardened the patent either.

Sourcing note: the proceeding number, dates, parties, and termination are corroborated by the '738 patent's Google Patents legal-events record (IPR event, 2025-04-01 entry, Petitioner "SAP AMERICA, INC., AND SAP SE"), the USPTO PTACTS petition files, Board-facing docket summaries, and the Ai-Lab PTAB docket. Judge-panel attribution and the "Challenged Claims" count come from third-party docket aggregators and an AI-summarized docket; where those conflicted with the filed petition text, I followed the filed petition. I did not find any Federal Circuit appeal, PGR, CBM, or ex parte reexamination directed to this patent, and I am flagging that absence rather than asserting completeness.

I'll reconstruct the ownership chain from the authoritative patent text and cross-reference external records.

I have strong external context. Now let me pin down the recorded-assignment correspondent details and the IPR/litigation status.

Let me attempt to identify the recording correspondents of record for the two post-issuance assignments.

US 7936738 — Ownership Chain Reconstruction

Patent: US 7,936,738 B2 — "Fault tolerant systems" · App. 10/536,625 · PCT/EP2004/051371 · Priority EP03291852.6 (2003‑07‑25) · Granted 2011‑05‑03 · Adjusted expiration 2028‑04‑17 (≈19 months of term remain as of today)

⚠️ Data-provenance caveat up front: Google Patents' legal-events table exposes reel/frame, conveyance type, assignor, assignee and execution/recording dates, but not the correspondent-of-record field. Neither Google Patents nor the searches I ran surfaced the recording attorney/firm for any of the four assignments below. I have not inferred or invented correspondent names. That field must be pulled directly from Assignment Center (see verification link at the end) — it is the one column in your request I could not populate from available sources.

Inventors

Unusual-pattern check: Only one inventor, and no public evidence of departure from HP within 12 months of filing. I could not verify Bouat's post‑2004 employment history from any source in this session — unclear, not a finding. Note that this is a single-inventor, French-origin, SIP-telephony defect-tolerance invention, which is atypical of the HPE assertion portfolio (most of the asserted HPE patents are US-origin, multi-inventor enterprise-computing patents). Treat the "inventor exodus" heuristic as not applicable / unverified here.

Original assignee

Hewlett‑Packard Development Company, L.P. (Texas), a subsidiary of Hewlett‑Packard Company. Assignee shown on the face of the issued patent and the "current assignee (original)" field.

• Line of business: HP was the dominant enterprise computing, server, storage and telecom-infrastructure OEM of the era. This patent sits in HP's carrier-grade / OpenCall / service-control-point product family (SS7 SCP, SIP B2BUA, high-availability signalling platforms) — i.e., HP shipped products that practised this class of subject matter (OPENCALL, HP Service Activator, and the SIP/SS7 HA platforms referenced in the specification's FIGS. 1 and 3).
• Current status: Operating. HP Inc. and Hewlett Packard Enterprise split in November 2015; HPE (the enterprise/spinoff entity, now "Hewlett Packard Enterprise Company") remains an active S&P 500 operating company. No bankruptcy, no dissolution.
• Key point: HP/HPE never asserted this patent. Neither did the escrow conduit. Assertion began only after the 2021 transfer to Valtrus.

Assignment timeline

Four recorded assignments. All reel/frame references are taken from the Google Patents legal-events table (which mirrors USPTO Assignment Center data).

• 2005‑07‑19 (executed) / recorded 2006‑03‑02 — Reel 017311/0966

  • Conveyance: Assignment by operation of law
  • Assignor: HP Centre de Compétences France S.A.S.; Bouat, Sebastien
  • Assignee: Hewlett‑Packard Development Company, L.P. (Texas)
  • Correspondent: Not retrievable from available sources — not fabricated.
  • Context: Original vesting — French statutory employer ownership of the invention, simultaneously assigned to the US operating parent. Routine, not a monetization event.

• 2015‑10‑27 (executed) / recorded 2015‑11‑09 — Reel 037079/0001

  • Conveyance: Assignment of assignor's interest
  • Assignor: Hewlett‑Packard Development Company, L.P.
  • Assignee: Hewlett Packard Enterprise Development LP (Texas)
  • Correspondent: Not retrievable.
  • Context: Internal corporate reorg — the November 2015 HP Inc./HPE separation. Cross-reference flag: the identical reel/frame 037079/0001 appears as an exhibit in IPR2025‑00414 (Patent Owner Preliminary Response, Ex. 2032) as the assignment record for a different HP patent, US 6,601,187 (Sicola). A single reel/frame serving two unrelated HP patents is conclusive proof that 037079/0001 is one bulk portfolio recording covering hundreds of HP patents, not a patent-specific instrument. Frame number 0001 = first instrument in the reel.

• 2021‑01‑15 (executed) / recorded 2021‑01‑26 — Reel 055269/0001

  • Conveyance: Patent assignment, security interest, and lien agreement (combined instrument)
  • Assignor: Hewlett Packard Enterprise Development LP and Hewlett Packard Enterprise Company
  • Assignee: OT Patent Escrow, LLC (Illinois)
  • Correspondent: Not retrievable.
  • Context: Securitization / escrow conduit step. This is the opening leg of the HPE portfolio monetization. The dual assignor (both the LP and the parent Company) plus the "security interest and lien" language signals a structured transaction with a financing/escrow intermediary rather than a clean sale. Frame 0001 again indicates a bulk recording across the HPE portfolio. No products, no operating business purpose.

• 2021‑08‑03 (executed) / recorded 2021‑08‑26 — Reel 057650/0537

  • Conveyance: Assignment of assignor's interest
  • Assignor: OT Patent Escrow, LLC
  • Assignee: Valtrus Innovations Limited (Ireland)
  • Correspondent: Not retrievable.
  • Context: Transfer to asserter — the escrow conduit passes a substantial HPE-derived portfolio to the licensing vehicle. Per the N.D. Cal. order in Valtrus Innovations Ltd. v. Google LLC, No. 25‑cv‑07063‑PCP (Mar. 16, 2026), Valtrus is a wholly owned subsidiary of Key Patent Innovations Ltd. and, on the same day it took title from HPE, executed a declaration of trust conveying all exclusionary rights to Key Patent. The court held Valtrus holds bare legal title only and lacked constitutional standing to sue.

No further assignment recorded. The chain terminates at Valtrus (title holder) / Key Patent Innovations (beneficial owner). No defensive-aggregator assignment.

Timeline diagram

timeline
    title Ownership of US 7936738
    2003 : Priority EP application filed
    2004 : PCT and US national stage filed
    2005 : Inventor and HP France assign to HPDC
    2011 : US 7936738 granted
    2015 : HPDC assigns to HPE Development
    2021 : HPE assigns to OT Patent Escrow LLC
         : OT Patent Escrow assigns to Valtrus
    2022 : Valtrus assertion campaign begins
    2024 : US 7936738 asserted against SAP
    2025 : SAP IPR filed then settled
    2026 : Google DJ suits and MDL designated

NPE / troll-pattern signals

1. Shell-entity transfer — PRESENT.
Reel 055269/0001 (executed 2021‑01‑15) moves the patent from operating-company HPE to OT Patent Escrow, LLC, an Illinois escrow/lien conduit, which seven months later (Reel 057650/0537, executed 2021‑08‑03) forwards it to Valtrus Innovations Limited. Concrete supporting evidence beyond naming: (a) Valtrus's recorded address is a Dublin registered office — The Glasshouses GH2, 92 Georges Street Lower, Dun Laoghaire, Dublin A96 VR66 (per the Valtrus v. Google complaint quoted in the record); (b) the N.D. Cal. court found Valtrus has no exclusionary rights, no independent licensing right, and no obligation to sue, holding IP purely in trust for Key Patent; (c) no products in commerce under the Valtrus name. Single-purpose holding vehicle confirmed by judicial finding, not inference.

2. Known asserter in the chain — PRESENT.
Current title holder Valtrus Innovations Limited (and beneficiary Key Patent Innovations Ltd.) does not appear on the classic lists in your prompt (Acacia, Marathon, IV, Wi‑LAN/Mosaid, Vringo, Pendrell, Innovatio, Round Rock, etc.) — I checked and I will not stretch the record to force a match. The finding rests instead on documented, high-frequency assertion conduct: Valtrus/KPI has sued Google, SAP, Red Hat, Lumen, Vertiv, NTT Global Data Centers Americas, Iron Mountain Data Centers, CoreSite, Cologix, H5 Data Centers, Prime Data Centers, Netrality and EvoDC; press coverage explicitly labels them "patent monetization entities"; and in June 2026 the JPML designated an MDL covering the Valtrus data-center campaign. Frequency and MDL designation — not a directory listing — carry this signal.

3. Repeat correspondent across the chain — UNCLEAR.
This is the signal you flagged as most diagnostic, and it is precisely the field I could not retrieve. Reel/frame identifiers are known for all four links (017311/0966 → 037079/0001 → 055269/0001 → 057650/0537), but the correspondent of record is not exposed in Google Patents' legal-events data and did not surface in any search. I am not naming a firm on a guess. Action item: pull the correspondent column for these four reel/frames directly from Assignment Center. A single recurring attorney across 055269/0001 and 057650/0537 (and across the other HPE-derived Valtrus patents) would convert this from unclear to a strong present.

4. Cascading transfers — PRESENT.
Two executions ~6.6 months apart in 2021 (2021‑01‑15 → 2021‑08‑03), recorded one week after each execution (2021‑01‑26, 2021‑08‑26), chaining HPE → OT Patent Escrow, LLC → Valtrus Innovations Ltd. Both are bulk recordings opening at frame 0001 (055269/0001) / a low frame (057650/0537), i.e. portfolio-level conveyances, and both sit inside a four-link chain in which three of the four links occurred within ~6 years while the patent's remaining life shrank toward the 2028 expiry. Classic multi-hop structure with an intermediary inserted between operating company and asserter.

5. Pre-litigation transfer — PRESENT.
The transfer to Valtrus was executed 2021‑08‑03. Valtrus's first assertion campaign — including Valtrus Innovations Ltd. v. Google LLC, N.D. Tex. (filed 10 Jan 2022; 3:22‑cv‑00066 / 4:22‑cv‑00020) — began ~5 months later, squarely inside your 6‑month window. Pre-suit notice letters to SAP followed in March 2022 and September 2022. This specific patent ('738) was asserted somewhat later, against SAP in E.D. Tex. 2:24‑cv‑00021, filed/served January 2024 (motion-to-dismiss order 8 Nov 2024), and the patent record also shows 2:25‑cv‑01859 (W.D. Wash., 2025) and 3:26‑cv‑00363 (N.D. Cal., 2026, captioned Google LLC v. Valtrus Innovations Ltd — a declaratory-judgment posture). The 2021 transfer date, not the 2024 filing, is the relevant pre-positioning datum.

6. Bankruptcy fire-sale — NOT PRESENT.
HPE was never in bankruptcy and never sold this portfolio in a Chapter 7/11 proceeding. The 2021 transaction was a negotiated portfolio sale. Notably, the N.D. Cal. sealing order references "the financial terms and identities of third-parties involved in Valtrus's patent purchase agreement with HPE" — i.e., a priced commercial deal, not a distressed auction. No Kodak/Nortel/Polaroid analogue.

7. Privateering — UNCLEAR.
The chain is HPE → escrow → Valtrus, and HPE is the named assignor on 055269/0001. However, HPE appears to have shed the assets outright rather than retained a back-end economic interest or assertion role: in IPR2025‑00414 the Patent Owner (Valtrus) argued the pre‑AIA §103(c) common-ownership exclusion to disqualify HP-origin prior art, which is litigation against HPE-derived references, not coordination with HPE. No SEC 10‑K/8‑K, Patent Progress or EFF coverage surfaced in this session establishing an HPE-funded assertion campaign. I could not verify privateering either way — unclear, and I will not assert it. Note the interesting counter-signal in the IPR record: SAP filed Exhibit 1130 titled "HPE and SAP Alliance," presumably to rebut any suggestion of coordination.

8. Defensive aggregator — NOT PRESENT.
The chain does not terminate at RPX, AST, LOT, Unified Patents or OIN. It terminates at Valtrus/Key Patent Innovations, which is an asserting entity. Inverse finding: the patent is live and weaponized, not neutralized.

Verdict

NPE — high confidence

Four strong signals are documented on the face of the recorded assignments and the litigation record. (1) Shell-entity transfer: Reel 055269/0001 (executed 2021‑01‑15) moves the patent from HPE into OT Patent Escrow, LLC with a combined "security interest and lien" instrument, and Reel 057650/0537 (executed 2021‑08‑03) forwards it to Irish holding vehicle Valtrus Innovations Limited — a court has since found Valtrus holds only bare legal title with all exclusionary rights in Key Patent Innovations Ltd. (2) Pre-litigation transfer: Valtrus began suing within ~5 months of taking title (Google, N.D. Tex., Jan 2022). (3) Cascading transfers: a two-hop 2021 chain executed 6.6 months apart, both legs recorded as bulk portfolio instruments. (4) Confirmed asserter: a documented multi-front campaign (Google, SAP, Red Hat, Lumen, Vertiv and others) culminating in a June 2026 MDL — while the patent expires 2028‑04‑17.

The original assignee, HPE, is an operating company that shipped the subject matter and never asserted the patent; it is now four links away from the record owner. Note that this IPR — IPR2025‑00419, SAP v. Valtrus, filed 15 Jan 2025 — was terminated as settled on 2025‑07‑01 without a merits ruling, so the '738 claims have never been adjudicated.

One open item drives the only weak spot: Signal 3 (repeat correspondent) is unclear solely because the correspondent field was unavailable in my sources. This matters — in an HPE-portfolio monetization of this scale, a single recording firm typically handles every leg of every patent. Pulling the correspondent for reels 017311/0966, 037079/0001, 055269/0001 and 057650/0537 is the highest-value verification step remaining.

Verify at: USPTO Assignment Center — search patent number 7936738; or assignment.uspto.gov. Cross-check the four reel/frames above, and confirm the correspondent column that I could not populate.

I'll verify the patent and its cited prior art against live sources before building the analysis.

USPTO record verification for US 7,936,738

Before the prior-art analysis, one sourcing note: I could not query USPTO PatentCenter / Patent Public Search directly with the available tooling. The record I verified against is the official USPTO-issued patent PDF (patentimages.storage.googleapis.com/.../US7936738.pdf) plus the Google Patents full-text record at https://patents.google.com/patent/US7936738/en (fetched 2026-09-16), which reproduces the printed front-page citation list. The front-page citation list is reproduced below verbatim in its identifiers — I have not corrected any number, title, or date.

The patent of record. US 7,936,738 B2, "Fault tolerant systems," app. US 10/536,625, inventor Sebastien Bouat, priority 2003-07-25 (EP 03291852.6), filed 2004-07-06 (PCT/EP2004/051371), granted 2011-05-03, examiner Ricky Ngo (per Patents-Review). Claims 1, 11, 17, 27, 33, 34 independent (consistent with the previously-generated summary — no contradiction found there).

1. The complete face-of-patent citation set

The '738 cites 8 patent documents and 2 non-patent publications. This is the universe your question targets.

Cross-reference to the earlier section: those sections did not list the citation set, so there is no conflict. One consistency check that does matter: the earlier section reported the IPR2025-00419 ground as being over "Forissier, US 7,936,763" — a number not in this face-of-patent list. That reference is petitioner-supplied art, not examiner-cited art, and its number still needs independent verification (flagged in §5).

2. Bottom line on § 102 anticipation

No reference on the face of the '738 anticipates any claim under 35 U.S.C. § 102.

The reason is structural, and it is worth stating precisely because it drives the whole analysis. Every independent claim of the '738 requires a round-trip limitation that none of the eight patent references discloses:

• Claim 1 requires adding the obtained context information to the outgoing message "such that a response, received from the destination node, to the outgoing message contains the obtained context information."
• Claim 17 requires the same response-return circuit.
• Claim 33 sharpens it: the response must contain context information "needed to restore a pre-switchover context of the layer."
• Claims 11, 27, 34 require receiving such a message, determining the layer's context is to be restored, detecting the context information within the message, and restoring from it — with claim 11/27/34 all expressly reciting "checking whether the received message is an initial message."

All eight patent references are active/standby state-replication systems: they move protocol/connection state from an active processor to a standby processor over an internal channel (duplex Ethernet, backplane, control link) or replicate it host-to-host. None teaches or suggests embedding the state in the outgoing application/signalling message so that the remote peer's response carries it back. That missing element is the point of novelty, and under § 102 anticipation requires a single reference disclosing every element as arranged in the claim (Net MoneyIN v. VeriSign). It is absent everywhere in the set.

Accordingly, the honest mapping is: these are § 103 obviousness references (and, for the two "third party" cites, background art), not § 102 anticipatory references. Below I give, for each, the closest claim and the specific element that defeats anticipation — that is more useful than forcing a false § 102 mapping.

3. Reference-by-reference

P1 — US 6,320,949 B1, "Method for duplicating calls of remote multiple subscribers"

Full citation: US 6,320,949 B1; [Samsung Electronics Co.](/litigations/by-defendant/Samsung%20Electronics%20Co.), Ltd.; priority 1997-05-19; granted 2001-11-20; examiner-cited.
Description (verified from the USPTO PDF): A remote-subscriber switching system with an active processor and a standby processor. On a call event the active processor transmits the subscriber number and voice-channel number of the "talk state" to the standby processor, which stores them in a working area and connects the corresponding port to the standby time switch; on call release it transmits the release-state numbers and disconnects. Fig. 5 is the duplication flow.
Closest claims: 11, 27, 34 (the "restore context of a layer" concept).
§ 102 assessment: No anticipation. It duplicates call/port state to a standby processor over an intra-system channel. It has no protocol-stack layer context, no outgoing application message carrying context, and no response-return mechanism. It cannot meet claim 11's "determining the presence, within the message, of context information relevant to the layer." Properly used as § 103 art for the proposition that duplicating live call state to a standby was known.

P2 — US 2005/0265346 A1, "Router and routing protocol redundancy"

Full citation: US 2005/0265346 A1; Nokia, Inc.; priority 2000-12-07; published 2005-12-01; examiner-cited.
Description: Router with an active and standby control path; routing-protocol state is maintained/synchronized so the standby can assume routing duties on failure.
Closest claims: 11, 27, 34.
§ 102 assessment: No anticipation. Internal router control-plane synchronization. No message-embedded context, no response echo, no per-layer context obtain/serve loop. § 103 background only.

P3 — US 2003/0046604 A1, "Method and system for implementing MPLS redundancy"

Full citation: US 2003/0046604 A1; inventorship listed as Chun-Hung Lau; filed 2001-05-03; published 2003-03-06; examiner-cited.
Description: Redundancy for MPLS label-switched paths between active/standby nodes.
Closest claims: 11, 27, 34.
§ 102 assessment: No anticipation. Label/path redundancy, not context conveyance via messages. § 103 background only.

P4 — WO 02/093863 A2, "Application transparent redundancy in a protocol stack" (closest to the "layer" language)

Full citation: WO 02/093863 A2; Telefonaktiebolaget LM Ericsson (Publ); priority 2001-05-14; published 2002-11-21; third-party cited. (Inventor reported as Konrad Feyerabend.)
Description (verified): A protocol stack with a first and second protocol layer; a first protocol layer has an executive protocol instance on one communication link and a standby protocol instance on another, the standby kept in standby mode to take over the executive's first-layer tasks.
Closest claims: 11, 27, 34 — and it is the only cited reference that speaks the '738's "layer of a protocol stack" vocabulary directly.
§ 102 assessment: No anticipation. It achieves redundancy by a standby instance inside the stack, not by copying context into an outgoing message and receiving it back in a response. It does not disclose "the presence, within the message, of context information relevant to the layer." Strong § 103 reference for "protocol-layer redundancy," but it cannot supply the response-return limitation.

P5 — US 2003/0005356 A1, "System and method of general purpose data replication between mated processors"

Full citation: US 2003/0005356 A1; named Franckowiak, Edward J.; filed 2001-06-04; published 2003-01-02; examiner-cited. (Same-titled family member US 7,370,099 B2, granted 2008-05-06, lists Hitachi, Ltd.)
Description: General-purpose data replication between mated (active/standby) processors — i.e., a replication engine, not a message protocol.
Closest claims: 11, 27, 34.
§ 102 assessment: No anticipation. Replication between processors is the problem the '738 sets out to avoid (the shared/common-store overhead), not its solution. No message-embedding, no response echo. § 103 background only.

P6 — EP 1 309 142 A1, "Communication system and method" (most substantive HP-family reference)

Full citation: EP 1 309 142 A1; Hewlett-Packard Company; filed 2001-10-30 (EP 01410140); published 2003-05-07; third-party cited. Inventors: Bouat, Sebastien and Wieczorek, Philippe. US counterpart: US 7,085,960 B2 (granted 2006-08-01).
Description (verified from EPO Global Patent Index and Google Patents): A fault-tolerant network element (active/standby gatekeeper) that preserves a connection context at a first (lower) protocol layer of the stack while letting a higher signalling layer tear the connection down on switchover; explicitly, "establishing a connection context comprises storing data relating to at least one of a signalling connection … and the data connection," and a "connection data replication module for replicating the connection context of the second protocol layer to the stand-by host."
Closest claims: 1, 11, 17, 27, 33, 34 — it is the only cited reference that combines (i) a fault-tolerant active/standby node, (ii) protocol-stack layers, (iii) context of a layer, and (iv) restoration of that context after switchover. It is also the only face cite with a common inventor (Bouat) with the '738.
§ 102 assessment: No anticipation of any claim — and only by the narrowest margin, which is exactly the margin the '738 relies on. EP '142 conveys context by a replication module to the standby host (host-to-host), whereas every '738 independent claim requires the context to travel inside the outgoing message and return in the response from the destination node (claims 1, 17, 33) and to be recovered from within the received message (claims 11, 27, 34). EP '142 never places context in an outgoing signalling message destined for a remote application and never gets it back in a response. It is therefore the single best § 103 reference on the set — an examiner could reasonably combine it with a header-carrying-state teaching (see N1) to reach claims 1/17/33 — but it does not anticipate.
Two procedural notes worth flagging: (a) with publication 2003-05-07 and the '738's earliest effective US filing of 2004-07-06, EP '142 is more than one year before the filing date, so it is available as pre-AIA § 102(b) art (subject to any § 119 benefit claim to the 2003-07-25 EP priority — I am not asserting the priority analysis); (b) the US counterpart US 7,085,960 may also be § 102(e) art given its ~2002 filing. I flag these as availability points, not as anticipation.

P7 — US 7,155,632 B2, "Method and system for implementing IS-IS protocol redundancy"

Full citation: US 7,155,632 B2; Nokia, Inc.; inventor Nishit Vasavada; filed 2002-06-27; granted 2006-12-26; examiner-cited.
Description (verified from the patent PDF): Router with an active IS-IS control card and a standby control card linked by a fast channel (e.g., duplex Ethernet). All protocol information (global, configuration, adjacencies, interface, link-state-packet, status) is forwarded to the standby and updated in real time, maintaining a "hot-standby" state so that on failure "all states of the link protocol immediately function as if the failure had not occurred." Notably, the specification states "Neighbor routers will not notice any difference after switch-over, and no additional information is needed from neighbor routers after the switch-over."
Closest claims: 11, 27, 34.
§ 102 assessment: No anticipation — and in fact it teaches away from the '738's mechanism: the whole point of the '632 is that the standby is kept synchronously informed precisely so that no information is needed from the remote peer. Claim 11 requires the opposite — recovering the layer's context from the received message. Best characterized as § 103 art for active/standby protocol-state synchronization.

P8 — US 2004/0088418 A1, "Socket extensions for redundancy"

Full citation: US 2004/0088418 A1; Nokia Corporation; filed 2002-11-01; published 2004-05-06; examiner-cited.
Description: Redundancy achieved through socket-layer extensions — i.e., the redundancy support lives in the socket/transport programming interface, with state maintained for a standby.
Closest claims: 1 (insofar as it touches a layer receiving state to convey), 11/27/34.
§ 102 assessment: No anticipation. Socket-level duplication to a standby, not context inserted into an outgoing application message for return by the peer. § 103 background. (I could not retrieve the full disclosure of D8 in this session; the assessment rests on the title/abstract-level characterization and should be confirmed against the document if it is ever relied on.)

N1 — Chandranmenon, "Trading Packet Headers for Packet Processing" — the most conceptually proximate item on the whole list

Full citation: Chandranmenon, G.P., et al., "Trading Packet Headers fir Packet Processing," IEEE/ACM Transactions on Networking, vol. 4, No. 2, pp. 141–152 (Apr. 1996). (The patent prints "fir"; the correct word is almost certainly "for," but I am reporting the text literally and not correcting it.)
Description: The well-known proposal to carry per-flow state in packet headers, trading header overhead for reduced per-packet processing/classification at intermediate nodes — i.e., placing state information into the message itself while it is in flight.
Closest claims: 1, 17, 33.
§ 102 assessment: No anticipation. Its purpose is processing economy (avoiding repeated classification), not fault tolerance; it does not disclose a node obtaining its own protocol-stack-layer context, nor a response to the outgoing message containing that context, nor restoration of a layer after switchover. But it is the reference on the list that supplies the "put state in the message header" element, so paired with P6 (or P4) it is the natural § 103 combination an examiner or petitioner would reach for. If the earlier-reported IPR2025-00419 ground rests on a single obviousness reference, this NPL is a plausible secondary reference worth checking.

N2 — Singh, "Distributed Fault-Tolerant/High-Availability Systems"

Full citation: Singh, H., "Distributed Fault-Tolerant/High-Availability Systems," online article, Dec. 12, 2001 (Trillium white paper; retrieved via web archive).
Description: Generic white-paper treatment of HA/distributed fault tolerance — the general state of the art the '738's background section describes.
Closest claims: none specifically.
§ 102 assessment: No anticipation. Establishes the general HA context (active/standby, task preservation vs. service continuity) and nothing more.

4. Where the § 102 exposure actually lies (summary table)

If a § 102 attack were nonetheless pressed, the two references that deserve a genuine element-by-element look are EP 1 309 142 A1 (on the strength of its fault-tolerant active/standby node + protocol-layer context language, and the shared inventor) and US 6,320,949 B1 (on the strength of duplicating live call state). Both still fail on the response-return limitation of claims 1/17/33 and on the "context information within the message" limitation of claims 11/27/34. The remaining six patent references and both NPL items are not close enough to anticipate anything.

Dependent-claim note (§ 102 for the narrower claims): Claims 8, 15, 24, 31 (SIP TAG field) and 9, 16, 25 (SIP extension header) and 10/26 (flagging context as potentially inaccurate/incomplete) are narrower, not broader, than their independent claims — so they cannot be anticipated by a reference that fails to anticipate the independent claim. No face-of-patent reference mentions SIP at all. The SIP-specific exposure, if any, would have to come from art outside this citation set.

5. Stated uncertainties and points requiring confirmation

• Source method. As noted, I verified against the official USPTO-issued PDF and the Google Patents record reproducing the printed front page, not a live USPTO PatentCenter / Patent Public Search query. The citation set above matches the printed list; the assignee/litigation data in the earlier section came from third-party aggregators and should be confirmed against PACER/USPTO before reliance.
• P8 (US 2004/0088418 A1). I did not obtain the full text in this session; the § 102 conclusion rests on title/abstract-level characterization. Confirm against the document if it is ever relied on.
• N1 pagination/title. The patent prints "Trading Packet Headers fir Packet Processing." I have reported it literally. I did not independently re-verify the volume/page numbers.
• The IPR ground reference. The earlier section reported IPR2025-00419 as resting on "Forissier, US 7,936,763." That number appears nowhere in the '738's face-of-patent citations, so it is petitioner-supplied art, not part of the answer to your question. It also sits one digit away from the patent-at-issue number; per the operating rule I am not auto-correcting it, and I flag that the identifier and its bibliographic data remain unverified. If the IPR reference is in fact the Ericsson "Application transparent redundancy" family or another document, the § 103 combination analysis in § 3 above would need to be re-run.
• No contradiction found between this citation analysis and the previously-generated sections; the earlier summary's observation of the duplicated SIP-TAG wording in claims 31/32 is consistent with the claim text and is unaffected by anything here.

I'll pull details on the cited prior-art references so the combination analysis is grounded in what each reference actually teaches.

Obviousness Analysis — US 7,936,738 B2 under 35 U.S.C. § 103

Scope note. Per the task, the analysis below draws on the Prior Art section of the Google Patents page (https://patents.google.com/patent/US7936738/en): the eight Patent Citations, the two Non-Patent Citations, plus material the '738 specification itself admits as known. I have supplemented reference content with live lookups (URLs cited inline) but not with references outside that list.

Which items on the page are not usable prior art. The "Families Citing this family" list (DE10344344B4, EP2134057B1, US10277745B1, CN113448795B) and "Cited By" (US9396451B2, June Ray Limited) all post-date the '738 priority/filing and are therefore not § 102/§ 103 art. Note DE10344344B4 (priority 2003‑09‑24) post-dates even the '738 priority date of 2003‑07‑25 and was not published until 2007 — it looks tempting but is unusable.

Flagged contradiction (as instructed). This task states "Current Date: April 26, 2026," while the operating context gives 2026‑09‑17 and the earlier-generated summary references a March 4, 2026 CAFC argument and an Aug. 10, 2026 N.D. Cal. order. Those events cannot both be true relative to an April 26, 2026 "current date." I treat the analysis as atemporal and flag the date inconsistency rather than reconciling it.

1. Framework and level of ordinary skill

Pre‑AIA § 103 (effective filing < March 16, 2013) governs. Graham v. John Deere factors apply, and KSR Int'l v. Teleflex (2007) supplies the "predictable combination / known problem / known technique" rationales that this analysis turns on.

PHOSITA: a person with a bachelor's degree in EE/CS (or equivalent) and ~2–3 years' experience designing or maintaining high-availability, message-based communication systems and layered protocol stacks, including at least familiarity with an IP-telephony signalling stack (H.323 or SIP) and with active/standby failover. This is the level the references themselves presuppose.

The invention's own framing of the problem (admitted art). The '738 specification expressly acknowledges the conventional solution — storing per-task context in a common/shared storage element (FIG. 1, database 118) — and states its aim is to remove the need for that shared store. The '738 also admits as known: (i) the SIP TAG feature of RFC 3261, "must be set in the first outgoing message… and thereafter, the TAG is included in all related messages and response messages"; and (ii) SIP extension headers that carry a field through subsequent responses. Those admissions are themselves prior art and are load-bearing below.

2. Element-by-element mapping of the cited art

3. Combination 1 — the "storing" claims (1–10, 17–26, 33)

EP1309142A1 + Chandranmenon + US20040088418A1 (optionally + WO2002093863A2, US6320949).

Why the combination. All three are in the same art: fault-tolerant/HA message-based communication over layered protocol stacks (the '738 is classified H04L69/40 "recovery from failure of a protocol instance" and H04L69/32 "OSI 7-layer stack architecture"). The combination is a substitution of one known state-preservation mechanism for another known one, with no change in principle of operation — the classic KSR "known technique, known problem" case.

• EP1309142A1 supplies the whole problem and context: a fault-tolerant network element (the '738's own FIG. 1 architecture), a layer-specific connection context that must survive a switchover, and the acknowledgement that each of two protocol layers has its own context. It is the closest art — and it shares the '738's inventor (Bouat) and assignee (HP); the INPI record lists inventors BOUAT, Sebastien and WIECZOREK, Philippe for EP1309142 (https://data.inpi.fr/brevets/EP1309142). A PHOSITA working on this exact problem at HP in 2002–2003 would necessarily start there. Critically, EP1309142's own mechanism is replication to the standby host — i.e., the expensive approach the '738 sets out to eliminate. That framing makes the motivation explicit: the '738's stated aim (avoid a common/duplicated store) is the recognized problem, and KSR holds that a problem recognized in the art supplies the motivation.
• Chandranmenon supplies the mechanism the '738 adopts: rather than store state centrally, trade bandwidth for processing by putting per-layer state into the message. Its teaching that the added information is "compiled from several layer headers" and placed in a separate header maps directly onto claim 1's "obtain context information… for that layer" and claim 2/18's aggregation across layers. Its motivation (bandwidth cheap, processing dear; no round-trip setup required) is a general engineering motivation that applies with equal force to reducing shared-storage dependency.
• US20040088418A1 supplies the "selectively" limitation: redundancy is opt-in, invoked by the application through an API/socket option at the socket layer, with a unique identifier embedded in a message that ties the message to the state. This is the closest thing in the cited set to "selectively indicating to a layer of the protocol stack that [state handling] should be applied for that layer." The examiner-cited citation of this reference confirms it was in the record.
• US6320949 and WO2002093863A2 reinforce: (a) that call-specific state (subscriber number, voice-channel, talk/release state — claim 5/21's "related to the outgoing message") is exactly the kind of state replicated for continuity; and (b) that redundancy can be implemented per protocol layer with an executive/standby instance pair, transparent to the application.

Claim 1's "such that a response… contains the obtained context information." This is the element the examiner did not find, and it is the element a petitioner must bridge. Two routes:

1. Admitted art / SIP TAG. The '738 itself states that the SIP TAG "must be set in the first outgoing message from a node, and thereafter, the TAG is included in all related messages and response messages," that the specification forbids altering it, and that an extension header can be chosen such that "all subsequent response messages include the context field." Combining a known mandatory-echo field with Chandranmenon's known technique of putting per-layer state in header fields is the textbook obvious combination: the field's guaranteed round-trip property is precisely why a PHOSITA would select it. (RFC 3261, June 2002, is not itself listed on the page's Prior Art section — I flag that the petitioner would need to introduce it; it is, however, admitted in the '738 specification.)
2. Stateless-server / message-carried-state practise generally (source-assigned identifiers, flow IDs, self-describing packets per Chandranmenon's Table II) — a PHOSITA knows that state carried by the originator is returned by the responder on the symmetric path.

Claim 33 adds nothing beyond a purpose clause ("context information needed to restore a pre‑switchover context of the layer"), which is supplied directly by EP1309142A1/WO2002093863A2 + Chandranmenon.

4. Combination 2 — the "restoring" claims (11–16, 27–32, 34)

EP1309142A1 (or WO2002093863A2 as the HA-stack base) + US20040088418A1 + Chandranmenon, optionally + US20050265346A1 / US7155632B2.

• Receiving a message and determining whether to restore — EP1309142A1's standby host "implement[s] the communication stack protocol… in response to detection of an event associated with the active host"; WO2002093863A2's standby layer instance "taking over the first protocol layer tasks from the executive protocol instance." Both are determinations of when to restore, at layer granularity.
• Determining presence of relevant context information within the message — US20040088418A1: the message "includes a unique identifier that is associated with the primary socket and the redundant socket," and the system uses it on failover. The '738's claim 13/29 (checking existence at the layer of context associated with the received message) is the direct analogue.
• "Checking whether the received message is an initial message" (the last limitation of independent claims 11, 27 and 34 — which, notably, appears to have been the amendment that distinguished the restoring claims, paralleling the duplicate-claim anomaly in claim 32 flagged in the prior section). This is the most contestable limitation. The obviousness case: within a connection/dialog-oriented signalling protocol, whether a message is dialog-initiating is a necessary, inherent property a PHOSITA must test before attempting restoration — you cannot restore state for a message that creates a dialog. The '738's own FIG. 6 flow presents this as a simple decision step (602) and even the specification treats the alternative (claim 13: no context exists at the layer) as equivalent. Under KSR, "a court must ask whether the improvement is more than the predictable use of prior art elements according to their established functions" — here the check is the predicate to the restoring step, not an independent inventive contribution.

Motivation to combine is the same as Combination 1, plus: US20040088418A1 explicitly pairs a "switchover" definition with the identifier-bearing message, so a PHOSITA using Chandranmenon's header-carried state in an active/standby node would arrive at the receive-side check as the mirror image of the transmit-side step.

5. Fallback Combination 3 (if EP1309142A1 is neutralized)

EP1309142A1 published 2003‑05‑07, less than one year before the '738's 2004‑07‑06 US (PCT national-stage) filing date but more than one year before it when measured against a 2003‑07‑06 critical date — i.e., it is plausibly a § 102(b) statutory bar (pre-AIA practice measures the grace period from the US filing date, and a foreign § 119 priority claim does not avoid a statutory bar; and note that under 35 U.S.C. § 363 the international filing date is the US filing date). If instead it is treated only as § 102(a) art, the applicant could attempt to antedate it under 37 C.F.R. 1.131 (acts in France being cognizable post‑1996 under 35 U.S.C. § 104) — and the "by others" requirement is technically satisfied despite the common inventor because the inventive entities differ (Bouat + Wieczorek vs. Bouat alone). I flag this as an issue both sides must resolve; it materially affects whether the best combination base stays on the table. If EP1309142A1 falls away, the combination is:

WO2002093863A2 (HA protocol stack with per-layer standby instances) + Chandranmenon + US20040088418A1 + US6320949 — which still covers: layered HA stack (WO '863), per-layer state carried in the message (Chandranmenon), opt-in indication via an application-facing interface (US 2004/0088418), and call-state duplication for task preservation (US 6,320,949).

6. Dependent-claim vulnerability

7. Where obviousness is genuinely contestable

1. Claims 10 and 26 (the inaccuracy flag). No reference in the Prior Art section discloses adding an indicator that recovered context is potentially inaccurate. A petitioner would have to rely on (a) KSR's "known technique to address a known problem" — marking estimated/derived data as provisional is routine in telephony billing (estimated/AMA records) and generally in data provenance — and (b) the '738's own admission that restored context "may be slightly out‑of‑date or incomplete" and that a restored billing record could overcharge. Because the specification frames the flag as a mitigation of a known deficiency of the disclosed technique, it is vulnerable to being characterized as an obvious quality‑control measure rather than an inventive contribution. But this is the claim family's best shelter, and it is where I would expect a patent owner to focus.
2. The "response contains the context information" limitation (claims 1/17/33). The examiner had Chandranmenon (per-layer header data) and the Singh HA white paper in front of him and still allowed these claims, which strongly suggests the round-trip echo requirement was the point of novelty. A challenger must affirmatively put RFC 3261 (or an equivalent echo mechanism) into the record; the '738's admission of the TAG behaviour helps but is not a substitute for a reference teaching the combined use.
3. "Selectively" (claims 1, 17). US20040088418A1's socket-option interface is the best fit and is close, but the '738's claim language requires the indication to be directed to a specific layer of the stack that then obtains that layer's context — a petitioner should map the socket-layer message interface precisely.
4. Means-plus-function risk for claims 17/27. "Means for indicating" and "restoration means" invoke pre‑AIA § 112 ¶ 6; the corresponding structure is the API/flag/circuit described in the '738 (application-sent field or flag, per FIG. 5 step 502; and the per-layer extraction/re-init logic of FIG. 6). Infringement and validity of these claims will rise or fall on whether the accused structure is an equivalent.

8. Secondary considerations and posture

• Objective indicia: I found no evidence in the retrieved record of nexus-based secondary considerations (no licensing-due-to-validity evidence; no unexpected-results data). The '738 itself concedes degraded/out-of-date restoration, which cuts against "unexpected results."
• Corroborating posture (from the earlier-generated section, treated as authoritative here): the PTAB petition IPR2025‑00419 (SAP America/SAP SE) reportedly challenged only claims 1–10 and 33 — the storing family — on a single obviousness ground. That is consistent with my analysis: the storing claims present the more conventional (hence more attackable) subject matter, while the restoring claims' initial-message limitation and the inaccuracy-flag claims are the harder targets. The IPR was terminated–settled before institution (July 1, 2025), so no PTAB merits determination exists on any § 103 theory, and this analysis is not a substitute for one.
• I note the earlier section's caution that the IPR summaries are AI-generated and give inconsistent claim lists — that caution carries over here.

9. Stated uncertainties (explicit)

• US20030005356A1, US20030046604A1, US20050265346A1, US7155632B2 and the Singh NPL citation: I did not retrieve full text for these in this pass; my characterizations are at title/abstract/field level and flagged as such. In particular, my statement that the Nokia router/IS‑IS redundancy references teach post‑failover peer re-synchronization is an inference from their titles and field, not from retrieved text, and must be verified against their specifications before being used in a petition.
• My § 102(b)/§ 119 dating conclusion for EP1309142A1 (and the availability of 37 C.F.R. 1.131 antedating if it is only § 102(a) art) is a legal characterization from general pre‑AIA practice, not a chain‑of‑title or priority opinion, and I could not verify the '738's prosecution file history from the sources retrieved.
• I could not confirm from the page's own excerpt how the applicant distinguished the cited art during prosecution, beyond the structure of the allowed claims (which suggests the initial-message clause was added and the claim‑32 duplication is an apparent error).

Bottom line: claims 1–9, 17–25, and 33 are the most exposed to a § 103 attack built on EP1309142A1 (or WO2002093863A2) + Chandranmenon + US20040088418A1, with the SIP TAG/extension-header mechanisms supplied as admitted art; claims 11–16, 27–32 and 34 are moderately exposed but turn on whether the "initial message" check is treated as a predictable predicate (my view: likely yes); claims 10 and 26 are the least exposed because no reference in the Prior Art section teaches the inaccuracy/incompleteness flag.