Administrative institution, administrative system, tax procedure and storage medium

Abstract

Administrative unit that can communicate with an inventory unit and a service provider unit to provide services to the inventory unit using resources and manages access rights to the resources with respect to the service provider unit, with an administrative unit for managing trust information between service provider entities and trust information between the existing entity and the service provider entity, and a setting unit for setting up a transfer of access rights held by a first service provider institution to the resources of a second service provider institution, where, if the hiring unit determines, based on the trust information, that the second service provider trusts the first service provider, the existing service provider trusts the first service provider, and the existing service provider trusts the second service provider, the hiring unit suspends the transfer of access rights.

Description

BACKGROUND OF THE INVENTIONField of the invention

[0001] The present invention relates to a management device, a management system, a control method and a storage medium. Description of related technology

[0002] Previously, a cloud system was proposed in which a service provider manages data belonging to customers. The term "service provider" refers to a company that provides various services to customers using a service provider. In the cloud service, data storage and user information are managed by a tenant, which is a dedicated region for each customer. In the cloud service, data is managed in a tenant unit, and a service provider can only access data in a tenant to which the service provider itself belongs, but is not allowed to access other tenants. However, for a service provider to manage customer data to which customers have entrusted business activities, the service provider must access customer data stored in a customer tenant (a tenant belonging to a customer).The service provider cannot provide data management services if it cannot access customer data. Since customer data may contain personal and confidential information, the service provider must be able to access customer data after the customer has given their prior consent.

[0003] Japanese Patent Laid-Open No. 2010-108170 discloses a role-based access control method. In the role-based access control method, a management device permits access to each data item and each function for each user, depending on their role. The management device determines access to a data object and a function object based on a role set in user identification information.

[0004] The user environment for using a cloud service is assumed to be the following. For example, consider that a customer who has entered into a service provision contract with a service provider is a large company with numerous internal companies or a global company whose headquarters are spread across a wide area. In this case, a single service provider cannot provide services for all customers. Therefore, the single service provider can outsource services for customers to another service provider (second service provider). To ensure secure outsourcing, outsourced customers are managed by dividing them into shared tenants in regional units or corporate group units, so that the scope of outsourced customers can be clarified.Rights are then granted to a second service provider, who serves as an entrustee for each sub-customer tenant, so that the second service provider can be entrusted with services.

[0005] However, a second service provider cannot necessarily have a direct relationship with a tenant for a entrusted customer, either because there is no service contract between them or because they do not have a top-down relationship in the hierarchical structure. For security reasons, the second service provider cannot therefore obtain direct access rights to the data (resources) of a entrusted customer. SUMMARY OF THE INVENTION

[0006] The present invention provides a method for entrusting another service provider with a service for a customer tenant provided by a service provider to securely transfer access rights to customer data.

[0007] According to one embodiment of the invention, a management device is provided that can communicate with an existing device and a service provider device for providing services using resources for the existing device, and manages access rights to the resources related to the service provider device. The management device includes a management unit for managing trust relationship information between the service providers and trust relationship information between the existing device and the service provider device, and a setting unit for setting a transfer of access rights to the resources held by a first service provider device to a second service provider device.If it is determined based on the obtained trust relationship information that the second service provider device trusts the first service provider device, the existing device trusts the first service provider device, and the existing device trusts the second service provider device, the setting unit sets the transfer of the access rights.

[0008] Further features of the invention will become apparent from the following description of the embodiments with reference to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS Fig. 1 illustrates a configuration of an access rights management system according to an embodiment of the invention. Fig. Figure 2 illustrates hardware configurations of a host computer and a management server. The Fig. 3A and Fig. 3B illustrates software configurations of the host computer and the management server. The Fig. Figures 4A to 4D illustrate the configurations of the respective tables managed by the management server. The Fig. 5A and Fig. 5B illustrates the configurations of the respective tables managed by the management server. The Fig. 6A and Fig. 6B illustrates the configurations of the respective tables managed by the management server. The Fig. 7A and Fig. 7B illustrates the configurations of the respective tables managed by the management server. The Fig. 8A and Fig. 8B illustrate examples of hierarchical client structures. Fig. 9 shows a flowchart illustrating the flow of user authentication processing. The Fig. 10A and Fig. 10B illustrate examples of home pages for a service provider and a customer. The Fig. 11A and Fig. 11B illustrate examples of screens used by a service provider. The Fig. 12A and Fig. 12B illustrate examples of screens used by a service provider. The Fig. 13A and Fig. 13B show examples of access permission acceptance screens used by a customer tenant. The Fig. 14A and Fig. 14B illustrate examples of service entrustment management screens used by a service provider. Fig. 15 illustrates an example of a service entrustment setting screen used by a service provider. Fig. 16 illustrates an example of a service entrustment acceptance screen used by a service provider. The Fig. 17A and Fig. 17B show flowcharts illustrating access permission processing and entrustment / transfer acceptance processing. The Fig. 18A and Fig. 18B show flowcharts illustrating entrustment / transfer acceptance processing according to a second embodiment and a third embodiment. The Fig. 19A to 19C are schematic diagrams illustrating a transfer / entrustment instruction and a transfer determination condition. The Fig. 20A and Fig. 20B are schematic diagrams showing a transfer / entrustment instruction and a transfer determination condition according to the third embodiment. Fig. 21 shows a flowchart illustrating the flow of access permission acceptance processing. Fig. 22 shows a flowchart illustrating the flow of entrustment instruction processing. Fig. 23 shows a flowchart illustrating the flow of entrustment acceptance processing performed by a service provider. Fig. 24 is a flowchart showing the flow of transfer instruction acceptance processing performed by a customer. Fig. 25 is a flowchart showing the flow of transmission determination processing. The Fig. 26A and Fig. 26B show flowcharts illustrating the flow of trust relationship determination processing. DESCRIPTION OF THE EMBODIMENTS

[0009] Specific embodiments of the invention are described in more detail below with reference to the drawings. It is noted that the following embodiments are not intended to limit the claims of the invention. Furthermore, not all combinations of features described in the embodiments are necessarily essential to achieving the object of the invention. <Erstes Ausführungsbeispiel> [General System Configuration]

[0010] Fig. 1 shows a diagram of an example configuration of an information processing system of this embodiment. A management system that performs access rights management includes host computers 101 and 102 and a management server 103. The host computers 101 and 102 and the management server 103 are connected to each other via a network 104 using a known technology such as LAN (Local Area Network), the Internet, or the like for communication.

[0011] The host computer 101 is a service provision device used by a service provider. A user of the service provider uses the service provision device when using a service provided by a management server 103 using the host computer 101 or editing customer data held in the management server 103. A service provider also entrusts another service provider with services for customers. The term "entrustment" used here refers to the process of executing a service provision request from one service provider to another service provider for the service provider when the service provider, trusted by its customers, can provide services to all customers. A service provider also registers customer tenants on the management server 103 to perform operations such as executing a customer data access permission request, providing an access rights transfer function, or the like.For example, if a first service provider entrusts a second service provider with providing services to customers, the second service provider cannot provide services if the second service provider does not have access rights to customer data from customer tenants. As used herein, "transfer" refers to the process of granting the second service provider access rights to customer data from a customer tenant that has received an instruction from the first service provider that has access rights to that customer data.

[0012] If the second service provider accepts the entrustment from the first service provider, or if the client-tenant transfers access rights to the second service provider, a mutual trust relationship is established between the second service provider and the client-tenant. The relationship between the parties when an acceptance instruction, such as an access permission, entrustment, or the like, is provided from one party to the other and the other party accepts the instruction is defined as "trust." Similarly, the relationship between the client-tenant and the second service provider when the client-tenant, who has received a transfer instruction from the first service provider, accepts the instruction is defined as "trust."If the second service provider trusts the first service provider, and the client-tenant, who has received an instruction from the first service provider with a trust relationship with the second service provider, trusts the second service provider, a trust relationship is established among these three parties, so that the above-mentioned entrustment and transfer can be carried out. Note that if the client-tenant delegates its access rights to the first service provider with a trust relationship with the client-tenant, a trust relationship is established between the three parties, even if the client-tenant does not trust the second service provider, so that the above-mentioned entrustment and transfer can be carried out.The term "delegation" refers to delegating the transfer of access rights to the first service provider in the transfer instruction given by the first service provider with a trust relationship with the client tenant. Thus, even if the client tenant does not perform access rights transfer processing, the second service provider can obtain access rights to client data. Although not shown, the host computer 101 is provided in a plurality for each service provider group or for each service provider.

[0013] The host computer 102 is an inventory device that holds data used by customer clients. The term "customer client" refers to a company divided into regional units or corporate group units, and uses a service provider that provides services such as data management or the like. A customer accesses the management server 103 from the host computer 102 and enters their user ID and password for user authentication. The customer then uses services provided by the management server 103 or edits customer data held by the management server. The customer also provides a permission or rejection instruction for an access permission request or a rights transfer instruction issued by the service provider. Although not illustrated, the host computer 102 is provided in multiples for each customer client group or for each customer client.

[0014] The management server 103 manages a plurality of service provider tenants (hereinafter also referred to as "SP tenant") or customer tenants divided into regional units or company group units, to manage user information for users belonging to the respective tenants. The management server 103 performs user authentication to identify a tenant to which the user belongs. The management server 103 also manages data divided for each tenant. When a user belonging to a tenant accesses the management server 103, the management server 103 allows access to data of the tenant to which the user belongs. Although an example in which the management server 103 is constructed as a single server is described in this embodiment, the functional configuration of the management server may be arranged separately on a plurality of management servers. [Hardware configuration]

[0015] Fig. 2 shows a diagram illustrating example hardware configurations of the host computers 101 and 102 and the management server 103. Each of the host computers 101 and 102 includes a CPU 201, a ROM 202, a RAM 203, a KBDC 205, a DISPC 206, a DKC 207, a NIC 208, a KBD 209, a DISPLAY 210, and an HD 211, where CPU is an abbreviation for central processing unit, RAM is an abbreviation for random access memory, ROM is an abbreviation for read-only memory, and HDD is an abbreviation for hard disk drive.

[0016] The CPU 201 executes software stored in the ROM 202 or the hard disk 211 serving as a large-capacity storage device. The CPU 201 generally controls devices connected to a system bus 204. The RAM 203 functions as a main memory for the CPU 201, a work area, or the like. The keyboard controller 205 (KBDC) controls an instruction input from the keyboard 209 provided in the host computer 101. The display controller 206 (DISPC) controls a display on the display module 210 (DISPLAY), which is constructed, for example, by a liquid crystal display or the like. The disk controller 207 (DKC) controls the hard disk 211 (HD). The network interface card 208 (NIC) performs bidirectional data exchange with other nodes via the network 104.

