US 6954893

I'll verify this specific patent number against live sources before summarizing.

Let me pull the actual claim text and check for any 2026 CAFC activity.

Let me try to retrieve the literal claim language, and one more check for litigation/docket activity.

Verification note first

I searched for the specific number 6954893 (and the nine-digit 6,954,893). I found consistent results confirming a real, granted US patent with that exact number. I did not find any Federal Circuit (CAFC) 2026 docket, appeal, IPR, or other post-grant proceeding involving this patent — those searches returned empty. I also could not retrieve the literal wording of the claims (the authoritative text supplied to me is truncated immediately after the "Summary of the Invention," before the claims). Everything below about claim scope is therefore derived from the specification's Summary/Detailed Description and is flagged accordingly.

1. Bibliographic identification

Abstract (verbatim from the patent): "A system and method for performing reliable unidirectional communication in a data network is disclosed. Unidirectional data is sent from a transmitting device to a receiving device. Prior to transmission, the data is divided into a window (401b) comprised of data bytes. A checksum value (407) is computed across data bytes comprising window (401b). Checksum value (407) is placed into an XML integrity element (404) that encapsulates window (401b) in a manner allowing a receiving device to use the contents of integrity element (404) to validate the received window (401b). Checksum value (407) is compared to a second check sum value computed across window (401b) at the receiving device. If checksum value (407) matches the second checksum value, window (401b) is validated."

2. What the patent actually covers

The invention solves a narrow, concrete problem: one-way (broadcast) infrared data pushed to battery-constrained handhelds has no return channel, so there is no ACK/NAK and no retransmission. The patent's answer is to wrap each block ("window" or "frame") of payload bytes in a special XML integrity element carrying a checksum computed over that block. The receiver recomputes the checksum, compares, and either accepts and strips the integrity element or discards and resynchronizes. Because the wrapper is XML, an ordinary XML parser can perform the integrity check and dispatch — no custom radio/IR hardware or handshake is needed.

Supporting disclosure worth noting:

• Integrity element header (403) contains checksum value 407, window size 408, operator 410, and seed 412; checksum may be computed by XORing each byte with its neighbor, and an optional time element (timestamp/GMT) provides temporal context.
• Three BI XML element types are broadcast: a banner element 302 (ticker), a service element 304 (identifies/downloads a service, potentially including executable code), and a context element 306 (a wrapper used to filter whether content is relevant to the client).
• Media-arbitration trick: the emitter transmits in 20 ms "on" bursts separated by 980 ms "off" intervals, sized against the IrDA 100 ms retry / 500 ms media-busy rules so the diffuse downlink does not block IrDA-to-IrDA traffic on the same port. This is the "gated transmission" aspect.
• Receiver architecture: the IrDA link layer is retained (physical/link layers are compatible with diffuse IR), while IrDA's bidirectional layers above the link layer are replaced by unidirectional client modules (CLM states: open, close, find-IC-element, perform-integrity-check, create-XML-element).

3. Plain-language overview of the independent claims

⚠️ Caveat: I could not obtain the issued claim language. The following is a reconstruction of the independent claims from the patent's own "Summary of the Invention," which tracks claim scope closely but is not the claim text. Claim numbers, exact transitions ("comprising" vs. "consisting"), and any narrowing language must be confirmed against the granted claims.

Based on that Summary, the patent's independent claims appear to fall into five families:

(a) Transmitter-side apparatus — "apparatus for creating and transmitting a data signal."
Drafted in means-plus-function form. An input data stream of bytes is divided by a parsing means into at least one frame (a subset of the bytes). A computing means calculates a checksum over that subset so the checksum uniquely identifies it. A providing means supplies an integrity element, and an embedding means writes the checksum into that integrity element. The integrity element is placed around the frame so it encapsulates the frame, letting the receiver determine whether the subset arrived "substantially intact." The element + frame together form a broadcast signal handed to a transmitting means.

(b) Receiver-side apparatus — "apparatus for receiving and utilizing a data signal."
Also means-plus-function. A detecting means finds the frame and its integrity element in the incoming stream; a separating means extracts the integrity element; a determining means reads its contents; and a utilizing means uses those contents to test the frame's validity. In the disclosed alternative, the integrity element holds a checksum computed over the frame, the receiver computes a second checksum, and a match validates the frame.

(c) Method of utilizing executable code in a source device (computer program product / computer-readable signal aspect).
Executable code on the source device performs the same four acts and then makes the resulting broadcast signal available to a transmitter for transmission to a handheld device over the communication medium. This is the software/floppy-disk-style claim (the disclosure expressly claims an "apparatus, computer program product, method, and/or computer-readable-signal").

(d) Method for creating a data signal at a source device having a transmitter.
The method-step counterpart of (a): parse data into bytes → group into a frame → determine a checksum over the frame → provide an integrity element → embed the checksum → encapsulate the frame in the integrity element to form a broadcast signal → make it available to the transmitter.

(e) Method for receiving and utilizing a data signal.
The method-step counterpart of (b): detect an integrity element encapsulating bytes grouped as a frame → separate the frame from the integrity element → use the integrity element's contents to test the frame's validity.

Dependent claims (per the specification, not confirmed as issued) likely add: the checksum-comparison-if-match validation step; window size / operator / seed fields in the integrity element header; a timestamp/"time element"; and XML-element framing (banner/service/context).

4. Uncertainty and data-quality flags

