Cloud system, delivery method, and program

Abstract

To allow easy use of any application in each of multiple service developer systems. [Solution] The cloud system (1) can cooperate with each of the multiple service developer systems (2). The data storage unit (100) stores application data related to multiple applications managed by the cloud system (1). The application usage function provision unit (121) provides each of the multiple service developer systems (2) with an application usage function to make any application from among the multiple applications available for use in the service developer system (2).

Description

Technical Field

[0001] The present disclosure relates to a cloud system, a provision method, and a program.

Background Art

[0002] Conventionally, a cloud system for managing applications on the cloud has been known. For example, in Patent Document 1, a resource storage address and a provision timing are managed in association with each other, and when the provision timing is detected, the resource storage address of the Web application at the provision timing is transmitted to a communication terminal so as to cache the resources of the Web application at the provision timing for the communication terminal related to the provision timing. An application provision system is described.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] However, the technique of Patent Document 1 merely deploys and provides any one of a plurality of applications managed by a server to a resource storage address according to a provision timing, and thus is not assumed to cooperate with a plurality of service developer systems. For this reason, with the technique of Patent Document 1, any Web application could not be easily used in each of a plurality of service developer systems. [[ID=@37]]

[0005] One object of the present disclosure is to enable any application to be easily used in each of a plurality of service developer systems.

Means for Solving the Problems

[0006] One aspect of this disclosure relates to a cloud system that can cooperate with each of a plurality of service developer systems, and includes a data storage unit that stores application data relating to a plurality of applications managed by the cloud system, and an application usage function provision unit that provides each of the plurality of service developer systems with an application usage function to make any of the plurality of applications available for use in the service developer system. [Effects of the Invention]

[0007] According to this disclosure, any application can be easily made available in each of multiple service developer systems. [Brief explanation of the drawing]

[0008] [Figure 1] This figure shows an example of the hardware configuration of the cloud system according to the first embodiment. [Figure 2] This figure shows an example of the relationship between the cloud system and the service developer system in the first embodiment. [Figure 3] This figure shows an example of a screen displayed on the user terminal of the first embodiment. [Figure 4] This figure shows an example of a screen displayed on the user terminal of the first embodiment. [Figure 5] This figure shows an example of a screen displayed on the user terminal of the first embodiment. [Figure 6] This figure shows an example of the functions implemented in the cloud system of the first embodiment. [Figure 7] This figure shows an example of a user database in the first embodiment. [Figure 8] This figure shows an example of processing performed in the cloud system of the first embodiment. [Figure 9] This figure shows an example of processing performed in the cloud system of the first embodiment. [Figure 10] This figure shows an example of the hardware configuration of the cloud system in the second embodiment. [Figure 11]This figure shows an example of the functions implemented in the cloud system of the second embodiment. [Figure 12] This figure shows an example of a synchronous database in the second embodiment. [Figure 13] This figure shows an example of processing performed in the cloud system of the second embodiment. [Figure 14] This figure shows an example of a function realized by a modification of the first embodiment. [Figure 15] This figure shows an example of a function realized in a modified version of the second embodiment. [Modes for carrying out the invention]

[0009] [1. First Embodiment] This document describes a first embodiment, which is an example of an embodiment of the cloud system, application usage method, and program related to this disclosure.

[0010] [1-1. Hardware configuration of the cloud system in the first embodiment] Figure 1 shows an example of the hardware configuration of a cloud system according to the first embodiment. For example, cloud system 1 includes an application server 10 and an authentication server 11. Cloud system 1 is connected to a network N such as the Internet or a LAN. In the example in Figure 1, multiple service developer systems 2, multiple authentication systems 3, and multiple user terminals 4 are further connected to the network N.

[0011] The application server 10 is a server computer. For example, the application server 10 includes a control unit 10A, a storage unit 10B, and a communication unit 10C. The control unit 10A includes at least one processor. The storage unit 10B includes at least one of volatile memory such as RAM and non-volatile memory such as flash memory. The communication unit 10C includes at least one of a communication interface for wired communication and a communication interface for wireless communication.

[0012] The authentication server 11 is a server computer. For example, the authentication server 11 includes a control unit 11A, a storage unit 11B, and a communication unit 11C. The hardware configurations of the control unit 11A, the storage unit 11B, and the communication unit 11C may be the same as those of the control unit 10A, the storage unit 10B, and the communication unit 10C, respectively.

[0013] In addition, the programs stored in the storage units 10B and 11B may be supplied via the network N. The hardware configurations of each of the application server 10 and the authentication server 11 are not limited to the example in FIG. 1. For example, each of the application server 10 and the authentication server 11 may include at least one of a reading unit (e.g., a memory card slot) for reading a computer-readable information storage medium and an input / output unit (e.g., a USB terminal) for directly connecting to an external device. The program stored in the information storage medium may be supplied to each of the application server 10 and the authentication server 11 via at least one of the reading unit and the input / output unit.

[0014] Also, the computers included in the cloud system 1 are not limited to the example in FIG. 1. The cloud system 1 may include at least one computer. For example, the cloud system 1 may include only the application server 10. In this case, the authentication server 11 may exist outside the cloud system 1. The authentication server 11 may not exist at all. The cloud system 1 may include the application server 10 and a computer not shown in FIG. 1 (e.g., a computer of an administrator who manages the cloud system 1). The cloud system 1 may include only the authentication server 11. In this case, the application server 10 may exist outside the cloud system 1. The cloud system 1 may include only the computer not shown in FIG. 1.

[0015] Service Developer System 2 is a system for service developers. A service developer is a person who develops software to provide a specified service to a user. Hereafter, the services provided by a service developer will be referred to as developer services. Developer services may be any service. For example, developer services may be groupware, cloud accounting services, services to assist in website creation, services to manage files on the cloud, services to manage emails on the cloud, or other services.

[0016] For example, a service developer may be a SaaS (Software as a Service) company, a company called an SIer (System Integrator), a company not classified as such, an organization not classified as a company, or an individual. For example, service developer system 2 includes at least one server computer. The hardware configuration of the server computer included in service developer system 2 may be the same as that of application server 10 or authentication server 11.

[0017] Authentication system 3 is a system that performs authentication for services handled by the service developer. For example, authentication system 3 may be a system called IdP (Identity Provider). In the first embodiment, an example is given where authentication system 3 performs knowledge authentication to verify the legitimacy of login accounts and passwords. The authentication performed by authentication system 3 is not limited to the example of the first embodiment. For example, authentication system 3 may perform other knowledge authentication, possession authentication, or biometric authentication. For example, authentication system 3 includes at least one server computer. The hardware configuration of the server computer included in authentication system 3 may be the same as that of application server 10 or authentication server 11.

[0018] User terminal 4 is the computer of a user utilizing the service developer system 2. In the first embodiment, we take the example of a case where, when a service developer contracts with the cloud system 1, users who were already using the service developer system 2 are added as users of the cloud system 1 and become able to use the cloud system 1. Since the service developer is also in a position to contract with and use the cloud service, the term "user" in the first embodiment refers to the end user. For example, user terminal 4 is a personal computer, tablet, smartphone, or wearable device.

[0019] [1-2. Overview of the Cloud System in the First Embodiment] In the first embodiment, the cloud system 1 can cooperate with each of the multiple service developer systems 2. The ability of the cloud system 1 to cooperate with the service developer systems 2 means that the cloud system 1 can communicate with the service developer systems 2 via the network N. The cloud system 1 can cooperate not only with the multiple service developer systems 2, but also with each of the multiple authentication systems 3. By cooperating with the service developer systems 2 and the authentication systems 3, the cloud system 1 provides a cloud service that allows users to use applications.

[0020] An application is a program that can run on the cloud. An application may include data that the program references. In the first embodiment, the application server 10 stores the application as an example, but the application may be stored on a computer other than the application server 10. An application may be developed for any purpose. For example, an application may be developed to provide users with services related to developer services, or it may be developed to provide users with services that are not particularly related to developer services.

[0021] For example, a user may access and use an application on the cloud from a browser, or they may access and use an application on the cloud from a dedicated program installed on user terminal 4. The application may not run on the cloud, but may be downloaded to user terminal 4 and run on user terminal 4. For cloud system 1 to allow a user to use an application means that cloud system 1 grants the user access to the application. In other words, cloud system 1 executing an application in response to a request from user terminal 4 is equivalent to cloud system 1 allowing a user to use an application.

[0022] In the first embodiment, we take the example of a cloud service provider developing an application. The application developer is not limited to a cloud service provider. The application developer may be a service developer, or another party other than a cloud service provider or service developer. A cloud service may contain a mix of various applications developed by various application developers. For example, when a service developer contracts for a cloud service, users of that service developer's service developer system 2 become able to use the application.

[0023] Figure 2 shows an example of the relationship between the cloud system 1 and the service developer system 2 in the first embodiment. In Figure 2, the authentication system 3 is omitted. As shown in Figure 2, the cloud system 1 is assumed to be linked with the service developer system 2 of a service developer that develops groupware A, the service developer system 2 of a service developer that develops cloud accounting software B, and the service developer system 2 of a service developer that develops website creation software C. The cloud service will handle a chat application 1, a bulletin board application 2, and an application 3 that manages user schedules. The service developer can contract for any of the applications 1 to 3 in the cloud service.

[0024] In the example in Figure 2, groupware A has 3 million users. Cloud accounting software B has 10 million users. Website creation software C has 2 million users. When these three service developers subscribe to the cloud service, the users of these three service developers are counted as users of the cloud service. Therefore, the number of users of the cloud service becomes 15 million, which is the sum of the users of these three service developers. When a new service developer subscribes to the cloud service, the existing users of that new service developer are added as users of the cloud service, so the number of users of the cloud service increases by the number of users of that new service developer.

[0025] For example, a user of groupware A can use user terminal 4 to access the service developer system 2 for groupware A to use developer services, and also access cloud system 1 to use cloud services. A user of cloud accounting software B can use user terminal 4 to access the service developer system 2 for cloud accounting software B to use developer services, and also access cloud system 1 to use cloud services. A user of website creation software C can use user terminal 4 to access the service developer system 2 for website creation software C to use developer services, and also access cloud system 1 to use cloud services.

[0026] Figures 3 to 5 show examples of screens displayed on the user terminal 4 in the first embodiment. Figures 3 to 5 show examples of screens displayed on the user terminal 4 of a user using the cloud accounting software B. For example, if a user specifies the URL of the cloud accounting software B in the browser of the user terminal 4 while not logged into the cloud accounting software, the user terminal 4 communicates with the service developer system 2 of the cloud accounting software B and displays the login page P1 for the user to log in to the cloud accounting software B in the browser.

[0027] For example, Cloud Accounting Software B provides users with multiple developer services, such as accounting services specializing in accounting, business startup services specializing in business startup, invoicing services specializing in invoices, and employee benefits services specializing in employee benefits. Users can log in to Cloud Accounting Software B by selecting any of the multiple developer services of Cloud Accounting Software B. In the first embodiment, it is assumed that the user's login account and password are the same for each of the multiple developer services of Cloud Accounting Software B.

[0028] In the upper example of Figure 3, login page P1 is displayed when a user selects the URL of the accounting service while not logged in. When the user enters their login account and password for cloud accounting software B on login page P1, the authentication system 3 of cloud accounting software B verifies the validity of the login account and password. After verifying the validity of the login account and password, the authentication system 3 of cloud accounting software B issues an ID token to verify the user based on OIDC (OpenID Connect), which is an example of an authentication protocol. Details of the ID token will be described later.