[0017] Fig. 3A shows a diagram of example software configurations of the host computers 101 and 102. Each of the host computers 101 and 102 includes a web browser 301 and an HTTP communication unit 302. The web browser 301 interprets HTML data, draws a screen on the display module 201, accepts a user operation from a keyboard or the like, and then transmits a request to the HTTP communication unit 302. Upon receiving a communication request from the web browser 301, the HTTP communication unit 302 communicates with the management server 103 via an image processing device or the like and the NIC via an HTTP or HTTPS protocol to request a web page, receive web page data, or the like.

[0018] Fig. 3B shows a diagram of an example software configuration of the management server 103. The management server 103 includes an interface unit 401, a tenant / user management unit 402, an access permission management unit 403, and a device management service unit 404. The interface unit 401 communicates with the host computers 101 and 102 via the NIC 208 and the network 104. Upon receiving a web page request from a host computer via HTTP / HTTPS, the interface unit 401 determines authentication, an access permission state, or the like, and then passes HTML data.

[0019] The tenant / user management unit 402 includes a tenant management table 4021, a user management table 4022, a tenant hierarchy management table 4023, and a tenant group management table 4024. The tenant / user management unit 402 performs user authentication processing for each tenant so as to identify a tenant to which the user belongs.

[0020] The access permission management unit 403 includes an access rights management table 4031, an access permission request management table 4032, an entrustment / transfer instruction ticket management table 4033, and a tenant-to-tenant trust / delegation relationship management table 4034. The trust / delegation relationship management table manages a trust / delegation relationship between entities, that is, a trust / delegation relationship between tenants. The access permission management unit 403 receives information about requesting permission to access a client tenant from an SP tenant and manages the received information. The access permission management unit 403 also receives access permission acceptance information from a client tenant and manages the received information.The access permission management unit 403 further manages rights transfer instruction information from a service provider and checks a trust / delegation relationship for implementing a transfer of rights to execute rights transfer processing.

[0021] The facility management service unit 404 includes a tenant-specific data table 4041 and an SP tenant-specific customer management table 4042. The facility management service unit 404 provides service functions such as facility management, report generation, and the like. The tenant-specific data table 4041 and the SP tenant-specific customer management table 4042 each provide a separate table for each tenant and store data belonging to a tenant corresponding to the respective table.

[0022] For example, a table can be created for each client by setting a table name to<mandanten-id>Of course, a plurality of data tables can be provided for each data type. In this case, a plurality of tables can be provided for each client and for each data type by setting a table name to <mandanten-id>and each row on <datentabellenname>provided. As another embodiment, data from all tenants can be stored in a single table. For example, a tenant ID is stored in a column in a data table, so that each row can confirm which data belongs to which tenant. (Table configuration)

[0023] Below, configurations of the respective tables managed by the management server 103 are described with reference to the Fig. 4 to 8 described. (Client management table 4021)

[0024] The Fig. 4A to 4D show representations of the configurations of the respective tables managed by the client / user management unit 402. The Fig. The tenant management table 4021 shown in Figure 4A indicates a table for managing the tenant type. A tenant ID 501 is a column for storing an ID used to identify a tenant. A tenant type 502 is a column for storing information for determining whether a tenant is a service provider tenant or a customer tenant. An administrator ID 503 is a column for storing a tenant administrator ID. In this embodiment, when a tenant to be processed is designated, a query is made to determine a tenant ID and its administrator ID so that it can be confirmed whether or not they match and an input error can be prevented. For example, a row 511 indicates a service provider tenant whose tenant ID is "SP_US" and administrator ID is "tony." (User management table 4022)

[0025] The Fig. The user management table 4022 shown in FIG. 4B indicates a table for storing information about a user belonging to a tenant. A tenant ID 601 is a column for storing a tenant ID used to identify a tenant to which the user belongs. A user ID 602 ​​is an ID for identifying a user. A unique ID is used at least for each tenant. A password 603 is a column for storing a password that is input together with a user ID when a user logs in to the management system of this embodiment. For example, a row 611 indicates a user belonging to a tenant SP_US, whose user ID and password are tony and xxxxxx, respectively. (Client hierarchy management table 4023)

[0026] The Fig. The tenant hierarchy management table 4023 shown in Figure 4C indicates a table for storing a hierarchical relationship between tenants. A tenant specified by an upper tenant 701 is positioned at a higher level than a tenant specified by a lower tenant 702. Fig. 8A and Fig. 8B show representations of tenant hierarchy structure information between existing facilities and between service provider facilities, which are created by the Fig. 4C shown tenant hierarchy management table 4023. A tenant ID is shown in a rectangular frame, and an arrow indicates a hierarchical structure from an upper tenant to a lower tenant. (Tenant group management table 4024)

[0027] The Fig. The tenant group management table 4024 shown in Figure 4D specifies a table for storing a service provider group to which a service provider tenant belongs. A tenant specified by a tenant ID 801 belongs to a service provider group specified by a membership group 802.

[0028] The Fig. 5A and Fig. 5B show diagrams of the respective tables managed by the access permission management unit 403. (Access rights management table 4031)

[0029] The Fig. The access rights management table 4031 shown in FIG. 5A indicates a table for storing access rights for a user tenant held by a holder tenant who owns resources such as data. Holder tenant 901 is a column for storing a tenant ID of a tenant who owns resources such as data. User tenant 902 is a column for storing an ID of a tenant who has access rights to a tenant specified by holder tenant 901.

[0030] A permitted right 903 is a column for storing the type of access rights to a user tenant held by a holder tenant to which resources such as data belong. If there are a plurality of access rights, the access rights management table 4031 stores a plurality of access rights for each data type. If a holder tenant has access rights to a plurality of organized data types, the access rights management table 403 may also store a right set name indicating a set of access rights to the plurality of data. For example, a right to count the number of scans, a report generation right, a continuous report generation right, and the like can be integrally configured as a plurality of data types by setting a right set name 38 to <abtastinformationen>be saved. (Access permission request management table 4032)

[0031] The Fig. The access permission request management table 4032 shown in FIG. 5B indicates a table for storing a tenant who owns resources such as data and a right content to be requested by a tenant who makes an access permission request to the tenant. An owner tenant 1001 is a column for storing a tenant ID of a tenant who owns resources such as data. A permission request / user tenant 1002 is a column for storing an ID of a tenant who requests access rights from a tenant specified by the owner tenant 1003. An access permission request 1003 is a column for indicating that the permission request / user tenant 1002 requests access rights to what type of data. If there is a large amount of data or a large amount of right sets to be accessed, the access permission management unit 403 stores many types of these data or right sets.For example, a row 1011 indicates that the SP_US serving as the service provider tenant requests data services for a customer tenant ABC_corp to transfer access rights that include a facility management right, a meter / report generation right, and an end-to-end report generation right. (Entrustment / Transfer Instruction Ticket Management Table 4033)

[0032] The Fig. The entrustment / transfer instruction ticket management table 4033 shown in FIG. 6A is a table for storing information regarding a service entrustment instruction or a rights transfer device. For example, the entrustment / transfer instruction ticket management table 4033 manages trust relationship information between service providing devices serving as service providers and trust relationship information between a customer tenant and a service provider. A ticket number 1101 is a management number for uniquely identifying an entrustment / transfer instruction ticket. An instructor 1102 indicates a tenant who provides an instruction for a transfer of access rights. A holder 1103 indicates a tenant who transfers access rights to a user tenant. User 1104 indicates a tenant who can access tenant data belonging to the holder 1103 upon receiving access rights.A target right 1105 indicates a type of access right whose transfer is instructed, for example, by the holder 1103 to the user 1104. A pass expression 1106 stores a pass expression that is set when a user of a tenant specified by the instructor 1102 provides a transfer instruction. The stored pass expression is a pass expression to be entered when a user of a tenant specified by the user 1104 accepts a transfer of rights.

[0033] An owner-to-instructor trust / delegation relationship 1107, an owner-to-user trust / delegation relationship 1108, and a user-to-instructor trust relationship 1109 each indicate a verification result regarding each trust / delegation relationship obtained by the transfer determination described below. The value "OK" indicates that the respective conditions satisfy a transfer condition, while the value "NG" indicates that an acceptance operation by a tenant user is required because the transfer condition is not satisfied. An entrustment mediation tenant 1110 indicates that an entrustment instruction has been provided via the entrustment mediation tenant 1110 without directly providing a service entrustment instruction from an instructor tenant to a user tenant.As described above, the entrustment / transfer instruction ticket management table 4033 indicates that the instructor 1102 instructs the owner 1103 to transfer access rights to owner tenant data to a tenant specified by the user 1104. The entrustment / transfer instruction ticket management table 4033 also indicates that the instructor 1102 instructs the user 1104 to access data of a tenant specified by the owner 1103 in order to provide services such as facility management to the owner 1103. (Tenant-to-Tenant Trust / Delegation Relationship Management Table 4034)

[0034] The Fig. 6B, tenant-to-tenant trust / delegation relationship management table 4034 indicates a table for storing a trust / delegation relationship between tenants. A tenant specified by a subject 1201 trusts a tenant specified by a target 1203 or delegates a transfer of access rights to a tenant specified by a target 1203. Either trust or delegation is specified in trust / delegation 1202.

[0035] The access permission management unit 403 refers to a trust / delegation relationship when determining whether or not to execute a transfer of access rights instructed by an instructor. Specifically, when a holder client trusts an instructor client or a user client, the access permission management unit 403 determines that the holder client can accept a transfer instruction to execute a transfer of rights. When a user client trusts an instructor client, the access permission management unit 403 determines that the user client can accept a transfer instruction given by the instructor, and services can be provided after accepting a transfer of access rights.When an owner client delegates access rights to an instruction client, the access permission management unit 403 determines that a transfer of access rights may be executed even if the owner client does not trust the user client.

[0036] If in this embodiment a client 2 exists directly above a client 1, where the client belongs to the same group in the client hierarchy management table 4023 ( Fig. 4C) and the client group management table 4024 ( Fig. 4D), it is defined that Client 1 is in a "direct relationship" with Client 2. If Client 1 has a relationship of trust or delegation with Client 2 in the Fig. In the tenant-to-tenant trust / delegation relationship management table shown in Figure 6B, it is also defined that tenant 1 has a "direct relationship" with tenant 2. If tenant 2, who has a direct relationship with tenant 1, has a direct relationship with a tenant 3, it is defined that tenant 1 has an "indirect relationship" with tenant 3, but not vice versa, because the upper and lower levels of a hierarchical structure of tenants and a trust / delegation relationship have directionality. For example, it is noted that tenant 3 does not have an "indirect relationship" with tenant 1. To determine the presence or absence of a trust relationship when determining the execution of a transfer of rights, it is determined, based on the definitions above, that a trust relationship exists even in the case of an "indirect relationship."

