DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 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)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1-3, 6, 7, 9-11, 14, 15, 17-19, 22, 23, 25-27, 30, and 31 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Baek et al. (US 2020/0296752 A1), hereinafter referred to as D1.
Regarding claims 1, 9, 17, and 25, D1 discloses a method, apparatus, and system for transmitting and receiving packet data information in a wireless communication system, which comprises:
obtaining one or more configuration parameters related to a format for a buffer status report (BSR), wherein the one or more configuration parameters are related to a size of one or more radio link control (RLC) headers and medium access control (MAC) subheaders that will be added to an amount of data reported by the BSR (Referring to Figures 6-9, including a size of a header, which is not yet generated, in a data volume according to data of a terminal. That is, when calculating a size of a buffer, the terminal may determine a data volume (a buffer size) in consideration of a size of a header which is not generated. In this example, the considered size of the header may include at least one of a representing a size of a MAC subheader, b representing a size of an RLC header, and c representing a size of a PDCP header. In other words, headers, the sizes of which are considered, may include all of a MAC subheader, an RLC header, and a PDCP header, or may include only some thereof according to an embodiment. However, various embodiments of the disclosure are characterized by including a particular header in a data volume equally for all packets. That is, when determining a data volume, the terminal may consider the same header with respect to all packets. For example, the terminal may transmit a BSR message by including a size of an RLC header and a size of a PDCP header in a data volume in relation to all data. Which header size is to be included in a data volume during transmission of a BSR message may be changed according to embodiments. For example, in the case of data 4 having only a PDCP header attached thereto in the RLC buffer 720, the terminal may calculate a data volume by adding b representing a size of an RLC header and a representing a size of a MAC subheader to d4 representing a size of a PDCP SDU and c representing a size of a PDCP header. This configuration implies that, although a header (e.g., a MAC subheader or an RLC header) is not yet generated, a data volume is determined to reflect a header of a fixed size. In the case of data 3 having a PDCP header and an RLC header attached thereto in the RLC buffer 720, the terminal may determine a data volume by further adding a representing a size of a MAC subheader to d3 representing a size of a PDCP SDU, c representing a size of a PDCP header, and b representing a size of an RLC header. The terminal may transmit a BSR depending on the determined data volume to the base station. In this example, a representing the size of the MAC subheader may be determined in consideration of a length of an L field generated with reference to a data volume obtained by adding b representing the size of the current RLC header, c representing the size of the PDCP header, and the corresponding data volume. The size of the RLC header may be determined as a size of an RLC header in a case where a packet is not segmented. In other words, the terminal may determine a data volume by using the size of the RLC header in the case where the packet is not segmented. See paragraphs 0084-0086.);
obtaining one or more configuration parameters related to a trigger for sending a BSR; detecting a BSR triggering event (Referring to Figures 6-9, the terminal may detect triggering of a BSR. A BSR may be triggered according to a determined condition (configuration parameters relate to a trigger for sending a BSR) (e.g., occurrence of an event). The terminal may transmit a buffer status message to a base station according to a predetermined condition. A format of the message may be a format described below with reference to FIG. 16 or FIG. 18. A BSR message may include the amount of data which should be transmitted in a UL for each LCG. In operation 803, the terminal may calculate a data volume so as to including a size (a length) of a header. A data volume may include a buffer size. When a BSR message is triggered (detecting a BSR triggering event), the terminal may calculate a data volume including a size of a header described in the embodiment of FIG. 7 according to various embodiments of the disclosure.) See paragraphs 0086-0090.); and
transmitting a BSR according to the obtained format (Referring Figures 6-9, The terminal may transmit a BSR message to the base station based on the data volume calculated in operation 803. The terminal may generate a BSR message including a size of a header (e.g., an RLC header or a PDCP header). The terminal may transmit the generated BSR message to the base station. See paragraphs 0088-0091.)
Regarding claims 2, 10, 18, and 26, D1 discloses wherein the one or more configuration parameters related to the format for the BSR are obtained when a particular service is established or when a particular traffic is served (Referring to Figures 6-9 and 16-18, The terminal may transmit a buffer status message to a base station according to a predetermined condition. A format of the message may be a format described below with reference to FIG. 16 or FIG. 18 (format according to configuration for service). A BSR message may include the amount of data which should be transmitted in a UL for each LCG. The BSR formats may be classified into a short BSR and a long BSR. In addition, according to the integrity of information included in a BSR, short BSRs may be classified into a general short BSR and a short truncated BSR. Similarly, long BSRs may be classified into a general long BSR and a long truncated BSR. A general short BSR and a short truncated BSR may use a short BSR format corresponding to the second format 1620, and a general long BSR and a long truncated BSR may use a long BSR format corresponding to the first format 1610. See paragraphs 0085-0089 and 0112-0114.)
Regarding claims 3, 11, 19, and 27, D1 discloses wherein the one or more configuration parameters related to the trigger for sending a BSR are obtained when a particular traffic is served or when a particular service is established (Referring to Figures 6-9 and 16-18, The terminal may transmit a buffer status message to a base station according to a predetermined condition (configuration parameters related to the trigger for sending a BSR are obtained when a particular traffic is served). A format of the message may be a format described below with reference to FIG. 16 or FIG. 18 (format according to configuration for service). A BSR message may include the amount of data which should be transmitted in a UL for each LCG. The BSR formats may be classified into a short BSR and a long BSR. In addition, according to the integrity of information included in a BSR, short BSRs may be classified into a general short BSR and a short truncated BSR. Similarly, long BSRs may be classified into a general long BSR and a long truncated BSR. A general short BSR and a short truncated BSR may use a short BSR format corresponding to the second format 1620, and a general long BSR and a long truncated BSR may use a long BSR format corresponding to the first format 1610. See paragraphs 0085-0089 and 0112-0114.)
Regarding claims 6, 14, 22, and 30, D1 discloses wherein the one or more configuration parameters related to a format for a BSR comprise an indication of any one or more of: a number of Packet Data Convergence Protocol (PDCP) data units in a PDCP buffer; a number of PDCP data units associated to an application data unit; a number of PDCP data units associated to a same latency bound; a size of one or more PDCP data units; a size of all PDCP data units associated to an application data unit; and a size of all PDCP data units associated to latency bound (Referring to Figures 6-9, determination of a data volume during packet segmentation according to various embodiments of the disclosure. Referring to FIG. 9, a description is made of a method for changing a data volume when a packet (e.g., data or a PDCP SDU) is segmented. A packet is segmented in an RLC layer in a wireless communication system, and segmentation is performed according to a size of a Transport Block (TB) in a MAC layer if necessary. See paragraphs 0090-0092. In the case of data having a PDCP header and an RLC header attached thereto in the RLC buffer 720, the terminal may determine a data volume by further adding a representing a size of a MAC subheader to representing a size of a PDCP SDU (a size of one or more PDECP data units), representing a size of a PDCP header, and representing a size of an RLC header. The terminal may transmit a BSR depending on the determined data volume to the base station. See paragraphs 0084-0086.)
Regarding claims 7, 15, 23, and 31, D1 discloses wherein the one or more configuration parameters related to the trigger for sending a BSR comprise an indication of one or more of: a threshold size associated with a logical channel or logical channel group buffer size; a threshold number associated with a number of buffered application data units; a threshold number associated with a number of buffered PDCP data units; a threshold size associated with all buffered PDCP data units associated to an application data unit; a threshold waiting time associated with all buffered PDCP data units associated to an application data unit; and configuration of a particular logical channel or corresponding quality of service flow (Referring to Figures 21-23, after a BSR is triggered in operation 2201, in operation 2203, the terminal may determine whether the BSR is a padding BSR. If the BSR is not a padding BSR (e.g., the BSR is a regular/periodic BSR), in operation 2207, the terminal may determine the number of LCGs including data and a BSR format to be used according to a data volume to be reported. If the number of LCGs including data is equal to 1 (is smaller than 2, and if the number of the LCGs is 0, this may not be reported) and a data volume to be reported in the BSR is smaller than or equal to a first threshold (or is smaller than the first threshold) in operation 2217, in operation 2225, the terminal transmits a BSR, the format of which is a short BSR. For example, the first threshold may be an index #30 of a buffer size level of a 5-bit buffer size field, that is, an upper bound of an index having the highest upper bound among the indices having an upper bound. As an example, if a buffer size value of an index #30 of a buffer size level of a 5-bit buffer size field exceeds 100 bytes and is smaller than or equal to 150 bytes, the first threshold may be 150 bytes which is the value of the upper bound. In contrast, if the number of LCGs including data is larger than or equal to 2, or if the number of LCGs including data is equal to 1 but a data volume to be reported in the BSR exceeds the first threshold, in operation 2227, the terminal may transmit a BSR by using a long BSR format. See paragraphs 0133-0135.)
Response to Arguments
Applicant's arguments filed 02 March 2026 have been fully considered but they are not persuasive.
On page 10 of the remarks, regarding claim 1, the Applicant argues Baek does not disclose obtaining configuration parameters; format of the BSR; obtaining configuration parameters related to the format of a BSR, in which the configuration parameters are related to a size of RLC headers and MAC subheaders that will be added to an amount of data reported by the BSR. The Examiner respectfully disagrees. D1 teaches obtaining one or more configuration parameters related to a format for a buffer status report (BSR), wherein the one or more configuration parameters are related to a size of one or more radio link control (RLC) headers and medium access control (MAC) subheaders that will be added to an amount of data reported by the BSR (Referring to Figures 6-9, including a size of a header, which is not yet generated, in a data volume according to data of a terminal. That is, when calculating a size of a buffer, the terminal may determine a data volume (a buffer size) in consideration of a size of a header which is not generated. In this example, the considered size of the header may include at least one of a representing a size of a MAC subheader, b representing a size of an RLC header, and c representing a size of a PDCP header. In other words, headers, the sizes of which are considered, may include all of a MAC subheader, an RLC header, and a PDCP header, or may include only some thereof according to an embodiment. However, various embodiments of the disclosure are characterized by including a particular header in a data volume equally for all packets. That is, when determining a data volume, the terminal may consider the same header with respect to all packets. For example, the terminal may transmit a BSR message by including a size of an RLC header and a size of a PDCP header in a data volume in relation to all data. Which header size is to be included in a data volume during transmission of a BSR message may be changed according to embodiments. For example, in the case of data 4 having only a PDCP header attached thereto in the RLC buffer 720, the terminal may calculate a data volume by adding b representing a size of an RLC header and a representing a size of a MAC subheader to d4 representing a size of a PDCP SDU and c representing a size of a PDCP header. This configuration implies that, although a header (e.g., a MAC subheader or an RLC header) is not yet generated, a data volume is determined to reflect a header of a fixed size. In the case of data 3 having a PDCP header and an RLC header attached thereto in the RLC buffer 720, the terminal may determine a data volume by further adding a representing a size of a MAC subheader to d3 representing a size of a PDCP SDU, c representing a size of a PDCP header, and b representing a size of an RLC header. The terminal may transmit a BSR depending on the determined data volume to the base station. In this example, a representing the size of the MAC subheader may be determined in consideration of a length of an L field generated with reference to a data volume obtained by adding b representing the size of the current RLC header, c representing the size of the PDCP header, and the corresponding data volume. The size of the RLC header may be determined as a size of an RLC header in a case where a packet is not segmented. In other words, the terminal may determine a data volume by using the size of the RLC header in the case where the packet is not segmented. See paragraphs 0084-0086. Under a broad literal reasonable claim interpretation, the recited size of the data volume as related to the header as recited above is “one or more configuration parameters related to a format for a BSR”.); obtaining one or more configuration parameters related to a trigger for sending a BSR; detecting a BSR triggering event (Referring to Figures 6-9, the terminal may detect triggering of a BSR. A BSR may be triggered according to a determined condition (configuration parameters relate to a trigger for sending a BSR) (e.g., occurrence of an event). The terminal may transmit a buffer status message to a base station according to a predetermined condition. A format of the message may be a format described below with reference to FIG. 16 or FIG. 18. A BSR message may include the amount of data which should be transmitted in a UL for each LCG. In operation 803, the terminal may calculate a data volume so as to including a size (a length) of a header. A data volume may include a buffer size. When a BSR message is triggered (detecting a BSR triggering event), the terminal may calculate a data volume including a size of a header described in the embodiment of FIG. 7 according to various embodiments of the disclosure.) See paragraphs 0086-0090.); and transmitting a BSR according to the obtained format (Referring Figures 6-9, The terminal may transmit a BSR message to the base station based on the data volume calculated in operation 803. The terminal may generate a BSR message including a size of a header (e.g., an RLC header or a PDCP header). The terminal may transmit the generated BSR message to the base station. See paragraphs 0088-0091.) On page 11, of the remarks, regarding claim 17, the Applicant argues Baek does not disclose the base station transmitting any parameters to the mobile terminal for the mobile terminal to use in performing its calculations. The Examiner respectfully disagrees. In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., transmitting any parameters to the mobile terminal for the mobile terminal to use in performing its calculations) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). The Examiner utilizes a broad literal reasonable claim interpretation as explained in the rejection above. The Applicant appears to read limitations from the specification into the claims. The claims merely recite a series of “parameters related to . . .” and argues that such language must be read in light of the specification while reading limitations from the specification into the claims. The claims do not present any functional or structural limitations which would preclude the Examiner’s interpretation in light of the prior art, because the claims doe not set forth any definition of “configuration parameters”. The claims should be amended to more explicitly recite the instant invention as disclosed by the specification, instead of merely arguing a narrow claim interpretation dependent upon reading limitations disclosed in the specification into the claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Lee et al. (US 2020/0205029 A1) - The method comprises receiving logical channel group (LCG) configuration information including identities of LCGs from the network; generating the BSR including octet presence indications; and transmitting the BSR to a network, wherein each of the octet presence indications indicates whether a corresponding octet is present or not in the BSR, wherein a number of the octet presence indications is variable according to a highest value of the identities of LCGs.
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DONALD L MILLS whose telephone number is (571)272-3094. The examiner can normally be reached Monday through Friday from 9-5 PM EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Yemane Mesfin can be reached at 571-272-3927. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
DONALD L. MILLS
Primary Examiner
Art Unit 2462
/Donald L Mills/ Primary Examiner, Art Unit 2462
Prosecution Insights