Information processing apparatus, information processing system, information processing method, and program

Abstract

To propose a software package on the basis of a state of use of a user belonging to a tenant and a state of use of a user belonging to another tenant.SOLUTION: An information processing apparatus includes: a first state-of-use specifying unit which specifies a state of use for software included in a first package which is treated by a first tenant; a second state-of-use specifying unit which specifies a state of use for the software included in the first package before switching subscription, for one or more second tenants that have switched subscription from the first package to a second package; a tenant specifying unit which specifies a tenant, in the second tenants, having a state of use in common with the first tenant; and a notification unit which provides information on the second package related to the tenant specified by the tenant specifying unit, to a user who belongs to the first tenant.SELECTED DRAWING: Figure 12

Description

[Technical field]

[0001] The present invention relates to an information processing device, an information processing system, an information processing method, and a program. [Background technology]

[0002] When using software such as applications, charges may be made according to the terms of the contract. If the amount charged is excessive for the user's usage of the software, the user may cancel the contract, which may result in a decrease in the software provider's profits.

[0003] Conventionally, there have been studies on improving user satisfaction by proposing a cheaper plan than the contracted rate plan depending on the number of times an application is executed (for example, Patent Document 1). Summary of the Invention [Problem to be solved by the invention]

[0004] The technology of Patent Document 1 provides a contract based only on the usage status of users belonging to its own tenant, and does not take into account the usage status of users belonging to other tenants.

[0005] An object of the present invention is to propose a software package based on the usage status of a user belonging to one's own tenant and the usage status of a user belonging to another tenant. [Means for solving the problem]

[0006] In order to solve the above problem, the information processing device has a first usage status identification unit that identifies usage status of software included in a first package that is the target of use by a first tenant, a second usage status identification unit that identifies, for one or more second tenants that have switched the target of use from the first package to another second package, usage status of the software included in the first package before the target of use is switched, a tenant identification unit that identifies, among the second tenants, a tenant having usage status in common with the usage status of the first tenant, and a notification unit that notifies a user belonging to the first tenant of information regarding the second package related to the tenant identified by the tenant identification unit. Effect of the Invention

[0007] A software package can be proposed based on the usage status of users belonging to the tenant itself and the usage status of users belonging to other tenants. [Brief description of the drawings]

[0008] [Figure 1] 1 is a diagram illustrating an example of a configuration of an information processing system 1 according to a first embodiment. [Diagram 2] 1 is a diagram illustrating an example of a hardware configuration of a service providing system 10 according to a first embodiment. [Diagram 3] FIG. 2 is a diagram illustrating an example of a hardware configuration when the device 20 according to the first embodiment is an image forming apparatus. [Figure 4] 1 is a diagram illustrating an example of a functional configuration of an information processing system 1 according to a first embodiment. [Diagram 5] FIG. 13 is a diagram illustrating an example of the configuration of an application management table 151. [Figure 6] FIG. 13 is a diagram showing an example of the configuration of a package management table 152. [Figure 7] FIG. 13 illustrates an example of the configuration of a package application management table 153. [Figure 8] 13 is a diagram illustrating an example of the configuration of a tenant management table 154. FIG. [Figure 9] FIG. 13 is a diagram showing an example of the configuration of a contract package management table 155. [Figure 10] 13 is a diagram showing an example of the configuration of a package alteration history management table 156. FIG. [Figure 11] 13 is a diagram showing an example of a configuration of an application execution log table 157 in the first embodiment. FIG. [Figure 12] FIG. 2 is a diagram illustrating an example of a functional configuration of a screen generating unit 131 according to the first embodiment. [Figure 13] 11 is a flowchart illustrating an example of a process performed in the information processing system 1 according to the first embodiment. [Figure 14] FIG. 2 is a sequence diagram illustrating an example of a process performed in the information processing system 1 according to the first embodiment. [Figure 15] FIG. 2 is a sequence diagram illustrating an example of a process performed in the information processing system 1 according to the first embodiment. [Figure 16] FIG. 2 is a sequence diagram illustrating an example of a process performed in the information processing system 1 according to the first embodiment. [Figure 17] FIG. 13 illustrates an example of a display of a tenant management page. [Figure 18] 13 is a diagram illustrating an example of an application execution count tally table of a proposed tenant. FIG. [Figure 19] 13 is a diagram illustrating an example of an application weighting coefficient table of a proposed tenant. FIG. [Figure 20] FIG. 13 is a diagram illustrating an example of an intra-tenant weighting coefficient table of a reference candidate tenant. [Figure 21] FIG. 13 is a diagram illustrating an example of a usage similarity aggregation table. [Figure 22] FIG. 13 is a diagram showing a display example of a package proposal screen. [Diagram 23] FIG. 13 is a diagram illustrating an example of a configuration of an application execution log table 157 in the second embodiment. [Figure 24] 13 is a diagram illustrating an example of an execution count tally table by document classification of a proposed tenant. [Diagram 25]FIG. 13 is a diagram illustrating an example of an execution count table by document classification of a reference candidate tenant. [Figure 26] FIG. 13 is a diagram illustrating an example of a configuration of a package management table 152 in the third embodiment. [Figure 27] FIG. 23 is a diagram illustrating an example of an intra-tenant weighting coefficient table of a reference candidate tenant in the fourth embodiment. [Figure 28] 13 is a flowchart illustrating an example of a process procedure executed in the information processing system 1 according to the fourth embodiment. [Figure 29] FIG. 13 is a diagram showing an example of a list screen for selecting software for which activation processing is to be performed. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0009] Hereinafter, an embodiment of the present invention will be described with reference to the drawings. Fig. 1 is a diagram showing a configuration example of an information processing system 1 in a first embodiment. The information processing system 1 shown in Fig. 1 includes a service providing system 10, a device 20, and a PC terminal 30, which are communicatively connected via a wide area network N1 such as the Internet.

[0010] The devices 20 are various electronic devices used by users. The devices 20 are, for example, image forming devices such as MFPs (Multifunction Peripherals), PCs (Personal Computers), projectors, electronic whiteboards, digital cameras, etc. The users can use the devices 20 to utilize various software (applications) provided by the service providing system 10.

[0011] The PC terminal 30 is, for example, a desktop PC, a notebook PC, a smartphone, a tablet terminal, etc. used by a user. In this embodiment, the user uses the PC terminal 30 to make a contract regarding the use of various applications (hereinafter simply referred to as "apps") provided by the service providing system 10.

[0012] The service providing system 10 is, for example, one or more computers that execute an application designated by a user of the device 20 or the PC terminal 30 for data input from the device 20 or the PC terminal 30, and output the processing result. For example, when data generated as the processing result is printed, the device 20 can also be the output destination of the processing result.

[0013] 1 is merely an example, and other configurations may be used. For example, the information processing system 1 according to the present embodiment may include various devices that perform at least one of input and output of electronic data, and these devices may use various services provided by the service providing system 10.

[0014] Fig. 2 is a diagram showing an example of a hardware configuration of the service providing system 10 in the first embodiment. The service providing system 10 shown in Fig. 2 has an input device 11, a display device 12, an external I / F 13, and a RAM (Random Access Memory) 14. The service providing system 10 also has a ROM (Read Only Memory) 15, a CPU (Central Processing Unit) 16, a communication I / F 17, and an HDD (Hard Disk Drive) 18. Each of these pieces of hardware is connected to each other via a bus B.

[0015] The input device 11 includes a keyboard, a mouse, a touch panel, etc., and is used by the user to input various operation signals. The display device 12 includes a display, etc., and displays the results of processing by the service providing system 10. At least one of the input device 11 and the display device 12 may be connected to the service providing system 10 and used when necessary. The communication I / F 17 is an interface that connects the service providing system 10 to the network N1. This allows the service providing system 10 to communicate via the communication I / F 17.

[0016] The HDD 18 is a non-volatile storage device that stores programs and data. The programs and data stored in the HDD 18 include an OS (Operating System), which is basic software that controls the entire service providing system 10, and applications that provide various functions on the OS.

[0017] The service providing system 10 may use a drive device (e.g., a solid-state drive: SSD) that uses a flash memory as a storage medium instead of the HDD 18. The HDD 18 manages the stored programs and data by a predetermined file system and / or DB.

[0018] The external I / F 13 is an interface with an external device. The external device may include a recording medium 13a. This allows the service providing system 10 to read from and write to the recording medium 13a via the external I / F 13. The recording medium 13a may include a flexible disk, a CD, a DVD, an SD memory card, a USB memory, etc.

