Information sharing system, processing execution method, and program

Abstract

To improve convenience for a user in an information sharing service.SOLUTION: An information sharing system (1) has a plurality of functions regarding an information sharing service for sharing information. A usage status acquisition unit (102) acquires, for each function, usage status of each of a plurality of users. A processing execution unit (103) executes, for each function, predetermined processing regarding the function based on the usage status of the function.SELECTED DRAWING: Figure 3

Description

Technical Field

[0001] The present disclosure relates to an information sharing system, a processing execution method, and a program.

Background Art

[0002] Conventionally, information sharing services for sharing information among multiple users have been known. For example, in an information sharing service, various functions such as a schedule sharing function, a file sharing function, a database sharing function, or a communication function are provided. If the usage status by the user can be obtained for each function provided by the information sharing service, for example, it becomes easier to consider deleting or modifying the function, so it is considered that the convenience of the user is enhanced. The usage status for each function is considered to be useful for various other purposes.

[0003] For example, Patent Document 1 describes a technique for collecting usage status such as the usage frequency or usage time zone of an application installed on a user terminal. For example, Patent Document 2 describes a technique for obtaining information such as the start time, end time, or start location of an application as the usage status of an application installed on a user terminal and analyzing which application is frequently used.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Patent Document 2

Summary of the Invention

Problems to be Solved by the Invention

[0005] However, the technologies described in Patent Documents 1 and 2 only collect usage data for the entire service, since one application corresponds to one service. Patent Documents 1 and 2 do not describe anything about collecting usage data for each function provided in a particular service. Therefore, even if the technologies described in Patent Documents 1 and 2 are applied to an information sharing service, it may be possible to collect usage data for the entire information sharing service, but it may not be possible to collect usage data for each function provided in the information sharing service.

[0006] One of the purposes of this disclosure is to improve user convenience in information sharing services. [Means for solving the problem]

[0007] An information sharing system relating to one aspect of this disclosure is an information sharing system having multiple functions relating to an information sharing service for sharing information, wherein each of the functions includes a usage status acquisition unit that acquires the usage status of each of a plurality of users, and a processing execution unit that performs predetermined processing relating to each of the functions based on the usage status of the function. [Effects of the Invention]

[0008] This disclosure will improve user convenience in information sharing services. [Brief explanation of the drawing]

[0009] [Figure 1] This figure shows an example of the overall configuration of an information sharing system. [Figure 2] This figure shows an example of a portal screen. [Figure 3] This diagram shows the functional blocks implemented in the information sharing system. [Figure 4] This figure shows an example of a user database. [Figure 5] This is a diagram showing an example of a usage database. [Figure 6] This figure shows an example of a usage status screen. [Figure 7] This figure shows an example of a process performed in an information sharing system. [Figure 8] This diagram shows the functional blocks in a modified example. [Figure 9] This figure shows an example of the usage screen for modified example 2. [Figure 10] This figure shows an example of an application database. [Figure 11] This figure shows an example of the portal screen in modified example 4. [Modes for carrying out the invention]

[0010] [1. Overall Configuration of the Information Sharing System] An example of an embodiment of the information sharing system relating to this disclosure will be described. Figure 1 is a diagram showing an example of the overall configuration of the information sharing system. For example, the information sharing system 1 includes a server 10 and a user terminal 20. Each of the server 10 and the user terminal 20 is connected to a network N such as the Internet or a LAN.

[0011] Server 10 is a server computer. The control unit 11 includes at least one processor. The storage unit 12 includes volatile memory such as RAM and non-volatile memory such as flash memory. The communication unit 13 includes at least one of a communication interface for wired communication and a communication interface for wireless communication.

[0012] The user terminal 20 is the user's computer. For example, the user terminal 20 is a personal computer, tablet, smartphone, or wearable device. The hardware configurations of the control unit 21, storage unit 22, and communication unit 23 may be the same as those of the control unit 11, storage unit 12, and communication unit 13, respectively. The operation unit 24 is an input device such as a mouse, touch panel, or keyboard. The display unit 25 is a liquid crystal display or an organic EL display.

[0013] Note that the programs stored in the storage units 12 and 22 may be supplied via the network N. The hardware configurations of each of the server 10 and the user terminal 20 are not limited to the example of FIG. 1. For example, a reading unit (for example, an optical disk drive or a memory card slot) that reads a computer-readable information storage medium, or an input / output unit (for example, a USB terminal) for directly connecting to an external device may be included. In this case, the program stored in the information storage medium may be supplied via the reading unit or the input / output unit.

[0014] Also, the information sharing system 1 may include at least one computer and is not limited to the example of FIG. 1. For example, in reality, since there are a large number of users, a large number of user terminals 20 may be included in the information sharing system 1. For example, the user terminal 20 may exist outside the information sharing system 1. In this case, the information sharing system 1 may include only the server 10 without including the user terminal 20. The information sharing system 1 may include the server 10 and other computers other than the user terminal 20.

[0015] [2. Overview of Information Sharing System] The information sharing system 1 has a plurality of functions related to an information sharing service for sharing information. Sharing information means providing information registered by a certain user to other users. Communicating among a plurality of users also corresponds to sharing information. The information to be shared may be of any type, for example, text, table, figure, e-mail, image data, document data, video data, audio data, or other data.

[0016] A function is an element of the information sharing system 1 that can be used by a user. A function can also be said to be a means or tool for information sharing. For each function, the type of information to be shared is different. In the information sharing system 1, since information sharing becomes possible by executing various programs, an individual program or a collection of codes included in an individual program corresponds to a function.

[0017] For example, suppose a user has access to three functions of an information sharing service: functions A, B, and C. In this case, there are programs PA for function A, PB for function B, and PC for function C in the information sharing system 1. Therefore, programs PA, PB, and PC can each be considered functions A, B, and C themselves. If programs PA, PB, and PC are combined into a single program, then within that single program, there are sets of code corresponding to function A, sets of code corresponding to function B, and sets of code corresponding to function C. Each of these sets of code can also be considered functions A, B, and C themselves.

[0018] The functions provided by the information sharing service may be various publicly known functions, such as a schedule sharing function for sharing schedules, a communication function for communicating via chat or web conferencing, a file sharing function for sharing files, or a database sharing function for sharing databases. The functions may also be provided using applications from other businesses different from the provider of the information sharing service.

[0019] In this embodiment, we take the example of a case where an information sharing service using cloud-based groupware is provided to the user, but the information sharing service may be of any type and is not limited to the example of this embodiment. For example, the information sharing service may be a service using on-premise groupware that is not cloud-based, or it may be a cloud service of a type that is not called groupware.

