The present invention relates to a method, according to the preamble of Claim 1, in a telecommunications system. The invention also relates to a system according to the preamble of Claim 14 and a computer-program product according to the preamble of Claim 11.

The term telecommunications system refers particularly to a system transmitting packet- based communications between user terminals, which is suitable for transmitting text- form information received from various user terminals in a form readable as a discussion on various user terminals. Such systems are, for example, email, various types of instant- messenger system, as well as the internet and the discussion forums operating on it.

From the point of view of an email user, it is useful if there are user-friendly ways to store, search for, and organize messages. It has been possible to improve the reliability of email communications by using various types of certificates authenticating the genuineness of the sender and the integrity of the message. Communications between companies has become more fluent with the aid of email. In the continuous revolution in communications technology, email has remained a 'familiar and secure' form of communication. It is useful, as nearly everyone has email available. The recipient need not be online simultaneously with the sender. Email is a handy way to send various types of attached files.

From the user's point of view, email communication is problematic, because in various connections long chains of messages form, in which there are numerous messages on the same subject. Users reply to questions that have already been answered in the chains, and long discussions are difficult and tiring to read through. Unnecessary signatures are repeated up to tens of times in the same message chain, and the number of messages often grows to become exhaustingly large, simply because of simple replies of perhaps only one line. For example, there may be ten replies to a single message. It is difficult for the user to choose which message to reply to. For particularly the aforementioned reasons, the use of email as an instant messenger is often frustrating. Different types of solution and system have been developed for instant messaging. From the user's point of view, they have the advantage of the rapid contactability of a discussion partner. With the aid of instant messengers, quick and short discussions can be held effectively. It can be seen from an instant messenger whether the desired recipient of an instant message is, in principle, contactable, for example, whether they are in online, or available for a discussion. With the aid of instant messengers, messages are transmitted rapidly and instant messengers provide the basic properties for group work.

Instant messengers are problematic from the point of view of the user, if it is wished to store, search for, organize, and authenticate messages. For these reasons among others, the use of instant messengers is difficult in communications between companies. The older generation is used to email and instant messengers are mainly used by the younger generation. Thus, in practice few can be contacted using an instant messenger. The recipient should be online, if the most important advantages of instant messaging are to be achieved. It is impossible, or at least problematic to transmit file attachments by instant messenger. New participants in instant-messaging discussions do not see the old messages in the discussion. In addition, it is difficult for discussion participants to reply to a specific desired question or message if they are not quick.

One known discussion forum according to the prior art is Suomi24. This uses a hierarchal form of presentation of messages displayed under a discussion heading, in a form readable on a user terminal. On these discussion forums, a reply to a specific message in the chain can be received from a user terminal and displayed out of chronological order, as a reply to a specific message, in a form readable from different user terminals. From the user's point of view, this allows replies to be made in between, compared to the chronological presentation order of the messages.

In a technical sense, in order to create Suomi24's hierarchal display form, an identifier for each reply message received from a user terminal, information as to the message that this reply message is a reply to, and the date of this reply message are stored in the discussion service provider's database. An identifier for the entire message chain can also be stored in the database. The hierarchal message display form used by Suomi24 is not, however, very common on internet discussion forums. The most usual is a chronological message display form, combined with means for lifting the text content of previous messages into the text context of a reply message, in order to correctly assign the reply message.

Application publication US 2008/0208994 discloses a method and email system for improving the efficiency of an email discussion. The publication describes using an email tag filter for filtering a particular tag from email contents, for referencing original email contents, and for identifying information relating to the tag, which comprises at least one writer name corresponding to the email contents. The invention distinguishes different users mainly by automatically labelling the content entered by each user, the entered content being able to be distributed to different stations in an individual email, which is compatible with the email procedure of existing users. Thus, the solution organizes the messages according to a desired criterion, but the solution according to the publication is not suitable for organizing message chains.

Application publication US2008/0215687 Al discloses a mechanism for creating a composite email in an email discussion. The composite email contains contents, which are automatically referenced from numerous emails in an email discussion, and which can be generated in response to the user accessing only one email in the email discussion. A method is also disclosed for finding and restoring emails that have become lost in the discussion. A method is also disclosed for automatically transferring emails from one container to another after the email has been read. Here these and other advantageous forms of creating, editing, and organizing email are disclosed. The solution of the publication, however, does not create unequivocal hierarchal message chains from the messages, but instead classifies the messages fuzzily according to their message content.

