JP2019003477A - 情報処理システム、制御方法及びそのプログラム - Google Patents

Abstract

【課題】 サービス提供ルートを構成する複数のテナントに紐付くアクセスポリシーがまとめて同意されることで、サービス提供ルートに対する複数のアクセスポリシーの紐付けの手間を削減し、同意されたアクセスポリシーに従ってデバイスのデータの提供を制御する。
【解決手段】 複数のテナントに関連するそれぞれの要求アクセスポリシーに基づいて、特定の属性を有するデータに対象のテナントがアクセスすることに同意するための同意画面を提供する画面提供手段と、同意画面の内容にユーザーが同意したことにより同意コードを発行する発行手段と、同意コードがデバイスに入力され、入力された前記同意コードに関連付くそれぞれの要求アクセスポリシーに基づいて、同意コードが入力されたデバイスのデータの提供を制御するデータ制御手段と、を有する。
【選択図】 図８

Description

本発明は、デバイスのデータを管理する情報処理システム、制御方法及びそのプログラムに関するものである。

画像形成装置、プロジェクター、ネットワークカメラ等のデバイスがインターネットを介してクラウドシステムに接続されている状況下で、デバイスに格納されているデータをクラウドシステムに送信する形態がある。さらに、クラウドシステムに送信されたデータを、デバイスの製造者やデバイスの所有者等が活用する形態もある。

例えば、デバイスで障害が発生した場合は、製造者がデバイスの基盤やセンサー等のデータをクラウドシステムから取得して障害対応のサービスを提供する。また、デバイスが画像形成装置の場合、販売者やディーラーがコピー用紙やトナー等の消耗品に関するデータを取得して、課金したり消耗品を提供したりするサービスがある。さらに、デバイスの所有者がデバイスの利用状況を知りたい場合、デバイスの作業ログを集計したデータを所有者に提供するサービスもある。以下、デバイスのデータを用いてサービスを提供するユーザーをサービス提供者と呼称し、デバイスのデータを用いてサービス提供者が提供する新たなアウトプットをデバイスサービスと呼称する。サービス提供者が取得するデータの種類はデバイスサービスの内容によって異なる。

また、サービス提供者に関するデータはテナント単位で管理されている場合がある。テナントとは、複数のユーザーや企業等のデータを集約したグループのことである。その場合に、各テナントに所属するサービス提供者がアクセスできるデータを予め設定することで、設定されたデータに基づいて上記のようなデバイスサービスをサービス提供者が提供できる。

さらに、個人情報の保護の観点から、デバイスのデータにアクセスする際はそのデバイスの所有者からの許可を得る必要がある。デバイスの所有者からの許可により、テナントまたはそのテナントに所属するサービス提供者がデバイスのデータにアクセスできるようになる。サービス提供者がアクセスできるデータを定めたルールをアクセスポリシーという。特許文献１には、認証されたユーザーに対してアクセスポリシーを作成するコンピュータサーバーについて開示されている。

特許第４１４３５２６号

しかし、デバイスが製造されてから顧客先で稼働するまでの販売ルート（以下、サービス提供ルート）においてデバイスは様々なテナントと関与する。そのため、サービス提供者がデバイスのデータを用いてデバイスサービスを提供する場合、サービス提供者が所属するテナントとそのテナントがアクセスするデータとの組み合わせは複雑になり、それに伴って定めなければならないアクセスポリシーの種類も多岐にわたる。その結果、アクセスポリシーの設定が煩雑となる。

本願発明は、サービス提供ルートを構成する複数のテナントに紐付くアクセスポリシーがまとめて同意されることで、サービス提供ルートに対する複数のアクセスポリシーの紐付けの手間を削減し、同意されたアクセスポリシーに従ってデバイスのデータの提供を制御することを目的とする。

上記課題を解決するために本発明は以下の構成を有する。デバイスのデータを保存する保存する保存手段と、前記保存手段によって保存されるデータの属性情報と前記データにアクセス可能なテナントを特定するためのテナント情報とを紐付けた要求アクセスポリシーを生成する生成手段と、を有する情報処理システムであって、前記情報処理システムにログインしたユーザーが所属するユーザーテナントを特定し、特定されたユーザーテナントを含むサービス提供ルートを構成する複数のテナントを特定する特定手段と、前記特定手段によって特定された複数のテナントに関連するそれぞれの要求アクセスポリシーに基づいて、特定の属性を有するデータに対象のテナントがアクセスすることに同意するための同意画面を提供する画面提供手段と、前記画面提供手段によって提供された同意画面の内容に対して前記ユーザーが同意したことにより同意コードを発行する発行手段と、前記発行手段によって発行された前記同意コードが前記デバイスに入力され、入力された前記同意コードに関連付く前記それぞれの要求アクセスポリシーに基づいて、前記同意コードが入力された前記デバイスのデータの提供を制御するデータ制御手段と、を有する。

本願発明により、サービス提供ルートを構成する複数のテナントに紐付くアクセスポリシーがまとめて同意されることで、サービス提供ルートに対する複数のアクセスポリシーの紐付けの手間を削減し、同意されたアクセスポリシーに従ってデバイスのデータの提供を制御することができる。

システム構成図 情報処理装置２００の内部構成図 認証認可サーバー１１０、リソースサーバー１２０、データ管理サーバー１３０、クライアントデバイス１４０、デバイス１５０が有する機能に関する図 デバイス１５０がデータ管理サーバー１３０によって認証され、デバイス１５０からデータ管理サーバー１３０に対してデータを送信する処理を示すシーケンス図 テナントの構成の模式図 要求アクセスポリシーを作成するためのフロー図 要求アクセスポリシーに同意するためのデータアクセス同意画面の一例 本同意画面７０２に表示すべき要求アクセスポリシーを列挙し、同意コードが発行するまでのフロー図 クライアントデバイス１４０の同意コード発行画面の一例 デバイス１５０の同意コード入力画面の一例 デバイス１５０のデータをユーザーが取得する処理のシーケンス図 実施例２における、要求アクセスポリシーに同意するためのデータアクセス同意画面の一例 実施例２における、本同意画面１１０２に表示すべき要求アクセスポリシーを列挙するためのフロー図

以下、本発明を実施するための最良の形態について実施例を用いて説明する。

［実施例１］
図１を用いて、本実施形態に係る情報処理システム１６０とそのネットワークを構成している各種装置について説明する。ソフトウェアアプリケーションとは、情報処理システム１６０を構成するサーバー上で実行されたアプリケーションが提供する機能または機能群のことである。図１では、Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＷＡＮ）１００を経由してクライアントデバイス１４０とデバイス１５０とが、情報処理システム１６０を構築するサーバー群と接続されており、Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ（ＷＷＷ）が構築されている。ＷＡＮ１００はＬｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＬＡＮ）１０１によって各デバイスや各サーバーと接続されている。

