US 7864816

Litigation Summary

As of April 26, 2026, there is no known litigation specifically involving US patent 7864816 in the CAFC dockets. Searches of the CAFC website for "7864816" or "US7864816" did not yield any direct case results. The CAFC site provides information on scheduled cases and case records, but a patent number alone is not typically sufficient for a direct search of active litigation without specific case information like party names or a case number. My previous search of Unified Patents and PACER also did not reveal any litigation, and these platforms often require more specific details for effective searching.

Therefore, based on the available information and search capabilities, no specific litigation involving US patent 7864816 is known at this time.

US Patent 7864816: Concise Summary

Title: Integrated circuit for network delay and jitter testing

Assignee: Marvell Asia Pte Ltd. (Current Assignee)

Inventors: Yuval Cohen

Filing Date: 2005-02-11

Issue Date: 2011-01-04

Abstract: An integrated circuit (IC) and its corresponding method for network delay and jitter testing are disclosed. The IC includes one or more ports to transmit and receive data packets and a forwarding engine to transfer these packets between the ports. At least one port features a packet generator to create a first packet with a timestamp indicating its transmission time, a network transmit interface to send it, and a network receive interface to get a reply packet. A controller then calculates network delay using the original timestamp and the reply packet.

Plain-language overview of independent claims:

• Claim 1 (Integrated Circuit for Network Switch): This claim describes an integrated circuit designed for a network switch. It has multiple ports for sending and receiving data on a network, and a forwarding engine to move data between these ports. Crucially, at least one of these ports contains a specialized setup:

  • A packet generator that creates a "first packet" (a test packet) and includes a timestamp representing when this packet was generated. This first packet is considered "received by the at least one of the ports from the network," which is a somewhat unusual phrasing for a generated packet but is specified in the claim.
  • A network transmit interface to send out this first packet.
  • A network receive interface to get a "second packet" (a reply) back in response to the first packet.
  • A controller that calculates the network delay. This delay specifically includes a queue delay that occurs when the first packet is waiting to be sent. The calculation is based on the generation timestamp from the first packet and the received second packet.

• Claim 16 (Method for Network Switch IC): This claim describes a method performed by an integrated circuit acting as a network switch. The steps include:

  • Transmitting and receiving data packets on a network using the IC's ports.
  • Transferring packets between these ports via a forwarding engine.
  • Using a packet generator (within one of the ports) to create a "first packet" that contains a timestamp of its generation. Again, the first packet is characterized as "received by the one of the ports from the network."
  • Transmitting this first packet.
  • Receiving a "second packet" in reply.
  • Using a controller (within the same port) to calculate a network delay, which includes a queue delay. This calculation relies on the generation timestamp of the first packet and the received second packet.

• Claim 25 (Integrated Circuit for Network Interface Controller): This claim describes an integrated circuit for a network interface controller (NIC). It features one or more ports for network communication and a host interface for exchanging data with a host device. Similar to Claim 1, at least one port includes:

  • A packet generator to originate a "first packet" with a generation timestamp. This packet is also described as "received by the at least one of the ports from the network."
  • A network transmit interface to send the first packet.
  • A network receive interface to get a reply "second packet."
  • A controller to calculate a network delay that includes a queue delay, using the generation timestamp of the first packet and the second packet.

• Claim 40 (Method for Network Interface Controller IC): This claim describes a method performed by an integrated circuit functioning as a network interface controller. The steps involve:

  • Transmitting and receiving packets on a network through the IC's ports.
  • Using a packet generator (within one of the ports) to create a "first packet" with a generation timestamp. This packet is again described as "received by the one of the ports from the network."
  • Transmitting the first packet.
  • Receiving a "second packet" in reply.
  • Using a controller (within the same port) to calculate a network delay, which includes a queue delay. This calculation is based on the generation timestamp of the first packet and the received second packet.

• Claim 49 (Integrated Circuit - Refinement of Claim 1): This claim adds a specific detail to the integrated circuit described in Claim 1. The controller further includes in the first packet third data representing a time of transmission when the first packet is actually sent. The network delay is then calculated based on this transmission timestamp and the time the second packet is received. This refines the delay calculation by using the actual transmission time rather than the generation time if there is a queue delay between generation and transmission.

• Claim 50 (Integrated Circuit - Refinement of Claim 25): This claim refines the integrated circuit described in Claim 25 (for a NIC) in the same way Claim 49 refines Claim 1. The controller includes third data representing a time of transmission in the first packet and calculates the network delay based on this transmission timestamp and the time the second packet is received.

• Claim 51 (Method - Refinement of Claim 16): This claim refines the method described in Claim 16 (for a network switch IC). It explicitly includes the step of inserting third data representing a time of transmission into the first packet when it is sent. The network delay calculation is then based on this transmission timestamp and the time the second packet is received.

• Claim 52 (Method - Refinement of Claim 40): This claim refines the method described in Claim 40 (for a NIC IC). It includes the step of inserting third data representing a time of transmission into the first packet when it is sent. The network delay calculation is then based on this transmission timestamp and the time the second packet is received.

