Systems, methods, and computer program products for automatic mapping between parlay-X short messaging service message element XML encoding and native SMPP protocol data coding scheme

Systems, methods, and computer program products are for mapping an extensible markup language (XML) encoding declarations to a short message peer-to-peer (SMPP) data coding scheme (DCS) for a mobile-terminated (MT) short messaging service (SMS). An exemplary method includes receiving a message from a short message entity (SME) for delivery to a mobile device. The message includes a payload with at least one character encoded in accordance with a first character encoding scheme. The exemplary method further includes receiving from the SME a second encoding scheme for the message, implementing a mapping table to map the first character encoding scheme to the second character encoding scheme, and performing an encoding transformation of the message from the first character encoding to the second character encoding scheme yielding a modified message comprising the payload of the message encoded in the second character encoding scheme as specified by the SME.

TECHNICAL FIELD

The present disclosure relates generally to protocol conversion and, more particularly, to systems, methods, and computer program products for automatic mapping between the Parlay-X short messaging service Extensible Markup Language (XML) encoding format for the message element and native Short Message Peer-to-Peer (SMPP) protocol data coding scheme (DCS).

BACKGROUND

Parlay-X (PX) is a set of open telecom web-service standards defined by the Parlay Group. The Parlay Group is a multi-vendor consortium formed to develop open, technology independent application programming interfaces (APIs) that enable the development of applications operating across multiple, networking-platform environments.

Parlay integrates intelligent network (IN) services with information technology (IT) applications via a secure interface that allows billing of services. By not requiring detailed knowledge of underlying code, networks and environments, Parlay open APIs enable developers to be innovative and to focus on business logic. Parlay-based portable, network-independent applications are connecting IT and telecom, generating new revenue streams for network operators, application service providers (ASPs), and independent software vendors (ISVs). The Parlay Group has released PX web-services specifications for messaging services, such as short messaging and multimedia messaging.

Short messaging typically utilizes the short message peer-to-peer (SMPP) protocol. The SMPP protocol is an open, industry standard protocol designed to simplify interconnection between various entities to exchange short messaging service (SMS) messages.

SUMMARY

According to one aspect of the present disclosure, a method for mapping an extensible markup language (XML) encoding declaration to a short message peer-to-peer (SMPP) data coding scheme (DCS) for the mobile-terminated (MT) short messaging service (SMS) includes receiving a message from a short message entity (SME) for delivery to a mobile device. The message includes a payload at least one character encoded in accordance with a first character encoding scheme. In one embodiment, the payload is the “message” element name within Parlay-X (PX) Short Messaging Service (SMS) API. The method further includes receiving from the SME a second encoding scheme for the message, implementing a mapping table to map the first character encoding scheme to the second character encoding scheme, and performing an encoding transformation of the message from the first character encoding to the second character encoding scheme yielding a modified message comprising the payload of the message encoded in the second character encoding scheme as specified by the SME.

In one embodiment, the method further includes sending the modified message to a short message service center (SMSC) for delivery to the mobile device. In this embodiment, the method may further include generating and sending a notification to the SME. The notification indicates that the modified message was delivered to the mobile device.

In one embodiment, the message is a PX sendSMS message, the first character encoding scheme for the PX SMS message element is an encoding scheme with an appropriate XML encoding declaration, and the second character encoding scheme is a short message peer-to-peer (SMPP) data coding scheme (DCS) for the message.

In one embodiment, the encoding scheme is one of a Unicode Transformation Format 8 (UTF-8), UTF-16, UCS-2, ISO-10646-UCS-2, ISO-10646-UCS-4, ISO-8859-1, ISO-8859-2, ISO-8859-9, ISO-2022-JP, Shift JIS, and EUC-JP.

In one embodiment, the message includes a multimedia component including at least one of an image, a sound, and a video.

