WO2002013038A1

WO2002013038A1 - System and method for universal broadcast messaging to members of a community

Info

Publication number: WO2002013038A1
Application number: PCT/US2001/041651
Authority: WO
Inventors: Patwinder S. Sidhu; Andrew W. Connors; Lee K. Najjar; John Bell
Original assignee: Mindsurf Networks, Inc.
Priority date: 2000-08-10
Filing date: 2001-08-10
Publication date: 2002-02-14
Also published as: AU2001281400A1

Abstract

A method and system for quickly and reliably contacting members of a community. Users become community members by providing contact and other information during a subscription process in order to establish a subscriber profile (502). Afterwards, the subscribers are assigned a unique ID (504) and are responsible for updating and maintaining their individual profiles (502). The subscribers can be grouped by virtue of their subscriber IDs to form a community and/or various sub-communities which also have unique IDs. Thereafter, messages can be sent based only on the unique IDs, and the memberships of the community and sub-communities can be administered using only the unique IDs. Thus, subscriber confidentiality is maintained and system administration is facilitated. Moreover, the messages are typically entered via the Internet, and are sent based only on the unique IDs, so that the messages can be sent to an individual or group in virtually as little time as it takes to enter or select a desired message.

Description

SYSTEM AND METHOD FOR UNIVERSAL BROADCAST MESSAGING TO

MEMBERS OF A COMMUNITY

Field of the Invention

The present invention relates to an improved system and method for sending a message to members of a community. More particularly, the system and method relate to an improved technique for the sending of a message, preferably entered using the Internet, via every one of the members' personal communication devices.

Background of the Invention

In today's highly mobile and complex society, communicating quickly and effectively poses a difficult challenge for schools and other large, fluctuating groups of individuals. For example, in emergency situations, when time is of the essence, a school must often track a large number of parents through multiple phone numbers (home, office, mobile) and still may be unable to connect to deliver crucial information in real time. Multiply this by hundreds, even thousands, of families in a school- wide emergency, and it becomes almost impossible to reach parents in a timely fashion with accurate, actionable information, given the staffing constraints most schools face. Similar issues face various other organizations, such as youth groups, churches, businesses, towns, or any other collection of individuals who need to communicate with one another quickly and effectively.

To address this issue, many schools have installed voice telephony systems which can be programmed for bulk outgoing calls and dial-in retrieval announcements; others are beginning to explore use of email and web site postings to communicate with parents. However, neither voice telephony nor email are effective in reaching parents "on the move" in their homes, on the job, etc.

Outside the school market, a number of companies provide delivery of messages, reminders, and content via the Internet to mobile alphanumeric devices such as cell phones, pagers, and PDAs. Several of these companies even have the ability to deliver a message to multiple types of communication devices at once. For example, a business may provide a service to its employees whereby the employees are able to send a message to their fellow employees by entering those employees' email address(es), cell phone number, etc. However, these systems all require knowledge of the recipients' contact information (such as email addresses, phone numbers, etc.), and the various messages are individually composed and sent based on this information. Thus, it is very difficult to quickly compose and send a message to all of the recipients at once. Moreover, it is also difficult to designate sub-groups of recipients, to thereby quickly compose and send messages thereto. In addition, recipients must be willing to divulge this information to the community-at-large. Finally, it is difficult or impossible to adequately deal with a large community of potential message recipients, especially when the community is constantly adding or subtracting members, or as contact information for the members changes over time. Thus, none of these prior art systems are well-suited for the type of real-time, universal messaging required for large communities of individuals, such as school communities. What is needed is a messaging system which is conveniently administered, maintained and executed, and which preserves the confidentiality of users while ensuring real-time, reliable communication.

Summary of the Invention A messaging system and method according to an embodiment of the present invention collects, records and maintains subscriber profiles for a group of people sharing a particular common attribute or association, such as an association with a particular school, business, town, etc. This subscriber profile is collected during a subscription process, arid includes contact information for all communication devices by which a particular person can be reached, including home, work and mobile phone numbers, pager(s), PDAs, email address(es) and web site(s). Each subscriber is then assigned a unique subscriber ID. The entire group of subscribers is termed a community, and the