• Claim text not independently verified. I retrieved the specification and abstract, not the printed claims. Treat the claim overview above as faithful to the disclosure but not authoritative on claim numbering or exact language.
• No CAFC 2026 (or any) litigation found. Searches for a 2026 Federal Circuit docket, IPR, or reexamination tied to 6954893 returned nothing. That is a negative search result, not proof of absence — I cannot rule out a proceeding that is not web-indexed. The patent's fee-related expiration in 2022 also makes fresh appellate activity unlikely, since the term has lapsed.
• Assignee chain. Lockheed Martin Corporation is listed as both original and current assignee; a corrective assignment was recorded 2002-07-09 (reel 012602, frame 0589) correcting the earlier 2002-01-16 recordation.
• Internal inconsistency in the source text. The Google Patents rendering describes "controller 106 comprising broadcast information (BI) controller 106b and service controller 106a," while other renderings of the same passage (and the later discussion of "Broadcast information controller 106B") reverse the two labels. This is a transcription/citation artifact in the secondary source, not a change to the patent.
• Third-party interest. The patent is cited as prior art in later filings, e.g. in the U.S. patent document listing for US 9,591,692 and in the international search report for WO 2007/054775 A3. This confirms the number and its 2005-10-11 issue date but does not bear on claim scope.

I'll research litigation involving US Patent 6954893. Let me search multiple sources.

Let me search specialized patent litigation databases.

Let me try the Unified Patents portal and other litigation-specific searches.

Litigation Search Results — U.S. Patent No. 6,954,893

Bottom line: I found no evidence of any litigation involving U.S. Patent No. 6,954,893. Based on the searches conducted, there is no known district court, Federal Circuit, ITC, or PTAB proceeding in which this specific patent was asserted or challenged.

What I searched and what I found

I searched for the specific patent number (both "6954893" and "6,954,893") in combination with litigation terms, the patent owner (Lockheed Martin), the patent title, and the asserted technology ("InfoFlo"). I also attempted to reach patent-litigation databases (Unified Patents litigation portal, CourtListener, and related dockets).

The searches returned no hits for the '893 patent itself. Every result that mentioned a similar-looking number was a different patent, which I am explicitly flagging rather than conflating:

Important caveats on this negative finding

1. Search limitation. I was unable to directly load the specific case list pages (e.g., portal.unifiedpatents.com/litigation/caselist?patents=6954893) — the retrievable results were secondary documents, not the direct litigation record for this number. My conclusion is therefore based on indexed search results, not an authoritative docket query. I cannot rule out the existence of litigation that simply did not surface in these searches.

2. Verify against primary sources. To confirm, the authoritative checks would be:

   • Unified Patents litigation portal, filtered by patent 6954893
   • USPTO Patent Center / Patent Assignment records for the '893 patent
   • PACER / CourtListener docket search on "6,954,893"
   • Google Patents "Litigation" tab (which is populated from these sources)

3. Patent characteristics suggest little or no assertion. The record itself is consistent with a low-litigation profile:

   • Assignee: Lockheed Martin Corporation (original and current)
   • Priority date: Aug. 15, 2000; Filed: Aug. 15, 2001; Granted: Oct. 11, 2005
   • Legal status: Expired – Fee Related, adjusted expiration Oct. 26, 2022
   • It is one of a family of Lockheed Martin applications filed Aug. 15, 2001 (including Ser. Nos. 09/930,421; 09/929,979; 09/929,995; and a related continuation that issued as US 7,386,238).
   • A patent that lapsed for failure to pay maintenance fees and was never transferred to a monetization entity is unlikely to have been the subject of infringement suits.

Direct answer to your request

• Known litigation involving US 6,954,893: None identified.
• For each requested field (plaintiff, defendant, jurisdiction, case number, filing date, outcome/status): not applicable — no case was found.

If you need a definitive negative confirmation, I recommend a direct query to the Unified Patents litigation portal and PACER for "6,954,893"; if you can supply docket access, I can help analyze any hits. I'd rather flag this as an unconfirmed negative than invent a case to fill the requested fields.

Proceedings overview

Zero (0) AIA trial proceedings on file for US 6,954,893 — 0 active, 0 with claims invalidated, 0 with claims sustained, 0 settled, 0 institution denials. The USPTO Open Data Portal returns no IPR, PGR, or CBM proceeding naming this patent, and independent web searching (patents.google.com, PTAB-related publications, PTAB/CourtListener-indexed material) surfaced none either. Bottom line for a defendant: there is no IPR record to leverage and no IPR-based estoppel to worry about — but that is cold comfort either way, because the more consequential fact is that the patent is expired (Google/ODP legal status: "Expired - Fee Related," adjusted expiration 2022-10-26). A defendant's best posture is therefore not "the PTAB killed the claims" but "this patent is dead as of 2022-10-26; any demand built on ongoing infringement is facially defective, and any recovery is limited to pre-expiration past damages within the § 286 six-year window."

Per-proceeding detail

There are no proceedings to detail. To be explicit about what that means rather than silently omitting the section:

(None) — No AIA trial proceeding identified

