DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Information Disclosure Statement
The information disclosure statements (IDSs) submitted are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Objections
Claims 1, 4, 7, 9, and 11 are objected to because of the following informalities:
Claims 1, 4, 7, 9, and 11 recite the word “RAN”, the acronym should be defined (spelled out) at least in the first instances in the claim. Appropriate correction is required.
Claims 4, 7, and 9 recite the phrase “RRC state”, the word “RRC” should be defined (spelled out) at least in the first instances in the claim. Appropriate correction is required.
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.
Claims 1-2, 11-13, and 16-18 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by 3GPP1 (3GPP TR 23.700-47 V18.0.0 (2022-12)).
Regarding claim 1, the cited reference 3GPP1 discloses an apparatus (Figure 6.19.3.3-1 (page 80) discloses a NG-RAN) comprising: one or more processors, and memory storing instructions that, when executed by the one or more processors (The NG-RAN is responsible for transmitting and receiving data between the LTE device and the core network and is connected to the 5GC (5G Core) via the NG interface. The NG-RAN architecture relies heavily on powerful processors (CPUs, GPUs, etc.) and memories to perform its functions.), cause the apparatus to perform: receiving a request Figure 6.19.3.3-1 (page 80) discloses receive Multicast announcement request (Step 5)) wherein the request requests the RAN node to broadcast an advertisement of a multicast session (Section 6.19.3.3 (page 80) discloses in Step 2-5 that MB-SMF informs RAN nodes in service area of multicast session via AMFs of multicastsession and asks them to announce multicast session), wherein the advertisement indicates that the apparatus transmits data for the multicast session in a transmission mode for inactive reception (Section 6.1.2 (page 17) lines 8-9 discloses that NG-RAN nodes maydeliver the MBS session to UEs in the inactive state), and wherein the data transmitted in the transmission mode for inactive reception is suitable to be received by a first terminal in an inactive state (Section 6.19.3.2 (page 79) discloses RAN procedures. RAN nodes decides whether to deliver in mode for RRC inactive reception, and otherwise will perform RAN paging. For the delivery mode for RRC inactive reception, RRC-inactive UEs should be made aware that the MBS multicast session is activated but remain in RRC-inactive state for multicast data reception); determining the apparatus is configured to transmit the data for the multicast session in the transmission mode for inactive reception (Section 6.19.3.3 (page 30) in step 6 that NG-RAN decide whether to apply delivery mode for inactive reception and transmit data and in lines 8-9 discloses that the NG-RAN node determines the MBS session data can be transmitted due to UE is in RRC inactive state); and broadcasting the advertisement in one or more cells associated with the apparatus based on the receiving the request and the determining the apparatus is configured to transmit the data for the multicast session in the transmission mode for inactive reception (Figure 6.19.3.3-1 (page 80) discloses that NG-RAN receives Multicast announcement request (Step 5) , decide whether to apply delivery mode for inactive reception and transmit data (Step 6), and in Step 8 perform RAM procedure such indication of delivery mode or delivery of data).
Regarding claim 2, the cited reference 3GPP1 discloses all limitations of claim 1. 3GPP1 further discloses wherein the request comprises at least one of the following: an identifier of the multicast session or assistance information indicating whether or not applying the transmission mode for inactive reception for transmitting the data for the multicast session is preferred (Figure 6.19.3.3-1 (page 80) discloses in Step 5 that the Multicast announcement request include MBS session ID).
Regarding claim 11, the cited reference 3GPP1 discloses all limitations of claim 1. 3GPP1 further discloses wherein the instructions, when executed by the one or more processors, cause the apparatus to perform for each of the one or several cells: supervising, for each of the one or several cells, whether the RAN node receives an indication that the first terminal desires to receive the data for the multicast session; multicasting the data for the multicast session in the cell in the transmission mode for reception in inactive state if the cell receives the indication (Figure 6.1.3.2-1 (pages 19 and 20) Steps 0 and 8-9 which disclose when UE registers, it indicates its capability to receive MBS multicast using the transmission mode for RRC inactive. It may also indicate a preference regarding the connectivity state in which it wishes to receive MBS session(s)… This information is propagated to NG-RAN via AMF where AMF sends the N2 SM information received from SMF to NG-RAN node during the shared tunnel establishment procedure. AF provides the UE session priority. in step 0 discloses that the capability is related to inactive reception and step 9 discloses that sending RRC message (i.e. inactive reception enabled) from NG-RAN to the UE. Step 15 discloses that the NG-RAN decides the transmission mode to apply for the MBS multicast session in a cell).
Regarding claim 12, the cited reference 3GPP1 discloses all limitations of claim 11. 3GPP1 further discloses wherein the indication that the first terminal desires to receive the data for the multicast session comprises at least one of an interest indication and a preamble (Figure 6.1.3.2-1 (pages 19 and 20) Steps 0 which disclose when UE registers, it indicates its capability to receive MBS multicast using the transmission mode for RRC inactive).
Regarding claims 13 and 16, the cited reference 3GPP1 discloses all limitations of claims 11 and 12 respectively. 3GPP1 further discloses wherein the instructions, when executed by the one or more processors, cause the apparatus to perform: supervising for each of the one or several cells whether at least one second terminal in connected state that joined the multicast session is in the cell; multicasting the data for the multicast session in the cell if second terminal in connected state that joined the multicast session is in the cell (pages 17 lines 39 and 40 disclose UEs that joined a MBS multicast session are in a cell, MBS data need to be transmitted using the Rel-17 transmission mode for RRC-connected reception).
Regarding claim 17, the cited reference 3GPP1 discloses all limitations of claim 16. 3GPP1 further discloses wherein the instructions, when executed by the one or more processors, cause the apparatus to perform: requesting the establishment of shared data delivery for the multicast session when starting to multicast the data for the multicast session(pages 81 lines 13 and 15-16 disclose NG-RAN… Receive assistance information either as part of request for service announcement or within shared delivery Establishment).
Regarding claim 18, the cited reference 3GPP1 discloses all limitations of claim 11. 3GPP1
further discloses wherein the instructions, when executed by the one or more processors, cause the apparatus to perform: requesting the establishment of shared data delivery for the multicast session when starting to multicast the data for the multicast session(pages 81 lines 13 and 15-16 disclose NG-RAN… Receive assistance information either as part of request for service announcement or within shared delivery Establishment).
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 of this title, 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.
Claims 3-10 are rejected under 35 U.S.C. 103 as being unpatentable over 3GPP1 (3GPP TR 23.700-47 V18.0.0 (2022-12)), in view of 3GPP2 (3GPP TSG-SA2 Meeting #156-e, S2-2305902 (2023-04)).
Regarding claim 3, the cited reference 3GPP1 discloses all limitations of claim 2. 3GPP1 further discloses wherein the request comprises an indication of a service area of the multicast session (Figure 6.19.3.3-1 (page 80) discloses in Step 5 that the Multicast announcement request include service area). 3GPP1 discloses in Figure 6.19.3.3-1 (page 80) Step 6 the RAN nodes decide delivery mode for MBS session in a cell and whether to deliver data. However, 3GPP1 does not explicitly teach determining the one or more cells based on the service area received in the request.
In an analogous art 3GPP2 teaches determining the one or more cells based on the service area received in the request (Page 5 lines 1-8 discloses that the AMF transfers the MBS Session Resource Setup Request message, which contains the N2 SM information in the received Namf_MBSBroadcast_ContextCreate Request to all NG-RANs which support MBS in the MBS service area. The AMF includes the MBS service area. NG-RAN creates a Broadcast MBS Session Context… If MBS FSA ID(s) were received, the NG-RAN may use those MBS FSA ID(s)s to determine cells/frequencies within the MBS service area to broadcast MBS session data ). It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to incorporate the method of 3GPP2 to optimize system performance, reduce the resource waste of radio interface and lower the complexity of the system processing.
Regarding claim 4, the combination of 3GPP1 and 3GPP2 discloses all limitations of claim 3. 3GPP1 further discloses wherein the instructions, when executed by the one or more processors, cause the apparatus to perform: determining, for each cell of the one or more cells,whether or not the RAN node transmits the data for the multicast session in the transmission mode for reception in inactive state or in a transmission mode for reception in connected state based on at least on one of the following: whether or not the RAN node receives the request to broadcast the advertisement, number of terminals wanting to receive the multicast session in the cell; RRC state of terminals in the multicast session in the cell; load in the cell; capabilities of terminals that have joined the multicast session in the cell to receive data for the multicast session while in inactive state, and assistance information received as part of the request to broadcast (Page 80 discloses in lines 3-6 that make the RAN nodes aware that an MBS multicast session enabling delivery for inactive reception is ongoing. RAN nodes can then apply appropriate procedures to handle the MBS session, e.g. decide whether to transmit data and whether to allow RRC_INACTIVE UE receiving MBS
Data where page 81 further discloses decide transmission mode for a multicast session in a cell).
Regarding claim 5, the combination of 3GPP1 and 3GPP2 discloses all limitations of claim 4. 3GPP1 further discloses wherein the instructions, when executed by the one or more processors, cause the apparatus to perform: broadcasting the advertisement including an indication of the determined transmission mode (Figure 6.19.3.3-1 Step 6 and 8 which discloses Ran node decides whether to apply delivery mode for inactive reception … perform RAN related procedures, e.g. indication of delivery mode).
Regarding claims 6, 7, and 8, the claims reciting substantially similar limitations of claims 3, 4, and 5 respectively. Therefore, the claims are subject to the same rejection as claims 3, 4, and 5 respectively.
Regarding claims 9 and 10, the claims reciting substantially similar limitations of claims 4 and 5 respectively. Therefore, the claims are subject to the same rejection as claims 4 and 5 respectively.
Claims 14-15 are rejected under 35 U.S.C. 103 as being unpatentable over 3GPP1 (3GPP TR 23.700-47 V18.0.0 (2022-12)), in view of Cooper (US20130159544).
Regarding claim 14, the cited reference 3GPP1 discloses all limitations of claim 13. 3GPP1 further discloses wherein the instructions, when executed by the one or more processors,cause the apparatus to perform: inhibiting the multicasting the data for the multicast session in the cell if none of the at least one second terminal in the connected state that joined the multicast session is in the cell (Section 6.5.3.1 (page 30 lines 29-30) discloses to stop the MBSdata transmission at the cell if there are no RRC connected state UE … at that cell). However, 3GPP1 does not explicitly teach inhibiting the multicasting the data for the multicastsession in the cell if the cell does not receive the indication.
In an analogous art Cooper teaches inhibiting the multicasting the data for the multicast session in the cell if the cell does not receive the indication (¶0008 discloses that a method comprising the actions of multicasting a first streaming content to at least one client of the plurality of clients, and terminating the multicast of the first streaming content upon a determination that none of the plurality of clients desires to continue to receive the first streaming content).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to incorporate the method of Cooper to save processing resources and network transmission resources.
Regarding claim 15, the combination of 3GPP1 and Cooper discloses all limitations of claim 14. 3GPP1 further discloses wherein the instructions, when executed by the one or more processors, cause the apparatus to perform: requesting the establishment of shared data delivery for the multicast session when starting to multicast the data for the multicast session (pages 81 lines 13 and 15-16 disclose NG-RAN… Receive assistance information either as part of request for service announcement or within shared delivery Establishment).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ABDELILLAH ELMEJJARMI whose telephone number is (571)270-1656. The examiner can normally be reached on Mon-Fri: 8AM-5PM EST.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Yemane Mesfin can be reached on (571)272-3927. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system,
see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
Respectfully submitted,
/ABDELILLAH ELMEJJARMI/
Primary Examiner, Art Unit 2462