DETAILED ACTION
This is the initial Office action based on the preliminary amendment submitted on July 31, 2024.
Claims 1-10 are pending.
Claims 1 and 10 are currently amended.
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
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Claim Interpretation Under 35 USC § 112(f)
The following is a quotation of 35 U.S.C. 112(f):
(f) ELEMENT IN CLAIM FOR A COMBINATION.—An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f):
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f). The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f). The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) because the claim limitations use a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitations are: “a storage section that […],” “a partial code extraction section that […],” “a feature vector generation section that […],” “a learning processing section that […],” “a performance verification processing section that […],” and “a communication section that […]” in Claims 1-9.
Because these claim limitations are being interpreted under 35 U.S.C. 112(f), they are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If the Applicant does not intend to have these limitations interpreted under 35 U.S.C. 112(f), the Applicant may: (1) amend the claim limitations to avoid them being interpreted under 35 U.S.C. 112(f) (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitations recite sufficient structure to perform the claimed function so as to avoid them being interpreted under 35 U.S.C. 112(f).
Specification
The title of the invention is not descriptive. A new title is required that is clearly indicative of the invention to which the claims are directed.
The following title is suggested: SOFTWARE PERFORMANCE VERIFICATION USING A FEATURE VECTOR BASED ON PARTIAL CODE.
The abstract of the disclosure is objected to because it exceeds 150 words in length. A corrected abstract of the disclosure is required and must be presented on a separate sheet, apart from any other text. See MPEP § 608.01(b).
Claim Objections
Claims 7 and 9 are objected to because of the following informalities:
Claim 7 recites “the indicators.” It should read -- the plurality of indicators --.
Claim 9 recites “the verification result.” It should read -- the verification result of the partial code --.
Appropriate correction is required.
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.
Claims 1-10 are rejected under 35 U.S.C. 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor regards as the invention.
Claims 1 and 10 recite the limitation “the basis of the partial code.” There is insufficient antecedent basis for this limitation in the claims. In the interest of compact prosecution, the Examiner subsequently interprets this limitation as reading “a basis of the partial code” for the purpose of further examination.
Claims 2-9 depend on Claim 1. Therefore, Claims 2-9 suffer the same deficiency as Claim 1.
Claim 6 recites the limitation “the probability.” There is insufficient antecedent basis for this limitation in the claim. In the interest of compact prosecution, the Examiner subsequently interprets this limitation as reading “a probability” for the purpose of further examination.
Claims 6 and 7 recite the limitation “the performance.” There is insufficient antecedent basis for this limitation in the claims. In the interest of compact prosecution, the Examiner subsequently interprets this limitation as reading “a performance” for the purpose of further examination.
Claim 7 recites the limitation “the indicators being based each on a different viewpoint.” The claim is rendered vague and indefinite because of the awkward claim language used. In the interest of compact prosecution, the Examiner subsequently interprets this limitation as reading “each of the plurality of indicators being based on a different viewpoint” for the purpose of further examination.
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.
Claims 1-10 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Claim Interpretation: Under the broadest reasonable interpretation (BRI), the limitations of Claim 1 are presumed to have their plain meaning consistent with the specification as it would be interpreted by one of ordinary skill in the art. See MPEP § 2111.
Step 1: Claim 1 is directed to a software performance verification system, which is a machine, and falls within one of the statutory categories of invention.
Step 2A, Prong One: Claim 1 recites the limitations:
(a) […] extracts a partial code as part of the code;
(b) […] generates a feature vector based on the partial code;
(c) […] generates a performance verification model […] that includes the feature vector of the partial code for learning and performance information indicative of a performance of the software expressed by at least either indicator of throughput, response time, and resource usage obtained by executing a software implemented on the basis of the partial code; and
(d) […] generates, as a verification result of the partial code, information based on output obtained through input of the partial code as a verification target to the performance verification model.
These recited steps, under the broadest reasonable interpretation (BRI), cover performance of the steps in the human mind alone or with the aid of pen and paper. That is, other than reciting:
(1) [a] software performance verification system configured by use of an information processing apparatus, the software performance verification system comprising:
(2) a storage section that […];
(3) a partial code extraction section that […];
(4) a feature vector generation section that […];
(5) a learning processing section that […];
(6) […] a machine learning model having been trained by use of learning data […]; and
(7) a performance verification processing section […].
Nothing in the claim precludes the steps from practically being performed in the human mind alone using observation, evaluation, judgment, and opinion or with the aid of pen and paper. For example, the limitation (a) in the context of the claim encompasses a human observing the code in the human mind alone using observation, evaluation, judgment, and opinion or with the aid of pen and paper to extract a partial code. And the limitation (b) in the context of the claim encompasses a human observing the partial code in the human mind alone using observation, evaluation, judgment, and opinion or with the aid of pen and paper to generate a feature vector. And the limitation (c) in the context of the claim encompasses a human observing the feature vector of the partial code in the human mind alone using observation, evaluation, judgment, and opinion or with the aid of pen and paper to generate a performance verification model. And the limitation (d) in the context of the claim encompasses a human observing output obtained through input of the partial code in the human mind alone using observation, evaluation, judgment, and opinion or with the aid of pen and paper to generate information. See MPEP § 2106.04(a)(2)(III).
If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the human mind alone or with the aid of pen and paper but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Step 2A, Prong Two: This judicial exception is not integrated into a practical application. In particular, the claim recites the additional elements:
(1) [a] software performance verification system configured by use of an information processing apparatus, the software performance verification system comprising:
(2) a storage section that […];
(3) a partial code extraction section that […];
(4) a feature vector generation section that […];
(5) a learning processing section that […];
(6) […] a machine learning model having been trained by use of learning data […]; and
(7) a performance verification processing section […].
The additional elements (1) to (7) are recited at a high-level of generality such that they amount to no more than mere instructions to apply the judicial exception using generic computer components. The information processing apparatus and the various sections of the software performance verification system are used as tools to perform the various steps of the claim. See MPEP § 2106.05(f).
Also, the claim recites the additional element:
(8) […] stores code of a program configuring software.
The additional element (8) is mere data storing recited at a high level of generality, and thus is an insignificant extra-solution activity. See MPEP § 2106.05(g). Furthermore, all uses of the recited judicial exception require such data storing, and, as such, the additional element does not impose any meaningful limits on the claim. The additional element amounts to necessary data storing. See MPEP § 2106.05.
Accordingly, even when viewed in combination, 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 claim is directed to an abstract idea.
Step 2B: The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements when considered both individually and as a combination do not amount to significantly more than the abstract idea. As discussed above with respect to integration of the abstract idea into a practical application, the claim recites the additional elements:
(1) [a] software performance verification system configured by use of an information processing apparatus, the software performance verification system comprising:
(2) a storage section that […];
(3) a partial code extraction section that […];
(4) a feature vector generation section that […];
(5) a learning processing section that […];
(6) […] a machine learning model having been trained by use of learning data […]; and
(7) a performance verification processing section […].
The additional elements (1) to (7) amount to no more than mere instructions to apply the judicial exception using generic computer components. Mere instructions to apply a judicial exception using generic computer components cannot provide an inventive concept.
Also, the claim recites the additional element:
(8) […] stores code of a program configuring software.
The additional element (8) simply appends a well-understood, routine, and conventional activity previously known to the industry, specified at a high level of generality, to the judicial exception is not indicative of an inventive concept. MPEP § 2106.05(d)(II) expressly states that the courts have recognized the computer function of storing and retrieving information in memory as a well‐understood, routine, and conventional computer function when it is claimed in a merely generic manner (e.g., at a high level of generality) or as an insignificant extra-solution activity. Thus, a person of ordinary skill in the art would readily comprehend that it is well-understood, routine, and conventional in the computing art to store code of a program. Therefore, the limitation remains an insignificant extra-solution activity even upon reconsideration and does not amount to significantly more.
Thus, taken alone, the additional elements do not amount to significantly more than the above-identified judicial exception (the abstract idea). Looking at the additional elements as a combination adds nothing that is not already present when looking at the additional elements taken individually. Even when considered in combination, the additional elements represent mere instructions to apply a judicial exception using generic computer components and an insignificant extra-solution activity, and therefore do not provide an inventive concept. The claim is not patent eligible.
Claims 2-9 are rejected under 35 U.S.C. 101 as directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more for at least the reasons stated above.
Claim 2 recites the limitations:
(a) wherein the code includes a description of a method, and
(b) wherein the partial code extraction section extracts the partial code from the code in units of the method.
<<>> + <<>> + <<>> + <<>> + <<>> + <<>> + <<>> + <<>>
Claim 3 recites the limitations:
(a) wherein the code includes a description of a method, and
(b) wherein the partial code extraction section extracts, as the partial code, a description including the description of one method and the description of another method having a call relation with the method.
<<>> + <<>> + <<>> + <<>> + <<>> + <<>> + <<>> + <<>>
Claim 4 recites the limitation:
(a) wherein the feature vector generation section generates, as the feature vector, a vector having metrics values acquired from the partial code as an element of the vector.
<<>> + <<>> + <<>> + <<>> + <<>> + <<>> + <<>> + <<>>
Claim 5 recites the limitations:
(a) wherein the storage section stores a word dictionary including information associating a description obtained by converting to common form a word used in the code describing the software with a value set for each such description, and
(b) wherein the feature vector generation section converts a word included in the partial code into a common form word, acquires from the word dictionary a value corresponding to the description of the word, and generates a vector having the acquired value as an element thereof and configuring the feature vector.
<<>> + <<>> + <<>> + <<>> + <<>> + <<>> + <<>> + <<>>
Claim 6 recites the limitation:
(a) wherein the performance verification model outputs the probability of there being a problem with the performance of a process to be implemented on a basis of the partial code.
<<>> + <<>> + <<>> + <<>> + <<>> + <<>> + <<>> + <<>>
Claim 7 recites the limitation:
(a) wherein the performance verification model outputs a plurality of indicators indicating the performance of a process to be implemented on a basis of the partial code, the indicators being based each on a different viewpoint.
<<>> + <<>> + <<>> + <<>> + <<>> + <<>> + <<>> + <<>>
Claim 8 recites the limitations:
(a) wherein the software performance verification system further includes a user interface that receives, from a user, designation of the code and designation of a predetermined method described in the code, and
(b) wherein the partial code extraction section extracts as the partial code the description of the predetermined method designated by the user in the code.
<<>> + <<>> + <<>> + <<>> + <<>> + <<>> + <<>> + <<>>
Claim 9 recites the limitations:
(a) wherein the software performance verification system further includes a communication section that communicates with a joint development environment that uses a repository to manage the code jointly developed by a plurality of users, the joint development environment determining whether to register the code with the repository depending on the verification result, and
(b) upon receipt, by the communication section, of a request to verify the code from the joint development environment,
(c) wherein the partial code extraction section extracts the partial code from the code,
(d) wherein the feature vector generation section generates a feature vector based on the partial code, and
(e) wherein the performance verification processing section generates the verification result by inputting the feature vector of the partial code to the performance verification model, and transmits the verification result to the joint development environment.
These claims are dependent on Claim 1, but do not add any feature or subject matter that would solve the judicial exception deficiencies of Claim 1.
Claims 2-5, 8, and 9 recite further mental steps which can be practically performed in the human mind alone using observation, evaluation, judgment, and opinion or with the aid of pen and paper and thus, fail to make the claim any less abstract (see MPEP § 2106.04(a)(2)(III)).
Claims 8 and 9 recite further additional elements that do not integrate the judicial exception into a practical application of the judicial exception because they are mere instructions to apply the judicial exception using generic computer components (see MPEP § 2106.05(f)), and thus, are not significantly more than the abstract idea.
Claims 5-9 recite further additional elements that do not integrate the judicial exception into a practical application of the judicial exception because they are mere data gathering/transmitting/outputting recited at a high level of generality, and thus are insignificant extra-solution activities (see MPEP § 2106.05(g)), and thus, are not significantly more than the abstract idea.
Thus, Claims 2-9 do not add any steps or additional elements, when considered both individually and as a combination, that would convert Claim 1 into patent-eligible subject matter.
Therefore, Claims 1-9 are not drawn to patent-eligible subject matter as they are directed to an abstract idea without significantly more.
<<>> • × • <<>> • × • <<>> • × • <<>> • × • <<>> • × • <<>> • × • <<>> • × • <<>>
Claim Interpretation: Under the broadest reasonable interpretation (BRI), the limitations of Claim 10 are presumed to have their plain meaning consistent with the specification as it would be interpreted by one of ordinary skill in the art. See MPEP § 2111.
Step 1: Claim 10 is directed to a software performance verification method, which is a process (a series of steps or acts), and falls within one of the statutory categories of invention.
Step 2A, Prong One: Claim 10 recites the limitations:
(a) extracting a partial code as part of the code;
(b) generating a feature vector based on the partial code;
(c) generating a performance verification model […] that includes the feature vector of the partial code for learning and performance information indicative of a performance of the software expressed by at least either indicator of throughput, response time, and resource usage obtained by executing a software implemented on the basis of the partial code; and
(d) generating, as a verification result of the partial code, information based on output obtained through input of the partial code as a verification target to the performance verification model.
These recited steps, under the broadest reasonable interpretation (BRI), cover performance of the steps in the human mind alone or with the aid of pen and paper. That is, nothing in the claim precludes the steps from practically being performed in the human mind alone using observation, evaluation, judgment, and opinion or with the aid of pen and paper. For example, the limitation (a) in the context of the claim encompasses a human observing the code in the human mind alone using observation, evaluation, judgment, and opinion or with the aid of pen and paper to extract a partial code. And the limitation (b) in the context of the claim encompasses a human observing the partial code in the human mind alone using observation, evaluation, judgment, and opinion or with the aid of pen and paper to generate a feature vector. And the limitation (c) in the context of the claim encompasses a human observing the feature vector of the partial code in the human mind alone using observation, evaluation, judgment, and opinion or with the aid of pen and paper to generate a performance verification model. And the limitation (d) in the context of the claim encompasses a human observing output obtained through input of the partial code in the human mind alone using observation, evaluation, judgment, and opinion or with the aid of pen and paper to generate information. See MPEP § 2106.04(a)(2)(III).
If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the human mind alone or with the aid of pen and paper but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Step 2A, Prong Two: This judicial exception is not integrated into a practical application. In particular, the claim recites the additional element:
(1) storing code of a program configuring software.
The additional element (1) is mere data storing recited at a high level of generality, and thus is an insignificant extra-solution activity. See MPEP § 2106.05(g). Furthermore, all uses of the recited judicial exception require such data storing, and, as such, the additional element does not impose any meaningful limits on the claim. The additional element amounts to necessary data storing. See MPEP § 2106.05.
Accordingly, even when viewed in combination, the additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
Step 2B: The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements when considered both individually and as a combination do not amount to significantly more than the abstract idea. As discussed above with respect to integration of the abstract idea into a practical application, the claim recites the additional element:
(1) storing code of a program configuring software.
The additional element (1) simply appends a well-understood, routine, and conventional activity previously known to the industry, specified at a high level of generality, to the judicial exception is not indicative of an inventive concept. MPEP § 2106.05(d)(II) expressly states that the courts have recognized the computer function of storing and retrieving information in memory as a well‐understood, routine, and conventional computer function when it is claimed in a merely generic manner (e.g., at a high level of generality) or as an insignificant extra-solution activity. Thus, a person of ordinary skill in the art would readily comprehend that it is well-understood, routine, and conventional in the computing art to store code of a program. Therefore, the limitation remains an insignificant extra-solution activity even upon reconsideration and does not amount to significantly more.
Thus, taken alone, the additional element does not amount to significantly more than the above-identified judicial exception (the abstract idea). Looking at the additional element as a combination adds nothing that is not already present when looking at the additional element taken individually. Even when considered in combination, the additional element represents an insignificant extra-solution activity, and therefore does not provide an inventive concept. The claim is not patent eligible.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 6, 7, and 10 are rejected under 35 U.S.C. 103 as being unpatentable over US 2018/0150742 (hereinafter “Woulfe”) (cited in the IDS submitted on 03/19/2025) in view of US 2018/0343186 (hereinafter “Milanese”).
[Examiner’s Remarks: In order for a reference to be proper for use in an obviousness rejection under 35 U.S.C. 103, the reference must be analogous art to the claimed invention. In re Bigio, 381 F.3d 1320, 1325, 72 USPQ2d 1209, 1212 (Fed. Cir. 2004). A reference is analogous art to the claimed invention if: (1) the reference is from the same field of endeavor as the claimed invention (even if it addresses a different problem); or (2) the reference is reasonably pertinent to the problem faced by the inventor (even if it is not in the same field of endeavor as the claimed invention).
Note that the claimed invention is generally directed to software performance verification (specification, paragraph [0002]). As for the “same field of endeavor” test, Woulfe is generally directed to predicting software bugs in a source code file (Woulfe, paragraph [0019]). And Milanese is generally directed to determining a performance trend of a software application based on performance indicators of the software application (Milanese, Abstract). Thus, Woulfe and Milanese are both analogous art to the claimed invention (even if they address different problems). See MPEP § 2141.01(a)(I).]
As per Claim 1, Woulfe discloses:
A software performance verification system (Figure 1A: 100) configured by use of an information processing apparatus, the software performance verification system comprising:
a storage section that stores code of a program configuring software (paragraph [0039], “Turning to FIG. 3, there is shown a portion of an original source code file 302 written in C# having 14 lines of code or source code statements.” and “This original source code file 302 may be stored in a source code repository (emphasis added).”);
a partial code extraction section that extracts a partial code as part of the code (paragraph [0039], “Turning to FIG. 3, there is shown a portion of an original source code file 302 written in C# having 14 lines of code or source code statements. For the purposes of this example, a source code statement is identified as being a continuous sequence of code elements that ends at a semicolon. This original source code file 302 may be stored in a source code repository. The original source code file 302 may have been checked out of the source code repository [extracts a partial code as part of the code] (emphasis added).”; paragraph [0058], “The code analysis engine 110 analyzes the source code file 802 and annotates predetermined elements of the source code file 802 with tokens as shown in annotated source code 804.”);
a feature vector generation section that generates a feature vector based on the partial code (paragraph [0060], “The annotated source code file 804 is then input into the training engine 114 which transforms the annotated source code statements into a binary representation or feature vectors that train a machine learning model, such as a recurrent neural network (RNN) [generates a feature vector based on the partial code] (emphasis added). The training engine 114 groups contiguous source code statements preceding a particular source code statement using a window of a certain size into feature vectors which are then used to train the RNN.”); and
a learning processing section that generates a performance verification model that is a machine learning model having been trained by use of learning data that includes the feature vector of the partial code for learning (paragraph [0028], “FIG. 1A illustrates an exemplary configuration of a system 100 for training a machine learning model for source code bug prediction. In one aspect of the subject matter disclosed herein, the system 100 executes a training phase 102 that generates a model 116 [a performance verification model] to predict the likelihood of a software bug in a source code file (emphasis added).” and “The mined data 108 is then input to a code analysis engine 110 that analyzes each source code statement in order to extract features which are transformed into training data 112 that includes the flag 107 and the extracted features 111. The training data 112 is analyzed by the training engine 114. The training engine 114 includes a feature vector generation engine 123 and a model generation engine 117. The feature vector generation engine 123 receives the training data 112 and transforms the training data 112 into feature vectors. The feature vectors are then input to the model generation engine 117 to train a probabilistic machine learning model 116 to determine a probability of the existence of a software bug [by use of learning data that includes the feature vector of the partial code for learning] (emphasis added).”).
Woulfe does not explicitly disclose:
performance information indicative of a performance of the software expressed by at least either indicator of throughput, response time, and resource usage obtained by executing a software implemented on the basis of the partial code; and
a performance verification processing section that generates, as a verification result of the partial code, information based on output obtained through input of the partial code as a verification target to the performance verification model.
However, Milanese discloses:
performance information indicative of a performance of the software expressed by at least either indicator of throughput, response time, and resource usage obtained by executing a software implemented on the basis of the partial code (paragraph [0025], “Starting from FIG. 1A, a server computing machine, or simply server 105, may run a software application 110 (such as interacting with one or more databases, not shown in the figure) [executing a software]. For example, the software application 110 is a web application that is available via the Internet.”; paragraph [0035], “[…] each program may be a module, segment or portion of code [a software implemented on the basis of the partial code], which comprises one or more executable instructions for implementing the specified logical function.”; paragraph [0037], “[…] an analyzer 335 may determine the performance trend of the software application 110 [performance information indicative of a performance of the software]. For this purpose, the analyzer 335 interacts with the software application 110 and it accesses (in read mode) the operation request log 330 for submitting (sample) operation requests to the software application 110 and collecting their (sample) response times and for retrieving the (actual) response times of the logged operation requests (emphasis added).”); and
a performance verification processing section that generates, as a verification result of the partial code, information based on output obtained through input of the partial code as a verification target to the performance verification model (paragraph [0037], “The analyzer 335 may access (in write mode) a performance trend repository, which stores the (up-to-date) performance trend of the software application 110 (denoted with the same reference 115). For example, the performance trend indicates a baseline response time of the software application 110 that is expected for a baseline query (according to predefined performance guidelines depending on the environment parameters) [generates, as a verification result of the partial code, information based on output obtained through input of the partial code as a verification target to the performance verification model]. The performance trend indicates the response times that are expected for one or more sample types of the sample operation requests, such as defined by selected tables, filtered fields and sorting criteria. The performance trend indicates the (average) response times that have been experienced (by the logged operation requests) for different time periods (such as every hour during the working days, every night and every weekend) and for different ranges of the number of concurrent users, or user ranges (such as with a pitch of 10-100 concurrent users).”).
As pointed out hereinabove, Woulfe and Milanese are both analogous art to the claimed invention. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Milanese into the teaching of Woulfe to include “performance information indicative of a performance of the software expressed by at least either indicator of throughput, response time, and resource usage obtained by executing a software implemented on the basis of the partial code; and a performance verification processing section that generates, as a verification result of the partial code, information based on output obtained through input of the partial code as a verification target to the performance verification model.” The modification would be obvious because one of ordinary skill in the art would be motivated to collect performance indicators of computing systems (for example, by measuring different metrics relating to monitored resources thereof) and detect any problems that may be experienced by the computing systems, so that appropriate actions may be taken to remedy the situation (Milanese, paragraph [0008]).
As per Claim 6, the rejection of Claim 1 is incorporated; and Woulfe further discloses:
wherein the performance verification model outputs the probability of there being a problem with the performance of a process to be implemented on a basis of the partial code (paragraph [0033], “The feature vector generation engine 123 converts the features or input 122 into feature vectors that is input to the model 116. The model 116 outputs probabilities 126 for each designated portion that indicates the likelihood of a particular source code statement having a bug. The probabilities 126 for each portion of the source code may be input into a visualization engine 128 that identifies potential software bugs.”).
As per Claim 7, the rejection of Claim 1 is incorporated; and Woulfe does not explicitly disclose:
wherein the performance verification model outputs a plurality of indicators indicating the performance of a process to be implemented on a basis of the partial code, the indicators being based each on a different viewpoint.
However, Milanese discloses:
wherein the performance verification model outputs a plurality of indicators indicating the performance of a process to be implemented on a basis of the partial code, the indicators being based each on a different viewpoint (paragraph [0025], “Starting from FIG. 1A, a server computing machine, or simply server 105, may run a software application 110 (such as interacting with one or more databases, not shown in the figure). For example, the software application 110 is a web application that is available via the Internet.”; paragraph [0035], “[…] each program may be a module, segment or portion of code, which comprises one or more executable instructions for implementing the specified logical function.”; paragraph [0037], “[…] an analyzer 335 may determine the performance trend of the software application 110. For this purpose, the analyzer 335 interacts with the software application 110 and it accesses (in read mode) the operation request log 330 for submitting (sample) operation requests to the software application 110 and collecting their (sample) response times and for retrieving the (actual) response times of the logged operation requests.”).
As pointed out hereinabove, Milanese is an analogous art to the claimed invention. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Milanese into the teaching of Woulfe to include “wherein the performance verification model outputs a plurality of indicators indicating the performance of a process to be implemented on a basis of the partial code, the indicators being based each on a different viewpoint.” The modification would be obvious because one of ordinary skill in the art would be motivated to collect performance indicators of computing systems (for example, by measuring different metrics relating to monitored resources thereof) and detect any problems that may be experienced by the computing systems, so that appropriate actions may be taken to remedy the situation (Milanese, paragraph [0008]).
Claim 10 is a software performance verification method claim corresponding to the software performance verification system claim hereinabove (Claim 1). Therefore, Claim 10 is rejected for the same reason set forth in the rejection of Claim 1.
Claims 2, 3, and 8 are rejected under 35 U.S.C. 103 as being unpatentable over Woulfe in view of Milanese as applied to Claim 1 above, and further in view of US 2019/0220596 (hereinafter “Lie”).
[Examiner’s Remarks: In order for a reference to be proper for use in an obviousness rejection under 35 U.S.C. 103, the reference must be analogous art to the claimed invention. In re Bigio, 381 F.3d 1320, 1325, 72 USPQ2d 1209, 1212 (Fed. Cir. 2004). A reference is analogous art to the claimed invention if: (1) the reference is from the same field of endeavor as the claimed invention (even if it addresses a different problem); or (2) the reference is reasonably pertinent to the problem faced by the inventor (even if it is not in the same field of endeavor as the claimed invention).
Note that the claimed invention is generally directed to (specification, paragraph [00]). As for the “reasonably pertinent” test, Lie is generally directed to the detection of malicious code in software (Lie, paragraph [0002]). Thus, Lie is an analogous art to the claimed invention (even if it is not in the same field of endeavor as the claimed invention). See MPEP § 2141.01(a)(I).]
As per Claim 2, the rejection of Claim 1 is incorporated; and the combination of Woulfe and Milanese does not explicitly disclose:
wherein the code includes a description of a method, and
wherein the partial code extraction section extracts the partial code from the code in units of the method.
However, Lie discloses:
wherein the code includes a description of a method (paragraph [0093], “The source code extraction feature processes each source file individually and outputs each function as a description.”), and
wherein the partial code extraction section extracts the partial code from the code in units of the method (paragraph [0046], “An extractor is configured to accept as input a first set of code (e.g. source code) and extract from the code a first set of features including a first set of functions […].”).
As pointed out hereinabove, Lie is an analogous art to the claimed invention. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Lie into the combined teachings of Woulfe and Milanese to include “wherein the code includes a description of a method, and wherein the partial code extraction section extracts the partial code from the code in units of the method.” The modification would be obvious because one of ordinary skill in the art would be motivated to perform source code audits (Lie, paragraph [0003]).
As per Claim 3, the rejection of Claim 1 is incorporated; and the combination of Woulfe and Milanese does not explicitly disclose:
wherein the code includes a description of a method, and
wherein the partial code extraction section extracts, as the partial code, a description including the description of one method and the description of another method having a call relation with the method.
However, Lie discloses:
wherein the code includes a description of a method (paragraph [0093], “The source code extraction feature processes each source file individually and outputs each function as a description.”), and
wherein the partial code extraction section extracts, as the partial code, a description including the description of one method and the description of another method having a call relation with the method (paragraph [0026], “[…] binary code and source code can have a call graph. The code auditor can determine the accountability of binary code if the call graph of binary code is accountable to the call graph of source code when a set of binary code functions match a set of source code functions.”; paragraph [0046], “An extractor is configured to accept as input a first set of code (e.g. source code) and extract from the code a first set of features including a first set of functions […].”).
As pointed out hereinabove, Lie is an analogous art to the claimed invention. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Lie into the combined teachings of Woulfe and Milanese to include “wherein the code includes a description of a method, and wherein the partial code extraction section extracts, as the partial code, a description including the description of one method and the description of another method having a call relation with the method.” The modification would be obvious because one of ordinary skill in the art would be motivated to perform source code audits (Lie, paragraph [0003]).
As per Claim 8, the rejection of Claim 2 is incorporated; and Woulfe further discloses:
wherein the software performance verification system further includes a user interface that receives, from a user, designation of the code and designation of a predetermined method described in the code (paragraph [0034], “[…] the visualization engine can be part of a source code editor or an integrated development environment (IDE). In another aspect, the visualization may be part of a user interface, a browser, or other type of application configured to present the source code file and model output in a visual manner.”; paragraph [0067], “[…] as shown in FIG. 10A, there is shown a segment of a source code file 1000 having four lines of source code enclosed in a box, 1002, 1004, 1006, 1008. These boxes can be highlighted in different colors with each color indicating a particular probability or indicating that the probability associated with a line exceeds a threshold. Alternatively, the boxes can be shaded in one color and the text can be displayed in another color.”), and
wherein the partial code extraction section extracts as the partial code […] designated by the user in the code (paragraph [0034], “[…] the visualization engine can be part of a source code editor or an integrated development environment (IDE). In another aspect, the visualization may be part of a user interface, a browser, or other type of application configured to present the source code file and model output in a visual manner.”; paragraph [0058], “The code analysis engine 110 analyzes the source code file 802 and annotates predetermined elements of the source code file 802 with tokens as shown in annotated source code 804.”).
The combination of Woulfe and Milanese does not explicitly disclose:
the description of the predetermined method.
However, Lie discloses:
the description of the predetermined method (paragraph [0093], “The source code extraction feature processes each source file individually and outputs each function as a description.”).
As pointed out hereinabove, Lie is an analogous art to the claimed invention. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Lie into the combined teachings of Woulfe and Milanese to include “the description of the predetermined method.” The modification would be obvious because one of ordinary skill in the art would be motivated to perform source code audits (Lie, paragraph [0003]).
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Woulfe in view of Milanese as applied to Claim 1 above, and further in view of US 2009/0210364 (hereinafter “Adi”).
[Examiner’s Remarks: In order for a reference to be proper for use in an obviousness rejection under 35 U.S.C. 103, the reference must be analogous art to the claimed invention. In re Bigio, 381 F.3d 1320, 1325, 72 USPQ2d 1209, 1212 (Fed. Cir. 2004). A reference is analogous art to the claimed invention if: (1) the reference is from the same field of endeavor as the claimed invention (even if it addresses a different problem); or (2) the reference is reasonably pertinent to the problem faced by the inventor (even if it is not in the same field of endeavor as the claimed invention).
Note that the claimed invention is generally directed to (specification, paragraph [00]). As for the “reasonably pertinent” test, Adi is generally directed to generating complex event processing system rules to infer a specific output event based on a stream of input events (Adi, paragraph [0001]). Thus, Adi is an analogous art to the claimed invention (even if it is not in the same field of endeavor as the claimed invention). See MPEP § 2141.01(a)(I).]
As per Claim 4, the rejection of Claim 1 is incorporated; and Woulfe discloses “wherein the feature vector generation section generates, as the feature vector, a vector […] from the partial code […],” but the combination of Woulfe and Milanese does not explicitly disclose:
wherein the feature vector generation section generates, as the feature vector, a vector having metrics values acquired from the partial code as an element of the vector.
However, Adi discloses:
[…] a vector having metrics values […] as an element of the vector (paragraph [0048], “Each vector element stores the number of events that occurred within a specific time period for a specific metric value […].”).
As pointed out hereinabove, Adi is an analogous art to the claimed invention. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Adi into the combined teachings of Woulfe and Milanese to include “wherein the feature vector generation section generates, as the feature vector, a vector having metrics values acquired from the partial code as an element of the vector.” The modification would be obvious because one of ordinary skill in the art would be motivated to implement a vector using metric values related to source code.
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Woulfe in view of Milanese as applied to Claim 1 above, and further in view of US 2006/0200803 (hereinafter “Neumann”).
[Examiner’s Remarks: In order for a reference to be proper for use in an obviousness rejection under 35 U.S.C. 103, the reference must be analogous art to the claimed invention. In re Bigio, 381 F.3d 1320, 1325, 72 USPQ2d 1209, 1212 (Fed. Cir. 2004). A reference is analogous art to the claimed invention if: (1) the reference is from the same field of endeavor as the claimed invention (even if it addresses a different problem); or (2) the reference is reasonably pertinent to the problem faced by the inventor (even if it is not in the same field of endeavor as the claimed invention).
Note that the claimed invention is generally directed to (specification, paragraph [00]). As for the “reasonably pertinent” test, Neumann is generally directed to checkin policies for source code control systems (Neumann, paragraph [0001]). Thus, Neumann is an analogous art to the claimed invention (even if it is not in the same field of endeavor as the claimed invention). See MPEP § 2141.01(a)(I).]
As per Claim 9, the rejection of Claim 1 is incorporated; and Woulfe further discloses:
wherein the software performance verification system further includes a communication section that communicates with a joint development environment that uses a repository to manage the code jointly developed by a plurality of users (Figure 1A; paragraph [0028], “The system 100 includes a source code repository 104 coupled to a data mining engine 106. The data mining engine 106 searches or mines the source code repository 104 for one or more source code files having been modified to fix bugs and for source code files that have not had bug fixes.”; paragraph [0036], “Referring to FIG. 2, the data mining engine searches a source code repository for exemplary source code files with and without software bugs (block 202). The source code repository may be a version control system such as Apache Subversion or GIT.”; paragraph [0074], “In one aspect, the techniques described herein may be applied to a specific set of source code files, such as the source code files of a specific developer or group of developers, such as members on the same programming team or project.”), and
the partial code extraction section extracts the partial code from the code (paragraph [0058], “The code analysis engine 110 analyzes the source code file 802 and annotates predetermined elements of the source code file 802 with tokens as shown in annotated source code 804.”),
the feature vector generation section generates a feature vector based on the partial code (paragraph [0060], “The annotated source code file 804 is then input into the training engine 114 which transforms the annotated source code statements into a binary representation or feature vectors that train a machine learning model, such as a recurrent neural network (RNN). The training engine 114 groups contiguous source code statements preceding a particular source code statement using a window of a certain size into feature vectors which are then used to train the RNN.”), and
the performance verification processing section generates the verification result by inputting the feature vector of the partial code to the performance verification model (paragraph [0028], “FIG. 1A illustrates an exemplary configuration of a system 100 for training a machine learning model for source code bug prediction. In one aspect of the subject matter disclosed herein, the system 100 executes a training phase 102 that generates a model 116 to predict the likelihood of a software bug in a source code file.” and “The mined data 108 is then input to a code analysis engine 110 that analyzes each source code statement in order to extract features which are transformed into training data 112 that includes the flag 107 and the extracted features 111. The training data 112 is analyzed by the training engine 114. The training engine 114 includes a feature vector generation engine 123 and a model generation engine 117. The feature vector generation engine 123 receives the training data 112 and transforms the training data 112 into feature vectors. The feature vectors are then input to the model generation engine 117 to train a probabilistic machine learning model 116 to determine a probability of the existence of a software bug.”).
The combination of Woulfe and Milanese does not explicitly disclose:
the joint development environment determining whether to register the code with the repository depending on the verification result;
upon receipt, by the communication section, of a request to verify the code from the joint development environment; and
transmits the verification result to the joint development environment.
However, Neumann discloses:
the joint development environment determining whether to register the code with the repository depending on the verification result (paragraph [0088], “In act 1050, process 1000 proceeds to perform different acts based on the policy compliance results determined in 1030. When the source code being submitted is compliant with the enabled policies, process 1000 proceeds to checkin the source code to the source code repository, as indicated in act 1060.”);
upon receipt, by the communication section, of a request to verify the code from the joint development environment (paragraph [0086], “In act 1030, policy compliance of the source code is evaluated. In one embodiment, the policy compliance of the source code may be evaluated by calling policy plugins corresponding to the policy types of the enabled policies, as described for process 730', illustrated in FIG. 8.”); and
transmits the verification result to the joint development environment (paragraph [0087], “In act 1040, policy compliance information may be displayed in a user interface either inside or outside the IDE, or in any other tool, as the invention is not limited in this respect. The policy compliance information may include a list of any policy failures, indication of the source code causing the policy failures, and/or any desired information, as the invention is not limited in this respect.”).
As pointed out hereinabove, Neumann is an analogous art to the claimed invention. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Neumann into the combined teachings of Woulfe and Milanese to include “the joint development environment determining whether to register the code with the repository depending on the verification result; upon receipt, by the communication section, of a request to verify the code from the joint development environment; and transmits the verification result to the joint development environment.” The modification would be obvious because one of ordinary skill in the art would be motivated to establish checkin policies governing source code that may be submitted to a source code repository (Neumann, paragraph [0022]).
Allowable Subject Matter
Claim 5 is objected to as being dependent upon a rejected base claim under 35 U.S.C. § 103, but would be allowable over the cited prior art if rewritten in independent form including all of the limitations of the base claim and any intervening claims, and overcome any corresponding objections and/or rejections set forth hereinabove.
Conclusion
The prior art made of record and not relied upon is considered pertinent to the Applicant’s disclosure. They are as follows:
US 2004/0163079 (hereinafter “Noy”) discloses the real-time capture, recognition, and analysis of target software behavior.
US 2005/0283765 (hereinafter “Warren”) discloses analyzing code execution in order to analyze and improve software performance by rapidly identifying of areas of code based on cost and use, and which may be candidates for optimization.
US 2007/0277155 (hereinafter “Casey”) discloses evaluating the performance of a software application.
US 2012/0079456 (hereinafter “Kannan”) discloses identifying factors that affect software performance during development.
US 2015/0227448 (hereinafter “Goel”) discloses evaluating performance of a software application through run-time assembly code execution.
US 2016/0321037 (hereinafter “Ono”) discloses verifying the performance of a program executed on a multi-core processor.
US 6,374,369 (hereinafter “O’Donnell”) discloses analyzing the performance of software using a combination of statistical sampling, hardware events and feedback, and a finite state machine execution model.
Any inquiry concerning this communication or earlier communications from the Examiner should be directed to Qing Chen whose telephone number is 571-270-1071. The Examiner can normally be reached on Monday through Friday from 9:00 AM to 5:00 PM ET.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, the Applicant is encouraged to use the USPTO Automated Interview Request (AIR) at https://www.uspto.gov/interviewpractice.
If attempts to reach the Examiner by telephone are unsuccessful, the Examiner’s supervisor, Wei Mui, can be reached at 571-272-3708. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for more 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.
/Qing Chen/
Primary Examiner, Art Unit 2191