US 7266682

I'll verify the current status of US 7,266,682 through live searches before summarizing.

Let me check the CAFC appeal docket 25-1414 and any 2026 developments.

Let me search specifically for the Federal Circuit docket 25-1414 and the IPR certificate outcome.

US Patent 7,266,682 — Summary

Important caveat up front: I was able to retrieve the patent's full text (Google Patents, fetched 2026‑09‑26) and locate the PTAB/CAFC records below, but my tool budget ran out before I could pull the full text of the Federal Circuit order or the IPR certificate. Where I could not confirm something directly, I flag it explicitly.

Bibliographic data

Source: https://patents.google.com/patent/US7266682/en

Abstract

"Data from a transmitter is extended to include authentication data on the application level by an application protocol. The authentication data is used by the receiver to determine whether the transmitter is known by the receiver. If the transmitter is known by the receiver, the data is accepted. If not, the data is rejected."

Plain‑language overview of the independent claims

Note: the granted claims are appreciably narrower than the claims in the published application (US 2003/0005284, whose claim 1 was a generic "extend the data by authentication data using an application protocol on the application layer"). The granted claims are specifically tied to the RTP packet level and to a MAC over the RTP header's sequence number/timestamp.

• Claim 1 (method): The transmitter adds authentication data to the end of the entire RTP packet payload, operating at the RTP packet level as the application‑layer protocol. The receiver uses that RTP‑level authentication data to decide whether it "knows" the transmitter. If yes, it accepts the whole RTP packet payload; if no, it rejects the whole payload. Essentially: per‑packet, packet‑level sender authentication used as a filter to drop traffic from unknown senders.

• Claim 25 (system): A transmitter + receiver. The transmitter inserts authentication data at the end of the whole RTP packet payload. The receiver decides "known/unknown" from the RTP‑level authentication data and accepts or rejects the whole payload. Additional structure: the payload header contains a sequence number and/or timestamp; insertion is done by generating a MAC from a common secret shared by transmitter and receiver, computed over the header sequence number and timestamp, and appending that MAC to the end of the payload. If the receiver's recomputed MAC equals the MAC in the received packet, the receiver accepts the RTP packet.

• Claim 26 (transmitter apparatus): Same RTP‑level insertion concept from the sender side — a processor inserts authentication data at the end of the whole RTP packet payload, generating a MAC from a common secret using the RTP header's sequence number and timestamp, and appending it; the transmitter then sends the payload including the authentication data.

• Claim 27 (receiver apparatus): A processing unit that determines whether the transmitter is known, based on RTP‑level authentication data appended at the end of the whole RTP packet payload, and accepts or rejects the whole payload accordingly. The processing unit obtains the appended authentication data by generating the MAC from the common secret using the RTP header sequence number and timestamp.

• Claim 28 (method): The method counterpart to claim 25 — RTP‑level insertion of authentication data at the end of the whole payload, "known/unknown transmitter" decision at the receiver, whole‑payload accept/reject, MAC generated from a common secret over the header sequence number and timestamp, appended at payload end, with acceptance when the receiver's MAC matches.

Dependent claims 2–24 add limitations such as: packet‑oriented transmission; deriving authentication data by linking part of the application‑layer PDU to a secret; symmetric key vs. asymmetric key pair; sequence number and/or timestamp; one‑way hash function or MAC with a key known only to transmitter and receiver; cryptographic verification (decryption and/or checksum check); pre‑transmission mutual authentication; use in Internet telephony, packet‑switched telephone services, and in switching nodes/switching installations. (Claims 6 and 7 appear as textual duplicates in the granted text.)

The specification supports this with an OSI‑layer discussion (FIGS. 1–3) and FIG. 4 showing an RTP packet 401 with RTP header 406 (sequence number 402, timestamp 403), encrypted media data 404, and authentication data/MAC field 405.

Litigation and PTAB posture (verified via search)

• IPR2023‑00923 — Petitioner: Meta Platforms, Inc., Instagram, Inc., WhatsApp LLC, Meta Platforms Technologies, LLC, and GIPHY, Inc., against Patent Owner VL Collective IP LLC. Filed 2023‑05‑24; institution granted 2023‑12‑06 (Director Review denied 2024‑01‑17); oral argument 2024‑09‑10; Final Written Decision terminating 2024‑12‑05 finding claims 1–28 unpatentable. Grounds included 35 U.S.C. §103(a) combinations of Handley/Basturk, PacketCable/Handley, and PacketCable/Basturk.

  • FWD PDF: http://cdn.patentlyo.com/media/2025/04/IPR2023-00923-FWD.pdf
  • Docket: https://ipverse.greyb.com/ptab-web/cases/case-details/IPR2023-00923

• IPR certificate — Google Patents shows an "INTER PARTES REVIEW CERTIFICATE," kind code K1, issued 2025‑08‑18 (trial no. IPR2023‑00923). Given the FWD found all claims 1–28 unpatentable, a certificate would ordinarily cancel all claims — but I could not retrieve the certificate text itself, so I cannot state definitively from primary source that all 28 claims are cancelled. Treat this as a high‑confidence inference, not a confirmed quote.

• CAFC docket 25‑1414 — VL Collective IP, LLC v. Meta Platforms, Inc. (origin: PTO; i.e., the appeal from IPR2023‑00923). A nonprecedential order posted 2025‑08‑07 is on the Federal Circuit site: https://www.cafc.uscourts.gov/08-07-2025-25-1414-vl-collective-ip-llc-v-meta-platforms-inc-order-25-1414-order-8-7-2025_2555311/. I could not retrieve the order's operative text, so I cannot confirm whether it dismissed the appeal, remanded, or affirmed. The timing (order in Aug 2025, certificate issuing 2025‑08‑18) is consistent with the appeal being resolved/ended before the certificate issued, but that is an inference.

• District court litigations (per the FWD and Google Patents): VideoLabs, Inc. v. Meta Platforms, Inc., No. 1‑22‑cv‑00680 (D. Del.), filed 2022‑05‑24; VideoLabs Inc. v. Amazon.com Inc., No. 6‑22‑cv‑01167 (W.D. Tex.) (completed); and a W.D. Tex. case, No. 6:22‑cv‑00079. Unified Patents' Patroll page also notes the patent "has been asserted against Amazon, Facebook, and Instagram."

What I could NOT confirm (2026 dockets and current status)

Per your specific instruction to look at CAFC 2026 dockets for this patent: I found no 2026 Federal Circuit decision or docket activity for US 7,266,682 specifically. The 2026 CAFC activity I did surface involves different VideoLabs/VL Collective patents — e.g., No. 24‑1890 (VL Collective IP, LLC v. Unified Patents, LLC, decided 2026‑02‑20, re US 8,605,794) and No. 25‑1132 (VL Collective IP, LLC v. Netflix, Inc., decided 2026‑08‑10, re US 7,440,559). Do not attribute those outcomes to 7,266,682. If a 2026 docket exists for '682, it did not appear in my searches, and I will not guess at its number or status.

Bottom line: US 7,266,682 is a Siemens-originated Euchner patent on per‑packet RTP‑level sender authentication using a MAC over the RTP sequence number/timestamp, now held by VL Collective IP LLC, whose claims were all held unpatentable in IPR2023‑00923 (FWD 2024‑12‑05), with a K1 IPR certificate issued 2025‑08‑18 and a related nonprecedential CAFC order in No. 25‑1414 posted 2025‑08‑07. The primary uncertainty is the exact disposition of the 25‑1414 appeal and the precise cancellation scope recited in the certificate — both of which you should confirm against the primary documents.

I'll research the litigation history for US patent 7266682, starting with the specific sources you mentioned.

Let me dig into the specific district court cases and the Federal Circuit appeal mentioned in the patent record.

Let me verify the current status of the district court cases and check for any additional defendants or appeals.

Litigation Involving U.S. Patent No. 7,266,682

