US 5850449

I'll search for authoritative information on this specific patent number.

Let me check litigation/docket records and the USPTO record specifically.

Let me do a couple more targeted checks for litigation and any 2026 docket activity.

US 5,850,449 — Search Results and Summary

A note on the searches performed (and what I could not confirm)

I searched for the literal identifier 5,850,449 / US5850449A, including queries directed at USPTO records and Federal Circuit 2026 dockets. Result:

• No CAFC 2026 docket, appeal, IPR, or district-court assertion naming U.S. Patent No. 5,850,449 surfaced in my searches. I cannot confirm any litigation involving this patent, and I would be fabricating if I asserted one. This is consistent with the patent being expired since its 20-year term ended (anticipated expiration 2015-10-26).
• Many hits for the string "449" refer to different patents and must not be confused with this one: U.S. 7,373,449 (Network System Technologies v. Qualcomm/Samsung, IPR2024-00338/01081), U.S. 5,787,449 (i4i v. Microsoft), and JP 5850449 B2 (a 2016 Japanese radiation-measurement patent). Per your instruction, I treat the numbers literally and do not attribute any of those proceedings to US 5,850,449.
• One source (Unified Patents portal) also returned a mangled page mixing in an unrelated "Security System for Preventing Unauthorized Communications Between Networks…" item; that text does not belong to this patent.

Bottom line: I found no authoritative evidence of 2026 CAFC activity for this patent.

---

Bibliographic data (from the full patent text)

⚠️ Uncertainty flag (preserve literally): the "Description" section of the record contains the sentence "This application is a continuation of patent application Ser. No. 08/858,785, filed May 19, 1997, which was a continuation of patent application Ser. No. 08/547,721, filed Oct. 26, 1995, now U.S. Pat. No. 5,680,461." This is self-referential and internally inconsistent (08/858,785 is this application). It appears to be an artifact of the continuation/family text carried into the record. The bibliographic tables elsewhere consistently show 08/858,785 filed 1997-05-19 as a continuation of 08/547,721 (1995-10-26). I report this discrepancy rather than silently correcting it.

---

Abstract (verbatim)

"A computer network having first and second network entities. The first network entity includes a packet object generator that generates a packet object including an executable source method, an executable destination method, and data associated with each of the methods. The first network entity also includes a communications interface to transmit the packet object. The second network entity includes a communications interface to receive the packet object and an incoming packet object handler to handle the received packet object. The incoming packet object handler includes a source and destination verifier to execute the source and destination methods with their associated data so as to verify the source and destination of the received object packet."

---

Plain-language overview of the independent claims

The core idea: instead of sending a dumb data packet with a protocol-type ID that a firewall must recognize in advance, you send a "packet object" carrying executable code — methods that the receiving side (and intervening firewall) can actually run to interrogate the message. Independent claims are 1, 9, 14, 17, 20, and 23.

Claim 1 — Apparatus, full two-way network entity (send + receive).
A first network node has three parts: (a) an object generator that builds an object having a source and destination and containing an executable source method, an executable destination method, and data associated with those methods; (b) a communications interface that transmits that object and receives similar objects from other nodes (at least some received objects also carry source/destination methods plus data); and (c) an incoming object handler with a source-and-destination verifier that executes the received object's source and destination methods together with their data so as to verify where the object came from and where it is going.

Claim 9 — Method counterpart of claim 1.
Same idea expressed as steps performed at a first network entity: generate the object (executable source method, executable destination method, associated data) → transmit it → receive an object from another entity that includes source and destination methods and associated data → handle it by executing those methods with their data to verify the received object's source and destination.

Claim 14 — Apparatus, receive-side only.
A network node whose role is only to receive: a communications interface for objects (a subset of which each include source and destination methods and associated data), plus an incoming object handler whose source-and-destination verifier executes those methods with the associated data to verify the received object's source and destination. (No object-generation requirement in this claim.)

Claim 17 — Apparatus, send-side only.
A network node with an object generator producing an object having a source and destination and containing an executable source method, an executable destination method, and associated data — where those methods, when executed by the receiving network entity, verify the object's source and destination — plus a communications interface to transmit the object to that receiving entity.

Claim 20 — "Computer data signal embodied in a carrier wave," receive-side.
A Beauregard-style signal claim: the signal carries (i) instructions for receiving objects transmitted by network entities, where at least a subset of received objects include source and destination methods and associated data, and (ii) an incoming object handler including a source-and-destination verifier that executes those methods with their data to verify source and destination.

Claim 21–22 add, respectively, the digital-signature verification and the executed "main method" features to claim 20's signal.

Claim 23 — "Computer data signal embodied in a carrier wave," send-side.
A signal carrying an object generator that generates an object with a source and destination and containing an executable source method, an executable destination method, and associated data (which methods verify source/destination when run by the receiver), plus instructions for transmitting that object to the receiving entity.

Claim 24–25 add the embedded digital signature and the main-method features to claim 23's signal.

Dependent-claim highlights (context for the independents)

