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 Application
This action is in reply to the reply filed November 13, 2025 (hereinafter “Reply”).
Claims 1, 5, and 9 are amended.
Claim 13 is new.
Claims 1-13 are pending.
Claim Rejections - 35 U.S.C. § 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 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-13 are rejected under AIA 35 U.S.C. § 103 as being unpatentable over Kharraz Tavakol et al. (U.S. Pub. No. 2021/0304141 A1) (hereinafter “Kharraz”) in view of Chock et al. (U.S. Pub. No. 2021/0398668 A1) (hereinafter “Chock”) and further in view of Yu et al. (U.S. Pub. No. 2014/0019149 A1) (hereinafter “Yu”).
Claims 1, 5, and 9: Kharraz, as shown, discloses the following limitations:
determining, at a provider gateway system, that a particular provider is authorized for one or more digital communication sessions, wherein the particular provider is represented in the provider gateway system by a digital identifier (see at least ¶ [0270]: FIG. 17 illustrates one example of a database structure for use in one or more embodiments of the method and apparatus of the invention. An aggregator database uses various stored tables of doctor, appointment, and user data for implementing the booking of a referral appointment. As shown, the doctor information table 220 may include a unique physician identifier (ID), physician name, specialty and sub-specialty identifiers, photo and physician statement information. An appointment table 221 may include a unique appointment identifier, practice identifier, physician identifier, location identifier, procedure identifier, start and end time for the procedure, a user identifier and duration. A user table 222 may include a unique user identifier, name, user key, gender and date of birth. This use of a relational database is meant to be illustrative of just one possible embodiment and not limiting; see also at least ¶¶ [0215]-[0234], which discloses various medical professionals logging into the software);
responsive to determining authorization, rendering, in a provider graphical user interface for that digital identifier, a control, selection of which transmits a request to register the particular provider with a queue processing system (see at least ¶ [0116]: the method further comprises the step of registering the referring physician to allow access to the portal; see also at least ¶ [0117]: access to the portal is limited to referring physicians previously registered with the portal; see also at least ¶ [0169]: a notification is then sent electronically to both the patient and the receiving (referred-to) practice. The patient’s data now becomes accessible to the receiving practice, offering the opportunity to send reminders and arrange for the appointment at a later time);
receiving, by the provider gateway system through the provider graphical user interface, selection data specifying selection of the control, with the selection data specifying the digital identifier (see at least ¶ [0170]: via the “Find Doctor” function (described below), a doctor or practice manager can input a patient's desired procedure, location, insurance provider and plan. These parameters serve to filter the view of the database provided to the referring party, and thus create a view of available appointments; see also at least ¶ [0172]: FIG. 3 is an example of a webpage 20 from an aggregator’s website which enables a referring physician to filter profile data stored in the aggregator’s central managed database for selecting an acceptable physician for the referral appointment; see also at least ¶ [0197]: FIG. 8 shows a web page 130 on the aggregator’s website that enables the referring physician to track referral appointments. The page, entitled “Booking History”, includes a number of filtering windows in an upper portion 131, enabling the referring physician to filter based on selected criteria and generate a booking history report; see also at least ¶ [0189]: a “Suggested Action” indicator provides the doctor or his staff with one-click access to a patient's contact information, further simplifying the process of following up on referrals. A referring practice is thus also informed immediately and automatically of a missed referral appointment; see also at least ¶ [0153]); and
responsive to receipt of the selection data, automatically:
retrieving, from a hardware storage device, one or more data records associated with the digital identifier (see at least ¶ [0148]: the network of FIG. 1 allows communications between a centralized service provider (aggregator), multiple healthcare practitioner practice groups, multiple hospitals, multiple insurers, and multiple patients. The aggregator's server provides a network based service to the practitioner groups, hospitals, insurers, and patients, e.g. an aggregator's server 4 a provides a web-based data processing service and interface to each of the physician or patient computers 5 a, practice group servers 4 b, hospital servers 4 c, and insurance provider servers 4 d, and can also communicate electronically via email with each of these computers and servers. The aggregator’s server also communicates (e.g. web-based) with each of the practice groups, hospitals and insurers via their respective servers for retrieving data such as available appointment times and other information for each of the practice groups, hospitals and insurers in order to enable online booking and confirmation of appointments on multiple websites. In alternative embodiments, the aggregator's service is provided to one or more practice groups, one or more hospitals, and/or one or more insurance provider(s). For ease of description, a first embodiment will refer to practice groups, it being understood that the services can similarly be provided to other healthcare provider groups; see also at least ¶¶ [0170], [0172], [0189], and [0197]);
based on the retrieved one or more data records, instructing the queue processing system to register the particular provider with the queue processing system by:
transmitting to the queue processing system the digital identifier and an indication that the particular provider represented by the digital identifier is authorized for the one or more digital communication sessions, wherein the queue processing system maintains queues with entries representing users requesting digital communication sessions (see at least ¶ [0170]: via the “Find Doctor” function (described below), a doctor or practice manager can input a patient's desired procedure, location, insurance provider and plan. These parameters serve to filter the view of the database provided to the referring party, and thus create a view of available appointments; see also at least ¶ [0172]: FIG. 3 is an example of a webpage 20 from an aggregator’s website which enables a referring physician to filter profile data stored in the aggregator’s central managed database for selecting an acceptable physician for the referral appointment; see also at least ¶ [0197]: FIG. 8 shows a web page 130 on the aggregator’s website that enables the referring physician to track referral appointments. The page, entitled “Booking History”, includes a number of filtering windows in an upper portion 131, enabling the referring physician to filter based on selected criteria and generate a booking history report; see also at least ¶ [0189]: a “Suggested Action” indicator provides the doctor or his staff with one-click access to a patient's contact information, further simplifying the process of following up on referrals. A referring practice is thus also informed immediately and automatically of a missed referral appointment; see also at least ¶ [0156]: the database maintained by the aggregator may include records of practitioner profile information and booking information for the practice groups and their respective practitioners, the hospitals and their affiliated practitioners, the insurance providers and their participating practitioners, and each patient who establishes an account with the aggregator. These records will be described further below in various embodiments; see also at least ¶ [0208]: emergency room staff working with the Referral Cockpit can identify low-priority cases, and access a real-time view of available primary care providers in the vicinity. This helps decrease waiting times, provides patients with faster access to care, and allows physicians and medical staff to concentrate their efforts on those patients in the greatest need of true emergency care. Furthermore, the Referral Cockpit can be used to steer patients to providers within the same provider network as the emergency facility.);
receiving, from the queue processing system, an indication of a user of the particular users for a digital communication session with the particular provider, with the indication of the user specifying another digital identifier, the user being selected from a queue for which the particular provider is eligible to provide consultations based on the one or more characteristics (see at least ¶ [0060]: the referring physician establishing communication via the portal with one or more of the patient and the selected physician; see also at least ¶ [0020]: systems and methods are provided for reviewing a patient's progress after a referral appointment, by facilitating communications about the patient between the referring physician and the referred-to physician; see also at least ¶ [0021]: systems and method are provided for reviewing and reporting the results of one or more appointment referrals, enabling the referring physician to analyze the patient experience and/or quality of patient care, physician communication and history of (e.g., willingness and ability to accept) referral appointments by the referred-to physician; see also at least ¶ [0165]: in cases where primary care physicians and specialists work in integrated facilities and/or share administrative staff, the same staff member may process both the referral and its receipt. However, even if this were the case, there would still be authentication required on both ends of the referral process, meaning that there would still be effectively two users (one representing the referring physician, one the receiving specialist) involved, even if there was only one actual person responsible; see also at least ¶¶ [0173] and [0176]);
registering the user with the provider gateway system by storing, in a hardware storage device, a data structure representing the user, with the data structure structured with data specifying the digital identifier of the user (see at least ¶ [0183]: personal patient contact and insurance plan data are stored on the aggregator’s central database, and made available to pass on to a referred-to doctor. Patients’ records are matched on the basis of their email address or phone number registered with the aggregator. This information can be transmitted automatically in conjunction with the appointment request; see also at least ¶¶ [0019] and [0197]).
Kharraz does not explicitly disclose, but Chock, as shown, teaches the following limitations:
by the provider gateway system, rendering another provider graphical user interface for the digital identifier of the provider that displays a visual representation of a console and a visual representation of the user within the console (see at least ¶ [0004]: systems and methods that provide live telehealth sessions. In one embodiment, a patient can use a general computing device interface, and with a click of a button or touch of screen, initiate communication (e.g., a real-time video conference) with a medical service provider (such as a physician) to obtain the needed health service; see at least ¶ [0007]: The HP-side application is configured to display a first graphical trigger on a display of the HP-side device that when selected causes the HP-side device to send a connection request to communicatively connect with the patient over the telehealth session; see also at least ¶ [0008]: the telehealth application is configured to receive, from the HP-side device, the connection request to communicatively connect with the patient. And, in response to receiving the connection request from the HP-side device, the telehealth application is configured to determine a contact information of the patient-side device; and send instructions to the patient-side device based on the contact information of the patient-side device; see also at least ¶ [0009]: the patient-side application is configured to display a second graphical trigger on a display of the patient-side device in response to receiving the instructions from the telehealth application. The second graphical trigger, when selected, causes the patient-side application of the patient-side device to communicatively connect with the HP-side application of the HP-side device to establish the telehealth session. The HP-side application is further configured to: generate one or more graphical user interfaces (GUIs) that display patient-related data on the display of the first device during the telehealth session; enable the healthcare provider to edit, using the one or more GUIs, one or more portions of the patient-related data during the telehealth session; and send the one or more edited portions to the telehealth application; see also at least ¶ [0050]).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to combine the telehealth session management techniques taught by Chock with the physician referral management systems disclosed by Kharraz, because Chock teaches at ¶ [0052] that the healthcare provider “has full control of what patient 152 can see and there can better drive and control the telehealth session.” See M.P.E.P. § 2143(I)(G).
Moreover, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to combine the telehealth session management techniques taught by Chock with the physician referral management systems disclosed by Kharraz, because the claimed invention is merely a combination of old elements (the telehealth session management techniques taught by Chock and the physician referral management systems disclosed by Kharraz), in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. See M.P.E.P. § 2143(I)(A).
Kharraz does not explicitly disclose, Chock does not explicitly teach, but Yu, as shown, teaches the following limitations:
the request being associated with one or more characteristics of the provider, wherein registering the provider includes assigning the particular provider to one or more queues with entries representing particular users for which the particular provider is eligible to provide consultations based on the one or more characteristics (see at least ¶ [0010]: a patient arriving at a node is inspected by a trained technician/general practitioner who identifies the urgency and the specialty of medical service provider the patient must meet. The technician queues the patient. The technician may identify a specialty or a particular specialist; see also at least ¶ [0112]: the scheduler 209 generates multiple lists of patients waiting for medical consultation based on the ailment associated with the patient. For example, the scheduler 209 generates a first list of patients waiting to consult with a first medical service provider associated with a first specialty and generates a second list of patients waiting to consult with a second medical service provider associated with a second specialty; see also at least ¶ [0117]: the scheduler 209 uses a POST message to add an authorized patient to a queue that includes a list of patients waiting for medical consultation and uses a DELETE message to remove an authorized patient from the queue. In another example, once a medical service provider accepting a selected patient, the scheduler 209 uses GET messages to allow the medical service provider at the hub 111 and the selected patient at the node 109 to exchange each other's information; see also at least ¶ [0115]: the scheduler 209 selects a patient for remote, virtual consultation by a medical service provider from the list based on the ailment associated with the patient matching the specialty of the available medical service provider. For example, assume the patient is complaining of knee pain, the scheduler 209 does not select the patient if the available medical service provider is a dermatologist, but may select the patient if the available medical service provider is an orthopedist because an orthopedist may address knee pain; see also at least ¶ [0116]);
each queue associated with data representing one or more characteristics of providers eligible to provide consultations for the users requesting the digital communication sessions, the particular provider being assigned to one or more of the queues with the entries representing the particular users for which the particular provider is eligible to provide consultations based on the one or more characteristics (see at least ¶¶ [0010], [0112], and [0115]-[0117] and the analysis above);
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to combine the telehealth session management techniques taught by Yu with the physician referral management systems disclosed by Kharraz (as modified by Chock), because Yu teaches at ¶ [0069] that “By allowing remote consultation of a patient at a node by a medical service provider at a hub, the medical service provider is more effectively used and patients may receive higher quality medical care” and “may increase usage of a medical service provider and increase the quality of medical care a patient receives.” See M.P.E.P. § 2143(I)(G).
Moreover, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to combine the telehealth session management techniques taught by Yu with the physician referral management systems disclosed by Kharraz (as modified by Chock), because the claimed invention is merely a combination of old elements (the telehealth session management techniques taught by Chock and Yu and the physician referral management systems disclosed by Kharraz), in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. See M.P.E.P. § 2143(I)(A).
Claims 2, 6, and 10: The combination of Kharraz, Chock, and Yu teaches the limitations as shown in the rejections above. Further, Kharraz, as shown, discloses the following limitations:
wherein retrieving the one or more data records associated with the digital identifier comprises accessing a computing system associated with the digital identifier, the computing system hosting the one or more data records through an application interface that is different from another application interface associated with one or more other data records associated with a different computing system associated with another digital identifier (see at least ¶ [0148]: the network of FIG. 1 allows communications between a centralized service provider (aggregator), multiple healthcare practitioner practice groups, multiple hospitals, multiple insurers, and multiple patients. The aggregator's server provides a network based service to the practitioner groups, hospitals, insurers, and patients, e.g. an aggregator's server 4 a provides a web-based data processing service and interface to each of the physician or patient computers 5 a, practice group servers 4 b, hospital servers 4 c, and insurance provider servers 4 d, and can also communicate electronically via email with each of these computers and servers. The aggregator's server also communicates (e.g. web-based) with each of the practice groups, hospitals and insurers via their respective servers for retrieving data such as available appointment times and other information for each of the practice groups, hospitals and insurers in order to enable online booking and confirmation of appointments on multiple websites. In alternative embodiments, the aggregator's service is provided to one or more practice groups, one or more hospitals, and/or one or more insurance provider(s). For ease of description, a first embodiment will refer to practice groups, it being understood that the services can similarly be provided to other healthcare provider groups; see also at least ¶ [0147]).
Claims 3, 7, and 11: The combination of Kharraz, Chock, and Yu teaches the limitations as shown in the rejections above. Further, Kharraz, as shown, discloses the following limitations:
wherein retrieving the one or more data records associated with the digital identifier comprises accessing authorization data associated with the digital identifier (see at least ¶ [0270]: FIG. 17 illustrates one example of a database structure for use in one or more embodiments of the method and apparatus of the invention. An aggregator database uses various stored tables of doctor, appointment, and user data for implementing the booking of a referral appointment. As shown, the doctor information table 220 may include a unique physician identifier (ID), physician name, specialty and sub-specialty identifiers, photo and physician statement information. An appointment table 221 may include a unique appointment identifier, practice identifier, physician identifier, location identifier, procedure identifier, start and end time for the procedure, a user identifier and duration. A user table 222 may include a unique user identifier, name, user key, gender and date of birth. This use of a relational database is meant to be illustrative of just one possible embodiment and not limiting; see also at least ¶¶ [0215]-[0234], which discloses various medical professionals logging into the software; see also at least ¶¶ [0116]-[0117] and [0169]); and
accessing, using the authorization data, a computing system hosting the one or more data records (see at least ¶ [0148]: the network of FIG. 1 allows communications between a centralized service provider (aggregator), multiple healthcare practitioner practice groups, multiple hospitals, multiple insurers, and multiple patients. The aggregator's server provides a network based service to the practitioner groups, hospitals, insurers, and patients, e.g. an aggregator's server 4 a provides a web-based data processing service and interface to each of the physician or patient computers 5 a, practice group servers 4 b, hospital servers 4 c, and insurance provider servers 4 d, and can also communicate electronically via email with each of these computers and servers. The aggregator's server also communicates (e.g. web-based) with each of the practice groups, hospitals and insurers via their respective servers for retrieving data such as available appointment times and other information for each of the practice groups, hospitals and insurers in order to enable online booking and confirmation of appointments on multiple websites. In alternative embodiments, the aggregator's service is provided to one or more practice groups, one or more hospitals, and/or one or more insurance provider(s). For ease of description, a first embodiment will refer to practice groups, it being understood that the services can similarly be provided to other healthcare provider groups; see also at least ¶ [0147]).
Claims 4, 8, and 12: The combination of Kharraz, Chock, and Yu teaches the limitations as shown in the rejections above. Further, Kharraz, as shown, discloses the following limitations:
wherein the queues with entries representing users requesting digital communication sessions are each associated with a particular type of medical service provided by providers associated with the queues (see at least ¶ [0167]: a portal referred to herein as a Referral Cockpit enables a referring (e.g., primary care) provider’s office to initiate a search for and then select among a customized list of doctors based on a desired patient procedure, specialty, accepted insurances, affiliation with provider systems, and/or a number of further criteria (geographic location, gender, etc.). The office can then choose from available time slots in real time, and book a referral appointment online. This makes it far easier to ensure that the patient can see a specialist in close proximity and timely fashion. It also eliminates the possibility that the patient may forego necessary care due to the inconvenience of obtaining an appointment; see also at least ¶¶ [0198]-[0199]).
Claim 13: The combination of Kharraz, Chock, and Yu teaches the limitations as shown in the rejections above. Further, Kharraz, as shown, discloses the following limitations:
wherein a first user of the particular users is associated with a first electronic health record system and wherein a second user of the particular users is associated with a second electronic health record system that is different from the first electronic health record system, and wherein the user that is selected from the queue is the first user or the second user (see at least ¶ [0175]: either the referring physician enters identifying information for the patient in the upper portion 72, to determine if the patient is previously included in the aggregator database, or else the referring physician creates a record for a new patient not previously existing in the database, in the lower portion 79. Assuming the patient already exists in the database, in this example he can be located either by entering his email address in window 73 and clicking the search button 74, or alternatively entering his phone number in window 75 and his last name in window 76 and clicking the search button 77. If no patient is found with the specified email, the referring physician will be so notified at 78; see also at least ¶ [0180]: over the course of a multi-doctor treatment process, a patient's medical records must often be transferred between several offices; see also at least ¶ [0182]: allows different practice groups to easily make patient information available to one another. Furthermore, a referring doctor can track a patient's progress after treatment by a specialist, eliminating uncertainty and allowing for more effective treatment at their next meeting; see also at least ¶ [0205]).
Response to Arguments
The arguments submitted with the Reply have been fully considered but are moot in view of the new grounds of rejection.
Conclusion
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.
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure. The following references have been cited to further show the state of the art with respect to healthcare resource provisioning and management.
Cordell et al. (U.S. Pub. No. 2021/0335502 A1) (multi-modality electronic invite routing system and process for telehealth language interpretation session); and
Kearly et al. (“Telehealth: An Opportunity for State and Territorial Health Agencies to Improve Access to Needed Health Services.” Journal of Public Health Management and Practice 26(1):p 86-90, January/February 2020).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Christopher Tokarczyk, whose telephone number is 571-272-9594. The examiner can normally be reached Monday-Thursday between 6:00 AM and 4:00 PM Eastern.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Mamon Obeid, can be reached at 571-270-1813. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/CHRISTOPHER B TOKARCZYK/ Primary Examiner, Art Unit 3687