JP7425486B2 - Message management system, message management method and program - Google Patents

Description

The present invention relates to a message management system, a message management method, and a program.

2. Description of the Related Art Communication using e-mail, SMS (Short Mail Service), chat, etc. is becoming popular, and communication history between senders and receivers of messages is managed. For example, Patent Document 1 discloses that the personal relationship between the owner of the e-mail destination address and the owner of the sender address and the past sending history are managed and displayed before sending the e-mail. ing.

Unexamined Japanese Patent Publication No. 2015-5210

People may use the same email address but have different roles as speakers in the conversation. For example, when sending an e-mail to someone who is a friend and a sales representative of a business partner, the context is different when sending an e-mail as a friend and when sending an e-mail as a customer, so there is a need for different management. . However, in conventional technologies, such as the system described in Patent Document 1, it is assumed that each sender and receiver of a message such as an e-mail is a single person, and the same e-mail address is used. As described above, it was difficult to manage the parties as different parties.

The present invention was made in view of this background, and an object of the present invention is to provide a message management system, a message management method, and a program that can manage messages according to the roles of senders and receivers.

The main invention of the present invention for solving the above-mentioned problems is a system for managing messages including a sender and a sender, which includes a message input section that accepts the input of the message, and a message input section that receives the input of the message, and assigns the message to the user indicated by the sender. and a destination role that is one of the one or more roles assigned to the user indicated by the destination. The information processing apparatus includes a role designation section and a message storage section that stores the message in association with the transmission source role and the transmission destination role.

Other problems disclosed in the present application and methods for solving the problems will be made clear by the section of the embodiments of the invention and the drawings.

According to the present invention, messages can be managed according to the roles of senders and receivers.

1 is a diagram showing an example of the overall configuration of a message management system according to the present embodiment. 2 is a diagram showing an example of the hardware configuration of a computer used for a user terminal 10 and a message management device 20. FIG. 2 is a diagram showing an example of a software configuration of a message management device 20. FIG. It is a figure showing an example of composition of message DB232. It is a figure showing an example of composition of role DB231. It is a diagram showing an example of the configuration of a thread DB 233. It is a figure showing an example of composition of thread message DB234. It is a figure showing an example of composition of thread status DB235. 3 is a diagram showing an example of a screen 32 displayed by a thread display section 215. FIG. FIG. 3 is a diagram showing the flow of e-mail transmission processing. 3 is a diagram illustrating an example of an input screen 31 for a message input unit 211 to receive a message input. FIG. FIG. 3 is a diagram illustrating the flow of e-mail registration processing. FIG. 7 is a diagram showing the flow of processing for warning about abandoned threads.

A message management system according to an embodiment of the present invention will be described below. The message management system according to this embodiment manages messages transmitted between multiple users. In this embodiment, it is assumed that the message is an e-mail, but any form may be used as long as the message is transmitted between users, such as a chat, a short mail service, or a post on a social network.

The message management system of this embodiment assumes that each user is assigned one or more roles, and manages which role a message is sent and received.

Furthermore, the message management system of this embodiment manages whether a reply has been sent to one role and another role regarding communication between the roles. In other words, the message management system also manages which role has the ball in a game of catch between roles.

FIG. 1 is a diagram showing an example of the overall configuration of a message management system according to this embodiment. The message management system of this embodiment includes a message management device 20. The message management device 20 is connected to the user terminal 10 so as to be able to communicate with each other. The user terminal 10 and the message management device 20 are connected via a communication path such as the Internet or a LAN (Local Area Network).

The user terminal 10 is a computer on which a user reads and writes e-mail. The user terminal 10 is, for example, a smartphone, a tablet computer, a mobile phone terminal, a portable (notebook type) personal computer, a stationary (desktop type) personal computer, or the like. In this embodiment, a so-called web mail format is assumed in which the user terminal 10 accesses the message management device 20 to read and write e-mails. Further, in this embodiment, it is assumed that a user is assigned one or more roles but uses only one e-mail address.