• Claims 2–3: digital-signature scheme — message digests over object contents, encrypted with a private key and verified with a public key; separately a methods signature (covering source/destination methods) and a data signature (covering the data).
• Claim 4: the object is an instance of a class whose header identifies it as a predefined "security" class; a class screener rejects anything not in that class.
• Claims 5, 7: a platform-independent virtual machine module (the specification says preferably a Java™ virtual machine) executes the methods regardless of host platform/OS.
• Claim 6: the object further includes an executable main method + data; a main method executer runs it to implement a desired function after source/destination verification.
• Claim 8: the interface re-transmits the received object onward once its destination is verified (the firewall/relay behavior).
• Claims 10–13, 15–16, 18–19, 21–22, 24–25: parallel dependent features mapped onto the method (9), receive-side (14), send-side (17), and carrier-wave signal (20/23) independents. (Note: claim 16's text says "the generated object further includes…" even though claim 14 is receive-only — an antecedent-basis quirk in the issued text.)

---

Implementation context (from the description)

The described system uses a firewall/sentry computer (105) partitioning a protected side (109) from an unprotected side (111). An unprotected client's packet-object generator (212) builds a packet object (header 706, source method 708, destination method 710, main method 712, method signature 714, object data 716, data signature 718). The firewall screens class → verifies signatures → executes the source/destination methods in its VM to confirm the object's origin and intended destination → re-headers and forwards. The server (or protected client) then screens the subclass and executes the main method to perform the service (e.g., set a default printer, change routing defaults, deliver e-mail), subject to administrator-defined primitives that may restrict functions by sender. Stated goal: add new network services without upgrading firewalls, since the object self-identifies.

---

Confidence and caveats

• High confidence on title, inventor, assignee chain, dates, abstract, claim structure, and technical content — these come from the authoritative full patent text.
• Low/no confidence on any litigation, PTAB, or 2026 CAFC activity involving 5,850,449: my searches returned nothing for this specific number, and the superficially similar hits ('449 patents) are demonstrably different patents. Treat "no 2026 CAFC docket found" as a negative search result, not a positive confirmation of non-existence.
• The expiry in 2015 is a strong structural reason there would be no live 2026 enforcement or appeal, but I state that as inference, not as verified fact.

I'll search for litigation involving US patent 5850449.

Let me search more specifically for litigation records.

Let me check the Unified Patents litigation portal directly for this patent.

Findings: Litigation Involving U.S. Patent No. 5,850,449

No litigation involving U.S. Patent No. 5,850,449 was identified in my searches.

I want to be explicit about the limitations here, since a negative result is only as good as the search behind it:

What I searched

• The Unified Patents litigation portal (portal.unifiedpatents.com), including the patent-specific page for US-5850449-A. That page returned only bibliographic/prior-art data (assignee Oracle America Inc., priority date, ~183 citing references, a cited-by list). It displayed no district court or PTAB litigation entries for this patent.
• General queries combining "5850449" / "5,850,449" with litigation, infringement, lawsuit, Sun Microsystems, and Oracle.

Critical caveat on false positives — do not conflate these

Multiple search hits referenced a "449 patent," but none of them is US 5,850,449. These were different patents with coincidentally similar numbers, and I am flagging them specifically so they are not mistaken for this patent:

Per your instruction not to return results for similar numbers, I am excluding those from the litigation list proper — they are shown above only to document the near-miss matches.

Additional context

• US 5,850,449 ("Secure network protocol system and method," Charles E. McManis) issued 1998-12-15 to Sun Microsystems (now Oracle America), priority 1995-10-26, and is a continuation of US 5,680,461 (the '461 patent, same title/inventor, filed 1995-10-26). If you want a complete picture, the '461 patent should be checked separately, since litigation is sometimes indexed by the parent.
• Legal status per Google Patents: Expired – Lifetime (anticipated expiration 2015-10-26). An expired patent can still have been litigated historically, but this is consistent with a low likelihood of recent assertion activity.

Honest limitation

I was unable to exhaustively query PACER, Docket Navigator, or the full Unified Patents litigation caselist filter (portal.unifiedpatents.com/litigation/caselist?patents=5850449) due to tool-step limits. I did not find any affirmative record of litigation, but I cannot certify that none exists. If you need a definitive clearance-style answer, the reliable next steps would be:

1. Direct query of https://portal.unifiedpatents.com/litigation/caselist?patents=5850449
2. A Docket Navigator / Lex Machina patent-litigation report filtered to 5,850,449
3. PACER full-text docket search

I can run any of those if you'd like me to continue.

Proceedings overview

Zero AIA trial proceedings on file. The structured PTAB proceedings data included in this prompt (sourced from the USPTO Open Data Portal) returns no IPR, PGR, or CBM proceeding naming US5850449 as the challenged patent, and my independent web searches surfaced none either. The count is 0 total — 0 active, 0 claims invalidated, 0 settled, 0 institution-denied. The bottom line for a defendant: no PTAB decision has ever canceled, narrowed, or even tested a single claim of this patent. Every claim (1–25, as issued) stands exactly as the examiner allowed it — and it therefore stands completely un-vetted on validity. The defensive posture is unusual and cuts both ways: there is no PTAB win to point to, but the patent is also expired, which usually moots the whole exercise (see below).

---

No proceedings to itemize

There is no proceeding number to report. I will not manufacture one. For completeness, here is what I affirmatively checked and what I found:

• Source of truth (ODP): "no AIA trial proceedings … as of the most recent ingest."
• Web sweep: Searches for US5850449 / "5,850,449" in combination with IPR/CBM/PGR/PTAB/Petitioner/Patent Owner returned no hit for this patent. Results consistently resolved to unrelated patents that merely share a "449" suffix — e.g., U.S. 9,338,449 (Velos Media / Unified Patents, IPR2019-00194), U.S. 9,818,449 (PGR2021-00096 family), U.S. 7,373,449 (IPR2024-01081 / IPR2024-00338), U.S. 6,226,449 (Samsung v. Apple litigation), and U.S. 6,895,449 (Papst Licensing). None of these is US5850449, and none should be cited as a proceeding against it. Flagging this explicitly because the "-449" string collision is an easy way to cite the wrong docket.
• Family: the direct parent/related case US5680461 ("Secure network protocol system and method," filed 1995-10-26, issued 1997-10-21) is the only sibling US patent in the family. It likewise shows no AIA trial activity in my search. Foreign counterparts exist (EP0776112A3, JPH09270788A, KR100414238B1, CN1143224C, AU717065B2, CA2187970A1, TW323420B) but those are national-phase rights, not PTAB matters.

Confidence statement: I am highly confident the ODP result (zero AIA trials) is correct for the indexed period. I cannot rule out a very recently filed, not-yet-indexed petition; the ODP block itself invites me to flag one if search surfaces it — it did not.

---

Strategic summary

Status of the claims. All 25 claims of US5850449 are, for practical purposes, UNTESTED at the PTAB: no claim is CANCELED (no FWD exists to cancel one) and no claim is SUSTAINED-by-the-Board (no FWD exists to sustain one). The independent claims of record are claim 1 (network-entity apparatus — object generator, comms interface, incoming object handler with a source-and-destination verifier), claim 9 (the method counterpart), claim 14 (a receiving-entity apparatus), claim 17 (a transmitting-entity apparatus), and claims 20 and 23 (computer data signals embodied in a carrier wave). Dependent claims 2–8, 10–13, 15–16, 18–19, and 21–22 layer on the digital-signature/message-digest scheme (claims 2–3, 10–11, 15, 18, 21, 24), the "security"-class screener (claims 4, 12), the virtual-machine execution element (claims 5, 7), the main-method executer (claims 6–7, 13, 16, 19, 22, 25), and re-transmission to a third entity (claim 8).

The expiration point dominates everything else. The patent's term ran from the 1995-10-26 priority date and it expired (anticipated) on 2015-10-26, per the Google Patents legal-status record. That timing is almost certainly why there is no PTAB history: the AIA trial regime began 2012-09-16, giving challengers roughly a three-year window, and the patent (issued 1998, by then a Java-era Sun artifact assigned to Oracle America) appears never to have been asserted in a way that attracted a petition. For a defendant today, the expiration is the first and often dispositive fact — you cannot infringe an expired claim for post-2015-10-26 conduct, so a demand letter citing this patent is, on its face, either time-barred as to damages or aimed at conduct that predates expiration. Verify the exact expiration/terminal-disclaimer math and any pre-expiration conduct window before relying on it, but the six-year § 286 damages lookback (roughly 2019-forward as of 2026) runs entirely after the patent's expiration date.

Estoppel landscape. Because no IPR/PGR/CBM ever reached a final written decision, § 315(e)(2) / § 325(e)(2) estoppel never attached to anyone with respect to this patent. There is no petitioner, no RPI, and no privy who is barred from raising any § 102/§ 103 ground in district court. If you are challenged on this patent, the entire prior-art universe — including patents and printed publications, and all the non-patent invalidity theories that IPR cannot reach, such as § 112 enablement/written-description and public-use/on-sale § 102(a)(1) art — remains available. There is also no PTAB claim-construction record to be pinned by, and no prosecution-disclaimer or IPR-disclaimer estoppel generated by PTAB argument. The flip side: there is no FWD finding of invalidity to hand the court, so any defense must be built from scratch in the district court record.

Pattern signals. None exist: no serial petitioner, no repeat filings, no defensive aggregator (no sign of Unified Patents or RPX involvement — those hits were all other "449" patents), and no PTAB appeals because there were no PTAB decisions to appeal. This is a "quiet" patent in PTAB terms.

---

Recommended next steps

1. Tell the client plainly: no PTAB activity exists on US5850449. The absence is a signal, but here it is explained by expiration rather than by invulnerability — well-asserted live patents eventually attract IPRs; this one expired before it did.
2. Screen the assertion for a live theory. Because the patent expired 2015-10-26, map any accused conduct to dates before that date, then apply the 35 U.S.C. § 286 six-year damages limit. If the demand letter targets post-2015 conduct, the response is that the claim is expired and cannot be infringed for that activity.
3. If pre-expiration conduct is genuinely at issue, avoid spending PTAB money (an IPR on an expired patent is generally moot — the Board has no reason to cancel claims that can no longer be asserted). Instead build invalidity directly in court: (a) § 102/§ 103 on the cited references from the 1995–1998 era (note the file's own cited art — e.g., U.S. 5,416,842, U.S. 5,550,984, U.S. 5,602,918, U.S. 5,360,757 — plus contemporaneous Java/ORB/"active messaging" literature such as WO 1992/022033, "Active messaging system," which is cited on the face of this patent); (b) § 112 written-description/enablement against the broad "executable method in a packet object" claims; and (c) any § 101 eligibility argument on the carrier-wave/data-signal claims 20–25, which are the most vulnerable formal claims.
4. Documentation links for the file: the authoritative full text (claims, specification, family, and cited references) is at the Google Patents record: https://patents.google.com/patent/US5850449/en. For PTAB-side negative confirmation, a name/number search of the PTAB's public PACTS/E2E system (https://ptacts.uspto.gov) for "5,850,449" returns no AIA trial; there is likewise no Federal Circuit docket to check because there is no Board decision to appeal. If you nonetheless want belt-and-suspenders confirmation of the negative, I can re-run the ODP/PACTS query closer to your filing date in case a petition has since been lodged — but as of 2026-10-01, the record is clean.

Caveat per operating rules: I am reporting the absence of proceedings rather than inventing any. If a proceeding surfaces that the ODP ingest does not yet reflect, it should override this analysis for that proceeding only.

I'll start by verifying the assignment records against the live USPTO data and cross-referencing the ownership chain.

I found the Oracle merger reel/frame via a parallel Sun patent. Let me verify whether it applies to this patent directly and check for the original 1997 Sun recording.

Ownership & Assignment Analysis — US 5,850,449

Patent: US 5,850,449 A — "Secure network protocol system and method"
Application: 08/858,785 (continuation of 08/547,721) · filed 1997-05-19 · issued 1998-12-15
Priority: 1995-10-26 · Term end (anticipated): 2015-10-26 · Status: Expired – Lifetime
Source of record: https://patents.google.com/patent/US5850449/en

Data-access caveat up front. My live queries against the Assignment Center index for this patent number returned no assignment records, and the USPTO Assignment Center UI is not curl-accessible. Accordingly, the entries below are reconstructed from (a) the Google Patents legal-events table embedded in the authoritative patent text, and (b) an Espacenet INPADOC cross-reference on a sibling Sun patent (US 7,409,710) that shares the identical Oracle merger recording. The reel/frame and correspondent fields for the 1997 Sun recording could not be retrieved and are reported as unknown rather than inferred. This should be confirmed with a direct patent-number lookup at https://assignmentcenter.uspto.gov/ and https://assignment.uspto.gov/patent/index.html.

Inventors

• Unusual-pattern check: not present. With a single inventor there is no "mass inventor departure" signature. No evidence in the retrieved record of the inventor leaving Sun near filing, and no inventor-side assignment beyond the original employer assignment.
• The Google Patents legal event of 1997-05-19 records "ASSIGNED TO SUN MICROSYSTEMS, INC. — ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS); Assignors: MCMANIS, CHARLES E." The signing date and reel/frame are not exposed in the sources retrieved.

Original assignee

Sun Microsystems, Inc. (Delaware corporation; principal place of business, Palo Alto / Mountain View / Santa Clara, California).

• Primary line of business: enterprise computing — SPARC workstations and servers, Solaris, and the Java platform. This patent is squarely within Sun's Java push: the specification expressly states the virtual machine is "preferably a 'Java' (a trademark of Sun Microsystems, Inc.) virtual machine module," and the claims recite transmitting objects containing executable methods rather than conventional protocol-identified data packets.
• Product embodiment: Sun did commercialize Java (JDK/Microsystems, JavaOS) in the 1995–1997 window, but the record does not tie any specific shipped Sun SKU to practice of the US 5,850,449 claims. Treat "shipped product embodying the claims" as unclear, not established.
• Current status: Acquired, not dissolved, not bankrupt. Oracle Corporation acquired Sun (announced 2009-04-20; closed 2010-01-27). On 2010-02-12/2010-02-15, Oracle USA, Inc. merged into Sun Microsystems, Inc.; the surviving corporation was renamed Oracle America, Inc. (Oracle Corp. holds 100%). Oracle America remains an operating subsidiary.
• Family context: parent US 5,680,461 (appl. 08/547,721, issued 1997-10-21) — same title, same inventor, same Sun→Oracle chain. Foreign siblings: EP0776112A3 (withdrawn), CA2187970A1 (abandoned), AU717065B2 (ceased), JPH09270788A, KR100414238B1, CN1143224C, TW323420B.
• Text anomaly (flagged, not corrected): the fetched description states "This application is a continuation of patent application Ser. No. 08/858,785…" — i.e., it names its own application number as parent. Per the patent's own "Related Parent Applications" table, 08/858,785 is a continuation of 08/547,721. The description text appears to be a transcription defect; I am reporting it literally.

Assignment timeline

1. 1995-10-26 (executed, by priority/filing date) / recorded 1997-05-19 — Reel/Frame NOT RETRIEVED

• Conveyance: Assignment of assignors' interest (inventor → employer)
• Assignor: Charles E. McManis
• Assignee: Sun Microsystems, Inc.
• Correspondent: Unknown — not exposed in any source retrieved. The Assignment Center record was not returned by my searches. No recurrence can be asserted.
• Context: Founding employment/priority assignment to the original operating-company assignee.

2. 2010-02-12 / recorded 2015-12-11 (Google Patents) — Reel 037303 / Frame 0336 (inferred from sibling Sun patent)

• Conveyance: Merger and Change of Name (no new consideration; no transfer of beneficial ownership)
• Assignor: Oracle USA, Inc.; Sun Microsystems, Inc.
• Assignee: Oracle America, Inc.
• Correspondent: Unknown — not exposed in Google Patents, Espacenet INPADOC, or the retrieved PTAB/court filings for the merger recording.
• Context: Internal reorganization — the Sun→Oracle rename; recorded roughly 5.9 years after the merger actually closed (a classic late clerical cleanup of a large inherited portfolio).
• Confirmation basis & discrepancy: The reel/frame string REEL/FRAME:037303/0336, with EFFECTIVE DATE: 20100212 and assignors ORACLE USA, INC.; SUN MICROSYSTEMS, INC.; ORACLE AMERICA, INC., appears verbatim on the Espacenet INPADOC record for US 7,409,710 (a different Sun patent): https://worldwide.espacenet.com/publicationDetails/inpadoc?CC=US&NR=[7409710B1](/patent/7409710B1). Google Patents lists the same event on the '449 patent as dated 2015-12-11; INPADOC shows 2015-12-16 for the sibling. The dates disagree by five days — I am reporting both literally and not auto-correcting.
• No-record confirmation: No other assignment, security interest, license, release, or termination is recorded against this patent in any source retrieved.

3. 2015-10-26 — Anticipated expiration (not an assignment; recorded as a legal-status event). Patent is expired as of today.

If the Assignment Center — on a direct lookup — returns no transactional records beyond the founding Sun assignment and this merger/name-change entry, that is itself the finding: no third-party or licensing entity ever took title.

Timeline diagram

timeline
    title Ownership of US 5850449
    1995 : McManis files parent application
         : Assigns rights to Sun Microsystems
    1997 : Continuation 08-858-785 filed
    1998 : US 5850449 issues
    2010 : Oracle acquires Sun Microsystems
         : Sun renamed Oracle America Inc
    2015 : Merger recorded Reel 037303 Frame 0336
         : Patent term ends 26 October 2015

NPE / troll-pattern signals

Verdict

Insufficient data — but with a substantive negative finding against NPE characterization.

From the enumerated set, this is the only defensible pick: the record consists of the founding assignment to Sun (recorded 1997-05-19, reel/frame not retrieved) plus a merger-and-change-of-name entry to Oracle America, Inc. (Reel 037303/0336, effective 2010-02-12, recorded 2015-12-11 per Google Patents / 2015-12-16 per Espacenet INPADOC on sibling US 7,409,710) — a name-change record conveys no new beneficial ownership, so in substance there is still exactly one transactional assignment. No shell entity, no listed asserter, no cascading transfers (one change in 18 years), no bankruptcy, no privateering, and no defensive aggregator. The patent expired 2015-10-26, eliminating any live assertion value. I decline to characterize as NPE/low-confidence-NPE on this record, and I flag that the missing reel/frame and correspondent fields for the 1997 assignment should be confirmed by direct lookup.

Verify at: https://assignmentcenter.uspto.gov/ (search patent number 5850449) · https://assignment.uspto.gov/patent/index.html · Google Patents legal events: https://patents.google.com/patent/US5850449/en

I'll research this systematically. Let me start by verifying the patent record and then examining each cited reference.

Let me gather details on the most relevant cited references.

Prior-Art Analysis — U.S. Patent No. 5,850,449

Note on scope: I was able to retrieve the full authoritative patent document (Google Patents, fetched 2026-09-24) plus independent search results for several cited references. I did not independently retrieve the full text of every reference (e.g., the three Taligent patents and US4724521); where I rely only on the title/abstract as reproduced in the patent record, I flag that explicitly. Per your instruction, all identifiers are reproduced literally and I have not "corrected" anything.

---

1. The Patent Under Review

Records inconsistency worth flagging: The published specification states: "This application is a continuation of patent application Ser. No. 08/858,785, filed May 19, 1997, which was a continuation of patent application Ser. No. 08/547,721, filed Oct. 26, 1995, now U.S. Pat. No. 5,680,461." Taken literally, the patent says it is a continuation of its own application number (08/858,785). The bibliographic metadata instead shows the correct chain as 08/547,721 → 08/858,785. I am reporting the inconsistency rather than silently correcting it.

The independent claims to be measured against art: claims 1 (network entity: object generator + comms interface + incoming object handler with source/destination verifier), 9 (method counterpart), 14 (receive-side entity only), 17 (transmit-side entity only), 20 (Beauregard-style "computer data signal embodied in a carrier wave," receive side), and 23 (same, transmit side). Dependent claims add: signatures/message digests (2, 3, 10, 11, 15, 18, 21, 24), object-header "security" class + class screener (4, 12), virtual-machine execution (5, 7), main-method execution (6, 13, 16, 19, 22, 25), and re-transmission (8).

---

2. Methodological Caveat on § 102

Because the effective priority date is 1995-10-26, only references meeting one of the § 102 categories qualify:

• § 102(a)/(b): printed publication/patent before 1995-10-26 (with § 102(b) requiring >1 year, i.e., before 1994-10-26).
• § 102(e): a U.S. patent granted on an application filed before the applicant's invention date (here, at latest the 1995-10-26 priority). A reference published after 1995-10-26 but filed before it can still be § 102(e) art.

This matters for two of the citations below (US5544297 and US5550984, both filed pre-1995 but published later → available only under § 102(e)), and it disqualifies US5602918 as § 102 art on its face (filed 1995-12-22, after the priority date).

---

3. The Nine "Patent Citations" of Record (references cited during prosecution)

(A) US 4,724,521 A — Method for operating a local terminal to execute a downloaded application program

• Assignee/date: Veri-Fone, Inc. — filed 1986-01-14; issued 1988-02-09.
• Description: A terminal receives an application program over a network and executes it locally (download-and-execute model).
• § 102 status: Qualifies under § 102(b) (issued more than one year before 1995-10-26).
• Potentially relevant claims: Only the "execution of a received program at the receiving entity" concept — i.e., the main-method-execution limitations of claims 6, 13, 16, 19, 22, 25. It does not disclose executable source/destination methods used for self-verification, so it cannot anticipate independent claims 1, 9, 14, 17, 20, 23.
• Confidence: Description based on the title/record only (full text not independently retrieved).

(B) US 5,367,573 A — Signature data object

• Assignee/date: Digital Equipment Corporation — filed 1993-07-02; issued 1994-11-22.
• Description (verified): A machine-readable structured data record (the "signature data object"/SDO) attached to a "parent object," comprising a signature header, signature data, and a signature proof block; may include a role identifier and semantic tags ("submitted by," "approved," etc.). It is an application-level construct layered over underlying OS/network security and is expressly technology-independent.
• § 102 status: Qualifies under § 102(a) (issued before, but within 1 year of, the priority date); could also be applied under § 102(e).
• Potentially relevant claims: The digital-signature-on-an-object concept maps onto the signature limitations of claims 2, 3, 10, 11, 15, 18, 21, 24. However, an SDO is a passive data record, not executable code, and it does not involve executing methods to verify source/destination. It therefore does not anticipate the independent claims.
• Confidence: High (abstract and description retrieved).

(C) US 5,388,264 A — Object oriented framework system for routing, editing, and synchronizing MIDI multimedia information using graphically represented connection object

• Assignee/date: Taligent, Inc. — filed 1993-09-13; issued 1995-02-07.
• Description: Object-oriented framework for manipulating MIDI/multimedia data via connected objects.
• § 102 status: § 102(a) (issued 1995-02-07, before 1995-10-26).
• Potentially relevant claims: Evidence that object-oriented encapsulation with class/object structures was known — i.e., background for the "object header / class" concepts in claims 4 and 12. No anticipation of the executable-method packet-object concept.
• Confidence: Description from title/record only.

(D) US 5,390,138 A — Object-oriented audio system

• Assignee/date: Taligent, Inc. — filed 1993-09-13; issued 1995-02-14.
• Description: Object-oriented audio processing architecture.
• § 102 status: § 102(a).
• Potentially relevant claims: Same role as (C) — general object-oriented background (claims 4, 12). Not anticipatory of the independent claims.
• Confidence: Description from title/record only.

(E) US 5,544,297 A — Object-oriented audio record/playback system

• Assignee/date: Taligent, Inc. — filed 1993-09-13; issued 1996-08-06.
• Description: Object-oriented audio record/playback.
• § 102 status: Issued after the priority date, so not § 102(a)/(b). Available only under § 102(e) based on its 1993-09-13 filing date.
• Potentially relevant claims: Same object-oriented background role (claims 4, 12). Not anticipatory.
• Confidence: Description from title/record only.

(F) US 5,416,842 A — Method and apparatus for key-management scheme for use with internet protocols at site firewalls

• Inventor/assignee: Aziz; Sun Microsystems, Inc. — filed 1994-06-10; issued 1995-05-16.
• Description (verified): Uses the SKIP scheme to encrypt inter-site traffic at the IP layer between firewalls; a firewall encrypts an outbound IP packet and tunnels it to a remote firewall, which decrypts and forwards it inside the protected network. Uses Diffie-Hellman certificates and transient keys (K_ab, K_p). Encryption is firewall-to-firewall; interior traffic is cleartext.
• § 102 status: § 102(a) (issued 1995-05-16, before 1995-10-26).
• Potentially relevant claims: The firewall/sentry network-entity and key-management/encryption aspects — most relevant to claims 1, 5, 7, 8 (network entities and re-transmission) and, more broadly, to the encryption of message digests backdrop of claims 2, 10, 18, 21, 24. Critically, Aziz operates at the IP/packet layer with no executable object carried in the payload; it does not disclose executing source/destination methods. It therefore does not anticipate claims 1, 9, 14, 17, 20, 23.
• Confidence: High (description retrieved). Note: same-assignee art (common ownership) to the patent owner.

(G) US 5,550,984 A — Security system for preventing unauthorized communications between networks by translating communications received in IP protocol to non-IP protocol to remove address and routing services information

• Assignee/date: Matsushita Electric Corporation of America — filed 1994-12-07; issued 1996-08-27.
• Description: A boundary security system that prevents unauthorized inter-network communication by translating IP traffic into a non-IP protocol so that address/routing information is stripped, thereby hiding internal topology.
• § 102 status: Issued after the priority date → available only under § 102(e), based on the 1994-12-07 filing date.
• Potentially relevant claims: The boundary firewall / network-security gateway architecture maps most closely to the firewall-entity concepts in claims 1, 4 (class screening), 9, 12, and to the general background of claim 1. It does not disclose packet objects containing executable methods; it translates protocols. Thus no anticipation of the independent claims.
• Confidence: Description from title/record and secondary search hits; full text not independently retrieved.

(H) US 5,680,461 A — Secure network protocol system and method

• Inventor/assignee: McManis; Sun Microsystems — filed 1995-10-26; issued 1997-10-21.
• Description: This is the parent of US 5,850,449 — the same invention by the same inventor, sharing the identical 1995-10-26 priority date.
• § 102 status: Not prior art to US 5,850,449. Because the two applications share the same disclosure, inventor, and effective filing date, US 5,680,461 cannot be a § 102(a), (b), (e), or (g) reference against its own continuation (same inventive entity and constructive reduction to practice). It appears in the citation list as a related/priority document, not as anticipating art.
• Potentially relevant claims: None (disqualified as prior art).
• Confidence: High.

(I) US 5,602,918 A — Application level security system and method

• Assignee/date: Virtual Open Network Environment Corp. (Chen et al.) — filed 1995-12-22; issued 1997-02-11.
• Description (verified): Uses smartcard technology for authenticating documents over the Internet; establishes a communications channel with mutual authentication and a session key, with a gateway/firewall (gateway processor) cooperating with the client to develop a session key without key exchange over the network.
• § 102 status: Its filing date (1995-12-22) is after the patent's 1995-10-26 priority, so it is not § 102(a)/(b) art, and it can only be § 102(e) art if the applicant's actual date of invention postdates 1995-12-22 (unlikely given the 1995 parent filing). On its face it is not § 102 prior art. It was almost certainly cited for general background on application-level network security.
• Potentially relevant claims: If it were available, its application-level authentication and firewall/gateway themes would touch claims 2, 10, 18 (authentication) and claim 1 (firewall entity) — but it uses smartcards and session keys, not executable packet-object methods, so again no anticipation.
• Confidence: High on the text; the § 102 date conclusion is a legal characterization based on the recorded dates.

---

4. Additional References "Cited by Family" (8)

These were cited in the prosecution of related family members (not necessarily against US 5,850,449 itself), but are worth listing for completeness:

---

5. Overall § 102 Assessment — Most Relevant Prior Art

No single cited reference anticipates any independent claim (1, 9, 14, 17, 20, or 23). The core inventive concept — a packet object that itself contains executable source, destination, and main methods that the receiving/firewall entity executes against accompanying data to self-verify the object's source and destination (claims 1, 9; and its sub-combinations in 14, 17, 20, 23) — is not disclosed by any of the nine citations. This is consistent with the patent having issued over all of them.

Most relevant references, ranked by closeness to the claimed subject matter:

1. US 5,550,984 (Matsushita) — closest to the boundary firewall screening architecture of claim 1 / the "class screener" concept (claims 4, 12). Available only under § 102(e).
2. US 5,416,842 (Aziz / Sun) — closest to the firewall encryption and key-management backdrop relevant to claims 2, 3, 5, 7, 8; § 102(a). Same assignee.
3. US 5,367,573 (DEC "Signature data object") — closest to the digital-signature/message-digest-on-an-object limitations of claims 2, 3, 10, 11, 15, 18, 21, 24; § 102(a). But it is a passive data record, not executable code.
4. US 4,724,521 (Veri-Fone) — closest to the execute-a-received-program limitations of claims 6, 13, 16, 19, 22, 25; § 102(b).
5. US 5,602,918 (V-ONE / Virtual Open Network) — application-level security/firewall background, but likely unavailable as § 102 art because it was filed after the 1995-10-26 priority.
6. Taligent patents (US 5,388,264 / 5,390,138 / 5,544,297) — object-oriented background only (claims 4, 12).
7. US 5,680,461 — the patent's own parent; not prior art.

Bottom line: The examiner's citations collectively establish that signatures attached to objects, firewall-based encryption, firewalls at network boundaries, download-and-execute of programs, and object-oriented systems were all known. They support § 103 obviousness-type arguments against individual dependent limitations, but under § 102 they are, at most, anticipating only isolated dependent features — not any independent claim.

---

6. Explicit Limitations of This Analysis

• I could not independently retrieve full texts for US 4,724,521, US 5,388,264, US 5,390,138, US 5,544,297, US 5,550,984, so for those I rely on titles/abstracts as they appear in the patent record and secondary sources. Claim-mapping for those should be re-verified against full text before being relied upon.
• The § 102 date categorizations (a)/(b)/(e) are my characterizations based on the recorded filing and issue dates; the applicant's actual invention date is presumed to be no later than the 1995-10-26 priority, which is what drives the § 102(e) conclusions.
• The distinction between a potential § 102 reference (anticipation of a claim as a whole) and a reference useful only for § 103 obviousness is critical here: none of these references anticipates the independent claims standing alone.
• The citation list includes one clearly unrelated chemistry patent (US 5,332,708, catalyst compositions), which suggests either a citation artifact in the family or an IDS/co-filing over-inclusion; I have not "corrected" it, per your instruction.

I'll ground the obviousness analysis by pulling details on the key prior-art references listed in the patent's Citations and Family Citations sections.

Obviousness Analysis — U.S. Patent No. 5,850,449 under 35 U.S.C. § 103

Analyst work product. Grounded in the prior-art record of the patent page provided (Citations (9) and Family Cites Families (8)), supplemented by searches noted in §7. Final date of analysis: April 26, 2026. Builds on the previously generated litigation section without repeating it.

---

0. Corrections and record caveats that affect this analysis

Before reaching obviousness, three record issues must be flagged, because they bear directly on which references are available and what the claims cover. Per my operating rules I am reporting these as contradictions rather than silently correcting identifiers.

0.1 The priority chain on the page is self-referential and internally inconsistent.
The Description states: "This application is a continuation of patent application Ser. No. 08/858,785, filed May 19, 1997, which was a continuation of patent application Ser. No. 08/547,721, filed Oct. 26, 1995, now U.S. Pat. No. 5,680,461." But 08/858,785 is the application number printed on the front of this page for US 5,850,449. An application cannot be a continuation of itself; the "Related Parent Applications" and "Family Applications Before" tables correctly list the chain as 08/858,785 ← 08/547,721 (US 5,680,461). I treat the bibliographic tables, not the Description sentence, as controlling for the effective filing date of October 26, 1995. This matters because it sets the § 102(b) critical date at October 26, 1994 and the § 102(e)/§ 102(a) cutoffs.

0.2 US 5,680,461 and US 5,602,918 appear in the Citations/Family tables but are not, on the face of the record, available as prior art.

• US 5,680,461 is the parent of the '449 patent — same inventor (McManis), same title, same priority date. It is not "by another," so it is not § 102(a)/(e)/(g) art against the '449 claims. It may be cited only as a co-pending-family evidentiary document. Any rejection built on the '461 patent is improper.
• US 5,602,918 (Virtual Open Network Environment, "Application level security system and method") was filed December 22, 1995 — after the October 26, 1995 effective filing date (per the page's own table: priority 1995-12-22, publication 1997-02-11). Its § 102(e) date postdates the invention date; it is not available as prior art for the '449 patent. It is usable only as background to show the state of the art as of 1997+, which is irrelevant to a 1995 priority. Do not use '918 in a § 103 combination.

0.3 Several other citations have date problems and must be checked before use (detail in §3.4). The most important: AU 683038 B2 (Fischer) published 1997-10-30, which is after the critical date, so the Australian document itself is not prior art — but a search result indicates an earlier-published European counterpart, EP 0 570 123 A1 (Fischer), cited against Java-related subject matter elsewhere. If the EP publication predates October 26, 1994, it is § 102(b) art and substantially strengthens Ground A below. I could not confirm its publication date in this session and flag it as unverified.

0.4 Claim-drafting defects relevant to scope (not § 103, but they affect how broadly each ground reads). I note these because they change the claim-construction posture:

• Claim 9 recites receiving "an object," then immediately refers to "the received data packet" — the antecedent is missing. Read literally, claim 9 covers a data packet including source/destination methods, which broadens it relative to claim 1.
• Claim 16 recites "the generated object further includes an executable main method," but parent claim 14 recites no object generation at all. Same defect in claim 22 ("the generated object" with no antecedent in claim 20).
• The specification's reference numerals are internally broken: "object data 714" is used where 716 is meant (716 is the object data element in FIG. 7); "library 146" and "memory 134" are cited but never introduced; and the firewall is called "firewall computer 103" at one point although 103 is a protected-side client computer. These are § 112(b) exposure points on terms like "the data associated with the source and destination methods."

---

1. Legal framework applied

• Governing law: pre-AIA § 103(a) (priority 1995-10-26). Graham v. John Deere Co., 383 U.S. 1 (1966) factors; KSR Int'l Co. v. Teleflex Inc., 551 U.S. 398 (2007) for the legal standard on motivation and predictability (applies as a matter of law to all § 103 analyses); In re Keller / In re Merck for the proposition that a combination is judged on the combined teachings, not reference-by-reference.
• Level of ordinary skill: a person with a bachelor's degree in CS/EE and 2–4 years of experience in network systems or operating-systems security, familiar with TCP/IP, firewalls, public-key cryptography and object-oriented programming. In 1995 that person routinely worked with delegation/proxy designs, hash-and-sign digital signatures (RSA/DSA), and platform-independent byte-code interpreters (UCSD p-System p-code, Smalltalk, and — by the 1995-96 timeframe — Java/bytecode).
• What the claims actually require. This is critical: independent claims 1, 9, 14 and 17 do not require digital signatures, a "security" class, a virtual machine, or a main method. Claim 1 requires only: (a) an object generator making an object containing an executable source method, an executable destination method, and data associated with them; (b) a transmit/receive interface; and (c) an incoming object handler that executes the source and destination methods to verify source and destination. Every one of those three elements is separately known.

---

2. Element decomposition of the claims

The practical consequence: only claims 2–5 and 7 are directed to anything beyond "a program carried in a network message that the recipient executes."

---

3. Prior-art inventory (from this page's Citations and Family Citations)

3.1 Confirmed-available art (with qualifying date and anchor)

3.2 Art available for background only (post-date)

• US 5,602,918 (VONE) — § 102 excluded (§0.2). Its value as evidence of the 1997 state of the art is nil for this patent.
• US 5,680,461 — same family (§0.2).
• US 5,606,617 (Brands, "Secret-key certificates"), published 1997-02-25; US 5,598,476 (random-clock cryptographic authentication), published 1997-01-28. Unless their underlying applications were filed before 1995-10-26, they are not available. Filing dates unverified.
• AU 683038 B2 (Fischer) — published 1997-10-30, after the critical date; not prior art. But see §0.3 re: EP 0 570 123 A1 (Fischer), which if published before 1994-10-26 is strong § 102(b) art on executable, authenticated program distribution.

3.3 What the '449 specification itself concedes (admissions usable in a § 103 case)

The Background states: "some new protocols, such as HTTP, are being used to implement very generic execution environments. As a result, the ability to secure a network from such protocols is becoming increasingly impossible," and that prior-art protected networks "use a filter on these data packet type identifiers." And Gelb '984 states the identical problem in the identical field ("code must be specially written to specify each application to be allowed through the subnetwork, making changes in application availability costly and time-consuming"). Two references in the same field, each recognizing the same problem the '449 patent purports to solve, is the classic KSR motivation.

3.4 Date/verification table (what I could and could not confirm)

---

4. Obviousness grounds

Ground A — Claims 1, 9, 14, 17 (and method claim 13's preamble): Gelb '984 + Veri-Fone '521 + Bellcore WO 92/22033 (+ Taligent '264/'138)

Rationale: These claims require nothing more than a message that carries executable code and a receiver (including an intermediary) that runs that code to figure out the message's source and destination.

• Veri-Fone '521 provides the core "download and execute a program received over a network" teaching (element: executable code delivered by the network). US 4,724,521 is squarely § 102(b) art.
• Bellcore WO 92/22033 "Active messaging system" — to the extent it discloses messages carrying receiver-executed code, it supplies the message-as-program element directly, and supplies the motivation to put program logic in the message rather than in the recipient's pre-written table of message types. (Conditional on §3.4.)
• Taligent '264/'138/'297 supply the object-oriented packaging the claims recite: an "object" that is an "instance of an associated object class" with an object header ("object header 706 specifies the class and subclass," per the spec), and the routine OO practice of methods carried with an object.
• Gelb '984 supplies every network-facing element: the boundary intermediary with a communications interface that receives messages, inspects them, and, if acceptable, attaches a new header and re-transmits to the destination (this is literally the '449's steps 612-624). Gelb's firewall already runs code to decide what to do with a message (its API-shim/DLL layer "passes executable code" between its two motherboards).

Motivation to combine (KSR-compliant, articulated):

1. Same field, same problem, same solution shape. Both '449 and '984 identify the root defect as a firewall that must pre-know the structure/protocol of each message it must let through. '984 states it in the Background; the '449 specification states it in the Background. A POSITA reading '984's statement that per-application firewall coding is "costly and time-consuming" would directly seek a mechanism by which the message itself tells the firewall what it is — which is precisely '449 claim 1.
2. Predictable, one-part substitution. Moving message-type logic from the firewall's static filter table into code carried by the message is a substitution of one known component (pre-written per-protocol proxy code) for another known component (sender-supplied code), with no change in the principal of operation — the firewall still functions as a screening intermediary. KSR: "a patent composed of several elements is not proved obvious merely by demonstrating that each of its elements was independently known," but here the elements also function together in the same way and yield the expected result.
3. Reasonable expectation of success because Veri-Fone already executed remotely supplied programs on general-purpose hardware, and '984's API-shim layer already executed code crossing its boundary.

Weakness of this ground (candid): Gelb '984 teaches removing source/destination address information from the communication transferred between motherboards. To the extent Ground A requires the firewall itself to execute the message's methods to learn its source and destination, '984's invention points the other way — this is a genuine "teaching away" argument the patent owner can raise (see §6). The ground survives only because '842 supplies a firewall that reconstructs/uses destination information (it must encapsulate to a destination firewall) and because '984's removal is of public-network addressing, not of an in-band authenticated source/destination assertion.

---

Ground B — Claims 2, 3, 10, 11, 15, 18, 21, 24: DEC '573 (Signature Data Object) + '842 (or '984), optionally with '5557518

Rationale: The signature limitations recite the textbook hash-and-sign/verify cycle: compute a message digest with a predetermined function, encrypt with a private key, embed the signature; at the receiver, decrypt with the corresponding public key, recompute the digest, and compare.

• DEC '573 discloses an application-level structured record attached to an object that carries a proof block and whose validity can be determined — i.e., an embedded, self-verifying signature on an object. A POSITA would apply that record verbatim to the packet-object of claim 1.
• The specific message-digest/private-key-encrypt mechanics were, by 1993-95, the ordinary and well-understood RSA/DSA/PEM construction (and are the subject of the '573 field). The claim adds no non-conventional detail: it does not even specify an algorithm, only "a predetermined function."
• Claim 3's separate methods signature vs. data signature (one over the methods, one over the data, so the class originator and the data originator can sign independently — '449 spec: "the encryption key used to encrypt the message digest of the methods… is the private key of the originator of the class… the encryption key used… for the object data is the private key of the originator of the data") is a natural extension of the SDO concept, which expressly contemplates "a single parent object can have multiple SDOs applied to it with differing levels of semantic tags" and "multiple SDOs might be applied by multiple versions of an evolving software application." '573 thus directly suggests plural, differently-signed records on one object — which is claim 3.

Motivation: '573 states its object is "not bound to any specific level of security implementation or technology" and exists to answer whether a signed object is valid. Placing it on a firewalled network message is the purpose for which '573 was designed; the combination produces the predictable benefit of tamper detection and origin authentication.

---

Ground C — Claims 4 and 12: Taligent '264/'138 + '984

Rationale: Claim 4 requires (i) the object to be an instance of a class whose header identifies a predefined "security" class, and (ii) a screener at the receiving entity that determines the class from the header and rejects the object if it is not "security."

• '984 already discloses the screening step at a boundary: Gelb's firewall "inspects the protocol identifier and then handles the data packet in accordance with a corresponding protocol procedure. If the network packet handler does not recognize the protocol identifier, it will typically reject the received data packet" (this text is the '449 spec's own description of the prior art, FIG. 5, and it describes '984-type firewalls).
• Taligent '264/'138 supply the object/instance-of-class/hierarchy model in which a type field in an object's header determines how it is handled.
• A POSITA combining them arrives at class-based screening of a message object as a predictable substitution of "protocol ID → protocol handler" with "class ID → class handler." The word "security" is a naming choice, not a technical difference.

Weakness: the specific choice to name/define the superclass "security" and to make that the pass/fail gate is not expressly taught. This is a § 112(b) problem more than a § 103 problem (the claim does not define what makes a class a "security" class), but a patent owner may argue the specific gating architecture is the point of novelty.

---

Ground D — Claims 5 and 7: Veri-Fone '521 + '984 + the known platform-independent interpreter art

Rationale: Claim 5/7 require only that the methods be written in "a predefined virtual machine language" executed by "a virtual machine module" regardless of the host's platform and OS.

• '984 already describes "passing executable code between" heterogeneous nodes (a Novell/Netware motherboard and an NT motherboard on different hardware), which presupposes portable executable content.
• Platform-independent byte-code execution by a virtual machine was, by 1994-95, long-known and standard (UCSD p-System p-code; Smalltalk virtual machines; and Java's bytecode/VM, which Sun itself describes in its own late-1990s filings as byte codes "not hardware specific… thus can be downloaded and executed on many different computers"). The claims add nothing beyond this — no VM construction detail is recited.
• Motivation: portability is the express reason one puts program logic in the message rather than in the firewall; '449's own specification ties the packet object's language to the "virtual machine modules 216, 316, and 416" precisely to make the same object run on client, firewall and server.

Note: the '449 specification's reference to Java ("preferably a 'Java'… virtual machine module") is a preference, not a claim limitation, and the claims do not recite Java. A rejection on generic VM art is therefore cleaner than a Java-specific one.

---

Ground E — Claims 6, 13, 16, 19, 22, 25: Gelb '984 + Veri-Fone '521 (+ Citibank '5557518)

Rationale: The main-method claims require an executable main method that, once source/destination are verified, is executed to implement a desired function (e.g., reconfigure a router, change the default printer, deliver e-mail).

• Veri-Fone '521 = execute a remotely supplied application program to perform the terminal's work.
• '984 = an intermediary that passes "code necessary to request and receive services from the other computer network" and that "retranslat[es]" the communication onward — i.e., the verified message is forwarded and then does something at the far side (a service request).
• '557518 (Citibank) = trusted agent software that receives an authenticated request and executes a transaction on the recipient's behalf — a near-perfect analogy to "main method executes a function with respect to the second network entity."

Motivation: the entire purpose of a security gate is to let through a useful operation and block a harmful one. Once authentication (Ground B) and screening (Ground C) are in place, executing the verified payload is the only remaining rational use of the object, and KSR permits the conclusion where the combination "was obvious to try" with a reasonable expectation of success.

---

Ground F — Claim 8 (re-transmission to an identified other network entity): '984 alone (primary), or '842

Rationale: Claim 8 is nearly a verbatim description of '984 claim 10/claim 1: receive at a first motherboard, and after the communication is acceptable, "transmit[] said retranslated communication to said second computer network." '842 likewise discloses the firewall re-encapsulating and forwarding a packet to the remote firewall named by the destination address. Motivation: forwarding a verified object is the functionally necessary next step; no new principle of operation is introduced.

---

Ground G — Claims 20–25 (computer data signal embodied in a carrier wave)

§ 103: these claims are obvious for the same reasons as claims 14–19 (claims 21–22, 24–25 are literal dependents of claim 20/23's subject matter). The "carrier wave" format adds no technical element that alters the obviousness analysis — it merely recites the same instructions as a propagating signal. Ground A–E therefore apply a fortiori.

Two independent problems beyond § 103, flagged for completeness:

1. § 101: claims to a signal per se were held non-statutory in In re Nuijten, 500 F.3d 1346 (Fed. Cir. 2007) (a propagating signal is not a "manufacture" or "machine" and is a transitory embodiment). This is a validity attack independent of, and in some ways stronger than, obviousness.
2. § 112(a)/(b): the specification describes a packet object with a network header and trailer stored and processed at network entities; it contains no description of generating, modulating, or receiving a carrier-wave signal, and claims 20/23 lack antecedent basis for "the generated object" in the dependents. Expect § 112 written-description and indefiniteness exposure on these claims.

---

5. Consolidated motivation-to-combine showing

The grounds above do not rely on a single "magic" reference. They rely on a five-way convergence, each pairing supported by an articulated reason:

Under KSR, this is the paradigm case of "a combination of familiar elements according to known methods [that] is likely to be obvious when it does no more than yield predictable results." Nothing in claims 1, 9, 14 and 17 changes the principle of operation of a firewall; it changes where the logic lives.

---

6. Where the obviousness case is genuinely weak (do not overstate it)

I want to be explicit about the limits of the above, because a well-constructed § 103 rejection must survive these:

1. No cited reference discloses executing the sender's code at the firewall in order to determine the message's own source and destination. '984's firewall executes its own code and strips source/destination addressing. '842's firewall uses out-of-band cryptographic credentials and a destination IP address, not in-band executable methods. This is the single most defensible point of novelty across all independent claims, and the strongest non-obviousness argument for the patent owner.
2. '984 arguably teaches away from the claim-1 architecture by removing address information at the boundary (though it removes public-network addressing, which is a distinction the challenger must draw carefully).
3. WO 92/22033 and US 5,144,664 are unverified in content. Any ground resting principally on WO 92/22033 collapses if the reference turns out to be about a different kind of "active messaging." Obtain the WO text before relying on it.
4. Claim 4's "security" class gating has no express counterpart in the cited art; the ground is a "predictable substitution" argument, which is weaker than an express teaching.
5. Secondary considerations (which a challenger must address): the '449 patent and its family claim priority to October 1995, the very moment Java/bytecode was being deployed (the page itself says the VM "is preferably a 'Java'… virtual machine module"). Evidence of industry adoption of executable-content security models and of licensing/commercial success attributable to the '449 family (Sun's own 1997-98 Java-security filings, e.g. WO 98/44404, and Sun's "servlet sandbox" line, appear in the record as citing references) can be used by the owner as nexus evidence. Note the counter: the same citing references post-date the priority date and describe the same general architecture, which supports that the architecture was, by 1997-98, the natural and expected extension of 1995 practice — a double-edged use of the same evidence.

---

7. Verification gaps and honesty statement

• I was able to confirm the content and key disclosures of US 5,550,984 (via uspto.report and Google Patents), US 5,602,918, US 5,416,842, US 5,367,573, and US 5,517,518.
• I could not retrieve the specification of WO 1992/022033 ("Active messaging system," Bell Communications Research) — every ground relying on it is expressly marked conditional.
• I could not retrieve US 5,144,664 or US 4,724,521 in full; both are characterized from their titles and from the page's citation table. US 4,724,521 is central to Grounds A and E, so pulling its specification is a prerequisite to filing any rejection.
• US 5,602,918 must be removed from any chart built from this page's citation list (post-date filing, §0.2), and US 5,680,461 must never be used as art against the '449 claims (same family/inventor).
• The Fischer EP 0 570 123 A1 lead (§0.3) is the single highest-value item to verify: if it published before 1994-10-26 and discloses authenticated distribution/execution of remotely supplied programs, it materially strengthens Grounds A and E and may create an independent § 102(b) anticipation theory for claim 17 (which requires only a generator that transmits an object whose source/destination methods self-verify).
• Where the prior-art record conflicts with my training data, I have used the record as retrieved. Where I lack high confidence (WO 92/22033's disclosure; '557518's exact filing date; '617's and '476's filing dates), I have said so rather than asserting it.

---

8. Summary table of grounds

Bottom line: Claims 2, 3, 5, 7, 8, 10, 11, 15, 18, 21, 24 are the most vulnerable — they recite conventional cryptographic and virtual-machine mechanics applied to the object-of-claim-1. Claims 1, 9, 14 and 17, while they read broadly on the combination, depend on (i) the WO 92/22033 disclosure being what its title suggests and (ii) characterizing '984's address-stripping as not inconsistent with a firewall that executes in-band source/destination methods. Claims 4, 12, 6, 13, 16, 19, 22 and 25 sit in between. The one argument that most threatens the whole family of grounds is the absence, in the cited art, of any teaching to run untrusted sender-supplied code inside the security boundary to establish that message's own provenance — that is the honest center of gravity of whatever invention is here.

---

Cross-reference note re: prior sections

Nothing in the earlier litigation section contradicts this analysis; that section found no litigation and correctly flagged the near-miss patent numbers (5,787,449 / 6,895,449 / 7,373,449). I add one cross-reference: US 5,680,461 (the parent) should also be screened for third-party citations, as the earlier section suggested — but for § 103 purposes, and as set out in §0.2, the '461 patent itself cannot be prior art against the '449 claims.