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 .
Claim Rejections - 35 USC § 101
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.
Claims 21-26 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claims do not fall within at least one of the four categories of patent eligible subject matter because Claim 21 recites “A computer program product comprising instructions that are stored on a computer- readable medium and that, when executed by one or more processors, cause a server implementing a serverless service to…”. Claims 22-26 depend on Claim 21. The present application’s specification states:
[0146] … The computer-readable storage medium may be any usable medium that can be stored by the server 100, or a data storage device, like a data center, including one or more usable media. The usable medium may be a magnetic medium (for example, a floppy disk, a hard disk drive, or a magnetic tape), an optical medium (for example, a DVD), a semiconductor medium (for example, a solid state drive), or the like. The computer-readable storage medium includes instructions, and the instructions instruct the server 100 to perform the foregoing service start method.
[0147] … The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on the server 100, the procedure or functions according to embodiments of this application are all or partially generated. The computer instructions may be stored in a computer-readable storage medium, or may be transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions may be transmitted from a website, a computing device, or a data center to another website, computing device, or data center in a wired (for example, a coaxial cable, an optical fiber, or a digital subscriber line (DSL)) or wireless (for example, infrared, radio, or microwave) manner.
The specification is not sufficiently clear. In light of the specification, the BRI of “computer- readable medium” can encompass non-statutory transitory forms of storage or non-statutory transitory forms of signal transmission, such as a propagating electrical or electromagnetic signal per se. See In re Nuijten, 500 F.3d 1346, 84 USPQ2d 1495 (Fed. Cir. 2007). When the BRI encompasses transitory forms of signal transmission or storage, a rejection under 35 U.S.C. 101 as failing to claim statutory subject matter would be appropriate.
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, 5, 14, 21, and 23 are rejected under 35 U.S.C. 103 as being unpatentable over Biernat (US 20220091899 A1) in view of Hotinger (US 11966769 B2), Featonby (US 11487591 B1) and Tikhomirov (US 12118379 B1).
Regarding Claim 1, Biernat teaches a method implemented by a server, implementing a serverless service (
Biernat discloses, “A container orchestration system 24, on the other hand, may operate in an information technology (IT) environment. That is, the container orchestration system 24 may include a cluster of multiple computing devices that coordinates an automatic process of managing or scheduling work of individual containers for applications within the computing devices of the cluster,” ¶ 0032, “the container orchestration system 24 may also be used to implement functions-as-a-service (FaaS) operations or serverless functions using the embodiments described herein,” ¶ 0075.
Here, the container orchestration system 24 is indicated to be a computer server consisting of a cluster of multiple computing devices. This container orchestration system implements serverless services.
The Examiner will also use a secondary reference to teach “server”.), and comprising:
obtaining service code (
Biernat discloses, “…the container node 30 may download the related container images 28 from the container registry 26. The container image 28, as mentioned above, represents data that encapsulates an application and its software dependencies. The container images 28 may be executable software bundles that may execute as standalone software without regard to the operating system that the corresponding container node 30 is using,” ¶ 0057, and “…package that may be retrieved and executed by the control system 66,” ¶ 0059.
The claimed “service code” is mapped to the disclosed code that is compressed/packed in the container image. After the container image is unpacked, the decompressed service code, including executables, binaries, scripts, etc. can be directly executed.
This aligns with paragraph 117 of the present application’s specification, which states “The worker process may download, from the OBS, service code submitted by the user. The service code is a compressed code package. The worker process may decompress the compressed code package to obtain decompressed service code, and then write the decompressed service code into the tmpfs. In this way, I/O overheads generated during code decompression can be reduced. Then, the runtime process may load the decompressed service code from the tmpfs, and execute the decompressed service code, to execute a call request of the serverless service, and start the serverless service. In this way, I/O overheads generated during code hot loading can be reduced.”);
unpacking(
Biernat discloses, “That is, container node 30 operating in the passive-direct mode may unpack a container image and push the resultant package to the industrial control system 12, such that the industrial control system 12 executes the package in response to receiving it from the container node 30,” ¶ 0037, “…the container node 30 may run or unpack the container images 28 and determine commands that may be performed by the control system 66 based on the container images 28. That is, the container images 28 may include software applications that are executable by container nodes 30,” ¶ 0058.
Here, a container image is unpacked to obtain its extracted contents (binaries, commands, software applications, etc.), which is unpacked service code.);
storingunpacked service code in a shared memory (
Biernat discloses, “After determining the commands that may be implemented by the control system 66 based on the container images 28, at block 118, the container node 30 may generate a package that may be retrieved and executed by the control system 66. That is, the container node 30 may organize or structure the determined commands into a software package that may be used by the control system 66,” ¶ 0059, “At block 120, the container node 30 may store the package in a memory or filesystem that is accessible to the control system 66,” ¶ 0060.
Here, the extracted contents of the container image (binaries, commands, etc.), are placed into a package that is then stored in a memory for access by the control system.
The memory is shared because both the container node 30 and the control system 66 can access it.);
and running(
Biernat discloses, “…package that may be retrieved and executed by the control system 66,” ¶ 0059, and “At block 120, the container node 30 may store the package in a memory or filesystem that is accessible to the control system 66,” ¶ 0060.
The contents of the package, originally from the container image, is retrieved from memory by the control system. The control system then executes the contents of the package.).
Biernat does not teach that the service code is obtained from a user,
starting a code decompression container,
decompressing, by the code decompression container, the service code to obtain decompressed service code,
storing, by the code decompression container, the decompressed service code in a shared memory,
starting a service container,
and running, by the service container, the service code using the shared memory.
However, Hotinger teaches that unpacking comprises decompressing (
Hotinger discloses, “A container's execution lifecycle in some systems may include pulling (i.e., downloading) content from a remote repository, unpackaging the content, creating a union file system on top of the content, and lastly creating a process based off the newly defined file system. Unpackaging content may include extracting selected content from surrounding data, e.g., copying content for a layer L out of a larger image file that includes content not only of layer L but also content of other layers. Unpackaging content may also include unpacking, which is used herein as a synonym for ‘decompressing’. Unpackaging content may also include decrypting content. In some systems, the majority of time spent after a container instantiation is requested and before the execution of the container's process begins is spent during the pulling and unpacking of content,” Col 3, Lines 64-67 and Col 4, Lines 1-11.
After the combination of Biernat with Hotinger, the unpacking of the container image from Biernat is explicitly specified to be decompressing as specified by Hotinger, such that the container image is decompressed to obtain its contents, which are then stored in shared memory.).
Biernat and Hotinger are both considered to be analogous to the claimed invention because they are in the same field of computer container 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 Biernat to incorporate the teachings of Hotinger and that decompressing is equivalent to unpacking. Doing so would ensure that the compressed code uses up less storage space before being decompressed, in order to improve transmission performance of the compressed code across a network.
Biernat in view of Hotinger does not teach that the service code is obtained from a user,
starting a code decompression container,
decompressing, by the code decompression container, the service code to obtain decompressed service code,
storing, by the code decompression container, the decompressed service code in a shared memory,
starting a service container,
and running, by the service container, the service code using the shared memory.
However, Featonby teaches that the service code is obtained from a user (
Featonby discloses, “The user who uploaded the container image onto the container registry service 130 at the time of uploading the container image (or a public repository within or external to the cloud network provider 120),” Col 4, Lines 15-18.
Here, service code in the form of a container image can be uploaded to a registry or repository by a user.).
Biernat in view of Hotinger, and Featonby are both considered to be analogous to the claimed invention because they are in the same field of computer container/pod 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 Biernat in view of Hotinger to incorporate the teachings of Featonby and provide that the service code is obtained from a user. Doing so would help allow for the user to specify a desired service code to be uploaded to the registry or repository, so that other users or systems may download it for use when needed, thus improving convenience and flexibility.
Biernat in view of Hotinger and Featonby does not teach starting a code decompression container,
decompressing, by the code decompression container, the service code to obtain decompressed service code,
storing, by the code decompression container, the decompressed service code in a shared memory,
starting a service container,
and running, by the service container, the service code using the shared memory.
However, Tikhomirov teaches starting a code decompression container (
Tikhomirov discloses, “In one exemplary aspect, the container management module 120 generates and maintains the service container 118 on a per-package, per-installation, or per-target container basis. In one exemplary aspect, a particular service container 118, for example, is temporarily created to manage installation of an instance of a package or of a set of packages and may be terminated upon completion of package installation and/or based on a termination command from the container management module 120,” Col 7, Lines 23-31,
“In one exemplary aspect of the scenario 200b any of the following optional steps may also be performed: using a network access 218 (e.g., provided by the host system 102) to download the package 206 over the network 209 (which is an example of the connection 106), such as, for example, from the network package source; retrieving package file 220 from the package 206 (e.g., unpacking, decompressing, decrypting, etc.); copying (e.g., by the package manager 130 process of the service container 118, or by host process, etc.) package files 220 to the container file system 126 of the target container 116; etc.,” Col 10, Lines 1-11,
“The service container 118, for instance, may include a package manager 130 process as one of the service container's processes 128. In one aspect, the package manager 130 is operable to manage different package installation actions such as download (which is optional) and execution of package files 220. The package manager 130, for instance, may download and unpack the package files 220, copy the package files 220 to the container file system 126, and then initiate package scripts which in turn may start execution of a binary file from the target container file system 126 for package installation,” Col 11, Lines 13-23.
The claimed “code decompression container” is mapped to the disclosed “service container 118”, which unpacks files from a package before copying them to a target container’s filesystem. After the combination of Biernat in view of Hotinger and Featonby, with Tikhomirov, the unpacking of these files is specified to be decompressing of the files, as specified by Hotinger.),
decompressing, by the code decompression container, the service code to obtain decompressed service code, storing, by the code decompression container, the decompressed service code in a shared memory (
Tikhomirov discloses, “FIG. 2b depicts an example scenario 200b illustrating a container file system access as part of secure package installation into a target container. The service container 118 can execute the package files 220 and files from the target container file system 126 from within the context of the service container 118, such as detailed throughout this disclosure. In the scenario, the service container 118 obtains access to the container file system 126 and to the files on it via the service container file system 134. Example ways for enabling the service container 118 to access the container file system 126 are detailed below,” Col 9, Lines 57-67,
“In one exemplary aspect of the scenario 200b any of the following optional steps may also be performed: using a network access 218 (e.g., provided by the host system 102) to download the package 206 over the network 209 (which is an example of the connection 106), such as, for example, from the network package source; retrieving package file 220 from the package 206 (e.g., unpacking, decompressing, decrypting, etc.); copying (e.g., by the package manager 130 process of the service container 118, or by host process, etc.) package files 220 to the container file system 126 of the target container 116; etc.,” Col 10, Lines 1-11.
The service container 118 unpacks a package 206 and stores the resulting code, or package files, to the file system of the target container 116. After the combination of Biernat in view of Hotinger and Featonby, with Tikhomirov, this unpacking is specified to be decompressing, as specified by Hotinger.),
starting a service container (
Tikhomirov discloses, “The target container 116 generally represents a container created by the container management module 120 for various purposes, such as for providing a virtual execution environment for executing container processes 122… The container processes 122, for example, represent applications and other functionality that execute within the context of the target container 116. The target container 116 also includes target container resources 124 which is a subset of host OS resources 108 and, may in one exemplary aspect, include a target container file system 126 and/or target container processes 122. The target container resources 124 generally represent resources utilized by the target container 116 such as, for example, for execution of the container processes 122,” Col 6, Lines 50-65.
The claimed “service container” is mapped to the disclosed “target container 116”.),
and running, by the service container, the service code using the shared memory (
Tikhomirov discloses, “In one exemplary aspect of the scenario 200b any of the following optional steps may also be performed: using a network access 218 (e.g., provided by the host system 102) to download the package 206 over the network 209 (which is an example of the connection 106), such as, for example, from the network package source; retrieving package file 220 from the package 206 (e.g., unpacking, decompressing, decrypting, etc.); copying (e.g., by the package manager 130 process of the service container 118, or by host process, etc.) package files 220 to the container file system 126 of the target container 116; etc.,” Col 10, Lines 1-11,
“Step 414 executes the script files. For instance, executing of the script files can perform actions such as: a) checks for status of the target container, packages already installed un the target container, and/or the package; and b) configuration of: target container, the package and/or other packages (e.g., integration with them); and/or OS configuration files in target container file system. Both a) and b) may also run (start execution) of a binary (or script, etc.) file from target container file system 126,” Col 16, Lines 58-67.
The claimed “service container”, or disclosed “target container 116”, runs the package files that were copied to it by the claimed “code decompression container”, or disclosed “service container 118”.
After the combination of Biernat in view of Hotinger and Featonby, with Tikhomirov, target container 116 from Tikhomirov uses Biernat in view of Hotinger and Featonby’s shared memory to run the package files.).
Biernat in view of Hotinger and Featonby, and Tikhomirov are both considered to be analogous to the claimed invention because they are in the same field of serverless-based code. 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 Biernat in view of Hotinger and Featonby to incorporate the teachings of Tikhomirov and provide starting a code decompression container, decompressing, by the code decompression container, the service code to obtain decompressed service code, storing, by the code decompression container, the decompressed service code in a shared memory, starting a service container, and running, by the service container, the service code using the shared memory. Doing so would help allow for having the decompression step and service startup step be performed by containers in order to maintain a higher level of modularity by separating the functionalities into different containers.
Claims 10 and 21 are a server claim and a computer program product claim, respectively, corresponding to the method Claim 1. In addition, Claim 10 recites a server configured to implement a serverless service and comprising: a first memory configured to store a computer program; and one or more processors coupled to the first memory and configured to execute the computer program to cause the server to… (
Biernat discloses, “The industrial control system 12 may include a communication component 42, a processor 44, a memory 46, a storage 48, input/output (I/O) ports 50, a display 20, and the like. The communication component 42 may be a wireless or wired communication component that facilitates communication between the container orchestration system 24 and the industrial control system 12, or any other suitable electronic device,” ¶ 0040, and
“The memory 46 and the storage 48 may be any suitable article of manufacture that may serve as media to store processor-executable code, data, or the like. These articles of manufacture may represent computer-readable media (i.e., any suitable form of memory or storage) that may store the processor-executable code used by the processor 44 to perform the presently disclosed techniques. The memory 46 and the storage 48 may represent non-transitory computer-readable media (e.g., any suitable form of memory or storage) that may store the processor-executable code used by the processor 44 to perform various techniques described herein,” ¶ 0041.).
In addition, Claim 21 recites a computer program product comprising instructions that are stored on a computer- readable medium and that, when executed by one or more processors, cause a server implementing a serverless service to… (
Biernat discloses, “The industrial control system 12 may include a communication component 42, a processor 44, a memory 46, a storage 48, input/output (I/O) ports 50, a display 20, and the like. The communication component 42 may be a wireless or wired communication component that facilitates communication between the container orchestration system 24 and the industrial control system 12, or any other suitable electronic device,” ¶ 0040, and
“The memory 46 and the storage 48 may be any suitable article of manufacture that may serve as media to store processor-executable code, data, or the like. These articles of manufacture may represent computer-readable media (i.e., any suitable form of memory or storage) that may store the processor-executable code used by the processor 44 to perform the presently disclosed techniques. The memory 46 and the storage 48 may represent non-transitory computer-readable media (e.g., any suitable form of memory or storage) that may store the processor-executable code used by the processor 44 to perform various techniques described herein,” ¶ 0041.).
Therefore, Claims 10 and 21 are rejected for the same reasons set forth in the rejection of Claim 1, in addition to the additional limitations of Claims 10 and 21 being taught by Biernat.
Regarding Claim 5, Biernat in view of Hotinger, Featonby, and Tikhomirov teaches the method of claim 1, wherein the shared memory is located in the server for deploying the service container and the shared memory is independent of a memory of the user in the server, the serverless service comprises a function-as-a-service (FaaS), a backend-as-a-service (BaaS), or a microservice, a size of the shared memory is based on meta information of the service code and the meta information comprises a first size of the service code or a second size of the decompressed service code, or the shared memory is managed by a memory file system (
Biernat discloses, “In addition to coordinating the communication between the IT system and the OT system, the container orchestration system 24 may also be used to implement functions-as-a-service (FaaS) operations or serverless functions using the embodiments described herein,” ¶ 0075, and “By way of introduction, serverless functions or FaaS operations corresponds to a computing scheme that allows certain logic or applications (e.g., packages, containers) be executed without regard to the available computing resources available on a respective device,” ¶ 0075.
Here, Biernat defines serverless functions and FaaS operations as independent of the available computing resources available on a respective device. This aligns with paragraph 4 of the present application’s specification, which states “The serverless service may have a plurality of service forms, in which function-as-a-service (FaaS) is a representative one, which allows a developer to build, compute, run, and manage an application of the developer in a form of a function, without maintaining infrastructure of a backend.”
Claim 5 only requires that at least one of its limitations, separated by an “or” clause, be satisfied. Biernat teaches at least one of the limitations, that “the serverless service comprises a function-as-a-service (FaaS), a backend-as-a-service (BaaS), or a microservice”, and thus Biernat teaches the method of Claim 5.).
Claims 14 and 23 are a server claim and a computer program product claim, respectively, corresponding to the method Claim 5. Therefore, Claims 14 and 23 are rejected for the same reasons set forth in the rejection of Claim 5.
Claims 4, 13, and 22 are rejected under 35 U.S.C. 103 as being unpatentable over Biernat (US 20220091899 A1) in view of Hotinger (US 11966769 B2), Featonby (US 11487591 B1) Tikhomirov (US 12118379 B1), and Holzman (US 20230035600 A1).
Regarding Claim 4, Biernat in view of Hotinger, Featonby, and Tikhomirov teaches the method of claim 1. Biernat in view of Hotinger, Featonby, and Tikhomirov does not teach wherein both the service container and the code decompression container are deployed on a bare metal server or a virtual machine, the shared memory is located in the server for deploying the service container and the code decompression container, or the service container and the code decompression container belong to a same pod.
However, Holzman teaches wherein both the service container and the code decompression container are deployed on a bare metal server or a virtual machine, the shared memory is located in the server for deploying the service container and the code decompression container, or the service container and the code decompression container belong to a same pod (
Holzman discloses, “A server associated with a cloud management platform, the server comprising: one or more processors; and memory storing one or more programs configured to be executed by the one or more processors, the one or more programs including instructions for: receiving a request to deploy a cloud infrastructure on a cloud service provider based on a cloud template of the cloud management platform; transmitting configuration instructions associated with a cloud infrastructure tool to a container orchestration platform for execution on one or more containers running on the container orchestration platform to deploy the cloud infrastructure,” ¶ 0007.
Here, Holzman teaches that a server includes memory for deploying cloud infrastructure. After the combination of Biernat in view of Hotinger, Featonby, and Tikhhomirov, the server uses the shared memory from Biernat in view of Hotinger, Featonby, and Tikhhomirov to deploy the service container and the code decompression container.).
Biernat in view of Hotinger, Featonby, and Tikhomirov, and Holzman are both considered to be analogous to the claimed invention because they are in the same field of online cloud deployment. 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 Biernat in view of Hotinger, Featonby, and Tikhomirov to incorporate the teachings of Holzman and provide wherein both the service container and the code decompression container are deployed on a bare metal server or a virtual machine, the shared memory is located in the server for deploying the service container and the code decompression container, or the service container and the code decompression container belong to a same pod. Doing so would help allow for increased performance from using the shared memory for deployment of the containers (Holzman discloses, “A cloud infrastructure provided by a cloud service provider generally includes high-performance compute, memory and network resources or components,” ¶ 0021.).
Claims 13 and 22 are a server claim and a computer program product claim, respectively, corresponding to the method Claim 4. Therefore, Claims 13 and 22 are rejected for the same reasons set forth in the rejection of Claim 4.
Claims 6, 16, and 24 are rejected under 35 U.S.C. 103 as being unpatentable over Biernat (US 20220091899 A1) in view of Hotinger (US 11966769 B2), Featonby (US 11487591 B1), Tikhomirov (US 12118379 B1), and Jin (US 10768973 B1).
Regarding Claim 6, Biernat in view of Hotinger, Featonby, and Tikhomirov teaches the method of claim 1. Biernat in view of Hotinger, Featonby, and Tikhomirov does not teach further comprising: obtaining a configuration file, wherein a type of a default volume in the configuration file is configured as a memory; and mounting the shared memory based on the configuration file.
However, Jin teaches further comprising:
obtaining a configuration file, wherein a type of a default volume in the configuration file is configured as a memory; and mounting the shared memory based on the configuration file (
Jin discloses, “A4 involves determining information about a volume mount point based on the mount point field in the container configuration file config.v2.json. For example, through analysis of the Name and Source fields of the json structure of MountPoints, it is possible to determine whether the volume is mounted on the default volume mount point or on a custom data mount point, and to at last locate it to the volume root directory,” Col 12, Lines 11-18.
Here, a configuration file specifies a type of volume mount point, such as default or custom, that is used for mounting a volume. After the combination of Biernat in view of Hotinger, Featonby, and Tikhomirov, with Jin, the shared memory from Biernat in view of Hotinger, Featonby, and Tikhomirov would be mounted based on this configuration file as specified by Jin.).
Biernat in view of Hotinger, Featonby, and Tikhomirov, and Jin are both considered to be analogous to the claimed invention because they are in the same field of container-based deployment. 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 Biernat in view of Hotinger, Featonby, and Tikhomirov to incorporate the teachings of Jin and provide further comprising: obtaining a configuration file, wherein a type of a default volume in the configuration file is configured as a memory; and mounting the shared memory based on the configuration file. Doing so would help allow for using the configuration file to obtain information about the shared memory before mounting it, in order to reduce the risk of errors occurring when mounting (Jin discloses, “and based on a mount point field in the container configuration file, determining information about a volume mount point,” Col 3, Lines 21-23.).
Claims 16 and 24 are a server claim and a computer program product claim, respectively, corresponding to the method Claim 6. Therefore, Claims 16 and 24 are rejected for the same reasons set forth in the rejection of Claim 6.
Claims 7, 17, and 25 are rejected under 35 U.S.C. 103 as being unpatentable over Biernat (US 20220091899 A1) in view of Hotinger (US 11966769 B2), Featonby (US 11487591 B1), Tikhomirov (US 12118379 B1) and Ye (WO 2022120577 A1).
Regarding Claim 7, Biernat in view of Hotinger, Featonby, and Tikhomirov teaches the method of claim 1. Biernat in view of Hotinger, Featonby, and Tikhomirov does not teach further comprising:
receiving a real-time event released by a management network element, wherein the real- time event is configured to trigger a cold start of the serverless service; and dynamically mounting the shared memory based on the real-time event.
However, Ye teaches further comprising:
receiving a real-time event released by a management network element, wherein the real- time event is configured to trigger a cold start of the serverless service; and dynamically mounting the shared memory based on the real-time event (
Ye discloses, “…and when a function execution request is received, mounting the target file in a container serving as a function executor, and directly executing a function within the target file (S4). By means of performing function pre-processing on a function after a user submits a function request, generating an executable target file or an intermediate file, performing saving, and mounting a data volume of a directory corresponding to a function during a cold start of a container serving as a function executor, consequently after the container starts, it is not necessary to start interpreting or compiling from source code, and cold start delay is reduced.,” Abstract, and “Service discovery module: The service discovery module is responsible for managing the information of the function executors running in the whole system. When the service discovery module receives the request from the controller module, it will retrieve all the running function executors. The function executor will return the container information to the controller module, and if not found, it will notify the controller module to prepare to cold start the function executor,” Page 6, and “If the function executor needs to be cold-started, the container scheduler module uses the function information and user information to retrieve the corresponding file information from the storage module, and mounts the file into the container when the container as the function executor is cold-started,” Page 7.
Here, a notification (mapped to claimed “real-time event”) is received from a “service discovery module” (mapped to claimed “management network element”), and in response, a container is cold-started and a data volume is mounted to said container. After the combination of Biernat in view of Hotinger, Featonby, and Tikhomirov, with Ye, the container from Biernat in view of Hotinger, Featonby, and Tikhomirov is cold-started, and the shared memory from Biernat in view of Hotinger, Featonby, and Tikhomirov is mounted to the container in response to receiving a notification from a service discovery module, as specified by Ye.).
Biernat in view of Hotinger, Featonby, and Tikhomirov, and Ye are both considered to be analogous to the claimed invention because they are in the same field of serverless-based code. 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 Biernat in view of Hotinger, Featonby, and Tikhomirov to incorporate the teachings of Ye and provide further comprising: receiving a real-time event released by a management network element, wherein the real- time event is configured to trigger a cold start of the serverless service; and dynamically mounting the shared memory based on the real-time event. Doing so would help ensure that the shared memory is automatically mounted when the real-time event is received, reducing cold start delay as a result (Ye discloses, “By means of performing function pre-processing on a function after a user submits a function request, generating an executable target file or an intermediate file, performing saving, and mounting a data volume of a directory corresponding to a function during a cold start of a container serving as a function executor, consequently after the container starts, it is not necessary to start interpreting or compiling from source code, and cold start delay is reduced.”).
Claims 17 and 25 are a server claim and a computer program product claim, respectively, corresponding to the method Claim 7. Therefore, Claims 17 and 25 are rejected for the same reasons set forth in the rejection of Claim 7.
Claims 8, 18, and 26 are rejected under 35 U.S.C. 103 as being unpatentable over Biernat (US 20220091899 A1) in view of Hotinger (US 11966769 B2), Featonby (US 11487591 B1), Tikhomirov (US 12118379 B1) and Prinsloo (US 20180173552 A1).
Regarding Claim 8, Biernat in view of Hotinger, Featonby, and Tikhomirov teaches the method of claim 1. Biernat in view of Hotinger, Featonby, and Tikhomirov does not teach further comprising unmounting the shared memory when running of the serverless service is abnormal or completed.
However, Prinsloo teaches further comprising unmounting the shared memory when running of the serverless service is abnormal or completed (
Prinsloo discloses, “The example embodiment of the invention further comprises a means for removing from the memory, the project specific functioning virtual machine after completion of the project specific function and storing the updated project specific content in the central content store. In this manner proliferation is minimized of unused project specific function virtual machine images in order to free-up storage space in the memory,” ¶ 0010.
Here, a virtual machine is removed/unmounted when its associated function is completed, in order to free up storage space.
This aligns with paragraph 111 of the present application’s specification, which states that “Further, when running of the serverless service is abnormal or completed, the server 100 may further unmount the shared memory, to reclaim a memory resource.”
After the combination of Biernat in view of Hotinger, Featonby, and Tikhomirov, with Prinsloo, the shared memory from Biernat in view of Hotinger, Featonby, and Tikhomirov is removed/unmounted when the serverless service from Biernat in view Hotinger, Featonby, and Tikhomirov has completed, as specified by Prinsloo.).
Biernat in view of Hotinger, Featonby, and Tikhomirov, and Prinsloo are both considered to be analogous to the claimed invention because they are in the same field of server-based computing. 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 Biernat in view of Hotinger, Featonby, and Tikhomirov to incorporate the teachings of Prinsloo and provide further comprising unmounting the shared memory when running of the serverless service is abnormal or completed. Doing so would help ensure that the shared memory does not accumulate unnecessary resource usage, thus preserving resource efficiency of the host system.
Claims 18 and 26 are a server claim and a computer program product claim, respectively, corresponding to the method Claim 8. Therefore, Claims 18 and 26 are rejected for the same reasons set forth in the rejection of Claim 8.
Claims 9 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Biernat (US 20220091899 A1) in view of Hotinger (US 11966769 B2), Featonby (US 11487591 B1), Tikhomirov (US 12118379 B1) and Chin (US 20120023319 A1).
Regarding Claim 9, Biernat in view of Hotinger, Featonby, and Tikhomirov teaches the method of claim 1, further comprising: presenting a start configuration interface to the user (
Featonby discloses, “As shown in FIG. 2, the user interface 200 also includes a user interface element for initiating generation of a task definition based on the information provided in the user interface 200. Alternatively, or additionally, the user interface 200 may include a ‘launch task’ button for initiating execution of the container images specified in the user interface 200 according to the task definition automatically generated based on the information provided in the user interface 200,” Col 11, Lines 15-23).
Biernat and Featonby are both considered to be analogous to the claimed invention because they are in the same field of computer container/pod 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 Biernat to incorporate the teachings of Featonby and provide further comprising: presenting a start configuration interface to the user. Doing so would help allow for the user to specify configuration parameters for a service to be launched, thus improving flexibility of the startup process.
Biernat in view of Hotinger, Featonby, and Tikhomirov does not teach receiving a start manner configured by the user through the start configuration interface; and further storing the decompressed service code in the shared memory when the start manner is quick start.
However, Chin teaches receiving a start manner configured by the user through the start configuration interface (
Chin discloses, “In this embodiment, when network device 100 boots (either a cold boot or a warm boot), the wmem variable indicates the size of the warm memory. The warm memory capability of the system may be disabled by setting the wmem to zero. In one embodiment, after a boot, network device 100 operates in a warm memory-enabled mode upon detecting that the warm memory size boot parameter (e.g., wmem) is set to a non-zero value,” ¶ 0041.
After the combination of Biernat in view of Hotinger, Featonby, and Tikhomirov, with Chin, the user interface from Biernat in view of Hotinger, Featonby, and Tikhomirov is configured to select whether the service undergoes a cold boot/start or a warm boot/start, as specified by Chin.);
and further storing the decompressed service code in the shared memory when the start manner is quick start (
Chin discloses, “In one embodiment, techniques are provided that enable volatile memory associated with a processing element to be configured to comprise a memory section (referred to as warm memory) for storing data that is to be persisted across a warm boot,” ¶ 0009, “A software component can be either program instructions or data. A power-cycle is also referred to as a ‘cold-boot’ (also sometimes referred to as a ‘cold reboot’). As opposed to a cold boot, a ‘warm boot’ (also sometimes referred to as a ‘warm reboot’) does not involve a power-cycle. A warm boot of a system restarts the operating system without cycling power to the system. A warm boot thus causes the operating system to be reloaded into volatile memory of the system without cycling power to the system,” ¶ 0039, and “As a result, the time to recovery of the application (i.e., the time when the application is up and running at a state the application was executing at prior to the warm boot) from the time of the warm boot is much faster than in conventional systems. The recovery/re-startability time of the application from a warm boot is significantly improved since the application-related data persisted in the warm memory is in the same state as it was prior to the warm boot,” ¶ 0096.
The claimed “quick start” is mapped to the disclosed “warm boot”. This is a quick start because it stores data in memory to be persisted before the application is restarted or recovered, thus reducing the amount of time taken to start the application compared to conventional startup methods.
After the combination of Biernat in view of Hotinger, Featonby, and Tikhomirov, with Chin, the decompressed service code from Biernat in view of Hotinger, Featonby, and Tikhomirov is stored in shared memory if the option of warm boot/start is selected, as specified by Chin).
Biernat in view of Hotinger, Featonby, and Tikhomirov, and Chin are both considered to be analogous to the claimed invention because they are in the same field of computer-based data storage and persistence. 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 Biernat in view of Hotinger, Featonby, and Tikhomirov to incorporate the teachings of Chin and receiving a start manner configured by the user through the start configuration interface; and further storing the decompressed service code in the shared memory when the start manner is quick start. Doing so would help ensure that the decompressed service code can be retrieved more quickly during quick start, instead of having to unpack and recopy the code to the shared memory.
Claim 20 is a server claim corresponding to the method Claim 9. Therefore, Claim 20 is rejected for the same reasons set forth in the rejection of Claim 9.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Chen (US 20230297352 A1): Method For Starting Serverless Container And Related Device
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ANDREW SUN whose telephone number is (571)272-6735. The examiner can normally be reached Monday-Friday 8:00-5:00.
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, Aimee Li can be reached at (571) 272-4169. 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.
/ANDREW NMN SUN/ Examiner, Art Unit 2195
/Aimee Li/ Supervisory Patent Examiner, Art Unit 2195
Prosecution Insights