[0020] For example, users share information within the group to which they belong. A group is a collection of multiple users who share information. For example, an organization such as a company or government agency is equivalent to a group. A department or team within an organization is also equivalent to a group. Users may share information with other users outside their group, or they may share information with an unspecified number of other users without any particular concept of a group. For example, when a user operates the user terminal 20 and logs in to the information sharing service, the portal screen of the information sharing service is displayed on the display unit 25.

[0021] Figure 2 shows an example of a portal screen. In this embodiment, the case in which each screen is displayed on the browser of the user terminal 20 is described, but each screen may also be displayed on a program dedicated to the information sharing service (for example, a so-called smartphone app) installed on the user terminal 20. Portal screen SC1 corresponds to the top page of each group. From portal screen SC1, users can use various functions related to the information sharing service.

[0022] In this embodiment, an application is described as an example of a function. Therefore, wherever "application" is written, it can be read as "function." An application is a tool to support the user's work. An application can also be described as a business system tailored to the user's work. In this embodiment, an application with functions similar to spreadsheet software is given as an example, but various known types of applications can be used. For example, an application may have functions similar to word processing software, image editing software, or presentation software. Other functions, such as schedule management functions, may be provided as a type of application.

[0023] For example, the display area A10 of the portal screen SC1 displays a list of apps available to the user. The user can select and use any app from the display area A10. For example, if the user selects the "Invoice Management" app, a table containing various information such as the invoice management number, date, amount, and responsible person will be displayed in the display unit 25. For example, if the user selects the "Patent Management" app, a table containing various information such as the patent application number, application date, and current status will be displayed in the display unit 25.

[0024] For example, an app may include not only the records that make up a table, but also other information such as comments entered by users, reactions made by users to other users' comments, and files uploaded by users. Therefore, an app will have not only database functionality equivalent to a spreadsheet program, but also other functions such as communication capabilities. Users can use apps pre-provided by the information sharing service, or they can create and add their own apps.

[0025] Information sharing system 1 contains various applications, some of which are frequently used, while others are rarely used. Furthermore, some applications that were frequently used in the past are now rarely used. Conversely, some applications that were rarely used in the past are now frequently used. Therefore, if the usage status of each application can be obtained, it would be easier for administrators with administrative privileges to consider, for example, deleting or modifying an application, thereby improving user convenience. This point also applies to other functions besides applications.

[0026] Therefore, the information sharing system 1 of this embodiment acquires the user's usage status for each application. For example, the information sharing system 1 displays the usage status for each application on the administrator's user terminal 20. This makes it easier for the administrator to check the usage status for each application and consider various options such as deleting or modifying applications, thus increasing convenience. The details of the information sharing system 1 will be described below.

[0027] [3. Functions implemented by the information sharing system] Figure 3 shows the functional blocks implemented in the information sharing system 1.

[0028] [3-1. Functions implemented by the server] The data storage unit 100 is implemented by the storage unit 12. The service provision unit 101, the usage status acquisition unit 102, and the processing execution unit 103 are implemented by the control unit 11.

[0029] [Data Storage Unit] The data storage unit 100 stores data necessary to provide information sharing services to users. In this embodiment, a user database DB1 and a usage status database DB2 are described as examples of this data.

[0030] Figure 4 shows an example of the user database DB1. The user database DB1 is a database that stores various information about users. For example, the user database DB1 stores the group ID, group name, portal URL, user ID, password, name, and whether or not the user has administrative privileges. The group ID of a certain group stores the portal URL for that group, along with the user IDs, passwords, names, and whether or not the user has administrative privileges for the users belonging to that group.

[0031] In this embodiment, multiple users include administrator users with administrative privileges and general users without administrative privileges. The administrative privileges stored in the user database DB1 are information indicating whether or not a user is an administrator user. In this embodiment, the administrative privileges for the entire group are given as an example, but an administrator user can be any user with some kind of administrative privilege, and is not limited to the example of this embodiment. For example, an administrator user may be a user who manages individual functions, such as an application, rather than a group.

[0032] Figure 5 shows an example of the usage status database DB2. The usage status database DB2 is a database that stores the usage status of functions. For example, the usage status database DB2 stores the group ID, function ID, function name, and function usage status. In the example in Figure 5, the usage status of functions other than the application (e.g., schedule sharing function) is also shown, but a separate usage status database DB2 may exist for each function. In this embodiment, we will mainly describe the usage status of the application.

[0033] Usage status is information that shows to what extent and in what way a function, such as an application, is being used. In the example in Figure 5, the usage status shows the number of accesses, the user ID of the user who accessed the application, the date and time of access, and the specific actions taken by the user (for example, whether the user only viewed information or performed an operation to update or delete information). In this embodiment, we will mainly explain the number of accesses. Therefore, sections that explain the number of accesses can be read as usage status. The number of accesses can also be said to be the number of times a function, such as an application, has been used or displayed.

[0034] The usage status may be any information that can be obtained by the server 10 based on the information received from the user terminal 20, and is not limited to the example of this embodiment. For example, the usage status may be information such as the number of times the information (e.g., app records) has been updated, the number of comments, the number of replies to comments, the number of reactions to comments, the type of user terminal 20 (e.g., personal computer, smartphone, or tablet terminal), the access location (e.g., the location of the user terminal 20), or the display time as shown in the modified example 8 described later.

[0035] Furthermore, the usage database DB2 may store usage data for the entire past period, or it may store usage data for only a recent period. Also, while the example in Figure 5 shows that the usage data for an entire group for a certain function (for example, the total number of accesses for the entire group) is stored in the usage database DB2, the individual usage data for each user may also be stored in the usage database DB2. For example, the number of accesses made by user X to the invoice management application and the number of accesses made by another user Y to the invoice management application may be stored in the usage database DB2 as separate usage data.

[0036] Furthermore, the data stored in the data storage unit 100 is not limited to the examples above. For example, the data storage unit 100 may store a database containing information registered for each function, such as an application (actual data of information to be shared). The information stored in this database is shared among multiple users. For example, the data storage unit 100 may store APIs for providing each function to users. In this case, the API for a certain function provides this function to the user by sending the processing result in response to a request received from the user terminal 20 to the user terminal 20. When an API is prepared for each function, the API can be considered the function itself.

