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 .
Specification
The disclosure is objected to because of the following informalities:
In paragraph [0011], line 16, “developed and complied” should read as “developed and compiled”;
In paragraph [0011], line 17, “in platform” should read “on a platform” and “such as widely-used JVM” should read as “such as the widely used JVM” or “such as a widely used JVM”.
Appropriate correction is required.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 3, 4, 7, 8, 10, 11, 14, 15, 17, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Shah et al. Pub. No. US 2016/0188350 A1 (hereafter Shah) in view of WESTRELIN et al. Pub. No. US 2016/0062878 A1 (hereafter Westrelin).
With regard to claim 1, Shah teaches a method, comprising: running, by a processing device, a virtual machine (In various examples, a “processor” may include any combination of logic elements, including by way of non-limiting example a microprocessor, digital signal processor, field-programmable gate array, graphics processing unit, programmable logic array, application-specific integrated circuit, or virtual machine processor in at least paragraph [0053]; In yet other examples, BTE may be any of a runtime engine, an interpreter, a just-in-time compiler, ahead-of-time compiler, a virtual machine (such as the Java Virtual Machine (JVM)), a compiler, a linker, and a toolchain utility by way of non-limiting example in at least paragraph [0092]) loading, in the virtual machine, a first bytecode module comprising a first bytecode of a first bytecode type (The device may receive a trusted binary object in a first form in at least the Abstract) wherein the first bytecode type is not supported by the virtual machine (There is disclosed in an example 2, the computing apparatus of example 1, wherein the first format is a non-native binary format in at least paragraph [0161]) generating a second bytecode module by translating the first bytecode to a second bytecode of a second bytecode type, wherein the second bytecode type is supported by the virtual machine (It may be necessary to translate trusted binary object 420 from a first format into a second format. For example, trusted binary object 420 may be Java byte code, which needs to be compiled into a native binary format by an ahead of time compiler. In another example, trusted binary object 420 may be a Java byte code program that will be compiled by a just-in-time compiler. In yet other examples, BTE may be any of a runtime engine, an interpreter, a just-in-time compiler, ahead-of-time compiler, a virtual machine (such as the Java Virtual Machine (JVM)), a compiler, a linker, and a toolchain utility by way of non-limiting example in at least paragraph [0092], Examiner notes that the binary translation is also outlined in FIG. 8) executing the second bytecode module by the virtual machine (The second binary is then suitable for execution within the TEE on the host system in at least paragraph [0022]; The TEE verifies the integrity of the derived code by verifying the signature before executing it in at least paragraph [0075]; Thus, signed native binary 430 may be used within enclave 230, or may be provided to some other computing device with a TEE capability in at least paragraph [0094]; IVE 460 may then analyze trusted binary object 420 and tag appropriate portions for execution within enclave 230, as is described in more detail in FIG. 6. IVE 460 may then provide validated input packets to BTE 224. BTE 224 may then perform its binary translation function, including designating tagged portions for execution within enclave 230 in at least paragraph [0096]);
In one embodiment of Shah, the programmer may use common Java attributes to inform the TEE of how to verify the inputs. Thus, the programmer may have the flexibility to configure the input verification without needing to write input verification routines himself. In another example that Shah provides, an IVE may allow Android ISVs, for example, to designate a part of their application code to access sensitive data coming from a protected input (such as a touch screen), and to validate the input without compromising the data. So, while Shah teaches validation techniques in the form of an IVE (input verification engine) which performs various verification and validation check, it does not explicitly teach any verification policies based on the status of the virtual machine.
However, in analogous art Westrelin teaches validating the first bytecode module according to a first validation policy based on a status of the virtual machine (The exact checks performed during verification are dependent on the implementation of the virtual machine 104. In some cases, verification may cause additional classes to be loaded, but does not necessarily require those classes to also be linked before proceeding. For example, assume Class A contains a reference to a static field of Class B. During verification, the virtual machine 104 may check Class B to ensure that the referenced static field actually exists, which might cause loading of Class B, but not necessarily the linking or initializing of Class B in at least paragraph [0087]).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine the validation policy taught by Westrelin with the code translation apparatus taught by Shah resulting in a translation method that performs verification on the input based on a status of a virtual machine. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of ensuring a dynamic form of validation of the input based on a status of the virtual machine especially within the input verification engine of Shah as it helps to ”check that the virtual machine 104 code of methods will not cause unexpected behavior (e.g. making sure a jump instruction does not send the virtual machine 104 beyond the end of the method)”(See Westrelin paragraph [0087]) .
With regard to claim 3, Shah and Westrelin teach the method of claim 1, Shah teaches validating the first bytecode module according to a specification (In certain embodiments, code validation performs an integrity check on code loaded into a TEE. Manifest 470 may be a whitelist describing acceptable code or a blacklist describing unacceptable code. The Manifest may be signed by a trusted domain (such as an enterprise IT department, or original equipment manufacturer) using a key that was provisioned by the domain. The Manifest and Code Validation operations may be applied when the TEE initializes, at boot time, at TEE software/firmware update time or when a new code object is added to or removed from a TEE. In some example, “Trusted Boot” and “Secure Boot” are industry terms that refer to at least some of the above initialization steps in at least paragraphs [0088] and [0089], Examiner notes that Manifest acts as a specification in this context.).
With regard to claim 4, while Shah and Westrelin teach the method of claim 1, Shah does not specifically teach monitoring the status of the virtual machine.
However, in analogous art Westrelin teaches monitoring the status of the virtual machine; and generating the first validation policy (check that the virtual machine 104 code of methods will not cause unexpected behavior (e.g. making sure a jump instruction does not send the virtual machine 104 beyond the end of the method), and so forth. The exact checks performed during verification are dependent on the implementation of the virtual machine 104. In some cases, verification may cause additional classes to be loaded, but does not necessarily require those classes to also be linked before proceeding. For example, assume Class A contains a reference to a static field of Class B in at least paragraph [0087], Examiner notes that “checking that the virtual machine code of methods will not cause unexpected behavior” corresponds to monitoring the virtual machine and “the exact checks performed during verification are dependent on the implementation of the virtual machine” corresponds to generating the first validation policy).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine the validation policy by monitoring the status of the virtual machine taught by Westrelin [0087] with the code translation apparatus taught by Shah ([0092] and FIG. 8) resulting in a translation method that performs verification on the input based on monitoring of a status of a virtual machine. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of ensuring “that the virtual machine 104 code of methods will not cause unexpected behavior (e.g. making sure a jump instruction does not send the virtual machine 104 beyond the end of the method)” (See Westrelin [0087])
With regard to claim 7, Shah and Westrelin teach the method of claim 1, while Shah teaches executing the second bytecode module in at least paragraph [0022], they do not teach that executing the second bytecode module further comprises: loading a class file required by the second bytecode module in a memory of the virtual machine.
However, in analogous art Westrelin teaches executing the second bytecode module further comprises: loading a class file required by the second bytecode module in a memory of the virtual machine (During resolution, the virtual machine 104 dynamically determines concrete memory address from the symbolic references included in the run-time constant pool 304 of the class. To resolve the symbolic references, the virtual machine 104 utilizes the class loader 107 to load the class identified in the symbolic reference (if not already loaded). Once loaded, the virtual machine 104 has knowledge of the memory location within the per-class area 303 of the referenced class and its fields/methods. The virtual machine 104 then replaces the symbolic references with a reference to the concrete memory location of the referenced class, field, or method. In an embodiment, the virtual machine 104 caches resolutions to be reused in case the same class/name/descriptor is encountered when the virtual machine 104 processes another class. For example, in some cases, class A and class B may invoke the same method of class C. Thus, when resolution is performed for class A, that result can be cached and reused during resolution of the same symbolic reference in class B to reduce overhead in at least paragraph [0089])
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine the loading of class files into memory to execute a bytecode module taught by Westrelin with the execution method of the second bytecode module taught by Shah resulting in loading a class file required by the second bytecode module in a memory of the virtual machine to execute the second bytecode. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of facilitating the execution process of the second bytecode module by loading a class file required by the second bytecode in a memory of the virtual machine so that “the virtual machine 104 has knowledge of the memory location within the per-class area 303 of the referenced class and its fields/methods”(See Westrelin paragraph [0089], which will in turn make it possible to for the symbolic references to undergo resolution.
With regard to claim 8, Shah teaches A system comprising: a memory device; a processing device, operatively coupled to the memory device, to perform operations (Client device 110 includes a processor 210 connected to a memory 220, having stored therein executable instructions for providing an operating system 222 and at least software portions of a BTE 224 and IVE 460 in at least paragraph [0050]) loading, in the virtual machine, a first bytecode module comprising a first bytecode of a first bytecode type (The device may receive a trusted binary object in a first form in at least the Abstract) wherein the first bytecode type is not supported by the virtual machine (There is disclosed in an example 2, the computing apparatus of example 1, wherein the first format is a non-native binary format in at least paragraph [0161]) generating a second bytecode module by translating the first bytecode to a second bytecode of a second bytecode type, wherein the second bytecode type is supported by the virtual machine (It may be necessary to translate trusted binary object 420 from a first format into a second format. For example, trusted binary object 420 may be Java byte code, which needs to be compiled into a native binary format by an ahead of time compiler. In another example, trusted binary object 420 may be a Java byte code program that will be compiled by a just-in-time compiler. In yet other examples, BTE may be any of a runtime engine, an interpreter, a just-in-time compiler, ahead-of-time compiler, a virtual machine (such as the Java Virtual Machine (JVM)), a compiler, a linker, and a toolchain utility by way of non-limiting example in at least paragraph [0092], Examiner notes that the binary translation is also outlined in FIG. 8) executing the second bytecode module by the virtual machine (The second binary is then suitable for execution within the TEE on the host system in at least paragraph [0022]);
In one embodiment of Shah, the programmer may use common Java attributes to inform the TEE of how to verify the inputs. Thus, the programmer may have the flexibility to configure the input verification without needing to write input verification routines himself. In another example that Shah provides, an IVE may allow Android ISVs, for example, to designate a part of their application code to access sensitive data coming from a protected input (such as a touch screen), and to validate the input without compromising the data. So, while Shah teaches validation techniques in the form of an IVE (input verification engine) which performs various verification and validation check, it does not explicitly teach any verification policies based on the status of the virtual machine.
However, in analogous art Westrelin teaches validating the first bytecode module according to a first validation policy based on a status of the virtual machine (The exact checks performed during verification are dependent on the implementation of the virtual machine 104 in at least paragraph [0087]).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine the validation policy taught by Westrelin with the code translation apparatus taught by Shah resulting in a translation method that performs verification on the input based on a status of a virtual machine. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of ensuring a dynamic form of validation of the input based on a status of the virtual machine especially within the input verification engine of Shah as it helps to ”check that the virtual machine 104 code of methods will not cause unexpected behavior (e.g. making sure a jump instruction does not send the virtual machine 104 beyond the end of the method)”(See Westrelin paragraph [0087]) .
With regard to claim 10, Shah and Westrelin teach the system of claim 8, Shah teaches validating the first bytecode module according to a specification (In certain embodiments, code validation performs an integrity check on code loaded into a TEE. Manifest 470 may be a whitelist describing acceptable code or a blacklist describing unacceptable code. The Manifest may be signed by a trusted domain (such as an enterprise IT department, or original equipment manufacturer) using a key that was provisioned by the domain. The Manifest and Code Validation operations may be applied when the TEE initializes, at boot time, at TEE software/firmware update time or when a new code object is added to or removed from a TEE. In some example, “Trusted Boot” and “Secure Boot” are industry terms that refer to at least some of the above initialization steps in at least paragraphs [0088] and [0089], Examiner notes that Manifest acts as a specification in this context.).
With regard to claim 11, while Shah and Westrelin teach the system of claim 8, Shah does not specifically teach monitoring the status of the virtual machine.
However, in analogous art Westrelin teaches monitoring the status of the virtual machine; and generating the first validation policy (check that the virtual machine 104 code of methods will not cause unexpected behavior (e.g. making sure a jump instruction does not send the virtual machine 104 beyond the end of the method), and so forth. The exact checks performed during verification are dependent on the implementation of the virtual machine 104. In some cases, verification may cause additional classes to be loaded, but does not necessarily require those classes to also be linked before proceeding. For example, assume Class A contains a reference to a static field of Class B in at least paragraph [0087], Examiner notes that “checking that the virtual machine code of methods will not cause unexpected behavior” corresponds to monitoring the virtual machine and “the exact checks performed during verification are dependent on the implementation of the virtual machine” corresponds to generating the first validation policy).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine the validation policy by monitoring the status of the virtual machine taught by Westrelin [0087] with the code translation apparatus taught by Shah ([0092] and FIG. 8) resulting in a translation method that performs verification on the input based on monitoring of a status of a virtual machine. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of ensuring “that the virtual machine 104 code of methods will not cause unexpected behavior (e.g. making sure a jump instruction does not send the virtual machine 104 beyond the end of the method)” (See Westrelin [0087])
With regard to claim 14, Shah and Westrelin teach the system of claim 8, while Shah teaches executing the second bytecode module in at least paragraph [0022], they do not teach that executing the second bytecode module further comprises: loading a class file required by the second bytecode module in a memory of the virtual machine.
However, in analogous art Westrelin teaches executing the second bytecode module further comprises: loading a class file required by the second bytecode module in a memory of the virtual machine (During resolution, the virtual machine 104 dynamically determines concrete memory address from the symbolic references included in the run-time constant pool 304 of the class. To resolve the symbolic references, the virtual machine 104 utilizes the class loader 107 to load the class identified in the symbolic reference (if not already loaded). Once loaded, the virtual machine 104 has knowledge of the memory location within the per-class area 303 of the referenced class and its fields/methods. The virtual machine 104 then replaces the symbolic references with a reference to the concrete memory location of the referenced class, field, or method. In an embodiment, the virtual machine 104 caches resolutions to be reused in case the same class/name/descriptor is encountered when the virtual machine 104 processes another class. For example, in some cases, class A and class B may invoke the same method of class C. Thus, when resolution is performed for class A, that result can be cached and reused during resolution of the same symbolic reference in class B to reduce overhead in at least paragraph [0089])
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine the loading of class files into memory to execute a bytecode module taught by Westrelin with the execution method of the second bytecode module taught by Shah resulting in loading a class file required by the second bytecode module in a memory of the virtual machine to execute the second bytecode. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of facilitating the execution process of the second bytecode module by loading a class file required by the second bytecode in a memory of the virtual machine so that “the virtual machine 104 has knowledge of the memory location within the per-class area 303 of the referenced class and its fields/methods”(See Westrelin paragraph [0089], which will in turn make it possible to for the symbolic references to undergo resolution.
With regard to claim 15, Shah teaches A non-transitory machine-readable storage medium including instructions that, when executed by a processing device, cause the processing device to perform operations (In operation, processors may store information in any suitable type of non-transitory storage medium (for example, random access memory (RAM), read only memory (ROM), field programmable gate array (FPGA), erasable programmable read only memory (EPROM), electrically erasable programmable ROM (EEPROM), etc.), software, hardware, or in any other suitable component, device, element, or object where appropriate and based on particular needs in at least paragraph [0155]) loading, in the virtual machine, a first bytecode module comprising a first bytecode of a first bytecode type (The device may receive a trusted binary object in a first form in at least the Abstract) wherein the first bytecode type is not supported by the virtual machine (There is disclosed in an example 2, the computing apparatus of example 1, wherein the first format is a non-native binary format in at least paragraph [0161]) generating a second bytecode module by translating the first bytecode to a second bytecode of a second bytecode type, wherein the second bytecode type is supported by the virtual machine (It may be necessary to translate trusted binary object 420 from a first format into a second format. For example, trusted binary object 420 may be Java byte code, which needs to be compiled into a native binary format by an ahead of time compiler. In another example, trusted binary object 420 may be a Java byte code program that will be compiled by a just-in-time compiler. In yet other examples, BTE may be any of a runtime engine, an interpreter, a just-in-time compiler, ahead-of-time compiler, a virtual machine (such as the Java Virtual Machine (JVM)), a compiler, a linker, and a toolchain utility by way of non-limiting example in at least paragraph [0092], Examiner notes that the binary translation is also outlined in FIG. 8) executing the second bytecode module by the virtual machine (The second binary is then suitable for execution within the TEE on the host system in at least paragraph [0022]);
In one embodiment of Shah, the programmer may use common Java attributes to inform the TEE of how to verify the inputs. Thus, the programmer may have the flexibility to configure the input verification without needing to write input verification routines himself. In another example that Shah provides, an IVE may allow Android ISVs, for example, to designate a part of their application code to access sensitive data coming from a protected input (such as a touch screen), and to validate the input without compromising the data. So, while Shah teaches validation techniques in the form of an IVE (input verification engine) which performs various verification and validation check, it does not explicitly teach any verification policies based on the status of the virtual machine.
However, in analogous art Westrelin teaches validating the first bytecode module according to a first validation policy based on a status of the virtual machine (The exact checks performed during verification are dependent on the implementation of the virtual machine 104 in at least paragraph [0087]).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine the validation policy taught by Westrelin with the code translation apparatus taught by Shah resulting in a translation method that performs verification on the input based on a status of a virtual machine. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of ensuring a dynamic form of validation of the input based on a status of the virtual machine especially within the input verification engine of Shah as it helps to ”check that the virtual machine 104 code of methods will not cause unexpected behavior (e.g. making sure a jump instruction does not send the virtual machine 104 beyond the end of the method)”(See Westrelin paragraph [0087]) .
With regard to claim 17, Shah and Westrelin teach the non-transitory machine-readable storage medium of claim 15, Shah teaches validating the first bytecode module according to a specification (In certain embodiments, code validation performs an integrity check on code loaded into a TEE. Manifest 470 may be a whitelist describing acceptable code or a blacklist describing unacceptable code. The Manifest may be signed by a trusted domain (such as an enterprise IT department, or original equipment manufacturer) using a key that was provisioned by the domain. The Manifest and Code Validation operations may be applied when the TEE initializes, at boot time, at TEE software/firmware update time or when a new code object is added to or removed from a TEE. In some example, “Trusted Boot” and “Secure Boot” are industry terms that refer to at least some of the above initialization steps in at least paragraphs [0088] and [0089], Examiner notes that Manifest acts as a specification in this context.).
With regard to claim 18, while Shah and Westrelin teach the non-transitory machine-readable storage medium of claim 15, Shah does not specifically teach monitoring the status of the virtual machine.
However, in analogous art Westrelin teaches monitoring the status of the virtual machine; and generating the first validation policy (check that the virtual machine 104 code of methods will not cause unexpected behavior (e.g. making sure a jump instruction does not send the virtual machine 104 beyond the end of the method), and so forth. The exact checks performed during verification are dependent on the implementation of the virtual machine 104. In some cases, verification may cause additional classes to be loaded, but does not necessarily require those classes to also be linked before proceeding. For example, assume Class A contains a reference to a static field of Class B in at least paragraph [0087], Examiner notes that “checking that the virtual machine code of methods will not cause unexpected behavior” corresponds to monitoring the virtual machine and “the exact checks performed during verification are dependent on the implementation of the virtual machine” corresponds to generating the first validation policy).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine the validation policy by monitoring the status of the virtual machine taught by Westrelin [0087] with the code translation apparatus taught by Shah ([0092] and FIG. 8) resulting in a translation method that performs verification on the input based on monitoring of a status of a virtual machine. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of ensuring “that the virtual machine 104 code of methods will not cause unexpected behavior (e.g. making sure a jump instruction does not send the virtual machine 104 beyond the end of the method)” (See Westrelin [0087])
Claim 2, 9, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Shah et al. Pub. No. US 2016/0188350 A1 (hereafter Shah) in view of WESTRELIN et al. Pub. No. US 2016/0062878 (hereafter Westrelin) as applied to claims 1, 3, 4, 7, 8, 10, 11, 14, 15, 17, and 18 above and in further view of Zhang et al. “Building a Rule-based Validation Framework (RVF) for Real-World Healthcare Data” (hereafter Zhang).
With regard to claim 2, Shah and Westrelin teach the method of claim 1 and while Shah does teach a validation policy where the programmer may have the flexibility to configure the input verification without needing to write input verification routines, they do not specifically teach a validation policy comprising a configuration file.
However, in analogous art Zhang teaches validating the first bytecode module according to a second validation policy comprising a configuration file (We defined our validation framework as a decisional procedure, based on a set of conditional checks evaluating for a purpose. These checks include things like testing for acceptable values in a given field, profiling how many records are missing data for each field, data density, and relational integrity. If data satisfies the conditions, it means that the behavior rules are not violated and the data are considered valid for the final use for which they are intended in at least page 3, Examiner notes that FIG. 1 also outlines a "List of rules to check for in the JSON format" as part of the validator engine).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine the validation that Zhang performs on the input where the validation policy comprises a configuration file with the input verification taught by Shah and Westrelin. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of ensuring a static form of validation of the input comprising a configuration file such that the validation policy “would be as well documented, consistent and transparent as possible” (See at least Zhang page 3)
With regard to claim 9, Shah and Westrelin teach the system of claim 8 and while Shah does teach a validation policy where the programmer may have the flexibility to configure the input verification without needing to write input verification routines, they do not specifically teach a validation policy comprising a configuration file.
However, in analogous art Zhang teaches validating the first bytecode module according to a second validation policy comprising a configuration file (We defined our validation framework as a decisional procedure, based on a set of conditional checks evaluating for a purpose. These checks include things like testing for acceptable values in a given field, profiling how many records are missing data for each field, data density, and relational integrity. If data satisfies the conditions, it means that the behavior rules are not violated and the data are considered valid for the final use for which they are intended in at least page 3, Examiner notes that FIG. 1 also outlines a "List of rules to check for in the JSON format" as part of the validator engine).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine the validation that Zhang performs on the input where the validation policy comprises a configuration file with the input verification taught by Shah and Westrelin. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of ensuring a static form of validation of the input comprising a configuration file such that the validation policy “would be as well documented, consistent and transparent as possible” (See at least Zhang page 3).
With regard to claim 16, Shah and Westrelin teach the non-transitory machine-readable storage medium of claim 8 and while Shah does teach a validation policy where the programmer may have the flexibility to configure the input verification without needing to write input verification routines, they do not specifically teach a validation policy comprising a configuration file.
However, in analogous art Zhang teaches validating the first bytecode module according to a second validation policy comprising a configuration file (We defined our validation framework as a decisional procedure, based on a set of conditional checks evaluating for a purpose. These checks include things like testing for acceptable values in a given field, profiling how many records are missing data for each field, data density, and relational integrity. If data satisfies the conditions, it means that the behavior rules are not violated and the data are considered valid for the final use for which they are intended in at least page 3, Examiner notes that FIG. 1 also outlines a "List of rules to check for in the JSON format" as part of the validator engine).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine the validation that Zhang performs on the input where the validation policy comprises a configuration file with the input verification taught by Shah and Westrelin. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of ensuring a static form of validation of the input comprising a configuration file such that the validation policy “would be as well documented, consistent and transparent as possible” (See at least Zhang page 3).
Claim 5, 12, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Shah et al. Pub. No. US 2016/0188350 A1 (hereafter Shah) in view of WESTRELIN et al. Pub. No. US 2016/0062878 (hereafter Westrelin) as applied to claims 1, 3, 4, 7, 8, 10, 11, 14, 15, 17, and 18 above and in further view of Dolev et al. Pub. No. US 2018/0196732 (hereafter Dolev).
With regard to claim 5, Shah and Westrelin teach method of claim 1, and while Shah teaches tagging the first format binary as part of the validation procedure, they do not specifically teach that validating the first bytecode module further comprises: modifying the first bytecode module according to a validation policy.
However, in analogous art Dolev teaches that validating the first bytecode module further comprises: modifying the first bytecode module according to a validation policy (Instrumentation is the ability to inject code into an already written (or even partially compiled, as the case with Java Bytecode) code in order to change the functionality or the behavior of the code. Since the most prominent example is Java Bytecode instrumentation, it can be considered as a proof of concept example even though this capability exists in other programming languages, as well. Insertion of code in Java is done via Bytecode Instrumentation which is the injection of code during the loading of compiled Java code (Bytecode—is computer object code that is processed by a program, usually referred to as a virtual machine, rather than by the hardware processor) to the operating environment (JVM—A Java Virtual Machine). The injection itself is done by writing a Java Agent object which is used by the JVM to load the Bytecode from a file format to the internal structures of the JVM. Rewriting such an Agent allows inspecting and injecting code into the loaded Bytecode. Many manuals and assisting packages exist to write Java Agents and Bytecode but it was found that the ASM framework (ASM is a Java bytecode manipulation and analysis framework that can be used to modify existing classes or dynamically generate classes, directly in binary form) and a GitHub (GitHub is a web-based version-control and collaboration platform for software developers) hosted profiling agent example to be particularly useful to start from. This ability can be utilized to inject hooks into the code which will allow the ability to on-demand introducing a reflex function at the injection points. This is a function that needs to be implemented (either naturally or automatically by a smart compiler) in each object (thread, process, class etc.) that wishes to enable the capability of reflexivity. This function can report the inner state of the object without changing it, or it can fix the state, depending of the result of the reflex check. This function should be fast and as un-obstructive as possible so that the reflex action will not create an overhead on the run-time in at least paragraphs [0140] - [0142]).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine the input verification taught by Shah and Westrelin with Code Instrumentation that can inject code into an already written (or even partially compiled, as the case with Java Bytecode) code in order to change the functionality or the behavior of the code which Dolev teaches resulting in the modification of the first bytecode module according to a validation policy. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of modifying the first bytecode module according to a validation policy “in order to change the functionality or the behavior of the code” so that it is optimized and can be translated to get the desired output (see at least Dolev [0140]).
With regard to claim 12, Shah and Westrelin teach the system of claim 8, and while Shah teaches tagging the first format binary as part of the validation procedure, they do not specifically teach that validating the first bytecode module further comprises: modifying the first bytecode module according to a validation policy.
However, in analogous art Dolev teaches that validating the first bytecode module further comprises: modifying the first bytecode module according to a validation policy (Instrumentation is the ability to inject code into an already written (or even partially compiled, as the case with Java Bytecode) code in order to change the functionality or the behavior of the code. Since the most prominent example is Java Bytecode instrumentation, it can be considered as a proof of concept example even though this capability exists in other programming languages, as well. Insertion of code in Java is done via Bytecode Instrumentation which is the injection of code during the loading of compiled Java code (Bytecode—is computer object code that is processed by a program, usually referred to as a virtual machine, rather than by the hardware processor) to the operating environment (JVM—A Java Virtual Machine). The injection itself is done by writing a Java Agent object which is used by the JVM to load the Bytecode from a file format to the internal structures of the JVM. Rewriting such an Agent allows inspecting and injecting code into the loaded Bytecode. Many manuals and assisting packages exist to write Java Agents and Bytecode but it was found that the ASM framework (ASM is a Java bytecode manipulation and analysis framework that can be used to modify existing classes or dynamically generate classes, directly in binary form) and a GitHub (GitHub is a web-based version-control and collaboration platform for software developers) hosted profiling agent example to be particularly useful to start from. This ability can be utilized to inject hooks into the code which will allow the ability to on-demand introducing a reflex function at the injection points. This is a function that needs to be implemented (either naturally or automatically by a smart compiler) in each object (thread, process, class etc.) that wishes to enable the capability of reflexivity. This function can report the inner state of the object without changing it, or it can fix the state, depending of the result of the reflex check. This function should be fast and as un-obstructive as possible so that the reflex action will not create an overhead on the run-time in at least paragraphs [0140] - [0142]).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine the input verification taught by Shah and Westrelin with Code Instrumentation that can inject code into an already written (or even partially compiled, as the case with Java Bytecode) code in order to change the functionality or the behavior of the code which Dolev teaches resulting in the modification of the first bytecode module according to a validation policy. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of modifying the first bytecode module according to a validation policy “in order to change the functionality or the behavior of the code” so that it is optimized and can be translated to get the desired output (see at least Dolev [0140]).
With regard to claim 19, Shah and Westrelin teach the non-transitory machine-readable storage medium of claim 15 and while Shah teaches tagging the first format binary as part of the validation procedure, they do not specifically teach that validating the first bytecode module further comprises: modifying the first bytecode module according to a validation policy.
However, in analogous art Dolev teaches that validating the first bytecode module further comprises: modifying the first bytecode module according to a validation policy (Instrumentation is the ability to inject code into an already written (or even partially compiled, as the case with Java Bytecode) code in order to change the functionality or the behavior of the code. Since the most prominent example is Java Bytecode instrumentation, it can be considered as a proof of concept example even though this capability exists in other programming languages, as well. Insertion of code in Java is done via Bytecode Instrumentation which is the injection of code during the loading of compiled Java code (Bytecode—is computer object code that is processed by a program, usually referred to as a virtual machine, rather than by the hardware processor) to the operating environment (JVM—A Java Virtual Machine). The injection itself is done by writing a Java Agent object which is used by the JVM to load the Bytecode from a file format to the internal structures of the JVM. Rewriting such an Agent allows inspecting and injecting code into the loaded Bytecode. Many manuals and assisting packages exist to write Java Agents and Bytecode but it was found that the ASM framework (ASM is a Java bytecode manipulation and analysis framework that can be used to modify existing classes or dynamically generate classes, directly in binary form) and a GitHub (GitHub is a web-based version-control and collaboration platform for software developers) hosted profiling agent example to be particularly useful to start from. This ability can be utilized to inject hooks into the code which will allow the ability to on-demand introducing a reflex function at the injection points. This is a function that needs to be implemented (either naturally or automatically by a smart compiler) in each object (thread, process, class etc.) that wishes to enable the capability of reflexivity. This function can report the inner state of the object without changing it, or it can fix the state, depending of the result of the reflex check. This function should be fast and as un-obstructive as possible so that the reflex action will not create an overhead on the run-time in at least paragraphs [0140] - [0142]).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine the input verification taught by Shah and Westrelin with Code Instrumentation that can inject code into an already written (or even partially compiled, as the case with Java Bytecode) code in order to change the functionality or the behavior of the code which Dolev teaches resulting in the modification of the first bytecode module according to a validation policy. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of modifying the first bytecode module according to a validation policy “in order to change the functionality or the behavior of the code” so that it is optimized and can be translated to get the desired output (see at least Dolev [0140]).
Claim 6, 13, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Shah et al. Pub. No. US 2016/0188350 A1 (hereafter Shah) in view of WESTRELIN et al. Pub. No. US 2016/0062878 (hereafter Westrelin) as applied to claims 1, 3, 4, 7, 8, 10, 11, 14, 15, 17, and 18 above and in further view of Gowda et al. Pub. No. US 2024/0256317 A1 (hereafter Gowda).
With regard to claim 6, Shah and Westrelin teach the method of claim 1, and while Shah does teach loading an unsupported bytecode onto the virtual machine, Shah and Westrelin do not specifically teach loading performed in response to a determinative check for a first module type supported by the virtual machine.
However, in analogous art Gowda teaches receiving, from a process, a request for the first bytecode module (In Step 200, the primary virtual machine receives a process request. In one or more embodiments, the primary virtual machine receives the process request from a user of the primary virtual machine and/or from some other software operating on any computing device of the system in at least paragraph [0070]) determining whether the first bytecode module comprises the first bytecode of the first bytecode type that is not supported by the virtual machine (In Step 202, the primary virtual machine identifies the process request constraints from the process request. In Step 204, the primary virtual machine makes a determination if the virtual components (processor(s), memory, storage) allocated to the primary virtual machine (itself) satisfy the requirements of the process request constraints. To make this determination, the primary virtual machine performs a lookup of the specifications for its own allocated virtual components and compares those specifications against the process request constraints in at least paragraphs [0071] and [0072]) wherein loading the first bytecode module is performed responsive to determining that the first bytecode module comprises the first bytecode of the first bytecode type that is not supported by the virtual machine (However, if the virtual machine does not support any one of the process request constraints (Step 204-NO), the method proceeds to Step 208. In Step 208, the primary virtual machine sends a creation request to the virtual machine manager to create an enclave virtual machine that satisfies the process request constraints (the creation request may include the process request constraints). As a non-limiting example, if the process request constraints specify (i) an x86 architecture and (ii) 2 GB of available memory, the primary virtual machine specifies those minimum requirements (e.g., an x86 processor and 2 GB of memory) to the virtual machine manager in the creation request. In Step 210, the virtual machine manager creates an enclave virtual machine satisfying the process request constraints, in order to execute the process specified in the process request. Additional details regarding this step may be found in the description of FIG. 2B. In Step 212, the primary virtual machine configures the enclave virtual machine to execute the process specified in the process request. Additional details regarding this step may be found in the description of FIG. 2C. In Step 214, the enclave virtual machine executes the process specified in the process request. Additional details regarding this step may be found in the description of FIG. 2D in at least paragraphs [0073] and [0076]-[0078]) sending, to the process, a result of executing the second bytecode module (In Step 216, the primary virtual machine obtains the result data. In one or more embodiments, the enclave virtual machine sends (or otherwise makes available) the result data to the primary virtual machine after completing the execution of the process specified in the process request in at least paragraph [0079]).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine the loading performed in response to a determinative check for a first module type supported by the virtual machine which is taught by Gowda with the loading of a bytecode of a first unsupported bytecode type which is taught by Shah and Westrelin. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of creating a process of loading a first module in response to a determination of its type and having it’s execution result returned to the process in such a way that it utilizes an enclave virtual machine , in accordance with one or more embodiments such that the unsupported bytecode module can be loaded and then executed (See FIG. 2A of Gowda).
With regard to claim 13, Shah and Westrelin teach the system of claim 8, and while Shah does teach loading an unsupported bytecode onto the virtual machine, Shah and Westrelin do not specifically teach loading performed in response to a determinative check for a first module type supported by the virtual machine.
However, in analogous art Gowda teaches receiving, from a process, a request for the first bytecode module (In Step 200, the primary virtual machine receives a process request. In one or more embodiments, the primary virtual machine receives the process request from a user of the primary virtual machine and/or from some other software operating on any computing device of the system in at least paragraph [0070]) determining whether the first bytecode module comprises the first bytecode of the first bytecode type that is not supported by the virtual machine (In Step 202, the primary virtual machine identifies the process request constraints from the process request. In Step 204, the primary virtual machine makes a determination if the virtual components (processor(s), memory, storage) allocated to the primary virtual machine (itself) satisfy the requirements of the process request constraints. To make this determination, the primary virtual machine performs a lookup of the specifications for its own allocated virtual components and compares those specifications against the process request constraints in at least paragraphs [0071] and [0072]) wherein loading the first bytecode module is performed responsive to determining that the first bytecode module comprises the first bytecode of the first bytecode type that is not supported by the virtual machine (However, if the virtual machine does not support any one of the process request constraints (Step 204-NO), the method proceeds to Step 208. In Step 208, the primary virtual machine sends a creation request to the virtual machine manager to create an enclave virtual machine that satisfies the process request constraints (the creation request may include the process request constraints). As a non-limiting example, if the process request constraints specify (i) an x86 architecture and (ii) 2 GB of available memory, the primary virtual machine specifies those minimum requirements (e.g., an x86 processor and 2 GB of memory) to the virtual machine manager in the creation request. In Step 210, the virtual machine manager creates an enclave virtual machine satisfying the process request constraints, in order to execute the process specified in the process request. Additional details regarding this step may be found in the description of FIG. 2B. In Step 212, the primary virtual machine configures the enclave virtual machine to execute the process specified in the process request. Additional details regarding this step may be found in the description of FIG. 2C. In Step 214, the enclave virtual machine executes the process specified in the process request. Additional details regarding this step may be found in the description of FIG. 2D in at least paragraphs [0073] and [0076] - [0078]) sending, to the process, a result of executing the second bytecode module (In Step 216, the primary virtual machine obtains the result data. In one or more embodiments, the enclave virtual machine sends (or otherwise makes available) the result data to the primary virtual machine after completing the execution of the process specified in the process request in at least paragraph [0079]).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine the loading performed in response to a determinative check for a first module type supported by the virtual machine which is taught by Gowda with the loading of a bytecode of a first unsupported bytecode type which is taught by Shah and Westrelin. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of creating a process of loading a first module in response to a determination of its type and having it’s execution result returned to the process in such a way that it utilizes an enclave virtual machine, in accordance with one or more embodiments such that the unsupported bytecode module can be loaded and then executed (See FIG. 2A of Gowda).
With regard to claim 20, Shah and Westrelin teach the non-transitory machine-readable storage medium of claim 15, and while Shah does teach loading an unsupported bytecode onto the virtual machine, Shah and Westrelin do not specifically teach loading performed in response to a determinative check for a first module type supported by the virtual machine.
However, in analogous art Gowda teaches receiving, from a process, a request for the first bytecode module (In Step 200, the primary virtual machine receives a process request. In one or more embodiments, the primary virtual machine receives the process request from a user of the primary virtual machine and/or from some other software operating on any computing device of the system in at least paragraph [0070]) determining whether the first bytecode module comprises the first bytecode of the first bytecode type that is not supported by the virtual machine (In Step 202, the primary virtual machine identifies the process request constraints from the process request. In Step 204, the primary virtual machine makes a determination if the virtual components (processor(s), memory, storage) allocated to the primary virtual machine (itself) satisfy the requirements of the process request constraints. To make this determination, the primary virtual machine performs a lookup of the specifications for its own allocated virtual components and compares those specifications against the process request constraints in at least paragraphs [0071] and [0072]) wherein loading the first bytecode module is performed responsive to determining that the first bytecode module comprises the first bytecode of the first bytecode type that is not supported by the virtual machine (However, if the virtual machine does not support any one of the process request constraints (Step 204-NO), the method proceeds to Step 208. In Step 208, the primary virtual machine sends a creation request to the virtual machine manager to create an enclave virtual machine that satisfies the process request constraints (the creation request may include the process request constraints). As a non-limiting example, if the process request constraints specify (i) an x86 architecture and (ii) 2 GB of available memory, the primary virtual machine specifies those minimum requirements (e.g., an x86 processor and 2 GB of memory) to the virtual machine manager in the creation request. In Step 210, the virtual machine manager creates an enclave virtual machine satisfying the process request constraints, in order to execute the process specified in the process request. Additional details regarding this step may be found in the description of FIG. 2B. In Step 212, the primary virtual machine configures the enclave virtual machine to execute the process specified in the process request. Additional details regarding this step may be found in the description of FIG. 2C. In Step 214, the enclave virtual machine executes the process specified in the process request. Additional details regarding this step may be found in the description of FIG. 2D in at least paragraphs [0073] and [0076] - [0078]) sending, to the process, a result of executing the second bytecode module (In Step 216, the primary virtual machine obtains the result data. In one or more embodiments, the enclave virtual machine sends (or otherwise makes available) the result data to the primary virtual machine after completing the execution of the process specified in the process request in at least paragraph [0079]).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine the loading performed in response to a determinative check for a first module type supported by the virtual machine that is taught by Gowda with the loading of a bytecode of a first unsupported bytecode type which is taught by Shah and Westrelin. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of creating a process of loading a first bytecode module in response to a determination of its type and having it’s execution result returned to the process in such a way that it utilizes an enclave virtual machine, in accordance with one or more embodiments such that the unsupported bytecode module can be loaded and then executed (See FIG. 2A of Gowda).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US-7725879-B2
teaches
Bytecode translation from a first bytecode type (a bytecode of a method of a Java class) to a second code and the execution of the second code.
US-12086574-B1
teaches
Bytecode translation of a first bytecode that can run in a first execution environment such that the first bytecode module is parsed to determine an intermediate representation (IR) comprising at least at least one single static assignment (SSA) that corresponds to the at least one stack-based object, and translate the IR into machine code that is executable in a second execution environment.
Examiner respectfully requests, in response to this Office action, support be shown for language added to any original claims on amendment and any new claims. That is, indicate support for newly added claim language by specifically pointing to page(s) and line number(s) in the specification and/or drawing figure(s). This will assist Examiner in prosecuting the application.
When responding to this Office Action, Applicant is advised to clearly point out the patentable novelty which he or she thinks the claims present, in view of the state of the art disclosed by the references cited or the objections made. He or she must also show how the amendments avoid such references or objections. See 37 CFR 1.111(c).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SIDHARTH R EAGE whose telephone number is (571)272-9858. The examiner can normally be reached Monday-Friday 9:30am-6:30pm.
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, Bradley Teets can be reached at (571)272-3338. 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.
/S.E./Examiner, Art Unit 2197
/BRADLEY A TEETS/Supervisory Patent Examiner, Art Unit 2197