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 .
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-4, 9-12, 16, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Barreto (US Pub. No. 2013/0124638) in view of Ding (US Pub. No. 2016/0127199) and “Real-time updates with Turbo Streams” (hereinafter, “Turbo Streams”).
Regarding claim 1, Barreto shows a computer-implemented method comprising:
receiving a first registration request message (the necessary communication which associates a user device with a user and allows the system to determine which devices require updates to items in a workspace: [0049], [0069]-[0071]);
receiving a second registration request message (the necessary communication which associates a second user device with a second user and allows the system to determine which devices require updates to items in a workspace: [0049], [0069]-[0071]);
pairing the first client application with the second client application upon registering the first client device and the second client device with a computing resource (identifying clients as part of a given workspace having associated compute that performs processing on behalf of the workspace: [0084]; see also [0032], [0071]);
receiving, from the first client device in response to an end user interaction with the first client application, an identification of a state of the first client application and a task request message corresponding to a task to be performed by the computing resource (e.g., actions relating to updates to a shared document, actionable tasks, file renames, etc.: [0035], [0046], [0049], [0051], [0060]-[0064]);
synchronizing a state of the second client application with the state of the first client application (see [0084]-[0086]);
determining a context associated with the task request message (the context including at least a workspace and associated collaborators of the workspace: see [0084]-[0086]; see also [0032], [0071]);
routing, based at least in part on the context associated with the task request message, the task request message to a selected task flow of a plurality of task flows associated with the computing resource (by a dispatcher, dispatching actions to appropriate processors associated with collaborators in the workspace: see Fig. 4A, Fig. 5B, [0051], [0055], [0066], [0084]-[0086]);
receiving a response message from the computing resource, the response message generated by the computing resource in response to the task being executed by processing steps of the task by the selected task flow, the response message having a payload content (receiving an output from the processor and placing it a client-type-specific queue for retrieval by clients: see [0055]-[0057]); and
providing the response message to one or both of the first client device and the second client device, wherein providing the response message to one or both of the first client device and the second client device causes the payload content of the response message to be displayed on one or both of a first client device display and a second client device display according to(reading, by the affected client devices, updates from the queue, according to capabilities such as whether the client is a real-time web or a sync client: [0057]).
Barreto does not explicitly show:
that the first and second registration request messages are from a first client application executing on a first client device and from a second client application executing on a second client device; and
that the first and second registration messages include information that identifies the capabilities of the first client device and capabilities of the second client device.
Ding shows:
first and second registration request messages that are from a first client application executing on a first client device and from a second client application executing on a second client device (see [0054]-[0057]; note that Ding provides for multiple such clients as depicted in Fig. 1 and described at [0027] and [0029]); and
that the first and second registration messages include information that identifies capabilities of the first client device and capabilities of the second client device (see [0054]-[0057]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Barreto with the teachings of Ding in order to offload aspects of registration to the client devices and their users, reducing the burden on the server and its administrators.
Barreto in view of Ding does not explicitly show:
the response message having a payload content including a set of configuration parameters that define a layout of the payload content; and
the client device causing the display according to the configuration parameters.
Turbo Streams shows:
a response message having a payload content including a set of configuration parameters that define a layout of the payload content (HTML markup corresponding to real-time content updates: see pp. 3-4); and
a client device causing display according to the configuration parameters (by rendering the received HTML in real time: see p. 6-7).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the system of Barreto with the teachings of Turbo Streams in order to reduce development cost by using pre-existing standards-based mechanisms to communicate state updates.
Regarding claim 2, the combination shows the limitations of claim 1 as applied above and further shows wherein the payload content of the response message is simultaneously displayed on the first client device display and the second client device display, and a change in the state of the first client application or the second application resulting from an interaction of the end user with the payload content is also applied to the other of the first application and the second application (see Turbo Streams, “What we will build in this chapter” on p. 2 and “Testing turbo streams with two browser windows” on p. 8, as combined above).
Regarding claim 3, the combination shows the limitations of claim 1 as applied above and further shows wherein the first client device and the second client device each subscribe to receive notifications from the computing resource, and the computing resource publishes a notification to the first client device and the second client device (see Turbo Streams, discussion of real-time updates at bottom of p. 1, and discussion of subscription and broadcast on p. 4, as combined above) any time a client device is registered with or unregistered from the computing resource (see Barreto, [0049], describing updates on “any other types of activities detected in the work space”).
Regarding claim 4, the combination shows the limitations of claim 1 as applied above and further shows wherein the first client device is a handheld mobile computing device, the first client application is a mobile client application, the second client device is a desktop computing device, and the second client application is a desktop client application (see Barreto, [0028], [0035], [0056]).
Claim 9 corresponds to claim 1 and is rejected for the reasons given above, mutatis mutandis.
Regarding claim 10, the combination shows the limitations of claim 9 as applied above and further shows wherein each of the first client application and the second client application supports one or more of touch, text, and voice interactions with the end user (e.g., at least text: see Turbo Streams, “HTML of the created quote”, pp. 2-3, as combined above).
Regarding claim 11, the combination shows the limitations of claim 9 as applied above and further shows wherein: the computing resource includes a unified events channel; the first registration request message and the second registration request message are each configured to subscribe the first client device and the second client device to the unified events channel upon registration of the first client device and the second client device with the computing resource (see Turbo Streams, discussion of real-time updates at bottom of p. 1, and discussion of subscription and broadcast on p. 4, as combined above); and the unified events channel is configured to publish a notification to the first client device and the second client device any time a client device is registered with or unregistered from the unified events channel (see Barreto, [0049], describing updates on “any other types of activities detected in the work space”).
Claim 12 corresponds to claim 4 and is rejected for the reasons given above, mutatis mutandis.
Claims 16 and 17 correspond to claims 1 and 4 and are rejected for the reasons given above, mutatis mutandis.
Claims 5-8, 13-15, and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Barreto (US Pub. No. 2013/0124638) in view of Ding (US Pub. No. 2016/0127199) and Turbo Streams, and further in view of Niehaus (US Pub. No. 2023/0386626).
Regarding claim 5, the combination shows the limitations of claim 4 as applied above but does not explicitly show wherein the first registration request message received from the mobile computing device is generated in response to scanning, with a camera of the mobile computing device, a barcode or a quick response code displayed on the display of the desktop computing device.
Niehaus shows wherein the first registration request message received from the mobile computing device is generated in response to scanning, with a camera of the mobile computing device, a barcode or a quick response code displayed on the display of the desktop computing device (see [0056] and Fig. 2A, “Scan QR Code from Computer”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the system of Barreto with the teachings of Niehaus in order to reduce the amount of labor required to produce structured medical notes that conducive to later analysis (see Niehaus, [0037]).
Regarding claim 6, the combination shows the limitations of claim 4 as applied above but does not explicitly show wherein: the end user interaction with the mobile client application initiates a dictation operation during which speech of the end user is captured by a microphone of the mobile computing device; the selected task flow receives the speech and transcribes the speech into text; and the text is included in the payload content of the response message.
Niehaus shows wherein: the end user interaction with the mobile client application initiates a dictation operation during which speech of the end user is captured by a microphone of the mobile computing device; the selected task flow receives the speech and transcribes the speech into text; and the text is included in the payload content of the response message (see [0041], “automatic speech recognition (ASR) engine”, [0055], describing viewing medical notes based on audio transcripts).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the system of Barreto with the teachings of Niehaus in order to reduce the amount of labor required to produce structured medical notes that conducive to later analysis (see Niehaus, [0037]).
Regarding claim 7, the combination shows the limitations of claim 4 as applied above but does not explicitly show wherein: the end user interaction with the mobile client application includes a natural language utterance requesting medical information for a patient; the selected task flow is associated with a generative artificial intelligence model that receives the natural language utterance, interprets the natural language utterance using one or more natural language processing techniques, and resultantly causes the selected task flow to retrieve the medical information; the response message is generated by the generative artificial intelligence model; and the medical information is included in the payload content of the response message.
Niehaus shows wherein: the end user interaction with the mobile client application includes a natural language utterance requesting medical information for a patient; the selected task flow is associated with a generative artificial intelligence model that receives the natural language utterance, interprets the natural language utterance using one or more natural language processing techniques, and resultantly causes the selected task flow to retrieve the medical information; the response message is generated by the generative artificial intelligence model; and the medical information is included in the payload content of the response message (see [0078], describing using an LLM to identify natural language medical information in input data such as “back pain”, and Fig. 2D, showing requests for medical information such as “What brings you here today?” and “I have a [sic] back pain”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the system of Barreto with the teachings of Niehaus in order to reduce the amount of labor required to produce structured medical notes that conducive to later analysis (see Niehaus, [0037]).
Regarding claim 8, the combination shows the limitations of claim 4 as applied above but does not explicitly show wherein: the end user interaction with the mobile client application initiates an ambient recording operation during which the selected task flow of the computing resource is caused to listen to a conversation between the end user and a medical patient using a microphone of the mobile computing device; the selected task flow generates a medical note based on the conversation; and the medical note is included in the payload content of the response message.
Niehaus shows wherein: the end user interaction with the mobile client application initiates an ambient recording operation during which the selected task flow of the computing resource is caused to listen to a conversation between the end user and a medical patient using a microphone of the mobile computing device; the selected task flow generates a medical note based on the conversation; and the medical note is included in the payload content of the response message (see [0078], describing using an LLM to identify natural language medical information in input data such as “back pain”, and Fig. 2D, showing requests for medical information such as “What brings you here today?” and “I have a [sic] back pain”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the system of Barreto with the teachings of Niehaus in order to reduce the amount of labor required to produce structured medical notes that conducive to later analysis (see Niehaus, [0037]).
Claims 13-15 and 18-20 correspond to claims 6-8 and are rejected for the reasons given above, mutatis mutandis.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Note the following documents in particular:
US Pub. No. 2024/0296946 to Thomas describes a system for multi-platform telemedicine.
US Pub. No. 2018/0181712 to Ensey describes a system which divides a patient care workflow into phases.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Christopher D. Biagini whose telephone number is (571)272-9743. The examiner can normally be reached weekdays from 9 AM - 5 PM.
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, Oscar Louie can be reached at (571) 270-1684. 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 D. Biagini
Primary Examiner
Art Unit 2445
/Christopher Biagini/Primary Examiner, Art Unit 2445