DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
This communication is considered fully responsive to the amendment filed on 08/15/2025. Claims 1-2, 12 and 21 have been amended and claims 5, 9-12, and 19 were previously canceled. Thus, claims 1-4, 6-8, 13-18, and 20-23 are pending in this application.
Objection to claims 2 and 21 are withdrawn since it has been amended accordingly.
Response to Arguments
Applicant’s arguments with respect to claims 1-4, 6-8, 13-18, and 20-23 filed on 08/15/2025 have been fully considered and are moot because the arguments related solely to amended limitations addressed in the instant Office Action with newly identified prior art, thus rendering applicant’s arguments moot.
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.
Claims 1, 4, 6, 13-18, 20, and 23 are rejected under 35 U.S.C. 103 as being unpatentable over GE et al (U.S. Patent Application Publication No. 2020/0374352, hereinafter “GE”) in view of GE et al (U.S. Patent Application Publication No. 2021/0112379, hereinafter “GE379”).
Examiner’s note: in what follows, references are drawn to GE unless otherwise mentioned.
With respect to Independent claims 1 and 13
Regarding claim 1, GE teaches A multicast service implementation method, performed by a first network function (Fig. 29; AMF entity) of a communications device (Fig. 22; session establishment device) and comprising:
receiving, from a terminal, a unicast session establishment request (para [0497]; when the terminal needs to be switched from a broadcast path to a unicast path, steps in this embodiment may be performed.)(para [0498]; First, when the terminal determines that the terminal fails to receive broadcast data, the terminal sends the broadcast quality report message (interpreted as “a unicast session establishment request”) to an AMF entity. … The PDU session establishment request message in the broadcast quality report message represents a request for establishing the PDU session.)
(The missing/crossed out limitation will be discussed in view of GE379)
executing a unicast session establishment procedure to establish a unicast session connection to the terminal (para [0500]; the AMF entity may send, to the terminal, the PDU session establishment response message that carries the information about the QoS flow corresponding to the PDU session.)(para [0509]; Therefore, signaling interaction between the terminal and a network side can be reduced, a delay of switching from the broadcast path to the unicast path can be reduced, and the PDU session can be quickly established.)(para [0206]; broadcast received quality information reported by a terminal, to complete switching from broadcast transmission to unicast transmission.);
transmitting, to the terminal, data content of a multicast service through the unicast session connection (para [0271]; When the terminal receives downlink data through a broadcast path, the terminal needs to be switched from the broadcast path to a unicast path. In a first case, when the terminal enters a broadcast receive mode, for example, when the terminal enters the broadcast receive mode starting from pre-configuration startup, the terminal may start to receive broadcast data. When broadcast received quality is poor, a network entity on a network side needs to switch a receive transmission mode of the terminal to a unicast transmission mode. In other words, the terminal is switched from the broadcast path to the unicast path. (interpreted as “transmitting, to the terminal, data content of a multicast service through the unicast session connection”, see paragraphs [0074-0075] of Applicant’s specification );
wherein the first network function is an Access and Mobility Management Function (AMF) or Session Management Function (SMF) (para [0498]; First, when the terminal determines that the terminal fails to receive broadcast data, the terminal sends the broadcast quality report message to an AMF entity (interpreted as “the first network function”).).
GE does not explicitly teach the above recited feature “a unicast session establishment request carrying a multicast Internet Protocol (IP) address, or a Temporary Mobile Group Identifier (TMGI) of a multicast service” of claim 1.
However, in analogous art, GE379 teaches the “a unicast session establishment request carrying a multicast Internet Protocol (IP) address, or a Temporary Mobile Group Identifier (TMGI) of a multicast service” (para [0223] of GE379: The terminal sends a first request message to an AMF.)(para [0224]: Correspondingly, the AMF receives the first request message from the terminal.)(para [0226] of GE379: The first request message (interpreted as “a unicast session establishment request”) may be used to request to switch from a multicast mode to a unicast mode to transmit target data. ) (para [0227] of GE379: the first request message may include an identifier of the source multicast transmission path, and may further include an identifier of the target unicast transmission path.) (para [0233] of GE379: The AMF may send the first request message to the first core network device based on the identifier that is of the source multicast transmission path and that is in the first request message (interpreted as “a multicast Internet Protocol (IP) address”)).
Further, GE379 defines in paragraphs [0115 and 0117] that the identifier of the source multicast transmission path included in the first request message of GE379 is Temporary Mobile Group Identifier (TMGI). See paragraphs [0115 and 0117] of GE379.
[0115] For ease of understanding of the technical solutions in the embodiments of this application, brief descriptions of related content in this application are first provided.
…
[0117] A multicast transmission path is a downlink transmission path used by a DN to transmit same user plane data to a group of users. The multicast transmission path may be a data flow corresponding to a multicast session (for example, an MBMS session)… The multicast transmission path may be identified by using a multicast transmission path identifier. For example, the multicast transmission path identifier may be a temporary group identity (TMGI), or may be a combination of a TMGI and a flow identity (flow ID). The multicast transmission path may also be referred to as a multicast bearer (such as an MBMS bearer), a group flow, or a multicast flow. For ease of description, in subsequent embodiments of this application, the multicast transmission path is used as an example for description. A group of users includes a plurality of users, and may usually be obtained through division based on a service area. For example, terminals in an administrative region B of a city A may be a group of users.
Based on the descriptions of a multicast transmission path identifier provided in para [0117] of GE379, “the multicast transmission path identifier may be a temporary group identity (TMGI), or may be a combination of a TMGI and a flow identity (flow ID)” is interpreted as the claimed feature of “a Temporary Mobile Group Identifier (TMGI) of a multicast service”.
Thus, GE 379 discloses the claimed feature “receiving, from a terminal, a unicast session establishment request carrying a multicast Internet Protocol (IP) address, or a Temporary Mobile Group Identifier (TMGI) of a multicast service”.
GE and GE379 are both considered to be analogous to the claimed invention because they are in the same field of PDU session establishment method and device and are filed by same inventors. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified GE to incorporate the teachings of GE379 in order to provide the Unicast session establishment request carrying a multicast Internet Protocol (IP) address, or a Temporary Mobile Group Identifier (TMGI) of a multicast service. Doing so would quickly initiate a unicast session and establish a unicast transmission path in a timely manner, to quickly switch downlink data for the terminal from a broadcast path to a unicast path is a problem that needs to be resolved. (see para [0005] of GE and para [0006] of GE379).
Regarding claim 13, it is a multicast service implementation method, performed by a terminal (Fig. 31; Terminal device), corresponding to the method claim 1 and is therefore rejected for the similar reasons set forth in the rejection of claim 1.
With respect to dependent claims:
Regarding Claim 4, GE and GE379 teach The multicast service implementation method according to claim 1, GE379 further teaches wherein the request further comprises any one of the following:
a multicast session establishment request (para [0227] of GE379: the first request message may include an identifier of the source multicast transmission path (interpreted as “a multicast session establishment request”) (para [0233] of GE379: The AMF may send the first request message to the first core network device based on the identifier that is of the source multicast transmission path and that is in the first request message.)(para [0234] of GE379: the AMF may send, to a UDM or a PCF, a request message that carries the identifier of the source multicast transmission path. The request message is used to request information about the control plane session management network element that manages the source multicast transmission path.); or
a first data packet for requesting to join a multicast group (para [0227] of GE379: the first request message may include an identifier of the source multicast transmission path (interpreted as “a first data packet for requesting to join a multicast group” ).
Regarding Claim 6, GE and GE379 teach The multicast service implementation method according to claim 1, GE379 further teaches wherein the request is sent to the first network function through a signaling path (Fig. 1 and para [0085] of GE379: The AMF serves as an anchor for N1 and N2 signaling connections, provides the SMF with routing of a session management (SM) message through an N1/N2 interface, and maintains and manages status information of the terminal)( Fig. 7A and para [0217] of GE379: 701. A terminal establishes a PDU session with a network side.)( Fig. 7A and para [0223] of GE379: 703. The terminal sends a first request message to an AMF.); or the request is sent to the first network function through a user-plane path Fig. 1 and para [0085] of GE379: The AMF serves as an anchor for N1 and N2 signaling connections, provides the SMF with routing of a session management (SM) message through an N1/N2 interface, and maintains and manages status information of the terminal) (Fig. 7A and para [0217] of GE379: 701. A terminal establishes a PDU session (interpreted as “a user-plane path” ) with a network side.).
Regarding Claim 14, Claim 14, has similar limitation as of Claim(s) 4, therefore it is rejected under the same reasons as Claim(s) 4.
Regarding Claim 15, GE and GE379 teach The multicast service implementation method according to claim 13, wherein the executing a unicast session establishment procedure comprises any one of the following: GE379 further teaches:
receiving a notification for establishing a unicast session connection (para [0023] of GE379: A terminal sends a request message to a first core network device, where the request message is used to request to switch from a multicast mode to a unicast mode to transmit service data to be sent to the terminal. The terminal receives a response message of the request message from the first core network device.) (para [0026] of GE379: the response message includes an identifier of a unicast transmission path corresponding to the terminal (interpreted as “a notification for establishing a unicast session connection” ). In the possible embodiment, the terminal can determine the unicast transmission path for receiving the service data to be sent to the terminal, to correctly receive the service data.);
initiating establishment of a unicast session connection (para [0026] of GE379: the terminal can determine the unicast transmission path for receiving the service data to be sent to the terminal, to correctly receive the service data.); or,
completing a unicast session establishment procedure (para [0026] of GE379: the terminal can determine the unicast transmission path for receiving the service data to be sent to the terminal, to correctly receive the service data.).
Regarding Claim 16, Claim 16 has similar limitation as of Claim(s) 6, therefore it is rejected under the same reasons as Claim(s) 6.
Regarding Claim 17, GE and GE379 teach The multicast service implementation method according to claim 13, GE further teaches further comprising receiving at least one of the following information from the first network function:
second indication information indicating whether a user is in a multicast service group (para [0249]; a format of the SM response message (interpreted as “a first invocation result”) is … N1 SM information (PDU session establishment accept (authorized QoS rule, SSC mode, S-NSSAI, allocated IPv4 address))(the N1 SM information is interpreted as “second indication information”))(para [0234]; the UDM entity sends a subscription data response (subscription data response) message to the SMF entity…. Then, the SMF entity performs an authorization check on the subscription information(the authorization check is interpreted as “whether a user is in a multicast service group”)); or, a failure cause. (para [0248]; S110. The SMF entity sends an SM response message (interpreted as “a first invocation result”) to the AMF entity.)(para [0249]; a format of the SM response message is (cause, N2 SM information (PDU session ID, QoS profile(s), CN tunnel info), N1 SM information))(Examiner’s note: The “cause” is interpreted as “indicates that a multicast session connection has failed to be established”, see para [0260-0263]; Specifically, if an N4 session (N4 session) is not established,… The SMF entity sends an SM response message to the AMF entity. Specifically, the SM response (SM response) message includes a cause value cause.)).
Regarding Claim 18, GE and GE379 teach A communications device (Fig. 29, AMF Entity), comprising a processor(Fig. 29, Processor 2901), a memory (Fig. 29, Memory 2902), and a program stored in the memory and running on the processor, wherein when the processor executes the program, the steps of the multicast service implementation method according to claim 1 are implemented (para [0160]; The AMF entity includes a processor and a memory. The memory is configured to store a computer program, and the processor invokes the computer program stored in the memory to perform any method).
Regarding Claim 20, GE and GE379 teach A communications device (Fig. 28, Terminal device), comprising a processor (Fig. 28, Processor 2801), a memory (Fig. 28, Memory 2802), and a program stored in the memory and running on the processor, wherein when the processor executes the program, the steps of the multicast service implementation method according to claim 13 are implemented (para [0150]; The terminal device includes a processor and a memory. The memory is configured to store a computer program, and the processor invokes the computer program stored in the memory to perform any method).
Regarding Claim 23, GE and GE379 teach The multicast service implementation method according to claim 13, further comprising:
receiving, from the first network function, second indication information indicating that a user is not in a multicast service group. (para [0234]; the UDM entity sends a subscription data response (subscription data response) message to the SMF entity…. Then, the SMF entity performs an authorization check on the subscription information… If the SMF entity determines that the authorization check fails , the SMF entity sends NAS signaling to the terminal. The NAS signaling indicates that a session establishment request of the terminal is rejected (interpreted as “second indication information indicating that a user is not in a multicast service group”))..
Claims 2-3, 7-8, and 21-22 are rejected under 35 U.S.C. 103 as being unpatentable over GE in view of GE379, and further in view of Zhu et al. (U.S Patent Application Publication No 2020/0267513; hereinafter “Zhu”).
With respect to Independent claim 21
Regarding claim 21, GE teaches A multicast service implementation method, comprising:
receiving, by a Session Management Function (SMF) from a user equipment (UE), a unicast session establishment request (para [0497]; when the terminal needs to be switched from a broadcast path to a unicast path, steps in this embodiment may be performed.)(para [0511]; 501. The terminal sends a broadcast quality report message (interpreted as “a unicast session establishment request”) to an SMF entity, where the broadcast quality report message is used to request to establish a PDU session.) (The missing/crossed out limitation will be discussed in view of GE379)
GE does not explicitly teach the above recited feature “a unicast session establishment request carrying a multicast Internet Protocol (IP) address, or a Temporary Mobile Group Identifier (TMGI) of a multicast service”.
However, in analogous art, GE379 teaches the “a unicast session establishment request carrying a multicast Internet Protocol (IP) address, or a Temporary Mobile Group Identifier (TMGI) of a multicast service” (para [0132]: A terminal sends a first request message(interpreted as “a unicast session establishment request”) to a first core network device based on receiving quality of the terminal on a multicast transmission path.)(para [0133] of GE379: the terminal may include, in the first request message, an identifier of a multicast transmission path on which receiving quality meets a preset condition, and information about receiving quality on the multicast transmission path, so that the first core network device determines a source multicast transmission path.)(para [0137] of GE379: When functions of the MBMS session management unit are integrated into an SMF, the first core network device may be the SMF.)(para [0117] of GE379: the multicast transmission path identifier may be a temporary group identity (TMGI), or may be a combination of a TMGI and a flow identity (flow ID) (interpreted as “a multicast Internet Protocol (IP) address, or a Temporary Mobile Group Identifier (TMGI) of a multicast service”)).
GE and GE379 are both considered to be analogous to the claimed invention because they are in the same field of PDU session establishment method and device and are filed by same inventors. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified GE to incorporate the teachings of GE379 in order to provide the Unicast session establishment request carrying a multicast Internet Protocol (IP) address, or a Temporary Mobile Group Identifier (TMGI) of a multicast service. Doing so would quickly initiate a unicast session and establish a unicast transmission path in a timely manner, to quickly switch downlink data for the terminal from a broadcast path to a unicast path is a problem that needs to be resolved. (see para [0005] of GE and para [0006] of GE379);
A combination of GE and GE379 does not explicitly teach about the claimed features of: invoking, by the SMF, a multicast context user delete operation of a Multicast Broadcast Session Function (MBSF) serving the multicast service; invoking, by the MBSF, a user delete authorization of a Multicast Broadcast Policy Control Function (MBPCF); returning, by the MBPCF, a user delete authorization response to the MBSF; sending, by the MBSF, the multicast context user delete response to the SMF; and establishing, by the SMF, the unicast session.
However, Zhu teaches the missing claimed features:
invoking, by the SMF, a multicast context user delete of a Multicast Broadcast Session Function (MBSF) serving a multicast service indicated by the multicast service information (para [0288] of Zhu; The RAN device sends, to the management device (for example, the SMF) having the multicast service management function, a message (interpreted as “multicast service information”) for requesting to terminate the first multicast service.);
invoking, by the MBSF, a user delete authorization of a Multicast Broadcast Policy Control Function (MBPCF) (para [0174] of Zhu; the AMF, SMF, and PCF (“a policy control function”) may be combined together as a management device to implement access control and mobility management functions such as access authentication, security encryption, and location registration of the terminal device, session management functions such as establishment, release, and change of a user plane transmission path, and functions such as analysis of slice-related data (such as congestion) and terminal device-related data.) (para [0288] of Zhu; The RAN device sends, to the management device (for example, the SMF) having the multicast service management function, a message for requesting to terminate the first multicast service (interpreted as “invoking … a user delete authorization”));
returning, by the MBPCF, a user delete authorization response to the MBSF (para [0294] of Zhu; The SMF maintains the network-level multicast member list based on the fourth report message. For understanding of the network-level multicast member list maintained by the SMF, refer to descriptions in operation 208.)(para [0295] of Zhu; That the SMF maintains the network-level multicast member list based on the fourth report message may include: For example, the SMF reads the identifier of first multicast service and the identifier corresponding to the first terminal device that are included in the fourth report message, where the fourth report message optionally further includes the identifier of the second terminal device; and the SMF updates the network-level multicast member list (Examiner’s note: As disclosed in para [0174] of Zhu, the AMF, SMF, and PCF are combined together as a management device (having the multicast service management function), to implement access control and mobility management functions such as access authentication. The updating the network-level multicast member list disclosed in para [0295] of Zhu are internal operations of the management device including AMF, multicast service management function, SMF, and PCF, and are therefore interpreted as “returning, by the MBPCF, a user delete authorization response to the MBSF”), that is, deletes an information entry corresponding to both the first terminal device and the first multicast service from the network-level multicast member list, or invalidates an information entry corresponding to both the first terminal device and the first multicast service.);
sending, by the MBSF, the multicast context user delete response to the SMF (para [0295] of Zhu; That the SMF maintains the network-level multicast member list based on the fourth report message may include: For example, the SMF reads the identifier of first multicast service and the identifier corresponding to the first terminal device that are included in the fourth report message, where the fourth report message optionally further includes the identifier of the second terminal device; and the SMF updates the network-level multicast member list, that is, deletes an information entry corresponding to both the first terminal device and the first multicast service from the network-level multicast member list (Examiner’s note: As noted above, The updating the network-level multicast member list disclosed in para [0295] of Zhu are internal operations of the management device including AMF, multicast service management function, SMF, and PCF, and are therefore interpreted as “sending, by the MBSF, the multicast context user delete response to the SMF”:), or invalidates an information entry corresponding to both the first terminal device and the first multicast service.);
establishing, by the SMF, the unicast session (para [0306] of Zhu; the SMF instructs, based on the fourth report message, the UPF to remove the multicast connection and maintain the network-level multicast member list.)(para [0307] of Zhu; The UPF receives the data packet of the multicast service from the network device, replicates the data packet of the multicast service, and sends, in a unicast mode and according to the QoS rule configured by the SMF (interpreted as “establishing, by the SMF, the unicast session”), the data packet of the multicast service to the terminal device by using the RAN device.).
GE, GE379 and Zhu are considered to be analogous to the claimed invention because they are in the same field of PDU session establishment method and device. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of GE and GE379 to incorporate the teachings of Zhu in order to provide the invoking a multicast context user deletion of a multicast service. Doing so would quickly initiate a unicast session and establish a unicast transmission path in a timely manner, to quickly switch downlink data for the terminal from a broadcast path to a unicast path is a problem that needs to be resolved. (see para [0005] of GE, para [0006] of GE379 and para [0374] of Zhu).
With respect to dependent claims:
Regarding Claim 2, GE and GE379 teach The multicast service implementation method according to claim 1, further comprising:
sending a first invocation parameter to a second network function (para [0229]; S13. The AMF entity sends an SM request message (interpreted as “first invocation parameter”) to the SMF entity (interpreted as “a second network function”))(para [0230]; … The SM request message includes a subscriber permanent identifier (subscriber permanent ID), the DNN, the S-NSSAI, the PDU session identifier, the N1 SM information, user location information (user location information), and an access technology type (access technology type).), (The missing/crossed out limitation will be discussed in view of Zhu)
wherein in case that the first network function is the AMF, the second network function is a multicast broadcast session function (MBSF), or, a SMF and MBSF (para [0229]; S13. The AMF entity sends an SM request message to the SMF entity.) (para [0206]; the SMF entity may be responsible for broadcast session management (interpreted as “the second network function is a multicast broadcast session function (MBSF), or, a SMF and MBSF”), including establishment, update, and release of a broadcast session, allocation of a broadcast session identifier, and the like. In this application, the SMF entity may further receive broadcast received quality information reported by a terminal, to complete switching from broadcast transmission to unicast transmission.) … ; and
receiving a first invocation result from the second network function (para [0248]; S110. The SMF entity (interpreted as “a second network function”) sends an SM response message (interpreted as “a first invocation result”) to the AMF entity.), wherein the first invocation result indicates that a multicast session connection has failed to be established (para [0249]; the SM response (SM response) message includes a cause value (cause), N2 reference point session management information (N2 SM information), and N1 SM information. … The N1 SM information includes a PDU session establishment accept (PDU session establishment accept) message, and the PDU session establishment accept message includes an authorized quality of service rule (authorized QoS rule), the SSC mode, the S-NSSAI, and the IPv4 address (allocated IPv4 address))(Examiner’s note: The “cause” is interpreted as “indicates that a multicast session connection has failed to be established”, see para [0260-0263]; Specifically, if an N4 session (N4 session) is not established,… The SMF entity sends an SM response message to the AMF entity. Specifically, the SM response (SM response) message includes a cause value cause.)…).).
The combination of GE and GE379 does not explicitly teach about “wherein the first invocation parameter is used for invoking a multicast session context user delete operation of the second network function”.
However, Zhu teaches the claimed “wherein the first invocation parameter is used for invoking a multicast session context user delete operation of the second network function” (para [0518] of Zhu; the RAN device receives the fourth report message sent by the first terminal device. The fourth report message is a message (for example, an IGMP leave report) for the first terminal device to request to terminate the first multicast service,)(para [0520] of Zhu; the AMF sends, to the SMF through, for example, an N11 interface, the message (interpreted as “first invocation parameter”) that the RAN device requests to terminate the first multicast service (interpreted as “used for invoking a multicast session context user delete operation of the second network function”),)
GE, GE379 and Zhu are considered to be analogous to the claimed invention because they are in the same field of PDU session establishment method and device. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of GE and GE379 to incorporate the teachings of Zhu in order to provide the sending a first invocation parameter to a second network function for invoking a multicast session context user delete operation of the second network function. Doing so would quickly initiate a unicast session and establish a unicast transmission path in a timely manner, to quickly switch downlink data for the terminal from a broadcast path to a unicast path is a problem that needs to be resolved. (see para [0005] of GE, para [0006] of GE379 and para [0374] of Zhu).
Regarding Claim 3, GE, GE379 and Zhu teach The multicast service implementation method according to claim 2, GE further teaches wherein the first invocation parameter comprises a user identifier of the terminal and the multicast service information (para [0230]; The SM request message (interpreted as “first invocation parameter”) includes a subscriber permanent identifier (subscriber permanent ID), the DNN, the S-NSSAI, the PDU session identifier, the N1 SM information, user location information (user location information), and an access technology type (access technology type).)(para [0311]; the SM request message is represented by using an SM request, and a format of the SM request is an SM request (PDU session establishment request, UE ID), session establishment assistance information ([broadcast session ID (or group identifier)]), [PDU session ID]).).
Regarding Claim 7, GE, GE379 and Zhu teach The multicast service implementation method according to claim 2, GE further teaches wherein the first invocation result further comprises at least one of the following:
second indication information indicating whether a user is in a multicast service group (para [0249]; a format of the SM response message (interpreted as “a first invocation result”) is … N1 SM information (PDU session establishment accept (authorized QoS rule, SSC mode, S-NSSAI, allocated IPv4 address))(the N1 SM information is interpreted as “second indication information”))(para [0234]; the UDM entity sends a subscription data response (subscription data response) message to the SMF entity…. Then, the SMF entity performs an authorization check on the subscription information(the authorization check is interpreted as “whether a user is in a multicast service group”)); or, a failure cause. (para [0248]; S110. The SMF entity sends an SM response message (interpreted as “a first invocation result”) to the AMF entity.)(para [0249]; a format of the SM response message is (cause, N2 SM information (PDU session ID, QoS profile(s), CN tunnel info), N1 SM information))(Examiner’s note: The “cause” is interpreted as “indicates that a multicast session connection has failed to be established”, see para [0260-0263]; Specifically, if an N4 session (N4 session) is not established,… The SMF entity sends an SM response message to the AMF entity. Specifically, the SM response (SM response) message includes a cause value cause.)…).)
Regarding Claim 8, GE, GE379 and Zhu teach The multicast service implementation method according to claim 7, further comprising: GE further teaches
sending the failure cause and/or the second indication information to the terminal (para [0301]; If the SMF entity determines that the authorization check fails, the SMF entity sends NAS signaling to the terminal. The NAS signaling indicates that a session establishment request of the terminal is rejected.).
Regarding Claim 22, GE, GE379 and Zhu teach The multicast service implementation method according to claim 2, GE further teaches
wherein the first invocation result further comprises second indication information indicating that a user is not in a multicast service group (para [0249]; a format of the SM response message (interpreted as “a first invocation result”) is … N1 SM information (PDU session establishment accept (authorized QoS rule, SSC mode, S-NSSAI, allocated IPv4 address))(the N1 SM information is interpreted as “second indication information”))(para [0234]; the UDM entity sends a subscription data response (subscription data response) message to the SMF entity…. Then, the SMF entity performs an authorization check on the subscription information… If the SMF entity determines that the authorization check fails , the SMF entity sends NAS signaling to the terminal. The NAS signaling indicates that a session establishment request of the terminal is rejected (interpreted as “second indication information indicating that a user is not in a multicast service group”)).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to WON JUN CHOI whose telephone number is (703)756-1695. The examiner can normally be reached MON-FRI 08:00 - 17:00.
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, Derrick W Ferris can be reached at 571-272-3123. 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.
/WON JUN CHOI/Examiner, Art Unit 2411
/DERRICK W FERRIS/Supervisory Patent Examiner, Art Unit 2411