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 Remarks
This Office action is considered fully responsive to the amendments filed 12/09/2025.
Response to Arguments
Applicant’s arguments, see Remarks, filed 12/09/2025, with respect to the rejection(s) of claim(s) 1-9, 15 and 30 under U.S.C. 102 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of EP 2978245 A1.
With respect to the amendments to claims 3 and 15 (Remarks, page 7), see the prior art rejections below which address these limitations as they are specifically taught by Xu.
All claims are rejected as indicated in the Claim Rejections section below.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 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.
Claim(s) 1-9, 15, 30 is/are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Publication No. 2022/0217506 A1 to XU et al. (“Xu”) in view of EP 2978245 A1 to HAN.
As to claim 1, Xu discloses a method for determining a delivery mode (para. 0092, The access network side device sends the multicast service to the terminal side device in the cell, and the terminal side device receives the multicast service on a multicast traffic channel (MTCH), i.e. radio delivery mode) for multicast broadcast service (MBS) service (para. 0003, a multicast service, such as a multimedia broadcast multicast service (MBMS)), performed by access network (AN) function (fig. 1A, fig. 2, Access network side device), comprising: receiving MBS assistance information sent by core network (CN) function or an operation, administration and maintenance (OAM) platform (fig. 1A, Access network side device receives Multicast service from Core network side device, i.e. CN; para. 0092, the core network side device sends a start message of the multicast service to an access network side device, where the start message indicates an interne protocol (IP) address of the multicast service and a cell for sending the multicast service, i.e. these being assistance information; para. 0003, a multicast service, such as a multimedia broadcast multicast service (MBMS)); and determining a radio delivery mode for MBS service and/or radio resources for the MBS service according to the MBS assistance information (fig. 1A, para. 0092, The access network side device sends the multicast service to the terminal side device in the cell, and the terminal side device receives the multicast service on a multicast traffic channel (MTCH), i.e. radio delivery mode, based on the configuration information of the multicast service. To enable the terminal side device to obtain the MCCH message, the access network side device further sends MCCH configuration information to the terminal side device. The MCCH configuration information includes an MCCH modification periodicity, an MCCH repetition periodicity, an MCCH start location, and the like, i.e. radio resources; para. 0090, Data is transmitted between the terminal side device and the access network side device through at least one established radio bearer (RB), i.e. radio resources; para. 0097, A manner used by the access network side to send the multicast service is sending the multicast service in only a unicast manner, in only a multicast manner, or in the unicast manner and the multicast manner. Optionally, the access network side device notifies the terminal side device of a receiving manner used for the multicast service, and the terminal side device receives the multicast service based on the receiving manner, i.e. delivery mode).
Xu does not expressly disclose wherein the MBS assistance information comprises one or more of the following information: UE subscription data related to MBS services; AN performance information, used for indicating a congestion status of the AN; CN performance information, used for indicating a congestion status or communication performance of the CN; or suggested information or suggested policy for the delivery mode used by the AN under specified performance of CN.
HAN discloses at fig. 2 a base station (i.e. AN) receives an MBMS service transmission request (i.e. MBS assistance information) and MBMS service data that are sent by a core network device (i.e. CN). The base station (i.e. AN) sends the MBMS service data to a UE according to (i.e. delivery mode) the MBMS service transmission request (i.e. MBS assistance information); paras. 0127-0128: after receiving the MBMS service transmission request, the base station may configure MBMS configuration information and send the MBMS configuration information and the MBMS service data to the UE. The UE may receive the MBMS service data according to the MBMS configuration information. The foregoing MBMS configuration information may further include an MBMS control channel MCCH resource configuration message. The UE may acquire corresponding MCCH information according to the MCCH resource configuration message, and receive the MBMS service data from a resource location corresponding to the MCCH information (i.e. the MBMS service transmission request is suggested information or suggested policy for the delivery mode used by the AN under specified performance of CN, as it is specified by the CN for the AN to perform a specific delivery of the MBMS service data after receiving it).
Further, para. 0184-0185 discloses content of the MBMS service paging message may be set according to a requirement in an actual application scenario, and is generally set according to (i.e. suggested information or suggested policy) the received MBMS service transmission request (i.e. MBS assistance information) or MBMS service data. Specifically, the MBMS service paging message may include but is not limited to: a transceiving manner of an MBMS service (i.e. for the delivery mode).
Prior to the effective filing date of invention, it would have been obvious to a person of ordinary skill in the art to incorporate the MBMS service transmission request as taught by HAN into the invention of Xu. The suggestion/motivation would have been to allow for MBMS service data communication (HAN, para. 0005). Including the MBMS service transmission request as taught by HAN into the invention of Xu was within the ordinary ability of one of ordinary skill in the art based on the teachings of HAN.
As to claim 2, Xu and HAN further discloses the method of claim 1, wherein the MBS service comprises a first MBS session (Xu, para. 0092, The access network side device sends the multicast service (i.e. first MBS session) to the terminal side device in the cell, and the terminal side device receives the multicast service on a multicast traffic channel (MTCH) based on the configuration information of the multicast service. To enable the terminal side device to obtain the MCCH message, the access network side device further sends MCCH configuration information to the terminal side device) or a quality of service (QoS) flow that is being established (Xu, Para. 0117, all data packets of the multicast service are corresponding to at least one quality of service (QoS) flow that belongs to a same PDU session, the multicast service belongs to the same PDU session) or modified, and/or a second MBS session or QoS flow with data transmission in progress (Xu, para. 0117, a plurality of data packets included in the multicast service are corresponding to a plurality of QoS flows that belong to a plurality of PDU sessions, the multicast service belongs to the plurality of PDU sessions). In addition, as the primary reference is used to teach the instant claim limitations, see the suggestion/motivation of claim 1.
As to claim 3, Xu and HAN further discloses the method of claim 1, wherein the MBS assistance information further comprises one or more of the following information: a first number of user equipments (UEs), used for indicating that the AN function is suggested to deliver MBS service or session in a multicast or broadcast mode when the number of UEs that are receiving or expect to receive the MBS service or session under the AN function or a cell of the AN function reaches the first number of UEs (Xu, para. 0099, The identifier corresponding to the multicast manner may be an identifier dedicated to a multicast group to which the terminal side device belongs, for example, a group-radio network temporary identifier (G-RNTI); para. 0120, plurality of terminal side devices to send feedbacks for the multicast service); or a second number of UEs, wherein the second number of UEs is the number of UEs counted or predicted by the CN or OAM that are receiving or expect to receive MBS service or session under the AN function or a cell of the AN function, information of a delivery mode for specified service (Xu, para. 0097, A manner used by the access network side to send the multicast service is sending the multicast service in only a unicast manner, in only a multicast manner, or in the unicast manner and the multicast manner. Optionally, the access network side device notifies the terminal side device of a receiving manner used for the multicast service, and the terminal side device receives the multicast service based on the receiving manner) or application (Xu, para. 0092, internet protocol (IP) address, i.e. a internet protocol being an application) or session (Xu, para. 0092, the start message indicates an interne protocol (IP) address of the multicast service and a cell for sending the multicast service, i.e. sending the service is a session) or QoS flow (Xu, para. 0092, the start message indicates an interne protocol (IP) address of the multicast service and a cell for sending the multicast service; Para. 0117, all data packets of the multicast service are corresponding to at least one quality of service (QoS) flow); UE capability information for delivery mode (Xu, para. 0098-0099, C-RNTI, G-RNTI, i.e. UE is capable for receiving unicast/multicast); or suggested information of the delivery mode used by the AN under specified performance of AN (Xu, para. 0097, A manner (i.e. delivery mode) used by the access network side to send the multicast service (i.e. a specified performance of AN) is sending the multicast service in only a unicast manner, in only a multicast manner, or in the unicast manner and the multicast manner. Optionally, the access network side device notifies (i.e. suggested information) the terminal side device of a receiving manner used for the multicast service, and the terminal side device receives the multicast service based on the receiving manner.). In addition, as the primary reference is used to teach the instant claim limitations, see the suggestion/motivation of claim 1.
As to claim 4, Xu and HAN further discloses the method of claim 3, further comprising: determining a third number of UEs according to local measurement of the AN function (Xu, para. 0090, Data is transmitted between the terminal side device and the access network side device through at least one established radio bearer (RB), i.e. local measurement; para. 0120, The access network side device may use a common RRC message to carry the first configuration information and send the common RRC message to a plurality of terminal side devices, i.e. third number of UEs ) or the second number of UEs, wherein the third number of UEs is the number of UEs that receive the MBS service (Xu, para. 0120, The access network side device may use a common RRC message to carry the first configuration information and send the common RRC message to a plurality of terminal side devices, so as to configure the plurality of terminal side devices to send feedbacks for the multicast service) or session under the AN function or a cell of the AN function; and determining, by the AN function, that the radio delivery mode for the MBS service or session is multicast or broadcast radio delivery mode (Xu, para. 0120, send feedbacks for the multicast service), and/or the radio resources for the MBS service or session are multicast or broadcast radio resources when the third number of UEs reaches a fourth number of UEs, wherein the fourth number of UEs is the first number of UEs or the minimum number of UEs that receive the MBS service or session in a multicast or broadcast mode determined by the AN function according to a local policy [i.e. due to “or” limitations are not given patentable weight]. In addition, as the primary reference is used to teach the instant claim limitations, see the suggestion/motivation of claim 1.
As to claim 5, Xu and HAN further discloses the method of claim 3, further comprising: receiving a radio resource control (RRC) message sent by the UE, wherein the RRC message includes a first identifier used for indicating MBS service that the UE expects to receive (Xu, fig. 2, feedback 202; para. 0137, the RRC message includes a plurality of bits corresponding to a plurality of multicast services received by the terminal side device in a same cell. A bit location of the i.sup.th bit in the plurality of bits indicates a multicast service i in the plurality of multicast services, and a bit state of the i.sup.th bit indicates whether receiving of the multicast service i succeeds or fails. For example, a bit state “0” indicates that receiving succeeds, and a bit state “1” indicates that receiving fails, i.e. a failure indicates what the UE expects to receive); determining, for the UE, radio delivery mode for MBS service and/or radio resources for the MBS service when the UE subscription data related to MBS services includes the MBS service that the UE expects to receive (Xu, para. 0165, the terminal side device sends an RLC status report to indicate which multicast service received on the RLC entity corresponding to the unicast manner fails, and optionally, the RLC status report specifically indicates which data packet or data packets of the multicast service fails to be received. The access network side device may retransmit, on the RLC entity (i.e. radio delivery mode/radio resources pertaining to the multicast broadcast service) corresponding to the unicast manner, the data packet that the terminal side device fails to receive.). In addition, as the primary reference is used to teach the instant claim limitations, see the suggestion/motivation of claim 1.
As to claim 6, Xu and HAN further discloses the method of claim 3, wherein the information of a delivery mode for the specified service or application or session or QoS flow includes that the specified service or application or session or QoS flow is allowed to be delivered in a multicast or broadcast mode only, or in a unicast mode only, or in both unicast and multicast or broadcast modes (Xu, para. 0097, A manner used by the access network side to send the multicast service is sending the multicast service in only a unicast manner, in only a multicast manner, or in the unicast manner and the multicast manner. Optionally, the access network side device notifies the terminal side device of a receiving manner used for the multicast service, and the terminal side device receives the multicast service based on the receiving manner). In addition, as the primary reference is used to teach the instant claim limitations, see the suggestion/motivation of claim 1.
As to claim 7, Xu and HAN further discloses the method of claim 3, wherein the determining a radio delivery mode for MBS service and/or radio resources for the MBS service according to the MBS assistance information, comprises: determining a radio delivery mode for MBS service and/or radio resources for the MBS service or session according to the congestion status or communication performance of the AN and/or the congestion status or communication performance of the CN (Xu, para. 0097, A manner used by the access network side to send the multicast service is sending the multicast service in only a unicast manner, in only a multicast manner, or in the unicast manner and the multicast manner. Optionally, the access network side device notifies the terminal side device of a receiving manner used for the multicast service, and the terminal side device receives the multicast service based on the receiving manner, i.e. determining unicast/multicast delivery mode based on access network communicating in that manner). In addition, as the primary reference is used to teach the instant claim limitations, see the suggestion/motivation of claim 1.
As to claim 8, Xu discloses a method for determining a delivery mode for multicast broadcast service (MBS) service (para. 0092, The access network side device sends the multicast service to the terminal side device in the cell, and the terminal side device receives the multicast service on a multicast traffic channel (MTCH), i.e. radio delivery mode; para. 0003, a multicast service, such as a multimedia broadcast multicast service (MBMS)), performed by core network (CN) function or an operation, administration and maintenance (OAM) platform (para. 0092, the core network side device sends a start message of the multicast service to an access network side device, where the start message indicates an interne protocol (IP) address of the multicast service and a cell for sending the multicast service; para. 0003, a multicast service, such as a multimedia broadcast multicast service (MBMS); para. 0097, receiving manner, i.e. delivery mode), comprising: determining MBS assistance information (para. 0092, the core network side device sends a start message of the multicast service to an access network side device, where the start message indicates an interne protocol (IP) address of the multicast service and a cell for sending the multicast service, i.e. these being assistance information; para. 0003, a multicast service, such as a multimedia broadcast multicast service (MBMS)); and sending the MBS assistance information to access network (AN) function for indicating the AN function to determine a radio delivery mode for MBS service and/or a radio resources for the MBS service according to the MBS assistance information (fig. 1A, para. 0092, The access network side device sends the multicast service to the terminal side device in the cell, and the terminal side device receives the multicast service on a multicast traffic channel (MTCH), i.e. radio delivery mode, based on the configuration information of the multicast service. To enable the terminal side device to obtain the MCCH message, the access network side device further sends MCCH configuration information to the terminal side device. The MCCH configuration information includes an MCCH modification periodicity, an MCCH repetition periodicity, an MCCH start location, and the like, i.e. radio resources; para. 0090, Data is transmitted between the terminal side device and the access network side device through at least one established radio bearer (RB), i.e. radio resources; para. 0097, A manner used by the access network side to send the multicast service is sending the multicast service in only a unicast manner, in only a multicast manner, or in the unicast manner and the multicast manner. Optionally, the access network side device notifies the terminal side device of a receiving manner used for the multicast service, and the terminal side device receives the multicast service based on the receiving manner, i.e. delivery mode).
Xu does not expressly disclose wherein the MBS assistance information comprises one or more of the following information: UE subscription data related to MBS services; AN performance information, used for indicating a congestion status of the AN; CN performance information, used for indicating a congestion status or communication performance of the CN; or suggested information or suggested policy for the delivery mode used by the AN under specified performance of CN.
HAN discloses at fig. 2 a base station (i.e. AN) receives an MBMS service transmission request (i.e. MBS assistance information) and MBMS service data that are sent by a core network device (i.e. CN). The base station (i.e. AN) sends the MBMS service data to a UE according to (i.e. delivery mode) the MBMS service transmission request (i.e. MBS assistance information); paras. 0127-0128: after receiving the MBMS service transmission request, the base station may configure MBMS configuration information and send the MBMS configuration information and the MBMS service data to the UE. The UE may receive the MBMS service data according to the MBMS configuration information. The foregoing MBMS configuration information may further include an MBMS control channel MCCH resource configuration message. The UE may acquire corresponding MCCH information according to the MCCH resource configuration message, and receive the MBMS service data from a resource location corresponding to the MCCH information (i.e. the MBMS service transmission request is suggested information or suggested policy for the delivery mode used by the AN under specified performance of CN, as it is specified by the CN for the AN to perform a specific delivery of the MBMS service data after receiving it).
Further, para. 0184-0185 discloses content of the MBMS service paging message may be set according to a requirement in an actual application scenario, and is generally set according to (i.e. suggested information or suggested policy) the received MBMS service transmission request (i.e. MBS assistance information) or MBMS service data. Specifically, the MBMS service paging message may include but is not limited to: a transceiving manner of an MBMS service (i.e. for the delivery mode).
Prior to the effective filing date of invention, it would have been obvious to a person of ordinary skill in the art to incorporate the MBMS service transmission request as taught by HAN into the invention of Xu. The suggestion/motivation would have been to allow for MBMS service data communication (HAN, para. 0005). Including the MBMS service transmission request as taught by HAN into the invention of Xu was within the ordinary ability of one of ordinary skill in the art based on the teachings of HAN.
As to claim 9, Xu and Han further discloses the method of claim 8, wherein the determining MBS assistance information comprises: determining, by the CN function or the OAM platform, the MBS assistance information based on one or more of the following parameters: analytics information of network data (Xu, para. 0092, When a multicast service arrives at a core network side device from a service content provider (for example, various Internet servers), i.e. analytics information of network data, the core network side device sends a start message of the multicast service to an access network side device, where the start message indicates an interne protocol (IP) address of the multicast service and a cell for sending the multicast service); MBS policy (Xu, fig. 1A, Core network side device upon arrival of a multicast service [para. 0003, a multicast service, such as a multimedia broadcast multicast service (MBMS)] (i.e. MBS policy), determine that the multicast service is started); UE subscription data related to MBS services (Xu, para. 0086, terminal is also referred to as user equipment (UE); para. 0092, the core network side device sends a start message of the multicast service to an access network side device, where the start message indicates an interne protocol (IP) address of the multicast service and a cell for sending the multicast service…the access network side device sends the multicast service to the terminal side device in the cell, i.e. UE being within a cell means it is subscribed to the cell ); or information sent by the UE to the CN function through non-access stratum (NAS) signaling. In addition, as the primary reference is used to teach the instant claim limitations, see the suggestion/motivation of claim 8.
As to claim 15, Xu and HAN further discloses the method of claim 8, wherein the MBS assistance information further comprises one or more of the following information: a first number of user equipments (UEs), used for indicating that the AN function is suggested to deliver MBS service or session in a multicast or broadcast mode when the number of UEs that are receiving or expect to receive the MBS service or session under the AN function or a cell of the AN function reaches the first number of UEs (Xu, para. 0099, The identifier corresponding to the multicast manner may be an identifier dedicated to a multicast group to which the terminal side device belongs, for example, a group-radio network temporary identifier (G-RNTI); para. 0120, plurality of terminal side devices to send feedbacks for the multicast service); or a second number of UEs, wherein the second number of UEs is the number of UEs counted or predicted by the CN or OAM that are receiving or expect to receive MBS service or session under the AN function or a cell of the AN function, information of a delivery mode for specified service (Xu, para. 0097, A manner used by the access network side to send the multicast service is sending the multicast service in only a unicast manner, in only a multicast manner, or in the unicast manner and the multicast manner. Optionally, the access network side device notifies the terminal side device of a receiving manner used for the multicast service, and the terminal side device receives the multicast service based on the receiving manner) or application (Xu, para. 0092, internet protocol (IP) address, i.e. a internet protocol being an application) or session (Xu, para. 0092, the start message indicates an interne protocol (IP) address of the multicast service and a cell for sending the multicast service, i.e. sending the service is a session) or QoS flow (Xu, para. 0092, the start message indicates an interne protocol (IP) address of the multicast service and a cell for sending the multicast service; Para. 0117, all data packets of the multicast service are corresponding to at least one quality of service (QoS) flow); UE capability information for delivery mode (Xu, para. 0098-0099, C-RNTI, G-RNTI, i.e. UE is capable for receiving unicast/multicast); or suggested information of the delivery mode used by the AN under specified performance of AN (Xu, para. 0097, A manner (i.e. delivery mode) used by the access network side to send the multicast service (i.e. a specified performance of AN) is sending the multicast service in only a unicast manner, in only a multicast manner, or in the unicast manner and the multicast manner. Optionally, the access network side device notifies (i.e. suggested information) the terminal side device of a receiving manner used for the multicast service, and the terminal side device receives the multicast service based on the receiving manner.). In addition, as the primary reference is used to teach the instant claim limitations, see the suggestion/motivation of claim 8.
As to claim 30, Xu and HAN further discloses the access network (AN) function, including a processor, and a memory storing a processor-executable program that, when executed by the processor, causes the processor to perform steps of the method for determining a delivery mode of claim 1 (Xu, para. 0201-0202, the communications device 1800 may be the access network side device in the foregoing first embodiment, second embodiment, or third embodiment or a chip system used for the access network side device. In this case, the communications device 1800 includes a processing unit 1802 and a transceiver unit 1801. The processing unit 1802 is configured to perform processing actions such as determining of the access network side device in any one of the foregoing first embodiment, second embodiment, and third embodiment; the communications device 1800 includes a processor and a memory, the memory stores a computer program, and when the computer program is invoked by the processor, the communications device may be enabled to perform actions performed by the terminal side device or the access network side device in the foregoing method embodiments). In addition, as the primary reference is used to teach the instant claim limitations, see the suggestion/motivation of claim 1.
Claim(s) 10-11, 13-14, 31 is/are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Publication No. 2022/0217506 A1 to XU et al. (“Xu”) in view of n view of EP 2978245 A1 to HAN and in further view of U.S. Publication No. 2023/0345310 A1 to LI et al. (“Li”).
As to claim 10, Xu and HAN does not expressly disclose the method of claim 9, wherein the MBS policy is determined by a policy control function (PCF) based on MBS service parameters provided by an application function (AF) and is provided to the CN function.
Li discloses at para. 0274, notification control may be used for a GBR QoS Flow if the application traffic is able to adapt to the change in the QoS (e.g. if the AF 210 is capable to trigger rate adaptation). Upon receiving a notification from the NG-RAN that the GFBR can no longer be guaranteed, the AMF 203/SMF 204 may forward the notification to the PCF (e.g., UDM/PCF 206)… The evolved notification control parameter or the new Delivery Mode control parameter may be used by the core network (e.g., a network server or other entity) to indicate whether notifications are requested from the NG-RAN when QoS requirement can no longer be met using the currently configured delivery mode, or to request delivery mode switch from MBMS user service (Multicast/Broadcast) to Unicast service, or to request delivery mode switch from unicast service to MBMS user service (Multicast/Broadcast).
Prior to the effective filing date of invention, it would have been obvious to a person of ordinary skill in the art to incorporate the notification as taught by Li into the invention of Xu and HAN. The suggestion/motivation would have been to provide switching between at least two unicast messaging, multicast messaging, and broadcast messaging to a user device over a 5G network (Li, para. 0006). Including the notification as taught by Li into the invention of Xu and HAN was within the ordinary ability of one of ordinary skill in the art based on the teachings of Li.
As to claim 11, Xu and HAN does not expressly disclose the method of claim 8, wherein the determining MBS assistance information comprises: subscribing to or requesting analytics information of a network from a network data analytics function (NWDAF), and receiving the analytics information sent by the NWDAF; and determining the MBS assistance information according to the analytics information.
Li discloses at para. 0218 third, the network functions such as MB-SMF 208, MB-UPF 209, AMF 203, or NWDAF finds or predicts that the data transfer performance within core network cannot meet requirement, or that UE 201 moves out of MBS session service area. In addition, if there is only one remaining UE receiving the multicast traffic, the network may switch the UE 201 to using unicast session for better mobility handling of the traffic in case the UE 201 moves, i.e. core network detects UE movement (i.e. assistance information) from NWDAF. [para. 0134, core network function…network functions…NWDAF, i.e. NWDAF is a core network function, hence core network is subscribed to it].
Prior to the effective filing date of invention, it would have been obvious to a person of ordinary skill in the art to incorporate the NWDAF as taught by Li into the invention of Xu and HAN. The suggestion/motivation would have been to provide switching between at least two unicast messaging, multicast messaging, and broadcast messaging to a user device over a 5G network (Li, para. 0006). Including the NWDAF as taught by Li into the invention of Xu and HAN was within the ordinary ability of one of ordinary skill in the art based on the teachings of Li.
As to claim 13, Xu and HAN does not expressly disclose method of claim 11, wherein the analytics information comprises one or more of the following types: service experience; network performance; user data congestion; quality of service (QoS) sustainability; or network function (NF) load.
Li discloses NWDAF finds or predicts that the data transfer performance within core network cannot meet requirement, or that UE 201 moves out of MBS session service area. In addition, if there is only one remaining UE receiving the multicast traffic, the network may switch the UE 201 to using unicast session for better mobility handling of the traffic in case the UE 201 moves, i.e. movement of UE outside area is a service experience (less UEs to service), network performance (need to swtich to unicast), and NF load (less UEs to service) (para. 0218).
Prior to the effective filing date of invention, it would have been obvious to a person of ordinary skill in the art to incorporate the NWDAF as taught by Li into the invention of Xu and HAN. The suggestion/motivation would have been to provide switching between at least two unicast messaging, multicast messaging, and broadcast messaging to a user device over a 5G network (Li, para. 0006). Including the NWDAF as taught by Li into the invention of Xu and HAN was within the ordinary ability of one of ordinary skill in the art based on the teachings of Li.
As to claim 14, Xu and HAN does not expressly disclose the method of claim 11, wherein the determining the MBS assistance information according to the analytics information, comprises: in case that the CN function is an application function (AF), updating, by the AF, MBS service parameters according to the analytics information, and sending the updated MBS service parameters to a policy control function (PCF); or in case that the CN function is a policy control function (PCF), updating, by the PCF, MBS policies according to the analytics information and/or the updated MBS service parameters, and sending the updated MBS policies to a session management function (SMF); or in case that the CN equipment is the SMF, determining, by the SMF, the MBS assistance information based on one or more of the following parameters: the analytics information; the updated MBS policies; UE subscription data related to MBS services, which is obtained by the SMF from the unified data management (UDM); or information sent by the UE to the SMF through non-access stratum (NAS) signaling.
Li discloses FIG. 3 illustrates an exemplary NAS transport for SM, SMS, UE Policy, or LCS. It is worth noting that the mobility management and session management functions are separated. A single N1 NAS connection is used for both Registration Management and Connection Management (RM/CM) and for SM-related messages and procedures for a UE. The single N1 termination point is located in the AMF. The AMF forwards SM related NAS information to the SMF. AMF handles the Registration Management and Connection Management of NAS signaling exchanged with the UE, while SMF handles the Session management of NAS signaling exchanged with the UE (para. 0087); para. 0137, the UE sends a NAS message to the AMF requesting to switch to the multicast transmission mode (e.g., a control plane method as shown in FIG. 7A-FIG. 7B), i.e. or in case that the CN equipment is the SMF, determining, by the SMF, the MBS assistance information based on one or more of the following parameters… information sent by the UE to the SMF through non-access stratum (NAS) signaling.
Prior to the effective filing date of invention, it would have been obvious to a person of ordinary skill in the art to incorporate the SMF as taught by Li into the invention of Xu and HAN. The suggestion/motivation would have been to provide switching between at least two unicast messaging, multicast messaging, and broadcast messaging to a user device over a 5G network (Li, para. 0006). Including the SMF as taught by Li into the invention of Xu and HAN was within the ordinary ability of one of ordinary skill in the art based on the teachings of Li.
Examiner notes that the instant claim recites contingent limitations using the terms “in case” that do not need to be given patentable weight. However, in the interest of Compact Prosecution, Examiner cited to prior art to teach the contingent limitation(s). See MPEP 2111.04 for details.
As to claim 31, Xu and HAN does not expressly disclose the core network (CN) function or an operation, administration and maintenance (OAM) platform, including a processor, and a memory storing a processor-executable program that, when executed by the processor, causes the processor to perform steps of the method for determining a delivery mode of claim 8.
Li discloses the Core Network…comprise a computer or server and may be controlled primarily by computer readable instructions, which may be in the form of software, wherever, or by whatever means such software is stored or accessed. Such computer readable instructions may be executed within a processor 91, to cause computing system 90 to do work (para. 0076).
Prior to the effective filing date of invention, it would have been obvious to a person of ordinary skill in the art to incorporate the Core Network as taught by Li into the invention of Xu and HAN. The suggestion/motivation would have been to provide switching between at least two unicast messaging, multicast messaging, and broadcast messaging to a user device over a 5G network (Li, para. 0006). Including the Core Network as taught by Li into the invention of Xu and HAN was within the ordinary ability of one of ordinary skill in the art based on the teachings of Li.
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 OMAR J GHOWRWAL whose telephone number is (571)270-5691. The examiner can normally be reached M-F 9:00am-6:00pm.
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, ASAD NAWAZ can be reached at 571-272-3988. 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.
/OMAR J GHOWRWAL/Primary Examiner, Art Unit 2463
Prosecution Insights