WO2008143531A1 - Messaging system - Google Patents

Messaging system Download PDF

Info

Publication number
WO2008143531A1
WO2008143531A1 PCT/NZ2008/000115 NZ2008000115W WO2008143531A1 WO 2008143531 A1 WO2008143531 A1 WO 2008143531A1 NZ 2008000115 W NZ2008000115 W NZ 2008000115W WO 2008143531 A1 WO2008143531 A1 WO 2008143531A1
Authority
WO
WIPO (PCT)
Prior art keywords
key
messaging
message
address
messaging client
Prior art date
Application number
PCT/NZ2008/000115
Other languages
French (fr)
Inventor
David Gray Hughes
Suzanne Sullivan
Original Assignee
Turner Technologies Limited
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Turner Technologies Limited filed Critical Turner Technologies Limited
Publication of WO2008143531A1 publication Critical patent/WO2008143531A1/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/083—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0435—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/061—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/061—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying further key derivation, e.g. deriving traffic keys from a pair-wise master key

Definitions

  • the present invention relates to transferring messages between nodes in a communications system.
  • it relates to transferring messages in a communications system in manner to reduce the inconvenience of receiving unsolicited messages.
  • Various messaging systems are well known for transferring messages between interconnected nodes in a system or network.
  • users of a networked computer system can send emails to each other to communicate information.
  • the computer system will comprise a number of nodes in the form of computers all interlinked by a communications network.
  • Email software
  • each node is in the form of a handheld telephone device or similar that operates software and hardware to enable users to enter messages via a keyboard or other means and transfer the messages between each other.
  • messages which convey, for example, information the form of text, voice, multimedia or other formats
  • the present invention may be said to consist in a method for transferring a message in a system between a first messaging client associated with a first messaging address and second messaging client associated with a second messaging address, the method comprising the steps of: transferring a first key and first messaging address from the first messaging client to a key generator, transferring the first key and second messaging address from the second messaging client to the key generator, generating a second key after receiving the first key from at least one of the first and second messaging agents, associating the second key with the first messaging address and the second messaging address transferring the second key to the first messaging client after receiving the first key from the first messaging client, transferring the second key to the second messaging client after receiving the first key from the second messaging client, and transferring a message from the first messaging client to the second messaging client, the message comprising or being associated with the second key and the message comprising or being associated with the first messaging address.
  • the first key is exchanged between the first and second messaging clients, or between users of the first and second messaging clients.
  • the first key is a temporary key.
  • the second key is stronger than the first key.
  • the method further comprises the second messaging client: receiving the message, and providing access to the message if it is determined that the message is not an unsolicited message, the second messaging client determining that the message is not an unsolicited message by retrieving the second key and first messaging address comprised within or associated with the message, and checking that the second key is associated with the first messaging address.
  • the system can be a computer network, telecommunications network or the like.
  • the message can be a text, email, voice, multimedia or other type message.
  • the messaging client can be operated on a node in the system, such as computer, telecommunications device or the like.
  • the second key and each messaging address form a private address structure. If an address structure is compromised and used by an unauthorised party to send unsolicited mail to the second messaging client, the second messaging client can subsequently disable the private address structure, such that further messages received with the second key and first messaging address forming the private address structure with not be provided to the user.
  • the present invention may be said to consist in a system comprising a plurality of messaging clients operating on nodes, each messaging clients associated with a respective messaging address and enabling the node to operate as a sender or receiver node, the system further comprising a key generator, the system being adapted to transfer a message between a pair of messaging clients by: receiving at the key generator a first key from a first messaging client and a second messaging client, the fkst and second messaging clients having respective fkst and second messaging addresses, generating a second key on the key generator after receiving the fkst key from at least one of the first and second messaging clients, the key generator associating the second key with the first messaging address and the second messaging address, transferring the second key from the key generator to the first messaging client after receiving the first key from the fkst messaging client, transferring the second key from the key generator to the second messaging client after receiving the fkst key from the second messaging client, and transferring a message from the fkst messaging client to
  • the fkst key is exchanged between the first and second messaging clients, or between users of the fkst and second messaging clients.
  • the second messaging client is adapted to receive the message, and provide access to the message if it is determined that the message is not an unsolicited message, the second messaging client determining that the message is not an unsolicited message by retrieving the second key and fkst messaging address comprised within or associated with the message, and checking that the second key is associated with the fkst messaging address.
  • the system can be a computer network, telecommunications network or the like.
  • the message can be a text, email, voice, multimedia or other type message.
  • the node could be a computer, telecommunications device, or the like.
  • the present invention may be said to consist in a method for transferring a message in a system between a fkst messaging client associated with a fkst messaging address and second messaging client associated with a second messaging address, the method comprising the steps of: transferring a fkst temporary key and a fkst and second messaging address from the a thkd messaging client to a key generator, generating a fkst strong key after receiving the fkst temporary key, associating the fkst strong key with the fkst messaging address and the second messaging address, wherein the first strong key is used for transferring a message between the first messaging client and the second messaging client.
  • the method further comprises: transferring a message between the first messaging client and the second messaging client using the first strong key, the message comprising a second temporary key, transferring the second temporary key and first messaging address from the first messaging client to a key generator, transferring the second temporary key and second messaging address from the second messaging client to the key generator, generating a second strong key after receiving the second temporary key from at least one of the first and second messaging clients, associating the second strong key with the first messaging address and the second messaging address transferring the second strong key to the first messaging client after receiving the second temporary key from the first messaging client, transferring the second strong key to the second messaging client after receiving the second temporary key from the second messaging client, and transferring a message from the first messaging client to the second messaging client, the message comprising or being associated with the second strong key and the message comprising or being associated with the first messaging address.
  • the present invention may be said to consist in a messaging client for use on a node in a system, the messaging client being associated with a first messaging address and being adapted to operate the node as a sender to communicate messages to another node on the system,. the messaging client further being adapted to: transfer a first key and the first messaging address to a key generator, receive a second key from the key generator, the second key being generated by the key generator in response to receiving the first key and the second key being associated with the first messaging address, and transfer a message from the first messaging client to a second messaging client, the message comprising or being associated with the second key and die message comprising or being associated with the first messaging address.
  • the present invention may be said to consist in a messaging client for use on a node in a system, the messaging client being associated with a first messaging address and being adapted to operate the node as a receiver to receive messages from another node on the system, the messaging agent further being adapted to: transfer a first key and a first messaging address to a key generator, receive a second key from the key generator, the second key being generated by the key generator in response to receiving the first key and the second key being associated with a second messaging address associated with a sender messaging client, and receive a message comprising or being associated with a key and the message comprising or being associated with a sender messaging client's messaging address, wherein the messaging client provides a user of the messaging client with access to the received message if the sender messaging client's messaging address is the second messaging address and the security key is the second key associated with the second messaging address.
  • the present invention may be said to consist in a method for sending a message in a system from a first messaging client associated with a first messaging address to a second messaging client associated with a second messaging address, the method comprising the steps of: transferring a first key and the first messaging address to a key generator, receiving a second key from the key generator, the second key being generated by the key generator in response to receiving the first key and the second key being associated with the first messaging address, and transferring a message from the first messaging client to the second messaging client, the message comprising or being associated with the second key and the message comprising or being associated with the first messaging address.
  • the present invention may be said to consist in a method for receiving a message in a system at a second messaging client associated with a second messaging address from a first messaging client associated with a first messaging address, the method comprising the steps of: transferring a first key and a second messaging address to a key generator, receiving a second key from the key generator, the second key being generated by the key generator in response to receiving the first key and the second key being associated with the first messaging address associated with the first messaging client, and receiving a message comprising or being associated with a security key and the message comprising or being associated with a sender messaging client's messaging address, wherein the second messaging client provides a user of the second messaging agent with access to the received message if the sender messaging client's messaging address is the first messaging address and the security key is the second key associated with the first messaging address.
  • the present invention should not be limited to any format or type of messaging. While the present invention is described in relation to email messages sent on a computer network and also text messages sent on a mobile telephone communications network, it is possible for the invention to be implemented in any type of system in which messages of any type are forwarded or transferred between nodes.
  • Figure 1 is a block diagram of a generic network comprising a plurality of communicating nodes, on which the invention could be implemented,
  • Figure 2 is a block diagram showing a possible private address structure
  • Figures 3 and 4 are a block diagram and flow chart of the private address structure generation process, including key generation, in accordance with a first embodiment
  • Figure 5 is a block diagram of two interconnected nodes that are communicating in accordance with the invention
  • Figure 6 is a flow diagram of the communication process between two nodes
  • Figure 7a is a block diagram of a message frame structure of a message sent in accordance with the invention
  • Figure 7b is a block diagram showing the inbox, outbox and deleted messages field of a messaging client
  • Figure 7c is a block diagram indicating die message structure
  • Figure 8 is a block diagram showing node relationships for private address structure generation in accordance with a second embodiment
  • Figures 9 and 10 are a block diagram and flow chart showing the private address structure generation process in accordance with a second embodiment.
  • a preferred embodiment of die present invention relates to a method and system for facilitating communication of messages between nodes in a messaging system.
  • the messaging system might be provided specifically for messaging.
  • the system might have several purposes or functions, of which transferring messages is one function or purpose.
  • the present invention may also relate to messaging software that can reside on one or more nodes in a messaging system to facilitate communication of messages between nodes..'The system, method and messaging software, for example, could be for transferring email or other electronic type messages in a computer system.
  • the system, method and messaging software could be for transferring text, voice, multimedia or other messages between mobile devices in a mobile telephone network.
  • the invention can be used as a means to facilitate a closed email system by use of a private address structure (comprising private address pairs') that forms a communications relationship between two nodes, or more particularly two messaging clients operating on a respective node.
  • the private address structure is utilised to provide communication of messages between nodes sharing a communicadons relationship. This reduces die likelihood of receiving unsolicited mail, such as spam, as the receiving party will not generally have a relationship with an originating node from which the spam is sent.
  • users of one or both of the nodes can simply destroy or disable the communications relationship to prevent any communications coming from that node. All other relationships with all other nodes could still operate in the normal manner.
  • FIG. 1 shows a generic system 10 in which die invention may be implemented in accordance with a preferred embodiment.
  • a system 10 comprises a network of interconnected nodes e.g. 1, Ia- If.
  • the system 10 is preferably formed as an ad hoc structure of peer-to-peer connections of nodes 1, Ia-If each capable of supporting communication.
  • the nodes 1, Ia-If are interconnected by any suitable communications network to allow transfer of information between the nodes.
  • Each node 1, Ia-If is configured and operates software to facilitate communications in accordance with the invention. This configuration of software will be described with the reference to node 1, but it will be appreciated that each of the other nodes Ia-If in the system would be configured in a similar manner.
  • the node 1 operates a messaging client 4 that is adapted to store, send and receive messages. This could be, for example an email client or similar, or a text messaging cEent, depending on the nature of the messaging system. As will be appreciated by those skilled in the art, other types of messaging clients could be used for other types of messaging systems.
  • the node 1 also operates a delivery agent 2 that is used by the messaging client 4 to transmit a message to another messaging client (not shown) operating on another node eg. Ia-If in the system 10.
  • the delivery agent 2 transfers a message from a sender to a recipient node by transversing through intermediate nodes.
  • the node 1 also operates an intermediate carrier 5 that is used to launch the delivery agent 2 on the recipient node.
  • the delivery agent is an electronic scout.
  • the software in each client contains the permanent IP address of the Reference Management System Computer (RMS).
  • RMS Reference Management System Computer
  • the Client computer links to the RMS through the IP address and this transfers the client IP Address to the RMS. This is then monitored by the RMS for any changes as the client logs in and out of the internet.
  • Electronic scouts (Tike a ping to an IP address) determine the best and fastest method through the internet for message and file transfer.
  • a key generator 3 is also provided to generate private address pairs.
  • the private address pairs form part of the private address structure to define a communications relationship between two nodes that permits communication of messages between tiiose two nodes.
  • the delivery agent 2, messaging client 4 and intermediate carrier 5 operate on a platform 7 that supports the private address structure based communication.
  • a governance layer 6 provides the interface for communications between the software agents /clients 2, 3, 5 and the platform 7.
  • delivery agent 2 messaging agent 4, intermediate carrier 5, governance layer 6 and platform 7 are executed as software on the node 1, although they could be implemented -in any other suitable manner.
  • Figure 1 shows a generic a system 10 in which the invention may be implemented.
  • the invention may be implemented in any type of system with nodes interconnected via a communications system.
  • the nodes may be computers that are interconnected on a local or wide area network.
  • the nodes might be handheld mobile devices communicating in a mobile or other telecommunications network.
  • the invention could be implemented in any other type of node based network also.
  • the messages transferred in such a system could be in the form of text, voice, multimedia or any other suitable content format.
  • the invention enables communication relationships to be set up between node pairs (or more specifically, the messaging clients running on those node pairs) in the form of a private address structure.
  • the private address structure defined for a node pair allows for communication between the nodes in that pait via their respective messaging clients.
  • the private address structure regime enables a messaging client running on a node to filter or block an incoming message that comes from a node for which there has been no previously established communications relationship.
  • Figure 2 shows a private address structure 20 that is implemented on a messaging client 4.
  • the private address structure 20 defines a communications" relationship with another messaging • client operating on another node.
  • the private address structure 20 in its simplest form preferably comprises a recipient messaging client locator 26 and a sender messaging client locator 27.
  • the messaging client locators 26 and 27 are also referred to as a messaging address.
  • the locator or messaging address is a piece of information that enables the respective messaging client's node to be physically and logically located on a network, to enable transfer of data to that node. It could be, for example, in the form of an email address (in the case of an email messaging system) or a telephone number (in the case of a mobile telephone text messaging system) or some other format for other messaging systems.
  • the recipient messaging client is identified by way of the messaging address 26 (such as an email address, or a telephone number) that is stored as a recipient messaging client locator 26 in a recipient messaging client locator field 21.
  • the sender messaging client identification which is in the form of a messaging address, is stored as a sender messaging client locator 27 in a sender messaging client locator field 22.
  • the private address structure 20 also comprises a verification key 23 that is shared between the recipient messaging client and the sender messaging client.
  • the verification key 28 is stored in a verification key field 23.
  • the private address structure 20 also defines a human readable description or identifier, 29, 30 of both the recipient and the sender. This may be in the form of a name, label or other identifier that identifies the user of the sender and recipient messaging clients respectively.
  • a user can easily select the desired recipient using the human readable identifier 29.
  • the messaging address 26 and other required information to send a message to the recipient node/messaging client is associated with the recipient human readable identifier 29.
  • the human readable identifier 30 can easily advise the receiver who the sender was.
  • the human readable recipient identifier 29 is stored in a human readable recipient identifier field 24.
  • the human readable sender identifier 30 is stored in a human readable sender identifier field 25.
  • sender and recipient nodes can change their functions.
  • a node running a messaging client that operates as a recipient node for a first communication, can operate as a sender node in another communication.
  • the private address structure 20 shown in Figure 2 could be expanded or adapted to utilise a more complex form for the verification key, such as a public/private key encryption system. Other aspects to the private address structure could also be provided as required.
  • Each node 1, Ia-If on a network can hold a plurality of private address structures 20, each relating to a communication relationship with a different respective node 1, Ia-If on the network.
  • Figures 3 and 4 show a schematic diagram and flow chart respectively indicating how a private address structure defining a communications relationship between two nodes is generated. In particular, it shows how the verification key for that private address structure is generated.
  • Figures 3 and 4 show private address structure generation in accordance with the first embodiment of the invention.
  • a private address structure generation process in accordance with the second embodiment of the invention is shown in Figure 9 and 10.
  • step 40 First of all the users of nodes 1 and Ic, exchange a temporary key, step 40.
  • This method allows a weak temporary key to be used in environments where a strong key would be cumbersome to reproduce and be prone to generating errors.
  • a weak key refers to a key that might be more easily "cracked" or guessed than a strong key.
  • the private address structure generation mechanism involves an alternative route to transmit the initial temporary key.
  • a user would be able to create a private relationship with another user by scribbling a short number (weak key) twice on two sheets of paper — one for each party wanting to set up a communications relationship.
  • a key could be exchanged through another email or mobile telephone channel (as appropriate), or any other suitable channel.
  • the temporary key is then communicated to the messaging client 4, 4c of each respective node 1, 1c.
  • each respective messaging client 4, 4c sends the temporary key along with its respective messaging address to a strong key generator 30, step 41.
  • Each messaging address provides a logical/physical location on the network of the respective messaging client 4, 4c.
  • the temporary key/messaging address combination might not be sent from each node 1, 1c simultaneously. Rather, the messaging client 4, 4c of each node 1, 1c might send the temporary key and its respective messaging address at different times.
  • the strong key generator 3 independently receives the temporary key and respective first/second messaging addresses from the first/second messaging clients 4, 4c over a suitable network or communications channel.
  • the strong key generator 3 then generates a permanent verification strong key 28 using the received weak key, step 43. .
  • the strong key generator 3 then associates the strong key with both the first messaging address and the second messaging address. For example, it might do so by storing the strong key and the first and second messaging addresses respectively in a database. Once the strong key generator has received the temporary key and respective messaging address from a respective messaging client 4, 4c it responds by sending the strong key back to that messaging client- 4, 4c, step 44, 45. As noted earlier, the strong key generator 4 might not receive this information from the messaging clients 4, 4c simultaneously. For example, it may receive the temporary key and first messaging address from the first messaging client 4 initially] In this case, the generator 3 will generate the strong key and associate it with the first messaging address, and then return the strong key to the first messaging client 4, step 44. When it later receives the temporary key and second 5 messaging address from the second messaging client 4c, it will associate the second messaging address with the already generated strong key, and return the strong key that has previously been generated to the second messaging client 4c, step 45.
  • the two parties know when a connection is made by a green dot appearing in your address book for the attempted connection and the status changing from pending to active.
  • the private address structure (the IP address) is administered and updated by the reference management system.
  • 4c generates the private address structure using the strong key (which becomes the verification key 28), step 46. It will also include in the private address structure the messaging address 26 or 27 from the corresponding messaging client 4 or 4c, along with its own messaging address, and along with human readable forms of both its own and corresponding messaging
  • the user of the first node 1 intends to send a message to the user of the second node Ic.
  • the user of node 1 prepares a message using the sender messaging client 4, step 60.
  • the message may comprise one or more of text, voice, still or video images, or any other multimedia content as supported by the messaging client and communications network.
  • the node 1 has input and output devices that
  • Figure 7a-7c show a possible form of the structure of the message 74.
  • Figure 7a shows the message frame 70 that contains the message 74 as sent (or as received).
  • the private address structure list field 71 holds a list of private address structures 71a that identify a list of recipients for
  • the private address structure list 71a will only include one private address structure 20, namely mat private address structure associated with the relationship between the sender messaging client 4 and the recipient messaging client 4c.
  • the message delivery tithe field 72 holds the message delivery time 72a (once the message is delivered).
  • the message delivery time 72a contains an environment specific time coding for the moment that the message was delivered by the sender delivery agent 2 shown in Figure 1.
  • the message field 73 contains the actual message 74, which can be of any structure and suitable content as described earlier.
  • Verification Key Field 23 is left blank for all Private Address Structures in the Private Address Structure-List of Figure 2 to prevent the Recipient Messaging Client from illegitimately forging relationships with other messaging clients on the Private Address Structure List.
  • Figure 7b shows the message frames stored by the messaging client, e.g. 4. The message client
  • an inbox list field 76 comprising an inbox list 76a, which comprises a number of message frames 70a-70c, which are of the same structure of the message frame 70 shown in Figure 7a.
  • Each message frame 70a-70c corresponds to a message e.g. 74 that'has been received from another node.
  • the message client 4 contains an outbox list field 77, comprising an outbox list 77a with a range of message frames 70d-70f relating to sent messages.
  • a deleted messages list field 78 comprising a deleted messages list 78a which comprises a number of message frames 70g-70i relating to messages that have been deleted by the user of the messaging client 4.
  • the user may at any point delete a message from either the inbox list 76 or outbox list 77. To do this, the set reference to the message frame 70 is removed and reinserted into the rightmost position of the deleted messages list 78 simultaneously. A further valid action by the user is to permanently delete all deleted messages. In this case all children are removed from the deleted message list. • • ⁇
  • Each message 74 and its message field 73 of the message frame 70 has a structure as shown in Figure 7c.
  • the message comprises an XML content field 79 containing XML content 79a.
  • the XML content could be any suitable text and/or other multimedia content. It will be appreciated that this is by way of example only, and the content field could be stored in any other suitable format.
  • the message 74 also comprises a file attachments list field 80 which comprises a file attachments list of one or more file attachments 80b, of which only one is shown in the present case. There may be a number of file attachments. Again, these could be any suitable text and/or multimedia content in any suitable format.
  • Figure 7c shows an exemplary message format where an XML message can be transmitted with multiple files.
  • the message can be structured using XML, allowing it to display HTML that includes graphics and fonts in a generic format.
  • XML also allows for any number of other formats providing the software application can understand these formats.
  • attachments could theoretically be inserted as part of the XML schema, they are separated here in the File-Attachments-List-Field 80 for the purpose of clarity.
  • the XML-Content 79a is affixed directly to the XML-Content and each • attachment is affixed to a unique File-Attachment 80b set. '
  • the user selects the desired recipient messaging client 4, which is operating on the desired recipient node 1. The user does this by selecting the human readable recipient identifier 29 ⁇ f the desired recipient as defined in the private address structure 20.
  • the user can instruct the sender messaging client 4 to transmit the message to the recipient messaging client 4c as indicated by. or selected by the human readable recipient identifier, step 60.
  • the created message can be sent to the recipient node in any suitable manner supported by the communications network on which the communicating nodes are operating.
  • the sender messaging client 4 needs to draw on local network resources to locate the recipient messaging client 4c — such as routing services that can provide navigational data on the network 10.
  • the navigational data is delivered from a query founded on the recipient messaging client locator 26 that contains sufficient data to identify the recipient on the network. As the delivery agent 2 propagates across the grid network, it is responsible for destroj'ing unnecessary copies of itself as well as funding all network resources utilised.
  • the sending messaging client 4 sends a sender delivery agent 2 to the recipient messaging agent 4c on the recipient node 1 c.
  • the sender delivery agent 2 delivers the message 74 to the recipient messaging client 4c and then returns to the sender messaging client 4 on the sender node 1. This verifies that the message 74 was received by the recipient node Ic.
  • the delivery agent 2 may deliver the message either direcdy to the recipient node Ic or via one or more intermediate nodes, for example Ia as shown in Figure 3. If the sender delivery agent 2 fails to return within a reasonable length of time, then the sender messaging client 3 will assume the message did not reach its destination and will resend the message via a new sender delivery agent 2. In this regime, it is possible that the sender delivery agent will arrive and attempt to deliver the message again. In this case the recipient messaging client should indicate that the message has already been delivered.
  • the sender delivery agent 2 can leave a series of sender intermediate carriers (for example 5 on intermediate node Ia) on each node visited as it propagates through to the recipient node Ic. It does this by effectively not deleting any of its old copies on route.
  • the sender intermediate carrier 5a is able to relay information across a chain between the recipient node Ic and the sender node 1. This method has the advantage over the previous method that verification of message delivery is substantially immediate.
  • the sender delivery agent 2 protects the verification key 28 from malicious nodes that may wish to utilise the verification key 28 for sending messages to the recipient node Ic.
  • the sender deEvery agent protects the verification key 28 by carefully selecting the nodes through which it transits to the recipient node Ic, or otherwise the verification key is encrypted on all nodes except the final connection point, being the recipient node Ic.
  • the sender delivery agent transfers the message, the next step is for the recipient node Ic to receive the message, step 62.
  • the sender delivery agent 2 reaches the recipient node Ic, it can communicate directly with the recipient messaging client 4c to deliver the message 79.
  • the recipient messaging client 4c conducts a verification process to ensure that the received message 74 has been received from a permitted sender node. That is, the recipient messaging client 4c checks that the received message 74 has come from a verified node that the recipient node Ic has a communication relationship with.
  • the recipient node Ic To determine if the received message is from a verified sender, the recipient node Ic first strips out the private address structure 20 from the received message frame 70, step 63. From the private address structure, the recipient node Ic can extract the verification key 28 in' the message and the messaging address 26 of the sender node 1. The recipient node Ic then determines if it has stored a private address structure that contains the verification key 28 and the sender messaging address 26 stripped from the incoming message 74, step 64. If the verification key 28 and sender messaging address 26 are associated together and match those specified in a private address structure stored in the recipient messaging client 4c, step 65, then the recipient messaging client 4c will conclude that it has an established communications relationship with the sender messaging agent 4. It will then deem that the incoming message 74 has come from a permitted source and should be accepted.
  • the recipient messaging client 4c does not have a stored private address structure that contains both the received verification key 28 and the sender messaging address 26, step 66, then it will not be able to verify a communications relationship set up between itself and the sender messaging client 4 . This might be because the message has come from a messaging client with which there is not established communications relationship. Alternatively, it could be because the message has come from a messaging address for which there is an established communications • relationship, but the verification- key is incorrect for that relationship. This could imply that the message has actually come from another source, which is illegitimately attempting to "spoof a legitimate source. There could be many other reasons for a "no-match". If there is no match the recipient messaging client 4c will reject the message, step 66.
  • the recipient messaging client 1 c determines that the verification key 28 and sender messaging address 26 match that in a private address structure held by the recipient mail client 4c, then the message is accepted by the recipient messaging client 4c and access is provided to the user, step 65. This causes the sender delivery agent 2 to notify the sender messaging client 4 that the message was delivered and to make the recipient messaging client 4c to store the message for viewing and retrieval by a user.
  • the recipient messaging address 4c verity, via the private address structure 20, whether a message has come from a sender messaging client (eg. Id) with which there is a communication relationship, enables the recipient node Ic and recipient messaging client 4c to manage the influx of unsolicited messaging.
  • the recipient messaging client 4c can identify, step 64, whether a message has come from a verified source node with which it holds a communication relationship. If a received message has not come from such a node, then the message can be identified as unsolicited. This may be due .to a rogue . messaging agent acquiring a verification key and then attempting to send an unsolicited message.
  • a verification key 28 might be acquired by an unauthorised messaging client either by carelessness by the user of the legitimate messaging client or by utilising an insecure communication channel when transmitting the verification key to establish the private address structure.
  • a recipient messaging client 4c has received a message that has been identified as unsolicited, step 66, this indicates to the recipient messaging client 4c that the verification key 28 has been compromised and has been used by a party with which there is no communication relationship set up in respect with that verification key.
  • the messaging client 4c, or user of the messaging client may then decide to destroy the communications relationship with the actual messaging client (i.e. 4) for which the verification key 28 does apply. This is done by destroying the private address structure set up between the recipient messaging client 4c and the corresponding messaging client (e.g. 4), which share the verification key 28. By destroying the private address structure, this does not imply that the recipient node 1 c does not want to receive further communications from the corresponding node (e.g. 1).
  • the node subsequendy When the node subsequendy receives a message that it identifies as unsoEcited, it prevents this being received and passed on to the user. Further, by destroying the relationship and the verification key 28, it prevents further unsoEcited messages coming from that party that has acquired the verification key without authority because the client will reject them.
  • All messages are stored on both the sender messaging client 4 and the recipient messaging client 4c.
  • Each message may be structured as a message frame 70.
  • the message frame 70 may be stored in different areas for the recipient messaging client 4c and the sender messaging client 4. Both the recipient messaging client 4 and the sender messaging client 4c have different copies of the message 74 structure on their appropriate nodes.
  • the recipient mail client 4c stores an incoming message in the rightmost position of the inbox list.
  • the sender mail client 4. stores an outgoing message in the rightmost position of the outbox list.
  • a distributed storage mechanism may be used to replace the above.
  • the distributed architecture can provide redundancy, backup and scalability.
  • a private address structure 20 to define a communications relationship between two nodes can be generated in a different way according to a second embodiment as will be described with reference to Figures 8-10.
  • a private address structure 20 can be generated direcdy with the aid of a third party node.
  • recipient messaging client 4c and messaging client 4a wish to generate a private address structure to establish a communications relationship.
  • messaging client Ic has already established a communication relationship with third party messaging client 1 , and has a respective private address structure for that relationship.
  • messaging client Ia also has a communication relationship with messaging client 1, which has been previously established.
  • messaging clients Ic and Ia can use the assistance of the third party messaging client 1 to assist in creating a private address structure to define a communication relationship between messaging client Ia and messaging client Ic.
  • the new private address structure is created in two stages, as will be described with reference to Figures 9 and 10.
  • the nodes Ia and Ic determine a third party node that they have respective communication relationships with and they wish to use to facilitate the generation of a private address structure, step 100.
  • the third party messaging client is messaging client 1.
  • the third party messaging client 1 sends a temporary key, step 101, along with the messaging • addresses of messaging clients Ia and Ic to a strong key generator.
  • the strong key generator generates a first strong key from the temporary key and associates this with the messaging addresses of the messaging clients Ic, Ia, step 102.
  • a private address structure for establishing a communications relationship between messaging clients Ia and Ic can then be set up in accordance with Figure 2 by using the received first verification (strong) key and the respective messaging addresses that are received at the third party messaging client 1, step 103.
  • This private address structure 20 is then transferred from the third party messaging client 1 to the messaging clients Ia, Ic, step 104.
  • This private address structure 20 is stored in the respective messaging clients Ia, Ic.
  • the private address structure can then be used to facilitate communication between messaging clients Ia and Ic, step 103.
  • step 2 messaging clients Ia, Ic use their temporary private address structure to communicate a second temporary key which the users of messaging clients Ia, Ic decide upon, step 105. Using the second temporary key the first and second messaging clients Ia, Ic can then create their own permanent private address structure, step 106, in the usual way as described in relation to Figures 3 and 4.
  • each messaging client Ia, Ic sends its messaging address and the second temporary key to a key generator 4 and the key generator 4 generates a second (strong) verification key and associates this with the messaging addresses of messaging client Ia, Ic, and sends the second verification strong key back to the respective messaging clients Ia, Ic.
  • the respective messaging clients Ia, Ic can tiien store the private address structure 20 that can be used for communication between the two messaging clients.
  • the strong verification key strong key 2 will be unknown to the third party messaging client 1.

