US20030154251A1 - Communication support method and communication support system - Google Patents

Communication support method and communication support system Download PDF

Info

Publication number
US20030154251A1
US20030154251A1 US10/386,666 US38666603A US2003154251A1 US 20030154251 A1 US20030154251 A1 US 20030154251A1 US 38666603 A US38666603 A US 38666603A US 2003154251 A1 US2003154251 A1 US 2003154251A1
Authority
US
United States
Prior art keywords
user
status
text information
communication device
network
Prior art date
Legal status (The legal status 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 status listed.)
Abandoned
Application number
US10/386,666
Inventor
Ai Manabe
Satoshi Okuyama
Jun Kakuta
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
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 Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to US10/386,666 priority Critical patent/US20030154251A1/en
Publication of US20030154251A1 publication Critical patent/US20030154251A1/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/02Details
    • H04L12/16Arrangements for providing special services to substations
    • H04L12/18Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1813Arrangements for providing special services to substations for broadcast or conference, e.g. multicast for computer conferences, e.g. chat rooms
    • H04L12/1827Network arrangements for conference optimisation or adaptation
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00Administration; Management
    • G06Q10/10Office automation; Time management
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/02Details
    • H04L12/16Arrangements for providing special services to substations
    • H04L12/18Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1813Arrangements for providing special services to substations for broadcast or conference, e.g. multicast for computer conferences, e.g. chat rooms
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/04Real-time or near real-time messaging, e.g. instant messaging [IM]

