DETAILED ACTION
The Office Action is in response to Amendments filed 01/02/2026.
Claim 2 is cancelled.
Claims 1, 3, 14, and 18 are currently amended.
Claims 1 and 3-20 are currently pending.
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 .
Specification
The disclosure is objected to because of the following informalities:
Specification Paragraph [0047] contains a typo. The disclosure recites “the process ca be discussed below” and should be amended as follows: “the process can be discussed below”
Appropriate correction is required.
Claim Objections
Claims 1, 11-12, 14, 17- 20 are objected to because of the following informalities:
Claims 1, 14, and 18 are objected to for a minor deficiency. The claim contains an inconsistency of claim terminology. The claim currently discloses (e.g. Claim 1 Line 11), “highlight any changes between said original code and said modified code”. For the purposes of consistency Applicant is recommended to amend as follows: “highlight any changes between said original code and said modified changed code”
Claim 10 is objected to for a minor deficiency. The claim contains an inconsistency of claim terminology. The claim currently discloses “analysis of differences between original and modified changed code”. For the purposes of consistency and compact prosecution, Applicant is recommended to amend as follows: “analysis of the differences between the original code and the modified changed code”
Claim 11 contains a minor typo. The claim recites “modified changed code portion”. Applicant is recommended to amend as follows “a modified changed code portion”
Claims 12, 17, and 20 are objected to for a minor deficiency. The claim contains an inconsistency of claim terminology and a minor grammatical typo. The claim currently discloses “to point where said original and said modified code diverge”. Applicant is recommended to amend as follows: “to a point where said original code and said modified changed code diverge”
Claim 19 is objected to because it is not listed with the set of original claims. For compact prosecution, Examiner will maintain the rejection of claim 19 as disclosed below.
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.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1 and 3-20 rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 1, 14, and 18 recite the limitation “monitoring events” in lines 13, 17-18, and 15-16 respectively. It is unclear if “events” refers to the aforementioned “events” in lines 12, 16, and 14 respectively, or to something else entirely. Therefore, the claim is rendered vague and indefinite.
Claims 1, 14, and 18 recite the limitation “variable value changes” in lines 14, 18, and 16 respectively. It is unclear if “variable value changes” refers to the aforementioned “variable value change” in lines 12, 16-17, and 14-15 respectively, or to something else entirely. Therefore, the claim is rendered vague and indefinite.
Claims 15, 16, and 19 recite the limitation “is obtained by monitoring events associated with said software program including variable value changes”. It is unclear if “events” and “variable value changes” refer to the aforementioned “events” or “variable value changes” in claims 14, and 18 respectively or to something else entirely. Therefore, the claim is rendered vague and indefinite.
Claims 3-13, 17, and 20 are rejected in light of their chain of dependency upon claims 1, 14, and 18 respectively.
Appropriate correction is required.
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, 3-8, and 10-20 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.
Claims 1, 14, and 18 as drafted recite a process, under its broadest reasonable interpretation, that covers steps which could reasonably be performed in the human mind with the aid of pen and paper, but for the recitation of generic computer/computing components. Claims 1, 14, and 18 recite the limitations:
classifying said modification requested based on a type of change;
identifying a plurality of unit tests available and selecting and customizing at least one of said unit tests based on classification of said type of code change requested;
using said at least one selected and customized unit test to determine differences between said original code and said a modified changed code;
generating one or more test execution stories to highlight any changes between said original code and said modified code, and wherein the information about code modification is obtained by monitoring events associated with said software program including variable value change and said information about said code modification to be made is obtained by monitoring events associated with said software program including variable value changes;
analyzing said test execution stories and reviewing previous code changes stored in a database to provide additional missing information from said test execution stories; and
generating instructions to highlight software changes by providing missing information from said test execution stories.
Which can be done by a human mind carrying out these functions through, observation, evaluation, judgement, and/or opinion with the aid of pen and paper. Thus, these limitations fall under the “Mental Processes” group of abstract ideas.
The judicial exception is not integrated into a practical application. Claim 14 recites the additional elements:
one or more processors, one or more computer-readable memories, one or more computer-readable tangible storage medium, and program instructions stored on at least one of the one or more tangible storage medium for execution by at least one of the one or more processors via at least one of the one or more memories, wherein the computer system is capable of performing a method
Claim 18 recites the additional elements:
A computer program product for data processing, comprising: one or more computer-readable storage medium and program instructions stored on at least one or more tangible storage medium, the program instructions executable by a processor
The additional elements are recited at a high level of generality such that it amounts to no more than a mere generic computer/computing component to apply the abstract idea (See MPEP 2106.05(f)). Furthermore, the claims recite the additional element “obtaining information about a requested modification to an original code of a software program;” which is a process, under its broadest reasonable interpretation, that is directed to the insignificant extra solution activity of mere data transmission (See MPEP 2106.05(g)). Accordingly, the additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits upon practicing the abstract idea.
The claims recite additional elements that do not amount to significantly more than the abstract idea. Claim 14 recites the additional elements:
one or more processors, one or more computer-readable memories, one or more computer-readable tangible storage medium, and program instructions stored on at least one of the one or more tangible storage medium for execution by at least one of the one or more processors via at least one of the one or more memories, wherein the computer system is capable of performing a method
Claim 18 recites the additional elements:
A computer program product for data processing, comprising: one or more computer-readable storage medium and program instructions stored on at least one or more tangible storage medium, the program instructions executable by a processor
The additional elements are recited at a high level of generality such that it amounts to no more than a mere generic computer/computing component to apply the abstract idea (See MPEP 2106.05(f)). Furthermore, the claims recite the additional element “obtaining information about a requested modification to an original code of a software program;” which has been determined to be a well-known, routine, and/or conventional activity of receiving or transmitting data over a network (See MPEP 2106.05(d)(II)). Accordingly, the additional elements recited in the claims cannot provide an inventive concept nor amount to significantly more. Thus, the claims are not patent eligible.
Claim 3 recites the limitations "wherein said code change has not been made but is scheduled to be made" which are processes that can be practically performed by the human mind through observation, evaluation, judgement, and/or opinion with the aid of pen and paper. Thus, the limitations fall under the “Mental Processes” group of abstract ideas. The claim is not patent eligible.
Claim 4 recites the limitation "wherein a code change type includes one of a group including: addition of a new feature, support for a new type of input file, an optimization feature to improve speed of execution, or a patch to provide a code fix to a problem" which is a process that can be practically performed by the human mind through observation, evaluation, judgement, and/or opinion with the aid of pen and paper. Thus, the limitation falls under the "Mental Processes" group of abstract ideas. The claim is not patent eligible.
Claim 5 recites the limitation "wherein detecting and classifying said type of change is performed through detecting NLP of commit messages generated" which is a process that can be practically performed by the human mind through observation, evaluation, judgement, and/or opinion with the aid of pen and paper. Thus, the limitation falls under the "Mental Processes" group of abstract ideas. The claim is not patent eligible.
Claim 6 recites the limitation "wherein detecting and classifying said type of change is performed through detecting AST and ontology search" which is a process that can be practically performed by the human mind through observation, evaluation, judgement, and/or opinion with the aid of pen and paper. Thus, the limitation falls under the "Mental Processes" group of abstract ideas. The claim is not patent eligible.
Claim 7 recites the limitation "wherein detecting and classifying said type of change is performed by identifying similarly labelled code" which is a process that can be practically performed by the human mind through observation, evaluation, judgement, and/or opinion with the aid of pen and paper. Thus, the limitation falls under the "Mental Processes" group of abstract ideas. The claim is not patent eligible.
Claim 8 recites the limitation "wherein said unit test selection and customization is performed by identifying existing unit tests affected by said modification" which is a process that can be practically performed by the human mind through observation, evaluation, judgement, and/or opinion with the aid of pen and paper. Thus, the limitation falls under the "Mental Processes" group of abstract ideas. The claim is not patent eligible.
Claim 10 recites the limitation "wherein analysis of differences between original and modified changed code is done through using tracing and monitoring, including log collection" which is a process that can be practically performed by the human mind through observation, evaluation, judgement, and/or opinion with the aid of pen and paper. Thus, the limitation falls under the "Mental Processes" group of abstract ideas. The claim is not patent eligible.
Claim 11 recites the limitation "wherein a test execution story instruction is generated by associating subtitles and labels to at least one block of modified changed code portion" which is a process that can be practically performed by the human mind through observation, evaluation, judgement, and/or opinion with the aid of pen and paper. Thus, the limitation falls under the "Mental Processes" group of abstract ideas. The claim is not patent eligible.
Claim 12 recites the limitation "generating a test execution story media file, wherein said test execution story media provides content to summarize steps up to point where said original and said modified code diverge" which is a process that can be practically performed by the human mind through observation, evaluation, judgement, and/or opinion with the aid of pen and paper. Thus, the limitation falls under the "Mental Processes" group of abstract ideas.
Claim 13 recites the additional element "attaching said test execution story media file to a code modification change versioning as supplemental material" which is a process, under its broadest reasonable interpretation, that is directed to the insignificant extra solution activity of data storage/output (See MPEP 2106.05(g)). Accordingly, the additional elements cannot integrate into a practical application because it does not impose any meaningful limits upon practicing the abstract idea.
The additional elements do not amount to significantly more than the abstract idea. The claim recites the additional element "attaching said test execution story media file to a code modification change versioning as supplemental material" which has been determined to be a well-known, routine, and/or conventional activity of data storage/output (See MPEP 2106.05(d)(II)). Accordingly, the additional elements recited in the claims cannot provide an inventive concept nor amount to significantly more. The claim is not patent eligible.
Claims 15, and 19 recite the limitation "wherein the information about code modification is obtained by monitoring events associated with said software program including variable value changes" which is a process that can be practically performed by the human mind through observation, evaluation, judgement, and/or opinion with the aid of pen and paper. Thus, the limitation falls under the "Mental Processes" group of abstract ideas. The claim is not patent eligible.
Claim 16 recites the limitations "wherein said code change has not been made but is scheduled to be made and said information about said code modification to be made is obtained by monitoring events associated with said software program including variable value changes" which are processes that can be practically performed by the human mind through observation, evaluation, judgement, and/or opinion with the aid of pen and paper. Thus, the limitations fall under the "Mental Processes" group of abstract ideas. The claim is not patent eligible.
Claims 17 and 20 as drafted recite a process, under its broadest reasonable interpretation, that can be reasonably performed by the human mind with the aid of pen and paper but for the recitation of generic computer/computing components. The claims recite the limitation "generating a test execution story media file, wherein said test execution story media provides content to summarize steps up to point where said original and said modified code diverge" which is a process that can be practically performed by the human mind through observation, evaluation, judgement, and/or opinion with the aid of pen and paper. Thus, the limitation falls under the "Mental Processes" group of abstract ideas.
The judicial exception is not integrated into a practical application. The claims recite the additional element "attaching said test execution story media file to a code modification change versioning as supplemental material" which is a process, under its broadest reasonable interpretation, that is directed to the insignificant extra solution activity of data storage/output (See MPEP 2106.05(g)). Accordingly, the additional elements cannot integrate into a practical application because it does not impose any meaningful limits upon practicing the abstract idea.
The additional element does not amount to significantly more than the abstract idea. The claims recite the additional element "attaching said test execution story media file to a code modification change versioning as supplemental material" which has been determined to be a well-known, routine, and/or conventional activity of data storage/output (See MPEP 2106.05(d)(II)). Accordingly, the additional elements recited in the claims cannot provide an inventive concept nor amount to significantly more. Thus, the claims are not patent eligible.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 14-15, and 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over US 20140040867 A1 hereinafter “Wefers” in view of US 10635566 B1 hereinafter “Talluri” and further in view of US 11301357 B1 hereinafter “Gacek”.
With regards to claim 1, Wefers teaches:
A method for generating instructions to highlight software changes, comprising: (Wefers [0029], "The data the test plan generator 210 operates upon includes system impact data 202 that identifies components of a software system impacted by a system update or other modification [A method for generating instructions to highlight software changes]. The system impact data 202 may identify system components at different granularities, such as business processes, objects, object code branches, database tables or fields, user interfaces, content, communication interfaces, and the like. In summary, the system impact data 202 represents what has been changed in the software system in a form that is relevant to the logic and other data within the test plan generator 210.")
obtaining information about a requested modification to an original code of a software program; (Wefers [0023], "the system update data 102 is data representative of modifications from software system 110 updates, such as from custom modifications or additions, configuration changes, a service pack, a new software system 110 version, activation of previously unutilized software system 110 functionality or processes, and the like. The system update data 102 may be received or obtained in a number of different ways [obtaining information]. One such way the system update data 102 may be received is with a service pack distributed by a software system 110 developer. In other embodiments, the system update data 102 may be received from or obtained by invoking a change analyzer program that operates to identify processes and components of the software system 110 impacted by the system update [about a requested modification to an original code of a software program].")
classifying said modification requested based on a type of change; (Wefers [0023], "As mentioned above, the system update data 102 is data representative of modifications from software system 110 updates, such as from custom modifications or additions, configuration changes, a service pack, a new software system 110 version, activation of previously unutilized software system 110 functionality or processes, and the like [based on a type of change]. The system update data 102 may be received or obtained in a number of different ways. One such way the system update data 102 may be received is with a service pack distributed by a software system 110 developer. In other embodiments, the system update data 102 may be received from or obtained by invoking a change analyzer program that operates to identify processes and components of the software system 110 impacted by the system update [classifying said modification requested]. A change analyzer program, such as the Business Process Change Analyzer available from SAP AG of Waldorf, Germany as a portion of the Solution Manager product, generally executes a set of test cases against the software system 110 while the software system 110 is in a trace mode. While in trace mode, the software system logs execution information such as processes and components that are called, what they are called by, and what they call. From this log data, processes and components either directly impacted by the system update or indirectly impacted (i.e., processes and components that call or are called by directly impacted processes or components) are identified.")
identifying a plurality of unit tests available and selecting and customizing at least one of said unit tests based on classification of said type of code change requested; (Wefers [0022], "The test plan generator 114 operates to generate a test plan in view of system update data 102 and test plan preferences. The system update data 102 is data representative of modifications from software system 110 updates, such as from custom modifications or additions, configuration changes, a service pack, a new software system 110 version, activation of previously unutilized software system 110 functionality or processes, and the like. The test plan preferences include data identifying parameters for use by the test plan generator 114 in selecting test cases to include in a test plan [selecting and]. Based on the system update data 102 and the test plan preferences, the test plan generator may consider a large number of test cases and assemble a subset therefrom to form a test plan meets the test plan preferences [identifying a plurality of unit tests available]. The test plan generator 114, in some embodiments, may first provide a summary view of a test plan prior to full test plan generation. The summary view can be provided to a user along with abilities to make modifications to the test plan and to accept the test plan. The test plan may then be modified or generated by the test plan generator based on the user input [customizing at least one of said unit tests based on classification of said type of code change requested].")
using said at least one selected and customized unit test to determine differences between said original code and said a modified changed code; (Wefers [0029], "The data the test plan generator 210 operates upon [using said at least one selected and customized unit test] includes system impact data 202 that identifies components of a software system impacted by a
system update or other modification. The system impact data 202 may identify system
components at different granularities, such as business processes, objects, object code branches,
database tables or fields, user interfaces, content, communication interfaces, and the like. In
summary, the system impact data 202 represents what has been changed in the software system
in a form that is relevant to the logic and other data within the test plan generator 210 [to
determine differences between said original code and said modified changed code].")
[Examiner's Note: A test plan can include selected and modified unit tests that operate upon
metadata to determine differences between code updates]
Wefers does not teach: generating one or more test execution stories to highlight any changes between said original code and said modified code, and wherein the information about code modification is obtained by monitoring events associated with said software program including variable value change and said information about said code modification to be made is obtained by monitoring events associated with said software program including variable value changes;
analyzing said test execution stories and reviewing previous code changes stored in a database to provide additional missing information from said test execution stories;
However, in an analogous art Talluri teaches: generating one or more test execution stories to highlight any changes between said original code and said modified code (Talluri, Column 25 Lines 7-32, “The procedure may start at step 1605, and continues to step 1610, where, again, a computing device maintains an IDE for managing software code for one or more software programs. In step 1615, as described in greater detail above, the IDE may also determine one or more code changes to the software code. In some embodiments, the IDE may determine a change between a particular given version of the software code and a subsequent version, such as from a software update or revision. Examples of code changes include an added code, a removed code, added anti-patterns, added service dependencies, and so on. In step 1620, as described in greater detail above, the IDE determines a performance impact (such as increased latency) of each of the one or more code changes (e.g., through various algorithms by leveraging existing performance data or calculating the new number of microprocessor instructions, etc.). For instance, in some embodiments, the determination in step 1620 comprises executing the code change (e.g., separately or as a whole with the entire code), determining runtime performance information resulting from the code change, and then calculating a difference between the determined runtime performance and the runtime performance from the version prior to the code change. In other embodiments, the performance impact may be determined by estimation of a change based on baselines of runtime performance information [generating one or more test execution stories] … In step 1625, as described in greater detail above, the IDE prepares user-understandable indications of the performance impact of the one or more code changes (e.g., a percentage change, a value change, a warning indication, color-coding of the code changes, and so on) [to highlight any changes]. In some embodiments, the user-understandable indications may be based on a comparison to a baseline (e.g., where the code is re-used from previous programs), while in others, the comparison may be to previous iterations of the code within the IDE (e.g., determining the difference(s) from the last time the code was executed in the runtime environment of the IDE) [between said original code and said modified code]. Accordingly, in step 1630, the IDE may then display the user-understandable indications of the performance impact in the GUI when a respective code change is displayed in the GUI. In some embodiments, additional information may also be displayed, as mentioned above.”) […]
analyzing said test execution stories and reviewing previous code changes stored in a database [to provide additional missing information] from said test execution stories; (Talluri Column 20 Lines 1-23, “For instance, various tools, such as APM tools 902, other monitoring tools 904, cloud providers 906, business tracking tools 908, etc. may feed information into a code mining and mapper (ingestion system) 610. The ingestion system 610 is illustratively a module which connects to those various tools (e.g., APM tools, controllers, front-end error collection tools, etc.) to collect runtime data like snapshots, stack traces, call graphs, errors, timing summaries, JVM stats, thread contention details, memory leaks, and other performance statistics or monitoring data and business performance data [analyzing said test execution stories]. An ingestion module 912 of the system 910 hooks into the various collection systems [stored in a database], e.g., in an ad-hoc manner by catching up on data and then getting inline updates in a parallel manner for new data. A meta data gatherer 914 may be used by the ingestion system 910 to collect various meta data like code versions and environment versions, code base artifacts or commentary, etc [and reviewing previous code changes]. At the same time, meta data gatherer 914 can interface with monitoring tools 902, 904, 906, 908 to communicate bi-directionally to configure info points and other configuration variables to track more performance data based on judgment by software developers as to whether a particular class or method needs to be tracked at higher frequency or in-depth with more performance data [from said test execution stories].”) [Examiner’s Note: An APM (application performance management) or a collection system can be a cloud database that allows for storage and monitoring of application versions as described in (104)]
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Talluri into the teachings of Wefers. This combination of teachings would have resulted in a method configured to obtain a requested code modification for test selection and customization, as in Wefers, with test execution to report and analyze changes between software versions, as in Talluri. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of receiving runtime data to configure the collection of runtime data and provide a visualization accordingly (Talluri Column 6 Lines 33-54).
The combination of Wefers and Talluri teaches generating one or more test execution stories to highlight any changes between said original code and said modified code, and … analyzing said test execution stories and reviewing previous code changes stored in a database…from test execution stories but does not teach: [generating one or more test execution stories to highlight any changes between said original code and said modified code, and] wherein the information about code modification is obtained by monitoring events associated with said software program including variable value change and said information about said code modification to be made is obtained by monitoring events associated with said software program including variable value changes;
[analyzing said test execution stories and reviewing previous code changes stored in a database] to provide additional missing information [from said test execution stories;]
generating instructions to highlight software changes by providing missing information [from said test execution stories.]
However, in an analogous art Gacek teaches: […] wherein the information about code modification is obtained by monitoring events associated with said software program including variable value change and said information about said code modification to be made is obtained by monitoring events associated with said software program including variable value changes; (Gacek Columns 4-5 Lines 65-67 and 1-26, “Performing inter-procedural dataflow analysis on a source code listing allows for the identification of nodes in a control flow graph that contribute to a data value, such as a variable [including variable value change], at a given point in a source code listing [obtained by monitoring events associated with said software program]. These nodes are called a program slice, and program slicing is the identification of these nodes across a whole software program and its source code listing. Program slicing reduces the amount of instructions in a source code listing that may be analyzed for API correctness. Instructions that contribute to the value of input data for API functions are identified and isolated through program slicing … Concolic execution is a software verification technique that combines symbolic execution with concrete execution to improve analysis of data values at a specific point in a source code listing. Symbolic execution is a technique whereby variables in a source code listing are represented by symbolic values, and their changes to a variable's value is monitored as it is handled by various instructions in a source code listing. Concrete execution is a technique where the value of variables is monitored as it is modified by instructions in a source code listing, where the initial value is set as a particular test value. In addition to improving program slice accuracy, concolic execution allows for a more thorough identification of possible values for input data to an API function at a specified point in a source code listing [said information about said code modification to be made is obtained].”) [Examiner’s Note: A code modification to be made includes potential or possible changes to API inputs]
[…] to provide additional missing information […] and
generating instructions to highlight software changes by providing missing information […] (Gacek Columns 9-10 Lines 52-67 and 1-11, FIG. 2 illustrates an integrated development environment (IDE) 202 according to at least one embodiment. An IDE 202 may contain a text editor 204 for writing and editing source code in any programming language, including those described above. The source code in the text editor 204 may include function calls to an API provided by a computing resource service provider. The text editor 204 may provide facilities to assist in software development, including source code highlighting and documentation related to a programming language [generating instructions to highlight software changes]. The IDE 202 may contain a module for code completion 206. The code completion module 206 allows for auto-completion of instructions as they are written in the text editor 204 by a software developer [to provide additional missing information].”) [Examiner’s Note: Using characteristics from static analysis, Gacek teaches a method of providing data values that allow autocompletion in the text editor/IDE to aid the developer in writing software and thereby providing missing information]
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Gacek into the teachings of Wefers in view of Talluri. This combination of teachings would have resulted in a method configured to obtain a requested code modification for test selection and customization, as in Wefers, with test execution to report and analyze changes between software versions, as in Talluri, in order to highlight variable changes and generate information according to user intentions, as in Gacek. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of using static analysis techniques to define the impacted data values associated with the program flow (Gacek Column 4 Lines 10-35).
Claim 14 is directed to a computer system for data processing, comprising: one or more processors, one or more computer-readable memories, one or more computer readable tangible storage medium, and program instructions stored on at least one of the one or more tangible storage medium for execution by at least one of the one or more processors via at least one of the one or more memories, (Wefers FIG 8.) corresponding to the method limitations as disclosed in claim 1. Thus, claim 14 is rejected for the same reasons set forth in claim 1.
With regards to claim 15, the rejection of claim 14 is incorporated.
The combination of Wefers and Talluri does not teach: wherein the information about code modification is obtained by monitoring events associated with said software program
including variable value changes.
However, in an analogous art Gacek teaches: wherein the information about code
modification is obtained by monitoring events associated with said software program
including variable value changes. (Gacek Columns 4-5 Lines 65-67 and 1-26, “Performing inter-procedural dataflow analysis on a source code listing allows for the identification of nodes in a control flow graph that contribute to a data value, such as a variable [including variable value change], at a given point in a source code listing [obtained by monitoring events associated with said software program]. These nodes are called a program slice, and program slicing is the identification of these nodes across a whole software program and its source code listing. Program slicing reduces the amount of instructions in a source code listing that may be analyzed for API correctness. Instructions that contribute to the value of input data for API functions are identified and isolated through program slicing … Concolic execution is a software verification technique that combines symbolic execution with concrete execution to improve analysis of data values at a specific point in a source code listing. Symbolic execution is a technique whereby variables in a source code listing are represented by symbolic values, and their changes to a variable's value is monitored as it is handled by various instructions in a source code listing. Concrete execution is a technique where the value of variables is monitored as it is modified by instructions in a source code listing, where the initial value is set as a particular test value. In addition to improving program slice accuracy, concolic execution allows for a more thorough identification of possible values for input data to an API function at a specified point in a source code listing [said information about said code modification to be made is obtained].”) [Examiner’s Note: A code modification to be made includes changes to API inputs]
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Gacek into the teachings of Wefers in view of Talluri. This combination of teachings would have resulted in a method configured to obtain a requested code modification for test selection and customization, as in Wefers, with test execution to report and analyze changes between software versions, as in Talluri, in order to highlight variable changes and generate information according to user intentions, as in Gacek. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of using static analysis techniques to define the impacted data values associated with the program flow (Gacek Column 4 Lines 10-35).
Claims 18 and 19 are directed to a computer program product for data processing corresponding to the computer program product limitations as disclosed in claims 14 and 15. Thus, claims 18 and 19 are rejected for the same reasons set forth in claim 14 and 15.
Claims 3 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Wefers in view of Talluri in view of Gacek as applied to claims 1 and 14 above, and further in view of US 20200089594 A1 hereinafter "Zhou".
With regards to claim 3, the rejection of claim 1 is incorporated.
The combination of Wefers, Talluri, and Gacek does not teach: wherein said code change has not been made but is scheduled to be made.
However, in an analogous art Zhou teaches wherein said code change has not been made but is scheduled to be made. (Zhou [0025], "As the software is developed, the code may be continuously re-written, edited, and updated. In some environments, the software code may be updated periodically, such as every day, as developers fix bugs in the code, add or remove features and functionality, change the design of the software, change the software in view of user feedback, and the like. A load testing team of programmers may be tasked with the responsibility of updating load tests in response to each change to the software.") [Examiner’s Note: A periodic update can mean a scheduled update]
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Zhou into the teachings of Wefers in view of Talluri and further in view of Gacek. This combination of teachings would have resulted in a method configured to obtain a requested code modification for test selection and customization, as in Wefers, with test execution to report and analyze changes between software versions, as in Talluri, in order to highlight variable changes and generate information according to user intentions, as in Gacek, and code changes are periodically changed but not integrated until receiving confirmation or feedback on its feasibility, as in Zhou. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of alleviating the burden of manual load testing by marking execution, logs, and scenarios for reporting each time the software is updated for code review (Zhou [0028-29]).
With regards to claim 16, the rejection of claim 14 is incorporated.
The combination of Wefers and Talluri does not teach: wherein said code modification has not been made but is scheduled to be made and said information about said code modification to be made is obtained by monitoring events associated with said software program including variable value changes.
However, in an analogous art Gacek teaches […] by monitoring events associated with said software program including variable value changes. (Gacek Columns 4-5 Lines 65-67 and 1-26, “Performing inter-procedural dataflow analysis on a source code listing allows for the identification of nodes in a control flow graph that contribute to a data value, such as a variable [including variable value change], at a given point in a source code listing [obtained by monitoring events associated with said software program]. These nodes are called a program slice, and program slicing is the identification of these nodes across a whole software program and its source code listing. Program slicing reduces the amount of instructions in a source code listing that may be analyzed for API correctness. Instructions that contribute to the value of input data for API functions are identified and isolated through program slicing”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Gacek into the teachings of Wefers in view of Talluri. This combination of teachings would have resulted in a method configured to obtain a requested code modification for test selection and customization, as in Wefers, with test execution to report and analyze changes between software versions, as in Talluri, in order to highlight variable changes and generate information according to user intentions, as in Gacek. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of using static analysis techniques to define the impacted data values associated with the program flow (Gacek Column 4 Lines 10-35).
The combination of Wefers, Talluri, and Gacek teaches by monitoring events associated with said software program including variable value changes but does not teach: wherein said code modification has not been made but is scheduled to be made and said information about said code modification to be made is obtained [by monitoring events associated with said software program including variable value changes]
However, in an analogous art Zhou teaches wherein said code change has not been made but is scheduled to be made. (Zhou [0025], "As the software is developed, the code may be continuously re-written, edited, and updated. In some environments, the software code may be updated periodically, such as every day, as developers fix bugs in the code, add or remove features and functionality, change the design of the software, change the software in view of user feedback, and the like. A load testing team of programmers may be tasked with the responsibility of updating load tests in response to each change to the software.") [Examiner’s Note: A periodic update can mean a scheduled update]
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Zhou into the teachings of Wefers in view of Talluri and further in view of Gacek. This combination of teachings would have resulted in a method configured to obtain a requested code modification for test selection and customization, as in Wefers, with test execution to report and analyze changes between software versions, as in Talluri, in order to highlight variable changes and generate information according to user intentions, as in Gacek, and code changes are periodically changed but not integrated until receiving confirmation or feedback on its feasibility, as in Zhou. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of alleviating the burden of manual load testing by marking execution, logs, and scenarios for reporting each time the software is updated for code review (Zhou [0028-29]).
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Wefers in view of Talluri in view of Gacek as applied to claim 1 above, and further in view of US 12072790 B1 hereinafter “Pearson”.
With regards to claim 4, the rejection of claim 1 is incorporated.
The combination of Wefers, Talluri, and Gacek does not teach: wherein a code change type includes one of a group including: addition of a new feature, support for a new type of input file, an optimization feature to improve speed of execution, or a patch to provide a code fix to a problem.
However, in an analogous art Pearson teaches wherein a code change type includes one of a group including: addition of a new feature, support for a new type of input file, an optimization feature to improve speed of execution, or a patch to provide a code fix to a problem. (Pearson Column 6 Lines 40-54, "When the CI/CD system 102 receives a request from a developer to integrate a source code change into the shared codebase for the application, it may transmit data identifying the source code integration request 108 to the mutation test system 104. The source code integration request 108 may include the modified source code itself [wherein a code change type includes one of a group including], such as one or more new or updated source code files, functions, and/or classes [addition of a new feature, support for a new type of input file, an optimization feature to improve speed of execution, or a patch to provide a code fix to a problem]. In some examples, the modified source code received from the CI/CD system 102 may include annotations (e.g., code comments, track changes, etc.) or other metadata to identify the specific changed portions of the code that are different from the corresponding code within the shared code repository for the application. Additionally or alternatively, the mutation test system 104 may use a code change analyzer 110 to determine the specific changed portions of the code associated with the source code integration request 108")
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Pearson into the teachings of Wefers in view of Talluri and further in view of Gacek. This combination of teachings would have resulted in a method configured to obtain a requested code modification for test selection and customization, as in Wefers, with test execution to report and analyze changes between software versions, as in Talluri, in order to highlight variable changes and generate information according to user intentions, as in Gacek, and monitoring events of the program to obtain the information required for the classification of code modification request, as in Pearson. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of determining which sets of tests are to be executed on the request based on metadata associations representing the relationships between different portions of source code with previous runs and/or coverage data associated with different test/test suites (Pearson Column 8 Lines 19-35).
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Wefers in view of Talluri in view of Gacek in view of Pearson as applied to claim 4 above, and further in view of US 20210157577 A1 hereinafter “Sobran”.
With regards to claim 5, the rejection of claim 4 is incorporated.
The combination of Wefers, Talluri, Gacek, and Pearson does not teach: wherein detecting and classifying said type of change is performed through detecting NLP of commit messages generated
However, in an analogous art Sobran teaches wherein detecting and classifying said type of change is performed through detecting NLP of commit messages generated (Sobran [0032], "In another embodiment, program 150 partitions logs into discrete sets containing multiple versions of the same log but processed utilizing different NLP techniques [is performed through detecting NLP]. In yet another embodiment, program 150 constructs subsets by identifying the scope of the associated context and segmenting the log or corpus sections into discrete context, topic, subject, issue, or category sets [detecting and classifying said type of change]. In various embodiments, program 150 non-deterministically divides the processed sets into training sets and test sets. In an embodiment, program 150 calculates a log difference (e.g., how different and/or how similar) set between consecutive commits based on the generated dictionary objects, as detailed in step 204. In this embodiment, program 150 utilizes Euclidean distance to calculate a difference between consecutive commits, associated logs, and/or related commits [of commit messages generated]. Additionally, program 150 may incorporate the log difference as a feature. For example, program 150 utilizes the following function to train/feed inputs into model 152; (C, P, L, D), where C is a commit, P is the an associated label, L is an associated log, and D is a calculated difference (e.g., log difference, similarity score, etc.).")
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Sobran into the teachings of Wefers in view of Talluri in view of Gacek and further in view of Pearson. This combination of teachings would have resulted in a method configured to obtain a requested code modification for test selection and customization, as in Wefers, with test execution to report and analyze changes between software versions, as in Talluri, in order to highlight variable changes and generate information according to user intentions, as in Gacek, and monitoring events of the program to obtain the information required for the classification of code modification request, as in Pearson, and further classifying the code modification through processing the commit messages through NLP, as in Sobran. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of utilizing NLP techniques to parse and analyze a commit/log and identify distinct categories, themes, or topics (Sobran [0027]).
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Wefers in view of Talluri in view of Gacek and in view of Person as applied to claim 4 above, and further in view of US 20190286741 A1 hereinafter “Agarwal”.
With regards to claim 6, the rejection of claim 4 is incorporated.
The combination of Wefers, Talluri, Gacek, and Pearson does not teach: wherein detecting and classifying said type of change is performed through detecting AST and ontology search
However, in an analogous art Agarwal teaches wherein detecting and classifying said type of change is performed through detecting AST and ontology search (Agarwal [0037],
"To assign a semantic label, the system may access or use one or more semantic role
dictionaries, ontologies, information extractors, or the like [and ontology search]. The semantic
label describes a semantic role of the word within the text surrounding the difference. In other
words, the semantic label describes the semantic role of the word within the completed phrase.
The semantic label provides an indication of the category or aspect of the changed word
[wherein detecting and classifying said type of change]. In other words, the system uses the
surrounding text to determine the semantic relationship of the identified change with respect to the surrounding text or completed phrase. This semantic relationship is then used to identify the
aspect of the rule or regulation that has changed, thereby allowing the system to assign a
semantic label indicating the semantic role of the changed word to the identified difference.
Assignment of the semantic label may include using a parse tree to identify the semantic parts of
the phrase or text surrounding the identified difference [is performed through detecting AST].
Once the parse tree has been created, the system can identify each semantic part of the phrase,
thereby identifying the semantic role of the changed word. The system can then assign a label
that corresponds to the semantic role to the changed word.")
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Agarwal into the teachings of Wefers in view of Talluri in view of Gacek and further in view of Pearson. This combination of teachings would have resulted in a method configured to obtain a requested code modification for test selection and customization, as in Wefers, with test execution to report and analyze changes between software versions, as in Talluri, in order to highlight variable changes and generate information according to user intentions, as in Gacek, and monitoring events of the program to obtain the information required for the classification of code modification request, as in Pearson, and classifying the change can be executed through a syntax tree or ontology search, as in Agarwal. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of providing a system that can identify changes and provide a summary between revisions as well as a rule or surrounding text once the structure has been identified and aligned (Agarwal [0022]).
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Wefers in view of Talluri in view of Gacek in view of Pearson as applied to claim 4 above, and further in view of US 20200257523 A1 hereinafter “Purohit”.
With regards to claim 7, the rejection of claim 4 is incorporated.
The combination of Wefers, Talluri, Gacek, and Pearson does not teach: wherein detecting and classifying said type of change is performed by identifying similarly labelled code.
However, in an analogous art Purohit teaches wherein detecting and classifying said
type of change is performed by identifying similarly labelled code. (Purohit [0032], "The
change to the section of the application program instruction set is then associated (block 103) to
the respective application feature. That is, based on the tag, the change to the section of the
application program instruction set is mapped to the respective application feature. As described
above, tags are created which relate to particular features of a computing application. Those tags
are matched with sections of the program instruction set that provide that feature. Accordingly, at
any point during development as that section of the instruction set is changed, the tag associated
with the changed section is identified. With the tag known, and the mapping between tags and
particular features stored in a database; the feature that is altered by the section change can be
identified via the tag.") [Examiner's Note: A tag would identify sections of code that can be then
identified later on for matching in order to classify and detect types of changes]
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Purohit into the teachings of Wefers in view of Talluri in view of Gacek and further in view of Pearson. This combination of teachings would have resulted in a method configured to obtain a requested code modification for test selection and customization, as in Wefers, with test execution to report and analyze changes between software versions, as in Talluri, in order to highlight variable changes and generate information according to user intentions, as in Gacek, and monitoring events of the program to obtain the information required for the classification of code modification request, as in Pearson, to further classify changes through the label of similar sections of code, as in Purohit. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of marking a section of application program instructions with metadata that can be used to identify the associated data (Purohit [0029]).
Claims 8-9 are rejected under 35 U.S.C. 103 as being unpatentable over Wefers in view of Talluri in view of Gacek as applied to claim 1 above, and further in view of US 20240320134 A1 hereinafter "Yang".
With regards to claim 8, the rejection of claim 1 is incorporated.
The combination of Wefers, Talluri, and Gacek does not teach: wherein said unit test selection and customization is performed by identifying existing unit tests affected by said modification.
However, in an analogous art Yang teaches wherein said unit test selection and customization is performed by identifying existing unit tests affected by said modification. (Yang [0076], "To resolve the foregoing problems, this application provides a unit testing generation method and apparatus, and a related device. When a user performs a refactoring operation on source code, a type of the refactoring operation performed by the user on the source code can be determined. Then unit testing corresponding to refactored code is determined based on the determined type of the refactoring operation, the source code, and the refactored code. A developer does not need to manually modify unit testing corresponding to the source code to obtain the unit testing corresponding to the refactored code, or rewrite the unit testing corresponding to the refactored code, to save energy and time of the developer, and improve efficiency of obtaining the unit testing corresponding to the refactored code and efficiency of software development and maintenance.")
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Yang into the teachings of Wefers in view of Talluri and further in view of Gacek. This combination of teachings would have resulted in a method configured to obtain a requested code modification for test selection and customization, as in Wefers, with test execution to report and analyze changes between software versions, as in Talluri, in order to highlight variable changes and generate information according to user intentions, as in Gacek, and customizing/selecting the unit tests are based on the source code modification, as in Yang. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of determining the unit test based on the type of refactoring operation, the source code, and the refactored code to save energy and time of the developer as well as the efficiency of software development/maintenance (Yang [0008]).
With regards to claim 9, the rejection of claim 8 is incorporated.
Wefers further teaches modifying a subset of unit tests that relate to said code change so that their input is reduced to a minimum number of elements needed to demonstrate said code change. (Wefers [0063], "Generation of the test plan in some embodiments may include retrieving data representative of test cases associated with each of the software system components and business processes represented in the identified set of software system components and business processes. The data representative of test cases is typically retrieved from a test case database, which may be a standalone database, a portion of a larger database, or other data storage mechanism or arrangement within which such data may be stored. The retrieved data representative of the test cases is then processed in view of the test plan preferences to reduce the number of test cases to include in the test plan. The processing of the retrieved data representative of the test cases in view of the test plan preferences, in some embodiments, includes removing test cases that test only software system components and business processes identified in the data representative of test plan preferences as not to be tested. Further, when a test plan preference specifies a requirement for either automated or manually executed test cases, all test cases contrary to the requirement are removed. Additionally, some embodiments, with regard to an individual test case included more than once in the retrieved data representative of test cases, include removing all but one instance of the respective test case.")
Claims 10-11 are rejected under 35 U.S.C. 103 as being unpatentable over Wefers in view of Talluri in view of Gacek as applied to claim 1 above, and further in view of Purohit.
With regards to claim 10, the rejection of claim 1 is incorporated.
The combination of Wefers, Talluri, and Gacek does not teach: wherein analysis of differences between original and modified changed code is done through using tracing and monitoring, including log collection.
However, in an analogous art Purohit teaches wherein analysis of differences between
original and modified changed code is done through using tracing and monitoring,
including log collection. (Purohit [0055-56], "FIG. 4 depicts a computing system (200) for
detecting application feature changes, according to another example of principles described
herein. In the example depicted in FIG. 4, the computing system (200) includes the tagging
device (202), database (204), change tracking device (206), and mapping device (208) as described above in connection with FIG. 2. in some examples, the computing system (200)
includes additional components. For example, the computing system (200) includes a log record
(410) that includes a record of changes to an application feature. The log record (410) may be
unique to an application feature. In other examples, the log record (410) includes all changes
made to an application functionality, which may include changes to multiple application features.
In yet another example, the log record (410) includes all changes made to an application, which
may include changes to multiple application features and functionalities. The log record (410)
may store various pieces of information. For example, each entry in the log record (410) may
include a tag associated with the application feature that was changed. The log record (410) entry
may also indicate the current version of the application feature as well as any number of past
versions of the application feature.") [Examiner's Note: A log record describing code changes
can be presented to any 3rd party for collection]
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Purohit into the teachings of Wefers in view of Talluri in view of Gacek. This combination of teachings would have resulted in a method configured to obtain a requested code modification for test selection and customization, as in Wefers, with test execution to report and analyze changes between software versions, as in Talluri, in order to highlight variable changes and generate information according to user intentions, as in Gacek, and tracing the software to provide a system that can determine software differences between commit versions, as in Purohit. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of providing a computing system that can mark sections of an application program by a tag while tracking a change to the section and making the associations between the marking tag and change respectively (Purohit [0003]).
With regards to claim 11, the rejection of claim 1 is incorporated.
The combination of Wefers, Talluri, and Gacek teaches a test execution story instruction is generated but does not teach: wherein a test execution story instruction is generated by associating subtitles and labels to at least one block of modified changed code portion.
However, in an analogous art Purohit teaches wherein a test execution story instruction is generated by associating subtitles and labels to at least one block of modified changed code portion. (Purohit [0023], "Specifically, the present specification provides a way of feature detection by detecting changes to a portion of the application program instruction set that relates to that feature. That is, the application program instruction set includes instructions to carry out a particular feature. As a developer changes those instructions, that change is carried through, and indicated to a third-party subscriber, as a change to the feature. This may be done by tagging the sections of the application program instruction set that relate to a particular feature and then to detect a change to the program instructions [by associating subtitles and labels to at least one block of modified changed code portion]. The location in the instruction set that is changed is identified by the tag and the feature associated with that tag is identified and passed to any interested third-party subscribers.") and (Purohit [0027], "Accordingly, a section of the application program instruction set may be the textual instructions that, when executed by a processor, displays the graph. Accordingly, this section of the application program instruction set may be marked (block 101) with a tag that associates it with the graphical display feature. In general, a tag refers to metadata that is associated with a portion of an instruction set. The tag may be searched and used to identify the associated data [wherein a test execution story instruction is generated].)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Purohit into the teachings of Wefers in view of Talluri in view of Gacek. This combination of teachings would have resulted in a method configured to obtain a requested code modification for test selection and customization, as in Wefers, with test execution to report and analyze changes between software versions, as in Talluri, in order to highlight variable changes and generate information according to user intentions, as in Gacek, and tracing the software to provide a system that can determine software differences between commit versions, as in Purohit. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of providing a computing system that can mark sections of an application program by a tag while tracking a change to the section and making the associations between the marking tag and change respectively (Purohit [0003]).
Claims 12-13, 17, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Wefers in view of Talluri in view of Gacek as applied to claims 1, 14, and 18 above, and further in view of US 20150254073 A1 hereinafter "Menard".
With regards to claim 12, the rejection of claim 1 is incorporated.
The combination of Wefers, Talluri, and Gacek does not teach: generating a test execution story media file, wherein said test execution story media provides content to summarize steps up to point where said original and said modified code diverge.
However, in an analogous art Menard teaches generating a test execution story media file, wherein said test execution story media provides content to summarize steps up to point where said original and said modified code diverge. (Menard [0082-86], "In accordance with another aspect of the present invention, there is provided a method for comparing versions of a given program asset in an ETL library, the given program asset being protected and buildable from a digest of instructions stored in a data storage, the data storage storing multiple instances of the digest, each instance corresponding to a version of the given program asset, the method comprising steps of: a) receiving, via a user interface, instructions to compare two versions of said given program asset of the ETL library; b) retrieving from the data storage, by means of an integration module, two instances of the digest corresponding to said two versions of said given program asset; c) by means of an integration module, generating comparison information, by pairing matching components of the two instances [provides content to summarize steps up to point where said original and said modified code diverge]; and d) returning, by means of the integration module, the comparison information on the user interface [generating a test execution story media file, wherein said test execution story media].") [Examiner's Note: By identifying matching pairs, Menard teaches to summarize unchanged software between the two versions not including the divergence]
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Menard into the teachings of Wefers in view of Talluri in view of Gacek. This combination of teachings would have resulted in a method configured to obtain a requested code modification for test selection and customization, as in Wefers, with test execution to report and analyze changes between software versions, as in Talluri, in order to highlight variable changes and generate information according to user intentions, as in Gacek, and summarize the similarities between software instances for display for user visualization, as in Menard. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of providing a version control system that controls versions of a program component with a digest or summary for instructions on building the program component with integration into the library or codebase (Menard [0101]).
With regards to claim 13, the rejection of claim 12 is incorporated.
The combination of Wefers, Talluri, and Gacek does not teach: attaching said test execution story media file to a code modification change versioning as supplemental material.
However, in an analogous art Menard teaches attaching said test execution story media file to a code modification change versioning as supplemental material. (Menard [0103], "an integration module being in communication with the user interface for receiving a user command to generate a new version of one of said program components, the integration module being in communication with the library of program components for extracting therefrom an instance of a digest corresponding to said program component and for associating thereto a new version, the integration module being further in communication with the data storage for storing therein said instance of the digest and the new version."). [Examiner's Note: the digest contains summary information about matching version features which is then stored with the new version of the software itself]
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Menard into the teachings of Wefers in view of Talluri in view of Gacek. This combination of teachings would have resulted in a method configured to obtain a requested code modification for test selection and customization, as in Wefers, with test execution to report and analyze changes between software versions, as in Talluri, in order to highlight variable changes and generate information according to user intentions, as in Gacek, and summarize the similarities between software instances for display for user visualization, as in Menard. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of providing a version control system that controls versions of a program component with a digest or summary for instructions on building the program component with integration into the library or codebase (Menard [0101]).
With regards to claim 17, the rejection of claim 14 is incorporated.
The combination of Wefers, Talluri, and Gacek does not teach: generating a test execution story media file, wherein said test execution story media provides content to summarize steps up to point where said original and said modified code diverge.
attaching said test execution story media file to a code modification change versioning as supplemental material.
However, in an analogous art Menard teaches generating a test execution story media file, wherein said test execution story media provides content to summarize steps up to point where said original and said modified code diverge. (Menard [0082-86], "In accordance with another aspect of the present invention, there is provided a method for comparing versions of a given program asset in an ETL library, the given program asset being protected and buildable from a digest of instructions stored in a data storage, the data storage storing multiple instances of the digest, cache instance corresponding to a version of the given program asset, the method comprising steps of: a) receiving, via a user interface, instructions to compare two versions of said given program asset of the ETL library; b) retrieving from the data storage, by means of an integration module, two instances of the digest corresponding to said two versions of said given program asset; c) by means of an integration module, generating comparison information, by pairing matching components of the two instances [provides content to summarize steps up to point where said original and said modified code diverge]; and d) returning, by means of the integration module, the comparison information on the user interface [generating a test execution story media file, wherein said test execution story media].") [Examiner's Note: By identifying matching pairs, Menard teaches to summarize unchanged software between the two versions not including the divergence]
attaching said test execution story media file to a code modification change versioning as supplemental material. (Menard [0103], "an integration module being in communication with the user interface for receiving a user command to generate a new version of one of said program components, the integration module being in communication with the library of program components for extracting therefrom an instance of a digest corresponding to said program component and for associating thereto a new version, the integration module being further in communication with the data storage for storing therein said instance of the digest and the new version."). [Examiner's Note: the digest contains summary information about matching version features which is then stored with the new version of the software itself]
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Menard into the teachings of Wefers in view of Talluri in view of Gacek. This combination of teachings would have resulted in a method configured to obtain a requested code modification for test selection and customization, as in Wefers, with test execution to report and analyze changes between software versions, as in Talluri, in order to highlight variable changes and generate information according to user intentions, as in Gacek, and summarize the similarities between software instances for display for user visualization, as in Menard. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of providing a version control system that controls versions of a program component with a digest or summary for instructions on building the program component with integration into the library or codebase (Menard [0101]).
Claim 20 is directed to a computer program product corresponding to the system limitations as disclosed in claim 17. Thus, claim 20 is rejected for the same reasons set forth in claim 17.
Response to Arguments
Applicant’s arguments with respect to claims 1 and 3-20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
In the Remarks, Applicant Argues:
There is nothing abstract in the solution provided by the amended claims. The techniques suggested are dynamic and require careful analysis each time. In addition, the volume of data that has to be processed at any one time, makes this process impossible to obtain using mental processes or abstract methodology. The benefits of suggested technique provided by the amendments are also very novel and has practical aspects that improve and enhance the ability of the developers to be able test or program sections effectively and by reducing the development time. In some examples, given a scenario in which developers and programmers are the project maintainers of a program, requesting a modification will lead to revisions of a complex code base. These modifications require a careful design and an understanding of all potential side- effects of the proposed code change that cannot be handled by pencil and paper, due to their complexity and amount of data to be handled. As suggested by the amended claims, this will lead to automatic generation of shortened narrative instructions that emphasize how new code changes affect runtime execution of the existing software (relevant data structures, data flow, and message exchanges) quickly, efficiently and by handling volumes of data simultaneously. This allows for dynamic changes usage of code change classes to select and configure existing software test cases that can highlight new software execution flows and automatic generation of narrative texts in the absence of comments and commit messages based on code change class detection.
Examiner’s Response:
The Examiner respectfully submits that the claims recite only “obtaining information about a requested modification to an original code of a software program;
classifying said modification requested based on a type of change;
identifying a plurality of unit tests available and selecting and customizing at least one of said unit tests based on classification of said type of code change requested;
using said at least one selected and customized unit test to determine differences between said original code and a modified changed code;
generating one or more test execution stories to highlight any changes between said original code and said modified code, wherein the information about code modification is obtained by monitoring events associated with said software program including variable value change and said information about said code modification to be made is obtained by monitoring events associated with said software program including variable value changes;
analyzing said test execution stories and reviewing previous code changes stored in a database to provide additional missing information from said test execution stories; and
generating instructions to highlight software changes by providing missing information from said test execution stories” with no further clarification on the claim scope of processing large amounts of data simultaneously while determining the outcome of processes instantaneously if one or more factors are dynamically changed, and how these activities can be performed by a machine and involves training a machine. Thus, as the claim are interpreted as broadly as their terms reasonably allow (see MPEP § 2111.01(I)). Under its broadest reasonable interpretation, it is a reasonable for one of ordinary skill in the art to construe the claims as an abstract process by its plain meaning.
In the Remarks, Applicant Argues:
Step 2A, Prong 1: The Claimed Invention is not Directed to an Abstract Idea Applicant's claimed invention is not simply directed to an abstract idea falling within the category of "Certain Methods of Organizing Human Activity." When the recitations of the claimed invention are viewed as a whole in light of the specification, it is clear that the claimed invention is directed to provide a practical application that includes a technical solution to overcome issues associated with overuse of computer resources when automatically mapping medical codes to extracted information from text in a narrative form.
National and private healthcare systems around the world are supporting increasingly complex and expensive treatments. In any case, the insurance companies bear the burden of paying the amount paid to hospitals and doctors. Technically, however, there is no closed information supply chain from diagnosis through one or more treatments, which are usually part of a frequently handwritten medical record, to insurance companies. Natural language processing (NLP) has been used to try to automate medical coding. The medical codes are typically organized hierarchically, i.e., as a sequence of characters comprising a main code and a respective sub-code. Although NLP technology may help with identifying some main codes, it
often lacks accuracy to gain the more detailed sub-code. This is due to lack of data to train the NLP engine, and lack of context beyond sentence and/or paragraphs that the NLP engine looks at. In addition, individual hospitals and/or individual doctors may have their own abbreviations for specific treatments. In enabling that computer functionality, a system that performs this hierarchical and artificial intelligence type teaching provides great improvements for patients in their treatment. The current amended claims provide includes understanding and applying of an amount of data beyond what may be comprehensible by a single person. (See paragraph [0022] of Applicant's specification). Therefore, the claimed invention is not directed to a judicial exception and based on the first prong of the Alice framework, the claimed invention is directed to patent eligible subject matter. Furthermore, beside abstract ideas, there are no mathematical formula involved in the present invention as reflected by the amended claims.
Examiner’s Response:
Examiner respectfully disagrees. While the disclosure may be viewed as a whole in light of the specification, the claimed invention is not directed to “mapping medical codes to extracted information from text in a narrative form” and any “information supply chain from diagnosis through one or more treatments, which are usually part of a frequently handwritten medical record, to insurance companies”. Therefore, the argument remains irrelevant as to why “highlighting software changes by obtaining information about a requested modification” integrates the abstract idea into a practical application. Furthermore, one of ordinary skill in the art would reasonably interpret the additional elements in the claims with a high level of generality such that it amounts to no more than a mere generic computer/computing component to apply the abstract idea (See MPEP 2106.05(f)). The claims also recite the additional element “obtaining information about a requested modification to an original code of a software program;” which has been determined to be a well-known, routine, and/or conventional activity of receiving or transmitting data over a network (See MPEP 2106.05(d)(II)). Accordingly, the additional elements recited in the claims cannot provide an inventive concept nor amount to significantly more.
In the Remarks, Applicant Argues:
Applicant submits that the claimed invention is integrated into a practical application of the alleged mental process by including additional elements that apply or use the judicial exception in some other meaningful way (described by the 2019 Guidance as an example limitation indicative of integration into a practical application). Applicant submits that the steps of the claimed invention have been narrowly tailored to illustrate elements which apply and use the judicial exception in a meaningful way.
Additionally, Federal Circuit court decisions and USPTO direction have provided further guidance regarding the rejection of claims under 35 U.S.C. § 101. Specifically, McRO, Inc. dba Planet Blue v. Bandai Namco Games America Inc., 120 USPQ2d 1091 (Fed. Cir. 2016) held the claimed methods of automatic lip synchronization and facial expression animation using computer-implemented rules patent eligible under 35 U.S.C. § 101, because they were not directed to an abstract idea (Step 2A of the USPTO's SME guidance). The McRO court relied on how the claimed rules within the McRO invention enabled the automation of specific animation tasks that previously could not be automated when determining that the claims were directed to improvements in computer animation instead of an abstract idea.
Specifically, the claims in McRo were deemed patent eligible under 35 U.S.C. § 101 based on the fact that they outlined a specific way of improving computer technology which "allow[ed] for the improvement realized by the invention." Similarly, Applicant's claimed method is similar in that it improves a method to obtain medical data which allows for how information can be used from a plurality of sources to build a complex network of nodes and relationships, thereby delivering a sorted list of potential paths of medical diagnosis codes and related procedural codes - in particular, main and/or secondary diagnosis codes, as well as, main procedure codes, as well as, secondary procedure codes - as a result of a query. Thus, "[a]n 'improvement in computer-related technology' is not limited to improvements in the operation of a computer or a computer network per se, but may also be claimed as a set of 'rules' (basically mathematical relationships) that improve computer-related technology by allowing computer performance of a function not previously performable by a computer." (Memorandum Regarding Recent Subject Matter Eligibility Decisions, issued November 2, 2016, pp. 2-3).
Examiner’s Response:
Examiner respectfully submits that McRo provides an improvement to the technological process of computer animation because he computer animation follows specific rules that pertain to facial expressions and sounds as an animated character speaks. A human artist did not use the claimed rules and relied on subjective determinations. So the use of these rules improves the existing technological process rather than merely using a computer as a tool to automate conventional activity. The current disclosure of the claims does not provide rules to follow and only provides a new/improved abstract idea NOT an improvement to computing technology. Thus, the computer remains a tool used to perform the steps of code analysis.
In the Remarks, Applicant Argues:
Step 2B: The Claimed Invention Amounts to Significantly More than the Alleged Judicial Exception. As held in the BASCOM Global Internet Services, Inc. v. AT&T Mobility LLC. Fed. Cir., No 2015-1763, 6/27/16 decision, when the patent claim seeks to cover a judicial exception to patent eligibility, the final question asks whether the inventive concept covered in the claimed invention was "significantly more" than merely the judicial exception. In this case, the question was whether the claim added significantly more, such that more than a mere abstract idea would be captured. The Federal Circuit ruled that the claims did add significantly more and, therefore, the claims are patent eligible and stated, "[a]s is the case here, an inventive concept can be found in the non-conventional and non-generic arrangement of known, conventional pieces." Applying BASCOM to amended claims, the claimed subject matter improves the technology of medical technology. Therefore, for at least the above reasons, Applicant respectfully requests that the rejection under 35 U.S.C. § 101 be reconsidered and withdrawn.
Applicant maintains that all claims are allowable for at least the reasons presented hereinabove. However, in the interests of brevity, this response does not comment on each and every comment made by the Examiner in the Office Action.
Examiner’s Response:
Examiner respectfully disagrees. The claimed invention does not apply to the technology of medical technology. Thus, the claims cannot improve the subject matter of medical technology. Furthermore, BASCOM further describes a non-conventional and non-generic arrangement of computer components for filtering Internet content which is not analogous to the subject of the invention disclosure. As recited the “one or more processors,” “one or more computer-readable memories,” “one or more computer-readable tangible storage medium,” and “program instructions executable by a processor” as disclosed in the claims are conventional and generic computer/computing components in a conventional arrangement. Thus, the additional elements cannot provide an inventive idea because it doesn’t provide an inventive concept nor amount to significantly more. For the reasons stated above, the rejections of claims 1, 3-8, and 10-20 under 35 U.S.C. 101 remain valid and are thus maintained.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TRAVIS VIET TRAN whose telephone number is (571)272-3720. The examiner can normally be reached Monday-Friday 8:30AM-5PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Wei Mui can be reached at 571-272-3708. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/T.V.T./Examiner, Art Unit 2191 /WEI Y MUI/Supervisory Patent Examiner, Art Unit 2191