[0029] For example, when a user logs into the accounting service, a session is established between the authentication system 3 and the user terminal 4. Separately from this session, after the validity of the ID token is verified, a session is established between the accounting service and the user terminal 4. Session identification information that can identify the session between the authentication system 3 and the user terminal 4, and session identification information that can identify the session between the accounting service and the user terminal 4, are stored in the browser of the user terminal 4 (for example, in the browser's cookie storage area).

[0030] Session identification information consists of letters, numbers, other symbols, or a combination thereof. Session identification information is sometimes called a session ID. Session identification information may have an expiration date. The method for issuing session identification information may be the same as known methods. In the first embodiment, the service developer system 2 and the authentication system 3 can identify that a user is logged in using the session identification information. The user can then log in to other services and use other services without having to log in again from other developer services of the cloud accounting software B. In other words, single sign-on is achieved.

[0031] For example, when a user logs into the accounting service, as shown in the lower part of Figure 3, the user terminal 4 communicates with the service developer system 2 of the cloud accounting software B and displays the top page P2 of the cloud accounting software B in the browser. The top page P2 may be common to all tenants that have a contract with the cloud accounting software B (for example, the company where the user works), or it may be prepared for each tenant. When the user selects an accounting service on the top page P2, as shown in the upper part of Figure 4, the user terminal 4 displays the service usage page P3, which shows the various functions of the accounting service, in the browser.

[0032] In the upper example of Figure 4, the user can switch between developer services of the cloud accounting software B by selecting other developer services from the service usage page P3. For example, when the user selects icon I30, the user terminal 4 displays a list L31 on the service usage page P3, showing the developer services available to the user, as shown in the lower example of Figure 4. In the lower example of Figure 4, list L31 shows not only the developer services of the cloud accounting software B, but also apps available to the user (in the lower example of Figure 4, "XXX Chat"). In other words, apps are shown in list L31 in the same way as developer services.

[0033] For example, each of the multiple developer services in List L31 (in the lower example of Figure 4, accounting services, business startup services, invoicing services, and employee benefits services) indicates a link to the service developer system 2. The apps in List L31 indicate a link to the app server 10. If a service developer has contracted for multiple apps, List L31 indicates the link to each of the apps. If there are multiple app servers 10, the app server 10 indicated by the link for one app may be different from the app server 10 indicated by the link for another app.

[0034] For example, when a user selects a business startup service from list L31, the authentication system 3 of the cloud accounting software B obtains session identification information for the session between the user terminal 4 and the authentication system 3 of the cloud accounting software B. The authentication system 3 of the cloud accounting software B verifies the validity of this session identification information. This verification of validity can also be interpreted as determining whether or not the user is logged in. If a user has valid session identification information, it means that the user is logged in and therefore trustworthy.

[0035] For example, once the validity of the session identification information for the session between user terminal 4 and authentication system 3 is verified, the authentication system 3 of cloud accounting software B issues an ID token for the business startup service. After the validity of the ID token for the business startup service is verified, user terminal 4 establishes a session with the business startup service without having to log in again, and displays the service usage page P3 for the business startup service in the browser. Similarly, if the user selects the invoicing service in list L31, or if the user selects the employee benefits service in list L31, user terminal 4 displays the service usage page P3 for the invoicing service or employee benefits service in the browser without having to log in again.

[0036] In the first embodiment, a similar mechanism enables single sign-on, eliminating the need for repeated logins, not only when a user utilizes the developer services of the cloud accounting software B, but also when they use applications of the cloud service. For example, if a service developer operating the service developer system 2 of the cloud accounting software B has contracted to use application 1, then "XXX Chat," the name of application 1, will be shown in list L31, as shown in the lower part of Figure 4. Users can select application 1 from list L31 and use application 1 with the same ease as using each of the developer services of the cloud accounting software B.

[0037] For example, when a user selects App 1 from list L31, as shown in the upper part of Figure 5, the user terminal 4 activates the side panel function, which is a browser extension, and displays the side panel P32 in the browser. The application server 10 of the cloud system 1 obtains session identification information for the session between the user terminal 4 and the authentication system 3 of the cloud accounting software B. The application server 10 transmits the session identification information to the authentication system 3 of the cloud accounting software B via the authentication server 11.

[0038] The authentication server 11 may also obtain session identification information directly from the user terminal 4. In this case, the authentication server 11 sends the session identification information to the authentication system 3 of the cloud accounting software B. The application server 10 or the authentication server 11 may also cause the authentication system 3 of the cloud accounting software B to obtain the session identification information by redirecting the user terminal 4 to the authentication system 3 of the cloud accounting software B. In addition, although Figure 5 shows a case where the application screen is displayed by the side panel function, the application screen may be displayed in the entire browser instead of using the side panel function. The application screen may also be displayed on a program other than the browser (for example, a program dedicated to the cloud service).

[0039] For example, the authentication system 3 of the cloud accounting software B verifies the validity of the session identifier. In the upper example of Figure 5, the validity of the session identifier is being verified, so the specific content of the chat provided by app 1 is not yet displayed on side panel P32. Once the validity of the session identifier is verified, the authentication system 3 of the cloud accounting software B issues an ID token for app 1. The ID token for app 1 establishes a session between app 1 and user terminal 4. As shown in the lower part of Figure 5, user terminal 4 communicates with the app server 10 and displays the specific content of the chat on side panel P32.

[0040] As shown in the lower part of Figure 3, App 1 may also be selectable from the top page P2 of the cloud accounting software B. Similar to List L31, each of the multiple developer services on the top page P2 (in the example in the lower part of Figure 3, accounting services, business startup services, invoicing services, and employee benefits services) indicates a link to the service developer system 2. Apps on the top page P2 indicate a link to the app server 10. Apps are displayed on the top page P2 in the same way as developer services. The user terminal 4 accesses the link destination corresponding to the developer service or app selected by the user from the top page P2.

[0041] For example, if a user selects App 1 on the top page P2 of Cloud Accounting Software B, and the user is already logged in, User Terminal 4 will display the side panel P32 in the browser, similar to the lower part of Figure 5, without requiring the user to log in again. If the user is not yet logged in, the top page P2 of Cloud Accounting Software B will not be displayed, so User Terminal 4 will display the login page P1 in the browser, similar to the upper part of Figure 3. Upon successful login, an ID token will be issued, and User Terminal 4 will display the side panel P32 in the browser, similar to the lower part of Figure 5.

[0042] As described above, the cloud system 1 of the first embodiment allows users to use applications managed by the cloud system 1 based on an ID token that proves the user's identity in the service developer system 2. This enables the cloud system 1 to appropriately allow each user of multiple service developer systems 2 to use the applications. The details of the cloud system 1 will be described below.

[0043] [1-3. Functions realized by the cloud system of the first embodiment] Figure 6 shows an example of the functions implemented in the cloud system 1 of the first embodiment. In Figure 6, the functions implemented in the application server 10 and the authentication server 11 are shown. Figure 6 also shows the functions implemented in the service developer system 2, the authentication system 3, and the user terminal 4.

[0044] [1-3-1. Functions implemented in the application server of the first embodiment] For example, the application server 10 implements a data storage unit 100, an ID token acquisition unit 101, and an application usage unit 102. The data storage unit 100 is implemented by a storage unit 10B. The ID token acquisition unit 101 and the application usage unit 102 are implemented by a control unit 10A.

[0045] [Data Storage Unit] The data storage unit 100 stores various data necessary for the cloud service. In the first embodiment, we take the example of a case where the data storage unit 100 has a storage area corresponding to each of multiple service developers. That is, the storage area of ​​the data storage unit 100 is divided for each service developer. Since a service developer contracts for a cloud service and users of the developer service provided by the service developer use the cloud service application, the storage area of ​​the data storage unit 100 is divided for each service developer who is a tenant of the cloud service. For example, in the storage area of ​​the data storage unit 100 for a certain service developer, a user database DB1 containing various information about the service developer's users is stored.

[0046] Figure 7 shows an example of a user database DB1 in the first embodiment. The user database DB1 is a database that stores various information about users of the service developer system 2 corresponding to the storage area where the user database DB1 is stored. For example, the user database DB1 stores the cloud service user ID, the developer service user ID, user information, and session identification information for the session between the application and the user terminal 4. The information stored in the user database DB1 is not limited to the example in Figure 7. The user database DB1 may store any information. For example, the user database DB1 may store a service developer ID that can identify the service developer, or it may store an ID token.

[0047] A cloud service user ID is information that allows a user to be identified within the cloud service. In other words, a cloud service user ID is a user ID issued by the cloud service provider. A developer service user ID is information that allows a user to be identified within the developer service. In other words, a developer service user ID is a user ID issued by the developer service provider. For example, a developer service user ID may be user identification information called "sub" included in the ID token, or it may be information not included in the ID token.

[0048] Note that the user ID for the developer service may be the same as the login account for the user used in the service developer system 2, but in the first embodiment, it shall be different from the login account. The login account for the user used in the service developer system 2 may be shared with the cloud system 1, but in the first embodiment, it shall not be shared with the cloud system 1. The cloud system 1 does not manage the login account for the user used in the service developer system 2.

[0049] For example, when a service developer operating a service developer system 2 enters into an application usage agreement, each of the multiple users of the service developer system 2 becomes a user of the cloud system 1. Therefore, the application server 10 issues a user ID for the cloud service for each user and obtains various information, such as the user ID for each user's developer service, from the service developer system 2. The application server 10 stores the service developer ID of the service developer system 2, the user ID for each user's cloud service, the user ID for each user's developer service, and user information in association in the user database DB1.

[0050] User information is information about a user. User information is different from the user ID. For example, user information may be the user's profile (e.g., name or affiliation). User information may be obtained from the service developer system 2 and stored in the user database DB1. If user information is obtained independently by the cloud service, the user information obtained independently by the cloud service may be stored in the user database DB1.

[0051] Session identification information for a session between an application and user terminal 4 is stored in the user database DB1 once a session is established between the application and user terminal 4. When a user terminal 4 establishes sessions with multiple applications, session identification information for the sessions between each of the applications and the user terminal 4 is stored in the user database DB1.

[0052] The data stored in the data storage unit 100 is not limited to the examples above. The data storage unit 100 can store any data. For example, the data storage unit 100 may store application data, which is the actual data of each of multiple applications. The data storage unit 100 may also store data that a user has registered in an application. If the storage area of ​​the data storage unit 100 is divided for each service developer system 2, the storage area of ​​each service developer system 2 may store the actual data of the applications used by that service developer system 2 and the data that a user has registered in that application.

[0053] Furthermore, the storage area of ​​the data storage unit 100 does not need to be separated for each service developer. In this case, the data storage unit 100 may store a single user database DB1 that stores various information for each user of multiple service developers. This user database DB1 may store the service developer ID, the cloud service user ID, the developer service user ID, user information, and session identification information. The service developer ID may be information that can identify the developer operating the service developer system 2, or information that can identify the service that the service developer system 2 provides to the user. When a new service developer system 2 starts coordinating with the cloud system 1, the application server 10 issues a service developer ID for the new service developer system 2 and stores it in the user database DB1 so as not to overlap with other service developer IDs.

[0054] [ID Token Acquisition Section] The ID token acquisition unit 101 acquires an ID token that proves the user of a service developer system 2 that uses an application managed by the cloud system 1, among multiple service developer systems 2, and is different from the login account used by the user to log in to the service developer system 2.

[0055] An ID token is information that proves who a user is. ID tokens are issued by an authentication protocol called OIDC. In the first embodiment, when a user logs in to authentication system 3, authentication system 3 issues an ID token. For example, the ID token shows the issuer's information, the user ID of the developer service, information that identifies the target of the ID token issuance (e.g., an app or developer service), an expiration date, the user's email address, the user's name, or a combination of these. The ID token is signed to prevent tampering.

[0056] In the first embodiment, the authentication system 3 issues an ID token, so the ID token acquisition unit 101 acquires the ID token from the authentication system 3. Furthermore, since the intermediary unit 111 of the authentication server 11 mediates communication between the application server 10 and the authentication system 3, the ID token acquisition unit 101 acquires the ID token from the intermediary unit 111. In particular, if the authentication server 11 does not perform mediation, the ID token acquisition unit 101 may acquire the ID token directly from the authentication system 3. If the ID token is stored in the data storage unit 100, another computer other than the application server 10 (for example, the authentication server 11, the service developer system 2, the authentication system 3, or the user terminal 4), or in an information storage medium, the ID token acquisition unit 101 may acquire the ID token from the data storage unit 100, the other computer, or the information storage medium.

[0057] For example, the ID token acquisition unit 101 may acquire an ID token without requiring the user to log in to the authentication system 3 again, when the user selects an application while the login session of the authentication system 3, which issues an ID token when the user logs in, is valid. The login session of the authentication system 3 is a session established when the user terminal 4 logs into the authentication system 3, and is a session between the authentication system 3 and the user terminal 4. The login session of the authentication system 3 may have an expiration date. The expiration date may be included in the ID token. The validity of the login session is determined by the session identification information of the session between the authentication system 3 and the user terminal 4.

[0058] In the first embodiment, each of the multiple service developer systems 2 has an authentication system 3 that authenticates the user in the developer services that the service developer system 2 provides to the user. The ID token acquisition unit 101 acquires an ID token issued by the authentication system 3 of the service developer system 2. For example, when a user selects an application on a user terminal 4, the ID token acquisition unit 101 queries the authentication system 3 to determine whether a login session with the user terminal 4 is valid.

[0059] The authentication server 11 may also mediate the above inquiry. The authentication system 3 issues an ID token and sends it to the cloud system 1 if the login session with the user terminal 4 is valid. The ID token acquisition unit 101 acquires the ID token issued by the authentication system 3. If the authentication server 11 acts as an intermediary, the ID token acquisition unit 101 acquires the ID token from the authentication system 3 via the authentication server 11. The authentication server 11 may also function as a client in the OIDC. The ID token acquisition unit 101 may acquire the ID token from the authentication system 3 via the authentication server 11, which functions as a client in the OIDC.

[0060] Furthermore, if the user selects an app while the login session for authentication system 3 is not valid, the user may attempt to log in to authentication system 3 again. In this case, if the re-login is successful, the ID token acquisition unit 101 may obtain an ID token issued by authentication system 3 from authentication system 3. If authentication server 11 mediates communication between app server 10 and authentication system 3, the ID token acquisition unit 101 may obtain an ID token from mediation unit 111. The ID token acquisition unit 101 sends the ID token to user terminal 4. The ID token acquisition unit 101 may also obtain an ID token issued by another issuing entity other than authentication system 3 (for example, authentication server 11).

[0061] [App Usage Section] The application usage unit 102 allows the user to use the application based on the ID token. For example, the application usage unit 102 verifies the validity of the ID token. The method for verifying the validity of the ID token may be the same as a publicly known method. If the ID token is signed with the private key of the authentication system 3 that issued the ID token, the application usage unit 102 may verify the signature of the ID token based on the public key corresponding to the private key. If the application usage unit 102 confirms the legitimacy of the signature of the ID token, it determines that the ID token is valid.

[0062] For example, if the application usage unit 102 determines that the ID token is valid, it establishes a session between the application and the user terminal 4. Based on the developer service user ID contained in the ID token, the application usage unit 102 identifies which user is attempting to establish the session. The application usage unit 102 issues session identification information for the session between the application and the user terminal 4 and stores it in the user database DB1 in association with the user ID of the identified user. The application usage unit 102 sends the session identification information for the session between the application and the user terminal 4 to the user terminal 4. The user terminal 4 stores the session identification information for the session between the application and the user terminal 4 in a browser cookie.

[0063] For example, if the application usage unit 102 determines that the ID token is not valid, it will not establish a session between the application and the user terminal 4. In this case, the application usage unit 102 requests the authentication server 11 to issue an ID token with the authentication system 3. If a session has been established between the authentication system 3 and the user terminal 4 (i.e., if the user has already logged into the authentication system 3), the authentication system 3 will issue an ID token. The ID token acquisition unit 101 acquires the ID token via the authentication server 11. The application usage unit 102 verifies the validity of the ID token.

[0064] In the first embodiment, the application usage unit 102 allows the user to use the application based on the ID token without requiring the user to log in to the authentication system 3 again. That is, if the application usage unit 102 determines that the ID token is valid, it establishes a session between the application and the user terminal 4 without requiring the user to log in to the authentication system 3 again. After the session between the application and the user terminal 4 is established, the application usage unit 102 displays the application screen on the user terminal 4. The application usage unit 102 executes the application based on the user's actions on the application screen. For example, the application usage unit 102 may record files uploaded by the user using the application in the data storage unit 100.

[0065] For example, the application user unit 102 may establish a session between the application and the user terminal 4 on the condition that the user attempts to log in to the authentication system 3 again if it determines that the ID token is invalid. However, if a session has already been established between the authentication system 3 and the user terminal 4 (i.e., the user has already logged in to the authentication system 3), the authentication system 3 will issue an ID token even if the user does not attempt to log in to the authentication system 3 again, so a second login is unnecessary.

[0066] For example, the application user unit 102 may obtain session identification information for the session between the authentication system 3 and the user terminal 4 from the user terminal 4 and send the session identification information to the authentication system 3 via the authentication server 11 or directly, or it may redirect the user terminal 4 to the authentication system 3 and have the user terminal 4 send the session identification information contained in the cookie. The authentication system 3 verifies the validity of the session identification information. The authentication system 3 also stores the session identification information. The authentication system 3 verifies the validity by determining whether the session identification information it stores matches the session identification information obtained from the user terminal 4. The authentication system 3 may also determine whether the session identification information is within its validity period.

[0067] For example, if the authentication system 3 determines that the session identification information is valid through the processing of the ID token issuance unit 300 described later, it issues an ID token. If the authentication system 3 does not determine that the session identification information is valid, or if the session identification information does not exist, it performs a login with the user terminal 4. If the login is successful, session identification information for the session between the authentication system 3 and the user terminal 4 is issued. This session information is stored in the cookie of the user terminal 4.

[0068] [1-3-2. Functions implemented by the authentication server of the first embodiment] For example, in the authentication server 11, a data storage unit 110 and an intermediary unit 111 are implemented. The data storage unit 110 is implemented by the storage unit 11B. The intermediary unit 111 is implemented by the control unit 11A.

[0069] [Data Storage Unit] The data storage unit 110 stores data necessary for communication with the authentication system 3. For example, the data storage unit 110 stores various data of the authentication system 3 corresponding to each of the multiple service developer systems 2. The data storage unit 110 also stores the program necessary for the authentication server 11 to function as an OIDC client.

[0070] [Intermediary Department] The intermediary unit 111 acts as an intermediary between the application and the authentication system 3, and as a client of the authentication system 3, obtains an ID token from the authentication system 3. For example, the intermediary unit 111 receives a request for processing between the application server 10 and the authentication system 3. The intermediary unit 111 may obtain browser cookie information from the application server 10 or the user terminal 4 and send it to the authentication system 3, or it may redirect the user terminal 4 to the authentication system 3 to send the browser cookie information to the authentication system 3. For example, once the intermediary unit 111 obtains an ID token from the authentication system 3, it forwards it to the application server 10.

[0071] [1-3-3. Functions implemented in the service developer system of the first embodiment] For example, the service developer system 2 includes a service provision unit 200. The service provision unit 200 is implemented by the control unit of the server computer of the service developer system 2 (for example, a control unit having a hardware configuration similar to control units 10A and 11A). The service provision unit 200 provides developer services to the user. For example, when the service provision unit 200 obtains a valid ID token from the user terminal 4, it establishes a session with the user terminal 4 and displays the service usage page P3 on the user terminal 4, thereby providing developer services to the user.

[0072] For example, the service developer system 2 stores display data for displaying the top page P2 and the service usage page P3 on the user terminal 4. The display data may be in any format. The display data may also be data in a markup language such as HTML. When a service developer subscribes to a cloud service and a certain application becomes available, the display data on the top page P2 and the service usage page P3 will indicate a link to that application.

[0073] In the examples in Figures 3 and 4, the developer service and the application are treated similarly on the top page P2 and the service usage page P3. Therefore, the display data on the top page P2 and the service usage page P3 shows links to the developer service and links to the application. Based on this display data, the service provision unit 200 displays the top page P2 and the service usage page P3 on the user terminal 4.

[0074] For example, the service developer system 2 may store user IDs and user information in the developer service. The service developer system 2 can store various information for providing developer services to users. This information may be stored in a system other than the service developer system 2. The other system may be the authentication system 3, or a system different from the authentication system 3. The service developer system 2 may store session identification information for the session between the developer service and the user terminal 4.

[0075] For example, when a service developer contracts with a cloud service provider, they may issue a user ID for the developer service, contained in an ID token, separate from the login account, and store it on their server computer. The user ID for the developer service may not be issued by the computer of the service developer system 2, but may be specified by the administrator of the developer service, or by the administrator of the tenant to which the user belongs (e.g., the company where the user works). The user ID for the developer service shall be associated with the user's login account. This association may be used to identify which user's user ID will be issued when a particular user logs in. This association may be stored in the authentication system 3 or another system.

[0076] [1-3-4. Functions realized in the authentication system of the first embodiment] For example, the authentication system 3 includes an ID token issuing unit 300. The ID token issuing unit 300 is implemented by the control unit of the server computer of the authentication system 3 (for example, a control unit having the same hardware configuration as control units 10A and 11A). The ID token issuing unit 300 issues an ID token for a user when the user's login is successful. The ID token issuing unit 300 issues an ID token for a user when it confirms a login session between the authentication system 3 and the user's user terminal 4.

[0077] Furthermore, the authentication system 3 may have a function to store an authentication database containing the correct login account and password for authentication. The authentication system 3 may also have a function to perform authentication based on the login account and password entered by the user and the login account and password stored in the authentication database. The authentication database may be stored in a system other than the authentication system 3.

[0078] [1-3-5. Functions implemented in the user terminal of the first embodiment] For example, user terminal 4 includes a data storage unit 400. The data storage unit 400 is implemented by a storage unit of user terminal 4 (for example, a storage unit having a hardware configuration similar to storage units 10B and 11B). The data storage unit 400 stores data for the user to use cloud services and developer services, respectively. The data storage unit 400 may store the data described below in the browser's cookie storage area or in other storage areas.

[0079] For example, the data storage unit 400 may store session identification information that can identify a session between the user terminal 4 and the communication partner of the user terminal 4. In the first embodiment, the communication partners of the user terminal 4 are the cloud system 1 (e.g., the application server 10 that stores applications), the service developer system 2, and the authentication system 3. When a session is established between the application and the user terminal 4, the data storage unit 400 stores the session identification information of the session between the application and the user terminal 4. If a user establishes sessions with multiple applications, the data storage unit 400 stores application identification information (e.g., the name of the application, an ID assigned to the application, or other information) that can identify each application, in association with the session identification information.

[0080] For example, when a session is established between the service developer system 2 and the user terminal 4, the data storage unit 400 stores session identification information for the session between the service developer system 2 and the user terminal 4. The data storage unit 400 stores service developer identification information that can identify the service developer system 2 and the session identification information in association. For a service developer system 2 that handles multiple developer services, a session may be established for each developer service. In this case, the data storage unit 400 stores session identification information for each developer service of a given service developer system 2.

[0081] For example, when a session is established between the authentication system 3 and the user terminal 4, the data storage unit 400 stores session identification information for the session between the authentication system 3 and the user terminal 4. The data storage unit 400 stores authentication system identification information that can identify the authentication system 3 (for example, the name of the authentication system 3, the domain of the authentication system 3, or the URL of the authentication system 3) in association with the session identification information.

[0082] In the first embodiment, the user terminal 4 can transmit information stored in the data storage unit 400 to each of the application server 10, authentication server 11, service developer system 2, and authentication system 3. For example, the user terminal 4 may transmit information stored in the browser cookie storage area of ​​the data storage unit 400 to each of the application server 10, authentication server 11, service developer system 2, and authentication system 3.

[0083] [1-4. Processing performed by the cloud system of the first embodiment] Figures 8 and 9 show an example of processing performed in the cloud system 1 of the first embodiment. The processing in Figures 8 and 9 is performed by the control units 10A and 11A executing programs stored in the storage units 10B and 11B, respectively. The processing in Figures 8 and 9 is an example of processing included in the application usage method. Figures 8 and 9 show an example of processing when the user selects an application. Figures 8 and 9 also show the processing of the authentication system 3 and the user terminal 4.

[0084] For example, when a user selects an app from the top page P2 or elsewhere, the user terminal 4 sends a usage request to the app server 10 to use the app selected by the user (S100), as shown in Figure 8. The usage request is data in a predetermined format that indicates a request to use the app. For example, the usage request is an HTTP request to the URL corresponding to the app. The usage request may also include information from a cookie stored on the user terminal 4. The cookie information may be sent separately from the usage request.

[0085] The cookie information included in the request may consist only of information corresponding to the app (for example, cookie information corresponding to the app's domain) from among all cookie information, or it may include information corresponding to at least one of the service developer 2 and the authentication system 3 (for example, cookie information corresponding to at least one of the domains of the service developer 2 and the authentication system 3).

[0086] For example, if a session has already been established between the app and user terminal 4, the session identifier information for that session will be included in the request. If the user is logged into authentication system 3, the session identifier information for the session between authentication system 3 and user terminal 4 will be included in the request. If cookie information does not exist, the request will not include cookie information.

[0087] When the application server 10 receives an application usage request from the user terminal 4 (S101), the application server 10 determines whether a session has already been established between the application and the user terminal 4 (S102). In S102, the application server 10 determines whether the session identification information for the session between the application and the user terminal 4 is included in the usage request and whether the session identification information is valid. The application server 10 may also determine whether the session identification information is valid by determining whether the session identification information is stored in the user database DB1. If the session identification information has an expiration date, the application server 10 may also determine whether the session identification information is within its expiration date.

[0088] If, in S102, it is determined that a session has not been established between the application and the user terminal 4 (S102:N), the application server 10 requests the authentication server 11 to obtain an ID token from the authentication system 3 (S103). Since the cloud system 1 can cooperate with multiple authentication systems 3, it is assumed that the usage request in S100 includes information that identifies which developer service the application is intended to be used with. In S103, the application server 10 identifies which authentication system 3 to obtain the ID token from based on this information. The application server 10 requests the authentication server 11 to communicate with the identified authentication system 3.

[0089] When the authentication server 11 receives a request from the application server 10 (S104), it requests the authentication system 3 to issue an ID token (S105). In S105, the authentication server 11 may redirect the user terminal 4 to the authentication system 3 and have the authentication system 3 send the information of the authentication system 3 stored in the cookie. The authentication server 11 may also obtain the information of the authentication system 3 stored in the cookie, either by itself or via the application server 10, and send it to the authentication system 3. The authentication system 3 can obtain the information of the authentication system 3 stored in the cookie in some way and determine whether or not the user is logged into the authentication system 3 based on that information.

[0090] When authentication system 3 receives a request for issuance of an ID token from authentication server 11 (S106), it determines whether the user is already logged into authentication system 3 (S107). In S107, authentication system 3 determines whether the user is already logged into authentication system 3 by determining whether a session has been established between authentication system 3 and user terminal 4. Establishment of a session is equivalent to the user being logged in. Authentication system 3 determines whether the session identification information for the session between authentication system 3 and user terminal 4 is included in the request and whether the session identification information is valid. Authentication system 3 determines whether the session identification information is valid by determining whether the session identification information obtained from user terminal 4 is also stored in itself. If the session identification information has an expiration date, authentication system 3 may determine whether the session identification information is within its expiration date.

[0091] In S107, if it is determined that the user is not logged into the authentication system 3 (S107:N), the authentication system 3 performs a login process with the user terminal 4 to allow the user to log in to the authentication system 3 (S108). In S108, the login page P1 is displayed, and the login account and password are verified. If the login in S108 is successful, the authentication system 3 establishes a session with the user terminal 4 (S109). In S109, the authentication system 3 issues session identification information for the session between the authentication system 3 and the user terminal 4. The authentication system 3 records this session identification information and causes the user terminal 4's browser to save it in a cookie. The session identification information may also be sent to the user terminal 4 via the authentication server 11.

[0092] The authentication system 3 issues an ID token for the application selected by the user (S110). In S110, the authentication system 3 may store the ID token in association with information such as the user's login account. This allows the authentication system 3 to identify which ID token belongs to which user. Moving to Figure 9, the authentication system 3 sends the ID token to the authentication server 11 (S111). The authentication server 11 receives the ID token from the authentication system 3 (S112). The authentication server 11 sends the ID token to the application server 10 (S113).

[0093] The application server 10 receives an ID token from the authentication server 11 (S114). The application server 10 determines whether the ID token is valid or not (S115). In S115, the application server 10 verifies the validity of the ID token in JWT (JSON Web Token) format based on information such as the issuer, the destination of the token, and the expiration date. The application server 10 may also verify the signature of the ID token using the public key published by the authentication system 3. The application server 10 may also request the authentication system 3 to verify the validity of the ID token.

[0094] In S115, if the ID token is determined to be valid (S115:Y), the application server 10 executes a process to establish a session between the application and the user terminal 4 (S116). In S116, the application server 10 issues session identification information for the session between the application and the user terminal 4 and stores it in the user database DB1. The application server 10 sends the session identification information for the session between the application and the user terminal 4 to the user terminal 4. The user terminal 4 saves the session identification information for the session between the application and the user terminal 4 in the browser's cookie.

[0095] The application server 10 executes a process to allow the user to use the application with the user terminal 4 (S117), and then this process ends. In S117, the specific content of the application is displayed on the browser's side panel P32. From then on, when the user performs an operation on the application on the user terminal 4, the user sends the details of the user's operation to the application server 10. The application server 10 executes the application based on the user's operation and displays the execution result of the application on the user terminal 4. In the lower example of Figure 5, a chat application is executed, so the application server 10 displays the messages exchanged in the chat on the side panel P32.

[0096] In S102, if it is determined that a session has been established between the application and the user terminal 4 (S102:Y), the process proceeds to S117, where the specific contents of the application are displayed on the browser's side panel P32. In S107, if it is determined that the user is already logged into the authentication system 3 (S107:Y), the process proceeds to S110, where an ID token is issued. In S115, if it is determined that the ID token is not valid (S115:N), the process proceeds to S103, where a series of processes are executed between the authentication server 11 and the authentication system 3.

[0097] [1-5. Summary of the First Embodiment] In the first embodiment, Cloud System 1 obtains an ID token to verify the user of a service developer system 2 that uses an application managed by Cloud System 1, among a group of service developer systems 2. Based on the ID token, Cloud System 1 allows the user to use the application. As a result, Cloud System 1 can verify the user using the ID token, and therefore ensure that each user of the multiple service developer systems 2 can use the application appropriately. For example, Cloud System 1 can prevent unintended users from using the application, thereby enhancing security. If users of service developer systems 2 are counted as users of Cloud System 1, Cloud System 1 can easily increase the number of users by contracting with new service developer systems 2. Users can use the application with the same ease as using developer services, thus improving user convenience.

[0098] Furthermore, when a user logs in to the cloud system 1, and the login session of the authentication system 3 (which issues an ID token) is active, the cloud system 1 obtains an ID token without requiring the user to log in to the authentication system 3 again when the user selects an application. The application usage unit 102 then allows the user to use the application based on the ID token without requiring the user to log in to the authentication system 3 again. This enables the cloud system 1 to achieve single sign-on using ID tokens, thereby improving user convenience.

[0099] Furthermore, each of the multiple service developer systems 2 has an authentication system 3 that authenticates users in the developer services that the service developer system 2 provides to users. Cloud system 1 obtains an ID token issued by the authentication system 3 of the service developer system 2. This eliminates the need for cloud system 1 to have a mechanism to issue ID tokens within itself, thus simplifying the configuration of cloud system 1. Cloud system 1 can have the authentication system 3, which is already built on the service developer system 2 side, issue the ID token.

[0100] Furthermore, Cloud System 1 includes an authentication server 11 that acts as an intermediary between the application and the authentication system 3, and obtains an ID token from the authentication system 3 as a client of the authentication system 3. Cloud System 1 obtains the ID token mediated by the authentication server 11. As a result, Cloud System 1 can simplify the application configuration because the application does not need to interact directly with the authentication system 3. For example, Cloud System 1 can reduce the development burden on those who develop applications.

[0101] [2. Second Embodiment] A second embodiment, which is an example of an embodiment of the cloud system 1, provision method, and program related to this disclosure, will be described. In the second embodiment, the same points as in the first embodiment will be omitted from the explanation.

[0102] [2-1. Hardware configuration of the cloud system in the second embodiment] Figure 10 shows an example of the hardware configuration of the cloud system 1 in the second embodiment. The hardware configuration of the cloud system 1 in the second embodiment may be the same as in the first embodiment, but the example in Figure 10 shows a case where the cloud system 1 includes a synchronization server 12. The application server 10, authentication server 11, service developer system 2, authentication system 3, and user terminal 4 may be the same as in the first embodiment.

[0103] The synchronization server 12 is a server computer. For example, the synchronization server 12 includes a control unit 12A, a storage unit 12B, and a communication unit 12C. The hardware configurations of the control unit 12A, the storage unit 12B, and the communication unit 12C may be the same as those of the control unit 10A, the storage unit 10B, and the communication unit 10C, respectively.

[0104] The program stored in the storage unit 12B may be supplied to the synchronization server 12 via the network N. The hardware configuration of the synchronization server 12 is not limited to the example in Figure 10. For example, the synchronization server 12 may include at least one of the reading unit and the input / output unit described in the first embodiment. The program stored in the information storage medium may be supplied to the synchronization server 12 via at least one of the reading unit and the input / output unit.

[0105] [2-2. Overview of the Cloud System in the Second Embodiment] The cloud system 1 of the second embodiment provides each of the multiple service developer systems 2 with an application usage function that enables any application from among multiple applications to be used by the service developer system 2. The service developer systems 2 and applications are as described in the first embodiment. In the second embodiment, as in the first embodiment, we take the example of a service developer system 2 that operates cloud accounting software B using the "XXX Chat" application.

[0106] The application usage function is a function that the cloud system 1 provides to the service developer system 2 in order to allow the service developer system 2 to use an application. The application usage function can also be described as a program that shows various processes for allowing the service developer system 2 to use an application. The application usage function may also include data referenced by the program. For example, the cloud system 1 executing the application usage function program in response to a request from the service developer system 2, sending data showing the execution result of the program to the service developer system 2, or sending the application usage function itself to the service developer system 2 in response to a request from the service developer system 2 constitutes the cloud system 1 providing the application usage function to the service developer system 2.

[0107] For example, an API that accepts API requests sent by service developer system 2 to use an application is an example of an application usage function. That is, at least one of the following is an example of an application usage function: a program that accepts API requests, a program that indicates the processing to be done in response to the API request, and a program that sends the result of the execution of said processing to service developer system 2. If service developer system 2 needs to install some program to use an application, that program is an example of an application usage function. If an application is provided by a browser extension, the browser extension is an example of an application usage function. The data referenced by these programs may also correspond to an application usage function.

[0108] For example, suppose the service developer of cloud accounting software B has not yet subscribed to cloud system 1. In this case, cloud system 1 does not store any data about the service developer system 2 of cloud accounting software B. When the service developer of cloud accounting software B subscribes to cloud system 1 to use the "XXX Chat" app, cloud system 1 synchronizes with the service developer system 2 of cloud accounting software B to enable the "XXX Chat" app on the service developer system 2 and shares the data necessary to start using the "XXX Chat" app.

[0109] For example, Cloud System 1 performs synchronization with Cloud Accounting Software B's service developer system 2 by acquiring user information about users of Cloud Accounting Software B, tenant information about tenants that subscribe to Cloud Accounting Software B (for example, the user's employer), other information besides user information and tenant information (for example, accounting information registered in Cloud Accounting Software B that is permitted to be viewed by the "XXX Chat" app), or a combination of these.

[0110] For example, if service developer system 2 needs to obtain data managed by cloud system 1 (e.g., user information, tenant information, application initial settings, or a combination thereof generated or acquired on the cloud system 1 side) in order to start using the application, cloud system 1 may perform synchronization by sending such data to service developer system 2. Once cloud system 1 has completed synchronization with service developer system 2 of cloud accounting software B, it provides the "XXX Chat" application to service developer system 2 of cloud accounting software B.

[0111] In the second embodiment, when a service developer of cloud accounting software B contracts with cloud system 1 and begins using any application such as "XXX Chat," cloud system 1 performs synchronization with the service developer system 2 of cloud accounting software B based on an application usage function, which is a program that indicates a series of processes for performing synchronization with the service developer system 2 of cloud accounting software B, and acquires various information necessary for using any application such as "XXX Chat." This allows cloud system 1 to easily enable the use of any application in each of the multiple service developer systems 2. Details of the second embodiment will be described below.

[0112] [2-3. Functions realized by the cloud system of the second embodiment] Figure 11 shows an example of the functions implemented in the cloud system 1 of the second embodiment. In Figure 11, the functions implemented by the synchronization server 12 are shown among the functions implemented in the cloud system 1. Figure 11 also shows the functions implemented by the service developer system 2.

[0113] In the second embodiment, we take an example where the application server 10 and the authentication server 11 have the functions described in the first embodiment. The respective functions of the application server 10 and the authentication server 11 are omitted in Figure 11. For example, the data storage unit 100 stores multiple applications managed by the cloud system 1. The data storage unit 100 is an example of an application storage unit. The application storage unit may be implemented by a computer other than the application server 10 or by an information storage medium. The functions described in the first embodiment as being implemented by the application server 10 and the authentication server 11 may be implemented by the synchronization server 12. For example, in the first embodiment, the case in which the user ID of the developer service is obtained by the application server 10 was described, but in the second embodiment, the user ID of the developer service may be obtained by the synchronization server 12.

[0114] Furthermore, at least one of the application server 10 and the authentication server 11 does not need to include at least a portion of the functions described in the first embodiment. The cloud system 1 of the second embodiment does not need to include the functions described in the first embodiment. For example, the cloud system 1 of the second embodiment may not include the single sign-on mechanism described in the first embodiment and may require a user who is already logged into the developer service to enter their login account and password when using the application. It is within the scope of this disclosure that the cloud system 1 does not include at least a portion of the functions described in the first embodiment and does not solve the problem of "allowing each user of the multiple service developer systems 2 to use the application appropriately" as in the first embodiment, but includes the functions described in the second embodiment and solves the problem of "allowing each of the multiple service developer systems 2 to easily use any application" as in the second embodiment.

[0115] [2-3-1. Functions implemented in the synchronization server of the second embodiment] For example, the synchronization server 12 implements a data storage unit 120 and an application usage function provision unit 121. The data storage unit 120 is implemented by the storage unit 12B. The application usage function provision unit 121 is implemented by the control unit 12A.

[0116] [Data Storage Unit] The data storage unit 120 stores various data necessary for the cloud service. In the second embodiment, we take the example of a case where the data storage unit 120 has a storage area corresponding to each of multiple service developers, similar to the data storage unit 100. That is, the storage area of ​​the data storage unit 120 is divided for each service developer. When a service developer contracts for a cloud service, the storage area of ​​the data storage unit 120 is divided for each service developer who is a tenant of the cloud service. For example, in the storage area of ​​the data storage unit 120 for a certain service developer, a synchronization database DB2 is stored, which contains various information obtained through synchronization performed between that service developer and the service developer system 2.

[0117] Figure 12 shows an example of a synchronization database DB2 in the second embodiment. The synchronization database DB2 is a database that stores various information obtained through synchronization with the service developer system 2 corresponding to the storage area where the synchronization database DB2 is stored. For example, the synchronization database DB2 stores the user ID of the cloud service, the user ID of the developer service, and user information. The information stored in the synchronization database DB2 is not limited to the example in Figure 12. Any information may be stored in the synchronization database DB2. For example, the synchronization database DB2 may store tenant information about the tenant to which the user belongs, information that the tenant has registered with the service developer system 2, or other information.

[0118] The cloud service user ID, the developer service user ID, and user information may be the same as in the first embodiment. In the second embodiment, an example is given where the developer service user ID and user information correspond to the information to be synchronized. Synchronization is not limited to the cloud system 1 obtaining information from the service developer system 2, but may also be the cloud system 1 sending information to the service developer system 2. For example, the cloud system 1 sending the cloud service user ID to the service developer system 2 may correspond to synchronization. In the second embodiment, the synchronization server 12 may synchronize each piece of information in the synchronization database DB2 with the service developer system 2 and then send the synchronized information to the application server 10. The application server 10 may receive the synchronized information and store it in the user database DB1. Through such processing, consistency may be achieved between the contents of the user database DB1 and the contents of the synchronization database DB2.

[0119] The data stored in the data storage unit 120 is not limited to the above example. The data storage unit 120 can store any data. For example, the data storage unit 120 may store the actual data of the application usage function. In the second embodiment, we take the example of a case where the data synchronization function for the cloud system 1 to synchronize with the service developer system 2 corresponds to the application usage function, so the data storage unit 120 stores the actual data of the data synchronization function. The actual data of the data synchronization function includes a program that shows a series of synchronization processes. The actual data of the data synchronization function may also include data referenced by the program. The data storage unit 120 may store information that can identify which data among the data managed by the service developer system 2 is to be synchronized. The application usage function provision unit 121, described later, may perform data synchronization based on this information.

[0120] Furthermore, the storage area of ​​the data storage unit 120 does not need to be separated for each service developer. In this case, the data storage unit 120 may store a single synchronization database DB2 that stores various information obtained through synchronization between multiple service developers and each service developer system 2. This synchronization database DB2 may store service developer IDs, cloud service user IDs, developer service user IDs, user information, tenant information, and other information. In the first embodiment, the case in which the application server 10 issues a service developer ID was described, but in the second embodiment, the synchronization server 12 may issue a service developer ID and store it in the synchronization database DB2.

[0121] [App Usage Function Provision Department] The application usage function provider unit 121 provides each of the multiple service developer systems 2 with an application usage function to enable any application from among the multiple applications to be used in the service developer system 2. Providing an application usage function by the application usage function provider unit 121 means that the application usage function provider unit 121 executes a program included in the application usage function, the application usage function provider unit 121 transmits the execution result of the program to the service developer system 2, or the application usage function provider unit 121 transmits the actual data of the application usage function to the service developer system 2. The application usage function provider unit 121 may provide the application usage function based on a request from the service developer system 2, or it may provide the application usage function spontaneously without receiving a request from the service developer system 2.

[0122] In the second embodiment, the application usage function provider 121 provides each of the multiple service developer systems 2 with a data synchronization function as an application usage function for synchronizing data with the cloud system 1. For example, when a service developer operating a certain service developer system 2 enters into a contract to use the cloud system 1, the application usage function provider 121 receives a synchronization request from the service developer system 2. The application usage function provider 121 obtains from the service developer system 2 the user ID of each of the multiple users managed by the service developer system 2, and the user information of each user. The application usage function provider 121 issues a cloud service user ID for each user, and the application server 10 stores the cloud service user ID, the developer service user ID, and the user information of each user in association with each user in the synchronization database DB2.

[0123] Furthermore, the information acquired by the application usage function provider 121 through synchronization is not limited to the developer service user ID and user information. The application usage function provider 121 can synchronize any information with the service developer system 2. For example, the application usage function provider 121 may perform synchronization by executing a program included in the data synchronization function and acquiring tenant information for each tenant (for example, an ID that can identify the tenant, the tenant's name, the tenant's industry, or information about the tenant's administrator) from the service developer system 2. The application usage function provider 121 may also perform synchronization by sending information generated by the cloud system 1 to the service developer system 2. The application usage function provider 121 may also perform synchronization by sending data indicating the execution results of the application to the service developer system 2.

[0124] Furthermore, the application usage function provision unit 121 may initiate synchronization spontaneously, rather than in response to a request from the service developer system 2. For example, when a service developer operating a certain service developer system 2 enters into a usage agreement for the cloud system 1, the administrator of the cloud system 1 registers usage agreement data indicating that the service developer has entered into the usage agreement on the cloud system 1 (for example, data storage unit 100, data storage unit 110, or data storage unit 120). When the application usage function provision unit 121 detects that the usage agreement data has been registered, it requests synchronization from the service developer system 2 that entered into the usage agreement. Information that can identify the service developer system 2 (for example, an ID, IP address, or domain name that can identify the service developer system 2) is shown in the usage agreement data. The service developer system 2 provides the data to be synchronized to the cloud system 1 based on the request from the application usage function provision unit 121.

[0125] [2-3-2. Functions implemented in the service developer system of the second embodiment] For example, the service developer system 2 includes a service provision unit 200, a data storage unit 201, and a synchronization unit 202. The service provision unit 200 may be the same as in the first embodiment. The data storage unit 201 is implemented by a storage unit of the server computer of the service developer system 2 (for example, a storage unit having a hardware configuration similar to that of storage unit 12B). The synchronization unit 202 is implemented by a control unit of the server computer of the service developer system 2 (for example, a control unit having a hardware configuration similar to that of control unit 12A).

[0126] [Data Storage Unit] The data storage unit 201 stores various information related to the developer service. For example, the data storage unit 201 stores the data to be synchronized. In the second embodiment, the user ID of the developer service and user information are to be synchronized, so the data storage unit 201 stores the user ID of the developer service and user information. If other information such as tenant information is to be synchronized, the data storage unit 201 stores the other information to be synchronized. The data storage unit 201 may also store information that identifies which data among the data managed by the service developer system 2 is to be synchronized. The service developer system 2 may add, update, or delete the data to be synchronized at any time, such as when a user uses the developer service.

[0127] [Classmates] The synchronization unit 202 performs synchronization with the cloud system 1. For example, when a service developer enters into a contract to use the cloud system 1, the synchronization unit 202 sends a synchronization request to the cloud system 1. When the synchronization unit 202 receives a notification from the cloud system 1 indicating that the synchronization request has been successfully received, it performs synchronization by sending the data to be synchronized stored in the data storage unit 201 to the cloud system 1. The synchronization unit 202 may also perform synchronization by receiving the information to be synchronized from the cloud system 1 and recording it in the data storage unit 201. The synchronization unit 202 may also perform synchronization based on a synchronization request from the cloud system 1.

[0128] [2-4. Processing performed in the cloud system of the second embodiment] Figure 13 shows an example of processing performed in the cloud system 1 of the second embodiment. The processing in Figure 13 is performed when the control unit 12A executes a program stored in the storage unit 12B. The processing in Figure 13 is an example of processing included in the provision method. Figure 13 shows an example of processing when a service developer contracts for the cloud system 1 to use the application. Figure 13 also shows the processing of the service developer system 2.

[0129] For example, when a service developer enters into a contract to use the cloud system 1, the service developer system 2 sends a synchronization request to the synchronization server 12 to synchronize the data to be synchronized necessary for starting to use the application (S200). The synchronization request is data in a predetermined format that indicates the start of synchronization. The synchronization request may include information that can identify the data to be synchronized, or if the synchronization server 12 has data indicating which data will be the data to be synchronized stored in advance, the synchronization request may not include information that can identify the data to be synchronized.

[0130] When the synchronization server 12 receives a synchronization request from the service developer system 2 (S201), it performs synchronization of the data to be synchronized necessary for starting to use the application with the service developer system 2 based on the data synchronization function, which is a program that shows a series of synchronization processes (S202), and this process ends. In S202, the synchronization server 12 performs synchronization by obtaining the developer service user ID and user information from the service developer system 2 and storing them in the synchronization database DB2. The synchronization server 12 issues a cloud service user ID and stores it in the synchronization database DB2 in association with the developer service user ID and user information obtained through synchronization.

[0131] [2-5. Summary of the second embodiment] The cloud system 1 of the second embodiment provides each of the multiple service developer systems 2 with an application usage function that enables any application from among multiple applications to be used in the service developer system 2. This allows the cloud system 1 to easily enable any application to be used in each of the multiple service developer systems 2. For example, if a service developer enters into a contract to use the cloud system 1, the cloud system 1 can make the application usable by providing the application usage function, rather than developing a new function for the service developer.

[0132] Furthermore, Cloud System 1 provides each of the multiple service developer systems with a data synchronization function as an application usage function to synchronize data with Cloud System 1. This allows Cloud System 1 to synchronize the data to be synchronized in order to allow each of the multiple service developer systems 2 to use any application, making it easy to use the application. For example, if the application requires the developer service user ID, user information, tenant information, and at least one of the other pieces of information, Cloud System 1 can obtain this information through the data synchronization function and allow the application to be used.

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

[0134] [3-1. Variations relating to the first embodiment] Figure 14 shows an example of a function realized in a modified version of the first embodiment. As shown in Figure 14, in the modified version of the first embodiment, an access token acquisition unit 103, a first addition unit 104, a second addition unit 105, an environment creation unit 106, a usage permission unit 107, a billing processing execution unit 108, and an ID token issuance unit 112 are realized. Each of the access token acquisition unit 103, the first addition unit 104, the second addition unit 105, the environment creation unit 106, the usage permission unit 107, and the billing processing execution unit 108 is realized by a control unit 10A. The ID token issuance unit 112 is realized by a control unit 11A.

[0135] [Variation 1-1] For example, in the first embodiment, a session is established between the application and the user terminal 4 based on an ID token that proves the user's identity, allowing the user to use the application without having to log in again. Some applications retrieve data managed not only by cloud services but also by developer services. In this case, the user of the application needs to prove to the developer service that they have access to the data. Modification 1-1 gives an example of a case where an access token is issued so that the user of the application can access the service developer system 2.

[0136] The cloud system 1 in Modification 1-1 includes an access token acquisition unit 103. The access token acquisition unit 103 acquires an access token for the application to access the service developer system 2. An access token is information that proves a user has the right to access a specific resource. Access tokens are issued based on OAuth 2.0 or an equivalent authentication protocol. Modification 1-1 takes the case where the authentication system 3 issues the access token as an example. If the access token expires, a new access token is issued by a refresh token.

[0137] In Modification 1-1, an example is given where an access token is issued together with an ID token, but the access token may be issued at a different time than the ID token. For example, when the authentication system 3 receives a request from the authentication server 11 for the issuance of an ID token, as in the first embodiment, it issues an access token together with the ID token. The authentication system 3 sends the ID token and the access token to the authentication server 11. The authentication server 11 receives the ID token and the access token from the authentication system 3. The authentication server 11 sends the ID token and the access token to the application server 10. The access token acquisition unit 103 acquires the access token from the authentication server 11. The access token acquisition unit 103 stores the access token in the user database DB1.

[0138] If the authentication server 11 does not mediate communication between the application server 10 and the authentication system 3, the access token acquisition unit 103 may acquire the access token by communicating directly with the authentication system 3. If the authentication server 11 issues the access token instead of the authentication system 3, the access token acquisition unit 103 may acquire the access token from the authentication server 11. If the access token is stored in the data storage unit 100, another computer other than the application server 10, or an information storage medium, the access token acquisition unit 103 may acquire the access token from the data storage unit 100, the other computer, or the information storage medium.

[0139] In the modified example 1-1, the application usage unit 102 accesses the service developer system 2 based on an access token. For example, when the application usage unit 102 accesses the API of the service developer system 2, it sends an access token to the service developer system 2. When the service developer system 2 receives the access token from the application server 10, it verifies the validity of the access token. If the service developer system 2 determines that the access token is valid, it grants access to the API. If the service developer system 2 determines that the access token is not valid, it does not grant access to the API.

[0140] The access token may also be used for access other than to the API. For example, the application user unit 102 may use the access token to access a database stored by the service developer system 2, or to access a program stored by the service developer system 2. The application user unit 102 may also retrieve data managed by the service developer system 2 and execute the application, or it may retrieve data managed by the service developer system 2 and record it in the data storage unit 100.

[0141] In the example shown in Figure 2, suppose a user of cloud accounting software B uses app 1, which has a chat function. In this case, the app usage unit 102 obtains data such as invoices managed by the service developer system 2 of cloud accounting software B based on the user's access token. Based on this data, the app usage unit 102 displays the side panel P32, which is the chat function screen of app 1, on the user terminal 4. The side panel P32 may show the specific contents of the invoice, or it may display a link to the invoice data managed by the service developer system 2. The app usage unit 102 obtains the data necessary for these displays based on the access token.

[0142] In the modified example 1-1, Cloud System 1 obtains an access token for the application to access Service Developer System 2. Based on the access token, Cloud System 1 accesses Service Developer System 2. This allows Cloud System 1 to allow the application to access Service Developer System 2. For example, since the application can access data stored by Service Developer System 2, Cloud System 1 can enhance the collaboration between cloud services and developer services.

[0143] [Variation 1-2] For example, in the first embodiment, the case in which the authentication system 3 issues an ID token was described, but the ID token may also be issued within the cloud system 1. In modification 1-2, the case in which the authentication server 11 issues an ID token is described, but if other computers other than the authentication server 11 are included in the cloud system 1, the ID token may also be issued by those other computers.

[0144] The cloud system 1 in Modification 1-2 includes an ID token issuing unit 112. The ID token issuing unit 112 issues an ID token when a user logs in to the service developer system 2 with a login account. Since login to the service developer system 2 is performed by the authentication system 3, the authentication server 11 obtains information that can identify the logged-in user (for example, the user ID of the developer service) from the authentication system 3. When the ID token issuing unit 112 obtains this information, it issues an ID token. For example, the ID token issuing unit 112 issues an ID token based on the procedure specified in OIDC, which is an example of an authentication protocol. The ID token issuing unit 112 sends the ID token to the application server 10.

[0145] In Modification 1-2, the ID token acquisition unit 101 acquires an ID token issued by the ID token issuing unit 112. For example, if the ID token issuing unit 112 is implemented by the authentication server 11, the ID token acquisition unit 101 acquires the ID token issued by the ID token issuing unit 112 from the authentication server 11. This differs from the first embodiment in that the issuing entity of the ID token is the authentication server 11, but the processing after the ID token is acquired may be the same as in the first embodiment.

[0146] Furthermore, if the service developer has an authentication system 3 capable of issuing ID tokens, the authentication system 3 may issue the ID tokens as in the first embodiment. If the service developer does not have an authentication system 3 capable of issuing ID tokens, the ID token issuing unit 112 of the authentication server 11 may issue the ID tokens as in the modified example 1-2. The data indicating which service developer will cause the ID token issuing unit 112 of the authentication server 11 to issue an ID token is stored in the data storage unit 100.

[0147] For example, based on the above data, the application server 10 can determine whether to have the authentication system 3 issue an ID token or the authentication server 11 issue an ID token when a user of a certain service developer uses the application. If the application server 10 determines that the authentication system 3 should issue an ID token, it can have the authentication system 3 issue an ID token in the same manner as in the first embodiment. If the application server 10 determines that the authentication server 11 should issue an ID token, it can have the authentication server 11 issue an ID token in the manner shown in Modification 1-2.

[0148] In the modified example 1-2, Cloud System 1 issues an ID token when a user logs into Service Developer System 2 with their login account. Cloud System 1 then acquires the issued ID token. This allows Cloud System 1 to issue ID tokens within itself, enabling each user of multiple Service Developer Systems 2 to use the application appropriately. For example, even if Service Developer System 2 does not have the functionality to issue ID tokens, Cloud System 1 can still enable users to use the application appropriately.

[0149] [Modifications 1-3] For example, as briefly explained in the first embodiment, when a new service developer subscribes to a cloud service, the existing users of that new service developer are added as new users of the cloud service. If the new service developer had 5 million existing users, the number of users of the cloud service would increase by 5 million. Modification 1-3 explains an example of the process when a new service developer subscribes to a cloud service.

[0150] The cloud system 1 in Modification 1-3 includes a first add-on section 104. The first add-on section 104 adds existing users of a new service developer system 2 as new users of the cloud system 1 when the new service developer system 2 begins to cooperate with the cloud system 1. The new service developer system 2 is the service developer system 2 of a new service developer that has contracted for a cloud service.

[0151] The commencement of integration between the new service developer system 2 and the cloud system 1 means that the new service developer has entered into a contract for the cloud service. The cloud system 1 may detect that the new service developer system 2 has commenced integration with the cloud system 1 through an operation by the cloud service administrator, or it may detect that the new service developer system 2 has commenced integration with the cloud system 1 through a notification from the new service developer system 2 or another system.

[0152] In Modification 1-3, the new service developer system 2 stores an existing user database containing various information about existing users who use the new service developer system 2. For example, the existing user database stores the user IDs and user information of existing users in the developer service. For example, the first addition unit 104 retrieves the user IDs and user information from the existing user database and adds them as new users by storing them in the cloud service user database DB1.

[0153] For example, the first add-on unit 104 may issue a user ID for the cloud service to an existing user who uses the new service developer system 2, associate the user ID for the cloud service, the user ID for the developer service, and the user information managed in the new service developer system 2, and store them in the user database DB1. The storage of this information in the user database DB1 may be equivalent to the first add-on unit 104 adding a user, or the issuance of a user ID for the cloud service may be equivalent to the first add-on unit 104 adding a user.

[0154] In Modification 1-3, when a new service developer system 2 begins to integrate with Cloud System 1, Cloud System 1 adds the existing users of the new service developer system 2 as new users of Cloud System 1. This makes it easier for Cloud System 1 to increase its user base, as the existing users of the new service developer system 2 become new users of Cloud System 1. For example, if a new service developer with 5 million existing users signs up for a cloud service, Cloud System 1 can increase its user base by 5 million.

[0155] [Modifications 1-4] For example, even if a service developer has already contracted for a cloud service, new users may be added to the service developer. If a new tenant (e.g., a company) contracts with a service developer, users belonging to that tenant will be added as new users of the service developer. Similarly, if an individual user contracts with a service developer, that individual user will also be added as a new user of the service developer. In these cases, cloud system 1 may obtain various information about the newly added users from service developer system 2 and add them as new users of cloud system 1.

[0156] The cloud system 1 in Modification 1-4 includes a second add-on section 105. The second add-on section 105 adds a new user to the cloud system 1 when a new user is added to the service developer system 2. For example, when a new user is added to the service developer system 2, the service developer system 2 stores the user ID and user information of the new user in an existing user database managed by the service developer system 2. The service developer system 2 then transmits the user ID and user information of the new user to the cloud system 1.

[0157] For example, the second add-on unit 105 obtains the user ID and user information of a new user from the service developer system 2. The second add-on unit 105 issues a user ID for the new user in the cloud service and stores it in the user database DB1 along with the user ID and user information obtained from the service developer system 2. The storage of this information in the user database DB1 may correspond to the second add-on unit 105 adding a user, or the issuance of a user ID in the cloud service may correspond to the second add-on unit 105 adding a user.

[0158] In Modification 1-4, when a new user is added to the service developer system 2, the cloud system 1 adds that new user as a new user of the cloud system 1. As a result, the cloud system 1 can easily increase the number of users because new users added to the service developer system 2 also become new users of the cloud system 1.

[0159] [Variations 1-5] For example, if a user of the service developer system 2 belongs to an organization such as a company, the organization often contracts with the service developer system 2 as a tenant. In this case, when a user uses a cloud service application, it may be easier to manage the data of that tenant if the environment for the tenant to which the user belongs is built on the application server 10. Therefore, in Modification 1-5, we will explain the case in which an environment for a new tenant is created when a new tenant is added to the service developer system 2.

[0160] The cloud system 1 in Modification 1-5 includes an environment creation unit 106. The environment creation unit 106 creates an environment for the new tenant in the application when a new tenant is added in the service developer system 2. For example, the service developer system 2 stores a tenant database containing various information about each of the multiple tenants it has contracted with. The tenant database stores a tenant ID that can identify the tenant, and basic information about the tenant (e.g., the tenant's name, address, or contact information). The service developer system 2 detects that a new tenant has been added when a new record is created in the tenant database.

[0161] For example, the service developer system 2 notifies the cloud system 1 that a new tenant has been added. The notification may include the tenant ID and basic information. Upon receiving the notification, the environment creation unit 106 allocates a storage area for the new tenant in the data storage unit 100. An environment database indicating which storage area belongs to which tenant is stored in the data storage unit 100. The environment creation unit 106 may add the environment by associating the tenant ID and basic information of the new tenant with information that can identify the storage area for that tenant (e.g., a memory address) and storing it in the environment database.

[0162] Furthermore, the environment created by the environment creation unit 106 is not limited to the storage area of ​​the data storage unit 100. The environment creation unit 106 only needs to secure resources that can be used by users belonging to the tenant of the service developer system 2. Resources may include, in addition to the storage area of ​​the data storage unit 100, virtual machines running on the application server 10, programs stored on the application server 10, APIs of the application server 10, physical hardware such as computers or memory, or other resources. The environment creation unit 106 may create the tenant's environment by securing these resources.

[0163] In Modification 1-5, Cloud System 1 creates an environment for the new tenant in the application when a new tenant is added in Service Developer System 2. This allows Cloud System 1 to make the application available in the environment for the new tenant, thereby improving convenience for the new tenant.

[0164] [Variations 1-6] For example, as explained to some extent in the first embodiment, the application provided by the cloud service may be developed by the cloud provider. In Modification 1-6, the application created by the cloud provider is called the provider application. The provider application can also be described as the genuine application developed by the cloud provider that operates the cloud service. The application server 10 only needs to provide the user with at least one of the provider application in Modification 1-6 and the developer application in Modification 1-7 described later.

[0165] For example, a cloud provider creates a business application on its own computer. The cloud provider may create the business application by coding it itself, or by using a publicly available program creation tool. The cloud provider operates its own computer and uploads the business application to the application server 10. The application server 10 stores the uploaded business application.

[0166] In Modification 1-6, the ID token acquisition unit 101 acquires an ID token when a user uses a vendor application, which is an application developed by the cloud provider operating the cloud system 1. In Modification 1-6, the service developer enters into a contract to use at least one vendor application from among several applications provided by the cloud service. For example, when a user selects a vendor application on the top page P2 at the bottom of Figure 3, the user terminal 4 sends a request to the application server 10 to use the vendor application. The request to use the application includes browser cookie information.

[0167] For example, when the application server 10 receives a request to use the service provider's application, it determines whether a session has been established between the service provider's application and the user terminal 4 based on the cookie information and the session identification information stored in the user database DB1. If it is determined that a session has been established, the application usage unit 102 communicates with the user terminal 4 based on the established session and allows the user to use the service provider's application. In this case, since a session has already been established, the ID token acquisition unit 101 does not acquire an ID token.

[0168] For example, if it is determined that a session has not been established, the ID token acquisition unit 101 requests the authentication server 11 to obtain an ID token from the authentication system 3. Upon receiving the request, the authentication server 11 executes a process to obtain an ID token with the authentication system 3. This process is the same as in the first embodiment. The ID token acquisition unit 101 obtains an ID token from the authentication server 11 to establish a session between the business application and the user terminal 4.

[0169] In the modified version 1-6, the application usage unit 102 allows the user to use the service provider's application based on an ID token. For example, the application usage unit 102 verifies the validity of the ID token. If the application usage unit 102 determines that the ID token is valid, it establishes a session between the service provider's application and the user terminal 4. The application usage unit 102 issues session identification information and stores it in the user database DB1, while simultaneously sending the session identification information to the user terminal 4. Subsequent communication is based on session identification information. The application usage unit 102 communicates with the user terminal 4 based on the established session and allows the user to use the service provider's application.

[0170] In the modified example 1-6, Cloud System 1 obtains an ID token when a user uses a service provider application, which is an application developed by the cloud provider. Based on the ID token, Cloud System 1 allows the user to use the service provider application. This enables Cloud System 1 to appropriately allow each user of multiple service developer systems 2 to use the service provider application.

[0171] [Variations 1-7] For example, an application provided through a cloud service may be developed by the service developer operating the service developer system 2, or by another developer different from the said service developer. The other developer may be an organization such as a company that does not operate the service developer system 2, or it may be an individual. In the modified example 1-7, an application created by the service developer or another developer is called a developer application. A developer application can be said to be an application developed by a third party (an entity other than the cloud provider), such as the service developer operating the cloud service or the other developer themselves.

[0172] For example, a service developer or another developer creates a developer application on their own computer. The service developer or other developer may create the developer application by coding it themselves, or by using a publicly known program creation tool. The service developer or other developer operates their own computer to upload the developer application to the application server 10. The application server 10 stores the uploaded developer application.

[0173] In Modification 1-7, the ID token acquisition unit 101 acquires an ID token when a user uses the developer application. In Modification 1-7, the service developer enters into a contract to use at least one developer application from among several applications provided by the cloud service. For example, when a user selects a developer application on the top page P2 at the bottom of Figure 3, the user terminal 4 sends a request to the application server 10 to use the developer application. The request to use the application includes browser cookie information.

[0174] For example, when the application server 10 receives a request to use the developer application, it determines whether a session has been established between the developer application and the user terminal 4 based on the cookie information and the session identification information stored in the user database DB1. If it is determined that a session has been established, the application usage unit 102 communicates with the user terminal 4 based on the established session and allows the user to use the developer application. In this case, since the session has already been established, the ID token acquisition unit 101 does not acquire an ID token.

[0175] For example, if it is determined that a session has not been established, the ID token acquisition unit 101 requests the authentication server 11 to obtain an ID token from the authentication system 3. Upon receiving the request, the authentication server 11 executes a process to obtain an ID token with the authentication system 3. This process is the same as in the first embodiment. The ID token acquisition unit 101 obtains an ID token from the authentication server 11 to establish a session between the developer application and the user terminal 4.

[0176] In Modification 1-7, the application usage unit 102 allows the user to use the developer application based on an ID token. For example, the application usage unit 102 verifies the validity of the ID token. If the application usage unit 102 determines that the ID token is valid, it establishes a session between the developer application and the user terminal 4. The application usage unit 102 issues session identification information and stores it in the user database DB1, while simultaneously sending the session identification information to the user terminal 4. Subsequent communication is based on session identification information. The application usage unit 102 communicates with the user terminal 4 based on the established session and allows the user to use the developer application.

[0177] In the modified version 1-7, the cloud system 1 obtains an ID token when a user uses a developer application, and the application usage unit 102 allows the user to use the developer application based on the ID token. This allows the cloud system 1 to appropriately allow each user of the multiple service developer systems 2 to use the developer application.

[0178] [Variations 1-8] For example, in Modification 1-7, the developer app may have conditions for its use. Hereafter, these conditions will be referred to as the terms of use. The terms of use are specified by the service developer who developed the developer app or by another developer. The terms of use may be arbitrary. For example, the terms of use may be conditions for organizations that are permitted to use the developer app, conditions for organizations that are permitted to use the developer app but are subject to certain restrictions, conditions for organizations that are prohibited from using the developer app, or other conditions.

[0179] In Modification 1-8, the data storage unit 100 stores usage condition data relating to usage conditions. The usage condition data is data that shows the specific content of the usage conditions. The usage condition data may be in any data format. For example, the usage condition data may be part of program code, or it may be data in the form of text data or markup language that can be referenced by a program such as an application. In Modification 1-8, as an example of usage conditions, the conditions of an organization that is permitted to use the developer application are described. For example, the usage condition data may show the industry, name, ID, or area of ​​the organization that is permitted to use the developer application. The usage condition data may also show the period during which the developer application is provided, the performance of the user terminal 4 on which the developer application can be used, the location of the user terminal 4, or other conditions as usage conditions.

[0180] The cloud system 1 in Modification 1-8 includes a user authorization unit 107. The user authorization unit 107 allows users of a service developer system 2 that are authorized according to the usage conditions defined in the developer application to use the developer application. For example, when a user of a certain service developer selects an application, the user authorization unit 107 determines, based on the usage conditions data, whether or not the user of that service developer is permitted to use the application. If the user authorization unit 107 determines that the use of the application is permitted, it causes the application usage unit 102 to execute the process for using the application. If the user authorization unit 107 determines that the use of the application is not permitted, it prevents the application usage unit 102 from executing the said process.

[0181] Furthermore, when a service developer applies for a cloud service, the permission unit 107 may determine, based on the usage conditions data, whether or not the service developer's users are permitted to use the application. If the permission unit 107 determines that the application is permitted, it authorizes the process of accepting the service developer's application for the cloud service. If the permission unit 107 determines that the application is not permitted, it does not authorize the process of accepting the service developer's application for the cloud service.

[0182] For example, when an administrator of a service developer performs an operation to display a list of applications handled by the cloud service, the authorization unit 107 determines whether the service developer meets the usage conditions indicated by the usage conditions data. If the application is only available to a specific organization, the authorization unit 107 obtains information about the organization to which the service developer belongs from the service developer system 2 or another system, and determines whether the service developer is that organization based on that information. If the authorization unit 107 determines that the service developer is that organization, it displays a screen on the service developer's terminal that allows them to apply for the application. The service developer applies for the application from that screen. If the service developer is from an organization that is not eligible to use the application, a screen is displayed that does not accept the application for the application, or a screen that does not contain any information about the application itself.

[0183] In Modification 1-8, Cloud System 1 allows users of a particular service developer system 2 to use the developer application, provided that these users are authorized according to the terms of use defined in the developer application. This allows Cloud System 1 to define terms of use for the application, thus enabling more flexible application usage. For example, if a service developer does not want other service developers to use their developer application, they can specify this in the terms of use, thereby preventing the application from being used by unintended users.

[0184] [Modifications 1-9] For example, a cloud provider may charge service developers in any way they choose. A cloud provider may charge service developers based on usage-based pricing for the amount of time users spend using the app. A cloud provider may charge service developers based on a price set for each app. Variation 1-9 explains a case where the service provider charges a price based on the number of users using the app.

[0185] The cloud system 1 in Modification 1-9 includes a billing processing execution unit 108. The billing processing execution unit 108 in Modification 1-9 executes billing processing for the service developer operating the service developer system 2, based on the number of users using the application. The billing processing can be any processing performed for the purpose of billing. In Modification 1-9, the example given is that the processing to calculate the billing amount corresponds to the billing processing, but the billing processing may be a settlement process such as bank withdrawal, a process to notify the service developer of the billing amount, or other processing.

[0186] For example, if information indicating which users use which applications is stored in the user database DB1, the billing execution unit 108 calculates the number of service developer users using the applications based on the user database DB1. The billing execution unit 108 may also obtain the number of users using individual applications from the service developer system 2. A unit price per user may be set for each application. Or, the unit price may be the same for all applications.

[0187] The unit price data, which indicates the unit price of the app per user, is stored in the data storage unit 100. The billing processing execution unit 108 acquires the unit price data. The billing processing execution unit 108 performs billing by calculating the amount to be billed to the service developer by multiplying the number of users by the unit price. For each service developer, the billing processing execution unit performs billing by calculating the amount to be billed to the service developer by multiplying the number of users of the service developer by the unit price of the app that the service developer contracts.

[0188] In Modification 1-9, Cloud System 1 executes a billing process for service developers operating Service Developer System 2, based on the number of users using the application. This enables Cloud System 1 to provide appropriate billing to service developers.

[0189] [Variations 1-10] For example, an app developer may code the app themselves, but some app developers may be unfamiliar with app development. Therefore, in Modification 1-10, we explain a case where a program showing the processing procedures, such as the process of obtaining an ID token, is provided by default. Basic processing common to each app is executed based on this default data.

[0190] The ID token acquisition unit 101 in Modification 1-10 is an ID token acquisition program that defines the process for acquiring an ID token, and acquires an ID token based on an ID token acquisition program included in common data provided to multiple developers who develop an application. The common data is data distributed to developers. Developers develop the application based on the common data. In Modification 1-10, the common data is assumed to be stored in the data storage unit 100, but the common data may be stored in a computer other than the application server 10, or in an information storage medium. The common data may be a program, data referenced by the program, a development manual, or other data.

[0191] For example, the ID token acquisition program shows a series of steps from when the ID token acquisition unit 101 starts acquiring an ID token until it finishes. The ID token acquisition program shows a process of receiving an application usage request from the user terminal 4, a process of confirming the session between the application and the user terminal 4, a process of requesting the authentication server 11 to acquire an ID token, a process of acquiring an ID token from the authentication server 11, or a combination of these. The ID token acquisition program may be written in any language. The ID token acquisition unit 101 acquires an ID token by executing the ID token acquisition program and performing the processes described in the first embodiment and modifications 1-1 to 1-9.

[0192] The application usage unit 102 in Modification 1-10 is an application usage program that defines the process for allowing the user to use the application, and allows the user to use the application based on the application usage program included in the common data. For example, the application usage program is shown to include a process for establishing a session between the application and the user terminal 4 based on an ID token, a process for maintaining communication based on the established session and inputting the data acquired by each party into the application, a process for recording the data uploaded by the user to the application in the data storage unit 100, or a combination of these. The application usage program may be written in any language. By executing the application usage program, the application usage unit 102 executes the processes described in the first embodiment and Modifications 1-1 to 1-9 to allow the user to use the application.

[0193] In the modified example 1-10, Cloud System 1 acquires an ID token based on an ID token acquisition program included in the common data. Cloud System 1 is an application usage program that defines the process of allowing users to use the application, and it allows users to use the application based on the application usage program included in the common data. As a result, Cloud System 1 can reduce the effort required for developers to develop applications.

[0194] [3-2. Modifications relating to the second embodiment] Figure 15 shows an example of a function realized in a modified version of the second embodiment. As shown in Figure 15, in the modified version of the second embodiment, the application server 10 implements a data storage unit 100 and an application utilization unit 102. The data storage unit 100 and the application utilization unit 102 may be the same as those in the first embodiment and any of the modified versions 1-1 to 1-10.

[0195] [Variation 2-1] For example, the data to be synchronized by the data synchronization function described in the second embodiment is not limited to the example of the second embodiment. Modification 2-1 is an example in which the application usage function provisioning unit 121 acquires service developer data managed by each of the multiple service developer systems 2 based on the data synchronization function provided to each of the multiple service developer systems 2 and records it in the cloud system 1. The application usage function provisioning unit 121 associates the service developer from which the service developer data was acquired with information that can identify the service developer (for example, a service developer ID) and records the service developer data in the cloud system 1.

[0196] Service developer data is data stored in the data storage unit 201 of the service developer system 2. Service developer data can also be described as data referenced by applications. The synchronized data described in the second embodiment is also an example of service developer data. Modification 2-1 takes the case where data registered by a user in the service developer system 2 corresponds to service developer data. The application usage function provision unit 121 executes a program included in the data synchronization function and obtains service developer data from the service developer system 2.

[0197] For example, if the developer service is groupware A, the application usage function provision unit 121 may acquire business data registered by the user in the service developer system 2 of groupware A as service developer data. Business data is data that indicates the content of the business of the tenant to which the user belongs (for example, the company where the user works). For example, business data may be documents that show the content of the business, documents created by the user as part of their work, messages sent and received between users, notifications to the user, the content of the workflow, the user's schedule, or other data. The application usage function provision unit 121 acquires business data from the business data stored in the service developer system 2 of groupware A that is permitted to be provided to the cloud system 1 as service developer data.

[0198] For example, if the developer service is cloud accounting software B, the application usage function provision unit 121 may acquire accounting data registered by the user in the service developer system 2 of cloud accounting software B as service developer data. Accounting data is data that shows the details of accounting that occurred in the tenant to which the user belongs (for example, the company where the user works). For example, accounting data may be invoices, quotations, receipts, expenses, salaries, financial statements, or other data. The application usage function provision unit 121 acquires accounting data from the accounting data stored in the service developer system 2 of cloud accounting software B that is permitted to be provided to the cloud system 1 as service developer data.

[0199] For example, if the developer service is website creation software C, the application usage function provision unit 121 may acquire website data registered by the user in the service developer system 2 of the website creation software C as service developer data. Website data is data that indicates the content of a website created in the tenant to which the user belongs (for example, the company where the user works). For example, website data may be the HTML data of the website, the layout data of the website, the data registered on the website, or other data. The application usage function provision unit 121 acquires website data from the website data stored in the service developer system 2 of the website creation software C that is permitted to be provided to the cloud system 1 as service developer data.

[0200] The application usage function provider 121 may record service developer data in any location on the cloud system 1. For example, the application usage function provider 121 may record service developer data in the data storage unit 100, data storage unit 110, or data storage unit 120. If other computers not shown in Figure 10 are included in the cloud system 1, the application usage function provider 121 may record service developer data on those other computers. The application usage function provider 121 may also record service developer data on an information storage medium not shown in Figure 10.

[0201] The cloud system 1 in Modification 2-1 includes an application usage unit 102. The application usage unit 102 allows users of a service developer system 2 to use an application used by that service developer system 2, based on the service developer data of each of the multiple service developer systems 2. The function of the application usage unit 102 in Modification 2-1 may be the same as in the first embodiment, or it may allow the application to be used without relying on an ID token. The data described in the first embodiment as being referenced by the application becomes service developer data in Modification 2-1.

[0202] For example, the application usage unit 102 executes an application available on a certain service developer system 2 (for example, an application that the developer service has a usage agreement for) and causes the application to reference service developer data obtained from the service developer system 2. The application usage unit 102 may update the service developer data based on the execution result of the application. The service developer data updated by the application usage unit 102 may be synchronized to match the service developer data managed by the service developer system 2. That is, the application usage unit 102 may request the service developer system 2 to overwrite the service developer data managed by the service developer system 2 with the service developer data updated by the application usage unit 102. The service developer system 2 may overwrite the service developer data in response to the request from the application usage unit 102.

[0203] For example, suppose the developer service is groupware A, and the business data registered in the service developer system 2 of groupware A corresponds to the service developer data. In this case, the application usage unit 102 causes the application to refer to the business data stored in the cloud system 1, or updates the business data based on the execution results of the application. If the application is "XXX Chat", the application usage unit 102 may display the contents of the business data on "XXX Chat", or update the contents of the business data based on operations performed in "XXX Chat".

[0204] For example, suppose the developer service is cloud accounting software B, and the accounting data registered in the service developer system 2 of cloud accounting software B corresponds to the service developer data. In this case, the application usage unit 102 causes the application to refer to the accounting data stored in the cloud system 1, or updates the accounting data based on the execution results of the application. If the application is "XXX Chat", the application usage unit 102 may display the contents of invoices etc. indicated by the accounting data on "XXX Chat", or update the contents of invoices etc. indicated by the accounting data based on operations performed in "XXX Chat".

[0205] For example, suppose the developer service is website creation software C, and the website data registered in the service developer system 2 of website creation software C corresponds to the service developer data. In this case, the application usage unit 102 causes the application to refer to the website data stored in the cloud system 1, or updates the website data based on the execution results of the application. If the application is "XXX Chat", the application usage unit 102 may display the content of the website indicated by the website data on "XXX Chat", or update the HTML content indicated by the website data based on operations performed in "XXX Chat".

[0206] In Modification 2-1, the cloud system 1 retrieves service developer data managed by each of the multiple service developer systems 2 based on the data synchronization function provided to each of the multiple service developer systems 2 and records it in the cloud system 1. Based on the service developer data of each of the multiple service developer systems 2, the cloud system 1 makes the applications used by each service developer system 2 available to the users of that service developer system 2. As a result, users can use the service developer data they use in their developer services in the applications of the cloud system 1, thus improving user convenience. For example, users do not have to go through the trouble of copying the service developer data managed by the service developer system 2 to the cloud system 1 and using it in the application. When the service developer data managed by the cloud system 1 and the service developer data managed by the service developer systems 2 are consistent (synchronized), the cloud system 1 can prevent these data from becoming inconsistent.

[0207] [Modification 2-2] For example, the application usage function is not limited to the data synchronization function described in the second embodiment and modification 2-1. The application usage function providing unit 121 in modification 2-2 provides each of the multiple service developer systems 2 with an application processing execution function as an application usage function, which executes application processing related to applications used by the service developer system 2 based on the service developer data managed by the service developer system 2. In modification 2-1, the case in which the service developer data is recorded in the cloud system 1 was given as an example, but in modification 2-2, the service developer data does not have to be recorded in the cloud system 1. The application usage function providing unit 121 may acquire the service developer data from the cloud system 1 and execute the application processing without specifically recording it (only performing temporary recording for application processing).

[0208] The application processing execution function includes a program that indicates application processing. Application processing may include processing that references service developer data, processing that is executed based on the referenced service developer data, processing that updates service developer data, or a combination thereof. The processing of the application utilization unit 102 described in Modification 2-1 is also an example of application processing executed by the application processing execution function. If the processing of the application utilization unit 102 corresponds to application processing, the application utilization unit 102 may be implemented by the control unit 12A of the synchronization server 12. In Modification 2-2, the data storage unit 120 stores each of the multiple applications. That is, in Modification 2-2, the data storage unit 120 corresponds to the application storage unit. The actual application data may be the same as in the first embodiment, the second embodiment, and Modification 2-1.

[0209] For example, the application usage function provision unit 121 executes an application available on a certain service developer system 2 (for example, an application for which a developer service has a usage agreement) and causes the application to refer to service developer data obtained from the service developer system 2. The application usage function provision unit 121 transmits data indicating the execution result of the application to the service developer system 2 or the user terminal 4. The service developer system 2 may update its own service developer data based on this data. The user terminal 4 may update the screen displayed on it based on this data. The application usage function provision unit 121 may also update the service developer data based on the execution result of the application, similar to the application usage unit 102 in Modification 2-1.

[0210] For example, suppose the developer service is groupware A, and the business data registered in the service developer system 2 of groupware A corresponds to the service developer data. In this case, the application usage function provision unit 121 will cause the application to refer to the business data obtained from the service developer system 2 of groupware A, or update the business data based on the execution results of the application. If the application is "XXX Chat", the application usage function provision unit 121 may display the contents of the business data on "XXX Chat", or update the contents of the business data based on operations performed in "XXX Chat".

[0211] For example, suppose the developer service is cloud accounting software B, and the accounting data registered in the service developer system 2 of cloud accounting software B corresponds to the service developer data. In this case, the application usage function provision unit 121 allows the application to refer to the accounting data obtained from the service developer system 2 of cloud accounting software B, or updates the accounting data based on the execution results of the application. If the application is "XXX Chat", the application usage function provision unit 121 may display the contents of the accounting data on "XXX Chat", or update the contents of the accounting data based on operations performed in "XXX Chat".

[0212] For example, suppose the developer service is website creation software C, and the website data registered in the service developer system 2 of website creation software C corresponds to the service developer data. In this case, the application usage function provision unit 121 may cause the application to refer to the website data obtained from the service developer system 2 of website creation software C, or update the website data based on the execution results of the application. If the application is "XXX Chat", the application usage function provision unit 121 may display the content of the website indicated by the website data on "XXX Chat", or update the HTML content indicated by the website data based on operations performed in "XXX Chat".

[0213] The cloud system 1 in Modification 2-2 provides each of the multiple service developer systems 2 with an application processing execution function as an application usage function, which executes application processing related to applications used by the service developer system 2 based on the service developer data managed by the service developer system 2. This allows the cloud system 1 to make the service developer data managed by the service developer system 2 available to applications. For example, the cloud system 1 can improve convenience for businesses operating the service developer system 2, or for users of the service developer system 2.

[0214] [Modification 2-3] For example, the application usage function is not limited to the examples described in the second embodiment and modified examples 2-1 and 2-2. The application usage function providing unit 121 in modified example 2-3 provides a cloud data providing function as an application usage function to each of the multiple service developer systems 2, which provides cloud data managed by the cloud system 1, relating to applications used by the service developer system 2.

[0215] Cloud data is data stored in Cloud System 1. For example, it may be data generated by Cloud System 1 (e.g., a cloud service user ID, user information managed independently by Cloud System 1, or tenant information managed independently by Cloud System 1), data generated by the execution results of an application and stored in Cloud System 1, data registered in an application at the request of Service Developer System 2 (e.g., data registered in an application by user operation), or other data.

[0216] The cloud data provision function includes a program that indicates the process for providing cloud data to the service developer system 2. Providing cloud data means sending cloud data to the service developer system 2. For example, the cloud data provision function includes a program that indicates a series of processes, including acquiring cloud data and sending cloud data to the service developer system 2. The cloud data provision function may also be a function that performs processing on cloud data and sends the data acquired by the execution of said processing to the service developer system 2.

[0217] In variation 2-3, we take the example of a case where cloud data is stored in the data storage unit 120. For example, the application usage function provision unit 121 executes a program for the cloud data provision function and obtains the cloud data to be provided from the data storage unit 120. The application usage function provision unit 121 may also obtain the cloud data to be provided from another computer other than the synchronization server 12 (for example, the application server 10 or the authentication server 11), or from an information storage medium. The application usage function provision unit 121 transmits the cloud data to the service developer system 2 that requested the cloud data. The service developer system 2 can use the cloud data obtained from the cloud system 1 for any purpose. For example, the service developer system 2 may store the cloud data for management purposes, or it may perform information processing based on the cloud data and provide the processing results to the user.

[0218] For example, if the cloud data is a user ID for a cloud service, the application usage function provision unit 121 provides a service developer system 2 with a user ID for identifying users of the service developer system 2 in the cloud service as cloud data. If the cloud data is user information managed independently by the cloud service, the application usage function provision unit 121 provides a service developer system 2 with user information for independently managing users of the service developer system 2 in the cloud service as cloud data. If the cloud data is tenant information managed independently by the cloud service, the application usage function provision unit 121 provides a service developer system 2 with tenant information for independently managing tenants of the service developer system 2 in the cloud service as cloud data.

[0219] In modified example 2-3, the cloud system 1 provides each of the multiple service developer systems 2 with a cloud data provision function as an application usage function, which provides cloud data related to the applications used by the service developer system 2. This allows the cloud system 1 to provide the cloud data it manages for application use. For example, the cloud system 1 can improve convenience for businesses operating the service developer systems 2, or for users of the service developer systems 2.

[0220] [Modification 2-4] For example, the application usage function is not limited to the examples described in the second embodiment and modified examples 2-1 to 2-3. The application usage function provisioning unit 121 of modified example 2-4 provides each of the multiple service developer systems 2 with a license information management function as an application usage function, which manages license information related to the licenses of applications used by the service developer system 2 in the cloud system 1.

[0221] License information is information that shows the details of the contract for an application that a service developer has contracted. For example, license information may include the contractor, contract period, amount, number of users who can use the application, application usage plan, other contract terms, application settings, or other information. For example, when a service developer enters into an application usage contract, cloud system 1 records the license information. License information may be created by the cloud service administrator, or it may be created based on the communication content between cloud system 1 and service developer system 2.

[0222] The license information management function includes a program that shows the process for managing license information in the cloud system 1. For example, the license information management function may include a program that shows the process for obtaining license information created by the cloud service administrator, a program that shows the process for creating license information based on the communication content between the cloud system 1 and the service developer system 2, a program that shows the process for recording license information in the cloud system 1, a program that shows the process for updating license information, or a combination of these.

[0223] Modification 2-4 takes the example of a case where license information is stored in the data storage unit 120. For example, the application usage function provision unit 121 executes a license information management function program and records the license information in the data storage unit 120. The application usage function provision unit 121 may also record the license information on another computer other than the synchronization server 12 (for example, the application server 10 or the authentication server 11), or on an information storage medium. The application usage function provision unit 121 may also provide the license information to the service developer system 2 of a service developer who has the license indicated by the license information. When a service subscriber renews the application usage contract, the application usage function provision unit 121 may obtain the renewal details from the service developer system 2 and update the license information.

[0224] In the modified version 2-4, the cloud system 1 provides each of the multiple service developer systems 2 with a license information management function as an application usage function, which manages the license information of the applications used by the service developer system 2. This allows the cloud system 1 to properly manage the license information of the applications. For example, the cloud system 1 can prevent applications from being used fraudulently.

[0225] [Modification 2-5] For example, the app usage function is not limited to the examples described in the second embodiment and modified versions 2-1 to 2-4. The app usage function providing unit 121 in modified version 2-5 provides a list providing function as an app usage function, which provides each of the multiple service developer systems 2 with a list of apps that can be used in the service developer system 2. The list may be displayed on the terminal of the service developer's administrator or on the user terminal 4. The list can also be described as a list of apps that the service developer can contract.

[0226] The list provision function includes a program that shows the process for providing a list of applications. For example, the list provision function may include a program that shows the process for reading the list of applications, a program that shows the process for sending the list of applications data to the service developer system 2, a program that shows the process for receiving the selection result of the list of applications, a program that shows the process for completing the user agreement based on the selection result, or a combination of these. For example, the application usage function provision unit 121 executes the list provision function program and provides the list of applications stored in the data storage unit 120.

[0227] The application list data is assumed to be stored in the data storage unit 120, but it may also be stored in another computer other than the synchronization server 12 (for example, the application server 10 or the authentication server 11), or in an information storage medium. The application usage function provision unit 121 may obtain the application list data from another computer or information storage medium. For example, the application list data may include the name of each application, a description of the application, an image of the application, a video introducing the application, the contents of the application usage agreement, or other information. For example, the application usage function provision unit 121 provides the application list data to the service developer system 2. If the available applications differ depending on the service developer's industry or other conditions, the application usage function provision unit 121 may provide the service developer system 2 with a list of applications that matches the industry or other conditions.

[0228] Furthermore, the app usage function provision unit 121 may provide the service developer system 2 with a list of apps before the service developer enters into an app usage agreement. In this case, the service developer system 2 will consider app contracts based on the list of apps. The app usage function provision unit 121 may also provide the service developer system 2 with a list of apps after the service developer has entered into an app usage agreement. In this case, the service developer system 2 will consider additional apps to be contracted or review the contract details of apps currently in use based on the list of apps.

[0229] In Modified Example 2-5, Cloud System 1 provides each of the multiple service developer systems 2 with a list provision function, which provides a list of applications available for use in that service developer system 2, as an application usage function. This allows Cloud System 1 to improve the convenience of those considering using applications on the service developer system 2 side. For example, Cloud System 1 can improve the convenience of service developer administrators and users.

[0230] [Modification 2-6] For example, the app usage function is not limited to the examples described in the second embodiment and modifications 2-1 to 2-5. The app usage function providing unit 121 in modification 2-6 provides each of the multiple service developer systems 2 with a usage status management function as an app usage function, which manages the usage status of the app used by the service developer system 2. The app usage status is information that shows how the app is being used. For example, the app usage status may be the number of app users, the number of times the app is used, the frequency of app use, the amount of data registered in the app, or a combination of these.

[0231] The usage status provision function includes a program that indicates the process for providing the usage status of the application. For example, the usage status provision function may include a program that indicates the process for reading the application usage status, a program that indicates the process for aggregating the application usage status, a program that indicates the process for sending the application usage status data to the service developer system 2, or a combination thereof. The usage status data related to the application usage status is stored in the data storage unit 100. The usage status data may also include data related to the application usage history. For example, the usage status data may include the number of application users, the number of times the application is used, the frequency of application use, the amount of data registered in the application, or a combination thereof.

[0232] For example, when an application is used in a service developer system 2, the application server 10 updates the usage data of the application associated with that service developer system 2. The application server 10 may update the usage data so that the number of users of the application increases. The application server 10 may update the usage data so that the number of times the application is used increases. The application server 10 may update the usage data so that the frequency of use of the application increases. The application server 10 may update the usage data so that the amount of data registered in the application increases.

[0233] For example, the application usage function provision unit 121 executes a program for the usage status provision function and provides application usage data stored in the data storage unit 100. The application usage data may be stored on a computer other than the application server 10 (for example, the authentication server 11 or the synchronization server 12) or on an information storage medium. The application usage function provision unit 121 may acquire application usage data from another computer or information storage medium. The application usage function provision unit 121 provides the application usage data to the service developer system 2. The service developer system 2 may save the application usage data or display the contents of the application usage data on the user terminal 4.

[0234] In Modified Example 2-6, the cloud system 1 provides each of the multiple service developer systems 2 with a usage management function, which manages the usage status of the applications used by that service developer system 2, as an application usage function. This allows the cloud system 1 to check the application usage status on the service developer system 2 side, thereby improving convenience for the service developer system 2.

[0235] [Modification 2-7] For example, the application usage function is not limited to the examples described in the second embodiment and modifications 2-1 to 2-6. The application usage function providing unit 121 in modification 2-7 provides each of the multiple service developer systems 2 with a billing function that charges according to the application used by the service developer system 2, as an application usage function. The application usage function providing unit 121 in modification 2-7 may have the same function as the billing processing execution unit 108 described in modification 1-9.

[0236] The billing function includes a program that processes billing to the service developer system 2. For example, the billing function may include a program that determines the billing amount based on the app's usage (e.g., the number of users), a program that retrieves a fixed billing amount, a program that retrieves payment method information for the service developer system 2 (e.g., credit card number, bank account information, or electronic money information), or a combination of these.

[0237] For example, the app usage function provision unit 121 executes a billing function program and determines the amount to be charged to the service developer system 2. The app usage function provision unit 121 then executes the settlement process for the determined amount. Alternatively, instead of executing the settlement, the app usage function provision unit 121 may perform the billing process by generating an invoice corresponding to the amount to be charged and sending the invoice to the service developer system 2.

[0238] In Modified Example 2-7, the cloud system 1 provides each of the multiple service developer systems 2 with a billing function as an application usage function, which charges based on the applications used by that service developer system 2. This allows the cloud system 1 to perform billing for the service developer systems 2, thereby improving convenience for the administrator of the cloud system 1.

[0239] [3-3. Other variations] For example, you may combine two or more of the above variations.

[0240] For example, the functions described as being implemented by the application server 10 may also be implemented by the authentication server 11, the synchronization server 12, the service developer system 2, the authentication system 3, and the user terminal 4. Each function may be shared among multiple computers or implemented by a single computer. Each function may also be implemented by a computer not shown in Figures 1 and 10 (for example, the computer of the administrator managing the cloud system 1). [Explanation of symbols]

[0241] 1 Cloud system, 2 Service developer system, 3 Authentication system, 4 User terminal, 10 Application server, 10A,11A,12A Control unit, 10B,11B,12B Storage unit, 10C,11C,12C Communication unit, 11 Authentication server, 12 Synchronization server, 100,120,201 Data storage unit, 101 Token acquisition unit, 102 Application usage unit, 103 Access token acquisition unit, 104 First addition unit, 105 Second addition unit, 106 Environment creation unit, 107 Usage permission unit, 108 Billing processing execution unit, 111 Intermediation unit, 112 Token issuance unit, 121 Application usage function provision unit, 200 Service provision unit, 202 Synchronization unit, 300 Token issuance unit, 400 Data storage unit, N Network, DB1 User database, DB2 Synchronization database, P1 Login page, P2 Top page, P3 Service usage page, I30 Icons, L31 List, P32 Side panel.

Claims

1. A cloud system that can be linked with each of multiple service developer systems, A data storage unit that stores application data for multiple applications managed by the aforementioned cloud system, A data synchronization function providing unit provides each of the multiple service developer systems with a data synchronization function for synchronizing data with the cloud system in order to make any of the multiple applications available on the service developer system. Includes, The aforementioned data synchronization function providing unit When a service developer operating each of the aforementioned multiple service developer systems enters into a usage agreement for the cloud system, the service developer system receives a synchronization request, retrieves the user IDs of each of the multiple users managed by the service developer system, and the user information of those users, issues a cloud service user ID for each user, associates each user's cloud service user ID, each user's developer service user ID, and the user information, and stores them in the synchronization database. The process of performing synchronization involves obtaining tenant information for each tenant from each of the multiple service developer systems, or transmitting information generated by the cloud system to each of the multiple service developer systems, or transmitting data indicating the execution result of the application to each of the multiple service developer systems. When a service developer operating one of the aforementioned multiple service developer systems enters into a usage agreement for the cloud system, and the administrator of the cloud system detects that the service developer has entered into a usage agreement and has registered usage agreement data on the cloud system, the administrator requests synchronization from the service developer system and retrieves the data to be synchronized provided by the service developer system in response to the request. The data synchronization function is provided by performing at least one of the following: Cloud system.

2. The data synchronization function provider unit, based on the data synchronization function provided to each of the multiple service developer systems, acquires service developer data managed by the service developer system from the service developer system and records it in the cloud system. The cloud system includes an application utilization unit that, based on the service developer data of each of the plurality of service developer systems, allows users of the service developer systems to use the applications used by those service developer systems. The cloud system according to claim 1.

3. A cloud system that can be linked with each of multiple service developer systems, A data storage unit that stores application data for multiple applications managed by the aforementioned cloud system, An application processing execution function providing unit that, for each of the multiple service developer systems, provides an application processing execution function that executes application processing related to an application used in the service developer system based on service developer data managed by the service developer system, in order to make any application among the multiple applications available in the service developer system; Includes, The aforementioned application processing execution function providing unit Each of the developer services of the aforementioned multiple service developer systems executes the application for which it has a usage agreement, causes the application to refer to service developer data obtained from the service developer system, transmits data indicating the execution result of the application to the service developer system or the user terminal, and updates the service developer data based on the execution result of the application, thereby providing the application processing execution function. Cloud system.

4. A cloud system that can be linked with each of multiple service developer systems, A data storage unit that stores application data for multiple applications managed by the aforementioned cloud system, A cloud data provision function provisioning unit provides a cloud data provisioning function to each of the aforementioned multiple service developer systems, in order to make any of the aforementioned applications among the aforementioned multiple applications available to the service developer system, the cloud data managed by the cloud system, which relates to the applications used by the service developer system, to the service developer system. Includes, The cloud data provision function provision unit acquires the cloud data to be provided and provides the cloud data provision function by transmitting the cloud data to the service developer system that requested the cloud data. Cloud system.

5. A cloud system that can be linked with each of multiple service developer systems, A data storage unit that stores application data for multiple applications managed by the aforementioned cloud system, A license information management function provider unit provides a license information management function to each of the aforementioned multiple service developer systems, which manages license information relating to the licenses of the applications used in the service developer system in the cloud system, in order to make any of the aforementioned applications available in the service developer system. Includes, The license information management function provider records the license information, provides the license information to the service developer system of a service developer who possesses the license indicated by the license information, and, when the service developer renews the application usage agreement, obtains the update details from the service developer system and updates the license information, thereby providing the license information management function. Cloud system.

6. A cloud system that can be linked with each of multiple service developer systems, A data storage unit that stores application data for multiple applications managed by the aforementioned cloud system, A list provision function provision unit provides a list of applications that are available for use in the service developer system, in order to make any of the applications available for use in the service developer system, for each of the multiple service developer systems. Includes, The list provision function provision unit provides the list provision function by acquiring data of the list of applications before each service developer of the multiple service developer systems enters into a usage agreement for the application, or after each service developer of the multiple service developer systems enters into a usage agreement for the application, and providing the data of the list of applications to the service developer system. Cloud system.

7. A cloud system that can be linked with each of multiple service developer systems, A data storage unit that stores application data for multiple applications managed by the aforementioned cloud system, A usage status management function providing unit that provides a usage status management function to each of the multiple service developer systems in order to make any application among the multiple applications available in the service developer system, for managing the usage status of the application used in the service developer system, Includes, The usage status management function provider unit provides the usage status management function by updating the usage status data of the application associated with each of the multiple service developer systems when the application is used in that service developer system. Cloud system.

8. A cloud system that can be linked with each of multiple service developer systems, A data storage unit that stores application data for multiple applications managed by the aforementioned cloud system, A billing function providing unit that provides a billing function to each of the multiple service developer systems, in order to make any of the multiple applications available in the service developer system, and that charges according to the application used in the service developer system, Includes, The billing function provider unit provides the billing function by determining the amount to be charged to each of the multiple service developer systems, executing the settlement process for the determined amount, or generating an invoice corresponding to the determined amount. Cloud system.

9. Computers To each of the multiple service developer systems that can be linked with a cloud system that manages multiple applications, a data synchronization function is provided to each of the multiple service developer systems for synchronizing data with the cloud system, in order to make any of the applications among the multiple applications available in the service developer system. When a service developer operating each of the aforementioned multiple service developer systems enters into a usage agreement for the cloud system, the service developer system receives a synchronization request, retrieves the user IDs of each of the multiple users managed by the service developer system, and the user information of those users, issues a cloud service user ID for each user, associates each user's cloud service user ID, each user's developer service user ID, and the user information, and stores them in the synchronization database. The process of performing synchronization involves obtaining tenant information for each tenant from each of the multiple service developer systems, or transmitting information generated by the cloud system to each of the multiple service developer systems, or transmitting data indicating the execution result of the application to each of the multiple service developer systems. When a service developer operating one of the aforementioned multiple service developer systems enters into a usage agreement for the cloud system, and the administrator of the cloud system detects that the service developer has entered into a usage agreement and has registered usage agreement data on the cloud system, the administrator requests synchronization from the service developer system and retrieves the data to be synchronized provided by the service developer system in response to the request. The data synchronization function is provided by performing at least one of the following: How it is provided.

10. A data synchronization function providing unit provides each of the multiple service developer systems, which are capable of cooperating with a cloud system that manages multiple applications, with a data synchronization function for synchronizing data with the cloud system, in order to make any of the applications among the multiple applications available in the service developer system. To make the computer function as, The aforementioned data synchronization function providing unit When a service developer operating each of the aforementioned multiple service developer systems enters into a usage agreement for the cloud system, the service developer system receives a synchronization request, retrieves the user IDs of each of the multiple users managed by the service developer system, and the user information of those users, issues a cloud service user ID for each user, associates each user's cloud service user ID, each user's developer service user ID, and the user information, and stores them in the synchronization database. The process of performing synchronization involves obtaining tenant information for each tenant from each of the multiple service developer systems, or transmitting information generated by the cloud system to each of the multiple service developer systems, or transmitting data indicating the execution result of the application to each of the multiple service developer systems. When a service developer operating one of the aforementioned multiple service developer systems enters into a usage agreement for the cloud system, and the administrator of the cloud system detects that the service developer has entered into a usage agreement and has registered usage agreement data on the cloud system, the administrator requests synchronization from the service developer system and retrieves the data to be synchronized provided by the service developer system in response to the request. The data synchronization function is provided by performing at least one of the following: program.

Images