WO2022157912A1 - コンピュータシステムおよびユーザ管理方法 - Google Patents

コンピュータシステムおよびユーザ管理方法 Download PDF

Info

Publication number
WO2022157912A1
WO2022157912A1 PCT/JP2021/002184 JP2021002184W WO2022157912A1 WO 2022157912 A1 WO2022157912 A1 WO 2022157912A1 JP 2021002184 W JP2021002184 W JP 2021002184W WO 2022157912 A1 WO2022157912 A1 WO 2022157912A1
Authority
WO
WIPO (PCT)
Prior art keywords
tenant
data
unit
user
management unit
Prior art date
Application number
PCT/JP2021/002184
Other languages
English (en)
French (fr)
Inventor
真也 北
一成 竹内
みさと 岡本
Original Assignee
楽天モバイル株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 楽天モバイル株式会社 filed Critical 楽天モバイル株式会社
Priority to PCT/JP2021/002184 priority Critical patent/WO2022157912A1/ja
Priority to US18/033,706 priority patent/US20230394126A1/en
Publication of WO2022157912A1 publication Critical patent/WO2022157912A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/32—User authentication using biometric data, e.g. fingerprints, iris scans or voiceprints
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2117—User registration

Definitions

  • Patent Document 4 describes identity management that achieves authentication by calling an identity management service via an API (Application Programming Interface) provided by a microservice. technique is described.
  • API Application Programming Interface
  • the security of user management in network services can be enhanced.
  • FIG. 10 is a diagram showing a procedure of login processing for a tenant administrator in the first embodiment
  • FIG. 7 is a diagram showing a procedure of general user login processing in the first embodiment
  • FIG. 10 is a diagram showing another procedure of general user login processing in the first embodiment
  • FIG. 10 is a diagram showing another procedure of general user login processing in the first embodiment
  • FIG. 1 is a diagram showing a computer system 1 according to this embodiment.
  • the computer system 1 is an information processing system that performs data processing related to construction and management of network services.
  • the vendor terminal 16 is a general computer such as a smart phone, tablet terminal, personal computer, etc. used by vendors such as service providers for network services.
  • the operation section data shows monitoring policies related to network services, such as monitored metrics and monitoring intervals.
  • FIG. 10 is a functional block diagram showing an example of functions implemented by the MPS 10 and NOS 12 according to this embodiment.
  • the plurality of functional blocks shown in the block diagrams of this specification can be configured by circuit blocks, memories, and other LSIs in terms of hardware, and in terms of software, the CPU executes programs loaded in the memory. It is realized by Therefore, those skilled in the art will understand that these functional blocks can be realized in various forms by hardware only, software only, or a combination thereof.
  • the MPS 10 and NOS 12 according to this embodiment need not implement all the functions shown in FIG. 10, and may implement functions other than the functions shown in FIG.
  • service catalog data may include requirement configuration correspondence data that indicates the correspondence between service requirement data values, types of functional unit groups, and the number of functional units for each type.
  • the requirement configuration data includes “20000 subscribers and one P-GW (Packet Data Network Gateway)", “20000 subscribers and one IMS (IP Multimedia System)", “20000 subscribers and one It may be indicated that one HSS (Home Subscriber Server) corresponds.
  • P-GW Packet Data Network Gateway
  • IMS IP Multimedia System
  • HSS Home Subscriber Server
  • Inventory template data is, for example, data corresponding to part of the technology section data and part of the security section data included in the bundle file.
  • the inventory template data is, for example, template data indicating logic used by the inventory manager 66 .
  • the slice template data includes "Generic Network Slice Template” information defined by the GSMA (GSM Association) ("GSM” is a registered trademark).
  • GSM Global System for Mobile communications
  • the slice template data includes network slice template data (NST), network slice subnet template data (NSST), and network service template data, and information indicating the hierarchical configuration of these network elements ( network hierarchy data above).
  • NST and NSST contain SLA information for Network Slice Instances (NSI) and Network Slice Subnet Instances (NSSI).
  • product catalog data, service catalog data, inventory template data, CM template data, service template data, slice template data, monitoring script data, security script data, helm chart data, and , container image data are associated with each other.
  • the product catalog storage unit 52 stores product catalog data associated with bundle IDs as described above.
  • the purchase management unit 54 transmits the purchase service requirement data associated with the purchase bundle ID to the E2EO unit 62 in response to acceptance of the above purchase request.
  • the purchase management unit 54 cooperates with the E2EO unit 62 and the inventory management unit 66 to identify the delivery date of the network service purchased by the purchaser. Then, the purchase management unit 54 notifies the purchaser of the specified delivery date.
  • the purchase management unit 54 for example, generates a purchase confirmation screen showing the specified delivery date and transmits the generated purchase confirmation screen to the purchaser terminal 14 .
  • FIG. 12 is a diagram showing an example of the data structure of physical inventory data.
  • the physical inventory data shown in FIG. 12 are associated with one server 90 .
  • the physical inventory data shown in FIG. 12 includes, for example, server IDs, location data, building data, floor data, rack data, allocated resource pool group IDs, allocated resource pool IDs, spec data, network data, operating container ID list, etc. is included.
  • the location data included in the physical inventory data is, for example, data indicating the location (eg, location address) of the server 90 associated with the physical inventory data.
  • the building data included in the physical inventory data is, for example, data indicating the building (eg, building name) in which the server 90 associated with the physical inventory data is located.
  • the assigned resource pool group ID included in the physical inventory data is, for example, the identifier of the resource pool group to which the server 90 associated with the physical inventory data is assigned.
  • the assigned resource pool ID included in the physical inventory data is, for example, the identifier of the resource pool to which the server 90 associated with the physical inventory data is assigned.
  • the resource pool indicated by the assigned resource pool ID is one of the resource pools included in the resource pool group corresponding to the assigned resource pool group ID.
  • a free server is assigned to one of the resource pool groups, but it is undecided to which resource pool included in the resource pool group the free server is assigned. Null is set as the value of the allocated resource pool ID included in the corresponding physical inventory data for such a free server.
  • the spec data included in the physical inventory data is data indicating the specs of the server 90, such as the number of cores, memory capacity, hard disk capacity, etc. of the server 90 associated with the physical inventory data.
  • the active container ID list included in the physical inventory data is, for example, data indicating a list of instance identifiers (container IDs) of one or more containers operating on the server 90 associated with the physical inventory data.
  • the NS data is, for example, data indicating attributes such as identifiers of network service instances corresponding to vRAN (virtual RAN) and the types of the network services.
  • the CNF data is, for example, data indicating attributes such as the identifier of the instance of the network function corresponding to eNodeB and the type of the network function.
  • the CNFC data is data indicating attributes such as the identifier of a CNFC instance and the type of the CNFC, which corresponds to, for example, a vCU or a vDU.
  • the pod data is data indicating attributes such as the identifier of the pod instance included in the CNFC and the type of the pod.
  • pod refers to the minimum unit for managing docker containers in Kubernetes.
  • the container data is data indicating attributes such as the container ID of the instance of the container included in the pod and the type of the container.
  • container data may include data indicating the IP address of the container corresponding to the container data.
  • CNFC data may include data indicating the IP address and host name of the CNFC indicated by the CNFC data.
  • NS data is associated with one or more CNF data corresponding to each of one or more network functions included in the network service corresponding to the NS data.
  • the CNF data is associated with one or more CNFC data respectively corresponding to one or more CNFCs included in the network function corresponding to the CNF data.
  • CNFC data is associated with one or more pod data respectively corresponding to one or more pods included in the CNFC corresponding to the CNFC data.
  • pod data is associated with one or more container data corresponding to each of one or more containers included in the pod corresponding to the pod data.
  • the container instance and the server 90 on which the container instance is running are identified by the container ID of the container data included in the logical inventory data and the container ID included in the active container ID list included in the physical inventory data. will be associated.
  • the network service purchased by the purchaser in this embodiment need not correspond to the network service associated with the NS data.
  • a network service purchased by a purchaser may be realized by a functional unit group corresponding to a network function associated with one or more CNF data, or may be associated with one or more CNFC data. It may be realized by a group of functional units that are provided.
  • the network service purchased by the purchaser may be realized by a functional unit group associated with one or more pods, or may be realized by a functional unit group associated with one or more containers. It does not matter if it is done.
  • FIG. 14 is a diagram showing an example of resource pool management data according to this embodiment.
  • the resource pool management data indicates the status of a plurality of resource pools included in the resource pool group associated with the resource pool management data.
  • the resource pool management data shown in FIG. 14 includes a resource pool group ID, multiple resource pool data, and free server count data.
  • the resource pool group ID included in the resource pool management data is the identifier of the resource pool group associated with the resource pool management data.
  • the free server number data included in the resource pool management data is data indicating the number of free servers assigned to the resource pool group associated with the resource pool management data.
  • Resource pool data is data that indicates the status of resource pools included in a resource pool group associated with resource pool management data.
  • resource pool data includes a resource pool ID, total core number data, remaining core number data, and CNFC type data.
  • a resource pool ID is an identifier for a resource pool.
  • the total number of cores data is data indicating the total number of cores of the server 90 allocated to the resource pool.
  • the total core count data is a specific example of resource total amount data indicating the total amount of hardware resources included in the resource pool.
  • the remaining core number data is data indicating the remaining number of cores of the server 90 allocated to the resource pool.
  • the remaining core number data is a specific example of resource remaining amount data indicating the remaining amount of hardware resources included in the resource pool.
  • the CNFC type data is data indicating one or more types of CNFC associated with the resource pool.
  • the CNFC type data is a specific example of functional unit type data indicating one or more types of functional units associated with the resource pool.
  • a resource pool group spanning multiple locations may be set in advance, or a resource pool group associated with only one location may be set in advance. In either case, the resource pool group will be associated with one or more locations indicated in the physical inventory data.
  • the E2EO unit 62 and the inventory management unit 66 specify the configuration of the functional unit group that realizes the purchased network service based on the service requirement data received from the purchase management unit 54, for example.
  • plan data may include the values set in the purchase service requirement data.
  • the plan data shown in FIGS. 15 and 16 includes the counter IP data value, monitoring target data value, monitoring interval data value, and password data value included in the purchase service requirement data.
  • the E2EO unit 62 may store the assumed busy level data shown in FIG.
  • the assumed busy level data shown in FIG. 17 indicates, for example, the population of an area covered by one or more cells under the control of the data center associated with the assumed busy level data.
  • the assumed busy level data value is an example of the weight set for each location described above.
  • Required resource data is, for example, data that indicates the resources required for the operation of the container.
  • the inventory template data indicates, for each container, the resources necessary for operating the container.
  • the inventory management unit 66 sets values of required resource data based on the inventory template data.
  • the CMaaS section 68, the service manager section 70, the slice manager section 72, and the container management section 78 construct a functional unit group by executing the specified construction procedure. This process is also triggered by execution of a workflow script by the E2EO unit 62, for example.
  • the CMaaS section 68 and the BMaas section 84 for example, secure hardware resources (here, for example, the server 90) on which new functional unit groups are deployed.
  • a general-purpose server with a general configuration may not be able to demonstrate sufficient performance. Therefore, for such a specific type of functional unit, it is desirable to provide a hardware resource such as a server with a dedicated setup for system software such as the host OS and BIOS.
  • a hardware resource such as a server with a dedicated setup for system software such as the host OS and BIOS.
  • system software such as the host OS and BIOS.
  • the required number of hardware resources with dedicated system software set up is prepared in advance before the start of network service provision, and the functional units are deployed to the prepared hardware resources when necessary. can be considered.
  • FIG. 19 is a diagram showing an example of CNFCD.
  • the service manager unit 70 generates the day0 parameter (CNFC instance) shown in FIG. 20, for example, based on the plan data and the CNFCD.
  • the day0 parameter shown in FIG. 20 is generated in which the values of the host name and IP address of CNFCD shown in FIG. 19 are set.
  • the service manager unit 70 then outputs each of the generated one or more day0 parameters to the container management unit 78, which is the output destination location of the day0 parameter.
  • a purchased bundle ID is associated with the day0 parameter.
  • the container management unit 78 deploys a new functional unit group based on the received day0 parameter.
  • the container management unit 78 identifies the container image to be deployed and the resource pool to which the container is to be deployed based on the helm chart data associated with the purchased bundle ID and the received day0 parameter, for example.
  • the container management unit 78 acquires the container image from the repository unit 80 and deploys the container corresponding to the container image in the specified resource pool.
  • a manifest file is generated based on the helm chart data associated with the purchased bundle ID and the received day0 parameter. Then, deployment of the container using the manifest file is executed.
  • the day1 parameter includes, for example, configuration management procedures such as settings for a group of deployed functional units and at least one functional unit related to the group of functional units (for example, a functional unit that communicates with the group of deployed functional units). It is shown.
  • the day1 parameter related to the base station device 22 indicates, for example, the radio wave intensity, the orientation and angle of the antenna 22a, the serial number, and the like.
  • the day1 parameter related to the S-GW includes, for example, information indicating the opposite node (information indicating the MME (Mobility Management Entity) of the communication partner, APN (Access Point Name), etc.), RADIUS (Remote Authentication Dial In User Service) server host name or FQDN, etc. are shown.
  • the CMaaS unit 68 executes configuration management such as setting of functional units based on the day1 parameter included in the generated planned CM data. These processes are triggered by execution of a workflow script by the E2EO unit 62, for example.
  • the slice manager unit 72 includes NSMF (Network Slice Management Function) and NSSMF (Network Slice Sub-network Management Function) functions described in the 3GPP specification "TS28 533".
  • NSMF Network Slice Management Function
  • NSSMF Network Slice Sub-network Management Function
  • NSMF is a function that creates and manages network slices and provides management of NSIs.
  • NSSMF is a function that creates and manages network slice subnets that form part of a network slice, and provides management of NSSI.
  • FIG. 21 schematically shows the processing when constructing the NSI and NSSI.
  • Device a to device c in FIG. 21 correspond to a plurality of servers 90 .
  • the slice manager section 72 passes configuration management instructions to the CMaaS section 68 including setting information for setting the NSI and NSSI on each device.
  • the slice manager unit 72 may output to the CMaaS unit 68 configuration management instructions related to instantiation of network slices. Then, the CMaaS unit 68 may execute configuration management such as setting according to the configuration management instruction.
  • CMaaS unit 68 may update the once generated day1 parameter based on the configuration management instruction received from the slice manager unit 72 . CMaaS unit 68 may then collectively perform configuration management related to instantiation of new functional units and network slices.
  • the monitoring management unit 74 may acquire logs from a sidecar that outputs the value of a monitored metric associated with a monitored container as a log at the above-described monitoring intervals. Then, the monitoring management unit 74 may accumulate the log. Then, the monitoring management unit 74 may transmit the log to the purchaser terminal 14 in response to a request from the purchaser terminal 14, for example.
  • the bundle expansion unit 60 causes the security setting unit 76 to store the security script data included in the data group shown in S102, which is associated with the bundle ID determined in the process shown in S103 (S111).
  • Each tenant 144 includes a tenant user management unit 146 and an application processing unit 152.
  • the tenant user management unit 146 has functions equivalent to those of the marketplace user management unit 136 described above.
  • the target of management is mainly general users who access the client within the tenant and use the service.
  • the marketplace user management unit 136 can be regarded as a "tenant generation system internal user management unit".
  • the tenant administrator who has performed user registration requests login to the MPS 10 when purchasing a tenant (S506). Specifically, the tenant administrator accesses the global page provided by the purchase management unit 54 of the MPS 10 and causes the purchaser terminal 14 to display a login screen. When the tenant administrator enters information used for authentication such as a user name, user ID, and password, the login processing unit 132 of the purchase management unit 54 acquires it and supplies it to the marketplace user management unit 136 for authentication. (S508).
  • This process may actually be realized by the login processing unit 132 redirecting the browser to the marketplace user management unit 136. If authentication is successful, such as that the entered information matches the registered information, the marketplace user management unit 136 calls back to the URL of the private page for the tenant administrator, and via the purchaser terminal 14 to present the private page to the user (S510).
  • the marketplace user management unit 136 causes the purchaser terminal 14 to acquire the user token for purchasing the tenant by adding it to the callback URL.
  • a “private page” is a page that is generated for each organization to which a tenant administrator belongs and that can only be viewed by members of that organization.
  • a "global page” is a page that can be browsed by a user who registers with the MPS 10 or a registered user, regardless of the organization. Subsequently, the tenant administrator makes a tenant purchase request via the private page (S512).
  • the purchase management unit 54 of the MPS 10 accepts the request and requests the E2EO unit 62 to create a tenant. This process may actually be realized by the procedure shown in FIGS.
  • the purchase reception unit 134 of the purchase management unit 54 receives the necessary information such as the tenant name and service requirements entered by the tenant administrator on the private page for purchasing the tenant, along with the user information issued to the tenant administrator. get a token. After that, the user token is used to associate the tenant with the tenant administrator or organization who requested to create the tenant.
  • the E2EO unit 62 When the purchase acceptance unit 134 supplies the acquired information and user token to the E2EO unit 62, the E2EO unit 62 accepts this and controls the creation process of the tenant 144 (S514). This processing may actually be realized by the procedure shown in FIGS. 25A to 25G.
  • the E2EO unit 62 issues a tenant ID for uniquely identifying the tenant.
  • the E2EO unit 62 registers clients such as applications and services to be operated in the tenant 144 in the client information storage unit 140 of the marketplace user management unit 136 (S516). Specifically, the client registration unit 142 of the E2EO unit 62 first causes the cooperation unit 150 of the tenant 144 to issue a URL for callback to the page of the client. Note that the cooperation unit 150 may actually be implemented as an IDP.
  • the client registration unit 142 stores the callback URL in the client information storage unit 140 in association with the identification information of the client.
  • the marketplace user management unit 136 issues a client secret as an access key to the marketplace user management unit 136 from the client.
  • the client registration unit 142 obtains it and registers it in the cooperation unit 150 of the tenant user management unit 146 (S518).
  • the procedure is as follows. First, the tenant administrator accesses the page provided by the application processing unit 152 of the tenant 144 corresponding to his own organization. Then, a login screen is displayed on the administrator terminal 160, and login is requested by entering information necessary for login such as a user ID and a password (S536). Based on the input information, the tenant user management unit 146 of the tenant 144 recognizes that the request source is the tenant administrator, and redirects to the marketplace user management unit 136 by the cooperation unit 150 (S538).
  • the cooperation unit 150 ensures access safety by transmitting the client secret.
  • the marketplace user management unit 136 confirms that the access is authorized based on the client information stored in the client information storage unit 140, and then performs authentication processing based on the user information storage unit 138. FIG. If the authentication succeeds, the marketplace user management unit 136 calls back using the URL associated with the client (S540). As a result, a post-login screen provided by the application processing unit 152 is presented on the administrator terminal 160 (S542).
  • the tenant user management unit 146 of the tenant 144 Based on the input user information, the tenant user management unit 146 of the tenant 144 recognizes that the requester is a general user, and performs authentication processing based on the user information storage unit 148 owned by itself (S552). When the authentication is successful, a call back is made to the page provided by the application processing unit 152, and the post-login screen provided by the application processing unit 152 is presented to the general user terminal 162 (S554).
  • the function of the user information storage unit 138 is as described with reference to FIG.
  • the cooperation unit 170 realizes login authentication to the MPS 10a using the tenant user management unit 146a.
  • the owner terminal 172 notifies the system owner that the tenant manager has registered as a user in the MPS 10a, and receives approval for creation of the corresponding tenant from the system owner.
  • the owner terminal 172 then requests the E2EO unit 62a to create an approved tenant.
  • the E2EO unit 62a includes a user registration unit 174 and a client registration unit 142a.
  • the user registration unit 174 registers the information of the tenant administrator who created the tenant in both the marketplace user management unit 136a and the tenant user management unit 146a in the created tenant 144a. That is, in the second embodiment, the tenant administrator is also registered on the tenant user management unit 146a side along with the creation of the tenant.
  • the client registration unit 142a registers client information in the tenant user management unit 146a in the created tenant 144a.
  • the function of the tenant user management unit 146a of the tenant 144a is basically the same as that of the tenant user management unit 146 of FIG. Prepare.
  • the function of the user information storage unit 148 is the same as that shown in FIG. 27, but in the second embodiment, the user information of the tenant administrator is stored by the E2EO unit 62 in addition to the user information of general users. be.
  • the client information storage unit 178 stores client information such as applications and services that operate in the tenant 144a. Client information includes access keys and realm settings.
  • the E2EO unit 62a accepts this and controls the creation process of the tenant 144a (S606). This processing may actually be realized by the procedure shown in FIGS. 25A to 25G.
  • the E2EO unit 62 issues a tenant ID for uniquely identifying the tenant.
  • the E2EO unit 62a also creates a tenant user management unit 146a as part of the tenant 144a. As in the first embodiment, the tenant user management unit 146a is generated in a state separated logically or physically from the marketplace user management unit 136a and the tenant user management units 146a of other tenants.
  • the user registration unit 174 of the E2EO unit 62 performs user registration of the tenant administrator who requested the creation of the tenant in the tenant user management unit 146a of the created tenant 144a (S608).
  • the user information of the tenant administrator is stored in the user information storage unit 148 .
  • the client registration unit 142a of the E2EO unit 62 also registers clients such as applications and services to be operated in the tenant 144 in the tenant user management unit 146a of the created tenant 144a (S610). The client information is thereby stored in the client information storage unit 178 .
  • the user registration unit 174 also stores, in the user information, the URL for callback to the private page for the tenant administrator provided by the purchase management unit 54a of the MPS 10a.
  • the client registration unit 142a of the E2EO unit 62a appropriately updates the client realm in the tenant user management unit 146a of the created tenant 144a according to the role assigned to the tenant administrator (S614).
  • both the use of services in the tenant 144a and the login to the MPS 10 are enabled by the authentication by the tenant user management unit 146a.
  • the E2EO unit 62 notifies the tenant administrator of the generated tenant ID by returning it to the purchaser terminal 14 (S616).
  • the E2EO unit 62 may also generate credential information such as a password that is used when the tenant user management unit 146a authenticates the tenant administrator, and notify the tenant administrator of the credential information.
  • a cooperative system (federation) is established between the marketplace user management unit 136 and the tenant user management unit 146, and authentication and authorization on the tenant 144 side can be used even when logging into the MPS 10.
  • the tenant user management unit 146a may cooperate with a system other than the computer system 1, as in FIG.
  • the general user login processing procedure in the second embodiment may be the same as the procedure shown in FIGS. 30 and 31 in the first embodiment. Even if the tenant administrator directly requests login to the client of the tenant 144a without logging into the MPS 10a, the login process is performed in the same procedure as for general users.

