DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Applicant’s preliminary amendments filed 09/23/2025 to the abstract, specification, and claims are acknowledged by the Examiner.
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Priority documents have been electronically received, available 01/27/2022.
This application is a continuation of International Application No. PCT/CN2023/071747, filed 01/10/2023, claiming priority to Chinese Patent Application No. 202210062563.8, filed 01/19/2022. The priority date is acknowledged by the Examiner.
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 10/03/2024, 04/29/2025 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner.
Examiner’s Note
The Examiner cites particular columns, paragraphs, figures, 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 also apply. It is respectfully requested that, in preparing responses, the Applicant fully consider the references in its 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.
Drawings
The drawings are objected to as failing to comply with 37 CFR 1.84(p)(4) because reference character “403” has been used to designate both “control thread” (FIG. 4, element 403) and “control process” (FIG. 5, element 403). Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
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.
Claims 1, 8, and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Lin et al. (NPL: FlashCube, 2021) hereafter Lin in view of Rebeja et al. (US 11281492 B1) hereafter Rebeja, further in view of Michimura et al. (US 20180232253 A1) hereafter Michimura.
Regarding claim 1, Lin teaches:
obtaining information of a function container in which the function is deployed (Page 42, right column; “pre-created container parts can be efficiently shared among functions — concurrent invocations of the same serverless function only need one shared pre-created (read-only) virtual root file system and one individual writable folder for each container instance. Different functions can still share the same base virtual file system (e.g., from the same base file system). Furthermore, since parallel invocations of the same function (i.e., from same cloud tenant) can trust each other, FlashCube allows multiple invocations of the same function to share the same container for reduced resource consumption.”, where the reuse of invocations of the same function requires that there must be a unique identifier that is obtained for the function container from which it is executed from, thereby obtaining information of a function container in which the function is deployed.);
forking a main thread of a language runtime process in a template container to obtain a target child process, wherein both the language runtime process in the template container and the target child process are language runtime processes corresponding to the function (Page 43, left column; “FlashCube prepares and maintains a template runtime process for each programming language (e.g., Python, Java, and Node.js). The template runtime process pre-loads all common libraries in advance. Then, during the provisioning of a new function, the function’s runtime can be forked from the template runtime process”, and “Once receiving a forking request, the parasite code uses the clone system call to create a child process of the template runtime process”, because the template runtime process is maintained for each programming language, the child process is created by cloning that runtime process, corresponding to the main thread, and the child process subsequently receives the target function information, loads the function code, and executes the function.);
switching control of the target child process to control of the function container (Page 42, right column; “FlashCube’s container runtime serves as the assembler, which attaches all the needed namespaces and cgroups (i.e., container parts) to an init process and configures the proper privileges 1, thus creating the final container sandbox for executing the target function code.”, which teaches switching control of the target child process to control of the function container because the child process is attached to the namespace and cgroup that define the function container execution environment, thereby placing the child process under control of the function container.);
and loading the function in the function container (Page 43, left column; “The execution point starts the logic to connect to the container runtime (in Section 4.2) for receiving the information of the target function, loads the function code, and begins execution”, teaches loading the function in the function container because the child process first connects to the container runtime, receives the target function information, then loads the function code for execution in the container runtime environment, thereby loading the function into the function container.).
Lin does not teach receiving a function call request sent by a user, wherein the function call request comprises information of a function; a process identifier of a corresponding function container; a namespace of the target child process is located in the function container; switching a control group; or being based on a process identifier of the target child process.
However, Rebeja teaches:
a process identifier of a corresponding function container (Col. 10, lines 35-44; “Web applications 104 receives the migration request 139, which may specify an identifier for each of the container and a target node to which the container is to be migrated (202). In some cases, the migration request 139 may specify an identifier of a current or source node on which the container is executing.”, explicitly discloses the use of an identifier, corresponding to a process identifier, of a corresponding function container.);
a namespace of the target child process is located in the function container (Col. 8, lines 31-43; “containers may be deployed according to Linux Containers (LXC), an operating-system-level virtualization method for running multiple isolated Linux systems (containers) on a control host using a single Linux kernel. LXC is an operating-system-level virtualization method for running multiple isolated Linux systems (containers) on a single control host (LXC host). An LXC does not use a virtual machine (although an LXC may be hosted by a virtual machine). Instead, an LXC uses a virtual environment with its own CPU, memory, block I/O, network, and/or other resource space. The LXC resource control mechanism is provided by namespaces and cgroups in the Linux kernel on the LXC host.”, where namespaces define the isolation contexts for processes executing within the container, and the child processes within a function container are associated with the namespace corresponding to that container due to the container’s isolation boundaries being defined by namespaces within the underlying operating system);
a control group (Col. 8, lines 31-43; “containers may be deployed according to Linux Containers (LXC)... The LXC resource control mechanism is provided by namespaces and cgroups in the Linux kernel on the LXC host.“);
based on a process identifier of the target child process (Col. 8, lines 31-43; “containers may be deployed according to Linux Containers (LXC), an operating-system-level virtualization method for running multiple isolated Linux systems (containers) on a control host using a single Linux kernel... The LXC resource control mechanism is provided by namespaces and cgroups in the Linux kernel on the LXC host” teaches that containerized environments are implemented using Linux kernel isolation mechanisms which operate on individually identifiably processes within the kernel.).
Lin and Rebeja are considered to be analogous to the claimed invention because they are in the same field of hypervisor management. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Lin to incorporate the teachings of Rebeja and have a namespace of the target child process located in the function container. A person of ordinary skill in the art before the effective filing date of the claimed invention would have recognized that implementing process isolation and execution context using namespaces and cgroups is a known method in Linux-based container systems yielding the predictable result of having processes executing in a system with a namespace that corresponds to the container’s isolation environment. Further, it would have been obvious to have switched a control group of a process in a containerized environment because cgroups are the standard Linux kernel mechanism for dynamically controlling process resource allocation and containerized systems use cgroup assignment to manage and isolate processes between execution contexts as disclosed by Liu, yielding the predictable result of enforcing correct resource control of processes executing within different container environments. Further, it would have been obvious to have performed actions based on a process identifier of the target child process because containers rely on namespaces/cgroups for managing and isolating processes and these kernel mechanisms operate by referencing and controlling processes using process identifiers, it would be obvious to have control within a containerized environment based on a process identifier of the target child process since PID-based identification is a standard mechanism in Linux for applying operations to specific namespaces/cgroups.
Lin in view of Rebeja does not teach receiving a function call request sent by a user, wherein the function call request comprises information of a function.
However, Michimura teaches:
receiving a function call request sent by a user, wherein the function call request comprises information of a function (Paragraph 14; “A VM executes, in addition to processing of a job assigned to the VM, a user interface process for processing a request made from the user. Examples of user interface processes include a login process that involves determining whether to permit the user to connect (log in) to the information processing system 10, a process that involves receiving settings on parameters (e.g., print attributes such as the number of copies to be printed) for a job, a process that involves receiving a request for starting execution of a job, and a process that involves, upon receipt of a request for checking the state of a print job, providing the user with information about the state of the job.”).
Lin, Rebeja, and Michimura are considered to be analogous to the claimed invention because they are in the same field of hypervisor management. Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to have modified Lin in view of Rebeja to incorporate the teachings of Michimura and have received a function call request sent by a user comprising information of a function. A person of ordinary skill in the art before the effective filing date of the claimed invention would have recognized that receiving a request with input parameters from a user is a known method in the art yielding the predictable result of condition-driven routing of processing operations for a function call request comprising function information.
Claim 8 recites similar limitations as those of claim 1, additionally reciting a processor, and a memory coupled to the processor and configured to store a plurality of instructions. Rebeja teaches:
a processor (Col. 15, lines 50-52; “Computing system 474 further includes one or more processors 476 that may implement functionality and/or execute instructions within computing system 474.”);
and a memory coupled to the processor and configured to store a plurality of instructions (Col. 16, lines 22-32; “The techniques described in this disclosure may also be embodied or encoded in a computer-readable medium, such as a computer-readable storage medium, containing instructions. Instructions embedded or encoded in a computer-readable medium may cause a programmable processor, or other processor, to perform the method, e.g., when the instructions are executed. Computer-readable media may include non-transitory computer-readable storage media and transient communication media. Computer readable storage media, which is tangible and non-transitory, may include random access memory (RAM)”).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to implement the use of a processor and memory coupled to the processor configured to store a plurality of instructions as usage of a processor executing instructions in memory is a known method of computational control, yielding the predictable result of reliable and programmable execution of processes in a standard computing environment.
Claim 8 is rejected for similar reasons as those of claim 1.
Claim 15 recites similar limitations as those of claim 1, additionally reciting a non-transitory computer-readable storage medium storing computer-executable instructions. Rebeja teaches:
a non-transitory computer-readable storage medium storing computer-executable instructions (Col. 16, lines 22-32; “The techniques described in this disclosure may also be embodied or encoded in a computer-readable medium, such as a computer-readable storage medium, containing instructions. Instructions embedded or encoded in a computer-readable medium may cause a programmable processor, or other processor, to perform the method, e.g., when the instructions are executed. Computer-readable media may include non-transitory computer-readable storage media and transient communication media.”).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to implement the use of a non-transitory computer-readable storage medium storing computer-executable instructions as usage of a processor executing instructions in a storage medium is a known method of computational control, yielding the predictable result of reliable and programmable execution of processes in a standard computing environment.
Claim 15 is rejected for similar reasons as those of claim 1.
Claims 2, 9, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Lin in view of Rebeja, further in view of Michimura, further in view of Masrani et al. (US 10817280 B1) hereafter Masrani.
Regarding claim 2, Lin in view of Rebeja, further in view of Michimura teach the method of claim 1. Michimura teaches:
receiving function information from a user (Paragraph 14; “A VM executes, in addition to processing of a job assigned to the VM, a user interface process for processing a request made from the user. Examples of user interface processes include a login process that involves determining whether to permit the user to connect (log in) to the information processing system 10, a process that involves receiving settings on parameters (e.g., print attributes such as the number of copies to be printed).
Lin in view of Rebeja, further in view of Michimura does not teach that the function information is received before receiving a function call request; or the function information comprises function code and a functional dependency; and deploying the function code and the functional dependency of the function in the function container.
However, Masrani teaches:
function code and a functional dependency (Col. 13, lines 21-24; “receiving the program code function at the computing hub may include receiving a function deployment package that contains a program code function and dependencies that include a service provider library.”);
and deploying the function code and the functional dependency of the function in the function container (Col. 13, lines 24-32; “After receiving the program code function, as in block 720, an instance of the program code function may be loaded for execution on the computing hub, wherein the computing hub may be included in a local device network that includes devices which connect to the computing hub. In one example, a software container may be launched that provides an isolated environment on the computing hub for an instance of the program code function to execute.”).
Lin, Rebeja, Michimura, and Masrani are considered to be analogous to the claimed invention because they are in the same field of hypervisor management. Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to have modified Lin in view of Rebeja, further in view of Michimura to incorporate the teachings of Masrani and have received the function code and dependencies before receiving the function call from the user. A person of ordinary skill in the art before the effective filing date of the claimed invention would have recognized the known concept that a function and its dependencies must be established before it can be invoked, whose implementation would yield the predictable result of enabling successful execution of the subsequently received function call request. Further, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to have the function information comprise function code and dependencies, and to deploy the function code and function dependency of the function in the function container. A person of ordinary skill in the art before the effective filing date of the claimed invention would have recognized that function code and its dependencies define the executable logic and runtime environment required for execution. Applying the known method of deploying these components within a function container would have predictably enabled the received function information to be instantiated in an execution environment with the resources and dependences necessary to correctly execute subsequent function call requests.
Claim 9 recites similar limitations as those of claim 2. Claim 9 is rejected for similar reasons as those of claim 2.
Claim 16 recites similar limitations as those of claim 2. Claim 16 is rejected for similar reasons as those of claim 2.
Claims 3, 10, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Lin in view of Rebeja, further in view of Michimura, further in view of Alwell (US 20220350574 A1).
Regarding claim 3, Lin in view of Rebeja, further in view of Michimura teach the method of claim 1. Lin in view of Rebeja, further in view of Michimura does not teach that the information of the function comprises at least one of a function name, a function type, or a function ID.
However, Alwell teaches:
the information of the function comprises at least one of a function name, a function type, or a function ID (Paragraph 44; “code injection component knows that the skip function includes parameters “id, name, count, and type””, explicitly disclosing that functions have parameters including name, type, and id.).
Lin, Rebeja, Michimura, and Alwell are considered to be analogous to the claimed invention because they are in the same field of hypervisor management. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Lin in view of Rebeja, further in view of Michimura to incorporate the teachings of Alwell and have the information of the function comprises at least one of a function name, a function type, or a function ID. A person of ordinary skill ion the art would have recognized that a function name, type, and identifier are known identifiers used to uniquely identify, classify, and locate executable functions, whose implementation would yield the predictable result of enabling accurate identification, retrieval, and invocation of the requested function during execution.
Claim 10 recites similar limitations as those of claim 3. Claim 10 is rejected for similar reasons as those of claim 3.
Claim 17 recites similar limitations as those of claim 3. Claim 17 is rejected for similar reasons as those of claim 3.
Claims 4, 11, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Lin in view of Rebeja, further in view of Michimura, further in view of Balmakhtar et al. (US 20230232236 A1) hereafter Balmakhtar.
Regarding claim 4, Lin in view of Rebeja, further in view of Michimura teach the method of claim 1. Lin teaches:
a template container (“FlashCube prepares and maintains a template runtime process for each programming language”, where a template runtime process used to generate function execution environments corresponds to the template container.);
a language runtime corresponding to the function (Page 43, left column; “FlashCube prepares and maintains a template runtime process for each programming language (e.g., Python, Java, and Node.js). The template runtime process pre-loads all common libraries in advance. Then, during the provisioning of a new function, the function’s runtime can be forked from the template runtime process”, where the disclosed template runtime process is maintained for each programming language, and during provisioning the function’s runtime is forked from the template runtime process. Therefore, the template runtime process corresponds to the language runtime required by the function, and the resulting runtime process is one corresponding to that function because it is created specifically to execute the function using its associated language runtime.).
Michimura teaches:
storing information of the container in storage (Paragraph 19; “For example, the VM control unit 20 creates, as information related to the condition of a VM in the ready state, a snapshot of the VM in the ready state, and stores the snapshot into the storage 22.”).
Lin in view of Rebeja, further in view of Michimura does not teach obtaining a container corresponding to the function if the container corresponding to the function exists; or if the container corresponding to the function does not exist, creating a container corresponding to the function; and storing the container.
However, Balmakhtar teaches:
obtaining a container corresponding to the function if the container corresponding to the function exists (Paragraph 45; “a determination is made whether a virtualization container corresponding to the virtualization container ID in the security descriptors exists”, and “if the virtualization container already exists or after the virtualization container is created, the UE initiates the application within the virtualization container”. The determination that the corresponding virtualization container already exists, followed by initiating the application within that existing container, requires retrieving the container for use. The retrieval and use of an existing container corresponds to obtaining a container corresponding to the function if the container corresponding to the function exists.);
or if the container corresponding to the function does not exist, creating a container corresponding to the function (Paragraph 45; “if the virtualization container does not already exist, a container management component on the UE creates the virtualization container based on the security descriptors”, which explicitly discloses determining whether the container exists, and if not, creating the corresponding container in response to the condition.);
Lin, Rebeja, Michimura, and Balmakhtar are considered to be analogous to the claimed invention because they are in the same field of hypervisor management. Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to have modified Lin in view of Rebeja, further in view of Michimura to incorporate the teachings of Balmakhtar and have performed steps before the forking a main thread of a language runtime process in a template container based on the process identifier of the function container, to obtain a target child process, and have obtained a container corresponding to the function if it exists, and if not, creating the container corresponding to the function and storing the container. A person of ordinary skill in the art before the effective filing date of the claimed invention would have recognized checking for an existing container prior to process instantiation and either obtaining the existing container or creating and storing a new container to be a known method in the art for managing reusable execution environments, yielding the predictable result of properly initialized and available execution environments present at the time of forking a main thread to obtain a target child process.
Claim 11 recites similar limitations as those of claim 4. Claim 11 is rejected for similar reasons as those of claim 4.
Claim 18 recites similar limitations as those of claim 4. Claim 18 is rejected for similar reasons as those of claim 4.
Claims 5, 12, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Lin in view of Rebeja, further in view of Michimura, further in view of Vanderspek et al. (US 6477591 B1) hereafter Vanderspek, further in view of Wang et al. (US 20230096015 A1) hereafter Wang, further in view of Narvaez et al. (US 20140189297 A1) hereafter Narvaez.
Regarding claim 5, Lin in view of Rebeja, further in view of Michimura teach the method of claim 1. Lin teaches:
the language runtime (Page 43, left column; “FlashCube prepares and maintains a template runtime process for each programming language (e.g., Python, Java, and Node.js). The template runtime process pre-loads all common libraries in advance. Then, during the provisioning of a new function, the function’s runtime can be forked from the template runtime process”, where the disclosed template runtime process is maintained for each programming language, and during provisioning the function’s runtime is forked from the template runtime process. Therefore, the template runtime process corresponds to the language runtime required by the function, and the resulting runtime process is one corresponding to that function because it is created specifically to execute the function using its associated language runtime).
Lin in view of Rebeja, further in view of Michimura does not teach wherein before the forking a main thread of a process in a template container based on the process identifier of the function container, to obtain a target child process, the method further comprises: when the function is multi-threaded, obtaining status information of each working thread in at least one working thread of the template container; in response to determining that the status information of each working thread in the at least one working thread is a first state, disabling each working thread in the at least one working thread, wherein the first state comprises any of: a state in which the working thread is blocked because of waiting for a task, a state in which the working thread does not store context, and a state in which the working thread has no logical interaction with the main thread; and when the at least one working thread comprises at least two working threads and in response to determining that the at least one working thread comprises at least two working threads and in response to determining that status information of the at least one of the at least two working threads is not the first state, suspending a working thread whose status information is the first state in the at least two working threads, and when status information of each working thread in the at least two working threads is the first state, disabling each working thread in the at least two working threads, or storing context of a working thread whose status information is not the first state, and disabling each working thread in the at least two working threads.
However, Vanderspek teaches:
obtaining status information of each working thread in at least one working thread of the template container (Col. 9, lines 49-59; “the worker thread updates it's status with the result of the I/O operation” shows that each worker thread maintains and updates its status as part of thread lifecycle processing. It would have been obvious that the system obtains status information for each working thread of the container in order to perform thread management operations and to monitor and retrieve thread state information of each worker thread as part of execution control in a multithreaded environment.);
performing an action in response to determining that the status information of each working thread in the at least one working thread is a first state (Col. 9, lines 49-59; “the worker thread gets a wake worker event, it checks (step 180) to see if the stop worker flag is set. A stop worker flag indicates that the worker thread should close its tape drive and shut down. This action is taken when the mirror is closed by the application. If the stop worker flag is set, the worker thread closes (step 182) the tape drive and terminates (step 184) the tape worker thread process for this tape drive.” Teaches performing an action in response to determining a thread status condition, where upon determining that the thread is in a corresponding state (flag set), it performs an action based on the state.);
disabling the working thread in the at least one working thread (Col. 9, lines 49-59; “it checks (step 180) to see if the stop worker flag is set. A stop worker flag indicates that the worker thread should close its tape drive and shut down. This action is taken when the mirror is closed by the application. If the stop worker flag is set, the worker thread closes (step 182) the tape drive and terminates (step 184) the tape worker thread process for this tape drive.”, which discloses disabling a working thread in response to a determined thread control condition is met, and termination corresponds to disabling the working thread of the at least one working thread.);
suspending a working thread whose status information is the first state in the at least two working threads (Col. 9, lines 49-59; “it checks (step 180) to see if the stop worker flag is set. A stop worker flag indicates that the worker thread should close its tape drive and shut down. This action is taken when the mirror is closed by the application. If the stop worker flag is set, the worker thread closes (step 182) the tape drive and terminates (step 184) the tape worker thread process for this tape drive.”, which discloses disabling a working thread in response to a determined thread control condition is met. Col. 5, lines 62-65 discusses “For some calls (identified as synchronous calls), execution of the application is suspended until indication of the completion of the API call is received from the operating system”, in which it would be obvious to perform a suspend operation on a thread whose status information calls for a suspension of execution.);
disabling each working thread in the at least two working threads (Col. 9, lines 49-59; “it checks (step 180) to see if the stop worker flag is set. A stop worker flag indicates that the worker thread should close its tape drive and shut down. This action is taken when the mirror is closed by the application. If the stop worker flag is set, the worker thread closes (step 182) the tape drive and terminates (step 184) the tape worker thread process for this tape drive.”, which discloses disabling a working thread in response to a determined thread control condition is met, and termination corresponds to disabling the working thread of the at least two working threads. It would have been obvious to apply the conditional working thread disabling mechanism to any thread that meets the criteria for disabling.).
Lin, Rebeja, Michimura, and Vanderspek are considered to be analogous to the claimed invention because they are in the same field of hypervisor management. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Lin in view of Rebeja, further in view of Michimura to incorporate the teachings of Vanderspek and have checked the status of working threads to perform actions thereon, including disabling working threads. A person of ordinary skill in the art before the effective filing date of the claimed invention would have recognized that conditional thread lifecycle management based on a per-thread status indicator is a known method for performing corresponding control actions, yielding the predictable result of enabling responsive state-driven control of individual threads to maintain correct execution behavior.
Lin in view of Rebeja, further in view of Michimura, further in view of Vanderspek does not teach checking when the function is multithreaded; or wherein the first state comprises any of: a state in which the working thread is blocked because of waiting for a task, a state in which the working thread does not store context, and a state in which the working thread has no logical interaction with the main thread.
However, Wang teaches:
wherein the first state comprises any of: a state in which the working thread is blocked because of waiting for a task, a state in which the working thread does not store context, and a state in which the working thread has no logical interaction with the main thread (Paragraph 16; “during execution of a certain task in a task sequence by a computing resource such as a thread, operations such as sleep, mutex, lock, and read/write may emerge, making the computing resource have to spin the task being processed and execute the above operations first. Once the thread is blocked, other tasks waiting for execution by the thread will have to wait”, teaches a state in which the working thread is blocked due to waiting for a task, corresponding to the element of a state in which the working thread is blocked because of waiting for a task.).
Lin, Rebeja, Michimura, Vanderspek, and Wang are considered to be analogous to the claimed invention because they are in the same field of hypervisor management. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Lin in view of Rebeja, further in view of Michimura, further in view of Vanderspek to incorporate the teachings of Wang and have the first state comprise a state in which the working thread is blocked because of waiting for a task. A person of ordinary skill in the art before the effective filing date of the claimed invention would have recognized that using a blocked state in which a working thread is waiting to proceed with task execution is a known thread state for controlling thread scheduling, yielding the predictable result of allowing the system to identify blocked threads and perform appropriate operations.
Lin in view of Rebeja, further in view of Michimura, further in view of Vanderspek, further in view of Wang does not teach checking when the function is multithreaded.
However, Narvaez teaches:
checking when the function is multithreaded (Paragraph 14; “mapping decision logic 1309 has determined that the workload currently running on the system is highly multithreaded”);
and when the at least one working thread comprises at least two working threads and in response to determining that the at least one working thread comprises at least two working threads (Paragraph 14; “mapping decision logic 1309 has determined that the workload currently running on the system is highly multithreaded”, determining whether the workload is multithreaded corresponds to when the working thread comprises at least two working threads.);
Lin, Rebeja, Michimura, Vanderspek, Wang, and Narvaez are considered to be analogous to the claimed invention because they are in the same field of hypervisor management. Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to have modified Lin in view of Rebeja, further in view of Michimura, further in view of Vanderspek, further in view of Wang to incorporate the teachings of Narvaez and have checked when the function is multithreaded, or comprises at least two working threads. A person of ordinary skill in the art before the effective filing date of the claimed invention would have recognized that determining whether a function comprises at least two working threads and managing threads based on their individual execution states is a known method in multithreaded computing systems, where the status of each working thread is monitored to identify blocked threads and perform corresponding management operations. Applying the known thread management technique to a multithreaded function would have yielded the predictable result of enabling coordinated management of all working threads based on their respective execution states, improving scheduling efficiency and resource utilization.
Claim 12 recites similar limitations as those of claim 5. Claim 12 is rejected for similar reasons as those of claim 5.
Claim 19 recites similar limitations as those of claim 5. Claim 19 is rejected for similar reasons as those of claim 5.
Claims 6, 13, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Lin in view of Rebeja, further in view of Michimura, further in view of Ball et al. (US 20160092407 A1) hereafter Ball.
Regarding claim 6, Lin in view of Rebeja, further in view of Michimura teach the method of claim 1. Lin teaches:
forking a thread to obtain a first child process (Page 43, left column; “FlashCube prepares and maintains a template runtime process for each programming language (e.g., Python, Java, and Node.js). The template runtime process pre-loads all common libraries in advance. Then, during the provisioning of a new function, the function’s runtime can be forked from the template runtime process”, and “Once receiving a forking request, the parasite code uses the clone system call to create a child process of the template runtime process”, because the template runtime process is maintained for each programming language, the child process is created by cloning that runtime process, corresponding to the main thread, and the child process subsequently receives the target function information, loads the function code, and executes the function);
switching control of the first child process to the function container (Page 42, right column; “FlashCube’s container runtime serves as the assembler, which attaches all the needed namespaces and cgroups (i.e., container parts) to an init process and configures the proper privileges 1, thus creating the final container sandbox for executing the target function code.”, which teaches switching control of the target child process to control of the function container because the child process is attached to the namespace and cgroup that define the function container execution environment, thereby placing the child process under control of the function container.).
Rebeja teaches:
namespaces (Col. 8, lines 31-43; “containers may be deployed according to Linux Containers (LXC)... The LXC resource control mechanism is provided by namespaces and cgroups in the Linux kernel on the LXC host”. Given the control mechanism is provided by both namespaces and cgroups on Linux, it would be obvious to have switched the namespace of the first child process to the function container.);
wherein the namespace of the target process is located in the function container (Col. 8, lines 31-43; “containers may be deployed according to Linux Containers (LXC)... The LXC resource control mechanism is provided by namespaces and cgroups in the Linux kernel on the LXC host”).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to have the namespace of the target child process located in the function container. A namespace defines the isolated execution environment of processes executing within a container, so a target child process having its namespace modified to a particular function container necessarily resides within the namespace within that container.
Lin in view of Rebeja, further in view of Michimura does not teach forking the main thread for the first time; switching control of the first child process to the function container based on the process identifier of the function container; and forking the first child process to obtain the target child process, wherein the namespace of the target child process is located in the function container.
However, Ball teaches:
forking the main thread for the first time (Paragraph 32; “Each worker process 304A-B may be a child process of the main process or may be a thread within main process 302. As such, the main process may generate a worker process by creating a new child process using, for example, spawning, forking or other similar functionality. Alternatively, generating a worker process may include creating a new thread using the appropriate functionality. In another example, the main process may re-use an existing thread or child process.”, explicitly discloses usage of the main process for forking.);
and forking the first child process to obtain the target child process (Paragraph 32; “Each worker process 304A-B may be a child process of the main process or may be a thread within main process 302. As such, the main process may generate a worker process by creating a new child process using, for example, spawning, forking or other similar functionality. Alternatively, generating a worker process may include creating a new thread using the appropriate functionality. In another example, the main process may re-use an existing thread or child process.”, explicitly disclosing the usage of an existing child process for forking, thereby obtaining another child process as a result.).
Lin, Rebeja, Michimura, and Ball are considered to be analogous to the claimed invention because they are in the same field of hypervisor management. Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to have modified Lin in view of Rebeja, further in view of Michimura to incorporate the teachings of Ball and forked a main thread for the first time, and forked a first child process to obtain a target child process. A person of ordinary skill in the art before the effective filing date of the claimed invention would have recognized forking a main thread to create an initial child process for function execution as a known method in process-based runtime systems, yielding the predictable benefit of efficiently instantiating target child processes from an initialized execution context and avoiding the overhead with creating a new process.
Claim 13 recites similar limitations as those of claim 6. Claim 13 is rejected for similar reasons as those of claim 6.
Claim 20 recites similar limitations as those of claim 6. Claim 20 is rejected for similar reasons as those of claim 6.
Claims 7 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Lin in view of Rebeja, further in view of Michimura, further in view of Cheng et al. (US 20020083143 A1) hereafter Cheng.
Regarding claim 7, Lin in view of Rebeja, further in view of Michimura teach the method of claim 1. Lin teaches:
the target child process (Page 43, left column; “FlashCube prepares and maintains a template runtime process for each programming language (e.g., Python, Java, and Node.js). The template runtime process pre-loads all common libraries in advance. Then, during the provisioning of a new function, the function’s runtime can be forked from the template runtime process”, and “Once receiving a forking request, the parasite code uses the clone system call to create a child process of the template runtime process”, because the template runtime process is maintained for each programming language, the child process is created by cloning that runtime process).
Lin in view of Rebeja, further in view of Michimura does not teach initializing a data structure used to manage a working thread, and creating a working thread of the process.
However, Cheng teaches:
initializing a data structure used to manage a working thread, and creating a working thread of the process (Paragraph 68; “HTTP server 231 allocates and initializes a data structure for each working thread that it will create, at 620. These data structures are used to communicate with the threads.”, explicitly teaches allocating and initializing a data structure for each working thread prior to creation, where the data structures are used for communication with the respective threads. This data structure stores thread-specific information used by the server to communicate with, identify, and coordinate operation of those threads, demonstrating that the data structures are maintained by the server for managing those threads.).
Lin, Rebeja, Michimura, and Cheng are considered to be analogous to the claimed invention because they are in the same field of hypervisor management. Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to have modified Lin in view of Rebeja, further in view of Michimura to incorporate the teachings of Cheng and have, after the switching a control group of the target child process to the function container based on the process identifier of the target child process, initialized a data structure used to manage a working thread, and creating a working thread of the target child process. A person of ordinary skill in the art before the effective filing date of the claimed invention would have recognized that performing thread initialization and creation after switching the target child process into the function container is a known method in containerized systems because working threads for a process would be preferably created only after the process has joined its intended container context so that the threads inherit the correct namespace and control group information, yielding the predictable benefit of ensuring that newly created working threads execute under the proper container isolation and resource management settings from the time they are created.
Claim 14 recites similar limitations as those of claim 7. Claim 14 is rejected for similar reasons as those of claim 7.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Knowles et al. (US 20190155648 A1) discusses executing a respective thread in each of a repeating sequence of time slots; and a plurality of context register sets, each comprising a respective set of registers for representing a state of a respective thread. The context register sets comprise a respective worker context register set for each of the number of time slots the execution unit is operable to interleave, and at least one extra context register set. The worker context register sets represent the respective states of worker threads and the extra context register set being represents the state of a supervisor thread.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KENNETH P TRAN whose telephone number is (571)272-6926. The examiner can normally be reached M-TH 4:30 a.m. - 12:30 p.m. PT, F 4:30 a.m. - 8:30 a.m. PT, or at Kenneth.Tran@uspto.gov.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, April Blair can be reached at (571) 270-1014. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/KENNETH P TRAN/Examiner, Art Unit 2196
/APRIL Y BLAIR/Supervisory Patent Examiner, Art Unit 2196
Prosecution Insights