Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
This is a reply to the application filed on 2/26/2025, in which, claim(s) 1-20 are pending.
Priority
Acknowledgment is made of applicant's claim for foreign priority under 35 U.S.C. 119(a)-(d). Receipt is acknowledged of papers submitted under 35 U.S.C. 119(a)-(d), which papers have been placed of record in the file.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 10/2/2025, has been reviewed. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the examiner is considering the information disclosure statement.
Specification
The lengthy specification has not been checked to the extent necessary to determine the presence of all possible minor errors. Applicant’s cooperation is requested in correcting any errors of which applicant may become aware in the specification.
Drawings
The drawings filed on 2/26/2025 is/are accepted by The Examiner.
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 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 1, 12 and 19 reciting “receiving a data compartment sharing request issued by a first user of the source institution via a first terminal device…”. It is unclear if the first user is doing the “receiving” or “requesting”.
Claims 1, 12 and 19 reciting “notifying a second terminal device of a second user of the target institution about the data compartment sharing request;
receiving approval or rejection of the data compartment sharing request issued by the second user via the second terminal device;
in case of the approval, providing access to the data stored in the selected data compartment to the second terminal device…”. If the second user is doing the approval, which implied they have access rights, why would you give second user access upon their own approval?
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.
Claim(s) 12-18 is/are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
Claim limitations “a system for sharing…, a cloud based distributed system configured to…” in claim 12, and “a network being configured to…” in claim 14 are limitations that invoke 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for the claimed function. The specification does not adequately disclose the structure to perform the functions of the claim. The corresponding structure must be more than a mere reference to a general-purpose computer, microprocessor, specialized computer, or an undefined component of a computer system, software, logic, code, or black box element.
Pursuant to 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181, applicant should:
(a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112, sixth paragraph; or
(b) Amend the written description of the specification such that it expressly recites the corresponding structure, material, or acts that perform the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(c) State on the record what corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1-20 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Wright et al. (US 20170235880 A1; hereinafter Wright).
Regarding claims 1, 12 and 19, Wright discloses a computer-implemented method for sharing data between customer institutions participating in a digital health platform, the computer-implemented method comprising:
providing at least one data compartment configured to store data of an application of a source institution (storage of medical data on hospital and cloud storage [Wright; ¶149; Fig. 1b and associated texts]);
receiving a data compartment sharing request issued by a first user of the source institution via a first terminal device, wherein the data compartment sharing request is a request for sharing a selected data compartment with a target institution, the selected data compartment being selected by the first user (a patient, insurance carrier, or medical care provider may inquire about images for a certain patient. This may involve either calling on the phone to the MDR having the patient information, or use of electronic means to send a request to the MDR. For example, in some embodiments, the third party cloud service can receive a request using its user interface for data about a particular patient for, by example, receiving the patient's name, id, or other identifying information in electronic form and either matching that data within its own record to determine whether the requested images exist on its own third party cloud service network, or send the request to the MDR where the patient's data is stored to handle the request [Wright; ¶135-156; Figs. 1b, 6-7, 9 and associated texts]);
notifying a second terminal device of a second user of the target institution about the data compartment sharing request (Once the medical staff, for example a nurse, doctor, orderly, or lawyer at the medical institution has selected the required HIPAA release using the cloud or on-site unit's user interface, or the HIPAA release was automatically selected, the medical staff may select the patient or recipient to receive the medical data. This may include adding a new recipient or patient to the cloud service system (and related on-site unit), or selecting the recipient if already included in the system. The user may add a recipient or patient, or select a recipient or patient by, for example, entering the patient's name and/or email address into the cloud service's user interface. After the cloud service of on-site unit has received this selection, it may use this information to search the cloud service or PACS and identify matching patients to present choices of patients to the user. This search may also involve returning various images, DICOM structured reports, other reports, or other medical data that can be selected by a user to send to a requestor (or without request) via upload to the cloud service [Wright; ¶135-156; Figs. 1b, 6-7, 9 and associated texts]);
receiving approval or rejection of the data compartment sharing request issued by the second user via the second terminal device (the steps necessary to obtain a release for a specific patient. In one embodiment, the specific HIPAA release may be sent in email to a patient. In another embodiment, a link may be sent in email to the patient. Other avenues of communication may be used to send the release, including SMS text messaging, phone call with voice recognition, by using a human call center, or collecting the release in person. For the human call center and in person options, a user must input manually into the user interface of the cloud system that the particular patient has agreed to the specific HIPAA release requested. This may involve the patient signing a physical copy of the document, and uploading a scan of that document to the cloud system [Wright; ¶135-156; Figs. 1b, 6-7, 9 and associated texts]);
notifying the first terminal device about the approval or rejection of the data compartment sharing request (yes or no on agreement/approval [Wright; ¶135-156; Figs. 1b, 6-7, 9 and associated texts]); and
in case of the approval, providing access to the data stored in the selected data compartment to the second terminal device (the process proceeds to allow the images to become available to the recipient. This allows the package to be accessed through the recipients Inbox, as shown in FIG. 13, and discussed in detail in other sections. A link may be sent to an email address associated with the recipients to notify that the images/reports or other medical data are now available for download or viewing [Wright; ¶135-156; Figs. 1b, 6-7, 9 and associated texts]).
Regarding claim 2, Wright discloses the method according to claim 1, wherein the data compartment sharing request includes at least one of an institution name, an identifier, a serial number or an address of the target institution (patient or procedure information (e.g. patient id, name, type of image etc.) [Wright; ¶67]).
Regarding claim 3, Wright discloses the method according to claim 1, wherein the data compartment sharing request specifies at least one owner application or at least one third party application available on the target institution to have access to the data stored in the selected data compartment (third party cloud storage [Wright; ¶135-156; Figs. 1b, 6-7, 9 and associated texts]).
Regarding claim 4, Wright discloses the method according to claim 1, wherein the data compartment sharing request specifies a time frame indicating a time period where the sharing of the data stored in the selected data compartment is active (the desire virtual packaged is time sensitives and will be deleted [Wright; ¶176]).
Regarding claim 5, Wright discloses the method according to claim 1, wherein the data compartment sharing request specifies a level of access to the data stored in the selected data compartment of the source institution (access is available only for those with proper rights [Wright; ¶135-156; Figs. 1b, 6-7, 9 and associated texts]).
Regarding claim 6, Wright discloses the method according to claim 5, wherein the level of access specified in the data compartment sharing request comprises allowed data operations including reading data, writing data, deleting data and execution of operations on data (access rights [Wright; ¶135-156; Figs. 1b, 6-7, 9 and associated texts]).
Regarding claim 7, Wright discloses the method according to claim 1, wherein the data stored in the selected data compartment comprises associated data properties including an indication of a purpose of the data stored in the selected data compartment and data retention policies indicating at least one of a level of retention or a duration of the data stored in the selected data compartment, and a privacy level used for a data minimization operation (access is available only for those with proper rights [Wright; ¶135-156; Figs. 1b, 6-7, 9 and associated texts]).
Regarding claim 8, Wright discloses the method according to claim 1, wherein the second user is enabled by an authorization mechanism to configure the selected data compartment (the process proceeds to allow the images to become available to the recipient. This allows the package to be accessed through the recipients Inbox, as shown in FIG. 13, and discussed in detail in other sections. A link may be sent to an email address associated with the recipients to notify that the images/reports or other medical data are now available for download or viewing [Wright; ¶135-156; Figs. 1b, 6-7, 9 and associated texts]).
Regarding claim 9, Wright discloses the method according to claim 3, wherein an affected third party application, from among the at least one third party application, is notified automatically about data compartments shared with the affected third party application (cloud notify of access [Wright; ¶114, 172; Figs. 1b, 6-7, 9 and associated texts]).
Regarding claim 10, Wright discloses the method according to claim 1, further comprising: receiving a data compartment un-sharing request triggered by a third user of the source institution or triggered by an event; and terminating sharing of the selected data compartment in response to the data compartment un-sharing request (access revoked [Wright; ¶172-173, 183-184; Figs. 1b, 6-7, 9 and associated texts]).
Regarding claim 11, Wright discloses the method according to claim 10, wherein the second user is notified automatically about a termination of the sharing of the selected data compartment (cloud notify of access [Wright; ¶114, 172; Figs. 1b, 6-7, 9 and associated texts]).
Regarding claim 13, Wright discloses the system according to claim 12, wherein the cloud based distributed system is configured to notify the second user about the data compartment sharing request, and notify the first user about the approval or a rejection of the data compartment sharing request by the second user (the steps necessary to obtain a release for a specific patient. In one embodiment, the specific HIPAA release may be sent in email to a patient. In another embodiment, a link may be sent in email to the patient. Other avenues of communication may be used to send the release, including SMS text messaging, phone call with voice recognition, by using a human call center, or collecting the release in person. For the human call center and in person options, a user must input manually into the user interface of the cloud system that the particular patient has agreed to the specific HIPAA release requested. This may involve the patient signing a physical copy of the document, and uploading a scan of that document to the cloud system [Wright; ¶135-156; Figs. 1b, 6-7, 9 and associated texts]).
Regarding claim 14, Wright discloses the system according to claim 12, further comprising: a network connecting a plurality of customer institutions, the network being configured to transport messages and notifications between the plurality of customer institutions according to a communication protocol (based on HIPAA and DICOM [Wright; ¶135-156; Figs. 1b, 6-7, 9 and associated texts]).
Regarding claim 15, Wright discloses the system according to claim 14, wherein the plurality of customer institutions form application entities in a DICOM (Digital Imaging and Communications in Medicine) network, and wherein each data compartment exposes unique application entity titles (DICOM network [Wright; ¶58-67, 135-156; Figs. 1b, 6-7, 9 and associated texts]).
Regarding claim 16, Wright discloses the system according to claim 12, wherein the cloud based distributed system comprises: a DICOM server having, for identification and communication, an IP address, a port number and one or more application entity titles belonging to a single data compartment or multiple data compartments (DICOM network [Wright; ¶58-67, 135-156; Figs. 1b, 6-7, 9 and associated texts]).
Regarding claim 17, Wright discloses the system according to claim 12, wherein the system is inter-operable with other systems including at least one of: imaging modalities configured to generate medical images; modality worklist servers configured to at least one of manage worklists for imaging modalities or provide information about scheduled procedures; image acquisition devices configured to acquire medical images from imaging modalities and send the medical images to a Picture Archiving and Communication System configured to store, retrieve, and distribute medical images; viewer components configured to retrieve medical images from the Picture Archiving and Communication System and to view and interpret the retrieved medical images; Radiology Information Systems configured to manage radiological information, including patient scheduling, reporting, and other administrative functions; or print servers configured to print medical images to hardcopy films or other output devices (DICOM images such as X-Ray, MRI, etc. [Wright; ¶58-67, 135-156; Figs. 1b, 6-7, 9 and associated texts]).
Regarding claim 18, Wright discloses the system of claim 17, wherein the imaging modalities include at least one of X-ray machines, CT scanners, or MRI machines (DICOM images such as X-Ray, MRI, etc. [Wright; ¶58-67, 135-156; Figs. 1b, 6-7, 9 and associated texts]).
Regarding claim 20, Wright discloses the method according to claim 10, wherein the event is an expiration of a time period during which the sharing of the data is active as specified in the data compartment sharing request (access expired or revoked [Wright; ¶114, 172-173, 183-184; Figs. 1b, 6-7, 9 and associated texts]).
Internet Communications
Applicant is encouraged to submit a written authorization for Internet communications (PTO/SB/439, http:ljwww.uspto.gov/sites/default/files/documents/sb0439.pdf) in the instant patent application to authorize the examiner to communicate with the applicant via email. The authorization will allow the examiner to better practice compact prosecution. The written authorization can be submitted via one of the following methods only: (1) Central Fax which can be found in the Conclusion section of this Office action; (2) regular postal mail; (3) EFS WEB; or (4) the service window on the Alexandria campus. EFS web is the recommended way to submit the form since this allows the form to be entered into the file wrapper within the same day (system dependent). Written authorization submitted via other methods, such as direct fax to the examiner or email, will not be accepted. See MPEP § 502.03.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DAO Q HO whose telephone number is (571)270-5998. The examiner can normally be reached on 7:00am - 5:00pm.
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, Jeffrey Nickerson can be reached on (469) 295-9235. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/DAO Q HO/Primary Examiner, Art Unit 2432
Prosecution Insights