The message management device 20 is a computer that distributes electronic messages and associates e-mails with roles. In this embodiment, the message management device 20 is realized by, for example, one or more personal computers or workstations. The message management device 20 receives input from the user terminal 10 for each item constituting an e-mail (destination, sender, title, body, etc.), constructs an e-mail from the received items, and sends the constructed e-mail to an SMTP (Simple (Mail Transfer Protocol). That is, the message management device 20 has the functions of an MDA (Mail Delivery Agent) that sends received e-mail to a mailbox within the message management device 20, and an MTA (Mail Transfer Agent) that transfers the received e-mail. . Note that as for the communication protocol regarding e-mail, any protocol other than those mentioned above may be used.

FIG. 2 is a diagram showing an example of the hardware configuration of a computer used in the user terminal 10 and the message management device 20. The user terminal 10 and the message management device 20 include a CPU 101, a memory 102, a storage device 103, a communication interface 104, an input device 105, and an output device 106. The storage device 103 stores various data and programs, and is, for example, a hard disk drive, solid state drive, flash memory, or the like. The communication interface 104 is an interface for connecting to the communication network 30, and includes, for example, an adapter for connecting to Ethernet (registered trademark), a modem for connecting to a public telephone line network, and a wireless communication device for performing wireless communication. , a USB (Universal Serial Bus) connector for serial communication, an RS232C connector, etc. The input device 105 is, for example, a keyboard, mouse, touch panel, button, microphone, etc., for inputting data. The output device 106 outputs data, such as a display, printer, or speaker.

FIG. 3 is a diagram showing an example of the software configuration of the message management device 20. As shown in FIG. The message management device 20 includes a message input section 211, a message transmission section 212, a message registration section 213, a role setting section 214, a thread display section 215, an alert output section 216, a role DB 231, a message DB 232, a thread DB 233, a thread message DB 234, and a thread A status DB 235 is provided.

The message input section 211, message transmission section 212, message registration section 213, role setting section 214, thread display section 215, and alert output section 216 are configured so that the CPU 101 of the message management device 20 stores programs stored in the storage device 103. This is realized by reading and executing the program in 102. Furthermore, the role DB 231, message DB 232, thread DB 233, thread message DB 234, and thread status DB 235 are realized as part of the storage area provided by the memory 102 and the storage device 103.

Message input section 211 accepts input of a message to be transmitted. In this embodiment, a message is input into the message input section 211 when receiving the contents of each item of an e-mail from the user interface, and when receiving an e-mail sent from another mail server (MTA). Let's say that. The processing when the message input unit 211 receives an e-mail is the same as the processing when a normal MTA or MDA receives an e-mail.

Message transmitter 212 transmits a message. In this embodiment, the message input section 211 and the message transmission section 212 receive an e-mail (message) sent from the user terminal 10, and the e-mail address specified as the destination (To, Cc) of the received e-mail. Send e-mail to. It is assumed that the e-mail transmission process by the message transmitter 212 employs the e-mail delivery process by a general MTA or MDA.

FIG. 4 is a diagram showing a configuration example of the message DB 232. As shown in FIG. In the example shown in the figure, the message DB 232 is represented in a table format that manages email headers and bodies in association with message IDs. The data may be saved or stored in an mbox format file.

The message registration unit 213 registers the message received by the message input unit 211 in the message DB 232. Processing by the message registration unit 213 is similar to processing by a general MDA. For example, the message registration unit 213 can store the email in the message DB 232 if the destination is addressed to a domain managed by the message management device 20 .

FIG. 5 is a diagram showing a configuration example of the role DB 231. The role DB 231 stores a name (role name) indicating a role assigned to a user using the e-mail address in association with the e-mail address.

The role setting unit 214 sets a role corresponding to the message. The role setting unit 214 sets roles for both the sender and the sender of the message. Further, the role setting unit 214 sets a role for each message registered in the message DB 232 by the message registration unit 213.

For example, the role setting unit 214 displays a message to the user, reads out and presents roles corresponding to the sender and destination addresses from the role DB 231, and accepts designation of one of the presented roles. can do. For example, the role setting unit 214 can estimate and present a role based on the title of the e-mail, words included in the text, and the like. Further, when a reply destination message ID (message ID set in the In-Reply-To header) is set in the e-mail, the role setting unit 214 sets the role corresponding to the message ID, which will be described later. It may be read out from the thread message DB 234 and presented. The role setting unit 214 may search the thread message DB 234 for e-mails with the same combination of e-mail addresses as the destination or Cc, and present the role corresponding to the searched e-mail.

The thread DB 233 stores information related to a series of e-mails (hereinafter referred to as threads) sent and received between roles. FIG. 6 is a diagram showing a configuration example of the thread DB 233. The thread DB 233 associates a parent thread ID indicating the parent thread of the thread with two roles (roll 1, role 2) in association with information for identifying the thread (hereinafter referred to as thread ID). It is attached and memorized. One record of the thread DB 233 is created for each thread transmitted and received between the two roles indicated by roles 1 and 2. The thread indicated by the parent thread ID is the communication from which the thread indicated by the thread ID is derived. For example, if an e-mail thread exists between "Role A" and "Role B", in response to any message included in this thread, "Role A" to "Role C" If an e-mail is sent, it is assumed that a thread between role A and role C is created that is different from the thread between role A and role B. A thread between role A and role C with the thread as a parent thread is created and registered in the thread DB 233.

Thread message DB 234 stores messages included in threads. FIG. 7 is a diagram showing an example of the configuration of the thread message DB 234. The thread message DB 234 stores, in association with the thread ID, a message ID indicating a message, a sender role indicating the role of the sender of the message, a receiver role indicating the role of the receiver of the message, and the sending date and time of the message. are stored in association with each other. In addition to the transmission date and time, various types of header information may be provided as record items in the thread message DB 234.

The thread status DB 235 stores information regarding the status of threads. FIG. 8 is a diagram showing a configuration example of the thread status DB 235. The thread status DB 235 includes, in association with the thread ID, a status indicating the state of the thread, the last sending date and time that is the date and time when the last message was sent, and the final recipient role indicating the role of the recipient of the last message. , and a message ID indicating the last message. That is, the thread status DB 235 manages conversation communication between roles in a thread, and which role has the ball in the conversation.

The thread display section 215 displays a list of messages included in the thread. The thread display unit 215 displays each of the records registered in the thread DB 233, accepts the designation of any thread, reads the record corresponding to the thread ID indicating the accepted thread from the thread message DB 234, and displays the read record. are displayed in a predetermined order (for example, in order of transmission date and time) in association with the sender role and the receiver role.

FIG. 9 is a diagram showing an example of the screen 32 displayed by the thread display section 215. The screen 32 shows messages being exchanged between the role of "Counter of Company A" and the role of "Customer X." The thread display unit 215 displays two roles, and for each record read from the thread message DB 234, displays an arrow 321 pointing from the role indicated by the sender role included in the record to the other role. The thread display section 215 also displays the transmission date and time 322. Furthermore, the thread display unit 215 reads the message corresponding to the message ID from the message DB 232 and displays a part 323 of the text of the read message. Note that the thread display section 215 may extract and display a predetermined number of threads from the beginning of the main text, or may summarize and display the main text. Further, the thread display unit 215 reads the status corresponding to the thread ID indicating the specified thread from the thread status DB 235 and displays the read status in the status display column 324 of the screen 32.

The alert output unit 216 notifies threads that have not been responded to. Details of the processing by the alert output unit 216 will be described later.

The main processes in the message management system of this embodiment will be explained below.

FIG. 10 is a diagram showing the flow of email sending processing. The message input unit 211 displays an input screen 31 as shown in FIG. 11, receives input from the user for each item constituting the e-mail, and creates an e-mail for transmission (S401).

The input screen 31 includes an input field 311 for the e-mail address that will be the destination (To) of the e-mail, an input field 312 for the e-mail address that will be the carbon copy (Cc) of the e-mail, and an e-mail address that will be the sender (From) of the e-mail. , an input field 313 for the email title (Subject), and an input field 315 for the email body. The input fields 311 to 315 are input items that are generally similar to those on the input screen when creating an e-mail.

Returning to FIG. 10, the role setting unit 214 reads out the roles corresponding to the user's email address from the role DB 231 and displays the list as a list (S402). In the example of FIG. 11, the settings field 316 for the role of the destination user is displayed in the form of a drop-down list. The role setting unit 214 accepts the designation of which role the user will use to send the email (S403). That is, the role setting unit 214 sets the role selected in the setting field 316 of the screen 31 as the source role (S403).

In the input screen 31, when an e-mail address is entered in the input fields 311 and 312, the role setting unit 214 reads the role corresponding to the e-mail address entered in the input field 311 from the role DB 231, and fills the setting field in FIG. 316 (S404).
It includes a setting field 317 for the role of the user to carbon copy, a setting field 318 for the role of the user who is the sender, and a setting field 319 for the state of the thread after transmission. The message input unit 211 accepts the designation of which role of the other party the designated mail is to be sent to (S405). That is, the message input unit 211 sets the role selected in the setting field 317 or 318 of the screen 31 as the destination role (S405).

The message input unit 211 inputs the source role and destination role of the e-mail created in step S401 in the format of "X-From-Role: source role" and "X-To-Role: destination role". It is included in the header part (S406). The message transmitter 212 transmits the e-mail created as described above (S407). Next, the e-mail registration process shown in FIG. 12 is performed (S408).

The message registration unit 213 registers the e-mail in the message DB 232 (S421), and searches the thread DB 233 for the thread ID corresponding to the combination of the sender role and the destination role (S422). That is, the message registration unit 213 determines whether the sender role matches role 1 and the destination role matches role 2, or whether the sender role matches role 2 and the destination role matches role 1. A thread ID that satisfies any of the conditions is searched from the thread DB 233.

If there is no thread ID (S423: None), the message registration unit 213 newly registers a record in which the source role and destination role are set to role 1 and role 2 in the thread DB 233 (S424).

The message registration unit 213 registers the message ID, sender role, recipient role, and sending date and time of the sent email in the thread message DB 234 in association with the thread ID (S425). Next, the message registration unit 213 registers the sending date and time, sender role, and message ID of the already sent email in the thread status DB 235 along with the status input in the input field 319 in FIG. 11 in association with the thread ID. (S426).

The e-mail created on the input screen 31 as described above is registered in the database with the sender role and the destination role associated with it. Note that when the message input section 211 receives an e-mail, the received e-mail is displayed in an uneditable manner on the input screen 31 of FIG. 11, except for the role setting fields 316 to 318 and the status input field 319. shall be taken as a thing. The role setting unit 214 receives the designation of the transmission source role and the transmission destination role, and executes S406 of FIG. 10 and the processing of FIG. 12.

FIG. 13 is a diagram showing the flow of processing for warning about abandoned threads. The alert output unit 216 reads from the thread DB 233 the thread ID in which role 1 or role 2 is the role assigned to the currently logged in user (S441), and reads the record corresponding to the read thread ID from the thread status DB 235. Reading (S442), the following processing is performed for each read record.

The alert output unit 216 determines that the final recipient role is its own role (S443: YES), and that the time from the last sending date and time to the current date and time is a predetermined time (for example, any time such as 24 hours or 72 hours can be set). ) (S444: YES), the message indicated by the message ID is read from the message DB 232 and output together with the last transmission date and time and the last recipient role (S445). Note that the alert output unit 216 may output the above information on the screen or may send it by e-mail.

