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 .
Notice to Applicant
Receipt of Applicant’s Amendment filed September 15, 2026 is acknowledged.
Response to Amendment
Claims 1, 5, and 13 have been amended. Claims 2-4, 6-12, 14-15, and 17-21 have not been modified. Claims 16 and 22-24 have been cancelled. Claims 1-15 and 17-21 are pending and are provided to be examined upon their merits.
Response to Arguments
Applicant’s arguments filed on September 15, 2026 have been considered but are not fully persuasive. Response has been provided below.
Applicant argues 35 U.S.C. §112 Rejections, pg. 6 of Remarks:
Applicant argues that the term “DICOM schema” is clearly understood to refer to the “DICOM-RT 2nd Generation schema, where a single workflow relates to a ‘phase’ of a treatment” ([0025] of Applicant specification).
Examiner notes that the broadest reasonable interpretation of the term “Digital Imaging and Communications in Medicine (DICOM) schema” encompasses more than the narrower interpretation presented in Applicant specification. Examiner suggests amending the claim limitation to only recite “according to DICOM-RT 2nd Generation schema, where a single workflow relates to a "phase" of a treatment” in accordance with Applicant argument.
Thus, the rejection is maintained.
Applicant argues 35 U.S.C. §102 and 103 Rejections, pg. 7 of Remarks:
Applicant argues that Mahesh does not teach the amended claim limitation of merging content from an atomic application into distinct elements of a separate UI environment. Examiner respectfully disagrees.
In support of Applicant amendment, [0058] of Applicant specification merely recites: “Upon operation by the user, the WB may identify the appropriate atomic application and present information from the atomic application within the same WB environment. Thereby, the WB may provide a UI which merges content associated with the atomic application with the visually perceptible elements of the WB itself, thereby preserving the "look and feel" of the overall WB environment.”
As noted by Applicant, [0046] of Mahesh states “the container 110 may be used to provide the same ‘look and feel’ (e.g., buttons, menus, display) for all applications in the container” and that “the container 110 may arrange information, applications, and/or interactions in a certain layout and/or format.”
Under the broadest reasonable interpretation of the term “merging content”, Mahesh’s teaching of arranging different applications in a certain layout to provide the same ‘look and feel’ is the same as merging as taught by Applicant specification.
Thus, Examiner maintains the prior art rejection.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 2 and 14 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 2 and 14 recite “a single patient chart view organized according to a Digital Imaging and Communications in Medicine (DICOM) schema”. However, a Digital Imaging and Communications in Medicine (DICOM) schema typically refers to a technical standard for digital storage and transmission of medical images and does not refer to a method of organizing information on a patient chart, such that it is unclear what the scope of the specific claimed arrangement of information entails.
For the purpose of examination, Examiner will interpret this claim limitation to refer to any patient chart user interface that may output DICOM-compliant images relevant to the patient.
Claim Rejections - 35 USC § 102
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 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.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1 and 13 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Mahesh (US 20060111936).
Regarding claim 1, Mahesh teaches a radiation oncology workflow management system comprising:
an interactive graphical interface configured to affect a workflow operation and workstation behavior for a radiation oncology patient-specific workflow ([0003], “workspaces, such as a radiology workspace” [0019], “the present invention provide a method and system for improved medical workflow and interfacing in a healthcare environment using a unified interface framework. In an embodiment, the system includes a unified user interface allowing access to a plurality of medical components, wherein the unified user interface coordinates the plurality of medical components to provide unified access and display of information from the plurality of medical components.” [0054], “a unified user interface may be implemented using a set of instructions on a computer-readable storage medium, such as a PACS workstation or other computing system.” [0033], “Thus, from the same workstation using the system 100, a user may look at a RIS for relevant prior reports, search a PACS for relevant prior images, and/or examine a LIS and/or HIS for specific information, all based on context sharing and rules.”). Examiner notes that “radiation oncology” is mere descriptive language for an intended target and has no functional limitations on the claims; MPEP 2111.05.
and a particularly programmed processor including computer program instructions, the instructions, when executed by the processor ([0054], “a unified user interface may be implemented using a set of instructions on a computer-readable storage medium, such as a PACS workstation or other computing system.”), cause the system to perform:
displaying a window containing a user interface (UI) environment on a computer screen ([0051], “First, at step 210, a unified user interface is provided for a user.”),
parsing an input received from a user via the UI environment, thereby to determine which of a plurality of atomic application functions is indicated by the input ([0052], “At step 220, a request for access is received at the unified user interface. For example, a user requests patient information from a RIS via the unified interface. Then, at step 230, the request is automatically routed to the appropriate application and/or information system.” [0011], “a practitioner may use different applications, such as a radiologist information system (RIS), picture archiving and communication system (PACS), electronic medical record (EMR), healthcare information system (HIS), and laboratory information system (LIS), to search for patients and examine the information electronically.” [0022], “the plurality of applications and/or the result may be filtered based on one or more rules.”). Examiner interprets processing of the request to encompass parsing as Applicant specification does not further detail what parsing entails.
automatically interacting with an atomic application associated with the atomic application function determined to be indicated by the input ([0052], “Then, at step 230, the request is automatically routed to the appropriate application and/or information system. For example, the interface contacts or queries the RIS or RIS interface to request application execution and/or data retrieval, for example.”), and
automatically displaying information received from the atomic application via the UI environment by merging content associated with the atomic application with elements of the UI environment ([0053], “At step 240, a result is returned from the application to the unified interface. In an embodiment, the result is returned in a predefined layout according to user or system preferences. The result may be an application execution and/or retrieved information, for example.” [0046], “The container 110 may be used to provide the same "look and feel" (e.g., buttons, menus, display) for all applications in the container 110. For example, a physician sees a same application feel across multiple medical applications… the container 110 may arrange information, applications, and/or interactions in a certain layout and/or format.”). Examiner notes the teachings of Mahesh are functionally analogous as the claim limitation, as [0045] of Applicant specification recites the same advantage as Mahesh (“Upon operation by the user, the WB may identify the appropriate atomic application and present information from the atomic application within the same WB environment. Thereby, the WB may provide a UI which merges content associated with the atomic application with the visually perceptible elements of the WB itself, thereby preserving the "look and feel" of the overall WB environment.”).
Regarding claim 13, this claim is rejected for the same reasons as claim 1. Mahesh further teaches a non-transitory computer-readable medium storing instructions that, when executed by a processor of a computing machine, cause the computing machine to be particularly programmed to perform operations ([0029], “The components of the system 100 may communicate via wired and/or wireless connections on one or more processing units, such as computers, medical systems, storage devices, custom processors, and/or other processing units. In an embodiment, the components of the system 100 are integrated into a single unit.” [0054], “a unified user interface may be implemented using a set of instructions on a computer-readable storage medium, such as a PACS workstation or other computing system.” Claim 16, “A computer-readable storage medium including a set of instructions for a computer”).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
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 2 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Mahesh (US 20060111936) in view of Geller (US 20190237189).
Regarding claim 2, Mahesh teaches the system of claim 1. Mahesh further teaches a single patient chart view organized according to a Digital Imaging and Communications in Medicine (DICOM) schema ([0006], “For example, during surgery, medical personnel may access patient information, such as images of a patient's anatomy, that are stored in a medical information system.” [0036], “the user access relevant prior history for a patient (e.g., images and reports).” [0044], “Perspectives may be used to logically group different applications. Rules, configuration options, and/or other criteria may be defined in order to define perspectives. Perspectives may be defined for images, examination results, laboratory data, patient history data, structured report data, DICOM data, and/or other data, for example.”).
Mahesh does not teach wherein the UI environment includes a view selected from a racetrack view including a plurality of individual tasks represented as state-specifying interactive pill icons.
However, Geller wherein the UI environment includes a view selected from a racetrack view including a plurality of individual tasks represented as state-specifying interactive pill icons (Figs. 7D and 7J, Table 1, “3. Confirm surgery start is available for the user to take action. Slide button interaction to confirm task. The card will slide away once confirmed. 9A In surgery overview The in surgery overview displays several possible flows while the patient is in the OR. 1. If there are no service requests, proceed to In Surgery (FIG. 9B.) 2. If there is a service request with OR Hold, proceed to In Surgery - OR Hold (FIG. 9H) 3. If there is a service request with OR Release, proceed to In Surgery - OR Release (FIG. 9O) 9B In Surgery Confirm start closing is available for the user to take action. Slide button interaction to confirm task.”). The racetrack view for a multitude of patients can be seen in Fig. 7D, below. Fig. 7J is provided to show that each icon corresponds to tasks, as supported by Table 1. Regarding the pill icon, Examiner notes that the pill shape is nonfunctional descriptive material and does not provide a functional relationship with the printed manner; MPEP 2111.05. As such, Examiner notes that there is no functional difference between a rectangular icon and a pill icon.
PNG
media_image1.png
778
387
media_image1.png
Greyscale
PNG
media_image2.png
767
370
media_image2.png
Greyscale
Mahesh in view of Geller are considered analogous to the claimed invention because they are in the field of patient management. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Mahesh with Geller for the advantage of “improving workflow in medical systems and environments” (Geller; [0003]).
Regarding claim 14, this claim is rejected for the same reasons as claim 2.
Claims 3-4 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Mahesh (US 20060111936) in view of Riker (US 20050111621).
Regarding claim 3, Mahesh teaches the system of claim 1. Mahesh further teaches wherein the atomic application is an electronic medical record application ([0029], “ electronic medical record (EMR) 133,” [0047], “For example, a radiologist accessing RIS, PACS, EMR and other clinical systems accesses one container with a selected skin. All application components are hosted within the container.”).
Mahesh does not teach wherein the UI environment includes an intake form including a first field on which the user may add or edit a patient information and/or a treatment information
However, Riker does wherein the UI environment includes an intake form including a first field on which the user may add or edit a patient information and/or a treatment information ([0166], “For at least one target, the user would specify the desired dose level in the text entry field 153 corresponding to "goal dose." This may be accomplished by entering a numeral input in the text entry field 153 for each of the at least one targets selected by the drop-down menu 151. For example, the user would input numeral 67.25 in the goal dose field 157 for the prostate.”).
Mahesh in view of Riker are considered analogous to the claimed invention because they are in the field of patient workflows. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Mahesh with Riker for the advantage of providing a “system capable of flexible adjustments” (Riker; [0030]).
Regarding claim 4, Mahesh teaches the system of claims 1 and 3. Mahesh does not teach wherein the intake form includes a second field on which the user may enter a patient treatment planning simulation.
However, Riker does teach wherein the intake form includes a second field on which the user may enter a patient treatment planning simulation ([0070], “FIGS. 2A-C illustrate methods for creating a radiation treatment plan incorporating the system 30 of the present invention, FIG. 2A illustrating a general overall flow chart. The system 30 can be implemented in two modes: the first is the FIG. 2B "Plan Tweak" mode wherein the system 30 receives an externally generated precedent plan, adjusts optimization parameters in order to simulate the plan, and then allows for iterative manipulation.” [0085], “Planning system tools, such as those described below, can then be applied to tweak that plan. These new tools can give the user the ability to make more specific requests of the computer planning apparatus, thus providing fine grained, more fluid control over the dose distribution.” [0088], “The user is provided a GUI 150 and software 36 which includes algorithms for data entry and manipulation of information displayed on the GUI 150. The GUI 150 can display interactive tools, such as, for example, drop-down menus 151, 151', checkboxes 152, 152', text field boxes, such as, for example, target "goal dose" 153 or structure "dose limit" 153', slide controls 154, 154' for parameters such as target "homogeneity" or structure "importance," respectively, and a screen pointer 163 which, through use of an input device, can manipulate isodose contours 162 displayed in image 161 and/or DVH curves 175.”).
Mahesh in view of Riker are considered analogous to the claimed invention because they are in the field of patient workflows. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Mahesh with Riker for the advantage of “adjust[ing] optimization parameters in order to simulate the plan” (Riker; [0070]).
Regarding claim 15, this claim is rejected for the same reasons as claim 3.
Claims 5 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Mahesh (US 20060111936) in view of Dimitrova (US 20230274809).
Regarding claim 5, Mahesh teaches the system of claim 1. Mahesh does not teach wherein the UI environment includes a planning directive form by which the user may construct or edit a radiotherapy plan, and the atomic application is a treatment planner application.
However, Dimitrova does teach wherein the UI environment includes a planning directive form by which the user may construct or edit a radiotherapy plan, and the atomic application is a treatment planner application ([0018], “the computer implemented method for treating a patient with a clinical pathway further includes receiving edits to the one or more of one or more consent forms or the report based on the treatment plan selection, the edits including one or more of modifications to a signature field, a signature date field, a provider field, or a signature time field.” [0107], “Once a treatment plan is selected, adjustments may be made to a corresponding dose and schedule.” [0078], “a treatment plan for radiation oncology may include radiation dosage and schedule, etc.”).
Mahesh in view of Dimitrova are considered analogous to the claimed invention because they are in the field of patient workflow. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Mahesh with Dimitrova for the advantage of allowing a system wherein a “user may adjust or confirm the treatment” (Dimitrova; [0168]).
Regarding claim 17, this claim is rejected for the same reasons as claim 5.
Claims 6 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Mahesh (US 20060111936) in view of Erry (US 20110015947).
Regarding claim 6, Mahesh teaches the system of claim 1. Mahesh does not teach wherein the UI environment includes a staff scheduler UI configured to indicate staff information, and the atomic application is a calendar application.
However, Erry does teach wherein the UI environment includes a staff scheduler UI configured to indicate staff information, and the atomic application is a calendar application ([0042], “The staff scheduler 201d tracks the job schedules for medical technicians and other staff members who are responsible for medication administration. The staff scheduler 201d collates the job schedule information with the facility master schedule to create daily task lists for each of the staff members.” [0058], “The medication management platform 200 also incorporates time management based web applications, for example, the Google calendar, for sending reminders and alerts to the health care users and the health care providers on different schedules of health care management.”).
Mahesh in view of Erry are considered analogous to the claimed invention because they are in the field of field. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Mahesh with Erry for the advantage of “facilitat[ing] managerial tracking” (Erry; [0014]).
Regarding claim 18, this claim is rejected for the same reasons as claim 6.
Claims 7 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Mahesh (US 20060111936) in view of Petro (US 20060173713).
Regarding claim 7, Mahesh teaches the system of claim 1. Mahesh does not teach wherein the UI environment includes a machine log UI, and the atomic application is an equipment tracker application.
However, Petro does teach wherein the UI environment includes a machine log UI, and the atomic application is an equipment tracker application ([0018], “System 15 provides automatic generation of peripheral device performance and availability metrics using data input from networked peripheral devices 33, 37, 39 and 43 and automated location of these devices using IP port data identifiers and a predetermined map associating the IP port identifiers with physical (geographic) locations. System 15 uses the performance and availability metrics identifying peripheral device utilization and active operational time duration, for example, for healthcare management and equipment utilization optimization” [0029], “The configuration manager in step 914 acquires medical device availability information, medical device utilization information and medical device location information from multiple medical devices via interface system 20.”). Examiner interprets device availability and active usage metrics to encompass a log of each device, as [0039] of Applicant specification notes that the Log Application allows users to view analytics regarding the status of equipment.
Mahesh in view of Petro are considered analogous to the claimed invention because they are in the field of patient workflow. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Mahesh with Petro for the advantage of “minimize[ing] peripheral device downtime and maintain patient workflow flexibility” (Petro; [0018]).
Regarding claim 19, this claim is rejected for the same reasons as claim 7.
Claims 8 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Mahesh (US 20060111936) in view of Dalbow (US 20150157880).
Regarding claim 8, Mahesh teaches the system of claim 1. Mahesh does not teach wherein the UI environment includes a morning quality assurance interface by which the user may add or edit a treatment status and/or a treatment machine status, and the atomic application is quality assurance application.
However, Dalbow does teach wherein the UI environment includes a morning quality assurance interface by which the user may add or edit a treatment status and/or a treatment machine status, and the atomic application is quality assurance application ([0045], “Continuing with the description of FIG. 2, "Add measurement" buttons (e.g. 214) are provided for a user to include additional measurements in this template. For instance, the user could click an "Add measurement" button under the X-ray output constancy test point to specify an additional X-ray output constancy (such as 12.0 MV) and manually enter the associated values. Additionally or alternatively, if data is to be provided from one or more other test date files, an "Add measurement" button may be selected and present an additional upload interface for a user to upload/extract data from a separate test data file to populate the measurement being added.” [0046], “If the data does not meet specification, an indicator, such as pop-up or color shading associated with the particular measurement, can be presented to the user informing that something is wrong.” [0048], “FIG. 3 depicts an example interface displaying machine status for machines associated with an account, in accordance with aspects described herein;” [0019], “FIG. 4 depicts one example of a QA test report, in accordance with aspects described herein;” [0027], “Presented herein are facilities to assist in quality assurance (QA) testing of systems and equipment, for instance equipment used in radiology and radiation therapy treatment.” [0063], “all of the above may be performed through a web interface to the cloud facility.” [0062], “In the example of FIG. 8, an overview 802 is presented to the user that displays the status of each machine. It shows that 13 devices were tested (in a given timeframe, for instance, such as overnight or early morning).”). Examiner notes that as a user inputs data that is then analyzed to derive machine status, the teachines of Dalbow encompass a user adding or editing a treatment or treatment machine status through an application.
Mahesh in view of Dalbow are considered analogous to the claimed invention because they are in the field of radiology workflows. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Mahesh with Dalbow for the advantage of “obtain[ing] QA results for the equipment” (Dalbow; [0003]).
Regarding claim 20, this claim is rejected for the same reasons as claim 8.
Claims 9-10 and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Mahesh (US 20060111936) in view of Sintay (US 20210146161).
Regarding claim 9, Mahesh teaches the system of claim 1. Mahesh does not teach wherein the UI environment includes a proton radiation management interface by which the user may manage a treatment execution, and the atomic application is a treatment management application.
However, Sintay does teach wherein the UI environment includes a proton radiation management interface by which the user may manage a treatment execution, and the atomic application is a treatment management application ([0033], “In some practices other staff in radiation oncology, including radiation therapists and medical dosimetrists, initially and periodically review charts. Chart review is endorsed by the Centers for Medicare and Medicaid Services which designates weekly physics and clinical management as a part of the treatment process.” [0069], “the system may also configure a user interface (e.g., graphical user interface) to present various information, charts generated based on the above analyses, data, and/or reports of the analyses.” [0052], “the system may analyze the technical parameters of a treatment plan execution to determine whether or not the desired treatment was delivered (i.e., the clinical requirements were met). Similar to the previous example, the treatment plan delivery system executes technical parameters from the treatment planning system to meet a subject's treatment objectives.” [0045], “treatment plans can be grouped by clinical technique such as isodose planning, depth calculation, 3D planning, intensity modulated radiation therapy, brachytherapy, proton therapy, electron therapy, etc. for a higher degree of accuracy.”).
Mahesh in view of Sintay are considered analogous to the claimed invention because they are in the field of field. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Mahesh with Sintay for the advantage of “achiev[ing] a clinically acceptable treatment plan” (Sintay; [0030]).
Regarding claim 10, Mahesh teaches the system of claims 1 and 9. Mahesh does not teach wherein the proton radiation management interface includes at least one of a treatment scheduler, a daily treatment list, a treatment statistic interface, a quality assurance view, or a treatment delivery calendar.
However, Sintay does teach wherein the proton radiation management interface includes at least one of a treatment scheduler, a daily treatment list, a treatment statistic interface, a quality assurance view, or a treatment delivery calendar ([0], “Through the web application 104, the user can see the automatic artificial intelligence algorithm quality assessment, visualize all the RT treatment plan elements including subject scans, delineated regions of interest, beams and computed dose, and finally mark the plan as approved or rejected for delivery, for example. The web application may be stand-alone and/or may link to existing QA or planning software suites. The web application 104 may allow ubiquitous access. Users can use desktops, laptops and tablets, or any other suitable computing device to access the service.” [0047], “the system may use the determined quality estimate, expected treatment plan features, and/or clinical requirements to determine whether there are any safety concerns, quality issues, compliance issues, or the like with respect to the treatment of a subject. The analyses may also include determination of how well certain plan features (e.g., technical parameters) match with expected plan characteristics (e.g., clinical requirements) and may include generation of error and/or warnings if the quality estimate is below a certain threshold value, compliance or safety issues are identified, or the like. For example, the quality estimate may be calculated as a confidence value, a simple pass/fail determination, or any other suitable estimate of quality.”).
Mahesh in view of Sintay are considered analogous to the claimed invention because they are in the field of patient management. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Mahesh with Sintay for the advantage of “performing automated quality assurance in radiation oncology” (Sintay; [0043]).
Regarding claim 21, this claim is rejected for the same reasons as claim 9.
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Mahesh (US 20060111936) in view of Fonte (US 20150055086).
Regarding claim 11, Mahesh teaches the system of claim 1. Mahesh does not teach wherein the UI environment includes a device tracking interface by which the user may track a creation and/or delivery of a patient-specific immobilization device, and the atomic application includes a device submission form.
However, Fonte does teach wherein the UI environment includes a device tracking interface by which the user may track a creation and/or delivery of a patient-specific immobilization device, and the atomic application includes a device submission form ([0047], “The computer system is further configured with an interface application. The system and method may include obtaining input or commands from a user through the computer system.” [0169], “FIGS. 1A and 1B at step 104 describe capturing the user's prescription data and other information to inform the analysis... The computer system requests this information through a form that the user enters information into by means of an input device connected to the computer system.” [0300], “A serialized identifier linked to the user's order is created to track the eyewear as it moves through the production process. The computer system associates the serial number with raw materials, specifications, or quality checklists.” [0318], “Those skilled in the art will recognize that the systems and methods described herein may also be used in the customization, rendering, display, and manufacture of other custom products… Custom Safety Goggles or Masks”). Examiner notes [0055] of Applicant specification notes that immobilization devices include masks and custom devices.
Mahesh in view of Fonte are considered analogous to the claimed invention because they are in the field of patient data processing. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Mahesh with Fonte for the advantage of “making some form of the product into a unique, non-mass-produced shape or size” (Fonte; [0021]).
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Mahesh (US 20060111936) in view of Mahesh2 (US 20060109961).
Regarding claim 12, Mahesh teaches the system of claim 1. Mahesh does not teach wherein the UI environment includes a waiting room interface, and the atomic application is an RSS feed application.
However, Mahesh2 does teach wherein the UI environment includes a waiting room interface, and the atomic application is an RSS feed application ([0052], “The resource map that is part of the dashboard interface displays a representation of the radiology waiting room and dynamically updates the resource map at a certain interval (e.g., anywhere from real-time or substantially real-time to every two minutes, every five minutes, every thirty minutes, etc.).” [0027], “more detailed resource information may be provided on demand. That is, the interface 130 may convey resource information to the user 140 that is selected using a set of rules. For example, the interface 130 may convey information regarding all waiting patients. The user 140 may then desire more specific and/or detailed resource information regarding a subset of the resource information conveyed and the user 140 may request such information from the interface 130. For example, the user 140 may desire resource information such as the name and pending procedure of a specific patient and request the name and pending procedure for that patient from the interface 130.” [0033], “assigning resources, such as imaging equipment, to certain tasks, and/or assigning personnel, such as radiologist, to certain tasks.”). Examiner notes [0056] of Applicant specification recites wherein “The Waiting Room RSS Feed Application provides a clinical status and information view for patients in the radiation oncology waiting room”, which Examiner interprets is encompassed by the resource information.
Mahesh in view of Mahesh2 are considered analogous to the claimed invention because they are in the field of patient workflow. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Mahesh with Mahesh2 for the advantage of “optimiz[ing] parameters such as patient wait time and procedure turnaround time in a medical facility” (Mahesh2; [0003]).
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 DAVID CHOI whose telephone number is (571)272-3931. The examiner can normally be reached M-Th:7:30-5:30 ET.
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, Shahid Merchant can be reached on (571)270-1360. 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.
/D.C./Examiner, Art Unit 3684
/Shahid Merchant/Supervisory Patent Examiner, Art Unit 3684
Prosecution Insights