- - community is commonly _ assigned _a _unique community ID. ._. A sub-group of the community is assigned a unique sub-community ID. According to the present invention, a subscriber wishing to send a message to another subscriber(s) selects an appropriate unique subscriber ID, community ID or sub- community ID assigned to a particular person or group of persons, and typically prepares the message by entering it via the Internet. Also via an Internet interface, system administrators are presented with a series of custom-tailored admin tools for utilizing the present invention whenever they need it. This interface might include grouping mechanisms reflective of a particular community's needs (for example, in a school setting, grouping may be by whole school, grade, class, club/team, blended/extended family, etc.), a suite of preprogrammed message types and messages specific to a particular community, a mechanism for linking the urgency of the message to the ti eframe for delivery, and a message tracking/feedback system.

Subsequently, the message is sent over the Internet to all of the selected recipients, via the communication devices that they specified during subscription. Importantly, at the time the message is sent, it is not necessary for the sender of the message to individually specify the recipients within a particular community or sub-community, or the types of communication devices, since these parameters are pre-set. As a result, messages can be universally broadcast to a desired group in a very fast and efficient manner, and the odds that the selected recipients will actually receive the message in a timely fashion are dramatically increased.

Moreover, the present invention is extremely easy to administer and maintain. This is because subscribers are in charge of creating and maintaining their own profiles (although system administrators have access to subscriber profiles), and can create, join or leave a community as desired. Also, since a subscriber generally need only share his or her unique subscriber ID, a subscriber can be included as a message recipient without having to publicly divulge his or her contact information.

Other features and advantages of the invention will become apparent from the following drawings and description.

Brief Description of the Drawings

Fig. 1 is an example of a browser-based control interface according to an embodiment of the present invention. Fig. 2 is an example of a browser-based compose interface according to an embodiment of the present invention.

Fig. 3 is an overview of the high level components in an exemplary architecture overview of an embodiment of the present invention. Fig. 4 demonstrates an exemplary network architecture according to an embodiment of the present invention.

Fig. 5 is a flowchart demonstrating a subscription process according to an embodiment of the present invention.

Fig. 6 is a flowchart demonstrating a process for managing communities according to an embodiment of the present invention.

Fig.7 is a flowchart demonstrating a process for joining a community according to an embodiment of the present invention.

Fig. 8 is a flowchart .demonstrating, a process for composing a message according to an embodiment of the present invention. Fig. 9 is a flowchart -illustrating- a process- for sending a message to multiple recipients and communication devices according to an embodiment of the present invention.

Detailed Description

A preferred embodiment of the present invention begins with subscription by persons wishing to utilize the present invention (typically this subscription occurs online; i.e., via the Internet). During subscription, members become subscribers by providing multiple contact numbers and indicating their contact preferences for various messaging situations (e.g., emergency and non-emergency). This contact information is part of a unique subscriber profile, and the subscriber profile is stored in a database, for (password- protected) access by a system administrator(s) only. In addition, system administrators can also become subscriber via online subscription.

Each subscriber is assigned a unique subscriber ID. The entire community of subscribers is assigned a unique community ID. Groups of subscribers within the community (e.g., all parents having students in a particular grade at a particular school) make up various sub-communities, each of which is assigned a unique sub-community ID.

Each subscriber is associated with one or more roles that belong to a particular community (or sub-community), and each role assigns one or more permissions to a subscriber. These permissions include, inter alia, the ability to send messages to the community, administer the community, add members to the community, view the community members, or perform corresponding functions within sub-communities. Message senders -access and activate the present invention via a designated portal homepage. Activating a special button (referred to hereinafter as a "Blast" button) on the designated portal homepage launches a browser-based- control interface 100,- hich is shown in Fig. 1. Through this interface, a subscriber can send a message. For example, the subscriber can designate (perhaps from a prepopulated list) message recipients in box 101, a type of message in box 102 and a priority level (for example, urgent, timely, standard) in boxes 103. The priority levels may have preset meanings. For example; "urgent" might mean messages are guaranteed to be sent within a specified period of time, and/or are sent multiple times (perhaps until recipient acknowledges receipt); "timely" might mean messages are sent once via all possible communications devices; and "standard" might mean messages are sent once via email only. Once the above designations are made, the subscriber then selects the compose link 104 to launch a browser-based Compose interface.

