WO2010115219A2

WO2010115219A2 - A method of transmitting digital information

Info

Publication number: WO2010115219A2
Application number: PCT/ZA2010/000013
Authority: WO
Inventors: David Hislop
Original assignee: David Hislop
Priority date: 2009-04-03
Filing date: 2010-03-29
Publication date: 2010-10-07
Also published as: WO2010115219A3

Abstract

A method and a system for transmitting digital information is provided, including creating digital information at a node, the digital information being arranged to be transmitted to another node. Context information is linked to the digital information which is then being transmitted from the node to another node, enabling the other node to determine an appropriate response upon receiving the digital information, by means of the context information.

Description

Title:

A method of transmitting digital information.

Field of the invention:

This invention relates to a method of transmitting digital information. In particular, the invention relates to a method of transmitting digital information and to a digital information transmission system.

Background of the invention:

A data model for defining the concept of linking context, or context information, to data is proposed. It is believed that the method can be used advantageously in security filtering applications, for example, in a data transmission system, such as, the Internet, or the like, for example. The term context can include geographical context, temporal context, location context as well as a social network context.

Summary of the invention:

According to a first aspect of the invention, there is provided a method of transmitting digital information, the method including: creating digital information at a node, the digital information being arranged to be transmitted to another node; linking context information to the digital information; transmitting the digital information from the node to the other node; and enabling the other node to determine an appropriate response upon receiving the digital information, by means of the context information.

Linking context information to the digital information may include linking context information including a time of creation of the digital information.

Linking context information to the digital information may include linking context information including a location at the node to the digital information.

Linking context information to the digital information may include linking context information including an owner of the digital information. Linking context information to the digital information may include linking context information including a destination for the digital information to the digital information.

Linking context information to the digital information may include linking context information including a manifest to the digital information.

Linking context information to the digital information may include linking context information including a social network context of the digital information to the digital information.

Enabling the other node to determine an appropriate response upon receiving the digital information by means of the context information may include enabling the other node to compare the context information with predetermined parameters, to forward the digital information together with the context information to a next node should the context information comply with predetermined parameters and to dump the digital information together with the context information should the context information fail to comply with the predetermined parameters.

Enabling the other node to compare the context information with predetermined parameters and to forward the digital information together with the context information to a next node should the context information comply with predetermined parameters may include enabling the other node to modify the context information.

Enabling the other node to modify the context information may include enabling the other node to add history of the passage of the digital information to the context information.

Enabling the other node to determine an appropriate response upon receiving the digital information by means of the context information may include enabling the other node to compare the context information with predetermined parameters and to transmit an appropriate response to the node, the appropriate response being determined by considering the context information.

According to another aspect of the invention, there is provided a digital information transmission system including: a node having instructions for creating digital information to be transmitted to another node; instructions for linking context information to the digital information; another node operatively connected to the node so as to receive transmitted digital information from the node; and instructions for enabling the other node to determine an appropriate response upon receiving the digital information from the node by means of the context information.

The instructions for linking context information to the digital information may include instructions for linking context information including a time of creation of the digital information.

The instructions for linking context information to the digital information may include instructions for linking context information including a location at the node to the digital information.

The instructions for linking context information to the digital information may include instructions for linking context information including an owner at the node to the digital information.

The instructions for linking context information to the digital information may include instructions for linking context information including a destination for the digital information to the digital information.

The instructions for linking context information to the digital information may include instructions for linking context information including a manifest to the digital information. The instructions for linking context information to the digital information may include instructions for linking context information including a social network context of the digital information to the digital information.

The instructions for enabling the other node to determine an appropriate response upon receiving the digital information from the node by means of the context information may include instructions enabling the other node to compare the context information with predetermined parameters, to forward the digital information together with the context information to a next node should the context information comply with predetermined parameters and to dump the digital information together with the context information should the context information fail to comply with the predetermined parameters.

The instructions for enabling the other node to forward the digital information together with the context information to a next node should the context information comply with predetermined parameters may include instructions for enabling the other node to modify the context information.

The instructions for enabling the other node to modify the context information may include instructions for enabling the other node to add history of the passage of the digital information to the context information.

The instructions for enabling the other node to determine an appropriate response upon receiving the digital information from the node by means of the context information may include instructions enabling the other node to compare the context information with predetermined parameters and to transmit an appropriate response to the node, the appropriate response being determined by considering the context information.

Brief Description of the drawings:

Embodiment of the invention will now be described, by way of example, with reference to the accompanying diagrammatic drawings, in which: Figure 1 shows a schematic representation of a message having a probability value of between t₀ and ti,the message being indicated as being certain; and

