DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
2. This action is in response to the following communication: Non-provisional Application No. 18/458,944 filed on 08/30/2023.
3. Claims 1-24 are pending.
Claims 1, 9 and 17 are independent claims.
Specification
4. The disclosure is objected to because of the following informalities: The disclosure consists of abbreviations which are not written out the first time they are used (e.g. USB, API, XML, FTP, NFS, TCP/IP, RPC, RMI, HTTP, ASIC, DVD). Abbreviations must be written out the first time they are used in the disclosure, again in the abstract, and again in the claims, as the intent of their meaning is likely to be changed over time.
Appropriate correction is required. The specification should be revised carefully in order to comply with 35 U.S.C. 112(a). 35 U.S.C. 132(a) states that no amendment shall introduce new matter into the disclosure of the invention. Any amendment to the disclosure must be supported by the disclosure as originally filed.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
6. Claims 1, 2, 9, 10, 17 and 18 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Englehart, U.S. Patent No. 7,849,440.
In regards to claim 1, Englehart teaches:
A computer-implemented method of facilitating live feedback on code generation, the method comprising: generating first source code based on at least one user configuration for code generation made via a configuration user interface; presenting the generated first source code in a live preview user interface (column 16, claim 1, see “receiving a user request to define a parameter or a setting of a block in a simulatable block diagram model via a first graphical user interface… automatically generating in real-time based on the determining, using a predictor mechanism, a preview of code representative of the code… automatically displaying in real-time the preview of the code on a preview graphical user interface”). Such settings and generating code is very much the same as such configuration for code generation.
obtaining, via the configuration user interface, a first change to the at least one user configuration for code generation (column 16, claim 1, see “the user can refine the preview of the code by altering the parameter or the setting for the block on the preview graphical user interface”). Such parameter altering is very much the same as such first change.
responsive to the obtaining of the first change to the at least one user configuration: generating second source code based on the first change to at least one user configuration for code generation; presenting the second source code in the live preview user interface by (column 3, lines 2-7, see “the code preview may be presented through the same graphical user interface used to select the settings for the component, or a separate graphical user interface. The code preview may be automatically updated when a user changes a setting, to reflect the impact of the change in the generated code”), (Fig. 7, see “parameters, States when enabling 712, Show output port 714) and (column 4, lines 8-11, see FIG. 7 illustrates an example of a graphical user interface for defining certain settings for an enabled subsystem and providing a code preview relating to the settings, according to one embodiment of the invention) (emphasis added). Such code preview may be automatically updated is very much the same as such code differences.
computing one or more differences between the second source code and the first source code (column 3, lines 2-7, see “the code preview may be presented through the same graphical user interface used to select the settings for the component, or a separate graphical user interface. The code preview may be automatically updated when a user changes a setting, to reflect the impact of the change in the generated code”) and (column 17, lines 37-43, see based on the determining, automatically updating a preview of code representative of the code corresponding to the block in the simulatable block diagram model in response to a user altering the parameter or the setting of the block, wherein the preview of code and the code corresponding to the block are in a different coding format) (emphasis added). Such changes in the generated code is very much the same as such differences between the second source code and the first source code and such the preview of code and the code corresponding to the block are in a different coding format is very much the same as such differences.
visually signaling a correspondence between the first change to the at least one user configuration for code generation and one or more portions of the second source code that are associated with the one or more differences between the second source code and the first source code; and visually distinguishing the one or more portions of the second source code that are associated with the one or more differences between the second source code and the first source code from other portions of the second source code (column 9, lines 32-38, see “the preview may be automatically updated when a user changes a setting in the model to reflect the change in code resulting from the change in the setting. In one embodiment, the latest changes to the code may be presented in a different format (e.g., font, color) to make it easier to see which portions of the preview are directly affected by the latest choices made”) (emphasis added). Such code preview may be automatically updated is very much the same as such code differences and such latest changes to the code may be presented in a different format is very much the same as such differences.
In regards to claim 2, Englehart teaches:
visually signaling a correspondence between the first change to the at least one user configuration for code generation and one or more portions of the second source code that are associated with the one or more differences between the second source code and the first source code comprises presenting, in at least one of (column 9, lines 32-38, see “the preview may be automatically updated when a user changes a setting in the model to reflect the change in code resulting from the change in the setting. In one embodiment, the latest changes to the code may be presented in a different format (e.g., font, color) to make it easier to see which portions of the preview are directly affected by the latest choices made”). Such code preview may be automatically updated is very much the same as such code differences (emphasis added). Such code preview may be automatically updated is very much the same as such code differences and such latest changes to the code may be presented in a different format is very much the same as such differences.
a same blinking pattern, highlight, size, font, or color, both the first change to the at least one user configuration for code generation and the one or more portions of the second source code (column 9, lines 32-38, see the preview may be automatically updated when a user changes a setting in the model to reflect the change in code resulting from the change in the setting. In one embodiment, the latest changes to the code may be presented in a different format (e.g., font, color) to make it easier to see which portions of the preview are directly affected by the latest choices made) (emphasis added). Such code preview may be automatically updated is very much the same as such code differences and such latest changes to the code may be presented in a different format is very much the same as such differences.
In regards to claim 9, Englehart teaches:
A non-transitory computer-readable medium storing contents that cause one or more processors to perform actions comprising: generating first source code based on at least one user configuration for code generation made via a configuration user interface; presenting the generated first source code in a live preview user interface (column 16, claim 1, see “receiving a user request to define a parameter or a setting of a block in a simulatable block diagram model via a first graphical user interface… automatically generating in real-time based on the determining, using a predictor mechanism, a preview of code representative of the code… automatically displaying in real-time the preview of the code on a preview graphical user interface”). Such settings and generating code is very much the same as such configuration for code generation.
obtaining, via the configuration user interface, a first change to the at least one user configuration for code generation (column 16, claim 1, see “the user can refine the preview of the code by altering the parameter or the setting for the block on the preview graphical user interface”). Such parameter altering is very much the same as such first change.
responsive to the obtaining of the first change to the at least one user configuration: generating second source code based on the first change to at least one user configuration for code generation; presenting the second source code in the live preview user interface by (column 3, lines 2-7, see “the code preview may be presented through the same graphical user interface used to select the settings for the component, or a separate graphical user interface. The code preview may be automatically updated when a user changes a setting, to reflect the impact of the change in the generated code”), (Fig. 7, see “parameters, States when enabling 712, Show output port 714) and (column 4, lines 8-11, see FIG. 7 illustrates an example of a graphical user interface for defining certain settings for an enabled subsystem and providing a code preview relating to the settings, according to one embodiment of the invention) (emphasis added). Such code preview may be automatically updated is very much the same as such code differences.
computing one or more differences between the second source code and the first source code (column 3, lines 2-7, see “the code preview may be presented through the same graphical user interface used to select the settings for the component, or a separate graphical user interface. The code preview may be automatically updated when a user changes a setting, to reflect the impact of the change in the generated code”) and (column 17, lines 37-43, see based on the determining, automatically updating a preview of code representative of the code corresponding to the block in the simulatable block diagram model in response to a user altering the parameter or the setting of the block, wherein the preview of code and the code corresponding to the block are in a different coding format) (emphasis added). Such changes in the generated code is very much the same as such differences between the second source code and the first source code and such the preview of code and the code corresponding to the block are in a different coding format is very much the same as such differences.
visually signaling a correspondence between the first change to the at least one user configuration for code generation and one or more portions of the second source code that are associated with the one or more differences between the second source code and the first source code; and visually distinguishing the one or more portions of the second source code that are associated with the one or more differences between the second source code and the first source code from other portions of the second source code (column 9, lines 32-38, see “the preview may be automatically updated when a user changes a setting in the model to reflect the change in code resulting from the change in the setting. In one embodiment, the latest changes to the code may be presented in a different format (e.g., font, color) to make it easier to see which portions of the preview are directly affected by the latest choices made”). Such code preview may be automatically updated is very much the same as such code differences (emphasis added). Such code preview may be automatically updated is very much the same as such code differences and such latest changes to the code may be presented in a different format is very much the same as such differences.
In regards to claim 10, Englehart teaches:
visually signaling a correspondence between the first change to the at least one user configuration for code generation and one or more portions of the second source code that are associated with the one or more differences between the second source code and the first source code comprises presenting, in at least one of (column 9, lines 32-38, see “the preview may be automatically updated when a user changes a setting in the model to reflect the change in code resulting from the change in the setting. In one embodiment, the latest changes to the code may be presented in a different format (e.g., font, color) to make it easier to see which portions of the preview are directly affected by the latest choices made”). Such code preview may be automatically updated is very much the same as such code differences (emphasis added). Such code preview may be automatically updated is very much the same as such code differences and such latest changes to the code may be presented in a different format is very much the same as such differences.
a same blinking pattern, highlight, font, or color, both the first change to the at least one user configuration for code generation and the one or more portions of the second source code (column 9, lines 32-38, see the preview may be automatically updated when a user changes a setting in the model to reflect the change in code resulting from the change in the setting. In one embodiment, the latest changes to the code may be presented in a different format (e.g., font, color) to make it easier to see which portions of the preview are directly affected by the latest choices made) (emphasis added). Such code preview may be automatically updated is very much the same as such code differences and such latest changes to the code may be presented in a different format is very much the same as such differences.
In regards to claim 17, Englehart teaches:
A system, comprising: one or more processors; and a computing device coupled to the one or more processors and configured to perform actions comprising: generating first source code based on at least one user configuration for code generation made via a configuration user interface; presenting the generated first source code in a live preview user interface (column 16, claim 1, see “receiving a user request to define a parameter or a setting of a block in a simulatable block diagram model via a first graphical user interface… automatically generating in real-time based on the determining, using a predictor mechanism, a preview of code representative of the code… automatically displaying in real-time the preview of the code on a preview graphical user interface”). Such settings and generating code is very much the same as such configuration for code generation.
obtaining, via the configuration user interface, a first change to the at least one user configuration for code generation (column 16, claim 1, see “the user can refine the preview of the code by altering the parameter or the setting for the block on the preview graphical user interface”). Such parameter altering is very much the same as such first change.
responsive to the obtaining of the first change to the at least one user configuration: generating second source code based on the first change to at least one user configuration for code generation; presenting the second source code in the live preview user interface by: (column 3, lines 2-7, see “the code preview may be presented through the same graphical user interface used to select the settings for the component, or a separate graphical user interface. The code preview may be automatically updated when a user changes a setting, to reflect the impact of the change in the generated code”), (Fig. 7, see “parameters, States when enabling 712, Show output port 714) and (column 4, lines 8-11, see FIG. 7 illustrates an example of a graphical user interface for defining certain settings for an enabled subsystem and providing a code preview relating to the settings, according to one embodiment of the invention) (emphasis added). Such code preview may be automatically updated is very much the same as such code differences.
computing one or more differences between the second source code and the first source code (column 3, lines 2-7, see “the code preview may be presented through the same graphical user interface used to select the settings for the component, or a separate graphical user interface. The code preview may be automatically updated when a user changes a setting, to reflect the impact of the change in the generated code”) and (column 17, lines 37-43, see based on the determining, automatically updating a preview of code representative of the code corresponding to the block in the simulatable block diagram model in response to a user altering the parameter or the setting of the block, wherein the preview of code and the code corresponding to the block are in a different coding format) (emphasis added). Such changes in the generated code is very much the same as such differences between the second source code and the first source code and such the preview of code and the code corresponding to the block are in a different coding format is very much the same as such differences.
visually signaling a correspondence between the first change to the at least one user configuration for code generation and one or more portions of the second source code that are associated with the one or more differences between the second source code and the first source code; and visually distinguishing the one or more portions of the second source code that are associated with the one or more differences between the second source code and the first source code from other portions of the second source code (column 9, lines 32-38, see “the preview may be automatically updated when a user changes a setting in the model to reflect the change in code resulting from the change in the setting. In one embodiment, the latest changes to the code may be presented in a different format (e.g., font, color) to make it easier to see which portions of the preview are directly affected by the latest choices made”). Such code preview may be automatically updated is very much the same as such code differences (emphasis added). Such code preview may be automatically updated is very much the same as such code differences and such latest changes to the code may be presented in a different format is very much the same as such differences.
In regards to claim 18, Englehart teaches:
visually signaling a correspondence between the first change to the at least one user configuration for code generation and one or more portions of the second source code that are associated with the one or more differences between the second source code and the first source code comprises presenting, in at least one of (column 9, lines 32-38, see “the preview may be automatically updated when a user changes a setting in the model to reflect the change in code resulting from the change in the setting. In one embodiment, the latest changes to the code may be presented in a different format (e.g., font, color) to make it easier to see which portions of the preview are directly affected by the latest choices made”). Such code preview may be automatically updated is very much the same as such code differences.
a same blinking pattern, highlight, font, or color, both the first change to the at least one user configuration for code generation and the one or more portions of the second source code (column 9, lines 32-38, see the preview may be automatically updated when a user changes a setting in the model to reflect the change in code resulting from the change in the setting. In one embodiment, the latest changes to the code may be presented in a different format (e.g., font, color) to make it easier to see which portions of the preview are directly affected by the latest choices made).
Claim Rejections - 35 USC § 103
7. 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 of this title, 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.
8. Claims 3, 11 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Englehart in view of Bienkowski et al., U.S. Patent No. 9,582,400 (hereinafter Bienkowski).
In regards to claims 1, 9, and 17 the rejections above are incorporated respectively.
In regards to claim 3, Englehart teaches:
visually signaling a correspondence between the first change to the at least one user configuration for code generation and one or more portions of the second source code that are associated with the one or more differences between the second source code and the first source code (column 9, lines 32-38, see “the preview may be automatically updated when a user changes a setting in the model to reflect the change in code resulting from the change in the setting. In one embodiment, the latest changes to the code may be presented in a different format (e.g., font, color) to make it easier to see which portions of the preview are directly affected by the latest choices made”). Such code preview may be automatically updated is very much the same as such code differences.
Englehart doesn't explicitly teach:
comprises presenting an animation of at least an arrow, line, or connection from the first change to the one or more portions of the second source code.
However, Bienkowski teaches such use: (column 11, lines 52-55, see in this case, client device 210 may use an animation, such as gradually fading out an old result (e.g., corresponding to the previously evaluated program code) and fading in an updated result (e.g., corresponding to the modified program code), gradually morphing the old result to the updated result, or the like, to provide the updated result for display) and (column 12, lines 8-15, see client device 210 may use an animation, such as gradually fading out the old result, to remove the result from being displayed. In some implementations, the old result may be positioned between other previously-generated results in the code evaluation window (e.g., when a line of program code, positioned between other lines of program code, is deleted)).
Englehart and Bienkowski are analogous art because they are from the same field of endeavor, code display.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teaching of Englehart and Bienkowski before him or her, to modify the system of Englehart to include the teachings of Bienkowski, as a system for providing live code results, and accordingly it would enhance the system of Englehart, which is focused on real-time code preview, because that would provide Englehart with the ability to determine what program code to evaluate and display, as suggested by Bienkowski (column 11, lines 52-55, column 15, lines 61-column 16, line 2).
In regards to claim 11, Englehart teaches:
visually signaling a correspondence between the first change to the at least one user configuration for code generation and one or more portions of the second source code that are associated with the one or more differences between the second source code and the first source code (column 9, lines 32-38, see “the preview may be automatically updated when a user changes a setting in the model to reflect the change in code resulting from the change in the setting. In one embodiment, the latest changes to the code may be presented in a different format (e.g., font, color) to make it easier to see which portions of the preview are directly affected by the latest choices made”). Such code preview may be automatically updated is very much the same as such code differences.
Englehart doesn't explicitly teach:
comprises presenting an animation of at least an arrow, line, or connection between the first change to the at least one user configuration for code generation and the one or more portions of the second source code.
However, Bienkowski teaches such use: (column 11, lines 52-55, see in this case, client device 210 may use an animation, such as gradually fading out an old result (e.g., corresponding to the previously evaluated program code) and fading in an updated result (e.g., corresponding to the modified program code), gradually morphing the old result to the updated result, or the like, to provide the updated result for display) and (column 12, lines 8-15, see client device 210 may use an animation, such as gradually fading out the old result, to remove the result from being displayed. In some implementations, the old result may be positioned between other previously-generated results in the code evaluation window (e.g., when a line of program code, positioned between other lines of program code, is deleted)).
Englehart and Bienkowski are analogous art because they are from the same field of endeavor, code display.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teaching of Englehart and Bienkowski before him or her, to modify the system of Englehart to include the teachings of Bienkowski, as a system for providing live code results, and accordingly it would enhance the system of Englehart, which is focused on real-time code preview, because that would provide Englehart with the ability to determine what program code to evaluate and display, as suggested by Bienkowski (column 11, lines 52-55, column 15, lines 61-column 16, line 2).
In regards to claim 19, Englehart teaches:
visually signaling a correspondence between the first change to the at least one user configuration for code generation and one or more portions of the second source code that are associated with the one or more differences between the second source code and the first source code (column 9, lines 32-38, see “the preview may be automatically updated when a user changes a setting in the model to reflect the change in code resulting from the change in the setting. In one embodiment, the latest changes to the code may be presented in a different format (e.g., font, color) to make it easier to see which portions of the preview are directly affected by the latest choices made”). Such code preview may be automatically updated is very much the same as such code differences.
Englehart doesn't explicitly teach:
comprises presenting an animation of at least an arrow, line, or connection between the first change to the at least one user configuration for code generation and the one or more portions of the second source code.
However, Bienkowski teaches such use: (column 11, lines 52-55, see in this case, client device 210 may use an animation, such as gradually fading out an old result (e.g., corresponding to the previously evaluated program code) and fading in an updated result (e.g., corresponding to the modified program code), gradually morphing the old result to the updated result, or the like, to provide the updated result for display) and (column 12, lines 8-15, see client device 210 may use an animation, such as gradually fading out the old result, to remove the result from being displayed. In some implementations, the old result may be positioned between other previously-generated results in the code evaluation window (e.g., when a line of program code, positioned between other lines of program code, is deleted)).
Englehart and Bienkowski are analogous art because they are from the same field of endeavor, code display.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teaching of Englehart and Bienkowski before him or her, to modify the system of Englehart to include the teachings of Bienkowski, as a system for providing live code results, and accordingly it would enhance the system of Englehart, which is focused on real-time code preview, because that would provide Englehart with the ability to determine what program code to evaluate and display, as suggested by Bienkowski (column 11, lines 52-55, column 15, lines 61-column 16, line 2).
9. Claims 7, 15 and 23 are rejected under 35 U.S.C. 103 as being unpatentable over Englehart in view of Farchi et al., U.S. Patent No. 9,052,983 (hereinafter Farchi).
In regards to claims 1, 9, and 17 the rejections above are incorporated respectively.
In regards to claim 7, Englehart teaches:
the second source code includes a plurality of source code files each corresponding to respective sub-context of the live preview user interface (column 10, lines 61-67, see the illustrative embodiment of the invention allows a user to generate code for a partially specified model. In one embodiment, the code preview field 318 presents only a subset of the code corresponding to the selected portion of the model. For example, the diagramming application can calculate and display the only subset of code that corresponds to or changes in response to a setting or settings of current interest).
Englehart doesn't explicitly teach:
visually distinguishing the one or more portions of the second source code includes visually indicating source code line changes with one or more identifiers of the sub-contexts.
However, Farchi teaches such use: (column 12, lines 12-24, see screen 400 shows a Graphical User Interface (GUI) of an editor in accordance with the disclosed subject matter. Editing pane 410 may be configured to display the source code and annotations. In some exemplary embodiments, the source code is displayed in such a manner indicative of the annotations, such as using different coloring or text style for added, removed or modified text. For example Factorial patch 425 which introduced a line modification to the factorial function, may be displayed to the user using a different coloring for modification section 415. Additionally or alternatively, removed text is displayed using a strikethrough line. Other graphical notations may be used in accordance with user preferences).
Englehart and Farchi are analogous art because they are from the same field of endeavor, code display.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teaching of Englehart and Farchi before him or her, to modify the system of Englehart to include the teachings of Farchi, as a system for source code patches, and accordingly it would enhance the system of Englehart, which is focused on real-time code preview, because that would provide Englehart with the ability to review and approve software patches, as suggested by Farchi (column 12, lines 12-24, column 13, line 66 – column 14, line 14).
In regards to claim 15, Englehart teaches:
the second source code includes a plurality of source code files each corresponding to respective sub-context of the live preview user interface (column 10, lines 61-67, see the illustrative embodiment of the invention allows a user to generate code for a partially specified model. In one embodiment, the code preview field 318 presents only a subset of the code corresponding to the selected portion of the model. For example, the diagramming application can calculate and display the only subset of code that corresponds to or changes in response to a setting or settings of current interest).
Englehart doesn't explicitly teach:
visually distinguishing the one or more portions of the second source code includes visually indicating source code line changes with one or more identifiers of the sub-contexts.
However, Farchi teaches such use: (column 12, lines 12-24, see screen 400 shows a Graphical User Interface (GUI) of an editor in accordance with the disclosed subject matter. Editing pane 410 may be configured to display the source code and annotations. In some exemplary embodiments, the source code is displayed in such a manner indicative of the annotations, such as using different coloring or text style for added, removed or modified text. For example Factorial patch 425 which introduced a line modification to the factorial function, may be displayed to the user using a different coloring for modification section 415. Additionally or alternatively, removed text is displayed using a strikethrough line. Other graphical notations may be used in accordance with user preferences).
Englehart and Farchi are analogous art because they are from the same field of endeavor, code display.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teaching of Englehart and Farchi before him or her, to modify the system of Englehart to include the teachings of Farchi, as a system for source code patches, and accordingly it would enhance the system of Englehart, which is focused on real-time code preview, because that would provide Englehart with the ability to review and approve software patches, as suggested by Farchi (column 12, lines 12-24, column 13, line 66 – column 14, line 14).
In regards to claim 23, Englehart teaches:
the second source code includes a plurality of source code files each corresponding to respective sub-context of the live preview user interface (column 10, lines 61-67, see the illustrative embodiment of the invention allows a user to generate code for a partially specified model. In one embodiment, the code preview field 318 presents only a subset of the code corresponding to the selected portion of the model. For example, the diagramming application can calculate and display the only subset of code that corresponds to or changes in response to a setting or settings of current interest).
Englehart doesn't explicitly teach:
visually distinguishing the one or more portions of the second source code includes visually indicating source code line changes with one or more identifiers of the sub-contexts.
However, Farchi teaches such use: (column 12, lines 12-24, see screen 400 shows a Graphical User Interface (GUI) of an editor in accordance with the disclosed subject matter. Editing pane 410 may be configured to display the source code and annotations. In some exemplary embodiments, the source code is displayed in such a manner indicative of the annotations, such as using different coloring or text style for added, removed or modified text. For example Factorial patch 425 which introduced a line modification to the factorial function, may be displayed to the user using a different coloring for modification section 415. Additionally or alternatively, removed text is displayed using a strikethrough line. Other graphical notations may be used in accordance with user preferences).
Englehart and Farchi are analogous art because they are from the same field of endeavor, code display.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teaching of Englehart and Farchi before him or her, to modify the system of Englehart to include the teachings of Farchi, as a system for source code patches, and accordingly it would enhance the system of Englehart, which is focused on real-time code preview, because that would provide Englehart with the ability to review and approve software patches, as suggested by Farchi (column 12, lines 12-24, column 13, line 66 – column 14, line 14).
10. Claims 8, 16 and 24 are rejected under 35 U.S.C. 103 as being unpatentable over Englehart in view of Fan et al., U.S. Patent No. 9,600,275 (hereinafter Fan).
In regards to claims 1, 9, and 17 the rejections above are incorporated respectively.
In regards to claim 8, Englehart doesn't explicitly teach:
visually distinguishing the one or more portions of the second source code from other portions of the second source code includes presenting a minimap to visually distinguishing at least a subset of the one or more portions that would be hidden in the live preview user interface without the minimap.
However, Fan teaches such use (column 8, lines 56-64, see referring back to FIG. 1, the developer may then open the mapped comment object 130 and the reviewer comments on the source code diff 500 may be displayed. The developer may click on indicator icons 510-514 or comment 516 and the smart source code review tool 122 may present the corresponding sections of the workflow on the graphical user interface 112. Therefore, the developer may be able to visualize the suggestions proposed by the reviewer to the edited source code document), (column 9, lines 27-30, see the developer may browse through source code diff 500 and select a comment 516 or indicator icons 510-514 to be navigated to the corresponding section of workflow diff 400), and (column 8, lines 49-64, see the suggested workflow window 502 may also include comment 516. Comment 516 may be inserted by the reviewer directly to the suggested source code window 502 on source code diff 500 or may be inserted to the suggested workflow window 402 and then mapped by the smart source code peer review tool 122 to the suggested source code window 502… The developer may click on indicator icons 510-514 or comment 516 and the smart source code review tool 122 may present the corresponding sections of the workflow on the graphical user interface 112. Therefore, the developer may be able to visualize the suggestions proposed by the reviewer to the edited source code document).
Englehart and Fan are analogous art because they are from the same field of endeavor, code display.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teaching of Englehart and Fan before him or her, to modify the system of Englehart to include the teachings of Fan, as a system for smart source code review system, and accordingly it would enhance the system of Englehart, which is focused on real-time code preview, because that would provide Englehart with the ability to visually indicate the linked logical groupings when a source code statement is selected, as suggested by Fan (column 8, lines 56-64, column, lines 40-48).
In regards to claim 16, Englehart doesn't explicitly teach:
visually distinguishing the one or more portions of the second source code from other portions of the second source code includes presenting a minimap to visually distinguishing at least a subset of the one or more portions that would be hidden in the live preview user interface without the minimap.
However, Fan teaches such use (column 8, lines 56-64, see referring back to FIG. 1, the developer may then open the mapped comment object 130 and the reviewer comments on the source code diff 500 may be displayed. The developer may click on indicator icons 510-514 or comment 516 and the smart source code review tool 122 may present the corresponding sections of the workflow on the graphical user interface 112. Therefore, the developer may be able to visualize the suggestions proposed by the reviewer to the edited source code document), (column 9, lines 27-30, see the developer may browse through source code diff 500 and select a comment 516 or indicator icons 510-514 to be navigated to the corresponding section of workflow diff 400), and (column 8, lines 49-64, see the suggested workflow window 502 may also include comment 516. Comment 516 may be inserted by the reviewer directly to the suggested source code window 502 on source code diff 500 or may be inserted to the suggested workflow window 402 and then mapped by the smart source code peer review tool 122 to the suggested source code window 502… The developer may click on indicator icons 510-514 or comment 516 and the smart source code review tool 122 may present the corresponding sections of the workflow on the graphical user interface 112. Therefore, the developer may be able to visualize the suggestions proposed by the reviewer to the edited source code document).
Englehart and Fan are analogous art because they are from the same field of endeavor, code display.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teaching of Englehart and Fan before him or her, to modify the system of Englehart to include the teachings of Fan, as a system for smart source code review system, and accordingly it would enhance the system of Englehart, which is focused on real-time code preview, because that would provide Englehart with the ability to visually indicate the linked logical groupings when a source code statement is selected, as suggested by Fan (column 8, lines 56-64, column, lines 40-48).
In regards to claim 24, Englehart doesn't explicitly teach:
visually distinguishing the one or more portions of the second source code from other portions of the second source code includes presenting a minimap to visually distinguishing at least a subset of the one or more portions that would be hidden in the live preview user interface without the minimap.
However, Fan teaches such use (column 8, lines 56-64, see referring back to FIG. 1, the developer may then open the mapped comment object 130 and the reviewer comments on the source code diff 500 may be displayed. The developer may click on indicator icons 510-514 or comment 516 and the smart source code review tool 122 may present the corresponding sections of the workflow on the graphical user interface 112. Therefore, the developer may be able to visualize the suggestions proposed by the reviewer to the edited source code document), (column 9, lines 27-30, see the developer may browse through source code diff 500 and select a comment 516 or indicator icons 510-514 to be navigated to the corresponding section of workflow diff 400), and (column 8, lines 49-64, see the suggested workflow window 502 may also include comment 516. Comment 516 may be inserted by the reviewer directly to the suggested source code window 502 on source code diff 500 or may be inserted to the suggested workflow window 402 and then mapped by the smart source code peer review tool 122 to the suggested source code window 502… The developer may click on indicator icons 510-514 or comment 516 and the smart source code review tool 122 may present the corresponding sections of the workflow on the graphical user interface 112. Therefore, the developer may be able to visualize the suggestions proposed by the reviewer to the edited source code document).
Englehart and Fan are analogous art because they are from the same field of endeavor, code display.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teaching of Englehart and Fan before him or her, to modify the system of Englehart to include the teachings of Fan, as a system for smart source code review system, and accordingly it would enhance the system of Englehart, which is focused on real-time code preview, because that would provide Englehart with the ability to visually indicate the linked logical groupings when a source code statement is selected, as suggested by Fan (column 8, lines 56-64, column, lines 40-48).
Allowable Subject Matter
11. Claims 4-6, 12-14, 20-22 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all the limitation of the base claim and any intervening claims.
The following is a statement of reasons for the indication of allowable subject matter: As per claims 4-6, 12-14, 20-22, prior art of record does not each and/or fairly suggest that “obtaining, via the configuration user interface, a second change to the at least one user configuration for code generation; and responsive to the obtaining of the second change to the at least one user configuration: generating third source code based on the second change to the at least one user configuration for code generation; computing one or more differences between the third source code and at least one of the first source code or the second source code; and presenting the third source code in the live preview user interface by: visually signaling a correspondence between the second change to the at least one user configuration for code generation and one or more portions of the third source code that are associated with the one or more differences between the third source code and the at least one of the first source code or the second source code; and visually distinguishing the one or more portions of the third source code that are associated with the one or more differences between the third source code and the at least one of the first source code or the second source code from other portions of the third source code… presenting the third source code in the live preview user interface comprises retaining, in the presenting of the third source code, the visually distinguishing of the one or more portions of the second source code that are associated with the one or more differences between the second source code and the first source code from other portions of the second source code… the presenting of the third source code and the presenting of the second source code are independent, via respective sub-contexts of the live preview user interface”. The art of record does not expressly disclose such features.
Conclusion
12. The prior art made of record and not relied upon is considered pertinent to
applicant's disclosure.
US Patent Application Publication
Coad et al., 6.993,710, teaches an improved software development tool which displays versions of source code with the indications of the edits in a graphical representation, wherein the graphical representation of the source code is not merely a text representation on a user interface. Each version reflects an instance in an edit history, i.e., reflects the changes made to the source code.
Cicerone 7,661,064, teaches text intra line diffing output may be provided. Based on a comparison of each of a first plurality of lines to a second plurality of lines, a deleted line set and an added line set may be created. The deleted line set may comprise lines selected from the first plurality of lines that are not identical to any line present in the second plurality of lines.
13. Any inquiry concerning this communication or earlier communications from the examiner should be directed to Evral Bodden whose telephone number is 571-272-3455. The examiner can normally be reached on Monday to Friday from 9am to 5pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Cha Do, can be reached at telephone number 571-272-3721. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center and the Private Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from Patent Center or Private PAIR. Status information for unpublished applications is available through Patent Center and Private PAIR to authorized users only. Should you have questions about access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 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) Form at https://www.uspto.gov/patents/uspto-automatedinterview-request-air-form.
/EVRAL E BODDEN/Primary Examiner, Art Unit 2193