• Type: N/A — no IPR, PGR, or CBM petition has been instituted or filed against US 6,954,893 in the sources reviewed.
• Filed: N/A
• Status: Per the structured "PTAB proceedings on file" block (USPTO ODP, most recent ingest): no AIA trial proceedings. I found nothing in web search that contradicts this.
• Judge panel: N/A — no panel exists.
• Petition grounds: N/A
• Institution decision: N/A
• Final Written Decision: N/A. No claim of US 6,954,893 has been canceled, confirmed, or construed by the PTAB. I am not aware of any FWD, and I will not manufacture claim-level outcomes.
• Settlement / termination: N/A
• Appeal: N/A — no FWD to appeal. No CAFC appeal of any PTAB decision on this patent is known to me.
• Defensive value: Neutral-to-strong. There is no PTAB win to cite, but there is also nothing on the patent owner's side to cite. The stronger defense is statutory expiration plus the pre-AIA, means-plus-function claim style (see below).

Why the absence is plausible here (not just an ODP indexing gap): US 6,954,893 issued 2005-10-11, is a pre-AIA patent (priority 2000-08-15), and expired 2022-10-26. The realistic challenge windows have closed or lost value: PGR was never available (pre-AIA patent, and the 9-month § 321(c) window closed in 2006); the CBM program sunset for new petitions on 2020-09-16; and IPR, while technically available at any time against a pre-AIA patent, is a poor vehicle against a patent with under two years of life left. I found no evidence this patent was ever asserted in district court litigation — searches surfaced only unrelated Lockheed matters (the Honeywell night-vision § 1498 case, MIT v. Lockheed Martin Global Telecommunications, and a particle-counter dispute), none involving the '893 patent.

Strategic summary

Claim status: entirely UNTESTED. No claims of US 6,954,893 are canceled. No claims are sustained. No claims have been narrowed by amendment (no IPR motion to amend, no reexam certificate appears in the sources reviewed). The whole claim set — from the specification's description, drafted in classic means-plus-function form ("parsing means," "computing means," "providing means," "embedding means" on the transmit side; "detecting means," "separating means," "determining means," "utilizing means" on the receive side) — stands or falls on the original prosecution record and § 112(f) construction, not on any PTAB record. Among the sibling applications disclosed on the face of this patent, § 09/930,421 ("Method and Apparatus for Infrared Data Communication"), § 09/929,979 ("Method and Apparatus for Determining the Context of a Handheld Device"), and § 09/929,995 ("Method and Apparatus for Delivering Services in a Constrained Environment") all issued into the same Lockheed Martin "InfoFlo" context family, and US 7,386,238 claims priority to this line. I have not verified whether those siblings attracted separate PTAB activity — do not assume the family is clean just because the '893 is.

Estoppel landscape: essentially empty, but asymmetric in the defendant's favor. Because no IPR was ever instituted against the '893 patent, no petitioner is subject to § 315(e)(2) estoppel as to this patent, and there is no PTAB record on which a patent owner could pin a district court to a narrower construction. That cuts both ways: you cannot inherit someone else's invalidity win, but you also face no adverse claim-construction rulings. Any prior art — including art that a hypothetical earlier petitioner "reasonably could have raised" — remains fully available to a defendant under §§ 102/103/112 in district court. Practically, however, the strongest lever is not art at all: the patent's expiration on 2022-10-26 means there is no prospective infringement to enjoin and no ongoing royalty to negotiate.

Pattern signals. No defensive aggregator (Unified Patents or similar) has targeted this patent. No serial petitioner. No patent-owner appeal history to the Federal Circuit on this patent — because there is no PTAB decision to appeal. The relevant pattern is instead a corporate one: this is Lockheed Martin's own research portfolio (inventors Noah J. Ternullo, Nader Mehravari, Patrick H. Madden), not an NPE asset, and the file history shows it was never monetized through PTAB-facing litigation or an aggressive assertion campaign that I could find. The absence of any PTAB activity on a 25-year-old patent that survived to full term is itself a signal: this patent was not a litigation asset.

Recommended next steps