Definitions

  • the present invention relates to technology for promoting user conversation and smoothing the flow of communications in a system wherein a plurality of computer users mutually share the same network, enabling simultaneous conversation.
  • chat system refers to a system comprising a chat server and a plurality of chat clients, wherein chat clients share the same space and can conduct conversations.
  • a “channel” refers to a virtual space shared by the chat clients.
  • a “nickname” refers to identification information used to specify uniquely a user in the chat system.
  • chat client detects whether a user-registered keyword is included in the remarks from another chat client. If a keyword is detected, the chat client consults the self-status previously set by the user, and notifies the other chat client that uttered the keyword of the user's self-status. Examples of user self-status designations that are registered include “away from desk” and “absent.”
  • a chat system is also provided that gives notification not only of the self-status, but also of a predetermined message in accordance with the self-status.
  • the chat client cannot respond to the utterance of a keyword from another client if the user forgets to set his or her self-status. Moreover, unless a user sets self-status by him or herself, user status, such as the user's location and actions, will be completely unknown to other users. For example, even if a user sets the self-status to “absent” when leaving his or her desk, there is a tendency for the user to forget to reset the self-status to “present” upon returning. If a keyword is uttered by another chat client in this situation, even though the user himself or herself tries to respond, the chat client ends up sending a message to the effect that the user is absent.
  • the object of the present invention is to smooth the flow of communications among network computer users conducting conversations in real time.
  • a first aspect of the invention in the present application presents a communication support method wherein a plurality of users mutually share the same network, used in a communication device that is simultaneous, bi-directional communication-enabled. The method provides
  • a chat system comprising a chat server and a chat client as an example will illustrate:
  • User A stores a keyword on the terminal of user A. If a keyword registered by user terminal A is uttered by another user terminal B on a channel #CH1 in which user terminal A is participating, the utterance of that keyword is detected by user terminal A. Next, user terminal A detects the status of user A. For example, the fact that a screen saver is operating or that a text message is being composed on another channel is detected. Subsequently, notification is given of the detected status to user terminal B on the channel on which the keyword was uttered.
  • a second aspect of the invention in the present application presents a communication support system wherein identical networks are mutually shared, used in a communication device that is simultaneous bi-directional communication-enabled.
  • the communication support system is provided with a first storage means, a detection means, a decision means and a reporting means.
  • the first storage means stores predetermined text information correlated with communication devices on a network.
  • the detection means detects the sending of any text information from a first communication device on a network.
  • the decision means in accordance with the detection of the text information, based on the status of a second communication device correlated with the detected text information judges the user status of the second communication device.
  • the reporting means sends the user status to the network to which the text information was sent.
  • the first storage means correlates user keywords with users. If a keyword registered by user terminal A is uttered by another user terminal B on a channel #CH1 in which user terminal A is participating, that keyword is detected by the detection means in user terminal A.
  • the decision means in user terminal A judges the status of user A based on the status of user terminal A. For example, the fact that a screen saver is operating or that a text message is being composed on another channel is detected, and the status of user A is thereby judged. Examples of user situations include “absent,” “working,” and “responding.”
  • the decision means sends the judged user status to the reporting means.
  • the reporting means uses a chat client and notifies the other user terminal of the status of user A on channel #CH1.
  • a decision means is provided in each user terminal.
  • the first storage means, detection means and reporting means may be provided in each user terminal and, moreover, may be provided in any information terminal that can run the chat client.
  • a third aspect of the invention in the present application is the communication support system according to the second aspect of the invention, but further presents a second storage means that stores communication devices that report user status and text-information sending-source communication devices, correlated with the communication devices on the network.
  • the communication support system reporting means determines user status report destinations in accordance with the second storage means, and reports the user status to the report destination via the network.
  • the second storage means stores a report destination table, wherein are recorded, for instance, content such as the following.
  • the report destination is set to user terminal B if the keyword was sent from user terminal B, and the report destination is set to user terminals B, C if the keyword was sent from user terminal C.
  • the remark source of the keyword and the report destination of the user status are also set for other user terminals. If the user wants to give notification of the status of another communication device other than the communication device that sent the keyword, the user can specify the report destination using the report destination table.
  • a fourth aspect of the invention in the present application is the communication support system according to the second aspect of the invention, but further presents a third storage means that stores user schedules correlated with communication devices.
  • the reporting means in this communication support system determines the user status to be sent to the network based on the judged user status of the second communication device and based on the schedule corresponding to the second communication device.
  • the third storage means stores the previously described schedule list wherein user schedules are correlated with the users. If the status of user A is judged to be “absent,” then the reporting means consults user A's schedule. If the user A's schedule is “Afternoon business trip to Tokyo,” then the reporting means sets “Afternoon business trip to Tokyo” as the report content. By providing the schedule list beforehand and combining it with the detected user status, a much more detailed user-status notification can be given.
  • a fifth aspect of the invention in the present application is the communication support system according to the second aspect of the invention, but further presents an acquisition means that detects whether the second communication device is operating, and acquires the user status from the decision means in accordance with the detection results.
  • Each user terminal is provided with a status reporting means.
  • the proxy terminal is provided with a first storage means, a detection means, an acquisition means and a reporting means. If the detection means detects a user A keyword, the acquisition means judges whether user terminal A is running. If it is running, the acquisition means makes a request to user terminal A to determine the user status, and then receives notification of the user status from user terminal A. The received user status is sent to the reporting means. Conversely, if user terminal A is not running, the acquisition means notifies the reporting means to that effect. By providing the acquisition means, the user status can be reported even if the user terminal is not running.
  • a sixth aspect of the invention in the present application is the communication support system according to the second invention, but further presents a display means that visually displays the status of each user sharing the network, and that can change the display in accordance with the user status sent from the network.
  • icons are prepared beforehand that indicate each of the following situations “absent,” “busy,” and “responding.” Then, if notification of a user status is given by another communication device, the display means changes the icon of that user to an icon that indicates the reported status.
  • a seventh aspect of the invention in the present application presents a status notification device used together with a communication device that is simultaneous, bi-directional communication-enabled wherein a plurality of users mutually share the same network.
  • the status notification device is provided with a first storage means, a detection means, a decision means and a reporting means.
  • the first storage means stores predetermined text information.
  • the detection means detects the sending of the text information from another communication device on a network.
  • the decision means in accordance with the detection of the text information, judges user status based on the status of the communication device.
  • the reporting means sends the user status to the network to which the text information was sent.
  • Actions/effects here are likewise as with the communication device in the second aspect of the invention wherein constituted without using a proxy terminal.
  • An eighth aspect of the invention in the present application presents a proxy device used in communication device that is simultaneous, bi-directional communication-enabled wherein a plurality of users mutually share the same network.
  • the proxy device is provided with a first storage means, a detection means, an acquisition means and a reporting means.
  • the first storage means stores predetermined text information correlated with users.
  • the detection means detects the sending of any text information from a first communication device on a network.
  • the acquisition means in accordance with the detection of the text information, detects whether a second communication device correlated with the detected text information is operating, and acquires from the second communication device the user status of the second communication device in accordance with the detection results.
  • the reporting means sends, to the network to which the text information was sent, the user status based on the detection results, or the acquired user status.
  • Actions/effects here are likewise as with a proxy terminal in the second aspect of the invention, wherein each user terminal is provided with a judgement means and the proxy terminal bears other functions.
  • a ninth aspect of the invention in the present application presents a computer readable recording medium on which is recorded a status notification program used together with a communication device that is simultaneous, bi-directional communication-enabled wherein a plurality of users mutually share the same network.
  • the status notification program is recorded for executing steps A to D below.
  • (D) a step of sending the user status to the network to which the text information was sent.
  • a tenth aspect of the invention in the present application provides a computer readable recording medium on which is recorded a proxy notification program wherein a plurality of users mutually share the same network, used in a communication device that is simultaneous, bi-directional communication-enabled.
  • the proxy notification program is recorded for executing steps A to D below.
  • (C) a step of finding, in response to the text information detection, whether the second communication device correlated with the detected text information is operating, and acquiring the second communication device user status from the second communication device in accordance with the detection results, and
  • (D) a step of sending the user status based on the detection results, or the acquired user status, to the network to which the text information was sent.
  • Utilizing the present invention enables communications to flow smoothly since users engaged in real-time conversation using text messages can determine each other's situations in real time as needed.
  • FIG. 1 is a diagram of the overall configuration of a communication support system according to the first embodiment
  • FIG. 2 is a block diagram illustrating the configuration of a user terminal in the first embodiment
  • FIG. 3 is an explanatory diagram illustrating a keyword list example
  • FIG. 4 is an explanatory diagram illustrating a report destination table example
  • FIG. 5( a ) is an explanatory diagram illustrating an example of displaying “away from desk” status by a text message
  • FIG. 5( b ) is an explanatory diagram illustrating an example of displaying “away from desk” status by an icon
  • FIG. 6( a ) is an explanatory diagram illustrating an example of displaying “busy” status by a text message
  • FIG. 6( b ) is an explanatory diagram illustrating an example of displaying “busy” status by an icon
  • FIG. 7 is an explanatory diagram illustrating an example of displaying “responding” status by a text message
  • FIG. 8 is an explanatory diagram illustrating an example of displaying a text message combined with a schedule
  • FIG. 9 is a flowchart illustrating process flow of a main routine executed by the status notification device in the first embodiment
  • FIG. 10 is a flowchart illustrating process flow in a status-judging routine
  • FIG. 11 is a flowchart illustrating process flow in a judge absent subroutine
  • FIG. 12 is a flowchart illustrating process flow in a judge working subroutine
  • FIG. 13 is a flowchart illustrating process flow in a judge responding subroutine
  • FIG. 14 is a diagram of the overall configuration of a communication support system according to the second embodiment.
  • FIG. 15 is a block diagram illustrating the configuration of a proxy terminal and user terminal in the second embodiment
  • FIG. 16 is an explanatory diagram illustrating one example of information in a keyword DB
  • FIG. 17 is an explanatory diagram illustrating one example of information in a report destination DB.
  • FIG. 18 is a flowchart illustrating flow of a routine that the proxy notification device in the second embodiment executes.
  • FIG. 1 is a diagram illustrating the entire configuration of the communication support system according to the first embodiment.
  • a chat server and a plurality of user terminals are connected via a computer network.
  • FIG. 2 is a block diagram illustrating the configuration of the user terminal of the present embodiment.
  • the user terminal shown in FIG. 2 is provided with a chat client and status notification device 1 .
  • Status notification device 1 is provided with a keyword-detection module 2 , a keyword list 3 , a status-detection section 4 , a reporting module 9 , a report destination table 10 , a schedule list 11 and a display module 12 .
  • the keyword-detection module 2 acquires from the chat client the remarks in the channel in which the chat client is participating. The keyword-detection module 2 judges whether the acquired remark is sent from another user terminal or inputted by the local terminal. If it is a remark from another user terminal, the keyword-detection module 2 judges whether a keyword registered by the user is included in the acquired remark. This decision is made based on the keyword list 3 , which is discussed later. If a keyword is included in the remark, the keyword-detection module 2 instructs the status-detection section 4 to detect the user status. This instruction is executed by the keyword-detection module 2 notifying the status-detection section 4 of the name of the channel on which the keyword was uttered, and the nickname of the user that uttered the keyword.
  • FIG. 3 is a diagram illustrating an example of a keyword list 3 registered by a user.
  • users normally register their real names and nicknames.
  • a user will register an “all,” which is a keyword common to all users on the channel.
  • user “Tamie Tanaka” has registered her real names “Tanaka” and “Tamie” as well as her nickname “tana” and “all” as keywords.
  • the keyword list 3 can be registered by the user or may be automatically created. For example, it is possible to register automatically the user's real name, nickname and “all” as keywords, and for other keywords to be additionally registered by the user.
  • the status-detection section 4 judges user status in accordance with an instruction from the keyword-detection module 2 . This is in order that the real-time status of user terminal B is reported when user terminal A calls user terminal B. In the present embodiment, the status-detection section 4 judges whether the user status is either “absent,” “working” or “responding.” When the status-detection section 4 has judged the user status, it notifies the reporting module 9 of the user status. In addition, along with the user status, the status-detection section 4 notifies the reporting module 9 of the name of the channel on which the keyword was uttered and the nickname of the user that uttered the keyword.
  • the status-detection section 4 has an event-detection module 5 , a screen saver detection module 6 and a recording module 7 for judging user status.
  • the event-detection module 5 detects the presence of user input (hereinafter referred to as an event), such as whether there is any keyboard input or whether the mouse is moving.
  • the event-detection module 5 detects whether the user input is directed to a channel on chat or whether it is input in an application other than chat.
  • the screen saver detection module 6 detects whether the user terminal screen saver is operating.
  • the recording module 7 creates an event table 8 and records in the event table 8 events that occur within a predetermined time, along with the time of the events.
  • the reporting module 9 notifies the other user terminals, via the chat client, of the user status reported by the status-detection section 4 .
  • the report destination user terminals are determined based on the report destination table 10 .
  • FIG. 4 shows an example of a report destination table 10 .
  • the nickname of the user that uttered the keyword is registered in the report destination table 10 as the call source user.
  • the report destination user(s) who are notified of self-status for keyword utterances from a call source user are correlated with each call source and registered. It is possible to specify that notification be given of the self-status only to the call source, or that notification be given to all users on the channel. In addition, a plurality of users can also be specified as the report destination. In FIG.
  • user A specifies “oku” as the report destination if the call source user is “oku.” If the call source user is “sasa,” then “sasa” and “tana” are specified as report destinations. If the call source user is “yama,” then all users (“all”) are specified as report destinations.
  • the report destination table 10 is prepared in advance by any means, such as registering by a user.
  • the reporting module 9 determines which text message among text messages prepared in advance is to be reported. Next, the reporting module 9 issues the text message on the call source channel. The status of the called user is thereby reported to the report destination user.
  • the reporting module 9 may also give notification to the report destination of a text message or, in place of a text message, information indicating the user status (hereinafter referred to as the status information). Notification of the status information is given via the chat client.
  • the report destination user terminal that receives this status information displays an icon indicating the user status, for example.
  • the status information may be a text message or may be other information such as a control command.
  • the reporting module 9 determines the text message based on the user status reported by the status-detection section 4 and based on a pre-registered schedule list 11 (not shown).
  • the user registers the user's schedule status in the schedule list 11 .
  • the user registers plans, such as “at work,” “business trip,” “meeting” and “yearly vacation,” correlated with date, time and destination.
  • the reporting module 9 when the reporting module 9 receives notification of an “absent” user status from the status-detection section 4 , it consults the schedule list 11 .
  • the schedule list 11 “business trip” is registered as the schedule for that time and “Tokyo” is registered as the destination. Thereupon, the reporting module 9 sets “Business trip Tokyo” as the text message to be reported. Conversely, if the schedule in schedule list 11 is “at work,” the reporting module 9 sets “Presently away from desk” as the text message to be reported. However, if the user status is “responding” or “working,” the reporting module 9 does not consult the schedule list 11 .
  • the display module 12 displays a window on the screen for each channel in which the chat client is participating. Furthermore, the display module 12 displays, in these windows, icons that indicate the status of each user participating in the channel.
  • FIG. 5 to FIG. 8 are examples of screen shots wherein icons indicating user situations are displayed by the display module 12 .
  • the display module 12 displays an icon for each user on the channel, and the status of each user participating on the channel is visually indicated. Icons are prepared in advance in accordance with predetermined status information.
  • the display module 12 changes the icon to be displayed based on the status information for other user terminals, sent from the reporting module 9 . For example, if a text message corresponding to “away from desk” is sent from another user terminal as the status information, the display module 12 changes the icon that indicates the status of that user to an “away-from-desk” icon.
  • FIG. 5 to FIG. 8 are examples of screen shots wherein the display module 12 of the report destination displays text messages and icons reported by the reporting module 9 at the call source.
  • Text messages and icons are prepared in advance in accordance with the user status to be reported.
  • text messages that report “absent,” “working” and “responding” situations are prepared in advance.
  • icons that indicate “at desk,” “away from desk” and “working” are prepared.
  • FIG. 5( a ) is an example of a screen shot wherein the text message reported by the reporting module 9 is displayed.
  • the display module 12 may also display user status as an icon, as shown in FIG. 5( b ). Therein the display module 12 displays the status of user “tana” by an icon indicating a “not-at-desk” status.
  • FIG. 6 is another example of a screen shot wherein a text message is displayed.
  • FIG. 6( a ) is a display example of a text message indicating that user “tana” is operating another application or is inputting remarks on another channel.
  • FIG. 6( b ) shows a screen shot taken after the display module 12 has changed the icon display of user “tana” in accordance with notification given by user “katz”'s user terminal.
  • FIG. 7 is another example of a screen shot wherein a text message is displayed.
  • the screen of FIG. 7 is a display example of a text message indicating that user “tana” is inputting a reply to user “katz.”
  • FIG. 8 is another example of a screen shot wherein a text message is displayed.
  • the screen of FIG. 8 is a display example wherein-the reporting module 9 has determined a text message based on both the user status and the schedule list 11 .
  • FIG. 5 to FIG. 8 show examples of reporting user status by reporting a text message or by changing the display of an icon. Of course, it is also possible to do both, i.e., report a text message and change the icon display.
  • FIG. 9 is a flowchart illustrating the process flow of a main routing executed by the status notification device 1 .
  • step S 1 the keyword-detection module 2 stands by for a remark on the channel in which the chat client is participating; if a remark occurs, the process flow goes to step S 2 .
  • step S 2 the keyword-detection module 2 judges whether the acquired remark was inputted by the local terminal or was sent from another user terminal. If the remark is from another user terminal, the process flow goes to step S 3 . If the remark is from the local terminal, the process flow returns to step S 1 and the keyword-detection module 2 stands by for the next remark.
  • step S 3 the keyword-detection module 2 judges whether the remark from another user terminal includes any keyword in the keyword list 3 . If a keyword is included in the remark, the process flow goes to step S 4 . If a keyword is not included in the remark from another user terminal, the process flow returns to step S 1 and the keyword-detection module 2 stands by for the next remark.
  • step S 4 the keyword-detection module 2 acquires the name of the channel (hereinafter referred to as the call source channel) on which the keyword was uttered, and the nickname of the user (hereinafter referred to as the call source user) that uttered the keyword.
  • the keyword-detection module 2 reports the acquired channel name and nickname, and instructs the status-detection section 4 to judge the user status.
  • step S 5 a status-judging routine, discussed later, is executed.
  • step S 6 the reporting module 9 receives notification of the user status from the status-detection section 4 .
  • the reporting module 9 judges whether the reported user status is “absent.” If the user status is “absent,” the process flow goes to step S 7 . If not “absent,” the process flow goes to step S 8 , discussed later.
  • step S 7 the reporting module 9 reads the schedule list 11 .
  • step S 8 the text message to be reported is determined based on the user status and user schedule.
  • step S 9 the reporting module 9 searches report destination table 10 for the nickname of the call source user, and determines the user to be notified. Next, the reporting module 9 reports the text message and status information to the determined report destination user terminal. At the user terminal that received the text message and status information, the display module 12 displays the reported text message and changes the icon based on the status information.
  • Step S 10 judges whether the chat client program is finished. If the chat client program is finished, the routine ends. If the chat client program is not finished, the process flow returns to step S 1 and the above-described routine is repeated.
  • the present routine When called by another user by a keyword, the present routine detects user status in real time, which it reports. The present routine can thereby notify a user, when the user SO requests, of the status of another user, and can therefore support the smooth flow of conversations conducted in real time.
  • FIG. 10 is a flowchart illustrating the flow of the status-judging routine executed by the status-detection section 4 .
  • step S 11 the status-detection section 4 executes a judge absent subroutine, discussed later, and determines whether the user status is “absent.”
  • step S 12 the status-detection section 4 judges whether the user status determined by the aforementioned judge absent subroutine is “absent.” If the user status is “absent,” the process flow goes to step S 13 . If the user status is not “absent,” the process flow goes to step S 14 , discussed later.
  • step S 13 the status-detection section 4 reports the “absent” user status to the reporting module 9 . Moreover, together with the user status report, the status-detection section 4 reports the call source channel and the nickname of the call source user to the reporting module 9 .
  • step S 12 If the user status is judged not to be “absent” in step S 12 , the process flow goes to step S 14 .
  • step S 14 the status-detection section 4 executes a judge working subroutine, discussed later, and determines whether the user status is “working.”
  • step S 15 the status-detection section 4 judges whether the user status determined by the aforementioned judge working subroutine is “working.” If the user status is “working,” the process flow goes to step S 13 . Furthermore, together with the “working” user status, the status-detection section 4 reports the call source channel and the nickname of the call source user to the reporting module 9 . If the user status is not “working,” the process flow goes to step S 16 .
  • step S 16 the status-detection section 4 executes a judge responding subroutine, discussed later, and determines whether the user status is “responding.”
  • step S 17 the status-detection section 4 judges whether the user status determined by the judge responding subroutine is “responding.” If the status-detection section 4 judges that the user status is “responding,” the process flow goes to step S 13 . Furthermore, the status-detection section 4 reports the “responding” user status to the reporting module 9 . If the user status is not “responding,” then the process flow returns to step S 1 of the main routine, and the keyword-detection module 2 stands by for the next remark.
  • step S 18 the status-detection section 4 judges whether the user status is “responding.” If the user status is “responding,” the process flow goes to step S 19 . If the user status is otherwise, the process flow returns to the main routine, since user status notification has already been completed.
  • step S 19 the status-detection section 4 judges whether the user currently inputting a response to a remark has finished inputting. Specifically, the status-detection section 4 judges whether inputting has finished by judging whether the return key has been pressed at the end of the inputted response message. If the judgment is that inputting has finished, the process flow goes to step S 20 .
  • step S 20 the status-detection section 4 notifies the reporting module 9 that inputting has finished.
  • the reporting module 9 notifies the report destination user terminal that inputting has finished.
  • the user terminal that receives that notification executes such processes as changing icon displays. Then, the process flow returns to the main routine.
  • FIG. 11 is a flowchart illustrating the flow of the judge absent subroutine executed by the status-detection section 4 . If the process flow goes to step S 11 in the status decision routine, then the following processing is started.
  • step S 21 the status-detection section 4 judges, based on an event log, whether there was an event before the keyword utterance. Specifically, the status-detection section 4 judges whether there was an event, such as keyboard input or mouse operation, during a past fixed time prior to the keyword utterance. If the status-detection section 4 judges that there was an event in that past predetermined time, the process flow goes to step S 25 , discussed later. If it is judged that there was no event, the process flow goes to step S 22 .
  • an event such as keyboard input or mouse operation
  • step S 22 the status-detection section 4 judges whether an event is currently in progress. If a user event is not in progress, the process flow goes to step S 23 . If a user event is in progress, the process flow goes to step S 25 .
  • step S 23 the status-detection section 4 judges whether predetermined time T 1 has elapsed since the keyword was uttered. If predetermined time T 1 has not elapsed, the process flow returns to step S 22 , and the decision is re-executed. In other words, step S 22 and step S 23 judge whether an event occurs within predetermined time T 1 after the keyword was uttered. If it is judged in step S 23 that predetermined time T 1 has elapsed, the process flow goes to step S 24 .
  • step S 24 the status-detection section 4 determines whether the user status is “absent.” If an event does not occur in a predetermined elapsed time prior to the keyword utterance, nor occurs also in predetermined time T 1 after the keyword utterance, then the user status is determined to be “absent.”
  • step S 21 If it is judged in step S 21 that a user event occurred in the predetermined elapsed time prior to the keyword utterance, the process flow goes to step S 25 .
  • step S 25 the status-detection section 4 judges whether a screen saver is operating on the user terminal. If a screen saver is operating on the user terminal, the process flow goes to step S 26 . If a screen saver is not operating, the process flow goes to step S 24 . Then, since the screen saver is not operating and the user is performing some operation on the user terminal, it is determined that the user status is not “absent.”
  • step S 26 the status-detection section 4 judges whether predetermined time T 2 has elapsed since the keyword utterance. If predetermined time T 2 has not elapsed, the process flow returns to step S 25 , and the decision is re-executed. If predetermined time T 2 has elapsed, the process flow goes to step S 24 . In this case, since the screen saver was operating-from the time when the keyword was uttered until predetermined time T 2 elapsed, and since the user was not performing any operation on the user terminal during that interval, the user status is determined to be “absent.”
  • FIG. 12 is a flowchart illustrating the flow of a judge working subroutine executed by the status-detection section 4 . If the process flow goes to step S 14 in the judge status routine, the following subroutine is initiated.
  • step S 31 the status-detection section 4 judges whether the user is running an application other than the chat client. This decision is executed by judging whether, for example, there is mouse operation at the user terminal directed to another application. If it is Judged that the user is operating another application, the process flow goes to step S 32 . If the decision is that the user is not running another application, the process flow goes to step S 34 , discussed later.
  • step S 32 the status-detection section 4 judges whether predetermined time T 3 has elapsed since the keyword utterance. If predetermined time T 3 has not elapsed, the process flow returns to step S 31 , and the decision is re-executed. In other words, the decision is whether an operation directed to another application is being performed continuously during predetermined time T 3 after the keyword utterance. If it is judged that predetermined time T 3 has elapsed since the keyword utterance, the process flow goes to step S 33 .
  • step S 33 the status-detection section 4 determines whether the user status is “working.” If the user is running another application and predetermined time T 3 has elapsed since the keyword utterance, the user status is judged to be “working.”
  • step S 34 the status-detection section 4 judges whether the user is inputting a text message on another channel different from the call source channel. If the decision is that a remark is being input on another channel, the process flow goes to step S 35 . If the decision is that a remark is not being input on another channel, the process flow goes to step S 33 . In this case, the user is not running another application and nor inputting a remark on another channel. Accordingly, in step S 33 , the user status is determined not to be “working.”
  • step S 35 the status-detection section 4 acquires a text message input by the user on another channel, and counts the number of characters.
  • step S 36 the status-detection section 4 judges whether the input character count is greater than or equal to a predetermined standard character count.
  • the process flow goes to step S 33 , and the user status is determined. Namely, if the input character count is greater than or equal to the predetermined standard character count, the input message is long and, therefore, the user status is judged to be “working.” Conversely, if the input character count is less than the predetermined standard character count, and the input message is short, the user status is determined not to be “working.”
  • FIG. 13 is a flowchart illustrating the flow of a judge responding subroutine executed by the status-detection section 4 . If the process flow goes to step S 16 in the judge status routine, the following subroutine is executed.
  • step S 41 the status-detection section 4 judges whether a user on the call source channel is inputting a remark. If it is judged that the user is inputting on the call source channel, the process flow goes to step S 42 . If it is judged that the user is not inputting on the call source channel, the process flow goes to step S 43 , discussed later.
  • step S 42 the status-detection section 4 judges whether predetermined time T 4 has elapsed since the keyword utterance. If predetermined time T 4 has not elapsed, the process flow returns to step S 41 , and the subroutine is re-executed. If predetermined time T 4 has elapsed since the keyword utterance, the process flow goes to step S 43 . In other words, step S 41 and step S 42 judge whether the user is trying to respond to a keyword utterance and the response is taking time. Although the decision in this example is performed based on the inputting time, the decision may also be based on the input text message character count as discussed earlier—the standard for making the decision is not especially limited.
  • step S 43 the status-detection section 4 determines whether the user status is responding to a keyword utterance.
  • the user status is determined to be “responding” if a text message is being input on the call source channel from the time when the keyword was uttered until predetermined time T 4 elapses. Subsequently, the process flow returns to the judge status subroutine. If it is judged in step S 41 that a text message is being input on the call source channel, then the user status is judged to be “other,” and the process flow returns to step S 1 in the main routine.
  • FIG. 14 shows the overall configuration of the communication support system the present invention in the second embodiment.
  • Connecting a chat server, a plurality of user terminals and a proxy terminal via a computer network constitutes the communication support system in this embodiment.
  • FIG. 15 is a block diagram illustrating the configuration of the proxy terminal and user terminal of the present embodiment.
  • the proxy terminal and user terminal are both provided with a chat client.
  • the proxy terminal further has a proxy reporting device 21 .
  • the user terminal further has a status-detection section 24 and a display module 32 .
  • the proxy reporting device 21 has a keyword-detection module 22 , a keyword database (DB) 23 , a monitor module 33 , a reporting module 29 , a report destination DB 30 and a schedule DB 31 .
  • the keyword-detection module 22 detects keywords from remarks on a channel, in the same manner as in the keyword-detection module 22 on the user terminal in the first embodiment. However, in the proxy terminal, the keyword-detection module 22 judges whether there has been utterance with regard to keywords of all users participating on the call source channel. In addition, if the keyword-detection module 22 detects a keyword registered by any user, it judges whether the call source user is not the same as the user called by the keyword. If not the same, the keyword-detection module 22 reports predetermined information to the monitor module 33 , and requests the detection of the status of the called user. In addition to the call source channel name and the nickname of the call source user, the predetermined information also includes the nickname of the called user.
  • FIG. 16 shows an example of a keyword DB 23 used by the keyword-detection module 22 for detecting keywords.
  • the nickname of the user connected to the proxy terminal via the network and the word registered as a keyword by that user are correlated and stored in keyword DB 23 shown in FIG. 16.
  • the user whose nickname is “tana” registers her real name “Tanaka” and “Tamie,” her nickname “tana” and “all” in keyword DB 23 .
  • the keyword-detection module 22 consults keyword DB 23 and acquires the nickname “tana” of the user who registered “Tanaka” as a keyword.
  • the keyword-detection module 22 compares the nickname “katz” of the call source user with the nickname “tana” of the called user. Since the two do not match, the keyword-detection module 22 notifies the monitor module 33 of both nicknames and the channel name.
  • the monitor module 33 first judges whether the called user terminal is booted up. If the called user terminal is not running, the monitor module 33 notifies the reporting module 29 to that effect. If the called user terminal is running, the monitor module 33 requests the called user terminal to detect the user status. In addition, the monitor module 33 , in accordance with the request, stands by for user status notification from the called user terminal. If the monitor module 33 is notified of the user status by the user terminal, it sends the reported user status to the reporting module 29 .
  • the reporting module. 29 consults the report destination DB 30 and specifies the report destination for the determined user status, likewise as with the reporting module 9 in the first embodiment.
  • the report destination DB 30 differs from the first embodiment in that it is configured to store a report destination table 10 of the first embodiment each user connected to the proxy terminal via the network.
  • FIG. 17 shows an example of the report destination DB 30 .
  • the nicknames of users connected to the proxy terminal, the nicknames of call source users and the nicknames of report destination users are correlated and stored in the report destination DB 30 .
  • the reporting module 29 searches the report destination DB using the nickname “tana” as a key, and acquires the report destination table of the called user “tana.”
  • the reporting module 29 reads the report destination set for the call source user “katz.”
  • the nicknames “katz” and “suzu” are set as the report destinations.
  • the reporting module 29 determines the text message to be reported based on the reported user status and the content of the schedule DB 31 , likewise as with the reporting module 9 in the first embodiment.
  • the present embodiment differs from the first embodiment in that the schedules of all users connected to the proxy terminal are stored in the schedule DB 31 .
  • the status-detection section 24 is provided with an event-detection module 25 , a screen saver detection module 26 and a recording module 27 .
  • the status-detection module 24 detects through the event-detection module 25 and the screen saver detection module 26 whether keyboard or mouse user input is directed to the chat client, and whether the screen saver is operating, likewise as with the status-detection section 4 in the first embodiment.
  • the results of the detection are recorded in an event table.
  • the present embodiment differs from the first embodiment in that the status-detection section 24 detects the user status in accordance with a request from the monitor module 33 of the proxy terminal, and notifies the proxy terminal of the detected user status.
  • the display module 32 displays on the screen an icon that indicates the reported user status, likewise as with the first embodiment.
  • FIG. 18 is a flowchart illustrating the main routine executed by the proxy terminal in the present embodiment. The following routine is initiated by loading the chat client in the proxy terminal or by connecting the chat client to the chat server.
  • step S 51 the event-detection module 25 judges whether there has been a remark in any channel. If there has been a remark, the process flow goes to step S 52 . If there has not been a remark, the decision is re-executed. In other words, in step S 51 , the keyword-detection module 22 stands by for a remark on any channel.
  • step S 52 the keyword-detection module 22 judges whether the keyword of any user is included in a remark. Consulting keyword DB 23 carries out this decision. If it is judged that the keyword of any user is included in a remark, the process flow goes to step S 53 . If it judged that no keyword of any user is included in a remark, the process flow returns to step S 51 , and the keyword-detection module 22 stands by for the next remark.
  • step S 53 the keyword-detection module 22 acquires from the chat client the nickname of the call source user that uttered the keyword, the nickname of the user called by the keyword utterance and the call source channel on which the remark occurred.
  • step S 54 the keyword-detection module 22 judges whether the call source user and the called user are the same user. If the two users are different users, the call source user, the called user and the call source channel name are reported to the monitor module 33 , and the process flow goes to step S 55 . If the call source user and the called user are the same user, the process flow returns to step S 51 , and the keyword-detection module 22 stands by for the next remark.
  • step S 55 the monitor module 33 judges whether the called user's user terminal is running. If the called user's user terminal is not running, the process flow goes to step S 58 , discussed later. If the called user's user terminal is running, the process flow goes to step S 56 for detecting the status of the called user.
  • step S 56 the monitor module 33 requests the called user terminal to detect the user status.
  • step S 57 the monitor module 33 stands by for a response to the request, and the process flow goes to step S 58 when the user status is acquired.
  • step S 58 the monitor module 33 sends to the reporting module 29 the user status of the called user acquired from the user terminal. In addition to the user status, the call source user and the call source channel are also sent.
  • the reporting module 29 that receives the user status judges whether the user status is “absent.” If the user status is “absent,” the process flow goes to step S 59 . If not “absent,” the process flow goes to step S 60 , discussed later.
  • step S 59 the reporting module 29 reads the schedule of the called user from the schedule DB 31 .
  • step S 60 the reporting module 29 determines the text message to be reported to the call source user based on the user status and the user schedule.
  • step S 61 the reporting module 29 reads the report destination DB 30 based on the nickname of the called user, and specifies the text message report destination. Next, the reporting module 29 reports the text message and status information to the determined report destination. At the user terminal that receives the text message and status information, the display module displays the reported text message and changes the icon.
  • Step S 62 judges whether the chat client program is finished; if finished, the present routine ends. If the chat client program is not finished, the process flow returns again to step S 51 and the routine is repeated.
  • the process flow at the user terminal is to detect the real-time status of the user called by another user, and to give notification, likewise as with the judge status routine in the first embodiment.
  • the present embodiment differs from the first embodiment in that user terminals perform the judge status routine in accordance with requests from the proxy terminal, and in that the proxy terminal notifies the user terminals of the user situations/status.
  • a proxy terminal is provided in the second embodiment, and that proxy terminal is provided with a chat client and a proxy reporting device.
  • a form is also possible that provides the proxy reporting device in an information terminal operated by the chat server.
  • the keyword-detection module 22 acquires remarks on the channel from the chat server.
  • the reporting module 29 issues text messages via the chat server.

