DETAILED ACTION
This Action is a response to the filing received 13 February 2024. Claims 1-20 are presented for examination.
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 .
Priority
Applicant’s claim for the benefit of a prior-filed application under 35 U.S.C. 119(e) or under 35 U.S.C. 120, 121, 365(c), or 386(c) is acknowledged.
Claim Objections
Claim 1 is objected to because of the following informalities: at lines 2-3, “process the source code into an index structures” should be corrected to “process source code into an index structure”; line 4 should be corrected to “obtaining the source code”; and line 5 should be corrected to “building the index structure by”.
Claim 5 is objected to because of the following informalities: at lines 1-2, “processors further configured” should be corrected to “processors are further configured” and at line 2 “building an index structure” should be corrected to “building the index structure”.
Claim 6 is objected to because of the following informalities: at lines 1-2, “processors further configured” should be corrected to “processors are further configured”.
Claim 7 is objected to because of the following informalities: at lines 1-2, “processors further configured” should be corrected to “processors are further configured”.
Claim 17 is objected to because of the following informalities: at line 1, “further” should be corrected to “further comprising”.
Claim 18 is objected to because of the following informalities: at lines 1-2, “building an index structure” should be corrected to “building the index structure”.
Appropriate correction is required.
Claim Rejections - 35 USC § 103
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 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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. § 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-20 are rejected under 35 U.S.C. § 103 as being unpatentable over R. Koschke, "Clone Detection Using Abstract Syntax Suffix Trees," 2006 13th Conference on Reverse Engineering, Benevento, Italy, 2006, pp. 253-262 (“Koschke”) in view of Tiffe et al., U.S. 8,819,856 B1 (“Tiffe”) and Sengupta et al., U.S. 11,675,584 B1 (“Sengupta”).
Regarding claim 1, Koschke teaches: … indexing source code (Koschke, e.g., p. 3, § 3 “Approach”, “our approach. In inter-system clone search …”), comprising: … process source code into an index structures through the steps of:
obtaining source code (Koschke, e.g., p. 3, § 3 “Approach”, “generate the suffix tree for either the subject system or the corpus … for a system with 10 MLOC code …”); and
building an index structure by: parsing the source code to generate one or more abstract syntax trees (ASTs) (Koschke, e.g., p. 4, § 3 “Approach”, “The algorithm consists of the following steps: 1. parse program and generate AST …”);
linearizing subtrees of the ASTs, each subtree having one or more elements thereof (Koschke, e.g., p. 4, § 3 “Approach”, “The algorithm consists of the following steps: … 2. serialize AST …”);
building a trie from the linearized subtrees (Koschke, e.g., p. 2, § 2.1 “Token-Suffix-Tree based Detection”, “Efficient token-based clone detection is based on suffix trees … A suffix tree is a representation of a string as a trie where every suffix is presented through a path from the root to a leaf. The edges are labeled with the substrings … Suffix trees are linear in space with respect to the sting length (the edge labels are stored as indexes of start and end token of a substring …” Examiner’s note: the “substrings” of Koschke may refer to the symbols, rather than sequences of symbols, consistent with the description in Applicant’s Spec. at, e.g., 4th para. of p. 3 and FIG. 4; however, a suffix tree is also generally known1 as a type of compressed trie), wherein the trie is comprised of a plurality of nodes and one or more edges (Koschke, e.g., p. 4, § 3 “Approach”, “The algorithm consists of the following steps: … 3. apply suffix tree detection … Step (3) has been described in Section 2.1 …” See also, e.g., p. 2, § 2.1 “Token-Suffix-Tree based Detection”, “Efficient token-based clone detection is based on suffix trees … A suffix tree is a representation of a string as a trie where every suffix is presented through a path from the root to a leaf. The edges are labeled with the substrings … Suffix trees are linear in space with respect to the string length (the edge labels are stored as indexes of start and end token of a substring …”).
Koschke does not more particularly teach that the method for generating an index structure for source code is implemented on a computer system. However, Tiffe does teach: A system for [indexing source code], comprising: one or more processors that are configured to [process source code into an index structure] (Tiffe, e.g., Tiffe, e.g., 6:46-56, “index 150 and code storage index 132 may be stored in memory 114, for example in main memory or in disk memory. In some implementations the temporary index 150, the code storage index 132, and the code storage system 134 may be stored in a memory device external to computing device 100. Code storage index 132 and temporary index 150 need not be stored in the same memory device or in the same computing device …”) for the purpose of preventing any portion of source code from a protected code location from being copied to unauthorized locations and to report non-compliant instances of the use of source code snippets (Tiffe, e.g., 3:67-5:6).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method for detecting source code clones as taught by Koschke to provide that the method for generating an index structure for source code is implemented on a computer system because the disclosure of Tiffe shows that it was known to those of ordinary skill in the pertinent art to improve a system and method for detecting source code clones to provide that the method for generating an index structure for source code is implemented on a computer system for the purpose of preventing any portion of source code from a protected code location from being copied to unauthorized locations and to report non-compliant instances of the use of source code snippets (Tiffe, Id.).
Koschke in view of Tiffe does not more particularly teach adding positions of elements of the subtrees in the source code to edges and/or nodes of the trie. However, Sengupta does teach: adding one or more positions of elements of the subtrees within the source code to edges and nodes of the trie, the one or more positions associated with one or more edges, one or more of the plurality of nodes, or both one or more edges and one or more of the plurality of nodes of the trie (Sengupta, e.g., FIG. 6; see also, e.g., 16:1-17, “nodes in the tree data structure … providing visual indicators of the dependent relationships between and among the nodes, and in turn between and among the variables and constants initialized and defined at the lines of the source code that correspond to each node …”) for the purpose of annotating a tree representation of a codebase to facilitate user understanding of code (Sengupta, e.g., 15:25-17:43).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method for detecting source code clones as taught by Koschke in view of Tiffe to provide for adding positions of elements of the subtrees in the source code to edges and/or nodes of the trie because the disclosure of Sengupta shows that it was known to those of ordinary skill in the pertinent art to improve a system and method for generating tree representations of source code and/or source code traces to provide for adding positions of elements of the subtrees in the source code to edges and/or nodes of the trie for the purpose of annotating a tree representation of a codebase to facilitate user understanding of code (Sengupta, Id.).
Claims 8 and 15 are rejected for the reasons given in the rejection of claim 1 above. Examiner notes that with respect to claim 8, Tiffe further teaches: A non-transitory computer readable medium having instructions stored thereon that, when executed by a computing device, cause the computing device to index source code (Tiffe, e.g., Tiffe, e.g., 6:46-56, “index 150 and code storage index 132 may be stored in memory 114, for example in main memory or in disk memory. In some implementations the temporary index 150, the code storage index 132, and the code storage system 134 may be stored in a memory device external to computing device 100. Code storage index 132 and temporary index 150 need not be stored in the same memory device or in the same computing device …”) by performing operations comprising the steps of: [[[the operations performed by the system of claim 1]]]; and with respect to claim 15, Tiffe further teaches: A computer-implemented method for indexing source code (Tiffe, e.g., Tiffe, e.g., 6:46-56, “index 150 and code storage index 132 may be stored in memory 114, for example in main memory or in disk memory. In some implementations the temporary index 150, the code storage index 132, and the code storage system 134 may be stored in a memory device external to computing device 100. Code storage index 132 and temporary index 150 need not be stored in the same memory device or in the same computing device …”), comprising: [[[the operations performed by the system of claim 1]]].
Regarding claim 2, the rejection of claim 1 is incorporated, and Koschke further teaches: wherein the index structure comprises the trie (Koschke, e.g., p. 2, § 2.1 “Token-Suffix-Tree based Detection”, “Efficient token-based clone detection is based on suffix trees … A suffix tree is a representation of a string as a trie where every suffix is presented through a path from the root to a leaf. The edges are labeled with the substrings … Suffix trees are linear in space with respect to the sting length (the edge labels are stored as indexes of start and end token of a substring …”).
Claims 9 and 16 are rejected for the additional reasons given in the rejection of claim 2 above.
Regarding claim 3, the rejection of claim 1 is incorporated, and Koschke further teaches: wherein the index structure is compressed (Koschke, e.g., p. 2, § 2.1 “Token-Suffix-Tree based Detection”, “Efficient token-based clone detection is based on suffix trees … A suffix tree is a representation of a string as a trie where every suffix is presented through a path from the root to a leaf. The edges are labeled with the substrings … Suffix trees are linear in space with respect to the sting length (the edge labels are stored as indexes of start and end token of a substring …” Examiner’s note: the “substrings” of Koschke may refer to the symbols, rather than sequences of symbols, consistent with the description in Applicant’s Spec. at, e.g., 4th para. of p. 3 and FIG. 4; however, a suffix tree is also generally known2 as a type of compressed trie).
Claim 10 is rejected for the additional reasons given in the rejection of claim 3 above.
Regarding claim 4, the rejection of claim 3 is incorporated, and Koschke further teaches: wherein the trie is compressed, and the index structure is based on the compressed trie (Koschke, e.g., p. 2, § 2.1 “Token-Suffix-Tree based Detection”, “Efficient token-based clone detection is based on suffix trees … A suffix tree is a representation of a string as a trie where every suffix is presented through a path from the root to a leaf. The edges are labeled with the substrings … Suffix trees are linear in space with respect to the sting length (the edge labels are stored as indexes of start and end token of a substring …” Examiner’s note: the “substrings” of Koschke may refer to the symbols, rather than sequences of symbols, consistent with the description in Applicant’s Spec. at, e.g., 4th para. of p. 3 and FIG. 4; however, a suffix tree is also generally known3 as a type of compressed trie).
Claims 11 and 17 are rejected for the additional reasons given in the rejection of claim 4 above.
Regarding claim 5, the rejection of claim 1 is incorporated, and Koschke further teaches: wherein the one or more processors further configured to perform the step of building an index structure by including one or more code bases (Koschke, e.g., p. 3, § 3 “Approach”, “generate the suffix tree for either the subject system or the corpus … for a system with 10 MLOC code …”).
Regarding claim 6, the rejection of claim 5 is incorporated, and Koschke further teaches: wherein the one or more processors further configured to perform the step of detecting code clones in the one or more code bases (Koschke, e.g., p. 3, § 3 “Approach”, “our approach. In inter-system clone search … take every file of the corpus and compare it against the suffix tree. This steps retrieves all subsequences of the file also contained in at least one file represented in the suffix tree, that is, the subject system …”).
Regarding claim 7, the rejection of claim 5 is incorporated, and Koschke further teaches: wherein the one or more processors further configured to perform the step of searching for a code fragment in the one or more code bases (Koschke, e.g., p. 3, § 3 “Approach”, “our approach. In inter-system clone search … take every file of the corpus and compare it against the suffix tree. This steps retrieves all subsequences of the file also contained in at least one file represented in the suffix tree, that is, the subject system …”).
Claims 12-14 and 18-20 are rejected for the additional reasons given in the rejections of claims 5-7 above.
Conclusion
Examiner has identified particular references contained in the prior art of record within the body of this action for the convenience of Applicant. Although the citations made are representative of the teachings in the art and are applied to the specific limitations within the enumerated claims, the teaching of the cited art as a whole is not limited to the cited passages. Other passages and figures may apply. Applicant, in preparing the response, should consider fully the entire reference as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art and/or disclosed by Examiner.
Examiner respectfully requests that, in response to this Office Action, support be shown for language added to any original claims on amendment and any new claims. That is, indicate support for newly added claim language by specifically pointing to page(s) and line number(s) in the specification and/or drawing figure(s). This will assist Examiner in prosecuting the application.
When responding to this Office Action, Applicant is advised to clearly point out the patentable novelty which he or she thinks the claims present, in view of the state of the art disclosed by the references cited or the objections made. He or she must also show how the amendments avoid such references or objections. See 37 C.F.R. 1.111(c).
Examiner interviews are available via telephone and video conferencing using a USPTO-supplied web-based collaboration tool. Applicant is encouraged to submit an Automated Interview Request (AIR) which may be done via https://www.uspto.gov/patent/uspto-automated-interview-request-air-form, or may contact Examiner directly via the methods below.
Any inquiry concerning this communication or earlier communication from Examiner should be directed to Andrew M. Lyons, whose telephone number is (571) 270-3529, and whose fax number is (571) 270-4529. The examiner can normally be reached Monday to Friday from 10:00 AM to 6:00 PM ET. If attempts to reach Examiner by telephone are unsuccessful, Examiner’s supervisor, Wei Mui, can be reached at (571) 272-3708. Information regarding the status of an application may be obtained from the Patent Center system. For more information about the Patent Center system, see https://www.uspto.gov/patents/apply/patent-center. If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call (800) 786-9199 (in USA or Canada) or (571) 272-1000.
/Andrew M. Lyons/Examiner, Art Unit 2191
1 See, e.g., “Suffix tree,” Wikipedia, last retrieved from https://en.wikipedia.org/wiki/Suffix_tree on 21 December 2022.
2 See, e.g., “Suffix tree,” Wikipedia, last retrieved from https://en.wikipedia.org/wiki/Suffix_tree on 21 December 2022.
3 See, e.g., “Suffix tree,” Wikipedia, last retrieved from https://en.wikipedia.org/wiki/Suffix_tree on 21 December 2022.