According to another aspect of the present disclosure, bytes are passed transparently, without transformation, to the SMSC with a destination of the destination encoding scheme. For example, suppose UTF-16 is specified as the originating scheme and UCS-2 as the DCS (assuming all the characters are in the Unicode Basic Multilingual Plane (BMP); then the applicable bytes are copied into the value field of the SMPP message-payload parameter. Message decoding and display, in one embodiment, is done by an application on the mobile device that recognizes the incoming coding format based on the DCS or, alternatively, may choose to analyze the bytes to determine the real encoding scheme to use.

According to another aspect of the present disclosure, a non-transitory computer-readable medium includes instructions that, when executed by a processor, cause the processor to perform the aforementioned method.

According to another aspect of the present disclosure, a system includes a network interface, a processor, and a memory including instructions that, when executed by the processor, cause the processor to perform the aforementioned method.

DETAILED DESCRIPTION

As required, detailed embodiments of the present disclosure are disclosed herein. It must be understood that the disclosed embodiments are merely exemplary examples of the disclosure that may be embodied in various and alternative forms, and combinations thereof. As used herein, the word “exemplary” is used expansively to refer to embodiments that serve as an illustration, specimen, model or pattern. The figures are not necessarily to scale and some features may be exaggerated or minimized to show details of particular components. In other instances, well-known components, systems, materials or methods have not been described in detail in order to avoid obscuring the present disclosure. Therefore, specific structural and functional details disclosed herein are not to be interpreted as limiting, but merely as a basis for the claims and as a representative basis for teaching one skilled in the art to variously employ the present disclosure.

The systems and methods of the present disclosure may be implemented in wireless networks that use exemplary telecommunications standards, such as Global System for Mobile communications (GSM) and a Universal Mobile Telecommunications System (UMTS). It should be understood, however, that the systems and methods may be implemented in wireless networks that use any existing or yet to be developed telecommunications technology. Some examples of other suitable telecommunications technologies include, but are not limited to, networks utilizing Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Wideband Code Division Multiple Access (WCDMA), Orthogonal Frequency Division Multiplexing (OFDM), Long Term Evolution (LTE), and various other 2G, 2.5G, 3G, 4G, and greater generation technologies. Examples of suitable data bearers include, but are not limited to, General Packet Radio Service (GPRS), Enhanced Data rates for Global Evolution (EDGE), the High-Speed Packet Access (HSPA) protocol family, such as, High-Speed Downlink Packet Access (HSDPA), Enhanced Uplink (EUL) or otherwise termed High-Speed Uplink Packet Access (HSUPA), Evolved HSPA (HSPA+), and various other current and future data bearers.

Referring now to the drawings in which like numerals represent like elements throughout the several views,FIG. 1schematically illustrates a network architecture100, according to an exemplary embodiment of the present disclosure. The illustrated network architecture100includes a short message entity (SME)102, a Parlay-X (PX) gateway104, a short messaging service center (SMSC)106, a mobile device108, and a radio access network (RAN)110.

The SME102is an entity which may send or receive short messaging service (SMS) messages. The SME102may be located in a mobile network, as illustrated, a fixed network, or the SMSC106. Although a single SME is illustrated, in some embodiments, multiple SMEs are in communication with the PX gateway104. These additional SMEs may be configured like the illustrated SME102. In one embodiment, the SME102is a third party application. In one embodiment, the SME102is configured to provide short messages including information related to one or more of news, sports, technology, entertainment, politics, health, mobile applications, subscriber accounts, banking, stock market, and the like.

The PX gateway104is configured to map extensible markup language (XML) encoding declarations to short message peer-to-peer (SMPP) data coding scheme (DCS) for mobile-terminated (MT) SMS. The PX gateway104includes a network interface, a processor in communication with the network interface, and a memory in communication with the processor. In one embodiment, the memory includes instructions that, when executed by the processor, cause the processor to perform various operations, such as those described immediately below.

The PX gateway104is configured to receive a message from the SME102for delivery to the mobile device108. The message includes a payload with at least one character encoded in accordance with a first character encoding scheme. The PX gateway104is further configured to receive a second encoding scheme for the message from the SME102. The PX gateway104is further configured to implement a mapping table to map the first character encoding scheme to the second character encoding scheme. The PX gateway104is configured to perform an encoding transformation of the message from the first character encoding to the second character encoding scheme to yield a modified message including the payload of the message encoded in the second character encoding scheme as specified by the SME102. Alternatively, depending on the originating encoding scheme and the selected DCS, transformation may not be necessary or wanted. For example, if an encoding scheme of GP 18030 is specified and a DCS of “Reserved” is used, then it may be that the PX gateway104copies the message byte-for-byte, allowing an application operating on the mobile device to properly handle the message. The PX gateway104and the components thereof are illustrated and described in detail below with reference toFIG. 5.

The SMSC106is an entity configured to receive, store, and forward SMS messages to a destination entity, such as the mobile device108.

The mobile device108is configured to communicate with the SMSC106via the RAN110to send/receive SMS messages. In accordance with aspects of the present disclosure, the mobile device108receives SMS messages originating from the SME102and/or other SMEs (not illustrated). The mobile device108and components thereof are described in detail below with reference toFIG. 6.

The RAN110includes at least one radio communications component, such as a base transceiver station (BTS) or Node-b in GSM and UMTS network types, respectively. The BTS/Node-b functions as the terminating node for the radio interface in the illustrated RAN110. Each BTS/Node-b includes one or more transceivers and is responsible for providing the radio/air interface to the mobile device108.

Each radio communications component is in communication with a controller component, such as a base station controller (BSC) or radio network controller (RNC) in GSM and UMTS network types, respectively. Typically, a BSC/RNC has tens or even hundreds of BTSs/Node-bs under its control. The BSC/RNC is configured to allocate radio resources to mobile devices (e.g., the mobile device108), administer frequencies, and control handovers between BTSs/Node-bs, except in the case of an inter-mobile switching center (MSC) handover, in which case control is in part the responsibility of the MSC. One function of the controller component is to act as a concentrator, so that many different low capacity connections to the radio communications component become reduced to a smaller number of connections towards the MSC. Generally, this means that networks are often structured to have many BSCs/RNCs distributed into regions near the BTSs/Node-bs and connected to large centralized MSC sites. In some embodiments, a controller component and a radio communications component are combined.

Although the RAN110has been generally described in context of a GSM/UMTS network environment. The RAN110may alternatively or additionally include components for operating using other network technologies, such as the exemplary network technologies described herein above.

It should be noted that the illustrated network architecture100does not illustrate certain core network components, such as MSCs, GPRS support nodes, location registers, and the like, so as not to obscure the novel aspects of the present disclosure. These and other components are contemplated as being in communication with one or more of the illustrated components in implementation.

Referring now toFIG. 2, a message flow diagram200for a mobile-terminated message is illustrated, according to an exemplary embodiment of the present disclosure. The illustrated message flow provides no delivery receipt to the sending entity (e.g., the SME102). A message flow that provides a delivery receipt is illustrated and described with reference toFIG. 3.

The message flow assumes that the SME102has generated a message including a payload that is encoded in a first character encoding scheme. The message flow begins, at step202, whereat the SME102specifies a second character encoding scheme for the payload of the message generated by the SME102. In one embodiment, the SME102specifies a specific encoding scheme with deterministic results using the same client application (i.e., the SME application calling the PX API) identification rather than, as is presently done, using different client application identifications for different statically provisioned encoding schemes. It should be noted that today, different API specifications (Web Services WSDLs) and services (the server executable) would have to be used on a PX gateway to accommodate different encoding scheme to DCS translations. To use the different PX APIs, the SME would have to use different applications. The disclosed systems and methods eliminate the need to create different APIs for each transformation or mapping.

At step204, the SME102sends a sendSMS PX message to the PX gateway104. The sendSMS message includes the second encoding scheme specified by the SME102. At step206, the PX gateway104performs an encoding transformation using a mapping table stored in the PX gateway104to map the payload encoded in the first character encoding scheme to the second character encoding scheme as specified by the SME102.

In one embodiment, the mapping table includes XML encoding declarations each of which is mapped to an SMPP data coding schemes. An exemplary mapping table is illustrated below.

After the PX gateway104transforms the message payload from the first character encoding scheme to the second character encoding scheme, the PX gateway104generates an SMPP message including the transformed payload. The payload, in an alternative embodiment is a byte-for-byte copy of the message payload. In this embodiment, transformations are internally defined. This embodiment is most applicable to an instance wherein the mobile device would be expected to know the transformation for a specific “Reserved” DCS value.

In one embodiment, the SMPP message is a submit_sm message including text of the message payload encoded in the second character encoding scheme. In another embodiment, the SMPP message is a submit_multi message including text of the message payload encoded in the second character encoding scheme and a multimedia component. The multimedia component includes, for example, an image, a video, and/or a sound.

At step208, the PX gateway104sends the submit_sm/submit_multi message to the SMSC106. At step210, the PX gateway104receives a submit_sm_resp or submit_multi_resp from the SMSC106in response to the submit_sm or submit_multi, respectively. At step212, the SMSC106sends the message to the mobile device108. At step214, the PX gateway104sends a sendSMS_resp PX message to the SME102. The message flow ends.

Referring now toFIG. 3, a message flow diagram300for a mobile-terminated message is illustrated, according to another exemplary embodiment of the present disclosure. The illustrated message flow provides a delivery receipt to the sending entity (e.g., the SME102). A message flow that does not provide a delivery receipt is illustrated and described with reference toFIG. 2.

The message flow assumes that the SME102has generated a message including a payload that is encoded in a first character encoding scheme. The message flow begins, at step302, whereat the SME102specifies a second character encoding scheme for the payload of the message generated by the SME102. In one embodiment, the SME102can specify a specific encoding scheme with deterministic results using the same client application identification rather than, as is presently done, using different client application identifications for different statically provisioned encoding schemes.

At step304, the SME102sends a sendSMS PX message to the PX gateway104. The sendSMS message includes the second encoding scheme specified by the SME102. At step306, the PX gateway104performs an encoding transformation using a mapping table stored in the PX gateway104to map the payload encoded in the first character encoding scheme to the second character encoding scheme as specified by the SME102. In one embodiment, the mapping table includes XML encoding declarations each of which is mapped to an SMPP data coding schemes. An exemplary mapping table is illustrated above in TABLE 2.

After the PX gateway104transforms the message payload from the first character encoding scheme to the second character encoding scheme, the PX gateway104generates an SMPP message including the transformed payload. In one embodiment, the SMPP message is a submit_sm message including text of the message payload encoded in the second character encoding scheme. In another embodiment, the SMPP message is a submit_multi message including text of the message payload encoded in the second character encoding scheme and a multimedia component. The multimedia component includes, for example, an image, a video, and/or a sound.

It should be noted that when a multimedia component is included, the PX interface is the PX multimedia API rather than the PX SMS API due to size limitations in the SMS message (i.e., 160 7-bit characters; 140 8-bit characters), although it is possible to concatenate up to five SMS messages together to form a single, long message.

At step308, the PX gateway104sends the submit_sm/submit_multi message to the SMSC106. At step310, the PX gateway104receives a submit_sm_resp or submit_multi_resp from the SMSC106in response to the submit_sm or submit_multi, respectively. At step312, the SMSC106sends the message to the mobile device108. At step314, the PX gateway104sends a sendSMS_resp PX message to the SME102.

At step316, the mobile device108responds to the message delivery with a delivery confirmation to the SMSC106. At step318, the SMSC106sends an SMPP deliver_sm message to the PX gateway104to notify the PX gateway104of successful delivery. Alternatively, the SMSC106may notify the PX gateway104of failed delivery if this is the case.

At step320, the PX gateway104sends a PX NotifySmsDeliveryReceipt to the SME106to notify the SME102of successful delivery. At step322, the SME102responds to the PX NotifySmsDeliveryReceipt with a PX NotifySmsDeliveryReceipt return message to confirm receipt of the delivery notification. Alternatively, the PX gateway104may notify the SME102of failed delivery if this is the case.

At step324, the PX gateway104sends an SMPP deliver_sm_resp to the SMSC106confirm receipt of the deliver_sm message and, in the illustrated embodiment, to confirm the sending entity (i.e., the SME102) has received the delivery confirmation. The message flow ends.

Referring now toFIG. 4, a method400for mapping XML encoding declarations to SMPP DCS for MT SMS is illustrated, according to an exemplary embodiment of the present disclosure. It should be understood that the steps of the method400are not necessarily presented in any particular order and that performance of some or all the steps in an alternative order is possible and is contemplated. The steps have been presented in the demonstrated order for ease of description and illustration. Steps can be added, omitted and/or performed simultaneously without departing from the scope of the appended claims. It should also be understood that the illustrated method400can be ended at any time. In certain embodiments, some or all steps of this process, and/or substantially equivalent steps can be performed by execution of computer-readable instructions stored or included on a computer-readable medium.

The method400begins and flow is to block402, whereat an SME, such as the SME102, generates a message with a payload encoded in a first character encoding scheme. At block404, the SME specifies a second character encoding scheme for the message payload. At block406, the SME sends the message and the second character encoding scheme to a gateway, such as the PX gateway104.

At step408, the gateway implements a mapping table to map the first character encoding scheme to the second character encoding scheme. At step410, the gateway performs an encoding transformation of the message from the first character encoding scheme to the second character encoding scheme yielding a modified message including the message payload encoded in the second character encoding scheme. At block412, the gateway sends the modified message to an SMSC, such as the SMSC106, for delivery to a mobile device, such as the mobile device108. The method400ends.

Referring now toFIG. 5, the PX gateway104and components thereof are illustrated, according to an embodiment of the present disclosure. Although connections are not shown between all components illustrated inFIG. 2, the components can interact with each other to carry out various system functions described herein. It should be understood thatFIG. 2and the following description are intended to provide a general description of a suitable environment in which the various aspects of some embodiments of the present disclosure can be implemented.

The PX gateway104includes a network interface502for facilitating communications between the PX gateway104and other systems504such as the short message entity (SME)102, the short message service center (SMSC)106, and other systems or components of the network architecture100. The PX gateway104also includes one or more processors506that are in communication with one or more memory modules508via one or more memory/data busses510. The memory module(s)508is configured to store a mapping table512and other data514. The mapping table512includes XML encoding declaration to SMPP DCS mappings, for example, as illustrated above in Table A.

The other data514may include instructions that, when executed by the processor(s)506, cause the processor(s)506to, among other operations, perform an encoding transformation of a message payload received from an SME (e.g., the SME102) from a first character encoding scheme (e.g., an XML-compatible character encoding) and a second character encoding scheme (e.g., an SMPP DCS) to yield a modified message including the message payload encoded in the second character encoding scheme.

The term “memory,” as used herein to describe the memory module(s)508, collectively includes all memory types associated with the PX gateway104such as, but not limited to, processor registers, processor cache, random access memory (RAM), other volatile memory forms, and non-volatile, semi-permanent or permanent memory types; for example, tape-based media, tangible optical media, solid state media, hard disks, combinations thereof, and the like. While the memory module(s)508is illustrated as residing proximate the processor(s)506, it should be understood that the memory module(s)508is in some embodiments a remotely accessible storage system. Moreover, the memory module(s)508is intended to encompass network memory and/or other storage devices in wired or wireless communication with the PX gateway104.

Referring now toFIG. 6, a schematic block diagram of an exemplary mobile device600is illustrated. Although connections are not shown between the components illustrated inFIG. 6, the components can interact with each other to carry out device functions. In some embodiments, for example, the components are arranged so as to communicate via one or more busses (not shown). It should be understood thatFIG. 6and the following description are intended to provide a general understanding of a suitable environment in which various aspects of embodiments of the present disclosure can be implemented.

In some embodiments, the mobile device108illustrated inFIGS. 1-3is configured like the mobile device600described with reference toFIG. 6. In some embodiments, the mobile device600is a multimode headset configured to provide access to more than one network type including, for example, the telecommunications technologies described above and/or other technologies such as Wi-Fi™ and WiMAX™.

In some embodiments, the mobile device600includes computer-readable media, including, for example, volatile media, non-volatile media, removable media, and non-removable media. The term “computer-readable media” and variants thereof, as used herein, refer to storage media and communication media. In some embodiments, storage media includes volatile and/or non-volatile, removable, and/or non-removable media. For example, storage media includes random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), solid state memory or other memory technology, CD ROM, DVD, or other optical disk storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other tangible, non-transitory medium that can be used to store the desired information and that can be accessed by the mobile device600.

