Information processing system, information processing method, and program

Abstract

To provide an information processing system and program configured so that posts of all users may be easy to comment on while reducing commenting burden, thereby efficiently facilitating communication and eliminating organizational imbalance.SOLUTION: In an information processing system, a management server 130 includes a control unit and a storage unit. The storage unit stores a plurality of user IDs identifying a plurality of users, respectively. The control unit includes a processing unit. The processing unit performs group generation processing to divide the user IDs into groups based on a predetermined reference value, displays timeline according to a group and a user ID, and displays information representing a user related to the user ID and a comment input field for receiving an input of comment, with the timeline.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates to an information processing system and a program, for example, to a system for supporting communication within an organization, and also to a technology for promoting non-face-to-face communication. [Background technology]

[0002] In recent years, labor-related issues in companies have been attracting attention, and society is beginning to value a company not only in terms of financial soundness, but also in terms of whether the company is run in a way that keeps employees healthy both physically and mentally. Among these, communication between employees is one of the factors that keeps employees healthy.

[0003] Promoting communication is an essential element in building trust between people, and is particularly important in companies as it is related to improving productivity and preventing employee turnover. However, with the spread of remote work in recent years, face-to-face communication has decreased, while non-face-to-face online communication has increased.

[0004] Unlike face-to-face communication, non-face-to-face communication rarely occurs accidentally, and the target person is often selected with a certain degree of communication purpose in mind. Therefore, while it is easy to contact direct superiors and related parties with whom one has a work-related relationship, opportunities for conversations with colleagues at work with whom one has little work-related relationship, or for casual conversations that are not work-related, tend to be lost.

[0005] Companies need to increase communication between employees, reduce feelings of loneliness and anxiety, and maintain a healthy workforce. As a means to achieve this, an increasing number of companies are introducing social networking services (SNS) within their companies. SNS allows users to share information across the organization through posts, which other participants can view and comment on, promoting cross-sectional communication. Therefore, it is important to encourage employee use, and related inventions are being developed for general SNSs.

[0006] For example, from the viewpoint of activating behavior such as comments, Patent Document 1 visualizes and displays information on the amount of behavior between users on SNS, allowing users to understand their own amount of behavior and promoting and preventing excessive behavior. Also, from the viewpoint of efficiently acquiring information, for example, Patent Document 2 determines and filters users who will display comments and users who will not, based on the degree of association between users. [Prior art documents] [Patent documents]

[0007] [Patent Document 1] Patent No. 6798958 [Patent Document 2] Japanese Patent Application Laid-Open No. 2014-154003 Summary of the Invention [Problem to be solved by the invention]

[0008] When considering the use of social media within a company, simply visualizing activity levels or filtering users does not necessarily promote cross-organizational communication.

[0009] First, in organizations such as companies, people in managerial positions are expected to support the organization, so it is desirable for them to actively comment on employee posts. However, managers are generally busy with their daily work, and the larger the organization, the greater the number of employees they need to support, so it is a heavy burden for managers to make comments alone. On the other hand, when non-managerial, experienced employees provide support instead, commenting on colleagues with whom they have little work-related ties is a high psychological hurdle, which can result in a burden on decision-making when deciding who to comment to, or in the risk of comments being concentrated on a few employees.

[0010] Next, subordinates and new employees who need support may not receive sufficient support from their superiors or veteran employees for the reasons mentioned above, which can lead to issues such as isolation within the organization and difficulty in building understanding relationships. If they realize that there are few comments from others on their posts, their sense of belonging to the organization and their desire for recognition may not be satisfied, which could lead to a vicious cycle of further suppression of communication.

[0011] As mentioned above, when trying to increase the use of SNS in organizations such as companies, simply visualizing the amount of activity and filtering users will only result in arbitrary control over who can send and view comments, which could lead to bias, such as the concentration of communication between specific people.In order to promote cross-sectional communication, it is necessary to increase communication among each employee while activating it equally across the entire organization.

[0012] Therefore, the object of the present invention is to efficiently promote communication and eliminate imbalances across the organization by reducing the burden of making comments and making it easier for any user to receive comments from others. [Means for solving the problem]

[0013] An example of an information processing system according to the present invention includes: An information processing system having a processing unit and a storage unit, the storage unit stores a plurality of user IDs each identifying a plurality of users; The processing unit performing a group generation process in which the plurality of user IDs are assigned to groups based on a predetermined reference value; Displaying a timeline according to the group and the user ID; Along with the timeline, information indicating the user associated with the user ID and a comment input field for accepting input of a comment are displayed.

[0014] An example of a program according to the present invention causes a computer to function as the information processing system described above. [Effects of the Invention]

[0015] According to the present invention, it is possible to efficiently promote cross-sectional communication by increasing communication between users and eliminating imbalances in communication within an organization. [Brief explanation of the drawings]

[0016] [Figure 1] 1 is a diagram showing the overall configuration and functions of a communication promotion system according to a first embodiment of the present invention. [Figure 2] FIG. 1 is a conceptual diagram showing an overview of allocating users to groups in the first embodiment of the present invention. [Figure 3] FIG. 2 is a sequence diagram showing an overview of the overall process when using the communication facilitation system according to the first embodiment of the present invention. [Figure 4] FIG. 3 is a diagram illustrating an example of a user table in the first embodiment of the present invention. [Figure 5] FIG. 3 is a diagram illustrating an example of a tenant table according to the first embodiment of the present invention. [Figure 6] FIG. 3 is a diagram showing an example of a posting history table in the first embodiment of the present invention. [Figure 7]FIG. 3 is a diagram showing an example of a behavior history table in the first embodiment of the present invention. [Figure 8] FIG. 10 is a diagram showing an example of a display screen of an application used when an administrator inputs group settings in the first embodiment of the present invention. [Figure 9] 10 is a flowchart illustrating an example of processing performed by a group setting receiving unit of the management server according to the first embodiment of the present invention. [Figure 10] FIG. 3 is a diagram showing an example of a group setting table in the first exemplary embodiment of the present invention. [Figure 11] FIG. 3 is a diagram showing an example of external relationship data in the first embodiment of the present invention. [Figure 12] 10 is a flowchart illustrating an example of processing performed by a group management unit of a management server according to the first embodiment of the present invention. [Figure 13] FIG. 3 is a diagram showing an example of a group table in the first exemplary embodiment of the present invention. [Figure 14] FIG. 3 is a diagram showing an example of a group member table in the first exemplary embodiment of the present invention. [Figure 15] 10 is a flowchart showing an example of processing performed by a UI providing unit of the management server according to the first embodiment of the present invention. [Figure 16] FIG. 4 is a diagram showing a display example of a client screen in the first embodiment of the present invention. [Figure 17] FIG. 10 is a diagram showing an example of a display screen of an application used when an administrator checks a group setting status in the first embodiment of the present invention. [Figure 18] FIG. 2 is a diagram showing an example of a display of an e-mail in the first embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0017] [Example 1] Figure 1 shows the overall configuration and functions of an SNS-type communication promotion system. Each function in the diagram is realized by a combination of hardware and software. An overview of the system is explained here, and details of each function will be provided later using other drawings.