An example of a Compose interface 200 is shown in Fig. 2. In the Compose interface 200, the subscriber can compose a subject in text box 201, and then compose the message in onscreen text box 202 (which also allows a selection of prewritten messages), and then preview the message for accuracy. The subscriber can then select either Save as

Draft 203, Cancel 204 or Send 205.

Figure 3 demonstrates high-level components for an exemplary architecture 300 contemplated for implementation of the present invention. The core component is Application Server 301, which is, for example, BEA weblogic 4.0. The Application Server 301 is preferably a Java engine used to format dynamic web pages and execute business logic. Content is delivered to a user using a web server 302 (via HTML and other mime types as implemented on web browsers, etc.), such as Netscape Enterprise Server 4.0. The web server can communicate with the Application Server 301 using a Netscape Server Applicati Program^~Interface (NSAPI) plugin and a desired weblogic protocol. Content which is generated by the Application Server 301 can be delivered using SMTP server 303 for email, paging server 304 for paging devices, speech server 305 for voice devices, and fax server 306 for fax messages. Note that speech server 305 may comprise a text-to-speech converter such as the Lucent iSpeech™ Server. Additionally, a wireless (WAP) gateway can be used; however, note that the preferred use of this gateway is not to push messages out to the subscriber, but to enable a subscriber to use a wireless device to browse the message interfaces (such as those shown in Figs. 1 and 2) and initiate Blast messages. Fig. 4 demonstrates an exemplary network architecture of the present invention. In

Fig. 4, a Blast Node 400 is connected to the Public Internet 401 through firewall 402 and router 403, and contains the various servers described above, such as paging server(s) 404, mail server(s) 405 and text-to-speech server(s) 406, web server(s) 407, application servers(s) 408 and database server 409, connected via Ethernet network 410.

The various servers are of course connected externally so as to dispatch a message to the corresponding communication device; in particular, text-to-speech server 406 is shown as connected via Primary Rate Interface (PRI), through multiplexer 411 and using

D-channel signaling, to voice switch 412 and thereby to Public Switched Telephone Network (PSTN) network 413.

Thus, Figs. 1 -4 describe examples of user interfaces and architecture according to the present invention. Hereafter, the flowcharts of Figs. 5-9 describe exemplary methodologies- Tor- practicing . -various features of the invention using the elements described with respect to Figs. 1-4. More particularly, Fig^~5 ^~illustrates^~how^~a^~-user subscribes -to a system implementing the present invention. In step 501, a user chooses to subscribe and in step 502 enters one or more sets of profile information, including a subscriber ID suggested by the subscriber.

According to one embodiment of the invention, such a subscriber profile may simply contain all of the contact information which the subscriber wishes to divulge to the system, such as the subscriber's mobile phone number, email address, etc. However, the subscriber profile can also be configured in more detail, according to the wishes of the subscriber. For example, the subscriber may designate different communication devices according to the type, content or level of urgency of a message, or according to the sender of the message. Thus, the subscriber profile may include that messages marked "timely" (as described above) should be sent only to his or her home telephone, whereas messages marked "urgent" should be sent to all available communication devices. Similar designations could be made regarding the sender of the message, so that, for example, messages from a school principal are given special status. The subscriber profile could also reserve a special email address or mobile phone number for certain types of messages (e.g., urgent messages). In fact, a subscriber could choose to have multiple subscriber profiles, with a corresponding number of subscriber IDs, where each profile is configured to a particular need of the user. It is important to note, however, that all of the information included in the subscriber profile (including, as another example, a language preference of the subscriber, which is discussed in more detail below) is completely transparent to other members of the community. -Thus, only knowledge of a particular subscriber ID is required to send a message in the exact manner desired by that subscriber. Moreover (as described in more detail below)7air of the^"profile^~information^~can be completely updated and maintained by the subscriber, making a system implementing the present invention extremely easy to administer and utilize.