情報処理システム１６０は、認証認可サーバー１１０とリソースサーバー１２０とデータ管理サーバー１３０とで構成されている。認証認可サーバー１１０は画像形成装置やプロジェクター等のデバイス１５０を認証する。後述の実施例では、デバイス１５０が１台の場合を例に説明するが、デバイス１５０は複数台あっても良い。リソースサーバー１２０はデバイス１５０のデータを用いてデバイス１５０の保守をサポートする保守サービスなどの様々なデバイスサービスをユーザーに提供する。データ管理サーバー１３０は、デバイス１５０からのデータの受信、データの保管、リソースサーバー１２０からのデータ要求への応答を行う。

図１では各サーバー１００〜１３０が１台ずつ設置されている場合を示しているが、各サーバーは複数台でも良く、さらに、各サーバー１００〜１３０の機能を有する１台のサーバーが設置されている形態でもよい。クライアントデバイス１４０は、生成された要求アクセスポリシーとデータとを紐付けるための同意コードを発行する機能を有する。要求アクセスポリシーとは、テナントとそのテナントがアクセスできるデータ（またはデータの種類）を定めたルールであり、詳細は後述する。クライアントデバイス１４０の例としてはパソコンやモバイル端末等が挙げられる。デバイス１５０は、デバイスサービスをユーザーが利用するために必要なデータを情報処理システム１６０に送信し、さらには入力された同意コードを情報処理システム１６０に送信する機能を有する。

図２は、図１に示した情報処理システム１６０を構成する認証認可サーバー１１０、リソースサーバー１２０、データ管理サーバー１３０の情報処理装置２００の内部構成について示したブロック図である。なお、図２に示されるブロック図は、クライアントデバイス１４０およびデバイス１５０も情報処理装置２００と同様の内部構造を有しているものとする。

ＣＰＵ２３１は、ＲＡＭ２３２、ＲＯＭ２３３、外部メモリ２４１などからプログラムを取り出してプログラムの命令を実行し、情報処理装置２００の制御を行うユニットである。後述のシーケンスはこのプログラムの命令が実行されることにより実現される処理である。また、ＣＰＵ２３１はシステムバス２３４に接続される各ブロックを制御する。

ＲＡＭ２３２は、ＣＰＵ２３１が命令を実行する際に使用するワークメモリである。ＲＯＭ２３３に保存されたプログラムがＲＡＭ２３２へとロードされ、そのプログラムの命令をＣＰＵ２３１が順次読みだし命令を実行する。ＲＯＭ２３３は、アプリケーションプログラムおよびＯＳを含む組込済みプログラム、およびデータ等が記録されている記憶装置である。

操作部Ｉ／Ｆ２３５は、操作部２３９からの入力を制御するユニットである。ＣＲＴＣ（Ｃａｔｈｏｄｅ Ｒａｙ Ｔｕｂｅ Ｃｏｎｔｒｏｌｌｅｒ）２３６は、ＣＲＴディスプレイ２４０の表示を制御するユニットである。ＤＫＣ（Ｄｉｓｋ Ｃｏｎｔｒｏｌｌｅｒ）２３７は外部メモリ２４１に対するデータアクセスを制御するユニットである。ＮＣ（Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌｌｅｒ）２３８はＷＡＮ１００またはＬＡＮ１０１を介して接続されたサーバー群や他の機器との通信制御処理を実行するユニットである。尚、後述の全ての説明においては、特に断りのない限り、サーバーやデバイス等のハード上の主体はＣＰＵ２３１であり、ソフトウェア上の主体は外部メモリ２４１にインストールされたアプリケーションプログラムである。

図３を用いて、認証認可サーバー１１０、リソースサーバー１２０、データ管理サーバー１３０、クライアントデバイス１４０、デバイス１５０が有する機能について説明する。認証認可サーバー１１０は認証認可部３１０、テナント管理部３１１、ライセンス管理部３１２を有する。認証認可部３１０は、各テナントに所属するサービス提供者を認証し、認証されたサービス提供者を認可する機能を有する。テナント管理部３１１はテナントに関する情報を管理する機能である。ライセンス管理部３１２はサービス提供ルートを管理する機能である。具体的には、サービス提供ルートを構成するテナントや、販売テナントに所属するサービス提供者がサービスを提供するサービス提供先の顧客テナントに関する情報（以下、ライセンス）を管理する機能である。以降、「テナントに所属するサービス提供者がサービスを提供する」等の表現を、「テナントがサービスを提供する」等のようにテナントを主語にして表現するものとする。

リソースサーバー１２０はリソースサーバー部３２０を有する。リソースサーバー部３２０はソフトウェアアプリケーションを実現するためのＡＰＩを公開し、公開されているＡＰＩを実行することで、クライアントデバイス１４０またはデバイス１５０からの要求に応じてソフトウェアアプリケーションを提供する。また、リソースサーバー部３２０は、クライアントデバイス１４０やデバイス１５０からの要求に対して、署名付きアクセストークンの検証処理を行うことで受信したリクエストの内容の改竄を検知し、ソフトウェアアプリケーションを提供するかを決定する。

データ管理サーバー１３０はデータ受信部３３０、データ提供部３３１、アクセスポリシー管理部３３２を有する。データ受信部３３０はデバイス１５０からのデータを受信し、受信したデータを保管する。データ提供部３３１はリソースサーバー１２０からのデータ提供要求を受信し、受信したデータ提供要求の内容に応じてデータを提供する。アクセスポリシー管理部３３２は、デバイス１５０の各種データに対してアクセスしてよいテナントに関する情報を管理する機能である。

クライアントデバイス１４０はＷｅｂブラウザ３４１を有する。Ｗｅｂブラウザ３４１は、ＷＷＷを利用するためのユーザーエージェントによって実現する機能である。デバイス１５０は、認証認可サーバー連携部３５１とデータ送信部３５２を有する。認証認可サーバー連携部３５１は認証認可サーバー１１０に対して、デバイス１５０の認証の要求、アクセストークンの発行依頼やアクセスを行う。データ送信部３５２は、デバイス１５０のデータをデータ管理サーバー１３０に送信する機能である。

図４を用いて、デバイス１５０がデータ管理サーバー１３０によって認証され、デバイス１５０からデータ管理サーバー１３０に対してデータを送信する処理を説明する。本処理は、デバイス１５０から定期的に実行されたり、デバイス１５０でイベントが発生したときに実行されたりすることにより開始される。

データ送信部３５２は、認証認可サーバー連携部３５１にアクセストークンの発行要求を行う（Ｓ４０１）。認証認可サーバー連携部３５１は、認証認可サーバー連携部３５１が管理しているデバイスＩＤとパスワードとを認証認可部３１０に送信し、アクセストークン発行要求を行う（Ｓ４０２）。デバイスＩＤは、デバイス１５０を識別するための識別情報である。パスワードはデバイス１５０を認証するための情報であり、デバイス１５０になりすました別のデバイスが、情報処理システム１６０のソフトウェアアプリケーションを不正に使用することを防ぐ。認証認可部３１０が管理しているデバイスＩＤとパスワードのテーブルの一例を表１に示す。

