Preferred embodiments of the present invention are described in detail with reference to the accompanying drawings. The same or similar components may be designated by the same or similar reference numerals although they are illustrated in different drawings. Detailed descriptions of constructions or processes known in the art may be omitted to avoid obscuring the subject matter of the present invention.

It should be understood that the terms used to describe various embodiments are provided to merely aid the understanding of the description, and that their use and definitions in no way limit the scope of the invention. Terms first, second, and the like are used to differentiate between objects having the same terminology and are no where intended to represent a chronological order, as and where stated otherwise. A set is defined as a non-empty set including at least one element.

FIG. 1 and FIG. 2 illustrate an environment 110 in accordance with an embodiment of the present invention. The environment 110 includes a plurality of electronic devices, for example, an electronic device or user agent 102 and an electronic device or service agent 104. However, while only two electronic devices are shown in the environment 110, it will be apparent to the person ordinarily skilled in the art that the environment 110 may include more electronic devices or a plurality of non-electronic devices. The examples of electronic devices 102 and 104 include, but are not limited to, mobile phones, televisions, PDAs, and computers.

In an embodiment of the present invention, the electronic devices 102 and 104 are capable of communicating with each other using a telecommunication network. In another embodiment of the present invention, the electronic devices 102 and 104 are capable of communicating with each other through short-range wireless communication technology. Examples of short range wireless communication technology includes but are not limited to, short range radio (BT), IR and NFC. Hence, the electronic devices 102 and 104 are capable of communicating with each other through NFC technology.

In the environment 110, a user of the electronic device 102 exchanges context information between the electronic device 104 and the electronic device 102 through NFC. The different fields in which context data may be used are shown as use cases 106. In an embodiment of the present invention, the electronic devices 102 and 104 are known as NFC devices. In an embodiment of the present invention, the electronic device 104 takes the role of an aggregator device. The aggregator device is a device that aggregates context data received from a plurality of devices. The aggregator device dynamically arranges context data corresponding to each of the electronic devices in a memory.

In NFC, the electronic devices, for example electronic devices 102 and 104, can communicate in three application modes. The three application modes are Peer-to-Peer mode, Reader/Writer mode, and Card Emulation mode. In the Peer-to-Peer mode of communication, both NFC devices have similar capability and there is no distinction between the NFC devices. In the Reader/Writer mode of communication, one of the NFC devices has the capability of the Reader/Writer and the other NFC device is a simple tag. In the Card Emulation mode of communication, one of the NFC devices is a reader and the other NFC device could be a simple tag. Hence, the information can be exchanged through any of the application modes described above.

To transfer data in the NFC network, the data is represented based on well-defined NFC data formats called RTDs. The RTDs are in turn packaged in a format called NFC Data Exchange Format (NDEF). Different types of RTDs in NFC standards are for example, Smart Poster RTD, Text RTD, URI RTD, Web RTD, and the like.

In the Peer-to-Peer networks, participating users/devices may exchange context information 108 with other electronic devices, as shown in FIG. 2. Examples of context information 108 include, but are not limited to, user profile, current location of the user, user preferences, room temperature, user’s blood pressure, user’s emotion, user’s presence, user’s identity, and the like. The context information can be private information associated with the users and can even vary with time and environment.

However, the set of defined RTDs are not sufficient to define CA information, which can be required by Peer-To-Peer devices and applications. Hence, a context RTD can be used for exchanging and transferring context information over the NFC interface. The structure of the context RTD is explained in conjunction with FIG. 4 and FIG. 5. For the sake of clarity and for the purpose of this description the context data is also referred as context information. Further, the electronic device 104 is also referred as the aggregator 104.

In an embodiment of the present invention, the context data from different nodes and/or electronic devices is aggregated at a single node and the node is called the aggregator. The aggregated context data at the aggregator is represented by an extended form of Context RTD. For example, in FIG. 1 and FIG 2, a context environment can be established by exchanging context information through easily readable tags. The aggregator device, for example, electronic device 104, can capture the context information from various electronic devices and aggregate them for the use of other devices.

In an embodiment of the present invention, when a user of the electronic device 102 enters the context environment, the context data associated with the electronic device 102 and the context environment are exchanged over the NFC interface. The use case 106 in the FIG. 1 shows a plurality of cases where the NFC technology can be used. Examples of NFC uses, sharing files, payment, ticketing, and the like. The context information can be exchanged through a stored NFC tags as per a NFC pre-defined format, RTD.

