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 .
Remarks
The present application having Application No. 18/761,833 filed on 07/02/2024 presents claims 1-21 for examination.
Priority
Applicant’s claim for the benefit of a prior-filed application under 35 U.S.C. 119(e) or under 35 U.S.C. 120, 121, 365(c), or 386(c) is acknowledged. The present application claims the benefit and priority of U.S. Provisional Application No. 63/526312 filed on July 12, 2023.
Drawings
The applicant’s drawings submitted are acceptable for examination purposes.
Information Disclosure Statement
As required by M.P.E.P. 609, the applicant’s submissions of the Information Disclosure Statement (IDS), submitted on 01/07/2025, is acknowledged by the examiner and the cited references have been considered in the examination of the claims now pending.
Examiner Notes
Examiner cites particular columns and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “an execution engine configured to…”, “an invocation manager configured to…,” “an access control module is configured to…” in claim 1-10.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
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 of this title, 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-2 and 11-12 are rejected under AIA 35 U.S.C. 103 as being unpatentable over Hoste et al. (US 2023/0086877 A1) (hereinafter Hoste) in view of Wimmer et al. (US 2020/0117509 A1) (hereinafter Wimmer), and further in view of Brooker et al. (US 2021/0240509 A1) (hereinafter Brooker).
As per claim 1, Hoste discloses A managed execution environment (e.g. Hoste: teaches a cloud computing platform for secure execution of third-party code from different tenants on shared computing infrastructure. Hoste explains that the cloud platform provides execution environment for the execution of third-party code, and that the execution environments are isolated from one another [0002-0005]. Also see [0044-0048] [Fig. 2, intra-process execution environment 241]), comprising: an internal invocation request for executing code in the managed execution environment, where the internal invocation request includes code for execution and the code for execution is written in a scripting language (e.g. Hoste: teaches receiving a request to execute computer code for a tenant in an intra-process execution environment. Hoste states that a request may triggered by an HTTP request, database update, remote procedure call, or application-specific notification [0009-0012]. Hoste further explains that a computer server receives the execution request and that the request can be received at a gateway module or API gateway. The request may include a reference to the computer code, a reference to the tenant, and input data for execution of the code [0049]. Hoste also teaches that the request may contain task metadata indicating program code to be executed, the programming language, user identity, resource constraints, permissions, and locations of code objects/libraries [0057-0060]. JavaScript engine, that executes different third-party codes, e.g. JavaScript code [0005]. The computer code may comprise a scripted code, that may be code written in a scripting language, e.g, JavaScript, Python, PHP, Perl, or Ruby [0018]. Also see [Abstract] [0008] [0016] [0027] [0030] [0044] [0050].); an execution engine configured to receive and process the internal invocation request (e.g. Hoste: teaches that a global process executes computer code from multiple tenants in different isolated intra-process execution environments. Hoste identifies the process as a runtime engine, including a JavaScript engine that executes different third-party JavaScript code in an isolated manner [0004-0005]. Hoste further teaches that a dispatcher receives the request and allocates code to a global queue or tenant-specific queue. A process then fetches, loads, and executes code form the appropriate queue [0057-0064]. Accordingly, Hoste’s process and corresponding runtime engine teach an execution engine configured to receive and process and execution request for code.); wherein, upon receipt of the internal invocation request, the execution engine creates an execution context for the code for execution and starts execution of the code for execution in the execution context, where creating the execution context includes creating a second memory space for execution of the code, such that the execution context permits changes to code contained in the second memory space (e.g. Hoste: teaches the request may comprise a reference to the computer code, the computer code may only be loaded into memory following a request to execute the computer code. The request may further comprise input data for the computer code, such as a parameter, a number, information, an identifier, and/or a key required to execute computer code [0016-0017]. Hotse discloses receiving a request execute a computer code, the request may comprise a reference to the code to be executed, a reference to the tenant on behalf of who the code is to be executed, and input data to execute the computer code [0049]. Hotse teaches fetching, loading and executing the computer code in an isolated intra-process execution environment [0052-0054]. Hotse teaches that a process may run intra-process execution environment, a process such as a JavaScript runtime engine execute third-party JavaScript code in isolated intra-process execution environment [0058-0064]. Thus, Hoste’s isolated environment loaded with desired code and supplied with the request-specific tenant association and input corresponds to execution context. Hotse teaches that each isolated intra-process execution environment can be protected through a private address space or by preventing code from requesting arbitrary memory [0004]. Hoste further discloses that code executing in one isolated intra-process execution environment cannot access or modify code, data, or keys of another intra-process execution environment in the same global process [0002, 0012, 0053-0054]. Thus, Hoste’s private-address-space/arbitrary-memory-access restriction teaches a second memory space associated with the execution context. Hoste further teaches that scripted code portions are directed interpreted from source code and translated into machine language at runtime [0018]. Hoste also teaches that code may include scripting portion and native portions, may be loaded into memory, and may be detected/processed when loaded or executed [0018-0021] [0050-0052] [0060]. Hoste therefore provides the basic scripting-runtime context in which code is loaded, interpreted, translated and executed in the memory.).
Hoste does not expressly disclose where the code for the execution engine resides in a first memory space of the managed execution environment and is implemented by a programming language that does not permit changes to the first memory space; and wherein, upon completion of the execution of the executable code, the execution engine discards the execution context.
However, Wimmer discloses where the code for the execution engine resides in a first memory space of the managed execution environment (e.g. Wimmer also discloses generating an image for a host application, the image includes an image heap and image compiled code. Wimmer states that image compiled code include code compiled from the host application by a compiler [0023-0026, 0043]. Wimmer also teaches that the image represents initialized sate of the host application and virtual machine, is accessed by multiple isolates, and reduces initialization overhead when isolates execute the host application. Wimmer’s image containing image compiled code constitutes a reusable engine-side first memory space. The image stores code and initialized runtime state that remain available across multiple isolates.) and is implemented by a programming language that does not permit changes to the first memory space (e.g. Wimmer teaches that each isolate has a read-only image heap map. Wimmer further teaches that the image heap includes a read-only object partition containing object that can be read but not modified by isolates [0025] [0029-0030] [0040]. Wimmer also teaches that the read-only image heap map designates the writable object partition as copy-on-write. When an object in the partition is modified, the OS generates a local copy of the page for the modifying isolate without modifying the corresponding image heap page in persistent storage [0032-0034]. Furthermore, Wimmer’s expressly teaches an image that includes image compiled code and an image heap, while JavaScript object and runtime compiled code are allocated within a private runtime heap and runtime-compiled code area of the particular isolate. Those isolate-side elements are inaccessible to other isolates [0067-0076]. Accordingly, Wimmer teaches the claimed functional distinction between protected reusable execution-engine/image code in a first memory space and isolate-specific modifications in separate context-side memory space. The shared image remains unmodified because isolate changes occurs in local copy-on-write pages or private runtime memory rather than modifying the original image.). Wimmer also discloses where creating the execution context includes creating a second memory space for execution of the code (e.g. Wimmer teaches that each isolate includes an address space, read-only heap map, runtime heap, and runtime compiled code. Wimmer states that the runtime heap includes objects private to a specific isolate and inaccessible to other isolates. Wimmer also states that runtime compiled code is private to the corresponding isolate [0029-0034]. Additionally, Wimmer teaches that a contiguous memory range is reserved for each isolate. The reserved memory range is sufficiently large to include the image heap, runtime heap, and runtime-compiled code [0044-0049]. Thus, Wimmer teaches a separate logical memory space for code execution, including isolate-private runtime heaps, private JavaScript objects, and runtime-compiled code.), such that the execution context permits changes to code contained in the second memory space (e.g. Wimmer: teaches that a compiler generates runtime compiled code A from additional JavaScript code provided by a first user. Wimmer further teaches that JavaScript objects A are allocated in runtime heap A, and that runtime heap A and runtime compiled code A are accessible to isolate A but inaccessible to other isolates [0072]. Wimmer also teaches that isolate-specific changes to writable image objects are stored in a modified page private to the relevant isolate [0073]. Thus, Wimmer teaches a second/context-side memory space holding execution-specific JavaScript objects and runtime-compiled code, with modifications confined to that isolate rather than modifying the shared-side image.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to apply Wimmer’s shared-image and isolate-private-memory architecture to Hoste’s cloud platform for multi-tenant execution of scripting code. Hoste teaches executing third-party scripting code, including JavaScript, in isolated intra-process execution environments within a shared global process. Such isolated contexts reduce startup latency, resource overhead, memory overhead, context-switching overhead, and execution cost compared with starting a distinct process for each tenant [0012-0015, 0053, 0056]. Wimmer teaches a known way to further reduce repeated virtual-machine/application initialization cost while preserving execution isolation: share an initialized image and compiled code through read-only maps, while reserving a private address space, private runtime heap, private runtime-compiled code region, and COW modification pages for each isolate [0018] [0023-0034] [0044-0054].
A POSITA would have been motivated to incorporate Wimmer’s architecture into Hoste’s global JavaScript execution process because the predicable result would be to retrain reusable compiled runtime/engine code and initialized image state while ensuring that tenant-specific JavaScript objects, runtime-generated code, and modifications remain confined to the corresponding isolated execution context. This would improve Hoste’s multi-tenant execution platform by reducing repeated initialization cost and memory duplication while providing stronger isolation against cross-tenant code/data modification.
The combination of Hoste and Wimmer does not expressly disclose wherein, upon completion of the execution of the executable code, the execution engine discards the execution context.
However, Brooker expressly discloses wherein, upon completion of the execution of the executable code, the execution engine discards the execution context (e.g. Brooker: discloses systems and methods for efficiently configuring an execution environment for an on-demand code execution to handle a single request. Once the session or request is complete, the execution environment is reset, such as by having the hardware processor state, memory, and storage reset. A subsequent code execution securely occurs in the execution environment, and the execution environment is reset again, and so forth [Abstract] [0013-0018]. Brooker further teaches that, following completion of code execution, the execution environment is reset by resetting processor registers, processor caches, page table, main memory, storage, and operating-system state [0043-0046, 0051-0052, 0067-0077]. Thus, resetting the execution environment after completion of code execution so that processor state, memory pages, storage state, page-table mappings, caches, and OS state revert to an initial state teaches discarding the prior execution context. The prior request-specific execution state/context are removed/discarded before the environment serves a subsequent request.).
Furthermore, Brooker also discloses “an internal invocation request for executing code in the managed execution environment” (e.g. Brooker teaches receiving code-execution requests through a gateway service, forwarding such requests to a provisioning service, and executing code in an execution environment [0016, 0021-0022, 0029-0032, 0060-0061, 0077]); “and the code for execution is written in a scripting language” (e.g. Brooker teaches that tasks may be written in JavaScript, Java, Python, or Ruby [0030].).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to apply Brooker’s completion-based reset mechanism to the combination of Hoste and Wimmer. Hoste teaches isolated execution of multi-tenant scripting code in shared global process and recognizes the importance of preventing one tenant’s code from accessing or modifying another tenant’s code or data. Wimmer teaches preserving reusable compiled runtime/image code while placing mutable runtime heap objects, JavaScript objects, runtime-compiled code, and COW modification in isolate-private memory. Brooker teaches that code-execution environments in on-demand systems should be reset after each request/session to eliminate persistent state. Brooker explains that this reset addresses persistent malware, side-channel attacks, corruption of reusable execution-environment state, and security risks caused by a shared environment serving multiple requests/users [0013-0018, 0043-0046, 0067-0077].
A POSITA would have been motivated to apply Brook’s reset technique to the combination of Hoste-Wimmer. The predictable result would preserve Wimmer’s reusable protected image/compiled-code memory while resetting or discarding only the request-specific context state after execution. This would prevent a prior tenant’s variables, JavaScript objects, runtime-compiled code, modified pages, or other context-specific states from affecting a later request, while retaining the performance advantages of reuse of the baseline engine/image.
As per claim 2, the combination of Hoste, Wimmer and Brooker discloses The managed execution environment of claim 1 [See rejection to claim 1 above] wherein the execution engine is configured to receive a second internal invocation request and creates another execution context in response to receiving the second internal invocation request (e.g. Hoste: teaches a cloud computing platform that executes third-party code from various tenants on shared compute infrastructure [0002]. Hoste further teaches that different tenants may register codes to be executed in response to requests, and that compute servers execute the code following such requests. Hoste specifically teaches that requests can be generated by numerous events [0012] [0044]. Wimmer: teaches first and second isolates in a single process, each isolate being a distinct runtime execution context with its own address space, runtime heap and compiled code [0018, 0027, 0029-0034]. Wimmer further teaches initializing an isolate and attaching a current thread to that isolate, thereby creating thread-specific execution context [Fig. 3, 312]. Brooker also discloses receiving a code-execution request, executing the code, resetting the execution environment after completion, and handling additional requests [0015-0017, Fig. 5, steps 504-510]. Also see [Abstract] [0076-0077].), where the execution context for the second internal invocation request differs from the execution context for the internal invocation request (e.g. Wimmer teaches separate first and second isolates, each having separate address spaces and separate maps of the shared image heap [007-009] [0018] [0027-0030]. Wimmer also teaches that each isolate include its own private runtime heap and private runtime-compiled code, both inaccessible to other isolates [0034]. Booker independently teaches reset of the execution environment after a request/session including reset of processor state, memory, and storage state before a subsequent execution [Abstract, 0015-0018, and Fig. 5]. Accordingly, even where the same lower-level environment is reused, the later request runs with different execution state. In the combined system, the second request executes either in separately initialized Wimmer isolate or in a reset context distinct from the earlier request’s state.).
As per claims 11-12, these are method claims having similar limitations cited in system claims 1-2, respectively. Thus, claims 11-12 are also rejected under the same rationale as cited in the rejection of rejected claims 1-2, respectively.
Claims 3-4, and 13-14 are rejected under AIA 35 U.S.C. 103 as being unpatentable over Hoste in view of Wimmer, and Brooker, and further in view of Keith et al. (US 2015/0229645 A1) (hereinafter Keith).
As per claim 3, the combination of Hoste, Wimmer and Brooker discloses The managed execution environment of claim 1 [See rejection to claim 1 above] further comprises an invocation manager (e.g. Hoste teaches control server and dispatcher perform invocation-management functions. The control server receives request, code, configures it, and provides code to the server. The dispatcher receives execution requests, check code characteristics, selects a queue/process, allocates code, and initializes processes as needed [0046, 0057-0065]. Also see Wimmer [0018] [0027-0034]; and Brooker [Abstract] [0015-0018].) and a plurality of platform instances (e.g. Hoste: teaches multiple servers, each capable of executing multiple processes and multiple isolated intra-process environments [0044-0045]. Wimmer: teaches multiple separate isolates in one process, each isolate being a distinct execution context with a separate address space, runtime heap, and compiled code [0018, 0027-0034]. These separately addressable/executable process, isolate, or environment instances are platform instances.), where each of the plurality of platform instances provides functionality or data for different system users (e.g. Hoste: teaches execution for different tenants and protects each tenant’s code, data, and keys from other tenants [0002, 0012-0015, 0052-0056]. Wimmer expressly states that isolates may be separated by identity, with each isolate corresponding to a different user of the host application [0027]. Thus, the different tenant-associated execution instances provide separately protected functionality/data.) and the invocation manager is configured to receive an invocation request (e.g. Hoste teaches receiving a request to execute code for a tenant [0012, 0044, 0049]. The dispatcher receives and processes code-execution requests [0057-0059]. Brooker: independently teaches receiving a code-execution request [Abstract; Fig. 5].).
The combination does not expressly disclose the invocation manager operates to resolve one of the plurality of platform instances to which the invocation requests pertains to.
However, Keith discloses the invocation manager…receives an invocation request (e.g. Keith: teaches dispatcher 118 which handles the requests and dispatches them to an appropriate service. The dispatcher parses the inbound request to extract information including tenant id, service id, application name, application version, requested resource, operation and parameters [0066]. Thus, Keith’s dispatcher is a direct counterpart to the claimed invocation manager receiving and analyzing the request.); and the invocation manager operates to resolve one of the plurality of platform instances to which the invocation requests pertains to (e.g. Keith: teaches that dispatcher uses the extracted request information to perform a lookup in metadata repository and retrieves corresponding data for the request. Keith further teaches that the dispatcher determines the target service based on the requested resource and mappings in the retrieved metadata. Keith also teaches that dispatcher resolves the destination of a request based on a location/address in a URI or URL [0066]. For internal requests, including request from composite services or custom executable instructions. Keith teaches that a caller can use a logical service name, and dispatcher uses the current execution context to determine the application and uses the logical name to determine the appropriate service [0067]. Keith teaches multiple template execution environments and multiple child execution environments. Chile execution environments are distinct secure execution environments established based on selected template environments [0005-0006, 0013, 0017, 0076-0078, 0100-0104]. Keith teaches selection of an appropriate templated execution environment based on criteria including code type, resource requirements, language type, security type, service type, and user type [0076-0078, 0100-0101]. Therefore, Keith’s target service/destination and its selected child execution environment together teach resolving and invocation to an appropriate platform/execution instance.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Keith’s metadata-driven routing into the combination because it would enable Hoste’s dispatcher to improve tenant/application-specific request routing and ensure that an invocation reaches the correct execution instance without exposing tenant code to incorrect resources. This would yield the predictable result of more precise request resolution while retaining the Hoste-Wimmer-Brooker combination’s multi-tenant isolation and clean execution-state behavior.
As per claim 4, the combination of Hoste, Wimmer and Brooker discloses The managed execution environment of claim 3 [See rejection to claim 3 above] wherein the invocation request includes identifying information for a given system user (e.g. Hoste: teaches that an execution request may include a reference to the tenant on whose behalf the code is executed [0049]. Hoste further teaches that execution request are associated with different tenants and that tenant-specific processes execute code belonging only to the associated tenant [0012-0015, 0052-0056]. Keith: expressly discloses that dispatcher parses a request and its header to extract tenant identifier [0066]. Keith also teaches that a request may include a request context and may be associated with a message source, message destination, and message payload [0047]. Therefore, both Hoste and Keith teach invocation-request information that identifies the relevant tenant/user.) and the invocation manager maps the identifying information for the given system user to an address for a platform instance associated with the given system user (e.g. Keith: teaches that dispatcher extracts identifying information, including a tenant identifier, service identifier, etc. The dispatcher uses parsed information to perform a lookup in metadata repository, retrieves corresponding metadata for the request, and determines the target based on the requested resource and mappings in that metadata. Keith further teaches that the dispatcher resolves the destination of the request based on location—i.e., an address—identified in a URI or URL, and routes the request to the determined target service [0066]. Also see [0054-0056]. Therefore, Keith teaches an invocation manger that maps a given user’s identifying information, through metadata associated with the request, to the URI/URL address of the corresponding target service or platform instance.).
As per claims 13-14, these are method claims having similar limitations cited in system claims 3-4, respectively. Thus, claims 13-14 are also rejected under the same rationale as cited in the rejection of rejected claims 3-4, respectively.
Claims 5-7, 10, 15-17 and 20 are rejected under AIA 35 U.S.C. 103 as being unpatentable over Hoste in view of Wimmer, and Brooker, and further in view of Osamu Takayasu (US 2016/0072822 A1) (hereinafter Takayasu).
As per claim 5, the combination of Hoste, Wimmer and Brooker discloses The managed execution environment of claim 1 [See rejection to claim 1 above] but does not expressly disclose wherein the internal invocation request further includes one or more access tokens, and the execution engine configures an access control module using the one or more access tokens.
However, Takayasu discloses wherein the internal invocation request further includes one or more access tokens, and the execution engine configures an access control module using the one or more access tokens (e.g. Takayasu: teaches that an access request includes an access token in its header, where the token includes client identity, permitted resource-scope information, and expiration time, and data-center identifier. The request includes resource information identifying the protected resource to be accessed and a URL identifying the resource location [0133-0134]. Takayasu further teaches that authority-judgement unit decodes the token and uses token-derived source and destination identities and resource scope as search keys for an access-propriety judgement table to determine whether resource access is permitted or refused [0135]. Also see [0145-0147]. Thus, when Takayasu’s token-bearing access-request format when used with Hoste’s internal invocation execution request, the resulting internal invocation request includes one or more access tokens.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Takayasu’s token-based authorization technique into Host’s multi-tenant execution platform, as enhanced by Wimmer and Brooker, to supplement context and memory isolation with per-invocation authorization. The predictable result is that an execution request is not only isolated from other tenant executions, but is also limited to the resource access authorized by the token associated with that particular request.
As per claim 6, the combination of Hoste, Wimmer, Brooker and Takayasu discloses The managed execution environment of claim 5 [See rejection to claim 5 above], Takayasu further discloses wherein the access control module is configured to receive a resource access request for a given resource from the code and directs the resource access request to the given resource (e.g. Takayasu: teaches a receiver that receives request addressed to a managed protection resource. The request includes an access token or refresh token in a header, resource information identifying the requested protection resource, and a URL identifying the resource location [0134]. Authority judgement unit 86 determines whether the token authorized access to the identified resource [0135]. When authorization is established, access-processing unit generates a resource receiving request and causes transmission of that request, thereby permitting access to the resource and returning the resource to the requestor [0136]. Also see [0011] [0058-0059] [0145-0147]. Thus, Takayasu discloses receiving a token-controlled resource-access request and directing the permitted request to the identified resource.).
As per claim 7, the combination of Hoste, Wimmer, Brooker and Takayasu discloses The managed execution environment of claim 6 [See rejection to claim 6 above], Takayasu further discloses wherein, upon receiving the resource access request, the access control module determines whether the resource access request includes a network address for the given resource (e.g. Takayasu: teaches that an access request received by access-token verification unit includes resource information identifying the resource and a URL identifying the location of that resource in the communication network [0134]. Authority-judgement unit identifies the destination data-center in which access to the resource is requested using the resource information in the access request [0135]. Takayasu further shows resolving a resource/domain name through DNS to an IP address and sending the access request to the resolved data center. [Fig. 25, S2502-2512]. Thus, Takayasu teaches examining the received request to determine the URL/IP-address location information for the requested resource.).
As per claim 10, the combination of Hoste, Wimmer, Brooker and Takayasu discloses The managed execution environment of claim 7 [See rejection to claim 7 above] Takayasu further discloses wherein, in response to a determination that a network address for the given resource is present in the resource access request, the access control module verifies whether the given resource is on an allow list and denies the resource access request in absence of the given resource on the allow list (e.g. Takayasu: teaches that an access request includes resource information identifying a resource and a URL identifying the resource location in the communication network. Authority judgement unit queries and access-propriety judgement table using token-derived source/destination identities, and resource-scope information [0134-0135]. The table identifies resources and indicates whether access is permitted (true) or refused (false) for the application source/destination/resource combination [0127, Fig. 22]. This table represents allow list. When the table indicates that access is refused, Takayasu determines that the token has no authority and rejects the resource access, instead urging the requester to obtain an appropriate token [0135-0137; Fig. 24, S2408-S2416].).
As per claims 15-17 and 20, these are method claims having similar limitations cited in system claims 5-7 and 10, respectively. Thus, claims 15-17 and 20 are also rejected under the same rationale as cited in the rejection of rejected claims 5-7 and 10, respectively.
Allowable Subject Matter
Claims 8-9, 18-19 and 21 are rejected/objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims, after addressing any claim objections/rejections detailed above.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Hiren Patel whose telephone number is (571) 270-3366. The examiner can normally be reached on Monday-Friday 9:30 AM to 6:00 PM.
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
If attempts to reach the above noted Examiner by telephone are unsuccessful, the Examiner’s supervisor, April Y. Blair, can be reached at the following telephone number: (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 an application may be obtained from Patent Center and the Private Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from Patent Center or Private PAIR. Status information for unpublished applications is available through Patent Center or Private PAIR to authorized users only. Should you have questions on access to Patent Center or the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
August 20, 2026
/HIREN P PATEL/Primary Examiner, Art Unit 2196
Prosecution Insights