DETAILED ACTION
The Office Action is in response to claims filed 05/19/2026.
Claim 2 is currently cancelled.
Claim 19 is a newly added claim.
Claims 1, 10-12, 14-18, and 20 are currently amended.
The objection to claims 1, 11-12, 14, and 17-20 are withdrawn in view of the applicant’s amendments to claims 1, 11-12, 14, and 17-20.
The rejection of claims 1 and 3-20 under 35 U.S.C. 112(b) are withdrawn in view of the applicant’s amendments to claims 1, 14-16, and 18-19.
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 .
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.
Claim 19 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 19 recites the limitation "variable value changes" in lines 3-4. It is unclear if variable value changes refers to the aforementioned “variable value changes” in claim 18 or to something else entirely. There is insufficient antecedent basis for this limitation in the claim.
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 and 3-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.
Claim Interpretation: Under the broadest reasonable interpretation (BRI), the limitations of Claim 1 are presumed to have their plain meaning consistent with the specification as it would be interpreted by one of ordinary skill in the art. See MPEP § 2111.
Step 1: Claim 1 is directed to a method, which is a process (a series of steps or acts), and falls within one of the statutory categories of invention.
Step 2A, Prong One: Claim 1 recites 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 changed code, and wherein the information about code modification is obtained by reviewing events associated with said software program including variable value change and said information about said code modification to be made is obtained by reviewing events associated with said software program including a change in any variable values;
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.
generating a plurality of narrative media files;
selecting by a reviewer, any of the one or more media files generated and executing any selected media file.
Nothing in the claim precludes the steps from practically being performed in the human mind alone using observation, evaluation, judgment, and opinion or with the aid of pen and paper. For example, the limitation (a) in the context of the claim encompasses a human classifying a modification based on a type of change in the human mind alone using observation, evaluation, judgment, and opinion or with the aid of pen and paper to classify a modification based on a type of change. And the limitation (b) in the context of the claim encompasses a human 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 in the human mind alone using observation, evaluation, judgment, and opinion or with the aid of pen and paper to identify a plurality of unit tests available and select and customize at least one of said unit tests based on classification of said type of code change. See MPEP § 2106.04(a)(2)(III).
If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the human mind alone or with the aid of pen and paper but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Step 2A, Prong Two: This judicial exception is not integrated into a practical application. In particular, the claim recites the additional elements:
(1) obtaining information about a requested modification to an original code of a software program;
(2) attaching one or more narrative media files from said plurality of media files generated in a source code database;
The additional elements are directed to the insignificant extra solution activity of mere data gathering/transmitting/outputting (See MPEP 2106.05(g)). Furthermore, all uses of the recited judicial exception require such data gathering/transmitting/outputting, and, as such, the additional elements do not impose any meaningful limits on the claim. The additional elements amount to necessary data gathering/transmitting/outputting. See MPEP § 2106.05(g).
Accordingly, even when viewed in combination, the additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
Step 2B: The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements when considered both individually and as a combination do not amount to significantly more than the abstract idea. As discussed above with respect to integration of the abstract idea into a practical application, the claim recites the additional element:
(1) obtaining information about a requested modification to an original code of a software program;
(2) attaching one or more narrative media files from said plurality of media files generated in a source code database;
The additional elements (1-2) simply append well-understood, routine, and conventional activities previously known to the industry, specified at a high level of generality, to the judicial exception is not indicative of an inventive concept. MPEP § 2106.05(d)(II) expressly states that the courts have recognized the computer function of receiving or transmitting data over a network, e.g., using the Internet to gather data as a well‐understood, routine, and conventional computer function when it is claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activities. Thus, a person of ordinary skill in the art would readily comprehend that it is well-understood, routine, and conventional in the computing art to attach one or more narrative media files generated in a source code database. Therefore, the limitations remain insignificant extra-solution activities even upon reconsideration and do not amount to significantly more.
Thus, taken alone, the additional elements do not amount to significantly more than the above-identified judicial exception (the abstract idea). Looking at the additional elements as a combination adds nothing that is not already present when looking at the additional elements taken individually. Even when considered in combination, the additional elements represent insignificant extra-solution activities and therefore do not provide an inventive concept. The claim is not patent eligible.
Claim Interpretation: Under the broadest reasonable interpretation (BRI), the limitations of Claim 14 are presumed to have their plain meaning consistent with the specification as it would be interpreted by one of ordinary skill in the art. See MPEP § 2111.
Step 1: Claim 14 is directed to a computer system, which is a machine, and falls within one of the statutory categories of invention.
Step 2A, Prong One: Claim 14 recites 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 a modified changed code;
generating one or more test execution stories to highlight any changes between said original code and said modified changed code, and wherein the information about code modification is obtained by reviewing events associated with said software program including variable value change and said information about said code modification to be made is obtained by reviewing events associated with said software program including a change in any variable values;
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.
generating a plurality of narrative media files;
selecting by a reviewer, any of the one or more media files generated and executing any selected media file.
These recited steps, under the broadest reasonable interpretation (BRI), cover performance of the steps in the human mind alone or with the aid of pen and paper. That is, other than reciting:
(1) 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 or more processors via at least one of the one or more memories, wherein the computer system is capable of performing a method
Nothing in the claim precludes the steps from practically being performed in the human mind alone using observation, evaluation, judgment, and opinion or with the aid of pen and paper. For example, the limitation (a) in the context of the claim encompasses a human classifying a modification based on a type of change in the human mind alone using observation, evaluation, judgment, and opinion or with the aid of pen and paper to classify a modification based on a type of change. And the limitation (b) in the context of the claim encompasses a human 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 in the human mind alone using observation, evaluation, judgment, and opinion or with the aid of pen and paper to identify a plurality of unit tests available and select and customize at least one of said unit tests based on classification of said type of code change. See MPEP § 2106.04(a)(2)(III).
If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the human mind alone or with the aid of pen and paper but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Step 2A, Prong Two: This judicial exception is not integrated into a practical application. In particular, the claim recites the additional elements:
(1) 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 or more processors via at least one of the one or more memories, wherein the computer system is capable of performing a method
The additional element (1) is 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. The one or more processors, one or more computer-readable memories, storage medium, and program instructions are used as a tool to perform the mental abstract steps of the claim (See MPEP 2106.05(f)).
Also, the claim recites the additional elements:
(2) obtaining information about a requested modification to an original code of a software program;
(3) attaching one or more narrative media files from said plurality of media files generated in a source code database;
The additional element (2-3) is directed to the insignificant extra solution activity of mere data gathering/transmitting/outputting (See MPEP 2106.05(g)). Furthermore, all uses of the recited judicial exception require such data gathering/transmitting/outputting, and, as such, the additional elements do not impose any meaningful limits on the claim. The additional elements amount to necessary data gathering/transmitting/outputting. See MPEP § 2106.05(g).
Step 2B: The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements when considered both individually and as a combination do not amount to significantly more than the abstract idea. As discussed above with respect to integration of the abstract idea into a practical application, the claim recites the additional elements:
(1) 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 or more processors via at least one of the one or more memories, wherein the computer system is capable of performing a method
The additional element (1) is 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. The one or more processors, one or more computer-readable memories, storage medium, and program instructions are used as a tool to perform the mental abstract steps of the claim (See MPEP 2106.05(f)).
Also, the claim recites the additional elements:
(1) obtaining information about a requested modification to an original code of a software program;
(2) attaching one or more narrative media files from said plurality of media files generated in a source code database;
The additional elements (2-3) simply append well-understood, routine, and conventional activities previously known to the industry, specified at a high level of generality, to the judicial exception is not indicative of an inventive concept. MPEP § 2106.05(d)(II) expressly states that the courts have recognized the computer function of receiving or transmitting data over a network, e.g., using the Internet to gather data as a well‐understood, routine, and conventional computer function when it is claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activities. Thus, a person of ordinary skill in the art would readily comprehend that it is well-understood, routine, and conventional in the computing art to attach one or more narrative media files generated in a source code database. Therefore, the limitations remain insignificant extra-solution activities even upon reconsideration and do not amount to significantly more.
Thus, taken alone, the additional elements do not amount to significantly more than the above-identified judicial exception (the abstract idea). Looking at the additional elements as a combination adds nothing that is not already present when looking at the additional elements taken individually. Even when considered in combination, the additional elements represent mere instructions to apply a judicial exception using generic computer components, insignificant extra-solution activities, and therefore do not provide an inventive concept. The claim is not patent eligible.
Claim Interpretation: Under the broadest reasonable interpretation (BRI), the limitations of Claim 18 are presumed to have their plain meaning consistent with the specification as it would be interpreted by one of ordinary skill in the art. See MPEP § 2111.
Step 1: Claim 18 is directed to a computer program product, which is a machine, and falls within one of the statutory categories of invention.
Step 2A, Prong One: Claim 18 recites 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 a modified changed code;
generating one or more test execution stories to highlight any changes between said original code and said modified changed code, and wherein the information about code modification is obtained by reviewing 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.
generating a plurality of narrative media files;
selecting by a reviewer, any of the one or more media files generated and executing any selected media file.
These recited steps, under the broadest reasonable interpretation (BRI), cover performance of the steps in the human mind alone or with the aid of pen and paper. That is, other than reciting:
(1) A 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.
Nothing in the claim precludes the steps from practically being performed in the human mind alone using observation, evaluation, judgment, and opinion or with the aid of pen and paper. For example, the limitation (a) in the context of the claim encompasses a human classifying a modification based on a type of change in the human mind alone using observation, evaluation, judgment, and opinion or with the aid of pen and paper to classify a modification based on a type of change. And the limitation (b) in the context of the claim encompasses a human 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 in the human mind alone using observation, evaluation, judgment, and opinion or with the aid of pen and paper to identify a plurality of unit tests available and select and customize at least one of said unit tests based on classification of said type of code change. See MPEP § 2106.04(a)(2)(III).
If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the human mind alone or with the aid of pen and paper but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Step 2A, Prong Two: This judicial exception is not integrated into a practical application. In particular, the claim recites the additional elements:
(1) A 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 element (1) is 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. The one or more processors, one or more computer-readable memories, storage medium, and program instructions are used as a tool to perform the mental abstract steps of the claim (See MPEP 2106.05(f)).
Also, the claim recites the additional elements:
(2) obtaining information about a requested modification to an original code of a software program;
(3) attaching one or more narrative media files from said plurality of media files generated in a source code database;
The additional element (2-3) is directed to the insignificant extra solution activity of mere data gathering/transmitting/outputting (See MPEP 2106.05(g)). Furthermore, all uses of the recited judicial exception require such data gathering/transmitting/outputting, and, as such, the additional elements do not impose any meaningful limits on the claim. The additional elements amount to necessary data gathering/transmitting/outputting. See MPEP § 2106.05(g).
Step 2B: The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements when considered both individually and as a combination do not amount to significantly more than the abstract idea. As discussed above with respect to integration of the abstract idea into a practical application, the claim recites the additional elements:
(1) A 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 element (1) is 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. The one or more processors, one or more computer-readable memories, storage medium, and program instructions are used as a tool to perform the mental abstract steps of the claim (See MPEP 2106.05(f)).
Also, the claim recites the additional elements:
(1) obtaining information about a requested modification to an original code of a software program;
(2) attaching one or more narrative media files from said plurality of media files generated in a source code database;
The additional elements (2-3) simply append well-understood, routine, and conventional activities previously known to the industry, specified at a high level of generality, to the judicial exception is not indicative of an inventive concept. MPEP § 2106.05(d)(II) expressly states that the courts have recognized the computer function of receiving or transmitting data over a network, e.g., using the Internet to gather data as a well‐understood, routine, and conventional computer function when it is claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activities. Thus, a person of ordinary skill in the art would readily comprehend that it is well-understood, routine, and conventional in the computing art to attach one or more narrative media files generated in a source code database. Therefore, the limitations remain insignificant extra-solution activities even upon reconsideration and do not amount to significantly more.
Thus, taken alone, the additional elements do not amount to significantly more than the above-identified judicial exception (the abstract idea). Looking at the additional elements as a combination adds nothing that is not already present when looking at the additional elements taken individually. Even when considered in combination, the additional elements represent mere instructions to apply a judicial exception using generic computer components, insignificant extra-solution activities, and therefore do not provide an inventive concept. The claim is 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 said
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.
Claim 15 recites the limitation "wherein the information about code modification
is obtained by analyzing events associated with said software program" 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 analyzing events associated with said software program" 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 19 recites the limitation “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” 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” in view of US 11301357 B1 hereinafter “Gacek” and further in view of US 2018009174 A1 hereinafter “Labarre”.
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 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 changed code, and wherein the information about code modification is obtained by reviewing events associated with said software program including variable value change and said information about said code
modification to be made is obtained by reviewing events associated with said software
program including a change in any variable values;
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 changed code (Talluri, Column 25 Lines 7-32, "The procedure may start at step 1605, and continues to step 1610, and generating instructions to highlight software changes by providing missing information from said test execution stories; 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 changed 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, frontend 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 changed 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 changed code, and] wherein the information about code modification is obtained by reviewing events associated with said software program including variable value change and said information about said code modification to be made is obtained by reviewing events associated with said software program including a change in any variable values;
[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 reviewing events associated with said software program including variable value change and said information about said code modification to be made is obtained by reviewing events associated with said software program including a change in any variable values; (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 reviewing 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 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).
The combination of Wefers, Talluri, and Gacek does not teach: generating a plurality of narrative media files; and
attaching one or more narrative media files from said plurality of media files generated in a source code database;
selecting by a reviewer, any of the one or more media files generated and executing any selected media file.
However, in an analogous art Labarre teaches generating a plurality of narrative media files; (Labarre [0022-24], “For example, the unrendered code 100 for an HTML-based project may require different parameters for analysis than the unrendered code 100 for a diagram-based project as can be appreciated. The file type rules 227 may include rules for one or more non-binary-based file types, such as, for example, HTML files, Extensible Markup Language (XML) files, text files, PowerPoint® presentation files, Microsoft Word® files, Visio® files, and/or any other type of non-binary file type. The file type rules 227 can be used by the code rendering engine 218 to analyze and determine differences in the different versions of unrendered code 100. The video rules 233 comprise rules used by the video generator 221 that define how the video content 109 is to be generated. For example, the video rules 233 may define parameters corresponding to the transition time between video frames, the types of transitions between frames (e.g., fade, wipe, etc.), which components are to be included in the video content (e.g., play component, title component, status bar component, etc.), what type of versions are to be included in the video content 109 (e.g., major versions only, all versions, every three versions, etc.), and/or any other type of rule associated with the generation of the video content 109. The video generator 221 may apply the video rules 233 so that the video content 109 is generated according to the video rules 233… The content data 236 may include images, text, code, graphics, audio, video, and/or other content that may be used by the video generator 221 when generating the video content 109. For example, the content data 236 may include the images and code that correspond to the play component 306 (FIG. 3A).”) and
attaching one or more narrative media files from said plurality of media files generated in a source code database; (Labarre [0029-30], “The version control system 251 may be executed to interact with one or more client applications 248 being executed on one or more clients 115 to store and/or access unrendered code of a project being created via the one or more client applications 248. The version control system 251 may correspond to known version control systems such as, for example, GIT®, PERFORCE®, Concurrent Versions System (CVS), and/or any other type of version control system. The data stored in the VCS repository 103 includes, for example, project data 253. The project data 253 may include version data 259 and the file type data 256. The version data 259 corresponds to the different versions of a project. The version data 259 includes the unrendered code 100 and the version metadata 261 for each version. The unrendered code 100 comprises the source code associated with the particular version. The version metadata 261 may comprise information corresponding to the unrendered code 100 … For example, the file type may comprise non-binary-based file types, such as, for example, HTML files, Extensible Markup Language (XML) files, text files, PowerPoint® presentation files, Microsoft Word® files, Visio® files, and/or any other type of non-binary file type.”)
selecting by a reviewer, any of the one or more media files generated and executing any selected media file. (Labarre [0020-21], “The data stored in the data store 215 includes, for example, project video data 224, file type rules 227, video rules 233, content data 236, and potentially other data. The project video data 224 is the data associated with a particular project. The project video data 224 includes version snapshots 239, filter parameters 242, video comments 244, and/or other information. The version snapshots 239 include snapshots of the rendered code 106 for each version of the unrendered code 100 that is to be used for a particular project. The filter parameters 242 include parameters that define characteristics of the content to be included in the video content 109 … The video comments 244 may comprise one or more user comments associated with the rendering of the video content 109 by the client 115. For example, the video content 109 may comprise interactive components (e.g., a text entry box, etc.) that allow a user to input video comments 244 regarding the rendered code 106. These video comments 244 may be stored in the data store 215 and accessed by a developer and/or other user for further review. In some embodiments, the video comments 244 may comprise the text entry and a frame number corresponding to the video frame being rendered by the client 115 when the video comment 244 was entered.”) [Examiner’s Note: A user is able to control the video by inputting comments that alter the data stored in the data store which controls the output contents in the video (including the non-binary file rules that define the video output).]
Therefore, it would have been obvious to one of ordinary skill in the art to have incorporated the teachings of Labarre 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 generating a narrative video, corresponding to user rules and code version history, as in Labarre. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of allowing a user to view the iterative development of a code based project visually through a rendered video content (Labarre [0014]).
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 analyzing events associated with said software program.
However, in an analogous art Gacek teaches: wherein the information about code
modification is obtained by analyzing events associated with said software program. (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).
Claim 18 is directed to a computer program product for data processing corresponding to the computer program product limitations as disclosed in claim 14. Thus, claim 18 is rejected for the same reasons set forth in claim 14.
Claims 3, 16, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Wefers in view of Talluri in view of Gacek in view of Labarre as applied to claims 1, 14, and 18 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, Gacek, and Labarre 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 to have incorporated the teachings of Zhou into the teachings of Wefers in view of Talluri in view of Gacek and further in view of Labarre. 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 generating a narrative video, corresponding to user rules and code version history, as in Labarre, 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 analyzing events associated with said software
program.
However, in an analogous art Gacek teaches [...] by analyzing events associated with
said software program. (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, at a given point in a source code listing [obtained by analyzing 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, Gacek, and Labarre teaches by analyzing events
associated with said software program 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 analyzing events associated with said software program]
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 to have incorporated the teachings of Zhou into the teachings of Wefers in view of Talluri in view of Gacek and further in view of Labarre. 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 generating a narrative video, corresponding to user rules and code version history, as in Labarre, 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 19, the rejection of claim 18 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 […] 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].")
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, Gacek, and Labarre 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 modification has not been made but is scheduled to be made and said information about said code modification 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 to have incorporated the teachings of Zhou into the teachings of Wefers in view of Talluri in view of Gacek and further in view of Labarre. 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 generating a narrative video, corresponding to user rules and code version history, as in Labarre, 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 in view of Labarre, 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, Gacek and Labarre 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 in view of Gacek and further in view of Labarre. 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 generating a narrative video, corresponding to user rules and code version history, as in Labarre, 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 Labarre 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, Labarre, 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 in view of Labarre 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 generating a narrative video, corresponding to user rules and code version history, as in Labarre, 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 in view of Labarre 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, Labarre, 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 in view of Labarre 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 generating a narrative video, corresponding to user rules and code version history, as in Labarre, 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 Labarre 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, Labarre, 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 in view of Labarre 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 generating a narrative video, corresponding to user rules and code version history, as in Labarre, 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 in view of Labarre 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, Gacek, and Labarre 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 in view of Gacek and further in view of Labarre. 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 generating a narrative video, corresponding to user rules and code version history, as in Labarre, 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 in view of Labarre, 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, Gacek and Labarre 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 and further in view of Labarre. 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 generating a narrative video, corresponding to user rules and code version history, as in Labarre,, 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, Gacek and Labarre 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 and further in view of Labarre. 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 generating a narrative video, corresponding to user rules and code version history, as in Labarre, 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 in view of Labarre 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, Gacek and Labarre 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 and further in view of Labarre. 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 generating a narrative video, corresponding to user rules and code version history, as in Labarre, 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, Gacek and Labarre 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 and further in view of Labarre. 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 generating a narrative video, corresponding to user rules and code version history, as in Labarre, 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, Gacek and Labarre 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 and further in view of Labarre. 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 generating a narrative video, corresponding to user rules and code version history, as in Labarre, 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
In the Remarks, Applicant Argues:
The benefits of the suggested technique provided by the amendments are also very novel and have 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 in the 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…The amended claims provide activities that are neither abstract nor can be performed in a human mind or through mental processes. Rather, these are activities that can be performed by a machine and involve training a machine. Furthermore, the current amended claims provide an understanding and application of an amount of data beyond what may be comprehensible by a single person … 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 an understanding and application 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 formulas involved in the present invention as reflected by the amended claims.
Examiner’s Response:
With respect to the applicant’s argument that “The benefits of the suggested technique provided by the amendments are also very novel and have 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…The amended claims provide activities that are neither abstract nor can be performed in a human mind or through mental processes. Rather, these are activities that can be performed by a machine and involve training a machine. Furthermore, the current amended claims provide an understanding and application of an amount of data beyond what may be comprehensible by a single person” Examiner respectfully disagrees. Although understanding the claim language may be aided by explanations the claims are interpreted as broadly as their terms reasonably allow (see MPEP 2111.01(I)). Therefore, nothing in the claim precludes the steps from practically being performed in the human mind alone using observation, evaluation, judgment, and opinion or with the aid of pen and paper. For example, the limitation (a) in the context of the claim encompasses a human classifying a modification based on a type of change in the human mind alone using observation, evaluation, judgment, and opinion or with the aid of pen and paper to classify a modification based on a type of change. And the limitation (b) in the context of the claim encompasses a human 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 in the human mind alone using observation, evaluation, judgment, and opinion or with the aid of pen and paper to identify a plurality of unit tests available and select and customize at least one of said unit tests based on classification of said type of code change. See MPEP § 2106.04(a)(2)(III).
If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the human mind alone or with the aid of pen and paper but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
In the Remarks, Applicant Argues:
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 "allowed" 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:
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.
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.
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.
Conclusion
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
/QING CHEN/Primary Examiner, Art Unit 2191
Prosecution Insights