[0037] The Fig. 7A and Fig. 7B show diagrams of configurations of the respective tables managed by the facility management service unit 404. (Client-specific data table)

[0038] In this embodiment, a plurality of data types for a plurality of clients can be configured by setting a table name to <mandanten-id>The data stored in Fig. The tenant-specific data table 4041 shown in Figure 7A is a table that manages device information managed for each tenant. The tenant-specific data table 4041 is a table with the table name ABC_JP.device_info and manages device information belonging to the tenant ABC_JP.

[0039] A device ID 1301 is an ID for identifying a device. A serial number or a MAC address is set as a device ID 1301. An IP address 1302 is an IP address set as an attribute of a device. An installation location 1301 represents installation location information set as an attribute of a device. Although the number of the data column is 3, as shown in Fig. 7A, any number of columns or data type information may be stored. In another embodiment, there is a method for storing data for all tenants in a single table with a tenant ID column. For example, a tenant ID column may be set via a facility ID to set a facility ID such as ABC_JP. It may be clarified which tenant owns data for a facility in each row. Alternatively, it may be clarified which tenant owns which data for a facility in each row by adding a tenant ID to a facility ID indicated by facility ID 1301.

[0040] The Fig. The SP tenant-specific customer management table 4042 shown in Figure 7B is a table that manages a service status for a customer tenant that is managed for each service provider tenant. Fig. 7B shows a representation of a sample customer management table managed by the service provider SP_US. A customer tenant ID 3601 stores a customer tenant ID managed by the service provider SP_US for provisioning services. A service status 3602 stores "Provisioning" if a customer tenant of the eligible row allows access to the service provider SP_US, while the service status 3602 stores "Not Yet Started" if a customer tenant in the eligible row does not allow access to the service provider SP_US. (processing flow)

[0041] The processing operations performed by the host computers 101 and 102 and the management server 103 are described below. (User authorization processing)

[0042] Fig. Figure 9 shows a flowchart of the user authentication processing flow for a user using the management system of this embodiment. A customer tenant user and an SP tenant user perform authentication processing as shown in Fig. 9. First, a user of the host computer 101 or 102 uses the web browser 301 to determine the URL of the management server 103. Then, the web browser 301 transmits a screen display request to the management server 103 specified by the URL via the network 104. When the interface unit 401 receives the request, the management server 103 checks session information via cookie information or the like to determine whether the request has already been authenticated or not. If the request has not yet been authenticated, the Fig. 9 shown user authentication processing is performed.

[0043] In step S1501, the management server 103 starts user authentication processing. In step S1509, the interface unit 401 generates HTML data indicating a login screen and transmits the HTML data to a host computer via a network. In the host computer, the HTTP communication unit 302 receives the HTML data and parses the HTML data using the web browser 301 to display a login screen. In step S1503, the user enters their user ID, a password, and a tenant ID on the login screen. The entered information is transmitted to the management server 103 via the HTTP communication unit 302.

[0044] In step S1504, the interface unit 501 provided in the management server transmits the received user ID, password, and tenant ID to the tenant / user management unit 402. Having received the user ID, password, and tenant ID, the tenant / user management unit 402 refers to the user management table 4022. The tenant / user management unit 402 checks whether or not there is a user matching the user ID, password, and tenant ID. If there is a matching user, the tenant / user management unit 402 determines that the user is a legitimate user.

[0045] In step S1505, if the client / user management unit 402 determines in step S1504 that the user is a legitimate user, processing proceeds to step S1507. Otherwise, processing proceeds to step S1506, and the client / user management unit 402 determines that authentication has failed and notifies the interface unit 401 of the authentication failure. In step S1506, the client / user management unit 402 notifies the interface unit 401 of the authentication failure. The interface unit 401 generates HTML data for reporting an interface login failure and transmits the HTML data to the host computer. User authentication processing then ends.

[0046] In step 51507, the tenant / user management unit 402 notifies the interface unit 401 of successful authentication. The interface unit 401 sets the user ID, the tenant ID to which the user belongs, and the tenant type in session information. At this time, role information associated with an authenticated user may also be set in the HTTP header. The interface unit 401 further generates HTML data representing a web page requested from a host computer based on session information and transmits the HTML data to the host computer. Unless otherwise specified in the web page, the interface unit 401 generates HTML data of the home page according to the tenant type and transmits the HTML data to the host computer.

[0047] When a user of a service provider tenant logs in, a Fig. 10A is displayed. Reference numeral 1601 is a link to a customer client registration screen. When a link is selected by a mouse pointer or the like, the SP home page 1600 screen goes to the screen shown in Fig. 11A. Reference numeral 1602 is a link to a facility management service customer management screen. If a link is selected by a mouse pointer or the like, the screen goes to the screen shown in Fig. 12A. Reference numeral 1603 is a link to a facility management service entrustment management screen. If a link is selected by a mouse pointer or the like, the screen goes to the Fig. 13A. Reference numeral 1604 is a region in which a login user name is displayed, which displays a home screen. Reference numeral 1605 is a link to a home screen. When the link is selected by a mouse pointer or the like, the screen goes to the Fig. 10A. Reference numerals 1604 and 1605 are controls commonly displayed on other screens, and so their description is omitted here.

[0048] When a customer client user logs in, a Fig. 10B is displayed. Reference numeral 2001 is a link to a client client user management screen. If the link is selected by a mouse pointer or the like, the screen transitions to the user management screen. Although not shown, the user management screen is a screen that can add, modify, and delete a client user. On the user management screen, a user can be added or modified by specifying their user ID and password. User information is stored in the Fig. 4B. Reference numeral 2002 is a link to a report retrieval screen. If the link is selected by a mouse pointer or the like, the screen transitions to the report retrieval screen. The report retrieval screen is a screen on which a report generated by a service provider to provide services to a customer can be downloaded. Reference numeral 2003 is a link to a provisioning service review screen. Which service provider provides which type of service to a customer displaying the provisioning service review screen is shown on the provisioning service review screen. On the provisioning service review screen, the owner tenant 901 receives a row matching the tenant ID of the customer displaying the provisioning service review screen, from which Fig. 5A, and the user tenant 902 and the permitted right 903 are displayed.

[0049] In the first embodiment, the processing flow for implementing access permission and service entrustment is described using an example of a first use case. Assume that SP_US of the service provider tenant (hereinafter referred to as SP tenant), which represents the first service provider entity, has entered into a facility management service contract with the customer ABC_Corp group. SP_US needs to generate an end-to-end report for the entire ABC_Corp group to provide it to ABC_Corp. ABC_JP exists subordinate to ABC_Corp, but SP_US cannot directly provide services to ABC_JP. Thus, SP_US wishes to entrust facility management and report generation (end-to-end report generation for ABC_JP) services to the service provider SP_JP, which represents the second service provider entity.

[0050] Fig. 17A shows a diagram of the processing flow performed until the user "tony" of the SP client SP_US obtains access permission by creating the customer clients ABC_Corp and ABC_JP using the management server 103. A rectangle represents a client, and an arrow represents an operation. The starting point of an arrow represents a client performing an operation, the end point of an arrow represents a client to be processed, and a text box and numbered content represent the order of operations and an operation content. Reference numeral 1401 denotes the SP client SP_US, reference numeral 1410 denotes the customer client ABC_Corp, and reference numeral 1412 denotes the customer client ABC_JP.

[0051] First, in step S1, the user "tony" of SP_US creates the customer tenant ABC_Corp and registers ABC_Corp in the management server 103, while simultaneously performing an access permission request. Next, in step S2, the user "tony" of SP_US creates the customer tenant ABC_JP and registers ABC_JP in the management server 103, while simultaneously performing an access permission request. In step S3, the user admin of ABC_Corp approves the access permission request from SP_US via the management server 103. In step S4-1, the user "suzuki" of ABC_JP approves the access permission request from SP_US. In step S4-2, the user "suzuki" of ABC_JP performs access permission processing for ABC_Corp.

[0052] Specific processing from the creation of a customer client (ABC_JP) by the user "tony" of SP_US to the performance of an access permission request to the management server 103 in step S2 will be described below. (Customer client registration processing)

[0053] If the user "tony" of SP_US accesses the management server 103 from a host computer 1 and performs a login operation, the Fig. 10A is displayed. If the user "tony" selects a link to the client client registration 1601 to register a client client, the home screen 1600 goes to a client client registration screen (reference numeral 1710 in Fig. 11A).

[0054] The Fig. 11A and Fig. 11B shows diagrams of example client client registration screens. To create a client client (ABC_JP), the user "tony" specifies the user ID 1711 of the client client administrator, the password 1712 of the client client administrator, and the ID 1713 of the client client at a higher level in the client client hierarchy. When these pieces of information are input and a [Register] button 1714 is pressed, client creation request information is set in the HTTP request, and the HTTP request is transmitted to the management server 103. The interface unit 401 receives the HTTP request and checks the input information. If there is no problem, the management server 103 transmits a client creation request to the client / user management unit 402.The tenant / user management unit 402 outputs a unique tenant ID and registers a record based on the information entered in the tenant management table 4021, the user management table 4022, and the tenant hierarchy management table 4023.

[0055] After completion of the registration processing, the output client ID and other information are transferred to the interface unit 401. The interface unit 401 generates HTML data of the customer client registration result screen 1720 ( Fig. 11B) and transmits the HTML data to the web browser 301 of the host computer 1 for display. The registered client ID 1721, the administrator user ID 1722, and the upper customer client ID 1723 are displayed on the customer client registration result screen 1720. In the example, "ABC_JP" is shown as an example of a client ID for ease of understanding, however, the description format is not particularly limited.

[0056] As a result of the ABC_corp customer client registration in step S1, a row 518 in the Fig. 4A and a row 613 in the client management table shown in Fig. 4B. As a result of the ABC_JP customer client registration in step S2, a row 520 is created in the Fig. 4A and a row 614 in the client management table shown in Fig. 4B shown user management table. In the Fig. 11A and Fig. In the examples shown in Figure 11B, ABC_JP is created as a subtenant of ABC_Corp, and suzuki is designated as the user ID of the administrator of the created tenant.

[0057] Next, a customer registration request and access permission request to be submitted to the management server 103 are described. The user "tony" of the service provider SP_US returns to the Fig. 10A to select a link to the customer management 1602. Then the screen goes to a Fig. 12A. A registration button 1801 on the customer management screen 1800 is a button for performing a customer registration process for registering customers on the management server 103. Upon pressing the registration button 1801, the screen advances to a customer registration screen 1900 ( Fig. 12B). A deregistration button 1802 is a button for deregistering a customer client selected by a radio button 1803 on the customer list. Further components are described below.