[0019] The ROM 15 is a non-volatile semiconductor memory that can retain programs and data even when the power is turned off. The ROM 15 stores programs and data such as a BIOS (Basic Input / Output System) that is executed when the service providing system 10 is started, OS settings, and network settings. The RAM 14 is a volatile semiconductor memory that temporarily retains programs and data.

[0020] The CPU 16 is a computing device that reads out programs and data from storage devices such as the ROM 15 and the HDD 18 onto the RAM 14 and executes processes, thereby realizing control and functions of the entire service providing system 10.

[0021] The PC terminal 30 may also have a hardware configuration as shown in FIG.

[0022] Fig. 3 is a diagram showing an example of a hardware configuration when device 20 in the first embodiment is an image forming apparatus. Device 20 shown in Fig. 3 has controller 21, operation panel 22, external I / F 23, communication I / F 24, printer 25, and scanner 26. Controller 21 also has CPU 31, RAM 32, ROM 33, NVRAM 34, and HDD 35.

[0023] The ROM 33 is a non-volatile semiconductor memory that stores various programs and data. The RAM 32 is a volatile semiconductor memory that temporarily holds programs and data. The NVRAM 34 stores, for example, setting information. The HDD 35 is a non-volatile storage device that stores various programs and data.

[0024] The CPU 31 is a calculation device that reads out programs, data, setting information, etc. from the ROM 33, NVRAM 34, HDD 35, etc. onto the RAM 32 and executes processing to realize the overall control and functions of the device 20. The operation panel 22 includes an input unit that accepts input from a user and a display unit that displays information. The external I / F 23 is an interface with an external device. The external device includes a recording medium 23a, etc. This allows the device 20 to read and / or write data from the recording medium 23a via the external I / F 23. The recording medium 23a includes, for example, an IC card, a flexible disk, a CD, a DVD, an SD memory card, a USB memory, etc.

[0025] The communication I / F 24 is an interface that connects the device 20 to a network. This allows the device 20 to communicate via the communication I / F 24. The printer 25 is a printing device that prints print data. The scanner 26 is a reading device that reads an original document and generates an electronic file (image file).

[0026] FIG. 4 is a diagram showing an example of a functional configuration of the information processing system 1 in the first embodiment. In FIG. 4, the PC terminal 30 has a screen rendering unit 301. The screen rendering unit 301 displays a screen indicated by screen data transmitted from the service providing system 10. The screen rendering unit 301 also transmits a request corresponding to a user's input on the screen to the service providing system 10. In this embodiment, the screen data is a Web page. Therefore, the screen rendering unit 301 may be realized by a Web browser. However, data in a format other than a Web page may be used as the screen data.

[0027] The service providing system 10 includes a document service 101, an input / output service 102, and a Web application 103. These are realized by processing executed by the CPU 16 of one or more programs installed in the service providing system 10. The service providing system 10 also uses storage units such as an application information storage unit 104 and a database 105. Each of these storage units can be realized using, for example, the HDD 18 or a storage device connectable to the service providing system 10 via a network.

[0028] The document service 101 is a collection of components that constitute a processing flow executed by an application provided by the service providing system 10. For example, the document service 101 includes components that execute OCR processing on image data scanned by the device 20, file conversion processing on the image data, or stamp application processing on the image data. The processing flow executed by each application is constituted by an ordered combination of one or more components.

[0029] The I / O service 102 manages information about each application (hereinafter referred to as "application information"), controls the execution of the application, etc. In Fig. 4, the I / O service 102 includes an application management unit 121, an I / O logic processing unit 122, an authentication unit 123, etc.

[0030] The application management unit 121 manages application information stored in the application information storage unit 104 for each application. The application information is managed in association with the ID of the application (hereinafter referred to as "application ID"), and includes a screen definition, processing contents, etc. The screen definition is definition information related to a screen displayed on the device 20 when the application is used. The processing contents is definition information related to a processing flow constituting the application. The definition information includes, for example, the execution order of components, input parameters for each component, etc.

[0031] The I / O logic processing unit 122 controls the execution of an application in response to a request from the device 20. When the I / O logic processing unit 122 executes an application, it records a log relating to the execution of the application in an application execution log table 157 in the database 105.

[0032] The authentication unit 123 authenticates the user who uses the application.

[0033] The Web application 103 executes a process for managing a contract for the use of an application. Hereinafter, a contract for the use of an application may be expressed as a license. Furthermore, a contract can be managed in units of a package including a contract for the use of one or more applications. The process for managing a contract also includes, for example, a process for proposing a change in the contract (a change in an application or package to be used). In FIG. 4, the Web application 103 includes a screen generation unit 131, a database processing unit 132, an authentication unit 133, and the like.

[0034] The screen generation unit 131 generates a Web page that constitutes a screen related to the contract, and transmits the Web page to the PC terminal 30. The screen generation unit 131 also executes processing in response to a request transmitted from the PC terminal 30 in response to an input by a user to the Web page.

[0035] The database processing unit 132 acquires data necessary for the processing executed by the screen generating unit 131 from the database 105 .

[0036] The authentication unit 133 authenticates a user who uses the Web application 103 from the PC terminal 30 .

[0037] The database 105 manages various data used by the Web application 103. In Fig. 4, the database 105 includes an application management table 151, a package management table 152, a package application management table 153, a tenant management table 154, a contract package management table 155, a package change history management table 156, an application execution log table 157, and the like.

[0038] Each of these tables will be explained below.

[0039] 5 is a diagram showing an example of the configuration of the application management table 151. The application management table 151 is a table for storing information about each application that can be provided by the service providing system 10, and one record corresponds to one application. Each record includes values ​​of each item, such as an application ID and an application name.

[0040] The application ID is the above-mentioned application ID, and is also an identifier of a record in application management table 151. When a record (an application) is added to application management table 151, an arbitrary value combining alphanumeric characters is assigned to the record (application) as a record ID. The application name is the name of the application.

[0041] 6 is a diagram showing an example of the configuration of package management table 152. Package management table 152 is a table for storing information related to packages, and one record corresponds to one package. A package is a unit that combines one or more applications. An application contract (a contract for obtaining a license (usage contract)) is made on a package basis. Each record includes values ​​of each item, such as a package ID and a package name.

[0042] The package ID is an identifier of a record (i.e., an identifier of a package) in package management table 152. When a record (a package) is added to package management table 152, an arbitrary value combining alphanumeric characters is assigned to the record (the package) as a record ID. The package name is the name of the package.

[0043] 7 is a diagram showing an example of the configuration of packaged application management table 153. Packaged application management table 153 is a table for storing the correspondence between packages and applications (information indicating which application each package includes), and one record corresponds to one application included in one of the packages. Therefore, for a package including multiple applications, multiple records are stored in packaged application management table 153. Each record includes values ​​of each item, such as a package management ID, a package ID, and an application ID.

[0044] The package management ID is an identifier of a record in the package management table 152. When a record is added (when an application is added to a package), an arbitrary value that is a combination of alphanumeric characters is assigned to the record as the package management ID.

[0045] The package ID is a package ID stored in package management table 152 (FIG. 6) for a package that includes an application related to the application ID of the same record.

[0046] The application ID is the application ID stored in the application management table 151 (FIG. 5) for an application that belongs to a package related to the package ID of the same record.

[0047] Which apps each package contains is set in advance, and one app may belong to two or more packages.

[0048] For example, according to the tables shown in Figures 5, 6, and 7, tenants who have subscribed to the Basic Package can only use Scan to Mail, tenants who have subscribed to the Standard Package can use Scan to Mail and Print from Local Storage, and tenants who have subscribed to the Premium Package can use Scan to Mail, Print from Local Storage, and Scan to Mail with Timestamp.

[0049] FIG. 8 is a diagram showing an example of the configuration of the tenant management table 154. The tenant management table 154 is a table for storing information about tenants, and one record corresponds to one tenant. A tenant is an example of a management unit for managing a company, organization, or individual who has made a contract to receive a service from a service provider including an app. A contract regarding an app is made for each set of one or more users (for example, a company or a department). Therefore, a tenant is distinguished for each set. To a tenant to which a certain user belongs, a device 20 used by the user also belongs. Each record includes a tenant ID, a tenant name, and values ​​of each item of a record for each user belonging to the tenant (hereinafter referred to as a "user record"). The user record includes values ​​of each item such as a user ID and a password.

[0050] The tenant ID is an identifier of a record (that is, a tenant) in the tenant management table 154. When a record is added (when a tenant is added), an arbitrary value that is a combination of alphanumeric characters is assigned to the record (tenant).