Abstract

コンピュータシステムにおいてテナント管理者は、購入管理部５４に対しユーザ登録、ログインをしたうえ、テナントの購入を要求する。登録したユーザ情報は、マーケットプレイスユーザ管理部１３６に格納される。Ｅ２ＥＯ部６２は、テナント１４４を生成するとともに、サービスを利用する一般ユーザの認証や認可を行うテナントユーザ管理部１４６を個別に生成する。購入管理部５４でユーザ登録を行ったユーザがテナントのサービスを利用するとき、テナントユーザ管理部１４６がマーケットプレイスユーザ管理部１３６に処理を委託する。

Description

コンピュータシステムおよびユーザ管理方法
　本発明は、データ処理技術に関し、特にコンピュータシステムにおけるユーザ管理技術に関する。
　ネットワークサービスの購入に応じた機能ユニットのデプロイに関する技術の一例として、特許文献１には、顧客が購入した製品のオーダを、ＶＮＦ（Virtualized Network Function）単位に分解し、ＮＦＶＩ（Network Functions Virtualization Infrastructure）上にデプロイする技術が記載されている。特許文献２には、非共有に関する要件であるアイソレーション要件を満たすよう、配備要求に応じたネットワーク機能部を利用可能な計算装置に配備する技術が記載されている。特許文献３には、上位の事業者において管理している複数のネットワークスライスの全部又は一部を、複数の事業者に対して独自性をもって利用させることができる技術が記載されている。
　また、クラウド環境においてユーザアクセスの安全性を高める技術の一例として、特許文献4には、マイクロサービスが提供するＡＰＩ（Application Programming Interface）を介してアイデンティティ管理サービスを呼び出すことにより認証を実現するアイデンティティ管理技術が記載されている。
国際公開第２０１８／１８１８２６号 国際公開第２０１９／６４６７８号 国際公開第２０１８／３４３２１号 特開２０１８－１４２３３２号公報
　ネットワークサービスの構成、規模、対象地域などといったネットワークサービスに対するニーズは様々である。当該ニーズに応じて多様なネットワークサービスを構築する場合、ネットワークサービスの提供者や利用者など様々な立場のユーザによるアクセスや各種情報更新があり得、認証や認可を含むユーザ管理をどのように実現するかは常に大きな課題である。そのため、ネットワークサービスの柔軟性やユーザにとっての利便性を損なわず、高い安全性を実現できるユーザ管理技術が求められている。
　本発明はこうした課題に鑑みてなされたものであり、その目的は、ネットワークサービスにおけるユーザ管理の安全性を高められる技術を提供することにある。また本発明の別の目的は、ユーザによるネットワークサービスへのアクセスの利便性を高められる技術を提供することにある。
　本発明のある態様はコンピュータシステムに関する。このコンピュータシステムは、複数のテナントのそれぞれに対応するサービスを提供するコンピュータシステムであって、テナント生成要求を受け付けテナントを生成するテナント生成システムと、生成されたテナントを稼働させるテナント稼働システムを含み、テナント稼働システムは、サービスを利用するユーザの認証および認可を行うテナントユーザ管理部を、テナント生成システムと分離して備えることを特徴とする。
　本発明の別の態様は、ユーザ管理方法に関する。このユーザ管理方法は、複数のテナントのそれぞれに対応するサービスを提供するコンピュータシステムにおいて、テナント生成システムが、テナント生成要求を受け付けテナントを生成するステップと、テナント稼働システムが、生成されたテナントを稼働させるステップと、テナント稼働システムが、サービスを利用するユーザの認証および認可を、テナント生成システムと分離されたテナントユーザ管理部において行うステップと、を含むことを特徴とする。
　なお、以上の構成要素の任意の組合せ、本開示の表現を、装置、コンピュータプログラム、コンピュータプログラムを読み取り可能に記録した記録媒体などの間で変換したものもまた、本開示の態様として有効である。
　本発明によると、ネットワークサービスにおけるユーザ管理の安全性を高められる。また、ユーザによるネットワークサービスへのアクセスの利便性を高められる。
前提技術に係るコンピュータシステムを示す図である。 購入画面の一例を模式的に示す図である。 サービス要件入力画面の一例を示す図である。 購入確認画面の一例を示す図である。 購入確認画面の一例を示す図である。 バンドルファイルのデータ構造の一例を示す図である。 複数種類のネットワーク要素の階層構成を示す図である。 ＮＳＩとＮＳＳＩの例を示す図である。 オンボーディング画面の一例を示す図である。 前提技術に係るＭＰＳ及びＮＯＳで実装される機能の一例を示す機能ブロック図である。 バンドルファイルに基づいて生成されるデータ群のデータ構造の一例を示す図である。 物理インベントリデータのデータ構造の一例を示す図である。 論理インベントリデータのデータ構造の一例を模式的に示す図である。 リソース管理データの一例を示す図である。 計画データのデータ構造の一例を示す図である。 計画データの一例を模式的に示す図である。 想定ビジーレベルデータの一例を示す図である。 リソース管理データの一例を示す図である。 ＣＮＦＣＤの一例を示す図である。 ｄａｙ０パラメータの一例を示す図である。 ＮＳＩおよびＮＳＳＩの構築時の処理を模式的に示す 前提技術に係るベンダ端末、ＭＰＳ、及び、ＮＯＳで行われる処理の流れの一例を示すフロー図である。 前提技術に係るベンダ端末、ＭＰＳ、及び、ＮＯＳで行われる処理の流れの一例を示すフロー図である。 前提技術に係る購入者端末、ＭＰＳ、及び、ＮＯＳで行われる処理の流れの一例を示すフロー図である。 前提技術に係る購入者端末、ＭＰＳ、及び、ＮＯＳで行われる処理の流れの一例を示すフロー図である。 前提技術に係るＮＯＳで行われる処理の流れの一例を示すフロー図である。 前提技術に係るＮＯＳで行われる処理の流れの一例を示すフロー図である。 前提技術に係るＮＯＳで行われる処理の流れの一例を示すフロー図である。 前提技術に係るＮＯＳで行われる処理の流れの一例を示すフロー図である。 前提技術に係るＮＯＳで行われる処理の流れの一例を示すフロー図である。 前提技術に係るＮＯＳで行われる処理の流れの一例を示すフロー図である。 前提技術に係るＮＯＳで行われる処理の流れの一例を示すフロー図である。 本実施の形態で想定する、コンピュータシステムにおける作業区分を例示する図である。 第１の実施形態におけるマーケットプレイスシステム（ＭＰＳ）、Ｅ２ＥＯ部、およびテナントの機能ブロックの構成を示す図である。 第１の実施形態における管理システムの構築手順を示す図である。 第１の実施形態における、テナント管理者のログイン処理の手順を示す図である。 第１の実施形態における、一般ユーザのログイン処理の手順を示す図である。 第１の実施形態における、一般ユーザのログイン処理の別の手順を示す図である。 第２の実施形態におけるマーケットプレイスシステム（ＭＰＳ）、Ｅ２ＥＯ部、オーナー端末、およびテナントの機能ブロックの構成を示す図である。 第２の実施形態における管理システムの構築手順を示す図である。 第２の実施形態における、テナント管理者のログイン処理の手順を示す図である。
　はじめに、本実施の形態で利用するネットワークサービスの構築や管理に係る態様を「前提技術」として詳述する。この態様は本発明との組み合わせに最適であるが、実施の形態で採用可能なコンピュータシステムの構成をこれに限るものではない。図２６以降、前提技術を利用したユーザ管理技術を具体的に説明する。
［前提技術の実施の形態］
　図１は、本実施の形態に係るコンピュータシステム１を示す図である。コンピュータシステム１は、ネットワークサービスの構築や管理に関するデータ処理を行う情報処理システムである。
　図１に示すように、コンピュータシステム１では、インターネット等のコンピュータネットワーク２４に、マーケットプレイスシステム（ＭＰＳ）１０、ネットワークオペレーティングシステム（ＮＯＳ）１２、購入者端末１４、ベンダ端末１６、複数のコアネットワークシステム２０、及び、複数の基地局装置２２、が接続されている。コアネットワークシステム２０、基地局装置２２、コンピュータネットワーク２４は、互いに連携して、移動無線通信ネットワークを実現する。
　コアネットワークシステム２０は、第４世代移動通信システム（以下、４Ｇと呼ぶ。）におけるＥＰＣ（Evolved Packet Core）や、第５世代移動通信システム（以下、５Ｇと呼ぶ。）における、ＡＭＦ（Access and Mobility Management Function）、ＳＭＦ（Session Management Function）、ＵＰＦ（User Plane Function）等を含む５ＧＣ（5G Core Network）に相当するシステムである。本実施形態に係るコアネットワークシステム２０は、様々なロケーションに設けられた複数のデータセンタに配置されたサーバ群によって実装されている。各データセンタには、複数のサーバが配置されている。なお、図１には２つのコアネットワークシステム２０が示されているが、本実施形態に係るコアネットワークシステム２０の数は２つには限定されず、１つであってもよいし３つ以上であってもよい。
　基地局装置２２は、４ＧにおけるｅＮＢ（ｅＮｏｄｅＢ）や、５ＧにおけるｇＮＢ（ＮＲ基地局）に相当する、アンテナ２２ａを備えたコンピュータシステムである。本実施形態に係る基地局装置２２には、１又は複数のサーバ（後述のサーバ９０）が含まれる。なお、基地局装置２２がデータセンタに配置されたサーバ群によって実装されていても構わない。
　また、４ＧにおけるＲＡＮ（Radio Access Network）の構成要素であるｖＤＵ（virtual Distributed Unit）やｖＣＵ（virtual Central Unit）は、基地局装置２２に配置されてもよいしコアネットワークシステム２０の一部に組み込まれていてもよい。また、５ＧにおけるＲＡＮの構成要素であるＤＵやＣＵについても同様に、基地局装置２２に配置されてもよいしコアネットワークシステム２０の一部に組み込まれていてもよい。
　本実施形態に係るＭＰＳ１０は、例えば、クラウド基盤上に構成されており、図１に示すように、プロセッサ１０ａ、記憶部１０ｂ、通信部１０ｃ、が含まれる。プロセッサ１０ａは、ＭＰＳ１０にインストールされるプログラムに従って動作するマイクロプロセッサ等のプログラム制御デバイスである。記憶部１０ｂは、例えばＲＯＭやＲＡＭ等の記憶素子や、ソリッドステートドライブ（ＳＳＤ）、ハードディスクドライブ（ＨＤＤ）などである。記憶部１０ｂには、プロセッサ１０ａによって実行されるプログラムなどが記憶される。通信部１０ｃは、例えば、ＮＩＣ（Network Interface Card）や無線ＬＡＮモジュールなどといった通信インタフェースである。通信部１０ｃは、コンピュータネットワーク２４を介して、ＮＯＳ１２や購入者端末１４との間でデータを授受する。
　本実施形態に係るＮＯＳ１２は、例えば、クラウド基盤上に構成されており、図１に示すように、プロセッサ１２ａ、記憶部１２ｂ、通信部１２ｃ、が含まれる。プロセッサ１２ａは、ＮＯＳ１２にインストールされるプログラムに従って動作するマイクロプロセッサ等のプログラム制御デバイスである。記憶部１２ｂは、例えばＲＯＭやＲＡＭ等の記憶素子や、ソリッドステートドライブ（ＳＳＤ）、ハードディスクドライブ（ＨＤＤ）などである。記憶部１２ｂには、プロセッサ１２ａによって実行されるプログラムなどが記憶される。通信部１２ｃは、例えば、ＮＩＣや無線ＬＡＮモジュールなどといった通信インタフェースである。通信部１２ｃは、コンピュータネットワーク２４を介して、ＭＰＳ１０、購入者端末１４、ベンダ端末１６、コアネットワークシステム２０、基地局装置２２との間でデータを授受する。
　本実施形態では、購入者によるネットワークサービスの購入要求に応じて、購入要求がされたネットワークサービスがコアネットワークシステム２０や基地局装置２２に構築される。そして、構築されたネットワークサービスが購入者に提供される。
　例えば、ＭＶＮＯ（Mobile Virtual Network Operator）である購入者に、音声通信サービスやデータ通信サービス等のネットワークサービスが提供される。本実施形態によって提供される音声通信サービスやデータ通信サービスは、図１に示すＵＥ（User Equipment）２６を利用する、購入者（上述の例ではＭＶＮＯ）にとっての顧客（エンドユーザ）に対して最終的に提供されることとなる。当該エンドユーザは、コアネットワークシステム２０や基地局装置２２を介して他のユーザとの間で音声通信やデータ通信を行うことが可能である。
　また、本実施形態において提供されるネットワークサービスは音声通信サービスやデータ通信サービスには限定されない。本実施形態において提供されるネットワークサービスは、例えば、ＩｏＴサービスであっても構わない。そして、例えば、ロボットアームやコネクテッドカーなどを利用するエンドユーザが本実施形態に係るネットワークサービスの購入者となっても構わない。
　また、本実施形態では、コアネットワークシステム２０や基地局装置２２に配置されているサーバには、ドッカー（Ｄｏｃｋｅｒ）などのコンテナ型のアプリケーション実行環境がインストールされており、これらのサーバにコンテナをデプロイして稼働させることができるようになっている。そして本実施形態において購入者に提供されるネットワークサービスは、コンテナベースの機能ユニットであるＣＮＦＣ（Cloud-native Network Function Component）によって実装される。
　本実施形態に係る購入者端末１４は、例えば、上述の購入者が利用する、スマートフォン、タブレット端末、パーソナルコンピュータ、などの一般的なコンピュータである。
　図２は、本実施形態に係る購入者端末１４に表示される購入画面の一例を示す図である。図２に示す購入画面では、ラジオボタンによって購入者が購入するネットワークサービスの種類が選択できるようになっている。ここで、購入者が音声通信サービスを指定して、次へボタン３０をクリックすると、購入者端末１４には、図３に示すサービス要件入力画面が表示される。
　サービス要件入力画面では、購入者は、購入するネットワークサービスについてのサービス要件を入力できるようになっている。図３の例では、加入者数、対向ＩＰ、監視対象、監視間隔、対象地域、及び、パスワードが設定できるようになっている。なお、対向ＩＰとは、購入者が既に保有しているネットワークシステムに対するアクセスポイントとなるＩＰアドレスを指す。
　購入者がこれらのサービス要件を入力して、次へボタン３２をクリックすると、サービス要件入力画面への入力に対応付けられるサービス要件データが、ＭＰＳ１０に送信される。
　サービス要件データには、例えば、加入者数を示す加入者数データ、対向ＩＰを示す対向ＩＰデータ、監視対象を示す監視対象データ、当該監視対象の監視間隔を示す監視間隔データ、購入されるネットワークサービスの対象地域を示す対象地域データ、及び、パスワードを示すパスワードデータが含まれる。なお、サービス要件データにこれらのデータのすべてが含まれている必要はなく、また、これら以外の要件を示すデータが含まれていてもよい。
　そして、ＭＰＳ１０が、ＮＯＳ１２と連携して、サービス要件データに基づいて、当該サービス要件データが示すサービス要件を満たすサーバの確保が可能であるか否かを確認する。ここでは例えば、（１）サービス要件を満たすサーバの確保が可能である、（２）空きサーバのセットアップを行うことでサービス要件を満たすサーバの確保が可能である、（３）サービス要件を満たすサーバの確保が不可能である、のいずれであるかが判定される。
　そして、当該判定の結果が（１）又は（２）である場合には、購入者端末１４には、図４に示す、即時の提供が可能であることを示す購入確認画面が表示される。当該判定の結果が（３）である場合には、購入者端末１４には、図５に示す、所定の納期が必要である（例えば、２週間の納期が必要である）ことを示す購入確認画面が表示される。
　ここで、購入者によって、図４又は図５に示す購入ボタン３４がクリックされると、購入要求がされたネットワークサービスが構築され、購入者に提供される。
　一方、購入者によって、図４又は図５に示すキャンセルボタン３６がクリックされると、購入はキャンセルされる。
　以上のように本実施形態によれば、購入者の様々なニーズに応じたネットワークサービスが柔軟に構築される。購入者は、ネットワークサービスの細かい実装について意識することなく、いくつかのサービス要件を指定するだけで、所望のネットワークサービスの提供を受けることができる。
　本実施形態に係るベンダ端末１６は、ネットワークサービスに関するサービスプロバイダ等のベンダが利用する、スマートフォン、タブレット端末、パーソナルコンピュータ、などの一般的なコンピュータである。
　本実施形態では、ベンダに、開発環境、検証環境、試験環境を含むＣＩ（Continuous Integration）／ＣＤ（Continuous Delivery）パイプラインが提供される。そして、本実施形態では、当該ＣＩ／ＣＤパイプラインを活用したオンボーディングプロセスによって、ベンダによって作成された、購入者への提供対象であるネットワークサービスに対応する検証済のバンドルファイルがオンボーディングされる。
　本実施形態に係るバンドルファイルは、例えば、所定のディレクトリ構成のファイル群を圧縮したファイル（例えばｔａｒｇｚ形式のファイル）である。
　図６は、本実施形態に係るバンドルファイルのデータ構造の一例を示す図である。図６に示すように、本実施形態に係るバンドルファイルには、ビジネスセクションデータ、テクノロジーセクションデータ、セキュリティセクションデータ、及び、オペレーションセクションデータが含まれる。
　ビジネスセクションデータには、例えば、ネットワークサービスの名称、ライセンス要件、サービスレベルアグリーメント（ＳＬＡ）の定義など、ネットワークサービスのビジネス要件が示されている。また、本実施形態に係るビジネスセクションデータには、ネットワークサービスのサービス要件についての必須の入力項目やオプションの入力項目を示すデータが含まれている。
　テクノロジーセクションデータには、例えば、ネットワークサービスを実現する機能ユニット群の構成が示されている。また、テクノロジーセクションデータには、例えば、ネットワークサービスを構成するアプリケーションやＣＮＦＣの構成が示されている。
　また、テクノロジーセクションデータには、例えば、ネットワークサービス（以下「ＮＳ」とも呼ぶ。）と、その下位に紐付けられるネットワーク機能（以下「ＣＮＦ」（Cloud-native Network Function）とも呼ぶ。）およびＣＮＦＣの階層構成が示されている。また、テクノロジーセクションデータには、例えば、ネットワークサービスと、その上位に紐付けられるネットワークスライスサブネット（以下「ＮＳＳＩ」とも呼ぶ。）およびネットワークスライス（以下「ＮＳＩ」とも呼ぶ。）の階層構成が示されている。すなわち、テクノロジーセクションデータは、複数種類のネットワーク要素の階層構成、言い換えれば、対応関係が示されている。
　図７は、複数種類のネットワーク要素の階層構成を示す。ＮＳＩとＮＳＳＩは１対多の関係となり、ＮＳＳＩとＮＳは多対多の関係となる。ＮＳとＣＮＦは１対多の関係となり、ＣＮＦとＣＮＦＣも１対多の関係となる。複数種類のネットワーク要素の階層構成を示すデータを以下「ネットワーク階層データ」とも呼ぶ。ネットワーク階層データは、１つ以上のＮＳＩと複数のＮＳＳＩとの対応関係を示すデータ、複数のＮＳＳＩと複数のＮＳとの対応関係を示すデータ、複数のＮＳと複数のＣＮＦとの対応関係を示すデータ、複数のＣＮＦと複数のＣＮＦＣとの対応関係を示すデータを含む。
　図８は、ＮＳＩとＮＳＳＩの例を示す。ＮＳＩは、複数ドメイン（例えばＲＡＮからコアネットワーク）に跨るエンド・ツー・エンドの仮想回線とも言える。ＮＳＩは、高速大容量通信用のスライス、高信頼度かつ低遅延通信用のスライス、または大量端末の接続用のスライスであってもよい。ＮＳＳＩは、ＮＳＩを分割した単一ドメインの仮想回線とも言える。ＮＳＳＩは、ＲＡＮドメインのスライス、ＭＢＨ（Mobile Back Haul）ドメインのスライス、またはコアネットワークドメインのスライスであってもよい。また、図８に示すように、複数のＮＳＩが同じＮＳＳＩを共有してもよい。
　ＮＳは、５Ｇのコアネットワーク（５ＧＣ）、４Ｇのコアネットワーク（ＥＰＣ）、５ＧのＲＡＮ、または４ＧのＲＡＮであってもよい。ＣＮＦは、５Ｇのコアネットワークにおける複数種類のネットワーク機能であってもよく、例えば、ＡＭＦ、ＳＭＦ、またはＵＰＦであってもよい。また、ＣＮＦは、４Ｇのコアネットワークにおける複数種類のネットワーク機能であってもよく、例えば、ＭＭＥ（Mobility Management Entity）、ＨＳＳ（Home Subscriber Server）、またはＳ－ＧＷ（Serving Gateway）であってもよい。
　ＣＮＦＣは、１つ以上のコンテナとしてサーバにデプロイされるマイクロサービスであってもよい。例えば、或るＣＮＦＣは、ｅＮｏｄｅＢ（すなわちＬＴＥ基地局）またはｇＮＢ（すなわち５Ｇ基地局）の機能のうち一部の機能を提供するマイクロサービスであってもよい。また、別のＣＮＦＣは、ＡＭＦまたはＭＭＥ等のコアネットワーク機能のうち一部の機能を提供するマイクロサービスであってもよい。
　図６に戻り、セキュリティセクションデータには、例えば、インストール資格情報などといった、当該ネットワークサービスのセキュリティ定義が示されている。
　オペレーションセクションデータには、例えば、監視対象のメトリックや監視間隔などのネットワークサービスに関する監視ポリシーが示されている。
　図９は、本実施形態に係るベンダ端末１６に表示されるオンボーディング画面の一例を示す図である。本実施形態では、ベンダが、バンドルファイルが配置されているパスを指
定した上で、オンボーディングボタン４０をクリックすると、当該バンドルファイルがオンボーディングされる。
　以上のようにして本実施形態では、ベンダは、開発したファイル群がオンボーディングされる実際のロケーションを意識することなく、ネットワークサービスのオンボーディングを簡単に行うことができる。
　以下、本実施形態に係るＭＰＳ１０及びＮＯＳ１２の機能、及び、ＭＰＳ１０及びＮＯＳ１２で実行される処理について、さらに説明する。
　図１０は、本実施形態に係るＭＰＳ１０及びＮＯＳ１２で実装される機能の一例を示す機能ブロック図である。本明細書のブロック図で示す複数の機能ブロックは、ハードウェア的には、回路ブロック、メモリ、その他のＬＳＩで構成することができ、ソフトウェア的には、メモリにロードされたプログラムをＣＰＵが実行すること等により実現される。したがって、これらの機能ブロックがハードウェアのみ、ソフトウェアのみ、またはそれらの組合せによっていろいろな形で実現できることは当業者には理解されるところである。なお、本実施形態に係るＭＰＳ１０及びＮＯＳ１２で、図１０に示す機能のすべてが実装される必要はなく、また、図１０に示す機能以外の機能が実装されていても構わない。
　図１０に示すように、ＭＰＳ１０には、機能的には例えば、バンドル管理部５０、プロダクトカタログ記憶部５２、購入管理部５４、が含まれる。
　バンドル管理部５０、購入管理部５４は、プロセッサ１０ａ及び通信部１０ｃを主として実装される。プロダクトカタログ記憶部５２は、記憶部１０ｂを主として実装される。
　以上の機能は、コンピュータであるＭＰＳ１０にインストールされた、以上の機能に対応する指令を含むプログラムをプロセッサ１０ａで実行することにより実装されてもよい。このプログラムは、例えば、光ディスク、磁気ディスク、磁気テープ、光磁気ディスク、フラッシュメモリ等のコンピュータ読み取り可能な情報記憶媒体を介して、あるいは、インターネットなどを介してＭＰＳ１０に供給されてもよい。
　また、図１０に示すように、ＮＯＳ１２には、機能的には例えば、バンドル展開部６０、オーケストレーション（Ｅ２ＥＯ：End-to-End-Orchestration）部６２、サービスカタログ記憶部６４、インベントリ管理部６６、ＣＭａａＳ（Configuration Management as a Service）部６８、サービスマネージャ部７０、スライスマネージャ部７２、監視管理部７４、セキュリティ設定部７６、複数のコンテナ管理部７８、リポジトリ部８０、インベントリデータベース８２、ＢＭａａＳ（Bare Metal as a Service）部８４、が含まれる。
　バンドル展開部６０、Ｅ２ＥＯ部６２は、プロセッサ１２ａ及び通信部１２ｃを主として実装される。サービスカタログ記憶部６４、リポジトリ部８０、インベントリデータベース８２は、記憶部１２ｂを主として実装される。インベントリ管理部６６、ＣＭａａＳ部６８、サービスマネージャ部７０、スライスマネージャ部７２、監視管理部７４、セキュリティ設定部７６、コンテナ管理部７８は、プロセッサ１２ａ及び記憶部１２ｂを主として実装される。ＢＭａａＳ部８４は、プロセッサ１２ａを主として実装される。
　以上の機能は、コンピュータであるＮＯＳ１２にインストールされた、以上の機能に対応する指令を含むプログラムをプロセッサ１２ａで実行することにより実装されてもよい。このプログラムは、例えば、光ディスク、磁気ディスク、磁気テープ、光磁気ディスク、フラッシュメモリ等のコンピュータ読み取り可能な情報記憶媒体を介して、あるいは、インターネットなどを介してＮＯＳ１２に供給されてもよい。
　また、図１０には、図１に示す、コアネットワークシステム２０、及び、基地局装置２２に含まれる、様々なロケーションに分散配置された複数のサーバ９０についても示されている。そして、本実施形態に係る複数のコンテナ管理部７８は、それぞれ、これら複数のサーバ９０のうちの一部であるサーバ群に対応付けられている。
　本実施形態に係る複数のコンテナ管理部７８のそれぞれには、例えば、クバネテス（Ｋｕｂｅｒｎｅｔｅｓ）等のコンテナ管理ツール、及び、ヘルム（Ｈｅｌｍ）等のパッケージマネージャがインストールされている。そして、コンテナ管理部７８は、当該コンテナ管理部７８に対応付けられているサーバ群（複数のサーバ９０）に対してコンテナのデプロイや設定などといったコンテナの構築を含む、コンテナのライフサイクル管理を実行する。
　なお、コンテナ管理部７８は、ＮＯＳ１２に含まれている必要はない。コンテナ管理部７８は、例えば、当該コンテナ管理部７８によって管理されるサーバ９０（すなわち、コアネットワークシステム２０や基地局装置２２）、あるいは、当該サーバ９０に併設されているサーバに設けられていてもよい。
　バンドル展開部６０は、本実施形態では例えば、バンドルファイルをベンダ端末１６から受け付ける。そして、バンドル展開部６０は、本実施形態では例えば、受け付けたバンドルファイルに基づいて、図１１にデータ構造が示されているデータ群を生成する。図１１に示すデータ群は、バンドル展開部６０が受け付けたバンドルファイルの内容を再構成したものとなっている。
　図１１に示すように、バンドル展開部６０によって生成されるデータ群には、プロダクトカタログデータ、サービスカタログデータ、インベントリテンプレートデータ、ＣＭテンプレートデータ、サービステンプレートデータ、スライステンプレートデータ、監視スクリプトデータ、セキュリティスクリプトデータ、ヘルムチャートデータ、及び、コンテナイメージデータが含まれる。
　プロダクトカタログデータは、例えば、バンドルファイルに含まれるビジネスセクションデータに対応するデータである。プロダクトカタログデータには、上述したように、図２に示す購入画面に表示されるネットワークサービスの名称、ライセンス要件、サービスレベルアグリーメント（ＳＬＡ）の定義など、ネットワークサービスのビジネス要件に関する情報が示されている。
　また、本実施形態に係るプロダクトカタログデータには、ネットワークサービスのサービス要件についての必須の入力項目やオプションの入力項目を示すデータが含まれている。本実施形態では、例えば、プロダクトカタログデータに基づいて、図２に示す購入画面、及び、図３に示すサービス要件入力画面が生成される。
　サービスカタログデータは、例えば、バンドルファイルに含まれるテクノロジーセクションデータの一部に対応するデータである。サービスカタログデータには、ネットワークサービスを構築するためのワークフローのスクリプトが含まれている。
　また、サービスカタログデータに、上述のサービス要件データの値と、購入要求に応じて構築される機能ユニット群（例えば、ＣＮＦＣ群）の構成との対応を示す要件構成対応データが含まれていてもよい。
　例えば、サービスカタログデータに、サービス要件データの値と、機能ユニット群の種類並びに各種類についての機能ユニットの数との対応を示す要件構成対応データが含まれていてもよい。例えば、要件構成対応データに、「加入者数２００００と１つのＰ－ＧＷ（Packet Data Network Gateway）」、「加入者数２００００と１つのＩＭＳ（IP Multimedia System）」、「加入者数２００００と１つのＨＳＳ（Home Subscriber Server）」が対応することが示されていてもよい。なお、サービス要件データと対応付けられるのは４Ｇの構成要素の種類や数には限定されず、サービス要件データと５Ｇの構成要素の種類や数とが対応付けられていてもよい。
　また、例えば、要件構成対応データに、サービス要件データの値と、購入要求に応じて構築される機能ユニット群に含まれる各機能ユニットが構築されるロケーションとの対応が示されていてもよい。この場合、要件構成対応データにおいてサービス要件データの値と対応付けられているロケーションは、構築される機能ユニット群に含まれる機能ユニットによって異なっていてもよい。
　インベントリテンプレートデータは、例えば、バンドルファイルに含まれるテクノロジーセクションデータの一部及びセキュリティセクションデータの一部に対応するデータである。インベントリテンプレートデータは、例えば、インベントリ管理部６６によって利用されるロジックを示すテンプレートデータである。
　ＣＭテンプレートデータは、例えば、バンドルファイルに含まれるテクノロジーセクションデータの一部及びオペレーションセクションデータの一部に対応するデータであり、例えば、ＣＭａａＳ部６８によって利用されるロジックを示すテンプレートデータである。
　サービステンプレートデータは、例えば、バンドルファイルに含まれるテクノロジーセクションデータの一部に対応するデータであり、例えば、サービスマネージャ部７０によって利用されるロジックを示すテンプレートデータである。サービステンプレートデータは、サービスマネージャ部７０がネットワークサービスを構築するために必要な情報を含む。具体的には、サービステンプレートデータは、図７に示したネットワーク階層データのうち、少なくともサービスマネージャ部７０が構築すべきＮＳ、ＣＮＦおよびＣＮＦＣを定義する情報と、ＮＳ－ＣＮＦ－ＣＮＦＣの対応関係を示す情報を含む。
　スライステンプレートデータは、例えば、バンドルファイルに含まれるテクノロジーセクションデータの一部に対応するデータであり、例えば、スライスマネージャ部７２によって利用されるロジックを示すテンプレートデータである。
　スライステンプレートデータは、ＧＳＭＡ（GSM Association）（「GSM」は登録商標）が定める「Generic Network Slice Template」の情報を含む。具体的には、スライステンプレートデータは、ネットワークスライスのテンプレートデータ（ＮＳＴ）、ネットワークスライスサブネットのテンプレートデータ（ＮＳＳＴ）、ネットワークサービスのテンプレートデータを含み、また、これらのネットワーク要素の階層構成を示す情報（例えば上記のネットワーク階層データ）を含む。ＮＳＴとＮＳＳＴは、ネットワークスライスインスタンス（ＮＳＩ）やネットワークスライスサブネットインスタンス（ＮＳＳＩ）に関するＳＬＡの情報を含む。
　上記のＳＬＡの情報は、監視対象のメトリックデータをもとにＮＳＩやＮＳＳＩに関する１つ以上のＫＰＩ（Key Performance Indicator）と、各ＫＰＩを算出するための計算ロジックを含む。また、ＳＬＡの情報は、監視時に用いる閾値や、算出したＫＰＩと比較する閾値（例えば異常検出用閾値）に関する情報を含む。
　監視スクリプトデータは、例えば、バンドルファイルに含まれるオペレーションセクションデータの一部に対応するデータであり、例えば、監視管理部７４によって実行される監視スクリプトを示すデータである。
　セキュリティスクリプトデータは、例えば、バンドルファイルに含まれるセキュリティセクションデータの一部に対応するデータであり、例えば、セキュリティ設定部７６によって実行されるセキュリティに関するスクリプトを示すデータである。
　ヘルムチャートデータは、例えば、バンドルファイルに含まれるオペレーションセクションデータの一部に対応するデータであり、コンテナ管理部７８によって利用されるスクリプトテンプレート（ヘルムチャート）を示すデータである。
　コンテナイメージデータは、例えば、バンドルファイルに含まれるオペレーションセクションデータの一部に対応するデータであり、例えば、ネットワークサービスを実現する機能ユニット群に含まれるコンテナについてのコンテナイメージのデータである。コンテナイメージデータには、１又は複数のコンテナイメージが含まれる。これら１又は複数のコンテナイメージのそれぞれには、当該コンテナイメージの識別子であるコンテナイメージＩＤが関連付けられている。
　本実施形態では、バンドル展開部６０は、バンドルファイルの受付に応じて、当該バンドルファイルに基づいて生成されるデータ群に対応するバンドルＩＤを決定する。バンド
ルＩＤは、生成されるデータ群ごとに一意に割り当てられる。
　そして、バンドル展開部６０は、当該バンドルＩＤに対応するデータ群に含まれるプロダクトカタログデータを、決定されるバンドルＩＤに関連付けた上で、ＭＰＳ１０に送信する。
　また、バンドル展開部６０は、当該データ群に含まれるサービスカタログデータを、決定されるバンドルＩＤに関連付けた上で、Ｅ２ＥＯ部６２に出力する。すると、Ｅ２ＥＯ部６２は、当該サービスカタログデータをサービスカタログ記憶部６４に記憶させる。
　また、バンドル展開部６０は、インベントリテンプレートデータ、ＣＭテンプレートデータ、サービステンプレートデータ、スライステンプレートデータ、監視スクリプトデータ、セキュリティスクリプトデータ、ヘルムチャートデータ、及び、コンテナイメージデータを、当該データ群に対応するバンドルＩＤに関連付けた上で、それぞれ、インベントリ管理部６６、ＣＭａａＳ部６８、サービスマネージャ部７０、スライスマネージャ部７２、監視管理部７４、セキュリティ設定部７６、コンテナ管理部７８、及び、リポジトリ部８０に記憶させる。
　このようにして、本実施形態ではバンドルＩＤによって、プロダクトカタログデータ、サービスカタログデータ、インベントリテンプレートデータ、ＣＭテンプレートデータ、サービステンプレートデータ、スライステンプレートデータ、監視スクリプトデータ、セキュリティスクリプトデータ、ヘルムチャートデータ、及び、コンテナイメージデータが互いに関連付けられることとなる。
　また、本実施形態では、ベンダは、バンドルファイルのパスの指定などの簡単な操作によって簡単にネットワークサービスを提供することが可能である。
　バンドル管理部５０は、本実施形態では例えば、バンドル展開部６０から送信される、バンドルＩＤに関連付けられたプロダクトカタログデータを受信する。そして、バンドル管理部５０は、受信したプロダクトカタログデータをプロダクトカタログ記憶部５２に記憶させる。
　プロダクトカタログ記憶部５２は、本実施形態では例えば、上述のように、バンドルＩＤに関連付けられたプロダクトカタログデータを記憶する。
　購入管理部５４は、本実施形態では例えば、購入者端末１４から、バンドルＩＤ、及び、サービス要件データに関連付けられた、ネットワークサービスの購入要求などといったネットワークサービスの構築要求を受け付ける。以下、購入要求に関連付けられているバンドルＩＤを購入バンドルＩＤと呼び、購入要求に関連付けられているサービス要件データを購入サービス要件データと呼ぶこととする。
　そして、購入管理部５４は、上述の購入要求の受付に応じて、当該購入バンドルＩＤに関連付けられた当該購入サービス要件データをＥ２ＥＯ部６２に送信する。
　また、購入管理部５４は、Ｅ２ＥＯ部６２及びインベントリ管理部６６と連携して、購入者が購入するネットワークサービスの納期を特定する。そして、購入管理部５４は、特定される納期を購入者に通知する。購入管理部５４は、例えば、特定される納期が示された購入確認画面を生成して、生成される購入確認画面を購入者端末１４に送信する。
　インベントリデータベース８２は、本実施形態では例えば、ＮＯＳ１２で管理されている、コアネットワークシステム２０や基地局装置２２に配置されている複数のサーバ９０についてのインベントリ情報が格納されたデータベースである。
　本実施形態では例えば、インベントリデータベース８２には、図１２に示す物理インベントリデータ、及び、図１３に示す論理インベントリデータを含む、インベントリデータが記憶されている。インベントリデータには、ＮＯＳ１２で管理されているリソースの状況（例えば、リソースの使用状況）が示されている。
　図１２は、物理インベントリデータのデータ構造の一例を示す図である。図１２に示す物理インベントリデータは、１つのサーバ９０に対応付けられる。図１２に示す物理インベントリデータには、例えば、サーバＩＤ、ロケーションデータ、建物データ、階数データ、ラックデータ、割り当てリソースプール群ＩＤ、割り当てリソースプールＩＤ、スペックデータ、ネットワークデータ、稼働コンテナＩＤリスト、などが含まれる。
　物理インベントリデータに含まれるサーバＩＤは、例えば、当該物理インベントリデータに対応付けられるサーバ９０の識別子である。
　物理インベントリデータに含まれるロケーションデータは、例えば、当該物理インベントリデータに対応付けられるサーバ９０のロケーション（例えばロケーションの住所）を示すデータである。
　物理インベントリデータに含まれる建物データは、例えば、当該物理インベントリデータに対応付けられるサーバ９０が配置されている建物（例えば建物名）を示すデータである。
　物理インベントリデータに含まれる階数データは、例えば、当該物理インベントリデータに対応付けられるサーバ９０が配置されている階数を示すデータである。
　物理インベントリデータに含まれるラックデータは、例えば、当該物理インベントリデータに対応付けられるサーバ９０が配置されているラックの識別子である。
　物理インベントリデータに含まれる割り当てリソースプール群ＩＤは、例えば、当該物理インベントリデータに対応付けられるサーバ９０が割り当てられているリソースプール群の識別子である。
　物理インベントリデータに含まれる割り当てリソースプールＩＤは、例えば、当該物理インベントリデータに対応付けられるサーバ９０が割り当てられているリソースプールの識別子である。割り当てリソースプールＩＤが示すリソースプールは、割り当てリソースプール群ＩＤに対応するリソースプール群に含まれるいずれかのリソースプールである。なお、本実施形態では、空きサーバは、いずれかのリソースプール群に割り当てられるが、当該空きサーバが当該リソースプール群に含まれるどのリソースプールに割り当てられるかは未決定である。このような空きサーバについては、対応する物理インベントリデータに含まれる割り当てリソースプールＩＤの値としてＮｕｌｌが設定される。
　物理インベントリデータに含まれるスペックデータは、例えば、当該物理インベントリデータに対応付けられるサーバ９０のコア数、メモリ容量、ハードディスク容量、などといった、当該サーバ９０のスペックを示すデータである。
　物理インベントリデータに含まれるネットワークデータは、例えば、当該物理インベントリデータに対応付けられるサーバ９０が備えるＮＩＣや当該ＮＩＣが備えるポート数などを示すデータである。
　物理インベントリデータに含まれる稼働コンテナＩＤリストは、例えば、当該物理インベントリデータに対応付けられるサーバ９０で稼働する１又は複数のコンテナのインスタンスの識別子（コンテナＩＤ）のリストを示すデータである。
　図１３は、論理インベントリデータのデータ構造の一例を模式的に示す図である。図１３に示すように、論理インベントリデータには、ＮＳ（Network Service）データ、ＣＮＦ（Cloud-native Network Function）データ、ＣＮＦＣデータ、ｐｏｄデータ、及び、コンテナデータが含まれている。
　ＮＳデータは、例えばｖＲＡＮ（virtual RAN）などに相当するネットワークサービス
のインスタンスの識別子や当該ネットワークサービスの種類等の属性を示すデータである。ＣＮＦデータは、例えばｅＮｏｄｅＢなどに相当するネットワークファンクションのインスタンスの識別子や当該ネットワークファンクション種類等の属性を示すデータである。ＣＮＦＣデータは、例えばｖＣＵやｖＤＵなどに相当する、ＣＮＦＣのインスタンスの識別子や当該ＣＮＦＣの種類等の属性を示すデータである。ｐｏｄデータは、ＣＮＦＣに含まれるｐｏｄのインスタンスの識別子や当該ｐｏｄの種類等の属性を示すデータである。ここで、ｐｏｄとは、クバネテスでドッカーコンテナを管理するための最小単位を指す。コンテナデータは、ｐｏｄに含まれるコンテナのインスタンスのコンテナＩＤや当該コンテナの種類等の属性を示すデータである。
　なお、ホスト名やＩＰアドレスなどの属性を示すデータが論理インベントリデータに含まれる上述のデータに設定されていても構わない。例えば、コンテナデータに、当該コンテナデータに対応するコンテナのＩＰアドレスを示すデータが含まれていてもよい。また、例えば、ＣＮＦＣデータに、当該ＣＮＦＣデータが示すＣＮＦＣのＩＰアドレス及びホスト名を示すデータが含まれていてもよい。
　上述のデータは階層構造になっており、ＮＳデータは、当該ＮＳデータに対応するネットワークサービスに含まれる１又は複数のネットワークファンクションのそれぞれに対応する１又は複数のＣＮＦデータと関連付けられている。また、ＣＮＦデータは、当該ＣＮＦデータに対応するネットワークファンクションに含まれる１又は複数のＣＮＦＣのそれぞれに対応する１又は複数のＣＮＦＣデータと関連付けられている。また、ＣＮＦＣデータは、当該ＣＮＦＣデータに対応するＣＮＦＣに含まれる１又は複数のｐｏｄのそれぞれに対応する１又は複数のｐｏｄデータと関連付けられている。また、ｐｏｄデータは、当該ｐｏｄデータに対応するｐｏｄに含まれる１又は複数のコンテナのそれぞれに対応する１又は複数のコンテナデータと関連付けられている。
　論理インベントリデータに含まれるコンテナデータのコンテナＩＤと、物理インベントリデータに含まれる稼働コンテナＩＤリストに含まれるコンテナＩＤと、によって、コンテナのインスタンスと、当該コンテナのインスタンスが稼働しているサーバ９０とが関連付けられることとなる。
　なお、本実施形態において購入者が購入するネットワークサービス（プロダクトカタログデータに対応付けられるネットワークサービス）は、ＮＳデータに対応付けられるネットワークサービスに相当するものである必要はない。例えば、購入者が購入するネットワークサービスが、１又は複数のＣＮＦデータに対応付けられるネットワークファンクションに相当する機能ユニット群によって実現されるものであっても構わないし、１又は複数のＣＮＦＣデータに対応付けられる機能ユニット群によって実現されるものであっても構わない。また、購入者に購入されるネットワークサービスが、１又は複数のｐｏｄに対応付けられる機能ユニット群によって実現されるものであっても構わないし、１又は複数のコンテナに対応付けられる機能ユニット群によって実現されるものであっても構わない。
　また、図１３に示すように、本実施形態に係る論理インベントリデータには、それぞれリソースプール群に対応付けられる複数のリソースプール管理データが含まれる。
　図１４は、本実施形態に係るリソースプール管理データの一例を示す図である。リソースプール管理データは、当該リソースプール管理データに対応付けられるリソースプール群に含まれる複数のリソースプールの状況が示されている。
　図１４に示すリソースプール管理データには、リソースプール群ＩＤ、複数のリソースプールデータ、及び、空きサーバ数データが含まれる。
　リソースプール管理データに含まれるリソースプール群ＩＤは、当該リソースプール管理データに対応付けられるリソースプール群の識別子である。
　リソースプール管理データに含まれる空きサーバ数データは、当該リソースプール管理データに対応付けられるリソースプール群に割り当てられた空きサーバ数を示すデータである。
　リソースプールデータは、リソースプール管理データに対応付けられるリソースプール群に含まれるリソースプールの状況を示すデータである。
　図１４に示すように、リソースプールデータには、リソースプールＩＤ、総コア数データ、残りコア数データ、ＣＮＦＣ種類データが含まれる。
　リソースプールＩＤは、リソースプールの識別子である。
　総コア数データは、当該リソースプールに割り当てられたサーバ９０の総コア数を示すデータである。総コア数データは、当該リソースプールに含まれるハードウェアリソースの総量を示すリソース総量データの一具体例である。
　残りコア数データは、当該リソースプールに割り当てられたサーバ９０の残りコア数を示すデータである。残りコア数データは、当該リソースプールに含まれるハードウェアリソースの残量を示すリソース残量データの一具体例である。
　また、ＣＮＦＣ種類データは、当該リソースプールに関連付けられた１種類以上のＣＮＦＣの種類を示すデータである。ＣＮＦＣ種類データは、当該リソースプールに関連付けられた１種類以上の種類の機能ユニットを示す機能ユニット種類データの一具体例である。
　本実施形態では、複数のロケーションにまたがるリソースプール群が予め設定されてもよいし、１つのロケーションだけに対応付けられるリソースプール群が予め設定されていてもよい。いずれの場合も、リソースプール群は、物理インベントリデータに示されている１又は複数のロケーションに対応付けられることとなる。
　また、インベントリ管理部６６は、コンテナ管理部７８と連携して、リソースの状況を適宜把握できるようになっている。そして、インベントリ管理部６６は、リソースの最新の状況に基づいて、インベントリデータベース８２に記憶されているインベントリデータを適宜更新する。
　Ｅ２ＥＯ部６２及びインベントリ管理部６６は、本実施形態では例えば、購入管理部５４から受信するサービス要件データに基づいて、購入されるネットワークサービスを実現する機能ユニット群の構成を特定する。
　ここで、Ｅ２ＥＯ部６２は、例えば、購入管理部５４から受信する購入サービス要件データに関連付けられている購入バンドルＩＤに対応するサービスカタログデータをサービスカタログ記憶部６４から取得する。そして、Ｅ２ＥＯ部６２は、当該サービスカタログデータが示すワークフローのスクリプトを実行する。
　Ｅ２ＥＯ部６２及びインベントリ管理部６６は、購入管理部５４から受信する購入サービス要件データ、購入バンドルＩＤに関連付けられているサービスカタログデータ、購入バンドルＩＤに関連付けられているインベントリテンプレートデータ、及び、インベントリデータに基づいて、図１５及び図１６に例示する計画データ（ｐｌａｎｎｅｄ　ｄａｔａ）を生成する。計画データは例えば、購入されるネットワークサービスを実現する機能ユニット群の構成を示すデータである。この処理は、例えば、Ｅ２ＥＯ部６２によるワークフローのスクリプトの実行をトリガとして実行される。
　図１５は、本実施形態に係る計画データのデータ構造の一例を示す図である。図１６は、本実施形態に係る計画データの一例を模式的に示す図である。本実施形態に係る計画データには、計画データの識別子であるインベントリキーが含まれる。インベントリキーは、計画データが生成される際に、当該計画データに一意に割り当てられる。また、計画データには、購入バンドルＩＤが含まれる（図１６の例では「００１０」）。また、計画データには、購入要求を行った購入者（ユーザ）の識別子であるユーザＩＤが含まれる。
　また、計画データに、購入サービス要件データに設定されている値が含まれていてもよい。図１５及び図１６に示す計画データには、購入サービス要件データに含まれる、対向ＩＰデータの値、監視対象データの値、監視間隔データの値、及び、パスワードデータの値が含まれている。
　そして、本実施形態では、計画データには、購入されるネットワークサービスを実現する機能ユニット群に含まれる機能ユニットのそれぞれについての機能ユニット構成データが含まれる。機能ユニット構成データには、例えば、当該機能ユニットの種類を示すＣＮＦＣ種類データ、ホスト名を示すホスト名データ、ＩＰアドレスを示すＩＰアドレスデータ、当該機能ユニットを構成するコンテナにそれぞれ対応付けられる複数のコンテナ構成データ、が含まれる。
　ここで例えば、Ｅ２ＥＯ部６２が、購入サービス要件データに基づいて、構築される機能ユニット群の数を特定してもよい。例えば、Ｅ２ＥＯ部６２が、購入サービス要件データとサービスカタログデータに含まれる要件構成対応データとに基づいて、購入されるネットワークサービスを実現する機能ユニット群の種類並びに各種類についての機能ユニットの数を特定してもよい。例えば、サービス要件データが示す加入者数が５００００である場合に、上述の要件構成対応データに基づいて、構築される機能ユニット群が、３個のＰ－ＧＷ、３個のＩＭＳ、及び、３個のＨＳＳであると特定されてもよい。
　そして、Ｅ２ＥＯ部６２が、サービス要件データとともに、機能ユニット群の種類並びに各種類についての機能ユニットの数を示すデータをインベントリ管理部６６に出力してもよい。そして、インベントリ管理部６６が、当該データと、インベントリデータと、に基づいて、各機能ユニットに割り当てられるホスト名およびＩＰアドレスを決定してもよい。ここで例えば、既に使用されているホスト名やＩＰアドレスと重複しないようホスト名やＩＰアドレスが決定されてもよい。そして、このようにして決定されるホスト名を示
すホスト名データ、及び、決定されるＩＰアドレスを示すＩＰアドレスデータを含む計画データが生成されてもよい。
　また、上述のように、Ｅ２ＥＯ部６２が、購入サービス要件データに基づいて、構築される機能ユニット群に含まれる機能ユニットのそれぞれが構築されるロケーションを特定してもよい。例えば、Ｅ２ＥＯ部６２が、購入サービス要件データに含まれる対象地域データとサービスカタログデータに含まれる要件構成対応データとに基づいて、構築される機能ユニット群に含まれる各機能ユニットのロケーションを決定してもよい。ここで各機能ユニットについて異なるロケーションが決定されてもよい。そして、各機能ユニットについて、当該機能ユニットについて決定されるロケーションにおいて利用可能なホスト名やＩＰアドレスが、当該機能ユニットのホスト名及びＩＰアドレスとして決定されてもよい。そして、このようにして決定されるホスト名を示すホスト名データ、及び、決定されるＩＰアドレスを示すＩＰアドレスデータを含む計画データが生成されてもよい。
　また、Ｅ２ＥＯ部６２が、購入サービス要件データに基づいて、複数のロケーションのそれぞれについて、当該ロケーションに構築される機能ユニットの種類及び数を特定してもよい。この場合、Ｅ２ＥＯ部６２が、購入サービス要件データに基づいて特定されるロケーションに応じて、当該ロケーションに構築される、それぞれの種類の機能ユニットの数を決定してもよい。また、Ｅ２ＥＯ部６２が、購入サービス要件データに基づいて特定されるロケーション毎に設定されている重みに基づいて、ロケーション毎に構築される、それぞれの種類の機能ユニットの数を決定してもよい。
　例えば、Ｅ２ＥＯ部６２に、図１７に示す想定ビジーレベルデータが記憶されていてもよい。図１７に示す想定ビジーレベルデータには、例えば、当該想定ビジーレベルデータに関連付けられているデータセンタの配下の１又は複数のセルがカバーするエリアの人口が示されている。想定ビジーレベルデータの値は、上述したロケーション毎に設定されている重みの一例である。
　ここで、コアネットワークシステム２０のデータセンタについての想定ビジーレベルデータには、例えば、当該コアネットワークシステム２０と通信する１又は複数の基地局装置２２のセルがカバーするエリアの人口が示される。
　そして、例えば、想定ビジーレベルデータが示す人口が高いロケーションであるほど多くの機能ユニットがデプロイされるようにしてもよい。例えば、購入サービス要件データに含まれる加入者数データに基づいて、デプロイされるｖＤＵの総数ｎが特定されるとする。そして、購入サービス要件データに含まれる対象地域データに基づいて、当該対象地域データが示す対象地域内にある、ｖＤＵのデプロイ先である複数のデータセンタが特定されるとする。この場合、特定された各データセンタについての想定ビジーレベルデータの値に基づいて、特定されたｖＤＵの総数ｎを按分した数のｖＤＵが各データセンタにデプロイされるようにしてもよい。
　図１５に示すように、コンテナ構成データには、例えば、コンテナＩＤ、コンテナイメージＩＤ、必要リソースデータ、リソースプール群ＩＤ、リソースプールＩＤ、及び、接続コンテナＩＤリストが含まれる。
　コンテナＩＤは、例えば、上述したように、当該コンテナ構成データに対応するコンテナのインスタンスに一意に割り当てられる識別子である。
　コンテナ構成データに含まれるコンテナイメージＩＤには、例えば、当該コンテナ構成データに対応するコンテナのコンテナイメージに割り当てられているコンテナイメージＩＤが設定される。
　必要リソースデータは、例えば、当該コンテナの稼働に必要なリソースを示すデータである。本実施形態では例えば、インベントリテンプレートデータに、各コンテナについて、当該コンテナの稼働に必要なリソースが示されている。インベントリ管理部６６は、インベントリテンプレートデータに基づいて、必要リソースデータの値を設定する。
　コンテナ構成データに含まれるリソースプール群ＩＤには、例えば、当該コンテナ構成データに対応するコンテナが割り当てられるリソースプール群のリソースプール群ＩＤの値が設定される。インベントリ管理部６６は、例えば、上述のようにして決定されるロケーションと、インベントリデータと、に基づいて、当該コンテナが構築されるリソースプール群ＩＤを決定してもよい。
　コンテナ構成データに含まれるリソースプールＩＤには、例えば、当該コンテナ構成データに対応するコンテナが割り当てられるリソースプールのリソースプールＩＤの値が設定される。インベントリ管理部６６は、例えば、当該コンテナの種類と、リソースプール管理データと、に基づいて、リソースプールＩＤを決定してもよい。
　接続コンテナＩＤリストは、当該コンテナと接続されるコンテナのコンテナＩＤのリストである。本実施形態では例えば、インベントリテンプレートデータに、各コンテナについて、当該コンテナと接続されるコンテナの種類が示されている。インベントリ管理部６６は、例えば、インベントリテンプレートデータと、インベントリデータと、に基づいて、接続コンテナＩＤリストの値を決定する。
　計画データを生成する際には、Ｅ２ＥＯ部６２は、インベントリ管理部６６と連携して、新規の機能ユニット群がデプロイされるリソースプール、及び、必要なリソースを特定する。ここで、Ｅ２ＥＯ部６２は、購入要求の受付などといった、ネットワークサービスの構築要求の受付に応じて特定される機能ユニットに関連付けられているリソースプールを特定してもよい。また、Ｅ２ＥＯ部６２は、購入されるネットワークサービスの対象地域に基づいて、リソースプール群を特定してもよい。例えば、購入サービス要件データに含まれる対象地域データが示す対象地域に基づいて、リソースプール群が特定されてもよい。そして、Ｅ２ＥＯ部６２は、特定されたリソースプール群に含まれるリソースプールのうちから、新規の機能ユニット群がデプロイされるリソースプールを特定してもよい。
　また、Ｅ２ＥＯ部６２は、新規の機能ユニット群がデプロイされるハードウェアリソース（ここでは例えばサーバ９０）を確保可能であるか否かを判定する。ここでは例えば、（１）サーバ９０の確保が可能である、（２）いずれのリソースプールにも含まれていない未使用ハードウェアリソース（ここでは例えば空きサーバ）のセットアップを行うことでサーバ９０の確保が可能である、（３）サーバ９０の確保が不可能である、のいずれであるかが判定される。
　ここで、（２）である場合は、Ｅ２ＥＯ部６２は、未使用ハードウェアリソース（ここでは例えば空きサーバ）に、予め定められた特定種類の機能ユニットがデプロイされるか否かを判定する。
　そして、特定種類の機能ユニットがデプロイされる場合は、Ｅ２ＥＯ部６２は、当該特定種類の機能ユニットに関連付けられているリソースプールを特定する。ここで例えば、リソースプール管理データに基づいて、当該リソースプールが特定される。
　本実施形態では例えば、以上のようにして特定されるリソースプール群のリソースプール群ＩＤ、及び、特定されるリソースプールのリソースプールＩＤが、コンテナ構成データに設定される。
　ＣＭａａＳ部６８、サービスマネージャ部７０、及び、スライスマネージャ部７２は、本実施形態では例えば、上述のようにして特定される機能ユニット群の構成と、当該構成をパラメータとして受け入れ可能なテンプレートデータと、に基づいて、当該機能ユニット群の構築手順を特定する。当該構築手順には、例えば、コンテナのデプロイ、及び、デプロイされたコンテナ及び当該コンテナに関係するコンテナの設定等のコンテナの構成管理の手順が含まれる。この処理は、例えば、Ｅ２ＥＯ部６２によるワークフローのスクリプトの実行をトリガとして実行される。
　そして、ＣＭａａＳ部６８、サービスマネージャ部７０、スライスマネージャ部７２、及び、コンテナ管理部７８は、特定される構築手順を実行することで、機能ユニット群を構築する。この処理も、例えば、Ｅ２ＥＯ部６２によるワークフローのスクリプトの実行をトリガとして実行される。
　なお、機能ユニット群に含まれる機能ユニットのそれぞれが、当該機能ユニットについて特定されるロケーションに構築されてもよい。
　また例えば、購入サービス要件データに基づいて特定される数の機能ユニット群が構築されてもよい。
　また例えば、複数のロケーションのそれぞれについて、当該ロケーションについて特定される種類の機能ユニットが、特定される数だけ構築されるようにしてもよい。
　ここで、ＣＭａａＳ部６８及びＢＭａａＳ部８４は、例えば、新規の機能ユニット群がデプロイされるハードウェアリソース（ここでは例えばサーバ９０）を確保する。
　また、ＣＭａａＳ部６８及びＢＭａａＳ部８４は、特定種類の機能ユニットに応じたシステムソフトウェアのセットアップを、未使用ハードウェアリソースに施す。本実施形態では例えば、ＣＭａａＳ部６８又はＢＭａａＳ部８４に上述の特定種類の機能ユニットについてのセットアップを行うためのスクリプト（例えば、Ａｎｓｉｂｌｅスクリプト）が記憶されている。当該スクリプトには、例えば、特定種類あるいは特定バージョンである、コンテナ実行環境の基盤であるホストＯＳのインストール手順、ホストＯＳのカーネルの設定手順、ＢＩＯＳ（Basic Input Output System）の設定手順、などが記述されている。そして、ＢＭａａＳ部８４が、当該スクリプトを実行することにより、特定種類の機能ユニットに応じたシステムソフトウェアのセットアップが、空きサーバに施される。例えば、コンテナ実行環境のホストＯＳやＢＩＯＳのセットアップが、空きサーバに施される。
　そして、ＣＭａａＳ部６８及びＢＭａａＳ部８４は、リソースプール管理データを更新して、システムソフトウェアのセットアップが施された未使用ハードウェアリソースを、特定されるリソースプールに追加する。このようなリソースプールへのハードウェアリソースの追加は当該ハードウェアリソースを管理するコンテナ管理部７８によって検出される。そして、インベントリ管理部６６が、追加されたハードウェアリソース（サーバ９０）に対応するインベントリデータを更新される。このようにして、当該リソースプールには、特定種類の機能ユニットに応じたシステムソフトウェアのセットアップが施されたハードウェアリソースが含まれることとなる。
　ここでは例えば、ｖＤＵが特定種類の機能ユニットであることとする。また、ｖＤＵに必要なコア数が５つであり、空きサーバのコア数が５０であるとする。
　この場合において、ｖＤＵを含むネットワークサービスが購入される際に、ｖＤＵに関連付けられたリソースプールが特定される。図１４の例では、リソースプールＩＤがＣであるリソースプールが特定される。そして、このリソースプールの残りハードウェアリソースが充分であるか否かが確認される。そして、残りハードウェアリソースが不足している場合は、１つの空きサーバに対して、ｖＤＵに応じたシステムソフトウェアのセットアップが施される。そして、システムソフトウェアのセットアップがされたサーバ９０が、リソースプールＣに追加され、リソースプール管理データは、図１８に示すものに更新される。
　このようにして、本実施形態では、リソースプールデータに対応するリソースプールに含まれるハードウェアリソースには、当該リソースプールに関連付けられている１種類以上の種類の機能ユニットに応じたシステムソフトウェアのセットアップが施されることとなる。
　機能ユニットの種類によっては一般的な構成の汎用サーバでは充分な性能が発揮できないことがある。そこで、このような特定種類の機能ユニットのために、ホストＯＳやＢＩＯＳ等のシステムソフトウェアについて、専用のセットアップをサーバ等のハードウェアリソースに施すことが望ましい。この場合、そうした専用のシステムソフトウェアのセットアップが施されたハードウェアリソースをネットワークサービスの提供開始前に所要数だけ予め準備しておき、必要時には、準備されたハードウェアリソースに当該機能ユニットをデプロイすることが考えられる。
　ところが、特定種類の機能ユニットに応じたシステムソフトウェアのセットアップを事前に施すべきハードウェアリソースの最適量をネットワークサービスの提供開始前に見積もることは困難である。また、余裕をもって多くのハードウェアリソースに対して特定種類の機能ユニットに応じたシステムソフトウェアのセットアップを施してしまうと、このようなハードウェアリソースは他の機能ユニットのデプロイには適さないため、リソースの無駄が発生する。
　本実施形態では、上述のようにして、特定種類の機能ユニットを、未使用ハードウェアリソースにデプロイする場合に、当該特定種類の機能ユニットに応じたシステムソフトウェアのセットアップが未使用ハードウェアリソースに施される。そして、システムソフトウェアのセットアップが施された未使用ハードウェアリソースが、当該特定種類の機能ユニットに関連付けられているリソースプールに追加される。
　このようにして本実施形態によれば、ネットワークサービスを実現する各種の機能ユニットがデプロイされるハードウェアリソースを有効活用できることとなる。
　なお、本実施形態において、需要予測の結果に基づいて機能ユニットが特定されてもよい。例えば、需要予測の結果に基づいて、近い将来に不足することが予測される機能ユニットが特定されてもよい。そして、このようにして特定される機能ユニットに関連付けられているリソースプールが特定されてもよい。そして、当該リソースプールに、当該機能ユニットに応じたシステムソフトウェアのセットアップが施された未使用ハードウェアリソースが追加されてもよい。
　新規の機能ユニット群がデプロイされるハードウェアリソースが確保されると、サービスマネージャ部７０は、例えば、上述の計画データと、サービスマネージャ部７０に記憶されている、購入バンドルＩＤに関連付けられたサービステンプレートデータと、に基づいて、新規の機能ユニット群のデプロイをコンテナ管理部７８に指示する。当該サービステンプレートデータは、当該計画データの一部又は全部をパラメータとして受け入れ可能なものとなっている。
　上述のサービステンプレートデータの一例として、ＣＮＦＣＤ（CNFC Descriptor）が挙げられる。図１９は、ＣＮＦＣＤの一例を示す図である。サービスマネージャ部７０は、例えば、計画データと当該ＣＮＦＣＤとに基づいて、図２０に示すｄａｙ０パラメータ（ＣＮＦＣインスタンス）を生成する。例えば、図１９に示すＣＮＦＣＤのホスト名とＩＰアドレスの値が設定された、図２０に示すｄａｙ０パラメータが生成される。
　ここでＣＮＦＣＤに複数のデプロイメントフレーバーのそれぞれに対応付けられたテンプレートが含まれていてもよい。そして例えば、サービスマネージャ部７０は、購入サービス要件データに応じたデプロイメントフレーバーに対応するテンプレートに基づいて、ｄａｙ０パラメータを生成してもよい。
　ここで、サービスマネージャ部７０は、ｄａｙ０パラメータの出力先のロケーションを特定してもよい。例えば、ｄａｙ０パラメータの出力先となる１又は複数のコンテナ管理部７８が特定されてもよい。例えば、計画データのコンテナ構成データに示されているリソースプールのロケーションに配置されているサーバ９０に対応付けられているコンテナ管理部７８が特定されてもよい。そして、特定されるロケーションのそれぞれに出力されるｄａｙ０パラメータが生成されてもよい。例えば、出力先となる１又は複数のコンテナ管理部７８のそれぞれに出力されるｄａｙ０パラメータが生成されてもよい。
　そして、サービスマネージャ部７０は、生成された１又は複数のｄａｙ０パラメータのそれぞれを、当該ｄａｙ０パラメータの出力先のロケーションであるコンテナ管理部７８に出力する。当該ｄａｙ０パラメータには購入バンドルＩＤが関連付けられている。
　そして、コンテナ管理部７８は、受け付けたｄａｙ０パラメータに基づいて、新規の機能ユニット群をデプロイする。コンテナ管理部７８は、例えば、購入バンドルＩＤに対応付けられるヘルムチャートデータと、受け付けたｄａｙ０パラメータとに基づいて、デプロイされるコンテナイメージ、及び、コンテナがデプロイされるリソースプールを特定する。そして、コンテナ管理部７８は、当該コンテナイメージをリポジトリ部８０から取得して、当該コンテナイメージに対応するコンテナを、特定されたリソースプールにデプロイする。ここでは例えば、購入バンドルＩＤに対応付けられるヘルムチャートデータと、受信したｄａｙ０パラメータとに基づいて、マニフェストファイルが生成される。そして、当該マニフェストファイルを用いたコンテナのデプロイが実行される。
　また、ＣＭａａＳ部６８は、例えば、上述の計画データと、ＣＭａａＳ部６８に記憶されている、購入バンドルＩＤに関連付けられたＣＭテンプレートデータと、に基づいて、ｄａｙ１パラメータを含む計画ＣＭデータを生成する。当該ＣＭテンプレートデータは、当該計画データの一部又は全部をパラメータとして受け入れ可能なものとなっている。
　ｄａｙ１パラメータには、例えば、デプロイされた機能ユニット群及び当該機能ユニット群に関係する少なくとも１つの機能ユニット（例えば、デプロイされた機能ユニット群と通信する機能ユニット）についての設定等の構成管理手順が示されている。基地局装置２２に係るｄａｙ１パラメータには、例えば、電波強度、アンテナ２２ａの向きや角度、シリアルナンバー、などが示されている。Ｓ－ＧＷ（Serving-Gateway）に係るｄａｙ１パラメータには、例えば、対向ノードを示す情報（通信相手のＭＭＥ（Mobility Management Entity）を示す情報やＡＰＮ（Access Point Name）等）、ＲＡＤＩＵＳ（Remote Authentication Dial In User Service）サーバのホスト名あるいはＦＱＤＮ、などが示されている。
　そして、ＣＭａａＳ部６８は、生成される計画ＣＭデータに含まれるｄａｙ１パラメータに基づいて、機能ユニットの設定等の構成管理を実行する。これらの処理は、例えば、Ｅ２ＥＯ部６２によるワークフローのスクリプトの実行をトリガとして実行される。
　そして、スライスマネージャ部７２は、例えば、上述の計画データと、スライスマネージャ部７２に記憶されている、購入バンドルＩＤに関連付けられたスライステンプレートデータと、に基づいて、購入されるネットワークサービスに係るネットワークスライスのインスタンス化を実行する。当該スライステンプレートデータは、当該計画データの一部又は全部をパラメータとして受け入れ可能なものとなっている。この処理は、例えば、Ｅ２ＥＯ部６２によるワークフローのスクリプトの実行をトリガとして実行される。
　スライスマネージャ部７２は、３ＧＰＰの仕様書「TS28 533」に記載される、NＳＭＦ（Network Slice Management Function）と、ＮＳＳＭＦ（Network Slice Sub-network Management Function）の機能を含んで構成される。ＮＳＭＦは、ネットワークスライスを生成し、管理する機能であり、ＮＳＩのマネジメントを提供する。ＮＳＳＭＦは、ネットワークスライスの一部を構成するネットワークスライスサブネットを生成し、管理する機能であり、ＮＳＳＩのマネジメントを提供する。
　スライスマネージャ部７２は、ＮＳＩおよびＮＳＳＩに関する情報を記憶する記憶部（不図示）を含んでもよい。この記憶部は、ＳＳＴ（SliceServiceType：MBB、V2X等）、ＮＳＩのＩＤ（ＮＳＩ－ＩＤ）、ＮＳＳＩのＩＤ（ＮＳＳＩ－ＩＤ）、ＮＳのＩＤ（ＮＳ－ＩＤ）を記憶してもよい。
　スライスマネージャ部７２は、スライステンプレートデータに基づいて、ネットワークスライスおよびネットワークスライスサブネットのインスタンス化に関係する構成管理指示をＣＭａａＳ部６８へ出力する。その際、スライスマネージャ部７２は、構成するＮＳＩおよびＮＳＳＩにＩＤを付与し、そのＩＤ情報を上記記憶部に格納する。変形例として、ＣＭａａＳ部６８が、スライスマネージャ部７２から受け付けた構成管理指示に応じてＮＳＩおよびＮＳＳＩにＩＤを付与し、そのＩＤ情報をスライスマネージャ部７２に通知してもよく、スライスマネージャ部７２は、ＣＭａａＳ部６８から通知されたＩＤ情報を上記記憶部に格納してもよい。スライスマネージャ部７２は、トポロジ管理のため、スライステンプレートデータのネットワーク階層データにおいて関連付けられたＮＳＩ、ＮＳＳＩ、ＮＳについて、それらのＮＳＩ、ＮＳＳＩ、ＮＳそれぞれのＩＤを対応付けて上記記憶部に格納する。
　ここで、ＮＳＩおよびＮＳＩを構築する処理の例を説明する。図２１は、ＮＳＩおよびＮＳＳＩの構築時の処理を模式的に示す。図２１の機器ａ～機器ｃは、複数のサーバ９０に対応する。スライスマネージャ部７２は、各機器上にＮＳＩおよびＮＳＳＩを設定するための設定情報を含む構成管理指示をＣＭａａＳ部６８に渡す。
　ＣＭａａＳ部６８は、スライスマネージャ部７２から渡された設定情報をもとに、公知のセグメントルーティング技術（例えばＳＲｖ６（セグメントルーティングＩＰｖ６））を用いて、各機器上にＮＳＩおよびＮＳＳＩを構築する。例えば、ＣＭａａＳ部６８は、複数の機器上に構築された複数の設定対象ＣＮＦＣに対して、共通のＶＬＡＮ（Virtual Local Area Network）を設定するコマンド、および、当該ＶＬＡＮに設定情報が示す帯域幅や優先度を割り当てるコマンドを発行することにより、それら複数の設定対象ＣＮＦＣに亘るＮＳＩおよびＮＳＳＩを生成してもよい。
　スライスマネージャ部７２は、複数の機器上に構築された複数の設定対象ＣＮＦＣに対してＮＳＩおよびＮＳＳＩを設定する際、監視管理部７４に通知すべきメトリックデータの種類と識別用タグを個々の設定対象ＣＮＦＣに対してさらに設定する。識別用タグは、複数のＣＮＦＣの中から個々のＣＮＦＣを一意に識別可能な値を含むデータであり、言い換えれば、ＣＮＦＣごとに異なる値を含むデータである。
　スライスマネージャ部７２は、スライステンプレートデータに含まれる、ＮＳＩおよびＮＳＳＩに関するＳＬＡ情報を保持する。ＳＬＡ情報には、ＫＰＩの算出ロジックと、アラームを発出するための閾値が定義される。スライスマネージャ部７２は、管理テーブルからＫＰＩ算出を行うＮＳＩ、ＮＳＳＩに関連付けられるＰｏｄ（コンテナまたはＣＮＦＣとも言える）を特定し、そのＰｏｄから出力されるメトリックデータをもとに、ＮＳＩ、ＮＳＳＩごとのＫＰＩを算出するよう監視管理部７４に指示する。
　ここで、スライスマネージャ部７２が、ネットワークスライスのインスタンス化に関係する構成管理指示をＣＭａａＳ部６８に出力してもよい。そして、ＣＭａａＳ部６８が、当該構成管理指示に従った設定等の構成管理を実行してもよい。
　ここで例えば、ＣＭａａＳ部６８が、新規の機能ユニット群のデプロイが終了した際にこれらの新規の機能ユニット群に関する構成管理を実行して、その後に、ネットワークスライスのインスタンス化に関係する構成管理を実行してもよい。
　あるいは、ＣＭａａＳ部６８が、一旦生成されるｄａｙ１パラメータを、スライスマネージャ部７２から受け付ける構成管理指示に基づいて更新してもよい。そして、ＣＭａａＳ部６８が、新規の機能ユニット群及びネットワークスライスのインスタンス化に関係する構成管理をまとめて実行してもよい。
　監視管理部７４は、本実施形態では例えば、上述の計画データと、監視管理部７４に記憶されている、購入バンドルＩＤに関連付けられた監視スクリプトデータと、に基づいて、購入サービス要件データが示す監視ポリシーを特定する。そして、監視管理部７４は、特定される監視ポリシーに従った監視設定を実行する。そして、監視管理部７４は、構築される機能ユニット群を、特定される監視ポリシーに従って監視する。ここでは例えば、購入サービス要件データが示す監視対象に対する、購入サービス要件データが示す監視間隔での監視が実行されてもよい。この処理は、例えば、Ｅ２ＥＯ部６２によるワークフローのスクリプトの実行をトリガとして実行される。
　監視管理部７４は、例えば、監視対象のコンテナに関連付けられた、監視対象のメトリックの値を上述の監視間隔でログとして出力するサイドカーからログを取得してもよい。そして、監視管理部７４は、当該ログを蓄積してもよい。そして、監視管理部７４は、例えば、購入者端末１４からの要求に応じて当該ログを購入者端末１４に送信してもよい。
　監視管理部７４は、既知の監視ソフトウェアを用いて監視対象のＣＮＦＣ（マイクロサービス）に関連付けられた監視対象のメトリックの値を取得し、そのメトリック値と予め定められた計算ロジックとをもとにＫＰＩを算出する。上記の既知の監視ソフトウェアは、プロメテウス（Prometheus）であってもよい。監視管理部７４は、算出したＫＰＩの値が予め定められた閾値を超えた場合や、またはＫＰＩの値が予め定められた閾値未満である場合、アラート情報を出力する。
　監視管理部７４は、スライスマネージャ部７２の指示に基づいて、ＮＳＩとＮＳＳＩに関するＫＰＩの値を算出してもよい。また、監視管理部７４は、ＮＳＩとＮＳＳＩに関するＫＰＩの値を算出するために、それらのＮＳＩとＮＳＳＩに対応付けられているＮＳ、ＣＮＦ、ＣＮＦＣのＫＰＩを算出してもよい。
　セキュリティ設定部７６は、例えば、本実施形態では例えば、上述の計画データと、セキュリティ設定部７６に記憶されている、購入バンドルＩＤに関連付けられたセキュリティスクリプトデータと、に基づいて、購入サービス要件データの値に従った、パスワードの設定等のセキュリティ設定を実行する。
　ここで、図９に示すオンボーディング画面においてベンダによってオンボーディングボタン４０がクリックされた際にベンダ端末１６、ＭＰＳ１０、及び、ＮＯＳ１２で実行される処理の流れを、図２２Ａ及び図２２Ｂに示すフロー図を参照しながら説明する。
　まず、ベンダ端末１６が、オンボーディング画面において指定されたパスに配置されたバンドルデータをＮＯＳ１２のバンドル展開部６０に送信する（Ｓ１０１）。
　そして、バンドル展開部６０は、Ｓ１０１に示す処理で受信したバンドルデータを展開して、図１１に示すデータ群を生成する（Ｓ１０２）。
　そして、バンドル展開部６０は、Ｓ１０２に示すデータ群に対応するバンドルＩＤを決定する（Ｓ１０３）。
　そして、バンドル展開部６０は、Ｓ１０３に示す処理で決定されたバンドルＩＤに関連付けられた、Ｓ１０２に示すデータ群に含まれるプロダクトカタログデータをＭＰＳ１０のバンドル管理部５０に送信する。そして、ＭＰＳ１０のバンドル管理部５０が、受信したプロダクトカタログデータをプロダクトカタログ記憶部５２に記憶させる（Ｓ１０４）。
　そして、バンドル展開部６０は、Ｓ１０３に示す処理で決定されたバンドルＩＤに関連付けられた、Ｓ１０２に示すデータ群に含まれるサービスカタログデータをＥ２ＥＯ部６２に出力する。そして、Ｅ２ＥＯ部６２が、受信したサービスカタログデータをサービスカタログ記憶部６４に記憶させる（Ｓ１０５）。
　そして、バンドル展開部６０が、Ｓ１０３に示す処理で決定されたバンドルＩＤに関連付けられた、Ｓ１０２に示すデータ群に含まれるインベントリテンプレートデータをインベントリ管理部６６に記憶させる（Ｓ１０６）。
　そして、バンドル展開部６０が、Ｓ１０３に示す処理で決定されたバンドルＩＤに関連付けられた、Ｓ１０２に示すデータ群に含まれるＣＭテンプレートデータをＣＭａａＳ部６８に記憶させる（Ｓ１０７）。
　そして、バンドル展開部６０が、Ｓ１０３に示す処理で決定されたバンドルＩＤに関連付けられた、Ｓ１０２に示すデータ群に含まれるサービステンプレートデータをサービスマネージャ部７０に記憶させる（Ｓ１０８）。
　そして、バンドル展開部６０が、Ｓ１０３に示す処理で決定されたバンドルＩＤに関連付けられた、Ｓ１０２に示すデータ群に含まれるスライステンプレートデータをスライスマネージャ部７２に記憶させる（Ｓ１０９）。
　そして、バンドル展開部６０が、Ｓ１０３に示す処理で決定されたバンドルＩＤに関連付けられた、Ｓ１０２に示すデータ群に含まれる監視スクリプトデータを監視管理部７４に記憶させる（Ｓ１１０）。
　そして、バンドル展開部６０が、Ｓ１０３に示す処理で決定されたバンドルＩＤに関連付けられた、Ｓ１０２に示すデータ群に含まれるセキュリティスクリプトデータをセキュリティ設定部７６に記憶させる（Ｓ１１１）。
　そして、バンドル展開部６０が、Ｓ１０３に示す処理で決定されたバンドルＩＤに関連付けられた、Ｓ１０２に示すデータ群に含まれるヘルムチャートデータをコンテナ管理部７８に記憶させる（Ｓ１１２）。ここで例えば、バンドル展開部６０は、Ｓ１０２に示すデータ群に含まれるヘルムチャートを複数のコンテナ管理部７８に記憶させてもよい。また、コンテナ管理部７８に対応付けられるヘルムチャートデータが当該コンテナ管理部７８に記憶されるようにしてもよい。
　そして、バンドル展開部６０が、Ｓ１０３に示す処理で決定されたバンドルＩＤに関連付けられた、Ｓ１０２に示すデータ群に含まれるコンテナイメージデータをリポジトリ部８０に記憶させて（Ｓ１１３）、本処理例に示す処理は終了される。
　ベンダ端末１６からアップロードされたバンドルデータのオンボーディング時の動作をまとめる。バンドルデータは、スライステンプレートデータとサービステンプレートデータを含む複数種類のテンプレートデータを含む。バンドル展開部６０は、ベンダ端末１６からアップロードされたバンドルデータを受け付け、そのバンドルデータに含まれる複数種類のテンプレートデータを、バンドルデータが示すサービスに対応付けて、ＮＯＳ１２の複数の機能ブロックへ配付する。例えば、バンドル展開部６０は、スライステンプレートデータをスライスマネージャ部７２へ提供し、サービステンプレートデータをサービスマネージャ部７０へ提供する。
　スライステンプレートデータには、サービスの購入者に提供すべきＮＳＩおよびＮＳＳＩのＳＬＡ情報が記述される。ＳＬＡ情報は、監視対象となるＫＰＩの種類と、ＫＰＩの計算ロジック、およびＫＰＩを評価する基準となる閾値を含む。また、スライステンプレートデータは、ＮＳＩ－ＮＳＳＩ－ＮＳの階層構造（対応関係）がさらに記述される。サービステンプレートデータには、構築すべきＮＳ、ＣＮＦ、ＣＮＦＣの種類や、定義情報が記述される。
　次に、図３に示すサービス要件入力画面において購入者によって次へボタン３２がクリックされた際に、購入者端末１４、ＭＰＳ１０、及び、ＮＯＳ１２で実行される処理の流れを、図２３に示すフロー図を参照しながら説明する。
　まず、購入者端末１４は、購入バンドルＩＤに関連付けられた購入サービス要件データをＭＰＳ１０の購入管理部５４に送信する（Ｓ２０１）。当該購入バンドルＩＤは、図２に示す購入画面において購入者によって選択されたネットワークサービスのバンドルＩＤである。当該購入サービス要件データは、図３に示すサービス要件入力画面における入力内容を示すサービス要件データである。
　すると、ＭＰＳ１０の購入管理部５４は、Ｓ２０１に示す処理で受信した、購入バンドルＩＤに関連付けられた購入サービス要件データを、ＮＯＳ１２のＥ２ＥＯ部６２に送信する（Ｓ２０２）。
　すると、ＮＯＳ１２のＥ２ＥＯ部６２が、当該購入バンドルＩＤに関連付けられているサービスカタログデータに基づいて、空き状況問合せデータを生成する（Ｓ２０３）。ここでは例えば、購入されるネットワークサービスを実現する機能ユニット群の種類並びに各種類についての機能ユニットの数を示す空き状況問合せデータが生成される。
　そして、Ｅ２ＥＯ部６２が、Ｓ２０３に示す処理で生成された空き状況問合せデータをインベントリ管理部６６に出力する（Ｓ２０４）。
　すると、インベントリ管理部６６が、受け付けた空き状況問合せデータ、インベントリデータ、及び、インベントリテンプレートデータに基づいて、空き状況データを生成する（Ｓ２０５）。ここでは例えば、受け付けた空き状況問合せデータに示されている機能ユニット群がデプロイされるハードウェアリソースについて（１）確保可能であること、（２）空きサーバをリソースプールに追加することで確保可能であること、又は、（３）確保が不可能であることのいずれかを示す空き状況データが生成される。
　そして、インベントリ管理部６６は、Ｓ２０５に示す処理で生成された空き状況データをＥ２ＥＯ部６２に送信する（Ｓ２０６）。
　すると、Ｅ２ＥＯ部６２は、Ｓ２０６に示す処理で受信した空き状況データに基づいて、回答データを生成する（Ｓ２０７）。ここでは例えば、空き状況データが上述の（１）又は（２）を示す場合は、ＯＫを示す回答データが生成され、空き状況データが上述の（３）を示す場合は、ＮＧを示す回答データが生成される。
　そして、Ｅ２ＥＯ部６２は、Ｓ２０７に示す処理で生成された回答データを、ＭＰＳ１０の購入管理部５４に送信する（Ｓ２０８）。
　そして、購入管理部５４は、Ｓ２０８に示す処理で受信した回答データに基づいて、購入確認画面を生成する（Ｓ２０９）。ここでは例えば、受信した回答データがＯＫを示す場合は、図４に示す、即時の提供が可能であることを示す購入確認画面が生成される。一方、受信した回答データがＮＧを示す場合は、図５に示す、所定の納期が必要である（例えば、２週間の納期が必要である）ことを示す購入確認画面が生成される。
　そして、購入管理部５４は、Ｓ２０９に示す処理で生成された購入確認画面を購入者端末１４に送信する（Ｓ２１０）。
　そして、購入者端末１４が、Ｓ２１０に示す処理で受信した購入確認画面を購入者端末１４のディスプレイに表示させて（Ｓ２１１）、本処理例に示す処理は終了される。
　次に、購入者によって、図４又は図５に示す購入確認画面において購入ボタン３４がクリックされた際に、購入者端末１４、ＭＰＳ１０、及び、ＮＯＳ１２で実行される処理の流れを、図２４に示すフロー図を参照しながら説明する。
　まず、購入者端末１４が、ネットワークサービスの購入要求をＭＰＳ１０の購入管理部５４に送信する（Ｓ３０１）。当該購入要求には、Ｓ２０１に示す処理で送信された購入バンドルＩＤ及び購入サービス要件データが関連付けられていることとする。
　そして、購入管理部５４は、Ｓ３０１に示す処理で受信した、購入バンドルＩＤ及び購入サービス要件データに関連付けられた購入要求をＥ２ＥＯ部６２に送信する（Ｓ３０２）。
　そして、Ｅ２ＥＯ部６２が、受信した購入要求に関連付けられている購入バンドルＩＤに対応するサービスカタログデータを特定する（Ｓ３０３）。
　そして、Ｅ２ＥＯ部６２が、Ｓ３０３に示す処理で特定されたサービスカタログデータをサービスカタログ記憶部６４から取得して、当該サービスカタログデータが示すワークフローのスクリプトを実行して（Ｓ３０４）、本処理例に示す処理は終了される。
　ここで、Ｓ３０４に示す処理の詳細について、図２５Ａ～図２５Ｇに示すフロー図を参照しながら説明する。
　まず、Ｅ２ＥＯ部６２及びインベントリ管理部６６が、購入要求に関連付けられている購入サービス要件データ、サービスカタログデータ、インベントリテンプレートデータ、及び、インベントリデータに基づいて、計画データを生成する（Ｓ４０１）。Ｓ４０１で実行される処理には、例えば、機能ユニット群がデプロイされるリソースプール、及び、必要なリソースを特定する処理が含まれる。
　そして、インベントリ管理部６６は、生成された計画データをインベントリデータベース８２に記憶させる（Ｓ４０２）。
　そして、インベントリ管理部６６は、生成された計画データに含まれるインベントリキーをＥ２ＥＯ部６２に出力する（Ｓ４０３）。
　すると、Ｅ２ＥＯ部６２は、受け付けたインベントリキーをＣＭａａＳ部６８に出力する（Ｓ４０４）。
　すると、ＣＭａａＳ部６８は、受け付けたインベントリキーを含む計画データをインベントリデータベース８２から取得する（Ｓ４０５）。
　そして、ＣＭａａＳ部６８は、Ｓ４０５に示す処理で取得された計画データに基づいて、ｄａｙ１パラメータを含む計画ＣＭデータを生成して、保持する（Ｓ４０６）。
　そして、ＣＭａａＳ部６８は、必要なハードウェアリソースの確保などのセットアップの指示をＢＭａａＳ部８４に出力して（Ｓ４０７）、ＢＭａａＳ部８４が、当該指示に応じたハードウェアリソースの確保などのセットアップを実行する（Ｓ４０８）。この際に、特定種類の機能ユニットに応じたシステムソフトウェアのセットアップや、リソースプールへの空きサーバの追加が、必要に応じて実行される。
　なお、本実施形態において、リソースプールへの空きサーバの追加は余裕（バッファ）をもって行われるようにしてもよい。例えば、複数台のサーバ９０がまとめてリソースプールに追加されてもよい。
　そして、ＢＭａａＳ部８４が、終了通知をＣＭａａＳ部６８に出力すると（Ｓ４０９）、ＣＭａａＳ部６８は、リソースプール管理データを更新する（Ｓ４１０）。ここでは例えば、ハードウェアリソースが確保されたリソースプールの残りコア数データの値が減算されてもよい。また、空きサーバ数や総コア数データの値が更新されてもよい。なお、Ｓ４１０に示す処理において、ＣＭａａＳ部６８ではなく、ＢＭａａＳ部８４がリソースプール管理データを更新してもよい。また、ＣＭａａＳ部６８からの指示に従って、インベントリ管理部６６がリソースプール管理データを更新してもよい。
　そして、ＣＭａａＳ部６８は、終了通知をＥ２ＥＯ部６２に出力する（Ｓ４１１）。
　すると、Ｅ２ＥＯ部６２は、Ｓ４０３に示す処理で受け付けたインベントリキーをサービスマネージャ部７０に出力する（Ｓ４１２）。
　すると、サービスマネージャ部７０は、受け付けたインベントリキーを含む計画データをインベントリデータベース８２から取得する（Ｓ４１３）。
　そして、サービスマネージャ部７０は、Ｓ４１８に示す処理で取得された計画データに基づいて、機能ユニット群がデプロイされるロケーションを特定する（Ｓ４１４）。
　そして、サービスマネージャ部７０は、Ｓ４１４に示す処理で特定されたロケーション毎のｄａｙ０パラメータ（ＣＮＦＣインスタンス）を生成する（Ｓ４１５）。
　そして、サービスマネージャ部７０は、Ｓ４１４に示す処理で特定されたそれぞれのロケーションに対応するコンテナ管理部７８に、当該コンテナ管理部７８に対応するｄａｙ０パラメータを出力する（Ｓ４１６）。
　そして、コンテナ管理部７８は、受け付けたｄａｙ０パラメータに基づいて、コンテナのデプロイを実行する（Ｓ４１７）。
　そして、コンテナ管理部７８は、終了通知をサービスマネージャ部７０に出力する（Ｓ４１８）。
　すると、サービスマネージャ部７０は、終了通知をＥ２ＥＯ部６２に出力する（Ｓ４１９）。
　そして、Ｅ２ＥＯ部６２は、ｄａｙ１パラメータに基づく構成管理指示をＣＭａａＳ部６８に出力する（Ｓ４２０）。
　すると、ＣＭａａＳ部６８は、保持している計画ＣＭデータに含まれるｄａｙ１パラメータに基づく、コンテナ群の構成管理を実行する（Ｓ４２１）。
　そして、ＣＭａａＳ部６８は、終了通知をＥ２ＥＯ部６２に出力する（Ｓ４２２）。
　すると、Ｅ２ＥＯ部６２は、Ｓ４０３に示す処理で受け付けたインベントリキーをスライスマネージャ部７２に出力する（Ｓ４２３）。
　すると、スライスマネージャ部７２は、受け付けたインベントリキーを含む計画データをインベントリデータベース８２から取得する（Ｓ４２４）。
　そして、スライスマネージャ部７２は、Ｓ４２９に示す処理で取得された計画データに基づいて、ネットワークスライスのインスタンス化を実行する（Ｓ４２５）。Ｓ４２５に示す処理では、例えば上述のように、スライスマネージャ部７２が、ネットワークスライスのインスタンス化に関係する構成管理指示をＣＭａａＳ部６８に出力してもよい。そして、ＣＭａａＳ部６８が、当該構成管理指示に従った設定等の構成管理を実行してもよい。
　また、上述のように、Ｓ４２０～Ｓ４２２に示す処理が実行されずに、Ｓ４２５に示す処理で、ＣＭａａＳ部６８が、ｄａｙ１パラメータを、スライスマネージャ部７２から受け付ける構成管理指示に基づいて更新してもよい。そして、ＣＭａａＳ部６８が、当該構成管理指示に従った設定等の構成管理を実行してもよい。
　そして、スライスマネージャ部７２は、終了通知をＥ２ＥＯ部６２に出力する（Ｓ４２６）。
　すると、Ｅ２ＥＯ部６２は、Ｓ４０３に示す処理で受け付けたインベントリキーを監視管理部７４に出力する（Ｓ４２７）。
　すると、監視管理部７４は、受け付けたインベントリキーを含む計画データをインベントリデータベース８２から取得する（Ｓ４２８）。
　そして、監視管理部７４は、Ｓ４２８に示す処理で取得された計画データに基づいて、購入サービス要件データが示す監視ポリシーに従った監視設定を実行する（Ｓ４２９）。
　そして、監視管理部７４は、終了通知をＥ２ＥＯ部６２に出力する（Ｓ４３０）。
　すると、Ｅ２ＥＯ部６２は、Ｓ４０３に示す処理で受け付けたインベントリキーをセキュリティ設定部７６に出力する（Ｓ４３１）。
　すると、セキュリティ設定部７６は、受け付けたインベントリキーを含む計画データをインベントリデータベース８２から取得する（Ｓ４３２）。
　そして、セキュリティ設定部７６は、Ｓ４３２に示す処理で取得された計画データに基づいて、セキュリティ設定を実行する（Ｓ４３３）。
　そして、セキュリティ設定部７６は、終了通知をＥ２ＥＯ部６２に出力して（Ｓ４３４）、本処理例に示す処理は終了される。
　購入者によりサービスが購入されたことを契機とするネットワークサービスプロビジョニング時の動作をまとめる。ここでは購入されたサービスを「購入対象サービス」と呼ぶ。Ｅ２ＥＯ部６２は、購入者により選択された購入対象サービスに対応するワークフローの実行を開始する。Ｅ２ＥＯ部６２およびインベントリ管理部６６は、購入対象サービスのインベントリテンプレートに、インベントリデータ（ＩＰアドレス、ホスト名等）を穴埋めすること、言い換えれば、インベントリテンプレートの変数項目にインベントリデータを設定することにより購入対象サービス用の計画データを作成する。
　サービスマネージャ部７０は、購入対象サービスのサービステンプレートデータに計画データが示す内容を穴埋めすることによりｄａｙ０データ（ｄａｙ０パラメータ）を作成する。サービスマネージャ部７０は、作成したｄａｙ０データをコンテナ管理部７８（クバネテス）に渡す。コンテナ管理部７８は、ｄａｙ０データをもとに、購入対象サービス用のＣＮＦＣ（言い換えればアプリケーション）を生成する。
　ＣＭａａＳ部６８は、購入対象サービスのＣＭテンプレートデータに計画データが示す内容を穴埋めすることによりｄａｙ１データ（ｄａｙ１パラメータ）を作成する。ＣＭａａＳ部６８は、作成したｄａｙ１データを、購入対象サービス用のＣＮＦＣに投入する。
　スライスマネージャ部７２は、購入対象サービスのスライステンプレートデータに計画データが示す内容を穴埋めすることによりスライスデータを作成する。スライスマネージャ部７２は、作成したスライスデータをＣＭａａＳ部６８に渡す。ＣＭａａＳ部６８は、スライスデータをもとに、ＣＮＦＣ（言い換えればアプリケーション）にネットワークスライスおよびネットワークスライスサブネットの設定を投入する。
　監視管理部７４は、構築される機能ユニット群（例えばＣＮＦＣ）に関する情報と、バンドルファイルのオンボーディング時に配付された監視スクリプトデータとに基づいて、機能ユニット群に対する監視処理を実行する。例えば、監視管理部７４は、構築される機能ユニット群に関する情報としての計画データが示す内容を、購入対象サービスの監視スクリプトデータに穴埋めすることにより監視設定データを作成してもよい。監視管理部７４は、監視設定データに基づく監視処理を開始してもよい。監視設定データは、例えば、（１）監視頻度、（２）監視対象とその階層構成、（３）ＣＮＦＣから取得するメトリックデータからＫＰＩを算出するロジック、（４）アラーム情報を送信するトリガとなる閾値を含む。
　監視管理部７４による監視設定データ作成の別の例を説明する。サービスマネージャ部７０は、購入者によるサービス購入に伴って構築したＮＳ、ＣＮＦ、ＣＮＦＣに関する情報（例えばＩＰアドレスやホスト名等の情報）をインベントリ管理部６６へ通知し、インベントリ管理部６６は、それらの情報を購入対象サービスに対応付けてインベントリデータベース８２に格納してもよい。監視管理部７４は、インベントリ管理部６６（インベントリデータベース８２）から、購入対象サービスのＮＳ、ＣＮＦ、ＣＮＦＣに関する情報を取得して購入対象サービスの監視スクリプトデータの変数項目に設定することにより監視設定データを作成してもよい。なお、監視管理部７４は、サービスマネージャ部７０により構築されたＮＳ、ＣＮＦ、ＣＮＦＣに関する情報をサービスマネージャ部７０から直接取得してもよい。
　また、監視管理部７４は、購入対象サービスのＮＳＩおよびＮＳＳＩに関する情報（例えばＮＳＩおよびＮＳＳＩの設定情報）をスライスマネージャ部７２から取得してもよい。監視管理部７４は、購入対象サービスのＮＳＩおよびＮＳＳＩに関する情報を、購入対象サービスの監視スクリプトデータの変数項目に設定することにより監視設定データを作成してもよい。なお、スライスマネージャ部７２は、購入対象サービスのＮＳＩおよびＮＳＳＩに関する情報をインベントリ管理部６６へ通知してもよい。この場合、監視管理部７４は、購入対象サービスのＮＳＩおよびＮＳＳＩに関する情報をインベントリ管理部６６から取得してもよい。
　ＮＯＳ１２によると、ネットワークサービスを提供するベンダは、ネットワークサービスを実現する機能ユニット群を定めた第１データ（例えばテクノロジーセクションデータ）と、ネットワークサービスに関する監視ポリシーを定めた第２データ（例えばオペレーションセクションデータ）とを含むバンドルファイルをＮＯＳ１２にアップロードすれば、購入者によるネットワークサービス購入を契機に、当該ネットワークサービスを実現する機能ユニット群の構築と、当該ネットワークサービスに対する監視設定とが自動的に実行される。ベンダは、バンドルファイルの内容を調整することにより、ネットワークサービスを柔軟に構築できる。また、購入者によるネットワークサービス購入に応じて、迅速にネットワークサービスを購入者に提供することができる。
［ユーザ管理技術に関する実施の形態］
　以上の前提技術を利用したユーザ管理技術の具体例を述べる。
［第１の実施形態］
　前提技術などにより実現されるネットワークシステムは、会社や個人など複数の利用主体がサーバや記憶領域といった物理リソースを共有しつつ、各利用主体に与えられた領域ごとに独立した運用を可能とする、いわゆるマルチテナントのシステムである。ここでテナントとは、ネットワークサービスの利用主体に割り当てられた、サーバやデータベースなどのリソースの論理区画を指す。
　前提技術を例にとると、ネットワークサービスの購入者は、会社のシステム管理者などに対応する。例えば当該システム管理者が自社のシステムとしてネットワークサービスを購入することにより、サーバにコンテナがデプロイされ、従業員が利用する勤怠管理や在庫管理など必要なアプリケーションが稼働する。以後、主にこのようなユースケースを想定して説明するが、テナントの生成目的やそれを利用するユーザの人数などを限定する主旨ではない。例えばコンピュータシステムで提供されるサービスは通信を実現するものに限らず、クラウドサービスのような多様な情報処理であってよい。
　図２６は、コンピュータシステム１における作業区分を例示している。この例でコンピュータシステム１に係る作業区分として、システムの全体を管理する「システム管理」、提供対象のサービスを登録する「サービス登録」、ネットワークサービスを購入する「サービス購入」、および、テナントＡ、Ｂ、Ｃ、Ｄ内でアプリケーションを利用する「テナントＡアプリ利用」、「テナントＢアプリ利用」、「テナントＣアプリ利用」、「テナントＤアプリ利用」が含まれる。
　「システム管理」の作業主体は、コンピュータシステム１のインフラストラクチャーを提供したり、全体的な運用や管理を担ったりする企業などの担当者である。以後、当該担当者を「システムオーナー」と呼ぶ。「サービス登録」の作業主体は前提技術の場合、バンドルファイルを登録するベンダである。「サービス購入」の作業主体はテナントを利用する組織におけるシステム管理者などであり、前提技術における「購入者」に対応する。以後、このようなテナントごとの管理者を「テナント管理者」と呼ぶ。
　「テナントＡアプリ利用」～「テナントＤアプリ利用」の作業主体は、各テナントに対応する組織のメンバー、例えば会社の従業員などである。以後、当該メンバーを「一般ユーザ」と呼ぶ。このようにコンピュータシステム１においては、多様な立場の人員がアクセスし、多様な目的で処理を要求したりデータを更新したりする。また、テナントは場合によって追加、削除、統合などの変動がある。さらに、１人のユーザが複数種類の作業を行う場合もある。例えばテナント管理者は、ネットワークサービスを購入するとともに、作成されたテナント内でアプリケーションを利用し得る。
　このように、構成の柔軟性を許容する大規模なシステムにおいては、ユーザの認証やアクセス権限の管理を安全に行うことが重要な課題となる。例えば従来のシステムでは、ユーザを１つのインスタンスで一元管理することがなされてきた。この場合、ユーザやグループの情報と、関連するセキュリティ資格を含むリポジトリ、いわゆるレルムを設定することで、ユーザの認証先や認証ポリシーを区別し得る。またアプリケーション内で定義される承認レベル、いわゆるロールをユーザに割り当てることで、アクセス権限を設定し得る。
　しかしながらそのような各種技術を導入しても、管理プログラムのバグやエラーなどにより、ユーザ情報が他の組織の端末から閲覧できてしまうといった想定外の事態は起こり得る。そこで本実施の形態では、作業区分などに対応する、より細かい単位でユーザ管理のインスタンスを立ち上げることにより、情報漏洩や不正アクセスといった不測の事態が起こりにくい安全性の高いシステムを実現する。
　図２７は、第１の実施形態におけるマーケットプレイスシステム（ＭＰＳ）、Ｅ２ＥＯ部、およびテナントの機能ブロックの構成を示している。なお同図は、ユーザ管理に係る機能ブロックを示しており、ネットワークサービスを実現するための機能は前提技術で述べたとおりである。ＭＰＳ１０は図１０で示した購入管理部５４に加え、マーケットプレイスユーザ管理部１３６を備える。
　購入管理部５４は、テナント管理者のユーザ登録を受け付ける登録受付部１３０、テナント管理者のログインを処理するログイン処理部１３２、および、テナントの購入を受け付ける購入受付部１３４を含む。登録受付部１３０は、テナント管理者がテナントを購入する目的で行うユーザ登録を、テナント管理者が用いる購入者端末１４を介して受け付ける。ログイン処理部１３２は、ユーザ登録を行ったテナント管理者によるシステムへのログイン要求を受け付ける。
　購入受付部１３４は、ＭＰＳ１０へログインしたテナント管理者による、テナント購入要求を受け付ける。購入受付部１３４の機能は、購入管理部５４の機能として前提技術で述べたとおりである。すなわち購入受付部１３４は、テナント管理者が用いる購入者端末１４に対し、図２～５で示した各種画面を表示させることにより、テナント内で実現すべきサービスの内容に係る情報を取得する。なお購入受付部１３４がテナント管理者に提示する画面は図２～５に限らない。
　マーケットプレイスユーザ管理部１３６は、登録受付部１３０で登録を受け付けたユーザ、すなわちテナント管理者の情報を管理する。より具体的には、ユーザ情報とリソースへのアクセスを管理する機能を有する。このような機能は、一般にＩＡＭ（Identity and Access Management）と呼ばれる。マーケットプレイスユーザ管理部１３６は、例えば次の機能を有する。
　認証：パスワードや生体情報などを利用しシステムへのアクセスを認証する
　認可：システム内のアクセスや処理を権限内で認可する
　ロール設定：システム内で権限が及ぶ範囲をロールとして設定する
　委任：上位の権限を持つロールに管理権限を委任できるようにする
　インターチェンジ：異なる管理ドメイン間で情報を交換する
　マーケットプレイスユーザ管理部１３６は、内部にユーザ情報記憶部１３８とクライアント情報記憶部１４０を備える。ユーザ情報記憶部１３８は、ユーザの識別情報、パスワード、属性など、マーケットプレイスユーザ管理部１３６の上記機能を実現するのに必要なユーザ情報を記憶する。登録受付部１３０は、登録を受け付けたテナント管理者のユーザ情報をユーザ情報記憶部１３８に格納する。登録受付部１３０は、ユーザ情報の修正や削除の要求をテナント管理者などから受け付け、それに従いユーザ情報記憶部１３８に格納された情報を適宜修正、削除してよい。
　クライアント情報記憶部１４０は、購入されたテナントで稼働するアプリケーションやサービスなどクライアントの情報を記憶する。例えばテナントが生成された際などに、そこで稼働するクライアントの情報がクライアント情報記憶部１４０に格納される。クライアントの情報には、クライアントの識別情報とともに、クライアントへのユーザアクセスに際しマーケットプレイスユーザ管理部１３６での認証を実現するための連係情報、例えばアクセスキーやコールバック用のＵＲＬ（Uniform Resource Locator）なども含める。
　Ｅ２ＥＯ部６２は、購入受付部１３４が受け付けた購入要求に応じて、前提技術で述べたように、必要な機能やサービスをサーバにデプロイすることでテナント１４４を生成する。ここでＥ２ＥＯ部６２は、作成したテナント１４４内のクライアントに係る情報を、マーケットプレイスユーザ管理部１３６のクライアント情報記憶部１４０に登録するクライアント登録部１４２を備える。なお図ではＥ２ＥＯ部６２のみを示しているが、実際には図１０のＮＯＳ１２が備える各機能ブロックの協働によりテナントが生成される。
　また、ここではテナントとして実現されるサービスやアプリケーションを「購入」の対象としているが、本実施の形態はそれに限らず、テナント管理者は単にテナントの作成を要求してもよい。またテナントの作成手順は前提技術で述べたものに限らず、一般的なネットワークサービスやクラウドサービスで採用される技術を適用してもよい。
　テナント１４４は、テナント管理者のテナント生成要求に応じて生成され、一般ユーザなどにより利用されるサービスの実行主体である。コンピュータシステム全体で見ると、テナント１４４は、Ｅ２ＥＯ部６２が生成した数だけ存在することになる。それらのテナントを包括して「テナント稼働システム」と捉えることができる。これに対し、テナント生成要求を受け付けテナントを生成する、ＭＰＳ１０およびＥ２ＥＯ部を含むシステムを、「テナント生成システム」と捉えることができる。
　各テナント１４４は、テナントユーザ管理部１４６およびアプリケーション処理部１５２を含む。テナントユーザ管理部１４６は、上述したマーケットプレイスユーザ管理部１３６と同等の機能を有する。ただし管理対象は主に、テナント内のクライアントにアクセスしてサービスを利用する一般ユーザである。なおこれに対し、マーケットプレイスユーザ管理部１３６は、「テナント生成システム内ユーザ管理部」と捉えることができる。
　テナントユーザ管理部１４６は、ユーザ情報記憶部１４８および連携部１５０を備える。ユーザ情報記憶部１４８は、一般ユーザの識別情報、パスワード、属性など、テナントユーザ管理部１４６の機能を実現するのに必要なユーザ情報を記憶する。一般ユーザの情報は、テナントが生成された後、適宜登録してよい。
　連携部１５０は他の認証機能と連携することにより、ユーザ情報記憶部１４８に格納されている情報以外のユーザ情報での認証や認可を実現する。例えば連携部１５０は上述のとおり、ユーザの少なくとも一部、すなわち、ＭＰＳ１０で登録済みのテナント管理者によるクライアントへのアクセスに応じて、マーケットプレイスユーザ管理部１３６へ認証や認可を委託する。これによりテナント管理者は、ＭＰＳ１０での登録情報を利用して、テナント内のクライアントへアクセスできる。
　一方、連携部１５０は、図示しない外部のユーザ管理機構と連携してもよい。例えば社内で従業員を管理するシステムが別にある場合、連携部１５０は当該システム内のＩＤＰ（Identity Provider）と連携する。これにより一般ユーザは、当該システムで登録済みのユーザ情報を利用して、新たに生成されたテナント内のクライアントへアクセスできる。このような構成とすることで、ユーザ情報を必要以上に拡散させることなくクライアントへのアクセスの認証や管理を実現できる。アプリケーション処理部１５２はクライアントの実体であり、テナント管理者が指定したりベンダが設計したりしたサービスを実行する。
　次に、以上の構成によって実現できる、コンピュータシステム１の動作について説明する。図２８は、第１の実施形態における管理システムの構築手順を示している。まずテナント管理者は購入者端末１４を介して、ＭＰＳ１０に対しユーザ登録を要求する（Ｓ５００）。具体的にはテナント管理者は、ＭＰＳ１０の購入管理部５４が提供するグローバルページへアクセスし、購入者端末１４に登録用画面を表示させる。
　テナント管理者が、ユーザ名、パスワード、組織名など所定のユーザ情報を入力したら、購入管理部５４の登録受付部１３０がそれを取得し、マーケットプレイスユーザ管理部１３６に供給することにより、当該ユーザ情報をユーザ情報記憶部１３８に格納させる（Ｓ５０２）。以上の処理は実際には、登録受付部１３０が、ブラウザをマーケットプレイスユーザ管理部１３６にリダイレクトすることによって実現してもよい。この際、マーケットプレイスユーザ管理部１３６は、テナント管理者を一意に識別するためのユーザＩＤを発行し、登録受付部１３０を介して購入者端末１４に返信することでユーザに通知する（Ｓ５０４）。以上の処理によりテナント管理者のユーザ登録が完了する。
　ユーザ登録を行ったテナント管理者は、テナントを購入する際、ＭＰＳ１０に対しログインを要求する（Ｓ５０６）。具体的にはテナント管理者は、ＭＰＳ１０の購入管理部５４が提供するグローバルページへアクセスし、購入者端末１４にログイン用画面を表示させる。テナント管理者が、ユーザ名あるいはユーザＩＤ、パスワードなど認証に用いる情報を入力したら、購入管理部５４のログイン処理部１３２がそれを取得し、マーケットプレイスユーザ管理部１３６に供給することにより認証を行わせる（Ｓ５０８）。
　この処理は実際には、ログイン処理部１３２が、ブラウザをマーケットプレイスユーザ管理部１３６にリダイレクトすることによって実現してもよい。入力された情報が登録情報と合致しているなど認証が成功したら、マーケットプレイスユーザ管理部１３６が、当該テナント管理者のためのプライベートページのＵＲＬへコールバックすることで、購入者端末１４を介してユーザにプライベートページを提示する（Ｓ５１０）。
　この際、マーケットプレイスユーザ管理部１３６はテナント購入のためのユーザトークンをコールバック用のＵＲＬに追加することで、購入者端末１４にそれを取得させる。なお「プライベートページ」は、テナント管理者が所属する組織ごとに生成され、当該組織のメンバーのみが閲覧できるページである。これに対し「グローバルページ」は、組織に関わらずＭＰＳ１０に登録するユーザや登録済みのユーザが閲覧できるページである。続いてテナント管理者は、当該プライベートページを介してテナントの購入要求を行う（Ｓ５１２）。
　ＭＰＳ１０の購入管理部５４は当該要求を受け付け、Ｅ２ＥＯ部６２にテナント作成を要求する。この処理は実際には、図２３、２４で示した手順で実現してよい。なお購入要求において購入管理部５４の購入受付部１３４は、テナント購入用のプライベートページに対しテナント管理者が入力した、テナント名やサービス要件など必要な情報とともに、当該テナント管理者に発行されたユーザトークンを取得する。以後、ユーザトークンは、テナント生成要求をしたテナント管理者や組織とテナントとの対応づけに利用される。
　購入受付部１３４が、取得した情報やユーザトークンをＥ２ＥＯ部６２に供給すると、Ｅ２ＥＯ部６２はこれを受け付け、テナント１４４の作成処理を制御する（Ｓ５１４）。この処理は実際には、図２５Ａ～２５Ｇで示した手順で実現してよい。テナント１４４の生成に際し、Ｅ２ＥＯ部６２は、テナントを一意に識別するためのテナントＩＤを発行する。
　ここでＥ２ＥＯ部６２は、テナント１４４の一部としてテナントユーザ管理部１４６を生成する。テナントユーザ管理部１４６は、マーケットプレイスユーザ管理部１３６や、他のテナントのテナントユーザ管理部１４６と論理的、あるいはさらに物理的にも分離された状態で生成する。例えばそれぞれを別のコンテナで実現する。これにより、別組織のユーザ情報の閲覧や改ざんなどを起こりにくくする。
　続いてＥ２ＥＯ部６２は、テナント１４４で稼働させるアプリケーションやサービスなどのクライアントを、マーケットプレイスユーザ管理部１３６のクライアント情報記憶部１４０に登録する（Ｓ５１６）。具体的にはＥ２ＥＯ部６２のクライアント登録部１４２はまず、テナント１４４の連携部１５０に対し、クライアントのページへのコールバック用ＵＲＬを発行させる。なお連携部１５０は実際には、ＩＤＰとして実装してよい。
　そしてクライアント登録部１４２は当該コールバック用ＵＲＬを、クライアントの識別情報と対応づけてクライアント情報記憶部１４０に格納する。これに応じてマーケットプレイスユーザ管理部１３６は、クライアントからマーケットプレイスユーザ管理部１３６へのアクセスキーとしてクライアントシークレットを発行する。クライアント登録部１４２はそれを取得したうえ、テナントユーザ管理部１４６の連携部１５０に登録する（Ｓ５１８）。
　一方、Ｅ２ＥＯ部６２は、生成したテナントのＩＤを購入者端末１４に返信することでテナント管理者に通知する（Ｓ５２０）。以上の処理により、テナント内のクライアントからマーケットプレイスユーザ管理部１３６への処理の移行経路と、マーケットプレイスユーザ管理部１３６からクライアントへ処理を戻す経路が形成される。
　結果として矢印１５４に示すように、マーケットプレイスユーザ管理部１３６とテナントユーザ管理部１４６で連携体制（フェデレーション）が確立し、テナント管理者が最初に登録したユーザ情報を、テナント１４４側でのサービス利用時の認証にも活用できる。なお上述のとおりテナントユーザ管理部１４６は、外部のシステム（例えば「組織内ＩＤＰ１５６」）とも同様に連携してよい。
　図２９は、第１の実施形態における、テナント管理者のログイン処理の手順を示している。なおテナント管理者が用いる端末は購入者端末１４とは限らないため、図では管理者端末１６０としている。ただし管理者端末１６０は購入者端末１４と同じでもよい。テナント管理者がＭＰＳ１０に対しログイン要求を行った場合は、図２８で示したテナント購入のためのログイン処理と同様の手順となる。
　すなわちテナント管理者は、ＭＰＳ１０の購入管理部５４が提供するグローバルページへアクセスし、管理者端末１６０にログイン用画面を表示させたうえ、ユーザＩＤやパスワードなどを入力することによりログインを要求する（Ｓ５３０）。すると購入管理部５４のログイン処理部１３２がそれを取得し、マーケットプレイスユーザ管理部１３６に供給することにより認証を行わせる（Ｓ５３２）。認証が成功したら、マーケットプレイスユーザ管理部１３６がプライベートページにコールバックすることで、管理者端末１６０を介してユーザにプライベートページが提示される（Ｓ５３４）。
　一方、テナント管理者がテナント内のアプリケーションやサービスを利用する場合は、次の手順となる。まずテナント管理者は、自組織に対応するテナント１４４のアプリケーション処理部１５２が提供するページにアクセスする。そして管理者端末１６０にログイン用画面を表示させたうえ、ユーザＩＤやパスワードなどログインに必要な情報を入力することによりログインを要求する（Ｓ５３６）。テナント１４４のテナントユーザ管理部１４６は、入力された情報に基づき、要求元がテナント管理者であることを認識し、連携部１５０によりマーケットプレイスユーザ管理部１３６へリダイレクトする（Ｓ５３８）。
　この際、連携部１５０は、クライアントシークレットを送信することによりアクセスの安全性を担保する。マーケットプレイスユーザ管理部１３６は、クライアント情報記憶部１４０に記憶されたクライアント情報に基づき、正規のアクセスであることを確認したうえ、ユーザ情報記憶部１３８に基づき認証処理を実施する。認証が成功したら、マーケットプレイスユーザ管理部１３６は、クライアントに対応づけられたＵＲＬを用いてコールバックする（Ｓ５４０）。これにより、管理者端末１６０には、アプリケーション処理部１５２が提供する、ログイン後の画面が提示される（Ｓ５４２）。
　図３０は、第１の実施形態における、一般ユーザのログイン処理の手順を示している。まず一般ユーザは一般ユーザ端末１６２を用いて、自組織に対応するテナント１４４のアプリケーション処理部１５２が提供するページにアクセスする。そして一般ユーザ端末１６２にログイン用画面を表示させたうえ、ユーザＩＤやパスワードなどログインに必要な情報を入力することによりログインを要求する（Ｓ５５０）。
　テナント１４４のテナントユーザ管理部１４６は、入力されたユーザ情報に基づき、要求元が一般ユーザであることを認識し、自らが保有するユーザ情報記憶部１４８に基づき認証処理を実施する（Ｓ５５２）。認証が成功したら、アプリケーション処理部１５２が提供するページへコールバックすることより、一般ユーザ端末１６２には、アプリケーション処理部１５２が提供する、ログイン後の画面が提示される（Ｓ５５４）。
　図３１は、第１の実施形態における、一般ユーザのログイン処理の別の手順を示している。この例では、コンピュータシステム１の外部の管理システムとして、組織内ＩＤＰ１５６との連携を利用する場合を示している。図３０の場合と同様、一般ユーザは、自組織に対応するテナント１４４のアプリケーション処理部１５２が提供するページにアクセスする。そして一般ユーザ端末１６２にログイン用画面を表示させたうえ、ユーザＩＤやパスワードなどログインに必要な情報を入力することによりログインを要求する（Ｓ５６０）。
　テナント１４４のテナントユーザ管理部１４６は、入力されたユーザ情報に基づき、要求元の登録情報が組織内ＩＤＰ１５６にあることを認識し、連携部１５０により組織内ＩＤＰ１５６へリダイレクトする（Ｓ５６２）。この場合も、クライアントシークレットなどを利用してアクセスの安全性を担保してよい。認証が成功したら組織内ＩＤＰ１５６は、アプリケーション処理部１５２が提供するページへコールバックする（Ｓ５６４）。これにより一般ユーザ端末１６２には、アプリケーション処理部１５２が提供する、ログイン後の画面が提示される（Ｓ５６６）。
　以上述べた第１の実施形態によれば、マーケットプレイスユーザ管理部１３６と、テナントごとのテナントユーザ管理部１４６が個別に構築される。これにより、各組織に属する一般ユーザの情報をＭＰＳ１０から隔離できる。したがって、障害などにより他の組織のユーザ情報が閲覧できる状態となるなどの不具合を極力回避できる。
　またテナントごとにテナントユーザ管理部１４６を生成することにより、組織に応じたカスタマイズが容易になる。例えば、あらかじめ規定された構成のログイン画面を、組織の都合に合わせて修正できる。換言すれば、テナント生成と同時に、規定された構成のログイン画面やデータ構造も提供されるため、組織内での簡易な修正で、所望のログイン環境を構築できる。また、組織内でのユーザ情報の取り扱い、すなわち追加、修正、削除、統合などを、手軽に行えるようになる。
　さらに、組織独自のＩＤＰとの連携が容易かつ安全に行える。例えば元から存在する認証や手続き、管理などの仕組みを大きく変更する必要がなく、新たなサービスの導入障壁を低くできる。またＭＰＳ１０内の登録情報を、テナント内でのログイン認証に利用できるよう連携させることにより、テナント管理者がサービスを利用する際、登録を二重に行うなどの手間を省くことができる。
［第２の実施形態］
　以後、第１の実施形態との差に主眼を置き説明する。図３２は、第２の実施形態におけるマーケットプレイスシステム（ＭＰＳ）、Ｅ２ＥＯ部、オーナー端末、およびテナントの機能ブロックの構成を示している。同図において図２７で示した機能ブロックに対応するブロックには同じ符号を付し、適宜説明を省略する。本実施形態では、ＭＰＳ１０ａ、Ｅ２ＥＯ部６２ａ、およびテナント１４４ａのほか、オーナー端末１７２が構成に含まれる。オーナー端末１７２は、上述したシステムオーナーが使用する端末である。
　第２の実施形態におけるＭＰＳ１０ａの購入管理部５４ａは、テナント管理者のユーザ登録を受け付ける登録受付部１３０、テナント管理者のログインを処理するログイン処理部１３２を含む。登録受付部１３０およびログイン処理部１３２の機能は、図２７について説明したとおりである。またマーケットプレイスユーザ管理部１３６ａの機能は、基本的には図２７のマーケットプレイスユーザ管理部１３６と同等であるが、内部にはユーザ情報記憶部１３８と連携部１７０を備える。
　ユーザ情報記憶部１３８の機能は、図２７について説明したとおりである。連携部１７０は、テナント１４４ａのテナントユーザ管理部１４６ａと連携することにより、ＭＰＳ１０ａへのログインの認証を、テナントユーザ管理部１４６ａを用いて実現する。オーナー端末１７２は、テナント管理者がＭＰＳ１０ａにユーザ登録した旨をシステムオーナーに通知し、対応するテナントの作成承認をシステムオーナーから受け付ける。そしてオーナー端末１７２は、承認が得られたテナントの作成をＥ２ＥＯ部６２ａに要求する。
　すなわち第２の実施形態では、システムオーナーがオーナー端末１７２を用いてテナント管理者の登録情報を確認し、承認する旨を入力した場合にテナントが作成される。Ｅ２ＥＯ部６２ａはオーナー端末１７２からの要求に応じて、前提技術で述べたように、必要な機能やサービスをサーバにデプロイしテナント１４４を生成する。実際にはＥ２ＥＯ部６２ａ以外の図示しない機能ブロックとの協働によりテナントが生成される。
　ここでＥ２ＥＯ部６２ａは、ユーザ登録部１７４とクライアント登録部１４２ａを備える。ユーザ登録部１７４は、テナントの作成元であるテナント管理者の情報を、マーケットプレイスユーザ管理部１３６ａと、作成したテナント１４４ａ内のテナントユーザ管理部１４６ａの双方に登録する。すなわち第２の実施形態では、テナントの作成とともにテナントユーザ管理部１４６ａ側にもテナント管理者を登録する。クライアント登録部１４２ａは、作成したテナント１４４ａ内のテナントユーザ管理部１４６ａにクライアント情報を登録する。
　テナント１４４ａのテナントユーザ管理部１４６ａの機能は、基本的には図２７のテナントユーザ管理部１４６と同等であるが、内部にはユーザ情報記憶部１４８、クライアント情報記憶部１７８、および連携部１５０を備える。ユーザ情報記憶部１４８の機能は図２７で示したものと同様であるが、第２の実施形態においては、一般ユーザのユーザ情報に加えて、Ｅ２ＥＯ部６２によりテナント管理者のユーザ情報が格納される。クライアント情報記憶部１７８は、テナント１４４ａで稼働するアプリケーションやサービスなどクライアントの情報を記憶する。クライアントの情報には、アクセスキーやレルムの設定が含まれる。
　連携部１５０は、他の認証機能と連携することにより、ユーザ情報記憶部１４８に格納されている情報以外のユーザ情報での認証や認可を実現する。ただし第２の実施形態においては、テナント管理者の情報をテナントユーザ管理部１４６ａ側で保持しておくことにより、マーケットプレイスユーザ管理部１３６ａに認証や認可を委託する必要がなくなる。したがって連携部１５０は、組織内ＩＤＰなどその他の認証機構と連携する。
　以上の構成とすることで、認証や認可の主体をテナント側に集約できる。この場合、ＭＰＳ１０にログインしたテナント管理者は、テナント側のクライアントにログインしたのと同じ状態になる。これによりテナント１４４ａのサービス利用に際し、再度ログインする必要がなくなり、ログイン処理を簡便化できる。
　次に、以上の構成によって実現できる、コンピュータシステム１の動作について説明する。図３３は、第２の実施形態における管理システムの構築手順を示している。まずテナント管理者は購入者端末１４を介して、ＭＰＳ１０ａに対しユーザ登録を要求する（Ｓ６００）。具体的にはテナント管理者は、ＭＰＳ１０ａの購入管理部５４ａが提供するグローバルページへアクセスし、購入者端末１４に登録用画面を表示させる。
　テナント管理者が、ユーザ名、パスワード、組織名など所定のユーザ情報とともに、テナント名やサービス要件などテナントの作成に必要な情報を入力したら、購入管理部５４ａの登録受付部１３０がそれを取得し、オーナー端末１７２に送信することにより、システムオーナーにテナント作成の承認を要求する（Ｓ６０２）。システムオーナーは、受信した情報をオーナー端末１７２に表示させ、所定の確認作業を行うことで承認の旨を入力する。オーナー端末１７２はそれを受け付け、Ｅ２ＥＯ部６２ａにテナント作成を要求する（Ｓ６０４）。
　Ｅ２ＥＯ部６２ａはこれを受け付け、テナント１４４ａの作成処理を制御する（Ｓ６０６）。この処理は実際には、図２５Ａ～２５Ｇで示した手順で実現してよい。テナント１４４ａの生成に際し、Ｅ２ＥＯ部６２は、テナントを一意に識別するためのテナントＩＤを発行する。またＥ２ＥＯ部６２ａは、テナント１４４ａの一部としてテナントユーザ管理部１４６ａを生成する。テナントユーザ管理部１４６ａは、第１の実施形態と同様、マーケットプレイスユーザ管理部１３６ａや、他のテナントのテナントユーザ管理部１４６ａと論理的、あるいはさらに物理的にも分離された状態で生成する。
　続いてＥ２ＥＯ部６２のユーザ登録部１７４は、生成したテナント１４４ａのテナントユーザ管理部１４６ａに、テナント生成要求元のテナント管理者のユーザ登録を行う（Ｓ６０８）。これによりテナント管理者のユーザ情報がユーザ情報記憶部１４８に格納される。さらにＥ２ＥＯ部６２のクライアント登録部１４２ａは、テナント１４４で稼働させるアプリケーションやサービスなどのクライアントも、生成したテナント１４４ａのテナントユーザ管理部１４６ａに登録する（Ｓ６１０）。これによりクライアント情報がクライアント情報記憶部１７８に格納される。
　次にＥ２ＥＯ部６２のユーザ登録部１７４は、マーケットプレイスユーザ管理部１３６ａのユーザ情報記憶部１３８に、テナント生成要求元のテナント管理者のユーザ情報と、生成したテナントのＩＤを対応づけて登録する（Ｓ６１２）。この際、ユーザ登録部１７４は、テナント管理者にロールを割り当て、当該ロールをユーザ情報に含めて格納する。これにより、テナント管理者がＭＰＳ１０ａにログインしようとしたとき、ロールの設定がないことによるエラーの発生を回避する。
　ユーザ登録部１７４はさらに、ＭＰＳ１０ａの購入管理部５４ａが提供する、テナント管理者のためのプライベートページへのコールバック用のＵＲＬもユーザ情報に含めて格納する。次にＥ２ＥＯ部６２ａのクライアント登録部１４２ａは、作成したテナント１４４ａのテナントユーザ管理部１４６ａにおけるクライアントのレルムを、テナント管理者に割り当てたロールに応じて適切に更新する（Ｓ６１４）。これにより、テナントユーザ管理部１４６ａによる認証によっても、テナント１４４ａにおけるサービス利用とＭＰＳ１０へのログインの双方を可能にする。
　一方、Ｅ２ＥＯ部６２は、生成したテナントのＩＤを購入者端末１４に返信することでテナント管理者に通知する（Ｓ６１６）。この際、Ｅ２ＥＯ部６２は、テナントユーザ管理部１４６ａがテナント管理者を認証する際に用いるパスワードなどのクレデンシャル情報も生成してテナント管理者に通知してよい。以上の処理により、マーケットプレイスユーザ管理部１３６からテナントユーザ管理部１４６ａへの処理の移行経路と、テナントユーザ管理部１４６ａからマーケットプレイスユーザ管理部１３６を介してテナント管理者のプライベートページへ処理を戻す経路が形成される。
　結果として図２８と同様、マーケットプレイスユーザ管理部１３６とテナントユーザ管理部１４６で連携体制（フェデレーション）が確立し、テナント１４４側での認証や認可を、ＭＰＳ１０へのログイン時にも利用できる。なお図３３では省略しているが、テナントユーザ管理部１４６ａは図２８と同様、コンピュータシステム１とは別のシステムと連携してよい。
　図３４は、第２の実施形態における、テナント管理者のログイン処理の手順を示している。まずＭＰＳ１０ａにログインする場合、テナント管理者は、購入管理部５４ａが提供するグローバルページへアクセスする。そして管理者端末１６０にログイン用画面を表示させたうえ、ユーザＩＤやパスワードなど認証に必要な情報を入力することによりログインを要求する（Ｓ６３０）。購入管理部５４ａのログイン処理部１３２がそれを取得し、ブラウザをマーケットプレイスユーザ管理部１３６ａにリダイレクトする（Ｓ６３２）。
　マーケットプレイスユーザ管理部１３６ａの連携部１７０は、ログイン要求元のテナント管理者に対応するテナント１４４ａを、ユーザ情報記憶部１３８に格納されたユーザ情報に基づき特定する。あるいは連携部１７０は、テナントの選択画面を管理者端末１６０に表示させ、テナント管理者による選択を受け付けてもよい。そして連携部１７０は、当該テナント１４４ａのテナントユーザ管理部１４６ａにさらにリダイレクトする（Ｓ６３２）。テナントユーザ管理部１４６ａは、テナント作成時にテナント管理者に通知したクレデンシャル情報の入力を促すなどして認証処理を実施する。
　認証が成功したら、テナントユーザ管理部１４６ａはマーケットプレイスユーザ管理部１３６ａにコールバックする（Ｓ６３２）。マーケットプレイスユーザ管理部１３６ａの連携部１７０は、ログイン要求元のテナント管理者のプライベートページのＵＲＬを、ユーザ情報記憶部１３８に格納されたユーザ情報に基づき特定する。そして当該ＵＲＬにコールバックすることにより（Ｓ６３２）、管理者端末１６０を介してユーザにプライベートページが提示される（Ｓ６３４）。
　この段階でテナント管理者は、テナントユーザ管理部１４６ａ自体の認証を得た状態である。したがって購入管理部５４ａが提供するプライベートページから、テナント１４４ａのアプリケーション処理部１５２が提供するページへ表示を切り替えた場合（Ｓ６３６）、管理者端末１６０にはログイン後の画面が提示される（Ｓ６３８）。すなわちログインの入り口が異なっていても、テナント１４４ａ側で認証を受けることにより、そのままテナント１４４ａのサービスを利用できることになる。
　第２の実施形態における一般ユーザのログイン処理の手順は、第１の実施形態の図３０、３１で示した手順と同様でよい。テナント管理者がＭＰＳ１０ａにログインせずに、直接テナント１４４ａのクライアントへのログインを要求した場合も、一般ユーザと同じ手順でログイン処理がなされる。
　以上述べた第２の実施形態によれば、テナント管理者のユーザ情報を、テナントの作成とともにテナントユーザ管理部１４６ａに自動的に登録する。これによりテナント管理者は、ＭＰＳ１０ａにログインした状態でそのままテナントのサービスを利用でき、ログイン作業の手間を最小限に抑えられる。また認証に必要なパスワードなどの情報はテナント１４４ａで一元管理できるため、安全性をより高めることができる。さらに第１の実施形態で述べた効果も同様に得ることができる。
　以上、本発明を実施の形態をもとに説明した。上記実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
　以上のように本発明は、ネットワークサービスを提供する各種システム、当該システムの管理装置、当該システムの管理を支援する装置などに利用可能である。
　１　コンピュータシステム、　１０　マーケットプレイスシステム、１２　ネットワークオペレーティングシステム、　１４　購入者端末、　５４　購入管理部、　６２　Ｅ２ＥＯ部、　１３０　登録受付部、　１３２　ログイン処理部、　１３４　購入受付部、　１３６　マーケットプレイスユーザ管理部、　１３８　ユーザ情報記憶部、　１４０　クライアント情報記憶部、　１４２　クライアント登録部、　１４４　テナント、　１４６　テナントユーザ管理部、　１４８　ユーザ情報記憶部、　１５０　連携部、　１５２　アプリケーション処理部、　１７０　連携部、　１７２　オーナー端末、　１７４　ユーザ登録部、　１７８　クライアント情報記憶部。