[0058] The SP user designates a customer intended for a facility management service on the customer registration screen 1900 to issue an access permission request. The ID of a customer client to be registered is designated in a client ID 1901, and the user ID of the administrator of the customer client to be registered is designated in an administrator user ID 1902. It is considered that a customer client ID alone can lead to the registration of an incorrect customer client due to erroneous input. Thus, entering the administrator user ID 1902 prevents the occurrence of an input error. Fig. In the examples shown in Figure 12B, an attempt is made to register a request to allow access to the customer tenant ABC_JP.

[0059] When the SP user presses a send button 1903, an access permission request including an SP tenant ID, a customer tenant ID, and an administrator user ID is transmitted as an HTTP request to the management server 103. Upon receiving the access permission request, the management server 103 transmits the access permission request to the facility management service unit 404. Upon receiving a customer registration request, the facility management service unit 404 transmits the customer tenant ID and the administrator user ID to the tenant / user management unit 402 to check whether there is a tenant matching two pieces of information. Here, the tenant / user management unit 402 confirms that a tenant matching a record 614 is already registered in the user management table 4022.The facility management service unit 404 transmits an access permission request registration request including the SP tenant ID (SP_US), customer tenant ID (ABC_JP), and a predetermined permitted right to the access permission management unit 403.

[0060] The access permission management unit 403 adds a record 1012 to the access permission request management table 4032 ( Fig. 5B). Specifically, the access permission management unit 403 sets ABC_JP for the owner client 1001 and SP_US for the permission request / user client 1002 in the access permission request management table 4032. The access permission management unit 403 also sets a facility management right, a count / report generation right, and a continuous report generation right for the access permission request 1003. Then, the facility management service unit 404 adds a record 3614 to the SP client-specific customer management table 4042 ( Fig. 7B). Specifically, the access permission management unit 403 sets ABC_JP in the customer tenant ID 3601 and "not yet started" in the service status 3602. (Customer Management Screen 1800 (Fig. 12A))

[0061] Below, customer client information is displayed on the customer management screen 1800 ( Fig. 12A). A list of customer tenants to which a tenant SP_US, to which the login user belongs, provides services or submits an access permission request is displayed on the customer management screen 1800. The customer management screen 1800 is generated by referring to the SP-tenant-specific customer management table 4042 of a tenant (SP_US) to which the login user belongs.

[0062] A customer tenant ID 1804 (the customer tenant ID 3601 in the SP tenant-specific customer management table 4042) and a service status 1806 (the service status 3602 in the SP tenant-specific customer management table 4042) are displayed in the customer list. The total number of registered facilities, obtained from the list of managed facilities in the tenant-specific data table 4041 (not shown), is displayed in a facility count 1807.

[0063] An operation selection button 1810 is a button provided for each customer client on the customer list. When the SP user presses the button, a customer operation menu 1811 for specifying an operation for the customer client is displayed in the relevant column. A menu is displayed in the customer operation menu 1811 depending on the rights permitted for the customer client for which the operation selection button 1810 was pressed, for the service provider client to which the login user belongs. The permitted rights are determined from the permitted right 903 in the access rights management table ( Fig. 5A) and menus related to the permitted rights are displayed.

[0064] In the Fig. In the examples shown in FIG. 12A, the user "tony" of SP_US logs in, and a screen is displayed on the host computer 1, and the customer operation menu 1811 for the customer tenant ABC_US is displayed on the screen. Menus associated with a facility management right, a count / report generation right, and a continuous report generation right permitted by the customer ABC_US are displayed in the customer operation menu 1811. A facility management 1812, a report generation 1813, and a service entrustment request 1814 are displayed as customer operation menus. If the facility management 1812 and the report generation 1813 are selected, the screen advances to a screen for using service functions provided by the facility management service unit 404 for the selected customer tenant, but this description is omitted.

[0065] Next, access permission processing is performed with reference to Fig. 21, which is performed by the management server 103 regarding access rights permitted by a customer client user. The flowchart describes an example of processing performed when the user "suzuki" of the customer client ABC_JP accepts the permission of access rights. When the customer client user accesses the management server 103 from a host computer 2 and logs into the management server 103, the customer home page screen 2000 ( Fig. 10B) is displayed.

[0066] If the client user selects the menu of the service confirmation 2003, a screen transition request containing the selected menu information and the client ID to which the user belongs is transmitted to the management server 103. After the interface unit 401 sets screen transition request information in session information, the management server 103 transmits the screen transition request to the facility management service unit 404. The facility management service unit 404 calls the access permission management unit 403 to execute a Fig. 21 shown access permission acceptance processing.

[0067] In step S3101, the access permission management unit 403 obtains the access permission record 1012 in which the client client ID (ABC_JP) included in the screen transition request matches the owner client 1001 from the access permission request management table 4032. If there is no access permission record in step S3102, processing proceeds to step S3108. If there is an access permission record 1012, processing proceeds to step S3103. In step S3103, the interface unit 401 generates HTML data for displaying a Fig. 13A and transmits the HTML data to the web browser 301 of the host computer 2 via the interface unit 401.

[0068] The web browser 301 displays the permitting request / user client 1002 of the access permission record (SP_US) via the access permission client 2101 on the access permission acceptance screen 2100. The access permission request 1003 for the access permission record of the record 1012 is displayed in the access permission service and data 2102.

[0069] If there are a plurality of access permission records, a plurality of combinations may also be displayed, as shown by reference numerals 2103 and 2104. Whether or not a transfer of access rights to an entrustee for entrustment services is delegated to the SP tenant (in the example, SP_US) that made an access permission request is determined by a delegation relationship check box 2110. When the check box is set to a selected state, it indicates that a delegation relationship (acceptance of a transfer of access rights to an entrustee for entrustment services) is established with the SP tenant that made the access permission request. Pressing an (access permission) button 2105 indicates access permission acceptance, and the access permission acceptance request is transmitted to the management server 103.

[0070] If the user presses the [Allow Access] button 2105 on the web browser 301 in step S3104, the processing proceeds to step S3105. If the management server 103 receives the access permission acceptance request in step S3105, the access permission acceptance request is transmitted to the access permission management unit 403, and the access permission management unit 403 registers the accepted access rights information in the access rights management table 4031. That is, the access permission management unit 403 registers a record 912 in the access rights management table 4031. Next, the access permission management unit 403 deletes a record (the record 1012 in Fig. 5B) relating to the corresponding customer tenant from the access permission request management table 4032. In step S3107, the access permission management unit 403 changes the service status 3602 of the SP tenant-specific customer management table 4042 for the corresponding SP tenant of the permitting request / user tenant 1002 to "provide." Here, the service status 3602 of the record 3614 is changed to "provide."

[0071] In step S3108, the access permission management unit 403 adds a record 1212 to the client-to-client trust / delegation relationship management table 4034. The access permission management unit 403 provides the client client ID (ABC_JP) to which the serving user belongs in the Fig. 6B. The access permission management unit 403 also sets the SP tenant ID (SP_US) specified by the permitting request / user tenant 1002 in the target 1203. If the delegation relationship check box 2110 has been selected, the value "Delegation" is set in Trust / Delegation 1202, while if the delegation relationship check box 2110 has not been selected, the value "Trust" is set in Trust / Delegation 1202. The added record indicates that the tenant in the subject 1201 trusts the tenant in the target 1203 or delegates rights specified by Trust / Delegation 1202 to the tenant in the target 1203.

[0072] After completion of these processing operations, the facility management service unit 404 transmits an access permission processing result screen via the interface unit 401. The above describes the processing flow that is performed until the Fig. 17A, the SP client SP_US receives access permission by registering the customer clients ABC_corp and ABC_JP in the management server 103.

[0073] Fig. Figure 17B shows a representation of the processing flow that is performed until ABC_JP accepts a transfer of access rights to SP_JP after the SP tenant SP_US instructs the SP tenant SP_JP to entrust services for the customer tenant ABC_JP. The flow is executed by providing an entrustment and transfer instruction by SP_US, which represents the third party. Fig. 17B, ​​the SP client SP_JP 1402 is also added to the Fig. Added to the clients shown in 17A.

[0074] First, in step S5-1, user "tony" of SP_US performs an entrustment operation to entrust the SP client SP_JP with services for the client client ABC_JP. On the other hand, in step S5-2, user "tony" instructs ABC_JP to transfer access rights to SP_JP. Then, in step S6, user "kato" of SP_JP performs an entrustment acceptance operation. Next, in step S7, user "suzuki" of the client client ABC_JP performs an acceptance operation to accept access rights for SP_JP. As a result of these operations, if a transfer condition for transferring access rights is satisfied, an access rights transfer execution instruction is provided in step S8, and processing for transferring access rights from ABC_JP to SP_JP is executed in step S9.

[0075] The process is described in more detail below. An entrustment process performed by the user "tony" of SP_US in step S5-1 is described with reference to the flowchart in Fig. 22, Fig. 10A, Fig. 14A and Fig. 15. If the user "tony" of SP_US accesses the management server 103 from the host computer 1 using a web browser and logs into the management server 103, the service provider home page 1600 is displayed ( Fig. 10A). If a link 1603 to an entrustment management screen is selected for an entrustment process, a service entrustment management screen 2200 ( Fig. 14A) is displayed.

[0076] The item "customer list to be entrusted" or "entrusted customer list" can be selected at a customer list selection control 2201 on the service entrustment management screen 2200. The screen is switched upon pressing an "Apply" button 2202. If the item "customer list to be entrusted" is selected, the following information can be displayed and the following operations can be performed. If the user "tony" of SP_US presses an "Add Service Entrustment" button 2217, the screen goes to a service entrustment setting screen 2300 ( Fig. 15). If the item "entrusted customer list" is selected, the screen will be converted into a Fig. 14B. A new service entrustment agent request can be added by an "Add Service Entrustment Agent" button 2218. The details are described below.

[0077] The Fig. The customer list shown in FIG. 14A is generated with respect to the entrustment / transfer instruction ticket management table 4033. The instructor 1102 obtains a record corresponding to a tenant ID to which the login user belongs and displays a record in a row in a customer list. Reference numeral 2211 denotes a customer tenant ID to be entrusted, reference numeral 2212 denotes the SP tenant ID of the entrustee, reference numeral 2213 denotes an entrustment agent SP tenant ID, and reference numeral 2214 denotes whether or not a transfer of access rights by accepting the service entrustment has already been performed in each row. Examples of the state denoted by reference numeral 2214 include "waiting for SP acceptance," "waiting for customer acceptance," "waiting for SP and customer acceptance," and "accepted."If an "Owner-to-Instructor Trust / Delegation Relationship" 1107 in the entrustment / transfer instruction ticket management table 4033 is NG, or an "Owner-to-User Trust / Delegation Relationship" 1108 is NG, the state is "Waiting for Customer Acceptance".

