EP2084891A2 - Procédé et appareil pour envoyer une notification aux abonnés d'événements demandés - Google Patents

Procédé et appareil pour envoyer une notification aux abonnés d'événements demandés

Info

Publication number
EP2084891A2
EP2084891A2 EP07854468A EP07854468A EP2084891A2 EP 2084891 A2 EP2084891 A2 EP 2084891A2 EP 07854468 A EP07854468 A EP 07854468A EP 07854468 A EP07854468 A EP 07854468A EP 2084891 A2 EP2084891 A2 EP 2084891A2
Authority
EP
European Patent Office
Prior art keywords
subscriber
event
database
procedure
notification
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP07854468A
Other languages
German (de)
English (en)
Inventor
Raymond C. Cole
Shawn M. Constance
Kyle S. Goodwin
Joshua Bruce Harrison
William R. Morris
John Julius Shilling
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Aflac Inc
Original Assignee
American Family Life Assurance Company of Columbus AFLAC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by American Family Life Assurance Company of Columbus AFLAC filed Critical American Family Life Assurance Company of Columbus AFLAC
Publication of EP2084891A2 publication Critical patent/EP2084891A2/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/42136—Administration or customisation of services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/30—Profiles
    • H04L67/306—User profiles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M11/00—Telephonic communication systems specially adapted for combination with other electrical systems
    • H04M11/04—Telephonic communication systems specially adapted for combination with other electrical systems with alarm systems, e.g. fire, police or burglar alarm systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2203/00—Aspects of automatic or semi-automatic exchanges
    • H04M2203/20—Aspects of automatic or semi-automatic exchanges related to features of supplementary services
    • H04M2203/2072—Schedules, e.g. personal calendars
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M7/00—Arrangements for interconnection between switching centres
    • H04M7/0024—Services and arrangements where telephone services are combined with data services
    • H04M7/0036—Services and arrangements where telephone services are combined with data services where the data service is an information service

