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 .
Examiner’s Note (EN)
The prior art rejections below cite particular paragraphs, columns, and/or line numbers in the references 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 their 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.
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-13 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Claim 1
Step 1: Statutory class – apparatus.
Step 2A Prong One: Does the claim recite an abstract idea, law of nature or natural phenomenon?
Yes
“3) Mental processes – concepts performed in the human mind (including an observation, evaluation, judgment, opinion) (see MPEP § 2106.04(a)(2), subsection III).” MPEP § 2106.04(a).
The claims are directed to an abstract idea of data processing and analysis. The claim recites:
measure software quality data values each indicating quality of the source code, based on the source code;
calculate complexity of the source code in a software structure as a diagnosed age of the source code, based on the software quality data values;.
calculate, based on the diagnosed age accumulated by the data accumulation storage for each of the revisions, a development trend approximate expression indicating a relationship between the revision and the diagnosed age; and
estimate a lifetime on the revision of the source code, based on the development trend approximate expression,
The measuring, calculating and estimating limitations are limitations of mental processes of evaluation, and judgement. By way of example, one can mentally evaluate the quality metrics of the source code, calculate a complexity score, and calculate a trend approximation along with a lifetime estimate based on the previously calculated values.
Step 2A Prong Two: Does the claim recite additional elements that integrate the judicial exception into a practical application?
No.
The additional elements are:
obtaining circuitry to obtain a source code;
software quality measurement unit;
age calculator
data accumulation unit;
development trend approximate expression calculator
lifetime estimation unit;
software quality measurement circuitry to
a data accumulation storage to accumulate the diagnosed age for each of revisions of the source code;
wherein the architecture lifetime estimation apparatus outputs information based on the lifetime.
The calculators / units and circuitry / components are generic computer components used as a tool. They provide nothing more than mere instructions to implement an abstract idea on a generic computer. The obtaining, storage and outputting limitations instructions are insignificant extra-solution activity that does not produce a practical application of the abstract idea or amount to significantly more. See MPEP 2106.05(d).
Step 2B: Does the claim recite additional elements that amount to significantly more than judicial exception?
No, as discussed with respect to Step 2A, the additional limitation are instructions to apply an exception on a generic computer and a general purpose computer. See MPEP 2106.05(f). MPEP 2106.05(f) provides the following considerations for determining whether a claim simply recites a judicial exception with the words “apply it” (or an equivalent), such as mere instructions to implement an abstract idea on a computer.
Additionally, the limitations do not impose any meaningful limits on practicing the abstract idea and therefore the claim does not provide an inventive concept in Step 2B. Further, in regards to step 2B MPEP 2106.05 (d) - II. ELEMENTS THAT THE COURTS HAVE RECOGNIZED AS WELL-UNDERSTOOD, ROUTINE, CONVENTIONAL ACTIVITY IN PARTICULAR FIELDS
Because examiners should rely on what the courts have recognized, or those of ordinary skill in the art would recognize, as elements that describe well‐understood, routine activities, the following section provides examples of elements that have been recognized by the courts as well-understood, routine, conventional activity in particular fields. It should be noted, however, that many of these examples failed to satisfy other considerations (e.g., because they were recited at a high level of generality and thus were mere instructions to apply an exception, or were insignificant extra-solution activity). Thus, examiners should carefully analyze additional elements in a claim with respect to all relevant Step 2B considerations, including this consideration, before making a conclusion as to whether they amount to an inventive concept.
The courts have recognized the following computer functions as well‐understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity.
• i. Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network); but see DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245, 1258, 113 USPQ2d 1097, 1106 (Fed. Cir. 2014) ("Unlike the claims in Ultramercial, the claims at issue here specify how interactions with the Internet are manipulated to yield a desired result‐‐a result that overrides the routine and conventional sequence of events ordinarily triggered by the click of a hyperlink." (emphasis added));
• ii. Performing repetitive calculations, Flook, 437 U.S. at 594, 198 USPQ2d at 199 (recomputing or readjusting alarm limit values); Bancorp Services v. Sun Life, 687 F.3d 1266, 1278, 103 USPQ2d 1425, 1433 (Fed. Cir. 2012) ("The computer required by some of Bancorp’s claims is employed only for its most basic function, the performance of repetitive calculations, and as such does not impose meaningful limits on the scope of those claims.");
• iii. Electronic recordkeeping, Alice Corp. Pty. Ltd. v. CLS Bank Int'l, 573 U.S. 208, 225, 110 USPQ2d 1984 (2014) (creating and maintaining "shadow accounts"); Ultramercial, 772 F.3d at 716, 112 USPQ2d at 1755 (updating an activity log);
• iv. Storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93.
The additional elements have been considered both individually and as an ordered combination in the significantly more consideration. This claim is ineligible.
Claim 2 recites wherein the source code is partitioned per predefined unit, the software quality measurement circuitry measures the software quality data values for each of the predefined units, based on the source code partitioned per the predefined unit, the age calculator calculates the diagnosed age for each of the predefined units, based on the software quality data values measured for the predefined unit, which is a mental/mathematical process under Step 2A Prong One.
the data accumulation storage accumulates the diagnosed age for each of the revisions and for each of the predefined units, which is mere data output under Step 2A Prong Two and 2B.
the development trend approximate expression calculator calculates, based on the diagnosed age accumulated by the data accumulation storage for each of the revisions and for each of the predefined units, the development trend approximate expression for the predefined unit, and the lifetime estimation circuitry estimates the lifetime for each of the predefined units, based on the development trend approximate expression calculated for the predefined unit, which is a mental/mathematical process under Step 2A Prong One.
Therefore, the claim is considered ineligible under 35 USC 101.
Claim 3 recites wherein the architecture lifetime estimation apparatus outputs information based on the lifetime estimated by the lifetime estimation circuitry for each of the predefined units, which is mere data output under Step 2A Prong Two and 2B. Therefore, the claim is considered ineligible under 35 USC 101.
Claim 4 recites main unit lifetime extraction circuitry to extract the lifetime of one of the predefined units, based on an influence of the lifetime estimated by the lifetime estimation circuitry for each of the predefined units on a lifetime of the whole source code, which is a mental/mathematical process under Step 2A Prong One.
wherein the architecture lifetime estimation apparatus outputs information based on the lifetime of the one of the predefined units, which is mere data output under Step 2A Prong Two and 2B. Therefore, the claim is considered ineligible under 35 USC 101.
Claim 5 recites lifetime correcting circuitry to correct the lifetime for each of the predefined units, based on the lifetimes estimated by the lifetime estimation circuitry for the predefined unit and dependencies between the predefined units, which is a mental/mathematical process under Step 2A Prong One.
Therefore, the claim is considered ineligible under 35 USC 101.
Claim 6 recites wherein the obtaining circuitry further obtains design information indicating an architecture designed in advance for the source code, and a difference between an architecture of the source code itself and the architecture indicated by the design information is reflected on the lifetime, which is mere data entry under Step 2A Prong Two and 2B. Therefore, the claim is considered ineligible under 35 USC 101.
Claim 7 recites wherein the obtaining circuitry further obtains design information indicating an architecture designed in advance for the source code, which is mere data entry under Step 2A Prong Two and 2B.
the architecture lifetime estimation apparatus further comprises a lifetime validity calculator to calculate validity of the lifetime for each of the predefined units, based on a difference between an architecture of the source code itself and the architecture indicated by the design information, which is a mental/mathematical process under Step 2A Prong One.
the architecture lifetime estimation apparatus outputs information based on the validity, which is mere data output under Step 2A Prong Two and 2B.
Therefore, the claim is considered ineligible under 35 USC 101.
Claim 8 recites wherein the obtaining circuitry further obtains malfunction information on the source code, which is mere data entry under Step 2A Prong Two and 2B.
the malfunction information is reflected on the lifetime, which is a mental/mathematical process under Step 2A Prong One.
Therefore, the claim is considered ineligible under 35 USC 101.
Claim 9 recites wherein the obtaining circuitry further obtains development prospect information for each of the predefined units, which is mere data entry under Step 2A Prong Two and 2B.
the architecture lifetime estimation apparatus further comprises a threshold controller to control an age threshold for each of the predefined units, based on the development prospect information for the predefined unit, and the lifetime estimation circuitry estimates the lifetime for each of the predefined units, based on the development trend approximate expression and the age threshold, which is a mental/mathematical process under Step 2A Prong One.
Therefore, the claim is considered ineligible under 35 USC 101.
Claim 10 recites wherein the obtaining circuitry further obtains operation information on an operator of the source code, which is mere data entry under Step 2A Prong Two and 2B.
the architecture lifetime estimation apparatus further comprises a proficiency level calculator to calculate a proficiency level of the operator, based on the operation information and the diagnosed age accumulated by the data accumulation storage for each of the revisions, and the lifetime estimation circuitry estimates the lifetime, based on the development trend approximate expression and the proficiency level, which is a mental/mathematical process under Step 2A Prong One.
Therefore, the claim is considered ineligible under 35 USC 101.
Claim 11 recites wherein the data accumulation storage accumulates the software quality data values and metrics extracted by the software quality measurement circuitry from the source code for each of the revisions of the source code, which is mere data output under Step 2A Prong Two and 2B.
the architecture lifetime estimation apparatus further comprising lifetime cause extraction circuitry to extract the metrics and the software quality data values to be causes on whether the lifetime is good or bad, as lifetime causes, which is a mental/mathematical process under Step 2A Prong One.
Therefore, the claim is considered ineligible under 35 USC 101.
Claim 12 recites an improvement entry selector to select a part or a whole of lifetime causes that negatively influence the lifetime from among the lifetime causes, which is mere data entry under Step 2A Prong Two and 2B.
an improved lifetime simulator to estimate an improved lifetime, based on the development trend approximate expression calculated from the diagnosed age when the lifetime causes selected by the improvement entry selector have been improved, which is mere instructions to apply an exception on a generic computer under Step 2A Prong Two and 2B.
Therefore, the claim is considered ineligible under 35 USC 101.
Claims 13 is a method claim reciting limitations similar to claim 1 and is rejected under the same rationale.
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-13 are rejected under 35 U.S.C. 103 as being unpatentable over Nakao et al. (IDS Reference: US-20140365990-A1) in view of Sturtevant et al. (US-20170235569-A1)
Regarding Claim 1, Nakao teaches an architecture lifetime estimation apparatus, comprising: obtaining circuitry to obtain a source code; software quality measurement circuitry to measure software quality data values each indicating quality of the source code, based on the source code ( [0041-0042] "FIG. 2 is a view showing the software metrics table which registers revision numbers of source codes of the respective revisions stored in the repository 71, file names, the number of source code lines of the file, and complexity of the source code of the file. It is possible to use the number of call relationships, the number of classes, the number of properties, the number of function lines, the number of code clones and the like as the software metrics to be registered without limitation to the number of the source code lines of the respective files and the complexity. It is also possible to calculate the statistic values such as the number of source codes lines for each file with respect to those of the software under development as a whole so that the calculated value is used as the software metrics. FIG. 3 is a view showing the process metrics table which registers revision numbers, file names, development language of file, the number of file development personnel, and skill level of the file development personnel. Besides the development language, the number and skill level of development personnel, is possible to use the number of development sites, and name and version of OS." And [0003])
an age calculator to calculate complexity of the source code in a software structure as a diagnosed age of the source code, based on the software quality data values ( [0041] "FIG. 2 is a view showing the software metrics table which registers revision numbers of source codes of the respective revisions stored in the repository 71, file names, the number of source code lines of the file, and complexity of the source code of the file. It is possible to use the number of call relationships, the number of classes, the number of properties, the number of function lines, the number of code clones and the like as the software metrics to be registered without limitation to the number of the source code lines of the respective files and the complexity. It is also possible to calculate the statistic values such as the number of source codes lines for each file with respect to those of the software under development as a whole so that the calculated value is used as the software metrics." [0044] "The evaluation process execution section 2 includes a metrics registration section 201, a fluctuation pattern calculation section 202, a similarity calculation section 203, an evaluation prediction section 204, and a result output section 205. The evaluation process execution unit 2 controls the metrics registration section 201, the fluctuation pattern calculation section 202, the similarity calculation section 203, the evaluation prediction section 204," [0050-0051] "The evaluation prediction section 204 generates the evaluation prediction model 303 for calculating the evaluation prediction value of the revision as the evaluation prediction target, and records the generated evaluation prediction model 303 in the recording section 3. The evaluation prediction section 204 calculates the evaluation prediction value of the revision as the evaluation prediction target using the evaluation prediction model 303 recorded in the recording section 3. The result output section 205 outputs the result to the I/O unit 4. FIG. 5 is a view showing an example of a display screen displaying output of the result output section 205 to the I/O unit 4. The display screen includes an evaluation value transition display section 40A, a prediction analysis summary display section 40B, and a prediction result display section 40C. The evaluation value transition display section 40A displays transition of the evaluation value of the evaluation item to be predicted with time. The prediction analysis summary display section 40B displays the summary including setting of the evaluation prediction. The prediction result display section 40C displays the evaluation prediction model 303 generated by the evaluation prediction section 204, and the evaluation prediction value calculated using the evaluation prediction model 303. The display screen illustrated in FIG. 5 only shows an example, which may be configured to display only a part of the display as described above." Also see Fig. 2 for sample metrics, and Fig 4. for the corresponding evaluation value. EN: Evaluation value is being mapped to the diagnosed age. The instant specification describes the diagnosed age as a single software metric evaluation value calculated via a weighted formula Eq(5) that reflects software complexity/quality metrics, such as lines of code, number of functions etc. See [0055-0059] of the instant application's specification)
a data accumulation storage to accumulate the diagnosed age for each of revisions of the source code ( [0040] "The management server 5 includes a configuration management system 7 which manages source codes of the software under development, a development information database 81 which stores software development information, and an evaluation database 91 which stores software evaluation results. The configuration management system 7 includes a repository 71 as OSS (Open Source Software) called Subversion, for example. The development information database 81 includes a software metrics table that stores software metrics, and a process metrics table that stores process metrics. The evaluation database 91 includes a performance evaluation table.")
a development trend approximate expression calculator to calculate, based on the diagnosed age accumulated by the data accumulation storage for each of the revisions, a development trend approximate expression indicating a relationship between the revision and the diagnosed age ([0069-0071] "The evaluation prediction section 204 selects the revision which satisfies the similarity judgment criterion as the one used for generating the evaluation prediction model 303 (S1003). The evaluation prediction section 204 acquires the software metrics and the process metrics of the revision selected in S1003 from the development information database 81 (S1004). The evaluation prediction section 204 acquires the value of the prediction evaluation item Q (evaluation value) of the revision selected in S1003 from the evaluation database 91 (S1005). The values (evaluation values) of the prediction evaluation items Q of the revisions prior to the revision P as the evaluation prediction target are stored in the evaluation database 91 upon action of the evaluation prediction section 204 on the subject revision as the evaluation prediction target. The evaluation prediction section 204 generates the evaluation prediction model 303 using the metrics acquired in S1004 and the evaluation value acquired in S1005 (S1006). The evaluation prediction model 303 is generated using the metrics acquired in S1004 as the explanatory variable, and regression analysis by taking the evaluation value acquired in S1005 as the objective variable. The evaluation prediction section 204 acquires the software metrics and the process metrics of the revision P as the evaluation target from the development information database 81 (S1007). The evaluation prediction section 204 calculates the prediction value of the evaluation item Q of the revision P by substituting the metrics acquired in S1007 for the evaluation prediction model 303 generated in S1006 (S1008), and stores the calculated prediction value (evaluation value) of the evaluation item Q of the revision P in the evaluation database 91. The process then ends. If the value is smaller than the preliminarily designated evaluation prediction value, the notice is output (not shown) to the I/O unit 4." [0051] " The display screen includes an evaluation value transition display section 40A, a prediction analysis summary display section 40B, and a prediction result display section 40C. The evaluation value transition display section 40A displays transition of the evaluation value of the evaluation item to be predicted with time. The prediction analysis summary display section 40B displays the summary including setting of the evaluation prediction. The prediction result display section 40C displays the evaluation prediction model 303 generated by the evaluation prediction section 204, and the evaluation prediction value calculated using the evaluation prediction model 303. The display screen illustrated in FIG. 5 only shows an example, which may be configured to display only a part of the display as described above." EN: The evaluation prediction model 303 is based on past revisions along with various other metrics.)
wherein the architecture lifetime estimation apparatus outputs information based on the lifetime ( [0050] "The evaluation prediction section 204 generates the evaluation prediction model 303 for calculating the evaluation prediction value of the revision as the evaluation prediction target, and records the generated evaluation prediction model 303 in the recording section 3. The evaluation prediction section 204 calculates the evaluation prediction value of the revision as the evaluation prediction target using the evaluation prediction model 303 recorded in the recording section 3. The result output section 205 outputs the result to the I/O unit 4." See Fig. 5 for sample output)
However, Nakao is not relied on for
lifetime estimation circuitry to estimate a lifetime on the revision of the source code, based on the development trend approximate expression
Sturtevant teaches lifetime estimation circuitry to estimate a lifetime on the revision of the source code, based on the development trend approximate expression ([0178] "Where expert knowledge is required, tools give users the ability to set and test different parameters of interest for use in higher-level SE metric computation. Examples of modifiable parameters that might be set by a user include: (1) Amount of code modified annually (% code turnover) is useful when only code is available for automated analysis by the tool, and data from version control is unavailable. This can be used to estimate the amount of labor going on in a codebase when used in combination with productivity estimates. (2) Current knowledge or future expectations about the number of developers that will be working in a codebase. This can be used to estimate the amount of code change when used in combination with productivity estimates. (3) The number of years and amount of development labor that will be expended before system decommissioning. This can be useful when reasoning about whether a CQ, DQ, or TQ improvement initiative will pay off. (4) The downstream cost of bugs that escape the development and QA process and are deployed (higher in nuclear plant control code than a cell-phone app.) (5) Developer salary. (6) The discount rate used in ‘present value’ financial calculations estimating ROI." EN [0177] shows the system calculating estimates for the values the user can modify in [0178] including (3) the lifetime estimate. Also see [0218] )
Nakao and Sturtevant are analogous art because they are from the same field of endeavor in technical debt evaluation. Before the effective filing date of the invention, it would have been obvious to a person of ordinary skill in the art, to combine Nakao and Sturtevant to incorporate Sturtevant’s lifetime estimation and evaluation into Nakao’s software quality evaluation framework with expected results. “Various embodiments disclosed herein relate to an interrelated set of tools, technologies, and processes that can be used, e.g., by leaders in a software development organization or in an organization that contracts for software development to manage in a better-informed and more financially rational way. These tools help them better assess individual software systems/projects and portfolios of those systems/projects. The tools can also be used by those responsible for independent verification and validation (IV&V) and those doing “due diligence” during the acquisition of a software system or development organization to assess future software economics, operational performance, and financial performance.” (Sturtevant, [0046])
Regarding Claim 2, Nakao in view of Sturtevant teaches the architecture lifetime estimation apparatus according to claim 1. Nakao teaches wherein the source code is partitioned per predefined unit, the software quality measurement circuitry measures the software quality data values for each of the predefined units, based on the source code partitioned per the predefined unit, the age calculator calculates the diagnosed age for each of the predefined units, based on the software quality data values measured for the predefined unit, the data accumulation storage accumulates the diagnosed age for each of the revisions and for each of the predefined units, the development trend approximate expression calculator calculates, based on the diagnosed age accumulated by the data accumulation storage for each of the revisions and for each of the predefined units, the development trend approximate expression for the predefined unit, ([0041] "FIG. 2 is a view showing the software metrics table which registers revision numbers of source codes of the respective revisions stored in the repository 71, file names, the number of source code lines of the file, and complexity of the source code of the file. It is possible to use the number of call relationships, the number of classes, the number of properties, the number of function lines, the number of code clones and the like as the software metrics to be registered without limitation to the number of the source code lines of the respective files and the complexity. It is also possible to calculate the statistic values such as the number of source codes lines for each file with respect to those of the software under development as a whole so that the calculated value is used as the software metrics." and [0048] "A formula (1) expresses an example of the fluctuation pattern 301 from the revision C to the revision D as shown in FIGS. 2 and 3, which will be called the fluctuation pattern 301 of the revision D. For example, referring to the software metrics table shown in FIG. 2, the number of source code lines of the file 1 is increased from 350 of the revision C to 370 of the revision D by 20. Then complexity of the file 1 is decreased from 17 of the revision C to 15 of the revision D by 2. In the example expressed by the formula (1), the fluctuation amount is expressed by the numerical value so that the development language that is not expressed by the numerical value is not contained in the item of the fluctuation pattern 301. The fluctuation pattern 301 may be expressed by presence or absence of the change besides the fluctuation amount expressed by the numerical value. A formula (2) shows an example of the fluctuation pattern 301 for expressing presence or absence of the change. In the presence of fluctuation, the value is set to “1”, and in the absence of fluctuation, it is set to “0” so as to express the fluctuation pattern 301 from the revision C to the revision D likewise the formula (1)." EN: The instant specification defines the predefined unit as per [0076] "In Embodiment 1, a lifetime of the whole software, that is, a lifetime of the whole source code is estimated. In contrast, the source code is partitioned per predefined unit and a lifetime is estimated for each of the partitions in Embodiment 2. The predefined unit will be described as a functional unit of software in the following description. The predefined unit is not limited to this but may be, for example, a unit whose revision is necessary.")
Sturtevant teaches the lifetime estimation circuitry estimates the lifetime for each of the predefined units, based on the development trend approximate expression calculated for the predefined unit ([0186-0187] "The weighting process can take a number of different forms depending on what information is available, as specified by user input. If a change-based weighting factor is desired, e.g., and the system has linked version control data showing the precise amount of activity on a file-by-file basis, the option exists for each file to be weighted according to activity over a specified period of time. If no such data is available, the rate of change can be estimated by applying a flat global activity rate equally to each file, or by the predicted degree of development activity in different sections of the codebase as specified by the user. The aggregation process, if needed, can occur at the level of the directory, module, system, collection of systems, or any other desired segmentation, depending on the user's specifications. The files are grouped together to calculate weighted averages for each input metric for that group, which in turn are fed as single inputs into the stage-specific calculations, resulting in output metrics specific to that group. If the aggregation step is eschewed, then the weighted metrics can be fed into the stage-specific calculations on a file-by-file basis, producing output metrics for each file independently.")
Regarding Claim 3, Nakao in view of Sturtevant teaches the architecture lifetime estimation apparatus according to claim 2. Sturtevant teaches wherein the architecture lifetime estimation apparatus outputs information based on the lifetime estimated by the lifetime estimation circuitry for each of the predefined units ([0187] also [0183])
Regarding Claim 4, Nakao in view of Sturtevant teaches the architecture lifetime estimation apparatus according to claim 2. Sturtevant teaches further comprising main unit lifetime extraction circuitry to extract the lifetime of one of the predefined units, based on an influence of the lifetime estimated by the lifetime estimation circuitry for each of the predefined units on a lifetime of the whole source code ([0184-0185] "Before each calculation step, some details are determined about the relationships between the metrics of individual files: namely, each file is weighted relative to others in the system. The weighting factor can be dependent on different file-level parameters, such as LOC, LOC changed over a given time period (extractable from version control data), LOC changed over time to fix bugs or develop features, and so on. If metrics are being calculated across multiple files, the level of aggregation is also specified: sets of files within the same directory, module, or entire system may be grouped together for analysis purposes, or even files across multiple systems. FIG. 19 shows the exemplary weighting and aggregation steps in the context of business outcome calculations. File-level metrics are weighted and aggregated according to user specifications, then fed into the calculations that are specific to the desired set of new metrics, along with any particular parameters (user-defined, Zoo-derived, etc.) that are specifically needed for those calculations." Also [0186-0187])
wherein the architecture lifetime estimation apparatus outputs information based on the lifetime of the one of the predefined units ([0187])
Regarding Claim 5, Nakao in view of Sturtevant teaches the architecture lifetime estimation apparatus according to claim 2. Sturtevant teaches further comprising lifetime correcting circuitry to correct the lifetime for each of the predefined units, based on the lifetimes estimated by the lifetime estimation circuitry for the predefined unit and dependencies between the predefined units ([0161-0163] "Independent system variables include such values as system size, language, age, and system complexity metrics such as core size and propagation cost. These metrics represent measurable attributes of a system that provide details about its context and meaningfully impact dependent system variables. Dependent system variables include such values as engineer productivity in lines of code, file defectfulness, and likelihood of critical defects occurrence in certain areas of a codebase. These metrics represent derived attributes of a system which provide details about its performance, business outcomes, and software economics. In general, these variables are considered to provide meaningful insight. Given a set of independent variables and corresponding dependent variables from multiple systems it is possible to apply mathematical regression (linear, binomial, etc.) to create fitted predictive curves from which missing data may be projected. " Also see Nakao [0091])
Regarding Claim 6, Nakao in view of Sturtevant teaches the architecture lifetime estimation apparatus according to claim 2. Nakao teaches wherein the obtaining circuitry further obtains design information indicating an architecture designed in advance for the source code ( [0090] "The management server 5 includes the model repository 72 which manages the design model of the software under development, the development information database 82 which stores the software development information, and the evaluation database 92 which stores the software evaluation value. The model repository 72 is capable of storing information of the model designed using UML (Unified Modeling Language) and MATLAB (MATrix LABoratory) in XMI (XML Metadata Interchange) form or unique text form. The model repository 72 according to this embodiment does not use the configuration management system. However, the configuration management system capable of storing the model information may be used. The development information database 82 includes the software metrics table which contains the software metrics. The evaluation database 92 includes the quality evaluation table. The table included in the development information database 82 may be configured to contain the process metrics table similar to that of the first or the second embodiment besides the software metrics table. The evaluation database 92 may be configured to contain the performance evaluation table instead of the quality evaluation table, or contain both the quality evaluation table and the performance evaluation table." also [0109])
Sturtevant teaches a difference between an architecture of the source code itself and the architecture indicated by the design information is reflected on the lifetime ([0086] "(1) Static code analysis can be used to analyze code to collect metrics, identify problems, identify violations of coding standards, and extract dependency information for use in network graphs, dependency structure matrix analysis, and other architectural analysis." EN: instant application specification [0103] eq(7) identifies the difference as a violation of dependencies)
Regarding Claim 7, Nakao in view of Sturtevant teaches the architecture lifetime estimation apparatus according to claim 2. Nakao teaches wherein the obtaining circuitry further obtains design information indicating an architecture designed in advance for the source code, ( [0089, 0090, and 0109])
Sturtevant teaches the architecture lifetime estimation apparatus further comprises a lifetime validity calculator to calculate validity of the lifetime for each of the predefined units, based on a difference between an architecture of the source code itself and the architecture indicated by the design information, ([0171] "If a project includes process metrics it is possible to perform a verification of the model's accuracy by deriving the same results by multiple means—ensuring results are within an acceptable margin. For example, if the project includes both version control data (from which file-specific activity levels can be computed) and human resource data (including number of active developers and experience levels), but not issue tracking data, it is possible to estimate productivity levels in the codebase through at least two different methods. The estimated results may be compared with each other to verify both calculations. If the model has been set up correctly, there should be no significant difference between results of the different methods." EN: as illustrated in [0090] the architecture deviation is included in the metrics, which are further used to validate/verify the estimation/calculation model)
the architecture lifetime estimation apparatus outputs information based on the validity ([0255] Also see Nakao [0050])
Regarding Claim 8, Nakao in view of Sturtevant teaches the architecture lifetime estimation apparatus according to claim 1. Sturtevant teaches wherein the obtaining circuitry further obtains malfunction information on the source code, ([0093] "In some instances, project management data that may also be available for capture and analysis. This includes data from version control, issue tracking, and human resource tracking systems, which serve to improve the tool's understanding of various features of developer activity, defects, code change over time, and other elements of the development process. If information about patches (or changes) from a version control system is added to the data store, one can extract information about which lines of code were changed in each file by which developer on what date." [0103] "The type and quality of data available, as well as its intended use, will determine what is captured and linked in a data store. Below are examples of some of the different types of data that may be available and captured for a given system:" and [0109] "(6) Continuous integration+testing info: Information about build failures, compiler warnings, unit+system test failures, and test coverage can be captured." also see [0180-0181])
the malfunction information is reflected on the lifetime ([0180-0181] "Higher level SE metrics computed from low-level ‘fitted model’ SE projections, other metrics, and user input can include: (1) Delta features: LOC expected to be modified over the time period to implement features in the system. (2) Delta bugs: LOC expected to be modified over the time period to fix bugs in the system. Files with greater complexity generally require more defect correction than those with lower complexity. (3) Bug LOC released: LOC expected to be modified over the time period to fix bugs that were released to end users, with the potential to have an adverse impact downstream. Files with greater complexity have more bugs with downstream impact than those with lower complexity. Based on these parameters, along with the others discussed earlier in this section, at least three cost subtotals can be calculated, though others are conceivable (e.g. a more specific subtotal dealing with security risk): (1) Bugfixing and feature development costs: Expected development effort (in the cost of full-time equivalents (FTEs), defined as the amount of work done by one full-time employee over the time period) allocated to fix bugs or develop features in the codebase, based partly on the relevant productivity metrics. Productivity is higher when developers work in code with lower architectural complexity and when they are implementing features, and lower when they are fixing bugs. This figure can also be considered the cost of continuing development. (2) Downstream risk of released bugs: Expected cost over some time-period resulting from bugs in the deployed system, based partly on the “delta bugs” number from above. Downstream impact (the total downstream risk and cost of released defects relating to, e.g., security, safety, recall, user productivity, waste, or reputation) is higher in code with higher complexity. (3) Staff turnover costs: Expected cost over the time period resulting from staff turnover and the ensuing productivity decreases, human capital loss, and knowledge loss. Using developer experience data, productivity metrics, and known features of the nature of the developer learning curve, it is possible to trace the effects of quality issues on attrition rates, productivity rates, and their associated costs.")
Regarding Claim 9, Nakao in view of Sturtevant teaches the architecture lifetime estimation apparatus according to claim 2. Sturtevant teaches wherein the obtaining circuitry further obtains development prospect information for each of the predefined units ([0248-0249] "In the event that no refactoring has yet occurred in a codebase, technical debt calculations from the most recent snapshot can be compared with a hypothesized snapshot at a future point in time to determine the expected IRR of a hypothetical refactoring effort. The mechanism for projecting this future snapshot entails using Zoo data to estimate the degree to which, given a certain user-defined input of time and resources, a particular improvement in code and design quality will result, using methods such as shifting files between different sectors in order to strengthen quality metrics. Obtaining an accurate estimation of the hypothetical refactoring effort's success rate is dependent on several user-supplied factors about the purpose and high-level situation of the system. For example, if the codebase is growing rapidly, refactoring will be more difficult, as new features (and bugs) are constantly being produced; if the codebase is in “maintenance mode,” on the other hand, it can be anticipated that refactoring efforts will be more effective due to the low degree of interference from new code. Alternatively, to simplify the initial calculations, it may be desirable to assume that normal feature development and other change in the codebase is minimized during the refactoring period: total lines of code remain the same, and efforts focus on maximizing the refactoring success rate." also [0177-0178])
the architecture lifetime estimation apparatus further comprises a threshold controller to control an age threshold for each of the predefined units, based on the development prospect information for the predefined unit ( [0178] allows the user to set an age threshold for decommissioning of the development project)
the lifetime estimation circuitry estimates the lifetime for each of the predefined units, based on the development trend approximate expression and the age threshold ([0186-0187] also [0248])
Regarding Claim 10, Nakao in view of Sturtevant teaches the architecture lifetime estimation apparatus according to claim 1. Nakao teaches wherein the obtaining circuitry further obtains operation information on an operator of the source code ([0042] "FIG. 3 is a view showing the process metrics table which registers revision numbers, file names, development language of file, the number of file development personnel, and skill level of the file development personnel. Besides the development language, the number and skill level of development personnel, is possible to use the number of development sites, and name and version of OS.")
Sturtevant teaches the architecture lifetime estimation apparatus further comprises a proficiency level calculator to calculate a proficiency level of the operator, based on the operation information and the diagnosed age accumulated by the data accumulation storage for each of the revisions ([0111-0112] "(8) Human resources metadata: Developer information including work-hours, salary (and other employee expenses), level of experience, and identifiers allowing individuals to be linked to version control and issue tracking data. (9) Outcome data: Historical data regarding development cost, how much development labor was applied, how much time was spent fixing bugs, whether the project failed, etc." [0154-0155] "Once statistical tests (such as those discussed above) have been run, the resulting ‘custom fitted models’ can be used to ‘predict’ or ‘simulate’ values of interest. Tools for doing so include the Zelig package in R or the statsmodels package in Python. By holding control variables constant, and varying input along independent variables of interest, we can capture information about the impact that an explanatory variable of interest (such as CQ, DQ, or TQ metrics) has on an independent variable such as ‘lines of code modified to fix bugs’, ‘developer productivity’, ‘probability of attrition’, ‘probability that a bug is not caught during development’, ‘probability that a file contains a security vulnerability’, etc. Using simulation or predictive techniques, one can make inferences and predict expected value and variance for some SE outcome datapoint given knowledge about characteristics of the independent variables. For example, given the statistical tests similar to those shown here, and knowledge of mean values for control variables, it should be clear to a statistician how to derive expected values for the following 4 business outcome parameters as a function of complexity scores (for files) or % effort in complex files (for developers): (1) ‘defect ratio’—the ratio of lines modified to fix bugs over lines modified to implement features in each file. More complex files have a higher defect ratio. (2) ‘fallout ratio’-similar to defect ratio, but only including bugs that escape the development process in the numerator. (i.e. they have a potential impact on customers.) (3) ‘feature productivity’—the productivity of developers (in terms of LOC produced or features delivered) per unit time when they are implementing features. (4) ‘bug fix productivity’—the productivity of developers (in terms of LOC produced or features delivered) per unit time when they are implementing features." also [0181])
the lifetime estimation circuitry estimates the lifetime, based on the development trend approximate expression and the proficiency level ( [0178])
Regarding Claim 11, Nakao in view of Sturtevant teaches the architecture lifetime estimation apparatus according to claim 1. Nakao teaches wherein the data accumulation storage accumulates the software quality data values and metrics extracted by the software quality measurement circuitry from the source code for each of the revisions of the source code ([0040-0041])
Sturtevant teaches the architecture lifetime estimation apparatus further comprising lifetime cause extraction circuitry to extract the metrics and the software quality data values to be causes on whether the lifetime is good or bad, as lifetime causes ( [0148] "To create ‘custom fitted models’ for a system, regressions are set up according to certain hypotheses about the nature of the relationship between CQ, DQ, TQ, and low-SE outcomes. To illustrate, we include statistical tables from previously conducted studies." and [0203] "FIG. 29 shows detailed analysis related to waste during the development process. Less than optimal quality (CQ, DQ, or TQ) will lead to lost productivity, extra bugs, more downstream cost, and other sources of cost and schedule slippage. This GUI allows a software leader to compare the software economics of their system against one considered ‘optimal’. (An ‘optimal’ system is one in the top 10% of Zoo benchmarks in this case.) This picture shows the amount of time required to develop and ship a 1000 LOC feature in the codebase being examined (22 days of developer time) vs the ‘optimal’ system (13 days).")
Regarding Claim 12, Nakao in view of Sturtevant teaches the architecture lifetime estimation apparatus according to claim 11. Sturtevant teaches further comprising: an improvement entry selector to select a part or a whole of lifetime causes that negatively influence the lifetime from among the lifetime causes ([0248])
an improved lifetime simulator to estimate an improved lifetime, based on the development trend approximate expression calculated from the diagnosed age when the lifetime causes selected by the improvement entry selector have been improved ([0216] "A hypothetical software initiative may consist of exploring the financial impact of investing time and money in improving CQ, DQ, or TQ by improving certain metrics in a code base. A tool may be written to determine the estimated value of such initiatives by projecting outcomes from a ‘custom’ or ‘standard’ fitted model given hypothetical improvements to certain independent variables." Also see [0217-0219] and [0244] "Another important component of the actual vs. actual calculations is the set of parameters related to Sturtevantctoring, either derived from user-modified dashboard inputs or from calculations of the differences between the two snapshots. All systems can use basic financial parameters from the dashboard, and will be able to calculate real Sturtevantctoring-based changes purely in codebase-extracted code metrics, i.e. Sturtevantctoring success rates. Using architectural quality and file complexity metrics as examples, these success parameters might include the proportion of files shifted from high-centrality to low-centrality areas of the code, or the proportion of files shifted from high complexity to low complexity, and so on. (Other success metrics are conceivable, based on different quality metrics.)")
Claim 13 is a method claim reciting limitations similar to claims 1 and is rejected under the same rationale.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Goern (US-20210149666-A1): discloses analyzing the impact of changes to source code.
Dhelaria et al. (US-20180196740-A1): discloses calculating software complexity metrics including analysis of temporal changes to code and determining runtime risk probabilities.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMIR DARWISH whose telephone number is (571)272-4779. The examiner can normally be reached 7:30-5:30 M-Thurs.
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, Lewis Bullock can be reached on 571-272-3759. 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.
/A.E.D./Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199
Prosecution Insights