Prosecution Insights
Last updated: April 19, 2026
Application No. 14/278,994

SYSTEM AND METHOD FOR PROVIDING STATUS REPORTS OF TRANSMITTED DATA PACKETS IN A DATA COMMUNICATIONS SYSTEM

Final Rejection §102§103
Filed
May 15, 2014
Examiner
CRAVER, CHARLES R
Art Unit
3992
Tech Center
3900
Assignee
Texas Instruments Incorporated
OA Round
12 (Final)
60%
Grant Probability
Moderate
13-14
OA Rounds
4y 1m
To Grant
83%
With Interview

Examiner Intelligence

Grants 60% of resolved cases
60%
Career Allow Rate
53 granted / 88 resolved
At TC average
Strong +23% interview lift
Without
With
+22.7%
Interview Lift
resolved cases with interview
Typical timeline
4y 1m
Avg Prosecution
22 currently pending
Career history
110
Total Applications
across all art units

Statute-Specific Performance

§101
4.2%
-35.8% vs TC avg
§103
30.8%
-9.2% vs TC avg
§102
11.3%
-28.7% vs TC avg
§112
32.0%
-8.0% vs TC avg
Black line = Tech Center average estimate • Based on career data from 88 resolved cases

Office Action

§102 §103
DETAILED ACTION This action is responsive to the amendment and Request for Continued Examination (RCE) filed September 18, 2024 (“Amendment”). The instant application is a reissue application of U.S. Pat 8,179,812 B2, issued May 15, 2012 from U.S. Pat. App. Ser. No. 12/236,001 filed September 23, 2008, dependent on U.S. Provisional Pat. App. Ser. No. 60/976,893, filed October 2, 2007 (“the provisional ‘893 Application”). Claims 1-25 were initially pending in the application. By way of amendments, claims 1-4, 6, 7, 11-14, 16, 17, 21, 22, 24-26, 30, 31, 35-42, 44, 45, 47-53, 55, 56, and 58-74 are currently pending in the application. Claims 1, 4, 11, 14, 21, 26, 31, 36, 39, 47, 50, 73, and 74 are independent claims. Claims 1-4, 6, 7, 11-14, 16, 17, 21, 22, 24-26, 30, 31, 35-42, 44, 45, 47-53, 55, 56, and 58-74 stand rejected below. It is noted that the Amendment does not change any of the claims1 and thus the previous grounds of rejection in the Office action mailed August 18, 2023 are unchanged below. As claims of an application for which a RCE has been filed may be finally rejected in the action immediately subsequent to the filing of the RCE (with a submission and fee under 37 CFR 1.114 ) in the case where all the claims in the application after the entry of the submission under 37 CFR 1.114 are identical to the claims in the application prior to the entry of the submission and would have been properly finally rejected on the grounds and art of record in the next Office action if they had been entered in the application prior to the filing of the RCE under 37 CFR 1.114, this action is Final. Reissue Because the instant application does not appear to contain a claim having an effective date on or after March 16, 2013, the America Invents Act First Inventor to File (“AIA -FITF”) provisions do not apply. Instead, the pre-AIA “First to Invent” provisions will govern this proceeding. See 35 U.S.C. § 100 (note). In the event the determination of the status of the application as subject to pre-AIA 35 U.S.C. 102 and 103 is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. Applicant is reminded of the continuing obligation under 37 CFR 1.178(b), to timely apprise the Office of any prior or concurrent proceed-ing in which Patent No. 8,179,812 is or was involved. These proceedings would include interferences, reissues, reexaminations, and litigation. Applicant is further reminded of the continuing obligation under 37 CFR 1.56, to timely apprise the Office of any information which is mate-rial to patentability of the claims under consideration in this reissue appli-cation. These obligations rest with each individual associated with the filing and prosecution of this application for reissue. See also MPEP §§ 1404, 1442.01 and 1442.04. Applicant is notified that any subsequent amendment to the specification and/or claims must comply with 37 CFR 1.173(b). Priority The instant Patent includes a claim for domestic priority under 35 U.S.C. 119(e) to Provisional Application 60/976,893, filed October 2, 2007. However, it is noted that patent claims 4, 7, 11-14, 16, 17, 21, 22, 25, 26, 30, 31, 35, 39, 41, 42, 47-53, 55, 56, 58-72, and 74 include limitations not supported by the Provisional application. Under 35 U.S.C. 119(e), the written description and drawing(s) (if any) of the provisional application must adequately support and enable the subject matter claimed in the nonprovisional application that claims the benefit of the provisional application. In New Railhead Mfg., L.L.C. v. Vermeer Mfg. Co., 298 F.3d 1290, 1294, 63 USPQ2d 1843, 1846 (Fed. Cir. 2002), the court held that for a nonprovisonal application to be afforded the priority date of the provisional application, “the specification of the provisional must ‘contain a written description of the invention and the manner and process of making and using it, in such full, clear, concise, and exact terms,’ 35 U.S.C. § 112¶1, to enable an ordinarily skilled artisan to practice the invention claimed in the nonprovisional application.” MPEP 201.11(I)(A). Amended dependent claims 7, 17, 22, 41, 42, 52, and 53 require receiving a retransmit SN in a re-segmented data packet from a sending unit, i.e. retransmission, specifically as to a segment. The provisional ‘893 Application fails to disclose receiving at least one retransmit data packet from a sending unit, or the makeup of such a retransmit data packet such as the inclusion of a data portion. Further, the provisional ‘893 Application does not disclose a storage, processor or transceiver/receiver/transmitter element (as to claims 11, 14, 21, 26, 31, 47, 50, 58, and 74) nor any means or step of generating the disclosed status packet (claims 1,4, 11, 14, 21, 31, 47, 50, 58, 73, and 74), or transmitting such to a sender, nor a means or step of extracting packet identifiers (claims 4, 14, 39, and 50), nor any timer set for determining a packet loss (claims 4, 14, 39, and 50). Lastly, dependent claims 61-72 recite wait times between 10 and 100ms which are not disclosed in the provisional ‘893 Application. As such, claims 4, 7, 11-14, 16, 17, 21, 22, 25, 26, 30, 31, 35, 39, 41, 42, 47-53, 55, 56, 58-72, and 74 of the instant Patent in this Reissue Application will be considered to have a filing date of the instant Patent Application, namely September 23, 2008, and “intervening art” references will be allowed to be applied to such claims. See MPEP 201.11. Reissue Oath/Declaration The reissue oath/declaration (Reissue Application Declaration by the Inventor, PTO/AIA /05) filed with this application is defective (see 37 CFR 1.175 and MPEP § 1414.01) because it fails to identify at least one error which is relied upon to support the reissue application. The given error statement (“Claims 11, 14 and 18 contain unnecessary limitations”) fails to indicate an error upon which a reissue is based as one which causes the patent to be “deemed wholly or partly inoperative or invalid, by reason of a defective specification or drawing, or by reason of the patentee claiming more or less than he had a right to claim in the patent.” The declaration further fails to identify at least one broadened claim; it is noted that claim 18 is canceled and issued claim 14 is a dependent claim, and enlarging the scope of a dependent claim is not broadening. See MPEP § 1414 II. A general statement, e.g., that all claims are broadened, is not sufficient to satisfy this requirement. In identifying the error, it is sufficient that the reissue oath/declaration identify a single word, phrase, or expression in the specification or in an original claim, and how it renders the original patent wholly or partly inoperative or invalid. Further, all claims stand rejected below as attempting recapture of surrendered subject matter. Recapture of surrendered subject matter is not a correctable error under § 251, thus any error identified by Patent Owner must not comport with such recapture. Applicant is required to submit a corrected Reissue Application Declaration by the Inventor PTO/AIA /05. Claim Rejections - 35 USC § 251 Claims 1-4, 6, 7, 11-14, 16, 17, 21, 22, 24-26, 30, 31, 35-42, 44, 45, 47-53, 55, 56, and 58-74 are rejected as being based upon a defective reissue oath/declaration under 35 U.S.C. 251. See 37 CFR 1.175. The reasons for the defect are noted above. Claims 1-4, 6, 7, 11-14, 16, 17, 21, 22, 24-26, 30, 31, 35-45, 47-53, 55, 56, and 58-74 are rejected under 35 U.S.C. 251 as being an improper recapture of broadened claimed subject matter surrendered in the application for the patent upon which the present reissue is based. See Greenliant Systems, Inc. et al v. Xicor LLC, 692 F.3d 1261, 103 USPQ2d 1951 (Fed. Cir. 2012); In re Shahram Mostafazadeh and Joseph O. Smith, 643 F.3d 1353, 98 USPQ2d 1639 (Fed. Cir. 2011); North American Container, Inc. v. Plastipak Packaging, Inc., 415 F.3d 1335, 75 USPQ2d 1545 (Fed. Cir. 2005); Pannu v. Storz Instruments Inc., 258 F.3d 1366, 59 USPQ2d 1597 (Fed. Cir. 2001); Hester Industries, Inc. v. Stein, Inc., 142 F.3d 1472, 46 USPQ2d 1641 (Fed. Cir. 1998); In re Clement, 131 F.3d 1464, 45 USPQ2d 1161 (Fed. Cir. 1997); Ball Corp. v. United States, 729 F.2d 1429, 1436, 221 USPQ 289, 295 (Fed. Cir. 1984). A broadening aspect is present in the reissue which was not present in the application for patent. The record of the application for the patent shows that the broadening aspect (in the reissue) relates to claimed subject matter that applicant previously surrendered during the prosecution of the application. Accordingly, the narrow scope of the claims in the patent was not an error within the meaning of 35 U.S.C. 251, and the broader scope of claim subject matter surrendered in the application for the patent cannot be recaptured by the filing of the present reissue application. It is noted that the following is the three step test for determining recapture in reissue applications (see: MPEP 1412.02 II.): “(1) first, we determine whether, and in what respect, the reissue claims are broader in scope than the original patent claims; (2) next, we determine whether the broader aspects of the reissue claims relate to subject matter surrendered in the original prosecution; and (3) finally, we determine whether the reissue claims were materially narrowed in other respects, so that the claims may not have been enlarged, and hence avoid the recapture rule.” Step 1: MPEP 1412.02 II. A. In the instant case and by way of the recent amendment, Applicant seeks to broaden or present broadened independent claims 1, 4, 11, 14, 21, 26, 31, 36, 39, 47, 50, 58, 73, and 74 which are broader than the original independent claims, at least by deleting/omitting the patent claim language requiring reception of a retransmit packet or that such includes at least a segment of the missing packet data payload, as well as the control packet comprising a header including a next-packet-to-be-received identifier. Thus claims 1, 4, 11, 14, 21, 26, 31, 36, 39, 47, 50, 58, 73, and 74 are broadened claims. Step 2: MPEP 1412.02 II. B. The record of the prior 12/236,001 application prosecution indicates that in an Amendment filed September 9, 2011 in an attempt to overcome rejections over prior art references (Jr. and Phan), Patent Owner argued in his Remarks that the prior art failed to properly teach or suggest a step of reception of a retransmit packet, specifically portions of the missing data as claimed in the issued claims: Conspicuous by its absence is any mention, teaching or suggestion by Jr to "transmittingat least one status control to said sending unit." Jr fails to teach or suggest a feedback mechanism to request re-transmission from the sending unit. In contrast, Jr presents a method to ignore a failed data packet transmission and continue with the next good cell received as the first cell of a next data packet; so cells; are added to packet assembly queue 516 until a first cell is received. Clearly, one of ordinary skill in the art recognizes that the present claims address a method of recovering from a data transmission loss by requesting re-transmission of the missing (failed) packet via the use of a missing packet identifier. Jr teaches nothing of the sort. … Again, conspicuous by its absence is any mention, teaching or suggestion by Jr to "receiving at least one retransmit data packet from said sending unit." As such, Jr fails to teach or suggest retransmission of the missing or corrupted portions of the previous packet. Further, Jr fails to teach or suggest a feedback mechanism utilizing a retransmit data packet to request re-transmission from the sending unit. In contrast, Jr presents a method to ignore a failed data packet transmission and continue with the next good cell received as the first cell of a next data packet; so cells; are added to packet assembly queue 516 until a first cell is received. Clearly, one of ordinary skill in the art recognizes that the present claims address a method of recovering from a data transmission loss by requesting re-transmission of the missing(failed) packet via the use of a missing packet identifier. Remarks at 11-13 (emphasis in original). The record further shows that in said same Argument Patent Owner asserted that the prior art failed to properly teach or suggest the control packet comprising a header, as well as the retransmit packet including at least a segment of the missing packet data payload: Therefore, the Examiner has failed to show that any combination of Jr and Phan teachesor suggests "transmitting at least one status control packet to said sending unit, said control packet comprising a header including a next packet identifier" OR "receiving at least one retransmit data packet from said sending unit, said retransmit data packet comprising at least a segment of said data payload in said missing data packet associated with said missing packet identifier" as required by Claim 1. … Therefore, the Examiner has failed to show that any combination of Jr and Phan teachesor suggests "configuring at least one status control packet for transmission to said sending unit, said control packet comprising a header" OR "at least one status payload portion including at least one missing packet identifier" OR "transmit packet identifier for said missing data packet" OR "retransmit data packet comprises at least a segment of said data payload" as required by Claim 11. … Therefore, the Examiner has failed to show that any combination of Jr and Phan teachesor suggests "configuring at least a status control packet for transmission to said sending unit, said control packet comprising a header including a next packet identifier" OR "receiving ... at least one retransmit data packet from a sending unit ... said retransmit data packet comprises at least a segment of said data payload in said missing data packet associated with said missing packet identifier" as required by Claim 21. Remarks at 13, 21, 30 (emphasis in original). Lastly, said arguments specifically argued that the prior art applied to the claims did not teach a packet header comprising a next packet identifier for a next data packet anticipated to be received, as to the subject matter now removed from claims 1, 4, 11, 14, 21, 26, 31, 36, 39, 47, 50, 58, 73, and 74. Note the portion cited above, stating that Jr. and Phan do not disclose or suggest “said control packet comprising a header including a next packet identifier”. Subject matter is previously surrendered during the prosecution of the original application by reliance on an argument/statement made by applicant that a limitation of the claim(s) defines over the art. In Hester, supra, the Federal Circuit held that the surrender that forms the basis for impermissible recapture “can occur through arguments alone”. Hester, 142 F.3d at 1482,46 USPQ2d at 1649. It is noted that a Patent Owner (reissue applicant) is bound by the argument that applicant relied upon to overcome an art rejection in the original application for the patent to be reissued, regardless of whether the Office adopted the argument in allowing the claims. Therefore, in the instant case the claimed limitations as to transmitting a retransmit packet, requiring the control packet comprise a header, and the retransmit packet including at least a segment of the missing packet data payload relates to surrendered subject matter and some of the broadening of the reissue claims, as noted above, are in the area of such surrendered subject matter. Step 3: MPEP 1412.02 II. C. It is noted that the previous requirement of a retransmit packet has been entirely eliminated from the claims, including the requirement of a portion of the missing data. Rather now the claims disclose reception of a “re-segmented” packet which is not any retransmission of data, while claims 26 and 31 do not even recite this much. Thus there is recapture. It is further noted that the previous requirement of a next-to-be-received packet identifier has been broadened. However, these claims are not further materially narrowed in other respects that relate to the surrendered subject matter to avoid recapture. MPEP 1412.02 III. B. 1. Here, it must be determined what portion of the amendment or argued limitation has been retained, and whether the retained portion materially narrows the original claims to avoid recapture. See Youman, 679 F.3d at 1346 n.4, 102 USPQ2d at 1870 n.4 ("'original claims' are defined as 'the claims before surrender'"). "[I]f the patentee modifies the added [or argued] limitation such that it is broader than the patented claim yet still materially narrows relative to the original claim, the recapture rule does not bar reissue." Id. at 1347, 102 USPQ2d at 1870. On the other hand, if the retained portion of the modified limitation is "well known in the prior art," impermissible recapture has not been avoided. See Mostafazadeh, 643 F.3d at 1361, 98 USPQ2d at 1644. It is to be noted that if the retained portion of the modified limitation is well known in the prior art, then impermissible recapture exists, even in a case where a further limitation which is not related to the surrendered subject matter (i.e., a limitation that does not materially narrow the claims) has been added to define the claims over the art. Id. Here, the Examiner notes that the remaining broadened limitation, as to sending an SN as to a received packet, are well-known in the art as demonstrated by the rejection below. Therefore improper recapture of broadened claimed subject matter surrendered in the application is present in the instant reissue application. Claim Interpretation The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph: An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof. The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when pre-AIA §112 ¶6 is invoked. As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under §112 ¶6: (A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function; (B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and (C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function. Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with §112 ¶6. The presumption that the claim limitation is interpreted under §112 ¶6, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function. Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with §112 ¶6. The presumption that the claim limitation is not interpreted under §112 ¶6, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function. This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under §112 ¶6, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “a storage element for receiving” in claims 11, 14, 21, 47, 50, 58; “processing element…configured for recognizing…and configuring…” in claims 11, 14, 21, 47, 58; “a processing element configured to recognize a failure…and to generate a status protocol data unit…” in claim 31; “a processing element configured for extracting…identifying…specifying…and configuring” in claim 50; “a processing element configured to recognize a failure…and to generate…” in claim 74; Here, the Examiner applies the three-pronged analysis disclosed in MPEP 2181(I) as follows: As to prong A, in elements 1-5 above the term “element” is considered a substitute for “means” as it is a generic placeholder or “nonce” term having no specific structural meaning for performing the claimed function. As to prong B, the generic placeholder term “element” is further modified by functional language, here “configured to”. As to prong C, the generic placeholder term “element” is not modified by sufficient structure for performing the claimed function. Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof. In this case, the structure as to the storage element 1 is identified in the disclosure in 4/39-44, as a processing element which “…can be implemented using any suitable data storage technology, such as semiconductor-based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory.” As to the processor elements 2-5 above, the structure is identified in the disclosure in 4/39-44, as a processing element which “…can be of any type suitable to the local technical environment, and can include one or more of general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on a multi-core processor architecture…” However, for a computer-implemented §112 ¶6 claim limitation, the specification must disclose an algorithm for performing the claimed specific computer function, or else the claim is indefinite under 35 U.S.C. 112(b). See Net MoneyIN, Inc. v. Verisign. Inc., 545 F.3d 1359, 1367, 88 USPQ2d 1751, 1757 (Fed. Cir. 2008). See also In re Aoyama, 656 F.3d 1293, 1297, 99 USPQ2d 1936, 1939 (Fed. Cir. 2011) ("[W]hen the disclosed structure is a computer programmed to carry out an algorithm, ‘the disclosed structure is not the general purpose computer, but rather that special purpose computer programmed to perform the disclosed algorithm.’") (quoting WMS Gaming, Inc. v. Int’l Game Tech., 184 F.3d 1339, 1349, 51 USPQ2d 1385, 1391 (Fed. Cir. 1999)). In cases involving a special purpose computer-implemented means-plus-function limitation, the Federal Circuit has consistently required that the structure be more than simply a general purpose computer or microprocessor and that the specification must disclose an algorithm for performing the claimed function. See, e.g., Noah Systems Inc. v. Intuit Inc., 675 F.3d 1302, 1312, 102 USPQ2d 1410, 1417 (Fed. Cir. 2012); Aristocrat, 521 F.3d at 1333, 86 USPQ2d at 1239. For a computer-implemented means-plus-function claim limitation invoking 35 U.S.C. 112(f) the Federal Circuit has stated that "a microprocessor can serve as structure for a computer-implemented function only where the claimed function is ‘coextensive’ with a microprocessor itself." EON Corp. IP Holdings LLC v. AT&T Mobility LLC, 785 F.3d 616, 622, 114 USPQ2d 1711, 1714 (Fed. Cir. 2015), citing In re Katz Interactive Call Processing Patent Litigation, 639 F.3d 1303, 1316, 97 USPQ2d 1737, 1747 (Fed. Cir. 2011). "‘It is only in the rare circumstances where any general-purpose computer without any special programming can perform the function that an algorithm need not be disclosed.’" EON Corp., 785 F.3d at 621, 114 USPQ2 at 1714, quoting Ergo Licensing, LLC v. CareFusion 303, Inc., 673 F.3d 1361, 1365, 102 USPQ2d 1122, 1125 (Fed. Cir. 2012). "‘[S]pecial programming’ includes any functionality that is not ‘coextensive’ with a microprocessor or general purpose computer." EON Corp., 785 F.3d at 623, 114 USPQ2d at 1715 (citations omitted). "Examples of such coextensive functions are ‘receiving’ data, ‘storing’ data, and ‘processing’ data—the only three functions on which the Katz court vacated the district court’s decision and remanded for the district court to determine whether disclosure of a microprocessor was sufficient." 785 F.3d at 622, 114 USPQ2d at 1714. Thus, "[a] microprocessor or general purpose computer lends sufficient structure only to basic functions of a microprocessor. All other computer-implemented functions require disclosure of an algorithm." Id., 114 USPQ2d at 1714 Looking to the disclosure, the algorithm disclosed as to elements 2-5 above with respect to claims 11, 21, 31, and 47 is shown in 5/61-6/4 and 6/35-41 and FIG 3 elements 324 and 334 showing algorithmic steps of determining a failure to receive a packet and constructing a status control packet. The algorithm disclosed as to elements 2-5 above with respect to claims 14 and 50 is shown in 5/61-6/10 and 6/35-41 and FIG 3 elements 324, 326, and 334 showing algorithmic steps of determining a failure to receive a packet by way of setting a timer and constructing a status control packet. If applicant does not intend to have this/these limitation(s) interpreted under §112 ¶6, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under §112 ¶6. Claim Rejections - 35 USC § 102 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. The following is a quotation of the appropriate paragraphs of pre-AIA 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action: A person shall be entitled to a patent unless – (a) the invention was known or used by others in this country, or patented or described in a printed publication in this or a foreign country, before the invention thereof by the applicant for a patent. Claims 26, 30, 31, 35, and 74 are rejected under pre-AIA 35 U.S.C. 102(a) as being anticipated by “Evolved Universal Terrestrial Radio Access (E-UTRA) Radio Link Control (RLC) protocol specification (Release 8)”, 3rd Generation Partnership Project (3GPP) TS 36.322 v2.0.0 (2007-11) (hereinafter “TS 36.322”), which references and incorporates “Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2 (Release 8)”, 3rd Generation Partnership Project (3GPP) TS 36.300 v8.2.0 (2007-09) (hereinafter “TS 36.300”), both of record. This is an intervening art rejection. As to claim 26, TS 36.322 discloses: A system comprising: a transceiver configured to transmit a status protocol data unit, the status protocol data unit comprising: TS 36.322 discloses a system including means to transmit PDUs from a transmitting element to a receiving element. TS 36.322 discloses that a UE or BS may do both. TS 36.322 at Sec. 4.2.1-4.2.1.1 pp. 7-9 and Sec. 4.2.1.3 p. 11. TS 36.322 discloses that the PDU may be a status PDU. Id. at Sec. 5.2.1 pp. 18-19, Sec. 6.1.2 p. 21 and at Sec. 6.2.1.6 p. 25. As the entities may transmit and receive data over a radio link, they inherently comprise a transceiver. Note that TS 36.322 references and incorporates TS 36.300 (TS 36.322 at Sec. 2), which discloses apparatus details as to the UE and eNB, showing processing which occurs therein as well as a transmitter and receiver. TS 36.300 at, inter alia, Sec. 5.1.2, 5.2.1, 5.2.2, and 5.2.7.3. a data/control flag specifying whether the status protocol data unit contains data or control information; TS 36.322 discloses that the status PDU may include a D/C flag specifying if it contains data or control information. TS 36.322 at Sec. 6.2.2.9 p. 27. a control field specifying a type of control protocol data unit; TS 36.322 discloses that the status PDU contains a control field specifying a type of control PDU. TS 36.322 at Sec. 6.2.2.13 p. 28. an acknowledgement sequence number field indicative of a sequence number for a packet received by the system; The status PDU is described in Sec. 6.2.1.6, and includes a header followed by an ACK_SN, which is a packet identifier indicative of a packet received from the sending unit. Id. at Sec. 6.2.1.6 and 6.2.2.14. a first extension field indicating whether a negative acknowledgment is present; TS 36.322 discloses that the status PDU contains an extension field indicating that further information is included, which may include a NACK. TS 36.322 at Sec. 6.2.2.15 p. 28. a negative acknowledgment sequence number field identifying a packet not received; TS 36.322 discloses that the status PDU may include a NACK identifying a packet not received by SN. TS 36.322 at Sec. 6.2.2.16. a negative acknowledgment beginning setoff value; and a negative acknowledgment ending setoff value. TS 36.322 discloses that the status PDU may further include, with the NACK, a beginning and ending offset value indicating a portion of data not received. TS 36.322 at Sec. 6.2.2.16 and 6.2.2.17 p 29. Further as to claim 30, TS 36.322 further discloses that the header and payload of the status control packet are set up such that the packet has a whole number of octets (bytes). TS 36.322 at Sec. 6.2.1.6 p. 25, noting “padding/reserve bits”. As to claim 31, TS 36.322 discloses A system comprising: a transceiver configured to receive retransmit data packets from a sending unit and to receive protocol data units, each protocol data unit associated with a sequence number; TS 36.322 discloses a system including means to transmit PDUs from a transmitting element to a receiving element. TS 36.322 discloses that a UE or BS may do both. TS 36.322 at Sec. 4.2.1-4.2.1.1 pp. 7-9 and Sec. 4.2.1.3 p. 11. TS 36.322 discloses that the PDU may be a status PDU. Id. at Sec. 5.2.1 pp. 18-19, Sec. 6.1.2 p. 21 and at Sec. 6.2.1.6 p. 25. As the entities may transmit and receive data over a radio link, they inherently comprise a transceiver. Note that TS 36.322 references and incorporates TS 36.300 (TS 36.322 at Sec. 2), which discloses apparatus details as to the UE and eNB, showing processing which occurs therein as well as a transmitter and receiver. TS 36.300 at, inter alia, Sec. 5.1.2, 5.2.1, 5.2.2, and 5.2.7.3. The receiver may receive retransmit packets. Id. at Sec. 4.2.1.3.2 pp. 12-13. a processing element configured to recognize a failure to receive at least one other protocol data unit and to generate a status protocol data unit TS 36.322 discloses determining a failure of reception of an RLC PDU. TS 36.322 at Sec. 5.2.3. The element performing such includes the logical programming shown in FIG 4.2.1.3.1-1 on p. 11, which would inherently be performed using a processing element. Note above how TS 36.300 discloses processing specifically. comprising: a one bit data/control flag specifying whether the status protocol data unit contains data or control information; TS 36.322 discloses that the status PDU may include a 1-bit D/C flag specifying if it contains data or control information. TS 36.322 at Sec. 6.2.2.9 p. 27. a three bit control field specifying a type of control protocol data unit; TS 36.322 discloses that the status PDU contains a 3-bit control field specifying a type of control PDU. TS 36.322 at Sec. 6.2.2.13 p. 28. a ten bit acknowledgement sequence number field equal to a sequence number of a packet received by the system; and The status PDU is described in Sec. 6.2.1.6, and includes a header followed by an ACK_SN, which is a 10-bit packet identifier indicative of a packet received from the sending unit. TS 36.322 at Sec. 6.2.1.6 and 6.2.2.14. a one bit extension field having a value of 1 indicating a ten bit negative acknowledgement sequence number field follows; TS 36.322 discloses that the status PDU contains a 1-bit extension field indicating that further information is included, which may include a NACK. TS 36.322 at Sec. 6.2.2.15 pp. 28-29. A value of 1 indicates a NACK field follows. Id. the ten bit negative acknowledgment sequence number field identifying a sequence number not received; TS 36.322 discloses that the status PDU may include a 10-bit NACK identifying a packet not received by SN. TS 36.322 at Sec. 6.2.1.6, FIG 6.2.1.6-1, and Sec. 6.2.2.16 p. 29. a second one bit extension field indicating whether an additional NACK field is present; TS 36.322 discloses that the first extension field indicates that, outside of the NACK, another extension field E1 follows the NACK identifying whether a further additional NACK field is present. TS 36.322 at Sec. 6.2.2.15 pp. 28-29, noting that the first E1 field indicates if a NACK as well as another E1 follows. a one bit additional extension field indicating a fifteen bit beginning setoff value field and a fifteen bit ending setoff value field follow; TS 36.322 discloses another 1-bit additional extension field E2 indicating that two offset values follow, both of which are 15 bits in length. TS 36.322 at Sec. 6.2.2.17 p. 29 and TABLE 6.2.2.17-1. the fifteen bit beginning setoff value field; and the fifteen bit ending setoff value field, and TS 36.322 discloses the two offset value fields in Sec. 6.2.2.16-6.2.2.17 p. 29. the transceiver configured to transmit the status protocol data unit to the sending unit. TS 36.322 discloses transmitting a PDU which may be a status PDU. Id. at Sec. 5.2.1 pp. 18-19, Sec. 6.1.2 p. 21 and at Sec. 6.2.1.6 p. 25. Further as to claim 35, TS 36.322 further discloses that the header and payload of the status control packet are set up such that the packet has a whole number of octets (bytes). TS 36.322 at Sec. 6.2.1.6 p. 25, noting “padding/reserve bits”. As to claim 74, TS 36.322 discloses A digital communications system comprising: a receiver configured to receive RLC PDUs, re-segmented RLC PDUs, retransmitted RLC PDUs, and retransmitted re-segmented RLC PDUs; TS 36.322 discloses a system and method including means to transmit PDUs from a transmitting element to a receiving element. TS 36.322 discloses that a UE or BS may do both. TS 36.322 at Sec. 4.2.1-4.2.1.1 pp. 7-9 and Sec. 4.2.1.3 p. 11. TS 36.322 discloses that the UE may receive RLC PDUs. Id. at Sec. 4.2.1. TS 36.322 discloses that RLC data PDUs may be either segmented or re-segmented, and may be transmitted or retransmitted. Id. at Sec. 4.2.1.3.2, 4.4, 5.2.1, 6.1.1, and 6.2.2.10. a processing element configured to recognize a failure to receive a re-segmented RLC PDU and to generate a status packet comprising a sequence number for the re-segmented RLC PDU, a beginning setoff value, and ending setoff value; TS 36.322 discloses determining a failure of reception of an RLC PDU. TS 36.322 at Sec. 5.2.3. TS 36.322 discloses that RLC data PDUs may be either segmented or re-segmented. Id. at Sec. 4.2.1.3.2, 4.4, 6.1.1, and 6.2.2.10. This can occur at the UE or eNB, which comprises a processor. Note that TS 36.322 references and incorporates TS 36.300 (TS 36.322 at Sec. 2), which discloses apparatus details as to the UE and eNB, showing processing which occurs therein. TS 36.300 at, inter alia, Sec. 5.1.2 and 5.2.2. TS 36.322 further discloses generating a status PDU, and that the status PDU may include a NACK identifying a packet not received by SN. TS 36.322 at Sec. 6.2.1.6 and 6.2.2.16. TS 36.322 discloses that the status PDU may further include, with the NACK, a beginning and ending offset value indicating a portion of data not received. TS 36.322 at Sec. 6.2.2.16 and 6.2.2.17 p 29. a transceiver element for transmitting the status packet. TS 36.322 discloses a system including means to transmit PDUs including status PDUs from a transmitting element to a receiving element. As the entities may transmit and receive data over a radio link, they inherently comprise a transceiver. TS 36.300 discloses a transmitter and receiver. TS 36.300 at Sec. 5.2.1 and 5.2.7.3. Claim Rejections - 35 USC § 103 The following is a quotation of pre-AIA 35 U.S.C. 103(a) which forms the basis for all obviousness rejections set forth in this Office action: (a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the manner in which the invention was made. Claims 1-3, 6, 7, 36-38, 40-42, 44, 45, and 73 are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over “Radio Link Control (RLC) protocol specification (Release 7)”, 3rd Generation Partnership Project (3GPP) TS 25.322 v7.3.0 (2007-06)2 (hereinafter “TS 25.322”) in view of “Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access (E-UTRA) Radio Link Control (RLC) protocol specification (Release 8)”, )”, 3rd Generation Partnership Project (3GPP) TS 36.322 v1.0.0 (2007-09) (hereinafter “TS 36.322 V1”). As to claim 1, TS 25.322 discloses: A method for delivery of one or more data blocks in a digital communications system, the method comprising: TS 25.322 discloses a digital communication system and method for transmitting data. TS 25.322 at Sec. 4.2. receiving a plurality of transmit data packets from a sending unit, each transmit data packet comprising a transmit sequence number (SN) specifying a sequence of transmission of transmit data packets; TS 25.322 discloses a receiver receiving data packets from a sending unit, each comprising a SN number specifying a sequence of transmission. TS 25.322 at Sec. 9.2.1.4. recognizing a failure to receive at least one other transmit data packet (missing data packet) from said sending unit; TS 25.322 discloses recognizing a failure to receive at least one data packet. TS 25.322 at Sec. 9.7.2 “[i]f the Receiver detects one or several missing AMD PDUs it shall trigger the transmission of a status report to the Sender” transmitting at least one status control packet to said sending unit, TS 25.322 discloses transmitting a status control packet back to the sender. TS 25.322 at Sec 9.4 “when the transmitter receives a STATUS PDU” and at Sec. 9.7.2 “The Receiver transmits status reports to the Sender” as well as Sec. 4.2.1.3.2 “The Receiver acknowledges successful reception or requests retransmission of the missing AMD PDUs by sending one or more STATUS PDUs to the AM RLC peer entity, through its transmitting side”. said status control packet comprising a header including a packet identifier indicative of a data packet received from said sending unit TS 25.322 discloses that the AMD PDU includes a header and a data section. TS 25.322 at Sec. 9.2.1.4. In the AMD STATUS PDU, the data section includes SUFIs, one of which may be an ACK SUFI which identifies by a SN the reception of packets up to that SN i.e. a packet identifier indicative of a packet received. Id. at Sec. 9.2.2.11.2. However this is disclosed as being in the end of the data portion, not the header. and at least one status payload portion including at least one missing packet identifier, said missing packet identifier comprising a transmit packet identifier for said missing data packet; In TS 25.322, other SUFIs (which would mean data payload portion) may include a list of SNs of packets not received. TS 25.322 at 9.2.2.11.4 “"Sequence Number" of AMD PDU, which was not correctly received”. said status payload portion includes a negative acknowledgement (NACK) field including said missing packet identifier […]; and TS 25.322 discloses that the payload section may include a LIST section noted above, which reads a negative ack field as it is a negative acknowledgement of various packets. receiving at least one […]segmented data packet from said sending unit. TS 25.322 discloses receiving a segmented data packet from the sending unit. TS 25.322 at Sec. 4.2.1.3.1 and Sec. 11.1.3. TS 25.322 fails to disclose that the NACK field includes a beginning and ending setoff value as well as receiving a re-segmented data packet. TS 36.322 V1 discloses an analogous art, namely a system and method for providing status control PDUs to apprise a sending unit of failed PDU reception in an RLC system like that of TS 25.322. TS 36.322 V1 at Sec. 1 and Sec. 4.2.1 as well as Sec. 4.2.1.3.3, 5.2.1, and 6.1.2. TS 36.322 further states that a status PDU may include information on the first and last bytes of an AMD PDU segment within the original AMD PDU. Id. at Sec. 6.2.1.6 and 6.2.2.7 (segment offset field). This reads a beginning and ending setoff value. See also Secs. 4.2.1.3.2 and 5.2.1-5.2.3 which mentions a PDU segment to be retransmitted when notified of loss by a status PDU. Lastly, TS 36.322 discloses that when a PDU segment to be retransmitted does not fit a single return PDU it can be re-segmented. Id. at Secs. 4.2.1.3.2 and 6.1.1. Therefore it would have been obvious to one of ordinary skill in the art at the time of the invention to modify TS 25.322 in the manner taught by TS 36.322 V1, namely as to the use of setoff values as well as re-segmented PDUs. TS 25.322 discloses segmenting PDUs and thus segments of a PDU may be not received. TS 36.322 V1 merely discloses the means for identifying these segments. Further, TS 36.322 V1 states that resending a segment may or may not include re-segmentation. One of ordinary skill in the art at the time of the invention would have seen the combination of references as merely an example of combining prior art elements according to known methods, each element in combination performing the same function as it does separately, yielding predictable results. MPEP § 2143 I. A., citing KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398, 415-421, 82 USPQ2d 1385, 1395-97 (2007). Lastly, while the combination of TS 25.322 and TS 36.322 V1 above discloses a SN identifier of a received packet in a payload portion instead of a header portion as claimed, it would further have been obvious to one of ordinary skill in the art to include the claimed SN in a header portion of the status control packet. First off, there is no critical teaching in the instant ‘812 Patent as to this particular SN existing in a header as opposed to a payload portion except inasmuch as it is generally disclosed in the provisional ‘893 document; the non-provisional patent itself only mentions a header with a SN corresponding to a SN anticipated to be received. Further, as the requirement for a retransmit packet responsive to the status control packet has been removed from the claim at issue, the actual structure and information contained in the status control packet is not disclosed as having any actual function at all; as there is no actual processing of the information in the packet, any arrangement of the data therein makes no difference whatsoever as to the claimed method which, again, does not use the status control packet or any information therein for any purpose. Thus even if the information in the status control packet or the arrangement thereof were given patentable weight here, one of ordinary skill in the art would have found rearranging the packet of the combined invention of TS 25.322 in view of TS 36.322 to have been obvious as merely an example of rearrangement of parts, an obvious design choice. MPEP § 2144.04 VI. C., citing In re Japikse, 181 F.2d 1019, 86 USPQ 70 (CCPA 1950). See further In re Kuhle, 526 F.2d 553, 188 USPQ 7 (CCPA 1975). Further as to claim 2: The method of claim 1, wherein said plurality of transmit data packets are received via an optical communications interface, a wireless communications interface, or a wire line communications interface. TS 25.322 and TS 36.322 both disclose a wireless interface. Further as to claim 3: The method of claim 1, wherein said status control packet further comprises additional bits in at least one of said header portion and said status payload portion for increasing a total bit count for said status control packet to a whole number of bytes. TS 25.322 discloses padding the packet, which would be for a whole number of bytes. TS 25.322 at Sec. 9.2.2.10 and 9.2.1.5 “padding shall be included to match one of the PDU sizes used by the logical channel on which the control PDUs are sent. The length of the STATUS PDU shall be a multiple of 8 bits.”. Further as to claim 6: The method of claim 1, wherein each of said re-segmented data packets further comprises a retransmit SN said retransmit SN specifying said transmit SN associated with a data payload in each of said re-segmented data packets. TS 25.322 discloses that the data packet sent may be a retransmit packet comprising a SN associated with its data payload. TS 25.322 at Secs. 11.3.2. and 11.3.2.1. Further as to claim 7: The method of claim 6, wherein at least one of said re-segmented data packets further comprises a retransmit segment identifier, and said retransmit segment identifier specifying a location in said data payload of a segment in said re-segmented data packet associated with a missing packet identifier. TS 25.322 discloses that the data packet sent may be a retransmit packet comprising a SN associated with its data payload. TS 25.322 at Secs. 11.3.2. and 11.3.2.1. Further, TS 25.322 further discloses that the retransmitted packet may include length indicators as to the original data, identifying segments. TS 25.322 at Secs. 9.2.2.8 and 11.3.2.1. Lastly, TS 36.322 further discloses setoff values in the AMD PDU (retransmit packet), which identifies a segment of data associated with the missing packet identifier. TS 36.322 at Sec. 6.2.1.5. As to claim 36, TS 25.322 discloses: A method for delivery of one or more data blocks in a digital communications system, the method comprising: TS 25.322 discloses a digital communication system and method for transmitting data. TS 25.322 at Sec. 4.2. receiving a plurality of transmit data packets from a sending unit; TS 25.322 discloses a receiver receiving data packets from a sending unit, each comprising a SN number specifying a sequence of transmission. TS 25.322 at Sec. 9.2.1.4. recognizing a failure to receive at least one other transmit data packet (missing data packet) from said sending unit; TS 25.322 discloses recognizing a failure to receive at least one data packet. TS 25.322 at Sec. 9.7.2 “[i]f the Receiver detects one or several missing AMD PDUs it shall trigger the transmission of a status report to the Sender” transmitting at least one status control packet to said sending unit, TS 25.322 discloses transmitting a status control packet back to the sender. TS 25.322 at Sec 9.4 “when the transmitter receives a STATUS PDU” and at Sec. 9.7.2 “The Receiver transmits status reports to the Sender” as well as Sec. 4.2.1.3.2 “The Receiver acknowledges successful reception or requests retransmission of the missing AMD PDUs by sending one or more STATUS PDUs to the AM RLC peer entity, through its transmitting side”. said status control packet comprising a header including a packet identifier indicative of a data packet received from said sending unit TS 25.322 discloses that the AMD PDU includes a header and a data section. TS 25.322 at Sec. 9.2.1.4. In the AMD STATUS PDU, the data section includes SUFIs, one of which may be an ACK SUFI which identifies by a SN the reception of packets up to that SN i.e. a packet identifier indicative of a packet received. Id. at Sec. 9.2.2.11.2. However this is disclosed as being in the end of the data portion, not the header. and a status payload portion including at least one missing packet identifier comprising a transmit packet identifier for said missing data packet; In TS 25.322, other SUFIs (which would mean data payload portion) may include a list of SNs of packets not received. TS 25.322 at 9.2.2.11.4 “"Sequence Number" of AMD PDU, which was not correctly received”. receiving at least one […]segmented data packet from said sending unit. TS 25.322 discloses receiving a segmented data packet from the sending unit. TS 25.322 at Sec. 4.2.1.3.1 and Sec. 11.1.3. TS 25.322 fails to disclose that the NACK field includes a beginning and ending setoff value as well as receiving a re-segmented data packet. TS 36.322 V1 discloses an analogous art, namely a system and method for providing status control PDU
Read full office action

Prosecution Timeline

May 15, 2014
Application Filed
May 15, 2014
Response after Non-Final Action
Jan 30, 2015
Non-Final Rejection — §102, §103
Aug 05, 2015
Response Filed
Sep 29, 2015
Final Rejection — §102, §103
Mar 08, 2016
Request for Continued Examination
Mar 09, 2016
Response after Non-Final Action
Jul 25, 2016
Non-Final Rejection — §102, §103
Dec 02, 2016
Response Filed
Apr 12, 2017
Final Rejection — §102, §103
Oct 23, 2017
Notice of Allowance
May 23, 2018
Request for Continued Examination
May 24, 2018
Response after Non-Final Action
Mar 30, 2019
Non-Final Rejection — §102, §103
Oct 08, 2019
Response Filed
Dec 04, 2019
Final Rejection — §102, §103
Jun 13, 2020
Request for Continued Examination
Jun 15, 2020
Response after Non-Final Action
Feb 05, 2021
Non-Final Rejection — §102, §103
Aug 12, 2021
Response Filed
Sep 20, 2021
Final Rejection — §102, §103
Mar 23, 2022
Notice of Allowance
Oct 24, 2022
Request for Continued Examination
Oct 25, 2022
Response after Non-Final Action
Dec 09, 2022
Non-Final Rejection — §102, §103
Jun 15, 2023
Response Filed
Aug 10, 2023
Final Rejection — §102, §103
Feb 18, 2024
Notice of Allowance
Sep 18, 2024
Request for Continued Examination
Sep 19, 2024
Response after Non-Final Action
Oct 15, 2024
Final Rejection — §102, §103
Apr 25, 2025
Notice of Allowance
Nov 24, 2025
Request for Continued Examination
Nov 25, 2025
Response after Non-Final Action
Dec 18, 2025
Final Rejection — §102, §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent RE50858
METHODS AND ARRANGEMENTS FOR A MOBILE COMMUNICATIONS NETWORK
2y 5m to grant Granted Apr 07, 2026
Patent RE50820
METHOD AND APPARATUS FOR REQUESTING SIB IN WIRELESS COMMUNICATION SYSTEM
2y 5m to grant Granted Mar 10, 2026
Patent RE50817
SELECTIVE USER PLANE MONITORING MULTIPLE MONITORING PROBES WHEN A SERVING GATEWAY HAS MULTIPLE IP ADDRESSES
2y 5m to grant Granted Mar 10, 2026
Patent 12550049
DEVICE NETWORK CONFIGURATION METHOD AND FIRST DEVICE
2y 5m to grant Granted Feb 10, 2026
Patent RE50781
DEVICE AND METHOD FOR MANIPULATING AN AUDIO SIGNAL
2y 5m to grant Granted Feb 03, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

13-14
Expected OA Rounds
60%
Grant Probability
83%
With Interview (+22.7%)
4y 1m
Median Time to Grant
High
PTA Risk
Based on 88 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month