[0018] The SNS-type communication promotion system is an information processing system that includes a client 111 operated by a user 110, an application system 161 operated by an administrator 160, and a management server 130 that can connect to the client 111 and the application system 161 via a wireless or wired network 170.

[0019] 1 illustrates user 120 and client 121, and multiple users can operate different clients to connect to network 170. Unless otherwise specified, the following explanation of user 110 and client 111 also applies to user 120 and client 121, and also to other users and clients not shown.

[0020] The client 111 is a typical smartphone, PC terminal, or the like, and includes a transmission / reception unit 112, an input / output unit 113, a control unit 114, and a storage unit 115. The transmission / reception unit 112 is configured with a wired or wireless network interface. The input / output unit 113 exchanges information with a user and is configured with input / output devices such as a screen, a touch panel, and a keyboard. The control unit 114 is configured with a central processing unit (CPU), which is a processing unit of a typical computer, or the like. It can be said that the processing of each computer described in this specification is executed by the respective processing unit. The storage unit 115 is configured with a memory device such as a semiconductor storage device or a magnetic storage device.

[0021] The control unit 114 has a user authentication function 116, a posting function 117, and a user-to-user behavior function 118, which are realized by executing a predetermined program stored in the storage unit 115. The user authentication function 116 authenticates whether the user is a person who has been registered in advance by means of a password request or the like, and if the authentication is successful, the user is permitted to log in. After successful login, the user ID is stored in the storage unit 115.

[0022] The posting function 117 enables the user 110 to post on the SNS by sending data input by the user 110 operating the input / output unit 113 to the management server 130 via the transmission / reception unit 112. Similarly, the user-to-user action function 118 enables the user 110 to perform actions such as "liking" or "commenting" on posts by other users by operating the input / output unit 113 and sending the data to the management server 130, thereby realizing communication with other users on the SNS.

[0023] The management server 130 has a control unit 131, a storage unit 132, a transmission / reception unit 133, and a mail server 134. The control unit 131, which is configured with a normal CPU or the like, has a group setting reception unit 140, a group management unit 141, a UI provision unit 142, a user management unit 143, a post / action management unit 144, a group status provision unit 145, and a mail management unit 146. These are realized by the control unit 131 executing a predetermined program stored in the storage unit 132, which is configured with a memory device or the like.

[0024] The database in the storage unit 132 includes a user table 150, a tenant table 151, a posting history table 152, an action history table 153, a group setting table 154, a group table 155, a group member table 156, and an external relationship table 157. Data exchange with the client 111 and the application system 161 is performed via the transmission / reception unit 133, which is configured as a network interface.

[0025] The user management unit 143 receives user information entered by the administrator 160 from the application system 161 and stores it in the user table 150. The post / action management unit 144 receives information about posts and actions entered by the user 110 from the client 111 and stores it in the post history table 152 and the action history table 153, respectively.

[0026] The group setting receiving unit 140 receives the group settings (such as the number of people in the group, schedule, etc.) input by the administrator 160 from the application system 161 and stores and registers them in the group setting table 154. Based on the stored setting data, the group management unit 141 determines how to allocate the target users to groups and stores the results in the group table 155 and the group member table 156.

[0027] The UI providing unit 142 receives a user ID and a screen display request from the client 111, and displays a dedicated timeline for the group to which the user 110 belongs on the screen of the client 111. With this basic configuration, target users are periodically sorted into groups based on the number of people, schedule, etc. set by the administrator 160, and are presented as people who can send comments to each other.

[0028] Furthermore, the group management unit 141 can determine group allocation by taking into consideration past group allocations and the amount of activity between users, using information stored in the group member table 156 and the behavior history table 153. Furthermore, group allocation may be determined by taking into consideration relationships and communication volume between users outside the system, for example, email sending and receiving history and chat history obtained from PC or mobile phone logs, or face-to-face information obtained from a sensor device, etc. This information can be prepared as external relationship data 180, and can be used for group allocation by having the administrator 160 operate the application system 161 to store it in the external relationship table 157 of the management server 130.

[0029] The group status providing unit 145 receives a screen display request from the application system 161, compiles the information stored in the group member table 156 and the action history table 153, and displays information such as the member composition and number of comments of each group on the screen of the application system 161. The email management unit 146 compiles the member composition and posting status based on the information stored in the group member table 156 and the posting history table 152, and delivers emails to the email addresses linked to the target users via the email server 134. Note that the user 110 may be able to view emails using the client 111.

[0030] The application system 161 is a system used by the administrator 160 to manage user and group settings. The application system 161 is a general PC terminal or the like. The application system 161 has a transmitting / receiving unit 162 configured as a network interface, an input / output unit 163 configured as a screen, a keyboard, etc., a control unit 164 configured as a CPU, etc., and a storage unit 165 configured as a memory device, etc.

[0031] The control unit 164 has an administrator authentication function 166, a user management function 167, and a group management function 168, which are realized by executing predetermined programs stored in the storage unit 165. The administrator authentication function 166 authenticates whether the administrator is a person registered in advance by using a means such as a password request, and if the authentication is successful, the administrator is permitted to log in. After the login is successful, the administrator ID is stored in the storage unit 165.

[0032] The user management function 167 enables the administrator 160 to manage users by pre-registering them and assigning predetermined labels to them, by transmitting data entered by the administrator 160 operating the input / output unit 163 to the management server 130 via the transmission / reception unit 162. Similarly, the group management function 168 enables the administrator 160 to set the number of people in a group, schedules, etc., and view the group allocation status, by transmitting data entered by the administrator 160 operating the input / output unit 163 to the management server 130 via the transmission / reception unit 162.

[0033] As described above, the management server 130, the client 111, and the application system 161 have a hardware configuration as a known computer, and each has a control unit and a storage unit. The control unit has a processing unit and controls the computer. The storage units each store a program, and the processing units execute the corresponding program, causing the computer to function as the management server 130, the client 111, and the application system 161, respectively. In other words, each program causes the corresponding computer to cooperate and function as a communication promotion system.

[0034] FIG. 2 is a diagram outlining an example of grouping users in a communication promotion system. Target user group 200 represents target users to be assigned to groups, and is a group including multiple users (for example, a certain number or more). Target user group 200 is a target for promoting communication, and may comprise a company, community, organization, etc. that aims to stimulate exchanges of comments and the like between users and to create an equal communication network so that communication is not concentrated among only a few users. Ten users are shown as an example.

[0035] Each user in the target user group 200 is assigned to a group by a group assignment process 220 (group generation process) based on information set by the administrator 160. The number of groups can be determined, for example, by setting a lower limit 210 on the number of people per group, so that the number of people in each group is equal to or greater than the lower limit and the number of groups is maximized. The example in FIG. 2 shows a case where the lower limit 210 on the number of people is set to "3," and 10 users are assigned to three groups 201.

[0036] In a small group environment where communication is impossible without constant participation, people tend to feel psychological pressure to comment, while in a large group they tend to become reluctant to communicate and feel burdened by commenting, so controlling the number of people in a group is important. Setting a minimum limit ensures that each group has the minimum number of people necessary for smooth communication, and at the same time, maximizing the number of groups prevents groups from becoming too large.

