Methods and apparatus of context-data acquisition and ranking

Disclosed are a system, method, and article of manufacture of a context-data acquisition and ranking. A context-data type is determined from a query. At least one context-data source that provides the context-data type is identified. A request for a context data of the context-data type is generated from the at least one context data source. A received context data from the at least one context data source according a specified parameter may be ranked. The received context data may be provided to the device that generated a short message. The received context data may be provided to a recipient mobile device. The received context data may be associated with a component of a short message generated by a device that generated the query. The received context data may be appended to the short message.

FIELD OF TECHNOLOGY

This disclosure relates generally to a short-message communication system, and, more particularly, to a system, methods and an article of manufacture of context-data acquisition and ranking.

BACKGROUND

Various forms of short messaging are currently used to communicate with mobile devices. For example, Short Message Service (SMS) messaging is a form of communication supported by most mobile telephone service providers and widely available on various networks including Global System for Mobile Communications (GSM), Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), third generation (3G) networks, and fourth generation (4G) networks. Versions of SMS messaging are described in GSM specifications such as GSM specification 03.40 “Digital cellular telecommunications system (Phase 2+); Technical realization of the Short Message Service” and GSM specification 03.38 “Digital cellular telecommunication system (Phase 2+); Alphabets and language-specific information.”

In general, SMS messages from a sender terminal are transmitted to a Short Message Service Center (SMSC), which provides a store-and-forward mechanism for delivering the SMS message to one or more recipient terminals. Successful SMS message arrival may be announced by a vibration and/or a visual indication at the recipient terminal. In some cases, the SMS message may typically contain an SMS header including the message source (e.g., telephone number, message center, or e-mail address) and a payload containing the text portion of the message. Generally, the payload of each SMS message is limited by the supporting network infrastructure and communication protocol to no more than 140 bytes which translates to 160 7-bit characters based on a default 128-character set defined in GSM specification 03.38, 140 8-bit characters, or 70 16-bit characters for languages such as Arabic, Chinese, Japanese, Korean, and other double-byte languages.

Due to payload limitations, a long message having more than 140 bytes or 160 7-bit characters may be delivered as separate SMS messages. In some cases, the SMS infrastructure may support concatenation allowing a long message to be sent and received as multiple concatenated SMS messages. In such cases, the payload of each concatenated SMS message is limited to 140 bytes but also includes a user data header (UDH) prior to the text portion of the message. The UDH contains segmentation information for allowing the recipient terminal to reassemble the multiple concatenated SMS messages into a single long message. In addition to alphanumeric characters, the text content of an SMS message may contain iconic characters (e.g. smiley characters) made up of a combination of standard punctuation marks such as a colon, dash, and open bracket for a smile.

Enhanced Messaging Service (EMS) is an application level extension to SMS described in the 3rd Generation Partnership Project (3GPP) Technical Specification (TS) 23.040 V6.7.0 (2006-03), “Technical realization of the Short Message Service.” EMS extends the use of the UDH to include binary data which allows EMS-enabled terminals to send and receive text messages having simple media content such as text formatting, predefined icons, pictures, and sounds. EMS messaging is supported by the SMS infrastructure and constrained by SMS payload limits. As such, several concatenated short messages are typically required for EMS messaging since usually only one picture or sound can be sent in a single short message. If an EMS message is received by a non-enabled terminal, unreadable data will be overwritten and the message will be displayed as a normal SMS message.

Multimedia Messaging (MMS) technology provides capabilities beyond those of SMS and allows terminals to send and receive multimedia messages including graphics, video and audio clips. Unlike SMS, which depends primarily on the underlying wireless network technology (e.g. GSM, CDMA, TDMA), MMS relies on Internet Protocol (IP) technology and is designed to work with mobile packet data services such as General Packet Radio Service (GPRS) and Evolution Data Only/Evolution Data Optimized (EV-DO).

A mobile device may include a short messaging application such as SMS, EMS, MMS and the like. A user may compose and send short messages with the short messaging application. Portions of the short messages may be related to a mobile device's context such as its physical environment. Knowledge of this context may be useful to a receiver when reviewing the short message. For example, without the context data, the receiver may not understand ambiguities in the short message. The receiver may need to query the sending user with additional questions (e.g. other text messages, cell phone calls, etc.) to clarify the meaning of the short message. Accordingly, there may be a need to enrich a short message with context data.

SUMMARY

A system, methods, and article of manufacture of context-data acquisition and ranking. In one aspect, a context-data type is determined from a query. At least one context-data source that provides the context-data type is identified. A request for a context data of the context-data type is generated from the at least one context data source. A received context data from the at least one context data source may be ranked according a specified parameter. The received context data may be provided to the device that generated a short message. The received context data may be provided to a recipient mobile device. The received context data may be associated with a component of a short message generated by a device that generated the query. The received context data may be appended to the short message.

In another aspect, a set of context-data is collected from at least one context-data provider. The context-data is related to a short message content. A relevant context data is selected according to a metric. The relevant context data is linked to the short message. The relevant context data and the short message are formatted according to a communication protocol.

DETAILED DESCRIPTION

Disclosed are a system, methods, and article of manufacture of context data acquisition and ranking. Although the present embodiments have been described with reference to specific example embodiments, it will be evident that various modifications and changes can be made to these embodiments without departing from the broader spirit and scope of the various claims.

A. Environment And Architecture

