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 .
Response to Amendment
The Amendment to the claims filed on 01/14/2026 complies with the requirements of 37 CFR 1.121(c) and has been entered.
Response to Arguments
Applicant's Arguments/Remarks filed 01/14/2026 (hereinafter Resp.) are fully considered hereinafter.
Applicant’s main argument against the prior art reference Hong, U.S. Patent Application Publication No. 2023/0380002 (hereinafter Hong) is that “the cited portions of Hong merely discuss an internal notification between layers ( e.g., MAC to RRC) followed by an autonomous UE state transition, whereas the amended claim 1 discloses that the UE transmits an external indication of timer expiry to the base station and waits for a subsequent network-side decision before transferring RRC states” – See Resp.,10:¶5. Examiner notes that the amended claim 1 does not recite the claimed feature “the UE transmits an external indication of timer expiry to the base station” and respectfully disagrees with the cursory reading of Hong, as explained below.
First, Hong discloses that “[a]lthough the disclosure does not contain the content of the UE operation related to the detailed definitions for the corresponding information elements, the content set forth in the standards may be incorporated in the disclosure” pointing out that “the disclosure may include the content of information elements and operations set forth in TS 38.321, the 3GPP NR MAC standard, and TS 38.331, the NR RRC standard” – See [¶0115]. Specifically, §5.3.1.1, 3GPP TS 38.331 V16.2.0 (2020-09), “Technical Specification Group Radio Access Network; NR; Radio Resource Control (RRC) protocol specification (Release 16)” (hereinafter 3GPP TS 38.331), specifies RRC connection control and states, at page 50 that: “The RRC message to suspend the RRC connection is integrity protected and ciphered” and “is initiated by the network”; furthermore, while “[t]he resumption of a suspended RRC connection is initiated by upper layers when the UE needs to transit from RRC_INACTIVE state to RRC_CONNECTED state,” among other situations, “[i]n response to a request to resume the RRC connection, the network may resume the suspended RRC connection and send UE to RRC_CONNECTED, or reject the request to resume and send UE to RRC_INACTIVE (with a wait timer), or directly re-suspend the RRC connection and send UE to RRC_INACTIVE, or directly release the RRC connection and send UE to RRC_IDLE.” The standards, and Hong, make it abundantly clear that there is no such “internal notification between layers (e.g., MAC to RRC) followed by an autonomous UE state transition” when a UE transitions between RRC connection states, as described in Applicant’s argument.
Second, Hong’s paragraph [¶0281], cited in the previous Office action, clearly states that upon timer expiration, “the base station may set/activate the MBS session as active state and transmit an RRC reconfiguration message for configuring/modifying/changing the MBS radio bearer mapped to the MBS session to the UE,” hence “the UE may be prevented from switching to the RRC idle state due to the function.” (emphasis added). Therefore, the argument that a “shift in decision authority to the base station ensures that high-QoS MBS sessions are not interrupted by local UE inactivity logic, a technical solution neither taught nor suggested by Hong” – See Resp., 10-11 is unpersuasive.
Applicant further argues that Hong reciting that “the UE may switch the RRC state to the RRC inactive state according to the instruction of the base station or trigger of the higher layer of the UE” – See [¶0119] does not teach that such an instruction is a consequent response to the expiry of the UE's data inactivity timer and explains that the amendment “defines a mandatory network-controlled handshake” whereby “the timer expiry does not trigger an autonomous state change, but rather a coordinated event where the final authority to transfer is externalized to the base station. This enables the network to veto a transition if high-QoS MBS sessions remain active-a technical dependency that is neither taught nor suggested by the passive, non-causal instruction described in Hong [0119]” – See Resp., 11:¶2 (emphasis added).
First, Hong [¶0119], a paragraph not cited in the previous Office action, specifically states “the UE may switch the RRC state to the RRC inactive state according to the instruction of the base station,” a statement sufficient for a person of ordinary skills to understand that the base station controls UE’s RRC state transition. In addition, subsequent paragraphs in Hong make abundantly clear that the base controls the MBS sessions and the RRC connection with the UE – See, e.g., [¶0131] (“the base station controlling multicast/broadcast services (MBS) processing of the UE may transmit, to the UE, an RRC connection release message including information to instruct whether to activate the MBS session”); see also [¶0133](“the UE may switch the RRC state to the RRC inactive state according to the instruction of the base station or according to trigger of the higher layer of the UE”);[¶0139](“When the UE initiates the RRC connection resume procedure based on the message, the base station may receive an RRC connection request message from the UE”).
Second, a UE having an RRC connection established with a base station, does not “autonomously” transition between RRC states because the standards do not provide for that autonomy; the UE must be first configured, at RRC level, to take or to not take an action related to the state of the RRC connection. Otherwise said, there are standardized “network-controlled handshake” RRC level procedures to transition a UE between the RRC states, many based on timers, including a data inactive timer, the procedures providing for base station control over the transition by sending RRC setup, release, reconfigure and reject messages to the UE, as explained in § 5, 3GPP TS 38.331 and schematized in Figure 4.2.1-1, at page 29. To be sure, for a “network-controlled handshake” to happen there must be an established network connection between the UE and the base station. This requirement excludes the only case when the UE relieves itself to the RRC_IDLE mode, and that is upon receiving an indication of 'RRC connection failure' cause from the lower layers – See, e.g., 3GPP TS 24.501 V17.0.0 (2020-09) “Technical Specification Group Services and System Aspects; System architecture for the 5G System (5GS); Stage 2 (Release 16)” (hereinafter 3GPP TS 24.501) (stating, in § 5.5.1.3.2, at page 262, that the UE shall initiate the network registration procedure “when the UE receives an indication of "RRC Connection failure" from the lower layers and does not have signalling pending . . . except for the case specified in subclause 5.3.1.4,” and § 5.3.1.4, at page 123, stating that “[a]ny pending procedure or uplink data packet when receiving an indication from the lower layers that the RRC connection has been suspended, triggers a request to the lower layers to transition to RRC_CONNECTED state”). For any other cases, 3GPPP TS 38.331 provides for network-controlled procedures to transition a UE between the RRC states.
Third, Applicant does not cite to any part of the Specification disclosing a “mandatory network-controlled handshake” upon the expiry of the timer. Although Applicant explains that “[s]upport for this amendment can be found throughout Applicant's specification and at least at paragraphs [0083], [0084], and [0087],” the cited paragraphs disclose, e.g., that “the BS may
transmit a second indication indicating whether to transfer from the first RRC state to
the second RRC state being RRC_IDLE state or RRC_INACTIVE state to the UE” and “the second indication may be a RRC release reject message” – See [¶¶0082-83]; that is no different from the RRC Release procedure initiated by the network as described in § 5.3.8, 3GPP TS 38.331:100 (“The network initiates the RRC connection release procedure to transit a UE in RRC_CONNECTED to RRC_IDLE; or . . . or to transit a UE in RRC_INACTIVE back to RRC_INACTIVE when the UE tries to resume; or to transit a UE in RRC_INACTIVE to RRC_IDLE when the UE tries to resume”). Furthermore, Hong specifically teaches that upon the expiry of the data inactivity timer the UE would be impeded to transit to RRC inactive if there is an active MBS session – See, e.g., [¶0267] (“If the UE receives data associated with the active
multicast session through an MBS session activation procedure, it is needed to maintain the RRC connected state of the UE in the active multicast session state” and “the receiving UE needs to be controlled not to switch to the RRC idle state”). It should be noted that the network, not the UE, is in control of the MBS session at all times, therefore knows whether to reject or not a UE’s request to release the RRC connection. This control “enables the network to veto a transition if high-QoS MBS sessions remain active” as taught by Hong. Therefore, Applicant’s argument that this “technical dependency . . . is neither taught nor suggested by the passive, non-causal instruction described in Hong [0119]” is unpersuasive. Finally, no person of ordinary skills in in the art would reasonably understand the amendment “an indication of the determination” as a “mandatory network-controlled handshake.”
In sum, all Applicant’s arguments have been fully addressed but are unpersuasive. In addition, the argument against Hong is also moot because the new ground of rejection necessitated by the Amendment.
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)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 13-14, as amended, are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Hong, U.S. Patent Application Publication No. 2023/0380002 (hereinafter Hong).
Regarding Amended Claim 13, Hong also teaches in Fig. 15 a network entity for wireless communication comprising: at least one memory; and at least one processor coupled with the at least one memory (“the controller 1510 transmits MBS data to the UE, necessary to perform the above-described embodiments and controls the overall operation of the base station 1500 necessary to configure the MBS” – See [¶0310] whereby the functions or operations are performed using “software code [that] may be stored in a memory unit and driven by a processor. The memory unit may be positioned inside or outside the processor to exchange data with the processor” – See [¶0315]) and operable to cause the network entity to:
set first inactivity timer associated with multicast and broadcast services (MBS) for a user equipment (UE) (“A UE may be configured with a data inactivity monitoring function by RRC in a RRC connected state” – See [¶0260] whereby “the data inactivity timer value may be one of {s1, s2, s3, s5, s7, sl0, s15, s20, s40, s50, s60, s80, sl00, s120, s150, and s180, where s1 means 1 second}. One value for disabling the function may be designated and applied to the UE, or a new value may be added to disable the function” – See [¶0272]);
monitor a data transmission state on a set of sessions associated with the UE in a first radio resource control (RRC) state (“the state change/ switching (active/inactive) for the MBS session may be triggered by an application function request or by whether to receive multicast data” – See [¶0253], e.g., “upon receiving data for the multicast session in the inactive state, the MB-UPF/UPF/base station may notify the AMF/SMF/MBSMF of it. The notification message may include MBS session identification information. The notification message may include indication information/message for notifying of downlink data for the MBS session” – See [¶0255]);
determine whether to indicate the UE to transfer from a first RRC state to a second RRC state based on the first inactivity timer and the monitoring (“If the higher layer (e.g., RRC) of the UE receives expiration of the data inactivity timer from the lower layer (e.g., MAC), the UE performs an action to enter the RRC_IDLE” – See [¶0266], however, “[i]f the UE receives data associated with the active multicast session through an MBS session activation procedure, it is needed to maintain the RRC connected state of the UE in the active multicast session state” – See [¶0267]); and
transmit an indication of the determination to the UE (“the base station may set/activate the MBS session as active state and transmit an RRC reconfiguration message for configuring/modifying/changing the MBS radio bearer mapped to the MBS session to the UE. Upon receiving the message (or upon receiving any related indication information, such as MBS session activation state indication, data inactivity timer pause/stop/suspend indication), the UE may stop/pause/suspend the MBS data inactivity timer. Thus, the UE may be prevented from switching to the RRC idle state due to the function” – See [¶0281]).
Therefore, Claim 13 is anticipated by Hong.
Regarding Claim 14, dependent from Claim 13, Hong further teaches the network entity of Claim 13 wherein the at least one processor is operable to cause the network entity to:
in a case that the first inactivity timer expires: indicate to the UE to transfer from the first RRC state being RRC_CONNECTED state to the second RRC state being RRC_IDLE state or RRC_INACTIVE state (“The base station may transmit an RRC release message (RRC release or RRC release with suspendconfig) according to the data inactivity timer of the UE, allowing the UE to enter the RRC idle or RRC inactive state” – See [¶0257]); and
indicate a MBS related UE inactivity to a core network (“the state change/ switching (active/inactive) for the MBS session may be triggered by an application function request or by whether to receive multicast data” – See [¶0253], whereby, a “timer (value) for checking the MBS session state change [may be configured] to the UPF/MB-UPF/base station” and “[i]f the timer for checking the MBS session state change expires, the UPF/MB-UPF/base station may transmit information for indicating MBS session deactivation to the AMF/SMF/MB-SMF,” i.e., the core network, e.g., because, due to UE inactivity, no data for the MBS session was received before the timer expiration – See [¶0254]; see also § 5.3.3, 3GPP TS 23.501 V16.6.0 (2020-09), “Technical Specification Group Services and System Aspects; System architecture for the 5G System (5GS); Stage 2 (Release 16),” at page 78-82, describing NAS signaling for a registered UE in CM_IDLE state).
Therefore, Claim 14 is anticipated by Hong.
In sum, Amended Claims 13-14 are rejected under 35 U.S.C. § 102(a)(2) as anticipated by Hong.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
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, 11, 15-17, and 23-26, as amended, are rejected under 35 U.S.C. 102(a)(2) as anticipated by Hong, U.S. Patent Application Publication No. 2023/0380002 (hereinafter Hong) or, in the alternative, under 35 U.S.C. 103 as being unpatentable over Hong in view of Shrivastava et al., U.S. Patent Application Publication No. 2023/0396965 (hereinafter Shrivastava).
Note: When the interpretation of the claim(s) is or may be in dispute, i.e., given one interpretation, a rejection under 35 U.S.C. 102 is appropriate and given another interpretation, a rejection under 35 U.S.C. 103 is appropriate, the examiner may make a rejection under both 35 U.S.C. 102 and 103. "There is nothing inconsistent in concurrent rejections for obviousness under 35 U.S.C. 103 and for anticipation under 35 U.S.C. 102." In re Best, 562 F.2d 1252, 1255 n.4, 195 USPQ 430, 433 n.4 (CCPA 1977). See MPEP §2111.01 and § 2112(III). Here, the “indication of the determination” may be interpreted as “signaling”, as Hong anticipates, or as “configuration” and Shrivastava is prior art.
Regarding Amended Claim 1, Hong teaches a method performed by a user equipment (UE) (“a method for processing multicast and broadcast services (MBS) data by a UE” – See [¶0006]), the method comprising:
receiving configuration information indicating a first data inactivity timer associated with multicast and broadcast services (MBS) (“the MBS configuration information may be received through the RRC dedicated message (e.g., RRC reconfiguration message) transmitted from the base station” – See [¶0220]; the “UE may be configured with a data inactivity monitoring function by RRC in a RRC connected state” – See [¶0260] whereby “[t]he base station may indicate a specific value (e.g., infinity) as the data inactivity timer value in the MAC-cell group configuration on the RRC reconfiguration message, allowing the UE to reconfigure/modify/release the function/timer” – See [¶0271]); and
determining whether to transfer from a first radio resource control (RRC) state to a second RRC state at least based on the first data inactivity timer (e.g., the default behavior is “[i]f the higher layer (e.g., RRC) of the UE receives expiration of the data inactivity timer from the lower layer (e.g., MAC), the UE performs an action to enter the RRC IDLE” – See [¶0266] but “the base station may add data reception through the MBS radio bearer mapped to the MBS session to the data inactivity timer operation in the MAC and process it, thereby preventing the UE from switching to the RRC idle state while receiving MBS session data” – See [¶0273] and “if the logical channel associated with the MBS session is received when the data inactivity timer is configured, the UE may start or restart the data inactivity timer” keeping it from expiring – See [¶0274]),
wherein in a case that the first data inactivity timer expires, an indication of the determination to transfer from the first RRC state to the second RRC state is received by the UE from a base station (BS) (when “the UE (MAC entity of the UE) indicates expiration of the data inactivity timer to the higher layer (RRC)” – See [¶0280], the UE may request from the base station, and “[t]he base station may transmit an RRC release message (RRC release or RRC release with suspendconfig) according to the data inactivity timer of the UE, allowing the UE to enter the RRC idle or RRC inactive state,” – See [¶0257], i.e., the UE in RRC_CONNECTED state explicitly requests RRC release from the base station and the base station releases the UE to RRC_INACTIVE/IDLE through RRC signaling). Therefore, Amended Claim 1 is anticipated by Hong.
In a case where the limitation “an indication of the determination to transfer from the first RRC state to the second RRC state is received by the UE from a base station (BS)” means, under a reasonable interpretation, that the UE is pre-configured by the base station with the indication of the determination to transfer from the first RRC state to the second RRC state, e.g., to save the time spent on RRC release request/release confirm or reject, then Hong does not teach this indication.
Shrivastava, like Hong, teaches “methods for guiding UE behavior, in terms of managing Radio Resource Control (RRC) state of the UE during MBS reception” – See [¶0007] aiming at controlling the UE RRC state to avoid “consuming higher battery power” and help “meet a predefined criterion required for ensuring reliability of MBS reception or loose the MBS reception” – See id.. Like Hong, Shrivastava teaches a “MBSdatainactivityTimer is configured, the UE” – See [¶0077].
Shrivastava explicitly teaches an indication of the determination to transfer from the first RRC state to the second RRC state is received by the UE from a base station (BS) in a case that the first data inactivity timer expires (“MBS specific Data Inactivity timer can be operated . . . as follows: . . . the wireless network 102 can provide a MBS configuration to the UE 101 that can include a "KeepConnectedMode" field” and “[t]he value of the KeepConnectedMode field can either ensure that the UE 101 remains in the RRC_CONNECTED state for MBS reception or allow the UE 101 to transit to the RRC_IDLE state or the RRC_INACTIVE state during MBS reception” when the timer expires, e.g., “if KeepConnectedMode=l, then the UE 101 remains in the RRC_CONNECTED state. In an embodiment, if KeepConnectedMode=0, then the UE 101 is allowed to transit to the RRC_IDLE state or the RRC_INACTIVE state” – See [¶¶0091-93] (emphasis added); furthermore, “the configuration or indication to the UE 101 is dynamically changed based on performance criteria such as throughput, error rate, latency, and so on, service reliability requirement, existing signal conditions, and so on” – See [¶0095]).
Thus, Hong and Shrivastava each teaches controlling UE behavior upon data inactivity timer expiration specified in the 3GPP technical standards. A person of ordinary skill in the art before the effective filing date of the claimed invention would have understood that the method of making a UE behavior deterministic based on the "KeepConnectedMode” indication from the base station, as taught by Shrivastava, could have been combined/substituted in for the method of UE restarting the timer based on received MBS session data or explicit RRC reconfiguration message, both controlled by the base station, as taught in Hong, because both methods provide the UE with indications for the determination to transfer from the first RRC state to the second RRC state. Furthermore, a person of ordinary skill in the art would have been able to carry out the combination/substitution through techniques known in the art. Finally, the result achieves the predictable result of indicating, by the base station, how the UE shall make the determination whether to transfer from a first RRC state to a second RRC state at least based on the first data inactivity timer for customized handling of RRC states of the UE while receiving specific types of MBS services in specific conditions.
Therefore, Amended Claim 1 is anticipated by Hong or, in the alternative, is obvious over Hong in view of Shrivastava.
Regarding Claim 2, dependent from Amended Claim 1, Hong further teaches the method of Claim 1, further comprising:
in a case of receiving or transmitting data on at least one logical channel of a set of logical channels in the first RRC state being RRC_CONNECTED state (e.g., “in the structure as shown in FIG. 13, there may be as many RLC entities of the leg/path for PTM transmission as the number of RRC connected UEs having joined the corresponding multicast group” – See [¶0245], i.e., a set of MBS logical channels), starting or restarting the first data inactivity timer (“if the logical channel associated with the MBS session is received when the data inactivity timer is configured, the UE may start or restart the data inactivity timer” – See [¶0274]); and
in a case that the first data inactivity timer expires, transferring to the second RRC state being RRC_IDLE state or RRC_INACTIVE state from the first RRC state (“If the data inactivity timer expires, the UE (MAC entity of the UE) indicates expiration of the data inactivity timer to the higher layer (RRC). If the higher layer (e.g., RRC) of the UE receives expiration of the data inactivity timer from the lower layer (e.g., MAC), the UE performs an action to enter the RRC_IDLE” – See [¶0264-66]).
Shrivastava, like Hong, further teaches that “if KeepConnectedMode=0, then the UE 101 is allowed to transit to the RRC_IDLE state or the RRC_INACTIVE state” – See [¶0093] in the case where “MBS specific Data Inactivity timer can be operated only for PTM logical channels (MTCH)” – See [¶0091] and “the datainactivityTimer expires” – See [¶0087].
Therefore, Claim 2 is anticipated by Hong or, in the alternative, is obvious over Hong in view of Shrivastava.
Regarding Claim 3, dependent from Claim 2, Hong further teaches the method of Claim 2, wherein the set of logical channels comprises at least one of: a multicast traffic channel (MTCH); and a multicast control channel (MCCH) (“The logical channel associated with the MBS session may indicate the MBS traffic logical channel and/or MBS control logical channel” – See [¶0274]).
Shrivastava, like Hong, teaches that an “MBS Control Channel (MCCH)” – See [¶0099] and “MTCH logical channel multicast MBS” – See [¶0102] whereby, e.g., a “MBS specific Data Inactivity timer can be operated only for PTM logical channels (MTCH)” – See [¶0091] .
Therefore, Claim 3 is anticipated by Hong or, in the alternative, is obvious over Hong in view of Shrivastava.
Regarding Claim 11, dependent from Amended Claim 1, Hong further teaches the method of Claim 1, further comprising:
in a case that the first data inactivity timer expires, transmitting a first indication to indicate expiry of the first data inactivity timer in the first RRC state being RRC_CONNECTED (“In the case of the multicast session, the UE may receive MBS data in an RRC connected state” – See [¶0107]; and “[i]f the data inactivity timer expires, the UE (MAC entity of the UE) indicates expiration of the data inactivity timer to the higher layer (RRC)” – See [¶¶0264-65]); and
receiving a second indication indicating whether to transfer from the first RRC state to the second RRC state being RRC_IDLE state or RRC_INACTIVE state (“The base station may receive information for indicating the multicast session as the active state or information for indicating activation of the multicast session” including “MBS context information” and “transmit an RRC reconfiguration message for configuring/modifying/changing the MBS radio bearer mapped to the MBS session to the UE” so that “the UE may stop/pause/suspend the MBS data inactivity timer. Thus, the UE may be prevented from switching to the RRC idle state due to the function” – See [¶0281]; in the alternative “[t]he base station may transmit an RRC release message (RRC release or RRC release with suspendconfig) according to the data inactivity timer of the UE, allowing the UE to enter the RRC idle or RRC inactive state” – See [¶0257]; in addition, “[i]f the higher layer (e.g., RRC) of the UE receives expiration of the data inactivity timer from the lower layer (e.g., MAC), the UE performs an action to enter the RRC_IDLE” – See [¶0266], however, “[i]f the UE receives data associated with the active multicast session through an MBS session activation procedure, is needed to maintain the RRC connected state of the UE in the active multicast session state” – See [¶0267]).
Therefore, Claim 11 is anticipated by Hong or, in the alternative, is obvious over Hong in view of Shrivastava.
Regarding Amended Claim 15, Hong teaches in Fig. 14 a user equipment (UE) for wireless communication comprising: at least one memory; and at least one processor coupled with the at least one memory (“a UE 1400 processing multicast and broadcast services (MBS) data includes a controller 1410 configured to control switching from an RRC state to an RRC inactive state and a receiver 1430 configured to receive a message for MBS session state notification from a base station. The controller 1410 may initiate a RRC connection resume procedure for switching the RRC state based on the message” – See [¶0287] whereby “the method according to the present embodiments may be implemented in the form of . . . software code [that] may be stored in a memory unit and driven by a processor,” i.e., the controller – See [¶0315]) and operable to cause the UE to: execute the steps recited in Amended Claim 1 using the same language. Because Amended Claim 1 is anticipated by Hong or, in the alternative, is obvious over Hong in view of Shrivastava, Amended Claim 15 is anticipated by Hong or, in the alternative, is obvious over Hong in view of Shrivastava.
Regarding Amended Claims 16-17, dependent from Amended Claim 15, they merely recite the same limitations as required by the method recited in Claims 2-3, respectively, only applied to the apparatus of Amended Claim 15. Because Claims 2-3 and 15, as amended, are anticipated by Hong or, in the alternative, are obvious over Hong in view of Shrivastava, Amended Claims 16-17 are also anticipated by Hong or, in the alternative, obvious over Hong in view of Shrivastava.
Regarding Amended Claim 23, dependent from Amended Claim 15, Hong further teaches the UE of Amended Claim 15, wherein the at least one processor is configured to cause the UE to:
deactivate or suspend the first data inactivity timer (“the UE [is allowed] to reconfigure/modify/release the function/timer so that the function is not operate” e.g., “the base station may indicate the timer value as the infinite value, disabling the timer/function” – See [¶0271]) in response to one of:
performing a MBS session join procedure for at least one MBS session or for at least one MBS session of a delivery mode with high quality of service (QoS) requirement, or for a multicast session (“The base station may receive an N2 message ( or message from 5GC through the AMF) from the AMF ( or any 5GC node/entity, e.g., SMF/MB-SMF) through a multicast session configuration procedure or multicast session activation procedure” including “multicast QoS flow information” – See [¶0270] and further send “the RRC reconfiguration message for configuring/modifying/changing the MBS radio bearer mapped to the MBS session to the UE,” e.g., after “a paging message to page the RRC_INACTIVE UE joining the multicast session through the radio interface (Uu)” and “the base station includes information for releasing the data inactivity timer”– See [¶0271] in response to the QoS setting requiring UE in RRC_CONNECTED state because “the MBS session may be classified in association with any (5G) QoS parameter”– See [¶0155]).
Shrivastava also teaches receiving a MBS session configuration for at least one MBS session, or for at least one MBS session of a delivery mode with high QoS requirement, or for a multicast session (“while receiving MBS, based on service configuration . . . the UE 101 may decide to stay in the RRC_CONNECTED state,” e.g., “when there is a need for high reliability (as indicated by service type such as multicast), higher Quality of service (QoS) requirement”– See [¶0110], i.e., “the MBS specific Data-Inactivity timer may be stopped or not operated” – See [¶0113]).
Therefore, Amended Claim 23 is anticipated by Hong or, in the alternative, is obvious over Hong in view of Shrivastava.
Regarding Amended Claim 24, dependent from Amended Claim 15, Hong further teaches the UE of Amended Claim 15, the at least one processor is operable to cause the UE to:
deactivate or suspend the first data inactivity timer in response to a received signaling indicating one of: a timer deactivation indication; and a timer suspension command (“the base station may . . . transmit an RRC reconfiguration message for configuring/modifying/changing the MBS radio bearer mapped to the MBS session to the UE. Upon receiving the message ( or upon receiving any related indication information, such as MBS session activation state indication, data inactivity timer pause/stop/suspend indication), the UE may stop/pause/suspend the MBS data inactivity timer. Thus, the UE may be prevented from switching to the RRC idle state due to the function” – See [¶0281]; in addition, “if the data inactivity function/timer is configured/applied to the UE, the base station may release the configuration” – See [¶0271]).
Therefore, Amended Claim 24 is anticipated by Hong or, in the alternative, is obvious over Hong in view of Shrivastava.
Regarding Amended Claim 25, dependent from Amended Claim 15, Hong further teaches the UE of Amended Claim 15, the at least one processor is operable to cause the UE to execute the steps of Claim 11, recited with the same language, and no other limitations. Because Claims 11 and 15, as amended, are anticipated by Hong or, in the alternative, are obvious over Hong in view of Shrivastava, Amended Claim 25 is also is anticipated by Hong or, in the alternative, is obvious over Hong in view of Shrivastava.
Regarding Amended Claim 26, dependent from Amended Claim 15, Hong further teaches the UE of Amended Claim 15, the at least one processor is operable to cause the UE to: set a value of the first data inactivity timer to be infinite (“The base station may indicate a specific value (e.g., infinity) as the data inactivity timer value in the MAC-cell group configuration on the RRC reconfiguration message, allowing the UE to reconfigure/modify/release the function/timer so that the function is not operated,” e.g., “the base station may indicate the timer value as the infinite value, disabling the timer/function” – See [¶0271]) in response to one of:
performing a MBS session join procedure for at least one MBS session (as explained in Regarding Claim 23, supra) or for at least one MBS session of a delivery mode with high quality of service (QoS) requirement, or for a multicast session;
receiving a MBS session configuration for at least one MBS session, or for at least one MBS session of a delivery mode with high QoS requirement, or for a multicast session (“The base station may receive an N2 message (or message from 5GC through the AMF) from the AMF (or any 5GC node/entity, e.g., SMF/MB-SMF) through a multicast session configuration procedure” whereby “[t]he N2 message may include MBS session context information. The MBS session context information may include one or more of MBS session ID, source specific multicast address, TMGI, multicast QoS flow information, MBS session AMBR, associated PDU session context, PDU session ID, S-NSSAI, PDU session AMBR, associated unicast QoS flow-multicast QoS flow information mapping/association” – See [¶0270] and “[u]pon receiving the information, the base station may transmit . . . the RRC reconfiguration message for configuring/modifying/changing the MBS radio bearer mapped to the MBS session to the UE” – See [¶0271], including the above data inactivity timer value setting); and
performing a MBS session start procedure for at least one MBS session, or for at least one MBS session of a delivery mode with high QoS requirement, or for a multicast session.
Therefore, Amended Claim 26 is anticipated by Hong or, in the alternative, is obvious over Hong in view of Shrivastava.
In sum, Claims 1-3, 11, 15-17, and 23-26, as amended, are rejected under 35 U.S.C §102(a)(2) as anticipated by Hong or, in the alternative, under 35 U.S.C. §103 as obvious over Hong in view of Shrivastava.
Amended Claim 22 is rejected under 35 U.S.C. 103 as being unpatentable over Hong in view of Shrivastava.
Regarding Amended Claim 22, dependent from Amended Claim 15, Hong further teaches the UE of Amended Claim 15, receiving MBS data on both unicast and multicast paths (“The UE may receive MBS service data transmitted according to the transmission scheme selected by the base station. For example, the base station may transmit data through one path (or two paths) of the RLC entity of the unicast leg/path for PTP transmission and the RLC entity of the leg/path for PTM transmission in the PDCP entity and the UE may receive the data” – See [¶0245] and Fig. 13). However, Hong does not teach two data inactivity timers.
Shrivastava, teaching that “the UE 101 may be configured, by the RRC layer, with a data inactivity monitoring functionality for unicast and MBS, when the UE 101 is in the RRC_CONNECTED state” – See [¶0076], discloses a first data inactivity timer for multicast operations (“[t]he RRC layer can control MBS data inactivity operation by configuring an MBSdatainactivityTimer” – See [¶0067], e.g., for “MTCH logical channel multicast MBS” – See [¶0069]) and further teaches wherein the configuration information further indicates a second data inactivity timer associated with unicast services (“datainactivityTimer is configured” e.g., when “MAC entity receives a MAC SDU for a DTCH logical channel (for unicast)” – See [¶¶0083-84]), and the at least one processor is operable to cause the UE to:
in a case of receiving or transmitting data on at least one MBS logical channel in the first RRC state being RRC_CONNECTED state, start or restart the first data inactivity timer (“If any MAC entity receives a MAC SDU for . . . MTCH logical channel for multicast MBS . . . Start or restart MBSdatainactivityTimer” – See [¶¶0077-80]);
in a case of receiving or transmitting data on at least one unicast logical channel, start or restart the second data inactivity timer (“If any MAC entity receives a MAC SDU for a DTCH logical channel (for unicast) . . . Start or restart datainactivityTimer,” – See [¶¶0083-86]); and
in a case that both the first data inactivity timer and the second data inactivity timer expire, transfer to the second RRC state being RRC_ IDLE state or RRC_INACTIVE state from the first RRC state (“receiving the expiry of datainactivityTimer and MBSdatainactivityTimer from lower layers while in RRC_CONNECTED, the UE 101 shall: 1. Perform the actions upon going to RRC_IDLE or RRC_INACTIVE” – See [¶¶0089-90]).
Because Amended Claim 15 is anticipated by Hong or, in the alternative, is obvious over Hong in view of Shrivastava, and the combination of the UE in Hong with Shrivastava are obvious to a person of ordinary skills in the art before the effective filing date of the claimed invention motivated by the desire of having a more deterministic UE behavior with MBS services, Amended Claim 22 is obvious over Hong in view of Shrivastava.
Claims 4, 6, and 18-21, as amended, are rejected under 35 U.S.C. 103 as being unpatentable over Hong in view of Shrivastava as applied to claims 2 and 16 above, and further in view of Fujishiro et al., U.S. Patent Application No. 2023/0171791 (hereinafter Fujishiro).
Regarding Claim 4, dependent from Claim 2, Hong in view of Shrivastava further teaches the method of Claim 2, wherein the set of logical channels is a subset of a set of MBS logical channels and the set of MBS logical channels comprises: a multicast traffic channel (MTCH) of a delivery mode with high quality of service (QoS) requirement and a multicast control channel (MCCH) of a delivery mode with high QoS requirement; a MTCH of a delivery mode with low QoS requirement; and a MCCH of a delivery mode with low QoS requirement (e.g., in LTE, “[o]ne SC-MCCH and one or more SC-MTCHs are mapped to the DL-SCH. Scheduling is provided by the base station. SC-MCCH and SC-MTCH each are indicated by one logical channel-specific RNTI (SC-RNTI or G-RNTI) on the PDCCH” and “single transmission is used for the DL-SCH to which SC-MCCH and SC-MTCH are mapped,” i.e. one MBS session associated with a subset of MTCH logical channels and one MCCH control channel – See Hong:[¶0098] and “in a RRC idle state, a UE was able to receive MBMS data of interest by receiving and configuring radio resource configuration information for receiving MBMS through a control logical channel (MCCH/SC-MCCH) associated with MBMS-related system information” – See id.:[¶0101]; furthermore, the NR uses MBS session ID for indicating the multicast group that the UE desires to join – See, e.g., id.:[¶0124], and a “MBS session may be classified in association with any (5G) QoS parameter” as provided through the “MBS control logical channel,” MCCH – See [¶0155] whereby “[t]he MBS session context may include one or more of MBS session ID” indicates “associated unicast QoS flow-multicast QoS flow information mapping/association, and multicast session state (active/inactive)” – See id.:[¶0237] and “the base station uses the MBS session QoS information for allocating a resource for serving the MBS session” – See id.:[¶0239], i.e., the MTCHs and the associated MCCH in the same MBS session context are associated with a QoS).
Shrivastava further teaches MBS session with high quality of service (QoS) requirement (“enable the UE to transit to the RRC_CONNECTED state from the RRC_INACTIVE state or the RRC_IDLE state, if reliability required for communication between the UE and the wireless network is high, Quality of Service (QoS) is high . . . if the multicast services and the broadcast services are being received through the PTP bearer” – See [¶0018]).
However, Hong in view of Shrivastava does not explicitly teach the low QoS requirement.
Fujishiro, like Hong in view of Shrivastava teaches a “method used in a mobile communication system including a base station for providing a multicast broadcast service (MBS) to a user equipment, the communication control method including transmitting, by the base station configured to manage a cell, in the cell, a plurality of MBS control channels associated with respective different service quality requirements” – See [¶0005] and that in “NR MBS-related logical channels are mapped to DL-SCHs” – See [¶0220] while “[i]n LTE, MCCHs and MTCHs are mapped to MCHs in the MESFN transmission scheme, whereas SC-MCCHs and SC-MTCHs are mapped to DL-SCHs in the SC-PTM transmission scheme” in the single cell MBS transmission scheme – See [¶0219] and Fig. 6, whereby “[a]n MBS control channel refers to the MCCH or SC-MCCH, and an MBS traffic channel refers to the MTCH or SC-MTCH” – See [¶0069].
Fujishito further teaches a set of MBS logical channels comprises: a multicast control channel (MCCH) of a delivery mode with high QoS requirement and a MCCH of a delivery mode with low QoS requirement (“a plurality of MBS control channels associated with respective different service quality requirements, and receiving, at the UE 100, an MBS control channel corresponding to the service quality requirement requested by the UE 100 among the plurality of MBS control channels” – See [0073] wherein “the plurality of MBS control channels may include a first MBS control channel for a predetermined MBS service and a second MBS control channel for an MBS service which requires a low latency compared to the predetermined MBS service” – See [¶0075], e.g., a high QoS MCCH “ is represented as ‘SC-MCCH delay-sensitive-services’” and a low QoS MCCH “is represented as ‘SC-MCCH-other-services’” – See [¶0087] and Fig. 7). Fujishito also teaches a set of MBS logical channels comprises:
a multicast traffic channel (MTCH) of a delivery mode with high quality of service (QoS) requirement; and a MTCH of a delivery mode with low QoS requirement (“the MBS system information transmitted in the broadcast control channel includes the SIBy indicating the scheduling of the MBS control channel and the SIBx indicating the scheduling of the MBS traffic channel” – See [¶0103], whereby “SIBx can directly point to an MBS traffic channel (MTCH #4) . . . an MBS traffic channel for transmitting MBS data for delay tolerant MBS service (Data for delay tolerant service)” – See [¶0104] and “MTCH #1 is an MBS traffic channel for transmitting MBS data for delay sensitive MBS service (Data for delay sensitive service). MTCH #2 and MTCH #3 are MBS traffic channels for transmitting MBS data of typical MBS service (Data for typical service)” – See [¶0106] and Fig. 9, i.e., MTCH #4 is for low QoS data and MTCH#1 is for high QoS MBS data traffic).
Thus, Hong in view of Shrivastava and Fujishito each teaches MBS control and data traffic logical channels. A person of ordinary skill in the art before the effective filing date of the claimed invention would have understood that the method of using different logical control and data traffic MBS channels for different UE or MBS session requirements, as taught in Fujishito could have been substituted for MCCH and MTCH logical channels in Hong in view of Shrivastava because both provide for MBS sessions that satisfy various QoS requirements required for each of specified usage scenarios. Furthermore, a person of ordinary skill in the art would have been able to carry out the substitution through techniques known in the art. Finally, the substitution achieves the predictable result of allowing the UE to receive the MBS control channel (MBS control information), and based on this information, receives the MBS traffic channel that the UE desires to receive, as taught in Fujishito.
Therefore, Claim 4 is obvious over Hong in view of Shrivastava and further in view of Fujishito.
Regarding Claim 6, dependent from Claim 2, Hong in view of Shrivastava further teaches the method of Claim 2, wherein the set of logical channels is a subset of a set of MBS logical channels, and the set of MBS logical channels comprises:
a traffic channel for a multicast session; a control channel for a multicast session (“The logical channel associated with the MBS session may indicate the MBS traffic logical channel and/or MBS control logical channel”– See Hong:[¶0275]; the “MBS based on 5G/NR in Rel-17. MBS denotes a multicast communication service and a broadcast communication service” – See id.:[¶0105] whereby “[i]n the case of the broadcast session, the UE may receive MBS data in RRC idle, RRC inactive, and RRC connected states” – See id.:[¶0106]; see also Shrivastava:[¶0094] (“the MBS configuration can be provided by . . . MCCH in the RRC_IDLE state, the RRC_INACTIVE state, or the RRC_CONNECTED state”)).
In addition, Hong in view of Shrivastava teaches a traffic channel for a broadcast session (the “LTE MBMS primarily targeting broadband broadcast” wherein “[s]ynchronized MBMS transmission is provided within the MBSFN area” – See Hong:[¶0097] and the “LTE-based MBMS supports only the broadcast mode” – See id.:[¶0100]; “reception of Multicast and Broadcast Service (MBS)” whereby “[t]he MBS reception comprises MBS multicast reception, wherein MAC SDU pertaining to a MBS Traffic Channel (MTCH) is received through a Point to Multipoint (PTM) bearer” – See Shrivastava:[¶0022]) and a control channel for a broadcast session (“the MBS configuration information/configuration parameter for receiving MBS data may be indicated . . . through the SIB on the BCCH” – See Hong:[¶0148]).
Hence Hong in view of Shrivastava teaches the MBSFN-like broadcast transmission scheme the set of MBS logical channels comprises a traffic channel for a broadcast session and a broadcasting control channel for receiving the system information about the broadcasting session. In addition, Fujishito shows in Fig. 6, among all logical channels, the set of MBS logical channels comprises MTCH and MCCH mapped to a multicast session and BCCH and LTE like SC-MTCH mapped to a broadcast session.
Therefore, Claim 6 is obvious over Hong in view of Shrivastava and further in view of Fujishito.
Regarding Amended Claims 18 and 20, dependent from Amended Claim 16, each claim merely recites the same limitations as required by the method in Claims 4 and 6, respectively, only applied to the apparatus of Amended Claim 16. Because Amended Claim 16 is obvious over Hong in view of Shrivastava and Claims 4 and 6 are obvious over Hong in view of Shrivastava and further in view of Fujishito, each of the Amended Claims 18 and 20 is obvious over Hong in view of Shrivastava and further in view of Fujishito.
Regarding Amended Claim 19, dependent from Amended Claim 18, Hong in view of Shrivastava further teaches the apparatus of Amended Claim 18 receiving MBS with high QoS (“the MBS session may be classified in association with any (5G) QoS parameter” – See Hong:[¶0155] and “the base station uses the MBS session QoS information for allocating a resource for serving the MBS session” – See id.:[¶0239], whereby “there is a need for high reliability (as indicated by service type such as multicast), higher Quality of service (QoS) requirement” – See Shrivastava:[¶0110])
However, Hong in view of Shrivastava does not teach the subset of the set of MBS logical channels with high QoS.
Fujishito teaches the subset of the set of MBS logical channels comprises at least:
the MTCH of a delivery mode with high QoS requirement; and the MCCH of a delivery mode with high QoS requirement (“FIG. 9 illustrates an example in which (SC-)MCCH #1 points to one MBS traffic channel (MTCH #1)” whereby “MTCH #1 is an MBS traffic channel for transmitting MBS data for delay sensitive MBS service (Data for delay sensitive service),” i.e., a high QoS – See [¶0106] and Fig. 9). Because the combination of Hong in view of Shrivastava and Fujishito at logical channel level is obvious to a person of ordinary skills in the art as explained in Regarding Claim 4 supra, Amended Claim 19 is obvious over Hong in view of Shrivastava in view of Fujishito.
Regarding Amended Claim 21, dependent from Amended Claim 20, Hong in view of Shrivastava further teaches the apparatus of Amended Claim 20, wherein the subset of the set of MBS logical channels comprises at least one of: the traffic channel for a multicast session; and the control channel for a multicast session (“The logical channel associated with the MBS session may indicate the MBS traffic logical channel and/or MBS control logical channel” – See Hong:[¶0274]). In addition, Fujishito also shows in Fig. 9 logical channels MCCH#1 and MTCH#1 as a subset of the set of MBS logical channels.
Therefore, Amended Claim 21 is obvious over Hong in view of Shrivastava in view of Fujishito.
In sum, Claims 4, 6, and 18-21, as amended, are rejected under 35 U.S.C. § 103 as obvious over Hong in view of Shrivastava in view of Fujishito.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Latheef et al., U.S. Patent Application Publication No. 2023/0300938 discloses methods and systems for managing MBS service continuity on a terminal, upon state change and upon cell change in a NR wireless network;
Hong, U.S. Patent Application Publication No. 2023/0292092 also discloses a method and device for transmitting/receiving multicast/broadcast service (MBS) data in an NR radio access network;
Babaei, U.S. Patent Application Publication No. 2025/0274816 discloses method and apparatus for MBS service continuity in IDLE and INACTIVE states;
Di Girolamo et al., U.S. Patent Application Publication No. 2023/0276470 discloses methods and apparatuses are described herein for 5G MBS operation;
Liao, U.S. Patent Application Publication No. 2021/0075631 teaches that Quality of Service (QoS) framework of clause 5.7 of 3GPP TS 23.501 is taken as baseline for NR MBS;
3GPP TS 23.501 V16.6.0 (2020-09), “Technical Specification Group Services and System Aspects; System architecture for the 5G System (5GS); Stage 2 (Release 16)”;
3GPP TS 24.501 V17.0.0 (2020-09), “Technical Specification Group Core Network and Terminals; Non-Access-Stratum (NAS) protocol for 5G System (5GS); Stage 3; (Release 17)”;
3GPP TS 38.331 V16.2.0 (2020-09), “Technical Specification Group Radio Access Network; NR; Radio Resource Control (RRC) protocol specification (Release 16)”;
3GPP TR 23.757 V1.2.0 (2020-11), “Technical Specification Group Services and System Aspects; Study on architectural enhancements for 5G multicast-broadcast services (Release 17)”;
3GPP TS 36.331 V16.2.1 (2020-09), “Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specification (Release 16)”;
3GPP TS 38.321 V16.2.1 (2020-09), “Technical Specification Group Radio Access Network; NR; Medium Access Control (MAC) protocol specification (Release 16);
3GPP TSG-RAN WG2 Meeting #111e, R2-2006793, Action Item 8.1.1, Title: “NR Multicast Radio Bearer Architecture aspects,” Source: Qualcomm, teaches a MBTCH downlink channel and GBR and non-GBR QoS flows;
3GPP TSG-RAN WG2 Meeting #111 electronic, R2-2007442, Action Item 8.1.1, Title: “Scope and Architecture analysis of NR MBS,” Source: ZTE, Sanechips; August 2020, proposing LTE MBMS and SC-PTM as disclosed in 3GPP TS 36.331, § 5.8.5.2 as baseline, and a QoS model
3GPP TSG-RAN WG2 Meeting #112-e, R2-2011022, Action Item 8.1.1, Title: “Summary of [AT112-e][036][MBS] SA2 LS on MBS,” Source: Huawei, November 2020;
3GPP TSG-RAN WG2 Meeting #112-e, R2-2009036, Action Item 8.1.1, Title: “NR Multicast Vs Broadcast comparison and Radio Bearer Architecture aspects,” Source: Qualcomm, November 2020;
SA-WG2 Meeting #S2-140E, ChairmansNotes_Combined_AI#_3.X_4.2_8.X_9.X _09-01-FINAL-UPDATED (and documents referenced therein for Action Item 8.9), September 2020.
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 LUCIA GHEORGHE GRADINARIU whose telephone number is (571)272-1377. The examiner can normally be reached Monday-Friday 9:00am - 5:00pm 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, Joseph AVELLINO can be reached at (571)272-3905. 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.
/L.G.G./ Examiner, Art Unit 2478
/KODZOVI ACOLATSE/ Primary Examiner, Art Unit 2478