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 .
DETAILED ACTION
1. This initial office action is based on the application filed on 11/11/2024, which claims 1-20 have been presented for examination.
Status of Claim
2. Claims 1-20 are pending in the application and have been examined below, of which, claims 1, 9 and 16 are presented in independent form.
Priority
3. The present application is a CON of 17/541,670 filed on 12/03/2021 PAT 12141557 which is CON of 16/887,271 filed on 05/29/2020 PAT 11221832 which is CON of 15/699,510 filed on 09/08/2017 PAT 10705809.
Information Disclosure Statement
4. The information disclosure statement (IDS) submitted on 03/10/2025. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Examiner Notes
5. Examiner cites particular columns and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
Double Patenting
6. The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
7. Claims 9-20 rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-14 of U.S. Patent No. 12,141,557. Although the claims at issue are not identical, they are not patentably distinct from each other because claims 1-14 of U.S. Patent No. 12,141,557 recites the elements of claims 9-20 of the instant application 18/943,525.
Instant Application
18/943,525
U.S Patent No. 12,141,557
9. A computer program product comprising at least one recordable medium having stored thereon executable instructions and data which, when executed by at least one processing device, cause the at least one processing device to:
8. A non-transitory, computer program product that comprises code stored therein: wherein the code enhances operable functionality of a software program by recommending library substitutions for input source code files, and the code is executable by one or more processors of a device to perform operations comprising:
receive a plurality of input source code files from the software program submitted by a developer;
receiving a plurality of input source code files included in the software program submitted by a developer;
preprocess each input source code file with a plurality of codeword processing
operations selected from a group consisting of a stopword removal operation, a splitting operation, a stemming operation, a conversion operation, a semantic information addition operation, or a wordnet integration operation, thereby generating a plurality of preprocessed input source code files;
preprocessing each input source code file with a plurality of codeword processing operations to generate a plurality of preprocessed input source code files;
14. The computer program product of claim 8, wherein preprocessing each input source code file with the plurality of codeword processing operations comprises: preprocessing each input source code file with the plurality of codeword processing operations selected from a group consisting of a stopword removal operation, a splitting operation, a stemming operation, a conversion operation, a semantic information addition operation, or a wordnet integration operation, thereby generating to generate a plurality of preprocessed input source code files.
identify one or more candidate code snippets from the plurality of preprocessed input source code files by pruning one or more preprocessed input source code files that do not meet a similarity threshold measure for library functions stored in the system library;
10. The computer program product of claim 9, wherein the computer readable program, when executed on the system, causes the at least one processing device to identify one or more candidate code snippets by: performing natural language processing analysis of the plurality of preprocessed input source code files to extract input source code feature vectors; and comparing the input source code feature vectors to library function feature vectors for library functions stored in the system library to identify at least a first candidate code snippet which meets at least a first similarity threshold measure for a first library function stored in the system library.
identify one or more candidate code snippets from the plurality of preprocessed input source code files, wherein the identifying the one or more code candidate snippets comprises: generating a feature vector of each of the one or more preprocessed input source code files;
determining a candidate value for each of the one or more preprocessed input source code files by comparing the feature vector of each of the one or more preprocessed input source code files to a feature vector of each of multiple library functions stored in the system library; for each candidate value of the one or more preprocessed input source code files, determining when the candidate value exceeds the similarity threshold measure for the library functions; and for each of the one or more preprocessed input source code files, pruning each preprocessed input source code files that does not meet a similarity threshold measure for the library functions stored in the system library;
identifying, by the device, at least a first validated code snippet from the one or more candidate code snippets that matches a first library function stored in the system memory on the basis of at least first and second matching metrics;
identifying at least a first validated code snippet from the one or more candidate code snippets that matches at least one of the library functions stored in the system memory on the basis of at least one parameter that indicates a match between the one or more candidate code snippets and the at least one of the library functions,
15. The computer program product of claim 10, wherein the computer readable program, when executed on the system, causes the at least one processing device to identify the first validated code snippet by performing machine learning and natural language processing in combination with code analysis techniques to implement an input/output matching algorithm for selecting a candidate code snippet which generates the same output as the first library function when both are injected with a shared input.
wherein identifying the first validated code snippet comprises performing machine learning and natural language processing in combination with code analysis techniques to implement an input/output matching algorithm for selecting a candidate code snippet which generates the same output as the first library function when both the candidate code snippet and the first library function are injected with a shared input; and
present a library function recommendation comprising the first validated code snippet, the first library function, and instructions for replacing the first validated code snippet with the first library function.
presenting a library function recommendation comprising the first validated code snippet, the first library function, and instructions for replacing the first validated code snippet with the first library function.
11. The computer program product of claim 10, wherein the computer readable program, when executed on the system, causes the at least one processing device to perform natural language processing analysis by employing a weighted combination of Latent Dirichlet Allocation (LDA), Latent Semantic Analysis (LSA), and Rapid Automatic Keyword Extraction (RAKE) on the plurality of preprocessed input source code by giving more weightage to LDA, then LSA, and then RAKE.
12. The computer program product of claim 8, wherein performing natural language processing analysis comprises employing a weighted combination of Latent Dirichlet Allocation (LDA), Latent Semantic Analysis (LSA), and Rapid Automatic Keyword Extraction (RAKE) on the plurality of preprocessed input source code by giving more weightage to LDA, then LSA, and then RAKE.
12. The computer program product of claim 10, wherein the computer readable program, when executed on the system, causes the at least one processing device to compare the input source code feature vectors by computing cosine similarity or dot product values between the input source code feature vectors and library function feature vectors.
13. The computer program product of claim 8, wherein comparing the input source code feature vectors comprises computing cosine similarity or dot product values between the input source code feature vectors and library function feature vectors.
13. The computer program product of
claim 10, wherein the computer
readable program, when executed on
the system, causes the at least one
processing device to compare the
input source code feature vectors by
computing dot product values
between the input source code feature
vectors and library function feature
vectors having a weightage set as 1.
11. The computer program product of claim 10, wherein comparing the input source code feature vectors comprises computing dot product values between the input source code feature vectors and library function feature vectors having a weight set as 1.
14. The computer program product of claim 9, wherein the computer readable program, when executed on the system, causes the at least one processing device to identify the first validated code snippet by performing machine learning and natural language processing in combination with code analysis techniques to implement a fuzzy matching algorithm for selecting a candidate code snippet having first internal extracted features that match second internal extracted features from the first library function.
9. The computer program product of claim 8, wherein
identifying the first validated code snippet comprises to perform machine learning and natural language processing in combination with code analysis techniques to implement a fuzzy matching algorithm for selecting a candidate code snippet having first internal extracted features that match second internal extracted features from the first library function.
Claims 16-20 recite the same limitations as claims 9-15.
Claims 1-7 recite the same limitations as claims 8-14.
8. Claims 1-8 rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-7 of U.S. Patent No. 11,221,832. Although the claims at issue are not identical, they are not patentably distinct from each other because claims 1-7 of U.S. Patent No. 11,221,832 recites the elements of claims 1-8 of the instant application 18/943,525.
Instant Application
18/943,525
U.S Patent No.
11,221,832
1. A method performed by a device having an operating system and a system library for enhancing operable functionality of a software program, comprising:
1. A method performed by a device having an operating system and a system library for enhancing operable functionality of a software program, comprising:
receiving, by the device, a plurality of input source code files from the software program submitted by a developer;
receiving, by the device, a plurality of input source code files from the software program;
preprocessing each input source code file with a plurality of codeword processing operations selected from a group consisting of a stopword removal operation, a splitting operation, a stemming operation, a conversion operation, a semantic information addition operation, or a wordnet integration operation, thereby generating a plurality of preprocessed input source code files;
preprocessing each input source code file with a plurality of codeword processing operations selected from a group consisting of a stopword removal operation, a splitting operation, a stemming operation, a conversion operation, a semantic information addition operation, or a wordnet integration operation, thereby generating a plurality of preprocessed input source code files;
identifying, by the device, one or more candidate code snippets from the plurality of preprocessed input source code files by pruning one or more preprocessed input source code files that do not meet a similarity threshold measure for library functions stored in the system library;
identifying, by the device, one or more candidate code snippets from the plurality of preprocessed input source code files by pruning one or more preprocessed input source code files, wherein pruning one or more preprocessed input source code files comprises: generating a feature vector of each of the one or more preprocessed input source code files; determining a candidate value for each of the one or more preprocessed input source code files by comparing the feature vector of each of the one or more preprocessed input source code files to a feature vector of each of multiple library functions stored in the-system library; and for each candidate value of the one or more preprocessed input source code files, determining if the candidate value exceeds a similarity threshold measure for the library functions; and for each of the one or more preprocessed input source code files, pruning each preprocessed input source code files that does not meet the similarity threshold measure for the library functions stored in the system library;
identifying, by the device, at least a first validated code snippet from the one or more candidate code snippets that matches a first library function stored in the system memory on the basis of at least first and second matching metrics;
8.The method of claim 1, where identifying the first validated code snippet comprises performing machine learning and natural language processing in combination with code analysis techniques to implement an input/output matching algorithm for selecting a candidate code snippet which generates the same output as the first library function when both are injected with a shared input.
identifying, by the device, at least a first validated code snippet from the one or more candidate code snippets that matches a first library function stored in the system library on a basis of at least first and second matching metrics,
where identifying the first validated code snippet comprises performing machine learning and natural language processing in combination with code analysis techniques to implement an input/output matching algorithm for selecting a candidate code snippet which generates the same output as the first library function when both are injected with a shared input;
presenting, to the developer, a library function recommendation comprising the first validated code snippet, the first library function, and instructions for replacing the first validated code snippet with the first library function.
presenting a library function recommendation comprising the first validated code snippet, the first library function, and instructions for replacing the first validated code snippet with the first library function.
2. The method of claim 1, where identifying one or more candidate code snippets comprises: performing natural language processing analysis of the plurality of preprocessed input source code files to extract input source code feature vectors; and comparing the input source code feature vectors to library function feature vectors for library functions stored in the system library to identify at least a first candidate code snippet which meets at least a first similarity threshold measure for a first library function stored in the system library.
2. The method of claim 1, where identifying one or more candidate code snippets comprises: performing natural language processing analysis of the plurality of preprocessed input source code files to extract input source code feature vectors; and comparing the input source code feature vectors to library function feature vectors for the library functions stored in the system library to identify at least a first candidate code snippet which meets at least a first similarity threshold measure for the first library function stored in the system library.
3. The method of claim 2, where performing natural language processing analysis comprises employing one or more vector formation techniques selected from the group consisting of Latent Semantic Indexing, Latent Semantic Analysis, Latent Dirichlet Allocation, Rapid Automatic Keyword Extraction, and Term Frequency–Inverse Document Frequency.
3. The method of claim 2, where performing natural language processing analysis comprises employing one or more vector formation techniques selected from a group consisting of Latent Semantic Indexing, Latent Semantic Analysis, Latent Dirichlet Allocation, Rapid Automatic Keyword Extraction, and Term Frequency-Inverse Document Frequency.
4. The method of claim 2, where performing natural language processing analysis comprises employing a weighted combination of Latent Dirichlet Allocation (LDA), Latent Semantic Analysis (LSA), and Rapid Automatic Keyword Extraction (RAKE) on the plurality of preprocessed input source code by giving more weightage to LDA, then LSA, and then RAKE.
4. The method of claim 2, where performing natural language processing analysis comprises employing a weighted combination of Latent Dirichlet Allocation (LDA), Latent Semantic Analysis (LSA), and Rapid Automatic Keyword Extraction (RAKE) on the plurality of preprocessed input source code files by giving more weightage to LDA, then LSA, and then RAKE.
5. The method of claim 2, where
comparing the input source code
featurevectors comprises computing
cosine similarity or dot product values
between the input source code feature
vectors and library function feature
vectors.
5. The method of claim 2, where comparing the input source code feature vectors comprises computing cosine similarity or dot product values between the input source code feature vectors and library function feature vectors.
6. The method of claim 2, where comparing the input source code feature vectors comprises computing dot product values between the input source code feature vectors and library function feature vectors having a weightage set as 1.
6. The method of claim 2, where comparing the input source code feature vectors comprises computing dot product values between the input source code feature vectors and library function feature vectors having a weightage set as 1.
7. The method of claim 1, where identifying the first validated code snippet comprises performing machine learning and natural language processing in combination with code analysis techniques to implement a fuzzy matching algorithm for selecting a candidate code snippet having first internal extracted features that match second internal extracted features from the first library function.
7. The method of claim 1, where identifying the first validated code snippet comprises performing the machine learning and natural language processing in combination with code analysis techniques to implement a fuzzy matching algorithm for selecting a candidate code snippet having first internal extracted features that match second internal extracted features from the first library function.
9. Claims 1-20 rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of U.S. Patent No. 10,705,809 B2. Although the claims at issue are not identical, they are not patentably distinct from each other because claims 1-20 of U.S. Patent No. 10,705,809 B2 recites the elements of claims 1-20 of the instant application 18/943,525.
Instant Application
18/943,525
U.S Patent No. 1
10,705,809 B2
1. A method performed by a device having an operating system and a system library for enhancing operable functionality of a software program, comprising:
1. A method performed by a device having an operating system and a system library for enhancing operable functionality of a software program, comprising:
receiving, by the device, a plurality of input source code files from the software program submitted by a developer;
receiving, by the device, a plurality of input source code files from the software program submitted by a developer;
preprocessing each input source code file with a plurality of codeword processing operations selected from a group consisting of a stopword removal operation, a splitting operation, a stemming operation, a conversion operation, a semantic information addition operation, or a wordnet integration operation, thereby generating a plurality of preprocessed input source code files;
preprocessing each input source code file with a plurality of codeword processing operations selected from a group consisting of a stopword removal operation, a splitting operation, a stemming operation, a conversion operation, a semantic information addition operation, or a wordnet integration operation, thereby generating a plurality of preprocessed input source code files;
identifying, by the device, one or more candidate code snippets from the plurality of preprocessed input source code files by pruning one or more preprocessed input source code files that do not meet a similarity threshold measure for library functions stored in the system library;
identifying, by the device, one or more candidate code snippets from the plurality of preprocessed input source code files by pruning one or more preprocessed input source code files, wherein pruning one or more preprocessed input source code files comprises: generating a feature vector of each of the one or more preprocessed input source code files;
determining a candidate value for each of the one or more preprocessed input source code files by comparing the feature vector of each of the one or more preprocessed input source code files to a feature vector of each of multiple library functions stored in the system library;
for each candidate value of the one or more preprocessed input source code files, determining if the candidate value exceeds a similarity threshold measure for the library functions; and for each of the one or more preprocessed input source code files, pruning each preprocessed input source code files that does not meet a similarity threshold measure for library functions stored in the system library;
identifying, by the device, at least a first validated code snippet from the one or more candidate code snippets that matches a first library function stored in the system memory on the basis of at least first and second matching metrics;
8.The method of claim 1, where identifying the first validated code snippet comprises performing machine learning and natural language processing in combination with code analysis techniques to implement an input/output matching algorithm for selecting a candidate code snippet which generates the same output as the first library function when both are injected with a shared input.
identifying, by the device, at least a first validated code snippet from the one or more candidate code snippets that matches a first library function stored in the system memory on the basis of at least first and second matching metrics,
wherein identifying the first validated code snippet comprises performing machine learning and natural language processing in combination with code analysis techniques to implement an input/output matching algorithm for selecting a candidate code snippet which generates the same output as the first library function when both are injected with a shared input;
presenting, to the developer, a library function recommendation comprising the first validated code snippet, the first library function, and instructions for replacing the first validated code snippet with the first library function.
presenting, to the developer, a library function recommendation comprising the first validated code snippet, the first library function, and instructions for replacing the first validated code snippet with the first library function.
2. The method of claim 1, where identifying one or more candidate code snippets comprises: performing natural language processing analysis of the plurality of preprocessed input source code files to extract input source code feature vectors; and comparing the input source code feature vectors to library function feature vectors for library functions stored in the system library to identify at least a first candidate code snippet which meets at least a first similarity threshold measure for a first library function stored in the system library.
2. The method of claim 1, where identifying one or more candidate code snippets comprises: performing natural language processing analysis of the plurality of preprocessed input source code files to extract input source code feature vectors; and comparing the input source code feature vectors to library function feature vectors for library functions stored in the system library to identify at least a first candidate code snippet which meets at least a first similarity threshold measure for a first library function stored in the system library.
3. The method of claim 2, where performing natural language processing analysis comprises employing one or more vector formation techniques selected from the group consisting of Latent Semantic Indexing, Latent Semantic Analysis, Latent Dirichlet Allocation, Rapid Automatic Keyword Extraction, and Term Frequency–Inverse Document Frequency.
3. The method of claim 2, where performing natural language processing analysis comprises employing one or more vector formation techniques selected from a group consisting of Latent Semantic Indexing, Latent Semantic Analysis, Latent Dirichlet Allocation, Rapid Automatic Keyword Extraction, and Term Frequency-Inverse Document Frequency.
4. The method of claim 2, where performing natural language processing analysis comprises employing a weighted combination of Latent Dirichlet Allocation (LDA), Latent Semantic Analysis (LSA), and Rapid Automatic Keyword Extraction (RAKE) on the plurality of preprocessed input source code by giving more weightage to LDA, then LSA, and then RAKE.
4. The method of claim 2, where performing natural language processing analysis comprises employing a weighted combination of Latent Dirichlet Allocation (LDA), Latent Semantic Analysis (LSA), and Rapid Automatic Keyword Extraction (RAKE) on the plurality of preprocessed input source code by giving more weightage to LDA, then LSA, and then RAKE.
5. The method of claim 2, where
comparing the input source code
feature vectors comprises computing
cosine similarity or dot product values
between the input source code feature
vectors and library function feature
vectors.
5. The method of claim 2, where comparing the input source code feature vectors comprises computing cosine similarity or dot product values between the input source code feature vectors and library function feature vectors.
6. The method of claim 2, where comparing the input source code feature vectors comprises computing dot product values between the input source code feature vectors and library function feature vectors having a weightage set as 1.
6. The method of claim 2, where comparing the input source code feature vectors comprises computing dot product values between the input source code feature vectors and library function feature vectors having a weightage set as 1.
7. The method of claim 1, where identifying the first validated code snippet comprises performing machine learning and natural language processing in combination with code analysis techniques to implement a fuzzy matching algorithm for selecting a candidate code snippet having first internal extracted features that match second internal extracted features from the first library function.
7. The method of claim 1, where identifying the first validated code snippet comprises performing machine learning and natural language processing in combination with code analysis techniques to implement a fuzzy matching algorithm for selecting a candidate code snippet having first internal extracted features that match second internal extracted features from the first library function.
Claims 9-15 recite the same limitations as claims 1-8.
Claims 8-13 recite the same limitations as claims 1-7.
Claims 16-20 recite the same limitations as claims 1-8.
Claims 14-20 recite the same limitations as claims 1-8.
Abstract Objection
10. Line 1 of Abstract recites “A method and apparatus are discloses.”
Applicant is reminded of the proper language and format for an abstract of the disclosure.
The abstract should be in narrative form and generally limited to a single paragraph on a separate sheet within the range of 50 to 150 words in length. The abstract should describe the disclosure sufficiently to assist readers in deciding whether there is a need for consulting the full patent text for details.
The language should be clear and concise and should not repeat information given in the title. It should avoid using phrases which can be implied, such as, “The disclosure concerns,” “The disclosure defined by this invention,” “The disclosure describes,” etc. In addition, the form and legal phraseology often used in patent claims, such as “means” and “said,” should be avoided.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
11. Claims 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 1, line 15; claim 9, line 15 and claim 16, line 21 recite “the basic of at least first and second matching metrics” renders the claim indefinite since it is not clear whether the first and second matching metrics are measured for library function and is not clearly understood what “the basic” is.
Claims 2-7, 8-15 and 17-20 are also rejected under 112(b) since they are dependent on claims 1, 8 and 16.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
9. Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The analysis specific to Claims 1, 9 and 16 is being presented below.
Claims 1, 9 and 16:
Step 1 Analysis:
Claims 1-8 of the instant application is direct to process/method.
Claims 9-15 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claim(s) does/do not fall within at least one of the four categories of patent eligible subject matter because
Claim 9 recites "at least one recordable medium"; however, " the at least one recordable medium has not been defined in specification. The spec. [0080] merely provides a description and/or example that "The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device..." (emphasis added). This is not limiting the claimed "at least one recordable medium". Absent such express limitation on the claimed "at least one recordable medium", it has been decided that "the ordinary and customary meaning of 'at least one recordable medium' to a person of ordinary skill in the art was broad enough to encompass both non-transitory and transitory media" - See Ex parte Mewherte, 107 USPQ2d 1875 (PTAB 2013) ("Precedential").
Claims 10-15 are also rejected because they do not provide any remedy for the deficiency suffered by claim 9.
Claims 16-20 of the instant application is direct to apparatus/system.
Step 2 Analysis:
Claims 1, 9 and 16 recites:
(a) receiving, by the device, a plurality of input source code files from the software program submitted by a developer;
(b) preprocessing each input source code file with a plurality of codeword processing operations selected from a group consisting of a stopword removal operation, a splitting operation, a stemming operation, a conversion operation, a semantic information addition operation, or a wordnet integration operation, thereby generating a plurality of preprocessed input source code files;
(c) identifying, by the device, one or more candidate code snippets from the plurality of preprocessed input source code files by pruning one or more preprocessed input source code files that do not meet a similarity threshold measure for library functions stored in the system library;
(d) identifying, by the device, at least a first validated code snippet from the one or more candidate code snippets that matches a first library function stored in the system memory on the basis of at least first and second matching metrics; and
(e) presenting, to the developer, a library function recommendation comprising the first validated code snippet, the first library function, and instructions for replacing the first validated code snippet with the first library function.
Step 2A -- Prong 1:
The claims 1, 9 and 16 recite the limitations of:
(a) receiving, by the device, a plurality of input source code files from the software program submitted by a developer;
(b) preprocessing each input source code file with a plurality of codeword processing operations selected from a group consisting of a stopword removal operation, a splitting operation, a stemming operation, a conversion operation, a semantic information addition operation, or a wordnet integration operation, thereby generating a plurality of preprocessed input source code files;
(c) identifying, by the device, one or more candidate code snippets from the plurality of preprocessed input source code files by pruning one or more preprocessed input source code files that do not meet a similarity threshold measure for library functions stored in the system library;
(d) identifying, by the device, at least a first validated code snippet from the one or more candidate code snippets that matches a first library function stored in the system memory on the basis of at least first and second matching metrics; and
Limitations (b)-(d) are limitations that, as drafted, are processes that, under its broadest reasonable interpretations, cover performance of the limitation in the mind. That is, nothing in the claim elements precludes the step from practically being performed in the mind or with a pen and paper, i.e. “preprocessing”/analyzing and “identifying” can be performed in the human mind through observation, evaluation, judgement, opinion with the aid of pen and paper. Limitation (a) is limitation that, as drafted, are processes that, under its broadest reasonable interpretations, cover performance of the limitation in the mind. That is, nothing in the claim elements precludes the step from practically being performed in the mind or with a pen and paper, i.e. “receiving”/collecting can be performed in the human mind with the aid of pen and paper. As such, these limitations fall within the “Mental Processes” grouping of abstract ideas.
Step 2A -- Prong 2:
The claim 1 recites the additional limitation of “a device”. The limitations of “a device” is recited at a high level of generality, i.e., merely instructions to implement the abstract idea on a generic computer or merely uses a computer as a tool to perform the abstract idea. Claim 9 recites the additional limitations of “at least one recordable medium” and “at least one processing device”. The limitation of “at least one recordable medium” and “at least one processing device” are recited at a high level of generality, i.e., merely instructions to implement the abstract idea on a generic computer or merely uses a computer as a tool to perform the abstract idea. Claim 16 recites the additional limitations “a system”; “one or more processors” and “a memory”. The limitations of “a system”, “one or more processors” and “a memory” are recited at a high level of generality, i.e., merely instructions to implement the abstract idea on a generic computer or merely uses a computer as a tool to perform the abstract idea. Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Step 2B:
As explained with respect to Step 2A Prong Two, the additional elements in the claim are recited at a high level of generality and amount to no more than mere instructions to apply the exception using generic computer components. Accordingly, the additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The same analysis applies here in 2B, i.e., simply adding extra-solution activity or well-understood, routine and conventional activity or generic computer components does not integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B since the courts have identified functions such as gathering, displaying/presenting, updating, transmitting/receiving and storing/uploading data as well- understood, routine, conventional activity. See MPEP 2106.05(d) and See MPEP 2106.05(g). Therefore, claims are ineligible.
Dependent claims
Additionally, claims 2 and 10 recite “where identifying one or more candidate code snippets comprises: performing natural language processing analysis of the plurality of preprocessed input source code files to extract input source code feature vectors; and comparing the input source code feature vectors to library function feature vectors for library functions stored in the system library to identify at least a first candidate code snippet which meets at least a first similarity threshold measure for a first library function stored in the system library” is merely insignificant extra solution activity of processing and comparing data. Accordingly, these limitations do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea or providing an inventive concept and thus do not amount to significantly more than the abstract idea. As such, these claims fail both Step 2A prong 2 and Step 2B. Therefore, claims 2 and 10 are ineligible.
Additionally, claim 3 recites “where performing natural language processing analysis comprises employing one or more vector formation techniques selected from the group consisting of Latent Semantic Indexing, Latent Semantic Analysis, Latent Dirichlet Allocation, Rapid Automatic Keyword Extraction, and Term Frequency–Inverse Document Frequency” is merely insignificant extra solution activity of processing data. Accordingly, these limitations do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea or provide an inventive concept and thus do not amount to significantly more that the abstract idea. As such, these claims fail both Step 2A prong 2 and Step 2B. Therefore, claim 3 is ineligible.
Additionally, claims 4 and 11 recite “where performing natural language processing analysis comprises employing a weighted combination of Latent Dirichlet Allocation (LDA), Latent Semantic Analysis (LSA), and Rapid Automatic Keyword Extraction (RAKE) on the plurality of preprocessed input source code by giving more weightage to LDA, then LSA, and then RAKE” is merely insignificant extra solution activity of processing data. Accordingly, these limitations do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea or providing an inventive concept and thus do not amount to significantly more than the abstract idea. As such, these claims fail both Step 2A prong 2 and Step 2B. Therefore, claims 4 and 11 are ineligible.
Additionally, claims 5 and 12 recite “where comparing the input source code feature vectors comprises computing cosine similarity or dot product values between the input source code feature vectors and library function feature vectors” as drafted, is a process that, under its broadest reasonable interpretations, covers performance of the limitation in mathematical calculations. As such, this limitation falls within the “Mathematical Concepts” grouping of abstract idea. Accordingly, these limitations do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea or providing an inventive concept and thus do not amount to significantly more than the abstract idea. As such, these claims fail both Step 2A prong 2 and Step 2B. Therefore, claims 5 and 12 are ineligible.
Additionally, claims 6, 13 and 18 recite “where comparing the input source code feature vectors comprises computing dot product values between the input source code feature vectors and library function feature vectors having a weightage set as 1” as drafted, is a process that, under its broadest reasonable interpretations, covers performance of the limitation in mathematical calculations. As such, this limitation falls within the “Mathematical Concepts” grouping of abstract idea. Accordingly, these limitations do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea or providing an inventive concept and thus do not amount to significantly more than the abstract idea. As such, these claims fail both Step 2A prong 2 and Step 2B. Therefore, claims 6, 13 and 18 are ineligible.
Additionally, claims 7, 14 and 19 recite “where identifying the first validated code snippet comprises performing machine learning and natural language processing in combination with code analysis techniques to implement a fuzzy matching algorithm for selecting a candidate code snippet having first internal extracted features that match second internal extracted features from the first library function” is merely insignificant extra solution activity of processing data. Accordingly, these limitations do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea or providing an inventive concept and thus do not amount to significantly more than the abstract idea. As such, these claims fail both Step 2A prong 2 and Step 2B. Therefore, claims 7, 14 and 19 are ineligible.
Additionally, claims 8, 15 and 20 recite “where identifying the first validated code snippet comprises performing machine learning and natural language processing in combination with code analysis techniques to implement an input/output matching algorithm for selecting a candidate code snippet which generates the same output as the first library function when both are injected with a shared input” is merely insignificant extra solution activity of processing data. Accordingly, these limitations do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea or providing an inventive concept and thus do not amount to significantly more than the abstract idea. As such, these claims fail both Step 2A prong 2 and Step 2B. Therefore, claims 8, 15 and 20 are ineligible.
Additionally, claim 17 recites “where identifying one or more candidate code snippets comprises: performing natural language processing analysis of the plurality of preprocessed input source code files to extract input source code feature vectors by employing one or more vector formation techniques selected from the group consisting of Latent Semantic Indexing, Latent Semantic Analysis, Latent Dirichlet Allocation, Rapid Automatic Keyword Extraction, and Term Frequency–Inverse Document Frequency; and comparing the input source code feature vectors to library function feature vectors for library functions stored in the system library by computing cosine similarity or dot product values between the input source code feature vectors and library function feature vectors to identify at least a first candidate code snippet which meets at least a first similarity threshold measure for a first library function stored in the system library” is merely insignificant extra solution activity of processing and comparing data. Accordingly, these limitations do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea or providing an inventive concept and thus do not amount to significantly more than the abstract idea. As such, these claims fail both Step 2A prong 2 and Step 2B. Therefore, claim 17 is ineligible.
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.
12.. Claim(s) 1-2, 6-7, 9-10, 13-14, 16 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Vineeth Kashyap (Source Forager: A Search Engine for Similar Source Code, 2017 – herein after Kashyap) in view of Dang (US Pub. No. 2015/0378692 A1 – herein after Dang) and in view of Sisman et al. (US Patent No. 10,108,526 B2 – herein after Sisman).
Regarding claim 1.
Kashyap discloses
A method performed by a device having an operating system (similar- machine code search is focused on operating systems - See page 1) and a system library (the different feature-classes employed in source forager, modeled Library Calls, User-Defined Library Calls - See page 4, left column) for enhancing operable functionality of a software program (Feature-Class and Similarity Functions - See page 4, left column), comprising:
receiving, by the device, a plurality of input source code [[files]] from the software program submitted by a developer (Developers routinely use code search as a learning and debugging tool for tasks such as looking for existing functionality in a code base, determining how to use an API or library, gathering information about what code is intended to do - See Introduction page 1);
preprocessing each input source code file with a plurality of codeword processing operations (Source Forager preprocesses the database to extract a variety of simple code features that capture different aspects of code. A search returns the k functions in the database that are most similar to the query, based on the various extracted code features - See page 1, Abstract. Such NL terms, after extraction, are subjected to a series of standard NL preprocessing steps- See page 5) selected from a group consisting of a stopword removal operation, a splitting operation, a stemming operation, a conversion operation, a semantic information addition operation, or a wordnet integration operation (Such NL terms, after extraction, are subjected to a series of standard NL preprocessing steps, such as splitting words with underscores or CamelCase, stemming, lemmatization, and removing single character strings and stop-words. Stop-word removal discards both typical English stop words, we extract a multiset of k-graph shapes. Fig. 5 shows an example of converting a 4-graph into a 16-bit - See page 5. Recent search techniques allow users to specify certain aspects of code semantics in addition to the textual query - See page 1), thereby generating a plurality of preprocessed input source code [[files]] (there are many text mining tools that can be used for building a text mining dictionary (e.g., lexical analyzer, stop-words filtering, hash-indexing system, etc.). Many studies have investigated the effect of these tools in the text pre-processing systems (Introduction, page 1). The comments are represented as a set of words - See page 6);
identifying, by the device, one or more candidate code snippets from the plurality of preprocessed input source code files (Our code-search mechanism takes code fragments as queries. Various kinds of semantic information can be extracted from the query and used by the search. This approach provides a unified mechanism for code search: searching code using code fragments – See page 1, right column. We compare the query's feature- observation for C with all other feature-observations for C in sample S - See page 6, right column. XSnippet and ParseWeb are specialized code-search engines: XSnippet looks specifically for code that instantiates objects of given type in a given context, ParseWeb has a similar focus on code sequences that instantiate objects - See page 10. Examiner respectfully notes that snippet code as reuse code/template code/clone code/sample code) by pruning one or more preprocessed input source code [[files]] (after NL pre-processing, we compute a term frequency inverse document frequency (TF-IDF) score for each NL term. We consider each function as a document, and compute the TF-IDF per C/C++ project - See page 5, left column. For example, tuniq = 0.15 indicates that any feature-observation that is similar to less than 15% of the sample feature-observations is considered distinctive enough to warrant inclusion - See page 5, left column) that do not meet a similarity threshold measure for library functions stored in the system library (we calculate a similarity threshold for each feature-class C by (1) computing pairwise similarity scores on the feature-observations for C in S. We select the feature-class C for code search if it is not too common, that is, if nsim-c nsamp < tuniq. Here tuniq is a threshold that indicates a feature-observation is sufficiently unique in the sample. For example, tuniq = 0.15 indicates that any feature- observation that is similar to less than 15% of the sample feature-observations is considered distinctive enough to warrant inclusion- See page 6, right column. Prunning/removing/distinct input that has low similarity threshold value – See page 18, left column);
identifying, by the device, at least a first validated code snippet from the one or more candidate code snippets that matches a first library function stored in the system memory on the basis of at least first and second matching metrics (A higher value indicates greater similarity between two feature-observations. For example, the similarity function for Numeric Literals is the Jaccard index - See page 2, right column; the Skeleton Tree feature-class would be useful in code search: other instances of the same distinctive structure from the code database would have high similarity scores to the query function. The k most-similar-function search is carried out between the query function and the functions in the code database as described, to obtain the k functions most similar to the query- See page 6, right column); and
Kashyap does not disclose
presenting, to the developer, a library function recommendation comprising the first validated code snippet, the first library function, and instructions for replacing the first validated code snippet with the first library function.
Dang discloses
presenting, to the developer, a library function recommendation comprising the first validated code snippet, the first library function, and instructions for replacing the first validated code snippet with the first library function (Fig. 2, code editor and recommendation area. Fig. 6, paragraphs [0061- 0065], Given an extracted code snippet, the codes contained in the snippet is first normalized and tokenized. That is, all variable names and literals are replaced with the same token. For example, with reference to FIG. 7, in fragments 710 and 720, the variables and literals "@StsCode," "SqIDbType.Int," "0," "resultCode," "@ErrMsg," "SqlDbType.VarChar," "1," and "errorText" may all be replaced with a same token, for example, "X". Then the code snippet may be checked for any duplicate sub- string. Any sub-string detection algorithm, no matter currently known or developed in the future, may be applied herein. In one embodiment, for the cloned code fragments detected in a code snippet, one of them is maintained and the others are removed).
It would have been obvious to one ordinary skill in the art before the effective filing date of claimed invention to use Dang's teaching into Kashyap's invention because incorporating Dang's teaching would enhance Kashyap to enable to improve quality, usability and user friendliness of the code recommendations and highlight one or more variation points in a recommended code snippet based on the associated metadata as suggested by paragraph [0006]).
Kashyap and Dang do not disclose
source code files
Sisman discloses
receiving, by the device, a plurality of input source code files from the software program submitted by a developer (Fig. 14, source code files 900);
preprocessing each input source code file with a plurality of codeword processing operations (a respective historical ranking (e.g., P(f|C)) is determined for each file using respective changeset information (e.g., I.sub.m, I.sub.b) of that file - See col. 6, lines 65-67 and col. 7, lines 1-12) selected from a group consisting of a stopword removal operation (treating each source-code file as a bag of words, an initial stopword list is first to remove the programming-language-specific tokens – See col. 15, lines 18-20), a splitting operation (Preprocessing can be done by processor 286, e.g., as discussed above. In various aspects, for the indexing of a particular version of the target code base, the compound terms are split using punctuation characters (e.g., the_magical.fwdarw.“the,” “magical”) – See col. 29, lines 60-65), a stemming operation (The remaining terms are then stemmed into their common roots using the Porter stemming algorithm – See col. 30, lines 1-2), a conversion operation, a semantic information addition operation, or a wordnet integration operation
Sisman also discloses
identifying, by the device, one or more candidate code snippets from the plurality of preprocessed input source code files by pruning one or more preprocessed input source code files (the change-sets for what are usually referred to as General Maintenance (GM) tasks tend to be very large. As a case in point, a change-set for removing unnecessary import statements from all Java files in a code base does not carry much useful information with regard to any co-modification dependencies between the files – See col. 6, lines 5-12)
It would have been obvious to one ordinary skill in the art before the effective filing date of claimed invention to use Sisman's teaching into Kashyap's and Dang's inventions because incorporating Sisman's teaching would enhance Kashyap and Dang to enable to receiving the source code files and provide analysis of source code files to locate files likely relevant to a given bug as suggested by Sisman (col. 8, lines 15-18).
Regarding claim 2, the method of claim 1,
Kashyap discloses
where identifying one or more candidate code snippets (XSnippet [5] and ParseWeb [25] are specialized code-search engines: XSnippet looks specifically for code that instantiates objects of given type in a given context, ParseWeb has a similar focus on code sequences that instantiate objects - See page 10, right column) comprises:
performing natural language processing analysis of the plurality of preprocessed input source code files to extract input source code feature vectors (Weighted NL Terms processed natural language terms in code - See page 4, table 1. Weighted NL Terms: The feature-observations for this feature-class consist of various natural-language (NL) terms in source code, such as function name, comments, local variable names, and parameter names of a function - See page 5, left column); and
comparing the input source code feature vectors to library function feature vectors for library functions stored in the system library to identify at least a first candidate code snippet which meets at least a first similarity threshold measure for a first library function stored in the system library (The feature-vector of the query is compared with each of the feature-vectors in the code database using this combined similarity function, and the k most-similar functions (that is, with the highest similarity scores to the query) are returned as results (for some configurable limit k). Fig. 3 shows an example Source Forager code-search result when the code in Fig. 2 is used as query - See page 3, left column).
Regarding claim 6, the method of claim 2,
Kashyap discloses
where comparing the input source code feature vectors comprises computing dot product values between the input source code feature vectors and library function feature vectors having a weightage set as 1 (The intuition behind including this feature-class is that similar functions tend to have similar natural-language vocabulary. The feature-observation for the example in Fig. 2 is {"bin": 0.65, "search": 0.65, "high": 0.13, "low": 0.13, "found": 0.13, "mid": 0.13, "match": 0.13} - See page 5, left column).
Regarding claim 7, the method of claim 1,
Kashyap discloses
where identifying the first validated code snippet comprises performing machine learning (A supervised-learning technique to pre-compute the relative importance of different feature-classes - See page 2, left column) and natural language processing in combination with code analysis techniques to implement a fuzzy matching algorithm for selecting a candidate code snippet having first internal extracted features that match second internal extracted features from the first library function (The intuition behind including this feature-class is that similar functions tend to have similar natural-language vocabulary. The feature-observation for the example in Fig. 2 is {"bin": 0.65, "search": 0.65, "high": 0.13, "low": 0.13, "found": 0.13, "mid": 0.13, "match": 0.13}. - See page 5, left column).
Regarding claim 9.
A computer program product comprising at least one recordable medium having stored thereon executable instructions and data which, when executed by at least one processing device, cause the at least one processing device to:
Regarding claim 9, recites the same limitations as rejected claim 1 above.
Regarding claim 10, recites the same limitations as rejected claim 2 above.
Regarding claim 13, recites the same limitations as rejected claim 6 above.
Regarding claim 14, recites the same limitations as rejected claim 7 above.
Regarding claim 16.
A system comprising:
one or more processors;
a memory coupled to at least one of the processors; and
a set of instructions stored in the memory and executed by at least one of the processors to enhance operable functionality of a software program by recommending library substitutions for input source code files submitted by a developer, wherein the set of instructions are executable to perform actions of:
Regarding claim 16, recites the same limitations as rejected claim 1 above.
Regarding claim 19, recites the same limitations as rejected claim 7 above.
13. Claims 3-5, 11-12 and 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Kashyap, Dang and Sisman as applied to claims 2, 10 and 16 respectively above, and further in view of Mehdi Allahyari (A Brief Survey of Text Mining: Classification, Clustering and Extraction Techniques, July 2017 --herein after Allahyari).
Regarding claim 3, the method of claim 2,
Allahyari discloses
where performing natural language processing analysis comprises employing one or more vector formation techniques selected from the group consisting of Latent Semantic Indexing, Latent Semantic Analysis, Latent Dirichlet Allocation (Three of the main dimension reduction techniques used in text mining are Latent Semantic Indexing (LSI) [42], Probabilistic Latent Semantic Indexing (PLSA) [66] and topic models [16]. In many text mining applications, Probabilistic Methods for Text Mining: There are various probabilistic techniques including unsupervised topic models suchas probabilistic Latent semantic analysis (pLSA) [66] and Latent Dirichlet Allocation (LDA) - See page 3), Rapid Automatic Keyword Extraction (Information Extraction from text (IE): Information Extraction is the task of, automatically extracting information or facts from unstructured or semi-structured documents [35, 122]. It usually serves as a starting point for other text mining algorithms. For example extraction entities, Name Entity Recognition (NER), and their relations from text can give us useful semantic information - See page 2), and Term Frequency–Inverse Document Frequency ((1) Boolean model: In this model a weight wi j > 0 is assigned to each term wi E dj For any term that does not appear in dj wi j = 0. 2) Term frequency-inverse document frequency (TF-IDF): The most popular term weighting schemes is TF-IDF - See page 4).
It would have been obvious to one ordinary skill in the art before the effective filing date of claimed invention to use Allahyari's teaching into Kashyap's and Dang's and Sisman's inventions because incorporating Allahyari's teaching would enhance Kashyap and Dang and Sisman to enable to process of discovering useful knowledge from data while data mining refers to a specific step in this process including natural language processing as suggested by Allahyari (page 2).
Regarding claim 4, the method of claim 2,
Allahyari discloses
where performing natural language processing analysis comprises employing a weighted combination of Latent Dirichlet Allocation (LDA), Latent Semantic Analysis (LSA), and Rapid Automatic Keyword Extraction (RAKE) on the plurality of preprocessed input source code by giving more weightage to LDA, then LSA, and then RAKE (The two main topic models are Probabilistic Latent Semantic Analysis (pLSA) [66] and Latent Dirichlet Allocation (LDA) [16] - See page 7. Information Extraction - See page 8).
It would have been obvious to one ordinary skill in the art before the effective filing date of claimed invention to use Allahyari's teaching into Kashyap's and Dang's and Sisman's inventions because incorporating Allahyari's teaching would enhance Kashyap and Dang and Sisman to enable to process of discovering useful knowledge from data while data mining refers to a specific step in this process including natural language processing as suggested by Allahyari (page 2).
Regarding claim 5, the method of claim 2,
Kashyap discloses
where comparing the input source code feature vectors comprises computing cosine similarity or dot product values between the input source code feature vectors and library function feature vectors (The similarity function for two observations of Weighted NL Terms uses cosine similarity - See page 5, left column).
Allahyari also discloses
where comparing the input source code feature vectors comprises computing cosine similarity or dot product values between the input source code feature vectors and library function feature vectors (Based on the term weighting scheme, each document is represented by a vector of term weights w(d) = (w(d,w1),w(d,w2), w(d,wv)). We can compute the similarity between two documents d1 and d2. One of the most widely used similarity measures is cosine similarity - See page 4).
Regarding claim 11, recites the same limitations as rejected claim 4 above.
Regarding claim 12, recites the same limitations as rejected claim 5 above.
Regarding claim 17, the system of claim 16,
Allahyari discloses
where identifying one or more candidate code snippets comprises:
performing natural language processing analysis of the plurality of preprocessed input source code files to extract input source code feature vectors by employing one or more vector formation techniques selected from the group consisting of Latent Semantic Indexing, Latent Semantic Analysis, Latent Dirichlet Allocation (Three of the main dimension reduction techniques used in text mining are Latent Semantic Indexing (LSI) [42], Probabilistic Latent Semantic Indexing (PLSA) [66] and topic models [16]. In many text mining applications, Probabilistic Methods for Text Mining: There are various probabilistic techniques including unsupervised topic models suchas probabilistic Latent semantic analysis (pLSA) [66] and Latent Dirichlet Allocation (LDA) - See page 3), Rapid Automatic Keyword Extraction (Information Extraction from text (IE): Information Extraction is the task of, automatically extracting information or facts from unstructured or semi-structured documents [35, 122]. It usually serves as a starting point for other text mining algorithms. For example extraction entities, Name Entity Recognition (NER), and their relations from text can give us useful semantic information - See page 2), and Term Frequency–Inverse Document Frequency ((1) Boolean model: In this model a weight wi j > 0 is assigned to each term wi E dj For any term that does not appear in dj wi j = 0. 2) Term frequency-inverse document frequency (TF-IDF): The most popular term weighting schemes is TF-IDF - See page 4); and
comparing the input source code feature vectors to library function feature vectors for library functions stored in the system library by computing cosine similarity or dot product values between the input source code feature vectors (The similarity function for two observations of Weighted NL Terms uses cosine similarity - See page 5, left column) and library function feature vectors to identify at least a first candidate code snippet which meets at least a first similarity threshold measure for a first library function stored in the system library (Based on the term weighting scheme, each document is represented by a vector of term weights ω(d) = (ω(d,w1),ω(d,w2), . . . , ω(d,wv )). We can compute the similarity between two documents d1 and d2. One of the most widely used similarity measures is cosine similarity and is computed – See page 4, left column).
It would have been obvious to one ordinary skill in the art before the effective filing date of claimed invention to use Allahyari's teaching into Kashyap's and Dang's and Sisman's inventions because incorporating Allahyari's teaching would enhance Kashyap and Dang and Sisman to enable to process of discovering useful knowledge from data while data mining refers to a specific step in this process including natural language processing as suggested by Allahyari (page 2).
Regarding claim 18, recites the same limitations as rejected claim 6 above
13. Claims 8, 15 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Kashyap, Dang and Sisman as applied to claims 1, 10 and 16 respectively above, and further in view of He Jiang (ROSF: Leveraging Information Retrieval and Supervised Learning for Recommending Code Snippets, July 2016 --herein after Jiang).
Regarding claim 8, the method of claim 1,
Jiang discloses
where identifying the first validated code snippet comprises performing machine learning (propose a code example search approach applying a machine learning technique (i.e., learning to rank) to recommend code examples taking method names and class names as inputs – See page 44, left column) and natural language (keywords and phase – See page 38, left column) processing in combination with code analysis techniques to implement an input/output matching algorithm for selecting a candidate code snippet which generates the same output as the first library function when both are injected with a shared input (method named MUSE by combining static slicing and clone detection technology to provide concise examples for that method. Each example contains the sequence of relevant steps to invoke the method, and the less relevant code is pruned out. Propose a code example search approach applying a machine learning technique (i.e., learning to rank) to recommend code examples taking method names and class names as inputs. Different from these studies, our method takes free-form queries as inputs and outputs the original code snippets to developers -- See page 44, left column).
It would have been obvious to one ordinary skill in the art before the effective filing date of claimed invention to use Jiang's teaching into Kashyap's and Dang’s and Sisman’s inventions because incorporating Jiang's teaching would enhance Kashyap and Dang and Sisman to enable to input and output code snippets for the queries as suggested by Jiang (page 41, left column).
Regarding claim 15, recites the same limitations as rejected claim 8 above.
Regarding claim 20, recites the same limitations as rejected claim 8 above.
Conclusion
15. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Cohen (US Pub. No. 2016/0127398 A1) discloses identifying similarity between query samples and stored samples in an efficiently maintained reference library may include receiving a first threshold and a second threshold, receiving a plurality of binary reference samples, and processing each reference sample of the plurality of reference samples. The processing may include operations of assigning each reference sample a respective unique identifier, producing a reference sample fingerprint for each reference sample, and registering each respective unique identifier to reference sample fingerprint pair in a reference library – See Abstract and specification for more details.
Mount (US Pub. No. 2019/0004774 A1) discloses store source code referencing a first application programming interface for a first version of a programming platform. The processor may be configured to automatically adapt the source code to reference a second application programming interface for a second version of the programming platform such that the source code maintains functionality of the first application programming interface for the first version of the programming platform, and output, based on the automatically adapted source code, an executable file – See Abstract and specification for more details.
Au et al. (US Pub. No. 2018/0024816 A1) discloses recommending content of a code snippet to define an object literal. For instance, information regarding one or more properties of the object literal is determined. The content of the code snippet is recommended to define the object literal based at least in part on the information. The content identifies the one or more properties of the object literal – See Abstract and specification for more details.
Durga et al. (US Pub. No. 2018/0267886 A1) discloses predicting a defect within a computer program comprising: accessing a code base of the computer program, the code base of the computer program comprising a plurality of computer program files; training the defect prediction system, the training including performing a historical analysis of defect occurrence patterns in the code base of the computer program; analyzing a commit of the computer program to identify a likelihood of defect occurrence within each of the plurality of files of the computer program; and, calculating a defect prediction metric for each of the plurality of files of the computer program, the defect prediction metric providing an objective measure of defect prediction for each of the plurality of files of the computer program – See Abstract and specification for more details.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MONGBAO NGUYEN whose telephone number is (571)270-7180. The examiner can normally be reached Monday-Friday 8am-5pm.
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, Hyung S. Sough can be reached at 571-272-6799. 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.
/MONGBAO NGUYEN/ Examiner, Art Unit 2192
Prosecution Insights