[0051] The tenant name is the name of the tenant.

[0052] The user ID is an identifier of a user who belongs to a tenant related to the tenant ID of the same record. The user ID only needs to be unique within the tenant, and the same user ID may be used between different tenants.

[0053] The password is the password of the user associated with the user ID of the same user record. In addition, in the tenant management table 154, role information indicating whether the user is a tenant administrator with administrator authority or a general user without administrator authority, and address information such as an email address may be stored for each user.

[0054] 9 is a diagram showing an example of the configuration of the contract package management table 155. The contract package management table 155 is a table for storing information about a package usage contract (hereinafter simply referred to as a "contract") by a tenant, and one record corresponds to a contract for one package by one tenant. Each record includes values ​​for each item, such as a contract management ID, a tenant ID, a package ID, contract date and time, cancellation date and time, usage start date and time, and usage end date and time.

[0055] The contract management ID is an identifier of a record (i.e., a contract) in the contract package management table 155. When a record is added, an arbitrary value that is a combination of alphanumeric characters is assigned to the record as the contract management ID.

[0056] The tenant ID is a tenant ID stored in the tenant management table 154 (FIG. 8) for a tenant who has a contract for a package related to the package ID of the same record.

[0057] The package ID is a package ID stored in the package management table 152 (FIG. 6) for a package to which a tenant associated with the tenant ID of the same record has made a contract.

[0058] The contract date and time is the date and time when a contract relating to the same record was made.

[0059] The cancellation date and time is the date and time when a contract related to the same record is terminated (cancelled). If a contract is changed from an active package to a different package, the date and time when the change was made is recorded as the cancellation date and time. The value of the cancellation date and time for records with ongoing contracts is blank.

[0060] The usage start date and time is the date and time when the package related to the package ID related to the same record can actually be used (or became available) by the tenant related to the tenant ID of the same record. The usage start date and time does not necessarily match the contract date and time.

[0061] The usage end date and time is the date and time when the usage of the package actually ends (or has ended) if the contract is canceled. The usage end date and time does not necessarily match the cancellation date and time. The value of the usage end date and time for records with ongoing contracts is null.

[0062] For example, in the case of the contract package management table 155 shown in FIG. 9, the contracts with the contract management IDs C11111 and C11190 have already been cancelled, while the contracts with the contract management IDs C11123 and C11191 are still ongoing.

[0063] 10 is a diagram showing an example of the configuration of package change history management table 156. Package change history management table 156 is a table for storing contract change history for each tenant, and one record corresponds to one contract change. A contract change refers to a case where a certain tenant cancels a contract for a package and contracts for a different package (changing the package that is the subject of the contract (the subject of use)). Hereinafter, changing a package contract may be expressed as switching packages. Each record includes values ​​for each item, such as a change ID, a tenant ID, a package ID before the change, a package ID after the change, and a change date and time.

[0064] The change ID is an identifier of a record (i.e., an identifier of a contract change) in the package change history management table 156. When a record is added (when a contract change is made), an arbitrary change ID consisting of a combination of alphanumeric characters is assigned to the record.

[0065] The tenant ID is the tenant ID stored in the tenant management table 154 (FIG. 8) for the tenant who has made the contract change.

[0066] The pre-change package ID is the package ID stored in package management table 152 (FIG. 6) for the package that was the subject of the contract before the contract change.

[0067] The changed package ID is the package ID stored in the package management table 152 (FIG. 6) for the package newly contracted as a result of the contract change.

[0068] The change date and time is the date and time when the contract change was made.

[0069] 11 is a diagram showing an example of the configuration of application execution log table 157 in the first embodiment. Application execution log table 157 is a table for recording the history of application execution, and one record corresponds to a log related to one execution of any application. Each record includes values ​​of each item, such as a record ID, application execution date and time, application ID, tenant ID, and user ID.

[0070] The record ID is an identifier of the record in the application execution log table 157. When a record is added to the application execution log table 157, an arbitrary value that is a combination of alphanumeric characters is assigned to the record as the record ID.

[0071] The application execution date and time is the date and time when the application is executed, which may be, for example, the date and time when the application is started, when a request to execute an application function is accepted, when the execution of the application function is started, or when the execution of the application function is completed.

[0072] The application ID is the application ID stored in the application management table 151 (FIG. 5) for the executed application.

[0073] The tenant ID is a tenant ID stored in the tenant management table 154 (FIG. 8) for the tenant to which the user associated with the user ID of the same record belongs.

[0074] The user ID is a user ID stored in the tenant management table 154 (FIG. 8) of a user who executed an app related to the app ID of the same record in a tenant related to the tenant ID of the same record.

[0075] The execution results of the application may be stored in the application execution log table 157.

[0076] Fig. 12 is a diagram illustrating an example of a functional configuration of the screen generating unit 131 in the first embodiment. In Fig. 12, the screen generating unit 131 includes a proposed destination usage situation identifying unit 141, a reference candidate usage situation identifying unit 142, a reference tenant identifying unit 143, a proposed package information acquiring unit 144, and an output unit 145.

[0077] The proposed destination usage status identifying unit 141 functions as an example of a first usage status identifying unit that identifies the usage status of a first package to be used by a first tenant for a predetermined period of time based on information indicating the usage status of multiple types of software by user. In this embodiment, multiple types of packages and apps included in the packages are an example of multiple types of software, and one or more packages subscribed to by the first tenant are an example of a first package. The application execution log table 157 is an example of information indicating the usage status of multiple types of software by user. A proposed destination tenant described later is an example of a first tenant.

[0078] The reference candidate usage status identifying unit 142 functions as an example of a second usage status identifying unit that identifies, for one or more second tenants that have switched the target of usage from the first package to another second package, a usage status of an app included in the first package during a predetermined period before the target of usage is switched, based on the information. In this embodiment, a reference candidate tenant described later is an example of a second tenant, and one or more packages that are contracted after the second tenant cancels the first package are an example of a second package.

[0079] The reference tenant identification unit 143 functions as an example of a tenant identification unit that identifies, from among the second tenants, a third tenant whose usage situation is relatively similar to that of the first tenant based on the information. That is, the third tenant is a tenant included in the second tenants and identified from among the second tenants. In this embodiment, a reference tenant described later is an example of the third tenant.

[0080] That is, the reference tenant identification unit 143 can identify a tenant among the second tenants whose usage status is common to that of the first tenant. Note that common indicates that at least a part of the usage status of apps and the like by users or devices belonging to the tenants matches between the two tenants. For example, if any of the apps in the top N number of usage counts in the first tenant is included in any of the apps in the top N number of usage counts in the second tenant, it can be determined that the usage status of the two tenants is common. Here, similarity and degree of similarity indicate the degree of commonality between the two tenants.

[0081] The proposed package information acquisition unit 144 acquires, from the database 105, information on the second package related to the third tenant (reference tenant) (that is, information on the second package to which the third tenant has switched from the first package).

[0082] The output unit 145 is an example of a notification unit. The output unit 145 outputs information about the second package related to the third tenant to a user or device belonging to the first tenant. Here, output indicates transmitting information to an external device such as a PC terminal 30, and includes, for example, displaying screen data or text data on a browser or an application of the PC terminal 30, and transmitting image data or text data to a predetermined destination such as an email address or a FAX number. Note that, hereinafter, output may be expressed as notification. Also, notification to a terminal owned by a user belonging to the first tenant or a destination corresponding to the user may be expressed as notification to a user belonging to the first tenant.

[0083] The process steps executed in the information processing system 1 will be described below. FIG. 13 is a flowchart for explaining an example of the process steps executed in the information processing system 1 of the first embodiment. Also, FIGS. 14 to 16 are sequence diagrams for explaining an example of the process steps executed in the information processing system 1 of the first embodiment. In FIGS. 14 to 16, steps corresponding to those in FIG. 13 are given step numbers that are branch numbers of the step numbers in FIG. 13. FIG. 13 and FIGS. 14 to 16 show the same process steps, but interactions between functional blocks are clarified in FIGS. 14 to 16.

[0084] At the start of the processing procedures of Figures 13 and 14 to 16 (hereinafter referred to as "Figure 13, etc."), a tenant management page is displayed by the screen rendering unit 301 on a PC terminal 30 used by a user (hereinafter referred to as the "tenant administrator") who has tenant administrator authority in a certain tenant.

[0085] 17 is a diagram showing an example of a tenant management page display. A tenant management page 510 is a Web page on which buttons (icons) for receiving various instructions from a tenant administrator are arranged.