本実施例では、事前にデバイス１５０に登録されていたデバイスＩＤとパスワードとを認証認可サーバー１１０に送信する形態で説明したが、デバイスＩＤを認証認可サーバー１１０で生成する方法も考えられる。具体的には、デバイス１５０にデバイスＩＤを発行するための秘密の情報を事前に登録し、その秘密の情報を認証認可サーバー１１０に送信することで、デバイス１５０のデバイスＩＤが生成される方法がある。

認証認可部３１０は、Ｓ４０２でアクセストークン発行要求とともに受信したデバイスＩＤとパスワードのペアと、予め認証認可部３１０で管理しているペア（表１）とを照合し、デバイス１５０を認証する（Ｓ４０３）。認証方法はデバイスＩＤとパスワードとのペアに留まらず、デバイス証明書による認証方法等でもよい。Ｓ４０３においてデバイス１５０が認証された後、認証認可部３１０はアクセストークンを発行して（Ｓ４０４）認証認可サーバー連携部３５１に送信する（Ｓ４０５）。

認証認可サーバー連携部３５１は、受信したアクセストークンをデータ送信部３５２に送信する（Ｓ４０６）。データ送信部３５２は、アクセストークンとデバイス１５０のデータとをデータ受信部３３０に送信する（Ｓ４０７）。デバイス１５０のデータの例としては、デバッグログやステータス情報、ジョブログ等が挙げられる。データ受信部３３０はＳ４０７でデータとともに受信したアクセストークンの検証を行う（Ｓ４０８）。本実施例におけるアクセストークンは、ＲＦＣ７５１９で決められたＪＳＯＮ Ｗｅｂ Ｔｏｋｅｎ（ＪＷＴ）の仕様を想定しており、アクセストークンにはデバイスＩＤなどの情報が含まれる。ただし、アクセストークンはＪＷＴの仕様に限らず、ランダムな数字の形態であってもよい。データ受信部３３０は受信したアクセストークンを検証するための公開鍵を保持している。データ受信部３３０はその公開鍵を用いてアクセストークンを検証し、デバイスＩＤを取得することができる。なお、アクセストークンの検証方法として、データ受信部３３０が認証認可部３１０にアクセストークンの検証を依頼し、検証結果とデバイスＩＤとを認証認可部３１０から取得するといった別の方法でも良い。

データ受信部３３０はＳ４０７で受信したデータに対してデータ処理を行う（Ｓ４０９）。処理内容の具体例は、受信したデータを種別ごとに分類したり、デバイスＩＤに紐づけて保存したりする。本実施例では、データをデバッグログとステータス情報とジョブログの３種類に分類し、各データはデバイス１５０のデバイスＩＤと紐付いて管理されているものとする。データ処理はこの形態に留まらず、デバイス１５０のデータが格納されている別の場所を参照するための情報とデバイスＩＤとデバイス種別とが紐付いている形態でもよい。つまり、デバイス１５０を特定するための情報とデータの種別とに基づいて、各データがラベリングされている形態であればどのような形態でもよい。本実施例ではデバイス１５０のデータがデータ種別ごとに分類される形態を示しているが、データの発行日やロケーション、ドメイン等、他の条件でデータを分類する形態も可能である。

データ受信部３３０においてデータ処理が実行された後、データ受信部３３０はデータ送信部３５２に対して処理結果を応答する（Ｓ４１０）。以上が、デバイス１５０がデータ管理サーバー１３０によって認証され、デバイス１５０からデータ管理サーバー１３０にデータを送信する処理である。

次に図５を用いて、テナント管理部３１１が管理しているテナントに関する情報について説明する。図５はテナントの構成を模式的に表した図である。テナント管理部３１１は、テナント５０１〜５１４を一意に識別するテナントＩＤとテナント名とテナント種別に関する情報とを管理する。テナント管理部３１１が管理するテーブルの一例を表２に示す。

表２における「テナント種別」とは、デバイス１５０のデータを用いてデバイスサービスを提供するテナント（以下、販売テナント）、販売テナントによってデバイスサービスが提供されるテナント（以下、顧客テナント）とを種別するための情報である。今回は、テナント５０１〜５０７が販売テナント、テナント５１１〜５１４は顧客テナントであるものとする。

次に図５を用いて、テナントがライセンスを提供する卸先のテナントに関する情報について説明する。ライセンスに関する情報はライセンス管理部３１２で管理されており、管理されている情報の一例を表３に示す。表３に示したテーブルはライセンス管理部３１２に予め設定されている。

表３における「ライセンスＩＤ」はライセンスを一意に識別する識別情報である。また、「テナントＩＤ」とは、「ライセンス種別」で特定されるデバイスサービスを提供できるテナントを識別するＩＤである。今回、ライセンス種別で特定されるデバイスサービスの例として、「保守サービス」と「ＭＤＳ」（Ｍａｎａｇｅｄ Ｄｏｃｕｍｅｎｔ Ｓｅｒｖｉｃｅ）を例に挙げている。デバイス１５０が画像形成装置の場合、保守サービスとは、画像形成装置の課金や消耗品の状況確認等の保守を行うデバイスサービスのことである。ＭＤＳは、画像形成装置で誰がいつ何を印刷しているかを管理し、その企業の画像形成装置の利用状況をレポートし、画像形成装置の最適配置やリプレースの助けを行うデバイスサービスのことである。

「卸元テナント」とは、「テナントＩＤ」で識別されたテナントが「ライセンス種別」で識別されるデバイスサービスを提供することを許可したテナントであり、「卸元テナントＩＤ」はその卸元テナントを識別する識別情報である。

表３のテーブルは、各卸元テナントに所属するサービス提供者が情報処理システム１６０にログインし、そのサービス提供者がテナントにライセンスを付与することで設定される。例えばライセンスＩＤ「３」のライセンスの場合、卸元テナントＩＤが「１０１ＡＡ」なので、卸元テナントＩＤ「１０１ＡＡ」のテナントに所属するサービス提供者が、テナントＩＤ「１０２ＡＡ」のテナントに対し保守サービスを提供するためのライセンスを提供している。

また、表３より、テナントＩＤ「１０２ＡＡ」のテナントが卸元テナントとして保守サービスのライセンスを提供する提供先のテナントは、テナントＩＤ「１０６ＡＡ」（ライセンスＩＤ「１１」）である。さらに、テナントＩＤ「１０６ＡＡ」のテナントが卸元テナントとして保守サービスのライセンスを提供する提供先のテナントは、テナントＩＤ「１００２ＡＡ」（ライセンスＩＤ「１４」）である。このように表３より、卸元テナントがライセンスを提供する提供先のテナントを順次特定できる。

次に、マスターポリシーとその管理方法について説明する。マスターポリシーとは、デバイス１５０のデータにアクセスできる各種テナントを定義した情報である。マスターポリシーは予めアクセスポリシー管理部３３２において設定され、管理されている。管理されている情報の一例を表４に示す。

