Product Testing and Packet Capture
Product testing and packet capture examine a working product to record what it actually does. Packet sniffing, penetration testing, and information gathering tools decode the network interaction between systems and expose the messaging protocols and content shared between devices.
Our team conducts in-depth product testing using packet sniffing, penetration testing, and information gathering tools. These methods are beneficial for identifying evidence of patent use, validating claim mapping, supporting litigation, and developing claim charts.
Setup
The product, or a live deployment of it, is configured to generate the interaction of interest.
Traffic capture
Packet sniffing and information gathering tools record the live network exchange.
Protocol decoding
Messaging protocols and message content are decoded from the raw capture.
Claim mapping
Findings are tied back to specific claim elements for evidence of use.
Evidence report
A written report covers the test setup, the methods used, and the findings.
What the testing establishes
Decode network interaction
Traffic between systems is captured and decoded, so the messaging protocols and content shared between devices in real-world implementations can be read directly.
Claim chart evidence
Where a claim element describes behaviour no published document records, captured traffic supplies the messages, order, fields and values instead.
Real-world behaviour
Testing is done on the product as it is deployed, so the behaviour recorded is the behaviour an ordinary user would produce.
Written reporting
A report documents the test setup, the methods used and the findings, ready to support litigation or licensing work.
Documented behaviour vs. captured behaviour
A claim chart built from specifications and manuals rests on what a product is documented to do. Packet capture shows what it actually does.
| Published documents | Captured traffic | |
|---|---|---|
| Source | Specifications, manuals, product literature | Live traffic from the product as deployed |
| Shows | What the product is described as doing | The messages sent, their order, fields and values |
| Risk if relied on alone | Some claim elements describe behaviour no document records | Validates or contradicts the assumed reading before a chart is finalised |
Captured evidence comes from what a product actually does, not from what it is described as doing.
What you receive
- Decoded analysis
- Of the network interaction observed between the tested systems.
- Protocol detail
- Messaging protocols and content shared between devices in real-world implementations.
- Captured evidence
- Of patent use that validates an existing claim mapping.
- Written report
- Covering the test setup, the methods used, and the findings.
Frequently asked questions
What is product testing and packet capture?
Hands-on examination of a live product to record how it behaves. Traffic between devices is captured and decoded, so the messaging protocols and content exchanged can be read directly. Because the record comes from real-world implementations rather than documents, it serves as evidence of patent use, validates claim mapping, supports litigation, and feeds claim chart development.
How does packet capture support a claim chart?
A claim chart needs evidence for every claim element, and some elements describe behaviour that no published document records. Captured traffic supplies it — the messages a device sends, the order they arrive in, the fields they carry, and the values in those fields. Where a capture contradicts the assumed reading, it's far better to find that out before the chart is relied on.
What is recorded during testing?
The sequence of exchanges, the protocol layers involved, and the content of the messages themselves. The work is done on the product as it is deployed, so the behaviour recorded is the behaviour an ordinary user would produce, then tied back to particular claim elements.
What do you need from us to run product testing?
The product itself, or access to a live deployment of it, along with any second device or accessory needed to generate the interaction of interest. It helps to know which claim elements you want evidenced, since that decides which exchanges are worth triggering and capturing — configuration details, firmware or software version, and network setup are worth sharing too.
Scope your product testing
Tell us about the product, the claim elements you need evidenced, and any access constraints, and we'll scope the capture and reporting.