In this way, the alert output unit 216 can notify the user of threads in which the conversation has not ended and a predetermined period of time has elapsed without a message being sent from the role assigned to the user. This makes it easy to notice emails that you have forgotten to reply to.

As explained above, according to the message management system of this embodiment, the role of the sender and the role of the receiver related to e-mail are managed. Therefore, using a tool called e-mail for exchanging messages between individuals, it is possible to manage conversations between groups called roles assigned to multiple people. For example, it is possible to know what kind of messages the "Sales Department of Company A" has sent and what messages the "Sales Department of Company A" has received. Therefore, communication history can be easily grasped.

Additionally, in general mailing lists, bulletin boards, collaboration tools, etc., multiple users can post comments on a single topic, allowing multiple people to communicate, but in the end only individuals can send and receive messages. However, according to the message management system of this embodiment, many-to-many communication can be managed using e-mail. Therefore, even though the communication involves many users, the history can be understood as simplified communication between roles. Therefore, it is possible to avoid losing the flow of the conversation.

In addition, most e-mails are sent and received by individual users, but even if the same user is the contact point of the company, it may be sent to a customer, or a member of one department may send it to another department. The thread of communication differs depending on the situation. The message management system of this embodiment manages which role of the sender and to which role of the receiver each message is sent. This makes it possible to manage whether or not there is any breakdown in communication between roles.