Whatever the configuration of the profile information, the profile information is submitted in step 503, and in step 504 the suggested subscriber ID is checked to see if it already exists within the system. If it already exists, then the subscriber must enter another subscriber ID in step 505 and then return to step 503. Otherwise, the subscriber is presented with a confirmation page in step 506, and the information is stored in a Lightweight Directory Access Protocol (LDAP) database in step 507. Thus, a subscriber is completely responsible for updating his or her subscriber profile. Hence, although system administrators may have access to the profiles, it is not necessary for the administrators to update all of the subscribers' various contact information. Moreover, using the above methodology, only the subscriber's unique subscriber ID is visible to the other subscribers. Therefore, as will be seen with regard to Figs. 6-8, messages can be sent and the system can be managed/configured entirely based on these unique subscriber IDs, resulting in a system which is fast, confidential, and easy to administer.

Figure 6 is a flowchart that demonstrates an exemplary methodology of how communities are managed in the present invention. In general, a subscriber with proper authorization can, at any time, preview, edit, create, modify or delete a community. Also, the methodology of Fig. 6 can apply to either a community as a whole, or to sub- communities thereof^ therefore, in Fig. 6 (as well as in remaining Figs. 7 and 8), the term community, unless indicated otherwise, is used generically to mean either community or sub-community. - - - - - — — - --- —

In step 601, a subscriber logins into and is authenticated into a system implementing the present invention. Step 602 presents the subscriber with the choice of three possible steps: step 603 to create a community, step 607 to edit a community and step 618 to delete a community. If the subscriber chooses to create a community in step 603, a new community name is required in step 604 and the subscriber is asked to confirm this in step 605, if not then the flow returns to step 603. Otherwise, the community is created and stored in the LDAP database in step 606. In step 607 the subscriber chooses to edit a community. After the community to be edited has been selected in step 608, the subscriber can choose to invite members to the community in step 609, edit a community name in step 612, remove members in step 613, or create a sub-community in step 616. Those who are invited are sent an email invitation in step 610 (using subscriber

IDs to invite subscriber and email addresses to invite non-subscribed users). The email message contains links to enable the invitee to subscribe (if currently a non-subscribed user), join the community (if already subscribed) or decline the invitation. The invitation list is saved to the LDAP database in step 611 (the process for joining a community is illustrated in more detail in Fig.7).

A sub-community can be created in step 617 from a list of members of the community. Step 614 asks the subscriber to confirm any edits, if the confirmation is not given the subscriber is returned to step 607, otherwise the updated- community is saved to the LDAP database in step 615. The subscriber creating the community ls^~aufoiriatically^~assigned ^"the community manager and "blastor" role (i.e., a community member able to send a message to other community members) As the community manager, the blastor can assign roles to members to allow them to initiate blasts or view the other members. In addition, the community manager is automatically authorized to create sub-communities from the commumty. If the subscriber chooses to delete a commumty in step 618, he or she is prompted to select a community in step 619 and asked to confirm in steps 620 and 621. If the subscriber does not confirm, the flow returns to step 618, otherwise the community is deleted from the LDAP database in step 622. Although the above description has been given only in terms of the members of the community, it is important to note that the present invention contemplates implementation and administration by way of an administrator external to the community. For example, such an external administrator may maintain the user interfaces and system architecture described with respect to Figs. 1-4. Additionally, the external administrator may undertake any of the methodology regarding the process of managing the communities just described with respect to Fig. 6, and may also be responsible for maintaining, grouping and listing the subscriber profiles which a community manager accesses in order to, for example, compose an invitation list, create a sub-community, and so forth. In this embodiment, the external administrator preferably has access to the subscriber profiles. In this way, for example, a subscriber in a school setting wishing to create a community or sub-community made up of all elementary school parents can choose from an invitation list listing all such parents, where the list is made available by the external administrator. Moreover, the responsibilities and capabilities just described (as well as any other feature of the invention described herein) may be divided in any desired manner between the external administrator and one or more members of the community (such as, in a school setting, the school principal), and still be within the scope of the invention.