[0037] [Service Provision Department] The service provision unit 101 executes various processes to provide information sharing services to the user. For example, the service provision unit 101 provides the user with various functions of the information sharing service. In this embodiment, as an example of a function, an application will be mainly described, so the service provision unit 101 provides the information sharing service by displaying a screen on the user terminal 20 that shows the information registered in the application. This screen itself may be a publicly known screen, for example, a screen for displaying the information registered in the application in a tabular format.

[0038] For example, the service provider unit 101 also performs processing to provide functions other than the application. For example, in the case of the schedule sharing function, the service provider unit 101 performs the process of registering a user's schedule with the server 10, and the process of displaying a schedule screen including the said schedule on each user terminal 20 of this user and other users. The schedule screen displays the schedules of each user in the group. Each user can change other users' schedules and write comments on other users' schedules.

[0039] For example, in the case of a file sharing function, the service provider 101 performs the process of registering a file uploaded by a user to the server 10, and the process of sending (allowing download) this file to the user terminal 20 of that user and other users. Similarly, for other functions such as a database sharing function or a communication function, the service provider 101 performs the process according to the other function. The service provider 101 changes the contents of the data storage unit 100 as needed.

[0040] In this embodiment, when a user uses a certain function, the service provision unit 101 updates the usage status of that function, which is stored in the usage status database DB2. For example, when a user uses a certain application, the service provision unit 101 increases the number of accesses associated with the function ID of that application. For example, when an application is provided on a browser, a URL for displaying the application's screen is defined for each application. Therefore, when an access occurs to the URL of a certain application, the service provision unit 101 determines that the application has been used and increases the number of accesses.

[0041] For example, if the app is provided on a program dedicated to the information sharing service rather than a browser, the function ID of the app specified by the user is sent from the user terminal 20 to the server 10. When the service provision unit 101 receives the function ID from the user terminal 20, it determines that the app with this function ID has been used and increases the access count. If the same user uses the app multiple times in a single day, the service provision unit 101 may increase the access count each time, or it may increase the access count only once.

[0042] Similarly, if information other than the number of accesses corresponds to usage status, the service provision unit 101 should update the usage status in the usage status database DB2 based on the information received from the user terminal 20. For example, the service provision unit 101 may store the user ID of the user who accessed the app, the date and time of access to the app, and the specific details of the operation as usage status in the usage status database DB2. Similarly, if other functions other than the app are used, the service provision unit 101 should update the usage status in the usage status database DB2 each time the other function is used.

[0043] [Usage Status Acquisition Unit] The usage status acquisition unit 102 acquires the usage status of each of multiple users for each function. In this embodiment, since the usage status is stored in the usage status database DB2, the usage status acquisition unit 102 refers to the usage status database DB2 and acquires the usage status for each function. In this embodiment, the usage status acquisition unit 102 acquires the number of accesses to the function as the usage status of the function.

[0044] Furthermore, if the usage status is stored in a database other than the usage status database DB2, the usage status acquisition unit 102 may refer to the other database and acquire the usage status for each function. Instead of the usage status itself being stored in a database, the usage status acquisition unit 102 may acquire the usage status by aggregating the user's activity history in the information sharing service on the spot. In this case, it is assumed that the user's activity history is stored in the user database DB1 or another database. Moreover, if the usage status is stored on the user terminal 20 or another computer instead of the server 10, the usage status acquisition unit 102 may acquire the usage status from the user terminal 20 or another computer.

[0045] In this embodiment, each of the multiple applications, which are examples of functionality, is added by any of the multiple users. Addition means that a new function becomes available. Recording data for the new function on the server 10 is equivalent to adding. For example, when a user logs into the information sharing service and performs configuration work to add an application, the application is added based on that configuration work. Applications may be added by known processes, for example, when configuration work is performed such as setting the application name, the table layout including the number and names of fields, the format of the data that can be entered, and whether or not comments can be entered for the application, the application is added based on that configuration work.

[0046] For example, when an app is added, data corresponding to the app is generated and recorded in the data storage unit 100. The program required for the app is also generated and recorded in the data storage unit 100. Adding an app does not have to be done while logged into the information sharing service; the user may add apps in advance by performing offline work using an app addition tool installed on the user terminal 20. In this case, the user may upload the apps stored on the user terminal 20 to the server 10.

[0047] For example, the usage status acquisition unit 102 acquires the usage status of apps added by any of multiple users. Users who can add apps may be users with group management privileges, or users without any particular management privileges. App management privileges are granted to the user who added the app. The usage status database DB2 stores not only the usage status of apps added by users themselves, but also the usage status of apps pre-provided by the information sharing service, so the usage status acquisition unit 102 acquires the usage status of these apps as well.

[0048] In addition, other functions besides the app may be added by the user. For example, a user may be able to add a schedule sharing function themselves. In this case, the user can specify the screen layout for schedule sharing or add macros to be executed for schedule sharing. The data of the schedule sharing function added by the user is recorded in the data storage unit 100. Other functions may also be added by the user themselves in a similar manner. Functions may be added using plugins.

[0049] [Processing Execution Unit] The processing execution unit 103 executes predetermined processing for each function based on the usage status of that function. In this embodiment, the number of accesses corresponds to the usage status, so the processing execution unit 103 executes predetermined processing based on the number of accesses to the function. In this embodiment, since users can add apps, which are an example of a function, the processing execution unit 103 executes predetermined processing based on the number of accesses to apps added by any of the multiple users.

[0050] The predetermined process is a process executed based on the usage status acquired by the usage status acquisition unit 102. The predetermined process can be any predetermined process, and it can be any process that is appropriate to the purpose for which the usage status was acquired. In this embodiment, the processing execution unit 103 executes a usage status display process to display the usage status of the function on the user terminal 20 as the predetermined process. Therefore, the section describing the usage status display process can be read as the predetermined process. Other examples of the predetermined process will be described in the following modifications 1 to 6.

[0051] The usage status display process is image processing to display a usage status screen that shows the usage status of a function. In this embodiment, the processing execution unit 103 is implemented by the server 10, so the usage status display process is the process of generating display data for the usage status screen and sending it to the user terminal 20. The display data may be in any format, and when a browser is used as in this embodiment, the display data may be in HTML format. The display data may not be the entire screen, but may be data for a part of the screen, such as an image or video.

[0052] Figure 6 shows an example of a usage status screen. In this embodiment, we will explain the case in which the usage status screen SC2 of an application to be managed by an administrator user is displayed on the user terminal 20 of an administrator user who has administrative privileges. For example, when an administrator user performs an operation to display the usage status screen SC2 from the portal screen SC1 or another screen, the processing execution unit 103 displays the usage status screen SC2 shown in Figure 6 on the administrator user's user terminal 20.

