DETAILED ACTION
Claims 1-21 are pending in the current application.
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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 10/2/25 has been entered.
Response to Arguments
Applicant's arguments filed 10/2/25 have been fully considered but they are not persuasive.
Applicant argues that the cited prior art does not disclose (Argument 1; Remarks pg. 11 lines 3-9) comparing the first floating point results to the second floating point result to provide a comparison result, the comparison result indicating a compiler optimization difference between the vehicle driving compatible compiler and the testing environment compatible compiler, wherein the comparison result is used to evaluate differences attributable to compiler optimization.
With respect to applicant’s argument examiner respectfully disagrees. As to argument 1, the teachings of Mathew Col. 2 lines 17-26 and 49-58, Col. 5 lines 23-25 and lines 39-46, Col. 11 lines 6-11 and Col. 18 lines 20-27 are used to show the specifics of different environments having different versions of the compiler, viewed as two different compilers where each environment will compile the same source code, same high level language code, with its respective compiler and thus viewed as generate a first and second target language computer code for each associated build environment associated with each different version of the compiler, where at least one environment can be viewed as an associated test environment thus viewed compiling code by a testing environment compatible compiler designed for a testing environment, thus having the same source code compiled by different compilers and executed in different build environments where the processing and executing of the build in the build environment includes use of processors, where the teachings of Dugan [0031] lines 1-6 and [0032] lines 7-20 are used to show the specifics vehicle driving environment and associated architecture and that can include processor to run/execute the code where the processors can be heterogenous combinations of processors, processor architecture or combination of different hardware and software viewed as different the environment including different processors thus showing that the vehicle execution environment can run/execute with different processors with different architecture and thus if the code can be compiled and run/executed on different combinations of processors and processor architecture it is viewed as being different from above processor for executing the code in the test environment of Mathew. Where the teachings of Krishnamurthy [0033] lines 2-11, [0041] lines 1-5 and [0045] lines 1-20 showing the specifics that the performed/executed code includes floating point computation/data processing where the code is processed/executed in two different environment and being able to compare the difference between the two floating point values the claim is silent however as what specifics of how the compared floating point results is used to indicating a compiler optimization difference between the two compiler used to compiler the code executed in the different environment, wherein the comparison result is used to evaluate difference attributable to compiler optimization as this language and thus this language is viewed as non-limiting intended use type language thus together with the teachings of Mathew showing the specifics of the different compiler compiling the same source code for use in different execution environments together viewed as being able to determine the difference between the floating point operations of two different environments it would indicate a type of compiler optimization difference between the two environments
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 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, 8, 10, 15 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Mathew et al. (Patent No. US 10,216,512 B1) in view of Dugan et al. (Pub. No. US 2006/0136131 A1), in view of Krishnamurthy et al. (Pub. No. US 2013/0007412 A1).
As to claims 1, 8 and 15, Mathew discloses a system for evaluating a floating-point accuracy of a vehicle driving compatible compiler, the system comprising: processing circuitry (Mathew Col. 5 lines 39-46); and
memory to store instructions, which when executed by the processing circuitry, cause the processing circuitry to perform operations comprising (Mathew Col. 17 lines 18-25):
receiving or generating a first target language computer code and a second target language computer code, the first target language computer code generated by compiling a high-level language computer code by a vehicle driving compatible compiler designed for a vehicle driving application, the second target language computer code generated by compiling the high-level language computer code by a testing environment compatible compiler designed for a general testing environment the first vehicle driving compatible compiler different from the testing environment compatible compiler(Mathew Col. 2 lines 17-26 and 49-58, Col. 5 lines 23-25, Col. 11 lines 6-11 and Col. 18 lines 20-27; which shows the specifics of different environments having different versions of the compiler, viewed as two different compilers where each environment will compile the source code with its respective compiler and thus viewed as generate a first and second target language computer code for each environment associated with each compiler, where at least one environment can be viewed as an associated test environment thus viewed compiling code by a testing environment compatible compiler designed for a testing environment where the can be an associated programming language associated with the targeted build, where the source code language can include high-level computer code languages, where the specifics of software environments including a vehicle driving environment thus including a specific vehicle driving compatible compiler for a vehicle driving application is seen specifically disclose in the teachings of Dugan below),
executing the first target language computer code by one or more vehicle driving compatible processors, the executing of the first target language computer code involving executing operations to provide a result (Mathew Col. 2 lines 49-58, Col. 3 lines 1-11, Col. 5 lines 39-46 and Col. 14 lines 38-44; which shows for each environment being able to execute the code with its specific environment and produce/provide results that can be processed by specific resources including processor resources, where the specifics of a processor being for a vehicle environment, viewed as a vehicle driving compatible processor is seen in the specific teachings of Dugan below);
executing the second target language computer code by one or more testing environment compatible processors, the executing of the second target language computer code involving executing operations to provide a second result (Mathew Col. 2 lines 49-58, Col. 3 lines 1-11, Col. 5 lines 39-46, Col. 11 lines 6-11 and Col. 14 lines 38-44; which shows for each environment being able to execute the code with its specific environment and produce/provide results which can be processed by specific resources including processor where and environment can be viewed as a testing environment).
Mathew does not specifically disclose the specifics of first compiler being vehicle driving compatible compiler designed for vehicle driving application; and the specifics that the testing environment compatible processors that differ by architecture from the one or more vehicle driving compatible processors.
However, Dugan discloses the specifics of first compiler being vehicle driving compatible compiler designed for vehicle driving application; and the specifics that the testing environment compatible processors that differ by architecture from the one or more vehicle driving compatible processor (Dugan [0031] lines 1-6 and [0032] lines 7-20; which shows that the code can be compiled to run on a device/environment which can include a vehicle device thus viewed as a type of vehicle driving compatible compiler for a vehicle driving application/function and that the compiled code can also run on a heterogenous combination of processors and processor architecture, thus viewed as different processor architecture from each other, thus in light of the teachings of Mathew above showing the specifics of compiling code with different compiler for different environments that can include a testing environment and executing that code in specifically targeted environment with specific resources can together be seen as showing executing the second target language computer code by one or more testing environment compatible processors that differ by architecture from the one or more vehicle driving compatible processors, the executing of the second target language computer code involving executing an operation to provide a second result).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate the teachings of Dugan showing the specifics of having different devices/environments that implement code with different processor architecture into the plurality of environment with different compilers for code of Mathew for the purpose of increasing the ease of use of instructions so they are adaptable to run on a plurality of different environments with different processing architecture, as taught by Dugan [0032] lines 7-20.
Mathew as modified by Dugan does not specifically disclose the high-level language computer code is free from programmer constraints regarding an order of execution of addition-type floating-point operations to enable floating point operation comparison between the vehicle driving compatible compiler and the testing environment compatible compiler; the executing of the first target language computer code involving executing addition type floating point operations to provide a first floating point result; the executing of the second target language computer code involving executing addition type floating point operations to provide a second floating point result that corresponds to the first floating point result; comparing the first floating point result to the second floating point results to provide a comparison result, the comparison result indicating a compiler optimization difference between the vehicle driving compatible compiler and the testing environment compatible compiler, wherein the comparison result is used to evaluate differences attributable to compiler optimization; and determining the floating-point accuracy of vehicle driving compatible compiler based on the comparison result.
However, Krishnamurthy discloses the high-level language computer code is free from programmer constraints regarding an order of execution of addition-type floating-point operations to enable floating point operation comparison between the vehicle driving compatible compiler and the testing environment compatible compiler (Krishnamurthy [0033] lines 2-11, [0045] lines 1-20 and [0051] lines 1-6; which shows that the high level language used is free from programming constraints regarding an order of execution of addition-type floating point operations as it is able to perform associative computations, including adding, thus viewed that the operations/additions can be applied to data in any order, thus viewed as not having constraints regarding the order of execution associated with the addition operations, where the data can include floating point results thus viewed as being able to perform floating-point addition-type operation/computations and thus enable a comparison between operations performed in two different environments, which in light of the teachings of Mathew and Dugan above showing the specifics of environments associated with one type of compiler for one environment, that can be a type of vehicle compiler and a second/different compiler for a second testing environment can be seen together as showing enable floating point operation comparison between the vehicle driving compatible compiler and the testing environment compatible compiler);
the executing of the first target language computer code involving executing addition type floating point operations to provide a first floating point result; the executing of the second target language computer code involving executing addition type floating point operations to provide a second floating point result that corresponds to the first floating point result (Krishnamurthy [0006] lines 11-15, [0027] lines 1-6, [0045] lines 1-20 and [0051] lines 1-6; which shows being able to compare floating point results/output from two separate processors performing/executing redundant actions/operations to generate two separate floating point output/results that can be used in comparison where operations/computations that can be performed are seen by example as including adding for values, where it is viewed that values can include floating point values, where the specifics of executing the first target language computer code and second target language computer code, where the source code is not limited as thus can include executing addition type floating point operations as well, are seen specifically disclosed in Mathew above and together would be viewed as showing the executing of the first target language computer code involving executing addition type floating point operations to provide a first floating point; the executing of the second target language computer code involving executing addition type floating point operations to provide a second floating point result that corresponds to the first floating point result);
comparing the first floating point result to the second floating point results to provide a comparison result, the comparison result indicating a compiler optimization difference between the vehicle driving compatible compiler and the testing environment compatible compiler, wherein the comparison result is used to evaluate differences attributable to compiler optimization (Krishnamurthy [0006] lines 11-15, [0027] lines 1-6 and [0045] lines 1-20; which shows being able to compare the redundantly generated two provided floating point results/output from the two separate processors and being able to indicate/determine a difference between the results, which in light of the teachings above in Mathew showing the specifics of being able to have specific targeted compilers to compiler the source code and associated environments for execution of the compiled source code, where the environments can include testing type environments and in light of the teachings of Dugan above vehicle type environments and thus together would show being able to compare floating point results from the testing environment compatible compiler execution of the source code and the floating point results from the vehicle driving compatible compiler execution of the source code and determine a comparison result/different where the comparison result is used to indicate a compiler optimization difference between the two compiler results and used to evaluate differences attributable to compiler optimization viewed as type of non-limiting intended use language limitations of the claim language); and
determining the floating-point accuracy of vehicle driving compatible compiler based on the comparison result (Krishnamurthy [0006] lines 11-15, [0027] lines 1-6 and [0045] lines 1-20; which shows being able to determine by comparison of the floating point results and based on the comparison determine that the results are equal, almost equal or not equal viewed as a type of floating point accuracy of the results, which in light of the teachings of Mathew above showing the execution of operations for the different environments with different compilers, that in light of the teachings of Dugan shows the specifics of a vehicle type compiler can together be viewed as showing being able to determine the floating point accuracy of vehicle driving compatible compiler based on the results ).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate the teachings of Krishnamurthy showing the ability to compare floating point results from two different processors performing redundant operation to determine how accurate results are to each other, into the having a plurality of different compilers for different target environment to use the same source code information of Mathew as modified by Dugan for the purpose of being able to determine how close results are from two different environment processing information and if they can be viewed as equal or not and thus helping to ensure reliability of data between different systems, at taught by Krishnamurthy [0022] lines 1-10 and [0045] lines 12-20.
As to claims 3, 10 and 17, Mathew discloses executing the first target language computer code a plurality of vehicle driving compatible processors (Mathew Col. 2 lines 49-58, Col. 3 lines 1-11, Col. 5 lines 39-46 and Col. 14 lines 38-44; which shows for each environment, of a plurality of environment, being able to execute the code with its specific environment and produce/provide results associated with that code that can be processed by specific resources including processor resources including a plurality of processors for the environment, where the specifics of a processor being for a vehicle environment, viewed as a vehicle driving compatible processor is seen in the specific teachings of Dugan below);
executing the second target language computer code by a plurality of testing environment compatible processors (Mathew Col. 2 lines 49-58, Col. 3 lines 1-11, Col. 5 lines 39-46, Col. 11 lines 6-11 and Col. 14 lines 38-44; which shows for each environment, of the plurality of environment, being able to execute the code with its specific environment and produce/provide results which can be processed by specific resources including plurality of processors where and environment can be viewed as a testing environment).
Mather does not specifically disclose the specifics of executing by a plurality of vehicle driving compatible processors.
However, Dugan disclose the specifics of executing by a plurality of vehicle driving compatible processors (Dugan [0031] lines 1-6 and [0032] lines 7-20; which shows that the code can be compiled to run on a device/environment which can include a vehicle device thus viewed as a type of vehicle driving compatible compiler for a vehicle driving application/function and that the compiled code can also run on a heterogenous combination of processors and processor architecture thus plurality of vehicle driving compatible processor, thus in light of the teachings of Mathew above showing the specifics of compiling code with different compiler for different environments that can include a testing environment and executing that code in specifically targeted environment with specific resources can together be seen as showing executing the code compiled to a specific language/target environment that can be viewed as including vehicle driving environment with a plurality of vehicle driving compatible processors).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate the teachings of Dugan showing the specifics of having different devices/environments that implement code with different processor architecture into the plurality of environment with different compilers for code of Mathew for the purpose of increasing the ease of use of instructions so they are adaptable to run on a plurality of different environments with different processing architecture, as taught by Dugan [0032] lines 7-20.
Mather as modified by Dugan do not specifically disclose executing a plurality of floating point operations by a plurality of vehicle driving compatible processors to provide the first floating point result, and executing the plurality of floating point operations by a plurality of testing environment compatible processors to provide the second floating point results; and determining the floating point accuracy comprises determining that an order of execution of the addition-type floating point operation of the first target language computer code differs from an order of execution of the addition-type floating-point operations of the second target language computer code.
However, Krishnamurthy discloses the specifics of executing a plurality of floating point operations by a plurality of vehicle driving compatible processors to provide the first floating point result, and executing the plurality of floating point operations by a plurality of testing environment compatible processors to provide the second floating point results; and determining the floating point accuracy comprises determining that an order of execution of the addition-type floating point operation of the first target language computer code differs from an order of execution of the addition-type floating-point operations of the second target language computer code (Krishnamurthy [0006] lines 11-15, [0027] lines 1-6, [0045] lines 1-21, [0049] lines 1-16 and [0051] lines 1-6; which shows the execution of the code in two different environment where the operations executed in the environment include redundantly/the same operation performed in the first and second environment, where operations can include floating point value operations that can include floating point addition and being able to compare the generate floating point results from the operation and determine based on comparison if values are equal, almost equal or not equal viewed as type of determined floating point accuracy where even with the redundant operations performed the execution in different environment can cause a difference in the order of operations of the floating point operations can cause errors from different order of execution computations that would be identified/determined from the comparison of the floating point results to determine equal, almost equal or not equal viewed as a type of floating point accuracy determination based on the different order of operation execution creating a difference, as based on the non-associated nature of the addition floating point operation a difference indicates that the order of execution difference between the two floating point addition operations where in light of the teachings of , which in light of the teachings of Mathew above showing the execution of the source code operations in the different environments with plurality of processors in the environments where the environments include a testing environment, that in light of the teachings of Dugan shows the specifics of a vehicle type environment can together be viewed as showing the specifics of executing a plurality of floating point operations by a plurality of vehicle driving compatible processors to provide the first floating point result, and executing the plurality of floating point operations by a plurality of testing environment compatible processors to provide the second floating point results; and determining the floating point accuracy comprises determining that an order of execution of the addition-type floating point operation of the first target language computer code differs from an order of execution of the addition-type floating-point operations of the second target language computer code).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate the teachings of Krishnamurthy showing the ability to compare floating point results from two different processors performing redundant operation to determine how accurate results are to each other, into the having a plurality of different compilers for different target environment to use the same source code information of Mathew as modified by Dugan for the purpose of being able to determine how close results are from two different environment processing information and if they can be viewed as equal or not and thus helping to ensure reliability of data between different systems, at taught by Krishnamurthy [0022] lines 1-10 and [0045] lines 12-20.
Claims 2, 9 and 16 re rejected under 35 U.S.C. 103 as being unpatentable over Mathew, Dugan and Krishnamurthy as applied to claims 1, 8 and 15 above, and further in view of Ogrinz (Pub. No. US 2015/0293952 A1).
As to claims 2, 9 and 16, Mathew as modified by Dugan, and Krishnamurthy do not specifically disclose wherein the memory comprises instructions for determining that the vehicle driving compatible compiler has an inadequate floating-point accuracy when the first floating point result differs from the second floating point result.
However, Ogrinz discloses wherein the memory comprises instructions for determining that the vehicle driving compatible compiler has an inadequate floating-point accuracy when the first floating point result differs from the second floating point result (Ogrinz [0006] lines 1-8 and [0007] lines 6-30; which shows as part of the comparison between a test/development environment and a production environment being able to determine a difference between the information and if greater than a threshold value, such that errors would be generated in one environment but not the other thus viewed as having a type of inadequate accuracy issue with one environment, where the specific teachings of Krishnamurthy above show that the performing specific floating point comparison between results from two environments to determine the difference where the teachings of Mathew above show the specifics of the two different environment having two different compilers that in light of the teachings of Dugan above show the specifics of the vehicle type compiler and thus together would show determining that the vehicle driving compatible compiler has an inadequate floating-point accuracy when the first floating point result differs from the second floating point result).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate the teachings of Ogrinz showing the determining an inaccuracy comparison into the floating point comparison of Mathew as modified by Dugan, and Krishnamurthy for the purpose of being further increasing the customization of the comparison by being able to determine if a comparison of data is similar enough/accurate enough results based on a threshold level thus having some level of specification an leeway of possible differences in the results depending on how accurate comparison is desired to by, as taught by Ogrinz [0007] lines 6-30.
Claims 4, 11 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Mathew, Dugan, and Krishnamurthy as applied to claims 1, 8 and 15 above, and further in view of Chiosi et al. (Pub. No. US 2016/0062746 A1).
As to claims 4, 11 and 18, Mathew as modified by Dugan, and Krishnamurthy do not specifically disclose wherein the testing environment compatible compiler is independently developed from the vehicle driving compatible compiler.
However, Chiosi discloses wherein the testing environment compatible compiler is independently developed from the vehicle driving compatible compiler (Chiosi [0013] lines 9-13; which shows being able to independently develop compilers independent of the network/environment, where in light of the teachings of Mathew above showing the specifics of the plurality of environments with different compilers that can include testing environment and the teachings of Dugan above showing the specifics of a vehicle environment with a vehicle compiler thus together can be viewed that each of the compilers, including testing and vehicle associated compilers, are development independently in regards to the network/environment and thus independent of each other).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate the teachings of Chiosi showing the independently development of compiler, into the compiler environment of Mathew as modified by Dugan, and Krishnamurthy for the purpose of increasing the optimization of the functions of a compiler independent of specific network/environment information, as taught by Chiosi [0013] lines 9-13.
Claims 5, 12 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Mathew, Dugan, and Krishnamurthy as applied to claims 1, 8 and 15 above, and further in view of Trim et al. (Pub. No. US 2020/0365044 A1).
As to claims 5, 12 and 19, Mathew as modified by Dugan, and Krishnamurthy do not specifically disclose wherein the one or more testing environment compatible processors are better fit to execute distributed processing than the one or more vehicle driving compatible processors.
However, Trim discloses wherein the one or more testing environment compatible processors are better fit to execute distributed processing than the one or more vehicle driving compatible processors (Trim [0075] lines 10-24; which shows that in two different type processor system able to have one processor that is better perform critical analysis as part of an on-site device that is able to maximize distributed processing power and thus viewed as a better fit to execute distributed processing, thus in light of the teaching disclosed above in Mathew and Dugan above showing the plurality of different environments including different processors with the environments being able to be testing and vehicle environments can be viewed together as showing the specific processor on site device, viewed as testing processor, being better able to execute distributed processing that other associated processor, viewed as vehicle processor).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate the teachings of Trim showing processors better able to perform distributed processing, into the processing system of Mathew as modified by Dugan, and Krishnamurthy for the purpose of being able customize processor performance by having processors that are better able to minimize delays and maximize distributed processing power, as taught by Trim [0075] lines 10-24.
Claims 6, 13 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Mathew, Dugan, and Krishnamurthy as applied to claims 1, 8 and 15 above, and further in view of Yang et al. (Pub. No. US 2020/0137580 A1).
As to claims 6, 13 and 20, Mathew discloses wherein the one or more testing environment compatible processors are general purpose processors (Mathew Col. 2 lines 49-58, Col. 3 lines 1-11, Col. 5 lines 39-46 and Col. 11 lines 6-11; which shows that the computer resources that process/execute the task that can include the task associated with testing, viewed as the testing environment, include processors that are viewed as generic/general purpose processors as it can be a processor the can run/perform a plurality of task/processes thus viewed as a type of general purpose processor ).
Mathew as modified by Dugan, and Krishnamurthy do not specifically disclose wherein the one or more vehicle driving compatible processors are at least one of: autonomous driving hardware accelerators and driver assistant hardware accelerators.
However, Yang disclose wherein the one or more vehicle driving compatible processors are at least one of: autonomous driving hardware accelerators and driver assistant hardware accelerators (Yang [0035] lines 14-24; which shows how a processor can include hardware accelerator that can accelerate function pertaining to autonomous driving thus viewed as a vehicle processor can be autonomous driving hardware accelerators, where it is seen specifically disclosed in Dugan above the specifics of a vehicle device associated with the processing environment processor thus viewed together as showing the one or more vehicle driving compatible processors are an autonomous driving hardware accelerators).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate the teachings of Yang showing the vehicle processor can include autonomous driving hardware accelerators processors into the vehicle processors of Mathew as modified by Dugan, and Krishnamurthy for the purpose of increasing the efficiency of processing by being able to accelerate certain processing functions, as taught by Yang [0035] lines 14-24.
Claims 7, 14 and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Mathew, Dugan, and Krishnamurthy as applied to claims 1, 8 and 5 above, and further in view of Mandava et al. (Patent No. US 10,289,409 B2) and further in view of Bendapudi et al. (Pub. No. US 2007/0250814 A1).
As to claims 7, 14 and 21 Mathew as modified by Dugan, and Krishnamurthy do not specifically disclose wherein the evaluating of the floating point accuracy is preceded by (a) validating the high-level computer code using a testing environment that executes the second target language computer code, (b) following a successful validation, executing the first target language computer code by multiple vehicle driving compatible processors; and (c) finding a floating point failure of the second target language computer code.
However, Mandava disclose wherein the evaluating of the floating point accuracy is preceded by (a) validating the high-level computer code using a testing environment that executes the second target language computer code, (b) following a successful validation, executing the first target language computer code by multiple vehicle driving compatible processors (Mandava Col. 9 line 64- Col. 10 line 4, Col. 13 lines 8-10 and claim 1; which is able to show being able to execute in the test environment testing code projects/test cases and validate/testing the testing code projects, then after validation/testing the code being able to use the code in a different target environment, which in light of the teachings of Mathew above showing the plurality of different environments with specific resources for executing the high level source code/program that can include testing environment and other environment being targeted thus the generations of first and second target language computer code and as seen in Dugan above the specifics of a vehicle environment can be seen together as showing the execution of the comparable code in the testing environment and after validation is performed in the test environment sending/using that same source code but in the second/different production environment, thus viewed as the first target language code, used/executed by the plurality of vehicle compatible processors associated with a vehicle environment)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate the teachings of Mandava showing the validation code validation, into the code testing environment of Mathew as modified by Dugan, and Krishnamurthy for the purpose of helping to ensure correctness of testing code by making sure to validate the testing code to make sure all testing have been run and no defects/errors are still open before running in another environment, as taught by Mandava Col. 4 lines 63-66.
Mathew as modified by Dugan, Krishnamurthy and Mandava do not specifically disclose (c) finding a floating point failure of the second target language computer code.
However, Bendapudi discloses finding a floating point failure of the second target language computer code (Bendapudi [0009] lines 1-6; which shows that software components can raise issues with encounter abnormal conditions, viewed as determination/find an issues that can include a floating point error/failure, thus in light of the teachings seen specifically disclosed in Mathew above showing the specifics of the second target langue computer code can be viewed together as being able to find/determine where the second target language compute code/software encounters a floating point error/failure condition).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate the teachings of Bendapudi showing the specifics being able to find/determine floating point failure conditions into the performing of floating point operations of Mathew as modified by Dugan, Krishnamurthy and Mandava for the purpose of increasing the correct functionality of code by being able to notify/raise exception when an abnormal condition is encounter thus being able to handle those issue and help prevent them from happening if needed, as taught by Bendapudi [0009] line 1-8.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BRADFORD F WHEATON whose telephone number is (571)270-1779. The examiner can normally be reached Monday-Friday 8:00-5:00 EST.
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, Chat Do can be reached at 571-272-3721. 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.
/BRADFORD F WHEATON/Examiner, Art Unit 2193