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 .
The instant office action is in response to communication filed on 02/08/2024.
The IDS(s) filed on 02/21/2024 and 06/11/2025 has been considered.
Claims 1-20 are pending of which claims 1, 8, and 15 are independent.
Internet Communications
Applicant is encouraged to submit a written authorization for Internet communications (PTO/SB/439, http://www.uspto.gov/sites/default/files/documents/sb0439.pdf) in the instant patent application to authorize the examiner to communicate with the applicant via email. The authorization will allow the examiner to better practice compact prosecution. The written authorization can be submitted via one of the following methods only: (1) Central Fax which can be found in the Conclusion section of this Office action; (2) regular postal mail; (3) EFS WEB; or (4) the service window on the Alexandria campus. EFS web is the recommended way to submit the form since this allows the form to be entered into the file wrapper within the same day (system dependent). Written authorization submitted via other methods, such as direct fax to the examiner or email, will not be accepted. See MPEP § 502.03.
Claim Objections
Claim 8 is objected to because of the following informalities: Line 15 “, , “ need to be replaced with a single comma. Appropriate correction is required.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1, 6, 8, 13, 15, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chamarty et al (US 20240163727A1, hereinafter referred to as D1) in view of Nair et al (US 20230362236 A1, hereinafter referred to as D2) and Buyukdura (US 20220360995A1, hereinafter referred to as D3).
Regarding claim 1, D1 discloses an apparatus (Fig. 10 and Figs. 2 and 3 show an apparatus used for scaling of cloud native radio access network workloads in a cloud computing environment - see paragraphs 18, 77 and 110), comprising:
a memory (Fig. 10 memory 1020 coupled to processor 1010 – paragraphs 18, 77, and 110), comprising:
information on one or more network resources available for allocation in one or
more containerized clusters a(See Paragraph 99 indicating in the system of Fig. 6 it can readily identify network resources available for allocation in one or more container clusters. Further it can only determine the resource is available by ascertaining it is no longer assigned indicating ability to identify unassigned network resource. See also paragraph 0077, Kubernetes control compute and storage resources, where by definition the control of computer/storage resources requires stored knowledge of information on available compute and storage resources. See also, Figure 11, ref. 1102 and paragraph 0111, wherein monitoring one or more processing resources being assigned to one or more container in a plurality of containers of a cloud native radio access, thereby utilizing system memory to store one or more network/processing resources for monitoring and allocation purposes.); and
a processor communicatively coupled to the memory (Fig. 10 memory 1020 coupled to processor 1010 – paragraphs 18, 77, and 110) and configured to:
determine whether the one or more network resources are unassigned (Per paragraph 99 the system of Fig. 6 it can readily identify network resources available for allocation in one or more container clusters. Further it can only determine the resource is available by ascertaining it is no longer assigned indicating ability to identify unassigned network resource. );
in response to determining that the one or more network resources are unassigned (see paragraph 99), determine that the one or more network resources (i.e. network resources are processing resources at the core or access network level per Fig. 11 step 1104) are available for allocation to a first plurality of resource pools (i.e. Fig. 11 step 1102 the network resources are assigned to a first resource pool as a first POD/first container and a second resource pool as a second POD/second container. See paragraphs 111-113) and a second plurality of resource pools; (Referring to Figures 2 and 3, See paragraph 0040 and paragraph 0080, scale- out (e.g., increase) subscriber handling pods, requiring a determination of available resources for allocation to newly added pods. Deploy upgraded resources (original and deployed upgraded each comprising resources comprising a first resource pool and a second resource pool) and monitor key performance indicators of the resources after upgrade. See paragraph 0042);
assign a first plurality of network resources to the first plurality of resource
pools;(i.e. as part of Fig. 11 step 1104 and requiring change in an assignment of one or more processing resources to the plurality of containers/pods/resource pools will involve assigning a first plurality of network resources to the first plurality of resource pools) assign a second plurality of network resources to the second plurality of resource pools; (i.e. as part of Fig. 11 step 1104 and requiring change in an assignment of one or more processing resources to the plurality of containers/pods/resource pools will involve assigning a second plurality of network resources to the second plurality of resource pools)
(Referring to Figures 2 and 3, system includes a custom resource definition (CRD) to identify the cloud resources (pods) for a rolling upgrade. One or more custom operators that monitor and sequence the upgrade of resources identified in CRD may be used. The system may be configured to deploy the upgraded resources (pods) and monitor one or more key performance indicators (KPIs) of the resources after upgrade (the pods comprising network resources for a first and second plurality of resources that enable control and user plane functions, layers). See paragraph 0041. Referring to Figure 11, the system 600 may perform monitoring of one or more processing resources being assigned to one or more containers (e.g., a pod 604) in a plurality of containers of a cloud native radio access network for providing communication to at least one user equipment in a plurality of user equipment. See paragraph 0111. Sequencing rolling software upgrades for at various RAN network functions, which may include one or more of the following: eNB, ng-eNB and/or gNB centralized unit- control plane function(s) (first plurality of layer operations assigned to a first resource pool) (ng-eNB-CU- CP, eNB-CU-CP and/or gNB-CU-CP, respectively), eNB, ng-eNB, and/or gNB centralized unit-user plane function(s) (second plurality of layer operations assigned to a second resource pool) (ng-eNB-CU- UP, eNB-CU-UP and/or gNB-CU-UP, respectively. See paragraph 0079.).
generate a first pod in the one or more containerized clusters comprising the first plurality of resource pools; (See paragraph 40 stating “…The policy may be used to determine how to scale in (e.g., reduce) and/or scale out (e.g., increase) subscriber handling pods in control and/or user planes of centralized units of eNB and/or gNB.” and paragraph 80 stating “…determining (e.g., using a policy in the HPA) whether to scale out and/or scale in of pods to handle the increased/decreased subscriber capacity, respectively.” See als0 paragraph 0040 and paragraph 0080, scale-out (e.g., increase) subscriber handling pods as consistent with the interpretation above comprising a first pod, one or more containerized clusters, comprising first resource pool for the control plane functions. See paragraph 0079.)
generate a second pod in the one or more containerized clusters comprising the second plurality of resource pools; (See paragraph 40 stating “…The policy may be used to determine how to scale in (e.g., reduce) and/or scale out (e.g., increase) subscriber handling pods in control and/or user planes of centralized units of eNB and/or gNB.” and paragraph 80 stating “…determining (e.g., using a policy in the HPA) whether to scale out and/or scale in of pods to handle the increased/decreased subscriber capacity, respectively.” See als0 paragraph 0040 and paragraph 0080, scale-out (e.g., increase) subscriber handling pods as consistent with the interpretation above comprising a second pod, one or more containerized clusters, comprising second resource pool for the control plane functions. See paragraph 0079.)
D1 fails to disclose one or more slice
assign a first slice
assign a second slice
D2, in the same endeavor, discloses one or more slice Per paragraph 16 states “… One or more clusters may be attached to the slice. Each slice has its own separate L3 domain address space—separate Subnet. Each cluster that is part of the slice has a part of the slice-subnet. Application Pods are connected to a slice and can connect to each other on slice subnet creating an overlay L3 network using slice routers cross the slice. See paragraph 333) in the one or more containerized clusters (See Fig. 2 Containerized clusters as POD 28. See Fig. 4 too ); and
assign a first slice (See Paragraph 50 and Fig. 4 slice-1 with id 1 assigned to first pod/CLUS C)
assign a second slice plurality of resource pools in the second pod. (See Paragraph 50 and Fig. 4 slice-2 with id 2 assigned to second pod/CLUS C)
D2 discloses a single slice with its own unique slice id and accordingly a group can include a single slice id and given that one can say D2 suggests or can teach a group slice id.
In view of the above, having D1’s scaling of cloud native radio access network workloads in a cloud computing environment and then given the well- established teaching of D2’s techniques for distributing computing system employing application slice, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention was made to modify D1’s scaling of cloud native radio access network workloads in a cloud computing environment as taught by D2’s techniques for distributing computing system employing application slice, since D2 states in paragraphs 177-180 that the modification results in allowing to associate namespaces and associated resource quotas per slice and normalize them across the slice (in all the clusters attached to the slice) and to perform the Slice Service discovery and makes it possible to export services from one attached cluster in the slice to across the slice (in all the clusters that are attached to the slice).
However, D1 modified by D2 fails to teach assigning group slice id.
D3, in the same endeavor, discloses assigning group slice id. (D3 discloses assigning group slice id where each group id applies to a plurality of slices. For instance, Group 1 contains slice ids 1-10.)
In view of the above, having D1’s scaling of cloud native radio access network workloads in a cloud computing environment modified by D2’s techniques for distributing computing system employing application slice and then given the well- established teaching of D3’s techniques for assigning for group slice id, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention was made to further modify D1’s scaling of cloud native radio access network workloads in a cloud computing environment modified by D2’s techniques for distributing computing system employing application slice as taught by D3’s techniques for assigning for group slice id, since D3 states in paragraph 19 that the modification results in different groups of network slice identifiers to be associated with different group network slice rules, which can be arranged to reduce the work of setting up network slice identifiers in various network slicing scenarios.
Regarding claim 8, D1 discloses a method determining whether the one or more network resources are unassigned (Per paragraph 99 the system of Fig. 6 it can readily identify network resources available for allocation in one or more container clusters. Further it can only determine the resource is available by ascertaining it is no longer assigned indicating ability to identify unassigned network resource. );
in response to determining that the one or more network resources are unassigned (see paragraph 99), determine that the one or more network resources (i.e. network resources are processing resources at the core or access network level per Fig. 11 step 1104) are available for allocation to a first plurality of resource pools (i.e. Fig. 11 step 1102 the network resources are assigned to a first resource pool as a first POD/first container and a second resource pool as a second POD/second container. See paragraphs 111-113) and a second plurality of resource pools; (Referring to Figures 2 and 3, See paragraph 0040 and paragraph 0080, scale- out (e.g., increase) subscriber handling pods, requiring a determination of available resources for allocation to newly added pods. Deploy upgraded resources (original and deployed upgraded each comprising resources comprising a first resource pool and a second resource pool) and monitor key performance indicators of the resources after upgrade. See paragraph 0042);
assigning a first plurality of network resources to the first plurality of resource
pools;(i.e. as part of Fig. 11 step 1104 and requiring change in an assignment of one or more processing resources to the plurality of containers/pods/resource pools will involve assigning a first plurality of network resources to the first plurality of resource pools)
assigning a second plurality of network resources to the second plurality of resource pools; (i.e. as part of Fig. 11 step 1104 and requiring change in an assignment of one or more processing resources to the plurality of containers/pods/resource pools will involve assigning a second plurality of network resources to the second plurality of resource pools)
(Referring to Figures 2 and 3, system includes a custom resource definition (CRD) to identify the cloud resources (pods) for a rolling upgrade. One or more custom operators that monitor and sequence the upgrade of resources identified in CRD may be used. The system may be configured to deploy the upgraded resources (pods) and monitor one or more key performance indicators (KPIs) of the resources after upgrade (the pods comprising network resources for a first and second plurality of resources that enable control and user plane functions, layers). See paragraph 0041. Referring to Figure 11, the system 600 may perform monitoring of one or more processing resources being assigned to one or more containers (e.g., a pod 604) in a plurality of containers of a cloud native radio access network for providing communication to at least one user equipment in a plurality of user equipment. See paragraph 0111. Sequencing rolling software upgrades for at various RAN network functions, which may include one or more of the following: eNB, ng-eNB and/or gNB centralized unit- control plane function(s) (first plurality of layer operations assigned to a first resource pool) (ng-eNB-CU- CP, eNB-CU-CP and/or gNB-CU-CP, respectively), eNB, ng-eNB, and/or gNB centralized unit-user plane function(s) (second plurality of layer operations assigned to a second resource pool) (ng-eNB-CU- UP, eNB-CU-UP and/or gNB-CU-UP, respectively. See paragraph 0079.).
generating a first pod in the one or more containerized clusters comprising the first plurality of resource pools; (See paragraph 40 stating “…The policy may be used to determine how to scale in (e.g., reduce) and/or scale out (e.g., increase) subscriber handling pods in control and/or user planes of centralized units of eNB and/or gNB.” and paragraph 80 stating “…determining (e.g., using a policy in the HPA) whether to scale out and/or scale in of pods to handle the increased/decreased subscriber capacity, respectively.” See als0 paragraph 0040 and paragraph 0080, scale-out (e.g., increase) subscriber handling pods as consistent with the interpretation above comprising a first pod, one or more containerized clusters, comprising first resource pool for the control plane functions. See paragraph 0079.)
generating a second pod in the one or more containerized clusters comprising the second plurality of resource pools; (See paragraph 40 stating “…The policy may be used to determine how to scale in (e.g., reduce) and/or scale out (e.g., increase) subscriber handling pods in control and/or user planes of centralized units of eNB and/or gNB.” and paragraph 80 stating “…determining (e.g., using a policy in the HPA) whether to scale out and/or scale in of pods to handle the increased/decreased subscriber capacity, respectively.” See als0 paragraph 0040 and paragraph 0080, scale-out (e.g., increase) subscriber handling pods as consistent with the interpretation above comprising a second pod, one or more containerized clusters, comprising second resource pool for the control plane functions. See paragraph 0079.)
D1 fails to disclose generating a first slice
generating a second slice
D2, in the same endeavor, discloses one or more slice i.e. the slice ID is the L3 domain address space name) corresponding to at least one slice Per paragraph 16 states “… One or more clusters may be attached to the slice. Each slice has its own separate L3 domain address space—separate Subnet. Each cluster that is part of the slice has a part of the slice-subnet. Application Pods are connected to a slice and can connect to each other on slice subnet creating an overlay L3 network using slice routers cross the slice. See paragraph 333) in the one or more containerized clusters (See Fig. 2 Containerized clusters as POD 28. See Fig. 4 too ); and
generating a first slice See Fig. 4 Slice-1 as 1 as the slice id generated being assigned) configured to access at least one slice of the first polarity of resource of pools in the first pod, each slice i.e. the slice ID is the L3 domain address space name) corresponding to at least one slice Per paragraph 16 states “… One or more clusters may be attached to the slice. Each slice has its own separate L3 domain address space—separate Subnet. Each cluster that is part of the slice has a part of the slice-subnet. Application Pods are connected to a slice and can connect to each other on slice subnet creating an overlay L3 network using slice routers cross the slice. See paragraph 333); (See Paragraph 50 and Fig. 4 slice-1 with id 1 generated to assign to first pod/CLUS C)
generating a second slice See Paragraph 50 and Fig. 4 slice-2 with id 2 assigned to second pod/CLUS C)
D2 discloses a single slice with its own unique slice id and accordingly a group can include a single slice id and given that one can say D2 suggests or can teach a group slice id.
In view of the above, having D1’s scaling of cloud native radio access network workloads in a cloud computing environment and then given the well- established teaching of D2’s techniques for distributing computing system employing application slice, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention was made to modify D1’s scaling of cloud native radio access network workloads in a cloud computing environment as taught by D2’s techniques for distributing computing system employing application slice, since D2 states in paragraphs 177-180 that the modification results in allowing to associate namespaces and associated resource quotas per slice and normalize them across the slice (in all the clusters attached to the slice) and to perform the Slice Service discovery and makes it possible to export services from one attached cluster in the slice to across the slice (in all the clusters that are attached to the slice).
However, D1 modified by D2 fails to teach generating group slice id.
D3, in the same endeavor, discloses generating group slice id. (D3 discloses assigning group slice id where each group id applies to a plurality of slices. For instance, Group 1 contains slice ids 1-10.)
In view of the above, having D1’s scaling of cloud native radio access network workloads in a cloud computing environment modified by D2’s techniques for distributing computing system employing application slice and then given the well- established teaching of D3’s techniques for assigning for group slice id, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention was made to further modify D1’s scaling of cloud native radio access network workloads in a cloud computing environment modified by D2’s techniques for distributing computing system employing application slice as taught by D3’s techniques for assigning for group slice id, since D3 states in paragraph 19 that the modification results in different groups of network slice identifiers to be associated with different group network slice rules, which can be arranged to reduce the work of setting up network slice identifiers in various network slicing scenarios.
Regarding claim 15, D1 discloses a non-transitory computer-readable medium (Fig. 10 memory 1020 and storage device 1030 ) storing instructions that when executed by a processor (Fig. 10 processor 1010) cause the processor to:
determine whether the one or more network resources are unassigned (Per paragraph 99 the system of Fig. 6 it can readily identify network resources available for allocation in one or more container clusters. Further it can only determine the resource is available by ascertaining it is no longer assigned indicating ability to identify unassigned network resource. );
in response to determining that the one or more network resources are unassigned (see paragraph 99), determine that the one or more network resources (i.e. network resources are processing resources at the core or access network level per Fig. 11 step 1104) are available for allocation to a first plurality of resource pools (i.e. Fig. 11 step 1102 the network resources are assigned to a first resource pool as a first POD/first container and a second resource pool as a second POD/second container. See paragraphs 111-113) and a second plurality of resource pools; (Referring to Figures 2 and 3, See paragraph 0040 and paragraph 0080, scale- out (e.g., increase) subscriber handling pods, requiring a determination of available resources for allocation to newly added pods. Deploy upgraded resources (original and deployed upgraded each comprising resources comprising a first resource pool and a second resource pool) and monitor key performance indicators of the resources after upgrade. See paragraph 0042);
assign a first plurality of network resources to the first plurality of resource
pools;(i.e. as part of Fig. 11 step 1104 and requiring change in an assignment of one or more processing resources to the plurality of containers/pods/resource pools will involve assigning a first plurality of network resources to the first plurality of resource pools)
assign a second plurality of network resources to the second plurality of resource pools; (i.e. as part of Fig. 11 step 1104 and requiring change in an assignment of one or more processing resources to the plurality of containers/pods/resource pools will involve assigning a second plurality of network resources to the second plurality of resource pools)
(Referring to Figures 2 and 3, system includes a custom resource definition (CRD) to identify the cloud resources (pods) for a rolling upgrade. One or more custom operators that monitor and sequence the upgrade of resources identified in CRD may be used. The system may be configured to deploy the upgraded resources (pods) and monitor one or more key performance indicators (KPIs) of the resources after upgrade (the pods comprising network resources for a first and second plurality of resources that enable control and user plane functions, layers). See paragraph 0041. Referring to Figure 11, the system 600 may perform monitoring of one or more processing resources being assigned to one or more containers (e.g., a pod 604) in a plurality of containers of a cloud native radio access network for providing communication to at least one user equipment in a plurality of user equipment. See paragraph 0111. Sequencing rolling software upgrades for at various RAN network functions, which may include one or more of the following: eNB, ng-eNB and/or gNB centralized unit- control plane function(s) (first plurality of layer operations assigned to a first resource pool) (ng-eNB-CU- CP, eNB-CU-CP and/or gNB-CU-CP, respectively), eNB, ng-eNB, and/or gNB centralized unit-user plane function(s) (second plurality of layer operations assigned to a second resource pool) (ng-eNB-CU- UP, eNB-CU-UP and/or gNB-CU-UP, respectively. See paragraph 0079.).
generate a first pod in the one or more containerized clusters comprising the first plurality of resource pools; (See paragraph 40 stating “…The policy may be used to determine how to scale in (e.g., reduce) and/or scale out (e.g., increase) subscriber handling pods in control and/or user planes of centralized units of eNB and/or gNB.” and paragraph 80 stating “…determining (e.g., using a policy in the HPA) whether to scale out and/or scale in of pods to handle the increased/decreased subscriber capacity, respectively.” See als0 paragraph 0040 and paragraph 0080, scale-out (e.g., increase) subscriber handling pods as consistent with the interpretation above comprising a first pod, one or more containerized clusters, comprising first resource pool for the control plane functions. See paragraph 0079.)
generate a second pod in the one or more containerized clusters comprising the second plurality of resource pools; (See paragraph 40 stating “…The policy may be used to determine how to scale in (e.g., reduce) and/or scale out (e.g., increase) subscriber handling pods in control and/or user planes of centralized units of eNB and/or gNB.” and paragraph 80 stating “…determining (e.g., using a policy in the HPA) whether to scale out and/or scale in of pods to handle the increased/decreased subscriber capacity, respectively.” See als0 paragraph 0040 and paragraph 0080, scale-out (e.g., increase) subscriber handling pods as consistent with the interpretation above comprising a second pod, one or more containerized clusters, comprising second resource pool for the control plane functions. See paragraph 0079.)
D1 fails to disclose generate a first slice
generate a second slice
D2, in the same endeavor, discloses one or more slice i.e. the slice ID is the L3 domain address space name) corresponding to at least one slice pod (Per paragraph 16 states “… One or more clusters may be attached to the slice. Each slice has its own separate L3 domain address space—separate Subnet. Each cluster that is part of the slice has a part of the slice-subnet. Application Pods are connected to a slice and can connect to each other on slice subnet creating an overlay L3 network using slice routers cross the slice. See paragraph 333) in the one or more containerized clusters (See Fig. 2 Containerized clusters as POD 28. See Fig. 4 too ); and
generate a first slice See Fig. 4 Slice-1 as 1 as the slice id generated being assigned) configured to access at least one slice of the first polarity of resource of pools in the first pod, each slice i.e. the slice ID is the L3 domain address space name) corresponding to at least one slice Per paragraph 16 states “… One or more clusters may be attached to the slice. Each slice has its own separate L3 domain address space—separate Subnet. Each cluster that is part of the slice has a part of the slice-subnet. Application Pods are connected to a slice and can connect to each other on slice subnet creating an overlay L3 network using slice routers cross the slice. See paragraph 333); (See Paragraph 50 and Fig. 4 slice-1 with id 1 generated to assign to first pod/CLUS C)
generate a second slice See Paragraph 50 and Fig. 4 slice-2 with id 2 assigned to second pod/CLUS C)
D2 discloses a single slice with its own unique slice id and accordingly a group can include a single slice id and given that one can say D2 suggests or can teach a group slice id.
In view of the above, having D1’s scaling of cloud native radio access network workloads in a cloud computing environment and then given the well- established teaching of D2’s techniques for distributing computing system employing application slice, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention was made to modify D1’s scaling of cloud native radio access network workloads in a cloud computing environment as taught by D2’s techniques for distributing computing system employing application slice, since D2 states in paragraphs 177-180 that the modification results in allowing to associate namespaces and associated resource quotas per slice and normalize them across the slice (in all the clusters attached to the slice) and to perform the Slice Service discovery and makes it possible to export services from one attached cluster in the slice to across the slice (in all the clusters that are attached to the slice).
However, D1 modified by D2 fails to teach generating group slice id.
D3, in the same endeavor, discloses generating group slice id. (D3 discloses assigning group slice id where each group id applies to a plurality of slices. For instance, Group 1 contains slice ids 1-10.)
In view of the above, having D1’s scaling of cloud native radio access network workloads in a cloud computing environment modified by D2’s techniques for distributing computing system employing application slice and then given the well- established teaching of D3’s techniques for assigning for group slice id, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention was made to further modify D1’s scaling of cloud native radio access network workloads in a cloud computing environment modified by D2’s techniques for distributing computing system employing application slice as taught by D3’s techniques for assigning for group slice id, since D3 states in paragraph 19 that the modification results in different groups of network slice identifiers to be associated with different group network slice rules, which can be arranged to reduce the work of setting up network slice identifiers in various network slicing scenarios.
Regarding claim 6, D1 modified by D2 and D3 discloses the apparatus as set forth above including the processor. However D1 modified by D2 fails to disclose the processor is further configured to: in conjunction with determining the first slice group ID of the one or more slice group IDs configured to access at least one slice of the first plurality of resource pools in the first pod, generate a first slice, a second slice, and a third slice in the first pod.
D3, in the same endeavor, discloses the processor is further configured to: in conjunction with determining the first slice group ID of the one or more slice group IDs (See Fig. 2 Slice ids 1-10 have Group Slice ID 1) configured to access at least one slice (See Fig. 4 from Group Slice ID 1 slices 1, 2, 3, 4 out of slice ids 1-10 in Group 1 is accessed) of the first plurality of resource pools (Resource Pools accessed are transport segment A and transport segment B in Fig. 4) in the first pod (container 5G Core Intra Zone A in Fig. 4), generate a first slice(Slice 1 Fig. 4), a second slice(Slice 2 Fig. 4), and a third slice (Slices 3 and 4 Fig. 4)in the first pod (i.e. in paragraph 122 containers use the group slices and the containers are also PODs and can correspond to container 5G Core Intra Zone A in Fig. 4 ).
In view of the above, having D1’s scaling of cloud native radio access network workloads in a cloud computing environment modified by D2’s techniques for distributing computing system employing application slice and then given the well- established teaching of D3’s techniques for assigning for group slice id, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention was made to further modify D1’s scaling of cloud native radio access network workloads in a cloud computing environment modified by D2’s techniques for distributing computing system employing application slice as taught by D3’s techniques for assigning for group slice id, since D3 states in paragraph 19 that the modification results in different groups of network slice identifiers to be associated with different group network slice rules, which can be arranged to reduce the work of setting up network slice identifiers in various network slicing scenarios.
Regarding claim 13, claim 13 rejected in the same scope as claim 6.
Regarding claim 20, claim 20 rejected in the same scope as claim 6.
Allowable Subject Matter
Claims 2-5, 7, 9-12, 14 and 16-19 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HABTE MERED whose telephone number is (571)272-6046. The examiner can normally be reached Monday - Friday 12-10 PM EST.
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, Michael Thier can be reached at 5712722832. 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.
/HABTE MERED/Primary Examiner, Art Unit 2474
Prosecution Insights