DETAILED ACTION
Continued Examination Under 37 CFR 1.114
Receipt is acknowledged of a request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e) and a submission, filed on August 15th, 2025.
Priority
The current application claims benefit of provisional application 63/343405, filed on May 18th, 2022. Examiner acknowledges the applicant’s claim for priority.
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 .
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-5 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.
Claim 1 recites the limitation "scrub the locally stored set of patient data so that it is no longer stored on the storage device;" in claim 1. There is insufficient antecedent basis for the phrase “it” in the claim. Claims 2-5 are rejected as they are dependent on claim 1. Examiner is interpreting this limitation to mean the processor encrypts patient information from the computer. Examiner recommends the applicant to clarify what the phrase “it” references by either elaborating on the object or detailing what function scrubbing performs [i.e., deletes patient names, birthdays, and treatment dates stored on the storage device].
35 USC § 101 Eligible Subject Matter
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-5 are analyzed following MPEP 2106’s guidelines to determine subject matter eligibility. The following steps will elaborate on the rationale behind the cases potential subject matter eligibility.
Step 1
Claims 1-5 recite subject matter within a statutory category as a process, machine, and/or article of manufacture.
Step 2A Prong One
Claim 1 states:
“a system for securely storing and providing medical image data comprising: a hub device comprising a processor,
a storage device,
and a display;
a security token device configured to store a set of security token data, and configured to be selectively communicatively coupled to the hub device;
a cloud imaging database that is in communication with the hub device and configured to store sets of medical image data;
wherein the processor is configured to:
receive and locally store on the storage device a set of medical image data and a set of patient data, each associated with a patient, from an image data source;
access the set of security token data when the security token device is coupled to the hub device,
and generate an anonymized identifier based on the set of patient data and the set of security token data;
create a patient repository for the patient on the cloud imaging database based on the anonymized identifier,
scan the set of medical image data to identify any embedded patient data,
modify the set of medical image data so that the embedded patient data is not present,
and store the set of medical image data in the patient repository;
immediately after generating the anonymized identifier, scrub the locally stored set of patient data so that it is no longer stored on the storage device;
display a patient image data interface via the display that comprises descriptions of a plurality of patient repositories stored by the cloud imaging database, wherein: when the set of security token data is not accessible by the hub device, the plurality of patient repositories are each displayed based upon their corresponding anonymized identifiers; when the set of security token data is accessible by the hub device: the processor is configured to convert each anonymized identifier to a corresponding set of patient data based upon the set of security token data; and the plurality of event repositories are each displayed based upon their corresponding set of patient data.
The broadest reasonable interpretation of these steps includes organizing human activities because each bolded component can practically be performed by a human to manage or organize behavior. The claims recite generic computer terms like the hub device’s “processor” or “display” and the claims do not preclude the bolded portions from practically being performed by a human. For example, but for the hub device’s processor, “receive and locally store on the storage device a set of medical image data and a set of patient data, each associated with a patient, from an image data source” in the context of this claim encompass organizing human behavior, such as a doctor organizing a Patient’s X rays in a cabinet. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation but for the recitation of generic computer components, then it falls within the “organizing human activity” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Dependent claims recite additional subject matter which further narrows or defines the abstract idea embodied in the claims (such as claim 2, reciting particular aspects of “display the plurality of patient repositories based upon their corresponding anonymized identifiers as a local display layer” may be performed without generic computer components if not required by the claims).
Dependent claim 5 introduces a “portable electronic memory device” as a generic component, similarly, but also still recite an abstract idea. Similarly, the remaining dependent claims (2-4,6) recite additional subject matter which further narrows or defines the abstract idea embodied in the claims and still address the abstract idea.
Step 2A Prong Two
This judicial exception is integrated into a practical application. The claim recites a combination of elements of receiving and locally storing data, associating it with a patient, generating an anonymized identifier based on the patient data, scrubbing the locally stored set of patient data so that it is no longer stored on the storage device, converting each anonymized identifier to a corresponding set of patient data based upon the set of security token data, and displaying the data based on the security toke data provided. When combined, these limitations direct this invention to an improvement of accessing secure healthcare data. Although each of the collecting steps analyzed individually may be viewed as mere pre- or post-solution activity, the combination of recreating a repository of stored data for access based on identifiable security token data after data manipulation, data output, and patient information deletion, amounts to an improvement of securing healthcare data.
Dependent claims 2-6 recite additional subject matter which further limit claim 1’s material without adding ineligible subject matter and, therefore, follows the same rationale as claim 1.
Thus, based on the aforementioned analysis, the aforementioned claims recite statutory material.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-5 are rejected under 35 U.S.C. 103 as being unpatentable over Kragh (Pat. 10,255,419) further in view of Friese et al. (US 2019/0122753).
Regarding claim 1, Kragh teaches.
a system for securely storing and providing medical image data comprising: a hub device comprising a processor, a storage device, and a display [para 7] “Upon being validated and authenticated with a digital ID coupled with authenticated and non-authenticated attributes that have a high trust level of assurance or having public key certificate, in good standing, then a person's (subject) authenticated identity can be enhanced with other attributes that originate from an Attribute Certification, currently recognized as a certified Identity Provider (IdP), that provides an identity proofing process where one's Authentication privilege is created extended to provide “certified binding attributes’ that link to a user's primary mobile computing device or ‘hub’ such as a smartphone, smartwatch, glasses or lap top, each with a unique identifier, that is user controlled for managing activities such as access control, secure email, access privileges and associated relationships on applications that have unique identifiers.” where the smartphone comprises aforementioned components)
a security token device configured to store a set of security token data and configured to be selectively communicatively coupled to the hub device: [para 74] “Next an internal unique identity number is generated and assigned (block 137) in concert with defined authenticated user attributes and also a separate and distinct unique, external enterprise patient/consumer voluntary Health ID controlled index number (VHID) is generated (block 138) and used as an external user identifier that can be placed on a user's primary smartphone or on different types of token devices reflected in 0017.” where the VHID is security token data and the token devices can be in connection with the hub device)
a cloud imaging database that is in communication with the hub device and configured to store sets of medical image data ([Figure 5A] “server”; comprises a cloud imaging database connected to smartphones [i.e., hub devices]; see also [para 77] “pre-approved PCs, lap-top or a smart digital device such as cell or smartphone can be server-side based” where digital devices are hub devices and servers are a cloud imaging database; see also [Fig 5] “Medical Device Tech and Images & Interface Engine w/ Attributes” where the listed technology [i.e., hub devices] store set of medical imaging data in a cloud imaging database)
wherein the processor is configured to: ([145] “These computer program instructions may be provided to a processor of a general purpose computer”)
access the set of security token data when the security token device is coupled to the hub device and generate an anonymized identifier based on the set of patient data and the set of security token data ([para 99-100] Consider FIGS. 7A, 7 B and 7C interrelationships: FIG. 7A, Verifying and Validating the Authenticity of Identity Attributes; FIG. 7B, generating a value as a result of verifying the Authenticity of Attributes related to Biometrics, Devices, Tokes, Sensors, Applications, Bar-QR Codes and others so a user can designated which element they will use as Authenticators for gaining access based on a Trust Level Vale and FIG. 7C, the algorithm that configures the Trust Level of one's Personal Dataset, their primary authenticated smart device such as a smartphone that is bound to the user's Digital Identity and linked to verified and validated sensors, applications and other object features with identifiers preapproved for use. By way of example, consider following the Enrollment process where piece code (digital security elements) is transmitted to the user's pre-approved smartphone or other user smart hub device along with their personal Voluntary Healthcare Digital ID that enables electronic access to their Personal Emergency Medical and Contact dataset along with their own Personal Health Record (PHR)” where the hub device receives digital security elements [comprising security token data] upon coupling the device to an authenticated smart devise [comprising a token device] and uses a voluntary health Digital ID [comprising an anonymized identifier based on the patient dataset])
Regarding claim 1, Kragh does not explicitly teach, as taught by Friese:
receive and locally store on the storage device a set of medical image data and a set of patient data, each associated with a patient, from an image data source ([0030] “If a patient is now intended to be examined in the hospital with the aid of a computer tomograph 4, for example, some sensitive patient data, for example the patient's name and date of birth, are first of all stored in a memory of the computer tomograph 4 during an input process step 6 before the examination. The actual examination of the patient is then carried out, during which raw data are generated using the computer tomograph 4 during a scanning process” where the computer tomograph [i.e. an image source] images and examines a patient [i.e., receive and locally store medical image data and a set of patient data] while storing the information in the memory [i.e., locally stores on the storage device] the patients’ medical image data)
create a patient repository for the patient on the cloud imaging based on the anonymized identifier, ([Friese 0030] “If a patient is now intended to be examined in the hospital with the aid of a computer tomograph 4, for example, some sensitive patient data, for example the patient's name and date of birth, are first of all stored in a memory of the computer tomograph 4 during an input process step 6 before the examination. The actual examination of the patient is then carried out, during which raw data are generated using the computer tomograph 4 during a scanning process step 8. Once this scanning process step 8 has been concluded, a patient-related data record is created from the raw data in which data record the sensitive patient data input in the input process step 6 are incorporated during an embedding process step 10. These sensitive patient data are also supplemented with further sensitive patient data which characterize and uniquely identify the examination carried out on the computer tomograph”) scan the set of medical image data to identify any embedded patient data, modify the set of medical image data so that the embedded patient data is not present, ([0032] -[0033] where a patient’s name and date of birth are selected as key data and anonymized using a one way has function to secure the sensitive information for authorized users only; see optionally [0025]- [0027] including “The doctor first of all inputs the name and date of birth of his patient in an input window, whereupon a QR code is generated on the basis of the name and date of birth using a given one-way hash function.” where scanning and modifying medical image data can also occur when an X-ray will depict a barcode or QR code containing embedded patient information after the patient information is scanned and identified and will display the patient information in either a plain or deidentified manner) and store the set of medical image data in the patient repository; ([Friese 0015] “Accordingly, the anonymized patient-related data records can be provided in the cloud computing architecture and can be stored and/or processed further in the latter without the sensitive patient data appearing as plain data”)
immediately after generating the anonymized identifier, scrub the locally stored set of patient data so that it is no longer stored on the storage device; ([0016] “The authorized persons are then given access to the patient-related data records via this client computer which is connected to the cloud computing architecture. Since only a comparison is carried out here, in which the anonymized sensitive patient data generated on the client computer are compared with the anonymized sensitive patient data in the anonymized patient-related data records, the plain data also do not appear in the cloud computing architecture even when accessing the latter.” where the plain data not appearing comprises scrubbing the locally stored set of patient data so that the information no longer stored on the storage device)
display a patient image data interface via the display that comprises descriptions of a plurality of patient repositories stored by the cloud imaging database, ([0034] “patient-related data record anonymized in this manner is then delivered from the immediate control area of the hospital to the cloud computing architecture” and [0036] “generating display data for display on a monitor” where anonymized data is displayed on a monitor in repositories)
wherein: when the set of security token data is not accessible by the hub device, the plurality of patient repositories are each displayed based upon their corresponding anonymized identifiers; ([0033] “The test data, here the numerical sequence or character string, are then generated from these key data using a one-way hash function and are incorporated in the patient-related data record with the aid of the additional “tag” for identifying the latter. All sensitive patient data contained in the patient-related data record are additionally anonymized in an anonymization process step 20 with the aid of the same one-way hash function and are replaced with numerical sequences or character strings as placeholders. In addition, the key data are incorporated, as test data, in the form of a QR code in each transverse slice, with the result that this QR code is always depicted at the top right-hand edge of the image when displaying a corresponding transverse slice on a monitor. In this case, the corresponding QR code is generated from the key data using a further hash algorithm, a 2-D barcode hash algorithm.” where the image depicts a patient repository)
when the set of security token data is accessible by the hub device: the processor is configured to convert each anonymized identifier to a corresponding set of patient data based upon the set of security token data; ([0016] “The authorized persons are then given access to the patient-related data records via this client computer” comprises security token data accessible by the hub device; see also [0027] “The testing process is then started, in which the QR code from the display and the QR code generated on the computer belonging to the doctor are virtually optically compared with one another, preferably in a software-based manner. If the two QR codes match, the display data are displayed as an image on the monitor of the computer belonging to the doctor. A second image in which the plain data represented by the QR code, that is to say the patient's name and date of birth, are displayed is then preferably superimposed on said image in the region of the displayed QR code. The doctor therefore does not see an x-ray, in the top right-hand corner of which a QR code is depicted, but rather sees an x-ray, in the top right-hand corner of which the patient's name and date of birth can be seen and read. In contrast, if the two QR codes do not match, the security function is triggered and a fault message is displayed, for example.” where the QR codes are identifiers converted to patient data based an authorized user scanning the QR code)
and the plurality of event repositories are each displayed based upon their corresponding set of patient data. ([0027] “The testing process is then started, in which the QR code from the display and the QR code generated on the computer belonging to the doctor are virtually optically compared with one another, preferably in a software-based manner. If the two QR codes match, the display data are displayed as an image on the monitor of the computer belonging to the doctor. A second image in which the plain data represented by the QR code, that is to say the patient's name and date of birth, are displayed is then preferably superimposed on said image in the region of the displayed QR code. The doctor therefore does not see an x-ray, in the top right-hand corner of which a QR code is depicted, but rather sees an x-ray, in the top right-hand corner of which the patient's name and date of birth can be seen and read. In contrast, if the two QR codes do not match, the security function is triggered and a fault message is displayed, for example.” Where the display data is the event repositories)
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Kragh with the teachings of Friese, with a reasonable chance of success, by removing the patient data so that it is no longer stored on the storage device after generating the identifier with the motivation of offering a more secure handling of sensitive information as taught by Friese over that of Kragh. Friese is adaptable to the system described in Kragh without a significant change in authentication processing in Kragh – while adding some additional elements, they still comparing identification and password information. Friese points out it is “often also necessary on account of legal provisions, to remove …Protected Health Information” [4], an important teaching of HIPAA. This would have allowed Friese’s “advantageous method for rendering and displaying medical images” [7] to inform the teachings of Kragh to improve upon his solution of government organized emergency response.
Regarding claim 2, Kragh-Friese as a combination teaches all of claim 1. Friese also teaches:
wherein the processor is further configured to, when displaying the patient image data interface with the set of security token data accessible by the hub device:(a) display the plurality of patient repositories based upon their corresponding anonymized identifiers as a local display layer; ([0037] “If the two QR codes do not match, a… fault notification draws the doctor's attention to the fact that the display data are assigned to an unknown patient.” where the notifications overlay upon anonymized patient repositories )
(b) access the set of security token data on the security token device, and search the local display layer to identify each anonymized identifier; and ([0038]“An additional image which is placed over the image based on the display data is also generated during an overlapping process step”)
(c) convert each anonymized identifier to the corresponding set of patient based on the set of security token data, and update the local display later to show the corresponding sets of patient data. ([0038]“As a result, the doctor does not see the desired x-ray in which the QR code is depicted at the top right but rather sees the desired x-ray in which the key data are depicted as plain data at the top right”)
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Kragh with the teachings of Friese, with a reasonable chance of success, by searching, converting, and updating the local display layer by way of the anonymized identifier and security token with the motivation of offering a more secure handling of sensitive information as taught by Friese over that of Kragh. Friese is adaptable to the system described in Kragh without a significant change in authentication processing in Kragh – while adding some additional elements, they still comparing identification and password information. Friese points out it is “often also necessary on account of legal provisions, to remove …Protected Health Information” [4], an important teaching of HIPAA. This would have allowed Friese’s “advantageous method for rendering and displaying medical images” [7] to inform the teachings of Kragh to improve upon his solution of government organized emergency response.
Regarding claim 3, Kragh-Friese as a combination teaches all of the limitations of claim 2. Friese also teaches:
wherein the corresponding sets of patient data: (a) are not stored in any persistent storage device of the hub device; (b) are not provided to any other device by the hub device; and (c) are stored by the hub device only while the patient image data interface is displayed ([0016] “Since only a comparison is carried out here, in which the anonymized sensitive patient data generated on the client computer are compared with the anonymized sensitive patient data in the anonymized patient-related data records, the plain data also do not appear in the cloud”)
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Kragh with the teachings of Friese, with a reasonable chance of success, by only storing information when the information is displayed with the motivation of offering a more secure handling of sensitive information as taught by Friese over that of Kragh. Friese is adaptable to the system described in Kragh without a significant change in authentication processing in Kragh – while adding some additional elements, they still comparing identification and password information. Friese points out it is “often also necessary on account of legal provisions, to remove …Protected Health Information” [4], an important teaching of HIPAA. This would have allowed Friese’s “advantageous method for rendering and displaying medical images” [7] to inform the teachings of Kragh to improve upon his solution of government organized emergency response.
Regarding claim 4, Kragh-Friese as a combination teaches all of the limitations of claim 1. Kragh also teaches:
wherein the security token device is a portable electronic memory device ([5]“factor(s) is commonly used for identity and can include, (if already verified and validated) one or several of the following devices … PIV, mag-strip-smartcard or a bank issued smart EMV card along with a smart watch and glasses.” Describes a security token device)
Regarding claim 5, Kragh-Friese as a combination teaches all of the limitations of claim 1. Kragh also teaches:
wherein the processor is further configured to create an optical code for the patient based on the location of the patient repository in the cloud imaging database wherein the optical code is configured to be read by a user device of the patient to cause the user device of the patient to access the patient repository ([50]“the user only needs to present the digital image of the credentialed document on their user-hub smart phone that is authenticated to the user. The digital image will reflect the document, its chip, bar code or QR code that will be read electronically while being displayed while also enabling real time verification of the document's visual security features”)
Response to Applicant’s Arguments
Applicants arguments are acknowledged and will be addressed in the order in which they were presented.
Regarding page 5-7, Applicant’s arguments have been fully considered but are not persuasive. Applicant argues that the prior art of record, Friese, teaches display data that is already processed and displayed for a user to see on the computer and fails to teach processing the information in the hub device. Applicant continues to argue that the medical image data is not located on a hub device, scanned on the device, and not further modified to remove patient data before being uploaded to a cloud patient repository. MPEP 2111.01 states that the claims must be given their plain meaning unless such meaning is inconsistent with the specification. Under broadest reasonable interpretation, the hub device comprises devices such as a computer and phone, which both can be connected to the server or cloud of a respective system. This is confirmed by Applicant’s specification in paragraph [0023] that states “A cloud imaging hub (100) may be a computer, tablet computer, smartphone, laptop, or other computing device having a display, user interface, processor and memory, and other common computer components.” In paragraphs [0021]-[0028], cited by applicant, the computing systems depicted in Friese scans the unprocessed patient medical imaging for patient information, performs the removal of patient information after receiving the unprocessed information, and removes the patients information while anonymizing the information for use by authorized personnel. Thus, Examiner maintains that Friese teaches the claimed language, as written in the prior art rejection depicted above.
Pertinent Prior Art
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Hosaki (US20090285479) the present invention relates to encoding and decoding techniques of image data.
Dekel et al. (US20130129165) discloses determining a hanging protocol for display of clinical images in a study.
Connel et al. (US 20100046808) discloses a method for generating a cancelable biometric.
Midgal et al. (US 20150049912) discloses a system which transforms original data and distorts portions to prevent access to private information.
Oowaki et al. (Pat 8726368) discloses a security management system for authenticating users to acquire various patient information and devices
Kundu et al. (US20150049912) discloses a system to transform image data, and application of transform distorts portions of original image data to remove private information.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ROBERT ANTHONY SKROBARCZYK whose telephone number is (571)272-3301. The examiner can normally be reached Monday thru Friday 7:30AM -5PM CST.
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, Kambiz Abdi can be reached at (571) 272-6702. 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.
/R.A.S/Examiner, Art Unit 3685
/KAMBIZ ABDI/Supervisory Patent Examiner, Art Unit 3685