As is apparent from the above description, managing communities according to the present invention is extremely fast, easy and convenient. In creating, editing or deleting communities, it is not necessary for a community manager to have knowledge of (or access to) the other subscribers' contact or other personal information. Moreover, the community manager need not be concerned that the other subscribers' contact information is outdated, since each subscriber can update his or her own contact information as necessary.

Figure 7 shows a flowchart that demonstrates an exemplary methodology of how a subscriber joins a community. The subscriber is authenticated into the system in step 701, and then selects to join a community in step 702, before selecting a community in step

703. Steps 701 to 703 can be performed, for example, by inserting an appropriate URL

(i.e., link) within the invitation email message (see step 610). Clicking on the link would prompt a subscriber to login (if not already logged in) and the subscriber could then be taken automatically through steps 702 and 703. In step 704 a check is made to determine if the subscriber has been invited; if the subscriber has been, then the invitation list is updated to show the subscriber has accepted in step 705, and the subscriber is then added to the community in step 707. Otherwise, another check is made in step 706 to determine if the community will allow anyone to add themselves; if not the subscriber is denied, otherwise the subscriber is added to the community in step 707. Also, once a subscriber joins the community, he/she is removed from the invitation list and automatically assigned the "blastee" role (i.e., a community member who will receive a particular blast). In addition, the new member can select which aspects of his/her profile, if any besides his/her unique subscriber ID, are visible to the community.

Figure 8 is a flowchart that demonstrates an exemplary methodology of how a subscriber composes a blast message. The subscriber is authenticated into the system in step 801 and then selects to send a message step 802. In step 803, the subscriber can choose to select a message template in step 804, and then continue to enter or edit a message header in step 805. In step 806, a message body is entered or edited, and then a recipient list is formed in step 807 comprising a list of zero, one or more communities and zero, one or more individuals. Once at least one community or individual has been selected, the subscriber is prompted to either send the message immediately in step 808, or send later in step 809. Whether the message is to be sent now or later, the message is previewed in step 810 and sent in step 811.

As described above, the blastor can initiate a blast in a simple three-step process: select an appropriate community, create a text message, and press a button to blast. Because a single community ID for each community (and/or a single subscriber ID for each subscriber) is all that is required to blast the message, the message can be sent as quickly as possible to all of the blastees' communication devices at once. Additionally, as referred to above, it is not necessary for a blastor to have access to blastees' personal and confidential information (such as unlisted phone numbers, etc.), since the blastor sees only the community/ subscriber ID.

Once the message has been blasted, the blastor may be updated as to its delivery status. That is, the blastor may be informed as to wfiether the message is completed, pending or undeliverable. The blastor may also be informed as to the percentage completion/incompletion rate, and/or the time the message(s) were delivered.

Figure 9 is a flowchart that demonstrates an exemplary methodology of how a blast message is propagated to the recipients. In step 901 a blast message is entered into the system (as just explained with respect to Fig. 8) and the community parts of the recipient list are expanded in step 902. Subsequently, all the recipients are expanded into a list of delivery types and delivery addresses in step 903, together with the message to be sent to each delivery address. In addition, each recipient is checked to confirm that they agree to accept the message in step 904. Then, the messages are sent, for example, by email in step 909, by paging server in 910 and telephone in step 911.

Although the present invention has been described in conjunction with the above embodiments, it should be noted that these embodiments are designed only to illustrate, and not limit, the present invention. For example, the present invention might also include bilingual universal messaging, in which school messages can be sent in either English or Spanish. In addition, the present invention may incorporate automatic translation of English messages to Spanish and vice versa.