[0086] In step S101, when the screen rendering unit 301 of the PC terminal 30 used by the tenant administrator accepts a press of the contract information screen display button 511 on the tenant management page 510 (FIG. 17) from the tenant administrator (S101-1), the screen rendering unit 301 requests a contract information screen from the screen generation unit 131 (S101-2). To generate a contract information screen, a user needs to be authenticated. Here, it is assumed that the tenant administrator is not authenticated. Then, the screen generation unit 131 transmits a web page of a login screen to the screen rendering unit 301 (S102-1). The screen rendering unit 301 displays the login screen on the PC terminal 30 based on the web page (S102, S102-2).

[0087] In the next step S103, when the screen rendering unit 301 receives input of a tenant ID, a user ID, and a password (hereinafter referred to as "login information") from the tenant administrator (S103-1), it transmits the login information to the screen generation unit 131 (S103-2).

[0088] In the next step S104, when the screen generation unit 131 transmits a login processing request including login information to the authentication unit 133 (S104-1), the authentication unit 133 performs authentication by checking the login information against the tenant ID, user ID, and password stored in the tenant management table 154 (FIG. 8), and transmits information indicating whether the login was successful to the screen generation unit 131 (S104-2). This identifies the tenant to which the tenant administrator belongs. If the login is successful (Yes in S104), the screen generation unit 131 continues with step S105 and onwards. If the login is unsuccessful (No in S104), the process returns to step S102.

[0089] In step S105, the proposed destination usage status identification unit 141 of the screen generation unit 131 acquires a package list that is contracted by the currently logged-in tenant (hereinafter referred to as the "proposed destination tenant"). Specifically, the proposed destination usage status identification unit 141 requests the database processing unit 132 for a package list that is contracted by the proposed destination tenant by specifying a tenant ID (hereinafter referred to as the "proposed destination tenant ID") included in the login information (S105-1). The database processing unit 132 acquires a list of records that include a tenant ID that matches the proposed destination tenant ID from the contract package management table 155 (FIG. 9) in the database 105 (S105-2, S105-3), and transmits the list to the proposed destination usage status identification unit 141 (S105-4). The list becomes a list of package IDs that are contracted by the proposed destination tenant (hereinafter referred to as the "contracted package list"). The following step S106 and subsequent steps are loop processing for each package ID included in the contracted package list. The package ID that is the target of processing in this loop is called the "target package ID," and the package associated with the target package ID is called the "target package."

[0090] In steps S106 to S110, the number of times each application in the package under contract with the proposal destination tenant is executed in the proposal destination tenant is tallied, and a weighting coefficient is assigned to each executed application.

[0091] In step S106, the proposal destination usage situation identification unit 141 acquires a list of applications (a list of application IDs and application names) belonging to the target package. Specifically, the proposal destination usage situation identification unit 141 requests the database processing unit 132 to acquire a list of applications related to the target package ID (a list of applications included in the target package) (S106-1 in FIG. 15). The database processing unit 132 extracts records including a package ID that matches the target package ID from the package application management table 153 (FIG. 7) in the database 105 (S106-2, S106-3). For each application ID included in each extracted record, the database processing unit 132 extracts records including the application ID from the application management table 151 (FIG. 5) in the database 105 (S106-4, S106-5). The database processing unit 132 transmits the list of extracted records to the proposal destination usage situation identification unit 141 (S106-6). The list of records is the list of applications belonging to the target package.

[0092] The following steps S107 and S108 are a loop process for each application ID included in the application list. The application ID being processed in the loop process is referred to as a "target application ID," and the application associated with the target application ID is referred to as a "target application."

[0093] In step S107, in response to a request from the proposed destination usage status identification unit 141 to acquire the application execution history of the proposed destination tenant (S107-1), the database processing unit 132 extracts, from the application execution log table 157 ( FIG. 11 ) in the database 105, records whose tenant ID and application ID match the proposed destination tenant ID and target application ID included in the acquisition request (S107-2, S107-3).

[0094] In the next step S108, the database processing unit 132 counts the number of times the target application has been executed in a predetermined period based on the extracted records (hereinafter referred to as "application execution history") (S108-1), and transmits the counting result to the proposed destination usage status identifying unit 141 (S108-2). The predetermined period is a period set in advance by the service provider to calculate the user's most recent usage status, such as the most recent month or year up to the present time. The database processing unit 132 counts the number of records in the application execution history extracted from the database 105 whose application execution date and time falls within the predetermined period, as the number of times the target application has been executed.

[0095] When steps S107 and S108 are executed for all application IDs included in the application list belonging to the target package (No in S109), the proposal destination usage state identifying unit 141 can obtain an application execution count count table as shown in FIG.

[0096] Fig. 18 is a diagram showing an example of an application execution count tally table of a proposed tenant. As shown in Fig. 18, the application execution count tally table includes an application ID, an application name, and an execution count for each application belonging to a target package. Therefore, the proposed destination usage status identification unit 141 can identify the usage status of an application belonging to a target package by using the application execution count tally table.

[0097] Next, the proposed destination usage status identifying unit 141 assigns a weighting coefficient (an example of a first coefficient, hereinafter referred to as an "application weighting coefficient") having a larger value in the order of the number of executions to the applications that are among the top N in the number of executions in the application execution count tabulation table and have an execution count of 1 or more (S110). In other words, a larger weight is assigned to the application having a larger number of executions. The value of N is a preset threshold. As a result, an application weighting coefficient table is generated, which is a list of pairs of application IDs and application weighting coefficients for up to N applications in the target package.

[0098] Fig. 19 is a diagram showing an example of an application weighting coefficient table of a proposed tenant. As shown in Fig. 19, the application weighting coefficient table is information in which an application weighting coefficient according to the number of executions is assigned to each record extracted from the application execution count tabulation table (Fig. 18) based on the number of executions. In Fig. 19, N1, N2, and N3 expressed as application weighting coefficients are values ​​that satisfy N1 ≥ N2 ≥ N3 > 0. The value of the application weighting coefficient assigned here may be a value fixed by the system or a value freely determined by the service provider.

[0099] In the subsequent steps S111 to S118, a process is executed to calculate the similarity between the usage of the target package in the proposed tenant and the past usage of the target package in a tenant other than the proposed tenant that has previously contracted for the target package (hereinafter referred to as a "reference candidate tenant").

[0100] In step S111, the reference candidate usage status identifying unit 142 of the screen generating unit 131 acquires a list of reference candidate tenants. Specifically, the reference candidate usage status identifying unit 142 transmits an acquisition request for a list of reference candidate tenants including the target tenant ID to the database processing unit 132 (S111-1). The database processing unit 132 extracts records including the target tenant ID as a pre-contract package ID from the package change management table (FIG. 10) (S111-2, S111-3). The database processing unit 132 transmits the list of records to the reference candidate usage status identifying unit 142 (S111-4). From the list of records, a list of tenant IDs of tenants (reference candidate tenants) that have previously used the target package can be obtained.

[0101] The following steps S112 to S117 are loop processes for each tenant ID of the reference candidate tenant. The tenant ID being processed in the loop process is referred to as a "target reference candidate tenant ID," and the tenant related to the target reference candidate tenant ID is referred to as a "target reference candidate tenant."

[0102] Steps S112 and S113 are loop processes for each application ID belonging to the target application. The application ID being processed in the loop process is referred to as a "target application ID," and the application related to the target application ID is referred to as a "target application."

[0103] In step S112, in response to a request to acquire the application execution history of a reference candidate tenant from the reference candidate usage status identification unit 142 (S112-1), the database processing unit 132 extracts records whose tenant ID and application ID match the target reference candidate tenant ID and target application ID included in the acquisition request from the application execution log table 157 (FIG. 11) in the database 105 (S112-2, S112-3).

[0104] In the next step S113, the database processing unit 132 counts the number of times the target application is executed in a predetermined period from the contract expiration date of the target package of the target reference candidate tenant based on the extracted record (hereinafter referred to as "application execution history") (S113-1), and transmits the counting result to the reference candidate usage status identification unit 142 (S113-2). The contract expiration date of the package can be identified based on the change date and time of the record that includes the target reference candidate tenant ID and the target application ID as the tenant ID and the pre-change application ID among the records acquired from the package change management table (FIG. 10) in step S114. Note that the reference candidate usage status identification unit 142 can identify the usage status by the target reference candidate tenant for each application belonging to the target package by acquiring the counting result.