A consistent point of potential uncertainty across the independent claims is the phrase "a first packet of the first data received by the at least one of the ports from the network, wherein the first packet comprises second data representing a time of generation of the first packet of the first data". This wording could be interpreted as the packet being both generated by the port and received by the port from the network, which seems contradictory. However, given the context of a packet generator originating the packet and then transmitting it, this phrasing likely refers to the conceptual point in the process where the packet, having been generated, is now ready for transmission into the network, and the 'time of generation' is the relevant timestamp for the measurement. Claims 49-52 clarify this by introducing a "time of transmission" directly into the packet, suggesting a distinction between generation time and actual transmission time after queuing.

A search for litigation involving US patent 7864816 using the Unified Patents Portal and general litigation searches did not return any direct results as of April 26, 2026. Therefore, there is no known litigation involving US patent 7864816.

Proceedings overview

The USPTO ODP API indicates no AIA trial proceedings on file for US patent 7864816. Therefore, there is no PTAB activity to report. For a defendant, this means the patent claims are currently untested by AIA trial challenges, and no claims have been invalidated or confirmed through these specific administrative proceedings.

Strategic summary

As there are no PTAB proceedings on file for US7864816, all claims of the patent are currently untested within the AIA trial system. This means that no claims have been canceled, sustained, or otherwise modified through IPR, PGR, or CBM proceedings.

The absence of PTAB activity implies there is no estoppel landscape under § 315(e)(2) to consider from prior PTAB trials. Any prior-art grounds that could be raised in an AIA trial are still available to a potential petitioner.

There are no patterns of repeated petitions or aggressive PTAB appeals by the patent owner, nor is there any involvement of a defensive aggregator like Unified Patents, as no proceedings have been initiated.

Recommended next steps

Since no PTAB activity exists for US patent 7864816, a defendant currently facing assertion of this patent has a "clean slate" regarding PTAB challenges. This means:

• Consider filing a petition for Inter Partes Review (IPR). If the asserted claims are directed to a process, machine, manufacture, or composition of matter, and the asserted prior art is patents or printed publications, an IPR could be a viable defense strategy.
• Conduct a thorough prior art search. The absence of PTAB challenges does not mean the patent is strong. A robust prior art search is crucial to identify strong invalidity arguments that could be presented in an IPR petition.
• Analyze the claims carefully. Focus on identifying the broadest reasonable interpretation of the claims and how they might be challenged under 35 U.S.C. §§ 102 and 103 using newly discovered or previously uncited prior art.

Inventors

Yuval Cohen is the sole named inventor. The patent does not explicitly state the inventor's employer at the time of filing. However, the original assignee is Marvell International Ltd..

Original assignee

The original assignee named on the issued patent is Marvell International Ltd. Marvell Technology Group Ltd. (the parent company of Marvell International Ltd.) is a fabless semiconductor company that develops and produces storage, processing, networking, security, and connectivity solutions. They ship products embodying the claims. Marvell Technology Group Ltd. is currently operating.

Assignment timeline

• 2005-02-11 (executed) / recorded 2005-02-11 — Reel 016730/0833

  • Conveyance: Assignment of Assignors Interest
  • Assignor: Cohen, Yuval
  • Assignee: Radlan Computer Communications, LTD.
  • Correspondent: BLANK ROME LLP.
  • Context: Inventor assigned rights to an early assignee.

• 2008-01-15 (executed) / recorded 2008-01-15 — Reel 020619/0814

  • Conveyance: Assignment of Assignors Interest
  • Assignor: Cohen, Yuval
  • Assignee: Radlan Computer Communications, LTD.
  • Correspondent: BLANK ROME LLP. This correspondent also appears on 016730/0833.
  • Context: Inventor re-assigned rights to an early assignee.

• 2010-11-02 (executed) / recorded 2010-11-02 — Reel 025232/0299

  • Conveyance: Assignment of Assignors Interest
  • Assignor: Marvell Software Solutions Israel Ltd.
  • Assignee: Marvell Internation Ltd.
  • Correspondent: Marvell Semiconductor, Inc. Attn: Patent Group, 5488 Marvell Lane, Santa Clara, CA 95054.
  • Context: Internal corporate reorganization/transfer.

• 2010-11-02 (executed) / recorded 2010-11-02 — Reel 025232/0298

  • Conveyance: Change of Name
  • Assignor: Radlan Computer Communications Ltd.
  • Assignee: Marvell Software Solutions Israel Ltd.
  • Correspondent: Marvell Semiconductor, Inc. Attn: Patent Group, 5488 Marvell Lane, Santa Clara, CA 95054.
  • Context: Change of name for an intermediate assignee.

• 2010-11-24 (executed) / recorded 2010-11-24 — Reel 025539/0783

  • Conveyance: Corrective Assignment
  • Assignor: Marvell Software Solutions Israel Ltd.
  • Assignee: Marvell International Ltd.
  • Correspondent: Marvell Semiconductor, Inc. Attn: Patent Group, 5488 Marvell Lane, Santa Clara, CA 95054.
  • Context: Corrective assignment to update assignee name.

• 2010-11-24 (executed) / recorded 2010-11-24 — Reel 025539/0782

  • Conveyance: Change of Name
  • Assignor: Radlan Computer Communications Ltd.
  • Assignee: Marvell Software Solutions Israel Ltd.
  • Correspondent: Marvell Semiconductor, Inc. Attn: Patent Group, 5488 Marvell Lane, Santa Clara, CA 95054.
  • Context: Change of name for an intermediate assignee.