The illustrated mobile device600also includes a processor604for processing data and/or executing computer-executable instructions of one or more applications608stored in a memory606. In some embodiments, the application(s)606include a user interface (UI) application610. The UI application610interfaces with a client612(e.g., an operating system (OS)) to facilitate user interaction with device functionality and data. In some embodiments, the client612is one of Symbian OS, Microsoft® Windows® Mobile OS (available from Microsoft Corporation of Redmond, Wash.), Palm® webOS™ (available from Palm Corporation of Sunnyvale, Calif.), Palm® OS (available from Palm Corporation), RIM® BlackBerry® OS (available from Research In Motion Limited of Waterloo, Ontario, Canada), Apple® iPhone® OS (available from Apple Corporation of Cupertino, Calif.), or Google Android™ OS (available from Google Inc. of Mountain View, Calif.). These operating systems are merely exemplary of the operating systems that may be used in accordance with the embodiments disclosed herein.

The UI application610aids a user in activating service OTA, if applicable, entering message content, viewing received messages (e.g., MMS messages, SMS messages, USSD messages, OTA messages), answering/initiating calls, entering/deleting data, entering and setting user IDs and passwords for device access, configuring settings, manipulating address book content and/or settings, multimode interaction, interacting with other applications614, and the like.

In one embodiment, the other applications614include an application that recognizes an incoming coding format based on the DCS. The application, in an alternative embodiment, chooses to analyze the bytes to determine the real encoding scheme to use.

