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 .
Claims 1-4, and 8-23 are presented for examination.
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.
Claim(s) 1-4, 10-20 and 22-23 is/are rejected under 35 U.S.C. 103 as being unpatentable over Burch (US 6978450) in view of Caron (US 5586328) further in view of de Seabra (US 7735062), Lakhdar (US 20220147442 A1) and Nackman (US 6182281).
Regarding Claim 1, Burch (US 6978450) teaches
A method comprising:
obtaining [a representation of portions of source code], wherein the portions of the source code are associated with respective components of [a software application]( Col 7: ln 30-44, Smartbuild 500 (FIG. 4) is the logic that creates the hash value 206 for the intermediate code stream 122. It is this hash value 206 that is used to determine if the intermediate code stream 122 has changed from the prior compilation represented in the object file 120) Examiner Comments: Burch teaches obtaining an intermediate code stream (representation of portions of source code) associated with a scope/component (e.g., function or basic block) for change detection during compilation
generating a hash digest based upon the source code string (Col 9: ln24-31, Smartbuild 500 computes a hash code 206 (FIG. 2) over the intermediate code stream 122 for the currently defined scope) Examiner Comments: Burch teaches computing a hash digest directly over the code string (intermediate code stream) to represent the portion's content
determining, based on the hash digest and a previous hash digest, that the portions of the source code satisfy a change condition (Col 9: ln 32-50, if it is determined at step 503 that the hash value 206 for the intermediate code stream 122 for the current scope matches the corresponding digital signature 612 (i.e. a hash value) extracted from the preexisting object code file 120, then smartbuild 500 proceeds to step 504 to skip normal processing and then exits at step 509) Examiner Comments: Burch teaches comparing the new hash digest to a previous one stored in the object file to determine if the code has changed (satisfies change condition if unequal, triggering further processing. If hashes do not match, the change condition is satisfied, as processing continues to step 506 for optimization
in response to determining that the change condition is satisfied, updating the repective components of the software application in relation to the portions of the source code (Col 9: ln 3-15, If smartbuild 500 determines that the newly generated intermediate code stream 122 is equal to the intermediate code stream 122 that was generated for the current scope in the object code file 120, then smartbuild 500 indicates this situation to the compiler system 108 to prevent wasting time in a recompilation of identical intermediate code stream 122) Eaminer Comments: Burch teaches updating (recompiling/optimizing) the component only if the hashes differ (change condition satisfied), reusing prior code otherwise. If unequal, proceed to optimization/recompilation, updating the object code.
Burch did not specifically teach
a representation of portions of source code (a syntax tree representation)
a software application (a web application)
generating a source code string based on a textual concatenation of the portions of the source code
wherein obtaining the representation of the portions of the source code comprises: identifying, within a first portion of the portions of the source code, a scoped identifier to a function,
and based on the scoped identifier, parsing the portions of the source code to find a second portion of the portions of the source code that is referenced by the function.
However, Caron (US 5586328) teaches
a representation of portions of source code (Col 9: ln 4-15, In a transition to the next or compiled state 100 (FIG. 4), the compiler performs syntax analysis to group the op-code in the op-code table 84 (FIG. 3) into various syntax structures, and generates excode corresponding to the syntax structures) Examiner Comments: Caron teaches using a syntax tree-like structure (syntax structures from opcodes) as the representation for incremental compilation.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Burch into Caron's in order to improve efficiency in software compilation and development processes as one skilled in the art would integrate Caron's dependency-based scoping and syntax analysis into Burch's hash-based change detection to enhance accuracy in identifying affected code portions, reducing unnecessary recompilations, as motivated by Caron's goal of minimizing compile time via precise dependency tracking (Caron [Summary]).
Burch and Caron did not specifically teach
a software application
generating a source code string based on a textual concatenation of the portions of the source code
wherein obtaining the representation of the portions of the source code comprises: identifying, within a first portion of the portions of the source code, a scoped identifier to a function,
and based on the scoped identifier, parsing the portions of the source code to find a second portion of the portions of the source code that is referenced by the function.
However, de Seabra (US 7735062) teaches
a software application (Col 11: ln 24-39, The executable program can be any executable or interpreted program, for example a web application targeting the .NET™ platform from Microsoft Corporation or the Java 2 Enterprise Edition (J2EE) platform developed by Sun Microsystems) Examiner Comments: de Seabra teaches applying incremental model updates to generate and update components of web applications.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Burch and Caron's teaching into de Seabra's, since applying the combined system to de Seabra's web application context would enable efficient incremental builds for client-server web systems, improving developer productivity and system performance in dynamic environments like web development, as motivated by de Seabra's emphasis on model-driven regeneration for web pages and business rules (de Seabra [Summary]).
Burch, Caron and de Seabra did not specifically teach
generating a source code string based on a textual concatenation of the portions of the source code
wherein obtaining the representation of the portions of the source code comprises: identifying, within a first portion of the portions of the source code, a scoped identifier to a function,
and based on the scoped identifier, parsing the portions of the source code to find a second portion of the portions of the source code that is referenced by the function.
However, Lakhdar teaches
generating a source code string based on a textual concatenation of the portions of the source code ([0248], “in an operation 108, the module 64 transforms the source code 62 into an instrumented intermediate source code, written only in C++ language. This transformation consists in replacing each specific instruction of the V0 language of the source code 62 with the concatenation of the corresponding set of instructions in C++ language and of the set of instrumentation instructions associated with this specific instruction”).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have combined Burch, Caron, de Seabra’s teaching to Lakhdar’s in order to effectively compiles the source code of the computer program to obtain the executable code of computer program, thus reducing the number of data transfers between the main memory and the secondary memory, and hence achieving a measurable level of performance of the electronic computer by providing executable code for computer program, where executable code includes declaration of data structure whose size is acquired only during execution of computer program (Lakhdar [Summary]).
Burch, Caron, de Seabra, and Lakhdar did not specifically teach
wherein obtaining the representation of the portions of the source code comprises: identifying, within a first portion of the portions of the source code, a scoped identifier to a function,
and based on the scoped identifier, parsing the portions of the source code to find a second portion of the portions of the source code that is referenced by the function.
However, Nackman (US 6,182,281) teaches
wherein obtaining the representation of the portions of the source code comprises: identifying, within a first portion of the portions of the source code, a scoped identifier to a function (Col 15, ln 20-51, "C++ declarations encountered during this parse are used to create Declarations inserted into a DeclarationStore representing the function's local scope; C++ expressions encountered during this parse are passed to the TypeAnalyzer. These steps cause additional dependency graph arcs to be added between the implementation and the Declarations needed to parse and type analyze it"; Col. 7, ln. 45-55,"A declaration store object represents a C++ scope. It contains the Declaration objects for all names in the scope that have been successfully processed. These objects are dictionaries; a definition can be retrieved by giving a name to the DeclarationStore. These dictionaries respond to lookup requests using the C++ rules for identifier lookup") Examiner Comments: Nackman teaches that during parsing, the system identifies scoped identifiers (declarations and expressions within a function's local scope) and creates dependency arcs linking those identifiers to their referenced declarations, thereby identifying scoped identifiers to functions within a first portion of source code.
and based on the scoped identifier, parsing the portions of the source code to find a second portion of the portions of the source code that is referenced by the function (Col 15, ln 34-51, "TypeAnalyzer may match function calls to function template names. If the corresponding template instance has not been used before, the body of the template instance is placed on the WorkQueue below any other implementation. These implementations are processed when their WorkQueue entries are encountered during this implementation parse sweep" Col 5, ln 21-37, "Information about the meaning of C++ identifiers is extracted from the programmer's definitions, not from forward declarations for type names, variables, or functions... This requires that all of the definitions must be available simultaneously during compilation, and may be parsed multiple times") Examiner Comments: Nackman teaches that the TypeAnalyzer matches function calls (scoped identifiers) to function template names and then locates and queues the body/definition of the referenced function (a second portion of source code) for parsing, thereby parsing the source code to find a second portion referenced by the function based on the scoped identifier.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Burch, Caron, de Seabra, and Lakhdar with Nackman's, as all are directed to efficient compilation and analysis of source code. Specifically, incorporating Nackman's scoped identifier resolution and function reference parsing into the combined system would provide more fine-grained dependency tracking, ensuring that when a function reference is encountered in one portion of code, the system can accurately locate and include the referenced function definition from another portion of code in the dependency graph, thus improve the accuracy of change detection and reduce unnecessary recompilations, as motivated by Nackman's goal of enabling incremental compilation through precise identifier-to-definition resolution and multi-pass dependency analysis (Nackman, Background/Summary).
Regarding claim 2, Burch, Caron, de Seabra, Lakhdar and Nackman teach
The method of claim 1, further comprising:
obtaining a further representation of further portions of the source code, wherein the further portions of the source code are associated with further respective components of the software application (Burch [Col 9: ln 15-24, The scope can be of varying sizes. The varying degrees of scope include, but are not limited to, individual instructions, basic blocks functions, subroutines, procedures, source-file, and whole-program optimization]) Examiner Comments: Burch teaches applying the process to multiple scopes (further portions/components) independently
generating a further source code string based on a further textual concatenation of the further portions of the source code (Burch [Col 10: ln 6-13, The smartbuild 500 computes a digital signature 611 (i.e. a hash value 206 (FIG. 2)) for the intermediate code stream 122, for the current scope defined]) Examiner Comments: Burch teaches repeating the code string generation for each scope/component
generating a further hash digest based upon the further source code string (Burch [COl 9: ln 24-31, Smartbuild 500 computes a hash code 206 (FIG. 2) over the intermediate code stream 122 for the currently defined scope]) Examiner Comments: Burch teaches generating hashes for each separate scope's code stream
determining, based on the further hash digest and a further previous hash digest, that the further portions of the source code satisfy the change condition (Burch [Col 9: ln32-50, if it is determined at step 503 that the hash value 206 for the intermediate code stream 122 for the current scope matches the corresponding digital signature 612 (i.e. a hash value) extracted from the preexisting object code file 120, then smartbuild 500 proceeds to step 504 to skip normal processing and then exits at step 509]) Examiner Comments: Burch teaches independent change determination for each scope using its own hash comparison
and in response to determining that the change condition is satisfied, updating the further component of the software application in relation to the further portions of the source code ( Burch [ Col 9: ln 3-14, If smartbuild 500 determines that the newly generated intermediate code stream 122 is equal to the intermediate code stream 122 that was generated for the current scope in the object code file 120, then smartbuild 500 indicates this situation to the compiler system 108 to prevent wasting time in a recompilation of identical intermediate code stream 122]) Examiner Comments: Burchteaches updating each changed scope/component separately.
Regarding claim 3, Burch, Caron, de Seabra, Lakhdar and Nackman teach
The method of claim 1, further comprising:
obtaining a further representation of further portions of the source code, wherein the further portions of the source code are associated with further respective components of the software application(Burch [Col 9: ln 15-24, The scope can be of varying sizes. The varying degrees of scope include, but are not limited to, individual instructions, basic blocks functions, subroutines, procedures, source-file, and whole-program optimization]) Examiner Comments: Burch teaches applying the process to multiple scopes (further portions/components) independently;
generating a further source code string based a further textual concatenation of the further portions of the source code (Burch [Col 10: ln 6-13, The smartbuild 500 computes a digital signature 611 (i.e. a hash value 206 (FIG. 2)) for the intermediate code stream 122, for the current scope defined])Examiner Comments: Burch teaches repeating the code string generation for each scope/component
generating a further hash digest based upon the further source code string (Burch [COl 9: ln 24-31, Smartbuild 500 computes a hash code 206 (FIG. 2) over the intermediate code stream 122 for the currently defined scope]) Examiner Comments: Burch teaches generating hashes for each separate scope's code stream
determining, based on the further hash digest and a further previous hash digest, that the further portions of the source code do not satisfy the change condition (Burch [Col 9: ln 32-50, if it is determined at step 503 that the hash value 206 for the intermediate code stream 122 for the current scope matches the corresponding digital signature 612 (i.e. a hash value) extracted from the preexisting object code file 120, then smartbuild 500 proceeds to step 504 to skip normal processing and then exits at step 509]) Examiner Comments: Burch teaches determining no change if hashes match, for each scope independently
and in response to determining that the change condition is not satisfied, refraining from updating the further respective components of the software application in relation to the further portions of the source code (Burch [Col 9: ln 32-50, skip normal processing and then exits at step 509]) Examiner Comments: Burch teaches refraining from recompilation/update if no change is detected.
Regarding claim 4, Burch, Caron, de Seabra, Lakhdar and Nackman teach
The method of claim 1, wherein the source code contains further portions that are not associated with the respective components, and wherein any components of the software application related to the further portions are not updated in response to determining that the change condition is satisfied (Burch [col 3: ln27-38, The present invention extends the use of incremental compilation systems; Col 3: 1-13, isolating the effect of an input file change to those that could potentially change the resulting object code. It is then possible to ignore any change not reflected in the intermediate code generation]) Examiner Comments: Burch teaches that unchanged scopes/portions are ignored, so related components are not updated even if other portions change.
Regarding claim 10, Burch, Caron, de Seabra, Lakhdar and Nackman teach
The method of claim 1, wherein determining that the portions of the source code satisfy the change condition comprises: determining that the previous hash digest does not exist in a hash table that associates the portions of the source code with a hash digest entry for the previous hash digest; and in response to determining that the previous hash digest does not exist in the hash table, inserting the hash digest into the hash digest entry (Burch [Col 9: ln 50-60, smartbuild 500 assigns the current generated hash value 206 to the digital signature 612 in the object code file 120 being built for the current scope, at step 506]) Examiner Comments: Burch teaches inserting the new hash into the entry when building a new scope/object file (no previous exists). This implies for first-time compilation where no previous exists.
Regarding claim 11, Burch, Caron, de Seabra, Lakhdar and Nackman teach
The method of claim 10, wherein determining that the hash digest does not exist in the hash table comprises determining that the hash digest entry for the previous hash digest is blank, empty, or null (Burch [Col 7: ln 30-44, It is this hash value 206 that is used to determine if the intermediate code stream 122 has changed from the prior compilation represented in the object file 120.]) Examiner Comments: Burch teaches checking for prior hash in object file; absence (blank/empty) triggers new insertion. This Implies first-time check where entry is absent/empty.
Regarding claim 12, Burch, Caron, de Seabra, Lakhdar and Nackman teach
The method of claim 1.
Burch did not specifically teach
wherein the representation of the portions of the source code comprises a syntax tree, wherein the syntax tree comprises nodes and links, wherein the nodes represent distinct units of the source code, and wherein links represent references and dependencies within the source code between respective nodes.
However, Caron (US 5586328) teaches
wherein the representation of the portions of the source code comprises a syntax tree, wherein the syntax tree comprises nodes and links, wherein the nodes represent distinct units of the source code, and wherein links represent references and dependencies within the source code between respective nodes (Col 9: ln 4-15, In a transition to the next or compiled state 100 (FIG. 4), the compiler performs syntax analysis to group the op-code in the op-code table 84 (FIG. 3) into various syntax structures, and generates excode corresponding to the syntax structures) Examiner Comments: Caron teaches a syntax tree (syntax structures with nodes as units like procedures/variables, links as dependencies.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Burch into Caron's in order to improve efficiency in software compilation and development processes as one skilled in the art would integrate Caron's dependency-based scoping and syntax analysis into Burch's hash-based change detection to enhance accuracy in identifying affected code portions, reducing unnecessary recompilations, as motivated by Caron's goal of minimizing compile time via precise dependency tracking (Caron [Summary]).
Regarding claim 13, Burch, Caron, de Seabra, Lakhdar and Nackman teach
The method of claim 12.
Burch did not specifically teach
wherein the syntax tree is constructed through identifying scoped identifiers within the portions of the source code, wherein a scoped identifier is a specific part of the source code that is not at a top level of the source code, and is a declaration or link to a declaration of a specific variable or a specific function within the source code.
However, Caron (US 5586328) teaches
wherein the syntax tree is constructed through identifying scoped identifiers within the portions of the source code, wherein a scoped identifier is a specific part of the source code that is not at a top level of the source code, and is a declaration or link to a declaration of a specific variable or a specific function within the source code (Col 6: ln 51-67, Frame dependencies are commonly created by statements declaring local variables of a procedure) Examiner Comments: Caron teaches identifying local (scoped) variables in procedures (not top-level), as declarations/links in the syntax structures.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Burch into Caron's in order to improve efficiency in software compilation and development processes as one skilled in the art would integrate Caron's dependency-based scoping and syntax analysis into Burch's hash-based change detection to enhance accuracy in identifying affected code portions, reducing unnecessary recompilations, as motivated by Caron's goal of minimizing compile time via precise dependency tracking (Caron [Summary]).
Regarding claim 14, Burch, Caron, de Seabra, Lakhdar and Nackman teach
The method of claim 13.
Burch did not specifically teach
wherein the nodes relate to the scoped identifiers, import statements, functions, and variables within the portions of the source code.
However, Caron (US 5586328) teaches
wherein the nodes relate to the scoped identifiers, import statements, functions, and variables within the portions of the source code (Col 12: ln 14-46, local variable declarations (e.g. statement 70 in FIG. 2) which import types create a frame dependency. Additionally, statements calling an imported procedure (e.g. statement 72) create a code dependency) Examiner Comments: Caron teaches nodes for scoped variables, imports, functions, and variables in the dependency graph/syntax structures.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Burch into Caron's in order to improve efficiency in software compilation and development processes as one skilled in the art would integrate Caron's dependency-based scoping and syntax analysis into Burch's hash-based change detection to enhance accuracy in identifying affected code portions, reducing unnecessary recompilations, as motivated by Caron's goal of minimizing compile time via precise dependency tracking (Caron [Summary]).
Regarding claim 15, Burch, Caron, de Seabra, Lakhdar and Nackman teach
The method of claim 1, wherein updating the respective components of the software application in relation to the portions of the source code comprises rebuilding the respective components of the software application in relation to portions of the source code (Burch [Col 3: ln 54-64, llustrated in FIG. 1 is a block diagram of an example of an incremental selective compiler tool 102 that is an element of a compilation system 108 and operates in a computer system 100. The compiler tool 102 enables reuse of parts of object code files 120 resulting from the compilation of one or more source code files 118. More particularly, the compiler tool 102 selectively updates an object code file 120 to reflect semantic changes in the source code file 118 since a prior compilation]) Examiner Comments: Burch teaches rebuilding (selective recompilation) of changed portions.
Regarding claim 16, Burch, Caron, de Seabra, Lakhdar and Nackman teach
The method of claim 15.
Burch and Caron did not specifically teach
wherein rebuilding the respective component of the software application in relation to the portions of the source code comprises compiling the respective component of the software application in relation to the portions of the source code to execute on a target platform.
However, de Seabra (US 7735062) teaches
wherein rebuilding the respective component of the software application in relation to the portions of the source code comprises compiling the respective component of the software application in relation to the portions of the source code to execute on a target platform (Col 23: ln 5-13, The native source code compiler 225 is used to create the executable binary files 226 that actually implement the computer software system behavior in a format that can be hosted and managed by an application server system 229) Examiner Comments: de Seabra teaches compiling to executable for target.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Burch and Caron's teaching into de Seabra's, since applying the combined system to de Seabra's web application context would enable efficient incremental builds for client-server web systems, improving developer productivity and system performance in dynamic environments like web development, as motivated by de Seabra's emphasis on model-driven regeneration for web pages and business rules (de Seabra [Summary]).
Regarding claim 17, Burch, Caron, de Seabra, Lakhdar and Nackman teach
The method of claim 1.
Burch and Caron did not specifically teach
wherein the software application is a web application that is configured to execute at least in part on a client device and to communicate with a server device.
However, de Seabra (US 7735062) teaches
wherein the software application is a web application that is configured to execute at least in part on a client device and to communicate with a server device (Col 23: ln 28-53, The application server system 229 will handle requests from end-users using a Hyper Text Transfer Protocol (HTTP) client system 232, like a web browser) Examiner Comments: de Seabra teaches web applications executing on client (browser) and communicating with server via HTTP.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Burch and Caron's teaching into de Seabra's, since applying the combined system to de Seabra's web application context would enable efficient incremental builds for client-server web systems, improving developer productivity and system performance in dynamic environments like web development, as motivated by de Seabra's emphasis on model-driven regeneration for web pages and business rules (de Seabra [Summary]).
Regarding claim 18, Burch, Caron, de Seabra, Lakhdar and Nackman teach
The method of claim 1.
Burch and Caron did not specifically teach
wherein obtaining the representation of the portions of the source code occurs in response to writing the source code to non-volatile memory.
However, de Seabra (US 7735062) teaches
wherein obtaining the representation of the portions of the source code occurs in response to writing the source code to non-volatile memory (Col 3: ln 30-43, The method includes, prior to the comparing step, the step of storing the modified computer design model in a source control repository) Examiner Comments: de Seabra teaches triggering model processing (obtaining representation) after storing (writing) to non-volatile repository.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Burch and Caron's teaching into de Seabra's, since applying the combined system to de Seabra's web application context would enable efficient incremental builds for client-server web systems, improving developer productivity and system performance in dynamic environments like web development, as motivated by de Seabra's emphasis on model-driven regeneration for web pages and business rules (de Seabra [Summary]).
Regarding Claim 19, is a computer system claim corresponding to the method claim above (Claim 1), and, therefore, is rejected for the same reason set forth in the rejection of Claim 1.
Regarding Claim 20, is a computer-readable medium claim corresponding to the method claim above (Claim 1), and, therefore, is rejected for the same reason set forth in the rejection of Claim 1.
Regarding Claim 22, Burch, Caron, de Seabra, Lakhdar, and Nackman teach
The method of claim 1.
Burch, Caron, de Seabra, and Lakhdar did not specifically teach
wherein the second portion includes a definition of the function.
However, Nackman teaches
wherein the second portion includes a definition of the function (Col 15, ln 34-52, "TypeAnalyzer may match function calls to function template names. If the corresponding template instance has not been used before, the body of the template instance is placed on the WorkQueue") Examiner Comments: Nackman teaches that the second portion found by parsing is the body/definition of the referenced function template instance, which is a definition of the function.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Burch, Caron, de Seabra, and Lakhdar with Nackman's, as all are directed to efficient compilation and analysis of source code. Specifically, incorporating Nackman's scoped identifier resolution and function reference parsing into the combined system would provide more fine-grained dependency tracking, ensuring that when a function reference is encountered in one portion of code, the system can accurately locate and include the referenced function definition from another portion of code in the dependency graph, thus improve the accuracy of change detection and reduce unnecessary recompilations, as motivated by Nackman's goal of enabling incremental compilation through precise identifier-to-definition resolution and multi-pass dependency analysis (Nackman, Background/Summary).
Regarding Claim 23, Burch, Caron, de Seabra, Lakhdar, and Nackman teach
The method of claim 1.
Burch, Caron, de Seabra, and Lakhdar did not specifically teach
wherein the scoped identifier is a parameter of the function within the source code
However, Nackman teaches
wherein the scoped identifier is a parameter of the function within the source code (Col 15, ln 20-33, "C++ declarations encountered during this parse are used to create Declarations inserted into a DeclarationStore representing the function's local scope") Examiner Comments: Nackman teaches that declarations within a function's local scope (including function parameters) are scoped identifiers that are used to build the dependency graph.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Burch, Caron, de Seabra, and Lakhdar with Nackman's, as all are directed to efficient compilation and analysis of source code. Specifically, incorporating Nackman's scoped identifier resolution and function reference parsing into the combined system would provide more fine-grained dependency tracking, ensuring that when a function reference is encountered in one portion of code, the system can accurately locate and include the referenced function definition from another portion of code in the dependency graph, thus improve the accuracy of change detection and reduce unnecessary recompilations, as motivated by Nackman's goal of enabling incremental compilation through precise identifier-to-definition resolution and multi-pass dependency analysis (Nackman, Background/Summary).
Claim(s) 8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Burch (US 6978450) in view of Caron (US 5586328), de Seabra (US 7735062), Lakhdar (US 20220147442 A1), and Nackman (US 6182281) further in view of Schaefer (US 10353702).
Regarding Claim 8, Burch, Caron, de Seabra, Lakhdar and Nackman teach
The method of claim 1.
Burch, Caron, de Seabra, Lakhdar and Nackman did not teach
wherein generating the source code string comprises: traversing the representation of portions of the source code in a depth-first or breadth-first order; and appending the portions to the source code string in the order of the traversal.
However, Schaefer (US 10353702) teaches
wherein generating the source code string comprises: traversing the representation of portions of the source code in a depth-first or breadth-first order; and appending the portions to the source code string in the order of the traversal (Col 6: ln 1-14, For example, the system can use a parser to generate the semantic representation, e.g., an abstract syntax tree (AST), and then generate the signature using the properties of the semantic representation. For example, the system can concatenate names of all nodes in the AST as the semantic representation) Examiner Comments: Schaefer teaches traversing the AST representation (implying an order like depth-first or breadth-first for complete node coverage) and appending/concatenating the node names (portions) into a string in traversal order for signature generation.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combined Burch, Caron, de Seabra, Lakhdar and Nackman's teaching into Schaefer's, as all are directed to efficient source code analysis and compilation. Specifically, incorporating Schaefer's AST concatenation via traversal into Burch's code string generation would provide a semantic-aware method for creating reproducible strings/hashes, reducing false positives in change detection and enabling better clone/similarity handling in large codebases as motivated by Schaefer's goal of unique signatures for static analysis, including clone detection (Schaefer [Summary]).
Claim(s) 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Burch (US 6978450) in view of Caron (US 5586328), de Seabra (US 7735062) Lakhdar (US 20220147442 A1) and Nackman (US 6182281) further in view of Ghose (US 9767271).
Regarding Claim 9, Burch, Caron, de Seabra, Lakhdar and Nackman teach
The method of claim 1.
Burch, Caron, de Seabra, Lakhdar and Nackman did not teach
wherein determining that the portions of the source code satisfy the change condition comprises: determining that the previous hash digest exists in a hash table that associates the portions of the source code with a hash digest entry for the previous hash digest; determining the hash digest matches the previous hash digest; and in response to determining that the hash digest differs from the previous hash digest, overwriting the previous hash digest in the hash digest entry with the hash digest.
However, Ghose (US 9767271) teaches
wherein determining that the portions of the source code satisfy the change condition comprises: determining that the previous hash digest exists in a hash table that associates the portions of the source code with a hash digest entry for the previous hash digest; determining the hash digest matches the previous hash digest; and in response to determining that the hash digest differs from the previous hash digest, overwriting the previous hash digest in the hash digest entry with the hash digest (Col 6: ln 23-43, A secure hash table is created containing a list of secure programs that the user wants to validate prior to execution. The table contains a secure hash value (i.e., a value generated by modification detection code) for each of these programs as originally installed on the computer system. This hash table is stored in protected memory that can only be accessed when the computer system is in system management mode. Following an attempt to execute a secured program, a system management interrupt is generated. An SMI handler then generates a current hash value for the program to be executed. In the event that the current hash value matches the stored hash value, the integrity of the program is guaranteed and it is loaded into memory and executed. If the two values do not match, the user is alerted to the discrepancy and may be given the option to update or override the stored hash value by entering an administrative password) Examiner comments: Interpreting "matches" as likely intended "does not match" based on logical consistency with change detection, as overwriting on match is redundant; prior art teaches overwriting on mismatch for updates. Ghose teaches determining the previous hash exists in the secure hash table associating program portions (source code) with entries, comparing the new/current hash to the previous/stored one, and in response to not matching (satisfying change condition via detected change), overwriting the entry with the new hash (update/override after alert).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Burch, Caron, de Seabra, Lakhdar and Nackman's teaching to Ghose's, as all are directed to efficient and secure handling of source code changes via hashing. Specifically, incorporating Ghose's secure hash table updates on change into Burch's system would provide integrity assurance, allowing safe overwriting after verification to handle legitimate updates while detecting tampering (Ghose [Col 6: ln 23-43]).
Claim(s) 21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Burch (US 6978450) in view of Caron (US 5586328), de Seabra (US 7735062) and Lakhdar (US 20220147442 A1) and Nackman (US 6182281) further in view of Birdeau (US 8136109 B1).
Regarding claim 21, Burch, Caron, de Seabra, Lakhdar and Nackman teach
The method of claim 17.
Burch, Caron, de Seabra, Lakhdar and Nackman did not specifically teach
wherein, the server device determines, while the web application is executing, whether to entirely reload a webpage associated with the web application or to only reload a subset of components of the webpage in response to determining that the portions of the source code satisfy the change condition.
However, Birdeau (US 8136109 B1) teaches
wherein, the server device determines, while the web application is executing, whether to entirely reload a webpage associated with the web application or to only reload a subset of components of the webpage in response to determining that the portions of the source code satisfy the change condition (Col 2, lines 14-27, “In embodiment of the invention manages XML or other hierarchical tagged data in a persistent data store, with the effect of enabling asynchronous communication of data between the server and the client, and with the effect of enabling asynchronous presentation updates at the client without server intervention. This has the effect of allowing the web client to use tagged data objects maintained in the local web browser memory or cache as a query-able database. An embodiment of the invention includes a communication channel between the persistent data store for hierarchical tagged data and the asynchronous presentation updates, with the effect of enabling dynamic partial update of data, or its presentation format, to the user”; Col 10: lines 42-51, “When application layer 320 changes the data or format for presenting the data, these changes are routed through the GUI objects in presentation layer 340. These objects preferably generate dynamic HTML (DHTML) for presentation to the user”; Col 16: lines 4-26, “any object's rendering routine can be invoked so as to only update portions of the application display without requiring a re-generation of the entire application display”; Col 11: lines 15-30, “changes to objects or functionality can also be delivered while the data manipulation application is already running, such as in response to a user request or in response to the server instructing the data manipulation application to update itself”; Col 12: lines 30-36, “Finally, the application layer (or other logic) in the data manipulation application can determine that all or part of the presentation should be changed. In that case, step 430 can occur by itself”) Examiner Comments: Birdeau teaches a server determining (via asynchronous data delivery) dynamic partial updates (only reload subset) to the presentation format or data of a web application at runtime without full reload, in response to changes in tagged data or formatting (change condition in source code portions like XML/JS objects). Further, determining to only reload a subset of components (partial update via DHTML rendering) rather than the entire display (full reload), based on changes to data or format (change condition) while the web application is executing.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have combined Burch, Caron, de Seabra, Lakhdar and Nackman’s teaching to Birdeau’s in order to enable delivering and formatting the data, thus providing a web client with capability of performing the data manipulation application without using resources at the server, or for communication between the client and server by receiving data e.g. data in XML format, data structured in a comma separated value (CSV) format, data structured in name value pairs, and formatting information to allow client-side manipulation of data for automated action e.g. automated scripting, compliance testing, scenario modeling, on data in regulated industry (Birdeau [Summary]).
Response to Arguments
Applicant’s arguments with respect to claims 1-4, and 8-23 have been considered but are moot because the arguments do not apply to the previous cited sections of the references used in the previous office action. The current office action is now citing additional references to address the newly added claimed limitations.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMIR SOLTANZADEH whose telephone number is (571)272-3451. The examiner can normally be reached M-F, 9am - 5pm ET.
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.
/AMIR SOLTANZADEH/Examiner, Art Unit 2191 /WEI Y MUI/Supervisory Patent Examiner, Art Unit 2191