[0037] Furthermore, since the administrator 160 can set an appropriate number of users that allows easy communication between them regardless of the number of people in the target user group 200, it is easier for the administrator 160 to determine by specifying a lower limit rather than simply specifying the number of groups. In practice, it is desirable to set the lower limit within the range of 3 to 5 people as an appropriate number of people that allows easy communication between users.

[0038] Users who are in the same group recognize each other as people who can comment on each other's posts. The group activity ends after a certain period of time, and the users are reassigned to a new group 202 by a group allocation process 221 (group generation process). In this embodiment, the certain period of time during which the group is active is called a first course 230, a second course 231, etc. The period of each course can be, for example, one week, and can be set in advance by the administrator 160. Similarly, the number of times the course is repeated can also be set by the administrator 160.

[0039] In this way, by assigning users to groups with an appropriate number of members that facilitate easy communication, it is expected that each user will be more likely to receive a certain number of comments. In addition, because the target users for comments are automatically determined and the number of members is small, the burden of comments is reduced, which is expected to promote communication within the group. Furthermore, by periodically changing the composition of groups, it is possible to eliminate imbalances in the communication network between users and support the building of cross-sectional human relationships within the organization.

[0040] In addition, as will be explained later in Figure 12, by taking into account information such as the most recent group member composition and the number of comments in the group allocation process, users who communicate less can be preferentially allocated to the same group, thereby more efficiently activating and equalizing communication within the organization.

[0041] FIG. 3 is a sequence diagram showing the overall flow of the usage procedure and processing in the communication promotion system.

[0042] In the sequence diagram, the user and the client operated by the user are represented as 301, the management server as 302, and the administrator and the application system operated by the administrator as 303. The processing content of each object and the data exchange between objects are briefly explained.

[0043] In step 304, the administrator inputs group settings (such as target users for grouping, minimum number of users, and group settings) through the application system, and in step 305, the input group settings are sent from application 303 to management server 302. In step 306, the sent group settings are saved (registered) in a database in management server 302.

[0044] The saved group settings contain data for the start date 307 of the first course, and when that date arrives, step 308 (group allocation process or group generation process) is executed. In step 308, group allocation process is performed based on the group settings, and the group to which each user will belong during the first course is determined. In parallel, the end date of the first course is also calculated. In step 309, an email containing the determined group membership is sent to the email address associated with the target user. Note that the notification of the membership may not only be sent by email, but may also be displayed directly on the client screen.

[0045] In step 310, the user performs user authentication through the client to log in, and the client requests screen display. In step 311, the user ID is sent from client 301 to management server 302. In step 312, the group to which the user belongs in the first season is checked based on the sent user ID. In step 313, post data from members of the group to which the user belongs is obtained and sent to client 301, and a timeline dedicated to the group is displayed.

[0046] In step 314, the user can input posts or perform user-to-user actions such as "liking" or "commenting" on other users' posts at any time through the client. A post refers to, for example, a message that a user inputs with the intention of other users viewing it, or data that includes that message. A post may also include images or other data that the user inputs or specifies.

[0047] In step 315, immediately after the user executes step 314, data on posts and actions is transmitted from client 301 to management server 302. Note that steps 314 and 315 may be executed multiple times by the user.

[0048] In step 316, an email (reminder email) describing the posting status for each group is sent to the email addresses associated with the members of each group. Note that step 316 may be executed periodically after the start date of the first course, and may be set by the administrator to be sent at a predetermined time every day, for example.

[0049] The above steps 310 to 316 may be repeatedly executed multiple times during the first period. Then, when the second period start date 317 arrives, new group allocation is executed in the next step 318, and the users are allocated to the new groups. After this, although not shown in the figure, the period start date arrives the number of times set by the administrator, and the same process is executed for each period. In this way, the management server 302 performs group generation processing at regular intervals. As a result, the group composition changes periodically, which can eliminate imbalances in the communication network between users and support the building of cross-sectional human relationships within the organization.

[0050] Furthermore, once the end date of the final course has passed, group allocation will no longer be performed and the user may be considered not to belong to any group.

[0051] Through the overall processing flow described above, the target user group designated by the administrator is grouped based on the number of people, schedule, etc. designated by the administrator. Each user will periodically belong to a group with a new member composition, and it is expected that communication between members within the group will become closer through the display of a timeline dedicated to that group and the distribution of emails, etc.

[0052] Note that group allocation may be performed all at once, for example, immediately after step 306, instead of at the timing of the start date of each course as in this sequence diagram, but it is preferable to perform it at the timing of the start date of each course if group allocation is performed taking into account the relationships between recent users, as will be described later in Figure 12. Also, by performing allocation each time each course, it is possible to deal with an increase or decrease in the number of target users midway, and flexible responses are possible, such as changing the number of groups depending on the number of target users at the timing of the start date of each course.

[0053] 4 is a table for managing user information, and is stored in the storage unit 132 of the management server 130. A user ID 401 is associated with a user name 402, a tenant 403, an email address 404, a login password 405, and a team 406.

[0054] The user ID 401 is information used to uniquely identify a user within the management server 130. The data stored in the user ID 401 can be omitted by specifying any one of the columns used in this table or a combination of multiple columns. The management server 130 may also automatically assign an ascending identification number to each user as an identifier. In this way, the storage unit 132 stores multiple user IDs that respectively identify multiple users.

[0055] The user name 402 stores the user's name as information representing the user. This information is displayed on the client 111 or application system 161 and is used by humans to identify the user.

[0056] The tenant 403 stores the ID of the tenant to which the user belongs in the tenant table 151 (corresponding to the tenant ID 501 in FIG. 5). A tenant is a dedicated area in the system where only users belonging to the tenant can view and comment on each other's posts, and in practice is set in units such as the company or community to which the user belongs. A user may belong to multiple tenants.

[0057] The email address 404 is information provided by the user 110 when registering an account on the management server 130, and is used as login information when accessing the management server 130 from the client 111, and when delivering email to the user from the mail server 134.

[0058] The login password 405 is password information used as login information when the user 110 accesses the management server 130 from the client 111 .

[0059] The belonging team 406 is a label assigned to the users belonging to each tenant, and is used when classifying users into certain groups. The belonging team 406 can be used as a unit equivalent to the target user group 200 (FIG. 2) that is the basis for allocating users to groups. Allocating users to groups by the belonging team allows for flexible response, for example, if there are combinations of users that you do not want to allocate to the same group, you can deal with this by separating the teams that each user group belongs to. If you want all users belonging to a tenant to be in the same target user group, you can simply set all users to the same belonging team.

[0060] In practice, to avoid information leakage between tenants, it is desirable that a team be composed of only users who belong to the same tenant. In other words, it is desirable that all of the multiple users included in one target user group 200 belong to a specific company (for example, one specific company). Note that one user may belong to multiple teams.

[0061] The user table 150 is an example, and it is preferable to add any information necessary for managing user information.

[0062] The tenant table 151 in FIG. 5 is a table for managing information about tenants, and is stored in the storage unit 132 of the management server 130.

