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 .
DETAILED ACTION
This is the initial office action based on the application submitted on June 28, 2024.
Claims 1-20 are pending.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Specification
The disclosure is objected to because of the following informalities:
In paragraph [0024], “functions” is labeled as “120a” whereas in the rest of the specification it is labeled as “116”. If this is not an error, 120a must be added to the drawings. Otherwise, correction is required.
In paragraph [0033], “which can be determining using the data structure 120” should be “which can be determined using the data structure 120”.
Appropriate correction is required.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-3, 5-6, 8-10, 12-13, 15-17, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Terashima (Terashima et al., “Static Call Graph Generator for C++ using Debugging Information”, January 07, 2008) in view of Paccapeli (US Patent Application Publication No. US 2024/021126 A1).
Regarding Claim 1, Terashima teaches:
receiving a debugging file in a standardized format as input, the debugging file corresponding to compiled code generated by a compiler subsequent to compiling source code (Fig. 1; Abstract, "We developed a tool, dcgg, that statically generates call graphs for C++ using DWARF2 debugging information based on this method." § 2.2, "Debugging information is information that debuggers need and compilers produce and put into binary files (emphasis added). Typical debugging information includes description about local variables, user defined types, line numbers, scopes, stack frames, and so on. DWARF2 [18] is one of the debugging information formats, which is supported by many compliers (like gcc) and debuggers (like gdb). DWARF2 has many advanced features, and its specification is open to the public (emphasis added)." § 3.1, "dcgg uses readelf+ [10, 9] to extract DWARF2-XML, therefore the target execution file should be ELF format and contain DWARF2 debugging information (emphasis added)." § 3.5, "DWARF2 information has been generated when each object file is created and the linker only overwrites addresses and unites each section (emphasis added).");
determining a set of functions based on the debugging file, the debugging file including one or more attributes corresponding to the set of functions (Fig. 1; § 2.2, "This section is represented as a tree of entries, which is a logical unit of debugging information. Each entry has an entry tag corresponding to a type of information and some attributes (emphasis added). Figure 1 shows an example of the tree structure of entries. In this sample, a compilation unit hello.c contains information about a type int and a function main (emphasis added)." § 3.2, "Overloaded functions are detected without special extensions because each function has a different entry in DWARF2 even though they have the same name (emphasis added).");
══════════════════════════════════════════════
Examiner's Remarks: As illustrated by Terashima’s Fig. 1, a function is represented by a DW_TAG_subprogram entry having corresponding DWARF attributes including DW_AT_name, DW_AT_type, and DW_AT_frame_base.
══════════════════════════════════════════════
subsequent to determining the set of functions, determining, based on the one or more attributes provided in the debugging file, one or more function relations associated with the set of functions (Abstract, "We developed a tool, dcgg, that statically generates call graphs for C++ using DWARF2 debugging information based on this method (emphasis added). We use a combination of a binary analysis and debugging information to detect static function calls (including inline expanded functions) simply and precisely, and also virtual function calls (dynamic function calls in C++)." § 2.3, "The method to detect function calls is like below. 1. Gather all pairs of caller and callee addresses from disassembled codes (emphasis added). 2. Transform each address to a function name with information about address ranges of functions contained by DWARF2. In addition, DWARF2 contains the address ranges of in line expanded functions.");
══════════════════════════════════════════════
Examiner's Remarks: As discussed above, Terashima’s DWARF2 function information is provided through debugging-information entries having attributes. Terashima uses the DWARF2 function/address-range information to associate caller and callee addresses with the corresponding functions, thereby determining function relations.
══════════════════════════════════════════════
generating a data structure mapping each function relation of the one or more function relations to the source code (Abstract, "We developed a tool, dcgg, that statically generates call graphs for C++ using DWARF2 debugging information based on this method (emphasis added). We use a combination of a binary analysis and debugging information to detect static function calls (including inline expanded functions) simply and precisely, and also virtual function calls (dynamic function calls in C++). Virtual function calls are detected by tracing types in registers and the stack. In a preliminary evaluation dcgg generated precise call graphs including inline expansions and virtual function calls (emphasis added). These techniques are important to C++ programmers as they help in creating efficient and maintainable code." § 2.3, "As one of those tools, a static call graph generator for C, called bscg, is developed. bscg generates call graphs using disassembled execution codes and DWARF2-XML. The method to detect function calls is like below. 1. Gather all pairs of caller and callee addresses from disassembled codes. 2. Transform each address to a function name with information about address ranges of functions contained by DWARF2 (emphasis added). In addition, DWARF2 contains the address ranges of inline expanded functions. This information is appended to all expanded code blocks whether the function is specified as inline or not. With this information, it is possible to detect inline expanded function calls and function calls in the expanded codes.");
══════════════════════════════════════════════
Examiner's Remarks: Terashima’s call graph corresponds to the claimed data structure because the call graph represents the determined caller/callee function relations, with the functions identified using DWARF2 information corresponding to the original source-code functions.
══════════════════════════════════════════════
[...] based on the one or more function relations indicated by the data structure (Abstract, "We developed a tool, dcgg, that statically generates call graphs for C++ using DWARF2 debugging information based on this method. We use a combination of a binary analysis and debugging information to detect static function calls (including inline expanded functions) simply and precisely, and also virtual function calls (dynamic function calls in C++)." § 2.3, "The method to detect function calls is like below. 1. Gather all pairs of caller and callee addresses from disassembled codes. 2. Transform each address to a function name with information about address ranges of functions contained by DWARF2. In addition, DWARF2 contains the address ranges of in line expanded functions.").
Terashima fails to teach:
and automatically controlling deployment of the source code based on a compliance score that indicates compliance of the source code with a functional safety requirement, the compliance score generated [...]
However, Paccapeli teaches:
and automatically controlling deployment of the source code based on a compliance score that indicates compliance of the source code with a functional safety requirement, the compliance score generated [...] (Paragraph [0018], "Examples of the data 120a-b can include design specifications, source code, test results, and validation results associated with the software package 106 (emphasis added)." Paragraph [0021], "After obtaining the data 120a-b, the automated scoring engine 130 can apply a set of rules 132 to the data 120a-b to determine an overall score 145 for the software package 106 (emphasis added). The set of rules 132 may be predefined and customizable by a user, such as the human evaluator 126. The overall score 134 may be a single score that suggests the overall degree to which the software package 106 complies with the functional safety standard 122 (emphasis added). A higher overall score may suggest a higher level of overall compliance with the functional safety standard 122, and a lower overall score may suggest a lower level of overall compliance with the functional safety standard 122." Paragraph [0024], "The system can further include an automated deployment controller 138 that can make deployment decisions based on the overall score 134 (emphasis added). For example, the automated deployment controller 138 can receive the overall score 134 for a software package 106 and compare it to a predefined threshold. If the overall score 134 meets or exceeds the predefined threshold, the automated deployment controller 138 may automatically provide the software package 106 to a production subsystem 140 for deployment to the end users 108. If the overall score 134 is below the predefined threshold, the automated deployment controller 138 may automatically notify the human evaluator 126 and prevent deployment of the software package 106 at that time.").
Terashima and Paccapeli are considered to be analogous to the claimed invention because they are in the same field of automated software analysis. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified the teachings of Terashima to incorporate the teachings of Paccapeli to have:
and automatically controlling deployment of the source code based on a compliance score that indicates compliance of the source code with a functional safety requirement, the compliance score generated [...]
The modification would have been obvious because Terashima teaches generating a call graph representing relationships between functions using DWARF debugging information as additional software-analysis data (Terashima, Abstract; § 2.3). Paccapeli teaches an automated evaluation system that applies the same rules to the same types of software data. Thus, one of ordinary skill in the art would have been motivated to incorporate the DWARF-based call-graph generation technique of Terashima as part of the software information evaluated by Paccapeli in order to provide additional structural information concerning relationships among functions for consideration during the automated compliance evaluation, thereby providing consistent evaluation of software before deployment (Paccapeli, Paragraph [0002, 0023]).
Regarding Claim 2, the rejection of claim 1 is incorporated. Terashima further teaches:
wherein determining the one or more function relations further comprises determining, using the one or more attributes provided by the debugging file, at least one static relation, and wherein the at least one static relation corresponds to an unchanging association between a subset of the functions (§ 2.3, "The method to detect function calls is like below. 1. Gather all pairs of caller and callee addresses from disassembled codes. 2. Transform each address to a function name with information about address ranges of functions contained by DWARF2." § 3.2, "Static function calls are basically detected by the same method as bscg’s (emphasis added). However, special care should be taken to some C++ specific features like overloading, member functions and templates. Normal functions that come from C are detected by the same method as bscg. That is, they are detected with call instructions in the execution codes and function information in DWARF2 (emphasis added).").
══════════════════════════════════════════════
Examiner's Remarks: The instant specification identifies direct function calls as exemplary static relations corresponding to unchanging associations. Accordingly, Terashima’s statically detected direct/normal function calls constitute the claimed static relation corresponding to an unchanging association between functions.
══════════════════════════════════════════════
Regarding Claim 3, the rejection of claim 1 is incorporated. Terashima further teaches:
wherein determining the one or more function relations further comprises determining, using the one or more attributes provided by the debugging file, at least one dynamic relation, and wherein the at least one dynamic relation corresponds to a variable association between a subset of the functions (Abstract, "We developed a tool, dcgg, that statically generates call graphs for C++ using DWARF2 debugging information based on this method. We use a combination of a binary analysis and debugging information to detect static function calls (including inline expanded functions) simply and precisely, and also virtual function calls (dynamic function calls in C++)." § 2.4, "Virtual function calls are a kind of dynamic function calls whose callee cites are limited to overriding ones (emphasis added)." § 3.3, "dcgg detects virtual function calls using the following two kind of information, both of which is available in DWARF2 (emphasis added). 1. The location of pointer to the virtual function table in classes and the layout of virtual function tables (emphasis added). 2. The type and location of all variables (including parameters) and the layout of all their types (emphasis added).").
══════════════════════════════════════════════
Examiner's Remarks: Terashima expressly characterizes virtual function calls as dynamic function calls and teaches that the callee sites are limited to overriding functions. Thus, the calling-function/called-function association is variable among the applicable overriding functions, corresponding to the claimed variable association between a subset of the functions.
══════════════════════════════════════════════
Regarding Claim 5, the rejection of claim 1 is incorporated. Terashima further teaches:
wherein determining the one or more function relations further comprises: extracting, using the debugging file, the one or more attributes used to define the set of functions (Fig. 1, § 2.2, "Each entry has an entry tag corresponding to a type of information and some attributes." § 3.1, "dcgg uses readelf+ [10, 9] to extract DWARF2-XML, therefore the target execution file should be ELF format and contain DWARF2 debugging information (emphasis added).");
══════════════════════════════════════════════
Examiner's Remarks: As shown in Terashima’s Fig. 1, the extracted DWARF2 information includes function entries having corresponding attributes, thereby extracting the attributes used to define the function.
══════════════════════════════════════════════
and determining, based on the one or more attributes, that the source code comprises an inline function call, wherein the inline function call indicates that an inline function of the source code is called by a particular function of the set of functions (§ 2.3, "In addition, DWARF2 contains the address ranges of in line expanded functions (emphasis added). This information is appended to all expanded code blocks whether the function is specified as inline or not. With this information, it is possible to detect inline expanded function calls and function calls in the expanded codes (emphasis added)." § 3.2, "Inline expanded functions are also detected by the same method as bscg (emphasis added). That is, they are detected with only DWARF2. Incidentally, if a function call is detected in expanded codes, the caller site is the expanded inline function (emphasis added). dcgg deals with such a case correctly.").
══════════════════════════════════════════════
Examiner's Remarks: Terashima teaches detecting inline-expanded functions and calls using DWARF2 information and identifying the caller associated with a detected call, thereby identifying the function-call relationship involving the inline function.
══════════════════════════════════════════════
Regarding Claim 6, the rejection of claim 1 is incorporated. Terashima further teaches:
wherein mapping each function relation of the one or more function relations to the source code comprises: identifying, based on the one or more function relations, one or more called functions called by a respective function of the set of functions (Abstract, "In a preliminary evaluation dcgg generated precise call graphs including inline expansions and virtual function calls (emphasis added)." § 2.3, "The method to detect function calls is like below. 1. Gather all pairs of caller and callee addresses from disassembled codes (emphasis added). 2. Transform each address to a function name with information about address ranges of functions contained by DWARF2 (emphasis added).");
and determining, based on the one or more attributes of the debugging file, a respective location identifier associated with each called function of the one or more called functions, wherein each location identifier corresponds to a respective location of a respective called function in the source code (§ 2.2, “Debugging information is information that debuggers need and compilers produce and put into binary files. Typical debugging information includes description about local variables, user defined types, line numbers, scopes, stack frames, and so on (emphasis added).” § 2.3, "The method to detect function calls is like below. 1. Gather all pairs of caller and callee addresses from disassembled codes. 2. Transform each address to a function name with information about address ranges of functions contained by DWARF2 (emphasis added). In addition, DWARF2 contains the address ranges of in line expanded functions. This information is appended to all expanded code blocks whether the function is specified as inline or not. With this information, it is possible to detect inline expanded function calls and function calls in the expanded codes.").
══════════════════════════════════════════════
Examiner's Remarks: Terashima teaches that DWARF2 debugging information includes line-number information (Terashima, § 2.2). The DWARF Debugging Information Format, Version 5 specification, confirms that line-number information correlates machine-code addresses with corresponding source-code locations. See DWARF Version 5, § 6.2
══════════════════════════════════════════════
Claims 8-10 and 12-13 are method claims corresponding to the system claims hereinabove (Claims 1-3 and 5-6 respectively). Therefore, claims 8-10 and 12-13 are rejected for the same reasons set forth in the rejections of claims 1-3 and 5-6 respectively.
Claims 15-17 and 19-20 are non-transitory computer-readable medium claims corresponding to the system claims hereinabove (Claims 1-3 and 5-6 respectively). Therefore, claims 15-17 and 19-20 are rejected for the same reasons set forth in the rejections of claims 1-3 and 5-6 respectively.
Claims 4, 11, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Terashima (Terashima et al., “Static Call Graph Generator for C++ using Debugging Information”, January 07, 2008) in view of Paccapeli (US Patent Application Publication No. US 2024/021126 A1) and further in view of Chen (US Patent Application Publication No. US 2024/0061764 A1).
Regarding Claim 4, the rejection of claim 1 is incorporated. Terashima further teaches:
extracting, using the debugging file, the one or more attributes used to define the set of functions (Fig. 1, § 2.2, "Each entry has an entry tag corresponding to a type of information and some attributes (emphasis added)." § 3.1, "dcgg uses readelf+ [10, 9] to extract DWARF2-XML, therefore the target execution file should be ELF format and contain DWARF2 debugging information (emphasis added).");
[…] based on the one or more attributes […] (Fig. 1; § 2.2, “Debugging information is information that debuggers need and compilers produce and put into binary files. Typical debugging information includes description about local variables, user defined types, line numbers, scopes, stack frames, and so on (emphasis added).” § 2.2, "Each entry has an entry tag corresponding to a type of information and some attributes (emphasis added).")
Terashima fails to teach:
and determining […] that the source code comprises a macro call […]
wherein the macro call indicates that a macro of the source code is called by a particular function of the set of functions.
However, Chen teaches:
and determining […] that the source code comprises a macro call […] (Chen, Fig. 4; Fig. 5, Fig. 7B; Paragraph [0076] "For example, a MacroEnclosed 408 includes a macro enclosed value that indicates whether a number of source code lines is enclosed by a macro (emphasis added), a StatementCompiledValid 410 includes a value that indicates whether a statement is compiled or not, a FuncSectionLinkValid 412 includes a value that indicates whether a function is linked, an ObjectLinkedValid 414 indicates whether an object code is linked to an executable file, and a MacroEncSymIdx 416 indicates an identifier of debugging information linked to a source code line of a computer instruction from computer program 302.").
wherein the macro call indicates that a macro of the source code is called by a particular function of the set of functions (Fig. 5, Paragraph [0083], “Entry 504 can further include file a name 508, which indicates the file name of the computer instruction. File name 508 may be FileName 424 of macro enclosed information 406 in FIG. 4. Entry 504 can also include a function name 510, which indicates the name of a function or variable of the compute instruction, and a Macro enclosed record ID 512, which is a numerical symbol assigned to each code segment within the computer instruction based on the line number of each code segment.” Paragraph [0090], “The debugger creates a table with relational information between features and properties of different code segments as shown by MacEncSymTable Old table. In the present example, MacEncSymTable Old table includes a Symbol Name column indicating the function name of a code segment, a File Name column indicating which preprocessed file does the function of the code segment belongs to, a Macro Enclosed Record ID, and a Symbol Index column with blanks.”).
══════════════════════════════════════════════
Examiner's Remarks: Chen teaches identifying source code associated with a macro and maintaining information records that associate the macro-enclosed source code with a particular function, including a Function Name 510 and a Macro Enclosed Record ID 512 (Chen, Fig. 5). Thus, Chen’s identification of macro-associated source code corresponding to a particular function is considered to correspond to the claimed macro call indicating that a macro of the source code is called by a particular function.
══════════════════════════════════════════════
Terashima, Paccapeli, and Chen are considered to be analogous to the claimed invention because they are in the same field of automated computer-implemented software analysis. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified the combined teachings of Terashima and Paccapeli to incorporate the teachings of Chen to have:
and determining […] that the source code comprises a macro call […]
wherein the macro call indicates that a macro of the source code is called by a particular function of the set of functions.
The modification would have been obvious because the combined system of Terashima and Paccapeli teaches analyzing debugging information to identify functions and relationships associated with source code, including extracting attributes from DWARF debugging information (Terashima, §§ 2.2, 3.1). Chen teaches generating and maintaining debugging information identifying source code associated with macros, including information associating macro-enclosed source code with particular functions (Chen, Fig. 5; Paragraph [0076]). Thus, one of ordinary skill in the art would have been motivated to incorporate the macro-information technique of Chen into the debugging information analysis of Terashima and Paccapeli to provide additional structural information identifying macro-associated source code and it’s corresponding functions, thereby enabling the software analysis to account for source-code constructs associated with macros avoiding issues with build performance, and runtime errors (Chen, Paragraph [0003]).
Claim 11 is a method claim corresponding to the system claim hereinabove (Claim 4). Therefore, claim 11 is rejected for the same reasons set forth in the rejection of claim 4.
Claim 18 is a non-transitory computer-readable medium claim corresponding to the system claim hereinabove (Claim 4). Therefore, claim 18 is rejected for the same reasons set forth in the rejection of claim 4.
Claims 7 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Terashima (Terashima et al., “Static Call Graph Generator for C++ using Debugging Information”, January 07, 2008) in view of Paccapeli (US Patent Application Publication No. US 2024/021126 A1) and further in view of Niddodi (Niddodi et al., “TOPr: Enhanced Static Code Pruning for Fast and Precise Directed Fuzzing”, September 18, 2023).
Regarding Claim 7, the rejection of claim 1 is incorporated. Terashima further teaches:
[…] wherein the function signature is provided as part of the one or more attributes of the debugging file […] (§ 2.2, "This section is represented as a tree of entries, which is a logical unit of debugging information. Each entry has an entry tag corresponding to a type of information and some attributes (emphasis added). Figure 1 shows an example of the tree structure of entries. In this sample, a compilation unit hello.c contains information about a type int and a function main. Additionally the function main contains a block and the block contains a local variable i. Moreover, this section contains much useful information including inline expansions and detailed type information such as the members of each class and the layout of each virtual function table (emphasis added).")
Terashima fails to teach:
determining that the particular function is a calling function based on a function signature of the particular function, […] and indicates a calling relationship between the calling function and a call target; and
identifying, based on the function signature, the call target configured to be called by the particular function.
However, Niddodi teaches:
determining that the particular function is a calling function based on a function signature of the particular function, […] and indicates a calling relationship between the calling function and a call target; and (Page 4, § III, "To overcome this challenge, we perform function signature matching to handle indirect calls to functions in the whole-program module (emphasis added). We build on the basic approach in type-based pointer analysis and call-graph construction (e.g., [38], [1]). In case of call instructions that contain function pointers instead of names, we use signature matching to identify all functions in the whole-program module whose function signature matches with the function signature seen in the call instruction (emphasis added).")
identifying, based on the function signature, the call target configured to be called by the particular function (Pages 4-5, § III, Paragraph 5, "In case of call instructions that contain function pointers instead of names, we use signature matching to identify all functions in the whole-program module whose function signature matches with the function signature seen in the call instruction (emphasis added). getMatchedSignFnNames on line 29 of algorithm Algorithm 1 accomplishes this task. This is a conservative mechanism which ensures that no relevant part of the program gets pruned out (emphasis added). We construct the call graph for the entire program module and store it as a map whose key is a function and value is the set of functions that call the said function (i.e., caller functions) (emphasis added).").
══════════════════════════════════════════════
Examiner's Remarks: Terashima teaches that DWARF debugging information includes entries corresponding to functions having associated attributes and detailed type information (Terashima, § 2.2; Fig. 1). Niddodi teaches using function signatures to determine calling relationships and identify call targets. Thus, in the proposed combination, the function-signature-based call resolution of Niddodi is applied using the function information provided by the attributes of Terashima’s DWARF debugging information.
══════════════════════════════════════════════
Terashima, Paccapeli, and Niddodi are considered to be analogous to the claimed invention because they are in the same field of computer-implemented software analysis. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified the combined teachings of Terashima and Paccapeli to incorporate the teachings of Niddodi to have:
determining that the particular function is a calling function based on a function signature of the particular function, […] and indicates a calling relationship between the calling function and a call target; and
identifying, based on the function signature, the call target configured to be called by the particular function.
The modification would have been obvious because the combined system of Terashima and Paccapeli teaches generating function relationships, including dynamic/virtual function-call relationships, using function and type information available in DWARF debugging information (Terashima, Abstract; § 2.3). Niddodi teaches resolving indirect calls by using function-signature matching to identify functions whose signatures match the signature associated with an indirect call instructions (Niddodi, Pages 4-5, § III, Paragraph 5). Thus, one of ordinary skill in the art would have been motivated to incorporate the signature matching technique of Niddodi into the call-graph analysis system of Terashima and Paccapeli to improve identification of potential call targets for indirect calls and thereby produce a more complete set of function relationships for the call graph. (Niddodi, Page 4, § III).
Claim 14 is a method claim corresponding to the system claim hereinabove (Claim 7). Therefore, claim 14 is rejected for the same reasons set forth in the rejection of claim 7.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. They are as follows:
Ageyev (US 2005/0050523 A1) discloses a method to generate a formatted trace for a second device embedded in a first device. The method provides source code comprising a trace entry, compiles that source code to form an embedded device code image comprising a trace description string and a trace description string address, and assigns the trace description string address as the traceId.
Blackman (US 2015/0331783 A1) discloses an approach for generating a compiler listing using Debugging With Attributed Record Format (DWARF) debugging data, a processor receives DWARF debugging data associated with source code of a programming language. A processor extracts information from the DWARF debugging data, wherein the information comprises at least source code lines, variable declaration lines, and variable reference lines. A processor generates a compiler listing based on the information extracted from the DWARF debugging data, wherein the compiler listing includes at least a symbol table, and cross-reference information.
Jain (US 20240045662 A1) discloses techniques for performing software code verification are described. Systems and methods are disclosed for generating, using intermediate code and user input, a call graph that represents source code for software. For instance, the call graph represents at least functions (e.g., internal functions, external functions, etc.) associated with the software, calls (e.g., direct calls, call pointers, etc.) between the functions, and register information associated with the functions (e.g., variables used by the functions, assembly code used by the functions, etc.). The systems and methods may further use the call graph to perform software code verification by verifying rules from design specifications for the software and/or rules from various certification standards.
DWARF Debugging Information Format Version 5 discloses DWARF which is a debugging information file format used by many compilers and debuggers to support source level debugging. It addresses the requirements of a number of procedural languages, such as C, C++, and Fortran, and is designed to be extensible to other languages. DWARF is architecture independent and applicable to any processor or operating system. It is widely used on Unix, Linux and other operating systems, as well as in stand-alone environments.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MD KAMRUZZAMAN whose telephone number is (571) 272-8415. The examiner can normally be reached Monday-Friday 9:00 am - 5: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, Wei Mui can be reached at (571) 272-3708. 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.
/M.K./Examiner, Art Unit 2191
/WEI Y MUI/Supervisory Patent Examiner, Art Unit 2191
Prosecution Insights