Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
2. This is the initial office action based on the application filed on December 29th, 2024, which claims 1-20 are presented for examination.
Status of Claims
3. Claims 1-20 are pending, of which claims, of which claim 1, 14 and 18 are in independent form.
Priority
4. No priority has been considered for the instant application
Information Disclosure Statement
5. Information disclosure statement filed on 10/29/2024, has been reviewed and considered by Examiner.
The Office's Note:
6. The Office has cited particular paragraphs / columns and line numbers in the reference(s) applied to the claims above for the convenience of the Applicant. Although the specified citations are representative of the teachings of the art and are applied to specific limitations within the individual claim(s), other passages and figures may apply as well. It is respectfully requested from the Applicant in preparing responses, to fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the cited passages as taught by the prior art or relied upon by the Examiner.
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.
7. Claims 1-20 rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
Claim 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Claim 1, claim 14 and claim 18 recite “ processing, using at least one application programming interface, source code associated with at least one web-based application; identifying a first set of one or more variables within one or more portions of the source code by processing the one or more portions of the source code in conjunction with one or more code-related data structures comprising code-related storage information; identifying a second set of one or more variables within the one or more portions of the source code by processing the one or more portions of the source code using one or more artificial intelligence techniques trained on variable naming data; and incorporating, at one or more positions within the source code, log information pertaining to one or more of at least a portion of the first set of one or more variables and at least a portion of the second set of one or more variables.” as drafted, are functions that, under its broadest reasonable interpretation, recite the abstract idea of a mental process. The limitations encompass a human mind carrying out the function through observation, evaluation judgment and /or opinion, or even with the aid of pen and paper. Thus, this limitation recites and falls within the “Mental Processes” grouping of abstract ideas under Prong 1.
Under Prong 2, this judicial exception is not integrated into a practical application. The additional elements ““memory”, and “processor” are recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using generic computer, and/or mere computer components, and “and incorporating, at one or more positions within the source code, log information pertaining to one or more of at least a portion of the first set of one or more variables and at least a portion of the second set of one or more variables” do nothing more than add insignificant extra solution activity to the judicial exception of merely gathering, displaying, updating, transmitting and storing data/information. Accordingly, the additional elements do not integrate the recited judicial exception into a practical application and the claim is therefore directed to the judicial exception. See MPEP 2106.05(g).
Under Step 2B, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of ““memory,” and “processor” are recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using generic computer, and/or mere computer components, and “and incorporating, at one or more positions within the source code, log information pertaining to one or more of at least a portion of the first set of one or more variables and at least a portion of the second set of one or more variables”, the courts have identified merely gathering, displaying, updating, transmitting and storing data/information on a display is well-understood, routine and conventional activity. See MPEP 2106.05(d). The recitation of generic computer instruction and computer components to apply the judicial exception, and merely displaying data do not amount to significantly more, thus, cannot provide an inventive concept. Accordingly, the claims are not patent eligible under 35 USC 101.
In conclusion, claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
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.
8. Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Ahadian (US 20120159433 – hereinafter Ahadian), in view of Lu (US 20160224793– hereinafter Lu) and further in view of Becker (US 20090007065– hereinafter Becker).
Claim 1 rejected, Ahadian teaches a computer-implemented method comprising:
processing, using at least one application programming interface, source code associated with at least one web-based application (Ahadian, US 20120159433, para [0016], FIG. 2 is a block diagram illustrating a hardware environment of a database server and a set of dependent applications and web services, according to one embodiment of the invention. Para [0030-0032]. Fig. 3 and para [0035-0040], The impact analyzer 350 outputs the impact analysis results 380 that show, in detail, the impacted applications and database web services. Such detail may be the affected workspaces, projects, and modules, or more specific, e.g., locations in source code files, methods, objects, and variables. For example, the impact analysis results 380 may list specific lines of the application source code 360 or web service source code 370 that would be affected by the DDL statement 330. The analysis results 380 enable a user to ascertain the extent of the impact of the DDL statement 330 on the application or web service);
identifying a first set of one or more variables within one or more portions of the source code by processing the one or more portions of the source code in conjunction with one or more code-related data structures comprising code-related storage information (Ahadian, fig. 3 and para [0035-0037]. Para [0038-0040], In step 440, the impact analyzer identifies all application/web service objects and methods that access the database objects. For example, for a Java application, the impact analyzer 440 identifies source code that accesses the database column renamed by the DDL statement. At step 450, the impact analyzer 350 creates and organizes references to the affected source code into a hierarchy. The references include a source code filename and a line number. For example, the hierarchy may be grouped by source code filenames, and each filename is associated with a list of line numbers corresponding to the affected source code. Para [0039], At step 460, the impact analyzer 350 generates analysis results 380, which displays the hierarchy and allows users to access and view the affected source code in a visually distinct (e.g., highlighted) manner. Further, additional output from the impact analyzer 350 may be generated, e.g., proposed actions to adapt the code and/or the SQL to the change. For example, assume the data type of a column is changed from a character to an integer, and that a function call in an application program may include a character (or string) variable used to store values from the column. In such a case, the impact analyzer 350 may suggest a modification to the function definition changing the character to an integer data type. Fig. 6 and para [0044], FIG. 6 illustrates a graphical user interface that displays impact analysis results 380 for a DDL statement 520, according to one embodiment of the invention. The impact analysis results 380 also display a hierarchy of affected source code locations 620, wherein the hierarchy 620 is seamlessly integrated into the IDE, allowing the user to access particular affected source code via the hierarchy 620. Further, the impact analysis results also highlight 610 variables and methods that access the affected column.);
wherein the method is performed by at least one processing device comprising a processor coupled to a memory (Ahadian, fig. 2 and para [0033], processor and memory).
Ahadian does not explicitly teach
identifying a second set of one or more variables within the one or more portions of the source code by processing the one or more portions of the source code using one or more artificial intelligence techniques trained on variable naming data;
incorporating, at one or more positions within the source code, log information pertaining to one or more of at least a portion of the first set of one or more variables and at least a portion of the second set of one or more variables;
However, Lu teaches
identifying a second set of one or more variables within the one or more portions of the source code by processing the one or more portions of the source code using one or more artificial intelligence techniques trained on variable naming data (Lu, US 20160224793, fig. 2A, fig. 2A and para [0035-0040], In STEP 204, in one or more embodiments, the information flow analysis module determines a plurality of variables using the application source code. In one or more embodiments, the information flow analysis module iterates through the application source code line-by-line and determines the variables present in each line. For example, the information flow analysis module may parse each file within a collection of application source code and determine the variables within each file within the application source code. In this example, the information flow analysis module may determine that a line in the application source code containing an assignment from variable X to variable Y includes the variable X and variable Y. Further in this example, the information flow analysis module may determine that a line in the application source code containing a function call passing variable Z as an argument includes the variable Z.); and
incorporating, at one or more positions within the source code, log information pertaining to one or more of at least a portion of the first set of one or more variables and at least a portion of the second set of one or more variables(Lu, para [0025-0028], In one or more embodiments, an information flow relation includes a source variable and a target variable, and is an indication that information may flow from the source variable to the target variable. For example, application source code (108) containing an assignment of variable X in method A of class Q to variable Y in method B of class R may correspond to an information flow relation with a source of variable X and a target of variable Y. In another example, application source code (108) containing an assignment of variable X in method A of class Q to variable Y in method B of class R and an assignment of variable Y in method B of class R to variable Z in method C of class S may correspond to three information flow relations reflecting the transitive properties of assignment—a first information flow relation with a source of variable X and a target of variable Y, a second information flow relation with a source of variable Y and a target of variable Z, and a third information flow relation with a source variable of X and a target variable of Z. In this way, multiple possible downstream recipients of information flowing from each source variable may be expressed. Para [0060], In STEP 220, in one or more embodiments of the invention, the access control analysis module generates an error report log entry for the information flow relation as determined in STEP 214. In one or more embodiments, an error report log entry is one or more data structures that include a descriptive listing for each information flow relation that fails the determination as performed by the access control analysis module in STEP 216 and 218. In one or more embodiments, each error report log entry is human readable. For example, an error report log entry may indicate a source variable, a line number, class, and file where the source variable may be found, a target variable, and a line number, class, and file where the target variable may be found. In one or more alternative embodiments, each error report log entry is machine readable, such that a process or group of processes may modify the application source code using the error report log entry.);
It would have obvious to one having ordinary skill in the art before the effecting filing date of the claimed invention to combine the teachings of cited references. Thus, one of ordinary skill in the art before the effecting filing date of the claimed invention would have been motivated to incorporate Lu into Ahadian to use static program analysis for detecting security bugs in an application source code in a computer system as suggested by Lu (See abstract and conclusion).
The Office would like to use prior art Becker to back up Ahadian and Lu to further teach limitation
incorporating, at one or more positions within the source code, log information pertaining to one or more of at least a portion of the first set of one or more variables and at least a portion of the second set of one or more variables(Becker, US 20090007065, fig. 1 and para [0022-0032], generally, the system 100 inserts a revised logging source code statement into source code in the source code 115 to replace the original logging source code statement. The revised logging source code statement specifies a "logging index value" and the names, types, and sizes of the associated variable names representing runtime dynamic data, derived from the associated static data of the original selected logging source code statement. This revised logging source code statement can be used as an alternative to the original print statement. Therefore, both types of numbers (i.e., the logging index value and the dynamic values associated with the static variable names) will be created in a log when running the modified source code 115. Fig. 2A and para [0038-0044], In a step 260, a write to a log is enabled with the log index value and variable names within the source code. This generates modified source code. In some embodiments, the LST 170 enables an outputting, such as a write in a source code 105 to generate modified source code 115. In some embodiments, a variable name is appended to the log index value within the modified source code 115. In some embodiments, source code static data and the original logging statement is deleted from the source code.)
It would have obvious to one having ordinary skill in the art before the effecting filing date of the claimed invention to combine the teachings of cited references. Thus, one of ordinary skill in the art before the effecting filing date of the claimed invention would have been motivated to incorporate Becker into Ahadian and Lu to enable improvement in generating and recording log data, allows log to be written within the source code efficiently, and generation of the computer-implemented logging dictionary effectively for compilation of the source code.as suggested by Lu (See abstract and conclusion).
Claim 2 is rejected for the reasons set forth hereinabove for claim 1, Ahadian, Lu and Becker teach the computer-implemented method of claim 1, wherein identifying the first set of one or more variables comprises identifying one or more variables pertaining to one or more identifiers in at least one database schema associated with the source code(Ahadian, fig. 3 and para [0035-0037]. Para [0038-0040], In step 440, the impact analyzer identifies all application/web service objects and methods that access the database objects. For example, for a Java application, the impact analyzer 440 identifies source code that accesses the database column renamed by the DDL statement. At step 450, the impact analyzer 350 creates and organizes references to the affected source code into a hierarchy. The references include a source code filename and a line number. For example, the hierarchy may be grouped by source code filenames, and each filename is associated with a list of line numbers corresponding to the affected source code. Para [0039], At step 460, the impact analyzer 350 generates analysis results 380, which displays the hierarchy and allows users to access and view the affected source code in a visually distinct (e.g., highlighted) manner. Further, additional output from the impact analyzer 350 may be generated, e.g., proposed actions to adapt the code and/or the SQL to the change. For example, assume the data type of a column is changed from a character to an integer, and that a function call in an application program may include a character (or string) variable used to store values from the column. In such a case, the impact analyzer 350 may suggest a modification to the function definition changing the character to an integer data type. Fig. 6 and para [0044], FIG. 6 illustrates a graphical user interface that displays impact analysis results 380 for a DDL statement 520, according to one embodiment of the invention. The impact analysis results 380 also display a hierarchy of affected source code locations 620, wherein the hierarchy 620 is seamlessly integrated into the IDE, allowing the user to access particular affected source code via the hierarchy 620. Further, the impact analysis results also highlight 610 variables and methods that access the affected column.).
Claim 3 is rejected for the reasons set forth hereinabove for claim 1, Ahadian, Lu and Becker teach the computer-implemented method of claim 1, wherein processing the one or more portions of the source code using one or more artificial intelligence techniques trained on variable naming data comprises processing the one or more portions of the source code using one or more artificial intelligence techniques trained on variable prefix data and variable suffix data(Lu, fig. 2A, fig. 2A and para [0035-0040], In STEP 204, in one or more embodiments, the information flow analysis module determines a plurality of variables using the application source code. In one or more embodiments, the information flow analysis module iterates through the application source code line-by-line and determines the variables present in each line. For example, the information flow analysis module may parse each file within a collection of application source code and determine the variables within each file within the application source code. In this example, the information flow analysis module may determine that a line in the application source code containing an assignment from variable X to variable Y includes the variable X and variable Y. Further in this example, the information flow analysis module may determine that a line in the application source code containing a function call passing variable Z as an argument includes the variable Z. Ahadian, para [0044-0045], FIG. 6 illustrates a graphical user interface that displays impact analysis results 380 for a DDL statement 520, according to one embodiment of the invention. The impact analysis results 380 also display a hierarchy of affected source code locations 620, wherein the hierarchy 620 is seamlessly integrated into the IDE, allowing the user to access particular affected source code via the hierarchy 620. Further, the impact analysis results also highlight 610 variables and methods that access the affected column.).
Claim 4 is rejected for the reasons set forth hereinabove for claim 1, Ahadian, Lu and Becker teach the computer-implemented method of claim 1, wherein incorporating log information at one or more positions within the source code comprises incorporating the log information at one or more of at least one branch statement within the source code, at least one infrastructure statement within the source code, and at least one control transfer point within the source code(Lu, para [0048-0049], In this example, the rule [EXPLICIT] simply includes all explicit information flow relations, such as those included in Table 2. In the rules [IF-TRUE] and [IF-FALSE], the condition of the if statement may implicitly influence the statements in its branches (i.e. which branch to take depends on the condition). In this example, the rest of the rules propagate the information from a statement to its components, allowing information of the if condition to flow to any statement/expression reachable from its branches. The rules [CALL] and [RETURN-IMPLICIT] support such propagation inter-procedurally. The last rule [TRANS-IMPLICIT] defines the transitivity of the information flow relation.).
Claim 5 is rejected for the reasons set forth hereinabove for claim 1, Ahadian, Lu and Becker teach the computer-implemented method of claim 1, wherein processing the source code associated with at least one web-based application comprises traversing, using the at least one application programming interface, the source code from at least one identified entry point within the source code, and tagging one or more input variables and one or more variables in one or more functions within the source code(Lu, para [0057-0058], In STEP 216, in one or more embodiments of the invention, for the information flow relation as determined in STEP 214, the access control analysis module compares the confidentiality requirement for the source variable to the capability for the target variable. If the confidentiality requirement for the source variable is less than or equal to the capability for the target variable, the access control analysis module proceeds to STEP 218. If the confidentiality requirement for the source variable is not less than or equal to the capability for the target variable, the access control analysis module proceeds to STEP 220. Para [0059-0060], In STEP 220, in one or more embodiments of the invention, the access control analysis module generates an error report log entry for the information flow relation as determined in STEP 214. In one or more embodiments, an error report log entry is one or more data structures that include a descriptive listing for each information flow relation that fails the determination as performed by the access control analysis module in STEP 216 and 218. In one or more embodiments, each error report log entry is human readable. For example, an error report log entry may indicate a source variable, a line number, class, and file where the source variable may be found, a target variable, and a line number, class, and file where the target variable may be found. In one or more alternative embodiments, each error report log entry is machine readable, such that a process or group of processes may modify the application source code using the error report log entry.).
Claim 6 is rejected for the reasons set forth hereinabove for claim 1, Ahadian, Lu and Becker teach the computer-implemented method of claim 1, wherein identifying the first set of one or more variables comprises identifying one or more variables pertaining to one or more fields with one or more unique key constraints and which lack a fixed set of values(Ahadian, para [0037-0042], As shown, the method 400 begins at step 410, where a proposed DDL statement 330 is received by the impact analyzer 350. For example, assume a DDL statement for renaming the name of a table column is received. At step 420, the impact analyzer 350 connects to the database 320. Once connected the impact analyzer 350 may request information from the database describing the structure or schema of a particular database. Alternatively, this information may be determined from a model or other representation of database state. In such case, rather than connect to the actual database or DBMS system, the impact analyzer 350 may access the model describing the database. At step 430, the impact analyzer 350 identifies each database object affected by the proposed DDL statement. Examples of database objects include database, schemas, tables, table spaces, views, columns, constraints, privileges, primary keys, foreign keys, and procedures. For example, the impact analyzer 350 may identify the column renamed by the DDL statement. Para [0049].).
Claim 7 is rejected for the reasons set forth hereinabove for claim 1, Ahadian, Lu and Becker teach the computer-implemented method of claim 1, wherein the first set of one or more variables and the second set of one or more variables share at least one variable (Ahadian, para [0044-0045], FIG. 6 illustrates a graphical user interface that displays impact analysis results 380 for a DDL statement 520, according to one embodiment of the invention. The impact analysis results 380 also display a hierarchy of affected source code locations 620, wherein the hierarchy 620 is seamlessly integrated into the IDE, allowing the user to access particular affected source code via the hierarchy 620. Further, the impact analysis results also highlight 610 variables and methods that access the affected column.).
Claim 8 is rejected for the reasons set forth hereinabove for claim 1, Ahadian, Lu and Becker teach the computer-implemented method of claim 1, wherein the first set of one or more variables is distinct from the second set of one or more variables (Ahadian, para [0046], FIG. 8 illustrates a graphical user interface of a DDL query builder 810 window of a database administration application, displaying the impact analysis results 380 for changing the ACTNO column type from SMALLINT to VARCHAR, according to one embodiment of the invention. The impact analysis results 380 also display a hierarchy of affected source code locations 820, wherein the hierarchy 820 is seamlessly integrated into the IDE, allowing the user to access particular source code locations via the hierarchy 820, according to one embodiment of the invention.).
Claim 9 is rejected for the reasons set forth hereinabove for claim 1, Ahadian, Lu and Becker teach the computer-implemented method of claim 1, wherein identifying the second set of one or more variables comprises processing the one or more portions of the source code using one or more natural language processing techniques trained on variable naming data(Lu, fig. 2A, fig. 2A and para [0035], In STEP 204, in one or more embodiments, the information flow analysis module determines a plurality of variables using the application source code. In one or more embodiments, the information flow analysis module iterates through the application source code line-by-line and determines the variables present in each line. For example, the information flow analysis module may parse each file within a collection of application source code and determine the variables within each file within the application source code. In this example, the information flow analysis module may determine that a line in the application source code containing an assignment from variable X to variable Y includes the variable X and variable Y. Further in this example, the information flow analysis module may determine that a line in the application source code containing a function call passing variable Z as an argument includes the variable Z.).
Claim 10 is rejected for the reasons set forth hereinabove for claim 1, Ahadian, Lu and Becker teach the computer-implemented method of claim 1, wherein incorporating log information at one or more positions within the source code comprises incorporating the log information at one or more of at least one position within the source code which contains incomplete log information and at least one position within the source code wherein log information is expected but not present(Lu, para [0025-0028], In one or more embodiments, an information flow relation includes a source variable and a target variable, and is an indication that information may flow from the source variable to the target variable. For example, application source code (108) containing an assignment of variable X in method A of class Q to variable Y in method B of class R may correspond to an information flow relation with a source of variable X and a target of variable Y. In another example, application source code (108) containing an assignment of variable X in method A of class Q to variable Y in method B of class R and an assignment of variable Y in method B of class R to variable Z in method C of class S may correspond to three information flow relations reflecting the transitive properties of assignment—a first information flow relation with a source of variable X and a target of variable Y, a second information flow relation with a source of variable Y and a target of variable Z, and a third information flow relation with a source variable of X and a target variable of Z. In this way, multiple possible downstream recipients of information flowing from each source variable may be expressed. Para [0060], In STEP 220, in one or more embodiments of the invention, the access control analysis module generates an error report log entry for the information flow relation as determined in STEP 214. In one or more embodiments, an error report log entry is one or more data structures that include a descriptive listing for each information flow relation that fails the determination as performed by the access control analysis module in STEP 216 and 218. In one or more embodiments, each error report log entry is human readable. For example, an error report log entry may indicate a source variable, a line number, class, and file where the source variable may be found, a target variable, and a line number, class, and file where the target variable may be found. In one or more alternative embodiments, each error report log entry is machine readable, such that a process or group of processes may modify the application source code using the error report log entry. Becker, fig. 2A and para [0038-0044], In a step 260, a write to a log is enabled with the log index value and variable names within the source code. This generates modified source code. In some embodiments, the LST 170 enables an outputting, such as a write in a source code 105 to generate modified source code 115. In some embodiments, a variable name is appended to the log index value within the modified source code 115. In some embodiments, source code static data and the original logging statement is deleted from the source code.).
Claim 11 is rejected for the reasons set forth hereinabove for claim 1, Ahadian, Lu and Becker teach the computer-implemented method of claim 1, wherein incorporating log information at one or more positions within the source code comprises incorporating the log information in connection with identifying one or more entry and one or more exit points within the source code(Lu, para [0026-0030], In one or more embodiments, information flow relations may be the result explicit flow of information, implicit flow of information, or both. An explicit information flow relation reflects a non-branching path in application source code (108), such that information flows from the source variable to the target variable. An implicit information flow relation reflects a branching path in application source code (108), such that information may flow from the source variable to the target variable depending on the execution of the application source code (108) at runtime. For example, in a portion of application source code (108) containing an assignment from variable X to variable Y if a first condition is true and an assignment from variable X to variable Z if the first condition is false, two implicit information flow relations may result—a first information flow relation with a source of variable X and a target of variable Y and a second information flow relation with a source of variable X and a target of variable Z. Para [0049]. Becker, fig. 2A and para [0038-0044], In a step 260, a write to a log is enabled with the log index value and variable names within the source code. This generates modified source code. In some embodiments, the LST 170 enables an outputting, such as a write in a source code 105 to generate modified source code 115. In some embodiments, a variable name is appended to the log index value within the modified source code 115. In some embodiments, source code static data and the original logging statement is deleted from the source code).
Claim 12 is rejected for the reasons set forth hereinabove for claim 1, Ahadian, Lu and Becker teach the computer-implemented method of claim 1, further comprising: automatically testing at least a portion of the source code subsequent to incorporating the log information (Lu, para [0063-0065], In optional STEP 226, in one or more embodiments of the invention, the compiler compiles the application source code into compiled application source code based on the error report log. In one or more embodiments, compiling the application source code is based on a determination that no error report log entries are generated. For example, if the error report log as generated in STEP 224 is empty or otherwise indicative of no errors, the compiler compiles the application source code. For example, the compiler may compile the application source code into java bytecode. In another embodiment, if the error report log as generated in STEP 224 is not empty, the compiler compiles the application source code with one or more errors.).
Claim 13 is rejected for the reasons set forth hereinabove for claim 1, Ahadian, Lu and Becker teach the computer-implemented method of claim 1, further comprising: automatically training at least a portion of the one or more artificial intelligence techniques based at least in part on feedback related to the incorporating of the log information at the one or more positions within the source code (Lu, para [0064-0066], In optional STEP 228, in one or more embodiments of the invention, the compiler modifies the application source code into modified application source code based on the error report log. In one example, the compiler removes one or more methods from the application source code for which information flow relations associated with that method have generated entries in the error report log. For example, a call to a method in a class with a low capability from a method in a class with a higher integrity requirement may be rewritten or removed. In one or more embodiments, the static program analysis system may prompt a user via an output device to modify the application source code in conjunction with presenting the error report log file to the user via an output device. In this way, the application source code may be improved, and potential security issues may be removed from the application source code as it is modified into modified application source code. Becker, para [0018], In the system 100, a source code 105 is coupled to a preprocessor 110. The preprocessor 110 has a logging statement identifier ("LSI") 120 and a symbol type extractor 130 both coupled to an input that accepts the source code 105. The logging statement identifier ("LSI") 120 is coupled to a logging statement translator 170 ("LST"). The LSI 120 is coupled to a logging dictionary generator ("LDG") 150 through a static branch 127 and a dynamic branch 129. The symbol type extractor 130 is coupled to a symbol table 160. The symbol table 160 is also coupled to the LDG 150. The LDG 150 is also coupled to the LST 170 through a log index value branch 155 and a dynamic value branch 157. The LST 170 has an output, which is a modified source code 115. Para [0032-0042], In one aspect, only the combined data element and the index key value are stored in the logging dictionary 140. This entry in the logging dictionary 140 does not contain or directly reference the logging statement, but that information is passed to the LST 170 to generate the equivalent modified logging statement. The index key value is printed to the log (along with dynamic data) by the modified source code 115 logging statement. When it comes time to "uncompress" the log, the index key is employed to lookup the combined data element to see how the original statement would have printed the equivalent log entry.).
As per claim 14, this is the medium claim to the method claim 1. Therefore, it is rejected for the same reasons as above.
As per claim 15, this is the medium claim to the method claim 2. Therefore, it is rejected for the same reasons as above.
As per claim 16, this is the medium claim to the method claim 3. Therefore, it is rejected for the same reasons as above.
As per claim 17, this is the medium claim to the method claim 4. Therefore, it is rejected for the same reasons as above.
As per claim 18, this is the apparatus claim to the method claim 1. Therefore, it is rejected for the same reasons as above.
As per claim 19, this is the apparatus claim to the method claim 2. Therefore, it is rejected for the same reasons as above.
As per claim 20, this is the apparatus claim to the method claim 3. Therefore, it is rejected for the same reasons as above.
Inquiry
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DUY KHUONG THANH NGUYEN whose telephone number is (571)270-7139. The examiner can normally be reached Monday - Friday 0800-1630.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Lewis Bullock can be reached at 5712723759. 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.
/DUY KHUONG T NGUYEN/ Primary Examiner, Art Unit 2199
Prosecution Insights