[0105] When steps S112 and S113 are executed for all application IDs included in the application list belonging to the target package (No in S114), the reference candidate usage status identifying unit 142 assigns a weighting coefficient (an example of a second coefficient, hereinafter referred to as an "intra-tenant weighting coefficient") having a larger value in descending order of the number of executions to the applications that are among the top N in the counting result and have an execution count of 1 or more, in the same manner as in step S110 (S115). As a result, an intra-tenant weighting coefficient table, which is a list of pairs of application IDs and application weighting coefficients, is generated for a maximum of N applications related to the target package.

[0106] FIG. 20 is a diagram showing an example of an intra-tenant weighting coefficient table of a reference candidate tenant. The intra-tenant weighting coefficient table shown in FIG. 20 has a structure in which a tenant ID field is added to the application weighting coefficient table of the proposed tenant shown in FIG. 19. Three intra-tenant weighting coefficient tables (1) to (3) are shown in FIG. 20. (1) is an example of an intra-tenant weighting coefficient table generated when the target reference candidate tenant ID is "112233". (2) is an example of an intra-tenant weighting coefficient table generated when the target reference candidate tenant ID is "456789". (3) is an example of an intra-tenant weighting coefficient table generated when the target reference candidate tenant ID is "121212".

[0107] Next, the reference tenant identification unit 143 of the screen generation unit 131 calculates the sum of the products of the intra-tenant weight coefficients in the intra-tenant weight coefficient table (FIG. 20) related to the target reference candidate tenant and the application weight coefficients in the application weight coefficient table (FIG. 19) of the proposed tenant for each application ID as the similarity of the target reference candidate tenant to the proposed tenant in terms of the usage status of the target package (hereinafter referred to as "usage similarity") (S116). That is, the usage similarity is calculated based on the following formula (1).

[0108]

number

[0109] When steps S112 to S117 are executed for all reference candidate tenants (No in S118), information as shown in FIG. 21 (hereinafter referred to as a "usage similarity aggregation table") is obtained.

[0110] Fig. 21 is a diagram showing an example of a usage similarity tabulation table. As shown in Fig. 21, the usage similarity tabulation table is information including a tenant ID, a usage similarity, and a post-change package ID for each reference candidate tenant.

[0111] Next, the reference tenant identification unit 143 identifies a reference tenant by sorting the records of the usage similarity aggregation table in descending order of usage similarity (S119). Specifically, the reference tenant identification unit 143 identifies a reference candidate tenant that is within a preset rank in the sorting order and has a usage similarity equal to or higher than a certain level as a reference tenant. A reference tenant is a tenant that is used as a reference for proposing a change to the contract for the proposed tenant.

[0112] Next, the proposed package information acquisition unit 144 of the screen generation unit 131 extracts packages related to the changed package ID of each reference tenant in the usage similarity aggregation table (FIG. 21) as a proposed package list for the proposed tenant (S120). That is, the package related to the changed package ID is identified as the proposed package. At this time, it is possible that multiple packages are included in the proposed package list. Note that if a package currently under contract by the proposed tenant is included in the proposed package list, the proposed package information acquisition unit 144 deletes the package from the proposed package list. The packages currently under contract by the proposed tenant can be identified by referring to the contract package management table 155 (FIG. 9).

[0113] Next, the proposed package information acquisition unit 144 acquires package information (package name) related to each package ID included in the proposed package list (S121). Specifically, the proposed package information acquisition unit 144 designates each package ID included in the proposed package list and requests the database processing unit 132 to acquire package information (S121-1). The database processing unit 132 extracts records including each package ID from the package management table 152 (FIG. 6) (S121-2, S121-3). The database processing unit 132 transmits each extracted record to the proposed package information acquisition unit 144 (S121-4).

[0114] When steps S106 to S121 are executed for all package IDs included in the package list of the proposed tenant contracted in step S105 (No in S122), the proposed package information acquisition unit 144 generates a final list of proposed package information by concatenating the list of proposed package information acquired for each package of the proposed tenant contracted (S123). At this time, the proposed package information acquisition unit 144 leaves only one package information with a duplicate package ID.

[0115] The proposed package information acquisition unit 144 may add, to each proposed package, information indicating which package of the proposed tenant's contracted packages the proposed package corresponds to. For example, when the target package is a Basic Package (a package under contract with the proposed tenant), it is possible to identify that the package to which the reference tenant is changed is a Standard Package. In this case, the proposed package information acquisition unit 144 may add information indicating that the proposed package corresponding to the Basic Package is a Standard Package (for example, text indicating that a user who had contracted the Basic Package has changed to the Standard Package) to information related to the Basic Package in the list of proposed package information.

[0116] In the next step S124, the output unit 145 of the screen generation unit 131 generates a Web page of the package proposal screen based on the list of final proposed package information and the list of packages under contract acquired in step S105 (S124-1), and transmits the Web page to the PC terminal 30 used by the tenant administrator (S124-2). The screen drawing unit 301 of the PC terminal 30 displays the package proposal screen based on the Web page (S125).

[0117] Fig. 22 is a diagram showing a display example of a package proposal screen 520. The package proposal screen 520 shown in Fig. 22 includes a proposal area 521, a contract information area 522, and the like.

[0118] The proposal area 521 is an area that is generated based on a list of final proposed package information and shows a list of packages proposed to the proposed tenant as contract changes. The contract information area 522 is an area that is generated based on a list of packages currently under contract and shows a list of packages currently under contract with the proposed tenant.

[0119] In the example of Fig. 22, a proposal is made to a tenant who has contracted for the Basic Package and Good Package for FAX to change their contract to the Standard Package and Best Package for FAX, respectively. If the tenant administrator of the proposed tenant accepts the proposal and wishes to change the contract, he or she can click on link L1 or the like to move to the contract change page and carry out the contract change procedure.

[0120] As described above, according to the first embodiment, among tenants (reference candidate tenants) that previously had a contract for a package (software to be used) that the proposed tenant is currently contracting, a package after a contract change of a tenant (reference tenant) with a relatively high similarity in usage status of the package is presented to the proposed tenant as a proposal target. Therefore, a software package can be proposed based on the usage status of a user belonging to the proposed tenant and the usage status of a user belonging to another tenant. As a result, for example, it can be expected that the possibility of canceling the use of the package will be reduced.

[0121] Next, a second embodiment will be described. In the second embodiment, differences from the first embodiment will be described. Therefore, the points not specifically mentioned may be the same as the first embodiment.

[0122] In the second embodiment, an example will be described in which the accuracy of the usage similarity is improved by tallying up the number of times an application is executed, taking into consideration the purpose for which the tenant is using the application.

[0123] In order to take the purpose of an application into consideration when calculating the usage similarity, in the second embodiment, the I / O logic processing unit 122 extracts classification information (hereinafter referred to as "document classification") of document data (image data, text data, or data in any other format) read (extracted) from the data processed by the executed application, and records the classification information in the application execution log table 157 as information indicating the purpose of the application.

[0124] Fig. 23 is a diagram showing an example of the configuration of application execution log table 157 in the second embodiment. As shown in Fig. 23, each record of application execution log table 157 in the second embodiment includes a document classification value in addition to the values ​​of each item shown in Fig. 11.

[0125] Extraction of document classification from data read from document data may be performed, for example, based on a rule base or using a machine learning model.

[0126] The proposed destination usage status identifying unit 141 and the reference candidate usage status identifying unit 142 of the screen generating unit 131, when tallying up the number of times an application is executed for the proposed destination tenant or each reference candidate tenant based on such an application execution log table 157 (S108, S113 in FIG. 13), tally up the number of times the application is executed for each package as well as the number of times the application is executed for each document classification. That is, the number of times the application is executed for each package is classified by purpose.

[0127] Fig. 24 is a diagram showing an example of an execution count tabulation table by document classification of a proposed tenant. Fig. 24 shows an example of an execution count tabulation table by document classification generated by aggregating the execution counts of apps belonging to a target package for a proposed tenant by document classification in step S108 of Fig. 13.

[0128] FIG. 25 is a diagram showing an example of an execution count by document classification tabulation table of a reference candidate tenant. FIG. 25 shows an example of an execution count by document classification tabulation table generated by tabulating the execution count of an app belonging to a target package for a target reference candidate tenant by document classification in step S113 of FIG. 13. (1) is an example of an execution count by document classification tabulation table generated when the target reference candidate tenant ID is "112233". (2) is an example of an execution count by document classification tabulation table generated when the target reference candidate tenant ID is "456789". (3) is an example of an execution count by document classification tabulation table generated when the target reference candidate tenant ID is "121212".