Figure 2 shows a schematic representation of an example of a pseudo-code.

Detailed Description of preferred embodiments:

By way of example, assume that you were offered information corresponding to a list of NHS clients in the UK, (which was famously lost a few years ago in the UK). Typically, such information would have no real value unless it could be determined to be authentic, to be current, and the like, for example. To establish this, certain factors can be examined, such as, the source of the information can be determined (the NHS in this case), the route which the information followed to get to you can be determined (i.e. you trust the messengers), the fact that you may want to sell it to spammers (the destination), the age of the data can be determined (that records have not lapsed), that the integrity is intact (that it is not circulated by law enforcement, to trap spammers), and so on. Such factors can be referred to as context of the information corresponding to the list of NHS clients in the UK.

Context can be carried implicitly by data. Such context can be controlled through direct control agents over the data by making use of "fortress" security models, for example. However, surrounding information with a "security fence" invites attack. It is clear that some data is more important than other data; there is security in the "comfort of crowds"; context can get lost; there is formal definition that will allow other agents to consume data with context and modify it. Accordingly, context can be used by IT systems. Context is associated with data so as to permit the information to be shared in a programming interface.

Context is employed in everyday human interaction, for example. There is a difference between the acceptance of information being credible when the information is shouted at you by a random person in the street and when the same information is conveyed to you from a friend who has a reputation for honesty.

It is believed that the invention can be used advantageously when information is transmitted between mobile phones in a mobile phone network, for example. However, it will be appreciated that the invention is not limited to such an application only, but extends to any other appropriate application, such as the transmission of information in a computer network, for example.

Advantageously, the method of linking context to data in accordance with the invention, avoids having a central registry for context, does not subvert any existing communications or security protocols to implement it, context information evolves over time and context can be "fuzzy" - it is interpreted in a context, which resolves some of this vagueness.

Typically, the information, or payload information, has a level of granularity which will be describe later. This means that one can decide whether to apply context to the entire NHS data set, as used in the example above, or just the letter "A" in the initial field of a contact. This will be described in greater detail below.

The invention provides a mechanism for capturing context parametrically and for transmitting the context information in such a way that existing protocols are retained. The method of the invention can be used for filtering, security, with infrastructure and for dotmobi applications, and the like, for example, as will be described herein below.

The context of the invention will now be described together with how to represent it and how it is attached to information, or "payload" data. Rules are then proposed for valid transformations of the data and some general mathematical properties will be explained. An Application Programming Interface (API) will then be described.

Although the embodiment of the invention can be used in any appropriate corresponding data transmission protocol, it is envisaged that it can be used for Internet data protocol, in particular. The Internet was invented by Tim Berners-Lee and Robert Cailliau to be context free. This is fine for collaborating scientists, for example, but makes eCommerce - where legal transactions have to be located in law - rather difficult. The invention recognizes a feature in the separate but related mobile communications field, which can provide geographical context (legally enforced upon it through, E911 legislation, for example) and social context.

