DETAILED ACTION
This action is in response to the application on 7/26/2024.
Claims 1-8 are pending in this application.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Objections
Claims 5 is objected to because of the following informalities:
Claim 5, at line 3, “whether an overflow flag is set” should be -- whether the overflow flag is set--.
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 7 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 7 is directed to “test arrangement”. However, the body of the claim does not recite any element to be considered as a part of the claimed arrangement. Thus, it is not clear what the claimed test arrangement is comprised of. Therefore, the claim is indefinite.
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, 7, and 8 are rejected under 35 U.S.C. 103 as being unpatentable over Grover (US Patent Application Publication 2021/0286702 A1) in view of Thiagarajan et al. (US Patent Application Publication 2006/0080578 A1).
As to claim 1, Grover teaches a method for testing a computer program (see Fig.1 and associated text. e.g. [0011]- method 100 of debugging code using thread patterns relative to multiple instances of execution of the code), comprising the following steps:
setting one or more breakpoints on one or more respective arithmetic or bit-shifting operations (e.g. operating system threads) in the computer program (e.g. first instance of code, [0019]- the user can set a breakpoint for the variance or any thread at any time and [0020]- a breakpoint may be set by the user relative to any thread(s) identified in the thread patterns, either at the beginning or end of the thread (or both), and for either one or both of the first and second instances of the code),
executing the computer program (see e.g. [0018]- In the initial stages of this debugging process, each thread pattern may only include one or two threads, but as debugging continues, each thread pattern may contain a plurality of threads relative to each of the first and second instances of execution),
when one of the set breakpoints is triggered, triggering a display that the computer program has an error (see e.g. Fig.4 and associated text, e.g. [0036]- Breakpoints may be set in the code debugging manager 310 to break at each thread identified, and/or at the variance, to assist in identifying possible areas within the code that may be problematic and [0037]- If an execution failure is detected 408 (e.g., an error is generated, such as a lockup, thrown exception, crash, memory fault, missing command, communication error, control flow, display error, stack overflow), such error may facilitate identifying the problem thread pattern V2 relative to the thread pattern V1 that had no execution error; when a variance is detected, a screen shot of the application may be captured and presented as part of the context information (e.g., the data returned from the server in a client/server context around the time of the thread variance).
Although Grover teaches that the computer program has an error (e.g. execution failure such as stack overflow, see e.g. [0037]), Grover does not specifically teach ascertaining whether an overflow flag is set by executing the respective arithmetic or bit-shifting operation and triggering a display in response to ascertaining that the overflow flag is set as a result of the respective arithmetic or bit-shifting operation.
In an analogous art of testing software, however, Thiagarajan teaches ascertaining whether an overflow flag is set (e.g. integer overflow detected) by executing a respective arithmetic or bit-shifting operation (see e.g. Figs. 1 and 2 and associated text, e.g. [0030]- When arithmetic operations on integer values yield new values that cannot be represented in the range of the type, a phenomenon called an "integer anomaly" can result. Two possible integer anomalies include integer overflows and integer underflows, [0032]- Generally, an integer overflow occurs when data resulting from input or processing requires more bits that have been provided in hardware or software to store the data and [0046]- At 230, the defect detection tool performs an instruction-level analysis of the program instructions to determine if there are programming defects in the program instructions) and triggering a display in response to ascertaining that the overflow flag is set as a result of the respective arithmetic or bit-shifting operation (See e.g. [0047]- At 250, a report is provided as output that details what, if any, programming defects were discovered in the program instructions. For example, the report can indicate how many potential integer anomalies (e.g., overflows or underflows) were detected, and where they are located in the program instructions).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified the method of Grover to incorporate/implement the limitations as taught by Thiagarajan in order to provide a more efficient method/system of detecting programming defects for the purpose of producing more reliable and secure software.
As to claim 7, the limitations of the claims are substantially similar to the limitations of claim 1, and therefore, it is rejected for the reasons stated above.
As to claim 8, the limitations of the claims are substantially similar to the limitations of claim 1, and therefore, it is rejected for the reasons stated above.
Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over Grover (US Patent Application Publication 2021/0286702 A1) in view of Thiagarajan et al. (US Patent Application Publication 2006/0080578 A1), as applied to claim 1 above, and further in view of Sarcar (US Patent Application Publication 2004/0143824 A1).
As to claim 3, Grover in view of Thiagarajan teaches triggering of the display that the computer program has an error as a result of the respective arithmetic or bit-shifting operation (See e.g. Grover: [0020] and [0037]), but does not specifically teach triggering a termination of the computer program in response to ascertaining that the overflow flag is set.
In an analogous art of debugging software, however, Sarcar teaches triggering a termination of a computer program in response to ascertaining that the overflow flag is set (e.g. stack overflow condition exists, see e.g. [0011]- the system halts execution of the operating system if a stack overflow condition exists).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified the method of Grover in view of Thiagarajan to incorporate/implement the limitations as taught by Sarcar in order to provide a more efficient method/system of debugging software for the purpose of performance tuning.
Claims 5 and 6 are rejected under 35 U.S.C. 103 as being unpatentable over Grover (US Patent Application Publication 2021/0286702 A1) in view of Thiagarajan et al. (US Patent Application Publication 2006/0080578 A1), as applied to claim 1, and further in view of Patel et al. (US Patent Application Publication 2019/0310318 A1).
As to claim 5, Grover in view of Thiagarajan teaches the setting of the breakpoints (See Grover: [0019]) , the ascertaining as to whether an overflow flag is set (see Thiagarajan: [0032] and [0046]), and the triggering of the display that the computer program has an error (See Grover: [0037]), but does not specifically teach wherein the computer program is executed on an embedded system or via a test system connected to the embedded system.
In an analogous art of debugging software, however, Patel teaches wherein a computer program is executed on an embedded system (See e.g. Fig.2 and associated text, e.g. [0052]- The DUT may be any of a variety of electronic devices for which a measurement function is desirable. It should be noted that a DUT may be any of various types of computer systems devices which are mobile or portable and which performs wireless communications, such as mobile wireless devices. Examples of DUTs include mobile telephones (e.g., cellular telephones (“cell phones”) or smart phones, portable gaming devices, laptops, tablets, PDAs, portable Internet devices, music players, data storage devices, or other handheld devices, etc. In general, the term “UE” or “UE device” can be broadly defined to encompass any electronic, computing, and/or telecommunications device (or combination of devices) which is easily transported by a user and capable of wireless communication) and a test system connected to the embedded system (See Fig.2 and associated text, e.g. [0052]- A computer 82 may be used by a user to conduct the measurement process and may be connected to a network and to the measurement apparatus. Software 104 may be installed on the computer to conduct the delay measurement process (e.g., using one or more software interfaces).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified the method of Grover in view of Thiagarajan to incorporate/implement the limitations as taught by Patel in order to provide a more efficient method/system of testing and debugging various devices in a more timely manner.
As to claim 6, Patel further teaches wherein the computer program is a control program for a robotic device (see e.g. [0043]- measurement device includes instruments, data acquisition devices, smart sensors, and any of various types of devices that are operable to acquire and/or store data from a DUT; Examples of a measurement device include a robot having machine vision) and the robotic device is controlled with the computer program depending on a result of the test of the computer program (see e.g. [0044]- A measurement device may be further operable to perform control functions, e.g., in response to analysis of the acquired or stored data. For example, the measurement device may send a control signal to an external system, such as a motion control system or to a sensor, in response to particular data. A measurement device may also be operable to perform automation functions, i.e., may receive and analyze data, and issue automation control signals in response).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified the method of Grover in view of Thiagarajan to incorporate/implement the limitations as taught by Patel in order to provide a more efficient method/system of testing and debugging various devices in a more timely manner.
Allowable Subject Matter
Claims 2 and 4 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Barsness et al. (US Patent Application Publication 2018/0210813 A1) discloses a method for debugging an executable that includes receiving one or more breakpoints related to a call stack in the executable.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHENECA SMITH whose telephone number is (571)270-1651. The examiner can normally be reached Mon-Fri 8:00AM-4:30PM 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, Hyung S Sough can be reached at 571-272-6799. 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.
/CHENECA SMITH/Examiner, Art Unit 2192
/S. Sough/SPE, Art Unit 2192
Prosecution Insights