[0129] In addition, when generating the execution count aggregation table by document classification for the proposed tenant and each reference candidate tenant, the screen generation unit 131 does not include in the execution count aggregation table by document classification document classifications whose execution count is less than a preset ratio to the total execution count of all apps in the target package (or document classifications whose execution count is less than a preset threshold) and execution counts whose document classification is unknown.

[0130] In step S116 of FIG. 13, the reference tenant identification unit 143 of the screen generation unit 131 calculates the usage similarity based on the following formula (2).

[0131]

number

[0132] The document overlap is a value obtained by counting the number of times each document classification that appears in the execution count by document classification table (FIG. 24) of the proposed tenant appears in the execution count by document classification table (FIG. 25) of the target reference candidate tenant, and calculating the sum of the count results (number of occurrences) for each document classification. Therefore, in the second embodiment, the reference tenant is further identified based on the similarity of the classification results by purpose of the usage status of the target package.

[0133] According to the examples in FIGS. 24 and 25, the document overlap of tenant 112233 is 2, the document overlap of tenant 456789 is 1, and the document overlap of tenant 121212 is 0.

[0134] As described above, according to the second embodiment, by introducing document overlap, the higher the usage similarity is for reference candidate tenants that tend to process documents of the same document classification as the proposed tenant (tend to use the target package for the same purpose as the proposed tenant), making it possible to propose contract changes for a package based on the track record of contract changes for reference tenants that have similar uses for the package.

[0135] Next, a third embodiment will be described. In the third embodiment, differences from the first embodiment will be described. Therefore, the points not specifically mentioned may be the same as the first embodiment.

[0136] In the third embodiment, an example will be described in which the accuracy of the utilization similarity is improved by a method different from that in the second embodiment.

[0137] In the third embodiment, in step S105 of FIG. 13, when the proposal destination utilization state specifying unit 141 acquires the list of packages under contract of the proposal destination tenant, the proposal destination tenant determines the business type of the proposal destination tenant based on the list.

[0138] Fig. 26 is a diagram showing an example of the configuration of package management table 152 in the third embodiment. Comparing Fig. 26 with Fig. 6, package management table 152 in Fig. 26 further includes an item for target industry. The target industry is information indicating the industry that the package targets. Some packages are intended for specific industries, such as medical practice or legal practice, and for such packages, information indicating the specific industry is registered in the target industry. On the other hand, for packages that are not intended for a specific industry (for general use packages), such as Basic Package, the target industry is not registered.

[0139] Therefore, the list acquired in step S105 may include a record in which the target business type is registered. The proposed destination usage status identification unit 141 identifies the target business type registered in the record as the business type of the proposed destination tenant.

[0140] In step S111 of FIG. 13, the reference candidate usage status identification unit 142 acquires a list of reference candidate tenants (a list of records in FIG. 10 whose pre-change package ID matches the target package ID), and then identifies a list of business types of each reference candidate tenant based on the list.

[0141] Specifically, the reference candidate usage status identifying unit 142 extracts the modification date and time of each record (reference tenant) in the list, and obtains a list of packages that the reference candidate tenant had contracted at the time of the modification date and time. The package list can be obtained by extracting records whose tenant ID in the contract package management table 155 (FIG. 9) matches the tenant ID of the reference candidate tenant, and whose modification date and time are included in the period between the usage start date and time and the usage end date and time. The reference candidate usage status identifying unit 142 obtains the target industry corresponding to the package ID of the extracted record from the package management table 152 (FIG. 26), thereby identifying a list of industries of the reference candidate tenant.

[0142] In step S116 of FIG. 13, the reference tenant identification unit 143 calculates the usage similarity based on the following formula (3).

[0143]

number

[0144] The business type similarity is the number of business types in the list of business types of the reference tenant that match any of the business types in the list of business types of the proposed tenant. In other words, one or more business types extracted from the package under contract of the proposed tenant are compared with one or more business types extracted from the package cancelled by the reference candidate tenant (or the package under contract), and the business type similarity is determined according to the number of matching business types. Therefore, in the second embodiment, the reference tenant is further identified based on the similarity between the business types of the proposed tenant and the business types of the reference candidate tenant.

[0145] In the above, the package and the business type are stored in association with each other, but the present invention is not limited to this. For example, one or more pieces of business type information may be stored for each tenant in the tenant management table 154. In this case, the reference tenant specification unit 143 may compare the business type information associated with the proposed tenant with the business type information associated with each reference candidate tenant, and calculate the usage similarity for the proposed tenant based on the number of matching business types.

[0146] The third embodiment may be combined with the second embodiment.

[0147] As described above, according to the third embodiment, it is possible to propose a contract change of a package based on the track record of contract changes of a reference tenant in a business type similar to that of the proposed tenant at the time of past contract changes.

[0148] Next, a fourth embodiment will be described. In the fourth embodiment, differences from the above-mentioned embodiments will be described. Therefore, the points not specifically mentioned may be the same as the above-mentioned embodiments.

[0149] In each of the above embodiments, the proposed package output process (FIG. 13) is executed each time the user (tenant administrator) presses the contract information screen display button 511 on the tenant management page 510 (FIG. 17), which takes time to display the package proposal screen 520 and increases the number of accesses to the database 105.

[0150] In the fourth embodiment, an example will be described in which the number of accesses to database 105 during the output processing of a proposed package is reduced by retaining (caching) the results during processing and re-tallying them only at the first access after the retention period has elapsed.

[0151] The data to be retained is as follows:

[0152] (1) The application weighting coefficient table of the proposed tenant generated in step S110 ( FIG. 19 ) Since the proposed tenant continues to use the target package, the number of times the application is executed is likely to change from day to day, but it is considered that the usage trend of the application is unlikely to change suddenly. Therefore, the retention period of the application weight coefficient table (FIG. 19) of the proposed tenant is set to the last day of the month, and when the output process of the proposed package is re-executed during the same month, the last counting result is obtained from the database 105 and used to generate the package proposal screen 520. Since the application weight coefficient table (FIG. 19) of the proposed tenant for the previous month is discarded in the following month, the application weight coefficient table (FIG. 19) of the proposed tenant is re-generated in the following month based on the application execution log table 157 (FIG. 11).

[0153] (2) The intra-tenant weighting coefficient table of the reference tenant generated in step S115 ( FIG. 20 ) Since the use of the target package has been terminated in the reference tenant, the count result of the number of times the application has been executed does not change. Therefore, by changing the intra-tenant weighting coefficient table of the reference tenant (FIG. 20) as shown in FIG. 27, it is possible to skip the generation process of the intra-tenant weighting coefficient table of the reference tenant (S112 to S115).

[0154] Fig. 27 is a diagram illustrating an example of an intra-tenant weighting coefficient table of a reference candidate tenant in the fourth embodiment. Each record of the intra-tenant weighting coefficient table in Fig. 27 includes values ​​of items such as a package ID and a last reference date in addition to the items in Fig. 20.

[0155] The package ID is the package ID of the package to which the app related to the app ID of the same record belongs. Since one app may belong to multiple packages, the package to which the app belongs is recorded.

[0156] The last reference date is the date when the record was last referenced. As a general rule, the same value is always assigned to records with the same tenant ID and package ID.

[0157] Fig. 28 is a flowchart for explaining an example of a processing procedure executed in the information processing system 1 according to the fourth embodiment. In Fig. 28, the same steps as those in Fig. 13 are given the same step numbers, and the description thereof will be omitted as appropriate.

[0158] In FIG. 28, step S201 is executed following step S105. In step S201, the proposal destination usage situation identification unit 141 determines whether or not there is a cache of the application weight coefficient table (FIG. 19) of the proposal destination tenant. If there is no such cache (No in S201), steps S106 to S110 are executed. However, in step S110, the proposal destination usage situation identification unit 141 saves the generated cache of the application weight coefficient table (FIG. 19) in the HDD 18 or the like. The cache is automatically deleted when the retention period has elapsed.

[0159] If the cache exists (Yes in S201), the proposal destination usage state identifying unit 141 acquires the cache (S202) without executing steps S106 to S110. The application weighting coefficient table (FIG. 19) referred to in the subsequent steps is the cache.

[0160] In Fig. 28, step S203 is executed after step S111. In step S203, the reference candidate usage status identifying unit 142 determines whether or not there is a cache of the intra-tenant weighting coefficient table (Fig. 27) of the reference candidate tenant for the target package. The cache for the target package refers to a cache of the intra-tenant weighting coefficient table (Fig. 27) in which the package ID matches the target package ID.

[0161] If the cache does not exist (No in S203), steps S112 to S115 are executed, and then step S204 is executed. However, in step S115, the reference candidate usage status identifying unit 142 records the package ID of each record in the intra-tenant weighting coefficient table (FIG. 27), the target package ID as the last reference date, and the date of the current day.