FIG. 1is a diagram illustrating an environment in which one or more embodiments can be implemented. The environment includes a context-data system100, network service provider(s)106, a context-enriched messaging application108and/or receiving short-message application110. Context-data system100can further include context-data acquisition component102and/or context data provider1044. It will be appreciated that, in some embodiments, all the elements ofFIG. 1need not be arranged as shown, not all elements are required and that other elements can be added to, or replace, those shown. For example, some elements shown as a singular element inFIG. 1may be extant as a plurality in other embodiments. In some embodiments, the operations of context-data system100can be performed by and/or be distributed between one or more entities. Furthermore, in some embodiments, a receiving mobile device may include another context-enriched messaging application108instead of or in addition to receiving short-message application110.

Context-data system100can include a context-data provider104. Context-data provider104can be arranged to provide context data to a mobile-device application such as context-enriched messaging application108and/or short-message application. In some embodiments, context-data provider104can be arranged to receive a query from a mobile device (e.g. a smart phone, portable digital assistant, tablet computer, cellular telephone and the like). The query can include a request for a context data related to the context of the mobile device and/or relevant to a component of a short message generated by the context-enriched messaging application108.

In some embodiments, the query can include a component of a short message generated with the mobile device. Context-data provider104can then be arranged to analyze the short message component to determine the relevant type context data. Relevancy between a context data and short-message component can be determined in a variety of manners. For example, a table can be used to match a particular word and/or phrase of a short message with a predetermined context-data type. In another example one or more pattern recognition algorithms can be used to determine the meaning of a word and/or phrase. The context-data type can then be selected according to the meaning of the word and/or phrase. Suitable types of pattern recognition algorithms can include neural networks, support vector machines, decision trees, K-nearest neighbor, Bayesian networks, Monte Carlo methods, bootstrapping methods, boosting methods, or any combination thereof.