[0053] For example, the usage status screen SC2 displays the function ID of an app, which is an example of a function, the app name, and the number of accesses, which is an example of usage status. The usage status screen SC2 may display the number of accesses for all apps under management, or it may display the number of accesses for only some apps. The processing execution unit 103 executes the usage status display process by generating display data for the usage status screen SC2 based on the number of accesses for the apps to be displayed on the usage status screen SC2 and sending it to the user terminal 20.

[0054] For example, the processing execution unit 103 may display a usage status screen SC2 on the user terminal 20 that shows the number of accesses per department or per user, rather than the total number of accesses for the entire group to a particular application. The usage status screen SC2 may display the number of accesses in a format other than a table, such as a bar graph or pie chart, rather than a table format as shown in Figure 6. For example, the format of the graph or table used to display the number of accesses may be switched by an administrator.

[0055] In this embodiment, the case where the usage status screen SC2 is displayed on the administrator user's terminal 20 is described, but the processing execution unit 103 may also execute a usage status display process to display the application usage status on the general user's terminal 20. In other words, the usage status screen SC2 may be displayed not only on the administrator user's terminal 20 but also on the general user's terminal 20.

[0056] For example, when the processing execution unit 103 receives a request from a general user's user terminal 20 to display the usage status screen SC2, it generates display data for the usage status screen SC2, including the number of accesses for the application to be displayed, and sends it to the user terminal 20. Similarly, if the display of other usage status information besides the number of accesses is requested, the processing execution unit 103 should generate display data for the usage status screen SC2, including the other usage status information. The same applies if the display of other functions other than applications is requested.

[0057] The usage status screen SC2 for general users and the usage status screen SC2 for administrators may be the same, or they may be partially or completely different. For example, if there are specified applications whose access counts can only be displayed on the usage status screen SC2 for administrators, the usage status screen SC2 for general users does not need to display the access counts for these applications. For example, the usage status screen SC2 for administrators may be able to display the access counts for applications over any period, while the usage status screen SC2 for general users may be restricted to displaying only the access counts for applications over a specific period. For example, the usage status screen SC2 for general users may only display their own usage status, rather than the usage status of the entire group. On the other hand, the usage status screen SC2 for administrators may allow switching between displaying various usage statuses, such as the usage status of the entire group, the usage status of each department, and the usage status of individual general users.

[0058] Furthermore, the processing execution unit 103 can similarly execute usage status display processing for functions other than applications. For example, the processing execution unit 103 may execute usage status display processing to display the number of accesses for the schedule sharing function and the number of accesses for the file sharing function on the usage status screen SC2. The usage status display processing may also be processing to display the specific actions of the user as other usage status in addition to the number of accesses. The usage status display processing only needs to be processing to display the usage status acquired by the usage status acquisition unit 102.