Definitions

  • the present invention relates to notifying persons of the occurrence of selected incoming events.
  • Subscriber profiles stored in a database, contain data concerning at least one specified event of which a subscriber wishes to be notified and a procedure by which the subscriber prefers to be notified.
  • data is extracted from the incoming event and the database is queried using the extracted data to identify at least one subscriber whose subscriber profile includes at least one item of the extracted data and the procedure by which the identified subscriber prefers to be notified of the incoming event.
  • An event notification is then prepared for the incoming event in accordance with the determined procedure for the identified subscriber and the event notification is sent to the identified subscriber in accordance with the determined procedure.
  • Figure 1 is a block diagram of an exemplary event notification system in an exemplary environment.
  • Figure 2 is an exemplary flow chart illustrating the process of the exemplary event notification system.
  • Figure 3 is an exemplary flow chart illustrating the process of the subscriber inputting conditions and preferences.
  • This event notification system allows field force personnel and other interested, authorized personnel (collectively, "subscribers") to receive real-time notification of events of interest or importance to them.
  • a subscriber chooses events of interest, and details regarding the events of interest. For example, a subscriber may choose to be notified of all events relating to a particular policy number. As another example, a subscriber may choose to be notified of all events relating to the issuance of a new policy.
  • the subscriber may want to limit such notices to particular areas of interest. For example, the subscriber may want to be notified of all events relating to the issue of a new policy, but only in a particular part of the country, or a particular state, county, city, country, or territory. These choices, also called “conditions" herein, are stored in a subscriber database.
  • notification of certain events may or may not be a "choice" of the person, but may be directed by company policy, procedure, or need.
  • the company may issue a memo advising that a particular office will be closed on a particular date or dates due to a local holiday or office move, due to damage from a storm, flood, or lightning strike, etc.
  • Such an important memo may be directed to some or all personnel so it is preferred that the personnel not have the option of altering the conditions so as not to receive the notification regarding that memo.
  • the subscriber can also choose the desired notification method, for example, but not limited to, a telephone call, preferably using voice synthesis, text messaging/short messaging service (SMS), email, and/or a personal web-based company portal.
  • a telephone call the subscriber can also choose the hours within which the notification can be delivered.
  • SMS text messaging/short messaging service
  • These notification preferences are also stored in the subscriber database.
  • subscribers are notified of selected incoming events, such as fax or a memo.
  • memo is used broadly herein, and generally includes any document intended to notify someone of something, including, but not limited to, a memorandum, a notice, an instruction, an announcement, a request, etc.
  • a memo is typically, but not necessarily, generated internally, that is, it may, but preferably does not, come from outside the company.
  • an incoming event occurs, such as a new memo
  • the fields to be examined are predetermined.
  • the subscriber database is then queried for the extracted data in the conditions field in the database. This query is preferably done for each item of extracted data so as to provide a list of subscribers who are interested in any particular aspect of the incoming event.
  • the subscriber database may have an index which indicates which conditions that subscribers have selected. The index is then queried for the extracted data to provide a list of the interested subscribers.
  • a list is generated of interested subscribers, i.e., those subscribers who wish to be (or must be) notified of the incoming event.
  • the notification preferences of each subscriber are then examined to determine how the subscriber wishes to be notified.
  • the incoming event, or one or more sections thereof, or a summary thereof, or some information pertaining thereto, or an index or reference thereto, or even some or all of the relevant data therein (collectively "event notification data”) is then sent to the interested subscriber. If a notification preference is by a telephone call then the subscriber preferably can also specify during which hours the call may be placed (or should not placed).
  • the subscriber's conditions and preferences are stored in a subscriber profile database. If used, the index of conditions may also be stored in the subscriber profile database, or may be stored separately.
  • Some events may contain confidential data which should not be sent over an insecure communications link. Therefore, preferably, only a limited amount of non- confidential data is sent when there is an event which contains confidential data and the notification method is insecure.
  • a company-owned, username and password- protected web site or intranet may be considered to be secure, other methods of communication, such as e-mail, fax, and even voice transmissions, are generally not considered to be secure.
  • the subscriber may also choose certain "negative" conditions, and a subscriber will not be notified of the event if that negative condition exists. For example, the subscriber may want to be notified of all events relating to the issue of a new policy, but not if the policy is to be issued in a particular state, county, city, country, territory, etc. As another example, a subscriber may want to be notified of all events relating to the issue of new policy for a particular product, but not if it includes other products. "Negative conditions” may also include range limitations, whether inclusive or exclusive, such as, but not limited to, a change greater than (less than) 5% with respect to the prior status, etc.
  • an event may relate to insurance policies, an event is not limited to such and may include other actions, documents, occurrences, etc., of which a person may wish to be notified.
  • Some other types of events are those relating to: service contracts; supply contracts; the use by banking or stock brokerage customers to have notifications of deposits, withdrawals, overdrafts with respect to their accounts, and notifications of opening and closing of those or affiliated accounts; the use by individuals, or companies, relating to their credit reports, such as a sale by a credit bureau of the credit status, including when a creditor or anyone else makes a request for a credit report, creditworthiness, or other information, or when the credit score is changed, whether favorably or unfavorably, the entry of new information or updated information into the credit report; the use by students, relating to their status at schools, colleges and universities, such as to have notification for registration in classes, payment or lack thereof for tuition, books and fees, publication of grades for courses taken, status of their transcript, status or change in requirements for graduation, entry or new or updated information; the use by pensioners, with respect to their pension plans and their pension providers, of the status of their personal and/or corporate retirement plan, changes in investment strategy or holding
  • condition should be understood to include any field, data, or term which can be defined and used to determine whether an event notification is appropriate, such as, but not limited to, name, street number, street address, city, county, state, ZIP code, territory, country, telephone number, fax number, area code, e-mail address, e-mail domain name, policy number, contract number, credit report reference number, student identification number, pension plan number, date, time, dollar amount, type of policy, group name or number, individual employee name or number, or other customer information, such as an SIC code, etc.
  • subscriber 4 wishes to be notified of all events relating to policy number 12345 and all events relating to Colorado.
  • Memo A advises that a new policy has been issued in Georgia; memo B advises that policy number 12345 has just been renewed in Georgia; memo C advises that Colorado policy number 13579 has lapsed; and a fax D has been received from telephone number 404-555-1212.
  • Predetermined fields in the various memos will be inspected and the data extracted therefrom. For example, memo A has the data "new policy” in a subject field, "Georgia” in a location field, and "memo" in an event type field; memo B has the data "Georgia” in the location field, policy no.
  • memo C has the data "Colorado” in the location field, "policy lapse” in the subject field, “13579” in the policy number field, and “memo” in the event type field; and the fax has the data "404-555-1212" in a telephone number field and "fax" in the event type field.
  • the above fields and names are exemplary and other fields and/or different field names may be used, as desired.
  • the subscriber profile data would, in this example, indicate as follows: [0023] Location: CO (subscriber 4); GA (subscriber 1);
  • Telephone # Area Code 404 (subscribers 2 and 3).
  • Subscriber 2 will receive notification of fax D;
  • Subscriber 3 will receive notification of memo B and fax D;
  • Subscriber 4 will receive notification of memos B and C.
  • the event notification system provides timely and efficient notice of events which are of interest or importance to a subscriber.
  • FIG. 1 is a block diagram of an exemplary event notification system 10 in an exemplary environment.
  • An event generator 8 generates events (memo, fax, etc.).
  • the event generator is typically not a single device, but represents several, usually distinct and independent, devices.
  • the event generator will typically comprise at least a fax receiving machine, and a document generator program, such as a word processing, spreadsheet, or presentation program.
  • the fax receiving machine will, upon receiving a fax, forward it to the system 10 for processing and storage.
  • Companies typically generate numerous memos, usually starting in draft form, being revised one or more times, and then finally being released.
  • the document generator will forward it to the system 10 for processing and storage or, if the memo is stored, even in unreleased, draft form on the system 10, then the document generator will add a flag, or set a flag, indicating that the document has been released. Determination of when a memo is final, and the decision to release it, is typically done manually. Nonetheless, when the memo is marked final and released, that document is forwarded to the system 10 and/or a flag is set so alert the system that the document is ready to be processed as an event. It should be understood that documents, memos, faxes, emails, etc., with respect to the system 10, are in electronic form. [0033] In the exemplary embodiment shown, the system 10 comprises an event input queue 11.
  • all incoming events are placed in this queue and processed sequentially.
  • the incoming event is forwarded to the database manager 13 for further action, if appropriate, and for storage.
  • the queue 11 immediately forwards the incoming event to the database manager 13 for storage and later action.
  • the event generator directly provides the incoming event to both the queue 11 and to the database manager 13 for storage and later action.
  • a single memory may serve as both event storage 14 and subscriber profile 15. Alternatively, different memories may be used for each.
  • the event analyzer 12 takes action.
  • One action taken by the analyzer 12 is that a flag is added or raised with respect to the incoming event that the analyzer 12 is currently processing. This is a reliability feature.
  • the analyzer 12 looks for the flag to determine where to resume processing. This reduces the likelihood that incoming events will be lost. Once the incoming event has been processed by the analyzer 12 then the flag is removed or lowered for that incoming event, and a flag is then added or raised for the next incoming event in the queue 11. [0035] Another action taken by the analyzer 12 is to inspect the incoming event to extract the relevant data therein. In one embodiment, the nature of the incoming event (memo, fax) determines what fields should be inspected.
  • a memo may have a subject field which can be examined to determine whether certain words are present, such as, but not limited to, "memo", “new policy”, “lapsed”, “lapse pending”.
  • This basic information may be used to identify the form type used for the memo and therefore identify the fields in the memo, the location of each field, and the type of information that is contained in each field.
  • all memos may follow the same format and have the same fields in the same location; different fields will be relevant for different types of memos and therefore some fields may not contain any information.
  • certain documents whether internally generated or received from an external source, may be visually inspected by a person who will then enter the appropriate information into one or more of the fields associated with the document.
  • a fax received incoming event will have little such information.
  • An incoming fax may have, for example, a fax source telephone number provided by the transmitting fax machine, a caller ID telephone number provided by the telephone company, the date and time received, the number of pages, etc.
  • a fax source telephone number provided by the transmitting fax machine
  • a caller ID telephone number provided by the telephone company
  • One or more of these fields may not be present, or may not contain any information.
  • OCR optical character recognition
  • each event input queue being for a particular type of incoming event.
  • one input queue could be for incoming fax messages
  • another input queue could be for memos regarding the issuance of new policies
  • another input queue could be for memos regarding policies which are about to lapse
  • another input queue could be for memos regarding policies which have just lapsed
  • another input queue could be for memos regarding pending/prospective policies/business, etc.
  • event analyzer there could a single event analyzer, which automatically "knows” the type of input event because of which event input queue it is in; or there could be multiple event analyzers, each analyzer being for at least one, and preferably only one, event input queue. This allows for
  • the analyzer 12 after retrieving the relevant data from the incoming event, sends the relevant data to the database manager 13 as a query of the subscriber profile.
  • the database manager 13, the event storage 14, and the subscriber profile 15 are implemented as a relational database.
  • the manager 13 queries the subscriber profile to determine which subscribers have indicated an interest in the conditions noted.
  • the subscriber profile database has a "conditions" field or an index which is queried.
  • Other techniques may also be used but, regardless of the technique used, the database manager 13 generates a list of interested subscribers.
  • the event analyzer 12 sends a single query containing all of the extracted data terms to the database manager 13. This query may be in alternative form, that is, "term A” OR “term B” OR “term C", etc., or the database manager 13 may be programmed to execute the query by searching in the alternative format.
  • the database manager 13 then examines the subscriber profile 15 and returns a list of all subscribers which meet any of the extracted data terms.
  • This provides superior speed and scalability in that only a single query to the database manager is required for each incoming event, even when the number of subscribers increases, and even when the number of extracted data terms increases.
  • This results because a separate query to the database manager 13 for each extracted data term is not required, and because a separate query to the database manager 13 of each subscriber's profile for extracted data terms is not required. It is possible, however, although not preferred, to separately query the database manager for each subscriber's profile in the alternative format, or to separately query the database manager for each extracted data term in all subscribers' profiles.
  • the database manager 13 then provides this list, and the corresponding event notification data, to the notification queue 16.
  • the notification queue 16 uses the list of interested subscribers to access the subscriber profile 15 to obtain the preferences of the interested subscribers.
  • the notification queue 16 then uses the subscriber preferences to determine what to send to an interested subscriber, how to send it, and, if appropriate, when to send it.
  • the notification queue 16 then sends an appropriate event notification 9 to each interested subscriber.
  • the event notification may to one subscriber may be a voice or fax telephone call which simply states or lists the relevant data obtained by event analyzer 12; whereas the event notification to another subscriber, or for a different document, may be an email message alerting the subscriber to see a particular document number, or may be a message on a company web portal that presents part or all of the relevant document, etc.
  • the subscriber may also list a preferred time or period of time for delivery for certain delivery options, such as by telephone. Thus, the telephone call may be delayed until the preferred time has arrived.
  • the event analyzer 12 may obtain the subscriber profile directly from the subscriber profile database 15 and provide all or part of the subscriber profile to the notification queue 16.
  • the event analyzer may obtain a reference or pointer to the profile of the interested subscriber and provide that pointer to the notification queue 16.
  • the database manager may provide a reference or pointer to the profile of the interested subscriber to the notification queue 16.
  • each notification queue being for a particular notification method.
  • one notification queue could be for fax notification
  • another notification queue could be voice telephone calls
  • another notification queue could be for e-mail
  • another notification queue could be for posting to the person's secure web site page of the company, etc.
  • each notification queue could provide a single event type notification, which automatically "knows" the relevant data which can be sent, and how it should be formatted, because it is designed to handle a specific method of sending the event notification data. This allows for "parallel" processing of different methods, which may speed up the delivery of certain method types, but it may also result in resources which are underused if a notification queue is empty for substantial periods of time.
  • the event is preferably examined for confidential information. For example, if the document contains a social security number field or a health history field, or some other field which indicates that the information contained therein is or may be confidential, and is therefore information which should not be sent via an insecure link, then this confidential information is removed from an event notification prior to being sent to the subscriber by the insecure link. If the event notification is via a secure link then the confidential information may be removed from the event notification or the information may be allowed to remain therein. This examination and cleaning may be performed by either the database manager 13, the notification queue 16, or the task divided among the two, as desired. [0046] Turn now to Figure 2 which is an exemplary flow chart illustrating the process of the exemplary event notification system.
  • the relevant data is extracted and, preferably, the event is stored 205.
  • the extracted data from the incoming event is then used to query 210 the subscriber profile database to generate a list of interested subscribers.
  • the subscriber preferences are obtained, or extracted, 215.
  • An event notification is then prepared 220 based upon those subscriber preferences.
  • the event notification is then sent 225 to the interested subscribers in accordance with the preferences of each subscriber.
  • the event is examined for confidential information, which will be removed if the event notification is to be sent via an insecure link.
  • Figure 3 is an exemplary flow chart illustrating the process of the subscriber inputting conditions and preferences.
  • the subscriber After logging in 300 the subscriber selects 305 the event type, such as a memo or fax, or any other event type which is supported. The subscriber then selects 310 the desired condition, that is, the condition type and the condition data.
  • the condition type and the condition data which may be selected will depend upon the event type selected. For example, as indicated above, the condition type and the condition data for a fax will generally be different from the condition type and the condition data for a memo, although they may have some fields in common. Also, a "subject" condition type will accept different condition data than a "telephone number" or "fax number” condition type.
  • the subscriber may be presented with the option to select a condition type for a fax, such as a fax source telephone number provided by the transmitting fax machine, a caller ID telephone number provided by the telephone company, the date and time received, the number of pages, etc.
  • the subscriber can then input the desired condition data. For example, if the subscriber selects the "a fax source telephone number provided by the transmitting fax machine" condition type then the subscriber can enter the desired fax source telephone number as the condition data.
  • the subscriber can then select 315 the desired event notification method, for example, a telephone call, preferably using voice synthesis, text messaging/short messaging service (SMS), email, and/or a personal web-based company portal, etc.
  • the subscriber is then presented with any options appropriate for the selected method. For example, if the selected method is a telephone call, then the subscriber may be allowed to select a range of hours and/or days of the week, calendar dates, etc. during which the telephone call may (or may not) be placed.
  • the subscriber may enter numerous profile entries, if desired.
  • the subscriber may make one entry for a fax from a first telephone number, make another entry for a fax from a second, different telephone number, make a third entry for a memo having a particular policy number, make a fourth entry for a memo having a particular state, make a fifth entry for a memo having a particular subject, etc.
  • the subscriber is therefore asked 320 whether the subscriber has completed making profile entries. If not, the subscriber is returned to step 305. If so, then the subscriber logs out 325.
  • the subscriber profile may also have "corporate" entries, that is, entries which are specified by the corporation and over which the subscriber may have limited control or no control.
  • corporate entries are generally entered in the same manner as subscriber entries but the corporate entry may also designate numerous subscribers at once, rather than having to enter the same information over and over again.
  • the subscriber may have some control over a corporate entry, such as selecting the method or time of notification, or the subscriber may have no control over any aspect of the corporate entry.
  • the subscriber profile database 15, and the subscriber index if used, is updated 330 in accordance with the subscriber entries. Although this is shown as occurring after log out, this is merely for ease of illustration to indicate that, at some point, the entries are saved into the subscriber profile database 15.
  • the subscriber profile database 15 could be, and preferably is, updated following completion of each profile entry.
  • the subscriber profile database update procedure is preferably performed by the database manager 13. In an alternative embodiment, the subscriber profile database update procedure is performed by another program or processor or program.
  • the notification system 10 is implemented by firmware and/or software on a mainframe database system. However, if the amount of data to be stored is not excessive, then it may be implemented on a PC-based system.
  • mainframe system and the PC system have one or more processors, volatile and non-volatile memory, power supplies, user input devices (keyboard, mouse, etc.), user output devices (displays, printers, etc.), input and output ports, firmware, software, etc.
  • the event input queue(s) 11, the event analyzer(s) 12, the subscriber profile database 15, and the notification queue(s) 16 are preferably implemented as plug-in software modules for use with the software and/or firmware which operates a relational database manager, such as the database manager 13.
  • This provides for speed and scalability in that, when an incoming event occurs, the data of the incoming event is used to query, such as by SQL (structured query language), the subscriber profile database for matches with selected data.
  • SQL structured query language
  • Event data is drawn from all relevant data environments, generally mainframe- based DB2 (IBMTM Database 2) databases and VSAM (IBM Virtual Storage Access Method) files.
  • the system could be implemented as a single-tier approach, which is a possible, but not preferred approach, because it could possibly require extensive modifications of underlying software, such as "new-business" processing software, and such as claims entry and processing software, in order to extend the system to a meaningful deployment, that is, a deployment which benefited a large portion of the field force in a timely manner, rather than benefiting only a selected few persons and/or providing delayed notices. Further, such modifications could be difficult and might require a substantial dedicated staff with expertise in the affected areas, such as mainframe applications, and would require extensive approval processes, collaboration, and testing exercises to verify its function and to verify that it did not adversely affect other software functions or speed.
  • underlying software such as "new-business" processing software, and such as claims entry and processing software
  • a modular design approach is used to ensure portability to new platforms and/or databases, and to provide extensibility to all company data stores.
  • This modular design approach also address the challenge involved retrieving the backend data from the mainframe DB2 and VSAM data stores.
  • a more agile relationship with the subscribers is obtained by providing real-time information to the subscribers; this reduces call-center polling, raises productivity, and also lowers costs. Additionally, because the event data is preferably centrally stored, then, over time, aggregate events and reports can be easily and efficiently created from this event data.
  • the event notification systems also allow subscribers to be notified when a certain threshold is exceeded, and reports are generated for such subscribers so that they will be aware of their current performance and trends. This results in a more informed and efficient field force, a less burdened call center, and a more agile method of managing and distributing real-time information.
  • the notification system has three tiers or subsystems: a mainframe tier, a middle tier, and a presentation tier.
  • the mainframe tier comprises the back-end systems from which events are drawn. In one actual implementation, these systems are primarily DB2 databases and VSAM data stores running on S/390 (z/OS) LPARs (Logical PARtitions) of a mainframe. Other implementations are possible and may be preferable in order to avoid the expense of upgrading the mainframe system unless there is other justification for doing so.
  • the presentation tier is run on an application server which uses a cross-platform portal, such as the cross-platform portal offered by PlumtreeTM Software.
  • the middle tier preferably provides the framework for event handling, funnels events according to subscriptions, serves the portlets for the presentation tier, and provides access to the various event delivery methods through encapsulated application programming interfaces (APIs).
  • APIs application programming interfaces
  • the processing effort of the middle tier is primarily servicing the core APIs.
  • the middle tier is platform agnostic in a general sense so as to provide for widespread utility, but is also preferably easily optimized for a particular platform to enhance speed, reduce processing time, and advantageously use features already available on the platform.
  • the middle tier provides for convenient integration with mainframe -based data stores.
  • a network communication technology for example, such as IBM's WebSphereTM MQ, is used with the WebSphere Application Server and JavaTM Messaging Services. This implementation allows system programming developments which are unconstrained by the overhead of interacting with remote systems which may necessarily be under tight control.
  • Other possible and preferred platforms are an IntelTM NVindowslDB2 platform and the pSeriesTM IAIXIDB2 platform.
  • the back-end API is a queue-based data retrieval layer which interfaces with the existing mainframe DB2 and VSAM data stores. This layer incorporates an intelligent classification strategy to retrieve relevant data from the underlying databases, and pulls the data into a consolidated format.
  • the eventing API is a push-method data transmittal to the various event delivery APIs which will enable the actual distribution of the events to subscribers. Preferably, at this point the events are already preprocessed, so the recipient event delivery API only needs to pass the data on through the proper medium without any further processing.
  • the reporting API is preferably a generic layer with an array of specialized plug- ins. Each plug-in will define the characteristics of a particular report type and interact as necessary with the database. The report is then pushed back through the generic layer to the requester through either a static reports mechanism or an application server.
  • the system may be implemented, for example, using Java2 Platform Enterprise Edition 1 (J2EE1) support for Java Messaging Services (JMS), Enterprise Java Beans (EJB), and WebSphere MQ integration in WebSphere Application Server.
  • J2EE1 Java2 Platform Enterprise Edition 1
  • JMS Java Messaging Services
  • EJB Enterprise Java Beans
  • WebSphere MQ integration in WebSphere Application Server.
  • Database servers are highly clusterable, so the database- located logic will be able to scale with the data sizes through clustered database servers where necessary. Both the target databases and platforms (pSeries 1AIXIDB2 and Intel Windows SQL Server) support such clustering arrangements.
  • the main subsystems of the middle tier include the database itself, the three major APIs (back-end, eventing, and reporting), the controller, and the Plumtree portlets. Data arrives at the system from the mainframe-based DB2 and VSAM data stores through MQueues which are part the of plug-ins interfacing with the back-end API.
  • This data is processed through Message Driven Beans (MDB), also part of the plug-in, before it is passed on to Entity Beans which are facades for the underlying database representation.
  • MDB Message Driven Beans
  • Entity Beans which are facades for the underlying database representation.
  • the MDB pass control to the Controller object, which is implemented as a Stateless Session Bean (SSB).
  • SSB invokes the proper database stored procedures to determine which, if any, subscriptions must be sent notifications in light of the new data, and, if necessary, sends a message through JMS to the Output Queue which serves as the control point for outgoing notifications.
  • the Output Queue is an MDB which can enumerate the various notification delivery methods and invoke the sending method in the one appropriate to the subscription being notified.
  • the notification delivery methods are plug-ins consisting of an SSB interfacing with the appropriate, externally-described notification API.
  • the portlet portion uses a Struts-based servelet and JSP structure to allow for maintainable portlet applications. These portlets interact with the balance of the system through an SSB which may modify the database through the Entity beans when necessary. Portlets are, by nature, pluggable, so there is no specific plug-in interface or API for their implementation. The reporting API will allow asynchronous generation of reports from the database using its capability for data warehousing. [0072]
  • the database schema makes the stored procedures efficient, small, and maintainable.
  • Stored procedures may be generated using, for example, an administrative console web interface when a new event type or other new feature is desired.
  • Use of an administrative console for such changes provides security which ensures the stability of the current set of stored procedures and also reduces the likelihood of schema- inconsistent changes.
  • Each stored procedure will have only one function: to locate all subscriptions of the same type (the subscription type with which the stored procedure is created to work) which satisfy the given parameters. This limited scope will ensure the stored procedures are, and remain, fast and robust to yield the performance and speed necessary in a high- volume event notification system.
  • An event is preferably composed of an event type and some variable number of parameters. These parameters provide information about the specifics of the event are the mechanisms by which subscriptions filter the events they car about.
  • Event types are templates which specify the set of valid parameters along with defining the subjective meaning and name of the class of events such as "New Business - Policy Just Issued.” This event type would then have a set of valid parameters-for example, policy number, group number, etc., which are defined as parameter templates. These parameter templates define the type of value and the subjective meaning of the value along with its name and position in the event template.
  • a subscription is a set of choices made by a user which defines the events for which notifications should be generated. Each subscription is preferably limited to a single event type, but may be filtered by any number of conditions on any or all of that event type's parameters. Subscriptions are created through the portlet interface which allows users to easily select and define their filter parameters and determine the type of notification appropriate when the subscription is satisfied by an event.
  • Event notifications can be generated in a number of ways through the output plug- in module or modules.
  • the notification methods supported are portal notifications, including, but not limited to, Email, VOX (voice synthesis), and SMS.
  • Each notification method has an associated plug-in which defines the proper event notification method and, preferably, may be called by the output queue.
  • Input plug-ins are defined by creating a method of moving the data from its initial position into the plug-in, filtering the data to be suitable for output to the database, and finally invoking the data- access layer methods the database to add the new event to the database. This action triggers the controller to examine the event and causes the stored procedures to evaluate whether any subscriptions are satisfied by the new event.
  • One aspect of the event notification system which is unique is its approach to controlling the flow of events through the system from the backend data sources by dynamically selecting the applicable events in the controller and then passing these events on through the output plug-ins to the subscriber.
  • the controller handles the dispatching of events by matching incoming events against subscriptions stored in the database. These subscriptions record the person who created the subscription, the event type to which the person subscribed, and the selection criteria the person wishes to use to filter which events that person will receive. Subscriptions are stored in the database in a normalized fashion such that each selection criterion is a discrete entity which can be joined into a query against an event dynamically.
  • These queries are implemented as stored procedures in the database which contain only a single logical SQL query joining all the relevant factors for all subscriptions and returning a list of the subscriptions which should be notified about the incoming message.
  • This single query per event allows the system to process an incredibly high volume of events with minimum database performance requirements.
  • the stored procedures responsible for this matching are executed by the system each time the metadata about a particular event type is changed, when a new event type is created, or when an old event type is deleted.
  • the stored procedures do not need to be manually modified because they are constructed from the event definition (what the event type is, what parameters it has, what its unique identifiers are, etc.).
  • These generated stored procedures are what the controller calls to determine the list of subscribers to notify about the current event.
  • Conditional language such as, among others, “can”, “could”, “might”, or “may”, unless specifically stated otherwise, or otherwise understood within the context as used, is generally intended to convey that certain embodiments optionally could include, while some other embodiments do not include, certain features, elements and/or steps. Thus, such conditional language indicates, in general, that those features, elements and/or step are not required for every implementation or embodiment.

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Information Transfer Between Computers (AREA)
  • Facsimiles In General (AREA)
  • Telephonic Communication Services (AREA)

Abstract

La présente invention concerne les situations où des abonnés sont avertis de certains événements entrants, comme une télécopie ou un mémo. Les profils des abonnés, stockés dans une base de données, contiennent des données concernant au moins un événement spécifié dont un abonné souhaite être averti et une procédure par laquelle l'abonné préfère être averti. En cas d'événement entrant (200), les données sont extraites (205) de l'événement entrant et la base de données est interrogée (210) à l'aide des données extraites pour identifier au moins un abonné dont le profil d'abonné contient au moins un élément des données extraites et la procédure par laquelle l'abonné identifié préfère être averti (215) de l'événement entrant. Une notification d'événement est ensuite préparée (220) pour l'événement entrant conformément à la procédure déterminée pour l'abonné identifié et la notification de l'événement est envoyée (225) à l'abonné identifié conformément à la procédure déterminée.
EP07854468A 2006-10-27 2007-10-29 Procédé et appareil pour envoyer une notification aux abonnés d'événements demandés Withdrawn EP2084891A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US86329706P 2006-10-27 2006-10-27
PCT/US2007/082779 WO2008052208A2 (fr) 2006-10-27 2007-10-29 Procédé et appareil pour envoyer une notification aux abonnés d'événements demandés

Publications (1)

Publication Number Publication Date
EP2084891A2 true EP2084891A2 (fr) 2009-08-05

Family

ID=39211987

Family Applications (1)

Application Number Title Priority Date Filing Date
EP07854468A Withdrawn EP2084891A2 (fr) 2006-10-27 2007-10-29 Procédé et appareil pour envoyer une notification aux abonnés d'événements demandés

Country Status (6)

Country Link
US (1) US20080184270A1 (fr)
EP (1) EP2084891A2 (fr)
JP (1) JP2010508731A (fr)
CN (1) CN101573952A (fr)
CA (1) CA2667206A1 (fr)
WO (1) WO2008052208A2 (fr)

Families Citing this family (53)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9400589B1 (en) 2002-05-30 2016-07-26 Consumerinfo.Com, Inc. Circular rotational interface for display of consumer credit information
US7474432B1 (en) 2004-03-05 2009-01-06 Callwave, Inc. Methods and systems for fax routing
US7480065B1 (en) 2004-03-05 2009-01-20 Callwave, Inc. Facsimile telecommunications system and method
US8285656B1 (en) 2007-03-30 2012-10-09 Consumerinfo.Com, Inc. Systems and methods for data verification
AU2008202534B2 (en) * 2007-06-08 2012-05-31 Titus Inc Method and system for e-mail management of e-mails having embedded classification metadata
US8024315B2 (en) * 2007-07-20 2011-09-20 International Business Machines Corporation Method of dynamically providing a compound object's source information during its development
US8312033B1 (en) 2008-06-26 2012-11-13 Experian Marketing Solutions, Inc. Systems and methods for providing an integrated identifier
US9256904B1 (en) 2008-08-14 2016-02-09 Experian Information Solutions, Inc. Multi-bureau credit file freeze and unfreeze
US9652802B1 (en) 2010-03-24 2017-05-16 Consumerinfo.Com, Inc. Indirect monitoring and reporting of a user's credit data
US20110258007A1 (en) * 2010-04-16 2011-10-20 Schlumberger Technology Corporation Data subscription
US8838707B2 (en) 2010-06-25 2014-09-16 Twilio, Inc. System and method for enabling real-time eventing
KR101921120B1 (ko) * 2010-08-27 2019-02-13 삼성전자주식회사 ＵＰｎＰ 텔레포니를 이용한 메모 공유 방법 및 장치
US8930262B1 (en) 2010-11-02 2015-01-06 Experian Technology Ltd. Systems and methods of assisted strategy design
US9147042B1 (en) 2010-11-22 2015-09-29 Experian Information Solutions, Inc. Systems and methods for data verification
US9680909B2 (en) * 2011-01-31 2017-06-13 Infosys Limited Method and system for providing electronic notification
US9558519B1 (en) 2011-04-29 2017-01-31 Consumerinfo.Com, Inc. Exposing reporting cycle information
WO2013009920A1 (fr) * 2011-07-12 2013-01-17 Experian Information Solutions, Inc. Systèmes et procédés pour une architecture de traitement de données de crédit à grande échelle
US10255598B1 (en) 2012-12-06 2019-04-09 Consumerinfo.Com, Inc. Credit card account data extraction
US20140195620A1 (en) * 2013-01-08 2014-07-10 Ebay Inc. Notification routing to a user device
US9697263B1 (en) 2013-03-04 2017-07-04 Experian Information Solutions, Inc. Consumer data request fulfillment system
US10078539B1 (en) * 2013-10-30 2018-09-18 American Airlines, Inc. System and method for logging and searching history events such as airline flight or crew history
US10102536B1 (en) 2013-11-15 2018-10-16 Experian Information Solutions, Inc. Micro-geographic aggregation system
US9529851B1 (en) 2013-12-02 2016-12-27 Experian Information Solutions, Inc. Server architecture for electronic data quality processing
US11100524B1 (en) 2013-12-23 2021-08-24 Massachusetts Mutual Life Insurance Company Next product purchase and lapse predicting tool
US11062337B1 (en) 2013-12-23 2021-07-13 Massachusetts Mutual Life Insurance Company Next product purchase and lapse predicting tool
US11062378B1 (en) 2013-12-23 2021-07-13 Massachusetts Mutual Life Insurance Company Next product purchase and lapse predicting tool
US11743389B1 (en) 2013-12-30 2023-08-29 Massachusetts Mutual Life Insurance Company System and method for managing routing of customer calls
US11509771B1 (en) 2013-12-30 2022-11-22 Massachusetts Mutual Life Insurance Company System and method for managing routing of customer calls
US12113936B1 (en) 2013-12-30 2024-10-08 Massachusetts Mutual Life Insurance Company System and method for managing routing of customer calls
US11151486B1 (en) 2013-12-30 2021-10-19 Massachusetts Mutual Life Insurance Company System and method for managing routing of leads
US11831794B1 (en) 2013-12-30 2023-11-28 Massachusetts Mutual Life Insurance Company System and method for managing routing of leads
US10394834B1 (en) 2013-12-31 2019-08-27 Massachusetts Mutual Life Insurance Company Methods and systems for ranking leads based on given characteristics
US10262362B1 (en) 2014-02-14 2019-04-16 Experian Information Solutions, Inc. Automatic generation of code for attributes
US10372515B1 (en) 2015-10-30 2019-08-06 American Airlines, Inc. System agnostic front end application for legacy systems
US10757154B1 (en) 2015-11-24 2020-08-25 Experian Information Solutions, Inc. Real-time event-based notification system
US10135940B2 (en) * 2015-12-04 2018-11-20 Oracle International Corporation Subscribing to event notifications using object instances
US10379907B2 (en) * 2016-03-25 2019-08-13 Change Healthcare Holdings, Llc Event-driven system and method for selectively performing computations
CN107644045B (zh) * 2016-07-22 2020-11-24 平安科技（深圳）有限公司 投保资料数据的处理方法和装置
US10216782B2 (en) * 2016-08-12 2019-02-26 Sap Se Processing of updates in a database system using different scenarios
US10542148B1 (en) 2016-10-12 2020-01-21 Massachusetts Mutual Life Insurance Company System and method for automatically assigning a customer call to an agent
CA3050139A1 (fr) 2017-01-31 2018-08-09 Experian Information Solutions, Inc. Ingestion de donnees heterogenes a grande echelle et resolution d'utilisateur
US10735183B1 (en) 2017-06-30 2020-08-04 Experian Information Solutions, Inc. Symmetric encryption for private smart contracts among multiple parties in a private peer-to-peer network
US10229370B1 (en) 2017-08-29 2019-03-12 Massachusetts Mutual Life Insurance Company System and method for managing routing of customer calls to agents
US11176461B1 (en) 2017-08-29 2021-11-16 Massachusetts Mutual Life Insurance Company System and method for managing routing of customer calls to agents
US10963434B1 (en) 2018-09-07 2021-03-30 Experian Information Solutions, Inc. Data architecture for supporting multiple search models
WO2020146667A1 (fr) 2019-01-11 2020-07-16 Experian Information Solutions, Inc. Systèmes et procédés d'agrégation et de calcul de données sécurisés
WO2020159917A1 (fr) 2019-01-28 2020-08-06 Pindrop Security, Inc. Repérage de mots-clés et découverte de mots non supervisés pour une analyse de fraude
US11948153B1 (en) 2019-07-29 2024-04-02 Massachusetts Mutual Life Insurance Company System and method for managing customer call-backs
US11941065B1 (en) 2019-09-13 2024-03-26 Experian Information Solutions, Inc. Single identifier platform for storing entity data
CN112540751A (zh) * 2019-09-23 2021-03-23 北京国双科技有限公司 事件接口的处理方法和装置、存储介质及电子设备
US11803917B1 (en) 2019-10-16 2023-10-31 Massachusetts Mutual Life Insurance Company Dynamic valuation systems and methods
US11880377B1 (en) 2021-03-26 2024-01-23 Experian Information Solutions, Inc. Systems and methods for entity resolution
US12586126B2 (en) 2021-11-03 2026-03-24 Consumerinfo.Com, Inc. Methods and apparatuses for generating a new credit file and adding tradelines

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6338056B1 (en) * 1998-12-14 2002-01-08 International Business Machines Corporation Relational database extender that supports user-defined index types and user-defined search
FR2824693B1 (fr) * 2001-05-14 2003-08-22 Cit Alcatel Procede de notification de l'arrivee d'un evenement sur un terminal mobile, et terminal mobile pour la mise en oeuvre de ce procede
US6888828B1 (en) * 2001-10-02 2005-05-03 Nokia Corporation System and method for providing at least one service obtained from a service network for a user in a packet switched communication network
WO2003048905A2 (fr) * 2001-12-05 2003-06-12 E-Xchange Advantage, Inc. Procede et systeme de gestion de donnees commerciales distribuees
GB0213728D0 (en) * 2002-06-14 2002-07-24 Nokia Corp A communication system
US7660856B2 (en) * 2003-10-06 2010-02-09 Microsoft Corporation Method and system for web-based event notification
US7437375B2 (en) * 2004-08-17 2008-10-14 Symantec Operating Corporation System and method for communicating file system events using a publish-subscribe model

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2008052208A2 *

Also Published As

Publication number Publication date
JP2010508731A (ja) 2010-03-18
WO2008052208A2 (fr) 2008-05-02
CA2667206A1 (fr) 2008-05-02
US20080184270A1 (en) 2008-07-31
WO2008052208A3 (fr) 2008-06-19
CN101573952A (zh) 2009-11-04

Similar Documents

Publication Publication Date Title
US20080184270A1 (en) Method and apparatus for sending notification to subscribers of requested events
US12321363B2 (en) Systems and methods for unifying formats and adaptively automating processing of business records data
US7805683B2 (en) Action pad
RU2549510C1 (ru) Системы и способы создания крупномасштабной архитектуры обработки кредитной информации
CA2372423C (fr) Systemes et procedes de presentation et de paiement de factures electroniques
US7634732B1 (en) Persona menu
AU2006319738B2 (en) A method and apparatus for storing and distributing electronic mail
US20200334690A1 (en) Method and system for monitoring an issue
US11574258B2 (en) Method and system for analyzing contact studies
US20070203778A1 (en) Workflow management
US8380797B2 (en) Business data exchange layer
US20030200527A1 (en) Development framework for case and workflow systems
US20040243588A1 (en) Systems and methods for administering a global information database
US8650043B1 (en) Semantic model for insurance software components
US20230237396A1 (en) System with capacity and resource allocation display to facilitate update of electronic record information
JP2002511160A (ja) 関係およびグループ管理を導入する財務計画システム
WO2008103493A1 (fr) Système et procédé de gestion de portail de relation client
CA2648611C (fr) Systeme de gestion de donnees
US10643286B2 (en) Knowledge management tool interface
US20150106128A1 (en) System and method to facilitate a communication interface between insurance agent and underwriter devices
US20060059033A1 (en) Interaction object
US9697524B1 (en) Enterprise fulfillment system with dynamic prefetching capabilities
US20240330817A1 (en) System and method to provide risk relationship entity interaction tracker
US20100030596A1 (en) Business Process Intelligence
US20220270024A1 (en) Method and system to predict stakeholder project impact

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20090519

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC MT NL PL PT RO SE SI SK TR

RIN1 Information on inventor provided before grant (corrected)

Inventor name: SHILLING, JOHN JULIUS

Inventor name: CONSTANCE, SHAWN M.

Inventor name: MORRIS, WILLIAM R.

Inventor name: COLE, RAYMOND C.

Inventor name: HARRISON, JOSHUA BRUCE

Inventor name: GOODWIN, KYLE S.

DAX Request for extension of the european patent (deleted)
REG Reference to a national code

Ref country code: HK

Ref legal event code: DE

Ref document number: 1132862

Country of ref document: HK

17Q First examination report despatched

Effective date: 20121211

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20130423

REG Reference to a national code

Ref country code: HK

Ref legal event code: WD

Ref document number: 1132862

Country of ref document: HK