Claims

What is claimed is: 1. A method of sending a message to members of a community, comprising: (a) registering a subscriber profile for each member, wherein the subscriber profile includes contact information for at least one communication device belonging to each of the members; (b) assigning a unique subscriber ID to each member which corresponds to the member's contact information; (c) selecting at least one message recipient only by designating the at least one message recipient's corresponding subscriber ID; (d) preparing a message; and (e) sending the message to the at least one message recipient via the at least one communication device, wherein the only knowledge of the at least one message recipient which is necessary to send the message is the at least one subscriber ID.

2. The method of claim 1, further comprising: (f) managing the membership of the community, including creating, editing, or deleting the community or sub-communities thereof, wherein the only knowledge of the members necessary to manage the membership is the subscriber IDs.

3. The method of claim 1, wherein step (a) further comprises: (a-1) configuring the subscriber profile such that the message is sent to a designated communication device based on the type, content or sender of the message.

4. The method of claim 3, wherein step (a-1) further comprises registering at least two subscriber profiles, each having a different configuration, and step (b) further comprises assigning at least two subscriber IDs to the member which correspond to the at least two subscriber profiles.

5. The method of claim 1, wherein each member is responsible for maintaining all information contained within his or her own subscriber profile.

6. The method of claim 1, wherein the community is made up of persons associated with a school, including teachers, parents, students and administrators.

7. The method of claim 1, wherein access to a first member's contact information by another member requires the authorization of the first member.

8. The method of claim 1, further comprising: (b-1) assigning a unique community ID which corresponds to all of the subscriber IDs; (c-1) selecting the entire community to receive the message, only by designating the community ID; and (e-1) sending the message to the entire community, wherein the only knowledge of the members of the community necessary to send the message is the community ID.

9. The method of claim 1, further comprising: (b-2) assigning a unique sub-community ID which corresponds to a sub-group of the subscriber IDs; (c-2) selecting the sub-community to receive the message, only by designating the sub-community ID; and 6 (e-2) sending the message to the sub-community, wherein the only knowledge

7 concerning the members of the sub-community necessary to send the message is the sub-

8 community ID.

1 10. The method of claim 1 , wherein step (d) further comprises designating the message

2. as urgent, and further wherein step (e) further comprises sending the message multiple

3 times to ensure receipt of the message.

1 11. The method of claim 1, wherein step (d) further comprises entering the message

2 via the Internet.

1 12. The method of claim 11, wherein step (d) still further comprises choosing a desired message from a selection of pre-configured messages.

1 13. The method of claim 1, wherein the message is textually entered via the Internet, and further wherein the text message is converted to speech when required by one of the registered communications devices.

1 14. The method of claim 1, wherein the subscriber profile includes a preferred language of each member, and further wherein step (e) further comprises sending the message in the preferred language.

1 15. The method of claim 1 , further comprising: (f) tracking the message to determine its delivery status.

1 16. A method for sending a message to members of a community, comprising only: selecting an ID which uniquely corresponds to contact information of a member or a plurality of members; entering a message via an Internet interface; and sending the message, based only on a single action and requiring knowledge only of the ID, to the member or plurality of members.

17. A system for sending a message to members of a community, comprising: a database containing a subscriber profile and corresponding unique subscriber ID for each of the members, wherein the subscriber profile includes contact information for at least one communication device belonging to each member; an interface through which a message and message characteristics are entered into the system, wherein the message characteristics include at least one recipient designated only by that recipient's subscriber ID; an application server connected to the interface, which accesses the database to determine corresponding contact information for the at least one recipient based on the recipient's unique subscriber ID; and a plurality of servers which receive the message from the application server and forward the message to all selected communication devices, based on the contact information corresponding to the at least one recipient.

18. The system of claim 17, further comprising at least one interface through which an authorized member may manage the membership of the commumty, including creating, editing, or deleting the community or sub-communities thereof, wherein the only knowledge of the members necessary to manage the membership is the subscriber IDs.