表４の「マスターポリシーＩＤ」はマスターポリシーを一意に識別するＩＤであり、「データ種別」はデバイス１５０のデータの種類を示す。「アクセス元テナントルール」はデータ種別で指定されたデータにアクセスできるテナントの種類を示す。本実施例では表４のように、４種類のアクセス元テナントルールが定義されているものとする。「ルートテナント」はライセンスを提供する提供元の最上位のテナントであり、具体的にはテナント５０１がそれに相当する。「販売ツリーテナント」は販売テナントのツリーを構成する販売テナントであり、具体的にはテナント５１１〜５１４以外の全てのテナントがそれに相当する。「サービス提供テナント」は顧客テナントに対してライセンスを提供する販売テナントのことであり、具体的にはテナント５０２、５０４〜５０７がそれに相当する。「サービス利用テナント」は最終的にライセンスが付与される顧客テナントのことであり、具体的にはテナント５１１〜５１４がそれに相当する。上記の例で示した通り、複数のアクセス元テナントルールを満たすテナントがあってもよく、例えばテナント５０２、５０４〜５０７は販売ツリーテナントでもあり、サービス提供テナントでもある。

表４において例えば、マスターポリシーＩＤ「２」の場合、ステータス情報に販売ツリーテナントがアクセスできると定義されている。例えば、顧客テナント「１００２ＡＡ」に提供されている保守サービスの場合、販売ツリーテナントは「１０６ＡＡ」、「１０２ＡＡ」、「１０１ＡＡ」であり、「１０６ＡＡ」、「１０２ＡＡ」、「１０１ＡＡ」がステータス情報にアクセスできることになる。以上が、マスターポリシーとその管理方法である。

アクセス元テナントルールの設定方法は、表４で挙げた形態に限定されない。例えば、複数のテナントによってグループが構成させることでグループという他の属性値を持たせ、属性値がある特定のグループの場合にマスターポリシーが有効になるといった形態も考えられる。また、販売ツリーに属するテナント且つある特定の属性値を有する場合、またはテナントがある特定のテナントである場合に、マスターポリシーを有効にする形態等が考えられる。

次に、ライセンスとそのライセンスが提供されるテナントについて、表５を用いて説明する。表５は予めアクセスポリシー管理部３３２において設定されており、各種テナントがデバイス１５０のデータを用いて提供できるライセンスを定義している。表５より、例えば保守サービスのライセンスがマスターポリシーＩＤ「１」と紐付いて管理されていることから、ルートテナントに属したテナントが保守サービスを提供できることが分かる。

次に、要求アクセスポリシーの生成方法について図６を用いて説明する。図６は、アクセスポリシー管理部３３２が要求アクセスポリシーを生成する処理を実行するためのフロー図であり、ライセンス管理部３１２がテナントにライセンスを割り当てて、ライセンスに関する情報（表３）を生成する処理をきっかけに開始される。要求アクセスポリシーとは、テナントがアクセスできるデバイス１５０のデータを定義した情報である。デバイス１５０のデータにアクセスできるテナントの種類を定義したマスターポリシーとは異なり、要求アクセスポリシーは、デバイス１５０のデータにアクセスできるテナントを一意に定義している。

まず、ライセンスＩＤに紐付くマスターポリシーＩＤを特定し、特定されたマスターポリシーＩＤを取得する（Ｓ６０１）。具体的には、ライセンスＩＤ「１」が割り当てられた際には、表３よりライセンスＩＤ「１」で提供できるデバイスサービスは保守サービスなので、表５より保守サービスのライセンスＩＤに紐づくマスターポリシーＩＤ「１，２」が取得される。

次に、アクセスポリシー管理部３３２が表４より、Ｓ６０１で取得したマスターポリシーＩＤと紐づいたアクセス元テナントルールを取得し（Ｓ６０２）、今回要求アクセスポリシーを生成する対象となっているテナントがそのアクセス元テナントルールを満たすかどうかを確認する（Ｓ６０３）。具体的には、今回はライセンスＩＤ「１」のテナント５０１を対象のテナントとすると、テナント５０１がマスターポリシーＩＤ「１」のアクセス元テナントルールであるルートテナントであるかを確認する。ライセンス管理部３１２が管理する情報（表３）よりテナント５０１の卸元テナントの値が存在しないことから、テナント５０１はルートテナントである。したがって、マスターポリシーＩＤ「１」のアクセス元テナントルールを満たし、ライセンスＩＤ「１」は要求アクセスポリシーを生成する対象となる。対象となる場合は要求アクセスポリシー生成（Ｓ６０４）に進み、ライセンスＩＤが生成の対象ではない場合はそのライセンスＩＤからは要求アクセスポリシーを生成しない（Ｓ６０５）。

対象としているテナントがアクセス元テナントルールを満たすかの判断（Ｓ６０３）で参照する情報は、表４のアクセス元テナントルールによって異なる。上記の例では、テナント５０１がルートテナントであるかを判断するために、ライセンス管理部３１２で管理されている情報を参照した。その他の例では、テナント５０１が「販売ツリーテナント」であるかを判断する場合、テナント管理部３１１が管理する情報（表２）を参照し、「テナント種別」が「販売」であるかを判断する。このように、アクセス元テナントルール毎に情報を参照する参照先を予め表４の情報に対して紐付けておくことで、アクセス元テナントルールに内容に応じて適切な情報を取得することができる。

Ｓ６０４において要求アクセスポリシーを生成した後、またはＳ６０５において要求アクセスポリシーを生成しなかった後は、対象としているテナントがマスターポリシーＩＤのアクセス元テナントルールを満たしているかどうかを全て確認できるまでＳ６０２〜Ｓ６０５の処理が繰り返される。今回は、マスターポリシーＩＤ「１」の処理の後に、マスターポリシーＩＤ「２」のアクセス元テナントルールを満たすかを確認する処理としてＳ６０２が再度実行される。

Ｓ６０４において生成された要求アクセスポリシーの一例を表６に示す。生成された要求アクセスポリシーはアクセスポリシー管理部３３２で管理される。表６における「要求アクセスポリシーＩＤ」は要求アクセスポリシーを一意に識別するＩＤである。図６の説明で例として挙げたライセンスＩＤ「１」の場合、生成された要求アクセスポリシーの要求アクセスポリシーＩＤは「１」と「２」である。

次に、生成された要求アクセスポリシーが同意され、同意された要求アクセスポリシーに応じてテナントがデバイス１５０のデータにアクセスするための処理について説明する。デバイス１５０の所有者等によって要求アクセスポリシーは同意される必要がある。要求アクセスポリシーが同意されたことで同意コードがクライアントデバイス１４０において発行される。発行された同意コードをユーザーがデバイス１５０に入力することで、要求アクセスポリシーに基づいてユーザーはデバイス１５０のデータにアクセスできるようになる。ここでのユーザーは、デバイス１５０のデータにアクセスできるテナントに所属するサービス提供者、あるいはデバイス１５０の所有者等であってもよく、同意コードをデバイス１５０に入力する人物は問わない。