[0063] The tenant ID 501 is information used to uniquely identify a tenant registered in the management server 130. The data stored in the tenant ID 501 can be omitted by specifying any one of the columns used in this table or a combination of multiple columns. The management server 130 may also automatically assign an ascending identification number to each tenant as an identifier.

[0064] The tenant name 502 stores the name of the tenant. This information is displayed on the client 111 or the application system 161 and is used by humans to identify the tenant.

[0065] The administrator ID 503 stores the user ID of the tenant administrator of the tenant. The administrator ID may contain user IDs for multiple people.

[0066] The tenant table 151 is an example, and it is preferable to add any information necessary for managing tenant information.

[0067] The posting history table 152 in FIG. 6 is a table for managing data posted by users, and is stored in the storage unit 132 of the management server 130.

[0068] The posting history ID 601 is information used to uniquely identify data representing posts stored in the management server 130. The data stored in the posting history ID 601 can be omitted by specifying any one of the columns used in this table or a combination of multiple columns. The management server 130 may also automatically assign an ascending identification number to each posting history as an identifier.

[0069] User ID 602 ​​stores the user ID corresponding to the client 111 that sent the posting data to the management server 130. If the client 111 and the user ID do not correspond one-to-one, the relationship between the posting and the user ID can be clarified by associating the user ID with the posting data and transmitting and receiving it.

[0070] Posting date and time 603 stores the date and time when the client 111 transmitted the posting data to the management server 130 .

[0071] The posted content 604 is a character string input by the user 110 through the input / output unit 113 of the client 111, and is the data that is the subject of the post. The UI providing unit 142 obtains the posted content 604 from the posting history table 152 and displays it as a timeline on the screen of the client 111, etc., thereby sharing the post with other users.

[0072] Note that the posting history table 152 is an example, and it is preferable to add any information necessary for managing the posting history information.

[0073] The behavior history table 153 in FIG. 7 is a table for managing data on the behavior of the user, and is stored in the storage unit 132 of the management server 130.

[0074] The behavior history ID 701 is information used to uniquely identify a user behavior within the management server 130. The behavior includes, for example, a "Like" behavior and a "Comment" behavior. The data stored in the behavior history ID 701 can be omitted by specifying any one of the columns used in this table or a combination of multiple columns. In addition, the management server 130 may automatically assign an ascending identification number to each behavior history as an identifier.

[0075] The user ID 702 stores the user ID of the client 111 that transmitted the behavioral data to the management server 130. If the client 111 and the user ID do not correspond one-to-one, the relationship between the behavior and the user ID can be clarified by transmitting and receiving the behavioral data in association with the user ID.

[0076] The behavior date and time 703 stores the date and time when the client 111 transmitted the behavior data to the management server 130 .

[0077] The action type 704 indicates the type of action, such as a "like" or a "comment," that the user 110 has performed on other users. This is one form of communication on SNS, and one of the aims of this embodiment is to increase the frequency of these actions and to even out the frequency so that it is not biased towards specific users.

[0078] The target post ID 705 is an ID used to identify the post data that was the target of an action such as a “Like” or a “Comment”, and corresponds to the post history ID 601 in the post history table 152 .

[0079] The target user ID 706 is a user ID used to identify the user who sent the posted data that was the target of the action, and corresponds to the user ID 602 ​​in the posting history table 152 .

[0080] The description content 707 is a character string input by the user 110 through the input / output unit 113 of the client 111, and in the case of a "comment" action, the body of the comment is stored.

[0081] The table itself may be divided into different action types, such as "Like" and "Comment," in which case the "Like" table may not have a column for description 707. Action types may include not only actions targeted at posted content, such as "Like" and "Comment," but also actions directly targeted at users, such as sending direct mail or giving peer bonuses. It is preferable to add any other information necessary for managing action history information.

[0082] 8 shows an application screen that is an example of a GUI for inputting group settings in the application system 161. On this screen, the administrator 160 considers and inputs grouping settings for users who belong to the tenants that he or she manages. This input is performed in step 304 of FIG. 3.

[0083] The application screen 800 indicates a screen displayed by the application system 161, and is displayed on a display of a PC or the like used by the administrator 160.

[0084] The application screen 800 is divided into a side screen 810 and a main screen 820.

[0085] The side screen 810 has a tenant information box 811 and a menu box 812. The side screen 810 displays information that continues to be displayed even when the information in the main screen 820 is switched.

[0086] The tenant information box 811 displays the tenant name stored in the tenant table 151. This allows the administrator 160 to check whether operations can be performed on the tenants that are under his / her management. Additionally, information on the logged-in administrator may be displayed as necessary.

[0087] The menu box 812 displays a list of functions that the administrator 160 can execute, and by selecting one of them, the screen for using that function is displayed. In the illustrated example, group management is selected. Although not shown, if user management is selected, a screen may be displayed that allows the user to register a tenant and enter team settings.

[0088] The main screen 820 has a group setting creation box 830 and a save button 821. When the administrator 160 inputs information into the group setting creation box 830 and presses the save button 821, the grouping settings are completed.

[0089] The group setting creation box 830 has a participating team setting 831, a start date setting 832, a one-season period setting 833, a number of seasons setting 834, a minimum group size setting 835, a reminder usage setting 836, a reminder delivery time 837, and an external relationship data setting 838.

[0090] The participating team setting 831 displays a list of teams that exist within the tenant, and the administrator 160 can select the teams to be grouped. If the following settings are to be common, multiple teams may be selected and set at once. In addition, the number of members of each team may be tallied and displayed as a reference when setting the group number minimum setting 835, which will be described later.

[0091] The start date setting 832 is an item for setting the start date for allocating users to groups, and refers to the start date of the first course. The administrator 160 may set any date later than the current date on which this screen is displayed. The one course period setting 833 is an item for setting the length of time per course as a fixed period, and basically specifies the number of days. The number of courses setting 834 is an item for setting the number of times the course will be repeated. By setting the start date, one course period, and number of courses, the schedule for the entire period for grouping is determined.

[0092] The group number minimum setting 835 is an item for setting the minimum number of users to be assigned to each group. The effect is as described in the explanation of Figure 2, but here we will explain the relationship with the selection status of the participating team setting 831. The desirable setting value for the group number minimum is about 3 to 5 people, but it can be set to any number depending on the situation.

[0093] However, due to its nature, it is not possible to set a value that exceeds the number of members of the participating team. Therefore, it is necessary to limit the range of values ​​that can be entered depending on the selection status of the participating team. For example, it is desirable to include a judgment such as that in step 903 of Figure 9, which will result in a registration error so that a lower limit value that exceeds the number of members of the team is not set.

[0094] In this way, the group number minimum setting 835 is a predetermined number that serves as a reference value when allocating users to groups. That is, the management server 130 allocates multiple user IDs to groups based on a predetermined reference value. Note that in this embodiment, a minimum number of people is specified as the reference value, but this does not need to be a numerical value that directly represents the minimum number of people, and a value that indirectly represents the minimum number of people may also be used. Furthermore, it is not limited to a minimum, and any reference value that represents a reference number of people may also be used.