I searched Unified Patents' litigation/PTAB portals, CourtListener/RECAP, Justia's Federal Circuit archive, and the Federal Circuit's own docket, using the exact number 7,266,682. Here is what I found. Note that the patent's asserted owner throughout is the VideoLabs / VL Collective IP family (original assignee Siemens AG; the current assignee of record is VL Collective IP LLC / VL IP Holdings LLC), and the record reflects litigation over this number only — I did not include unrelated hits (e.g., the Brazilian registry entry "7266682," Japanese JP7266682B2 for cosmetic packaging, or the Fed. Cir. 24-1890/25-1132 appeals, which concern other VideoLabs patents, not the '682 patent).

1. VideoLabs, Inc. & VL Collective IP LLC v. Amazon.com, Inc. & Amazon Web Services, Inc.

• Plaintiff(s): VideoLabs, Inc. and VL Collective IP LLC
• Defendant(s): Amazon.com, Inc. and Amazon Web Services, Inc.
• Jurisdiction: U.S. District Court for the Western District of Texas, Waco Division
• Case No.: 6:22-cv-00079 (full caption "6:22-cv-00079-ADA-DTG"; Judge Alan D. Albright)
• Filing date: March 2022 (reported March 17, 2022)
• Asserted patents: The '682 patent was one of seven asserted in this action — U.S. Patent Nos. 6,880,156; 7,266,682; 7,440,559; 7,769,238; 7,970,059; 8,139,878; and 8,605,794.
• Status/outcome: The case progressed at least through claim construction (a Joint Claim Construction Statement referencing the '682 patent's "application layer" term was filed and a scheduling order entered). I could not confirm a final disposition for this docket from the sources available to me, so I will not represent one. Treat the outcome as unverified rather than as dismissed or decided.

Source: W.D. Tex. Joint Claim Construction Statement, VideoLabs, Inc. and VL Collective IP LLC v. Amazon.com, Inc. and Amazon Web Services, Inc., No. 6:22-cv-00079-ADA-DTG (via PTAB exhibit); Mondaq, "Patent Collective Turned Plaintiff VideoLabs Expands Campaign, Sues Amazon" (Mar. 17, 2022); Unified Patents litigation portal, case 6:22-cv-00079.

2. VideoLabs, Inc. & VL Collective IP LLC v. Meta Platforms, Inc. et al. (D. Del.)

• Plaintiff(s): VideoLabs, Inc. and VL Collective IP LLC
• Defendant(s): Meta Platforms, Inc.; Instagram, Inc.; WhatsApp LLC; Facebook Technologies, LLC; and Giphy, Inc.
• Jurisdiction: U.S. District Court for the District of Delaware
• Case No.: 1:22-cv-00680 (Judge Joel H. Slomsky, "1:22-cv-00680-JHS")
• Filing date: May 24, 2022
• Asserted patents: Five asserted, including 7,266,682 (along with 7,769,238; 8,139,878; 7,970,059; and 7,436,980).
• Status/outcome: Resolved. A partial motion to dismiss was litigated in 2022–2024, and the docket reflects an order dated October 3, 2025 (Judge Slomsky) providing that "VideoLabs' claims for relief against Meta are DISMISSED WITH PREJUDICE and Meta's claims for relief against VideoLabs are DISMISSED WITHOUT PREJUDICE" — i.e., a disposition consistent with a settlement/consent resolution.

Sources: D. Del. Complaint, No. 1:22-cv-00680 (via Unified Patents litigation portal and ex parte.ai); CourtListener D. Del. RECAP (Case 1:22-cv-00680-JHS, Doc. 35); D. Del. opinion in related 22-229.

Related but NOT the '682 patent: VideoLabs also sued Netflix (D. Del., No. 1:22-cv-00229) and Starz, but those complaints asserted different patents (e.g., '790, '559, '794) — not 7,266,682.

3. PTAB Inter Partes Review — Meta Platforms, Inc. et al. v. VL Collective IP LLC

• Proceeding: IPR2023-00923 (Patent 7,266,682; Application 10/181,564; Tech Center 2100)
• Petitioner(s): Meta Platforms, Inc.; Instagram, Inc.; WhatsApp LLC; Meta Platforms Technologies, LLC; and Giphy, Inc.
• Patent Owner: VL Collective IP LLC (VideoLabs)
• Filing date: May 24, 2023
• Outcome: Institution granted December 6, 2023; Final Written Decision (35 U.S.C. § 318(a)) holding all challenged claims unpatentable, terminating December 5, 2024. An IPR certificate (K1) issued August 18, 2025 (trial IPR2023-00923).

Sources: Unified Patents PTAB portal, IPR2023-00923; GreyB/IPVerse case detail for IPR2023-00923; Google Patents legal-events record for US7266682B2.

4. Federal Circuit Appeal — VL Collective IP, LLC v. Meta Platforms, Inc.

• Appellant: VL Collective IP, LLC (Patent Owner)
• Appellee: Meta Platforms, Inc.
• Court: U.S. Court of Appeals for the Federal Circuit
• Appeal No.: 25-1414 (origin: PTO — appeal from IPR2023-00923)
• Status/outcome: Appeal dismissed by order dated August 7, 2025 (nonprecedential order). Patent Owner had filed its Notice of Appeal on February 3, 2025.

Sources: Fed. Cir. docket/order for 25-1414 (cafc.uscourts.gov, posted Aug. 7, 2025); GreyB/IPVerse IPR2023-00923 docket entry ("Fed. Cir. Order Dismissing Appeal," Aug. 7, 2025).

Supporting / contextual items (not separate cases)

