DETAILED ACTION
This communication is response to the application filed 01/23/2024. Claims 1-5, 10-12, 14-19, 23-27, and 32 are pending and presented for examination. A preliminary amendment submitted on 01/23/2024 is acknowledged and entered.
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 .
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 01/23/2024, 01/24/2025, and 07/16/2025 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Regarding claim 32, the claim is rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claim recites “computer-readable storage medium”, and while the applicant’s disclosure recites examples of computer-readable storage medium, however, it does not limit the storage medium to the examples. In other words, the definition of storage medium in applicant’s disclosure does not exclude signal as being an example of medium (see Applicant Publication, ¶ 0498: including but not limited to disk storage, optical storage, and the like) and therefore, claimed medium is directed to a non-statutory subject matter.
A claim drawn to such a computer readable storage medium that covers both transitory and non-transitory embodiments may be amended to narrow the claim to cover only statutory embodiments to avoid a rejection under 35 U.S.C. 101 by adding the limitation “A non-transitory” to the claim.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1, 2, 4, 5, 10-12, 14-19, 23-27, and 32 is/are rejected under 35 U.S.C. 102(a) as being anticipated by US 2020/0092923 to Abraham et al. (hereafter Abraham).
Regarding claim 1, Abraham discloses a method for processing a multicast broadcast session, applied to a first access and mobility management function (AMF) (see Abraham, Fig 5A, AMF 210-b), comprising:
receiving a first request transmitted from a user equipment (UE), wherein the first request is a registration request message or a service request message (see Abraham, Fig 5A, step 510, Registration and Service Request; ¶ 0121: at 510 the UE 115-j transmit a registration and service request to the (R)AN 205-e, which may share information provided in the request with the AMF 210-b);
obtaining multicast broadcast session information of the UE based on the first request, wherein the multicast broadcast session information is used to indicate that the UE remains joined in, leaves, or requests to join a first multicast broadcast session (see Abraham, ¶ 0122: the UE 115-j may transmit an M-PDU session establishment request to the AMF 210-b. For example, the UE 115-j may request to join a particular M-PDU session), and the first multicast broadcast session is a multicast broadcast session that the UE has joined or a multicast broadcast session that the UE requests to join (see Abraham, ¶ 0122: the UE 115-j may request to join a particular M-PDU session, which may be identified based on a M-PDU session identifier (e.g., provided by the UE 115-j)); and
performing a processing operation related to a multicast broadcast session based on the multicast broadcast session information (see Abraham, ¶ 0122-¶ 0123).
Regarding claim 2, Abraham discloses the method of claim 1, wherein the obtaining the multicast broadcast session information of the UE based on the first request comprises: in case that the first request carries the multicast broadcast session information of the UE, obtaining the multicast broadcast session information of the UE from the first request (see Abraham, ¶ 0122: the UE 115-j may request to join a particular M-PDU session, which may be identified based on a M-PDU session identifier (e.g., provided by the UE 115-j). At 525, the AMF 210-b may select the M-SMF 220-b. For example, the AMF 210-b may select the M-SMF 220-b using the M-PDU session identifier provided by the UE 115-j. At 530-a, the AMF 210-b may transmit to the M-SMF 220-b a message (e.g., Namf_PDUSession_CreateSMContextRequest) requesting that the UE 115-j join the identified M-PDU session; ¶ 0123: the M-SMF 220-b may retrieve registration information and subscription information associated with the UE 115-j, and determine whether the UE 115-j can join the identified M-PDU session offered by the data network 230-g. Based on the determination, at 530-b the M-SMF 220-b may transmit a response message (e.g., Namf PDUSession CreateSMContextResponse) to the AMF 210-b indicating that the UE 115-j is allowed to join the identified M-PDU session).
Regarding claim 4, Abraham discloses the method of claim 1, wherein the multicast broadcast session information comprises at least one of the following identifier (ID) information:
a first multicast broadcast service (MBS) session ID; an ID of a protocol data unit (PDU) session associated with the first multicast broadcast session; or an ID of the MB-SMF and/or an ID of the SMF serving the first multicast broadcast session (see Abraham, ¶ 0035: the identifier for the multicast service session comprises an M-PDU session identifier; ¶ 0097: An M-PDU session identifier related to a specific multicast session may be assigned by an M-SMF such as the M-SMF 220. In some cases, one M-SMF may be used for a multicast session. The M-PDU session identifier may be a combination of an M-SMF identifier and a multicast stream identifier generated by an M-SMF, such as the M-SMF 220);
wherein the multicast broadcast session information further comprises indication information, wherein the indication information is used to indicate that the UE remains joined in, leaves, or requests to join a first multicast broadcast session (see Abraham, ¶ 0098: The M-SMF 220 may record a UE-specific identifier associated with the UE 115-a that joins an M-PDU session with a M-PDU session identifier; ¶ 0122: the AMF 210-b may select the M-SMF 220-b using the M-PDU session identifier provided by the UE 115-j. At 530-a, the AMF 210-b may transmit to the M-SMF 220-b a message (e.g., Namf_PDUSession_CreateSMContextRequest) requesting that the UE 115-j join the identified M-PDU session; ¶ 0123: the M-SMF 220-b may transmit a response message (e.g., Namf PDUSession CreateSMContextResponse) to the AMF 210-b indicating that the UE 115-j is allowed to join the identified M-PDU session; ¶ 0126: the M-SMF 220-b may transmit an N4 request to the M-UPF 215-c, which may create or modify an N4 session towards the M-UPF 215-c (or a secondary multicast-user plane function) of the UE 115-j that has joined a multicast service area).
Regarding claim 5, Abraham discloses the method of claim 1, wherein the performing the processing operation related to the multicast broadcast session based on the multicast broadcast session information comprises:
determining a first network function entity serving the first multicast broadcast session, wherein the first network function entity comprises a session management function (SMF) or a multicast broadcast session management function (MB-SMF) (see Abraham, Fig 5A; ¶ 0121-¶ 0123);
transmitting a second request to the first network function entity, wherein the second request carries the multicast broadcast session information (see Abraham, Fig 5A; ¶ 0121-¶ 0123); and
receiving a response message to the second request transmitted from the first network function entity (see Abraham, Fig 5A; ¶ 0121-¶ 0123),
wherein the response message to the second request carries at least one of the following information: information about acknowledging that the UE joins or leaves the first multicast broadcast session; information about accepting the UE to join the first multicast broadcast session; information about indicating the UE to leave the first multicast broadcast session; or, information about rejecting the UE to join the first multicast broadcast session (see Abraham, Fig 5A; ¶ 0121-¶ 0123).
Regarding claim 10, Abraham discloses a method for processing a multicast broadcast session, applied to a session management function (SMF) (see Abraham, Fig 5s, M-SMF 220-b), comprising:
receiving a second request transmitted from a first access and mobility management function (AMF) during a registration procedure or a service request procedure of a user equipment (UE) (see Abraham, Fig 5A, step 510, Registration and Service Request; ¶ 0121: at 510 the UE 115-j transmit a registration and service request to the (R)AN 205-e, which may share information provided in the request with the AMF 210-b), wherein the second request carries multicast broadcast session information of the UE, the multicast broadcast session information is used to indicate that the UE remains joined in, leaves, or requests to join a first multicast broadcast session, and the first multicast broadcast session is a multicast broadcast session that the UE has joined or a multicast broadcast session that the UE requests to join (see Abraham, ¶ 0122: the UE 115-j may transmit an M-PDU session establishment request to the AMF 210-b. For example, the UE 115-j may request to join a particular M-PDU session), and the first multicast broadcast session is a multicast broadcast session that the UE has joined or a multicast broadcast session that the UE requests to join (see Abraham, ¶ 0122: the UE 115-j may request to join a particular M-PDU session, which may be identified based on a M-PDU session identifier (e.g., provided by the UE 115-j); ¶ 0123: the M-SMF 220-b may retrieve registration information and subscription information associated with the UE 115-j, and determine whether the UE 115-j can join the identified M-PDU session offered by the data network 230-g. Based on the determination, at 530-b the M-SMF 220-b may transmit a response message (e.g., Namf PDUSession CreateSMContextResponse) to the AMF 210-b indicating that the UE 115-j is allowed to join the identified M-PDU session); and
processing a multicast broadcast session of the UE based on the multicast broadcast session information carried by the second request (see Abraham, ¶ 0122-¶ 0123).
Regarding claim 11, Abraham discloses the method of claim 10, wherein the multicast broadcast session information comprises at least one of the following identifier (ID) information: a first multicast broadcast service (MBS) session ID; or an ID of a protocol data unit (PDU) session associated with the first multicast broadcast session (see Abraham, ¶ 0035: the identifier for the multicast service session comprises an M-PDU session identifier; ¶ 0097: An M-PDU session identifier related to a specific multicast session may be assigned by an M-SMF such as the M-SMF 220. In some cases, one M-SMF may be used for a multicast session. The M-PDU session identifier may be a combination of an M-SMF identifier and a multicast stream identifier generated by an M-SMF, such as the M-SMF 220); and
wherein the multicast broadcast session information further comprises indication information, wherein the indication information is used to indicate that the UE remains joined in, leaves, or requests to join a first multicast broadcast session (see Abraham, ¶ 0098: The M-SMF 220 may record a UE-specific identifier associated with the UE 115-a that joins an M-PDU session with a M-PDU session identifier; ¶ 0122: the AMF 210-b may select the M-SMF 220-b using the M-PDU session identifier provided by the UE 115-j. At 530-a, the AMF 210-b may transmit to the M-SMF 220-b a message (e.g., Namf_PDUSession_CreateSMContextRequest) requesting that the UE 115-j join the identified M-PDU session; ¶ 0123: the M-SMF 220-b may transmit a response message (e.g., Namf PDUSession CreateSMContextResponse) to the AMF 210-b indicating that the UE 115-j is allowed to join the identified M-PDU session; ¶ 0126: the M-SMF 220-b may transmit an N4 request to the M-UPF 215-c, which may create or modify an N4 session towards the M-UPF 215-c (or a secondary multicast-user plane function) of the UE 115-j that has joined a multicast service area).
Regarding claim 11, Abraham discloses the method of claim 10, wherein the multicast broadcast session information comprises at least one of the following identifier (ID) information: a first multicast broadcast service (MBS) session ID; or an ID of a protocol data unit (PDU) session associated with the first multicast broadcast session (see Abraham, ¶ 0035: the identifier for the multicast service session comprises an M-PDU session identifier; ¶ 0097: An M-PDU session identifier related to a specific multicast session may be assigned by an M-SMF such as the M-SMF 220. In some cases, one M-SMF may be used for a multicast session. The M-PDU session identifier may be a combination of an M-SMF identifier and a multicast stream identifier generated by an M-SMF, such as the M-SMF 220); and
wherein the multicast broadcast session information further comprises indication information, wherein the indication information is used to indicate that the UE remains joined in, leaves, or requests to join a first multicast broadcast session (see Abraham, ¶ 0098: The M-SMF 220 may record a UE-specific identifier associated with the UE 115-a that joins an M-PDU session with a M-PDU session identifier; ¶ 0122: the AMF 210-b may select the M-SMF 220-b using the M-PDU session identifier provided by the UE 115-j. At 530-a, the AMF 210-b may transmit to the M-SMF 220-b a message (e.g., Namf_PDUSession_CreateSMContextRequest) requesting that the UE 115-j join the identified M-PDU session; ¶ 0123: the M-SMF 220-b may transmit a response message (e.g., Namf PDUSession CreateSMContextResponse) to the AMF 210-b indicating that the UE 115-j is allowed to join the identified M-PDU session; ¶ 0126: the M-SMF 220-b may transmit an N4 request to the M-UPF 215-c, which may create or modify an N4 session towards the M-UPF 215-c (or a secondary multicast-user plane function) of the UE 115-j that has joined a multicast service area).
Regarding claim 12, Abraham discloses the method of claim 10, wherein the processing the multicast broadcast session of the UE based on the multicast broadcast session information carried by the second request comprises:
in case that the multicast broadcast session information is used to indicate that the UE remains joined in the first multicast broadcast session, transmitting a response message to the second request to the first AMF, wherein the response message to the second request carries information about acknowledging that the UE joins in the first multicast broadcast session; or,
in case that the multicast broadcast session information is used to indicate that the UE leaves the first multicast broadcast session, transmitting a response message to the second request to the first AMF, wherein the response message to the second request carries information about acknowledging that the UE leaves the first multicast broadcast session; or,
in case that the multicast broadcast session information is used to indicate that the UE requests to join the first multicast broadcast session and it is determined to accept the UE to join the first multicast broadcast session, establishing a corresponding relationship between an ID of the UE and the first MBS session ID, and transmitting a response message to the second request to the first AMF, wherein the response message to the second request carries information about accepting the UE to join the first multicast broadcast session (see Abraham, ¶ 0123: determine whether the UE 115-j can join the identified M-PDU session offered by the data network 230-g. Based on the determination, at 530-b the M-SMF 220-b may transmit a response message (e.g., Namf PDUSession CreateSMContextResponse) to the AMF 210-b indicating that the UE 115-j is allowed to join the identified M-PDU session); or,
in case that the multicast broadcast session information is used to indicate that the UE requests to join the first multicast broadcast session and the UE is not within a service area of the first multicast broadcast session, transmitting a response message to the second request to the first AMF, wherein the response message to the second request carries information about rejecting the UE to join the first multicast broadcast session (see Abraham, ¶ 0114: The M-SMF 220 may additionally or alternatively ignore or reject requests from UEs to join the multicast service session when the UEs are out of the multicast service area. In some cases, if the UE 115-a moves out of a multicast service area, the M-SMF 220 may terminate the multicast session to the UE 115-a, and inform the M-UPF 215 that may additionally or alternatively terminate a respective N3 tunnel to the UE 115-a); or,
in case that the multicast broadcast session information is used to indicate that the UE remains joined in the first multicast broadcast session and the UE is not within a service area of the first multicast broadcast session, transmitting a response message to the second request to the first AMF, wherein the response message to the second request carries information about indicating the UE to leave the first multicast broadcast session; or,
in case that the multicast broadcast session information is used to indicate that the UE leaves the first multicast broadcast session, deleting a corresponding relationship between an ID of the UE and the first MBS session ID.
Regarding claim 14, it is rejected for the same reasons as set forth in claim 1. Applicant is merely claiming the transmitting side of the invention.
Regarding claim 15, it is rejected for the same reasons as set forth in claim 4.
Regarding claim 16, Abraham discloses the method of claim 14, wherein the processing the first multicast broadcast session based on the response message to the first request comprises:
in case that the response message to the first request carries information about accepting the UE to join the first multicast broadcast session, storing first multicast broadcast session context; or,
in case that the response message to the first request carries information about rejecting the UE to join the first multicast broadcast session or information about indicating the UE to leave the first multicast broadcast session, deleting first multicast broadcast session context (see Abraham, ¶ 0114: The M-SMF 220 may additionally or alternatively ignore or reject requests from UEs to join the multicast service session when the UEs are out of the multicast service area. In some cases, if the UE 115-a moves out of a multicast service area, the M-SMF 220 may terminate the multicast session to the UE 115-a, and inform the M-UPF 215 that may additionally or alternatively terminate a respective N3 tunnel to the UE 115-a; ¶ 0123: determine whether the UE 115-j can join the identified M-PDU session offered by the data network 230-g. Based on the determination, at 530-b the M-SMF 220-b may transmit a response message (e.g., Namf PDUSession CreateSMContextResponse) to the AMF 210-b indicating that the UE 115-j is allowed to join the identified M-PDU session).
Regarding claim 17, Abraham discloses the method of claim 14, wherein the receiving the response message to the first request transmitted from the first AMF comprises:
receiving the response message to the first request transmitted from the first AMF and forwarded by a radio access network function entity; wherein the method further comprises: in case that the response message to the first request carries information about accepting the UE to join the first multicast broadcast session, establishing or updating a resource for the first multicast broadcast session (see Abraham, ¶ 0109: resources may be assigned at a time that a UE (e.g., the UE 115-h and/or the UE 115-i) requests access to a multicast application; ¶ 0123: the AMF 210-b may select the M-SMF 220-b. For example, the AMF 210-b may select the M-SMF 220-b using the M-PDU session identifier provided by the UE 115-j. At 530-a, the AMF 210-b may transmit to the M-SMF 220-b a message (e.g., Namf_PDUSession_CreateSMContextRequest) requesting that the UE 115-j join the identified M-PDU session); and
receiving service data of the first multicast broadcast session by using the resource (see Abraham, ¶ 0050: The UE may receive, from a base station wirelessly communicating with the UE, an indication of one or more of an activation of the at least one multicast quality of service flow or communication resources for the UE to use to receive multicast packets of the multicast service session from a content provider via a tunnel between the network node and the base station, the tunnel established for the multicast service session in response to the transmitted request from the UE based on identifying that the multicast service session lacks an existing tunnel between the first network node and the base station the tunnel).
Regarding claim 18, Abraham discloses the method of claim 17, wherein the receiving the service data of the first multicast broadcast session by using the resource comprises: in case that a radio access network function entity does not support multicast broadcast service, receiving the service data of the first multicast broadcast session in a unicast manner by using the resource; or, in case that a radio access network function entity supports multicast broadcast service, receiving the service data of the first multicast broadcast session in a multicast broadcast manner by using the resource (see Abraham, ¶ 0104: In some cases, the (R)AN 205 may map the QoS flow in the multicast service session to either a multicast radio bearer or one or more unicast radio bearers. As such, the (R)AN 205 may determine to switch from multicast to unicast radio bearers based on a number of UEs that are subscribed to the multicast service session and radio conditions. For example, if the (R)AN 205 is servicing the UE 115-a, it may establish and use a unicast radio bearer; ¶ 0117: valuable resources are prevented from being wasted by a (R)AN when no UEs are available to receive multicast traffic. Further, UEs may be in a connected mode for reception of the multicast traffic, thereby avoiding situations when the (R)AN may waste valuable resources (e.g., bandwidth, power). The techniques described herein may allow (R)ANs to switch between unicast and multicast to improve efficiency and reliability when servicing either a single UE or multiple UEs).
Regarding claim 19, it is rejected for the same reasons as set forth in claim 1. Although phrased as an apparatus claim, the claim is nevertheless simple repetitions of the subject matter of claim 1.
Vesely further discloses wherein the memory is used for storing a computer program; the transceiver is used for transmitting and receiving data under a control of the processor; and the processor is used for reading the computer program stored in the memory and performing the method of claim 1 (see Abraham, Fig 14).
Regarding claim 23, it is rejected for the same reasons as set forth in claim 10. Although phrased as an apparatus claim, the claim is nevertheless simple repetitions of the subject matter of claim 10.
Regarding claim 24, it is rejected for the same reasons as set forth in claim 14. Although phrased as an apparatus claim, the claim is nevertheless simple repetitions of the subject matter of claim 14.
Regarding claim 25, it is rejected for the same reasons as set forth in claim 15. Although phrased as an apparatus claim, the claim is nevertheless simple repetitions of the subject matter of claim 15.
Regarding claim 26, it is rejected for the same reasons as set forth in claim 16. Although phrased as an apparatus claim, the claim is nevertheless simple repetitions of the subject matter of claim 16.
Regarding claim 27, it is rejected for the same reasons as set forth in claims 17 and 18. Although phrased as an apparatus claim, the claim is nevertheless simple repetitions of the subject matter of claims 17 and 18.
Regarding claim 32, it is rejected for the same reasons as set forth in claim 14. Although phrased as a computer-readable storage medium claim, the claim is nevertheless simple repetitions of the subject matter of claim 14.
(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.
Claim(s) 1, 2, 4, 5, 10-12, 14-19, 23-27, and 32 is/are rejected under 35 U.S.C. 102(a)(2) as being anticipated by US 2023/0096763 to Vesely et al. (hereafter Vesely).
Regarding claim 1, Vesely discloses a method for processing a multicast broadcast session, applied to a first access and mobility management function (AMF) (see Vesely, Fig 8, AMF 110; ¶ 0006: a method performed by an Access and Mobility Management Function (AMF) for a MB session join procedure), comprising:
receiving a first request transmitted from a user equipment (UE) (see Vesely, ¶ 0006: a method performed by an Access and Mobility Management Function (AMF) for a MB session join procedure comprises receiving a MB session join request from a User Equipment (UE) via a RAN node, the MB session join request being a request to join a particular MB session; ¶ 0111: The UE 108 indicates its interest to Join an MBS Session by an UL NAS Message MB Session Join (MB Session ID, e.g. TMGI) or, alternatively, an UL NAS MB Service Request (MB Session ID, e.g. TMGI). The NG-RAN node 106 forwards the NAS message to the AMF 110), wherein the first request is a registration request message or a service request message (see Vesely, ¶ 0023 and ¶ 0026: receiving an MBS service request from a UE via a RAN node responsive to performing the group paging; ¶ 0111: The UE 108 indicates its interest to Join an MBS Session by an UL NAS Message MB Session Join (MB Session ID, e.g. TMGI) or, alternatively, an UL NAS MB Service Request (MB Session ID, e.g. TMGI). The NG-RAN node 106 forwards the NAS message to the AMF 110; ¶ 0128: A UE 108 interested in the MB Session sends an MBS Service Request to the AMF 110. Optionally, this may include MBS Session Join. The MBS Service Request includes the TMGI or other reference to the MB Session that triggered paging);
obtaining multicast broadcast session information of the UE based on the first request (see Vesely, ¶ 0007: the MB session join request comprises a MB session identity (ID) of the particular MB session), wherein the multicast broadcast session information is used to indicate that the UE remains joined in, leaves, or requests to join a first multicast broadcast session, and the first multicast broadcast session is a multicast broadcast session that the UE has joined or a multicast broadcast session that the UE requests to join (see Vesely, ¶ 0006: receiving a MB session join request from a User Equipment (UE) via a RAN node, the MB session join request being a request to join a particular MB session. The method further comprises determining that the MB session join request is permitted by a subscription of the UE; ¶ 0111: The UE 108 indicates its interest to Join an MBS Session by an UL NAS Message MB Session Join (MB Session ID, e.g. TMGI) or, alternatively, an UL NAS MB Service Request (MB Session ID, e.g. TMGI). The NG-RAN node 106 forwards the NAS message to the AMF 110; ¶ 0128: A UE 108 interested in the MB Session sends an MBS Service Request to the AMF 110. Optionally, this may include MBS Session Join. The MBS Service Request includes the TMGI or other reference to the MB Session that triggered paging); and
performing a processing operation related to a multicast broadcast session based on the multicast broadcast session information (see Vesely, ¶ 0006: determining that the MB session join request is permitted by a subscription of the UE, selecting a MB Session Management Function (MB-SMF) based on information comprised in the MB session join request, communicating with the MB-SMF to create a MB session context in the AMF and an MB session context in the MB-SMF, and sending a MB session join accept message to the UE; ¶ 0104: The AMF 110 that serves UEs 108 for non-MBS services is capable of processing MBS specific UE context data and discovering the MB-SMF 118 with the MBS Session Context).
Regarding claim 2, Vesely discloses the method of claim 1, wherein the obtaining the multicast broadcast session information of the UE based on the first request comprises: in case that the first request carries the multicast broadcast session information of the UE, obtaining the multicast broadcast session information of the UE from the first request (see Vesely, ¶ 0007: the MB join request comprises a MB session identity (ID) of the particular MB session).
Regarding claim 4, Vesely discloses the method of claim 1, wherein the multicast broadcast session information comprises at least one of the following identifier (ID) information: a first multicast broadcast service (MBS) session ID; an ID of a protocol data unit (PDU) session associated with the first multicast broadcast session; or an ID of the MB-SMF and/or an ID of the SMF serving the first multicast broadcast session (see Vesely, ¶ 0006: selecting a MB Session Management Function (MB-SMF) based on information comprised in the MB session join request, communicating with the MB-SMF to create a MB session context in the AMF and an MB session context in the MB-SMF, and sending a MB session join accept message to the UE; ¶ 0016: receiving, from the AMF, a UE ID of the UE and a MB session ID of the particular MB session, determining whether the UE is authorized to join the particular MB session based on the UE ID and the MB session ID, and sending a response to the AMF that indicates whether the UE is authorized to join the particular MB session);
wherein the multicast broadcast session information further comprises indication information, wherein the indication information is used to indicate that the UE remains joined in, leaves, or requests to join a first multicast broadcast session (see Vesely, ¶ 0008: storing an identifier of the particular MB session, as a joined MB session, to a UE context of the UE stored at the AMF; ¶ 0032: a MB session leave procedure comprises receiving a MB session release message from an AMF, the MB session release message being for a particular UE for a particular MB session).
Regarding claim 5, Vesely discloses the method of claim 1, wherein the performing the processing operation related to the multicast broadcast session based on the multicast broadcast session information comprises:
determining a first network function entity serving the first multicast broadcast session, wherein the first network function entity comprises a session management function (SMF) or a multicast broadcast session management function (MB-SMF) (see Vesely, ¶ 0006: selecting a MB Session Management Function (MB-SMF) based on information comprised in the MB session join request, communicating with the MB-SMF to create a MB session context in the AMF and an MB session context in the MB-SMF);
transmitting a second request to the first network function entity, wherein the second request carries the multicast broadcast session information (see Vesely, ¶ 0006: communicating with the MB-SMF to create a MB session context in the AMF and an MB session context in the MB-SMF, and sending a MB session join accept message to the UE; ¶ 0015: a method performed by a MB-SMF for a MB session join procedure comprises communicating with an AMF to create a MB session context in the MB-SMF during a join procedure in which a UE joins a particular MB session, the MB session context comprising information that indicates the AMF; ¶ 0028); and
receiving a response message to the second request transmitted from the first network function entity (see Vesely, ¶ 0006: sending a MB session join accept message to the UE; ¶ 0028),
wherein the response message to the second request carries at least one of the following information: information about acknowledging that the UE joins or leaves the first multicast broadcast session; information about accepting the UE to join the first multicast broadcast session; information about indicating the UE to leave the first multicast broadcast session; or, information about rejecting the UE to join the first multicast broadcast session (see Vesely, ¶ 0006: determining that the MB session join request is permitted by a subscription of the UE, selecting a MB Session Management Function (MB-SMF) based on information comprised in the MB session join request……..sending a MB session join accept message to the UE; ¶ 0141).
Regarding claim 10, Vesely discloses a method for processing a multicast broadcast session, applied to a session management function (SMF) (see Vesely, Fig 8, MB-SMF 118), comprising:
receiving a second request transmitted from a first access and mobility management function (AMF) during a registration procedure or a service request procedure of a user equipment (UE) (see Vesely, ¶ 0006: a method performed by an Access and Mobility Management Function (AMF) for a MB session join procedure comprises receiving a MB session join request from a User Equipment (UE) via a RAN node, the MB session join request being a request to join a particular MB session; ¶ 0111: The UE 108 indicates its interest to Join an MBS Session by an UL NAS Message MB Session Join (MB Session ID, e.g. TMGI) or, alternatively, an UL NAS MB Service Request (MB Session ID, e.g. TMGI). The NG-RAN node 106 forwards the NAS message to the AMF 110; ¶ 0023 and ¶ 0026: receiving an MBS service request from a UE via a RAN node responsive to performing the group paging; ¶ 0111: The UE 108 indicates its interest to Join an MBS Session by an UL NAS Message MB Session Join (MB Session ID, e.g. TMGI) or, alternatively, an UL NAS MB Service Request (MB Session ID, e.g. TMGI). The NG-RAN node 106 forwards the NAS message to the AMF 110; ¶ 0128: A UE 108 interested in the MB Session sends an MBS Service Request to the AMF 110. Optionally, this may include MBS Session Join. The MBS Service Request includes the TMGI or other reference to the MB Session that triggered paging), wherein the second request carries multicast broadcast session information of the UE, the multicast broadcast session information is used to indicate that the UE remains joined in, leaves, or requests to join a first multicast broadcast session, and the first multicast broadcast session is a multicast broadcast session that the UE has joined or a multicast broadcast session that the UE requests to join (see Vesely, ¶ 0006: receiving a MB session join request from a User Equipment (UE) via a RAN node, the MB session join request being a request to join a particular MB session. The method further comprises determining that the MB session join request is permitted by a subscription of the UE; ¶ 0111: The UE 108 indicates its interest to Join an MBS Session by an UL NAS Message MB Session Join (MB Session ID, e.g. TMGI) or, alternatively, an UL NAS MB Service Request (MB Session ID, e.g. TMGI). The NG-RAN node 106 forwards the NAS message to the AMF 110; ¶ 0128: A UE 108 interested in the MB Session sends an MBS Service Request to the AMF 110. Optionally, this may include MBS Session Join. The MBS Service Request includes the TMGI or other reference to the MB Session that triggered paging); and
processing a multicast broadcast session of the UE based on the multicast broadcast session information carried by the second request (see Vesely, ¶ 0006: determining that the MB session join request is permitted by a subscription of the UE, selecting a MB Session Management Function (MB-SMF) based on information comprised in the MB session join request, communicating with the MB-SMF to create a MB session context in the AMF and an MB session context in the MB-SMF, and sending a MB session join accept message to the UE; ¶ 0104: The AMF 110 that serves UEs 108 for non-MBS services is capable of processing MBS specific UE context data and discovering the MB-SMF 118 with the MBS Session Context).
Regarding claim 11, Vesely discloses the method of claim 10, wherein the multicast broadcast session information comprises at least one of the following identifier (ID) information: a first multicast broadcast service (MBS) session ID; or an ID of a protocol data unit (PDU) session associated with the first multicast broadcast session (see Vesely, ¶ 0006: selecting a MB Session Management Function (MB-SMF) based on information comprised in the MB session join request, communicating with the MB-SMF to create a MB session context in the AMF and an MB session context in the MB-SMF, and sending a MB session join accept message to the UE; ¶ 0016: receiving, from the AMF, a UE ID of the UE and a MB session ID of the particular MB session, determining whether the UE is authorized to join the particular MB session based on the UE ID and the MB session ID, and sending a response to the AMF that indicates whether the UE is authorized to join the particular MB session); and
wherein the multicast broadcast session information further comprises indication information, wherein the indication information is used to indicate that the UE remains joined in, leaves, or requests to join a first multicast broadcast session (see Vesely, ¶ 0008: storing an identifier of the particular MB session, as a joined MB session, to a UE context of the UE stored at the AMF; ¶ 0032: a MB session leave procedure comprises receiving a MB session release message from an AMF, the MB session release message being for a particular UE for a particular MB session).
Regarding claim 12, Vesely discloses the method of claim 10, wherein the processing the multicast broadcast session of the UE based on the multicast broadcast session information carried by the second request comprises:
in case that the multicast broadcast session information is used to indicate that the UE remains joined in the first multicast broadcast session, transmitting a response message to the second request to the first AMF, wherein the response message to the second request carries information about acknowledging that the UE joins in the first multicast broadcast session; or,
in case that the multicast broadcast session information is used to indicate that the UE leaves the first multicast broadcast session, transmitting a response message to the second request to the first AMF, wherein the response message to the second request carries information about acknowledging that the UE leaves the first multicast broadcast session (see Vesely, ¶0144 and ¶ 0145); or,
in case that the multicast broadcast session information is used to indicate that the UE requests to join the first multicast broadcast session and it is determined to accept the UE to join the first multicast broadcast session, establishing a corresponding relationship between an ID of the UE and the first MBS session ID, and transmitting a response message to the second request to the first AMF, wherein the response message to the second request carries information about accepting the UE to join the first multicast broadcast session (see Vesely, ¶ 0006: determining that the MB session join request is permitted by a subscription of the UE, selecting a MB Session Management Function (MB-SMF) based on information comprised in the MB session join request, communicating with the MB-SMF to create a MB session context in the AMF and an MB session context in the MB-SMF, and sending a MB session join accept message to the UE; ¶ 0022); or,
in case that the multicast broadcast session information is used to indicate that the UE requests to join the first multicast broadcast session and the UE is not within a service area of the first multicast broadcast session, transmitting a response message to the second request to the first AMF, wherein the response message to the second request carries information about rejecting the UE to join the first multicast broadcast session; or,
in case that the multicast broadcast session information is used to indicate that the UE remains joined in the first multicast broadcast session and the UE is not within a service area of the first multicast broadcast session, transmitting a response message to the second request to the first AMF, wherein the response message to the second request carries information about indicating the UE to leave the first multicast broadcast session (see Vesely, ¶ 0142-¶ 0145); or,
in case that the multicast broadcast session information is used to indicate that the UE leaves the first multicast broadcast session, deleting a corresponding relationship between an ID of the UE and the first MBS session ID (see Vesely, ¶ 0035-¶ 0043; ¶ 0170-¶ 0174).
Regarding claim 14, it is rejected for the same reasons as set forth in claim 1. Applicant is merely claiming the transmitting side of the invention.
Regarding claim 15, it is rejected for the same reasons as set forth in claim 4.
Regarding claim 16, Vesely discloses the method of claim 14, wherein the processing the first multicast broadcast session based on the response message to the first request comprises: in case that the response message to the first request carries information about accepting the UE to join the first multicast broadcast session, storing first multicast broadcast session context (see Vesely, ¶ 0022: processing circuitry configured to cause the RAN node to receive a MB session join request from a UE, the MB session join request being a request to join a particular MB session. The processing circuitry is further configured to cause the RAN node to send the MB session join request to an AMF, receive a MB session join accept message from the AMF, and send the MB session join accept message to the UE. The RAN node receives, in association with interactions for the MB session, an identity associated with the joined MB session, and the processing circuitry is further configured to cause the RAN node to store the received identity in a RAN UE context for the UE); or,
in case that the response message to the first request carries information about rejecting the UE to join the first multicast broadcast session or information about indicating the UE to leave the first multicast broadcast session, deleting first multicast broadcast session context (see Vesely, ¶ 0038: sending one or more messages to delete the particular MB session, the one or more messages comprising: (a) a message to one or more RAN nodes to request deletion of resources allocated for the particular MB session, (b) a message to one or more UEs that joined the particular MB session to release resources allocated for the particular MB session and/or to leave the particular MB session, or (c) both (a) and (b)).
Regarding claim 17, Vesely discloses the method of claim 14, wherein the receiving the response message to the first request transmitted from the first AMF comprises:
receiving the response message to the first request transmitted from the first AMF and forwarded by a radio access network function entity; wherein the method further comprises: in case that the response message to the first request carries information about accepting the UE to join the first multicast broadcast session, establishing or updating a resource for the first multicast broadcast session (see Vesely, ¶ 0023: a method performed by an AMF for a MB session start procedure comprises receiving a MB session start request from a MB-SMF, the MB session start request being a request to start a particular MB session. The method further comprises, responsive to receiving the MB session start request from the MB-SMF, performing group paging in one or more registration areas of one or more UEs that have an association to the particular MB session. The method further comprises receiving an MBS service request from a UE via a RAN node responsive to performing the group paging, sending a MB session resource setup request to the RAN node, receiving a MB session resource setup response from the RAN node that indicates successful establishment of resources, and sending an MB session start acknowledge to the MB-SMF; ¶ 0026: The AMF is further adapted to, responsive to receiving the MB session start request from the MB-SMF, perform group paging in one or more registration areas of one or more UEs that have an association to the particular MB session. The AMF is further adapted to receive an MBS service request from a UE via a RAN node responsive to performing the group paging, send a MB session resource setup request to the RAN node, receive a MB session resource setup response from the RAN node that indicates successful establishment of resources, and send an MB session start acknowledge to the MB-SMF; ¶ 0213: responsive to receiving (FIG. 9, step 9) the MBS service request from the UE (108), sending (FIG. 9, step 10), to a MB-SMF (118), a request to setup of the particular MB session; ¶ 0111: The UE 108 indicates its interest to Join an MBS Session by an UL NAS Message MB Session Join (MB Session ID, e.g. TMGI) or, alternatively, an UL NAS MB Service Request (MB Session ID, e.g. TMGI). The NG-RAN node 106 forwards the NAS message to the AMF 110; ¶ 0112: NAS and AS MBS user plane resource model (MBS Session, MBS Session Resource, etc.) in analogy to the UE associated user plane resource model); and
receiving service data of the first multicast broadcast session by using the resource (see Vesely, ¶ 0026: receive a MB session resource setup response from the RAN node that indicates successful establishment of resources, and send an MB session start acknowledge to the MB-SMF).
Regarding claim 18, Vesely discloses the method of claim 17, wherein the receiving the service data of the first multicast broadcast session by using the resource comprises: in case that a radio access network function entity does not support multicast broadcast service, receiving the service data of the first multicast broadcast session in a unicast manner by using the resource; or, in case that a radio access network function entity supports multicast broadcast service, receiving the service data of the first multicast broadcast session in a multicast broadcast manner by using the resource (see Vesely, ¶ 0029: forwarding the MBS service request to the AMF, receiving a MB session resource setup request from the AMF for the particular MB session, establishing either point-to-point (PTP) or Point-to-Multipoint (PTM) resources for the MB session, and sending a MB session resource setup response to the AMF).
Regarding claim 19, it is rejected for the same reasons as set forth in claim 1. Although phrased as an apparatus claim, the claim is nevertheless simple repetitions of the subject matter of claim 1.
Vesely further discloses wherein the memory is used for storing a computer program; the transceiver is used for transmitting and receiving data under a control of the processor; and the processor is used for reading the computer program stored in the memory and performing the method of claim 1 (see Vesely, Fig 16; ¶ 0181: the wireless communication device 1600 includes one or more processors 1602 (e.g., CPUs, ASICs, FPGAs, and/or the like), memory 1604, and one or more transceivers 1606 each including one or more transmitters 1608 and one or more receivers 1610 coupled to one or more antennas 1612. The transceiver(s) 1606 includes radio-front end circuitry connected to the antenna(s) 1612 that is configured to condition signals communicated between the antenna(s) 1612 and the processor(s) 1602, as will be appreciated by on of ordinary skill in the art. The processors 1602 are also referred to herein as processing circuitry).
Regarding claim 23, it is rejected for the same reasons as set forth in claim 10. Although phrased as an apparatus claim, the claim is nevertheless simple repetitions of the subject matter of claim 10.
Regarding claim 24, it is rejected for the same reasons as set forth in claim 14. Although phrased as an apparatus claim, the claim is nevertheless simple repetitions of the subject matter of claim 14.
Regarding claim 25, it is rejected for the same reasons as set forth in claim 15. Although phrased as an apparatus claim, the claim is nevertheless simple repetitions of the subject matter of claim 15.
Regarding claim 26, it is rejected for the same reasons as set forth in claim 16. Although phrased as an apparatus claim, the claim is nevertheless simple repetitions of the subject matter of claim 16.
Regarding claim 27, it is rejected for the same reasons as set forth in claims 17 and 18. Although phrased as an apparatus claim, the claim is nevertheless simple repetitions of the subject matter of claims 17 and 18.
Regarding claim 32, it is rejected for the same reasons as set forth in claim 14. Although phrased as a computer-readable storage medium claim, the claim is nevertheless simple repetitions of the subject matter of claim 14.
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.
Claim(s) 3 is/are rejected under 35 U.S.C. 103 as being unpatentable over Abraham in view of US 2020/0344576 to LI et al. (hereafter Li).
Regarding claim 3, Abraham discloses the method of claim 1, but does not explicitly disclose wherein the obtaining the multicast broadcast session information of the UE based on the first request comprises: obtaining the multicast broadcast session information of the UE from a second AMF based on the first request, wherein the second AMF is a network function entity that provides service to the UE before the UE moves, and the first AMF is a network function entity that provides service to the UE after the UE moves.
However, Li discloses wherein the obtaining the multicast broadcast session information of the UE based on the first request comprises: obtaining the multicast broadcast session information of the UE from a second AMF based on the first request, wherein the second AMF is a network function entity that provides service to the UE before the UE moves, and the first AMF is a network function entity that provides service to the UE after the UE moves (see Li, Fig 15a showing New AMF and old AMF; ¶ 0108-¶ 0112).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the above teaching as taught by Li and incorporate it into the system of Abraham to enable efficient usage of radio resources (see Li, ¶ 0056).
Claim(s) 3 is/are rejected under 35 U.S.C. 103 as being unpatentable over Vesely in view of US 2022/0322160 to BAEK (hereafter Baek).
Regarding claim 3, Vesely discloses the method of claim 1, but does not explicitly disclose wherein the obtaining the multicast broadcast session information of the UE based on the first request comprises: obtaining the multicast broadcast session information of the UE from a second AMF based on the first request, wherein the second AMF is a network function entity that provides service to the UE before the UE moves, and the first AMF is a network function entity that provides service to the UE after the UE moves.
However, Baek discloses wherein the obtaining the multicast broadcast session information of the UE based on the first request comprises: obtaining the multicast broadcast session information of the UE from a second AMF based on the first request, wherein the second AMF is a network function entity that provides service to the UE before the UE moves, and the first AMF is a network function entity that provides service to the UE after the UE moves (see Baek, Fig 16; ¶ 039 and ¶ 0164).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the above teaching as taught by Li and incorporate it into the system of Abraham to achieve efficient multicast service in the 5G network (see Baek, ¶ 0012).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 2022/0053455 to BAEK et al. discloses receiving a multicast service by a UE in a wireless communication system comprises receiving, from an application function (AF), a multicast service announcement message including first information related to a local multicast and broadcast service (MBS), identifying that the UE is located in a local MBS area, and transmitting, to an access and mobility management function (AMF), a multicast session join request message for joining a multicast session for the local MBS, the multicast session join request message including second information corresponding to the first information.
US 2023/0345310 to LI et al. discloses delivery mode switch for multicast and broadcast service in a 5G network. The first method is that 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). Multiple options are disclosed for the content of NAS message. First, the NAS message could be PDU session establishment request, where the UE indicates that the session is for multicast, so that the IP multicast address will be allocated later by the core network function, such as MBMF or MB-SMF. Alternatively, the NAS message may be a PDU session modification request indicating that UE would like to re-use an existing MBS PDU session to receive the multicast data through shared traffic delivery method. Second, the NAS message could also be service request message, where UE requests to activate and switch to an existing multicast session. In case that UE wants to switch to an existing active multicast session, UE can send a NAS-SM message to AMF/SMF and indicate the TMGI or IP multicast address in the NAS-SM message.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RASHEED GIDADO whose telephone number is (571)270-7645. The examiner can normally be reached Monday - Friday 8AM-5PM 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, Ricky Ngo can be reached at 571-272-3139. 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.
/RASHEED GIDADO/ Primary Examiner, Art Unit 2464