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 .
Status of Claims
Claims 1-15 and 20 are pending.
This communication is in response to the communication filed on February 26, 2026.
Claim Objections
Claim 1 is objected to for minor informalities. Claim 1 recites “a polarity of sources of medical information” and should recite “a plurality of sources of medical information”. Appropriate correction is required.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
Use of the word “means” (or “step for”) in a claim with functional language creates a rebuttable presumption that the claim element is to be treated in accordance with 35 U.S.C. 112(f) (pre-AIA 35 U.S.C. 112, sixth paragraph). The presumption that 35 U.S.C. 112(f) (pre-AIA 35 U.S.C. 112, sixth paragraph) is invoked is rebutted when the function is recited with sufficient structure, material, or acts within the claim itself to entirely perform the recited function.
Absence of the word “means” (or “step for”) in a claim creates a rebuttable presumption that the claim element is not to be treated in accordance with 35 U.S.C. 112(f) (pre-AIA 35 U.S.C. 112, sixth paragraph). The presumption that 35 U.S.C. 112(f) (pre-AIA 35 U.S.C. 112, sixth paragraph) is not invoked is rebutted when the claim element recites function but fails to recite sufficiently definite structure, material or acts to perform that function.
Claim elements in this application that use the word “means” (or “step for”) are presumed to invoke 35 U.S.C. 112(f) except as otherwise indicated in an Office action. Similarly, claim elements that do not use the word “means” (or “step for”) are presumed not to invoke 35 U.S.C. 112(f) except as otherwise indicated in an Office action.
Claim limitations “module for handling information” and “the module” have been interpreted under 35 U.S.C. 112(f), because they use generic placeholders “module” coupled with functional language without reciting sufficient structure to achieve the function. Furthermore, the generic placeholder is not preceded by a structural modifier.
Since the claim limitation(s) invokes 35 U.S.C. 112(f), claims 1-15 and 20 have been interpreted to cover the corresponding structure described in the specification that achieves the claimed function, and equivalents thereof.
A review of the specification shows that the following appears to be the corresponding structure described in the specification for the 35 U.S.C. 112(f) limitations: In one embodiment the invention is a module that is part of an image sharing server. The module can be a combination of hardware and software, or just software or just hardware. (p. 2).
If applicant wishes to provide further explanation or dispute the examiner’s interpretation of the corresponding structure, applicant must identify the corresponding structure with reference to the specification by page and line number, and to the drawing, if any, by reference characters in response to this Office action.
If applicant does not intend to have the claim limitation(s) treated under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112 , sixth paragraph, applicant may amend the claim(s) so that it/they will clearly not invoke 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, or present a sufficient showing that the claim recites/recite sufficient structure, material, or acts for performing the claimed function to preclude application of 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
For more information, see MPEP § 2173 et seq. and Supplementary Examination Guidelines for Determining Compliance With 35 U.S.C. 112 and for Treatment of Related Issues in Patent Applications, 76 FR 7162, 7167 (Feb. 9, 2011).
Claim Rejections - 35 USC § 112(b)
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.
Claims 1-15 and 20 are rejected under 35 U.S.C. 112(b) 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.
The term “automatically delivering the medical information to a plurality of destinations substantially simultaneously” in claim 20 of which “substantially simultaneously” is a relative term which renders the claim indefinite. Substantially simultaneously may refer to when a plurality of instances of data can be sent to one destination or a plurality of destinations at the same time, at the same time and about the same time (specification p. 20). The term is not defined by the claim, the specification does not provide a specific standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention.
The term “wherein the module relates pieces of medical information to one another using best data available” in claim 8 of which “best data available” is a relative term which renders the claim indefinite. The term is not defined by the claim, the specification does not provide a specific standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention.
Claims 1 and 20 recite the limitation “module”. The limitation invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. It is unclear how the module may be any combination of hardware and software as stated in specification page 2. Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Applicant may:
(a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph;
(b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(c) Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)).
If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either:
(a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing 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
(b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181.
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 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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
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 set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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-15 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Haskell et al. US20030233251 in view of Bruegl et al. US20060168338 in further view of Cotugno et al. US20100332629.
As per claim 1, Haskell teaches
a computer system for medical information comprising: a polarity of sources of medical information, at least one source of medical information, including DICOM files; (Haskell par. 25 teaches healthcare data processing systems using various types of data formats including DICOM.)
a memory for storing medical information, including DICOM files, from the plurality of sources; (Haskell par. 20, 29, 35 teaches repositories with medical data)
a processor communicatively coupled to the memory and the plurality of sources; (Haskell par. 20, fig. 1 and associated paragraphs teach processors, interfaces, and data repositories)
a module for handling information, the module executable on the processor including a set of instructions for receiving medical information from the plurality of sources, storing information, and automatically delivering the medical information to a plurality of destinations; (Haskell par. 23, 37, claim 19 teaches a healthcare dictionary system, comprising: an input processor for acquiring healthcare transaction message data in at least one of a plurality of different data formats; a data processor for, parsing said acquired transaction message data and extracting a term from said acquired transaction message data.)
a database that includes connection information for the plurality of destinations that include: (Haskell par. 23 teaches healthcare information systems contain messages which contain data which may include: (a) a communication involving a healthcare enterprise laboratory, (b) a communication involving a healthcare enterprise pharmacy, (c) a communication involving a healthcare enterprise radiology department, (d) a communication involving a healthcare enterprise modality department, (e) a communication involving a healthcare enterprise administration operation (f) a communication involving a healthcare enterprise orders or results management operation; and/or any other data to be communicated between one facility within the healthcare enterprise and other facility within or without the enterprise.)
at least one destination for receiving medical information directly from the computer system, (Haskell par. 23-24 teaches destinations for receiving medical information messages)
Haskell does not specifically teach the following limitations met by Bruegl, wherein a destination is designated, and the database provides the module with the connection information needed to securely send the information to the destination (Bruegl par. 106 teaches Selected Studies may be used when Studies are sent to a destination. In the Select Radiologist Destination feature, a list of destinations may be provided for sending studies. In the Control Study feature, controlling studies may involve any manipulation of Study data that can be changed. This may involve: sending a Study, splitting up a Study, setting Study data, updating a Study, locking a Study, unlocking a Study, and merging Studies. In the Send Study feature, send study may send the currently selected Studies in the Studies Worklist to the currently selected destination or user. In the Send Slices feature. the slices that have been selected in the Slice Image thumbnail panel may be sent to the currently selected destination or user.).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to modify the systems and methods as taught by Haskell to providing connection information to securely send information as taught by Bruegl with the motivation to improve medical information communication systems. There is a need to develop a system that is capable of receiving increasingly large quantities of data, accessing the data for QC, and sending the data to a user to be examined. The current problems include increased latency of data transfer, the increased volume of data is becoming more inefficient with existing workflow solutions. All data currently needs to be present everywhere, and current software will soon be insufficient to handle the high volumes of data. The successful solution would be to create a system that would control the entire process of receiving the data, displaying the data for QC, and sending the data to the appropriate user. (Bruegl par. 3).
Haskell and Bruegl do not specifically teach the following limitations met by Cotugno, a plurality of clouds, the data base associating at least one cloud to at least one of the plurality of destinations (Cotugno fig. 10, claim 8 teaches a plurality of cloud storage facilities, which are communicatively connective to each other and a plurality of various destinations and archiving at least a portion of the computing resources associated with the custom application in the cloud computing environment; and, deprovisioning the computing resources in the cloud environment that were associated with the custom application.)
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to modify the systems and methods as taught by Haskell and Bruegl to use a plurality of clouds as taught by Cotugno with the motivation to enable traditional information technology systems around newer technology (Cotugno par. 7-8).
As per claim 2, Haskell, Bruegl, and Cotugno teach all the limitations of claim 1 and further teach wherein the database tracks referral sources and the referral sources method of connectivity such as one of the plurality of cloud providers, a portable storage device, a media device or a direct secure share (Bruegl par. 761, 777 teaches an order tracking website that may be used to track orders or requests by different doctors. A system has the ability to track the opened case and assign it to the radiologist who issued the preliminary report. The radiologist's comments on the case may be stored and reported back to the customer on various stated devices. Here the referral source is the source that requests medical information as described in the specification p. 3).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to modify the systems and methods as taught by Haskell to track referral sources and use referral sources of connectivity as taught by Bruegl with the motivation to improve medical information communication systems. There is a need to develop a system that is capable of receiving increasingly large quantities of data, accessing the data for QC, and sending the data to a user to be examined. The current problems include increased latency of data transfer, the increased volume of data is becoming more inefficient with existing workflow solutions. All data currently needs to be present everywhere, and current software will soon be insufficient to handle the high volumes of data. The successful solution would be to create a system that would control the entire process of receiving the data, displaying the data for QC, and sending the data to the appropriate user. (Bruegl par. 3).
As per claim 3, Haskell, Bruegl, and Cotugno teach all the limitations of claim 1 and further teach wherein the medical information includes at least one of lab results, medical professionals notes, and lab report (Haskell par. 26 teaches information including cbc lab tests).
As per claim 4, Haskell, Bruegl, and Cotugno teach all the limitations of claim 1 and further teach wherein the medical information includes information generated by other medical devices (Haskell par. 6 teaches All of the selected terms are then processed to automatically generate structured medical information for the medical record. A term may be manually added to the lexicon, possibly after the approval of a medical director or other person of authority. For example, if a desired term is not in the lexicon, a doctor may request that it be added to the lexicon. In addition, medical texts may be scanned and parsed, and terms found in the texts automatically added to the lexicon.).
As per claim 5, Haskell, Bruegl, and Cotugno teach all the limitations of claim 1 and further teach wherein the module parses incoming medical information to get physician, patient and study information (Haskell par. 6-9 teaches parsing medical records, which may include information on doctors, patients, and examination results).
As per claim 6, Haskell, Bruegl, and Cotugno teach all the limitations of claim 5 and further teach wherein the module can modify the format of a report to one of a plurality of formats (Bruegl par. 103, 493 teaches format conversion for studies).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to modify the systems and methods as taught by Haskell to modify formats of reports as taught by Bruegl with the motivation to improve medical information communication systems. There is a need to develop a system that is capable of receiving increasingly large quantities of data, accessing the data for QC, and sending the data to a user to be examined. The current problems include increased latency of data transfer, the increased volume of data is becoming more inefficient with existing workflow solutions. All data currently needs to be present everywhere, and current software will soon be insufficient to handle the high volumes of data. The successful solution would be to create a system that would control the entire process of receiving the data, displaying the data for QC, and sending the data to the appropriate user. (Bruegl par. 3).
As per claim 7, Haskell, Bruegl, and Cotugno teach all the limitations of claim 5 and further teach wherein the module relates pieces of medical information to one another using an Accession number (Bruegl par. 88 teaches using accession numbers as unique DICOM Instance IDs).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to modify the systems and methods as taught by Haskell to use accession numbers as taught by Bruegl with the motivation to improve medical information communication systems. There is a need to develop a system that is capable of receiving increasingly large quantities of data, accessing the data for QC, and sending the data to a user to be examined. The current problems include increased latency of data transfer, the increased volume of data is becoming more inefficient with existing workflow solutions. All data currently needs to be present everywhere, and current software will soon be insufficient to handle the high volumes of data. The successful solution would be to create a system that would control the entire process of receiving the data, displaying the data for QC, and sending the data to the appropriate user. (Bruegl par. 3).
As per claim 8, Haskell, Bruegl, and Cotugno teach all the limitations of claim 5 and further teach wherein the module relates pieces of medical information to one another using best data available (Haskell par. 3, 9 teaches searching medical terms using best practices, interpreted as using best data available since the data was gathered using the best practices available.).
As per claim 9, Haskell, Bruegl, and Cotugno teach all the limitations of claim 8 and further teach wherein the module performs a query of an archive to find archived information related to the medical information (Haskell par. 3, 7, 9, 36 teaches searching medical records.).
As per claim 10, Haskell, Bruegl, and Cotugno teach all the limitations of claim 9 and further teach the module is configurable to search selected archives (Haskell par. 6, 36 teaches querying a central term repository and selected facility repositories.).
As per claim 11, Haskell, Bruegl, and Cotugno teach all the limitations of claim 9 and further teach the module is configurable to search archives for selected time frames to find relevant prior studies (Haskell par. 36 teaches perform a query on the central term repository 506 to identify a set of terms matching desired criteria, such as only new terms acquired within a particular time period, or criteria based on attributes of the terms themselves such as only terms acquired from a particular source, or only terms of a particular status).
As per claim 12, Haskell, Bruegl, and Cotugno teach all the limitations of claim 9 and further teach the module is configurable to exclude selected series from a study (Bruegl par. 106 teaches locking studies, here locked studies are interpreted as excluded studies.).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to modify the systems and methods as taught by Haskell to exclude selected series from a study as taught by Bruegl with the motivation to improve medical information communication systems. There is a need to develop a system that is capable of receiving increasingly large quantities of data, accessing the data for QC, and sending the data to a user to be examined. The current problems include increased latency of data transfer, the increased volume of data is becoming more inefficient with existing workflow solutions. All data currently needs to be present everywhere, and current software will soon be insufficient to handle the high volumes of data. The successful solution would be to create a system that would control the entire process of receiving the data, displaying the data for QC, and sending the data to the appropriate user. (Bruegl par. 3).
As per claim 13, Haskell, Bruegl, and Cotugno teach all the limitations of claim 1 and further teach wherein selected tasks are done as part of an automated operation (Haskell par. 6, 10-11, 35, claim 12teaches systems for automatic processes).
As per claim 14, Haskell, Bruegl, and Cotugno teach all the limitations of claim 1 and further teach wherein the module presents a drag and drop user interface that presents prompts related to sending information from the computer system to another destination (Bruegl par. 84, 131, 479 teaches the system may provide a GUI QC tool. The IID system may provide a GUI based tool that assists a QC Team Member in their workflow. DICOM studies may be viewable, using image window levels and advanced scrolling techniques. Fax transmissions may be viewable with zoom and panning. A global work list may be provided that will promote a fair and efficient workflow within the QC Team. A QC Team Member may be able to send a specific study to a destination. DICOM studies may be marked for splitting apart or merging.).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to modify the systems and methods as taught by Haskell to use drag and drop functions presenting prompts to send information as taught by Bruegl with the motivation to improve medical information communication systems. There is a need to develop a system that is capable of receiving increasingly large quantities of data, accessing the data for QC, and sending the data to a user to be examined. The current problems include increased latency of data transfer, the increased volume of data is becoming more inefficient with existing workflow solutions. All data currently needs to be present everywhere, and current software will soon be insufficient to handle the high volumes of data. The successful solution would be to create a system that would control the entire process of receiving the data, displaying the data for QC, and sending the data to the appropriate user. (Bruegl par. 3).
As per claim 15, Haskell, Bruegl, and Cotugno teach all the limitations of claim 1 and further teach wherein the module further comprises hardware components and software components (Haskell par. 20 teaches computer hardware and software).
As per claim 20, Haskell, Bruegl, and Cotugno teach all of the claim limitations, A computer system for medical information comprising: a source of medical information, including DICOM files; a memory for storing medical information, including DICOM files, from the source; a processor communicatively coupled to the memory and the source; a module executable on the processor including instructions for receiving medical information from the source, storing information, and automatically delivering the medical information to a plurality of destinations substantially simultaneously; a database that includes connection information for: a plurality of clouds and associates each of the clouds to the plurality of destinations, and at least one destination for receiving medical information directly from the computer system, wherein a destination is designated and the database provides the module with the connection information needed to securely send the information to the destination (see claim 1 rejection).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAY M. PATEL whose telephone number is (571)272-6793 and email is jay.patel2@uspto.gov. The examiner can normally be reached on Monday-Friday 8AM-4:30PM.
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, Peter H. Choi can be reached on (469)295-9171. 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.
/JAY M. PATEL/Primary Examiner, Art Unit 3686