1. Confirm the expiration and fee status on the official record before relying on it. The "Expired - Fee Related / expires 2022-10-26" entry is a machine-derived legal-status assumption (Google's own disclaimer). Pull the maintenance-fee and term-adjustment history from USPTO Patent Center (https://patentcenter.uspto.gov/) and the file wrapper for application 09/930,004 to confirm (a) no maintenance-fee reinstatement petition and (b) the PTA-adjusted expiration date. If expired, the patent cannot support an injunction or an ongoing-royalty theory.

2. Check the file wrapper for non-AIA activity. The ODP "PTAB proceedings on file" block covers AIA trials only. Before treating the record as completely clean, verify there is no ex parte or inter partes reexamination certificate in the file wrapper, and no terminal disclaimer affecting term. Nothing in the sources I reviewed indicates one, but I could not verify this from the ODP data alone.

3. Calendar the § 286 limitations horizon. For an expired patent, recovery is limited to infringing acts within six years before the complaint is filed (35 U.S.C. § 286). With infringement ending at expiration (2022-10-26), a suit filed after 2028-10-26 recovers $0 in damages. Any demand letter you receive before then should be evaluated against the actual pre-2022-10-26 accused activity, not against current product sales.

4. If a demand letter nonetheless cites US 6,954,893, attack the claims on § 112(f). The claims are means-plus-function drafteed (from the specification, e.g., "parsing means," "computing means," "detecting means," "utilizing means") with corresponding structure limited to the XML-integrity-element/checksum embodiment described at cols. re integrity element 402/404/406, checksum value 407, window size 408, operator 410, and seed 412. Under Williamson v. Citrix, indefiniteness and narrow corresponding-structure arguments are the highest-value defenses — and they are untouched by any PTAB record because there is none.

5. Verify before you file anything. My searches did not surface any PTAB proceeding, any FWD, any CAFC appeal, any judge panel, or any settlement for this patent. I am not claiming such records don't exist in a database I failed to reach — I am telling you the ODP structured list is empty and web search did not fill it in. Cross-check PTAB E2E (https://ptacts.uspto.gov/ptacts/) by patent number and by assignee ("Lockheed Martin") before you represent to a court or an adversary that the patent has zero post-grant history.

I'll verify what I can about the assignment record and the Lockheed Martin context before writing this up.

Let me check the inventors' later affiliations and any assignment/NPE activity.

Assignment-chain reconstruction — US 6,954,893 B2

⚠️ Sourcing caveat (read before the timeline)

I could not directly query the USPTO Assignment Center in this session. Searches against assignment-center/assignment.uspto.gov and against the patent number plus assignment terms returned zero results, and my remaining retrieval steps were exhausted before I could resolve the correspondent fields. Everything below is reconstructed from the legal-events (reassignment) records embedded in the authoritative Google Patents rendering supplied to me, cross-checked against the patent's own specification.

Two consequences you must hold onto:

1. Correspondent data is unavailable. The Google Patents legal-events feed does not carry the filing attorney/agent or firm. The "repeat correspondent" signal — the single most valuable one for this task — therefore cannot be scored from what I have. I am not going to invent an attorney name to fill the field.
2. A reel/frame is only partially attributable. See the ambiguity note under the timeline.

I found no assignment record transferring this patent away from Lockheed Martin, and no security agreement, license, merger, or release in the chain.

Inventors

Pattern notes:

• All three inventors share a single employer, and all three simultaneously executed the inventor→employer assignment recorded in 2002. That is the ordinary employee-invention picture, not a fragmented-ownership picture.
• No evidence of a mass departure of the inventor group within 12 months of the 2001-08-15 filing, and none is even plausible here: the assignment ran to the employer, was recorded twice (originally and then corrected), and the patent never left Lockheed Martin. Not present. (This is a negative finding from the record, not a verified employment history — I could not retrieve individual departure dates.)
• Inventorship does not equal authorship. The InfoFlo IEEE paper carries a fourth author, Robert J. Szczerba, who is not a named inventor on the '893 patent. He belongs elsewhere in the Lockheed Martin InfoFlo family (the co-pending applications). Do not conflate the paper's author list with this patent's inventive entity.
• Source inconsistency to flag: the two reassignment entries list the assignors in different orders — "MEHRVARI, NADER, MADDEN, PATRICK H., TERNULLO, NOAH J." (2002) versus "MEHRAVARI, NADER, TERNULLO, NOAH J., MADDEN, PATRICK H." (corrective). Same three people; this is a recording-order artifact, not a change in inventorship. Note also the spelling drift Mehravari / Mehravari across records.

Original assignee

Lockheed Martin Corporation, a Maryland corporation — named as assignee on both 2002 recordings, and listed by Google Patents as both original and current assignee.

• Primary line of business: aerospace, defense, and government IT/systems integration. (NYSE: LMT; a going concern — no bankruptcy, no receivership, no dissolution.)
• Did they ship a product embodying the claims? No — not at commercial scale. The originating work, InfoFlo, was a research proof-of-concept: the inventors' own paper describes it as a "proof of concept system showing the viability of the InfoFlo communications infrastructure in its minimal configuration," implemented on a Palm III with a "hybrid Diffuse IR – IrDA network" and a headless kiosk for the return path. There is no evidence of an InfoFlo product SKU, license, or revenue line. This is a corporate-research patent, not a product patent.
• Current owner: Lockheed Martin Corporation, per the last recorded reassignment and the current-assignee field. No post-issuance transfer was recorded.

Assignment timeline

Only two reassignment records exist. If Assignment Center holds additional post-issuance records that did not reach the Google Patents feed, that would be news to me — but on the record I have, the chain is two entries long, and the second is administrative.

Record 1 — the original inventor assignment

• Executed: not stated in the source / recorded 2002-01-16
• Reel/Frame: 012602/0589 (most probable attribution — see ambiguity note below)
• Conveyance: Assignment ("ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS)")
• Assignor: MEHRAVARI, NADER; MADDEN, PATRICK H.; TERNULLO, NOAH J.
• Assignee: LOCKHEED MARTIN CORPORATION, A MARYLAND CORPORATION
• Correspondent: not available in my source — the feed omits the filing attorney/agent and firm. Cannot be scored.
• Context: ordinary employer-invention assignment — the three Lockheed Martin engineers convey their rights in the application to their employer. Near-simultaneous with the 2001-08-15 filing; not an acquisition, fire-sale, or securitization.

Record 2 — the corrective document

• Executed: not stated / recorded 2002-07-09
• Reel/Frame: not stated for this record; the entry cites REEL 012602, FRAME 0589 as the record being corrected
• Conveyance: Correction ("CORRECTIVE DOCUMENT REEL 012602, FRAME 0589")
• Assignor: MEHRAVARI, NADER; TERNULLO, NOAH J.; MADDEN, PATRICK H.
• Assignee: LOCKHEED MARTIN CORPORATION (no "a Maryland corporation" suffix in this entry)
• Correspondent: not available in my source.
• Context: purely administrative correction to a defect in the original recording. No change in ownership — the patent stayed with Lockheed Martin before and after. This entry is not a transfer and should not be counted as a link in the chain.

Ambiguity note on 012602/0589 (flagging rather than guessing): the source renders the 2002-01-16 entry without a reel/frame and the 2002-07-09 entry with the string "REEL 012602, FRAME 0589" embedded in the conveyance description. USPTO corrective filings conventionally cite the previously recorded reel/frame in that position, which points to 012602/0589 being the original assignment and the corrective carrying its own, unstated reel/frame. Reel 012602 is numerically consistent with an early-2002 recording date. I regard that reading as probable but unconfirmed — verify both reel/frames against Assignment Center before relying on them.

No later records. Nothing assigned the patent out of Lockheed Martin after 2002. No security interest, no license recordation, no change of name, no merger, no release.

Timeline diagram

timeline
    title Ownership of US 6954893
    2000 : Provisional app filed by inventors
    2001 : Non-provisional app filed 15 Aug 2001
    2002 : Rights assigned to Lockheed Martin
         : Corrective recording 9 July 2002
    2005 : Patent issued 11 October 2005
    2022 : Term expires 26 October 2022

NPE / troll-pattern signals

Corroborating negative evidence: the patent's legal status is "Expired – Fee Related," adjusted expiration 2022-10-26 — i.e., Lockheed Martin let the term lapse for non-payment of maintenance fees rather than maintaining it for assertion. That is a strong, concrete indicator of a non-monetization posture.

Verdict

Insufficient data — under the strict reading of your options ("no records, or only the original assignment"). That is the honest label, but state the substance clearly: the data gap is not missing ownership records; it is the missing correspondent fields. On ownership, the chain is complete and unambiguous — the only records are the original inventor assignment and a corrective document (most likely reel 012602/0589, both recorded in 2002), both to the same assignee, Lockheed Martin Corporation, with no transfer thereafter and no assertion activity identified. None of the eight NPE signals fires: signals 1, 2, 4, 5, 6, 7 and 8 are not present, and signal 3 is unclear solely because the attorney/firm of record was not retrievable from my source. A corporate-research patent that stayed with its defense-contractor employer and lapsed for non-payment of fees is the profile of a non-asserted asset, not a troll asset — but I decline to upgrade the verdict to a clean negative while the correspondent test remains unscored.

To close the remaining gap (and confirm the reel/frame attribution): query https://assignmentcenter.uspto.gov/ (identical records are indexed at https://assignment.uspto.gov/patent/index.html) by patent number 6954893, and pull the correspondent of record for the 2002-01-16 entry and for the 2002-07-09 corrective. If you can supply that output, signal 3 can be scored in one step.

Contradiction log

• No contradiction with the previously generated sections. The earlier sections independently reached the same negative litigation finding and the same assignee chain (Lockheed Martin original and current; corrective recorded 2002-07-09 at reel 012602, frame 0589). This section adds the correct interpretation of that citation — that 012602/0589 is most likely the corrected record, not the corrective record's own reel/frame — which the earlier text did not address.
• One minor artifact carries forward: the Google Patents rendering reverses the order of the listed assignors between the two 2002 entries, and reverses the labels of controllers 106a/106b relative to other renderings of the same passage. Both are transcription artifacts in the secondary source, not changes to the patent.

I'll research the prior-art citations for US 6,954,893, building on the verification and litigation work already done. Let me pull the patent's citation records from multiple sources.

The general searches are noisy. Let me target the citation tables directly.

I have partial citation data. Let me target Justia and the Google Patents citation tables directly.

Prior-Art Analysis for US 6,954,893 — Sourcing Caveat First

I could not retrieve the face-of-patent "References Cited" list for US 6,954,893 from any source I could reach, and I will not fabricate it. This is the central limitation and it directly constrains the task you set. Here is exactly why, and what I can and cannot give you.

The authoritative full text supplied to me is truncated immediately after the "Summary of the Invention" — it therefore does not contain the printed claims, nor the front-page citation tables (U.S. Patent Documents / Foreign Patent Documents / Other Publications). At the same time, my web searches for the number returned mostly noise, not the '893 citation record: irrelevant hits such as US 5,368,742 (resin-acid removal from paper effluent), an acoustics paper on nonreciprocal devices, and unrelated WO/EP search reports. The one search that reached a genuine '893 record (the Google Patents / FPO rendering) returned the specification text only, cut off before the citations. I exhausted my tool budget before loading the Justia, FreePatentsOnline, or Google "Patent Citations" tables.

So: I have not verified the backward citations of US 6,954,893. Any specific per-reference § 102 mapping I produced now would be invention, not analysis. Below I give you everything I did verify, the specification's own identified prior art, and a rigorous framework you can populate once the front page is in hand.

A. Disambiguation: two different things are called "citations"

Your request can mean two opposite directions, and they carry different legal significance:

I was able to confirm several forward citations (Section D) but no backward citations. Do not let the forward list be mistaken for the prior art you want.

B. Identification confirmed (literal, no auto-correction)

The number resolves literally to a real grant: US 6,954,893 B2, Method and apparatus for reliable unidirectional communication in a data network, application 09/930,004, filed 2001-08-15, priority 2000-08-15 (provisional 60/225,349), granted 2005-10-11, inventors Ternullo / Mehravari / Madden, assignee Lockheed Martin Corporation. Status Expired – Fee Related, adjusted expiration 2022-10-26. (Consistent with the earlier-generated section; no contradiction found.)

Important consequence for your § 102 question: because the term lapsed in 2022, § 102 anticipation is now of historical/validity-only interest — there is no live infringement to defend against, so the practical purpose of "which claims are anticipated" is to understand what the art did or did not teach at the 2000/2001 priority date.

C. Backward citations (the prior art you asked for) — status

Result: not retrieved. I have no verified list of U.S. patents, foreign patents, or non-patent publications cited on the face of US 6,954,893.

What this means for each field you requested (full citation / publication-filing date / description / anticipating claims): I cannot supply them without inventing references. I am declining to do that.

What I can tell you about the art the patent itself engages, taken from its own "Description of Prior Art" section (this is the specification talking about prior art, not the examiner's citation list — a meaningful distinction):

The IrDA standard is the only item the spec treats as a concrete, dated technical standard, and it is the reference most likely to bear on any claim covering the emitter on/off burst scheme (the 20 ms-on / 980 ms-off arbitration against IrDA's 100 ms / 500 ms rules). The spec itself concedes diffuse IR is unacknowledged and thus unreliable — which is precisely the gap the integrity-element claims are drafted to fill.

D. Forward citations — verified ("cited by" '893)

These are not prior art against '893 (all post-date it) but confirm the number and show downstream interest. Verified in this session:

1. US 9,591,692 B2 — "Dynamic point to point mobile network including destination device aspects system and method" — lists US 6,954,893 B2 (Ternullo et al., Oct. 11, 2005) under "References Cited / Referenced Cited."
   URLs: https://patents.justia.com/patent/[9591692](/patent/9591692) and https://patents.google.com/patent/[US9591692B2](/patent/US9591692B2)
2. WO 2007/054775 A3 — Nokia, "Portable local server with context sensing" — search-report/IDS listing shows "US 6954893 B 11/10/2005."
   URL: https://patentimages.storage.googleapis.com/d1/9d/67/52afec79dd9bf7/WO2007054775A3.pdf
3. WO 2002/015438 A1 ("Infrared data communication system") — its Google "Cited By" table lists US 6,954,893 B2 together with the sibling Lockheed patents US 7,215,887, US 7,280,823, US 7,386,238, US 7,480,462.
   URL: https://patents.google.com/patent/WO2002015438A1/en
4. The Google Patents "H04L 12" sitemap confirms the 10/11/2005 grant date.

⚠️ Do not treat references cited within WO 2002/015438 A1 (e.g., US 6,078,806 to Nokia; US 5,852,664 to Intel; US 5,845,282 to Apple; US 5,831,664 to MediaOne; US 6,278,499 to Evolve Products; US 6,292,283 to LSI Logic) as prior art of '893. Those are that separate application's citations. Conflating them would be exactly the "similar number / similar document" error your instructions warn against.

E. § 102 framework keyed to '893's own claim families

From the earlier section, the independent claims fall into five families. Here is where the real § 102 risk lies, so you can map the true citation list onto it once retrieved:

• Family (a)/(d) — transmitter apparatus & method (parse → frame → checksum → embed in integrity element → transmit). The potentially anticipating art is the general body of block/segment checksum error-detection (e.g., CRC/Hamming-on-a-block, packet checksum schemes) combined with any teaching of embedding the check value in a markup/self-describing wrapper. The novelty pressure point is the "integrity element encapsulates the frame" limitation — plain block-checksum art may hit the checksum step but not the encapsulation step.
• Family (b)/(e) — receiver apparatus & method (detect → separate → recompute → compare → validate). Potentially anticipated by any store-and-forward receiver that recomputes a checksum over a received frame and compares — very broad prior art. The distinguishing limitation is again the XML-element wrapper as the carrier of the check value.
• Family (c) — method of utilizing executable code in a source device. Anticipation would require art teaching a software/broadcast layer that parses data into frames, computes a per-frame checksum, and hands a wrapped broadcast signal to a transmitter — i.e., a software-plus-protocol combination; the ceiling here is whether the art is in a unidirectional (no-ACK) environment.
• Dependent aspects (per spec): window-size / operator / seed header fields; timestamp/"time element"; banner/service/context XML element types. These are narrow and readily met by generic checksum-header/parameter-field art or by generic XML messaging art.

The likely hardest limitation for an anticipator to meet is the XML integrity element that encapsulates the payload frame — generic checksumming is ancient, but checksum-as-XML-wrapper for unacknowledged one-way IR to a PDA is the specific 2000-era contribution.

F. How to get the authoritative answer (recommended, ranked)

Because the front page is the only place the true prior-art list lives, retrieve it directly:

1. USPTO Patent Center / Patent Public Search (ppubs.uspto.gov) — open US 6,954,893; the "References Cited" and "Referenced By" tabs are USPTO-official. This is the literal "USPTO database" source your instruction names.
2. USPTO Patent Full-Text (patft / patft.uspto.gov legacy) front-page "References Cited" field.
3. The granted patent PDF front page via patentimages (Google) — the citation tables are printed there.
4. Google Patents → US6954893B2 → "Patent Citations" (backward) and "Cited By" (forward) tables.
5. FreePatentsOnline entry for US6954893 (the FPO page for the pre-grant US2002/0023249A1 is confirmed reachable).

If you can paste the front-page "References Cited" list (or grant me a fresh tool budget), I will produce the full per-reference deliverable you specified: full citation, publication/filing date, brief description, and the specific claim(s) each reference could anticipate under 35 U.S.C. § 102(b) (pre-2000-08-15 publications) or § 102(e) (earlier-filed, later-published U.S. applications), with § 103 combinations flagged separately.

G. Bottom line

• US 6,954,893 is confirmed to exist exactly as numbered and was verified against live sources; there is no similar-number substitution in this analysis (e.g., US 6,945,933 and the "'489" pharma patents previously surfaced are different patents and are excluded).
• Its backward prior-art citations were not obtainable in this session, and I will not manufacture them.
• The only prior art the specification itself engages is the IrDA standard, the diffuse optical communication protocol, and the generic GPS / RF-ranging / cellular / Bluetooth / wireless-Ethernet context and transport technologies — with IrDA the most on-point.
• Forward citations of '893 are verified (US 9,591,692; WO 2007/054775 A3; WO 2002/015438 A1) but are legally irrelevant to § 102 against '893.

The honest answer to "which claims each cited reference potentially anticipates" is: not determinable from the evidence available to me — I can supply that analysis the moment the front-page citation list is provided, and I'd rather return a flagged gap than a fabricated reference table.

I'll gather the prior-art references associated with this patent before analyzing.

Let me try to identify the specific references cited on the face of this patent.

Obviousness Analysis — U.S. Patent No. 6,954,893 under 35 U.S.C. § 103

0. Threshold caveats (read first)

Two record limitations materially affect this analysis, and I want to flag them rather than paper over them:

1. The "Prior Art" / "References Cited" section of the page was not included in the authoritative text supplied to me. The full text I received runs from the title through the "Summary of the Invention" and then the Detailed Description, but it contains no "References Cited" list, no "Cited By" list, and no examiner's PTO-892 form. I therefore cannot map claims to the specific references the examiner actually considered. What follows is grounded in (a) the references that appear in the specification's own background, (b) the single examiner-cited item that surfaced in search ("John Cox, WideRay Beams Data to Handhelds, Network World, May 27, 2002"), and (c) prior art I could date in the relevant fields from live search. Any reference I have not independently verified is flagged as such.
2. The literal claim language was never retrieved (this was flagged in the previously generated Patent summary section and remains true). The claim families below are reconstructed from the patent's own "Summary of the Invention." Because every independent claim appears to be drafted in means-plus-function form, claim construction under §112(f) will be driven by the corresponding structures disclosed in the specification — which actually helps an obviousness analysis, because it narrows the claim scope to the disclosed algorithms.

One corollary: the Cox Network World article is dated May 27, 2002 — after both the 2000-08-15 priority date and the 2001-08-15 filing date. It is not §102/§103 prior art; it functions only as background/evidence of the state of the art, if anything. Any §103 ground built on Cox alone fails on date.

1. The claim families at issue

Carried forward from the earlier sections (not repeated): five families — (a) transmitter apparatus, (b) receiver apparatus, (c) "utilizing executable code in a source device" method/computer-program-product, (d) method of creating a data signal at a source device, (e) method of receiving/utilizing a data signal.

Reduced to their actual technical content, all five families recite some permutation of the same six steps:

Everything else (banner/service/context elements, gated 20 ms/980 ms transmission, service objects) is either described as optional/environmental or belongs to the sibling applications, not to the '893 claims.

2. The relevant prior-art landscape

2.1 In-field art identified

2.2 Level of ordinary skill

A POSITA here would be a communications/software engineer with a bachelor's degree and ~2 years' experience in wireless data networking and frame protocols, familiar with: framing + FCS/CRC error detection, the IrDA stack, and markup-language parsing. That skill level is high enough that "wrap a block in an element that carries its checksum" reads as routine — which is the central tension in this analysis.

3. Element-by-element mapping and proposed combinations

Ground 1 — Ellenby (WO 99/49668) in view of the IrDA/HDLC framing-and-CRC art

• E5 (unidirectional wireless broadcast to a constrained receiver): Ellenby. Its receivers "do not require remote receive units to have any transmission function whatever." Ellenby even ties content to receiver physical state (position/orientation/time) — the same locational context premise the '893 specification uses.
• E1 + E2 (framing with a check computed over the frame): IrDA physical layer / HDLC, both admitted as known in the '893 specification. Even the patent concedes the physical layer "handles the beginning of frame (BOF), end of frame (EOF) flags, and cyclic redundancy checks (CRCs)."

Motivation to combine: Ellenby itself explains why reliable one-way delivery is hard — there is no up-link and therefore no ACK. A POSITA confronted with Ellenby's no-return-link system would have an express design need (error detection without retransmission) and would reach for the single most standard tool for exactly that: a per-frame check sequence. This is KSR predictable use of a known technique to address the very deficiency the primary reference identifies, with no change in the references' operation.

Gap: this combination yields E1, E2, E5, E6 but not necessarily the markup-encapsulated "integrity element" of E3/E4.

Ground 2 — Ground 1 further in view of XML 1.0 + MIME/HTTP Content-MD5

• E3 + E4 (integrity metadata embedded in an enclosing element that wraps the payload): Once the POSITA has selected XML for the downlink (a design choice the '893 specification treats as motivated by parsers already present on handhelds), placing integrity metadata in a wrapper element enclosing the protected content is the natural XML idiom — it is precisely the same idea already implemented in MIME's and HTTP's content-integrity fields, and it is the only tidy way to scope a check to a block in a nested-markup document.

Motivation: Improve a known device (an XML-based broadcast) using a known technique (integrity field adjacent to protected content) in the same way, yielding no more than predictable results. Under KSR, "the combination of familiar elements according to known methods is likely to be obvious when it does no more than yield predictable results." A POSITA choosing markup would also want to avoid inventing a bespoke binary sidecar when attributes/elements are available for free.

Strongest counter to this ground: at the 2000 priority date, was embedding a checksum in markup actually a "familiar" combination, or did the field still treat integrity as a link-layer/binary concern? I am not confident there is a single pre-2000 reference squarely holding "checksum carried in an enclosing XML element." MIME Content-MD5 (1996) is close but is a MIME header, not an element wrapping the content. That gap is where the patent's best non-obviousness argument lives.

Ground 3 — Nilsen (US 5,703,562) in view of HDLC/IrDA framing, optionally with Ellenby

• E5 + the "no acknowledgement possible" problem: Nilsen's data diode is a one-way transfer in which the receiving side cannot talk back.
• E1–E4, E6: HDLC/IrDA framing + CRC gives the framing, the check, and the receiver-side recompute/compare.

This ground is essentially Ground 1 with a different primary and is weaker on the wireless handheld broadcast aspect (Nilsen is wired/secured-networks), so I would run it as a secondary/backup theory rather than lead.

Ground 4 — Reiss, Nokia multiple-checksum art, etc.

I saw several superficially similar "multiple-checksum-protected data packet" references in search (e.g., Nokia's US 7,161,960). These post-date the '893 priority date and are not prior art. I am explicitly excluding them rather than misreading the dates. Similarly, the many IPR petitions that surfaced (Corke/Swanson/Chikama around optical transceivers; Bloch/802.3/Peguiron) are unrelated subject matter and unrelated patents — they appear only because of keyword collision, not relevance.

4. Dependent-claim considerations

Per the specification (not confirmed as issued), dependent claims likely add:

• the explicit compare-and-if-match-validate step — squarely met by HDLC/IrDA CRC comparison; this is the most vulnerable dependent claim.
• window size 408 / operator 410 / seed 412 fields in the integrity element header — these are just a parameterized checksum descriptor. Variable-length/location checksum descriptors with length and type fields were known (e.g., the length-field/checksum-type-field/checksum-value-field pattern later claimed in Nokia's art, if an earlier equivalent exists). A POSITA would add size, operator, and seed fields as ordinary design choices to make a checksum algorithm-selective — predictable variation of a known element.
• a "time element"/timestamp for temporal context — Ellenby expressly organizes content by time references at the receiver, so a timestamp field is taught by Ellenby and would have been obvious to include given the '893's own stated purpose (temporal context).
• XML banner/service/context element types — these are application-layer content taxonomies, largely the subject matter of the sibling applications (09/929,979; 09/929,995), and are unlikely to carry independent patentable weight over the integrity-element concept.

Bottom line on dependents: the more the dependents descend into "compare the checksums and validate on match," the more clearly obvious they are. The dependents most likely to survive a §103 challenge are those reciting the specific combination of the wrapping-element framing plus the window-size/operator/seed descriptor plus the unidirectional broadcast context as a single integrated structure.

5. Secondary considerations / rebuttal analysis

The record contains no objective indicia I could verify — no evidence of unexpected results, no licensing program, no copying, no long-felt need, no commercial success tied to the '893 claims. Some considerations weigh against obviousness and should be stated fairly:

• No litigation history. As established earlier, no district court, ITC, PTAB, or Federal Circuit proceeding involving the '893 patent could be found, and the patent expired fee-related on 2022-10-26. There is therefore no adjudicated validity finding for or against, and an "industry respect" narrative cannot be constructed.
• The examiner recorded only one NPL citation ("Cox") that I could confirm, and it is post-dating — suggesting the examiner did not locate a close pre-2000 markup-integrity reference either. That cuts mildly toward non-obviousness (the art was not obviously at hand).
• The encapsulation limitation (integrity element placed around the frame) is the one element that is not squarely met by MIME-header art, because a MIME header labels rather than encloses. If any claim was going to survive, it would be on the strength of the enclosing structure being non-routine at the time.

6. Conclusion

My assessment: Claims (b) and (e) — and every dependent claim reciting only "compute a second checksum, compare, and validate on match" — are likely obvious over the unidirectional-broadcast art (Ellenby; Nilsen) combined with the standard framing/CRC art, because the '893 specification admits BOF/EOF framing and CRCs as pre-existing in the IrDA physical layer it builds upon, and the unidirectional-broadcast-without-up-link premise is squarely in Ellenby. Claims (a), (c), and (d) turn on the markup-encapsulated integrity element (E3/E4); those are moderately vulnerable — a strong KSR case can be made (XML idiom + MIME/HTTP content-integrity fields = predictable combination), but I could not locate a pre-2000 reference that squarely teaches a checksum-carrying element enclosing its own payload, and the absence of any adjudication means this is an open question, not a settled one.

Confidence and what would change the answer. My confidence in the claim mapping is moderate (reconstructed from the Summary, not the issued claims). My confidence in the reference dates for Ellenby (1999-09-30), Nilsen (1997-12-30), IrDA 1.0 (1994), and XML 1.0 (1998) is high. My confidence that this is the complete set of relevant art is low, for one specific reason: I was not given the "References Cited" / PTO-892 section of the page, and I could not load a primary source (Google Patents' own cited-references list, or the FPO/Justia "Referenced Cited" tables) to enumerate the examiner's actual references. If the omitted Prior Art section contains a pre-2000 reference disclosing markup-based integrity wrapping, the analysis above shifts sharply from "moderate" to "clearly obvious" for all five families. To close that gap definitively, retrieve: (i) the "References Cited" list from the granted patent front page, and (ii) the file wrapper / PTO-892 from USPTO Patent Center for application 09/930,004.