DETAILED ACTION
Acknowledgement
This final office action is in response to the amendment filed on 11/24/2025.
Status of Claims
Claims 5 and 13 have been cancelled.
Claims 1, 6-9, 11-12, and 18 have been amended.
Claims 1-4, 6-12, and 14-20 are now pending.
Response to Arguments
The 112f claim interpretation is withdrawn in light of claim 12 and 13 amendments.
The 35 U.S.C. 112(a) and 112(b) rejection of claims 12 and 13 are withdrawn in light of amendments.
The 35 U.S.C. 112(b) rejection of claims 14 and 18 are withdrawn in light of amendments to claim 12.
Applicant's arguments filed on 11/24/2025 regarding the 35 U.S.C. 101 and 103 rejections of the claims have been fully considered. The Applicant argues the following.
(1) As per the 101 rejection, the Applicant argues, in summary, that (i) claim 1 does not describe an abstract idea. At least the step of adding the new records to a landing table based on a time-based partitioning scheme is not an abstract idea, nor could it be done by pen and paper. It is a technical step rooted in computer database processing; (ii) even if claim 1 is considered to cover an abstract idea such as a mental process, which Applicant submits that the claims is integrated into a practical application that improves the functioning of computers, and thus patent eligible. The limitations change how the computer stores and processes data, resulting in faster processing, improved responsiveness, and reduced resource usage--a technical improvement in database operation as reflected in paragraph [0051]; (iii) With reference to amended claim 1, it recites a specific and non-conventional combination of technical components and operations that, when considered as an ordered combination, amount to an inventive concept. The claim does not merely apply generic computer function; instead, it recites a specific, non-conventional combination of technical features.
The Examiner respectfully disagrees with all arguments. As per argument (i), the Examiner submits that amended claim 1 is directed to the abstract grouping of Mental Processes because the claims describe a process of managing membership change events via receiving, preprocessing, and storing membership change event records in order to compute at least one metric. Receiving new records in chronological order, adding records in a table format, preprocessing new and historic records to create a normalized data table, chronologically arranging all records, determining invalid records, creating a condensed table of normalized records by filtering out the invalid records, comparing data tables for differences, updating the normalized data table, and computing at least one metric (e.g. size, population, revenue, etc.) based on the normalized data table can practically be performed mentally with pen and paper. Mental Processes include claims directed to collecting information, analyzing it, and displaying certain results of the collection and analysis even if they are claimed as being performed on a computer. Per MPEP 2106.04(a), a claim recites a judicial exception when the judicial exception is “set forth” or “described” in the claim.
As per arguments (ii) and (iii), the Examiner submits that the additional elements recited in the claims and listed in Steps 2A(2) and 2B do not integrate the abstract idea into a practical application nor provide significantly more (i.e. an inventive concept). The Applicant’s arguments for technological improvements and an inventive concept are based on “abstract elements” and not “additional elements”, such as “a time-based partitioning scheme…; chronologically arranges historic and new records…; difference-based updating of a normalized table to avoid recomputation”. The Examiner finds that the improvements (e.g. faster processing, improved responsiveness, and reduced resource usage) are based on the organization of data (e.g. chronologically) and/or cleaning/filtering of data (e.g. removing invalid data). Organizing data chronologically or temporally is considered abstract. The improvement is not due to any particular technological or structural component (i.e. additional element). The change and/or improvement is in the data and not in the technology itself (e.g. database). Per MPEP 2106.05, the abstract elements cannot furnish the improvement and/or inventive concept. It must be furnished by the additional elements recited in the claims. Any steps of organizing, arranging, comparing, or updating data is considered abstract. An improvement in the judicial exception itself is not an improvement in technology. Therefore, the 35 U.S.C. 101 rejection is maintained.
(2) As per the 103 rejections, the Applicant argues, that (i) claim 1 is not unpatentable over Schlaper in view MacIntyre. A fundamental difference between Schlapfer and the invention as recited in claim 1 is the use of historical records. Where Schlapfer replaces out-of-date records with current records to maintain a current state (of, e.g. the care team assignment), claim 1 explicitly recites maintaining "and" regular use of historical records; (ii) Schlapfer refers to "normalization operations". In contrast claim 1 recites a normalizer for building and regularly updating a normalized table of only valid records of membership change events including records of old and new timestamps; and (iii) MacIntyre nor Landa do not make up for the deficiencies of Schlapfer.
The Examiner respectfully disagrees with all arguments. The Examiner submits that based on the broadest reasonable interpretation of the claims, Schlapfer in view of MacIntyre teach all the limitations of amended claim 1 as shown in the updated responses below. As per argument (i), Schlapfer teaches using previously generated records, previously stored data, and previously received care team assignment (i.e. historical records) to determine a current state and perform syncing operations ([0039], [0071], [0097], etc.). The previously received records can be considered historical/past data.
As per argument (ii), the Examiner submits that the Applicant’s amended claims do not recite “a normalizer”. Therefore, the Examiner considers this argument moot. However, the Examiner points out the Schlapfer explicitly teaches the use of normalizer for example, in paragraph [0052] which states “When a synching application begins executing on the sync server 110, a HL7 server instance may be created for each row in the feed table. Once an HL7 connection is established on a port defined by the feed table, the feed table row may define a transformation (e.g., using normalizers) to convert HL7 message data from the HL7 connection into a location and patient within the synching application.”
As per argument (iii), the Examiner submits that based on the broadest reasonable interpretation of the claims, Schlapfer in view of MacIntyre teach all the limitations of amended claim 1 as shown in the updated responses below. Therefore, the 35 U.S.C. 103 rejections are maintained.
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 .
Information Disclosure Statement
The information disclosure statements (IDSs) submitted on 10/21/2025 and 11/24/2025 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the Examiner.
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.
Claims 1-4, 6-12, and 14-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 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 pre-AIA the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claim 1 recite the limitations of “computing, on the analytics processing database, at least one metric for the collection based on the user selection and the updated normalized data table, thereby avoiding requiring the analytics processing database to organize both the valid and invalid events such that processing time is faster, responsiveness to the user is faster, and less computing resources are required.” The underlined portion of the claim was not found or supported in paragraphs [0011], [0032], [0051], [0076], and [0117] as referenced by the Applicant nor in the entirety of the Applicant’s specification. Therefore, claim 1 contains new matter and is rejected under 35 U.S.C. 112(a). Dependent claims 2-4 and 6-11 are also rejected under 35 U.S.C. 112(a).
Claim 12 recite the limitations of “wherein the database management system is able to compute the at least one metric without being required to organize both the valid and invalid events such that processing time is faster, responsiveness to the user is faster, and less computing resources are required.” These claim limitations were not found or supported in paragraphs [0011], [0032], [0051], [0076], and [0117] as referenced by the Applicant nor in the entirety of the Applicant’s specification. Therefore, claim 12 contains new matter and is rejected under 35 U.S.C. 112(a). Dependent claims 14-20 are also rejected under 35 U.S.C. 112(a).
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-4, 6-12, and 14-20 are rejected under 35 U.S.C. 101 because the claimed invention, “Computer-Implemented Method for Real-Time Group Membership Tracking and Related System”, is directed to an abstract idea, specifically Mental Processes, without significantly more. The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements individually or in combination provide mere instructions to implement the abstract idea on a computer.
Step 1: Claims 1-4, 6-12, and 14-20 are directed to a statutory category, namely a process (claims 1-4 and 6-11) and a machine (claims 12 and 14-20).
Step 2A (1): Independent claims 1 and 12 are directed to an abstract idea of Mental Processes, based on the following claim limitations: “receiving, in any chronological order, the new records for membership change events, wherein the new records have varying time stamps ranging from old time stamps to current time stamps; addition the new records to a…table according to a time-based partitioning scheme compatible with a database protocol for grouping new records by profile ID and Segment ID, wherein the time-based partitioning scheme enables quick and efficient record ingestion by updating only a relatively small number of files versus over the whole dataset for where the data should be written; preprocessing,…, the new records and historic records to create a normalized data table, wherein the preprocessing comprises: reading, from a historic table, all historic records for the memberships present in new records; chronologically arranging the historic records and new records together per group; determining... invalid records, in each group, as (i) each removed change event that is not preceded by an added change event; and (ii) each added change event if preceded by an unclosed added change event; creating a new condensed table of normalized records by filtering out the invalid records from the …table; comparing the new condensed table to a previous normalized data table for differences; updating the previous normalized data table to form the normalized data table based on the differences from the comparing step; sending the updated normalized data table …; receiving a user selection…; and computing, …, at least one metric for the collection based on the user selection and the updated normalized data table; thereby avoiding requiring… to organize both the valid and invalid events such that processing time is faster, responsiveness to the user is faster, and less computing resources are required.” (claim 1) and “…new membership change events are received and recorded to a raw event table according to a time-based partitioning scheme compatible with a database protocol for grouping new records by profile ID and Segment ID, wherein the time-based partitioning scheme enables quick and efficient record ingestion by updating only a relatively small number of files versus over the whole dataset for where the data should be written; …the new membership change events and existing membership change events are saved in a historical event table; read, from the historical event table, all historic records for the memberships present in new records; chronologically arrange the historic records and new records together per group; determine invalid records in each group as:(i) each removed change event that is not preceded by an added change event; and(ii) each added change event if preceded by an unclosed added change event; create a condensed event table by filtering out invalid membership change events from the historical event table; compare the condensed event table to a previous normalized event table for differences; and update the previous normalized event table based on the differences from the comparing step; …recording the updated normalized event table; and …compute at least one metric based on the normalized event table …;… able to compute the at least one metric without being required to organize both the valid and invalid events such that processing time is faster, responsiveness to the user is faster, and less computing resources are required.” (claim 12). These claims describe a process of managing membership change events via receiving, preprocessing, and storing membership change event records in order to compute at least one metric. Dependent claims 2-4, 6-11 and 14-20 further describe the change events, preprocessing of records, and the computation of metrics. Receiving new records in chronological order, adding records in a table format, preprocessing new and historic records to create a normalized data table, chronologically arranging all records, determining invalid records, creating a condensed table of normalized records by filtering out the invalid records, comparing data tables for differences, updating the normalized data table, and computing at least one metric (e.g. size, population, revenue, etc.) based on the normalized data table can practically be performed mentally with pen and paper. Therefore, these limitations, under the broadest reasonable interpretation, fall within the abstract groupings of Mental Processes which include concepts performed in the human mind such as observations, evaluations, judgments, and opinions. Mental Processes include claims directed to collecting information, analyzing it, and displaying certain results of the collection and analysis even if they are claimed as being performed on a computer. The courts have found claims requiring a generic computer or nominally reciting a generic computer may still recite a mental process even though the claim limitations are not performed entirely in the human mind. Therefore, claims 1-4, 6-12, and 14-20 are directed to an abstract idea and are not patent eligible.
Step 2A (2): This judicial exception is not integrated into a practical application. In particular, claims 1, 4, 12, and 14-20 recite additional elements of “a computer-implemented method; improving the processing speed of an analytics processing database; landing table; a database; a server; a user input device (claims 1 and 12); email channel (claim 4); a system for improving the speed of a database management system; a new change event data repository; a historical change event data repository; a processor, programmed and operable to; a normalized change event data repository (claim 12); a computing device programmed and operable with the database management system (claim 15); wherein the computing device is a portable computing device selected from the group consisting of a tablet and mobile phone (claim 16); a segmentation engine programmed and operable (claims 17 and 18)”. These additional elements do not integrate the abstract idea into a practical application because the claims do not recite (a) an improvement to another technology or technical field and (b) an improvement to the functioning of the computer itself and (c) implementing the abstract idea with or by use of a particular machine, (d) effecting a particular transformation or reduction of an article, or (e) applying the judicial exception in some other meaningful way beyond generally linking the use of an abstract idea to a particular technological environment. These additional elements evaluated individually and in combination are viewed as computing and display devices that are used to perform the abstract process described in Step 2A (prong2). Limitations that recite mere instructions to implement an abstract idea on a computer or merely uses a computer as a tool to perform an abstract idea are not indicative of integration into a practical application (see MPEP 2106.05(f)). The Examiner finds that improving the processing speed of an analytics processing database via preprocessing, filtering, condensing, and/or organizing data chronologically thereby reducing the amount of data to process is not a direct technological improvement of the database itself. The database’s capabilities or functionality has not changed as a result of implementing this process. Per MPEP 2106.04(a), mere automation of manual processes or increasing the speed of a process where these purported improvements come solely from the capabilities of a general-purpose computer are not sufficient to show an improvement in computer-functionality. Therefore, claims 1-4, 6-12, and 14-20 do not include individual or a combination of additional elements that integrate the judicial exception into a practical application and thus are not patent eligible.
Step 2B: The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. Claims 1, 4, 12, and 14-20 recite additional elements of “a computer-implemented method; improving the processing speed of an analytics processing database; landing table; a database; a server; a user input device (claims 1 and 12); email channel (claim 4); a system for improving the speed of a database management system; a new change event data repository; a historical change event data repository; a processor, programmed and operable to; a normalized change event data repository (claim 12); a computing device programmed and operable with the database management system (claim 15); wherein the computing device is a portable computing device selected from the group consisting of a tablet and mobile phone (claim 16); a segmentation engine programmed and operable (claims 17 and 18)”. These additional elements evaluated individually and in combination are viewed as mere instructions to apply or implement the abstract idea on a computer. Applying an abstract idea on a computer does not integrate a judicial exception into a practical application or provide an inventive concept (see MPEP 2106.05(f)). Therefore, claims 1-4, 6-12, and 14-20 do not include individual or a combination of additional elements that are sufficient to amount to significantly more than the judicial exception and thus are not patent eligible.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 6-12, and 15-20 are rejected under 35 U.S.C. 103 as being unpatentable over Schlapfer et al. (US 2017/0048323 A1) in view of MacIntyre et al. (US 2008/0208910 A1).
As per claim 1 (Currently amended), Schlapfer teaches a computer-implemented method for improving the processing speed of an analytics processing database for tracking membership of a collection based on new records corresponding to new membership change events, wherein the new records have varying time stamps ranging from old time stamps to current time stamps, the method comprising (Schlapfer e.g. Methods, devices, systems, and non-transitory process-readable storage media for updating care team assignments data in multiple systems associated with a hospital (Abstract). FIG. 1 illustrates a communication system 100 including a sync server 110, an electronic hospital record server 120 ("EHR"), and a voice communications server 130 suitable for use with the various embodiments [0044]. The sync server 110 may be configured to store log information ( e.g., data within an HL 7 log database, etc.) in response to every HL 7 communication exchanged with the EHR interface engine 402. The sync server 110 may store a record of the time, recipient, content, and/or content of such an HL 7 transmission in an HL 7 log file [0095]. FIG. 5A illustrates an embodiment method 500 performed by a sync server to provide up-to-date information of care team assignments based on data from other servers (e.g., a voice communications server and/or an EHR server) [0101].):
Schlapfer teaches receiving, in any chronological order, the new records for membership change events, wherein the membership change events comprise additions and removals; (Schlapfer e.g. Multiple systems may be used to define and track care team assignments within a hospital [0033]. Typically, an EHR system may include a server configured to manage and distribute patient-based data, such as by transmitting HL 7 data feeds that report associated physician(s) and assigned room(s)/bed(s) for all admitted [0033]. Hospitals may employ a communications-based system to facilitate communications among hospital staff [0034]. In order to enable communications with the correct individual for a particular situation, such voice communication systems may maintain a database that matches communication devices to particular individuals and keeps track of their care team assignments and locations [0034]. The sync server may utilize existing APIs to register with each of the EHR server and voice communications server such that any changes to either corresponding system may be reported to the sync server [0036]. Event messages from the voice communications server may provide accurate data regarding the adding or removing of staff members from care teams [0036]. In general, the voice communications server may transmit event messages that indicate changes or updates to care team assignments (or group information) [0047]. For example, the sync server 110 may receive subscription messages from the voice communications server 130 indicating when particular nurses of the hospital log-in or out of a shift and/or HL 7 messages from the EHR server 120 that indicate when a particular patient's data changes (e.g., assigned to a new bed, room, specialist doctor, etc.) [0050]. The sync server 110 may recognize and store data indicating care team member assignments (e.g., staff assignments) using an interface library executing on the sync server 110. Such a library may ...further register for group membership change events (i.e., subscribe to receive event messages from the voice communications server 130). For example, when an event occurs related to the reassignment of a care team member, the sync server 110 via the library may receive a notification of the event, causing the library to look-up a related group-to-location and role mapping created during an initial process, and send an update message to the EHR server indicating such a reassignment [0059]. The embodiment techniques may be useful in several use cases, some examples of which include removing a provider (e.g., a nurse, nurse assistant, etc.) from active care team assignment data, adding a provider to active care team assignment data that has never been on the care team before, and adding a provider to active care team assignment data that has been on the care team before [0042].)
Schlapfer teaches adding the new records to a landing table according to a time-based partitioning scheme compatible with a database protocol for grouping new records by profile ID and Segment ID, wherein the time-based partitioning scheme enables quick and efficient record ingestion by updating only a relatively small number of files versus over the whole dataset for where the data should be written; (Schlapfer e.g. In some embodiments the voice communications server may add new data records (or instances) when a provider is logging into a care team for the first time. In some embodiments, the voice communications server may add new data records (or instances) when a provider is logging into a care team after a first time, in which case the new instances overwrite or otherwise replace any previous instances so that the older instances are no longer reported to other systems (e.g., EHR system via HL 7 message, etc.) [0039]. The voice communications server 130 may also be connected to a log module 134, such as a local database configured to store information related to communications from the various voice communications badge devices 136 [0048]. For example, via the wired or wireless connection 135, the voice communications server 130 may transmit to the log module 134 data describing incoming messages from a nurse's voice communications badge device 136, the time of receipt, and any other location-based and/or shift-based information [0048]. The voice communications server 130 may also be connected to an assignments computer 132 (or shift assignments computer), such as a hospital computing device or database configured to store information related to the current care team assignments within the hospital [0048]. The sync server 110 may be configured to continually receive data from both the EHR server 120 and the voice communications server 130 that indicates up-to-date changes to care teams associated with the various patients, locations, and/or shifts of the hospital [0050]. The sync server 110 may utilize an architecture designed to utilize data feeds from the EHR server 120 that are delivered to the sync server 110, such as via an ADT message-handling system or software [0052]. The architecture may include a feed table that may be an HL 7 service thread within a synching application or functionality executing on the sync server 110. In other words the feed table may be a data feed configured to receive HL 7 messages [0052]. In some embodiments, such a feed table may be generally associated with HL 7 message parsing functionalities of the sync server 110. For example, when an HL7 message arrives from the EHR server 120, the message may be inserted into a message table that is linked to the feed table from which the message came [0053]. Once inserted into the message table, the HL 7 message may be acknowledged, processed for patient assignment information, and then processed for staff assignments information [0053]. Assignments may be stored in an assignment table in a local database. The assignment table may contain role identifiers, location identifiers, and the user identifiers (e.g., unique identifiers for each nurse, etc.) wherein the role identifier may be the source, unit and role from which the assignment was generated [0060]. In particular, if changes are needed to the data currently stored at the voice communications server 130, the sync server 110 may transmit an update message 448 to the voice communications server 130 that is configured to cause the voice communications server 130 to replace, delete, add, and/or otherwise update care team assignment data according to the determinations of the sync server 110 [0090]. FIG. 5A illustrates an embodiment method 500 performed by a sync server to provide up-to-date information of care team assignments based on data from other servers (e.g., a voice communications server and/or an EHR server) [0101]. The operations of blocks 504-520 may represent a "live" (or online or real-time) sync mode wherein the sync server may continually update data records based on received messages from the voice communications server and/or the EHR server [0106].)
Schlapfer teaches preprocessing, on a server, the new records and historic records to create a normalized data table, wherein the preprocessing comprises (Schlapfer e.g. In some embodiments the voice communications server may add new data records (or instances) when a provider is logging into a care team for the first time. In some embodiments, the voice communications server may add new data records (or instances) when a provider is logging into a care team after a first time, in which case the new instances overwrite or otherwise replace any previous instances so that the older instances are no longer reported to other systems (e.g., EHR system via HL 7 message, etc.) [0039]. Once an HL7 connection is established on a port defined by the feed table, the feed table row may define a transformation ( e.g., using normalizers) to convert HL 7 message data from the HL 7 connection into a location and patient within the synching application [0052]. Accordingly, in block 502, the sync server may obtain a data record for each in a plurality of tracked locations, such as a data record for each room in a hospital. In general, the obtained data records may include a database of common terms that represent an initial state of all the care team assignments associated with the tracked locations [0102]. The obtained data records may correspond to group information received from the voice communications server, such as an initial download of current shift-based and/or location-based care team assignment data for all relevant, tracked locations within a hospital [0103]. In some embodiments, the obtained data records may be records previously generated or otherwise populated by the sync server (e.g., synched care team assignment data based on data from both the voice communications server and the EHR server) [0103].):
Schlapfer teaches reading, from a historic table, all historic records for the memberships present in new records; chronologically arranging the historic records and new records together per group; determining by the server invalid records, in each group, as: (Schlapfer e.g. The sync server 110 may be connected to a local database, such as the MySQL module 116 configured to store data records related to the various patients admitted to the hospital and/or the various care teams active in the hospital [0050]. Once a message has been stored in the message table and acknowledged, the sync server 110 may asynchronously perform various message processing tasks in order to continue reading and acknowledging messages. In some embodiments, the sync server 110 may read a message from a database and apply a field mapping/rule set to populate the columns of the message table [0053]. The sync server may generate the data structures 302, 352 for transmission to the voice communications server and EHR server respectively based on evaluating the data structures 202, 252 and/or any previously stored data within a local database (e.g., MySQL database) [0071]. The sync server 110 may be configured to store log information ( e.g., data within an HL 7 log database, etc.) in response to every HL 7 communication exchanged with the EHR interface engine 402. The sync server 110 may store a record of the time, recipient, content, and/or content of such an HL 7 transmission in an HL 7 log file [0095]. Accordingly, in block 502, the sync server may obtain a data record for each in a plurality of tracked locations, such as a data record for each room in a hospital. In general, the obtained data records may include a database of common terms that represent an initial state of all the care team assignments associated with the tracked locations [0102]. The obtained data records may correspond to group information received from the voice communications server, such as an initial download of current shift-based and/or location-based care team assignment data for all relevant, tracked locations within a hospital [0103]. In some embodiments, the obtained data records may be records previously generated or otherwise populated by the sync server (e.g., synched care team assignment data based on data from both the voice communications server and the EHR server) [0103]. The event message may indicate various identifiers, codes, names, labels, and/or similar data related to care team members, locations within the hospital, patient and patient associations with care team members and/or locations within the hospital, timestamps, and/or other data that may be used by the sync server to properly contextualize the event message's information [0106]. In some embodiments, the sync server may compare timestamps or other date information of the received event message to the timestamp or date information of the identified data record to determine whether the voice communications server is utilizing out-of-date care team assignment data [0136].) (i) each removed change event that is not preceded by an added change event; and (ii) each added change event if preceded by an unclosed added change event; (Schlapfer e.g. Based on a comparison of data from the EHR server 120 and the voice communications server 130, the sync server 110 may determine whether updates are needed to be sent to the EHR server 120 and/or the voice communications server 130 [0088]. For example, if nurse identifiers received from the event relay message 432 were inaccurate or incomplete, the sync server 110 may determine that an update to the EHR server 120 is needed. As another example, if physician data received from the group information data 412 was out incomplete or out-of-date, the sync server 110 may determine that an update to the voice communications server 130 is needed [0088]. When inaccurate or out-of-date data is detected in the data received from the voice communications server 130 and/or the EHR server 120, the sync server 110 may generate an assignment event that causes the sync server 110 to transmit updates to the servers 120, 130 having data in need of adjustment [0090]. In particular, if changes are needed to the data currently stored at the voice communications server 130, the sync server 110 may transmit an update message 448 to the voice communications server 130 that is configured to cause the voice communications server 130 to replace, delete, add, and/or otherwise update care team assignment data according to the determinations of the sync server 110 [0090]. For example, the sync server 110 may transmit an update message 448 indicating that a data record needs to add a member (e.g., a patient has been moved to a room associated with a nurse, etc.) and/or remove a member (e.g., a patient is no longer associated with a particular room worked by a nurse, etc.) [0090]. The event message may indicate various identifiers, codes, names, labels, and/or similar data related to care team members, locations within the hospital, patient and patient associations with care team members and/or locations within the hospital, timestamps, and/or other data that may be used by the sync server to properly contextualize the event message's information [0106]. The sync server may create an 'addMember' request to add a member to a group when an HL7 message (i.e., the ADT message) from the EHR server is received and the EHR server is the source of truth for that role and unit. For those users removed, the sync server may create a 'removeMember' request to remove the user from the group [0110]. The sync server may determine whether there is any missing data in the identified data record in optional determination block 516 [0111]. The sync server may determine whether the received event message indicates that there is missing and/or out-of-date data in the EHR server in determination block 552. For example, the sync server may evaluate whether the event message from the EHR server includes empty, null, or placeholder data that indicate current or accurate information for such data fields is not known by the EHR server [0130]. The sync server may compare timestamps or other date information of the received event message to the timestamp or date information of the identified data record to determine whether the EHR server is utilizing out-of-date care team assignment data [0132]. In some embodiments, the sync server may compare timestamps or other date information of the received event message to the timestamp or date information of the identified data record to determine whether the voice communications server is utilizing out-of-date care team assignment data [0136].)
Schlapfer teaches creating a new condensed table of normalized records by filtering out the invalid records from the landing table; and (Schlapfer e.g. In some embodiments, determining whether the data in the first obtained data record for the tracked location and associated with the second server is inaccurate based on the received event message from the first server may include using a heuristic or intelligence comparison algorithm to identify that the data in the first obtained data record is incorrect or out-of-date [0002]. In some embodiments, the method may further include determining whether there is missing or out-of-date information at the first server based on the received event message and the first obtained data record, and transmitting a second update message to the first server including the missing or out-of-date information from the first obtained data record [0002]. The data processing operations performed by the sync server may include receiving HL7 data streams from the EHR server and receiving group information from the voice communications server via an HTTP connection, identifying data fields from the received data that are related to care team assignments of the hospital, translating the identified data fields into common terms that are can be compared to care team assignment data from the either server (e.g., the EHR server and/or the voice communications server) using an intelligent translator (or normalization operations), forming a database of the common terms, using a heuristic or intelligence comparison algorithm to compare care team assignment data stored in the common terms database to identify incorrect or out-of-date records, and sending corrective data or messages [0038].)
Schlapfer teaches comparing the new condensed table to a previous normalized data table for differences; (Schlapfer e.g. In some embodiments, the method may further include performing normalization operations to translate data within the received event message into common terms [0007]. In some embodiments, performing the normalization operations to translate the data within the received event message into the common terms may include identifying an output format for the received event message, applying a regular expression to input data for each node in a node set to obtain a result string, storing group information of the obtained result string for each node in the node set, and applying the identified output format to the stored group information to obtain normalized data [0007]. In some embodiments a sync server may compare staff assignments to data stored in the EHR system to staff assignments to communicators stored in the hospital communication system database, and update the EHR system database as appropriate [0024]. In response to receiving an event message from the voice communications server or the EHR server, the sync server may intelligently processes the event message to generate a common term database of information related to care team assignments (if necessary), and compare care team assignment data from both servers to find inconsistencies, errors, missing data, or out-of-date content for either [0037]. In some embodiments, intelligent heuristics may be used to identify inconsistencies indicative of outdated EHR server or voice communications server records [0037]. When accurate care team assignment data from one server is not represented in the data associated with the other server, the sync server may transmit update messages to correct and/or supplement care team assignment data stored on the other server, thus synchronizing care team assignment information stored in the two systems [0037]. The data processing operations performed by the sync server may include receiving HL 7 data streams from the EHR server and receiving group information from the voice communications server via an HTTP connection, identifying data fields from the received data that are related to care team assignments of the hospital, translating the identified data fields into common terms that are can be compared to care team assignment data from the either server (e.g., the EHR server and/or the voice communications server) using an intelligent translator (or normalization operations), forming a database of the common terms, using a heuristic or intelligence comparison algorithm to compare care team assignment data stored in the common terms database to identify incorrect or out-of-date records, and sending corrective data or messages [0038]. Various embodiments include translating and correlating different database fields and values in order to affect such comparisons and updates when the two databases use inconsistent data structures, terminology, and organizations [0024]. The embodiment techniques may be useful in several use cases, some examples of which include removing a provider (e.g., a nurse, nurse assistant, etc.) from active care team assignment data, adding a provider to active care team assignment data that has never been on the care team before, and adding a provider to active care team assignment data that has been on the care team before [0042].)
Schlapfer teaches updating the previous normalized data table to form the normalized data table based on the differences from the comparing step (Schlapfer e.g. In some embodiments a sync server may compare staff assignments to data stored in the EHR system to staff assignments to communicators stored in the hospital communication system database, and update the EHR system database as appropriate [0024]. Various embodiments include translating and correlating different database fields and values in order to affect such comparisons and updates when the two databases use inconsistent data structures, terminology, and organizations [0024]. In addition to receiving and analyzing data from the voice communications server and/or the EHR server, the sync server may receive care assignment data records from various other data sources, devices, servers, etc. that are configured to communicate with the sync server via supported messaging (e.g., HL7 messages via TCP connections, via programmatic interface connections such as a Vocera Administration Interface (VAI)) over HTTP connections, etc.), determine the most accurate assignments for each patient/room based on any or all the received data records, and transmit all necessary update messages to the various data sources (including the EHR server and/or the voice communications server) to ensure the more current, up-to-date care team assignment information is stored on the various data sources [0041]. The sync server 110 may then perform a look-up operation using the patient identifier on a local database and update the patient information (e.g., physician data, assigned bed, etc.) of the local database with any new information from the received HL7 message [0054]. Based on a comparison of data from the EHR server 120 and the voice communications server 130, the sync server 110 may determine whether updates are needed to be sent to the EHR server 120 and/or the voice communications server 130 [0088]. For example, if nurse identifiers received from the event relay message 432 were inaccurate or incomplete, the sync server 110 may determine that an update to the EHR server 120 is needed. As another example, if physician data received from the group information data 412 was out incomplete or out-of-date, the sync server 110 may determine that an update to the voice communications server 130 is needed [0088].)
Schlapfer teaches sending the updated normalized data table to the… processing server/database;…thereby avoiding requiring the… processing database to organize both the valid and invalid events such that processing time is faster, responsiveness to the user is faster, and less computing resources are required. (Schlapfer e.g. The sync server 110 may specify and adjust over time the locations and roles of personnel associated with care team assignments of the hospital by creating unit location entries in a local database when synchronizing with the voice communications server 130 and/or the EHR server 120 [0058]. FIGS. 3A-3B illustrate exemplary synched data that may be transmitted by an embodiment sync server to various sources for storage in individual tracking systems, such as EHR and voice communications systems [0071]. The synched data in FIGS. 3A-3B may result from the sync server evaluating the data from both received data structures 202, 252 as illustrated above in FIGS. 2A-2B [0071]. FIGS. 3A-3B illustrate exemplary synched data that may be transmitted by an embodiment sync server to various sources for storage in individual tracking systems, such as EHR and voice communications systems [0071]. The sync server may generate the data structures 302, 352 for transmission to the voice communications server and EHR server respectively based on evaluating the data structures 202, 252 and/or any previously stored data within a local database (e.g., MySQL database) [0071]. Fig. 4A illustrates...a sync phase 425 during which the sync server 110 receives and utilizes event messages from the servers 120, 130 to generate complete, synched care team assignment data to be redistributed back to the servers 120, 130 [0076]. FIG. 5A illustrates an embodiment method 500 performed by a sync server to provide up-to-date information of care team assignments based on data from other servers (e.g., a voice communications server and/or an EHR server) [0101]. The operations of blocks 504-520 may represent a "live" (or online or real-time) sync mode wherein the sync server may continually update data records based on received messages from the voice communications server and/or the EHR server [0106].)
Schlapfer teaches receiving a user input via a user input device; and (Schlapfer e.g. The EHR server 120 may receive information that is transmitted from various input sources, such as hospital administrator computers 126 connected to the EHR server 120 via wired or wireless connections 127 [0046].)
Schlapfer does not explicitly teach, however, MacIntyre teaches the following:
MacIntyre teaches a computer-implemented method for improving the processing speed of an analytics processing database (MacIntyre e.g. A system, method, and computer program product for processing and visualization of information comprising a Visual On-Line Analytical Processing (VOLAP) Platform comprising one or more Visual Workstations, a Visual Server, and one or more Visual Sensors [0050]. The Visual Workstation includes high-speed graphics capabilities for fast multi-dimensional graphic presentations of e-business analytics to the user [0053].)
MacIntyre teaches sending the updated normalized data to an analytics processing database (MacIntyre e.g. A system, method, and computer program product for processing and visualization of information comprising a Visual On-Line Analytical Processing (VOLAP) Platform comprising one or more Visual Workstations, a Visual Server, and one or more Visual Sensors [0050]. The Visual Workstation includes high-speed graphics capabilities for fast multi-dimensional graphic presentations of e-business analytics to the user [0053]. The Visual Server is installed on the user's network and collects data from the Visual Sensors. After receiving the data, the Visual Server does the following with the data:...maintains a database of the transformed data in order that it can be re-transmitted to a Visual Workstation or transmitted to a new Visual Workstation ([0140]-[0145]). On-Line Analytical Processing (OLAP) has become available as a tool for providing c-business analytics. OLAP is a category of software technology that enables analysts, managers and executives to gain insight into data through fast, consistent, interactive access to a wide variety of possible views of information that has been transformed from raw data to reflect the real dimensionality of the enterprise as understood by the user [0023].)
MacIntyre teaches receiving a user selection via a user input device (MacIntyre e.g. The present invention extends and modifies the typical definition of OLAP in the following ways, amongst others: permits users to define selections or queries through interacting with visualizations that depicts metrics and data dimensions ([0056]-[0060]). A selection, filter or query defines the search terms and conditions used by Visual Workstation to go to the database and retrieve data as defined by that selection, filter or query and present it to the user [0119]. The Visual Workstation is a desktop application that provides its users with a robust desktop operating environment that enables very fast multi-dimensional data analysis, robust data visualization, and an interactive method of defining queries of the fact data [0126]. The Visual Workstation also provides a user interface with numerous interaction techniques such as data range selection, sliding window selection, normalize to series, water leveling, selection by water level, choice of series dimensions, move camera, drag, zoom and spin camera, mouse over to display values, context dialogs and menus, axis zooming, axis drilling, and others. Each visualization provides interactive selection techniques to filter the others allowing the user to visually slice and dice the data set [0196].)
MacIntyre teaches computing, on the analytics processing database, at least one metric for the collection based on the user selection and the updated normalized data table. (MacIntyre e.g. The present invention extends and modifies the typical definition of OLAP in the following ways, amongst others: 2. enables metrics and dimensions to be constantly updated on the user's visual desktop as the fact data changes, in real-time, due to ongoing data collection; ([0056] and [0058]). A metric is a numerical value set representing and relating a measurement or a derived and calculated measurement. For instance, the present invention can monitor the following metrics amongst others: visits, value events, conversion, return, other metrics, custom metrics, and temporary metrics ([0101]-[0108]). Data is organized hierarchically into databases containing tables containing columns containing rows [0307].)
The Examiner submits that before the effective filing date, it would have been obvious to one of ordinary skill in the art to combine Schlapfer’s communication system with MacIntyre’s analytical processing platform that improves the processing speed of analytics, receive a user selection, and computes at least one metric for the collection in order to quickly identify trends, changes, opportunities, correlations, and problems through the use of the advanced visualization techniques and real-time online analytical processing (MacIntyre e.g. [0055]).
As per claim 6 (Currently amended), Schlapfer in view of MacIntyre teach the method of claim 1, Schlapfer teaches wherein the collection is an audience (Schlapfer e.g. Event messages from the voice communications server may provide accurate data regarding the adding or removing of staff members from care teams [0036]. Event messages from the EHR server may provide accurate data regarding changes to the patient's status (e.g., admission, discharge, etc.) and/or to the patient's long-term team of care providers (e.g., general physician, specialist, etc.) [0036].).
As per claim 7 (Currently amended), Schlapfer in view of MacIntyre teach the method of claim 1, Schlapfer teaches further comprising continuously reading new records, and generating an initial set of records of membership change events after reading new records (Schlapfer e.g. The sync server 110 may be configured to continually receive data from both the EHR server 120 and the voice communications server 130 that indicates up-to-date changes to care teams associated with the various patients, locations, and/or shifts of the hospital [0050]. FIG. 5A illustrates an embodiment method 500 performed by a sync server to provide up-to-date information of care team assignments based on data from other servers (e.g., a voice communications server and/or an EHR server) [0101]. The obtained data records may correspond to group information received from the voice communications server, such as an initial download of current shift-based and/or location-based care team assignment data for all relevant, tracked locations within a hospital [0103]. In some embodiments, the obtained data records may be records previously generated or otherwise populated by the sync server (e.g., synched care team assignment data based on data from both the voice communications server and the EHR server) [0103]. The operations of blocks 504-520 may represent a "live" (or online or real-time) sync mode wherein the sync server may continually update data records based on received messages from the voice communications server and/or the EHR server [0106].).
As per claim 8 (Currently amended), Schlapfer in view of MacIntyre teach the method of claim 7, Schlapfer teaches wherein the initial set of records are generated based on previously stored membership data of the collection (Schlapfer e.g. Assignments may be stored in an assignment table in a local database. The assignment table may contain role identifiers, location identifiers, and the user identifiers (e.g., unique identifiers for each nurse, etc.) wherein the role identifier may be the source, unit and role from which the assignment was generated [0060].The obtained data records may correspond to group information received from the voice communications server, such as an initial download of current shift-based and/or location-based care team assignment data for all relevant, tracked locations within a hospital [0103]. In some embodiments, the obtained data records may be records previously generated or otherwise populated by the sync server (e.g., synched care team assignment data based on data from both the voice communications server and the EHR server) [0103].)
As per claim 9 (Currently amended), Schlapfer in view of MacIntyre teach the method of claim 1, Schlapfer teaches further comprising creating the history table comprising the historical records, and wherein the new records are written to the history table by clusters according to profile ID and segment ID (Schlapfer e.g. The sync server 110 may be connected to a local database, such as the MySQL module 116 configured to store data records related to the various patients admitted to the hospital and/or the various care teams active in the hospital [0050]. The MySQL module 116 may be accessed via the wired or wireless connection 117 to obtain a data record indicating the last known nurse, nurse assistant, bed, wing, building, physician, specialist, and hospitalist for a particular patient identifier [0050]. The sync server 110 may then perform a look-up operation using the patient identifier on a local database and update the patient information (e.g., physician data, assigned bed, etc.) of the local database with any new information from the received HL7 message [0054]. Assignments may be stored in an assignment table in a local database. The assignment table may contain role identifiers, location identifiers, and the user identifiers (e.g., unique identifiers for each nurse, etc.) wherein the role identifier may be the source, unit and role from which the assignment was generated. In some embodiments, each role data record may include a set of rules [0060]. FIG. 2A illustrates an exemplary data structure 202 (or data record) including care team assignment data from a voice communications server that may be received by an embodiment sync server [0063]. The data structure 202 may include various data segments 210-222, including a location identifier segment 210, a nurse role segment 212, a nurse assistant role segment 214, a primary doctor role segment 216, a specialist doctor role segment 218, a hospitalist role segment 220, and an optional patient identifier segment 222 [0063].).
As per claim 10 (Original), Schlapfer in view of MacIntyre teach the method of claim 9, Schlapfer teaches further comprising purging the history table (Schlapfer e.g. In some embodiments the voice communications server may add new data records (or instances) when a provider is logging into a care team for the first time. In some embodiments, the voice communications server may add new data records (or instances) when a provider is logging into a care team after a first time, in which case the new instances overwrite or otherwise replace any previous instances so that the older instances are no longer reported to other systems ( e.g., EHR system via HL 7 message, etc.) [0039]. The sync server 110 may be configured to update local data to indicate care team assignment changes as indicated by event messages from the voice communications server 130 [0057]. For example, when a patient location has changed (e.g., reassigned to a new bed/room/ wing, etc.), the sync server 110 may update local database records to remove nurse assignments to the patient (or his/her location) and insert new nurse assignments to the patient based on his/her new location from the current message [0057].The sync server 110 may specify and adjust over time the locations and roles of personnel associated with care team assignments of the hospital by creating unit location entries in a local database when synchronizing with the voice communications server 130 and/or the EHR server 120 [0058].).
As per claim 11 (Currently amended), Schlapfer in view of MacIntyre teach the method of claim 1, Schlapfer teaches wherein the normalized data table is updated at least frequently as every 30 minutes (Schlapfer e.g. When a synching application begins executing on the sync server 110, a HL7 server instance may be created for each row in the feed table. Once an HL7 connection is established on a port defined by the feed table, the feed table row may define a transformation ( e.g., using normalizers) to convert HL7 message data from the HL7 connection into a location and patient within the synching application [0052]. The sync server 110 may perform normalizing operations to ensure that data exchanged with the EHR interface engine 402 is in a format that may be accessible to the EHR server 120 [0094]. FIG. 5A illustrates an embodiment method 500 performed by a sync server to provide up-to-date information of care team assignments based on data from other servers (e.g., a voice communications server and/or an EHR server) [0101]. The operations of blocks 504-520 may represent a "live" (or online or real-time) sync mode wherein the sync server may continually update data records based on received messages from the voice communications server and/or the EHR server [0106].), Schlapfer does not explicitly teach, however, MacIntyre teaches and wherein the computing step is performed in under 1 second. (MacIntyre e.g. The present invention achieves these objects and others by providing a system, method, and computer program product for processing and visualization of information comprising a Visual On-Line Analytical Processing (VOLAP) Platform comprising one or more Visual Workstations, a Visual Server, and one or more Visual Sensors [0050]. As shown in FIGS. 1-4, the VOLAP Platform includes at least one Visual Sensor component 101a-101c, a Visual Server 103 and at least one Visual Workstation 105, 201 [0125]. VOLAP technology allows very fast access to its database and allows the rapid location of data in that database. The data that VOLAP queries each time is the fact data, not an aggregation of the data into multi-dimensional arrays that needed to be prepared in advance. VOLAP's tremendously fast data access abilities allow it to create multi-dimensional arrays and multiple other types of data structures on-the-fly in milliseconds if they are needed for a particular type of analysis [0532]. The system provide real-time response as filtering and other user interface operations complete in about 100ms or less allowing for animation of multiple on-screen visualizations [0197].)
The Examiner submits that before the effective filing date, it would have been obvious to one of ordinary skill in the art to combine Schlapfer’s communication system with MacIntyre’s analytical processing platform that performs a computing step under 1 second in order to quickly identify trends, changes, opportunities, correlations, and problems through the use of the advanced visualization techniques and real-time online analytical processing (MacIntyre e.g. [0055]).
As per claim 12 (Currently amended) Schlapfer teaches…a database management system…,the system comprising: (Schlapfer e.g. FIG. 1 illustrates a communication system 100 including a sync server 110, an electronic hospital record server 120 ("EHR"), and a voice communications server 130 suitable for use with the various embodiments [0044].):
Schlapfer teaches a new change event data repository where new membership change events are received and recorded to a raw event table (Schlapfer e.g. The voice communications server 130 may also be connected to a log module 134, such as a local database configured to store information related to communications from the various voice communications badge devices 136 [0048]. The voice communications server 130 may also be connected to an assignments computer 132 (or shift assignments computer), such as a hospital computing device or database configured to store information related to the current care team assignments within the hospital [0048]. The voice communications server may be configured to update care team assignments data in response to voice communications received via voice communications badge devices carried by hospital personnel, a mobile application running on a mobile device (e.g., a doctor or nurse's smartphone, etc.), and/or a website or web-based client accessed by various care team members and/or hospital personnel [0031].) Schlapfer teaches according to a time-based partitioning scheme compatible with a database protocol for grouping new records by profile ID and Segment ID, wherein the time-based partitioning scheme enables quick and efficient record ingestion by updating only a relatively small number of files versus over the whole dataset for where the data should be written (See claim 1 response.);
Schlapfer teaches a historical change event data repository where the new membership change events and existing membership change events are saved in a historical event table; (Schlapfer e.g. The method may further include providing configuration data to a local database to obtain the data record for each in the plurality of tracked locations of the hospital, connecting to the voice communications server, downloading group data from the voice communications server, identifying a set of the obtained data records from the local database that may be associated with the downloaded group data [0003]. Various embodiments provide methods and systems for updating care team assignments data in multiple systems associated with a hospital by leveraging information stored within a communication system database [0024]. In order to enable communications with the correct individual for a particular situation, such voice communication systems may maintain a database that matches communication devices to particular individuals and keeps track of their care team assignments and locations [0034]. Assignments may be stored in an assignment table in a local database. The assignment table may contain role identifiers, location identifiers, and the user identifiers (e.g., unique identifiers for each nurse, etc.) wherein the role identifier may be the source, unit and role from which the assignment was generated. In some embodiments, each role data record may include a set of rules [0060].)
Schlapfer teaches a processor, programmed and operable to (Schlapfer e.g. In various embodiments, a processor of an embodiment sync server may be configured to perform a process for synchronizing care team assignment data of a hospital ( or other similar facility) [0100].) :
Schlapfer teaches read, from the historical event table, all historic records for the memberships present in new records; chronologically arrange the historic records and new records together per group; determine invalid records in each group as: (i) each removed change event that is not preceded by an added change event; and (ii) each added change event if preceded by an unclosed added change event; create a condensed event table by filtering out invalid membership change events from the historical event table; compare the condensed event table to a previous normalized event table for differences; and update the previous normalized event table based on the differences from the comparing step; (See claim 1 response.)
Schlapfer teaches a normalized change event data repository for recording the updated normalized event table; and (Schlapfer e.g. In response to receiving an event message from the voice communications server or the EHR server, the sync server may intelligently processes the event message to generate a common term database of information related to care team assignments (if necessary), and compare care team assignment data from both servers to find inconsistencies, errors, missing data, or out-of-date content for either [0037]. The sync server 110 may specify and adjust over time the locations and roles of personnel associated with care team assignments of the hospital by creating unit location entries in a local database when synchronizing with the voice communications server 130 and/or the EHR server 120 [0058]. The sync server may generate the data structures 302, 352 for transmission to the voice communications server and EHR server respectively based on evaluating the data structures 202, 252 and/or any previously stored data within a local database (e.g., MySQL database) [0071].)
Schlapfer teaches a database management system operable to update data records based on the normalized event table from the normalized change event data repository… without being required to organize both the valid and invalid events such that processing time is faster, responsiveness to the user is faster, and less computing resources are required.. (Schlapfer e.g. A sync server may be configured to detect and automatically update out-of-date care team assignment data that is reported and maintained by a first server associated with the hospital's voice communications system (i.e., the voice communications server) and a second server associated with the hospital's EHR system (i.e., the EHR server) [0036]. In addition to receiving and analyzing data from the voice communications server and/or the EHR server, the sync server may receive care assignment data records from various other data sources, devices, servers, etc. that are configured to communicate with the sync server via supported messaging (e.g., HL7 messages via TCP connections, via programmatic interface connections such as a Vocera Administration Interface (VAI)) over HTTP connections, etc.), determine the most accurate assignments for each patient/room based on any or all the received data records, and transmit all necessary update messages to the various data sources (including the EHR server and/or the voice communications server) to ensure the more current, up-to-date care team assignment information is stored on the various data sources [0041]. In other words, the embodiment sync server may be configured to process and synchronize care team assignment data from a plurality of sources associated with a tracked facility (e.g., a hospital) [0041]. FIG. 5A illustrates an embodiment method 500 performed by a sync server to provide up-to-date information of care team assignments based on data from other servers (e.g., a voice communications server and/or an EHR server) [0101]. The operations of blocks 504-520 may represent a "live" (or online or real-time) sync mode wherein the sync server may continually update data records based on received messages from the voice communications server and/or the EHR server [0106]. In optional block 506, the sync server may perform normalization operations on data within the received event message. In general, such normalization operations may adjust the formatting, organization, and/or content of some or all of the information within the received event message to conform to a uniform data configuration used by the sync server [0107]. FIGS. 7A-7C illustrate embodiment normalization functionalities of a sync server [0143].)
Schlapfer does not explicitly, however, MacIntyre teaches the following:
MacIntyre teaches a system for improving the processing speed of a database management system operable to compute a metric of a collection (MacIntyre e.g. The present invention achieves these objects and others by providing a system, method, and computer program product for processing and visualization of information comprising a Visual On-Line Analytical Processing (VOLAP) Platform comprising one or more Visual Workstations, a Visual Server, and one or more Visual Sensors [0050]. The Visual Workstation includes high-speed graphics capabilities for fast multi-dimensional graphic presentations of e-business analytics to the user [0053]. The present invention extends and modifies the typical definition of OLAP in the following ways, amongst others: 2. enables metrics and dimensions to be constantly updated on the user's visual desktop as the fact data changes, in real-time, due to ongoing data collection; ([0056] and [0058]).)
MacIntyre teaches a database management system operable to compute at least one metric… (MacIntyre e.g. The present invention achieves these objects and others by providing a system, method, and computer program product for processing and visualization of information comprising a Visual On-Line Analytical Processing (VOLAP) Platform comprising one or more Visual Workstations, a Visual Server, and one or more Visual Sensors [0050]. The present invention extends and modifies the typical definition of OLAP in the following ways, amongst others: 2. enables metrics and dimensions to be constantly updated on the user's visual desktop as the fact data changes, in real-time, due to ongoing data collection; ([0056] and [0058]). A metric is a numerical value set representing and relating a measurement or a derived and calculated measurement. For instance, the present invention can monitor the following metrics amongst others: visits, value events, conversion, return, other metrics, custom metrics, and temporary metrics ([0101]-[0108]).)
The Examiner submits that before the effective filing date, it would have been obvious to one of ordinary skill in the art to combine Schlapfer’s communication system with MacIntyre’s analytical processing platform that improves the processing speed of a database management system to compute at least one metric in order to quickly identify trends, changes, opportunities, correlations, and problems through the use of the advanced visualization techniques and real-time online analytical processing (MacIntyre e.g. [0055]).
As per claim 15 (Original), Schlapfer in view of MacIntyre teach the system of claim 12, Schlapfer teaches further comprising a computing device programmed and operable with the database management system to receive a user input (Schlapfer e.g. (Schlapfer e.g. The EHR server 120 may receive information that is transmitted from various input sources, such as hospital administrator computers 126 connected to the EHR server 120 via wired or wireless connections 127 [0046].) Schlapfer does not explicitly teach, however, MacIntyre teaches receive a user selection, and to display the metric. (MacIntyre e.g. The present invention extends and modifies the typical definition of OLAP in the following ways, amongst others: permits users to define selections or queries through interacting with visualizations that depicts metrics and data dimensions ([0056]-[0060]). A metric is a numerical value set representing and relating a measurement or a derived and calculated measurement. For instance, the present invention can monitor the following metrics amongst others: visits, value events, conversion, return, other metrics, custom metrics, and temporary metrics ([0101]-[0108]). A selection, filter or query defines the search terms and conditions used by Visual Workstation to go to the database and retrieve data as defined by that selection, filter or query and present it to the user [0119]. The Visual Workstation is a desktop application that provides its users with a robust desktop operating environment that enables very fast multi-dimensional data analysis, robust data visualization, and an interactive method of defining queries of the fact data [0126]. The Visual Workstation also provides a user interface with numerous interaction techniques such as data range selection, sliding window selection, normalize to series, water leveling, selection by water level, choice of series dimensions, move camera, drag, zoom and spin camera, mouse over to display values, context dialogs and menus, axis zooming, axis drilling, and others. Each visualization provides interactive selection techniques to filter the others allowing the user to visually slice and dice the data set [0196].)
The Examiner submits that before the effective filing date, it would have been obvious to one of ordinary skill in the art to combine Schlapfer’s communication system with MacIntyre’s analytical processing platform that receive a user selection and display metrics in order to quickly identify trends, changes, opportunities, correlations, and problems through the use of the advanced visualization techniques and real-time online analytical processing (MacIntyre e.g. [0055]).
As per claim 16 (Original), Schlapfer in view of MacIntyre teach the system of claim 15, Schlapfer teaches wherein the computing device is a portable computing device selected from the group consisting of a tablet and mobile phone. (Schlapfer e.g. In some embodiments, the received event message may correspond to a communication associated with a voice communications badge device, a mobile application running on a mobile device, and/or a web-based client application [0005]. In some embodiments, the voice communications server 130 may receive messages from other devices used by care team members, such as mobile devices and/or computing devices executing web clients/browsers (not shown) [0047]. The term "computing device" is used herein to refer to an electronic device equipped with at least a processor. Examples of computing devices may include mobile devices (e.g., cellular telephones, wearable devices, smartphones, web-pads, tablet computers, Internet enabled cellular telephones, Wi-Fi® enabled electronic devices, personal data assistants (PDA's), laptop computers, etc.), personal computers, and server computing devices [0026].)
As per claim 17 (Original), Schlapfer in view of MacIntyre teach the system of claim 12, Schlapfer teaches further comprising a segmentation engine programmed and operable to define a member segment based on a user instruction. (Schlapfer e.g. In response to receiving the subscription message 410, the voice communications server 130 may transmit group information data 412 to the sync server 110. Such group information data 412 may include data indicating the various groups stored by the voice communications server 130, such as groups comprising a location (e.g., a room number, etc.), patient(s), name(s), care team members assigned to the location, etc.[0081]. For example, the group information data 412 may include a plurality of data records, each associated with various rooms of a hospital and indicating any currently known identities of assigned nurses, nurse assistants, physicians, patients, hospitalists, etc. for the rooms [0081]. The returned group information may be stored and otherwise used at the sync server 110, such as stored in a local database (e.g., MySQL database) [0081].)
As per claim 18 (Currently amended), Schlapfer in view of MacIntyre teach the system of claim 17, Schlapfer teaches wherein the segmentation engine is further programmed and operable to determine a new membership change event based on automatically detecting an action of a sub-user, and to write the new membership change event to the raw event table for preprocessing (Schlapfer e.g. In some embodiments, the received event message may correspond to a communication associated with a voice communications badge device, a mobile application running on a mobile device, and/or a web-based client application. In some embodiments, the communication may indicate whether a care team member has logged-into or logged-out of a shift at the hospital [0005]. At the end of her shift, a nurse may use a voice communications badge device to log-off of her care team assignment associated with a room and a bed group within a hospital. The voice communications badge device may transmit a message to the voice communications server that in turn updates the appropriate care team assignment data, indicating the nurse is logged off [0043]. The voice communications server may then transmit an event message to the sync server indicating the nurse is logged off of her care team assignment to the room and the bed group within the hospital. The sync server may then transmit an HL7 update message to the EHR server, indicating the change to the care team assignment now that the nurse logged-off [0043]. Such an update message may indicate all nurses for the hospital and include data indicating that the nurse has an "end time" set corresponding to the time she logged-off [0043]. The sync server 110 may be configured to continually receive data from both the EHR server 120 and the voice communications server 130 that indicates up-to-date changes to care teams associated with the various patients, locations, and/or shifts of the hospital [0050]. For example, the sync server 110 may receive subscription messages from the voice communications server 130 indicating when particular nurses of the hospital log-in or out of a shift and/or HL 7 messages from the EHR server 120 that indicate when a particular patient's data changes (e.g., assigned to a new bed, room, specialist doctor, etc.) [0050]. In response to receiving the subscription message 410, the voice communications server 130 may transmit group information data 412 to the sync server 110. Such group information data 412 may include data indicating the various groups stored by the voice communications server 130, such as groups comprising a location (e.g., a room number, etc.), patient(s), name(s), care team members assigned to the location, etc.[0081]. For example, the group information data 412 may include a plurality of data records, each associated with various rooms of a hospital and indicating any currently known identities of assigned nurses, nurse assistants, physicians, patients, hospitalists, etc. for the rooms [0081]. The sync server 110 may specify and adjust over time the locations and roles of personnel associated with care team assignments of the hospital by creating unit location entries in a local database when synchronizing with the voice communications server 130 and/or the EHR server 120 [0058].)
As per claim 19 (Original), Schlapfer in view of MacIntyre teach the system of claim 12, Schlapfer teaches wherein the normalized change event data repository applies a time-based partitioning scheme for recording a normalized event table (Schlapfer e.g. The event message may indicate various identifiers, codes, names, labels, and/or similar data related to care team members, locations within the hospital, patient and patient associations with care team members and/or locations within the hospital, timestamps, and/or other data that may be used by the sync server to properly contextualize the event message's information [0106]. The sync server may evaluate timestamp information of care team assignment data from each source (e.g., EHR server, voice communications server) and provide a higher confidence value to the data with the most recent timestamp [0128]. The sync server may compare timestamps or other date information of the received event message to the timestamp or date information of the identified data record to determine whether the EHR server is utilizing out-of-date care team assignment data [0132]. In some embodiments, the sync server may compare timestamps or other date information of the received event message to the timestamp or date information of the identified data record to determine whether the voice communications server is utilizing out-of-date care team assignment data [0136].).
As per claim 20 (Original), Schlapfer in view of MacIntyre teach the system of claim 19, Schlapfer teaches wherein the historical change event data repository applies a data clustering scheme for saving the new membership change events and existing membership change events in the historical event table (Schlapfer e.g. The sync server 110 may recognize and store data indicating care team member assignments (e.g., staff assignments) using an interface library executing on the sync server 110. Such a library may ...further register for group membership change events (i.e., subscribe to receive event messages from the voice communications server 130). For example, when an event occurs related to the reassignment of a care team member, the sync server 110 via the library may receive a notification of the event, causing the library to look-up a related group-to-location and role mapping created during an initial process, and send an update message to the EHR server indicating such a reassignment [0059]. The sync server 110 may then perform a look-up operation using the patient identifier on a local database and update the patient information (e.g., physician data, assigned bed, etc.) of the local database with any new information from the received HL7 message [0054]. For example, when a patient location has changed (e.g., reassigned to a new bed/room/ wing, etc.), the sync server 110 may update local database records to remove nurse assignments to the patient (or his/her location) and insert new nurse assignments to the patient based on his/her new location from the current message [0057]. The sync server 110 may specify and adjust over time the locations and roles of personnel associated with care team assignments of the hospital by creating unit location entries in a local database when synchronizing with the voice communications server 130 and/or the EHR server 120 [0058].)
Claims 2-4 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Schlapfer et al. (US 2017/0048323 A1) in view of MacIntyre et al. (US 2008/0208910 A1) and in further view of Landa et al. (US 2013/0198376 A1).
As per claim 2 (Original), Schlapfer in view of MacIntyre teach the method of claim 1, Schlapfer in view of MacIntyre do not explicitly teach, however, Landa teaches wherein the computing comprises computing at least one metric from the following: size of the collection, population of the collection, and population for the collection for a time period. (Landa e.g. This invention relates to methods and systems for collecting, processing, and displaying information related to traffic on a web site [0005]. Site analytics may use clickstream data collected from a community of internet users to generate and present internet activity metrics [0015]. Metrics of internet activity, which may be called site analytics, may provide analysis that represents aspects of internet user access to a website. Such aspects may include, without limitation, activity related to visitors, engagement, growth, trust, deals, and the like. Data representing a number of visitors, unique visitors, and repeat visitors over a predetermined period of time may be analyzed to generate visitor metrics such as people counts, rank, and visits [0015].)
The Examiner submits that before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify Schlapfer in view of MacIntyre’s communication and analytical processing system to include computing a size of the collection metric as taught by Landa in order to provide an understanding of how people respond to or engage with the site (Landa e.g. [0100]).
As per claim 3 (Original), Schlapfer in view of MacIntyre teach the method of claim 1, Schlapfer in view of MacIntyre do not explicitly teach, however, Landa teaches wherein the computing comprises computing size of the collection, and the method further comprises displaying growth of the collection. (Landa e.g. In addition to determining metrics associated with a period of time, growth may provide important metrics associated with daily changes and may represent velocity of attention, such as changes in daily attention. Metrics of internet activity, which may be called site analytics, may provide analysis that represents aspects of internet user access to a website. Such aspects may include, without limitation, activity related to visitors, engagement, growth, trust, deals, and the like. Data representing a number of visitors, unique visitors, and repeat visitors over a predetermined period of time may be analyzed to generate visitor metrics such as people counts, rank, and visits [0015]. Growth metrics may provide a perspective on how a change or an event associated with a web site may impact visitors and attention [0016]. Growth related metrics may include a velocity metric which may include aspects of engagement, such as daily attention. In an example, velocity metrics may be useful in reporting a relative change in daily Attention. Velocity metrics may facilitate determining growth of a domain. Velocity metrics may represent domain growth over a particular timeframe (e.g. a day, month, or any period of time). Domain growth may be measurable using a velocity metric relative to an initial attention metric. By calculating and presenting velocity metrics for a plurality of web sites, relative growth performance of the sites may be compared. Velocity metrics may facilitate effectively measuring the impact of planned (or unplanned) events, such as new advertising campaigns, product/service launches or general site growth [0111]. FIG. 17 depicts a chart for a growth type site analytic-velocity [0076].)
The Examiner submits that before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify Schlapfer in view of MacIntyre’s communication and analytical processing system to include computing a size of the collection metric and displaying growth of the collection as taught by Landa in order to provide an understanding of how people respond to or engage with the site (Landa e.g. [0100]).
As per claim 4 (Original), Schlapfer in view of MacIntyre and Landa teach the method of claim 2, Schlapfer in view of MacIntyre do not explicitly teach, however, Landa teaches comprising displaying at least one channel performance metric selected from the group comprising revenue attributed to email, email open rate, click rate, and placed order rate. (Landa e.g. This invention relates to methods and systems for collecting, processing, and displaying information related to traffic on a web site [0005]. In the method, the profile metrics are selected from a set consisting of people count, rank, visitors, attention, average stay, page views, and velocity [0037]. Wherein the profile metrics reflect a result of analyzing one or more of real-time clickstream sharing by a plurality of users and a clickstream database [0039]. In a variation of this method, the statistical information is derived from one or more of real-time clickstream sharing and a clickstream data store [0043]. The processed statistical information comprises one or more of user volume, user dwell time, user activity, user purchases, user downloads, click-throughs, click-aways, pageview ranking, user ranking, top search terms, etc. [0045].)
The Examiner submits that before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify Schlapfer in view of MacIntyre’s communication and analytical processing system to include displaying at least one channel performance metric such as click rate and purchases as taught by Landa in order to provide an understanding of how people respond to or engage with the site (Landa e.g. [0100]).
As per claim 14 (Original), Schlapfer in view of MacIntyre teach the system of claim 12, Schlapfer in view of MacIntyre do not explicitly teach, however, Landa teaches wherein the processor is programmed and operable to display growth of the collection responsive to a user selection (See claim 3 response).
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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Ayanna Minor whose telephone number is (571)272-3605. The examiner can normally be reached M-F 9am-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, Jerry O'Connor can be reached at 571-272-6787. 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.
/A.M./Examiner, Art Unit 3624
/Jerry O'Connor/Supervisory Patent Examiner,Group Art Unit 3624