DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
The Office Action is in response to claims filed 05/06/2026.
Claims 1-20 are pending.
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, 2, 6, 10, 11, 12, 16 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Banerjee et al. Pat. No. US 20190179678 A1 (hereafter Banerjee) in view of Mason et al. Pat. No. US 10467143 B1, Anonymous IPCOM000254459D (hereafter ‘459D), and Brandt et al. Pat. No. US 20180260337 A1.
With regard to claim 1, Banerjee teaches a computer implemented method for managing function execution, the computer implemented method comprising (¶ [0004] states "an example method for executing functions in a software application using a server cluster that uses functions as a service architecture is described"):
determining, by a number of processor units, whether an address for a called function in a second container called by a calling function in a first container is in a data structure of addresses for called functions within the first container (¶ [0093] states “The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present technical solutions.” ¶ [0080] states “The in-node scheduler 123 on the first host monitors for container invocation requests from the first container 125, at 540.” ¶ [0083] states “the first host 120 maintains a pool or list of containers associated with specific functions in a suspended state. The in-node scheduler 123 determines which container to add to the pool of suspended containers” and “The in-node scheduler 123 checks if the first function being invoked by the first container 125 already has an in-node container 127 that is in the list, at 610.” Examiner’s Note: container invocation requests from the first container is analogous to the calling function in a first container. The in-node container 127 is analogous to the second container that contains the called function. The pool/list of containers is the data structure);
in responsive to determining that the called function in the second container called by the calling function in the first container is not in the data structure of addresses for called functions within the first container, identifying, by the number of processor units, the address of the called function in the second container called by the calling function in the first container using a controller node in a container orchestration platform for the first container and the second container, wherein the first container and the second container are in different nodes of the container orchestration platform (¶ [0088] states “If the in-node container 127 is not created by the in-node scheduler 123, because of lack of available resources at the first host 120, the invocation request from the first container 125 is forwarded to the global scheduler 113, which creates a second container 125 at a second host 120, at 520. As described earlier, the global scheduler 113 identifies the second host 120 from the server cluster 115 based on the available resources using the resource database 117 and invokes the second container 125 at the second host 120 subsequently, at 522 and 524.” ¶ [0005] states “a system includes a server cluster that includes a plurality of host nodes.” ¶ [0060] states “The orchestrator 112 is a management platform for allocating the software to one or more host(s) 120 and instantiating new hosts 120. A host 120 can be a physical, a virtual, or a partitioned server. Further, the orchestrator 112 builds a container 125 from the built application software when requested, creates an identity to the container 125 and provides the container 125 to the host 120 selected to execute the software.” See FIG. 3. Examiner’s Note: invoking the second container at the second host is for the execution of the called function is the identifying of the called function. Orchestrator 112 and Global scheduler 113 are analogous to the container orchestration platform);
adding, by the number of processor units, the address of the called function in the second container called by the calling function in the first container to the data structure of addresses (¶ [0090] states “The in-node scheduler 123 determines whether to save the in-node container 127 for the first function in suspended state based on one or more metrics that the in-node scheduler 123 or a runtime of the first host 120 monitors.”);
and sending, by the number of processor units, a request directly from the calling function in the first container to the called function in the second container using the address without requesting the address from the controller node (¶ [0088] states “the first function invoked from within the first container 125 is executed within the in-node container 127, at 560 and 570.” ¶ [0081] states “the in-node scheduler 123 intercepts the request and attempts to schedule an in-node container 127 corresponding to the request, at 550.” Examiner’s Note: the function invocation is the request that is sent from the calling function in the first container to the called function in the second container. If the in-node scheduler successfully schedules an in-node container to handle the request, then it has scheduled without requesting additional information from the orchestrator/controller node).
Banerjee does not explicitly teach that the data structure is within the first container.
However, in an analogous art, Mason teaches determining, by a number of processor units, whether an address for a called function in a second container called by a calling function in a first container is in a data structure of addresses for called functions within the first container (Col. 8 Lines 57-60 states “Cache data 412a is a portion of the dedicated persistent storage 406a reserved for storing data for the cache that was established for the client 402 in response to the request to establish the cache.” Col. 8 Lines 48-51 states “the computing device launches the container 404a and reserves an amount of dedicated persistent storage 406a of the container 404a.” See FIG. 4. Examiner’s Note: FIG. 4 shows Cache Data 412a within Container 404a);
in responsive to determining that the called function in the second container called by the calling function in the first container is not in the data structure of addresses for called functions within the first container, identifying, by the number of processor units, the address of the called function in the second container called by the calling function in the first container using a controller node in a container orchestration platform for the first container and the second container, wherein the first container and the second container are in different nodes of the container orchestration platform (Col. 8 Lines 57-60 states “Cache data 412a is a portion of the dedicated persistent storage 406a reserved for storing data for the cache that was established for the client 402 in response to the request to establish the cache.” Col. 8 Lines 48-51 states “the computing device launches the container 404a and reserves an amount of dedicated persistent storage 406a of the container 404a.” See FIG. 4. Examiner’s Note: FIG. 4 shows Cache Data 412a within Container 404a);
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine caches within containers of Mason with the container caching of Banerjee. A person having ordinary skill in the art would have been motivated to make this combination “to reduce cost, reduce network delays and traffic, reduce communication errors, and reduce the amount of computing infrastructure/devices required to implement a cache for clients” (Col. 3 Lines 50-53).
Banerjee and Mason do not explicitly teach the use of the address of a called function.
However, in an analogous art, ‘459D teaches determining, by a number of processor units, whether an address for a called function in a second container called by a calling function in a first container is in a data structure of addresses for called functions within the first container (Page 3 Lines 5-6 states “A table containing information about the machine addresses and the call libraries available on that machine is maintained at an API gateway which is the only point of user interaction.” Examiner’s Note: the call libraries are the called functions. The table identifies the addresses of the call libraries);
in responsive to determining that the called function in the second container called by the calling function in the first container is not in the data structure of addresses for called functions within the first container, identifying, by the number of processor units, the address of the called function in the second container called by the calling function in the first container using a controller node in a container orchestration platform for the first container and the second container, wherein the first container and the second container are in different nodes of the container orchestration platform (Page 3 Lines 5-6 states “A table containing information about the machine addresses and the call libraries available on that machine is maintained at an API gateway which is the only point of user interaction.” Examiner’s Note: the call libraries are the called functions. The table identifies the addresses of the call libraries);
adding, by the number of processor units, the address of the called function in the second container called by the calling function in the first container to the data structure of addresses (Page 3 Lines 5-6 states “A table containing information about the machine addresses and the call libraries available on that machine is maintained at an API gateway which is the only point of user interaction.” Examiner’s Note: the call libraries are the called functions. The table identifies the addresses of the call libraries);
and sending, by the number of processor units, a request directly from the calling function in the first container to the called function in the second container using the address without requesting the address from the controller node (Page 3 Lines 5-6 states “A table containing information about the machine addresses and the call libraries available on that machine is maintained at an API gateway which is the only point of user interaction.” Page 3 Lines 6-8 states “A user query for a FaaS function is appropriately redirected by the API gateway based on the information from the table.” Examiner’s Note: the query is the request. The table contains address information related to the FaaS function).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the table of addresses and call libraries of ‘459D with the caller function in a first container calling the called function in the second container of Banerjee and the cache within a container of Mason. As a result, the function in the first container can call the second function using the address of the second function. Additionally, the table containing information about the machine addresses and call libraries are stored within the cache of Mason. A person having ordinary skill in the art would have been motivated to make this combination so that “the entire set of call libraries are distributed over individual machines in the cluster.” Doing so would allow the system access the libraries from all machines in the network without heavy maintenance and a huge duplication of resources (Page 2 paragraph 7 states “To avoid a centralized architecture, or, to avoid installing all the libraries on all the available machines (drawback of heavy maintenance, huge duplication, wastage of resources) the entire set of call libraries are distributed over individual machines in the cluster”). One of ordinary skill in the art recognizes the benefits of increased availability of functions without inefficient data duplication.
Banerjee, Mason, and ‘459D do not explicitly teach the flow of determining if an address is present in a data structure, acquiring the missing address from a costly source in response to the address not being in the data structure, adding the address to the data structure, then using the address to bypass the costly source.
However, in an analogous art, Brandt teaches determining, by a number of processor units, whether an address for a called function in a second container called by a calling function in a first container is in a data structure of addresses for called functions within the first container (¶ [0056] states “a virtual address to real or absolute address translation mapping may be stored in an entry of a structure associated with address translation, such as a translation look-aside buffer (TLB).” ¶ [0067] states “Processing determines whether there is a TLB hit 504.” See FIG. 5);
in responsive to determining that the called function in the second container called by the calling function in the first container is not in the data structure of addresses for called functions within the first container, identifying, by the number of processor units, the address of the called function in the second container called by the calling function in the first container using a controller node in a container orchestration platform for the first container and the second container, wherein the first container and the second container are in different nodes of the container orchestration platform (¶ [0068] states “Assuming that there is a TLB miss, then translation engine 430 is started 508, and the translation engine determines whether a table fetch is needed 510.” ¶ [0068] also states “Assuming that a table fetch is required, then the translation engine sends the table fetch request to the table cache 516 and the cache determines whether there is a hit 514. If no, then the table fetch request miss is resolved via the cache hierarchy 516 using conventional processing.” See FIG. 5. Examiner’s Note: the process of starting the translation engine 508 and the following steps of sending a table fetch request 512 and resolving cache miss 516 are all considered to the call to a remote source, like the controller node, when translation is missing in the TLB);
adding, by the number of processor units, the address of the called function in the second container called by the calling function in the first container to the data structure of addresses (¶ [0068] states “Once all table fetches have been received, then the translation engine obtains a result of the translation request. Once the engine finds the result of the address translation request, the result is written into the translation lookaside buffer.” See FIG. 5 Write Translation Result into TLB 520)
and sending, by the number of processor units, a request directly from the calling function in the first container to the called function in the second container using the address without requesting the address from the controller node (¶ [0056] states “The next time translation for a virtual address is requested, the TLB will be checked and if it is in the TLB, there is a TLB hit and the real or absolute address is retrieved therefrom. Otherwise, a page walk is performed, as described above.”).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the TLB page walk process of Brandt with the container invocations of Banerjee, the caches within containers of Mason, and the addresses of call functions of ‘459D. As a result of the combination, when Banerjee determines if the container is already in the pool/list of containers (¶ [0083]), it is determining if the function addresses of ‘459D are present within the container cache of Mason. If the address is not present, the page walk process of Brandt is applied. In Brandt, the address is determined by the next layer of cache hierarchy (¶ [0068]). In the combination, querying the orchestrator of Banerjee is analogous to visiting a next layer of a hierarchy. Banerjee teaches that the orchestrator may create a second container on a second host (¶ [0088]). In the combination, the response to the query is address of the function within in the second container. The response is then added into the cache of Mason. Next, the first container uses the cached address to send an invocation, or request, to the second container of Banerjee without having to communicate with the orchestrator similar to how in Banerjee the first container communicates with the in-node container (¶ [0088]). Bypassing the orchestrator is analogous to a TLB hit and not needing to use the next layer of the cache hierarchy.
A person having ordinary skill in the art would have been motivated to make this combination “to improve virtual address translation speed” (Brandt ¶ [0004]).
With regard to claim 2, Banerjee, Mason, ‘459D, and Brandt teach the computer implemented method of claim 1. Banerjee additionally teaches wherein identifying, by the number of processor units, the address of the called function in a second container called by the calling function in the first container comprises: identifying, by the number of processor units, the address of the called function in the second container called by the calling function in the first container using the data structure of addresses for called functions in the first container that identifies the address of the called function in the second container (¶ [0083] states “the first host 120 maintains a pool or list of containers associated with specific functions in a suspended state. The in-node scheduler 123 determines which container to add to the pool of suspended containers” and “The in-node scheduler 123 checks if the first function being invoked by the first container 125 already has an in-node container 127 that is in the list, at 610.” Examiner’s Note: the list is the data structure that is used to identify the called function).
Mason additionally teaches identifying, by the number of processor units, the address of the called function in the second container called by the calling function in the first container using the data structure of addresses for called functions in the first container that identifies the address of the called function in the second container (Col. 8 Lines 57-60 states “Cache data 412a is a portion of the dedicated persistent storage 406a reserved for storing data for the cache that was established for the client 402 in response to the request to establish the cache.” Col. 8 Lines 48-51 states “the computing device launches the container 404a and reserves an amount of dedicated persistent storage 406a of the container 404a.” See FIG. 4. Examiner’s Note: FIG. 4 shows Cache Data 412a within Container 404a).
‘459D additionally teaches identifying, by the number of processor units, the address of the called function in the second container called by the calling function in the first container using the data structure of addresses for called functions in the first container that identifies the address of the called function in the second container (Page 3 Lines 5-6 states “A table containing information about the machine addresses and the call libraries available on that machine is maintained at an API gateway which is the only point of user interaction.” Examiner’s Note: the call libraries are the called functions. The table identifies the addresses of the call libraries).
With regard to claim 6, Banerjee and ‘459D teach the computer implemented method of claim 1. To remotivate the teaching, ‘459D teaches a data structure of addresses (Page 3 Lines 5-6 states “A table containing information about the machine addresses and the call libraries available on that machine is maintained at an API gateway which is the only point of user interaction.” Examiner’s Note: the call libraries are the called functions. The table identifies the addresses of the call libraries).
Banerjee additionally teaches further comprising: sending, by the number of processor units, a call to a container orchestration platform for the first container in response to the called function being absent from the data structure of addresses for called functions (¶ [0085] states “if the in-node container 127 does not already exist, or if (referring back to the flowchart in FIG. 5) in case the pool of suspended containers is not maintained, the assignment of the in-node container 127 to the first function further includes, the in-node scheduler 123 checking resource availability for the first function that is to be executed in the new container, at 554.” ¶ [0088] states “If the in-node container 127 is not created by the in-node scheduler 123, because of lack of available resources at the first host 120, the invocation request from the first container 125 is forwarded to the global scheduler 113.” Examiner’s Note: the global scheduler is the container orchestration platform. Due to the in-node container not existing in the suspended container list and if there is not enough resources at the host, the invocation request is sent to the container orchestration platform);
and adding, by the number of processor units, an entry for the called function in the data structure of addresses for called functions in response to receiving the address for the called function (¶ [0083] states “The in-node scheduler 123 determines which container to add to the pool of suspended containers based on one or more metrics that the in-node scheduler 123 monitors.” Examiner’s Note: the pool of suspended containers is the data structure).
Brandt additionally sending, by the number of processor units, a call to a container orchestration platform for the first container in response to the called function being absent from the data structure of addresses for called functions (¶ [0068] states “Assuming that there is a TLB miss, then translation engine 430 is started 508, and the translation engine determines whether a table fetch is needed 510.” ¶ [0068] also states “Assuming that a table fetch is required, then the translation engine sends the table fetch request to the table cache 516 and the cache determines whether there is a hit 514. If no, then the table fetch request miss is resolved via the cache hierarchy 516 using conventional processing.” See FIG. 5. Examiner’s Note: the process of starting the translation engine 508 and the following steps of sending a table fetch request 512 and resolving cache miss 516 are all considered to the call to a remote source, like the container orchestration platform, when translation is missing in the TLB);
and adding, by the number of processor units, an entry for the called function in the data structure of addresses for called functions in response to receiving the address for the called function (¶ [0068] states “Once all table fetches have been received, then the translation engine obtains a result of the translation request. Once the engine finds the result of the address translation request, the result is written into the translation lookaside buffer.” See FIG. 5 Write Translation Result into TLB 520).
With regard to claim 10, Banerjee, Mason, ‘459D, and Brandt teach the computer implemented method of claim 1. Banerjee additionally teaches wherein the container orchestration platform for the first container is bypassed in sending the request directly from the calling function to the called function using the address (¶ [0088] states “If the in-node container 127 is created on the first host 120 that is executing the first container 125, the first function invoked from within the first container 125 is executed within the in-node container 127, at 560 and 570. If the in-node container 127 is not created by the in-node scheduler 123, because of lack of available resources at the first host 120, the invocation request from the first container 125 is forwarded to the global scheduler 113.” Examiner’s Note: when the in-node container is available, the function call goes directly from the first container to the in-node container. It does not go through the global scheduler, or container orchestration platform).
‘459D additionally teaches wherein the container orchestration platform for the first container is bypassed in sending the request directly from the calling function to the called function using the address (Page 3 Lines 6-8 states “A user query for a FaaS function is appropriately redirected by the API gateway based on the information from the table.” Examiner’s Note: the query is the request. The table contains address information related to the FaaS function).
With regard to claim 11, Banerjee teaches a computer system comprising (¶ [0058] states “FIG. 3 depicts an example system 100 for container scheduling in a computer cluster server according to one or more embodiments”):
a number of processor units, wherein the number of processor units executes program instructions to (¶ [0093] states “The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present technical solutions.”):
determine whether an address for a called function in a second container called by a calling function in a first container is in a data structure of addresses for called functions within the first container (¶ [0080] states “The in-node scheduler 123 on the first host monitors for container invocation requests from the first container 125, at 540.” ¶ [0083] states “the first host 120 maintains a pool or list of containers associated with specific functions in a suspended state. The in-node scheduler 123 determines which container to add to the pool of suspended containers” and “The in-node scheduler 123 checks if the first function being invoked by the first container 125 already has an in-node container 127 that is in the list, at 610.” Examiner’s Note: container invocation requests from the first container is analogous to the calling function in a first container. The in-node container 127 is analogous to the second container that contains the called function. The pool/list of containers is the data structure);
in responsive to determining that the called function in the second container called by the calling function in the first container is not in the data structure of addresses for called functions within the first container, identify the address of the called function in the second container called by the calling function in the first container using a controller node in a container orchestration platform for the first container and the second container, wherein the first container and the second container are in different nodes of the container orchestration platform (¶ [0088] states “If the in-node container 127 is not created by the in-node scheduler 123, because of lack of available resources at the first host 120, the invocation request from the first container 125 is forwarded to the global scheduler 113, which creates a second container 125 at a second host 120, at 520. As described earlier, the global scheduler 113 identifies the second host 120 from the server cluster 115 based on the available resources using the resource database 117 and invokes the second container 125 at the second host 120 subsequently, at 522 and 524.” ¶ [0005] states “a system includes a server cluster that includes a plurality of host nodes.” ¶ [0060] states “The orchestrator 112 is a management platform for allocating the software to one or more host(s) 120 and instantiating new hosts 120. A host 120 can be a physical, a virtual, or a partitioned server. Further, the orchestrator 112 builds a container 125 from the built application software when requested, creates an identity to the container 125 and provides the container 125 to the host 120 selected to execute the software.” See FIG. 3. Examiner’s Note: invoking the second container at the second host is for the execution of the called function is the identifying of the called function. Orchestrator 112 and Global scheduler 113 are analogous to the container orchestration platform);
add the address of the called function in the second container called by the calling function in the first container to the data structure of addresses (¶ [0090] states “The in-node scheduler 123 determines whether to save the in-node container 127 for the first function in suspended state based on one or more metrics that the in-node scheduler 123 or a runtime of the first host 120 monitors.”);
and send a request directly from the calling function in the first container to the called function in the second container using the address without requesting the address from the controller node (¶ [0088] states “the first function invoked from within the first container 125 is executed within the in-node container 127, at 560 and 570.” ¶ [0081] states “the in-node scheduler 123 intercepts the request and attempts to schedule an in-node container 127 corresponding to the request, at 550.” Examiner’s Note: the function invocation is the request that is sent from the calling function in the first container to the called function in the second container. If the in-node scheduler successfully schedules an in-node container to handle the request, then it has scheduled without requesting additional information from the orchestrator/controller node).
Banerjee does not explicitly teach that the data structure is within the first container.
However, in an analogous art, Mason teaches determine whether an address for a called function in a second container called by a calling function in a first container is in a data structure of addresses for called functions within the first container (Col. 8 Lines 57-60 states “Cache data 412a is a portion of the dedicated persistent storage 406a reserved for storing data for the cache that was established for the client 402 in response to the request to establish the cache.” Col. 8 Lines 48-51 states “the computing device launches the container 404a and reserves an amount of dedicated persistent storage 406a of the container 404a.” See FIG. 4. Examiner’s Note: FIG. 4 shows Cache Data 412a within Container 404a);
in responsive to determining that the called function in the second container called by the calling function in the first container is not in the data structure of addresses for called functions within the first container, identify the address of the called function in the second container called by the calling function in the first container using a controller node in a container orchestration platform for the first container and the second container, wherein the first container and the second container are in different nodes of the container orchestration platform (Col. 8 Lines 57-60 states “Cache data 412a is a portion of the dedicated persistent storage 406a reserved for storing data for the cache that was established for the client 402 in response to the request to establish the cache.” Col. 8 Lines 48-51 states “the computing device launches the container 404a and reserves an amount of dedicated persistent storage 406a of the container 404a.” See FIG. 4. Examiner’s Note: FIG. 4 shows Cache Data 412a within Container 404a);
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine caches within containers of Mason with the container caching of Banerjee. A person having ordinary skill in the art would have been motivated to make this combination “to reduce cost, reduce network delays and traffic, reduce communication errors, and reduce the amount of computing infrastructure/devices required to implement a cache for clients” (Col. 3 Lines 50-53).
Banerjee and Mason do not explicitly teach the use of the address of a called function.
However, in an analogous art, ‘459D teaches determine whether an address for a called function in a second container called by a calling function in a first container is in a data structure of addresses for called functions within the first container (Page 3 Lines 5-6 states “A table containing information about the machine addresses and the call libraries available on that machine is maintained at an API gateway which is the only point of user interaction.” Examiner’s Note: the call libraries are the called functions. The table identifies the addresses of the call libraries);
in responsive to determining that the called function in the second container called by the calling function in the first container is not in the data structure of addresses for called functions within the first container, identify the address of the called function in the second container called by the calling function in the first container using a controller node in a container orchestration platform for the first container and the second container, wherein the first container and the second container are in different nodes of the container orchestration platform (Page 3 Lines 5-6 states “A table containing information about the machine addresses and the call libraries available on that machine is maintained at an API gateway which is the only point of user interaction.” Examiner’s Note: the call libraries are the called functions. The table identifies the addresses of the call libraries);
add the address of the called function in the second container called by the calling function in the first container to the data structure of addresses (Page 3 Lines 5-6 states “A table containing information about the machine addresses and the call libraries available on that machine is maintained at an API gateway which is the only point of user interaction.” Examiner’s Note: the call libraries are the called functions. The table identifies the addresses of the call libraries);
and send a request directly from the calling function in the first container to the called function in the second container using the address without requesting the address from the controller node (Page 3 Lines 5-6 states “A table containing information about the machine addresses and the call libraries available on that machine is maintained at an API gateway which is the only point of user interaction.” Page 3 Lines 6-8 states “A user query for a FaaS function is appropriately redirected by the API gateway based on the information from the table.” Examiner’s Note: the query is the request. The table contains address information related to the FaaS function)).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the table of addresses and call libraries of ‘459D with the caller function in a first container calling the called function in the second container of Banerjee and the cache within a container of Mason. As a result, the function in the first container can call the second function using the address of the second function. Additionally, the table containing information about the machine addresses and call libraries are stored within the cache of Mason. A person having ordinary skill in the art would have been motivated to make this combination so that “the entire set of call libraries are distributed over individual machines in the cluster.” Doing so would allow the system access the libraries from all machines in the network without heavy maintenance and a huge duplication of resources (Page 2 paragraph 7 states “To avoid a centralized architecture, or, to avoid installing all the libraries on all the available machines (drawback of heavy maintenance, huge duplication, wastage of resources) the entire set of call libraries are distributed over individual machines in the cluster”). One of ordinary skill in the art recognizes the benefits of increased availability of functions without inefficient data duplication.
Banerjee, Mason, and ‘459D do not explicitly teach the flow of determining if an address is present in a data structure, acquiring the missing address from a costly source in response to the address not being in the data structure, adding the address to the data structure, then using the address to bypass the costly source.
However, in an analogous art, Brandt teaches determine whether an address for a called function in a second container called by a calling function in a first container is in a data structure of addresses for called functions within the first container (¶ [0056] states “a virtual address to real or absolute address translation mapping may be stored in an entry of a structure associated with address translation, such as a translation look-aside buffer (TLB).” ¶ [0067] states “Processing determines whether there is a TLB hit 504.” See FIG. 5);
in responsive to determining that the called function in the second container called by the calling function in the first container is not in the data structure of addresses for called functions within the first container, identify the address of the called function in the second container called by the calling function in the first container using a controller node in a container orchestration platform for the first container and the second container, wherein the first container and the second container are in different nodes of the container orchestration platform (¶ [0068] states “Assuming that there is a TLB miss, then translation engine 430 is started 508, and the translation engine determines whether a table fetch is needed 510.” ¶ [0068] also states “Assuming that a table fetch is required, then the translation engine sends the table fetch request to the table cache 516 and the cache determines whether there is a hit 514. If no, then the table fetch request miss is resolved via the cache hierarchy 516 using conventional processing.” See FIG. 5. Examiner’s Note: the process of starting the translation engine 508 and the following steps of sending a table fetch request 512 and resolving cache miss 516 are all considered to the call to a remote source, like the controller node, when translation is missing in the TLB);
add the address of the called function in the second container called by the calling function in the first container to the data structure of addresses (¶ [0068] states “Once all table fetches have been received, then the translation engine obtains a result of the translation request. Once the engine finds the result of the address translation request, the result is written into the translation lookaside buffer.” See FIG. 5 Write Translation Result into TLB 520);
and send a request directly from the calling function in the first container to the called function in the second container using the address without requesting the address from the controller node (¶ [0056] states “The next time translation for a virtual address is requested, the TLB will be checked and if it is in the TLB, there is a TLB hit and the real or absolute address is retrieved therefrom. Otherwise, a page walk is performed, as described above.”).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the TLB page walk process of Brandt with the container invocations of Banerjee, the caches within containers of Mason, and the addresses of call functions of ‘459D. As a result of the combination, when Banerjee determines if the container is already in the pool/list of containers (¶ [0083]), it is determining if the function addresses of ‘459D are present within the container cache of Mason. If the address is not present, the page walk process of Brandt is applied. In Brandt, the address is determined by the next layer of cache hierarchy (¶ [0068]). In the combination, querying the orchestrator of Banerjee is analogous to visiting a next layer of a hierarchy. Banerjee teaches that the orchestrator may create a second container on a second host (¶ [0088]). In the combination, the response to the query is address of the function within in the second container. The response is then added into the cache of Mason. Next, the first container uses the cached address to send an invocation, or request, to the second container of Banerjee without having to communicate with the orchestrator similar to how in Banerjee the first container communicates with the in-node container (¶ [0088]). Bypassing the orchestrator is analogous to a TLB hit and not needing to use the next layer of the cache hierarchy.
A person having ordinary skill in the art would have been motivated to make this combination “to improve virtual address translation speed” (Brandt ¶ [0004]).
With regard to claim 12, Banerjee, Mason, ‘459D, and Brandt teach the computer system of claim 11. Banerjee additionally teaches wherein in identifying, by the number of processor units, the address of the called function in a second container called by the calling function in the first container, the number of processor units executes program instructions to: identify the address of the called function in the second container called by the calling function in the first container using the data structure of addresses for called functions in the first container that identifies the address of the called function in the second container (¶ [0083] states “the first host 120 maintains a pool or list of containers associated with specific functions in a suspended state. The in-node scheduler 123 determines which container to add to the pool of suspended containers” and “The in-node scheduler 123 checks if the first function being invoked by the first container 125 already has an in-node container 127 that is in the list, at 610.” Examiner’s Note: the list is the data structure that is used to identify the called function).
Mason additionally teaches identify the address of the called function in the second container called by the calling function in the first container using a data structure of addresses for called functions in the first container that identifies the address of the called function in the second container (Col. 8 Lines 57-60 states “Cache data 412a is a portion of the dedicated persistent storage 406a reserved for storing data for the cache that was established for the client 402 in response to the request to establish the cache.” Col. 8 Lines 48-51 states “the computing device launches the container 404a and reserves an amount of dedicated persistent storage 406a of the container 404a.” See FIG. 4. Examiner’s Note: FIG. 4 shows Cache Data 412a within Container 404a)
‘459D additionally teaches identify the address of the called function in the second container called by the calling function in the first container using a data structure of addresses for called functions in the first container that identifies the address of the called function in the second container (Page 3 Lines 5-6 states “A table containing information about the machine addresses and the call libraries available on that machine is maintained at an API gateway which is the only point of user interaction.” Examiner’s Note: the call libraries are the called functions. The table identifies the addresses of the call libraries).
With regard to claim 16, Banerjee and ‘459D teach the computer system of claim 11. To remotivate the teaching, ‘459D teaches the data structure of addresses (Page 3 Lines 5-6 states “A table containing information about the machine addresses and the call libraries available on that machine is maintained at an API gateway which is the only point of user interaction.” Examiner’s Note: the call libraries are the called functions. The table identifies the addresses of the call libraries).
Banerjee additionally teaches wherein the number of processor units executes program instructions to: send a call to the container orchestration platform for the first container in response to the called function being absent from the data structure of addresses for called functions (¶ [0085] states “if the in-node container 127 does not already exist, or if (referring back to the flowchart in FIG. 5) in case the pool of suspended containers is not maintained, the assignment of the in-node container 127 to the first function further includes, the in-node scheduler 123 checking resource availability for the first function that is to be executed in the new container, at 554.” ¶ [0088] states “If the in-node container 127 is not created by the in-node scheduler 123, because of lack of available resources at the first host 120, the invocation request from the first container 125 is forwarded to the global scheduler 113.” Examiner’s Note: the global scheduler is the container orchestration platform. Due to the in-node container not existing in the suspended container list and if there is not enough resources at the host, the invocation request is sent to the container orchestration platform);
and adding an entry for the called function in the data structure of addresses for called functions in response to receiving the address for the called function (¶ [0083] states “The in-node scheduler 123 determines which container to add to the pool of suspended containers based on one or more metrics that the in-node scheduler 123 monitors.” Examiner’s Note: the pool of suspended containers is the data structure).
Brandt additionally teaches send a call to the container orchestration platform for the first container in response to the called function being absent from the data structure of addresses for called functions (¶ [0068] states “Assuming that there is a TLB miss, then translation engine 430 is started 508, and the translation engine determines whether a table fetch is needed 510.” ¶ [0068] also states “Assuming that a table fetch is required, then the translation engine sends the table fetch request to the table cache 516 and the cache determines whether there is a hit 514. If no, then the table fetch request miss is resolved via the cache hierarchy 516 using conventional processing.” See FIG. 5. Examiner’s Note: the process of starting the translation engine 508 and the following steps of sending a table fetch request 512 and resolving cache miss 516 are all considered to the call to a remote source, like the container orchestration platform, when translation is missing in the TLB);
and adding an entry for the called function in the data structure of addresses for called functions in response to receiving the address for the called function (¶ [0068] states “Once all table fetches have been received, then the translation engine obtains a result of the translation request. Once the engine finds the result of the address translation request, the result is written into the translation lookaside buffer.” See FIG. 5 Write Translation Result into TLB 520).
With regard to claim 20, Banerjee teaches a computer program product for managing function execution, the computer program product comprising a computer readable storage medium having program instructions embodied therewith the program instructions executable by a computer system to cause the computer system to perform a method of (¶ [0093] states “The present technical solutions may be a system, a method, and/or a computer program product at any possible technical detail level of integration. The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present technical solutions”):
determining, by a number of processor units, whether an address for a called function in a second container called by a calling function in a first container is in a data structure of addresses for called functions within the first container (¶ [0093] states “The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present technical solutions.” ¶ [0080] states “The in-node scheduler 123 on the first host monitors for container invocation requests from the first container 125, at 540.” ¶ [0083] states “the first host 120 maintains a pool or list of containers associated with specific functions in a suspended state. The in-node scheduler 123 determines which container to add to the pool of suspended containers” and “The in-node scheduler 123 checks if the first function being invoked by the first container 125 already has an in-node container 127 that is in the list, at 610.” Examiner’s Note: container invocation requests from the first container is analogous to the calling function in a first container. The in-node container 127 is analogous to the second container that contains the called function. The pool/list of containers is the data structure);
in responsive to determining that the called function in the second container called by the calling function in the first container is not in the data structure of addresses for called functions within the first container, identifying, by the number of processor units, the address of the called function in the second container called by the calling function in the first container using a controller node in a container orchestration platform for the first container and the second container, wherein the first container and the second container are in different nodes of the container orchestration platform (¶ [0088] states “If the in-node container 127 is not created by the in-node scheduler 123, because of lack of available resources at the first host 120, the invocation request from the first container 125 is forwarded to the global scheduler 113, which creates a second container 125 at a second host 120, at 520. As described earlier, the global scheduler 113 identifies the second host 120 from the server cluster 115 based on the available resources using the resource database 117 and invokes the second container 125 at the second host 120 subsequently, at 522 and 524.” ¶ [0005] states “a system includes a server cluster that includes a plurality of host nodes.” ¶ [0060] states “The orchestrator 112 is a management platform for allocating the software to one or more host(s) 120 and instantiating new hosts 120. A host 120 can be a physical, a virtual, or a partitioned server. Further, the orchestrator 112 builds a container 125 from the built application software when requested, creates an identity to the container 125 and provides the container 125 to the host 120 selected to execute the software.” See FIG. 3. Examiner’s Note: invoking the second container at the second host is for the execution of the called function is the identifying of the called function. Orchestrator 112 and Global scheduler 113 are analogous to the container orchestration platform);
adding, by the number of processor units, the address of the called function in the second container called by the calling function in the first container to the data structure of addresses (¶ [0090] states “The in-node scheduler 123 determines whether to save the in-node container 127 for the first function in suspended state based on one or more metrics that the in-node scheduler 123 or a runtime of the first host 120 monitors.”);
and sending, by the number of processor units, a request directly from the calling function in the first container to the called function in the second container using the address without requesting the address from the controller node (¶ [0088] states “the first function invoked from within the first container 125 is executed within the in-node container 127, at 560 and 570.” ¶ [0081] states “the in-node scheduler 123 intercepts the request and attempts to schedule an in-node container 127 corresponding to the request, at 550.” Examiner’s Note: the function invocation is the request that is sent from the calling function in the first container to the called function in the second container. If the in-node scheduler successfully schedules an in-node container to handle the request, then it has scheduled without requesting additional information from the orchestrator/controller node).
Banerjee does not explicitly teach that the data structure is within the first container.
However, in an analogous art, Mason teaches determining, by a number of processor units, whether an address for a called function in a second container called by a calling function in a first container is in a data structure of addresses for called functions within the first container (Col. 8 Lines 57-60 states “Cache data 412a is a portion of the dedicated persistent storage 406a reserved for storing data for the cache that was established for the client 402 in response to the request to establish the cache.” Col. 8 Lines 48-51 states “the computing device launches the container 404a and reserves an amount of dedicated persistent storage 406a of the container 404a.” See FIG. 4. Examiner’s Note: FIG. 4 shows Cache Data 412a within Container 404a);
in responsive to determining that the called function in the second container called by the calling function in the first container is not in the data structure of addresses for called functions within the first container, identifying, by the number of processor units, the address of the called function in the second container called by the calling function in the first container using a controller node in a container orchestration platform for the first container and the second container, wherein the first container and the second container are in different nodes of the container orchestration platform (Col. 8 Lines 57-60 states “Cache data 412a is a portion of the dedicated persistent storage 406a reserved for storing data for the cache that was established for the client 402 in response to the request to establish the cache.” Col. 8 Lines 48-51 states “the computing device launches the container 404a and reserves an amount of dedicated persistent storage 406a of the container 404a.” See FIG. 4. Examiner’s Note: FIG. 4 shows Cache Data 412a within Container 404a);
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine caches within containers of Mason with the container caching of Banerjee. A person having ordinary skill in the art would have been motivated to make this combination “to reduce cost, reduce network delays and traffic, reduce communication errors, and reduce the amount of computing infrastructure/devices required to implement a cache for clients” (Col. 3 Lines 50-53).
Banerjee and Mason do not explicitly teach the use of the address of a called function.
However, in an analogous art, ‘459D teaches determining, by a number of processor units, whether an address for a called function in a second container called by a calling function in a first container is in a data structure of addresses for called functions within the first container (Page 3 Lines 5-6 states “A table containing information about the machine addresses and the call libraries available on that machine is maintained at an API gateway which is the only point of user interaction.” Examiner’s Note: the call libraries are the called functions. The table identifies the addresses of the call libraries);
in responsive to determining that the called function in the second container called by the calling function in the first container is not in the data structure of addresses for called functions within the first container, identifying, by the number of processor units, the address of the called function in the second container called by the calling function in the first container using a controller node in a container orchestration platform for the first container and the second container, wherein the first container and the second container are in different nodes of the container orchestration platform (Page 3 Lines 5-6 states “A table containing information about the machine addresses and the call libraries available on that machine is maintained at an API gateway which is the only point of user interaction.” Examiner’s Note: the call libraries are the called functions. The table identifies the addresses of the call libraries);
adding, by the number of processor units, the address of the called function in the second container called by the calling function in the first container to the data structure of addresses (Page 3 Lines 5-6 states “A table containing information about the machine addresses and the call libraries available on that machine is maintained at an API gateway which is the only point of user interaction.” Examiner’s Note: the call libraries are the called functions. The table identifies the addresses of the call libraries);
and sending, by the number of processor units, a request directly from the calling function in the first container to the called function in the second container using the address without requesting the address from the controller node (Page 3 Lines 5-6 states “A table containing information about the machine addresses and the call libraries available on that machine is maintained at an API gateway which is the only point of user interaction.” Page 3 Lines 6-8 states “A user query for a FaaS function is appropriately redirected by the API gateway based on the information from the table.” Examiner’s Note: the query is the request. The table contains address information related to the FaaS function).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the table of addresses and call libraries of ‘459D with the caller function in a first container calling the called function in the second container of Banerjee and the cache within a container of Mason. As a result, the function in the first container can call the second function using the address of the second function. Additionally, the table containing information about the machine addresses and call libraries are stored within the cache of Mason. A person having ordinary skill in the art would have been motivated to make this combination so that “the entire set of call libraries are distributed over individual machines in the cluster.” Doing so would allow the system access the libraries from all machines in the network without heavy maintenance and a huge duplication of resources (Page 2 paragraph 7 states “To avoid a centralized architecture, or, to avoid installing all the libraries on all the available machines (drawback of heavy maintenance, huge duplication, wastage of resources) the entire set of call libraries are distributed over individual machines in the cluster”). One of ordinary skill in the art recognizes the benefits of increased availability of functions without inefficient data duplication.
Banerjee, Mason, and ‘459D do not explicitly teach the flow of determining if an address is present in a data structure, acquiring the missing address from a costly source in response to the address not being in the data structure, adding the address to the data structure, then using the address to bypass the costly source.
However, in an analogous art, Brandt teaches determining, by a number of processor units, whether an address for a called function in a second container called by a calling function in a first container is in a data structure of addresses for called functions within the first container (¶ [0056] states “a virtual address to real or absolute address translation mapping may be stored in an entry of a structure associated with address translation, such as a translation look-aside buffer (TLB).” ¶ [0067] states “Processing determines whether there is a TLB hit 504.” See FIG. 5);
in responsive to determining that the called function in the second container called by the calling function in the first container is not in the data structure of addresses for called functions within the first container, identifying, by the number of processor units, the address of the called function in the second container called by the calling function in the first container using a controller node in a container orchestration platform for the first container and the second container, wherein the first container and the second container are in different nodes of the container orchestration platform (¶ [0068] states “Assuming that there is a TLB miss, then translation engine 430 is started 508, and the translation engine determines whether a table fetch is needed 510.” ¶ [0068] also states “Assuming that a table fetch is required, then the translation engine sends the table fetch request to the table cache 516 and the cache determines whether there is a hit 514. If no, then the table fetch request miss is resolved via the cache hierarchy 516 using conventional processing.” See FIG. 5. Examiner’s Note: the process of starting the translation engine 508 and the following steps of sending a table fetch request 512 and resolving cache miss 516 are all considered to the call to a remote source, like the controller node, when translation is missing in the TLB);
adding, by the number of processor units, the address of the called function in the second container called by the calling function in the first container to the data structure of addresses (¶ [0068] states “Once all table fetches have been received, then the translation engine obtains a result of the translation request. Once the engine finds the result of the address translation request, the result is written into the translation lookaside buffer.” See FIG. 5 Write Translation Result into TLB 520)
and sending, by the number of processor units, a request directly from the calling function in the first container to the called function in the second container using the address without requesting the address from the controller node (¶ [0056] states “The next time translation for a virtual address is requested, the TLB will be checked and if it is in the TLB, there is a TLB hit and the real or absolute address is retrieved therefrom. Otherwise, a page walk is performed, as described above.”).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the TLB page walk process of Brandt with the container invocations of Banerjee, the caches within containers of Mason, and the addresses of call functions of ‘459D. As a result of the combination, when Banerjee determines if the container is already in the pool/list of containers (¶ [0083]), it is determining if the function addresses of ‘459D are present within the container cache of Mason. If the address is not present, the page walk process of Brandt is applied. In Brandt, the address is determined by the next layer of cache hierarchy (¶ [0068]). In the combination, querying the orchestrator of Banerjee is analogous to visiting a next layer of a hierarchy. Banerjee teaches that the orchestrator may create a second container on a second host (¶ [0088]). In the combination, the response to the query is address of the function within in the second container. The response is then added into the cache of Mason. Next, the first container uses the cached address to send an invocation, or request, to the second container of Banerjee without having to communicate with the orchestrator similar to how in Banerjee the first container communicates with the in-node container (¶ [0088]). Bypassing the orchestrator is analogous to a TLB hit and not needing to use the next layer of the cache hierarchy.
A person having ordinary skill in the art would have been motivated to make this combination “to improve virtual address translation speed” (Brandt ¶ [0004]).
Claim(s) 3 and 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Banerjee in view of Mason, ‘459D, and Brandt and further in view of Wawrzoniak et al., “Boxer: Data Analytics on Network--enabled Serverless Platforms,” (hereafter Wawrzoniak).
With regard to claim 3, Banerjee, Mason, ‘459D, and Brandt teach the computer implemented method of claim 1. Banerjee additionally teaches wherein sending, by the number of processor units, the request directly to the called function using the address comprises: sending the request directly from the calling function in the first container in a first node to the called function in the second container in a second node using a first network endpoint for the first node and a second network endpoint for the second node using a function name and an IP address and port in the address (¶ [0088] states “the first function invoked from within the first container 125 is executed within the in-node container 127, at 560 and 570.” ¶ [0076] states "In some embodiments, the system 200 may further include a network interface 260 for coupling to a network 265. The network 265 may be an IP-based network for communication between the system 200.” See FIG. 4 Network Interface 260. Examiner’s Note: the function invocation is the request that is sent from the calling function in the first container to the called function in the second container. The network interface card is the network endpoint and is present in all hosts).
‘459D teaches sending the request directly from the calling function in the first container in a first node to the called function in the second container in a second node using a first network endpoint for the first node and a second network endpoint for the second node using a function name and an IP address and port in the address (Page 3 Lines 5-8 state “A table containing information about the machine addresses and the call libraries available on that machine is maintained at an API gateway which is the only point of user interaction. A user query for a FaaS function is appropriately redirected by the API gateway based on the information from the table.” Examiner’s Note: the table contains machine addresses and names of call libraries, or functions).
Banerjee, Mason, ‘459D, and Brandt do not explicitly teach using the network endpoints, IP address, and port in the address to send the request.
However, in an analogous art, Wawrzoniak teaches sending the request directly from the calling function in the first container in a first node to the called function in the second container in a second node using a first network endpoint for the first node and a second network endpoint for the second node using a function name and an IP address and port in the address (Page 3 Lines 1-5 states “a system enabling network communication across serverless functions, Boxer leverages TCP/IP, a reliable data stream protocol, and standard sockets, to allow functions to communicate directly with each other without an intermediary service.” Examiner’s Note: Boxer uses TCP/IP and standard sockets which include the IP address and port).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the use of TCP/IP and sockets for function to function communication of Wawrzoniak with the system of a function in a container calling another function in another container using a data structure for function addresses of Banerjee and ‘459D, and the cache within containers of Mason and the TLB flow of Brandt. A person having ordinary skill in the art would have been motivated to make this combination for the purpose of improving function to function performance and latency (Wawrzoniak Page 1 Lines 13-21 states “Our benchmarks show a speedup as high as 11 x in TPC-H queries over systems that use cloud storage to communicate across functions, sustained function-to function throughput of 621 Mbit/s, and a round-trip latency of less than 1 ms”).
With regard to claim 13, Banerjee, Mason, ‘459D, and Brandt teach the computer system of claim 11. Banerjee additionally teaches wherein in sending the request directly to the called function using the address, the number of processor units executes program instructions to: send the request directly from the calling function in the first container in a first node to the called function in the second container in a second node using a first network endpoint for the first node and a second network endpoint for the second node using a function name and an IP address and port in the address (¶ [0088] states “the first function invoked from within the first container 125 is executed within the in-node container 127, at 560 and 570.” ¶ [0076] states "In some embodiments, the system 200 may further include a network interface 260 for coupling to a network 265. The network 265 may be an IP-based network for communication between the system 200.” See FIG. 4 Network Interface 260. Examiner’s Note: the function invocation is the request that is sent from the calling function in the first container to the called function in the second container. The network interface card is the network endpoint and is present in all hosts).
‘459D additionally teaches send the request directly from the calling function in the first container in a first node to the called function in the second container in a second node using a first network endpoint for the first node and a second network endpoint for the second node using a function name and an IP address and port in the address (Page 3 Lines 5-8 state “A table containing information about the machine addresses and the call libraries available on that machine is maintained at an API gateway which is the only point of user interaction. A user query for a FaaS function is appropriately redirected by the API gateway based on the information from the table.” Examiner’s Note: the table contains machine addresses and names of call libraries, or functions).
Banerjee, Mason, ‘459D, and Brandt do not explicitly teach using the network endpoints, IP address, and port in the address to send the request.
However, in an analogous art, Wawrzoniak teaches send the request directly from the calling function in the first container in a first node to the called function in the second container in a second node using a first network endpoint for the first node and a second network endpoint for the second node using a function name and an IP address and port in the address (Page 3 Lines 1-5 states “a system enabling network communication across serverless functions, Boxer leverages TCP/IP, a reliable data stream protocol, and standard sockets, to allow functions to communicate directly with each other without an intermediary service.” Examiner’s Note: Boxer uses TCP/IP and standard sockets which include the IP address and port).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the use of TCP/IP and sockets for function to function communication of Wawrzoniak with the system of a function in a container calling another function in another container using a data structure for function addresses of Banerjee and ‘459D, and the cache within containers of Mason and the TLB flow of Brandt. A person having ordinary skill in the art would have been motivated to make this combination for the purpose of improving function to function performance and latency (Wawrzoniak Page 1 Lines 13-21 states “Our benchmarks show a speedup as high as 11 x in TPC-H queries over systems that use cloud storage to communicate across functions, sustained function-to function throughput of 621 Mbit/s, and a round-trip latency of less than 1 ms”).
Claim(s) 4, 5, 14, and 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Banerjee in view of Mason, ‘459D, and Brandt, and further in view of Adams et al. Pat. No. US 20190334876 A1 (hereafter Adams).
With regard to claim 4, Banerjee, Mason, ‘459D, and Brandt teach the computer implemented method of claim 1. Banerjee additionally teaches wherein sending, by the number of processor units, the request directly to the called function using the address comprises: sending, by the number of processor units, the request directly from calling function in the first container to the called function in a second container using a local communications medium in a node in which the first container and the second container are located using function name and local medium identifier (¶ [0088] states “the first function invoked from within the first container 125 is executed within the in-node container 127, at 560 and 570.” Examiner’s Note: the function invocation is the request that is sent from the calling function in the first container to the called function in the second container. Since both containers are on the same host, a local communications medium is used).
‘459D teaches sending, by the number of processor units, the request directly from calling function in the first container to the called function in a second container using a local communications medium in a node in which the first container and the second container are located using function name and local medium identifier (Page 3 Lines 5-6 states “A table containing information about the machine addresses and the call libraries available on that machine is maintained at an API gateway which is the only point of user interaction.” Examiner’s Note: the call libraries are the called functions. The table identifies the addresses and names of the call libraries).
Banerjee, Mason, ‘459D, and Brandt do not explicitly teach a local medium identifier.
However, in an analogous art, Adams teaches sending, by the number of processor units, the request directly from calling function in the first container to the called function in a second container using a local communications medium in a node in which the first container and the second container are located using function name and local medium identifier (Adams ¶ [0102] states “applications may be arranged to select a mechanism or method for communicating handshake packages or message packages to other applications. The particular method may be selected from one or more communication facilities, such as, one or more network interfaces, one or more network protocols, one or more inter-process communication methods (e.g., shared files, shared memory, sockets, or the like), message queues, store-and-forward pipelines, or the like.” Examiner’s Note: to select a communication method from a plurality of available methods requires using an identifier. Shared files, shared memory, and pipelines are local mediums of communication).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the selection of communication methods of Adams with the environment of containers communication with each other within a same host using function names and addresses of Banerjee and ‘459D, and the cache within containers of Mason and the TLB flow of Brandt. As a result, a first container can choose the communication method when communicating with a second container. A person having ordinary skill in the art would have been motivated to make this combination so that applications can determine which communication would be optimal to use. Additionally, Adams teaches “more than one communication facility may be used to communicate the handshake packages or message packages between applications” (¶ [0102]). Adams then states “this improves performance of conventional networks because the secure session between application client 408 and application server 412 may be unaffected by changes to network security options or functionality of the underlying networks” (¶ [0103]). One of ordinary skill in the art recognizes the benefits of flexible and secure communication.
With regard to claim 5, Banerjee, Mason, ‘459D, Brandt and Adams teach the computer implemented method of claim 4. Adams additionally teaches wherein the local communications medium is selected from a group consisting of a shared memory, a file, and a pipeline (¶ [0102] states “applications may be arranged to select a mechanism or method for communicating handshake packages or message packages to other applications. The particular method may be selected from one or more communication facilities, such as, one or more network interfaces, one or more network protocols, one or more inter-process communication methods (e.g., shared files, shared memory, sockets, or the like), message queues, store-and-forward pipelines, or the like”).
With regard to claim 14, Banerjee, Mason, ‘459D, and Brandt teach the computer system of claim 11. Banerjee additionally teaches wherein in sending the request directly to the called function using the address, the number of processor units executes program instructions to: send the request directly from calling function in the first container to the called function in a second container using a local communications medium in a node in which the first container and the second container are located using function name and local medium identifier (¶ [0088] states “the first function invoked from within the first container 125 is executed within the in-node container 127, at 560 and 570.” Examiner’s Note: the function invocation is the request that is sent from the calling function in the first container to the called function in the second container. Since both containers are on the same host, a local communications medium is used).
‘459D additionally teaches send the request directly from calling function in the first container to the called function in a second container using a local communications medium in a node in which the first container and the second container are located using function name and local medium identifier (Page 3 Lines 5-6 states “A table containing information about the machine addresses and the call libraries available on that machine is maintained at an API gateway which is the only point of user interaction.” Examiner’s Note: the call libraries are the called functions. The table identifies the addresses and names of the call libraries).
Banerjee, Mason, ‘459D, and Brandt do not explicitly teach a local medium identifier.
However, in an analogous art, Adams send the request directly from calling function in the first container to the called function in a second container using a local communications medium in a node in which the first container and the second container are located using function name and local medium identifier (Adams ¶ [0102] states “applications may be arranged to select a mechanism or method for communicating handshake packages or message packages to other applications. The particular method may be selected from one or more communication facilities, such as, one or more network interfaces, one or more network protocols, one or more inter-process communication methods (e.g., shared files, shared memory, sockets, or the like), message queues, store-and-forward pipelines, or the like.” Examiner’s Note: to select a communication method from a plurality of available methods requires using an identifier. Shared files, shared memory, and pipelines are local mediums of communication)
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the selection of communication methods of Adams with the environment of containers communication with each other within a same host using function names and addresses of Banerjee and ‘459D and the cache within containers of Mason and the TLB flow of Brandt. As a result, a first container can choose the communication method when communicating with a second container. A person having ordinary skill in the art would have been motivated to make this combination so that applications can determine which communication would be optimal to use. Additionally, Adams teaches “more than one communication facility may be used to communicate the handshake packages or message packages between applications” (¶ [0102]). Adams then states “this improves performance of conventional networks because the secure session between application client 408 and application server 412 may be unaffected by changes to network security options or functionality of the underlying networks” (¶ [0103]). One of ordinary skill in the art recognizes the benefits of flexible and secure communication.
With regard to claim 15, Banerjee, Mason, ‘459D, Brand, and Adams teach the computer system of claim 14. Adams additionally teaches wherein the local communications medium is selected from a group consisting of a shared memory, a file, and a pipeline (¶ [0102] states “applications may be arranged to select a mechanism or method for communicating handshake packages or message packages to other applications. The particular method may be selected from one or more communication facilities, such as, one or more network interfaces, one or more network protocols, one or more inter-process communication methods (e.g., shared files, shared memory, sockets, or the like), message queues, store-and-forward pipelines, or the like”).
Claim(s) 7 and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Banerjee in view of Mason, ‘459D, and Brandt, and further in view of Navasivasakthivelsamy Pat. No. US 20190238411 A1 (hereafter Navasivasakthivelsamy).
With regard to claim 7, Banerjee, Mason, ‘459D, and Brandt teach the computer implemented method of claim 1. Banerjee additionally teaches further comprising: placing, by the number of processor units, containers for functions in a set of node nodes based on communications patterns, wherein local communications is increased (¶ [0078] states “Creating the first container 125 on the first host 120 includes checking the resources database 117 to select the first host based on the availability of resources that the software application uses, at 522” and “Once the first host 120 is selected, the first container 125 is initiated on the first host 120 and assigned for executing the software application”).
Banerjee, Mason, ‘459D, and Brandt do not explicitly teach placing containers for functions based on communication patterns.
However, in an analogous art, Navasivasakthivelsamy teaches placing, by the number of processor units, containers for functions in a set of node nodes based on communications patterns, wherein local communications is increased (¶ [0039] states “determining an optimal host machine to place a virtual machine based on its network communication patterns with other virtual machines.” ¶ [0043] states “the message from User VM 105a-1 only has to travel across leaf switch 220 to reach User VM 105b-1. Consequently, the communication between User VM 105a-1 and User VM 105b-1 consumes less networking bandwidth than the communication between User VM 105a-2 and User VM 105d-2.” See FIG. 2A. Examiner’s Note: the rack 201 is an example of a “node.” Local communication is increased when VMs are placed in the same rack such that communications only have to go through a leaf switch and do not have to go through a spine switch).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the placement strategy to avoid communication between racks and through multiple switches of Navasivasakthivelsamy with the placement of containers in a set of nodes of Banerjee and ‘459D, and the cache within containers of Mason and the TLB flow of Brandt. A person having ordinary skill in the art would have been motivated to make this combination because it would “dramatically [reduce] network latency, network congestion, and the consumption of vital networking bandwidth” (¶ [0023]).
With regard to claim 17, Banerjee, Mason, ‘459D, and Brandt teach the computer system of claim 11. Banerjee additionally teaches wherein the number of processor units executes program instructions to: place containers for functions in nodes based on communications patterns, wherein local communications is increased (¶ [0078] states “Creating the first container 125 on the first host 120 includes checking the resources database 117 to select the first host based on the availability of resources that the software application uses, at 522” and “Once the first host 120 is selected, the first container 125 is initiated on the first host 120 and assigned for executing the software application”).
Banerjee, Mason, ‘459D, and Brandt do not explicitly teach placing containers for functions based on communication patterns.
However, in an analogous art, Navasivasakthivelsamy teaches place containers for functions in nodes based on communications patterns, wherein local communications is increased (¶ [0039] states “determining an optimal host machine to place a virtual machine based on its network communication patterns with other virtual machines.” ¶ [0043] states “the message from User VM 105a-1 only has to travel across leaf switch 220 to reach User VM 105b-1. Consequently, the communication between User VM 105a-1 and User VM 105b-1 consumes less networking bandwidth than the communication between User VM 105a-2 and User VM 105d-2.” See FIG. 2A. Examiner’s Note: the rack 201 is an example of a “node.” Local communication is increased when VMs are placed in the same rack such that communications only have to go through a leaf switch and do not have to go through a spine switch).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the placement strategy to avoid communication between racks and through multiple switches of Navasivasakthivelsamy with the placement of containers in a set of nodes of Banerjee and ‘459D, and the cache within containers of Mason and the TLB flow of Brandt. A person having ordinary skill in the art would have been motivated to make this combination because it would “dramatically [reduce] network latency, network congestion, and the consumption of vital networking bandwidth” (¶ [0023]).
Claim(s) 8 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Banerjee in view of Mason, ‘459D, Brandt, and Navasivasakthivelsamy, and further in view of Bhasi et al., “Kraken : Adaptive Container Provisioning for Deploying Dynamic DAGs in Serverless Platforms,” (hereafter Bhasi) and Broecheler Pat. No. US 10698955 B1 (hereafter Broecheler).
With regard to claim 8, Banerjee, Mason, ‘459D, Brandt, and Navasivasakthivelsamy teach the computer implemented method of claim 7. Banerjee additionally teaches and assigning, by the number of processor units, containers for the functions to nodes based on the functions in the subgraphs (¶ [0078] states “Creating the first container 125 on the first host 120 includes checking the resources database 117 to select the first host based on the availability of resources that the software application uses, at 522” and “Once the first host 120 is selected, the first container 125 is initiated on the first host 120 and assigned for executing the software application”).
Navasivasakthivelsamy additionally teaches splitting, by the number of processor units, the directed acyclic graph into subgraphs based on increase local communications between functions (¶ [0039] states “determining an optimal host machine to place a virtual machine based on its network communication patterns with other virtual machines”).
Banerjee, Mason, ‘459D, Brandt, and Navasivasakthivelsamy do not explicitly teach the directed acyclic graph algorithm.
However, in an analogous art, Bhasi additionally teaches creating, by the number of processor units, a directed acyclic graph for a workflow in an application in which the workflow calls functions, wherein the nodes in the directed acyclic graph represent functions and edges represent calls made by the functions (Page 154 Lines 16-24 states “applications can be modeled as a Directed Acyclic Graph (DAG) where each vertex/stage is a function. Henceforth, we will use the terms ‘function’ and ‘stage’ interchangeably. We define a workflow or path within an application as a sequence of vertices and the edges that connect them, starting from the first vertex (or vertices) and ending at the last vertex (or vertices). An application invokes functions in the sequence as specified by the path in the DAG.” Examiner’s Note: the vertex that is a function represents the node in the DAG. Paths represent function invocation sequences. Therefore, edges represent function calls between functions);
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the DAG with nodes representing functions and edges representing function calls of Bhasi with the computer system for placing containers based communication patterns for inter-container communication between functions of Banerjee, ‘459D, and Navasivasakthivelsamy, and the cache within containers of Mason and the TLB flow of Brandt. A person having ordinary skill in the art would have been motivated to make this combination because “Kraken spawns up to 76% fewer containers, thereby improving container utilization and saving cluster-wide energy by up to 4x and 48%, respectively, when compared to state-of-the art schedulers employed in serverless platforms” (Page 153 Lines 21-25).
Banerjee, Mason, ‘459D, Brandt, Navasivasakthivelsamy, and Bhasi do not explicitly teach splitting the directed acyclic graph into subgraphs.
However, in an analogous art, Broecheler teaches splitting, by the number of processor units, the directed acyclic graph into subgraphs based on increase local communications between functions (Col. 3 Lines 1-5 states “Partitioning a graph database is disclosed. In some embodiments, vertices of the graph database are each assigned to nodes (e.g., processing servers that will store data of the vertex and/or handle query processing for the vertex) according to abstract paths between the vertices. For example, abstract paths indicate relationships between vertices for purposes of graph partitioning.” See FIG. 1E. Col. 11 Lines 47-49 states “Circle 124 includes vertices assigned to a first node and circle 126 includes vertices assigned to a second node.” Examiner’s Note: the “nodes” represent the subgraphs because the comprise of vertices);
and assigning, by the number of processor units, containers for the functions to nodes based on the functions in the subgraphs (See FIG. 1E. Col. 11 Lines 47-49 states “Circle 124 includes vertices assigned to a first node and circle 126 includes vertices assigned to a second node.” Examiner’s Note: the “nodes” represent the subgraphs because they comprise of vertices)
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the partitioning of the graph based on abstract paths of Broecheler with the computing system and directed acyclic graph of Banerjee, Mason, ‘459D, Brandt, Navasivasakthivelsamy, and Bhasi. The combination of Banerjee, Mason, ‘459D, Brandt, Navasivasakthivelsamy, Bhasi, and Broecheler results in a computer system that places the containers with functions of Banerjee. Bhasi teaches the directed acyclic graph that has nodes representing functions of Banerjee and edges representing the function invocations of Banerjee. The DAG of Bhasi can then be partitioned according to the partitioning strategy of Broecheler. However, instead of using abstract paths of Broecheler, the network communication patterns between virtual machines of Navasivasakthivelsamy can be used. After the DAG has been partitioned, the containers of Banerjee can now be placed according to the subgraphs to increase local communications.
A person having ordinary skill in the art would have been motivated to make this combination because “The division of a graph database may be optimized to enable efficient storage and/or load balancing amongst the nodes” (Col. 4 Lines 26-29). Additionally, “tradeoffs have to be made with respect to data locality and performance. Additionally, as the graph database becomes larger, it becomes inefficient and often impractical to store the database on a single storage/machine. Efficiently and effectively dividing up graph data for storage in different locations becomes important.” (Col. 1 Lines 19-25). By carefully partitioning the graph, data can be stored efficiently in multiple computers. In a similar way, by carefully deciding which containers to place on a same physical machine, function calls between containers can be improved.
With regard to claim 18, Banerjee, ‘459D, and Navasivasakthivelsamy teach the computer system of claim 17. Banerjee additionally teaches and assign containers for the functions to nodes based on the functions in the subgraphs (¶ [0078] states “Creating the first container 125 on the first host 120 includes checking the resources database 117 to select the first host based on the availability of resources that the software application uses, at 522” and “Once the first host 120 is selected, the first container 125 is initiated on the first host 120 and assigned for executing the software application”).
Navasivasakthivelsamy additionally teaches split the directed acyclic graph into subgraphs based on increase local communications between functions (¶ [0039] states “determining an optimal host machine to place a virtual machine based on its network communication patterns with other virtual machines”);
Banerjee, ‘459D, and Navasivasakthivelsamy do not explicitly teach the directed acyclic graph algorithm.
However, in an analogous art, Bhasi additionally teaches create a directed acyclic graph for a workflow in an application in which the workflow calls functions, wherein the nodes in the directed acyclic graph represent functions and edges represent calls made by the functions (Page 154 Lines 16-24 states “applications can be modeled as a Directed Acyclic Graph (DAG) where each vertex/stage is a function. Henceforth, we will use the terms ‘function’ and ‘stage’ interchangeably. We define a workflow or path within an application as a sequence of vertices and the edges that connect them, starting from the first vertex (or vertices) and ending at the last vertex (or vertices). An application invokes functions in the sequence as specified by the path in the DAG.” Examiner’s Note: the vertex that is a function represents the node in the DAG. Paths represent function invocation sequences. Therefore, edges represent function calls between functions);
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the DAG with nodes representing functions and edges representing function calls of Bhasi with the computer system for placing containers based communication patterns for inter-container communication between functions of Banerjee, ‘459D, and Navasivasakthivelsamy , and the cache within containers of Mason and the TLB flow of Brandt. A person having ordinary skill in the art would have been motivated to make this combination because “Kraken spawns up to 76% fewer containers, thereby improving container utilization and saving cluster-wide energy by up to 4x and 48%, respectively, when compared to state-of-the art schedulers employed in serverless platforms” (Page 153 Lines 21-25).
Banerjee, Mason, ‘459D, Brandt, Navasivasakthivelsamy, and Bhasi do not explicitly teach splitting the directed acyclic graph into subgraphs.
However, in an analogous art, Broecheler teaches split the directed acyclic graph into subgraphs based on increase local communications between functions (Col. 3 Lines 1-5 states “Partitioning a graph database is disclosed. In some embodiments, vertices of the graph database are each assigned to nodes (e.g., processing servers that will store data of the vertex and/or handle query processing for the vertex) according to abstract paths between the vertices. For example, abstract paths indicate relationships between vertices for purposes of graph partitioning.” See FIG. 1E. Col. 11 Lines 47-49 states “Circle 124 includes vertices assigned to a first node and circle 126 includes vertices assigned to a second node.” Examiner’s Note: the “nodes” represent the subgraphs because they comprise of vertices);
and assign containers for the functions to nodes based on the functions in the subgraphs (See FIG. 1E. Col. 11 Lines 47-49 states “Circle 124 includes vertices assigned to a first node and circle 126 includes vertices assigned to a second node.” Examiner’s Note: the “nodes” represent the subgraphs because the comprise of vertices).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the partitioning of the graph based on abstract paths of Broecheler with the computing system and directed acyclic graph of Banerjee, Mason, ‘459D, Brandt, Navasivasakthivelsamy, and Bhasi. The combination of Banerjee, Mason, ‘459D, Brandt, Navasivasakthivelsamy, Bhasi, and Broecheler results in a computer system that places the containers with functions of Banerjee. Bhasi teaches the directed acyclic graph that has nodes representing functions of Banerjee and edges representing the function invocations of Banerjee. The DAG of Bhasi can then be partitioned according to the partitioning strategy of Broecheler. However, instead of using abstract paths of Broecheler, the network communication patterns between virtual machines of Navasivasakthivelsamy can be used. After the DAG has been partitioned, the containers of Banerjee can now be placed according to the subgraphs to increase local communications.
A person having ordinary skill in the art would have been motivated to make this combination because “The division of a graph database may be optimized to enable efficient storage and/or load balancing amongst the nodes” (Col. 4 Lines 26-29). Additionally, “tradeoffs have to be made with respect to data locality and performance. Additionally, as the graph database becomes larger, it becomes inefficient and often impractical to store the database on a single storage/machine. Efficiently and effectively dividing up graph data for storage in different locations becomes important.” (Col. 1 Lines 19-25). By carefully partitioning the graph, data can be stored efficiently in multiple computers. In a similar way, by carefully deciding which containers to place on a same physical machine, function calls between containers can be improved.
Claim(s) 9 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Banerjee in view of Mason, ‘459D, Brandt, and Bhasi and further in view of Cadambi et al. Pat. No. US 20120124591 A1 (hereafter Cadambi).
With regard to claim 9, Banerjee, Mason, ‘459D, and Brandt teach the computer implemented method of claim 1. Banerjee, Mason, ‘459D, and Brandt do not explicitly teach scheduling function requests based on slack.
However, in an analogous art, Bhasi teaches further comprising: scheduling, by the number of processor units, requests for the called function using priorities based on slack from a service level objective (Page 159 Lines 22-23 state “Slack refers to the difference in expected response time and actual execution time of functions within a function chain.” Page 159 Lines 27-28 state “there is significant difference (slack) between the function's expected SLO and its run-time.” Page 159 Lines 29-31 state “This slack is leveraged by Kraken by batching multiple requests to the functions by queueing requests at their containers.” Examiner’s Note: slack is from the service level objective because it is calculated using the function’s expected SLO. Slack is then used to batch, or schedule, the function requests).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the batching of requests to function based on slack of Bhasi with the function in containers calling other functions using function addresses of Banerjee and ‘459D, and the cache within containers of Mason and the TLB flow of Brandt. A person having ordinary skill in the art would have been motivated to make this combination because “Batching reduces the number of containers spawned for each function” (Page 159 Lines 32-33) and “Kraken spawns up to 76% fewer containers, thereby improving container utilization and saving cluster-wide energy by up to 4x and 48%, respectively, when compared to state-of-the art schedulers employed in serverless platforms” (Page 153 Lines 21-25). Request batching contributes to improving container utilization.
Banerjee, Mason, ‘459D, Brandt, and Bhasi do not explicitly teach using priorities based on slack.
However, in an analogous art, Cadambi teaches scheduling, by the number of processor units, requests for the called function using priorities based on slack from a service level objective (¶ [0018] states “scheduling is based on a priority metric such that the tasks of the application with the highest priority metric are selected first for immediate scheduling” and “the priority metric may be computed based on the request's slack”).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the priority scheduler based on slack of Cadambi with the scheduling of function requests using slack from an SLO of Banerjee, ‘459D, and Bhasi , and the cache within containers of Mason and the TLB flow of Brandt. A person having ordinary skill in the art would have been motivated to make this combination to use “a priority metric (PM) to adjust the allocated resources for each application 110 so that tasks may be completed within an acceptable QoS.” Additionally, the priority is used so that the scheduler can schedule “client-server applications onto heterogeneous clusters” (¶ [0007]) and to increase utilization of computer resources (¶ [0006] states “For better utilization, multiple client-server applications should be able to concurrently run and share heterogeneous clusters”).
With regard to claim 19, Banerjee, Mason, ‘459D, and Brandt teach the computer system of claim 11. Banerjee, Mason, ‘459D, and Brandt do not explicitly teach scheduling function requests based on slack.
However, in an analogous art, Bhasi teaches wherein the number of processor units executes program instructions to: schedule requests for the called function using priorities based on slack from a service level objective (Page 159 Lines 22-23 state “Slack refers to the difference in expected response time and actual execution time of functions within a function chain.” Page 159 Lines 27-28 state “there is significant difference (slack) between the function's expected SLO and its run-time.” Page 159 Lines 29-31 state “This slack is leveraged by Kraken by batching multiple requests to the functions by queueing requests at their containers.” Examiner’s Note: slack is from the service level objective because it is calculated using the function’s expected SLO. Slack is then used to batch, or schedule, the function requests).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the batching of requests to function based on slack of Bhasi with the function in containers calling other functions using function addresses of Banerjee and ‘459D , and the cache within containers of Mason and the TLB flow of Brandt. A person having ordinary skill in the art would have been motivated to make this combination because “Batching reduces the number of containers spawned for each function” (Page 159 Lines 32-33) and “Kraken spawns up to 76% fewer containers, thereby improving container utilization and saving cluster-wide energy by up to 4x and 48%, respectively, when compared to state-of-the art schedulers employed in serverless platforms” (Page 153 Lines 21-25). Request batching contributes to improving container utilization.
Banerjee, Mason, ‘459D, Brandt, and Bhasi do not explicitly teach using priorities based on slack.
However, in an analogous art, Cadambi teaches schedule requests for the called function using priorities based on slack from a service level objective (¶ [0018] states “scheduling is based on a priority metric such that the tasks of the application with the highest priority metric are selected first for immediate scheduling” and “the priority metric may be computed based on the request's slack”).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the priority scheduler based on slack of Cadambi with the scheduling of function requests using slack from an SLO of Banerjee, ‘459D, and Bhasi, and the cache within containers of Mason and the TLB flow of Brandt. A person having ordinary skill in the art would have been motivated to make this combination to use “a priority metric (PM) to adjust the allocated resources for each application 110 so that tasks may be completed within an acceptable QoS.” Additionally, the priority is used so that the scheduler can schedule “client-server applications onto heterogeneous clusters” (¶ [0007]) and to increase utilization of computer resources (¶ [0006] states “For better utilization, multiple client-server applications should be able to concurrently run and share heterogeneous clusters”).
Response to Arguments
The 35 U.S.C. § 101 rejection of claims 1-20 has been withdrawn.
Applicant's arguments filed 05/06/2026 have been fully considered but they are not persuasive.
With regard to the 35 U.S.C. § 103 rejection of claims 1, 11, and 20, applicant argues “Banerjee does not disclose a data structure maintained within a calling container that maps function identifiers to container addresses, nor does it disclose determining the absence of an entry in such a data structure and, in response, requesting an address from a controller node. Banerjee's architecture remains centered on scheduler-based management and container selection rather than decentralized, container-local address resolution and caching. There is no teaching in Banerjee of updating a local translation table with retrieved addresses to enable subsequent direct communication.” Applicant further argues “IPCOM '459D does not disclose or suggest maintaining a data structure within a calling container itself, nor does it disclose a cache-miss-driven request to a controller node followed by updating a local data structure. Instead, IPCOM '459D relies on persistent centralized routing logic, which is fundamentally different from the claimed decentralized, container-local update mechanism.”
Examiner respectfully disagrees. Examiner does not solely rely upon Banerjee or ‘459D to teach the claim limitations. Rather, examiner relies upon the combination of Banerjee, Mason, ‘459D, and Brandt to teach the claim limitations. Banerjee teaches a data structure that stores containers. ‘459D teaches a table mapping between functions identifiers and machine addresses. Together, Banerjee and ‘459D teach a data structure that maps function identifiers and container addresses. Mason teaches a cache, a type of data structure, within a container. Combining Banerjee, ‘459D, and Mason teaches the data structure that maps function identifiers and container addresses, and the data structure is within a container.
Additionally, combining Banerjee, Mason, and ‘459D with Brandt teaches the flow of determining an absence in the data structure, requesting an address from a controller node, updating a local translation table, and using the retrieved address for subsequent direct communication. The controller node is orchestrator of Banerjee and is considered the next level cache hierarchy of Brandt. Therefore, Banerjee, Mason, ‘459D, and Brandt teaches the claim limitations.
Applicant further argues “IPCOM '459D requires that communications be routed through the API gateway, and Banerjee relies on scheduler-mediated function invocation. Neither reference teaches or suggests transitioning from controller-mediated address resolution to direct container-to-container communication enabled by a locally updated data structure.”
Examiner respectfully disagrees. Examiner relies upon the combination of Banerjee, Mason, ‘459D, and Brandt to fully teach the limitations. Banerjee teaches a direct container-to-container communication when the first container sends an invocation to the in-node container. In the combination, it is enabled by the locally updated data structure that is taught by Banerjee, Mason, ‘459D, and Brandt. Brandt teaches the transition from address resolution to direct communication when Brandt teaches a TLB fetch which can then be followed by a TLB hit. Therefore, Banerjee, Mason, ‘459D, and Brandt teaches the claim limitations.
Applicant further argues “the amended claim recites a coordinated sequence of operations that include local lookup, miss detection, controller-based resolution, local update, and direct communication, which together define a specific distributed communication architecture. The Examiner has not identified, and the cited references do not disclose, this ordered combination of features.”
Examiner respectfully disagrees. As explained above and in the 35 U.S.C. 103 rejection of claims 1, 11, and 20, the coordinated sequence of local lookup, miss detection, controller-based resolution, local update, and direct communication is taught using the combination of Brandt with Banerjee, Mason, and ‘459D. Banerjee teaches steps of looking up if a container exists locally, miss detection when a suitable container does not exist, communicating with an orchestrator to resolve the container invocation, and direct communication between the first container and in-node container. Mason adds that the data structure is within the container, and ‘459D adds that the data structure maps addresses and function identifiers. Brandt ties the steps of Banerjee together with Mason and ‘459D to fully teach the ordered combination of features.
Applicant further argues “there is no articulated motivation that would have led one of ordinary skill in the art to modify Banerjee's scheduler-based architecture with IPCOM '459D's gateway-based routing system to arrive at a container-local, self-updating address resolution mechanism. Such a modification would require a fundamental redesign of the system architecture, replacing centralized routing and scheduling with decentralized, container-level caching and direct invocation. The cited references provide no teaching or suggestion of such a transformation, nor do they recognize the latency and resource-consumption problems solved by the present invention.”
Applicant’s argument has been considered moot because the new ground of rejection does not solely rely upon Banerjee and ‘459D to fully teach the amended claim. Rather, it is the combination of Banerjee, Mason, ‘459D, and Brandt that teach the claim limitations. The motivation to combine Mason’s cache data structure within containers and Banerjee’s container invocation system is that by adding a cache within the container, can “reduce cost, reduce network delays and traffic, reduce communication errors, and reduce the amount of computing infrastructure/devices required to implement a cache for clients” (Col. 3 Lines 50-53). The motivation to adding ‘459D to the combination is “To avoid a centralized architecture, or, to avoid installing all the libraries on all the available machines (drawback of heavy maintenance, huge duplication, wastage of resources) the entire set of call libraries are distributed over individual machines in the cluster” (Page 2 paragraph 7). Lastly, the motivation to add the TLB flow of Brandt is “to improve virtual address translation speed” (Brandt ¶ [0004]). Further motivation and explanation are provided in the 35 U.S.C. § 103 rejection of claims 1, 11, and 20. Therefore, there is motivation to combine Banerjee, Mason, ‘459D, and Brandt.
Examiner maintains 35 U.S.C. § 103 rejections of independent claims 1, 11, and 20. Further, examiner maintains 35 U.S.C. § 103 rejections of dependent claims 2-10 and 12-19.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20180218295 A1
teaches
ENGINE FOR MODELING AND EXECUTING CUSTOM BUSINESS PROCESSES
US 20160330277 A1
teaches
CONTAINER MIGRATION AND PROVISIONING
US 20200226009 A1
teaches
SCALABLE AND ACCELERATED FUNCTION AS A SERVICE CALLING ARCHITECTURE
US 20200250087 A1
teaches
DYNAMIC ALLOCATION OF MEMORY BETWEEN CONTAINERS
US 20240152462 A1
teaches
CENTRALIZED, SCALABLE CACHE FOR CONTAINERIZED APPLICATIONS IN A VIRTUALIZED ENVIRONMENT
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to PETER L YUAN whose telephone number is (571)272-5737. The examiner can normally be reached Mon-Fri 7:30am-5pm.
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, Bradley Teets can be reached at 571-272-3338. 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.
/PETER LI YUAN/Examiner, Art Unit 2197
/BRADLEY A TEETS/Supervisory Patent Examiner, Art Unit 2197
Prosecution Insights