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 .
DETAILED ACTION
In the amendment filed January 26, 2026, claims 1, 3, 5-7, 9, 10, 13, 15, 16, 19, and 20 have been amended, claims 1, 3, 5-7, 9-10, 13 and 15-20 are currently pending for examination.
Drawings
The drawings are objected to under 37 CFR 1.83(a). The drawings must show every feature of the invention specified in the claims. Therefore, the first core network node is an access and mobility management function (AMF) entity, and the second network node is a multicast broadcast session management function (MB-SMF) entity, as recited in claim 9, must be shown or the feature(s) canceled from the claim(s). No new matter should be entered.
Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Claim Objections
Claims 1, 3 and 5-7 are objected to because of the following informalities:
Claim 1 recites “an access network node" in line 7. For consistency and clarification with “the at least one access network node” recited in line 6, it is suggested to change “an access network node" in line 7, to “the at least one
Claims 3, and 5-7 are also objected to since they are dependent on the objected base independent claim 1 as set forth above.
Appropriate correction is required.
Regarding 35 U.S.C. 102 applicant’s arguments, see page 9 paragraph 2, January 26. 2026, with respect to claims 1, 3, and 5-7 have been fully considered and are persuasive. The rejection of claims 1, 3, and 5-7 have been withdrawn.
Regarding 35 U.S.C. 103 applicant’s arguments, see page 9 paragraphs 6 - page 19, filed January 26, 2026, with respect to claims 9-10, 13 and 15-20 have been fully considered and are not persuasive. Examiner note that independent claim 9 and 15 are of different scope than that independent claim 1 and subjected to a restriction.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action.
Regarding amended claim 9, the applicant argued that, see page 10 paragraph 3-page 16, “…Specifically, as shown in Steps 704-705 of Fig. 7, Li discloses that an SMF network element sends multicast capability inquiry request to an AMF network element, and receives a multicast capability inquiry response from the AMF network element. The interaction disclosed in Li is directed to "capability inquiry", rather than tunnel establishment. No evidence has been provided to demonstrate that a "capability inquiry" amounts to a "shared tunnel establishment". Therefore, Li fails to disclose the feature a) of amended claim 9. With respect to the above feature b) of claim 9 The feature b) of amended claim 9 was previously recited in pending claim 11. On page 7 of the Office Action, it is asserted that said feature is disclosed by Li. In support of this, the Examiner references paragraphs [0019]-[0020], [0095]-[0097], [0139], [0170], and [0191], placing particular emphasis on the interpretation that: "sending a shared tunnel establishment request of the access network node to a first core network node, and receiving a shared tunnel establishment rejection message/the multicast capability information includes: not supporting broadcast sending, or no supporting multicast tunnel reception, or not supporting unicast tunnel reception, or supporting broadcast sending/rejecting/a rejection message based on the MBS capability information of the access network node". The Applicant respectfully disagrees. First, based on the same reasoning set forth above regarding feature a), Li explicitly states that the multicast capability information includes supporting multicast tunnel reception or supporting unicast tunnel reception. This is fundamentally different from the Examiner's interpretation on page 7 of the Office Action, which suggests that the information includes no supporting multicast tunnel reception or not supporting unicast tunnel reception. Since the rejection is predicated on this misinterpretation of the cited reference, it is unfounded and should be withdrawn. Furthermore, according to the subject matter of amended claim 9, the shared tunnel establishment rejection message is sent in a case that it is determined that the access network node does not support an MBS. However, Li is silent about sending a shared tunnel establishment rejection message in a case that it is determined that the access network node does not support an MBS. Therefore, Li fails to disclose, teach or suggest the above feature b) of amended claim 9. For at least the reasons discussed above, each of Lei and Li does not disclose, teach, or suggest the features a) and b) of independent claim 9. As such, the rejections under 35 U.S.C. § 103 are not supported and independent claim 9 is in condition for allowance.
In response to applicant's argument, the examiner respectfully disagrees with the argument above.
Regarding amended claim 9, Li disclose A shared tunnel management method, comprising:
sending, by a second core network node, a shared tunnel establishment request of the access network node to a first core network node, and receiving a shared tunnel establishment rejection message sent by the first core network node (see para. 19-20, 95-97, 139, 170-170, 191, sending a shared tunnel establishment request of the access network node to a first core network node, and receiving a shared tunnel establishment rejection message / the multicast capability information includes: not supporting broadcast sending, or no supporting multicast tunnel reception, or not supporting unicast tunnel reception, or supporting broadcast sending / rejecting/ a rejection message/ a shared tunnel establishment rejection message);
wherein the shared tunnel establishment rejection message is sent, based on multicast
broadcast service (MBS) capability information of the access network node, by the first core network node in a case that it is determined that the access network node does not support an MBS (see para. 19-20, 95-97, 139, 170-170, 191, sending MBS capability of the RAN node, where it is determined the RAN/access network node does not support an MBS), the Examiner further states that Ma disclose wherein a first core network node is an access and mobility management function (AMF) entity (see Fig.1, Fig.2, AFM), and a second network node is a multicast broadcast session management function (MB-SMF) entity (see Fig.2, the Multicast/Broadcast SMF (MB-SMF) 203, see para. 0027).
Under the broadest reasonable interpretation, the combination of the systems as disclosed by Li and Ma reads upon “sending, by a second core network node, a shared tunnel establishment request of an access network node to a first core network node, and receiving a shared tunnel establishment rejection message sent by the first core network node; wherein the shared tunnel establishment rejection message is sent, based on multicast broadcast service (MBS) capability information of the access network node, by the first core network node in a case that it is determined that the access network node does not support an MBS; wherein the first core network node is an access and mobility management function (AMF) entity, and the second network node is a multicast broadcast session management function (MB-SMF) entity” as recites in the claim.
Regarding amended claim 15, the applicant argued that, see page 17 last paragraph -page 19, “…At the end of page 9 of the Office Action, it is asserted that the feature b) of claim 15 is disclosed by Yang722. In support of this, the Examiner references paragraphs [0153]-[0350], placing particular emphasis on the interpretation that: "a multicast SMF determining, according to multicast transmission stream status information sent by a terminal, whether to transmit multicast data to the terminal in a unicast manner; a multicast service control network element determining, with reference to other information, whether to use a multicast transmission manner or a unicast transmission manner; and upon receiving a first multicast session request, an access network node determining whether to accept the request". According to the Examiner's interpretation, Yang 722 merely relates to determining the manner (i.e., multicast or unicast) for transmitting data. However, the determination of a multicast/unicast manner is not equivalent to the establishment of a shared tunnel. The transmission manner (e.g., multicast or unicast) is a packet-level transmission decision that is independent of the establishment of a shared tunnel. Therefore, the mere disclosure of the decision regarding transmission manner does not inherently disclose, teach or suggest the limitation regarding establishment of a tunnel claimed in the present application. Therefore, Yang722 fails to disclose the above feature b) of amended claim 15. For at least the reasons discussed above, each of Yang and Yang722 does not disclose, teach, or suggest the features a) and b) of independent claim 15. As such, the rejections under 35 U.S.C. § 103 are not supported and independent claim 15 is in condition for allowance. Likewise, dependent claims 16-20 are allowable over the cited prior art of record at least due to their dependency on allowable independent claim 15. Based on the foregoing, it is respectfully submitted that each of the pending claims is allowable. Accordingly, it is respectfully requested that the rejections under 35 U.S.C. § 103 be withdrawn.
In response to applicant's argument, the examiner respectfully disagrees with the argument above.
Regarding amended claim 15, Yang disclose A multicast service tunnel management method, comprising:
initiating, by a second core network node, a shared tunnel establishment request based on non-existence of a storage record for an information of an access network node (see para. 147-250, an SMF sending a multicast session request to an AMF; and the AMF sending a multicast request to access network nodes, and determining, according to stored region information, and on the basis of whether there is a storage record, a core network node initiating a sharing channel establishment request, see Yang233, Fig.5, para. Fig.6, para. 0241-0243, 0247-0251, the access and mobility management network element determine, based on the information carried in the received first multicast session request (for example, the service area information of the multicast service), the access network nodes to which the first multicast session request is sent. In addition, the access and mobility management network element in S601a and S601b is determined by the multicast session management network element based on a correspondence between the service area information and the access and mobility management network element. The correspondence is stored on the multicast session management network element, or is obtained from another device by the multicast session management network element / request based on non-existence of a storage record for an information of an access network node, see also para. 0173, 0222, 0279).
Although Yang disclose initiating, by a second core network node, a shared tunnel establishment request based on non-existence of a storage record for an information of an access network node;
Yang however does not explicitly disclose– Alternate Limitations (Note: Scope different than Independent claim 1):indicating or rejecting indicating, by a second core network node, establishment of a shared tunnel based on a state of a multicast session; or indicating, by a second core network node, establishment of a unicast tunnel based on existence of an access network node that does not support multicast in a multicast session; or rejecting indicating, by a second core network node, establishment of a unicast tunnel based on non-existence of an access network node that does not support multicast in a multicast session, the Examiner further states that Yang722 disclose indicating or rejecting indicating, by a second core network node, establishment of a shared tunnel based on a state of a multicast session; or indicating, by a second core network node, establishment of a unicast tunnel based on existence of an access network node that does not support multicast in a multicast session; or rejecting indicating, by a second core network node, establishment of a unicast tunnel based on non-existence of an access network node that does not support multicast in a multicast session (see para. 153-350, a multicast SMF determining, according to multicast transmission stream status information sent by a terminal, whether to transmit multicast data to the terminal in a unicast manner; a multicast service control network element determining, with reference to other information, whether to use a multicast transmission manner or a unicast transmission manner; and upon receiving a first multicast session request, an access network node determining whether to accept the request).
Under the broadest reasonable interpretation, the combination of the systems as disclosed by Yang and Yang722 reads upon “initiating, by a second core network node, a shared tunnel establishment request based on non-existence of a storage record for an information of an access network node; or indicating or rejecting indicating, by a second core network node, establishment of a shared tunnel based on a state of a multicast session; or indicating, by a second core network node, establishment of a unicast tunnel based on existence of an access network node that does not support multicast in a multicast session; or rejecting indicating, by a second core network node, establishment of a unicast tunnel based on non-existence of an access network node that does not support multicast in a multicast session” as recites in the claim.
Notice re prior art available under both pre-AIA and AIA
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 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.
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 9-14 are rejected under 35 U.S.C. 103 as being unpatentable over Li (CN110098942A), and further in view of Ma et al (US Pub. No.:20230171845).
As per claim 9, Li disclose A shared tunnel management method, comprising:
sending, by a second core network node, a shared tunnel establishment request of the access network node to a first core network node, and receiving a shared tunnel establishment rejection message sent by the first core network node (see para. 19-20, 95-97, 139, 170-170, 191, sending a shared tunnel establishment request of the access network node to a first core network node, and receiving a shared tunnel establishment rejection message / the multicast capability information includes: not supporting broadcast sending, or no supporting multicast tunnel reception, or not supporting unicast tunnel reception, or supporting broadcast sending / rejecting/ a rejection message/ a shared tunnel establishment rejection message);
wherein the shared tunnel establishment rejection message is sent, based on multicast
broadcast service (MBS) capability information of the access network node, by the first core network node in a case that it is determined that the access network node does not support an MBS (see para. 19-20, 95-97, 139, 170-170, 191, sending MBS capability of the RAN node, where it is determined the RAN/access network node does not support an MBS).
Li however does not explicitly disclose wherein the first core network node is an access and mobility management function (AMF) entity, and the second network node is a multicast broadcast session management function (MB-SMF) entity.
Ma however disclose wherein a first core network node is an access and mobility management function (AMF) entity (see Fig.1, Fig.2, AFM), and a second network node is a multicast broadcast session management function (MB-SMF) entity (see Fig.2, the Multicast/Broadcast SMF (MB-SMF) 203, see para. 0027).
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to provide the functionality of wherein the first core network node is an access and mobility management function (AMF) entity, and the second network node is a multicast broadcast session management function (MB-SMF) entity, as taught by Ma, in the system of Li, so to enable a Radio Access Network (RAN) node to establish a Multicast and Broadcast Service (MBS) session using an existing tunnel that has been established between the core network and another RAN node, thereby improving load balancing among the RAN nodes and reducing signaling overhead associated with mobile devices in mobility scenarios, see Ma, paragraphs 4-6.
As per claim 10, the combination of Li and Ma disclose the method according to claim 9.
Li however disclose wherein the MBS capability information indicates that the access network node supports or does not support the MBS (see para. 19-20, 95-97, 139, 170-170, 191, the multicast capability information includes: not supporting broadcast sending, or no supporting multicast tunnel reception, or not supporting unicast tunnel reception, or supporting broadcast sending).
As per claim 13, the combination of Li and Ma disclose the method according to claim 9.
Li however disclose wherein after the receiving the shared tunnel establishment rejection message sent by the first core network node, the method further comprises: determining that the access network node does not support the MBS, and rejecting initiating the shared tunnel establishment request to the access network node (see para. 19-20, 95-97, 139, 170-170, 191, sending a shared tunnel establishment request of the access network node to a first core network node, and receiving a shared tunnel establishment rejection message / the multicast capability information includes: not supporting broadcast sending, or no supporting multicast tunnel reception, or not supporting unicast tunnel reception, or supporting broadcast sending / rejecting/ a rejection message/ a shared tunnel establishment rejection message).
Claims 9-14 are rejected under 35 U.S.C. 103 as being unpatentable over Li (CN110098942A), and further in view of Xiong et al (US Pub. No.:2023/0025793).
As per claim 9, Li disclose A shared tunnel management method, comprising:
sending, by a second core network node, a shared tunnel establishment request of the access network node to a first core network node, and receiving a shared tunnel establishment rejection message sent by the first core network node (see para. 19-20, 95-97, 139, 170-170, 191, sending a shared tunnel establishment request of the access network node to a first core network node, and receiving a shared tunnel establishment rejection message / the multicast capability information includes: not supporting broadcast sending, or no supporting multicast tunnel reception, or not supporting unicast tunnel reception, or supporting broadcast sending / rejecting/ a rejection message/ a shared tunnel establishment rejection message);
wherein the shared tunnel establishment rejection message is sent, based on multicast
broadcast service (MBS) capability information of the access network node, by the first core network node in a case that it is determined that the access network node does not support an MBS (see para. 19-20, 95-97, 139, 170-170, 191, sending MBS capability of the RAN node, where it is determined the RAN/access network node does not support an MBS).
Li however does not explicitly disclose wherein the first core network node is an access and mobility management function (AMF) entity, and the second network node is a multicast broadcast session management function (MB-SMF) entity.
Xiong however disclose wherein a first core network node is an access and mobility management function (AMF) entity (see Fig.10, Fig.11, AFM), and a second network node is a multicast broadcast session management function (MB-SMF) entity (see Fig.11, the Multicast/Broadcast SMF (MB-SMF) 203, see para. 0099-0100).
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to provide the functionality of wherein the first core network node is an access and mobility management function (AMF) entity, and the second network node is a multicast broadcast session management function (MB-SMF) entity, as taught by Ma, in the system of Li, so to broadcast service and the multicast service, see Ma, paragraphs 48-52.
Examiner Note: Claim 9 Limitations ( Scope different than Independent claim 1).
As per claim 10, the combination of Li and Xiong disclose the method according to claim 9.
Li however disclose wherein the MBS capability information indicates that the access network node supports or does not support the MBS (see para. 19-20, 95-97, 139, 170-170, 191, the multicast capability information includes: not supporting broadcast sending, or no supporting multicast tunnel reception, or not supporting unicast tunnel reception, or supporting broadcast sending).
As per claim 13, the combination of Li and Xiong disclose the method according to claim 9.
Li however disclose wherein after the receiving the shared tunnel establishment rejection message sent by the first core network node, the method further comprises: determining that the access network node does not support the MBS, and rejecting initiating the shared tunnel establishment request to the access network node (see para. 19-20, 95-97, 139, 170-170, 191, sending a shared tunnel establishment request of the access network node to a first core network node, and receiving a shared tunnel establishment rejection message / the multicast capability information includes: not supporting broadcast sending, or no supporting multicast tunnel reception, or not supporting unicast tunnel reception, or supporting broadcast sending / rejecting/ a rejection message/ a shared tunnel establishment rejection message).
Claims 15, and 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over Yang (CN109699013A, also published as US Pub. No.:2020/0260233, Yang233), and further in view of Yang722 (CN1112087722A).
As per claim 15, Yang disclose A multicast service tunnel management method, comprising:
initiating, by a second core network node, a shared tunnel establishment request based on non-existence of a storage record for an information of an access network node (see para. 147-250, an SMF sending a multicast session request to an AMF; and the AMF sending a multicast request to access network nodes, and determining, according to stored region information, and on the basis of whether there is a storage record, a core network node initiating a sharing channel establishment request, see Yang233, Fig.5, para. Fig.6, para. 0241-0243, 0247-0251, the access and mobility management network element determine, based on the information carried in the received first multicast session request (for example, the service area information of the multicast service), the access network nodes to which the first multicast session request is sent. In addition, the access and mobility management network element in S601a and S601b is determined by the multicast session management network element based on a correspondence between the service area information and the access and mobility management network element. The correspondence is stored on the multicast session management network element, or is obtained from another device by the multicast session management network element / request based on non-existence of a storage record for an information of an access network node, see also para. 0173, 0222, 0279).
Although Yang disclose initiating, by a second core network node, a shared tunnel establishment request based on non-existence of a storage record for an information of an access network node;
Yang however does not explicitly disclose– Alternate Limitations (Note: Scope different than Independent claim 1):indicating or rejecting indicating, by a second core network node, establishment of a shared tunnel based on a state of a multicast session; or indicating, by a second core network node, establishment of a unicast tunnel based on existence of an access network node that does not support multicast in a multicast session; or rejecting indicating, by a second core network node, establishment of a unicast tunnel based on non-existence of an access network node that does not support multicast in a multicast session.
Yang722 however disclose indicating or rejecting indicating, by a second core network node, establishment of a shared tunnel based on a state of a multicast session; or indicating, by a second core network node, establishment of a unicast tunnel based on existence of an access network node that does not support multicast in a multicast session; or rejecting indicating, by a second core network node, establishment of a unicast tunnel based on non-existence of an access network node that does not support multicast in a multicast session (see para. 153-350, a multicast SMF determining, according to multicast transmission stream status information sent by a terminal, whether to transmit multicast data to the terminal in a unicast manner; a multicast service control network element determining, with reference to other information, whether to use a multicast transmission manner or a unicast transmission manner; and upon receiving a first multicast session request, an access network node determining whether to accept the request).
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to provide the functionality of indicating or rejecting indicating, by a second core network node, establishment of a shared tunnel based on a state of a multicast session; or indicating, by a second core network node, establishment of a unicast tunnel based on existence of an access network node that does not support multicast in a multicast session; or rejecting indicating, by a second core network node, establishment of a unicast tunnel based on non-existence of an access network node that does not support multicast in a multicast session, as taught by Yang233, in the system of Yang, so as to provide a communications system, a communication method and an apparatus thereof, to achieve separation of a multicast service control function from a multicast transmission management function, thereby implementing flexible deployment of the service control function and the transmission management function, see Yang233, paragraphs 0006-0012.
As per claim 17, the combination of Yang and Yang233 disclose the method according to claim 15.
Yang722 further disclose wherein the indicating establishment of the shared tunnel comprises: sending an instruction for establishing the shared tunnel to the access network node through a first core network function; or sending the shared tunnel establishment request to the access network node (see para. 153-350, for establishing the shared tunnel to the access network node through a AF).
As per claim 18, the combination of Yang and Yang233 disclose the method according to claim 15.
Yang722 further disclose, wherein the rejecting indicating establishment of the shared tunnel comprises: sending an instruction for rejecting establishing the shared tunnel to the access network node through a first core network function; or rejecting sending the shared tunnel establishment request to the access network node (see para. 153-350, a multicast SMF determining, according to multicast transmission stream status information sent by a terminal, whether to transmit multicast data to the terminal in a unicast manner; a multicast service control network element determining, with reference to other information, whether to use a multicast transmission manner or a unicast transmission manner; and upon receiving a first multicast session request, an access network node determining whether to accept the request).
As per claim 19, the combination of Yang and Yang233 disclose the method according to claim 15.
Yang722 further disclose wherein the indicating establishment of a unicast tunnel comprises: sending an instruction for establishing a unicast tunnel to a first core network function (see para. 153-350, a multicast service control network element determining, with reference to other information, whether to use a multicast transmission manner or a unicast transmission manner; and upon receiving a first multicast session request, an access network node determining whether to accept the request).
As per claim 20, the combination of Yang and Yang233 disclose the method according to claim 15.
Yang722 further disclose wherein the rejecting indicating establishment of a unicast tunnel comprises: sending an instruction for rejecting establishing a unicast tunnel to a first core network function; or rejecting sending an instruction for establishing a unicast tunnel to a first core network function; wherein the instruction for establishing a unicast tunnel is further used to instruct the first core network function to send multicast service information associated with the unicast tunnel to the access network node (see para. 153-350, a multicast SMF determining, according to multicast transmission stream status information sent by a terminal, whether to transmit multicast data to the terminal in a unicast manner; a multicast service control network element determining, with reference to other information, whether to use a multicast transmission manner or a unicast transmission manner; and upon receiving a first multicast session request, an access network node determining whether to accept the request).
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over Yang (CN109699013A), in view of Yang722 (CN1112087722A) and further in view of Jia et al (US Pub. No.:2023/0188949).
As per claim 16, the combination of Yang and Yang233 disclose the method according to claim 15.
The combination of Yang and Yang233 however does not explicitly disclose wherein the indicating or rejecting indicating establishment of a shared tunnel based on a state of a multicast session comprises: in a case that the multicast session is in an active state, indicating establishment of the shared tunnel; or in a case that the multicast session is in an inactive state, rejecting indicating establishment of the shared tunnel.
Jia however disclose the indicating or rejecting indicating establishment of a shared tunnel based on a state of a multicast session comprises: in a case that the multicast session is in an active state, indicating establishment of the shared tunnel; or in a case that the multicast session is in an inactive state, rejecting indicating establishment of the shared tunnel (see para. 0218, That the status of the multicast/broadcast session is the active state (active or MBS session activation) may mean: The multicast/broadcast session is activated when a content provider starts/initiates/initiates multicast/broadcast session start/initiate (MBS session start or Session start), multicast/broadcast service session activation (MBS session activation), or multicast session activation; during an execution process of activating the multicast/broadcast session or after the multicast/broadcast session is activated, information related to the multicast/broadcast session is created on a terminal side and an access network device side, and the information related to the multicast/broadcast session is set to an active state (active) in the first session management function network element and/or the second session management function network element. Specifically, activation of the multicast/broadcast session may mean: Information related to the multicast/broadcast service (for example, QoS information related to the multicast/broadcast service) is created/allocated in a terminal; the information related to the multicast/broadcast service (for example, a context related to the multicast/broadcast service (for example, a multicast/broadcast context (MB context) or a multicast/broadcast service session context (MBS session context) or a multicast/broadcast group context (MB group context) or a multicast/broadcast service context (MBS context))) is created in the access network device; tunnel information related to the multicast/broadcast session is allocated; an air interface resource related to the multicast/broadcast session is allocated; information related to the multicast/broadcast service is established in a context of a terminal; a tunnel related to the multicast/broadcast session is established; information related to the multicast/broadcast service is set to an active state (active) in the first session management function network element and the second session management function network element).
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to provide the functionality of indicating or rejecting indicating, by a second core network node, establishment of a shared tunnel based on a state of a multicast session; or indicating, by a second core network node, establishment of a unicast tunnel based on existence of an access network node that does not support multicast in a multicast session; or rejecting indicating, by a second core network node, establishment of a unicast tunnel based on non-existence of an access network node that does not support multicast in a multicast session, as taught by Jai, in the system of Yang and Yang233, so as to implement continuity of the multicast service when a multicast/broadcast session is activated and deactivated, see Jai, paragraphs 0005-0010.
Allowable Subject Matter
Claims 1, 3 and 5-7 are allowed.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Ma (US Pub. No.:2023/0080042) – see para. 0006, “A method includes transmitting, by an access node to a network node in a core network, information requesting a multicast tunnel associated with a multicast and broadcast service. The method includes receiving, by the access node, information about a shared tunnel associated with the multicast and broadcast service that has been established for a neighboring access node. The method also includes transmitting, by the access node to the network node, a response indicating whether the shared tunnel is usable by the access node for the multicast and broadcast service”.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LAKERAM JANGBAHADUR whose telephone number is (571)272-1335. The examiner can normally be reached M-F 7 am - 4 pm.
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, Ian Moore can be reached at 571-272-3085. 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.
/LAKERAM JANGBAHADUR/Primary Examiner, Art Unit 2469