Abstract

The present invention relates to a method and system that can be used as a means to facilitate a closed email system by use of a private address structure 20 (comprising private address pairs ) that forms a communications relationship between two nodes e.g. 1, 1c, or more particularly two messaging clients e.g.4, 4c operating on a respective node 1, 1c. The private address structure 20 is utilised to provide communication of messages 74 between nodes 1, 1c sharing a communications relationship. This reduces the likelihood of receiving unsolicited mail, such as spam, as the receiving party e.g. 1c will not generally have a relationship with an originating node e.g 1 from which the spam is sent.

Description

MESSAGING SYSTEM
FIELD OF THE INVENTION
The present invention relates to transferring messages between nodes in a communications system. In particular, it relates to transferring messages in a communications system in manner to reduce the inconvenience of receiving unsolicited messages.
BACKGROUND OF THE INVENTION
Various messaging systems are well known for transferring messages between interconnected nodes in a system or network. For example, users of a networked computer system can send emails to each other to communicate information. Typically, the computer system will comprise a number of nodes in the form of computers all interlinked by a communications network. Email software
(clients) are' executed on each of the nodes to allow for creation, receiving, transferring and reading of emails. Similarly, in a mobile telephone communications network, users can send text messages, voicemails or other message types to communicate information. In this type of system, each node is in the form of a handheld telephone device or similar that operates software and hardware to enable users to enter messages via a keyboard or other means and transfer the messages between each other. Many other types of messaging systems are known, wherein messages (which convey, for example, information the form of text, voice, multimedia or other formats) can be transferred between interconnected nodes.
Due to the ease and low cost of transferring messages, such message systems create the problem of unsolicited messages, commonly known as spam. This is where a user will receive messages that are unwanted, generally from parties that they do not know. At best, such unsolicited messages are annoying and inconvenient. Worse, they can be the source of fraud and other criminal activity.
Therefore, it is desirable to have a means by which to at least partially reduce the number of unsolicited messages in a messaging system.
SUMMARY OF INVENTION
It is an object of the present invention to provide a user with the ability to reduce the quantity of unsolicited messages received via a messaging system.
In one aspect the present invention may be said to consist in a method for transferring a message in a system between a first messaging client associated with a first messaging address and second messaging client associated with a second messaging address, the method comprising the steps of: transferring a first key and first messaging address from the first messaging client to a key generator, transferring the first key and second messaging address from the second messaging client to the key generator, generating a second key after receiving the first key from at least one of the first and second messaging agents, associating the second key with the first messaging address and the second messaging address transferring the second key to the first messaging client after receiving the first key from the first messaging client, transferring the second key to the second messaging client after receiving the first key from the second messaging client, and transferring a message from the first messaging client to the second messaging client, the message comprising or being associated with the second key and the message comprising or being associated with the first messaging address.
Preferably, before transferring the first key from the first and second messaging clients to the key generator, the first key is exchanged between the first and second messaging clients, or between users of the first and second messaging clients. Preferably, the first key is a temporary key. Preferably, the second key is stronger than the first key.
Preferably, the method further comprises the second messaging client: receiving the message, and providing access to the message if it is determined that the message is not an unsolicited message, the second messaging client determining that the message is not an unsolicited message by retrieving the second key and first messaging address comprised within or associated with the message, and checking that the second key is associated with the first messaging address.
The system can be a computer network, telecommunications network or the like. The message can be a text, email, voice, multimedia or other type message. The messaging client can be operated on a node in the system, such as computer, telecommunications device or the like. Preferably, the second key and each messaging address form a private address structure. If an address structure is compromised and used by an unauthorised party to send unsolicited mail to the second messaging client, the second messaging client can subsequently disable the private address structure, such that further messages received with the second key and first messaging address forming the private address structure with not be provided to the user. In another aspect the present invention may be said to consist in a system comprising a plurality of messaging clients operating on nodes, each messaging clients associated with a respective messaging address and enabling the node to operate as a sender or receiver node, the system further comprising a key generator, the system being adapted to transfer a message between a pair of messaging clients by: receiving at the key generator a first key from a first messaging client and a second messaging client, the fkst and second messaging clients having respective fkst and second messaging addresses, generating a second key on the key generator after receiving the fkst key from at least one of the first and second messaging clients, the key generator associating the second key with the first messaging address and the second messaging address, transferring the second key from the key generator to the first messaging client after receiving the first key from the fkst messaging client, transferring the second key from the key generator to the second messaging client after receiving the fkst key from the second messaging client, and transferring a message from the fkst messaging client to the second messaging client, the message comprising or being associated with the second key and the message comprising or being associated with the fkst messaging address.
Preferably, before transferring the first key from the fkst and second messaging clients to the key generator, the fkst key is exchanged between the first and second messaging clients, or between users of the fkst and second messaging clients.
Preferably, the second messaging client is adapted to receive the message, and provide access to the message if it is determined that the message is not an unsolicited message, the second messaging client determining that the message is not an unsolicited message by retrieving the second key and fkst messaging address comprised within or associated with the message, and checking that the second key is associated with the fkst messaging address.
The system can be a computer network, telecommunications network or the like. The message can be a text, email, voice, multimedia or other type message. The node could be a computer, telecommunications device, or the like.
In another aspect the present invention may be said to consist in a method for transferring a message in a system between a fkst messaging client associated with a fkst messaging address and second messaging client associated with a second messaging address, the method comprising the steps of: transferring a fkst temporary key and a fkst and second messaging address from the a thkd messaging client to a key generator, generating a fkst strong key after receiving the fkst temporary key, associating the fkst strong key with the fkst messaging address and the second messaging address, wherein the first strong key is used for transferring a message between the first messaging client and the second messaging client.
Preferably, the method further comprises: transferring a message between the first messaging client and the second messaging client using the first strong key, the message comprising a second temporary key, transferring the second temporary key and first messaging address from the first messaging client to a key generator, transferring the second temporary key and second messaging address from the second messaging client to the key generator, generating a second strong key after receiving the second temporary key from at least one of the first and second messaging clients, associating the second strong key with the first messaging address and the second messaging address transferring the second strong key to the first messaging client after receiving the second temporary key from the first messaging client, transferring the second strong key to the second messaging client after receiving the second temporary key from the second messaging client, and transferring a message from the first messaging client to the second messaging client, the message comprising or being associated with the second strong key and the message comprising or being associated with the first messaging address. In another aspect the present invention may be said to consist in a messaging client for use on a node in a system, the messaging client being associated with a first messaging address and being adapted to operate the node as a sender to communicate messages to another node on the system,. the messaging client further being adapted to: transfer a first key and the first messaging address to a key generator, receive a second key from the key generator, the second key being generated by the key generator in response to receiving the first key and the second key being associated with the first messaging address, and transfer a message from the first messaging client to a second messaging client, the message comprising or being associated with the second key and die message comprising or being associated with the first messaging address.
In another aspect the present invention may be said to consist in a messaging client for use on a node in a system, the messaging client being associated with a first messaging address and being adapted to operate the node as a receiver to receive messages from another node on the system, the messaging agent further being adapted to: transfer a first key and a first messaging address to a key generator, receive a second key from the key generator, the second key being generated by the key generator in response to receiving the first key and the second key being associated with a second messaging address associated with a sender messaging client, and receive a message comprising or being associated with a key and the message comprising or being associated with a sender messaging client's messaging address, wherein the messaging client provides a user of the messaging client with access to the received message if the sender messaging client's messaging address is the second messaging address and the security key is the second key associated with the second messaging address. In another aspect the present invention may be said to consist in a method for sending a message in a system from a first messaging client associated with a first messaging address to a second messaging client associated with a second messaging address, the method comprising the steps of: transferring a first key and the first messaging address to a key generator, receiving a second key from the key generator, the second key being generated by the key generator in response to receiving the first key and the second key being associated with the first messaging address, and transferring a message from the first messaging client to the second messaging client, the message comprising or being associated with the second key and the message comprising or being associated with the first messaging address.
In another aspect the present invention may be said to consist in a method for receiving a message in a system at a second messaging client associated with a second messaging address from a first messaging client associated with a first messaging address, the method comprising the steps of: transferring a first key and a second messaging address to a key generator, receiving a second key from the key generator, the second key being generated by the key generator in response to receiving the first key and the second key being associated with the first messaging address associated with the first messaging client, and receiving a message comprising or being associated with a security key and the message comprising or being associated with a sender messaging client's messaging address, wherein the second messaging client provides a user of the second messaging agent with access to the received message if the sender messaging client's messaging address is the first messaging address and the security key is the second key associated with the first messaging address. It will be appreciated that the present invention should not be limited to any format or type of messaging. While the present invention is described in relation to email messages sent on a computer network and also text messages sent on a mobile telephone communications network, it is possible for the invention to be implemented in any type of system in which messages of any type are forwarded or transferred between nodes.
In this specification where reference has been made to patent specifications, other external documents, or other sources of information, this is generaEy for the purpose of providing a context for discussing the features of the invention. Unless specifically stated otherwise, reference to such external documents is not to be construed as an admission that such documents, or such sources of information, in any jurisdiction, are prior art, or form part of the common general knowledge in the art The term "comprising" as used in this specification means "consisting at least in part of.
Related terms such as "comprise" and "comprised" are to be interpreted in the same manner.
To those skilled in the art to which the invention relates, many changes in construction and widely differing embodiments and applications of the invention will suggest themselves without departing from the scope of the invention as defined in the appended claims. The disclosures and the descriptions herein are purely illustrative and are not intended to be in any sense limiting
BRIEF DESCRIPTION OF THE DRAWINGS
Preferred embodiments of the invention will be described with reference to the following drawings, of which; Figure 1 is a block diagram of a generic network comprising a plurality of communicating nodes, on which the invention could be implemented,
Figure 2 is a block diagram showing a possible private address structure,
Figures 3 and 4 are a block diagram and flow chart of the private address structure generation process, including key generation, in accordance with a first embodiment, Figure 5 is a block diagram of two interconnected nodes that are communicating in accordance with the invention,
Figure 6 is a flow diagram of the communication process between two nodes,
Figure 7a is a block diagram of a message frame structure of a message sent in accordance with the invention, Figure 7b is a block diagram showing the inbox, outbox and deleted messages field of a messaging client,
Figure 7c is a block diagram indicating die message structure,
Figure 8 is a block diagram showing node relationships for private address structure generation in accordance with a second embodiment, and Figures 9 and 10 are a block diagram and flow chart showing the private address structure generation process in accordance with a second embodiment.
DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS A preferred embodiment of die present invention relates to a method and system for facilitating communication of messages between nodes in a messaging system. The messaging system might be provided specifically for messaging. Alternatively, the system might have several purposes or functions, of which transferring messages is one function or purpose. The present invention may also relate to messaging software that can reside on one or more nodes in a messaging system to facilitate communication of messages between nodes..'The system, method and messaging software, for example, could be for transferring email or other electronic type messages in a computer system. Alternatively, the system, method and messaging software could be for transferring text, voice, multimedia or other messages between mobile devices in a mobile telephone network. These are just two examples, and messaging could take place between any other types of interconnected nodes in any other type of system or network, using any suitable type of message structure.
The invention can be used as a means to facilitate a closed email system by use of a private address structure (comprising private address pairs') that forms a communications relationship between two nodes, or more particularly two messaging clients operating on a respective node. The private address structure is utilised to provide communication of messages between nodes sharing a communicadons relationship. This reduces die likelihood of receiving unsolicited mail, such as spam, as the receiving party will not generally have a relationship with an originating node from which the spam is sent. Further, in the event that an established relationship between two nodes (or more particularly, their respective message clients) becomes compromised, then users of one or both of the nodes can simply destroy or disable the communications relationship to prevent any communications coming from that node. All other relationships with all other nodes could still operate in the normal manner.
Figure 1 shows a generic system 10 in which die invention may be implemented in accordance with a preferred embodiment. A system 10 comprises a network of interconnected nodes e.g. 1, Ia- If. The system 10 is preferably formed as an ad hoc structure of peer-to-peer connections of nodes 1, Ia-If each capable of supporting communication. The nodes 1, Ia-If are interconnected by any suitable communications network to allow transfer of information between the nodes. Each node 1, Ia-If is configured and operates software to facilitate communications in accordance with the invention. This configuration of software will be described with the reference to node 1, but it will be appreciated that each of the other nodes Ia-If in the system would be configured in a similar manner. The node 1 operates a messaging client 4 that is adapted to store, send and receive messages. This could be, for example an email client or similar, or a text messaging cEent, depending on the nature of the messaging system. As will be appreciated by those skilled in the art, other types of messaging clients could be used for other types of messaging systems. The node 1 also operates a delivery agent 2 that is used by the messaging client 4 to transmit a message to another messaging client (not shown) operating on another node eg. Ia-If in the system 10. The delivery agent 2 transfers a message from a sender to a recipient node by transversing through intermediate nodes. The node 1 also operates an intermediate carrier 5 that is used to launch the delivery agent 2 on the recipient node. The delivery agent is an electronic scout. The software in each client contains the permanent IP address of the Reference Management System Computer (RMS). When you start the software, the Client computer links to the RMS through the IP address and this transfers the client IP Address to the RMS. This is then monitored by the RMS for any changes as the client logs in and out of the internet. Electronic scouts (Tike a ping to an IP address) determine the best and fastest method through the internet for message and file transfer. A key generator 3 is also provided to generate private address pairs. The private address pairs form part of the private address structure to define a communications relationship between two nodes that permits communication of messages between tiiose two nodes.
The delivery agent 2, messaging client 4 and intermediate carrier 5 operate on a platform 7 that supports the private address structure based communication. A governance layer 6 provides the interface for communications between the software agents /clients 2, 3, 5 and the platform 7.
Preferably the delivery agent 2, messaging agent 4, intermediate carrier 5, governance layer 6 and platform 7 are executed as software on the node 1, although they could be implemented -in any other suitable manner.
It will be appreciated that Figure 1 shows a generic a system 10 in which the invention may be implemented. The invention may be implemented in any type of system with nodes interconnected via a communications system. For example, the nodes may be computers that are interconnected on a local or wide area network. Alternatively, the nodes might be handheld mobile devices communicating in a mobile or other telecommunications network. The invention could be implemented in any other type of node based network also. The messages transferred in such a system could be in the form of text, voice, multimedia or any other suitable content format.
The invention enables communication relationships to be set up between node pairs (or more specifically, the messaging clients running on those node pairs) in the form of a private address structure. The private address structure defined for a node pair allows for communication between the nodes in that pait via their respective messaging clients. The private address structure regime enables a messaging client running on a node to filter or block an incoming message that comes from a node for which there has been no previously established communications relationship. Figure 2 shows a private address structure 20 that is implemented on a messaging client 4. The private address structure 20 defines a communications" relationship with another messaging • client operating on another node. The private address structure 20 in its simplest form preferably comprises a recipient messaging client locator 26 and a sender messaging client locator 27. The messaging client locators 26 and 27 are also referred to as a messaging address. The locator or messaging address is a piece of information that enables the respective messaging client's node to be physically and logically located on a network, to enable transfer of data to that node. It could be, for example, in the form of an email address (in the case of an email messaging system) or a telephone number (in the case of a mobile telephone text messaging system) or some other format for other messaging systems.
As shown in the private address structure in Figure 2, the recipient messaging client is identified by way of the messaging address 26 (such as an email address, or a telephone number) that is stored as a recipient messaging client locator 26 in a recipient messaging client locator field 21. Similarly, the sender messaging client identification, which is in the form of a messaging address, is stored as a sender messaging client locator 27 in a sender messaging client locator field 22. The private address structure 20 also comprises a verification key 23 that is shared between the recipient messaging client and the sender messaging client. The verification key 28 is stored in a verification key field 23.
Preferably, the private address structure 20 also defines a human readable description or identifier, 29, 30 of both the recipient and the sender. This may be in the form of a name, label or other identifier that identifies the user of the sender and recipient messaging clients respectively. When sending a message, a user can easily select the desired recipient using the human readable identifier 29. The messaging address 26 and other required information to send a message to the recipient node/messaging client is associated with the recipient human readable identifier 29. Similarly, when receiving a message, the human readable identifier 30 can easily advise the receiver who the sender was. The human readable recipient identifier 29 is stored in a human readable recipient identifier field 24. Likewise, the human readable sender identifier 30 is stored in a human readable sender identifier field 25.
It will be appreciated that the sender and recipient nodes can change their functions. For example, a node running a messaging client that operates as a recipient node, for a first communication, can operate as a sender node in another communication.
The private address structure 20 shown in Figure 2 could be expanded or adapted to utilise a more complex form for the verification key, such as a public/private key encryption system. Other aspects to the private address structure could also be provided as required. Each node 1, Ia-If on a network can hold a plurality of private address structures 20, each relating to a communication relationship with a different respective node 1, Ia-If on the network. Figures 3 and 4 show a schematic diagram and flow chart respectively indicating how a private address structure defining a communications relationship between two nodes is generated. In particular, it shows how the verification key for that private address structure is generated. Figures 3 and 4 show private address structure generation in accordance with the first embodiment of the invention. A private address structure generation process in accordance with the second embodiment of the invention is shown in Figure 9 and 10.
If, for example the user of node 1 wishes to communicate with the user of node Ic, the following process is undertaken. First of all the users of nodes 1 and Ic, exchange a temporary key, step 40. As this is only temporary or transient key, it can be a relatively weak key. This method allows a weak temporary key to be used in environments where a strong key would be cumbersome to reproduce and be prone to generating errors. A weak key refers to a key that might be more easily "cracked" or guessed than a strong key.
There are many variant methods of establishing and sharing a weak key between two parties. Preferably, the private address structure generation mechanism involves an alternative route to transmit the initial temporary key. For example, a user would be able to create a private relationship with another user by scribbling a short number (weak key) twice on two sheets of paper — one for each party wanting to set up a communications relationship. Alternatively, a key could be exchanged through another email or mobile telephone channel (as appropriate), or any other suitable channel. The temporary key is then communicated to the messaging client 4, 4c of each respective node 1, 1c. Next, each respective messaging client 4, 4c sends the temporary key along with its respective messaging address to a strong key generator 30, step 41. Each messaging address provides a logical/physical location on the network of the respective messaging client 4, 4c. The temporary key/messaging address combination might not be sent from each node 1, 1c simultaneously. Rather, the messaging client 4, 4c of each node 1, 1c might send the temporary key and its respective messaging address at different times.
Next, in step 42, the strong key generator 3 independently receives the temporary key and respective first/second messaging addresses from the first/second messaging clients 4, 4c over a suitable network or communications channel. The strong key generator 3 then generates a permanent verification strong key 28 using the received weak key, step 43. .
The strong key generator 3 then associates the strong key with both the first messaging address and the second messaging address. For example, it might do so by storing the strong key and the first and second messaging addresses respectively in a database. Once the strong key generator has received the temporary key and respective messaging address from a respective messaging client 4, 4c it responds by sending the strong key back to that messaging client- 4, 4c, step 44, 45. As noted earlier, the strong key generator 4 might not receive this information from the messaging clients 4, 4c simultaneously. For example, it may receive the temporary key and first messaging address from the first messaging client 4 initially] In this case, the generator 3 will generate the strong key and associate it with the first messaging address, and then return the strong key to the first messaging client 4, step 44. When it later receives the temporary key and second 5 messaging address from the second messaging client 4c, it will associate the second messaging address with the already generated strong key, and return the strong key that has previously been generated to the second messaging client 4c, step 45.
The system as it is, operates from one set of softcodes. When they are matched the Reference management computer links the two with the hard code generated by random alpha/numeric
10 generator. The two parties know when a connection is made by a green dot appearing in your address book for the attempted connection and the status changing from pending to active. The private address structure (the IP address) is administered and updated by the reference management system.
Upon receiving the verification key 28 from the strong key generator 3, each respective
15 messaging client 4, 4c generates the private address structure using the strong key (which becomes the verification key 28), step 46. It will also include in the private address structure the messaging address 26 or 27 from the corresponding messaging client 4 or 4c, along with its own messaging address, and along with human readable forms of both its own and corresponding messaging
■ ■ addresses 27 or 28.
20 Once a communications relationship has been set up between two nodes 1, 1c using a private address structure 20, a message can be communicated between the two nodes 1, 1c. Either the first or second messaging clients 4, 4c can use the private address structure, including the verification key 28, to send a message to the corresponding messaging client 4 or 4c with which a communications relationship has be set up by way of the private address structure. Figures 5 and 6 show a schematic
25 block diagram and flow chart respectively of the message communication process. In this case, the user of the first node 1 intends to send a message to the user of the second node Ic. The user of node 1 prepares a message using the sender messaging client 4, step 60. The message may comprise one or more of text, voice, still or video images, or any other multimedia content as supported by the messaging client and communications network. The node 1 has input and output devices that
30 enable the user to interact with the messaging client 4 in order to create and. view messages that are received.
Figure 7a-7c show a possible form of the structure of the message 74. Figure 7a shows the message frame 70 that contains the message 74 as sent (or as received). The private address structure list field 71 holds a list of private address structures 71a that identify a list of recipients for
35 a single message. In this particular case, the private address structure list 71a will only include one private address structure 20, namely mat private address structure associated with the relationship between the sender messaging client 4 and the recipient messaging client 4c. The message delivery tithe field 72 holds the message delivery time 72a (once the message is delivered). The message delivery time 72a contains an environment specific time coding for the moment that the message was delivered by the sender delivery agent 2 shown in Figure 1. The message field 73 contains the actual message 74, which can be of any structure and suitable content as described earlier.
Note that the Verification Key Field 23 is left blank for all Private Address Structures in the Private Address Structure-List of Figure 2 to prevent the Recipient Messaging Client from illegitimately forging relationships with other messaging clients on the Private Address Structure List. Figure 7b shows the message frames stored by the messaging client, e.g. 4. The message client
4 comprises an inbox list field 76 comprising an inbox list 76a, which comprises a number of message frames 70a-70c, which are of the same structure of the message frame 70 shown in Figure 7a. Each message frame 70a-70c corresponds to a message e.g. 74 that'has been received from another node. Likewise, the message client 4 contains an outbox list field 77, comprising an outbox list 77a with a range of message frames 70d-70f relating to sent messages. There is also a deleted messages list field 78 comprising a deleted messages list 78a which comprises a number of message frames 70g-70i relating to messages that have been deleted by the user of the messaging client 4.
The user may at any point delete a message from either the inbox list 76 or outbox list 77. To do this, the set reference to the message frame 70 is removed and reinserted into the rightmost position of the deleted messages list 78 simultaneously. A further valid action by the user is to permanently delete all deleted messages. In this case all children are removed from the deleted message list. • •■
Each message 74 and its message field 73 of the message frame 70 has a structure as shown in Figure 7c. Preferably, the message comprises an XML content field 79 containing XML content 79a. The XML content could be any suitable text and/or other multimedia content. It will be appreciated that this is by way of example only, and the content field could be stored in any other suitable format. The message 74 also comprises a file attachments list field 80 which comprises a file attachments list of one or more file attachments 80b, of which only one is shown in the present case. There may be a number of file attachments. Again, these could be any suitable text and/or multimedia content in any suitable format.
Any attachments are considered part of the message 74. However, Figure 7c shows an exemplary message format where an XML message can be transmitted with multiple files. The message can be structured using XML, allowing it to display HTML that includes graphics and fonts in a generic format. XML also allows for any number of other formats providing the software application can understand these formats. Although attachments could theoretically be inserted as part of the XML schema, they are separated here in the File-Attachments-List-Field 80 for the purpose of clarity. The XML-Content 79a is affixed directly to the XML-Content and each • attachment is affixed to a unique File-Attachment 80b set. '
While the message frame 70, messages 74 and message structure has been described with reference to Figures 7a-7c with respect to the messaging client 4 of the sender node 1, it will be appreciated that the same structure occurs on the messaging clients of all other nodes Ia-If and are populated with messages 74 each respective node has created, sent, received and deleted.
Referring back to Figures 5 and 6, once the user has created a message for sending, the user selects the desired recipient messaging client 4, which is operating on the desired recipient node 1. The user does this by selecting the human readable recipient identifier 29 σf the desired recipient as defined in the private address structure 20. Once the message 74 has been. 'created, the user can instruct the sender messaging client 4 to transmit the message to the recipient messaging client 4c as indicated by. or selected by the human readable recipient identifier, step 60.
The created message can be sent to the recipient node in any suitable manner supported by the communications network on which the communicating nodes are operating. The sender messaging client 4 needs to draw on local network resources to locate the recipient messaging client 4c — such as routing services that can provide navigational data on the network 10. The navigational data is delivered from a query founded on the recipient messaging client locator 26 that contains sufficient data to identify the recipient on the network. As the delivery agent 2 propagates across the grid network, it is responsible for destroj'ing unnecessary copies of itself as well as funding all network resources utilised.
In one option, called the "there and back" regime, the sending messaging client 4 sends a sender delivery agent 2 to the recipient messaging agent 4c on the recipient node 1 c. The sender delivery agent 2 delivers the message 74 to the recipient messaging client 4c and then returns to the sender messaging client 4 on the sender node 1. This verifies that the message 74 was received by the recipient node Ic. The delivery agent 2 may deliver the message either direcdy to the recipient node Ic or via one or more intermediate nodes, for example Ia as shown in Figure 3. If the sender delivery agent 2 fails to return within a reasonable length of time, then the sender messaging client 3 will assume the message did not reach its destination and will resend the message via a new sender delivery agent 2. In this regime, it is possible that the sender delivery agent will arrive and attempt to deliver the message again. In this case the recipient messaging client should indicate that the message has already been delivered.
In a second option, called "chaining", the sender delivery agent 2 can leave a series of sender intermediate carriers (for example 5 on intermediate node Ia) on each node visited as it propagates through to the recipient node Ic. It does this by effectively not deleting any of its old copies on route. The sender intermediate carrier 5a is able to relay information across a chain between the recipient node Ic and the sender node 1. This method has the advantage over the previous method that verification of message delivery is substantially immediate.
The sender delivery agent 2 protects the verification key 28 from malicious nodes that may wish to utilise the verification key 28 for sending messages to the recipient node Ic. The sender deEvery agent protects the verification key 28 by carefully selecting the nodes through which it transits to the recipient node Ic, or otherwise the verification key is encrypted on all nodes except the final connection point, being the recipient node Ic.
It will be appreciated that any other suitable regime for transferring the message from the ' sender node 1 to the recipient node 1 c via any intermediate nodes (if appropriate) could be used. The two above are provided for exemplary purposes only.
Once the sender delivery agent transfers the message, the next step is for the recipient node Ic to receive the message, step 62. Once the sender delivery agent 2 reaches the recipient node Ic, it can communicate directly with the recipient messaging client 4c to deliver the message 79.
However, to accept the message 74 the recipient messaging client 4c conducts a verification process to ensure that the received message 74 has been received from a permitted sender node. That is, the recipient messaging client 4c checks that the received message 74 has come from a verified node that the recipient node Ic has a communication relationship with.
To determine if the received message is from a verified sender, the recipient node Ic first strips out the private address structure 20 from the received message frame 70, step 63. From the private address structure, the recipient node Ic can extract the verification key 28 in' the message and the messaging address 26 of the sender node 1. The recipient node Ic then determines if it has stored a private address structure that contains the verification key 28 and the sender messaging address 26 stripped from the incoming message 74, step 64. If the verification key 28 and sender messaging address 26 are associated together and match those specified in a private address structure stored in the recipient messaging client 4c, step 65, then the recipient messaging client 4c will conclude that it has an established communications relationship with the sender messaging agent 4. It will then deem that the incoming message 74 has come from a permitted source and should be accepted.
However, if the recipient messaging client 4c does not have a stored private address structure that contains both the received verification key 28 and the sender messaging address 26, step 66, then it will not be able to verify a communications relationship set up between itself and the sender messaging client 4 . This might be because the message has come from a messaging client with which there is not established communications relationship. Alternatively, it could be because the message has come from a messaging address for which there is an established communications • relationship, but the verification- key is incorrect for that relationship. This could imply that the message has actually come from another source, which is illegitimately attempting to "spoof a legitimate source. There could be many other reasons for a "no-match". If there is no match the recipient messaging client 4c will reject the message, step 66.
If the recipient messaging client 1 c determines that the verification key 28 and sender messaging address 26 match that in a private address structure held by the recipient mail client 4c, then the message is accepted by the recipient messaging client 4c and access is provided to the user, step 65. This causes the sender delivery agent 2 to notify the sender messaging client 4 that the message was delivered and to make the recipient messaging client 4c to store the message for viewing and retrieval by a user.
The ability for the recipient messaging address 4c to verity, via the private address structure 20, whether a message has come from a sender messaging client (eg. Id) with which there is a communication relationship, enables the recipient node Ic and recipient messaging client 4c to manage the influx of unsolicited messaging. As described in relation to Figures 5 and 6, the recipient messaging client 4c can identify, step 64, whether a message has come from a verified source node with which it holds a communication relationship. If a received message has not come from such a node, then the message can be identified as unsolicited. This may be due .to a rogue . messaging agent acquiring a verification key and then attempting to send an unsolicited message. Alternatively, it may simply be a messaging client attempting to send an unsolicited message, unaware that it is necessary to have a private address structure set up to allow communications with the destination node. A verification key 28 might be acquired by an unauthorised messaging client either by carelessness by the user of the legitimate messaging client or by utilising an insecure communication channel when transmitting the verification key to establish the private address structure.
Once a recipient messaging client 4c has received a message that has been identified as unsolicited, step 66, this indicates to the recipient messaging client 4c that the verification key 28 has been compromised and has been used by a party with which there is no communication relationship set up in respect with that verification key. The messaging client 4c, or user of the messaging client may then decide to destroy the communications relationship with the actual messaging client (i.e. 4) for which the verification key 28 does apply. This is done by destroying the private address structure set up between the recipient messaging client 4c and the corresponding messaging client (e.g. 4), which share the verification key 28. By destroying the private address structure, this does not imply that the recipient node 1 c does not want to receive further communications from the corresponding node (e.g. 1). Rather it just prevents die now compromised verification key being used by other unsolicited parties in the future. Once the private address structure has been destroyed or disabled (which destroys the communication relationship) that verification key may no longer be used to send communications between the two messaging clients. If the user still- wishes to communicate with the node corresponding to the destroyed private address structure 20, this can be done by re-establishing a new communication relationship by setting up a new private address structure 20 using the method described in relation to Figures 3 and 4. This will result in a new private address structure 20 where the corresponding node 1 uses a new verification key. This process enables a recipient messaging agent 4c to control and reduce the amount of unsolicited messages that it receives. When the node subsequendy receives a message that it identifies as unsoEcited, it prevents this being received and passed on to the user. Further, by destroying the relationship and the verification key 28, it prevents further unsoEcited messages coming from that party that has acquired the verification key without authority because the client will reject them.
All messages are stored on both the sender messaging client 4 and the recipient messaging client 4c. Each message may be structured as a message frame 70. The message frame 70 may be stored in different areas for the recipient messaging client 4c and the sender messaging client 4. Both the recipient messaging client 4 and the sender messaging client 4c have different copies of the message 74 structure on their appropriate nodes. The recipient mail client 4c stores an incoming message in the rightmost position of the inbox list. The sender mail client 4. stores an outgoing message in the rightmost position of the outbox list.
In more sophisticated versions of the mail clients, a distributed storage mechanism may be used to replace the above. The distributed architecture can provide redundancy, backup and scalability.
A private address structure 20 to define a communications relationship between two nodes can be generated in a different way according to a second embodiment as will be described with reference to Figures 8-10. In accordance with the second embodiment, a private address structure 20 can be generated direcdy with the aid of a third party node. As shown in Figure 8, recipient messaging client 4c and messaging client 4a wish to generate a private address structure to establish a communications relationship. In this case, as described previously messaging client Ic has already established a communication relationship with third party messaging client 1 , and has a respective private address structure for that relationship. In this case also, we will assume messaging client Ia also has a communication relationship with messaging client 1, which has been previously established. Therefore, messaging clients Ic and Ia can use the assistance of the third party messaging client 1 to assist in creating a private address structure to define a communication relationship between messaging client Ia and messaging client Ic. The new private address structure is created in two stages, as will be described with reference to Figures 9 and 10.
In the first stage, the nodes Ia and Ic determine a third party node that they have respective communication relationships with and they wish to use to facilitate the generation of a private address structure, step 100. In this case, the third party messaging client is messaging client 1. Next, the third party messaging client 1 sends a temporary key, step 101, along with the messaging • addresses of messaging clients Ia and Ic to a strong key generator. The strong key generator generates a first strong key from the temporary key and associates this with the messaging addresses of the messaging clients Ic, Ia, step 102. A private address structure for establishing a communications relationship between messaging clients Ia and Ic can then be set up in accordance with Figure 2 by using the received first verification (strong) key and the respective messaging addresses that are received at the third party messaging client 1, step 103. This private address structure 20 is then transferred from the third party messaging client 1 to the messaging clients Ia, Ic, step 104. This private address structure 20 is stored in the respective messaging clients Ia, Ic. The private address structure can then be used to facilitate communication between messaging clients Ia and Ic, step 103.
However, the private address structure 20 that is created is not strictly private since the third party messaging client 1 also knows the first verification key. Therefore communications between messaging clients Ia and Ic could be compromised. Therefore, in stage 2, step , messaging clients Ia, Ic use their temporary private address structure to communicate a second temporary key which the users of messaging clients Ia, Ic decide upon, step 105. Using the second temporary key the first and second messaging clients Ia, Ic can then create their own permanent private address structure, step 106, in the usual way as described in relation to Figures 3 and 4. That is each messaging client Ia, Ic sends its messaging address and the second temporary key to a key generator 4 and the key generator 4 generates a second (strong) verification key and associates this with the messaging addresses of messaging client Ia, Ic, and sends the second verification strong key back to the respective messaging clients Ia, Ic. The respective messaging clients Ia, Ic can tiien store the private address structure 20 that can be used for communication between the two messaging clients. The strong verification key (strong key 2) will be unknown to the third party messaging client 1.

