WO2003085885A1

WO2003085885A1 - An interactive messaging communication system

Info

Publication number: WO2003085885A1
Application number: PCT/SG2002/000054
Authority: WO
Inventors: Lakshminarayanan Anantharaman
Original assignee: National University of Singapore
Current assignee: National University of Singapore
Priority date: 2002-04-08
Filing date: 2002-04-08
Publication date: 2003-10-16
Anticipated expiration: 2004-10-08
Also published as: AU2002307617A1

Abstract

A communication system for providing interactive messaging communication in an interactive session between first and second parties is disclosed. The system involves messaging a message from a first party whereby a data tree is receivable, wherein a plurality of data nodes representative of the message are interlinked to form the data tree and each of the plurality of data nodes includes content forming a portion of the message. The system also involves delivering the plurality of data nodes and content thereof to a second party whereby at least one of the plurality of data nodes representative of a portion of the message is deliverable for access by the second party. In the system, the content of each of the plurality of data nodes is created and adapted for access by the second party independent of the delivery mechanism and the delivery mechanism is adaptable during the interactive session.

Description

An Interactive Messaging Communication System

Field Of Invention

The invention relates generally to systems for providing messaging communications. In particular, the invention relates to a communication system for providing interactive messaging.

Background

Communication through messaging is becoming more popular. Advantages of messaging relative to a personal conversation include more efficient use of communication capacity. For example, communication via text-based electronic mail (e-mail), a popular form of messaging communication, requires far less communication channel capacity than an equivalent voice message that is communicated digitally. Also, communication by messaging is more time-efficient due to less need for time-consuming ritual social enquiries. Additionally, messaging communication also provides opportunities for more careful composition of messages and inclusion of various types of communication. For example, a message may be created in a multimedia format using audio, video and/or text. Furthermore, the composition effort of a broadcast message is amortized across recipients of the message.

Also, a message may be buffered when a recipient is unavailable or unwilling to receive the message immediately. The recipient also has more time to plan a response upon receiving the message. Additionally, an electronic message is easy to capture and place in long-term storage, and software may be used to assist in composing and organizing such messages.

Communication by messaging includes electronic messaging such as e-mail communication or the like messaging communication methods. Such conventional messaging communication methods, however, have constraints such as substantially slower delivery and response times in situations where interactivity is required. For example, the interaction involved in an e-mail exchange consisting of a number of e-mail transmissions for facilitating an exchange of information may only be completed after a typically extended period of "delayed" interaction, since either sender or recipient may not always attend to the e-mails during the same time frame.

Due to technological advances in communication methods, such as instant messaging, interaction time may be reduced when such messaging communication methods are used where interactivity is required for facilitating exchanges of information. However, when one party is unavailable or unwilling to receive any messages, such "instant" interaction cannot be carried out and instant messaging then functions much like e-mails.

With other advances in communication technology, such as wireless messaging, third generation mobile phones and personal digital assistant (PDA), and high-speed and broadband networks, users expect near-instant connectivity and mobility, and more importantly, richer interactivity, when using messaging communication.

There is therefore a need for a messaging communication system for providing efficient interactive messaging communication in relation to both delayed and instant interaction.

Summary

In accordance with a first aspect of the invention, a communication system for providing interactive messaging communication in an interactive session between first and second parties is disclosed. The system comprises a receiver for receiving a message from a first party whereby a data tree is receivable, wherein a plurality of data nodes representative of the message are interlinked to form the data tree and each of the plurality of data nodes includes content forming a portion of the message. The system also comprises a delivery mechanism for delivering the plurality of data nodes and content thereof to a second party whereby at least one of the plurality of data nodes representative of a portion of the message is deliverable for access by the second party. In the system, the content of each of the plurality of data nodes is created and adapted for access by the second party independent of the delivery mechanism and the delivery mechanism is adaptable during the interactive session. In accordance with a second aspect of the invention, a method for providing interactive messaging communication in an interactive session between first and second parties is disclosed. The method comprises receiving a message from a first party whereby a data tree is receivable, wherein a plurality of data nodes representative of the message are interlinked to form the data tree and each of the plurality of data nodes includes content forming a portion of the message. The method also comprises delivering the plurality of data nodes and content thereof to a second party whereby at least one of the plurality of data nodes representative of a portion of the message is deliverable for access by the second party. In the method, the content of each of the plurality of data nodes is created and adapted for access by the second party independent of the delivery mechanism and the delivery mechanism is adaptable during the interactive session.

Brief Description Of Drawings

Embodiments of the invention are disclosed hereinafter with reference to the drawings, in which:

Fig. 1 is a screen shot of a query tree (QTree) viewer of a messaging communication system according to an embodiment of the invention;

Fig. 2 is a screen shot of a login graphical user interface (GUI) of the messaging communication system of Fig. 1;

Figs. 3 A and 3B are screen shots of a QTree generation GUI of the messaging communication system of Fig. 1 ;

Fig.4 is a screen shot of a QTree mapping GUI of the messaging communication system of Fig. 1 ;

Fig. 5 is a screen shot of a QTree modification GUI of the messaging communication system of Fig. 1 ; Figs. 6A and 6B are screen shots of a QTree delivery GUI of the messaging communication system of Fig. 1 ;

