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 Arguments
Applicant's arguments filed November 6, 2025 have been fully considered but they are not persuasive.
On pages 2-3 of the remarks, Applicant states that claims 1, 3, 5-6, 8, 10, 12-15, 17-19, and 21 were rejected under U.S.C. 103 as being unpatentable over Zee et al. (US 10893455 A1), hereinafter Zee in view of Karampatsis (WO 2024088573), with Applicant stating that Zee and Karampatsis fails to disclose, teach, or suggest the amended limitations of “associating a connection identifier with a network slice identifier based on mapping a traffic category […] to another traffic category associated with the connection identifier, wherein the other traffic category is a throughput category is a throughput traffic category or a latency traffic category”, as per amended claim 1. Applicant states that Zee, column 18, lines 20-38 and column 22, lines 41-52 allegedly discloses the amended limitation, while restating Zee’s column 18, lines 20-38, and merely restating that the references of Zee and Karampatsis do not teach or suggest the amended limitation, with the independent claims 1, 8, and 14 being patentable over the prior art.
Examiner disagrees, as Examiner points out that the amended portion of “[…] wherein the other traffic category is a throughput category is a throughput traffic category or a latency traffic category” of the independent claims 1, 8, and 14 can be found within the reference of Zee, as the section of [Col. 4, lines 29-35] states that 5G communications can be used for an ultra-low latency use case, with [Col. 5, lines 19-30], a network slice being a type of communication service at an acceptable latency as a requirement can be used for a user device, corresponding to the other traffic category being a latency traffic category of the Applicant, which in this scenario, is an ultra-low latency traffic category, such as for high-speed entertainment or mobility on-demand for connected devices. As a result, the independent claims 1, 8, and 14 remain rejected under U.S.C. 103 as being unpatentable over Zee in view of Karampatsis.
Finally, in page 3 of the remarks, claims 2, 4, and 7 depend from independent claim 1, claim 11 depends from independent claim 8, and claims 16 and 20 depend on independent claim 14. Applicant states that, as a result, the aforementioned claims are patentable for at least the reasons set forth above with respect to claims 1, 8, and 14, as amended.
Examiner maintains the rejection on independent claim 1, and independent claims 8 and 14 recite similar claim limitations, and therefore, stand rejected. The dependent claims inherit the deficiencies of their respective independent claims, and therefore, the rejections are also maintained as a result. Furthermore, the amended portion of dependent claim 17, which includes “wherein the network slice identifier corresponds to the traffic category associated with the new service”, is disclosed by Zee in the section [Col. 18, lines 19-22] Fig. 10, action 1003, where the indicating of a slice ID corresponds to the network slice identifier during a connection setup of a wireless device to the network slice, which is a new service to connect to the wireless device. A connection of a wireless device to the network slice is a new service being run by the device, and as a result, Zee discloses the amendments made in dependent claim 17.
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.
Claim(s) 1, 3, 5-6, 8, 10, 12-15, 17-19, and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Zee et al. (US 10893455 A1), hereinafter Zee, in view of Karampatsis et al. (WO 2024088573, using the translated English document), hereinafter Karampatsis.
Regarding claim 1, Zee discloses ‘a method, comprising: receiving, at a network device and from a cloud computing service, an indication associating a connection identifier with a network slice identifier based on mapping a traffic category associated with the network slice identifier to another traffic category associated with the connection identifier, wherein the other traffic category is a throughput traffic category or a latency traffic category’ ([Col. 18, lines 19-29] Fig. 10, wherein the Indicating of a slice ID corresponds to the network slice identifier. The core network node 19 corresponds to the cloud computing service of the applicant. The indicating of the slice ID the wireless device 10 supports corresponds to the connection identifier, which in this scenario, is the device type identifier, as stated in [page 15, lines 1-2] from the applicant. [Col. 18, lines 19-29] Fig. 10, radio network node 12 corresponds to a network device of the Applicant, which obtains an indication from a core network node 19. [Col. 18, lines 20-38] “UE context information implicitly provides the UE context ID”, where the slice ID, corresponding to a network slice identifier's traffic category of the Applicant, is known to a core network node to the wireless device context, where ‘UE context information’ is provided in step 1211b in Fig. 12, or its equivalent, a ‘target slice ID’ in step 1111b in Fig. 11, in which the ‘target slice ID’ corresponds to another traffic category associated with a connection identifier, as the ‘target slice ID’ can also be an equivalent slices that a UE can connect to, as stated in [Col. 22, lines 41-52]. The first radio network node 12 correlating the slice ID and a slice ID of a UE context ID/’target slice ID’ corresponds to the mapping of the Applicant. Furthermore, [Col. 18, lines 19-22] Fig. 10, action 1003, where the indicating of a slice ID corresponds to the network slice identifier, and as stated by [Col. 5, lines 19-30], a network slice corresponds to a different type of communication service at an acceptable latency as a requirement, to which a network slice identifier can be used to indicate, such as a 5G ultra-low latency use case in [Col. 4, lines 29-35].);
‘storing, at the network device, the indication’ ([Col. 30, lines 57-63] Where the first radio network node 12 stores the slice indication, wherein the indication includes both the connection identifier and the slice IDs stated earlier in Zee [Col. 18, lines 19-29].);
‘receiving, from a network operator, a request including the connection identifier’ ([Col. 25, line 62-Col. 26, line 3] Fig. 13, action 1303, wherein the core network node 19, corresponding to the network operator, sends a support indication, corresponding to the request of the applicant, includes the slice ID the wireless device 10 supports, which contains information regarding the identification of the wireless device 10.);
‘and transmitting, to the network operator, the network slice identifier in response to the request’ ([Col. 32, lines 21-27] Fig. 18, where the network slice and network combination indication corresponds to the network slice identifier when it comes to what network slices are available and for use by the wireless device 10 of a user and/or the network, and a core network node 19 sends an indication as a list of combination of networks and network slices equivalent to network slice associated with a wireless device 10 at a first radio network node 12, corresponding to a network slice identifier of the applicant.).
Zee does not appear to disclose, but Karampatsis teaches the limitations of ‘wherein a network slice associated with the network slice identifier is provisioned based on at least one user equipment route selection policy (URSP) rule that is generated by the network operator’ ([0146] PCF determines at least one URSP rule for a UE, and the at least one URSP rule considers availability information of a network slice, and when the network slice is available, the UE can connect via the network slice. [0148] PCF can generate URSP rule, and the PCF can be further configured via policies of a network operator, and as a PCF is part of a network, the limitation corresponds to a URSP rule that is generated by the network operator, as stated by the Applicant.);
and ‘wherein the network slice includes at least a first network function that is associated with the network operator and a second network function that is associated with the cloud computing service’ ([0003] Network slice can include a core network (5GC, 5G core network), control plane, and user plane network functions (NFs), and an access network, such as a 5G radio access network, or 5G RAN. [0033] Radio access network can be coupled to one or more core networks, which in turn can be coupled to other networks, such as the Internet. With paragraph [0032] stating what devices can be connected to a network, such as mobile devices or television sets, and with paragraph [0060] stating that network slices provide network connectivity towards customers or application service providers, it can be determined that a 5G core network can correspond to an application service provider, and a service provider can correspond to a cloud computing service of the applicant. [0102] Control plane can include a UE, AMF, SMF, PCF, and other functions that are related to a network device of Karampatsis. [0148] PCF function can consider further locally configured policies from a network operator along with a received slice availability information for a network slice, and the PCF considering policies from a network operator can correspond to a network function being associated with a network operator of the applicant.).
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Zee and Karampatsis before them, to include Karampatsis’s ‘wherein a network slice associated with the network slice identifier is provisioned based on at least one user equipment route selection policy (URSP) rule’, and ‘wherein the network slice includes at least a first network function that is associated with the network operator and a second network function that is associated with the cloud computing service’ in Zee’s method performing ‘receiving, from a cloud computing service, an indication associating a connection identifier with a network slice identifier’, and other functions in claim 1. One would have been motivated to make such a combination to increase efficiency as having multiple network functions can be performed with a transceiver, which operates under the control of a processor to transmit messages, data, and other signals, and receive the aforementioned elements as well, as stated in paragraph [0046], and when a PCF 630 considers URSP rules and sends the URSP rules to a UE 620 to match with a corresponding S-NSSAI, then UE 620 does not need to request registration to the S-NSSAI when the network slice is not available, as taught by Karampatsis [0123].
Zee discloses the limitation of the cloud computing service as a core network node 19, as stated in [Col. 18, lines 19-29] of Zee. Zee does not disclose the limitation of, but Karampatsis teaches the limitation of ‘wherein the network device is between the cloud computing service and the network operator’ ([0148] Figs. 6, Policy Control Function (PCF) 630 corresponds to a network device, which is located between a network operator, corresponding to the network operator device of claim 1, which is not shown in the figures, and an access node 622. The network operator can define various aspects of a PCF for the function to consider, which puts a PCF in between a network operator.).
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Zee and Karampatsis before them, to include Karampatsis’s ‘wherein the network device is between the cloud computing service and the network operator’ in Zee’s method performing ‘receiving, from a cloud computing service, an indication associating a connection identifier with a network slice identifier’, and other functions in claim 1. One would have been motivated to make such a combination to increase efficiency by having a network operator configure a network slice by deploying homogenously in a tracking area (TA), which can be performed with functions of a network device including the policy control function (PCF) component, as stated by Karampatsis [0064].
Regarding claim 3, Zee in view of Karampatsis teaches the elements of claim 1 as outlined above. Zee does not appear to disclose ‘wherein receiving the indication comprises: transmitting, to the cloud computing service, a request for an application programming interface (API) subscription, wherein the indication is included in a push communication received by the network device based on the API subscription’.
However, Karampatsis teaches ‘wherein receiving the indication comprises: transmitting, to the cloud computing service, a request for an application programming interface (API) subscription, wherein the indication is included in a push communication received by the network device based on the API subscription’ ([0013] The PCF, or policy control function, corresponds to the cloud computing service, and the subscription data and policy data corresponds to the subscription for an API. [0129] Fig. 7, a UDM, or Unified Management Function, may subscribe to an AMF 714, or Access and Mobility Management Function, for notifications on when network slice availability changes for any S-NSSAI, wherein the notifications could be push notifications, and the AMF corresponds to the API for the subscriptions, and the UDM is part of the network device.).
Accordingly, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the invention, having the teachings of Zee and Karampatsis before them, to include Karampatsis’s ‘wherein receiving the indication comprises: transmitting, to the cloud computing service, a request for an application programming interface (API) subscription, wherein the indication is included in a push communication received by the network device based on the API subscription’ in Zee’s method performing receiving from a cloud computing service, an indication associating a connection identifier with a network slice identifier. One would have been motivated to make such a combination to increase efficiency such that the "method may further comprise subscribing with the AMF for notification for the UE presence in an area of interest and receiving notifications from the AMF when the UE is within the area of interest", which will assist in notifying the user when it is capable of communicating with the network, and the user will be able to connect to the service with little hassle and guesswork regarding the availability of a service, as taught by Karampatsis [0195].
Regarding claim 5, Zee in view of Karampatsis teaches the method of claim 1, as recited above. Zee also discloses wherein the connection identifier comprises a device type indicator, an Internet protocol (IP) address, or a port ([Col. 18, lines 19-22] Fig. 10, action 1003, where the indicating the slice ID the wireless device supports corresponds to the connection identifier, which in this scenario, is the device type identifier, as stated in [page 15, lines 1-2] from the applicant.).
Regarding claim 6, Zee in view of Karampatsis teaches the method of claim 1, as recited above. Zee also discloses wherein the network slice identifier comprises a traffic category indicator or single network slice selection assistance information (S-NSSAI) ([Col. 18, lines 19-22] Fig. 10, action 1003, where the indicating of a slice ID corresponds to the network slice identifier, and as stated by [Col. 5, lines 27-30], a network slice corresponds to a different type of communication service, to which a network slice identifier can be used to indicate.).
Regarding claim 8, Zee discloses ‘a device, comprising: one or more processors configured to: receive, from a user device, a connection request including a connection identifier’ ([Col. 18, lines 19-29] Fig. 10, wherein the Indicating of a slice ID corresponds to the network slice identifier. The core network node 19 corresponds to the cloud computing service of the applicant. The indicating of the slice ID the wireless device 10 supports corresponds to the connection identifier, which in this scenario, is the device type identifier and can correspond to a connection request of a user device.);
‘transmit, to a network device, a request for network slice information associated with the connection identifier’ ([Col. 25, line 64-Col. 26, line 3] Fig. 13, action 1303, where the core network node 19, corresponding to the network operator, sends a support indication, which corresponds to the request, includes the slice ID the wireless device 10 supports, which has information regarding the identification of the wireless device 10.);
‘receive, from the network device, a network slice identifier in response to the request, wherein the connection identifier is associated with the network slice identifier based on mapping a traffic category associated with the network slice identifier to another traffic category associated with the connection identifier, wherein the other traffic category is a throughput traffic category or a latency traffic category’ ([Col. 7, lines 17-28] First radio network node 12 transmits a message comprising information indicating one or more slice identities supported by the first radio network node to another network node, and can transmit a slice identifier to a wireless device of a user to setup the connection to a radio network node. [Col. 18, lines 19-29] Fig. 10, wherein the Indicating of a slice ID corresponds to the network slice identifier. The core network node 19 corresponds to the cloud computing service of the applicant. The indicating of the slice ID the wireless device 10 supports corresponds to the connection identifier, which in this scenario, is the device type identifier, as stated in [page 15, lines 1-2] from the applicant. [Col. 18, lines 19-29] Fig. 10, radio network node 12 corresponds to a network device of the Applicant, which obtains an indication from a core network node 19. [Col. 18, lines 20-38] “UE context information implicitly provides the UE context ID”, where the slice ID, corresponding to a network slice identifier's traffic category of the Applicant, is known to a core network node to the wireless device context, where ‘UE context information’ is provided in step 1211b in Fig. 12, or its equivalent, a ‘target slice ID’ in step 1111b in Fig. 11, in which the ‘target slice ID’ corresponds to another traffic category associated with a connection identifier, as the ‘target slice ID’ can also be an equivalent slices that a UE can connect to, as stated in [Col. 22, lines 41-52]. The first radio network node 12 correlating the slice ID and a slice ID of a UE context ID/’target slice ID’ corresponds to the mapping of the Applicant. Furthermore, [Col. 18, lines 19-22] Fig. 10, action 1003, where the indicating of a slice ID corresponds to the network slice identifier, and as stated by [Col. 5, lines 19-30], a network slice corresponds to a different type of communication service at an acceptable latency as a requirement, to which a network slice identifier can be used to indicate, such as a 5G ultra-low latency use case in [Col. 4, lines 29-35].);
‘and provision, to the user device, a network slice based on the network slice identifier’ ([Col. 20, lines 31-35] First radio network node 12 matches equivalent networks and slices, and determines what slices are allowed or not allowed to use the wireless device 10 against a target cell’s PLMN-ID and a slice ID received from a second radio network node 13 in action 1007 of Fig. 10.).
Zee does not appear to disclose, but Karampatsis teaches the limitations of ‘wherein a network slice associated with the network slice identifier is provisioned based on at least one user equipment route selection policy (URSP) rule that is generated by the device’ ([0146] PCF determines at least one URSP rule for a UE, and the at least one URSP rule considers availability information of a network slice, and when the network slice is available, the UE can connect via the network slice. [0148] PCF can generate URSP rule, and the PCF can be further configured via policies of a network operator, and as a PCF is part of a network, the limitation corresponds to a URSP rule that is generated by the netwrok operator, as stated by the Applicant.);
and ‘wherein the network slice includes at least a first network function that is associated with the device and a second network function that is associated with the cloud computing service’ ([0003] Network slice can include a core network (5GC, 5G core network), control plane, and user plane network functions (NFs), and an access network, such as a 5G radio access network, or 5G RAN. [0033] Radio access network can be coupled to one or more core networks, which in turn can be coupled to other networks, such as the Internet. With paragraph [0032] stating what devices can be connected to a network, such as mobile devices or television sets, and with paragraph [0060] stating that network slices provide network connectivity towards customers or application service providers, it can be determined that a 5G core network can correspond to an application service provider, and a service provider can correspond to a cloud computing service of the applicant. [0102] Control plane can include a UE, AMF, SMF, PCF, and other functions that are related to a network device of Karampatsis. [0148] PCF function can consider further locally configured policies from a network operator along with a received slice availability information for a network slice, and the PCF considering policies from a network operator can correspond to a network function being associated with a network operator of the applicant.).
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Zee and Karampatsis before them, to include Karampatsis’s ‘wherein a network slice is provisioned based on at least one user equipment route selection policy (URSP) rule’, and ‘wherein the network slice includes at least a first network function that is associated with the network operator and a second network function that is associated with the cloud computing service’ in Zee’s device performing ‘receive, from a user device, a connection request including a connection identifier’, and other functions in claim 8. One would have been motivated to make such a combination to increase efficiency as having multiple network functions can be performed with a transceiver, which operates under the control of a processor to transmit messages, data, and other signals, and receive the aforementioned elements as well, as stated in paragraph [0046], and when a PCF 630 considers URSP rules and sends the URSP rules to a UE 620 to match with a corresponding S-NSSAI, then UE 620 does not need to request registration to the S-NSSAI when the network slice is not available, as taught by Karampatsis [0123].
Zee discloses the limitation of the cloud computing service as a core network node 19, as stated in [Col. 18, lines 19-29] of Zee. Zee does not disclose the limitation of, but Karampatsis teaches the limitation of ‘and wherein the network device is between the device and the cloud computing device’ ([0148] Figs. 6, Policy Control Function (PCF) 630 corresponds to a network device, which is located between a network operator, corresponding to the device of claim 8, which is not shown in the figures, and an access node 622. The network operator can define various aspects of a PCF for the function to consider, which puts a PCF in between a network operator.).
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Zee and Karampatsis before them, to include Karampatsis’s ‘wherein the network device is between the cloud computing service and the network operator’ in Zee’s device performing ‘receive, from a user device, a connection request including a connection identifier’, and other functions in claim 8. One would have been motivated to make such a combination to increase efficiency by having a network operator configure a network slice by deploying homogenously in a tracking area (TA), which can be performed with functions of a network device including the policy control function (PCF) component, as stated by Karampatsis [0064].
Regarding claim 10, Zee in view of Karampatsis teaches the elements of claims 8 as outlined above. Zee does not appear to disclose ‘wherein the one or more processors, to provision the network slice, are configured to: receive, from the user device, a request for the network slice consistent with the URSP rule’.
However, Karampatsis teaches ‘wherein the one or more processors, to provision the network slice, are configured to: receive, from the user device, a request for the network slice consistent with the URSP rule’ ([0146] Processor is configured to cause PCF to receive availability information for a network slice associated with a user equipment, or UE. [0159] Receiving availability information corresponds to the receiving a request for network slice in accordance with the UE.);
and connect the user device to an initial network function of the network slice in response to the request for the network slice ([0061] Network slice is a logical network that comprises a set of network functions, or NFs, and corresponding resources (computing, storage, networking, etc.), necessary to provide network capabilities and network characteristics. [0012] Indication of availability information will allow the user equipment to connect to the network slice that a UE requests, which also includes the initial network function of the network slice.).
Accordingly, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the invention, having the teachings of Zee and Karampatsis before them, to include Karampatsis’s ‘wherein the one or more processors, to provision the network slice, are configured to: receive, from the user device, a request for the network slice consistent with the URSP rule’ in Zee’s device performing ‘with one or more processors configured to: receive, from a user device, a connection request including a connection identifier’ as stated in claim 14 above. One would have been motivated to make such a combination to increase efficiency by "network slice availability information is used by the PCF for the creation of RSD validation criteria for a URSP rule" to connect the user equipment to the desired network slice in response to the request, as taught by Karampatsis [0071].
Regarding claim 12, Zee in view of Karampatsis teaches the device of claim 8, as recited above. Zee also discloses wherein the connection identifier comprises a device type indicator, an Internet protocol (IP) address, or a port ([Col. 18, lines 19-22] Fig. 10, action 1003, where the indicating the slice ID the wireless device supports corresponds to the connection identifier, which in this scenario, is the device type identifier, as stated in [page 15, lines 1-2] from the applicant.).
Regarding claim 13, Zee in view of Karampatsis teaches the device of claim 8, as recited above. Zee also discloses wherein the network slice identifier comprises a traffic category indicator or single network slice selection assistance information (S-NSSAI) ([Col. 18, lines 19-22] Fig. 10, action 1003, where the indicating of a slice ID corresponds to the network slice identifier, and as stated by [Col. 5, lines 27-30], a network slice corresponds to a different type of communication service, to which a network slice identifier can be used to indicate.).
Regarding claim 14, Zee discloses ‘a non-transitory computer-readable medium storing a set of instructions, the set of instructions comprising: one or more instructions that, when executed by one or more processors of a device, cause the device to:’ ([Col. 30, line 64-Col. 31, line 5] Fig. 16, where first radio network 12 has instructions provided by means of a computer program 1609 comprising instructions such as software code portions, which can be executed by at least one processor, causes the at least one processor to carry out actions described in the invention. The computer program 1609 can be stored on a computer-readable storage medium 1610 can be a non-transitory storage medium, as described in [Col. 31, lines 11-13].);
‘establish a new service associated with a connection identifier’ ([Col. 7, lines 25-28] A service is established by a first radio network node while being associated with a connection identifier, which in this scenario, is the wireless device being identified.);
‘determine a network slice identifier to associate with the connection identifier based on mapping a traffic category associated with the network slice identifier to another traffic category associated with the connection identifier, wherein the other traffic category is a throughput traffic category or a latency traffic category’ ([Col. 20, lines 31-34] First radio network node 12 determines equivalent networks and network slice via a network slice identifier, and determines whether the network slice identifier is determined based on whether it is allowed or not allowed for use with the wireless device, which corresponds to the user equipment. [Col. 18, lines 20-38] “UE context information implicitly provides the UE context ID”, where the slice ID, corresponding to a network slice identifier's traffic category of the Applicant, is known to a core network node to the wireless device context, where ‘UE context information’ is provided in step 1211b in Fig. 12, or its equivalent, a ‘target slice ID’ in step 1111b in Fig. 11, in which the ‘target slice ID’ corresponds to another traffic category associated with a connection identifier, as the ‘target slice ID’ can also be an equivalent slices that a UE can connect to, as stated in [Col. 22, lines 41-52]. The first radio network node 12 correlating the slice ID and a slice ID of a UE context ID/’target slice ID’ corresponds to the mapping of the Applicant. Furthermore, [Col. 18, lines 19-22] Fig. 10, action 1003, where the indicating of a slice ID corresponds to the network slice identifier, and as stated by [Col. 5, lines 19-30], a network slice corresponds to a different type of communication service at an acceptable latency as a requirement, to which a network slice identifier can be used to indicate, such as a 5G ultra-low latency use case in [Col. 4, lines 29-35].);
‘generate an indication associating the connection identifier with the network slice identifier’ ([Col. 8, line 27-31] "second radio network node is configured to transmit to the first radio network node in the communication network, a response message comprising information indicating one or more slice identities supported by the second radio network node" Second radio network node is configured to transmit to first radio network node a response message comprising information indicating one or more slice identities supported by a second radio network node, with further support from [Col. 18, lines 19-29] with regards to an indication of a slice ID the wireless device 10 supports in Fig. 10 corresponds to transmitting from a user device to a network device an indication of supported network slices of the applicant.);
‘and transmit, to a network device, the indication’ ([Col. 8, lines 7-10] Indication is transmitted to a network device, and the information from the message transmitted from the device mentioned in this claim. ).
Zee does not appear to disclose, but Karampatsis teaches the limitations of ‘wherein a network slice associated with the network slice identifier is provisioned based on at least one user equipment route selection policy (URSP) rule that is generated by a network operator’ ([0146] PCF determines at least one URSP rule for a UE, and the at least one URSP rule considers availability information of a network slice, and when the network slice is available, the UE can connect via the network slice. [0148] PCF can generate URSP rule, and the PCF can be further configured via policies of a network operator, and as a PCF is part of a network, the limitation corresponds to a URSP rule that is generated by the network operator, as stated by the Applicant.);
and ‘wherein the network slice includes at least a first network function that is associated with the network operator and a second network function that is associated with the cloud computing service’ ([0003] Network slice can include a core network (5GC, 5G core network), control plane, and user plane network functions (NFs), and an access network, such as a 5G radio access network, or 5G RAN. [0033] Radio access network can be coupled to one or more core networks, which in turn can be coupled to other networks, such as the Internet. With paragraph [0032] stating what devices can be connected to a network, such as mobile devices or television sets, and with paragraph [0060] stating that network slices provide network connectivity towards customers or application service providers, it can be determined that a 5G core network can correspond to an application service provider, and a service provider can correspond to a cloud computing service of the applicant. [0102] Control plane can include a UE, AMF, SMF, PCF, and other functions that are related to a network device of Karampatsis. [0148] PCF function can consider further locally configured policies from a network operator along with a received slice availability information for a network slice, and the PCF considering policies from a network operator can correspond to a network function being associated with a network operator of the applicant.).
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Zee and Karampatsis before them, to include Karampatsis’s ‘wherein a network slice associated with the network slice identifier is provisioned based on at least one user equipment route selection policy (URSP) rule’, and ‘wherein the network slice includes at least a first network function that is associated with the network operator and a second network function that is associated with the cloud computing service’ in Zee’s non-transitory computer-readable medium performing ‘receiving, from a cloud computing service, an indication associating a connection identifier with a network slice identifier’, and other functions in claim 14. One would have been motivated to make such a combination to increase efficiency as having multiple network functions can be performed with a transceiver, which operates under the control of a processor to transmit messages, data, and other signals, and receive the aforementioned elements as well, as stated in paragraph [0046], and when a PCF 630 considers URSP rules and sends the URSP rules to a UE 620 to match with a corresponding S-NSSAI, then UE 620 does not need to request registration to the S-NSSAI when the network slice is not available, as taught by Karampatsis [0123].
Zee discloses the limitation of the cloud computing service as a core network node 19, as stated in [Col. 18, lines 19-29] of Zee. Zee does not disclose the limitation of, but Karampatsis teaches the limitation of ‘…to a network device that is between the network operator and the device…’ ([0148] Figs. 6, Policy Control Function (PCF) 630 corresponds to a network device, which is located between a network operator, corresponding to the network operator device of claim 14, which is not shown in the figures, and an access node 622. The network operator can define various aspects of a PCF for the function to consider, which puts a PCF in between a network operator.).
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Zee and Karampatsis before them, to include Karampatsis’s ‘wherein the network device is between the cloud computing service and the network operator’ in Zee’s non-transitory computer-readable medium performing ‘receiving, from a cloud computing service, an indication associating a connection identifier with a network slice identifier’, and other functions in claim 14. One would have been motivated to make such a combination to increase efficiency by having a network operator configure a network slice by deploying homogenously in a tracking area (TA), which can be performed with functions of a network device including the policy control function (PCF) component, as stated by Karampatsis [0064].
Regarding claim 15, Zee in view of Karampatsis discloses the elements of claim 14 as outlined above. Zee does not appear to teach ‘wherein the one or more instructions, when executed by the one or more processors, further cause the device to: receive, from the network device, a request for an application programming interface (API) subscription, wherein the indication is transmitted based on the API subscription’.
However, Karampatsis teaches ‘wherein the one or more instructions, when executed by the one or more processors, further cause the device to: receive, from the network device, a request for an application programming interface (API) subscription, wherein the indication is transmitted based on the API subscription’ ([0051-0053] Network node 3000 can include one or more processors 305, memory 310, and transceiver 310, with processor(s) 305 executing instructions in a memory 310. [0081] Access Network node 622, or AN, is a general denotation of a node/entity from the access network, such as a radio access network, or RAN. [0129] Fig. 7, a UDM, or Unified Management Function, may subscribe to an AMF 714, or Access and Mobility Management Function, for notifications on when network slice availability changes for any S-NSSAI, wherein the notifications could be push notifications, and the AMF corresponds to the API for the subscriptions, and the UDM is part of the network device.).
Accordingly, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the invention, having the teachings of Zee and Karampatsis before them, to include Karampatsis’s ‘wherein the one or more instructions, when executed by the one or more processors, further cause the device to: receive, from the network device, a request for an application programming interface (API) subscription, wherein the indication is transmitted based on the API subscription’ in Zee’s non-transitory computer-readable medium storing a set of instructions. One would have been motivated to make such a combination to increase efficiency such that the "method may further comprise subscribing with the AMF for notification for the UE presence in an area of interest and receiving notifications from the AMF when the UE is within the area of interest", as taught by Karampatsis [0195].
Regarding claim 17, Zee in view of Karampatsis teaches the non-transitory computer-readable medium of claim 14 as recited above. Zee also discloses the limitation of ‘wherein the one or more instructions, that cause the device to determine the network slice identifier, cause the device to: determine a traffic category associated with the new service, wherein the network slice identifier corresponds to the traffic category associated with the new service’ ([Col. 18, lines 19-22] Fig. 10, action 1003, where the indicating of a slice ID corresponds to the network slice identifier during a connection setup of a wireless device to the network slice, which is a new service to connect to the wireless device. [Col. 14, lines 48-51] Network slices support a different set of functionalities, including a type of service.).
Regarding claim 18, Zee in view of Karampatsis teaches the non-transitory computer-readable medium of claim 14 as recited above. Zee also discloses the limitation of wherein the connection identifier comprises a device type indicator, an Internet protocol (IP) address, or a port ([Col. 18, lines 19-22] Fig. 10, action 1003, where the indicating the slice ID the wireless device supports corresponds to the connection identifier, which in this scenario, is the device type identifier, as stated in [page 15, lines 1-2] from the applicant.).
Regarding claim 19, Zee in view of Karampatsis teaches the non-transitory computer-readable medium of claim 14 as recited above. Zee also discloses the limitation of wherein the network slice identifier comprises a traffic category indicator or single network slice selection assistance information (S-NSSAI) ([Col. 18, lines 19-22] Fig. 10, action 1003, where the indicating of a slice ID corresponds to the network slice identifier, and as stated by [Col. 5, lines 27-30], a network slice corresponds to a different type of communication service, to which a network slice identifier can be used to indicate.).
Regarding claim 21, Zee in view of Karampatsis teaches the device of claim 8, as recited above. Zee does not appear to disclose, but Karampatsis teaches the limitation of ‘wherein the URSP rule indicates at least one of: single network slice selection assistance information’ (S-NSSAI), a data network name (DNN), or session and service continuity (SSC) mode information’ ([0117] Fig. 6, PCF 630 creates URSP rules, with slice availability infor4mation from the AMF 614, where the PCF uses the slice availability information to create the slice associated with a first S-NSSAI to create validation criteria for an RSD (Route Selection Descriptor), including the first S-NSSAI. This corresponds to a URSP rule indicating at least one S-NSSAI of the applicant.).
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Zee and Karampatsis before them, to include Karampatsis’s ‘wherein the URSP rule indicates at least one of: single network slice selection assistance information’ in Zee’s device performing ‘receive, from a user device, a connection request including a connection identifier’, and other functions in claim 8. One would have been motivated to make such a combination to increase efficiency by having a route selection descriptor associated with a selection validation criteria to be verified before a user device connects to a network via a network slice, and network slice availability information is associated with a specific network slice, e.g. identified by S-NSSAI, to more efficiently connect with a network, as taught by Karampatsis [0071]-[0072].
Claims 2, 4, and 11 are rejected under 35 U.S.C. 103 as being unpatentable over Zee in view of Karampatsis, and further in view of Baskaran et al. (US 20240397322 A1), hereinafter Baskaran.
Regarding claim 2, Zee in view of Karampatsis teaches the method of claim 1 as outlined above. Zee in view of Karampatsis does not appear to disclose the limitation of ‘further comprising: receiving, from the cloud computing service, a set of credentials, wherein the indication is received based on verification of the set of credentials.’
However, Baskaran teaches ‘further comprising: receiving, from the cloud computing service, a set of credentials, wherein the indication is received based on verification of the set of credentials’ ([0062] Fig. 1, AF 145, or application function, may send credentials as a Secured Packet 127 to a UDM 149, or consumer NF, and passes the Secured Packet to a remote unit 105, which corresponds to a user device. [0042] Secured Packet corresponds to the set of credentials, and the lifetime parameter corresponds to the indication that is dependent on the verification of the set of credentials. [0193] Multiple pieces of credential information reside within the packet, including subscriber identity, and lifetime of a Secured Packet. [0202] Secondary authentication corresponds to the verification of the set of credentials, most notably in this scenario, the subscriber identity, and/or the device storage requirements noted in [0193] of Baskaran.).
Accordingly, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the invention, having the teachings of Zee, Karampatsis, and Baskaran before them, to include Baskaran’s ‘further comprising: receiving, from the cloud computing service, a set of credentials, wherein the indication is received based on verification of the set of credentials’ in Zee’s method performing receiving from a cloud computing service, an indication associating a connection identifier with a network slice identifier. One would have been motivated to make such a combination to increase security with regards to the "the secured packet including a valid credential and provisioning the secured packet to the device via an update procedure (e.g., a UE Parameters Update procedure)", such that the packet containing the credentials has an easier time authenticating the user device in accordance with the data present in the secured packet, including the subscriber identity and/or the device storage requirement indication, as taught by Baskaran [0230].
Regarding claim 4, Zee in view of Karampatsis teaches the elements of claim 1 as outlined above. Zee in view of Karampatsis does not appear to disclose the limitation of ‘further comprising: receiving, from the network operator, a set of credentials, wherein the request is received based on verification of the set of credentials’.
However, Baskaran teaches ‘further comprising: receiving, from the network operator, a set of credentials, wherein the request is received based on verification of the set of credentials’ ([0062] Fig. 1, AF sends a Secured Packet to UDM to be passed onto a remote unit 105. [0042] Secured Packet corresponds to the set of credentials, and the lifetime parameter corresponds to the indication that is dependent on the verification of the set of credentials. [0193] Multiple pieces of credential information reside within the packet, including subscriber information and lifetime of the packet. [0103] Fig. 3, step 1b, wherein the NEF corresponds to the network operator, and the POST request is sent to a device, in this case, SP-AF. [0105] Fig. 3, step 2b-1, wherein if the credentials exist and match up, the secured packet is sent to the user. [0106] fig. 3, step 2b-2, wherein if the information does not match up or otherwise does not exist, it simply throws an error code to the user.).
Accordingly, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the invention, having the teachings of Zee, Karampatsis, and Baskaran before them, to include Baskaran’s ‘further comprising: receiving, from the network operator, a set of credentials, wherein the request is received based on verification of the set of credentials’ in Zee’s method performing receiving from a cloud computing service, an indication associating a connection identifier with a network slice identifier. One would have been motivated to make such a combination to increase security by ensuring that "for provisioning a Secured Packet... first apparatus may be implemented by a consumer NF... and/or the network apparatus 800, described above... send the request for the credential, the processor is configured to cause the apparatus to send a HTTP POST request message... to receive the secured packet and the credential information, the processor is configured to cause the apparatus to receive a HTTP 200 OK message", such that the request is only received and processed when the credentials matching the user are found by the network apparatus, as taught by Baskaran [0220-0225].
Regarding claim 11, Zee in view of Karampatsis teaches the elements of claim 8 as outlined above. Zee in view of Karampatsis does not appear to teach ‘wherein the one or more processors are further configured to: transmit, to the network device, a set of credentials, wherein the request for network slice information is transmitted based on the set of credentials’.
However, Baskaran teaches ‘wherein the one or more processors are further configured to: transmit, to the network device, a set of credentials, wherein the request for network slice information is transmitted based on the set of credentials’ ([0062] Fig. 1, AF sends a Secured Packet to UDM to be passed onto a remote unit 105. [0042] Secured Packet corresponds to the set of credentials, and the lifetime parameter corresponds to the indication that is dependent on the verification of the set of credentials. [0193] Multiple pieces of credential information reside within the packet, including subscriber information and lifetime of the packet. [0202] Secondary authentication corresponds to the verification of the set of credentials, most notably in this scenario, the subscriber identity, and/or the device storage requirements noted in [0193] of Baskaran.).
Accordingly, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the invention, having the teachings of Zee, Karampatsis, and Baskaran before them, to include Baskaran’s ‘wherein the one or more processors are further configured to: transmit, to the network device, a set of credentials, wherein the request for network slice information is transmitted based on the set of credentials’ in Zee’s device performing with one or more processors configured to: receive, from a user device, a connection request including a connection identifier. One would have been motivated to make such a combination to increase security with regards to the "the secured packet including a valid credential and provisioning the secured packet to the device via an update procedure (e.g., a UE Parameters Update procedure)", such that the packet containing the credentials has an easier time authenticating the user device in accordance with the data present in the secured packet, including the subscriber identity and/or the device storage requirement indication, as taught by Baskaran [0230].
Claims 7 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Zee in view of Karampatsis, and further in view of Zhang et al. (CN 118633313 A, using the translated English document), hereinafter Zhang.
Regarding claim 7, Zee in view of Karampatsis teach the elements of claim 1 as outlined above. Zee in view of Karampatsis does not appear to disclose ‘further comprising: receiving, from the cloud computing service, traffic statistics associated with an additional connection identifier; applying a machine learning model to the traffic statistics to determine an additional network slice identifier’, ‘generating an additional indication associating the additional connection identifier with the additional network slice identifier’, and ‘storing, at the network device, the additional indication’.
However, Zhang teaches ‘further comprising: receiving, from the cloud computing service, traffic statistics associated with an additional connection identifier’ ([Page 12, lines 29-30] Data associated with the application corresponds to the traffic statistics associated with an additional connection identifier, which in this scenario, is the device/UE itself. [Page 12, lines 39-46] Application server corresponds to the cloud computing service. the data stream to the UE corresponds to the traffic statistics associated with an additional connection identifier, which in this scenario, is the device/UE itself. Network node may provide data for ML and analysis via ML to authorize and provide further information to network nodes to determine an appropriate network slice.);
applying a machine learning model to the traffic statistics to determine an additional network slice identifier ([Page 12, lines 30-32] Network node provides the data to the ML model to train and analyze the data based on the data from the server. [Page 15, lines 1-2] Slice identification is a result of the analysis performed by the ML model in the network node.);
generating an additional indication associating the additional connection identifier with the additional network slice identifier ([Page 14, lines 11-13] A NWDAF, known as a network data analysis function, or DCCF, known as a data collection coordination function, correspond to a network device storing the mapping, wherein the mapping is the additional indication, and requests mapping from additional network node to a user equipment, or UE, to a SUPI, or subscription permanent identifier. The action of requesting mapping from an additional network node corresponds to generating an additional indication of the applicant.);
and storing, at the network device, the additional indication ([Page 22, lines 16-20] User equipment, or UE, corresponds to the additional connection identifier, the S-NSSAI corresponds to the additional network slice identifier, while the SUPI mapping to the UE IP address corresponds to the additional indication. The mapping of the UE to the SUPI is in the local storage.).
Accordingly, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the invention, having the teachings of Zee, Karampatsis, and Zhang before them, to include Zhang’s ‘further comprising: receiving, from the cloud computing service, traffic statistics associated with an additional connection identifier; applying a machine learning model to the traffic statistics to determine an additional network slice identifier’, ‘generating an additional indication associating the additional connection identifier with the additional network slice identifier’, and ‘storing, at the network device, the additional indication’ in Zee’s method performing receiving from a cloud computing service, an indication associating a connection identifier with a network slice identifier. One would have been motivated to make such a combination to increase efficiency by “sending to a network node a request for network assistance information associated with one or more of a machine learning (ML) model or analysis associated with an application layer communication”, wherein the request for network assistance information using a machine learning model will assist in using the information for picking out a better network slice for an application and/or the conditions of the current connection using information pertaining to the network, as taught by Zhang [Page 2, lines 29-31].
Regarding claim 20, Zee in view of Karampatsis teaches the elements of claim 14 as outlined above. Zee in view of Karampatsis does not explicitly disclose ‘wherein the one or more instructions, when executed by the one or more processors, further cause the device to: transmit, to the network device, traffic statistics associated with an additional connection identifier’.
However, Zhang teaches ’wherein the one or more instructions, when executed by the one or more processors, further cause the device to: transmit, to the network device, traffic statistics associated with an additional connection identifier’ ([Page 19, line 3-5] Components may be implemented as instructions or code stored in a non-transient medium, and may be executable by a controller or processor to perform functions of the component. [Page 12, lines 29-30] Data associated with the application corresponds to the traffic statistics associated with an additional connection identifier, which in this scenario, is the device/UE itself.).
Accordingly, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the invention, having the teachings of Zee, Karampatsis, and Zhang before them, to include Zhang’s ‘wherein the one or more instructions, when executed by the one or more processors, further cause the device to: transmit, to the network device, traffic statistics associated with an additional connection identifier’ in Zee’s non-transitory computer-readable medium storing a set of instructions. One would have been motivated to make such a combination to increase efficiency by means of having a "network node [which] may provide data for ML and analysis to additional network nodes configured to train and/or use an ML model associated with network performance", such that the network node uses its own ML model to analyze patterns in the data of an application or a network to determine the best slice for the applications or any other given situation, as taught by Zhang [Page 12, lines 29-31].
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over Zee in view of Karampatsis, and further in view of Bordeleau et al. (WO 2020171957 A1, using the translated English document), hereinafter Bordeleau.
Regarding claim 16, Zee in view of Karampatsis teaches the elements of claim 14 as outlined above. Zee in view of Karampatsis does not appear to disclose ‘wherein the one or more instructions, that cause the device to establish the new service, cause the device to: establish a new Internet protocol (IP) address and port for the new service, wherein the connection identifier is the IP address and the port’.
However, Bordeleau teaches ‘wherein the one or more instructions, that cause the device to establish the new service, cause the device to: establish a new Internet protocol (IP) address and port for the new service, wherein the connection identifier is the IP address and the port’ ([0201] Fig. 30, processing unit(s) 3010 retrieve instructions to execute processes of the invention. [0203] Fig. 30, other removable storages that can be used include a floppy disk, flash drive, and others that are considered a permanent storage, which corresponds to a non-transient storage medium, and system memory 3025 can store instructions as well. [0102] L5-L7 information means 'layer 5 to layer 7' information that is used to assign a network slice, and in paragraph [0009], L5-L7 information is needed to identify the slice used by the device, and its use is for determining the user equipment device 1005, a network domain 1020 denoting the website or service being used by the user, and is also used for handshakes and establishing the network slice or a connection in general. Also, the device sending a data request message corresponds to the device establishing a new service. [0103] Network addresses and the transport layer units corresponds to the IP address and the ports, respectively, and are being established by the slice selector.).
Accordingly, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the invention, having the teachings of Zee, Karampatsis, and Bordeleau before them, to include Bordeleau’s ‘wherein the one or more instructions, when executed by the one or more processors, further cause the device to: transmit, to the network device, traffic statistics associated with an additional connection identifier’ in Zee’s non-transitory computer-readable medium storing a set of instructions. One would have been motivated to make such a combination to increase efficiency by "slic[ing] a network based on the source device (e.g., using the source network address or information identifying the type of device)... while other embodiments slice a network based on the type of traffic (e.g., by performing deep packet inspection)" where the service is initiated by one of the conditions, most notably, the source device network information, which using the source network address and the port mentioned in [0103], would assist in setting up the service to allow the device to connect to a network slice, as taught by Bordeleau [0058].
Conclusion
THIS ACTION IS MADE FINAL. 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 TOMMY MARTINEZ whose telephone number is (703)756-5651. The examiner can normally be reached Monday thru Friday 8AM-4PM ET.
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, Jorge L. Ortiz-Criado can be reached at (571) 272-7624 on Monday thru Friday, 7AM-7PM ET. 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.
/T.M./ Examiner, Art Unit 2496
/JORGE L ORTIZ CRIADO/ Supervisory Patent Examiner, Art Unit 2496