(57)【特許請求の範囲】
【請求項１】
第１のサービスシステムと、
第２のオンラインサービスを提供し、かつ前記第１のサービスシステムと通信することが可能な第２のサービスシステムと、
前記第２のサービスシステムを含む複数のサービスシステムを利用するために必要な認証情報、および認可トークンを管理するアクセス管理サービスシステムと、
前記第１のサービスシステム、および前記第２のサービスシステムが提供するオンラインサービスを利用するために必要な認証情報を登録済みのユーザーが操作するクライアントとから構成される権限委譲システムであって、
前記第１のサービスシステムは、前記ユーザーが操作するクライアントからの処理要求に応じる過程の中で前記第２のサービスシステムが提供する前記第２のオンラインサービスを利用する必要性が発生した場合、前記第１のサービスシステムが利用したい前記第２のオンラインサービスを特定するためのスコープ情報を前記クライアントに送信するとともに前記クライアントを前記アクセス管理サービスシステムへアクセスさせる第１のリダイレクト指示手段と、
前記アクセス管理サービスシステムは、前記ユーザーが前記第２のオンラインサービスを利用できる権限を有しているか否かを確認し、権限を有していることが確認されたことに応じて、前記第１のサービスシステムが前記第２のオンラインサービスを利用することを認可するか否かを確認するための認可画面を前記クライアントに送信する認可画面送信手段と、
前記アクセス管理サービスシステムは、前記認可画面を介して前記ユーザーにより認可されたことが確認できた場合、認可トークンを発行する際に必要となるコードを発行し、発行されたコードと前記クライアントからアクセスされた際に取得した前記スコープ情報とが紐付くように管理する管理手段と、
前記アクセス管理サービスシステムは、前記コードを前記クライアントに送信するとともに前記第１のサービスシステムへアクセスさせる第２のリダイレクト指示手段と、
前記第１のサービスシステムは、前記第１のサービスシステムに固有の認証情報と、前記クライアントからアクセスされた際に取得した前記コードを前記アクセス管理サービスシステムに送信する送信手段と、
前記アクセス管理サービスシステムは、受信した前記コードに紐付くスコープ情報を基に前記第１のサービスシステムが利用したいオンラインサービスを特定するとともに、受信した前記第１のサービスシステムに固有の認証情報を基に前記第１のサービスシステムが利用可能なオンラインサービスの中に前記特定されたオンラインサービスが含まれるか否かを確認する確認手段と、
前記アクセス管理サービスシステムは、前記第１のサービスシステムが利用可能なオンラインサービスの中に前記特定されたオンラインサービスが含まれると確認されたことに応じて認可トークンを発行する発行手段と、を有し、
前記第１のサービスシステムは、発行された前記認可トークンを用いることで前記第２のオンラインサービスを利用することが可能となることを特徴とする権限委譲システム。
【請求項２】
前記アクセス管理サービスシステムは、アクセスしてきた前記クライアントを操作するユーザーが前記第２のオンラインサービスを利用できる権限を有していないと確認した場合、またはアクセスしてきた前記クライアントを操作するユーザーが前記第２のオンラインサービスを利用できる権限を有していると確認はされたが、前記第１のサービスシステムが利用可能なオンラインサービスの中に前記特定されたオンラインサービスが含まれていないと確認された場合は、前記発行手段による認可トークンの発行が行われないように制御することを特徴とする請求項１に記載の権限委譲システム。
【請求項３】
前記アクセス管理サービスシステムは、アクセスしてきた前記クライアントを操作するユーザーが前記第２のオンラインサービスを利用できる権限を有していないと確認した場合は、前記ユーザーは前記第２のオンラインサービスを利用する権限を有していないことを前記ユーザーに認識させるための認証エラー画面を送信し、
アクセスしてきた前記クライアントを操作するユーザーが前記第２のオンラインサービスを利用できる権限を有していると確認はされたが、前記第１のサービスシステムが利用可能なオンラインサービスの中に前記特定されたオンラインサービスが含まれていないと確認された場合は、前記第１のサービスシステムは前記第２のオンラインサービスを利用する権限を有していないことを前記ユーザーに認識させるためのスコープエラー画面を送信することを特徴とする請求項１または２に記載の権限委譲システム。
【請求項４】
前記第１のサービスシステムは、前記第１のサービスシステムが前記クライアントに送信する、前記第１のサービスシステムが利用したい前記第２のオンラインサービスを特定するためのスコープ情報の他に、前記第１のサービスシステムが前記第２のオンラインサービスを利用することを認可する権限を前記ユーザーが有しているかを特定するための別のスコープ情報も送信し、
前記アクセス管理サービスシステムは、アクセスしてきた前記クライアントを操作するユーザーが前記第２のオンラインサービスを利用できる権限を有しているか否かを確認する際は、受信した前記別のスコープ情報に紐付くオンラインサービスの利用権限を確認するとともに、前記ユーザーが入力した認証情報を基に特定した前記ユーザーに割り当てられているオンラインサービスの利用権限を確認し、受信した前記別のスコープ情報に紐付くオンラインサービスの利用権限が前記ユーザーに割り当てられていると確認された場合に、アクセスしてきた前記クライアントを操作するユーザーが前記第２のオンラインサービスを利用できる権限を有していると判断することを特徴とする請求項１乃至３の何れか１項に記載の権限委譲システム。
【請求項５】
第１のオンラインサービスを提供する第１のサービスシステムと、
第２のオンラインサービスを提供し、かつ前記第１のサービスシステムと通信することが可能な第２のサービスシステムと、
前記第２のサービスシステムを含む複数のサービスシステムを利用するために必要な認証情報、および認可トークンを管理するアクセス管理サービスシステムと、
前記第１のサービスシステム、および前記第２のサービスシステムが提供するオンラインサービスを利用するために必要な認証情報を登録済みのユーザーが操作するクライアントとから構成される権限委譲システムを制御する制御方法であって、
前記第１のサービスシステムの第１のリダイレクト指示手段は、前記ユーザーが操作するクライアントからの処理要求に応じる過程の中で前記第２のサービスシステムが提供する前記第２のオンラインサービスを利用する必要性が発生した場合、前記第１のサービスシステムが利用したい前記第２のオンラインサービスを特定するためのスコープ情報を前記クライアントに送信するとともに前記クライアントを前記アクセス管理サービスシステムへアクセスさせ、
前記アクセス管理サービスシステムの認可画面送信手段は、前記ユーザーが前記第２のオンラインサービスを利用できる権限を有しているか否かを確認し、権限を有していることが確認されたことに応じて、前記第１のサービスシステムが前記第２のオンラインサービスを利用することを認可するか否かを確認するための認可画面を前記クライアントに送信し、
前記アクセス管理サービスシステムの管理手段は、前記認可画面を介して前記ユーザーにより認可されたことが確認できた場合、認可トークンを発行する際に必要となるコードを発行し、発行されたコードと前記クライアントからアクセスされた際に取得した前記スコープ情報とが紐付くように管理し、
前記アクセス管理サービスシステムの第２のリダイレクト指示手段は、前記コードを前記クライアントに送信するとともに前記第１のサービスシステムへアクセスさせ、
前記第１のサービスシステムの送信手段は、前記第１のサービスシステムに固有の認証情報と、前記クライアントからアクセスされた際に取得した前記コードを前記アクセス管理サービスシステムに送信し、
前記アクセス管理サービスシステムの確認手段は、受信した前記コードに紐付くスコープ情報を基に前記第１のサービスシステムが利用したいオンラインサービスを特定するとともに、受信した前記第１のサービスシステムに固有の認証情報を基に前記第１のサービスシステムが利用可能なオンラインサービスの中に前記特定されたオンラインサービスが含まれるか否かを確認し、
前記アクセス管理サービスシステムの発行手段は、前記第１のサービスシステムが利用可能なオンラインサービスの中に前記特定されたオンラインサービスが含まれると確認されたことに応じて認可トークンを発行し、
前記第１のサービスシステムが発行された認可トークンを用いることで前記第２のオンラインサービスを利用可能となり、前記第１のオンラインサービスと前記第２のオンラインサービスとを連携させたマッシュアップサービスが実現されることを特徴とする権限委譲システムの制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のオンラインサービスをマッシュアップして実現する際に権限を移譲させることでサービスをマッシュアップする権限委譲システム、アクセス管理サービスシステム、および権限委譲システムを制御する制御方法に関する。
【背景技術】
【０００２】
近年、クラウドサービスと呼ばれるインターネットを介してソフトウェアの機能を提供するサービスが注目を集めている。最近では、個々のクラウドサービスが連携して、新しいサービスを提供するケースが増えている。
【０００３】
クラウドサービス同士を連携させるためには、適切なアクセス権限を有しているユーザーによって操作されていることを、個々のサービスが備えた認証機構にアクセスして検証しなければならない。特許文献１に記載のシステムは、複数のサービスが連携して動作することを前提としたシステムであり、各サービスがそれぞれ独自の認証機構を有している。システムを構成するいずれかのサービスへの最初の１回の認証処理の実行をきっかけとして、全てのサービスに対して認証処理を実行し、且つその結果を併合して返す。これにより、以降認証処理を実行することなく複数のサービスの利用を可能とする。
【０００４】
一方、サービスを連携する際に、サービス間のアクセス制御を安全且つ容易に行う仕組みとしてＯＡｕｔｈと呼ばれる技術を利用し連携させることが知られている。ＯＡｕｔｈは、連携先のサービスのアクセス権限に限って連携元のサービスに対して移譲する技術である。ＯＡｕｔｈによるサービスのアクセス権限移譲の仕組みを、個々のサービスの認証機構が備えることでユーザーＩＤやパスワードなどのセキュリティ情報をサービスに記憶させることなく、安全にクラウドサービス間の連携を実現することができる。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００４−２５２９５５
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ＯＡｔｕｈによるアクセス権限移譲の仕組みは、連携元となるサービスが連携先のサービスと連携する際に、連携元となるサービスを操作しているユーザーに認可を要求することで連携元サービスへのアクセス権限移譲の可否を決定している。認可されると、連携元となるサービスは連携先のサービスを一時的に使用することが可能になる。しかしながら、連携元のサービスを提供するサーバー自身が、連携先のサービスに対して適切なアクセス権限を有していなければならないようなサービスと連携する場合について考えられていなかった。
【０００７】
本発明は、このような課題を解決するものであり、クラウドサービス同士の連携に際してより正確かつ安全なアクセス権限移譲の仕組みを提供するものである。
【課題を解決するための手段】
【０００８】
本発明の一実施形に係る権限委譲システムは、第１のオンラインサービスを提供する第１のサービスシステムと、第２のオンラインサービスを提供し、かつ前記第１のサービスシステムと通信することが可能な第２のサービスシステムと、前記第２のサービスシステムを含む複数のサービスシステムを利用するために必要な認証情報、および認可トークンを管理するアクセス管理サービスシステムと、前記第１のサービスシステム、および前記第２のサービスシステムが提供するオンラインサービスを利用するために必要な認証情報を登録済みのユーザーが操作するクライアントとから構成される権限移譲システムであって、前記第１のサービスシステムは、前記ユーザーが操作するクライアントからの処理要求に応じる過程の中で前記第２のサービスシステムが提供する前記第２のオンラインサービスを利用する必要性が発生した場合、前記第１のサービスシステムが利用したい前記第２のオンラインサービスを特定するためのスコープ情報を前記クライアントに送信するとともに前記クライアントを前記アクセス管理サービスシステムへアクセスさせる第１のリダイレクト指示手段と、前記アクセス管理サービスシステムは、前記ユーザーが前記第２のオンラインサービスを利用できる権限を有しているか否かを確認し、権限を有していることが確認されたことに応じて、前記第１のサービスシステムが前記第２のオンラインサービスを利用することを認可するか否かを確認するための認可画面を前記クライアントに送信する認可画面送信手段と、前記アクセス管理サービスシステムは、前記認可画面を介して前記ユーザーにより認可されたことが確認できた場合、認可トークンを発行する際に必要となるコードを発行し、発行されたコードと前記クライアントからアクセスされた際に取得した前記スコープ情報とが紐付くように管理する管理手段と、前記アクセス管理サービスシステムは、前記コードを前記クライアントに送信するとともに前記第１のサービスシステムへアクセスさせる第２のリダイレクト指示手段と、前記第１のサービスシステムは、前記第１のサービスシステムに固有の認証情報と、前記クライアントからアクセスされた際に取得した前記コードを前記アクセス管理サービスシステムに送信する送信手段と、前記アクセス管理サービスシステムは、受信した前記コードに紐付くスコープ情報を基に前記第１のサービスシステムが利用したいオンラインサービスが前記第２のオンラインサービスであることを特定するとともに、受信した前記第１のサービスシステムに固有の認証情報を基に前記第１のサービスシステムが利用可能なオンラインサービスの中に前記特定された前記第２のオンラインサービスが含まれるか否かを確認する確認手段と、前記アクセス管理サービスシステムは、前記第１のサービスシステムが利用可能なオンラインサービスの中に前記特定された前記第２のオンラインサービスが含まれると確認されたことに応じて認可トークンを発行する発行手段と、を有し、前記第１のサービスシステムが発行された認可トークンを用いることで前記第２のオンラインサービスを利用可能となり、前記第１のオンラインサービスと前記第２のオンラインサービスとを連携させたマッシュアップサービスが実現されることを特徴とする。
【発明の効果】
【０００９】
認可トークンの発行における各処理の実行に際して、各オンラインサービスのアクセス権限を検証した上で実行することで、高いセキュリティを維持してオンラインサービス間の権限移譲を実現することができる。
【図面の簡単な説明】
【００１０】
【図１】システム全体図
【図２】サーバーのハードウェア構成図
【図３】外部有償サーバーのソフトウェア構成図
【図４】サービス連携データ管理テーブル
【図５】帳票サーバーのソフトウェア構成図
【図６】印刷サーバーのソフトウェア構成図
【図７】アクセス管理サーバーのソフトウェア構成図
【図８】アクセス管理サービスシステム１０７が保持するデータ構造を示したテーブル
【図９】アクセス管理サービスシステム１０７が保持する帳票サービス及び印刷サービスの実行権限を管理するデータ構造を示したテーブル
【図１０】本発明によって制御される権限移譲処理について示した実施例１のフロー図
【図１１】外部有償サービスシステム１０３が実行する各マッシュアップ処理の実行権限を管理するデータ構造を示したテーブル
【図１２】認可画面の一例を示した図
【図１３】アクセス管理サービスシステム１０７が保持する認可コードのデータ構造を示したテーブル
【図１４】アクセス管理サービスシステム１０７が保持する認可トークンのデータ構造を示したテーブル
【図１５】本発明によって制御される権限移譲処理について示した実施例２のフロー図
【発明を実施するための形態】
【００１１】
本願発明は、連携元のサービスを提供するサーバー自身が、連携先のサービスに対して適切なアクセス権限を有していなければならないようなサービスと連携する場合を想定した発明である。このようなサービスと連携する場合の理想として、権限移譲時には、ユーザーと連携元のサービスが連携先のサービスに対して適切なアクセス権限を有しているか否かをサービス実行前に確認することが理想である。なぜなら、ユーザーがアクセス権限を有していても、連携元のサービスがアクセス権限を有していない状況で連携先サービスへのアクセス権限を移譲された場合、実行した時点で連携ができないことが判明する形態も考えられ、この場合、認可トークンが無駄に発行されることとなる。
【００１２】
その他の理由として、次の様な理由が挙げられる。連携先サービスを提供するサービスシステムが、認可トークンを用いたオンラインサービスの利用であれば連携元サービス利用権限を確認しない構成だった場合、不正な権限でもサービスの連携が可能となってしまいシステムの信頼性が低下してしまう。
【００１３】
本願発明は、これらの課題の内、少なくとも１つを解決することを目的とする。以下、本発明を実施するための最良の形態について図面を用いて説明する。
【実施例１】
【００１４】
インターネット上で、様々なサービス提供者が様々なオンラインサービスを提供している。単一のサービス提供者が運営している単体のオンラインサービスもあれば、複数のサービス提供者が運営している複数のオンラインサービスを組み合わせ、１つのソリューションを実現するという手法も存在する。後者は、マッシュアップと呼ばれ、あたかも１つのＷｅｂサイトあるいは１つのＷｅｂサービスを利用しているかのようにユーザーに見せる技術である。しかしながら、このマッシュアップを実現するために行われるバックエンド処理では、複数のオンラインサービスが連携・連動し、必要なオンラインサービスを提供するモジュール群と連携してソリューションを実現する。なお、ここで言うオンラインサービスとは、Ｗｅｂサイト、Ｗｅｂアプリケーション、Ｗｅｂサービスなどが提供する機能群のことである。Ｗｅｂサイト、Ｗｅｂアプリケーション、Ｗｅｂサービスなどは、サーバーコンピューターで実行されるソフトウェアである。オンラインサービスが提供する内容自体に特に制限はないが、例えば、印刷データの変換サービス、帳票を作成する帳票作成サービス、デバイスのステータスを含むデータを管理しそのデータをレポートして出力するデバイス管理サービス等が考えられる。
【００１５】
図１は、各種オンラインサービスが存在するネットワーク構成を示しており、本願発明の権限委譲システムを説明する図である。インターネット１００は、インターネットなどの外部から接続可能なパブリックなネットワークである。イントラネット１０１はＬＡＮなどの外部から接続不可能なプライベートなネットワークである。クライアント１０２は、インターネット１００を介して、パーソナルコンピューターやモバイル端末などのオンラインサービスを利用する際に使用されるクライアント端末である。
【００１６】
外部有償サービスシステム１０３は、後述する帳票サービスシステム１０５及び印刷サービスシステム１０６とオンラインでマッシュアップする機能を有するオンラインサービスシステムである。例えば、外部有償サービスシステム１０３は、帳票サービスシステム１０５と連携することで、ユーザーに帳票生成サービスを提供する。帳票生成サービスとは、後述するサービス連携データ管理部３０３に格納されたデータを、インターネットを経由して帳票サービスシステム１０５に送信し、帳票データ管理部５０４に格納された帳票フォームと合成し、帳票データを提供するサービスである。帳票サービスシステム１０５は、このサービスを提供する機能を有する。帳票データは、クライアント１０２に対して送信される。
【００１７】
また、外部有償サービスシステム１０３は、帳票サービスシステム１０５と印刷サービスシステム１０６と通信することが可能であり、通信可能なこれらのサービスシステムが提供するサービスと連携することで、ユーザーに帳票生成印刷サービスを提供する。帳票生成印刷サービスとは、帳票生成サービスによって合成された帳票データを、インターネットを経由して印刷サービスシステム１０６に送信し、プリンター１０９で印刷可能なデータ形式に変換した印刷データを提供するサービスである。即ち、実施例１における外部有償サービスシステム１０３は、帳票サービスシステム１０５と印刷サービスシステム１０６を連携させるために、仲介役となるサービスを提供する。なお、外部有償サービスシステム１０３は、単に仲介役となるだけではなく、例えば、帳票データに付加価値を加えて印刷させる様なサービスであっても良い。
【００１８】
なお、外部有償サービスシステム１０３が第１のサービスシステムに相当し、外部有償サービスシステム１０３により提供されるサービスが第１のオンラインサービスに相当する。そして、その第１のサービスシステムと連携する帳票サービスシステム１０５、および／または印刷サービスシステム１０６が第２のサーバーシステムに相当し、それらのサービスシステムにより提供されるサービスが第２のオンラインサービスに相当する。例えば、実施例１における第２のオンラインサービスは、帳票サービス、または印刷サービスである。
【００１９】
外部有償サービスシステム１０３は外部有償サーバー１０３Ａ、１０３Ｂ、負荷分散装置１０８で構成される。外部有償サーバー１０３Ａ、１０３Ｂ、負荷分散装置１０８はイントラネット１０１で接続されている。クライアント１０２と外部有償サービスシステム１０３及び後述するその他のオンラインサービスシステムとの通信はインターネット１００を介して実行される。負荷分散装置１０８はインターネット１００からのリクエストを分散して処理する装置である。なお、図１によれば、外部有償サービスシステム１０３を構成する外部有償サーバーは１０３Ａと１０３Ｂの２台となっているが、実際には１台であっても良いし、２台以上の外部有償サーバーによって構成されていても良い。
【００２０】
アクセス管理サービスシステム１０７は、帳票サービスシステム１０５及び印刷サービスシステム１０６を利用するユーザーの認証情報、および認可トークンを管理する。ユーザー、および連携元となるサービスシステムは、正当な認証情報や正当な認可トークンを有していない限り、アクセス管理サービスシステム１０７が管理するサービスシステムを利用することができない。ユーザーは、アクセス管理サービスシステム１０７により管理されるサービスシステムを利用するために、予めサービスシステムを利用するために必要な認証情報を登録しておく必要がある。認証情報を登録済みのユーザーは、クライアントから認証情報を入力し、認証処理が行われ成功したことに応じてサービスを受ける。一方、連携元となるサービスシステムは後述する方法でアクセストークンを取得し、そのアクセストークンをアクセス管理サービスシステム１０７へ送信し、アクセストークンが正当なものであると検証されたことに応じて、サービスのマッシュアップを実現することができる。
【００２１】
アクセス管理サービスシステム１０７はアクセス管理サーバー１０７Ａ、１０７Ｂ、負荷分散装置１０８で構成される。アクセス管理サーバー１０７Ａ、１０７Ｂ、負荷分散装置１０８はプライベートネットワーク１０１で接続されている。アクセス管理サービスシステム１０７は負荷分散装置１０８によってイントラネット１０１を介した帳票サービスシステム１０５、印刷サービスシステム１０６からのリクエストを分散して処理することができる。また、アクセス管理サービスシステム１０７はインターネット１００を介してクライアント１０２からのリクエストを処理することができる。なお、図１によれば、アクセス管理サービスシステム１０７を構成するアクセス管理サーバーは１０７Ａと１０７Ｂの２台となっているが、実際には１台であっても良いし、２台以上のアクセス管理サーバーによって構成されていても良い。
【００２２】
帳票サービスシステム１０５は、インターネット１００を介したクライアント１０２、または外部有償サービスシステム１０３からのリクエストに応じて帳票を生成するオンラインサービスである。帳票サービスシステム１０５は、帳票サーバー１０５Ａ、１０５Ｂ、負荷分散装置１０８で構成される。帳票サーバー１０５Ａ、１０５Ｂ、負荷分散装置１０８はイントラネット１０１で接続されている。クライアント１０２、外部有償サービスシステム１０３、および後述するその他オンラインサービスシステムとの通信はインターネット１００を介して実行される。負荷分散装置１０８はインターネット１００からのリクエストを分散して処理する装置である。なお、図１によれば、帳票サービスシステム１０５を構成する帳票サーバーは１０５Ａと１０５Ｂの２台となっているが、実際には１台であっても良いし、２台以上の帳票サーバーから構成されていても良い。
【００２３】
印刷サービスシステム１０６は、インターネット１００を介したクライアント１０２あるいは外部有償サービスシステム１０３からのリクエストに応じて帳票データをプリンター１０９で印刷可能なデータ形式に変換するオンラインサービスである。印刷サービスシステム１０６は、印刷サーバー１０６Ａ、１０６Ｂ、負荷分散装置１０８で構成される。印刷サーバー１０６Ａ、１０６Ｂ、負荷分散装置１０８はイントラネット１０１で接続されている。クライアント１０２、外部有償サービスシステム１０３、および後述するその他オンラインサービスシステムとの通信はインターネット１００を介して実行される。負荷分散装置１０８はインターネット１００からのリクエストを分散して処理する装置である。なお、図１によれば、印刷サービスシステム１０６を構成する印刷サーバーは１０６Ａと１０６Ｂの２台となっているが、実際には１台であっても良いし、２台以上の帳票サーバーから構成されていても良い。
【００２４】
プリンター１０９は、印刷サービスシステム１０６によって生成される印刷データを、インターネット１００を介して受信して印刷するプリンター装置である。なお、外部有償サービスシステム１０３は、帳票サービスシステム１０５、および印刷サービスシステム１０６を運営するサービス提供者とは別のサービス提供者が運営しているオンラインサービスであり、インターネット１００を経由して通信する事が可能である。
【００２５】
図２は、図１に示した各種サーバーを構成するＷｅｂサイト、Ｗｅｂアプリケーション、Ｗｅｂサービスなどのソフトウェアを実行するサーバーコンピューターの情報処理機能の論理構成を示している。ユーザーインターフェース２０１は、ディスプレイ、キーボード、マウスなどによる、情報の入出力を行うハードウェアである。これらのハードウェアを備えないコンピューターは、リモートデスクトップなどにより、他のコンピューターから接続・操作することも可能である。ネットワークインターフェース２０２は、ＬＡＮなどのネットワークに接続して、他のコンピューターやネットワーク機器との通信を行うハードウェアである。
【００２６】
ＣＰＵ２０３は、ＲＯＭ２０４、ＲＡＭ２０５、二次記憶装置２０６などから読み込んだプログラムを実行し、各種サービスを実現する。ＲＯＭ２０４は、組込済みプログラムおよびデータが記録されている記憶装置である。ＲＡＭ２０５は、一時メモリ領域である。二次記憶装置２０６は、ＨＤＤに代表されるような外部記憶装置である。各部は入出力インターフェース２０７を介して接続されている。
【００２７】
図３は、外部有償サーバー１０３Ａのソフトウェア構成図を示したブロック図である。なお、後述するサービスシステムのソフトウェア構成を含め、これらの図面に示された各処理部は、ＲＯＭ２０４に記憶されているプログラムをＲＡＭ２０５にロードし、ＣＰＵ２０３がプログラムを実行することで実現するものである。
【００２８】
リクエスト処理部３０１は、外部有償サービスシステム１０３がクライアント１０２からインターネット１００を経由して受信したサービスリクエストを処理する処理部である。負荷分散装置１０８は、クライアント１０２からインターネット１００を経由してサービスリクエストを受信する。その後、負荷分散装置１０８は、外部有償サーバーにリクエストをイントラネット１０１を経由して分散して配布し、リクエスト処理部３０１が処理を行う。サービス制御部３０２は、リクエスト処理部３０１からのリクエストに応じて必要な処理を行い、応答データを呼び出し元に返す。この際、サービス制御部３０２は、インターネット１００を経由して、帳票サービスシステム１０５、または印刷サービスシステム１０６に対し帳票生成リクエスト、および帳票印刷リクエストを送信し、リクエストの処理結果である応答データを受信する。
【００２９】
サービス連携データ管理部３０３は、外部有償サービスシステム１０３が帳票サービスシステム１０５あるいは印刷サービスシステム１０６に対して送信する帳票生成リクエスト、帳票印刷リクエストを生成するために利用するデータを管理する。認可コード管理部３０４は、認可コードのデータを管理する。トークン管理部３０５は、認可トークンのデータを管理する。
【００３０】
図４は、帳票サービスシステム１０５、印刷サービスシステム１０６に対して送信する帳票生成リクエスト、帳票印刷リクエストを生成するために利用するデータを、テーブル形式で示した図である。外部有償サービスシステム１０３は、図４に示すようなテーブル構造でデータを管理する。
【００３１】
サービス連携テーブル４００は、サービス名カラム４０１、Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍ  Ｉｎｔｅｒｆａｃｅカラム（以降、ＡＰＩカラムと記載する。）４０２、スコープＩＤカラム４０３で構成され、サービス連携データ管理部３０３に格納される。サービス名カラム４０１は、連携先のサービスの名前を格納するカラムである。ＡＰＩカラム４０２は、各オンラインサービスシステムが他のオンラインサービスシステムに対して公開している、リクエストを受信するためのＵＲＬを格納するカラムである。マッシュアップを行うオンラインサービスシステムは、ＡＰＩカラム４０２に格納されたＵＲＬに対して、サービスリクエストを送信する。例えば、実施例１において、外部有償サービスシステム１０３が帳票サービスシステム１０５に対応するデータが格納されているかを確認する。
【００３２】
そして、外部有償サービスシステム１０３は、サービス連携テーブル４００のＡＰＩカラム４０２に格納された値を基にサービスリクエストを帳票サービスシステム１０５に送信することで、帳票サービスシステム１０５とのマッシュアップが実現する。スコープＩＤカラム４０３は、外部有償サービスシステム１０３が各オンラインサービスを利用できる権限範囲を格納している。外部有償サービスシステム１０３が各オンラインサービスを実行する際に、各オンラインサービスと連携する権限を有しているか否かをアクセス管理サービスシステム１０７が判定する際に使用されるスコープ情報を格納するカラムである。アクセス管理サービスシステム１０７は、このスコープ情報から外部有償サービスシステム１０３が利用したいオンラインサービスを特定することができる。更に、アクセス管理サービスシステム１０７は、このスコープ情報と、後述するロールＩＤとを基に、外部有償サービスシステム１０３は、スコープ情報を基に特定されたオンラインサービスを利用できる。
【００３３】
認可コードテーブル４１０は、サービス名カラム４１１、認可コードＩＤカラム４１２で構成され、サービス連携データ管理部３０３に格納される。サービス名カラム４１１は、連携対象のサービス名を格納するカラムである。認可コードＩＤカラム４１２は、アクセス管理サービスシステム１０７が生成する認可コードを示す認可コードＩＤ１３０１を格納するカラムである。後述するステップＳ１０１０において、アクセス管理サービスシステム１０７が認可コードを生成すると、アクセス管理サービスシステム１０７から外部有償サービスシステム１０３に対して生成した認可コードを示す認可コードＩＤが送信される。認可コードの発行処理についての詳細は後述する。認可コードＩＤカラム４１２に格納される認可コードＩＤの値は、外部有償サービスシステム１０３がアクセス管理サービスシステム１０７に対し、帳票サービスシステム１０５を実行するために必要な認可トークンの発行を要求する際に送信される値である。そして、この認可コードＩＤは、外部有償サービスシステム１０３がアクセス管理サービスシステム１０７にアクセスするとともに送る認可トークン要求リクエストに含まれる。アクセス管理サービスシステム１０７が、外部有償サービスシステム１０３から認可コードＩＤを受信し、認可トークン発行をするまでの処理についての詳細は後述する。
【００３４】
認可トークンテーブル４２０は、サービス名カラム４２１、トークンＩＤカラム４２２で構成され、サービス連携データ管理部３０３に格納される。サービス名カラム４２１は、連携対象のサービス名を格納するカラムである。トークンＩＤカラム４２２は、アクセス管理サービスシステム１０７が生成する認可トークンを示す認可トークンＩＤ１４０１を格納するカラムである。後述するステップＳ１０１３において、アクセス管理サービスシステム１０７が認可トークンを生成すると、アクセス管理サービスシステム１０７から外部有償サービスシステム１０３に対して生成した認可トークンを示す認可トークンＩＤが送信される。認可トークンの発行処理についての詳細は後述する。
【００３５】
トークンＩＤカラム４２２に格納される認可トークンＩＤの値は、外部有償サービスシステム１０３が、帳票サービスシステム１０５に帳票生成要求、または帳票印刷要求を送信する際に合わせて送信される値である。帳票サービスシステム１０５が、外部有償サービスシステム１０３から認可トークンＩＤを受信し、帳票生成要求及び帳票印刷要求を実行するまでの処理についての詳細は後述する。
【００３６】
図５は、帳票サーバー１０５Ａの内部構造を示したブロック図である。帳票リクエスト処理部５０１は、インターネット１００を経由して、クライアント１０２から帳票データ生成リクエスト及び帳票データ取得リクエストを受信する。また、帳票リクエスト処理部５０１は、イントラネット１０１を経由して、連携サービス１０４から帳票データ生成リクエスト及び帳票データ取得リクエストを受信する。
【００３７】
帳票制御部５０２は、帳票リクエスト処理部５０１が受信したリクエストに応じて必要な処理を行い、応答データを呼び出し元に返す。この時、イントラネット１０１経由で帳票制御部５０２はアクセス管理サービスシステム１０７に対してリクエストを送信し、リクエストの処理結果である応答データを受信する。
【００３８】
帳票データ処理部５０３は、帳票制御部５０２から帳票データ生成リクエストを受信して、帳票データを生成する。また、帳票データ処理部５０３は生成した帳票データを応答として帳票制御部５０２に返す。
【００３９】
帳票データ管理部５０４は、帳票データ処理部５０３における帳票データ生成処理に使用される帳票フォームデータ及び帳票データを登録、管理する。また、帳票制御部５０２からの帳票データ取得リクエストを受信して、応答として帳票データを返す。
【００４０】
図６は、印刷サーバー１０６Ａの内部構造を示したブロック図である。印刷リクエスト処理部６０１は、インターネット１００を経由して、クライアント１０２から印刷データ変換リクエスト及び印刷データ取得リクエストを受信する。また、印刷リクエスト処理部６０１は、イントラネット１０１を経由して、連携サービス１０４から印刷データ変換リクエスト及び印刷データ取得リクエストを受信する。
【００４１】
印刷制御部６０２は、印刷リクエスト処理部６０１が受信したリクエストに応じて必要な処理を行い、応答データを呼び出し元に返す。この時、イントラネット１０１経由で印刷制御部６０２はアクセス管理サービスシステム１０７に対してリクエストを送信し、リクエストの処理結果である応答データを受信する。
【００４２】
印刷データ変換部６０３は、印刷制御部６０２から印刷データ変換リクエストを受信して、印刷データを生成する。また、印刷データ変換部６０３は変換した印刷データを応答として印刷制御部６０２に返す。
【００４３】
印刷データ管理部６０４は、印刷データ変換部６０３によって変換された印刷データを登録、管理する。また、印刷制御部６０２からの印刷データ取得リクエストを受信して、応答として印刷データを返す。
【００４４】
図７は、アクセス管理サーバー１０７Ａの内部構造を示したブロック図である。アクセス管理リクエスト処理部７０１は、インターネット１００及びイントラネット１０１を経由して、他のオンラインサービスシステムからの認証・認可リクエストを受信する。また、アクセス管理リクエスト処理部７０２は、アクセス制御部７０２から返される応答データを呼び出し元に返す。
【００４５】
アクセス制御部７０２は、認証データ管理部７０３及び認可データ管理部７０４から取得するデータに基づき、認証・認可リクエストに対して応答データを生成し、アクセス管理リクエスト処理部に応答データを返す。認証データ管理部７０３は、ユーザーアカウントを含む認証情報のデータを管理する。認可データ管理部７０４は、認可トークンのデータを管理する。そして、アクセス制御部７０２は、管理している認証情報、および認可トークンを基に、送信されてきた認証情報、および認可トークンの正当性を検証するための認証処理を実行する。
【００４６】
図８から図９は、アクセス管理サービスシステム１０７が保持するデータ構造をテーブル形式で示した図である。図８は、帳票サービスシステム１０５、および印刷サービスシステム１０６を利用可能なユーザーの情報を管理するデータ構造を示したテーブルである。その他に、外部有償サービスシステム１０３を一意に識別するために割り当てられた、外部有償サービスシステム１０３に固有のユーザーＩＤ、およびパスワードも同様に管理される。
【００４７】
ユーザーテーブル８００は、ユーザーＩＤカラム８０１とパスワードカラム８０２で構成され、認証データ管理部７０３に格納される。ユーザーＩＤカラム８０１は、ユーザーの識別子であるユーザーＩＤを格納するカラムである。パスワードカラム８０２は、ユーザーの秘匿情報となるパスワードを格納するカラムである。ユーザーテーブル８００には、外部有償サービスシステム１０３を操作するユーザーの帳票サービスシステム１０５、および印刷サービスシステム１０６に対応するユーザーＩＤ、パスワードが格納されている。また、上述したように、ユーザーテーブル８００には、マッシュアップ時に実際にリクエストを送信する外部有償サービスシステム１０３自身のユーザーＩＤ、パスワードも同様に格納されている。外部有償サービスシステム１０３に固有のこの認証情報は、帳票サービスシステム１０５、および印刷サービスシステム１０６に対応する認証情報である。
【００４８】
なお、以降の説明において外部有償サービスシステム１０３を操作するユーザーを「ユーザー」と呼称する。ユーザーからの帳票生成指示のリクエストを受けて、実際に帳票サービスシステム１０５に帳票生成リクエストを送信する外部有償サービスシステム１０３を「インボーカー」と呼称する。つまり、ユーザーテーブル８００には、ユーザーＩＤとそれに対応するパスワード、およびインボーカーＩＤとそれに対応するパスワードが格納されている。外部有償サービスシステム１０３がアクセス管理サービスシステム１０７の管理下にあるサービスシステムを利用する際には、インボーカーＩＤとパスワードを基に行われる認証処理が成功しない限り、その管理下にあるサービスシステムを利用できない。
【００４９】
図９は、帳票サービスシステム１０５、および印刷サービスシステム１０６といった各オンラインサービスシステムの実行権限を管理するデータ構造を示したテーブルである。ロールテーブル９１０は、ロールＩＤカラム９１１とロール名称カラム９１２で構成され、認可データ管理部７０４に格納される。ロールＩＤカラム９１１は、各オンラインサービスを実行可能なロール情報を格納するカラムである。ロール名称カラム９１２は、ロールＩＤカラム９１１の値を識別するための名称を格納するカラムである。ロール名称は主に、ロール情報をクライアント１０２が備えるディスプレイ（不図示）に表示する際に使用される値である。
【００５０】
ユーザー割り当てロールテーブル９２０は、ユーザーＩＤカラム９２１とロールＩＤカラム９２２で構成され、認可データ管理部７０４に格納される。ユーザーＩＤカラム９２１は、ユーザーの識別子であるユーザーＩＤを格納するカラムである。ユーザーテーブル８００に格納されたユーザーＩＤカラム８０１の値が本カラムに格納される。ロールＩＤカラム９２２は、各オンラインサービスを実行可能なロール情報を格納するカラムである。ロールテーブル９１０に格納されたロールＩＤカラム９１１の値が本カラムに格納される。このように、ユーザーＩＤが示すユーザー、またはサービスシステムがオンラインサービスを実行可能な権限を有している場合には、ユーザーＩＤと、実行可能な権限を示すロールＩＤとを紐付けて管理する。
【００５１】
ユーザーテーブル８００に格納されているユーザーが、帳票サービスシステム１０５、印刷サービスシステム１０６といった各オンラインサービスシステムを利用する場合には、ユーザーＩＤと各オンラインサービスシステムに対応するロールＩＤとを対応付けてユーザー割り当てロールテーブル９２０に格納する必要がある。そこで、先程の様な紐付け管理を行うのである。ユーザーがどのようなオンラインサービスの利用権限を有しているかを確認する処理について、より詳細に説明する。ユーザーがオンラインサービスシステムを実行する権限を有しているか否かの判断は、ユーザーテーブル８００、ユーザー割り当てロールテーブル９２０に登録されたユーザーＩＤの値、およびロールＩＤの値を参照して行われる。つまり、ユーザーＩＤカラム９２１の値とユーザーＩＤカラム８０１の値が一致し、かつユーザーＩＤ絡む９２１に紐付くロールＩＤ９２２を参照することで、ユーザーがオンラインサービスを利用できる権限を有しているか否かを確認できる。
【００５２】
以下、本発明のオンラインサービス連携によって実現する、外部有償サービスシステム１０３から帳票サービスシステム１０５を実行し帳票データを生成する処理のシーケンスを、図１０を用いて説明する。なお、帳票サービスシステム１０５は、アクセス管理サービスシステム１０７によって帳票サービスの利用が制御されていることは上述した通りである。
【００５３】
ここで、外部有償サービスシステム１０３と、帳票サービスシステム１０５は別のサービス提供者によって運営されているので、ユーザーが外部有償サービスシステム１０３のサービスを利用するためには、ユーザーは外部有償サービスシステム１０３と帳票サービスシステム１０５の両方を利用できる状態である必要がある。また、帳票生成サービスにおいて、実際に帳票サービスシステムへ帳票生成リクエストを送信するのは外部有償サービスシステム１０３である。そのため、外部有償サービスシステム１０３も、帳票サービス１０５のユーザーとして認証される。
【００５４】
ステップＳ１００１において、ユーザーはクライアント１０２を操作して、インターネット１００を経由して外部有償サービスシステム１０３へ帳票生成指示のリクエストを送信する。このとき、外部有償サービスシステム１０３は、帳票を生成するのに必要となる帳票フォームデータと、帳票に差し込むデータをユーザーに選択可能とする画面情報（不図示）を生成し、クライアント１０２が備えるＷｅｂブラウザ（不図示）に表示させる。ユーザーがＷｅｂブラウザに表示された画面情報から、帳票生成に使用する帳票フォームデータと帳票に差し込むデータとを選択することで、帳票生成指示のリクエストが生成される。なお、ステップＳ１００１は、外部有償サービスシステム１０３は、ユーザーが操作するクライアントからの処理要求に応じる過程の中で帳票サービスを利用する必要性が発生した状況である。外部有償サービスシステム１０３を利用したとしても、外部サービスシステムと連携する必要がない場合も考えられる。
【００５５】
ステップＳ１００２において、リクエスト処理部３０１はクライアント１０２から送信された帳票生成指示のリクエストを受信する。リクエスト処理部３０１は、受信した帳票生成指示のリクエストから、帳票生成に使用する帳票フォームデータと帳票に差し込むデータとを解析し、サービス制御部３０２に情報を渡す。サービス制御部３０２は、トークン管理部３０５に対し、トークンテーブル４２０の認可トークンＩＤカラム４２２に帳票サービスシステム１０５を実行するために必要な認可トークンが格納されているかどうかを確認する。
【００５６】
認可トークンＩＤカラム４２２に認可トークンＩＤが格納されていれば、ステップＳ１０１５に進み、外部有償サービスシステム１０３は帳票サービスシステム１０５に対して帳票生成リクエストを送信する。認可トークンＩＤカラム４２２に認可トークンＩＤが格納されていなければ、ステップＳ１００３に進み、外部有償サービスシステム１０３は、帳票サービスシステム１０５への認可要求リクエストを生成し、アクセス管理サービスシステム１０７に送信する。このとき、外部有償サービスシステム１０３は、サービス連携テーブル４００から、帳票サービスシステム１０５に該当するＡＰＩカラム４０２値とスコープＩＤカラム４０３の値を参照して、認可要求リクエストを生成する。認可要求リクエストにスコープＩＤを含める理由は、アクセス管理サービスシステム１０７が、外部有償サービスシステム１０３、およびユーザーが、帳票サービスシステム１０５のサービスを利用する権限があるかを検証するためである。アクセス管理サービスシステム１０７は、認可要求リクエストに含まれるスコープＩＤの値からスコープテーブル１１００、およびユーザー割り当てロールテーブル９２０を参照し、ユーザー、および外部有償サービスシステム１０３が帳票サービスシステム１０５のサービスを利用する権限があるかを検証する。なお、ユーザーに割り当てられた利用権限を確認すると言うことを換言すれば、外部有償サービスシステム１０３がオンラインサービスを利用することを認可するか否かを決める権限を有しているかを確認していることである。
【００５７】
ステップＳ１００３において、外部連携サービス１０３からアクセス管理サービスシステム１０７に送信される認可要求リクエストにスコープＩＤとして「Ｓｃｏｐｅ＿ＦｏｒｍＵｓｅｒ」「Ｓｃｏｐｅ＿ＦｏｒｍＩｎｖｏｋｅｒ」の値が含まれるものとする。ステップＳ１００４において、アクセス管理リクエスト処理部７０１は、外部有償サービスシステム１０３から認可要求リクエストを受信し、アクセス制御部７０２に渡す。アクセス制御部７０２は、ユーザーに認証処理を促す認証画面（不図示）を生成し、クライアント１０２が備えるＷｅｂブラウザ（不図示）に表示する。なお、ステップＳ１００３においてアクセス管理サービスシステム１０７に送信されるスコープ情報は、クライアントを介して渡される。具体的には、外部有償サービス１０３は、クライアントに対してスコープ情報を送信するとともに、アクセス管理サービスシステム１０７にリダイレクトするようリダイレクト指示を行う。リダイレクトとは、リダイレクト指示により指定されるコンピューターにアクセスする技術であり、リダイレクト指示を受けたクライアントは、リダイレクト指示が指定するアクセス管理サービスシステム１０７へ、送信されたスコープ情報を送信する。リダイレクト指示により指定されるコンピューターはＵＲＬにより指定されることを実施例１では想定している。アクセス管理サービスシステム１０７は、リダイレクト指示に従いアクセスしてくるクライアントからスコープ情報を受け取り、ユーザーの権限確認を行う。
【００５８】
ステップＳ１００５において、ユーザーはクライアント１０２のＷｅｂブラウザに表示された認証画面に、ユーザーＩＤとパスワードを入力して、アクセス管理サービスシステム１０７に認証リクエストを送信する。ステップＳ１００６において、アクセス管理リクエスト処理部７０１は、クライアント１０２から認証リクエストを受信し、アクセス制御部７０２に渡す。アクセス制御部７０２は、認証リクエストに含まれるユーザーＩＤ、パスワードを検証する。具体的には、認証リクエストに含まれるユーザーＩＤ、パスワードの組み合わせが認証データ管理部７０３に格納されたユーザーテーブル８００に登録されているかを確認する。認証リクエストに含まれるユーザーＩＤ、パスワードの組み合わせがユーザーテーブル８００に登録されている場合、アクセス制御部７０２は、クライアント１０２を操作するユーザーをアクセス管理サービスシステム１０７で管理しているユーザーであると判断し、ステップＳ１００７に進み処理を継続する。認証リクエストに含まれるユーザーＩＤ、パスワードの組み合わせがユーザーテーブル８００に登録されていない場合には、アクセス制御部７０２は、クライアント１０２を操作するユーザーをアクセス管理サービスシステム１０７で管理しているユーザーではないと判断し、認証エラー画面（不図示）を生成し、クライアント１０２が備えるＷｅｂブラウザ（不図示）に送信する。
【００５９】
ステップＳ１００７において、アクセス制御部７０２は、ステップＳ１００６において認証したユーザーが、外部有償サービスシステム１０３の連携先のサービスシステムが提供するサービスを受ける権限を有しているかを確認する。具体的には、アクセス制御部７０２は、ステップＳ１００６において認証したユーザーに対応するユーザーＩＤカラム８０１に格納されているユーザーＩＤに紐付くロールＩＤを、ユーザー割り当てロールテーブル９２０を参照して取得する。例えば、ステップＳ１００６で認証したユーザーのユーザーＩＤが「Ｕｓｅｒ１」であった場合、「ＵｓｅｒＲｏｌｅ＿Ｆｏｒｍ」というロールＩＤを取得する。次に、アクセス制御部７０２は、ステップＳ１００４で受信した認可要求リクエストに含まれるスコープＩＤに紐付くロールＩＤを、スコープテーブル１１００を参照して取得する。
【００６０】
図１１は、ステップＳ１００７において、外部有償サービスシステム１０３が連携先のサービスシステムから受けられるサービスをデータ構造で示したテーブルである。スコープテーブル１１００は、スコープＩＤカラム１１０１とロールＩＤ１１０２から構成され、認可データ管理部７０４に格納される。スコープＩＤカラム１１０１は、スコープ情報を格納するカラムである。ここでのスコープ情報は、サービス連携テーブル４００のスコープＩＤカラム４０３で格納され、ステップＳ１００４においてアクセス管理サービスシステム１０７が受信する認可要求リクエストに含まれるスコープ情報と同種である。ロールＩＤカラム１１０２は、各オンラインサービスを実行可能なロール情報を格納するカラムであり、ロールテーブル９１０に格納されたロールＩＤカラム９１１の値と同種である。アクセス管理サービスシステムは、このスコープテーブル１１００を基に、外部有償サービスシステム１０３が連携先のサービスシステムから受けられるサービスを受けられるか否かを確認する。
【００６１】
例えば、認可要求リクエストに含まれる帳票サービスシステム１０５に対応するスコープＩＤの値は、スコープテーブル４００によると「Ｓｃｏｐｅ＿ＦｏｒｍＵｓｅｒ」、「Ｓｃｏｐｅ＿ＦｏｒｍＩｎｖｏｋｅｒ」である。このため、「ＵｓｅｒＲｏｌｅ＿Ｆｏｒｍ」、「ＳｅｒｖｉｃｅＲｏｌｅ＿Ｆｏｒｍ」の二つのロールＩＤを取得する。最後に、アクセス制御部７０２は、ユーザー割り当てロールテーブル９２０を参照して取得したロールＩＤと、スコープテーブル１１００を参照して取得したロールＩＤを比較する。アクセス制御部７０２は、一致していることを確認した場合、ステップＳ１００６において認証したユーザーは帳票サービスシステム１０５のオンラインサービスを利用できる権限を有していると判断する。このように判断された場合、外部有償サービスシステム１０３がそのユーザーの権限の範囲内で帳票サービスシステム１０５を利用することを、そのユーザーが認可できると判断し、後述するＳ１００９の認可処理を実行する。例えば、ユーザーＩＤ「Ｕｓｅｒ１」に紐付くロールＩＤ「ＵｓｅｒＲｏｌｅ＿Ｆｏｒｍ」と、スコープＩＤ「Ｓｃｏｐｅ＿ＦｏｒｍＵｓｅｒ」に紐付くロールＩＤ「ＵｓｅｒＲｏｌｅ＿Ｆｏｒｍ」は一致するため、ユーザーＩＤ「Ｕｓｅｒ１」のユーザーには帳票サービスシステム１０５を実行する権限を有していると判断する。なお、ここで取得したインボーカー用のスコープ情報と、それに基づき取得したロールＩＤは後述するＳ１０１２で利用される。
【００６２】
アクセス制御部７０２は、ユーザー割り当てロールテーブル９２０を参照して取得したロールＩＤと、スコープテーブル１１００を参照して取得したロールＩＤを比較する。一致なかった場合、アクセス制御部７０２は、ステップＳ１００６において認証した帳票サービスシステム１０５のユーザーが、帳票サービスシステム１０５のオンラインサービスを利用する権限を有していないと判断する。そして、アクセス制御部７０２は、ユーザーのスコープエラーである旨を、クライアント１０２のＷｅｂブラウザを介して外部有償サービスシステム１０３に送信して、ステップＳ１０２２に進む。
【００６３】
ステップＳ１０２２において、リクエスト処理部３０１は、クライアント１０２のＷｅｂブラウザを介して、アクセス管理サービスシステム１０７からスコープエラーを受信し、サービス制御部３０２に渡す。サービス制御部３０２は、スコープエラーを受け取るとスコープエラー画面（不図示）を生成し、クライアント１０２が備えるＷｅｂブラウザ（不図示）に送信する。ステップＳ１０２５において、クライアント１０２は、外部有償サービスシステム１０３からスコープエラー画面を受信すると、Ｗｅｂブラウザにそれを表示し、ステップＳ１００１で指示した帳票生成指示を中断する。このスコープエラー画面は、第２のオンラインサービスに相当する帳票サービスを利用する権限を、そのユーザーが有していないことを認識させるためのスコープエラー画面である。
【００６４】
ステップＳ１００８において、アクセス制御部７０２は認可画面１２００を生成し、クライアント１０２が備えるＷｅｂブラウザ（不図示）に送信する。図１２は、アクセス制御部７０２がステップＳ１００８において生成する認可画面を示した図である。図１２の認可画面が、ステップＳ１００８で認可画面送信される画面である。認可画面１２００は、情報表示部１２０１と認可ボタン１２０２、認可キャンセルボタン１２０３から構成される。情報表示部１２０１は、認可を与えるサービスと、認可を与えられたサービスが実行するオンラインサービスの情報をユーザーに対して示す情報表示部である。本実施例においては、認可を与えるサービスとは外部有償サービスシステム１０３であり、認可を与えられたサービスが実行するサービスとは帳票サービスシステム１０５、または印刷サービスシステム１０６を指す。認可ボタン１２０２は、認可を承認する際にユーザーによって押下されるボタンである。認可キャンセルボタン１２０３は、ユーザーが認可を拒否する場合に押下されるボタンである。
【００６５】
ステップＳ１００９において、ユーザーが認可画面１２００の認可ボタン１２０２を押下すると、クライアント１０２はアクセス管理サービスシステム１０７に対して認可承認リクエストを送信する。ステップＳ１０１０において、アクセス制御部７０２は、クライアント１０２から認可承認リクエストを受信すると、認可コードを生成し、認可データ管理部７０４で管理される認可コードテーブル１３００に格納する。
【００６６】
図１３は、ステップＳ１０１０において、アクセス制御部７０２が生成する認可コードを管理するデータ構造を示したテーブルである。認可コードテーブル１３００は、認可コードＩＤカラム１３０１、ユーザーＩＤカラム１３０２、スコープＩＤカラム１３０３によって構成され、認可データ管理部７０４で管理される。認可コードＩＤカラム１３０１は、アクセス制御部７０２によって生成される認可コードを格納するカラムである。ユーザーＩＤカラム１３０２は、ステップＳ１００９において認可画面１２００の認可ボタン１２０２を押下したユーザーのユーザーＩＤを格納するカラムである。ユーザーＩＤカラム１３０２に格納されるユーザーＩＤの値は、ユーザーテーブル８００で管理され、認可ボタン１２０２を押下したユーザーに該当するユーザーＩＤカラム８０１の値が格納される。スコープＩＤカラム１３０３は、ステップＳ１００４において、アクセス制御部７０２が受信した認可要求リクエストに含まれるスコープＩＤの値を格納するカラムである。
【００６７】
ステップＳ１０１０において、アクセス制御部７０２は、認可コードを認可コードテーブル１３００に格納した後、ステップＳ１００９の認可承認リクエストの応答として認可コードＩＤカラム１３０１に格納された認可コードＩＤを、クライアント１０２のＷｅｂブラウザを介して外部有償サービスシステム１０３に送信する。これは、ステップＳ１００３で説明したように、クライアントにリダイレクト指示を送ることで認可コードが外部有償サービス１０３に渡される。ステップＳ１０１１において、外部有償サービスシステム１０３は、アクセス管理サービスシステム１０７から認可コードＩＤを受信すると、認可コードテーブル４１０に格納する。次に、認可トークン要求リクエストを生成して、アクセス管理サービスシステム１０７に送信する。このとき、外部有償サービス１０３は、認可コードＩＤ、インボーカーＩＤ、及びインボーカーＩＤに対応するパスワードを含む認可トークン要求リクエストを生成する。
【００６８】
ステップＳ１０１２において、アクセス管理サービスシステム１０７のアクセス管理リクエスト処理部７０１は、外部有償サービスシステム１０３から認可トークン要求リクエストを受信し、アクセス制御部７０２に渡す。アクセス制御部７０２は、まず認可トークン要求リクエストに含まれるインボーカーＩＤ、パスワードを検証する。具体的には、認可トークン要求リクエストに含まれるインボーカーＩＤ、パスワードの組み合わせが認証データ管理部７０３に格納されたユーザーテーブル８００に登録されているかを確認する。認可トークン要求リクエストに含まれるインボーカーＩＤ、パスワードの組み合わせがユーザーテーブル８００に登録されている場合には、アクセス制御部７０２は、インボーカーはアクセス管理サービスシステム１０７が管理するサービスを利用する権限があると判断する。認可トークン要求リクエストに含まれるユーザーＩＤ、パスワードの組み合わせがユーザーテーブル８００に登録されていない場合には、アクセス制御部７０２は、インボーカーはアクセス管理サービスシステム１０７が管理するサービスを利用する権限がないと判断し、認証エラーを外部有償サービスシステム１０３に送信して、ステップＳ１０２３に進む。なお、上述した通りインボーカーは外部有償サービスシステム１０３に固有のＩＤである。
【００６９】
アクセス管理サービスシステム１０７が管理するサービスを利用する権限をインボーカーは有していると判断されたら、アクセス制御部７０２は、インボーカーが帳票サービスシステム１０５に送信する帳票生成要求を実行する権限を有しているか否かを確認する。即ち、インボーカーは帳票サービスシステム１０５が提供する帳票サービスを利用する権限を有しているか否かを確認することと同義である。よって、権限の確認の処理が、実施例１で示した帳票生成要求を実行する権限の確認に限定されるものではないということである。
【００７０】
具体的には、アクセス制御部７０２は、ステップＳ１０１２において認証したインボーカーに対応するユーザーＩＤカラム８０１に格納されているユーザーＩＤを特定し、その特定されたユーザーＩＤに紐付くロールＩＤを、ユーザー割り当てロールテーブル９２０を参照して取得する。例えば、ステップＳ１０１２で認証したユーザーのユーザーＩＤが「インボーカー」であった場合、「ＳｅｒｖｉｃｅＲｏｌｅ＿Ｆｏｒｍ」というロールＩＤを取得する。次に、アクセス制御部７０２は、スコープテーブル１１００を参照して、インボーカーのロールＩＤに対応するスコープＩＤ１１０１を取得する。例えば、インボーカー、即ち、外部有償サービスシステム１０３のロールＩＤ「ＳｅｒｖｉｃｅＲｏｌｅ＿Ｆｏｒｍ」に対応するスコープＩＤは「Ｓｃｏｐｅ＿ＦｏｒｍＩｎｖｏｋｅｒ」である。
【００７１】
次に、アクセス制御部７０２は、認可トークン要求リクエストに含まれる認可コードＩＤの値に該当する認可コードを、認可コードテーブル１３００を参照して取得する。そして、アクセス制御部７０２は、取得した認可コードのスコープＩＤカラム１３０３の値を取得し、取得したインボーカーのスコープＩＤと比較する。一致していることを確認した場合、アクセス制御部７０２は外部有償サービスシステム１０３が、帳票サービスシステム１０５に送信する帳票生成要求を実行する権限を有していると判断し、ステップＳ１０１３に進む。なお、受信したコードに紐付くスコープ情報を基に第１のサーバーシステムが利用したいオンラインサービスが第２のオンラインサービスであることを特定するとは、アクセス制御部７０２が認可コードに紐付くスコープＩＤを取得する処理に相当する。この際、アクセス制御部７０２は、認可コードに紐付くスコープＩＤを基に、第１のサーバーシステムが利用したいオンラインサービスが第２のオンラインサービスであることを認識する形態であっても良い。実施例１におけるアクセス制御部７０２は、第１のサーバーシステムが利用したいオンラインサービスを認識することはない。
【００７２】
スコープＩＤの値が一致しなかった場合、アクセス制御部７０２は、外部有償サービスシステム１０３が帳票サービスシステム１０５に送信する帳票生成要求を実行する権限を有していないと判断し、スコープエラーを外部有償サービスシステム１０３に送信して、ステップＳ１０２３に進む。ステップＳ１０２３において、外部有償サービスシステム１０３のリクエスト処理部３０１は、アクセス管理サービスシステム１０７から認証エラー、あるいはスコープエラーを受信してサービス制御部３０２に渡す。サービス制御部３０２は、エラーを受け取るとエラーに対応した認証エラー画面、またはスコープエラー画面（不図示）を生成し、クライアント１０２が備えるＷｅｂブラウザ（不図示）に送信する。このスコープエラー画面は、第１のサーバーシステムである外部有償サービスシステム１０３は、第２のオンラインサービスである帳票サービスを利用する権限を有していないことを示すものである。
【００７３】
実施例１では、アクセスしてきたクライアントを操作するユーザーが第２のオンラインサービスを利用できる権限を有していないと確認された場合は、ユーザーは第２のオンラインサービスを利用する権限を有していないことをユーザーに認識させるための認証エラー画面を送信する。そして、アクセスしてきたクライアントを操作するユーザーが第２のオンラインサービスを利用できる権限を有していると確認はされたが、第１のサービスシステムが利用可能なオンラインサービスの中に特定された第２のオンラインサービスが含まれていないと確認された場合は、第１のサービスシステムは第２のオンラインサービスを利用する権限を有していないことをユーザーに認識させるためのスコープエラー画面を送信する。以上の様な構成にすることで、なぜ、外部有償サービスシステム１０３は、帳票サービスシステム１０５が提供するオンラインサービスである帳票サービスを利用できないかを正確に認識することができる。正確に認識した結果、例えば、ユーザーが第２のオンラインサービスを利用できるように手続きを取ることもできる。また、そもそも、外部有償サービスシステム１０３は帳票サービスシステム１０５に対応していないので、別の外部有償サービスシステムを利用する対応を取ることもできる。
【００７４】
ステップＳ１０２５において、クライアント１０２は、外部有償サービスシステム１０３から認証エラー画面、あるいはスコープエラー画面を受信すると、Ｗｅｂブラウザにそれを表示し、ステップＳ１００１で指示した帳票生成指示を中断する。ステップＳ１０１３において、アクセス制御部７０２は、認可トークンを生成し、認可データ管理部７０４で管理される認可トークンテーブル１４００に格納する。
【００７５】
図１４は、ステップＳ１０１３において、アクセス制御部７０２が発行する認可トークンを管理するデータ構造を示したテーブルである。認可トークンテーブル１４００は、認可トークンＩＤカラム１４０１、ユーザーＩＤカラム１４０２、インボーカーカラム１４０３、スコープＩＤカラム１４０４から構成され、認可データ管理部７０４で管理される。認可トークンＩＤカラム１４０１は、アクセス制御部７０２によって発行される認可トークンを格納するカラムである。ユーザーＩＤカラム１４０２は、ステップＳ１００９において認可画面１２００の認可ボタン１２０２を押下したユーザーのユーザーＩＤを格納するカラムである。ユーザーＩＤカラム１３０２に格納されるユーザーＩＤの値は、ユーザーテーブル８００で管理され、認可ボタン１２０２を押下したユーザーに該当するユーザーＩＤカラム８０１の値が格納される。インボーカーＩＤカラム１４０３は、ステップＳ１０１２において帳票サービスシステム１０５に送信する帳票生成要求を実行する権限を有していると判断されたインボーカーＩＤを格納するカラムである。インボーカーＩＤカラム１４０３に格納されるユーザーＩＤの値は、ユーザーテーブル８００で管理され、外部有償サービスシステム１０３に該当するユーザーＩＤカラム８０１の値が格納される。スコープＩＤカラム１４０４は、ステップＳ１０１０において、認可コードテーブル１３００に格納されたスコープＩＤカラム１３０３の値を格納するカラムである。
【００７６】
ステップＳ１０１３において、アクセス制御部７０２は、認可トークンを認可トークンテーブル１４００に格納した後、ステップＳ１０１２の認可トークン要求リクエストの応答として、認可トークンＩＤカラム１４０１に格納された認可トークンＩＤを外部有償サービスシステム１０３に返す。ステップＳ１０１４において、外部有償サービスシステム１０３は、アクセス管理サービスシステム１０７から認可トークンを受信すると、認可トークンテーブル４２０に格納する。
【００７７】
ステップＳ１０１５において、外部有償サービスシステム１０３は、帳票サービスシステム１０５に対して帳票生成要求を送信する。このとき、外部有償サービスシステム１０３は、認可トークンテーブル４２０に格納されている認可トークンを取りだす。そして、外部有償サービスシステム１０３は、ステップＳ１００３においてクライアント１０２から受信した帳票生成に使用する帳票フォームデータと帳票に差し込むデータから帳票生成要求を生成する。外部有償サービスシステム１０３は、帳票生成要求を帳票生成サービスシステム１０５へ送信するとともに、取りだした認可トークンも送信する。認可トークンは帳票生成要求に含まれているものとする。
【００７８】
ステップＳ１０１６において、帳票リクエスト処理部５０１は、インターネット１００を経由して、外部有償サービスシステム１０３から帳票生成要求を受信する。帳票リクエスト処理部５０１は、受信した帳票生成要求からまず、認可トークンを解析し、帳票制御部５０２に渡す。帳票制御部５０２は、イントラネット１０１を経由してアクセス管理サービスシステム１０７に認可トークンの検証リクエストを送信する。このとき、帳票制御部５０２は、帳票リクエスト処理部５０１から受信した認可トークン、および帳票サービスを実行するために必要なスコープＩＤを基にトークンの検証リクエストを生成する。
【００７９】
ステップＳ１０１７において、アクセス管理リクエスト処理部７０１は、イントラネット１０１を経由して、帳票サービスシステム１０５からトークンの検証リクエストを受信する。アクセス管理リクエスト処理部は、受信したトークン検証リクエストから認可トークンＩＤ、および帳票サービスを利用する権限を示すスコープＩＤを取りだし、解析し、アクセス制御部７０２に渡す。次に、アクセス制御部７０２は、認可データ管理部７０４が管理する認可トークンテーブル１４００を参照して、受信した認可トークンＩＤ、スコープＩＤに対応する認可トークンが格納されているかを確認する。
【００８０】
まず、受信した認可トークンＩＤに対応する認可トークンが格納されていた場合には、ユーザーＩＤカラム１４０２、スコープＩＤカラム１４０４カラムに格納されている値を参照する。そして、その認可トークンが帳票生成要求を実行する権限をもったユーザーの認可によって生成されたものであるかどうかを確認する。具体的には、検証リクエストに含まれるスコープＩＤ値とスコープＩＤカラム１４０４の値を比較する。このとき検証リクエストに含まれるスコープＩＤ値がスコープＩＤカラム１４０４に格納されていれば良い。次に、ユーザーＩＤカラム１４０２に格納されているユーザーＩＤ値が、ユーザー割り当てロールテーブル９２０のユーザーＩＤカラム９２１に格納されているかをそれぞれ確認する。次に、ユーザーＩＤカラム１４０２に格納されているユーザーＩＤ値に対応するロールＩＤ値をユーザー割り当てロールテーブル９２０のロールＩＤカラム９２２から取得する。そして、スコープテーブル１１００のロールＩＤカラム１１０２に格納されているかをそれぞれ確認する。
【００８１】
最後に該当するロールＩＤカラム１１０２に対応するそれぞれのスコープＩＤカラム１１０１のスコープＩＤ値と、認可トークンテーブル１４００のスコープＩＤカラム１４０４の値とを比較する。一致していた場合にはその認可トークンがユーザーによって生成されたものであると判断し、ステップＳ１０１８に進む。認可トークンがユーザーによって生成されたものではないと判断した場合には、アクセス制御部７０２は、ユーザーが帳票生成要求を実行する権限を有していないと判断する。そして、トークンエラーを外部有償サービスシステム１０３に送信して、ステップＳ１０２４に進む。
【００８２】
ステップＳ１０１８において、アクセス制御部７０２は、ステップＳ１０１７に引き続き認可トークンが帳票生成要求を実行する権限をもったインボーカーによって生成されたものであるかどうかを確認する。具体的には、まず検証リクエストに含まれるスコープＩＤ値とスコープＩＤカラム１４０４の値を比較する。このとき検証リクエストに含まれるスコープＩＤ値がスコープＩＤカラム１４０４に格納されていれば良い。次に、インボーカーＩＤカラム１４０３に格納されているユーザーＩＤ値が、ユーザー割り当てロールテーブル９２０のユーザーＩＤカラム９２１に格納されているかをそれぞれ確認する。次に、インボーカーＩＤカラム１４０３に格納されているユーザーＩＤ値に対応するロールＩＤ値をユーザー割り当てロールテーブル９２０のロールＩＤカラム９２２から取得する。そして、スコープテーブル１１００のロールＩＤカラム１１０２に格納されているかをそれぞれ確認する。
【００８３】
最後に該当するロールＩＤカラム１１０２に対応するそれぞれのスコープＩＤカラム１１０１のスコープＩＤ値と、認可トークンテーブル１４００のスコープＩＤカラム１４０４の値とを比較する。一致していた場合にはその認可トークンがインボーカーによって生成されたものであると判断する。アクセス制御部７０２はその結果を応答として帳票サービスシステム１０５に送信し、ステップＳ１０１９に進む。認可トークンがインボーカーによって生成されたものではないと判断した場合には、アクセス制御部７０２は、インボーカーが帳票生成要求を実行する権限を有していないと判断する。そして、トークンエラーを外部有償サービスシステム１０３に送信して、ステップＳ１０２４に進む。
【００８４】
ステップＳ１０２４において、外部有償サービスシステム１０３のリクエスト処理部３０１はインターネット１００を介して、アクセス管理サービスシステム１０７からトークンエラーを受信してサービス制御部３０２に渡す。サービス制御部３０２は、トークンエラーを受け取るとトークンエラー画面（不図示）を生成し、クライアント１０２が備えるＷｅｂブラウザ（不図示）に送信する。ステップＳ１０２５において、クライアント１０２は、外部有償サービスシステム１０３からトークンエラー画面を受信すると、Ｗｅｂブラウザにその画面を表示し、ステップＳ１００１で指示した帳票生成指示を中断する。
【００８５】
ステップＳ１０１９において、帳票リクエスト処理部５０１は、アクセス管理サービスシステム１０７から、トークン検証リクエストの応答を受信する。そして、帳票リクエスト処理部５０１は、受信した帳票生成要求から帳票生成に使用する帳票フォームデータと帳票に差し込むデータを解析し、帳票制御部５０２に渡す。帳票制御部５０２は、帳票データ処理部５０３に受信した帳票フォームデータと帳票に差し込むデータを渡し、帳票生成処理を実行する。帳票制御部５０２は、帳票生成処理が完了すると、実行結果である帳票データをまず、帳票データ管理部５０４に保存する。そして、外部有償サービスシステム１０３に、帳票生成要求の応答として、生成した帳票データを送信する。このように第１のサーバーシステムに相当する外部有償サービスシステム１０３が、発行されたアクセストークンを用いることで第２のオンラインサービスに相当する帳票サービスシステム１０５が提供する帳票サービスを利用可能となる。そして、外部有償サービスと帳票サービスとを連携させたマッシュアップサービスが実現されるのである。２つ以上のサービスを連携させることで実現するサービスをマッシュアップサービスと称する。
【００８６】
ステップＳ１０２０において、外部有償サービスシステム１０３は、帳票サービスシステム１０５から帳票データを受信し、クライアント１０２が備えるＷｅｂブラウザ（不図示）に送信する。ステップＳ１０２１において、クライアント１０２は、外部有償サービスシステム１０３から帳票データを受信すると、Ｗｅｂブラウザに帳票データを表示する。以上の処理により、ステップＳ１００１において外部有償サービスシステム１０３に対し指示した帳票生成指示が正常に終了する。
【００８７】
以上、実施例１は、連携元のサービスを提供するサーバー自身が、連携先のサービスに対して適切なアクセス権限を有していなければならないようなサービスと連携する場合を想定した実施例である。そして実施例１では、ユーザーと連携元のサービスが連携先のサービスに対して適切なアクセス権限を有しているか否かをサービス実行前に確認することを達成することが出来る。
【実施例２】
【００８８】
実施例１では、外部有償サービスシステム１０３が一つのオンラインサービスシステム、具体的には帳票サービスシステム１０５を実行するオンラインサービス連携について説明した。実施例２では、外部有償サービスシステム１０３が複数のオンラインサービスシステム、具体的には帳票サービスシステム１０５、および印刷サービスシステム１０６が提供するオンサインサービスとの連携について、図１５に示すシーケンス図を用いて説明する。図１５は、ユーザーが外部有償サービスシステム１０３を介して帳票生成印刷サービスを利用し、外部有償サービスシステム１０３が保持するデータを基に変換された帳票データを印刷する一連の処理を示したシーケンス図である。なお、実施例２において特に説明がない限りは、実施例１で説明したものと同じ形態である。
【００８９】
なお、ユーザーが、外部有償サービスシステム１０３を介して帳票生成印刷サービスを利用するためには、外部有償サービスシステム１０３、帳票サービスシステム１０５、および印刷サービスシステム１０６の全てのシステムにおいて認証情報を登録済みでなければならない。また、帳票生成印刷サービスにおいて、実際に帳票サービスシステムに帳票印刷リクエストを送信するのは外部有償サービスシステム１０３である。そのため、外部有償サービスシステム１０３も、帳票サービスシステム１０５、印刷サービスシステム１０６を利用できる権限を有していなければならない。そのうえで、マッシュアップ時には、外部有償サービスシステム１０３を操作するユーザーの権限の範囲内で、帳票サービスシステム１０５、印刷サービスシステム１０６を利用できるようにしなければならない。また、同様に外部有償サービスシステム１０３の権限の範囲内で、帳票サービスシステム１０５、印刷サービスシステム１０６を利用できるようにしなければならない。
【００９０】
ステップＳ１５０１において、ユーザーはクライアント１０２を操作して、外部有償サービスシステム１０３へ帳票生成印刷指示のリクエストを送信する。このとき、外部有償サービスシステム１０３は、帳票を生成するのに必要となる帳票フォームデータと、帳票に差し込むデータをユーザーに選択可能とする画面情報（不図示）を生成する。そして、クライアント１０２が備えるＷｅｂブラウザ（不図示）に画面情報を表示する。ユーザーはＷｅｂブラウザに表示された画面情報から、帳票生成に使用する帳票フォームデータと帳票に差し込むデータ、印刷に使用するプリンターとを選択することで、帳票生成印刷指示のリクエストが生成される。
【００９１】
ステップＳ１５０２において、リクエスト処理部３０１はクライアント１０２から送信された帳票生成印刷指示のリクエストを受信する。リクエスト処理部３０１は、受信した帳票生成印刷指示のリクエストから、帳票生成に使用する帳票フォームデータと帳票に差し込むデータ、印刷に使用するプリンターの情報とを解析し、サービス制御部３０２に情報を渡す。サービス制御部３０２は、トークン管理部３０５を参照して、トークンテーブル４２０の認可トークンＩＤカラム４２２に帳票サービスシステム１０５、および印刷サービスシステム１０６が提供するオンラインサービスを利用するために必要な認可トークンが格納されているか否かを確認する。
【００９２】
認可トークンＩＤカラム４２２に認可トークンが格納されていればステップＳ１５１５に進み、外部有償サービスシステム１０３は帳票サービスシステム１０５に対して帳票生成印刷要求を送信する。認可トークンＩＤカラム４２２に認可トークンが格納されていなければステップＳ１５０３に進み、外部有償サービスシステム１０３は、帳票サービスシステム１０５、および印刷サービスシステム１０６に対する認可要求リクエストを生成し、アクセス管理サービスシステム１０７に送信する。
【００９３】
このとき、外部有償サービスシステム１０３は、サービス連携テーブル４００から、帳票サービスシステム１０５、および印刷サービスシステム１０６に該当するＡＰＩカラム４０２値とスコープＩＤカラム４０３の値を参照して、認可要求リクエストを生成する。
【００９４】
このとき、認可要求リクエストにスコープＩＤが含める理由は、ユーザーが帳票サービスシステム１０５の実行を認可する権限があるかを検証するためである。アクセス管理サービスシステム１０７は、スコープテーブル１１００、およびユーザー割り当てロールテーブル９２０を参照し、ユーザーが、外部有償サービスシステム１０３に対して帳票サービスシステム１０５の実行を認可する権限があるか否かを検証する。具体的には、ステップＳ１５０３において、外部連携サービス１０３からアクセス管理サービスシステム１０７に送信される認可要求リクエストにはスコープＩＤとして「Ｓｃｏｐｅ＿ＦｏｒｍＵｓｅｒ」「Ｓｃｏｐｅ＿ＦｏｒｍＩｎｖｏｋｅｒ」「Ｓｃｏｐｅ＿ＰｒｉｎｔＵｓｅｒ」「Ｓｃｏｐｅ＿ＰｒｉｎｔＩｎｖｏｋｅｒ」の値が含まれるものとする。
【００９５】
ステップＳ１５０４およびステップＳ１５０５においては、図１０のステップＳ１００４およびステップＳ１００５と同様のため説明を省略する。ステップＳ１５０６において、アクセス管理リクエスト処理部７０１は、クライアント１０２から認証リクエストを受信し、アクセス制御部７０２に渡す。アクセス制御部７０２は、認証リクエストに含まれるユーザーＩＤ、パスワードを検証する。具体的には、認証リクエストに含まれるユーザーＩＤ、パスワードの組み合わせが認証データ管理部７０３に格納されたユーザーテーブル８００に登録されているかを確認する。
【００９６】
認証リクエストに含まれるユーザーＩＤ、パスワードの組み合わせがユーザーテーブル８００に登録されている場合、アクセス制御部７０２は、クライアント１０２を操作するユーザーをアクセス管理サービスシステム１０７で管理しているユーザーであると判断し、ステップＳ１５０７に進む。認証リクエストに含まれるユーザーＩＤ、パスワードの組み合わせがユーザーテーブル８００に登録されていない場合、アクセス制御部７０２は、クライアント１０２を操作するユーザーをアクセス管理サービスシステム１０７で管理しているユーザーではないと判断し、認証エラー画面（不図示）を生成し、クライアント１０２が備えるＷｅｂブラウザ（不図示）に送信する。
【００９７】
ステップＳ１５０７において、アクセス制御部７０２は、ステップＳ１５０６において認証したユーザーが、外部有償サービスシステム１０３の連携先のサービスシステムが提供するサービスを受ける権限を有しているか否かを確認する。具体的には、アクセス制御部７０２は、ステップＳ１５０６において認証したユーザーに対応するユーザーＩＤカラム８０１に格納されているユーザーＩＤに紐付くロールＩＤを、ユーザー割り当てロールテーブル９２０を参照して取得する。例えば、ステップＳ１５０６で認証したユーザーのユーザーＩＤが「Ｕｓｅｒ１」であった場合、帳票サービスシステム１０５のロールＩＤとして「ＵｓｅｒＲｏｌｅ＿Ｆｏｒｍ」、印刷サービスシステム１０６のロールＩＤとして「ＵｓｅｒＲｏｌｅ＿Ｐｒｉｎｔ」というロールＩＤを取得する。
【００９８】
次に、アクセス制御部７０２は、ステップＳ１５０４で受信した認可要求リクエストに含まれるスコープＩＤに紐付くロールＩＤを、スコープテーブル１１００を参照して取得する。例えば、認可要求リクエストに含まれる帳票サービスシステム１０５に対応するスコープＩＤの値は、スコープテーブル４００によると「Ｓｃｏｐｅ＿ＦｏｒｍＵｓｅｒ」「Ｓｃｏｐｅ＿ＦｏｒｍＩｎｖｏｋｅｒ」である。また、印刷サービスシステム１０６に対応するスコープＩＤの値は、スコープテーブル４００によると「Ｓｃｏｐｅ＿ＰｒｉｎｔＵｓｅｒ」「Ｓｃｏｐｅ＿ＰｒｉｎｔＩｎｖｏｋｅｒ」である。このため、ここでは帳票サービスシステム１０５に対応するロールＩＤとして「ＵｓｅｒＲｏｌｅ＿Ｆｏｒｍ」「ＳｅｒｖｉｃｅＲｏｌｅ＿Ｆｏｒｍ」の二つ、印刷サービスシステム１０６に対応するロールＩＤとして「ＵｓｅｒＲｏｌｅ＿Ｐｒｉｎｔ」「ＳｅｒｖｉｃｅＲｏｌｅ＿Ｐｒｉｎｔ」の二つ、合計四つのロールＩＤを取得する。
【００９９】
最後に、アクセス制御部７０２は、ユーザー割り当てロールテーブル９２０を参照して取得したロールＩＤと、スコープテーブル１１００を参照して取得したロールＩＤを比較する。そして、一致していることを確認した場合、ステップＳ１５０６において認証した帳票サービスシステム１０５のユーザーが、外部有償サービスシステム１０３の連携先のサービスシステムが提供するサービスを受ける権限を有していると判断し、ステップＳ１５０８に進む。
【０１００】
例えば、ユーザーＩＤ「Ｕｓｅｒ１」に紐付くロールＩＤ「ＵｓｅｒＲｏｌｅ＿Ｆｏｒｍ」とスコープＩＤ「Ｓｃｏｐｅ＿ＦｏｒｍＵｓｅｒ」に紐付くロールＩＤ「ＵｓｅｒＲｏｌｅ＿Ｆｏｒｍ」が一致するため、ユーザーＩＤ「Ｕｓｅｒ１」のユーザーは帳票サービスシステム１０５の帳票サービスを利用する権限を有していると判断する。加えて、ユーザーＩＤ「Ｕｓｅｒ１」に紐付くロールＩＤ「ＵｓｅｒＲｏｌｅ＿Ｐｒｉｎｔ」と、スコープＩＤ「Ｓｃｏｐｅ＿ＰｒｉｎｔＵｓｅｒ」に紐付くロールＩＤ「ＵｓｅｒＲｏｌｅ＿Ｐｒｉｎｔ」は一致するため、ユーザーＩＤ「Ｕｓｅｒ１」のユーザーは印刷サービスシステム１０６の印刷サービスを利用する権限も有していると判断する。
【０１０１】
アクセス制御部７０２は、ユーザー割り当てロールテーブル９２０を参照して取得したロールＩＤと、スコープテーブル１１００を参照して取得したロールＩＤを比較する。そして一致しなかった場合、アクセス制御部７０２は、ステップＳ１５０６において認証したユーザーは、外部有償サービスシステム１０３の連携先のサービスシステムが提供するサービスを受ける権限を有していないと判断する。そして、アクセス制御部７０２は、スコープエラーのリダイレクト要求を、クライアント１０２のＷｅｂブラウザを介して外部有償サービスシステム１０３に送信し、ステップＳ１５２７に進む。
【０１０２】
ステップＳ１５２７において、リクエスト処理部３０１は、アクセス管理サービスシステム１０７からスコープエラーのリダイレクト要求を受信し、サービス制御部３０２にスコープエラーの情報を渡す。サービス制御部３０２は、スコープエラーのリダイレクト要求を受け取るとスコープエラー画面（不図示）を生成し、クライアント１０２が備えるＷｅｂブラウザ（不図示）に送信する。このユーザーのスコープエラー画面は実施例１で説明したものと同じ画面とするが、実施例２では２つのサービスと連携することが前提なので次の様な画面にしても良い。即ち、ユーザーが２つのサービスの内、何れか１つのサービスを利用する権限を有していない場合には、そのサービスを利用する権限を有していないことを認識させる画面であっても良い。その際、サービスを利用する権限を有しているサービスを認識させても良い。この画面を表示することで、外部有償サービス１０３から帳票印刷要求を指示するためにどのような処理を行えばよいかを認識し易くなる。
【０１０３】
ステップＳ１５３０において、クライアント１０２は、外部有償サービスシステム１０３からスコープエラー画面を受信すると、Ｗｅｂブラウザにそれを表示し、ステップＳ１５０１で指示した帳票生成指示を中断する。ステップＳ１５０８、ステップＳ１５０９およびステップＳ１５１０においては、図１０のステップＳ１００８、ステップＳ１００９およびステップＳ１０１０と同様のため説明を省略する。
【０１０４】
ステップＳ１５１１において、外部有償サービスシステム１０３は、アクセス管理サービスシステム１０７から認可コードＩＤを受信すると、認可コードテーブル４１０に格納する。次に、認可トークン要求リクエストを生成して、アクセス管理サービスシステム１０７に送信する。このとき、外部有償サービス１０３は、認可コードＩＤ、帳票サービスシステム１０５、および印刷サービスシステム１０６に対するインボーカーＩＤ、およびそのインボーカーＩＤに対応するパスワードを含む認可トークン要求リクエストを生成する。
【０１０５】
ステップＳ１５１２において、アクセス管理リクエスト処理部７０１は、外部有償サービスシステム１０３から認可トークン要求リクエストを受信し、アクセス制御部７０２へ認可トークン要求リクエストを送信する。アクセス制御部７０２は、認可トークン要求リクエストに含まれるインボーカーＩＤ、パスワードを検証する。具体的には、認可トークン要求リクエストに含まれるインボーカーＩＤ、パスワードの組み合わせが、認証データ管理部７０３に格納されたユーザーテーブル８００に登録されているかを確認する。
【０１０６】
認可トークン要求リクエストに含まれるインボーカーＩＤ、パスワードの組み合わせがユーザーテーブル８００に登録されている場合、アクセス制御部７０２は、インボーカーをアクセス管理サービスシステム１０７の管理下にあるサービスを利用できると判断する。認可トークン要求リクエストに含まれるインボーカーＩＤ、パスワードの組み合わせがユーザーテーブル８００に登録されていない場合、アクセス制御部７０２は、インボーカーをアクセス管理サービスシステム１０７の管理下にあるサービスを利用できないと判断し、認証エラーを外部有償サービスシステム１０３に送信し、ステップＳ１５２８に進む。
【０１０７】
インボーカーがアクセス管理サービスシステム１０７の管理下にサービスを利用できると判断されたら、アクセス制御部７０２は、インボーカーが帳票サービスシステム１０５に送信する帳票生成要求を実行する権限を有しているかを確認する。具体的には、アクセス制御部７０２は、ステップＳ１５１２において認証したユーザーに対応するユーザーＩＤがユーザーＩＤカラム８０１に格納されているかを確認し、そのユーザーＩＤに紐付くロールＩＤをユーザー割り当てロールテーブル９２０を参照して取得する。
【０１０８】
具体的には、ステップＳ１５１２で認証したユーザーのユーザーＩＤが「インボーカー」であった場合、「ＳｅｒｖｉｃｅＲｏｌｅ＿Ｆｏｒｍ」「ＳｅｒｖｉｃｅＲｏｌｅ＿Ｐｒｉｎｔ」というロールＩＤを取得する。次に、アクセス制御部７０２は、スコープテーブル１１００を参照して、インボーカーのロールＩＤに対応するスコープＩＤ１１０１を取得する。例えば、インボーカー、即ち外部有償サービスシステム１０３のロールＩＤ「ＳｅｒｖｉｃｅＲｏｌｅ＿Ｆｏｒｍ」に対応するスコープＩＤは「Ｓｃｏｐｅ＿ＦｏｒｍＩｎｖｏｋｅｒ」、「ＳｅｒｖｉｃｅＲｏｌｅ＿Ｐｒｉｎｔ」に対応するスコープＩＤは「Ｓｃｏｐｅ＿ＰｒｉｎｔＩｎｖｏｋｅｒ」である。
【０１０９】
次に、アクセス制御部７０２は、認可トークン要求リクエストに含まれる認可コードに対応するスコープ情報を、認可コードテーブル１３００を参照して取得する。そして、アクセス制御部７０２は、取得した認可コードに対応するスコープ情報と、取得したインボーカーに対応するスコープ情報とを比較する。そして、一致していることを確認した場合、外部有償サービスシステム１０３は帳票生成印刷要求を実行する権限を有していると判断し、ステップＳ１５１３に進む。即ち、外部有償サービス１０３は、帳票サービスシステム１０５、および印刷サービスシステム１０６が提供するオンラインサービスを利用する権限を有していると判断されたと言うことである。
【０１１０】
スコープＩＤの値が一致なかった場合、アクセス制御部７０２は、外部有償サービスシ帳票生成印刷要求を実行する権限を有していないと判断し、スコープエラーを外部有償サービスシステム１０３に送信して、ステップＳ１５２８に進む。ステップＳ１５２８において、リクエスト処理部３０１は、アクセス管理サービスシステム１０７から認証エラー、あるいはスコープエラーを受信してサービス制御部３０２に渡す。サービス制御部３０２は、エラーを受け取ると、エラーに対応した認証エラー画面、またはスコープエラー画面（不図示）を生成し、クライアント１０２が備えるＷｅｂブラウザ（不図示）に送信する。
【０１１１】
このスコープエラー画面は、ユーザーのスコープエラー画面とは違い、どのオンラインサービスを利用する権限を有していないかを詳細に認識させる必要はない。望ましくは、外部有償サービスシステム１０３は連携先のサービスシステムと連携できないため処理を実行できない、のようにシンプルに表示する画面が良い。なぜなら、ユーザーの時とは異なり、外部有償サービスシステム１０３に連携先のオンラインサービスを利用させる権限を設定することは、ユーザーにはできないからである。ユーザーはあくまで外部有償サービスシステム１０３を利用する顧客であって、外部有償サービスシステム１０３を運営する管理者ではない。そのようなユーザーは、外部有償サービスシステム１０３がどのオンラインサービスを利用できないかを認識する必要はないであろう。ユーザーとしてみれば、外部有償サービスシステム１０３からでは、連携先のオンラインサービスを利用できないことさえ認識し、別の外部有償サービスシステムを利用する方法を考えるであろう。このように、同じスコープエラー画面であっても、その表示方法を異なるものにすることには意義がある。
【０１１２】
ステップＳ１５３０において、クライアント１０２は、外部有償サービスシステム１０３から認証エラー画面、あるいはスコープエラー画面を受信すると、Ｗｅｂブラウザにそれを表示し、ステップＳ１５０１で指示した帳票生成指示を中断する。ステップＳ１５１３、およびステップＳ１５１４においては、図１０のステップＳ１０１３およびステップＳ１０１４と同様のため説明を省略する。ステップＳ１５１５において、外部有償サービスシステム１０３は、帳票サービスシステム１０５に対して帳票生成印刷要求を送信する。このとき、外部有償サービスシステム１０３は、認可トークンテーブル４２０に格納されている認可トークンＩＤ、ステップＳ１００３においてクライアント１０２から受信した帳票生成に使用する帳票フォームデータ、および帳票に差し込むデータ、および印刷に使用するプリンター情報から帳票生成印刷要求を生成する。
【０１１３】
ステップＳ１５１６において、帳票リクエスト処理部５０１は、外部有償サービスシステム１０３から帳票生成印刷要求を受信する。帳票リクエスト処理部５０１は、受信した帳票生成要求から認可トークンを取りだし、その認可トークンを帳票制御部５０２に渡す。帳票制御部５０２は、アクセス管理サービスシステム１０７にトークンの検証リクエストを送信する。このとき、帳票制御部５０２は、帳票リクエスト処理部５０１から受信した認可トークンを基に認可トークンの検証リクエストを生成する。ステップＳ１５１７、Ｓ１５１８においては、図１０のステップＳ１０１７、Ｓ１０１８と同様のため説明を省略する。認可トークンが、適正な権限範囲を有するユーザーとインボーカーによって生成されたものであると判断された場合、アクセス制御部７０２はその結果を応答として帳票サービスシステム１０５に送信しステップＳ１５１９に進む。
【０１１４】
適正な権限範囲を有するユーザーとインボーカーによって生成されたものであると判断された場合、アクセス制御部７０２は、ユーザー、およびインボーカーが帳票生成要求を実行する権限を有していないと判断する。そして、アクセス制御部７０２は、トークンエラーを外部有償サービスシステム１０３に送信して、ステップＳ１５２９に進む。ステップＳ１５１９において、帳票リクエスト処理部５０１は、アクセス管理サービスシステム１０７から、トークン検証リクエストの応答を受信する。そして、帳票リクエスト処理部５０１は、受信した帳票生成印刷要求から帳票生成に使用する帳票フォームデータと帳票に差し込むデータを解析し、帳票制御部５０２に渡す。帳票制御部５０２は、帳票データ処理部５０３に受信した帳票フォームデータと帳票に差し込むデータを渡し、帳票生成処理を実行する。帳票制御部５０２は、帳票生成処理が完了すると、実行結果である帳票データをまず、帳票データ管理部５０４に保存する。
【０１１５】
ステップＳ１５２０において、帳票サービスシステム１０５は、印刷サービスシステム１０６に対し帳票印刷要求を送信する。このとき、帳票サービスシステム１０５は、認可トークンテーブル４２０に格納されている認可トークンＩＤ、ステップＳ１５１８において生成し帳票データ管理部５０４に格納されている帳票データ、ステップＳ１５１６で受信した帳票生成印刷要求に含まれる印刷に使用するプリンター情報を基に帳票印刷要求を生成する。
【０１１６】
ステップＳ１５２１において、印刷リクエスト処理部６０１は、帳票サービスシステム１０５から帳票印刷要求を受信する。印刷リクエスト処理部６０１は、受信した帳票印刷要求から認可トークンを取り出し、印刷制御部６０２に渡す。印刷制御部６０２は、アクセス管理サービスシステム１０７にトークンの検証リクエストを送信する。このとき、印刷制御部６０２は、印刷リクエスト処理部６０１から受信した認可トークンＩＤを基にトークンの検証リクエストを生成する。ステップＳ１５２２において、アクセス管理リクエスト処理部７０１は、印刷サービスシステム１０６からトークンの検証リクエストを受信する。アクセス管理リクエスト処理部７０１は、受信したトークン検証リクエストから認可トークンＩＤ、スコープＩＤを取り出し、アクセス制御部７０２に渡す。
【０１１７】
次に、アクセス制御部７０２は、認可データ管理部７０４が管理する認可トークンテーブル１４００を参照して、受信した認可トークンＩＤ、スコープＩＤに対応する認可トークンが格納されているかを確認する。まず、受信した認可トークンＩＤに対応する認可トークンが格納されていた場合には、ユーザーＩＤカラム１４０２、スコープＩＤカラム１４０４カラムに格納されている値を参照して、その認可トークンが帳票印刷要求を実行する権限を持ったユーザーによって生成されたものであるかどうかを確認する。
【０１１８】
具体的には、まず検証リクエストに含まれるスコープＩＤ値とスコープＩＤカラム１４０４の値を比較する。このとき検証リクエストに含まれるスコープＩＤ値がスコープＩＤカラム１４０４に格納されていれば良い。次に、ユーザーＩＤカラム１４０２に格納されているユーザーＩＤ値が、ユーザー割り当てロールテーブル９２０のユーザーＩＤカラム９２１に格納されているかを確認する。
【０１１９】
次に、ユーザーＩＤカラム１４０２に格納されているユーザーＩＤ値に対応するロールＩＤを、ユーザー割り当てロールテーブル９２０のロールＩＤカラム９２２から取得する。そして、スコープテーブル１１００からスコープＩＤを取得する。最後に、ロールＩＤカラム１１０２に対応するスコープＩＤカラム１１０１のスコープ情報と、認可トークンテーブル１４００のスコープＩＤカラム１４０４のスコープ情報とを比較する。一致していた場合にはその認可トークンがユーザーによって生成されたものであると判断し、ステップＳ１５２３に進む。認可トークンがユーザーによって生成されたものではないと判断した場合には、アクセス制御部７０２は、ユーザーが帳票印刷要求を実行する権限を有していないと判断する。そして、トークンエラーを外部有償サービスシステム１０３に送信して、ステップＳ１５２９に進む。
【０１２０】
ステップＳ１５２３において、アクセス制御部７０２はステップＳ１５２２に引き続き
認可トークンが帳票印刷要求を実行する権限をもったインボーカーによって生成されたものであるかどうかを確認する。確認方法は、上述したＳ１５２２の方法と同様であり、かつＳ１５１８のようにインボーカーの検証となる。認可トークンがインボーカーによって生成されたものではないと判断した場合には、アクセス制御部７０２は、インボーカーが帳票生成要求を実行する権限を有していないと判断する。そして、トークンエラーを外部有償サービスシステム１０３に送信して、ステップＳ１５２９に進む。
【０１２１】
ステップＳ１５２９において、リクエスト処理部３０１は、アクセス管理サービスシステム１０７からトークンエラーを受信してサービス制御部３０２に渡す。サービス制御部３０２は、トークンエラーを受け取るとスコープエラー画面（不図示）を生成し、クライアント１０２が備えるＷｅｂブラウザ（不図示）に送信する。ステップＳ１５３０において、クライアント１０２は、外部有償サービスシステム１０３からスコープエラー画面を受信すると、Ｗｅｂブラウザにそれを表示し、ステップＳ１５０１で指示した帳票生成指示を中断する。このスコープエラー画面は上述した通りの画面である。
【０１２２】
ステップＳ１５２４において、印刷リクエスト処理部６０１は、アクセス管理サービスシステム１０７からトークン検証リクエストの応答を受信する。そして、印刷リクエスト処理部６０１は、受信した帳票印刷要求から帳票データと印刷に使用するプリンター情報を取り出し、帳票制御部６０２に渡す。印刷制御部６０２は、印刷データ処理部６０３に対し、受信した印刷データを渡し、印刷データ生成処理を要求する。印刷制御部６０２は、印刷データ生成処理が完了すると、実行結果である印刷データを印刷データ管理部６０４に保存する。そして、外部有償サービスシステム１０３に、帳票生成印刷要求の応答として、生成した印刷データ、および印刷に使用するプリンター情報を送信する。
【０１２３】
ステップＳ１５２５において、外部有償サービスシステム１０３は、印刷サービスシステム１０６から印刷データを受信し、クライアント１０２に接続されたが備えるＷｅｂブラウザ（不図示）に送信する。ステップＳ１５２６において、クライアント１０２は、外部有償サービスシステム１０３から印刷データ、および印刷に使用するプリンター情報を受信すると、受信したプリンター情報に該当するプリンター１０９に印刷データを送信して、印刷処理を実行する。これにより、ステップＳ１５０１において、外部有償サービスシステム１０３に送信した帳票生成印刷指示を正常に終了する。なお、印刷データをクライアントを介してプリンターに送る処理について説明したが、これに限るものではない。例えば、外部有償サービスシステム１０３に保存した印刷データのＵＲＬのファイルパスをクライアントを介してプリンターに送っても良い。プリンターはＵＲＬを基に印刷データを取得する。
【０１２４】
以上、実施例２は、外部有償サービスシステム１０３が複数のオンラインサービスシステム、具体的には帳票サービスシステム１０５、および印刷サービスシステム１０６が提供するオンサインサービスと連携する処理について説明したものである。実施例１の効果を得られることはもちろんだが、実施例２の構成であれば次の様な効果も得られる。ユーザーが使用しているプリンターは外部有償サービスシステム１０３により管理されており、帳票サービスシステム１０５、および印刷サービスシステム１０６の管理外であったと仮定する。そのような場合であっても、実施例２によれば適正な権限範囲において複数のオンラインサービスが連携するので、高いセキュリティポリシーでプリンターは付加価値の高いオンライン印刷を行うことができる。
【０１２５】
なお、各実施例において、ユーザーが有する連携先のオンラインサービスの権限確認の後に、インボーカーが有する連携先のオンラインサービスの権限確認を行ったが、必ずしもそうである必要はない。例えば、ユーザーが外部有償サービス１０３のオンラインサービスを利用するよりも前に、外部有償サービス１０３は連携先のサービスシステムが提供するオンラインサービスを利用できるか否かの確認を行う形態も考えられる。その場合、外部有償サービス１０３はアクセス管理サービスシステム１０７にインボーカーのスコープ情報を送信し、権限確認の結果を得るであろう。権限確認の結果、外部有償サービス１０３は連携先のサービスシステムが提供するオンラインサービスを利用できるのであれば、ユーザーからのオンラインサービスの利用を実行すれば良い。しかしながら、外部有償サービス１０３がそのオンラインサービスを利用できないのであれば、ユーザーがオンラインサービスを利用する前に、その旨を告知する形態であっても良い。この形態であれば、ユーザーはオンラインサービスを利用するよりも前に、この外部有償サービス１０３は、連携をさせたいオンラインサービスと連携できないことを認識できるので、無駄な利用を省くことができる。
【図１】
0005932344.tif 000002
【図２】
0005932344.tif 000003
【図３】
0005932344.tif 000004
【図４】
0005932344.tif 000005
【図５】
0005932344.tif 000006
【図６】
0005932344.tif 000007
【図７】
0005932344.tif 000008
【図８】
0005932344.tif 000009
【図９】
0005932344.tif 000010
【図１０】
0005932344.tif 000011
【図１１】
0005932344.tif 000012
【図１２】
0005932344.tif 000013
【図１３】
0005932344.tif 000014
【図１４】
0005932344.tif 000015
【図１５】
0005932344.tif 000016