[0078] If a "user-to-instructor trust relationship" 1109 is NG, the status is "waiting for SP acceptance." If both "waiting for customer acceptance" and "waiting for SP acceptance" satisfy the display condition, the status is "waiting for SP and customer acceptance." If three trust relationships are OK, the status is "accepted." Reference numeral 2215 denotes the type of service to be entrusted. A button 2219 is a button for removing the accepted service entrustment. When the button 2219 is pressed, the transferred rights are deleted from the access rights management table along with the relevant rights transfer ticket.

[0079] If the user "tony" of SP_US presses the "Add Service Entrustment" button 2217 in step S5-1 to perform a service entrustment operation, the management server 103 executes the process shown in the flowchart in Fig. 22. First, in step S3120, the access permission management unit 403 generates HTML data of the service entrustment setting screen 2300 ( Fig. 15) and transmits the HTML data to the web browser 301.

[0080] As in Fig. As shown in Figure 15, the service entrustment setting screen 2300 includes elements such as a customer tenant ID 2301, a service provider ID 2302, an administrator user ID 2303, a passphrase 2304, a service to be entrusted 2305, and the like. The service entrustment setting screen 2300 also includes elements such as a setting button 2306 and a clear button 2307.

[0081] An SP Provider ID of the entrustee 2302 can be entered directly by typing a tenant ID via a keyboard, but can also be selected from a drop-down list. The SP tenant ID displayed in the drop-down list is a tenant that has an additional trust relationship with tenants that are at a lower level in the tenant hierarchy than a tenant to which the login user belongs and belong to the same group.

[0082] The tenant hierarchy is obtained by referring to the tenant hierarchy management table 4023. Whether the tenants belong to the same group or not can be determined by referring to the tenant group management table 4024. Whether the additional trust relationship has been established between tenants or not is obtained by referring to the tenant-to-tenant trust / delegation relationship management table 4034.

[0083] The pass expression 2304 is entered to ensure that the entrustee's SP tenant must be a legitimate user. The pass expression is reported to the user of the entrustee's SP tenant outside the system and entered during an entrustment acceptance process, and incorrect input of a entrustee's tenant can be avoided. Then, the entrusted service 2305 is selected. The entrustment service is a service provided by the entrusting SP tenant to a customer to be entrusted. It further indicates that a transfer of access rights to required data is required to provide the service.

[0084] In step S3202, the SP_US user "tony" assigns "ABC_JP" to the customer tenant ID 2301, which is the target for service entrustment, on the service entrustment setting screen 2300. The user "tony" also enters "SP_JP" into the SP tenant ID of the entrustee 2302, "kato" into the administrator user ID 2303, and "1111111111" into the pass-through printout 2304. When the SP_US user "tony" presses the setting key 2306, the flow proceeds to step S3203. In step S3203, the access permission management unit 403 verifies the SP tenant ID of the entrustee (SP_JP) and the administrator user ID (kato) in the tenant management table 4021 to check whether the administrator user ID of the SP tenant of the entrustee has been correctly determined. If the administrator user ID of the SP tenant of the entrustee is OK, the flow proceeds to step S3204 and processing continues.If the administrator user ID of the entrustee's SP tenant is NG, processing is interrupted as faulty.

[0085] In step S3204, the access permission management unit 403 registers a transfer instruction record in the entrustment / transfer instruction ticket management table 4033. In the Fig. 15 shown input example, a Fig. 6A is added to the transfer instruction ticket management table 4033. The tenant ID (SP_US) to which the login user who provided an entrustment instruction belongs is set in the instructor 1102. The customer tenant ID 2301 (ABC_JP) to be entrusted is set in the owner 1103. The tenant ID of the entrustee 2302 (SP_JP) is set in the user 1104. The input pass expression 2304 is set in the pass expression 1106. The right name representing a service designated by the service to be entrusted 2305 is set in the transfer target right 1105. At this time, zero is set in each column 1107 to 1109, and the columns 1107 to 1109 are set in the Fig. The following transmission determination processing shown in Figure 25 is set.

[0086] First, the transmission determination condition is described with reference to a schematic diagram. Fig. 19A shows a schematic representation of a service entrustment instruction and a rights transfer instruction. Reference numeral 2601 denotes an instructing client, which indicates a client that has provided an instruction for a service entrustment for a customer client. The instructing client 2601 corresponds to the SP client SP_US in the first embodiment. Reference numeral 2602 denotes an owner client, which indicates a customer client to whom data belongs. The owner client 2601 is a client that attempts to transfer access rights to data to the user client 2603 upon receiving a transfer instruction from the instructing client 2601. The owner client 2602 corresponds to the customer client ABC_JP in the first embodiment. Reference numeral 2603 denotes a user client that attempts to provide services to the owner client upon receiving a service entrustment instruction from the instructing client 2601.Since the user tenant 2603 needs to access data to provide services, the user tenant 2603 is a tenant that has access rights to data via a transfer of access rights granted by the owner tenant 2602. The user tenant 2603 corresponds to the SP tenant SP_JP in the first embodiment.

[0087] The instruction client 2601 provides an instruction to entrust services for the owner client 2602 to the user client 2603 (2612). At the same time, the instruction client 2601 instructs the owner client 2602 to transfer access rights to data belonging to the owner client 2602 to the user client 2603 (authorizing the user client 2603 to access data) (2611).

[0088] In this embodiment, a transfer of access rights to data belonging to the owner client 2602 is instructed by a client different from the owner client 2603, that is, a third party. A transfer of access rights need not necessarily be performed even if the owner client 2602 can trust the user client 2603 to which access rights for data are transferred. The owner client 2602 cannot execute a transfer of access rights as long as a transfer instruction has been provided by a client that can be trusted. The user client 2603 accepts (is entrusted with) the provision of services for the owner client 2602 from the instructing client 2601. Thus, the user client 2603 cannot undertake service provision as long as the user client 2603 cannot trust the instructing client 2601.

[0089] The transfer terms are in Fig. 19B. Once the illustrated three trust relationships 2621, 2622, and 2623 are established, a transfer instruction issued by the instruction client 2601 is executed. That is, the owner client 2602 trusts the instruction client 2601, as shown by reference numeral 2621, the owner client 2602 trusts the user client 2603, as shown by reference numeral 2622, and the user client 2603 trusts the instruction client 2601, as shown by reference numeral 2623.

[0090] The transfer determination conditions that are applied when the owner client 2602 delegates a transfer of access rights to the instructing client 2601 are set out in Fig. 19C. The term "delegate" refers to delegating a transfer of access rights to an instructing client in a transfer instruction given by a delegating client. If the owner client 2602 delegates a transfer of access rights to the instructing client 2601 (2631), a transfer of access rights is assumed, even if the owner client 2602 is not in a trust relationship with the user client 2603. In this case, too, the user client 2603 must, of course, trust the instructing client 2601 (2633). The following describes the case in which a service entrustment instruction is mediated by an intermediary client ( Fig. 20A and Fig. 20B).

[0091] The description returns to the Fig. 17B. When the entrustment process is completed in step S5-1, a transfer instruction ticket is registered in the transfer instruction ticket management table 4033. Then, the user "kato" of the SP client SP_JP performs an entrustment acceptance process in step S6. When the user "kato" of the SP client SP_JP logs into the management server 103 using the web browser 301 of the host computer, the Fig. 10A is displayed. If the user "kato" selects the entrustment management 1603 on the home page 1600, the Fig. 14A is displayed. When the user "kato" selects the "entrusted customer list" using the customer list selection control 2201 and presses the "Accept" button 2202, the screen shown in Fig. The screen shown in Figure 14B is displayed.

[0092] Customer client information about a customer client who has provided an entrustment instruction to the SP client SP_JP is stored on the Fig. 14B is displayed. The customer list is generated by the facility management service unit 404 by referring to the transfer instruction ticket management table 4033. The facility management service unit 404 obtains the user 1104 that matches the tenant ID to which the login user belongs. Then, the facility management service unit 404 displays the corresponding record in a row in the customer list. Here, the record 1111 is obtained in the transfer instruction ticket management table 4033.

[0093] The owner client 1103 (ABC_JP) is displayed at a customer client ID 2221 to be entrusted, which is in Fig. 14B. The instructor 1102 (SP_US) is displayed at an SP client ID of the entruster 2222. The entrustment agent client 1110 is displayed at an SP client ID of an entrustment agent 2223. Whether or not a transfer of access rights has been authorized by accepting a service entrustment in the respective row is displayed in the service entrustment acceptance status 2224. The content to be displayed is the same as in the Fig. 14A. A entrusted service 2225 indicates information about a service to be entrusted. A service entrustment acceptance operation button 2229 is a button to be displayed when the service entrustment acceptance status is "waiting for SP acceptance" or "waiting for SP / customer acceptance." When the service entrustment acceptance operation button 2229 is pressed, the entrustment acceptance processing indicated by the entrustment acceptance in step S8 is executed.

[0094] The following describes the process of entrustment acceptance processing with reference to Fig. 23, which is performed when the user "kato" of SP_JP accepts an entrustment. First, in step S3301, the access permission management unit 403 obtains the instruction record 1111 as the operation target from the transfer instruction ticket management table 4033. Then, in step S3302, the access permission management unit 403 generates HTML data of a service entrustment acceptance screen 2400 ( Fig. 16) as an entrustment screen and transmits the HTML data via the interface unit 401 to the web browser 301. The content of the instruction record is displayed on the service entrustment acceptance screen 2400 ( Fig. 16).

[0095] As in Fig. 16, the owner 1103 (ABC_JP) is displayed at a customer client ID 2401 to be entrusted. The instructor 1102 (SP_US) is displayed at an SP client ID of the entrustor 2402. The target right 1105 (facility management, count value / report generation) is displayed at a service to be entrusted 2404. Whether or not a future service entrustment will also be accepted by trusting the instructor client (SP_US) is determined by a check box 2410. When the check box 2410 is clicked, trust relationship information is added to the client-to-client trust / delegation relationship management table 4034. The user "kato" inputs a pass expression reported from an external system into a pass expression 2403 using the web browser 301 and presses an acceptance button 2411 (step 53304).

[0096] When the user "kato" inputs the pass expression into the pass expression 2403 and presses the accept button 2411, an acceptance request is transmitted from the web browser 310 to the management server 103, and the request is forwarded to the access permission management unit 403. Then, the processing proceeds to step S3305. In step S3305, the access permission management unit 403 checks whether the input pass expression matches the pass expression 1106 of the instruction record 1111. If the input pass expression does not match the pass expression 1106, the processing ends with an error. If the input pass expression matches the pass expression 1106, the processing proceeds to step S3306.