Abstract

A method and associated system for promoting smooth communications in a chat system. A keyword list 3 stores keywords. A keyword-detection module 2 detects the sending of any keyword from another user terminal on any channel. A status-detection system 4, in response to the detection of a keyword, judges user status based on the status of the user terminal. A reporting module 9 sends the user status to the channel on which the keyword was sent. A report destination table 10 correlates the user status report destination with the keyword remark source and stores this information, and the reporting module 9 may report the user status to a report destination determined based on the report destination table. The real-time status of a user called by a keyword is reported, so as to support smoothly conducting conversations held in real time.

Description

    BACKGROUND OF THE INVENTION
  • 1. Technical Field [0001]
  • The present invention relates to technology for promoting user conversation and smoothing the flow of communications in a system wherein a plurality of computer users mutually share the same network, enabling simultaneous conversation. [0002]
  • In the present invention, “chat system” refers to a system comprising a chat server and a plurality of chat clients, wherein chat clients share the same space and can conduct conversations. A “channel” refers to a virtual space shared by the chat clients. A “nickname” refers to identification information used to specify uniquely a user in the chat system. [0003]
  • 2. Description of Related Art [0004]
  • In conventional chat systems, the conversations of channel participants are displayed lined in time series or within a described balloon. In addition to the conversations of channel participants, information is also displayed that indicates the fact that a user has joined or parted from a channel. [0005]
  • In addition to the aforementioned information, a chat system that can register users' self-status and user-specified keywords has been offered lately. In this chat system, the chat client detects whether a user-registered keyword is included in the remarks from another chat client. If a keyword is detected, the chat client consults the self-status previously set by the user, and notifies the other chat client that uttered the keyword of the user's self-status. Examples of user self-status designations that are registered include “away from desk” and “absent.” In addition, a chat system is also provided that gives notification not only of the self-status, but also of a predetermined message in accordance with the self-status. [0006]
  • The aforementioned chat system, wherein the self-status can be reported, has the following problems. [0007]
  • Since the user must set the self-status beforehand, the chat client cannot respond to the utterance of a keyword from another client if the user forgets to set his or her self-status. Moreover, unless a user sets self-status by him or herself, user status, such as the user's location and actions, will be completely unknown to other users. For example, even if a user sets the self-status to “absent” when leaving his or her desk, there is a tendency for the user to forget to reset the self-status to “present” upon returning. If a keyword is uttered by another chat client in this situation, even though the user himself or herself tries to respond, the chat client ends up sending a message to the effect that the user is absent. [0008]
  • Further, when someone is composing a long-text answer to remarks from other user(s), the other users will not realize that person's status—whether a response is being composed to their messages, whether the person is not at his or her desk, or whether he or she is busy running another application for example. These are aspects which therefore make it difficult to take full advantage of chat systems wherein conversations can be conducted in real time. [0009]
  • SUMMARY OF THE INVENTION
  • The object of the present invention is to smooth the flow of communications among network computer users conducting conversations in real time. [0010]
  • Toward solving the aforementioned problems, a first aspect of the invention in the present application presents a communication support method wherein a plurality of users mutually share the same network, used in a communication device that is simultaneous, bi-directional communication-enabled. The method provides [0011]
  • (A) preparing a correlation between predetermined text information and the users; [0012]
  • (B) detecting the utterance of any of the text information by a first user on a network; [0013]
  • (C) in response to the text information detection, finding the status of a second user correlated with the detected text information; and [0014]
  • (D) sending the detected second user status to the network on which the text information was uttered. [0015]
  • Taking a chat system comprising a chat server and a chat client as an example will illustrate: User A stores a keyword on the terminal of user A. If a keyword registered by user terminal A is uttered by another user terminal B on a channel #CH1 in which user terminal A is participating, the utterance of that keyword is detected by user terminal A. Next, user terminal A detects the status of user A. For example, the fact that a screen saver is operating or that a text message is being composed on another channel is detected. Subsequently, notification is given of the detected status to user terminal B on the channel on which the keyword was uttered. [0016]
  • A second aspect of the invention in the present application presents a communication support system wherein identical networks are mutually shared, used in a communication device that is simultaneous bi-directional communication-enabled. The communication support system is provided with a first storage means, a detection means, a decision means and a reporting means. [0017]
  • The first storage means stores predetermined text information correlated with communication devices on a network. The detection means detects the sending of any text information from a first communication device on a network. The decision means, in accordance with the detection of the text information, based on the status of a second communication device correlated with the detected text information judges the user status of the second communication device. The reporting means sends the user status to the network to which the text information was sent. [0018]
  • Taking a chat system comprising a chat server and a chat client as an example will illustrate: In any terminal, the first storage means correlates user keywords with users. If a keyword registered by user terminal A is uttered by another user terminal B on a channel #CH1 in which user terminal A is participating, that keyword is detected by the detection means in user terminal A. [0019]
  • Next, the decision means in user terminal A judges the status of user A based on the status of user terminal A. For example, the fact that a screen saver is operating or that a text message is being composed on another channel is detected, and the status of user A is thereby judged. Examples of user situations include “absent,” “working,” and “responding.” Next, the decision means sends the judged user status to the reporting means. The reporting means uses a chat client and notifies the other user terminal of the status of user A on channel #CH1. [0020]
  • A decision means is provided in each user terminal. The first storage means, detection means and reporting means may be provided in each user terminal and, moreover, may be provided in any information terminal that can run the chat client. [0021]
  • A third aspect of the invention in the present application is the communication support system according to the second aspect of the invention, but further presents a second storage means that stores communication devices that report user status and text-information sending-source communication devices, correlated with the communication devices on the network. The communication support system reporting means determines user status report destinations in accordance with the second storage means, and reports the user status to the report destination via the network. [0022]
  • For example, the second storage means stores a report destination table, wherein are recorded, for instance, content such as the following. For user terminal A, the report destination is set to user terminal B if the keyword was sent from user terminal B, and the report destination is set to user terminals B, C if the keyword was sent from user terminal C. Likewise, the remark source of the keyword and the report destination of the user status are also set for other user terminals. If the user wants to give notification of the status of another communication device other than the communication device that sent the keyword, the user can specify the report destination using the report destination table. [0023]
  • A fourth aspect of the invention in the present application is the communication support system according to the second aspect of the invention, but further presents a third storage means that stores user schedules correlated with communication devices. The reporting means in this communication support system determines the user status to be sent to the network based on the judged user status of the second communication device and based on the schedule corresponding to the second communication device. [0024]
  • For example, the third storage means stores the previously described schedule list wherein user schedules are correlated with the users. If the status of user A is judged to be “absent,” then the reporting means consults user A's schedule. If the user A's schedule is “Afternoon business trip to Tokyo,” then the reporting means sets “Afternoon business trip to Tokyo” as the report content. By providing the schedule list beforehand and combining it with the detected user status, a much more detailed user-status notification can be given. [0025]
  • A fifth aspect of the invention in the present application is the communication support system according to the second aspect of the invention, but further presents an acquisition means that detects whether the second communication device is operating, and acquires the user status from the decision means in accordance with the detection results. [0026]
  • Consider a system configuration comprising a plurality of user terminals and at least one proxy terminal. Each user terminal is provided with a status reporting means. The proxy terminal is provided with a first storage means, a detection means, an acquisition means and a reporting means. If the detection means detects a user A keyword, the acquisition means judges whether user terminal A is running. If it is running, the acquisition means makes a request to user terminal A to determine the user status, and then receives notification of the user status from user terminal A. The received user status is sent to the reporting means. Conversely, if user terminal A is not running, the acquisition means notifies the reporting means to that effect. By providing the acquisition means, the user status can be reported even if the user terminal is not running. [0027]
  • A sixth aspect of the invention in the present application is the communication support system according to the second invention, but further presents a display means that visually displays the status of each user sharing the network, and that can change the display in accordance with the user status sent from the network. [0028]
  • For example, icons are prepared beforehand that indicate each of the following situations “absent,” “busy,” and “responding.” Then, if notification of a user status is given by another communication device, the display means changes the icon of that user to an icon that indicates the reported status. [0029]
  • A seventh aspect of the invention in the present application presents a status notification device used together with a communication device that is simultaneous, bi-directional communication-enabled wherein a plurality of users mutually share the same network. The status notification device is provided with a first storage means, a detection means, a decision means and a reporting means. [0030]
  • The first storage means stores predetermined text information. The detection means detects the sending of the text information from another communication device on a network. The decision means, in accordance with the detection of the text information, judges user status based on the status of the communication device. The reporting means sends the user status to the network to which the text information was sent. [0031]
  • Actions/effects here are likewise as with the communication device in the second aspect of the invention wherein constituted without using a proxy terminal. [0032]
  • An eighth aspect of the invention in the present application presents a proxy device used in communication device that is simultaneous, bi-directional communication-enabled wherein a plurality of users mutually share the same network. The proxy device is provided with a first storage means, a detection means, an acquisition means and a reporting means. [0033]
  • The first storage means stores predetermined text information correlated with users. The detection means detects the sending of any text information from a first communication device on a network. The acquisition means, in accordance with the detection of the text information, detects whether a second communication device correlated with the detected text information is operating, and acquires from the second communication device the user status of the second communication device in accordance with the detection results. The reporting means sends, to the network to which the text information was sent, the user status based on the detection results, or the acquired user status. [0034]
  • Actions/effects here are likewise as with a proxy terminal in the second aspect of the invention, wherein each user terminal is provided with a judgement means and the proxy terminal bears other functions. [0035]
  • A ninth aspect of the invention in the present application presents a computer readable recording medium on which is recorded a status notification program used together with a communication device that is simultaneous, bi-directional communication-enabled wherein a plurality of users mutually share the same network. The status notification program is recorded for executing steps A to D below. [0036]
  • (A) a step of storing predetermined text information; [0037]
  • (B) a step of detecting the sending of the text information from another communication device on a network; [0038]
  • (C) a step of judging, in accordance with the detection of the text information, user status based on the status of the communication device; and [0039]
  • (D) a step of sending the user status to the network to which the text information was sent. [0040]
  • Actions/effects here are likewise as with the seventh aspect of the invention. [0041]
  • A tenth aspect of the invention in the present application provides a computer readable recording medium on which is recorded a proxy notification program wherein a plurality of users mutually share the same network, used in a communication device that is simultaneous, bi-directional communication-enabled. The proxy notification program is recorded for executing steps A to D below. [0042]
  • (A) a step of storing predetermined text information correlated with users; [0043]
  • (B) a step of detecting the sending of any text information from a first communication device on a network; [0044]
  • (C) a step of finding, in response to the text information detection, whether the second communication device correlated with the detected text information is operating, and acquiring the second communication device user status from the second communication device in accordance with the detection results, and [0045]
  • (D) a step of sending the user status based on the detection results, or the acquired user status, to the network to which the text information was sent. [0046]
  • Actions/effects here are likewise as with the eighth aspect of the invention. [0047]
  • Utilizing the present invention enables communications to flow smoothly since users engaged in real-time conversation using text messages can determine each other's situations in real time as needed. [0048]
  • The foregoing and other objects, features, aspects and advantages of the present invention will become more apparent from the following detailed description in conjunction with the accompanying drawings. [0049]
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • FIG. 1 is a diagram of the overall configuration of a communication support system according to the first embodiment; [0050]
  • FIG. 2 is a block diagram illustrating the configuration of a user terminal in the first embodiment; [0051]
  • FIG. 3 is an explanatory diagram illustrating a keyword list example; [0052]
  • FIG. 4 is an explanatory diagram illustrating a report destination table example; [0053]
  • FIG. 5([0054] a) is an explanatory diagram illustrating an example of displaying “away from desk” status by a text message;
  • FIG. 5([0055] b) is an explanatory diagram illustrating an example of displaying “away from desk” status by an icon;
  • FIG. 6([0056] a) is an explanatory diagram illustrating an example of displaying “busy” status by a text message;
  • FIG. 6([0057] b) is an explanatory diagram illustrating an example of displaying “busy” status by an icon;
  • FIG. 7 is an explanatory diagram illustrating an example of displaying “responding” status by a text message; [0058]
  • FIG. 8 is an explanatory diagram illustrating an example of displaying a text message combined with a schedule; [0059]
  • FIG. 9 is a flowchart illustrating process flow of a main routine executed by the status notification device in the first embodiment; [0060]
  • FIG. 10 is a flowchart illustrating process flow in a status-judging routine; [0061]
  • FIG. 11 is a flowchart illustrating process flow in a judge absent subroutine; [0062]
  • FIG. 12 is a flowchart illustrating process flow in a judge working subroutine; [0063]
  • FIG. 13 is a flowchart illustrating process flow in a judge responding subroutine; [0064]
  • FIG. 14 is a diagram of the overall configuration of a communication support system according to the second embodiment; [0065]
  • FIG. 15 is a block diagram illustrating the configuration of a proxy terminal and user terminal in the second embodiment; [0066]
  • FIG. 16 is an explanatory diagram illustrating one example of information in a keyword DB; [0067]
  • FIG. 17 is an explanatory diagram illustrating one example of information in a report destination DB; and [0068]
  • FIG. 18 is a flowchart illustrating flow of a routine that the proxy notification device in the second embodiment executes. [0069]
  • DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
  • The following sets forth embodiments to explain the communication support system of the present invention specifically. [0070]
  • First Embodiment [0071]
  • (Configuration) [0072]
  • FIG. 1 is a diagram illustrating the entire configuration of the communication support system according to the first embodiment. In the communication support system of the present embodiment, a chat server and a plurality of user terminals are connected via a computer network. [0073]
  • FIG. 2 is a block diagram illustrating the configuration of the user terminal of the present embodiment. The user terminal shown in FIG. 2 is provided with a chat client and [0074] status notification device 1. Status notification device 1 is provided with a keyword-detection module 2, a keyword list 3, a status-detection section 4, a reporting module 9, a report destination table 10, a schedule list 11 and a display module 12.
  • The keyword-[0075] detection module 2 acquires from the chat client the remarks in the channel in which the chat client is participating. The keyword-detection module 2 judges whether the acquired remark is sent from another user terminal or inputted by the local terminal. If it is a remark from another user terminal, the keyword-detection module 2 judges whether a keyword registered by the user is included in the acquired remark. This decision is made based on the keyword list 3, which is discussed later. If a keyword is included in the remark, the keyword-detection module 2 instructs the status-detection section 4 to detect the user status. This instruction is executed by the keyword-detection module 2 notifying the status-detection section 4 of the name of the channel on which the keyword was uttered, and the nickname of the user that uttered the keyword.
  • FIG. 3 is a diagram illustrating an example of a keyword list [0076] 3 registered by a user. Presumably, users normally register their real names and nicknames. In addition, it is also assumed that a user will register an “all,” which is a keyword common to all users on the channel. In FIG. 3, user “Tamie Tanaka” has registered her real names “Tanaka” and “Tamie” as well as her nickname “tana” and “all” as keywords. The keyword list 3 can be registered by the user or may be automatically created. For example, it is possible to register automatically the user's real name, nickname and “all” as keywords, and for other keywords to be additionally registered by the user.
  • The status-[0077] detection section 4 judges user status in accordance with an instruction from the keyword-detection module 2. This is in order that the real-time status of user terminal B is reported when user terminal A calls user terminal B. In the present embodiment, the status-detection section 4 judges whether the user status is either “absent,” “working” or “responding.” When the status-detection section 4 has judged the user status, it notifies the reporting module 9 of the user status. In addition, along with the user status, the status-detection section 4 notifies the reporting module 9 of the name of the channel on which the keyword was uttered and the nickname of the user that uttered the keyword.
  • The status-[0078] detection section 4 has an event-detection module 5, a screen saver detection module 6 and a recording module 7 for judging user status. The event-detection module 5 detects the presence of user input (hereinafter referred to as an event), such as whether there is any keyboard input or whether the mouse is moving. In addition, the event-detection module 5 detects whether the user input is directed to a channel on chat or whether it is input in an application other than chat. The screen saver detection module 6 detects whether the user terminal screen saver is operating. The recording module 7 creates an event table 8 and records in the event table 8 events that occur within a predetermined time, along with the time of the events.
  • The [0079] reporting module 9 notifies the other user terminals, via the chat client, of the user status reported by the status-detection section 4. The report destination user terminals are determined based on the report destination table 10. FIG. 4 shows an example of a report destination table 10. The nickname of the user that uttered the keyword is registered in the report destination table 10 as the call source user. The report destination user(s) who are notified of self-status for keyword utterances from a call source user are correlated with each call source and registered. It is possible to specify that notification be given of the self-status only to the call source, or that notification be given to all users on the channel. In addition, a plurality of users can also be specified as the report destination. In FIG. 4, for example, user A specifies “oku” as the report destination if the call source user is “oku.” If the call source user is “sasa,” then “sasa” and “tana” are specified as report destinations. If the call source user is “yama,” then all users (“all”) are specified as report destinations. The report destination table 10 is prepared in advance by any means, such as registering by a user.
  • In addition, based on the user status reported by the status-[0080] detection section 4, the reporting module 9 determines which text message among text messages prepared in advance is to be reported. Next, the reporting module 9 issues the text message on the call source channel. The status of the called user is thereby reported to the report destination user. The reporting module 9 may also give notification to the report destination of a text message or, in place of a text message, information indicating the user status (hereinafter referred to as the status information). Notification of the status information is given via the chat client. The report destination user terminal that receives this status information displays an icon indicating the user status, for example. The status information may be a text message or may be other information such as a control command.
  • If the [0081] schedule list 11 is prepared in advance, the reporting module 9 determines the text message based on the user status reported by the status-detection section 4 and based on a pre-registered schedule list 11 (not shown). The user registers the user's schedule status in the schedule list 11. The user registers plans, such as “at work,” “business trip,” “meeting” and “yearly vacation,” correlated with date, time and destination.
  • For example, when the [0082] reporting module 9 receives notification of an “absent” user status from the status-detection section 4, it consults the schedule list 11. In the schedule list 11, “business trip” is registered as the schedule for that time and “Tokyo” is registered as the destination. Thereupon, the reporting module 9 sets “Business trip Tokyo” as the text message to be reported. Conversely, if the schedule in schedule list 11 is “at work,” the reporting module 9 sets “Presently away from desk” as the text message to be reported. However, if the user status is “responding” or “working,” the reporting module 9 does not consult the schedule list 11. Instead, it creates a text message that indicates the user status, such as “Responding” or “Presently busy,” which it reports to the report destination. If the schedule list 11 is provided in advance, detailed user status can be reported; however, even if the schedule list 11 is not provided or even if the schedule is not registered in the schedule list 11, user status can still be reported.
  • The [0083] display module 12 displays a window on the screen for each channel in which the chat client is participating. Furthermore, the display module 12 displays, in these windows, icons that indicate the status of each user participating in the channel. FIG. 5 to FIG. 8 are examples of screen shots wherein icons indicating user situations are displayed by the display module 12. The display module 12 displays an icon for each user on the channel, and the status of each user participating on the channel is visually indicated. Icons are prepared in advance in accordance with predetermined status information. The display module 12 changes the icon to be displayed based on the status information for other user terminals, sent from the reporting module 9. For example, if a text message corresponding to “away from desk” is sent from another user terminal as the status information, the display module 12 changes the icon that indicates the status of that user to an “away-from-desk” icon.
  • FIG. 5 to FIG. 8 are examples of screen shots wherein the [0084] display module 12 of the report destination displays text messages and icons reported by the reporting module 9 at the call source. Text messages and icons are prepared in advance in accordance with the user status to be reported. In the present embodiment, text messages that report “absent,” “working” and “responding” situations are prepared in advance. In addition, icons that indicate “at desk,” “away from desk” and “working” are prepared.
  • FIG. 5([0085] a) is an example of a screen shot wherein the text message reported by the reporting module 9 is displayed. On channel “#suzume,” user “katz” has uttered the real name of user “tana,” and a text message to the effect that user “tana” is not at her desk is displayed. In addition, the display module 12 may also display user status as an icon, as shown in FIG. 5(b). Therein the display module 12 displays the status of user “tana” by an icon indicating a “not-at-desk” status.
  • FIG. 6 is another example of a screen shot wherein a text message is displayed. FIG. 6([0086] a) is a display example of a text message indicating that user “tana” is operating another application or is inputting remarks on another channel. In addition, FIG. 6(b) shows a screen shot taken after the display module 12 has changed the icon display of user “tana” in accordance with notification given by user “katz”'s user terminal.
  • FIG. 7 is another example of a screen shot wherein a text message is displayed. The screen of FIG. 7 is a display example of a text message indicating that user “tana” is inputting a reply to user “katz.”[0087]
  • FIG. 8 is another example of a screen shot wherein a text message is displayed. The screen of FIG. 8 is a display example wherein-the [0088] reporting module 9 has determined a text message based on both the user status and the schedule list 11.
  • FIG. 5 to FIG. 8 show examples of reporting user status by reporting a text message or by changing the display of an icon. Of course, it is also possible to do both, i.e., report a text message and change the icon display. [0089]
  • (Process Flow) [0090]
  • The following explains the process flow executed by the [0091] status notification device 1 according to the present embodiment.
  • (1) Main Routine [0092]
  • FIG. 9 is a flowchart illustrating the process flow of a main routing executed by the [0093] status notification device 1. Loading a chat client on a user terminal, or running a chat client to connect a user terminal and a chat server, starts the following routine.
  • First, in step S[0094] 1, the keyword-detection module 2 stands by for a remark on the channel in which the chat client is participating; if a remark occurs, the process flow goes to step S2.
  • In step S[0095] 2, the keyword-detection module 2 judges whether the acquired remark was inputted by the local terminal or was sent from another user terminal. If the remark is from another user terminal, the process flow goes to step S3. If the remark is from the local terminal, the process flow returns to step S1 and the keyword-detection module 2 stands by for the next remark.
  • In step S[0096] 3, the keyword-detection module 2 judges whether the remark from another user terminal includes any keyword in the keyword list 3. If a keyword is included in the remark, the process flow goes to step S4. If a keyword is not included in the remark from another user terminal, the process flow returns to step S1 and the keyword-detection module 2 stands by for the next remark.
  • In step S[0097] 4, the keyword-detection module 2 acquires the name of the channel (hereinafter referred to as the call source channel) on which the keyword was uttered, and the nickname of the user (hereinafter referred to as the call source user) that uttered the keyword. Next, the keyword-detection module 2 reports the acquired channel name and nickname, and instructs the status-detection section 4 to judge the user status.
  • In step S[0098] 5, a status-judging routine, discussed later, is executed.
  • In step S[0099] 6, the reporting module 9 receives notification of the user status from the status-detection section 4. The reporting module 9 judges whether the reported user status is “absent.” If the user status is “absent,” the process flow goes to step S7. If not “absent,” the process flow goes to step S8, discussed later.
  • In step S[0100] 7, the reporting module 9 reads the schedule list 11.
  • In step S[0101] 8, the text message to be reported is determined based on the user status and user schedule.
  • In step S[0102] 9, the reporting module 9 searches report destination table 10 for the nickname of the call source user, and determines the user to be notified. Next, the reporting module 9 reports the text message and status information to the determined report destination user terminal. At the user terminal that received the text message and status information, the display module 12 displays the reported text message and changes the icon based on the status information.
  • Step S[0103] 10 judges whether the chat client program is finished. If the chat client program is finished, the routine ends. If the chat client program is not finished, the process flow returns to step S1 and the above-described routine is repeated.
  • When called by another user by a keyword, the present routine detects user status in real time, which it reports. The present routine can thereby notify a user, when the user SO requests, of the status of another user, and can therefore support the smooth flow of conversations conducted in real time. [0104]
  • (2) Judge Status Subroutine [0105]
  • When the main the process flow goes to step S[0106] 5, the following judge status routine is executed. FIG. 10 is a flowchart illustrating the flow of the status-judging routine executed by the status-detection section 4.
  • In step S[0107] 11, the status-detection section 4 executes a judge absent subroutine, discussed later, and determines whether the user status is “absent.”
  • In step S[0108] 12, the status-detection section 4 judges whether the user status determined by the aforementioned judge absent subroutine is “absent.” If the user status is “absent,” the process flow goes to step S13. If the user status is not “absent,” the process flow goes to step S14, discussed later.
  • In step S[0109] 13, the status-detection section 4 reports the “absent” user status to the reporting module 9. Moreover, together with the user status report, the status-detection section 4 reports the call source channel and the nickname of the call source user to the reporting module 9.
  • If the user status is judged not to be “absent” in step S[0110] 12, the process flow goes to step S14. In step S14, the status-detection section 4 executes a judge working subroutine, discussed later, and determines whether the user status is “working.”
  • In step S[0111] 15, the status-detection section 4 judges whether the user status determined by the aforementioned judge working subroutine is “working.” If the user status is “working,” the process flow goes to step S13. Furthermore, together with the “working” user status, the status-detection section 4 reports the call source channel and the nickname of the call source user to the reporting module 9. If the user status is not “working,” the process flow goes to step S16.
  • In step S[0112] 16, the status-detection section 4 executes a judge responding subroutine, discussed later, and determines whether the user status is “responding.”
  • In step S[0113] 17, the status-detection section 4 judges whether the user status determined by the judge responding subroutine is “responding.” If the status-detection section 4 judges that the user status is “responding,” the process flow goes to step S13. Furthermore, the status-detection section 4 reports the “responding” user status to the reporting module 9. If the user status is not “responding,” then the process flow returns to step S1 of the main routine, and the keyword-detection module 2 stands by for the next remark.
  • If any of the user situations “absent,” “working” or “responding” is reported to the [0114] reporting module 9 in step S13, the process flow goes to step S18. In step S18, the status-detection section 4 judges whether the user status is “responding.” If the user status is “responding,” the process flow goes to step S19. If the user status is otherwise, the process flow returns to the main routine, since user status notification has already been completed.
  • In step S[0115] 19, the status-detection section 4 judges whether the user currently inputting a response to a remark has finished inputting. Specifically, the status-detection section 4 judges whether inputting has finished by judging whether the return key has been pressed at the end of the inputted response message. If the judgment is that inputting has finished, the process flow goes to step S20.
  • In step S[0116] 20, the status-detection section 4 notifies the reporting module 9 that inputting has finished. The reporting module 9 notifies the report destination user terminal that inputting has finished. The user terminal that receives that notification executes such processes as changing icon displays. Then, the process flow returns to the main routine.
  • (3) Judge Absent Subroutine [0117]
  • FIG. 11 is a flowchart illustrating the flow of the judge absent subroutine executed by the status-[0118] detection section 4. If the process flow goes to step S11 in the status decision routine, then the following processing is started.
  • In step S[0119] 21, the status-detection section 4 judges, based on an event log, whether there was an event before the keyword utterance. Specifically, the status-detection section 4 judges whether there was an event, such as keyboard input or mouse operation, during a past fixed time prior to the keyword utterance. If the status-detection section 4 judges that there was an event in that past predetermined time, the process flow goes to step S25, discussed later. If it is judged that there was no event, the process flow goes to step S22.
  • In step S[0120] 22, the status-detection section 4 judges whether an event is currently in progress. If a user event is not in progress, the process flow goes to step S23. If a user event is in progress, the process flow goes to step S25.
  • In step S[0121] 23, the status-detection section 4 judges whether predetermined time T1 has elapsed since the keyword was uttered. If predetermined time T1 has not elapsed, the process flow returns to step S22, and the decision is re-executed. In other words, step S22 and step S23 judge whether an event occurs within predetermined time T1 after the keyword was uttered. If it is judged in step S23 that predetermined time T1 has elapsed, the process flow goes to step S24.
  • In step S[0122] 24, the status-detection section 4 determines whether the user status is “absent.” If an event does not occur in a predetermined elapsed time prior to the keyword utterance, nor occurs also in predetermined time T1 after the keyword utterance, then the user status is determined to be “absent.”
  • If it is judged in step S[0123] 21 that a user event occurred in the predetermined elapsed time prior to the keyword utterance, the process flow goes to step S25. In step S25, the status-detection section 4 judges whether a screen saver is operating on the user terminal. If a screen saver is operating on the user terminal, the process flow goes to step S26. If a screen saver is not operating, the process flow goes to step S24. Then, since the screen saver is not operating and the user is performing some operation on the user terminal, it is determined that the user status is not “absent.”
  • In step S[0124] 26, the status-detection section 4 judges whether predetermined time T2 has elapsed since the keyword utterance. If predetermined time T2 has not elapsed, the process flow returns to step S25, and the decision is re-executed. If predetermined time T2 has elapsed, the process flow goes to step S24. In this case, since the screen saver was operating-from the time when the keyword was uttered until predetermined time T2 elapsed, and since the user was not performing any operation on the user terminal during that interval, the user status is determined to be “absent.”
  • (4) Judge Working Subroutine [0125]
  • FIG. 12 is a flowchart illustrating the flow of a judge working subroutine executed by the status-[0126] detection section 4. If the process flow goes to step S14 in the judge status routine, the following subroutine is initiated.
  • In step S[0127] 31, the status-detection section 4 judges whether the user is running an application other than the chat client. This decision is executed by judging whether, for example, there is mouse operation at the user terminal directed to another application. If it is Judged that the user is operating another application, the process flow goes to step S32. If the decision is that the user is not running another application, the process flow goes to step S34, discussed later.
  • In step S[0128] 32, the status-detection section 4 judges whether predetermined time T3 has elapsed since the keyword utterance. If predetermined time T3 has not elapsed, the process flow returns to step S31, and the decision is re-executed. In other words, the decision is whether an operation directed to another application is being performed continuously during predetermined time T3 after the keyword utterance. If it is judged that predetermined time T3 has elapsed since the keyword utterance, the process flow goes to step S33.
  • In step S[0129] 33, the status-detection section 4 determines whether the user status is “working.” If the user is running another application and predetermined time T3 has elapsed since the keyword utterance, the user status is judged to be “working.”
  • If it is judged in step S[0130] 31 that the user is not running another application, the process flow goes to step S34. In step S34, the status-detection section 4 judges whether the user is inputting a text message on another channel different from the call source channel. If the decision is that a remark is being input on another channel, the process flow goes to step S35. If the decision is that a remark is not being input on another channel, the process flow goes to step S33. In this case, the user is not running another application and nor inputting a remark on another channel. Accordingly, in step S33, the user status is determined not to be “working.”
  • In step S[0131] 35, the status-detection section 4 acquires a text message input by the user on another channel, and counts the number of characters.
  • In step S[0132] 36, the status-detection section 4 judges whether the input character count is greater than or equal to a predetermined standard character count. Next, the process flow goes to step S33, and the user status is determined. Namely, if the input character count is greater than or equal to the predetermined standard character count, the input message is long and, therefore, the user status is judged to be “working.” Conversely, if the input character count is less than the predetermined standard character count, and the input message is short, the user status is determined not to be “working.”
  • (5) Judge Responding Subroutine [0133]
  • FIG. 13 is a flowchart illustrating the flow of a judge responding subroutine executed by the status-[0134] detection section 4. If the process flow goes to step S16 in the judge status routine, the following subroutine is executed.
  • In step S[0135] 41, the status-detection section 4 judges whether a user on the call source channel is inputting a remark. If it is judged that the user is inputting on the call source channel, the process flow goes to step S42. If it is judged that the user is not inputting on the call source channel, the process flow goes to step S43, discussed later.
  • In step S[0136] 42, the status-detection section 4 judges whether predetermined time T4 has elapsed since the keyword utterance. If predetermined time T4 has not elapsed, the process flow returns to step S41, and the subroutine is re-executed. If predetermined time T4 has elapsed since the keyword utterance, the process flow goes to step S43. In other words, step S41 and step S42 judge whether the user is trying to respond to a keyword utterance and the response is taking time. Although the decision in this example is performed based on the inputting time, the decision may also be based on the input text message character count as discussed earlier—the standard for making the decision is not especially limited.
  • In step S[0137] 43, the status-detection section 4 determines whether the user status is responding to a keyword utterance. In the present subroutine, the user status is determined to be “responding” if a text message is being input on the call source channel from the time when the keyword was uttered until predetermined time T4 elapses. Subsequently, the process flow returns to the judge status subroutine. If it is judged in step S41 that a text message is being input on the call source channel, then the user status is judged to be “other,” and the process flow returns to step S1 in the main routine.
  • Second Embodiment [0138]
  • (Configuration) [0139]
  • The following explains the communication support system in accordance with a second embodiment of the present invention. FIG. 14 shows the overall configuration of the communication support system the present invention in the second embodiment. Connecting a chat server, a plurality of user terminals and a proxy terminal via a computer network constitutes the communication support system in this embodiment. [0140]
  • FIG. 15 is a block diagram illustrating the configuration of the proxy terminal and user terminal of the present embodiment. The proxy terminal and user terminal are both provided with a chat client. The proxy terminal further has a [0141] proxy reporting device 21. The user terminal further has a status-detection section 24 and a display module 32.
  • (1) Proxy Terminal [0142]
  • The [0143] proxy reporting device 21 has a keyword-detection module 22, a keyword database (DB) 23, a monitor module 33, a reporting module 29, a report destination DB 30 and a schedule DB 31.
  • The keyword-[0144] detection module 22 detects keywords from remarks on a channel, in the same manner as in the keyword-detection module 22 on the user terminal in the first embodiment. However, in the proxy terminal, the keyword-detection module 22 judges whether there has been utterance with regard to keywords of all users participating on the call source channel. In addition, if the keyword-detection module 22 detects a keyword registered by any user, it judges whether the call source user is not the same as the user called by the keyword. If not the same, the keyword-detection module 22 reports predetermined information to the monitor module 33, and requests the detection of the status of the called user. In addition to the call source channel name and the nickname of the call source user, the predetermined information also includes the nickname of the called user.
  • FIG. 16 shows an example of a [0145] keyword DB 23 used by the keyword-detection module 22 for detecting keywords. The nickname of the user connected to the proxy terminal via the network and the word registered as a keyword by that user are correlated and stored in keyword DB 23 shown in FIG. 16. For example, the user whose nickname is “tana” registers her real name “Tanaka” and “Tamie,” her nickname “tana” and “all” in keyword DB 23. If nickname “katz” utters “Tanaka,” the keyword-detection module 22 consults keyword DB 23 and acquires the nickname “tana” of the user who registered “Tanaka” as a keyword. Next, the keyword-detection module 22 compares the nickname “katz” of the call source user with the nickname “tana” of the called user. Since the two do not match, the keyword-detection module 22 notifies the monitor module 33 of both nicknames and the channel name.
  • The [0146] monitor module 33 first judges whether the called user terminal is booted up. If the called user terminal is not running, the monitor module 33 notifies the reporting module 29 to that effect. If the called user terminal is running, the monitor module 33 requests the called user terminal to detect the user status. In addition, the monitor module 33, in accordance with the request, stands by for user status notification from the called user terminal. If the monitor module 33 is notified of the user status by the user terminal, it sends the reported user status to the reporting module 29.
  • The reporting module. [0147] 29 consults the report destination DB 30 and specifies the report destination for the determined user status, likewise as with the reporting module 9 in the first embodiment. However, the report destination DB 30 differs from the first embodiment in that it is configured to store a report destination table 10 of the first embodiment each user connected to the proxy terminal via the network.
  • FIG. 17 shows an example of the [0148] report destination DB 30. The nicknames of users connected to the proxy terminal, the nicknames of call source users and the nicknames of report destination users are correlated and stored in the report destination DB 30. For example, consider the case in which the user whose nickname is “katz” utters the keyword of the user whose nickname is “tana.” The reporting module 29 searches the report destination DB using the nickname “tana” as a key, and acquires the report destination table of the called user “tana.” Next, the reporting module 29 reads the report destination set for the call source user “katz.” In FIG. 17, the nicknames “katz” and “suzu” are set as the report destinations.
  • In addition, the reporting [0149] module 29 determines the text message to be reported based on the reported user status and the content of the schedule DB 31, likewise as with the reporting module 9 in the first embodiment. However, the present embodiment differs from the first embodiment in that the schedules of all users connected to the proxy terminal are stored in the schedule DB 31.
  • (2) User Terminal [0150]
  • The status-[0151] detection section 24 is provided with an event-detection module 25, a screen saver detection module 26 and a recording module 27. The status-detection module 24 detects through the event-detection module 25 and the screen saver detection module 26 whether keyboard or mouse user input is directed to the chat client, and whether the screen saver is operating, likewise as with the status-detection section 4 in the first embodiment. In addition, the results of the detection are recorded in an event table. However, the present embodiment differs from the first embodiment in that the status-detection section 24 detects the user status in accordance with a request from the monitor module 33 of the proxy terminal, and notifies the proxy terminal of the detected user status.
  • The [0152] display module 32 displays on the screen an icon that indicates the reported user status, likewise as with the first embodiment.
  • (Process Flow) [0153]
  • The following explains the processes executed in the status notification system. FIG. 18 is a flowchart illustrating the main routine executed by the proxy terminal in the present embodiment. The following routine is initiated by loading the chat client in the proxy terminal or by connecting the chat client to the chat server. [0154]
  • In step S[0155] 51, the event-detection module 25 judges whether there has been a remark in any channel. If there has been a remark, the process flow goes to step S52. If there has not been a remark, the decision is re-executed. In other words, in step S51, the keyword-detection module 22 stands by for a remark on any channel.
  • In step S[0156] 52, the keyword-detection module 22 judges whether the keyword of any user is included in a remark. Consulting keyword DB 23 carries out this decision. If it is judged that the keyword of any user is included in a remark, the process flow goes to step S53. If it judged that no keyword of any user is included in a remark, the process flow returns to step S51, and the keyword-detection module 22 stands by for the next remark.
  • In step S[0157] 53, the keyword-detection module 22 acquires from the chat client the nickname of the call source user that uttered the keyword, the nickname of the user called by the keyword utterance and the call source channel on which the remark occurred.
  • In step S[0158] 54, the keyword-detection module 22 judges whether the call source user and the called user are the same user. If the two users are different users, the call source user, the called user and the call source channel name are reported to the monitor module 33, and the process flow goes to step S55. If the call source user and the called user are the same user, the process flow returns to step S51, and the keyword-detection module 22 stands by for the next remark.
  • In step S[0159] 55, the monitor module 33 judges whether the called user's user terminal is running. If the called user's user terminal is not running, the process flow goes to step S58, discussed later. If the called user's user terminal is running, the process flow goes to step S56 for detecting the status of the called user.
  • In step S[0160] 56, the monitor module 33 requests the called user terminal to detect the user status.
  • In step S[0161] 57, the monitor module 33 stands by for a response to the request, and the process flow goes to step S58 when the user status is acquired.
  • In step S[0162] 58, the monitor module 33 sends to the reporting module 29 the user status of the called user acquired from the user terminal. In addition to the user status, the call source user and the call source channel are also sent. The reporting module 29 that receives the user status judges whether the user status is “absent.” If the user status is “absent,” the process flow goes to step S59. If not “absent,” the process flow goes to step S60, discussed later.
  • In step S[0163] 59, the reporting module 29 reads the schedule of the called user from the schedule DB 31.
  • In step S[0164] 60, the reporting module 29 determines the text message to be reported to the call source user based on the user status and the user schedule.
  • In step S[0165] 61, the reporting module 29 reads the report destination DB 30 based on the nickname of the called user, and specifies the text message report destination. Next, the reporting module 29 reports the text message and status information to the determined report destination. At the user terminal that receives the text message and status information, the display module displays the reported text message and changes the icon.
  • Step S[0166] 62 judges whether the chat client program is finished; if finished, the present routine ends. If the chat client program is not finished, the process flow returns again to step S51 and the routine is repeated.
  • The process flow at the user terminal is to detect the real-time status of the user called by another user, and to give notification, likewise as with the judge status routine in the first embodiment. However, the present embodiment differs from the first embodiment in that user terminals perform the judge status routine in accordance with requests from the proxy terminal, and in that the proxy terminal notifies the user terminals of the user situations/status. [0167]
  • Other Embodiments [0168]
  • A proxy terminal is provided in the second embodiment, and that proxy terminal is provided with a chat client and a proxy reporting device. However, a form is also possible that provides the proxy reporting device in an information terminal operated by the chat server. In this case, the keyword-[0169] detection module 22 acquires remarks on the channel from the chat server. Moreover, the reporting module 29 issues text messages via the chat server.
  • Various details of the present invention may be changed without departing from its spirit nor its scope. Furthermore, the foregoing description of the embodiments according to the present invention are provided for illustration only, and not for the purpose of limiting the invention as defined by the appended claims and their equivalents. [0170]