[0162] Furthermore, in step S204, the reference candidate usage state identifying unit 142 saves a cache of the intra-tenant weighting coefficient table (FIG. 27) generated in step S115 in the HDD 18 or the like.

[0163] On the other hand, if the cache exists (Yes in S203), the reference candidate usage situation identifying unit 142 acquires the cache (S205). Next, the reference candidate usage situation identifying unit 142 updates the last reference date of each record in the cache to the current date (S206). The intra-tenant weighting coefficient table (FIG. 27) referenced in the following steps is the cache.

[0164] Step S116 and subsequent steps are the same as those in the above-described embodiments. Therefore, in the fourth embodiment, the reference tenant identification unit 143 identifies a reference tenant based on the similarity between the usage situation identified by the reference candidate usage situation identification unit 142 within a predetermined period before the timing at which the output unit 145 outputs information on the proposed package related to the reference tenant and the usage situation identified by the proposed destination usage situation identification unit 141 within the predetermined period.

[0165] Since the cache of the tenant weighting coefficient table (FIG. 27) grows larger each time step S204 is executed, records that have been last referenced for more than one year are automatically deleted.

[0166] As described above, according to the fourth embodiment, it is possible to improve the processing efficiency.

[0167] In the above-described embodiments, the number of executions of the application is counted and the proposed package is identified when the user accesses and logs in to the service providing system 10 via the PC terminal 30 or the like. However, the timing of counting the number of executions of the application and identifying the proposed package is not limited to this. For example, the service providing system 10 can count the number of executions of the application belonging to each package that the tenant has a contract for and identify the proposed package for the package at a specific timing before the user logs in. This makes it possible to present the proposed package list to the user immediately after the user logs in. In the fourth embodiment, the proposed package is identified by storing the application weight coefficient table and the intra-tenant weight coefficient table. However, by storing the proposed package itself as described above, the process of identifying the proposed package can be omitted.

[0168] In addition, in each of the above-described embodiments, an example has been shown in which a proposed package list is presented (output) to a user in the form of a package proposal screen 520 (FIG. 22) on the PC terminal 30 owned by a user belonging to the first tenant, but the method of presenting (outputting) the proposed package list is not limited to this. For example, the screen generation unit 131 can tally up the number of times an application is executed and identify proposed packages at a predetermined timing, and send the proposed package list to the email address of a user belonging to the first tenant. In this case, the screen generation unit 131 can store destination information such as the email address of an administrator of the tenant for each tenant, and send the proposed package list based on the destination information.

[0169] The device 20 can obtain software in package units from a cloud server (e.g., the service providing system 10) via a network. In the above, an example was given in which a package is a collection of applications, but a package may contain multiple types of software, such as applications and firmware (hereinafter, when both applications and firmware are included, it may be expressed as software), and a package may contain multiple applications and multiple firmware. For example, a package may contain an application and firmware necessary for the application to operate. However, a package may contain only one application or one firmware.

[0170] When a new version of software is released, the device 20 can automatically download a package including the software. In this case, the software included in the package can be changed according to the contract status of the user (tenant) and the software owned by the device 20. For example, a package including only software that is available by contract or software installed in the device 20 among the released software can be downloaded. However, the package may be downloaded to the device 20 in response to a user request via the device 20 or a terminal such as the PC terminal 30. In this case, the software included in the package acquired by the device 20 can be changed according to the user request. For example, in response to a user request such as a contract change or software update, the device 20 can request a package including software corresponding to the request from the cloud server.

[0171] When the device 20 downloads the package, the device 20 can install the software included in the package on the device 20. Here, a configuration may be adopted in which an activation process is further required to enable the functions of each piece of installed software. In this case, an activation process (hereinafter sometimes referred to as "enablement") is executed on a package basis or on a software basis in the device 20, thereby enabling the functions of each piece of software to be used. In other words, even if the software is installed, the user or the device 20 cannot use the functions of the software until the activation process is executed.

[0172] Depending on the software included in the package, the activation process can be performed automatically or upon request from the user.

[0173] For example, the software included in the package may be software that provides a function that does not affect the user interface of the device 20. Furthermore, when updating the version of software already installed in the device 20, the version of the software included in the package may be for improving bug fixes, virus protection, etc. In this case, the device 20 can automatically execute an activation process after installing the software. This allows the functions of the software that do not contribute to the operability of the device 20 to be enabled without user operation, thereby improving user convenience.

[0174] The device 20 can determine whether to automatically execute the activation process based on the version information of the installed software, or whether to execute the activation process according to a user's operation. For example, the leftmost "1" in the software version "V1.0.1" is called the major version, the center "0" is called the minor version, and the rightmost "1" is called the maintenance version. In this case, a change in the version due to the addition of a function is made by incrementing the minor version or major version. On the other hand, a change in the version for fixing bugs or the like in a function is made by incrementing the maintenance version. For example, when the firmware version is changed from V1.0.0 to V1.0.1, it is clear that the version change is due to the correction of bugs or the like because the maintenance version has been incremented. However, even if the version V1.0.0 is upgraded to V1.0.1, the function version remains unchanged at V1.0. In this case, since the software version included in the package is for bug corrections, virus countermeasures, and other improvements, the device 20 can automatically execute the activation process after installing the software.

[0175] However, the device 20 may determine whether to automatically execute the activation process based on the type of software or flag information assigned to the software indicating whether automatic activation processing is required, or whether to execute the activation process in response to a user operation.

[0176] On the other hand, the software included in the package may be software that provides a function that affects the user interface of the device 20. Furthermore, when updating the version of software already installed in the device 20, the version of the software included in the package may include new functions added to the previous version. Furthermore, the software included in the package may be paid software that requires a user contract. In this case, after installing the software, the device 20 can execute an activation process in response to an operation from the user. As a result, the function of the software that contributes to the operability of the device 20 is activated only when the user allows it, so the user can know that a function has been changed or a new function has been added.

[0177] A user can request activation processing of software installed in the device 20 via a terminal such as the device 20 or the PC terminal 30. The list screen 1200 shown in FIG. 29 includes, as buttons corresponding to firmware, a firmware button 1201a corresponding to "FW V1.0", a firmware button 1201b corresponding to "FW V1.1", a firmware button 1201c corresponding to "FW V1.2", and a firmware button 1201d corresponding to "FW V2.0". Furthermore, the list screen 1200 includes, as buttons for apps, an application button 1202a corresponding to "App A" and an application button 1202b corresponding to "App B". The list screen 1200 also includes a management button 1203 for performing various settings. Note that the list screen 1200 may display only a list of software or function versions that have not yet been installed or activated. Furthermore, software that is the target of the above-mentioned automatic activation processing does not need to be included in the list. The user can select software for which activation processing is to be performed from the list screen 1200. If the selected software has not yet been installed, the device 20 installs the software and then performs activation processing. Although the list screen 1200 displays the software on a software basis, the device 20 may display the software on a package basis. In this case, activation processing can be performed for all software included in the selected package or for the selected software. In addition, the software may include multiple functions. In this case, a list screen of functions included in the software selected on the list screen 1200 may be displayed, and the user may specify whether or not to perform activation processing for each function. At this time, the display of the list screen and the user's specification may be omitted by automatically performing activation processing for functions that do not affect the user interface of the device 20 among the multiple functions included in the software.

[0178] In addition, the device 20 is not limited to an image forming device as long as it is a device equipped with a communication function. The device 20 may be, for example, a PJ (Projector), an IWB (Interactive White Board: a white board having an electronic blackboard function capable of mutual communication), an output device such as a digital signage, a HUD (Head Up Display) device, an industrial machine, an imaging device, a sound collecting device, a medical device, a network home appliance, a notebook PC (Personal Computer), a mobile phone, a smartphone, a tablet terminal, a game machine, a PDA (Personal Digital Assistant), a digital camera, a wearable PC, a desktop PC, or the like.

[0179] Each function of the above-described embodiments can be realized by one or more processing circuits. Here, the term "processing circuit" in this specification includes a processor programmed to execute each function by software, such as a processor implemented by an electronic circuit, and a device such as an ASIC (Application Specific Integrated Circuit), a DSP (digital signal processor), an FPGA (field programmable gate array), or a conventional circuit module designed to execute each function described above.

[0180] Additionally, the devices described in the above embodiments are merely illustrative of one of several computing environments for implementing the embodiments disclosed herein.