In some embodiments, the other applications614include, for example, visual voicemail applications, messaging applications (e.g., SMS, enhanced messaging service (EMS), MMS applications), presence applications, text-to-speech applications, speech-to-text applications, add-ons, plug-ins, email applications, music applications, video applications, camera applications, location service applications (LSAs), power conservation applications, game applications, productivity applications, entertainment applications, enterprise applications, combinations thereof, and the like. The applications608are stored in the memory606and/or in a firmware616, and are executed by the processor604. The firmware616may also store code for execution during device power up and power down operations.

The illustrated mobile device600also includes an input/output (I/O) interface618for input/output of data, such as, for example, location information, presence status information, user IDs, passwords, and application initiation (start-up) requests. In some embodiments, the I/O interface618is a hardwire connection, such as, for example, a USB, mini-USB, audio jack, PS2, IEEE 1394, serial, parallel, Ethernet (RJ48) port, RJ11 port, or the like. In some embodiments, the I/O interface618accepts other I/O devices such as, for example, keyboards, keypads, mice, interface tethers, stylus pens, printers, thumb drives, touch screens, multi-touch screens, touch pads, trackballs, joysticks, microphones, remote control devices, monitors, displays, liquid crystal displays (LCDs), combinations thereof, and the like. It should be appreciated that the I/O interface618may be used for communications between the mobile device600and a network device or local device, instead of, or in addition to, a communications component620.