Claims (12)

  1. 　複数のテナントのそれぞれに対応するサービスを提供するコンピュータシステムであって、
    　テナント生成要求を受け付けテナントを生成するテナント生成システムと、
    　生成されたテナントを稼働させるテナント稼働システムを含み、
    　前記テナント稼働システムは、前記サービスを利用するユーザの認証および認可を行うテナントユーザ管理部を、前記テナント生成システムと分離して備えることを特徴とするコンピュータシステム。
  2. 　前記テナント稼働システムは、テナントごとに、そのサービスを利用するユーザの認証および認可を行う前記テナントユーザ管理部を備えることを特徴とする請求項１に記載のコンピュータシステム。
  3. 　前記テナント生成システムは、前記テナント生成要求を行うユーザの認証および認可を行うテナント生成システム内ユーザ管理部を備え、
    　前記テナントユーザ管理部は、前記サービスを利用するユーザの少なくとも一部について、前記テナント生成システム内ユーザ管理部に処理を委託することを特徴とする請求項１または２に記載のコンピュータシステム。
  4. 　前記テナントユーザ管理部は、前記テナント生成要求のために前記テナント生成システムにおいてユーザ登録を行ったユーザの認証および認可を、前記テナント生成システム内ユーザ管理部に委託することを特徴とする請求項３に記載のコンピュータシステム。
  5. 　前記テナント生成システムは、前記テナントユーザ管理部からの委託要求を受け付け、認証後にクライアントへ処理を戻すためのクライアント情報を格納したクライアント情報記憶部を備えることを特徴とする請求項４に記載のコンピュータシステム。
  6. 　前記テナント生成システムは、自システム内へのログインを要求したユーザの認証および認可を、当該ユーザが生成要求したテナントの前記テナントユーザ管理部に委託することを特徴とする請求項１または２に記載のコンピュータシステム。
  7. 　前記テナント生成システムは、前記テナント生成要求をしたユーザと生成されたテナントを識別する情報を対応づけて格納するユーザ情報記憶部を備え、
    　前記テナント生成システムは、前記ユーザ情報記憶部を参照して委託先のテナントを特定することを特徴とする請求項６に記載のコンピュータシステム。
  8. 　前記テナント生成システムは、前記テナント生成要求をしたユーザと、前記テナント生成システムにおける当該ユーザのプライベートページのＵＲＬ（Uniform Resource Locator）を対応づけて格納するユーザ情報記憶部を備え、
    　前記テナント生成システムは、前記ユーザ情報記憶部を参照して、委託先での認証後の表示を前記プライベートページへ遷移させることを特徴とする請求項６または７に記載のコンピュータシステム。
  9. 　前記テナント生成システムは、自システムに対するユーザ登録要求を前記テナント生成要求として受け付け、テナントの生成とともに、当該ユーザに係る情報を、生成したテナントの前記テナントユーザ管理部に格納することを特徴とする請求項６から８のいずれかに記載のコンピュータシステム。
  10. 　前記テナント生成システムは、テナントの生成において、対応する前記テナントユーザ管理部を生成することを特徴とする請求項１から９のいずれかに記載のコンピュータシステム。
  11. 　前記テナント生成システムは、個別のコンテナとして各テナントユーザ管理部を生成することを特徴とする請求項１０に記載のコンピュータシステム。
  12. 　複数のテナントのそれぞれに対応するサービスを提供するコンピュータシステムにおいて、
    　テナント生成システムが、テナント生成要求を受け付けテナントを生成するステップと、
    　テナント稼働システムが、生成されたテナントを稼働させるステップと、
    　前記テナント稼働システムが、前記サービスを利用するユーザの認証および認可を、前記テナント生成システムと分離されたテナントユーザ管理部において行うステップと、
    　を含むことを特徴とするユーザ管理方法。