[0095] Reminder usage setting 836 is an item for setting whether or not the user can receive information even when not logged in. For example, by selecting email, the administrator can decide whether or not to execute step 309 or step 316 by the mail management unit 146. Reminder delivery time 837 is an item for setting the delivery time of email, etc., as desired when the administrator selects to execute the above-mentioned reminder usage setting 836.

[0096] The external relationship data setting 838 is an item for optionally specifying a file of the external relationship data 180 for taking into consideration previously established relationships between users when allocating users to groups. The specified file is uploaded to the management server 130 together with other setting data.

[0097] 9 is a flowchart showing an example of processing performed by the group setting reception unit 140 of the control unit 131 of the management server 130. This processing is executed in steps 304 to 306 of FIG.

[0098] The group setting reception unit 140 receives the group setting information input by the administrator 160 in the application system 161, determines whether it is possible to register it, and registers it in the management server 130.

[0099] In step 901, the group setting reception unit 140 displays a group setting creation screen such as the application screen 800 shown as an example in Figure 8 on the application system 161. In step 902, the group setting information entered by the administrator 160 is acquired from the application system 161.

[0100] In step 903, it is determined whether the value of the lower limit of the number of members of a group entered as group setting information is equal to or less than the number of members of the participating team also selected as group setting information. If it is equal to or less than the number of members, the process proceeds to step 904, and if it is greater than the number of members, a registration error is detected and the process returns to step 901. Note that if multiple participating teams are selected, the number of members of the team with the fewest number of members is used as the criterion for determination.

[0101] In step 904, the group setting information is saved and registered in the group setting table 154. In step 905, it is determined whether the administrator 160 uploaded the external relationship data 180 when setting up the group, and if uploaded, the process proceeds to step 906. In step 906, the external relationship data 180 is saved in the external relationship table 157, and its ID is saved (e.g., additionally registered) in the group setting table 154.

[0102] It is also possible to display already registered group settings on the screen of the application system 161, and allow the administrator 160 to select one of the settings and edit or delete it.

[0103] The group setting table 154 in FIG. 10 is a table that is registered by the group setting receiving unit 140 and that manages information on group settings.

[0104] The group setting ID 1001 is information used to uniquely identify a group setting within the management server 130. The data stored in the group setting ID 1001 can be omitted by specifying any one of the columns used in this table or a combination of multiple columns. The management server 130 may also automatically assign an ascending identification number to each group setting as an identifier.

[0105] The tenant ID 1002 stores the ID of the tenant that is the target of the group setting. The team ID 1003 stores the ID of the team that is the target of the group setting. There may be multiple team IDs. The start date 1004 stores the start date of the first course of the group setting. The one course period 1005 stores the number of days per course of the group setting as a fixed period. The number of courses 1006 stores the number of times the course of the group setting is repeated. The group number minimum 1007 stores the minimum number of people set as a standard value for the number of people belonging to each group of the group setting. The reminder use 1008 stores a flag value indicating whether reminders are used in the group setting. The delivery time 1009 stores the scheduled delivery time of reminder emails, etc., in the group setting. The external relationship ID 1010 is an ID for uniquely identifying external relationship data used in the group setting, and is used as a key when linking information with the external relationship table 157.

[0106] 11 shows an example of the data format of the external relationship data 180 uploaded in the external relationship data setting 838 on the application screen 800. Here, the explanation will be given using data based on the sending and receiving history of e-mails and chats.

[0107] Date 1101 indicates the date the email or chat was sent. Sending user 1102 is the email address that sent the email or chat, and receiving user 1103 is the email address that sent the email or chat. By matching each with the email address 404 stored in user table 150, it is possible to link them to user IDs within the communication promotion system.

[0108] Type 1104 is information that indicates the relationship between users and the content of communication, and in the example of Fig. 11, it indicates which records are email histories and which records are chat histories. Action points 1105 are an example of points that can be assigned to type 1104, and may be set arbitrarily by the administrator 160 or the like. By tallying up action points 1105 over a certain period of time, the relationship between users outside the system and the amount of communication between users can be quantified, and this can be used for group allocation processing.

[0109] 12 is a flowchart showing an example of processing of the group management unit 141 performed by the control unit 131 in the management server 130 at the timing of the start date of each course. This processing is executed in steps 308 and 318 in FIG.

[0110] The group management unit 141 executes a process of allocating target users to groups based on the information registered in the group setting table 154 .

[0111] In step 1201, the number of groups for the course and the course end date are calculated based on the target group settings registered in group setting table 154. As explained in FIG. 2, the number of groups is determined so that the number of members in each group is equal to or greater than the lower limit of the number of group members and so that the number of groups is maximized. One possible calculation method is to add up the number of members in the target team and use the integer part when dividing this by the lower limit of the number of group members. For example, if the team consists of 8 people and the lower limit of the number of group members is 3, then 8 / 3 is approximately 2.66, and the integer part, 2, is the number of groups.

[0112] In addition, because the number of groups is calculated based on the number of members of the target team as of the start date of the cool period, it can flexibly accommodate last-minute changes in the number of members of the target team. In the previous example, if the number of team members increases by one to nine, the number of groups will be three, since 9 / 3 = 3. Conversely, if the number of team members decreases to five, the number of groups will be one, since 5 / 3 ≒ 1.66.

[0113] In this way, even if a target user is added or removed after the administrator 160 has registered the group settings, the management server 130 can automatically handle the situation. Note that if the number of group members is calculated to be 0 as a result of a decrease in the number of team members, the group allocation process may be terminated at that point and a notification may be displayed on the screen of the application system 161.

[0114] The cool end date can be calculated using the value of one cool period stored in the group setting table 154. After the number of groups and the cool end date are calculated, they are stored in the group table 155.

[0115] In steps 1202, 1203, and 1204, a relationship matrix is ​​calculated for the target users to be divided into groups, the relationship matrix representing the relationships between the target users during a specific period.

[0116] A relationship matrix is ​​an example of user relationship information that represents the relationships between users. A relationship matrix is ​​an n x n matrix that expresses the relationship values ​​between each pair of n target users. Target users are assigned to each row and each column in order. For example, if the relationship value between user #i and user #j is m, then m is entered as the element in row i and column j of the relationship matrix.

[0117] The relationship matrix is ​​calculated in two types: an internal relationship matrix M1 that represents the relationships between target users within the communication promotion system, and an external relationship matrix M2 that represents the relationships between target users outside the system, and the combined (for example, added) matrix is ​​used to create the overall relationship matrix.

[0118] The internal relationship matrix M1 is generated by aggregating the user-to-user performance within the system for a target user group during the validity period T1. The user performance may be, for example, the number of times "likes" or "comments" have been sent, or the number of times users have belonged to the same group in the past, and is obtained by acquiring and aggregating information on the two target users from the behavior history table 153 or the group member table 156. The more such performances there are between two users, the stronger the relationship between them can be considered to be.

[0119] In step 1202, for all pairwise combinations of the target users, the inter-user performance during the valid period T1 is tallied and summed to calculate the relationship value between the users. Note that the inter-user performance may be weighted according to type, and for example, by preparing a correspondence table 1210, the relationship value may be the sum of points defined for each behavior rather than the frequency of the behavior.

