Abstract:
An flexible, extensible, and dynamically configurable Advanced IP Messaging Server (AIMS) facility that among other things may leverage various pools of data—including for example routing data, location and presence data, Mobile Subscriber profile data, etc.—to expeditiously process and route a wide range of information including among other things conventional Short Message Service, Multimedia Message Service, IP Multimedia Subsystem, etc. messaging; E-Mail messaging; Instant Messaging communications; Voice Over IP and other (e.g., video conference, etc.) data streams; Session Initiation Protocol-addressed artifacts; etc.

Description:
[0001]    This patent application claims the benefit of U.S. Provisional Patent Application Ser. No. 61/316,513, filed on 23 Mar. 2010, which is herein incorporated by reference in its entirety. 
     
    
     BACKGROUND 
       [0002]    1. Field of the Invention 
         [0003]    The present invention relates generally to telecommunications services. More particularly, the present invention relates to capabilities that enhance substantially the value and usefulness of various communication paradigms including, inter alia, Short Message Service (SMS), Multimedia Message Service (MMS), Internet Protocol (IP) Multimedia Subsystem (IMS), Wireless Application Protocol (WAP), Electronic Mail (E-Mail), Instant Messaging (IM), etc. 
         [0004]    2. Background of the Invention 
         [0005]    As the ‘wireless revolution’ continues to march forward through various flavors of 2G, 3G, 4G, and beyond, the importance to a Mobile Subscriber (MS)—for example a user of a Wireless Device (WD) that is serviced by possibly inter alia a Wireless Carrier (WC)—of their WD grows substantially. Examples of WDs include, possibly inter alia, mobile telephones, handheld computers, Internet-enabled phones, pagers, radios, TVs, audio devices, car audio (and other) systems, recorders, text-to-speech devices, bar-code scanners, net appliances, mini-browsers, personal digital assistants (PDAs), etc. 
         [0006]    One consequence of such a growing importance is the resulting ubiquitous nature of WDs—i.e., MSs carry them at almost all times and use them for an ever-increasing range of activities. For example, MSs employ their WDs to, possibly inter alia: 
         [0007]    1) Exchange messages with other MSs (e.g., “Let&#39;s meet for dinner at 6”) through Peer-to-Peer, or P2P, messaging. 
         [0008]    2) Secure information (such as, for example, weather updates, travel alerts, news updates, sports scores, etc.), participate in voting initiatives (such as, for example, with the television show American Idol®), interact with social networking sites, etc. through various of the available Application-to-Peer, or A2P, based service offerings. 
         [0009]    3) Engage in Mobile Commerce (which, broadly speaking, encompasses the buying and selling of merchant-supplied products, goods, and services through a WD) and Mobile Banking (which, broadly speaking, encompasses performing various banking activities through a WD). 
         [0010]    Coincident with the rapid growth of WDs has been the desire of WCs, and other entities within a mobile ecosystem, to offer to MSs a continuing stream of new and interesting products and services that, possibly inter alia, attract new MSs and retain existing MSs, leverage or exploit the continually increasing features and capabilities of new WDs, incrementally increase the volume of messaging traffic (and the revenue that is associated with same) that flows through a mobile ecosystem, etc. 
         [0011]    Implementation of the various product/service offerings that were referenced above may raise a host of processing, routing, performance, billing, etc. issues which an existing telecommunication infrastructure, which may have originated during the days of voice-only landline communication and which may have evolved incrementally over time to handle aspects of wireless communication, may be incapable of handling and which, as a consequence of the resulting void, may impact or preclude the delivery of such products or services. 
         [0012]    Aspects of the present invention fills the lacuna that was noted above by (1) providing enhanced communication processing capabilities through among other things an Advanced IP Messaging Server (AIMS) facility that among other things may leverage various pools of data (e.g., routing data, location and presence data, MS profile data, etc.) to expeditiously process and route a wide range of information (including conventional SMS, MMS, etc. messaging; Voice Over IP [VoIP] and other data streams; Session Initiation Protocol [SIP]-addressed artifacts; etc.) while (2) addressing, in new and innovatory ways, various of the not insubstantial challenges that are associated with same. 
       SUMMARY OF THE INVENTION 
       [0013]    In one embodiment of the present invention there is provided a server-based method for directing a quanta of data towards a WD of a MS that includes possibly among other things (1) receiving the quanta of data at a gateway, the quanta of data comprising an originating address, a destination address, and a content, (2) performing a plurality of processing steps including at least creating an Internal Message Object (IMO), characterizing aspects of the quanta of data, generating one or more Feature Tags, preserving aspects of same in the IMO, and selecting a delivery route, and (3) selecting aspects of the IMO for dispatch over the selected delivery route. 
         [0014]    In another embodiment of the present invention there is provided a processor-based system on a server for directing a quanta of data towards a WD of a MS that includes possibly among other things (1) a gateway configured to receive the quanta of data, (2) workflow modules configured to perform various processing steps including at least creating an IMO, characterizing aspects of the quanta, generating one or more Feature Tags, preserving aspects of same in the IMO, and selecting a delivery route, (2) a gateway configured to select aspects of the IMO for dispatch over the selected delivery route, (3) a repository, and (4) an administrator. 
         [0015]    These and other features of the embodiments of the present invention, along with their attendant advantages, will be more fully appreciated upon a reading of the following detailed description in conjunction with the associated drawings. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0016]      FIG. 1  is a diagrammatic presentation of an exemplary Messaging Inter-Carrier Vendor (MICV). 
           [0017]      FIG. 2  illustrates various implementation aspects of an exemplary MICV. 
           [0018]      FIG. 3  illustrates various implementation aspects of an exemplary MICV Message Processing Engine (MPE). 
           [0019]      FIG. 4  illustrates aspects of an exemplary incoming SMS message received via an IP-based protocol. 
           [0020]      FIG. 5  illustrates aspects of an exemplary incoming SMS message received via Signaling System Number 7 (SS7). 
           [0021]      FIG. 6  illustrates aspects of a hypothetical Internal Message Object (IMO) that is possible in connection with an SMS message received via an IP-based protocol. 
           [0022]      FIG. 7  illustrates aspects of a hypothetical IMO that is possible in connection with an SMS message received via SS7. 
           [0023]      FIG. 8  illustrates a hypothetical Feature Tag that is possible under aspects of the instant invention. 
           [0024]      FIG. 9  is a diagrammatic presentation of the three logical IMS planes. 
           [0025]      FIG. 10  illustrates exemplary logical connections of multiple carriers that is possible under aspects of the instant invention. 
           [0026]      FIG. 11  is a diagrammatic presentation of the virtual implementation of the three logical IMS planes within aspects of the present invention. 
           [0027]      FIG. 12  depicts various of the elements that might be found in an exemplary AIMS environment. 
           [0028]      FIG. 13  illustrates aspects of an exemplary IMO. 
           [0029]      FIG. 14  illustrates aspects of an exemplary address resolution facility. 
           [0030]      FIG. 15  illustrates elements of an exemplary data model that is supportive of various of the location aspects of the present invention. 
           [0031]      FIG. 16  depicts the hypothetical contents of an exemplary data model. 
           [0032]      FIG. 17  illustrates an exemplary Pricing Scheme (PS). 
           [0033]      FIG. 18  illustrates an exemplary Contract Scheme (CS). 
           [0034]      FIG. 19  depicts an exemplary Universal Rating Engine (URE). 
           [0035]      FIG. 20  illustrates aspects of an exemplary IMO. 
           [0036]      FIG. 21  illustrates one particular IMS-centric arrangement that is possible through aspects of the present invention. 
           [0037]      FIG. 22  depicts at a high-level a logical arrangement that is possible under aspects of the present invention. 
           [0038]      FIGS. 23 and 24  illustrate aspects of a Java-based OSGi dynamic component model. 
           [0039]      FIG. 25  illustrates the possible interaction/collaboration between a hypothetical collection of bundles. 
           [0040]      FIGS. 26   a  through  26   d  illustrate several of the SMS-based exchanges or interactions that may be possible through aspects of the present invention. 
           [0041]      FIGS. 27   a  through  27   e  illustrate several of the MMS-based exchanges or interactions that may be possible through aspects of the present invention. 
           [0042]      FIG. 28  depicts an exemplary computer system through which embodiments of aspects of the present invention may be implemented. 
           [0043]      FIG. 29  depicts some of the logical elements of a processing and routing layer that may be possible through aspects of the present invention. 
           [0044]      FIG. 30  illustrates how aspects of a routing layer might be physically realized under particular implementation approach. 
           [0045]      FIG. 31  depicts aspects of an exemplary IMO. 
       
    
    
       [0046]    It will be understood that the drawings depict embodiments of the invention. Variations of these embodiments will be readily apparent to persons skilled in the relevant art(s) based on the teachings contained herein. 
       DETAILED DESCRIPTION OF THE INVENTION 
       [0047]    In the discussion below aspects of AIMS (see for example  FIG. 22 ) are described and illustrated as residing within a centrally-located, full-featured MICV facility. Reference is made to U.S. Pat. No. 7,154,901 entitled “INTERMEDIARY NETWORK SYSTEM AND METHOD FOR FACILITATING MESSAGE EXCHANGE BETWEEN WIRELESS NETWORKS,” and its associated continuations, for a discussion of the concept of a MICV, a summary of various of the services/functions/etc. that may be performed by a MICV, and a discussion of the numerous advantages that may arise from same. 
         [0048]    In the discussion below aspects of AIMS are described and illustrated as being offered by a Service Provider (SP). A SP may, for example, be realized through any combination of, possibly inter alia, any one or more of (1) an element of a WC, an element of a landline carrier, an element of a MICV, or multiple such elements working together; (2) a Third-Party (3P) such as possibly inter alia a merchant, a Content Provider (CP, such as for example a news organization, an advertising agency, a brand, etc.), or a financial institution; (3) multiple 3P entities working together; (4) a 3P service bureau; etc. 
         [0049]    As illustrated in  FIG. 1  and reference numeral  100 , under one particular arrangement a MICV  120  is disposed between, possibly inter alia, multiple WCs (WC 1    114 , WC 2    116 →WC x    118 ) and multiple SPs (SP 1    122 →SP y    124 ) and thus ‘bridges’ all of the connected entities. A MICV  120  thus, as one simple example, may offer various routing, formatting, delivery, value-add, etc. capabilities that provide, possibly inter alia: 
         [0050]    1) A WC  114 → 118  (and, by extension, all of the MSs  102 → 104 ,  106 → 108 ,  110 → 112  that are serviced by the WC  114 → 118 ) with ubiquitous access to a broad universe of SPs  122 → 124  (and other entities that may be connected to the MICV), and 
         [0051]    2) A SP  122 → 124  (and other entities that may be connected to the MICV) with ubiquitous access to a broad universe of WCs  114 → 118  (and, by extension, to all of the MSs  102 → 104 ,  106 → 108 ,  110 → 112  that are serviced by the WCs  114 → 118 ). 
         [0052]    Generally speaking a MICV may have varying degrees of visibility (e.g., access, etc.) to the (MS←→MS, MS←→SP, etc.) messaging traffic: 
         [0053]    1) A WC may elect to route just their out-of-network messaging traffic to a MICV. Under this approach the MICV would have visibility (e.g., access, etc.) to just the portion of the WC&#39;s messaging traffic that was directed to the MICV by the WC. 
         [0054]    2) A WC may elect to route all of their messaging traffic to a MICV. The MICV may, possibly among other things, subsequently return to the WC that portion of the messaging traffic that belongs to (i.e., that is destined for a MS of) the WC. Under this approach the MICV would have visibility (e.g., access, etc.) to all of the WC&#39;s messaging traffic. 
         [0055]    For purposes of illustration,  FIG. 2  and reference numeral  200  depict a possible logical implementation of aspects of a MICV  202  under one particular arrangement. The figures depict among other things Gateways ( 208  and  214  that for example provide information/data receipt and dispatch capabilities across possibly inter alia different application-level communication protocols), Queues ( 210  and  212  that for example provide interim storage and buffering capabilities), a Message Highway (MH  220 , that for example provides interconnection capabilities), and MPEs  222 → 224 . 
         [0056]      FIG. 3  and reference numeral  300  depict a possible logical implementation of aspects of a MPE  302 . A MPE may contain several key components—Receivers (Rx 1    304 →Rx a    314  in the diagram), Queues (Q 1    306 →Q b    316  and Q 1    310 →Q d    320  in the diagram), WorkFlows (WorkFlow 1    308 →WorkFlow c    318  in the diagram), Transmitters (Tx 1    312 →Tx e    322  in the diagram), and an Administrator  326 . It will be readily apparent to one of ordinary skill in the relevant art that numerous other components are possible within a MPE. 
         [0057]    A dynamically updateable set of one or more Receivers (Rx 1    304 →Rx a    314  in the diagram) ‘get’ messages from a MICV MH and deposit them on an intermediate or temporary Queue (Q 1    306 →Q b    316  in the diagram) for subsequent processing. 
         [0058]    A dynamically updateable set of one or more Queues (Q 1    306 →Q b    316  and Q 1    310 →Q d    320  in the diagram) operate as intermediate or temporary buffers for incoming and outgoing messages. 
         [0059]    A dynamically updateable set of one or more WorkFlows (WorkFlow 1    308 →WorkFlow c    318  in the diagram) remove incoming messages from an intermediate or temporary Queue (Q 1    306 →Q b    316  in the diagram), perform all of the required operations on the messages, and deposit the processed messages on an intermediate or temporary Queue (Q 1    310 →Q d    320  in the diagram). The WorkFlow component will be described more fully below. 
         [0060]    A dynamically updateable set of one or more Transmitters (Tx 1    312 →Tx e    322  in the diagram) remove processed messages from an intermediate or temporary Queue (Q 1    310 →Q d    320  in the diagram) and ‘put’ the messages on a MICV MH. 
         [0061]    An Administrative Engine  324  provides a linkage to all of the different components of a MPE so that a MPE, along with all of the different components of a MPE, may be fully and completely administered or managed  326 . 
         [0062]    While portions of the discussion below will reference a MICV, it will be readily apparent to one of ordinary skill in the relevant art that numerous other arrangements are equally possible and indeed are fully within the scope of the present invention. 
         [0063]    Under one possible implementation paradigm aspects of an AIMS environment may be physically realized through the Java-based OSGi dynamic component model (see for example  FIG. 23 ). Under such an approach various of the aspects of the present invention may be realized through possibly inter alia one or more of the following components (see for example  FIG. 24 ): 
         [0064]    1) Process Bundle—e.g., an executable entity that supports some processing activity such as inter alia routing, billing, reporting, etc. 
         [0065]    2) Service Bundle—e.g., an aggregation of application-level services that may be realized (implemented) through other bundles. 
         [0066]    3) Object Bundle—e.g., a set of Java classes that may be accessed or leveraged by other bundles. 
         [0067]    4) System Bundle—e.g., a collection that offers core or key services. 
         [0068]    For purposes of illustration, under such a paradigm  FIG. 25  illustrates the possible interaction or collaboration between a hypothetical collection of bundles that might take place during the processing of a SIP-based SMS message that is dispatched to a legacy platform (SMS Exchange/MMS Exchange) for final delivery. 
         [0069]    Under different implementation paradigms the ‘boundary’ between various AIMS components may be realized through possibly inter alia queues (e.g., in-memory, via disk drives, etc.), through shared memory regions, through files, through application-level communication protocols, etc. and information may be passed across such boundaries as possibly inter alia proprietary data structures, Java Message Service (JMS) messages or objects, etc. 
         [0070]    In portions of the discussion below reference is made to messages that are sent, for example, between a MS and a SP. As set forth below, a given ‘message’ sent between a MS and a SP may actually comprise a series of steps in which the message is received, forwarded and routed between different entities, including possibly inter alia a MS, a WC, a MICV, and a SP. Thus, unless otherwise indicated, it will be understood that reference to a particular message generally includes that particular message as conveyed at any stage between an origination source, such as for example a MS, and an end receiver, such as for example a SP. As such, reference to a particular message generally includes a series of related communications between, for example, a MS and a WC; a WC and a MICV; a MICV and a SP; etc. The series of related communications may, in general, contain substantially the same information, or information may be added or subtracted in different communications that nevertheless may be generally referred to as a same message. To aid in clarity, a particular message, whether undergoing changes or not, is referred to by different reference numbers at different stages between a source and an endpoint of the message. 
         [0071]    Aspects of AIMS may ‘plug into’ different layers/levels of legacy, current, and/or future technology and among other things may for example facilitate interoperation between such technologies. For example, looking just at an IMS context: 
         [0072]    1)  FIG. 9  and reference numeral  900  illustrate IMS&#39; three logical planes: 
         [0073]    a) Services Plane  902 . For example, one or more Application Server (AS) instances  904 , Billing facilities  906 , Reporting facilities  908 , etc. 
         [0074]    b) Control Plane  910 . For example, a Home Subscriber Server (HSS) capability  912 , a Call Session Control Function (CSCF) capability  914 , one or more Media Gateway (MG) instances  916 , etc. 
         [0075]    c) Network or Transport Plane  918 . Support, interfaces, etc. for, possibly inter alia, VoIP  920 , WiFi  922 , Public Land Mobile Network (PLMN)  924 , Public Switched Telephone Network (PSTN)  926 , etc. 
         [0076]    2)  FIG. 10  and reference numeral  1000  depict how the different functional elements of an entity (e.g., carriers such as C a    1002 →C z    1010 , etc.) within an IMS ecosystem may plug in to AIMS&#39; single access/connection point  1032 —e.g., elements of carrier Ca&#39;s  1002  Control Plane and Network or Transport Plane may plug in to AIMS&#39; single access/connection point  1018 → 1020 , elements of carrier Cb&#39;s  1004  Services Plane may plug into AIMS&#39; single access/connection point  1022 . Similar access points may be realized at  1024 → 1030 . 
         [0077]    3)  FIG. 11  and reference numeral  1100  illustrate how the single access/connection point  1104  serves much like a façade, behind which connected entities (e.g., carriers such as C a →C z    1102 , etc.) may access one or more of the virtual implementations of IMS&#39; logical planes  1106 → 1110 . 
         [0078]    Thus, for example, as a carrier&#39;s environment grows and changes, as a carrier&#39;s business needs and models change and evolve, as a carrier deploys new service offerings, etc. it can, possibly among other things, plug into (and thus take advantage of the features and functions that are offered by) different combinations of the virtual implementations of IMS&#39; logical planes all through the single access/communication point. 
         [0079]    Additionally, placing the virtual planes behind a single façade allows for, possibly among other things, ongoing and dynamic changes, updates, etc. to the physical implementation of a plane without any impact on, or interruptions to, any of the connected entities. 
         [0080]    4)  FIG. 21  and reference numeral  2100  depict one particular IMS-centric arrangement that is possible through aspects of the present invention—Networks A  2102 , B  2106 , and C  2110  represent hypothetical IMS-enabled or IMS-capable carriers; Network D  2112  represents a hypothetical non-IMS-enabled carrier that offers, possibly inter alia, MMS services; and Network E  2108  represents a hypothetical fixed (e.g., landline) carrier that offers, possibly inter alia, Digital Subscriber Line (DSL) services. AIMS  2104  may among other things tie together the different (disparate, natively incompatible, etc.) environments. The depicted arrangement is illustrative only and it will be readily apparent to one of ordinary skill in the relevant art that numerous other arrangements are easily possible and indeed are fully within the scope of the present invention. 
         [0081]    Central to the operation of AIMS is the unit of information within AIMS that is received, manipulated or otherwise operated on, dispatched, etc. Unlike prior environments that might operate just on, and thus potentially be limited just to, a SMS message or a MMS message, the unit of information within AIMS is a more general quanta of data. Accordingly AIMS is natively capable of operating on inter alia an SMS message, a MMS message, an IMS message, an E-Mail message, a VoIP data stream, IM data, a video conference data stream, etc. 
         [0082]    Within AIMS a flexible, extensible, and dynamically configurable IMO (see for example  FIG. 13  and  FIG. 20 ) may be employed as an internal representation of a received quanta of data. An IMO ( 1302  and  2004 ) may logically contain possibly inter alia one or more headers ( 1304  and  2006 ), a body ( 1312  and  2008 ), etc. within which for example aspects of a received quanta of data may be preserved ( 1306 → 1310  and  2010 → 2012 ). An IMO may physically be realized through any combination of possibly inter alia proprietary data structures, JMS messages or objects, flat files, database entries, in-memory constructs, etc. 
         [0083]    For purposes of illustration, within an SMS context AIMS may support the receipt and dispatch of information through possibly inter alia Short Message Peer-to-Peer (SMPP) via Transmission Control Protocol (TCP)/IP and Mobile Application Part (MAP) via SS7. Under such a context: 
         [0084]    1)  FIG. 4  and reference numeral  400  depict an exemplary incoming SMS message received via for example SMPP with for example the data elements associated with the SMS message  428 → 436  encapsulated within a SMPP Protocol Data Unit (PDU  422 ) encapsulated within a TCP Segment  412  encapsulated within an IP Packet  402 . 
         [0085]    2)  FIG. 5  and reference numeral  500  depict an exemplary incoming SMS message received via for example MAP with for example the data elements associated with the SMS message encapsulated within a Message Signal Unit (MSU  502 ) 
         [0086]    3)  FIG. 6  and reference numeral  600  depict a hypothetical IMO  602  that is possible in support of an SMS message received via for example SMPP, and 
         [0087]    4)  FIG. 7  and reference numeral  700  depict a hypothetical IMO  702  that is possible in support of an SMS message received via for example MAP. 
         [0088]    It will be readily apparent to one of ordinary skill in the art that numerous alternative arrangements, in connection with for example different contexts (such as inter alia MMS, VoIP, etc.) and different communication protocols, are easily possible. 
         [0089]    AIMS includes among other elements a vertically and horizontally scalable Protocol Engine (PE) layer (see for example reference point  1220  in  FIG. 12 ) through which information may be received and/or transmitted using any combination of one or more of the supported communication protocols including inter alia SS7, TCP/IP, User Datagram Protocol (UDP)/IP, Really Simple Syndication (RSS), SMPP, Simple Mail Transfer Protocol (SMTP), HyperText Transfer Protocol (HTTP), Extensible Messaging and Presence Protocol (XMPP), MM4, MM7, SIP, etc. 
         [0090]    A PE layer may house a dynamically updateable set of one or more PEs (PE 1    1224 →PE n    1230  in the  FIG. 12 ). A PE may, for example, leverage a body of flexible, extensible, and dynamically updateable configuration information as it completes its tasks, including possibly inter alia: 
         [0091]    A) Receiving incoming and sending outgoing traffic using any combination of the supported communication protocols, paradigms, etc. 
         [0092]    B) Performing various extraction, validation, editing, formatting, conversion, etc. operations on the elements of an incoming and/or outgoing data stream—e.g., source address, destination address, encoding indicators or flags, payload or body, etc. The specific elements that were just described are illustrative only and it will be readily apparent to one of ordinary skill in the relevant art that numerous other elements are easily possible and indeed are fully within the scope of the present invention. 
         [0093]    C) Encapsulating various elements of an incoming data stream within an IMO and/or un-encapsulating various elements of an outgoing data stream from an IMO. 
         [0094]    The catalog of PE processing steps that was described above is illustrative only and it will be readily apparent to one of ordinary skill in the relevant art that numerous other processing steps are easily possible and indeed are fully within the scope of the present invention. 
         [0095]    A PE layer may be quickly and easily scaled either vertically (to for example add additional capacity in response to increases in demand [e.g., message volume]), horizontally (to for example add support for a new application-level communication protocol), or both. 
         [0096]    AIMS includes among other elements a flexible, extensible, and dynamically configurable WorkFlow-based Processing, Routing, and Switching (PRS) layer (see reference numeral  1232  in  FIG. 12  along with  FIG. 29  and reference numeral  2900 ). The WorkFlow elements of the PRS layer may be ‘glued’ together by a Message Routing Language (MRL, a full-featured scripting language that is based in part on the disclosures found in U.S. Pat. No. 6,735,586 entitled “System and Method for Dynamic Content Retrieval” and U.S. Pat. No. 7,240,067 entitled “System and Methodology for Extraction and Aggregation of Data from Dynamic Content”) and may support among other things: 
         [0097]    1) Processing. For example, the automatic and dynamic determination of the type of content (e.g., an SMS message, a VoIP data stream, etc.) in a received quanta of data and the preservation of same in for example an IMO; content transcoding operations; billing activities (including possibly pricing/rating events); data logging and collection in support of reporting; the generation of a Feature Tag; etc. 
         [0098]    2) Routing. For example, the authoritative resolution of destination and/or source addresses; the examination of available routes and the application of various criteria (possibly including for example MS WD location information, least cost routing rules, MS profile and preference information, route loadings, aspects of a Feature Tag, attributes of a received quanta of data [e.g., data type, size, etc.], Quality of Service constraints, billing and revenue constraints, etc.) to available routes to arrive at a specific route selection; etc. 
         [0099]    3) Switching. For example, directing (switching) based on a selected route data to an appropriate outbound delivery channel (see for example reference number  1234  in  FIG. 12 ). 
         [0100]    The catalog of processing activities that was described above is illustrative only and it will be readily apparent to one of ordinary skill in the relevant art that numerous other processing activities are easily possible and indeed are fully within the scope of the present invention. 
         [0101]    The billing activities within the Processing portion of a PRS layer may make use of a PS. A PS is a self-contained framework for capturing all of the particulars associated with cost and may include, possibly among other things, elements such as: 
         [0102]    1) Descriptive Information. A range of descriptive or identifying information that may include, possibly inter alia, a unique identifier, a description (that may be displayed, that may be conveyed to an Operator for inclusion in a line-item on a MS monthly statement, etc.), effective dates/times, etc. 
         [0103]    2) Interval. The starting point (e.g., the first of each month) and the duration (e.g., one calendar month) of the interval or cycle during which cost is accumulated. 
         [0104]    3) Pre Amounts. Zero, one, or more fixed (e.g., $5.00) or variable (e.g., $0.05 times the number of items processed) amounts that contribute to an interval&#39;s overall or aggregate cost amount. A Pre Amount may be either a charge (a positive amount) or a discount (a negative amount) and may include, possibly inter alia, set-up fees, monthly service charges, etc. 
         [0105]    4) Base Amount. The particulars that are applied to each event to rate, or determine the cost of, an event. Numerous plans or models are available to select from, including inter alia Static-Flat Rate-Basic (e.g., a single, fixed price), Static-Flat Rate-Tiered (e.g., price is derived from, inter alia, volume through defined thresholds or plateaus), etc. It is important to note that the preceding catalog of plans is illustrative only; it will be readily apparent to one of ordinary skill in the relevant art that other plans may be easily added. 
         [0106]    5) Post Amounts. Zero, one, or more fixed (e.g., $1.00) or variable (e.g., 2% of the aggregate interval cost) amounts that contribute to an interval&#39;s overall or aggregate cost. A Post Amount may be either a charge (a positive amount) or a discount (a negative amount). 
         [0107]    For purposes of illustration, consider the hypothetical PS  1702  that is illustrated in  FIG. 17  (and reference number  1700 ) which includes three (3) Pre Amounts ( 1706 → 1710 ), one (1) Base Amount  1712 , and two (2) Post Amounts ( 1714 → 1716 ). 
         [0108]    It should be noted that the specific PS that was just presented is illustrative only. It will be readily apparent to one or ordinary skill in the relevant art that the inclusion of different elements and/or alternative arrangements of the elements are easily possible. 
         [0109]    One or more PSs may be associated with a Contract. A Contract may contain, possibly inter alia, descriptive information (e.g., a unique identifier, a description, etc.), all applicable terms and conditions (e.g., including support for one or more levels of optional taxation by, possibly inter alia, geography, national entity, etc.), etc. 
         [0110]    One or more Contracts may be associated with an Operator, Merchant, etc. through a CS. For purposes of illustration consider the hypothetical CS  1800  that is presented in  FIG. 18 . The depicted CS  1800  employs a flexible and extensible ontology that easily supports multiple contracts ( 1806 ,  1814 ,  1816 ) per Operator/Merchant/etc  1802 . A contract may include a Pricing Scheme 1 -&gt;Pricing Scheme n  ( 1808 ,  1810 ,  1812 ). Descriptive material  1804  may also be associated with a given Operator/Merchant  1802 . 
         [0111]    The billing activities within the PRS layer may also make use of a URE. As illustrated in  FIG. 19  and reference numeral  1900  a hypothetical URE  1904  may accept as input a raw (or unrated) event  1902 ; leverage a pool of flexible, extensible, and dynamically configurable definitional  1908 → 1910  and configuration  1912  information; and produce as output a processed (or rated) event  1906 . 
         [0112]    The different billing activities may yield among other things a billing transaction. A billing transaction may take any number of forms and may involve different external entities (e.g., a carrier billing system, a carrier billing system service bureau, a credit or debit card clearinghouse, a financial institution, etc.). A billing transaction may include, possibly inter alia: 
         [0113]    1) The appearance of a line item charge on the bill or statement that a MS receives from her WC. 
         [0114]    2) The charging of a credit card or the debiting of a debit card. 
         [0115]    3) The (electronic, etc.) transfer of funds. 
         [0116]    4) The generation of an invoice, statement, etc. 
         [0117]    The Processing portion of a PRS layer may optionally generate, and possibly preserve in for example an IMO, one or more Feature Tags. A Feature Tag (see  FIG. 8  and reference numeral  802 ) is effectively a compact digest of key data elements, thus providing inter alia a representation of or an alias for or a ‘fingerprint’ of those data elements, and may be based on possibly inter alia (a) attributes of a received quanta of data (e.g., data type, size, etc.), (b) routing and switching attributes (e.g., a selected route, the current loading on that route, etc.), (c) billing attributes, (d) etc. Once generated, a Feature Tag may be quickly referenced by other elements of an AIMS environment as those elements complete their processing activities. (See for example U.S. Pat. No. 7,240,067 entitled “System and Methodology for Extraction and Aggregation of Data from Dynamic Content” and pending U.S. patent application Ser. No. 12/140,478 entitled “System and Method for Enhanced Message Routing” for a discussion of aspects of a Feature Tag). Feature Tags may follow an organized naming scheme and the naming scheme may incorporate an encoding model (e.g., the name ‘SIP-PSI’ might indicate a SIP message that has a Person endpoint, is of type SIP SIMPLE, and has an Indeterminate or unknown domain), may be organized in any number of ways (including for example alphabetically, nested, hierarchically, etc.), and may be searched or matched against in numerous ways (including for example sequentially, through wildcards, etc.).  FIG. 31  depicts aspects of illustrative Feature Tags (e.g., SIP-PSI→AGT-S→RCP-FR→TXT-NN1-001)  3102 . 
         [0118]    The Routing portion of a PRS layer may support, and may include as it makes a route determination, among other things information on the current physical location of a MS&#39; WD (as received for example from possibly inter alia the WC that services the WD). For purposes of illustration, a portion of an exemplary data model is illustrated in  FIG. 15  (and reference numeral  1500 ) and hypothetical contents of such a data model are presented in  FIG. 16  (and reference numeral  1600 ). 
         [0119]    The Routing portion of a PRS layer may also leverage a comprehensive, flexible, scalable, etc. lookup facility (indicated, albeit at a very high level, as Routing Data  1264  in  FIG. 12 ) to support, possibly inter alia, its routing operations. Such a lookup facility may provide authoritative answers to inquiries like “At this moment in time what carrier services the Telephone Number (TN) 1-703-555-1212 ?”, “What entity services the SIP addresss sip:john.doe@bigcompany.com?”, etc. Among other things such a lookup facility may address (1) the complexities that are associated with all of the different TN numbering plans, schemes, etc. that exist around the world; (2) the complexities that arise with worldwide Mobile Number Portability (MNP) regimes; etc. A more detailed depiction of such a lookup facility is presented in  FIG. 14  and reference numeral  1400 . Such a lookup facility may consist of, possibly inter alia: 
         [0120]    A) An Electronic Numbering (ENUM) façade  1410  through which possibly inter alia various PRSEs (E 1    1402 →E n    1408  in  FIG. 14 ) may connect, submit routing inquiries, receive routing responses, etc. 
         [0121]    B) A dynamically updateable set of one or more In-Memory Databases (In-Memory Database 1    1412 →In-Memory Database n    1414  in the diagram) that optionally house or host selected data (including, possibly inter alia, data from a Composite Routing Database [CRD]  1416 ) to provide, as one example, optimal performance. 
         [0122]    C) A Real-Time Query Facility (RTQF)  1422  through which inquiries may be dispatched real-time to authoritative bodies (such as, for example, TN assignment administrators) around the world. A RTQF  1422  may support multiple communication channels, paradigms, protocols, etc. (such as, possibly inter alia, SS7  1424 , TCP/IP  1426 , UDP/IP, SMPP  1428 , etc.). 
         [0123]    D) A CRD  1416  containing comprehensive routing information for, possibly inter alia, TNs within all of the different TN numbering plans, schemes, etc. that exist around the world. A CRD  1416  may receive updates (e.g., dynamically, on a scheduled basis, etc.) from any number of sources or feeds including, possibly inter alia, domestic  1418  (such as, for example, from a Local Exchange Routing Guide [LERG], from one or more Number Portability Administration Centers [NPACs], etc.) and international  1420  (such as, for example, from Hong Kong, from the United Kingdom, etc.). 
         [0124]    A lookup facility as described above may support a wide range of address types including among others a TN (such as 703-555-1234), a Short Code (SC, such as 46625), a SIP Uniform Resource Identifier (URI, such as sip:mark@mydomain.com), a Tel URI (such as tel:+19257652333), a Uniform Resource Locator (URL), etc. 
         [0125]    The Routing portion of a PRS layer may be physically realized through any number of technologies, arrangements, etc. As just one example,  FIG. 30  and reference numeral  3000  illustrate how aspects of the Routing portion of a PRS layer might be realized using a Java-based OSGi dynamic component model (see for example paragraphs 61→66 above). 
         [0126]    The Databases  1262 ,  1264 ,  1272 → 1276 ,  1282 → 1286  that are depicted in  FIG. 12  are a logical representation of the possibly multiple physical repositories that may be implemented to support, inter alia, configuration, routing, profile, monitoring, logging, reporting, etc. information. The physical repositories may be implemented through any combination of conventional Relational Database Management Systems (RDBMSs), through Object Database Management Systems (ODBMSs), through in-memory Database Management Systems (DBMSs), or through any other equivalent facilities. 
         [0127]    The Administrator  1290  that is depicted in  FIG. 12  provides management or administrative control over all of the different components of an environment through, as one example, a World Wide Web (WWW)-based interface. It will be readily apparent to one of ordinary skill in the relevant art that numerous other interfaces (e.g., a data feed, an Application Programming Interface [API], etc.) are easily possible. 
         [0128]    An AIMS environment may maintain one or more repositories (e.g.,  1272 → 1276  and  1282 → 1286  in  FIG. 12 ) into which selected details of all administrative, analytical, processing, routing, etc. activities; Transaction Detail Records (TDRs); the results of Extraction-Transformation-Load (ETL) operations; etc. may be recorded. Among other things, such repositories may be used to support: 
         [0129]    1) Scheduled (e.g., daily, weekly, etc.) and/or on-demand reporting with report results delivered through SMS, MMS, etc. messages; through E-Mail; through a WWW-based facility; etc. 
         [0130]    2) Scheduled and/or on-demand data mining initiatives (possibly leveraging or otherwise incorporating one or more external data sources) with the results of same presented through Geographic Information Systems (GISs), visualization, etc. facilities and delivered through SMS, MMS, etc. messages; through E-Mail; through a WWW-based facility; etc. 
         [0131]      FIGS. 26   a  through  26   d  illustrate several of the exchanges or interactions that may be possible within an AIMS-based environment in connection with the processing, delivery, of an SMS message. In the figures the designation ‘MM Server’ indicates a protocol handling layer (such as element  1220  in  FIG. 12 ), the designation ‘OSGi Server’ indicates a PRS layer (such as element  1232  in  FIG. 12 ), and the designation ‘SMS MC’ indicates application logic for common Short Message Service Center (SMSC) functions. 
         [0132]      FIGS. 27   a  through  27   e  illustrate several of the exchanges or interactions that may be possible within an AIMS-based environment in connection with the processing, delivery, etc. of a MMS message. In the figures the designation ‘MM Server’ indicates a protocol handling layer (such as element  1220  in  FIG. 12 ), the designation ‘OSGi Server’ indicates a PRS layer (such as element  1232  in  FIG. 12 ), and the designation ‘MMS MC’ indicates application logic for common Multimedia Message Service Center (MMSC) functions. 
         [0133]    Various aspects of the present invention can be implemented by software, firmware, hardware, or any combination thereof.  FIG. 28  illustrates an example computer system  2800  in which the present invention, or portions thereof, (such as described above under paragraphs 47-52, paragraphs 54-60, and paragraphs 69-123) can be implemented as computer-readable code. Various embodiments of the invention are described in terms of this example computer system  2800 . After reading this description, it will become apparent to a person skilled in the relevant art how to implement the invention using other computer systems and/or computer architectures. 
         [0134]    Computer system  2800  includes one or more processors, such as processor  2804 . Processor  2804  can be a special purpose processor or a general purpose processor. Processor  2804  is connected to a communication infrastructure  2802  (for example, a bus or a network). 
         [0135]    Computer system  2800  also includes a main memory  2806 , preferably Random Access Memory (RAM), containing possibly inter alia computer software and/or data  2808 . 
         [0136]    Computer system  2800  may also include a secondary memory  2810 . Secondary memory  2810  may include, for example, a hard disk drive  2812 , a removable storage drive  2814 , a memory stick, etc. A removable storage drive  2814  may comprise a floppy disk drive, a magnetic tape drive, an optical disk drive, a flash memory, or the like. A removable storage drive  2814  reads from and/or writes to a removable storage unit  2816  in a well known manner. A removable storage unit  2816  may comprise a floppy disk, magnetic tape, optical disk, etc. which is read by and written to by removable storage drive  2814 . As will be appreciated by persons skilled in the relevant art(s) removable storage unit  2816  includes a computer usable storage medium  2818  having stored therein possibly inter alia computer software and/or data  2820 . 
         [0137]    In alternative implementations, secondary memory  2810  may include other similar means for allowing computer programs or other instructions to be loaded into computer system  2800 . Such means may include, for example, a removable storage unit  2824  and an interface  2822 . Examples of such means may include a program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as an Erasable Programmable Read-Only Memory [EPROM], or Programmable Read-Only Memory [PROM]) and associated socket, and other removable storage units  2824  and interfaces  2822  which allow software and data to be transferred from the removable storage unit  2824  to computer system  2800 . 
         [0138]    Computer system  2800  may also include an input interface  2826  and a range of input devices  2828  such as, possibly inter alia, a keyboard, a mouse, etc. 
         [0139]    Computer system  2800  may also include an output interface  2830  and a range of output devices  2832  such as, possibly inter alia, a display, one or more speakers, etc. 
         [0140]    Computer system  2800  may also include a communications interface  2834 . Communications interface  2834  allows software and/or data  2838  to be transferred between computer system  2800  and external devices. Communications interface  2834  may include a modem, a network interface (such as an Ethernet card), a communications port, a Personal Computer Memory Card International Association (PCMCIA) slot and card, or the like. Software and/or data  2838  transferred via communications interface  2834  are in the form of signals  2836  which may be electronic, electromagnetic, optical, or other signals capable of being received by communications interface  2834 . These signals  2836  are provided to communications interface  2834  via a communications path  2840 . Communications path  2840  carries signals and may be implemented using wire or cable, fiber optics, a phone line, a cellular phone link, a Radio Frequency (RF) link or other communications channels. 
         [0141]    As used in this document, the terms “computer program medium,” “computer usable medium,” and “computer readable medium” generally refer to media such as removable storage unit  2816 , removable storage unit  2824 , and a hard disk installed in hard disk drive  2812 . Signals carried over communications path  2840  can also embody the logic described herein. Computer program medium and computer usable medium can also refer to memories, such as main memory  2806  and secondary memory  2810 , which can be memory semiconductors (e.g. Dynamic Random Access Memory [DRAM] elements, etc.). These computer program products are means for providing software to computer system  2800 . 
         [0142]    Computer programs (also called computer control logic) are stored in main memory  2806  and/or secondary memory  2810 . Computer programs may also be received via communications interface  2834 . Such computer programs, when executed, enable computer system  2800  to implement the present invention as discussed herein. In particular, the computer programs, when executed, enable processor  704  to implement the processes of aspects of the present invention, such as the steps discussed above under paragraphs 47-52, paragraphs 54-60, and paragraphs 69-123. Accordingly, such computer programs represent controllers of the computer system  2800 . Where the invention is implemented using software, the software may be stored in a computer program product and loaded into computer system  2800  using removable storage drive  2814 , interface  2822 , hard drive  2812  or communications interface  2834 . 
         [0143]    The invention is also directed to computer program products comprising software stored on any computer useable medium. Such software, when executed in one or more data processing devices, causes data processing device(s) to operate as described herein. Embodiments of the invention employ any computer useable or readable medium, known now or in the future. Examples of computer useable mediums include, but are not limited to, primary storage devices (e.g., any type of random access memory), secondary storage devices (e.g., hard drives, floppy disks, Compact Disc Read-Only Memory [CD-ROM] disks, Zip disks, tapes, magnetic storage devices, optical storage devices, Microelectromechanical Systems [MEMS], nanotechnological storage device, etc.), and communication mediums (e.g., wired and wireless communications networks, local area networks, wide area networks, intranets, etc.). 
         [0144]    It is important to note that the hypothetical examples that were presented above, which were described in the narrative and which were illustrated in the accompanying figures, are exemplary only. They are not intended to be exhaustive or to limit the invention to the specific forms disclosed. It will be readily apparent to one of ordinary skill in the relevant art that numerous alternatives to the presented examples are easily possible and, indeed, are fully within the scope of the present invention. 
         [0145]    The following list defines acronyms as used in this disclosure. 
         [0000]    
       
         
               
               
             
           
               
                   
               
               
                 Acronym 
                 Meaning 
               
               
                   
               
             
             
               
                 A2P 
                 Application-to-Peer 
               
               
                 AIMS 
                 Advanced IP Messaging Server 
               
               
                 API 
                 Application Programming Interface 
               
               
                 AS 
                 Application Server 
               
               
                 CD-ROM 
                 Compact Disc Read-Only Memory 
               
               
                 CP 
                 Content Provider 
               
               
                 CRD 
                 Composite Routing Database 
               
               
                 CS 
                 Contract Scheme 
               
               
                 CSCF 
                 Call Session Control Function 
               
               
                 DBMS 
                 Database Management System 
               
               
                 DRAM 
                 Dynamic Random Access Memory 
               
               
                 DSL 
                 Digital Subscriber Line 
               
               
                 E-Mail 
                 Electronic Mail 
               
               
                 ENUM 
                 Electronic Numbering 
               
               
                 EPROM 
                 Erasable Programmable Read-Only Memory 
               
               
                 ETL 
                 Extraction-Transformation-Load 
               
               
                 GIS 
                 Geographic Information System 
               
               
                 HSS 
                 Home Subscriber Server 
               
               
                 HTTP 
                 HyperText Transfer Protocol 
               
               
                 IM 
                 Instant Messaging 
               
               
                 IMO 
                 Internal Message Object 
               
               
                 IMS 
                 IP Multimedia Subsystem 
               
               
                 IP 
                 Internet Protocol 
               
               
                 JMS 
                 Java Message Service 
               
               
                 LERG 
                 Local Exchange Routing Guide 
               
               
                 MAP 
                 Mobile Application Part 
               
               
                 MEMS 
                 Microelectromechanical Systems 
               
               
                 MG 
                 Media Gateway 
               
               
                 MH 
                 Message Highway 
               
               
                 MICV 
                 Messaging Inter-Carrier Vendor 
               
               
                 MMS 
                 Multimedia Message Service 
               
               
                 MMSC 
                 Multimedia Message Service Center 
               
               
                 MNP 
                 Mobile Number Portability 
               
               
                 MPE 
                 Message Processing Engine 
               
               
                 MRL 
                 Message Routing Language 
               
               
                 MS 
                 Mobile Subscriber 
               
               
                 MSU 
                 Message Signal Unit 
               
               
                 NPAC 
                 Number Portability Administration Center 
               
               
                 ODBMS 
                 Object Database Management System 
               
               
                 P2P 
                 Peer-to-Peer 
               
               
                 PCMCIA 
                 Personal Computer Memory Card International Association 
               
               
                 PDA 
                 Personal Digital Assistant 
               
               
                 PDU 
                 Protocol Data Unit 
               
               
                 PE 
                 Protocol Engine 
               
               
                 PLMN 
                 Public Land Mobile Network 
               
               
                 PROM 
                 Programmable Read-Only Memory 
               
               
                 PRS 
                 Processing, Routing, and Switching 
               
               
                 PS 
                 Pricing Scheme 
               
               
                 PSTN 
                 Public Switched Telephone Network 
               
               
                 RAM 
                 Random Access Memory 
               
               
                 RDBMS 
                 Relational Database Management System 
               
               
                 RF 
                 Radio Frequency 
               
               
                 RSS 
                 Really Simple Syndication 
               
               
                 RTQF 
                 Real-Time Query Facility 
               
               
                 SC 
                 Short Code 
               
               
                 SIP 
                 Session Initiation Protocol 
               
               
                 SMPP 
                 Short Message Peer-to-Peer 
               
               
                 SMS 
                 Short Message Service 
               
               
                 SMSC 
                 Short Message Service Center 
               
               
                 SMTP 
                 Simple Mail Transfer Protocol 
               
               
                 SP 
                 Service Provider 
               
               
                 SS7 
                 Signaling System Seven 
               
               
                 3P 
                 Third Party 
               
               
                 TCP 
                 Transmission Control Protocol 
               
               
                 TDR 
                 Transaction Detail Record 
               
               
                 TN 
                 Telephone Number 
               
               
                 UDP 
                 User Datagram Protocol 
               
               
                 URE 
                 Universal Rating Engine 
               
               
                 URI 
                 Uniform Resource Identifier 
               
               
                 URL 
                 Uniform Resource Locator 
               
               
                 VoIP 
                 Voice Over IP 
               
               
                 WAP 
                 Wireless Application Protocol 
               
               
                 WC 
                 Wireless Carrier 
               
               
                 WD 
                 Wireless Device 
               
               
                 WWW 
                 World-Wide Web 
               
               
                 XMPP 
                 Extensible Messaging and Presence Protocol