DETAILED ACTION
Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
2. This action is responsive to the application filed September 11, 2023.
Claims 1-20 are pending and are presenting for examination
Examiner Notes
3. Examiner cites particular columns and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
4. In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Claim Objections
5. Claims 16-17 are objected to because of the following informalities:
As to claim 16, recites to include the limitation “the deployed configuration” appears lacking of antecedent basis for this limitation in the claim and should be changed to, for example, -- 16. The computer program product of claim [[10]] 15— instead. Appropriate correction is required.
Claim 17 is also objected for being depended upon the objection of base claim 16.
Claim Rejections - 35 USC § 101
6. 35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
7. Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Independent Claims 1 and 18 recite:
A computer-implemented method, comprising:
[a] receiving, by a processor set, a plurality of incoming requests;
[b] determining, by the processor set, that the plurality of incoming requests comprise a plurality of instant requests;
[c] creating, by the processor set, a software image based on the plurality of instant requests; and
[d] pulling, by the processor set, the software image based on a deployed configuration.
Step 2A – prong 1:
The claim 10 recites the limitation of:
[a] receive a plurality of incoming requests;
[b] determine that the plurality of incoming requests comprise a plurality of continuous requests;
[c] create a service image based on the plurality of continuous requests.
[d] pull the service image based on an instruction of pulling and running the service image.
These limitations of steps [b]-[c] of claims 1, 10, and 18 and as draft, are functions that, under its broadest reasonable interpretation, recite the abstract idea of a mental process. The limitations encompass a human mind carrying out the function through observation, evaluation judgment and /or opinion, or even with the aid of pen and paper. Thus, this limitation recites and falls within the “Mental Processes” grouping of abstract ideas under Prong 1.
Step 2A – Prong 2:
Under Prong 2, this judicial exception is not integrated into a practical application. The claims recite the following additional elements: “by a processor set” and “A system”, “a processor set, one or more computer readable storage media, and program instructions collectively stored on the one or more computer readable storage media, the program instructions executable”, steps [a] and step [d] of claims 1, 10, and 18.
The additional elements “by a processor set”, “A system”, and “a processor set, one or more computer readable storage media, and program instructions collectively stored on the one or more computer readable storage media, the program instructions executable” merely recite instructions to implement an abstract idea on a generic computer, or merely use a generic computer or computer components as a tool to perform the abstract idea, thus is not a practical application under Prong 2. See MPEP 2106.05(f).
Furthermore, the additional element of step [a] of claims 1, 10, and 18 merely recites insignificant extra solution activity such as gathering, displaying, updating, transmitting and storing data which does not integrate the judicial exception into a practical application under Prong 2. See MPEP 2106.05(g).
Lastly, the additional element of step [d] of claims 1, 10, and 18 fails to meaningfully limit the claim because it does not require any particular application of the recited “pulling,” and is at best the equivalent of merely adding the words “apply it” to the judicial exception. Therefore, this additional element does not integrate the judicial exception into a practical application under Prong 2. See MPEP 2106.05(f).
Accordingly, the additional elements do not integrate the recited judicial exception into a practical application and the claims are therefore directed to the judicial exception.
Step 2B:
Under Step 2B, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of “by a processor set”, “A system”, and “a processor set, one or more computer readable storage media, and program instructions collectively stored on the one or more computer readable storage media, the program instructions executable” are amount to no more than mere instructions, or generic computer/computer components as a tool to carry out the exception, and the additional element of step [d] of claims 1, 10, and 18 fails to meaningfully limit the claim because it does not require any particular application of the recited “pulling” and is at best the equivalent of merely adding the words “apply it” to the judicial exception. Lastly, the limitation of step [a] “receiving, a plurality of incoming requests” the courts have identified mere data gathering is well-understood, routine and conventional activity. See MPEP 2106.05(d). The recitation of generic computer instruction and computer components to apply the judicial exception, merely applying the judicial exception or abstract idea, and mere data gathering do not amount to significantly more, thus, cannot provide an inventive concept. Accordingly, the claims are not patent eligible under 35 USC 101.
Regarding to per claims 2 and 19, do not recite any mental process; however, the additional element of “the deployed configuration includes a scheduled policy” is merely further applying the judicial exception or abstract idea which is neither a practical application under prong 2, or amount to significantly more under step 2B.
Regarding to per claims 3 and 20, do not recite any mental process; however, the additional element of “the scheduled policy comprises a policy of scaling down when there are no instant requests” is merely further applying the judicial exception or abstract idea which is neither a practical application under prong 2, or amount to significantly more under step 2B.
Regarding to claim 4, does not recite any mental process; however, the additional element of “the software image comprises a WebAssembly image” is further defining software image is merely insignificant extra solution activity under prong 2. Under step 2B, the courts have identified merely defining data/information is well-understood, routine and conventional activity. See MPEP 2106.05(d).
Regarding to claim 5, the limitation “determining that the plurality of incoming request comprise a plurality of continuous requests” recites further mental process. The claim does not include any additional element, thus, no limitation that needs to be analyzed under prong 2 for practical application, or under step 2B for significantly more.
Regarding to claim 6, the limitation “creating a service image based on the continuous requests” recites further mental process. The claim does not include any additional element, thus, no limitation that needs to be analyzed under prong 2 for practical application, or under step 2B for significantly more.
Regarding to claim 7, the limitation “scaling up based on an instruction of scaling up the continuous requests” recites further mental process. The claim does not include any additional element, thus, no limitation that needs to be analyzed under prong 2 for practical application, or under step 2B for significantly more.
Regarding to claim 8, the limitation “scaling down based on an instruction of scaling down the continuous requests” recites further mental process. The claim does not include any additional element, thus, no limitation that needs to be analyzed under prong 2 for practical application, or under step 2B for significantly more.
Regarding to claim 9, it does not recite any mental process; however, the additional element of “pulling the service image based on an instruction of pulling and running the service image” fails to meaningfully limit the claim because it does not require any particular application of the recited “pulling nor running” and is at best the equivalent of merely adding the words “apply it” to the judicial exception or abstract idea which is neither a practical application under prong 2, or amount to significantly more under step 2B.
Independent Claim 10 recites:
A computer program product comprising one or more computer readable storage media having program instructions collectively stored on the one or more computer readable storage media, the program instructions executable to:
[i] receive a plurality of incoming requests;
[ii] determine that the plurality of incoming requests comprise a plurality of continuous requests;
[iii]create a service image based on the plurality of continuous requests; and
[iv] pull the service image based on an instruction of pulling and running the service image.
Step 2A – prong 1:
The claim 10 recite the limitation of:
[ii] determine that the plurality of incoming requests comprise a plurality of continuous requests;
[iii]create a service image based on the plurality of continuous requests.
These limitations of steps [[ii]-[iii] as draft, are functions that, under its broadest reasonable interpretation, recite the abstract idea of a mental process. The limitations encompass a human mind carrying out the function through observation, evaluation judgment and /or opinion, or even with the aid of pen and paper. Thus, this limitation recites and falls within the “Mental Processes” grouping of abstract ideas under Prong 1.
Step 2A – Prong 2:
Under Prong 2, this judicial exception is not integrated into a practical application. The claims recite the following additional elements: “A computer program product comprising one or more computer readable storage media having program instructions collectively stored on the one or more computer readable storage media, the program instructions executable”, step [i], and step [iv].
The additional elements “by a processor set”, “A computer program product comprising one or more computer readable storage media having program instructions collectively stored on the one or more computer readable storage media, the program instructions executable” merely recite instructions to implement an abstract idea on a generic computer, or merely use a generic computer or computer components as a tool to perform the abstract idea, thus is not a practical application under Prong 2. See MPEP 2106.05(f).
Furthermore, the additional element of step [i] “receive a plurality of incoming requests” merely recite insignificant extra solution activity such as gathering, displaying, updating, transmitting and storing data which does not integrate the judicial exception into a practical application under Prong 2. See MPEP 2106.05(g).
Lastly, the additional elements of step [iv] “pull the service image based on an instruction of pulling and running the service image” fail to meaningfully limit the claim because it does not require any particular application of the recited “pulling nor running” and is at best the equivalent of merely adding the words “apply it” to the judicial exception.
Therefore, this additional element does not integrate the judicial exception into a practical application under Prong 2. See MPEP 2106.05(f).
Accordingly, the additional elements do not integrate the recited judicial exception into a practical application and the claims are therefore directed to the judicial exception.
Step 2B:
Under Step 2B, the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional element of “A computer program product comprising one or more computer readable storage media having program instructions collectively stored on the one or more computer readable storage media, the program instructions executable” is amount to no more than mere instructions, or generic computer/computer components as a tool to carry out the exception, and for the limitation of step [iv] “pull the service image based on an instruction of pulling and running the service image” fails to meaningfully limit the claim because it does not require any particular application of the recited “pulling nor running” and is at best the equivalent of merely adding the words “apply it” to the judicial exception. Lastly, the limitation of step [i] “receiving, a plurality of incoming requests” the courts have identified mere data gathering is well-understood, routine and conventional activity. See MPEP 2106.05(d). The recitation of generic computer instruction and computer components to apply the judicial exception, merely applying the judicial exception or abstract idea, and mere data gathering do not amount to significantly more, thus, cannot provide an inventive concept. Accordingly, the claim 10 is not patent eligible under 35 USC 101.
Regarding to claim 11, the limitation “scaling up based on an instruction of scaling up the continuous requests” recites further mental process. The claim does not include any additional element, thus, no limitation that needs to be analyzed under prong 2 for practical application, or under step 2B for significantly more.
Regarding to claim 12, the limitation “scaling down based on an instruction of scaling down the continuous requests” recites further mental process. The claim does not include any additional element, thus, no limitation that needs to be analyzed under prong 2 for practical application, or under step 2B for significantly more.
Regarding to claim 13, the limitation “determining that the plurality of incoming requests comprise a plurality of instant requests” recites further mental process. The claim does not include any additional element, thus, no limitation that needs to be analyzed under prong 2 for practical application, or under step 2B for significantly more.
Regarding to claim 14, the limitation “creating a software image based on the instant requests” recites further mental process. The claim does not include any additional element, thus, no limitation that needs to be analyzed under prong 2 for practical application, or under step 2B for significantly more.
Regarding to claim 15, it does not recite any mental process; however, the additional element of “pulling the software image based on a deployed configuration” fails to meaningfully limit the claim because it does not require any particular application of the recited “pulling” and is at best the equivalent of merely adding the words “apply it” to the judicial exception or abstract idea which is neither a practical application under prong 2, or amount to significantly more under step 2B.
Regarding to claim 16, it does not recite any mental process; however, the additional element of “the deployed configuration includes a scheduled policy” is merely further applying the judicial exception or abstract idea which is neither a practical application under prong 2, or amount to significantly more under step 2B.
Regarding to claim 17, it does not recite any mental process; however, the additional element of “the scheduled policy comprises a policy of scaling down when there are no instant requests” is merely further applying the judicial exception or abstract idea which is neither a practical application under prong 2, or amount to significantly more under step 2B.
Claim Rejections - 35 USC § 103
8. 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.
9. Claims 1-3 and 5-20 are rejected under 35 U.S.C. 103 as being unpatentable over Kallakuri et al. (US 12443427 B1, hereinafter Kallakuri) in view of ARKKO (US 20210409931 A1).
As per claims 1 and 18, Kallakuri discloses a computer-implemented method, comprising:
receiving, by a processor set, a plurality of incoming requests – (e.g., The operations 600 include, at block 602, receiving, by a control plane of a cloud provider network, from one or more agents executing in a network that is distinct from the cloud provider network, a plurality of requests to pull one or more container images from a container registry hosted in the cloud provider network—see at least col. 16: 26-32, Fig. 1, Fig. 6, and associated text) ;
determining, by the processor set, that the plurality of incoming requests comprise a plurality of instant requests –(e.g., determine type of requests upon stagged time in which long time requests refer as – instant requests – as such “In some examples, the control plane can store these requests in a buffer or other data structure that enables the control plane to determine whether the control plane will receive requests for a same one or more containers in some defined future window of time (e.g., within the next 10 seconds or other defined period). Responsive to receiving a request for a particular container image, the control plane can determine, based on the buffered requests, that multiple requests for a container image have been received from two or more agents executing in the network.” --see at least col. 11: 4-9, col. 14: 27-49, Fig. 1, and associated text and “each of the agents 120 selects a time … at which to request the container image(s). For example, the time in the… selected by a particular agent can be based on a randomized value used to temporally stagger a time at which each of the agents 120 generates a request…the randomized value can be used to select a time within a …time window (e.g., in the next 5, 10, or 30 minutes—instant request --to request its container images from the container registry service 114,— see, at least col. 10: 11-45, Fig. 1, Fig. 6, and associated text).
pulling, by the processor set, the software image based on a deployed configuration – (E.g. “sending, by the control plane to the one or more agents, instructions to obtain –pull--the set of container images from the container registry,” – see at least col. 16: 36-39, Fig. 1, Fig. 6, and associated text, and “ responsive to the determination, the control plane can send to the agent instructions to obtain the container image from a local cache located in the network (e.g., a local cache associated with another agent in the environment, which may be running on a same or different host within the environment)” – see at least col. 14: 27-49, Fig. 1, and associated text).
It is to note that while Kallakuri discloses pull/obtain container image – software image-- but does not explicitly disclose; however, ARKKO, in an analogous art, discloses creating, by the processor set, a software image based on the plurality of instant requests – (E.g., At step 402b, upon detecting by an entity in the visited network a trigger indicating a request for a service in the home network but for which a software image is available, instantiating the
software image of the service in the visited network. Once instantiated, the entity may execute the step of retrieving from the home network up-to-date configuration data for the instantiated software image of the service. Once the software image of the service is configured, it provides the service as if it was provided by the home network. Once the service is provided, the instantiation is removed, hence preventing the associated resources from idling – see ARKKO, at least 0020, 0105, Fig. 4b and associated text).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated ARKKO’s teaching into a Kallakuri’s teaching for further optimizing the creating container image on demand; accordingly promoting easier for provisioning, scaling, and managing any servers as seen in ARKKO (e.g., 0009 and 0011).
Further regarding to claim 18, Kallakuri discloses a system comprising: a processor set, one or more computer readable storage media, and program instructions collectively stored on the one or more computer readable storage media— (e.g., one or more computer systems configured with executable instructions, and are implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications) executing collectively on one or more processors. The code is stored on a computer-readable storage medium, for example, in the form of a computer program comprising instructions executable by one or more processors – see at least col. 16: 14-21, the computer system 1000 includes one or more processors 1010 coupled to a system memory 1020 via an input/output (I/O) interface 1030 – see at least col. 21: 15-18, Fig. 10, and associated text), the program instructions executable to implement method steps as of claim 1 above.
As per claims 2 and 19, modified Kallakuri with ARKKO discloses wherein the deployed configuration includes a scheduled policy-- (e.g. “sending, by the control plane to the one or more agents, instructions to obtain the set of container images from the container registry, wherein the instructions include staggered times –scheduling --for the one or more agents to initiate requests to the container registry.” — see Kallakuri, at least col. 16: 36-59, Fig. 1, Fig. 6, and associated text).
As per claims 3 and 20, modified Kallakuri with ARKKO discloses, wherein the scheduled policy comprises a policy of scaling down when there are no instant requests --(e.g. rather than each agent immediately requesting any container image(s) identified by a task or service definition from the container registry service 114, each of the agents 120 selects a time … at which to request the container image(s). For example, the time in the… selected by a particular agent can be based on a randomized value used to temporally stagger a time at which each of the agents 120 generates a request…the randomized value can be used to select a time within a …time window (e.g., in the next 5, 10, or 30 minutes—no instant request--, or any other span of time) such that, e.g., agent 120A might determine wait twenty seven (27) seconds to request its container images from the container registry service 114,— see Kallakuri, at least col. 10: 11-45, Fig. 1, Fig. 6, and associated text).
As to claim 5, modified Kallakuri with ARKKO discloses further comprising determining that the plurality of incoming request comprise a plurality of continuous requests –(E.g., pull requests can be frequency requests as in short/instant period as such “In some examples, the control plane can store these requests in a buffer or other data structure that enables the control plane to determine whether the control plane will receive requests for a same one or more containers in some defined future window of time (e.g., within the next 10 seconds or other defined period). Responsive to receiving a request for a particular container image, the control plane can determine, based on the buffered requests, that multiple requests for a container image have been received from two or more agents executing in the network. --see Kallakuri, at least col. 11: 4-9, col. 14: 27-49, Fig. 1, and associated text and “ requests for container image rather than each agent immediately requesting any container image(s) identified by a task or service definition from the container registry service 114, each of the agents 120 selects a time in…to request the container image(s). For example, the time … In FIG. 1, for example, each of the computing devices 124A-124N initiates execution of a task near in time to one another and each selects a respective time at which to request a container image from the container registry service 114 (where each computing device 124 may be requesting the same container image(s) or an overlapping set of container images).”— see Kallakuri, at least col. 10: 11-45, Fig. 1, Fig. 6, and associated text).
As to claim 6, it is to note that while Kallakuri discloses pull/obtain container image – service image--; but does not explicitly disclose; however, ARKKO, in an analogous art, discloses creating a service image based on the continuous requests – (e.g., At step 402b, upon detecting by an entity in the visited network a trigger indicating a request for a service in the home network but for which a software image is available, instantiating the software image
of the service in the visited network. Once instantiated, the entity may execute the step of retrieving from the home network up-to-date configuration data for the instantiated software image of the service. Once the software image of the service is configured, it provides the service as if it was provided by the home network. Once the service is provided, the instantiation is removed, hence preventing the associated resources from idling – see ARKKO, at least 0020, 0105, Fig. 4b and associated text).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated ARKKO’s teaching into a Kallakuri’s teaching for further optimizing the creating container image on demand; accordingly promoting easier for provisioning, scaling, and managing any servers as seen in ARKKO (e.g., 0009 and 0011).
As to claim 7, modified Kallakuri with ARKKO discloses further comprising scaling up based on an instruction of scaling up the continuous requests - (e.g. rather than each agent immediately requesting any container image(s) identified by a task or service definition from the container registry service 114, each of the agents 120 selects a time … at which to request the container image(s). For example, the time in the… selected by a particular agent can be based on a randomized value used to temporally stagger a time at which each of the agents 120 generates a request…the randomized value can be used to select a time within a …time window (e.g., in the next 5, 10, or 30 minutes—scaling down--, or any other span of time) such that, e.g., agent 120A might determine wait twenty seven (27) seconds –scaling up--to request its container images from the container registry service 114,— see Kallakuri, at least col. 10: 11-45, Fig. 1, Fig. 6, and associated text).
As to claim 8, modified Kallakuri with ARKKO discloses further comprising scaling down based on an instruction of scaling down the continuous requests--(e.g. rather than each agent immediately requesting any container image(s) identified by a task or service definition from the container registry service 114, each of the agents 120 selects a time … at which to request the container image(s). For example, the time in the… selected by a particular agent can be based on a randomized value used to temporally stagger a time at which each of the agents 120 generates a request…the randomized value can be used to select a time within a …time window (e.g., in the next 5, 10, or 30 minutes—scaling down--, or any other span of time) such that, e.g., agent 120A might determine wait twenty seven (27) seconds –scaling up--to request its container images from the container registry service 114,— see Kallakuri, at least col. 10: 11-45, Fig. 1, Fig. 6, and associated text).
As to claim 9, modified Kallakuri with ARKKO discloses further comprising pulling the service image based on an instruction of pulling and running the service image --(E.g. “sending, by the control plane to the one or more agents, instructions to obtain the set of container images from the container registry,” – see Kallakuri, at least col. 16: 36-39, Fig. 1, Fig. 6, and associated text, and “ responsive to the determination, the control plane can send to the agent instructions to obtain the container image from a local cache located in the network (e.g., a local cache associated with another agent in the environment, which may be running on a same or different host within the environment)” – see Kallakuri , at least col. 14: 27-49, Fig. 1, and associated text).
As to claim 10, Kallakuri discloses a computer program product comprising one or more computer readable storage media having program instructions collectively stored on the one or more computer readable storage media – (e.g., the system memory 1020 can be one embodiment of a computer-accessible medium configured to store program instructions and data as described above – see at least col. 22: 47-50, Fig. 10, and associated text), the program instructions executable to:
receive a plurality of incoming requests--(e.g., The operations 600 include, at block 602, receiving, by a control plane of a cloud provider network, from one or more agents executing in a network that is distinct from the cloud provider network, a plurality of requests to pull one or more container images from a container registry hosted in the cloud provider network—see at least col. 16: 26-32, Fig. 1, Fig. 6, and associated text);
determine that the plurality of incoming requests comprise a plurality of continuous requests–(e.g., determine type of requests upon stagged time in which short time requests refer as – continuous requests – as such “In some examples, the control plane can store these requests in a buffer or other data structure that enables the control plane to determine whether the control plane will receive requests for a same one or more containers in some defined future window of time (e.g., within the next 10 seconds ). Responsive to receiving a request for a particular container image, the control plane can determine, based on the buffered requests, that multiple requests for a container image have been received from two or more agents executing in the network.” --see at least col. 11: 4-9, col. 14: 27-49, Fig. 1, and associated text and “each of the agents 120 selects a time … at which to request the container image(s). For example, the time in the… selected by a particular agent can be based on a randomized value used to temporally stagger a time at which each of the agents 120 generates a request…the randomized value can be used to select a time within a …time window such that, e.g., agent 120A might determine wait twenty seven (27) seconds –continuous request --to request its container images from the container registry service 114”— see, at least col. 10: 11-45, Fig. 1, Fig. 6, and associated text).
pull the service image based on an instruction of pulling and running the service image --(E.g. “sending, by the control plane to the one or more agents, instructions to obtain –pull--the set of container images from the container registry,” – see at least col. 16: 36-39, Fig. 1, Fig. 6, and associated text, and “ responsive to the determination, the control plane can send to the agent instructions to obtain the container image from a local cache located in the network (e.g., a local cache associated with another agent in the environment, which may be running on a same or different host within the environment)” – see at least col. 14: 27-49, Fig. 1, and associated text).
It is to note that while Kallakuri discloses pull/obtain container image – service image--; but does not explicitly disclose; however, ARKKO, in an analogous art, discloses create a service image based on the plurality of continuous requests– (e.g., At step 402b, upon detecting by an entity in the visited network a trigger indicating a request for a service in the home network but for which a software image is available, instantiating the software image of the service in the
visited network. Once instantiated, the entity may execute the step of retrieving from the home network up-to-date configuration data for the instantiated software image of the service. Once the software image of the service is configured, it provides the service as if it was provided by the home network. Once the service is provided, the instantiation is removed, hence preventing the associated resources from idling – see ARKKO, at least 0020, 0105, Fig. 4b and associated text).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated ARKKO’s teaching into a Kallakuri’s teaching for further optimizing the creating container image on demand; accordingly promoting easier for provisioning, scaling, and managing any servers as seen in ARKKO (e.g., 0009 and 0011).
As to claim 11, modified Kallakuri with ARKKO discloses further comprising scaling up based on an instruction of scaling up the continuous requests --(e.g., rather than each agent immediately requesting any container image(s) identified by a task or service definition from the container registry service 114, each of the agents 120 selects a time … at which to request the container image(s). For example, the time in the… selected by a particular agent can be based on a randomized value used to temporally stagger a time at which each of the agents 120 generates a request…the randomized value can be used to select a time within a …time window (e.g., in the next 5, 10, or 30 minutes—scaling down--, or any other span of time) such that, e.g., agent 120A might determine wait twenty seven (27) seconds –scaling up--to request its container images from the container registry service 114,— see Kallakuri, at least col. 10: 11-45, Fig. 1, Fig. 6, and associated text).
As to claim 12, modified Kallakuri with ARKKO discloses further comprising scaling down based on an instruction of scaling down the continuous requests- --(e.g. rather than each agent immediately requesting any container image(s) identified by a task or service definition from the container registry service 114, each of the agents 120 selects a time … at which to request the container image(s). For example, the time in the… selected by a particular agent can be based on a randomized value used to temporally stagger a time at which each of the agents 120 generates a request…the randomized value can be used to select a time within a …time window (e.g., in the next 5, 10, or 30 minutes—scaling down--, or any other span of time) such that, e.g., agent 120A might determine wait twenty seven (27) seconds –scaling up--to request its container images from the container registry service 114,— see Kallakuri, at least col. 10: 11-45, Fig. 1, Fig. 6, and associated text).
As to claim 13, modified Kallakuri with ARKKO discloses further comprising determining that the plurality of incoming requests comprise a plurality of instant requests(e.g., determine type of requests upon stagged time in which long time requests refer as – instant requests – as such “In some examples, the control plane can store these requests in a buffer or other data structure that enables the control plane to determine whether the control plane will receive requests for a same one or more containers in some defined future window of time (e.g., within the next 10 seconds or other defined period). Responsive to receiving a request for a particular container image, the control plane can determine, based on the buffered requests, that multiple requests for a container image have been received from two or more agents executing in the network.” --see Kallakuri, at least col. 11: 4-9, col. 14: 27-49, Fig. 1, and associated text and “each of the agents 120 selects a time … at which to request the container image(s). For example, the time in the… selected by a particular agent can be based on a randomized value used to temporally stagger a time at which each of the agents 120 generates a request…the randomized value can be used to select a time within a …time window (e.g., in the next 5, 10, or 30 minutes—instant request --to request its container images from the container registry service 114,— see Kallakuri, at least col. 10: 11-45, Fig. 1, Fig. 6, and associated text).
As to claim 14, it is to note that while Kallakuri discloses pull/obtain container image – software image-- but does not explicitly disclose; however, ARKKO, in an analogous art, discloses further comprising creating a software image based on the instant requests – (E.g., At step 402b, upon detecting by an entity in the visited network a trigger indicating a
request for a service in the home network but for which a software image is available,
instantiating the software image of the service in the visited network. Once instantiated, the entity may execute the step of retrieving from the home network up-to-date configuration data for the instantiated software image of the service. Once the software image of the service is configured, it provides the service as if it was provided by the home network. Once the service is provided, the instantiation is removed, hence preventing the associated resources from idling – see ARKKO, at least 0020, 0105, Fig. 4b and associated text).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated ARKKO’s teaching into a Kallakuri’s teaching for further optimizing the creating container image on demand; accordingly promoting easier for provisioning, scaling, and managing any servers as seen in ARKKO (e.g., 0009 and 0011).
As to claim 15, modified Kallakuri with ARKKO discloses further comprising pulling the software image based on a deployed configuration --(E.g. “sending, by the control plane to the one or more agents, instructions to obtain –pull--the set of container images from the container registry,” – see at least col. 16: 36-39, Fig. 1, Fig. 6, and associated text, and “ responsive to the determination, the control plane can send to the agent instructions to obtain the container image from a local cache located in the network (e.g., a local cache associated with another agent in the environment, which may be running on a same or different host within the environment)” – see Kallakuri, at least col. 14: 27-49, Fig. 1, and associated text).
As to claim 16, modified Kallakuri with ARKKO discloses wherein the deployed configuration includes a scheduled policy -- (e.g. “sending, by the control plane to the one or more agents, instructions to obtain the set of container images from the container registry, wherein the instructions include staggered times –scheduling --for the one or more agents to initiate requests to the container registry.” — see Kallakuri, at least col. 16: 36-59, Fig. 1, Fig. 6, and associated text).
As to claim 17, modified Kallakuri with ARKKO discloses wherein the scheduled policy comprises a policy of scaling down when there are no instant requests--(e.g. rather than each agent immediately requesting any container image(s) identified by a task or service definition from the container registry service 114, each of the agents 120 selects a time … at which to request the container image(s). For example, the time in the… selected by a particular agent can be based on a randomized value used to temporally stagger a time at which each of the agents 120 generates a request…the randomized value can be used to select a time within a …time window (e.g., in the next 5, 10, or 30 minutes—no instant request--, or any other span of time) such that, e.g., agent 120A might determine wait twenty seven (27) seconds to request its container images from the container registry service 114,— see Kallakuri, at least col. 10: 11-45, Fig. 1, Fig. 6, and associated text).
10. Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Kallakuri in view of ARKKO, and in further view of Scrivano et al. (US 20240103882 A1, hereinafter Scrivano).
As to claim 4, it is to note that while modified Kallakuri with ARKKO, wherein the software image—see Kallakuri, at least col. 16: 26-32, Fig. 1, Fig. 6, and associated text, but the modified does not explicitly disclose that the software image comprises a WebAssembly image. However, Scrivano, in an analogous art, discloses the software image comprises a WebAssembly image— (e.g. container image 116 including webassembly application/payload 122 – see Scrivano, at least 0008, 0022, 0043, Fig. 1, and associated text).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated Scrivano’s teaching into modified teaching of Kallakuri with ARKKO for further optimizing the deployment of container image due to portable binary-code format; accordingly, promoting easier interactions between such programs of the container image and their host environments as seen in Scrivano (e.g., 0002-0003).
Conclusion
11. The prior art made of record and not relied upon (cited on 892 form) is considered pertinent to application disclosure.
Ibryam (US-11018965-B1) discloses serverless function scaling.
Zhang et al. (US-20190205186-A1) disclose mapping events from external sources to serverless.
12. Any inquiry concerning this communication or earlier communications from the examiner should be directed to MARINA LEE whose telephone number is (571)270-1648. The examiner can normally be reached Monday to Friday (8 am to 4: 30 pm ET).
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Hyung S. Sough can be reached on (571)-272-6799. 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.
/MARINA LEE/Primary Examiner, Art Unit 2192