Claims

1. A method for transferring a message in a system between a first messaging client associated with a fkst messaging address and second messaging client associated with a second messaging address, the method comprising the steps of: transferring a first key and first messaging address from the first messaging client to a key generator, transferring the fkst key and second messaging address from the second messaging client to the key generator, generating a second key after receiving the first key from at least one of the fkst and second messaging agents, associating the second key with the first messaging address and the second messaging address transferring the second key to the fkst messaging client after receiving the fkst key from the fkst messaging client, transferring the second key to the second messaging client after receiving the fkst key from the second messaging client, and transferring a message from the fkst messaging client to the second messaging client, the message comprising or being associated with the second key and the message comprising or being associated with the first messaging address.
2. A method according to any preceding claim wherein before transferring the first key from the fkst and second messaging clients to the key generator, the fkst key is exchanged between the fkst and second messaging clients, or between users of the first and second messaging clients.
3. A method according to any preceding claim wherein the first key is a temporary key and the second key is stronger than the fkst key.
4. ' A method according to any preceding claim and comprising the second messaging client: receiving the message, and providing access to the message if it is determined that the message is not an unsolicited message, the second messaging client determining that the message is not an unsolicited message by retrieving the second key and fkst messaging address comprised within or associated with the message, and checking that the second key is associated with the fkst messaging address.
5-. A method according to any preceding claim wherein the second key and each messaging address form a private address structure. If an address structure is compromised and used by an unauthorised party to send unsolicited mail to the second messaging client, the second messaging client can subsequently disable the private address structure, such that further messages received with the second key and first messaging address forming the private address structure with not be provided to the user.
6. A system comprising a plurality of messaging clients operating on nodes, each messaging clients associated with a respective messaging address and enabling the node to operate as a sender or receiver node, the system further comprising a key generator, the system being adapted to transfer a message between a pair of messaging clients by: receiving at the key generator a first key from a first messaging client and a second messaging client, the first and second messaging clients having respective first and second messaging addresses, generating a second key on the key generator after receiving the first key from at least one of the first and second messaging clients, the key generator associating the second key with the first messaging address and the second messaging address, . transferring the second key from the key generator to the first messaging client after receiving the first key from the first messaging client, transferring the second key from the key generator to the second messaging client after receiving the first key from the second messaging client, and transferring a message from the first messaging client to the second messaging client, the message comprising or being associated with the second key and the message comprising or being associated with the first messaging address.
7. A system according to claim 6 wherein before transferring the first key from the first and second messaging clients to the key generator, the first key is exchanged between the first and second messaging clients, or between users of the first and second messaging clients.
8. A system according to claim 6 or 7 wherein the second messaging client is adapted to receive the message, and provide access to the message if it is determined that the message is not an unsolicited message, the second messaging client determining that the message is not an unsolicited message by retrieving the second key and first messaging address comprised within or associated with the message, and checking that the second key is associated with the first messaging address.
The system can be a computer network, telecommunications network or the like. The message can be a text, email, voice, multimedia or other type message. The node could be a computer, telecommunications device, or the like.
9. A method for -transferring a message in a system between a first messaging client associated with a first messaging address and second messaging client-associated with a second messaging address, the method comprising the steps of: transferring a first temporary key and a first and second messaging address from the a third messaging client to a key generator, generating a first strong key after receiving the first temporary key, associating the first strong key with the first messaging address and the second messaging address, wherein the first strong key is used for transferring a message between the first messaging client and the second messaging client. :
10. A method according to claim 9 further comprising: transferring a message between the first messaging client and the second messaging client using the first strong key, the message comprising a second temporary key, transferring the second temporary key and first messaging address from the first messaging client to a key generator, transferring the second temporary key and second messaging address from the second messaging client to the key generator, generating a second strong key after receiving the second temporary key from at least one of the first and second messaging clients, associating the second strong key with the first messaging address and the second messaging address transferring the second strong key to the first messaging client after receiving the second temporary key from the first messaging client, transferring the second strong key to the second messaging client after receiving the second temporary key from the second messaging client, and transferring a message from the first messaging client to the second messaging client, the message comprising or being associated with the second strong key and the message comprising or being associated with the first messaging address.
11. A messaging client for use on a node in a system, the messaging client being associated with a first messaging address and being adapted to operate the node as a sender to communicate messages to another node on the system, the messaging client further being adapted to: transfer a first key and the first messaging address to a key generator, receive a second key from the key generator, the second key being generated by the key generator in response to receiving the first key and the second key being associated with the first messaging address, and transfer a message from the first messaging client to a second messaging client, the message comprising or being associated with the second key and the message comprising or being associated with the fkst messaging address.
12. A messaging client for use on a node in a system, the messaging client being associated with a first messaging address and being adapted to operate the node as a receiver to receive messages from another node on the system, the messaging agent further being adapted to: transfer a first key and a first messaging address to a key generator, • receive a second key from the key generator, the second key being generated by the key generator in response to receiving the first key and the second key being associated with a second messaging address associated with a sender messaging client, and receive a message comprising or being associated with a key and the message comprising or being associated with a sender. messaging client's messaging address, wherein the messaging client provides a user of the messaging client with access to the received message if the sender messaging client's messaging address is the second messaging address and the security key is the second key associated with the second messaging address.
13. A method for sending a message in a system from a first messaging client associated with a first messaging address to a second messaging client associated with a second messaging address, the method comprising the steps of: transferring a first key and the first messaging address to a key generator, receiving a second key from the key generator, the second key being generated by the key generator in response to receiving the first key and the second key being associated with the first messaging address, and
• transferring a message from the first messaging client to the second messaging client, the message comprising or being associated with the second key and the message comprising or being associated with the first messaging address.
14. A method for receiving a message in a system at a second messaging client associated with a second messaging address from a first messaging client associated with a first messaging address, the method comprising the steps of: transferring a first key and a second messaging address to a key generator, receiving a second key from the key generator, the second key being generated by the key generator in response to receiving the first key and the second key being associated with the first messaging address associated with the first messaging client, and receiving a message comprising or being associated with a security key and the message comprising or being associated with a sender messaging client's messaging address, wherein the second messaging client provides a user of the second messaging agent with access to the received message if the sender messaging client's messaging address is the first messaging address and the " security key is the second key associated with the first messaging address. ■
PCT/NZ2008/000115 2007-05-24 2008-05-21 Messaging system WO2008143531A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US93996907P 2007-05-24 2007-05-24
US60/939,969 2007-05-24