In Fig. 2 when the user of the electronic device 102 touches the electronic device 104 the context information 108 of the user, for example location, floor, and room information of the user, are updated in the environment and other context information is updated in the electronic device 102. Thereafter, the context data can be used for managing different applications using one or more short-range wireless communication networks. For example, the context information 108 gathered by electronic device 102 is used by different applications communicating over BT and a BT profile is derived for such a context transfer operation.

FIG. 3 illustrates the electronic device 102 in accordance with an embodiment of the present invention. The electronic device 102 includes a processor 202 and a transceiver 204. The processor 202 processes context data in the electronic device 102. In an embodiment of the present invention, the processor 202 represents the context data based on a context RTD. The context RTD is a record type definition used for defining context data in the NFC network.

The transceiver 204 receives a request from one or more electronic devices to send context data. Hence, when the transceiver 204 receives the request, the processor 202 represents the context data in the context RTD format. Thereafter, the transceiver 204 exchanges the context data that is represented based on the context RTD with the one or more electronic devices. In an embodiment of the present invention, the transceiver 204 transmits the processed context data to other electronic devices. Similarly, the transceiver 204 receives the context data from the other electronic devices.

FIG. 4 illustrates a NDEF structure for a context RTD, in accordance with an embodiment of the present invention. The NFC enables the exchange of data in a plurality of formats and for a plurality of applications. Hence, the NFC forum defines a plurality of data formats using a plurality of RTDs. Examples of the plurality of RTDs include Smart Poster, Handover of Configuration information, Web Access, and the like.

In an embodiment of the present invention, the RTD can be used individually and/or can be part of an NDEF message. The RTD has a plurality of header fields that represent a plurality of information that is associated with data. The plurality of information associated with the data includes control information of a record, a type of data, a payload length of the data, an identity field, and the like. Hence, the plurality of information associated with the context data is stored in a plurality of byte fields, for example a byte field 302, a byte field 304, a byte field 306, a byte field 308, a byte field 310, and a byte field 312.

The byte field 302 represents a first byte that includes control information for the NDEF message associated with the context data. The byte field 302 includes a plurality of information that is included in a plurality of bit fields. Each of the plurality of bit fields signifies specific information associated with the context data. In an embodiment of the present invention, the byte field 302 is divided into six bit fields represented as MB, MF, CF, SR, IL and TNF.

Each of the six bit fields signifies specific information, for example, MB represents Message Begin, ME represents Message End, CF represents Chunk Flag, SR represents Short Record, IL represents ID Length field, TNF represents Type Name Format. The different bit fields can represent different values for representing the data. For example, the TNF can have the value 0x01 or 0x04.

The byte field 304 represents type length of the type field shown in byte field 310. The Payload length byte fields, for example the byte fields 306a, 306b, 306c, and 306d, give the length of the context payload that is given in 314. The byte field 308 represents ID length of the data. Hence, the byte field 308 provides the length value of the ID. The byte field 310 represents the Type of the payload. For example, the ‘Type’ of the payload is CA for context data.

The byte field 312 represents an ID field. The ID field is used to identify the context. For example, the ID field is used to identify location, user, presence or other sensor data. Further, the byte field 314 represents payload associated with the type of data. For example, the byte field represents CA specific payload. For the sake of clarity, summary of the different fields used in the Context RTD is provided in Table 1. In Table 1, a first column represents field names. The second column has the description of corresponding field.

Table 1

The details of the types for context RTD are provided in Table 2 shown below. In Table 2, a first column represents Record Name and a second column gives the Description of the corresponding record name.

Table 2

FIG. 5 illustrates formats for the context payload, in accordance with different embodiments of the present invention. The format is divided into a plurality of fields. A field 402 is a Control_Bitmap field. The field 402 is a two-byte field. Further, the field 402 represents a bitmap where each bit is used to indicate if the corresponding control field information is present in this context representation. A field 404 in the format is a TLV privacy level. Hence, the field 404 is represented in the Type Length Value (TLV) format and indicates the privacy level that should be satisfied for using the context payload.

