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 .
Response to Amendment
This office action is in response to the amendments filed January 26, 2026. Claims are 1, 12, and 14-16 are amended. Claims 13, 17, and 23 are cancelled. Claims 44-46 are newly added. Claims 1-5, 7-10, 12, 14-16, 18, 20-22, and 44-46 are pending and addressed below.
Response to Arguments
Applicant’s arguments regarding the rejection under 35 USC 102 and 103 have been fully considered but are not persuasive.
Applicant’s arguments with respect to claims 1-5, 7-10, 12-13, 15, 18, and 20-23 have been fully considered but are moot because the new ground of rejection does not rely on any combination of references applied in the prior rejection of record for any teaching or matter specifically challenged in the argument. Applicant’s arguments are only directed to the claim amendments, which add new limitations to the claims and are addressed below.
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-5, 7-10, 12, 15, 18, 20-22, and 44-46 are rejected under 35 U.S.C. 103 as being unpatentable over US20210251706A1 (Johnson).
Regarding claim 1, Johnson discloses a robotic medical system, comprising:
one or more medical instruments;
See Fig. 4E, where Johnson discloses one or more medical instruments.
one or more robotic arms, wherein each of the robotic arms is configured to attach to at least one medical instrument of the one or more medical instruments;
See Figs. 4E of Johnson, where robotic arm is configured with at least one medical instrument of the one or more medical instruments.
one or more displays;
See Fig. 1A of Johnson, where user display 130 is shown to display surgical or medical information ([0026]).
one or more processors; and
See Fig. 3 of Johnson, where the figure shows an exemplary variation of system 300 that includes a robotic surgical system ([0033]). The figure discloses the use of processor(s) 310 ([0034]).
memory storing instructions that, when executed by the one or more processors, cause the one or more processors to:
display a three-dimensional (3-D) rendering that includes a graphical representation of the one or more robotic arms;
[0048] of Johnson, “In one embodiment, the GUI runs a “stadium view” app that renders a graphical representation (i.e., not an actual camera view) of current positions of the table and the plurality of robotic arms 160.”, where the stadium view application comprises a display of 3D rendering 910 of a patient on a patient table, and a plurality of robotic arms docked to the patient ([0051]).
update the 3-D rendering in accordance with a pre-programmed workflow corresponding to a procedure, to guide a user through the procedure.
[0058] of Johnson, “In one embodiment, the rendered display of one or more portions of the robotic system can be modified to help guide a surgical team during setup and/or teardown (e.g., pre-operative and/or post-operative procedures) of the robotic surgical system 150, or otherwise tend to the system 150.”
identify a specific portion of a first robotic arm of the one or more robotic arms, the specific portion comprising at least a specific joint or specific link of the first robotic arm;
[0052] of Johnson, “The display of the 3D rendering 910 in the stadium view application may be modified based on status of the rendered objects. For example, as shown in FIG. 4B, the rendering 910 is generally a nominal rendering, with no particular portions of the rendering 910 selected or highlighted. As shown in FIG. 4C, the stadium view application may be configured to highlight at least one of the robotic arms (labeled “2” in FIG. 4C), such as in response to a user selection of the arm. For example, a user may select a particular robotic arm and in response, the stadium view application may display information regarding status of the selected arm. As shown in, for example, FIG. 4E, in response to a user selection of an arm, the stadium view application may also display and/or highlight information relating to the selected arm and its associated tool, such as tool type (e.g., “scissors”), tool status (e.g., operation state such as “cut” or “coagulate”, and/or staples remaining, etc.) and the like.”, where the specific portion identified of a first robotic arm of the one or more robotic arms is a specific link/end effector of the robotic arm.
detect a status state associated with the identified specific portion of the first robotic arm; and
See Fig. 4E of Johnson, where status states associated with the identified specific portion of the first robotic arm are detected.
update the 3-D rendering to display the identified specific portion of the first robotic arm in a visually distinctive manner from other portions of the first robotic arm based on the detected status state.
While Johnson does not explicitly disclose updating the 3-D rendering to display the identified specific portion of the first robotic arm in a visually distinctive manner from other portions of the first robotic arm based on the detected status state, in a different embodiment (Johnson, [0061]), Johnson discloses updating the 3-D rendering to display the identified specific portion of the first robotic arm in a visually distinctive manner from other portions of the first robotic arm (see Fig. 16 of Johnson, where the bottom right window appears to be the end effectors of the tools).
However, one of ordinary skill in the art would find it obvious that the displayed specific portion of the first robotic arm would be updated based on the detected status state as the window in Fig. 16 shows that the end effectors are performing actions pertaining to the end effectors, where Johnson originally discloses that the GUI provides real-time or near-real-time view of the robotic arms intraoperatively ([0055]).
Regarding claim 2, with all the limitations of claim 1, the system further discloses:
a patient support platform; and
See Figs. 1A and 4A of Johnson, where a patient is placed on a platform for a surgery in both platforms.
the memory further includes instructions that, when executed by the one or more processors, cause the one or more processors to:
execute a spatial configuration adjustment of the one or more robotic arms relative to the patient support platform in accordance with the workflow; and
[0057] “Movement of the arms can be done, for example, using a user input device (e.g., remote control). FIG. 7 is an illustration of a graphical user interface of an embodiment that includes a stadium view application that provides an instruction on how to drape robotic arms.”
update the 3-D rendering to reflect positional changes of the one or more robotic arms according to the spatial configuration adjustment.
[0049] “The current positions can be derived from real-time or near real-time information relating to a current position of the table and the plurality of robotic arms 160. For example, the graphical representation (sometimes referred to herein as a “rendering”) of a robotic arm may be based at least in part on one or more kinematic algorithms that control the robotic arm. The one or more kinematic algorithms may be fed into a modeling module that transforms the kinematic information into a rendered two- or three-dimensional model.”
Regarding claim 3, with all the limitations of claim 2, the system further discloses:
wherein the memory further includes instructions that, when executed by the one or more processors, cause the one or more processors to:
cause movement of the patient support platform from a first position to a second position in accordance with the workflow; and
See Figs. 5-8 of Johnson. The figures show that the patient support platform moves the robotic arms from a first position to a second position in accordance to the workflow shown on the left of the figures.
update the 3-D rendering to reflect the movement of the patient support platform.
See above limitation.
Regarding claim 4, with all the limitations of claim 1, the system further discloses:
one or more adjustable arm supports that are movably coupled to the one or more robotic arms; and the memory further includes instructions that, when executed by the one or more processors, cause the one or more processors to:
cause movement of the one or more adjustable arm supports relative to the one or more robotic arms in accordance with the workflow; and
See Fig. 7 of Johnson. The GUI also has instructions according to the workflow that details moving the arms.
update the 3-D rendering to reflect a positional change of the one or more adjustable arm supports.
See Fig. 8 of Johnson. The 3-D rending from Fig.7 shifted in light of the movement instructions to the rending shown in Fig. 8.
Regarding claim 5, with all the limitations of claim 1, the system further discloses:
wherein the memory further includes instructions that, when executed by the one or more processors, cause the one or more processors to:
receive user selection of a portion of the 3-D rendering; and
[0052] of Johnson, “As shown in FIG. 4C, the stadium view application may be configured to highlight at least one of the robotic arms (labeled “2” in FIG. 4C), such as in response to a user selection of the arm.”
in accordance with the user selection, display the user-selected portion in a visually distinctive manner from other portions of the 3-D rendering.
See Fig. 4C of Johnson. The selected robotic arm (labeled “2”) is shown in a darker color than the rest of them.
Regarding claim 7, with all the limitations of claim 1, the system further discloses:
wherein the pre-programmed workflow includes a pre-operative stage, wherein a step of the pre-operative stage includes deploying the one or more robotic arms from a stowed position into a deployed position.
See at least Fig. 7. The figure shows that the surgery is in a patient preparation and arm setup stage with Fig. 7 in particular showing that the arms are being initiated.
Regarding claim 8, with all the limitations of claim 1, the system further discloses:
wherein the pre-programmed workflow includes a pre-operative stage, wherein a step of the pre-operative stage includes moving the one or more robotic arms into a draping pose.
[0057] of Johnson, “FIG. 7 is an illustration of a graphical user interface of an embodiment that includes a stadium view application that provides an instruction on how to drape robotic arms.”
Regarding claim 9, with all the limitations of claim 1, the system further discloses:
wherein the pre-programmed workflow includes a pre-operative stage, wherein a step of the pre-operative stage includes placing the one or more robotic arms in a docked state.
[0057] of Johnson, “FIG. 10 is an illustration of a graphical user interface of an embodiment that includes a stadium view application that provides an instruction on how to deploy robotic arms to a dock arms position.”
Regarding claim 10, with all the limitations of claim 1, the system further discloses:
an adjustable arm support that is movably coupled to the one or more robotic arms; and
See Fig. 10 of Johnson. The figure shows that the arms are movably coupled to a support on the platform.
a patient support platform,
See Fig. 10 of Johnson. The patient lies on a support platform in the figure, where the figure shows a 3D representation of a stadium view of the procedure to take ([0057]).
wherein the pre-programmed workflow includes an intra-operative stage, wherein a step of the intra-operative stage includes leveling the adjustable arm support and the patient support platform.
See Fig. 13 of Johnson. The arms are shown to be leveled with the patient support platform.
Regarding claim 12, with all the limitations of claim 1, the system further discloses:
wherein the memory further includes instructions that, when executed by the one or more processors, cause the one or more processors to:
identify a step of the procedure to which the robotic medical system corresponds;
See Fig. 4A of Johnson. The right-hand side of the figure shows a list of steps and procedures associated with the operation performed.
cause movement of a portion of a second robotic arm of the one or more robotic arms in accordance with the identified step; and
While the list of steps in Fig. 4A of Johnson only list generic steps, one of ordinary skill in the art would find it obvious to fill in steps associated with a specific surgery and operation to the GUI instructions listed for aiding the operator of robotic system such as the options in Fig. 4E, where each arm has its own function in the figure.
during the movement, update the 3-D rendering to:
display the portion of the second robotic arm with a first visual representation that is visually distinct from other portions of the second robotic arm; and
In light of the rationale above, Fig. 4E has a visually distinct arm with robotic arm “2” being highlighted compared to the rest of the arms.
display a positional change of the portion of the second robotic arm according to the movement.
While the figure does not explicitly show the positional change, one of ordinary skill in the art would find it obvious to have this view change with respect to the real robotic motion in a similar fashion to the GUI of Figs. 5-8.
Regarding claim 15, with all the limitations of claim 1, the system further discloses:
wherein the memory further includes instructions that, when executed by the one or more processors, cause the one or more processors to:
in accordance with the movement, produce an audio signal.
In light of the rationale of claim 12, see Fig. 4D of Johnson. Johnson discloses that the alert 930 may also be accompanied with an audio alert to the user to indicate the collision ([0054]).
Regarding claim 18, with all the limitations of claim 1, the system further discloses:
an adjustable arm support that is movably coupled to the one or more robotic arms are coupled; and
See the rationale of claim 4.
the memory further includes instructions that, when executed by the one or more processors, cause the one or more processors to:
identify a step of procedure to which the robotic medical system corresponds;
See the rationale of claim 12.
cause movement of the adjustable arm support in accordance with the identified step; and
See the rationale of claim 12.
during the movement, update the 3-D rendering to:
display the adjustable arm support with a first visual representation that is visually distinct from the one or more robotic arms; and
See Figs. 13-14 of Johnson. The arm supports are shown in between two configurations of “stowed away” in Fig. 13 and “destination position” in Fig. 14.
display a positional change of the adjustable arm support according to the movement.
See Figs. 13-14 of Johnson. The arm supports are shown to have a change in their rotational position.
Regarding claim 20, with all the limitations of claim 1, the system further discloses:
a patient support platform;
See the rationale of claim 2.
the memory further includes instructions that, when executed by the one or more processors, cause the one or more processors to:
identify a step of procedure to which the robotic medical system corresponds;
See the rationale of claim 12.
cause movement of at least a portion of the patient support platform; and
[0053] of Johnson, “Similarly, the position of the patient table may be adjusted via adjustment of the rendered patient table within the stadium view app.”
during the movement, update the 3-D rendering to:
display the at least a portion of the patient support platform with a first visual representation that is visually distinct from the one or more robotic arms and/or other portions of the patient support platform; and
See Figs. 5-8 of Johnson. The patient support platform has a first visual representation visually distinct from the robotic arms.
display a positional change of the at least a portion of the patient support platform according to the movement.
While Johnson do not explicitly disclose updating the 3-D rendering of the patient table by the use of the rendered patient table within the stadium view app, one of ordinary skill in the art would find it obvious to update the support platform in light of any motion of the support platform as the stadium view is a graphical representation of the operating room at the time where accurate surgery requires proper knowledge of the positions of all relevant apparatuses.
Regarding claim 21, with all the limitations of claim 20, the system further discloses:
wherein displaying the at least a portion of the patient support platform with the first visual representation comprises displaying the at least a portion of the patient support platform with a first color that is distinct from a color corresponding to the one or more robotic arms.
See Fig. 4C. In the figure, the patient support platform of a first visual representation is of a different color corresponding to robotic arm “2”.
Regarding claim 22, with all the limitations of claim 1, the system further discloses:
wherein the memory further includes instructions that, when executed by the one or more processors, cause the one or more processors to:
in accordance with a determination that the robotic medical system is executing a specific step of the workflow, adjust a field of view of a virtual camera of the robotic medical system to include a specific portion of the one or more robotic arms.
See Figs. 5-7 of Johnson. As the steps progress from Fig. 5 to Fig. 7, the field of view is zoomed out further to better include the portions of the robotic arms.
Regarding claim 44, Johnson discloses a robotic medical system, comprising:
one or more robotic arms, wherein a distal end of each of the robotic arms is configured to attach to a medical instrument;
See Figs. 4E of Johnson, where robotic arm is configured with at least one medical instrument of the one or more medical instruments.
one or more displays;
See Fig. 1A of Johnson, where user display 130 is shown to display surgical or medical information ([0026]).
one or more processors; and
See Fig. 3 of Johnson, where the figure shows an exemplary variation of system 300 that includes a robotic surgical system ([0033]). The figure discloses the use of processor(s) 310 ([0034]).
memory storing instructions that, when executed by the one or more processors, cause the one or more processors to:
display a three-dimensional (3-D) rendering that includes a graphical representation of the one or more robotic arms;
[0048] of Johnson, “In one embodiment, the GUI runs a “stadium view” app that renders a graphical representation (i.e., not an actual camera view) of current positions of the table and the plurality of robotic arms 160.”, where the stadium view application comprises a display of 3D rendering 910 of a patient on a patient table, and a plurality of robotic arms docked to the patient ([0051]).
display a rendering that includes a graphical representation of one or more medical instruments corresponding to the one or more robotic arms;
update the 3-D rendering in accordance with a pre-programmed workflow, wherein the pre-programmed workflow includes a pre-operative stage, an intra- operative stage, and a post-operative stage;
Johnson discloses updating the 3-D rendering in accordance with a pre-programmed workflow, wherein the pre-programmed workflow includes a pre-operative stage, an intra-operative stage ([0055], “In the above examples, the stadium view was used intraoperatively during surgery to provide the surgeon (using a display on the bridge 100) and/or staff (e.g., using the display 134 on the control tower 133 or the display 132 located bedside adjacent to/proximate the patient) with a real-time or near-real-time view of the position of the robotic arms 160 to warn of possible collisions between the arms 160 and/or other objects. The above examples also show that the stadium view can be used by the surgeon during surgery to guide the staff during instrument swaps on the robotic arms”, where the above examples appear to refer to at least Figs. 4A-4E), and a post-operative stage ([0058], “In one embodiment, the rendered display of one or more portions of the robotic system can be modified to help guide a surgical team during setup and/or teardown (e.g., pre-operative and/or post-operative procedures) of the robotic surgical system 150, or otherwise tend to the system 150.”).
identify a step of the pre-programmed workflow to which the robotic medical system corresponds;
See Fig. 4A of Johnson, where a series of steps of a procedure is provided as an exemplary case of a GUI.
cause movement of a portion of a first robotic arm of the one or more robotic arms in accordance with the identified step; and
[0058] of Johnson, “In one embodiment, the rendered display of one or more portions of the robotic system can be modified to help guide a surgical team during setup and/or teardown (e.g., pre-operative and/or post-operative procedures) of the robotic surgical system 150, or otherwise tend to the system 150. That is, in addition to displaying a graphical representation of current positions of the table and plurality of robotic arms 160, the GUI can display user-guidance information on how to move the plurality of robotic arms 160 to a different position (e.g., an arm setup position or an arm teardown position). “, where [0057] discloses the movement of the arms by a user input device (e.g., remote control).
during the movement, update the 3-D rendering to display a positional change of the portion of the first robotic arm according to the movement.
See the above limitation citing to [0058] of Johnson regarding displaying a graphical representation of current positions.
Regarding claim 45, Johnson discloses a robotic medical system, comprising:
one or more robotic arms, wherein a distal end of each of the robotic arms is configured to attach to a medical instrument;
See Figs. 4E of Johnson, where robotic arm is configured with at least one medical instrument of the one or more medical instruments.
one or more displays;
See Fig. 1A of Johnson, where user display 130 is shown to display surgical or medical information ([0026]).
one or more processors; and
See Fig. 3 of Johnson, where the figure shows an exemplary variation of system 300 that includes a robotic surgical system ([0033]). The figure discloses the use of processor(s) 310 ([0034]).
memory storing instructions that, when executed by the one or more processors, cause the one or more processors to:
display a three-dimensional (3-D) rendering that includes a graphical representation of the one or more robotic arms;
[0048] of Johnson, “In one embodiment, the GUI runs a “stadium view” app that renders a graphical representation (i.e., not an actual camera view) of current positions of the table and the plurality of robotic arms 160.”, where the stadium view application comprises a display of 3D rendering 910 of a patient on a patient table, and a plurality of robotic arms docked to the patient ([0051]).
display a rendering that includes identification of one or more instruments to be attached to the one or more robotic arms;
[0058] of Johnson, “In one embodiment, the rendered display of one or more portions of the robotic system can be modified to help guide a surgical team during setup and/or teardown (e.g., pre-operative and/or post-operative procedures) of the robotic surgical system 150, or otherwise tend to the system 150.”
update the 3-D rendering in accordance with a pre-programmed workflow, wherein the pre-programmed workflow includes a pre-operative stage, an intra- operative stage, and a post-operative stage;
Johnson discloses updating the 3-D rendering in accordance with a pre-programmed workflow, wherein the pre-programmed workflow includes a pre-operative stage, an intra-operative stage ([0055], “In the above examples, the stadium view was used intraoperatively during surgery to provide the surgeon (using a display on the bridge 100) and/or staff (e.g., using the display 134 on the control tower 133 or the display 132 located bedside adjacent to/proximate the patient) with a real-time or near-real-time view of the position of the robotic arms 160 to warn of possible collisions between the arms 160 and/or other objects. The above examples also show that the stadium view can be used by the surgeon during surgery to guide the staff during instrument swaps on the robotic arms”, where the above examples appear to refer to at least Figs. 4A-4E), and a post-operative stage ([0058], “In one embodiment, the rendered display of one or more portions of the robotic system can be modified to help guide a surgical team during setup and/or teardown (e.g., pre-operative and/or post-operative procedures) of the robotic surgical system 150, or otherwise tend to the system 150.”).
identify a specific portion of a first robotic arm of the one or more robotic arms, the specific portion comprising a specific joint or a specific link of the first robotic arm;
[0052] of Johnson, “The display of the 3D rendering 910 in the stadium view application may be modified based on status of the rendered objects. For example, as shown in FIG. 4B, the rendering 910 is generally a nominal rendering, with no particular portions of the rendering 910 selected or highlighted. As shown in FIG. 4C, the stadium view application may be configured to highlight at least one of the robotic arms (labeled “2” in FIG. 4C), such as in response to a user selection of the arm. For example, a user may select a particular robotic arm and in response, the stadium view application may display information regarding status of the selected arm. As shown in, for example, FIG. 4E, in response to a user selection of an arm, the stadium view application may also display and/or highlight information relating to the selected arm and its associated tool, such as tool type (e.g., “scissors”), tool status (e.g., operation state such as “cut” or “coagulate”, and/or staples remaining, etc.) and the like.”, where the specific portion identified of a first robotic arm of the one or more robotic arms is a specific link/end effector of the robotic arm.
detect a status state associated with the identified specific portion of the first robotic arm; and
See Fig. 4E of Johnson, where status states associated with the identified specific portion of the first robotic arm are detected.
update the 3-D rendering to display the identified specific portion of the first robotic arm in a visually distinctive manner from other portions of the first robotic arm and from the representation of the patient based on the detected status state.
While Johnson does not explicitly disclose updating the 3-D rendering to display the identified specific portion of the first robotic arm in a visually distinctive manner from other portions of the first robotic arm and from the representation of the patient based on the detected status state, in a different embodiment (Johnson, [0061]), Johnson discloses updating the 3-D rendering to display the identified specific portion of the first robotic arm in a visually distinctive manner from other portions of the first robotic arm (see Fig. 16 of Johnson, where the bottom right window appears to be the end effectors of the tools).
However, one of ordinary skill in the art would find it obvious that the displayed specific portion of the first robotic arm would be updated based on the detected status state as the window in Fig. 16 shows that the end effectors are performing actions pertaining to the end effectors, where Johnson originally discloses that the GUI provides real-time or near-real-time view of the robotic arms intraoperatively ([0055]).
Regarding claim 46, with all of the limitations of claim 1, the system further discloses, wherein the memory further includes instructions that, when executed by the one or more processors, cause the one or more processors to:
display a rendering that includes a graphical representation of the one or more medical instruments.
See Fig. 16 of Johnson, where a graphical representation of the one or more medical instruments is rendered in the bottom right of the figure.
36. Claims 14 and 16-17 are rejected under 35 U.S.C. 103 as being unpatentable over US20210251706A1 (Johnson) in view of Burns US20190183591A1 (Burns).
Regarding claim 14, with all the limitations of claim 1, the system further discloses:
wherein the memory further includes instructions that, when executed by the one or more processors, cause the one or more processors to during the movement, display a progress bar for visualizing progress of the identified step that is being executed.
While Johnson does not identify a progress bar for visualizing progress of the identified step during a movement of an arm, Burns discloses a robotic surgical system with the use of a progress bar that “fills” to indicate elapsed time and anticipated remaining time for an action, where the action in their case would be the clamping of a tool ([0123] of Burns).
One of ordinary skill in the art would find it obvious, prior to the applicant’s effective filing date, to integrate the progress bar of Burns as visualizing progress of the identified step being executed allows an operator of the system to know how much longer a step is taking, giving them a timeframe of when to proceed further with the operation.
Regarding claim 16, with all the limitations of claim 1, the system further discloses:
wherein the memory further includes instructions that, when executed by the one or more processors, cause the one or more processors to:
determine whether the step has been completed; and
While Johnson does not disclose the completion of a step, in light of the rationale of claim 14, Burns discloses a flowchart of activities associated with a tool where the icons change in response to completion ([0124]).
One of ordinary skill in the art would find it obvious, prior to the applicant’s effective filing date, to combine the system of Burns and Johnson as an indicator when steps are completed would help operators understand when the next step should be started.
in accordance with a determination that the step has been completed, update the 3-D rendering to display the portion of the first robotic arm in a second visual representation that is distinct from the first visual representation.
As Johnson discloses the updating of a 3-D rending in the disclosed display, one of ordinary skill in the art would find it obvious to update the visual representation of robotic arm from a first to a second visual representation to better display the next step such as in Figs. 6 and 7 of Johnson.
Regarding claim 17, with all the limitations of claim 16, the system further discloses:
wherein the first visual representation corresponds to a first color and the second visual representation corresponds to a second color that is distinct from the first color.
In light of the rationale of claim 16, see Fig. 4C of Johnson. One of ordinary skill in the art would find it obvious to try a color based distinct visual representation in a similar fashion to the figure.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAEWOOK JUNG whose telephone number is (571)272-5470. The examiner can normally be reached Monday - Friday, 9:00 AM - 5:00 PM..
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, Wade Miles can be reached on (571) 270-7777. 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.
/J.J./Examiner, Art Unit 3656
/WADE MILES/Supervisory Patent Examiner, Art Unit 3656
Prosecution Insights