[0097] In step S3306, the access permission management unit 403 changes the "user-to-instructor trust relationship" 1109 of the record 1111 in the entrustment / delegation instruction ticket management table 4033 to OK. Then, in step S3307, the access permission management unit 403 determines whether or not trust relationship addition has been selected in the check box 2410. If trust relationship addition has been selected in the check box 2410, processing proceeds to step S3308, and a record indicating that "user" trusts "instructor" is added to the tenant-to-tenant trust / delegation relationship management table 4034. Here, a record has been added in which SP_JP has been set as the subject 1201 and SP_US has been set as the destination.

[0098] In step S3309, the access permission management unit 403 determines whether the "holder-to-instructor trust / delegation relationship" 1107, the "holder-to-user trust / delegation relationship" 1108, and the "user-to-instructor trust relationship" 1109 are each set to OK or not. If all three relationships are set to OK, the access permission management unit 403 determines that the access right entrustment condition is satisfied. Then, the processing proceeds to step S3310, and the entrustment processing is executed. If any of the three relationships is set to NG, the access right entrustment condition is not satisfied, and the processing ends without executing the entrustment processing.In the process, the "user-to-instructor trust relationship" 1109 is set to OK, but the "holder-to-instructor trust / delegation relationship" 1107 and the "holder-to-user trust / delegation relationship" 1108 are set to NG, and the entrustment processing is not executed. In step S3310, the access permission management unit 403 adds a permitted right record to the access right management table 4031 based on the entrustment instruction.

[0099] Next, processing performed by the management server when the user "suzuki" of the customer client ABC_JP accepts a transfer of access rights to SP_JP in step S7 will be described. When the user "suzuki" of the customer client ABC_JP accesses the management server 103 from the host computer 2 and logs into the management server 103, the customer home page screen 2000 ( Fig. 10B) is displayed.

[0100] When the user "suzuki" of ABC_JP selects the service confirmation 2003, a screen transition request with the selected menu information and the customer client ID to which the user belongs is transmitted to the management server 103. After the management server 103 sets screen transition request information in session information, the management server 103 transmits the screen transition request to the facility management service unit 404. Then, the access permission management unit 403 executes a Fig. 24 shown transfer instruction acceptance processing.

[0101] First, in step S3401, the access permission management unit 403 obtains the record 1111 of the corresponding customer from the entrustment / transfer instruction ticket table. Next, in step S3402, it is determined whether or not there is an instruction record, and either "holder-to-instructor trust / delegation relationship" or "holder-to-user trust / delegation relationship" is set to NG. If NO is determined in step S3402, there is no new transfer instruction, and thus the processing ends. If YES is determined in step S3404, the processing proceeds to step S3403. In the flow, the "user-to-instructor trust relationship" 1109 is set to OK, but the "owner-to-instructor trust / delegation relationship" 1107 and the "owner-to-user trust / delegation relationship" 1108 are set to NG, and the processing proceeds to step 53403.In step 53403, the access permission management unit 403 generates HTML data of an access permission acceptance screen 3500 (. Fig. 13B) as a transmission screen and transmits the HTML data to the web browser 301 for display.

[0102] The contents of the instruction record are displayed on the access permission acceptance screen 3500. The instructor 1102 is displayed on an access permission instruction client 3501, the user 1104 is displayed on an access permission client 3502, and the target right 1105 is displayed on the access permission service and data 3503. When the user "suzuki" of ABC_JP presses a "Permit Access" button 3511 on the web browser 301, a request for transmission instruction acceptance processing by the client is transmitted to the management server 103 via the web browser (step 53404).

[0103] Next, in step S3405, the access permission management unit 403 changes the candidate rows, which are the "holder-to-instructor trust / delegation relationship" 1107 and the "holder-to-user trust / delegation relationship" 1108 in the entrustment / transfer instruction ticket management table 4033, to OK. In step S3406, the access permission management unit 403 adds a record to the tenant-to-tenant trust / delegation relationship management table 4034, indicating that the "holder ABC_JP" trusts the "user SP_JP" and the "instructor SP_US."

[0104] In step S3407, the access permission management unit 403 determines whether the "holder-to-instructor trust / delegation relationship" 1107, the "holder-to-user trust / delegation relationship" 1108, and the "user-to-instructor trust relationship" 1109 are each set to OK or not. If all three relationships are set to OK, the access permission management unit 403 determines that the access rights transfer condition is satisfied. Then, the processing proceeds to step S3408, and access rights transfer processing is executed. If any of the three relationships is set to NG, the access rights transfer condition is not satisfied, and the processing ends without executing the transfer processing. In the flow, the transfer condition is satisfied, and thus, in step S3408, the access permission management unit 403 adds a Fig. 5A to the access rights management table 4031 based on the transfer instruction.

[0105] Next, the flow of transmission determination processing performed by the management server 103 will be explained with reference to Fig. 25 and Fig. 26. If the user "tony" sends an instruction to execute a rights transfer in the Fig. 17B, ​​the management server 103 executes the transfer determination processing described below. In step S2901, the access permission management unit 403 starts the transfer determination processing. The access permission management unit 403 executes the transfer determination processing by referring to the corresponding record in the entrustment / transfer instruction ticket management table 4033 and the other tables.

[0106] The following describes the processing using an instruction ticket in the Fig. 6A. In step S2902, the access permission management unit 403 determines whether the client "User" 1104 (SP_JP) can trust the client "Instructor" 1102 (SP_US) or not. Trust / delegation relationship determination processing is performed based on one of the Fig. 26A or Fig. 26B. Which process is used is selected by the tenant types 402 of the subject tenant and the target tenant. In this example, the subject tenant is the user tenant SP_JP, and its tenant type is "Service Provider." The target tenant is the instructor tenant SP_US, and its tenant type is "Service Provider." Thus, the trust / delegation relationship determination processing is performed using the Fig. 26A shown flowchart.

[0107] The following describes a processing operation to determine whether a relationship of trust is established between service providers, which is established by the Fig. 26A. In step S2821, the access permission management unit 403 starts processing to determine whether or not a trust relationship is established between service providers. For the description, it is assumed that the subject SP A is SP_JP and the destination SP B is SP_US. In step S2822, the access permission management unit 403 determines whether a direct trust relationship has already been established between SP_JP and SP_US. If there is a row in the tenant-to-tenant trust / delegation relationship management table 4034 in which the subject 1201 is SP_JP and the destination 1203 is SP_US, the flow proceeds to step S2823, and the access permission management unit 403 determines that a trust relationship exists between SP A and SP B. In the process, the access permission management unit 403 adds a record in the Fig. 23, which indicates that the "user" trusts the "instructor." Thus, in step S2822, the access permission management unit 403 determines that a trust relationship exists between SP A and SP B, and the flow proceeds to step S2823. If no trust relationship exists between SP A and SP B, the flow proceeds to step S2824, and the access permission management unit 403 determines whether or not SP B is at the level immediately above SP A in the SP tenant hierarchy, and SP B and SP A belong to the same group.

[0108] The access permission management unit 403 determines whether or not there is a path to reach SP A by tracing the lower tenant 702 from the SP B belonging to the upper tenant 701, with reference to the tenant hierarchy management table 4023. The access permission management unit 403 also determines that SP A and SP B belong to the same group if the membership groups 802 to which SP A and SP B belong exist and are identical, referring to the tenant group management table 4024. If the results of all these determinations are YES, the flow proceeds to step S2823, and the access permission management unit 403 determines that a trust relationship exists between SP A and SP B. If all the determination results are NO, the flow proceeds to step S2825.

[0109] In step S2825, the access permission management unit 403 determines whether an SP tenant located at the level above SP A in the tenant hierarchy and belonging to the same group as SP A has already established a direct trust relationship with SP B. If the determination in step S2825 is YES, the flow proceeds to step S2823, and the access permission management unit 403 determines that a trust relationship exists between SP A and SP B. If the determination in step S2825 is NO, the flow proceeds to step S2826, and the access permission management unit 403 determines that no trust relationship exists between SP A and SP B.

[0110] If the access permission management unit 403 determines in step S2902 in Fig. 25, that the client "user" 1104 can trust the client "instructor" 1102, the flow proceeds to step S2903. In the flow, the access permission management unit 403 determines that a trust relationship can be established between the client "user" 1104 and the client "instructor" 1102, and the flow proceeds to step S2903. Then, the "user-to-instructor trust relationship" 1107 is set to OK.

[0111] If the client "instructor" 1102 cannot trust the client "user" 1104, the flow proceeds to step S2904. In step S2904, there is a client "intermediary" (the entrusting intermediary client 1110) that mediates a transmission instruction, and the access permission management unit 403 determines whether or not the "user" can trust the "intermediary" and whether or not the "intermediary" can trust the "instructor."

[0112] If the result in step S2904 is YES, the flow proceeds to step S2903, while if the result in step S2904 is NO, the flow proceeds to step S2905. In step S2905, the "User-to-Instructor Trust Relationship" 1109 is set to NG.

[0113] In step S2906, the access permission management unit 403 determines whether the client "owner" trusts the "instructor" or not, or delegates a transfer of access rights to the "instructor". In the process, the client type of the client "owner" ABC_JP is a customer, and the client type of the client "instructor" SP_US is a service provider. Thus, the access permission management unit 403 makes a determination according to the Fig. 26B shown trust determination process.

[0114] The following describes the process of a customer-to-service provider trust agreement, which is implemented by the Fig. 26B. In step S2811, the access permission management unit 403 starts the trust determination processing. The description is based on the assumption that the subject is customer A ABC_JP and the target SP B is SP_US. In step S2812, the access permission management unit 403 determines whether a direct delegation relationship has already been established between ABC_JP and SP_US. The access permission management unit 403 determines whether customer A has a "delegation relationship" (trust / delegation 1202) with SP B, referring to the tenant-to-tenant trust / delegation relationship management table 4034. If customer A has a "delegation relationship" with SP B, the flow proceeds to step S2813, and the access permission management unit 403 determines that a delegation relationship exists between customer A and SP B.Delegation is performed by user "suzuki" of ABC_JP using the parameters defined in . Fig. 13A shown test button in the Fig. 21. Then, in step S3108, the access permission management unit 403 sets the client client ID (ABC_JP) to which the operating user belongs in the Fig. 6. The access permission management unit 403 also sets the SP tenant ID (SP_US) specified in the request permission / user tenant 1002 in the destination 1203. Thus, the access permission management unit 403 determines that a direct delegation relationship is established between the customer A and SP B, and the flow proceeds to step S2813.