The TLV for each control can vary based on the context data. Hence the TLV Privacy Level field (the byte field 404) is used to indicate privacy level expected for exchange of the context data. A field 406 is a TLV Time Stamp field. The field 406 is used to express time at which the context data was captured. The field 408 represents the TLV Validity. Further, the field 408 indicates a time duration for which the context data will be valid. The context data after the TLV validity time expires is not assumed valid.

A field 410 represents a TLV Location Specific data. The field 410 indicates parameters that are considered along with location context data given in the payload. For example, a relative GPS coordinate associated with the context data can be represented with this field. A field 412 represents a TLV Trust Level. The field 412 is used to indicate trust level that needs to be satisfied by the electronic device while reading the context data in the payload.

A field 414 represents TLV Action to be taken on the context data. The field 414 indicates action that a first electronic device expects a second electronic device to take. A field 416 represents a TLV Other Control fields. The field 416 is used to mention other control fields that are specific to the electronic device and/or application that will use the context data.

A field 418 represents a TLV Schema/Format. The field 418 is used to indicate schema or format in which the context data is represented. Thereafter, a field 420 represents a context data. The field 420 represents the context data in a pre-agreed format. For the sake of clarity, summary of the different fields for the context payload is provided in Table 3. In Table 3, a first column represents field names. The second column has the description of corresponding field.

Table 3

FIG. 6 illustrates a flow chart depicting a method for managing data in a NFC network, in accordance with an embodiment of the present invention. To explain the method 500, references will be made to FIGs. 1 and 2. However, it will be apparent to a person ordinarily skilled in the art that the present invention can be explained with the help of any other suitable embodiment of the present invention. The method 500 can also include a different number of steps than those depicted in FIG. 6. Further, the order of the steps may also vary. In an embodiment of the present invention, the method is performed by the communication device.

At step 502, the method 500 is initiated. At step 504, the method exchange of the context data includes interchanging one or more NFC RTD with the second electronic device. In another embodiment of the present invention, the context data is also encapsulated with control parameters in the context RTD prior to exchanging the context data.

The context data assembled in the context RTD can be used by different applications. In an embodiment of the present invention, the different applications include BT applications. The applications are used based on context data represented using context RTD and/or one or more BT profiles. The context data received from a plurality of electronic devices can also be aggregated in an electronic device, for example the aggregator 104.

In an embodiment of the present invention, the electronic device receives context data from a plurality of electronic devices through one or more wireless communication networks. In another embodiment of the present invention, one or more wireless communication networks include one or more short-range wireless communication networks. Further, the context data in the context RTD format is aggregated based on the context data received from each of the plurality of electronic devices. For example, the context information received from the first electronic device is maintained corresponding to the first electronic device number.

In an embodiment of the present invention, the NFC network between the first electronic device and the second electronic device is based on a peer-to-peer mode of communication. In another embodiment of the present invention, the NFC network between the first electronic device and the second electronic device is based on a reader/writer mode of communication.

At step 510, the method 500 is terminated.

FIG. 7 illustrates an environment, in accordance with another embodiment of the present invention. The environment 600 includes, a plurality of network of sensors, for example, a network of sensors 602 and a network of sensors 604, an aggregator device, for example, the electronic device 104, an electronic device capable of enabling NFC, for example the electronic device 102, and a plurality of Peer-to-Peer networks (P2P), for example, a Peer-to-Peer (P2P) network 606 and a Peer-to-Peer (P2P) network 608. In a Peer-to-Peer (P2P) network, devices communicate through BT, Wi-Fi wireless connection, and the like. The electronic devices include various sensors and are enabled with various features.

In an embodiment of the present invention, the electronic devices are associated with one or more sensors such as GPS, RFID, and temperature sensors. A P2P network can communicate with another P2P network through a wireless network or a wire lined communication network. For example, the P2P network 606 and the P2P network 608 can communicate with each other through a wireless communication network.

In the environment 600, the aggregator is a device or a computer that aggregates a plurality of information and can communicate with other networks and electronic devices. For example, the electronic device 102 or the aggregator 104 communicates with a sensor network using a wired (LAN, USB) or a wireless (Wi-Fi, BT, NFC) connection. Further, the aggregator 104 also communicates with the electronic device 102 through NFC, BT, and the like.

The aggregator 104, aggregates information received from all the sensors and arrange in Context RTD format, as shown in FIG. 4. Further, the electronic device 102 also stores context data associated with a plurality of users. When an NFC device, for example the electronic device 102, establishes a communication link with the electronic device 104, context data associated with the user of the electronic device 102 can be exchanged between the electronic devices 102 and 104.

