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 .
Examiner’s Note (EN)
The prior art rejections below cite particular paragraphs, columns, and/or line numbers in the references for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 6 and 10 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the enablement requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to enable one skilled in the art to which it pertains, or with which it is most nearly connected, to make and/or use the invention.
Claim 6 requires the hardware emulator writes “into the first program …during the execution”. The specification refers to DBI (Dynamic Binary Instrumentation). However, DBI does not insert code into the program, rather DBI adds instrumentation code blocks before and after various section of the program being instrumented in the execution cache. Please refer to https://www.cs.ucr.edu/~heng/software-security-book/dbi/ for a description of how DBI works.
Claim 10 requires tracing only the edited part of the code. This is described in [0070] however, the specification doesn’t describe how this is to be accomplished.
Wands Factors Analysis:
The breath of the claims
Claim 6 broadly require DBI however, is worded in a way inconsistent with how DBI works in practice.
Claim 10 discusses differential code instrumentation broadly, with no disclosure of how it is accomplished.
The nature of the invention
The invention discloses running benchmarking metrics for software applications on various hardware platforms through the usage of hardware emulators.
The state of the prior art
DBI is known in the art. However, differential code instrumentation is a highly technical technique with multiple possible specific implementations. The instant application broadly discusses DBI, however mischaracterizes how it works in practice. Additionally, there is no discussion of differential code instrumentation related to Claim 10.
The level of one of ordinary skill
The level of ordinary skill required by the invention is that of a software developer with multiple years of industry experience or a graduate degree holder in computer science. Creating an algorithm for differential instrumentation requires a lot of technical skill and hardware architecture knowledge that is not provided or known to the examiner to conduct the claimed functionality without undue experimentation.
The level of predictability in the art
There is a high level of predictability in the art with clear specification and requirements. However, the specification doesn’t provide either. Trying to write into the program code while it’s executing is highly unpredictable and unstable. Differential instrumentation on the other hand is very technical and requires detailed knowledge of hardware architecture and how machine code is executed at the operation system level.
The amount of direction provided by the inventor
The direction for DBI is misleading and there is no direction for differential instrumentation.
The existence of working examples
The examples provided in the specification are broad and don’t detail the function of the instrumentation as far as DBI or differential instrumentation is concerned.
The quantity of experimentation needed to make or use the invention based on the content of the disclosure
Trying to write into the program code while it’s executing is highly unpredictable and unstable.
The quantity of experimentation to create a differential instrumentation implementation is unreasonable. While determining the difference between various code bodies is reasonable, devising working algorithms to implement differential instrumentation would involve unreasonable experimentation.
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-8 and 13-20 are rejected under 35 U.S.C. 103 as being unpatentable over Gorton (US20100115494A1)
Regarding Claim 1, Gorton teaches A method comprising: compiling, on a hardware emulator, a first program (Gorton, [0042] "Binary code 310 may be augmented by instrumentation 320, which, in one embodiment, may be static 322, or prior to run-time of the executable code. Such a flow may require static compilation, wherein instrumentation libraries or tools insert analysis code. This insertion step may occur prior to linking or subsequent to linking within the back-end compilation stage. The new, augmented code is then ready to be executed and provide statistics for performance studies or debugging techniques." [0051-0052] "Virtual machine 410 executes programs as if it is the hardware platform. Virtual machine 410 may execute programs that were written for the computer processor architecture within subsystem 100, which may be referred to as native execution. Virtual machine emulates the hardware of subsystem 100. Alternatively, virtual machine 410 may execute programs that were written for another computer processor architecture outside of subsystem 100. In this case, virtual machine 410 emulates the hardware of an outside processor architecture with the aid of emulation unit 414. Dynamic binary translation performed by virtual machine 410 permits this interesting feature that executing binary code 420 may be separated from the underlying hardware in subsystem 100. Virtual machine 410 may support dynamic compilation, such as Just-In-Time (JIT) compilation with JIT compiler 412. Binary code 420 may be an application that has already been compiled and currently resides in system memory or the cache memory subsystem of hardware processing subsystem 100. Dynamic compilation performed by JIT compiler 412 within virtual machine 410 may also perform dynamic binary translation, which allows a software application of an arbitrary guest architecture to be executed on a computing system 400 with a different host architecture within subsystem 100. Therefore, the software and hardware may evolve independently. The dynamically translation output of binary code 420 is stored in code cache 416 for execution. The performance improvement over interpreters originates from caching the results of translated blocks, such as basic blocks, of binary code 420 into code cache 416. Now each line or operand is not reevaluated each time it is encountered. It also has advantages over statically compiling the code at development time, as it can partially recompile the binary code 420 if this is found to be advantageous, and may be able to enforce security guarantees.")
wherein the compiled first program includes an ID marker corresponding to an operation of the first program; (Gorton, [0033] "The instructions 202 of an application may be grouped into basic blocks 204, wherein basic blocks 204 may consist of one or more code statements terminated by an unconditional jump instruction. A particular basic block 204 may be identified by the address of its corresponding first instruction. As described earlier, a path 206 within the application may be defined as a sequence of unique basic blocks (Bbs) such that the next executed Bb may result in a cycle, wherein a match of the current Bb compared to a previously processed Bb in the construction of the current path completes the cycle. Table 1 below displays an example of a sequence of Bbs and one embodiment of the resulting paths 206. The initial three Bbs (e.g. A B C) are defined as the first path, Path 0. The fourth Bb (e.g. the second B) is defined as the second path, Path 1, and so forth.")
executing, on the hardware emulator, the compiled first program; (Gorton, [0051])
generating, by the hardware emulator based on the executing, a trace of the first program, the trace including the ID marker corresponding to the operation of the first program (Gorton, [0049] "The DBI tool sees every instruction in the user process that is executed, including the dynamic loader and all shared libraries. The instrumentation and analysis execute in the same address space as the application, and can see all the application's data. The DBI tool passes instructions or a sequence of instructions (trace) to an instrumentation routine. It does not use the same memory stack or heap area as the application, and maps addresses in a special area. Addresses of local variables (stack) and addresses returned by calls are not changed. Other embodiments of a DBI tool are possible and contemplated." and [0059-0060] "In block 502, instructions of binary code, such as machine code, of a software application may be loaded, translated, instrumented, and executed. In one embodiment, the instrumentation code and analysis code may be augmented to the translated binary code according to directives given by a user via a dynamic binary instrumentation (DBI) tool. In one embodiment, each time a basic block boundary, such as the head or the end, is encountered (conditional block 504), an analysis function call may be invoked and characterization information of the basic block may be compressed and stored, or simply stored, in block 506. Storage may utilize a hash table. The characterization information corresponding to the current basic block may include one or more of the following: an address of the first instruction of the basic block, the weight or “heat” value, disassembly of the instructions, or other. In another embodiment, the DBI tool may utilize a more efficient location in the code to invoke an analysis function call other than a basic block boundary. For example, another location within the basic block other than the start or finish may require less context, or data corresponding to system registers, virtual addresses, or other information pertaining to the execution of a particular thread or process, to be saved due to the instruction sequence. If the current identified basic block (Bb) is new (conditional block 508), or it does not match a previously processed Bb in the construction of a sequence of unique Bbs, or current path, then the current path is extended with the current Bb and control flow of method 500 returns to block 502. Otherwise, if the current identified Bb is not new (conditional block 508), then the current path, or New Path, is marked as completed in block 512." )
mapping, by one or more processors, the trace to one or more benchmarks of a representative operation performed on a hardware system, wherein the mapping includes matching the ID marker of the trace to an ID marker corresponding to the representative operation (Gorton, [0024] "If a sequence of basic blocks is “A B C D B . . . ” then the first path constructed may be “A B C D”, and the second path constructed may start with the second “B”. In addition, a cost, or a weight, may be associated with each Bb, such as the total number of instructions within the Bb, the number of a certain type of instruction within the Bb, or other. During program profiling, this weight may be summed or averaged over all the instructions within the basic block to generate a “heat” value for a path. The “heat” of the path may be multiplied by the frequency of the path during dynamic execution, wherein the frequency may be measured by use-counters. This generated “hot” information allows investigation into the program behavior such as program phase changes. Program phase changes may find a “hot” spot at a time t0 during execution, but this “hot” spot may not exist at time t1, t2, or other. Also, such hot path program profiling may be useful in determining library interactions and information on dynamic instruction mix such as the number of instructions of a certain type, whether the application is instruction fetch bound, or other." [0057-0062] "Next, the DBA tool 464 may analyze the compressed set of paths simultaneously as the binary code 420 is being translated, instrumented, and executed in order to identify repeated paths. The repeated paths may be used to later identify strata, repeated stratum, and a stratum layer as described earlier regarding the hierarchical layers of cycles in FIG. 2. In one embodiment, compression may occur prior to storage of strata, repeated strata, and the stratum layer. In one embodiment, each of the repeated paths is given a unique “strata” identifier. An identified sequence of repeated strata may then be compressed and stored to an indexed sequential access method (ISAM) file. Each record of information in the ISAM file may be accessed by an ending instruction number, ending path number, an ending strata number, or other. Profile information 466, such as [t]he combination of the stored data in hash tables and the ISAM file, provides a whole program profile that may be used to characterize the dynamic behavior of binary code 420 such as program phase changes and other." [0066-0067] "Method 600 may correspond to processing steps subsequent to block 518 of method 500. Predetermined statistics of the received repeated path are collected in block 602. These statistics and information corresponding to the sequence of Bbs within the path are stored in block 604. In one embodiment, the statistics and information are compressed prior to being stored in a hash table. If this particular repeated path has been processed earlier in dynamic program execution (conditional block 606), then a corresponding global trip count is incremented by the current trip count of the repeated path in block 608. Whether or not this repeated path has been processed earlier, a unique path identifier (ID) is assigned to this repeated path in block 610. The path ID and current trip count of the repeated path are then passed to a stratum processing function in block 612." also see [0032-0034])
Gorton teaches the usage of hash tables to store the trace information for the various blocks of code being executed. It would have been obvious to a person of ordinary skill in the art that hash table’s unique IDs correspond to the unique ID of the trace being mapped to the unique ID of the code blocks being executed. (Gorton [0059] “In block 502, instructions of binary code, such as machine code, of a software application may be loaded, translated, instrumented, and executed. In one embodiment, the instrumentation code and analysis code may be augmented to the translated binary code according to directives given by a user via a dynamic binary instrumentation (DBI) tool. In one embodiment, each time a basic block boundary, such as the head or the end, is encountered (conditional block 504), an analysis function call may be invoked and characterization information of the basic block may be compressed and stored, or simply stored, in block 506. Storage may utilize a hash table. The characterization information corresponding to the current basic block may include one or more of the following: an address of the first instruction of the basic block, the weight or “heat” value, disassembly of the instructions, or other. In another embodiment, the DBI tool may utilize a more efficient location in the code to invoke an analysis function call other than a basic block boundary. For example, another location within the basic block other than the start or finish may require less context, or data corresponding to system registers, virtual addresses, or other information pertaining to the execution of a particular thread or process, to be saved due to the instruction sequence.”)
Regarding Claim 2, Gorton teaches the method of claim 1, further comprising estimating at least one parameter regarding the first program based on the mapping, wherein the at least one parameter pertains to a performance metric of the operation of the first program (Gorton, [0046] "For example, an instrumentation toolkit may be instructed to insert code at basic block boundaries within the application program. In one embodiment, the following information may be collected from the application by the instrumentation code at the basic block boundaries: basic block address, “heat” of the basic block, and basic block disassembly. The “heat” of the basic block may be a measure of how much time a particular basic block requires to execute. In one embodiment, the “heat” may simply be the number of instructions in the basic block. In other embodiments, the “heat” may be measure of a number of a certain type of instruction within the corresponding basic block, a total number of clock cycles required for an execution of the basic block, a total number of cache misses, or other." and [0024] generates a heat value comprising cost/weight of the total number of instructions)
Regarding Claim 3, Gorton teaches the method of claim 1, further comprising writing, by the hardware emulator, a block record into the first program based on the compiling of the first program, wherein the block record includes the ID marker corresponding to the operation of the first program (Gorton, [0036] "In order to detect or identify basic blocks in order to track a sequence of basic blocks (e.g. A B C B B) during execution of a software application, the application program may be instrumented. Program instrumentation may comprise augmenting code with new code in order to collect runtime information. Generally speaking, to instrument code refers to the act of adding extra code to a program for the purpose of dynamic analysis. Also, the code added during instrumentation is referred to as the instrumentation code. It may also be referred to as analysis code. The code that performs the instrumentation is not referred to as instrumentation code. Rather, this code resides in an instrumentation toolkit, which is further explained shortly. In one embodiment, the analysis code may be inserted entirely inline. In another embodiment, the analysis code may include external routines called from the inline analysis code. The analysis code is executed as part of the program's normal execution. However, the analysis code does not change the results of the program's execution, although the analysis code may increase the required execution time." [0043-0046] "Binary code 310 may be augmented by instrumentation 320, which, in one embodiment, may be static 322, or prior to run-time of the executable code. Such a flow may require static compilation, wherein instrumentation libraries or tools insert analysis code. This insertion step may occur prior to linking or subsequent to linking within the back-end compilation stage. The new, augmented code is then ready to be executed and provide statistics for performance studies or debugging techniques. In a preferred embodiment, binary code 310 may be augmented by dynamic instrumentation 324, which occurs at run-time. In one embodiment, a dynamic binary instrumentation (DBI) tool grafts itself into the client process at start-up, and then partially (re)compiles the binary code of the software application, one basic block at a time, in a just-in-time (JIT), execution manner. This (re)compilation process may comprise disassembling the machine code into an intermediate representation (IR) which is instrumented by a tool plug-in…For example, an instrumentation toolkit may be instructed to insert code at basic block boundaries within the application program. In one embodiment, the following information may be collected from the application by the instrumentation code at the basic block boundaries: basic block address, “heat” of the basic block, and basic block disassembly. The “heat” of the basic block may be a measure of how much time a particular basic block requires to execute. In one embodiment, the “heat” may simply be the number of instructions in the basic block. In other embodiments, the “heat” may be measure of a number of a certain type of instruction within the corresponding basic block, a total number of clock cycles required for an execution of the basic block, a total number of cache misses, or other." [0059] "In block 502, instructions of binary code, such as machine code, of a software application may be loaded, translated, instrumented, and executed. In one embodiment, the instrumentation code and analysis code may be augmented to the translated binary code according to directives given by a user via a dynamic binary instrumentation (DBI) tool. In one embodiment, each time a basic block boundary, such as the head or the end, is encountered (conditional block 504), an analysis function call may be invoked and characterization information of the basic block may be compressed and stored, or simply stored, in block 506. Storage may utilize a hash table. The characterization information corresponding to the current basic block may include one or more of the following: an address of the first instruction of the basic block, the weight or “heat” value, disassembly of the instructions, or other. In another embodiment, the DBI tool may utilize a more efficient location in the code to invoke an analysis function call other than a basic block boundary. For example, another location within the basic block other than the start or finish may require less context, or data corresponding to system registers, virtual addresses, or other information pertaining to the execution of a particular thread or process, to be saved due to the instruction sequence.")
Regarding Claim 4, Gorton teaches the method of claim 3, wherein writing, by the hardware emulator, the block record into the first program includes augmenting the block record to include a description of the operation of the first program ([0043-0046] and [0059])
Regarding Claim 5, Gorton teaches the method of claim 3, wherein writing, by the hardware emulator, the block record into the first program is conducted during or following the compiling (Gorton, [0043-0046])
Regarding Claim 6, Gorton teaches the method of claim 3, wherein writing, by the hardware emulator, the block record into the first program is conducted during the executing (Gorton, [0043-0046] and [0041] if the 'first program' is interpreted broadly to mean machine code representation of the first program, and writing into interpreted to mean around the first program’s machine code to perform DBI as the instant specification attempts to describe [0052])
Regarding Claim 7, Gorton teaches the method of claim 1, wherein the hardware emulator emulates the hardware system (Gorton, [0051] "Virtual machine 410 executes programs as if it is the hardware platform. Virtual machine 410 may execute programs that were written for the computer processor architecture within subsystem 100, which may be referred to as native execution. Virtual machine emulates the hardware of subsystem 100. Alternatively, virtual machine 410 may execute programs that were written for another computer processor architecture outside of subsystem 100. In this case, virtual machine 410 emulates the hardware of an outside processor architecture with the aid of emulation unit 414. Dynamic binary translation performed by virtual machine 410 permits this interesting feature that executing binary code 420 may be separated from the underlying hardware in subsystem 100.")
Regarding Claim 8, Gorton teaches the method of claim 1, further comprising generating, by the hardware emulator, a second trace of a second program ([0049] and [0006-0008] “Systems and methods for efficient whole program profiling of software applications.”)
Regarding Claim 13, Gorton teaches A system for testing software, the system comprising: a memory including a code repository; one or more processors, the one or more processors configured to: a hardware system configured to ([0021-0022])
The remaining limitations are similar to claim 1 and are rejected under the same rationale.
Regarding Claim 14, Gorton teaches the system of claim 13, further comprising a developer device (Gorton, [0045] “The user writes instrumentation and analysis routines, which may interface with an application programming interface (API) of the DBI tool. The instrumentation is customizable. The user decides where analysis calls are inserted, the arguments to the analysis routines, and what the analysis routines measure. The instrumented IR may then be converted back into binary code, which is referred to as a translation. This translation may be stored in a code cache to be executed as necessary. The processor core(s) spends its execution time generating, locating, and executing translations.” And [0053])
Regarding Claim 15, Gorton teaches the system of claim 14, wherein the memory is a memory of the developer device ([0021-0022] The examiner designates Gorton’s instrumentation device to be the development device)
Regarding Claim 16, Gorton teaches the system of claim 14, wherein the one or more processors are one or more processors of the developer device ([0021-0022)
Regarding Claim 17, Gorton teaches the system of claim 13, wherein the hardware system is a plurality of hardware systems and the hardware emulator is a plurality of hardware emulators (Gorton, [0051])
Regarding Claim 18, Gorton teaches the system of claim 13, wherein the operation of the first program is a plurality of operations of the first program and the representative operation is a plurality of representative operations (Gorton, [0057])
Claim 19 is a system claim reciting limitations similar to claim 7 and is rejected under the same rationale.
Regarding Claim 20, Gorton teaches the system of claim 13, wherein the hardware system is one of: a desktop computer, a laptop, a tablet PC, an at-home assistant device, a smart speaker, a temperature unit, a thermostat unit, a mobile phone, a PDA, or a smartwatch (Gorton, [0021-0022])
Claims 9-11 are rejected under 35 U.S.C. 103 as being unpatentable over Gorton (US20100115494A1) in view of Mazkatli et al. (Incremental Calibration of Architectural Performance Models with Parametric Dependencies)
Regarding Claim 9, Gorton teaches the method of claim 8. Mazkatli teaches wherein the second program is the first program with one or more edits (Mazkatli, Pg. 2, "Incremental Dev-time calibration: We propose a novel incremental calibration at Development time (Dev-time) that responds to source code changes by adaptive instrumentation of the changed parts of the code and uses the resulting measurements from performance tests or the production system to estimate the PMPs incrementally. For this purpose, we propose a novel incremental Resource Demand Estimation (RDE) that is based on adaptive monitoring. Our calibration uses statistical analysis to learn potential dependencies, e.g., regression analysis for resource demands and decision trees for the estimation of branch transitions.")
Gorton and Mazkatli are analogous art because they are from the same field of instrumentation of computer applications. Mazkatli teaches a known process of instrumenting only the edited sections of the code. Before the effective filing date of the invention, It would be obvious to one of ordinary skill in the art to apply the known technique of Mazkatli in the environment and process of Gorton which teaches various instrumentation methods in order to save time and computing resources by only focusing on the new changes to the code. Note MPEP 2143- (D) Applying a known technique to a known device (method, or product) ready for improvement to yield predictable results.
Regarding Claim 10, Gorton in view of Mazkatli teaches the method of claim 9. Mazkatli teaches wherein the second trace is a trace of only the one or more edits (Mazkatli, Pg. 2, "Incremental Dev-time calibration: We propose a novel incremental calibration at Development time (Dev-time) that responds to source code changes by adaptive instrumentation of the changed parts of the code and uses the resulting measurements from performance tests or the production system to estimate the PMPs incrementally. For this purpose, we propose a novel incremental Re source Demand Estimation (RDE) that is based on adaptive monitoring. Our calibration uses statistical analysis to learn potential dependencies, e.g., regression analysis for resource demands and decision trees for the estimation of branch transitions.") Refer to claim 9 for the motivation to combine.
Regarding Claim 11, Gorton teaches method of claim 1. Mazkatli teaches wherein mapping the trace to the one or more benchmarks further includes statistically refining an accuracy of the benchmarks (Gorton [0024] , [0043] and Mazkatli pg. 2, "Incremental Dev-time calibration: We propose a novel incremental calibration at Development time (Dev-time) that responds to source code changes by adaptive instrumentation of the changed parts of the code and uses the resulting measurements from performance tests or the production system to estimate the PMPs incrementally. For this purpose, we propose a novel incremental Re source Demand Estimation (RDE) that is based on adaptive monitoring. Our calibration uses statistical analysis to learn potential dependencies, e.g., regression analysis for resource demands and decision trees for the estimation of branch transitions.")
For motivation to combine please see claim 9.
Claims 12 are rejected under 35 U.S.C. 103 as being unpatentable over Gorton (US20100115494A1) in view of Nelson et al. (US20190340103A1)
Regarding Claim 12, Gorton teaches the method of claim 1. Nelson teaches wherein compiling the first program is conducted using LLVM intermediate representation (IR) (Nelson, [0293] "FIG. 11 shows some examples of intermediate representations 826. The illustrated examples include a symbol table 1102, which correlates source code identifiers 1104 (variable names, function names, object member and method names, etc.) with data types 1106 (integer, float, string, Boolean, and user-defined types, for example). Another example is an abstract syntax tree 1108. Other examples include code 1112 written in one or more intermediate languages 1110. More generally, some embodiments use an intermediate representation 826 which shares the structure, or is even a copy of, an intermediate representation created by a compiler. However, the intermediate representation 826 is placed in the context of an execution controller as opposed to the context of the compiler. Also, the intermediate representation 826 is utilized for trace replay of an execution trace 418 of previously generated code, not for generating that code in the first place." [0304] "In some embodiments, the intermediate representation 826 includes at least one of the following: a symbol table 1102 which correlates at least two identifiers 1104 used in the source code with data types 1106, an abstract syntax tree 1108 derived from at least a portion of the source code, or a translation 1112 into an intermediate language 1110 of at least a portion of the source code 212." EN: 1110 is defined in [0096]: 1110 intermediate language, e.g., Microsoft Common Intermediate Language, Java® bytecode (mark of Oracle Corporation), register transfer languages, Parrot intermediate representation, Standard Portable Intermediate Representation, LLVM® IR intermediate language (mark of LLVM Foundation Corporation), and others)
Gorton and Nelson are analogous art because they are from the same field of instrumentation of computer applications. Nelson teaches a known process of utilizing LLVM Intermediate representation for compiling programming languages. Before the effective filing date of the invention, It would be obvious to one of ordinary skill in the art to apply the known technique of Nelson in the environment and process of Gorton which teaches various instrumentation methods in order to provide wide compatibility for applications written in various programming languages. Note MPEP 2143- (D) Applying a known technique to a known device (method, or product) ready for improvement to yield predictable results.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Gurevich (US20190205243A1): discloses detailed binary instrumentation methods.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMIR DARWISH whose telephone number is (571)272-4779. The examiner can normally be reached 7:30-5:30 M-Thurs.
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, Lewis Bullock can be reached on 571-272-3759. 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.
/A.E.D./Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199
Prosecution Insights