Ｓ６０４で生成された要求アクセスポリシーを同意するための表示画面について、図７を用いて説明する。図７は、デバイス１５０の所有者がクライアントデバイス１４０において要求アクセスポリシーに同意する際に、Ｗｅｂブラウザ３４１に表示される表示画面である。この表示画面は、デバイス１５０の所有者がＷｅｂブラウザ３４１において情報処理システム１６０にログインしたことで、アクセスポリシー管理部３３２によって表示される。データアクセス同意画面７０１における本同意画面７０２には、生成された要求アクセスポリシーに基づき、デバイス１５０のデータにアクセスするテナントが列挙される。

図８を用いて、本同意画面７０２に表示すべき要求アクセスポリシーを列挙し、同意コードが発行されるまでの処理を説明する。図８のフロー図は、アクセスポリシー管理部３３２が主体となって実行される。まず、サービス提供ルートに基づいてライセンスが付与されるルートに従って、アクセスポリシー管理部３３２が順次処理を行う。その処理とは、情報処理システム１６０にログインしているサービス利用者が所属するテナントにライセンスが付与されるまでに経由したテナントを、アクセスポリシー管理部３３２がライセンス管理部３１２に格納されている情報（表３）を用いて特定する（Ｓ８０１）。例えば、情報処理システム１６０にログインしているユーザーが所属するテナントがテナント５１２（テナントＩＤは「１００２ＡＡ」）である場合、表３よりテナント５１２が利用できるライセンスのライセンスＩＤは「１４」であるとわかる。特定されたテナントとライセンスＩＤに対して紐付いている要求アクセスポリシーをアクセスポリシー管理部３３２が特定する（Ｓ８０２）。具体的には、表３を参照して、テナント５１２にライセンスが提供されるまでに経由したテナントと、そのライセンスＩＤを特定し、表６を参照してそのライセンスＩＤに紐付く要求アクセスポリシーＩＤを取得する。

アクセスポリシー管理部３３２は、対象としているテナントの利用できるライセンスとそれに紐付く要求アクセスポリシーを取得するまで、Ｓ８０１とＳ８０２の処理を繰り返す。今回の例の場合、Ｓ８０１とＳ８０２の処理を繰り返すことで、テナント５１２に保守サービスのライセンスを提供するまでに関与したテナントの卸元テナントＩＤは表３より「１０１ＡＡ」、「１０２ＡＡ」、「１０６ＡＡ」であるとわかり、各テナントＩＤに紐付くライセンスＩＤは「１」、「３」、「１１」であることがわかる。さらに、これらのライセンスＩＤと紐付く要求アクセスポリシーＩＤは表６より「１」、「２」、「５」、「１３」であると特定される。ここで、ライセンス種別が保守サービスである理由は、表３よりテナント５１２に対して提供されているライセンスのライセンス種別が「保守サービス」のみだからである。一つのテナントに対して複数種類のライセンスが提供されている場合は、各ライセンスに紐付く要求アクセスポリシーが特定されるまでＳ８０１とＳ８０２のステップをアクセスポリシー管理部３３２が繰り返すことになる。

Ｓ８０２において要求アクセスポリシーを特定された後、特定された要求アクセスポリシーに紐付くアクセス元テナントＩＤをアクセスポリシー管理部３３２がＷｅｂブラウザ３４１に送信し、Ｗｅｂブラウザ３４１はデータアクセス同意画面を表示する（Ｓ８０３）。アクセス元テナントＩＤとは、アクセス元テナントルールが適用されるテナントを識別するためのＩＤである。その際に表示されるデータアクセス同意画面の一例を図７のデータアクセス同意画面７０１に示す。今回、Ｓ８０２で特定された要求アクセスポリシーＩＤは「１」、「２」、「５」、「１３」だから、各要求アクセスポリシーＩＤと紐付くアクセス元テナントＩＤは、「１０１ＡＡ」（データ種別はデバッグログ）、「１０１ＡＡ」（データ種別はステータス情報）、「１０２ＡＡ」、「１０６ＡＡ」である。特定されたアクセス元テナントＩＤがデータアクセス同意画面７０１に表示されている。

データアクセス同意画面７０１の「同意する」ボタン７０３が押下されると、アクセスポリシー管理部３３２において同意情報が生成される（Ｓ８０４）。ここで同意情報とは、同意情報と一意に識別するための同意コードと、データアクセス同意画面７０１に表示される要求アクセスポリシーに関する情報（Ｓ８０２で取得した要求アクセスポリシー）と、その要求アクセスポリシーに同意することができるテナントに関する情報とを含む情報のことである。Ｗｅｂブラウザ３４１は同意コードを表示する（Ｓ８０５）。その表示画面の一例を図９のデータアクセス同意画面７２１に示す。

データアクセス同意画面７２１には同意コード７２２が表示される。Ｓ８０４で、アクセスポリシー管理部３３２において生成された同意情報の一例を表７に示す。今回の例で説明したテナント５１２（テナントＩＤ「１００２ＡＡ」）は、要求アクセスポリシーの内容を同意することができるテナントであり、要求アクセスポリシーに関連付いたテナントを経由して最終的にライセンスが付与されるテナントでもあるので、表７では要求アクセスポリシーＩＤリスト「１、２、５、１３」と紐付くテナントＩＤは「１００２ＡＡ」としている。また、テナントＩＤ「１００２ＡＡ」の場合、表７より同意コードは「ＡＢＣＤ１２３４５」であり、データアクセス同意画面７２１に同意コード７２２として表示されている。

以上が、本同意画面７０２に表示すべき要求アクセスポリシーを列挙し、同意コードがＷｅｂブラウザ３４１において表示するまでの処理である。Ｓ８０４において生成される同意コードは有効期限が設定されていても良い。

次に、Ｗｅｂブラウザ３４１に表示されるデータアクセス同意画面の別の形態を説明するために、情報処理システム１６０にログインしているサービス提供者が所属するテナントがテナント５１４（テナントＩＤ「１００４ＡＡ」）である場合を説明する。テナント５１４の場合のデータアクセス同意画面を図７の７１１に示す。要求アクセスポリシーを列挙するまでの処理はテナントＩＤ「１００２ＡＡ」の場合と同様なので、説明は省略する。テナントＩＤ「１００４ＡＡ」の場合、図８の処理の結果、ライセンスが提供されるまでに経由したテナントとそれに紐付く要求アクセスポリシーＩＤは「１、２、３、４、７、８、１１、１２、１４」であることが特定される。上記でも説明した通り、一つのテナント（今回はテナント５１４）に対して複数種類のライセンス（保守サービス、ＭＤＳサービス）が提供されている場合は、各ライセンスに紐付く要求アクセスポリシーが特定されるまでＳ８０１とＳ８０２のステップを繰り返すことになる。その結果、今回特定された要求アクセスポリシーＩＤが「１、２、３、４、７、８、１１、１２、１４」である。