Google's gmail, which is in accordance with the prior art, permits instant-message discussions between email users on the basis of email address, routed with the aid of an email server, and with the email username as the user identifier. This solution is not compatible with normal email. Using the system according to the solution, the writer of a message cannot assign further messages as reply messages to a specific message in the chain, but the message writer must refer in the text field to the message to which they are replying, leaving it up to the recipient of the message to determine how to assign the messages on the basis on the content of the text field. This solution also does not permit attachments to be sent.

The invention is intended to create a technical solution, which makes good the deficiencies in email and instant messengers, as well as in discussion forums, and solves their problems.

The invention is based on the fact that, during the transmission of messages, the first message, in which there is no reference to other messages, is equipped with a message- chain identifier, which is unequivocally only for this message and which cannot be confused with the message-chain identifier of other messages, the message-chain identifier of the first message is included in all messages that are direct or indirect replies to the first message, and the messages of the same message chain are grouped together at least for the user interfaces.

One preferred embodiment of the invention is characterized by constructing a form of communication, which operates using a protocol-independent distributed database model, with the aid of which the messages come to the user, so that the user does not have to checkif new messages have arrived, and which combines the speed and ease of instant-messenger communications with email's better message archiving and intercompany communications properties.

More specifically, the method according to the invention is characterized by what is stated in the characterizing portion of Claim 1.

For its part, the system according to the invention is characterized by what is stated in the characterizing portion of Claim 14, and the computer-program product according to the invention is characterized by what is stated in the characterizing portion of Claim 11.

With the aid of the invention, a technical solution is created, which makes good the deficiencies of email and instant messengers and solves their problems.

When using stackmail, only one header datum is required for each message chain in the message listing, and no separate listings of sent or incoming messages are required. The messages can be organized hierarchically or chronologically in response to a command received from the user's terminal. As everything relating to the same discussion is seen in a single chain, no caption or space-taking repeated signatures are required. Nevertheless, a stackmail system can provide normal email properties, such as sending and receiving attachments, such as images. Even though the view properties of a stackmail might be very similar to those of known discussion-forum implementations, a stackmail has the advantage that the user does not have to retrieve different pages, for example discussion-forum pages, and check if messages have arrived. In addition, there is no certainly about the security of known discussion forums, nor can the visibility of messages in them be limited by user, in a manner controllable by the user.

In the following, the invention is examined with the aid of examples and with reference to the accompanying drawings.

Figure 1 shows a structure and operation diagram of the construction of one stackmail system according to the present invention and of operation in the stackmail server system.

Figure 2 shows one screen view produced by the solution according to Figure 1.

Figure 3 shows a second screen view produced by the solution according to Figure 1.

Figure 4 shows a screen view from one stackmail solution according to the present invention, which is retro-compatible with email.

Figure 5 shows a screen view from the user interface of one stackmail system according to the invention, in an email program.

The stackmail system according to Figure 1 is constructed from a distributed database- based communications environment. The figure contains the following numbered elements:

I Internet

10 First stackmail-community system

I 1 Database DB of first stackmail community

12 Stackmail server of first stackmail community

13 First user terminal of first stackmail community

14 First user terminal 14 of first stackmail community

20 Second stackmail-community system

21 Database of second stackmail community

22 Stack-message server of second stackmail community

23 First user terminal of second stackmail community

24 Second user terminal of second stackmail community

1On System of nth stackmail community (n being an integer (series) from the 3 ^rd in the number of stackmail communities in the communications environment)

1On + 1 Database

1On + 2 Email server, which can also be a stackmail server

1On +3 User terminal 1On + 4 User terminal

The following numbered elements are used in the screen view according to Figure 2:

201 Stackmail base-message sender field

202 Stackmail recipient field

203 Stackmail base-message time stamp

204 Stackmail base-message message field

In the screen view according to Figure 3, the following numbered elements are used in addition to the numbered elements of Figure 2:

301 Stackmail continuation-message sender field

303 Stackmail continuation-message time stamp

304 Stackmail continuation-message text field

The following numbered elements are used in the screen view of Figure 4:

400a Stackmail message-chain identifier

400b Instruction message for later users of a stackmail base message