Fig. 7 is a screen shot of a QTree listing GUI of the messaging communication system of Fig. 1 ;

Fig. 8 is a flowchart of a QTree generation process in the messaging communication system of Fig. 1 ;

Fig. 9 is a flowchart of a QTree delivery process in the messaging communication system of Fig. 1.

Detailed Description

Embodiments of the invention are hereinafter disclosed for addressing the need for a messaging communication system for providing efficient interactive messaging communication in relation to both delayed and instant interaction.

A messaging communication system is accordingly disclosed hereinafter that provides an interactive messaging experience in which the system separates delivery mechanism from delivery content. This is achieved by creating the delivery content independent of the peculiarities or specificity of the delivery mechanism. The system also preferably enables non-repudiation support for such interactions.

To provide the interactive messaging experience, the system preferably involves mechanisms for generating "query trees", delivering query trees, viewing contents in query trees, providing responses in relation to query trees by recipients, capturing responses sent, generating "response trails", and providing an auditable trail of the interactions. The system is advantageously suited for delivering interactive content to handheld devices that have limited visual interfaces.

Users of such a messaging communication system include a composer, a sender, a recipient, an initiator, and a responder. The system includes an entity known as an Intelligent Query Management (IQM) System. The composer composes an interactive message encapsulated in a QTree and the sender initiates the sending of the message addressed to the recipient with which the sender wishes to interact. The responder is a recipient in receipt of the QTree and thereafter responds to the message represented by it, while the initiator, which may be either the sender or recipient, initiates delivery of the

QTree to the recipient. For all intents and purposes, the composer may be generally assumed to be the sender and the recipient to be the responder. However, a sender may also send a QTree composed by other composers.

In accordance with a first embodiment of the invention, the IQM system is configured as a trusted intermediate party (TIP) that is an independent entity within the messaging communication system that is logically residing outside of and between the responder and sender. The IQM system in this instance receives the QTree sent by the sender and delivers it to the responder at the request of the initiator. In a second embodiment, the IQM system is not an independent entity but is logically part of the sender and/or responder.

The IQM system and equipment or devices through which users in the first embodiment communicate with the IQM system preferably form a client-server network environment in which the IQM system is a server and the user devices are client devices. In such a client-server environment, each client device may have different capabilities and access control permissions. In the second embodiment, users communicate with each other using equipment or devices that preferably form a peer-to-peer network environment in which the functions and responsibilities of the IQM system are shared out between the user devices.

System Environment

The messaging communication system described hereinafter with reference to Figs. 1 to 9 preferably operates in a network environment. The network environment preferably comprises a communication network, user host computers, service host computers, connection host computers, gateways to other networks such as local area networks (LAN), mobile communication networks and mobile messaging networks, software executed on the various computers, and user equipment and devices such as mobile phones, personal computers, terminals, PDAs and the like personal communication devices. Internet connections and wireless communications may be used in such a network environment.

Many different communication protocols may be employed in facilitating communications between the various parts of the network environment, such as TCP/IP, X.25, ISDN,

Ethernet, asynchronous line protocols and analog and/or digital voice transmission. Also, where appropriate, authentication and encryption protocols are employed, for example, secure socket layer (SSL) protocol.

Depending on circumstances under which users interact through the messaging communication system, for example the locality and time of accessing the network environment, there exists a number of ways by which the users may use user devices to facilitate such access. In one example, the user device may comprise only a mobile phone or a short message service (SMS) messaging device which functions as a client device that communicates with the IQM system in the client-server network environment.

In another example, a user may through a user host computer, which functions as a user device, dial a connection host computer which is part of the network environment to access the messaging communication system. The user then establishes network access authority, for example by entering the appropriate identification code and password. The connection host computer verifies access authority, then makes the appropriate network resources available to the user for communicating with the IQM system. Such network access include, for example, Internet access, instant messaging access, and etc. Once such network access is established, the user may through the user device communicate with other users through the respective user devices in either the peer-to-peer or client-server network environment.

Delivery Channel

A communication protocol and a user device with associated software and/or hardware through which an interactive message is sent preferably constitute a delivery channel. For example, the combination of TCP/IP and e-mail messaging communication constitute a delivery channel.

Query Tree With reference to a screen shot shown in Fig. 1 , a query tree (QTree) viewer 100 of a messaging communication system according to an embodiment of the invention is described. A QTree 102, an example of which is shown in the QTree viewer 100, is a data tree structure having interlinked data nodes representative of an interactive message composed by a sender that consists of a set of queries each of which may invoke a response given by a responder. Such a data structure preferably encapsulates the interactive message in which the set of queries together with options and/or attributes, described in detail hereinafter, provide interactive content for facilitating interactive messaging communication. In the QTree 102, each of the set of queries and respective options and/or attributes is preferably encapsulated using each of multiple data nodes (lines 104 to 126). Each of the multiple data nodes (any of lines 104 to 126) is preferably an independent data node in the data structure of the QTree 102 in which the multiple data nodes (lines 104 to 126) are preferably logically and hierarchically interlinked to form the QTree 102.