The communications component620interfaces with the processor604to facilitate wired/wireless communications with external systems. Example external systems include, but are not limited to, SMSCs, intranets, network databases, network storage systems, cellular networks, location servers, presence servers, Voice over Internet Protocol (VoIP) networks, local area networks (LANs), wide area networks (WANs), metropolitan area networks (MANs), personal area networks (PANs), and other networks, network components, and systems described herein. In some embodiments, the external systems are implemented using Wi-Fi™, WiMAX™, combinations and/or improvements thereof, and the like. In some embodiments, the communications component620includes a multimode communications subsystem for providing cellular communications via different cellular technologies. In some embodiments, for example, a first cellular transceiver622operates in one mode, such as, GSM, and an Nth cellular transceiver624operates in a different mode, such as UMTS. While only two cellular transceivers622,624are illustrated, it should be appreciated that a plurality of transceivers can be included.

The illustrated communications component620also includes an alternative communications transceiver626for use by other communications technologies such as, for example, Wi-Fi™, Wi-Max™, BLUETOOTH, infrared, infrared data association (IRDA), near field communications (NFC), RF, and the like. In some embodiments, the communications component620also facilitates reception from terrestrial radio networks, digital satellite radio networks, Internet-based radio services networks, combinations thereof, and the like.

The communications component620processes data from a network such as, for example, the Internet, an intranet (e.g., business intranet), a home broadband network, a Wi-Fi™ hotspot, and the like, via an Internet service provider (ISP), digital subscriber link (DSL) provider, or broadband provider. In some embodiments, the communications component620facilitates the transmission of authentication information from the mobile device600to a network for processing in accordance with the methods described herein.

