Abstract:
Data about a plurality of events is stored in an event database, including information for selecting who should be invited to the event. Data about a plurality of members is stored in a member database, preferably including members&#39; preference criteria specifying the type of events in which each member likes to participate. The member information is matched against the invitee selection criteria and the event information is matched against the member preference criteria to determine which members should be invited to each event. Based on results of this matching process, e-mail invitations to the selected events are sent to the members.

Description:
CROSS REFERENCE TO RELATED APPLICATIONS 
     Priority is claimed to U.S. provisional application No. 60/432,873, filed Dec. 11, 2002, which is incorporated herein by reference. 
    
    
     BACKGROUND 
     The present invention relates to the distribution of invitations for a plurality of events. 
     In many fields, particularly among practitioners such as doctors, companies and institutions that wish to disseminate information about their products sponsor events to promote those products. These events are typically promoted to members of the target practitioners. For example, in the medical field, drug companies that wish to promote a new drug may run such a symposium where a speaker presents a paper about the benefits of the drug to a group of doctors. Other examples in the medical field include CME events, dinner meetings, webcasts, and teleconferences. 
     In fields with a large number of practitioners and a large number of products, it can be difficult for the sponsors to get information about such events to the relevant target audience, especially since conventional approaches such as cold calling and spam emails can be perceived as a nuisance by their recipients. In addition, it can be difficult for the practitioners to keep abreast of events that they would like to participate in. 
     SUMMARY OF THE INVENTION 
     The present invention facilitates distribution of invitations for a plurality of events to a desired sub-population of practitioners within a field. In some embodiments, recipients can specify what type of information they are interested in receiving. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is an overall block diagram of an embodiment of the invention. 
         FIG. 2  is an example of a data structure for storing information about a plurality of events. 
         FIG. 3  is an example of a data structure for storing information about a plurality of members. 
         FIG. 4A  is a table that depicts matches between the members and the events. 
         FIG. 4B  is a table that depicts matches between the members and the events, adjusted to account for members&#39; preferences. 
         FIG. 5  is a data structure for tracking the status of issued invitations. 
         FIG. 6  is a sample of an e-mail invitation inviting a particular member to a selection of events. 
         FIG. 7  is a sample screen where members can specify their preferences. 
         FIG. 8  is a sample screen for a web-based display of a member&#39;s invitations. 
     
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
     The embodiments described herein preferably are implemented using a central Internet-based server. Conventional computer hardware (e.g., Windows, McIntosh, and Linux-based machines) communicate with the central server via the Internet, Internet-based e-mail and/or alternate communication mechanisms. The hardware and software for implementing these servers and computers, as well as the mechanism for their communication is well known to persons skilled in the relevant arts. Accordingly, this application focuses on the data structures that are implemented in the server, and the communication between the server and the members (i.e., the users). It is envisioned that instructions for performing the process steps described herein will be stored on computer-readable media (e.g., optical, magnetic, or semiconductor media), in any conventional manner. 
       FIG. 1  is an overall block diagram of an embodiment of the invention. The illustrated embodiment contains an event information database  12  which is populated based on information received from sponsors of the event. In some embodiments, the event database  12  is managed by a system administrator who receives information from the sponsors of the events. In alternative embodiments, particularly with sponsors that run a large number of events, the system may permit the sponsors to create new entries in the event database  12  themselves. In such case, suitable communications between the event database  12  and the sponsors&#39; remote computers (both not shown) are preferably implemented using any conventional communication protocol. 
     The illustrated embodiment also includes a member information database  13 . This member database  13  includes information about the people who are to receive the invitations that are generated by the system. The member database  13  may initially be populated by importing information from another database in the relevant field. For example, if the system is used to deliver invitations to medical doctors, a preexisting database of medical doctors could be used to pre-populate the member database  13 . In some embodiments, a mechanism is provided by which a new user can register and add his or her information into the member database  13 , preferably via a conventional web-based interface (not shown). 
       FIG. 2  is an illustrative example of an appropriate set of fields for the event database  12 . This database preferably includes information that describes each event (such as the topic, the speaker, the data and time, the location, and the sponsor). If an incentive is offered to attendees of the event, that incentive is also included in the event database. The fields that describe the events may include, for example, an event ID, topic, speaker name, description, event type, location, time(s), date(s), RSVP date, RSVP phone number, an event URL, and eligible attendees (i.e. MD, PA, RN, etc.). Fields to describe each event&#39;s sponsor may also be included, such as the company name, a drug name, and a drug category. 
     The event database preferably also includes recruitment information (also referred herein as invitee selection criteria) which specifies characteristics of desired target audience. Those characteristics could include generalized information such as the recipient&#39;s specialty, or particular information that identifies specific individuals that are to be invited. Examples of fields that are suited for invitee-selection include, for example, Customer ID, First Name, Last Name, Degree, Address, City, State, Zip Code, Phone Number, Fax Number, Email Address, Specialty, ME Number, and DEA Number. 
       FIG. 3  is an illustrative example of an appropriate set of fields for the member database  13 . The illustrated member database includes all the information that the Detect Matches process  14  (shown in  FIG. 1 ) needs in order to implement sponsor-directed matching. This information may include, for example, the name and specialty of each member as well as contact information and a unique identifier number such as the ME number. 
     Once the event database  12  and the member database  13  have been populated, the Detect Matches process  14  examines the contents of the two databases  12 ,  13  and determines which of the events match which of the members. 
     Matching may be implemented automatically by comparing the topic of each event (which appears in the event database  12 ) to the specialty of each member (which appears in the member database  13 ), and searching for matches between events and members. For example, a member database for doctors might include each doctor&#39;s specialization (e.g., cardiology, orthopedics, pediatrics), and the event information in the event database  12  would contain fields that match those specialties. The Detect Matches process  14  would compare the appropriate fields in the event database  12  and the member database  13  to find matches. For example, the Detect Matches process  14  might match a pediatric cardiology event to pediatricians and cardiologists, but would not match that event with a member whose specialty is oncology. 
     Matching may also be implemented based on sponsor-directed invitee-selection criteria, which permits event sponsors to target promotion of their events to their desired audience. This may be accomplished, for example, by providing appropriate fields in the event database  12 , and searching for matches for those fields in the member database  13 . The fields are preferably populated using any conventional user interface (e.g., a web-based interface). Examples of such fields could include an area of specialization (e.g., cardiology, orthopedics, etc.), to permit promotion of an event to all interested members with that specialization. See, for example, event # 1  in  FIG. 2 , which specifies a specialty (orthopedics). 
     Events may also be promoted to specific individuals by specifically listing those individuals that the sponsor would like to invite to the event. This approach may be implemented, for example, by providing fields in the event database  12  for listing individual names of the desired recipients (or another unique identifier such as an e-mail address or a license number). See, for example, event # 3  in  FIG. 2 , which specifies three names. In still other embodiments, category-based invitee-selection criteria may be combined with individual invitee-selection criteria by using some fields in the event database  12  to specify a specialty, and using other fields in the event database  12  to specify individual recipients. See, for example, event # 4  in  FIG. 2 , which specifies both a specialty (orthopedics) and an individual&#39;s name. 
     Matching may also be implemented based on the preferences of the members. In these embodiments, the members enter the type of events that they would like to hear about in an appropriate field in the member database  13 . The Detect Matches process  14  compares the values entered into those fields with corresponding fields in the event database  12  and designates those events with corresponding criteria as matching. See, for example, member # 1  in  FIG. 3 , which specifies both tendonitis as an area of interest. 
     Thus, three alternatives exist: In the first alternative, the Detect Matches process  14  may be configured to flag matches based only on the selection criteria contained in the event database  12 , and comparisons of those criteria to information contained in the member database  13 . In the second alternative, the Detect Matches process  14  may be configured to flag matches based only on the members&#39; preferences contained in the member database  13 , and comparisons of those preferences to information contained in the event database  13 . 
     In the third alternative, the Detect Matches process  14  is configured to flag matches based on both (a) the selection criteria contained in the event database  12  and comparisons of those criteria to information contained in the member database  13 ; and (b) the members&#39; preferences contained in the member database  13  and comparisons of those preferences to information contained in the event database  13 . With the third alternative, any invitation that is received by a member would satisfy two conditions: the event&#39;s sponsor wants the invitation delivered to the member, and the member is also interested in receiving that particular type of invitation. 
       FIG. 4A  is an example of the matches that are obtained when the first alternative is used (i.e., when the sponsor&#39;s criteria contained in the event database illustrated in  FIG. 2  is compared to the information in the member database illustrated in  FIG. 3 ). In this example, member no.  1  matched the criteria for event nos.  2  and  4 ; member no.  2  matched the criteria for event nos.  1  and  3 ; member no.  3  matched the criteria for event no.  3 ; member no.  4  matched the criteria for event no.  3 , and member no.  5  matched the criteria for event nos.  4  and  5 . All these matches are listed in  FIG. 4A . 
       FIG. 4B  illustrates what the match table would look like when the third alternative is used (i.e., when member preferences are used in addition to sponsor&#39;s invitee selection criteria). Note that while either set of criteria could theoretically be applied first, the example of  FIG. 4B  assumes that the sponsor&#39;s criteria is applied first. As explained above, the results of the sponsor&#39;s invitee selection criteria for the data shown in  FIGS. 2 and 3  is the set of matches that appear in  FIG. 4A . The matches from  FIG. 4A  are then used as the starting point for the next selection step, which is based on the members&#39; preferences. 
     For the example data shown in  FIG. 3 , member numbers  2 - 4  have not specified any interests, so the system assumes the default condition that those members are willing to accept invitations relating to all areas of interest. Accordingly, the events that were previously selected for member numbers  1 - 3  are not changed, as shown in  FIG. 4B . 
       FIG. 4A  contained two events for member number  1  (i.e., event nos.  2  and  4 ). However, because member number  1  has specified that he is only interested in tendonitis, the system recognizes that member number  1  is not interested in event number  4 , which relates to osteoporosis. As such, only event number  2  (which relates to tendonitis), remains in  FIG. 4B  for member number  1 . Similarly, because member number  5  indicated that he is interested in the products of ABC Co., but did not indicate an interest in the products of GHI Co., only event number  5  (which relates to ABC), remains in  FIG. 4B  for member number  4 . 
     Once a set of matches is obtained as described above (as reflected in  FIG. 4A  for sponsor-directed matches, or  FIG. 4B  when both a sponsor-directed and member-directed matches), the Generate Invitations process  16  (shown in  FIG. 1 ) is implemented. This process queues up all the invitations that are to be delivered to each member based on the results of the Detect Matches process  14 . 
     The member database (shown in  FIG. 3 ) preferably includes a field entitled “E-mail frequency” which allows a member to specify how often he would like to be contacted with invitations, and a preferred time of day or day of the week. For example, one member may specify that he would like to receive emails daily at 8 AM, and a second member may specify that she would like to receive emails every Monday at noon. When the preferred reception time arrives for a given member, all of the invitations that are queued up for that member are formatted into an e-mail, and the e-mail is delivered to the member  17  (shown in  FIG. 1 ). 
       FIG. 6  is an example of such an e-mail for member number  2 . The e-mail contains two invitations: one for each of the events that appear on the match table for member number  2 . Preferably, the user may obtain details about any of the listed events by clicking on the corresponding link in the email. When member number  2  receives the e-mail, the member is provided with the option to accept, decline, or delete each of the invitations. Although any suitable user interface may be used for this purpose, as will be appreciated by those skilled in the relevant art, the illustrated example includes check boxes that the member clicks to make their selections. 
     After the member has made their selections, the member clicks on the submit button which submits the member&#39;s responses to the central server via the internet. In an alternative embodiment, members may log into their account via the Internet, and access their invitations using a suitable web-based interface.  FIG. 8  is a sample web-based screen for listing a member&#39;s invitations and reporting the status of those invitations (e.g., accepted, declined, etc.) to the member. With either embodiment, the central server then implements the Manage Responses process  18  to deal with the members&#39; responses. 
     Preferably, response to the e-mail will direct the member&#39;s browser&#39;s to a website that manages the members&#39; responses. Access to this website may be protected using conventional mechanisms such as password protection. On the website, members may be provided with the option to filter, sort, search, accept, decline, and/or delete all their invitations, using any appropriate user interface. 
     Optionally, the system may be programmed to track accepted invitations and send a reminder e-mail at a predetermined time before the event (e.g., one day for live events, or one-half hour for webcast events). 
     Optionally, members&#39; responses may be reported to the sponsors to help the sponsors manage attendance at their events. Certain responses may call for updating of the event information. For example, when an in-person event only has room for a limited number of participants, the event can be marked “closed” after the maximum number of participants have registered for the event (and optionally removed from all queues). Optionally, if a sponsor recognizes that one of their events is not receiving sufficient interest, facilities for updating the event&#39;s description (e.g., by modifying the title) or the invitee-selection criteria (e.g., to broaden the target audience) may be provided. New emails would then be queued after the update has occurred. 
     Optionally, appropriate feedback may be returned to the member by the Manage Responses process  18  (e.g., by sending a confirmatory e-mail to the member to indicate that registration for an event has been successful). 
       FIG. 5  is an example of a data structure that may be used by the Generate Invitations process  16  to track the issuance of invitations, and by the Manage Responses process  18  to track the members&#39; responses. The data shown in  FIG. 5  reflects the status of each of the eight invitations at a snapshot in time. More specifically, this snapshot in time occurs after all of the matches have been queued for invitation a-h, but the preferred e-mail reception time has only passed for member number  1 - 3 . As a result, only invitations a-e have been e-mailed (indicated by the entry “yes” in the “emailed” column). In contrast, because the preferred e-mail reception time for member numbers  4  and  5  has not yet occurred, invitations f-h have not yet been mailed to member numbers  4  and  5 . 
     On the response, side, at the snapshot of time represented in  FIG. 5 , member number  1  has not yet responded to his invitations (i.e., the invitations with reference codes a and b), so the word “none” appears in the response column for those invitations. Member numbers  2  and  3 , on the other hand, have already responded to invitation numbers c-e, and those responses are reflected in the right-hand column of  FIG. 5 . Since member nos.  4  and  5  have not yet received their invitations (because their preferred delivery time has not yet arrived), the response column is not applicable to them. 
     The above-described embodiments are advantageous to sponsors, because it enables them to target their events to those recipients that they find most desirable. They are also advantageous to the members, because the members can tailor the events to which they are invited by entering their preferences using, for example, a conventional web interface. An example of a web-based data entry screen that members can use to input their preferences is shown in  FIG. 7 . This information is ultimately transferred into the member database  13 , shown in  FIG. 1 . 
     This arrangement is convenient for members, because all of their invitations are consolidated from multiple sponsors into a single place. In addition, the members do not have to sift through mountains of spam to find events in which they are interested. Because of these advantages to the member, it is expected that members will make use of the service. This, in turn, increases the system&#39;s usefulness to sponsors, because it helps the sponsors get their invitations in front of their target audiences. 
     While the present invention has been explained in the context of the preferred embodiments described above, various changes may be made to those embodiments and various equivalents may be substituted without departing from the scope of the invention, as will be apparent to persons skilled in the relevant art. For example, a similar system could be used to market other products and services besides the “events” discussed above. One example would be to use a similar system to disseminate samples of drugs to the appropriate recipients. Other examples, both in and outside the medical field, can also make use of similar systems. In such cases, the sponsors would use selection criteria to select their target audience, and the audience would use member preferences to select the offers that they would like to receive. The matching of which offer is to be directed to which member, however, would be implemented using similar principles.