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, 8-22, and 24 are presented for examinations.
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, 22, and 24 is/are rejected under 35 U.S.C. 103 as being unpatentable over Burch (US 6,978,450) in view of Caron (US 5,586,328) further in view of de Seabra (US 7,735,062), Lakhdar (US 2022/0147442 A1), Nackman (US 6,182,281), and Garvin (US 2004/0010780 A1).
Regarding Claim 1, Burch (US 6,978,450) 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 (a representation of portions of source code) associated with a scope or component for change detection during compilation.
generating a hash digest based upon the source code string (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 computing a hash digest directly over the code string (intermediate code stream) that represents the content of the portion.
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 previously stored hash digest so that a mismatch (a satisfied change condition) triggers further processing of the portion.
in response to determining that the change condition is satisfied, updating the respective 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) Examiner Comments: Burch teaches updating (recompiling) the component only when the hashes differ, that is, only when the change condition is satisfied.
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;
identifying, within a first portion of the portions of the source code, a scoped identifier that is a parameter to a function within the 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.
However, Caron (US 5,586,328) 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 structure (syntax structures grouped from op-codes) 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 and reduce 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 (a web application);
generating a source code string based on a textual concatenation of the portions of the source code;
identifying, within a first portion of the portions of the source code, a scoped identifier that is a parameter to a function within the 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.
However, de Seabra (US 7,735,062) 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 the 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 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 and improve 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;
identifying, within a first portion of the portions of the source code, a scoped identifier that is a parameter to a function within the 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.
However, Lakhdar (US 2022/0147442 A1) 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) Examiner Comments: Lakhdar teaches generating a code string by concatenation of the corresponding sets of instructions of the source code portions.
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, and de Seabra's teachings with Lakhdar's in order to effectively compile the source code of the computer program to obtain executable code, thus reducing the number of data transfers between the main memory and the secondary memory and achieving a measurable level of performance of the electronic computer, as motivated by Lakhdar's provision of executable code that includes a declaration of a data structure whose size is acquired only during execution of the computer program (Lakhdar [Summary]).
Burch, Caron, de Seabra, and Lakhdar did not specifically teach
identifying, within a first portion of the portions of the source code, a scoped identifier to a function within the 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.
However, Nackman (US 6,182,281) teaches
identifying, within a first portion of the portions of the source code, a scoped identifier to a function within the source code (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) Examiner Comments: Nackman teaches that during parsing the system identifies scoped identifiers within a function's local scope and links those identifiers to their referenced declarations through dependency graph arcs.
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) Examiner Comments: Nackman teaches matching a function call (scoped identifier) to a function name and then locating and queuing the referenced function body (a second portion) for parsing based on that 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. 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 improving the accuracy of change detection and reducing 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).
Burch, Caron, de Seabra, Lakhdar, and Nackman did not specifically teach that the scoped identifier is a parameter to a function within the source code, that is, identifying a scoped identifier based on its status as a parameter to a function and, based on that identifier, parsing the portions of the source code to find a second portion referenced by the function.
However, Garvin (US 2004/0010780 A1) teaches
identifying, within a first portion of the portions of the source code, a scoped identifier that is a parameter to a function within the source code ([0072], if one or more of the parameters being received is an identifier expression of an unknown type, or a function call with an unknown return type, then the type resolver 40 is required to make a best guess, or attempt to resolve the type of the parameter) Examiner Comments: Garvin teaches identifying a parameter received in a function call that is an identifier expression, which is a scoped identifier that is a parameter to a function within the 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 ([0060], the type resolver 40 uses the index files created in step 42 to process the Unresolved XREFs file 24. Processing consists of namespace look-up, identifying class members/data, or identifying global variable usage) Examiner Comments: Garvin teaches that, based on the parameter identifier, the type resolver processes the cross-references through namespace look-up to locate the declaration or definition that the identifier within the function references (a second portion).
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 with Garvin's, as all are directed to parsing and analyzing source code to resolve identifier references. Incorporating Garvin's resolution of a parameter received in a function call, where the parameter is an identifier expression, to its referenced declaration would enable the combined system to identify a scoped identifier based on its status as a parameter to a function and to locate the declaration or definition that the parameter references, thereby improving the completeness and accuracy of the cross-reference and dependency information used for change detection and reducing unnecessary recompilations, as motivated by Garvin's goal of generating complete and accurate source code cross-reference information by resolving identifier expressions, including function and method parameters, to their declarations (Garvin, [0072] and [Summary]).
Regarding Claim 2, Burch, Caron, de Seabra, Lakhdar, Nackman, and Garvin 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 and 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 or 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 a hash 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: 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 an 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 respective components 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: Burch teaches updating each changed scope or component separately.
Regarding Claim 3, Burch, Caron, de Seabra, Lakhdar, Nackman, and Garvin 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 and 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 or 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 a hash 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 when the 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 recompiling or updating when no change is detected.
Regarding Claim 4, Burch, Caron, de Seabra, Lakhdar, Nackman, and Garvin 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: ln. 27-38 and Col. 3: ln. 1-13, The present invention extends the use of incremental compilation systems ... 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 portions are ignored, so components related to those further portions are not updated even when other portions change.
Regarding Claim 10, Burch, Caron, de Seabra, Lakhdar, Nackman, and Garvin 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 scope for which no previous hash exists.
Regarding Claim 11, Burch, Caron, de Seabra, Lakhdar, Nackman, and Garvin 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 a prior hash in the object file, where the absence of such an entry triggers a new insertion.
Regarding Claim 12, Burch, Caron, de Seabra, Lakhdar, Nackman, and Garvin 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 5,586,328) 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 of syntax structures in which nodes are distinct code units and links represent 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 and Caron 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 and improve 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 13, Burch, Caron, de Seabra, Lakhdar, Nackman, and Garvin 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 5,586,328) 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) variable declarations within procedures that are not at the top level as declarations or links within 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 and Caron 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 and improve 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 14, Burch, Caron, de Seabra, Lakhdar, Nackman, and Garvin 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 5,586,328) 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 relating to scoped variables, imports, functions, and variables within the dependency 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 and Caron 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 and improve 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 15, Burch, Caron, de Seabra, Lakhdar, Nackman, and Garvin 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 the portions of the source code (Burch, Col. 3: ln. 54-64, Illustrated 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 (selectively recompiling) the changed portions.
Regarding Claim 16, Burch, Caron, de Seabra, Lakhdar, Nackman, and Garvin teach
The method of Claim 15.
Burch and Caron did not specifically teach
wherein rebuilding the respective components of the software application in relation to the portions of the source code comprises compiling the respective components of the software application in relation to the portions of the source code to execute on a target platform.
However, de Seabra (US 7,735,062) teaches
wherein rebuilding the respective components of the software application in relation to the portions of the source code comprises compiling the respective components 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 an executable for a target platform.
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 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, 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, Nackman, and Garvin 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 7,735,062) 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 a web application that executes on a client (browser) and communicates with a 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 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, 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, Nackman, and Garvin 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 7,735,062) 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 the representation) after storing (writing) the source to a 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 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, 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 computing system claim corresponding to the method claim above (Claim 1) and, therefore, is rejected for the same reasons set forth in the rejection of Claim 1.
Regarding Claim 20, is a non-transitory computer-readable medium claim corresponding to the method claim above (Claim 1) and, therefore, is rejected for the same reasons set forth in the rejection of Claim 1.
Regarding Claim 22, Burch, Caron, de Seabra, Lakhdar, Nackman, and Garvin 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 (US 6,182,281) 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 located by parsing is the body or definition of the referenced 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, in order to accurately locate the referenced function definition from another portion of code, as motivated by Nackman's goal of enabling incremental compilation through precise identifier-to-definition resolution (Nackman, Background/Summary).
Regarding Claim 24, the computing system recites operations corresponding to the method steps of Claim 2 and, therefore, is rejected for the same reasons set forth in the rejection of Claim 2 above.
Claim(s) 8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Burch (US 6,978,450) in view of Caron (US 5,586,328), de Seabra (US 7,735,062), Lakhdar (US 2022/0147442 A1), Nackman (US 6,182,281), and Garvin (US 2004/0010780 A1) further in view of Schaefer (US 10,353,702).
Regarding Claim 8, Burch, Caron, de Seabra, Lakhdar, Nackman, and Garvin teach
The method of Claim 1.
Burch, Caron, de Seabra, Lakhdar, Nackman, and Garvin did not teach
wherein generating the source code string comprises: traversing the representation 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 10,353,702) teaches
wherein generating the source code string comprises: traversing the representation 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 and appending or concatenating the node names 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 combine Burch, Caron, de Seabra, Lakhdar, Nackman, and Garvin's teachings with Schaefer's, as all are directed to efficient source code analysis and compilation. Incorporating Schaefer's AST concatenation via traversal into the combined code string generation would provide a semantic-aware method for creating reproducible strings and hashes, reducing false positives in change detection, as motivated by Schaefer's goal of generating 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 6,978,450) in view of Caron (US 5,586,328), de Seabra (US 7,735,062), Lakhdar (US 2022/0147442 A1), Nackman (US 6,182,281), and Garvin (US 2004/0010780 A1) further in view of Ghose (US 9,767,271).
Regarding Claim 9, Burch, Caron, de Seabra, Lakhdar, Nackman, and Garvin teach
The method of Claim 1.
Burch, Caron, de Seabra, Lakhdar, Nackman, and Garvin 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 9,767,271) 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 ... 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: Ghose teaches a hash table associating program portions with entries, comparing the current hash to the stored hash, and overwriting the entry with the new hash when a change is detected.
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, Nackman, and Garvin with Ghose's, as all are directed to efficient and secure handling of source code changes via hashing. Incorporating Ghose's secure hash table update on change into the combined system would provide integrity assurance and allow 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 6,978,450) in view of Caron (US 5,586,328), de Seabra (US 7,735,062), Lakhdar (US 2022/0147442 A1), Nackman (US 6,182,281), and Garvin (US 2004/0010780 A1) further in view of Birdeau (US 8,136,109 B1).
Regarding Claim 21, Burch, Caron, de Seabra, Lakhdar, Nackman, and Garvin teach
The method of Claim 17.
Burch, Caron, de Seabra, Lakhdar, Nackman, and Garvin 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 8,136,109 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: ln. 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 ... 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) Examiner Comments: Birdeau teaches determining whether to update the presentation entirely or to perform a dynamic partial update of a subset of components of the webpage.
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, Nackman, and Garvin with Birdeau's in order to enable dynamic partial updates of the presentation, thereby reducing the amount of data reloaded and improving responsiveness of the web application, as motivated by Birdeau's goal of asynchronous presentation updates at the client without full server intervention (Birdeau [Summary]).
Response to Arguments
Applicant’s arguments with respect to claims 1-4, 8-22, and 24 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
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
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 /Ted T. Vo/Primary Examiner, Art Unit 2191
Prosecution Insights