DETAILED ACTION
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
This communication is in response to the amendment filed 4/1/26. Claims 1, 7-9, and 15-20 have been amended. Claims 1-20 are pending.
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-20 are rejected under 35 U.S.C. §101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1:
Claims 1-6 are directed to a method (i.e., a process) and claims 7-14 are directed to a system (i.e., a machine). Accordingly, claims 1-14 are all within at least one of the four statutory categories.
Claims 15-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claim(s) does/do not fall within at least one of the four categories of patent eligible subject matter because they are drawn to software per se (e.g., modules, application). Software per se intrinsically require no tangible physical structure, thus do not constitute tangible physical articles or other forms of matter. Therefore, software per se is not considered to be statutory subject matter. Products that do not have a physical or tangible form, such as information (often referred to as "data per se") or a computer program per se (often referred to as "software per se") when claimed as a product without any structural recitations are not directed to any of the statutory categories.
Step 2A - Prong One:
Regarding Prong One of Step 2A, the claim limitations are to be analyzed to determine whether, under their broadest reasonable interpretation, they “recite” a judicial exception or in other words whether a judicial exception is “set forth” or “described” in the claims. An “abstract idea” judicial exception is subject matter that falls within at least one of the following groupings: a) certain methods of organizing human activity, b) mental processes, and/or c) mathematical concepts.
Representative independent claim 1 includes limitations that recite at least one abstract idea. Specifically, independent claim 1 recites:
1. A medical information processing method suitable for executing on a cloud platform service system of medical information, which is used to process medical information containing descriptive information and to-be-processed data, wherein the medical information is processed to conform a calculation of a selected medical information calculation application, the cloud platform service system of medical information comprises a computer equipment and a cloud platform, the computer equipment comprises a calculation required information detection module and a verification information generation module, the medical information processing method comprising: the calculation required information detection module executes a calculation required information detection process configured to compare the descriptive information with a calculation required information comparison table and to detect at least one calculation required information required by the calculation of the medical information calculation application from the descriptive information of the medical information, wherein if items and contents of the calculation required information are detected to be correct according to the calculation required information comparison table, the calculation required information detection process is further configured to delete all or part of contents from the descriptive information except the contents of the calculation required information by the medical information calculation application, and to generate to-be-processed medical information based on the to-be-processed data and a remained descriptive information after deletion; and the verification information generation module executes a verification information generation process configured to generate a verification information when the to-be- processed medical information is generated in the calculation required information detection process; wherein the descriptive information comprises personal information used to describe patients, information related to medical units, tests, or information used to describe parameters related to medical images or physiological signal; wherein, the descriptive information and the to-be-processed data are stored in one single data file or in separated data files.
The Examiner submits that the foregoing underlined limitations constitute “certain methods of organizing human activity” because a calculation required information detection process configured to compare the descriptive information with a calculation required information comparison table and to detect at least one calculation required information required by the calculation from the descriptive information of the medical information, wherein if items and contents of the calculation required information are detected to be correct according to the calculation required information comparison table, the calculation required information detection process is further configured to delete all or part of contents from the descriptive information except the contents of the calculation required information, and to generate to-be-processed medical information based on the to-be-processed data and a remained descriptive information after deletion; and a verification information generation process configured to generate a verification information when the to-be- processed medical information is generated in the calculation required information detection process; wherein the descriptive information comprises personal information used to describe patients, information related to medical units, tests, or information used to describe parameters related to medical images or physiological signal amount to managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions), at the currently claimed high level of generality.
Accordingly, the claim recites at least one abstract idea.
Step 2A - Prong Two:
Regarding Prong Two of Step 2A, it must be determined whether the claim as a whole integrates the abstract idea into a practical application. It must be determined whether any additional elements in the claim beyond the abstract idea integrate the exception into a practical application in a manner that imposes a meaningful limit on the judicial exception. The courts have indicated that additional elements merely using a computer to implement an abstract idea, adding insignificant extra solution activity, or generally linking use of a judicial exception to a particular technological environment or field of use do not integrate a judicial exception into a “practical application.”
The limitations of claims 1, 7, and 15, as drafted, is a process that, under its broadest reasonable interpretation, covers certain methods of organizing human activity but for the recitation of generic computer components. That is, other than reciting a cloud platform service system, computer equipment, cloud platform, modules, an application, an application server, and a network server to perform the limitations, nothing in the claim elements precludes the steps from practically being certain methods of organizing human activity. If a claim limitation, under its broadest reasonable interpretation, covers certain methods of organizing human activity but for the recitation of generic computer components, then it falls within the “certain methods of organizing human activity” grouping of abstract ideas. Accordingly, the claims recite an abstract idea.
This judicial exception is not integrated into a practical application. In particular, the cloud platform service system, computer equipment, cloud platform, modules, application, application server, and network server are recited at a high-level of generality (i.e., as generic computer components performing generic computer functions of comparing information, detecting information, generating information, deleting information, receiving information, sending information, analyzing information, and storing data) such that it amounts no more than mere instructions to apply the exception using generic computer components. Accordingly, 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 claims are directed to an abstract idea.
Thus, taken alone, the additional elements do not amount to significantly more than the above-identified judicial exception (the abstract idea). Looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually. For instance, there is no indication that the additional elements, when considered as a whole, reflect an improvement in the functioning of a computer or an improvement to another technology or technical field, apply or use the above-noted judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition, implement/use the above-noted judicial exception with a particular machine or manufacture that is integral to the claim, effect a transformation or reduction of a particular article to a different state or thing, or apply or use the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment, such that the claim as a whole is not more than a drafting effort designed to monopolize the exception (see MPEP § 2106.05). Their collective functions merely provide conventional computer implementation.
Claims 2-6, 8-14, and 16-20 are ultimately dependent from Claim(s) 1, 7, and 15 and include all the limitations of Claim(s) 1, 7, and 15. Therefore, claim(s) 2-6, 8-14, and 16-20 recite the same abstract idea. Claims 2-6, 8-14, and 16-20 describe further limitations regarding wherein the accompanying descriptive information comprises direct personal information and indirect personal information, types of files, wherein the to-be-processed data is medical image data, physiological signal data, or non-file descriptive text data, transmitting information, recovering information, and an AI model or medical information analysis. These are all just further describing the abstract idea recited in claims 1, 7, and 15, without adding significantly more.
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 amount to no more than mere instructions to apply the exception using generic computer components. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. The claims are not patent eligible.
Step 2B:
Regarding Step 2B, independent claims 1, 7, and 15 do not include additional elements (considered both individually and as an ordered combination) that are sufficient to amount to significantly more than the judicial exception for reasons the same as those discussed above with respect to determining that the claim does not integrate the abstract idea into a practical application.
Regarding the additional limitations directed to storing information/data in data files, a server storing an application, and a server receiving/sending information, all of which the Examiner submits merely add insignificant extra-solution activity to the abstract idea or are claimed in a merely generic manner (e.g., at a high level of generality), the Examiner further submits that such steps are not unconventional as they merely consist of storing and retrieving information in memory and receiving and transmitting data over a network. See MPEP 2106.05(d)(II).
The dependent claims do not include additional elements (considered both individually and as an ordered combination) that are sufficient to amount to significantly more than the judicial exception for the same reasons to those discussed above with respect to determining that the dependent claims do not integrate the at least one abstract idea into a practical application.
Therefore, claims 1-20 are ineligible under 35 USC §101.
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, 10, and 16 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, 10, and 16 recite the limitation "the accompanying descriptive information" in lines 1-2. There is insufficient antecedent basis for this limitation in the claims. Note that Applicant deleted “accompanying descriptive information” from the independent claims.
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.
Claim(s) 1-4, 6-12, 14-18, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Sorenson et al. (US 2018/0137244 A1) in view of Berlinger et al. (US 2021/0046328 A1).
(A) Referring to claim 1, Sorenson discloses A medical information processing method suitable for executing on a cloud platform service system of medical information (para. 30 & 31 of Sorenson), which is used to process medical information containing descriptive information and to-be-processed data, wherein the medical information is processed to conform a calculation of a selected medical information calculation application, the cloud platform service system of medical information comprises a computer equipment and a cloud platform, the computer equipment comprises a calculation required information detection module and a verification information generation module, the medical information processing method comprising (para. 30, 31, 77, & 183 of Sorenson; a locally-sited system and/or cloud-based platform is utilized to make it easy to anonymize studies, upload studies, register and access a new account, establish a community, specify a clinical advisory board and/or governance for the group, access tools to train and create machine learned algorithms/engines, upload or download algorithms/engines, access and run published algorithms/engines on studies and communicate the outcome/results such as number of uses, accuracy, and confidence level based on the confirmed or rejected findings. A machine learning module can receive image data from a medical image data source. The machine learning module can correlate image data from the medical image data source to a workflow based on in-image analysis and metadata. This workflow can be a unique machine learning module or a collection of machine learning (ensemble) which can provide a unique or a collection of results to be consume within a third-party application. The correlation of the medical data to a machine learning module or collection of machine learning can be done based on pattern extraction, feature extraction or image processing which result of a medical image classification (clusterization).):
the calculation required information detection module executes a calculation required information detection process configured to detect at least one calculation required information required by the calculation of the medical information calculation application from the descriptive information of the medical information (para. 183 of Sorenson; The machine learning module can correlate image data from the medical image data source to a workflow based on in-image analysis and metadata. This workflow can be a unique machine learning module or a collection of machine learning (ensemble) which can provide a unique or a collection of results to be consume within a third-party application. The correlation of the medical data to a machine learning module or collection of machine learning can be done based on pattern extraction, feature extraction or image processing which result of a medical image classification (clusterization). Over time, the machine learning module can optimize and improve the association between the workflow and image data by machine learning based on a series of individual user's inputs, a group of user's inputs from one or more medical institutes over a network, information from the in-image analysis, information from metadata, or patient context or any combination thereof. The machine learning module can associate the series (i.e., image data) with the workflow based on metadata, for example within the DICOM file (e.g., DICOM headers and tags), such as patient ID, accession number, date, time frame, body part, body area, medical condition, encounter, procedure, symptom, description, or any combination thereof, or for example within the HL7 message containing clinical relevant information about the exam request (ORM, ORU etc. . . . ). ) ), the calculation required information detection process is further configured to generate to-be-processed medical information based on the to-be-processed data and a remained descriptive information after deletion (para. 72, 142, 143, and 183 of Sorenson; If a physician replaces a number in a report with a different measurement value made via a different measurement in the image viewer, the system will prompt the physician to accept the deletion of the old measurement that was replaced, or automatically do this based on this and other preferences. The changes in the findings in the report which were made by the physician's further interrogation and measurements within the images are coordinated such that the original measurements or annotations made in the images by the computer automation methods are removed or replaced. This avoids confusion in the patient record that can occur when images are stored along with the final report, and avoids unnecessary work to delete computer generated findings in the case they are duplicated and not updated. Such workflow confusion and inefficiency is resolved by a bi-directional updating of physician-adjusted, added, or deleted findings within the report and the diagnostic interpretation viewer, irrespective of the point of the change, whether it be the report value that is changed, or the measurement or image process used in the image viewer being adjusted to create a new resultant value. The user can remove the recommended image data and replace with another image data which will update the weight of the result and optimize machine learning module.); and
the verification information generation module executes a verification information generation process configured to generate a verification information when the to-be-processed medical information is generated in the calculation required information detection process (para. 42, 43, 50, 88, and 98 of Sorenson; the image processing engines are used to confirm or verify findings by the physicians, where the engines operate as medical data review systems. The review system operating as a medical data review system is configured to review the second set of medical images to verify or confirm or unverify or reject the abnormality of the images, generating a second result. A processing engine would then run on both CT studies to compare the two to see if there are any differences. If the most recent report is deemed “no significant interval change,” a medical data review system function can be to run an engine that can verify the similarity, and therefore provide the ability to agree or disagree with that statement. Often, the reported findings are maintained in reports, and electronic communications, which are inputs to the platform and the relevant contents are provided to the engine when it runs.);
wherein the descriptive information comprises personal information used to describe patients, information related to medical units, tests, or information used to describe parameters related to medical images or physiological signal (para. 183 of Sorenson; associate the series (i.e., image data) with the workflow based on metadata, for example within the DICOM file (e.g., DICOM headers and tags), such as patient ID, accession number, date, time frame, body part, body area, medical condition, encounter, procedure, symptom, description, or any combination thereof, or for example within the HL7 message containing clinical relevant information about the exam request (ORM, ORU etc. . . . ). The machine learning module can associate the series with the workflow based on in-image analysis, for example, by reconstructing the image or analyzing the pixel characteristics (e.g., intensity, shading, color, etc.) to determine the anatomy or modality.);
wherein, the descriptive information and the to-be-processed data are stored in one single data file or in separated data files (para. 77, 195, 201, and 206 of Sorenson; Database may be a data store to store medical data such as digital imaging and communications in medicine (DICOM) compatible data, image data, files, or any combination thereof. The in-image analysis module can determine information such as anatomy or modality based on analysis of the image/image volume. Such information can be included in the log file by the tracking module. The log file can be stored in the database and updated.).
Sorenson does not disclose compare the descriptive information with a calculation required information comparison table, wherein if items and contents of the calculation required information are detected to be correct according to the calculation required information comparison table, the calculation required information detection process is further configured to delete all or part of contents from the descriptive information except the contents of the calculation required information by the medical information calculation application.
Berlinger discloses compare the descriptive information with a calculation required information comparison table, wherein if items and contents of the calculation required information are detected to be correct according to the calculation required information comparison table, the calculation required information detection process is further configured to delete all or part of contents from the descriptive information except the contents of the calculation required information by the medical information calculation application (Fig. 3, para. 10, 23, and 370 of Berlinger; Using the strategy Look-up table and a look-up table of each machine (embodying the treatment machine capability data) such as the one shown in Table 2, a simulation on available and suitable treatment machines is executed for the strategy with the highest weight or sum of weights. If the simulation is ok, an identification of the most effective strategy and the corresponding treatment machine or treatment machines are output to the user. For example, the most effective strategy may be determined by the system after the simulation outlined herein. Not only may acquired or input data be verified to prevent possible improper determination of treatment parameters, but techniques may be determined for tumor motion tracking, patient positioning, tumor localization, and as well, determined breathing curves through motion analysis can be accomplished. These determinations result in more accurate, less time consuming and more direct treatment of the tumor by the most appropriate machine, technique and method. This includes such gating and tracking data as well as relative patient position data for proper positioning of the treatment area relative to the radiation source. If the simulation fails, the strategy that failed is deleted from a temporary strategy look-up table, and the temporary strategy look-up table is then fed into sub-step 1) of step S305.).
Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to combine the aforementioned features of Berlinger within Sorenson. The motivation for doing so would have been to determine the most effective strategy (para. 70 of Berlinger).
(B) Referring to claim 2, Sorenson discloses wherein the accompanying descriptive information comprises direct personal information and indirect personal information (para. 183, 154, 55, and 65 of Sorenson).
(C) Referring to claim 3, Sorenson discloses wherein the medical information calculation application comprises a medical information AI model calculation application or a medical information analysis application (para. 155 & 158 of Sorenson).
(D) Referring to claim 4, Sorenson discloses wherein the to-be-processed medical information is a DICOM file, a RTSS file, an NIfTI file, an ANALZE file, a JPG file, a Tiff file, or a Bmp file (para. 58 & 183 of Sorenson).
(E) Referring to claim 6, Sorenson discloses wherein the to-be-processed data is medical image data, physiological signal data, or non-file descriptive text data (para. 43 of Sorenson).
(F) Referring to claim 7, Sorenson discloses A cloud platform service system of medical information, which is used to process the medical information containing descriptive information and to-be-processed data, wherein the medical information is processed to conform a calculation of a selected medical information calculation application, the cloud platform service system comprising (para. 46, 54, and 183 of Sorenson; FIG. 1 is a block diagram illustrating a medical data medical data review system according to one embodiment. Referring to FIG. 1, medical data review system 100 includes one or more client devices 101-102 communicatively coupled to medical image processing server 110 over network 103. Client devices 101-102 can be a desktop, laptop, mobile device, workstation, etc. Network 103 may be a local area network (LAN), a metropolitan area network (MAN), a wide area network (WAN) such as the Internet or an intranet, a private cloud network, a public cloud network, or a combination thereof.):
a computer equipment comprising a calculation required information detection module and a verification information generation module, wherein the calculation required information detection module detects at least one calculation required information required by the calculation of the medical information calculation application from the descriptive information of the medical information (Fig. 6, para. 31, 54, 81, and 183, and 197 of Sorenson; The machine learning module can correlate image data from the medical image data source to a workflow based on in-image analysis and metadata. This workflow can be a unique machine learning module or a collection of machine learning (ensemble) which can provide a unique or a collection of results to be consume within a third-party application. The correlation of the medical data to a machine learning module or collection of machine learning can be done based on pattern extraction, feature extraction or image processing which result of a medical image classification (clusterization). Over time, the machine learning module can optimize and improve the association between the workflow and image data by machine learning based on a series of individual user's inputs, a group of user's inputs from one or more medical institutes over a network, information from the in-image analysis, information from metadata, or patient context or any combination thereof. The machine learning module can associate the series (i.e., image data) with the workflow based on metadata, for example within the DICOM file (e.g., DICOM headers and tags), such as patient ID, accession number, date, time frame, body part, body area, medical condition, encounter, procedure, symptom, description, or any combination thereof, or for example within the HL7 message containing clinical relevant information about the exam request (ORM, ORU etc. . . . ). ), generates to-be-processed medical information based on the to-be-processed data and a remained descriptive information (para. 72, 142, 143, and 183 of Sorenson; If a physician replaces a number in a report with a different measurement value made via a different measurement in the image viewer, the system will prompt the physician to accept the deletion of the old measurement that was replaced, or automatically do this based on this and other preferences. The changes in the findings in the report which were made by the physician's further interrogation and measurements within the images are coordinated such that the original measurements or annotations made in the images by the computer automation methods are removed or replaced. This avoids confusion in the patient record that can occur when images are stored along with the final report, and avoids unnecessary work to delete computer generated findings in the case they are duplicated and not updated. Such workflow confusion and inefficiency is resolved by a bi-directional updating of physician-adjusted, added, or deleted findings within the report and the diagnostic interpretation viewer, irrespective of the point of the change, whether it be the report value that is changed, or the measurement or image process used in the image viewer being adjusted to create a new resultant value. The user can remove the recommended image data and replace with another image data which will update the weight of the result and optimize machine learning module.), and the verification information generation module generates a verification information when the calculation required information detection module generates the to-be-processed medical information after deletion (para. 42, 43, 50, 88, and 98 of Sorenson; the image processing engines are used to confirm or verify findings by the physicians, where the engines operate as medical data review systems. The review system operating as a medical data review system is configured to review the second set of medical images to verify or confirm or unverify or reject the abnormality of the images, generating a second result. A processing engine would then run on both CT studies to compare the two to see if there are any differences. If the most recent report is deemed “no significant interval change,” a medical data review system function can be to run an engine that can verify the similarity, and therefore provide the ability to agree or disagree with that statement. Often, the reported findings are maintained in reports, and electronic communications, which are inputs to the platform and the relevant contents are provided to the engine when it runs.); and
a cloud platform comprising an application server and a network server, wherein the application server at least stores the medical information calculation application, the network server is used to receive the to-be-processed medical information and the verification information from the computer equipment, and after verifying the verification information, to send the to-be-processed medical information to the application server, and the medical information calculation application performs an analysis with the to-be-processed medical information and generates analyzed medical information (see Figures 1 & 15, para. 31, 39, 46, 48, 59, 181, 183, 192, and 197 of Sorenson; The image processing engines 113-115 can be uploaded and listed in a Web server 109, in this example, an application store, to allow a user of clients 101-102 to purchase, select, and download one or more image processing engines as part of client applications 111-112 respectively. The image processing engines 113-115 can be downloaded to client systems 101-102 to perform the operations. Alternatively, the image processing engines 113-115 can be hosted in a cloud-based system, such as an image processing server 110 as a part of software as a service (SaaS) and/or platform as a service (PaaS), to perform the operations and allow authors of engines to control access and maintain versions and regulatory compliance. Image quality needs to be checked and verified before or after any predictive engine is evoked in order to ensure engine standards are met. A machine learning module can receive image data from a medical image data source. The machine learning module can correlate image data from the medical image data source to a workflow based on in-image analysis and metadata.);
wherein the descriptive information comprises personal information used to describe patients, information related to medical units, tests, or information used to describe parameters related to medical images or physiological signal (para. 183 of Sorenson; associate the series (i.e., image data) with the workflow based on metadata, for example within the DICOM file (e.g., DICOM headers and tags), such as patient ID, accession number, date, time frame, body part, body area, medical condition, encounter, procedure, symptom, description, or any combination thereof, or for example within the HL7 message containing clinical relevant information about the exam request (ORM, ORU etc. . . . ). The machine learning module can associate the series with the workflow based on in-image analysis, for example, by reconstructing the image or analyzing the pixel characteristics (e.g., intensity, shading, color, etc.) to determine the anatomy or modality.);
wherein, the descriptive information and the to-be-processed data are stored in one single data file or in separated data files (para. 77, 195, 201, and 206 of Sorenson; Database may be a data store to store medical data such as digital imaging and communications in medicine (DICOM) compatible data, image data, files, or any combination thereof. The in-image analysis module can determine information such as anatomy or modality based on analysis of the image/image volume. Such information can be included in the log file by the tracking module. The log file can be stored in the database and updated.).
Sorenson does not disclose compares the descriptive information with a calculation required information comparison table, wherein if items and contents of the calculation required information are detected to be correct according to the calculation required information comparison table, the calculation required information detection module further deletes all or part of contents from the descriptive information except the contents of the calculation required information by the medical information calculation application.
Berlinger discloses compares the descriptive information with a calculation required information comparison table, wherein if items and contents of the calculation required information are detected to be correct according to the calculation required information comparison table, the calculation required information detection module further deletes all or part of contents from the descriptive information except the contents of the calculation required information by the medical information calculation application (Fig. 3, para. 10, 23, and 370 of Berlinger; Using the strategy Look-up table and a look-up table of each machine (embodying the treatment machine capability data) such as the one shown in Table 2, a simulation on available and suitable treatment machines is executed for the strategy with the highest weight or sum of weights. If the simulation is ok, an identification of the most effective strategy and the corresponding treatment machine or treatment machines are output to the user. For example, the most effective strategy may be determined by the system after the simulation outlined herein. Not only may acquired or input data be verified to prevent possible improper determination of treatment parameters, but techniques may be determined for tumor motion tracking, patient positioning, tumor localization, and as well, determined breathing curves through motion analysis can be accomplished. These determinations result in more accurate, less time consuming and more direct treatment of the tumor by the most appropriate machine, technique and method. This includes such gating and tracking data as well as relative patient position data for proper positioning of the treatment area relative to the radiation source. If the simulation fails, the strategy that failed is deleted from a temporary strategy look-up table, and the temporary strategy look-up table is then fed into sub-step 1) of step S305.).
Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to combine the aforementioned features of Berlinger within Sorenson. The motivation for doing so would have been to determine the most effective strategy (para. 70 of Berlinger).
(G) Referring to claim 8, Sorenson discloses wherein the analyzed medical information and the verification information are transmitted from the network server to the computer equipment through the Internet (para. 54-56, 69, and 181 of Sorenson).
(H) Referring to claim 9, Sorenson discloses wherein the computer equipment recovers the to-be-processed medical information to the medical information based on the verification information (para. 55-58 & 72 of Sorenson).
(I) Referring to claim 10, Sorenson discloses wherein the accompanying descriptive information comprises direct personal information and indirect personal information (para. 183, 154, 55, and 65 of Sorenson).
(J) Referring to claim 11, Sorenson discloses wherein the medical information calculation application comprises a medical information AI model calculation application or a medical information analysis application (para. 155 & 158 of Sorenson).
(K) Referring to claim 12, Sorenson discloses wherein the to-be-processed medical information is a DICOM file, a RTSS file, an NIfTI file, an ANALZE file, a JPG file, a Tiff file, or a Bmp file (para. 58 & 183 of Sorenson).
(L) Referring to claim 14, Sorenson discloses wherein the to-be-processed data is medical image data, physiological signal data, or non-file descriptive text data (para. 43 of Sorenson).
(M) Referring to claim 15, Sorenson discloses A computer equipment, which is applied with a selected medical information calculation application for processing medical information containing descriptive information and to-be-processed data, comprising (para. 54, 81, 181, 183, and 203 of Sorenson):
a calculation required information detection module detecting at least one calculation required information required by a calculation of the medical information calculation application from the descriptive information of the medical information (para. 183 of Sorenson; The machine learning module can correlate image data from the medical image data source to a workflow based on in-image analysis and metadata. This workflow can be a unique machine learning module or a collection of machine learning (ensemble) which can provide a unique or a collection of results to be consume within a third-party application. The correlation of the medical data to a machine learning module or collection of machine learning can be done based on pattern extraction, feature extraction or image processing which result of a medical image classification (clusterization). Over time, the machine learning module can optimize and improve the association between the workflow and image data by machine learning based on a series of individual user's inputs, a group of user's inputs from one or more medical institutes over a network, information from the in-image analysis, information from metadata, or patient context or any combination thereof. The machine learning module can associate the series (i.e., image data) with the workflow based on metadata, for example within the DICOM file (e.g., DICOM headers and tags), such as patient ID, accession number, date, time frame, body part, body area, medical condition, encounter, procedure, symptom, description, or any combination thereof, or for example within the HL7 message containing clinical relevant information about the exam request (ORM, ORU etc. . . . ). ), generates to-be-processed medical information based on the to-be-processed data and a remained descriptive information after deletion (para. 72, 142, 143, and 183 of Sorenson; If a physician replaces a number in a report with a different measurement value made via a different measurement in the image viewer, the system will prompt the physician to accept the deletion of the old measurement that was replaced, or automatically do this based on this and other preferences. The changes in the findings in the report which were made by the physician's further interrogation and measurements within the images are coordinated such that the original measurements or annotations made in the images by the computer automation methods are removed or replaced. This avoids confusion in the patient record that can occur when images are stored along with the final report, and avoids unnecessary work to delete computer generated findings in the case they are duplicated and not updated. Such workflow confusion and inefficiency is resolved by a bi-directional updating of physician-adjusted, added, or deleted findings within the report and the diagnostic interpretation viewer, irrespective of the point of the change, whether it be the report value that is changed, or the measurement or image process used in the image viewer being adjusted to create a new resultant value. The user can remove the recommended image data and replace with another image data which will update the weight of the result and optimize machine learning module.); and
a verification information generation module generating a verification information when the calculation required information detection module generates the to-be-processed medical information (para. 42, 43, 50, 88, and 98 of Sorenson; the image processing engines are used to confirm or verify findings by the physicians, where the engines operate as medical data review systems. The review system operating as a medical data review system is configured to review the second set of medical images to verify or confirm or unverify or reject the abnormality of the images, generating a second result. A processing engine would then run on both CT studies to compare the two to see if there are any differences. If the most recent report is deemed “no significant interval change,” a medical data review system function can be to run an engine that can verify the similarity, and therefore provide the ability to agree or disagree with that statement. Often, the reported findings are maintained in reports, and electronic communications, which are inputs to the platform and the relevant contents are provided to the engine when it runs.);
wherein the descriptive information comprises personal information used to describe patients, information related to medical units, tests, or information used to describe parameters related to medical images or physiological signal (para. 183 of Sorenson; associate the series (i.e., image data) with the workflow based on metadata, for example within the DICOM file (e.g., DICOM headers and tags), such as patient ID, accession number, date, time frame, body part, body area, medical condition, encounter, procedure, symptom, description, or any combination thereof, or for example within the HL7 message containing clinical relevant information about the exam request (ORM, ORU etc. . . . ). The machine learning module can associate the series with the workflow based on in-image analysis, for example, by reconstructing the image or analyzing the pixel characteristics (e.g., intensity, shading, color, etc.) to determine the anatomy or modality.);
wherein, the descriptive information and the to-be-processed data are stored in one single data file or in separated data files (para. 77, 195, 201, and 206 of Sorenson; Database may be a data store to store medical data such as digital imaging and communications in medicine (DICOM) compatible data, image data, files, or any combination thereof. The in-image analysis module can determine information such as anatomy or modality based on analysis of the image/image volume. Such information can be included in the log file by the tracking module. The log file can be stored in the database and updated.).
Sorenson does not disclose comparing the descriptive information with a calculation required information comparison table, wherein if items and contents of the calculation required information are detected to be correct according to the calculation required information comparison table, the calculation required information detection module further deletes all or part of contents from the descriptive information except the contents of the calculation required information by the medical information calculation application.
Berlinger discloses comparing the descriptive information with a calculation required information comparison table, wherein if items and contents of the calculation required information are detected to be correct according to the calculation required information comparison table, the calculation required information detection module further deletes all or part of contents from the descriptive information except the contents of the calculation required information by the medical information calculation application (Fig. 3, para. 10, 23, and 370 of Berlinger; Using the strategy Look-up table and a look-up table of each machine (embodying the treatment machine capability data) such as the one shown in Table 2, a simulation on available and suitable treatment machines is executed for the strategy with the highest weight or sum of weights. If the simulation is ok, an identification of the most effective strategy and the corresponding treatment machine or treatment machines are output to the user. For example, the most effective strategy may be determined by the system after the simulation outlined herein. Not only may acquired or input data be verified to prevent possible improper determination of treatment parameters, but techniques may be determined for tumor motion tracking, patient positioning, tumor localization, and as well, determined breathing curves through motion analysis can be accomplished. These determinations result in more accurate, less time consuming and more direct treatment of the tumor by the most appropriate machine, technique and method. This includes such gating and tracking data as well as relative patient position data for proper positioning of the treatment area relative to the radiation source. If the simulation fails, the strategy that failed is deleted from a temporary strategy look-up table, and the temporary strategy look-up table is then fed into sub-step 1) of step S305.).
Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to combine the aforementioned features of Berlinger within Sorenson. The motivation for doing so would have been to determine the most effective strategy (para. 70 of Berlinger).
(N) Referring to claim 16, Sorenson discloses wherein the accompanying descriptive information comprises direct personal information and indirect personal information (para. 183, 154, 55, and 65 of Sorenson).
(O) Referring to claim 17, Sorenson discloses wherein the medical information calculation application comprises a medical information AI model calculation application or a medical information analysis application (para. 155 & 158 of Sorenson).
(P) Referring to claim 18, Sorenson discloses wherein the to-be-processed medical information is a DICOM file, a RTSS file, an NIfTI file, an ANALZE file, a JPG file, a Tiff file, or a Bmp file (para. 58 & 183 of Sorenson).
(Q) Referring to claim 20, Sorenson discloses wherein the to-be-processed data is medical image data, physiological signal data, or non-file descriptive text data (para. 43 of Sorenson).
Claim(s) 5, 13, and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Sorenson et al. (US 2018/0137244 A1) in view of Berlinger et al. (US 2021/0046328 A1), and further in view of Dicks et al. (US 2008/0097552 A1).
(A) Referring to claims 5, 13, and 19, Sorenson and Berlinger do not disclose wherein the to-be-processed medical information is an EDF file, a BrainVision Analyzer file, a BDF file, a common sports biomechanical data file, or an ASCII text file.
Dicks discloses wherein the to-be-processed medical information is an EDF file, a BrainVision Analyzer file, a BDF file, a common sports biomechanical data file, or an ASCII text file (para. 127 of Dicks).
Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to modify the information in Sorenson and Berlinger to include the aforementioned feature of Dicks. The motivation for doing so would have been to send, receive, and process machine-readable data can in any standard format (para. 127 of Dicks).
Response to Arguments
Applicant’s arguments with respect to claim(s) 1, 7, and 15 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Applicant's additional arguments filed 4/1/26 have been fully considered but they are not persuasive. Applicant’s arguments will be addressed hereinbelow in the order in which they appear in the response filed 4/1/26.
(1) Applicants respectfully request withdrawal of the § 101 rejection.
(2) Applicant argues that Sorenson fails to disclose each and every element of amended independent claims 1, 7 and 15, arranged as recited, and therefore cannot anticipate claims 1, 7 and 15 under 35 U.S.C. §102.
(A) As per the first argument, see 101 rejection above. The limitations of claims 1, 7, and 15, as drafted, is a process that, under its broadest reasonable interpretation, covers certain methods of organizing human activity but for the recitation of generic computer components. That is, other than reciting a cloud platform service system, computer equipment, cloud platform, modules, an application, an application server, and a network server to perform the limitations, nothing in the claim elements precludes the steps from practically being certain methods of organizing human activity. If a claim limitation, under its broadest reasonable interpretation, covers certain methods of organizing human activity but for the recitation of generic computer components, then it falls within the “certain methods of organizing human activity” grouping of abstract ideas. Accordingly, the claims recite an abstract idea.
This judicial exception is not integrated into a practical application. In particular, the cloud platform service system, computer equipment, cloud platform, modules, application, application server, and network server are recited at a high-level of generality (i.e., as generic computer components performing generic computer functions of comparing information, detecting information, generating information, deleting information, receiving information, sending information, analyzing information, and storing data) such that it amounts no more than mere instructions to apply the exception using generic computer components. Accordingly, 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. Regarding the additional limitations directed to storing information/data in data files, a server storing an application, and a server receiving/sending information, all of which the Examiner submits merely add insignificant extra-solution activity to the abstract idea or are claimed in a merely generic manner (e.g., at a high level of generality), the Examiner further submits that such steps are not unconventional as they merely consist of storing and retrieving information in memory and receiving and transmitting data over a network. See MPEP 2106.05(d)(II). Regarding the “software per se” rejection of claim 15, the body of the claim still lacks hardware components. As such, the rejection remains.
(B) As per the second argument, Examiner disagrees that Sorenson does not disclose “the calculation required information detection process is further configured to generate to-be-processed medical information based on the to-be-processed data and a remained descriptive information after deletion.” See at least paragraphs 72, 142, 143, and 183 of Sorenson. Note that Sorenson discloses “If a physician replaces a number in a report with a different measurement value made via a different measurement in the image viewer, the system will prompt the physician to accept the deletion of the old measurement that was replaced, or automatically do this based on this and other preferences. The changes in the findings in the report which were made by the physician's further interrogation and measurements within the images are coordinated such that the original measurements or annotations made in the images by the computer automation methods are removed or replaced. This avoids confusion in the patient record that can occur when images are stored along with the final report, and avoids unnecessary work to delete computer generated findings in the case they are duplicated and not updated. Such workflow confusion and inefficiency is resolved by a bi-directional updating of physician-adjusted, added, or deleted findings within the report and the diagnostic interpretation viewer, irrespective of the point of the change, whether it be the report value that is changed, or the measurement or image process used in the image viewer being adjusted to create a new resultant value. The user can remove the recommended image data and replace with another image data which will update the weight of the result and optimize machine learning module.” Furthermore, note that the claim recites conditional language such as “if” and “when.” As such, it is unclear how the language of the claim differs from the applied prior art.
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 LENA NAJARIAN whose telephone number is (571)272-7072. The examiner can normally be reached Monday - Friday 9:30 am-6 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, Mamon Obeid can be reached at (571)270-1813. 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.
/LENA NAJARIAN/Primary Examiner, Art Unit 3687
Prosecution Insights