• 2020-02-20 (executed) / recorded 2020-02-20 — Reel 050519/0426

  • Conveyance: Assignment of Assignor's Interest
  • Assignor: Marvell International Ltd.
  • Assignee: Cavium International
  • Correspondent: Kilpatrick Townsend & Stockton LLP, 1100 Peachtree Street, Suite 2800, Atlanta, GA 30309.
  • Context: Transfer of ownership.

• 2020-06-16 (executed) / recorded 2020-06-16 — Reel 050965/0427

  • Conveyance: Assignment of Assignor's Interest
  • Assignor: Cavium International
  • Assignee: Marvell Asia Pte, Ltd.
  • Correspondent: Kilpatrick Townsend & Stockton LLP, 1100 Peachtree Street, Suite 2800, Atlanta, GA 30309. This correspondent also appears on 050519/0426.
  • Context: Transfer of ownership, potentially an internal Marvell restructuring after Cavium acquisition.

Timeline diagram

timeline
    title Ownership of US 7864816
    2005 : Assigned to Radlan Computer
    2008 : Assigned to Radlan Computer
    2010 : Radlan changes name to Marvell Israel
         : Assigned to Marvell International
         : Marvell Israel name change corrected
         : Corrective Assignment to Marvell
    2011 : Issued
    2020 : Assigned to Cavium International
         : Assigned to Marvell Asia Pte

NPE / troll-pattern signals

1. Shell-entity transfer — not present. The entities in the chain (Radlan, Marvell, Cavium) appear to be operating companies or direct subsidiaries involved in semiconductor and networking.
2. Known asserter in the chain — not present. None of the assignees (Radlan, Marvell International Ltd., Marvell Software Solutions Israel Ltd., Cavium International, Marvell Asia Pte, Ltd.) are recognized as known NPEs in public directories like RPX or Unified Patents.
3. Repeat correspondent across the chain — present. BLANK ROME LLP appears as the correspondent for the 2005-02-11 (Reel 016730/0833) and 2008-01-15 (Reel 020619/0814) assignments. Marvell Semiconductor, Inc. (Attn: Patent Group) is listed for multiple entries in November 2010 (Reel 025232/0299, 025232/0298, 025539/0783, 025539/0782), indicating internal handling of assignments. Kilpatrick Townsend & Stockton LLP appears for the 2020-02-20 (Reel 050519/0426) and 2020-06-16 (Reel 050965/0427) assignments. The recurrence of Kilpatrick Townsend & Stockton LLP for consecutive transfers (Marvell International Ltd. to Cavium International, then Cavium International to Marvell Asia Pte, Ltd.) could be a weak signal if the entities were distinct, but in this case, it appears to be part of Marvell's corporate structure.
4. Cascading transfers — not present. While there are multiple transfers, they appear to be part of corporate structuring (name changes, inter-company transfers, or acquisitions like Marvell acquiring Cavium) rather than rapid, consecutive transfers to shell entities. The transfers from 2005 to 2010 are spaced, and the 2020 transfers are related to a corporate acquisition and subsequent internal consolidation.
5. Pre-litigation transfer — unclear. There is no information regarding litigation available at this stage of the analysis to assess this signal.
6. Bankruptcy fire-sale — not present. There is no indication that Marvell International Ltd. or any other assignor in the chain underwent bankruptcy proceedings leading to the assignment of this patent.
7. Privateering — unclear. There is no public information or SEC filings available in this record that suggest a privateering arrangement.
8. Defensive aggregator (anti-NPE) — not present. The chain does not terminate at a known defensive aggregator.

Verdict

Operating-company assertion. The patent originates from and is currently owned by Marvell Asia Pte, Ltd., which is part of the Marvell Technology Group, a known operating company in the semiconductor and networking industry. The assignment history, specifically the transfers between Marvell International Ltd., Cavium International (acquired by Marvell), and Marvell Asia Pte, Ltd. (Reel 050519/0426, Reel 050965/0427), indicates corporate restructuring and internal asset management within an operating company, rather than transfers to a shell entity for licensing or assertion by a non-practicing entity.

USPTO Assignment Center search for US7864816

US patent 7864816, titled "Integrated circuit for network delay and jitter testing," was filed on February 11, 2005, with a priority date of January 7, 2005. The patent describes an integrated circuit (IC) that can conduct network delay and jitter testing at the Media Access Control (MAC) level and above, aiming to minimize the burden on the device's Central Processing Unit (CPU). The IC includes ports with a packet generator to originate timestamped test packets, and a controller to calculate network delay and jitter based on these packets and their replies.

A thorough analysis under 35 U.S.C. § 102 for each of the 54 prior art citations would involve a detailed claim-by-claim mapping of every element of US7864816's claims against each reference. This level of detail is extensive and beyond the scope of this summary. However, based on the titles and abstracts of selected prior art, we can identify potential areas of anticipation for the core concepts of US7864816.

Below are details for some of the most relevant patent citations, chosen based on their titles' direct relevance to network delay, jitter, and timestamping, and their publication dates preceding the priority date of US7864816.

Selected Prior Art Citations for US7864816:

1. US5307354A

   • Full Citation: U.S. Patent 5,307,354 to C. C. Lo, et al., "Method and apparatus for measuring end-to-end network delay and jitter using time-stamping packets"
   • Publication/Filing Date: Filed September 15, 1992; Published April 26, 1994.
   • Brief Description: This patent describes a method and apparatus for measuring end-to-end network delay and jitter by transmitting packets with timestamps from a sender to a receiver and calculating delay based on the timestamps and reception times. It uses a network management station (NMS) to coordinate tests and collect results from network elements.
   • Potential Anticipation (35 U.S.C. § 102):
     • Claims 1, 16, 25, 40 (core concept of network delay calculation): The fundamental concept of using timestamped packets to measure network delay and jitter is directly taught. Specifically, the idea of originating a packet with a time of transmission/generation and using it with a reply packet to calculate delay is present. While US7864816 specifies an integrated circuit with a packet generator within a port, the core methodology of timestamping and delay calculation is anticipated.
     • Claims 6, 21, 30, 45 (jitter determination): The patent explicitly teaches determining network jitter from a plurality of network delays.

2. US5579308A

   • Full Citation: U.S. Patent 5,579,308 to C. C. Lo, et al., "Method and apparatus for active measurement of network performance"
   • Publication/Filing Date: Filed May 1, 1995; Published November 26, 1996.
   • Brief Description: This patent describes an active measurement system for network performance that sends specially formatted test packets to measure various metrics, including delay and jitter. The system uses network management agents to perform measurements and report data back to a central station.
   • Potential Anticipation (35 U.S.C. § 102):
     • Claims 1, 16, 25, 40 (active testing and delay measurement): The concept of actively injecting test packets into a network to measure performance metrics like delay and jitter is anticipated. The use of "specially formatted test packets" aligns with US7864816's packet generator originating packets with timestamps.
     • Claims 6, 21, 30, 45 (jitter determination): Similar to US5307354A, this patent teaches the measurement of jitter as a network performance metric.

3. US6452945B1

   • Full Citation: U.S. Patent 6,452,945 to F. M. Vitenberg, "Method and apparatus for measuring network performance, loss, delay and jitter of packets"
   • Publication/Filing Date: Filed June 21, 2000; Published September 17, 2002.
   • Brief Description: This patent describes a system and method for measuring network performance characteristics, including packet loss, delay, and jitter. It involves sending test packets with timestamps and analyzing the timestamps of received packets and acknowledgment packets to determine performance metrics. The method allows for measurement of both one-way and two-way delay.
   • Potential Anticipation (35 U.S.C. § 102):
     • Claims 1, 16, 25, 40 (comprehensive delay and jitter measurement): This patent directly teaches methods for measuring delay and jitter of packets using timestamps. The analysis of received and acknowledgment packets to determine various delay types (one-way, two-way) is a core aspect shared with US7864816.
     • Claims 2, 3, 4, 5, 17, 18, 19, 20, 26, 27, 28, 29, 41, 42, 43, 44 (specific delay calculation methods): The varying ways delay is calculated (e.g., based on receipt time, or timestamps within reply packets) are explicitly discussed.
     • Claims 6, 21, 30, 45 (jitter determination): The patent clearly addresses determining jitter based on delay measurements.

4. US6795450B1

   • Full Citation: U.S. Patent 6,795,450 to T. S. Bell et al., "Network measurement of latency and jitter"
   • Publication/Filing Date: Filed May 15, 2000; Published September 21, 2004.
   • Brief Description: This patent describes a system and method for measuring network latency (delay) and jitter. It involves a "latency engine" that inserts timestamps into packets and uses these timestamps to calculate the time taken for packets to traverse the network. The system can be integrated into network devices.
   • Potential Anticipation (35 U.S.C. § 102):
     • Claims 1, 16, 25, 40 (latency/delay and jitter measurement with timestamping): The core functionality of measuring network latency and jitter by inserting timestamps into packets and calculating based on these timestamps is strongly anticipated. The concept of a "latency engine" performing this function suggests an integrated hardware approach, which is a key aspect of US7864816's integrated circuit.
     • Claims 2, 3, 4, 5, 17, 18, 19, 20, 26, 27, 28, 29, 41, 42, 43, 44 (specific delay calculation methods): The methods of using timestamps for delay calculation would likely cover the various ways delay is determined in US7864816.
     • Claims 6, 21, 30, 45 (jitter determination): Jitter measurement is explicitly a focus of this patent.

5. US20030103493A1

   • Full Citation: U.S. Patent Application Publication 2003/0103493 to K. B. Thompson, "Methods and systems for measuring network quality of service metrics using packet sampling"
   • Publication/Filing Date: Filed November 27, 2001; Published June 5, 2003.
   • Brief Description: This publication describes methods and systems for measuring network Quality of Service (QoS) metrics, including delay and jitter, by analyzing sampled packets. It details how network devices can monitor packet flows and collect statistics related to QoS.
   • Potential Anticipation (35 U.S.C. § 102):
     • Claims 9, 22, 33, 46 (classifier and counter for packet properties/QoS): This reference teaches determining QoS metrics and monitoring packet flows, which aligns with US7864816's classifier and counter mechanisms to determine properties and count packets matching property definitions, especially concerning "one or more qualities of service for the packets of the first data" (Claims 10, 23, 34, 47).
     • Claims 1, 16, 25, 40 (general network testing context): While not as specific on timestamping and packet generation within a port as other references, it broadly anticipates the goal of integrated network devices performing QoS testing, which includes delay and jitter.