要求アクセスポリシーＩＤが異なっても要求アクセス元テナントＩＤとデータ種別とが重複している場合がある。例えば、要求アクセスポリシーＩＤ「１」と「３」の場合、アクセス元テナントＩＤが「１０１ＡＡ」、データ種別が「デバッグログ」である。その場合、データアクセス同意画面７０１のように異なる要求アクセスポリシーＩＤを一つずつ列挙する表示形態も考えられるが、データアクセス同意画面７１１のように、重複する情報をマージして表示し一括で設定できる別の表示形態も考えられる。以上が、Ｗｅｂブラウザ３４１に表示されるデータアクセス同意画面の別の形態である。

次に、Ｓ８０３において同意された要求アクセスポリシーをデバイス１５０のデータと関連付ける処理に関して説明する。図１０は、デバイス１５０の不図示のＷｅｂブラウザに表示される同意コード入力画面である。Ｓ８０５でクライアントデバイス１４０において表示された同意コード（図９）を同意コード入力画面９０１にユーザーが入力することで、図１１の処理が開始される。図１１は、デバイス１５０のデータをユーザーが取得する処理のシーケンス図であり、図４と同様の処理については同じ符番を振り、説明は省略する。

Ｓ４０６においてデータ送信部３５２が認証認可サーバー連携部３５１からアクセストークンを取得した後、データ送信部３５２はアクセスポリシー管理部３３２に対してアクセストークンとともにＳ８０５で入手した同意コードを送信する（Ｓ１００１）。Ｓ１００１で送信される同意コードは、デバイス１５０の不図示のＷｅｂブラウザにおいてユーザーが入力した同意コードであり、入力された同意コードはデータ送信部３５２で管理されるものとする。

アクセスポリシー管理部３３２はＳ１００１で受信したアクセストークンの検証を行う（Ｓ１００２）。アクセスポリシー管理部３３２は受信したアクセストークンを検証するための公開鍵を保持している。アクセスポリシー管理部３３２はその公開鍵を用いてアクセストークンを検証し、デバイスＩＤと同意コードを取得することができる。なお、アクセストークンの検証方法として、アクセスポリシー管理部３３２が認証認可部３１０にアクセストークンの検証を依頼し、検証結果とデバイスＩＤとを認証認可部３１０から取得するといった別の方法でも良い。

Ｓ１００２においてアクセスポリシー管理部３３２はアクセストークンの検証を行った後、同意コードとアクセストークンに含まれていたデバイスＩＤとを紐づけて管理する（Ｓ１００３）。アクセスポリシー管理部３３２で管理されるデバイスＩＤと同意コードとの紐付け情報の一例を表８に示す。このように、同意コードを用いることで、同意コードが入力されたデバイス１５０のデータと要求アクセスポリシーが関連付く。

表８では、デバイスＩＤ「ｄｅｖ＿００００１」とデバイスＩＤ「ｄｅｖ＿００００２」の異なる２台のデバイス１５０に対して、同じ同意コード「ＡＢＣＤ１２３４５」が紐付いている形態を示している。ユーザーは複数の異なるデバイス１５０に対して同じ同意コードを入力することができ、その場合は表８のように同じ同意コードが異なるデバイスＩＤを紐付いて管理される。また、１台のデバイス１５０に対して複数の同意コードを入力することもでき、その場合は一つのデバイスＩＤに対して複数の異なる同意コードが紐づいて管理される。

アクセスポリシー管理部３３２でデバイスＩＤと同意コードとが紐付けられた後、アクセスポリシー管理部３３２はデータ送信部３５２に対してＳ１００１の要求への結果を応答する（Ｓ１００４）。以上が、デバイスＩＤと同意コードとを紐付ける処理である。デバイスＩＤは、デバイス１５０のデータを特定するための情報であり、同意コードは同意された要求アクセスポリシーを特定するための情報であるため、デバイスＩＤと同意コードとが紐づいたことで、要求アクセスポリシーとデバイス１５０のデータとが関連付いたことになる。

次に、データ管理サーバー１３０において管理されているデバイス１５０のデータにリソースサーバー１２０がアクセスしてデータを取得する処理について、引き続き図１１（Ｓ１００５〜）を用いて説明する。この処理（Ｓ１００５〜）はリソースサーバー部３２０がデータ提供部３３１に対してデータ取得要求を送信したことで開始される。また、リソースサーバー部３２０がデータ提供部に対してデータの取得要求を送信する処理は、ユーザーが図１１では不図示のＷｅｂブラウザ３４１から、リソースサーバー部３２０に対してデータの取得要求を送信することで開始される。その開始形態以外にも、リソースサーバー部３２０がデータ提供部３３１に対して定期的にデータの取得要求を送信し、結果的に得られたデータを用いてリソースサーバー部３２０がバッチ処理を行う形態等も考えられる。

リソースサーバー１２０はデータ提供部３３１に対して、データの取得要求としてアクセス元テナントＩＤとデータ種別を送信する（Ｓ１００５）。具体的には、アクセス元テナントＩＤ「１０６ＡＡ」、データ種別「ステータス情報」がデータ提供部３３１に対して送信されたものとする。データ提供部３３１はアクセスポリシー管理部３３２に対して、デバイスＩＤの取得要求がアクセス元テナントＩＤとともに送信される（Ｓ１００６）。

アクセスポリシー管理部３３２は、受信したアクセス元テナントＩＤに紐付くデバイスＩＤを特定する（Ｓ１００７）。具体的には、アクセスポリシー管理部３３２で管理されている要求アクセスポリシー（表６）より、Ｓ１００６で受信したアクセス元テナントＩＤに合致する要求アクセスポリシーＩＤを特定する。特定された要求アクセスポリシーＩＤと紐付く同意コードを、アクセスポリシー管理部３３２で管理されている同意情報（表７）を用いて特定する。特定された同意コードとそれに紐付くデバイスＩＤを特定する。今回であれば、アクセス元テナントＩＤ「１０６ＡＡ」に対して紐付く要求アクセスポリシーＩＤは表６より「１３」である。表７より、要求アクセスポリシーＩＤ「１３」に紐付く同意コードは「ＡＢＣＤ１２３４５」であり、表８より同意コード「ＡＢＣＤ１２３４５」に紐付くデバイスＩＤは「ｄｅｖ＿００００１」であることがわかる。

Ｓ１００７で特定されたデバイスＩＤはデータ提供部３３１に送信される（Ｓ１００８）。Ｓ１００７で特定されたデバイスＩＤが複数存在する場合は、特定された複数のデバイスＩＤをまとめたリストがデータ提供部３３１に送信される。今回は、Ｓ１００６において特定されたデバイスＩＤ「ｄｅｖ＿００００１」がデータ提供部３３１に送信される。Ｓ４０９でデバイスＩＤとデータ種別ごとに分類したデータから、Ｓ１００６で取得したデバイスＩＤとＳ１００５で受信したデータ種別に対して紐付くデータをリソースサーバー部３２０に応答する（Ｓ１００９）。今回は、デバイスＩＤ「ｄｅｖ＿００００１」とデータ種別「ステータス情報」に紐付くデータが特定されて、リソースサーバー部３２０に送信される。これにより、許可された要求アクセスポリシーの範囲内でデバイス１５０のデータをリソースサーバー部３２０は取得できる。