[0120] The correspondence table 1210 may be automatically defined and maintained in advance within the system, or may be defined or changed by the administrator 160. The validity period T1 may be specified in days, such as "the last 7 days," or, for group allocation for the second or subsequent cycles, the previous cycle period may be specified. By utilizing the internal relationship matrix M1 generated as described above, it becomes possible to determine the next group allocation taking into account factors such as the frequency of communication between users in the immediately preceding period.

[0121] The external relationship matrix M2 is generated by aggregating data representing the relationships outside the system for the target user group during the validity period T2. If the administrator 160 uploads external relationship data 180 when registering group settings, calculations can be performed based on that information. In step 1203, the total values ​​of the action points 1105 in the external relationship table 157 for all pairwise combinations of the target user group during the validity period T2 may be aggregated.

[0122] The validity period T2 may be specified by a specific date, or by the number of days, such as "the most recent 30 days of history." By utilizing the external relationship matrix M2 generated as described above, even when a target user group is using the communication promotion system for the first time, it is possible to infer the relationships already established between users from data such as email sending and receiving history and face-to-face history, and use this information to help determine group allocation.

[0123] The overall relationship matrix is ​​a combination (for example, addition) of the internal relationship matrix M1 and the external relationship matrix M2. In step 1204, the elements of M1 and M2 are added together and output as the overall relationship matrix. Note that the calculation method is not limited to addition, and weighted sums or inputs into a specific formula may also be used for calculation.

[0124] For example, the comprehensive relationship matrix is ​​expressed in a format such as relationship value table 1211. #1 to #6 represent target users, and the other elements represent the relationship values ​​between each pair of target users. Note that in the representation in relationship value table 1211, element values ​​of 0 are omitted from the display. By utilizing the comprehensive relationship matrix generated as described above, it becomes possible to determine group allocation by comprehensively considering relationships both inside and outside the system.

[0125] An example of a specific process for allocating the target users into groups will be described below in steps 1205 to 1209. However, the allocation method is not limited to this.

[0126] Steps 1205 to 1208 are repeated to create multiple group allocation patterns.

[0127] In step 1206, users are selected one by one from the target user group and randomly assigned to one of the groups created in step 1201 that has the smallest number of members. By assigning all users, it is possible to determine the member composition while minimizing the variation in the number of members in each group. The group assignment at this stage is stored in memory as one of the patterns, and is not yet officially adopted and stored in the group member table 156.

[0128] In step 1207, the allocation is evaluated based on the overall relationship matrix generated in step 1205 and the group allocation pattern generated in step 1206. An example will be given of allocation pattern 1212 in Fig. 12. In allocation pattern 1212, users #1, #2, and #6 are allocated to the same group 1, while users #3, #4, and #5 are allocated to the other group 2. In this state, this allocation pattern is evaluated based on a certain policy, and an evaluation value is output.

[0129] For example, when performing an evaluation aimed at eliminating communication bias by periodically reassigning groups, it is desirable to evaluate as a good assignment a pattern in which users with low relationship values ​​are assigned to the same group as much as possible.A simple method is to count the number of pairs of two people belonging to the same group whose relationship value is below a threshold and use this as an evaluation value, which makes it possible to evaluate whether users who do not communicate much are assigned to the same group.