[0115] If no direct delegation relationship has been established between the customer A and SP B, the flow proceeds to step S2814, and the access permission management unit 403 determines whether or not a direct trust relationship has already been established between the customer A and SP B. If the customer client does not delegate a transfer of access rights to the service provider that is a transfer instructor, transfer instruction acceptance processing performed by a customer is required, and thus the Fig. 24 is carried out. In the Fig. 24, in step S3405, the access permission management unit 403 changes the candidate rows representing "holder-to-instructor trust / delegation relationship" 1107 and "holder-to-user trust / delegation relationship" 1108 in the entrustment / transfer instruction ticket management table 4033 to OK. In this case, trust / delegation 1202 in the tenant-to-tenant trust / delegation relationship management table 4034 indicates "Trust." Then, the flow proceeds to step S2815, and the access permission management unit 403 determines that a trust relationship has already been established between the customer A and SP B. Otherwise, the flow proceeds to step S2816. In step S2816, the access permission management unit 403 determines whether or not a customer who is at a higher level than the customer A in the customer hierarchy already has a direct trust relationship with SP B.If the determination result in step S2816 is YES, the flow proceeds to step S2815, and the access permission management unit 403 determines that a trust relationship exists between the customer A and SP B. If the determination result in step S2816 is NO, the flow proceeds to step S2817, and the access permission management unit 403 determines that no trust relationship exists between the customer A and SP B.

[0116] In step S2906 in Fig. 25, the access permission management unit 403 determines that the client "owner" (ABC_JP) delegates a transfer of access rights to the "instructor" (SP_US), and the flow proceeds to step S2907. Then, the access permission management unit 403 sets the "owner-to-instructor trust / delegation relationship" 1107 and the "owner-to-user trust / delegation relationship" 1108 to OK, and the flow proceeds to step S2913. If the access permission management unit 403 determines that the client "owner" (ABC_JP) trusts the "instructor" (SP_US), the flow proceeds to step S2908. Then, only the "Owner-to-Instructor Trust / Delegation Relationship" 1107 is set to OK, and the flow proceeds to step S2910.That is, if the access permission management unit 403 determines that the tenant "owner" (ABC_JP) delegates a transfer of access rights to the "instructor" (SP_US), the processing for determining whether the "owner" can trust the "user" or not in step S2910 can be omitted. If the access permission management unit 403 determines that neither a trust relationship nor a delegation relationship exists between the tenant "owner" (ABC_JP) and the "instructor" (SP_US), the flow proceeds to step S2909, the "owner-to-instructor trust / delegation relationship" 1107 is set to NG, and the flow proceeds to step S2901.

[0117] When the flow advances to step S2910, the access permission management unit 403 determines whether the "holder" can trust the "user" or not. For example, if the access permission management unit 403 determines in step S2906 that no delegation relationship is established between the "holder" and the "instructor", the access permission management unit 403 determines whether or not a relationship has been established between the "holder" and the "instructor" using the Fig. 26B is used, since the owner client ABC_JP is a customer client and the user client SP_JP is an SP client. The access permission management unit 403 checks the Fig. 6B to determine whether or not a trust relationship exists between ABC_JP and SP_JP. If the access permission management unit 403 determines that a trust relationship exists between ABC_JP and SP_JP, the flow proceeds to step S2911, and the access permission management unit 403 sets the "holder-to-user trust / delegation relationship" 1108 to OK. If the access permission management unit 403 determines that no trust relationship exists between ABC_JP and SP_JP, the flow proceeds to step S2912, and the access permission management unit 403 sets the "holder-to-user trust / delegation relationship" 1108 to NG.

[0118] In step S2913, the access permission management unit 403 determines whether the "holder-to-instructor trust / delegation relationship" 1107, the "holder-to-user trust / delegation relationship" 1108, and the "user-to-instructor trust relationship" 1109 are set to OK. If all three relationships are set to OK, the access permission management unit 403 determines that the access rights transfer condition is satisfied. Then, the flow proceeds to step S2914, and the access rights transfer processing is executed. In the flow, the access permission management unit 403 determines that the transfer condition is satisfied. If any of the three relationships is set to NG, the access rights transfer condition is not satisfied, and the process ends without executing the transfer processing.In step S2914, the access permission management unit 403 sets ABC_JP in the owner client 901, SP_JP in the user client 902, and "facility management right" and "count value / report generation right" in the permitted right 903.

[0119] As described above, according to the management device of the invention, a service provider can entrust another service provider with services for a customer tenant, so that the customer tenant can securely transfer access rights to customer data to another service provider. <Zweites Ausführungsbeispiel>

[0120] Next, a processing flow for implementing access authorization and service entrustment is described using an example of the second use case. Assume that the SP tenant SP_US has entered into a facility management service contract with the customer ABC_Corp Group. SP_US must generate a consistent report for the entire ABC_Corp Group to make it available to ABC_Corp.

[0121] ABC_AS exists as a subordinate of ABC_Corp, but the SP tenant SP_AS already provides services for ABC_AS. Therefore, SP_US wants to provide an integrated report generation service for ABC_AS by adding ABC_AS as a subordinate of ABC_Corp.

[0122] Fig. 18A shows an illustration of the processing flow performed until the SP tenant SP_AS obtains access permission by entrusting the SP tenant SP_US with services for the customer tenant ABC_AS. Reference numeral 1401 denotes the SP tenant SP_US, reference numeral 1403 denotes the SP tenant SP_AS, reference numeral 1410 denotes the customer tenant ABC_Corp, and reference numeral 1413 denotes the customer tenant ABC_AS.

[0123] In Fig. 18A, the processing flow performed until SP_US obtains access permission by creating a client ABC_Corp and registering it in the facility management service unit, and the processing flow performed until SP_AS obtains access permission by creating an ABC_AS and registering it in the facility management service unit are omitted. The processing flow until reaching step S11 is the same as with reference to Fig. 17A.

[0124] If the SP_AS user executes an entrustment process to entrust the SP client SP_US with services for the customer client ABC_AS in step S11-1, the SP_AS user simultaneously provides an instruction for ABC_AS in step S11-2 to transfer access rights to SP_US. If SP_AS provides an entrustment / transfer instruction, a record 1114 is created in the Fig. 6A is used. That is, the target rights are facility management, count / report generation, and end-to-end report generation. Next, the user of the SP tenant SP_US performs an entrustment acceptance operation in step S12. Then, the user of the customer tenant ABC_AS accepts a transfer of access rights to SP_US in step S13. If a transfer condition for transferring access rights is satisfied as a result of these operations, an access rights transfer execution instruction is provided in step S14, and the processing for transferring the access rights from ABC_AS to SP_US is executed in step S15.

[0125] The entrustment process in step S11 is essentially the same as that in Fig. 17B, ​​but differs from step S5-2 in the following points. In the service 2305 to be entrusted on the Fig. In the service entrustment setting screen 2300 shown in Figure 15, the SP_AS user selects continuous report generation in addition to facility management and counter / report generation. That is, the entrustment process in step S11 differs from that in step S5-2 in that the SP_AS user provides an instruction to SP_US to entrust a continuous report generation rights service to ABC_AS. The entrustment acceptance process in step S12 is the same as that in Fig. 17B. A user operation for ABC_AS is unnecessary for accepting a transfer of access rights to SP_US in step S13 because the customer client ABC_AS trusts SP_AS. Therefore, the owner-to-instructor trust / delegation relationship 1107 is set to OK. Furthermore, ABC_Corp, which is higher in the customer hierarchy than ABC_AS, has already established a direct trust relationship with SP_US. This is determined as YES in step S2816, and in the Fig. 26B, it is determined that a trust relationship exists between ABC_AS and SP_US. Thus, the owner-to-user trust / delegation relationship 1108 is also determined to be OK. If the user of SP_US performs an entrustment acceptance operation in step S12, the access rights transfer condition is thus satisfied, and therefore the access rights transfer processing in steps S14 and S15 is executed. <Drittes Ausführungsbeispiel>

[0126] Next, a processing flow for implementing service entrustment through an intermediary is described using an example of the third use case. Assume that the SP client SP_US has a facility management service contract with the customer ABC_Corp group. SP_US needs to generate an end-to-end report for the entire ABC_Corp group to provide it to ABC_Corp. ABC_London exists subordinate to ABC_Corp, but SP_US cannot directly provide services to ABC_London. Thus, SP_US wants to perform service entrustment but does not know of a service provider that can provide services to ABC_London. If no service provider is determined, SP_US wants to entrust SP_London, subordinate to ABC_Corp, with services for ABC_London by providing a service entrustment intermediary instruction to SP_UK, which is a third-party service provider.

[0127] Fig. Figure 18B shows a representation of a processing flow that is performed until SP_London receives an access permission from ABC_London after the SP tenant SP_US has made a request to entrust SP tenant SP_UK with services for the customer tenant ABC_London. As in Fig. 18A omits the processing flow that is performed until SP_US has obtained an access permission from ABC_London by creating a client ABC_London.

[0128] First, in step S21, the user "tony" of SP_US makes a service entrustment brokerage request to broker the entrustment of SP_UK with services for the customer client ABC_London. The service entrustment brokerage process is started when the "Add Service Entruster" button 2216 is pressed on the Fig. 14A is pressed. The service entrustment status setting screen is essentially the same as that shown in Fig. 15, but differs from the one shown in Fig. 15 in the following points. That is, the screen for entering information for a service entrustment agent service provider tenant is displayed instead of information for an entrusted service provider tenant. Here, the user of SP_US at the customer tenant ID 2301 determines that ABC_London is to be entrusted and enters SP_UK information into information for an entrustment agent service provider. The user of SP_US creates entrustment service information and presses a setting key. Then, an instruction record 1113 is added to the entrustment / transfer instruction ticket management table. SP_US is set for the instructor 1102, ABC_London is set for the holder 1103, and null is set for the user 1104. SP_UK is further set as the entrustment agent client 1107.

[0129] When the user of SP_UK displays the Service Entrustment Management screen, a customer list is displayed in a row 2242 at the bottom of Fig. 14B. If there is a client in the entrustment agent client 1107 in the entrustment / transfer instruction ticket management table 4033 to which the user belongs, the fact that the entrustment agent has been requested is displayed in the entrustment service 2225. If the user of SP_UK presses an acceptance key 2228, the screen goes to the Fig. 16, and the user of SP_UK inputs a pass expression reported by SP_US via an external system, so that the user of SP_UK can accept the service entrustment switching request in step S22.

[0130] In step S23, the SP_UK user entrusts SP_London with services. As with a normal service entrustment, a process for entrusting SP_London with services by SP_UK is performed on the service entrustment setting screen 2300, which is accessed using the "Add Service Entrustment" button 2217 on the service entrustment management screen 2200. The SP_UK user designates ABC_London at the customer tenant ID 2301 as being entrusted and designates SP_London at the entrusted service provider tenant ID 2302. A pass expression reported by SP_US via an external system is entered into the pass expression 2304. When the setting button 2306 is pressed, the SP_London specified in the entrusted service provider tenant ID 2302 is set in the applicable row corresponding to the user 1104 in the entrustment / transfer instruction ticket management table 4033. Accordingly, the setting is executed as shown in row 1113.The state is determined as a result of executing the function defined in . Fig. 22 shown entrustment instruction processing until step S3204.

