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 .
Acknowledgements
This communication is in response to Remarks filed on 3/2/2026.
Claims 1, 2, 4, 7, 13, 17, 20 are amended.
Claim 21 is canceled.
Claims 1-20 are pending and have been examined and rejected as follows.
Continued Examination Under 37 CFR 1.114
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 3/2/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-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, 13 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claim recites a method and system for providing dose data.
The limitations of receiving, […], study data according to at least one selection criterion from an image archiving and communication system […]; uploading, […], first dose data based upon the study data received, […], the first dose data including or indicating at least one respective unique study-identifying characteristic value; checking, via a dose data provisioning module […], checking whether a trigger condition is present; producing a user token to obtain an item of association information between the at least one respective unique study-identifying characteristic value and a corresponding deidentified unique study-identifying characteristic value, the user token produced based on a service access token provided to an apparatus of the local […] via a reactive pull module of the dose data provisioning module, the corresponding de-identified unique study-identifying characteristic value containing no patient specific data; downloading, […], upon the checking indicating a presence of the trigger condition, second dose data based upon the first dose data […], the second dose data including or indicating a respective unique study-identifying characteristic value; and providing the second dose data to a reporting system or another local apparatus […], either automatically or upon a provisioning condition being fulfilled, wherein the trigger condition […] provided by a reactive pull module of the dose provisioning module, […] including at least one respective unique study-identifying characteristic value and a service access token as a parameter of the […]., 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 recitation of generic computer components. This claim encompasses a person receiving data, checking whether a trigger condition is present, and then providing data in the manner described in the identified abstract idea, supra. The Examiner notes that certain “method[s] of organizing human activity” includes a person’s interaction with a computer (see MPEP 2106.04(a)(2)(II)). 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” 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, the claim recites the additional element of a local intranet, cloud-based, and receiving a call from a URL that implements the identified abstract idea. The local intranet, cloud-based, and receiving a call from a URL is not described by the applicant and is recited at a high-level of generality (i.e., a generic intranet, cloud, and URL performing a generic functions) such that it amounts no more than mere instructions to apply the exception using a generic computer component. Accordingly, this additional element does 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.
The claim further recites the two additional elements of (1) downloading data and (2) uploading data. Each of these transmitting steps are recited at a high level of generality (i.e., as a general means of transmitting data) and amounts to the mere transmission of data, which is a form of extra-solution activity. MPEP 2106.04(d)(I) indicates that extra-solution data gathering activity cannot provide a practical application. Accordingly, even in combination, these additional elements do not integrate the abstract idea into a practical application. The claim is directed to an abstract idea.
Step 2B
The claim does 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 element of a local intranet, cloud-based, and receiving a call from a URL 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”).
Also, as discussed above with respect to integration of the abstract idea into a practical application, the additional elements of (1) downloading data and (2) uploading data were considered extra-solution activity. This has been re-evaluated under the “significantly more” analysis and determined to be well-understood, routine, conventional activity in the field. MPEP 2016.05(d)(II) indicates that receiving and/or transmitting data over a network has been held by the courts to be well-understood, routine, conventional activity (citing Symantec, TLI Communications, OIP Techs., and buySAFE). Well-understood, routine, conventional activity cannot provide an inventive concept (“significantly more”). As such the claim is not patent eligible.
Dependent Claims
Claims 2-12, 14-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 2 merely describes the study identifying value. Claim 5, 18 merely describes the local apparatus is a radiology information system. Claim 6, 19 merely describes the proactive push module. Claim 7, 20 merely describes de-identifying data. Claim 8 merely describes the second dose data. Claim 9 merely describes the provisioning condition checking whether an incomplete order is on the system. Claim 10 merely describes a dose registration module to provide data to a registry of a national dose registry computing facility. Claim 11 merely describes a registry site service system of a national dose registry system notifying the dose registration module of new data and uploading new data. Claim 12 merely describes functioning as a global dose registry, contrast management system or protocol management system.
Claims 3-4, 16-17 also includes the additional element of “a URL” which is analyzed the same as in the independent claim and does not provide a practical application or significantly more for the same reasons. Claim 3, 16 merely describes the URL and the second dose data. Claim 4, 17 merely describes the reactive pull module and authentication.
Claims 14 also includes the additional element of a non-transitory computer program product storing executable program code which is recited at a high-level of generality (i.e., a generic computer performing a generic computer functions) such that it amounts no more than mere instructions to apply the exception using a generic computer component. Accordingly, this additional element does 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. As discussed above with respect to integration of the abstract idea into a practical application, the additional element of using a non-transitory computer program product storing executable program code 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”). Accordingly, even in combination, this additional element does not provide significantly more. As such the claim is not patent eligible. Claim 14 merely describes a non-transitory computer program product to execute claim 1.
Claims 15 also includes the additional element of a non-transitory computer-readable, non-volatile data storage medium storing executable program code which is recited at a high-level of generality (i.e., a generic computer performing a generic computer functions) such that it amounts no more than mere instructions to apply the exception using a generic computer component. Accordingly, this additional element does 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. As discussed above with respect to integration of the abstract idea into a practical application, the additional element of using a non-transitory computer-readable, non-volatile data storage medium storing executable program code 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”). Accordingly, even in combination, this additional element does not provide significantly more. As such the claim is not patent eligible. Claim 15 merely describes a non transitory computer readable medium storing code to execute the method of claim 1.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-3, 5, 7-8, 13-16, 20-21 are rejected under 35 U.S.C. 103 as being unpatentable over Moore (US 20150356258) in view of Kohli (US 20190156921) in view of Clough (20030182363) in view of Sanso (US 20170012980)
Claim 1, 13:
Moore teaches:
A method (method) for
[0005] A novel system and method for radiation dose monitoring is presented.
A system (system) for
[0005] A novel system and method for radiation dose monitoring is presented.
providing dose data (dose monitoring) from a cloud-based (cloud-based) dose management system (system) in a local Intranet (intranet), comprising:
[0005] A novel system and method for radiation dose monitoring is presented.
[0016] The database 103 and the application server 105 can be cloud-based.
[0017] The network 111 can be a local area network (LAN), intranet, internet, or any other communication network as known to one skilled in the art.
a medicine data gateway (inventive system, login), within a local Intranet (intranet) of the system, the medicine data gateway (inventive system, login) being embodied to execute a dose data provisioning module (application server); a reporting system (push notifications), within the local Intranet (intranet); and a cloud-based (cloud-based) dose management system (system), outside of the local Intranet (internet);
[0005] A novel system and method for radiation dose monitoring is presented.
[0016] FIG. 1 is a high-level architectural schematic of an embodiment of the inventive system. As shown in FIG. 1, the system has one or more scanners 101, a database 103 in which data including dose information is stored, and an application server 105 having memory in which algorithms for performing dose monitoring in accordance with the present invention are stored. […] The database 103 and the application server 105 can be cloud-based.
[0017] The network 111 can be a local area network (LAN), intranet, internet, or any other communication network as known to one skilled in the art.
[0018] In one aspect, the scanner is automatically logged into the inventive system. In step S203, the login can be performed by HTML 5 login procedures. Each technologist login requires user specific credentials. The system will automatically register to the CT scanner based on the location of the computer used to log into the system. An administrator log-in is also available; this will allow an administrator to monitor all radiation producing units at his or her facility.
[0054] In one embodiment, the cloud-based automated dose-tracking platform can use HTML5 push notifications to generate custom dose printouts or cards as soon as an examination is processed
receiving, at a medicine data gateway (inventive system, login) within the local Intranet (intranet), study data (scan, or radiation dose) according to at least one selection criterion (scan, or radiation dose, optional step s206, the collected data is converted and effective dose data is obtained at the time of the scan) from an image archiving and communication system (radiation producing unit, modern equipment produces a Digital Imaging and Communication in Medicine (DICOM) public field called DICOM SR (Structured Report)) within the local Intranet (intranet);
[0017] The network 111 can be a local area network (LAN), intranet, internet, or any other communication network as known to one skilled in the art.
[0018] In one aspect, the scanner is automatically logged into the inventive system. In step S203, the login can be performed by HTML 5 login procedures. Each technologist login requires user specific credentials. The system will automatically register to the CT scanner based on the location of the computer used to log into the system. An administrator log-in is also available; this will allow an administrator to monitor all radiation producing units at his or her facility.
[0021] In step S205, scan, or radiation dose, data is collected and stored in the database 103. In one embodiment, in optional step S206, the collected data is converted and effective dose data is obtained at the time of the scan. Dose data can be received and collected from the radiation producing unit in different ways. For example, modern equipment produces a Digital Imaging and Communication in Medicine (DICOM) public field called DICOM SR (Structured Report).
Uploading (store), via the medicine data gateway (inventive system, login), at least first dose data (data) based upon the study data (scan, or radiation dose) received, into the cloud- based (cloud-based) dose management system (system), the first dose data (data) including or indicating at least one respective unique study- identifying characteristic value (CTDI volume, DLP, technologist name, and all other DICOM fields, in addition to patient demographics, medical record number or identifier) ;
[0005] A novel system and method for radiation dose monitoring is presented. The system uses a particular study (e.g., patient-centered) approach to radiation dose tracking that empowers imaging centers, interventionalists and affiliated services to rapidly track patient specific radiation doses.
[0016] The database 103 and the application server 105 can be cloud-based.
[0018] In one aspect, the scanner is automatically logged into the inventive system. In step S203, the login can be performed by HTML 5 login procedures. Each technologist login requires user specific credentials. The system will automatically register to the CT scanner based on the location of the computer used to log into the system. An administrator log-in is also available; this will allow an administrator to monitor all radiation producing units at his or her facility.
[0021] In step S205, scan, or radiation dose, data is collected and stored in the database 103. In one embodiment, in optional step S206, the collected data is converted and effective dose data is obtained at the time of the scan. Dose data can be received and collected from the radiation producing unit in different ways. For example, modern equipment produces a Digital Imaging and Communication in Medicine (DICOM) public field called DICOM SR (Structured Report). In this report, the radiation dose parameters are displayed. The inventive system can collect the DICOM SR information and store the appropriate information. In one embodiment, the dose data can be converted in step S206. However, older equipment (the majority of the equipment available in the United States at present) does not conform to DICOM. Hence, the dose data can be collected by performing Optical Character Recognition (OCR) on the dose sheets. Typically, CTDI volume, DLP, technologist name, and all other DICOM fields, in addition to patient demographics, are collected and sent to the database 103.
[0044] In one aspect, dose information has internal references to identifying patient information such as medical record number or identifier, in a HIPAA compliant manner
[…] , via a dose data provisioning module (application server) executed in the medicine data gateway (inventive system, login) within the local Intranet (intranet), […]
[0016] FIG. 1 is a high-level architectural schematic of an embodiment of the inventive system. As shown in FIG. 1, the system has one or more scanners 101, a database 103 in which data including dose information is stored, and an application server 105 having memory in which algorithms for performing dose monitoring in accordance with the present invention are stored.
[0017] The network 111 can be a local area network (LAN), intranet, internet, or any other communication network as known to one skilled in the art.
[0018] In one aspect, the scanner is automatically logged into the inventive system. In step S203, the login can be performed by HTML 5 login procedures. Each technologist login requires user specific credentials. The system will automatically register to the CT scanner based on the location of the computer used to log into the system. An administrator log-in is also available; this will allow an administrator to monitor all radiation producing units at his or her facility.
[0022] In step S207, after the examination, e.g., after operation of the scanner, the effective dose data is compared to baseline data obtained from the database 103. In step S209, the radiation dose is monitored for a particular patient and a customized, branded dose card and/or a printout of the dose data for the patient is generated. In one aspect, the radiation dose is monitored in accordance with “monitor data” which can be one of effective dose data, CTDI volume or DLP.
producing […] the at least one respective unique study-identifying characteristic value and a corresponding […] unique study-identifying characteristic value, the […] of the local Intranet […] of the dose data provisioning module, the corresponding […] unique study-identifying characteristic value containing no patient specific data (Moore para 21 teach CTDI volume, DLP, technologist name, and all other DICOM fields, in addition to patient demographics, are collected. Para 17 teaches intranet. )
downloading via the dose data provisioning module (application server) […], second dose data (dose card) based upon the first dose data (dose data) from the cloud-based (cloud-based) dose management system, the second dose data (dose card) including or indicating a respective unique study-identifying characteristic value (customized, branded, effective dose data, CTDI volume or DLP, medical record number or identifier); and
[0016] FIG. 1 is a high-level architectural schematic of an embodiment of the inventive system. As shown in FIG. 1, the system has one or more scanners 101, a database 103 in which data including dose information is stored, and an application server 105 having memory in which algorithms for performing dose monitoring in accordance with the present invention are stored. […] The database 103 and the application server 105 can be cloud-based.
[0022] In step S207, after the examination, e.g., after operation of the scanner, the effective dose data is compared to baseline data obtained from the database 103. In step S209, the radiation dose is monitored for a particular patient and a customized, branded dose card and/or a printout of the dose data for the patient is generated. In one aspect, the radiation dose is monitored in accordance with “monitor data” which can be one of effective dose data, CTDI volume or DLP.
[0044] In one aspect, dose information has internal references to identifying patient information such as medical record number or identifier, in a HIPAA compliant manner
providing the second dose data (dose card) to a reporting system (push notifications) or another local apparatus (printer, display on UI) within the local Intranet (intranet), either automatically (automated) or […]. (Examiner interprets additional limitation as optional due to claim language “or …”)
[0016] The results can be displayed by the system on the display of the UI 107 and/or printed on a printer 109
[0022] In step S207, after the examination, e.g., after operation of the scanner, the effective dose data is compared to baseline data obtained from the database 103. In step S209, the radiation dose is monitored for a particular patient and a customized, branded dose card and/or a printout of the dose data for the patient is generated. In one aspect, the radiation dose is monitored in accordance with “monitor data” which can be one of effective dose data, CTDI volume or DLP.
[0036] In one embodiment, automated dose-entry workflow allows the performing technologist to access a secure portal with the ability to generate a patient printout (or dose card) for communication.
[0054] In one embodiment, the cloud-based automated dose-tracking platform can use HTML5 push notifications to generate custom dose printouts or cards as soon as an examination is processed
Moore does not teach:
checking, via a dose data provisioning module executed in the medicine data gateway within the local Intranet, whether a trigger condition is present;
producing a user token to obtain an item of association information between the at least one respective unique study-identifying characteristic value and a corresponding de-identified unique study-identifying characteristic value, the user token produced based on a service access token provided […] of the local Intranet […] of the dose data provisioning module, the corresponding de-identified unique study-identifying characteristic value containing no patient specific data
downloading via the dose data provisioning module, upon the checking indicating a presence of the trigger condition, second dose data based upon the first dose data from the cloud-based dose management system, the second dose data including or indicating a respective unique study-identifying characteristic value; and
Kohli does teach:
checking, via a dose data provisioning module executed in the medicine data gateway within the local Intranet, whether a trigger condition (data source triggers) is present;
producing a user token to obtain an item of association information between the at least one respective unique study-identifying characteristic value and a corresponding de-identified unique study-identifying characteristic value, the user token produced based on a service access token provided […] of the local Intranet […] of the dose data provisioning module, the corresponding de-identified unique study-identifying characteristic value containing no patient specific data (Kohli para 58 teaches a key and de-identified health information)
downloading via the dose data provisioning module, upon the checking indicating a presence of the trigger condition (incoming data), second dose data based upon the first dose data from the cloud-based dose management system, the second dose data including or indicating a respective unique study-identifying characteristic value; and
[0052] In certain examples, an apparatus responds to data source events through data source triggers and/or polling.
[0105] Data source events (e.g., new documents, updated documents, lab results, exams for review, and/or other medical information, etc.) are pushed or pulled from the data source 402 to the IRCC processor 404 to trigger processing of the data from the data source. Once data is received from the data source 402 at the IRCC processor 404, the IRCC processor 404 processes the data to enrich the data and provide an indication of relevancy of the data to one or more clinical scenarios.
See also [0142]
It would have been obvious to one or ordinary skill in the art, before the effective filing date of the claimed invention, to modify the data provisioning module as taught by Moore with the checking for a trigger condition and deidentifying and reidentifying health data with a key as taught by Kohli. It would be beneficial to check for a trigger condition in order to have more context to interpret symptoms more accurately and de-identify and re-identify health information for security as taught by Kohli para 35, 58.
Moore in view of Kohli do not teach:
producing a user token to obtain an item of association information between the at least one respective unique study-identifying characteristic value and a corresponding deidentified unique study-identifying characteristic value, the user token produced based on a service access token provided to an apparatus of the local Intranet via a reactive pull module of the dose data provisioning module, the corresponding de-identified unique study-identifying characteristic value containing no patient specific data;
Wherein the trigger condition includes receiving a call from a URL provided by a reactive pull module of the dose provisioning module, the URL including at least one respective unique study-identifying characteristic value
Clough does teach:
producing a user token to obtain an item of association information between the at least one respective unique study-identifying characteristic value and a corresponding deidentified unique study-identifying characteristic value, the user token produced based on a service access token provided to an apparatus of the local Intranet via a reactive pull module of the dose data provisioning module, the corresponding de-identified unique study-identifying characteristic value containing no patient specific data; (Para 4 teaches providing network local resource access to a locally remote device. Para 23 teaches the URL can be mapped to a particular local resource to point to different web services and the URL may use HTTPS headers to determine destination resources. )
Wherein the trigger condition includes receiving a call from a URL provided by a reactive pull module of the dose provisioning module, the URL including at least one respective unique study-identifying characteristic value (Para 4 teaches providing network local resource access to a locally remote device. Para 23 teaches the URL can be mapped to a particular local resource to point to different web services and the URL may use HTTPS headers to determine destination resources. )
It would have been prima facie obvious to one of ordinary skill in the art at the time the invention was made to combine the noted features of Moore in view of Kohli with teaching of Clough since the combination of the two references is merely combining prior art elements according to known methods to yield predictable results (KSR rational A); see MPEP 2143(I)(A)). It can be seen that each element claimed is present in either Moore in view of Kohli or Clough. A URL provided by a reactive pull module and apparatus as taught by Clough does not change or affect the normal providing of dose data. Providing dose data would be performed the same way even with the addition of a URL provided by a reactive pull module and apparatus. Since the functionalities of the elements in Moore in view of Kohli and Clough do not interfere with each other, the results of the combination would be predictable.
Moore in view of Kohli in view of Clough does not teach
wherein the trigger condition includes receiving a call from a URL provided by a reactive pull module of the dose provisioning module, the URL including the at least one respective unique study-identifying characteristic value and a service access token as a parameter of the URL.
Sanso does teach
wherein the trigger condition includes receiving a call from a URL provided by a reactive pull module of the dose provisioning module, the URL including the at least one respective unique study-identifying characteristic value and a service access token as a parameter of the URL. (Sanso para 10 teaches adding an access token to a URL)
It would have been obvious to one or ordinary skill in the art, before the effective filing date of the claimed invention, to modify the URL as taught by Moore in view of Kohli in view of Clough with the access token as taught by Sanso. It would be beneficial to have security as taught by Sanso para 8-9.
Claim 2:
Moore teaches:
The method of claim 1, wherein at least one respective unique study- identifying characteristic value (customized, branded, effective dose data, CTDI volume or DLP, medical record number or identifier) is at least one of or is based on at least one of:[…]; a patient identification characteristic value (medical record number or identifier); […]. (Examiner interprets additional limitations as optional due to claim language "at least one of")
[0021] Typically, CTDI volume, DLP, technologist name, and all other DICOM fields, in addition to patient demographics, are collected and sent to the database
[0044] In one aspect, dose information has internal references to identifying patient information such as medical record number or identifier, in a HIPAA compliant manner
Claim 3, 16:
Moore teaches wherein the […] a local apparatus within the local Intranet, to request the second dose data via the local apparatus; and wherein the second dose data is provided by the reactive pull module the local apparatus. (Moore para 16 teaches a printer (local apparatus) which may connect via a network to the database and para 22 teaches this connection may be used to print a dose card)
Moore does not teach wherein the URL is callable by the local apparatus within the local Intranet, to request the second dose data via the local apparatus; and wherein the second dose data is provided by the reactive pull module of the local apparatus
Clough does teach wherein the URL is callable by the local apparatus within the local Intranet, to request the second dose data via the local apparatus; and wherein the second dose data is provided by the reactive pull module of the local apparatus. (Clough para 4 teaches LAN connected to any number of resources or peripherals for access and use of resources and data. Para 8 teaches access to a logically remote device. Para 23 teaches access to a particular resource via a URL that may point to any local device and headers to determine destination resources and commands embedded in data post. )
It would have been prima facie obvious to one of ordinary skill in the art at the time the invention was made to combine the noted features of Moore in view of Kohli in view of Clough in view of Sanso with the teaching of Clough since the combination of the two references is merely combining prior art elements according to known methods to yield predictable results (KSR rational A); see MPEP 2143(I)(A)). It can be seen that each element claimed is present in either Moore in view of Kohli in view of Clough in view of Sanso or Clough. A callable URL as taught by Clough does not change or affect the normal providing of dose data. Providing dose data would be performed the same way even with the addition of a callable URL. Since the functionalities of the elements in Moore in view of Kohli in view of Clough in view of Sanso and Clough do not interfere with each other, the results of the combination would be predictable.
Claim 5:
Moore in view of Kohli in view of Clough in view of Sanso teach:
The method of claim 3, […]
Moore further teaches:
wherein the local apparatus is a radiology information system (radiology reports).
[0052] Data communication options can include patient health records, radiology reports
Claim 7, 20:
Moore teaches:
wherein the medicine data gateway (inventive system) […] dose data (data) and uploads the first dose data (data) […] into the cloud-based (cloud-based) dose management system (system); and wherein the medicine data gateway (inventive system) […] the second dose data (dose card) based upon the respective unique study-identifying characteristic value (CTDI volume, DLP, technologist name, and all other DICOM fields, in addition to patient demographics, medical record number or identifier).
[0005] A novel system and method for radiation dose monitoring is presented. The system uses a particular study (e.g., patient-centered) approach to radiation dose tracking that empowers imaging centers, interventionalists and affiliated services to rapidly track patient specific radiation doses.
[0016] The database 103 and the application server 105 can be cloud-based.
[0018] In one aspect, the scanner is automatically logged into the inventive system. In step S203, the login can be performed by HTML 5 login procedures. Each technologist login requires user specific credentials. The system will automatically register to the CT scanner based on the location of the computer used to log into the system. An administrator log-in is also available; this will allow an administrator to monitor all radiation producing units at his or her facility.
[0021] In step S205, scan, or radiation dose, data is collected and stored in the database 103. In one embodiment, in optional step S206, the collected data is converted and effective dose data is obtained at the time of the scan. Dose data can be received and collected from the radiation producing unit in different ways. For example, modern equipment produces a Digital Imaging and Communication in Medicine (DICOM) public field called DICOM SR (Structured Report). In this report, the radiation dose parameters are displayed. The inventive system can collect the DICOM SR information and store the appropriate information. In one embodiment, the dose data can be converted in step S206. However, older equipment (the majority of the equipment available in the United States at present) does not conform to DICOM. Hence, the dose data can be collected by performing Optical Character Recognition (OCR) on the dose sheets. Typically, CTDI volume, DLP, technologist name, and all other DICOM fields, in addition to patient demographics, are collected and sent to the database 103.
[0022] In step S207, after the examination, e.g., after operation of the scanner, the effective dose data is compared to baseline data obtained from the database 103. In step S209, the radiation dose is monitored for a particular patient and a customized, branded dose card and/or a printout of the dose data for the patient is generated. In one aspect, the radiation dose is monitored in accordance with “monitor data” which can be one of effective dose data, CTDI volume or DLP.
[0044] In one aspect, dose information has internal references to identifying patient information such as medical record number or identifier, in a HIPAA compliant manner
[0046] In one embodiment, the cloud stores encrypted dose information using an elastic, scalable, and relational database adhering to the necessary HIPAA requirements. Data can be transferred securely to a remote location via the Health Level 7 protocol or API integration, which can be integrated with internal EMR systems or decision systems in a customized institution specific fashion. Advantages of cloud architecture can include significantly reduced costs and improved scalability.
Moore does not teach:
wherein the medicine data gateway de-identifies the first dose data and uploads the first dose data in de-identified form into the cloud-based dose management system; and wherein the medicine data gateway re-identifies the downloaded second dose data based upon the respective unique study-identifying characteristic value.
Kohli does teach:
wherein the medicine data gateway de-identifies (de-identified) the first dose data and uploads the first dose data in de-identified (de-identified) form into the cloud-based dose management system; and wherein the medicine data gateway re-identifies (re-identified) the downloaded second dose data based upon the respective unique study-identifying characteristic value.
[0058] In some examples, PHI that has been “de-identified” can be re-identified based on a key and/or other encoder/decoder.;.
It would have been prima facie obvious to one of ordinary skill in the art at the time the invention was made to combine the noted features of Moore in view of Kohli in view of Clough in view of Sanso with teaching of Kohli since the combination of the two references is merely combining prior art elements according to known methods to yield predictable results (KSR rational A); see MPEP 2143(I)(A)). It can be seen that each element claimed is present in either Moore in view of Kohli in view of Clough in view of Sanso or Kohli. Deidentifying and reidentifying health data as taught by Kohli does not change or affect the normal uploading of data. Uploading data would be performed the same way even with the addition of deidentifying and reidentifying data. Since the functionalities of the elements in Moore in view of Kohli in view of Clough in view of Sanso and Kohli do not interfere with each other, the results of the combination would be predictable.
Claim 8:
Moore teaches:
wherein information about at least one of a standard protocol mapping (DICOM) and standard reference values (national mean radiation dose) is provided as part of the second dose data (dose card) or in addition to the second dose data (dose card).
[0021] In step S205, scan, or radiation dose, data is collected and stored in the database 103. In one embodiment, in optional step S206, the collected data is converted and effective dose data is obtained at the time of the scan. Dose data can be received and collected from the radiation producing unit in different ways. For example, modern equipment produces a Digital Imaging and Communication in Medicine (DICOM) public field called DICOM SR (Structured Report). In this report, the radiation dose parameters are displayed. The inventive system can collect the DICOM SR information and store the appropriate information. In one embodiment, the dose data can be converted in step S206. However, older equipment (the majority of the equipment available in the United States at present) does not conform to DICOM. Hence, the dose data can be collected by performing Optical Character Recognition (OCR) on the dose sheets. Typically, CTDI volume, DLP, technologist name, and all other DICOM fields, in addition to patient demographics, are collected and sent to the database 103.
[0022] In step S207, after the examination, e.g., after operation of the scanner, the effective dose data is compared to baseline data obtained from the database 103. In step S209, the radiation dose is monitored for a particular patient and a customized, branded dose card and/or a printout of the dose data for the patient is generated. In one aspect, the radiation dose is monitored in accordance with “monitor data” which can be one of effective dose data, CTDI volume or DLP.
[0024] In one embodiment, the inventive system is based in cloud architecture which enables assessment of the data for multiple facilities. In one embodiment, the mean radiation dose at a thirty day running average can be displayed for each different type of imaging study. The cloud architecture allows for display on an HTML 5 graphical display the mean facility radiation dose. For example, as shown in FIG. 3, the line marked with triangles is compared to the national mean radiation dose, the dotted line. This system is used by hospitals and imaging facilities to benchmark their radiation dose to other imaging centers radiation dose. The graphical display allow for ease of use of the system.
Claim 14:
Moore teaches:
A non-transitory computer program product (non-tangible computer readable storage medium) storing executable program code (computer instructions), when executed by the system, causes the system, to execute the method of claim 1.
[0058] Various aspects of the present disclosure may be embodied as a program, software, or computer instructions embodied or stored in a computer or machine usable or readable medium, which causes the computer or machine to perform the steps of the method when executed on the computer, processor, and/or machine. A program storage device readable by a machine, e.g., a computer readable medium, tangibly embodying a program of instructions executable by the machine to perform various functionalities and methods described in the present disclosure is also provided. A non-tangible computer readable storage medium does not include the tangible computer readable medium of signals.
Claim 15:
Moore teaches:
A non-transitory computer-readable, non-volatile data storage medium (non-tangible computer readable storage medium) storing executable program code (computer instruction) embodied, when executed, to execute the method of claim 1.
[0058] Various aspects of the present disclosure may be embodied as a program, software, or computer instructions embodied or stored in a computer or machine usable or readable medium, which causes the computer or machine to perform the steps of the method when executed on the computer, processor, and/or machine. A program storage device readable by a machine, e.g., a computer readable medium, tangibly embodying a program of instructions executable by the machine to perform various functionalities and methods described in the present disclosure is also provided. A non-tangible computer readable storage medium does not include the tangible computer readable medium of signals.
Claims 4, 17, 18 are rejected under 35 U.S.C. 103 as being unpatentable over Moore (US 20150356258) in view of Kohli (US 20190156921) in view of Clough (20030182363) in view of Sanso (US 20170012980) in view of Lebrun (20200135321)
Claim 4, 17:
Moore teaches:
wherein […] the local apparatus (display of UI, printer) […], […] on the local apparatus (display of UI, printer), to authenticate (authenticate) the call, and wherein the […] includes a successful authentication (authentication) […].
[0008] In one aspect, the system and method further comprises displaying, on the display device, the benchmark dose data for one or more facilities in addition to the one facility. In one aspect the system and method further comprises enabling a user to enter authentication data, and authenticating the user. In one aspect, the system further comprises a printer, wherein the module is further operable to send the effective dose data and the benchmark dose data to the printer.
[0019] The system is secured by an SSL (security sockets layer) application engine on a node replicated via cloud instances. SSL uses public and private keys, along with digital certificates, for security. In some embodiments, SSL can be replaced with TLS (transport layer security). The system employs SSH (secure shell) protocol to enable SSH tunnels, e.g., encrypted tunnels, to provide secure remote login and access over insecure networks, such as over the cloud.
[0020] Application security can be obtained, in addition to SSH tunnels, by enforcing user authorization and application authorization in accordance with required credentials for system access. Additional security can be obtained from database security including, for example, failover protection node replication and/or regular database backup.
[0020] Application security can be obtained, in addition to SSH tunnels, by enforcing user authorization and application authorization in accordance with required credentials for system access. Additional security can be obtained from database security including, for example, failover protection node replication and/or regular database backup.
Moore does not teach:
wherein […] the local apparatus […], […] on the local device, to authenticate the call, and wherein the trigger condition includes a successful authentication […].
Kohli does teach:
wherein […] the local apparatus […], […] on the local device, to authenticate the call, and wherein the trigger condition (data source trigger) includes a successful authentication […].
[0052] In certain examples, an apparatus responds to data source events through data source triggers and/or polling.
[0105] Data source events (e.g., new documents, updated documents, lab results, exams for review, and/or other medical information, etc.) are pushed or pulled from the data source 402 to the IRCC processor 404 to trigger processing of the data from the data source. Once data is received from the data source 402 at the IRCC processor 404, the IRCC processor 404 processes the data to enrich the data and provide an indication of relevancy of the data to one or more clinical scenarios.
See also [0142]
It would have been obvious to one or ordinary skill in the art, before the effective filing date of the claimed invention, to modify the data provisioning module as taught by Moore with the checking for a trigger condition as taught by Kohli. It would be beneficial to check for a trigger condition in order to have more context to interpret symptoms more accurately, "[0035] In a radiological examination, a patient's clinical history and indication (CHI) are critical components of a quality interpretation, as this data provides a context in which acute symptoms and findings can be interpreted more accurately. Pertinent and accurate information relating to current symptoms and past medical history enable the radiologist to interpret imaging findings in the appropriate clinical context. The appropriate clinical context and interpretation of findings then leads to a more relevant differential diagnosis, a more useful report for the clinician, and, ideally, a better outcome for the patient.
Moore in view of Kohli does not teach:
wherein the reactive pull module provides the local apparatus […], checked by the reactive pull module within a scope of the call from the URL on the local device, to authenticate the call, and wherein the trigger condition includes a successful authentication […].
Clough does teach:
wherein the reactive pull module (access to logically remote device) provides the local apparatus […], […] the reactive pull module (access to logically remote device) within a scope of the URL (URL) call on the local device, to authenticate the call, and wherein the trigger condition includes a successful authentication […].
[0004] To illustrate this consider the following example, wherein a hotel's (or some other entity's) LAN is connected to any number of resources or peripheral devices (e.g., a printer, a scanner, public network access, and so on) to allow convenient guest, visitor, customer, employee, and/or so on, access and use of such resources. A user connecting a computing device (e.g., PC, laptop, personal digital assistant (PDA), etc.) into the hotel's LAN at this point is typically able to access these resources over the LAN.
[0008] The following described subject matter provides private network local resource access to a logically remote device. [0023] For instance, the secure data post from the client 110 to the server 106 can include a header to specify a particular device, or the URL can be mapped to the particular local resource 108. Either way will work, a separate URL per local device 110 (that may, or may not, all point to different web services 108), or a URL to the server 106 that uses the HTTP(S) headers to determine destination resources 109 for the data and/or commands that are embedded in the secure data post from the client 110. These aspects are described in greater detail below in reference to FIGS. 2 through 5.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have included a reactive pull module which provides a URL as taught by Clough in the system of Moore in view of Kohli, since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Moore in view of Clough does not teach:
wherein the reactive pull module provides the local apparatus with a service access token, checked by the reactive pull module within a scope of the URL call on the local device, to authenticate the call, and wherein the trigger condition includes a successful authentication of the service access token.
Lebrun does teach:
wherein the reactive pull module provides the local apparatus with a service access token, checked by the reactive pull module within a scope of the URL call on the local device, to authenticate the call, and wherein the trigger condition includes a successful authentication of the service access token.
[0010] A smart monitor device is also associated with the user by obtaining a first token associated with the smart monitor device and associating the first token with the user. The dose management system also authenticates a user device of the user based on the first token, thereby permitting management of the product.
It would have been prima facie obvious to one of ordinary skill in the art at the time the invention was made to combine the noted features of Moore in view of Kohli in view of Clough with teaching of Lebrun since the combination of the two references is merely combining prior art elements according to known methods to yield predictable results (KSR rational A); see MPEP 2143(I)(A)). It can be seen that each element claimed is present in either Moore in view of Kohli in view of Clough or Lebrun. A service access token checked as taught by Lebrun does not change or affect the normal access of data. Accessing data would be performed the same way even with the addition of a service token. Since the functionalities of the elements in Moore in view of Kohli in view of Clough and Lebrun do not interfere with each other, the results of the combination would be predictable.
Claim 18:
Moore in view of Kohli further in view of Clough in view of Sanso in view of Lebrun teach:
The method of claim 4, […]
Moore further teaches:
wherein the local apparatus is a radiology information system (radiology reports).
[0052] Data communication options can include patient health records, radiology reports
Claim 9 are rejected under 35 U.S.C. 103 as being unpatentable over Moore (US 20150356258) in view of Kohli (US 20190156921) in view of Clough (20030182363) in view of Sanso (US 20170012980) in view of Jadeja (US 20140058844).
Claim 9:
Moore teaches:
wherein the […] on the reporting (monitoring) system (system) […] a unique study-identifying characteristic value (CTDI volume, DLP, technologist name, and all other DICOM fields, in addition to patient demographics, medical record number or identifier), the unique study-identifying characteristic value being (dose information has internal references to identifying patient information) associated with the second dose data (dose card).
[0005] A novel system and method for radiation dose monitoring is presented.
[0021] Typically, CTDI volume, DLP, technologist name, and all other DICOM fields, in addition to patient demographics, are collected and sent to the database 103.
[0022] In step S207, after the examination, e.g., after operation of the scanner, the effective dose data is compared to baseline data obtained from the database 103. In step S209, the radiation dose is monitored for a particular patient and a customized, branded dose card and/or a printout of the dose data for the patient is generated. In one aspect, the radiation dose is monitored in accordance with “monitor data” which can be one of effective dose data, CTDI volume or DLP.
[0044] In one aspect, dose information has internal references to identifying patient information such as medical record number or identifier, in a HIPAA compliant manner
Moore does not teach:
wherein the provisioning condition is or includes a positive result of a check to determine whether an incomplete order is currently present on the reporting system, the incomplete order being linked to a unique study-identifying characteristic value, associated with the second dose data.
Jadeja does teach:
wherein the provisioning condition (data check) is or includes a positive result (prompt user to enter additional information) of a check (check) to determine whether an incomplete order (gaps in the user information) is currently present on the reporting system, the incomplete order (missing information) being linked to a unique study-identifying characteristic value, associated with the second dose data
[0116] A data check is then initiated in step 804 to check for gaps in the user information. The computing apparatus 2 may prompt a user to enter additional information if the data check identifies missing information. This is represented by the generation of a user survey in step 814. Any additional information that the user contributes in the survey is entered into the master record and another data check 802 is initiated.
It would have been obvious to one or ordinary skill in the art, before the effective filing date of the claimed invention, to modify the data provisioning module as taught by Moore in view of Kohli in view of Clough in view of Sanso with the checking for a provisional condition as taught by Jadeja. It would be beneficial to check for a provisional condition as taught by Jadeja in order to identify and fix any missing information in the data , "[0116] A data check is then initiated in step 804 to check for gaps in the user information. The computing apparatus 2 may prompt a user to enter additional information if the data check identifies missing information. This is represented by the generation of a user survey in step 814. Any additional information that the user contributes in the survey is entered into the master record and another data check 802 is initiated.".
Claims 6, 19 are rejected under 35 U.S.C. 103 as being unpatentable over Moore (US 20150356258) in view of Kohli (US 20190156921) in view of Clough (20030182363) in view of Sanso (US 20170012980) in view of Brandmaier (US 8510196)
Claim 6, 19:
Moore teaches:
wherein the dose data provisioning module (application server) includes a proactive push module (inventive system); and wherein […] includes receiving of an item of information (dose data), from the cloud-based (cloud-based) dose management system (system), […] the cloud-based (cloud-based) dose management system (system).
[0005] A novel system and method for radiation dose monitoring is presented. The system uses a particular study (e.g., patient-centered) approach to radiation dose tracking that empowers imaging centers, interventionalists and affiliated services to rapidly track patient specific radiation doses.
[0016] FIG. 1 is a high-level architectural schematic of an embodiment of the inventive system. As shown in FIG. 1, the system has one or more scanners 101, a database 103 in which data including dose information is stored, and an application server 105 having memory in which algorithms for performing dose monitoring in accordance with the present invention are stored. […] The database 103 and the application server 105 can be cloud-based.
[0022] In step S207, after the examination, e.g., after operation of the scanner, the effective dose data is compared to baseline data obtained from the database 103. In step S209, the radiation dose is monitored for a particular patient and a customized, branded dose card and/or a printout of the dose data for the patient is generated. In one aspect, the radiation dose is monitored in accordance with “monitor data” which can be one of effective dose data, CTDI volume or DLP.
[0024] In one embodiment, the inventive system is based in cloud architecture which enables assessment of the data for multiple facilities.
Moore does not teach:
wherein the dose data provisioning module includes a proactive push module; and wherein the trigger condition; includes receiving of an item of information, from the cloud-based dose management system, […]; into the cloud-based dose management system.
Kohli does teach:
wherein the dose data provisioning module includes a proactive push module; and wherein the trigger condition (data source triggers); includes receiving of an item of information, from the cloud-based dose management system, […]; into the cloud-based dose management system.
[0052] In certain examples, an apparatus responds to data source events through data source triggers and/or polling.
[0105] Data source events (e.g., new documents, updated documents, lab results, exams for review, and/or other medical information, etc.) are pushed or pulled from the data source 402 to the IRCC processor 404 to trigger processing of the data from the data source. Once data is received from the data source 402 at the IRCC processor 404, the IRCC processor 404 processes the data to enrich the data and provide an indication of relevancy of the data to one or more clinical scenarios.
See also [0142]
It would have been obvious to one or ordinary skill in the art, before the effective filing date of the claimed invention, to modify the data provisioning module as taught by Moore with the checking for a trigger condition as taught by Kohli. It would be beneficial to check for a trigger condition in order to have more context to interpret symptoms more accurately, "[0035] In a radiological examination, a patient's clinical history and indication (CHI) are critical components of a quality interpretation, as this data provides a context in which acute symptoms and findings can be interpreted more accurately. Pertinent and accurate information relating to current symptoms and past medical history enable the radiologist to interpret imaging findings in the appropriate clinical context. The appropriate clinical context and interpretation of findings then leads to a more relevant differential diagnosis, a more useful report for the clinician, and, ideally, a better outcome for the patient.
Moore in view of Kohli does not teach:
wherein the dose data provisioning module includes a proactive push module; and wherein the trigger condition includes receiving of an item of information, from the cloud-based dose management system, indicating that a study was fully uploaded into the cloud-based dose management system.
Brandmaier does teach:
wherein the dose data provisioning module includes a proactive push module; and wherein the trigger condition includes receiving of an item of information, from the cloud-based dose management system, indicating that a study was fully uploaded (upload progress bar may indicate the progress of the … upload, display screen 707, which indicates that the … have been uploaded) into the cloud-based dose management system.
[Col 15, line23-28] the mobile device may display screen 705 where an upload progress bar may indicate the progress of the photo upload. Once the photos have been fully uploaded, the mobile device may display screen 707, which indicates that the photos have been uploaded and explains any next steps that should be taken.
It would have been obvious to one or ordinary skill in the art, before the effective filing date of the claimed invention, to modify the upload as taught by Moore in view of Kohli in view of Clough in view of Sanso with the indication of a full upload as taught by Brandmaier. It would be beneficial for the user to know when the data was fully uploaded as taught by Brandmaier, "[Col 15, line23-28] the mobile device may display screen 705 where an upload progress bar may indicate the progress of the photo upload. ".
Claims 10-12 are rejected under 35 U.S.C. 103 as being unpatentable over Moore (US 20150356258) in view of Kohli (US 20190156921) in view of Clough (20030182363) in view of Sanso (US 20170012980) in view of Brandmaier (US 8510196) in view of Larson (20140270053)
Claim 10:
Moore teaches:
wherein the dose data provisioning module (application server) includes […] wherein upon a study (dose data) […] the cloud-based (cloud-based) dose management system (system), the cloud-based dose management system (system) informs […] executed in the medicine data gateway (inventive system, login); whereupon […] provides the second dose data (dose card) to […] as the local device within the local Intranet (intranet); and wherein […] third dose data (dose card), based upon the second dose data (dose card), […].
[0005] A novel system and method for radiation dose monitoring is presented. The system uses a particular study (e.g., patient-centered) approach to radiation dose tracking that empowers imaging centers, interventionalists and affiliated services to rapidly track patient specific radiation doses.
[0006] In one aspect, the method can comprise scanning, using a scanner at one facility of one or more facilities, storing the radiation dose data, monitoring monitor data based on the monitor data, e.g., effective dose data or CT Dose Index (CTDI) volume or Dose Length Product (DLP), and the benchmark dose data for the one or more facilities; and displaying, on the display, the monitor data, e.g., effective dose data, DLP or CTDI volume, and the benchmark dose data for the one facility. In one aspect, the method can also comprise converting the radiation dose data in accordance with recommended dose data stored in a database and obtaining the effective dose data based on the converted radiation dose data.
[0007] In one aspect, the system can comprise a database storing at least recommended dose data and benchmark dose data for one or more facilities, a scanner located in one facility of the one or more facilities, the scanner can perform a scan with radiation dose data, an application server having a processor, a user interface comprising at least a display, and a module operable on the processor, said module operable to receive the radiation dose data from the scanner, store the radiation dose data, monitor the radiation dose data based on the monitor data, e.g., effective dose data or CTDI volume or DLP, and the benchmark dose data for the one or more facilities, and display, on the display, the monitor data, e.g., the effective dose data or CTDI volume or DLP, and the benchmark dose data for the one facility.
[0016] FIG. 1 is a high-level architectural schematic of an embodiment of the inventive system. As shown in FIG. 1, the system has one or more scanners 101, a database 103 in which data including dose information is stored, and an application server 105 having memory in which algorithms for performing dose monitoring in accordance with the present invention are stored.
[0018] In one aspect, the scanner is automatically logged into the inventive system. In step S203, the login can be performed by HTML 5 login procedures. Each technologist login requires user specific credentials. The system will automatically register to the CT scanner based on the location of the computer used to log into the system. An administrator log-in is also available; this will allow an administrator to monitor all radiation producing units at his or her facility.
[0022] In step S207, after the examination, e.g., after operation of the scanner, the effective dose data is compared to baseline data obtained from the database 103. In step S209, the radiation dose is monitored for a particular patient and a customized, branded dose card and/or a printout of the dose data for the patient is generated. In one aspect, the radiation dose is monitored in accordance with “monitor data” which can be one of effective dose data, CTDI volume or DLP.
Moore does not teach:
wherein the dose data provisioning module includes […]; wherein upon a study being fully uploaded into the cloud-based dose management system, the cloud-based dose management system informs […] executed in the medicine data gateway; whereupon […] provides the second dose data to […]as the local device within the local Intranet; and wherein […] third dose data, based upon the second dose data […]
Brandmaier does teach:
wherein the dose data provisioning module includes […]; wherein upon a study being fully uploaded (upload progress bar, indicates that the .. have been uploaded) into the cloud-based dose management system, the cloud-based dose management system informs […] executed in the medicine data gateway; whereupon […] provides the second dose data to […]as the local device within the local Intranet; and wherein […] third dose data, based upon the second dose data […]
[Col 15, line23-28] the mobile device may display screen 705 where an upload progress bar may indicate the progress of the photo upload. Once the photos have been fully uploaded, the mobile device may display screen 707, which indicates that the photos have been uploaded and explains any next steps that should be taken.
It would have been obvious to one or ordinary skill in the art, before the effective filing date of the claimed invention, to modify the upload as taught by Moore in view of Kohli in view of Clough in view of Sanso with the indication of a full upload as taught by Brandmaier. It would be beneficial for the user to know when the data was fully uploaded as taught by Brandmaier, "[Col 15, line23-28] the mobile device may display screen 705 where an upload progress bar may indicate the progress of the photo upload. ".
Moore in view of Kohli in view of Clough in view of Sanso in view of Brandmaier does not teach:
wherein the dose data provisioning module includes a dose registration module; wherein upon a study being fully uploaded into the cloud-based dose management system, the cloud-based dose management system informs the dose registration module executed in the medicine data gateway; whereupon the dose registration module provides the second dose data to a registry site service system as a local apparatus within the local Intranet; and wherein the registry site service system transmits third dose data, based upon the second dose data, to a national dose registry computing facility.
Larson does teach:
wherein the dose data provisioning module includes a dose registration module (transmitted to … national data registry); wherein upon a study being fully uploaded into the cloud-based dose management system, the cloud-based dose management system informs a dose registration module (transmitted to … national data registry) executed in the medicine data gateway; whereupon the dose registration module (transmitted to … national data registry) provides the second dose data to a registry site service system (national data registry) as the local device within the local Intranet; and wherein the registry site service system (transmitted to … national data registry) transmits third dose data, based upon the second dose data, to a national dose registry (national data registry or regulatory agency) computing facility (organization).
[0172] Data from a query can be exported into an external data file. This file includes all study data in the database, not only those that are displayed by the study analysis application. These data can be used for research, internal monitoring, or reporting. The data can be deidentified and transmitted to both internal and external reviewers or reviewing organizations, such as a national data registry or regulatory agency. With the cooperation of such an organization, an automatic report can be developed and periodically transmitted to the organization.
It would have been prima facie obvious to one of ordinary skill in the art at the time the invention was made to combine the noted features of Moore in view of Kohli in view of Clough in view of Sanso in view of Brandmaier with the teaching of Larson since the combination of the two references is merely combining prior art elements according to known methods to yield predictable results (KSR rational A); see MPEP 2143(I)(A)). It can be seen that each element claimed is present in either Moore in view of Kohli in view of Clough in view of Sanso in view of Brandmaier or Larson. Transmitting data to a registry system as taught by Larson does not change or affect the normal transmitting of data. Transmitting data would be performed the same way even with the addition of transmitting data to a registry system. Since the functionalities of the elements in Moore in view of Kohli in view of Clough in view of Sanso in view of Brandmaier and Larson do not interfere with each other, the results of the combination would be predictable.
Claim 11:
Moore teaches:
wherein […] receives dose benchmark data (dose data and benchmark) from the national dose registry computing facility (dose registry), whereupon […] uploads the new dose benchmark data (dose) into the cloud-based (cloud-based) dose management system (system).
[0005] A novel system and method for radiation dose monitoring is presented. The system uses a particular study (e.g., patient-centered) approach to radiation dose tracking that empowers imaging centers, interventionalists and affiliated services to rapidly track patient specific radiation doses.
[0050] In one embodiment, these analytics are provided in a graphical display, which displays scanner-specific and patient-specific data for a given time frame. In one aspect, these reports can be used to track protocol changes over time and reduce delivered patient dose. The inventive solution has the advantage of providing real-time feedback from our multi-center dose-reporting database for technologists per examination relative to a real-time average in the inventive cloud-based database.
[0057] The use of a dose registry can allow obtaining multicentric or geographic dose data and benchmarks for participating institutions. Initiatives by the American College of Radiology (ACR) such as the Dose Index Registry aim to catalogue and monitor institution-specific doses. The ACR Dose Index Registry supports DICOM-SR for dose capture as well as OCR with many vendor partners. A list of compatible and supported ACR Dose Index Registry tools may be found at the ACR's website.
Moore does not teach:
wherein the registry site service system receives dose benchmark data from the national dose registry computing facility, whereupon the registry site service system informs the dose registration module of availability of new dose benchmark data, whereupon the dose registration module uploads the new dose benchmark data into the cloud-based dose management system.
Larson does teach:
wherein the registry site service (transmitted to … national data registry) system receives dose benchmark data from the national dose registry computing facility, whereupon the registry site service (transmitted to … national data registry) system informs (transmitted to … national data registry) the dose registration module of availability of new dose benchmark data, whereupon the dose registration module uploads the new dose benchmark data into the cloud-based dose management system.
[0172] Data from a query can be exported into an external data file. This file includes all study data in the database, not only those that are displayed by the study analysis application. These data can be used for research, internal monitoring, or reporting. The data can be deidentified and transmitted to both internal and external reviewers or reviewing organizations, such as a national data registry or regulatory agency. With the cooperation of such an organization, an automatic report can be developed and periodically transmitted to the organization..
It would have been prima facie obvious to one of ordinary skill in the art at the time the invention was made to combine the noted features of Moore in view of Kohli in view of Clough in view of Sanso in view of Brandmaier with teaching of Larson since the combination of the two references is merely combining prior art elements according to known methods to yield predictable results (KSR rational A); see MPEP 2143(I)(A)). It can be seen that each element claimed is present in either Moore in view Kohli further in view of Clough further in view of Brandmaier or Larson. Transmitting data to a registry system as taught by Larson does not change or affect the normal transmitting of data. Transmitting data would be performed the same way even with the addition of transmitting data to a registry system. Since the functionalities of the elements in Moore in view of Kohli in view of Clough in view of Sanso in view of Brandmaier and Larson do not interfere with each other, the results of the combination would be predictable.
Claim 12:
Moore further teaches:
wherein the cloud-based dose management system (system) additionally functions as at least one […] a cloud-based (cloud-based) protocol management system (track protocol changes over time). (Examiner interprets additional limitations as optional due to claim language “at least one”)
[0046] In one embodiment, the cloud stores encrypted dose information using an elastic, scalable, and relational database adhering to the necessary HIPAA requirements. Data can be transferred securely to a remote location via the Health Level 7 protocol or API integration, which can be integrated with internal EMR systems or decision systems in a customized institution specific fashion. Advantages of cloud architecture can include significantly reduced costs and improved scalability.
[0050] In one embodiment, these analytics are provided in a graphical display, which displays scanner-specific and patient-specific data for a given time frame. In one aspect, these reports can be used to track protocol changes over time and reduce delivered patient dose. The inventive solution has the advantage of providing real-time feedback from our multi-center dose-reporting database for technologists per examination relative to a real-time average in the inventive cloud-based database.
[0057] The use of a dose registry can allow obtaining multicentric or geographic dose data and benchmarks for participating institutions. Initiatives by the American College of Radiology (ACR) such as the Dose Index Registry aim to catalogue and monitor institution-specific doses. The ACR Dose Index Registry supports DICOM-SR for dose capture as well as OCR with many vendor partners. A list of compatible and supported ACR Dose Index Registry tools may be found at the ACR's website.
Prior Art Cited but Not Relied Upon
US 20210035681 Bossio
The method of claim 13, further comprising: passing a token at least partially based on the session variable to the data analytics tool, wherein the token is compared to available tokens at the central server to determine if the user is to be granted access to the data analytics tool.
Response to Arguments Regarding U.S.C. 101 rejection
Applicant argues page 9
As noted in the Advisory Action, MPEP 106.04(d)(l) describes that the word "improvements" is limited to improvements to the functioning of a computer or any other technology or technical field. The pending claims improve the technological field of dose data reporting. See Specification, paragraphs [0005]-[0008]. In particular, as described in the Amendment of January 9, 2026, the pending claims are designed to avoid human interaction which improves the technological field of dose data reporting and eliminates technological problems of unrestricted access to patient data.
The Final Office Action identifies the local intranet, cloud-based, receiving a call from a URL, and downloading and uploading data as additional elements and each of these additional elements helps to integrate the alleged abstract idea of the pending claims into a practical application. The pending claims provide systems and methods for providing dose data to and from a cloud-based dose management system. In particular, the pending claims provide systems and methods that receive dose data from study data and upload the data to a cloud-based management system via a local intranet. The systems and methods then enable accessing data from the cloud-based management system via the local Intranet based on a verified call from a URL. Thus, the additional elements of the pending claims provide an improvement to the technological field of dose data reporting by removing human interaction and issues associated with human interaction thereby providing an improvement to the technological field of dose data reporting.
Examiner responds
The Examiner respectfully disagrees. Multiple CAFC decisions that the Office has characterized as Certain Method of Organizing Human Activity did not actively recite a person or persons performing the steps of the claims (see, e.g., EPG, TLI communications, Ultramercial). Because whether a human is required to perform the step of the claim is not a requirement for claims to encompass certain method of organizing human activity, this argument is not persuasive.
MPEP 2106. 04(a)(2)(II) states that a claimed invention is directed to certain methods of organizing human activity if the identified claim elements contain limitations that encompass fundamental economic principles or practices, commercial or legal interactions, or managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions). The Examiner submits that the identified claim elements represent a series of rules or instructions that a person or persons, with or without the aid of a computer, would follow for providing dose data. Applicant has not pointed to “local intranet, cloud-based, receiving a call from a URL, and downloading and uploading data” as additional elements and each of these additional elements has been identified as not integrating the abstract idea into a practical application. Because the claim elements fall under a series of rules or instructions that a person or persons would follow to provide dose data, the claimed invention is directed to an abstract idea.
Response to Arguments Regarding U.S.C. 103 rejection
Applicant argues page 12-13:
With respect to the art rejections, the Advisory Action alleges that the broadest reasonable interpretation of the "user token based on a service token" is analogous to paragraph [0058] of Kohli. Applicants respectfully disagree, especially in view of the further amendments to the pending claims.
Paragraph [0058] of Kohli describes that patient identifying information "can be masked or even stripped from certain data depending upon where the data is stored and who has access to that data" and that PHI that has been de-identified "can be reidentified based on a key and/ or other encoder/ decoder." Claim 1 is being further amended to clarify that the user token is "produced based on a service access token provided to an apparatus of the local Intranet via a reactive pull module of the dose provisioning module." Kohli's generic description of de-identifying and re-identifying data does not describe a user token that is based on a service access token as recited in amended claim 1.
Examiner responds
Examiner respectfully disagrees. Examiner uses the broadest reasonable interpretation of "user token based on a service token" to be analogous Kohli para 58 which teaches a key or encoder for re-identifying de-identified PHI. Examiner notes the current claim language is so broad as to include a single token as taught by Kohli. Examiner notes a key and/or encoder/decoder does not contain patient specific data because it is a key for encryption/decryption of the data. Examiner points to Clough for features of the apparatus and reactive pull module and has found it an obvious combination. See 103 rejection above.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ANDREW KYLE TAPIA whose telephone number is (703)756-1662. The examiner can normally be reached 830 - 530.
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.
/A.K.T./Examiner, Art Unit 3687
/MAMON OBEID/Supervisory Patent Examiner, Art Unit 3687
Prosecution Insights