It's important to note that while these prior art references teach various aspects of network delay and jitter measurement, the specific combination of features in US7864816, such as an integrated circuit with a packet generator directly within the port's MAC and a controller designed to explicitly calculate delay that includes queue delay that occurs when the first packet is queued for transmission, and doing so at wirespeed to offload the CPU, would be the points of novelty that differentiate US7864816's claims from these prior art references. A full anticipation analysis would scrutinize whether each and every element of a US7864816 claim is found in a single prior art reference, or if the combination would be obvious over multiple references (obviousness under 35 U.S.C. § 103).

I'll ground this analysis by verifying the prior-art references identified earlier and gathering supporting detail on the standards-based motivation to combine.

Obviousness Analysis — 35 U.S.C. § 103

US 7,864,816 B1 — "Integrated circuit for network delay and jitter testing"

Assignee of record: Marvell Asia Pte Ltd. · Inventor: Yuval Cohen · Filed: 2005‑02‑11 · Priority: 2005‑01‑07 (Prov. 60/642,483) · Issued: 2011‑01‑04

This section builds on the previously generated Patent summary, Prior art, Litigation, PTAB, and Assignment history sections. It does not restate them. Where it contradicts them, the contradiction is flagged explicitly (§1.2, §9).

1. Framework

1.1 Governing law and forum constraints

US 7,864,816 has a 2005 effective filing date, so pre‑AIA §§ 102/103 apply; the AIA first‑inventor‑to‑file, IPR‑eligibility and PGR provisions do not create new exposure or new defenses here. Practically:

1.2 ⚠️ Critical contradictions in the supplied record (must be resolved before any ground is filed)

The previously generated Prior art section attached specific titles and disclosures to five reference numbers. Live retrieval of the authoritative bibliographic records contradicts four of those five identifications:

Per the operating rules, the numbers control and the search results are the current ground truth. The consequence is that the §102 "anticipation" mappings proposed in the Prior art section are, as written, unsupportable: US5307354A, US5579308A, US6452945B1 and US20030103493A1 as actually identified do not teach or suggest packet‑based network delay/jitter measurement at all, let alone a packet generator inside a switch port's MAC. Any petition or invalidity contention built on those labelings would fail on the face of the references. See §9.

Also flagged:

• The Prior art section refers to "54 prior art citations." The authoritative page shows only "Cited By (4)" with an unexpanded citation list, and the patent has 52 claims. The "54" figure is unverifiable from the provided record.
• The Prior art section states that claim 49 "refines the delay calculation by using the actual transmission time rather than the generation time if there is a queue delay." That is internally inconsistent with claim 1, which requires the delay to include queue delay. A delay computed from egress‑transmit time to reply‑receipt time excludes egress queuing. I address this in §5.3 and §11.

2. Person of ordinary skill in the art (POSITA)

For a January 2005 priority date, a POSITA would be a network‑ASIC architect or network performance engineer with a B.S. in EE/CS and 3–5 years of experience in packet‑switching silicon and/or IP performance measurement, familiar with: (a) MAC/switch data paths, per‑port ingress/egress queues and schedulers; (b) ICMP echo/timestamp exchange and RMON‑style classification/counting; and (c) the IETF IPPM metric RFCs and ITU‑T I.380/E.800 performance parameters. This is a well‑populated, well‑documented intersection — a fact that cuts strongly toward obviousness under KSR's "known work in one field prompting variations for use in the same field."

3. Element decomposition (the workhorse table)

4. Ground 1 — Primary § 103 attack on claims 1, 16, 25, 40

4.1 Reference set

A. IETF IPPM active‑measurement framework (printed publications, all pre‑priority):

• RFC 2330, Framework for IP Performance Metrics (May 1998) — defines active vs. passive measurement and the "comparison of two clocks" model.
• RFC 2679, A One‑way Delay Metric for IPPM (Sept. 1999) — one‑way delay computed by subtracting the timestamp taken at the source when the packet is sent from the destination arrival timestamp, and expressly discusses the sender‑side systematic error between timestamping and actual transmission.
• RFC 2681, A Round‑trip Delay Metric for IPPM (Sept. 1999) — round‑trip delay from a node to itself via a remote node.
• RFC 3393, IP Packet Delay Variation Metric (Nov. 2002) and RFC 3432, Network performance measurement with periodic streams (Nov. 2002) — jitter from a plurality of delay samples.
• ITU‑T I.380 / E.800 — IP packet transfer delay, delay variation and loss parameters (regulatory/SLA pressure).
• Citations/URLs: datatracker.ietf.org RFC index; rfc-editor.org/info/rfc2679

B. Klassen — network analysis using "probative test packets" with send/receipt timestamps, per‑class‑of‑service transmission, and recorded statistics including one‑way/round‑trip time and "best/average/worst/standard deviation … for packets." The only excerpts available to me come from a PTAB petition in an unrelated matter, which refers to the Klassen patent as "the '485 patent" (ptacts.uspto.gov petition 1550566). I could not verify the Klassen patent number or its filing/issue dates in this session — verification is mandatory before filing.

C. Hardware/MAC‑level timestamping — contemporaneous literature explaining why timestamping should be moved out of the host and into the NIC/MAC hardware: "By recording the time‑stamp for each packet in hardware instead of on the host, the error contributions from interrupt latency, buffering, host processing time, and the unreliable host clock can all be eliminated," and noting that "[t]ime‑stamps for transmitted packets are generated before the packet is sent" (core.ac.uk thesis).