[0131] In step S24, the user of SP_London accepts the entrustment. The flowchart of the entrustment instruction acceptance processing is the same as that in Fig. 23. In step S25, the SP_US user provides a transfer instruction to transfer access rights to SP_London for ABC_London as a result of the SP_London user's acceptance entrustment. The transfer instruction acceptance processing is the same as that described in Fig. 24 shown flowchart.

[0132] A transfer provision including an intermediary for entrustment is described below with reference to a schematic diagram. Fig. 20A shows a schematic diagram illustrating a service entrustment instruction, a mediation request, and a rights transfer instruction. Reference numeral 2601 denotes an instruction client, which indicates a client that has provided an instruction (2642) for a service entrustment for a customer client. According to the third embodiment, the instructing client 2601 corresponds to the SP client SP_US. Reference numeral 2602 denotes an owner client, which indicates a customer client who is the owner of data. The owner client 2602 is a client that wishes to transfer access rights to data to the user client 2603 upon receiving a transfer instruction from the instructing client 2601. In the third embodiment, the owner client 2602 corresponds to the customer client ABC_London.

[0133] Reference numeral 2604 denotes an intermediary client that indicates a client that wishes to designate the user client as a service entruster upon receiving a service entrustment intermediation request instruction (2642) from the instructing client 2601. Reference numeral 2603 denotes a user client that wishes to provide services to the owner client upon receiving a service entrustment instruction from the intermediary client 2604.

[0134] The user client 2603 does not receive an instruction directly from the instructing client 2601. However, the user client 2603 undertakes the provision of services for the owner client 2602 from the mediator client 2604 (the user client 2603 is entrusted to do so). Thus, the user client 2603 cannot provide a service as long as the user client 2603 cannot trust the mediator client 2604. The mediator client 2604 also does not provide services for the owner client 2602, but performs a service entrustment to the user client 2603. Thus, the mediator client 2604 cannot mediate a service entrustment as long as the mediator client 2604 cannot trust the instructing client 2601.

[0135] The transfer terms are in Fig. 20B. Once the illustrated four trust relationships 2651, 2652, 2653, and 2654 are established, a rights transfer instruction given by the instructor client 2601 and the mediator client is executed. The owner client 2602 trusts the instructor client 2604 or delegates a transfer of access rights to the instructor client 2601, as shown by reference numeral 2651. The owner client 2602 trusts the user client 2603, as shown by reference numeral 2652 (which may be omitted if the owner client delegates a transfer of access rights to the instructor client). The user client 2603 trusts the mediator client 2604, as shown by reference numeral 2654. The mediator client 2604 trusts the instruction client 2601, as shown by reference numeral 2653.

[0136] Since, in the third embodiment, a trust relationship indicated by reference numeral 2651 is established between ABC_London and SP_US upon execution of an access permission acceptance, it is determined that a trust relationship exists between ABC_London and SP_US. The owner-to-instructor trust / delegation relationship 1107 is set to OK. Since there is no trust relationship indicated by reference numeral 2652, the owner-to-user trust / delegation relationship 1108 is set to NG. That is, the transfer acceptance process by the customer is required, and thus the Fig. 24 is performed. Since SP_UK is located at a higher level in the SP tenant hierarchy than SP_London, and SP_UK and SP_Londen belong to the same group, it is determined that a trust relationship denoted by reference numeral 2654 exists between SP_UK and SP_London. With a trust relationship denoted by reference numeral 2653, a service entrustment broker acceptance process is required, and thus, broker acceptance processing is performed in step S22. When broker acceptance processing is performed in step S22, the trust relationship denoted by reference numeral 2653 is satisfied, and thus the user-to-instructor trust relationship 1109 is set to OK.

[0137] Next, the user of the client ABC_London accepts a transfer of access rights to SP_London in step S26. The processing procedure is the same as the procedure in the Fig. 17B, ​​and its description will be omitted. If a transfer condition for transferring access rights is satisfied as a result of these operations, an access rights transfer execution instruction is provided in step S27, and processing for transferring access rights from ABC_London to SP_London is executed in step S28.

[0138] As described above, according to the management device of the invention, even if a service provider does not know another service provider working as a service entruster, the service provider can securely entrust another service provider to provide services to customers via an intermediary provider.

[0139] Embodiments of the invention may also be implemented by a computer, system, or apparatus that retrieves and executes computer-readable instructions recorded on a storage medium (e.g., a non-transitory computer-readable storage medium) to perform the functions of one or more of the above-described embodiments of the invention, and by a method performed by the computer, system, or apparatus, for example, by retrieving the computer-executable instructions from the storage medium and executing them to perform the function of one or more of the above-described embodiments. The computer may include a central processing unit (CPU), microprocessing unit (MPU), or other circuitry, and may include a network of separate computers or separate computer processors.The computer-executable instructions may be supplied to the computer, for example, from a network or the storage medium. The storage medium may include, for example, a hard disk, random access memory (RAM), read-only memory (ROM), distributed computing system memory, an optical disc (such as a compact disc (CD), digital versatile disc (DVD), or Blu-ray Disc (BD)™), flash memory, a memory card, and the like.

[0140] Although the invention has been described with reference to exemplary embodiments, it should be understood that the invention is not limited to the disclosed embodiments. The scope of the following claims is intended to be given the broadest interpretation to encompass all modifications and equivalent structures and functions.

[0141] This application claims priority to Japanese Patent Application No. 2013-076533, filed on April 2, 2013, the contents of which are incorporated herein by reference.

[0142] A management device is provided that manages trust relationship information between service providers and trust relationship information between an existing device and a service provider. If the management device determines, based on the obtained trust relationship information, that a second service provider trusts a first service provider, the existing device trusts the first service provider, and the existing device trusts the second service provider, the management device sets up a transfer of access rights to the existing device held by the first service provider to the second service provider. < / abtastinformationen> < / datentabellenname>

Claims

[1] Management facility that can communicate with an existing facility and a service provider facility to provide services to the existing facility using resources and manages access rights to the resources with respect to the service provider facility, with a management unit for managing trust relationship information between the service provider institutions and trust relationship information between the existing institution and the service provider institution, and a setting unit for setting a transfer of access rights to the resources held by a first service provider to a second service provider, wherein, when the setting unit determines based on the trust relationship information that the second service provider device trusts the first service provider device, the inventory device trusts the first service provider device, and the inventory device trusts the second service provider device, the setting unit stops the transfer of the access rights. [2] The management device according to claim 1, wherein the trust relationship information includes information about a trust relationship or a delegation relationship between devices, and wherein, when the trust relationship information indicates that the inventory device delegates the transfer of the access rights to the first service provider device when the first service provider device entrusts the second service provider device with services for the inventory device, the setting unit sets the transfer of the access rights without determining whether the inventory device trusts the second service provider device or not. [3] Administrative device according to claim 1, further comprising a transmission unit for transmitting an entrustment screen for entrusting the second service provider device with services provided by the first service provider device to the second service provider device and transmitting a transmission screen for transferring access rights to the resources from the second service provider device to the existing device, wherein the setting unit determines that the second service providing device trusts the first service providing device when the second service providing device accepts an entrustment via the entrustment screen, and determines that the existing device trusts the second service providing device when the existing device accepts a transmission via the transmission screen. [4] The management device according to claim 1, wherein the management unit further manages hierarchical structure information about a hierarchical structure between the inventory devices and a hierarchical structure between the service provider devices, and wherein, when the second service provider device accepts entrustment via the entrustment screen, or when the first service provider device is positioned at a higher level than the second service provider device, the setting unit determines that the second service provider device trusts the first service provider device. [5] The management device according to claim 4, wherein, when the inventory device delegates the transfer of the access rights to the first service provider device via the transfer screen, the setting unit sets the transfer of the access rights without determining whether the inventory device trusts the second service provider device or not, and wherein, when the inventory device accepts a transfer via the transfer screen, or when there is an inventory device at a higher level than that of the inventory device, and the fact that the inventory device positioned at a higher level trusts the first service provider device is included in the trust relationship information, the setting unit determines that the inventory device trusts the first service provider device. [6] Management system comprising a management device that can communicate with an existing device and a service provider device to provide services to the existing device using resources and manages access rights to the resources with respect to the service provider device, where the administrative facility includes a management unit for obtaining trust relationship information from the existing facility and the service provider facility and managing trust relationship information between the service provider facilities and trust relationship information between the existing facility and the service provider facility and a setting unit for setting a transfer of access rights to the existing device held by a first service provider device to a second service provider device, wherein the first service provider comprises an entrustment instruction unit for entrusting the second service provider with services provided by the first service provider, and a transfer instruction unit for transferring access rights to the inventory facility, and wherein, when the setting unit provided in the management device determines, based on the obtained trust relationship information, that the second service provider device trusts the first service provider device, the inventory device trusts the first service provider device, and the inventory device trusts the second service provider device, the setting device stops the transfer of the access rights. [7] The management system according to claim 6, wherein the first service provider device further comprises a switching instruction unit for instructing a third service provider device to switch an entrustment of services provided by the first service provider device when the second service provider device is not determined, wherein the transfer instruction unit provides a transfer instruction for the existing device as a result of the acceptance of the entrustment by the second service provider device based on the switching instruction, and wherein the setting unit stops the transfer of access rights when the inventory facility accepts the transfer instruction. [8] A control method of a management device that can communicate with an existing device and a service provider device to provide services to the existing device using resources and manages access rights to the resources with respect to the service provider device, the control method comprising Managing trust relationship information between the service provider entities and trust relationship information between the existing entity and the service provider entity and Setting up a transfer of access rights to the resources held by a first service provider to a second service provider, wherein, if it is determined in the setting based on the obtained trust relationship information that the second service provider device trusts the first service provider device, the existing device trusts the first service provider device, and the existing device trusts the second service provider device, the transfer of the access rights is set in the setting based on the trust relationship information. [9] A non-transitory storage medium on which a computer program is stored that causes a computer to execute a control method of a management device that can communicate with an inventory device and a service provider device for providing services to the inventory device using resources and manages access rights to the resources with respect to the service provider device, the control method comprising Managing trust relationship information between the service provider entities and trust relationship information between the existing entity and the service provider entity, and Setting up a transfer of access rights to the resources held by a first service provider to a second service provider, wherein, if it is determined in the setting based on the obtained trust relationship information that the second service provider device trusts the first service provider device, the existing device trusts the first service provider device, and the existing device trusts the second service provider device, the transfer of the access rights is set in the setting based on the trust relationship information.

Images