PCT/JP2021/002184 2021-01-22 2021-01-22 コンピュータシステムおよびユーザ管理方法 WO2022157912A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/JP2021/002184 WO2022157912A1 (ja) 2021-01-22 2021-01-22 コンピュータシステムおよびユーザ管理方法
US18/033,706 US20230394126A1 (en) 2021-01-22 2021-01-22 Computer system and user management method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2021/002184 WO2022157912A1 (ja) 2021-01-22 2021-01-22 コンピュータシステムおよびユーザ管理方法

Publications (1)

Publication Number Publication Date
WO2022157912A1 true WO2022157912A1 (ja) 2022-07-28

Family

ID=82549601

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2021/002184 WO2022157912A1 (ja) 2021-01-22 2021-01-22 コンピュータシステムおよびユーザ管理方法

Country Status (2)

Country Link
US (1) US20230394126A1 (ja)
WO (1) WO2022157912A1 (ja)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013182310A (ja) * 2012-02-29 2013-09-12 Mitsubishi Electric Corp アクセス制御装置及びアクセス制御方法及びプログラム
JP2019532418A (ja) * 2016-09-16 2019-11-07 オラクル・インターナショナル・コーポレイション マルチテナントアイデンティティおよびデータセキュリティ管理クラウドサービスのためのテナントおよびサービス管理
JP2020112886A (ja) * 2019-01-08 2020-07-27 株式会社リコー サービスシステム、クラウドサービス、ユーザ登録方法、プログラム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013182310A (ja) * 2012-02-29 2013-09-12 Mitsubishi Electric Corp アクセス制御装置及びアクセス制御方法及びプログラム
JP2019532418A (ja) * 2016-09-16 2019-11-07 オラクル・インターナショナル・コーポレイション マルチテナントアイデンティティおよびデータセキュリティ管理クラウドサービスのためのテナントおよびサービス管理
JP2020112886A (ja) * 2019-01-08 2020-07-27 株式会社リコー サービスシステム、クラウドサービス、ユーザ登録方法、プログラム

