DETAILED ACTION
This action is in response to an amendment to application 18/323842, filed on 1/21/2026. Claims 1-20 are pending. 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 § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Shillaker et al., “FAASM: Lightweight Isolation for Efficient Stateful Serverless Computing,” USENIX, July 17, 2020, hereinafter “Shillaker.”
Regarding claim 1, Shillaker anticipates “A method for starting a serverless container, (see, e.g., Shillaker, pg. 420, col. 1; “In this paper, we describe Faaslets, a new lightweight isolation abstraction for data-intensive serverless computing. Faaslets support stateful functions with efficient shared memory access, and are executed by our FAASM distributed serverless runtime.”; col. 2 “Faaslets have fast initialisation times.”) wherein the method comprises:
receiving a source code file of an application; compiling the source code file to generate a code segment file of the application and an initialization data file of the application; (see, e.g., Shillaker, pg. 425, col.1; “Fig.3shows the three phases to convert source code of a function into a Faaslet executable: (1) the user invokes the Faaslet toolchain to compile the function into a WebAssembly binary, linking against a language-specific declaration of the Faaslet host interface; (2) code generation creates an object file with machine code from WebAssembly; and (3) the host interface definition is linked with the machine code to produce the Faaslet executable.”
preloading the code segment file and the initialization data file; (see, e.g., Shillaker, pg. 426, col. 2; “While Faaslets typically initialise in under 10 ms, FAASM reduces this further using Proto-Faaslets.” pg. 427, col. 1; “Different Proto-Faaslets are generated for a function by specifying user-defined initialisation code, which is executed before snapshotting. If a function executes the same code on each invocation, that code can become initialisation code and be removed from the function itself. For Faaslets with dynamic language runtimes, the runtime initialisation can be done as part of the initialisation code.”)
deserializing the initialization data file to initialize memory of the application; (see, e.g., Shillaker, pg. 427, col. 1; “FAASM can serialise Proto-Faaslets and instantiate them across hosts.” “When a Faaslet undergoes a cold start, it loads the object file and Proto-Faaslet, and restores it.”; the initialization data file would be deserialized before initialization)
performing a snapshot operation on the memory to generate a snapshot file, wherein the snapshot file comprises a deserialized data segment of the application; (see, e.g., Shillaker, pg. 427, col. 1; “A Proto-Faaslet snapshot includes a function’s stack, heap, function table, stack pointer and data, as defined in the WebAssembly specification.”) and
uploading the code segment file and the snapshot file of the application to an image repository.” (see, e.g., Shillaker, pg. 427, col. 1; “Proto-Faaslets are generated and stored in the FAASM global state tier.”).
Regarding claim 2, Shillaker anticipates “The method of claim 1, further comprising:
loading the code segment file from the image repository to create an application instance; loading the snapshot file from the image repository; (see, e.g., Shillaker, pg. 427, col. 1; “Proto-Faaslets are generated and stored in the FAASM global state tier as part of this process. When a Faaslet undergoes a cold start, it loads the object file and Proto-Faaslet, and restores it.”) and
mapping the deserialized data segment to a data area of the application instance.” (see, e.g., Shillaker, pg. 427, col. 1; “A Proto-Faaslet snapshot includes a function’s stack, heap, function table, stack pointer and data, as defined in the WebAssembly specification. Since WebAssembly memory is represented by a contiguous byte array, containing the stack, heap and data, FAASM restores a snapshot into a new Faaslet using a copy-on-write memory mapping.”).
Regarding claim 3, Shillaker anticipates “The method of claim 2, wherein mapping the deserialized data segment comprises mapping the deserialized data segment using a copy-on-write technology.” (see, e.g., Shillaker, pg. 427, col. 1; “restores a snapshot into a new Faaslet using a copy-on-write memory mapping.”).
Regarding claim 4, Shillaker anticipates “The method of claim 1, wherein the code segment file and the snapshot file are separately stored.” (see, e.g., Shillaker, pg. 427, col. 1; “FAASM provides an upload service that exposes an HTTP endpoint. Users upload WebAssembly binaries to this end point, which then performs code generation (§3.4) and writes the resulting object files to a shared object store. The implementation of this store is specific to the underlying serverless platform but can be a cloud provider’s own solution such as AWS S3 [6].”
Regarding claim 5, Shillaker anticipates “The method of claim 4, wherein the code segment file and the snapshot file are separately loaded.” (see, e.g., Shillaker, pg. 427, col. 1; “Proto-Faaslets are generated and stored in the FAASM global state tier as part of this process. When a Faaslet undergoes a cold start, it loads the object file and Proto-Faaslet, and restores it.”)
Regarding claim 6, Shillaker anticipates “The method of claim 5, further comprising generating the initialization data file for a heap memory page of the application.” (see, e.g., Shillaker, pg. 427, col. 1; “A Proto-Faaslet snapshot includes a function’s stack, heap, function table, stack pointer and data, as defined in the WebAssembly specification. Since WebAssembly memory is represented by a contiguous byte array, containing the stack, heap and data, FAASM restores a snapshot into a new Faaslet using a copy-on-write memory mapping.”).
Regarding claims 7-12, the instant claims are equivalents of claims 1-6, differing only by statutory class. Accordingly, the rejections of claims 1-6 apply, mutatis mutandis, to claims 7-12.
Regarding claim 13, Shillaker anticipates “The starting device of claim 7, wherein the snapshot file comprises a deserialized heap memory page of the application.” (see, e.g., Shillaker, pg. 427, col. 1; “A Proto-Faaslet snapshot includes a function’s stack, heap, function table, stack pointer and data, as defined in the WebAssembly specification. Since WebAssembly memory is represented by a contiguous byte array, containing the stack, heap and data, FAASM restores a snapshot into a new Faaslet using a copy-on-write memory mapping.”).
Regarding claims 14-20, the instant claims are equivalents of claims 1-6 and 13, differing only by statutory class. Accordingly, the rejections of claims 1-6 apply, mutatis mutandis, to claims 14-19, and the rejection of claim 13 applies, mutatis mutandis, to claim 20.
Response to Arguments
Applicant’s arguments in traversal of the standing rejections are rendered moot by the foregoing new grounds of rejection.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RYAN D. COYER whose telephone number is (571) 270-5306 and whose fax number is (571) 270-6306. The examiner normally can be reached via phone on Monday-Friday 12pm-10pm Eastern Time. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Wei Mui, can be reached on 571-272-3708. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Ryan D. Coyer/Primary Examiner, Art Unit 2191