Publications (1)

Publication Number Publication Date
WO2008143531A1 true WO2008143531A1 (en) 2008-11-27

Family

ID=40032131

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/NZ2008/000115 WO2008143531A1 (en) 2007-05-24 2008-05-21 Messaging system

Country Status (1)

Country Link
WO (1) WO2008143531A1 (en)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6333983B1 (en) * 1997-12-16 2001-12-25 International Business Machines Corporation Method and apparatus for performing strong encryption or decryption data using special encryption functions
US20040111625A1 (en) * 2001-02-14 2004-06-10 Duffy Dominic Gavan Data processing apparatus and method
US20040255122A1 (en) * 2003-06-12 2004-12-16 Aleksandr Ingerman Categorizing electronic messages based on trust between electronic messaging entities
US20060200527A1 (en) * 2005-01-20 2006-09-07 Woods Michael E System, method, and computer program product for communications management
US20080037775A1 (en) * 2006-03-31 2008-02-14 Avaya Technology Llc Verifiable generation of weak symmetric keys for strong algorithms

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6333983B1 (en) * 1997-12-16 2001-12-25 International Business Machines Corporation Method and apparatus for performing strong encryption or decryption data using special encryption functions
US20040111625A1 (en) * 2001-02-14 2004-06-10 Duffy Dominic Gavan Data processing apparatus and method
US20040255122A1 (en) * 2003-06-12 2004-12-16 Aleksandr Ingerman Categorizing electronic messages based on trust between electronic messaging entities
US20060200527A1 (en) * 2005-01-20 2006-09-07 Woods Michael E System, method, and computer program product for communications management
US20080037775A1 (en) * 2006-03-31 2008-02-14 Avaya Technology Llc Verifiable generation of weak symmetric keys for strong algorithms