19. The system of claim 17, wherein each member is responsible for maintaining all information contained within his or her own subscriber profile.

20. The system of claim 17, wherein the subscriber profile is configured such that the message is sent to a designated communication device based on the type, content or sender of the message.

21. The system of claim 20, wherein at least two subscriber profiles are registered for a member, each having a different configuration, and further wherein at least two subscriber IDs are assigned to the member which correspond to the at least two subscriber profiles.

22. The system of claim 17, wherein the community is made up of persons associated with a school, including teachers, parents, students and administrators.

23. The system of claim 17, wherein the database additionally stores a single, unique community ID which is commonly assigned to the entire membership of the community, and further wherein the message characteristics include a designation of the entire community as message recipients using only the community ID.

24. The system of claim 17, wherein the database additionally stores a unique sub- community ID which is commonly assigned to a sub-group of the community, and further wherein the message characteristics include a designation of the sub-community as message recipients using only the sub-community ID.

25. The system of claim 17, wherein one of the message characteristics is a designation as urgent, and further wherein the plurality of servers send the message to all necessary communication devices multiple times to ensure receipt of the message.

26. The system of claim 17, wherein the interface through which the message is entered is the Internet.

27. The system of claim 26, wherein the database contains a selection of pre- configured messages, one of which is chosen as the message to be sent.

28. The system of claim 17, wherein the message is textually entered via the Internet, and further wherein one of the plurality of servers is a text-to-speech server which converts the text message to speech.

29. The system of claim 17, wherein the subscriber profile includes a preferred language of the registered person, and further wherein the application server and the plurality of servers deliver the message in the preferred language.

30. The system of claim 17, wherein the application server tracks the message to determine its delivery status.

31. A method of sending a message to members of a community, comprising: (a) registering a subscriber profile for each member, wherein the subscriber profile includes contact information for at least one communication device belonging to each of the members; (b) assigning a unique subscriber ID to each member. which corresponds to the member's contact infoπhation; (c) selecting at least one message recipient only by designating the at least one message recipient's corresponding subscriber ID; (d) preparing a message; and (f) sending the message to the at least one message recipient via the at least one communication device, using the at least one subscriber ID.

32. The method of claim 31 , further comprising: (f) managing the membership of the community, including creating, editing, or deleting the community or sub-communities thereof, using the subscriber IDs.

33. The method of claim 31, wherein the subscriber profile includes contact information for at least two communication devices, and further wherein the message is sent to the at least one member via the at least two communication devices.

34. The method of claim 33, wherein at least two message recipients are selected, each recipient receiving the message via at least two communication devices.

35. A system for sending a message to members of a community, comprising: 4 a database containing a subscriber profile and corresponding unique subscriber ID

5 for each of the members, wherein the subscriber profile includes contact information for at

6 least one communication device belonging to each member;

7 an interface through which a message and message characteristics are entered into

8 the system, wherein the message characteristics include at least one recipient designated

9 by that recipient's subscriber ID;

10 an application server connected to the interface, which accesses the database to

[ 1 determine corresponding contact information for the at least one recipient based on the

12 recipient's unique subscriber ID; and

'.3 a plurality of servers which receive the message from the application server and

A forward the message to all selected communication devices, based on the contact

.5 information corresponding to the at least one recipient.

1 36. The system of claim 35, further comprising at least one interface through which an

2 authorized member may manage the membership of the community, including creating,

3 editing, or deleting the community or sub-communities thereof, wherein the membership

4 is managed using the subscriber IDs.

1 37. The system of claim 35, wherein the subscriber profile includes contact

2 information for at least two communication devices, and further wherein the message

3 characteristics include at least two recipients designated by their respective subscriber IDs.

1 38. The system of claim 37, wherein at least two message recipients are selected, each

2 recipient receiving the message via at least two communication devices.

39. The system of claim 35, wherein at least a portion of the system is administered to the community by a party which is external to the community.