DETAILED ACTION
This action is responsive to the application filed on September 23, 2024.
Claims 1-9 are pending and presented to examination.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Examiner Notes
Examiner cites particular columns, paragraphs, figures and line numbers in the references as applied to the claims below 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 or disclosed by the examiner.
Foreign Priority
The foreign priority date considered for this application is October 09, 2023.
Drawings
The drawings filed on September 23, 2024 are acceptable for examination purposes.
Specification
Applicant is reminded of the proper language and format for an abstract of the disclosure.
The abstract should be in narrative form and generally limited to a single paragraph on a separate sheet within the range of 50 to 150 words in length. The abstract should describe the disclosure sufficiently to assist readers in deciding whether there is a need for consulting the full patent text for details.
The language should be clear and concise and should not repeat information given in the title. It should avoid using phrases which can be implied, such as, “The disclosure concerns,” “The disclosure defined by this invention,” “The disclosure describes,” etc. In addition, the form and legal phraseology often used in patent claims, such as “means” and “said,” should be avoided.
The abstract of the disclosure is objected to under 37 CFR 1.72(b) and MPEP § 608.01(b) for the following reasons:
(1) The abstract uses legal phraseology. Specifically, the recitation "a bytecode representation thereof" employs a legalistic term of the type that should be avoided in an abstract (see MPEP § 608.01(b), directing that the abstract avoid legal phraseology such as "said," "means," and similar terms).
(2) The abstract is set out in claim format and recites claim language rather than presenting a concise narrative statement of the technical disclosure. The abstract reproduces the preamble and the method steps of claim 1 in a "preamble — the method includes: — semicolon-delimited step" format, and carries over claim constructs such as "at least one," "a respective," and "the at least two threads." The abstract should be a concise statement, in narrative form, of the technical disclosure, and should not be a recitation of the claim language.
The following replacement abstract is suggested:
“A memory access error in a multi-threaded application is detected by converting the application to a bytecode representation and profiling the bytecode representation to determine a shared memory access point accessed by two or more threads. A delay is injected into a memory access operation to the shared memory access point by one thread, and accesses to the shared memory access point are monitored during the delay to detect the memory access error. A computer program, apparatus, and storage medium are also described.” A corrected abstract of the disclosure is required and must be presented on a separate sheet, apart from any other text. See MPEP § 608.01(b).
Claim Objections
Claims 1-9 are objected to because of the following informalities:
Claim 1 (and similar for claims 8-9) recites the limitation “injecting a delay time frame into a respective memory access operation to the shared memory access point by at least one thread of the at least two threads; and”. Please add “and” at the end of the limitation as indicated in bold. Appropriate correction is required.
Dependent claims 2-7 do not overcome the deficiency of the base claim and, therefore, are objected for the same reasons as the base claim.
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.
Claims 1-9 are 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.
Claims 1 and 8-9 first recites “at least one shared memory access point,” and thereafter recites, in the injecting and monitoring limitations, “the shared memory access point” in the singular definite form. The recitation “the shared memory access point” lacks proper antecedent basis, because the element previously introduced is “at least one shared memory access point,” which encompasses a plurality. It is therefore unclear whether the delay is injected into, and the accesses monitored at, every shared memory access point so determined or only one of them. For purposes of examination, “the shared memory access point” is interpreted as “the at least one shared memory access point.” Appropriate correction is required.
Claim 2 recites “performing a static analysis of a source code of the bytecode representation.” It is unclear what is meant by “a source code of the bytecode representation,” because claim 1 recites converting the multi-threaded application to a bytecode representation, and a bytecode representation is the product of such a conversion rather than a thing that itself has “source code.” It is therefore unclear whether the recited “source code” refers to (i) the source code of the multi-threaded application from which the bytecode representation was converted, or (ii) a textual or disassembled form of the bytecode representation itself. For purposes of examination, the limitation is interpreted as encompassing either. Appropriate correction is required.
Claim 7 recites “the at least one determined shared memory access point.” This recitation lacks proper antecedent basis, because claim 1 introduces only “at least one shared memory access point” and does not recite a “determined” shared memory access point. For purposes of examination, the limitation is interpreted as referring to the “at least one shared memory access point” determined by the profiling step of claim 1. Appropriate correction is required. Claim 8 recites “A data processing apparatus configured to detect a memory access error in a multi-threaded application, the device configured to:” in lines 1-3. The limitation “the device” lacks proper antecedent basis. Claim 8 introduces “a data processing apparatus,” but thereafter refers to “the device,” rendering it unclear whether “the device” refers to the previously recited “data processing apparatus” or to some other, separately introduced element. For purposes of examination, “the device” is interpreted as referring to the previously recited “data processing apparatus.” Appropriate correction (e.g., amending “the device” to recite “the data processing apparatus”) is required. Claims 3-6 are rejected for the same reason by virtue o their dependency from claim 1.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claim 8 is rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. Claim 8 recites “A data processing apparatus configured to detect a memory access error in a multi-threaded application, the device configured to:” convert the multi-threaded application to a bytecode representation, profile the bytecode representation to determine at least one shared memory access point, inject a delay time frame into a respective memory access operation, and monitor accesses during the delay time frame to detect the memory access error. Claim 8 does not positively recite any hardware or physical structure—no processor, memory, circuitry, or other physical component is recited. The recited “data processing apparatus” and “device” are claimed solely in terms of the software functions they are “configured to” perform (converting, profiling, injecting, and monitoring).
Accordingly, under its broadest reasonable interpretation, claim 8 encompasses software per se—functional logic or instructions not embodied in or tied to any physical apparatus—which does not fall within any of the four statutory categories of 35 U.S.C. 101 (process, machine, manufacture, or composition of matter). See MPEP 2106.03. Claim 8 is therefore directed to non-statutory subject matter and is rejected under 35 U.S.C. 101.
To overcome this rejection, applicant may amend claim 8 to positively recite hardware—for example, “a processor and a non-transitory computer-readable memory storing instructions that, when executed by the processor, cause the data processing apparatus to:” perform the recited converting, profiling, injecting, and monitoring operations.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 3 and 6-9 are rejected under 35 U.S.C. 103 as being unpatentable over John Erickson et al. (“Effective Data-Race Detection for the Kernel”, hereinafter “Erickson”) in view of Daniel Lehmann et al. (“Wasabi: A Framework for Dynamically Analyzing WebAssembly”, hereinafter “Lehmann”).
With respect to claim 1, Erickson teaches a method for detecting a memory access error in a multi-threaded application (Erickson discloses “DataCollider, a lightweight and effective technique for dynamically detecting data races in kernel modules” (Abstract, page 1); a data race is a memory access error arising between threads of a multi-threaded program), comprising the following steps: profiling [[the bytecode representation]] to determine at least one shared memory access point by at least two threads [[of the bytecode representation]] (Erickson samples a memory access at random and then detects whether a second thread accesses the same location: “Right before a read or write access to shared memory location, chosen at random, DataCollider monitors for any concurrent accesses that conflict with the current access” (Fig. 2 caption, page 2); see also section 3.2, page 7: “DataCollider pauses the current thread waiting to see if another thread makes a conflicting access to the same memory location.” A location accessed by two different threads, at least one access being a write, is a shared memory access point accessed by at least two threads). injecting a delay time frame into a respective memory access operation to the shared memory access point by at least one thread of the at least two threads (Erickson section 3.2.3, page 8: “For a sampled memory access, DataCollider attempts to detect a conflicting access to the same memory location by delaying the thread for a short amount of time”; see also Fig. 2, page 2, in which the DetectConflicts routine executes “delay()” at the sampled access location). monitoring accesses of the at least two threads to the shared memory access point during the delay time frame to detect the memory access error (Erickson section 3.2.1, page 7, and Fig. 2, page 2: during the delay, DataCollider sets a data breakpoint that traps a conflicting access by another thread and additionally performs a repeated read—“temp = read(loc,size); … delay(); … temp′ = read(loc,size); if(temp != temp′ || data breakpoint fired) ReportDataRace()”—thereby monitoring for an access by another thread to the same location during the delay window and reporting a detected data race).
Erickson is silent to disclose, however, in an analogous art, Lehmann teaches: converting the multi-threaded application to a bytecode representation of the multi-threaded application; the bycode representation (Lehmann discloses WebAssembly as “a new, low-level binary instruction format” that is “a compilation target for systems programming languages like C, C++, or Rust” (section 1, page 1045), and that Wasabi operates by “binary instrumentation, which inserts calls to analysis functions … into a WebAssembly binary” (Abstract, page 1045; section 2.1, page 1047); compiling the multi-threaded application to a WebAssembly binary is converting it to a bytecode representation thereof). Lehmann further teaches the bytecode representation itself because the WebAssembly binary that Lehmann produces and instruments is the bytecode representation upon which the dynamic analysis is performed (section 2.1, page 1047; section 4.2, page 1053). Accordingly, the bytecode representation recited in the profiling, injecting, and monitoring limitations above is taught by and credited to Lehmann, while Erickson supplies only the underlying detection acts—profiling to determine a shared access point, injecting the delay, and monitoring during the delay—which, in the combination, are performed upon Lehmann’s bytecode representation.
It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to perform the data-race detection technique of Erickson upon a bytecode representation of the application as taught by Lehmann. One of ordinary skill would have been motivated to do so to obtain the portability and low-overhead benefits expressly recited by Lehmann—namely, that binary instrumentation of WebAssembly is “independent of the execution platform that WebAssembly runs on” (section 2.1, page 1047), is “portable across different vendors, architectures, and devices” (section 1, page 1045), and reduces overhead through “selective instrumentation” that instruments “only those instructions that are relevant for a particular analysis” (section 2.1, page 1046). The combination amounts to applying a known data-race detection technique (Erickson) to a known bytecode-instrumentation platform (Lehmann) to yield the predictable result of portable, low-overhead data-race detection. With respect to claim 3, Erickson teaches identifying a respective memory access point as the at least one shared memory access point when the respective memory access point is accessed from at least two different threads [[of the bytecode representation]] during the execution (Erickson identifies a shared/conflicting memory access point at runtime when a second thread accesses the same location during execution: “… DataCollider monitors for any concurrent accesses that conflict with the current access” (Fig. 2 caption, page 2); a location accessed by two different threads is reported as a conflicting (shared) access (section 3.2, page 7)).
Erickson is silent to disclose, however, in an analogous art, Lehmann teaches: modifying the bytecode representation to log memory accesses during an execution of the bytecode representation (Lehmann instruments—i.e., modifies—the WebAssembly binary to insert hooks that record memory accesses at runtime: the static-instrumentation phase “augments the given WebAssembly binary with instructions that call into the analysis implementation” (section 2.1, pages 1047), and the Memory Access Tracing analysis “tracks all memory accesses and stores them” (section 4.2, page 1053; Table 4, page 1053, listing the “load, store” hooks)). Lehmann thereby supplies the bytecode representation upon which the identifying of the shared access point (mapped to Erickson above) is performed).
It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to perform the data-race detection technique of Erickson upon a bytecode representation of the application as taught by Lehmann. One of ordinary skill would have been motivated to do so to obtain the portability and low-overhead benefits expressly recited by Lehmann—namely, that binary instrumentation of WebAssembly is “independent of the execution platform that WebAssembly runs on” (section 2.1, page 3), is “portable across different vendors, architectures, and devices” (section 1, page 1), and reduces overhead through “selective instrumentation” that instruments “only those instructions that are relevant for a particular analysis” (section 2.1, page 2). The combination amounts to applying a known data-race detection technique (Erickson) to a known bytecode-instrumentation platform (Lehmann) to yield the predictable result of portable, low-overhead data-race detection. With respect to claim 6, Erickson teaches sampling at least one random subset of instructions [[of the bytecode representation]] (Erickson samples a random subset of memory-access instructions: “DataCollider randomly samples a small percentage of memory accesses as candidates for data-race detection” (Abstract, page 1), where “the initial breakpoints are set at a small number of program locations chosen uniformly randomly from the sampling set” (section 3.1.1, page 6)). executing [[the bytecode representation]] based on the sampled at least one random subset of instructions (Erickson executes the program with code breakpoints set on the randomly sampled subset of memory-access instructions and performs conflict detection only for those sampled accesses: “If and when a code breakpoint fires, DataCollider performs conflict detection for the memory access at that breakpoint” (section 3.1.1, page 6). The credit language reads coherently as “executing… based on the sampled at least one random subset instructions,” the bracketed object being supplied by Lehmann below ).
Erickson is silent to disclose, however, in an analogous art, Lehmann teaches the bytecode representation (the WebAssembly binary that Lehmann produces and instruments is the bytecode representation—“a new, low-level binary instruction format” and “a compilation target for systems programming languages like C, C++, or Rust” (section 1, page 1045), instrumented as “a WebAssembly binary” (Abstract, page 1045; section 2.1, page 1047)).
It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to perform the data-race detection technique of Erickson upon a bytecode representation of the application as taught by Lehmann. One of ordinary skill would have been motivated to do so to obtain the portability and low-overhead benefits expressly recited by Lehmann—namely, that binary instrumentation of WebAssembly is “independent of the execution platform that WebAssembly runs on” (section 2.1, page 3), is “portable across different vendors, architectures, and devices” (section 1, page 1), and reduces overhead through “selective instrumentation” that instruments “only those instructions that are relevant for a particular analysis” (section 2.1, page 2). The combination amounts to applying a known data-race detection technique (Erickson) to a known bytecode-instrumentation platform (Lehmann) to yield the predictable result of portable, low-overhead data-race detection. With respect to claim 7, Erickson teaches eliminating at least one memory access operation [[of the bytecode representation]] that is not accessing the at least one determined shared memory access point (Erickson removes from consideration memory-access operations that do not touch shared locations: “DataCollider performs a simple static analysis to identify instructions that are guaranteed to only touch thread-local stack locations and removes them from the sampling set” (section 3.1.1, page 6); a thread-local access is an access that is not accessing a shared memory access point, and such accesses are eliminated).
Erickson is silent to disclose, however, in an analogous art, Lehmann teaches the bytecode representation (the WebAssembly binary that Lehmann produces and instruments is the bytecode representation—“a new, low-level binary instruction format” and “a compilation target for systems programming languages like C, C++, or Rust” (section 1, page 1045), instrumented as “a WebAssembly binary” (Abstract, page 1045; section 2.1, page 1047)).
It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to perform the data-race detection technique of Erickson upon a bytecode representation of the application as taught by Lehmann. One of ordinary skill would have been motivated to do so to obtain the portability and low-overhead benefits expressly recited by Lehmann—namely, that binary instrumentation of WebAssembly is “independent of the execution platform that WebAssembly runs on” (section 2.1, page 3), is “portable across different vendors, architectures, and devices” (section 1, page 1), and reduces overhead through “selective instrumentation” that instruments “only those instructions that are relevant for a particular analysis” (section 2.1, page 2). The combination amounts to applying a known data-race detection technique (Erickson) to a known bytecode-instrumentation platform (Lehmann) to yield the predictable result of portable, low-overhead data-race detection. With respect to claim 8, claim 8 recites limitations similar to those of claim 1, in the form of a data processing apparatus, and is rejected for the same reasons set forth above for claim 1. Erickson further teaches a data processing apparatus configured to perform the recited operations (DataCollider is implemented on, and executed by, a data processing apparatus – “the 32-bit Windows kernel running on the x86 architecture” (Abstract, page 1), implemented for “the Windows 7 kernel” (Abstract, page 1) and heavily using “the code and data breakpoint mechanism available on x86” (section 3 page 6).
With respect to claim 9, claim 9 recites limitations similar to those of claim 1, in the form of a non-transitory computer-readable storage medium storing instructions that, when executed by a computer, cause the recited steps to be performed, and is rejected for the same reasons set forth above for claim 1. Erickson teaches that DataCollider is implemented as a program/tool executed by the kernel and processor (section 3), and Lehmann teaches that the Wasabi instrumenter is implemented as stored program code (section 3, page 1052: the Wasabi instrumenter is implemented “in about 5000 lines of Rust code”). A non-transitory computer-readable storage medium storing such instructions is therefore taught by the combination).
Claim 2 is rejected under 35 U.S.C. 103 as being unpatentable over John Erickson et al. (“Effective Data-Race Detection for the Kernel”, hereinafter “Erickson”) in view of Daniel Lehmann et al. (“Wasabi: A Framework for Dynamically Analyzing WebAssembly”, hereinafter “Lehmann”) and further in view of Chen et al. (US Pub. No. 2017/0161073, hereinafter “Chen”).
With respect to claim 2, Erickson is silent to disclose performing a static analysis of a source code of the bytecode representation to determine the at least one shared memory access point. Although Erickson performs “a simple static analysis” (section 3.1.1, p. 6) as noted in the rejection of claim 7 above, that analysis is performed upon a native binary rather than upon a source code, and it identifies instructions that touch only thread-local stack locations so that they may be excluded from the sampling set; it does not analyze a source code to determine the at least one shared memory access point as claimed.
However, in an analogous art (dynamic analysis and instrumentation of multi-threaded software), Lehmann teaches the bytecode representation (the WebAssembly binary that Lehmann produces and instruments is the bytecode representation—“a new, low-level binary instruction format” that is “a compilation target for systems programming languages like C, C++, or Rust” (§ 1, p. 1045), which the static-instrumentation phase “augments … with instructions that call into the analysis implementation” (§ 2.1, p. 1047)). The bracketed term recited in the limitation above is therefore taught by and credited to Lehmann.
It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to perform the static analysis recited in claim 2 with respect to a bytecode representation of the multi-threaded application as taught by Lehmann. One of ordinary skill would have been motivated to do so to obtain the portability and low-overhead benefits Lehmann expressly recites for analyzing the WebAssembly bytecode representation—that such instrumentation is “independent of the execution platform that WebAssembly runs on” (§ 2.1, p. 1047) and “portable across different vendors, architectures, and devices” (§ 1, p. 1045)—thereby permitting the analysis to be applied uniformly across heterogeneous platforms. The combination amounts to applying a known analysis to a known bytecode-instrumentation platform to yield a predictable result, and is therefore obvious under KSR.
Erickson in view of Lehmann is silent to disclose However, in an analogous art (data-race detection in multi-threaded software), Chen teaches performing a static analysis of a source code [[of the bytecode representation]] to determine the at least one shared memory access point (Chen [0019]: “determining the instructions that access the same memory locations can be done statically by analyzing the source code or compiled binary. For programs written in some languages, static analysis can determine these instructions quite accurately.” Statically analyzing the source code to determine the instructions that access the same memory location is performing a static analysis of a source code to determine the at least one shared memory access point; the bracketed term “of the bytecode representation” is not taught by Chen and is supplied by Lehmann as set forth immediately above).
It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to incorporate the static source-code analysis of Chen into the combined method of Erickson and Lehmann to determine the at least one shared memory access point. One of ordinary skill would have been motivated to do so because Chen teaches that determining such instructions statically allows the system to “filter[] out, as early as possible, instructions that would not be part of a data race,” which “results in a smaller set of instructions to rank and choose from” (Chen [0017]), thereby reducing the runtime instrumentation burden and improving the efficiency and accuracy of the detection. Combining Chen’s static pre-determination with the combined method of Erickson and Lehmann yields the predictable result of a reduced candidate set and lower runtime overhead, and is therefore obvious under KSR.
Allowable Subject Matter
Claims 4-5 are rejected under 35 U.S.C. 112(b) by virtue of their dependency from claim 1, as set forth above. Claims 4 and 5 are otherwise objected to as being dependent upon a rejected base claim, but would be allowable over the prior art of record if rewritten in independent form including all of the limitations of the base claim and any intervening claims, and provided that the indefiniteness set forth above is corrected.
The following is a statement of reasons for the indication of allowable subject matter. The prior art of record, alone or in combination, does not teach or reasonably suggest the limitations of claim 4, specifically, that “at least during the monitoring, the bytecode representation is executed on at least two different devices, the at least two different devices being different to one another by at least one performance characteristic”, nor the limitations of claim 5, specifically, that “the modifying of the bytecode representation is performed in accordance with the respective at least one performance characteristic of the at least two different devices.” While the prior art of record teaches dynamic data-race detection performed on a bytecode representation by sampling, delay injection, and monitoring (Erickson; Lehmann), and teaches distributing instrumentation and sampling across multiple deployed machines for statistical aggregation (Jin, which deploys “differently-instrumented executables for different users” across user sites for cooperative bug isolation), the prior art of record does not teach executing the instrumented bytecode representation, during the monitoring, across at least two devices that differ from one another in a performance characteristic (e.g., processing power or network performance) for the purpose of detecting the memory access error, and further does not teach tuning the modification (instrumentation) of the bytecode representation in accordance with the respective performance characteristic of each such device. In particular, Jin apportions instrumentation among sites according to statically defined function groups, not according to any performance characteristic of the executing device, and therefore does not teach or suggest the performance-characteristic-based execution and instrumentation recited in claims 4 and 5. Accordingly, claims 4 and 5 contain allowable subject matter.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Shah et al. (US Pub. No. 2010/0299656) Techniques for generating concurrent static single assignment (CSSA) are provided. The techniques include generating a clocked control flow graph of a program, for each thread of the program created through async instruction, determining each part of the program that can execute concurrently with each thread to create a pair comprising a thread and a parallel program part, for each pair that can execute concurrently, using one or more flow equations to perform node-by-node matching, and using the node-by-node matching to generate CSSA form for the program. (see abstract).
Berg et al. (US Pat. No. 7,398,517) A method and system of detecting vulnerabilities in source code. Source code is parsed into an intermediate representation. Models (e.g., in the form of lattices) are derived for the variables in the code and for the variables and/or expressions used in conjunction with routine calls. The models are then analyzed in conjunction with pre-specified rules about the routines to determine if the routine call posses one or more of pre-selected vulnerabilities. (see abstract).
Erickson et al. (US Pub. No. 2012/0204062) The claimed subject matter provides a method for detecting a data race. The method includes inserting a plurality of breakpoints into a corresponding plurality of program locations. Each of the program locations accesses a plurality of memory locations. Each of the program locations is selected randomly. The method also includes detecting one or more data races for the memory locations in response to one or more of the breakpoints firing. Additionally, the method includes generating a report describing the one or more data races. (see abstract). Any inquiry concerning this communication or earlier communications from the examiner should be directed to ANIBAL RIVERACRUZ whose telephone number is (571)270-1200. The examiner can normally be reached Monday-Friday 9:30 AM-6:00 PM.
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 5712726799. 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.
/ANIBAL RIVERACRUZ/Primary Examiner, Art Unit 2192
Prosecution Insights