Similar Documents

Publication Publication Date Title
ES2237022T3 (en) INSTANT MESSAGING.
US9369424B2 (en) Targeted notification of content availability to a mobile device
US7711786B2 (en) Systems and methods for preventing spam
US9419950B2 (en) Secure message forwarding system detecting user's preferences including security preferences
US7774409B2 (en) Providing common contact discovery and management to electronic mail users
US6701378B1 (en) System and method for pushing information from a host system to a mobile data communication device
US6779022B1 (en) Server that obtains information from multiple sources, filters using client identities, and dispatches to both hardwired and wireless clients
US7912910B2 (en) Triggering a communication system to automatically reply to communications
CA2544717C (en) Storing, sending and receiving text message threads on a wireless communication device
US20040148356A1 (en) System and method for private messaging
US20020087639A1 (en) System and method for cleansing addresses for electronic messages
CN1514611A (en) Method and equipment used for anonymous group information transfer in distribustion type information transfer system
US20020174188A1 (en) Method and apparatus for exchanging contact information
KR20010062065A (en) Protocol for instant messaging
US7826406B2 (en) Storing, sending and receiving text message threads on a wireless communication device
JP2005285116A (en) Cryptographic puzzle cancellation service for deterring bulk electronic mail message
US9846858B2 (en) System and method for a global directory service
KR20070037951A (en) A method and apparatus for securitily sending/receiving contents in mobile network
US20040093382A1 (en) Method of transmitting an electronic mail message
US11575767B2 (en) Targeted notification of content availability to a mobile device
EP2701371B1 (en) Constructing a Contact Sharing History
US6978293B1 (en) Methods and systems for selecting criteria for a successful acknowledgement message in instant messaging
US20020085534A1 (en) Device independent communication system
US20080155263A1 (en) Systems and Methods for Tracking Electronic Files in Computer Networks Using Electronic Signatures
JPH10275119A (en) Electronic mail system

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08766964

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

WPC Withdrawal of priority claims after completion of the technical preparations for international publication

Ref document number: 60/939,969

Country of ref document: US

Date of ref document: 20091123

Free format text: WITHDRAWN AFTER TECHNICAL PREPARATION FINISHED

122 Ep: pct application non-entry in european phase

Ref document number: 08766964

Country of ref document: EP

Kind code of ref document: A1