Home
Patent Search
IMT Blog
REGISTER
|
SIGN IN
United States Patent Application
20030095555
Kind Code
A1
McNamara, Justin ; et al.
May 22, 2003
System for the validation and routing of messages
Abstract
A router for directing messages across a bus in a telecommunications system. The router comprises a bus interface and a processor. The bus interface is coupled to the bus and is operable to receive routing request in a common format from the bus, where the routing request comprising a destination device address. The processor is coupled to the bus interface and is operable to receive the routing request from the bus interface and determine routing information based on the destination device address.
Inventors:
McNamara; Justin
(Atlanta, GA)
, Lewis; John Ervin
(Lawrenceville, GA
)
, Lai; Danh Tan
(Fremont, CA
)
, Schlieber; Karl J.
(Flemington, NJ
)
, Tam; Richard Man-Keung
(Austin, TX
)
, Lee; Jessie T.
(Austin, TX
)
, Richardson; Simon James
(Pflugerville, TX
)
Correspondence Name and Address:
5565 GLENRIDGE CONNECTOR, 9TH FLOOR MC 920 C/O LINDA GILES, SYSTEM ANALYST
CINGULAR WIRELESS
ATLANTA
GA
30342
US
Series Code:
299181
Filed:
November 18, 2002
U.S. Current Class:
370/401
U.S. Class at Publication:
370/401
Intern'l Class:
H04L 012/28
Claims
What is claimed is:
1. A router for directing messages across a bus in a telecommunications infrastructure, comprising: a bus interface coupled to the bus, the bus interface operable to receive a routing request for one of the messages, the routing request being in a common format from the bus, the routing request comprising a destination device address; and a processor coupled to the bus interface, the processor operable to receive the routing request from the bus interface and determine routing information for the message based at least in part on the destination device address.
2. The router of claim 1, wherein the processor is further operable to generate a routing reply comprising the routing information; and wherein the bus interface is further operable to transmit the routing reply on the bus.
3. The router of claim 2, further comprising a routing database in communication with the processor, the routing database comprising the routing information for device addresses.
4. The router of claim 3, wherein the processor is further operable to extract the routing information from the routing database.
5. The router of claim 4, wherein the routing information in the routing database comprises at least one of the following for a device address: a device type, a device address, and an adapter.
6. The router of claim 5, wherein the routing request further comprises an originating device address.
7. The router of claim 6, wherein the routing information in the routing database further comprises an approved list associated with the destination device address; and wherein the processor is operable to return a valid response in the routing information if the originating device address is in the approved list.
8. The router of claim 6, wherein routing information in the routing database further comprises a disapproved list associated with the device address; and wherein the processor is operable to return an invalid response in the routing information if the originating device address is in the disapproved list.
9. The router of claim 5, wherein the routing information in the routing database further comprises a password associated with the device address; and wherein the processor is operable to return a password request response in the routing information.
10. The router of claim 6, wherein the routing information in the routing database further comprises a class of service associated with the device address; and wherein the processor is operable to return an invalid response in the routing information if the class of service of the originating device address does not meet the class of service associated with the destination device address.
11. The router of claim 6, wherein the routing database comprises a prepaid subscriber database in communication with the processor, the prepaid subscriber database containing account balance information for each device address.
12. The router of claim 11, wherein the processor is further operable to query the prepaid subscriber database upon receipt of the routing request and return an invalid response in the routing information if the account balance information associated with the originating device address is less than a message charge amount.
13. The router of claim 11, wherein the processor is further operable to query the prepaid subscriber database upon receipt of the routing request and return an invalid response in the routing information if the account balance information associated with the destination device address is less than a message charge amount.
14. The router of claim 2, further comprising a user alias database in communication with the processor; and wherein the routing request comprises an alias, the user alias database containing data associating the alias with one or more destination device addresses.
15. The router of claim 14, wherein the processor is operable to extract the one or more destination device addresses associated with the alias from the user alias database and generate a routing reply containing the routing information for each of the one or more destination device addresses.
16. The router of claim 15, further comprising a routing database in communication with the processor, the routing database comprising the routing information for the one or more destination device addresses.
17. The router of claim 16, wherein the processor is further operable to extract the routing information from the routing database for each of the one or more destination device addresses.
18. The router of claim 17, wherein the routing information in the routing database comprises at least one or more of the following for each of the one or more destination device address: a device type, a device address, and an adapter.
19. The router of claim 18, wherein the routing request further comprise an originating device address.
20. The router of claim 19, wherein routing information in the routing database further comprises an approved list associated with the destination device address; and wherein the processor is operable to return a valid response in the routing information if the originating device address is in the approved list.
21. The router of claim 19, wherein routing information in the routing database further comprises a disapproved list associated with the device address; and wherein the processor is operable to return an invalid response in the routing information if the originating device address is in the disapproved list.
22. The router of claim 18, wherein routing information in the routing database further comprises a password associated with the device address; and wherein the processor is operable to return a password request response in the routing information.
23. The router of claim 19, wherein the routing information in the routing database further comprises a class of service associated with the device address; and wherein the processor is operable to return an invalid response in the routing information if the class of service of the originating device address does not meet the class of service associated with the destination device address.
24. The router of claim 19, further comprising a prepaid subscriber database in communication with the processor, the prepaid subscriber database containing account balance information for each device address.
25. The router of claim 24, wherein the processor is further operable to query the prepaid subscriber database upon receipt of the routing request and return an invalid response in the routing information if the account balance information associated with the originating device address is less than a message charge amount.
26. The router of claim 24, wherein the processor is further operable to query the prepaid subscriber database upon receipt of the routing request and return an invalid response in the routing information if the account balance information associated with the destination device address is less than a message charge amount.
27. A method of routing messages in a telecommunications system, comprising: receiving a routing request in a common format from a bus in the telecommunications system, the routing request comprising a destination device address; extracting routing information from a routing database for the destination device address; generating a routing reply to the routing request, the routing reply comprising the routing information; and returning the routing reply on the bus.
28. The method of routing messages of claim 27, wherein extracting the routing information further comprises extracting device address information from the routing database for the destination device address.
29. The method of routing messages of claim 28, wherein the routing information comprises the device address information.
30. The method of routing messages of claim 27, wherein the routing request further comprises an originating device address; and wherein extracting routing information further comprises checking the originating device address against an approved list associated with the destination device address in the routing database.
31. The method of routing messages of claim 30, wherein the routing information contains a valid response if the originating device address is in the approved list associated with the destination device address.
32. The method of routing messages of claim 27, wherein the routing request further comprises an originating device address; and wherein extracting routing information further comprises checking the originating device address against a disapproved list associated with the destination device address in the routing database.
33. The method of routing messages of claim 32, wherein the routing information contains an invalid response if the originating device address is in the disapproved list associated with the destination device address.
34. The method of routing messages of claim 27, wherein extracting the routing information further comprises retrieving a password associated with the destination device address in the routing database.
35. The method of routing messages of claim 34, wherein the routing information contains a password response.
Description
RELATED APPLICATIONS
[0001] The application claims the benefit of priority from provisional U.S. Patent Application Serial No. 60/332,376 filed Nov. 16, 2001 which is expressly incorporated herein by reference.
[0002] Set forth below is a complete list containing the names of this application and related commonly owned U.S. patent applications entitled "Telecommunications System Messaging Infrastructure", A System for Translation and Communication of Messaging Protocols into a Common Protocol", A System for the Validation and Routing of Messages", A System for the Storage and Retrieval of Messages", A System for Handling Proprietary Files", A System for Handling File Attachments", A System for the Centralized Storage of Wireless Customer Information", A System for Customer Access to Messaging and Configuration Data", A System and Method for Querying Message Information", A System and Method for Password Protecting a Distribution", A System and Method for Providing Message Notification", Methods and Systems for Routing Messages Through a Communications Network Based on Message Content", and Methods and Systems for Tracking and Playing Back Errors in a Communications Network" filed on the same date herewith.
DESCRIPTION OF THE INVENTION
BACKGROUND OF THE INVENTION
[0003] As we progress into the twenty-first century, communications systems continue to enhance the interconnectedness of mankind. In particular, mobile telephony permits individuals to stay in contact with each other, without the prior limitations of being tied to land line systems. With the simple act of dialing a telephone number, a cellular telephone user can contact anyone possessing a telephone for instant voice communication. As mobile telephony technology improves, engineers have developed additional means of communicating using a cell phone. These include various forms of short messaging and email.
[0004] Unfortunately, while voice communication across multiple plain old telephone systems (POTS) and varying cell phone technologies is possible due to compatibility of the systems, users of mobile telephony products have difficulty communicating with each other over different systems and standards. For instance, a cell phone user having access to short messaging service (SMS) messages can not send an SMS message to a user utilizing a Research-in-Motion (RIM) pager which operates using Mobitex messages. Things become even more difficult when those users are operating with different service providers.
[0005] A system is needed to provide mobile telephony product users access to differing messaging types, such that messages sent in a first format can be received by a user in a second format. Such a system should provide a system and method of routing the messages within the system and validate addressing for such routing.
SUMMARY OF THE INVENTION
[0006] In accordance with an aspect of the present invention, a router for directing messages across a bus in a telecommunications system is disclosed. The router comprises a bus interface and a processor. The bus interface is coupled to the bus and is operable to receive routing request in a common format from the bus, where the routing request comprising a destination device address. The processor is coupled to the bus interface and is operable to receive the routing request from the bus interface and determine routing information based on the destination device address.
[0007] In accordance with another aspect of the present invention, a method of routing messages in a telecommunications system is disclosed. The method receives routing request in a common format from a bus, where the routing request comprise a destination device address. Next, the method extracts routing information from a routing database for the destination device address and generates a routing reply to the routing request, the routing reply comprising the routing information. Next, the method returns the routing reply on the bus.
[0008] Additional objects and advantages of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. The objects and advantages of the invention will be realized and attained by means of the elements and combinations particularly pointed out in the appended claims.
[0009] It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention, as claimed.
[0010] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate one (several) embodiment(s) of the invention and together with the description, serve to explain the principles of the invention.
BRIEF DESCRIPTION OF THE DRAWINGS
[0011] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate one embodiment of the invention and together with the description, serve to explain the principles of the invention.
[0012] FIG. 1 illustrates a diagram of a messaging infrastructure 100 in an exemplary embodiment consistent with the present invention.
[0013] FIG. 2 illustrates a diagram of an adaptive routing concentrator in an exemplary embodiment consistent with the present invention.
[0014] FIG. 3 illustrates a diagram of a routing and validation entity in an exemplary embodiment consistent with the present invention.
[0015] FIG. 4 illustrates a flowchart of message delivery in an exemplary embodiment consistent with the present invention.
[0016] FIG. 5 illustrates a flowchart of the operation of an ARC functioning to receive a message from a messaging element in an exemplary embodiment consistent with the present invention.
[0017] FIG. 6 illustrates a flowchart of the operation of the message receipt stage of an ARC in an exemplary embodiment consistent with the present invention.
[0018] FIG. 7 illustrates a flowchart of the operation of the routing request publication stage of an ARC in an exemplary embodiment consistent with the present invention.
[0019] FIG. 8 illustrates a flowchart of the operation of the receipt of a routing reply stage of an ARC in an exemplary embodiment consistent with the present invention.
[0020] FIG. 9 illustrates a flowchart of the operation of the translation stage of an ARC in an exemplary embodiment consistent with the present invention.
[0021] FIG. 10 illustrates a flowchart of the operation of an ARC functioning to transmit a message from the network transport bus in an exemplary embodiment consistent with the present invention.
[0022] FIG. 11 illustrates a flowchart of the operation of a RAVE for routing messages in an exemplary embodiment consistent with the present invention.
[0023] FIG. 12 illustrates a flowchart of the operation of the routing request receipt stage of a RAVE in an exemplary embodiment consistent with the present invention.
[0024] FIG. 13 illustrates a flowchart of the operation of the extraction of routing information stage of a RAVE in an exemplary embodiment consistent with the present invention.
[0025] FIG. 14 illustrates a diagram of a Data Storage and Routing Terminal in an exemplary embodiment consistent with the present invention.
[0026] FIG. 15 illustrates a simplified view of the messaging infrastructure 100 illustrated in FIG. 1 in an exemplary embodiment consistent with the present invention.
[0027] FIG. 16 illustrates a flow chart of the operation of a DART element in an exemplary embodiment consistent with the principles of the present invention.
[0028] FIG. 17 illustrates the receipt of a request by a DART entity in an exemplary embodiment consistent with the principles of the present invention.
[0029] FIG. 18 is a flow chart illustrating the operation of a DART entity performing a store function in an exemplary embodiment consistent with the principles of the present invention.
[0030] FIG. 19 illustrates a query request performed by a DART entity in an exemplary embodiment consistent with the principles of the present invention.
[0031] FIG. 20 illustrates a cancel request performed by a DART entity in an exemplary embodiment consistent with the principles of the present invention.
[0032] FIG. 21 illustrates an external mail request performed by a DART entity in an exemplary embodiment consistent with the principles of the present invention.
[0033] FIG. 22 illustrates a method for limiting access to a proprietary file such as a ring tone in an exemplary embodiment consistent with the principles of the present invention.
[0034] FIG. 23 depicts an method for handling attachments to messages in an exemplary embodiment consistent with the principles of the present invention.
[0035] FIG. 24 illustrates the Mail Transfer Gateway 170 interfaced to the messaging infrastructure 100 in an exemplary embodiment consistent with the principles of the present invention.
[0036] FIG. 25 illustrates a flow chart of the operation of an MTA element in an exemplary embodiment consistent with the principles of the present invention.
[0037] FIG. 26 illustrates the execution of a validation function by an MTA entity in an exemplary embodiment consistent with the principles of the present invention.
[0038] FIG. 27 illustrates the execution of various anti-spamming functions by an MTA entity in an exemplary embodiment consistent with the principles of the present invention.
[0039] FIG. 28 depicts a MIND database 137 in an exemplary embodiment consistent with the principles of the present invention.
[0040] FIG. 29 illustrates the database business logic component of the messaging infrastructure in an exemplary embodiment consistent with the principles of the present invention.
[0041] FIG. 30 depicts an exemplary embodiment of the MIND database in an exemplary embodiment consistent with the principles of the present invention.
[0042] FIG. 31 illustrates a flow chart of a bulk load operation performed by the MIND in an exemplary embodiment consistent with the principles of the present invention.
[0043] FIG. 32 depicts an incremental update of data contained in the databases of the infrastructure in an exemplary embodiment consistent with the principles of the present invention
[0044] FIG. 33 illustrates an SCI in an exemplary embodiment consistent with the principles of the present invention.
[0045] FIG. 34 depicts a method for querying or tracking a message based on a unique identifier in an exemplary embodiment consistent with the principles of the present invention.
[0046] FIG. 35 depicts a method for password protecting a subscriber-created distribution list in an exemplary embodiment consistent with the principles of the present invention.
[0047] FIG. 36 depicts a method for designating a type of message notification in an exemplary embodiment consistent with the principles of the present invention.
[0048] FIG. 37 depicts a method for providing message information to a subscriber based on the contents of a cookie in an exemplary embodiment consistent with the principles of the present invention.
[0049] FIG. 38 illustrates a flow chart of the operation of an SCI in an exemplary embodiment consistent with the principles of the present invention.
[0050] FIG. 39 illustrates the receipt of a response by the SCI in an exemplary embodiment consistent with the principles of the present invention.
[0051] FIG. 40 is an exemplary flow diagram that illustrates the processing of a response by the SCI in an exemplary embodiment consistent with the principles of the present invention.
[0052] FIG. 41 illustrates a LAMB in an exemplary embodiment consistent with the principles of the present invention.
[0053] FIG. 42 illustrates an exemplary method for administering an error condition in accordance with an embodiment of the present invention.
[0054] FIG. 43 illustrates an exemplary method for stepping through a message transmission consistent with an embodiment of the present invention will now be described.
[0055] FIG. 44 illustrates a first exemplary embodiment of a content router may be operatively connected to a multiplexer consistent with the principles of the present invention.
[0056] FIG. 45 illustrates another exemplary system environment with a content router in which to practice an embodiment of the present invention.
[0057] FIG. 46 illustrates a flowchart of an exemplary method for retrieving information with a content router consistent with an embodiment of the present invention.
[0058] FIG. 47 illustrates another exemplary method for retrieving information using a content router according to an exemplary embodiment of the present invention.
DETAILED DESCRIPTION
[0059] Reference will now be made in detail to the present exemplary embodiments of the invention, examples of which are illustrated in the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts.
Definitions and Acronyms
[0060] Unless otherwise stated or evident based on the context used, the following terms and acronyms will be defined as follows:
[0061] ARC--Adaptive Routing Concentrators.
[0062] BITBUS--Backbone Integration Transport.
[0063] COS--Class of Service.
[0064] CR--Content Routers.
[0065] DART--Data Storage and Routing Terminals.
[0066] EMS--Enhanced Messaging Service.
[0067] IM--Instant Messaging.
[0068] IMAP--Internet Message Access protocol.
[0069] JBBC--JAVA database connectivity.
[0070] LAMB--Logging Administration Maintenance and Billing.
[0071] LDAP--Lightweight data application protocol.
[0072] MDS--Message Data Store.
[0073] MIME--Multipurpose Internet Mail Extensions.
[0074] MIND--Master IT and Network Database.
[0075] MTA--Mail Transfer Agent.
[0076] MTG--Mail Transfer Gateway.
[0077] ODBC--Open Database connectivity.
[0078] POP--Post Office Protocol.
[0079] RAVE--Routing and Validation Entities.
[0080] RVDB--Routing and Validation Database.
[0081] SOAP--Simple Object Access Protocol
[0082] SCI--Subscriber Interface.
[0083] SMPP--Short Message Peer to Peer.
[0084] SMTP--Simple Mail Transfer Protocol.
[0085] TAP--Telecator Alphanumeric Paging Protocol.
[0086] UADB--User Alias Database.
[0087] XML--Extensible Markup Language.
[0088] Overview
[0089] A messaging infrastructure 100 serves to communicate messages from a first device to a second device. While in the prior art messaging tended to be limited to sending and receiving messages only from devices accessible from the same Short Message Service Center (SMSC), exemplary embodiments of a messaging infrastructure 100 consistent with the present invention facilitate the sending and receipt of messages between disparate (or similar) devices, many of which use different messaging protocols and formats, across a range of messaging centers and gateways. In order to assist in this process, messages sent from a first device may be received by a first adapter, which translates the messages into a common format; published onto a network transport bus in a common messaging format; received by a second adapter, which translates the messages into a second device format; and transmitted to the second device. In this fashion messages can be transmitted between various devices having different formats and capacities.
[0090] FIG. 1 illustrates a diagram of a messaging infrastructure 100 in an exemplary embodiment consistent with the present invention. The wireless messaging infrastructure 100 is comprised of a number of network elements communicating over a network transport bus 125. The network transport bus 125 may be a common asynchronous message exchange mechanism for transmitting messages in a common format. One or more Adaptive Routing Concentrators (ARCs) 110a-c provide messaging elements, such as Short Messaging Service (SMS) 105, Enhanced Messaging Service Center (EMCS) 115, and Internet Message Access Protocol/Post Office Protocol (IMAP/POP) server 118 access to and from the network transport bus 125. The ARCs 110a-c (labeled ARC1, ARC2, ARC N) serve to translate messages between a particular messaging element format associated with the messaging element and the common format used on the network transport bus 125. The ARCs 110a-c also may request routing information from routing entities and send the translated messages across the network transport bus 125 to an appropriate destination ARC.
[0091] In exemplary embodiments of the present invention, the one or more routing entities are known as a Routing and Validation Entities (RAVE) 130 which may be accessed by the ARCs 110a-c to perform validation, routing and alias/distribution list functions. The RAVE 130 accesses routing information in a Routing and Validation Database (RVDB) 135 via a Backbone Integration Transport Bus (BITBUS) 132. The RAVE 130 accesses alias and distribution list data in the User Alias Database (UADB) 140. In exemplary embodiments of the present invention, a Master IT and Network Database (MIND) 137 may populate both the RVDB 135 and the UADB 140. The RAVE 130 returns routing information to the ARC 110a-c that requested the routing information. Through the interaction of the ARCs 110a-c, the network transport bus 125, and the RAVE 130, messages into the messaging infrastructure 100 are received, translated, routed, and transmitted to destination devices.
[0092] In addition to these elements, exemplary embodiments of the present invention may also include one or more Data Storage and Routing Terminals (DART) 145a-b (shown as DART 1, DART 2) interfaced to the network transport bus 125 for storing messaging data in a Message Data Store (MDS) 150a-c for access and retrieval at later points in time. The DARTs 145a-b access the MDSs 150a-c via a Backbone DataStore Transport Bus 108. One or more Content Routers 155 interfaced to the network transport bus 125 receive messages addressed to a particular address and redirect the messages to external devices which, for example, may return information requested in the message to the message sender. A Logging Administration Maintenance and Billing Entity (LAMB) 160 interfaced to the network transport bus 125 may log network traffic for error tracking, error replay and billing functions. Also, a Subscriber Configuration Interface (SCI) 165 interfaces to the network transport bus 125 for allowing users to access and update subscriber and messaging device information.
[0093] Exemplary embodiments consistent with the present invention may also include a Mail Transfer Gateway (MTG) 170. The Mail Transfer Gateway 170 may serve as an email gateway between the messaging infrastructure 100 and the Internet 175. To facilitate this function, the Mail Transfer Gateway may be coupled to both the network transport bus 125 and the BITBUS 132.
[0094] It should be noted that this exemplary embodiment illustrated in FIG. 1 and the other figures contained herein is intended to show the overall architecture and certain components of the present invention. It will be appreciated by those skilled in the art that operation of a messaging infrastructure in accordance with the present invention may include all or a subset of these components, or may include additional elements of a similar nature or additional elements with common interfaces as such elements are developed.
[0095] Components of Messaging Infrastructure Architecture
[0096] The following summaries the particular components of the Messaging Infrastructure Hardware.
[0097] Adaptive Routing Concentrator Hardware
[0098] FIG. 2 illustrates a diagram of an adaptive routing concentrator 110 in an exemplary embodiment consistent with the present invention. The adapter, or ARC 110, comprises a messaging interface 210 coupled to a processor 220 coupled to a network transport bus interface 230. The messaging interface 210 communicates between the ARC 110 and a messaging element 205. The message element 205 may be any of a number of messaging elements communicating a variety of messaging protocols. Messaging element 205 may comprise, for example, an SMSC, an Enhanced Messaging Service Center (EMSC), an email gateway operating Simple Mail Transfer Protocol (SMTP), Multipurpose Internet Mail Extensions (MIME) or Short Message Peer to Peer (SMPP), an Instant Messaging (IM) gateway, a push proxy gateway communicating HTTP elements, Telecator Alphanumeric Paging Protocol (TAP), a Mobitex gateway, an IMAP/POP server or any other type of element or gateway.
[0099] Messaging interface 210 is operable to pre-cache messages or post-cache messages, or it performs no caching. Caching is useful where certain messaging elements operate in such a way that messages are segmented into multiple parts. In pre-caching, incoming message segments into the messaging interface 210 are held in the messaging interface 210
until the last segment is received, prior to sending the incoming message to the processor 220. In post-caching, outgoing segmented messages from the messaging interface 210 to the message element 205 are held until the last segment is received from the Processor 220.
[0100] Messaging interface 210 is extensible such that, regardless of the messaging element 205 with which the messaging interface 210 is communicating, the messaging interface 210 can be adapted to communicate with that messaging element 205. Communication between the messaging interface 210 and the messaging element 205 may be unidirectional or bi-directional, such that the ARC 110 may send and/or receive messages with the messaging element 205. In addition, the ARC 110 may comprise multiple messaging interfaces 210, where each interface communicates with a separate messaging element 205.
[0101] The messaging interface 210 communicates with the processor 220. Regarding messages incoming from the messaging interface 210, the processor 220 operates to translate messages between the messaging element 205 format or protocol and the common format utilized on the network transport bus 125. In addition, the processor 220 generates routing requests to a router, generally a RAVE 130. In order to generate a routing request, the processor 220 may, for example, parse the incoming message from the message interface 210 to retrieve an originating address and a destination address from the incoming message. The routing request generated by processor 220 may include the origination address, destination address, and a unique transaction identification that identifies the message. The processor 220 receives a routing response via the network transport bus interface 230 that contains routing information for the received message. Based on that routing response, the processor 220 operates to route messages received from the messaging interface 210
to an appropriate destination.
[0102] Should routing responses contain requests for additional information, such as a password, the processor 220 operates to request the password via the messaging interface 210 from the messaging element 205 and verify the receipt of an accurate password prior to routing the message to its destination. The processor 220 is also operable to send message status information to the messaging element 205 via the messaging interface 210.
[0103] Regarding messages incoming from the network transport bus interface 230, the processor 220 is operable to translate the messages from the common format into the messaging element format and transmit the messages, via the messaging interface 210 to the messaging element 205.
[0104] The translation operation of the processor may be operable to store a plurality of potential messaging element formats within the ARC 110 or only the applicable messaging element format for the messaging element in communication with the ARC 110. The processor 220 may be operable to sense the appropriate messaging element format and adaptively translate the common format between the appropriate messaging element format, or the appropriate messaging element format may be configured into the processor 220.
[0105] The network transport bus interface 230 couples the processor 220
to the network transport bus 125. The network transport bus interface 230
monitors traffic along the network transport bus 125 for messages directed to the ARC 110 and places messages on the network transport bus 125 from the processor 210.
[0106] The Network Transport Bus
[0107] The network transport bus 125 is a data and control bus that operates as a multi-port switch to permit the transfer of messages between various network elements. The network transport bus utilizes a common message format for communication among and between the network elements. In exemplary embodiments of the present invention, the common message format may be Extensible Markup Language (XML) or MIME. While the network transport bus 125 is illustrated as a single common bus, those skilled in the art will appreciate that it may be segmentable and scalable and may be physically broken with firewalls and gateways separating parts of the network transport bus 125. The network transport bus 125 may include a message broker to facilitate communication along the bus and may monitor itself for congestion or other potential problems.
[0108] In an exemplary embodiment consistent with the present invention, messaging across the network transport bus 125 may be point-to-point, multipoint, or broadcast. A point-to-point message utilizes an addressing scheme whereby the message is designated to be received by a single network element. Multipoint messaging utilizes an addressing scheme whereby a single message may be delivered to two or more specified network elements. Broadcast messaging publishes the message onto the network transport bus 125 for receipt by any or all network elements programmed to receive the message.
[0109] Exemplary embodiments consistent with the present invention may utilize a combination of subject and device addressing to send messages along the network transport bus 125. Subject based addressing tends to be broadcast based, tagging a subject address onto a message. Some or all network elements may monitor the network transport bus 125 for subject addresses of interest to that particular network element. For instance, in generating a routing request, an ARC may append the subject address "Routing_Validation" to the header of a message broadcast on the network transport bus. Each of the Network elements interested in reading a "Routing_Validation", such as routers or RAVEs, would read these messages off of the network transport bus 125.
[0110] Exemplary embodiments consistent with the present invention may also append a more specific network element address onto the header along with the subject address. For instance, a routing request may be addressed to "Routing_Validation.RAVE1". In that case, RAVE1 would be the intended RAVE that would read the message associated with the routing request. Other RAVEs would likely not read the message associated with the request; however, error tracking network elements, such as a LAMB, may choose to read the message.
[0111] In addition, messages may have a plurality of headers for messages intended to be received by a variety of different network elements, i.e., a multicast message. For instance, a message sent to a distribution list of recipients may have several headers attached to the message, with each header designating an intended destination network element.
[0112] Network transport bus interfaces, such as network transport bus interface 230, may run daemons that monitor the network traffic for appropriate subject addresses and network element addresses. For instance, ARC1 110a may monitor network traffic for subject addresses such as "Deliver_MSG" (for delivering a message) or "Routing_Validation_Response" (for a routing validation response). ARC1
110a may also monitor any specific network addresses appended to these subject addresses looking for ".ARC1.", in which case ARC1 110a will read the message.
[0113] Routing and Validation Entity Hardware
[0114] FIG. 3 illustrates a diagram of a routing and validation entity 130
in an exemplary embodiment consistent with the present invention. The RAVE 130 comprises a network transport bus interface 310 coupled to the network transport bus 125 and a processor 320 coupled to the network transport bus interface 310. The network transport interface 310 monitors traffic along the network transport bus 125 for messages directed to the RAVE 130 and places routing replies on the network transport bus 125 from the processor 320.
[0115] Similarly to the operation of the ARC's network transport bus interface 230, the RAVE's network transport bus interface 310 may run daemons that monitor the network traffic for appropriate subject addresses and network element addresses. For instance, RAVE 130 may monitor network traffic for subject addresses such as "Routing_Validation" (for receiving a routing request for a message). RAVE 130, through network transport bus interface 310 may also monitor any specific network addresses appended to these subject addresses looking for ".RAVE.", in which case RAVE 130 will read the message.
[0116] Processor 320 interfaces with the network transport bus interface 310 to receive routing requests and generate and transmit routing replies. Upon receipt of a routing request, the processor 320 may extract routing information based on the destination device address and/or the origination device address. If the destination device address is an alias or a distribution list, the processor 320 may look-up the alias or distribution list in the UADB 140 and return one or more actual destination device addresses that correspond to the alias or distribution list.
[0117] In exemplary embodiments consistent with the present invention, the processor 320 may query an RVDB, such as RVDB 135, for routing information for each of the one or more destination device address (more than one in the case of a distribution list). The routing information may contain information, including but not necessarily limited to, the device type of the destination device, device address of the destination device, and an adapter, or ARC (110), that serves the destination device. Routing information may also include a password, if the destination device is password protected. In addition, the origination address may be used in the routing information lookup to determine if the origination device address is on a whitelist (permitted communication) or on a blacklist (barred communication). A class of service indicator may also be looked up for the destination device address, origination device address, or both to ensure that the messaging device has an appropriate class of service prior to routing the message to the destination. In addition, if the destination device address or the origination device address is associated with a prepaid subscriber, the processor 320 may verify sufficient available funds are available to route the message. Data storage options may also be looked up for either the destination device address or the originating device address. Processor 320 may return some or all of this information in the routing reply returned to the requesting ARC.
[0118] While the RAVE 130 and the ARC 110a-c have been discussed as if they were physically separate units, it is foreseen that they may function as distinct processes within a single hardware unit. In that case, communication between the ARC 110a-c and RAVE 130 might be over a logical network transport bus rather than a physical network transport bus.
[0119] In view of the high-level description of RAVES ARC's and the network transport BUS, the process by which messages are received, routed and/or delivered will now be discussed.
[0120] Message Delivery
[0121] FIG. 4 illustrates a flowchart of message delivery in an exemplary embodiment consistent with the present invention. This flowchart illustrates the processes that occur across the ARCs, RAVE, and network transport bus in an exemplary embodiment of the present invention. In this particular example, an SMS message residing in SMS 105 will be delivered as an ESM message via ESMC 115. At stage 405, an ARC, in this example, ARC1 110a, receives an incoming message from an SMSC 105. The message is received by ARC1 110a in SMS format and carries an originating device address and a destination device address. The ARC1 110a parses the incoming message to determine the originating device address and destination device address and assigns a unique transaction identification to the message. At stage 410, ARC1 110a requests routing information by publishing a routing request on the network transport bus. The routing request may contain the destination device address, originating device address, and the unique transaction identification. For optimum efficiency, we prefer that the message itself not be sent in the routing request in an exemplary embodiment of the invention.
[0122] At stage 415, the router, RAVE 130, receives the routing request and extracts routing information. The RAVE 130 may perform a look-up in the RVDB 135 based on the destination device address to extract the routing information. At stage 420, the RAVE 130 publishes the routing information back onto the network transport bus. The ARC1 110a picks up the routing information from the network transport bus.
[0123] At stage 425, the ARC1 110a translates the incoming message from the SMS format to the common format, which may, for example, be either XML or MIME, and appends routing or addressing information onto the common format message. At stage 430, the ARC1 110a publishes the message on the network transport bus. At stage 435, ARC2 110b receives the published message from the network transport bus. At stage 440, ARC2 110b translates the message from the common format to the EMS format, and, at stage 445, ARC2 110b transmits the message to the ESMC 115 for delivery to the destination device.
[0124] Detailed operations of the various network elements follows.
[0125] Adaptive Routing Concentrator Operation
[0126] FIG. 5 illustrates a flowchart of an ARC operating to receive a message from a messaging element in an exemplary embodiment consistent with the present invention. At stage 510, the ARC receives the message from the originating device via the messaging element. At stage 520, the ARC publishes a routing request for routing information for the received message. At stage 530, the ARC receives a routing reply in response to the routing request. At stage 540, assuming the routing request returns a valid response, the ARC translates the message from the incoming messaging format into the common format. At stage 550, the ARC publishes the common message to the destination device over the network transport bus 125.
[0127] FIG. 6 illustrates a flowchart of the operation of the message receipt stage 510 of an ARC in an exemplary embodiment consistent with the present invention. At stage 605, the ARC receives an incoming message from an originating device via a messaging element. At stage 610, the ARC separates the header from the body of the message. At stage 615, the ARC parses the header for an originating device address and a destination device address. At stage 620, the ARC assigns a unique transaction identification to the message. Typically, an ARC contains memory for short term storage of the message, header information, and associated unique transaction identification.
[0128] FIG. 7 illustrates a flowchart of the operation of the routing request publication stage 520 of an ARC in an exemplary embodiment consistent with the present invention. At stage 705, the ARC generates a routing request. Typically, a routing request may be of the following form:
[0129] "Routing_Validation.RAVE_ADDRESS.ORIGINATING_ARC_ADDRES S.TRANSACTION_ID.ORIGINATING_DEVICE_ADDRESS.DESTINATION_DEVIC E_ADDRESS"
[0130] where:
[0131] RAVE_ADDRESS is the address of the destination RAVE for the request. Typically, the ARC will not address the routing request to a particular RAVE, so this field will typically be "RAVE*", meaning any RAVE;
[0132] ORIGINATING_ARC_ADDRESS is the address of the ARC originating the routing request, e.g, ARC1, ARC2, etc.;
[0133] TRANSACTION_ID is the assigned transaction identification of the message;
[0134] ORIGINATING_DEVICE_ADDRESS is the address of the originating device gathered from parsing the header information; and
[0135] DESTINATION_DEVICE_ADDRESS is the address of the destination device gathered from parsing the header information.
[0136] At stage 710, the request is published on the network transport bus.
[0137] Once the ARC publishes the routing request, its tasks relating to this message are complete until the return of a routing reply. FIG. 8
illustrates a flowchart of the operation of the receipt of a routing reply stage 530 of an ARC in an exemplary embodiment consistent with the present invention. At stage 805, the monitor daemon in the ARC monitors traffic on the network transport bus. At stage 815, the daemon examines the header of a message on the network transport bus to determine if the subject address is a routing reply for this particular ARC. Typically, it is searching for "Routing_Validation_Response.ARCn", where ARCn is the address of this ARC that is awaiting the routing reply.
[0138] If an appropriately addressed routing reply is received at stage 815, at stage 820, the ARC will parse the routing reply. At stage 825, the routing reply is examined for an invalid message in the response. An Invalid message in the response may typically be of the following form:
[0139] "Routing_Validation_Response.Invalid.Reason", where Reason could be because of, for example, an insufficient prepaid account, blacklisting, or an insufficient Class of Service (COS).
[0140] If an Invalid response is returned, at stage 830 the ARC examines the reason field to determine if it is because of insufficient funds in a prepaid subscriber's device. If so, an invalid message is returned to the originating device in stage 845. The invalid message may include the reason for the invalid message. Following an invalid message to the originating device in stage 845, at stage 875, further processing of the message is halted, so that the message is not delivered to the recipient. In the exemplary embodiment of the invention, resources are not expended translating the message to the common format if the message is not going to be transmitted across the network transport bus to the destination device.
[0141] If insufficient funds are not the reason for the Invalid reply, at stage 835 the ARC examines the reason field to determine if it is because of a blacklist associated with the destination device. If so, an invalid message is returned to the originating device in stage 845. The invalid message may include the reason for the invalid message. Following an invalid message to the originating device in stage 845, at stage 875, further processing of the message is halted, so that the message is not delivered to the recipient.
[0142] If blacklisting is not the reason for the Invalid reply, at stage 840 the ARC examines the reason field to determine if it is because of an insufficient COS associated with the device. If so, an invalid message is returned to the originating device in stage 845. The invalid message may include the reason for the invalid message. Following an invalid message to the originating device in stage 845, at stage 875, further processing of the message is halted, so that the message is not delivered to the recipient.
[0143] If none of these is the reasons for the Invalid reply, at stage 875, the message is not sent, and, typically an invalid message is sent to the originating device.
[0144] If a valid reply is received in the routing response, e.g., "Routing_Validation_Response.Valid.", at stage 850 the reply is examined to see whether a password has been transmitted in the reply. If a password has been submitted in the reply, this is an indication that the destination device is password protected and the originator needs to supply a password to send the message. Optionally, the originating device may include a password in the original message which would obviate the need for stages 855-860. Typically the originating device will not have supplied a password. Therefore, at stage 855, a password request is sent to the messaging entity requesting a password. At stages 860 and 865, the password is received and compared to the password supplied by the routing reply. If the passwords do not match, at stages 870 and 875 an invalid password message is returned to the originating device and the message is not delivered. Optionally, exemplary embodiments consistent with the present invention may provide for multiple attempts to provide a correct password.
[0145] Assuming a valid response and a valid password, if required, processing continues at stage 540 where the message is translated into the common format. FIG. 9 illustrates a flowchart of the operation of the translation stage 540 of an ARC in an exemplary embodiment consistent with the present invention. At stage 905, the message is translated from its original message format to the common message format utilized on the network transport bus 125. At stage 910 routing information gathered from the routing reply is utilized to append a header to the message in the common format. The header of the common message may be in one of the following formats:
[0146] "Deliver_Message.ARCn.DEVICE_TYPE.DESTINATION_ADDRESS.T RANSACTION_IDENTIFICATION" or "Deliver_Store_Message.ARCn.DEVICE_TYPE.DES- TINATION_ADDRESS.TRANS ACTION_IDENTIFICATION", where:
[0147] ARCn is the address of the ARC associated with the destination device. This information may or may not be in the routing reply information. If the information is in the routing reply information, then the appropriate ARC address is in this field. Otherwise, this field will contain ARC*, and each ARC will have to examine this message and internally decide whether the Device Type or Destination Address is associated with the respective recipient ARC;
[0148] Device_Type is the type of destination device. Examples include GSM, TDMA, Mobitex, FAX, etc.;
[0149] Destination Address is the destination address for the destination device;
[0150] A Deliver_Message subject is used if the message does not need to be stored in the DART. A Deliver_Store_Message subject is used if the message is to be stored in the DART.
[0151] Once the message had been published onto the network transport bus, the operations of the ARC are essentially complete. Additional exemplary embodiments of the invention may provide for feedback to originating ARCs relating to the delivered status of messages.
[0152] While the previous FIGS. 5-9 illustrated the flowchart of the operation of an ARC functioning to receive a message from a messaging element in an exemplary embodiment consistent with the present invention, ARCs also function to receive messages from the network transport bus for transmission to destination devices. FIG. 10 illustrates a flowchart of the operation of an ARC functioning to transmit a message from the network transport bus in an exemplary embodiment consistent with the present invention.
[0153] At stage 1005, the monitor daemon in the ARC monitors traffic on the network transport bus. At stage 1010, the daemon examines the header of a message on the network transport bus to determine if the subject address is related to delivery of a message. Typically, it is searching for "Deliver_Message.ARCn.DEVICE_TYPE.DESTINATION_ADDRESS" or "Deliver_Store_Message.ARCn.DEVICE_TYPE.DESTINATION_ADDRESS". If a delivery related message is found at stage 1010 and the ARCn field is left as "ARC*", at stage 1015 the ARC will parse the common message header to pull out the Device_Type and Destination_Address entries. At stage 1020, if either of these entries has a value assigned to the ARC, processing proceeds to stage 1030.
[0154] At stage 1025, if the subject address is not related to delivery of a message and the ARC is not specifically addressed, e.g. .ARC1., then the daemon continues to monitor network traffic at stage 1005. Otherwise, flow proceeds to stage 1030.
[0155] At stage 1030, the contents of the message in the common format are read from the network transport bus. At stage 1035, the header of the message is parsed to determine the destination address. At stage 1040, the message is translated by the ARC from the common format to the messaging format of the messaging entity, and at stage 1045, the message is sent to the destination device via the messaging entity.
[0156] Routing and Validation Entity Operation
[0157] In view of the detailed description of the operation of an ARC, a detailed description of the operation of the RAVE follows with reference to FIG. 11. FIG. 11 illustrates a flowchart of the operation of a RAVE for routing messages in an exemplary embodiment consistent with the present invention. At stage 1105, the RAVE receives a routing request from the network transport bus. At stage 1110, the RAVE extracts routing information relating to the routing request. At stage 1115, the RAVE generates a routing reply comprising the routing information. At stage 1120, the RAVE transmits the routing reply back onto the network transport bus.
[0158] FIG. 12 illustrates a flowchart of the operation of the routing request receipt stage 1105 of a RAVE in an exemplary embodiment consistent with the present invention. At stage 1205, a daemon on the RAVE monitors network traffic on the network transport bus 125. At stage 1210, the daemon examines the header of a message on the network transport bus to determine if the subject address is a routing request. Typically, it is searching for "Routing_Validation.RAVE_ADDRESS.ORIGINATI- NG_ARC_ADDRESS.TRANSAC TION_ID.ORIGINATING_DEVICE_ADDRESS.DESTINATION_DEVI- CE_ADDRESS"
[0159] where:
[0160] RAVE_ADDRESS is the address of the destination RAVE for the request. Typically, the ARC will not address the routing request to a particular RAVE, so this field will typically be "RAVE*", meaning any RAVE;
[0161] ORIGINATING_ARC_ADDRESS is the address of the ARC originating the routing request, e.g, ARC1, ARC2, etc.;
[0162] TRANSACTION_ID is the assigned transaction identification of the message;
[0163] ORIGINATING_DEVICE_ADDRESS is the address of the originating device gathered from parsing the header information; and
[0164] DESTINATION_DEVICE_ADDRESS is the address of the destination device gathered from parsing the header information.
[0165] If a Routing_Validation message is found at stage 1210 and the RAVE_ADDRESS field is left as "RAVE*", at stage 1215 the RAVE will parse the common message header to pull out the Destination_Device_Address entry. At stage 1220, if the entry has a value assigned to the RAVE, processing proceeds to stage 1230.
[0166] At stage 1225, if the subject address is not a Routing Validation and the RAVE is not specifically addressed, e.g. .RAVE1., then the daemon continues to monitor network traffic at stage 1005. Otherwise, flow proceeds to stage 1230.
[0167] At stage 1230, the Routing_Validation message is read, and at stage 1235 the Routing_Validation message is parsed to pull out the originating device address and the destination device address. At stage 1110, routing information is extracted from the RVDB.
[0168] FIG. 13 illustrates a flowchart of the operation of the extraction of routing information stage 1110 of a RAVE in an exemplary embodiment consistent with the present invention. At stage 1303, the RAVE examines the destination device address entry to determine whether it is an alias or a distribution list. If the destination device address entry is an alias or a distribution list, at stage 1306 the RAVE looks up the entry in the UADB. At stage 1309, if the entry is not found in the UADB, an Invalid response is returned in the routing response at stage 1312. But, if the entry is found in the UADB, at stage 1315 the destination devices are expanded from the entry in the UADB, and the list of one or more destination devices is returned at stage 1318.
[0169] At stage 1321, for each of the one or more destination devices, process stages 1324-1369 are executed. If more than one device is present, this will yield a string of routing information with a header portion for each of the destination devices.
[0170] At stage 1324, the destination device is looked up in the RVDB. At stage 1327, routing information is extracted from the RVDB for the destination device. The routing information comprises at least a device address. The routing information may further comprise: a device type, an ARC address associated with the device address, prepaid subscriber flag, whitelist data, blacklist data, COS data, password data, and a data storage flag.
[0171] At stage 1330, if the origination device and/or the destination device is related to a prepaid subscriber, stage 1333 looks up balance information to determine if there is an available balance. If the balance is not available, at stage 1336, an Invalid reply is returned for the associated destination device.
[0172] If the balance is available, the RAVE may debit the origination device and/or destination devices account.
[0173] If the origination and/or destination device is not associated with a prepaid subscriber, or if the origination and/or destination device is associated with a prepaid subscriber with a sufficient balance, processing proceeds in parallel to stages 1339, 1348, and 1351.
[0174] At stage 1339, the ARC checks whether the originating address is on a whitelist for the destination device. If so, a Valid response is generated and processing continues at stage 1369. If not, at stage 1342
the ARC checks whether the originating address is on a blacklist for the destination device. If so, an Invalid response is generated and processing continues at stage 1369. If not, at stage 1345 the ARC checks whether the originating address or destination address meets the COS requirements. If so, a Valid response is generated and processing continues at stage 1369.
[0175] At stage 1348, the process checks whether a password is required for the destination device. If so, at stage 1363 a Password is returned and processing proceeds to stage 1369.
[0176] At stage 1351, the process checks whether a data storage flag is turned on for the destination device. If so, at stage 1365 a data storage flag is returned and processing proceeds to stage 1369.
[0177] At stage 1369, the various returned routing information is compiled for all destination devices associated with the message. This is used to generated the routing reply of stage 1115 (FIG. 11). A routing reply header typically will look like this for each destination device in the header:
[0178] "Routing_Validation_Response.VALIDITY.REASON.DEVICE_TYPE.D EVICE_ADDRESS.ARCn.PASSWORD.DATASTORE.TRANSACTION_ID", where
[0179] VALIDITY generally returns either Valid or Invalid;
[0180] REASON may return the reason for an Invalid response;
[0181] DEVICE_TYPE may return the type of device;
[0182] DEVICE_ADDRESS returns the specific device address for the destination device;
[0183] ARCn may return the address of the ARC responsible for the device;
[0184] PASSWORD may return a password if one is required to send a message to the destination device; and
[0185] DATASTORE may return a flag if data storage should take place for the message.
[0186] Data Storage and Routing Terminal
[0187] At a high level, as set forth in the detailed description that follows, Data Storage and Routing Elements ("DART") are used in the system of the present invention to manage the message storage and retrieval functions of the system. DART(s) also provide message routing functionality for data messages.
[0188] In an exemplary embodiment consistent with the present invention, DARTS 145a-b may be active network elements that supply business logic for storing, updating, and querying current message objects from MDS 150a-c. DARTS 145a-b, for example, can provide an interface between MDS 150a-c, and other elements of the wireless architecture that produce and query the data stored in MDS 150a-c. In the example of FIG. 1, DARTS 145a-b may support interface requirements to MDS 150a-c. For example, DARTS 145a-b may implement load balancing between MDS 150a-c. In this manner, one or more of the DARTs, such as DART1 145a, may perform a load balancing function for the data stored in one or more message data stores such as MDS 150a.
[0189] One or more of the DARTs, such as DART1 145a, may provide routing to one or more of the message data stores such as MDS 150a. In this manner, DART1 145a, for example, may route messages or other information to one or more of the message data stores such as MDS 150a. In one exemplary embodiment, DARTS 145a-b perform routing functions which direct particular messages to a particular message data store such as MDS 150b.
[0190] One or more of the DARTs such as DART1 145a, may store messages in a message data store such as MDS 150c, on a per device basis. For example, all of the messages that are associated with a particular device may be stored in a single message data store, such as MDS 150b. In that example, DART1 145a may be able to detect a device type associated with a particular message and route that message to a predefined message data store. Device types may be defined based on their supporting network, such as general packet radio service (GPRS), Global System for Mobile Communication (GSM) or MOBITEX. In another embodiment of the present invention, a single DART, such as DART1 145a, may be adapted to handle a certain type of message for a particular device. In this manner, DART1
145a may handle all MOBITEX messages. DART1 145a-may then be tasked with routing all MOBITEX messages to a particular message data store. In yet another alternate embodiment of the present invention, multiple DARTs may handle multiple device types. For example, each DART 145a-b in the system depicted in FIG. 1 may be capable of handling messages for numerous different device types.
[0191] DARTS 145a-b may also be capable of handling fragmented message segments. For example, in a short messaging service (SMS) format, messages may be segmented into different parts of standard lengths. One embodiment of the DART may be capable of handling message segments so as to preserve the integrity of a message made up of message segments. For example, DART 145a may be capable of receiving numerous message segments of a single message and directing those message segments to a single message data store such as MDS 150b.
[0192] DARTS 145a-b may be capable of routing information including the originating and terminating addresses of a particular message. In a further embodiment of the present invention, DARTS 145a-b may be able to handle and direct COS data as well as context identification data on a per transaction basis. DART 145a may also be able to parse out a message header. In general, DARTS 145a-b may be capable of handling numerous data and information structures associated with a particular message.
[0193] DARTS 145a-b may be capable of querying messages and determining the current status of a message. These query and status functions may be performed on a per device basis. For example, a DART, such as DART1 145a, may be able to access a message data store, such as MDS 150b, to determine the number of messages stored therein for a particular device type. Additionally, DART1 145a may be capable of determining the current status of messages stored in a message data store.
[0194] One or more DARTs, such as DART 145b, may provide support for multiple database elements such as UADB 140, RVDB 135, and MDS 150a-c, as well as other internal or external databases. In an exemplary embodiment of the present invention, DARTs, such as DART 145b, may support call level interfaces such as open database connectivity (ODBC) or JAVA database connectivity (JDBC), database middle ware, light weight directory access protocol (LDAP) interfaces, multiplexing database requests, JAVA messaging service and JAVA naming directory information, database connection pooling, database adaptors, and format and application protocol of a database gateway. Alternate embodiments of the DART of the present invention may be able to support any one or more of these protocols and applications as well as numerous others known to those skilled in the art.
[0195] The DARTs, such as DART 145a, may provide the ability to send transactions as a remote request in which one sequential query language request is sent to one database. In other embodiments, a DART, such as DART 145b, may be able to send transactions as a remote unit of work in which many sequential query language requests are sent to one database or as a distributive request in which many sequential query language requests are sent to many databases. In this manner, one or more DARTs, for example, may be capable of querying one or more databases, such as RVDB 135, UADB 140, and MDS 150c.
[0196] DART2 145b, may be capable of publishing messages to other network elements such as, for example, RAVEs, ARCs, and other DARTs. This message transfer may be accomplished via a publish and subscribe process. Additionally, in another embodiment of the present invention, the transfer of messages may be accomplished via a synchronous or an asynchronous transaction process.
[0197] DART1 145a may be capable of parsing a message so that only header information without message text can be sent to a wireless subscriber. DART1 145a may also be capable of responding with specific header information, message identification information, message size or length, date stamps, and message statuses. In this manner, DART 145a may be able to parse out various segments of a message and send any number of those segments to a wireless subscriber.
[0198] In a further aspect of the present invention, segmented messages can be linked together into a single transaction. For example, if a message exceeds the standard length, it would then take up more than one segment. DART 145b of the present invention contemplates treating the segmented pieces of a single message as a single transaction. In a further embodiment of the present invention, data can be parsed out of the message to convert it into different protocols.
[0199] DART 145b may also provide various storage management functions. For example, DART 145b may provide the capability of throttling the number of messages for a single wireless subscriber. In addition, DART 145b may be capable of tracking the number and size of messages a single wireless subscriber stores in a message data store such as MDS 150a. DART2 145b may be capable of notifying a wireless subscriber of the number of messages stored in a message data store.
[0200] In another embodiment of the present invention, a wireless subscriber may be allotted a certain limited amount of storage in a message data store such as MDS 150a. In this manner, a wireless subscriber, for example, may be given one megabyte of data storage capability on a message data store. If the wireless subscriber exceeds the one megabyte storage limit, then DART2 145b may be capable of sending the wireless subscriber a message indicating such. DART2 145b may be capable of notifying a wireless subscriber that his message storage limit is about to be reached. These notification messages may be delivered through any convenient medium to the wireless subscriber. For example, the wireless subscriber may receive such a message on his pager. A further aspect of the current invention provides for storage thresholds that are dynamically modifiable. In this example, a wireless subscriber may be allocated an initial storage capacity, for example two megabytes, and then be able to increase that capacity later upon a request or upon the occurrence of a certain event.
[0201] The DARTs, such as DART1 145a may be capable of supporting data replication. Further, DART 145a may be capable of supporting method replication. For example, business logic may be replicated among various DARTs and may be thus modifiable throughout all DARTs.
[0202] DARTs, such as DART2 145b, may be capable of allowing a user to remotely delete e-mail from a wireless device. In this manner, a wireless subscriber may be able to access his wireless device and be able to delete, for example, an email message. DART 145a may then be able to synchronize this deletion to a mail server so that the e-mail is also deleted from the mail server. In other words, a single delete command from a wireless device could operate to erase, for example, an e-mail message from both a database and an e-mail server. In the exemplary embodiment of FIG. 1, DART1 145a may receive a delete command from a wireless subscriber. In this example, DART1 145a may then be able to delete the particular e-mail message from MDS 150a as well as from an IMAP/POP server 156. In this manner, DART 145a may be capable of a synchronized delete function.
[0203] FIG. 14 illustrates a diagram of a Data Storage and Routing Terminal 145 in an exemplary embodiment consistent with the present invention. The DART 145 comprises a network transport bus interface 1410
coupled to a processor 1420 coupled to a backbone datastore transport bus interface 1430.
[0204] The network transport bus interface 1410 couples the processor 1420
to the network transport bus 125. The network transport bus interface 1410 monitors traffic along the network transport bus 125 for messages directed to the DART 145 and places messages on the network transport bus 125 from the processor 1420.
[0205] The processor performs the operations described throughout this portion of the specification and interfaces to the backbone datastore transport bus 108 through the backbone datastore transport bus interface 1430. Through this interface and bus, the DART communicates with the message data store entities, MDS.
[0206] The message data store entities, such as MDS 150a, may be capable of storing e-mail messages with or without attachments, text messages including, for example, short messages, instant messages, and MOBITEX messages, enhanced messages including, for example, ETSI messages, EMS messages, and NOKIA smart messages, multimedia messages including, for example, text, fax, icons, logos, animations, music, photos, media clips, or any combination of the above.
[0207] The MDS may be able to store data in a MIME or XML format. Messages may also be popped up to an external e-mail server. In this manner, a message stored at the direction of a DART, such as DART1 145a, in a database, such as MDS 150a, in MIME format could be transmitted to an external device through ARC translation. Additionally, messages can be stored, for example, in a linked list format.
[0208] MDS elements 150a, 150b, and 150c, may be capable of storing messages in any convenient data format. This message storage may be capable of supporting any number of various communications protocols. In addition to MIME format, numerous other data storage formats known to those skilled in the art may be used consistently with the principles of the present invention. In addition, data may be stored in MDS 150a-c, on a per transaction basis to decrease the storage requirements for multiple devices or destinations.
[0209] MDS may be scaleable. For example, MDS 150a may be expandable beyond an initial data storage capability. Further, additional MDSs (not shown) may be added to the backbone data store transport 105 to provide additional storage capability. In this manner, not only are individual MDSs, such as MDS 150a, scaleable but so too is the storage capacity across all MDSs in the entire network.
[0210] MDS 150a, 150b, and 150c may provide security features. For example, data may be stored in MDS 150a, 150b, and 150c in any convenient encrypted format as known in the art. Other exemplary embodiments of MDS 150b, for example, may provide for redundancy to ensure no loss of data. Further, MDS 150b may be configured to ensure no duplication of records or data.
[0211] MDS elements 150a, 150b, and 150c may support both long term and transient storage. In this manner, MDS 150b may contain cache memory or any other sort of transient storage medium. Further, MDS 150b may support distributed storage and may provide a storage area network architecture. Long term storage can occur, for example, on a magnetic medium or an optical medium or other media now known or to be developed. The database architecture of MDS 150a-c, may be based on, for example, a relational model or an object oriented model. Numerous database structures are known to those skilled in the art and are possible implementations of MDS 150a-c.
[0212] MDS 150a-c may provide security features. For example, data may be stored in MDS 150a-c in any convenient encrypted format. Other exemplary embodiments of MDS 150a-c may provide for redundancy to ensure no loss of data. Further, MDS 150a-c may be configured to ensure no duplication of records or data.
[0213] MDS elements 150a-c may support both long term and transient storage. In this manner, MDS 150a may contain cache memory or any other sort of. transient storage medium. Further, MDS 150a may support distributed storage and may provide a storage area network architecture. Long term storage can occur, for example, on a magnetic medium or an optical medium. The database architecture of MDS 150a-c may be based on a relational model or an object oriented model. Numerous database structures are known to those skilled in the art and are possible implementations of MDS 150a-c.
[0214] In an exemplary embodiment consistent with the principles of the present invention, an MDS may comprise three tables: a message store table, a message device status table and a transaction data segment table. In this example, the message store table, the message device status table and the transaction data segment table are each contained in a relational database. The relational database may be distributed over many different data storage entities and may be implemented in any convenient manner. For example, one skilled in the art would be able to implement the principles of the MDS on an Oracle database product.
[0215] In one embodiment, the message store table is a repository for message information. The message store table stores a transaction identifier associated with a message, a message class, a description of a the message, the number of segments in a multi-segment message, message priority, an originating address, a destination address, a class of service code, message status information, the date the message was submitted, a sequence number for the message, and a notification address for the message. The message store table has as its primary key a message identifier. This message identifier, in this example, is a unique string associated with a message.
[0216] In general, the message store table is configured to accept detailed information about a message transmitted across a messaging infrastructure 100. In this example, a unique transaction identifier is associated with each message. This transaction identifier may be in the form of a string of characters. The message class describes the type of message, such as a proprietary ring tone. For multi-segment SMS messages, the message store table stores the number of segments in the message. A message priority, in the form of a flag, may be associated with each message. In this manner, priorities may be associated with each message and delivery schemes may be established based on message priority. For example, a priority flag may be set to a priority of "urgent." In such a case, a message with an associated priority flag set to "urgent" may receive preferential delivery treatment. The origination and destination addresses may be any form of address associated with a communications device. For example, these addresses could correspond to email addresses, IP domain names, cellular telephone numbers, fax machines, pagers, or any other type of communications device.
[0217] The MDS is capable of storing in a common format, such as MIME or XML, messages that are generated on or received by any communications device. The status information, in this example, tracks the status of a message. For example, the status information may indicate that a message was delivered. A notification address, contained in the exemplary embodiment of message store table receives an indication that a message was delivered.
[0218] The message device status table stores message and device information. In this example, the message device status table contains device type information, a routing identifier, device status, completion date, query attempts, retry attempts, the number of segments of a multi-segment message that were delivered successfully, and the number of segments of a multi-segment message that were not delivered successfully. The device type information, for example, includes the type of device and any relevant associated characteristics. The routing identifier, for example, may be a string that denotes a particular route to be traveled by a message. Device status information may include information about whether a particular device is turned on or is in use. Query attempts and retry attempts, in this example, refer to the number of query attempts made on a message and the number of attempts made at delivery, respectively. Likewise, the number of segments of a multi-segment message delivered successfully and unsuccessfully are stored so that multi-segment messages may be properly delivered. In this example, the message device status table has as its foreign key a message identifier. In this manner, the message device status table references message store table for message information.
[0219] The transaction data segment table stores information about segmented messages. In SMS messaging, the maximum length of a message segment is typically 160 characters. If an SMS message is longer than 160
characters, then it preferably will be stored in more than one segment. Each segment may be transmitted separately over a network and then reassembled at a destination. In this example, the transaction data segment table stores information about the number of segments in a multi-segment message along with the data contained in each segment. The transaction data segment table has as its primary key a segment identifier and as its foreign key a transaction identifier. In this manner, the transaction data segment table references message store table for message information.
[0220] The message store table contains the body of a message in a common format. This message body, for example, could be the text of an email message or the coding of a ring tone converted into a common format. In one embodiment of the present invention, the message body is associated with multiple destination addresses without duplication of the message body. For example, an SMS message may have as its destination numerous devices. Instead of storing the SMS message text in a data structure associated with each of the destination addresses, the SMS message text may be stored a single time and associated with the multiple destination addresses in the message store table. In this manner, message text is stored only once and the associated information, such as destination addresses, can then be used to reference the message text.
[0221] Operation of the DART in Communication with the ARC & RAVE
[0222] FIG. 15 illustrates a simplified view of the messaging infrastructure 100 illustrated in FIG. 1 in an exemplary embodiment consistent with the present invention. DART 145b is interfaced with network transport bus 125 and backbone data store transport bus 108. Likewise, in this example, DART 145a interfaces with network transport bus 125 and backbone data transport bus 108. Network transport bus 125
interfaces with DART 145a, DART 145b, ARC1 110a, ARC2 110b, and RAVE 130. Backbone data store transport bus 108 interfaces with DART1 145a, DART2
145b, MDS 150a, MDS 150b, and MDS 150c.
[0223] In operation, messages stored on an MDS 150a-c may flow from the MDS through backbone data store transport bus 108 to an applicable DART 145a or 145b to network transport bus 125, and then to an applicable ARC 110a or 110b. Likewise, messages may originate in an applicable ARC 110a or 110b and then flow to network transport bus 125, an applicable DART 145a or 145b, backbone data store transport bus 108, and an applicable MDS 150a, 150b, or 150c.
[0224] As discussed in previous portions of the detailed discussion, a data storage function may be enabled to trigger storage of messages in an MDS by a DART. An ARC may designate the address of a specific DART, such as DART1 145a by utilizing "Deliver_Store_Message.DART1". In this manner, a point to point communications protocol may be employed. Alternatively, a publish and subscribe protocol may be used in which case ARC 110a simply publishes the new message, for example, with a subject such as "Deliver_Store_Message.DART*" on network transport 125. Each DART may subscribe to "Deliver_Store_Message" messages.
[0225] In this publish and subscribe system, each ARC element and each DART connected to network transport 125 receives the new message. Likewise, in this example, the DART will make a storage decision based on, for example, the DEVICE_TYPE, DESTINATION_ADDRESS, or ORIGINATION_ADDRESS associated with the message. In this example, both ARC 110a and DART 145a have subscribed for these messages and both process the message. The message processing by DART 145a and ARC 110a occurs in parallel. DART 145a may then publish the message on backbone data store transport 108.
[0226] There may be many MDS elements listening for these published messages but only one is configured for the subscriber. MDS 150b stores the message at the direction of DART 145a as the DART 145a issues an "MDS_STORE.MDS2" on the Backbone DataStore Transport 108. DART 145a may also publish a "Confirm_Store" message along with the transaction ID for this message on network transport bus 106. ARC2 110b is listening for this message, and once it is received, ARC2 110b may transmit this confirmation status to the originator of the message.
[0227] In another example, a wireless subscriber may access a message that has already been sent to a destination and can, for example, resend, forward, query, or delete this message. In this example, a wireless subscriber sends a request to see the contents of his message mailbox. This request is sent via ARC2 110b to network transport 125. ARC2 110b publishes the request on network transport 125. ARC2 110b may append the address of a specific DART to the published request in which case a point to point protocol is used. Alternatively, ARC2 110b may simply attach a subject such as "Read_Mailbox" to the published request, without a specific element identified, in which case a publish and subscribe protocol is used.
[0228] The DART associated with the particular subscriber or device processes the request. DART2 145b has subscribed to any query request and therefore receives the request from network transport 125. DART2 145b then republishes this request on backbone data store transport 108. While all of the MDSs may be listening for these types of messages, only one MDS, in this case MDS3 150c, processes the query request. MDS3 150c receives this request because the wireless subscriber who sent this request has his information stored on MDS3 150c. DART2 145b may use a point to point protocol addressing the request specifically to MDS3 150c. Alternatively, DART2 145b may use a publish and subscribe protocol in which case the request is published on backbone data store transport 108
and each MDS listens for the request. Only the MDS associated with the subscriber, in this case MDS3 150c, processes the request. MDS3 150c then publishes the information about this wireless subscriber on backbone data store transport 108. DART2 145b receives the information about the wireless subscriber from backbone data transport 108. DART2 145b then publishes this information on network transport 125 with addressing specified for ARC2 110b, in a point to point protocol. Alternatively, DART2 145b may employ a publish and subscribe protocol. Since ARC2 110b has subscribed for this message, it receives the information about the wireless subscriber, performs any translation functions that may be necessary, and displays the results to the wireless subscriber. In that manner, information stored in MDS3 150c can be retrieved and forwarded to a wireless subscriber.
[0229] In yet another example of the operation of an exemplary embodiment of the present invention, a wireless subscriber may submit a request to cancel a message that is set for delivery. In that case, a wireless subscriber has received information about his current pending messages. The subscriber sees one message that is marked for delivery that he wishes to cancel so he sends a "cancel message" request. This cancel message request is sent from ARC2 110b over network transport bus 125. ARC2 110b transforms the cancel message request into a request that is published on network transport 125. This published request, for example, may contain the transaction ID, the subscriber ID, and the device type. ARC1 110a has subscribed to any cancel message requests. ARC1 110a receives this cancel message request and converts it into the proper format for the other elements of the wireless network. Both ARC2 110b and DART1 145a are listening for this request. DART1 145a then publishes this request on backbone data store transport 108. Each MDS listens for these types of requests. MDS1 150a responds to the request because MDS1 150a has this particular wireless subscriber's data stored in its data storage mechanism. After MDS1 150a receives the request, MDS1 150a returns the requested data and publishes it on the backbone data store transport 108. MDS1 150a may then delete the message. DART1 145a receives the requested data and publishes the requested data on network transport 125. ARC2
110b, since it subscribes to this requested data, receives the requested data, performs any translation functions, and returns the requested data to the wireless subscriber.
[0230] In still yet another example, a wireless subscriber may wish to access a message from an external IMAP/POP client. A wireless subscriber's user name and password may be used for validation. The RAVE entity may be responsible for validating the particular wireless subscriber. A wireless subscriber sends a request to retrieve external messages from an IMAP/POP mail server. This request is received by ARC2
110b which may, in turn, perform translation functions. After any translation functions, ARC2 110b publishes the request on network transport 125. The request may be published in the form of an update message request.
[0231] DART1 145a subscribes to such "update message requests." DART1 145a receives this "update message request." Upon receiving this update message request, DART1 145a publishes on network transport 125 a "get subscriber mail information" request. RAVE 130 subscribes to get subscriber mail information request messages and receives this message. RAVE 130 searches applicable databases, such as RVDB 135 for appropriate wireless subscriber information. RAVE 130 then publishes this information on network transport 125. In this manner, RAVE 130 places on network transport 125 various information about a wireless subscriber, such as the wireless subscriber's user name, alias, preferences, and possible destination addresses.
[0232] DART1 145a subscribes to the information placed on network transport 125 by RAVE 130. DART1 145a receives this information and in response publishes a "get external e-mail request" on network transport 125. ARC2 110b is associated with an IMAP/POP server (not shown) and to that extent, ARC2 110b may perform various translation functions for the IMAP/POP server. ARC2 110b subscribes to get external e-mail requests and therefore receives this request and its accompanying information and forwards the request to an IMAP/POP server (not shown) which retrieves the information from an external storage device. This retrieved information, which for example could be an e-mail message, is received by ARC2 110b for any necessary translation. After ARC2 110b performs necessary translation functions on the external mail message, ARC2 110b publishes this email message on network transport 125.
[0233] In this example, DART2 145b subscribes to such external mail messages. DART2 145b receives the external message from network transport 125 and publishes the external mail message on backbone data store transport 108. All of the MDSs listen for external mail messages such as that placed on backbone data store transport 108 by DART2 145b. MDS2 150b contains information about the wireless subscriber and therefore receives the external mail message attributable to that wireless subscriber. MDS2
150b receives the external mail message from backbone data store transport 108. MDS2 150b then updates its data storage with the external mail message that it received from backbone data store transport 108. The wireless system may be configured such that one DART subscribes to new message requests while another DART subscribes to update requests.
[0234] After MDS2 150b has received the last external e-mail message, DART2 145b may then publish on network transport 125 a sub-messages POP message which may also contain subscriber identification. ARC1 110a subscribes to receive this type of message which would contain the information about the external mail message. Accordingly, in this example, ARC1 110a receives this information and the accompanying external mail message, performs any translation that may be necessary, and then returns the external mail message to the wireless subscriber.
[0235] In another example, a class of service associated with a message may not allow the body of the message itself to be read. In such a case, ARC1 110a may return only a description of the message. For example, a wireless subscriber may request that a ring tone be forwarded from an external IMAP/POP server. In such a case, ARC2 110b receives this request and, through the previously described method, publishes a request on network transport 125. A field associated with this message may indicate that it is a proprietary ring tone. If this is the case, ARC1 110a, may return to the wireless subscriber a message indicating that the proprietary ring tone may not be forwarded.
[0236] In yet another example, a DART entity may allow a wireless subscriber to POP a message through an external IMAP/POP client. A wireless subscriber may be able to download an external message description or the whole message itself based on an associated class of service code.
[0237] In this example, a wireless subscriber requests a description of all messages stored on an IMAP/POP server. ARC1 110a receives this request and transforms it into a publish request which is published on network transport 125. DART1 145a has subscribed to this publish request and receives the request from network transport 125. DART1 145a transforms this request into a query that is then published on backbone data store transport 108. In this case, MDS2 150b has subscribed for queries and receives the query from backbone data store transport 108. Upon receiving the query, MDS2 150b processes the request to return the subscriber's messages. For example, MDS2 150b may be able to receive a query from backbone data store transport 108 and, through associated functions, search its associated database or databases for contents relevant to the query.
[0238] MDS2 150b contains all messages associated with the wireless subscriber. MDS2 150b, after processing the query, returns the information to backbone data store transport 108. DART2 145b has subscribed to receive this information and receives it from backbone data store transport 108. DART2 145b may then forward this information to network transport 125. ARC1 110a, associated with an IMAP/POP server, has subscribed to receive this information. After receiving the information, ARC1 110a transforms the information to POP responses and forwards them through the server to the IMAP/POP client of the wireless subscriber.
[0239] In yet another example of the operation of the communications system, a wireless subscriber may receive a value added message. A value added message service generates a new message for a subscriber. The value added message service may need confirmation of message delivery so that the wireless network provider can bill the wireless subscriber. As such, a short message peer to peer primitive with a registered delivery flag is sent to ARC1 110a. In this example, ARC1 110a extracts the destination address, origination address, and any additional information necessary, and then publishes a subscriber look-up on network transport 125. If any passwords are required for a destination or distribution list, then these can also be sent in a query published on network transport 125. RAVE 130
has subscribed for these subscriber look-up requests. RAVE 130 receives the look-up requests and performs an alias look-up and a validation request to connected routing and validation databases and user alias databases. This alias look-up and validation request may be performed using a publish and subscribe protocol or any other convenient protocol.
[0240] RAVE 130 then publishes the extracted list, the associated device types, any disallowed destinations, and any other pertinent information to the originating ARC, in this case ARC1 110a, in the destination field. RAVE 130 publishes this information on network transport 125 with its destination as ARC1 110a. In another aspect, RAVE 130 publishes that information on network transport 125 with a subject to which all ARCs subscribe. RAVE 130 may use a publish and subscribe protocol to communicate with ARC1 110a and other ARC entities. ARC1 110a has subscribed to this information and receives the list, device type, disallowed destinations, and other information and proceeds to publish on network transport 125 the message data with the extracted destinations and associated device types. ARC1 110a may also return failed destinations to the originating value added message service.
[0241] DART1 145a and ARC2 110b have subscribed for this message. For example, a device type of SMSC associated with ARC2 110b may be included in the destination. ARC2 110b may then convert this message to an SNPP and perform any transformations required based on message type, device type, and SMSC type. DART1 145a, via backbone data store transport 108, may then publish this message to MDS1 150a for storage. MDS1 150a stores the message. MDS1 150a may return the confirmation of storage by publishing it on backbone data store transport 108. DART1 145a, by subscribing to confirmation messages, receives the confirmation and publishes it on network transport 125. ARC1 110a, by subscribing to this type of confirmation message, receives the confirmation message from network transport 125. A confirmation is then forwarded from message data store transport 116, via backbone data store transport 108, DART1 145a, and network transport 125, to ARC1 110a via a publish and subscribe protocol, point to point protocol, or any other convenient method.
[0242] The SMSC acknowledges receiving the SMPP message and returns an acknowledgement. ARC2 110b, associated with the SMSC, publishes this acknowledgement on network transport 125. DART2 145b listens for this acknowledgment and, based on the originating address, adds this acknowledgement to the stored transaction in MDS1 150a. This can occur, for example, by DART2 145b receiving from network transport 125 the acknowledgement and then publishing the acknowledgement on backbone data store transport 108. MDS1 150a, because it subscribes to the acknowledgment associated with this particular wireless subscriber, receives the acknowledgement and adds it to the stored transaction.
[0243] MDS1 150a may then return a completed transaction message by publishing it on backbone data store transport 108. DART2 145b may then receive this completed transaction message and publish it on network transport 125. The completed transaction message may then be received by ARC2 110b associated with the SMSC. In this manner, the SMSC can receive confirmation of delivery and generate a receipt. This receipt may then proceed through ARC2 110b to network transport 125. ARC2 110b, after performing any necessary translation functions, may publish the receipt on network transport 125. DART2 145b, has subscribed to receive the receipt published on network transport 125. DART2 145b, after receiving the receipt, publishes it on backbone data store 108. MDS1 150a, because it is associated with a particular wireless user, adds the receipt to the message transaction. The status of the message can be updated in MDS1
150a.
[0244] Operation of the DART
[0245] FIG. 16 illustrates a flow chart of the operation of a DART element consistent with the principles of the present invention. The DART element is capable of performing several different functions. For example, store, query, cancel, external mail access, among others, related to the storage and maintenance of messages.
[0246] At stage 1605, a DART element receives a request from the network transport bus. This request may be specifically addressed to a particular DART in a point to point protocol or may contain a subject header in a publish and subscribe protocol. Upon receiving the request, the DART element then determines which function to execute. At stage 1610, the DART element determines whether the request is a store request. Typically, a string of characters in the request heading or the request itself denominates the type of request. For example, a request containing the string "DELIVER_STORE" indicates that the request is to deliver a message and to store it. In another example, the string "STORE" contained in a request indicates to a DART entity that the request is a store request.
[0247] If the DART entity determines that the request is a store request, then the DART entity performs a store function as indicated in stage 1615. If the request is not a store request, then the DART entity proceeds to stage 1620 to determine if the request is a query request. Like the store request, the DART entity examines the request, for example, for the string "QUERY." If the request is a query request, then the DART entity performs a query function as depicted in stage 1625. If not, the DART entity proceeds to stage 1630 to determine if the request is a cancel request. If it is, then the DART entity performs a cancel function as depicted in stage 1635. If not, the DART entity, as depicted in stage 1640, determines whether the request is an external mail request. If it is, then the DART entity performs an external mail function. If not, then the DART entity, as illustrated in stage 1650, determines if the request is any other type of request. If it is, then the DART entity performs the requested function. Otherwise, the DART entity performs an error handling function.
[0248] In this manner, the DART entity determines the type of request and performs the associated function. FIG. 16 is merely an example of a few different types of functions performed by the DART entity as many other functions are within the scope of the present invention. For example, the DART entity may perform specific lookup requests by accessing an associated MDS and returning specific data. Likewise, in error handling stage 1660, the DART entity may perform several different, error related, functions; for example reporting an error to other network entities such as the LAMB.
[0249] FIG. 17 illustrates the receipt of a request by a DART entity consistent with the principles of the present invention. FIG. 17 is an exemplary embodiment of stage 1605 of FIG. 16. At stage 1705, a monitor daemon in the DART monitors traffic on the network transport bus. At stage 1710, the daemon examines a header of a message on the network transport bus to determine if the subject heading is one that is for a DART. For example, the subject heading may contain the string, "STORE" which indicates that the request is a store request to be handled by a DART. If the subject address is not a DART subject address, then the DART daemon continues to monitor traffic on the network bus. If the subject address is a DART subject, then the DART parses the request as illustrated in stage 1715.
[0250] At stage 1720, the DART determines whether the request contains a DART specific address. For example, a request may contain a subject followed by a specific DART address such as ". . . STORE.DART1 . . . . " In this case, the specific DART address is "DART1" which indicates that the request is directed specifically to the addressed DART, DART1. If the request does not contain a specific DART address, then the request is assigned to an available DART entity. In alternate embodiments, the first DART to receive the request processes it. In yet another embodiment, the assignment of a request to a DART may be based upon real time loading information. If the request contains a DART specific address, then the addressed DART reads the request as depicted in stage 1730.
[0251] Likewise, after a request is assigned in stage 1725, a DART reads the request in stage 1730. The DART then parses the request as illustrated in stage 1735. In parsing the request, the DART may strip out a subject heading, addressing information, and message content. The flow then proceeds to the determination of the function request explained with regard to FIG. 16.
[0252] FIG. 18 is a flow chart illustrating the operation of a DART entity performing a store function (1615 in FIG. 16) consistent with the principles of the present invention. In exemplary stage 1805, the DART receives from the network transport the message that is to be stored. The DART, as depicted in decision block 1810, examines the message header, content, or appended information to determine if it contains an address for a specific MDS. For example, a header contained with the message may contain the address of a specific MDS, such as "MDS1." If the message header, content, or appended information does not contain a specific MDS address, then the DART, as illustrated in stage 1820, determines which MDS is to store the message.
[0253] The DART accomplishes the assignment function in any of a number of ways. For example, the DART may store the message on an MDS that contains the messages for a particular subscriber. If the message header, content, or appended information contains a specific MDS address, then the DART, as illustrated in stage 1830, places the message on the backbone datastore transport. Likewise, after assigning an MDS in stage 1820, the DART places the message on the backbone datastore transport as depicted in stage 1830. The message is received and stored by the designated MDS in stage 1835. In stage 1835, the MDS stores the message and any accompanying information in a storage device.
[0254] In stage 1840, the DART produces a confirmation message and publishes it on the network transport. For example, in the case of a store request, the DART produces a confirmation message indicating that the message has been stored. In exemplary stage 1845, the DART receives from the network transport an update message request. In one embodiment of the present invention, this update message request may contain delivery information for the message. For example, if the message is the subject of a "DELIVER_STORE" request, then a delivery confirmation may accompany the update message request to indicate that the message has been delivered. In stage 1850, the DART places the update information on the backbone datastore transport. In stage 1855, the same MDS that stored the message receives and stores the update information.
[0255] FIG. 19 illustrates a query request (1625 in FIG. 16) performed by a DART entity consistent with the principles of the present invention. In exemplary stage 1905, the DART receives a query request from the network transport. The DART, as depicted in decision block 1910, examines the request header, content, or appended information to determine if it contains an address for a specific MDS. For example, a header accompanying the request may contain the address of a specific MDS, such as "MDS1." If the request header, content, or appended information does not contain a specific MDS address, then the DART, as illustrated in stage 1920, determines which MDS to query.
[0256] The DART accomplishes this function in any of a number of ways. For example, the DART may query the MDS that contains the messages associated with a particular subscriber. If the request header, content, or appended information contains a specific MDS address, then the DART, as illustrated in stage 1930, places the request on the backbone datastore transport. Likewise, after determining which MDS to query in stage 1920, the DART places the request on the backbone datastore transport as depicted in stage 1930. The request is received by the designated MDS in stage 1935. In stage 1935, the MDS accesses the requested information from a storage device. In stage 1940, the requested information retrieved from the MDS is placed on the backbone datastore transport. In stage 1945, the DART receives the requested information and, in stage 1950, places the requested information on the network transport.
[0257] FIG. 20 illustrates a cancel request (1635 in FIG. 16) performed by a DART entity consistent with the principles of the present invention. In exemplary stage 2005, the DART receives a cancel request from the network transport. The DART, as depicted in stage 2010, examines the request header, content, or appended information to determine if it contains an address for a specific MDS. For example, a header accompanying the request may contain the address of a specific MDS, such as "MDS1." If the request header, content, or appended information does not contain a specific MDS address, then the DART, as illustrated in stage 2020, determines which MDS contains the message that is to be canceled. If the request header, content, or appended information contains a specific MDS address, then the DART, as illustrated in stage 2030, places the request on the backbone datastore transport.
[0258] Likewise, after determining which MDS contains the message to be canceled in stage 2020, the DART places the request on the backbone datastore transport as depicted in stage 2030. The request is received by the designated MDS in stage 2035. In stage 2040, the DART updates the corresponding record in the MDS with the cancel message information. For example, the DART, in accessing the MDS with the particular message, may delete the message from the MDS or may store information on the MDS indicating that the message is a canceled message. In stage 2045, the DART generates a confirmation message. This confirmation message, for example, contains information