DETAILED ACTION
Examiner acknowledges receipt of Applicant’s amendment filed 4/20/2026.
In the amendment, Applicant amended claims 1, 14, and 27-30.
Claims1-30 are currently pending.
Response to Arguments
Examiner has fully considered Applicant's arguments, see pages 9-11, filed 4/20/2026, with respect to the rejection of claims 1-30 under 35 U.S.C. 112(a) but they are not persuasive.
Applicant argues that [0056] and [0057] of the published application ([0053] and [0054] of the specification as filed), when “read together” provide support for portion of the amended independent claims relating to the capability report. In particular, Applicant focuses on the teaching in [0057], which indicates that “In some cases, when connected mode DRX is not configured for a UE, the UE may not be required to receive certain DCI formats…” (emphasis added). Applicant suggests that this, combined with [0056], teaches the amended claim limitation.
Examiner respectfully disagrees. The limitation in question states “transmitting to a network entity a capability report indicating that the UE supports receiving an indication of a change in dormancy behavior for one or more secondary cells (SCells) or SCell groups using downlink control information (DCI) associated with a first DCI format and that the UE is not required to receive the indication of the change in dormancy behavior via at least a second DCI format from multiple DCI formats comprising at least the first DCI format and the second DCI format” (emphasis added). Examiner interprets this to require a capability report indicating (a) that the UE supports receiving an indication of change in dormancy behavior using a first DCI format and (b) that the UE is not required to receive the indication of the change in dormancy via at least a second DCI format.
Turning to the specification, [0056] of the published application “a UE capability report signaling…to indicate to the network whether the UE supports the SCell dormancy function when CDRX is not configured”. Clearly, this explicitly indicates that the capability report indicates “whether the UE supports the SCell dormancy function”. This is further modified in the next sentence of [0056], which indicates that “Indication of this support may mean that the UE will support receiving the DCI format 0_l or 1_1 that contains the "SCell dormancy indication" field…”. That is, the “indication of support” provided by the UE capability report “may mean” that the UE will support a first DCI format (0_1 or 1_1). However, this does not indicate that the specific formats are included in the UE capability report, only that an indication of support “may mean” that one or more DCI formats are supported.
Next, consider [0057] of the published application. This paragraph does not mention the “UE capability report” or the “indication of support” included within the UE capability report. Rather, [0057] indicates that the UE “may not be required to receive certain DCI formats”. This does not teach that the UE indicates the formats which it is not required to receive in the UE capability report, merely that the UE may not be required to receive them (in certain situations).
Therefore, Examiner maintains the rejection under 35 U.S.C. 112(a) as the original disclosure does not support the amended independent claims.
Examiner has fully considered Applicant's arguments, see pages 11-16, filed 4/20/2026, with respect to the rejection of claims under 35 U.S.C. 103 but they are not persuasive.
First, on pages 12-13, Applicant argues that the “capability report does indicate DCI-format-specific information”. Applicant discusses [0056] and [0057] of the published application ([0053] and [0054] of the specification as filed), making arguments similar to those addressed above regarding the rejection under 35 U.S.C. 112(a). For reasons articulated above, Examiner does not agree with Applicant’s interpretation of [0056] and [0057] and provides a different interpretation. For similar reasons, Examiner maintains the interpretation from the previous office action which is described in detail below. That is, Examiner maintains that the claim requires the steps of (1) transmitting to a network entity a capability report indicating support for a feature (change in dormancy behavior when C-DRX is not configured); (2) receiving a message in accordance with the feature; (3) applying the information in the received message.
On pages 13-15, Applicant argues that the combination of Xue and Rai does not disclose the amended claim limitations. Some of this argument relies upon a different claim interpretation than that of Examiner. For example, see the first sentence on page 14, which states “the claim 1 does not merely require that the UE happens to not receive dormancy indications via a second DCI format; the claim requires the capability report itself to indicate this to the network”. Examiner respectfully disagrees. First, Examiner does not agree that the specification (see [0056] and [0057] of the published application) discloses that the UE capability report indicates anything more than “support” for a particular feature. That is, [0056] does not disclose any teaching of a field or other information indicating a specific DCI format to which the support applies. Second, the claim language and [0056] and [0057] of the published application further clearly support the interpretation of Examiner that the UE capability report indicates support for “feature A”, where “feature A” is “change in dormancy behavior when C-DRX is not configured” and that this feature “may mean” that a particular DCI format or formats is/are supported to receive an indication of the dormancy behavior change.
As noted in detail below, the claim requires the steps of (1) transmitting to a network entity a capability report indicating support for a feature (change in dormancy behavior when C-DRX is not configured); (2) receiving a message in accordance with the feature; (3) applying the information in the received message. Xue discloses a UE that supports the feature, receives a message in accordance with the feature, and applying the information in the received message. Xue only differs from this claim in that the UE does not report to the network that it supports the feature. Examiner maintains that Rai teaches this missing limitation of reporting support for a feature to the network. Therefore, the combination of Xue and Rai renders the amended claims obvious.
On pages 15-16, Applicant argues that dependent claims are allowable for reasons similar to those discussed above regarding the independent claims. For reasons similar to those indicated above, Examiner respectfully disagrees.
Claim Rejections - 35 USC § 112(a)
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-30 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement.
The claims contain subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventors, at the time the application was filed, had possession of the claimed invention.
Regarding claim 1: the original disclosure does not explicitly support the limitation “a capability report indicating that the UE supports receiving an indication of a change in dormancy behavior for one or more secondary cells (SCells) or SCell groups using downlink control information (DCI) associated with a first DCI format and that the UE is not required to receive the indication of the change in dormancy behavior via at least a second DCI format from multiple DCI formats comprising at least the first DCI format and [[a]] the second DCI format”. That is, the original disclosure mentioned “capability report” only in [0053] (which is also [0056] of the published application). This capability report is described as follows: “In some cases, a UE capability report signaling may be defined to indicate to the network whether the UE supports the SCell dormancy function when CDRX is not configured. Indication of this support may mean that the UE will support receiving the DCI format 0_1 or 1_1 that contains the “SCell dormancy indication” field and is able to apply the indicated behavior (e.g., perform switching between dormancy behavior and non-dormancy behavior).” This discloses that the capability report indicates support for the “the SCell dormancy function when CDRX is not configured” and further discloses that this “may mean that the UE will support receiving the DCI format 0_1 or 1_1 that contains the “SCell dormancy indication” field”. However, this does not provide support for the limitation that the capability report further indicates that the UE “is not required to receive the indication of the change in dormancy behavior via at least a second DCI format”.
Claims 14 and 27-30 include similar limitations and are thus similarly rejected under 35 U.S.C. 112(a).
Claims 2-13 and 15-26 depend from claims 1 and 14, respectively and are thus similarly rejected under 35 U.S.C. 112(a).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-3, 5-7, 9, 10, 13-16, 18-20, 22, 23, and 26-30 are rejected under 35 U.S.C. 103 as being unpatentable over Xue et al (US 2022/0264574) in view of Rai et al (US 9,973,951).
Regarding claim 1: Xue discloses a method of wireless communication by a user equipment (UE), comprising:
receiving from the network entity via the DCI associated with a first DCI format, while the UE is in a first mode associated with continuous physical downlink control (PDCCH) monitoring, the indication of the change in the dormancy behavior for the one or more SCells or SCell groups (disclosed throughout; see [0055]-[0058], for example; first, [0055] indicates that the network may indicate to a terminal device (the UE) “whether to perform dormancy behavior in an SCell” and that this is indicated “by using 1-bit, to switch between the dormant BWP and a non-dormant BWP in the SCell”; further, as indicated in [0057], this indication may be sent “[w]hen connected mode (C)-DRX is not configured for the terminal device” – this is interpreted to be “continuous physical downlink control (PDCCH) monitoring” as the terminal continuously monitors the PDCCH when not in DRX (discontinuous reception); as indicated in [0057], this indication is carried via a DCI using one of a subset of formats (either DCI format 0_1 or DCI format 1_1)); and
applying the indicated change in dormancy behavior (disclosed throughout; see the description in [0055], which indicates that this change is implemented by switching to/from a dormant BWP and a non-dormant BWP).
As indicated above, the UE in Xue clearly supports receiving an indication of a change in dormancy behavior for one or more secondary cells (SCells) or SCell groups using downlink control information (DCI) associated with a first DCI format and that the UE is not required to receive the indication of the change in dormancy behavior via at least a second DCI format from multiple DCI formats comprising at least the first DCI format and the second DCI format (see [0055]-[0057] and the rejection above, which clearly indicate that the UE receives an indication of change of dormancy behavior in a subset of DCI formats (formats 0_1 and 1_1); further, this also discloses that the change of dormancy is limited to this subset of DCI formats and is not received in all DCI formats that could potentially carry a change of dormancy indication). Specifically, Xue discloses an indication from a network device that indicates to a terminal “whether to perform dormancy behavior” and that this “indication may be carried in a downlink control information (DCI) format 0_1 or a DCI format 1_1”. This is very similar to the language in [0052] in Applicant’s published application “the UE may receive a particular DCI format (e.g., DCI format 0_1 or 1_1) that includes a dormancy indication field for the switch between dormancy behavior and non-dormancy behavior” and [0056] in Applicant’s published application “may mean that the UE will support receiving the DCI format 0_1 or 1_1 that contains the “SCell dormancy indication” field”.
However, Xue does not explicitly disclose the limitation of transmitting to a network entity a capability report indicating that the UE supports this feature regarding receiving the dormancy indication using one of the subset of DCI formats. Similarly, Xue does not explicitly disclose receiving the indication of the change in dormancy in the first DCI format in accordance with the capability report.
First, the interpretation of the “capability report” claim limitation is that the report indicates support for a feature (change in dormancy behavior when C-DRX is not configured). This feature is implemented using an indication received using one of multiple DCI formats. However, the “capability report” does not indicate a specific format of these multiple formats, only whether the feature is supported. Consider [0056] of Applicant’s published application, which notes that “a UE capability report signaling may be defined to indicate to the network whether the UE supports the SCell dormancy function when CDRX is not configured”. That is, the capability report signaling indicates to the network whether the UE supports a particular function (the function being “SCell dormancy…when CDRX is not configured”). Next, [0056] notes that “Indication of this support may mean that the UE will support receiving the DCI format 0_1 or 1_1 that contains the ‘SCell dormancy indication’ field and is able to apply the indicated behavior”. This does not suggest that the capability report indication includes information identifying which of the DCI formats is supported. Rather, it indicates support for the feature of “SCell dormancy…when CDRX is not configured”. The indication of SCell dormancy happens to be included in a particular DCI format (and not in another DCI format), but this format is not indicated via the capability report.
Stated another way, claim 1 can be viewed broadly as requiring the steps of (1) transmitting to a network entity a capability report indicating support for a feature; (2) receiving a message in accordance with the feature; (3) applying the information in the received message. Xue discloses a UE that supports the feature, receives a message in accordance with the feature, and applying the information in the received message. Xue only differs from this claim in that the UE does not report to the network that it supports the feature.
However, sending a capability report from a UE to the network to indicate whether (or not) the UE supports a newly added feature is well known in the art. Consider Rai, for example, which discloses a UE transmitting “UE capability information” comprising a set of “feature group indicator (FGI) bits, each mapped to a particular capability, and each having a value (0 or 1) indicating whether or not the UE has that capability”. This information is transmitted “to inform the eNodeB what capabilities the UE has and does not have”. (See 8:8-22 of Rai, for example). Further, as indicated in 8:23-32, for example, if the UE does not support a particular feature, (such as determining and measuring neighboring coverage per events A4 and A5), then the network (eNodeB) will not perform functions associated with this feature in its communications with the UE. Clearly, the reverse is true – namely, when the UE indicates that it supports a feature, the network implements the functions associated with this feature.
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Xue such that the terminal/UE reports to the network whether it is capable a particular function (such as receiving the dormancy indication field and performing the functions associated with this indication field). The rationale for doing so would have been to ensure that the network only uses the dormancy indication field for terminals that can actually use it to prevent wasted bandwidth (by unnecessarily sending the information to devices not capable of using it) and also potential confusion where the network and terminal are not implementing the same functions.
Regarding claim 14: Xue discloses a method of wireless communication by a network entity, comprising:
providing, via a DCI associated with a first DCI format to the UE that is in a first mode associated with continuous physical downlink control (PDCCH) monitoring, the indication of the change in the dormancy behavior for the one or more SCells or SCell groups (disclosed throughout; see [0055]-[0058], for example; first, [0055] indicates that the network may indicate to a terminal device (the UE) “whether to perform dormancy behavior in an SCell” and that this is indicated “by using 1-bit, to switch between the dormant BWP and a non-dormant BWP in the SCell”; further, as indicated in [0057], this indication may be sent “[w]hen connected mode (C)-DRX is not configured for the terminal device” – this is interpreted to be “continuous physical downlink control (PDCCH) monitoring” as the terminal continuously monitors the PDCCH when not in DRX (discontinuous reception); as indicated in [0057], this indication is carried via a DCI using one of a subset of formats (either DCI format 0_1 or DCI format 1_1)); and
applying the indicated change in dormancy behavior (disclosed throughout; see the description in [0055], which indicates that this change is implemented by switching to/from a dormant BWP and a non-dormant BWP).
As indicated above, the UE in Xue clearly supports receiving an indication of a change in dormancy behavior for one or more secondary cells (SCells) or SCell groups using downlink control information (DCI) associated with a first DCI format and that the UE is not required to receive the indication of the change in dormancy behavior via at least a second DCI format from multiple DCI formats comprising at least the first DCI format and the second DCI format (see [0055]-[0057] and the rejection above, which clearly indicate that the UE receives an indication of change of dormancy behavior in a subset of DCI formats (formats 0_1 and 1_1)). Specifically, Xue discloses an indication from a network device that indicates to a terminal “whether to perform dormancy behavior” and that this “indication may be carried in a downlink control information (DCI) format 0_1 or a DCI format 1_1”. This is very similar to the language in [0052] in Applicant’s published application “the UE may receive a particular DCI format (e.g., DCI format 0_1 or 1_1) that includes a dormancy indication field for the switch between dormancy behavior and non-dormancy behavior”.
However, Xue does not explicitly disclose the limitation of UE means for receiving from a user equipment (UE) a capability report indicating that the UE supports this feature regarding receiving the dormancy indication using one of the subset of DCI formats. Similarly, Xue does not explicitly disclose providing the indication of the change in dormancy in the first DCI format in accordance with the capability report.
First, the interpretation of the “capability report” claim limitation is that the report indicates support for a feature (change in dormancy behavior). This feature is implemented using an indication received using one of multiple DCI formats. However, the “capability report” does not indicate a specific format of these multiple formats, only whether the feature is supported. Consider [0056] of Applicant’s published application, which notes that “a UE capability report signaling may be defined to indicate to the network whether the UE supports the SCell dormancy function when CDRX is not configured”. That is, the capability report signaling indicates to the network whether the UE supports a particular function (the function being “SCell dormancy…when CDRX is not configured”). Next, [0056] notes that “Indication of this support may mean that the UE will support receiving the DCI format 0_1 or 1_1 that contains the ‘SCell dormancy indication’ field and is able to apply the indicated behavior”. This does not suggest that the capability report indication includes information identifying which of the DCI formats is supported. Rather, it indicates support for the feature of “SCell dormancy…when CDRX is not configured”. The indication of SCell dormancy happens to be included in a particular DCI format, but this format is not indicated via the capability report.
Stated another way, claim 1 can be viewed broadly as requiring the steps of (1) transmitting to a network entity a capability report indicating support for a feature; (2) receiving a message in accordance with the feature; (3) applying the information in the received message. Xue discloses a UE that supports the feature, receives a message in accordance with the feature, and applying the information in the received message. Xue only differs from this claim in that the UE does not report to the network that it supports the feature.
However, sending a capability report from a UE to the network to indicate whether (or not) the UE supports a newly added feature is well known in the art. Consider Rai, for example, which discloses a UE transmitting “UE capability information” comprising a set of “feature group indicator (FGI) bits, each mapped to a particular capability, and each having a value (0 or 1) indicating whether or not the UE has that capability”. This information is transmitted “to inform the eNodeB what capabilities the UE has and does not have”. (See 8:8-22 of Rai, for example). Further, as indicated in 8:23-32, for example, if the UE does not support a particular feature, (such as determining and measuring neighboring coverage per events A4 and A5), then the network (eNodeB) will not perform functions associated with this feature in its communications with the UE. Clearly, the reverse is true – namely, when the UE indicates that it supports a feature, the network implements the functions associated with this feature.
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Xue such that the terminal/UE reports to the network whether it is capable a particular function (such as receiving the dormancy indication field and performing the functions associated with this indication field). The rationale for doing so would have been to ensure that the network only uses the dormancy indication field for terminals that can actually use it to prevent wasted bandwidth (by unnecessarily sending the information to devices not capable of using it) and also potential confusion where the network and terminal are not implementing the same functions.
Regarding claim 27: Xue discloses an apparatus for wireless communication by a user equipment (UE), comprising:
means for receiving (see transceiver 901 of Figure 9, for example) from the network entity via the DCI associated with a first DCI format, while the UE is in a first mode associated with continuous physical downlink control (PDCCH) monitoring, the indication of the change in the dormancy behavior for the one or more SCells or SCell groups (disclosed throughout; see [0055]-[0058], for example; first, [0055] indicates that the network may indicate to a terminal device (the UE) “whether to perform dormancy behavior in an SCell” and that this is indicated “by using 1-bit, to switch between the dormant BWP and a non-dormant BWP in the SCell”; further, as indicated in [0057], this indication may be sent “[w]hen connected mode (C)-DRX is not configured for the terminal device” – this is interpreted to be “continuous physical downlink control (PDCCH) monitoring” as the terminal continuously monitors the PDCCH when not in DRX (discontinuous reception); as indicated in [0057], this indication is carried via a DCI using one of a subset of formats (either DCI format 0_1 or DCI format 1_1)); and
means for applying (see processor 902 of Figure 9, for example) the indicated change in dormancy behavior (disclosed throughout; see the description in [0055], which indicates that this change is implemented by switching to/from a dormant BWP and a non-dormant BWP).
As indicated above, the UE in Xue clearly supports receiving an indication of a change in dormancy behavior for one or more secondary cells (SCells) or SCell groups using downlink control information (DCI) associated with a first DCI format and that the UE is not required to receive the indication of the change in dormancy behavior via at least a second DCI format from multiple DCI formats comprising at least the first DCI format and the second DCI format (see [0055]-[0057] and the rejection above, which clearly indicate that the UE receives an indication of change of dormancy behavior in a subset of DCI formats (formats 0_1 and 1_1)). Specifically, Xue discloses an indication from a network device that indicates to a terminal “whether to perform dormancy behavior” and that this “indication may be carried in a downlink control information (DCI) format 0_1 or a DCI format 1_1”. This is very similar to the language in [0052] in Applicant’s published application “the UE may receive a particular DCI format (e.g., DCI format 0_1 or 1_1) that includes a dormancy indication field for the switch between dormancy behavior and non-dormancy behavior”.
However, Xue does not explicitly disclose the limitation of UE means for receiving from a user equipment (UE) a capability report indicating that the UE supports this feature regarding receiving the dormancy indication using one of the subset of DCI formats. Similarly, Xue does not explicitly disclose providing the indication of the change in dormancy in the first DCI format in accordance with the capability report.
First, the interpretation of the “capability report” claim limitation is that the report indicates support for a feature (change in dormancy behavior). This feature is implemented using an indication received using one of multiple DCI formats. However, the “capability report” does not indicate a specific format of these multiple formats, only whether the feature is supported. Consider [0056] of Applicant’s published application, which notes that “a UE capability report signaling may be defined to indicate to the network whether the UE supports the SCell dormancy function when CDRX is not configured”. That is, the capability report signaling indicates to the network whether the UE supports a particular function (the function being “SCell dormancy…when CDRX is not configured”). Next, [0056] notes that “Indication of this support may mean that the UE will support receiving the DCI format 0_1 or 1_1 that contains the ‘SCell dormancy indication’ field and is able to apply the indicated behavior”. This does not suggest that the capability report indication includes information identifying which of the DCI formats is supported. Rather, it indicates support for the feature of “SCell dormancy…when CDRX is not configured”. The indication of SCell dormancy happens to be included in a particular DCI format, but this format is not indicated via the capability report.
Stated another way, claim 1 can be viewed broadly as requiring the steps of (1) transmitting to a network entity a capability report indicating support for a feature; (2) receiving a message in accordance with the feature; (3) applying the information in the received message. Xue discloses a UE that supports the feature, receives a message in accordance with the feature, and applying the information in the received message. Xue only differs from this claim in that the UE does not report to the network that it supports the feature.
However, sending a capability report from a UE to the network to indicate whether (or not) the UE supports a newly added feature is well known in the art. Consider Rai, for example, which discloses a UE transmitting “UE capability information” comprising a set of “feature group indicator (FGI) bits, each mapped to a particular capability, and each having a value (0 or 1) indicating whether or not the UE has that capability”. This information is transmitted “to inform the eNodeB what capabilities the UE has and does not have”. (See 8:8-22 of Rai, for example). Further, as indicated in 8:23-32, for example, if the UE does not support a particular feature, (such as determining and measuring neighboring coverage per events A4 and A5), then the network (eNodeB) will not perform functions associated with this feature in its communications with the UE. Clearly, the reverse is true – namely, when the UE indicates that it supports a feature, the network implements the functions associated with this feature.
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Xue such that the terminal/UE reports to the network whether it is capable a particular function (such as receiving the dormancy indication field and performing the functions associated with this indication field). The rationale for doing so would have been to ensure that the network only uses the dormancy indication field for terminals that can actually use it to prevent wasted bandwidth (by unnecessarily sending the information to devices not capable of using it) and also potential confusion where the network and terminal are not implementing the same functions.
Regarding claim 28: Xue discloses an apparatus for wireless communication by a network entity, comprising:
means for providing (see transceiver 1001 of Figure 10, for example), via a DCI associated with a first DCI format to the UE that is in a first mode associated with continuous physical downlink control (PDCCH) monitoring, the indication of the change in the dormancy behavior for one or more SCells or SCell groups (disclosed throughout; see [0055]-[0058], for example; first, [0055] indicates that the network may indicate to a terminal device (the UE) “whether to perform dormancy behavior in an SCell” and that this is indicated “by using 1-bit, to switch between the dormant BWP and a non-dormant BWP in the SCell”; further, as indicated in [0057], this indication may be sent “[w]hen connected mode (C)-DRX is not configured for the terminal device” – this is interpreted to be “continuous physical downlink control (PDCCH) monitoring” as the terminal continuously monitors the PDCCH when not in DRX (discontinuous reception); as indicated in [0057], this indication is carried via a DCI using one of a subset of formats (either DCI format 0_1 or DCI format 1_1)); and
means for applying (see processor 1002 of Figure 10, for example) the indicated change in dormancy behavior (disclosed throughout; see the description in [0055], which indicates that this change is implemented by switching to/from a dormant BWP and a non-dormant BWP).
As indicated above, the UE in Xue clearly supports receiving an indication of a change in dormancy behavior for one or more secondary cells (SCells) or SCell groups using downlink control information (DCI) associated with a first DCI format and that the UE is not required to receive the indication of the change in dormancy behavior via at least a second DCI format from multiple DCI formats comprising at least the first DCI format and the second DCI format (see [0055]-[0057] and the rejection above, which clearly indicate that the UE receives an indication of change of dormancy behavior in a subset of DCI formats (formats 0_1 and 1_1)). Specifically, Xue discloses an indication from a network device that indicates to a terminal “whether to perform dormancy behavior” and that this “indication may be carried in a downlink control information (DCI) format 0_1 or a DCI format 1_1”. This is very similar to the language in [0052] in Applicant’s published application “the UE may receive a particular DCI format (e.g., DCI format 0_1 or 1_1) that includes a dormancy indication field for the switch between dormancy behavior and non-dormancy behavior”.
However, Xue does not explicitly disclose the limitation of UE means for receiving from a user equipment (UE) a capability report indicating that the UE supports this feature regarding receiving the dormancy indication using one of the subset of DCI formats. Similarly, Xue does not explicitly disclose providing the indication of the change in dormancy in the first DCI format in accordance with the capability report.
First, the interpretation of the “capability report” claim limitation is that the report indicates support for a feature (change in dormancy behavior). This feature is implemented using an indication received using one of multiple DCI formats. However, the “capability report” does not indicate a specific format of these multiple formats, only whether the feature is supported. Consider [0056] of Applicant’s published application, which notes that “a UE capability report signaling may be defined to indicate to the network whether the UE supports the SCell dormancy function when CDRX is not configured”. That is, the capability report signaling indicates to the network whether the UE supports a particular function (the function being “SCell dormancy…when CDRX is not configured”). Next, [0056] notes that “Indication of this support may mean that the UE will support receiving the DCI format 0_1 or 1_1 that contains the ‘SCell dormancy indication’ field and is able to apply the indicated behavior”. This does not suggest that the capability report indication includes information identifying which of the DCI formats is supported. Rather, it indicates support for the feature of “SCell dormancy…when CDRX is not configured”. The indication of SCell dormancy happens to be included in a particular DCI format, but this format is not indicated via the capability report.
Stated another way, claim 1 can be viewed broadly as requiring the steps of (1) transmitting to a network entity a capability report indicating support for a feature; (2) receiving a message in accordance with the feature; (3) applying the information in the received message. Xue discloses a UE that supports the feature, receives a message in accordance with the feature, and applying the information in the received message. Xue only differs from this claim in that the UE does not report to the network that it supports the feature.
However, sending a capability report from a UE to the network to indicate whether (or not) the UE supports a newly added feature is well known in the art. Consider Rai, for example, which discloses a UE transmitting “UE capability information” comprising a set of “feature group indicator (FGI) bits, each mapped to a particular capability, and each having a value (0 or 1) indicating whether or not the UE has that capability”. This information is transmitted “to inform the eNodeB what capabilities the UE has and does not have”. (See 8:8-22 of Rai, for example). Further, as indicated in 8:23-32, for example, if the UE does not support a particular feature, (such as determining and measuring neighboring coverage per events A4 and A5), then the network (eNodeB) will not perform functions associated with this feature in its communications with the UE. Clearly, the reverse is true – namely, when the UE indicates that it supports a feature, the network implements the functions associated with this feature.
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Xue such that the terminal/UE reports to the network whether it is capable a particular function (such as receiving the dormancy indication field and performing the functions associated with this indication field). The rationale for doing so would have been to ensure that the network only uses the dormancy indication field for terminals that can actually use it to prevent wasted bandwidth (by unnecessarily sending the information to devices not capable of using it) and also potential confusion where the network and terminal are not implementing the same functions.
Regarding claim 29: Xue discloses an apparatus for wireless communication by a user equipment (UE), comprising:
a receiver (see transceiver 901 of Figure 9, for example) configured to receive from the network entity via the DCI associated with a first DCI format, while the UE is in a first mode associated with continuous physical downlink control (PDCCH) monitoring, the indication of the change in the dormancy behavior for the one or more SCells or SCell groups (disclosed throughout; see [0055]-[0058], for example; first, [0055] indicates that the network may indicate to a terminal device (the UE) “whether to perform dormancy behavior in an SCell” and that this is indicated “by using 1-bit, to switch between the dormant BWP and a non-dormant BWP in the SCell”; further, as indicated in [0057], this indication may be sent “[w]hen connected mode (C)-DRX is not configured for the terminal device” – this is interpreted to be “continuous physical downlink control (PDCCH) monitoring” as the terminal continuously monitors the PDCCH when not in DRX (discontinuous reception); as indicated in [0057], this indication is carried via a DCI using one of a subset of formats (either DCI format 0_1 or DCI format 1_1)); and
one or more processors, individually or collectively (see processor 902 of Figure 9, for example), configured to apply the indicated change in dormancy behavior (disclosed throughout; see the description in [0055], which indicates that this change is implemented by switching to/from a dormant BWP and a non-dormant BWP).
As indicated above, the UE in Xue clearly supports receiving an indication of a change in dormancy behavior for one or more secondary cells (SCells) or SCell groups using downlink control information (DCI) associated with a first DCI format and that the UE is not required to receive the indication of the change in dormancy behavior via at least a second DCI format from multiple DCI formats comprising at least the first DCI format and the second DCI format (see [0055]-[0057] and the rejection above, which clearly indicate that the UE receives an indication of change of dormancy behavior in a subset of DCI formats (formats 0_1 and 1_1); further, this also discloses that the change of dormancy is limited to this subset of DCI formats and is not received in all DCI formats that could potentially carry a change of dormancy indication). Specifically, Xue discloses an indication from a network device that indicates to a terminal “whether to perform dormancy behavior” and that this “indication may be carried in a downlink control information (DCI) format 0_1 or a DCI format 1_1”. This is very similar to the language in [0052] in Applicant’s published application “the UE may receive a particular DCI format (e.g., DCI format 0_1 or 1_1) that includes a dormancy indication field for the switch between dormancy behavior and non-dormancy behavior” and [0056] in Applicant’s published application “may mean that the UE will support receiving the DCI format 0_1 or 1_1 that contains the “SCell dormancy indication” field”.
However, Xue does not explicitly disclose the limitation of transmitting to a network entity a capability report indicating that the UE supports this feature regarding receiving the dormancy indication using one of the subset of DCI formats. Similarly, Xue does not explicitly disclose receiving the indication of the change in dormancy in the first DCI format in accordance with the capability report.
First, the interpretation of the “capability report” claim limitation is that the report indicates support for a feature (change in dormancy behavior when C-DRX is not configured). This feature is implemented using an indication received using one of multiple DCI formats. However, the “capability report” does not indicate a specific format of these multiple formats, only whether the feature is supported. Consider [0056] of Applicant’s published application, which notes that “a UE capability report signaling may be defined to indicate to the network whether the UE supports the SCell dormancy function when CDRX is not configured”. That is, the capability report signaling indicates to the network whether the UE supports a particular function (the function being “SCell dormancy…when CDRX is not configured”). Next, [0056] notes that “Indication of this support may mean that the UE will support receiving the DCI format 0_1 or 1_1 that contains the ‘SCell dormancy indication’ field and is able to apply the indicated behavior”. This does not suggest that the capability report indication includes information identifying which of the DCI formats is supported. Rather, it indicates support for the feature of “SCell dormancy…when CDRX is not configured”. The indication of SCell dormancy happens to be included in a particular DCI format (and not in another DCI format), but this format is not indicated via the capability report.
Stated another way, claim 1 can be viewed broadly as requiring the steps of (1) transmitting to a network entity a capability report indicating support for a feature; (2) receiving a message in accordance with the feature; (3) applying the information in the received message. Xue discloses a UE that supports the feature, receives a message in accordance with the feature, and applying the information in the received message. Xue only differs from this claim in that the UE does not report to the network that it supports the feature.
However, sending a capability report from a UE to the network to indicate whether (or not) the UE supports a newly added feature is well known in the art. Consider Rai, for example, which discloses a UE transmitting “UE capability information” comprising a set of “feature group indicator (FGI) bits, each mapped to a particular capability, and each having a value (0 or 1) indicating whether or not the UE has that capability”. This information is transmitted “to inform the eNodeB what capabilities the UE has and does not have”. (See 8:8-22 of Rai, for example). Further, as indicated in 8:23-32, for example, if the UE does not support a particular feature, (such as determining and measuring neighboring coverage per events A4 and A5), then the network (eNodeB) will not perform functions associated with this feature in its communications with the UE. Clearly, the reverse is true – namely, when the UE indicates that it supports a feature, the network implements the functions associated with this feature.
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Xue such that the terminal/UE reports to the network whether it is capable a particular function (such as receiving the dormancy indication field and performing the functions associated with this indication field). The rationale for doing so would have been to ensure that the network only uses the dormancy indication field for terminals that can actually use it to prevent wasted bandwidth (by unnecessarily sending the information to devices not capable of using it) and also potential confusion where the network and terminal are not implementing the same functions.
Regarding claim 30: Xue discloses an apparatus for wireless communication by a network entity, comprising:
a transmitter (see transceiver 1001 of Figure 10, for example) configured to provide, via a DCI associated with a first DCI format to the UE that is in a first mode associated with continuous physical downlink control (PDCCH) monitoring, the indication of the change in the dormancy behavior for the one or more SCells or SCell groups (disclosed throughout; see [0055]-[0058], for example; first, [0055] indicates that the network may indicate to a terminal device (the UE) “whether to perform dormancy behavior in an SCell” and that this is indicated “by using 1-bit, to switch between the dormant BWP and a non-dormant BWP in the SCell”; further, as indicated in [0057], this indication may be sent “[w]hen connected mode (C)-DRX is not configured for the terminal device” – this is interpreted to be “continuous physical downlink control (PDCCH) monitoring” as the terminal continuously monitors the PDCCH when not in DRX (discontinuous reception); as indicated in [0057], this indication is carried via a DCI using one of a subset of formats (either DCI format 0_1 or DCI format 1_1)); and
one or more processors, individually or collectively (see processor 1002 of Figure 10, for example), configured to apply the indicated change in dormancy behavior (disclosed throughout; see the description in [0055], which indicates that this change is implemented by switching to/from a dormant BWP and a non-dormant BWP).
As indicated above, the UE in Xue clearly supports receiving an indication of a change in dormancy behavior for one or more secondary cells (SCells) or SCell groups using downlink control information (DCI) associated with a first DCI format and that the UE is not required to receive the indication of the change in dormancy behavior via at least a second DCI format from multiple DCI formats comprising at least the first DCI format and the second DCI format (see [0055]-[0057] and the rejection above, which clearly indicate that the UE receives an indication of change of dormancy behavior in a subset of DCI formats (formats 0_1 and 1_1); further, this also discloses that the change of dormancy is limited to this subset of DCI formats and is not received in all DCI formats that could potentially carry a change of dormancy indication). Specifically, Xue discloses an indication from a network device that indicates to a terminal “whether to perform dormancy behavior” and that this “indication may be carried in a downlink control information (DCI) format 0_1 or a DCI format 1_1”. This is very similar to the language in [0052] in Applicant’s published application “the UE may receive a particular DCI format (e.g., DCI format 0_1 or 1_1) that includes a dormancy indication field for the switch between dormancy behavior and non-dormancy behavior” and [0056] in Applicant’s published application “may mean that the UE will support receiving the DCI format 0_1 or 1_1 that contains the “SCell dormancy indication” field”.
However, Xue does not explicitly disclose the limitation of transmitting to a network entity a capability report indicating that the UE supports this feature regarding receiving the dormancy indication using one of the subset of DCI formats. Similarly, Xue does not explicitly disclose receiving the indication of the change in dormancy in the first DCI format in accordance with the capability report.
First, the interpretation of the “capability report” claim limitation is that the report indicates support for a feature (change in dormancy behavior when C-DRX is not configured). This feature is implemented using an indication received using one of multiple DCI formats. However, the “capability report” does not indicate a specific format of these multiple formats, only whether the feature is supported. Consider [0056] of Applicant’s published application, which notes that “a UE capability report signaling may be defined to indicate to the network whether the UE supports the SCell dormancy function when CDRX is not configured”. That is, the capability report signaling indicates to the network whether the UE supports a particular function (the function being “SCell dormancy…when CDRX is not configured”). Next, [0056] notes that “Indication of this support may mean that the UE will support receiving the DCI format 0_1 or 1_1 that contains the ‘SCell dormancy indication’ field and is able to apply the indicated behavior”. This does not suggest that the capability report indication includes information identifying which of the DCI formats is supported. Rather, it indicates support for the feature of “SCell dormancy…when CDRX is not configured”. The indication of SCell dormancy happens to be included in a particular DCI format (and not in another DCI format), but this format is not indicated via the capability report.
Stated another way, claim 1 can be viewed broadly as requiring the steps of (1) transmitting to a network entity a capability report indicating support for a feature; (2) receiving a message in accordance with the feature; (3) applying the information in the received message. Xue discloses a UE that supports the feature, receives a message in accordance with the feature, and applying the information in the received message. Xue only differs from this claim in that the UE does not report to the network that it supports the feature.
However, sending a capability report from a UE to the network to indicate whether (or not) the UE supports a newly added feature is well known in the art. Consider Rai, for example, which discloses a UE transmitting “UE capability information” comprising a set of “feature group indicator (FGI) bits, each mapped to a particular capability, and each having a value (0 or 1) indicating whether or not the UE has that capability”. This information is transmitted “to inform the eNodeB what capabilities the UE has and does not have”. (See 8:8-22 of Rai, for example). Further, as indicated in 8:23-32, for example, if the UE does not support a particular feature, (such as determining and measuring neighboring coverage per events A4 and A5), then the network (eNodeB) will not perform functions associated with this feature in its communications with the UE. Clearly, the reverse is true – namely, when the UE indicates that it supports a feature, the network implements the functions associated with this feature.
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Xue such that the terminal/UE reports to the network whether it is capable a particular function (such as receiving the dormancy indication field and performing the functions associated with this indication field). The rationale for doing so would have been to ensure that the network only uses the dormancy indication field for terminals that can actually use it to prevent wasted bandwidth (by unnecessarily sending the information to devices not capable of using it) and also potential confusion where the network and terminal are not implementing the same functions.
Regarding claims 2 and 15: Xue discloses the limitations that the first mode corresponds to mode in which connected mode discontinuous reception (CDRX) is not configured for the UE (as discussed above, see [0057], which indicates that the indication may be sent “[w]hen connected mode (C)-DRX is not configured for the terminal device”).
Regarding claims 3 and 16: Xue discloses the limitations that the indication is received via the DCI associated with the first DCI format that includes a dormancy indication field for a switch between a dormancy behavior and a non-dormancy behavior (disclosed throughout; see [0055], for example, which discloses the “1-bit” indicator used to indicated whether “to switch between the dormant BWP and a non-dormant BWP in the SCell”; further, see [0057]-[0058], for example, which discloses that this can be transmitted via a DCI).
Regarding claims 5 and 18: Xue discloses the limitations that the UE is configured with at least one dormant bandwidth part (BWP) and at least one non-dormant BWP for a SCell associated with the dormancy behavior and non-dormancy behavior when CDRX is not configured for the UE (disclosed throughout; see at least [0055], which discloses “A dormant BWP is configured in the SCell. Then, in the PCell, the terminal device is indicated, by using 1-bit, to switch between the dormant BWP and a non-dormant BWP in the SCell.” (emphasis added); this passage refers to both a dormant BWP and a non-dormant BWP in the SCell).
Regarding claims 6 and 19: Xue discloses the limitations that the non-dormant BWP comprises a first non- dormant BWP the UE operates in when switched from dormancy behavior to non- dormancy behavior on the associated SCell (disclosed throughout; see at least [0055], for example, which discloses that when the UE switches from dormancy to non-dormancy behavior (the indicator set to ‘1’ in the example), the UE “switches from the dormant BWP to the non-dormant BWP”).
Regarding claims 7 and 20: Xue discloses the limitations that the dormant BWP and first non-dormant BWP are configured separately for SCells (disclosed throughout; see the examples of BWP configuration discussed starting in [0068] and in Figures 3 and 4, for example; the dormant BWP and non-dormant BWPs are configured separately for SCells).
Regarding claims 9 and 22: Xue discloses the limitations that the UE is configured with the same dormant BWP and same non-dormant BWP when CDRX is configured for the UE (disclosed throughout; as indicated in [0058], for example, when CDRX is configured, the indication is received in a different DCI format; however, the BWPs are the same in both the CDRX not configured and CDRX configured modes).
Regarding claims 10 and 23: Xue discloses the limitations that the dormancy indication field is present in the DCI associated with the first DCI format only when one or more conditions are met (disclosed throughout; see [0057] and [0058], which discloses the particular DCI formats used for carrying the dormancy indication; see also [0017]-[0023], which indicate that a first configuration information regarding the DCI can comprise one of multiple “categories” of indication information, where one of these categories indicates that “neither first indication information nor second indication information” is present in the DCI, where “the second indication information is used to indicate the terminal device whether to perform a dormancy operation in a secondary cell”; another of the categories indicates that “the downlink control information includes at least one of first indication information or second indication information”; thus, the dormancy indication field is conditionally present in the DCI).
Regarding claims 13 and 26: Xue discloses the limitations of parent claims 2 and 15 as indicated above. Xue further discloses the limitation of applying the change in behavior indicated by the dormancy indication field (disclosed throughout; see the description in [0055], which indicates that this change is implemented by switching to/from a dormant BWP and a non-dormant BWP).
As indicated above, the UE in Xue clearly supports receiving DCI with the dormancy indication field when CDRX is not configured for the UE (see [0055]-[0057] and the rejection above, which clearly indicate that the UE receives an indication of change of dormancy behavior in a subset of DCI formats (formats 0_1 and 1_1) when CDRX is not configured for the UE). However, Xue does not explicitly disclose the limitation of reporting, to the network entity, that the UE supports this feature regarding receiving the dormancy indication when CDRX is not configured.
However, sending a capability report from a UE to the network to indicate whether (or not) the UE supports a newly added feature is well known in the art. Consider Tie, for example, which discloses in [0110] “The terminal-side device reports capability information of the terminal-side device by using signaling. The capability information includes, but is not limited to, a first offset and a BWP switching delay.” and further discloses in [0116] “The capability information reported by the terminal side may further include other information”. It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Xue such that the terminal/UE reports to the network that it is capable of receiving the dormancy indication field and performing the functions associated with this indication field. The rationale for doing so would have been to ensure that the network only uses the dormancy indication field for terminals that can actually use it to prevent wasted bandwidth (by unnecessarily sending the information to devices not capable of using it) and also potential confusion where the network and terminal are not aware of the state of particular BWPs that are used to communicate between them.
Claims 4 and 7 are rejected under 35 U.S.C. 103 as being unpatentable over Xue et al (US 2022/0264574) in view of Rai et al (US 9,973,951) in view of Tie et al (US 2023/0024064).
Regarding claims 4 and 17: Xue, modified, discloses the limitations of parent claims 3 and 16 as indicated above. However, Xue does not explicitly disclose the limitation that the DCI associated with the first DCI format is received in a slot according to a search space set configuration. However, Tie discloses a similar system that includes sending a dormancy indication in a DCI (see [0104] and [0105], for example). Tie further discloses, in at least [0119], [0120], and [0139], that the DCI configuration includes a search space set indicates the location of a monitoring occasion corresponding to the DCI including a start time at which the DCI format is detected. It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to indicate to the UE/terminal the location where the dormancy indication may be detected utilizing at least the search space configuration to indicate a monitoring occasion and start time. The rationale for doing so would have been to minimize power consumption by enabling the terminal/UE to efficiently locate the dormancy indication as suggested by Tie.
Claims 8 and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Xue et al (US 2022/0264574) in view of Rai et al (US 9,973,951) in view of Wang et al (US 12,225,546).
Regarding claims 8 and 21: Xue discloses the limitations of parent claims 5 and 18 as indicated above. Xue does not explicitly disclose the limitations of claims 8 and 21 that the UE is configured with at least one of a different dormant BWP or a different non-dormant BWP when CDRX is configured for the UE. However, Wang discloses a system for configuring dormancy behavior in SCells similar to Xue. Wang further discloses in 7:57-8:17 that the network side may “configure two Scell grouping configurations” and that two scenarios include either DRX active or inactive times or a “DCI corresponding to a Wake Up Signal (WUS)” and “the other…from normal DCI” may be configured as “different BWPs”. It would have been obvious to apply this teaching to the scenarios in Xue in which the CDRX is either configured or not configured, respectively. It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Xue such that the UE is configured with at least one different dormant or non-dormant BWP depending upon the CDRX configuration. The rationale for doing so would have been to enable the network to have flexibility in configuring the SCells to balance the various implementation factors when configuring the dormancy of SCells suggested in Wang.
Claims 11, 12, 24 and 25 are rejected under 35 U.S.C. 103 as being unpatentable over Xue et al (US 2022/0264574) in view of Rai et al (US 9,973,951) in view of MediaTek* (R1-2004669 - “Summary#1 for Procedure of Cross-Slot Scheduling Power Saving Techniques”).
* Cited in Applicant’s IDS filed 10/14/2022.
Regarding claims 11 and 24: Xue discloses the limitations of parent claims 10 and 23 as indicated above. Xue does not explicitly disclose the limitation that when connected mode DRX is not configured for the UE, the dormancy indication field is only present when the DCI associated with the first DCI format is carried by PDCCH on a primary cell and the UE is configured with at least two downlink bandwidth parts (BWPs) for an SCell. However, MediaTek discloses this on page 19 in the section attributed to Oppo and discussing the “SCell dormancy indication”. This section indicates that the field (SCell dormancy indication) “is only present when this format is carried by PDCCH on the primary cell within DRX Active Time and the UE is configured with at least two DL BWPs for an SCell”. It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Xue, which as indicated above discloses the use of the dormancy indication when connected mode DRX (CDRX) is not configured, such that the field is only present when the particular DCI format is carried by the PDCCH and at least two DL BWPs are configured of the UE on an SCell. The rationale for doing so would have been to conserve bandwidth by only including the indicator in the DCI (and increasing the size of the DCI) when the bits can actually be used (such as when at least two BWPs are configured for an SCell so that a BWP switch can be performed if indicated by the dormancy indicator).
Regarding claims 12 and 25: Xue, modified, discloses the limitations of parent claims 11 and 24 as indicated above. Xue does not explicitly disclose the limitation that when connected mode DRX is configured for the UE, the dormancy indication field is only present when the DCI associated with the first DCI format is carried by PDCCH on the primary cell within a DRX active time and the UE is configured with at least two DL BWPs for an SCell. However, MediaTek discloses this on page 19 in the section attributed to Oppo and discussing the “SCell dormancy indication”. This section indicates that the field (SCell dormancy indication) “is only present when this format is carried by PDCCH on the primary cell within DRX Active Time and the UE is configured with at least two DL BWPs for an SCell”. It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Xue, which as indicated above discloses the use of the dormancy indication when connected mode DRX (CDRX) is configured, such that the field is only present when the particular DCI format is carried by the PDCCH and at least two DL BWPs are configured of the UE on an SCell. The rationale for doing so would have been to conserve bandwidth by only including the indicator in the DCI (and increasing the size of the DCI) when the bits can actually be used (such as when at least two BWPs are configured for an SCell so that a BWP switch can be performed if indicated by the dormancy indicator).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 Robert C Scheibel whose telephone number is (571)272-3169. The examiner can normally be reached Monday-Friday 8:00 AM - 5:00 PM.
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, Hassan A Phillips can be reached at 571-272-3940. 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.
Robert C. Scheibel
Primary Examiner
Art Unit 2467
/Robert C Scheibel/Primary Examiner, Art Unit 2467 April 29, 2026
Prosecution Insights