The illustrated mobile device600also includes a SIM slot interface628for accommodating a SIM630such as, for example, a SIM card, a universal SIM (USIM) card, or a universal integrated circuit card (UICC) including one or more SIM applications (e.g., ISIM, SIM, USIM, CSIM). The SIM630is configured to store an international mobile subscriber identity (IMSI). The mobile device600can only be operated if the SIM630includes a valid IMSI and is inserted into the SIM slot interface628of the mobile device600with a valid IMEI.

Audio capabilities for the mobile device600may be provided by an audio I/O component632that includes a speaker for the output of audio signals and a microphone to collect audio signals.

The mobile device600may also include an image capture and processing system634(image system). Photos may be obtained via an associated image capture subsystem of the image system634, for example, a camera. The mobile device600may also include a video system636for capturing, processing, recording, modifying, and/or transmitting video content. Photos and videos obtained using the image system634and the video system636, respectively, may be added as message content to an MMS message and sent to another mobile device.

The illustrated mobile device600also includes a location component638for sending and/or receiving signals such as, for example, GPS data, assisted GPS (A-GPS) data, Wi-Fi™/Wi-Max™ and/or cellular network triangulation data, combinations thereof, and the like, for determining a location of the mobile device600. The location component638may communicate with the communications component620to retrieve triangulation data for determining a location. In some embodiments, the location component638interfaces with cellular network nodes, telephone lines, satellites, location transmitters and/or beacons, wireless network transmitters and receivers, for example, Wi-Fi™ hotspots, radio transmitters, combinations thereof, and the like. Using the location component638, the mobile device600obtains, generates, and/or receives data to identify its location, or transmits data used by other devices to determine the location of the mobile device600.