Claims (19)

What is claimed is:
1. A communication support method wherein a plurality of users mutually share a network, used in a communication device that is simultaneous, bi-directional communication-enabled, the communication support method comprising:
preparing a predetermined correlation between predetermined text information and a second user among the users;
detecting an utterance of any of the predetermined text information by a first user on the network;
in response to the text information detection, finding a status of the second user correlated with the detected text information;
matching the first user, who uttered the text information, to a predetermined correlation between the first user and a set of one or more users; and
sending the detected second user status over the network to the set of one or more users.
2. A communication support system wherein identical networks are mutually shared, used in a communication device that is simultaneous bi-directional communication-enabled, the communication support system being provided with:
a first storage means for storing predetermined text information correlated with communication devices on a network;
a detection means for detecting sending of any of the text information from a first communication device on any network;
a decision means for judging the user status of a second communication device in accordance with the detection of the text information, based on status of the second communication device correlated with the detected text information; and
a reporting means for sending the user status to the network to which the text information was sent.
3. A communication support system wherein communication devices are enabled for simultaneous bi-directional communication over a network, the communication support system comprising:
a first storage means for storing predetermined text information correlated with a second of the communication devices on the network;
a detection means for detecting a sending of any of the text information stored in said first storage means, where the sending is from a first communication device on the network;
a decision means for judging a status of a user of the second communication device in accordance with the detection of the text information, based on a status of the second communication device correlated with the detected text information;
a second storage means for storing a predetermined correlation between the first communication device and a set of one or more communication devices from among the communication devices on the network; and
a reporting means for sending the user status to the network to which the text information was sent, said reporting means determining a report destination for the user status in accordance with said second storage means, and reporting the user status to the report destination via the network, where the report destination is the set of one or more communication devices.
4. The communication support system set forth in claim 3, further comprising:
a third storage means for storing user schedules correlated with the communication devices; and wherein
the user status to be sent to the network is further judged based on a user schedule corresponding to the second communication device.
5. The communication support system set forth in claim 3, further comprising:
an acquisition means for detecting whether the second communication device is operating, and acquiring the user status from said decision means in accordance with the detecting.
6. The communication support system set forth in claim 3, further comprising:
a display means for visually displaying a status of each user sharing the network, enabled for changing the displayed status of the user of the second device in accordance with the user status sent from the network.
7. A status notification device used together with a communication device that is simultaneous, bi-directional communication-enabled, wherein a plurality of users mutually share a network, the status notification device being provided with:
a first storage means for storing predetermined text information;
a detection means for detecting that any of the text information has been sent from another communication device on the network by comparing the sent text information with the predetermined text information;
a decision means for judging a user status of a user of the communication device in accordance with the detection of the text information, based on a status of the communication device;
a second storage means for storing a predetermined correlation between a communication device that sent the text information and a set of one or more communication devices from among the communication devices on the network; and
a reporting means for sending the user status over the network through which the text information was sent, said reporting means determining a report destination for the user status in accordance with said second storage means, and reporting the user status to the report destination via the network, where the report destination is the set of one or more communication devices.
8. A proxy device used by a communication device that is simultaneous, bi-directional communication-enabled wherein a plurality of users mutually share a network, the proxy device comprising:
a first storage means for storing a predetermined correlation between text information and a second communication device;
a detection means for detecting a sending of any of the text information from a first communication device on a network, where the sent text information matches the predetermined text information;
an acquisition means for detecting whether the second communication device correlated with the detected and sent text information is operating, and acquiring from the second communication device a user status of the second communication device in accordance with the detecting;
a second storage means for storing a predetermined correlation between the first communication device that sent the text information and a set of one or more communication devices from among the communication devices on the network; and
a reporting means for sending over the network through which the text information was sent, said reporting means determining a report destination for the user status in accordance with said second storage means, and reporting the user status to the report destination via the network, where the report destination is the set of one or more communication devices.
9. A computer readable recording medium on which is recorded a status notification program used together with a communication device that is simultaneous, bi-directional communication-enabled wherein a plurality of users mutually share a network, the status notification program capable of performing a process comprising:
storing predetermined text information correlated with the communication device;
detecting a sending of the text information from another communication device on the network;
judging, in accordance with the detection of the text information, a user status of a user of the communication device based on a status of the communication device;
storing a predetermined correlation between the other communication device that sent the text information and a set of one or more communication devices from among the communication devices on the network; and
sending the user status over the network through which the text information was sent to the set of one or more communication devices.
10. A computer readable recording medium on which is recorded a proxy notification program wherein a plurality of users mutually share a same network, used in a communication device that is simultaneous, bi-directional communication-enabled, the proxy notification program capable of performing a process comprising:
storing a predetermined correlation between text information and a second communication device;
detecting the sending of any text information from a first communication device on the network;
finding, in response to the detecting of the sending of the text information detection, whether the second communication device correlated with the detected text information is operating, and acquiring a user status of a user of the second communication device in accordance with the detecting; and
sending the user status based on the detecting, to the set of one or more communication devices.
11. A communication support method wherein a plurality of users mutually share a network, used in a communication device that is simultaneous, bi-directional communication-enabled, the communication support method comprising:
preparing a predetermined correlation between predetermined text information and a second user among the users;
detecting an utterance of any of the predetermined text information by a first user on the network;
in response to the text information detection, finding a status of the second user correlated with the detected text information;
storing a user schedule correlated with the second user, wherein the user status of the second user is further based on the schedule; and
sending the detected second user status over the network.
12. A communication support system wherein communication devices that are enabled for simultaneous bi-directional communication over a network, the communication support system comprising:
a first storage means for storing predetermined text information correlated with at least one of the communication devices on the network;
a detection means for detecting sending of any of the text information stored in said first storage means, where the sending is from a first communication device on the network;
a decision means for judging a status of a user of a second communication device in accordance with the detection of the text information, based on a status of the second communication device correlated with the detected text information;
a second storage means for storing a schedule of the user of the second communication device, wherein the user status is further based on the schedule; and
a reporting means for sending the user status over the network.
13. A status notification device used together with a communication device that is simultaneous, bi-directional communication-enabled, wherein a plurality of users mutually share the same network, the status notification device being provided with:
a first storage means for storing predetermined text information;
a detection means for detecting that any of the text information has been sent from another communication device on the network by comparing the sent text information with the predetermined text information;
a decision means for judging a user status of a user of the communication device in accordance with the detection of the text information, based on a status of the communication device;
a second storage means for storing a schedule correlated with the second communication device, wherein the user status to be sent to the network is further based on the schedule; and
a reporting means for sending the user status over the network.
14. A proxy device used by a communication device that is simultaneous, bi-directional communication-enabled wherein a plurality of users mutually share a network, the proxy device comprising:
a first storage means for storing a predetermined correlation between text information and a second communication device;
a detection means for detecting a sending of any of the text information from a first communication device on a network, where the sent text information matches the predetermined text information;
an acquisition means for detecting whether the second communication device correlated with the detected and sent text information is operating, and acquiring from the second communication device a user status of the second communication device in accordance with the detecting;
a second storage means for storing a schedule correlated with the second communication device, wherein the user status to be sent to the network is further based on the schedule; and
a reporting means for the user status over the network.
15. A computer readable recording medium on which is recorded a status notification program used together with a communication device that is simultaneous, bi-directional communication-enabled wherein a plurality of users mutually share a network, the status notification program capable of performing a process comprising:
storing predetermined text information correlated with the communication device;
detecting a sending of the text information from another communication device on the network;
judging, in accordance with the detection of the text information, a user status of a user of the communication device based on a status of the communication device;
storing a user schedule correlated with the communication device, wherein the user status to be sent to the network is further based on the schedule; and
sending the user status over the network.
16. A computer readable recording medium on which is recorded a proxy notification program wherein a plurality of users mutually share a same network, used in a communication device that is simultaneous, bi-directional communication-enabled, the proxy notification program capable of performing a process comprising:
storing a predetermined correlation between text information and a second communication device;
detecting the sending of any text information from a first communication device on the network;
finding, in response to the detecting of the sending of the text information detection, whether the second communication device correlated with the detected text information is operating, and acquiring a user status of a user of the second communication device in accordance with the detecting;
storing a user schedule correlated with the communication device, wherein the user status to be sent to the network is further based on the schedule; and
sending the user status based on the detecting, to the set of one or more communication devices.
17. A method, comprising:
receiving a text message directed to a networked text discussion;
detecting in the text message a nickname of a participant in the discussion;
in response to the detecting, automatically determining a status of the participant;
detecting in the text message at least one of a name and a nickname of a sender of the text message;
matching the at least one of the name and the nickname of the sender to one or more other participants in the networked text discussion; and
sending the status to the one or more other participants in the discussion.
18. A method according to claim 17, wherein the status of the participant is determined by referring to a schedule of the participant.
19. A method of automatically detecting and propagating a status of a user in a chat session, comprising:
receiving a chat message sent to a client used by the user to participate in the chat session;
detecting in the chat message a pre-determined nickname of the user and a pre-determined nickname of a sender of the chat message;
automatically determining a user status of the user by referring to a schedule of the user; and
determining a set of recipients to receive the use status by referring to the pre-determined nickname of the sender of the chat message.
US10/386,666 1998-12-18 2003-03-13 Communication support method and communication support system Abandoned US20030154251A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US10/386,666 US20030154251A1 (en) 1998-12-18 2003-03-13 Communication support method and communication support system

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
JP10-361489 1998-12-18
JP36148998A JP3685938B2 (en) 1998-12-18 1998-12-18 Communication support method and communication support system
US09/429,926 US6584494B1 (en) 1998-12-18 1999-10-29 Communication support method and communication support system
US10/386,666 US20030154251A1 (en) 1998-12-18 2003-03-13 Communication support method and communication support system

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US09/429,926 Continuation US6584494B1 (en) 1998-12-18 1999-10-29 Communication support method and communication support system