Ｓ１００７において、アクセス元テナントＩＤに紐付くデバイスＩＤを特定できなかった場合、エラー通知がデータ提供部３３１を介してリソースサーバー部３２０に送信される。

実施例１より、デバイスの所有者によって要求アクセスポリシーがまとめて許可されることによって、サービス提供ルートに対する複数の要求アクセスポリシーの紐付けの手間を削減し、同意された要求アクセスポリシーに従って各テナントにデバイスのデータを提供できる。

［実施例２］
実施例１において、クライアントデバイス１４０において表示された要求アクセスポリシーを、デバイスの所有者がまとめて許可される形態を示した。実施例２では、サービス提供ルートの途中のテナントに所属するサービス提供者が、要求アクセスポリシーの内容への同意を拒否する場合について、図１１と図１２を用いて説明する。ただし、実施例２に記載されていない部分は、実施例１に記載されていることと同じである。

図１２のアクセスポリシー継承設定画面１１０１は、図７の場合と同様に、アクセスポリシー管理部３３２で管理されている要求アクセスポリシーの情報に基づいてＷｅｂブラウザ３４１に表示される表示画面である。ただし、図１２は、テナントＩＤ「１０６ＡＡ」の日本ディーラーテナントに所属するサービス提供者が情報処理システム１６０にログインしたことで表示された場合の一例である。図８で示した同様の処理を行い、テナントＩＤ「１０６ＡＡ」が同意できる要求アクセスポリシーをアクセスポリシー継承設定画面１１０１において列挙する。列挙された要求アクセスポリシーの要求アクセスポリシーＩＤは「１」、「２」、「５」、「１３」であり、本同意画面１１０２に表示されている。各要求アクセスポリシーＩＤの横にはチェックボックスが設けられており、内容に同意しない要求アクセスポリシーがある場合は、その要求アクセスポリシーＩＤの横のチェックを外し、「設定する」ボタン（１１０３）を押下する。その結果、内容に同意しない要求アクセスポリシーに関する情報がアクセスポリシー管理部３３２で生成される。生成された情報の一例を表９に示す。表９における「拒否アクセスポリシーＩＤリスト」は、Ｗｅｂブラウザ３４１において内容が同意されなかった要求アクセスポリシーＩＤのリストである。今回は本同意画面１１０２において、テナントＩＤ「１０６ＡＡ」のユーザーが要求アクセスポリシーＩＤ「２」と「５」横のチェックボックスのチェックを外していることから、アクセスポリシー管理部３３２（表９）では、テナントＩＤ「１０６ＡＡ」の「拒否アクセスポリシーＩＤリスト」が「２、５」と設定されている。

表９に基づいて、アクセスポリシー管理部３３２がデータアクセス同意画面を生成する処理のフローを図１３で説明する。図８と同様の処理については同じ符番を振り、説明は省略する。情報処理システム１６０にログイン中のサービス提供者が所属するテナントが顧客テナントであるかを判定する（Ｓ８００）。顧客テナントであると判定された場合、図８のデータアクセス同意画面の作成処理が実行される。顧客テナントでないと判定された場合は、Ｓ８０１の処理に進む。具体的には、情報処理システム１６０にログインしているユーザーが所属するテナントがテナント５１２（テナントＩＤは「１００２ＡＡ」）である場合、テナント管理部３１１が管理する情報（表２）より、顧客テナントであると判定され、図８の処理が実行される。一方、ログインしているユーザーが所属するテナントがテナント５０５（テナントＩＤは「１０５ＡＡ」）である場合、販売テナントであると判定され、Ｓ８０１の処理に進む。Ｓ８００の処理により、同意画面において、同意する要求アクセスポリシーを選択するためのチェックボックスを各要求アクセスポリシーＩＤの横に設けるかどうかが決定される。本実施例では、各要求アクセスポリシーＩＤの横のチェックボックスの有無を、Ｓ８００における判定の条件としたが、判定の条件はこれに限定されない。また、チェックボックスの表示の有無の判定はＳ８００のタイミングに限定されず、データアクセス同意画面を生成するタイミング（Ｓ８０５、Ｓ１２０６）より前であればいつでもよい。

Ｓ８０２においてアクセスポリシー管理部３３２がＷｅｂブラウザ３４１に列挙する要求アクセスポリシーを特定した後、アクセスポリシー継承設定画面１１０１を表示する（Ｓ１２０１）。アクセスポリシー継承設定画面１１０１においてユーザーが同意する要求アクセスポリシーを選択し、「設定する」ボタン１１０３を押下した結果、アクセスポリシー管理部３３２は拒絶アクセスポリシーＩＤリストを作成する（Ｓ１２０２）。Ｓ１２０２において作成された拒絶アクセスポリシーＩＤリスト（表９）において、拒絶アクセスポリシーＩＤリストの有無を判定する（Ｓ１２０３）。具体的には、Ｓ８０２において特定された要求アクセスポリシーと表９の拒絶アクセスポリシーＩＤリストとを照合して、表９に値が含まれていないかどうかを確認する。含まれていない場合は、Ｓ８０２で特定した要求アクセスポリシーを同意対象アクセスポリシーに追加し（Ｓ１２０４）、含まれている場合は、拒否アクセスポリシーＩＤリストに入っている要求アクセスポリシーを同意の対象から除外する（Ｓ１２０５）。今回は、要求アクセスポリシーＩＤ「２，５」である要求アクセスポリシーが同意されることが拒否されているので、要求アクセスポリシーＩＤ「１，１３」のみが同意対象アクセスポリシーに追加される。Ｓ１２０４で生成された同意対象アクセスポリシーに基づいてアクセスポリシー管理部３３２はデータアクセス同意画面を生成する（Ｓ１２０６）。生成されたデータアクセス同意画面の一例を図１２（表示画面１１１１）に示す。表示画面１１１１では、アクセスポリシー継承設定画面１１０１で同意されなかった要求アクセスポリシーに関する情報のみが表示されていない。

以上が、サービス提供ルートの途中のテナントが、要求アクセスポリシーへの同意を拒否する場合の処理である。本実施例より、サービス提供ルートの途中のテナントが上位の卸元テナントが要求している要求アクセスポリシーへの同意を要求アクセスポリシー毎に詳細に設定することが可能となる。例えば、販売ルートの途中のディーラーが卸元テナントのサービス提供者に、ディーラーが持つ顧客情報を知られたくない場合に、卸元テナントが顧客情報にアクセスするための要求アクセスポリシーをディーラーが同意しないことができる。

実施例２ではサービス提供ルートの途中のテナントが、同意する要求アクセスポリシーを選択する形態を示した。しかし、実施例１と同様に、サービス提供ルートの末端のテナントである顧客テナントが、同意する要求アクセスポリシーをアクセスポリシー継承設定画面１１０１において選択する形態も可能である。