In an embodiment of the present invention, the electronic device 102 also shares updated information with a plurality of electronic devices associated with it through a communication link. Therefore, the electronic device 102, after establishing a communication link with the electronic device 104, exchanges the updated context data aggregated in the electronic device 104. Hence, when the user of the NFC device 102 enters the region of the P2P network 606, the electronic devices in the P2P network 606 can exchange context data with the electronic device 102 based on the updated information received from the electronic device 102.

In an embodiment of the present invention, the context data represented in a context RTD format can be shared between an NFC device and a non-NFC device using short-range wireless communication networks. In an embodiment of the present invention, the non-NFC device can be a BT enabled device. Hence, the context data represented in a context RTD can also be accessed by the non-NFC devices using different profiles.

FIG. 8 illustrates a message flow diagram depicting a method to manage data in a NFC network, in accordance with an embodiment of the present invention. In the environment 700, a first device, initiator 702, is initially authenticated. The initiator 702 requests context information from a second device, target 703, using a REQUEST_CONTEXT_INFO () primitive.

At step 704, the initiator 702 sends REQUEST_CONTEXT_INFORMATION () primitive to the target 703. The target 703 composes appropriated response using a Context RTD and then sends the context data as RECEIVE_CONTEXT_INFORMATION () message to the initiator 702, in step 706. Hence, the context information can be shared and exchanged between the electronic devices using context RTD in the NFC network.

Further, the context RTD can also be used for other short-range wireless communication networks applications. For example, the context RTD can be used for enabling BT applications. In an embodiment of the present invention, the communication between the electronic devices for sharing the context information is performed using a BT profile or a WiFi transfer mechanism. In an embodiment of the present invention, a third device, source 710, requests context information using a GET_CONTEXT_INFO () primitive over BT wireless technology. In an embodiment of the present invention, the request for context information is done after proper authentication of electronic devices.

At step 714, the source 710 request for context data from a receiver, sink 712, using GET_CONTEXT_INFO (). The sink 712, then encapsulates the context data through a BT profile and sends the context data using the SEND_CONTEXT_INFO() primitive. At step 716 and 718, the sink 712 and the source 710 share context information (CA_RTD). The message primitives are representative in nature and can be expanded or added based on a use case.

For exchange of context data between two NFC enabled devices and/or for communicating the context data over BT various Application Programming Interfaces (APIs) are used. Some of the APIs are defined below for reference. However, the invention is not limited to the APIs listed below and a person ordinarily skilled in the art can use any other API's.

REQUEST_CONTEXT_INFORMATION (): The API is used to get the context data from another NFC enabled device.

RECEIVE_CONTEXT_INFORMATION (): The API is used to receive context data when the context data is requested or pushed by another device.

SEND_CONTEXT_INFORMATION (): The API is used to send context data when the context data is requested and/or when sending as unsolicited messages over BT.

GET_CONTEXT_INFORMATION (): The API is used to get context data from other BT enabled devices.

SUBSCRIBE_CONTEXT_INFORMATION: The API is used when a periodic update of some context data is expected from an NFC / BT enabled entity.

FIG. 9 illustrates a BT protocol stack incorporating a CA profile for exchanging context data, in accordance with an embodiment of the present invention. In an embodiment of the present invention, an electronic device 802 (also referred to as a sender device) sends CA data to an electronic device 804 (also referred to as a receiver device). The sender device 802 and the receiver device 804 have identical BT protocol stack including Service Discovery Protocol (SDP), Logical Link Control Adaptation Protocol (L2CAP), Link Manger (LM), Baseband (BB) and Radio Layer (RF).

The sender device 802 and the receiver device 804 have respective CA profiles, 806 and 808, that enable the devices to exchange shared context information. The sender device 802 sends the context information using CA profile encapsulating Context RTD in the primitives SEND_CONTEXT_INFORMATION, GET_CONTEXT_INFORMATION, and SUBSCRIBE CONTEXT_INFORMATION, which is in turn used by the CA application.

FIG. 10 is an example of the invention, in accordance with an embodiment of the present invention. The following example is solely for the sake of clarity and does not limit the scope of the invention.