Also Published As

Publication number Publication date
US20230394126A1 (en) 2023-12-07

Similar Documents

Publication Publication Date Title
US10361843B1 (en) Native blockchain platform for improving workload mobility in telecommunication networks
EP3207678B1 (en) Lawful intercept management modules and methods for li configuration of an internal interception function in a cloud based network
CN102947797B (zh) 使用横向扩展目录特征的在线服务访问控制
US20050257244A1 (en) Method and apparatus for role-based security policy management
CN107615799A (zh) 网络中个体会话的准入
EP4113911A1 (en) Network service construction system and network service construction method
TW201141126A (en) Apparatus and methods for managing network resources
WO2018037453A1 (ja) 認証システム、ならびに、情報記録媒体
JP2019514090A (ja) ユーザアカウントと企業ワークスペースとの関連付け
EP4113914A1 (en) Resource pool management system, resource pool management method and program
WO2022074435A1 (ja) ネットワークサービス管理システムおよびネットワークサービス管理方法
US20130182288A1 (en) Account management system
JP2015032056A (ja) メニュー制御方法、メニュー制御装置およびメニュー制御プログラム
WO2011040192A1 (ja) 仮想マシン、仮想マシンのプログラム、アプリケーションサービス提供システム及びアプリケーションサービス提供方法
WO2022157912A1 (ja) コンピュータシステムおよびユーザ管理方法
JP2020119147A (ja) システム、テナントの移動方法、情報処理装置およびその制御方法、認可サーバーおよびその制御方法、並びにプログラム
JP6957223B2 (ja) 情報処理システム、制御方法及びそのプログラム
EP4113915A1 (en) Network service construction system and network service construction method
JP2012231293A (ja) 中継サーバ及び中継通信システム
JP7477657B2 (ja) ネットワークサービス管理システムおよびネットワークサービス管理方法
WO2018004407A1 (en) Systems and methods for service access control
WO2020209161A1 (ja) 制御装置、無線通信システム、制御方法及びプログラム
JP2021158466A (ja) 中継装置、中継システム、及びプログラム
JP2021196908A (ja) サーバ装置、システム、制御方法及びプログラム
JP2019003317A (ja) 本人認証装置、本人認証システム、本人認証プログラム、および、本人認証方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21921023

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21921023

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: JP