[0181] In one embodiment, the service providing system 10 includes a plurality of computing devices, such as a server cluster. The plurality of computing devices are configured to communicate with each other via any type of communication link, including a network, shared memory, etc., to perform the processes disclosed herein. Similarly, the PC terminal 30 may include a plurality of computing devices configured to communicate with each other. Also, each element of the service providing system 10 and the PC terminal 30 may be integrated into one server device or may be separated into multiple devices.

[0182] In each of the above embodiments, the service providing system 10 is an example of an information processing device.

[0183] Although the embodiment of the present invention has been described in detail above, the present invention is not limited to such specific embodiment, and various modifications and variations are possible within the scope of the gist of the present invention described in the claims.

[0184] For example, aspects of the present invention are as follows. <1> a first usage status identification unit that identifies a usage status of software included in a first package that is to be used by a first tenant; a second usage status identification unit that identifies, for one or more second tenants that have switched a usage target from the first package to another second package, a usage status of software included in the first package before the switching of the usage target; a tenant identification unit that identifies, among the second tenants, a tenant having a usage situation common to the usage situation related to the first tenant; a notification unit that notifies a user belonging to a first tenant of information related to the second package related to the tenant identified by the tenant identification unit; 13. An information processing device comprising: <2> the tenant identification unit identifies, from among the second tenants, a tenant having a similarity higher than a predetermined threshold as a first tenant; Characterized by <1> The information processing device described in <3> the tenant identification unit calculates the similarity by assigning a first coefficient having a larger value to each piece of software included in the first package in descending order of frequency of use, and assigning a second coefficient having a larger value to each piece of software included in the second package in descending order of frequency of use. Characterized by <2> The information processing device described in <4> The first usage status identification unit classifies the usage status of the first package by the first tenant based on a purpose, The second usage status identification unit classifies the usage status of the first package by the second tenant according to purpose; the tenant identification unit further identifies, from the second tenants, a tenant having a common usage status classification result with the usage status classification result related to the first tenant; Characterized by <1> ~ <3> 2. An information processing device according to claim 1 . <5> The tenant identification unit further identifies, among the second tenants, a tenant in a business type common to a business type of the first tenant. Characterized by <1> ~ <4> 2. An information processing device according to claim 1 . <6> the tenant identification unit identifies a tenant whose usage status identified by the second usage status identification unit within a predetermined period prior to a timing at which the notification unit notifies the information on the second package related to the tenant identified by the tenant identification unit is common to that identified by the first usage status identification unit within the predetermined period; Characterized by <1> ~ <5> 2. An information processing device according to claim 1 . <7> An information processing system including a terminal and an information processing device, The information processing device includes: a first usage status identification unit that identifies a usage status of software included in a first package that is to be used by a first tenant; a second usage status identification unit that identifies, for one or more second tenants that have switched a usage target from the first package to another second package, a usage status of software included in the first package before the switching of the usage target; a tenant identification unit that identifies, among the second tenants, a tenant having a usage situation common to the usage situation related to the first tenant; a notification unit that notifies a user belonging to a first tenant of information related to the second package related to the tenant identified by the tenant identification unit; An information processing system comprising: <8> a first usage status identification step of identifying a usage status of software included in a first package to be used by a first tenant; a second usage status identification step of identifying, for one or more second tenants that have switched the target of use from the first package to another second package, a usage status of software included in the first package before the target of use is switched; a tenant identification step of identifying a tenant having a usage situation common to the usage situation related to the first tenant, among the second tenants; a notification step of notifying a user belonging to a first tenant of information related to the second package related to the tenant identified in the tenant identification step; An information processing method characterized by being executed by a computer. <9> a first usage status identification step of identifying a usage status of software included in a first package to be used by a first tenant; a second usage status identification step of identifying, for one or more second tenants that have switched the target of use from the first package to another second package, a usage status of software included in the first package before the target of use is switched; a tenant identification step of identifying a tenant having a usage situation common to the usage situation related to the first tenant, among the second tenants; a notification step of notifying a user belonging to a first tenant of information related to the second package related to the tenant identified in the tenant identification step; A program characterized by causing a computer to execute the above. [Explanation of symbols]

[0185] 1. Information Processing Systems 10 Service provision system 11 Input Devices 12 Display device 13 External I / F 14 RAM (Random Access Memory) 15 ROM (Read Only Memory) 16 CPU(Central Processing Unit) 17 Communication I / F 18 HDD (Hard Disk Drive) 20 equipment 21 Controller 22 Operation Panel 23 External I / F 24 Communication I / F 25 Printers 26 Scanner 30 PC terminals 31 CPU 32 RAM 33 ROM 34 NVRAM 35 HDD 101 Document Services 102 Input / Output Services 103 Web Applications 104 Application information storage unit 105 Database 121 App Management Department 122 I / O logic processing unit 123 Authentication Department 131 Screen generation section 132 Database processing section 133 Authentication Department 141 Proposal Destination Utilization Identification Department 142 Reference candidate usage status identification section 143 Reference Tenant Identification Department 144 Proposal Package Information Acquisition Unit 145 Output section 151 App Management Table 152 Package Management Table 153 Package App Management Table 154 Tenant Management Table 155 Contract Package Management Table 156 Package Change History Management Table 157 App execution log table 301 Screen drawing section [Prior art documents] [Patent documents]

[0186] [Patent Document 1] JP 2022-045324 A

Claims

1. a first usage status identification unit that identifies a usage status of software included in a first package that is to be used by a first tenant; a second usage status identification unit that identifies, for one or more second tenants that have switched a usage target from the first package to another second package, a usage status of software included in the first package before the switching of the usage target; a tenant identification unit that identifies, among the second tenants, a tenant having a usage situation common to the usage situation related to the first tenant; a notification unit that notifies a user belonging to a first tenant of information related to the second package related to the tenant identified by the tenant identification unit; 13. An information processing device comprising:

2. the tenant identification unit identifies, from the second tenants, a tenant having a similarity higher than a predetermined threshold; 2. The information processing apparatus according to claim 1,

3. the tenant identification unit calculates the similarity by assigning a first coefficient having a larger value to each piece of software included in the first package in descending order of frequency of use, and assigning a second coefficient having a larger value to each piece of software included in the second package in descending order of frequency of use.

3. The information processing apparatus according to claim 2.

4. The first usage status identification unit classifies the usage status of the first package by the first tenant based on a purpose, The second usage status identification unit classifies the usage status of the first package by the second tenant according to purpose; The tenant identification unit further identifies, from the second tenants, a tenant having a common usage status classification result with the usage status classification result related to the first tenant.

2. The information processing apparatus according to claim 1,

5. The tenant identification unit further identifies, among the second tenants, a tenant in a business type common to a business type of the first tenant.

2. The information processing apparatus according to claim 1,

6. the tenant identification unit identifies a tenant whose usage status identified by the second usage status identification unit within a predetermined period prior to a timing at which the notification unit notifies the information on the second package related to the tenant identified by the tenant identification unit is common to that of the first usage status identification unit within the predetermined period; 2. The information processing apparatus according to claim 1,

7. An information processing system including a terminal and an information processing device, The information processing device includes: a first usage status identification unit that identifies a usage status of software included in a first package that is to be used by a first tenant; a second usage status identification unit that identifies, for one or more second tenants that have switched a usage target from the first package to another second package, a usage status of software included in the first package before the switching of the usage target; a tenant identification unit that identifies, among the second tenants, a tenant having a usage situation common to the usage situation related to the first tenant; a notification unit that notifies a user belonging to a first tenant of information related to the second package related to the tenant identified by the tenant identification unit; An information processing system comprising:

8. a first usage status identification step of identifying a usage status of software included in a first package to be used by a first tenant; a second usage status identification step of identifying, for one or more second tenants that have switched a usage target from the first package to another second package, a usage status of software included in the first package before the switching of the usage target; a tenant identification step of identifying a tenant having a usage situation common to the usage situation related to the first tenant among the second tenants; a notification step of notifying a user belonging to a first tenant of information related to the second package related to the tenant identified in the tenant identification step; An information processing method characterized by being executed by a computer.

9. a first usage status identification step of identifying a usage status of software included in a first package to be used by a first tenant; a second usage status identification step of identifying, for one or more second tenants that have switched a usage target from the first package to another second package, a usage status of software included in the first package before the switching of the usage target; a tenant identification step of identifying a tenant having a usage situation common to the usage situation related to the first tenant among the second tenants; a notification step of notifying a user belonging to a first tenant of information related to the second package related to the tenant identified in the tenant identification step; A program characterized by causing a computer to execute the above.

Images