401a Stackmail base-message sender field

401b Stackmail base-message sender field

402a Stackmail recipient field 402b Stackmail recipient list

403 Stackmail base-message time stamp

404 Stackmail base-message message field

405 Stackmail base-message identifier

406 Stackmail base-message reply field

411 Stackmail first continuation-message sender field

413 Stackmail first continuation message time-stamp

414 Stackmail first continuation-message message field

415 Stackmail first continuation-message identifier

416 Stackmail first continuation-message reply field

421 Sender field of continuation message to stackmail first continuation message

423 Time stamp of continuation message to stackmail first continuation message

424 Message field of continuation message to stackmail first continuation message

425 Message identifier of continuation message to stackmail first continuation message

426 Reply field of continuation message to stackmail first continuation message

431 Stackmail second continuation-message sender field 433 Stackmail second continuation-message time stamp

434 Stackmail second continuation-message message field

435 Stackmail second continuation-message message identifier

436 Stackmail second continuation-message reply field The following numbered elements are used in the screen view of Figure 5:

510 Mail-folder list

511 Stackmail folder

520 Stackmail-chain listing

521 Stackmail chain 530 Stackmail chain 521 opened in window

531 Notification of order of stackmail chain 521

532 Stackmail chain 521 heading

533 Name (or identifier) 533 of person starting stackmail chain 521

534 Names (or identifiers) 534 of recipients of stackmail chain 535 Stackmail chain 521 base message

536 Base-message 535 continuation message 537 Continuation-message 536 continuation message

538 Base-message 535 second continuation message

539 Base-message third continuation message

540 Attachment to third continuation message 539

541 First button

542 Second button

543 Third button

544 Fourth button

In the following, operation according to one preferred embodiment of the invention is described with the aid of Figures 1 - 3.

In the stackmail system according to Figure 1, each stackmail community, such as a company or organization, or at least each operator has, in the system 10, 20, ..., n, a stackmail server 12, 22, ..., 10n+2 for its own stackmail community, which can be at the same time an email server, and a database 11, 21, ..., lOn+1 connected to it, in which the stackmail messages are located.

The screen views according to Figures 2 - 3 are produced by means of the stackmail system according to Figure 1. Each stackmail server 12, 22, 32 of the stackmail- community system 10, 20, 30 of the user terminal 13, 23, 24, 33, 34 participating in the message chain producing the screen views of Figures 2 and 3 has its own copy of each message in a database 11, 21, 31, from which the chain is displayed to the user in the desired display mode, which can be, for example, hierarchal or chronological.

In the embodiments according to Figures 1 - 5, the content of a stackmail is sent in XML (extensible Markup Language) form, which can besides text contain images, attachments, and applications implemented using stackmail, coded in HTML (Hypertext Markup Language), such as voting or questionnaires. The message is transmitted with the aid of the ESMTP (Extended Simple Mail Transfer Protocol), utilizing freely definable x-prefixed extensions. Using these, a suitable form for the situation can be selected, by means of which the message is sent, thus achieving retro-compatibility. In all of the embodiments according to Figures 1 - 5, stages 101 - 103 are performed. They are performed in order to determine the recipient's stackmail readiness.

101) A connection is opened from server 22 to severs 12 and 32.

102) A transfer-respond message mail.company.(10 or 30) ready for ESMTP is received 220 from servers 12 and 32 by server 22.

103) An EHLO message is sent from server 22 to the receiving servers 12 and 32.

In the embodiments according to Figures 1 - 3, stages 104 - 108 are also performed in order to transmit the exchange of messages between the user terminals 13, 23, 24, and 34 and to display them with stackmail. hi the embodiments according to Figure 4 and Figure 5, similar stages are performed, with certain exceptions defined later.

104) In response to the EHLO message, reply messages are received from the severs 22 and 32, which comprise greetings, such as 250- mail.company.(10 or 30) Hello mail.company.20[10, 10, 10, 10], pleased to meet you, and normal email reception comments, such as

250- VRFY

250-ENHANCEDSTATUSCODES 250-8BITMIME 250-ETRN,

250-DSN , and

250 HELP as well as a command reporting readiness to receive stackmail, such as 250-XSTACKMAIL