User 1 902 visits an exhibition fair in a particular city. The exhibition fair has plurality of stalls, for example, 5000 stalls. User 1 902 has an interest in Nano technology material. Hence, User 1 902 updates his mobile phone with Nano technology context. Thereafter, User 1 902 carries an NFC enabled mobile phone, for example, the electronic device 102, into the exhibition fair. There, User 1 902 establishes an NFC with the aggregator, for example, the electronic device 104, at an entrance 904.

Thereafter, at step 906, the aggregator 104 sends a request to the electronic device 102 about context data using REQUEST_CONTEXT_INFO () primitive. At step 908, User 1 902 sends context data in a context RTD format to the aggregator 104 using RECEIVE_CONTEXT_INFO () primitive. At step 910, the context data and preferences of Nano technology associated with User 1 902 are captured and updated in a data management system.

The aggregator 104 also captures and assembles information about a plurality of stalls in the exhibition fair. For example, a shop 912 sends the context information to the aggregator 104 using a short-range wireless communication profile, for example a BT profile. At step 914, the shop 912 sends the context information using SEND_CONTEXT_INFO_BT (). At step 916, User 1 902 gets information about the shop 912.

Thereafter, User 1 902 will be prompted through BT profile and connectivity if he/she crosses a stall of Bio-tech sensors related to Nano technology. Therefore, the context data can be requested and received based on the interest of User 1 902 and preferences. The context data can be received at step 918 and sent at step 920 based on the REQUEST_CONTEXT_INFO () primitive and RECEIVE_CONTEXT_INFO () primitive. At step 922, when User 1 902 crosses the stalls in the exhibition fair, the context data is exchanged between the shop 912 and User 1 902 electronic device. Further, User 1 902 also gets the specific information as per the interest through NFC.

In addition, User 1 902 may also receive regular prompts about different users who have visited the same stall, for example User 2 924. These exchange happen using Context RTD over other carriers such as BT or WiFi. The exchange is shown at step 926 and step 928. Hence, this enables a virtual social networking in an ad-hoc real-time fashion. The message sequence diagram is shown in FIG. 7.

As per the example discussed above, User 1 902 preferences are stored on his mobile device as a ContextRTD as represented in Table 4. Table 4 represents ContextRTD at User 1 902 mobile device when he is entering the premises of the exhibition. Although, Web Ontology Language "OWL" is used in the Table 4 as a representation format for context RTD information, it will be apparent to the person skilled in the art that representation format, such as XML, RDF, and RDFS can also be used.

Table 4

The "REQUEST" and "RECEIVE" CONTEXT_INFO () primitives are used to exchange the context information at the entrance. After the context information is exchanged, a system stores and updates a relevant database along with aggregated context data. Hence at a particular location, for example, at Shop 912, a system at Shop 912 recognizes the interest of the User 1 902, and pushes the context information as a BT Profile which is shown in Table 5. Table 5 is a representative context RTD of Shop 912 which specializes in Nano Technologies.

Table 5

There may be multiple instances of this context RTD which can be shared based on the events/updates that are generated. In this case, a generic ContextRTD is generated and sent to the system at Shop 912, when the system does not know specific interest of User 1 902. After receiving the context information, the electronic device at User 1 902 analyzes received information and generates relevant alterations for User 1 902.

Alerts are sent to User 1 902 stating information about presence of Nano Technology related information at Shop 912. Thereafter, on receiving the alerts, User 1 902 decides to visit Shop 912. At the entrance of Shop 912, User 1 902 exchanges his context information over the NFC enabled device using the REQUEST and RECEIVE primitives. The associated ContextRTD is shown in Tables 4 and 6. Table 6 represents ContextRTD exchanged based on User 1 Interest.

Table 6

Once the context information is exchanged, the system at User 1 902 electronic device, the system at the Shop 912, and aggregator 104 at the entrance update the relevant database and generate appropriate notification and events for other users. For example, in this case, User 2 924 whose interest is similar to that of User 1 902 may be notified of the presence of User 1 902 at Shop 912 over BT or WiFi. When User 1 902 crosses User 2 924, the system generates an event at the device of User 2 924 stating that User 1 902 in close vicinity. This event leads to an exchange of context information over the BT profile using the BT Context Profile.

While the invention has been shown and described with reference to certain preferred embodiments thereof, it will understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the invention as defined in the appended claims.