［その他の実施例］
また、本発明の目的は以下の処理を実行することによっても達成される。即ち、上述した実施例の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）が記憶媒体に格納されたプログラムコードを読み出す処理である。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施例の機能を実現することになり、そのプログラムコード及び該プログラムコードを記憶した記憶媒体は本発明を構成することになる。

１１０ 認証認可サーバー
１２０ リソースサーバー
１３０ データ管理サーバー
１４０ クライアントデバイス
１５０ デバイス
３１０ 認証認可部
３１１ テナント管理部
３１２ ライセンス管理部
３２０ リソースサーバー部
３３０ データ受信部
３３１ データ提供部
３３２ アクセスポリシー管理部
３４１ Ｗｅｂブラウザ
３５１ 認証認可サーバー連携部
３５２ データ送信部

Claims (11)

1. デバイスのデータを保存する保存手段と、
   前記保存手段によって保存されるデータの属性情報と前記データにアクセス可能なテナントを特定するためのテナント情報とを紐付けた要求アクセスポリシーを生成する生成手段と、
   を有する情報処理システムであって、
   前記情報処理システムにログインしたユーザーが所属するユーザーテナントを特定し、特定されたユーザーテナントを含むサービス提供ルートを構成する複数のテナントを特定する特定手段と、
   前記特定手段によって特定された複数のテナントに関連する１または複数の要求アクセスポリシーに基づいて、特定の属性を有するデータに対象のテナントがアクセスすることに同意するための同意画面を提供する画面提供手段と、
   前記画面提供手段によって提供された同意画面の内容に対して前記ユーザーが同意したことにより同意コードを発行する発行手段と、
   前記発行手段によって発行された前記同意コードが前記デバイスに入力され、入力された前記同意コードに関連付く１または複数の要求アクセスポリシーに基づいて、前記同意コードが入力された前記デバイスのデータの提供を制御するデータ制御手段と、
   を有することを特徴とする情報処理システム。
2. 前記同意コードは、
   前記同意コードを入力された前記デバイスを特定するためのデバイス識別子と紐付き、
   前記データ制御手段は、
   前記同意コードと紐づいた前記デバイス識別子に基づいて、
   前記データを取得するためのデータ取得要求の送信元に対して送信すべきデバイスのデータを特定する請求項１に記載の情報処理システム。
3. 前記データを取得するためのデータ取得要求は、
   前記データ取得要求の送信元が所属するテナントを特定するための送信元テナント情報を含み、
   前記データ制御手段は、
   前記送信元テナント情報に紐付く要求アクセスポリシーを特定し、特定された要求アクセスポリシーに紐づく同意コードを特定することにより、前記デバイスのデータの提供を制御する請求項１乃至２のいずれか１項に記載の情報処理システム。
4. 前記データを取得するためのデータ取得要求は、
   前記データの属性情報を含み、
   前記データ制御手段は、
   前記データ取得要求が含む前記データの属性情報に基づいて、前記送信元に対して送信すべきデバイスのデータを特定する請求項１乃至３のいずれか１項に記載の情報処理システム。
5. 前記情報処理システムは、
   前記同意画面の内容を前記ユーザーに選択させることが可能であり、
   前記発行手段は、
   前記ユーザーによって選択された前記同意画面の内容と関連付く要求アクセスポリシーに対して前記同意コードを発行する請求項１乃至４のいずれか１項に記載の情報処理システム。
6. 前記データを用いてデバイスサービスを提供するユーザーが所属するテナントが販売テナントであり、
   前記販売テナントによって前記デバイスサービスを提供されるユーザーが所属するテナントが顧客テナントであって、
   前記ユーザーが所属するテナントが販売テナントである場合に、前記同意画面の内容を前記ユーザーが選択することが可能であり、
   前記ユーザーが所属するテナントが顧客テナントである場合に、前記同意画面の内容を前記ユーザーが選択することを不可とすることを特徴とする請求項５に記載の情報処理システム。
7. 前記デバイスが前記情報処理システムにおいて認証された後に、前記情報処理システムに対して前記デバイスのデータが送信され、前記データは、前記デバイス識別子と前記データの属性情報とに紐付いて管理されることを特徴とする請求項２乃至６のいずれか１項に記載の情報処理システム。
8. 前記生成手段は、
   前記データの属性情報と、特定の属性を有するデータにアクセスできるテナントの種別情報とを紐付けたマスターポリシーに基づいて、対象となるテナントが前記マスターポリシーを満たすと判断された場合に、
   前記対象となるテナントに対応した前記要求アクセスポリシーを生成する請求項１乃至７のいずれか１項に記載の情報処理システム。
9. 前記データの属性情報は、
   デバックログ、ステータス情報、ジョブログのいずれか１つを示す情報である請求項１乃至８のいずれか１項に記載の情報処理システム。
10. デバイスのデータを保存する保存ステップと、
    前記保存ステップによって保存されるデータの属性情報と前記データにアクセス可能なテナントを特定するためのテナント情報とを紐付けた要求アクセスポリシーを生成する生成ステップと、
    を有する制御方法であって、
    前記情報処理システムにログインしたユーザーが所属するユーザーテナントを特定し、特定されたユーザーテナントを含むサービス提供ルートを構成する複数のテナントを特定する特定ステップと、
    前記特定ステップによって特定された複数のテナントに関連する１または複数の要求アクセスポリシーに基づいて、特定の属性を有するデータに対象のテナントがアクセスすることに同意するための同意画面を提供する画面提供ステップと、
    前記画面提供ステップによって提供された同意画面の内容に対して前記ユーザーが同意したことにより同意コードを発行する発行ステップと、
    前記発行ステップによって発行された前記同意コードが前記デバイスに入力され、入力された前記同意コードに関連付く１または複数の要求アクセスポリシーに基づいて、前記同意コードが入力された前記デバイスのデータの提供を制御するデータ制御ステップと、
    を有することを特徴とする制御方法。
11. デバイスのデータを保存する保存ステップと、
    前記保存ステップによって保存されるデータの属性情報と前記データにアクセス可能なテナントを特定するためのテナント情報とを紐付けた要求アクセスポリシーを生成する生成ステップと、
    を有する制御方法が実現されるためのプログラムであって、
    前記情報処理システムにログインしたユーザーが所属するユーザーテナントを特定し、特定されたユーザーテナントを含むサービス提供ルートを構成する複数のテナントを特定する特定ステップと、
    前記特定ステップによって特定された複数のテナントに関連する１または複数の要求アクセスポリシーに基づいて、特定の属性を有するデータに対象のテナントがアクセスすることに同意するための同意画面を提供する画面提供ステップと、
    前記画面提供ステップによって提供された同意画面の内容に対して前記ユーザーが同意したことにより同意コードを発行する発行ステップと、
    前記発行ステップによって発行された前記同意コードが前記デバイスに入力され、入力された前記同意コードに関連付く１または複数の要求アクセスポリシーに基づいて、前記同意コードが入力された前記デバイスのデータの提供を制御するデータ制御ステップと、
    を有する制御方法が実現されるためのプログラム。

Images