D. Switch/ASIC port architecture — the patent's own specification concedes that forwarding engines, per‑port egress queues, packet generators and multi‑input schedulers are conventional ("according to methods well‑known in the relevant arts," 8:lines describing step 204).

4.2 Motivation to combine (KSR rationales, articulated)

1. Same field, same problem, same solution type. All of A–C address active in‑network delay/jitter measurement using timestamped probe and reply packets. § 103 combinations are strongest when references are analogous art addressing the common problem of network performance verification.
2. The patent's own background supplies the motivation. US 7,864,816 admits the prior approaches were deficient because CPU‑hosted test applications "burden the CPUs … cannot handle traffic at wirespeed." That admission is an express design incentive to move the generator and the delay computation into the ASIC/MAC — i.e., to do exactly what E3 and E7 recite. In re Nomiya‑type reasoning: a statement of the problem is itself a teaching toward the solution.
3. Hardware timestamping was a known, standard remedy (Reference C) for the known inaccuracy of software timestamps. "[U]se of a known technique [(hardware timestamping at the MAC)] to improve a similar device [(a switch/NIC)] in the same way" — KSR, and MPEP 2143(A)(3)(i).
4. Standards/SLA pressure. RFC 2679/3393 and ITU‑T I.380 define deliverables (one‑way delay, round‑trip delay, delay variation, loss) that switch vendors were commercially compelled to expose in‑box. "Design incentives and other market forces can prompt variations of it" — KSR.
5. Predictable results. Combining a timestamped probe generator (A/B) with a hardware timestamp unit and a MAC‑resident controller (C) yields nothing more than the predictable sum of prior‑art functions: a delay number. No new interoperability, no unexpected property.

4.3 Mapping table — Ground 1

4.4 The contested element — "a network delay that includes a queue delay"

