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 .
Response to Amendment
The amendment filed on 02/02/2026 has been entered. Claims 1-3 and 5 have been amended. Claims 1-20 remain pending.
The previously raised objections for Claims 1-3 and 5 are withdrawn because the issues have been properly corrected.
The previously raised rejections under 35 U.S.C. 112(b) for Claims 1-20 are withdrawn because the issues have been properly corrected.
Response to Arguments
On Pages 7-8 of Remarks, Applicant argues that, regarding the limitations of “initiate a selection prompt …; and initiate a configuration prompt …, wherein the configuration prompt is … and wherein the configuration specifies …” of amended Claim 1, reference Rothberg does not teach the limitations, and reference Bao does not cure the above deficiencies of Rothberg. This argument is moot in view of the new grounds of rejection which relies on the combination of reference Bao and reference Weiner (US 20080217392 A1) to disclose these limitations in the claims. A new reference Cumbie (US 20150213203 A1) included in the section of Conclusion also discloses examples of how to process barcode data based on patient identification number embedded in the data.
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.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
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.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier.
Such claim limitation is: “a mobile device … running an ultrasound application” in Claim 1. A review of the Specification discloses that the corresponding structure for the “a mobile device … running an ultrasound application” is formed of “operative communication (either through a wireless or wired connection) with the ultrasound device 102”, “a graphical user interface (GUI) … to configure the ultrasound device for a particular type of ultrasound scan” (Para 0027), and “a camera” (Para 0028), and may be “a smartphone, tablet, or laptop” (Para 0027).
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claim 1, Lines 12-14, recites “wherein the configuration specifies how data fields extracted from the barcode are to be mapped to parameters of an electronic health record query”. Specification of Application does not provide sufficient support for the claimed limitation.
Claims 2-20 are also rejected under 35 U.S.C. 112(a) because they inherit the deficiencies of the claim(s) they respectively depend upon.
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.
Claim 1, Lines 12-14, recites “wherein the configuration specifies how data fields extracted from the barcode are to be mapped to parameters of an electronic health record query”. It is unclear what “parameters of an electronic health record query” refer to. For present purposes of examination, the recited “parameters” is interpreted to be data types that can be used to identify a patient or a subject, such as patient identification number, patient name, date of birth, and so on.
Claims 2-20 are also rejected under 35 U.S.C. 112(b) because they inherit the indefiniteness of the claim(s) they respectively depend upon.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim 1 is rejected under 35 U.S.C. 103 as being unpatentable over Rothberg et al (US 20170360412 A1; hereafter Rothberg), in view of Bao (US 20130197992 A1; hereafter Bao), and further in view of Weiner et al (US 20080217392 A1; hereafter Weiner).
With regard to Claim 1, Rothberg discloses an ultrasound system, comprising:
an ultrasound device (Rothberg, Para 0017; “… a system is provided that comprises an ultrasound device …”);
a mobile device in operative communication with the ultrasound device (Rothberg, Para 0181; “… an ultrasound device 102 that is communicatively coupled to the computing device 104 by a communication link 112.”) and running an ultrasound application (Rothberg, Para 0144; “The guidance may be provided via a software application (hereinafter “App”) installed on a computing device of the operator (such as: a mobile device, a smartphone or smart-device, tablet, etc.)”);
a processing device (Rothberg, Para 0313; “As shown in FIG. 15B, these external devices may include servers 1518, workstations 1520, and/or databases 1522.”); and
a cloud comprising one or more servers, wherein the ultrasound device and the processing device are in communication with the cloud (Rothberg, Para 0313; “… the computing device 1502 may communicate with one or more external devices via the network 1516 … As shown in FIG. 15B, these external devices may include servers 1518, workstations 1520, and/or databases 1522.”);
wherein the processing device (Rothberg, Para 0144; “The guidance may be provided via a software application (hereinafter “App”) …”. In this disclosure, the processing procedure is configured and provided as a software or App.) is configured; and
wherein the mobile device is configured to:
download, from the cloud, barcode settings (Rothberg, Para 0144; “… a software application (hereinafter “App”) … the operator may install the App on a computing device and connect the computing device to an ultrasound device …”; Para 0223; “the computing device 804 reads the QR code”),
perform an ultrasound scan on a patient in conjunction with the ultrasound device (Rothberg, Para 0308; “The ultrasound device 1514 may be configured to generate ultrasound data that may be employed to generate an ultrasound image.”);
scan a barcode associated with the patient (Rothberg, Para 0222; “… instruct the operator to scan a quick response (QR) code associated with the ultrasound device.”; Para 0223; “The subject information screen may include a display of subject information 810 obtained by the computing device 804 using the scanned QR code.”);
process the barcode data encoded in the scanned barcode based on the downloaded barcode settings (Rothberg, Para 0223; “Once the computing device 804 reads the QR code, the computing device 804 may transition from the home screen shown in FIG. 8A to a subject information screen shown in FIG. 8B.”); and
perform an electronic health record (EHR) query based on data from the processed barcode (Rothberg, Para 0252; “… the computing device may use information obtained from the barcode to access medical records associated with the subject on a remote server.”).
Rothberg does not clearly and explicitly disclose wherein the processing device is configured to:
initiate a selection prompt for and receive a selection of a barcode type; and
initiate a configuration prompt for and receive configuration of how to process barcode data encoded in a barcode of the selected barcode type, wherein the configuration prompt is based on the selected barcode type and wherein the configuration specifies how data fields extracted from the barcode are to be mapped to parameters of an electronic health record query.
Bao in an analogous field of endeavor discloses:
initiating a selection prompt for and receiving a selection of a barcode type (Bao, Para 0148; “The participant-user is prompted to choose the type of QR Code to generate 510, then to enter QR Code data 512, …); and
initiating a configuration prompt for and receiving configuration of how to process barcode data, wherein the configuration prompt is based on the selected barcode type (According to Specification (Para 0005) of Application, the claimed “configuration of how to process barcode data” comprises selection of application identifier or delimiter and their associated data or information type, and the data or information type is for identifying a subject or patient (the disclosed step 204 in Para 0035-0037). Bao, Para 0148; “The participant-user is prompted to choose the type of QR Code …, then to enter QR Code data 512, …”; Para 0150; “The participant-user may choose from the following list of QR Code Modes: …”. Detailed procedure of the disclosed choosing is in Fig. 6a of Bao. Here the disclosed choosing of QR code mode corresponds to selection of data or information type, so can be interpreted as specifying how to process barcode data. It is also noted that Bao explicitly discloses to first choose QR code type, and then to choose code mode).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Rothberg, as suggested by Bao, in order to select barcode of different types and determine what data to be encoded in the barcode. One of ordinary skill in the art would have been motivated to make the modification for the benefit of making the system to be compatible with different types of barcodes (Rothberg, Para 0224; “It should be appreciated that other types of bar codes may be employed separate from QR codes. Other example bar codes include: MaxiCode bar codes, Codabar bar codes, and Aztec bar codes.”) and therefore allowing the system to encode and convey different types of data as needed by the practitioner.
Rothberg and Bao do not explicitly and clearly disclose specifying how data fields extracted from the barcode are to be mapped to parameters of an electronic health record query.
Weiner in the same field of endeavor discloses specifying how data fields extracted from the barcode are to be mapped to parameters of an electronic health record query (Weiner, Para 0039; “Referring to FIG. 3A, the data has been demarcated into three data elements using spaces as the delimiter prior to being tokenized. … In accordance with the computer-executable instructions, the first such element is tokenized to be the patient's name. Such a data element maybe further demarcated and tokenized such that the element is comprised of two sub-elements, delimited by a comma. The first such sub-element is the last name, and the second such sub-element is the first name. The second data element is tokenized to be the patient's Social Security number. …”). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Rothberg and Bao, as suggested by Weiner, in order to specify how a patient’s identification information is embedded in a barcode. One of ordinary skill in the art would have been motivated to make the modification for the benefit of improving efficiency of patient data management and ensuring correctly identifying patients by using a predetermined format or standard for encoding patient-worn barcode (Weiner, Para 0009-0010; “one hospital may use patient wristbands which contain a patient name (last name first) followed by a medical record number, a second hospital may use patient wristbands which contain the medical record number, followed by the patient's date of birth, gender, and patient name (first name first) … Therefore, a method for processing barcode data is desired wherein the data can be provided to a software application in an acceptable format”).
Claim 2 and 5-6 are rejected under 35 U.S.C. 103 as being unpatentable over Rothberg, Bao and Weiner, further in view of Sanchez et al (US 20210169336 A1; hereafter Sanchez).
With regard to Claim 2, Rothberg, Bao and Weiner disclose all the limitations of Claim 1 as discussed above. Rothberg further discloses wherein the processing device is configured, when prompting for and receiving the selection of the barcode type, to prompt for and receive a selection of a 1D non-GS1 barcode, or a 2D barcode (Rothberg, Para 0224; “other types of bar codes may be employed separate from QR codes. Other example bar codes include: MaxiCode bar codes, Codabar bar codes, and Aztec bar codes.”. Codabar barcode is a 1D non-GS1 barcode. Aztec barcode is a 2D barcode).
Rothberg, Bao and Weiner do not clearly and explicitly disclose including 1D GS1 barcode as an option.
Sanchez in the same field of endeavor discloses including 1D GS1 barcode as an option (Sanchez, Para 0271; “A patient identity may be encrypted and encoded in a visual graphical code. … A barcode may be a UPC barcode, EAN barcode, Code 39 barcode, ITF barcode, CodaBar barcode, GS1 DataBar barcode, …”. All the listed barcode types are 1D GS1 barcodes). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Rothberg, Bao and Weiner, as suggested by Sanchez, in order to provide 1D GS1 barcode as a selective option. One of ordinary skill in the art would have been motivated to make the modification for the benefit of 1D GS1 barcode being one of the most widely used types of barcode.
With regard to Claim 5, Rothberg, Bao and Weiner disclose all the limitations of Claim 1 as discussed above, but not clearly and explicitly disclose wherein the processing device is configured, when prompting for and receiving the configuration of how to process the barcode data, to prompt for input of application identifiers and a data type associated with each of the application identifiers when the selected barcode type is a 1D GS1 barcode.
Sanchez in the same field of endeavor discloses wherein the processing device is configured, when prompting for and receiving the configuration of how to process the barcode data, to prompt for input of application identifiers and a data type associated with each of the application identifiers when the selected barcode type is a 1D GS1 barcode (Sanchez, Para 0271; “… A patient identity may be encrypted and encoded in a visual graphical code. … A barcode may be … Code 128 barcode, …, GS1 DataBar barcode … A barcode may define an element such as a version, format, position, alignment, or timing of the barcode to enable reading and decoding of the barcode. A barcode can encode various types of information in any type of suitable format, such as binary or alphanumeric information.” To read the different pieces of information from a barcode, application identifiers are inherently necessary). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Rothberg, Bao and Weiner, as suggested by Sanchez, in order to use application identifiers in a 1D GS1 barcode. One of ordinary skill in the art would have been motivated to make the modification for the benefit of correctly interpreting the information in the barcode (Sanchez, Para 0271; “A barcode may define an element such as a version, format, position, alignment, or timing of the barcode to enable reading and decoding of the barcode.”).
With regard to Claim 6, Rothberg, Bao, Weiner and Sanchez disclose all the limitations of Claim 5 as discussed above, but do clearly and explicitly disclose wherein the data type comprises a first name, last name, date of birth, gender/sex, patient ID, encounter ID, or blank.
Sanchez further discloses wherein the data type comprises a first name, last name, date of birth, gender/sex, patient ID, encounter ID, or blank (Sanchez, Para 0271; “A subject identity may comprise patient's photo, name, address, social security number, birthday, telephone number, zip code, or any combination thereof.”). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Rothberg, Bao, Weiner and Sanchez, as further suggested by Sanchez, in order to embed identification information of patient into a barcode. One of ordinary skill in the art would have been motivated to make the modification for the benefit of enabling recognition of patient in a quick and accurate way.
Claim 3-4, 7-8, 14 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Rothberg, Bao and Weiner, further in view of Ninomiya (US 20150331860 A1; hereafter Ninomiya).
With regard to Claim 3, Rothberg, Bao and Weiner disclose all the limitations of Claim 1 as discussed above, but do not clearly and explicitly disclose wherein the processing device is configured, when prompting for and receiving the configuration of how to process the barcode data, to prompt for a selection of a data type encoded by the barcode when the selected barcode type is a 1D non-GS1 barcode.
Ninomiya in the same field of endeavor discloses wherein the processing device is configured, when prompting for and receiving the configuration of how to process the barcode data, to prompt for a selection of a data type encoded by the barcode (Ninomiya, Para 0030; “The information processing apparatus 400 may generate a barcode corresponding to the patient number”) when the selected barcode type is a 1D non-GS1 barcode (Ninomiya, Para 0068; “… the barcode may be a one-dimensional bar code or a two-dimensional barcode as illustrated in FIG. 7”). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Rothberg, Bao and Weiner, as suggested by Ninomiya, in order to encode a data type in the barcode. One of ordinary skill in the art would have been motivated to make the modification for the benefit of enabling patient identification information to be encoded so as to improve efficiency and accuracy of management of medical image data (Ninomiya, Para 0038; “the medical personnel may simply … In this way, the burden on the medical personnel may be reduced, and errors in associating image data with a corresponding patient may be prevented.”).
With regard to Claim 4, Rothberg, Bao, Weiner and Ninomiya disclose all the limitations of Claim 3 as discussed above, but do not clearly and explicitly disclose wherein the data type comprises patient ID or an encounter ID.
Ninomiya further discloses wherein the data type comprises patient ID or an encounter ID (Ninomiya, Para 0030; “The information processing apparatus 400 may generate a barcode corresponding to the patient number”). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Rothberg, Bao, Weiner and Ninomiya, as further suggested by Ninomiya, in order to encode patient number in the barcode. One of ordinary skill in the art would have been motivated to make the modification for the benefit of improving efficiency and accuracy of management of medical image data (Ninomiya, Para 0038; “Oftentimes, medical personnel are too busy to … to associate image data with a patient number … according to the image management system 1 of the present embodiment, the medical personnel may simply … In this way, the burden on the medical personnel may be reduced, and errors in associating image data with a corresponding patient may be prevented.”).
With regard to Claim 7, Rothberg, Bao and Weiner disclose all the limitations of Claim 1 as discussed above, but do not clearly and explicitly disclose wherein the processing device is configured, when prompting for and receiving the configuration of how to process the barcode data, to prompt for selection of a certain number of delimiters and a data type associated with each of the delimiters.
Ninomiya in the same field of endeavor discloses wherein the processing device is configured, when prompting for and receiving the configuration of how to process the barcode data, to prompt for selection of a certain number of delimiters and a data type associated with each of the delimiters (Ninomiya, Para 0069; “FIG. 8 illustrates an example of data in the XML (eXtensible Markup Language) format that may be obtained when the recognition unit 202 recognizes the two-dimensional barcode. In this case, the recognition unit 202 may recognize information items such as the patient name (“name”) and the output time (“date”), for example, in addition to the patient number (“id”).” As shown in Fig. 8, the symbols “<…> … </…>” are the delimiters that divide the different data types). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Rothberg, Bao and Weiner, as suggested by Ninomiya, in order to use a number of delimiters in the barcode. One of ordinary skill in the art would have been motivated to make the modification for the benefit of utilizing delimiters as in 2D barcodes for recognizing more structured and complicated information (Ninomiya, Para 0069; “By recognizing the two-dimensional barcode, the recognition unit 202 may be able to recognize more structured and complicated information as compared with the case of recognizing the one-dimensional bar code”).
With regard to Claim 8, Rothberg, Bao, Weiner and Ninomiya disclose all the limitations of Claim 7 as discussed above, but do not clearly and explicitly disclose wherein the data type comprises a first name, last name, date of birth, gender/sex, patient ID, encounter ID, or blank.
Ninomiya further discloses wherein the data type comprises a first name, last name, date of birth, gender/sex, patient ID, encounter ID, or blank (Ninomiya, Fig. 8 shows an example that the data obtaining from a barcode could include patient number and patient name). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Rothberg, Bao, Weiner and Ninomiya, as further suggested by Ninomiya, in order to embed identification information of patient into a barcode. One of ordinary skill in the art would have been motivated to make the modification for the benefit of recognizing more patient information by a recognition unit in an efficient and accurate way (Ninomiya, Para 0069; “In this case, the recognition unit 202 may recognize information items such as the patient name (“name”) and the output time (“date”), for example, in addition to the patient number (“id”).”).
With regard to Claim 14, Rothberg, Bao and Weiner disclose all the limitations of Claim 1 as discussed above, but do not clearly and explicitly disclose wherein:
the mobile device is configured, when scanning the barcode associated with the patient, to scan a barcode printed on a bracelet worn by the patient; and
the mobile device comprises a camera and is configured, when scanning the barcode associated with the patient, to capture an image of the barcode using the camera.
Ninomiya in the same field of endeavor discloses wherein:
the mobile device is configured, when scanning the barcode associated with the patient, to scan a barcode printed on a bracelet worn by the patient (Ninomiya, Para 0062; “… an output image including the barcode and patient information to be printed on a label 3, and the label 3 with the output image printed thereon may be attached to a wristband to be secured to the arm of a patient.” Para 0067; “The recognition unit 202 recognizes the corresponding patient number from the image of the barcode acquired by the image acquiring unit 201”); and
the mobile device comprises a camera and is configured, when scanning the barcode associated with the patient, to capture an image of the barcode using the camera (Ninomiya, Para 0097; “The image acquiring unit 201 of the image capturing apparatus 200 acquires an image of the barcode that is printed on the wristband (step S406).”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Rothberg, Bao and Weiner, as suggested by Ninomiya, in order to print and scan a barcode on a bracelet worn by the patient. One of ordinary skill in the art would have been motivated to make the modification for the benefit of avoiding loss and convenient access of the barcode (Ninomiya, Para 0031; “the image forming apparatus 500 may output the barcode and the patient information onto a label 3 to be attached to an accessory (e.g., wristband) that is secured to the patient's body (e.g., arm).”).
With regard to Claim 18, Rothberg, Bao and Weiner disclose all the limitations of Claim 1 as discussed above, but do not clearly and explicitly disclose wherein the mobile device is further configured, when there is only one matching encounter from the EHR query, to automatically associate the ultrasound scan with patient information from the matching encounter.
Ninomiya in the same field of endeavor discloses wherein the mobile device is further configured, when there is only one matching encounter from the EHR query, to automatically associate the ultrasound scan with patient information from the matching encounter (Ninomiya, Para 0032; “once the image capturing apparatus 200 recognizes the patient number from a barcode of a patient, the image capturing apparatus 200 may automatically associate image data of an affected area of the patient obtained thereafter with the corresponding patient number of the patient.”). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Rothberg, Bao and Weiner, as suggested by Ninomiya, in order to automatically associate image data with identification information for a patient. One of ordinary skill in the art would have been motivated to make the modification for the benefit of storing the acquired image data in an efficient and accurate way (Ninomiya, Para 0038; “… the burden on the medical personnel may be reduced, and errors in associating image data with a corresponding patient may be prevented.”).
Claim 9, 11-13, 15-17 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Rothberg, Bao and Weiner, further in view of David et al (US 20150120321 A1; hereafter David).
With regard to Claim 9, Rothberg, Bao and Weiner disclose all the limitations of Claim 1 as discussed above, but do not clearly and explicitly disclose wherein the processing device is further configured to determine that automatic EHR querying should be presented as an option.
David in the same field of endeavor discloses wherein the processing device is further configured to determine that automatic EHR querying should be presented as an option (David, Para 0066; “Upon receiving the identifier, the data reader 106 may initiate the data logger 109b to document 404 clinical information, based on the patient identifier in the server 118”. In this arrangement, data documentation is initiated immediately, without automatically querying EHR. David, Para 0067; “In some implementations, the data reader 106 may communicate with and access the centralized server 118 via the network 112. The centralized server 118, as described in FIG. 2, may process real-time measurement data 202 and continuously consolidate such information with the comprehensive patient record (e.g., patient record 120) in a proper format.” In this arrangement, documentation of measurement data is performed in a real-time manner, indicating automatic EHR querying (without a user’s manual initiation). To one of ordinary skill in the field, whether to automatically perform EHR querying can be presented to the user as an option). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Rothberg, Bao and Weiner, as suggested by David, in order to provide the selective option of automatically performing EHR querying. One of ordinary skill in the art would have been motivated to make the modification for the benefit of providing more flexibility on whether to perform EHR query automatically for different situations or needs (David, Para 0066; “when a patient is being transferred to an operating room, the physicians may only need to check pertinent drug consumption history from patient barcode label 104 for diagnostic purposes.”)(David, Para 0067; “… continuously consolidate such information with the comprehensive patient record (e.g., patient record 120) in a proper format”).
With regard to Claim 11, Rothberg, Bao, Weiner and David disclose all the limitations of Claim 9 as discussed above, but do not clearly and explicitly disclose wherein the processing device is further configured to prompt for and receive a selection of whether to automatically perform the EHR query based on the data from the processed barcode after the ultrasound scan.
David further discloses wherein the processing device is further configured to prompt for and receive a selection of whether to automatically perform the EHR query based on the data from the processed barcode after the ultrasound scan (David, Para 0066; “Upon receiving the identifier, the data reader 106 may initiate the data logger 109b to document 404 clinical information, based on the patient identifier in the server 118”. In this arrangement, once “clinical information” is acquired, its documentation is initiated, without automatic EHR query. David, Para 0067; “In some implementations, the data reader 106 may communicate with and access the centralized server 118 via the network 112. The centralized server 118, as described in FIG. 2, may process real-time measurement data 202 and continuously consolidate such information with the comprehensive patient record (e.g., patient record 120) in a proper format.” In this arrangement, “measurement data” is first acquired, followed by automatic EHR query to achieve real-time processing or documentation. To one of ordinary skill in the field, whether to automatically perform EHR query after data acquisition can be presented to the user as an option). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Rothberg, Bao, Weiner and David, as further suggested by David, in order to provide the selective option of automatically performing EHR querying after data acquisition. One of ordinary skill in the art would have been motivated to make the modification for the benefit of providing more flexibility on whether to perform EHR query automatically for different situations or needs (David, Para 0066; “when a patient is being transferred to an operating room, the physicians may only need to check pertinent drug consumption history from patient barcode label 104 for diagnostic purposes.”)(David, Para 0067; “… continuously consolidate such information with the comprehensive patient record (e.g., patient record 120) in a proper format”).
With regard to Claim 12, Rothberg, Bao, Weiner and David disclose all the limitations of Claim 11 as discussed above. According to Claim 1, the barcode settings are configured by the processing device, so Rothberg, Bao, Weiner and David disclose wherein the barcode settings further comprise whether to automatically perform the EHR query based on the data from the processed barcode after the ultrasound scan (see the discussion above with Claim 11).
With regard to Claim 13, Rothberg, Bao and Weiner disclose all the limitations of Claim 1 as discussed above, but do not clearly and explicitly disclose wherein the barcode settings are associated with a particular department, and the mobile device is further configured, when downloading the barcode settings from the cloud, to check whether new department-specific settings are available from the cloud when running the ultrasound application under an account linked to the particular department.
David in the same field of endeavor discloses wherein the barcode settings are associated with a particular department (David, Para 0046; “… information recorded on the patient barcode label 104 may be determined based upon the nature of the patient's disease and/or requests made by certain departments or physicians.”), and the mobile device is further configured, when downloading the barcode settings from the cloud, to check whether new department-specific settings are available from the cloud when running the ultrasound application under an account linked to the particular department (David, Para 0058; “The server 118 may maintain and update rules in both of the rules manager software 206 and 208 … Outdated rules may be purged out of the server 118 periodically by administrative departments or authorized parties.”). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Rothberg, Bao and Weiner, as suggested by David, in order to customize barcode setting for a department and update the setting when new setting is available. One of ordinary skill in the art would have been motivated to make the modification for the benefit of providing customized healthcare service based on a patient’s disease and ensuring the service procedure being updated to be efficient and/or reliable (David, Para 0058; “… new drug related information and patient information/data from various sources, such as new research findings or new regulations from appropriate governmental agencies.”).
With regard to Claim 15, Rothberg, Bao and Weiner disclose all the limitations of Claim 1 as discussed above, but do not clearly and explicitly disclose wherein the mobile device is configured, when performing the EHR query based on the data from the processed barcode, to query the EHR for active encounters associated with a patient ID when the barcode contains the patient ID.
David in the same field of endeavor discloses wherein the mobile device is configured, when performing the EHR query based on the data from the processed barcode, to query the EHR for active encounters (David, Para 0005; “Using the unique patient identifier to retrieve medical information associated with the patient includes accessing the centralized information source with the unique identifier”; Para 0087; “FIG. 17 shows an electronic health record system (EHR) having a barcode 1700c that can be detected by the wearable data reader.”) associated with a patient ID when the barcode contains the patient ID (David, Para 0041; “The initial identifier may also be a unique patient identifier permanently assigned to a given patient to maintain the consistency of the patient records in the hospital. … The patient identifier may be encoded into or be in the form of a barcode 105a or a multiple-digit string 105b as shown in FIG. 1.”). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Rothberg, Bao and Weiner, as suggested by David, in order to query the EHR associated with a patient ID. One of ordinary skill in the art would have been motivated to make the modification for the benefit of timely and automatically updating the patient record in the centralized EHR system (David, Para 0041; “Updates of new information about the patient can be conveniently integrated into the shared information or data on the network 112 using the unique identifier.”).
With regard to Claim 16, Rothberg, Bao and Weiner disclose all the limitations of Claim 1 as discussed above, but do not clearly and explicitly disclose wherein the mobile device is configured, when performing the EHR query based on the data from the processed barcode, to query the EHR for active encounters associated with an encounter ID when the barcode contains the encounter ID.
David in the same field of endeavor discloses wherein the mobile device is configured, when performing the EHR query based on the data from the processed barcode, to query the EHR for active encounters (David, Para 0005; “Using the unique patient identifier to retrieve medical information associated with the patient includes accessing the centralized information source with the unique identifier”; Para 0087; “FIG. 17 shows an electronic health record system (EHR) having a barcode 1700c that can be detected by the wearable data reader.”) associated with an encounter ID when the barcode contains the encounter ID (David, Para 0042; “For the event that a patient has not been previously assigned a patient identifier (e.g., initial, unique identifier), a healthcare practitioner may generate a unique patient identifier (e.g., a barcode 105a or a multiple-digit string 105b, or both)”). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Rothberg, Bao and Weiner, as suggested by David, in order to query the EHR associated with an encounter ID. One of ordinary skill in the art would have been motivated to make the modification for the benefit of timely and automatically updating the patient record in the centralized EHR system (David, Para 0041; “Updates of new information about the patient can be conveniently integrated into the shared information or data on the network 112 using the unique identifier.”).
With regard to Claim 17, Rothberg, Bao and Weiner disclose all the limitations of Claim 1 as discussed above, but do not clearly and explicitly disclose wherein the mobile device is further configured to:
return a list of matching encounters from the EHR query;
prompt for selection of one of the matching encounters; and
associate the ultrasound scan with patient information from the selected encounter.
David in the same field of endeavor discloses wherein the mobile device is further configured to:
return a list of matching encounters from the EHR query (David, Para 0076; “The main screen presents the user with the options to (1) scan a barcode to select a patient, (2) display a list of patients, (3) … A clinician may be able to select an option from the list of options using a voice command or …”);
prompt for selection of one of the matching encounters (David, Para 0079; “FIG. 10 shows a screen 1000 of the graphical user interface of FIG. 8 for confirming the selection of a patient … A clinician can use the presented information to determine whether the correct patient has been selected.”); and
associate the ultrasound scan with patient information from the selected encounter (David, Para 0091; “FIG. 21 shows a screen 2100 of the graphical user interface of FIG. 8 for documenting a medical procedure performed on a patient. … the screen 2100 can be used to select from a list 2102 of medical procedures (e.g., "milestones") to document.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Rothberg, Bao and Weiner, as suggested by David, in order to associate the performed procedure such as ultrasound scan of a patient with one of his or her encounters. One of ordinary skill in the art would have been motivated to make the modification for the benefit of timely and accurately updating medical record of a patient (David, Para 0067; “The centralized server 118, as described in FIG. 2, may process real-time measurement data 202 and continuously consolidate such information with the comprehensive patient record (e.g., patient record 120) in a proper format … As a result, the hospital can provide a timely, reliable, substantially complete and context-relevant information service”).
With regard to Claim 20, Rothberg, Bao and Weiner disclose all the limitations of Claim 1 as discussed above, but do not clearly and explicitly disclose wherein the processing device is further configured to prompt for and receive a selection as to whether the mobile device should automatically start every patient association with barcode scanning.
David in the same field of endeavor discloses wherein the processing device is further configured to prompt for and receive a selection as to whether the mobile device should automatically start every patient association with barcode scanning (David, Para 0074; “In certain embodiments, the first barcode aligned with wearable camera 704 is scanned, and then the scan mode is exited automatically. In some embodiments, the scan mode is initiated by a voice command.” To one of ordinary skill in the field, whether to initiate the scan mode automatically or by a voice command at a convenient time point can be provided to the user as options for selection). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Rothberg, Bao and Weiner, as suggested by David, in order to provide the selective option of automatically start the procedure with barcode scanning. One of ordinary skill in the art would have been motivated to make the modification for the benefit of providing more flexibility on when and how to perform barcode scanning to fit healthcare need.
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Rothberg, Bao, Weiner and David, further in view of Russell et al (US 20200089664 A1; hereafter Russell).
With regard to Claim 10, Rothberg, Bao, Weiner and David disclose all the limitations of Claim 9 as discussed above, but do not clearly and explicitly disclose wherein the processing device is configured to determine that automatic EHR querying should be presented as an option based on querying using Fast Healthcare Interoperability Resources being enabled.
Russell in the same field of endeavor discloses wherein the processing device is configured to determine that automatic EHR querying should be presented as an option based on querying using Fast Healthcare Interoperability Resources being enabled (Russell, Para 0097; “In the clinical domain, one such technology is the Fast Healthcare Interoperability Resources (FHIR) standard, which defines a set of Representational State Transfer (REST) facilities that support the automated query of Electronic Health Record (EHR) systems using domain concepts.”). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Rothberg, Bao, Weiner and David, as suggested by Russell, in order to determine the optional automatic EHR querying based on whether FHIR is enabled. One of ordinary skill in the art would have been motivated to make the modification for the benefit of utilizing the FHIR standard to facilitate automatic EHR querying.
Claim 19 is rejected under 35 U.S.C. 103 as being unpatentable over Rothberg, Bao and Weiner, further in view of David and Ninomiya.
With regard to Claim 19, Rothberg, Bao and Weiner disclose all the limitations of Claim 1 as discussed above, but do not clearly and explicitly disclose wherein the processing device is further configured to prompt for and receive a selection as to whether the mobile device should automatically associate the ultrasound scan with patient information if there is only one matching encounter from the EHR query.
Ninomiya and David in the same field of endeavor disclose wherein the processing device is further configured to prompt for and receive a selection as to whether the mobile device should automatically associate the ultrasound scan with patient information if there is only one matching encounter from the EHR query (Ninomiya, Para 0032; “once the image capturing apparatus 200 recognizes the patient number from a barcode of a patient, the image capturing apparatus 200 may automatically associate image data of an affected area of the patient obtained thereafter with the corresponding patient number of the patient.” In this disclosure, the association is automatic.) (David, Para 0079; “A clinician can use the presented information to determine whether the correct patient has been selected.” In this disclosure, a clinician needs to confirm whether the association should be done. To one of ordinary skill in the field, whether to automatically associate data and patient information can be provided to the user as options for selection). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Rothberg, Bao and Weiner, as suggested by Ninomiya and David, in order to provide an option of whether data and patient information should be associated automatically. One of ordinary skill in the art would have been motivated to make the modification for the benefit of enabling the technique to be applicable in situations that require efficiency (Ninomiya, Para 0038; “… the burden on the medical personnel may be reduced …”) and in other situations where accuracy is highly required (David, Para 0072; “This confirmation [by clinician or user] may prevent the user from inadvertently viewing or modifying medical information in the file of another patient.”).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure. Cumbie (US 20150213203 A1) discloses processing barcode data based on patient identification number embedded in the data.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LEI ZHANG whose telephone number is (571)272-7172. The examiner can normally be reached Monday-Friday 8am-5pm E.T..
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, Pascal Bui-Pho can be reached at (571) 272-2714. 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.
/L.Z./Examiner, Art Unit 3798
/PASCAL M BUI PHO/Supervisory Patent Examiner, Art Unit 3798
Prosecution Insights