Further, according to the message management system of this embodiment, the current state of communication between roles and the last received role are stored. Therefore, it is possible to know which role has the ball of conversation. Furthermore, when a message is sent to a certain role but no reply is received, each user to whom that role is assigned is notified of this fact. Therefore, for example, if role A is assigned to person X and person Y, and person Z in another role B sends an email to person X, but person X does not reply, Mr. Y, who is assigned the same role A as Mr. X, can easily understand that Mr. In other words, it is possible to easily determine whether or not there is a breakdown in communication. Therefore, smooth communication is promoted.

Although the present embodiment has been described above, the above embodiment is for facilitating understanding of the present invention, and is not for construing the present invention in a limited manner. The present invention may be modified and improved without departing from its spirit, and the present invention also includes equivalents thereof.

For example, in the present embodiment, the user terminal 10 accesses the message management device 20 and performs all operations such as sending and receiving e-mails on the message management device 20, but the present invention is not limited to this. may be determined and managed.

Further, in this embodiment, it is assumed that the user uses only one e-mail address, but the present invention is not limited to this, and can be applied to a case where the user uses a plurality of e-mail addresses.

In addition, the email addresses of all users assigned the same role are stored in association with the role, and if multiple email addresses are set in To or Cc, the corresponding email address is Roles included in multiple email addresses may be estimated as destination roles, and the estimated roles may be presented.

10 User terminal 20 Message management device 211 Message input section 212 Message transmission section 213 Message registration section 214 Role setting section 215 Thread display section 216 Alert output section 231 Role DB
232 Message DB
233 Thread DB
234 Thread message DB

Claims (2)

A system for managing messages communicated between users having multiple roles, the system comprising:
a thread database that stores the message in association with a transmission source, a first role corresponding to the transmission source, a transmission destination, and a second role corresponding to the transmission destination;
Depending on the text contained in the message, first and second roles corresponding to the users of the source and destination are estimated, and the message is threaded for each pair of the first and second roles. a role setting unit that registers in the thread database as
By reading the messages corresponding to the specific thread from the thread database, the messages corresponding to the pair of the first and second roles , at least one of which is held by a plurality of the users, are read and displayed in a predetermined order. a thread display section to
to have
A message management system featuring: The message management system according to claim 1,
the role setting unit reads and presents the first and second roles corresponding to the transmission source and the transmission destination;
A message management system featuring:

Images