SEPPi
Enter a patent number, or upload a specification you have not filed yet, and get a SEP (3GPP) matching report that cites the standard's clauses at pinned versions.
How it works
Search by patent number, or upload a pre-grant specification.
Patent claim
incrementing a first counter based on a number of data units transmitted,
3GPP TS 36.322 §5.2.2.1 excerpt
SEPPi compares the patent claims against 3GPP standard documents.
SEP (3GPP) matching analysis report
2 specs cited · 9 clauses
Receive a matching analysis report grounded in 3GPP standard specifications.
2 more features
You can also upload a specification you have not filed. Check the claims and it runs the same sequence as a registered patent, with each clause shown alongside the release it entered the standard in.
Pre-grant patentSee how it works →Got multiple patents? Use Bulk mode: add fields to the search box and screen up to 20 at once.
Bulk modeSee how it works →See it on a real match
A real claim chart, color-coded to map claim language onto 3GPP standard clauses.
Method in a first node for requesting a status report from a second node, the first node and the second node both being comprised within a wireless communication network, the status report comprising at least one of positive and negative acknowledgement of data sent from the first node to be received by the second node, wherein the method comprises the steps of:
The claimed pair of nodes is the two ends of one acknowledged-mode RLC link: the transmitting side of an AM RLC entity, which is the side that asks for a report, and its peer AM RLC entity, which is the side that returns one. The report itself is the STATUS PDU, and the standard states its purpose as providing positive and/or negative acknowledgement of the RLC PDUs the peer received — the two kinds of acknowledgement the preamble recites, either of which suffices.
transmitting a sequence of data units or data unit segments to be received by the second node,
An acknowledged-mode entity delivers exactly the two kinds of unit the step recites, and the standard lists them as two separate RLC data PDUs: the AMD PDU and the AMD PDU segment. What leaves the sender is a sequence rather than a set, because each new AMD PDU is given the send-state sequence number when it is delivered to lower layer. The side that receives them, and that returns the acknowledgement for them, is the peer AM RLC entity.
incrementing a first counter based on a number of data units transmitted,
On assembly of each new AMD PDU the transmitting side increments PDU_WITHOUT_POLL by one. The state-variable clause defines that counter as the number of AMD PDUs sent since the most recent poll — a running total kept over transmitted units, which is what this step requires.
incrementing a second counter based on a number of bytes of data transmitted,
In the same list of actions the transmitting side increments BYTE_WITHOUT_POLL by every new byte of Data field element that it maps into the data field of the RLC data PDU, and the state-variable clause defines that counter as the number of data bytes sent since the most recent poll. It is a second running total, kept over volume rather than over units.
A real claim chart generated from 3GPP TS 36.322 (LTE RLC), shown as delivered. Matching colors mark corresponding elements between the claim and the standard.
What is SEPPi?
SEPPi takes the first step of an essentiality assessment —
comparing claims against thousands of pages of 3GPP specifications —
and leaves the cited text in place so you can check the work yourself. A registered patent goes in by number; a specification you have not filed goes in as a file.SEPPi runs on kernalic's kernel ontology. The 3GPP standard is defined there by specification, version and clause, and claims are matched against it, so every citation carries its version and clause.