In the case of social context, the context information can have the following aspects, namely, the owner (in this case the owner of the data), the destination (the intended recipient of the data), a manifest ( a way of "proving" the context does refer to the correct data), a history (an ordered list of nodes which the information followed during transmission), a temporal (time) profile (which may include having a lifetime and a creation date), a physical origin such as location (which may be associated with the history), a social context ( such as whether the information is circulated between friends, in a family or in a business (This can be interpreted as orthogonal axes) and a value (Probability of Veracity) of being true ( i.e. the user can cast aspersions on the data). In other words, the user can use some subjective information to decrease the value of the message, for example.

For convenience the above will be referred to as a context mote. Furthermore, it will be assumed that the information is transmitted between nodes and that the payload data is a message.

It will be appreciated that the context need not include all of the above aspects. Only useful aspects of the context are linked to the information, depending on the application.

A node at a later stage may choose to change this mote, for example, upgrade the value parameter of the information (based on other information), but that is for the application to decide.

A null value of one of the aspects means the data is not available or relevant, and does not necessarily imply a zero value.

Each node can modify the information traversing it as they desire, i.e. "put a spin on things". The Social Context will take into account this "Chinese whisper" effect. The phenomenon of Chinese Whispers implies a lack of fidelity of information transfer between people. For example, assume each node propagates 90% of the information. Then after two nodes, there is 81% and three nodes 72.9% and so on. Accordingly, after about five hops, typically only about 50% of the information is intact.

The exact form in which this data is propagated can vary. However, for context data which is not in a closed system, it can advantageously be represented by self describing xml, that is collapsed and converted to text, in a fashion similar to Wireless Binary XML (WBXML), for example.

The owner aspect will now be described in greater detail. An intention of data exchange is to ascribe data with a real owner. The owner here is not the person who derives ultimate value from the information, but the person or entity who created the data. The representation of this person may be highly structured (for example, in a self describing xml structure that enumerates the person's name as Title, First Name, Surname, etc.) or quite specific (for example "Bilbo Baggins") or colloquial (for example "dad").

Nodes may come in different generations: a. Series 1 (monitoring equipment, such as a monitor on a reservoir that communicates with a base via GSM), b. Series 2 (interactive monitoring equipment, such as a security system, for example), c. Series 3 (basic personal device), d. Series 4 (smart phone), or e. Series 5 (personal sensor data)

The destination aspect is the intended destination of the data. Once again it can be quite specific or colloquial, as described in the context metadata.

The manifest aspect is arranged to give some confidence that the context mote is attached to the correct data. A conventional algorithm for creating a message and linking the context to the message can be used. The conventional algorithm can be in the form of a cryptographic hash function, such as, SHA-256, for example. However, it is possible to use other digest information. The history aspect can be in the form of a list of nodes, contacts, or people through which the message has come. This can be a "contact's" name in the way the node, or person, propagating the information, wishes to use it. As for the owner, this could correspond to a formal definition, or colloquial, such as honorific & surname, or nickname, or patronymic. The contact receiving the message could "translate" the labels in the history to their desired label, and propagate it on. As, mentioned, a user can drop / edit the history, should they desire. Also it is not expected that the history gets too long due to the "Chinese whisper" effect rendering long histories inappropriate. Each contact will have some kind of time stamp, indicating when the data passed through that contact.

The time aspect can be represented through metadata but can conveniently be implemented in terms of a value that varies between 0 (no longer valid) and 1 (valid). Accordingly, the data can start off with no value, increase to a value between 0 and 1 and then decrease to 0 again. This would, for example, be the case when credit card info is initially issued by the supplier and then lapses contractually after a predetermined period of time. It will be appreciated that a null time stamp is not the same as zero but implies that the message does not have a time dimension.

In Figure 1, the probability of a message having value between to and ti is indicated as being certain; otherwise the data is of no value. In addition, a timestamp corresponding to when the data was created, as well as the time system e.g. UTC, can be provided.

The location aspect can be in the form of coordinates, (such as GPS coordinates) or can be colloquial, such as "at home", or the like, for example. An important aspect of the data model is to marry similar, but slightly different, data fields. For example, "First Avenue" and "First Street" and "First Straat" and "First St." may or may not be the same. The way these values are interpreted can be through an optional "personality" module.

As mentioned, the method of the invention can employ context of a geographical and temporal location or to its colloquial or localized use, such as, "work" or "bedtime", for example. In addition, the context can be extended to include social context. The social context information can be represented through three independent axes. These axes can be "friend", "family" and "work", for example.

For example, a person giving you information may be a close friend and a distant family member. The node may choose to propagate the information to a node that can be associated with an ordinary work colleague and spouse. Whatever the case, context information is mixed and matched before, during or after exchange of the payload message. Therefore a security application may demand that the information is reconciled before the message is transferred, and an enterprise server application may choose to query this information asynchronously, while a web interface may do this querying interactively.

The sender can decide that information has a business and personal character. The sender can then select the "business character" to be 0.7, the "personal (friend) character" to be 0.6 and the "family character" to be zero. This can be represented by frf_a b = (0.6,0.0,0.7). Here the values are real numbers that lie between [0,1]. A value of zero represents no affinity; a value of 1 represents the full affinity.

The value (probability of veracity) aspect can be set to reflect the value the user assigns to the data. This is purely relative. This parameter can be conditional, that is it may be the apriori component of a probability according to Bayes's Theorem, for example.

The context data can be represented in terms of a self describing structure. Such a structure can include a header which informs a user what form the information is in, as well as an associated manifest.

A typical example in pseudo-code is indicated in Figure 2 of the drawings. Assuming that the context is executed in xml, the xml is then encoded using a WBXML function. This results in a textual data stream. In this way the mote of context data can be associated with information such as a message. This information can be rendered accessible in other applications. Now we need to associate the context mote with the message.

Hand-over, or transmission, of a message with its context mote can occur in several ways. One way is by means of is a direct request, such as

BusinessCard be = peer. GetBusinessCard (mycontext);

Here we assume that you agree that it really is "me" and I agree that "you" are who "you" claim to be. In this instance the digest is null.

When used in security applications, the context information can be used to grant limited access. For example, a mobile phone user may be given access to another user's calendar based primarily on their reported MSISDN, but then the secondary information (context mote) can kick-in around the fact that their name appears in that user's contacts, and the request is being made at a reasonable time of day and from a reasonable location (for example not from the University of Turkey at 3 am.)

In another example, let us say I received a message from a trusted friend. Assuming I choose to relay the information to a vague business acquaintance. Why I should do this is not relevant here; I may elect to do so for some reason or I have been mandated to do so by some system. The recipient, in this case, however, regards me as a trusted business acquaintance and therefore increases the message's value before passing it on in our peer network. If the recipient had not had any association with me ifjb = 0) then they may have chosen not to relay the information.

Transmission, or propogation, of the message with the context mote will now be described. Generally speaking, the context is imbued on this mote through metadata, such as, {data, key) + (key, context), (data, context), and (data, UID).

In the first case data and context are transmitted separately, for example through an http X-header. The data and context are then reunited at the application. In the second case the context is added in the data. In the third case the user identifies themselves with the server and the server maintains a repository of context. Here is an example where context is not carried with the data (this works for a closed system) or through metadata.

Although it is possible to randomly edit the context data, conveniently rules are provided that permit an orderly propagation of the context data through the network. These rules can include simple conventions, such as, the fact that history information should only be appended to the list, for example.

It is also possible for applications to derive transitive relationships such as a friend of a friend is my friend.

It is up to the application to try and match alternative representations of context. For example GPS co-ordinates lying in a certain region correspond to "home".

Granularity of information is the size a message must be before it gets a context mote. Typically, what is chosen to be imbued with context is application dependent. A rule of thumb is that the message should be complete and consistent. By complete is meant that a non-trivial feature is described in sufficient detail to convey the expected description and contain information that does not contradict itself. Another rule of thumb is that the message should exceed the context mote in size. In addition, the context mote should not be so complex so as to inhibit the message from getting through, or being successfully transmitted.

Examples of implementations of the invention now follow.

In a dotmobi system, for example, a mobile phone typically sends information to a web server as http. Context information of the user is assembled at the server, through whatever a WAP gateway, for example, permits. In some systems users do not authenticate themselves in a tangible way. For example, Google™ uses social engineering to associate an account with a real person, such as by determining their geo location. For the sake of example, assume that a user authenticates him or herself. The user is then provided with mail, calendaring information, and the like, for example, based purely on a data profile that has been generated for them (for example MSISDN) and comparing the data profile with data which the system already has. In passing the context information onto other systems, the application on the web server can assemble the context information more formally, as described above.

In the example provided above, say the NHS data is provided with a context mote attached. Typically, it is not known if the mote is valid. However, with non- trivial information in the mote, you can trace it back. This investigation is up to the receiver of the information, or the application, as the case may be. Typically, one task is to decide whether the context is true and valid. The context mote gives you a formal way of giving the data context.

Further enterprise systems can decide whether to forward content to a client (phone) based on context. For example, in the case of mail push applications, the phone periodically synchronizes with a mail server. A context based application on the mail server could decide through knowledge of the user's calendar and location whether to push emails to them. The application would know the information either through context information obtained from the phone through the context mote during synchronizing, or through assembling this context based on domain knowledge (i.e. access to corporate calendars).

A particular application of the data model of the invention, is where information systems interact (through people) with the infra-structure. For example, someone wants to receive on their phone the next three trains to Cape Town (that is platform and time). The originating request contains the location and the time through manual input or some location based service (LBS), plus the device timestamp. The particular information provider, say Cape Metro, for example, gets the information which it requires (i.e. time, location and implicitly the data return format). Cape Metro may be interested that the request is being referred from the MWEB ISP. (Here the context information is being provided in an implicit vehicle.) If the ISP is running a context enable service, they can do things such as ensure that the time envelop of the request is still valid. The information provider (Cape Metro) identifies the station from the location and returns the information as requested, as an xml dataset, for example. Accordingly, the data model of the invention permits users to convey electronically the context of information in a way that is susceptible to exchange. Although applications of the data model have also described for use in filtering, interaction with infrastructure, security and dotmobi transactions, it will be appreciated that the data model is not limited to use in such applications only. The model does not greatly extend the data footprint, nor rely on enhanced CPU power.

Claims

Claims:

1. A method of transmitting digital information, the method including: creating digital information at a node, the digital information being arranged to be transmitted to another node; linking context information to the digital information; transmitting the digital information from the node to the other node; and enabling the other node to determine an appropriate response upon receiving the digital information, by means of the context information.

2. The method of transmitting digital information as claimed in claim 1, in which linking context information to the digital information includes linking context information including a time of creation of the digital information.

3. The method of transmitting digital information as claimed in claim 1 or claim 2, in which linking context information to the digital information includes linking context information including a location at the node to the digital information.

4. The method of transmitting digital information as claimed in any one of the preceding claims, in which linking context information to the digital information includes linking context information including an owner of the digital information.

5. The method of transmitting digital information as claimed in any one of the preceding claims, in which linking context information to the digital information includes linking context information including a destination for the digital information to the digital information.

6. The method of transmitting digital information as claimed in any one of the preceding claims, in which linking context information to the digital information includes linking context information including a manifest to the digital information.

7. The method of transmitting digital information as claimed in any one of the preceding claims, in which linking context information to the digital information includes linking context information including a social network context of the digital information to the digital information.

8. The method of transmitting digital information as claimed in any one of the preceding claims, in which enabling the other node to determine an appropriate response upon receiving the digital information by means of the context information includes enabling the other node to compare the context information with predetermined parameters, to forward the digital information together with the context information to a next node should the context information comply with predetermined parameters and to dump the digital information together with the context information should the context information fail to comply with the predetermined parameters.

9. The method of transmitting digital information as claimed in claim 8, in which enabling the other node to compare the context information with predetermined parameters and to forward the digital information together with the context information to a next node should the context information comply with predetermined parameters includes enabling the other node to modify the context information.

10. The method of transmitting digital information as claimed in claim 9, in which enabling the other node to modify the context information includes enabling the other node to add history of the passage of the digital information to the context information.

11. The method of transmitting digital information as claimed in any one of the preceding claims, in which enabling the other node to determine an appropriate response upon receiving the digital information by means of the context information includes enabling the other node to compare the context information with predetermined parameters and to transmit an appropriate response to the node, the appropriate response being determined by considering the context information.

12. A digital information transmission system including: a node having instructions for creating digital information to be transmitted to another node; instructions for linking context information to the digital information; another node operatively connected to the node so as to receive transmitted digital information from the node; and instructions for enabling the other node to determine an appropriate response upon receiving the digital information from the node, by means of the context information.

13. The digital information transmission system as claimed in claim 12, in which the instructions for linking context information to the digital information includes instructions for linking context information including a time of creation of the digital information.

14. The digital information transmission system as claimed in claim 12 or claim 13, in which the instructions for linking context information to the digital information includes instructions for linking context information including a location at the node to the digital information.

15. The digital information transmission system as claimed in any one of claims claim 12 to 14 inclusive, in which the instructions for linking context information to the digital information includes instructions for linking context information including an owner at the node to the digital information.

16. The digital information transmission system as claimed in any one of claims claim 12 to 15 inclusive, in which the instructions for linking context information to the digital information includes instructions for linking context information including a destination for the digital information to the digital information.

17. The digital information transmission system as claimed in any one of claims claim 12 to 16 inclusive, in which the instructions for linking context information to the digital information includes instructions for linking context information including a manifest to the digital information.

18. The digital information transmission system as claimed in any one of claims claim 12 to 17 inclusive, in which the instructions for linking context information to the digital information includes instructions for linking context information including a social network context of the digital information to the digital information.

19. The digital information transmission system as claimed in any one of claims claim 12 to 18 inclusive, in which the instructions for enabling the other node to determine an appropriate response upon receiving the digital information from the node by means of the context information includes instructions enabling the other node to compare the context information with predetermined parameters, to forward the digital information together with the context information to a next node should the context information comply with predetermined parameters and to dump the digital information together with the context information should the context information fail to comply with the predetermined parameters.

20. The digital information transmission system as claimed in any one of claims claim 12 to 19 inclusive, in which the instructions for enabling the other node to forward the digital information together with the context information to a next node should the context information comply with predetermined parameters includes instructions for enabling the other node to modify the context information.

21 The digital information transmission system as claimed in claim 20, in which the instructions for enabling the other node to modify the context information includes instructions for enabling the other node to add history of the passage of the digital information to the context information.

2. The digital information transmission system as claimed in any one of claims claim 12 to 21 inclusive, in which the instructions for enabling the other node to determine an appropriate response upon receiving the digital information from the node by means of the context information includes instructions enabling the other node to compare the context information with predetermined parameters and to transmit an appropriate response to the node, the appropriate response being determined by considering the context information.