• PATROLL prior-art contest (Unified Patents): A $2,000 contest seeking prior art on at least claim 1 of US-7266682-B2, running Feb. 24 – May 15, 2023. Unified's own description states the '682 patent "has been asserted against Amazon, Facebook, and Instagram," which aligns exactly with the two district court suits above. (https://patroll.unifiedpatents.com/contests/c6X3zpSKy8eL2366B)
• IPR2023-00924 is referenced only as a parallel proceeding in the same PTAB papers; I did not confirm it targets the '682 patent itself, so I am flagging it rather than attributing it.
• Patent status: The '682 patent expired (adjusted expiration) on November 11, 2022, and the PTAB final written decision + IPR certificate effectively cancelled the challenged claims, which explains the subsequent dismissal of the remaining district court claims.

Summary of known matters touching 7,266,682

If you need the Amazon (6:22-cv-00079) final disposition confirmed, the authoritative sources would be PACER for the W.D. Tex. docket and/or a CourtListener/RECAP pull for that case number; I was unable to confirm it within this session and did not want to guess.

Caveat: I interpreted the identifiers literally as given. Where search results were ambiguous, I flagged them rather than auto-correcting. Litigation records change frequently; verify against PACER/PTAB before relying on any status.

I'll start by reconciling the structured "no PTAB activity" block against the events embedded in the patent record, then search for claim-level outcomes.

Key finding: there is an IPR on file (IPR2023-00923), despite the "no PTAB activity" block. Let me get the panel, claim-level outcome, and appeal details.

Let me pull the FWD text, the panel composition, and the 25-1414 order disposition.

PTAB Activity on US 7,266,682 ("Method and system for transmitting data from a transmitter to a receiver and transmitter and receiver therefor")

⚠️ Source-conflict flag (read first). The structured "PTAB proceedings on file" block states the ODP API returns no AIA trial proceedings for this patent. That block is stale/incorrect. The patent's own Google Patents record (the authoritative text supplied above) shows a PTAB case — IPR2023-00923 — an entry for "PTAB case IPR2023-00923 filed (Final Written Decision)," and a 2025-08-18 Inter Partes Review Certificate (docket event dated 2025-08-26). Public sources confirm the proceeding and its outcome. I report the proceeding below rather than the empty default, per the instruction to flag proceedings the ODP ingest hasn't captured.

Second flag: Google Patents links this case to the Unified Patents portal (portal.unifiedpatents.com/ptab/case/IPR2023-00923). That is only a docket-data source link — the petitioner is Meta Platforms, Inc. et al., not Unified Patents. There is no defensive aggregator in the filing chain. Do not assume Unified Patents is footing any defense.

Proceedings overview

There is one (1) AIA trial proceeding on file for US 7,266,682: IPR2023-00923, instituted and decided against the patent owner — all 28 challenged claims (1–28) were held unpatentable, the Federal Circuit appeal was dismissed on 2025-08-07, and an Inter Partes Review Certificate issued 2025-08-18 canceling the claims. Status breakdown: active 0 / claims invalidated (all claims) 1 / claims sustained 0 / settled 0 / institution denied 0. Bottom line for a defendant: there is no live claim left to assert — a demand letter citing claim 1, claim 25, claim 28, or any dependent claim is asserting a canceled claim, and any infringement suit built on it is vulnerable to immediate dismissal.

IPR2023-00923 — Meta Platforms, Inc.; Instagram, Inc.; WhatsApp LLC; Meta Platforms Technologies, LLC; and GIPHY, Inc. v. VL Collective IP LLC

• Type: Inter Partes Review (35 U.S.C. §§ 311–319)

• Filed: 2023-05-24

• Status: Final Written Decision — all challenged claims unpatentable (PTAB docket: "Determining All Challenged Claims Unpatentable 35 U.S.C. § 318(a)," 2024-12-05), terminated 2024-12-05; IPR certificate issued 2025-08-18.

• Judge panel: The panel included Administrative Patent Judge McKone, who dissented-in-part (on the public-accessibility of the asserted prior art and on the grant of Petitioner's motion to submit supplemental information). I could not confirm the remaining APJ names from the sources retrieved; I am not filling them in speculatively. Supervisory Trial Paralegal on the related papers: Eric W. Hawthorne.

• Parties / RPI: Petitioner RPI: Meta Platforms, Inc.; Instagram, Inc.; WhatsApp LLC; Meta Platforms Technologies, LLC; GIPHY, Inc. Patent Owner: VL Collective IP LLC (RPI: VL Collective, VL IP Holdings LLC, and VideoLabs, Inc.). Petitioner counsel: W. Todd Baker, Ellisen Turner, Jonathan Brit (Kirkland & Ellis LLP). Patent Owner counsel: Christine Lehman, Philip Eklem, Michael Matulewicz-Crowley, Jaime Cardenas-Navia (Reichman Jorgensen Lehman & Feldberg LLP).

• Petition grounds (all under pre-AIA § 103(a); 28 claims challenged):

  Claims challenged	Basis	References
  1–21, 23, 25–28	§ 103(a)	Handley + Basturk
  1–28	§ 103(a)	PacketCable + Handley
  1–28	§ 103(a)	PacketCable + Basturk
  22, 24	§ 103(a)	Handley + Basturk + PacketCable

  Key references: EX1005 — M. Handley, J. Crowcroft, C. Bormann, Very Large Conferences on the Internet: The Internet Multimedia Conferencing Architecture and the MBONE; EX1007 — PacketCable 1.0 Architecture Framework Technical Report, CableLabs, Dec. 1, 1999.

• Institution decision: Instituted on 2023-12-06 (Institution Decision: Grant). Patent Owner sought Director Review of the institution decision; denied 2024-01-17. A significant threshold fight ran in parallel: whether Handley (EX1005) and PacketCable (EX1007) qualified as printed publications under Hulu v. Sound View. On 2023-10-05 the Board authorized only a 3-page Reply on that issue and denied Petitioner's request to submit supplemental evidence for lack of good cause; Patent Owner moved to strike the Reply as containing new evidence. The Board later granted Petitioner's motion to submit supplemental information (Order, 2024-03-28; erratum 2024-04-02), over Judge McKone's dissent-in-part, and the FWD majority relied on a Hall-Ellis librarian declaration (EX1019) plus the CableLabs website to find PacketCable publicly accessible as of Dec. 1, 1999.

• Final Written Decision (2024-12-05): All 28 challenged claims — claims 1–28 — held unpatentable. The FWD's dispositive ground was claims 1–28 obvious over PacketCable in combination with Handley, with the Board stating (in its "Analysis" of PacketCable): "We disagree with Patent Owner's contention that neither the CableLabs website nor the testimony of Dr. Hall-Ellis shows that PacketCable was publicly accessible in 1999." On the merits of the core limitation, the majority reasoned: "we disagree with Patent Owner's contention that inserting information at a lower layer does not satisfy the claim's req[uirement]." No claim was held patentable. The dissent (McKone, APJ) would have found the Petition's showing on Handley as a printed publication insufficient and would have excluded most of the supplemental exhibits: "For the reasons given in my Dissent to the Institution Decision, I would not find that Petitioner made a sufficient showing in the Petition that Handley was a printed publication and prior art to the '682 patent." The dissent also flagged that Petitioner, in the majority's view, effectively substituted a different document (EX1028) for Handley as the thing published in Computer Networks.

• Settlement / termination: No settlement. The proceeding ran to a merits FWD (no adverse judgment, no termination-by-agreement).

• Appeal: Yes — by Patent Owner. Notice of Appeal filed 2025-02-03; docketed at the Federal Circuit as VL Collective IP, LLC v. Meta Platforms, Inc., No. 2025-1414. The Federal Circuit dismissed the appeal by nonprecedential order entered 2025-08-07 (no merits opinion). The PTAB docket entry reads "Fed. Cir. Order Dismissing Appeal." No claim was revived or narrowed on appeal; the FWD's cancellation stands. The Inter Partes Review Certificate issued 2025-08-18 (record event 2025-08-26, code K1), confirming cancellation of claims 1–28. (Note: the parallel appeal 2025-1415, from IPR2023-00924 on U.S. 7,436,980 — a different patent — was likewise voluntarily dismissed 2025-08-11; that appeal and a Giphy appeal in No. 2025-1454 are not proceedings on the '682 patent.)

• Defensive value: Decisive. Every claim of the '682 patent — including independent claims 1, 25, 26, 27, and 28 and all dependents — has been canceled by a final, unappealable IPR. Any demand letter or complaint asserting the '682 patent is asserting canceled claims; a defendant should treat such an assertion as a Rule 11 / § 285 exposure issue for the plaintiff, not as a validity defense problem.

Strategic summary

Claim status — all claims CANCELED, nothing SUSTAINED, nothing UNTESTED. Claims 1–28 of US 7,266,682 were all held unpatentable in the 2024-12-05 Final Written Decision in IPR2023-00923, the appeal was dismissed 2025-08-07, and the IPR certificate issued 2025-08-18. Unlike a typical "narrowed but surviving" IPR outcome, there is no surviving claim to assert: independent claims 1, 25, 26, and 27 (the method, system, transmitter, and receiver claims) and claim 28 (second method claim) fell together with every dependent claim, including claims 4/10/14/18 (sequence number/timestamp) and claims 22 and 24 (the switching-node/switching-installation dependents). The only post-IPR disputes remaining are the parallel proceedings on other VideoLabs patents (e.g., IPR2023-00924 on U.S. 7,436,980; and the Netflix '559 appeal affirmed 2026-08-10) — none of which touch the '682 patent.

Estoppel landscape. Because the FWD reached a final written decision, § 315(e)(2) estops the Meta petitioners and their privies (Instagram, WhatsApp, Meta Platforms Technologies, GIPHY, and their real parties-in-interest) from raising in district court, as to claims 1–28, any ground they raised or reasonably could have raised in IPR2023-00923. Practically, that estoppel is now academic: there are no claims left to litigate against anyone, so a current defendant does not need an invalidity theory at all — it needs only the IPR certificate and the FWD's ordering paragraphs. For a defendant considering offensive use of the record rather than estoppel, note the Handley printed-publication weakness the dissent identified (Petitioner's substitution of EX1028 for EX1005, and the Board's reliance on EX1019/the present-day CableLabs site for PacketCable). That weakness is historical only — the majority's finding was never reversed.

Pattern signals. This is a one-IPR patent — the same petitioner did not file multiple IPRs on the '682 patent itself (its second petition, IPR2023-00924, targeted a different patent, U.S. 7,436,980, and was run under consolidated/parallel scheduling). The patent owner (VideoLabs / VL Collective / VL IP Holdings, a monetization entity that acquired the Siemens-origin portfolio through Lough Corrib in 2019, with a Praetor Fund I security interest later released on 2022-12-28) did appeal — it filed a Notice of Appeal rather than accepting the FWD — but the appeal was dismissed without a merits ruling. No defensive aggregator (Unified Patents, RPX, etc.) filed here; the Unified Patents link on Google Patents is docket data only. Litigation context for the '682 patent: VideoLabs v. Meta Platforms, No. 1:22-cv-00680 (D. Del.) and VideoLabs v. Amazon.com, No. 6:22-cv-01167 (W.D. Tex.).

Recommended next steps

If you are a defendant facing an assertion of US 7,266,682:

1. Do not build a validity defense. Cite the disposition instead. The FWD ends: "We determine Petitioner has shown by a preponderance of the evidence that claims 1–28 are unpatentable." FWD (2024-12-05) — see the PTAB decision (Patently-O mirror: http://cdn.patentlyo.com/media/2025/04/IPR2023-00923-FWD.pdf) and the PTAB E2E record for IPR2023-00923 (https://ptacts.uspto.gov/ptacts/public-informations/petitions/[1554037](/patent/1554037)/).
2. Cite the cancellation certificate. The Inter Partes Review Certificate issued 2025-08-18 canceled claims 1–28. That is the operative, dispositive document — attach it to any responsive pleading, motion to dismiss, or § 285 fee motion.
3. Cite the dismissed appeal to foreclose any "the FWD is on appeal" argument: VL Collective IP, LLC v. Meta Platforms, Inc., No. 2025-1414 (Fed. Cir. order entered 2025-08-07) — https://www.cafc.uscourts.gov/08-07-2025-25-1414-vl-collective-ip-llc-v-meta-platforms-inc-order-25-1414-order-8-7-2025_2555311/.
4. Do not concede the neighboring patents. If the assertion bundles the '682 patent with related VideoLabs assets (e.g., U.S. 7,436,980 — the subject of IPR2023-00924), do not assume those had the same fate; the '980-patent appeal was voluntarily dismissed, leaving that patent live. Keep the analysis patent-by-patent.

No active proceedings remain on the '682 patent, so there are no institution-deadline, oral-hearing, or statutory 1-year FWD milestones to track. The only milestone has already passed (certificate issued 2025-08-18).

Characterization caution for the record: don't describe this as "claims narrowed" or "patent survived." It didn't narrow — it was entirely canceled. The one nuance worth knowing (but not worth conceding away) is Judge McKone's dissent on the printed-publication status of Handley/PacketCable, which is the only theoretical crack in the FWD; it was never adopted on appeal, and the appeal was dismissed without a merits ruling, so it gives you no leverage.

I'll research this patent's assignment chain, litigation, and IPR history before drafting.

Assignment & Ownership Analysis — US 7,266,682 B2

Patent: US 7,266,682 B2 — "Method and system for transmitting data from a transmitter to a receiver and transmitter and receiver therefor"
App. No.: 10/181,564 (PCT/DE2001/000021 national phase) | Priority: DE 10001855.6, filed 2000-01-18 | Filed: 2001-01-05 | Issued: 2007-09-04 | Adjusted expiry: 2022-11-11 (expired)

Inventors

• Martin Euchner — sole named inventor. At the time of filing he was employed by Siemens Aktiengesellschaft (Germany). The inventors' rights were assigned to Siemens by a recorded assignment executed 2002-05-29 and recorded 2002-07-18 (Reel 013284/0156; "ASSIGNMENT OF ASSIGNORS INTEREST; ASSIGNOR: EUCHNER, MARTIN"). This is a routine employee invention-assignment, not an inventor departure.

Unusual patterns: None detected. There is no evidence of inventors departing the original assignee within 12 months of filing, nor of any inventor-held residual interest. The ~2-year gap between the German priority filing (2000) and the recorded assignment (2002) is explained by the PCT/national-phase prosecution sequence, not by a dispute.

Original assignee

Siemens Aktiengesellschaft (Munich, Germany). Siemens was, and remains, a large diversified industrial/telecommunications conglomerate. At the relevant time it operated a significant telecoms equipment and Internet-telephony (VoIP) business — the technical field of this patent (RTP-based media transmission with application-layer authentication) was squarely within Siemens' then-active communications business.

• Shipped a product embodying the claims? Not determinable from the record. Siemens was an operating telecom-equipment vendor and worked in the RTP/Internet-telephony space, but no evidence was located that the specific claimed method was commercialized. No product-marketing or licensing evidence is associated with this patent.
• Primary line of business: Diversified industrial, energy, and (at the time) telecommunications equipment.
• Current status: Operating — Siemens AG remains a going concern. No bankruptcy, dissolution, or Chapter 7/11 proceeding is associated with this patent's chain. The 2018 transfer was a portfolio divestiture, not a distressed sale.

Assignment timeline

Note on correspondents: The Assignment Center "correspondent of record" (recording attorney/agent) for each reel/frame is not exposed by the sources retrieved for this analysis — the USPTO Assignment Center reels are indexed by Google Patents only for reel/frame, conveyance, assignor and assignee. I therefore do not state a correspondent name for any reel below, because I could not verify one and will not fabricate it. The recurrence test (Signal 3) is consequently marked unclear and flagged for manual verification at the Assignment Center. (Litigation counsel — not the recording correspondent — is noted separately where relevant.)

• 2002-05-29 (executed) / recorded 2002-07-18 — Reel 013284/0156

  • Conveyance: Assignment (inventor → employer)
  • Assignor: Martin Euchner
  • Assignee: Siemens Aktiengesellschaft
  • Correspondent: Not retrievable from sources at hand — verify at Assignment Center.
  • Context: Routine employee invention assignment to the original assignee.

• 2018-10-24 (executed) / recorded 2019-05-09 — Reel 049125/0070

  • Conveyance: Assignment
  • Assignor: Siemens Aktiengesellschaft
  • Assignee: Lough Corrib Intellectual Property Limited (Ireland)
  • Correspondent: Not retrievable from sources at hand — verify at Assignment Center.
  • Context: Portfolio divestiture — Siemens sells the asset to an Irish IP-holding intermediary (first link in the NPE chain).

• 2019-10-15 (executed) / recorded 2019-10-16 — Reel 050733/0526

  • Conveyance: Assignment
  • Assignor: Lough Corrib Intellectual Property Limited
  • Assignee: VideoLabs, Inc. (California)
  • Correspondent: Not retrievable from sources at hand — verify at Assignment Center.
  • Context: Transfer to the aggregator/licensing platform (VideoLabs, founded 2018–2019, Palo Alto).

• 2019-12-19 (executed) / recorded 2019-12-31 — Reel 051391/0919

  • Conveyance: Assignment
  • Assignor: VideoLabs, Inc.
  • Assignee: VL IP Holdings LLC (Delaware / California)
  • Correspondent: Not retrievable from sources at hand — verify at Assignment Center.
  • Context: Internal reorg into a holding LLC (VL IP Holdings is the parent of VL Collective per PTAB mandatory notices).

• 2019-12-19 (executed) / recorded 2019-12-31 — Reel 051392/0412

  • Conveyance: Assignment
  • Assignor: VL IP Holdings LLC
  • Assignee: VL Collective IP LLC (Delaware / California)
  • Correspondent: Not retrievable from sources at hand — verify at Assignment Center.
  • Context: Internal reorg into the operating assertion LLC — the current record owner of US 7,266,682.

• 2019-12-04 (executed) / recorded 2020-02-07 — Reel 051748/0267

  • Conveyance: Security Interest (not a title transfer)
  • Assignor: VL Collective IP LLC
  • Assignee: Praetor Fund I, a sub-fund of Praetorium Fund I ICAV (New York)
  • Correspondent: Not retrievable from sources at hand — verify at Assignment Center.
  • Context: Securitization / IP-backed financing collateralizing the VL Collective portfolio.

• 2020-03-24 (executed) / recorded 2020-03-31 — Reel 052272/0435

  • Conveyance: Security Interest (not a title transfer)
  • Assignor: VL Collective IP LLC
  • Assignee: Praetor Fund I, a sub-fund of Praetorium Fund I ICAV
  • Correspondent: Not retrievable from sources at hand — verify at Assignment Center.
  • Context: Second/additional securitization filing covering the portfolio.

• 2022-12-28 (executed) / recorded 2023-03-14 — Reel 062977/0325

  • Conveyance: Release by Secured Party
  • Assignor: Praetor Fund I, a sub-fund of Praetorium Fund I ICAV
  • Assignee: VL Collective IP LLC
  • Correspondent: Not retrievable from sources at hand — verify at Assignment Center.
  • Context: Release of the security interest — VL Collective regains unencumbered title.

Chain of title in one line: Euchner → Siemens AG → Lough Corrib IP Ltd (IE) → VideoLabs, Inc. → VL IP Holdings LLC → VL Collective IP LLC (record owner; twice collateralized to Praetor Fund I, then released).

Timeline diagram

timeline
    title Ownership of US 7266682
    2000 : German priority application filed
    2001 : PCT application filed
    2002 : Inventor assigns rights to Siemens
    2007 : Patent issues
    2019 : Siemens assigns to Lough Corrib
         : Lough Corrib assigns to VideoLabs
         : VideoLabs assigns to VL IP Holdings
         : VL IP Holdings assigns to VL Collective
    2020 : Security interest to Praetor Fund
    2022 : Amazon suits filed
    2023 : Security interest released
         : Meta IPR filed
    2024 : All claims held unpatentable
    2025 : IPR certificate issued

NPE / troll-pattern signals

1. Shell-entity transfer — Present. Reel 049125/0070 (Siemens → Lough Corrib IP Ltd), Reel 050733/0526 (→ VideoLabs), Reel 051391/0919 (→ VL IP Holdings LLC), Reel 051392/0412 (→ VL Collective IP LLC). The terminal owners are Delaware "IP/Holdings" LLCs with no products in commerce; VideoLabs publicly describes itself as a "patent aggregation and licensing platform," and its VL Collective arm holds 150+ assets acquired from Siemens, HP, Nokia, Samsung, etc.

2. Known asserter in the chain — Present. The current owner, VL Collective IP LLC / VideoLabs, Inc., is a high-frequency plaintiff surfaced by Unified Patents. Unified filed IPR2022-01086 (06/07/2022) against VL Collective and runs a Patroll prior-art bounty specifically on US-7266682-B2, noting it "has been asserted against Amazon, Facebook, and Instagram." No Unified/RPX filing naming this patent as defensive aggregation by an operating company — the assertion posture is aggrieved-defendant, not license-partner.

3. Repeat correspondent across the chain — Unclear. The recording correspondent for each reel/frame was not retrievable from the sources available, so I cannot confirm or refute a single repeat-player attorney running this chain. This is the one signal that most needs manual checking at the Assignment Center. (Distinct and not dispositive: litigation counsel of record for VL Collective in IPR2023-00923 was Christine Lehman / Reichman Jorgensen Lehman & Feldberg LLP; petitioner Meta used Kirkland & Ellis LLP.)

4. Cascading transfers — Present. Four assignments in ~14 months: executed 2018-10-24 → 2019-10-15 → 2019-12-19 → 2019-12-19, recorded 2019-05-09 → 2019-10-16 → 2019-12-31 (×2) — the final two executed on the same day (Reels 051391/0919 and 051392/0412), i.e., a simultaneous two-step hop through Vídeo→Holdings→Operating LLC. Classic chained-LLC layering.

5. Pre-litigation transfer — Not present (as defined). Transfers executed Oct–Dec 2019; the earliest assertion located (VideoLabs/VL Collective v. Amazon, W.D. Tex. 6:22-cv-00079) was filed January 2022 — roughly 25 months later, well outside the 6-month window. The chain was assembled well in advance of assertion rather than on its eve. (Flag: any earlier assertion not surfaced here would change this.)

6. Bankruptcy fire-sale — Not present. No Chapter 7/11 or insolvency proceeding is associated with Siemens or any intermediate. This was an arm's-length portfolio divestiture, not a distressed sale.

7. Privateering — Unclear / not established. Siemens sold the asset out of its portfolio and appears to retain no continuing economic interest or enforcement role visible in the record; the chain instead runs to a general-purpose licensing platform. No SEC-filing or Patent Progress/EFF evidence of Siemens directing assertion against competitors was located, so this signal is not affirmatively supported.

8. Defensive aggregator (anti-NPE) — Not present. The chain terminates at VL Collective IP LLC, an active asserting entity — not RPX, AST, LOT, Unified, or OIN. Note, however, that PTAB IPR2023-00923 (filed by Meta Platforms/Instagram/WhatsApp/Meta Platforms Technologies/Giphy) issued a Final Written Decision holding all challenged claims unpatentable, and an IPR certificate was issued 2025-08-18, effectively neutralizing the claims notwithstanding the NPE ownership chain.

Verdict

NPE — high confidence.

The ownership chain is a textbook assertion-vehicle structure: Siemens → Lough Corrib IP Ltd → VideoLabs → VL IP Holdings LLC → VL Collective IP LLC (Reels 049125/0070, 050733/0526, 051391/0919, 051392/0412), with the last two hops executed the same day into Delaware IP LLCs that hold no products. The current owner is a self-described patent-aggregation/licensing platform that is a repeat, high-frequency plaintiff (Unified Patents Patroll bounty on this very patent; Unified's IPR2022-01086 against VL Collective), giving two independent strong signals — shell-entity layering (Signal 1) and known asserter (Signal 2) — plus cascading same-day transfers (Signal 4) as support. The only counterweight is that the platform's own claims were cancelled in IPR2023-00923 (certificate issued 2025-08-18), so the asset is effectively neutralized even though the ownership pattern is high-confidence NPE.

Verify at: USPTO Patent Assignment Search — https://assignmentcenter.uspto.gov/ (search US 7,266,682 / app. 10/181,564) and https://assignment.uspto.gov/patent/index.html — specifically to capture the correspondent of record on Reels 049125/0070, 050733/0526, 051391/0919, 051392/0412, 051748/0267, 052272/0435 and 062977/0325, which would resolve Signal 3.

Caveats: The reel/frame numbers, dates, conveyance types, assignors and assignees above are taken from the USPTO legal-events record as reproduced in the authoritative patent text. I did not retrieve the recording correspondents and have deliberately left them blank rather than guess. The litigation/IPR facts (IPR2023-00923, IPR2022-01086, the Amazon W.D. Tex. and D. Del. suits, and the all-claims-unpatentable FWD) are from PTAB/docket/Unified Patents secondary sources and should be confirmed against the primary PTAB record before being relied on.

I'll research US 7266682 and each of its cited references. Let me run searches.

Let me get details on the key cited references and the IPR proceeding.

Prior‑Art Analysis — US 7,266,682 B2

Prepared 26 April 2026 · Sources: Google Patents US7266682B2 (authoritative full text), USPTO/PTAB records, IPR2023‑00923 Final Written Decision, IPR certificate K1

1. Patent identification (USPTO record verified)

Claim architecture relevant to § 102. The granted patent has 28 claims: independent method claim 1, independent system claim 25, independent transmitter claim 26, independent receiver claim 27, and independent method claim 28. The asserted novelty is narrow and specific:

• Claim 1 requires authentication at the Real Time Transport Protocol (RTP) packet level as an application protocol, by inserting authentication data "at end of a whole RTP packet payload"; the receiver ascertains whether it knows the transmitter from that data; and the whole RTP packet payload is accepted or rejected.
• Claims 25–28 add that the RTP header includes a sequence number and/or timestamp, that a MAC is generated from a common secret using the header sequence number and timestamp and appended to the end of the whole RTP packet payload, and that the packet is accepted if the receiver's computed MAC equals the received MAC.
• Dependent claims recite: secret = symmetric key or asymmetric key pair (3, 9, 13, 17); one‑way hash / MAC (5, 11, 15, 19); cryptographic verification by decryption or checksum (6, 7, 16); pre‑transmission authentication (20); Internet telephony (21); packet‑switched telephone services (23); switching node/switching installation (22, 24).

§ 102 caveat. Anticipation requires a single reference disclosing every element of a claim, arranged as claimed. Several references below disclose sub‑combinations (e.g., MACs, application‑level security, RTP payload multiplexing) and are far stronger as § 103 obviousness material than as pure § 102 anticipants. Where I say a reference "potentially anticipates," I mean an examiner/ petitioner could plausibly read it onto the claim; where it plainly omits an element I say so.

2. Prior art cited on the face of the '682 patent

Google Patents lists 13 patent citations and 10 non‑patent citations (some entries duplicated in the raw table). Each is treated below in the order the register presents it.

2.1 US 4,375,097 A — Texas Instruments Incorporated

• Title: Transparent intelligent network for data and voice
• Priority / issue: 2 Jun 1978 / 22 Feb 1983
• Description: Early "intelligent," transparent network for carrying both data and voice traffic. It contributes only the general notion of a network that transports voice/data transparently across layers.
• Potential § 102 mapping: At most the preamble of claims 1 and 28 (transmitting data from a transmitter to a receiver). Discloses nothing of RTP‑level authentication or accept/reject of a whole RTP payload. Weak — background only.

2.2 US 5,345,507 A — International Business Machines Corporation

• Title: Secure message authentication for binary additive stream cipher systems
• Priority / issue: 8 Sep 1993 / 6 Sep 1994
• Description: Message authentication for stream‑cipher systems — i.e., cryptographic checksum / authenticator generation for streamed data.
• Potential § 102 mapping: Bears on the authentication‑data generation elements: claims 2, 5, 8, 11, 15, 19 (linking to a secret; one‑way hash / MAC). It does not disclose placing such data at the end of a whole RTP packet payload, so it is better characterized as § 103 material against the MAC‑type dependent claims than as a § 102 anticipant of claim 1.

2.3 US 6,320,869 B1 — U.S. Philips Corporation

• Title: Telecommunication network with improved access protocol
• Priority / issue: 4 May 1995 / 20 Nov 2001
• Description: Telecom network access‑protocol improvement (connection/access control).
• Potential § 102 mapping: Only the transmitter→receiver transmission preamble of claims 1 / 28 and the network‑node context of claims 22 / 24. No application‑layer/RTP authentication. Weak.

2.4 US 5,602,918 A — Virtual Open Network Environment Corp. (V‑ONE)

• Title: Application level security system and method
• Priority / issue: 22 Dec 1995 / 11 Feb 1997
• Description (from the specification): Establishes secured communications across an unsecured network (the Internet) using smartcard technology, providing mutual authentication of the parties on initial channel establishment and generation of a session key; a gateway processor/firewall controls communications, and "no data is allowed to pass this 'firewall' unless communications are authenticated through the use of a secret key." Uses master/session DES keys and random numbers for mutual authentication.
• Why it matters: This is the closest of the intrinsic citations to the "application level" concept and to the firewall/switching‑entity variant described in the '682 specification.
• Potential § 102 mapping:
  • Claim 1 — could be argued for the "application level" authentication and the receiver testing whether it knows the transmitter (accept/reject of the message). However, it does not disclose RTP‑packet‑level authentication data at the end of a whole RTP packet payload, and its authentication is session establishment, not per‑RTP‑packet.
  • Claims 25, 27 — relevant to the receiver rejecting data from an unknown transmitter before it enters the private network (the '682 firewall teaching).
  • Claim 20 (pre‑transmission authentication between transmitter and receiver) — strongly implicated, since V‑ONE describes mutual authentication at channel establishment.
  • Best characterized as § 103 material for the "application‑level authentication + firewall rejects unknown transmitters" predicate; § 102 anticipation of claim 1 is plausible only under a very broad reading.

2.5 US 5,917,830 A — General Instrument Corporation

• Title: Splicing compressed packetized digital video streams
• Priority / issue: 18 Oct 1996 / 29 Jun 1999
• Description: Splicing of compressed (MPEG‑type) packetized digital video streams — i.e., manipulation of media packets.
• Potential § 102 mapping: Only the media‑data / packetized‑video payload aspects of claims 1, 25, 28 (the "whole RTP packet payload" containing video/audio media data). No authentication. Background only.

2.6 US 6,229,821 B1 — AT&T Corp.

• Title: Serial data transmission of variable length mini packets using statistical multiplexing
• Priority / issue: 22 Apr 1997 / 8 May 2001
• Description: Variable‑length mini‑packet serial transmission with statistical multiplexing.
• Potential § 102 mapping: Concerns the transport of small media packets multiplexed into a larger payload — i.e., the structural context of the RTP payload of claims 1, 25–28. Discloses no per‑packet authentication. Background / § 103 context.

2.7 US 6,396,840 B1 — Nortel Networks Limited

• Title: Method, interface and system for connecting communication traffic across an intermediate network
• Priority / issue: 6 Jun 1997 / 28 May 2002
• Description: Connecting communication traffic across an intermediate network node.
• Potential § 102 mapping: Bears on claims 22 / 24 ("switching node / switching installation") and on the '682 teaching that the "receiver" may be an intermediate switching entity rather than an end receiver. Not an authentication reference.

2.8 / 2.9 / 2.10 US 6,158,011 A; US 6,061,796 A; WO 1999/011019 A1 — V‑ONE Corporation (same family)

• Title: Multi‑access virtual private network
• Dates: priority 26 Aug 1997; issued 5 Dec 2000 / 9 May 2000; PCT published 4 Mar 1999
• Description: Multi‑access VPN providing authenticated remote access across a public network (access control + cryptographic authentication to a private network).
• Potential § 102 mapping: Relevant to the authentication‑before‑access / unknown‑party‑rejection theme of claims 1, 25, 27 and to claim 20 (pre‑transmission authentication). These operate at the network/VPN layer, not RTP/application layer; they were almost certainly cited to show that "authenticate then accept or reject" was known, i.e., § 103 predicate art, not a § 102 anticipant of claim 1's RTP‑payload limitation.

2.11 US 6,327,660 B1 — Intel Corporation

• Title: Method for securing communications in a pre‑boot environment
• Priority / issue: 18 Sep 1998 / 4 Dec 2001
• Description: Securing communications using cryptographic authentication in a pre‑boot environment (challenge/response authentication).
• Potential § 102 mapping: Bears on the cryptographic‑verification dependent claims (2, 5, 6, 11, 15, 16, 19) — the generic notion of cryptographically authenticating a counterpart before trusting data. Not RTP/application‑layer, not payload‑append. § 103 predicate art.

2.12 US 6,366,961 B1 — Nokia Telecommunications, Oy

• Title: Method and apparatus for providing mini packet switching in IP based cellular access networks
• Priority / issue: 3 Mar 1999 / 2 Apr 2002 (the WO 00/52884 family)
• Description (from the WO‑family specification): Multiplexes low‑bit‑rate connections into a single RTP/UDP/IP payload as MINI‑IP mini‑packets, each with a mini‑header containing a Channel Identifier (CID), Length Indicator (LI), and a Sequence Number (SN), and performs mini‑packet switching at intermediate nodes (BS/RNC) — i.e., a switching node inside the network path.
• Potential § 102 mapping:
  • Claims 1, 25–28 (structural context) — a whole RTP payload carrying multiple mini‑packets; the sequence‑number field recited in claims 4/10/14/18 and in claims 25–28 is disclosed here (as the mini‑header SN).
  • Claims 22 / 24 (switching node / switching installation) — the '961 mini‑packet controller at a base station or RNC is squarely an intermediate switching entity of the kind the '682 specification contemplates as the "receiver."
  • It does not disclose per‑packet authentication data appended to the RTP payload — so no § 102 anticipation of the authentication limitations, but it supplies the RTP‑payload + sequence‑number + switching‑node substrate under § 103.

2.13 US 6,918,034 B1 — Nokia Corporation — the closest intrinsic reference

• Title: Method and apparatus to provide encryption and authentication of a mini‑packet in a multiplexed RTP payload
• Priority / issue: 29 Sep 1999 (prio. 28 Sep 1999) / 12 Jul 2005
• Description (from the specification): Assembles mini‑packets into a multiplexed RTP payload; each mini‑packet has a mini‑header with a length indicator; adds padding and encryption at the mini‑packet level; and adds an authenticator to each mini‑packet, where the authentication type is HMAC‑SHA1 (20‑byte authenticator) or HMAC‑MD5 (16‑byte), with the authenticator removed based on the known authentication type.
• Why it is the most relevant intrinsic citation:
  • It is prior art under pre‑AIA § 102(e) — its 28/29 Sep 1999 filing date precedes the '682 priority date (18 Jan 2000).
  • It discloses per‑packet message authentication codes computed with a shared secret and appended to a multiplexed RTP payload — the functional core of the '682 claims.
• Potential § 102 mapping:
  • Claims 1, 28 — arguably discloses "authentication at the RTP [payload] level" and "accept or reject based on that authentication data." The gap: the '682 claim 1 requires the authentication data at "end of a whole RTP packet payload," whereas '034 authenticates each mini‑packet within the multiplexed payload. That is a genuine structural difference, which is why '034 is much more likely to have driven § 103 rejections/amendments than a clean § 102 anticipation.
  • Claims 4/10/14/18, 25–28 — the MAC‑over‑header‑fields concept (its mini‑header carries a sequence number) and the HMAC‑SHA1/HMAC‑MD5 MAC limitation of claims 5/11/15/19.
  • Claim 25 (MAC generated from a common secret and appended to the payload) — closest intrinsic disclosure.

3. Non‑patent literature cited on the face of the '682 patent

These are the substantive § 102/§ 103 references for the protocol aspects, since the patent is essentially an application of the RTP standard:

1. H. Schulzrinne et al., "RTP: A Transport Protocol for Real‑Time Applications," IETF RFC 1889, 1996, pp. 1–75 (cited twice in the register) — the base RTP standard. Discloses the RTP header with sequence number and timestamp recited in claims 4/10/14/18 and 25–28. Most relevant for the RTP‑packet substrate.
2. D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)," IETF RFC 2409, 1998, pp. 1–41 — IPSEC key management and the "cookie" anti‑DoS mechanism (discussed at length in the '682 Background). Relevant to the DoS‑resistance motivation of claim 1.
3. S. Kent, R. Atkinson, "IP Authentication Header," IETF RFC 2402, 1998, pp. 1–22 and "IP Encapsulating Security Payload (ESP)," IETF RFC 2406, 1998, pp. 1–22 — IPsec integrity/authentication. Directly relevant to the decision to add authentication at packet (not IP) level, which the '682 specification positions as its distinction over IPsec.
4. C. Ruland, Informationssicherheit in Datennetzen, DATACOM‑Verlag, Bergheim, 1993, pp. 61–63 and 68–79 — MAC, one‑way hash functions, asymmetric (public‑key) methods. Bears directly on claims 2, 3, 5, 8, 9, 11, 13, 15, 17, 19 (MAC, one‑way hash, symmetric/asymmetric secret). The single most relevant NPL for the cryptographic dependent claims; a textbook, so anticipation would be difficult but obviousness easy.
5. A. S. Tanenbaum, Computer‑Netzwerke, Wolfram's Fachverlag, Attenkirchen, 1992, pp. 17–32 — OSI reference model. Relevant only to the "application layer / application protocol" preamble.
6. Ray Hunt, "Internet/Intranet Firewall Security — Policy, Architecture and Transaction Services," Computer Communications, vol. 21, no. 13, Sep 1998, pp. 1107–1123 — firewalls/security policy. Relevant to the '682 teaching that the receiver may be a firewall with switching functionality (claims 22/24, and the asymmetric‑key variant).
7. Perkins et al., "RTP Payload for Redundant Audio Data," Network Working Group, Sep 1997, pp. 1–10 — RTP payload format.
8. "HMACSHA1," MSDN Library (msdn2.microsoft.com/.../system.security.cryptography.hmacsha1), 2006 — the HMAC‑SHA1 implementation cited in claims‑support fashion (note: dated 2006, i.e., after the 18 Jan 2000 priority date, so it is not itself prior art; it appears to have been cited to illustrate the MAC construction).

4. Which prior art is "most relevant"?

Ranked by probative weight against the granted claims:

5. Critical update: the claims were invalidated in IPR2023‑00923 — on art not cited on the patent's face

This is the single most important fact for any current reliability assessment, and it does not come from the references cited in the patent:

• Meta Platforms, Inc.; Instagram, Inc.; WhatsApp LLC; Meta Platforms Technologies, LLC; and GIPHY, Inc. v. VL Collective IP LLC, IPR2023‑00923, filed 24 May 2023, instituted 6 Dec 2023.
• The Final Written Decision (5 Dec 2024) determined, by a preponderance of the evidence, that claims 1–28 are unpatentable.
• Petitioners' grounds rested on Handley et al. (a Feb 1999 article in Computer Networks, vol. 31, iss. 3, pp. 191–204) and on PacketCable — against both of which the Patent Owner argued the Petition failed the Hulu v. Sound View public‑accessibility standard.
• The Patent Owner appealed (Notice of Appeal 3 Feb 2025); the Federal Circuit dismissed the appeal on 7 Aug 2025.
• An inter partes review certificate (kind code K1) issued 18 Aug 2025 for IPR2023‑00923 — consistent with cancellation of the challenged claims.
• Related district‑court activity: VideoLabs, Inc. v. Meta Platforms, Inc., No. 1‑22‑cv‑00680 (D. Del., filed 24 May 2022) and the W.D. Tex. action (6‑22‑cv‑01167).

Analyst note: The fact that the Board invalidated all 28 claims using Handley + PacketCable — references that do not appear among the '682 patent's own citations — means that anyone seeking the most relevant prior art should treat those two references as primary and the intrinsic citations above as supporting/§ 103 material. I do not have verified bibliographic detail for the specific Handley and PacketCable documents beyond what the PTAB papers state, and I flag that rather than guess.

6. Caveats and confidence

• Verified with high confidence: patent identification, claim text, party/assignment chain, the intrinsic citation lists, and the IPR2023‑00923 outcome (claims 1–28 unpatentable; K1 certificate 18 Aug 2025). Source: Google Patents US7266682B2; PTAB FWD PDF; Unified Patents/PTAB portal; IPR certificate.
• Lower confidence / needs the source documents: the exact bibliographic identity and content of the IPR's "Handley" and "PacketCable" exhibits; the precise scope of the V‑ONE and pre‑1997 references (I relied on their abstracts and the '682 specification's characterizations).
• § 102 vs § 103: Except for RFC 1889 (RTP header) and, in part, US 6,918,034 (per‑packet MAC over RTP payload), none of the intrinsic references discloses every element of claim 1 — in particular the combination of (i) application‑layer/RTP‑packet‑level authentication, (ii) authentication data placed at the end of a whole RTP packet payload, and (iii) accept/reject of the whole payload. They are therefore best cited as § 103 combinations, which is exactly how such art is normally deployed.

I'll research the key prior art references and the known IPR proceedings before building the § 103 analysis.

Let me gather more on the IPR outcome and the litigation, plus the RTP RFC content.

Obviousness Analysis — U.S. Patent No. 7,266,682 (35 U.S.C. § 103)

Prepared: 2026-04-26 · Analyst: technical patent analyst (not legal advice)
Patent: US 7,266,682 B2, "Method and system for transmitting data from a transmitter to a receiver and transmitter and receiver therefor," inventor Martin Euchner, orig. assignee Siemens AG, now VL Collective IP LLC / VL IP Holdings LLC. Priority 2000‑01‑18 (DE 10001855.6); PCT filed 2001‑01‑05; granted 2007‑09‑04. Status: Expired – Lifetime (adjusted expiration 2022‑11‑11).
Source: https://patents.google.com/patent/US7266682/en (authoritative text used throughout)

Reader's note on the claim text. The claim set reproduced on the Google Patents page (28 claims) contains unusually RTP-specific language — "whole RTP packet payload," "RTP packet level," and a MAC computed over the RTP header's sequence number and timestamp (claims 1, 25–28). This does not read like the plain 2007 grant, which claimed the generic application-layer concept in the abstract. The page also records an IPR certificate (K1) issued 2025‑08‑18 for IPR2023‑00923. I analyze the claims as displayed per the instruction to interpret the record literally; the possibility that these are amended/post-IPR claims is flagged where it affects the analysis. I could not retrieve the specific grounds pleaded in IPR2023‑00923, so I do not attribute any particular reference combination to the Board.

1. Governing framework

• Graham v. John Deere factors: scope/content of the claims, scope/content of the prior art, level of ordinary skill, and objective indicia.
• KSR Int'l v. Teleflex (2007): a combination is obvious where the elements were known, the combination yields only predictable results, and there was a known reason to combine. Any of the MPEP 2143 rationales suffices: (A) combining prior-art elements by known methods; (B) substitution of a known element; (C) use of a known technique to improve similar devices in the same way; (D) applying a known technique to a known device ready for improvement; (F) "obvious to try."
• The claims here are structural/functional combinations of well-known networking and cryptographic primitives (RTP packetization + keyed message authentication + accept/reject decision). That posture makes § 103 the central validity question.

2. Level of ordinary skill (POSITA)

A bachelor's degree in EE/CS (or equivalent) with ~2–3 years' experience in packet-switched networking and/or IP telephony, including working familiarity with: the OSI/Internet layering model; the RTP/RTCP suite (RFC 1889); basic applied cryptography (message authentication codes, one-way hash functions, symmetric/asymmetric keys); and firewall/security-gateway design. This is the level the patent itself assumes — its Background cites Tanenbaum (OSI), Ruland (MAC/hash/asymmetric), RFC 1889 (RTP), and the IPSEC RFCs as ordinary knowledge.

3. The prior art of record (from the patent's own "Prior Art" section)

3.1 Patent references

3.2 Non‑patent literature

(Also present as "Similar Documents": WO 98/32065 A2 "Improved network security device" (1998) and US 6,154,679 A, both usable origin-authentication art; and post-2000 items such as Kuhn et al. 2005 and JP 2004‑295891, which are not prior art to a 2000 priority date.)

4. Claim 1 — element-by-element mapping

Every element of claim 1 is disclosed; the only issue is motivation to combine, addressed in § 7.

5. Independent claims 25–28 (system / transmitter / receiver / method)

Claims 25–28 add the same three specific limitations beyond claim 1:

1. the RTP header comprises at least one of a sequence number and a timestamp → RFC 1889 (both fields are in the RTP fixed header);
2. the authentication data is a MAC generated from a common secret between transmitter and receiver using the header sequence number and timestamp, appended at the end of the whole RTP packet payload → Ruland (MAC + key), US 5,345,507 (append + verify), RFC 1989/1889 (fields), and RFC 2104 (HMAC) for the keyed-hash instantiation;
3. on receipt, if the receiver's computed MAC equals the received MAC, the receiver accepts → US 5,345,507 (matching-residue acceptance).

Because claims 25–28 are the claim‑1 concept instantiated with the RTP header fields plus a MAC, their obviousness posture is, if anything, stronger — the added features are precisely the conventional inputs to a keyed hash (packet-identifying header fields), and both the keyed MAC and the "compute → compare → accept/reject" step are admitted prior art in the specification's own Background (Ruland).

Dependent claims 2–24 map as follows:

• Secret = symmetric key or asymmetric key pair (claims 3, 9, 13, 17) → Ruland (both methods), US 5,602,918 (DES/shared key + key server).
• One-way hash / MAC with key known only to tx and rx (claims 5, 11, 15, 19) → Ruland, RFC 2104.
• Sequence number / timestamp as MAC input (claims 4, 10, 14, 18) → RFC 1889.
• Verification by decryption / cryptographic checksum (claims 6, 7, 16) → Ruland, US 5,345,507.
• Pre‑transmission authentication between tx and rx (claim 20) → US 5,602,918 (mutual authentication before establishing the channel).
• Internet telephony / packet-switched telephone services (claims 21, 23) → obvious in view of RFC 1889 / US 6,918,034 (IP telephony context).
• Receiver/transmitter in a switching node or switching installation (claims 22, 24) → US 5,602,918 (gateway/firewall), US 6,918,034 / US 6,396,840 (network switching/relay).

6. Specific § 103 combinations

Ground A — RFC 1889 (RTP) + US 6,918,034 (Nokia RTP-payload authentication) + Ruland (MAC) [and optionally US 5,345,507 for the append/accept‑reject]
Renders claim 1 obvious: RFC 1889 supplies the RTP packet at the application layer with header SNR/timestamp; Nokia supplies the express teaching of adding an authenticator to RTP-carried media and discarding it on receipt; Ruland supplies the keyed MAC that identifies the origin. Motivation: Nokia already addresses the identical problem (authenticating RTP media in IP telephony), so a POSITA seeking to reject spoofed/DoS media would adopt its RTP-level authenticator and drop the "who am I talking to?" check onto a real RTP packet.

Ground B — RFC 1889 + US 5,345,507 (IBM) + Ruland
The strongest read on the "whole RTP packet payload … append at end … accept/reject" limitations: IBM teaches appending an authentication value at the end of the whole message and the binary accept/reject decision; substituting an RTP packet for IBM's generic message and a MAC (Ruland) for IBM's encrypted residue is a substitution of a known element to obtain a predictable result (MPEP 2143(B)).

Ground C — RFC 1889 + US 5,602,918 (V‑ONE) + US 5,345,507 / Ruland
Targets the "receiver knows the transmitter" and switching-entity limitations. V‑ONE teaches application-level authentication enforced by a gateway/firewall that admits traffic only if the origin is authenticated with a shared secret — exactly claims 1, 20, 22, and 24's firewall/switching-node placement. Motivation: offload the DoS filter to a network node so untrusted media never reaches the endpoint (the patent's own stated advantage).

Ground D — any of A–C + RFC 2402/2406 (IPSEC) + RFC 2409 (IKE cookie), and/or Hunt (1998)
Provides the motivation for cryptographic, real-time DoS‑resistant media security: IPSEC supplies implicit sender authentication and integrity for real-time IP flows; the IKE cookie shows DoS defense was a recognized need; Hunt supplies firewall filtering policy. These references are best used for motivation/rationale, not as the core anticipation — the patent itself distinguishes IPSEC as IP‑layer art.

7. Motivation to combine — why a POSITA would have done this

1. Same field, same problem. RFC 1889 and Nokia's US 6,918,034 are both about real-time media in IP telephony — the very application the '682 specification uses as its example. Combining them is "use of a known technique to improve similar devices in the same way" (KSR; MPEP 2143(C)).
2. A recognized, articulated problem with known countermeasures. Denial-of-service/"unwanted mass data" against VoIP, and cryptographic integrity/authentication of real-time packets, were known by 1999 (RFC 2402/2406; IKE RFC 2409 cookies; Hunt 1998). KSR holds that a known problem with an available known solution is obvious to implement.
3. The patent's own Background concedes the building blocks. The specification expressly states that MACs (Ruland), one-way hash functions (Ruland), and asymmetric methods (Ruland) are known, and that the problem (DoS, unwanted mass media) is known. Under § 103, admitted prior art may be used to show what a POSITA knew.
4. Predictable result. Appending a keyed MAC to a packet and accepting only on a match is the paradigm taught by US 5,345,507. There is no unexpected result and no new structural change; the output is exactly what one would expect from applying a known authentication primitive to a known packet format.
5. Infrastructure-ready. RTP packets already contained a sequence number and timestamp (RFC 1889); using those header fields as MAC inputs is a natural, low-cost choice (and provides replay ordering), satisfying MPEP 2143(D) — a known technique applied to a known device ready for improvement.
6. Standards trajectory / market pressure. The RTP community was actively working to secure RTP media around the 1999–2000 timeframe (the patent's own priority window), supplying commercial and technical impetus.

Mapping to the enumerated rationales:

• A (combining known elements by known methods): A, B, C.
• B (substitution of a known element): B (IBM append+reject substituted into RTP); D (MAC for residue).
• C (known technique to improve a similar device): A (Nokia's media-auth technique applied to the RTP payload).
• D (known technique applied to a known device ready for improvement): the sequence-number/timestamp‑keyed MAC of claims 25–28.
• F (obvious to try): the keying/verification variants of claims 2–19 (symmetric vs. asymmetric; hash vs. MAC).

8. Rebuttal considerations

• Teaching away? The patent argues IPSEC (RFC 2402/2406) is unsuitable for linking to application-layer security. That is an argument against IP‑layer art, not against the application/RTP‑layer art (Nokia US 6,918,034, V‑ONE US 5,602,918, IBM US 5,345,507). A robust invalidity ground should therefore be anchored in the RTP/application-layer references, using IPSEC/IKE only for motivation. Nokia's express RTP-authentication teaching is, if anything, the opposite of teaching away.
• "Whole RTP packet payload" / "accept the whole … reject the whole." This is the limitation a patent owner would press (arguing Nokia authenticates per mini-packet, not the whole payload). US 5,345,507's whole-message accept/reject, or reading Nokia's multiplexed payload+authenticators as authenticated payload matter, blunts this. If the claims are post‑IPR amendments narrowed to the "whole payload" concept, this is precisely the term to test — the recording is ambiguous (see reader's note).
• Objective indicia (secondary considerations). I found no evidence of unexpected results, a long‑felt unmet need, industry praise, copying, or nexus in the record. Given the crowded, standard‑driven field and the decades of prior RTP-security activity, such evidence would be hard to establish; the patent is also expired (adjusted expiration 2022‑11‑11).
• § 102 vs. § 103. Several references (RFC 1889 for the packet format; Ruland for MAC/keying) are arguably anticipatory of individual claims, but the combination claims are best analyzed under § 103 as above.
• Citation hygiene. The MSDN HMAC‑SHA1 non‑patent citation is dated 2006 and is not prior art; if it were ever cited as art, that is a defect to raise. RFC 2104 (1997) supplies the same teaching legitimately.

9. Real‑world corroboration (from the record and live sources)

• IPR2023‑00923 (Meta Platforms, Instagram, WhatsApp, Meta Platforms Technologies, GIPHY v. VL Collective IP), filed 2023‑05‑24, instituted 2023‑12‑06, Final Written Decision terminating 2024‑12‑05, recorded as "Determining All Challenged Claims Unpatentable, 35 U.S.C. § 318(a)." An IPR certificate (K1) issued 2025‑08‑18. A CAFC appeal, No. 25‑1414, appears in the litigation record.
• Related VideoLabs/VL Collective assertions: W.D. Tex. 6:22-cv-00079 and D. Del. 1:22-cv-00680; the patent has been asserted against Amazon, Facebook, and Instagram; Unified Patents ran a prior-art bounty on claim 1 in 2023.
• Separately, the Federal Circuit has repeatedly affirmed PTAB obviousness holdings against VL Collective (e.g., VL Collective IP, LLC v. Netflix, Inc., No. 25‑1132, decided 2026‑08‑10, affirming unpatentability of claims 1–24 of the '559 patent over Huston) — the same patent owner in the same video/VoIP space.

These outcomes are consistent with the analysis above: the challenged claims of the '682 patent were held unpatentable. I was not able to retrieve the specific grounds and reference combinations the Board relied on, so I have deliberately not attributed any particular combination to the Board — the combinations above are my own independent § 103 analysis.

10. Bottom line

Every limitation of independent claims 1 and 25–28 is disclosed by prior art already of record on this page, and the combinations are supported by strong, explicit motivations to combine:

• Primary combination: RFC 1889 (RTP packet, application layer, SNR/timestamp) + US 6,918,034 (authentication of RTP-carried media in IP telephony) + Ruland (keyed MAC / hash / asymmetric) — with US 5,345,507 best covering the "append authentication at the end / accept‑or‑reject the whole message" limitations.
• Motivation: known, articulated DoS/unwanted‑media problem in VoIP; known cryptographic primitives (admitted in the patent's own Background); Nokia addresses the identical RTP-authentication problem; adding a MAC over the RTP header fields is a predictable, low‑cost design choice; no unexpected results or objective indicia of nonobviousness.
• Strongest patent‑owner defense: narrow construction of "whole RTP packet payload" and the "at the end" placement, and any pre‑transmission mutual‑authentication nuance — each of which is met or mooted by US 5,345,507 / US 5,602,918.

Confidence: High for claims 1 and 25–28 as displayed; moderate for the dependent claims' narrower variants. Primary uncertainty: the provenance of the displayed RTP-specific claim text (potential post‑grant amendment/ IPR certificate) and the specific grounds of the IPR2023‑00923 Final Written Decision, neither of which I could confirm from the sources retrieved.

This is a technical invalidity opinion for analytical purposes only and is not legal advice; a formal § 103 opinion should be confirmed against the certified claim text, the complete file history, and the IPR2023‑00923 record.