Browse Prior Art Database

Application of a single moveable input box to allow concise realtime instant multi-threaded messaging

IP.com Disclosure Number: IPCOM000193027D
Original Publication Date: 2010-Feb-08
Included in the Prior Art Database: 2010-Feb-08
Document File: 7 page(s) / 324K

Publishing Venue

IBM

Abstract

A mechanism for providing a single movable input box in a real-time multi-threaded instant messaging application. The user will have the ability to use their keyboard or other input devices to move the input box to the location of where they want to enter their message and the associated thread hierarchy.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 7

Application of a single moveable input box to allow concise realtime instant multi-threaded messaging

Disclosed is a mechanism whereby an instant messaging application can reposition the single input box within a message hierarchy to enable users to relate their new messages to an existing location in the conversation thread. This will allow them to type within context and the message can be inserted in that contextual location once submitted.

Instant messaging conversation between multiple users can often become disjointed and confusing when there are multiple threads of conversation happening within the same session. For example,
Example 1.1
Person 1: How are you today?

Person 2: Ok
Person 3: Has anyone seen John?

Person 1: No
Person 4: Good thanks
...

Here in example 1.1, Person 2 and 4 are replying to Person 1's initial question, but Person 3 has interjected with another question which splits the context of responses. Example 1.2
Person 1: Have you completed your tasks from yesterday?

Person 2: Yes
Person 3: Is Dave in today as I need to discuss my task with him?

Person 4: Yes
In example 1.2, we have illustrated that the answer Person 4 has provided, it is extremely difficult to know whether they are answering Person 1's or Person 2's question. In reality, the only way to know this would be to do one of the following: Make a decision about the timing of Person 4's answer. If the message was received within a second of the new question, then it is reasonably unlikely that it is an answer to the question posed by Person 3. However, this relies on a person either watching the conversation or analysing the time-stamps of the messages
Ask for Person 4 to clarify who they were answering which adds more complexity to the conversation
A common approach would be for a user supplying an answer, they would provide extra information in their message to indicate which question they are answering. E.g. "Yes, I have completed my task from yesterday", or "Person 1 - Yes". However, this assumes that the person responding to the conversation expects that there will be multiple questions in the conversation at the point they are typing their response. This invention solves the problem of correlating message response interactions in a multi-person conversation session.

The implementation of the solution can be broken down into two distinct parts.
1. Display of a multi-threaded conversation in a real-time chat
This works by rendering the conversation content in a hierarchy. When a new message is received by the client, the message will have a parent ID of which the client can locate within it's stored message history, and insert a child message under the parent message. This will all...