This is the only limitation that differentiates the granted claims from the as‑filed disclosure (the specification and abstract speak of a timestamp "representing a time of transmission"; the granted claims say "time of generation" and add "includes a queue delay"). That divergence is, in the public record, strong circumstantial evidence that the applicant amended during prosecution to escape art that taught transmit‑time timestamping. (The prosecution history is not in the supplied record — flagged as an inference, not a finding. Obtaining the file wrapper is item #1 on the verification checklist.)

Three independent § 103 attacks on E7:

1. Inherency. Any probe timestamped at creation must traverse the local egress queue before leaving the device. A delay computed from that timestamp to reply receipt necessarily includes the queuing time. Prior‑art software probe generators (Klassen; the class of "ping from the host" tools catalogued in the petition excerpts) timestamp before the packet is handed to the driver/queue. The claim recites the inherent consequence of the prior‑art measurement, which is not a patentable difference. Source: core.ac.uk thesis ("Time‑stamps for transmitted packets are generated before the packet is sent").
2. Express prior‑art recognition of the problem. The sender‑side interval between timestamping and actual transmission, and its impact on measured delay, is a recognized source of error in the active‑measurement literature (RFC 2679, and the discussion of timestamp accuracy in Reference C). A POSITA seeking a device‑characterization metric — as opposed to a pure path metric — would deliberately bracket the local queue by choosing the generation timestamp as the start point. That is the "applying a known technique to a known device ready for improvement" rationale.
3. Commercial realism. The measured quantity is what a "ping‑style" in‑box test reports. Because the claims were drafted to capture that arithmetic, the queue‑delay recitation reads as a description of a result, not a mechanism. A claim that recites a result inherent in the prior‑art practice is obvious.

Residual risk: a tribunal could read "includes a queue delay" as a deliberate, claimed measurement capability (i.e., the device intentionally quantifies its own queuing contribution), which would require a reference teaching the purpose. If so, the petitioner should add a device‑latency reference — note that US 6,975,656 B1, Method and system for accurately calculating latency variation on an end-to-end path in a network, expressly frames latency as comprising device processing plus queuing and discusses "queuing traffic in the device's memory" (US6975656B1). Its filing date must be verified — it issued 2005‑12‑13, after the priority date, so it is only available as pre‑AIA §102(e) art if its filing date precedes January 7, 2005, which I could not confirm in this session.

5. Ground 2 — reply‑packet timestamps (claims 3–5, 18–20, 27–29, 42–44) and claims 49–52

5.1 Claims 3–5 family (third timestamp in the reply, either as reply‑Tx time or request‑Rx time)

Single‑reference read: ICMP Timestamp / Timestamp Reply (RFC 792) carries three timestamps in the reply — Originate Timestamp, Receive Timestamp, and Transmit Timestamp — with the Receive Timestamp defined as "the time the echoer first touched [the message] on receipt" (RFC 792, pp. 16–17, as quoted in the PTAB petition excerpts). That maps element‑for‑element onto claim 4 ("third data … represents a time of transmission of the second packet") and claim 5 ("third data … represents a time of receipt of the first packet"). The petition excerpts also collect corroborating art on the same point (Zhang '404, Zhang '706, Zhang '223, Link, Beaven, Auerbach) — useful as § 103 corroboration of the state of the art, though each needs independent verification.

Combination: RFC 792 (reply‑packet timestamps) + RFC 2679/2681 (delay arithmetic) + Reference C (hardware/MAC timestamping). Motivation: implementing the well‑known ICMP timestamp exchange in the MAC/ASIC of a switch test port so that timestamps are hardware‑accurate and wirespeed‑capable. Predictable result.

5.2 Claims 3/18/27/42 generally

Also met by the OWAMP/TWAMP 4‑timestamp model (T1–T4) and by the general ICMP echo model. Caution on dates: RFC 5357 (TWAMP) is October 2008 and RFC 4656 (OWAMP) is September 2006 — both post‑date the 2005 priority and are NOT prior art. OWAMP/TWAMP are useful only as evidence of later industry consensus; do not plead them as art. The pre‑2005 equivalents to plead are RFC 792 (1981), RFC 2330 (1998), RFC 2679/2680/2681 (1999), RFC 3393/3432 (2002), and RFC 2722/2720/2723 (1999).

5.3 Claims 49–52 (delay computed from an explicit transmit‑time timestamp)

Claims 49–52 add: the controller includes in the first packet third data representing a time of transmission when the first packet is transmitted, and calculates the delay from that time and the reply‑receipt time.

• This is a direct, unremarkable read on the prior art: RFC 2679's source‑send timestamp; ICMP's Transmit Timestamp; and Reference C's hardware timestamp at the moment of transmission. There is no new mechanism — it is the same measurement moved by one event in the pipeline.
• Motorola/design‑choice framing: choosing to sample the clock at egress rather than at generation is (a) a "simple substitution of one known element for another" and (b) an obvious design choice with a recognized benefit (excluding sender‑side queuing error from a path delay measurement).
• Internal inconsistency to exploit. Because claim 49 depends on claim 1, it incorporates E7 ("includes a queue delay") while simultaneously requiring a computation (Tx→Rx) that mathematically excludes the egress queue delay. Claims 50–52 have the same defect. This is a §112(b) problem (§11) and a §103 problem: to the extent the claims are construed to avoid the inconsistency, they read squarely on the prior‑art transmit‑timestamp art; to the extent they are construed literally, they are indefinite.
• Net assessment: claims 49–52 are the weakest claims in the patent and should be the lead targets.

6. Ground 3 — jitter (claims 6, 21, 30, 45)

Straightforward. RFC 3393 (IPDV) defines jitter as the variation of one‑way delay across a stream of packets; RFC 3432 defines periodic‑stream measurement. Klassen expressly records "best/average/worst/standard deviation … for packets," which is the very computation the specification names ("the network jitter can be determined as the standard deviation of the network delays"). Combination with Ground 1 or 2 is a near‑compelled one: once you have multiple delay samples (RFC 2681 round‑trip metric applied repeatedly), computing their variation is a routine statistical step. Independent claims 1/16/25/40 already recite "a plurality of" capability implicitly through the packet generator and scheduler; the dependent jitter claims add only the arithmetic.

7. Ground 4 — classifier / counter / property definitions (claims 9–11, 15, 22–24, 33–35, 39, 46–48)

Primary reference: RMON / RMON2 (RFC 1757, Feb. 1995; RFC 2021, Jan. 1997); corroborated by the Traffic Flow Measurement architecture (RFC 2722, RFC 2720 Meter MIB, RFC 2723 flow specification language, all Oct. 1999).

Motivation: the patent's own specification explains the counter's purpose is "to support a packet loss calculation by another ASIC" — i.e., the exact purpose served by RMON channels and by loss‑measurement probes counting a defined flow at two points. Combining an existing RMON filter/counter block with the Ground 1/2 test‑packet generator is the routine union of two known switch features (management counters + active probing) with a predictable result. Whether the classifier is a TCAM with "dual lookup" (as the specification prefers) is an unclaimed implementation detail — no claim recites TCAM.

8. Ground 5 — queue/scheduler architecture and packaging claims

• Claims 7 / 31 (egress queue + test queue + 2‑input scheduler): The patent concedes the elements are conventional. Multi‑input egress schedulers (strict priority, WRR, DWRR) feeding a MAC are the standard switch/NIC egress architecture. Additional motivation: Klassen teaches that probative packets are transmitted with class‑of‑service/priority bits so that they experience the "level of service accorded to the class," which requires injecting test packets into the same scheduling structure as traffic — precisely the two‑input arrangement of claim 7. The patent's own stated benefit ("permits ASIC 100 to conduct network testing while also handling regular network traffic") is the same benefit.
• Claims 8 / 32 (ingress queue): Conventional; admitted.
• Claims 12 / 36 (network switch), 13 / 37 (network device), 38 (NIC), 14 (wireless AP/client): Packaging claims. Under In re Schreiber‑type reasoning and MPEP 2143, reciting a known article (switch, device, NIC) containing the claimed IC adds no patentable weight absent a new functional relationship.
• Claims 15 / 39 (user interface for property definitions + counter retrieval): Met by the RMON/SNMP management surface, or by any switch CLI. Alternatively, if construed to require a specific GUI, still obvious over an RMON manager application.

9. Grounds that would FAIL — why the supplied Prior art section cannot be used as‑written

Applying the operating rule that patent numbers are interpreted literally and that search results control:

Do not plead any of the four verified‑mismatched references. If the earlier drafts of this analysis were used to prepare a notice of invalidity or IPR exhibit list, that list must be corrected immediately.

10. Secondary considerations (objective indicia)

On the record provided, I see no evidence of nexus‑bearing secondary indicia:

• No litigation (per the previously generated Litigation section) → no infringement‑driven commercial‑success narrative for the claimed features.
• No PTAB proceedings → no prior adjudication of validity or claim scope.
• No unexpected results in the specification — the specification asserts only the expected benefits (measure at wirespeed, offload the CPU). It does not claim, and does not enable a showing of, any surprising accuracy, throughput, or latency‑exclusion advantage attributable to "queue delay."
• No long‑felt need / failure of others documented in the file as provided.
• The assignment history shows ordinary corporate succession within an operating‑company family (Radlan → Marvell Software Solutions Israel → Marvell International → Cavium → Marvell Asia Pte), which is neutral on obviousness.

A patent owner would likely argue "industry praise" and "copying" if Marvell switch products embody the feature. Absent a nexus to the queue‑delay/generation‑timestamp limitations, such evidence is entitled to little weight.

11. Claim‑construction and §112 interactions (these shape the §103 case)

1. "a first packet of the first data received by the at least one of the ports from the network." The packet generator originates the packet, yet the claim says the packet is received by the port from the network. The specification is squarely to the contrary (the packet is generated in the MAC and transmitted out; nothing in the spec has it arriving from the network). This is a probable drafting error and a serious §112(b) indefiniteness candidate under Nautilus.
   • Construed in light of the specification (Phillips) as "…[transmitted] from the at least one of the ports [onto] the network," the prior‑art mapping is clean and Ground 1 reads on it.
   • Constructed literally (packet is generated by the port and received by the port from the network), the claim would require an in‑line return path and is indefinite; an IPR petitioner should propose the specification‑consistent construction in the petition and pre‑empt the patent owner's contrary reading.
2. "time of generation" and "includes a queue delay" lack explicit written‑description support. The specification never uses "queue delay," never distinguishes generation time from transmission time, and repeatedly describes the timestamp as "represent[ing] a time of transmission." This is a strong §112(a) district‑court attack, and it also supports the § 103 position that the "queue delay" recitation is a result, not a mechanism. IPR cannot reach §112 — plan accordingly (§1.1).
3. Claim 49–52 internal inconsistency (see §5.3): incorporates E7 while requiring a calculation that excludes it.
4. Pre‑AIA §103(c) and the sibling application. The related application US 11/031,984 → US 8,036,123 B1 ("Integrated circuit for network stress testing," filed 2005‑01‑07, common priority to 60/642,483, common ownership at the time of invention) is disqualified as prior art under pre‑AIA §103(c) even if it otherwise qualified under §102(e). Do not build any ground on the family members US 8,036,123 B1 or US 8,854,961 B1.

12. Confidence, verification checklist, and recommended next steps

Confidence levels:

• High: the four bibliographic mismatches (§1.2); the legal framework; the element decomposition; the ICMP/RFC 792 and RMON mappings; the internal inconsistency of claims 49–52.
• Moderate: the inherency/obviousness argument on "queue delay"; the Klassen characterization (title, number, and dates unverified; excerpts come from a third‑party petition).
• Low / unverified: US 6,795,450 B1's existence and content; US 6,975,656 B1's filing date (critical to §102(e) eligibility); the "54 prior art citations" figure; the Klassen patent number; whether a prosecution‑history amendment actually occurred.

Verification checklist before filing anything:

1. Pull the full prosecution history (USPTO PatentCenter) for US 11/056,753 to confirm why "time of generation … includes a queue delay" and "received by the at least one of the ports from the network" were added, and to identify the art the examiner applied.
2. Verify every reference number to title, dates, and content from the authoritative record before pleading it. Explicitly re‑verify US 5,307,354; US 5,579,308; US 6,452,945; US 2003/0103493; and US 6,795,450.
3. Verify the Klassen reference number and its §102(b) date; likewise Zhang '404 / '706 / '223, Auerbach, Link, Beaven, Hunt, Ricciulli.
4. Verify US 6,975,656 B1 filing date for §102(e) availability.
5. Obtain the full text of RFC 1757, RFC 2021, RFC 792, RFC 2330, RFC 2679, RFC 2680, RFC 2681, RFC 3393, RFC 3432, RFC 2722/2720/2723 and pin exact pin cites (IPR petitions are lost on unsupported pin cites).
6. Search for contemporaneous hardware/ASIC timestamping art (1998–2004) assigning timestamps in the MAC/egress path — this is the most likely place to find a clean single‑reference or two‑reference read on E3+E4+E7.

Recommended §103 ground structure for a petition (all §§102/103‑eligible, patents and printed publications only):

Bottom line: the strongest § 103 case is not the one sketched in the Prior art section. It rests on (i) the IPPM/RFC active‑measurement framework plus ICMP reply timestamps, (ii) the Klassen‑type probe generator, (iii) hardware/MAC‑level timestamping as the known architectural fix for the exact problem the patent's own background recites, and (iv) RMON for the classifier/counter claims. The single point of genuine resistance is the "includes a queue delay" recitation added to the granted claims — and that recitation is vulnerable on inherency, on lack of written‑description support, and on the internal contradiction it creates with claims 49–52. Claims 49–52 should be the first target.