[0130] 12, users whose relationship value is equal to or greater than a threshold are linked together. Under this condition, (#1, #6), (#2, #6), (#3, #4), (#3, #5), and (#4, #5) are not linked together, and the number of combinations (5), which is less than the threshold, can be used as the evaluation value.

[0131] The above steps 1206 and 1207 are repeated N times (where N is an integer equal to or greater than 1, and preferably equal to or greater than 2), and N combinations of allocation patterns and evaluation values ​​are output. In step 1209, the allocation pattern with the maximum evaluation value is adopted, and the group allocation is stored in group member table 156.

[0132] In this way, the management server 130 acquires the relationship matrix (user relationship information), and the group generation process is executed based on the acquired relationship matrix. In particular, by going through the processes from step 1205 to step 1209 as described above, users who do not communicate much can be preferentially assigned to the same group, and imbalances in communication within the organization can be efficiently eliminated.

[0133] However, in step 1207, group allocation may be performed using other methods. For example, instead of counting the number of combinations whose relationship value is less than a threshold, the relationship values ​​themselves may be summed within each group, and the smallest one may be adopted by comparing them for each allocation pattern. Furthermore, in addition to evaluation indices aimed at eliminating communication bias, evaluation indices may be added from new perspectives. For example, the number of combinations of users who are in the same group this time as in the previous time may be counted as an evaluation index, and an allocation pattern that reduces this number may be adopted.

[0134] Alternatively, an index may be provided that evaluates allocation that increases the number of connection triangles between users. For example, in the example of allocation pattern 1212, the direct relationship value between users #1 and #6 is low, but both users have a high relationship value with user #5, and it can be said that they have mutual acquaintances. In such a case, it may be considered that users #1 and #6 are more likely to communicate with each other than usual, and an index may be provided that highly evaluates the situation where users #1 and #6 are in the same group. When there are multiple evaluation indexes as described above, they may be treated as an overall evaluation index by ultimately adding them up, for example.

[0135] In summary, the group management unit 141 determines the number of groups for each course based on the number of team members as of the start date of that course, allowing for flexible response to increases or decreases in the number of team members. Furthermore, by taking into account the relationships between users based on the user's behavioral history and even estimating relationships outside the system using external data, it is possible to determine new group allocations based on the amount of communication to date. When allocating groups, for example, by prioritizing users who communicate less with each other and assigning them to the same group, it is possible to efficiently eliminate communication imbalances within an organization.

[0136] The group table 155 in FIG. 13 is a table registered by the group management unit 141 for managing the number of groups and the cool period for each group setting.

[0137] The group ID 1301 is information used to uniquely identify a group within the management server 130. The data stored in the group ID 1301 can be omitted by specifying any one of the columns used in this table or a combination of multiple columns. The management server 130 may also automatically assign an ascending identification number to each group as an identifier.

[0138] The group setting ID 1302 is an ID used to uniquely identify the group setting that is the setting source of the target group, and corresponds to the group setting ID 1001 in the group setting table 154 .

[0139] The team ID 1303 is an ID used to uniquely identify the team to which the group of users to be assigned to the target group belongs. The season 1304 indicates the season number in which the target group will be active. The start date 1305 indicates the start date of the period in which the target group will be active. The end date 1306 indicates the end date of the period in which the target group will be active.

[0140] 13, for a group with a group setting ID of Gr_conf#1, two groups Gr#1 and Gr#2 are generated in the first season. Similarly, Gr#3 and Gr#4 are generated in the second season, and Gr#5 and Gr#6 are generated in the third season.

[0141] The group member table 156 in FIG. 14 is a table registered by the group management unit 141 and used to manage the member configuration of each group.

[0142] The group member ID 1401 is information used to uniquely identify a group member within the management server 130. The data stored in the group member ID 1401 can be omitted by specifying any one of the columns used in this table or a combination of multiple columns. The management server 130 may also automatically assign an ascending identification number to each group member as an identifier.

[0143] The group ID 1402 is an ID used to uniquely identify the group to which the target group member belongs, and corresponds to the group ID 1301 in the group table 155 .

[0144] The user ID 1403 is an ID used to uniquely identify the target group member, and corresponds to the user ID 401 in the user table 150 .

[0145] 14, three users belong to the group with group ID Gr#1 as group members. By linking group ID 1402 with group ID 1301 in group table 155, information on the member composition and activity period of each group can be obtained.

[0146] 15 is a flowchart showing an example of processing performed by the UI providing unit 142 of the control unit 131 of the management server 130. This processing is executed from step 311 to step 313 in FIG.

[0147] In response to a screen display request from a client, the UI providing unit 142 determines the group to which the user belongs in the course, and displays a timeline and comments dedicated to the group.

[0148] In step 1501, the management server 130 receives a screen display request sent from the client 111. The screen display request is associated with one user ID (for example, the user ID of the user who performed the login process on the client 111).

[0149] In step 1502, the management server 130 identifies the group to which the user ID belongs based on the received user ID. For example, the management server 130 collates the user ID received in step 1501 with the group member table 156 to obtain the group ID to which the user belongs.

[0150] In step 1503, the posted data of all users belonging to the group identified in step 1502 is obtained by filtering from the posting history table 152. In step 1504, the posted data obtained in step 1503 is displayed on the group-specific timeline of the client 111.

[0151] In this way, the client 111 displays a timeline according to the group and user ID. In particular, in this embodiment, the client 111 displays a different timeline according to the group. This promotes efficient communication that is specialized for a limited group.

[0152] In step 1505, it is determined based on the behavior history table 153 whether the person with the user ID received in step 1501 has commented on each post displayed in step 1503. If there are any posts for which a comment has not been made, the process proceeds to step 1506, where a comment input field (entry area) dedicated to that user is displayed for the posts for which a comment has not been made and displayed on the timeline.

[0153] The posted data displayed in step 1504 may be displayed by narrowing the target period to data posted during the relevant season. Also, the posted data displayed in step 1506, which displays a user-specific comment input field, may be displayed by narrowing the target period to data posted during the relevant season.

[0154] FIG. 16 is an example of a GUI (client screen) showing an example of a group-dedicated timeline and a user-dedicated comment input field displayed on the screen of the client 111. In FIG.

[0155] On this screen, the user 110 posts his / her own posts or comments on posts by others. Part of this screen is displayed by the UI providing unit 142 after going through the steps described with reference to FIG.

[0156] The client screen 1600 is an example of a screen displayed after user authentication, and includes a login user name 1601, a post button 1602, and a timeline 1603. The login user name 1601 displays the user name associated with the user ID that performed the user authentication, and is information that represents the user. The post button 1602 is a button that the logged-in user 110 presses when using the post function 117, and when pressed, a post creation screen or the like is displayed.

[0157] The timeline 1603 displays data posted by a user (the logged-in user or another user). The timeline 1603 includes one or more posts 1606. For each post, the timeline 1603 also includes the poster's name (an example of information representing the user), the post content, the time of posting, the number of "like" actions for that post, and the number of comments for that post. If there are comments, the timeline 1603 also includes, for each comment, the commenter's name (an example of information representing the user) and the comment content. Through this timeline 1603, the user 110 can view posts by other users and perform user-to-user actions such as "like" actions and "comment" actions.

[0158] Specific processes for implementing "posting," "likes," "comments," etc. can be designed appropriately by a person skilled in the art based on known SNS technologies, etc. As an example, the client 111 accepts input of text as the content of a post and transmits the information shown in Fig. 6 (excluding the post history ID 601) to the management server 130. Here, as shown in Fig. 6, the post is associated with a user ID.

[0159] The management server 130 accepts this information and stores it with a posting history ID 601. The management server 130 also transmits the content of this post in response to a screen display request from the client, and each user's client 111 displays the content of the post on a timeline 1603. In this way, the management server 130 accepts posts associated with a user ID, generates a timeline based on this post, and displays it on the client 111. In this way, communication is promoted by each user's posts being reflected and displayed on a timeline.

[0160] In this way, when content posted by other users is displayed on the screen of client 111, if a user feels a positive impression of the post, the user can input a positive impression into client 111 by performing a predetermined "like" action (for example, clicking on a predetermined area). In response to the "like" action, client 111 transmits the information shown in FIG. 7 (excluding action history ID 701) to management server 130. Management server 130 stores this information with the action history ID 701 attached.

[0161] Furthermore, when transmitting the content of a post to the client 111, the management server 130 refers to the action history table 153, acquires information on "Like" actions for the post, calculates the total number, and transmits this information along with the content of the post. Upon receiving this, the client 111 displays the total number of "Like" actions in association with the post when displaying the post on the timeline 1603.

[0162] The group tab 1604 is a button for switching the display range of the timeline 1603, and is used to switch to a group-only timeline that displays only posts from members of the group to which the user 110 belongs.

[0163] When the group tab 1604 is selected, posts 1606 displayed on the timeline and a user-specific comment input field 1608 are provided by the UI providing unit 142. Also, in relation to the comment input field 1608 (immediately above the comment input field 1608 in the example of FIG. 16 ), the name of the user using the client 111 (the same as the login user name 1601) is displayed. In this way, the client 111 displays, together with the timeline 1603, information (name) representing the user associated with the user ID and the comment input field 1608 for accepting comment input.

[0164] The "comment" action can also be designed in the same way as the above-mentioned "like" action. However, in the "comment" action, a user can use the comment input field 1608 to input a sentence or a message as the content of the comment on another user's post. In response to the comment action, the client 111 transmits the information shown in FIG. 7 (excluding the action history ID 701) to the management server 130. The management server 130 stores this information with the action history ID 701 attached. Furthermore, when transmitting the content of the post to the client 111, the management server 130 refers to the action history table 153, acquires information about the comment on the post, and transmits it together with the content of the post. Upon receiving this, the client 111 displays the content of the comment in association with the post when displaying the post on the timeline 1603.

[0165] Also, a message prompting the user to enter a comment may be displayed in relation to the comment input field 1608. For example, if the user has not yet entered a comment for the post (i.e., if a comment associated with the user ID associated with the screen display request has not been entered), the client 111 displays a message prompting the user to enter a comment in relation to the comment input field 1608. In the example of FIG. 16, this message corresponds to the message "<Send your support and thanks>". By displaying such a message, communication between users can be promoted.

[0166] In addition to the group tab 1604, there may be a tab for switching to a timeline where posts by users who belong to the team to which the user 110 belongs can be viewed, or a tab for switching to a timeline where posts by users who belong to the tenant to which the user 110 belongs can be viewed. Furthermore, when the user 110 does not belong to any group, the group tab 1604 may be made unselectable or hidden.

[0167] The group selection pull-down 1605 is used by the user 110 to filter the posted data displayed on the group-specific timeline. For example, if the user 110 belongs to multiple teams and group settings are registered for each team, the user 110 will belong to multiple groups. Therefore, if the user wants to view only posts from a specific group, the user 110 selects a pull-down that displays the team name and cool period to display posts from that group.

[0168] The post 1606 may include the name of the user who posted it, information about the timing of posting, and the post content text. The posts 1606 are displayed in the timeline 1603 in order of most recent posting date and time. The comments 1607 display the content of comments made by other users in response to the post.

[0169] The user-only comment input field 1608 is an item displayed by the UI providing unit 142, and is displayed when the user 110 has not yet commented on a post by a group member. As an example, the name of the user 110 is displayed in advance, and a message encouraging the user 110 to comment is displayed in the area where the user's 110 comment is displayed.

[0170] In this embodiment, whether to display the comment input field 1608 is dynamically determined. If the user 110 has already entered a comment for the post (i.e., if a comment associated with the user ID associated with the screen display request has already been entered), the client 111 does not display the comment input field 1608. In this way, communication can be promoted efficiently only when a comment has not been entered.

[0171] In addition, by displaying a timeline dedicated to the group to which the user belongs, users can easily recognize the target users to whom they should send comments and can easily view the posts of the target users. Furthermore, if a comment has not been made, the comment input field dedicated to the user is highlighted, making it easier for the user to recognize that they have not made a comment, which is expected to encourage them to write comments.

[0172] 17 shows an application screen that is an example of a GUI for checking the group setting status in the application system 161. On this screen, the administrator 160 checks a list of group settings set in the tenant that he or she manages and the group status for each setting.

[0173] The main screen 1700 is made up of a new creation button 1710, a group setting list 1720, and a group detailed information box 1730.

[0174] The new creation button 1710 is a button that the administrator 160 presses when creating a new group setting, and when this button is pressed, the screen switches to the main screen 820 of FIG.

[0175] The group setting list 1720 displays a list of created group settings, allowing the setting contents to be confirmed. For example, the ID of the corresponding group setting, the number of participants, the start date, and the end date are displayed. When the management server 130 receives a screen display request from the application system 161, the group status providing unit 145 acquires and displays information from the group setting table 154, etc. Each group setting may be edited or deleted.

[0176] The detail confirmation button 1721 is a button for checking the implementation status of the group settings, and by selecting any of the group settings, a group detailed information box 1730 is displayed.

[0177] The group detail information box 1730 has a group status list 1731 and cool information 1732. The group status list 1731 displays information such as the member composition and number of comments for each group in any group setting. In the group status list 1731, the management server 130 displays, for each group, the total number of posts for that group (more precisely, posts related to user IDs belonging to that group) and the total number of comments on those posts. The total number of "likes" for those posts may also be displayed.

[0178] When the management server 130 receives a screen display request from the application system 161, the group status providing unit 145 aggregates and displays information from the group member table 156, the behavior history table 153, etc. The season information 1732 indicates the season that is the target period for the information displayed in the group status list 1731. It is also possible to select another season, and the information displayed in the group status list 1731 may be switched accordingly.

[0179] By displaying this information on screen, administrators can review group settings and understand the degree to which communication is being promoted in each group.

[0180] 18 shows an example of an email delivered to users belonging to a group in each course. Email is delivered when email is selected in the reminder usage setting 836 in FIG.

[0181] The member notification email 1800 shown in Figure 18(a) is an example of an email that notifies the members of each group to the users who belong to that group after group allocation has been performed. This email is delivered in step 309 of Figure 3, and the email management unit 146 obtains group member information for that group based on the information in the group table 155 and the group member table 156. For each group, the email management unit 146 sends information identifying the users associated with each user ID belonging to that group (for example, their names) by email to the email addresses associated with each user ID belonging to that group.

[0182] In this way, even if a user is not logged in, the user can find out the group member composition for that course on the start date of the course or other occasion, and can be made aware of the need to communicate with group members.

[0183] 18(b) describes the posting status of members of the group to which the user belongs. This is an e-mail delivered in step 316 of FIG. 3, and the mail management unit 146 acquires the posting information of the group members based on the information in the group member table 156 and the posting history table 152.

[0184] The posted email body 1812 may contain different text depending on whether the destination user 1811 or group members have recently posted. For example, the email management unit 146 sends, for each group, information indicating whether posts associated with each user ID belonging to the group have been made within a certain period of time using an email to the email addresses associated with each user ID belonging to the group. This "within a certain period of time" may mean, for example, from the time the group creation process is performed until the current time. The example in FIG. 18(b) indicates that Takahashi Shiro has not yet posted, while Tanaka Hanako has already posted. This makes it possible to make users who have not yet posted aware of their unposted status and encourage them to post.

[0185] Furthermore, if the destination user 1811 has not yet posted, a message encouraging the destination user 1811 to post may be included in the posted email body 1812, or if the group members have not yet posted, a message requesting the group members to contact them. In this way, even if the user is not logged in, the user can know the posting status of group members, making it easier for the user to recognize if they have forgotten to comment, and promoting communication.

[0186] As described above, based on the settings registered by the administrator, users are automatically assigned to small groups, and they can send and receive comments to each other through a dedicated group timeline. By belonging to small groups, each user can expect to receive a certain number of comments from others, making it less likely that comments will be concentrated on a specific user. In addition, since the recipients of comments are automatically determined and the number of recipients is limited, the burden on the sender of comments is reduced. Furthermore, by prioritizing the reassignment of users with weak relationships to the same group based on information on the amount of communication between each user recently, it is possible to efficiently eliminate communication imbalances within an organization and promote cross-sectional communication.

[0187] The relationship between the hardware and functions of each computer in the above-described first embodiment can be changed as appropriate. For example, a person skilled in the art can transfer any of the functional units shown in Fig. 1 to any of the computers shown in Fig. 1 or to another computer not shown as appropriate. [Explanation of symbols]

[0188] 110...User 114...Control unit (processing unit) 115...Storage section 120...User 131...control unit (processing unit) 132...Storage section 164...Control unit (processing unit) 165...Storage section 200...Target user group (multiple users) 201...Group 202...Group 210...Minimum number of people (standard value) 220...Group allocation process (group generation process) 221...Group allocation process (group generation process) 230...First course (for a certain period) 231...2nd course (for a certain period) 308...Step (Group generation process) 310...Step (screen display request) 401...User ID 402...User name (information representing the user) 403...Affiliated tenant (company) 404...Email address 602...User ID 702...User ID 833...1 cool period setting (fixed period) 835...Minimum group size (standard value) 1005...1 cool period (fixed period) 1007...Minimum number of people in a group (standard value) 1211...Relationship value table (user relationship information) 1403...User ID 1601...Login user name (information representing the user) 1603…Timeline 1606...Posts 1607...Comments 1608...Comment input field 1800...Member notification email (email) 1810...Reminder email (email)

Claims

[Claim 1] An information processing system having a processing unit and a storage unit, the storage unit stores a plurality of user IDs each identifying a plurality of users; The processing unit performing a group generation process in which the plurality of user IDs are assigned to groups based on a predetermined reference value; Displaying a timeline according to the group and the user ID; displaying, together with the timeline, information indicating a user associated with the user ID and a comment input field for accepting input of a comment; Information processing system.

Images