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 .
DETAILED ACTION
Response to Amendment
The present Office Action is in response to the Request for Continued Examination dated 04/01/2026.
In the amendment dated 04/01/2026, the following occurred: Claims 1, 6-8, 13-15 and 20 were amended. Claims 2, 9 and 16 were canceled.
Claims 1, 3-8, 10-15 and 17-20 are currently pending.
Request for Continued Examination
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 04/01/2026 has been entered.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1, 3-8, 10-15 and 17-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Claims 1, 8 and 15 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1
The claim recites a method, a non-transitory computer readable medium (CRM) and a system for generating and presenting visualizations, which are within a statutory category.
Step 2A1
Regarding claims 1, 8 and 15, the limitation of (claim 1 being representative) receiving one or more visualization attributes corresponding to the visualization of the radiation therapy treatment plan data associated with a radiation therapy treatment of a patient; executing a […] model using the one or more visualization attributes and one or more configurations of a […] module to generate machine-readable code instructing the […] module to generate a medical visualization of the radiation therapy treatment corresponding to the one or more visualization attributes, wherein the one or more configurations of the visualization software module specify at least one digital library comprising a set of functions configured to be invoked by machine-readable code, and […] rendering the medical visualization of the one or more visualization attributes; transmitting the machine-readable code, to the […] module; causing the […] module to retrieve the at least one digital library and execute the machine-readable code to generate the medical visualization of the radiation therapy treatment according to the one or more visualization attributes; and in response to receiving the medical visualization from the […] module, presenting the medical visualization as drafted, is a process that, under the broadest reasonable interpretation, covers certain methods of organizing human activity (i.e., managing personal behavior including following rules or instructions) but for the recitation of generic computer components. The claims encompass a series of rules or instructions for a person or persons to follow, with or without the aid of a computer, receive visualization attributes, execute a ML language processing model, transmit machine-readable code, causing to retrieve digital library and to generate a medical visualization and present the medical visualization in the manner described in the identified abstract idea, supra. The rules or instructions are the claimed steps of “receiving … executing… transmitting… causing to retrieve and generate …and presenting the medical visualization” as indicated supra.
Other than reciting (in claim 1) a processor on a user device, (in claim 8) a non-transitory computer readable medium, a processor and a user device and (in claim 15) a processor and a user device, the claimed invention amounts to managing personal behavior or interaction between people. If a claim limitation, under its broadest reasonable interpretation, covers managing personal behavior or interactions between people, but for the recitation of generic computer components, then it falls within the “Certain Methods of Organizing Human Activity – Managing Personal Behavior Relationships, Interactions Between People (e.g. social activities, teaching, following rules or instructions)” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Step 2A2
This judicial exception is not integrated into a practical application. In particular, claims 1 and 15 recite the additional element of a processor. Claim 8 recites the additional elements of a non-transitory computer readable medium and a processor. These additional elements are not exclusively defined by the Applicant and are recited at a high-level of generality (i.e., a generic computer components for enabling access to medical information or for performing generic computer functions. See Specification at para. [0039] and [0040]) such that they amounts to no more than mere instructions to apply the exception using a generic computer component. As set forth in MPEP 2106.04(d) “merely including instructions to implement an abstract idea on a computer” is an example of when an abstract idea has not been integrated into a practical application. Accordingly, even in combination, these additional elements do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
Claims 1, 8 and 15 further recite the additional elements of a user interface comprising an interaction interface and a user device. These additional elements merely generally links the abstract idea to a particular technological environment or field of use. MPEP 2106.04(d)(I) indicates that generally linking an abstract idea to a particular technological environment or field of use cannot provide a practical application.
The claims further recite the additional elements of a machine-learning language processing model to generate machine-readable code and a visualization software module to generate a medical visualization which is interpreted as “apply it” to the abstract idea. MPEP 2106.04(d)(I) indicates that merely saying “apply it” or equivalent to the abstract idea cannot provide a practical application.
Accordingly, even in combination, these additional elements do not integrate the abstract idea into a practical application.
Step 2B
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of the non-transitory computer readable medium and a processor to perform the noted steps amounts to no more than mere instructions to apply the exception using a generic computer component. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept (“significantly more”). Moreover, using generic computer components to perform abstract ideas does not provide a necessary inventive concept. See Alice, 573 U.S. at 223 (“mere recitation of a generic computer cannot transform a patent-ineligible abstract idea into a patent-eligible invention”). Therefore, whether considered alone or in combination, the additional elements do not amount to significantly more than the abstract idea.
Also, as discussed above with respect to integration of the abstract idea into a practical application, the additional elements of user interface comprising an interactive user interface and a user device were determined to generally link the abstract idea to a particular technological environment or field of use. MPEP 2106.05(A) indicates that generally linking an abstract idea to a particular technological environment or field of use cannot provide significantly more.
As discussed above with respect to integration of the abstract idea into a practical application, the additional element of using a machine-learning language processing model to generate machine-readable code and a visualization software module to generate a visualization were found to be “apply it” to the abstract idea. This has been re-evaluated under the “significantly more” analysis and determined to be insufficient to provide significantly more. MPEP2106.05(1)(A) indicates that merely saying “apply it’ or equivalent to the abstract idea cannot provide an inventive concept (“significantly more’). As such the claim is not patent eligible.
Accordingly, even in combination, these additional elements do not provide significantly more. As such the claim is not patent eligible.
The Examiner notes that: A well-known, general-purpose computer has been determined by the courts to be a well-understood, routine and conventional element (see, e.g., Alice Corp. v. CLS Bank; see also MPEP 2106.05(d)); Receiving and/or transmitting data over a network (“a communications network”) has also been recognized by the courts as a well - understood, routine and conventional function (see, e.g., buySAFE v. Google; MPEP 2016(d)(II)); and Performing repetitive calculations is/are also well-understood, routine and conventional computer functions when they are claimed in a merely generic manner (see, e.g., Parker v. Flook; MPEP 2016.05(d)).
Claims 3-7, 10-14 and 17-20 are similarly rejected because they either further define/narrow the abstract idea and/or do not further limit the claim to a practical application or provide as inventive concept such that the claims are subject matter eligible even when considered individually or as an ordered combination. Claim(s) 3, 4, 10, 11, 17 and 18 further merely describe(s) the machine-learning language processing model. Claim(s) 5, 12 and 19 further merely describe(s) recalibrating the machine- learning language processing model. Claim(s) 6 and 13 further merely describe(s) adjusting the one or more visualization attributes. Claim(s) 7, 14 and 20 further merely describe(s) the medical visualization. Claims 3-7, 10-14 and 17-20 further define the abstract idea and are rejected for the same reason presented above with respect to claims 1, 8 and 15.
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 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.
Claims 1, 3-8, 10-15 and 17-20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Peltola (US 2022/0296923).
REGARDING CLAIM 1
Peltola discloses a method for generating machine-readable code for visualization of radiation therapy treatment plan data comprising: presenting, by a processor on a user device, a user interface comprising an interaction interface for a medical professional operating the user device ([0028] teaches an electronic platform that includes graphical user interfaces (GUIs) (interpreted by Examiner as presenting the user interface comprising an interactive interface) displayed on the end-user devices 140, and/or the administrator computing device 150 and that a physician operating the physician device 120b (interpreted by Examiner as the medical professional operating the user device) may access the platform, input patient attributes or characteristics and other data); receiving, by the processor from the interaction interface, one or more visualization attributes corresponding to the visualization of the radiation therapy treatment plan data associated with a radiation therapy treatment of a patient ([0028] teaches the platform identifies and displays treatment attributes (e.g., RTTP that includes different radiation parameters). [0035] teaches treatment data received from a physician operating the physician device 120b and [0036] teaches retrieve/receive data associated with a particular patient's treatment plan. [0041] teaches the analytics server receives patient data (e.g., physical attributes and diagnosis) and treatment data and [0080] teaches the data received (e.g., patient/treatment data) may be visual (interpreted by Examiner as the received one or more visualization attributes corresponding to the visualization of the radiation therapy treatment plan data associated with a radiation therapy treatment of a patient)); executing, by the processor, a machine-learning language processing model using the one or more visualization attributes and one or more configurations of a visualization software module to generate machine-readable code instructing the visualization software module to generate a medical visualization of the radiation therapy treatment corresponding to the one or more visualization attributes, wherein the one or more configurations of the visualization software module specify at least one digital library comprising a set of functions configured to be invoked by machine-readable code, and wherein the machine-learning language processing model is configured to generate the machine-readable code corresponding to the visualization software module for rendering the medical visualization of the one or more visualization attributes ([0022] teaches the methods and systems described herein can be used to simulate and visualize dose distribution for a patient based on a suggested treatment plan and [0029] teaches radiation parameters may include, but are not limited to, different treatment modalities, field geometry settings for external beam radiotherapy, side effect predictions, organ and/or tumor segmentation, machine therapy attributes, dosage administration attributes (e.g., dosage amount), treatment frequency, treatment timing, etc. (interpreted by Examiner as the one or more visualization attributes and one or more configurations of a visualization software module) [0033] and [0035] teach the analytics server uses inputs to train the machine-learning or other computer models and executes various models to analyze the retrieved data (interpreted by Examiner as executing a machine-learning language processing model using the one or more visualization attributes and one or more configurations of a visualization software module) [0095] teaches a plan optimizer generating a treatment plan and [0096] teaches the output generated by the AI model may be ingested by the plan optimizer. [0049] teaches visually represent in two or three dimensional graphs dose distribution of a patient's treatment based on the particular treatment plan (interpreted by Examiner as the medical visualization) and [0102] teaches the plan optimizer 330 may display the suggested treatment plan 340 on a computer of a clinic where a radiotherapy technician or a treating oncologist can review the treatment plan (interpreted by Examiner as the visualization software module for rendering the medical visualization of the one or more visualization attributes) [0020] teaches the plan optimizer may be a set of computer-readable instructions stored on a non-transitory computer medium and configured to be executed by a processor to carry out this functionality and [0077] teaches the analytics server may receive the characteristics for the patient based on a patient identifier that is provided via a user interface of the electronic platform. The analytics server may use the patient's name to query a database that includes patient information and retrieve information about the patient such as the patient's electronic health data records, data associated with the patient's anatomy, such as physical data (e.g., height, weight, and/or body mass index) and/or other health-related data (e.g., blood pressure or other data relevant to the patient receiving radiation therapy treatment) and/or geometrical data, data associated with current and/or previous medical treatments received by the patient (e.g., data associated with the patient's previous surgeries). (interpreted by Examiner as the machine-readable code instructing the visualization software module to generate a medical visualization of the radiation therapy treatment, wherein the one or more configurations of the visualization software module specify at least one digital library comprising a set of functions configured to be invoked by machine-readable code). [0028] teaches a physician operating the physician device 120b may access the platform, input patient attributes or characteristics and other data, and further instruct the analytics server 110a to optimize the patient's treatment plan and [0095] teaches instructing the plan optimizer to generate a new plan (interpreted by Examiner as executing, by the processor, a machine-learning language processing model to generate machine-readable code)) transmitting, by the processor, the machine-readable code, to the visualization software module for execution by the visualization software module ([0020] teaches the plan optimizer may be a set of computer-readable instructions configured to be executed by a processor to carry out this functionality (interpreted by Examiner as means for transmitting the machine-readable code to the software module for execution)); causing, by the processor, the visualization software module to retrieve the at least one digital library and execute the machine-readable code to generate the medical visualization of the radiation therapy treatment according to the one or more visualization attributes ([0022] teaches to simulate and visualize dose distribution for a patient based on a suggested treatment plan, [0076] teaches the analytics server may retrieve values of characteristics of the patient from storage to include in the feature vector responsive to receiving an identifier of the patient. The analytics server may input the feature vector into the AI model and obtain an output from the AI model and [0102] teaches the plan optimizer 330 may display the suggested treatment plan 340 (interpreted by Examiner as causing, by the processor, the visualization software module to retrieve the at least one digital library and execute the machine-readable code to generate the medical visualization of the radiation therapy treatment according to the one or more visualization attributes)); and in response to receiving the medical visualization from the visualization software module, presenting, by the processor, the medical visualization via the user interface based on causing the visualization software to execute the machine-readable code ([0028] teaches the analytics server optimize dosage distribution and display the results (interpreted by Examiner as the medical visualization) on the end-user devices and may display the predicted dose distribution and/or radiation parameters (also interpreted by Examiner as the medical visualization) on the physician device [0035] teaches executing various models 111 to analyze the retrieved data and displays the results via the electronic platform on the administrator computing device 150, the electronic physician device 120b, and/or the end-user devices 140 (interpreted by Examiner as the user interface) and [0006] teaches displaying, by the processor, a heat map having a set of segments where each segment corresponds to a first coordinate and a second coordinate of the anatomical region of the patient, wherein a visual attribute of each segment corresponds to a calculated dose distribution value and [0088] teaches visualizing the AI model's predictions. (All of the above are interpreted by the Examiner as presenting the medical visualization in response to receiving the medical visualization from the visualization software module, via the user interface based on causing the visualization software to execute the machine-readable code)).
REGARDING CLAIMS 8 and 15
Claims 8 and 15 are analogous to Claim 1 thus Claims 8 and 15 are similarly analyzed and rejected in a manner consistent with the rejection of Claim 1.
REGARDING CLAIM 3
Peltola discloses the limitation of claim 1.
Peltola further discloses:
The method of claim 1, wherein the machine-learning language processing model is specifically trained for a plan optimizer that generates the radiation therapy treatment of the patient (Peltola at [0006] teaches that the artificial intelligence model trained using training dataset and [0029] teaches the predicted dose distribution values can be ingested by the plan optimizer to iteratively improve the patient's treatment plan (interpreted by Examiner as wherein the machine-learning language processing model is specifically trained for a plan optimizer that generates the radiation therapy treatment of the patient)).
REGARDING CLAIM 4
Peltola discloses the limitation of claim 1.
Peltola further discloses:
The method of claim 1, wherein the machine-learning language processing model is specifically trained for the medical visualization using at least one configuration of the visualization software module (Peltola [0102] the plan optimizer (interpreted by Examiner as the visualization software module) may iteratively revise the patient's treatment plan and with each iteration, the plan optimizer may transmit new treatment plan data back to the machine-learning model (interpreted by Examiner as the machine-learning language processing model) whereby the machine-learning model can recalculate/re-predict new dose distribution data based on the revised treatment data generated by the plan optimizer (iteration 322). The plan optimizer 330 and the machine-learning model 320 may repeat the iteration 322 until the patient's treatment plan is optimized (interpreted by Examiner as wherein the machine-learning language processing model is specifically trained for the medical visualization using at least one configuration of the visualization software module)).
REGARDING CLAIM 5
Peltola discloses the limitation of claim 1.
Peltola further discloses:
The method of claim 1, further comprising: recalibrating, by the processor, the machine-learning language processing model using an input corresponding to a quality of the medical visualization (Peltola at [0110] teaches the analytics server may use user interactions to further train and re-calibrate the AI model. When an end user performs an activity on the electronic platform that displays the results predicted via the AI model, the analytics server may track and record details of the user's activity. For instance, when a predicted result is displayed on a user's electronic device, the analytics server may monitor the user's electronic device to identify whether the user has interacted with the predicted results by editing, deleting, accepting, or revising the results. The analytics server may also identify a timestamp of each interaction, such that the analytics server records the frequency of modification, duration of revision/correction (interpreted by Examiner as recalibrating the machine-learning language processing model using an input corresponding to a quality of the medical visualization)).
REGARDING CLAIM 6
Peltola discloses the limitation of claim 1.
Peltola further discloses:
The method of claim 1, further comprising: adjusting, by the processor, the one or more visualization attributes of the radiation therapy treatment plan in accordance with an input received after presenting the medical visualization (Peltola at [0028] teaches the analytics server 110a may utilize the methods and systems described herein to optimize dosage distribution and display the results on the end-user devices or adjust the configuration of one of end-user devices 140 (e.g., the radiotherapy machine 140d) [0040] teaches adjusting the medical device 140d based on the radiation parameters generated by the analytics server 110a. For instance, the radiotherapy machine may adjust the gantry and couch based on angles and other attributes/parameters determined by the analytics server 110a. The analytics server 110a may transmit instructions to the radiotherapy machines indicating any number or type of radiation parameters (e.g., field geometry settings) to facilitate such adjustments. [0058] teaches medical professional adjusting one or more attributes of the patient's treatment plan (interpreted by Examiner as means for adjusting the one or more visualization attributes of the radiation therapy treatment plan in accordance with an input received after presenting the medical visualization)).
REGARDING CLAIM 7
Peltola discloses the limitation of claim 1.
Peltola further discloses:
The method of claim 1, wherein the medical visualization is a comparison between the one or more visualization attributes of the radiation therapy treatment plan at two different times (Peltola at [0029] teaches evaluating the radiation parameters. [0061] teaches the analytics server may label the training dataset, such that the AI model can differentiate between desirable and undesirable outcomes. Labeling the training dataset may be performed automatically and/or using human intervention. For instance, the analytics server may analyze a treatment plan, DVH, and/or achieved values for clinical goals for a previously treated patient and may identify various hot spots or cold spots (e.g., by comparing the dosage received with the plan objective thresholds). [0065] teaches The AI model may output dose distribution values for individual patients based on their respective characteristics, and the outputs can be compared against the labels. Also, [0071] teaches the AI model may ingest all the data within the training dataset to identify hidden patterns and connections between data points and [0072] teaches the analytics server may compare the predicted values with true and actual values within the training dataset (interpreted by Examiner as wherein the medical visualization is a comparison between the one or more visualization attributes of the radiation therapy treatment plan at two different times)).
REGARDING CLAIMS 9-14 and 16-20
Claims 9-14 and 16-20 are analogous to Claims 2-7 thus Claims 9-14 and 16-20 are similarly analyzed and rejected in a manner consistent with the rejection of Claim 2-7.
Response to Arguments
Claim Objections
Regarding the claim objection(s), the Applicant has amended claims 6, 7, 13, 14 and 20 to overcome the basis/bases of objection.
Rejection under 35 U.S.C. § 101
Regarding the rejection of claims 1, 3-8, 10-15 and 17-20, the Examiner has considered the Applicant’s arguments, but does not find them persuasive. Applicant argues:
The claims are directed to methods of executing a machine-learning language processing model to generate a visualization of radiation therapy treatment plan data. For example, the claims recite limitations such as "executing, by the processor, a machine-learning language processing model using the one or more visualization attributes and one or more configurations of a visualization software module to generate machine-readable code" and "causing, by the processor, the visualization software module to retrieve the at least one digital library and execute the machine-readable code." These limitations are therefore not directed to methods of organizing human activity, as alleged by the Office Action, but rather to a computer-implemented process for generating executable visualization code and causing a visualization software module to retrieve libraries and execute that code to render a medical visualization… However, the described systems and methods not merely use the computer "as a tool to perform their abstract idea," as alleged by the Office Action. Rather, the claimed systems and methods are directed to executing a computer in a specific manner using defined data inputs to produce a particular data output. For example, amended claim recites "executing, by the processor, a machine-learning language processing model using the one or more visualization attributes and one or more configurations of a visualization software module to generate machine-readable code" and "causing, by the processor, the visualization software module to retrieve the at least one digital library and execute the machine-readable code." While the computer is executed based on visual attributes received from an "interaction interface," the claims are note directed towards receiving the visual attributes, but rather a computer-implemented method of transforming received visual attributes. Receiving inputs from a user interface does not detract from the claims being directed to a concrete technological process that transforms input data into executable machine-readable code and causes that code to be executed by a visualization software module using retrieved digital libraries to generate a medical visualization.
Regarding 1, The Examiner respectfully disagrees. Executing a computer in a specific manner using defined data inputs to produce a particular data output is in fact an abstract idea. The claims use a generic processor to generate a medical visualization. Outputting data, i.e., a medical visualization is an abstract idea. The processor is not exclusively defined by the Applicant and is recited at a high-level of generality (i.e., a generic computer components for enabling access to medical information or for performing generic computer functions. See Specification at para. [0039] and [0040]) such that it amounts to no more than mere instructions to apply the exception using a generic computer component.
The Office Action further states that "[m]oreover, the specification does not claim a technical solution to a technical problem. Instead the specification focuses on improving the accuracy and effectiveness of radiotherapy treatments [0003] and improving treatment plan visualizations to improve the efficiency and efficacy of treatment planning [0007]. The claim is in ineligible." See page 18. The Applicant respectfully disagrees. The Specification clearly states the technical problem of limitations in existing visualization software, including outdated interfaces and limited customization options that constrain how radiation therapy treatment plan data can be presented and reviewed. This is a demonstrable technical problem with current systems and methods for generating visualizations of radiation therapy treatment plan data. For example, the Specification describes that "[c]urrent software solutions, however, are often cumbersome, featuring outdated interfaces and limited customization options. This technical shortcoming can hinder the ability to make informed decisions quickly and adapt treatments to patient-specific needs, ultimately impacting the effectiveness and efficiency of the RTTP" See para. [0005]. The systems and methods described by the Specification therefore address the technical problem limited customization options with current software for presenting data associated with radiation therapy treatment plans. The Specification further describes a technical benefit of adapting visualization code to accommodate different clinics that operate on distinct visualization software systems. For example, the Specification describes that "a particular clinic can tune the machine learning language processing model in accordance with their clinic's software/version of software applications." See para. [0054]. The Specification also describes that "[t]he code or script for these visualizations may be produced directly by the large language model rather than relying on pre-installed, manually created software that is often static and/or requires coding experience to operate." See para. [0056]… The claims are therefore not merely focus on "improving treatment plan visualizations to improve the efficiency and efficacy of treatment planning," as alleged on page 18 of the Office Action, but rather are directed to a concrete computer-implemented solution that improves the operation and flexibility of visualization software by enabling dynamic generation and execution of visualization code across different software environments.
Regarding 2, the Examiner respectfully submits that the Applicant does not provide technical solutions/improvements, rather provides improvements to treatment plan visualization, which is an improvement to the abstract idea. The Applicant mentions “This technical shortcoming can hinder the ability to make informed decisions quickly and adapt treatments to patient-specific needs, ultimately impacting the effectiveness and efficiency of the RTTP", this is not a technical problem but a medical/administrative problem. The Applicant does not improve upon interfaces, visualization software systems or machine learning models but applies known interfaces, software systems and ML techniques to render improvements in visualization. The claims simply execute ML model using specific information to render a visualization. There is no practical application in the claim and the claims do not provide technical improvements, such as improvements to a user interface, improvements to ML technology or improvements to software systems. The claim is ineligible.
Rejection under 35 U.S.C. § 102
Regarding the rejection of claims 1, 3-8, 10-15 and 17-20, the Examiner has considered the Applicant’s arguments, but does not find them persuasive. Applicant argues:
… the models described in Peltola are therefore not analogous "digital library comprising a set of functions configured to be invoked by machine-readable code," as recited in amended claim 1. Applicant further notes that in the Office Action, the rejection of claim 1 fails to establish that Peltola describes "causing, by the processor, the visualization software module to retrieve at least one library," as recited in amended claim 1. For example, in reference to paragraphs [0028], [0035], [0006], and [0088] of Peltola, the Office Action states "All of the above are interpreted by the Examiner as presenting the medical visualization in response to receiving the medical visualization from the visualization software module, via the user interface based on causing the visualization software to execute the machine-readable code." See page 11. However merely "causing the visualization software to execute the machine-readable code" does not teach "causing, by the processor, the visualization software module to retrieve at least one library," as recited in amended claim 1.
Regarding 1, The Examiner respectfully submits that Peltola at [0077] teaches the analytics server may receive the characteristics for the patient based on a patient identifier that is provided via a user interface of the electronic platform. The analytics server may use the patient's name to query a database that includes patient information and retrieve information about the patient such as the patient's electronic health data records, data associated with the patient's anatomy, such as physical data (e.g., height, weight, and/or body mass index) and/or other health-related data (e.g., blood pressure or other data relevant to the patient receiving radiation therapy treatment) and/or geometrical data, data associated with current and/or previous medical treatments received by the patient (e.g., data associated with the patient's previous surgeries), which is interpreted by Examiner as “wherein the one or more configurations of the visualization software module specify at least one digital library comprising a set of functions configured to be invoked by machine-readable code”. Given the broadest reasonable interpretation the cited reference in combination teaches the claimed features.
By contrast, as an exemplary nonlimiting example, the Specification states that input including visualization attributes may include "I would like to see DVH for John Smith, but highlight the OARs in blue." See para. [0061]. As another nonlimiting example, the Specification describes "the user may input, 'Let me see how doses affect different organs if we go with this treatment plan.'… Visualization attributes, such as presenting a DVH or highlighting OARs in blue, define how radiation therapy treatment plan data is visually presented. "Treatment parameters," as described by Peltola, are therefore not visualization parameters for visual representations of radiation therapy treatment plan data, but rather parameters that define delivery of radiation during radiation therapy treatment. As a result, Peltola fails to teach or describe "visualization attributes corresponding to the visualization of the radiation therapy treatment plan data," as recited in amended claim 1.
Regarding 2, The Examiner suggests amending claims to define what visualization attributes are. Given the broadest reasonable interpretation the cited reference in combination teaches the claimed features.
Additionally, the Office Action states that "[0020] teaches the plan optimizer may be a set of computer-readable instructions stored on a non-transitory computer medium and configured to be executed by a processor to carry out this functionality (interpreted by Examiner as the machine- readable code instructing the visualization software module to generate a medical visualization of the radiation therapy treatment)." See page 10. However, Peltola does not describe "generate the medical visualization of the radiation therapy treatment according to the one or more visualization attributes," where the visual attributes are received "from the interaction interface," as recited in amended claim 1. As described above, "treatment attributes" and "radiation treatment parameters" are not analogous to visualization attributes. Peltola describes that "[t]he plan optimizer may be a set of computer-readable instructions stored on a non-transitory computer medium and configured to be executed by a processor to carry out this functionality. The customized treatment plan may also consider how dosages are distributed among the patient's organs to ensure radiation is appropriately applied to PTV without compromising OARs." See para. [0020]. However, executing pre-existing machine-readable code to optimize a treatment plan according to input values does not teach "generate the medical visualization of the radiation therapy treatment according to the one or more visualization attributes" received via a user interface, as recited in amended claim 1 (emphasis added).
Regarding 3, the Examiner respectfully submits that current claims are very broad and require the rendering of a medical visualization, which Peltola teaches at [0022] which teaches the methods and systems described herein can be used to simulate and visualize dose distribution for a patient based on a suggested treatment plan, at [0049] teaches visually represent in two or three dimensional graphs dose distribution of a patient's treatment based on the particular treatment plan and at [0102] teaches the plan optimizer 330 may display the suggested treatment plan 340 on a computer of a clinic where a radiotherapy technician or a treating oncologist can review the treatment plan. Moreover, [0028] teaches a physician operating the physician device 120b may access the platform, input patient attributes or characteristics and other data, and further instruct the analytics server 110a to optimize the patient's treatment plan. Under the broadest reasonable interpretation the following portion of Peltola teaches “generate the medical visualization of the radiation therapy treatment according to the one or more visualization attributes,” where the visual attributes are received "from the interaction interface," as recited in amended claim 1. The Examiner suggests amending claims to define/clarify intent.
Conclusion
The prior art made of record though not relied upon in the present basis of rejection are noted in the attached PTO 892 and include:
Hardemark (US 2018/0078783) discloses system and method for providing a radiation therapy treatment plan and radiation therapy machine. Fox (US 2014/0378736) discloses methods, systems and computer readable storage media storing instructions for generating a radiation therapy treatment plan.
Any inquiry concerning this communication or earlier communications from the Examiner should be directed to LIZA TONY KANAAN whose telephone number is (571)272-4664. The Examiner can normally be reached on Mon-Thu 9:00am-6:00pm 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, Robert Morgan can be reached on 571-272-6773. 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 the 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/docs 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.
/LIZA TONY KANAAN/Examiner, Art Unit 3683
Prosecution Insights