In the embodiment according to Figures 1 - 3, stackmail is selected, because the servers 12 or 32 reply "250-XSTACKMAIL". Normal email is selected, if the receiving server does not reply "250-XSTACKMAIL". First of all a case according to the screen views of Figures 2 and 3, in which the server 12 replies "250-ST ACKMAIL", will be reviewed.

The task of the sending server 22 is to send a stackmail identifier, i.e. a stackmail ID, i.e. the identifier of the message chain, which identifies the message chain, and which the sending server should create in connection with the first message of the message chain, an MsgID, i.e. a message identifier that identifies each individual message and which the sending server should create in connection with the transmission of the message, as well as an MsgSent time stamp, which is the transmission time of the message in local time according to the ISO 8601 standard, in connection with the transmission of each message.

105) The server 22 sends, to the receiving servers 12 and 32, a stackmail identifier, such as XST ACKMAIL 1D:{9E57B4E2-8OAF-481F-8AF2- 0AFB4A724CBC},

a message identifier, such as MsgID:{3138664F-EA23-4B98-96F0- 22FA55F3AEB4},

the transmission's time stamp, such as MsgSent: 2008-10-

17T14:08: 16+03, as well as a normal exchange of messages, which is used in order to send an email message from the sending server and to receive the message on the receiving server, takes place between the sending server 22 and the receiving servers 12 and 32, such as the following:

250 2.5.0 OK <- (from servers 12 and 32 to server 22) MAIL FROM:User24@company.20-> (from server 22 to servers 12 and 32)

250 2.5.0 OK <-

RCPT TO:<Userl3 ©company.10>ORCPT=rfc822;User 13® company.10->

250 2.5.0 OK. <-

DATA ->

354 3.5.4 Start mail input, end with <CRLF>,<CRLF>, <-

and sends the content of the stackmail message "How's this working?"

204 sender "From: 24" 201 and recipient data "To: 23, 13, 33, 34" 202 from server 22 to servers 12 and 32.

106) Perform connection setdown routines. A message acknowledging receipt of the stackmail, such as 250 2.5.0 Received message qnnbcaaa OK, is received by the server 22 from the servers 12 and 32, and the exchange of messages required to set down the call is performed, such as

107) the "command" QUIT is sent form server 22 to servers 12 and 32 and the connection is set down.

The means for displaying the screen view according to Figure 3 are obtained, when the normal connection-creation operations and stage 108 are performed. Stage 108 is performed immediately after stage 105. In stage 108, the following is performed in brief:

108) A reply identifier InReplylD, which is the MegID of the message of stage 105, and the related stackmail continuation message 304, are received by server 22 (and 32) from server 12. More specifically, in stage 108 the following are received by server 22 (and 32) from server 12

a stackmail identifier, such as XSTACKMIAL ID: { 9E57B4E2-80AF-

481F-8AF2-0AFB4A724CBC } ,

a message identifier, such as MsgID:{30DCEA0A-5363-45BD-BF45- 8EE10DF9858A},

a reply identifier, such as InReplylD: {3138664F-EA23-4B98-96F0- 22FA55F3AEB4}, and

a transmission time stamp, such as MsgSent: 2008-10-17T14:09:36+03

and a normal exchange of messages takes place between the sending server 12 and the receiving server 22 (and 32), which is used in order to send an email message from the sending server and to receive the message at the receiving server, and

the contents "Seems to be working really well" 304 of the continuation message of the stackmail message is transmitted, together with the sending data "From: 13" 301 and a time stamp "17.10.2008 14.09" 303, from server 12 to server 22 (and 32), in order to display the stackmail chain according to the screen view of Figure 3 on the user terminal(s) 23,

24 (13, 33, and 34).

Transmitting stackmail messages using the IM/SIP protocol:

Stackmail messages can also be transmitted by using the instant messaging (IM, Instant Messaging / SIP (Session Initiation Protocol) protocol, or in some other corresponding manner, as long as the same data; ID, MsgID, MsgSent, and if necessary InReplylD travel with them. In order to determine the support of the IM / SIP protocol, it is possible to use, for example, DNS data (Domain Name System, the internet name-server system) TXT records, by means of which the necessary server addresses can be transmitted. If the instant-messaging protocol is implemented with the aid of a centralized-server model, information on support for stackmail can also be placed on the centralized server.

When transmitting stackmails over instant-messaging protocols and/or SIPs, transmission in (essentially) real time is possible. In communications between companies over email servers, stackmails are subject to the normal delays of emails. Of course, even then, when using the IM/SIP protocol, transmission of stackmails takes place in (essentially) real time.

Retro-compatibility with email according to Figure 4:

If the email server 10n+2 does not reply to the EHLO message 250-XST ACKMAIL, or does not understand the EHLO message, the stackmail is sent instead converted to normal email. In the email, the stackmail identifier 400a, on the basis of which reply messages are attached to the correct message chain, is sent after the heading in the heading field. The stackmail identifier 400a is similar to, for example, the stackmail identifier XST ACKM AIL ID according to Figures 1 - 3. The preface 400b to the message tells the message-chain participants 402b what the message is about: "This is a stackmail, when replying please write only where there are Answer here messages in the message chain. Your message will be delivered to all the participants in the chain. You can attach files normally" and the chain participants 402b: "In the message chain: Kukkaro Matti <matti.kukkaro@ company. fi>, Torronen Edward <edward.torronen@ municipality. fi>, Tester Teppo <teppo@ tester. com>" .

The replies 404, 414, 424, 434 written between the ID tags 405, 415, 425, 435 within the message are sorted into the correct places and sent to all the participants 402b in the discussion. In the message, the message chain that has been written so far is displayed hierarchically, and at the start of the message a 'reply to this' portion 406, 416, 426, 436, in which the user is instructed to write their possible reply. A reply identifier, like the example according to Figures 1 - 3, is created to correspond to each 'reply to this' portion 406, 416, 426, 436, with the aid of which the stackmail continuation messages are displayed hierarchically logically on the user terminals of the stackmail participants (or of other readers). The message is sent back only to those 401a and 401b who have sent a message, whose stackmail server takes care of parsing and forwarding to the other participants 402b in the message chain.

The screen view of Figure 5 shows the user's mail folders 510, one of which is a stackmail folder (511). The screen view also shows the message listing marking 520 of the stackmail chains in the stackmail folder 511, arranged in temporal with heading, participants, and time-stamp data. Here, there is only one stackmail chain, the stackmail chain 521. The stackmail chain 521 can be seen opened in the window 530. It comprises a notification of the type of order 531, the heading 532 of the stackmail chain, the name (or code) of the originator 533 of the stackmail chain, the names (or codes) of the recipients 534 of the stackmail chain, as well as the base message 535 of the stackmail chain:

"Hi! What do you think of this Stackmail?",

continuation message 536 to base message 535:

"Seems to be working well, doesn't it?",

continuation message 537 to continuation message 536:

"That last message came through to me well",

second continuation message 538 to base message 535:

"These messages came up great on my screen at least",

as well as a third continuation message 539 to base message 535: "Looks really good, did the images and attachments get through?" with attachment 540:

"New strategy. doc" '.

In addition, the screen view shows buttons 541 - 544, the response to clicking on which is set to be the opening of the sender and recipient fields as well as of the time stamp of the message relating to the button.

Thus, in the message listing 520 of the stackmail folder 511, the user is shown only one message-listing marking 521 per message chain, which facilitates discussion. It is preferable to set the order (chronological or hierarchal) of the message chains (opened) formed of stackmails to be in response to the choice received from the user terminal, hi order to implement the example according to Figure 5, stackmail identifiers and reply identifiers are used, as in the examples of Figures 1 - 4, even though they do not appear in Figure 5.

It is preferable to implement the stackmail system according to the figures on top of, for example, the ESMTP (Enhanced Simple Mail Transfer Protocol) email protocol. It is preferable to construct the stackmail system on top of an email program (and server), in which case the existing infrastructure can be exploited as the basis of the solution. The usability and data security requirements of communications between companies can be designed into the stackmail system from the very start, making the stackmail system simple and familiar to use. It is preferable to make stackmails retro-compatible with conventional email, and to set the storage, retrieval, and certificates of the message chain to function as in conventional email, however, such that the message chain is displayed as one message in the message listing of the stackmail program.

On the basis of the examples described above, it is obvious that numerous solutions differing from the embodiments depicted above can be implemented within the scope of the invention. Thus, the invention is not intended to be restricted to apply to only the examples described above, but instead the patent protection should be examined within the full extent of the accompanying Claims.