Publications (1)

Publication Number Publication Date
US20030154251A1 true US20030154251A1 (en) 2003-08-14

Family

ID=18473794

Family Applications (2)

Application Number Title Priority Date Filing Date
US09/429,926 Expired - Fee Related US6584494B1 (en) 1998-12-18 1999-10-29 Communication support method and communication support system
US10/386,666 Abandoned US20030154251A1 (en) 1998-12-18 2003-03-13 Communication support method and communication support system

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US09/429,926 Expired - Fee Related US6584494B1 (en) 1998-12-18 1999-10-29 Communication support method and communication support system

Country Status (2)

Country Link
US (2) US6584494B1 (en)
JP (1) JP3685938B2 (en)

Cited By (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030135629A1 (en) * 2001-12-28 2003-07-17 Fujitsu Limited Advertising broadcast method and advertising broadcast device
US20040267939A1 (en) * 2003-06-30 2004-12-30 Hitachi, Ltd. Session control apparatus, software applied to session control apparatus, communication control method, and network system
US20050276407A1 (en) * 2004-06-09 2005-12-15 Avaya Technology Corp. Telephony device ring determination by scheduler
US20060190535A1 (en) * 2003-11-18 2006-08-24 Nokia Corporation Method, subject terminal device, target terminal device, data content server, system and computer programs for maintaining and updating data contents
US20070198647A1 (en) * 2006-02-23 2007-08-23 International Business Machines Corporation System, method and program for managing chat sessions
US20080201438A1 (en) * 2007-02-20 2008-08-21 Indrek Mandre Instant messaging activity notification
US20090022286A1 (en) * 2003-01-20 2009-01-22 Avaya Inc. Messaging advise in presence-aware networks
US20090031223A1 (en) * 2006-01-31 2009-01-29 Konami Digital Entertainment Co., Ltd Chat system, chat device and control method of chat server, information storage medium
WO2009077901A1 (en) * 2007-12-18 2009-06-25 Koninklijke Philips Electronics N.V. Method and system for enabling conversation
US20090182826A1 (en) * 2006-01-06 2009-07-16 Konami Digital Entertainment Co., Ltd. Chat System, Chat Device, Chat Server Control Method, And Information Storage Medium
US20100162138A1 (en) * 2008-12-23 2010-06-24 At&T Mobility Ii Llc Conversation bubbles including visual cues for threaded messaging applications
US7769154B1 (en) 2004-06-09 2010-08-03 Avaya Inc. Aggregated perceived presence
US20100235455A1 (en) * 2009-03-11 2010-09-16 Fujitsu Limited Information processing apparatus
US7995742B2 (en) 2002-12-04 2011-08-09 Avaya Inc. Outbound dialing decision criteria based
US8108516B2 (en) 2002-02-14 2012-01-31 Avaya Inc. Presence tracking and name space interconnection techniques
US8150003B1 (en) 2007-01-23 2012-04-03 Avaya Inc. Caller initiated undivert from voicemail
US8301581B2 (en) 2009-09-24 2012-10-30 Avaya Inc. Group compositing algorithms for presence
US8984420B2 (en) 2007-07-03 2015-03-17 Skype Instant messaging communication system and method
JP2015170234A (en) * 2014-03-10 2015-09-28 アルパイン株式会社 Electronic system, electronic apparatus, situation notification method thereof, and program
US9398152B2 (en) 2004-02-25 2016-07-19 Avaya Inc. Using business rules for determining presence
US20220277255A1 (en) * 2019-08-19 2022-09-01 Yanmar Power Technology Co., Ltd. Work reliever mediation system and farm machine sharer mediation system

Families Citing this family (76)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000250826A (en) * 1999-03-01 2000-09-14 Fujitsu Ltd Method and system for reporting state change
US7010110B2 (en) * 1999-03-31 2006-03-07 Walker Digital, Llc Method and apparatus for monitoring telephone status
JP4425407B2 (en) * 1999-05-13 2010-03-03 富士通株式会社 Conversation sending method and conversation system
JP4172886B2 (en) * 1999-10-08 2008-10-29 富士通株式会社 Pseudo client device, computer readable medium storing pseudo client program, and chat system
US6678719B1 (en) * 1999-12-20 2004-01-13 Mediaone Group, Inc. Virtual workplace intercommunication tool
JP3926963B2 (en) * 2000-03-03 2007-06-06 富士通株式会社 State setting system and method
US9736209B2 (en) 2000-03-17 2017-08-15 Facebook, Inc. State change alerts mechanism
US7624172B1 (en) 2000-03-17 2009-11-24 Aol Llc State change alerts mechanism
US20020021307A1 (en) * 2000-04-24 2002-02-21 Steve Glenn Method and apparatus for utilizing online presence information
US20020015003A1 (en) * 2000-08-07 2002-02-07 Masami Kato Virtual space system structured by plural user terminals and server device
JP2002073512A (en) * 2000-08-28 2002-03-12 Nifty Corp Conditions notice network system and computer-readable medium
US6983305B2 (en) * 2001-05-30 2006-01-03 Microsoft Corporation Systems and methods for interfacing with a user in instant messaging
US8644475B1 (en) 2001-10-16 2014-02-04 Rockstar Consortium Us Lp Telephony usage derived presence information
US7668915B2 (en) * 2001-12-20 2010-02-23 Motorola, Inc. System and method for responding to a communication message with a canned reply
US7299286B2 (en) 2001-12-27 2007-11-20 Nortel Networks Limited Personal user agent
US7227937B1 (en) 2002-03-19 2007-06-05 Nortel Networks Limited Monitoring natural interaction for presence detection
US7139797B1 (en) * 2002-04-10 2006-11-21 Nortel Networks Limited Presence information based on media activity
US7689649B2 (en) * 2002-05-31 2010-03-30 Aol Inc. Rendering destination instant messaging personalization items before communicating with destination
US7395329B1 (en) 2002-05-13 2008-07-01 At&T Delaware Intellectual Property., Inc. Real-time notification of presence availability changes
US7353455B2 (en) * 2002-05-21 2008-04-01 At&T Delaware Intellectual Property, Inc. Caller initiated distinctive presence alerting and auto-response messaging
US7370278B2 (en) * 2002-08-19 2008-05-06 At&T Delaware Intellectual Property, Inc. Redirection of user-initiated distinctive presence alert messages
US7496631B2 (en) * 2002-08-27 2009-02-24 Aol Llc Delivery of an electronic communication using a lifespan
US7363345B2 (en) * 2002-08-27 2008-04-22 Aol Llc, A Delaware Limited Liability Company Electronic notification delivery mechanism selection based on recipient presence information and notification content
US8392609B2 (en) 2002-09-17 2013-03-05 Apple Inc. Proximity detection for media proxies
US7555108B2 (en) * 2002-10-01 2009-06-30 Nortel Networks Limited Presence information for telephony users
US20040078445A1 (en) * 2002-10-17 2004-04-22 Malik Dale W. Forwarding instant messaging (IM) messages
US7716289B2 (en) * 2002-10-17 2010-05-11 At&T Intellectual Property I, L.P. Transferring instant messaging (IM) messages
US8965964B1 (en) 2002-11-18 2015-02-24 Facebook, Inc. Managing forwarded electronic messages
US7640306B2 (en) 2002-11-18 2009-12-29 Aol Llc Reconfiguring an electronic message to effect an enhanced notification
US8701014B1 (en) 2002-11-18 2014-04-15 Facebook, Inc. Account linking
US7428580B2 (en) 2003-11-26 2008-09-23 Aol Llc Electronic message forwarding
US8005919B2 (en) 2002-11-18 2011-08-23 Aol Inc. Host-based intelligent results related to a character stream
US7899862B2 (en) 2002-11-18 2011-03-01 Aol Inc. Dynamic identification of other users to an online user
US8122137B2 (en) 2002-11-18 2012-02-21 Aol Inc. Dynamic location of a subordinate user
CA2506585A1 (en) 2002-11-18 2004-06-03 Valerie Kucharewski People lists
US7590696B1 (en) 2002-11-18 2009-09-15 Aol Llc Enhanced buddy list using mobile device identifiers
US7636755B2 (en) 2002-11-21 2009-12-22 Aol Llc Multiple avatar personalities
US8037150B2 (en) 2002-11-21 2011-10-11 Aol Inc. System and methods for providing multiple personas in a communications environment
US7257218B2 (en) * 2002-12-30 2007-08-14 Nortel Networks Limited Presence enabled queue management
US7711810B2 (en) 2003-01-03 2010-05-04 Nortel Networks Limited Distributed services based on presence technology
JP2004220361A (en) * 2003-01-15 2004-08-05 Fujitsu Ltd Conversation system, information device for conversation system, conversation program, and computer readable recording medium which records conversation program
US7913176B1 (en) 2003-03-03 2011-03-22 Aol Inc. Applying access controls to communications with avatars
US7908554B1 (en) 2003-03-03 2011-03-15 Aol Inc. Modifying avatar behavior based on user action or mood
US20040179037A1 (en) 2003-03-03 2004-09-16 Blattner Patrick D. Using avatars to communicate context out-of-band
US20040210639A1 (en) 2003-03-26 2004-10-21 Roy Ben-Yoseph Identifying and using identities deemed to be known to a user
US7669134B1 (en) * 2003-05-02 2010-02-23 Apple Inc. Method and apparatus for displaying information during an instant messaging session
US7653693B2 (en) 2003-09-05 2010-01-26 Aol Llc Method and system for capturing instant messages
US8180840B2 (en) * 2003-10-14 2012-05-15 At&T Intellectual Property I, L.P. Automatically replying to instant messaging (IM) messages
KR100584369B1 (en) * 2003-11-06 2006-05-26 삼성전자주식회사 Method for providing status information of mobile communication terminal in mobile communication system and the mobile communication terminal
US9118574B1 (en) 2003-11-26 2015-08-25 RPX Clearinghouse, LLC Presence reporting using wireless messaging
US20050138129A1 (en) * 2003-12-23 2005-06-23 Maria Adamczyk Methods and systems of responsive messaging
US20050182816A1 (en) * 2004-02-12 2005-08-18 Wanrong Lin Automated dissemination of presence and availability schedule
US8229454B1 (en) 2004-03-22 2012-07-24 Avaya Inc. Personal location information management
US7720012B1 (en) * 2004-07-09 2010-05-18 Arrowhead Center, Inc. Speaker identification in the presence of packet losses
US9652809B1 (en) 2004-12-21 2017-05-16 Aol Inc. Using user profile information to determine an avatar and/or avatar characteristics
US8358762B1 (en) 2005-03-21 2013-01-22 Aol Inc. Conference calls and meetings via electronic messaging interface
EP1734728B1 (en) * 2005-06-17 2014-08-13 BlackBerry Limited Method and apparatus for switching between concurrent messaging sessions
US7724703B2 (en) * 2005-10-13 2010-05-25 Belden, Inc. System and method for wireless network monitoring
US20070143415A1 (en) * 2005-12-15 2007-06-21 Daigle Brian K Customizable presence icons for instant messaging
US8966018B2 (en) 2006-05-19 2015-02-24 Trapeze Networks, Inc. Automated network device configuration and network deployment
US9258702B2 (en) 2006-06-09 2016-02-09 Trapeze Networks, Inc. AP-local dynamic switching
US8818322B2 (en) 2006-06-09 2014-08-26 Trapeze Networks, Inc. Untethered access point mesh system and method
US20070300169A1 (en) * 2006-06-26 2007-12-27 Jones Doris L Method and system for flagging content in a chat session and providing enhancements in a transcript window
JP4740076B2 (en) * 2006-09-12 2011-08-03 シャープ株式会社 Message exchange terminal
US7561041B2 (en) * 2006-09-13 2009-07-14 At&T Intellectual Property I, L.P. Monitoring and entry system presence service
US8316117B2 (en) * 2006-09-21 2012-11-20 At&T Intellectual Property I, L.P. Personal presentity presence subsystem
US20080077685A1 (en) * 2006-09-21 2008-03-27 Bellsouth Intellectual Property Corporation Dynamically configurable presence service
JP5172156B2 (en) * 2007-01-15 2013-03-27 富士通株式会社 Information processing apparatus, display method, and display program
JP2008217621A (en) * 2007-03-07 2008-09-18 Netman:Kk Behavior modification measuring system
JP4527748B2 (en) * 2007-05-01 2010-08-18 富士通株式会社 Status distribution method and status distribution device
JP4826627B2 (en) * 2008-12-10 2011-11-30 ソニー株式会社 Information terminal device, information terminal device processing method and program
US20100235448A1 (en) * 2009-03-12 2010-09-16 Morris Robert P Methods, Systems, And Computer Program Products For Reporting A Change In Presentable Content Of A Communication Message
US9258376B2 (en) 2009-08-04 2016-02-09 At&T Intellectual Property I, L.P. Aggregated presence over user federated devices
JPWO2011077501A1 (en) * 2009-12-26 2013-05-02 株式会社ラピースドリーム Communication system
KR101613809B1 (en) * 2015-01-02 2016-04-19 라인 가부시키가이샤 Method, system and recording medium for providing messenger service having specific condition
JP7439025B2 (en) 2021-08-18 2024-02-27 Lineヤフー株式会社 Information processing device, information processing system, information processing method, and information processing program

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5493692A (en) * 1993-12-03 1996-02-20 Xerox Corporation Selective delivery of electronic messages in a multiple computer system based on context and environment of a user
US5634005A (en) * 1992-11-09 1997-05-27 Kabushiki Kaisha Toshiba System for automatically sending mail message by storing rule according to the language specification of the message including processing condition and processing content
US5793365A (en) * 1996-01-02 1998-08-11 Sun Microsystems, Inc. System and method providing a computer user interface enabling access to distributed workgroup members
US5802253A (en) * 1991-10-04 1998-09-01 Banyan Systems Incorporated Event-driven rule-based messaging system
US5987503A (en) * 1996-06-28 1999-11-16 Fujitsu Limited System and method for displaying an electronic mail containing a keyword detected in a chat session message
US6128646A (en) * 1997-12-24 2000-10-03 Genesys Telecommunications Laboratories Inc. System for routing electronic mail to best qualified person based on content analysis
US6278996B1 (en) * 1997-03-31 2001-08-21 Brightware, Inc. System and method for message process and response
US6353827B1 (en) * 1997-09-04 2002-03-05 British Telecommunications Public Limited Company Methods and/or systems for selecting data sets

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2778488B2 (en) 1994-11-04 1998-07-23 日本電気株式会社 Awareness control device

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5802253A (en) * 1991-10-04 1998-09-01 Banyan Systems Incorporated Event-driven rule-based messaging system
US5634005A (en) * 1992-11-09 1997-05-27 Kabushiki Kaisha Toshiba System for automatically sending mail message by storing rule according to the language specification of the message including processing condition and processing content
US5493692A (en) * 1993-12-03 1996-02-20 Xerox Corporation Selective delivery of electronic messages in a multiple computer system based on context and environment of a user
US5793365A (en) * 1996-01-02 1998-08-11 Sun Microsystems, Inc. System and method providing a computer user interface enabling access to distributed workgroup members
US5987503A (en) * 1996-06-28 1999-11-16 Fujitsu Limited System and method for displaying an electronic mail containing a keyword detected in a chat session message
US6278996B1 (en) * 1997-03-31 2001-08-21 Brightware, Inc. System and method for message process and response
US6353827B1 (en) * 1997-09-04 2002-03-05 British Telecommunications Public Limited Company Methods and/or systems for selecting data sets
US6128646A (en) * 1997-12-24 2000-10-03 Genesys Telecommunications Laboratories Inc. System for routing electronic mail to best qualified person based on content analysis

Cited By (43)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030135629A1 (en) * 2001-12-28 2003-07-17 Fujitsu Limited Advertising broadcast method and advertising broadcast device
US8108516B2 (en) 2002-02-14 2012-01-31 Avaya Inc. Presence tracking and name space interconnection techniques
US7995742B2 (en) 2002-12-04 2011-08-09 Avaya Inc. Outbound dialing decision criteria based
US8064574B2 (en) 2003-01-20 2011-11-22 Avaya Inc. Messaging advise in presence-aware networks
US8050388B2 (en) 2003-01-20 2011-11-01 Avaya Inc. Messaging advise in presence-aware networks
US7936865B2 (en) 2003-01-20 2011-05-03 Avaya Inc. Messaging advise in presence-aware networks
US20090022286A1 (en) * 2003-01-20 2009-01-22 Avaya Inc. Messaging advise in presence-aware networks
US8218735B2 (en) 2003-01-20 2012-07-10 Avaya Inc. Messaging advise in presence-aware networks
US20090034700A1 (en) * 2003-01-20 2009-02-05 Avaya Inc. Messaging advise in presence-aware networks
US8014497B2 (en) 2003-01-20 2011-09-06 Avaya Inc. Messaging advise in presence-aware networks
US8098799B2 (en) 2003-01-20 2012-01-17 Avaya Inc. Messaging advise in presence-aware networks
US8107597B2 (en) 2003-01-20 2012-01-31 Avaya Inc. Messaging advise in presence-aware networks
US7882235B2 (en) * 2003-06-30 2011-02-01 Hitachi, Ltd. Session control apparatus, software applied to session control apparatus, communication control method, and network system
US20110093601A1 (en) * 2003-06-30 2011-04-21 Hitachi, Ltd. Session control apparatus, software applied to session control apparatus, communication control method, and network system
US8396972B2 (en) 2003-06-30 2013-03-12 Hitachi, Ltd. Session control apparatus, software applied to session control apparatus, communication control method, and network system
US20040267939A1 (en) * 2003-06-30 2004-12-30 Hitachi, Ltd. Session control apparatus, software applied to session control apparatus, communication control method, and network system
US20060190535A1 (en) * 2003-11-18 2006-08-24 Nokia Corporation Method, subject terminal device, target terminal device, data content server, system and computer programs for maintaining and updating data contents
US9398152B2 (en) 2004-02-25 2016-07-19 Avaya Inc. Using business rules for determining presence
US7769154B1 (en) 2004-06-09 2010-08-03 Avaya Inc. Aggregated perceived presence
US20050276407A1 (en) * 2004-06-09 2005-12-15 Avaya Technology Corp. Telephony device ring determination by scheduler
US20090182826A1 (en) * 2006-01-06 2009-07-16 Konami Digital Entertainment Co., Ltd. Chat System, Chat Device, Chat Server Control Method, And Information Storage Medium
US7921168B2 (en) * 2006-01-06 2011-04-05 Konami Digital Entertainment Co., Ltd. Chat system, chat device, chat server control method, and information storage medium including chat stop limiting capability based on keyword
US20090031223A1 (en) * 2006-01-31 2009-01-29 Konami Digital Entertainment Co., Ltd Chat system, chat device and control method of chat server, information storage medium
US8234342B2 (en) 2006-01-31 2012-07-31 Konami Digital Entertainment Co., Ltd. Chat system, chat device and control method of chat server, and information storage medium for advancing an end timing of a message reception stopping period
US7882194B2 (en) 2006-02-23 2011-02-01 International Business Machines Corporation System, method and program for managing chat sessions
US20070198647A1 (en) * 2006-02-23 2007-08-23 International Business Machines Corporation System, method and program for managing chat sessions
US8150003B1 (en) 2007-01-23 2012-04-03 Avaya Inc. Caller initiated undivert from voicemail
US20080201438A1 (en) * 2007-02-20 2008-08-21 Indrek Mandre Instant messaging activity notification
US8417784B2 (en) * 2007-02-20 2013-04-09 Skype Instant messaging activity notification
US9720565B2 (en) 2007-02-20 2017-08-01 Skype Instant messaging activity notification
US9223464B2 (en) 2007-02-20 2015-12-29 Skype Instant messaging activity notification
US8849934B2 (en) 2007-02-20 2014-09-30 Skype Instant messaging activity notification
US8984420B2 (en) 2007-07-03 2015-03-17 Skype Instant messaging communication system and method
US9483277B2 (en) 2007-07-03 2016-11-01 Skype Instant messaging communication system and method
US10291558B2 (en) 2007-07-03 2019-05-14 Skype Instant messaging communication system and method
WO2009077901A1 (en) * 2007-12-18 2009-06-25 Koninklijke Philips Electronics N.V. Method and system for enabling conversation
US20100162138A1 (en) * 2008-12-23 2010-06-24 At&T Mobility Ii Llc Conversation bubbles including visual cues for threaded messaging applications
US9160691B2 (en) 2009-03-11 2015-10-13 Fujitsu Limited Information processing apparatus implementing response to editing message
US8364768B2 (en) 2009-03-11 2013-01-29 Fujitsu Limited Information processing apparatus implementing editing message
US20100235455A1 (en) * 2009-03-11 2010-09-16 Fujitsu Limited Information processing apparatus
US8301581B2 (en) 2009-09-24 2012-10-30 Avaya Inc. Group compositing algorithms for presence
JP2015170234A (en) * 2014-03-10 2015-09-28 アルパイン株式会社 Electronic system, electronic apparatus, situation notification method thereof, and program
US20220277255A1 (en) * 2019-08-19 2022-09-01 Yanmar Power Technology Co., Ltd. Work reliever mediation system and farm machine sharer mediation system

Also Published As

Publication number Publication date
US6584494B1 (en) 2003-06-24
JP2000181847A (en) 2000-06-30
JP3685938B2 (en) 2005-08-24

Similar Documents

Publication Publication Date Title
US6584494B1 (en) Communication support method and communication support system
US8831647B2 (en) Presence-enabled mobile access
US8332760B2 (en) Dynamically mapping chat session invitation history
JP3704434B2 (en) Network search method and network search system
US8849907B1 (en) System and method for notifying participants of topics in an ongoing meeting or conference
US8019069B1 (en) Method and apparatus for altering participants in a conference call to topics of interest
US20160261648A1 (en) Communication system and method of using the same
US8433761B2 (en) Method for receiving and displaying segments of a message before the message is complete
US20120269185A1 (en) System and method for computer based collaboration initiated via a voice call
US20200112595A1 (en) Communication system and method of using the same
US7295657B1 (en) Automated selection of a backup recipient and distribution of an instant messaging request to the backup recipient
US20180131731A1 (en) Systems, methods, and computer programs for establishing a screen share session for a remote voice call
US20170288943A1 (en) Supplying Context Data to a Servicing Entity
US20080281914A1 (en) Computer system
US20110082942A1 (en) Communication terminal device, communication control method, and communication control program
US9224134B2 (en) Arranging a conversation among a plurality of participants
CN103563344A (en) Method and apparatus for joining a meeting using the presence status of a contact
US20060031366A1 (en) Method for dynamically ordering instant messaging lists
US8909718B2 (en) Methods and systems for incorporating a third user into an instant message session
KR20190036604A (en) Hybrid chat providing method using predefined conversation flow and hybrid chat service server
US8605882B1 (en) Adding a teleconference caller to a group instant messaging chat
JPH08214023A (en) Network system capable of schedule management
KR102053344B1 (en) Apparatus and method for providing conference call in mobile communication
US9959416B1 (en) Systems and methods for joining online meetings
CN113709021B (en) Session message generation method and device, computer equipment and storage medium

Legal Events

Date Code Title Description
STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION