JP2014085962A - Community system, community server, control method of community system and program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To collect opinions with respect to a message to be an opinion posted to a net community (a bulletin board) while clarifying declaration of intention such as approval from another user, without considering a strict path such as a workflow.SOLUTION: When a message and an approver to be a user of a net community requesting approval of the message are associated with each other to be applied as a consensus building content to the net community, the message is posted as a normal message, and in order to manage the approver and an approval condition, the message, the approver and the approval condition are stored into message storage means.

Description

  The present invention relates to a technique for forming an agreement (simple workflow) in which a message applied by a user using an online community (electronic bulletin board) is agreed with other users.

  Conventionally, a network community (electronic bulletin board) has been used for exchanging opinions and finally agreeing opinions on a network. However, the net community does not have “approval” or “denial” in a strict sense like a workflow, but it is an exchange of opinions freely. In other words, the author of a theme of a certain theme, a user who wants to collect opinions of other people to make his / her judgment, and a confirmation content that he wants to approve. I (or someone of the user) had to decide the conclusion.

  Conventionally, a workflow system has been used to process approval of some processing in an organization such as a company. However, it was necessary to precisely define the route such as the circulation destination and approval destination of the workflow and the activities such as each circulation destination and the person (user) of the approval destination and authority in the route when introducing the workflow system. .

  Therefore, the workload of developers to introduce the workflow system is high, and users who use the introduced workflow system also follow the definition at the time of introduction, and flexible route editing (for example, circulation destination, approval destination ( Activity) was difficult to add, skip, or change.

  In Patent Document 1, the developer defines only a basic route and each activity in the route, and when the user uses it, a person other than the “next person in charge” of the basic route by “selection item”. A workflow system that can be used as a circulation destination and an approval destination has been proposed.

The selection item includes, for example, a “skip process” in which the next person in charge is skipped and an approval request is sent to the next person in charge.
However, even in the workflow system in Patent Document 1, the developer needs to define the basic route and the activities that appear on the route. Furthermore, each item in the “selected item” that can be used by the user without following the path defined by the developer needs to be incorporated in the workflow system in advance.

Japanese Patent Laid-Open No. 10-177608

  As mentioned above, in order to form a consensus, in the case of the net community, the final conclusion must be made by the user himself, and in the case of a workflow, the user goes through a fixed “path”. And had to get strict approval.

  In view of the above problems, the present invention displays a message indicating an opinion posted to the Internet community (electronic bulletin board) without being bound by a strict route such as a workflow, and displaying an intention such as approval by another user. The purpose is to provide a mechanism that can collect opinions in a clear manner.

  The present invention is a community system in which a client terminal and a community server that manages a message posted to the net community can be connected via a network, and the client terminal approves the message and the message. Corresponding approver who is a user of the network community to request, consensus formation content application accepting means for accepting as consensus formation content, and notifying the consensus formation content accepted by the consensus formation content application accepting means to the community server Consensus formation content notifying means, and the community server stores in the message storage means the posted message and information about the approver when the message is the message in the consensus formation content. Message registration A consensus formation content receiving means for receiving the consensus formation content notified from the client terminal; a message extracting means for extracting the message in the consensus formation content from the consensus formation content; and the message storing the message Posting means for posting to the means.

  According to the present invention, a message that is an opinion posted to the Internet community (electronic bulletin board) is not restricted by a strict route such as a workflow, and the intention display such as approval by other users is clarified. It is possible to provide a mechanism that can collect opinions.

It is a figure which shows an example of the system configuration | structure concerning embodiment of this invention. It is a block diagram which shows an example of the hardware constitutions of the community server concerning embodiment of this invention. It is a figure which shows an example of the software structure of the community server concerning embodiment of this invention. It is a figure which shows an example of GUI (graphical user interface) which displays the list of the forum and message in the community concerning embodiment of this invention. It is a figure which shows an example of the data structure of the forum and message concerning embodiment of this invention. It is a figure which shows an example of GUI which posts the sub message with respect to the posted message concerning embodiment of this invention. It is a figure which shows an example of the state transition to which a message is added according to contribution in the message list concerning embodiment of this invention. It is a figure which shows an example of GUI which posts the comment with respect to the posted message concerning embodiment of this invention. It is a figure which shows an example of GUI which posts the sub comment with respect to the posted comment concerning embodiment of this invention. It is a figure which shows an example of GUI which displays the list of the message, comment, and subcomment concerning embodiment of this invention. It is a flowchart which shows an example of the posting process from the mail concerning embodiment of this invention. It ’s It is a flowchart which shows an example of the posting process from the SNS user interface concerning embodiment of this invention. It is a figure which shows an example of GUI for applying the message of consensus formation concerning embodiment of this invention. It is a figure which shows an example of GUI which displays the message in the forum of the approver who approves the consensus formation message concerning embodiment of this invention. It is a figure which shows an example of GUI for demonstrating the transition of the approval process in the consensus formation message concerning embodiment of this invention. It is a figure which shows an example of the data structure of the message memory | storage part corresponding to the consensus formation message concerning embodiment of this invention. It is a figure which shows an example of the GUI explaining the approval result of the consensus formation message concerning embodiment of this invention, and contribution of a subcomment. It is a flowchart which shows an example of the application process of the consensus formation message concerning embodiment of this invention. It is a flowchart which shows an example of the approval process of the consensus formation message concerning embodiment of this invention.

  Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings.

<First embodiment for explaining basic operation of community system>
FIG. 1 is a diagram illustrating an example of a system configuration according to an embodiment of the present invention.

  In the system configuration in the embodiment of the present invention, the community server 101 is connected via a client terminal 102 (for example, an in-house SNS (social network system) client, an outside mail client), a mail server 103, a web mail server 104, and a network 105. It is connected. In FIG. 1, the SNS client is illustrated as being in-house and the mail client is illustrated as outside, but the user authority of the community is given to the net community (electronic bulletin board, SNS, etc.) to the last, or posting from the SNS client or mail It indicates whether the client posts or not, and does not limit these configurations. In the following, an online community may be abbreviated as a community.

  The community server 101 receives posts from the client terminal 102 and displays them in the community. Further, the information processing apparatus transmits a post as a mail to the client terminal 102 which is a mail client according to a condition.

  The client terminal 102 is an information processing apparatus that allows a user to use an SNS user interface or mail software and posts to the community server 101. Moreover, in the client terminal 102 which is an SNS client, the user can browse a community forum, a message, etc. according to each user's authority.

  The mail server 103 receives mail and mail transmission / reception instructions from the community server 101 or the web mail server 104, transmits mail according to the instructions, or passes received mail to each server.

  Next, the Web mail server 104 will be described. The mail system configured based on the Web mail server 104 in the present invention refers to an electronic mail system that can be used by the Web browser of the client terminal 102. Browsing received mail and creating / sending new messages can be performed only by a Web browser. Unlike e-mail systems that install e-mail software on the client terminal 102 to manage e-mail transmission / reception, all e-mail transmission / reception is managed on the server side, so users can create e-mails anywhere using a web browser , Receiving and browsing.

  In the embodiment of this system, either the mail server 103 or the Web mail server 104 may be used. Further, the Web mail server 104 may use the mail server 103 as a configuration, and may make it possible for the client terminal 102 to use the mail server 103 from a Web browser. In the above description, the Web terminal is accessed from the client terminal 102 using the Web browser. However, the embodiment of the present invention includes a configuration in which communication is performed from the community server 101 using the HTTP protocol.

  The embodiment of the present invention includes a case where mail is transmitted / received from the community server 101 using the mail server 103 or the API (application programming interface) of the web mail server 104.

  Further, any or all of the community server 101, the mail server 103, and the web mail server 104 may be the same casing. The configuration in FIG. 1 is an example, and various configurations are possible.

  FIG. 2 is a block diagram showing an example of a hardware configuration of the community server 101 according to the embodiment of the present invention. The present invention can also be applied to other information processing apparatuses, that is, the client terminal 102, the mail server 103, and the Web mail server 104.

  As shown in FIG. 2, the community server 101 includes a CPU (Central Processing Unit) 201, a RAM (Random Access Memory) 203, a ROM (Read Only Memory) 202, an input controller 205, a video controller 206, a system bus 204, and the like. A configuration in which a memory controller 207, a communication I / F controller 208, and the like are connected is adopted.

  The CPU 201 comprehensively controls each device and controller connected to the system bus 204.

  Further, the ROM 202 or the external memory 211 will be described later, which is necessary for realizing the functions executed by each server or each PC, such as BIOS (Basic Input / Output System) and OS (Operating System) which are control programs of the CPU 201. Various programs are stored. Further, information necessary for carrying out the present invention is stored. The external memory may be a database.

  The RAM 203 functions as a main memory, work area, and the like for the CPU 201. The CPU 201 implements various operations by loading a program or the like necessary for executing the processing from the ROM 202 or the external memory 211 to the RAM 203 and executing the loaded program.

  The input controller 205 controls input from a keyboard (KB) 209 or a pointing device such as a mouse (not shown).

  The video controller 206 controls display on a display device such as the display 210. The display device may be a display device such as a liquid crystal display. These are used by the administrator as needed.

  The memory controller 207 is an external storage device (hard disk (HD)), flexible disk (FD), or PCMCIA (Personal Computer) that stores a boot program, various applications, font data, user files, editing files, various data, and the like. Controls access to an external memory 211 such as a Compact Flash (registered trademark) memory connected to a Memory Card International Association (Card Memory) card slot via an adapter.

  The communication I / F controller 208 connects and communicates with an external device via the network 105, and executes communication control processing on the network. For example, communication using TCP / IP (Transmission Control Protocol / Internet Protocol) is possible.

  The CPU 201 can display on the display 210 by executing an outline font rasterization process on a display information area in the RAM 203, for example. Further, the CPU 201 enables a user instruction using a mouse cursor (not shown) on the display 210.

  Various programs to be described later for realizing the present invention are recorded in the external memory 211 and executed by the CPU 201 by being loaded into the RAM 203 as necessary. Furthermore, definition files and various information tables used when executing the program are also stored in the external memory 211, and a detailed description thereof will be described later.

  FIG. 3 is a diagram showing an example of the software configuration of the community server according to the embodiment of the present invention. The community server 101 includes a forum registration unit 301, a mail reception unit 302, an SNS message reception unit 303, an ID assignment determination unit 304, an ID determination unit 305, a posting unit 306, a mail transmission unit 307, a forum storage unit 308, and a message storage unit 309. The message registration unit 310 is provided.

  The forum registration unit 301 is created by an administrative user or a general user who has the authority to create a forum in the community server 101, and registers it in the forum storage unit 308.

  The mail reception unit 302 receives post data from a mail (message, sub message, comment, sub comment, etc. described later).

  The SNS message accepting unit 303 accepts post data from the SNS user interface.

  The ID assignment determination unit 304 determines whether or not an ID for specifying the second post data is assigned to a designated position such as a header of the first post data. When the ID for identifying the second posting data is given, the first posting data is not a new posting (the one directly under the forum), but specifies the second posting data specified by the ID Then, it is shown that the post was made as a subordinate post. If no ID is given, it indicates a new post.

  If there is an ID, the ID determination unit 305 determines whether the ID already exists in the forum where the ID is posted. Otherwise it is an error. In particular, since posting from e-mail is not a community user, it is possible to assign an ID to a designated position such as a header of post data by mistake or illegally. It is also possible to prevent posts having these IDs. In the embodiment of the present invention, an example of determining whether an ID already exists in the forum where the ID has been posted has been described. However, the ID may be managed and determined as the entire community.

  The posting unit 306 posts the posting data received by the mail receiving unit 302 or the SNS message receiving unit 303 to a forum designated by the community. Post data is stored in the message storage unit 309. The designation of the forum will be described later.

  When the first posting data is posted from an email, the email transmission unit 307 designates the first posting data and posts the second data, and sends an email to the first posting data. To be sent. Details such as obtaining an email address will be described later.

  The forum storage unit 308 stores information related to forums in the community registered by the forum registration unit. Details will be described later.

  The message storage unit 309 stores the posted data in association with the forum. Details will be described later. Specifically, it is registered by the message registration unit 310.

  FIG. 4 is a diagram showing an example of a GUI (Graphical User Interface) that displays a list of forums and messages in the community according to the embodiment of the present invention. 4 of FIG. 4 illustrates an example of the SNS user interface used for the SNS user in the client terminal 102 (SNS client).

  In 401, a list of forums that can be used in the community is displayed based on the forum storage unit 308. Although not shown, for example, in the user information storage unit, it is possible to set the user's access authority for each forum. When a specific SNS user uses the SNS user interface, only those having access authority You may make it display. Also, with regard to the access authority, the display form (color, icon shape), etc. may be changed depending on, for example, when the user has the viewing authority or the authority to post.

  In 402, the name of the currently focused forum is displayed. For example, it is possible to display the screen 403 by, for example, clicking the forum that the user wants to browse from the list of forums 401 with the mouse. In the example of FIG. 4, “Company A project” (forum name for sharing and supporting information on development projects ordered from Company A) is displayed. In the above-described forum registration unit 301, for example, access authority may be given only to the persons related to the “Company A project”. In addition, it is conceivable to give access authority to managers and project management departments. In addition, a 404 (new posting from SNS) button to be described later is displayed.

  In 403, posted messages are displayed as a hierarchical structure (tree structure). In the hierarchical structure, a message is directly linked to a forum (root message). There can be multiple root messages. In FIG. 4 403, two messages, message A and message B, are the root messages. The root message is implemented, for example, by creating a message to be posted by clicking a new posting button 404 with a mouse and displaying a message input screen (not shown). In addition, when posting a sub-message (that is, when a first message to be posted is to be posted), there is a case in which it is desired to post a sub-message. For example, the message A1, the message A2, or the message A21, the message A22 under the message A2 below the message A in FIG. In this case, a GUI for creating a message is displayed by, for example, right-clicking the second message (the message one level higher) with the mouse, and after posting, the GUI is displayed one level lower than the second message. To be placed.

  Even if the message A and the message B are information related to the same “Company A project”, the message group is divided into different hierarchical structures in order to handle different topics. This one message group may be referred to as a “thread”. The thread having the message A as a root has a message A1 and a message A2 as subordinate messages (submessages) in order to state opinions, confirmations, and thanks for the message A. In 403, the message A is displayed one level below (displayed indented on the right side).

  In FIG. 4 of the first embodiment, the hierarchical structure of messages can be created without limitation, but the number of hierarchies may be fixed as a community system. In addition, the administrator may be able to set the number of levels. In this case, for example, the forum registration unit 301 may be set for each forum, or an administrator GUI (not shown) may be able to set a uniform number of hierarchies for the entire system. If it can be set, the operation method can be changed depending on the purpose, for example, whether it is mainly used with a personal computer in the company or mainly used with a portable terminal having a small screen outside the company.

  Reference numerals 405 to 407 denote application start buttons for use in cooperation with applications other than the community or for other purposes using the community system.

  For example, a button 405 is used to form a new message for consensus building (simple workflow). 406 makes a conference room reservation in the electronic conference system. In step 407, a reserved conference room is entered (participation in the conference).

  Reference numeral 408 denotes an icon for indicating to the user that a mail has been accepted when a post from the mail is accepted. For example, it is realized by changing the display form such as simple animation such as blinking and rotation.

  Reference numeral 410 denotes an example of a screen on which a user displays a message when the posting of the message by mail is accepted. This community server 101 is operated by “C Development Co., Ltd.”, and the screen 410 is posted by “Mr. Nishimoto” of “Company A” by email. In order to post by e-mail, it is necessary to know the e-mail address set in the “Company A Project” forum of the community described later. That is, the company A / Nishimoto is notified in advance of the e-mail address.

  As an example of operation, for example, a user who uses a mail client is a customer outside the company, and a user who uses an SNS user interface is a person in charge such as a department in charge of C Development Co., Ltd. or a project in charge. As will be described later, the person in charge can post a message while selecting whether or not to mail the customer. That is, in response to a customer request / question, first, an answer to the effect that the request / question has been accepted is sent by e-mail, and then a meeting is held between the persons in charge within the company. It is possible to respond such as giving a final answer. Of course, intermediate answers can be made at any time during that time.

By these methods, the person in charge within the company can receive and answer customer requests / questions using only the SNS user interface. In addition, it is possible to obtain an effect that it is possible to send only necessary messages to the customer by email instead of all in-house meetings.
This completes the description of the GUI of FIG.

  FIG. 5 is a diagram illustrating an example of a data structure of a forum and a message according to the embodiment of the present invention. Data managed by the community is stored in the forum storage unit 308 (detailed using 500 in FIG. 5) and the message storage unit 309 (detailed using 510 in FIG. 5).

  The forum storage unit 308 includes data items such as a forum name 501 and a forum mail address 502.

  The forum name 501 is a data item in which the name of the forum displayed in the forum list 401 of FIG. 4 is registered.

  The forum email address 502 is a data item that describes an email address used when posting to the forum by email. This e-mail address can be designated by an authorized user (such as an administrative user) when the corresponding forum information is registered by the forum registration unit.

  The message storage unit 309 includes data items such as a forum name 511, ID 512, posting time 513, upper ID 514, mail address 515, contents 516, and the like.

  The forum name 511 is a data item that identifies which forum the message information is for.

  The ID 512 is a data item that describes an ID that uniquely identifies the message. By using it together with a higher-order ID 514 described later, it is possible to trace the message of the route. As a result, it is possible to determine the hierarchical structure (tree structure) of one thread. Also, as will be described later, when a post is made by mail, if there is an ID at a designated position such as the header of the mail and the ID already exists in the forum corresponding to the mail address, post to that thread. Identified as a message. It is assumed that a post from the mail client and a post from the SNS client are posted to a position one level lower as a sub-message having an ID at a specified position such as a header of the message. However, the present invention is not limited to such a configuration. For example, for a posting from a mail client, it is possible to implement a community system such that the ID is traced to the upper level and posted to the position one level lower than the root message. In addition, it may be possible to specify which message is to be posted below by specifying the user in the posted message (such as specifying some symbol in the mail title).

  The posting time 513 is a data item for describing the time when the message was posted.

  The upper ID 514 is a data item that describes the ID of an upper message when the message is posted as a sub message of another message (one higher in the hierarchical structure).

  The mail address 515 is a data item that describes the mail address of the transmission source when the message is posted from the mail client.

  Content 516 is the content of the posted message. It is a data item in which “Subject: Product Inquiry C Development Co., Ltd./Tamaoki-Thank you in advance” in 410 of FIG. Alternatively, the subject may be a separate data item. The third and subsequent lines of the content 516 (character string enclosed in <>) describe the position of each message in the hierarchical structure, not the actual content.

  Note that 500 in FIG. 5 corresponds to the forum list 400 in FIG. 4 and 510 in FIG. 5 corresponds to the message list 403 in FIG. 4 as an example in which forum data and posted message data are registered. doing.

  This completes the description of FIG. The above-described data configuration is merely an example, and other data items may be included. For example, the forum storage unit 308 may describe a link to an icon image file indicating a forum. In addition, a different configuration may be used.

  FIG. 6 is a diagram illustrating an example of a GUI for posting a sub message corresponding to a posted message according to the embodiment of the present invention. In the example of FIG. 6, the GUI is for posting a sub message to “Message A” posted in the “Company A Project” forum of FIG. 4. As described above, for example, when the message A is right-clicked with the mouse, the GUI of FIG. 6 is displayed.

  6 is the same as 410 in FIG. That is, the content of message A is displayed as it is. On the lower side 601, there are a field for inputting a sub message (602), a button for posting a message (603), a button for posting a message, and a button (604) for sending the contents by e-mail. Is displayed. The SNS user inputs a message in the input field 602.

  When the button 603 is pressed (when a message is specified to be posted), the “Message A1” posting process in the message list 403 in FIG. 4 is performed.

  When the button 604 is pressed (when both message posting and mail transmission are designated), mail transmission processing is performed simultaneously with the posting of “message A1” in the message list 403 in FIG. The details will be described.

The address used for sending the e-mail at the time of posting is searched for the e-mail address corresponding to the message specified when posting the message (which becomes a message one level higher when the posting is completed). That is, in the above example, in order to post a sub-message of message A, the mail address corresponding to message A (515 in FIG. 5) is used for transmission. If there is no corresponding mail address, the transmission process is stopped.
This completes the description of FIG.

<Second Embodiment Explaining Basic Operation of Community System>
The second embodiment will be described with reference to FIGS. The first embodiment and the second embodiment are basically processed in the same flow. However, in the second embodiment, the hierarchical structure of messages is limited to three layers. The root message is simply referred to as “message”, the root message (message) sub-message is referred to as “comment”, and the comment sub-message is referred to as “sub-comment”.

  As described in FIG. 4 as an operation example, a message (route message) can be posted from an SNS client corresponding to the forum or by a mail user who knows a mail address using the mail client. That is, firstly, information sharing such as a meeting can be performed for each topic among in-house personnel (SNS client users). In this case, since there is no e-mail address (customer e-mail address) corresponding to the thread (a message, a comment below it, and sub-comments), no e-mail is sent. Furthermore, when a message is sent from a customer's mail client, there is a case where a mail is sent or not sent when a message is posted because there is a corresponding mail address.

  The difference from the first embodiment is that whether or not to send an email to a customer is changed depending on whether a comment is posted or a sub comment is posted. Thus, unlike the first embodiment, it is possible to fix whether the person in charge sends an e-mail according to the hierarchy to be posted, and to obtain an effect of preventing an in-house consultation from being e-mailed by mistake. Is possible. Details will be described below.

  FIG. 7 is a diagram illustrating an example of state transition in which a message is added according to a posting in the message list according to the embodiment of the present invention. FIG. 7 shows a state in which the message A (702) is posted (701), a state in which the comment A1 (704) is posted to the message A (702) (702), and a sub for the comment A1 (704) in the SNS user interface. A state (705) in which the comment A11 (706) has been posted is illustrated.

  FIG. 8 is a diagram showing an example of a GUI for posting a comment on a posted message according to the embodiment of the present invention. In the first embodiment, as described with reference to FIG. 6, in the first embodiment, after creating a sub-message, whether to post the message to the community or to send an email together with the posting, Was specified by the contributor using a button. In the second embodiment, it is as follows.

  When posting a comment is used for a message, the GUI is as shown in FIG. The upper side is the same as 410 in FIGS. That is, the content of message A is displayed as it is. A column (802) for inputting a comment and a button (803) for posting the comment and transmitting the contents by e-mail are displayed in the lower part 801. The SNS user inputs a message in the input field 802. If message A is posted from an email, comments are posted and emails are sent as described above, but if message A is posted from an SNS user interface, email No transmission is done (no corresponding email address). In that case, instead of the “Comment & Email” button 803, a “Comment” button similar to 904 in FIG. 9 to be described later is displayed, and it is easy to present to the poster that only posting is possible. Good.

  FIG. 9 is a diagram showing an example of a GUI for posting a sub comment for a posted comment according to the embodiment of the present invention. As explained in the previous operation example, the sub-comment is a post of a message that is one level lower than the comment, and because it is an internal meeting, email transmission is not performed (for example, an email address corresponds to the message) But do n’t send).

  901 on the upper side of FIG. 9 is a subcomment in which posting and transmission to the customer are performed (the same content as 803 in FIG. 8). On the other hand, on the lower side 902, there are a sub-comment input field (903) and a button (904) for posting the input sub-comment.

  FIG. 10 is a diagram showing an example of a GUI that displays a list of messages, comments, and subcomments according to the embodiment of the present invention. As in the above-described example, there is a post by a mail from a customer (message A (1001) and a response to it (comment A1 (1002): post and mail transmission). Further, an internal subcomment for the comment A1 (1003 to 1004).

  In the comment A2, the user's post is displayed as a comment of the message A. Since the person in charge of posting the comment A1 has selected the message A (there is no comment A1 at this point), the ID of the message A is assigned to the header and sent to the customer by mail. Since the ID is also given to the header of the mail from the customer as the reply, it is posted as a comment which is a sub-message of message A. Thereby, it is possible to prevent the comment A2 that is a reply mail from the customer from being mixed into the sub-comment of the comment A1 (meeting of countermeasures in the company).

  On the contrary, since it is a reply to the comment A1 (email from the person in charge to the customer) as the content, if it is easier to make a subcomment of the comment A1, add the ID of the comment A1 just posted to the header Just reply to the customer.

  Although not shown, it may be possible to instruct when posting a comment on the SNS user interface so that the contributor selects whether to use the comment of the message A or the subcomment of the comment A1.

  Finally, a countermeasure for the message A is determined between the persons in charge within the company, and the comment A3 (1006) is a state in which the posting to the message A and the mail transmission to the customer are performed.

  The description of the second embodiment that differs from the first embodiment has been given above with reference to FIGS. Next, the process in a community server is demonstrated using the flowchart of FIG. 11, FIG. Since the processing is basically the same between the first embodiment and the second embodiment, the same flowchart is used, but the following two points are different. The first point is whether or not posting to the third layer (or subcomment) is possible in the SNS user interface. The second point is whether or not to check up to the first layer if the e-mail address is not set to the comment (second layer) when the subcomment (third layer) is posted. The difference between these two points is not particularly described in the description of the flowchart.

  FIG. 11 is a flowchart showing an example of mail posting processing according to the embodiment of the present invention. Each step in FIG. 11 is executed by the CPU 201 of the community server 101.

In S1101, it is checked whether or not an instruction to end the community processing in the community server has been issued. If there is no end command (NO), the process proceeds to S1102. If there is an end instruction (YES), the process ends.
In S1102, the reception of the mail is confirmed.

  In S1103, it is determined whether or not a mail is received in the confirmation in S1102. If mail has been received (YES), the process proceeds to S1104. If not (NO), the process proceeds to S1101.

  In S1104, it is analyzed whether an ID of the format specified in the embodiment of the present invention is assigned to a predetermined position (for example, a position corresponding to the sender name in the header) of the received mail data.

  In step S1105, it is determined whether an ID is included. If not included (NO), the process proceeds to S1106. If it is included (YES), the process proceeds to S1108.

  In S1106, a message posted as mail data is regarded as a root message. That is, an ID is issued as a new message rather than a message that is a subordinate of another message (ID issuing unit).

  In S1107, the message posted as mail data is posted as a root message in association with the sender mail address and the ID issued in S1106.

  In S1108, it is determined whether the ID is already existing in the forum. If it is not an existing ID (NO), the process proceeds to S1109. If it is an existing ID (YES), the process proceeds to S1110.

  In step S1109, a post from a mail with a message with an ID that does not exist is regarded as an error, and a notification to that effect is sent to the mail sender.

In S1110, the mail data is posted as a sub-message of the message corresponding to the ID. In this case, an ID corresponding to this message is newly issued (ID issuing unit).
Thus, the description of the flowchart of FIG. 11 is completed.

  FIG. 12 is a flowchart illustrating an example of posting processing from the SNS user interface according to the embodiment of the present invention. Each step in FIG. 12 is executed by the CPU 201 of the community server 101.

  In S1201, it is checked whether or not an instruction to end the community processing in the community server has been issued. If there is no end command (NO), the process proceeds to S1202. If there is an end instruction (YES), the process ends.

  In S1202, the presence / absence of posting a message from the SNS user interface is confirmed.

  In S1203, it is determined whether there is a post in the confirmation in S1202. If there is a post (YES), the process proceeds to S1204. If not (NO), the process proceeds to S1201.

  In S1204, it is analyzed whether or not an ID of the format specified in the embodiment of the present invention is assigned to a predetermined position (for example, a tag position specified in the header) of the posted message.

  In step S1205, it is determined whether an ID is included. If not included (NO), the process proceeds to S1206. If it is included (YES), the process proceeds to S1208.

  In S1206, the posted message is regarded as a root message. That is, an ID is issued as a new message rather than a message that is a subordinate of another message (ID issuing unit).

  In S1207, the posted message is posted as a root message in association with the ID issued in S1206.

  In S1208, the message is posted as a sub-message of the message corresponding to the ID. In this case, an ID corresponding to this message is newly issued (ID issuing unit).

  In step S1209, it is determined whether or not this message is designated to be transmitted by mail (mail transmission designation determination unit). The above operation example corresponds to the case where an email is sent from the person in charge to the customer. If it is designated to transmit (YES), the process proceeds to S1210. If it is not designated to transmit (NO), the process proceeds to S1201. A specific description of whether or not to transmit will depend on whether the message button (603) in FIG. 6 or the message & mail button (604) in the first embodiment is pressed. Also, depending on whether a comment is posted on a message or a sub-comment is posted on a comment in the second embodiment. In addition, as described above, although not shown, when the user can explicitly select, designation by each method is included.

  In step S1210, the upper message is traced based on the corresponding ID, and the mail address is acquired. In the second embodiment, when a comment is posted, the upper message has an e-mail address. In the first embodiment, the upper message has a mail address. However, if the upper message does not have a mail address, whether the higher message is followed depends on the design or setting.

In S1211, when the e-mail address is acquired in S1210, the message posted in S1208 is transmitted as an e-mail to the e-mail address.
Thus, the description of the flowchart in FIG. 12 is completed.

<Embodiment related to process of consensus building by community system>
Next, a process for realizing consensus building using the community system will be described with reference to FIGS. In other words, a message that is an opinion posted to the Internet community (electronic bulletin board), which is the object of the present invention, is not bound by a strict route such as a workflow, and an intention indication such as approval by another user is displayed. A process to make it possible to collect opinions in a clear manner will be described.

  FIG. 13 is a diagram showing an example of a GUI for applying for a consensus message according to the embodiment of the present invention. A user who makes an application (a user who wants to collect opinions) activates this screen by pressing a button 405 in FIG.

  1300a is an initial screen immediately after the applicant starts up the screen for consensus building. The applicant is a user who has write permission in this forum (in the example, “Company A project”).

  The applicant inputs the contents to be aggregated and the contents to be approved as text in the application message field 1301a. Further, when it is desired to attach a file, a file attachment button 1304 is pressed, a target file is searched using, for example, a file manager, and the attachment process to the application message is performed. In addition, when a URL of a Web site or the like is to be attached, the URL is searched using the link URL attachment button 1305 or designated by manual description.

  Next, in order to obtain an agreement on the submitted opinion, a user (approver) who wants approval is selected. Specifically, when an add button 1303 is pressed, an approver list 1310 is displayed, and one or more approvers are selected. For example, this list may be included in the screen data received from the community server 101 when the forum screen is displayed. Further, the list may be requested from the community server 101 when the add button 1303 is pressed.

  The result of specifying the input to the application message column 1301b and the addition of the approver to the approver column 1302b is the screen of 1300b, and three users are added in this example.

  When the above input work is completed, the applicant presses the application button 1306. The input application message (consensus formation message for obtaining an agreement) and information on the approver are registered in the community server 101.

  FIG. 14 is a diagram showing an example of a GUI that displays a message in a forum of an approver who approves the consensus message according to the embodiment of the present invention.

  A user designated as an “approver” by the applicant displays a community site, but the screen is 1400a. The user is given access authority (viewing or writing) to a plurality of forums, but a forum list is displayed in the left frame of 1400a. Among these, a 1401 mark (a circular arrow) is displayed to the right of the forum “Company A Project”. This indicates that this user (a user who logs in and sees this GUI) has received an approval request in the forum “Company A project” and has not yet been processed. At the stage with this mark,

  A message list of the forum is displayed in the right frame of 1400a by an operation such as clicking on the corresponding forum. The top message (1402a) is a message for which an approval request is made.

  When this message is opened (1402b of 1400b), in addition to the message, the approval status of the user who requested the approval can be known. For example, the status is displayed as unprocessed / approved / denied. Initially, all users are in an unprocessed state, but the state (display form) changes as approval proceeds.

  If the user requested for approval is unprocessed, the user presses the 1403 button 1400a. Then, a selection list 1410 is displayed, and “approval” or “denial” can be selected.

  FIG. 15 is a diagram showing an example of a GUI for explaining the transition of the approval process in the consensus message according to the embodiment of the present invention. In FIG. 14, the description has been made on the assumption that the user who has requested the approval selects “approval” or “denial”. However, in the case of simple consensus formation, there may be a case where only confirmation that the user who requested the approval has approved (read the consensus message) may be performed. In that case, it is only necessary to display on the screen as a state change only the status of whether or not it is unprocessed. FIG. 15 is a diagram for explaining such a situation.

  Each screen in FIG. 15 is an image obtained by extracting only the part of message F (1402) in FIG.

  First, at the stage where no one is processing, the names of all three users requested for approval are displayed as “unprocessed” (1402c).

  Approval display form changes to 1402d and 1402e as it is sequentially approved, and when it is determined that the approval of all has been completed (by the approval completion determination unit), it indicates that the approval of all is completed as indicated by 1402f. The display form may be changed.

  FIG. 16 is a diagram showing an example of the data configuration of the message storage unit corresponding to the consensus building message according to the embodiment of the present invention.

  When an application message (consensus building message) is applied, a normal message is posted to the message storage unit 309 (510 in FIG. 5, 510a in FIG. 16) with the body of the application message (contents described in 1301b). Registered as if. In 510a, a message (1600) having a message ID “F” is registered in the forum “Company A project”.

  Further, information indicating that it is an application message is stored in the table (1610) of the message storage unit 309. 1610 includes a data item of a forum name (1611) and a message ID (1612) as relation information indicating which message (application message) of 510a corresponds, and further, as a list of approval requesters, Data items of an unprocessed user (1613), an approved user (1614), and a rejected user (1615) are provided.

  However, this data configuration example is merely an example, and 1613 to 1615 out of 1610 tables may be configured in the same table as the message storage unit 309. Further, in order to distinguish whether the message is a consensus message or a normal message, it may be determined that at least one user name is described in 1613 to 1615. Reference numeral 1610 denotes a description corresponding to the GUI shown in FIG.

  In the case of corresponding to the GUI in FIG. 15, the data items 1614 and 1615 in the table 1610 are unnecessary, and in 1613, in the initial application state of the consensus message, all users of the approval requester are described. Thereafter, the user who has performed the transmission process may be deleted from 1613. In this case, even if only the unprocessed data item 1613 is used as the data item in the message storage unit 309, it becomes impossible to distinguish whether the message was originally an agreement formation message after all the approvals have been completed. Therefore, a flag indicating that it is a consensus message is prepared and set to “true” at the time of application.

  This completes the description of the data items and the like that need to be expanded in order to deal with the consensus building message in the message storage unit 309 described in FIG. 16 will be described together in FIG.

  FIG. 17 is a diagram showing an example of a GUI for explaining the approval result of the consensus message and the posting of the sub comment according to the embodiment of the present invention. Message F will be described as a consensus message.

  First, since the consensus building message is a normal message, as described in the first and second embodiments for explaining the basic operation of the community system, a sub message (in the case of the first embodiment), a comment ( In the case of the second embodiment). That is, even if it is an approver and not an approver, a sub message or a comment (hereinafter referred to as a comment) can be posted as a normal process (for example, 1700a).

  In the GUI (1700a), for example, a comment F1 is a post made by an approver, and F2 is a post made by a person other than the approver. However, it cannot be distinguished.

  In the description of FIG. 14, the user who is requested to approve can select approval or denial (1410), but cannot post a comment describing the reason. Therefore, the comment of the GUI (1700a) is posted separately from the approval operation.

  However, it is possible to input a comment upon approval or rejection (post as a comment related to the consensus message). Therefore, after selecting approval / denial in 1410 in FIG. 14, a comment input GUI (see FIG. 8) is displayed, the comment may be input, and the comment may be posted. As a result, in the GUI (1700b), the consensus building message is in a state where all the members have been approved (1701), and the comment posted by the user who requested the approval at the time of approval or denial so that the fact is understood. The display form is changed from a normal comment (for example, 1702). The display form of other comments, such as a user who has not been requested for approval or a comment posted even when approved or rejected, may not be changed (1703).

  In addition, when the user inputs a comment at the time of approval or rejection and uses a GUI of 1700b, the message storage unit 309 is configured as shown in the table (510b) of FIG. 16 in order to distinguish posted comments. Can do. That is, an approval time flag (1616) may be provided as a data item, and if the value is “true”, it may be indicated that the comment has been posted as an approval or denial comment. For example, a comment whose message ID is F1 is a comment at the time of approval or denial, and F2 (1617) is a comment other than at the time of approval / denial even if the user is requested to approve, or an approval is not requested. User comments.

  In addition, the community system may be able to repeat re-approval and re-denial for the user who has requested the approval, in order to change the judgment again, replace the comment, etc. even after once approving or denying it. Alternatively, it may be possible only once.

In the above description, a comment can be posted by a user other than the user who requested the approval. However, it may be limited so that only the user who requested the approval can post.
This completes the description of the GUI of FIG.

  Next, the process of the community system will be described with reference to the flowcharts of FIGS.

  FIG. 18 is a flowchart showing an example of the application process for the consensus message according to the embodiment of the present invention. Each step in FIG. 18 is executed by the CPU 201 of the client terminal 102 or the community server 101.

  In step S <b> 1801, the client terminal 102 receives a function activation operation for consensus formation from the user. Specifically, the pressing of the button 405 in FIG. 4 is accepted.

  In step S <b> 1802, the client terminal 102 requests the community server 101 for a screen for performing an agreement formation operation.

  In step S <b> 1803, the community server 101 receives a request for a screen for performing an agreement formation operation from the client terminal 102.

  In step S <b> 1804, the community server 101 transmits a screen for performing an agreement formation operation to the client terminal 102.

  In step S <b> 1805, the client terminal 102 receives a screen for performing an agreement formation operation from the community server 101.

  In step S <b> 1806, the client terminal 102 displays a screen for performing an agreement formation operation on the display device of the client terminal 102.

  In step S <b> 1807, the client terminal 102 receives an input of an application message (a message for consensus formation) from the user.

  In step S <b> 1808, the client terminal 102 presents a user list (a list of users having access rights to the forum) to the user and determines the approver selected by the user from among them in order to determine an approver to which the user requests approval. Accept. For example, the above-described screen for making a consensus (the screen received from the community server 101 in S1804) includes a user list of forums being processed as information, which is displayed as a list, and one or more Let the creator of the application message select this user.

  In step S <b> 1809, the client terminal 102 receives a file attachment or a link destination URL designation from the user.

  In step S <b> 1810, the client terminal 102 receives the content of the consensus formation message (consensus formation content including information such as the approver) from the user (consensus formation content application reception unit). Specifically, the content of the agreement formation is accepted by the operation of pressing the application button 1306 in FIG.

  In S1811, the client terminal 102 notifies the application content of the consensus building message to the community server 101 (consensus building content notifying unit).

  In S1812, the community server 101 receives the application content of the agreement formation message from the client terminal 102 (agreement formation content reception unit).

  In S1813, if there is a file attached to the application content of the consensus building message, the community server 101 stores it in the file storage unit managed by the community server 101, and acquires the storage destination as a URL.

  In S1814, the community server 101 extracts a consensus message (message extraction unit) if there is a designation of the URL for storing the attached file or a designation of the link destination URL (specified in S1809). Add to the body of the message.

  In S1815, the community server 101 posts the consensus building message in the same manner as a normal message. Specifically, the message is stored in the message storage unit 309. Further, if there is a flag indicating that it is a consensus message, it is set to an appropriate value (for example, the one described in FIG. 16).

  In step S <b> 1816, the community server 101 registers an approver list for the consensus building message in the message storage unit 309. Specifically, it is registered in 1610 unprocessed (1613) in FIG.

  With the functions described above, it is possible to easily apply for an agreement forming message as to whether or not another user's agreement can be obtained by the same operation as the function to specify the approver and post the message of the community system. An effect can be obtained.

  This completes the description of the flowchart for applying for the consensus message in FIG.

  FIG. 19 is a flowchart showing an example of the process for approving the consensus message according to the embodiment of the present invention. Each step in FIG. 19 is executed by the CPU 201 of the client terminal 102 or the community server 101. In the flowchart of FIG. 19, the GUI is displayed on the client terminal 102 of the user set as the approver, and is processed according to the operation of the user.

  In step S1901, the client terminal 102 requests a community site screen from the community server 101 based on a user operation. Specifically, the GUI shown in FIG. 4 is a state where a specific forum is not selected, that is, a message is not displayed in 403. In addition, a message list of a default forum (the top forum or the like) may be displayed. For example, when using a Web browser, the URL for providing the community service in the community server 101 is specified from the Web browser and accessed, and an initial screen is requested by performing an authentication process such as login.

  In step S <b> 1902, the community server 101 receives a community site screen request from the client terminal 102.

  In step S1903, the community server 101 transmits the screen of the community site to the client terminal.

  In step S <b> 1904, the client terminal 102 receives a community site screen from the community server 101.

  In S1905, the client terminal 102 displays the screen of the community site on the display device by the display control unit. In the above example, it is displayed on the Web browser.

  In S1906, the client terminal 102 determines whether there is an unprocessed consensus message. That is, it is determined whether or not there is an unprocessed consensus message in any forum. Specifically, the screen of the site received in the above-described step includes an attribute in which any of the messages is a consensus message and is in an unprocessed state. If an unprocessed consensus message is included (in the case of YES), the process proceeds to S1907. If not (NO), the process proceeds to S1908.

  In step S <b> 1907, the client terminal 102 changes the display form of the forum (displayed in the GUI forum list (401 in FIG. 4)) described above. For example, a mark 1401 in FIG. 14 is given, highlighted, or blinked.

  In step S1908, the client terminal 102 accepts a forum detail display operation. Specifically, in order to display a list of messages from the forum list, the user accepts the operation for selection by pressing the forum. Actually, an arbitrary forum can be selected from the forums displayed in the forum list, but hereinafter, the operation and processing will be described assuming that a forum having an unprocessed consensus message is selected. For example, in FIG. 14, an operation in which the user selects the “Company A project” forum to which the mark 1401 is assigned is accepted.

  In step S1909, the client terminal 102 displays a list of messages in the forum designated by the user (there is an unprocessed consensus message).

  In step S1910, the client terminal 102 receives processing such as approval performed by the user (approval content reception unit). Specifically, the result of the operation of the consensus building message performed by the user by the operation described in FIG. 14 is accepted.

  In S <b> 1911, the client terminal 102 changes the display form of the consensus building message according to the result of the approval operation. Specifically, as described above, 1402a in FIG. 14 is changed to 1402b, or 1402c in FIG. 15 is sequentially changed to 1402f. Alternatively, if an approval (or denial) message can be posted as described in the GUI of FIG. 17, these messages are also displayed.

  In S1912, the client terminal 102 notifies the community server 101 of the approval content (approval content notification unit).

  In S1913, the community server 101 receives the approval content from the client terminal 102 (approval content receiving unit). Specifically, whether or not it has been approved is accepted, and if a comment can be posted, the comment is accepted.

  In S1914, the community server 101 registers the approval content (approval information update unit). Specifically, the message storage unit 309 is updated as described with reference to FIG. That is, the content of approval or rejection is extracted from the approval content, and the message storage unit 309 is updated. If a comment is further given, the comment is extracted and the message storage unit 309 is updated.

  With the functions described above, it is possible to obtain an effect that an agreement formation message requested by another user can be browsed and an operation such as approval can be easily performed by an operation equivalent to the function of browsing a message of the community system. .

  This completes the description of the flowchart of the approval process for the consensus message in FIG.

  It should be noted that the configuration and contents of the various data described above are not limited to this, and it goes without saying that the various data and configurations are configured according to the application and purpose.

  Although one embodiment has been described above, the present invention can take an embodiment as, for example, a system, apparatus, method, program, or recording medium, and specifically includes a plurality of devices. The present invention may be applied to a system including a single device.

  The program according to the present invention is a program that allows a computer to execute the processing methods of the flowcharts shown in FIGS. 11, 12, 18, and 19, and the storage medium according to the present invention is illustrated in FIGS. A program capable of executing the processing method of FIG. 19 by a computer is stored. Note that the program in the present invention may be a program for each processing method of each apparatus in FIGS. 11, 12, 18, and 19.

  As described above, a recording medium that records a program that implements the functions of the above-described embodiments is supplied to a system or apparatus, and a computer (or CPU or MPU) of the system or apparatus stores the program stored in the recording medium. It goes without saying that the object of the present invention can also be achieved by executing the reading.

  In this case, the program itself read from the recording medium realizes the novel function of the present invention, and the recording medium storing the program constitutes the present invention.

  As a recording medium for supplying the program, for example, a flexible disk, hard disk, optical disk, magneto-optical disk, CD-ROM, CD-R, DVD-ROM, magnetic tape, nonvolatile memory card, ROM, EEPROM, silicon A disk, solid state drive, or the like can be used.

  Further, by executing the program read by the computer, not only the functions of the above-described embodiments are realized, but also an OS (operating system) operating on the computer based on an instruction of the program is actually It goes without saying that a case where the function of the above-described embodiment is realized by performing part or all of the processing and the processing is included.

  Furthermore, after the program read from the recording medium is written to the memory provided in the function expansion board inserted into the computer or the function expansion unit connected to the computer, the function expansion board is based on the instructions of the program code. It goes without saying that the case where the CPU or the like provided in the function expansion unit performs part or all of the actual processing and the functions of the above-described embodiments are realized by the processing.

  Further, the present invention may be applied to a system composed of a plurality of devices or an apparatus composed of a single device. Needless to say, the present invention can be applied to a case where the present invention is achieved by supplying a program to a system or apparatus. In this case, by reading a recording medium storing a program for achieving the present invention into the system or apparatus, the system or apparatus can enjoy the effects of the present invention. Furthermore, by downloading and reading a program for achieving the present invention from a server, database, etc. on a network using a communication program, the system or apparatus can enjoy the effects of the present invention.

  In addition, all the structures which combined each embodiment mentioned above and its modification are also included in this invention.

101 Community server 102 Client terminal 103 Mail server 104 Web mail server 105 Network

Claims (7)

A community system in which a client terminal and a community server that manages messages posted to the net community can be connected via the network,
The client terminal is
An agreement formation content application accepting means for associating the message with an approver who is a user of a net community requesting approval of the message, and accepting it as agreement formation content;
An agreement formation content notification means for notifying the community server of the agreement formation content received by the agreement formation content application reception means;
With
The community server
Message registration means for storing the posted message and information about the approver when the message is the message in the consensus content, in a message storage means;
An agreement formation content receiving means for receiving the agreement formation content notified from the client terminal;
Message extraction means for extracting the message in the agreement formation content from the agreement formation content;
Posting means for posting the message to the message storage means;
A community system characterized by comprising: The client terminal further includes:
Display control means for displaying a screen for performing the message and approval operation of the net community on a display device of the client terminal;
When the message of the net community displayed on the display device by the display control means is the message in the content of the consensus formation, the result of the approval operation of the user who is the approver requested to approve, Approval content acceptance means for accepting approval content;
An approval content notification means for notifying the approval content to the community server;
With
The community server further includes:
An approval content receiving means for receiving a notification of the approval content;
Approval information updating means for updating information on the approver registered in the message storage means based on the approval contents received by the approval content receiving means;
The community system according to claim 1, further comprising:   The community system according to claim 2, wherein the approval content further includes either approval or denial information for the message in the consensus formation content. The approval content may further include the approver's message for the message in the consensus building content,
The approval information update means further includes:
3. If the message of the approver is included in the approval content, the posting means causes the posting means to post as the message related to the message of the posted consensus content. The community system described in Item 3. The client terminal further includes:
Approval completion determination means for determining whether or not all of the approvers requested for approval have been approved for the message in the content of the consensus formation based on information on the approver in the message storage means;
With
The display control means further includes
When the approval completion determination unit determines that all the approvers have approved the message in the consensus content posted by the posting unit, the display form of the message is changed. The community system according to any one of claims 2 to 4. A control method of a community system in which a client terminal and a community server that manages messages posted to the net community can be connected via a network,
The client terminal is
An agreement formation content application receiving means accepts the message and an approver who is a user of the net community requesting approval of the message as an agreement formation content application receiving step;
A consensus formation content notifying means for notifying the consensus formation content received in the consensus formation content application receiving step to the community server;
With
The community server
A message registration step for causing the message registration means to store the posted message and the information on the approver in the case where the message is the message in the consensus formation content in association with each other in the message storage means;
A consensus formation content accepting unit accepts the consensus formation content notified from the client terminal;
A message extracting step for extracting the message in the agreement formation content from the agreement formation content;
Posting means for posting the message to the message storage means;
A community system control method comprising: A program that can be executed in a community system in which a client terminal and a community server that manages messages posted to the net community can be connected via the network,
The client terminal is
An agreement formation content application accepting means for accepting the message and an approver who is a user of a net community requesting approval of the message as agreement formation content,
Agreement formation content notification means for notifying the community server of the agreement formation content received by the agreement formation content application reception means;
Function as
The community server,
Message registration means for associating and storing the posted message and the information related to the approver when the message is the message in the consensus formation content, in a message storage means;
Agreement formation content receiving means for receiving the agreement formation content notified from the client terminal;
Message extraction means for extracting the message in the consensus formation content from the consensus formation content;
Posting means for posting the message to the message storage means;
A program characterized by functioning as

Images