DETAILED ACTION
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 .
Claim Objections
Claims 11-19 are objected to because of the following informalities:
a. Claims 11 and 12 recite on Lines 14 and 2, respectively: “outputting dynamic log data” which the Office believes should be “outputting the dynamic log data,” in view of the recited “dynamic log data” of Claim 11 Line 10.
b. Claims 11, 18 and 19 recite on Lines 9, 8 and 10: “each log statement of the set of log statements” which the Office believes should be “each of the log statements of the set of log statements”.
c. Claim 13, Line 8 recites: “information” which the Office believes should be “the information”.
d. Claim 17, Line 1 recites: “the log data types” which the Office believes should be “the [[log]] log-statement-argument data types”.
e. Claims 18 and 19 recite on Lines 13 and 15, respectively: “outputting dynamic log data” which the Office believes should be “outputting the dynamic log data,” in view of the recited “dynamic log data” of Claims 18 and 19, Lines 10 and 11, respectively.
f. Claims 12-17 are also objected to since they depend from objected Claim 11, and as such inherit the same deficiencies.
Appropriate correction is required.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim 11, 16 and 18 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Becker (US PGPUB 2009/0007065; hereinafter “Becker”).
Claim 11: (New)
Becker teaches a method for transferring log data from an execution of a computer program, comprising the following steps:
generating an indexed list of identifiers of user-defined log-statement-argument data types ([0038] “Turning now to FIG. 2A, illustrated is a flow diagram of an embodiment of a method 200 for inserting a log index value and variable names into source code.” [0043] “In a step 250, a log index value, associated with the correlated combined data element and the logging statement, is generated. In some embodiments, this can occur by the LDG 150. In some embodiments, log index value is written to a logging dictionary 140 during a generation of the modified source code 115.”);
before execution of the program, for each log statement of a set of log statements for outputting log data that is contained in the program, transferring static log data to a log data receiver, wherein the static log data are log data that, from execution to execution of the program, remain the same for the log statement ([0021] “Static data may generally be defined as time invariant data that does not change whenever a given print/output occurs for a given line of code.” [0031] “the LDG 150 determines whether the logging dictionary 140 contains an entry that has the same combined data element entered under the associated logging statement. If the logging dictionary 140 does not have the same combined data element entered under the associated logging statement, the LDG 150 generates a logging index value that serves as a key to the logging dictionary 140 for that combined data element. The logging index value is typically unique for a given software code. The LDG 150 then stores the logging index value and its correlated static data element into the logging dictionary 140,” wherein the “correlated static data element” and “preprocessor 110,” comprising the “logging dictionary” as shown in Fig. 1, are the claimed “static log data” and “log data receiver” respectively.); and
upon execution of the program, for each log statement of the set of log statements that is executed upon execution of the program, transferring dynamic log data for the log statement, wherein the dynamic log data are log data that may vary from execution to execution of the program, and wherein, in response to the log statement using one of the user-defined log-statement-argument data types for outputting dynamic log data, the dynamic log data contain an index of the identifier of the log-statement-argument data type ([0005] “An approach to reducing the amount of data logged is to generate a key to represent the static data, such as an arbitrary but unique number, and log the key and dynamic data values instead of the original text log data. For instance, an ‘fprintf(‘error in Memory Area % d’, errNo)’ where the format string ‘error in Memory Area % d’ and the name, type, and size of the variable ‘errNo’ would be keyed as a key 4678 to represent the static information, and the current value associated with the name ‘errNo’ is dynamic and is generated at runtime and had the value 53 at runtime. 4678, 53 would then be output to an error log in binary form,” wherein “53” is the “dynamic log data” and “key 4678” is the “index”. The key being the index, i.e. [0031] “the LDG 150 generates a logging index value that serves as a key.”).
Claim 16: (New)
Becker teaches all the limitations of claim 11 as described above, and Becker further teaches:
wherein the static log data are: (i) a location of the log statement, and/or (ii) a channel of a log message output by the log statement, and/or (iii) an argument layout of the log statement ([0057] “the associated static data can be selected from the group consisting of: a line number associated with the logging statement in the source code…,” wherein the “line number” is the “location of the log statement”.).
Claim 18: (New)
With regard to Claim 18, this claim is equivalent in scope to Claim 11 rejected above, merely having a different independent claim type, and as such Claim 18 is rejected under the same grounds and for the same reasons as discussed above with regard to Claim 11.
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 12-14 are rejected under 35 U.S.C. 103 as being unpatentable over Becker as applied to Claim 1 above, and further in view of Enright et al. (US PGPUB 2016/0140025; hereinafter “Enright”).
Claim 12: (New)
Becker teaches all the limitations of claim 11 as described above, and Becker further teaches:
wherein when the log statement uses one of the user-defined log-statement-argument data types for outputting dynamic log data, the dynamic log data contain raw data for the log-statement-argument data type ([0005] “For instance, an ‘fprintf(‘error in Memory Area % d’, errNo)’ where… the current value associated with the name ‘errNo’ is dynamic and is generated at runtime and had the value 53 at runtime. 4678, 53 would then be output to an error log in binary form,” wherein “53” is the “raw data”).
With further regard to Claim 12, Becker does not teach the following, however, Enright teaches:
the dynamic log data contain an indication of a data volume of the raw data ([0086] “Trace data is in essence a copy of the original data relating to the operations. Trace data may however include information indicating the type, size, format, etc. of the original data which may… be provided in addition to, the copy of the original data,” wherein “information indicating the… size” is the “volume of the raw data” and further wherein the “Trace data” is equivalent to the “log data” as taught above in Becker.).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Becker with the log data size information as taught by Enright as this “may further assist in identifying patterns in the trace data” (Enright [0044]).
Claim 13: (New)
Becker in view of Enright teaches all the limitations of claim 12 as described above. Becker teaches further comprising:
transferring the dynamic log data via a communication channel ([0047] “In step 280, as a result of running the executable file based on the modified source code… dynamic data associated with said log index number is outputted into the log,” wherein “running the executable file” is performed via the associated system processor and the “log” is necessarily stored in a memory storage of some type, wherein the communication bus between the system processor and memory storage is the “communication channel”.);
receiving the dynamic log data by the log data receiver ([0005] “the current value associated with the name ‘errNo’ is dynamic and is generated at runtime and had the value 53 at runtime. 4678, 53 would then be output to an error log in binary form.” ”[0048] “a different executable program, (i.e., not the same one in step 270) that reads the output log.”);
checking whether the received dynamic log data contain an index of a log- statement-argument data type ([0032] “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.” [0053] “In a step 340, the method 300 determines whether or not the combined data element is found in the log dictionary.”); and
in response to the dynamic log data containing an index of a log-statement- argument data type, obtaining information about the log-statement-argument data type and converting the dynamic log data into a data structure according to information about the log-statement-argument data type ([0048] “the log index value, correlated to the combined data element, is employed to convert into human-readable log the static data and the associated dynamic data that were also output into the compressed, binary log. For instance, the binary log could read 45678 3456, which could be interpreted as ‘Error in memory location 3456’… This can be performed by a different executable program, (i.e., not the same one in step 270) that reads the output log, and with the logging dictionary, does the converting of the binary log into something that is readily human understandable (e.g., in ASCII text format, as opposed to binary format).”).
Claim 14: (New)
Becker in view of Enright teaches all the limitations of claim 13 as described above. Becker further teaches:
wherein the information about the log-statement-argument data type includes designations of elements of the log-statement-argument data type ([0023] “One example of such a logging statement in the C programming language to be found in the source code 105 might be:” [0024] “fprintf (LOG, ‘time: % d file: % s line: % d Error occurred while processing message from % d\n’, time( ), _FILE_, _LINENO_, user); In this example, the static data includes the name of the file descriptor (LOG), the format specification, the static values _FILE_ and _LINENO_ information, and the names and sizes of the variables (time( ) and user) used to represent future dynamic values,” wherein the “name of the file descriptor (LOG)…[and] the static values _FILE_ and _LINENO_ information, and the names and sizes of the variables (time( ) and user),” are the “designations of elements.”).
Claim 15 is rejected under 35 U.S.C. 103 as being unpatentable over Becker as applied to Claim 1 above, and further in view of Fliess et al. (US PGPUB 2012/0060142; hereinafter “Fliess”).
Claim 15: (New)
Becker teaches all the limitations of claim 11 as described above. Becker does not teach the following, however, Fliess teaches:
wherein the identifier of each log-statement-argument data type is a hash of a syntax tree of the log-statement-argument data type ([0178] “Abstract Syntax Tree (AST) based matching is used where several open source C# parser libraries support conversion of source code into ASTs using AST conversion module 147. Programs have structure induced by the grammar rules of the language. The clone detection module 148 is operative to use this to find clones efficiently by hashing on arbitrary substructures of the program (i.e. identifiers, expressions, statements, declarations, function headers and statement sequences) encoded as compiler data structures called abstract syntax trees (ASTs).”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Becker with the hash-based identifier as taught by Fliess since “the clone detection module is capable of finding clones regardless of program formatting” (Fliess [0179]), thereby enabling the identifiers, i.e. the “log index values” in Becker, to be matched more reliably.
Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Becker as applied to Claim 1 above, and further in view of Tsyganskiy et al. (US PGPUB 2006/0293934; hereinafter “Tsyganskiy”).
Claim 17: (New)
Becker teaches all the limitations of claim 11 as described above. Becker does not teach the following, however, Tsyganskiy teaches:
wherein the log data types are classes of an object-oriented programming language ([0050] “an object-oriented language class, such as Java.TM. class.” [0210] “the system categorizes the log information according to data object classes, associating log entries where a data object of a given class was accessed (e.g., created, deleted, changed, read, etc.) with a category for that given class.” [0228] “the log entries contain information indicating how the entry affects the objects of each data class that it uses.” [0237] “For example, many applications (e.g., a Java.TM. program application) may be configured to generate, (or utility programs can be used to generate), execution flow logs (or live execution information) containing information regarding affected data classes and the lifecycle of data objects during application execution.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Becker with the log data types being classes as taught by Tsyganskiy as this “allows a user to efficiently trace how a data object is changed during execution of an application, determine where a problem occurs, and debug the application” (Tsyganskiy [0222]).
Claim 19 is rejected under 35 U.S.C. 103 as being unpatentable over Becker in view of Enright.
Claim 19: (New)
Becker teaches a causing one or more processors to perform the following steps ([0038] “FIG. 2A, illustrated is a flow diagram of an embodiment of a method 200 for inserting a log index value and variable names into source code. The method 200 can generate modified source code. The method can be computer-implemented.”):
generating an indexed list of identifiers of user-defined log-statement-argument data types ([0038] “Turning now to FIG. 2A, illustrated is a flow diagram of an embodiment of a method 200 for inserting a log index value and variable names into source code.” [0043] “In a step 250, a log index value, associated with the correlated combined data element and the logging statement, is generated. In some embodiments, this can occur by the LDG 150. In some embodiments, log index value is written to a logging dictionary 140 during a generation of the modified source code 115.”);
before execution of the program, for each log statement of a set of log statements for outputting log data that is contained in the program, transferring static log data to a log data receiver, wherein the static log data are log data that, from execution to execution of the program, remain the same for the log statement ([0021] “Static data may generally be defined as time invariant data that does not change whenever a given print/output occurs for a given line of code.” [0031] “the LDG 150 determines whether the logging dictionary 140 contains an entry that has the same combined data element entered under the associated logging statement. If the logging dictionary 140 does not have the same combined data element entered under the associated logging statement, the LDG 150 generates a logging index value that serves as a key to the logging dictionary 140 for that combined data element. The logging index value is typically unique for a given software code. The LDG 150 then stores the logging index value and its correlated static data element into the logging dictionary 140,” wherein the “correlated static data element” and “preprocessor 110,” comprising the “logging dictionary” as shown in Fig. 1, are the claimed “static log data” and “log data receiver” respectively.); and
upon execution of the program, for each log statement of the set of log statements that is executed upon execution of the program, transferring dynamic log data for the log statement, wherein the dynamic log data are log data that may vary from execution to execution of the program, and wherein, in response to the log statement using one of the user-defined log-statement-argument data types for outputting dynamic log data, the dynamic log data contain an index of the identifier of the log-statement-argument data type ([0005] “An approach to reducing the amount of data logged is to generate a key to represent the static data, such as an arbitrary but unique number, and log the key and dynamic data values instead of the original text log data. For instance, an ‘fprintf(‘error in Memory Area % d’, errNo)’ where the format string ‘error in Memory Area % d’ and the name, type, and size of the variable ‘errNo’ would be keyed as a key 4678 to represent the static information, and the current value associated with the name ‘errNo’ is dynamic and is generated at runtime and had the value 53 at runtime. 4678, 53 would then be output to an error log in binary form,” wherein “53” is the “dynamic log data” and “key 4678” is the “index”. The key being the index, i.e. [0031] “the LDG 150 generates a logging index value that serves as a key.”).
With further regard to Claim 19, Becker does not teach the following, however, Enright teaches:
A non-transitory computer-readable medium on which are stored instructions for transferring log data from an execution of a computer program, the instructions, when executed by one or more processors, causing the one or more processors to perform the steps ([0066] “The invention also provides a computer program or a computer program product for carrying out any of the methods described herein, and a computer-readable medium having stored thereon a program for carrying out any of the methods described herein. A computer program embodying the invention may be stored on a computer-readable medium.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Becker to use a computer-readable medium to implement the method steps, as taught by Enright, since it is well known in the art that “the various features may be implemented in hardware, or as software modules running on one or more processors” (Enright [0066]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure is as follows:
Gholamian et al. (“A Comprehensive Survey of Logging in Software: From Logging Statements Automation to Log Mining and Analysis,” 2021) discusses contemporary logging practices and log statement mining and monitoring techniques and their applications such as in system failure detection and diagnosis, including discussion regarding the intermixing of both static and dynamic log content.
O’Dowd et al. (US Patent 9,898,385) discloses a system configured to replay and reconstruct execution events and system states in real time or substantially in real time using logged execution data, wherein a compiler can be configured to structure the instrumentation to log only the dynamic data and a unique identifier representing the logging point.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Joanne G. Macasiano whose telephone number is (571)270-7749. The examiner can normally be reached Monday to Thursday, 10:30 AM to 6:00 PM Eastern Standard Time.
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, Bradley Teets can be reached at (571) 272-3338. 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.
/JOANNE G MACASIANO/ Examiner, Art Unit 2197
Prosecution Insights