CTNF 18/308,595 CTNF 93290 DETAILED ACTION 12-151 AIA 26-51 12-51 Status of Claims 07-03-aia AIA 15-10-aia The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. This action is in reply to the application filed on 04/23/2027. Claims 1-20 are pending and have been examined. Claim Rejections - 35 USC § 102 07-06 AIA 15-10-15 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. 07-07-aia AIA 07-07 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 – 07-08-aia AIA (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. 07-12-aia AIA (a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention. 07-15 AIA Claim s 1, 2, 5,9, 12, 14, and 15 are rejected under 35 U.S.C. 102( a)(1) and 102(a)(2 ) as being anticipated by Hale, et al. (US Patent Application Publication 20140040863), “Hale” . As per claim 1, Hale discloses: A method comprising: generating, at a first computing system, bytecode from source code of an application; fig. 1, [0012] In one embodiment, developer system 102 includes a compiler 112 configured to generate "bytecode" based on source code 142 of an application (e.g., web service 122 ) . By way of example, compiler 112 may compile source code 142 written in Java programming language into Java bytecode, and deploy the generated bytecode in a runtime environment 120 configured to parse and execute the bytecode, such as a Java Virtual Machine (JVM). executing, at the first computing system, the bytecode to an execution state; fig. 1, [0012] In one embodiment, developer system 102 includes a compiler 112 configured to generate "bytecode" based on source code 142 of an application (e.g., web service 122). By way of example, compiler 112 may compile source code 142 written in Java programming language into Java bytecode, and deploy the generated bytecode in a runtime environment 120 configured to parse and execute the bytecode, such as a Java Virtual Machine (JVM). generating, at the first computing system an application snapshot comprising: fig. 1, [0013], [0020], [0030] Developer system 102 is further configured to generating documentation 132 for web service 122 based on bytecode for web service 122. In one embodiment, the developer system 102 includes a documentation generator 114 having bytecode analyzer 116 and note analyzer 118 modules. Bytecode analyzer 116 is configured to parse bytecode for an application and retrieve metadata pertaining to web service 122. Bytecode analyzer 116 is further configured to generate an index for documentation describing web service 122 based on the metadata retrieved. Note analyzer 118 is configured to retrieve code notes 128 from a storage source (e.g., storage 126) and merge code notes 128 with the documentation index (e.g., generated by bytecode analyzer 116) to create documentation 132 describing web service 122. the bytecode; and [0020-0022], [0030] At 202, compiler 112 processes source code 142 for a web service application 122 to generate one or more files of bytecode 144. In one embodiment, the service provider may develop web service application 122 using one or more application frameworks that support development of web-based applications, such as web services…In one embodiment, source code 142 of web service 122 specifies a mapping between requests and portions of source code 142 (referred to as a "request mapping") that indicates which application code is to be executed to process a particular request… At 208, documentation generator 114 generates an index of documentation according to the retrieved metadata. Because documentation generator 114 is deriving documentation based on certain immutable information (e.g., HTTP method, URL) as specified by source code 142 itself), documentation generator 114 is able to generate a canonical listing of resources made available by web service 122 using a process that is less prone to human input errors and less susceptible to synchronization issues. The index of documentation comprises a data structure that provides a skeleton document that outlines information retrieved about web service 122. Documentation generator 114 may create a unique key for each resource (e.g., REST endpoint) identified in bytecode 144. object information indicating a plurality of application objects created during execution of the bytecode and, for individual of the application objects, object state information indicating a state of the individual application object at the execution state; [0012], [0017], [0020-0022], [0030] Client system 106 supports execution of one or more client applications 130 that are configured to communicate with web service 122 to retrieve information and/or modify a state of web service 122… Developer system 102 is further configured to generating documentation 132 for web service 122 based on bytecode for web service 122. In one embodiment, the developer system 102 includes a documentation generator 114 having bytecode analyzer 116 and note analyzer 118 modules. Bytecode analyzer 116 is configured to parse bytecode for an application and retrieve metadata pertaining to web service 122. Bytecode analyzer 116 is further configured to generate an index for documentation describing web service 122 based on the metadata retrieved. Note analyzer 118 is configured to retrieve code notes 128 from a storage source (e.g., storage 126) and merge code notes 128 with the documentation index (e.g., generated by bytecode analyzer 116) to create documentation 132 describing web service 122. …In one embodiment, source code 142 of web service 122 specifies a mapping between requests and portions of source code 142 (referred to as a "request mapping") that indicates which application code is to be executed to process a particular request receiving, at the first computing system, a request for the application from a second computing system; and fig. 1, [0018] , [0033] For example, while third-party developer 160 is writing programming code that transmits a request to web service 122, an installed plug-in may conveniently render documentation 132 alongside the programming code.. . At 214, service provider 150 distributes the generated documentation 132 to third-party developers 160 that may wish to use web service 122. In one particular implementation, documentation 132 may be a JSON file that encompasses all information from the index of documentation and code notes 128. A documentation viewer may be configured to load the JSON file (e.g., via JavaScript) and dynamically render the contents of documentation 132 as a web page viewable in a conventional web browser. In another implementation, documentation 132 may be dynamically loaded into an IDE of third-party developer 160 and be rendered inline or alongside programming code of a client application configured to contact web service 122. providing, from the first computing system, the application snapshot to the second computing system. [0010], [0018], [0033] At 214, service provider 150 distributes the generated documentation 132 to third-party developers 160 that may wish to use web service 122. In one particular implementation, documentation 132 may be a JSON file that encompasses all information from the index of documentation and code notes 128. A documentation viewer may be configured to load the JSON file (e.g., via JavaScript) and dynamically render the contents of documentation 132 as a web page viewable in a conventional web browser. In another implementation, documentation 132 may be dynamically loaded into an IDE of third-party developer 160 and be rendered inline or alongside programming code of a client application configured to contact web service 122… For example, while third-party developer 160 is writing programming code that transmits a request to web service 122, an installed plug-in may conveniently render documentation 132 alongside the programming code. As per claim 2, Hale discloses : wherein the request comprises information indicating a requested execution state of the application, the providing the application snapshot being performed in response to the first computing system determining that the execution state matches the requested execution state. [0017], [0030] Client system 106 supports execution of one or more client applications 130 that are configured to communicate with web service 122 to retrieve information and/or modify a state of web service 122. To ensure proper interoperability between client application 130 and web service 122, a user, such as a third-party developer, has to carefully configure (e.g., at runtime, or during development) client application 130 to transmit requests to web service 122 having a pre-determined format and particular parameters expected by web service 122… At 210, note analyzer 118 receives code notes 128. Code notes 128 provide application documentation having comprehensive details for web service 122. In one embodiment, each entry in code notes 128 includes a key that may be used to uniquely match with a corresponding entry in the index of documentation (e.g., generated in 208). For example, a key for an entry in code notes 128 may comprise an HTTP method and URL path for the API endpoint. The developer of web service 122 may provide a plurality of code notes 128 that describe in detail each resource made available by web service 122. As per claim 5, Hale discloses: wherein the executing the bytecode is performed in a runtime configured according to one or more runtime configuration settings, the application snapshot further comprising information indicating at least one of the one or more runtime configuration settings. [0015-0017], [0024] Server system 104 supports execution of bytecode for a web service application 122 and deployed from developer system 102. In one embodiment, server system 104 provides a runtime environment 120 configured to execute bytecode for one or more applications (e.g., web service 122) that provide, for example, web services, database services, and other information technology services that may involve retrieval, processing, and serving of data to one or more users. In the embodiments illustrated herein, runtime environment 120 is a Java Virtual Machine (JVM)… Client system 106 supports execution of one or more client applications 130 that are configured to communicate with web service 122 to retrieve information and/or modify a state of web service 122. To ensure proper interoperability between client application 130 and web service 122, a user, such as a third-party developer, has to carefully configure (e.g., at runtime, or during development) client application 130 to transmit requests to web service 122 having a pre-determined format and particular parameters expected by web service 122. Further, the user has to configure client application 130 to correctly process data returned in a response from web service 122 and arranged in pre-determined format… Referring back to FIG. 2, when compiler 112 processes source code 142 to generate bytecode 144, compiler 112 translates source code 142, which is generally human-readable, into a plurality of compact numeric codes, constants, and references that may be directly interpreted by runtime environment 120. In one embodiment, the annotations included in source code 142, which specify the request mapping of web service 122, are preserved in bytecode 144. As per claim 9, and 14, Hale discloses: A computing system comprising: [0006] one or more processor units; and [0006] one or more computer-readable storage media storing computer-executable instructions that, when executed, cause the one or more processor units to perform a method of [0006], claim 9 generating bytecode from source code of an application; fig. 1, [0012] In one embodiment, developer system 102 includes a compiler 112 configured to generate "bytecode" based on source code 142 of an application (e.g., web service 122 ) . By way of example, compiler 112 may compile source code 142 written in Java programming language into Java bytecode, and deploy the generated bytecode in a runtime environment 120 configured to parse and execute the bytecode, such as a Java Virtual Machine (JVM). executing the bytecode to an execution state; fig. 1, [0012] In one embodiment, developer system 102 includes a compiler 112 configured to generate "bytecode" based on source code 142 of an application (e.g., web service 122). By way of example, compiler 112 may compile source code 142 written in Java programming language into Java bytecode, and deploy the generated bytecode in a runtime environment 120 configured to parse and execute the bytecode, such as a Java Virtual Machine (JVM). generating an application snapshot comprising: fig. 1, [0013], [0020], [0030] Developer system 102 is further configured to generating documentation 132 for web service 122 based on bytecode for web service 122. In one embodiment, the developer system 102 includes a documentation generator 114 having bytecode analyzer 116 and note analyzer 118 modules. Bytecode analyzer 116 is configured to parse bytecode for an application and retrieve metadata pertaining to web service 122. Bytecode analyzer 116 is further configured to generate an index for documentation describing web service 122 based on the metadata retrieved. Note analyzer 118 is configured to retrieve code notes 128 from a storage source (e.g., storage 126) and merge code notes 128 with the documentation index (e.g., generated by bytecode analyzer 116) to create documentation 132 describing web service 122. the bytecode; and [0020-0022], [0030] At 202, compiler 112 processes source code 142 for a web service application 122 to generate one or more files of bytecode 144. In one embodiment, the service provider may develop web service application 122 using one or more application frameworks that support development of web-based applications, such as web services…In one embodiment, source code 142 of web service 122 specifies a mapping between requests and portions of source code 142 (referred to as a "request mapping") that indicates which application code is to be executed to process a particular request… At 208, documentation generator 114 generates an index of documentation according to the retrieved metadata. Because documentation generator 114 is deriving documentation based on certain immutable information (e.g., HTTP method, URL) as specified by source code 142 itself), documentation generator 114 is able to generate a canonical listing of resources made available by web service 122 using a process that is less prone to human input errors and less susceptible to synchronization issues. The index of documentation comprises a data structure that provides a skeleton document that outlines information retrieved about web service 122. Documentation generator 114 may create a unique key for each resource (e.g., REST endpoint) identified in bytecode 144. object information indicating a plurality of application objects created during execution of the bytecode and, for individual of the application objects, object state information indicating a state of the individual application object at the execution state; [0012], [0017], [0020-0022], [0030] Client system 106 supports execution of one or more client applications 130 that are configured to communicate with web service 122 to retrieve information and/or modify a state of web service 122… Developer system 102 is further configured to generating documentation 132 for web service 122 based on bytecode for web service 122. In one embodiment, the developer system 102 includes a documentation generator 114 having bytecode analyzer 116 and note analyzer 118 modules. Bytecode analyzer 116 is configured to parse bytecode for an application and retrieve metadata pertaining to web service 122. Bytecode analyzer 116 is further configured to generate an index for documentation describing web service 122 based on the metadata retrieved. Note analyzer 118 is configured to retrieve code notes 128 from a storage source (e.g., storage 126) and merge code notes 128 with the documentation index (e.g., generated by bytecode analyzer 116) to create documentation 132 describing web service 122. …In one embodiment, source code 142 of web service 122 specifies a mapping between requests and portions of source code 142 (referred to as a "request mapping") that indicates which application code is to be executed to process a particular request receiving a request for the application from a remote computing system; and fig. 1, [0018] , [0033] For example, while third-party developer 160 is writing programming code that transmits a request to web service 122, an installed plug-in may conveniently render documentation 132 alongside the programming code.. . At 214, service provider 150 distributes the generated documentation 132 to third-party developers 160 that may wish to use web service 122. In one particular implementation, documentation 132 may be a JSON file that encompasses all information from the index of documentation and code notes 128. A documentation viewer may be configured to load the JSON file (e.g., via JavaScript) and dynamically render the contents of documentation 132 as a web page viewable in a conventional web browser. In another implementation, documentation 132 may be dynamically loaded into an IDE of third-party developer 160 and be rendered inline or alongside programming code of a client application configured to contact web service 122. providing the application snapshot to the remote computing system. [0010], [0018], [0033] At 214, service provider 150 distributes the generated documentation 132 to third-party developers 160 that may wish to use web service 122. In one particular implementation, documentation 132 may be a JSON file that encompasses all information from the index of documentation and code notes 128. A documentation viewer may be configured to load the JSON file (e.g., via JavaScript) and dynamically render the contents of documentation 132 as a web page viewable in a conventional web browser. In another implementation, documentation 132 may be dynamically loaded into an IDE of third-party developer 160 and be rendered inline or alongside programming code of a client application configured to contact web service 122… For example, while third-party developer 160 is writing programming code that transmits a request to web service 122, an installed plug-in may conveniently render documentation 132 alongside the programming code. As per claim 12, Hale discloses: wherein the executing the bytecode is performed in a runtime configured according to one or more runtime configuration settings, the application snapshot further comprising information indicating at least one of the one or more runtime configuration settings. [0015-0017], [0024] Server system 104 supports execution of bytecode for a web service application 122 and deployed from developer system 102. In one embodiment, server system 104 provides a runtime environment 120 configured to execute bytecode for one or more applications (e.g., web service 122) that provide, for example, web services, database services, and other information technology services that may involve retrieval, processing, and serving of data to one or more users. In the embodiments illustrated herein, runtime environment 120 is a Java Virtual Machine (JVM)… Client system 106 supports execution of one or more client applications 130 that are configured to communicate with web service 122 to retrieve information and/or modify a state of web service 122. To ensure proper interoperability between client application 130 and web service 122, a user, such as a third-party developer, has to carefully configure (e.g., at runtime, or during development) client application 130 to transmit requests to web service 122 having a pre-determined format and particular parameters expected by web service 122. Further, the user has to configure client application 130 to correctly process data returned in a response from web service 122 and arranged in pre-determined format… Referring back to FIG. 2, when compiler 112 processes source code 142 to generate bytecode 144, compiler 112 translates source code 142, which is generally human-readable, into a plurality of compact numeric codes, constants, and references that may be directly interpreted by runtime environment 120. In one embodiment, the annotations included in source code 142, which specify the request mapping of web service 122, are preserved in bytecode 144. As per claim 15, Hale discloses: wherein the request comprises information indicating a requested execution state of the application, the providing the application snapshot being performed in response to the computing system determining that the execution state matches the requested execution state. [0017], [0033] Client system 106 supports execution of one or more client applications 130 that are configured to communicate with web service 122 to retrieve information and/or modify a state of web service 122. To ensure proper interoperability between client application 130 and web service 122, a user, such as a third-party developer, has to carefully configure (e.g., at runtime, or during development) client application 130 to transmit requests to web service 122 having a pre-determined format and particular parameters expected by web service 122. Further, the user has to configure client application 130 to correctly process data returned in a response from web service 122 and arranged in pre-determined format… At 214, service provider 150 distributes the generated documentation 132 to third-party developers 160 that may wish to use web service 122. In one particular implementation, documentation 132 may be a JSON file that encompasses all information from the index of documentation and code notes 128. A documentation viewer may be configured to load the JSON file (e.g., via JavaScript) and dynamically render the contents of documentation 132 as a web page viewable in a conventional web browser. In another implementation, documentation 132 may be dynamically loaded into an IDE of third-party developer 160 and be rendered inline or alongside programming code of a client application configured to contact web service 122. As per claim 14, claim 14 recites substantially similar limitations to those found in claim 9. Therefor claim 14 is rejected under the same art and rationale as claim 9. Furthermore, Hale discloses one or more non-transitory computer readable media (see claim 9, [0006]) . Claim Rejections - 35 USC § 103 07-06 AIA 15-10-15 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. 07-20-aia AIA 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. 07-23-aia AIA The factual inquiries set forth in Graham v. John Deere Co. , 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows: 1. Determining the scope and contents of the prior art. 2. Ascertaining the differences between the prior art and the claims at issue. 3. Resolving the level of ordinary skill in the pertinent art. 4. Considering objective evidence present in the application indicating obviousness or nonobviousness. 07-21-aia AIA Claim s 3, 10, 16, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Hale, et al. (US Patent Application Publication 20140040863), “Hale” . As per claim 3, Hale discloses: wherein the execution state is a first execution state, the application snapshot is a first application snapshot, the object state information is first object state information indicating states of the individual application objects at the first execution state, the method further comprising: [0012], [0017-0018], [0020-0022], [0030] executing, at the first computing system, the bytecode to a second execution state; In re Harza, [ 0010], [0012], [0017] , fig. 1, as this could be a different 3 rd party with different using a different state of the web service, Client system 106 supports execution of one or more client applications 130 that are configured to communicate with web service 122 to retrieve information and/or modify a state of web service 122. To ensure proper interoperability between client application 130 and web service 122, a user, such as a third-party developer, has to carefully configure (e.g., at runtime, or during development) client application 130 to transmit requests to web service 122 having a pre-determined format and particular parameters expected by web service 122. Further, the user has to configure client application 130 to correctly process data returned in a response from web service 122 and arranged in pre-determined format… In one embodiment, developer system 102 includes a compiler 112 configured to generate "bytecode" based on source code 142 of an application (e.g., web service 122). By way of example, compiler 112 may compile source code 142 written in Java programming language into Java bytecode, and deploy the generated bytecode in a runtime environment 120 configured to parse and execute the bytecode, such as a Java Virtual Machine (JVM). generating, at the first computing system, a second application snapshot comprising: In re Harza, fig. 1, [0013], [0020], [0030] Developer system 102 is further configured to generating documentation 132 for web service 122 based on bytecode for web service 122. In one embodiment, the developer system 102 includes a documentation generator 114 having bytecode analyzer 116 and note analyzer 118 modules. Bytecode analyzer 116 is configured to parse bytecode for an application and retrieve metadata pertaining to web service 122. Bytecode analyzer 116 is further configured to generate an index for documentation describing web service 122 based on the metadata retrieved. Note analyzer 118 is configured to retrieve code notes 128 from a storage source (e.g., storage 126) and merge code notes 128 with the documentation index (e.g., generated by bytecode analyzer 116) to create documentation 132 describing web service 122. the bytecode or information from which the bytecode can be generated; and [0020-0022], [0030] At 202, compiler 112 processes source code 142 for a web service application 122 to generate one or more files of bytecode 144. In one embodiment, the service provider may develop web service application 122 using one or more application frameworks that support development of web-based applications, such as web services…In one embodiment, source code 142 of web service 122 specifies a mapping between requests and portions of source code 142 (referred to as a "request mapping") that indicates which application code is to be executed to process a particular request… At 208, documentation generator 114 generates an index of documentation according to the retrieved metadata. Because documentation generator 114 is deriving documentation based on certain immutable information (e.g., HTTP method, URL) as specified by source code 142 itself), documentation generator 114 is able to generate a canonical listing of resources made available by web service 122 using a process that is less prone to human input errors and less susceptible to synchronization issues. The index of documentation comprises a data structure that provides a skeleton document that outlines information retrieved about web service 122. Documentation generator 114 may create a unique key for each resource (e.g., REST endpoint) identified in bytecode 144. the object information indicating the plurality of application objects and, for individual of the application objects, second object information indicating a state of the individual application object at the second execution state; and In re Harza, [0012], [0017], [0020-0022], [0030] Client system 106 supports execution of one or more client applications 130 that are configured to communicate with web service 122 to retrieve information and/or modify a state of web service 122… Developer system 102 is further configured to generating documentation 132 for web service 122 based on bytecode for web service 122. In one embodiment, the developer system 102 includes a documentation generator 114 having bytecode analyzer 116 and note analyzer 118 modules. Bytecode analyzer 116 is configured to parse bytecode for an application and retrieve metadata pertaining to web service 122. Bytecode analyzer 116 is further configured to generate an index for documentation describing web service 122 based on the metadata retrieved. Note analyzer 118 is configured to retrieve code notes 128 from a storage source (e.g., storage 126) and merge code notes 128 with the documentation index (e.g., generated by bytecode analyzer 116) to create documentation 132 describing web service 122. …In one embodiment, source code 142 of web service 122 specifies a mapping between requests and portions of source code 142 (referred to as a "request mapping") that indicates which application code is to be executed to process a particular request providing, from the first computing system, the second application snapshot to the second computing system. In re Harza, [0010], [0018], [0033] At 214, service provider 150 distributes the generated documentation 132 to third-party developers 160 that may wish to use web service 122. In one particular implementation, documentation 132 may be a JSON file that encompasses all information from the index of documentation and code notes 128. A documentation viewer may be configured to load the JSON file (e.g., via JavaScript) and dynamically render the contents of documentation 132 as a web page viewable in a conventional web browser. In another implementation, documentation 132 may be dynamically loaded into an IDE of third-party developer 160 and be rendered inline or alongside programming code of a client application configured to contact web service 122… For example, while third-party developer 160 is writing programming code that transmits a request to web service 122, an installed plug-in may conveniently render documentation 132 alongside the programming code. It would have been obvious to generate a second snapshot corresponding to a second execution state since it is only a duplication of parts and “mere duplication of parts has no patentable significance unless a new and unexpected result is produced” In re Harza , 274 F.2d 669, 124 USPQ 378 (CCPA 1960). Here, the second snapshot does nothing more than duplicate the efforts of the creating another snapshot which as disclosed by Hale could be for a different 3 rd party with different format and parameter requirements, i.e. it performs all the same functions and produces all the same results which are already being accomplished except that the snapshot is for a different configuration as disclosed by Hale. Thus, the second snapshot is generated in the same manner as the first and is not producing an unexpected result . See MPEP 2144.04 (VI)(B). As per claim 10, and 16, Hale discloses: wherein the execution state is a first execution state, the application snapshot is a first application snapshot, the object state information is first object state information indicating states of the individual application objects at the first execution state; [0012], [0017-0018], [0020-0022], [0030] the method further comprising: executing the bytecode to a second execution state; In re Harza, [ 0010], [0012], [0017] , fig. 1, as this could be a different 3 rd party with different using a different state of the web service, Client system 106 supports execution of one or more client applications 130 that are configured to communicate with web service 122 to retrieve information and/or modify a state of web service 122. To ensure proper interoperability between client application 130 and web service 122, a user, such as a third-party developer, has to carefully configure (e.g., at runtime, or during development) client application 130 to transmit requests to web service 122 having a pre-determined format and particular parameters expected by web service 122. Further, the user has to configure client application 130 to correctly process data returned in a response from web service 122 and arranged in pre-determined format… In one embodiment, developer system 102 includes a compiler 112 configured to generate "bytecode" based on source code 142 of an application (e.g., web service 122). By way of example, compiler 112 may compile source code 142 written in Java programming language into Java bytecode, and deploy the generated bytecode in a runtime environment 120 configured to parse and execute the bytecode, such as a Java Virtual Machine (JVM). generating a second application snapshot comprising: In re Harza, fig. 1, [0013], [0020], [0030] Developer system 102 is further configured to generating documentation 132 for web service 122 based on bytecode for web service 122. In one embodiment, the developer system 102 includes a documentation generator 114 having bytecode analyzer 116 and note analyzer 118 modules. Bytecode analyzer 116 is configured to parse bytecode for an application and retrieve metadata pertaining to web service 122. Bytecode analyzer 116 is further configured to generate an index for documentation describing web service 122 based on the metadata retrieved. Note analyzer 118 is configured to retrieve code notes 128 from a storage source (e.g., storage 126) and merge code notes 128 with the documentation index (e.g., generated by bytecode analyzer 116) to create documentation 132 describing web service 122. the bytecode or information from which the bytecode can be generated; and [0020-0022], [0030] At 202, compiler 112 processes source code 142 for a web service application 122 to generate one or more files of bytecode 144. In one embodiment, the service provider may develop web service application 122 using one or more application frameworks that support development of web-based applications, such as web services…In one embodiment, source code 142 of web service 122 specifies a mapping between requests and portions of source code 142 (referred to as a "request mapping") that indicates which application code is to be executed to process a particular request… At 208, documentation generator 114 generates an index of documentation according to the retrieved metadata. Because documentation generator 114 is deriving documentation based on certain immutable information (e.g., HTTP method, URL) as specified by source code 142 itself), documentation generator 114 is able to generate a canonical listing of resources made available by web service 122 using a process that is less prone to human input errors and less susceptible to synchronization issues. The index of documentation comprises a data structure that provides a skeleton document that outlines information retrieved about web service 122. Documentation generator 114 may create a unique key for each resource (e.g., REST endpoint) identified in bytecode 144. the object information indicating the plurality of application objects and, for individual of the application objects, second object information indicating a state of the individual application object at the second execution state; and In re Harza, [0012], [0017], [0020-0022], [0030] Client system 106 supports execution of one or more client applications 130 that are configured to communicate with web service 122 to retrieve information and/or modify a state of web service 122… Developer system 102 is further configured to generating documentation 132 for web service 122 based on bytecode for web service 122. In one embodiment, the developer system 102 includes a documentation generator 114 having bytecode analyzer 116 and note analyzer 118 modules. Bytecode analyzer 116 is configured to parse bytecode for an application and retrieve metadata pertaining to web service 122. Bytecode analyzer 116 is further configured to generate an index for documentation describing web service 122 based on the metadata retrieved. Note analyzer 118 is configured to retrieve code notes 128 from a storage source (e.g., storage 126) and merge code notes 128 with the documentation index (e.g., generated by bytecode analyzer 116) to create documentation 132 describing web service 122. …In one embodiment, source code 142 of web service 122 specifies a mapping between requests and portions of source code 142 (referred to as a "request mapping") that indicates which application code is to be executed to process a particular request providing the second application snapshot to the remote computing system. In re Harza, [0010], [0018], [0033] At 214, service provider 150 distributes the generated documentation 132 to third-party developers 160 that may wish to use web service 122. In one particular implementation, documentation 132 may be a JSON file that encompasses all information from the index of documentation and code notes 128. A documentation viewer may be configured to load the JSON file (e.g., via JavaScript) and dynamically render the contents of documentation 132 as a web page viewable in a conventional web browser. In another implementation, documentation 132 may be dynamically loaded into an IDE of third-party developer 160 and be rendered inline or alongside programming code of a client application configured to contact web service 122… For example, while third-party developer 160 is writing programming code that transmits a request to web service 122, an installed plug-in may conveniently render documentation 132 alongside the programming code. It would have been obvious to generate a second snapshot corresponding to a second execution state since it is only a duplication of parts and “mere duplication of parts has no patentable significance unless a new and unexpected result is produced” In re Harza , 274 F.2d 669, 124 USPQ 378 (CCPA 1960). Here, the second snapshot does nothing more than duplicate the efforts of the creating another snapshot which as disclosed by Hale could be for a different 3 rd party with different format and parameter requirements, i.e. it performs all the same functions and produces all the same results which are already being accomplished except that the snapshot is for a different configuration as disclosed by Hale. Thus, the second snapshot is generated in the same manner as the first and is not producing an unexpected result . See MPEP 2144.04 (VI)(B). As per claim 18, Hale discloses: wherein the executing the bytecode is performed in a runtime configured according to one or more runtime configuration settings, the application snapshot further comprising information indicating at least one of the one or more runtime configuration settings. [0015-0017], [0024] Server system 104 supports execution of bytecode for a web service application 122 and deployed from developer system 102. In one embodiment, server system 104 provides a runtime environment 120 configured to execute bytecode for one or more applications (e.g., web service 122) that provide, for example, web services, database services, and other information technology services that may involve retrieval, processing, and serving of data to one or more users. In the embodiments illustrated herein, runtime environment 120 is a Java Virtual Machine (JVM)… Client system 106 supports execution of one or more client applications 130 that are configured to communicate with web service 122 to retrieve information and/or modify a state of web service 122. To ensure proper interoperability between client application 130 and web service 122, a user, such as a third-party developer, has to carefully configure (e.g., at runtime, or during development) client application 130 to transmit requests to web service 122 having a pre-determined format and particular parameters expected by web service 122. Further, the user has to configure client application 130 to correctly process data returned in a response from web service 122 and arranged in pre-determined format… Referring back to FIG. 2, when compiler 112 processes source code 142 to generate bytecode 144, compiler 112 translates source code 142, which is generally human-readable, into a plurality of compact numeric codes, constants, and references that may be directly interpreted by runtime environment 120. In one embodiment, the annotations included in source code 142, which specify the request mapping of web service 122, are preserved in bytecode 144. As per claim 16, claim 16 recites substantially similar limitations to those found in claim 10. Therefor claim 16 is rejected under the same art and rationale as claim 10. Furthermore, Hale discloses one or more non-transitory computer readable media (see claim 9, [0006]) . 07-21-aia AIA Claim s 4, 6-8, 11, 13, 17, 19, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Hale, et al. (US Patent Application Publication 20140040863), “Hale” in view of Pilkington, et al. (US Patent 10,884,764), “Pilkington” . As per claim 4, Hale does not expressly disclose the following, Pilkington, however discloses: receiving, from the second computing system, information indicating the second execution state, the executing the bytecode to the second execution state and the generating the second application snapshot being performed in response to receiving the information indicating the second execution state. Col. 2 lines 5-15, col. 6 line 38- col. 7 line 3, see also col. 9 lines 50-67, The managed runtime application is executed with a profiling agent. The profiling agent records methods invoked during execution of the managed runtime application. Methods recorded as invoked by the profiling agent are stored as method invocation statistics, in response to an indication that execution of the managed runtime application is complete, for use in generating an optimized version of the managed runtime application…. As described below with reference to FIG. 3, a managed runtime application may be started, instantiated and run on a virtual machine created by a runtime in a serverless environment, with a profiling agent for profiling the application . In particular, a profiling agent is used to obtain “method invocation statistics” during execution of the application. For example, in the case of a class-based application, a modified core component of the virtual machine, e.g., a modified stack walker, may be configured to place a marker against methods in classes that are invoked during execution of the application. In other examples, a standard or custom Application Programming Interface (API) that records method invocations may be used. As the skilled person will appreciate, invoked methods of classes (or equivalent) may be recorded using other techniques. During shutdown of the virtual machine, the obtained statistics corresponding to invoked methods are stored. After a threshold number of executions of the application, the obtained method invocation statistics are sent to the serverless service for optimizing the application, as described below… As the skilled person will appreciate, the execution of a particular managed runtime application is associated with an individual consumer and may be performed in response to different “source invocations” (e.g., different types of request from the consumer) as described below… The method 400 starts at step 405 and step 410 receives invocation statistics for a managed runtime application. The managed runtime application may be the original runtime application, in which case the invocation statistics comprise method invocation statistics obtained from running the original runtime application It would have been obvious to one having ordinary skill in the art at the time the invention was filed to modify Hale with the ability optimize, execute and record run-times based on the manage runtime application received as taught by Pilkington, doing so allows classes to be selectively removed for the particular run-time which are not invoked to improve performance [col. 8 lines 44-67] As per claim 6, Hales discloses: generating, at the first computing system, a second application snapshot comprising: the bytecode or information from which the bytecode can be generated; and In re Harza, [ 0010], [0012], [0017] , fig. 1, as this could be a different 3 rd party with different using a different state of the web service, Client system 106 supports execution of one or more client applications 130 that are configured to communicate with web service 122 to retrieve information and/or modify a state of web service 122. To ensure proper interoperability between client application 130 and web service 122, a user, such as a third-party developer, has to carefully configure (e.g., at runtime, or during development) client application 130 to transmit requests to web service 122 having a pre-determined format and particular parameters expected by web service 122. Further, the user has to configure client application 130 to correctly process data returned in a response from web service 122 and arranged in pre-determined format… In one embodiment, developer system 102 includes a compiler 112 configured to generate "bytecode" based on source code 142 of an application (e.g., web service 122). By way of example, compiler 112 may compile source code 142 written in Java programming language into Java bytecode, and deploy the generated bytecode in a runtime environment 120 configured to parse and execute the bytecode, such as a Java Virtual Machine (JVM). the object information indicating the plurality of application objects and, for individual of the application objects, second object state information indicating a state of the individual application objects in response to executing the bytecode in the second runtime to the execution state; and In re Harza, [0012], [0017], [0020-0022], [0030] Client system 106 supports execution of one or more client applications 130 that are configured to communicate with web service 122 to retrieve information and/or modify a state of web service 122… Developer system 102 is further configured to generating documentation 132 for web service 122 based on bytecode for web service 122. In one embodiment, the developer system 102 includes a documentation generator 114 having bytecode analyzer 116 and note analyzer 118 modules. Bytecode analyzer 116 is configured to parse bytecode for an application and retrieve metadata pertaining to web service 122. Bytecode analyzer 116 is further configured to generate an index for documentation describing web service 122 based on the metadata retrieved. Note analyzer 118 is configured to retrieve code notes 128 from a storage source (e.g., storage 126) and merge code notes 128 with the documentation index (e.g., generated by bytecode analyzer 116) to create documentation 132 describing web service 122. …In one embodiment, source code 142 of web service 122 specifies a mapping between requests and portions of source code 142 (referred to as a "request mapping") that indicates which application code is to be executed to process a particular request providing, from the first computing system, the second application snapshot to the second computing system. In re Harza, [0010], [0018], [0033] At 214, service provider 150 distributes the generated documentation 132 to third-party developers 160 that may wish to use web service 122. In one particular implementation, documentation 132 may be a JSON file that encompasses all information from the index of documentation and code notes 128. A documentation viewer may be configured to load the JSON file (e.g., via JavaScript) and dynamically render the contents of documentation 132 as a web page viewable in a conventional web browser. In another implementation, documentation 132 may be dynamically loaded into an IDE of third-party developer 160 and be rendered inline or alongside programming code of a client application configured to contact web service 122… For example, while third-party developer 160 is writing programming code that transmits a request to web service 122, an installed plug-in may conveniently render documentation 132 alongside the programming code. Hale does not expressly disclose the following ,Pilkington, however discloses: wherein the runtime is a first runtime, the one or more runtime configuration settings are one or more first runtime configuration settings, the application snapshot is a first application snapshot comprising first object state information indicating states of the application objects in response to executing the bytecode in the first runtime to the execution state, the method further comprising: col. 1 lines 35-40, see also col. 12 lines 40-47 The managed runtime application comprises code defining a plurality of classes, each class including corresponding bytecode for one or more methods associated with the class. The method invocation statistics identify the methods invoked during at least one previous execution of the managed runtime application… At step 520 , the method retrieves the optimized application corresponding to the identified managed runtime application. Optionally, in the case that multiple optimized versions of the managed runtime application are available to the consumer for different source invocations, step 520 retrieves the optimized application based on source invocation parameters associated with the request. executing, at the first computing system, the bytecode in a second runtime configured according to one or more second runtime configuration settings; col. 12 lines 40-67, At step 530, the method starts up a virtual machine in the serverless environment. Accordingly, step 530 loads only the classes and bytecode present in the optimized application during the startup and instantiation process, thereby reducing the startup time. At step 540, the method runs the optimized application using the virtual machine in the serverless environment. In the example implementation of FIG. 5, method 500 includes a feedback mechanism, which operates during execution of the optimized application in step 540. In particular, the feedback mechanism obtains invocation statistics comprising “proxy code invocation statistics” relating to invocations of proxy code during execution of the optimized application, for use in updating the optimized application. In addition, or alternatively, the feedback mechanism obtains “removed class invocation statistics” relating to invocations of removed classes (as described herein) during execution of the optimized application, for use in updating the optimized application. In some example implementations, the feedback mechanism is implemented as a profiling agent for profiling the optimized application during execution thereof. For example, a profiling agent, such as a modified stack walker or suitable API, may be used for obtaining invocation statistics that may include proxy code and/or removed class invocation statistics, as well as method invocation statistics as described above with reference to the method 300 of FIG. 3. In other example implementations, the feedback mechanism is implemented in the proxy code of the optimized application. For example, the proxy code itself may be configured to record access to a data storage to retrieve the corresponding bytecode (i.e., invocation of the proxy code), such that each proxy code logs its invocation in a log or record of proxy code invocation statistics It would have been obvious to one having ordinary skill in the art at the time the invention was filed to modify Hale with the ability optimize, execute and record run-times based on the manage runtime application received as taught by Pilkington, doing so allows classes to be selectively removed for the particular run-time which are not invoked to improve performance [col. 8 lines 44-67] As per claim 7, Hale discloses: wherein the request comprises information indicating one or more requested runtime configuration settings, the providing the first application snapshot being performed in response to the first computing system determining that the one or more requested runtime configuration settings match the first runtime configuration settings. [0017], [0033] Client system 106 supports execution of one or more client applications 130 that are configured to communicate with web service 122 to retrieve information and/or modify a state of web service 122. To ensure proper interoperability between client application 130 and web service 122, a user, such as a third-party developer, has to carefully configure (e.g., at runtime, or during development) client application 130 to transmit requests to web service 122 having a pre-determined format and particular parameters expected by web service 122. Further, the user has to configure client application 130 to correctly process data returned in a response from web service 122 and arranged in pre-determined format… At 214, service provider 150 distributes the generated documentation 132 to third-party developers 160 that may wish to use web service 122. In one particular implementation, documentation 132 may be a JSON file that encompasses all information from the index of documentation and code notes 128. A documentation viewer may be configured to load the JSON file (e.g., via JavaScript) and dynamically render the contents of documentation 132 as a web page viewable in a conventional web browser. In another implementation, documentation 132 may be dynamically loaded into an IDE of third-party developer 160 and be rendered inline or alongside programming code of a client application configured to contact web service 122. As per claim 8, Hale does not expressly disclose the following, Pilkington, however discloses: receiving, from the second computing system, information indicating the one or more second runtime configuration settings, the executing the bytecode in the second runtime and the generating the second application snapshot being performed in response to receiving the information indicating the one or more second runtime configuration settings. Col. 2 lines 5-30, col. 6 line 38- col. 7 line 3, see also col. 9 lines 50-67, The managed runtime application is executed with a profiling agent. The profiling agent records methods invoked during execution of the managed runtime application. Methods recorded as invoked by the profiling agent are stored as method invocation statistics, in response to an indication that execution of the managed runtime application is complete, for use in generating an optimized version of the managed runtime application…. As described below with reference to FIG. 3, a managed runtime application may be started, instantiated and run on a virtual machine created by a runtime in a serverless environment, with a profiling agent for profiling the application . In particular, a profiling agent is used to obtain “method invocation statistics” during execution of the application. For example, in the case of a class-based application, a modified core component of the virtual machine, e.g., a modified stack walker, may be configured to place a marker against methods in classes that are invoked during execution of the application. In other examples, a standard or custom Application Programming Interface (API) that records method invocations may be used. As the skilled person will appreciate, invoked methods of classes (or equivalent) may be recorded using other techniques. During shutdown of the virtual machine, the obtained statistics corresponding to invoked methods are stored. After a threshold number of executions of the application, the obtained method invocation statistics are sent to the serverless service for optimizing the application, as described below… As the skilled person will appreciate, the execution of a particular managed runtime application is associated with an individual consumer and may be performed in response to different “source invocations” (e.g., different types of request from the consumer) as described below… The method 400 starts at step 405 and step 410 receives invocation statistics for a managed runtime application. The managed runtime application may be the original runtime application, in which case the invocation statistics comprise method invocation statistics obtained from running the original runtime application… T he feedback mechanism optionally records methods invoked during execution of the optimized application. The feedback mechanism stores the recorded invocations, in response to an indication that execution of the optimized application is complete, for use in generating an updated optimized application. It would have been obvious to one having ordinary skill in the art at the time the invention was filed to modify Hale with the ability optimize, execute and record run-times based on the manage runtime application and settings received as taught by Pilkington, doing so allows classes to be selectively removed for the particular run-time which are not invoked to improve performance [col. 8 lines 44-67] As per claims 11, and 17, Hale does not expressly disclose the following, Pilkington, however discloses: receiving, from the remote computing system, information indicating the second execution state, the executing the bytecode to the second execution state and the generating the second application snapshot being performed in response to receiving the information indicating the second execution state. Col. 2 lines 5-15, col. 6 line 38- col. 7 line 3, see also col. 9 lines 50-67, The managed runtime application is executed with a profiling agent. The profiling agent records methods invoked during execution of the managed runtime application. Methods recorded as invoked by the profiling agent are stored as method invocation statistics, in response to an indication that execution of the managed runtime application is complete, for use in generating an optimized version of the managed runtime application…. As described below with reference to FIG. 3, a managed runtime application may be started, instantiated and run on a virtual machine created by a runtime in a serverless environment, with a profiling agent for profiling the application . In particular, a profiling agent is used to obtain “method invocation statistics” during execution of the application. For example, in the case of a class-based application, a modified core component of the virtual machine, e.g., a modified stack walker, may be configured to place a marker against methods in classes that are invoked during execution of the application. In other examples, a standard or custom Application Programming Interface (API) that records method invocations may be used. As the skilled person will appreciate, invoked methods of classes (or equivalent) may be recorded using other techniques. During shutdown of the virtual machine, the obtained statistics corresponding to invoked methods are stored. After a threshold number of executions of the application, the obtained method invocation statistics are sent to the serverless service for optimizing the application, as described below… As the skilled person will appreciate, the execution of a particular managed runtime application is associated with an individual consumer and may be performed in response to different “source invocations” (e.g., different types of request from the consumer) as described below… The method 400 starts at step 405 and step 410 receives invocation statistics for a managed runtime application. The managed runtime application may be the original runtime application, in which case the invocation statistics comprise method invocation statistics obtained from running the original runtime application It would have been obvious to one having ordinary skill in the art at the time the invention was filed to modify Hale with the ability optimize, execute and record run-times based on the manage runtime application received as taught by Pilkington, doing so allows classes to be selectively removed for the particular run-time which are not invoked to improve performance [col. 8 lines 44-67] As per claims 13, and 19, Hale discloses: generating a second application snapshot comprising: the bytecode or information from which the bytecode can be generated; and In re Harza, [ 0010], [0012], [0017] , fig. 1, as this could be a different 3 rd party with different using a different state of the web service, Client system 106 supports execution of one or more client applications 130 that are configured to communicate with web service 122 to retrieve information and/or modify a state of web service 122. To ensure proper interoperability between client application 130 and web service 122, a user, such as a third-party developer, has to carefully configure (e.g., at runtime, or during development) client application 130 to transmit requests to web service 122 having a pre-determined format and particular parameters expected by web service 122. Further, the user has to configure client application 130 to correctly process data returned in a response from web service 122 and arranged in pre-determined format… In one embodiment, developer system 102 includes a compiler 112 configured to generate "bytecode" based on source code 142 of an application (e.g., web service 122). By way of example, compiler 112 may compile source code 142 written in Java programming language into Java bytecode, and deploy the generated bytecode in a runtime environment 120 configured to parse and execute the bytecode, such as a Java Virtual Machine (JVM) the object information indicating the plurality of application objects and, for individual of the application objects, second object state information indicating a state of the individual application objects in response to executing the bytecode in the second runtime to the execution state; and In re Harza, [0012], [0017], [0020-0022], [0030] Client system 106 supports execution of one or more client applications 130 that are configured to communicate with web service 122 to retrieve information and/or modify a state of web service 122… Developer system 102 is further configured to generating documentation 132 for web service 122 based on bytecode for web service 122. In one embodiment, the developer system 102 includes a documentation generator 114 having bytecode analyzer 116 and note analyzer 118 modules. Bytecode analyzer 116 is configured to parse bytecode for an application and retrieve metadata pertaining to web service 122. Bytecode analyzer 116 is further configured to generate an index for documentation describing web service 122 based on the metadata retrieved. Note analyzer 118 is configured to retrieve code notes 128 from a storage source (e.g., storage 126) and merge code notes 128 with the documentation index (e.g., generated by bytecode analyzer 116) to create documentation 132 describing web service 122. …In one embodiment, source code 142 of web service 122 specifies a mapping between requests and portions of source code 142 (referred to as a "request mapping") that indicates which application code is to be executed to process a particular request providing, from the computing system, the second application snapshot to the remote computing system. In re Harza, [0010], [0018], [0033] At 214, service provider 150 distributes the generated documentation 132 to third-party developers 160 that may wish to use web service 122. In one particular implementation, documentation 132 may be a JSON file that encompasses all information from the index of documentation and code notes 128. A documentation viewer may be configured to load the JSON file (e.g., via JavaScript) and dynamically render the contents of documentation 132 as a web page viewable in a conventional web browser. In another implementation, documentation 132 may be dynamically loaded into an IDE of third-party developer 160 and be rendered inline or alongside programming code of a client application configured to contact web service 122… For example, while third-party developer 160 is writing programming code that transmits a request to web service 122, an installed plug-in may conveniently render documentation 132 alongside the programming code. Hale does not expressly disclose the following ,Pilkington, however discloses: wherein the runtime is a first runtime, the one or more runtime configuration settings are one or more first runtime configuration settings, the application snapshot is a first application snapshot comprising first object state information indicating states of the application objects in response to executing the bytecode in the first runtime to the execution state, the method further comprising: col. 1 lines 35-40, see also col. 12 lines 40-47 The managed runtime application comprises code defining a plurality of classes, each class including corresponding bytecode for one or more methods associated with the class. The method invocation statistics identify the methods invoked during at least one previous execution of the managed runtime application… At step 520 , the method retrieves the optimized application corresponding to the identified managed runtime application. Optionally, in the case that multiple optimized versions of the managed runtime application are available to the consumer for different source invocations, step 520 retrieves the optimized application based on source invocation parameters associated with the request. executing the bytecode in a second runtime configured according to one or more second runtime configuration settings; col. 12 lines 40-67, At step 530, the method starts up a virtual machine in the serverless environment. Accordingly, step 530 loads only the classes and bytecode present in the optimized application during the startup and instantiation process, thereby reducing the startup time. At step 540, the method runs the optimized application using the virtual machine in the serverless environment. In the example implementation of FIG. 5, method 500 includes a feedback mechanism, which operates during execution of the optimized application in step 540. In particular, the feedback mechanism obtains invocation statistics comprising “proxy code invocation statistics” relating to invocations of proxy code during execution of the optimized application, for use in updating the optimized application. In addition, or alternatively, the feedback mechanism obtains “removed class invocation statistics” relating to invocations of removed classes (as described herein) during execution of the optimized application, for use in updating the optimized application. In some example implementations, the feedback mechanism is implemented as a profiling agent for profiling the optimized application during execution thereof. For example, a profiling agent, such as a modified stack walker or suitable API, may be used for obtaining invocation statistics that may include proxy code and/or removed class invocation statistics, as well as method invocation statistics as described above with reference to the method 300 of FIG. 3. In other example implementations, the feedback mechanism is implemented in the proxy code of the optimized application. For example, the proxy code itself may be configured to record access to a data storage to retrieve the corresponding bytecode (i.e., invocation of the proxy code), such that each proxy code logs its invocation in a log or record of proxy code invocation statistics It would have been obvious to one having ordinary skill in the art at the time the invention was filed to modify Hale with the ability optimize, execute and record run-times based on the manage runtime application received as taught by Pilkington, doing so allows classes to be selectively removed for the particular run-time which are not invoked to improve performance [col. 8 lines 44-67]. As per claim 20, Hale does not expressly disclose the following, Pilkington, however discloses: receiving, from the remote computing system, information indicating the one or more second runtime configuration settings, the executing the bytecode in the second runtime and the generating the second application snapshot being performed in response to receiving the information indicating the one or more second runtime configuration settings. Col. 2 lines 5-30, col. 6 line 38- col. 7 line 3, see also col. 9 lines 50-67, The managed runtime application is executed with a profiling agent. The profiling agent records methods invoked during execution of the managed runtime application. Methods recorded as invoked by the profiling agent are stored as method invocation statistics, in response to an indication that execution of the managed runtime application is complete, for use in generating an optimized version of the managed runtime application…. As described below with reference to FIG. 3, a managed runtime application may be started, instantiated and run on a virtual machine created by a runtime in a serverless environment, with a profiling agent for profiling the application . In particular, a profiling agent is used to obtain “method invocation statistics” during execution of the application. For example, in the case of a class-based application, a modified core component of the virtual machine, e.g., a modified stack walker, may be configured to place a marker against methods in classes that are invoked during execution of the application. In other examples, a standard or custom Application Programming Interface (API) that records method invocations may be used. As the skilled person will appreciate, invoked methods of classes (or equivalent) may be recorded using other techniques. During shutdown of the virtual machine, the obtained statistics corresponding to invoked methods are stored. After a threshold number of executions of the application, the obtained method invocation statistics are sent to the serverless service for optimizing the application, as described below… As the skilled person will appreciate, the execution of a particular managed runtime application is associated with an individual consumer and may be performed in response to different “source invocations” (e.g., different types of request from the consumer) as described below… The method 400 starts at step 405 and step 410 receives invocation statistics for a managed runtime application. The managed runtime application may be the original runtime application, in which case the invocation statistics comprise method invocation statistics obtained from running the original runtime application… T he feedback mechanism optionally records methods invoked during execution of the optimized application. The feedback mechanism stores the recorded invocations, in response to an indication that execution of the optimized application is complete, for use in generating an updated optimized application. It would have been obvious to one having ordinary skill in the art at the time the invention was filed to modify Hale with the ability optimize, execute and record run-times based on the manage runtime application and settings received as taught by Pilkington, doing so allows classes to be selectively removed for the particular run-time which are not invoked to improve performance [col. 8 lines 44-67]. As per claims 17 and 19, claims 17 and 19 recite substantially similar limitations to those found in claims 11 and 13, respectively. Therefor claims 17 and 19 are rejected under the same art and rationale as claims 11 and13. Furthermore, Hale discloses one or more non-transitory computer readable media (see claim 9, [0006]) . Conclusion 07-96 AIA The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. US Patent application Publication 20200151279 to Haberstroh discloses “A web application system may access a web application document that comprises object data, user interface data, and rule data. The web application system may serve the first user interface page to a first instance of a web application executing at a first user computing device, the first user interface page including first data object attributes of the first data object. The web application system may receive, through the first user interface page, a change to the first data object. The web application system may determine that the rule data describes a first action to be executed in response to the change to the first data object and execute the first action.” US Patent Application Publication 20140223419 to Sakai, et al. discloses “According to one embodiment, a compiler applicable to a parallel computer including processors, wherein a source program is input to the compiler and a local code for each of the processors are generated, the compiler includes a generation module and an object code generation module. The generation module is configured to analyze the input source program, extract a data transfer point from a procedure described in the source program, and generate a call processing for data copy. The object code generation module is configured to generate an object code including the call processing.” Any inquiry concerning this communication or earlier communications from the examiner should be directed to GREGORY S CUNNINGHAM II whose telephone number is (313)446-6564. The examiner can normally be reached Mon-Fri 8:30am-4pm. 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, Bennett Sigmond can be reached at 303-297-4411. 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. GREGORY S. CUNNINGHAM II Primary Examiner Art Unit 3694 /GREGORY S CUNNINGHAM II/Primary Examiner, Art Unit 3694 Application/Control Number: 18/308,595 Page 2 Art Unit: 3694 Application/Control Number: 18/308,595 Page 3 Art Unit: 3694 Application/Control Number: 18/308,595 Page 4 Art Unit: 3694 Application/Control Number: 18/308,595 Page 5 Art Unit: 3694 Application/Control Number: 18/308,595 Page 6 Art Unit: 3694 Application/Control Number: 18/308,595 Page 7 Art Unit: 3694 Application/Control Number: 18/308,595 Page 8 Art Unit: 3694 Application/Control Number: 18/308,595 Page 9 Art Unit: 3694 Application/Control Number: 18/308,595 Page 10 Art Unit: 3694 Application/Control Number: 18/308,595 Page 11 Art Unit: 3694 Application/Control Number: 18/308,595 Page 12 Art Unit: 3694 Application/Control Number: 18/308,595 Page 13 Art Unit: 3694 Application/Control Number: 18/308,595 Page 14 Art Unit: 3694 Application/Control Number: 18/308,595 Page 15 Art Unit: 3694 Application/Control Number: 18/308,595 Page 16 Art Unit: 3694 Application/Control Number: 18/308,595 Page 17 Art Unit: 3694 Application/Control Number: 18/308,595 Page 18 Art Unit: 3694 Application/Control Number: 18/308,595 Page 19 Art Unit: 3694 Application/Control Number: 18/308,595 Page 20 Art Unit: 3694 Application/Control Number: 18/308,595 Page 23 Art Unit: 3694 Application/Control Number: 18/308,595 Page 24 Art Unit: 3694 Application/Control Number: 18/308,595 Page 25 Art Unit: 3694 Application/Control Number: 18/308,595 Page 26 Art Unit: 3694 Application/Control Number: 18/308,595 Page 27 Art Unit: 3694 Application/Control Number: 18/308,595 Page 28 Art Unit: 3694 Application/Control Number: 18/308,595 Page 29 Art Unit: 3694 Application/Control Number: 18/308,595 Page 30 Art Unit: 3694 Application/Control Number: 18/308,595 Page 31 Art Unit: 3694 Application/Control Number: 18/308,595 Page 32 Art Unit: 3694 Application/Control Number: 18/308,595 Page 33 Art Unit: 3694 Application/Control Number: 18/308,595 Page 34 Art Unit: 3694 Application/Control Number: 18/308,595 Page 35 Art Unit: 3694 Application/Control Number: 18/308,595 Page 36 Art Unit: 3694 Application/Control Number: 18/308,595 Page 37 Art Unit: 3694
Prosecution Insights