US20230368091A1 - Systems and methods for efficiently distributing alert messages - Google Patents

Abstract

In response to receiving a text describing a news event, a centralized information provider applies semantic rules to the text to determine to which client attributes the text corresponds. The centralized information provider retrieves, from an electronic database, (i) identifiers for multiple clients, (ii) a set of client attributes for each of the clients, and (iii) for each of the clients, an identifier of a respective service provider. The centralized information provider then generates a metric of relevance of the news event for each of the clients, based on the client attributes of the client and the client attributes to which the text was determined to correspond. The centralized information provider transmits, to at least one service provider, an electronic alert message descriptive of the news event and an indication of a set of clients of the service provider for distribution to some or all of the set of clients.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS
• The present application is a divisional of U.S. application Ser. No. 16/340,654, entitled “SYSTEMS AND METHODS FOR EFFICIENTLY DISTRIBUTING ALERT MESSAGES,” and filed Apr. 9, 2019, which was a U.S. National Stage of International Application No. PCT/US2016/056269, entitled “SYSTEMS AND METHODS FOR EFFICIENTLY DISTRIBUTING ALERT MESSAGES,” and filed Oct. 10, 2016.
FIELD OF THE DISCLOSURE
• The following disclosure generally relates to systems and methods for generating and distributing alert messages related to news events and, more particularly, to automatically determining how alerts should be distributed to clients using semantic rule processing.
BACKGROUND
• The background description provided herein is for the purpose of generally presenting the context of the disclosure. Work of the presently named inventors, to the extent it is described in this background section, as well as aspects of the description that may not otherwise qualify as prior art at the time of filing, are neither expressly nor impliedly admitted as prior art against the present disclosure.
• Providers of professional services such as accounting, medicine, law, etc. often notify their clients of relevant industry news, recent practice developments, and changes in technology or regulation. To this end, the providers generally peruse numerous documents from various sources. In some cases, the providers also subscribe to updates from publishers or news aggregators. These updates can relate to a specific topic or area of interest such as taxation, for example. Although subscribing to such updates is generally more efficient than reviewing primary sources, the updates still require that the providers of professional services process a large amount of information to identify specific clients or prospects who may be interested in these updates. Further, the providers and often tailor the presentation of these updates for individual recipients. Still further, to the extent that providers of professional services can deploy various searching or text processing tools, this processing in general is computationally inefficient due to the large number of nodes at which it occurs.
SUMMARY
• This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.
• Generally speaking, a system of this disclosure efficiently distributes electronic alerts related to various events from a centralized information provider to clients via intermediate service providers. To this end, the centralized information provider according to one example implementation receives anonymized datasets specifying various attributes of clients of the service providers, receives “raw” information describing potentially relevant events from various sources, processes the information using semantic rules to automatically identify attributes of the information that correspond to the attributes of the clients, and generates metrics of relevance of the information to the clients. The centralized information provider then distributes electronic alerts descriptive of the received information along with the generated metrics of relevance, so that the service providers can further distribute the alerts to their respective clients in a consistent, reliable and efficient manner. The system of this disclosure thus eliminates the need to process information at multiple network nodes, thereby increasing the overall efficiency of distributing alerts and, more particularly, reducing the processing cost and memory usage at the computing systems of the service providers. Moreover, the centralized information provider can apply a more robust set of semantic rules than the individual service providers to increase the probability of accurately distributing relevant alerts to clients.
• One example embodiment of these techniques is a method for facilitating efficient distribution of electronic alerts to clients via intermediate service providers. The method includes receiving, by one or more processors of a centralized information provider, a text describing a news event. The method further includes receiving, by the one or more processors, semantic rules for processing text, where each of the semantic rules, when satisfied, specifies a correspondence to one or more client attributes, and applying, by the one or more processors, the semantic rules to the text to determine to which client attributes the text corresponds. Still further, the method includes retrieving, by the one or more processors from an electronic database, (i) identifiers for multiple clients, (ii) a set of client attributes for each of the of clients, and (iii) for each of the clients, an identifier of a respective service provider; generating, by the one or more processors for each of the clients, a metric of relevance of the news event based on the client attributes of the client and the client attributes to which the text was determined to correspond; and transmitting, to at least one service provider by the one or more processors, an electronic alert message descriptive of the news event and an indication of a set of clients of the service provider whose metrics of relevance exceed a certain threshold, for distribution to some or all of the set of clients.
• In various implementations, the method described above also includes one or more of the following acts or steps. Transmitting the client attributes to which the text was determined to correspond, along with the alert message and the indication of a set of clients, to the at least one service provider. Providing, to the at least one service provider, a provider user interface that includes at least one of a first control for transmitting a bulk email based on the alert message to some or all of the clients, and a second control for creating internal tasks related to the alert message for a set of clients and linking the set of clients to the alert message for subsequent tracking. Providing, to an operator of the centralized information provider via a workstation, an operator user interface including a control for modifying the semantic rules applied to the news event. Applying the semantic rules via natural language processing (NLP) includes identifying semantic concepts (e.g., “organization,” “monetary value,” or “date”) and various names entities, or certain combinations of semantic concepts within a certain scope such as sentence or paragraph, to trigger appropriate actions. Applying a word search approach instead of NLP includes parsing the text to detect presence of one or more word patterns, wherein each word pattern includes one or more keywords in a specified relative arrangement. Generating, using the client attributes to which the text was determined to correspond, a profile of a potential client for distribution of the news event, and transmitting the profile of the potential client to the at least one service provider. Automatically populating the electronic database with information related to the clients using a set of electronic documents, including parsing the set of electronic documents using second semantic rules.
• Another example embodiment of these techniques is a method for efficiently distributing electronic alerts. The method includes providing, from a computing system associated with a service provider to a centralized information provider via a communication network, anonymized data including respective client attributes for each of multiple clients, each of the attributes selected from a predefined set. The anonymized data according to some implementations is transformed to a semantic representation to allow the centralized information provider to generate alerts more efficiently. The method further includes receiving, from the centralized information provider, an alert for a news event, the alert including (i) a textual component describing the news event and (ii) an indication of clients, selected from among the multiple clients, for which the news event was determined to have a metric of relevance in excess of a certain threshold using the respective client attributes. The method also includes determining, at the computing system, identities of the clients indicated in the received alert; providing a listing of the identified clients via a user interface, including providing a control for selecting or unselecting individual clients for distribution of the alert, and distributing the alert via the communication network to one or more clients selected via the user interface.
• Yet other example embodiments of the techniques of this disclosure are computing systems including processing hardware and a non-transitory computer-readable memory. The memory stores instructions that, when executed by the processing hardware, executes any of the methods discussed above.
• The features and advantages described in this summary and the following detailed description are not all-inclusive. Many additional features and advantages will be apparent to one of ordinary skill in the art in view of the drawings, specification, and claims hereof.
BRIEF DESCRIPTION OF THE DRAWINGS
• The Figures described below depict various aspects of the system and methods disclosed therein. It should be understood that each Figure depicts an embodiment of a particular aspect of the disclosed system and methods, and that each of the Figures is intended to accord with a possible embodiment thereof. Further, wherever possible, the following description refers to the reference numerals included in the following Figures, in which features depicted in multiple Figures are designated with consistent reference numerals.
• There are shown in the drawings arrangements which are presently discussed, it being understood, however, that the present embodiments are not limited to the precise arrangements and instrumentalities shown, wherein:
• FIG.1 is a block diagram of a system in which techniques for distributing client alerts can be implemented;
• FIG.2 is a block diagram of example event detection and client profiling engines, which can be implemented in the system ofFIG.1;
• FIG.3 is a conceptual diagram of example flow of information between different nodes operating in the system ofFIG.1;
• FIG.4 is a flow diagram of an example method for processing events and determining to which clients the corresponding alert is likely to be sent, which can be implemented in the server system illustrated the system ofFIG.1;
• FIG.5 is a flow diagram of an example method for processing events and generating a profile of a hypothetical client that likely will be interested in the alert, which also can be implemented in the server system illustrated the system ofFIG.1;
• FIG.6 is a flow diagram of an example method for receiving operator input and modifying event data in view of the received operator input, which can be implemented in the server system illustrated the system ofFIG.1;
• FIG.7 is a diagram of an example user interface screen for presenting event via an operator interface, which can be implemented in the service provider system illustrated the system ofFIG.1;
• FIG.8 is a flow diagram of an example method for modifying or building an event query using input received via an operator interface, which can be implemented in the server system illustrated the system ofFIG.1;
• FIG.9 is an example method for receiving alerts from a centralized information provider in response to anonymized data, which can be implemented in the service provider system illustrated the system ofFIG.1;
• FIG.10 is an example widget for reviewing received alerts, which can displayed as part of a service provider interface in the system ofFIG.1;
• FIG.11 illustrates an example user interface screen for reviewing event data, which can displayed as part of a service provider interface in the system ofFIG.1; and
• FIG.12 is an example widget for reviewing event criteria, which can displayed as part of a service provider interface in the system ofFIG.1.
DETAILED DESCRIPTIONOverview
• The techniques discussed below can be implemented in an environment in which a centralized information provider such as a publishing company, for example, transmits news alerts to providers of services such as accounting, medical care, legal counseling, etc., which in turn distribute information to their clients that can include individuals, corporations, and other organizations. These techniques reduce the computational complexity associated with identifying relevant information and routing the relevant information via communication networks, improve the overall accuracy of delivering relevant alerts, provide user interfaces that improve efficiency by supporting simultaneous operations upon multiple clients, for example, and provide other technical advantages.
• As discussed below, a server system of the centralized information provider can distribute news alerts along with metadata that specifies, in a probabilistic manner, how the alerts should be further distributed. In other words, the server system specifies anonymous clients and/or profiles of clients that are likely to be interested in the particular alert. The server system can receive information from various sources such as news outlets, press releases, publications by regulatory bodies, etc., and apply semantic rules to the received information to identify various attributes of clients that may be interested in the received information (e.g., “corporation incorporated between 1/1/2016 and 12/31/2016,” “company with annual income of $200,000 or less,” “construction company”). In some scenarios, the server system then uses anonymized data from service providers describing various client attributes to identify clients for potential notification. In other scenarios, the server system automatically generates a profile of a client that probably should be notified, and distributes the profile to various service providers along with an alert based on the received information, for subsequent distribution to relevant clients.
• The server system can provide an interactive user interface (“operator UI”) via which operators of the centralized information provider can review automatically detected events, add or delete attributes of the event, refine automatically created queries or even build new search queries in some cases by specifying various criteria by which clients should be selected for notification, etc. The operators also can use the operator UI to link additional information to the events, create and edit suggested client letters, and generate other event content. More generally, the operators can use the operator UI to modify the content, the timing, and the targets of event notification.
• Further, the server system can provide a different interactive user interface to service providers (“service provider UI”). Using the service provider UI, a service provider can review the news alerts received from the centralized information provider, review the identified matches between the service provider's clients and the news alert, adjust the automatically identified matches to add or delete clients, and begin automatic notification of the clients. The service provider UI can support bulk distribution of alerts to multiple clients, thereby improving efficiency of the corresponding service provider system. In some implementations, a news alert includes suggested text for client notification, and the user interface exposed to the service providers includes controls for reviewing and modifying the suggested text.
• An example computing environment in which these techniques can be implemented in discussed with reference toFIG.1, and example processing engines operating in this computing environment are discussed with reference toFIG.2, followed by a discussion of data flow in the computing environment. Examples methods, operator interfaces that can be provided at the centralized information provider, and service provider interfaces that can be provided as service provider systems are then discussed with reference to the remaining figures.
Example Computing Environment
• Referring toFIG.1, anexample computing environment10 includes aserver system12 associated with an information provider such as a publishing company. Theserver system12 can include one or more servers coupled to acommunication network14, via which theserver system12 can access various sources of information such as public records16 and news sources18. The sources16 and18 can include web sites, mail servers, newsgroups, etc. maintained by government regulatory bodies that post announcements regarding new regulations, industry-specific associations, news outlets, courts, etc. Depending on the implementation, theserver system12 can poll the sources16 and18 for new information according to a certain schedule, such as every hour, or theserver system12 can subscribe to real-time notifications from the sources16 and18.
• Thecomputing environment10 further includesservice provider systems20. Each of thesystems20 can include one or more servers including processor(s) and non-transitory computer-readable memory or, in some implementations, an account associated with a cloud-based service, for example. Thesystems20 can be operated by providers of professional services such as accounting, medical care, etc. Theservice provider systems20 can communicate withclient email services22 via thecommunication network14, where theclient email services22 are operated by various clients or subscribers of the service providers.
• Theserver system12 can be coupled to electronic databases such a client andservice provider database30 storing information related for various services providers and anonymized client data, for example. Anevent repository32 can store event data which theserver system12 generates based on the “raw” information received from the sources16 and18. Asemantic rules database34 stores definitions of various rules which the seversystem12 applies to the raw information and to the anonymized client data to determine relevance of the information to various clients. Each of thedatabases30,32 and34 can be implemented as a separate database or as part of a single database, which can be implemented using any suitable techniques (e.g., using a set of tables interconnected by indices to define a relational database).
• Anexample data record40 stored in theservice provider database30 describes attributes of a certain client. Thedata record40 includes an anonymized client identifier along with an identifier of the service provider with which the client is associated. Although the anonymized client identifier does not reveal identity of the client to theserver system12, the service provider referenced in thedata record40 can use the anonymized client identifier to identify the client. Thedata record40 also includes such example attributes as annual income level of the client, a flag indicating whether the client has more than 50 employees, a field identifying the type of business in which the client is engaged.
• An example data record42 stored in thedatabase32 describes an event processed by theserver system12. The data record42 includes fields to indicate the date associated with the event (e.g., the date when a certain legislative change will come into effect and/or the date when information about upcoming change was received), the type of event, the source of information related to the event, the text to be distributed to service providers in connection with the event, attributes of the event which theserver system12 determines based on the source information, etc.
• With continued reference toFIG.1, theserver system12 includes one ormore processors50 and anon-transitory memory52 readable by the one ormore processors50. Thememory52 can store instructions that implement aclient profiling engine62, anevent detection engine64, and aninterface generator66. Each of theservice provider systems20 also can include one or more processors and a non-transitory memory storing instructions that implement ananonymizer60. The non-transitory memory of theservice provider systems20 also can store web browsers or other applications that allow service providers to access various functions of theserver system12. Theservice provider systems20 can obtain the instructions that implement theanonymizer60 by invoking an appropriate application programming interface (API) function exposed by theserver system12, for example.
• In operation, theservice provider systems20 invoke theanonymizer60 to remove actual client identifiers from client data, replace the client identifiers with temporary identifiers such as alphanumeric strings that appear random, generate a semantic representation of the anonymized data, and provide the semantic representation of the anonymized data to theserver system12. Theserver system12 receives new information from the sources16 and18 and identifies a new event. Theengines62 and64 determine to which anonymized clients the new event corresponds, and theserver system12 generates alert messages for some or all of theserver provider systems20 related to the event. Theinterface generator66 provides anoperator UI70 via which an operator of theserver system12 can adjust event criteria to select or unselect various event attributes, formulate and initiate queries, etc. Theinterface generator66 also can provides a web-based API using which theservice provider systems20 can interact with theserver system12. When invoked, the API can generate service provider UI screens72. In this manner, service providers can review the received alerts and automatically distribute the alerts to clients, for example.
Example Components for Processing Events and Client Data
• Now referring toFIG.2, anexample processing environment100 can be implemented in theserver system12, for example. In general, the components of theprocessing environment100 can be implemented in a single server or multiple servers, possibly disposed remotely from each other.
• Theprocessing environment100 includes anevent detection engine102 in communication with aclient profiling engine104. Theevent detection engine102 includes asemantic rule processor108 and anatural language processor110. Theevent detection engine102 can receive input from, and provide output to, an operator UI106 (which may be similar to theoperator UI70 discussed with reference toFIG.1. Theevent detection engine102 receive data fromvarious data sources 1, 2, . . . N. Referring back toFIG.1, thedata sources 1, 2, . . . N can include the public records16 and the news sources18. These data sources can include text and, in some implementations, other media such as images, audio, video, etc. In some cases,multiple data sources 1, 2, . . . N can provide information which theevent detection engine102 consolidates as a single event (for example, multiple news outlets can report regarding the same development).
• Theevent detection engine102 also receives semantic rules and domain-specific concepts (e.g., fiscal year in the tax document domain, weigh in the medical record domain), which thesemantic rule processor108 uses to determine whether the text received from the data sources includes certain attributes that trigger event notification. More generally, thenatural language processor110 can provide semantic data to thesemantic rule processor108, which then can execute rules to determine whether the idea expressed by the semantic data and the refining characteristics represent an impactful change that should trigger an alert. As part of its output, thenatural language processor110 can specify dates, amounts of money, locations, etc. The semantic rules can be stored in a database such as thedatabase34 illustrated inFIG.1. The semantic rules can be formatted in any suitable manner to specify, for example, that a certain semantic domain concept occurring in the document should cause theevent detection engine102 to assign a certain attribute (e.g., “agricultural regulation”) and refining characteristics to the corresponding event. Thus, a semantic rule can specify that certain semantic data or particular combinations or arrangements of semantic data in a text make it highly probable the text is relevant to companies with income of over $500,000 per year, even if the text does not contain the number $500,000.
• As a more specific example, a federal agency responsible for regulating agricultural production can publish a bulletin on a website specifically designated for this purpose, and theevent detection engine102 can assign certain attributes to the event based on the source of the information. In accordance with additional semantic rules, theevent detection engine102 can assign more specific attributes to the event, such as the type of agricultural activity, whether the new development concerns imports or exports, whether the new development concerns farmers, suppliers, distributors, etc. Further, depending on the implementation or scenario, the semantic rules can specify whether theevent detection engine102 should specifically identify changes to the existing regulation or practices, identify only significant changes to the existing regulations or practices, or trigger on any notifications regarding these regulation or practices.
• Using theoperator UI106, an operator can add, delete or modify the semantic rules, and control application of particular semantic rules to various data sources. The operator in some cases can use theoperator UI106 to override the automatic determination of attributes, remote attributes, or manually remove attributes. Further, theoperator UI106 can allow operators to modify or build queries using attributes.
• In general, using NLP with semantic rules allows theevent detection engine102 to automatically detect ideas expressed in various forms, where the text does not adhere to rigid rules that require specific keywords. For example, thenatural language processor110 can recognize the concept “childcare worker,” and equivalent expressions, where the corresponding regulated code used in standard documents is childcare_worker. Moreover, thenatural language processor110 can identify the concept of “childcare worker” along with names of jurisdictions (e.g., state of New York), dates, and other concepts such as “training” and “compliance,” for example. The arrangement of these semantic concepts can correspond to a certain identifier of a rule that specifies how the resulting expression should be evaluated.
• Theevent detection engine102 generates a list of attributes for an event and provides these attributes to theclient profile engine104. As illustrated inFIG.2, theclient profile engine104 can include a relevancymetric generator120, anautomatic client profiler122, and anAPI124 for retrieving information for matched clients. Theclient profile engine104 in other implementations can include additional components or, conversely, omit some of the components illustrated inFIG.2. Theclient profile engine104 receives client attributes, service provider data as inputs, and commands from theoperator UI106 as inputs. The outputs of theclient profile engine104 can include alert details, indicators of target clients, and a notification template for notifying clients.
• Theautomatic client profiler122 can operate on forms, documents, and other domain-specific artifacts that are transformed to a domain-specific semantic model. Each artifact can be defined as a profile composed of items linked to client attributes. For example, theautomatic client profiler122 processes income tax returns to determine numerous attributes of a client. The income tax returns can conform to a standard electronic format in which data records are populated according to certain documented rules. Similarly, multiple well-documented formats such as HL7 exist today for medical records, and theautomatic client profiler122 can generate a client profile based on anonymized datasets received from hospitals. Thesystem100 also can create semantic models and transform the text accordingly for Health Insurance Portability and Accountability Act (HIPAA) policy documents, compliance checklists, etc. Similar to theevent detection102, theautomatic client profiler122 can apply semantic rules and/or natural language processing to extract client attributes. Once extracted, the client attributes can be stored in thedatabase30 illustrated inFIG.1, for example. Theautomatic client profiler122 can operate in a batch mode to process client data according to a certain schedule and store client attributes for subsequent use, for example, or theautomatic client profiler122 can operate substantially in real time to extract client attributes when a news event becomes available.
• The relevancymetric generator120 can receive event attributes from theevent detection engine102 and compare the event attributes to client attributes generated by theautomatic client profiler122. For example, if one of the attributes of an event is “income under $100,000 per year,” and if the profile of a certain client also includes this attribute, the relevancymetric generator120 can increase the counter of matching attributes. In some implementations, the relevancymetric generator120 assigns weights to the attributes. The relevancymetric generator120 can assign the weights in accordance with the specificity of the attribute, for example. Thus, an attribute which many clients share (e.g., state of incorporation=“Delaware”) may have a lower weight than an attribute that relatively few clients share (e.g., business type=“dance studio”).
• Some of the semantic rules theevent detection engine102 and/or theclient profiling engine104 applies can correspond to event criteria defined by operators and/or stored in a database. For example, a certain event criterion can be that the new information concerns companies with the primary production losses claimed in the last income year being over $50,000. The corresponding rule specifies which semantic concepts, and in what relative arrangement, satisfy this criterion. Further, an event criterion can be parameterized by a number to allow approximate matches and hear-hits. To continue with the example above, $50,000 can be a parameter of the criterion “a company with the primary production losses claimed in the last income year being over X.” Applying the corresponding semantic rule, theevent detection engine102 can detect a reference to primary production losses claimed in the last income year being over $40,000. Theevent detection engine102 then can determine how close the value $40,000 is to the parameter $50,000, and generate an indication of an approximate match. Alternatively, theevent detection engine102 can detect a match between the event attribute and the client attribute, but assign a weight to the match in proportion to the amount of error defined by the difference between $40,000 and $50,000.
• Based on the overlap between event attributes and client attributes, the relevancymetric generator120 can determine whether the event is likely to be of interest to the client. In some implementations, the relevancymetric generator120 can compare the number of matched attributes to the overall number of client attributes and/or the overall number of event attributes. For example, in order for the relevancymetric generator120 to determine that the event is likely to be of interest to the client, the ratio of matched attributes N to the overall number of attributes available to the client M must exceed a certain threshold number T, according to one embodiment. In some embodiments, the threshold number T is set individually for each event.
• With continued reference toFIG.2, service providers can invoke theAPI124 to identify clients to generate email notifications for individual or multiple clients, in accordance with commands received from theoperator UI106. For example, an operator can edit the text of an alert, and theAPI124 additionally can generate a notification template that includes the text and the attributes of clients to which the text can be distributed.
Example Data Flow in a System for Distributing Alert Messages
• For further clarity,FIG.3 schematically illustrates the flow of data in theenvironment10 or a similar computing environment. Atopology150 includes aninformation provider152 communicates withservices providers154A,154B, etc., each of which in turn communicate withrespective client systems160A-C,160D-160F, etc. These entities can be similar to those that operate theservice system12, theservice provider systems20, andclient email services22, respectively (seeFIG.1).
• As illustrated inFIG.1, semantic representation of anonymized client data travels “upstream” in thetopology150 fromservice providers154A and154B, for example. An alert message including event information and metadata specifying anonymous clients, client profiles, matched attributes, etc. travels “downstream” from theinformation provider152 to theservice providers154A and154B, and event information travels to some of theclient systems160A-F.
• It is noted that this arrangement advantageously allows semantic processing of events to occur at a single node, theinformation provider152, thereby reducing computational load at the other nodes. In other words, this arrangement eliminates the need to perform similar operations, often applied to the same data, at theservice providers154A and154B to determine event attributes.
• Moreover, the arrangement ofFIG.3 defines a probabilistic routing scheme in which an alert message is transmitted to an intermediate node (e.g., fromservice provider154A154A) along with a list of probable recipients of the alert message, or endpoints. Theintermediate node154A thus receives information regarding recommended subsequent routing of the alert message, but theintermediate node154A does not always forward the alert message to every endpoint identified by theinformation provider152. Still further, although theinformation provider152 can identify the attributes of the ultimate recipient of the alert message, the information provider152 (at least in some embodiments) is not aware of the identities of these ultimate recipients.
Example Operator Methods and User Interfaces
• Now referring toFIG.4, anexample method200 for processing events and determining to which clients the corresponding alert is likely to be sent can be implemented in theserver system12 ofFIG.1, for example, or another suitable system. Themethod200 can be implemented as a set of instructions stored on a non-transitory computer-readable medium and executable by one or more processors, for example.
• Themethod200 begins atblock202, where text describing a potential news event is received. As discussed above, the text can be received from any suitable source (e.g., the source16 or18 ofFIG.1) and, in some cases, multiple texts can be received from different sources for the same event.
• Atblocks204 and206, the semantic rules for processing text are obtained and applied to the text, respectively. Each semantic rule can require that one or more semantic concepts be present in the text in a particular relative arrangement, and specify an attribute to be assigned to the event if the semantic rule is satisfied. The semantic rules can be defined for a particular domain or industry, such as “construction” or “hospitality services,” so that the same semantic concept match generates different attributes for different industries. If desired, the system in which themethod200 is implemented can use both semantic rules and natural language processing to extract event attributes.
• Atblock208, client data specifying client attributes is retrieved. In some embodiments, the client data is anonymized. A module such as theautomatic client profiler122 ofFIG.2 can process client dataset in an offline (batch) mode at an earlier time and populate a database (e.g., thedatabase30 illustrated inFIG.1). More generally, block208 in various embodiments can be executed prior toblocks202 and204, afterblocks202 and204, or in parallel withblocks202 and204.
• Once both the client attributes and the event attributes are available, metrics of relevance of the news event are generated for various clients atblock210. At discussed above, each metric can reflect the number of client attributes that match event attributes, and some of the attributed can be assigned higher weights.
• Atblock212, a set of clients with metrics exceeding a certain threshold value are identified. The threshold value can be defined in absolute terms (e.g., “5 or more matching attributes”), relative terms (e.g., “60% or more of the event attributes match client's attributes), or in any other suitable manner.
• Atblock214, an alert message that includes a description of the news event as well as indications regarding the proposed distribution of the alert message is transmitted to one or more service providers. The description of the news event in some cases can be automatically generated based on the text received atblock202. In other cases, an operator can manually edit the description via operator UI (e.g.,operator UI106 discussed with reference toFIG.2). The indications regarding the proposed distribution of the alert message can include anonymized references to clients, which the corresponding service providers can use to determine client identity.
• In some cases, however, specific clients cannot be identified for alert distribution due to unavailability of client data, for example, or because none of the clients in the available dataset have the sufficient number of client attributes matching the event attributes for a certain news event. Referring toFIG.5, amethod250 is generally similar to themethod200, except that a client profile rather than identifiers of clients is transmitted to one or more service providers.
• In particular, blocks252-256 are similar to blocks202-206 discussed above. Atblock258, a subset of the identified event attributes is selected in view of respective attribute weights, and a client profile is generated based on the selected event attributes atblock260. The attribute weights are the same for all attributes according to one implementation of themethod250. In some embodiments, the client profile includes all of the identified event attributes.
• Atblock262, an alert message with a description of the event along with the generated client profile is transmitted to one or more service providers. The service providers then can use the received client to automatically identify clients for alert distributions using a dataset that was not exposed to the centralized information provider, for example.
• Next,FIG.6 depicts a flow diagram of anexample method300 or receiving operator input and modifying event data in view of the received operator input, which theserver system12 ofFIG.1 can implement using software instructions, for example. Referring back toFIG.2, operator input and output can be received via theoperator UI106.
• Atblocks302 and304, listings of recently detected source documents and recently detected events are provided via the operator interface. It is noted that not every source document necessarily includes semantic concepts which theevent detection engine102, for example (seeFIG.2) can identify as matching one or more semantic rules or recognize using natural language processing. Accordingly, in one implementation, the operator UI lists both the source documents that were automatically recognized as a basis for a news event and source documents that were not used in generating the news event. The operator can review the documents of both types and, if desired, override the results of the automatic processing.
• The operator can modify the event criteria atblock306. For example, the operator can add, remove, or edit the event criteria so as to modify the attributes assigned to the event. In response, the system can modify the event data in accordance with the operator input atblock308.
• FIG.7 illustrates an exampleuser interface screen400, which theoperator UI70 or106 (seeFIGS.1 and2) can provide to an operator of the centralized information provider to review a particular event. In an example scenario, the operator UI presents a searchable list of current and past events to the operator, and generates thescreen400 in response to the operator selecting one of these events.
• Thescreen400 can indicate the status of the event (e.g., Released, Pending, Deleted) at the centralized information provider. In this example scenario, the event has already been released to service providers. Thescreen400 also indicates the type of event (in this case, Legislative Change), the title of the event, create and last modification dates, the source(s) of the event, the name of the contributor, and a brief description. More generally, thescreen400 can display any desired number of informational fields for each event.
• As illustrated inFIG.7, theexample screen400 further includes tabs under which respective groups of functions and informational fields are organized. Under the Details tab, activated in the view depicted inFIG.7, the operator can access source documents both in the original and the enriched, or annotated, format. For example, the source document can be the original text of a relevant court decision, and the annotated format can display the semantic concepts which theevent detection engine102 or a similar component detected, various dates and numbers identified in the source document, etc. Further, the Details tab can include an interactive list of terms mentioned in the event and an interactive list of broader concepts detected in the event. The operator can selectively delete and add these terms and concepts.
• The Related Events tab can include links to other events to allow the operator to review and modify the listing of events that were determined to be related. For example, theevent detection engine102 can determine that two recent events share multiple event attributes and automatically cross-reference these events for the operator. The Event Criteria tab can include an interactive listing of event criteria which the operator can review and adjust.
• For example, to allow the operator to modify event criteria, theserver system12 ofFIG.1 can implement anexample method450. Themethod450 begins atblock452, where a request to modify event criteria is received in response to the operator activating the Event Criteria, for example. Atblock454, an interactive interface for modifying or building a query is presented. The interactive query interface can include controls for specifying event criteria and the relationships between the criteria. For example, the operator can specify that he or she wishes to search for clients shoe individual tax returns indicate one of: net primary production income/less is 2.1, share of net income from trusts is 10%, primary production losses claimed this income year is $50,000, etc. In one embodiment, these criteria are predefined and stored in the database, with the operator only supplying numerical parameters (2.1, 10%, $50,000, etc.). The relationships between the criteria the operator selects can include, for example, “should have at least one of,” “must have all of,” or “should have at least one of.”
• Atblock456, the selections of attributes is received, and the query is executed in accordance with the selected attributes to obtain a set of matching clients atblock458. The obtained set can be used in alert distribution atblock460.
Example Service Provider Methods and User Interfaces
• FIG.9 depicts is a flow diagram of anexample method500 for receiving alerts from a centralized information provider in response to anonymized data, which can be implemented in one of theservice provider systems20 ofFIG.1, for example. Similar to the other methods of this disclosure, themethod500 can be implemented as a set of instructions stored on a computer-readable medium and executable by one or more processors.
• Themethod500 begins atblock502, where a semantic representation of an anonymized client data is provided to centralized information provider. The anonymized client data can include, for example, income tax statements in a standard, computer-parseable electronic format, with the data identifying clients replaced with temporary identifiers. Atblock504, a news alert is received from the centralized information provider. The news alert can include a textual component (and, if desired, other media such as images) along with metadata for determining which clients of the service provider are likely to be interested in the news alert. The metadata can include temporary identifiers of clients, supplied as part of the anonymized client data. Additionally or alternatively, the metadata can include a client profile listing multiple attributes of a fictitious client potentially interested in the news alert.
• Atblock506, a service operator UI is provided as part of a web-based interface, for example. Next, distribution commands are received via the service operator UI atblock508, and the news alert is distributed in accordance with the received distribution commands atblock510.
• For additional clarity,FIG.10 illustrates anexample widget500 which the service operator UI can provide for reviewing received alerts. The widget550 includes a listing of events received from the centralized information provider, an indication of how many clients of the service provider have been matched to the event based on their attributes, the date on which the events were announced, etc. The example widget550 allows the service provider to rank the events based on the number of matched clients.
• Thus, the service provider can determine how many clients are potentially impacted by the news alert using the received metadata, without analyzing the news event locally. Moreover, the metadata allows the service provider UI to automatically prioritize the alert messages based on the number of potentially impacted clients.
• Next,FIG.11 illustrates an exampleuser interface screen600 which the service provider UI can generate for reviewing event data. For each event, thescreen600 can include an event description, a client profile, a proposed client impact statement and a proposed client letter received from the centralized information provider, etc. The service provider can use the functions accessible via thescreen600 to modify the profiles of clients to which the news alert will be distributed, the text the clients will receive, etc.
• Further, as illustrated inFIG.12, the service provider can view the event criteria detected at the centralized information provider and, if desired, override these criteria. Anexample widget650 can be provided as part of the service provider UI and can include a listing of individual event criteria and indications of how many clients have matching client criteria. In this example scenario, thewidget650 indicates that the event the service provider is reviewing in thescreen600 is applicable to companies with accessible income of $200,000 or less, companies who claimed a research and development offset, etc. In some implementations, the service provider can both override some or all of these event criteria and generate feedback for the centralized information provider. The centralized information provider in turn can generate an appropriate alert for an operator if a certain number or percentage of the service providers disagree with a certain event criterion.
Additional Considerations
• The following additional considerations apply to the foregoing discussion. Throughout this specification, plural instances may implement functions, components, operations, or structures described as a single instance. Although individual functions and instructions of one or more methods are illustrated and described as separate operations, one or more of the individual operations may be performed concurrently, and nothing requires that the operations be performed in the order illustrated. Structures and functionality presented as separate components in exemplary configurations may be implemented as a combined structure or component. Similarly, structures and functionality presented as a single component may be implemented as separate components. These and other variations, modifications, additions, and improvements fall within the scope of the subject matter herein.
• For example, the network may include, but is not limited to, any combination of a LAN, a MAN, a WAN, a mobile, a wired or wireless network, a private network, or a virtual private network. Moreover, it is understood that any number of client computers or display devices are supported and may be in communication with thedata system104.
• Additionally, certain embodiments are described herein as including logic or a number of functions, components, modules, blocks, or mechanisms. Functions may constitute either software modules (e.g., non-transitory code stored on a tangible machine-readable storage medium) or hardware modules. A hardware module is a tangible unit capable of performing certain operations and may be configured or arranged in a certain manner. In example embodiments, one or more computer systems (e.g., a standalone, client or server computer system) or one or more hardware modules of a computer system (e.g., a processor or a group of processors) may be configured by software (e.g., an application or application portion) as a hardware module that operates to perform certain operations as described herein.
• Accordingly, the term hardware should be understood to encompass a tangible entity, which may be one of an entity that is physically constructed, permanently configured (e.g., hardwired), or temporarily configured (e.g., programmed) to operate in a certain manner or to perform certain operations described herein. Considering embodiments in which hardware modules are temporarily configured (e.g., programmed), each of the hardware modules need not be configured or instantiated at any one time. For example, where the hardware modules comprise a general-purpose processor configured using software, the general-purpose processor may be configured as respective different hardware modules at different times. Software may accordingly configure a processor, for example, to constitute a particular hardware module at one instance of time and to constitute a different hardware module at a different instance of time.
• Hardware and software modules may provide information to, and receive information from, other hardware and/or software modules. Accordingly, the described hardware modules may be regarded as being communicatively coupled. Where multiple of such hardware or software modules exist contemporaneously, communications may be achieved through signal transmission (e.g., over appropriate circuits and buses) that connect the hardware or software modules. In embodiments in which multiple hardware modules or software are configured or instantiated at different times, communications between such hardware or software modules may be achieved, for example, through the storage and retrieval of information in memory structures to which the multiple hardware or software modules have access. For example, one hardware or software module may perform an operation and store the output of that operation in a memory device to which it is communicatively coupled. A further hardware or software module may then, at a later time, access the memory device to retrieve and process the stored output. Hardware and software modules may also initiate communications with input or output devices, and may operate on a resource (e.g., a collection of information).
• The various operations of exemplary functions and methods described herein may be performed, at least partially, by one or more processors that are temporarily configured (e.g., by software) or permanently configured to perform the relevant operations. Whether temporarily or permanently configured, such processors may constitute processor-implemented modules that operate to perform one or more operations or functions. The modules referred to herein may, in some exemplary embodiments, comprise processor-implemented modules.
• Similarly, the methods or functions described herein may be at least partially processor-implemented. For example, at least some of the functions of a method may be performed by one or more processors or processor-implemented hardware modules. The performance of certain of the functions may be distributed among the one or more processors, not only residing within a single machine, but deployed across a number of machines. In some exemplary embodiments, the processor or processors may be located in a single location (e.g., within a home environment, an office environment or as a server farm), while in other embodiments the processors may be distributed across a number of locations.
• The one or more processors may also operate to support performance of the relevant operations in a “cloud computing” environment or as a “software as a service” (SaaS). For example, at least some of the functions may be performed by a group of computers (as examples of machines including processors). These operations are accessible via a network (e.g., the Internet) and via one or more appropriate interfaces (e.g., application program interfaces (APIs)).
• The performance of certain operations may be distributed among the one or more processors, not only residing within a single machine, but deployed across a number of machines. In some exemplary embodiments, the one or more processors or processor-implemented modules may be located in a single geographic location (e.g., within a home environment, an office environment, or a server farm). In other exemplary embodiments, the one or more processors or processor-implemented modules may be distributed across a number of geographic locations.
• Some portions of this specification are presented in terms of algorithms or symbolic representations of operations on data and data structures stored as bits or binary digital signals within a machine memory (e.g., a computer memory). These algorithms or symbolic representations are examples of techniques used by those of ordinary skill in the data processing arts to convey the substance of their work to others skilled in the art. As used herein, a “function” or an “algorithm” or a “routine” is a self-consistent sequence of operations or similar processing leading to a desired result. In this context, functions, algorithms, routines and operations involve physical manipulation of physical quantities. Typically, but not necessarily, such quantities may take the form of electrical, magnetic, or optical signals capable of being stored, accessed, transferred, combined, compared, or otherwise manipulated by a machine. It is convenient at times, principally for reasons of common usage, to refer to such signals using words such as “data,” “content,” “bits,” “values,” “elements,” “symbols,” “characters,” “terms,” “numbers,” “numerals,” or the like. These words, however, are merely convenient labels and are to be associated with appropriate physical quantities.
• Unless specifically stated otherwise, discussions herein using words such as “processing,” “computing,” “calculating,” “determining,” “presenting,” “displaying,” or the like may refer to actions or processes of a machine (e.g., a computer) that manipulates or transforms data represented as physical (e.g., electronic, magnetic, or optical) quantities within one or more memories (e.g., volatile memory, non-volatile memory, or a combination thereof), registers, or other machine components that receive, store, transmit, or display information.
• As used herein any reference to “some embodiments” or “one embodiment” or “an embodiment” means that a particular element, feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. The appearances of the phrase “in one embodiment” in various places in the specification are not necessarily all referring to the same embodiment.
• Some embodiments may be described using the expression “coupled” and “connected” along with their derivatives. For example, some embodiments may be described using the term “coupled” to indicate that two or more elements are in direct physical or electrical contact. The term “coupled,” however, may also mean that two or more elements are not in direct contact with each other, but yet still co-operate or interact with each other. The embodiments are not limited in this context.
• As used herein, the terms “comprises,” “comprising,” “includes,” “including,” “has,” “having” or any other variation thereof, are intended to cover a non-exclusive inclusion. For example, a function, process, method, article, or apparatus that comprises a list of elements is not necessarily limited to only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Further, unless expressly stated to the contrary, “or” refers to an inclusive or and not to an exclusive or. For example, a condition A or B is satisfied by any one of the following: A is true (or present) and B is false (or not present), A is false (or not present) and B is true (or present), and both A and B are true (or present).
• In addition, use of the “a” or “an” are employed to describe elements and components of the embodiments herein. This is done merely for convenience and to give a general sense of the description. This description should be read to include one or at least one and the singular also includes the plural unless it is obvious that it is meant otherwise.
• Still further, the figures depict preferred embodiments of acomputer system100 for purposes of illustration only. One of ordinary skill in the art will readily recognize from the following discussion that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles described herein.
• Upon reading this disclosure, those of skill in the art will appreciate still additional alternative structural and functional designs for a system and a process for efficiently distributing alert messages through the disclosed principles herein. Thus, while particular embodiments and applications have been illustrated and described, it is to be understood that the disclosed embodiments are not limited to the precise construction and components disclosed herein. Various modifications, changes and variations, which will be apparent to those skilled in the art, may be made in the arrangement, operation and details of the method and apparatus disclosed herein without departing from the spirit and scope defined in the appended claims.

Claims (18)

What is claimed is:

1. A method for efficiently distributing electronic alerts, the method comprising:

providing, from a computing system associated with a service provider to a centralized information provider via a communication network, anonymized data including respective client attributes for each of a plurality of clients, each of the attributes selected from a predefined set;

receiving, from the centralized information provider, an alert message for a news event, the alert message including (i) a textual component describing the news event and (ii) an indication of clients, selected from among the plurality of clients, for which the news event was determined to have a metric of relevance in excess of a certain threshold using the respective client attributes;

determining, at the computing system, identities of the clients indicated in the received alert;

providing a listing of the identified clients via a user interface, including providing a control for selecting or unselecting individual clients for distribution of the alert; and

distributing the alert via the communication network to one or more clients selected via the user interface.

2. The method ofclaim 1, wherein receiving the alert message further includes receiving a set of event attributes which the centralized information provider determined for the news event.

3. The method ofclaim 2, wherein providing the listing of the identified clients via the user interface includes providing, for each of the clients, those of the client attributes that match the client attributes.

4. The method ofclaim 1, further comprising:

receiving a plurality of alert messages for a plurality of respective news events, including receiving, for each of the plurality of alert messages an indication of clients for which the news event was determined to have a metric of relevance in excess of a certain threshold; and

listing the plurality of alert messages via the user interface in accordance with numbers of clients for the news event was determined to have a metric of relevance in excess of a certain threshold.

5. The method ofclaim 1, further comprising:

receiving a text template for distributing as part of the alert to the one or more clients, and

providing an interactive control for editing the text template.

6. The method ofclaim 1, further comprising receiving a profile of a potential client for distribution of the news event, the profile including a set of attributes.

7. A system, comprising:

one or more processors; and

a non-transitory computer-readable memory storing thereon instructions that, when executed by the one or more processors, cause the system to:

provide, to a centralized information provider via a communication network, anonymized data including respective client attributes for each of a plurality of clients, each of the attributes selected from a predefined set;

receive, from the centralized information provider, an alert message for a news event, the alert message including (i) a textual component describing the news event and (ii) an indication of clients, selected from among the plurality of clients, for which the news event was determined to have a metric of relevance in excess of a certain threshold using the respective client attributes;

determine identities of the clients indicated in the received alert;

provide a listing of the identified clients via a user interface, including providing a control for selecting or unselecting individual clients for distribution of the alert; and

distribute the alert via the communication network to one or more clients selected via the user interface.

8. The system ofclaim 7, wherein receiving the alert message further includes receiving a set of event attributes which the centralized information provider determined for the news event.

9. The system ofclaim 8, wherein providing the listing of the identified clients via the user interface includes providing, for each of the clients, those of the client attributes that match the client attributes.

10. The system ofclaim 7, wherein the instructions, when executed by the processing hardware, further cause the system to:

receive a plurality of alert messages for a plurality of respective news events, including receiving, for each of the plurality of alert messages an indication of clients for which the news event was determined to have a metric of relevance in excess of a certain threshold; and

list the plurality of alert messages via the user interface in accordance with numbers of clients for the news event was determined to have a metric of relevance in excess of a certain threshold.

11. The system ofclaim 7, wherein the instructions, when executed by the processing hardware, further cause the system to:

receive a text template for distributing as part of the alert to the one or more clients, and

provide an interactive control for editing the text template.

12. The system ofclaim 7, wherein the instructions, when executed by the processing hardware, further cause the system to:

receive a profile of a potential client for distribution of the news event, the profile including a set of attributes.

13. A non-transitory computer-readable memory storing thereon instructions that, when executed by one or more processors, cause the one or more processors to:

provide, to a centralized information provider via a communication network, anonymized data including respective client attributes for each of a plurality of clients, each of the attributes selected from a predefined set;

receive, from the centralized information provider, an alert message for a news event, the alert message including (i) a textual component describing the news event and (ii) an indication of clients, selected from among the plurality of clients, for which the news event was determined to have a metric of relevance in excess of a certain threshold using the respective client attributes;

determine identities of the clients indicated in the received alert;

provide a listing of the identified clients via a user interface, including providing a control for selecting or unselecting individual clients for distribution of the alert; and

distribute the alert via the communication network to one or more clients selected via the user interface.

14. The non-transitory computer-readable memory ofclaim 13, wherein receiving the alert message further includes receiving a set of event attributes which the centralized information provider determined for the news event.

15. The non-transitory computer-readable memory ofclaim 14, wherein providing the listing of the identified clients via the user interface includes providing, for each of the clients, those of the client attributes that match the client attributes.

16. The non-transitory computer-readable memory ofclaim 13, wherein the instructions, when executed by the processing hardware, further cause the one or more processors to:

receive a plurality of alert messages for a plurality of respective news events, including receiving, for each of the plurality of alert messages an indication of clients for which the news event was determined to have a metric of relevance in excess of a certain threshold; and

list the plurality of alert messages via the user interface in accordance with numbers of clients for the news event was determined to have a metric of relevance in excess of a certain threshold.

17. The non-transitory computer-readable memory ofclaim 13, wherein the instructions, when executed by the processing hardware, further cause the one or more processors to:

receive a text template for distributing as part of the alert to the one or more clients, and

provide an interactive control for editing the text template.

18. The non-transitory computer-readable memory ofclaim 13, wherein the instructions, when executed by the processing hardware, further cause the one or more processors to:

receive a profile of a potential client for distribution of the news event, the profile including a set of attributes.

Images