Patent Application
20110173280
This application claims priority to the Japanese Application No. 2008-260325, filed Oct. 7, 2008.
The disclosure relates to real-time text exchange communications and communication sessions.
In recent years, real-time communications where text is exchanged between two or more participants has become increasingly popular. For example, chat communications (such as instant messaging) are often used.
Real-time message exchanges are to be contrasted with non-real-time mechanisms, such as electronic mails and electronic bulletin boards. In these non-real-time communications, a message can be sent unilaterally. This type of unilateral communication is possible whether the other party of communication is available or not at the time the message was sent. It may take a long time until the user receives the reply.
In contrast, during real-time message exchanges a communication session is established between two or more people, which are concurrently participating in the communication session. This type of communication is bi-directional and feedback/message can be instantly read and responded to during the communication session. Because communication occurs concurrently, a technique of displaying presence information showing the status of the other party is used. This status informs a potential communicator whether a desired individual is available for a communication session.
One aspect of the disclosure is for a method, computer program product, system, and/or apparatus for providing a user status during a real-time communication session to other users of the communication session. In the aspect, at least two applications can be instantiated on a client device. Each of the at least two applications can include a user interface for interacting with a user of the client device. One of the applications can be a real-time communication application through which the user is participating in a real-time communication session with at least one remotely located user. Another of the applications can be referred to as a second application. Status information relating to user interactions with the second application can be determined. A status message can be generated that includes content from the determined status information. The status message can be generated without manually entered user input. The status message can be conveyed automatically and without manual user input to the at least one remotely located user via the real-time communication application during the real-time communication application.
One aspect of the disclosure is for a method, computer program product, system, and/or apparatus for providing a user status during an Instant Messaging (IM) communication session to other users of the communication session. An instant messaging (IM) status agent can execute on a client device, which also executes an IM application having a user interface through which a human user corresponds to at least one remotely located user during an IM communication session. At least one active window can be determined for an application that is not the IM application, wherein the application is referred to as a second application. Without manual user input from the human user a status message can be generated. The status message can indicate that the human user is interacting via the second application. The status message can be conveyed via the IM application to the at least one remotely located user.
Displaying presence information during a real-time text exchange communication commonly occurs by using a contact list, a BUDDY LIST, and similar artifacts. This information is useful to know whether a communication session (e.g., an IM session) can be initiated successfully. This information is less helpful, however, during the communication session.
No existing “presence information” related to a communication session helps to inform participants of activities of other participants during the session. That is, often one or more session participant is unaware of whether actions are being taken during the communication session by another, or whether another session participant is not actively engaged in activities related to the communication session. One of the few “status” messages currently possible during a real-time text exchange communication session is an indicator that a person is typing within the text input session of an instant messaging interface. This lets participants know that they can expect to receive a message shortly. This is especially useful when relatively long messages are being entered, which causes other session participants to wonder what is going on in absence of receiving a message that the other participant is typing.
During the course of developing inventive content of the current disclosure, Applicants have discovered that additional situations (ones other than a user typing a response) exist, which result in delays during a communication session. Specifically, many modern forms of real-time communication involve an exchange of additional content (e.g., files, video, etc.) that supplement the communication exchange. These file may have to be opened in applications other than the IM application, and delays (in responses to IM communication) can be expected as this information is digested.
At present, it is impossible to know whether the other party of a communication session is doing any work related to the message exchange, doing nothing, or is doing something completely unrelated to the communication session. That is, the only way to know what a user is going, is to rely on user-input messages (such as “give me a minute, I′m looking at the video now). These messages are often not communicated, as the user who could send such a message is currently busy with other activity (such as looking at a video, editing a document, etc.). Even if a user does think to send a message, the time required to do so could otherwise be spent performing the activity in question (which would help expedite the real-time communication session).
Resolving this uncertainty by providing additional feedback during a communication session on a participants status, is believed to greatly enhance the end-user experience during a communication session, which is why a solution to this effect has been developed and expressed herein.
The present disclosure provides an ability to communicate desktop status information from one participant in a communication session (e.g., an instant messaging session) to another. This desktop status information can, for example, include what applications a user is running on their desktop in addition to the IM application, and what activities are being performed with these applications during the IM session. In one embodiment, the desktop status information that is communicated can be restricted to information related and pertinent to the instant messaging session.
For example, a user can be completing a report, uploading/downloading a file, etc., which is consistent (or inconsistent) with communication elements discussed during the IM session. The desktop status information and related messages can be conveyed without active user intervention, in one embodiment.
Thus, if a user is receiving and opening a PFD document conveyed during the IM session and discussed during the IM session, a notification can be sent (via IM message and the IM interface) informing a communication participant that another participant is waiting for the document to arrive, is opening the document, is reading the document, etc. Additionally, in one embodiment, a series of rules can be defined to determine what information is communicated to others and what is not during a communication session. This exchanged information can have a nexus with desktop activities outside the instantiated IM application, which is utilized to participate in the IM session and/or to convey the desktop status information.
The disclosure is now described within the context of one or more embodiments, although the description is intended to be illustrative of embodiments of the invention as a whole, and is not to be construed as limiting other embodiments of the invention to the embodiments shown. It is appreciated that various modifications may occur to those skilled in the art that, while not specifically shown herein, are nevertheless within the true spirit and scope of the invention.
As will be appreciated by one skilled in the art, aspects of the disclosure may be embodied as a system, method or computer program product. Accordingly, aspects of the disclosure may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Furthermore, aspects of the disclosure may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.
Any combination of one or more computer readable medium(s) may be utilized. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.
A computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.
Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing. Computer program code for carrying out operations for aspects of the disclosure may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).
Aspects of the disclosure are described below with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.
The computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
Reference is now made to
The clients 10a and 10b are terminal devices such as personal computers (PCs), mobile phones, kiosks, etc. More specifically, the clients (10a and 10b) are each a terminal device used by a human user to exchange messages with one or more other users. In one embodiment, one or more automated software agents can be a communication endpoint involved in a session where messages are conveyed (as opposed to a session having human user-to-user communications). The communication session where messages are conveyed can be a real-time communication within which text exchanges are possible. For example, instant messaging communications, chat forum communications, text messages, co-browsing, real-time collaboration, and the like can be considered communication sessions for purposes of the disclosure. Additionally, modality conversions (e.g., from text to speech and/or speech to text) can occur so that one or more of the participants of a communication session are interacting with a client 10a, 10b using voice input/output. Although two clients are shown in the figure, any number (1 to N) of clients can be utilized and are contemplated. In the following, the client 10a, 10b may simply be referred to as the “client 10” when the distinction is unnecessary.
The IM server 20 is a server computer which manages message exchange by IM via the network 80. For example, in response to requests for participation in the same IM session from the client 10a operated by a user A and the client 10b operated by a user B, the IM server 20 manages identification information of the IM session, identification information of the users A and B, and identification information of the clients 10a and 10b. Further, in response to input of a message from the user A or B, the IM server 20 controls such that the message is transmitted to the client 10 of the other party.
Use of the term IM server 20 is to be understood to represent a server that facilitates real-time communications that can include an exchange of text. Thus, a chat server, a GOOGLE WAVE server, a collaboration server, an online meeting server, and other related categories of servers are to be included in the definition of IM server 20 as used herein. Further, a combination of servers (that together maintain presence information and facilitate a real-time exchange of text messages over a network 80 are contemplated). For example, a peer-to-peer network, where an aggregation of the peers performs the functions of IM server 20, can be considered an IM server 20 as detailed herein.
The network 80 is communication means used for message exchange. The network 80 may be the Internet, a LAN (Local Area Network), a metropolitan area network (MAN), etc. That is, Network 120 can include any hardware/software/and firmware necessary to convey data encoded within carrier waves. Data can be contained within analog or digital signals and conveyed though data or voice channels. Network 80 can include local components and data pathways necessary for communications to be exchanged among computing device components and between integrated device components and peripheral devices. Network 80 can also include network equipment, such as routers, data lines, hubs, and intermediary servers which together form a data network, such as the Internet. Network 80 can also include circuit-based communication components and mobile communication components, such as telephony switches, modems, cellular communication towers, and the like. Network 80 can include line based and/or wireless communication pathways.
In the computer system having the above-described configuration, in the present embodiment, an IM status agent is installed in each client 10. The IM status agent determines a status of a user (or, a user status) from information regarding the user's activity related to the IM (hereinafter, referred to as the “user activity information”), and displays the determined user status on the client 10 of the other party, to ensure smoother communication between the users. The “user activity information” can include “desktop status information” which relates to activities that a user is performing via a desktop interface. These activities can occur outside the boundaries of the instantiated IM application, yet can related and/or be pertinent to the communication session. For example, activities can include what window has focus, what documents are open within other windows of the desktop, a status of file exchanges, email message arrivals, what content/documents is presently displayed on a user's desktop, and the like.
For example, the user activity information includes: IM status information; activated application information (activated AP information); window status information; and events occurring within activated applications (other than the IM application used to participate in the communication session).
Among them, the IM status information indicates a status of a message in the IM. For example, it indicates an input status of a message text to the IM (i.e., whether the message text is being input). The IM status information can also indicate whether the IM window has focus within a desktop or whether another application window currently has focus.
The activated AP information shows an application which is activated by a user operation on the IM. This information includes, for example, a name of the activated application, and a process ID which uniquely identifies the process generated as a result of activation of the application.
The window status information indicates a status of a window for the application activated by the user operation on the IM. Specifically, it shows, for example, a focus status of the window (i.e., whether a user operation is being performed on the window), and a status of switch of focus between windows (i.e., whether the user operations are being performed on the window and another window).
The user status to be displayed on the client 10 of the other party is transmitted in the form of a status message. The status message can be dynamically conveyed by a system without explicit manual input from a user. That is, the client 10a, 10b can determine content of the status message and can determine whether or not the status message is to be sent to others participating in the communication session. In one embodiment, the status message can be sent to a relevant sub-set of users, which is less than the set of users participating in the communication session. IM status messages can be customized by configuration options (user configurable) established by the user (for whom the status information is generated) and/or can be customized for the receiver of the IM status messages in accordance with configuration options established by the receiver of the IM status messages.
As will be described later, the status message can be generated in accordance with a rule in association with the definitions regarding the IM status information and the window status information. In the present embodiment, the status message is used as an example of the user status information indicating the status of the user. As used herein, the “status of the user” refers to the status related to the user operation on the software activated in the client 10, wherein the software may be either or both of the IM (e.g., the application that a user is utilizing to participate in the communication session with others) and an application activated from the IM (e.g., an application distinct from the instantiated IM application that is running on the client 10a, 10b concurrent with the IM application instance).
One embodiment showing a functional configuration of the client 10 will be described, as indicated by
As shown in the figure, the client 10 includes a communication unit 11, an operation accepting unit 12, a message processing unit 13, a display unit 14, a rule storing unit 15, a window monitoring unit 16, a rule interpreting unit 17, and/or other such components.
The communication unit 11 transmits and receives messages to and from the client 10 of the other party of communication. In the present embodiment, the communication unit 11 is shown as an example of the notification unit which notifies the user status information.
The operation accepting unit 12 accepts a user operation, such as a keyboard operation, mouse operation, and the like, on the client 10.
The message processing unit 13, which is a function implemented as the CPU in the client 10 executes the IM program, performs processing related to messages, such as message exchange with another client 10.
Upon activation of the message processing unit 13, the display unit 14 displays a window for the IM, a message, and others, whereas upon activation of another application from the message processing unit 13, the display unit 14 displays a window for that application.
The rule storing unit 15 stores, for each application which may be activated from the IM, a rule definition in which a definition of a condition regarding the status of the message in the IM (hereinafter, referred to as the “IM status definition”) and a definition of a condition regarding the status of the window for the application (hereinafter, referred to as the “window status definition”) are associated with each other. In the present embodiment, the IM is shown as an example of the first software that is operated by the user for the message exchange, and the application which may be activated from the IM is shown as an example of the second software that is different from the first software. Further, the rule storing unit 15 is shown as an example of the storing unit which stores association information in which the user status information is associated with the second software.
The window monitoring unit 16 and the rule interpreting unit 17 are the functions which are implemented within computer program instructions that are stored in a storage medium, such as a memory of the client 10. The computer program instructions (that may be part of an IM status agent grogram) can be executed by the CPU in the client 10. Units 16 and/or 17 check the IM status information and the window status information at regular intervals, and if the checked result matches a rule included in the rule definitions stored in the rule storing unit 15, units 16 and/or 17 output the status message defined in that rule to the message processing unit 13.
Specifically, the window monitoring unit 16 monitors the windows displayed on the display unit 14 to check the windows the user is working on. A z-stack order maintained by an operating system of the client 10 can be queried by monitoring unit 16, for example, in one contemplated embodiment. This z-stack order can be used to determine not only which windows are currently active in a desktop, but also indicate which window current has focus.
The rule interpreting unit 17 reads the rule definitions from the rule storing unit 15, and determines whether the IM status information and the window status information match the IM status definition and the window status definition, respectively. If they both match, the rule interpreting unit 17 retrieves and passes the status message associated with the IM status definition and the window status definition to the message processing unit 13. In the present embodiment, the rule interpreting unit 17 is shown as an example of the reading unit which reads into a memory the association information in which the user status information is associated with the second software and also as an example of the output unit which outputs the user status information to the first software.
Although the IM status agent is shown separately from the IM in the figure, the IM status agent may be included in the IM software as plug-in software and the like.
The example of the rule definition in the present embodiment is a collection of action rule definitions for the IM status agent (hereinafter, simply referred to as the “action rule definitions”). <Rule> to </Rule> constitute a unit of the action rule definitions, which coincides with a unit of processing executed by the rule interpreting unit 17. The action rule definitions include the following definitions, which are included in the rule definition for the purposes of associating the user activity information with the status messages.
Action rule definitions include a window definition, which is defined as a Window element. The window definition defines information which specifies the window (hereinafter, referred to as the “object window”) on which a user activity indicated by the user activity information that is associated with a status message is performed.
The Window element may define the following attributes, with “*” indicating a mandatory attribute:
Id*: a window ID for identification of the object window, used in the window status definition and others. Here, the Id takes the numerical value other than “0”, because the window ID “0” is applied to the IM window.
LauncherId: a window ID of the window for the application (launcher) that activated another application. In the absence of this definition, the launcher is regarded as arbitrary.
In the figure, the window for “PDF Reader”, which is the application activated from the IM (with the window ID “0”), has a window ID defined as “1”.
Another description as follows is possible, wherein the window for “Web Browser”, which is another application activated from the application that is opening the window with the window ID “1”, has a window ID defined as “2”:
Action rule definitions include a window status definition, which is defined as a WindowState element. The window status definition defines a condition regarding the status of the object window.
The WindowState element may define the following attributes, with definition of either Focus or Visible being mandatory:
Here, the list includes the window IDs separated by commas. If there is “0” in the list, it represents the window for the IM. For the negation symbol, any symbol, “!” for example, may be used.
Defined in the figure is the status in which focus is switched between the window for the IM (with the window ID “0”) and the window for the PDF viewing software “PDF Reader” (with the window ID “1”).
Another description as follows is possible, which defines the status in which the IM window (with the window ID “0”) and the window with the window ID “2” are open, without being minimized to icons, and focus is switched between the windows with the window IDs “1” and “4”:
Action rule definitions include an IM status definition, which is defined as an IMState element. The IM status definition defines the condition related to the status of the IM application.
The IMState element may define the following attributes:
Presence: a numerical value indicating the presence status of the IM. Typical presence statuses may be defined, e.g., as: 0—Active (possible to answer), 1—Away (away from keyboard), 2—Idle (no operation), 3—Inactive (impossible to answer), and others, although the numerical values may vary depending on the types of the IM.
Shown in the figure is the status in which the message is being input to the IM.
Another description as follows is possible, which defines that the presence status of the IM is Idle and the message is being input:
Action rule definitions include an IM status modification definition, which is defined as a Status element. The IM status modification definition defines an IM status to which the status is to be modified in the case where the actual status satisfies the condition defined in the rule definition. In the present embodiment, particularly, it includes the definition of a status modification instruction (to update a status message and the like), which is notified to the IM when the status matches the rule.
The Status element may define the following attributes:
In the figure, it is defined such that the IM status message is changed to “Now Making Comments on the Document” when the status matches the condition defined in the rule definition.
The example of the rule definition shown in
An operation of the present embodiment will now be described. While the rule definition in
Firstly, the message processing unit 13 determines whether a notification that there was a user operation has been received from the operation accepting unit 12 (step 101). It repeats step 101 until such a notification is received, and once it receives the notification, it determines the content of the user operation (step 102).
Assume it is determined that the user operation is the one for activating an application.
In this case, the message processing unit 13 activates the designated application (step 103). It then notifies the rule interpreting unit 17 of activated AP information related to the activated application, for example by storing the information in a memory which is used for storing the activated AP information and which is accessible by the rule interpreting unit 17 (step 104). Here, it is assumed that the message processing unit 13 is able to recognize the type of the activated application, and the application name is included in the activated AP information. Further, the process ID for identification of a process generated as a result of activation of the application is also included in the activated AP information.
Assume it is determined that the user operation is the one for modifying the status of the IM.
In this case, the message processing unit 13 notifies the rule interpreting unit 17 of the IM status information, for example by storing the information in a memory used for storing the IM status information, which can be accessed by the rule interpreting unit 17 (step 105). Here, the IM status information may be the one indicating that a text is being input to the IM.
In the case where it is determined that the content of the user operation is other than described above, processing is performed in accordance with that user operation before termination of the process. The processing based on the user operation is irrelevant to the disclosure, and thus, description thereof will not be provided here.
Window monitoring unit 16 determines whether it is time to check the windows (step 121). If it is not the time, it repeats step 121 until the time comes. If it is the time to check the windows, the window monitoring unit 16 obtains and stores in a memory the process ID of the application that opened the foreground window among the windows displayed on display unit 14 (step 122). To specify the foreground window among the windows displayed on the display unit 14, an API function of GetForegroundWindow, for example, may be used. Thereafter, the window monitoring unit 16 determines whether the process ID for the foreground window has been obtained a predetermined number of times (step 123).
As a result, if the process ID for the foreground window has not been obtained the predetermined number of times yet, steps 121 to 123 are repeated.
If the process ID for the foreground window has been obtained the predetermined number of times, the process IDs obtained in step 122 up to that point are retrieved from the memory (step 124). It then notifies the rule interpreting unit 17 of the obtained process IDs, by storing them in a memory which is used for storing the window status information and accessible by the rule interpreting unit 17 (step 125).
Rule interpreting unit 17 reads the rule definition from the rule storing unit 15 (step 141).
Rule interpreting unit 17 obtains the window status information that the window monitoring unit 16 stored in the memory (step 142). Here, the window status information includes the process IDs of the applications that have opened the windows that the user is currently working on.
Rule interpreting unit 17 also obtains the activated AP information that the message processing unit 13 stored in the memory (step 143). Here, the activated AP information includes the application names and the process IDs.
Rule interpreting unit 17 replaces the process IDs included in the window status information obtained in step 142 with the application names by referring to the activated AP information obtained in step 143, to regenerate the window status information (step 144). Assuming that the IM status agent has acquired the process ID of the IM upon activation thereof, if that process ID is among the process IDs included in the window status information, the rule interpreting unit 17 replaces that process ID with the application name “IM”. Further, if the process ID included in the activated AP information obtained in step 143 is not among the process IDs included in the window status information, the rule interpreting unit 17 replaces that process ID with a blank, for example, to indicate that the windows the user is currently working on include a window that was activated from an application other than the IM.
Further, the rule interpreting unit 17 obtains the IM status information that the message processing unit 13 stored in the memory (step 145).
Rule interpreting unit 17 performs matching between the window status information and the window status definition, and between the IM status information and the IM status definition (step 146). It then determines whether the window status information and the IM status information match the window status definition and the IM status definition, respectively (step 147).
If they both match, the rule interpreting unit 17 transmits an IM status modification instruction to the message processing unit 13, in accordance with the IM status modification definition included in the rule definition read in step 141 (step 148). The IM status modification instruction may be, e.g., an instruction to change the IM status message to the one that is associated with the window status definition and the IM status definition. When the IM status message is transmitted to the message processing unit 13 according to the above operation, the message processing unit 13 passes the status message to the communication unit 11, which in turn transmits it to another client 10.
On the other hand, if either one does not match, the process is terminated, without transmitting the IM status modification instruction to the message processing unit 13.
The information obtained in step 142, obtained in step 143, and generated in step 144 will be described with reference to specific examples, as shown by
It can be assumed, for the example, that focus is switched between two windows, and the process IDs of the applications that opened the respective windows are shown in the form of a table. Of the process IDs, “1222” is the process ID for the IM, and “1234” is the process ID for “PDF Reader”.
It is assumed that “PDF Reader” has been activated, and the correspondence between the process ID “1234” and the application name “PDF Reader” is shown in the form of a table.
Because the IM status agent knows that the process ID “1222” in
The status matching processing in step 146 in
Rule interpreting unit 17 generates association information between the application name and the window ID, according to the window definition which is included in the rule definition read in step 141 in
Rule interpreting unit 17 reads the action rule definition in which the application name included in the activated AP information obtained in step 143 in
Further, the rule interpreting unit 17 retrieves the list of window IDs included in the Focus attribute in the window status definition (step 163). It then specifies the application corresponding to a respective window ID in the list, to generate a list of applications (step 164). If the window ID is “0”, the application is “IM”. If the window ID is other than “0”, the application is specified based on the association information between the application name and the window ID generated in step 161. For example, the rule definition shown in
Rule interpreting unit 17 determines whether the applications included in the list of applications generated in step 164 match the applications included in the window status information generated in step 144 (step 165).
If they match, the rule interpreting unit 17 obtains the value that is set in the Input attribute in the IM status definition (step 166). It then determines whether the status indicated by that value matches the status indicated by the IM status information obtained in step 145 (step 167).
If they match, the rule interpreting unit 17 outputs a notification that they match as well as the IM status modification instruction described in the IM status modification definition (step 168). In the present embodiment, particularly, the instruction to change the IM status message is output.
On the other hand, if the result of matching is “NO” in step 165 or 167, the rule interpreting unit 17 outputs a notification that they do not match to the message processing unit 13 (step 169).
While the negation symbol described in conjunction with the rule definition in
For example, in the case where a negation symbol is added to the list of the window IDs, it may be determined in step 165 whether the condition that the window status information generated in step 144 (e.g., the information shown in
In the case where a negation symbol is added to one or more of the window IDs in the list, it may be determined in step 165 as follows: In the list of applications generated in step 164, for the application having the window ID not added with the negation symbol, it may be determined whether the condition that the application is included in the window status information generated in step 144 (e.g., the information shown in
It is noted that the matching algorithm described above with reference to
An embodiment of the disclosure has been described above in detail. In the present embodiment, in the case where the focus is switched between the window for the IM and the window for the “PDF Reader” and a message is being input to the IM, the status message “Now Making Comments on the Document” is output to indicate that the user is inputting a message to the IM while viewing the document using “PDF Reader”. However, various other situations are conceivable as to what kind of status message is to be output when what kind of condition is satisfied.
For example, it may be configured such that a condition of Focus=” 1″ and Input=“0” is defined in advance and, when the condition is satisfied, a status message indicating that the user is viewing the document using “PDF Reader” before inputting a message to the IM is output.
Further, another situation not taking account of the condition regarding the status of the message in the IM is conceivable.
For example, it may be configured such that a condition of Focus=” 1″ alone is defined in advance and, upon satisfaction of the condition, a status message indicating that the user is doing work using “PDF Reader” for the purpose of message exchange is output.
Alternatively, it may be configured to define a condition of Focus=!“1” (“!” is the negation symbol) alone and, in response to satisfaction of the condition, to output a status message indicating that the user is not doing work using “PDF Reader” for the message exchange.
Still another situation not taking account of the condition regarding the status of the window is conceivable as well.
In this case, the user status information showing the user status may be stored in association with “PDF Reader” in advance and, when “PDF Reader” is activated from the IM, the associated user status information may be output.
Further, it has been assumed in the present embodiment that the data transmitted by the IM is a PDF file and the PDF viewing software is activated from the IM for viewing the PDF file. However, this is only illustrative; the data transmitted by the IM may be of any format and may be viewed using any software.
Furthermore, while it has been assumed in the present embodiment that the user exchanges messages with only one party, in the case where the user chats with a plurality of parties individually, the above-described process may be performed on a respective chat session.
As described above, in the present embodiment, the condition regarding the window status and the condition regarding the message in the IM, and the status message indicating the user status are associated with each other for each of the applications that may be activated from the IM, and in the case where an actual status satisfies the conditions, the status message is output. This provides the other party of communication with the presence information, not of the type such as “on the phone”, “available”, “away”, and the like, but from the standpoint of whether the user is doing work related to the chat using the software activated from the IM.
Further, in most cases, obtaining the user activity information requires only modification of the IM software and use of the function of the window system, without the need of modification of the applications.
A hardware structure of a computer suitable for implementing the present embodiment will be described.
In
While the disclosure has been described with reference to the embodiment, the description of the embodiment above does not restrict the technical scope of the disclosure. Those skilled in the art will appreciate that various modifications and substitutions are possible, without departing from the scope and spirit of the invention.
| Number | Date | Country | Kind |
|---|---|---|---|
| 2008-260325 | Oct 2008 | JP | national |