The QTree 102 may be viewed as an "Interactive Questionnaire" that provides a set of interrelated queries for facilitating a querying process during the interaction. There is a root node (line 104) and preferably only one such data node exists in each QTree 102, such a data node preferably being of the highest order in the hierarchy of multiple data nodes (lines 104 to 126) in the QTree 102. A unique identifier preferably identifies each QTree 102, each QTree 102 preferably has an owner, and there is preferably only one instance of a QTree 102. A QTree 102 preferably consists of a number of data nodes (lines 104 to 126) having query-based or the like content, hereinafter referred to as "Query Nodes" (QNodes) (lines 104 to 126), and each QNode (any of lines 104 to 126) preferably has a unique identifier. Each QNode (any of lines 104 to 126) may be linked to any number of child nodes in which a child node is preferably of a lower order in the hierarchy than a parent node. Any QNode (lines 104 to 126) not linked to any child node (lines 106 to 126) is a leaf node (lines 112 and 120 to 126). Each child node is preferably unique and is linked to only one parent node (lines 104 to 1 10 and 1 14 to 118).

Each QNode (any of lines 104 to 126) preferably includes content relating to the respective query and a set of options and/or attributes, and in the case of a leaf node (lines 1 12 and 120 to 126), preferably only content. Each QNode (any of lines 104 to 126) that includes at least one option or attribute is preferably linked to at least one child node (line 106 to 126), each option or attribute linking the QNode (any of lines 104 to 126) to a child node, whereas leaf nodes are not linked to any child node. The content in each QNode (any of lines 104 to 126) may be of text, audio, and/or video or the like content format. Logic for accessing other entities in the messaging communication system or outside the system through the gateways to other networks may also encapsulated in each QNode (lines 104 to 126), and preferably such logic is encoded in software.

Depending on the response given for a query relating to a QNode (any of lines 104 to

126), logic associated with the QNode (any of lines 104 to 126) is preferably applied to the response and a specific child node is chosen based on the logic. The logic that is applied may also use information which is not part of the responses to the queries, for example relating to time of response or location of the responder, and may include some prior knowledge and/or responses to the queries to the parent nodes. Only one child node is preferably chosen depending on the response to a query relating to a QNode (lines 104 to 126).

To provide interactive messaging communication, the QTree 102 and multiple QNodes (lines 104 to 126) are sent to one or more responders with which the sender wishes to communicate. However, only one QNode (lines 104 to 126) is preferably delivered to a responder each time for the duration of an interactive messaging communication session, known hereinafter as a QSession, involving the QTree 102. The order of delivering multiple QNodes (lines 104 to 126) to the responder during such an interactive messaging communication session preferably depends on the hierarchical order of the multiple nodes (lines 104 to 126) in the QTree 102, where a QNode (any of lines 104 to 126) of the highest order in the hierarchy is delivered first and a QNode (any of lines 104 to 126) of the lowest order is delivered last. The responses provided by the responder for the queries relating to the QNodes are delivered to the sender during the interactive messaging communication session.

The sender preferably uses the QTree viewer 100 on one user device to view the QTree 102 and multiple QNodes (lines 104 to 106), while the responder, on the other hand, uses another user device to receive and view one QNode (any of lines 104 to 126) at a time and respond to the query relating to the QNode (any of lines 104 to 126), thereby reciprocating the interactive messaging communication initiated by the sender.

Types of QNodes

A QNode may be static, which means that it is created during the creation of a QTree, or dynamic, which means that it is created during a QSession. Child nodes are preferably implemented as static QNodes when the number of child nodes is not large and the content of the child nodes is known before hand. Static QNodes are also simpler and hence QTrees consisting only of static QNodes are easily generated using suitable tools.

The content and child nodes, if any, of dynamic QNodes are preferably generated during a QSession. Hence dynamic QNodes are more complicated than static QNodes and may require access to an external server which provides the logic for the creation of the dynamic QNode. The content of a dynamic QNode generated during a QSession is preferably archived along with the corresponding response nodes or RNodes described hereinafter that are generated during the QSession.

The generation of these QNodes are implementation specific. Generation of the dynamic QNodes may also be dependent on external events, for example, fall or rise in share prices, sudden change in weather etc. However, the recipient of a QNode sees no difference between a static QNode and a dynamic QNode in relation to the QMessage received.

QNode Properties

Every QNode also preferably includes properties such as time of creation, owner, and access permissions in relation reading from or writing to the QNode. The access permission of the QTree preferably overrides the access permission of the QNodes in the

QTree.

Contents of a QNode A QNode preferably consists of content and options and/or attributes, and these may be textual, aural or visual in nature. The content of the QNode may provide information, pose a question, request for information, direct the responder to the options and/or attributes, or any combination of these. The options are preferably devices through which the responder selects from a list of child nodes linked to the QNode. The attributes are preferably user input devices such as textboxes, text fields or data entry/attachment fields for enabling text or data entry by the responder for selecting child nodes linked to the QNode. For example, queries sent to the responder may be text content with pre-defined choices for options and attributes that enable the responder to enter content which is text, audio, video, a combination of these, or any other type of content.

QNode Logic

Every QNode is preferably associated with logic for the selection of a child node, the application of such logic being dependent on the response for selecting the child node. The response may either be the selection of an option or data entry using an attribute. The logic may be programmatic in nature, which may involve software codes and/or hardware.

Alternatively, the logic may be dependent on decisions made by a human user instead of a computer, in which case the selection process in relation to the child node is stored together with the identity of such a user making the decisions. For example, during an interactive chat, the responses provided by a recipient are sent back to the sender and the sender based on the responses make decisions on which child nodes to choose.

The logic essentially determines which child node is preferably selected based on input to the parent node provided by the responder. The logic is preferably not delivered together with the parent node to the responder, and in the client-server network environment, the logic resides in the IQM system. In the messaging communication system, each QNode may also have logic, for example in the form of software codes, embedded therein, in which such logic allows the QNode to have capabilities, through such software codes, for providing access to other applications, software objects, databases or servers that may reside on equipment or devices other than the user device within or without the messaging communication system. Connection for such access may be made through relevant networking mechanisms such as connection host computers and gateways to other networks.

Query Session Preferably, a Query Session (QSession) starts when a root node of a QTree is delivered by the IQM system to a responder and ends when the responder receives a leaf node of the QTree.

As each QNode of a QTree is identified by a unique identifier and the QTrees are preferably stored in a persistent data store, a QSession may be maintained indefinitely.

QMessage

An interactive message that is delivered to a responder, which preferably consists of QNodes of a QTree delivered to the responder during a QSession, is called a QMessage. Each QMessage may have a QMessage identifier. When a QSession is initiated, the

QSession is preferably also given a unique identifier. All QMessages sent to responders preferably carry a unique identifier, and each unique identifier may be a function of the QSession identifier and QNode identifier or any other information.

Response Nodes

Responses given by the responder to queries in a QTree are preferably captured using a "Response Trail" (RTrail), which in turn is preferably made up of individual Response Nodes (RNodes).

The RTrail preferably includes information about the sender, responder, and time of initiation of delivery of the QTree. The RTrail is preferably associated a QSession during which a query process associated with the QTree takes place, and is designated a unique ID. An RNode preferably corresponds to a QNode and each RNode captures each response sent by the responder.

When a QNode is delivered to a responder, a corresponding RTrail is preferably created at the IQM system. However, there may be special QTrees for which the sender may not need a RTrail to be created, for example, a QTree that consists merely of information and the user responses are not useful to the sender. An RNode corresponding to the root node delivered is also preferably created at the IQM system, and the RTrail is preferably completed once a leaf node is delivered to the responder. The RNode preferably captures each response given by the responder upon arrival of the response at the IQM system. The RNode may include tokens such as the digital signature of the sender. The RNode may also store responder tokens such as the digital signature of the responder. The RTrail may also store information regarding the QSession. The response, tokens, responder tokens and information regarding the QSession may be permanently stored, for example in a database, for the duration of a QSession or after the completion of a QSession.

Viewing an RTrail

There are a number of ways of viewing an RTrail, including showing the complete QTree and RTrail together, or merely showing the RTrail.

Collation/Summary of RTrail

A single QTree may be sent to multiple responders. The messaging communication system may be capable of obtaining statistical data from various responses of these responders for collation. The content of an RTrail may also be summarised.

Time-based Delivery

A QNode may have a "Delivery Time" Attribute, which determines when a QNode is to be delivered to a responder. Even if a QNode delivery is triggered, a Delivery Engine or a QTree adapter, which are described hereinafter, is to wait for the delivery time to expire before delivering the QNode. This may be very useful for providing reminder services. Also, a time window may be specified during which a response is to be made by the responder. Otherwise, the response is considered as "out of date".

Location-based Delivery A QNode may also have a location dependency attribute, which ensures that a QNode is delivered to a recipient only if the recipient is in a particular location.

Consistency of a QTree

A QTree is preferably considered consistent if the selection of a particular option or inputting to any attribute of a QNode leads to the delivery of another QNode. Any QTree that does not satisfy this criterion is considered inconsistent.

Generation of a Query Tree

With reference to Figs. 2 to 5, a preferred process of generating a QTree is described in detail. To generate a QTree, a sender first performs a login to access the messaging communication system using a graphical user interface (GUI) 200 shown in Fig. 2, which is executable from the sender's user equipment by entering a set of user identity 202 and password 204 or using another secure authentication mechanism such as secure ID, SSL authentication, etc.

During the process, a software/hardware component known as a QTree generator in the messaging communication system, preferably logically residing in the sender's user equipment, generates a QTree using input provided by the sender through a GUI 300 shown in Figs. 3A, 3B and 4. Such a component provides means for generating the QNodes of a QTree, either static or dynamic. The QTree is then submitted to the IQM system.

Every QTree created in this way is associated with attributes including a unique identifier, an owner, a time of creation, and access permissions. The owner of a QTree may be a user or a device delegated to perform the task of creating the QTree automatically on behalf of the user. By using the QTree generator, a QTree is generated starting with a root node using query and option entry fields 302 and 304 and a pop-up menu 306. The QTree generator then enables the sender to create the queries, logic and child nodes using the same devices but selecting different options in the pop-up menu 306 and using entry and entry/selection fields 402 and 404 in the GUI shown in Fig. 4, and showing the QTree generated in windows 308 and 408. The creation of the root node, QNodes, logic and child nodes may be done manually or automatically by a device.

Linking one QTree to another QTree may create a new QTree provided the resultant data structure is a QTree. The messaging communication system preferably does not restrict a QTree to any particular size.

The QTree generation GUI 300 shown in Figs. 3A, 3B and 4 may be implemented as a Web-based document, but is not restricted to be Web-based only.

The QTree generation process is further illustrated using a flowchart shown in Fig. 8, in which the process begins with a sender in a step 802 performing a login to access the messaging communication system. In a step 804, the messaging communication system checks if the sender is a valid user of the messaging communication system. If the sender is not a valid user, error handling is performed in a step 806 and the process terminates thereafter.

If the sender is a valid user of the messaging communication system, the process continues in a step 808 in which the sender creates the QTree and set attributes in a step 810. The information inputted by the sender is sent to the IQM system and archived in a step 812 in a central or local database, depending on whether the messaging communication system is configured to operate in a client-server or peer-to-peer network environment, respectively.

Updating a QTree When a QTree is updated, a new QTree is preferably created with the updated QNodes. In this case, the new QTree maybe re-assigned new properties such as ownership, unique identifier, and time of creation. The sender may append a QTree or delete QNodes in an existing QTree to obtain a new QTree. When a QNode is deleted, all related child nodes, if any, are preferably also deleted.

The sender may also "cut/copy" QNodes from one QTree and "paste" these onto another QTree. However only the contents are preferably copied over and a new QNode identifier is created for the every new QNode.

In the process described with reference to Figs. 3 A, 3B, 4 and 8, the modification of a

QTree is carried out using entry and entry/selection fields 502 and 504 in a GUI shown in Fig. 5.

Viewing a QTree There are many ways of viewing a QTree, and one example is shown in Fig. 1 in which a QTree viewer 100 is shown. There are a number of ways of viewing a QTree, for example, by displaying all the QNodes with their properties. Alternatively, the QTree viewer 100 may start with displaying the root node and its child nodes. When a child node is selected, the selected child node is shown with its child nodes if any. The procedure is repeated for each child node.

Delivering a QTree

A QTree may be delivered by the IQM system any number of responders via any appropriate delivery mechanism such as instant messenger, wireless SMS, or the like communication services.

Once the user device of a responder responds to a QMessage, the response is preferably sent to the IQM system where the IQM system processes the response and depending on the application logic of the node, obtains the next QNode and delivers the selected QNode to the responder. An example of a QTree delivery process is illustrated using a flowchart shown in Fig. 9, in which the process begins with a sender or a responder from the respective user equipment or device initiating delivery of a QTree in a step 902. A recipient list is then compiled for the messaging communication system to perform the delivery in a step 904, and in a step 906, the IQM system delivers the content of each QNode in the QTree. The response is obtained from a responder in a step 908, and the IQM system uses this information to construct an RTrail in a step 910. The RTrail is then stored in a central or local database, depending on whether the messaging communication system is configured to operate in a client-server or peer-to-peer network environment.

The logic of the QNode meanwhile, is processed by the IQM system in a step 912, which checks if the QNode is a leaf node in a step 914. If the QNode is not a leaf node, the process loops back through a step 916 to get the next QNode in the QTree for processing in the step 906. If the QNode is a leaf node, however, the process terminates thereafter.

QTree Delivery Initiation

QTrees may be sent from a user or delegated device to another user or delegated device. An initiator may initiate a QTree delivery by prompting an appropriate service provided by the messaging communication system, which may be implementation dependent, for example, via Web-based, SMS and the like communication methods.

Figs. 6A and 6B are screen shots of a QTree delivery GUI of the messaging communication system, and the initiation of QTree delivery may be carried out using entry and selection fields 602 and 604 in the QTree delivery GUI by which the responder of the QTree is identified and mode of delivery is indicated, respectively.

QTree Delivery Engine and Adapters

A QTree delivery engine in the messaging communication system preferably manages the delivery of QNodes, but does not deliver the interactive messages to user devices. The messaging communication system preferably consists of QTree adapters which transform the interactive message to suit the profile of a particular user device. There may be as many QTree adapters as there are different types of user devices. Since the QTree delivery engine delivers QNodes to the adapters, the QTree delivery engine therefore p preferably does not partake in content transformation and error handling, which remains the responsibility of the QTree adapters.

Identification of Users

Users of the messaging communication system may receive interactive messages using different user devices each of which may have a different physical address. The IQM system preferably includes an "address book" which maps a single unique name to each physical address. Hence when a sender wishes to send an interactive message to a responder through SMS, the GSM phone number of the responder, if it exists, is retrieved from the address book before the QTree is dispatched.

A more sophisticated address book may also support access control restrictions where users may specify fine-grained access control lists.

In the messaging communication system, it is preferably also possible to directly send a QTree to a user device if the physical address of the user device is known. This may be useful when a QTree needs to be delivered to a responder not part of the messaging communication system.

Access Control Mechanisms

In the messaging communication system, the physical address of each user device may be associated with an access control policy. Such policies include "Allow All", in which a user allows anybody to send interactive messages to that particular user device; "Strictly Forbidden", in which a user allows anybody except those in a list of addresses to send messages to that particular user device, for example using an address list which may include wild cards. Any other message is sent is dropped or sent to a "trash" directory; and finally "Only Allowed", in which a list of addresses is kept and any interactive message from any address not in this list are dropped or sent to a "trash" directory. Messages in the "trash" directly may be sent to a particular delivery channel if the user so chooses so. This user access control policy and address list may be set up for each delivery channel and may also be modified at any point in time.

When a QSession is initiated, the access control policy for the entire QSession is the access control policy associated with the first delivery channel in cases when the delivery channel is changed during the QSession.

Preferred Delivery Channel

In the messaging communication system, it is preferable to allow migration from one delivery channel to another during a QSession. This is possible through users changing the preferred delivery channel during a QSession.

In the messaging communication system, a user may specify a preferred delivery channel for receiving interactive messages based on convenience. The messaging communication system also provides a means of changing the preferred delivery channel for receiving QTrees.

The preferred delivery channel may be set in many ways, which includes the user accessing a server to change the preferred delivery channel. This may be achieved in several ways such as accessing the user's account on a Web portal, for example using entry and selection fields 602 and 604 shown in Figs. 6A and 6B, calling up a number and changing the preferences, or sending a data message from a mobile phone via SMS. In the last two instances, the user is uniquely identified by the mobile phone number. Any scheme by which the user may be uniquely identified before the change in delivery channel may be effected may also be used to change the preferred delivery channel.

Alternatively, the preferred delivery channel may be set in a way in which the change of preferred delivery channel is an extra "option" which is included with the other options of a QMessage.

When a preferred delivery channel is changed within a QSession, there are two options regarding message delivery in the messaging communication system. Either the current QNode is sent to the new preferred delivery channel, or when a query is responded to, the next QNode in the QSession is sent to the new preferred delivery channel. This may be implementation dependent.

Group Messaging

The user may also have an address book which may contain addresses of groups consisting of a set of users. A QTree may be delivered to groups of user, that is, every responder in a group is delivered the relevant QTree.

Sender Intimation

In the messaging communication system, once a QSession is complete, the sender may receive an intimation message informing the sender of the completion.

Content Transformation Content that is actually delivered to a user device by the QTree adapter may depend on the user device characteristic and the delivery channel. QTree adapters perform content transformation. Content transformation information may also be captured in a QNode and delivered together with a QMessage. The user device may use this information appropriately while displaying the interactive message to the responder.

Moreover, it may be the responsibility of QTree adapters to handle issues such as error handling in addition to content transformation.

Inserting Advertisements Advertisement clips may also be inserted into the interactive message delivered to responders or in between delivered contents of two QNodes. The QTree delivery engine manages the advertisements within a QSession but keeps tracks of the responses to the QTree only.

Intelligent Query Management System

The IQM system preferably includes the ability to create/delete users, update details about users, create with authentication support, create and update QTrees, send queries to selected responders, obtain responses and collate the same, perform authentication support, archive sent/received messages, perform access control to archive, provide search capabilities, and provide capability to view user information and archived information to which user has access.

The IQM system may operate in two communication modes, namely one that operates using a trusted intermediate party and the other without one, according to the first and second embodiments of the invention.

Trusted Intermediate Party (TIP) Communication Mode

According to the first embodiment, there is preferably a trusted intermediate party (TIP) logically resident between two or more communicating parties which is an intermediary. The TIP is preferably responsible for archiving interactive messages and managing the infrastructure of the IQM system. The TIP may be a Web portal, a Web e-mail system, or such similar scheme or system.

Peer-to-Peer Communication (P2P) Communication Mode

There may be cases where communication between entities may not require a TIP or a TIP may not be present. Then in such cases all the communication links are preferably point- to-point communication links without an intermediary. Such a peer-to-peer configuration of the IQM system according to the second embodiment is preferably similar to the TIP configuration except that a sender directly sends QNodes to responders which the software/hardware on the sender peer device is preferably capable of performing. Similarly the responder is also preferably capable of handling the QNodes and responding to the QNodes. The sender at the sender peer device preferably performs the creation of QTrees, and RTrails are archived by the peer devices. Certificate and digital signing validation, described hereinafter, is preferably performed by the peer devices since this is a responsibility assigned to the interacting peer devices.

Secure Communications between Entities

All communications between entities may be secured using cryptographic techniques such as SSL. Digital Signatures Definition

Digital signatures are preferably associated with public key infrastructure related signatures as described in "Applied Cryptography", Second Edition by Bruce Schneier. However, in the messaging communication system, digital signatures refer more broadly to any digital signature that is legally accepted.

Different types of Non-repudiation

In the messaging communication system, there are preferably three types of non- repudiation, namely non-repudiation of origin, which protects the responder, non- repudiation of delivery, which protects the sender, and non-repudiation of submission, which protects the sender as described in "Secure Electronic Commerce", Second Edition, Warwick Ford and Michael S. Baum.

The parties or entities involved in non-repudiation are preferably the sender, recipient and TIP, if applicable, which is "trusted" to archive QTrees, RTrails and associated non- repudiation information reliably, try "best effort" delivery schemes while transmitting interactive content, and be a neutral party with no bias.

Paranoid users, who may be users that do not completely trust the TIP, are preferably allowed to perform some or all tasks of the TIP if such users do not completely trust the TIP. In such cases, some of the functionality of the TIP may be duplicated by the paranoid users.

The TIP may also aggregate relevant non-repudiation information if there exists such a prior agreement. The TIP may also take over some of the digital signature validation responsibilities from any of the parties involved if the parties desire to have such an agreement, especially if the requesting party does not possess certain capabilities. The TIP may also check that the QNodes are "properly" linked, which is described hereinafter.

Sometimes, the TIP may not be present at all, in which case the concerned parties are to assume some or all of the functionality of the TIP. The TIP is preferably kept simple, for example without digital signing capability, because in this case, the TIP assumes more liability and the TIP efforts may even be duplicated for providing redundancy where many functionalities of the TIP may be duplicated by the parties involved, for example the function of archival. All other parties involved in non- repudiation in the messaging communication system, however, are assumed to possess digital signing capability.

Linking in QTree Delivery QNodes may include simple content such as "Do you agree to the earlier request?" and straightforward options such as "Yes" and "No". In such cases, it may be necessary to link such a QNode to other QNodes. If linking is not included, it may be possible to insert QNodes that have been sent during other QSessions. So if the response to a query consists of a simple answer such as "Yes" or "No", there should preferably be a reliable way of associating this response to the query to which the response was made and to link this query to its parent node as well as the selected child node, if any.

Where linking is necessary, it is preferably achieved using sender and responder QTree "cert tokens". There are a number of methods to link QNodes, namely via Signature linking and/or Hash linking.

Signature Linking

This is a preferred method of linking QNodes, which involves using signature operations to generate receiver and sender cert tokens. A sender cert token is preferably sent along with each QNode and the user device of the responder checks the sender cert token before proceeding to process the QNode. Similarly, the user device of the sender preferably checks a responder cert token, which is sent together with each response, when the response is provided by the responder. The TIP may check that the linking, information of which is carried in the cert tokens, is proper. Examples of cert tokens used in the messaging communication systems include:

Receiver Cert Token (-1) = null; Sender Cert Token(i) = Signature (QSession ID, QNode ID, sender ID, receiver ID, time of delivery of QNode, QNode content, Hash(receiver Cert Token(i-l)); and

Receiver Cert Token(i) = Signature(QSession ID, QNode ID, receiver ID, sender ID, time of response of QNode, QNode content, QNode response, Hash(sender Cert Token(i)).

It is preferably assumed that a root node is the 0^th QNode, and the QSession ID is a random ID associated with every QSession, which should be sufficiently long with at least 128 bits, random and preferably generated by the TIP. The QNode ID is an ID associated with a QNode, and the QSession ID and QNode ID uniquely identify a QNode delivered to a responder. The Receiver ID and sender ID refer to the respective ID of the responder and sender.

Also, the time of delivery may be supported by additional time stamps that may be obtained from a trusted time stamping server, either by the TIP or any of the parties involved.

Hash Linking

In some cases, the use of signature operations may be computationally expensive and therefore may alternatively be replaced by a cryptographic hash operation. Examples of cert tokens used in the messaging communication systems include:

Sender Cert Token(i) = Hash (Qsession ID, QNode ID,, sender ID, receiver ID, time of delivery of QNode, QNode content, Hash(receiver Cert Token(i-l)); and

Receiver Cert Token(i) = Hash(QSession ID, QNode ID, receiver ID, sender ID, time of response of QNode, QNode content, QNode response, Hash(sender Cert

Token(i)). This linking method, however, does not support non-repudiation. If non-repudiation support is required, at least the sender cert token (0), receiver cert token (1), sender cert token for the last QNode sent, and receiver cert token for the response to the last QNode have to be signed to support a modicum level of non-repudiation.

Non-repudiation support

The sender cert token provides the messaging communication system with support for

"non-repudiation of origin". When a responder responds to a QNode, the attendant receiver cert token serves to provide support for "non-repudiation of delivery". The TIP supports non-repudiation of submission and the receiver cert token may also serve to support non-repudiation of submission, albeit in an indirect manner because a responder cannot respond to a QMessage unless the responder accepts in the first place that the

QMessage was received.

Messaging communication system without TIP

When a TIP is not present in the messaging communication system, for example in the peer-to-peer network environment in which the messaging communication system operates, it is preferably the responsibility of the parties to perform the operations of the TIP such as aggregation of non-repudiation information. But in this case it is difficult to achieve the same level of non-repudiation when there is a TIP. Non-repudiation of submission is difficult to achieve in this case when only two parties are involved. Hence if a responder responds to a QNode, then the response may be taken as evidence for both non-repudiation of delivery and submission. Aggregation of non-repudiation related evidence such as certificate revocation lists and time stamps are also performed by the parties involved.

Capability Disability

There may be cases where the sender or responder may not have capabilities to perform digital signing, aggregate non-repudiation information, obtain reliable time stamps, and verify linking information. In such cases, the TIP may assume some or all of the above roles if non-repudiation support is required by the messaging communication system. If digital signing capability is lacking in any of the parties, the TIP may vouch for party identity, delivery of message, and etc. This may be supported either by a single document generated by the TIP or a digitally signed document from the TIP that may be time stamped by an external party. However when this happens, the TIP assumes greater liability.

The TIP may aggregate non-repudiation information such as information for certificate validation, signature validation, signature policies, and etc. The TIP may also obtain reliable time stamps from external servers.

Sometimes a party involved may not be able to verify the sender or receiver cert tokens because the party may not have sufficient information, for example because of limited data storage or software. Since the information necessary for verifying the cert tokens is archived by the TIP, the TIP may therefore also verify the cert tokens before forwarding these to the parties involved.

Non-repudiation for Interactive "Chats"

Interactive "chats" using the messaging communication system may also be archived as QTrees and RTrails. The same approach used when the messaging communication system is without a TIP may also be used for non-repudiation support for such interactions. Each message sent to a responder has a unique identifier generated in the same way as in case when the messaging communication system operates in the peer-to-peer network environment.

In the foregoing manner, a system is described for providing efficient interactive messaging communication in relation to both delayed and instant interaction.. Although only a number of embodiments of the invention are disclosed, it will be apparent to one skilled in the art in view of this disclosure that numerous changes and/or modification can be made without departing from the scope and spirit of the invention.

Claims

1. A communication system for providing interactive messaging communication in an interactive session between first and second parties, the system comprising: a receiver for receiving a message from a first party whereby a data tree is receivable, wherein a plurality of data nodes representative of the message are interlinked to form the data tree and each of the plurality of data nodes includes content forming a portion of the message; and a delivery mechanism for delivering the plurality of data nodes and content thereof to a second party whereby at least one of the plurality of data nodes representative of a portion of the message is deliverable for access by the second party wherein the content of each of the plurality of data nodes is created and adapted for access by the second party independent of the delivery mechanism and the delivery mechanism is adaptable during the interactive session.

2. The system as in claim 1, wherein the delivery mechanism delivers the at least one of the plurality of data nodes for responding by the second party.

3. The system as in claim 2, wherein the content of the at least one of the plurality of data nodes comprises at least one of text, audio, and video information.

4. The system as in claim 3, wherein the content of the at least one of the plurality of data nodes further comprises a query for providing interactivity between the first and second parties in relation to the message.

5. The system as in claim 4, wherein the at least one of the plurality of data nodes further comprises at least one option associated with the query wherein the selection of the at least one option is dependent on a response to the query.

6. The system as in claim 5, wherein the at least one of the plurality of data nodes further comprises logic associated with the at least one of the plurality of data nodes wherein the selection of at least another of the plurality of data nodes is dependent on at least one of the logic and response to the query.

7. The system as in claim 6, wherein each of the plurality of data nodes is logically associated to at least another of the plurality of data nodes to form the data tree.

8. The system as in claim 7, wherein the data tree comprises a parent node which is an originating node wherefrom a child node originates.

9. The system as in claim 8, wherein the data tree further comprises at least one leaf node which is a terminal node in the data tree originating from another of the plurality of data nodes.

10. The system as in claim 9, wherein the selection of the at least one option at a parent node results in the selection of a child node dependent on a parent-child logical association.

1 1. The system as in claim 10, wherein one of the plurality of data nodes is linked to another of the plurality of data nodes by linking information transmissible together with one or another of the plurality of data nodes.

12. The system as in claim 1 1 , wherein the one of the plurality of data nodes is linked to another of the plurality of data nodes using one of signature and hash linking.

13. A method for providing interactive messaging communication in an interactive session between first and second parties, the method comprising the steps of: receiving a message from a first party whereby a data tree is receivable, wherein a plurality of data nodes representative of the message are interlinked to form the data tree and each of the plurality of data nodes includes content forming a portion of the message; and delivering the plurality of data nodes and content thereof to a second party whereby at least one of the plurality of data nodes representative of a portion of the message is deliverable for access by the second party wherein the content of each of the plurality of data nodes is created and adapted for access by the second party independent of the delivery mechanism and the delivery mechanism is adaptable during the interactive session.

14. The method as in claim 13, wherein the step of delivering includes delivering the at least one of the plurality of data nodes for responding by the second party.

15. The method as in claim 14, wherein the step of receiving includes receiving content of the at least one of the plurality of data nodes which comprises at least one of text, audio, and video information.

16. The method as in claim 15, wherein the step of receiving includes receiving content of the at least one of the plurality of data nodes which further comprises a query for providing interactivity between the first and second parties in relation to the message.

17. The method as in claim 16, wherein the step of delivering includes delivering the at least one of the plurality of data nodes which further comprises at least one option associated with the query wherein the selection of the at least one option is dependent on a response to the query.

18. The method as in claim 17, wherein the step of delivering includes delivering the at least one of the plurality of data nodes which further comprises logic associated with the at least one of the plurality of data nodes wherein the selection of at least another of the plurality of data nodes is dependent on at least one of the logic and response to the query.

19. The method as in claim 18, wherein the step of receiving includes receiving each of the plurality of data nodes which is logically associated to at least another of the plurality of data nodes to form the data tree.

20. The method as in claim 19, wherein the step of receiving includes receiving the data tree which comprises a parent node which is an originating node wherefrom a child node originates.

21. The method as in claim 20, wherein the step of receiving includes receiving the data tree which further comprises at least one leaf node which is a terminal node in the data tree originating from another of the plurality of data nodes.

22. The method as in claim 21 , wherein the step of delivering includes delivering wherein selection of the at least one option at a parent node results in the selection of a child node dependent on a parent-child logical association.

23. The method as in claim 22, wherein the step of delivering includes delivering one of the plurality of data nodes which is linked to another of the plurality of data nodes by linking information transmissible together with one or another of the plurality of data nodes.

24. The method as in claim 23, wherein the step of delivering includes delivering one of the plurality of data nodes which is linked to another of the plurality of data nodes using one of signature and hash linking.