Context-data provider104can be arranged to acquire context data from context-data acquisition component102. Furthermore, in some embodiments, context-data provider104can be arranged to analyze the context data to determine a context-enhancement data (e.g. data that further describes the context data, media that enriches a user's experience of the context data, and so forth). In some embodiments, context-data provider104can provide the context data and /or the context enhancement data to context-enriched messaging application108and/or short-message application110.

Context-data acquisition component102can include devices, functionalities and systems arranged to acquire context data. For example, context-data acquisition component102can include native and remote sensors. Example sensors include, inter alia, global positioning system systems, accelerometers, inclinometers, position sensors (compass, magnetometer), barometers, WiFi sensors, RFID sensors, near-filed communication (NFC) devices, gyroscopes, pressure sensors, pressure gauges, time pressure gauges, torque sensors, ohmmeters, thermometers, infrared sensors, microphones, image sensors (e.g. digital cameras), biosensors (e.g. photometric biosensors, electrochemical biosensors), capacitance sensors, radio antennas, biometric sensors, capacitance probes, medical-device sensors and for any combination thereof. In at least one example embodiment, context-data acquisition component102can include a smart device or a network of related smart devices. It should also be noted that the other sensor devices other than those listed can also be utilized to ‘sense’ context data. A remote sensor can also include a processor, power source and/or networking interface.

It should be noted that in some embodiments, a remote sensor can be integrated into another mobile device. For example, context-data provider104can be arranged to implement a functionality that determines the location of other mobile devices registered with the system from geo-location data provided by the mobiles devices, other sensors in the system, and/or other geolocation operations. A database of available sensors in each mobile device can also be maintained. Thus, the other mobile devices can be used to acquire context data. In certain embodiments, the database can include other mobile device attributes and/or user attributes such as power supply availability, cellular service provider information, user-demographic information, user state, user-behavior patterns (such as social networking behavior) and the like. Context-data provider104can then use the database to query the mobile device for sensor data (such as context data) and/or other information relevant to generating a context data for the querying context-enriched messaging application108and/or other mobile device application or utility. In some embodiments, mobile devices in the system can be arranged to periodically upload certain sensor data and/or other pertinent metadata to the database. Thus, in some embodiments, the database can be queried to acquire context data.

In some embodiments, context data can be derived from virtual sensors that measure an attribute of a virtual environment (e.g. a video game environment, a virtual world such as Second Life™) in addition to physical sensors that measure attributes of the physical environment of the mobile device and/or attributes of physical entities (e.g. a user state, a computer state).

In some embodiments, context-data acquisition component102can include a wireless sensor network (WSN) and/or a virtual sensor network (VSN). For example, a WSN can be implemented as a network of distributed autonomous sensors that cooperatively monitor physical or environmental conditions, such as temperature, sound, vibration, pressure, motion or pollutants. In another example, a VSN can involve dynamically varying subset of remote sensors. In such a case, remote sensors can detect how a phenomenon changes with time as the phenomenon migrates.

In other embodiments, context-data system100can be included in a context-data aggregator (not shown) that includes servers arranged to aggregate context-data and/or other relevant data from one or more context-data acquisition components. A context-data aggregator can provide an intermediary context-data database available for context-data provider104.

In some embodiments, context-data system100can be arranged to interface with network service providers106. Network service providers106network one or more computers, sensors and/or mobile devices (e.g. the Internet, a wide area network, a telecommunicate ions network, a cellular network, and the like). Example, network service providers106can include internet service providers (ISPs), cellular network providers (e.g. AT&T®, Verizon®, and so forth) and/or local area network providers (that communicatively couples context-data acquisition component102with context data provider104).

Context-enriched messaging application108can reside in a computer such as a mobile device. Context-enriched messaging application108can be arranged to context enrich short messages (e.g. SMS, EMS, MMS, proprietary application-generated messages and the like) with context data. Short messages can be received from a short-message application110. Short messages can be context enriched by associating components of the short message (e.g. a word, phrase, media image) with one or more context data. It will be appreciated that various methods can be utilized to associate the context data with the short message. Example methods include, inter alia, hyperlinks, appending context data to the short message, encoding the context data into the short message with a markup language, providing a network address to a server where the context data can be acquired, explicit textual references, graphical elements and the like. In some embodiments, receiving short message application also can be arranged to format a context-enriched short message for presentation with a graphical user interface (GUI) of a receiving mobile device. It should also be noted, that a context-enriched messaging application108can reside on both a sending and a receiving mobile device.

Typically, short message application110can include, for example, an instant-messaging (IM) application, an e-mail application, an SMS application, an EMS application and an MMS application (e.g. context-enriched messaging application406described infra), and the like. In other embodiments, context-data provider104and/or context-enriched messaging application108can also be arranged to format the context-enriched short message for presentation with a GUI if short message application110does not include such a context-enriched short message formatting functionality. In some embodiments, a receiving device can include context-enriched messaging application108as well. However, it should be noted that it is not necessary for a receiving device to include context-enriched messaging application108in order to receive and display the short message and/or context data. A short-message application110can reside on both a sending and a receiving mobile device.

FIG. 2is a diagram functionally illustrating an example context-data provider104, according to one or more embodiments. Query manager200can be arranged to manage an incoming query message for context data. Query manager200can be arranged to parse an incoming query message and/or short message. In some embodiments, query manager200can be arranged to format incoming queries and/or short messages for analysis by the other modules ofFIG. 2.

If the query includes a short message, message analyzer202can be arranged to analyze the short message to determine components of the short message to associate with certain context-data types. For example, certain words, phrases and/or media types of the short message can associated (e.g. indexed) with a certain context-data type.

In another example, a user of a device that generated the short message can have indicated a specified context-data type to associate with a specified short message component. In yet another example, the query can include a request to acquire one or more context-data types and not include a short message or short message component.

Sensor manager204can be arranged to acquire context data from available context-data sources according to the specified context-data types from the query manager and/or the message analyzer202. For example, sensor manager204can communicate a request to a context-data acquisition component102to obtain and return a context-data. In one example, sensor manager204can first query database212for a context-data that has been obtained within a certain period. Sensor manager204can also store context data in database206with a time stamp. Additionally, sensor manager204can be arranged to acquire context-data from third party servers (e.g. a context-data aggregator).

Context-data ranking engine206can be arranged to rank context data. For example, context-data ranking engine206can determine a ranking value associated with each acquired context data according to a specified parameter. The context data can then be ranked according to the ranking values. Example parameters include recency of context-data acquisition, cost of context data as determined by a context-data acquisition component102, accuracy of context data, proximity of context data source to a relevant device (e.g. a sending mobile device), bidding offers by context-data acquisition component(s)s102and/or any combination thereof.

Enriched-message manager208can be arranged to format and communicate context data and/or context-enriched short messages to a mobile device. Example mobile devices can include a mobile device that generated the query and/or a mobile device that is the addressed recipient of the original short message. In some embodiments, enriched-message manager208can generate a different type of message for each receiving mobile device. Enriched-message manager208can select context data according to the ranked list provided by context-data ranking engine206. It should be noted that in some embodiments, enriched-message manager208can be modified and included in a mobile device (e.g. a mobile device that sends and/or receives context-enriched short messages).

In some embodiments, context-enhancement component210can be arranged to analyze a context data selected for a query response and/or a context-enriched message. Context-enhancement component210can determine, acquire and associate context-enhancement data with the context data. Context-enhancement component210can include a database and/or Internet search engine. Context-enhancement can be data acquired from third party services that further explain and/or elaborate on the context data. For example, if the context data is a geolocation data then context-enhancement data can include a web page document from a web mapping service application (such a Google Maps®).

Billing component210can be arranged to perform billing-related functions. Users of context-data provider104and/or context-data acquisition component102services can be billed for the acquisition of context data. Billing component210can generate and digitally communicate invoices. The data required for, or obtained by, billing component210can be stored in database212. In some embodiments, billing component210can manage an online money transfer service that allows end user to purchase context data from context-data acquisition component(s)102.

Database212can be arranged to include a variety of data used by context-data system100and more particularly, by context-data provider104. Database212can include information such as a list of context-data acquisition components112, a network address of context-data acquisition components112, current context data, historical context data, specified parameters associated with certain types of context data, specified parameters associated with certain registered mobile devices, specified parameters associated with certain context-enriched messaging applications108, specified parameters associate with certain short message applications110, historical context-data bidding information, context-data acquisition component registers (including location and state information), bidding information, user information, information used to locate a mobile device and/or an application residing in a mobile device (e.g. an IP address, short codes, SMS address information), query data, short message data and the like. Multiple databases can be employed for gathering and storing information used in context-data system100.

In some embodiments, bidding manager214can be arranged to manage context-data transactions between a context-data acquisition component102and a context-enriched messaging application106. In some embodiments, one or more context-data acquisition components102can provide context data to context-data provider104. Context-enriched message application108can purchase the context data from the bidding manager214.

In some embodiments, bidding manager214can be arranged to allow a context-data acquisition source(s)102to set and/or reset a cost of acquiring a particular context-data. Bidding manager214can also provide information about the cost of the particular context data to an end user of a context-enriched messaging application108that provided the query. In some embodiments, the end user can then select a context data and be charge the cost of the context data. In some embodiments, bidding manager214can facilitate a counter offer for the particular context data from the end user. In some embodiments, bidding manager214can facilitate various other online bidding business models such as an online auction business model. In some embodiments, advertisements can be included in a context-enriched short message in order to offset the cost of the context data. For example, such advertisements can be provided by third parties and displayed in a context-enriched short message on a receiving device. An advertising third party can then pay all or a portion of the cost of the context data. In some embodiments, enriched message manager208can include a functionality for integrating advertisements into either a content data returned to a query originator and/or a context-enriched text message forwarded to a receiving device.

In some embodiments, bidding information can be communicated through short messages between the various parties involved. Alternatively or additionally, bidding manager214can manage a website that provides context-data cost information as well as facilitates bidding.

Statistics engine216can be arranged to include information pertaining to the selection of context data and/or performance of context-data acquisition components102. Statistics engine216can log statistics in database212. Sensor manager204can use information acquired by statistics engine to streamline context-data acquisition operations. For example, sensor manager204can focus requests for context-data on more reliable context-data acquisition components102and/or context-data acquisition components102that provide data at a lower cost. In some embodiments, data generated by statistics engine216can be included in a short message as context-enhancement data.

Network interfaces218is a component that interfaces with various communications networks such as cellular networks, IP networks (e.g. the Internet), local area networks (LAN), private wide area networks (WAN), a network using an open wireless technology standard for exchanging data over short distances (using short length radio waves) from fixed and mobile devices and/or any combination thereof.

In one example, a mobile device can generate a short message that reads “I am here”. The short message may be communicated by the sending mobile device and/or a short message service provider to the context-data provider104. Message analyzer202can determine that short message component “here” is to be associated with the context-data type of geolocation data of a mobile device that generated the short message. Accordingly, sensor manager204can obtain context data from sources relevant to the geolocation of the sending mobile device. For example, sensor manager204can acquire geolocation context data from various context-data acquisition components102. Context-data acquisition components102can utilize methods such as associating the geographic location with the Internet Protocol (IP) address of the mobile device and/or nearby fixed server, the MAC address mobile device, nearby RFID device, hardware embedded article/production number, embedded software number (such as UUID, Exif/IPTC/XMP or modern steganography (for example, in a nearby smart device)), a Wi-Fi connection location in proximity to the mobile device, device GPS coordinates of the mobile device, assisted GPS, enhanced GPS and/or self-disclosed information. Context-data ranking engine can rank the acquired geolocation data according to cost and method accuracy. A top ranked geolocation data can be provided by the query manager200to the requesting mobile device that generated the query. Bidding manager can charge the requesting mobile device an amount specified by the context-data acquisition component102that provided the selected geolocation data. The embodiments are not limited in this context.

FIG. 3is a diagram illustrating an architecture in which one or more embodiments can be implemented. The architecture includes multiple client devices302, remote sensor(s)306, a server device308, and a network300, which can be, for example, the Internet. Client devices302each include a computer-readable medium, such as random access memory, coupled to a processor. Processor executes program instructions stored in memory. Client devices302can also include a number of additional external or internal devices, such as, without limitation, a mouse, a CD-ROM, a keyboard, and a display. Thus, as will be appreciated by those skilled in the art, the client devices may be mobile personal computers, gaming computer system, personal digital assistances, mobile phones, content players, tablet computers (e.g. the iPad® by Apple Inc.), etc.

Through client devices302, users304can communicate over network300with each other and with other systems and devices coupled to network300, such as server device308, remote sensors, smart devices, third-party servers, and the like.

Remote sensor306can also be a client device that includes a sensor. Remote sensor can communicate with other systems and devices coupled to network300.

Similar to client devices302, server device308can include at least one processor coupled to a computer readable memory. Server device308may additionally include a secondary storage element, such as a database212and/or other database systems.

Client processors and server processor can be any of a number of well-known microprocessors. Memory may contain a number of programs, such as the components described above in reference toFIGS. 1 and 2. In some example embodiments, client device302, remote sensor304and/or server device308can be virtualized and reside in other computer systems.

In general, client device302may be any type of computing platform connected to a network and that interacts with application programs, such as a digital assistant or a “smart” cellular telephone. Remote sensor306and server308, although depicted as a single computer system, may be implemented as a network of computers and/or computer processors.

FIG. 4illustrates a mobile device400in accordance with one or more embodiments. In some embodiments, mobile device400may be implemented as a combination handheld computer and mobile telephone, sometimes referred to as a smart phone. Mobile device400may provide voice and/or data communications functionality in accordance with different types of cellular radiotelephone systems. Examples of cellular radiotelephone systems may include CDMA systems, GSM systems, North American Digital Cellular (NADC) systems, TDMA systems, Extended-TDMA (E-TDMA) systems, Narrowband Advanced Mobile Phone Service (NAMPS) systems, 3G systems such as Wide-band CDMA (WCDMA), CDMA-2000, Universal Mobile Telephone System (UMTS) systems, and so forth.

In addition to voice communications functionality, mobile device400may be arranged to provide mobile packet data communications functionality in accordance with different types of cellular radiotelephone systems. Examples of cellular radiotelephone systems offering mobile packet data communications services may include, inter alia, GSM with GPRS systems (GSM/GPRS), CDMA/1xRTT systems, Enhanced Data Rates for Global Evolution (EDGE) systems, EV-DO systems, Evolution For Data and Voice (EV-DV) systems, High Speed Downlink Packet Access (HSDPA) systems, High Speed Uplink Packet Access (HSUP A), and so forth.

Mobile device400may be arranged to provide voice and/or data communications functionality in accordance with different types of wireless network systems. Examples of wireless network systems may include a wireless local area network (WLAN) system, wireless metropolitan area network (WMAN) system, wireless wide area network (WWAN) system, and so forth. Examples of suitable wireless network systems offering data communication services may include the Institute of Electrical and Electronics Engineers (IEEE) 802.xx series of protocols, such as the IEEE 802.11a/b/g/n series of standard protocols and variants (also referred to as “WiFi”), the IEEE 802.16 series of standard protocols and variants (also referred to as “WiMAX”), the IEEE 802.20 series of standard protocols and variants, and so forth.

Mobile device400may be arranged to perform data communications in accordance with different types of shorter-range wireless systems, such as a wireless personal area network (PAN) system. One example of a suitable wireless PAN system offering data communication services may include a Bluetooth system operating in accordance with the Bluetooth Special Interest Group (SIG) series of protocols, including Bluetooth Specification versions v1.0, v1.1, v1.2, v2.0, v2.0 with Enhanced Data Rate (EDR), as well as one or more Bluetooth Profiles, and so forth. Other examples may include systems using infrared techniques or near-field communication techniques and protocols, such as electro-magnetic induction (EMI) techniques. An example of EMI techniques may include passive or active radiofrequency identification (RFID) protocols and devices.

As shown in the embodiment ofFIG. 4, mobile device400can include a dual processor architecture including a host processor402and a radio processor448. In some embodiments, host processor402and the radio processor448can be arranged to communicate with each other using interfaces such as one or more universal serial bus (USB) interfaces, micro-USB interfaces, universal asynchronous receiver-transmitter (UART) interfaces, general purpose input/output (GPIO) interfaces, control/status lines, control/data lines, audio lines, and so forth. Host processor402can be responsible for executing various software programs such as system programs and applications programs to provide computing and processing operations for the mobile device400. Radio processor448can be responsible for performing various voice and data communications operations for mobile device400such as transmitting and receiving voice and data information over one or more wireless communications channels. Although some embodiments can be described as comprising a dual processor architecture for purposes of illustration, it is worthy to note that mobile device400can include any suitable processor architecture and/or any suitable number of processors in accordance with the described embodiments.

Host processor402can be implemented as a host central processing unit (CPU) using any suitable processor or logic device, such as a as a general purpose processor. Although some embodiments can be described with host processor402implemented as a CPU or general purpose processor by way of example, it can be appreciated that the embodiments are not limited in this context. For example, host processor402can include, or be implemented as, a chip multiprocessor (CMP), dedicated processor, embedded processor, media processor, input/output (I/O) processor, co-processor, microprocessor, controller, microcontroller, application specific integrated circuit (ASIC), field programmable gate array (FPGA), programmable logic device (PLD), or other processing device in accordance with the described embodiments. Host processor402can be arranged to provide processing or computing resources to the mobile device400. For example, host processor402can be responsible for executing various software programs including system programs such as operating system (OS)404, context-enriched messaging application108, messaging applications406(e.g. short message application110), application programs418and sensor drivers420. System programs generally can assist in the .running of the mobile device400and can be directly responsible for controlling, integrating, and managing the individual hardware components of the computer system. In some embodiments, OS404can be implemented, for example, as an Apple iOS, Blackberry OS, Android OS, Symbian OS, Palm Web OS, Microsoft Windows Mobile, LiMo, MeeGo, Palm OS®, Palm OS® Cobalt, Microsoft® Windows OS, Microsoft Windows® CE OS, Microsoft Pocket PC OS, Microsoft Mobile OS, Symbian OS™, Embedix OS, Linux OS, Binary Run-time Environment for Wireless (BREW) OS, Java OS, a Wireless Application Protocol (WAP) OS, or other suitable OS in accordance with the described embodiments. The mobile device400can include other system programs such as device drivers, programming tools, utility programs, software libraries, application-programming interfaces (APIs), and so forth.

Host processor402can include messaging application406. Messaging application406can include a variety of text messaging applications that communicate various types of short messages in a variety of formats. Each messaging application can be representative of a particular kind of transport, enabling handling of short messages of particular types and formats for the particular application. The messaging applications can include, for example, an IM application, an e-mail application, an SMS application, and an MMS application. It is to be understood that the embodiments are not limited in this regard and that the messaging applications can include any other type of messaging or communications application in accordance with the described embodiments. In some embodiments, messaging applications can include a utility for converting voice messages to text. In this way, a voice message can be rendered into a short message format by a utility of messaging application406. Voice message data can be acquired from such applications as a telephone application such as a cellular telephone application, a Voice over Internet Protocol (VoIP) application, a Push-to-Talk (PTT) application, voicemail, and so forth.

Host processor402can include a context-enriched messaging application108. Context-enriched messaging application108can be arranged to enrich short messages (e.g. SMS, EMS, MMS, other proprietary application-generated messages and the like) generated with the mobile device400. In some embodiments, the short messages can be context enriched to include and/or refer to context data that provides information about the physical environment of mobile device400. Example reference devices include, inter alia, a hyperlink to a web document that includes the context data and/or an embedded URL to trigger the receiver's WAP browser to open and receive the context data from the embedded URL. Context-enriched messaging application108can communicate context-enriched messages, context data and/or short messages to a next appropriate entity according the various embodiments. For example, if the context-enriched message is an SMS message, context-enriched messaging application108can forward the context-enriched SMS message to an SMSC or VAS server, or similar entity of a cellular network. In another example, context-enriched messaging application108can forward the context-enriched message to a server if the context-enriched message utilizes an IP-based means of delivery (such as the Internet). Context-enriched messaging application108can be arranged to determine an appropriate context data to associate with the short message such as according to any of the various metrics discussed herein. Context-enriched messaging application108can also be arranged to manage sensors430A-N and432according to the various system attributes of the mobile device such as power availability, sensor power use, mobile device context, sensor availability and the like. Context-enriched messaging application108can also acquire context data from context provider104. In one example embodiment, context-enriched messaging application108can provide context data to enrich a communication of messaging application406.

Application programs418generally can allow a user to accomplish one or more specific tasks. In various implementations, the application programs418can provide one or more graphical user interfaces (GUIs) to communicate information between the mobile device400and a user. In some embodiments, application programs418can include upper layer programs running on top of the OS404of host processor402that operate in conjunction with the functions and protocols of lower layers including, for example, a transport layer such as a Transmission Control Protocol (TCP) layer, a network layer such as an IP layer, and a link layer such as a Point-to-Point (PPP) layer used to translate and format data for communication. Examples of application programs418can include, without limitation, messaging applications, web browsing applications, personal information management (PIM) applications (e.g., contacts, calendar, scheduling, tasks), word processing applications, spreadsheet applications, database applications, media applications (e.g., video player, audio player, multimedia player, digital camera, video camera, media management), gaining applications, image recognition applications (e.g. Google Goggles™ from Google Inc.) and so forth. It is also to be appreciated that the mobile device400can implement other types of applications in accordance with the described embodiments.

Sensor drivers420can be arranged to allow other programs such as OS404, application programs418, Context-enriched messaging application108and the like, to interact with sensors coupled with host processor402. Sensor drivers420can be specific to a sensor-type. Sensor drivers420can typically communicate with a sensor through a computer bus and/or communications subsystem to which the sensor connects. In some embodiments, sensor drivers420can communicate with one or more remote sensors432via a wireless interface, LAN and/or the Internet. In some embodiments, context-data provider104can utilize sensor drivers420to acquire context data from sensors430A-B and/or432. In such a case, mobile device400can include a utility to implement the communication between context-data provider104and sensors driver420.

Mobile device400can include an alphanumeric keypad422coupled to the host processor402. Keypad422can include, for example, a QWERTY key layout and an integrated number dial pad. Mobile device400can include various keys, buttons, and switches such as, for example, input keys, preset and programmable hot keys, left and right action buttons, a navigation button such as a multidirectional navigation button, phone/send and power/end buttons, preset and programmable shortcut buttons, a volume rocker switch, a ringer on/off switch having a vibrate mode, and so forth. In some embodiments, keypad422can be virtualized and rendered on touchscreen by a graphical user interface (GUI) utility.

Mobile device400can include a display424coupled to the host processor402. The display424can include any suitable visual interface for displaying content to a user of the mobile device400. In one embodiment, for example, the display424can be implemented by a liquid crystal display (LCD) such as a touch-sensitive color (e.g., 16-bit color) thin-film transistor (TFT) LCD screen. In some embodiments, the touch-sensitive LCD can be used with a stylus and/or a handwriting recognizer program.

Host processor402can be coupled to a power supply426arranged to supply and manage power to the elements of mobile device400. In some embodiments, the power supply426can be implemented by a rechargeable battery, such as a removable and rechargeable lithium ion battery to provide direct current (DC) power, and/or an alternating current (AC) adapter to draw power from a standard AC main power supply.

Host processor402can be coupled to sensors430A-N and/or remote sensor432. A sensor can be arranged to translate a physical characteristic of the environment of the mobile device400into a computer-processor readable format. Example sensors include, inter alia, global positioning system systems, accelerometers, inclinometers, position sensors (compass, magnetometer), barometers, WiFi sensors, RFID sensors, near-filed communication (NFC) devices, gyroscopes, pressure sensors, pressure gauges, time pressure gauges, torque sensors, ohmmeters, thermometers, infrared sensors, microphones, image sensors (e.g. digital cameras), biosensors (e.g. photometric biosensors, electrochemical biosensors), capacitance sensors, radio antennas, biometric sensors, capacitance probes and/or any combination thereof. It should be noted that the other sensor devices other than those listed can also be utilized to ‘sense’ context data.

Mobile device400can include an input/output (I/O) circuitry428coupled to the host processor402. I/O circuitry428can include one or more I/O devices such as a serial connection port, an infrared port, integrated Bluetooth™ wireless capability, and/or an integrated 802.11x (WiFi) wireless capability, to enable wired (e.g., USB cable) and/or wireless connection to a local computer system, such as a local personal computer (PC). In various implementations, mobile device400can be arranged to transfer and/or synchronize information with the local computer system. Various audio/video (AV) devices that support AV capability of the mobile device400can also be included. Examples of AV devices can include, for example, a microphone, one or more speakers, an audio port to connect an audio headset, an audio coder/decoder (codec), an audio player, a MIDI device, a digital camera, a video camera, a video codec, a video player, and so forth.

As shown, host processor402can be coupled through memory bus446to a memory434. Memory bus446can include any suitable interface and/or bus architecture for allowing host processor402to access memory434. Although memory434can be shown as being separate from host processor402for purposes of illustration, it is worthy to note that in various embodiments some portion or the entire memory434can be included on the same integrated circuit as host processor402. Alternatively, some portion or the entire memory434can be disposed on an integrated circuit or other medium (e.g., hard disk drive) external to the integrated circuit of host processor402. In various embodiments, mobile device400can include an expansion slot to support a multimedia and/or memory card, for example.

Memory434can be implemented using any computer-readable media capable of storing data such as volatile or non-volatile memory, removable or nonremovable memory, erasable or non-erasable memory, writeable or re-writeable memory, and so forth. Examples of computer-readable storage media can include, without limitation, random-access memory (RAM), dynamic RAM (DRAM), Double-Data-Rate DRAM (DDRAM), synchronous DRAM (SDRAM), static RAM (SRAM), read-only memory (ROM), programmable ROM (PROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory (e.g., NOR or NAND flash memory), content addressable memory (CAM), polymer memory (e.g., ferroelectric polymer memory), phase-change memory, ovonic memory, ferroelectric memory, silicon-oxide-nitride-oxide-silicon (SONOS) memory, magnetic or optical cards, or any other type of media suitable for storing information.

As mentioned above, radio processor448can perform voice and/or data communication operations for mobile device400. For example, radio processor448can be arranged to communicate voice information and/or data information over one or more assigned frequency bands of a wireless communication channel. In various embodiments, radio processor448can be implemented as a communications processor using any suitable processor or logic device, such as a modem processor or baseband processor. Although some embodiments can be described with radio processor448implemented as a modem processor or baseband processor by way of example, it can be appreciated that the embodiments are not limited in this context. For example, radio processor448can include, or be implemented as, a digital signal processor (DSP), media access control (MAC) processor, or any other type of communications processor in accordance with the described embodiments.

Mobile device400can include memory434coupled to radio processor448. Memory450can be implemented using one or more types of computer-readable media capable of storing data such as volatile or non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, writeable or re-writeable memory, and so forth. Memory450can include, for example, flash memory and secure digital (SD) RAM. Although memory450can be shown as being separate from and external to radio processor448for purposes of illustration, it is worthy to note that in various embodiments some portion or the entire memory450can be included on the same integrated circuit as radio processor448.

Mobile device400can include a transceiver module452coupled to radio processor448. Transceiver module452can include one or more transceivers arranged to communicate using different types of protocols, communication ranges, operating power requirements, FRO sub-bands, information types (e.g., voice or data), use scenarios, applications, and so forth. In various embodiments, transceiver module452can include one or more transceivers arranged to support voice communication for a cellular radiotelephone system such as a GSM, UMTS, and/or CDMA system. Transceiver module452also can include one or more transceivers arranged to perform data communications in accordance with one or more wireless communications protocols such as WWAN protocols (e.g., GSM/GPRS protocols, CDMA/1xRTT protocols, EDGE protocols, EV-DO protocols, EV-DV protocols, HSDPA protocols, etc.), WLAN protocols (e.g., IEEE 802.11a/b/g/n, IEEE 802.16, IEEE 802.20, etc), PAN protocols, Infrared protocols, Bluetooth protocols, EMI protocols including passive or active RFID protocols, and so forth. In some embodiments, transceiver module452can include a Global Positioning System (GPS) transceiver to support position determination and/or location-based services. Transceiver module452generally can be implemented using one or more chips as desired for a given implementation. Although transceiver module452can be shown as being separate from and external to radio processor448for purposes of illustration, it is worthy to note that in various embodiments some portion or the entire transceiver module452can be included on the same integrated circuit as radio processor448. The embodiments are not limited in this context.

Mobile device400can include antenna system154for transmitting and/or receiving electrical signals. As shown, antenna system154can be coupled to radio processor448through transceiver module452. Antenna system154can include or be implemented as one or more internal antennas and/or external antennas.

Mobile device400can include a subscriber identity module (SIM)456coupled to the radio processor448. SIM456can include, for example, a removable or non-removable smart card arranged to encrypt voice and data transmissions and to store user-specific data for allowing a voice or data communications network to identify and authenticate the user. SIM456also can store data such as personal settings specific to the user. In some embodiments, SIM456can be implemented as an UMTS universal SIM (USIM) card or a CDMA removable user identity module (RUIM) card. SIM456can include a SIM application toolkit (STK)458including a set of programmed commands for enabling the SIM456to perform various functions. In some cases, STK458can be arranged to enable SIM456to independently control various aspects of mobile device400.

FIG. 5is a flow diagram of an exemplary method for implementing one or more embodiments. The exemplary method is not limited by the order shown in the flow diagram. The process determines a context-data type from a query in step500. In some embodiments, a query can include a request for a context-data. In some embodiments, the query can also include information to assist in determining a source for the context data. In some embodiments, the query can include a copy of a short message. The short message can be analyzed to determine relevant context data sources. Alternatively or in addition to, the query can request a context-data type for a specified location (e.g. the location of the device that generated the short message). The location can then be surveyed to determine at least one relevant context-data source (such as context-data acquisition component102) from which to acquire a context data of the specified context-data type. For example, a query can be sent from a mobile device. The query may include a request for certain context data types related to the location of the mobile device. In one example, the query can also include a request to improve the accuracy of the location data of the mobile device using other geolocation operations available from other context-data sources.

In step502, at least one context-data source that provides the context-data type is identified. For example, in some embodiments, context-data sources can integrated into an entity for the purpose of providing context data. In such a case, a list of the context-data sources can be available on a web page and/or from a server. In some embodiments, a context-data source can be located using a search algorithm. For example, a context-source can reside in a mobile device. An entity such as a cellular-network management server can be contacted to determine the location of the mobile device. In one example, the cellular-network management server can be contacted to determine if mobile devices with certain types of context-data sources are available in certain locations. Various types of context-data source identification operations can be used alone or in combination according to the various embodiments.

In step504, a request for a context data of the context-data type to the at least one context data provider is generated. The request can be communicated to the context-data source(s). The requests can be formatted in accordance with the system and communication network protocols used by the context-data source(s).

In step506, received context data from the at least one context-data source is ranked according a specified parameter. One example method of ranking is that each received context data can be weighted according the specified parameter. The parameter can be specified in the query and/or be specific to a particular context-data type. A table of parameters and associated context-data types can be stored in an available database. In some embodiments, multiple parameters can be used to rank the context data received from the context-data sources. Once the context data is ranked, one or more context data can then be selected. In some embodiments, election can depend on the context-data type and/or specified parameter used to rank the context data. For example, if the specified parameter is cost of the context data charged by the context-data source. Then the context-data ranked with the lowest cost can be selected.

FIG. 6is a flow diagram of an exemplary method for implementing one or more embodiments. The exemplary method is not limited by the order shown in the flow diagram. In step600, a set of context-data from at least one context-data provider is collected. The context-data is related to a short-message content. In one example, the context data can be collected from a variety of) nodes representing sensors in a particular location that are available on one or more networks (e.g. LAN, WAN, the Internet). In a particular example, context-data from one or more sensors can be algorithmically combined and/or modified to generate a secondary context-data. For example, if the context-data type to be acquired is location data, then GPS context data from a variety of sources can be combined to determine an average GPS location. This average GPS location can then be collected into the set of context data. In yet another example, data from different sensor types can be combined and/or manipulated to generate another type of context data. For example, Wi-Fi location data (wireless local area network (WLAN) devices based on the IEEE 802.11 standards) can be averaged with GPS location data.

In step602, a relevant context data is selected according to a metric. In some embodiments, the metric can be an assigned magnitude for a value of a context-data. In some embodiments, the metric can include a state of a receiving device. For example, a power-source of the receiving device can be obtained. The value of the power can then be an example of a metric used to selected the relevant context data. In some embodiments, the metric can be related to a content of the short message. For example, if the short message includes a term “here”, the metric can be the accuracy of the location context data. In some embodiments, the metric can be related to an available bandwidth of a communication network. For example, if the short message is to be delivered via an SMS network, then the metric can include context-data that can be transported within the bandwidth limitations of the SMS network. In some embodiments, the metric can include a combination of other metrics.

In step604, the relevant context data is linked to the short message. In one example, the context data can be appended to the short message. The context data can be modified according to the type of short message. In another example, a hyperlink to the context data can be included in the short message. In yet another example, the context data can be rendered as text and/or a graphical icon and included in the short message.

In step606, the relevant context data and the short message are formatted according to a communication protocol. For example, in some embodiments, the context data can be formatted to be included in an SMS, EMS and/or MMS message according to the type of short message generated by the sending device. Alternatively, in other example embodiments, the original short message can be modulated into another short-message type in order to accommodate the context data.

FIG. 7shows a set of operations for context-data acquisition and ranking according one example embodiment. In step700, context-enriched messaging application108receives a short message from short message application110. Both context-enriched messaging application108and short message application110can reside on a mobile device such mobile device400. In step702, context-enriched messaging application104can request a context-data type from a context-data provider104residing on a server. Context-data provider104can conduct a search of context-data type sources in the contextual proximity of the mobile device in step704. In some embodiments, contextual proximity can include the conditions and circumstances of the mobile device that are relevant to a short message generated by the mobile device. In some embodiments, context-data acquisition components102can provide locations and available context-data types to context-data provider104. Context-data provider104can then store the information in a register. Context-data provider104can periodically query context-data acquisition components102in order to update the register. Context-data provider104and context-data acquisition components102can communicate via any available communication network. In step706, context-data provider104can request context-data from located context-data acquisition components102that provide the specified context-data type in the contextual proximity of the mobile device. In step708, context-data acquisition components102can acquire context data (e.g. using a sensor) and return the context-data to context-data provider104. In some embodiments, context-data acquisition components102can also return metadata regarding the state of the sensor used to acquire the context-data, as well as other pertinent information to context-data provider104. This metadata can be used to rank and format returned context data. In step710, context-data provider104ranks and returns one or more advantageously ranked context data to context-enriched messaging application108. In step712, context data is associated with the short message. Example methods of associating context data and the short message have been discussed supra. The resulting context-enriched short message can then be communicated by the mobile device to an appropriate communications network for forwarding to a receiving mobile device. The embodiments are not limited in this context.

FIG. 8shows a set of operations for context-data acquisition and ranking according another example embodiment. In step800, context-enriched messaging application108can provide a short message to context-data provider104. Context-data provider104can analyze the short message to determine one or more context-data types to associate with the various words, phrases or media of the short message in step802. Context-data provider104can locate one or more context-data type sources in the contextual proximity of the mobile device in step804. A context data source can be a context-data acquisition component102. Context-data acquisition component102can include, for example, smart devices with sensors, virtual sensors, databases with recently acquired context data, third-party servers, other mobile devices with sensors, and the like. Context-data acquisition components102can be placed into categories of context-data types acquirable by the respective context-data acquisition component102. In step806, context-data provider104can request context data from the located context-data sources. In step808, the context data is acquired and returned by each context-data acquisition component102that received a request and was able to acquire a context-data measurement. In step810, context-data provider104ranks the received context data according to a certain parameter. In step812, context-data provider104associates the highest ranked context data with short message. The short message and associated context data can then be forwarded to a communication network by context-data provider104for delivery to a receiving mobile device short message application. The embodiments are not limited in this context.