The illustrated mobile device600also includes a power source640, such as batteries and/or other power subsystem (AC or DC). The power source640may interface with an external power system or charging equipment via a power I/O component642.

While the processes or methods described herein may, at times, be described in a general context of computer-executable instructions, the methods, procedures, and processes of the present disclosure can also be implemented in combination with other program modules and/or as a combination of hardware and software. The term application, or variants thereof, is used expansively herein to include routines, program modules, programs, components, data structures, algorithms, and the like. Applications can be implemented on various system configurations, including servers, network systems, single-processor or multiprocessor systems, minicomputers, mainframe computers, personal computers, hand-held computing devices, mobile devices, microprocessor-based consumer electronics, programmable electronics, network elements, gateways, network functions, devices, combinations thereof, and the like.

The disclosed embodiments are merely examples that may be embodied in various and alternative forms, and combinations thereof. As used herein, for example, “exemplary,” and similar terms, refer expansively to embodiments that serve as an illustration, specimen, model or pattern. The figures are not necessarily to scale and some features may be exaggerated or minimized, such as to show details of particular components. In some instances, well-known components, systems, materials or methods have not been described in detail in order to avoid obscuring the systems, methods, and computer program products of the present disclosure. Therefore, specific structural and functional details disclosed herein are not to be interpreted as limiting, but merely as a basis for the claims and as a representative basis for teaching one skilled in the art.

The law does not require and it is economically prohibitive to illustrate and teach every possible embodiment of the present claims. Hence, the above-described embodiments are merely exemplary illustrations of implementations set forth for a clear understanding of the principles of the disclosure. Variations, modifications, and combinations may be made to the above-described embodiments without departing from the scope of the claims. All such variations, modifications, and combinations are included herein by the scope of this disclosure and the following claims.