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 .
No claims have been amended. No new claims have been added. No claims have been canceled. Claims 1-20 are currently pending for examination.
Response to Arguments
Applicant’s arguments, see pgs.7-10, filed 7/15/2026, with respect to the independent claims; specifically “coordinating the first load balancing configuration and the second load balancing configuration such that, following the change, each execution instance of one or more of the plurality software functions is subject to the same load balancing configuration as each instance of one or more of the plurality of software containers with which the one or more of the plurality of software functions is associated”, claim 1 have been fully considered and are persuasive. The rejection of claim 1 under 35 USC 103 under Thoemmes in view of Jiang has been withdrawn. The new grounds of rejection of claim 1 rely upon Thoemmes (US 20220027203 A1) in view of Coleman (US 11310309 B1).
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 1, 7, and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Thoemmes (US 20220027203 A1) in view of Coleman (US 11310309 B1).
As per claim 1, Thoemmes discloses:
A method performed by an entity for load balancing in a system comprising a function-as-a-service, FaaS, (FaaS) system and a container- as-a-service, CaaS, (CaaS) system, wherein the FaaS system runs a plurality of software functions ("The function management module 125 may also be in communication with a load balancer associated with the FaaS system 130. In one example, the function management module 125 may monitor resource consumption of runtime containers executing one of the functions 135A-N on the FaaS system 130. The function management module 125 may determine whether one or more additional function instances can be executed within the runtime container in view of the resource consumption.", 0017)
each software container of the plurality of software containers is associated with a respective software function of the plurality of software functions (“the function management module 125 may monitor resource consumption of runtime containers executing one of the functions 135A-N on the FaaS system 130.", 0017 ; see figure 1)
Thoemmes discloses the above limitations of claim 1, but does not disclose a CaaS system, or coordinating the first and second load balancing configurations.
However, Coleman discloses:
a container- as-a-service, CaaS, (CaaS) system…the CaaS system runs a plurality of software containers (“users can request computer resources from a data center, including single computing devices or a configuration of networked computing devices, and be provided with varying numbers of virtual machine resources.”, col.1, lines 27-31)
the method comprises: in response to a change in a first load balancing configuration of the plurality of software containers and/or a second load balancing configuration of the plurality of software functions: coordinating the first load balancing configuration and the second load balancing configuration such that, following the change, each execution instance of one or more of the plurality software functions is subject to the same load balancing configuration as each instance of one or more of the plurality of software containers with which the one or more of the plurality of software functions is associated. (“multiple load balancers 112 may be coordinated to share at least some information during operation. For example, an individual load balancer 112 may select a location for a newly added server on a consistent hash ring, and communicate that selection to other load balancers 112.”, col.11, lines 19-24 ; “multiple load balancers 112 may operate based on a shared logical representation of the ring 10, such as in a strongly consistent data store accessible to each load balancer 122, such that modification of the ring 10 by a first load balancer 112 also modifies the ring 10 for a second load balancer 112.”, col.14, lines 31-37 ; “A cloud computing environment (sometimes referred to simply as a “cloud”), such as the environment 110 of FIG. 2, refers to a pool of network-accessible computing resources (such as compute, storage, and networking resources, applications, and services), which may be virtualized or bare-metal... Cloud computing can thus be considered as both the applications delivered as services over a publicly accessible network (e.g., the Internet, a cellular communication network) and the hardware and software in cloud provider data centers that provide those services.”, col.8, lines 17-32 ; Examiner Note: the shared logical representation of the hash ring which is used to make load balancing decisions equates to a load balancing configuration. The virtualized compute resources equate to the plurality of software containers. The virtualized resources are directly associated with the applications which are delivered as services- equating to the plurality of software functions)
It would have been obvious to one of ordinary skill in the art, before the effective filing date to combine the teachings of Thoemmes with those of Coleman in order to provide the load balancers with an improved consistent hash ring algorithm for load distribution- resulting in a more evenly distributed load among servers without inhibiting rapid operation of the load balancer; and associate the multiple load balancers in a way that acts as a distributed service (Coleman, [col.11, lines 5-16]).
As per claim 7, Thoemmes in view of Coleman fully discloses the limitations of claim 1.
Furthermore, Coleman discloses:
in response to a change in the first load balancing configuration, coordinating the first load balancing configuration and the second load balancing configuration comprises: generating an updated second load balancing configuration such that, following the change, each execution instance of one or more of the plurality of software functions is subject to the same load balancing configuration as each instance of one or more of the plurality of software containers with which the one or more of the plurality of software functions is associated (“multiple load balancers 112 may be coordinated to share at least some information during operation. For example, an individual load balancer 112 may select a location for a newly added server on a consistent hash ring, and communicate that selection to other load balancers 112.”, col.11, lines 19-24 ; “multiple load balancers 112 may operate based on a shared logical representation of the ring 10, such as in a strongly consistent data store accessible to each load balancer 122, such that modification of the ring 10 by a first load balancer 112 also modifies the ring 10 for a second load balancer 112.”, col.14, lines 31-37 ; “A cloud computing environment (sometimes referred to simply as a “cloud”), such as the environment 110 of FIG. 2, refers to a pool of network-accessible computing resources (such as compute, storage, and networking resources, applications, and services), which may be virtualized or bare-metal... Cloud computing can thus be considered as both the applications delivered as services over a publicly accessible network (e.g., the Internet, a cellular communication network) and the hardware and software in cloud provider data centers that provide those services.”, col.8, lines 17-32 ; Examiner Note: the modified ring equates to the updated second load balancing configuration which is generated in response to the change of the first load balancing configuration)
As per claim 14, Thoemmes in view of Coleman fully discloses the limitations of claim 1.
Furthermore, Coleman discloses:
in response to a change in the second load balancing configuration, coordinating the first load balancing configuration and the second load balancing configuration comprises: generating an updated first load balancing configuration such that, following the change, each execution instance of one or more of the plurality of software function is subject to the same load balancing configuration as each instance of one or more of the plurality of software containers with which the one or more of the plurality of software functions is associated. (“multiple load balancers 112 may be coordinated to share at least some information during operation. For example, an individual load balancer 112 may select a location for a newly added server on a consistent hash ring, and communicate that selection to other load balancers 112.”, col.11, lines 19-24 ; “multiple load balancers 112 may operate based on a shared logical representation of the ring 10, such as in a strongly consistent data store accessible to each load balancer 122, such that modification of the ring 10 by a first load balancer 112 also modifies the ring 10 for a second load balancer 112.”, col.14, lines 31-37 ; “A cloud computing environment (sometimes referred to simply as a “cloud”), such as the environment 110 of FIG. 2, refers to a pool of network-accessible computing resources (such as compute, storage, and networking resources, applications, and services), which may be virtualized or bare-metal... Cloud computing can thus be considered as both the applications delivered as services over a publicly accessible network (e.g., the Internet, a cellular communication network) and the hardware and software in cloud provider data centers that provide those services.”, col.8, lines 17-32 ; Examiner Note: the modified ring equates to the updated second load balancing configuration which is generated in response to the change of the first load balancing configuration)
Claims 2-4 are rejected under 35 U.S.C. 103 as being unpatentable over Thoemmes (US 20220027203 A1) in view of Coleman (US 11310309 B1) in further view of Gero (US 20230161603 A1).
As per claim 2, Thoemmes in view of Coleman fully discloses the limitations of claim 1, but does not disclose constraints of software functions and containers.
However, Gero discloses:
each software container is associated with a respective software function by having one or more common constraints (“Affinity groups have a scope attribute that defines the required proximity of worker nodes that an affinity group states as orchestration constraints. For example, the scope of an affinity group may be a worker node, i.e. the scope of an affinity group may be that all VNFs of the affinity group are initiated on the same worker node (which may be selected by the orchestration system).", 0002 ; "Functions may be (and typically are) deployed as containers via a container orchestration system, which may support affinity groups. As a result, containers that include functions may be co-located with other containers, e.g. in Kubeless.", 0008 ; Examiner Note: a VNF with an orchestration constraint that requires it to be on the same location as a container which is in an affinity group necessitating its co-location with a container running the function equates to a software container sharing a constraint with a software function)
It would have been obvious to one of ordinary skill in the art, before the effective filing date, to combine the teachings of Thoemmes and Coleman with those of Gero in order to provide the system with the ability to deploy mixed function and container based software (Gero, [0011]).
As per claim 3, Thoemmes in view of Coleman in further view of Gero fully discloses the limitations of claim 2.
Furthermore, Gero discloses:
the one or more common constraints comprises a constraint that the software container is co-located with the respective software function. ("Affinity groups have a scope attribute that defines the required proximity of worker nodes that an affinity group states as orchestration constraints. For example, the scope of an affinity group may be a worker node, i.e. the scope of an affinity group may be that all VNFs of the affinity group are initiated on the same worker node (which may be selected by the orchestration system).", 0002 ; "Functions may be (and typically are) deployed as containers via a container orchestration system, which may support affinity groups. As a result, containers that include functions may be co-located with other containers, e.g. in Kubeless.", 0008 ; Examiner Note: an orchestration constraint that a VNF must be located on the same node as another VNF which is necessarily running in another container equates to an orchestration constraint that a software container must be co-located with a software container)
As per claim 4, Thoemmes in view of Coleman in further view of Gero fully discloses the limitations of claim 3.
Furthermore, Gero discloses:
the software container and the respective software function are co-located at the same node or site ("Functions may be (and typically are) deployed as containers via a container orchestration system, which may support affinity groups. As a result, containers that include functions may be co-located with other containers, e.g. in Kubeless.", 0008)
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Thoemmes (US 20220027203 A1) in view of Coleman (US 11310309 B1) in further view of Gero (US 20230161603 A1) in further view of Makhervaks (US 20160072817 A1).
As per claim 5, Thoemmes in view of Coleman in further view of Gero fully discloses the limitations of claim 2, but does not disclose the sharing of a database shard between container and function.
However, Makhervaks discloses:
the one or more common constraints comprises a constraint that the software container uses the same database shard as the respective software function ("Note that multiple VMs may be granted access to the each specific database service, and that a single VM may be granted access to multiple database services. The access granted is completely granular as per the ACL table and can be configured as necessary to isolate VMs associated with particular tenants from database services associated with other tenants or to share particular database services between VMs of different tenants as necessary or desirable for the particular service", 0074; Examiner Note: a first VM of multiple VMs equates to a software container, and software running on a second VM of multiple VMs equates to a software function)
The combination of Thoemmes in view of Coleman in further view of Gero in further view of Makhervaks would provide a system which possessed constraints that a software container uses the same database shard as a software function with which it is associated. It would have been obvious to one of ordinary skill in the art, before the effective filing date, to combine the teachings of Thoemmes in view of Coleman in further view of Gero with those of Makhervaks in order to provide a security solution that ensures the security of data in a multitenant environment (Makhervaks, [0011]).
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Thoemmes (US 20220027203 A1) in view of Coleman (US 11310309 B1) in further view of Jiang (US20190272205A1).
As per claim 6, Thoemmes in view of Coleman fully discloses the limitations of claim 1, but does not explicitly disclose acquiring information indicative of the association of each software container of the plurality of software containers with the respective software function of the plurality of software functions.
However, Jiang discloses:
acquiring information indicative of the association of each software container of the plurality of software containers with the respective software function of the plurality of software functions. (“The transceiver 206 is configured to receive a container deployment message, where the container deployment message includes container image information and association information of a container.”, 0046)
The combination of Thoemmes in view of Coleman in further view of Jiang would provide a system which receives/acquires the association information between the respective software containers and software functions. It would have been obvious to one of ordinary skill in the art, before the effective filing date to combine the teachings of Thoemmes in view of Coleman with those of Jiang in order to provide the system with a means for achieving extremely high speeds of access between processes (Jiang, [0037]).
Claims 8, 9, 15, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Thoemmes (US 20220027203 A1) in view of Coleman (US 11310309 B1) in further view of Foreman (US 20210157655 A1) in further view of Anchi (US 20220179804 A1).
As per claim 8, Thoemmes in view of Coleman fully discloses the limitations of claim 7, but does not explicitly disclose the identifiers of containers/functions or the replacing of one with the other.
However, Foreman discloses:
the first load balancing configuration comprises a plurality of identifiers, each of which identifies a software container of the plurality of software containers (“In accordance with aspects of the invention, the individual nodes 105a-n of the cluster perform load balancing of running containers in the cluster based on the tags of the containers and the capabilities of the nodes", 0077)
It would have been obvious to one of ordinary skill in the art, before the effective filing date, to combine the teachings of Thoemmes in view of Coleman with those of Foreman in order to provide the advantages of faster addition or removal from the cluster without a central usage policy; multiple, independent department or host-level ownership and control of specific cluster members; sharing resources among member-owners of the cluster hosts; and, optimizing excess resources available among all of the participating organization's assets; thereby reducing costs; and permitting each member of the cluster to prioritize usage for assets it owns and also reduce wasted provisioning (Foreman, [0019]).
Thoemmes in view of Coleman in further view of Foreman discloses the above limitations of claim 8, but does not disclose the replacement of identifiers of containers/functions.
However, Anchi discloses:
generating the updated second load balancing configuration comprises: for each of the plurality of software containers, replacing the identifier that identifies the software container with an identifier that identifies the software function with which the software container is associated. ("In some embodiments, the first version of the host OS data structure comprises a virtual machine file system (VMFS) header or other type of VMFS data structure that includes the first identifier of the logical storage device and the second version of the host OS data structure comprises the VMFS header or other VMFS data structure updated to replace the first identifier of the logical storage device with the second identifier of the logical storage device.", 0113)
The system of Thoemmes in view of Coleman in further view of Foreman in further view of Anchi would be capable of replacing the identifier of a container with the identifier of a function with which it is associated. It would have been obvious to one of ordinary skill in the art, before the effective filing date, to combine the teachings of Thoemmes in view of Coleman in further view of Foreman with those of Anchi in order to provide the system with the ability to configure a multi-path layer of one or more host devices to include efficient load balancing functionality (Anchi, [0129]).
As per claim 9, Thoemmes in view of Coleman in further view of Foreman in further view of Anchi fully discloses the limitations of claim 8.
Furthermore, Coleman discloses:
generating the updated second load balancing configuration comprises: creating a copy of the first load balancing configuration, (“multiple load balancers 112 may operate based on a shared logical representation of the ring 10”, col.14, lines 31-34 ; Examiner Note: the shared logical representation of the ring equates to a copy of the first load balancing configuration)
Furthermore, Anchi discloses:
the identifier that identifies the software container is replaced in the copy of the first load balancing configuration. ("In some embodiments, the first version of the host OS data structure comprises a virtual machine file system (VMFS) header or other type of VMFS data structure that includes the first identifier of the logical storage device and the second version of the host OS data structure comprises the VMFS header or other VMFS data structure updated to replace the first identifier of the logical storage device with the second identifier of the logical storage device.", 0113)
As per claim 15, Thoemmes in view of Coleman fully discloses the limitations of claim 14, but does not explicitly disclose the identifiers of containers/functions or the replacing of one with the other.
However, Foreman discloses:
the second load balancing configuration comprises a plurality of identifiers, each of which identifies a software function of the plurality of software functions (“In accordance with aspects of the invention, the individual nodes 105a-n of the cluster perform load balancing of running containers in the cluster based on the tags of the containers and the capabilities of the nodes", 0077)
The system of Thoemmes in view of Coleman in view of Foreman consists of a second load balancing configuration comprising the identifiers of the virtual functions within containers.
Thoemmes in view of Coleman in further view of Foreman discloses the above limitations of claim 15, but does not disclose the replacement of identifiers of containers/functions.
However, Anchi discloses:
generating the updated first load balancing configuration comprises: for each of the plurality of software functions, replacing the identifier that identifies the software function with an identifier that identifies the software container with which the software function is associated ("In some embodiments, the first version of the host OS data structure comprises a virtual machine file system (VMFS) header or other type of VMFS data structure that includes the first identifier of the logical storage device and the second version of the host OS data structure comprises the VMFS header or other VMFS data structure updated to replace the first identifier of the logical storage device with the second identifier of the logical storage device.", 0113)
As per claim 16, Thoemmes in view of Coleman in further view of Foreman in further view of Anchi fully discloses the limitations of claim 15.
Furthermore, Coleman discloses:
generating the updated first load balancing configuration comprises: creating a copy of the second load balancing configuration, (“multiple load balancers 112 may operate based on a shared logical representation of the ring 10”, col.14, lines 31-34 ; Examiner Note: the shared logical representation of the ring equates to a copy of the first load balancing configuration)
Furthermore, Anchi discloses:
the identifier that identifies the software function is replaced in the copy of the second load balancing configuration. ("In some embodiments, the first version of the host OS data structure comprises a virtual machine file system (VMFS) header or other type of VMFS data structure that includes the first identifier of the logical storage device and the second version of the host OS data structure comprises the VMFS header or other VMFS data structure updated to replace the first identifier of the logical storage device with the second identifier of the logical storage device.", 0113)
Claims 10 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Thoemmes (US 20220027203 A1) in view of Coleman (US 11310309 B1) in further view of Foreman (US 20210157655 A1) in further view of Anchi (US 20220179804 A1) in further view of Knotwell (US 20210058388 A1).
As per claim 10, Thoemmes in view of Coleman in further view of Foreman in further view of Anchi fully discloses the limitations of claim 9, but does not disclose the acquisition of identifiers of software functions.
However, Knotwell discloses:
for each of the plurality of software functions, acquiring the identifier that identifies the software function ("In one embodiment, the unique identifier of the virtual function allocated to the guest VM that was torn down is retrieved from local storage (for example, by looking up the identifier of the virtual function associated with the identifier of the guest VM that was torn down) by allocation method 1067. ", 0202)
It would have been obvious to one of ordinary skill in the art, before the effective filing date, to combine the teachings of Thoemmes in view of Coleman in further view of Foreman in further view of Anchi with those of Knotwell in order to provide a system wherein no prior configuration of the hosts is required other than provision of the certificate and an EAPOL/802.1x supplicant module to pass the certificate, which reduces the possibility for error in configuration of the hosts (Knotwell, [0031]).
As per claim 17, Thoemmes in view of Coleman in further view of Foreman in further view of Anchi fully discloses the limitations of claim 16, but does not explicitly disclose the acquisition of identifiers of software containers
However, Knotwell discloses:
for each of the plurality of software containers, acquiring the identifier that identifies the software container ("In one embodiment, the unique identifier of the virtual function allocated to the guest VM that was torn down is retrieved from local storage (for example, by looking up the identifier of the virtual function associated with the identifier of the guest VM that was torn down) by allocation method 1067. ", 0202; Examiner Note: looking up the identifier of the virtual function and associated guest VM equates to acquiring the ID of a software container)
Claims 11, 12, 13, 18, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Thoemmes (US 20220027203 A1) in view of Coleman (US 11310309 B1) in further view of Agarwal (US 20170214738 A1).
As per claim 11, Thoemmes in view of Coleman fully discloses the limitations of claim 7, but does not disclose the passing of the load balancing configuration to the FaaS node.
However, Agarwal discloses:
providing the updated second load balancing configuration to a FaaS node, wherein the FaaS node is a node that is configured to perform load balancing in the FaaS system ("In step 2332, the routine accesses layer-7 load-balancing policies and the local copy of the layout, configuration, and performance data in order to determine to which computational node to forward the service-related message.", 0098 ; Examiner Note: the routine, equating to a node, accessing the load balancing configuration equates to being provided with the load balancing configuration)
It would have been obvious to one of ordinary skill in the art, before the effective filing date, to combine the teachings of Thoemmes in view of Coleman with those of Agarwal in order to provide an event-record log which can be easily searched, partitioned, and otherwise processed based on event-message types, which produces a significant computational advantage for downstream event-analysis and event-interpretation systems. (Agarwal, [0062]).
As per claim 12, Thoemmes in view of Coleman fully discloses the limitations of claim 7, but does not disclose the acquisition of the load balancing configuration from the CaaS node.
However, Agarwal discloses:
acquiring the first load balancing configuration from a CaaS node, wherein the CaaS node is a node that is configured to perform load balancing in the CaaS system ("In step 2332, the routine accesses layer-7 load-balancing policies and the local copy of the layout, configuration, and performance data in order to determine to which computational node to forward the service-related message.", 0098)
The system of Thoemmes in view of Coleman in further view of Agarwal would be capable of acquiring the first load balancing configuration from a CaaS node (Jiang, [0050]) which is configured to perform load balancing.
As per claim 13, Thoemmes in view of Coleman in further view of Agarwal fully discloses the limitations of claim 12.
Furthermore, Agarwal discloses:
acquiring the first load balancing configuration from the CaaS node comprises: reading the first load balancing configuration from the CaaS node receiving the first load balancing configuration from the CaaS node in response to a request for the first load balancing configuration. (“The layer-7 load-balancing subcomponent of computational node 1806 consults the layer-7 load-balancing policies 1832 and stored information 1834 in order to determine to which of the n−1 other nodes to redistribute all or a subset of the queued messages for processing.", 0085 ; Examiner Note: receiving a message which is queued and must be distributed equates to a request for a load balancing configuration)
As per claim 18, Thoemmes in view of Coleman fully discloses the limitations of claim 14, but does not disclose the provision of the updated load balancing configuration to a CaaS node.
However, Agarwal discloses:
providing the updated first load balancing configuration to a CaaS node, wherein the CaaS node is a node that is configured to perform load balancing in the CaaS system. (“In step 2332, the routine accesses layer-7 load-balancing policies and the local copy of the layout, configuration, and performance data in order to determine to which computational node to forward the service-related message.", 0098”)
The system of Thoemmes in view of Coleman in further view of Agarwal would be capable of passing the load balancing policies, or configuration, to a CaaS node (Jiang, [0051]) configured to perform load balancing.
As per claim 19, Thoemmes in view of Coleman fully discloses the limitations of claim 14, but does not disclose the acquisition of the updated load balancing configuration from a FaaS node.
However, Agarwal discloses:
acquiring the second load balancing configuration from a FaaS node, wherein the FaaS node is a node that is configured to perform load balancing in the FaaS system. (“In step 2332, the routine accesses layer-7 load-balancing policies and the local copy of the layout, configuration, and performance data in order to determine to which computational node to forward the service-related message.", 0098)
The system of Thoemmes in view of Coleman in further view of Agarwal would be capable of acquiring the load balancing policies, or configuration, from an FaaS node (Thoemmes, [0017]) configured to perform load balancing.
Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over Thoemmes (US 20220027203 A1) in view of Coleman (US 11310309 B1) in further view of Agarwal (US 20170214738 A1) in further view of Bai (US 8689021 B1).
As per claim 20, Thoemmes in view of Coleman in further view of Agarwal fully discloses the limitations of claim 19.
Furthermore, Agarwal discloses:
acquiring the second load balancing configuration from the FaaS node comprises: reading the second load balancing configuration from the FaaS node; or receiving the second load balancing configuration from the FaaS node in response to a request for the second load balancing configuration (“The layer-7 load-balancing subcomponent of computational node 1806 consults the layer-7 load-balancing policies 1832 and stored information 1834 in order to determine to which of the n−1 other nodes to redistribute all or a subset of the queued messages for processing.", 0085; Examiner Note: receiving a message which is queued and must be distributed equates to receiving a request for a load balancing configuration))
Thoemmes in view of Coleman in further view of Agarwal fully discloses the above limitations of claim 20 but does not disclose the load balancing configuration information being stored in a look up table.
However, Bai discloses:
the first load balancing configuration and/or the second load balancing configuration is stored in a look-up table. (“Alternative (e.g., if the load balance scenario does not correspond to any of the candidate configurations), the load balance condition can be added as a candidate configuration in the configuration LUT 32.", 0036)
It would have been obvious to one of ordinary skill in the art, before the effective filing date, to combine the teachings of Thoemmes in view of Jiang in further view of Agarwal with those of Bai in order to provide the system for a method for configuring processing cores which facilitates the distribution of workloads among the processing cores such that a power consumption of the computing system is reduced (Bai, [advantage])
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Haghighat (US 20210263779 A1) – discloses a system for providing a FaaS system to users which executes functions in response to events triggered by the users in an execution environment provided by the architectural subsystems.
Mallick (US 20210216228 A1) – discloses an apparatus which is configured to control delivery of IO operations from a host device to at least first and second storage systems being arranged in an active-active configuration.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ROSS MICHAEL VINCENT whose telephone number is (703)756-1408. The examiner can normally be reached Mon-Fri 8:30AM-5:30PM.
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, April Blair can be reached at (571) 270-1014. 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.
/R.M.V./
Examiner, Art Unit 2196
/APRIL Y BLAIR/Supervisory Patent Examiner, Art Unit 2196
Prosecution Insights