[0059] [3-2. Applications implemented on the user's device] The data storage unit 200 is implemented by the storage unit 22. The display control unit 201 and the operation reception unit 202 are implemented by the control unit 11.

[0060] [Data Storage Unit] The data storage unit 200 stores data necessary to provide information sharing services to users. For example, the data storage unit 200 stores a browser for displaying various screens related to the information sharing service. For example, the data storage unit 200 stores a program specifically for the information sharing service.

[0061] [Display Control Unit] The display control unit 201 displays various screens in the information sharing service on the display unit 25. For example, the display control unit 201 displays the portal screen SC1, the usage status screen SC2, or other screens on the display unit 25 based on the display data received from the server 10.

[0062] [Operation Reception Section] The operation reception unit 202 receives various operations in the information sharing service. For example, the operation reception unit 202 receives operations to access the application, operations to edit records within the application, or operations to display detailed information within the application. These operations are transmitted to the server 10 as appropriate.

[0063] [4. Processes executed by the information sharing system] Figure 7 shows an example of the processing performed by the information sharing system 1. Figure 7 primarily describes the usage status display processing, which is used to display the usage status screen SC2 on the user terminal 20 of the management user. Details of the processing for using applications and other functions are omitted in Figure 7.

[0064] As shown in Figure 7, the server 10 determines whether or not one of several functions has been used based on the information received from the user terminal 20 (S1). If it is determined that one of the functions has been used (S1:Y), the server 10 updates the usage status of the function determined to have been used in S1, which is stored in the usage status database DB2 (S2). For example, each time an application is used, the process in S2 is executed, and the number of accesses to the application increases each time. Other usage statuses besides the number of accesses are also updated. If a function other than an application is used, its usage status is also updated by the process in S2.

[0065] The administrator user's terminal 20 performs a login process with the server 10 to allow the administrator to log in to the information sharing service (S3). If the login process is successful, the user terminal 20 performs a process with the server 10 to display the portal screen SC1 (S4). When the administrator user performs an operation from the portal screen SC1 or another screen to display the usage status screen SC2, the user terminal 20 sends a request to the server 10 to display the usage status screen SC2 (S5).

[0066] When server 10 receives a request to display the usage status screen SC2 (S6), it refers to the usage status database DB2 and obtains the usage status of the function to be managed (S7). In this embodiment, the case in which all apps in the group to which the administrator user belongs are managed is described, but administrator privileges may be set for each app, and only apps for which the administrator user has administrator privileges may be managed. If the display of usage status other than the number of accesses of an app is requested, the other usage status is obtained in S7. If the display of usage status of a function other than an app is requested, the usage status of that function is also obtained in S7.

[0067] Server 10 generates display data for the usage status screen SC2 based on the number of accesses to the managed application obtained in S7 and sends it to the user terminal 20 (S8). When the user terminal 20 receives the display data for the usage status screen SC2 (S9), it displays the usage status screen SC2 on the display unit 25 based on the display data (S10), and this process ends. From here on, the management user checks the usage status screen SC2 and considers whether to delete applications that are not used often, or whether to modify applications that have been used frequently recently.

[0068] The information sharing system 1 of this embodiment performs predetermined processing for each function based on the usage status of that function. By acquiring the usage status of individual functions rather than the usage status of the entire information sharing service and performing predetermined processing, it is possible to analyze in detail to what extent and in what way each function is being used, thereby improving user convenience in the information sharing service.

[0069] Furthermore, the information sharing system 1 performs a usage status display process as a predetermined process. This makes it easier for users to check the usage status of individual functions. For example, administrators can consider whether to disable functions that are not used often, or whether to modify functions that have been used frequently recently. For example, when performing a usage status display process to show the usage status of functions on the user terminals 20 of general users, it makes it easier for general users to check the usage status of individual functions.

[0070] Furthermore, the information sharing system 1 acquires the number of accesses to a given function as a measure of its usage. By acquiring easily understandable indicators such as the number of accesses, it becomes easier to analyze how much each function is being used.

[0071] Furthermore, the information sharing system 1 acquires the usage status of features added by users. If users are allowed to add features themselves, a large number of features may be added to the information sharing service, potentially making feature management complicated. For example, it may be difficult to distinguish between frequently used features and those that are rarely used. In this respect, acquiring the usage status of each feature makes it easier to manage the numerous features.

[0072] [5. Variant] This disclosure is not limited to the embodiments described above. It may be modified as appropriate without departing from the spirit of this disclosure.

[0073] Figure 8 shows a functional block in a modified example. The search unit 104 is implemented by the control unit 11.

[0074] [5-1. Variation 1] For example, the predetermined processing performed by the processing execution unit 103 is not limited to the usage status display processing described in the embodiment. The predetermined processing can be any processing appropriate to the purpose for which the usage status was acquired. Modifications 1 to 6 describe other examples of predetermined processing. The processing execution unit 103 only needs to be capable of performing all or part of the predetermined processing described in the embodiment and modifications 1 to 6. In modification 1, an application is also described as an example of a function.

[0075] For example, the processing execution unit 103 may, as a predetermined process, execute a function deactivation process to stop an application among multiple applications whose usage by each of multiple users satisfies the first criterion. The first criterion is the condition for whether or not to execute the function deactivation process. In the modified example 1, the first criterion is given as an example where relatively low usage of the function corresponds to a relatively low criterion, but the first criterion may be other criteria. For example, the first criterion may not be relatively low usage, but rather that the user does not use it at all, the number of times the user uses it is below a threshold, or the elapsed time since the last use is greater than or equal to a predetermined time. Relatively low usage of an application means that the number of times the application is used (e.g., the number of accesses) is less than that of other applications. For example, when applications are ranked in descending order of the number of times they are used, applications ranked lower than a predetermined rank correspond to applications with relatively low usage.

[0076] The function deactivation process in Modification 1 is a process to stop the use of the application itself. When the function deactivation process is executed, all users will no longer be able to use the application. For example, the processing execution unit 103 determines, for each application, whether the usage by all users who can use the application has decreased. Low usage corresponds to the number of times the application is used (e.g., the number of accesses) being below a predetermined threshold. For example, if the number of uses in a certain first period was above the threshold, but the number of uses in a second period after the first period falls below the threshold, this corresponds to a decrease in the number of times the application is used. The processing execution unit 103 executes the function deactivation process by unassociating all user IDs associated with the function ID of the application to be deactivated.

[0077] Note that the function deactivation process may be performed by other processes and is not limited to the examples above. For example, the processing execution unit 103 may stop the use of an application by deleting the record of the application to be stopped from the application database DB3. For example, if a user's user ID and the function ID of an application that this user is permitted to use are associated in the user database DB1, the processing execution unit 103 may perform the function deactivation process by releasing all of these associations in the user database DB1. Alternatively, for example, a process that displays a list of applications with relatively low usage on the administrator's user terminal 20 and stops their use according to the administrator's operation may also be considered a function deactivation process. Similar function deactivation processes may be performed for other functions besides applications.

[0078] In the modified example 1, the information sharing system 1 performs a function shutdown process as a predetermined operation. This stops the function that meets the first criterion, eliminating the need for the administrator to manually shut down the function, thus reducing the burden on the administrator.

[0079] [5-2. Variation 2] For example, apps added by users themselves are generally free, but apps provided in advance by the information sharing system, as well as other functions not related to apps, may be subject to a fee. For example, users may be able to decide whether or not to continue the contract for paid functions, or change their contract plan. In the information sharing service of Example 2, contracts can be made on a per-function basis. Various publicly known contract mechanisms can be used for per-function contracts.

[0080] In Modification 2, the processing execution unit 103 performs a contract process to enter into a contract according to the usage status of the function, as a predetermined process. The contract process may be a process that automatically decides whether or not to continue the contract or automatically changes the contract plan, but in Modification 2, the case where the process of proposing to the user whether or not to continue the contract or prompting the user to change the contract plan corresponds to the contract process is explained. For example, the processing execution unit 103 performs the contract process by displaying contract-related information on the usage status screen. In Modification 2, an application is also explained as an example of a function.

[0081] Figure 9 shows an example of the usage status screen SC2 in Modification 2. For example, the processing execution unit 103 executes contract processing by displaying a message on the usage status screen SC2 prompting the termination of the contract for an app with relatively low usage. For example, the processing execution unit 103 executes contract processing by displaying a message on the usage status screen SC2 prompting the user to change the contract plan for an app with relatively low usage to a cheaper contract plan, or to stop continued use altogether. The method for determining whether usage is relatively low or not may be the same as in Modification 2.

[0082] In the example in Figure 9, apps with access counts below a threshold correspond to apps with relatively low usage. For example, since the number of accesses for the chat app is below the threshold, the usage status screen SC2 displays a message prompting the user to delete the chat app and stop using it. The processing execution unit 103 may automatically stop the continued use of the chat app or automatically change to a cheaper contract plan than the current one.

[0083] Conversely, the processing execution unit 103 may perform contract processing by displaying a message on the usage status screen SC2 prompting the user to change the contract plan of an application whose usage is increasing to a higher-priced contract plan. In the example in Figure 10, since the number of accesses to the billing management application is increasing, a message prompting a change in the contract plan is displayed on the usage status screen SC2. The processing execution unit 103 may also automatically change the billing management application to a higher-priced and more convenient contract plan. Similarly, for other functions other than applications, contract processing should be performed according to the usage status of those functions.

[0084] In the modified version 2, the information sharing system 1 performs contract processing as a predetermined process. This makes it easier for users to consider contracts for the functions they are currently using, thereby improving user convenience.

[0085] [5-3. Modified Example 3] For example, the usage status acquisition unit 102 may acquire the user IDs of users who accessed the information provided by the function from among multiple users as usage status. The information provided by the function is information shared using the function. For example, in the case of an application, the information of records included in tables that can be displayed in the application, or the information included in parts other than records, corresponds to the information provided by the application. For example, in the case of a schedule sharing function, the schedules and comments that can be displayed on the schedule screen correspond to the information provided by the schedule sharing function. In the modified example 3, it is assumed that the usage status database DB2 stores the user IDs of users who accessed the information for each piece of information provided by each function.

[0086] A user ID is an example of user identification information. Therefore, any section describing a user ID can be interpreted as referring to user identification information. User identification information can be any information that can identify a user, and is not limited to a user ID. For example, user identification information may be an email address or a phone number, or it may be information called a user account instead of a user ID.

[0087] In the modified example 3, the processing execution unit 103 executes a predetermined process based on the application's user ID. Therefore, the predetermined process in modified example 3 is a process executed based on the user ID of the user who accessed the information provided by the application. In the case of the usage status display process described in the embodiment, the processing execution unit 103 executes a usage status display process to display the usage status screen SC2, which shows the user ID of the user who accessed the information provided by the function.

[0088] For example, if you want to restrict which users can access a specific record within an application, the administrator may be allowed to set access rights for that record. The administrator sets access rights for a specific record by specifying which users can access it. If the administrator makes a mistake in the setting process, a user who should not have access may be able to access the record. In this case, the processing execution unit 103 may perform a predetermined process by notifying the administrator of the user ID of the user who accessed the record.

[0089] For example, the processing execution unit 103 may perform a predetermined process by changing the access rights of a user who does not frequently access the information provided by a certain application. The processing execution unit 103 may also change the access rights of a user who does not frequently access a record in a certain application so that they cannot access that record. Alternatively, for example, the processing execution unit 103 may send a notification to a user who does not frequently use a certain application, urging them to use the application. Similarly, the predetermined processes described above may be performed for other functions other than applications.

[0090] Furthermore, the application may be configured to allow access permissions to be set so that only specific users can use it. For example, an application for a certain group may have access permissions set so that only some of the users belonging to that group can use it. The access permissions for an application are specified by an administrator user who has administrative privileges for the application. In the modified example 3, the data storage unit 100 stores an application database DB3 in which the access permissions for applications are defined. The data storage unit 100 may also store a database in which the access permissions for other functions other than applications are defined.

[0091] Figure 10 shows an example of the application database DB3. For example, the application database DB3 associates a group ID, the function IDs of each of multiple applications, and the user IDs of users who have access rights to those applications. When a request to use an application is sent from a user terminal 20 of a certain user, the service provision unit 101 refers to the application database DB3 and determines whether the user's user ID is associated with the function ID of this application. If these are not associated, the service provision unit 101 does not permit the use of the application; if they are associated, it permits the use of the application.

[0092] For example, when the service provider unit 101 displays the portal screen SC1 on a user terminal 20 of a particular user, it may refer to the application database DB3 to identify the applications to which this user has access rights, and then display only those identified applications in the display area A10. Note that the application database DB3 may store user IDs of users who do not have access rights to an application, rather than user IDs of users who do have access rights to an application.

[0093] In the modified example 3, the processing execution unit 103 may perform a usage suspension process as a predetermined process based on user identification information, in order to stop the use of the app by users who use the app relatively infrequently among multiple users. Users who use the app relatively infrequently are users whose number of app usages (e.g., number of accesses) is less than that of other users or a predetermined threshold. For example, if users are ranked in descending order of the number of app usages, users ranked below a predetermined rank will be considered users who use the app relatively infrequently. For example, users who do not use the app at all, or users whose number of app usages is below a threshold, will be considered users who use the app relatively infrequently. The threshold may be a fixed value, or it may be determined according to the total number of usages of all users.

[0094] In Modification 3, the user ID of the user who accessed the app and the date and time of access to the app are referenced from the usage status database DB2 in Figure 5. The usage status acquisition unit 102 acquires this usage status. The aggregation of whether or not the app usage is relatively low may be for the entire past period or for a recent period. In Modification 3, an example is given where not using the app at all in the most recent six months is considered to be relatively low app usage.

[0095] The processing execution unit 103 identifies users who use an application relatively infrequently, based on the usage status of that application. For example, for each application, the processing execution unit 103 identifies users who have access rights to the application but have not used the application at all in the past six months as users who use the application relatively infrequently. For example, the processing execution unit 103 executes a usage suspension process by setting access rights so that users who use the application relatively infrequently cannot use the application.

[0096] Note that the deactivation process may be performed by other processes and is not limited to the above example. For example, if the user database DB1 associates a user's user ID with the function ID of an application to which that user has access rights, the processing execution unit 103 may perform the deactivation process by changing the access rights settings in the user database DB1 when the user's use of the application decreases. Alternatively, for example, displaying a list of users who use the application relatively infrequently on the administrator's user terminal 20 and setting access rights according to the administrator's actions may also constitute the deactivation process. Similar deactivation processes may be performed for other functions besides applications.

[0097] The information sharing system 1 in Modification 3 performs predetermined processing based on the user ID of the user who accessed the information provided by the application among multiple users. This makes it possible to perform detailed analysis of which users accessed the information and to automatically set access rights, thereby increasing the convenience of the information sharing service. For example, if access to a specific record in a certain application is restricted to only specific users, it becomes easier for the administrator to check whether a user who should not be able to access it is able to access it due to a misconfiguration of access rights. In the event of such access, a predetermined notification may be sent to the administrator. For example, if a suspension process is performed as a predetermined process, the use of the application by users who do not frequently use certain functions will be suspended, eliminating the need for the administrator to manually change access rights and thus reducing the burden on the administrator.

[0098] [5-4. Modification 4] In Modification 4, a thread function, which is a type of bulletin board that allows for communication, is described as an example of a function. For example, the processing execution unit 103 may perform an information display process as a predetermined process to display information from among the multiple pieces of information provided by the thread function that satisfies the second criterion for use by each of the multiple users.

[0099] The information provided by the thread function is information such as comments posted in a thread. The second criterion is the condition for whether or not to execute the information display process. Modification 4 gives an example where being frequently viewed corresponds to the second criterion, but the second criterion may be other criteria. For example, the second criterion may be being viewed by a specific user, the number of likes being above a threshold, the number of replies being above a threshold, the inclusion of specific words above a threshold, and the number of backlinks being above a threshold. Frequently viewed information is information with an access count above a threshold. In Modification 4, it is assumed that the usage status database DB2 stores the access count for each piece of information provided by the thread function.

[0100] Figure 11 shows an example of the portal screen SC1 of Modification 4. In the example in Figure 11, it is shown that frequently viewed information is displayed in the display area A11 of the portal screen SC1. In Modification 4, the usage status is acquired for each piece of information exchanged in a thread created using the thread function. The usage status may also be acquired for each individual post within a thread. For this reason, the usage status acquisition unit 102 acquires the usage status for each piece of information within a thread. The processing execution unit 103 identifies frequently viewed information based on the usage status of each piece of information within a thread. The processing execution unit 103 performs information display processing by displaying the frequently viewed information or its link on the portal screen SC1.

[0101] Furthermore, the information display process can be applied to functions other than the threading function. For example, if an app corresponds to a function, the process for displaying frequently viewed information among the multiple pieces of information registered in the app may correspond to the information display process. For example, if a schedule sharing function corresponds to a function, the process for displaying frequently viewed information among the multiple pieces of information registered in the schedule sharing function may correspond to the information display process. Similarly, for other functions, it is sufficient to display frequently viewed information through the information display process.

[0102] In the modified example 4, the information sharing system 1 performs an information display process as a predetermined operation. This makes it easier for users to notice information that is frequently viewed on the information sharing service, thereby improving user convenience.

[0103] [5-5. Variation 5] For example, the processing execution unit 103 may, as a predetermined process, execute a permission change process to change the permissions for information among the multiple pieces of information provided by the function whose use by each of the multiple users satisfies the third criterion.

[0104] The third criterion is the condition for whether or not to execute the permission change process. In Modification 5, the third criterion is given as an example where the number of times the app has been used is below a threshold, but the third criterion may be any other criterion. For example, the third criterion may be that the app is viewed but not updated, no comments are posted to the app, no reactions are made to comments by other users, the app is not viewed by a specific user, a specific reaction is made more than a threshold, and the creation date is before a threshold. The process of changing the access rights of an app record, as explained in Modification 3, is a type of permission change process. In Modification 5, processes not explained in Modification 3 can also be executed as permission change processes. In Modification 5, the app is explained again as an example of functionality.

[0105] For example, the permission change process may be a process that archives the application information so that it cannot be updated. Archiving prevents further updates to the application information. Archiving may also involve compressing the data by changing the data format. For example, archiving may be performed by changing the application information, which was in tabular format, to text format. For example, archiving may be performed by saving image data showing a screenshot of a screen that displays certain information. Various publicly known methods can be used for archiving itself. The processing execution unit 103 may archive applications that are no longer viewed.

[0106] In the modified example 5, the information sharing system 1 performs a permission change process as a predetermined operation. This reduces the burden on the administrator, for example, by eliminating the need for the administrator to manually change access rights. Similarly, when archiving information to prevent further updates, the effort required for the administrator to manually archive it is reduced. Archiving also compresses the size of the information, thus reducing memory consumption.

[0107] [5-6. Variation 6] For example, the predetermined processing may be processing to make it easier to find results in searches within the information sharing service. The information sharing system 1 in Modification 6 includes a search unit 104. The search unit 104 searches for information provided by each of the multiple functions based on search conditions entered by each of the multiple users. In Modification 6, an in-app search is given as an example, but the scope of the search is not limited to the app. For example, information from other functions such as threads may be the target of the search, or the search may be performed across multiple functions. The search itself can utilize methods adopted by various search engines.

[0108] The processing execution unit 103 in Modification 6 may perform a hit process as a predetermined process to make it easier for information provided by frequently used apps among multiple apps to be found in searches. For example, the processing execution unit 103 may perform a hit process by adjusting the search score so that the more accesses an app receives, the higher its search score for the information of that app. The processing execution unit 103 may also perform a hit process by limiting the search to apps with an access count above a threshold.

[0109] Similarly, for other functions besides the app, information on frequently used functions should be made more easily searchable. For example, if a function has both flow information that is immediately discarded and stock information that is accumulated rather than immediately discarded, the stock information may be prioritized in searches over the flow information. In this case, the processing execution unit 103 may make information on frequently used functions easier to find in searches by changing it from flow information to stock information. In this case, each piece of information is assumed to have an attribute indicating whether it is flow information or stock information. The processing execution unit 103 changes the flow information to stock information by changing the attribute of the information.

[0110] In the modified version 6, the information sharing system 1 performs a hit process as a predetermined operation. This makes it easier to find information on frequently viewed functions in searches, thereby improving the convenience of searching.

[0111] [5-7. Variation 7] For example, each of multiple functions may be provided to each of multiple users using an API related to that function. The service provision unit 101 in Modification 7 provides a certain function using its API. For example, when the service provision unit 101 receives a request for a certain function's API from a user terminal 20, it provides this function to the user based on the request for that API. Various methods can be used for providing functions using APIs. For example, there may be APIs for schedule sharing, file sharing, and APIs corresponding to individual applications. The usage status acquisition unit 102 in Modification 7 acquires the usage status of a function using its API.

[0112] Modification 7 provides an example where a management user, who is a labor manager, manages the attendance and working hours of general users, who are employees under their management. For this reason, the information sharing service in Modification 7 has an attendance management function. The attendance management function is a function for managing the arrival and departure times of users. For example, when the service provider 101 receives a notification from the user terminal 20 indicating that a user has arrived at work, it uses the attendance management function to store the user's arrival time in the user database DB1. When the service provider 101 receives a notification from the user terminal 20 indicating that a user has left work, it uses the attendance management function to store the user's departure time in the user database DB1.

[0113] For example, the attendance management function may be part of the schedule sharing function. In this case, based on the usage status of the schedule sharing function, information that allows the administrator to grasp the actual status of meetings and visits by general users or the entire organization may be obtained using the API of the schedule sharing function. That is, the usage status acquisition unit 102 may obtain the usage status of the schedule sharing function using the API of the schedule sharing function in order to collect statistics on the schedule information for each general user. This usage status may be the schedule itself that individual general users have registered using the schedule sharing function.

[0114] For example, the usage status acquisition unit 102 uses the schedule sharing function API to acquire usage status information such as the number of appointments / total time for each menu showing the schedule of a general user (e.g., visits or holidays), the workload related to individual meetings, the number of appointments / total time for appointments within regular hours, the number of appointments / total time for appointments outside of regular hours, the number of recurring appointments / total time for appointments within a certain period of time, statistics on schedule information at the organization / group level, the workload related to meetings for the organization / group, the number of recurring appointments for the organization / group, and users who participate in many appointments within the organization / group.

[0115] The usage data described in Modification Example 7 is statistics for labor management administrators, so the usage data acquisition unit 102 can obtain the information necessary for labor managers. For example, the usage data acquisition unit 102 may use the schedule sharing function's API to obtain time spent on leave or midday breaks, early starts, and overtime hours (in combination with time cards). In Modification Example 7, the schedule sharing function was used as an example, but similarly, the usage data acquisition unit 102 may use the APIs of the various applications and other functions described in the Embodiment and Modification Examples 1 to 6 to obtain usage data.

[0116] In the modified example 7, the information sharing system 1 obtains the usage status of a function using the API of that function. Since requests to the API are always made when individual functions are provided using APIs, obtaining the usage status using the API allows for a more accurate acquisition of the function's usage status.

[0117] [5-8. Variation 8] For example, the usage status acquisition unit 102 may acquire the display time of the screen related to the function as the usage status of the function. The display time is the time from when the display of a function's screen starts until it ends. For example, if an app corresponds to a function, the time that each app is displayed on the user terminal 20 corresponds to the display time. The same applies to other functions. For example, in the case of a schedule sharing function, the time that the schedule screen is displayed corresponds to the display time. In the case of a thread function, the time that each thread's screen is displayed corresponds to the display time.

[0118] In the modified example 8, the service provision unit 101 starts timing when a screen for a certain function is displayed on the user terminal 20, and measures the display time of that function by measuring the time until the user transitions to another screen. The service provision unit 101 stores the measured display time as a usage status in the usage status database DB2. The usage status acquisition unit 102 acquires the display time of each function stored in the usage status database DB2 as a usage status.

[0119] In the modified example 8, the processing execution unit 103 executes a predetermined process based on the display time of the function. The predetermined process may be any of the processes described in the embodiment or modified examples 1 to 7. For example, the processing execution unit 103 executes a usage status display process to display the display time of each function on the usage status screen SC2. For example, the processing execution unit 103 executes a usage suspension process to stop the use of a function by a user whose display time is relatively short. Other predetermined processes may also be executed similarly based on the display time.

[0120] The information sharing system 1 in the modified example 8 performs predetermined processing based on the display time of the screen related to a function. This makes it possible to analyze how thoroughly a user is reviewing the screen of a particular function.

[0121] [5-9. Other variations] For example, the above variations may be combined.

[0122] For example, each of the functions described above can be implemented by any device in the information sharing system 1. For instance, a function described as being implemented by server 10 may be implemented by user terminal 20. In this case, the same processing performed by server 10 may be executed by a browser script or by a program installed on user terminal 20. For example, each function may be shared among multiple computers. [Explanation of symbols]

[0123] 1 Information sharing system, 10 Server, 11,21 Control unit, 12,22 Storage unit, 13,23 Communication unit, 20 User terminal, 24 Operation unit, 25 Display unit, 100 Data storage unit, 101 Service provision unit, 102 Usage status acquisition unit, 103 Processing execution unit, 104 Search unit, 200 Data storage unit, 201 Display control unit, 202 Operation reception unit, N Network, DB1 User database, DB2 Usage status database, DB3 Application database, SC1 Portal screen, SC2 Usage status screen, A10 Display area.

Claims

1. An information sharing system having a plurality of functions related to an information sharing service for sharing information, a usage status acquisition unit that acquires usage status of each of the plurality of users for each of the functions; a process execution unit that executes a predetermined process for each of the functions based on the usage status of the function; An information sharing system including:

2. the process execution unit executes, as the predetermined process, a usage status display process for displaying the usage status of the function on a user terminal. The information sharing system according to claim 1 .

3. the process execution unit executes, as the predetermined process, a function stop process for stopping a function, among the plurality of functions, whose use by each of the plurality of users satisfies a first criterion; 3. An information sharing system according to claim 1 or 2.

4. In the information sharing system, a contract for each function is possible, the process execution unit executes, as the predetermined process, a contract process for making the contract according to the usage status of the function.

3. An information sharing system according to claim 1 or 2.

5. the usage status acquisition unit acquires, as the usage status, user identification information capable of identifying a user who has accessed information provided by the function among the plurality of users; The process execution unit executes the predetermined process based on the user identification information of the function.

3. An information sharing system according to claim 1 or 2.

6. the processing execution unit executes, as the predetermined processing, an information display processing for displaying, among a plurality of pieces of information provided by the function, the information whose use by each of the plurality of users satisfies a second criterion; 3. An information sharing system according to claim 1 or 2.

7. the process execution unit executes, as the predetermined process, an authority change process for changing an authority related to the information, among a plurality of pieces of information provided by the function, the use of which by each of the plurality of users satisfies a third criterion; 3. An information sharing system according to claim 1 or 2.

8. the information sharing system further includes a search unit that searches for information provided by each of the plurality of functions based on search conditions input by each of the plurality of users; the processing execution unit executes, as the predetermined processing, a hit processing for making it easier for information provided by a frequently used function among the plurality of functions to be hit in a search; 3. An information sharing system according to claim 1 or 2.

9. Each of the plurality of functions is provided to each of the plurality of users by utilizing an API related to the function; The usage status acquisition unit acquires the usage status of the function by using the API of the function.

3. An information sharing system according to claim 1 or 2.

10. the usage status acquisition unit acquires, as the usage status of the function, a number of accesses to the function; The process execution unit executes the predetermined process based on the number of accesses to the function.

3. An information sharing system according to claim 1 or 2.

11. the usage status acquisition unit acquires, as the usage status of the function, a display time during which a screen related to the function is displayed; The process execution unit executes the predetermined process based on the display time of the function.

3. An information sharing system according to claim 1 or 2.

12. each of the plurality of functions is added by any one of the plurality of users; the usage status acquisition unit acquires the usage status of the function added by any one of the plurality of users; the process execution unit executes the predetermined process based on the usage status of the function added by any one of the plurality of users.

3. An information sharing system according to claim 1 or 2.

13. An information sharing system having a plurality of functions related to an information sharing service for sharing information, an acquisition unit that acquires user identification information capable of identifying a user who has accessed information provided by each of the plurality of functions among a plurality of users; a process execution unit that executes a function stop process for stopping a function, among the plurality of functions, whose use by each of the plurality of users satisfies a first criterion, based on the user identification information; An information sharing system including:

14. The process execution unit executes a usage status display process for displaying a usage status of the function by each of the plurality of users on a user terminal based on the user identification information. The information sharing system according to claim 13.

15. A processing execution method in an information sharing system having a plurality of functions related to an information sharing service for sharing information, comprising: a usage status acquisition step of acquiring a usage status by each of a plurality of users for each of the functions; a process execution step of executing a predetermined process related to each of the functions based on the usage status of the function; A method for performing a process comprising the steps of:

16. A computer in an information sharing system having a plurality of functions related to an information sharing service for sharing information, a usage status acquisition unit that acquires a usage status of each of the plurality of users for each of the functions; a process execution unit that executes a predetermined process for each of the functions based on the usage status of the function; A program to function as a

Images