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 .
Priorities and Examiner Remarks
This application claims foreign priority to application of FINLAND: 20236070 (filed 09/27/2023).
Objections
Claims 12-13, and 18-19 are objected to because of the following informalities, and appropriate correction is required.
Claim 12 line 7-8, the phrase “multicast and broadcast control channel, MCCH” should be changed to “multicast and broadcast control channel (MCCH)” for avoiding ambiguity. Similar problem appears in claim 18.
Claim 13 line 3, the phrase “SIB20/MCCH” should be changed to “SIB20 or MCCH” for avoiding ambiguity. Otherwise, clarification is requested. Similar problem appears in claim 19.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(B) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 5, 10, and 16 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
Claim 5 line 3-4, the phrase “a paging message” is unclear and ambiguous as to whether it is referred to the “paging message” as in claim 4 line 6-7. Clarification is requested. Similar problem appears in claim 16.
Claim 10 line 2, the phrase “a network device” is unclear and ambiguous as to whether it is referred to the “network device” as in claim 4 line 5. Clarification is requested.
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 text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
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.
Claims 1, 3-7, 10, 13-16, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Zhang et al. (US 20230413380 A1, hereinafter Zhang), in view of Alireza Babaei (US 20230328843 A1, hereinafter Babaei).
Regarding claim 1,
Zhang teaches a network device, comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor (Zhang, see fig. 1, e.g. device components),
cause the network device to (Zhang, in general, see either or both of fig. 6 and fig. 7, in view of fig. 4 and/or fig. 5, and along with their corresponding paragraphs):
generate an indicator based on at least one of an activation status of a multicast session or a data inactivity status (Zhang, see at least para. 32, “...At step 622, the network sends UE to RRC INACTIVE state by RRCRelease with suspend indication
...”);
and
transmit the indicator to a client device, wherein the indicator indicates to the client device whether the client device should stop monitoring data of the multicast session while the client device is in an inactive state (Zhang, see at least para. 32, one or more steps after (or in view of) step 622, for a non-limiting example, “...At step 623, the UE receives a group paging notification from the network. In one embodiment, UE establishes an RRC connection and receives multicast service in RRC CONNECTED. In one embodiment (614), UE performs a multicast MRB configuration procedure. In one embodiment, the MRB configuration procedure is based on the stored multicast configuration. At step 640, the UE receives the multicast service in RRC INACTIVE...”).
Zhang does not teach whether the client device should wait for a paging message for the multicast session.
Babaei teaches whether the client device should wait for a paging message for the multicast session (Babaei, see at least para. 128, “...The suspendConfig field/IE may comprise ..., a ran-PagingCycle parameter, ... A ran-PagingCycle parameter may refer to the UE specific cycle for RAN-initiated paging...”).
Therefore, it would have been obvious, before the effective filing date of the claimed invention, to a person having ordinary skill in the art to incorporate Babaei into Zhang for providing substantial benefits, especially in terms of system efficiency and user experience (para. 129).
Regarding claim 3,
Zhang in view of Babaei teaches claim 1.
Zhang further teaches wherein the network device is further caused to transmit the indicator in a radio resource control (RRC) release message or in a multicast and broadcast control channel (MCCH). (Zhang, see at least para. 32, “...At step 622, the network sends UE to RRC INACTIVE state by RRCRelease with suspend indication
...”)
Regarding claim 4, this claim is rejected for the same reasoning as claim 1. To be more specific, although reciting subject matters slightly different, one skilled in the art would have known claim 4 performs reverse (or corresponding) procedures of claim 1. For example, it would be a client device of claim 4 that performs the reverse (or corresponding) receiving from and transmitting to the network device of claim 1. Hence, examiner applies the same rejection reasoning as set forth in claim 1.
In addition, Zhang in view of Babaei also teaches based on the obtained indication, perform one of:
monitor the data of the multicast session while the client device is in the inactive state, if the indication indicates that the client device should not wait for the paging message, or
wait for the paging message for the multicast session and stop monitoring the data of the multicast session while the client device is in the inactive state, if the indication indicates that the client device should wait for the paging message for the multicast session and stop monitoring the data of the multicast session (Zhang, see at least para. 32, one or more steps after (or in view of) step 622, note that “...At step 622, the network sends UE to RRC INACTIVE state by RRCRelease with suspend indication...”, in other words, suspending and moving to inactive state).
Regarding claim 5,
Zhang in view of Babaei teaches claim 4.
Zhang further teaches wherein the obtaining the indication comprises receiving an indicator, wherein the indicator explicitly indicates to the client device whether the client device should stop monitoring data of the multicast session while the client device is in the inactive state from network device or detecting an absence of the indicator from the network device (Zhang, see at least para. 32, one or more steps after (or in view of) step 622, note that “...At step 622, the network sends UE to RRC INACTIVE state by RRCRelease with suspend indication...”, in other words, suspending and moving to inactive state).
Zhang does not teach whether the client device should wait for a paging message for the multicast session.
Babaei teaches whether the client device should wait for a paging message for the multicast session (Babaei, see at least para. 128, “...The suspendConfig field/IE may comprise ..., a ran-PagingCycle parameter, ... A ran-PagingCycle parameter may refer to the UE specific cycle for RAN-initiated paging...”).
Therefore, it would have been obvious, before the effective filing date of the claimed invention, to a person having ordinary skill in the art to incorporate Babaei into Zhang for providing substantial benefits, especially in terms of system efficiency and user experience (para. 129).
Regarding claim 6,
Zhang in view of Babaei teaches claim 4.
Zhang further teaches wherein the multicast session comprises an active multicast session. (Zhang, see at least para. 33, “... UE 701 is in the RRC CONNECTED state (711). At step 721, the UE joins the multicast session. In one scenario, the UE joined a multicast session in RRC CONNECTED state and the multicast session is ongoing...”)
Regarding claim 7,
Zhang in view of Babaei teaches claim 4.
Zhang further teaches wherein the client device is further caused to obtain the indication in a radio resource control (RRC) release message or in a multicast and broadcast control channel (MCCH). (Zhang, see at least para. 32, “...At step 622, the network sends UE to RRC INACTIVE state by RRCRelease with suspend indication
...”)
Regarding claim 10,
Zhang in view of Babaei teaches claim 4.
Zhang further teaches wherein the client device is further caused to, in response to obtaining the indication from a network device controlling a first cell and selecting a second cell controlled by a second network device for camping in the inactive state, receive the paging message according to the indication while the client device is camping in the second cell. (Zhang, see at least fig. 8 in view of fig. 6, in particular, steps 840-851 of fig. 8, in view of steps 622-640)
Regarding claim 13,
Zhang in view of Babaei teaches claim 4.
Zhang further teaches wherein the client device is further caused to: select a second cell to camp on (Zhang, see at least para. 34, e.g. step 821); switch to a connected state in the second cell in response to not receiving SIB20/MCCH in the second cell (Zhang, see at least para. 34, e.g. step 840 and step 851).
Regarding claim 14,
Zhang in view of Babaei teaches claim 13.
Zhang further teaches wherein the client device is further caused to: receive an RRC release message from a first cell, the RRC release message not comprising the indication and/or a multicast session activation status (Zhang, see at least para. 32, “...At step 622, the network sends UE to RRC INACTIVE state by RRCRelease with suspend indication...”)
Regarding claims 15, 16, 19, and 20, these claims are rejected for the same reasoning as claims 4, 5, 13, and 14, respectively, except each of these claims is in method claim format.
Claim 2 is rejected under 35 U.S.C. 103 as being unpatentable over Zhang in view of Babaei, and further in view of Kim et al. (US 20180213452 A1, hereinafter Kim).
Regarding claim 2,
Zhang in view of Babaei teaches claim 4.
Zhang in view of Babaei does not teach wherein the data inactivity status is based on whether the network device has received data for the multicast session within a predetermined time duration.
Kim teaches wherein the data inactivity status is based on whether the network device has received data for the multicast session within a predetermined time duration. (Kim, see at least para. 314 of fig. 2E, “...if data is not generated for a predetermined time, the UE in the RRC connected mode 2 e-03 may be switched to the RRC inactive mode 2 e-02 by the network...”)
Therefore, it would have been obvious, before the effective filing date of the claimed invention, to a person having ordinary skill in the art to incorporate Kim into Zhang in view of Babaei for the purpose of battery saving and rapid access support (para. 314).
Claims 8, 9, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Zhang in view of Babaei, and further in view of SHRIVASTAVA et al. (US 20240008128 A1, hereinafter SHRIVASTAVA).
Regarding claim 8,
Zhang in view of Babaei teaches claim 4.
Zhang in view of Babaei does not teach in response to the indication indicating that the client device should not wait for the paging message for the multicast session and monitor the data of the multicast session, keep radio bearers for the multicast session active and monitor the data of the multicast session while the client device is in the inactive state.
SHRIVASTAVA teaches in response to the indication indicating that the client device should not wait for the paging message for the multicast session and monitor the data of the multicast session, keep radio bearers for the multicast session active and monitor the data of the multicast session while the client device is in the inactive state (SHRIVASTAVA, in general, see fig. 4 and corresponding paragraphs, in particular, see at least para. 68, note that in step 410, the UE 102 continues to receive the multicast services in the RRC_INACTIVE state without suspending the multicast MRB configurations, when the UE 102 transitions from the RRC connected state to the RRC_INACTIVE state).
Therefore, it would have been obvious, before the effective filing date of the claimed invention, to a person having ordinary skill in the art to incorporate SHRIVASTAVA into Zhang in view of Babaei to configure the UEs to efficiently and seamlessly continue receiving one or more multicast services while the UEs transition from an RRC connected state to the RRC inactive state for MBS multicast service reception (para. 15).
Regarding claim 9,
Zhang in view of Babaei and SHRIVASTAVA teaches claim 8.
Zhang does not teaches wherein monitoring the data of the multicast session comprises monitoring a group radio network temporary identifier (G-RNTI) of the multicast session.
Babaei further teaches wherein monitoring the data of the multicast session comprises monitoring a group radio network temporary identifier (G-RNTI) of the multicast session. (Babaei, see at least para. 131, e.g. G-RNIT for MBS multicast)
Therefore, it would have been obvious, before the effective filing date of the claimed invention, to a person having ordinary skill in the art to incorporate Babaei into Zhang for providing substantial benefits, especially in terms of system efficiency and user experience (para. 129).
Regarding claim 17, this claim is rejected for the same reasoning as claim 8 except this claim is in method claim format.
Claims 11, 12, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Zhang in view of Babaei, and further in view of SHRIVASTAVA Vinay Kumar (US 20230269828 A1, hereinafter SHRIVASTAVA_828).
Regarding claim 11,
Zhang in view of Babaei teaches claim 4.
Zhang in view of Babaei does not teach wherein the client device is further caused to, in response to the indication indicating that the client device should not wait for the paging message for the multicast session and monitor the data of the multicast session, switch to a connected state from the inactive state in response to at least one criterion being met.
SHRIVASTAVA_828 teaches wherein the client device is further caused to, in response to the indication indicating that the client device should not wait for the paging message for the multicast session and monitor the data of the multicast session, switch to a connected state from the inactive state in response to at least one criterion being met. (SHRIVASTAVA_828, see sections including at least para. 237-244, note that in an embodiment, the UE (100) continues to receive multicast service in Connected mode, when the UE (100) transits to the Connected mode)
Therefore, it would have been obvious, before the effective filing date of the claimed invention, to a person having ordinary skill in the art to incorporate SHRIVASTAVA_828 into Zhang in view of Babaei to provide efficient and effective methods and a UE for MCCH configuration and operation and handling idle/inactive mode operation for NR Multicast Broadcast Services (para. 12).
Regarding claim 12,
Zhang in view of Babaei teaches claim 11.
Zhang in view of Babaei does not teach wherein the at least one criterion comprises at least: the client device being sent to the inactive state from the connected state in a first cell controlled by the network device, the client device switching to a second cell to camp in the inactive state; and the client device not finding a multicast and broadcast control channel, MCCH, in the second cell.
SHRIVASTAVA_828 teaches wherein the at least one criterion comprises at least: the client device being sent to the inactive state from the connected state in a first cell controlled by the network device, the client device switching to a second cell to camp in the inactive state; and the client device not finding a multicast and broadcast control channel, MCCH, in the second cell. (SHRIVASTAVA_828, see sections including at least para. 237-244, note that the UE (100) is triggered to receive multicast service in the idle mode or the inactive mode, among others, including at least one of the following: when the network entity (200) releases the UE (100) from the connected mode (e.g., due to congestion) with an indication of continuation of MBS multicast service in Idle or Inactive mode)
Therefore, it would have been obvious, before the effective filing date of the claimed invention, to a person having ordinary skill in the art to incorporate SHRIVASTAVA_828 into Zhang in view of Babaei to provide efficient and effective methods and a UE for MCCH configuration and operation and handling idle/inactive mode operation for NR Multicast Broadcast Services (para. 12).
Regarding claim 18, this claim is rejected for the same reasoning as combination of claims 11-12, except this claim is in method claim format.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to YEE F LAM whose telephone number is (571)270-7577. The examiner can normally be reached M-F 8am-5pm. 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, Ayman Abaza can be reached on 571-270-0422. 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.
/YEE F LAM/Primary Examiner, Art Unit 2465
Prosecution Insights