アクセス認可システム、アクセス制御サーバ、およびビジネスプロセス実行システム
【課題】ユーザから要求されたサービスの提供開始までのユーザの待ち時間を少なくすることができるアクセス認可システム１０を提供する。
【解決手段】本発明のアクセス認可システム１０は、クライアント側の通信装置であるＵＳ５００に現在提供されているサービスの次に当該ＵＳ５００に提供されるべきサービスを特定し、当該ＵＳ５００が当該次のサービスを要求する前に、当該ＵＳ５００のユーザに対する当該次のサービスの認可判定を予め実行する。
【解決手段】本発明のアクセス認可システム１０は、クライアント側の通信装置であるＵＳ５００に現在提供されているサービスの次に当該ＵＳ５００に提供されるべきサービスを特定し、当該ＵＳ５００が当該次のサービスを要求する前に、当該ＵＳ５００のユーザに対する当該次のサービスの認可判定を予め実行する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、クライアント側の通信装置からのサービスの要求に基づいて、当該通信装置を使用しているユーザに対して当該サービスの提供が許可されるか否かを判定する認可判定を行う技術に関する。
【背景技術】
【０００２】
現在のインターネット環境では、電子商取引サービスをはじめとする様々なサービスが利用可能となっている。このようなサービスの中には、名前や住所等の個人情報の入力を必要とするサービス、または、金銭の授受が発生するサービス等がある。これらのサービスでは、なりすましを防ぐための本人確認、または、プライバシの保護といったセキュリティを確保するための仕組みが必要となる。特に通信を安全に実現するには、ユーザ認証、ユーザ毎のサービスの利用可否の判定（認可）、ユーザ毎のアクセス制御、またはデータの暗号化等の対策が重要である。
【０００３】
しかし、認証やアクセス制御の対策が必要なサービスが増えれば増えるほど、ユーザおよびサービス提供者がセキュリティ対策に費やすコストが増大する。例えば、ネットショッピングサイトまたはオンラインバンキング等の会員制サービスは、通常、ユーザ認証を必要とする。ユーザ認証の必要な複数のサービスを利用する場合、ユーザは、サービスを利用する度にＩＤ、パスワード、および電子証明書等の認証情報を入力しなければならない。
【０００４】
しかし、このような操作はユーザにとって面倒であり、複数の認証情報を管理するユーザの負担も大きい。一方、サービスを提供する側も、独自に認証サーバまたは認証機能を備えたアプリケーションサーバを用意しなければならず、設置コストおよび運用コストが大きくなる。
【０００５】
そこで近年では、一度のユーザ認証で複数のサービスが利用可能となるＳＳＯ（Single Sign On）のニーズが高まっている。ＳＳＯは、複数のサービスを利用する場合であっても、ユーザが一度認証を受けるだけで、それぞれのサービス毎に認証を行うことなく複数のサービスを利用できる仕組みである。そして、ＳＳＯにおける認証は、通常、ユーザやサービス提供者とは異なる第三者機関が実施する。
【０００６】
例えば、非特許文献１には、ＳＳＯを実現するため技術であるＳＡＭＬ（Security Assertion Markup Language）の技術仕様が定義されている。一度ユーザが第三者機関であるＳＡＭＬオーソリティから認証を受けると、ＳＡＭＬオーソリティがサービス提供者へユーザ認証の結果である認証アサーションを伝達するため、ユーザはサービスを利用する度に認証情報を入力する手間を省くことができる。
【０００７】
また、非特許文献１のＳＡＭＬオーソリティは、ユーザ認証を代行するだけでなく、ユーザのサービスの利用権限をチェックし、サービス利用の認可判定も代行する。ＳＡＭＬオーソリティは、ユーザの所属、住所、および資格等の属性情報、ならびに、サービスの利用を認可するためのポリシ情報を管理する。そして、ＳＡＭＬオーソリティは、ユーザがサービスを利用する際、属性情報およびポリシ情報に基づき、サービスの利用の可否を判定し、判定結果として認可アサーションを発行する。サービス提供者は、ＳＡＭＬオーソリティから認可アサーションを受け取り、受け取った認可アサーションに従ってユーザに対するアクセス制御を行うため、各サービス提供者は、個々に認可判定用のサーバを用意する必要がなくなるというメリットがある。
【０００８】
また、従来のＷｅｂサービスでは、サービス提供者が予めすべてのサービス構成要素を作り込んでおくことが一般的であったが、近年では、その場の状況に応じてサービスの構成要素を組み合わせて一つのビジネスプロセスを実現するサービス連携の考え方が広まってきている。
【０００９】
サービス連携を実現するための既存技術としては、例えば個々のＷｅｂサービスをサービス構成要素として連携させる手法であるＢＰＥＬ（Business Process Execution Language for Web Services）が知られている（例えば、非特許文献２参照）。ＢＰＥＬは、複数のＷｅｂサービスの実行手順を、一連のビジネスプロセスの流れとして記述するための言語仕様である。ＢＰＥＬで記述されたビジネスプロセスを解釈・実行する機能はＢＰＥＬエンジンと呼ばれる。
【００１０】
【非特許文献１】OASIS Standard, ”Security Assertion Markup Language (SAML) v2.0,”OASIS Security Services TC (2005), http://docs.oasis-open.org/security/saml/v2.0/saml-2.0-os.zip
【非特許文献２】OASIS Standard, ”Web Services Business Process Execution Language Version 2.0”，OASIS Web Services Business Process Execution Language (WSBPEL) TC（2007），http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.pdf
【発明の開示】
【発明が解決しようとする課題】
【００１１】
しかし、上記非特許文献１のＳＡＭＬオーソリティは、ユーザがサービスへアクセスする度に認可判定を行うため、ユーザがサービスを要求した場合、その後の認可判定が終了しなければユーザはサービスの提供を受けられない。つまり、ユーザは、認可判定が終了するまでサービスの提供開始を待たなければならない。個々の認可判定に関する処理負荷はそれほど高くないため、サービスの提供を要求するユーザの数が少ない場合には、認可判定にかかる時間は少なく、サービスの提供開始までのユーザの待ち時間は少ない場合が多い。
【００１２】
しかし、非特許文献１では、認可判定をＳＡＭＬオーソリティが一括して行っているため、多くのユーザが短期間にサービスの提供を要求した場合には、ＳＡＭＬオーソリティにかかる処理負荷が高くなり、個々の認可判定にかかる時間が長くなる場合がある。認可判定にかかる時間が長くなると、個々のサービスの提供開始までのユーザの待ち時間が長くなり、ユーザの利便性が損なわれる。
【００１３】
また、非特許文献２に記載されているＢＰＥＬにおいても、一連のビジネスプロセスの中で、それぞれのサービスが呼び出されてから当該サービスの認可判定を行うとすれば、それぞれのサービスの提供開始までのユーザの待ち時間が長くなる場合がある。
【００１４】
本発明は上記事情を鑑みてなされたものであり、本発明の目的は、ユーザから要求されたサービスの提供開始までのユーザの待ち時間を少なくすることにある。
【課題を解決するための手段】
【００１５】
上記課題を解決するために、本発明のアクセス認可システムは、クライアント側の通信装置に現在提供されているサービスに引き続いて当該通信装置に提供されるべきサービスを特定し、当該通信装置が当該次のサービスを要求する前に、当該通信装置のユーザに対する当該次のサービスの認可判定を予め実行する。
【００１６】
例えば、本発明の第１の態様は、クライアント側の通信装置からのサービスの要求に基づいて、当該通信装置を使用しているユーザに対して当該サービスの提供が許可されるか否かを判定する認可判定を行うアクセス認可システムであって、
ポリシ管理サーバと、
認可サーバと、
アクセス制御サーバと
を備え、
前記ポリシ管理サーバは、
クライアント側の通信装置のユーザを識別するユーザＩＤ毎に、当該ユーザのユーザ属性情報を格納するユーザ属性情報格納手段と、
サービスを識別するサービスＩＤ毎に、当該サービスの提供が許可されるユーザの条件を示すサービスポリシ情報を格納するサービスポリシ情報格納手段と、
前記アクセス制御サーバからユーザＩＤおよびサービスＩＤを含む登録情報取得要求を受信した場合に、当該ユーザＩＤに対応するユーザ属性情報を前記ユーザ属性情報格納手段から抽出すると共に、当該サービスＩＤに対応するサービスポリシ情報を前記サービスポリシ情報格納手段から抽出し、抽出したユーザ属性情報およびサービスポリシ情報を含む登録情報取得応答を前記アクセス制御サーバへ送信する情報管理手段と
を有し、
前記認可サーバは、
前記アクセス制御サーバからユーザ属性情報およびサービスポリシ情報を含む認可判定要求を受信した場合に、当該ユーザ属性情報が、当該サービスポリシ情報を満たすか否かを判定し、認可判定結果、当該認可判定結果の対象となるユーザのユーザＩＤ、および当該認可判定結果の対象となるサービスのサービスＩＤを含む認可判定応答を、前記アクセス制御サーバへ送信する認可判定手段を有し、
前記アクセス制御サーバは、
サービスＩＤ毎に、当該サービスＩＤに対応するサービスの次に提供されるべきサービスのサービスＩＤを格納する次サービスＩＤ格納手段と、
クライアント側の通信装置のユーザがサービスを利用可能か否かを示す認可情報の取得要求であって、当該ユーザのユーザＩＤおよび当該サービスのサービスＩＤを含む認可情報取得要求を受信した場合に、当該ユーザＩＤおよび当該サービスＩＤを含む登録情報取得要求を前記ポリシ管理サーバへ送信し、当該ユーザＩＤに対応するユーザ属性情報および当該サービスＩＤに対応するサービスポリシ情報を含む登録情報取得応答を前記ポリシ管理サーバから受信した場合に、当該ユーザ属性情報およびサービスポリシ情報を含む認可判定要求を前記認可サーバへ送信し、当該認可サーバから認可判定応答を受信した場合に、当該認可判定応答に含まれる認可判定結果、ユーザＩＤ、およびサービスＩＤを含む認可情報取得応答を出力する認可判定要求手段と、
前記認可判定要求手段が前記認可情報取得応答を出力した後に、当該認可情報取得応答に含まれる認可判定結果の対象であるサービスのサービスＩＤに基づいて前記次サービスＩＤ格納手段を参照して、当該サービスＩＤに対応するサービスの次に提供されるべきサービスのサービスＩＤを抽出し、抽出したサービスＩＤを、当該認可判定結果の対象であるユーザのユーザＩＤと共に前記認可判定要求手段へ送る次サービス特定手段と
を有し、
前記認可判定要求手段は、
前記認可情報取得応答を出力してから、当該認可情報取得応答に含まれるユーザＩＤと同一のユーザＩＤを含む認可情報取得要求を受信するまでの間に、前記次サービス特定手段から受け取ったユーザＩＤおよびサービスＩＤに対応するユーザ属性情報およびサービスポリシ情報を前記ポリシ管理サーバから取得し、当該ユーザ属性情報およびサービスポリシ情報を含む認可判定要求を前記認可サーバへ送信することにより、前記認可サーバに、当該ユーザＩＤに対応するユーザおよび当該サービスＩＤに対応するサービスの組み合わせについて認可判定を予め実行させることを特徴とするアクセス認可システムを提供する。
【００１７】
例えば、本発明の第２の態様は、クライアント側の通信装置のユーザを識別するユーザＩＤ毎に、当該ユーザのユーザ属性情報を格納するユーザ属性情報格納手段と、
サービスを識別するサービスＩＤ毎に、当該サービスの提供が許可されるユーザの条件を示すサービスポリシ情報を格納するサービスポリシ情報格納手段と、
ユーザＩＤおよびサービスＩＤを含む登録情報取得要求を受信した場合に、当該ユーザＩＤに対応するユーザ属性情報を前記ユーザ属性情報格納手段から抽出すると共に、当該サービスＩＤに対応するサービスポリシ情報を前記サービスポリシ情報格納手段から抽出し、抽出したユーザ属性情報およびサービスポリシ情報を含む登録情報取得応答を返す情報管理手段と
を有するポリシ管理サーバと、
ユーザ属性情報およびサービスポリシ情報を含む認可判定要求を受信した場合に、当該ユーザ属性情報が、当該サービスポリシ情報を満たすか否かを判定する認可判定を行い、認可判定結果、当該認可判定結果の対象となるユーザのユーザＩＤ、および当該認可判定結果の対象となるサービスのサービスＩＤを含む認可判定応答を返す認可判定手段
を有する認可サーバと
を備え、
クライアント側の通信装置からのサービスの要求に基づいて、当該通信装置を使用しているユーザに対する当該サービスの認可判定を行うアクセス認可システムに用いられるアクセス制御サーバであって、
サービスＩＤ毎に、当該サービスＩＤに対応するサービスの次に提供されるべきサービスのサービスＩＤを格納する次サービスＩＤ格納手段と、
クライアント側の通信装置のユーザがサービスを利用可能か否かを示す認可情報の取得要求であって、当該ユーザのユーザＩＤおよび当該サービスのサービスＩＤを含む認可情報取得要求を受信した場合に、当該ユーザＩＤおよび当該サービスＩＤを含む登録情報取得要求を前記ポリシ管理サーバへ送信し、当該ユーザＩＤに対応するユーザ属性情報および当該サービスＩＤに対応するサービスポリシ情報を含む登録情報取得応答を前記ポリシ管理サーバから受信した場合に、当該ユーザ属性情報およびサービスポリシ情報を含む認可判定要求を前記認可サーバへ送信し、当該認可サーバから認可判定応答を受信した場合に、当該認可判定応答に含まれる認可判定結果、ユーザＩＤ、およびサービスＩＤを含む認可情報取得応答を出力する認可判定要求手段と、
前記認可判定要求手段が前記認可情報取得応答を出力した後に、当該認可情報取得応答に含まれる認可判定結果の対象であるサービスのサービスＩＤに基づいて前記次サービスＩＤ格納手段を参照して、当該サービスＩＤに対応するサービスの次に提供されるべきサービスのサービスＩＤを抽出し、抽出したサービスＩＤを、当該認可判定結果の対象であるユーザのユーザＩＤと共に前記認可判定要求手段へ送る次サービス特定手段と
を有し、
前記認可判定要求手段は、
前記認可情報取得応答を出力してから、当該認可情報取得応答に含まれるユーザＩＤと同一のユーザＩＤを含む認可情報取得要求を受信するまでの間に、前記次サービス特定手段から受け取ったユーザＩＤおよびサービスＩＤに対応するユーザ属性情報およびサービスポリシ情報を前記ポリシ管理サーバから取得し、当該ユーザ属性情報およびサービスポリシ情報を含む認可判定要求を前記認可サーバへ送信することにより、前記認可サーバに、当該ユーザＩＤに対応するユーザおよび当該サービスＩＤに対応するサービスの組み合わせについて認可判定を予め実行させることを特徴とするアクセス認可サーバを提供する。
【００１８】
例えば、本発明の第３の態様は、クライアント側の通信装置から要求された、複数のサービスから構成されるビジネスプロセスについて、当該通信装置のユーザに対して当該ビジネスプロセスに含まれる個々のサービスの提供が許可されるか否かを判定する認可判定を行うビジネスプロセス実行システムであって、
属性管理サーバと、
ポリシ管理サーバと、
認可サーバと、
サービス実行サーバと
を備え、
前記属性管理サーバは、
クライアント側の通信装置のユーザを識別するユーザＩＤ毎に、当該ユーザのユーザ属性情報を格納するユーザ属性情報格納手段と、
前記認可サーバからユーザＩＤを含む属性取得要求を受信した場合に、当該ユーザＩＤに対応するユーザ属性情報を前記ユーザ属性情報格納手段から抽出し、抽出したユーザ属性情報を含む属性取得応答を前記認可サーバへ送信する属性情報管理手段と
を有し、
前記ポリシ管理サーバは、
サービスを識別するサービスＩＤ毎に、当該サービスの提供が許可されるユーザの条件を示すサービスポリシ情報を格納するサービスポリシ情報格納手段と、
前記認可サーバからサービスＩＤを含むポリシ取得要求を受信した場合に、当該サービスＩＤに対応するサービスポリシ情報を前記サービスポリシ情報格納手段から抽出し、抽出したサービスポリシ情報を含むポリシ取得応答を前記認可サーバへ送信するポリシ情報管理手段と
を有し、
前記認可サーバは、
前記サービス実行サーバからユーザＩＤおよび１つ以上のサービスＩＤを含む認可判定要求を受信した場合に、当該ユーザＩＤを含む属性取得要求を前記属性管理サーバへ送信して、当該ユーザＩＤに対応するユーザ属性情報を取得すると共に、当該サービスＩＤを含むポリシ取得要求を前記ポリシ管理サーバへ送信して、当該サービスＩＤに対応するサービスポリシ情報を取得し、取得したユーザ属性情報が、取得したサービスポリシ情報を満たすか否かを判定し、サービスＩＤ毎の認可判定結果を含む認可判定応答を、前記サービス実行サーバへ送信する認可判定手段を有し、
前記サービス実行サーバは、
ビジネスプロセスに含まれる複数のサービスの提供順番を規定するサービスシナリオを、それぞれのサービスシナリオを識別するシナリオＩＤに対応付けて格納するシナリオ格納手段と、
クライアント側の通信装置からユーザＩＤおよびシナリオＩＤを含むサービス要求を受信した場合に、当該シナリオＩＤに対応するサービスシナリオを前記シナリオ格納手段から取得し、当該ユーザＩＤおよび取得したサービスシナリオに含まれているそれぞれのサービスのサービスＩＤを含む認可判定要求を前記認可サーバへ送信することにより、当該サービスシナリオに含まれているそれぞれのサービスの認可判定結果を取得し、当該サービスシナリオに含まれている一連のサービスの全てが許可されている場合に、当該サービスシナリオにおいて最初に提供されるべきサービスを実行するサービス提供サーバに、当該ユーザＩＤのユーザに対して当該サービスの提供を要求するシナリオ実行手段と
を有することを特徴とするビジネスプロセス実行システムを提供する。
【発明の効果】
【００１９】
本発明によれば、サービスの提供開始までのユーザの待ち時間を少なくすることができる。
【発明を実施するための最良の形態】
【００２０】
以下、本発明の実施例について、図面を用いて詳細に説明する。
【００２１】
なお、以下の実施例１および２では、ＳＩＰ(Session Initiation Protocol)を用いたアクセス認可システム１０を一例に説明する。ＳＩＰはＩＥＴＦにおいてＲＦＣ３２６１で定義された、通信セッションの管理や制御を行う通信プロトコルである。また、各実施例に登場するシステム構成要素のうち、同一の要素が複数登場する場合には、ＳＰ（サービス提供サーバ）−α、ＳＰ−βのように表記する。また、例えばＳＰ−αとＳＰ−βをサービス提供サーバとして説明する場合のように複数の要素をまとめて説明する場合は、単にＳＰのように表現する。
【００２２】
また、以下の各実施例において、ユーザとは、ユーザ端末（ＵＳ）５００を操作する人間を指す。サービスとは、ＳＰ６００上で動作する、ユーザがＵＳ５００を介して利用するアプリケーションの特徴を示したものである。属性情報とは、ユーザやサービスの特性を示した情報で、例えばユーザの性別、名前、もしくは年齢、または、サービスの種別（動画配信または商取引等）、料金、もしくは品質等を計算機が解釈可能な形式で記述した情報である。
【００２３】
サービスポリシ情報とは、サービスの利用基準を定めた情報であり、例えば、２０歳以上のユーザのみ利用可能、特定の地域に在住のユーザのみ利用可能、または、一定額以上の費用を支払ったユーザのみ利用可能等のルールを計算機が解釈可能な形式で記述した情報である。認可情報とは、ＳＰ６００がユーザに対するアクセス制御を実施するための情報であり、認可サーバ（ＡｕＳ）４００の判定結果を基にアクセス制御サーバ（ＡＣＳ）１００が作成する。制御通信とは、例えばＳＩＰを用いた通信であり、ＵＳ５００と通信管理サーバ（ＣＭＳ）３００との間の通信、およびＳＰ６００とＣＭＳ３００との間の通信を指す。データ通信とは、ＵＳ５００とＳＰ６００とがＣＭＳ３００を介さずに行う通信を指す。
【００２４】
＜実施例１＞
まず、本発明の第１実施例について説明する。
【００２５】
図１は、第１実施例におけるアクセス認可システム１０の構成を例示するシステム構成図である。アクセス認可システム１０は、アクセス制御サーバ（ＡＣＳ）１００、ポリシ管理サーバ（ＰＭＳ）２００、通信管理サーバ（ＣＭＳ）３００、認可サーバ（ＡｕＳ）４００、ユーザ端末（ＵＳ）５００、および複数のサービス提供サーバ（ＳＰ）６００を備える。ＡＣＳ１００、ＰＭＳ２００、ＣＭＳ３００、ＡｕＳ４００、ＵＳ５００、およびＳＰ６００は、ネットワーク１１を介して互いに通信する。
【００２６】
図１に示すアクセス認可システム１０は、ユーザがＵＳ５００を介してサービスを利用する際に、第三者機関であるＡＣＳ１００が、ＰＭＳ２００およびＡｕＳ４００と連携して当該ユーザに対する当該サービスの認可判定を行い、その結果に基づいてＣＭＳ３００がアクセス制御を行う。
【００２７】
次に、本実施例におけるアクセス認可システム１０の各構成要素が備える機能について述べる。
【００２８】
まずＵＳ５００について説明する。ＵＳ５００は、通信部５０１、通信アプリケーション５０２、ＳＩＰクライアント５０３、通信管理テーブル格納部５０４、および通信制御エンジン５０５を備える。なお、本実施例では、ＳＰ６００からのサービスを受ける通信装置をＵＳ５００として説明するが、ＵＳ５００は端末装置である必要はなく、プロキシサーバ等のサーバ装置であってもよい。
【００２９】
通信部５０１は、通信アプリケーション５０２またはＳＩＰクライアント５０３からの指示に応じて、ネットワーク１１を介して他の装置と通信を行う。通信管理テーブル格納部５０４には、例えば図２に示すような通信管理テーブル５０４０が格納されている。通信管理テーブル５０４０には、現在提供を受けているサービスを特定するサービスＩＤ５０４１毎に、ＳＩＰクライアント５０３によって作成された通信ＩＤ５０４２が格納される。
【００３０】
本実施例においてサービスＩＤ５０４１には、例えば当該サービスＩＤ５０４１で特定されるサービスを提供するＳＰ６００のＵＲＬ（Uniform Resource Locator）が格納される。また、本実施例において通信ＩＤ５０４２としては、例えばＳＩＰ通信におけるCall_IDが使用される。
【００３１】
ＳＩＰクライアント５０３は、制御通信を実行する機能ブロックである。ＳＩＰクライアント５０３は、ＵＳ５００に接続されている入力装置を介して入力されたユーザからの指示に応じて、通信部５０１を介してＣＭＳ３００との間で認証処理を実行する。また、ＳＩＰクライアント５０３は、ユーザからの指示に応じて、通信部５０１を介して、ＳＩＰに規定されている位置登録の処理をＣＭＳ３００との間で実行する。
【００３２】
位置登録の処理とは、例えば自ＵＳ５００のSIP-URI（Uniform Resource Identifier）と位置情報の組をＳＩＰサーバに登録する処理を指す。位置情報としては、例えばＩＰアドレスであってもよく、ＩＰアドレスとポート番号の組等であってもよい。本実施例において、認証処理および位置登録処理を実行することをログインと呼ぶ。本実施例において、ＵＳ５００およびそれぞれのＳＰ６００は、ＣＭＳ３００との間で予めログインの処理をそれぞれ実行しているものとする。
【００３３】
ログインの処理後、ＳＩＰクライアント５０３は、通信制御エンジン５０５からサービスＩＤを受け取った場合に、当該サービスＩＤを記載した通信開始要求を作成し、作成した通信開始要求を、通信部５０１を介してＣＭＳ３００へ送信する。本実施例において通信開始要求は、例えば図４（ａ）に示すように、ＳＩＰにおいて定義されているＩＮＶＩＴＥリクエストと同様のメッセージフォーマットで作成される。通信開始要求のＢＯＤＹ部３０には、通信制御エンジン５０５から通知されたサービスＩＤが記載される。
【００３４】
なお、サービスが提供されているＳＰ６００のＵＲＬはユーザから指示されるが、宛先のＳＰ６００のSIP-URIは不明であるため、ＳＩＰクライアント５０３は、宛先のSIP-URIを「anonymous」として通信開始要求を作成する。
【００３５】
また、ＳＩＰクライアント５０３は、通信部５０１を介してＣＭＳ３００から通信開始応答を受信した場合に、当該通信開始応答に記載されているCall_ID、および、当該通信開始応答に対応する通信開始要求に記載したサービスＩＤを、通信路が確立している旨を示す情報と共に通信制御エンジン５０５へ送る。本実施例において通信開始応答は、例えば図４（ｂ）に示すように、ＳＩＰにおいて定義されている２００ＯＫレスポンスと同様のメッセージフォーマットでＣＭＳ３００によって作成される。
【００３６】
また、ＳＩＰクライアント５０３は、ＢＹＥリクエストをＣＭＳ３００から受信することにより通信が終了した場合に、通信の終了を示す情報と共に、当該ＢＹＥリクエストに含まれているCall_IDを通信制御エンジン５０５へ送る。
【００３７】
また、ＳＩＰクライアント５０３は、ユーザからユーザ属性情報の変更を指示された場合に、登録情報更新要求を作成し、作成した登録情報更新要求を通信部５０１を介してＣＭＳ３００へ送信する。そして、ＳＩＰクライアント５０３は、ＣＭＳ３００から登録情報更新応答を受信することにより、ユーザ属性情報が正常に変更されたことを認識する。
【００３８】
本実施例において登録情報更新要求は、例えば図６（ａ）に示すように、ＳＩＰにおいて定義されているＵＰＤＡＴＥリクエストと同様のメッセージフォーマットで作成される。登録情報更新要求のＢＯＤＹ部３１には、ユーザから指示された、変更すべきユーザ属性情報が記載される。本実施例において登録情報更新応答は、例えば図６（ｂ）に示すように、ＳＩＰにおいて定義されている２００ＯＫレスポンスと同様のメッセージフォーマットでＣＭＳ３００によって作成される。
【００３９】
通信制御エンジン５０５は、通信アプリケーション５０２からサービスＩＤを受け取った場合に、通信管理テーブル格納部５０４を参照して、当該サービスＩＤが通信管理テーブル５０４０に登録されているか否かを判定する。当該サービスＩＤが通信管理テーブル５０４０に登録されている場合、通信制御エンジン５０５は、通信路が確立している旨を示す情報を通信アプリケーション５０２に返す。
【００４０】
当該サービスＩＤが通信管理テーブル５０４０に登録されていない場合、通信制御エンジン５０５は、当該サービスＩＤをＳＩＰクライアント５０３へ送ることにより、ＳＩＰクライアント５０３に、当該サービスＩＤに示されたＵＲＬのＳＰ６００との間に通信路を確立させる。
【００４１】
そして、通信制御エンジン５０５は、通信路が確立している旨を示す情報と共に、Call_IDおよびサービスＩＤをＳＩＰクライアント５０３から受け取った場合に、受け取ったCall_IDを通信ＩＤとして、通信ＩＤおよびサービスＩＤの組を通信管理テーブル５０４０に登録する。そして、通信制御エンジン５０５は、通信路が確立している旨を示す情報を通信アプリケーション５０２に通知する。
【００４２】
また、通信の終了を示す情報と共に、Call_IDをＳＩＰクライアント５０３から受け取った場合、通信制御エンジン５０５は、Call_IDに対応する通信ＩＤおよび当該通信ＩＤに対応付けられているサービスＩＤを通信管理テーブル５０４０から削除する。
【００４３】
通信アプリケーション５０２は、データ通信を実行する機能ブロックである。通信アプリケーション５０２は、ユーザからサービスの要求を受け付けた場合に、当該サービスに対応するサービスＩＤを通信制御エンジン５０５へ送る。そして、通信アプリケーション５０２は、通信制御エンジン５０５から、当該サービスＩＤに対応するサービスの提供を受けるための通信路が確立している旨を通知された場合に、当該サービスＩＤに示されるＵＲＬのＳＰ６００へアクセスして対応するサービスの提供を受ける。
【００４４】
次に、ＳＰ６００について説明する。ＳＰ６００は、通信部６０１、サービスアプリケーション６０２、ＳＩＰクライアント６０３、通信管理テーブル格納部６０４、および通信制御エンジン６０５を備える。通信部６０１は、サービスアプリケーション６０２またはＳＩＰクライアント６０３からの指示に応じて、ネットワーク１１を介して他の装置と通信を行う。
【００４５】
通信管理テーブル格納部６０４には、例えば図３に示すような通信管理テーブル６０４０が格納されている。通信管理テーブル６０４０には、ユーザを特定するユーザＩＤ６０４１毎に、当該ユーザに対して提供が許可されたサービスのサービスＩＤ６０４２、当該サービスを提供する際に使用する通信路を特定する通信ＩＤ６０４３、および当該ユーザに当該サービスの提供が許可されたことを示す認可情報６０４４が格納される。
【００４６】
ＳＩＰクライアント６０３は、制御通信を実行する機能ブロックである。ＳＩＰクライアント６０３は、ＳＰ６００に接続された入力装置を介して入力された管理者からの指示に応じて、通信部６０１を介してＣＭＳ３００との間で認証処理と位置登録処理とを実行することにより、ログインを行う。
【００４７】
その後、ＳＩＰクライアント６０３は、ＣＭＳ３００から、ＢＯＤＹ部３０にさらに図５（ｅ）に示す形式の認可情報を含む通信開始要求（図４（ａ）参照）を受信した場合に、当該通信開始要求に含まれる送信元のユーザＩＤ、サービスＩＤ、通信ＩＤ、および認可情報を通信制御エンジン６０５に送る。そして、ＳＩＰクライアント６０３は、図４（ｂ）に示した通信開始応答を作成し、作成した通信開始応答を通信部６０１を介してＣＭＳ３００へ送信する。
【００４８】
また、ＳＩＰクライアント６０３は、ＢＹＥリクエストを受信することにより通信が終了した場合に、通信の終了を示す情報と共に、当該ＢＹＥリクエストに含まれているCall_IDを通信制御エンジン６０５へ送る。
【００４９】
また、ＳＩＰクライアント６０３は、通信部６０１を介して、ＡＣＳ１００から認可情報削除要求を受信した場合に、当該認可情報削除要求に含まれているユーザＩＤに対応するレコードを通信管理テーブル６０４０から全て削除する。そして、ＳＩＰクライアント６０３は、削除結果を含む認可情報削除応答を作成し、作成した認可情報削除応答を通信部６０１を介してＡＣＳ１００へ送信する。
【００５０】
本実施例において認可情報削除要求は、例えば図６（ｅ）に示すように、delAuthorizationAssertionRequestタグを用いたＸＭＬメッセージとして作成される。図６（ｅ）は、認可情報削除要求のうち、本実施例の説明に必要な部分のみを示している。subjectタグにはユーザＩＤが記載される。resourceタグにはサービスＩＤが記載される。seqタグには、認可情報削除要求と認可情報削除応答とを対応付けるためのリクエスト番号が記載される。
【００５１】
また、本実施例において認可情報削除応答は、例えば図６（ｆ）に示すように、delAuthorizationAssertionResponseタグを用いたＸＭＬメッセージとして作成される。図６（ｆ）は、認可情報削除応答のうち、本実施例の説明に必要な部分のみを示している。resultタグには認可情報の削除結果が記載される。seqタグには、認可情報削除要求と認可情報削除応答とを対応付けるためのリクエスト番号が記載される。
【００５２】
通信制御エンジン６０５は、ＳＩＰクライアント６０３から認可情報を受け取った場合に、受け取った認可情報がサービス提供を許可する旨を示すならば、当該認可情報、ならびに、当該認可情報と共に受け取ったユーザＩＤ、サービスＩＤ、および通信ＩＤを６０４０に登録する。また、通信の終了を示す情報と共に、Call_IDをＳＩＰクライアント６０３から受け取った場合、通信制御エンジン６０５は、Call_IDに対応する通信ＩＤ、ならびに、当該通信ＩＤに対応付けられているユーザＩＤ、サービスＩＤ、および認可情報を通信管理テーブル６０４０から削除する。
【００５３】
また、通信制御エンジン６０５は、サービスアプリケーション６０２からユーザＩＤおよびサービスＩＤの組を受け取った場合に、当該ユーザＩＤおよびサービスＩＤの組が通信管理テーブル６０４０内に存在するか否かを判定する。当該ユーザＩＤおよびサービスＩＤの組が通信管理テーブル６０４０内に存在する場合、通信制御エンジン６０５は、当該ユーザＩＤに対応するユーザに対して、当該サービスＩＤに対応するサービスの提供が許可されている旨をサービスアプリケーション６０２に返す。当該ユーザＩＤおよびサービスＩＤの組が通信管理テーブル６０４０内に存在しない場合、通信制御エンジン６０５は、当該ユーザＩＤに対応するユーザに対して、当該サービスＩＤに対応するサービスの提供が許可されていない旨をサービスアプリケーション６０２に返す。
【００５４】
サービスアプリケーション６０２は、データ通信を実行する機能ブロックである。サービスアプリケーション６０２は、通信部６０１を介して、サービスＩＤおよび当該サービスＩＤに対応するサービスの提供先のユーザのユーザＩＤを含むサービス提供要求を受信した場合に、当該ユーザＩＤおよびサービスＩＤを通信制御エンジン６０５に送る。そして、当該ユーザＩＤに対応するユーザに対して、当該サービスＩＤに対応するサービスの提供が許可されていない旨が通信制御エンジン６０５から返された場合、サービスアプリケーション６０２は、その旨を通信部６０１を介して当該ユーザＩＤに対応するユーザが使用しているＵＳ５００へ返信する。
【００５５】
一方、当該ユーザＩＤに対応するユーザに対して、当該サービスＩＤに対応するサービスの提供が許可されている旨が通信制御エンジン６０５から返された場合、サービスアプリケーション６０２は、当該ユーザＩＤに対応するユーザに対して、当該サービスＩＤに対応するサービスの提供を開始する。
【００５６】
次に、ＣＭＳ３００について説明する。ＣＭＳ３００は、位置情報格納部３０１、ログイン処理部３０２、アクセス履歴格納部３０３、ＳＩＰメッセージ制御部３０４、および通信部３０５を備える。通信部３０５は、ログイン処理部３０２またはＳＩＰメッセージ制御部３０４からの指示に応じて、ネットワーク１１を介して他の装置と通信を行う。
【００５７】
ログイン処理部３０２は、ＵＳ５００およびＳＰ６００のそれぞれとの間で位置登録処理および認証処理を含むログインに関する処理を実行し、位置登録において受信したSIP-URIと位置情報の組を位置情報格納部３０１に登録する。なお、本実施例では、ＣＭＳ３００は位置情報格納部３０１およびログイン処理部３０２を備えるが、他の例として、位置情報格納部３０１およびログイン処理部３０２は、ＣＭＳ３００の外部の装置により実現されていてもよい。
【００５８】
アクセス履歴格納部３０３には、例えば図７に示すように、ＳＩＰ通信におけるCall_IDを示す通信ＩＤ３０３１、ＵＳ５００のユーザのSIP-URIを示すSubject_ID３０３２、サービスを提供するＳＰ６００のSIP-URIを示すTarget_ID３０３３、サービスＩＤを示すService_ID３０３４、ＳＩＰによる通信の開始日時を示すStart３０３５、およびＳＩＰによる通信の終了日時を示すEnd３０３６が、それぞれのレコードを識別する番号３０３０に対応付けて格納されている。
【００５９】
ＳＩＰメッセージ制御部３０４は、通信部３０５を介して、ＵＳ５００から図４（ａ）に示した通信開始要求を受信した場合に、当該通信開始要求のＢＯＤＹ部３０に記載されているサービスＩＤで特定されるＵＲＬから、外部のＤＮＳサーバ等を参照して当該ＵＲＬに対応するＳＰ６００の位置情報（ＩＰアドレス）を特定し、特定した位置情報に対応するSIP-URIを位置情報格納部３０１から抽出する。
【００６０】
そして、ＳＩＰメッセージ制御部３０４は、当該通信開始要求に含まれているCall_IDを通信ＩＤとし、当該通信開始要求の送信元のSIP-URIをSubject_IDとし、当該通信開始要求に含まれているサービスＩＤに基づいて特定したSIP-URIをTarget_IDとし、当該通信開始要求に含まれているサービスＩＤをService_IDとして、新たに割り振った番号に対応付けてアクセス履歴格納部３０３に格納する。
【００６１】
そして、ＳＩＰメッセージ制御部３０４は認可情報取得要求を作成し、作成した認可情報取得要求を通信部３０５を介してＡＣＳ１００へ送信する。本実施例において認可情報取得要求は、図４（ｃ）に示すように、getAuthAssertionRequestタグを用いたＸＭＬメッセージとして作成される。図４（ｃ）は、認可情報取得要求のうち、本実施例の説明に必要な部分のみを示している。subjectタグにはＵＳ５００のSIP-URIが記載される。resourceタグにはサービスＩＤが記載される。seqタグには、認可情報取得要求とその応答である認可情報取得応答とを対応付けるためのリクエスト番号が記載される。
【００６２】
また、ＳＩＰメッセージ制御部３０４は、通信部３０５を介して、ＡＣＳ１００から認可情報取得応答を受信した場合に、ＢＯＤＹ部３０にさらに図５（ｅ）に示す形式の認可情報を含む通信開始要求（図４（ａ）参照）を作成し、作成した通信開始要求を、通信部３０５を介してＳＰ６００へ送信する。本実施例において認可情報取得応答は、図４（ｄ）に示すように、getAuthAssertionResponseタグを用いたＸＭＬメッセージとして作成される。図４（ｄ）は、認可情報取得応答のうち、本実施例の説明に必要な部分のみを示している。assertionタグには認可情報（図５（ｅ）参照）が記載される。seqタグには、認可情報取得要求と認可情報取得応答とを対応付けるためのリクエスト番号が記載される。
【００６３】
また、ＳＩＰメッセージ制御部３０４は、通信部３０５を介して、ＳＰ６００から通信開始応答を受信した場合に、アクセス履歴格納部３０３を参照して、当該通信開始応答に含まれているCall_IDと同一の通信ＩＤ、当該通信開始応答に含まれている送信元のSIP-URIと同一のSubject_ID、および、当該通信開始応答に含まれている宛先のSIP-URIと同一のTarget_IDに対応付けられているレコードを特定し、特定したレコードのStartの欄に、当該通信開始応答を受信した日時を登録する。そして、ＳＩＰメッセージ制御部３０４は、当該通信開始応答内の一部の情報（例えばviaヘッダの内容）を書き換えて宛先のＵＳ５００へ送信する。
【００６４】
また、ＳＩＰメッセージ制御部３０４は、通信部３０５を介して、ＢＹＥリクエストに対する２００ＯＫレスポンスを受信した場合に、当該２００ＯＫレスポンスに含まれているCall_IDと同一の通信ＩＤ、当該２００ＯＫレスポンスに含まれている送信元のSIP-URIと同一のSubject_ID、および、当該２００ＯＫレスポンスに含まれている宛先のSIP-URIと同一のTarget_IDに対応付けられているレコードを特定し、特定したレコードのEndの欄に、当該２００ＯＫレスポンスを受信した日時を登録する。
【００６５】
また、ＳＩＰメッセージ制御部３０４は、通信部３０５を介して、ＵＳ５００から図６（ａ）に示した登録情報更新要求を受信した場合に、異なる形式の登録情報更新要求を作成し、作成した登録情報更新要求を通信部３０５を介してＡＣＳ１００へ送信する。本実施例においてＳＩＰメッセージ制御部３０４によって作成される登録情報更新要求は、例えば図６（ｃ）に示すように、updateAttributeRequestタグを用いたＸＭＬメッセージとして作成される。図６（ｃ）は、ＳＩＰメッセージ制御部３０４によって作成される登録情報更新要求のうち、本実施例の説明に必要な部分のみを示している。subjectタグにはＵＳ５００のSIP-URIが記載される。attributeタグには更新すべきユーザ属性情報が記載される。seqタグには、登録情報更新要求とその応答である登録情報更新応答とを対応付けるためのリクエスト番号が記載される。
【００６６】
また、ＳＩＰメッセージ制御部３０４は、通信部３０５を介して、ＡＣＳ１００から登録情報更新応答を受信した場合に、異なる形式の登録情報更新応答（図６（ｂ）参照）を作成し、作成した登録情報更新要求を通信部３０５を介してＵＳ５００へ送信する。本実施例においてＡＣＳ１００から送信される登録情報更新応答は、例えば図６（ｄ）に示すように、updateAttributeResponseタグを用いたＸＭＬメッセージとして作成される。図６（ｄ）は、ＡＣＳ１００から送信される登録情報更新応答のうち、本実施例の説明に必要な部分のみを示している。resultタグにはユーザ属性情報の変更結果が記載される。seqタグには、登録情報更新要求と登録情報更新応答とを対応付けるためのリクエスト番号が記載される。
【００６７】
次に、ＡＣＳ１００について説明する。ＡＣＳ１００は、次サービスＩＤ格納部１０１、次サービスＩＤ特定部１０２、認可情報格納部１０３、認可判定要求部１０４、および通信部１０５を備える。通信部１０５は、認可判定要求部１０４からの指示に応じて、ネットワーク１１を介して他の装置と通信を行う。
【００６８】
認可情報格納部１０３には、例えば図８に示すように、ＵＳ５００のユーザのSIP-URIを示すSubject１０３１、サービスＩＤを示すResource１０３２、認可判定要求部１０４によって作成された認可情報（図５（ｅ）参照）に記載されているアサーションＩＤ１０３３、認可情報を格納している場所を示す認可情報参照点１０３４、Resource１０３２に対応するサービスがSubject１０３１に対応するユーザに提供されている状態か否かを示す通信フラグ１０３５が、それぞれのレコードを識別する番号１０３０に対応付けて格納されている。
【００６９】
次サービスＩＤ格納部１０１には、例えば図９に示すように、それぞれのサービスのサービスＩＤ１０１０毎に、次に提供されるべきサービスのサービスＩＤを示す次サービスＩＤ１０１１が格納されている。本実施例では、それぞれのサービスは、予め定められたワークフロー内の一部を構成するものであり、それぞれのワークフロー毎に、サービスの提供順番が予め定められている。
【００７０】
次サービスＩＤ特定部１０２は、認可判定要求部１０４からユーザＩＤおよびサービスＩＤを受け付けた場合に、次サービスＩＤ格納部１０１を参照して、当該サービスＩＤに対応付けられている次サービスＩＤを抽出する。そして、次サービスＩＤ特定部１０２は、抽出した次サービスＩＤを、認可判定要求部１０４から受け付けたユーザＩＤと共に認可判定要求部１０４へ送る。なお、認可判定要求部１０４から受け取ったサービスＩＤに対応する次サービスＩＤが次サービスＩＤ格納部１０１内に存在しない場合（例えばワークフローの内の最後のサービスの次に提供されるべきサービスのサービスＩＤ等）、次サービスＩＤ特定部１０２は、認可判定要求部１０４から受け取ったユーザＩＤを認可判定要求部１０４へ返す。
【００７１】
認可判定要求部１０４は、通信部１０５を介して、ＣＭＳ３００から認可情報取得要求（図４（ｃ）参照）を受信した場合に、認可情報格納部１０３を参照して、当該認可情報取得要求のsubjectタグで示されるユーザＩＤおよびresourceタグで示されるサービスＩＤの組み合わせに対応する認可情報が存在するか否かを判定する。当該ユーザＩＤおよびサービスＩＤの組み合わせに対応する認可情報が存在する場合、認可判定要求部１０４は、当該認可情報を認可情報格納部１０３から取得して、図４（ｄ）で説明した認可情報取得応答を作成し、作成した認可情報取得応答を通信部１０５を介してＣＭＳ３００へ送信する。
【００７２】
認可情報取得要求に含まれているユーザＩＤおよびサービスＩＤの組み合わせに対応する認可情報が認可情報格納部１０３内に存在しない場合、認可判定要求部１０４は、登録情報取得要求を作成し、作成した登録情報取得要求を通信部１０５を介してＰＭＳ２００へ送信する。本実施例において登録情報取得要求は、図４（ｅ）に示すように、getAttributeAndPolicyRequestタグを用いたＸＭＬメッセージとして作成される。図４（ｅ）は、登録情報取得要求のうち、本実施例の説明に必要な部分のみを示している。subjectタグにはＵＳ５００のSIP-URIが記載される。resourceタグにはサービスＩＤが記載される。seqタグには、登録情報取得要求と登録情報取得応答とを対応付けるためのリクエスト番号が記載される。
【００７３】
そして、通信部１０５を介して登録情報取得応答をＰＭＳ２００から受信した場合、認可判定要求部１０４は、認可判定要求を作成し、作成した認可判定要求を、通信部１０５を介してＡｕＳ４００へ送信する。本実施例において登録情報取得応答は、図４（ｆ）に示すように、getAttributeAndPolicyResponseタグを用いたＸＭＬメッセージとして作成される。図４（ｆ）は、登録情報取得応答のうち、本実施例の説明に必要な部分のみを示している。
【００７４】
登録情報取得応答のresultタグにはＵＳ５００のユーザの属性情報およびサービスポリシ情報の取得結果が記載される。取得結果としては、例えば、ユーザの属性情報とサービスポリシ情報を両方取得できた場合にはＯＫが記載され、ユーザ属性情報およびサービスポリシ情報のいずれか一方が取得できなかった場合にはＮＧが記載される。登録情報取得応答のseqタグには、登録情報取得要求と登録情報取得応答とを対応付けるためのリクエスト番号が記載される。
【００７５】
登録情報取得応答のattributeタグにはユーザの属性情報が記載される。ユーザ属性情報は、例えば図５（ａ）に示すようなＸＭＬメッセージとして記述される。属性情報のidタグにはユーザのSIP-URIが記載される。nameタグにはユーザの名前が記載される。ageタグにはユーザの年齢が記載される。sexタグにはユーザの性別が記載される。addressタグにはユーザの住所が記載される。interestsタグにはユーザの嗜好がitemタグで挟んでそれぞれ記載される。itemタグは１つ以上記載される。idタグ以外のタグの要素はオプションであり、記載しない場合は各タグの要素に「null」が記載される。
【００７６】
登録情報取得応答のpolicyタグにはサービスポリシ情報が記載される。サービスポリシ情報は、例えば図５（ｂ）のようなＸＭＬメッセージとして記述される。idタグにはサービスＩＤが記載される。ruleListsタグには認可判定を行うための基準となるルールがruleタグで挟んで記載される。algorithmタグにはruleListsタグに記載している各ルールを用いた認可判定に使用されるアルゴリズムの名前が記載される。Ruleタグは１つ以上記載される。また、idタグ以外のタグの要素はオプションであり、記載しない場合は各タグの要素に「null」が記載される。
【００７７】
本実施例では、使用可能な認可判定アルゴリズムの例として２種類の認可判定アルゴリズムを想定する。サービスポリシ情報に記載するalgorithmタグの要素には、例えば以下の２つのアルゴリズムが指定可能である。「Deny-overrides」は、全てのルールに対して判定を行い、全てのルールについて「Permit」である場合のみ認可判定結果を「Permit」とし、それ以外の全ての場合については認可判定結果を「Deny」とする認可判定アルゴリズムである。「Permit-overrides」は、全てのルールに対して判定を行い、どれか一つのルールについて「Permit」であれば認可判定結果を「Permit」とし、全てのルールについて「Deny」である場合にのみ認可判定結果を「Deny」とする認可判定アルゴリズムである。認可判定の必要がないサービスを利用する場合には、認可判定アルゴリズムとして「null」が指定される。
【００７８】
また、本実施例において認可判定要求は、図５（ｃ）に示すように、judgeAuthorizationRequestタグを用いたＸＭＬメッセージとして作成される。図５（ｃ）は、認可判定要求のうち、本実施例の説明に必要な部分のみを示している。attributeタグにはユーザの属性情報が記載される。policyタグにはサービスポリシ情報が記載される。seqタグには認可判定要求と認可判定応答とを対応付けるためのリクエスト番号が記載される。
【００７９】
そして、通信部１０５を介して認可判定応答をＡｕＳ４００から受信した場合、認可判定要求部１０４は、認可情報を作成する。本実施例において認可判定応答は、図５（ｄ）に示すように、judgeAuthorizationResponseタグを用いたＸＭＬメッセージとして作成される。図５（ｄ）は、認可判定応答のうち、本実施例の説明に必要な部分のみを示している。resultタグには認可判定の結果が記載される。seqタグには認可判定要求と認可判定応答とを対応付けるためのリクエスト番号が記載される。
【００８０】
そして、当該認可判定応答に含まれている認可判定結果が、サービスの提供を許可する旨を示す場合、認可判定要求部１０４は、作成した認可情報をＡＣＳ１００内のメモリまたはＡＣＳ１００の外部の装置内のメモリに保存し、保存先を示す情報を当該認可情報の対象となるユーザＩＤおよびサービスＩＤに対応付けて認可情報格納部１０３に登録する。そして、認可判定要求部１０４は、認可情報取得応答（図４（ｄ）参照）を作成して、通信部１０５を介してＣＭＳ３００へ送信する。
【００８１】
本実施例において認可情報は、図５（ｅ）に示すように、assertion-Bodyタグを用いたＸＭＬメッセージとして作成される。図５（ｅ）は、認可情報のうち、本実施例の説明に必要な部分のみを示している。assertionIDタグには認可情報を識別する識別情報が記載される。subjectタグには認可判定応答に対応する認可判定要求内のユーザ属性情報に含まれるユーザＩＤが記載される。resourceタグには認可判定応答に対応する認可判定要求内のサービスポリシ情報に含まれるサービスＩＤが記載される。decisionタグには認可判定応答に含まれている認可判定の結果が記載される。signatureタグにはassertion-Bodyタグ全体を対象としたＸＭＬ署名が記載される。
【００８２】
認可情報取得応答をＣＭＳ３００へ送信した後、認可判定要求部１０４は、当該認可情報取得応答に含まれているユーザＩＤおよびサービスＩＤを次サービスＩＤ特定部１０２へ送る。そして、次サービスＩＤ特定部１０２からユーザＩＤおよび次サービスＩＤを受け取った場合、認可判定要求部１０４は、当該ユーザＩＤおよび次サービスＩＤの組み合わせに対応する認可情報が認可情報格納部１０３に登録されているか否かを判定する。
【００８３】
当該ユーザＩＤおよび次サービスＩＤの組み合わせに対応する認可情報が認可情報格納部１０３に登録されていない場合、認可判定要求部１０４は、当該ユーザＩＤおよび次サービスＩＤを含む登録情報取得要求（図４（ｅ）参照）を作成してＰＭＳ２００へ送る。なお、当該ユーザＩＤおよび次サービスＩＤの組み合わせに対応する認可情報が認可情報格納部１０３に既に登録されている場合、または、次サービスＩＤ特定部１０２がユーザＩＤと共に次サービスＩＤを出力しなかった場合、認可判定要求部１０４は、予め認可判定を行う処理を実行しない。
【００８４】
そして、認可判定要求部１０４は、ＰＭＳ２００から登録情報取得応答（図４（ｆ））を受け取り、受け取った登録情報取得応答に基づいて認可判定要求（図５（ｃ））を作成してＡｕＳ４００へ送る。そして、認可判定要求部１０４は、ＡｕＳ４００から認可判定応答（図５（ｄ））を受け取り、受け取った認可判定応答に含まれている認可判定結果がサービスの提供を許可する旨を示す場合に、認可情報を作成し、作成した認可情報をＡＣＳ１００内のメモリまたはＡＣＳ１００の外部の装置内のメモリに保存し、保存先を示す情報を当該認可情報の対象となるユーザＩＤおよびサービスＩＤに対応付けて認可情報格納部１０３に登録する。
【００８５】
このように、認可判定要求部１０４は、あるユーザについて認可判定を行ったサービスの次に提供されるべきサービスの認可判定を、当該ユーザから要求される前に実行する。これにより、アクセス認可システム１０は、ユーザからサービスの要求を受け付けた場合に、認可判定の間ユーザを待たせることなく、ユーザに対する認可判定結果に基づいてより迅速にサービスの提供を開始することができる。
【００８６】
なお、本実施例において、認可判定要求部１０４は、認可情報取得応答をＣＭＳ３００へ送信してから、当該認可情報取得応答に記載したサービスＩＤで特定されるサービスの次に提供されるべきサービスに対する認可情報取得要求をＣＭＳ３００から受信する前までの間に、当該認可情報取得応答に含まれるユーザＩＤに対応するユーザについて、当該次に提供されるべきサービスの認可判定に関する処理を実行する。
【００８７】
より好ましくは、認可判定要求部１０４は、認可情報取得応答をＣＭＳ３００へ送信してから、当該認可情報取得応答に記載したサービスＩＤで特定されるサービスの次に提供されるべきサービスに対する認可情報取得要求をＣＭＳ３００から受信する前までの間であって、ＡＣＳ１００の処理負荷が低いときに、当該次に提供されるべきサービスの認可判定を実施する。処理負荷が低いときとは、例えばＡＣＳ１００の処理負荷が予め定められた閾値よりも低いときを指す。例えば、ＡＣＳ１００のＣＰＵ使用率が５０％未満のときに、認可判定要求部１０４は、当該次に提供されるべきサービスの認可判定を実施する。
【００８８】
また、認可判定要求部１０４は、通信部１０５を介して、ＣＭＳ３００から登録情報更新要求（図６（ｃ）参照）を受信した場合に、受信した登録情報更新要求をＰＭＳ２００に転送する。そして、ＰＭＳ２００から登録情報更新応答（図６（ｄ）参照）を受信した場合、認可判定要求部１０４は、認可情報格納部１０３を参照して、当該登録情報更新応答に対応する登録情報更新要求に含まれているユーザＩＤが認可情報格納部１０３に登録されているか否かを判定する。当該ユーザＩＤが認可情報格納部１０３に登録されていない場合、認可判定要求部１０４は、ＰＭＳ２００から受信した登録情報更新応答をＣＭＳ３００へ転送する。
【００８９】
一方、ＰＭＳ２００から受信した登録情報更新応答に対応する登録情報更新要求に含まれているユーザＩＤが認可情報格納部１０３に登録されている場合、認可判定要求部１０４は、認可情報格納部１０３を参照して、当該ユーザＩＤに対応付けられているサービスＩＤを抽出する。そして、認可判定要求部１０４は、抽出したそれぞれのサービスＩＤについて認可情報削除要求（図６（ｅ）参照）を作成し、作成した認可情報削除要求を、通信部１０５を介してそれぞれの宛先のＳＰ６００へ送信する。
【００９０】
そして、認可情報削除要求を送信した全てのＳＰ６００から認可情報削除応答（図６（ｆ））を受信した場合、認可判定要求部１０４は、送信した認可情報削除要求に含まれるユーザＩＤを含む全てのレコードを認可情報格納部１０３から削除し、ＰＭＳ２００から受信した登録情報更新応答をＣＭＳ３００へ転送する。
【００９１】
次に、ＰＭＳ２００について説明する。ＰＭＳ２００は、サービスポリシ情報格納部２０１、ユーザ属性情報格納部２０２、情報管理部２０３、および通信部２０４を備える。通信部２０４は、情報管理部２０３からの指示に応じて、ネットワーク１１を介して他の装置と通信を行う。
【００９２】
サービスポリシ情報格納部２０１には、例えば図１０に示すように、サービスＩＤ２０１０毎に、当該サービスＩＤ２０１０に対応するサービスのサービスポリシ情報の実体が格納されているＰＭＳ２００のメモリ内の場所を示す参照先アドレス２０１１が格納されている。サービスポリシ情報の実体は、例えば図５（ｂ）に示すようなデータ構造である。
【００９３】
ユーザ属性情報格納部２０２には、例えば図１１に示すように、ユーザＩＤ２０２０毎に、当該ユーザＩＤ２０２０に対応するユーザの属性情報の実体が格納されているＰＭＳ２００のメモリ内の場所を示す参照先アドレス２０２１が格納されている。ユーザ属性情報の実体は、例えば図５（ａ）に示すようなデータ構造である。
【００９４】
情報管理部２０３は、通信部２０４を介して、登録情報取得要求（図４（ｅ）参照）をＡＣＳ１００から受信した場合に、当該登録情報取得要求に含まれているサービスＩＤに対応するサービスポリシ情報をサービスポリシ情報格納部２０１から取得し、当該登録情報取得要求に含まれているユーザＩＤに対応するユーザ属性情報をユーザ属性情報格納部２０２から取得する。そして、情報管理部２０３は、取得したサービスポリシ情報およびユーザ属性情報に基づいて登録情報取得応答（図４（ｆ）参照）を作成し、作成した登録情報取得応答を、通信部２０４を介してＡＣＳ１００へ送信する。
【００９５】
また、情報管理部２０３は、通信部２０４を介して、ＡＣＳ１００から登録情報更新要求（図６（ｃ）参照）を受信した場合に、ユーザ属性情報格納部２０２を参照して、当該登録情報更新要求に含まれるユーザＩＤに対応するユーザ属性情報を、当該登録情報更新要求に含まれるユーザ属性情報で更新する。そして、情報管理部２０３は、更新結果を含む登録情報更新応答（図６（ｄ））を作成し、作成した登録情報更新応答を、通信部２０４を介してＡＣＳ１００へ送信する。
【００９６】
次に、ＡｕＳ４００について説明する。ＡｕＳ４００は、認可判定部４０１および通信部４０２を備える。通信部４０２は、認可判定部４０１からの指示に応じて、ネットワーク１１を介して他の装置と通信を行う。
【００９７】
認可判定部４０１は、通信部４０２を介して、認可判定要求（図５（ｃ）参照）をＡＣＳ１００から受信した場合に、当該認可判定要求に含まれるユーザ属性情報が、当該認可判定要求に含まれるサービスポリシ情報を満たすか否かを判定する認可判定を実行する。そして、認可判定部４０１は、認可判定結果を含む認可判定応答（図５（ｄ）参照）を作成し、作成した認可判定応答を、通信部４０２を介してＡＣＳ１００へ送信する。
【００９８】
次に、第１実施例において、ユーザの要求に応じてサービスの提供が開始される場合のアクセス認可システム１０の一連の動作について図１２を用いて説明する。
【００９９】
まず、ＵＳ５００のＳＩＰクライアント５０３は、ユーザからの要求に応じて図４（ａ）に示した通信開始要求を作成し、作成した通信開始要求をＣＭＳ３００へ送信する（Ｓ１００）。ここで、ＵＳ５００のユーザのSIP-RUIは「jiro@sipdomain.com」であり、ユーザが希望するサービスのサービスＩＤは「http://travel.testservice1.com/」であるものと仮定する。ＣＭＳ３００のＳＩＰメッセージ制御部３０４は、ＵＳ５００から受信した通信開始要求に基づいて図４（ｃ）に示した認可情報取得要求を作成し、作成した認可情報取得要求をＡＣＳ１００へ送信する（Ｓ１０１）。
【０１００】
次に、ＡＣＳ１００の認可判定要求部１０４は、ＣＭＳ３００から受信した認可情報取得要求に含まれるユーザＩＤおよびサービスＩＤの組み合わせに対応する認可情報が認可情報格納部１０３に格納されているか否かを判定する（Ｓ１０２）。当該ユーザＩＤおよびサービスＩＤの組み合わせに対応する認可情報が認可情報格納部１０３に格納されている場合（Ｓ１０２：Ｙｅｓ）、認可判定要求部１０４は、ステップＳ１０９に示す処理を実行する。
【０１０１】
ここで、ステップＳ１０２が実行される前の認可情報格納部１０３には、例えば図１３（ａ）に示すようなデータが格納されているものとする。本シーケンス図で示される例では、ＣＭＳ３００から受信した認可情報取得要求に含まれるユーザＩＤおよびサービスＩＤの組み合わせに対応する認可情報が認可情報格納部１０３に格納されておらず（Ｓ１０２：Ｎｏ）、認可判定要求部１０４は、当該ユーザＩＤおよびサービスＩＤに基づいて、図４（ｅ）に示した登録情報取得要求を作成し、作成した登録情報取得要求をＰＭＳ２００へ送信する（Ｓ１０３）。
【０１０２】
ＰＭＳ２００の情報管理部２０３は、ＡＣＳ１００から受信した登録情報取得要求に含まれているユーザＩＤおよびサービスＩＤに基づいて、サービスポリシ情報格納部２０１およびユーザ属性情報格納部２０２から対応するユーザ属性情報およびサービスポリシ情報をそれぞれ取得する。そして、情報管理部２０３は、取得したユーザ属性情報およびサービスポリシ情報を含む登録情報取得応答（図４（ｆ）参照）を作成し、作成した登録情報取得応答をＡＣＳ１００へ送信する（Ｓ１０４）。
【０１０３】
次に、ＡＣＳ１００の認可判定要求部１０４は、ＰＭＳ２００から受信した登録情報取得応答に含まれているユーザ属性情報およびサービスポリシ情報を含む認可判定要求（図５（ｃ）参照）を作成し、作成した認可判定要求をＡｕＳ４００へ送信する（Ｓ１０５）。ＡｕＳ４００の認可判定部４０１は、ＡＣＳ１００から受信した認可判定要求に含まれるユーザ属性情報が、当該認可判定要求に含まれているサービスポリシ情報を満たすか否かを判定する（Ｓ１０６）。そして、認可判定部４０１は、認可判定結果を含む認可判定応答（図５（ｄ）参照）を作成し、作成した認可判定応答をＡＣＳ１００へ送信する（Ｓ１０７）。
【０１０４】
次に、ＡＣＳ１００の認可判定要求部１０４は、ＡｕＳ４００から受信した認可判定応答に基づいて、図５（ｅ）に示した認可情報を作成し、当該認可応答に含まれる判定結果がサービスの利用を許可する旨を示す場合に、当該認可情報を、対応するユーザＩＤおよびサービスＩＤ等の情報と共に認可情報格納部１０３に保存する（Ｓ１０８）。この時点で、認可情報格納部１０３内のデータは、例えば図１３（ｂ）に示すような構成になる。そして、認可判定要求部１０４は、図４（ｄ）に示した認可情報取得応答を作成し、作成した認可情報取得応答をＣＭＳ３００へ送信する（Ｓ１０９）。
【０１０５】
ＣＭＳ３００のＳＩＰメッセージ制御部３０４は、図４（ａ）に示した通信開始要求において、宛先をサービスＩＤに対応するサービスを提供するＳＰ６００のSIP-URIとし、ＢＯＤＹ部３０にＡＣＳ１００から受信した認可情報取得応答に含まれている認可情報を含めた通信開始要求を作成し、作成した通信開始要求をＳＰ６００へ送信する（Ｓ１１０）。
【０１０６】
ＳＰ６００のＳＩＰクライアント６０３は、ＣＭＳ３００から受信した通信開始要求に応じて、図４（ｂ）に示した通信開始応答を作成し、作成した通信開始応答をＣＭＳ３００へ送信する（Ｓ１１１）。ＣＭＳ３００のＳＩＰメッセージ制御部３０４は、ＳＰ６００から受信した通信開始応答の一部を書き換えてＵＳ５００へ送信する（Ｓ１１２）。そして、ＳＰ６００のサービスアプリケーション６０２は、ＵＳ５００へのサービスの提供を開始する（Ｓ１１３）。
【０１０７】
次に、ＡＣＳ１００の認可判定要求部１０４は、ステップＳ１０９において送信した認可情報取得応答内の認可情報に含まれているユーザＩＤおよびサービスＩＤを次サービスＩＤ特定部１０２へ送る。次サービスＩＤ特定部１０２は、次サービスＩＤ格納部１０１を参照して、当該サービスＩＤに対応付けられている次サービスＩＤを抽出することにより、次に提供されるべきサービスのサービスＩＤを特定する（Ｓ１１４）。
【０１０８】
次に、次サービスＩＤ特定部１０２は、抽出した次サービスＩＤを、認可判定要求部１０４から受け付けたユーザＩＤと共に認可判定要求部１０４へ返す。そして、認可判定要求部１０４は、次サービスＩＤ特定部１０２から受信したユーザＩＤおよびサービスＩＤを用いて、ステップＳ１０２からステップＳ１０８に示した処理Ａを実行する（Ｓ１１５）。ステップＳ１１５の処理が終了すると、認可情報格納部１０３内のデータは、例えば図１３（ｃ）に示すような構成になる。これにより、アクセス認可システム１０は、同一のユーザから次のサービスの提供を要求された場合に、認可情報格納部１０３内の認可情報をもとに迅速にサービスの提供を開始することができる。
【０１０９】
なお、本シーケンス図では、ステップＳ１１４およびＳ１１５で示される処理が、ステップＳ１１３で示される処理の後に実行されているが、本発明はこれに限られず、認可判定要求部１０４は、ステップＳ１０９で示される処理を実行してから、次のサービスの要求に対応する認可情報取得要求を受信するまでの間に、ステップＳ１１４およびＳ１１５で示される処理を実行すればよい。
【０１１０】
次に、第１実施例において、ＵＳ５００を介したユーザによる登録情報の更新に関する一連の処理について図１４を用いて説明する。
【０１１１】
まず、ＵＳ５００のＳＩＰクライアント５０３は、ユーザからの要求に応じて図６（ａ）に示した登録情報更新要求を作成し、作成した登録情報更新要求をＣＭＳ３００へ送信する（Ｓ２００）。ＣＭＳ３００のＳＩＰメッセージ制御部３０４は、ＵＳ５００から受信した登録情報更新要求に基づいて図６（ｃ）に示した登録情報更新要求を作成し、作成した登録情報更新要求をＡＣＳ１００へ送信する（Ｓ２０１）。
【０１１２】
ＡＣＳ１００の認可判定要求部１０４は、ＣＭＳ３００から受信した登録情報更新要求をＰＭＳ２００へ転送する（Ｓ２０２）。ＰＭＳ２００の情報管理部２０３は、ＡＣＳ１００から受信した登録要求更新要求に含まれているユーザＩＤに対応するユーザ属性情報格納部２０２内のユーザ属性情報を、当該登録情報更新要求に含まれているユーザ属性情報で更新する（Ｓ２０３）。そして、情報管理部２０３は、図６（ｄ）に示した登録情報更新応答を作成し、作成した登録情報更新応答をＡＣＳ１００へ送信する（Ｓ２０４）。
【０１１３】
次に、ＡＣＳ１００の認可判定要求部１０４は、ステップＳ２０１で受信した登録情報更新要求に含まれているユーザＩＤに対応する認可情報が認可情報格納部１０３に格納されているか否かを判定する（Ｓ２０５）。当該ユーザＩＤに対応する認可情報が認可情報格納部１０３に格納されていない場合（Ｓ２０５：Ｎｏ）、認可判定要求部１０４は、ステップＳ２１３に示す処理を実行する。
【０１１４】
ステップＳ２０１で受信した登録情報更新要求に含まれているユーザＩＤに対応する認可情報が認可情報格納部１０３に格納されている場合（Ｓ２０５：Ｙｅｓ）、認可判定要求部１０４は、当該認可情報に対応付けられているサービスＩＤを認可情報格納部１０３から抽出し、抽出したそれぞれのサービスＩＤについて、図６（ｅ）に示した認可情報削除要求を作成し、作成した認可情報削除要求を送信する（Ｓ２０６、Ｓ２０９）。本例では、ＳＰ６００−αとＳＰ６００−βにはサービスの提供を許可する旨を示す認可情報が既に渡されており、ＳＰ６００−γにはサービスの提供を許可する旨を示す認可情報が渡されていないものとする。
【０１１５】
ＳＰ６００−αおよびＳＰ６００−βのそれぞれのＳＩＰクライアント６０３は、通信管理テーブル格納部６０４を参照して、ＡＣＳ１００から受信した認可情報削除要求に含まれているユーザＩＤに対応するレコードを通信管理テーブル６０４０から全て削除する（Ｓ２０７、Ｓ２１０）。そして、ＳＩＰクライアント６０３は、図６（ｆ）に示した認可情報削除応答を作成し、作成した認可情報削除応答をＡＣＳ１００へ送信する（Ｓ２０８、Ｓ２１１）。
【０１１６】
次に、ＡＣＳ１００の認可判定要求部１０４は、ステップＳ２０１で受信した登録情報更新要求に含まれているユーザＩＤに対応する認可情報を認可情報格納部１０３から全て削除し（Ｓ２１２）、ステップＳ２０４で受信した登録情報更新応答をＣＭＳ３００へ転送する（Ｓ２１３）。ＣＭＳ３００のＳＩＰメッセージ制御部３０４は、ＡＣＳ１００から受信した登録情報更新応答に基づいて、図６（ｂ）に示した登録情報更新応答を作成し、作成した登録情報更新応答をＵＳ５００へ送信する（Ｓ２１４）。
【０１１７】
以上、本発明の第１実施例について説明した。上記説明から明らかなように、本実施例のアクセス認可システム１０によれば、ユーザから要求されたサービスの提供開始までのユーザの待ち時間を少なくすることができる。
【０１１８】
また、本実施例において、ＡＣＳ１００は、事前に行った認可判定の結果を保持し、ＣＭＳ３００から認可情報取得要求を受信した場合に、保持していた認可情報を用いて認可情報取得応答を返信する。これにより、実際にはユーザが提供を受けていないサービスに関する認可情報は、ＡＣＳ１００内に存在する。そのため、ユーザの属性情報が変更された場合に、認可判定のやり直しに伴う認可情報の削除を実行する必要があるが、認可情報が保存されている装置を少なくできるため、認可情報の削除に伴う通信トラフィックを低減することができる。
【０１１９】
＜実施例２＞
次に、本発明の第２実施例について説明する。
【０１２０】
図１５は、第２実施例におけるアクセス認可システム１０の構成を例示するシステム構成図である。アクセス認可システム１０は、アクセス制御サーバ（ＡＣＳ）１００、ポリシ管理サーバ（ＰＭＳ）２００、通信管理サーバ（ＣＭＳ）３００、認可サーバ（ＡｕＳ）４００、ユーザ端末（ＵＳ）５００、および複数のサービス提供サーバ（ＳＰ）６００を備える。なお、以下に説明する点を除き、図１５において、図１と同じ符号を付した構成は、図１における構成と同一または同様の機能を有するため説明を省略する。
【０１２１】
ＳＰ６００のＳＩＰクライアント６０３は、ＡＣＳ１００からユーザＩＤ、サービスＩＤ、および認可情報を含む認可情報送信通知を受信した場合に、受信したこれらの情報を通信管理テーブル格納部６０４に登録し、認可情報送信完了通知をＡＣＳ１００へ送信する。
【０１２２】
本実施例において認可情報送信通知は、例えば図１６（ａ）に示すように、sendAuthorizationAssertionNotifyタグを用いたＸＭＬメッセージとして作成される。図１６（ａ）は、認可情報送信通知のうち、本実施例の説明に必要な部分のみを示している。subjectタグにはユーザＩＤが記載される。resourceタグにはサービスＩＤが記載される。assertionタグには認可情報（図５（ｅ）参照）が記載される。seqタグには、認可情報送信通知と認可情報送信完了通知とを対応付けるためのリクエスト番号が記載される。
【０１２３】
また、本実施例において認可情報送信完了通知は、例えば図１６（ｂ）に示すように、sendAuthorizationAssertionReportタグを用いたＸＭＬメッセージとして作成される。図１６（ｂ）は、認可情報送信完了通知のうち、本実施例の説明に必要な部分のみを示している。statusタグには認可情報送信通知の受信結果が記載される。seqタグには、認可情報送信通知と認可情報送信完了通知とを対応付けるためのリクエスト番号が記載される。
【０１２４】
ＡＣＳ１００は、次サービスＩＤ格納部１０１、次サービスＩＤ特定部１０２、認可情報格納部１０３、認可判定要求部１０４、通信部１０５、およびサービス履歴格納部１０６を備える。
【０１２５】
認可情報格納部１０３には、例えば図１７に示すように、ＵＳ５００のユーザのSIP-URIを示すSubject１０３１、および、サービスＩＤを示すResource１０３２が、それぞれのレコードを識別する番号１０３０に対応付けて格納されている。
【０１２６】
サービス履歴格納部１０６には、例えば図１８に示すように、ユーザＩＤ１０６１およびサービスＩＤ１０６２の組み合わせ毎に、履歴テーブル１０６０が格納されている。それぞれの履歴テーブル１０６０には、ユーザＩＤ１０６１に対応するユーザに対して、サービスＩＤ１０６２に対応するサービスが提供された後に、当該ユーザに対して次に提供されたサービスのサービスＩＤを示す次サービスＩＤ１０６３が、当該次サービスＩＤ１０６３に対応するサービスが提供された回数１０６４に対応付けて格納されている。
【０１２７】
次サービスＩＤ特定部１０２は、認可判定要求部１０４からユーザＩＤおよびサービスＩＤを受け付けた場合に、次サービスＩＤ格納部１０１を参照して、当該サービスＩＤに対応付けられている次サービスＩＤが存在するか否かを判定する。当該サービスＩＤに対応付けられている次サービスＩＤが存在する場合、次サービスＩＤ特定部１０２は、当該次サービスＩＤを、認可判定要求部１０４から受け付けたユーザＩＤと共に認可判定要求部１０４へ送る。
【０１２８】
一方、認可判定要求部１０４から受け取ったサービスＩＤに対応付けられている次サービスＩＤが次サービスＩＤ格納部１０１内に存在しない場合、次サービスＩＤ特定部１０２は、サービス履歴格納部１０６を参照し、認可判定要求部１０４から受け取ったユーザＩＤおよびサービスＩＤに対応する履歴テーブル１０６０を特定する。そして、次サービスＩＤ特定部１０２は、特定した履歴テーブル１０６０を参照して、予め定められた閾値以上（例えば２０以上）の回数が対応付けられている次サービスＩＤを抽出し、抽出したサービスＩＤを、認可判定要求部１０４から受け取ったユーザＩＤと共に認可判定要求部１０４へ送る。図１８に示した例において、予め定められた閾値が２０回であるとすると、次サービスＩＤ特定部１０２は、２つのサービスＩＤを抽出することになる。
【０１２９】
なお、認可判定要求部１０４から受け取ったユーザＩＤおよびサービスＩＤに対応する履歴テーブル１０６０がサービス履歴格納部１０６内に存在しない場合、または、予め定められた値以上の回数が対応付けられている次サービスＩＤが履歴テーブル１０６０内に存在しない場合、次サービスＩＤ特定部１０２は、認可判定要求部１０４から受け取ったユーザＩＤを認可判定要求部１０４へ返す。
【０１３０】
認可判定要求部１０４は、通信部１０５を介して、ＣＭＳ３００から認可情報取得要求（図４（ｃ）参照）を受信した場合に、当該認可情報取得要求のsubjectタグで示されるユーザＩＤおよびresourceタグで示されるサービスＩＤの組み合わせが認可情報格納部１０３内に存在するか否かを判定する。当該ユーザＩＤおよびサービスＩＤの組み合わせが認可情報格納部１０３内に存在する場合、認可判定要求部１０４は、図４（ｄ）においてassertionタグを含まない認可情報取得応答を作成し、作成した認可情報取得応答を通信部１０５を介してＣＭＳ３００へ送信する。
【０１３１】
認可情報取得要求に含まれているユーザＩＤおよびサービスＩＤの組み合わせが認可情報格納部１０３内に存在しない場合、認可判定要求部１０４は、図４（ｅ）に示した登録情報取得要求を作成し、作成した登録情報取得要求を通信部１０５を介してＰＭＳ２００へ送信する。そして、通信部１０５を介して、図４（ｆ）に示した登録情報取得応答をＰＭＳ２００から受信した場合、認可判定要求部１０４は、図５（ｃ）に示した認可判定要求を作成し、作成した認可判定要求を、通信部１０５を介してＡｕＳ４００へ送信する。
【０１３２】
また、通信部１０５を介して図５（ｄ）に示した認可判定応答をＡｕＳ４００から受信した場合、認可判定要求部１０４は認可情報を作成する。そして、当該認可判定応答に含まれている認可判定結果が、サービスの提供を許可する旨を示す場合、認可判定要求部１０４は、作成した認可情報に含まれているユーザＩＤおよびサービスＩＤを認可情報格納部１０３に保存する。そして、認可判定要求部１０４は、認可情報取得応答（図４（ｄ）参照）を作成して、通信部１０５を介してＣＭＳ３００へ送信する。
【０１３３】
認可情報取得応答をＣＭＳ３００へ送信した後、認可判定要求部１０４は、当該認可情報取得応答の契機となった認可情報取得要求に含まれているユーザＩＤおよびサービスＩＤを次サービスＩＤ特定部１０２へ送る。そして、次サービスＩＤ特定部１０２からユーザＩＤおよび次サービスＩＤを受け取った場合、認可判定要求部１０４は、当該ユーザＩＤおよび次サービスＩＤの組み合わせが認可情報格納部１０３に登録されているか否かを判定する。
【０１３４】
当該ユーザＩＤおよび次サービスＩＤの組み合わせが認可情報格納部１０３に登録されていない場合、認可判定要求部１０４は、当該ユーザＩＤおよび次サービスＩＤを含む登録情報取得要求（図４（ｅ）参照）を作成してＰＭＳ２００へ送る。なお、当該ユーザＩＤおよび次サービスＩＤの組み合わせが認可情報格納部１０３に既に登録されている場合、または、次サービスＩＤ特定部１０２がユーザＩＤと共に次サービスＩＤを出力しなかった場合、認可判定要求部１０４は、予め認可判定を行う処理を実行しない。
【０１３５】
そして、認可判定要求部１０４は、ＰＭＳ２００から登録情報取得応答（図４（ｆ））を受け取り、受け取った登録情報取得応答に基づいて認可判定要求（図５（ｃ））を作成してＡｕＳ４００へ送る。そして、認可判定要求部１０４は、ＡｕＳ４００から認可判定応答（図５（ｄ））を受け取り、認可情報を作成する。そして、当該認可判定応答に含まれている認可判定結果が、サービスの提供を許可する旨を示す場合、認可判定要求部１０４は、作成した認可情報に含まれているユーザＩＤおよびサービスＩＤを認可情報格納部１０３に保存する。
【０１３６】
そして、認可判定要求部１０４は、作成した認可情報を含む認可情報送信通知（図１６（ａ）参照）を作成し、作成した認可情報送信通知を通信部１０５を介してＳＰ６００へ送信する。そして、認可判定要求部１０４は、通信部１０５を介して、図１６（ｂ）に示した認可情報送信完了通知を受信する。
【０１３７】
次に、第２実施例において、ユーザの要求に応じてサービスの提供が開始される場合のアクセス認可システム１０の一連の動作について図１９を用いて説明する。
【０１３８】
まず、ＵＳ５００のＳＩＰクライアント５０３は、ユーザからの要求に応じて図４（ａ）に示した通信開始要求を作成し、作成した通信開始要求をＣＭＳ３００へ送信する（Ｓ３００）。ＣＭＳ３００のＳＩＰメッセージ制御部３０４は、ＵＳ５００から受信した通信開始要求に基づいて図４（ｃ）に示した認可情報取得要求を作成し、作成した認可情報取得要求をＡＣＳ１００へ送信する（Ｓ３０１）。
【０１３９】
ＡＣＳ１００の認可判定要求部１０４は、ＣＭＳ３００から受信した認可情報取得要求に含まれるユーザＩＤおよびサービスＩＤの組み合わせが認可情報格納部１０３に格納されているか否かを判定する（Ｓ３０２）。当該ユーザＩＤおよびサービスＩＤの組み合わせが認可情報格納部１０３に格納されている場合（Ｓ３０２：Ｙｅｓ）、認可判定要求部１０４は、ステップＳ３０９に示す処理を実行する。
【０１４０】
ＣＭＳ３００から受信した認可情報取得要求に含まれるユーザＩＤおよびサービスＩＤの組み合わせが認可情報格納部１０３に格納されていない場合（Ｓ３０２：Ｎｏ）、認可判定要求部１０４は、当該ユーザＩＤおよびサービスＩＤに基づいて、図４（ｅ）に示した登録情報取得要求を作成し、作成した登録情報取得要求をＰＭＳ２００へ送信する（Ｓ３０３）。
【０１４１】
ＰＭＳ２００の情報管理部２０３は、ＡＣＳ１００から受信した登録情報取得要求に含まれているユーザＩＤおよびサービスＩＤに基づいて、サービスポリシ情報格納部２０１およびユーザ属性情報格納部２０２から対応するユーザ属性情報およびサービスポリシ情報をそれぞれ取得する。そして、情報管理部２０３は、取得したユーザ属性情報およびサービスポリシ情報を含む登録情報取得応答（図４（ｆ）参照）を作成し、作成した登録情報取得応答をＡＣＳ１００へ送信する（Ｓ３０４）。
【０１４２】
次に、ＡＣＳ１００の認可判定要求部１０４は、ＰＭＳ２００から受信した登録情報取得応答に含まれているユーザ属性情報およびサービスポリシ情報を含む認可判定要求（図５（ｃ）参照）を作成し、作成した認可判定要求をＡｕＳ４００へ送信する（Ｓ３０５）。ＡｕＳ４００の認可判定部４０１は、ＡＣＳ１００から受信した認可判定要求に含まれるユーザ属性情報が、当該認可判定要求に含まれるサービスポリシ情報を満たすか否かを判定する（Ｓ３０６）。そして、認可判定部４０１は、認可判定結果を含む認可判定応答（図５（ｄ）参照）を作成し、作成した認可判定応答をＡＣＳ１００へ送信する（Ｓ３０７）。
【０１４３】
次に、ＡＣＳ１００の認可判定要求部１０４は、ＡｕＳ４００から受信した認可判定応答に基づいて、図５（ｅ）に示した認可情報を作成し、当該認可応答に含まれる判定結果がサービスの利用を許可する旨を示す場合に、当該認可情報に含まれているユーザＩＤおよびサービスＩＤを認可情報格納部１０３に保存する（Ｓ３０８）。そして、認可判定要求部１０４は、図４（ｄ）に示した認可情報取得応答を作成し、作成した認可情報取得応答をＣＭＳ３００へ送信する（Ｓ３０９）。
【０１４４】
次に、ＣＭＳ３００のＳＩＰメッセージ制御部３０４は、図４（ａ）に示した通信開始要求において、宛先をサービスＩＤに対応するサービスを提供するＳＰ６００のSIP-URIとし、ＡＣＳ１００から受信した認可情報取得応答に含まれている認可情報を含めた通信開始要求を作成し、作成した通信開始要求をＳＰ６００へ送信する（Ｓ３１０）。
【０１４５】
ＳＰ６００のＳＩＰクライアント６０３は、ＣＭＳ３００から受信した通信開始要求に応じて、図４（ｂ）に示した通信開始応答を作成し、作成した通信開始応答をＣＭＳ３００へ送信する（Ｓ３１１）。ＣＭＳ３００のＳＩＰメッセージ制御部３０４は、ＳＰ６００から受信した通信開始応答の一部を書き換えてＵＳ５００へ送信する（Ｓ３１２）。そして、ＳＰ６００のサービスアプリケーション６０２は、ＵＳ５００へのサービスの提供を開始する（Ｓ３１３）。
【０１４６】
なお、ステップＳ３０２において、ＣＭＳ３００から受信した認可情報取得要求に含まれるユーザＩＤおよびサービスＩＤの組み合わせが認可情報格納部１０３に格納されていると判定された後に（Ｓ３０２：Ｙｅｓ）、ステップＳ３０９において送信される認可情報取得応答およびステップＳ３１０において送信される通信開始要求には、認可情報が含まれない。
【０１４７】
次に、ＡＣＳ１００の認可判定要求部１０４は、ステップＳ３０９において送信した認可情報取得応答内の認可情報に含まれているユーザＩＤおよびサービスＩＤを次サービスＩＤ特定部１０２へ送る。次サービスＩＤ特定部１０２は、次サービスＩＤ格納部１０１またはサービス履歴格納部１０６を参照して、当該サービスＩＤに対応付けられている次サービスＩＤを抽出することにより、次に提供されるべきサービスのサービスＩＤを特定する（Ｓ３１４）。
【０１４８】
次に、次サービスＩＤ特定部１０２は、特定した次サービスＩＤを、認可判定要求部１０４から受け付けたユーザＩＤと共に認可判定要求部１０４へ返す。そして、認可判定要求部１０４は、次サービスＩＤ特定部１０２から受信したユーザＩＤおよびサービスＩＤを用いて、ステップＳ３０２からステップＳ３０８に示した処理Ｂを実行する（Ｓ３１５）。
【０１４９】
そして、認可判定要求部１０４は、図１６（ａ）に示した認可情報送信通知をＳＰ６００へ送信する（Ｓ３１６）。ＳＰ６００のＳＩＰクライアント６０３は、受信した認可情報送信通知に含まれているユーザＩＤ、サービスＩＤ、および認可情報を通信管理テーブル格納部６０４に格納し、図１６（ｂ）に示した認可情報送信完了通知をＡＣＳ１００へ送信する（Ｓ３１７）。
【０１５０】
次に、第２実施例において、ＵＳ５００を介したユーザによる登録情報の更新に関する一連の処理について図２０を用いて説明する。
【０１５１】
まず、ＵＳ５００のＳＩＰクライアント５０３は、ユーザからの要求に応じて図６（ａ）に示した登録情報更新要求を作成し、作成した登録情報更新要求をＣＭＳ３００へ送信する（Ｓ４００）。ＣＭＳ３００のＳＩＰメッセージ制御部３０４は、ＵＳ５００から受信した登録情報更新要求に基づいて図６（ｃ）に示した登録情報更新要求を作成し、作成した登録情報更新要求をＡＣＳ１００へ送信する（Ｓ４０１）。
【０１５２】
ＡＣＳ１００の認可判定要求部１０４は、ＣＭＳ３００から受信した登録情報更新要求をＰＭＳ２００へ転送する（Ｓ４０２）。ＰＭＳ２００の情報管理部２０３は、ＡＣＳ１００から受信した登録要求更新要求に含まれているユーザＩＤに対応するユーザ属性情報格納部２０２内のユーザ属性情報を、当該登録情報更新要求に含まれているユーザ属性情報で更新する（Ｓ４０３）。そして、情報管理部２０３は、図６（ｄ）に示した登録情報更新応答を作成し、作成した登録情報更新応答をＡＣＳ１００へ送信する（Ｓ４０４）。
【０１５３】
次に、ＡＣＳ１００の認可判定要求部１０４は、ステップＳ４０１で受信した登録情報更新要求に含まれているユーザＩＤが認可情報格納部１０３に格納されているか否かを判定する（Ｓ４０５）。当該ユーザＩＤが認可情報格納部１０３に格納されていない場合（Ｓ４０５：Ｎｏ）、認可判定要求部１０４は、ステップＳ４１３に示す処理を実行する。
【０１５４】
ステップＳ４０１で受信した登録情報更新要求に含まれているユーザＩＤが認可情報格納部１０３に格納されている場合（Ｓ４０５：Ｙｅｓ）、認可判定要求部１０４は、当該ユーザＩＤに対応付けられているサービスＩＤを認可情報格納部１０３から抽出し、抽出したそれぞれのサービスＩＤについて、図６（ｅ）に示した認可情報削除要求を作成し、作成した認可情報削除要求を送信する（Ｓ４０６、Ｓ４０９）。本例では、ＳＰ６００−αとＳＰ６００−βにはサービスの提供を許可する旨を示す認可情報が既に渡されており、ＳＰ６００−γにはサービスの提供を許可する旨を示す認可情報が渡されていないものとする。
【０１５５】
ＳＰ６００−αおよびＳＰ６００−βのそれぞれのＳＩＰクライアント６０３は、通信管理テーブル格納部６０４を参照して、ＡＣＳ１００から受信した認可情報削除要求に含まれているユーザＩＤに対応するレコードを通信管理テーブル６０４０から全て削除する（Ｓ４０７、Ｓ４１０）。そして、ＳＩＰクライアント６０３は、図６（ｆ）に示した認可情報削除応答を作成し、作成した認可情報削除応答をＡＣＳ１００へ送信する（Ｓ４０８、Ｓ４１１）。
【０１５６】
次に、ＡＣＳ１００の認可判定要求部１０４は、ステップＳ４０１で受信した登録情報更新要求に含まれているユーザＩＤを含むレコードを認可情報格納部１０３から全て削除し（Ｓ４１２）、ステップＳ４０４で受信した登録情報更新応答をＣＭＳ３００へ転送する（Ｓ４１３）。ＣＭＳ３００のＳＩＰメッセージ制御部３０４は、ＡＣＳ１００から受信した登録情報更新応答に基づいて、図６（ｂ）に示した登録情報更新応答を作成し、作成した登録情報更新応答をＵＳ５００へ送信する（Ｓ４１４）。
【０１５７】
以上、本発明の第２実施例について説明した。本実施例のアクセス認可システム１０においても、ユーザから要求されたサービスの提供開始までのユーザの待ち時間を少なくすることができる。
【０１５８】
また、本実施例において、ＡＣＳ１００は、事前に行った認可判定の結果を、その認可判定結果を使用するＳＰ６００へ即座に送信する。これにより、ＡＣＳ１００からＣＭＳ３００へ送信される認可情報取得応答、および、ＣＭＳ３００からＳＰ６００へ送信される通信開始要求内に認可情報を記述する必要がない。そのため、ユーザからサービスの提供を要求されてから送受信される認可情報取得応答および通信開始要求のデータ量を少なくすることができる。従って、アクセス認可システム１０は、ユーザからサービスの提供を要求されてからのデータ通信にかかる時間を少なくすることができ、サービス提供開始までのユーザの待ち時間を少なくすることができる。
【０１５９】
＜実施例３＞
次に、本発明の第３実施例について説明する。本実施例のビジネスプロセス実行システム４０は、ＳＡＭＬによってアクセス制御を実現している複数のＷｅｂサービスをサービスシナリオに従って連携させることで１つのサービスを実現するものである。
【０１６０】
図２１は、第３実施例におけるビジネスプロセス実行システム４０の構成を例示するシステム構成図である。ビジネスプロセス実行システム４０は、ポリシ管理サーバ（ＰＭＳ）２００、認可サーバ（ＡｕＳ）４００、ユーザ端末（ＵＳ）５００、複数のサービス提供サーバ（ＳＰ）６００、サービス実行サーバ（ＳＥＳ）７００、および属性管理サーバ（ＡＳ）８００を備える。
【０１６１】
図２１に示すビジネスプロセス実行システム４０は、ユーザがＵＳ５００を介してＳＥＳ７００で提供されているサービスシナリオを利用する際に、ＳＥＳ７００がＡｕＳ４００と連携して当該ユーザに対して当該サービスシナリオに含まれるそれぞれのＷｅｂサービスの提供が許可されているか否かを判定する認可判定を行い、その結果に基づいてサービスシナリオに規定されている順番でそれぞれのＷｅｂサービスを順次呼び出す。
【０１６２】
次に、本実施例におけるビジネスプロセス実行システム４０の各構成要素が備える機能について説明する。なお、以下に説明する点を除き、図２１において、図１と同じ符号を付した構成は、図１における構成と同一または同様の機能を有するため説明を省略する。
【０１６３】
まず、ＳＥＳ７００について説明する。ＳＥＳ７００は、シナリオ格納部７０１、プロセス情報格納部７０２、シナリオ実行部７０３、および通信部７０４を備える。通信部７０４は、シナリオ実行部７０３からの指示に応じて、ネットワーク１１を介して他の装置と通信を行う。
【０１６４】
シナリオ格納部７０１には、例えば図２２に示すように、サービスシナリオ７０１１を、それぞれのサービスシナリオを識別するシナリオＩＤ７０１０に対応付けて格納している。ここで、サービスシナリオとは、例えば図２３に示すようにＸＭＬ形式で記述され、１つ以上のＳＰ６００で提供されているＷｅｂサービスをどの順序で連携させていくかを規定するものである。
【０１６５】
図２３には、シナリオＩＤが「Scenario1」であるサービスシナリオ５０が例示されている。図２３のサービスシナリオ５０には、それぞれのＷｅｂサービスを識別するサービスＩＤが「SpAlpha」であるＷｅｂサービスを実行した後に（記述５３参照）、サービスＩＤが「SpBeta」であるＷｅｂサービスが実行可能であれば（記述５５参照）、サービスＩＤが「SpBeta」であるＷｅｂサービスを実行し（記述５６参照）、さもなければサービスＩＤが「SpGamma」であるＷｅｂサービスを実行する（記述５８参照）という連携順序が規定されている。
【０１６６】
プロセス情報格納部７０２には、例えば図２４に示すように、それぞれのビジネスプロセスを識別するプロセスＩＤ７０２０に対応付けて、実行中のサービスシナリオのシナリオＩＤ７０２１、実行中のＷｅｂサービスのサービスＩＤを示す現在実行点７０２２、および実行が禁止されているＷｅｂサービスのサービスＩＤを示す禁止サービス７０２３が格納されている。図２４に示したプロセス情報格納部７０２において、プロセスＩＤが「１」のビジネスプロセスでは、シナリオＩＤが「Scenario1」であるサービスシナリオが実行中であり、その中でサービスＩＤが「SpAlpha」であるＷｅｂサービスが実行中であり、サービスＩＤが「SpGamma」であるＷｅｂサービスの実行が禁止されていることを示す情報等が格納されている。
【０１６７】
シナリオ実行部７０３は、通信部７０４を介してＵＳ５００から、ユーザＩＤおよびシナリオＩＤを含むサービス要求を受信した場合に、プロセスＩＤを生成し、生成したプロセスＩＤに対応付けて、当該シナリオＩＤをプロセス情報格納部７０２に登録する（このとき、現在実行点および禁止サービスの欄は空欄となる）。そして、シナリオ実行部７０３は、当該シナリオＩＤに対応するサービスシナリオをシナリオ格納部７０１から抽出して、当該サービスシナリオに実行順番が規定されているそれぞれのＷｅｂサービスのサービスＩＤを抽出する。そして、シナリオ実行部７０３は、例えば図２５（ａ）に示すような認可判定要求６０を生成し、生成した認可判定要求６０を通信部７０４を介してＡｕＳ４００へ送信する。
【０１６８】
認可判定要求６０には、例えば図２５（ａ）に示すように、それぞれの認可判定要求６０を識別する識別子（記述６１参照）と、認可判定の対象となるサービスシナリオに関する情報（記述６２参照）、および、当該サービスシナリオに含まれる１つ以上のＷｅｂサービスに関する情報（記述６３から記述６５参照）が含まれる。認可判定要求６０を識別する識別子には、例えばプロセスＩＤが用いられる。
【０１６９】
図２５（ａ）において、記述６２には、対象となるサービスシナリオのシナリオＩＤである「Scenario1」と、当該サービスシナリオに対する認可判定の対象となるユーザのユーザＩＤである「User1」とが記述されており、記述６３には、対象となるＷｅｂサービスのサービスＩＤである「SpAlpha」と、当該Ｗｅｂサービスに対する認可判定の対象となるユーザのユーザＩＤである「User1」とが記述されており、記述６４には、対象となるＷｅｂサービスのサービスＩＤである「SpBeta」と、当該Ｗｅｂサービスに対する認可判定の対象となるユーザのユーザＩＤである「User1」とが記述されており、記述６５には、対象となるＷｅｂサービスのサービスＩＤである「SpGamma」と、当該Ｗｅｂサービスに対する認可判定の対象となるユーザのユーザＩＤである「User1」とが記述されている。
【０１７０】
シナリオ実行部７０３は、認可判定要求６０に対する応答として、例えば図２５（ｂ）に示すような認可判定結果７０を、通信部７０４を介してＡｕＳ４００から受信する。認可判定結果７０には、それぞれの認可判定結果７０を識別する識別子（記述７１参照）と、認可判定の対象となるサービスシナリオに関する認可判定結果（記述７２参照）、および、当該サービスシナリオに含まれる１つ以上のＷｅｂサービスに関する認可判定結果（記述７３から記述７５参照）が含まれる。認可判定結果７０を識別する識別子には、対応する認可判定要求６０の識別情報が記述される。
【０１７１】
図２５（ｂ）に示した例おいて、記述７２には、対象となるサービスシナリオのシナリオＩＤである「Scenario1」と、当該サービスシナリオに対する認可判定結果が許可（Permit）である旨とが記述されており、記述７３には、対象となるＷｅｂサービスのサービスＩＤである「SpAlpha」と、当該Ｗｅｂサービスに対する認可判定結果が許可（Permit）である旨とが記述されており、記述７４には、対象となるＷｅｂサービスのサービスＩＤである「SpBeta」と、当該Ｗｅｂサービスに対する認可判定結果が許可（Permit）である旨とが記述されており、記述７５には、対象となるＷｅｂサービスのサービスＩＤである「SpGamma」と、当該Ｗｅｂサービスに対する認可判定結果が拒否（Deny）である旨とが記述されている。
【０１７２】
シナリオ実行部７０３は、ＡｕＳ４００から認可判定結果７０を受信した場合に、受信した認可判定結果７０に基づいて例えば図２６および図２７に示す禁止サービス登録処理を実行することにより、ユーザから要求されたサービスシナリオに含まれるそれぞれのサービスについて、禁止サービスとして登録すべきか否かを判定し、禁止サービスとして登録すべきと判定されたサービスのサービスＩＤを、プロセスＩＤに対応付けてプロセス情報格納部７０２に登録する。
【０１７３】
図２６において、まず、シナリオ実行部７０３は、ユーザから指定されたサービスシナリオが許可されているか否かを判定する（Ｓ５００）。ユーザから指定されたサービスシナリオが許可されていない場合（Ｓ５００：Ｎｏ）、シナリオ実行部７０３は、当該サービスシナリオに規定されている最初のＷｅｂサービスを禁止サービスとしてプロセスＩＤに対応付けてプロセス情報格納部７０２に登録し（Ｓ５０５）、シナリオ実行部７０３は、本フローチャートに示す処理を終了する。
【０１７４】
ユーザから指定されたサービスシナリオが許可されている場合（Ｓ５００：Ｙｅｓ）、シナリオ実行部７０３は、当該サービスシナリオに規定されている最初のＷｅｂサービスが許可されているか否かを判定する（Ｓ５０１）。最初のＷｅｂサービスが許可されていない場合（すなわち、認可判定結果が拒否である場合）（Ｓ５０１：Ｎｏ）、シナリオ実行部７０３は、ステップＳ５０５に示した処理を実行する。
【０１７５】
最初のＷｅｂサービスが許可されている場合（Ｓ５０１：Ｙｅｓ）、シナリオ実行部７０３は、ユーザから指定されたサービスシナリオに基づいて、次に提供されるべきＷｅｂサービスを特定し、当該次に提供されるべきＷｅｂサービスの中で、許可されているＷｅｂサービスが少なくとも１つ存在するか否かを判定する（Ｓ５０２）。次に提供されるべきＷｅｂサービスが全て許可されていない場合（Ｓ５０２：Ｎｏ）、シナリオ実行部７０３は、ステップＳ５０５に示した処理を実行する。
【０１７６】
次に提供されるべきＷｅｂサービスの少なくとも１つが許可されている場合（Ｓ５０２：Ｙｅｓ）シナリオ実行部７０３は、次に提供されるべきＷｅｂサービスの中で、許可されていないサービスがあればそのサービスのサービスＩＤを禁止サービスとしてプロセスＩＤに対応付けてプロセス情報格納部７０２に登録する（Ｓ５０３）。そして、シナリオ実行部７０３は、許可されている次のＷｅｂサービスについて後述する禁止判定処理を実行する（Ｓ６００）。
【０１７７】
次に、シナリオ実行部７０３は、次に提供されるべき全てのＷｅｂサービスが禁止サービスとしてプロセス情報格納部７０２に登録されているか否かを判定する（Ｓ５０４）。次に提供されるべき全てのＷｅｂサービスが禁止サービスとしてプロセス情報格納部７０２に登録されている場合（Ｓ５０４：Ｙｅｓ）、シナリオ実行部７０３は、ステップＳ５０５に示した処理を実行する。一方、次に提供されるべき少なくとも１つのＷｅｂサービスが禁止サービスとしてプロセス情報格納部７０２に登録されていない場合（Ｓ５０４：Ｎｏ）、シナリオ実行部７０３は、本フローチャートに示した処理を終了する。
【０１７８】
図２７は、シナリオ実行部７０３によって実行される禁止判定処理（Ｓ６００）の一例を示すフローチャートである。
【０１７９】
まず、シナリオ実行部７０３は、許可されている次のＷｅｂサービスの中で、未選択のＷｅｂサービスを１つ選択し（Ｓ６０１）、ユーザから指定されたサービスシナリオを参照して、選択したＷｅｂサービスの次に提供されるべきＷｅｂサービスが存在するか否かを判定する（Ｓ６０２）。選択したＷｅｂサービスの次に提供されるべきＷｅｂサービスが存在しない場合（Ｓ６０２：Ｎｏ）、シナリオ実行部７０３は、ステップＳ６０６に示す処理を実行する。
【０１８０】
選択したＷｅｂサービスの次に提供されるべきＷｅｂサービスが存在する場合（Ｓ６０２：Ｙｅｓ）、シナリオ実行部７０３は、ユーザから指定されたサービスシナリオに基づいて、ステップＳ６０１において選択されたＷｅｂサービスの次に提供されるべきＷｅｂサービスを特定し、当該次に提供されるべきＷｅｂサービスの中で、許可されているＷｅｂサービスが少なくとも１つ存在するか否かを判定する（Ｓ６０３）。
【０１８１】
次に提供されるべきＷｅｂサービスが全て許可されていない場合（Ｓ６０３：Ｎｏ）、シナリオ実行部７０３は、ステップＳ６０１において選択されたＷｅｂサービスのサービスＩＤを禁止サービスとしてプロセスＩＤに対応付けてプロセス情報格納部７０２に登録し（Ｓ６０５）、ステップＳ６０６に示す処理を実行する。
【０１８２】
次に提供されるべきＷｅｂサービスの中で、許可されているＷｅｂサービスが少なくとも１つ存在する場合（Ｓ６０３：Ｙｅｓ）、シナリオ実行部７０３は、許可されている次のＷｅｂサービスについて禁止判定処理を再帰呼び出しにより実行する（Ｓ６００）。そして、シナリオ実行部７０３は、ステップＳ６０１において選択されたＷｅｂサービスの次に提供されるべき全てのＷｅｂサービスが禁止サービスとしてプロセス情報格納部７０２に登録されているか否かを判定する（Ｓ６０４）。
【０１８３】
ステップＳ６０１において選択されたＷｅｂサービスの次に提供されるべき全てのＷｅｂサービスが禁止サービスとしてプロセス情報格納部７０２に登録されている場合（Ｓ６０４：Ｙｅｓ）、シナリオ実行部７０３は、ステップＳ６０５に示した処理を実行する。一方、ステップＳ６０１において選択されたＷｅｂサービスの次に提供されるべきＷｅｂサービスの少なくとも１つが、禁止サービスとしてプロセス情報格納部７０２に登録されていない場合（Ｓ６０４：Ｎｏ）、シナリオ実行部７０３は、許可されているＷｅｂサービスがステップＳ６０１において全て選択されたか否かを判定する（Ｓ６０６）。
【０１８４】
許可されているＷｅｂサービスがステップＳ６０１において全て選択されていない場合（Ｓ６０６：Ｎｏ）、シナリオ実行部７０３は、再びステップＳ６０１に示した処理を実行する。一方、許可されているＷｅｂサービスがステップＳ６０１において全て選択された場合（Ｓ６０６：Ｙｅｓ）、シナリオ実行部７０３は、本フローチャートに示した禁止判定処理を終了する。
【０１８５】
図２６および図２７に示した処理を実行した後、シナリオ実行部７０３は、プロセス情報格納部７０２を参照して、ユーザから要求されたサービスシナリオに規定されている最初のＷｅｂサービスが禁止サービスとしてプロセス情報格納部７０２に登録されていない場合に、当該最初のＷｅｂサービスを提供するＳＰ６００に対して、当該ＷｅｂサービスのサービスＩＤおよび当該Ｗｅｂサービスの提供対象となるユーザのユーザＩＤを含むサービス呼出を送信することにより、ユーザに一連のビジネスプロセスの提供を開始する。そして、シナリオ実行部７０３は、プロセス情報格納部７０２の現在実行点に、最初のＷｅｂサービスのサービスＩＤを登録する。なお、最初のＷｅｂサービスが禁止サービスとしてプロセス情報格納部７０２に登録されている場合、シナリオ実行部７０３は、指定されたサービスシナリオが実行できない旨をＵＳ５００に通知する。
【０１８６】
また、シナリオ実行部７０３は、ユーザから指定されたサービスシナリオに従って、順次ＷｅｂサービスをＳＰ６００に実行させる過程で、一連のビジネスプロセスの状態を示す情報を管理する。そして、サービスシナリオに従って、現在提供されているＷｅｂサービスの次に提供されるべきＷｅｂサービスが異なる分岐が存在する場合、シナリオ実行部７０３は、一連のビジネスプロセスの状態を示す情報に応じて、次に提供されるべきＷｅｂサービスを特定し、特定したＷｅｂサービスをＳＰ６００に実行させる。
【０１８７】
なお、一連のビジネスプロセスの状態を示す情報に応じて特定した、次に提供されるべきＷｅｂサービスが、禁止サービスとしてプロセス情報格納部７０２に登録されている場合、シナリオ実行部７０３は、Ｗｅｂサービスの提供が許可されてない旨と共に当該Ｗｅｂサービスに関する情報をＵＳ５００に通知する。これにより、シナリオ実行部７０３は、ＵＳ５００のユーザが、それ以降のＷｅｂサービスの提供を無駄に受けることを防止することができる。
【０１８８】
次に、ＡｕＳ４００について説明する。ＡｕＳ４００は、認可判定部４０１および通信部４０２を備える。認可判定部４０１は、通信部４０２を介してＳＥＳ７００から図２５（ａ）に示した認可判定要求６０を受信した場合に、当該認可判定要求６０に含まれているシナリオＩＤおよびサービスＩＤのそれぞれについて、例えば図２８（ｃ）に示すようなポリシ取得要求８２を作成し、作成したポリシ取得要求８２を通信部４０２を介してＰＭＳ２００へ送信する。図２８（ｃ）には、サービスシナリオに関するポリシを要求するポリシ取得要求８２が示されている。
【０１８９】
そして、通信部４０２を介してＰＭＳ２００から、例えば図２８（ｄ）に示すようなポリシ取得応答８３を受信した場合、認可判定部４０１は、当該ポリシ取得応答８３に示されているユーザのパラメータ（図２８（ｄ）の例では年齢）、および、ＳＥＳ７００から受信した認可判定要求６０に含まれているユーザＩＤを含む属性取得要求を作成し、作成した属性取得要求を通信部４０２を介してＡＳ８００へ送信する。本実施例において、属性取得要求は、例えば図２８（ａ）に示すようなデータ構造である。
【０１９０】
そして、通信部４０２を介してＡＳ８００から、例えば図２８（ｂ）に示すような属性取得応答８１を受信した場合、認可判定部４０１は、認可判定要求６０で指定されたシナリオＩＤに対応するサービスシナリオおよびサービスＩＤに対応するＷｅｂサービスのそれぞれについて、属性取得応答８１に含まれているユーザの属性が、ポリシ取得応答８３に含まれているサービスポリシを満たしているか否かを判定する認可判定を実行する。
【０１９１】
そして、認可判定部４０１は、図２５（ｂ）で説明した認可判定結果７０を作成し、作成した認可判定結果７０を通信部４０２を介してＳＥＳ７００へ送信する。また、認可判定部４０１は、それぞれのサービスＩＤにおいて、認可判定の結果が「許可」であるものについて、当該認可判定の結果を、対象となるユーザのユーザＩＤと共に、当該サービスＩＤに対応するＷｅｂサービスを提供するＳＰ６００に通知する。
【０１９２】
なお、本実施例では、１つの属性取得要求８０において１人のユーザのユーザ属性情報を要求するようにしているが、他の例として、１つの属性取得要求８０で複数のユーザのユーザ属性情報を要求するようにしてもよい。具体的には、属性取得要求８０内にユーザ毎にAttributeQueryタグを作成すればよい。また、本実施例では、１つのポリシ取得要求８２において１つのＷｅｂサービスのサービスポリシ情報を要求するようにしているが、他の例として、１つのポリシ取得要求８２で複数のＷｅｂサービスのサービスポリシ情報を要求するようにしてもよい。具体的には、ポリシ取得要求８２内にＷｅｂサービス毎にAttributeQueryタグを作成すればよい。このようにすることで、ＡｕＳ４００とＰＭＳ２００間の通信トラフィックを低減することができる。
【０１９３】
次に、ＰＭＳ２００について説明する。ＰＭＳ２００は、サービスポリシ情報格納部２０１、通信部２０４、シナリオポリシ情報格納部２０５、およびポリシ情報管理部２０６を備える。サービスポリシ情報格納部２０１には、図１０で説明した構造のデータが格納されている。シナリオポリシ情報格納部２０５には、例えば図２９に示すように、シナリオＩＤ２０５０に対応付けて、当該シナリオＩＤ２０５０に対応するサービスシナリオのシナリオポリシ情報の実体が格納されているＰＭＳ２００のメモリ内の場所を示す参照先アドレス２０５１が格納されている。
【０１９４】
ポリシ情報管理部２０６は、通信部２０４を介してＡｕＳ４００から図２８（ｃ）に示したポリシ取得要求８２を受信した場合に、当該ポリシ取得要求８２にサービスＩＤが格納されているならば、当該サービスＩＤに対応するサービスポリシ情報をサービスポリシ情報格納部２０１を参照して取得し、当該ポリシ取得要求８２にシナリオＩＤが格納されているならば、当該シナリオＩＤに対応するシナリオポリシ情報をシナリオポリシ情報格納部２０５を参照して取得する。そして、ポリシ情報管理部２０６は、取得したサービスポリシ情報またはシナリオポリシ情報を含むポリシ取得応答８３を作成し、作成したポリシ取得応答８３を通信部２０４を介してＡｕＳ４００へ送信する。
【０１９５】
次に、ＡＳ８００について説明する。ＡＳ８００は、ユーザ属性情報格納部８０１、属性情報管理部８０２、および通信部８０３を備える。通信部８０３は、属性情報管理部８０２からの指示に応じて、ネットワーク１１を介して他の装置と通信を行う。ユーザ属性情報格納部８０１には、例えば図１１で説明した構造のデータが格納されている。
【０１９６】
属性情報管理部８０２は、通信部８０３を介してＡｕＳ４００から図２８（ａ）に示した属性取得要求８０を受信した場合に、当該属性取得要求８０に格納されているユーザＩＤに対応するユーザ属性情報をユーザ属性情報格納部８０１から抽出する。そして、属性情報管理部８０２は、抽出したユーザ属性情報を含む属性取得応答８１を作成し、作成した属性取得応答８１を通信部８０３を介してＡｕＳ４００へ送信する。
【０１９７】
次に、ＳＰ６００について説明する。ＳＰ６００は、通信部６０１、サービスアプリケーション６０２、認可判定取得部６０６、および認可判定結果格納部６０７を備える。
【０１９８】
認可判定取得部６０６は、通信部６０１を介してＡｕＳ４００から、認可判定の結果が「許可」であるユーザのユーザＩＤを受信した場合に、受信したユーザＩＤを認可判定結果格納部６０７に格納する。なお、ＳＰ６００によって提供可能なＷｅｂサービスが複数存在する場合、ＡｕＳ４００は、ユーザＩＤおよび「許可」である認可判定の結果と共に、対象となるＷｅｂサービスのサービスＩＤをＳＰ６００へ送信し、認可判定取得部６０６は、認可判定の結果が「許可」であるユーザのユーザＩＤを、対象となるサービスのサービスＩＤと共に認可判定結果格納部６０７に格納する。
【０１９９】
サービスアプリケーション６０２は、通信部６０１を介してＳＥＳ７００からサービス呼出を受信した場合に、当該サービス呼出に含まれているユーザＩＤが認可判定結果格納部６０７に格納されているか否かを判定し、当該ユーザＩＤが認可判定結果格納部６０７に格納されている場合に、当該ユーザＩＤに対応するユーザに対してＷｅｂサービスの提供が許可されているものと判定し、当該ユーザＩＤに対応するユーザに対してＷｅｂサービスを提供する。
【０２００】
次に、第３実施例において、ユーザの要求に応じてＷｅｂサービスの提供が開始される場合のビジネスプロセス実行システム４０の一連の動作について図３０を用いて説明する。
【０２０１】
まず、ＵＳ５００の通信アプリケーション５０２は、ユーザからの要求に応じてサービス要求を作成し、作成したサービス要求を通信部５０１を介してＳＥＳ７００へ送信する（Ｓ７００）。ＳＥＳ７００のシナリオ実行部７０３は、通信部７０４を介してサービス要求を受信した場合に、プロセスＩＤを生成し、生成したプロセスＩＤに対応付けて、当該サービス要求に含まれているシナリオＩＤをプロセス情報格納部７０２に登録する。そして、シナリオ実行部７０３は、当該シナリオＩＤに対応するサービスシナリオをシナリオ格納部７０１から取得して（Ｓ７０１）、当該サービスシナリオに実行順番が規定されているそれぞれのＷｅｂサービスのサービスＩＤを抽出する。そして、シナリオ実行部７０３は、例えば図２５（ａ）に示した認可判定要求６０を生成し、生成した認可判定要求６０を通信部７０４を介してＡｕＳ４００へ送信する（Ｓ７０２）。
【０２０２】
次に、ＡｕＳ４００の認可判定部４０１は、通信部４０２を介してＳＥＳ７００から図２５（ａ）に示した認可判定要求６０を受信した場合に、後述する認可判定処理を実行する（Ｓ８００）。そして、認可判定部４０１は、図２５（ｂ）で説明した認可判定結果７０を作成し、作成した認可判定結果７０を通信部４０２を介してＳＥＳ７００へ送信する（Ｓ７０３）。そして、認可判定部４０１は、それぞれのサービスＩＤにおいて、認可判定の結果が「許可」であるものについて、当該認可判定の結果を、対象となるユーザのユーザＩＤと共に、当該サービスＩＤに対応するＷｅｂサービスを提供するＳＰ６００に通知する（Ｓ７０４）。それぞれのＳＰ６００の認可判定取得部６０６は、通信部６０１を介してＡｕＳ４００から受信した、認可判定の結果が「許可」であるユーザのユーザＩＤを認可判定結果格納部６０７に格納する（Ｓ７０５）。
【０２０３】
次に、ＳＥＳ７００のシナリオ実行部７０３は、ＡｕＳ４００から受信した認可判定結果に基づいて、図２６および図２７において説明した禁止サービス登録処理を実行する（Ｓ７０６）。そして、シナリオ実行部７０３は、プロセス情報格納部７０２を参照して、ユーザから要求されたサービスシナリオに規定されている最初のＷｅｂサービスが禁止サービスとしてプロセス情報格納部７０２に登録されているか否かを判定する（Ｓ７０７）。
【０２０４】
最初のＷｅｂサービスが禁止サービスとしてプロセス情報格納部７０２に登録されている場合（Ｓ７０７：Ｙｅｓ）、シナリオ実行部７０３は、指定されたサービスシナリオが実行できない旨を示すエラー通知をＵＳ５００へ送信する（Ｓ７０８）。一方、最初のＷｅｂサービスが禁止サービスとしてプロセス情報格納部７０２に登録されていない場合（Ｓ７０７：Ｎｏ）、シナリオ実行部７０３は、当該最初のＷｅｂサービスを提供するＳＰ６００αに対して、当該ＷｅｂサービスのサービスＩＤおよび当該Ｗｅｂサービスの提供対象となるユーザのユーザＩＤを含むサービス呼出を送信する（Ｓ７０９）。そして、シナリオ実行部７０３は、プロセス情報格納部７０２の現在実行点に、最初のＷｅｂサービスのサービスＩＤを登録する。
【０２０５】
次に、ＳＰ６００αのサービスアプリケーション６０２は、受信したサービス呼出に含まれているユーザＩＤが認可判定結果格納部６０７に格納されている場合に、当該ユーザＩＤに対応するユーザに対してＷｅｂサービスの提供が許可されているものと判定し、当該ユーザＩＤに対応するユーザのＵＳ５００に対してＷｅｂサービスを提供する（Ｓ７１０）。
【０２０６】
そして、Ｗｅｂサービスの提供が終了した場合、サービスアプリケーション６０２は、提供されたＷｅｂサービスの実行結果を示す情報と共に、当該Ｗｅｂサービスの提供が終了した旨をＳＥＳ７００に通知する（Ｓ７１１）。ＳＥＳ７００のシナリオ実行部７０３は、Ｗｅｂサービスの実行結果を示す情報に基づいて一連のビジネスプロセスの状態を示す情報を更新する。そして、シナリオ実行部７０３は、ユーザから指定されたサービスシナリオを参照して、次に提供されるべきＷｅｂサービスが存在するか否かを判定する（Ｓ７１２）。次に提供されるべきＷｅｂサービスが存在しない場合（Ｓ７１２：Ｎｏ）、シナリオ実行部７０３は、ビジネスプロセスの終了をユーザのＵＳ５００に通知する（Ｓ７１３）。
【０２０７】
次に提供すべきＷｅｂサービスが存在する場合（Ｓ７１２：Ｙｅｓ）、シナリオ実行部７０３は、当該次に提供すべきＷｅｂサービスを提供するＳＰ６００αに対して、当該ＷｅｂサービスのサービスＩＤおよび当該Ｗｅｂサービスの提供対象となるユーザのユーザＩＤを含むサービス呼出を送信する（Ｓ７１４）。そして、シナリオ実行部７０３は、プロセス情報格納部７０２の現在実行点に、当該次に提供すべきＷｅｂサービスのサービスＩＤを登録する。
【０２０８】
ＳＰ６００αのサービスアプリケーション６０２は、受信したサービス呼出に含まれているユーザＩＤが認可判定結果格納部６０７に格納されている場合に、当該ユーザＩＤに対応するユーザのＵＳ５００に対してＷｅｂサービスを提供する（Ｓ７１６）。そして、Ｗｅｂサービスの提供が終了した場合に、サービスアプリケーション６０２は、提供されたＷｅｂサービスの実行結果を示す情報と共に、当該Ｗｅｂサービスの提供が終了した旨をＳＥＳ７００に通知する（Ｓ７１１）。ＳＥＳ７００のシナリオ実行部７０３は、Ｗｅｂサービスの実行結果を示す情報に基づいて一連のビジネスプロセスの状態を示す情報を更新し、再びステップＳ７１２に示した処理を実行する。
【０２０９】
図３１は、認可判定処理（Ｓ８００）の一例を示すシーケンス図である。
【０２１０】
まず、ＡｕＳ４００の認可判定部４０１は、通信部４０２を介してＳＥＳ７００から図２５（ａ）に示した認可判定要求６０を受信した場合に、当該認可判定要求６０に含まれているシナリオＩＤおよびサービスＩＤのそれぞれについて、例えば図２８（ｃ）に示すようなポリシ取得要求８２を作成し、作成したポリシ取得要求８２を通信部４０２を介してＰＭＳ２００へ送信する（Ｓ８０１）。
【０２１１】
ＰＭＳ２００のポリシ情報管理部２０６は、通信部２０４を介してＡｕＳ４００から受信したポリシ取得要求８２にサービスＩＤが含まれている場合にはサービスポリシ情報格納部２０１を参照して対応するサービスポリシ情報を取得し、ポリシ取得要求８２にシナリオＩＤが含まれている場合にはシナリオポリシ情報格納部２０５を参照して対応するシナリオポリシ情報を取得する（Ｓ８０２）。そして、ポリシ情報管理部２０６は、取得したサービスポリシ情報またはシナリオポリシ情報を含むポリシ取得応答８３を作成し、作成したポリシ取得応答８３を通信部２０４を介してＡｕＳ４００へ送信する（Ｓ８０３）。
【０２１２】
ＡｕＳ４００の認可判定部４０１は、通信部４０２を介してＰＭＳ２００から受信したポリシ取得応答８３の内容を解析して、ポリシ取得応答８３に示されているユーザのパラメータおよびＳＥＳ７００から受信した認可判定要求６０に含まれているユーザＩＤを含む属性取得要求８０を作成し、作成した属性取得要求８０を通信部４０２を介してＡＳ８００へ送信する（Ｓ８０５）。
【０２１３】
ＡＳ８００の属性情報管理部８０２は、通信部８０３を介してＡｕＳ４００から受信した属性取得要求８０に格納されているユーザＩＤに対応するユーザ属性情報をユーザ属性情報格納部８０１から取得する。そして、属性情報管理部８０２は、取得したユーザ属性情報を含む属性取得応答８１を作成し、作成した属性取得応答８１を通信部８０３を介してＡｕＳ４００へ送信する（Ｓ８０７）。
【０２１４】
ＡｕＳ４００の認可判定部４０１は、認可判定要求６０で指定されたシナリオＩＤに対応するサービスシナリオおよびサービスＩＤに対応するＷｅｂサービスのそれぞれについて、ＡＳ８００から受信した属性取得応答８１に含まれているユーザの属性が、ポリシ取得応答８３に含まれているサービスポリシを満たしているか否かを判定する認可判定を実行する（Ｓ８０８）。
【０２１５】
以上、本発明の第３実施例について説明した。本実施例のビジネスプロセス実行システム４０によれば、ＳＰ６００で提供されているＷｅｂサービスの認可判定は、ＳＥＳ７００がＵＳ５００からサービス要求を受信してから、ＳＥＳ７００がＳＰ６００を呼び出すまでの間に行われる。また、ＡｕＳ４００は、認可判定を行った後にその結果をＳＰ６００へ送信し、ＳＰ６００がその結果を保存する。これにより、ＳＰ６００が呼び出された後に認可判定処理を行う必要がなく、ユーザの待ち時間を少なくすることができる。
【０２１６】
また、本実施例のビジネスプロセス実行システム４０では、ＳＥＳ７００がＵＳ５００から要求されたサービスシナリオに含まれるＷｅｂサービスを列挙して、認可判定をＡｕＳ４００に要求する。また、ＡｕＳ４００は認可判定結果をＳＰ６００へ送信し、ＳＰ６００が認可判定結果を保存する。すなわち、ＳＰ６００が保存している認可判定結果は、ＳＥＳ７００が実行しようとしているサービスシナリオに関係したものであるため、比較的短時間でＳＰ６００にＷｅｂサービスの呼び出しが行われる可能性が高く、認可判定結果を無駄に保存することを少なくすることができる。
【０２１７】
なお、上記した実施例におけるＡＣＳ１００、ＰＭＳ２００、ＣＭＳ３００、ＡｕＳ４００、ＵＳ５００、ＳＰ６００、ＳＥＳ７００、またはＡＳ８００は、例えば図３２に示すような構成のコンピュータ２０によって実現される。
【０２１８】
コンピュータ２０は、ＣＰＵ２１と、メモリ２２と、インターネットやＬＡＮ等のネットワーク１１を介して他のコンピュータ２０と通信を行うための通信装置２４と、キーボードやマウス等の入力装置を接続する入力インターフェイス２５と、モニタやプリンタ等の出力装置を接続する出力インターフェイス２６と、読取装置２７と、ハードディスク等の外部記憶装置２３とを備え、これらの各構成要素はバス２８を介して互いに接続されている。また、読取装置２７にはＩＣカードやＵＳＢメモリのような、可搬性を有する記憶媒体２９を接続することができる。
【０２１９】
コンピュータ２０は、ＡＣＳ１００、ＰＭＳ２００、ＣＭＳ３００、ＡｕＳ４００、ＵＳ５００、およびＳＰ６００の中のいずれか１つの装置として機能する。コンピュータ２０は、当該いずれか１つの装置の機能を実現するプログラムをメモリ２２にロードし、当該プログラムをＣＰＵ２１により実行することで、対応する装置の機能を実現する。これらのプログラムは、予め外部記憶装置２３に格納されていてもよく、必要なときに、読取装置２７または通信装置２４により当該コンピュータ２０が利用可能な媒体を介して、他の装置から取得されて外部記憶装置２３に格納されてもよい。
【０２２０】
媒体とは、例えば、読取装置２７に着脱可能な記憶媒体２９、または、通信装置２４に接続されているネットワーク１１またはネットワーク１１を伝搬する搬送波やディジタル信号を指す。そして、これらのプログラムは、一旦外部記憶装置２３に格納された後、そこからメモリ２２上にロードされてＣＰＵ２１に実行されてもよく、あるいは外部記憶装置２３に格納されることなく、直接メモリ２２上にロードされて、ＣＰＵ２１により実行されてもよい。
【０２２１】
また、上記した第１または第２実施例において、次サービスＩＤ特定部１０２は、現在提供されているサービスの１つ次に提供されるべきサービスのサービスＩＤを特定したが、他の例として、次サービスＩＤ特定部１０２は、現在提供されているサービスを含むワークフローにおいて、当該サービスの後に実行されるべき全てのサービスのサービスＩＤを全て特定して認可判定要求部１０４に提供するようにしてもよい。
【０２２２】
また、上記した第２実施例において、次サービスＩＤ特定部１０２は、現在提供されているサービスの次に提供されたサービスの回数を用いて次に提供されるべきサービスを推定したが、これ以外にも、ユーザの過去のサービス利用履歴や属性情報等を基にしてよく知られたデータマイニング手法により、次に要求される可能性の高いサービスを推定するようにしてもよい。
【０２２３】
また、上記した第３実施例では、ＳＥＳ７００によって提供されるサービスシナリオ、および、ＳＰ６００によって提供されるＷｅｂサービスの認可判定をＡｕＳ４００が一元的に判定しているが、本発明はそのような構成に限定されない。例えば、それぞれのＳＰ６００が、当該ＳＰ６００で提供されているＷｅｂサービスについての認可判定を実行するようにしてもよい。すなわち、ＳＰ６００内に、ＡｕＳ４００の機能が組み込まれていてもよい。また、ＰＭＳ２００またはＡＳ８００の機能もそれぞれのＳＰ６００内に組み込まれていてもよい。
【０２２４】
ＳＰ６００が当該ＳＰ６００で提供されているＷｅｂサービスについての認可判定を実行するようにすれば、認可判定のために交換されるメッセージを少なくすることができ、ネットワークを効果的に利用することができる。このような構成においても、ＳＥＳ７００からＳＰ６００にＷｅｂサービスの呼び出しが行われる前に認可判定処理を行い、各ＳＰ６００が認可判定結果を保存しているため、実際にＷｅｂサービスの呼び出しが行われても認可判定処理を行う必要がなく、Ｗｅｂサービスの提供を迅速に開始することができる。
【０２２５】
ＳＰ６００内にＡｕＳ４００の機能を組み込んだ場合のビジネスプロセス実行システム４０の動作は例えば図３３のようになる。なお、以下に説明する点を除き、図３３において、図３０と同じ符号を付した処理は、図３０における処理と同様であるため説明を省略する。
【０２２６】
ＳＥＳ７００のシナリオ実行部７０３は、シナリオ格納部７０１から取得したサービスシナリオからサービスＩＤを抽出して、例えば図２５（ａ）に示した認可判定要求６０を生成する。そして、シナリオ実行部７０３は、生成した認可判定要求６０を、抽出したサービスＩＤに対応するＷｅｂサービスを提供するそれぞれのＳＰ６００へ送信する（Ｓ７２０）。なお、シナリオ実行部７０３は、シナリオＩＤを含む認可判定要求６０を、いずれかのＳＰ６００へ送信することにより、ユーザから指定されたサービスシナリオの認可判定をいずれかのＳＰ６００に実行させる。
【０２２７】
それぞれのＳＰ６００は、図３１で説明した認可判定処理（Ｓ８００）を実行した後に、図２５（ｂ）で説明した認可判定結果７０を作成し、作成した認可判定結果７０をＳＥＳ７００へ送信する（Ｓ７２１）。そして、それぞれのＳＰ６００は、認可判定の結果が「許可」である場合に、当該認可判定の結果を、対象となるユーザのユーザＩＤと共に、認可判定結果格納部６０７に格納する（Ｓ７２２）。
【０２２８】
また、上記した第３実施例において、シナリオ実行部７０３は、ＵＳ５００からサービス要求を受信した場合に、当該サービス要求に含まれているシナリオＩＤに対応するサービスシナリオに実行順番が規定されているＷｅｂサービスの認可判定を一括して実行するが、本発明はこれに限定されない。例えば、シナリオ実行部７０３は、ユーザから指定されたサービスシナリオおよび当該サービスシナリオに規定されている最初のＷｅｂサービスについてＡｕＳ４００に認可判定を実行させ、当該サービスシナリオおよび当該最初のＷｅｂサービスのいずれも許可されている場合に、当該最初のＷｅｂサービスの提供を開始する。
【０２２９】
そして、当該最初のＷｅｂサービスが提供されている間に、シナリオ実行部７０３は、ユーザから指定されたサービスシナリオを参照して、当該サービスシナリオに規定されているそれぞれのＷｅｂサービスの認可判定をＡｕＳ４００に実行させてもよい。これにより、最初のＷｅｂサービスの提供が開始されるまでのユーザの待ち時間を低減することができる。なお、ＳＰ６００が最初のＷｅｂサービスの提供を開始した後に、シナリオ実行部７０３が図２６および図２７に示した禁止サービスの登録処理を実行して、最初のＷｅｂサービスが禁止サービスとしてプロセス情報格納部７０２に登録された場合、シナリオ実行部７０３は、即座に、ユーザのＵＳ５００に、それ以降のＷｅｂサービスの提供が受けられない旨のエラー通知を送信することが好ましい。あるいは、サービスシナリオの中に含まれるＷｅｂサービスの提供を開始した後に、当該Ｗｅｂサービスが禁止サービスとして登録された場合も、即座に、ＵＳ５００に、それ以降のＷｅｂサービスの提供が受けられない旨のエラー通知を送信することが好ましい。
【０２３０】
上記において、本発明を実施の形態を用いて説明したが、本発明の技術的範囲は上記実施の形態に記載の範囲には限定されない。上記実施の形態に、多様な変更または改良を加えることが可能であることが当業者に明らかである。その様な変更または改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。
【図面の簡単な説明】
【０２３１】
【図１】第１実施例におけるアクセス認可システム１０の構成を例示するシステム構成図。
【図２】通信管理テーブル格納部５０４に格納されるデータの構造を例示する図。
【図３】通信管理テーブル格納部６０４に格納されるデータの構造を例示する図。
【図４】通信開始要求、通信開始応答、認可情報取得要求、認可情報取得応答、登録情報取得要求、および登録情報取得応答のデータ構造を例示する図。
【図５】ユーザ属性情報、サービスポリシ情報、認可判定要求、認可判定応答、および認可情報のデータ構造を例示する図。
【図６】登録情報更新要求、登録情報更新応答、認可情報削除要求、および認可情報削除応答のデータ構造を例示する図。
【図７】アクセス履歴格納部３０３に格納されるデータの構造を例示する図。
【図８】第１実施例において認可情報格納部１０３に格納されるデータの構造を例示する図。
【図９】次サービスＩＤ格納部１０１に格納されるデータの構造を例示する図。
【図１０】サービスポリシ情報格納部２０１に格納されるデータの構造を例示する図。
【図１１】ユーザ属性情報格納部２０２に格納されるデータの構造を例示する図。
【図１２】第１実施例におけるアクセス認可システム１０のサービス提供開始処理を例示するシーケンス図。
【図１３】第１実施例において、サービス提供開始前、サービス提供開始後、および認可判定を予め行った後の認可情報格納部１０３の内容を例示する図。
【図１４】第１実施例におけるアクセス認可システム１０の登録情報更新処理を例示するシーケンス図。
【図１５】第２実施例におけるアクセス認可システム１０の構成を例示するシステム構成図。
【図１６】認可情報送信通知および認可情報送信完了通知のデータ構造を例示する図。
【図１７】第２実施例において認可情報格納部１０３に格納されるデータの構造を例示する図。
【図１８】サービス履歴格納部１０６に格納されるデータの構造を例示する図。
【図１９】第２実施例におけるアクセス認可システム１０のサービス提供開始処理を例示するシーケンス図。
【図２０】第２実施例におけるアクセス認可システム１０の登録情報更新処理を例示するシーケンス図。
【図２１】第３実施例におけるビジネスプロセス実行システム４０の構成を例示するシステム構成図。
【図２２】シナリオ格納部７０１に格納されるデータの構造を例示する図。
【図２３】サービスシナリオ５０のデータ構造を例示する図。
【図２４】プロセス情報格納部７０２に格納されるデータの構造を例示する図。
【図２５】認可判定要求６０および認可判定結果７０のデータ構造を例示する図。
【図２６】シナリオ実行部７０３によって実行される、禁止サービス登録処理を例示するフローチャート。
【図２７】禁止判定処理（Ｓ６００）を例示するフローチャート。
【図２８】属性取得要求８０、属性取得応答８１、ポリシ取得要求８２、およびポリシ取得応答８３のデータ構造を例示する図。
【図２９】シナリオポリシ情報格納部２０５に格納されるデータの構造を例示する図。
【図３０】第３実施例におけるビジネスプロセス実行システム４０の動作を例示するシーケンス図。
【図３１】第３実施例における認可判定処理（Ｓ８００）を例示するシーケンス図。
【図３２】ＡＣＳ１００、ＰＭＳ２００、ＣＭＳ３００、ＡｕＳ４００、ＵＳ５００、ＳＰ６００、ＳＥＳ７００、またはＡＳ８００の機能を実現するコンピュータ２０の構成を例示するハードウェア構成図。
【図３３】第３実施例におけるビジネスプロセス実行システム４０の動作の他の例を示すシーケンス図。
【符号の説明】
【０２３２】
１０・・・アクセス認可システム、１１・・・ネットワーク、２０・・・コンピュータ、２１・・・ＣＰＵ、２２・・・メモリ、２３・・・外部記憶装置、２４・・・通信装置、２５・・・入力インターフェイス、２６・・・出力インターフェイス、２７・・・読取装置、２８・・・バス、２９・・・記憶媒体、３０・・・ＢＯＤＹ部、３１・・・ＢＯＤＹ部、４０・・・ビジネスプロセス実行システム、１００・・・ＡＣＳ、１０１・・・次サービスＩＤ格納部、１０２・・・次サービスＩＤ特定部、１０３・・・認可情報格納部、１０４・・・認可判定要求部、１０５・・・通信部、１０６・・・サービス履歴格納部、２００・・・ＰＭＳ、２０１・・・サービスポリシ情報格納部、２０２・・・ユーザ属性情報格納部、２０３・・・情報管理部、２０４・・・通信部、２０５・・・シナリオポリシ情報格納部、２０６・・・ポリシ情報管理部、３００・・・ＣＭＳ、３０１・・・位置情報格納部、３０２・・・ログイン処理部、３０３・・・アクセス履歴格納部、３０４・・・ＳＩＰメッセージ制御部、３０５・・・通信部、４００・・・ＡｕＳ、４０１・・・認可判定部、４０２・・・通信部、５００・・・ＵＳ、５０１・・・通信部、５０２・・・通信アプリケーション、５０３・・・ＳＩＰクライアント、５０４・・・通信管理テーブル格納部、５０５・・・通信制御エンジン、６００・・・ＳＰ、６０１・・・通信部、６０２・・・サービスアプリケーション、６０３・・・ＳＩＰクライアント、６０４・・・通信管理テーブル格納部、６０５・・・通信制御エンジン、６０６・・・認可判定取得部、６０７・・・認可判定結果格納部、７００・・・ＳＥＳ、７０１・・・シナリオ格納部、７０２・・・プロセス情報格納部、７０３・・・シナリオ実行部、７０４・・・通信部、８００・・・ＡＳ、８０１・・・ユーザ属性情報格納部、８０２・・・属性情報管理部、８０３・・・通信部
【技術分野】
【０００１】
本発明は、クライアント側の通信装置からのサービスの要求に基づいて、当該通信装置を使用しているユーザに対して当該サービスの提供が許可されるか否かを判定する認可判定を行う技術に関する。
【背景技術】
【０００２】
現在のインターネット環境では、電子商取引サービスをはじめとする様々なサービスが利用可能となっている。このようなサービスの中には、名前や住所等の個人情報の入力を必要とするサービス、または、金銭の授受が発生するサービス等がある。これらのサービスでは、なりすましを防ぐための本人確認、または、プライバシの保護といったセキュリティを確保するための仕組みが必要となる。特に通信を安全に実現するには、ユーザ認証、ユーザ毎のサービスの利用可否の判定（認可）、ユーザ毎のアクセス制御、またはデータの暗号化等の対策が重要である。
【０００３】
しかし、認証やアクセス制御の対策が必要なサービスが増えれば増えるほど、ユーザおよびサービス提供者がセキュリティ対策に費やすコストが増大する。例えば、ネットショッピングサイトまたはオンラインバンキング等の会員制サービスは、通常、ユーザ認証を必要とする。ユーザ認証の必要な複数のサービスを利用する場合、ユーザは、サービスを利用する度にＩＤ、パスワード、および電子証明書等の認証情報を入力しなければならない。
【０００４】
しかし、このような操作はユーザにとって面倒であり、複数の認証情報を管理するユーザの負担も大きい。一方、サービスを提供する側も、独自に認証サーバまたは認証機能を備えたアプリケーションサーバを用意しなければならず、設置コストおよび運用コストが大きくなる。
【０００５】
そこで近年では、一度のユーザ認証で複数のサービスが利用可能となるＳＳＯ（Single Sign On）のニーズが高まっている。ＳＳＯは、複数のサービスを利用する場合であっても、ユーザが一度認証を受けるだけで、それぞれのサービス毎に認証を行うことなく複数のサービスを利用できる仕組みである。そして、ＳＳＯにおける認証は、通常、ユーザやサービス提供者とは異なる第三者機関が実施する。
【０００６】
例えば、非特許文献１には、ＳＳＯを実現するため技術であるＳＡＭＬ（Security Assertion Markup Language）の技術仕様が定義されている。一度ユーザが第三者機関であるＳＡＭＬオーソリティから認証を受けると、ＳＡＭＬオーソリティがサービス提供者へユーザ認証の結果である認証アサーションを伝達するため、ユーザはサービスを利用する度に認証情報を入力する手間を省くことができる。
【０００７】
また、非特許文献１のＳＡＭＬオーソリティは、ユーザ認証を代行するだけでなく、ユーザのサービスの利用権限をチェックし、サービス利用の認可判定も代行する。ＳＡＭＬオーソリティは、ユーザの所属、住所、および資格等の属性情報、ならびに、サービスの利用を認可するためのポリシ情報を管理する。そして、ＳＡＭＬオーソリティは、ユーザがサービスを利用する際、属性情報およびポリシ情報に基づき、サービスの利用の可否を判定し、判定結果として認可アサーションを発行する。サービス提供者は、ＳＡＭＬオーソリティから認可アサーションを受け取り、受け取った認可アサーションに従ってユーザに対するアクセス制御を行うため、各サービス提供者は、個々に認可判定用のサーバを用意する必要がなくなるというメリットがある。
【０００８】
また、従来のＷｅｂサービスでは、サービス提供者が予めすべてのサービス構成要素を作り込んでおくことが一般的であったが、近年では、その場の状況に応じてサービスの構成要素を組み合わせて一つのビジネスプロセスを実現するサービス連携の考え方が広まってきている。
【０００９】
サービス連携を実現するための既存技術としては、例えば個々のＷｅｂサービスをサービス構成要素として連携させる手法であるＢＰＥＬ（Business Process Execution Language for Web Services）が知られている（例えば、非特許文献２参照）。ＢＰＥＬは、複数のＷｅｂサービスの実行手順を、一連のビジネスプロセスの流れとして記述するための言語仕様である。ＢＰＥＬで記述されたビジネスプロセスを解釈・実行する機能はＢＰＥＬエンジンと呼ばれる。
【００１０】
【非特許文献１】OASIS Standard, ”Security Assertion Markup Language (SAML) v2.0,”OASIS Security Services TC (2005), http://docs.oasis-open.org/security/saml/v2.0/saml-2.0-os.zip
【非特許文献２】OASIS Standard, ”Web Services Business Process Execution Language Version 2.0”，OASIS Web Services Business Process Execution Language (WSBPEL) TC（2007），http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.pdf
【発明の開示】
【発明が解決しようとする課題】
【００１１】
しかし、上記非特許文献１のＳＡＭＬオーソリティは、ユーザがサービスへアクセスする度に認可判定を行うため、ユーザがサービスを要求した場合、その後の認可判定が終了しなければユーザはサービスの提供を受けられない。つまり、ユーザは、認可判定が終了するまでサービスの提供開始を待たなければならない。個々の認可判定に関する処理負荷はそれほど高くないため、サービスの提供を要求するユーザの数が少ない場合には、認可判定にかかる時間は少なく、サービスの提供開始までのユーザの待ち時間は少ない場合が多い。
【００１２】
しかし、非特許文献１では、認可判定をＳＡＭＬオーソリティが一括して行っているため、多くのユーザが短期間にサービスの提供を要求した場合には、ＳＡＭＬオーソリティにかかる処理負荷が高くなり、個々の認可判定にかかる時間が長くなる場合がある。認可判定にかかる時間が長くなると、個々のサービスの提供開始までのユーザの待ち時間が長くなり、ユーザの利便性が損なわれる。
【００１３】
また、非特許文献２に記載されているＢＰＥＬにおいても、一連のビジネスプロセスの中で、それぞれのサービスが呼び出されてから当該サービスの認可判定を行うとすれば、それぞれのサービスの提供開始までのユーザの待ち時間が長くなる場合がある。
【００１４】
本発明は上記事情を鑑みてなされたものであり、本発明の目的は、ユーザから要求されたサービスの提供開始までのユーザの待ち時間を少なくすることにある。
【課題を解決するための手段】
【００１５】
上記課題を解決するために、本発明のアクセス認可システムは、クライアント側の通信装置に現在提供されているサービスに引き続いて当該通信装置に提供されるべきサービスを特定し、当該通信装置が当該次のサービスを要求する前に、当該通信装置のユーザに対する当該次のサービスの認可判定を予め実行する。
【００１６】
例えば、本発明の第１の態様は、クライアント側の通信装置からのサービスの要求に基づいて、当該通信装置を使用しているユーザに対して当該サービスの提供が許可されるか否かを判定する認可判定を行うアクセス認可システムであって、
ポリシ管理サーバと、
認可サーバと、
アクセス制御サーバと
を備え、
前記ポリシ管理サーバは、
クライアント側の通信装置のユーザを識別するユーザＩＤ毎に、当該ユーザのユーザ属性情報を格納するユーザ属性情報格納手段と、
サービスを識別するサービスＩＤ毎に、当該サービスの提供が許可されるユーザの条件を示すサービスポリシ情報を格納するサービスポリシ情報格納手段と、
前記アクセス制御サーバからユーザＩＤおよびサービスＩＤを含む登録情報取得要求を受信した場合に、当該ユーザＩＤに対応するユーザ属性情報を前記ユーザ属性情報格納手段から抽出すると共に、当該サービスＩＤに対応するサービスポリシ情報を前記サービスポリシ情報格納手段から抽出し、抽出したユーザ属性情報およびサービスポリシ情報を含む登録情報取得応答を前記アクセス制御サーバへ送信する情報管理手段と
を有し、
前記認可サーバは、
前記アクセス制御サーバからユーザ属性情報およびサービスポリシ情報を含む認可判定要求を受信した場合に、当該ユーザ属性情報が、当該サービスポリシ情報を満たすか否かを判定し、認可判定結果、当該認可判定結果の対象となるユーザのユーザＩＤ、および当該認可判定結果の対象となるサービスのサービスＩＤを含む認可判定応答を、前記アクセス制御サーバへ送信する認可判定手段を有し、
前記アクセス制御サーバは、
サービスＩＤ毎に、当該サービスＩＤに対応するサービスの次に提供されるべきサービスのサービスＩＤを格納する次サービスＩＤ格納手段と、
クライアント側の通信装置のユーザがサービスを利用可能か否かを示す認可情報の取得要求であって、当該ユーザのユーザＩＤおよび当該サービスのサービスＩＤを含む認可情報取得要求を受信した場合に、当該ユーザＩＤおよび当該サービスＩＤを含む登録情報取得要求を前記ポリシ管理サーバへ送信し、当該ユーザＩＤに対応するユーザ属性情報および当該サービスＩＤに対応するサービスポリシ情報を含む登録情報取得応答を前記ポリシ管理サーバから受信した場合に、当該ユーザ属性情報およびサービスポリシ情報を含む認可判定要求を前記認可サーバへ送信し、当該認可サーバから認可判定応答を受信した場合に、当該認可判定応答に含まれる認可判定結果、ユーザＩＤ、およびサービスＩＤを含む認可情報取得応答を出力する認可判定要求手段と、
前記認可判定要求手段が前記認可情報取得応答を出力した後に、当該認可情報取得応答に含まれる認可判定結果の対象であるサービスのサービスＩＤに基づいて前記次サービスＩＤ格納手段を参照して、当該サービスＩＤに対応するサービスの次に提供されるべきサービスのサービスＩＤを抽出し、抽出したサービスＩＤを、当該認可判定結果の対象であるユーザのユーザＩＤと共に前記認可判定要求手段へ送る次サービス特定手段と
を有し、
前記認可判定要求手段は、
前記認可情報取得応答を出力してから、当該認可情報取得応答に含まれるユーザＩＤと同一のユーザＩＤを含む認可情報取得要求を受信するまでの間に、前記次サービス特定手段から受け取ったユーザＩＤおよびサービスＩＤに対応するユーザ属性情報およびサービスポリシ情報を前記ポリシ管理サーバから取得し、当該ユーザ属性情報およびサービスポリシ情報を含む認可判定要求を前記認可サーバへ送信することにより、前記認可サーバに、当該ユーザＩＤに対応するユーザおよび当該サービスＩＤに対応するサービスの組み合わせについて認可判定を予め実行させることを特徴とするアクセス認可システムを提供する。
【００１７】
例えば、本発明の第２の態様は、クライアント側の通信装置のユーザを識別するユーザＩＤ毎に、当該ユーザのユーザ属性情報を格納するユーザ属性情報格納手段と、
サービスを識別するサービスＩＤ毎に、当該サービスの提供が許可されるユーザの条件を示すサービスポリシ情報を格納するサービスポリシ情報格納手段と、
ユーザＩＤおよびサービスＩＤを含む登録情報取得要求を受信した場合に、当該ユーザＩＤに対応するユーザ属性情報を前記ユーザ属性情報格納手段から抽出すると共に、当該サービスＩＤに対応するサービスポリシ情報を前記サービスポリシ情報格納手段から抽出し、抽出したユーザ属性情報およびサービスポリシ情報を含む登録情報取得応答を返す情報管理手段と
を有するポリシ管理サーバと、
ユーザ属性情報およびサービスポリシ情報を含む認可判定要求を受信した場合に、当該ユーザ属性情報が、当該サービスポリシ情報を満たすか否かを判定する認可判定を行い、認可判定結果、当該認可判定結果の対象となるユーザのユーザＩＤ、および当該認可判定結果の対象となるサービスのサービスＩＤを含む認可判定応答を返す認可判定手段
を有する認可サーバと
を備え、
クライアント側の通信装置からのサービスの要求に基づいて、当該通信装置を使用しているユーザに対する当該サービスの認可判定を行うアクセス認可システムに用いられるアクセス制御サーバであって、
サービスＩＤ毎に、当該サービスＩＤに対応するサービスの次に提供されるべきサービスのサービスＩＤを格納する次サービスＩＤ格納手段と、
クライアント側の通信装置のユーザがサービスを利用可能か否かを示す認可情報の取得要求であって、当該ユーザのユーザＩＤおよび当該サービスのサービスＩＤを含む認可情報取得要求を受信した場合に、当該ユーザＩＤおよび当該サービスＩＤを含む登録情報取得要求を前記ポリシ管理サーバへ送信し、当該ユーザＩＤに対応するユーザ属性情報および当該サービスＩＤに対応するサービスポリシ情報を含む登録情報取得応答を前記ポリシ管理サーバから受信した場合に、当該ユーザ属性情報およびサービスポリシ情報を含む認可判定要求を前記認可サーバへ送信し、当該認可サーバから認可判定応答を受信した場合に、当該認可判定応答に含まれる認可判定結果、ユーザＩＤ、およびサービスＩＤを含む認可情報取得応答を出力する認可判定要求手段と、
前記認可判定要求手段が前記認可情報取得応答を出力した後に、当該認可情報取得応答に含まれる認可判定結果の対象であるサービスのサービスＩＤに基づいて前記次サービスＩＤ格納手段を参照して、当該サービスＩＤに対応するサービスの次に提供されるべきサービスのサービスＩＤを抽出し、抽出したサービスＩＤを、当該認可判定結果の対象であるユーザのユーザＩＤと共に前記認可判定要求手段へ送る次サービス特定手段と
を有し、
前記認可判定要求手段は、
前記認可情報取得応答を出力してから、当該認可情報取得応答に含まれるユーザＩＤと同一のユーザＩＤを含む認可情報取得要求を受信するまでの間に、前記次サービス特定手段から受け取ったユーザＩＤおよびサービスＩＤに対応するユーザ属性情報およびサービスポリシ情報を前記ポリシ管理サーバから取得し、当該ユーザ属性情報およびサービスポリシ情報を含む認可判定要求を前記認可サーバへ送信することにより、前記認可サーバに、当該ユーザＩＤに対応するユーザおよび当該サービスＩＤに対応するサービスの組み合わせについて認可判定を予め実行させることを特徴とするアクセス認可サーバを提供する。
【００１８】
例えば、本発明の第３の態様は、クライアント側の通信装置から要求された、複数のサービスから構成されるビジネスプロセスについて、当該通信装置のユーザに対して当該ビジネスプロセスに含まれる個々のサービスの提供が許可されるか否かを判定する認可判定を行うビジネスプロセス実行システムであって、
属性管理サーバと、
ポリシ管理サーバと、
認可サーバと、
サービス実行サーバと
を備え、
前記属性管理サーバは、
クライアント側の通信装置のユーザを識別するユーザＩＤ毎に、当該ユーザのユーザ属性情報を格納するユーザ属性情報格納手段と、
前記認可サーバからユーザＩＤを含む属性取得要求を受信した場合に、当該ユーザＩＤに対応するユーザ属性情報を前記ユーザ属性情報格納手段から抽出し、抽出したユーザ属性情報を含む属性取得応答を前記認可サーバへ送信する属性情報管理手段と
を有し、
前記ポリシ管理サーバは、
サービスを識別するサービスＩＤ毎に、当該サービスの提供が許可されるユーザの条件を示すサービスポリシ情報を格納するサービスポリシ情報格納手段と、
前記認可サーバからサービスＩＤを含むポリシ取得要求を受信した場合に、当該サービスＩＤに対応するサービスポリシ情報を前記サービスポリシ情報格納手段から抽出し、抽出したサービスポリシ情報を含むポリシ取得応答を前記認可サーバへ送信するポリシ情報管理手段と
を有し、
前記認可サーバは、
前記サービス実行サーバからユーザＩＤおよび１つ以上のサービスＩＤを含む認可判定要求を受信した場合に、当該ユーザＩＤを含む属性取得要求を前記属性管理サーバへ送信して、当該ユーザＩＤに対応するユーザ属性情報を取得すると共に、当該サービスＩＤを含むポリシ取得要求を前記ポリシ管理サーバへ送信して、当該サービスＩＤに対応するサービスポリシ情報を取得し、取得したユーザ属性情報が、取得したサービスポリシ情報を満たすか否かを判定し、サービスＩＤ毎の認可判定結果を含む認可判定応答を、前記サービス実行サーバへ送信する認可判定手段を有し、
前記サービス実行サーバは、
ビジネスプロセスに含まれる複数のサービスの提供順番を規定するサービスシナリオを、それぞれのサービスシナリオを識別するシナリオＩＤに対応付けて格納するシナリオ格納手段と、
クライアント側の通信装置からユーザＩＤおよびシナリオＩＤを含むサービス要求を受信した場合に、当該シナリオＩＤに対応するサービスシナリオを前記シナリオ格納手段から取得し、当該ユーザＩＤおよび取得したサービスシナリオに含まれているそれぞれのサービスのサービスＩＤを含む認可判定要求を前記認可サーバへ送信することにより、当該サービスシナリオに含まれているそれぞれのサービスの認可判定結果を取得し、当該サービスシナリオに含まれている一連のサービスの全てが許可されている場合に、当該サービスシナリオにおいて最初に提供されるべきサービスを実行するサービス提供サーバに、当該ユーザＩＤのユーザに対して当該サービスの提供を要求するシナリオ実行手段と
を有することを特徴とするビジネスプロセス実行システムを提供する。
【発明の効果】
【００１９】
本発明によれば、サービスの提供開始までのユーザの待ち時間を少なくすることができる。
【発明を実施するための最良の形態】
【００２０】
以下、本発明の実施例について、図面を用いて詳細に説明する。
【００２１】
なお、以下の実施例１および２では、ＳＩＰ(Session Initiation Protocol)を用いたアクセス認可システム１０を一例に説明する。ＳＩＰはＩＥＴＦにおいてＲＦＣ３２６１で定義された、通信セッションの管理や制御を行う通信プロトコルである。また、各実施例に登場するシステム構成要素のうち、同一の要素が複数登場する場合には、ＳＰ（サービス提供サーバ）−α、ＳＰ−βのように表記する。また、例えばＳＰ−αとＳＰ−βをサービス提供サーバとして説明する場合のように複数の要素をまとめて説明する場合は、単にＳＰのように表現する。
【００２２】
また、以下の各実施例において、ユーザとは、ユーザ端末（ＵＳ）５００を操作する人間を指す。サービスとは、ＳＰ６００上で動作する、ユーザがＵＳ５００を介して利用するアプリケーションの特徴を示したものである。属性情報とは、ユーザやサービスの特性を示した情報で、例えばユーザの性別、名前、もしくは年齢、または、サービスの種別（動画配信または商取引等）、料金、もしくは品質等を計算機が解釈可能な形式で記述した情報である。
【００２３】
サービスポリシ情報とは、サービスの利用基準を定めた情報であり、例えば、２０歳以上のユーザのみ利用可能、特定の地域に在住のユーザのみ利用可能、または、一定額以上の費用を支払ったユーザのみ利用可能等のルールを計算機が解釈可能な形式で記述した情報である。認可情報とは、ＳＰ６００がユーザに対するアクセス制御を実施するための情報であり、認可サーバ（ＡｕＳ）４００の判定結果を基にアクセス制御サーバ（ＡＣＳ）１００が作成する。制御通信とは、例えばＳＩＰを用いた通信であり、ＵＳ５００と通信管理サーバ（ＣＭＳ）３００との間の通信、およびＳＰ６００とＣＭＳ３００との間の通信を指す。データ通信とは、ＵＳ５００とＳＰ６００とがＣＭＳ３００を介さずに行う通信を指す。
【００２４】
＜実施例１＞
まず、本発明の第１実施例について説明する。
【００２５】
図１は、第１実施例におけるアクセス認可システム１０の構成を例示するシステム構成図である。アクセス認可システム１０は、アクセス制御サーバ（ＡＣＳ）１００、ポリシ管理サーバ（ＰＭＳ）２００、通信管理サーバ（ＣＭＳ）３００、認可サーバ（ＡｕＳ）４００、ユーザ端末（ＵＳ）５００、および複数のサービス提供サーバ（ＳＰ）６００を備える。ＡＣＳ１００、ＰＭＳ２００、ＣＭＳ３００、ＡｕＳ４００、ＵＳ５００、およびＳＰ６００は、ネットワーク１１を介して互いに通信する。
【００２６】
図１に示すアクセス認可システム１０は、ユーザがＵＳ５００を介してサービスを利用する際に、第三者機関であるＡＣＳ１００が、ＰＭＳ２００およびＡｕＳ４００と連携して当該ユーザに対する当該サービスの認可判定を行い、その結果に基づいてＣＭＳ３００がアクセス制御を行う。
【００２７】
次に、本実施例におけるアクセス認可システム１０の各構成要素が備える機能について述べる。
【００２８】
まずＵＳ５００について説明する。ＵＳ５００は、通信部５０１、通信アプリケーション５０２、ＳＩＰクライアント５０３、通信管理テーブル格納部５０４、および通信制御エンジン５０５を備える。なお、本実施例では、ＳＰ６００からのサービスを受ける通信装置をＵＳ５００として説明するが、ＵＳ５００は端末装置である必要はなく、プロキシサーバ等のサーバ装置であってもよい。
【００２９】
通信部５０１は、通信アプリケーション５０２またはＳＩＰクライアント５０３からの指示に応じて、ネットワーク１１を介して他の装置と通信を行う。通信管理テーブル格納部５０４には、例えば図２に示すような通信管理テーブル５０４０が格納されている。通信管理テーブル５０４０には、現在提供を受けているサービスを特定するサービスＩＤ５０４１毎に、ＳＩＰクライアント５０３によって作成された通信ＩＤ５０４２が格納される。
【００３０】
本実施例においてサービスＩＤ５０４１には、例えば当該サービスＩＤ５０４１で特定されるサービスを提供するＳＰ６００のＵＲＬ（Uniform Resource Locator）が格納される。また、本実施例において通信ＩＤ５０４２としては、例えばＳＩＰ通信におけるCall_IDが使用される。
【００３１】
ＳＩＰクライアント５０３は、制御通信を実行する機能ブロックである。ＳＩＰクライアント５０３は、ＵＳ５００に接続されている入力装置を介して入力されたユーザからの指示に応じて、通信部５０１を介してＣＭＳ３００との間で認証処理を実行する。また、ＳＩＰクライアント５０３は、ユーザからの指示に応じて、通信部５０１を介して、ＳＩＰに規定されている位置登録の処理をＣＭＳ３００との間で実行する。
【００３２】
位置登録の処理とは、例えば自ＵＳ５００のSIP-URI（Uniform Resource Identifier）と位置情報の組をＳＩＰサーバに登録する処理を指す。位置情報としては、例えばＩＰアドレスであってもよく、ＩＰアドレスとポート番号の組等であってもよい。本実施例において、認証処理および位置登録処理を実行することをログインと呼ぶ。本実施例において、ＵＳ５００およびそれぞれのＳＰ６００は、ＣＭＳ３００との間で予めログインの処理をそれぞれ実行しているものとする。
【００３３】
ログインの処理後、ＳＩＰクライアント５０３は、通信制御エンジン５０５からサービスＩＤを受け取った場合に、当該サービスＩＤを記載した通信開始要求を作成し、作成した通信開始要求を、通信部５０１を介してＣＭＳ３００へ送信する。本実施例において通信開始要求は、例えば図４（ａ）に示すように、ＳＩＰにおいて定義されているＩＮＶＩＴＥリクエストと同様のメッセージフォーマットで作成される。通信開始要求のＢＯＤＹ部３０には、通信制御エンジン５０５から通知されたサービスＩＤが記載される。
【００３４】
なお、サービスが提供されているＳＰ６００のＵＲＬはユーザから指示されるが、宛先のＳＰ６００のSIP-URIは不明であるため、ＳＩＰクライアント５０３は、宛先のSIP-URIを「anonymous」として通信開始要求を作成する。
【００３５】
また、ＳＩＰクライアント５０３は、通信部５０１を介してＣＭＳ３００から通信開始応答を受信した場合に、当該通信開始応答に記載されているCall_ID、および、当該通信開始応答に対応する通信開始要求に記載したサービスＩＤを、通信路が確立している旨を示す情報と共に通信制御エンジン５０５へ送る。本実施例において通信開始応答は、例えば図４（ｂ）に示すように、ＳＩＰにおいて定義されている２００ＯＫレスポンスと同様のメッセージフォーマットでＣＭＳ３００によって作成される。
【００３６】
また、ＳＩＰクライアント５０３は、ＢＹＥリクエストをＣＭＳ３００から受信することにより通信が終了した場合に、通信の終了を示す情報と共に、当該ＢＹＥリクエストに含まれているCall_IDを通信制御エンジン５０５へ送る。
【００３７】
また、ＳＩＰクライアント５０３は、ユーザからユーザ属性情報の変更を指示された場合に、登録情報更新要求を作成し、作成した登録情報更新要求を通信部５０１を介してＣＭＳ３００へ送信する。そして、ＳＩＰクライアント５０３は、ＣＭＳ３００から登録情報更新応答を受信することにより、ユーザ属性情報が正常に変更されたことを認識する。
【００３８】
本実施例において登録情報更新要求は、例えば図６（ａ）に示すように、ＳＩＰにおいて定義されているＵＰＤＡＴＥリクエストと同様のメッセージフォーマットで作成される。登録情報更新要求のＢＯＤＹ部３１には、ユーザから指示された、変更すべきユーザ属性情報が記載される。本実施例において登録情報更新応答は、例えば図６（ｂ）に示すように、ＳＩＰにおいて定義されている２００ＯＫレスポンスと同様のメッセージフォーマットでＣＭＳ３００によって作成される。
【００３９】
通信制御エンジン５０５は、通信アプリケーション５０２からサービスＩＤを受け取った場合に、通信管理テーブル格納部５０４を参照して、当該サービスＩＤが通信管理テーブル５０４０に登録されているか否かを判定する。当該サービスＩＤが通信管理テーブル５０４０に登録されている場合、通信制御エンジン５０５は、通信路が確立している旨を示す情報を通信アプリケーション５０２に返す。
【００４０】
当該サービスＩＤが通信管理テーブル５０４０に登録されていない場合、通信制御エンジン５０５は、当該サービスＩＤをＳＩＰクライアント５０３へ送ることにより、ＳＩＰクライアント５０３に、当該サービスＩＤに示されたＵＲＬのＳＰ６００との間に通信路を確立させる。
【００４１】
そして、通信制御エンジン５０５は、通信路が確立している旨を示す情報と共に、Call_IDおよびサービスＩＤをＳＩＰクライアント５０３から受け取った場合に、受け取ったCall_IDを通信ＩＤとして、通信ＩＤおよびサービスＩＤの組を通信管理テーブル５０４０に登録する。そして、通信制御エンジン５０５は、通信路が確立している旨を示す情報を通信アプリケーション５０２に通知する。
【００４２】
また、通信の終了を示す情報と共に、Call_IDをＳＩＰクライアント５０３から受け取った場合、通信制御エンジン５０５は、Call_IDに対応する通信ＩＤおよび当該通信ＩＤに対応付けられているサービスＩＤを通信管理テーブル５０４０から削除する。
【００４３】
通信アプリケーション５０２は、データ通信を実行する機能ブロックである。通信アプリケーション５０２は、ユーザからサービスの要求を受け付けた場合に、当該サービスに対応するサービスＩＤを通信制御エンジン５０５へ送る。そして、通信アプリケーション５０２は、通信制御エンジン５０５から、当該サービスＩＤに対応するサービスの提供を受けるための通信路が確立している旨を通知された場合に、当該サービスＩＤに示されるＵＲＬのＳＰ６００へアクセスして対応するサービスの提供を受ける。
【００４４】
次に、ＳＰ６００について説明する。ＳＰ６００は、通信部６０１、サービスアプリケーション６０２、ＳＩＰクライアント６０３、通信管理テーブル格納部６０４、および通信制御エンジン６０５を備える。通信部６０１は、サービスアプリケーション６０２またはＳＩＰクライアント６０３からの指示に応じて、ネットワーク１１を介して他の装置と通信を行う。
【００４５】
通信管理テーブル格納部６０４には、例えば図３に示すような通信管理テーブル６０４０が格納されている。通信管理テーブル６０４０には、ユーザを特定するユーザＩＤ６０４１毎に、当該ユーザに対して提供が許可されたサービスのサービスＩＤ６０４２、当該サービスを提供する際に使用する通信路を特定する通信ＩＤ６０４３、および当該ユーザに当該サービスの提供が許可されたことを示す認可情報６０４４が格納される。
【００４６】
ＳＩＰクライアント６０３は、制御通信を実行する機能ブロックである。ＳＩＰクライアント６０３は、ＳＰ６００に接続された入力装置を介して入力された管理者からの指示に応じて、通信部６０１を介してＣＭＳ３００との間で認証処理と位置登録処理とを実行することにより、ログインを行う。
【００４７】
その後、ＳＩＰクライアント６０３は、ＣＭＳ３００から、ＢＯＤＹ部３０にさらに図５（ｅ）に示す形式の認可情報を含む通信開始要求（図４（ａ）参照）を受信した場合に、当該通信開始要求に含まれる送信元のユーザＩＤ、サービスＩＤ、通信ＩＤ、および認可情報を通信制御エンジン６０５に送る。そして、ＳＩＰクライアント６０３は、図４（ｂ）に示した通信開始応答を作成し、作成した通信開始応答を通信部６０１を介してＣＭＳ３００へ送信する。
【００４８】
また、ＳＩＰクライアント６０３は、ＢＹＥリクエストを受信することにより通信が終了した場合に、通信の終了を示す情報と共に、当該ＢＹＥリクエストに含まれているCall_IDを通信制御エンジン６０５へ送る。
【００４９】
また、ＳＩＰクライアント６０３は、通信部６０１を介して、ＡＣＳ１００から認可情報削除要求を受信した場合に、当該認可情報削除要求に含まれているユーザＩＤに対応するレコードを通信管理テーブル６０４０から全て削除する。そして、ＳＩＰクライアント６０３は、削除結果を含む認可情報削除応答を作成し、作成した認可情報削除応答を通信部６０１を介してＡＣＳ１００へ送信する。
【００５０】
本実施例において認可情報削除要求は、例えば図６（ｅ）に示すように、delAuthorizationAssertionRequestタグを用いたＸＭＬメッセージとして作成される。図６（ｅ）は、認可情報削除要求のうち、本実施例の説明に必要な部分のみを示している。subjectタグにはユーザＩＤが記載される。resourceタグにはサービスＩＤが記載される。seqタグには、認可情報削除要求と認可情報削除応答とを対応付けるためのリクエスト番号が記載される。
【００５１】
また、本実施例において認可情報削除応答は、例えば図６（ｆ）に示すように、delAuthorizationAssertionResponseタグを用いたＸＭＬメッセージとして作成される。図６（ｆ）は、認可情報削除応答のうち、本実施例の説明に必要な部分のみを示している。resultタグには認可情報の削除結果が記載される。seqタグには、認可情報削除要求と認可情報削除応答とを対応付けるためのリクエスト番号が記載される。
【００５２】
通信制御エンジン６０５は、ＳＩＰクライアント６０３から認可情報を受け取った場合に、受け取った認可情報がサービス提供を許可する旨を示すならば、当該認可情報、ならびに、当該認可情報と共に受け取ったユーザＩＤ、サービスＩＤ、および通信ＩＤを６０４０に登録する。また、通信の終了を示す情報と共に、Call_IDをＳＩＰクライアント６０３から受け取った場合、通信制御エンジン６０５は、Call_IDに対応する通信ＩＤ、ならびに、当該通信ＩＤに対応付けられているユーザＩＤ、サービスＩＤ、および認可情報を通信管理テーブル６０４０から削除する。
【００５３】
また、通信制御エンジン６０５は、サービスアプリケーション６０２からユーザＩＤおよびサービスＩＤの組を受け取った場合に、当該ユーザＩＤおよびサービスＩＤの組が通信管理テーブル６０４０内に存在するか否かを判定する。当該ユーザＩＤおよびサービスＩＤの組が通信管理テーブル６０４０内に存在する場合、通信制御エンジン６０５は、当該ユーザＩＤに対応するユーザに対して、当該サービスＩＤに対応するサービスの提供が許可されている旨をサービスアプリケーション６０２に返す。当該ユーザＩＤおよびサービスＩＤの組が通信管理テーブル６０４０内に存在しない場合、通信制御エンジン６０５は、当該ユーザＩＤに対応するユーザに対して、当該サービスＩＤに対応するサービスの提供が許可されていない旨をサービスアプリケーション６０２に返す。
【００５４】
サービスアプリケーション６０２は、データ通信を実行する機能ブロックである。サービスアプリケーション６０２は、通信部６０１を介して、サービスＩＤおよび当該サービスＩＤに対応するサービスの提供先のユーザのユーザＩＤを含むサービス提供要求を受信した場合に、当該ユーザＩＤおよびサービスＩＤを通信制御エンジン６０５に送る。そして、当該ユーザＩＤに対応するユーザに対して、当該サービスＩＤに対応するサービスの提供が許可されていない旨が通信制御エンジン６０５から返された場合、サービスアプリケーション６０２は、その旨を通信部６０１を介して当該ユーザＩＤに対応するユーザが使用しているＵＳ５００へ返信する。
【００５５】
一方、当該ユーザＩＤに対応するユーザに対して、当該サービスＩＤに対応するサービスの提供が許可されている旨が通信制御エンジン６０５から返された場合、サービスアプリケーション６０２は、当該ユーザＩＤに対応するユーザに対して、当該サービスＩＤに対応するサービスの提供を開始する。
【００５６】
次に、ＣＭＳ３００について説明する。ＣＭＳ３００は、位置情報格納部３０１、ログイン処理部３０２、アクセス履歴格納部３０３、ＳＩＰメッセージ制御部３０４、および通信部３０５を備える。通信部３０５は、ログイン処理部３０２またはＳＩＰメッセージ制御部３０４からの指示に応じて、ネットワーク１１を介して他の装置と通信を行う。
【００５７】
ログイン処理部３０２は、ＵＳ５００およびＳＰ６００のそれぞれとの間で位置登録処理および認証処理を含むログインに関する処理を実行し、位置登録において受信したSIP-URIと位置情報の組を位置情報格納部３０１に登録する。なお、本実施例では、ＣＭＳ３００は位置情報格納部３０１およびログイン処理部３０２を備えるが、他の例として、位置情報格納部３０１およびログイン処理部３０２は、ＣＭＳ３００の外部の装置により実現されていてもよい。
【００５８】
アクセス履歴格納部３０３には、例えば図７に示すように、ＳＩＰ通信におけるCall_IDを示す通信ＩＤ３０３１、ＵＳ５００のユーザのSIP-URIを示すSubject_ID３０３２、サービスを提供するＳＰ６００のSIP-URIを示すTarget_ID３０３３、サービスＩＤを示すService_ID３０３４、ＳＩＰによる通信の開始日時を示すStart３０３５、およびＳＩＰによる通信の終了日時を示すEnd３０３６が、それぞれのレコードを識別する番号３０３０に対応付けて格納されている。
【００５９】
ＳＩＰメッセージ制御部３０４は、通信部３０５を介して、ＵＳ５００から図４（ａ）に示した通信開始要求を受信した場合に、当該通信開始要求のＢＯＤＹ部３０に記載されているサービスＩＤで特定されるＵＲＬから、外部のＤＮＳサーバ等を参照して当該ＵＲＬに対応するＳＰ６００の位置情報（ＩＰアドレス）を特定し、特定した位置情報に対応するSIP-URIを位置情報格納部３０１から抽出する。
【００６０】
そして、ＳＩＰメッセージ制御部３０４は、当該通信開始要求に含まれているCall_IDを通信ＩＤとし、当該通信開始要求の送信元のSIP-URIをSubject_IDとし、当該通信開始要求に含まれているサービスＩＤに基づいて特定したSIP-URIをTarget_IDとし、当該通信開始要求に含まれているサービスＩＤをService_IDとして、新たに割り振った番号に対応付けてアクセス履歴格納部３０３に格納する。
【００６１】
そして、ＳＩＰメッセージ制御部３０４は認可情報取得要求を作成し、作成した認可情報取得要求を通信部３０５を介してＡＣＳ１００へ送信する。本実施例において認可情報取得要求は、図４（ｃ）に示すように、getAuthAssertionRequestタグを用いたＸＭＬメッセージとして作成される。図４（ｃ）は、認可情報取得要求のうち、本実施例の説明に必要な部分のみを示している。subjectタグにはＵＳ５００のSIP-URIが記載される。resourceタグにはサービスＩＤが記載される。seqタグには、認可情報取得要求とその応答である認可情報取得応答とを対応付けるためのリクエスト番号が記載される。
【００６２】
また、ＳＩＰメッセージ制御部３０４は、通信部３０５を介して、ＡＣＳ１００から認可情報取得応答を受信した場合に、ＢＯＤＹ部３０にさらに図５（ｅ）に示す形式の認可情報を含む通信開始要求（図４（ａ）参照）を作成し、作成した通信開始要求を、通信部３０５を介してＳＰ６００へ送信する。本実施例において認可情報取得応答は、図４（ｄ）に示すように、getAuthAssertionResponseタグを用いたＸＭＬメッセージとして作成される。図４（ｄ）は、認可情報取得応答のうち、本実施例の説明に必要な部分のみを示している。assertionタグには認可情報（図５（ｅ）参照）が記載される。seqタグには、認可情報取得要求と認可情報取得応答とを対応付けるためのリクエスト番号が記載される。
【００６３】
また、ＳＩＰメッセージ制御部３０４は、通信部３０５を介して、ＳＰ６００から通信開始応答を受信した場合に、アクセス履歴格納部３０３を参照して、当該通信開始応答に含まれているCall_IDと同一の通信ＩＤ、当該通信開始応答に含まれている送信元のSIP-URIと同一のSubject_ID、および、当該通信開始応答に含まれている宛先のSIP-URIと同一のTarget_IDに対応付けられているレコードを特定し、特定したレコードのStartの欄に、当該通信開始応答を受信した日時を登録する。そして、ＳＩＰメッセージ制御部３０４は、当該通信開始応答内の一部の情報（例えばviaヘッダの内容）を書き換えて宛先のＵＳ５００へ送信する。
【００６４】
また、ＳＩＰメッセージ制御部３０４は、通信部３０５を介して、ＢＹＥリクエストに対する２００ＯＫレスポンスを受信した場合に、当該２００ＯＫレスポンスに含まれているCall_IDと同一の通信ＩＤ、当該２００ＯＫレスポンスに含まれている送信元のSIP-URIと同一のSubject_ID、および、当該２００ＯＫレスポンスに含まれている宛先のSIP-URIと同一のTarget_IDに対応付けられているレコードを特定し、特定したレコードのEndの欄に、当該２００ＯＫレスポンスを受信した日時を登録する。
【００６５】
また、ＳＩＰメッセージ制御部３０４は、通信部３０５を介して、ＵＳ５００から図６（ａ）に示した登録情報更新要求を受信した場合に、異なる形式の登録情報更新要求を作成し、作成した登録情報更新要求を通信部３０５を介してＡＣＳ１００へ送信する。本実施例においてＳＩＰメッセージ制御部３０４によって作成される登録情報更新要求は、例えば図６（ｃ）に示すように、updateAttributeRequestタグを用いたＸＭＬメッセージとして作成される。図６（ｃ）は、ＳＩＰメッセージ制御部３０４によって作成される登録情報更新要求のうち、本実施例の説明に必要な部分のみを示している。subjectタグにはＵＳ５００のSIP-URIが記載される。attributeタグには更新すべきユーザ属性情報が記載される。seqタグには、登録情報更新要求とその応答である登録情報更新応答とを対応付けるためのリクエスト番号が記載される。
【００６６】
また、ＳＩＰメッセージ制御部３０４は、通信部３０５を介して、ＡＣＳ１００から登録情報更新応答を受信した場合に、異なる形式の登録情報更新応答（図６（ｂ）参照）を作成し、作成した登録情報更新要求を通信部３０５を介してＵＳ５００へ送信する。本実施例においてＡＣＳ１００から送信される登録情報更新応答は、例えば図６（ｄ）に示すように、updateAttributeResponseタグを用いたＸＭＬメッセージとして作成される。図６（ｄ）は、ＡＣＳ１００から送信される登録情報更新応答のうち、本実施例の説明に必要な部分のみを示している。resultタグにはユーザ属性情報の変更結果が記載される。seqタグには、登録情報更新要求と登録情報更新応答とを対応付けるためのリクエスト番号が記載される。
【００６７】
次に、ＡＣＳ１００について説明する。ＡＣＳ１００は、次サービスＩＤ格納部１０１、次サービスＩＤ特定部１０２、認可情報格納部１０３、認可判定要求部１０４、および通信部１０５を備える。通信部１０５は、認可判定要求部１０４からの指示に応じて、ネットワーク１１を介して他の装置と通信を行う。
【００６８】
認可情報格納部１０３には、例えば図８に示すように、ＵＳ５００のユーザのSIP-URIを示すSubject１０３１、サービスＩＤを示すResource１０３２、認可判定要求部１０４によって作成された認可情報（図５（ｅ）参照）に記載されているアサーションＩＤ１０３３、認可情報を格納している場所を示す認可情報参照点１０３４、Resource１０３２に対応するサービスがSubject１０３１に対応するユーザに提供されている状態か否かを示す通信フラグ１０３５が、それぞれのレコードを識別する番号１０３０に対応付けて格納されている。
【００６９】
次サービスＩＤ格納部１０１には、例えば図９に示すように、それぞれのサービスのサービスＩＤ１０１０毎に、次に提供されるべきサービスのサービスＩＤを示す次サービスＩＤ１０１１が格納されている。本実施例では、それぞれのサービスは、予め定められたワークフロー内の一部を構成するものであり、それぞれのワークフロー毎に、サービスの提供順番が予め定められている。
【００７０】
次サービスＩＤ特定部１０２は、認可判定要求部１０４からユーザＩＤおよびサービスＩＤを受け付けた場合に、次サービスＩＤ格納部１０１を参照して、当該サービスＩＤに対応付けられている次サービスＩＤを抽出する。そして、次サービスＩＤ特定部１０２は、抽出した次サービスＩＤを、認可判定要求部１０４から受け付けたユーザＩＤと共に認可判定要求部１０４へ送る。なお、認可判定要求部１０４から受け取ったサービスＩＤに対応する次サービスＩＤが次サービスＩＤ格納部１０１内に存在しない場合（例えばワークフローの内の最後のサービスの次に提供されるべきサービスのサービスＩＤ等）、次サービスＩＤ特定部１０２は、認可判定要求部１０４から受け取ったユーザＩＤを認可判定要求部１０４へ返す。
【００７１】
認可判定要求部１０４は、通信部１０５を介して、ＣＭＳ３００から認可情報取得要求（図４（ｃ）参照）を受信した場合に、認可情報格納部１０３を参照して、当該認可情報取得要求のsubjectタグで示されるユーザＩＤおよびresourceタグで示されるサービスＩＤの組み合わせに対応する認可情報が存在するか否かを判定する。当該ユーザＩＤおよびサービスＩＤの組み合わせに対応する認可情報が存在する場合、認可判定要求部１０４は、当該認可情報を認可情報格納部１０３から取得して、図４（ｄ）で説明した認可情報取得応答を作成し、作成した認可情報取得応答を通信部１０５を介してＣＭＳ３００へ送信する。
【００７２】
認可情報取得要求に含まれているユーザＩＤおよびサービスＩＤの組み合わせに対応する認可情報が認可情報格納部１０３内に存在しない場合、認可判定要求部１０４は、登録情報取得要求を作成し、作成した登録情報取得要求を通信部１０５を介してＰＭＳ２００へ送信する。本実施例において登録情報取得要求は、図４（ｅ）に示すように、getAttributeAndPolicyRequestタグを用いたＸＭＬメッセージとして作成される。図４（ｅ）は、登録情報取得要求のうち、本実施例の説明に必要な部分のみを示している。subjectタグにはＵＳ５００のSIP-URIが記載される。resourceタグにはサービスＩＤが記載される。seqタグには、登録情報取得要求と登録情報取得応答とを対応付けるためのリクエスト番号が記載される。
【００７３】
そして、通信部１０５を介して登録情報取得応答をＰＭＳ２００から受信した場合、認可判定要求部１０４は、認可判定要求を作成し、作成した認可判定要求を、通信部１０５を介してＡｕＳ４００へ送信する。本実施例において登録情報取得応答は、図４（ｆ）に示すように、getAttributeAndPolicyResponseタグを用いたＸＭＬメッセージとして作成される。図４（ｆ）は、登録情報取得応答のうち、本実施例の説明に必要な部分のみを示している。
【００７４】
登録情報取得応答のresultタグにはＵＳ５００のユーザの属性情報およびサービスポリシ情報の取得結果が記載される。取得結果としては、例えば、ユーザの属性情報とサービスポリシ情報を両方取得できた場合にはＯＫが記載され、ユーザ属性情報およびサービスポリシ情報のいずれか一方が取得できなかった場合にはＮＧが記載される。登録情報取得応答のseqタグには、登録情報取得要求と登録情報取得応答とを対応付けるためのリクエスト番号が記載される。
【００７５】
登録情報取得応答のattributeタグにはユーザの属性情報が記載される。ユーザ属性情報は、例えば図５（ａ）に示すようなＸＭＬメッセージとして記述される。属性情報のidタグにはユーザのSIP-URIが記載される。nameタグにはユーザの名前が記載される。ageタグにはユーザの年齢が記載される。sexタグにはユーザの性別が記載される。addressタグにはユーザの住所が記載される。interestsタグにはユーザの嗜好がitemタグで挟んでそれぞれ記載される。itemタグは１つ以上記載される。idタグ以外のタグの要素はオプションであり、記載しない場合は各タグの要素に「null」が記載される。
【００７６】
登録情報取得応答のpolicyタグにはサービスポリシ情報が記載される。サービスポリシ情報は、例えば図５（ｂ）のようなＸＭＬメッセージとして記述される。idタグにはサービスＩＤが記載される。ruleListsタグには認可判定を行うための基準となるルールがruleタグで挟んで記載される。algorithmタグにはruleListsタグに記載している各ルールを用いた認可判定に使用されるアルゴリズムの名前が記載される。Ruleタグは１つ以上記載される。また、idタグ以外のタグの要素はオプションであり、記載しない場合は各タグの要素に「null」が記載される。
【００７７】
本実施例では、使用可能な認可判定アルゴリズムの例として２種類の認可判定アルゴリズムを想定する。サービスポリシ情報に記載するalgorithmタグの要素には、例えば以下の２つのアルゴリズムが指定可能である。「Deny-overrides」は、全てのルールに対して判定を行い、全てのルールについて「Permit」である場合のみ認可判定結果を「Permit」とし、それ以外の全ての場合については認可判定結果を「Deny」とする認可判定アルゴリズムである。「Permit-overrides」は、全てのルールに対して判定を行い、どれか一つのルールについて「Permit」であれば認可判定結果を「Permit」とし、全てのルールについて「Deny」である場合にのみ認可判定結果を「Deny」とする認可判定アルゴリズムである。認可判定の必要がないサービスを利用する場合には、認可判定アルゴリズムとして「null」が指定される。
【００７８】
また、本実施例において認可判定要求は、図５（ｃ）に示すように、judgeAuthorizationRequestタグを用いたＸＭＬメッセージとして作成される。図５（ｃ）は、認可判定要求のうち、本実施例の説明に必要な部分のみを示している。attributeタグにはユーザの属性情報が記載される。policyタグにはサービスポリシ情報が記載される。seqタグには認可判定要求と認可判定応答とを対応付けるためのリクエスト番号が記載される。
【００７９】
そして、通信部１０５を介して認可判定応答をＡｕＳ４００から受信した場合、認可判定要求部１０４は、認可情報を作成する。本実施例において認可判定応答は、図５（ｄ）に示すように、judgeAuthorizationResponseタグを用いたＸＭＬメッセージとして作成される。図５（ｄ）は、認可判定応答のうち、本実施例の説明に必要な部分のみを示している。resultタグには認可判定の結果が記載される。seqタグには認可判定要求と認可判定応答とを対応付けるためのリクエスト番号が記載される。
【００８０】
そして、当該認可判定応答に含まれている認可判定結果が、サービスの提供を許可する旨を示す場合、認可判定要求部１０４は、作成した認可情報をＡＣＳ１００内のメモリまたはＡＣＳ１００の外部の装置内のメモリに保存し、保存先を示す情報を当該認可情報の対象となるユーザＩＤおよびサービスＩＤに対応付けて認可情報格納部１０３に登録する。そして、認可判定要求部１０４は、認可情報取得応答（図４（ｄ）参照）を作成して、通信部１０５を介してＣＭＳ３００へ送信する。
【００８１】
本実施例において認可情報は、図５（ｅ）に示すように、assertion-Bodyタグを用いたＸＭＬメッセージとして作成される。図５（ｅ）は、認可情報のうち、本実施例の説明に必要な部分のみを示している。assertionIDタグには認可情報を識別する識別情報が記載される。subjectタグには認可判定応答に対応する認可判定要求内のユーザ属性情報に含まれるユーザＩＤが記載される。resourceタグには認可判定応答に対応する認可判定要求内のサービスポリシ情報に含まれるサービスＩＤが記載される。decisionタグには認可判定応答に含まれている認可判定の結果が記載される。signatureタグにはassertion-Bodyタグ全体を対象としたＸＭＬ署名が記載される。
【００８２】
認可情報取得応答をＣＭＳ３００へ送信した後、認可判定要求部１０４は、当該認可情報取得応答に含まれているユーザＩＤおよびサービスＩＤを次サービスＩＤ特定部１０２へ送る。そして、次サービスＩＤ特定部１０２からユーザＩＤおよび次サービスＩＤを受け取った場合、認可判定要求部１０４は、当該ユーザＩＤおよび次サービスＩＤの組み合わせに対応する認可情報が認可情報格納部１０３に登録されているか否かを判定する。
【００８３】
当該ユーザＩＤおよび次サービスＩＤの組み合わせに対応する認可情報が認可情報格納部１０３に登録されていない場合、認可判定要求部１０４は、当該ユーザＩＤおよび次サービスＩＤを含む登録情報取得要求（図４（ｅ）参照）を作成してＰＭＳ２００へ送る。なお、当該ユーザＩＤおよび次サービスＩＤの組み合わせに対応する認可情報が認可情報格納部１０３に既に登録されている場合、または、次サービスＩＤ特定部１０２がユーザＩＤと共に次サービスＩＤを出力しなかった場合、認可判定要求部１０４は、予め認可判定を行う処理を実行しない。
【００８４】
そして、認可判定要求部１０４は、ＰＭＳ２００から登録情報取得応答（図４（ｆ））を受け取り、受け取った登録情報取得応答に基づいて認可判定要求（図５（ｃ））を作成してＡｕＳ４００へ送る。そして、認可判定要求部１０４は、ＡｕＳ４００から認可判定応答（図５（ｄ））を受け取り、受け取った認可判定応答に含まれている認可判定結果がサービスの提供を許可する旨を示す場合に、認可情報を作成し、作成した認可情報をＡＣＳ１００内のメモリまたはＡＣＳ１００の外部の装置内のメモリに保存し、保存先を示す情報を当該認可情報の対象となるユーザＩＤおよびサービスＩＤに対応付けて認可情報格納部１０３に登録する。
【００８５】
このように、認可判定要求部１０４は、あるユーザについて認可判定を行ったサービスの次に提供されるべきサービスの認可判定を、当該ユーザから要求される前に実行する。これにより、アクセス認可システム１０は、ユーザからサービスの要求を受け付けた場合に、認可判定の間ユーザを待たせることなく、ユーザに対する認可判定結果に基づいてより迅速にサービスの提供を開始することができる。
【００８６】
なお、本実施例において、認可判定要求部１０４は、認可情報取得応答をＣＭＳ３００へ送信してから、当該認可情報取得応答に記載したサービスＩＤで特定されるサービスの次に提供されるべきサービスに対する認可情報取得要求をＣＭＳ３００から受信する前までの間に、当該認可情報取得応答に含まれるユーザＩＤに対応するユーザについて、当該次に提供されるべきサービスの認可判定に関する処理を実行する。
【００８７】
より好ましくは、認可判定要求部１０４は、認可情報取得応答をＣＭＳ３００へ送信してから、当該認可情報取得応答に記載したサービスＩＤで特定されるサービスの次に提供されるべきサービスに対する認可情報取得要求をＣＭＳ３００から受信する前までの間であって、ＡＣＳ１００の処理負荷が低いときに、当該次に提供されるべきサービスの認可判定を実施する。処理負荷が低いときとは、例えばＡＣＳ１００の処理負荷が予め定められた閾値よりも低いときを指す。例えば、ＡＣＳ１００のＣＰＵ使用率が５０％未満のときに、認可判定要求部１０４は、当該次に提供されるべきサービスの認可判定を実施する。
【００８８】
また、認可判定要求部１０４は、通信部１０５を介して、ＣＭＳ３００から登録情報更新要求（図６（ｃ）参照）を受信した場合に、受信した登録情報更新要求をＰＭＳ２００に転送する。そして、ＰＭＳ２００から登録情報更新応答（図６（ｄ）参照）を受信した場合、認可判定要求部１０４は、認可情報格納部１０３を参照して、当該登録情報更新応答に対応する登録情報更新要求に含まれているユーザＩＤが認可情報格納部１０３に登録されているか否かを判定する。当該ユーザＩＤが認可情報格納部１０３に登録されていない場合、認可判定要求部１０４は、ＰＭＳ２００から受信した登録情報更新応答をＣＭＳ３００へ転送する。
【００８９】
一方、ＰＭＳ２００から受信した登録情報更新応答に対応する登録情報更新要求に含まれているユーザＩＤが認可情報格納部１０３に登録されている場合、認可判定要求部１０４は、認可情報格納部１０３を参照して、当該ユーザＩＤに対応付けられているサービスＩＤを抽出する。そして、認可判定要求部１０４は、抽出したそれぞれのサービスＩＤについて認可情報削除要求（図６（ｅ）参照）を作成し、作成した認可情報削除要求を、通信部１０５を介してそれぞれの宛先のＳＰ６００へ送信する。
【００９０】
そして、認可情報削除要求を送信した全てのＳＰ６００から認可情報削除応答（図６（ｆ））を受信した場合、認可判定要求部１０４は、送信した認可情報削除要求に含まれるユーザＩＤを含む全てのレコードを認可情報格納部１０３から削除し、ＰＭＳ２００から受信した登録情報更新応答をＣＭＳ３００へ転送する。
【００９１】
次に、ＰＭＳ２００について説明する。ＰＭＳ２００は、サービスポリシ情報格納部２０１、ユーザ属性情報格納部２０２、情報管理部２０３、および通信部２０４を備える。通信部２０４は、情報管理部２０３からの指示に応じて、ネットワーク１１を介して他の装置と通信を行う。
【００９２】
サービスポリシ情報格納部２０１には、例えば図１０に示すように、サービスＩＤ２０１０毎に、当該サービスＩＤ２０１０に対応するサービスのサービスポリシ情報の実体が格納されているＰＭＳ２００のメモリ内の場所を示す参照先アドレス２０１１が格納されている。サービスポリシ情報の実体は、例えば図５（ｂ）に示すようなデータ構造である。
【００９３】
ユーザ属性情報格納部２０２には、例えば図１１に示すように、ユーザＩＤ２０２０毎に、当該ユーザＩＤ２０２０に対応するユーザの属性情報の実体が格納されているＰＭＳ２００のメモリ内の場所を示す参照先アドレス２０２１が格納されている。ユーザ属性情報の実体は、例えば図５（ａ）に示すようなデータ構造である。
【００９４】
情報管理部２０３は、通信部２０４を介して、登録情報取得要求（図４（ｅ）参照）をＡＣＳ１００から受信した場合に、当該登録情報取得要求に含まれているサービスＩＤに対応するサービスポリシ情報をサービスポリシ情報格納部２０１から取得し、当該登録情報取得要求に含まれているユーザＩＤに対応するユーザ属性情報をユーザ属性情報格納部２０２から取得する。そして、情報管理部２０３は、取得したサービスポリシ情報およびユーザ属性情報に基づいて登録情報取得応答（図４（ｆ）参照）を作成し、作成した登録情報取得応答を、通信部２０４を介してＡＣＳ１００へ送信する。
【００９５】
また、情報管理部２０３は、通信部２０４を介して、ＡＣＳ１００から登録情報更新要求（図６（ｃ）参照）を受信した場合に、ユーザ属性情報格納部２０２を参照して、当該登録情報更新要求に含まれるユーザＩＤに対応するユーザ属性情報を、当該登録情報更新要求に含まれるユーザ属性情報で更新する。そして、情報管理部２０３は、更新結果を含む登録情報更新応答（図６（ｄ））を作成し、作成した登録情報更新応答を、通信部２０４を介してＡＣＳ１００へ送信する。
【００９６】
次に、ＡｕＳ４００について説明する。ＡｕＳ４００は、認可判定部４０１および通信部４０２を備える。通信部４０２は、認可判定部４０１からの指示に応じて、ネットワーク１１を介して他の装置と通信を行う。
【００９７】
認可判定部４０１は、通信部４０２を介して、認可判定要求（図５（ｃ）参照）をＡＣＳ１００から受信した場合に、当該認可判定要求に含まれるユーザ属性情報が、当該認可判定要求に含まれるサービスポリシ情報を満たすか否かを判定する認可判定を実行する。そして、認可判定部４０１は、認可判定結果を含む認可判定応答（図５（ｄ）参照）を作成し、作成した認可判定応答を、通信部４０２を介してＡＣＳ１００へ送信する。
【００９８】
次に、第１実施例において、ユーザの要求に応じてサービスの提供が開始される場合のアクセス認可システム１０の一連の動作について図１２を用いて説明する。
【００９９】
まず、ＵＳ５００のＳＩＰクライアント５０３は、ユーザからの要求に応じて図４（ａ）に示した通信開始要求を作成し、作成した通信開始要求をＣＭＳ３００へ送信する（Ｓ１００）。ここで、ＵＳ５００のユーザのSIP-RUIは「jiro@sipdomain.com」であり、ユーザが希望するサービスのサービスＩＤは「http://travel.testservice1.com/」であるものと仮定する。ＣＭＳ３００のＳＩＰメッセージ制御部３０４は、ＵＳ５００から受信した通信開始要求に基づいて図４（ｃ）に示した認可情報取得要求を作成し、作成した認可情報取得要求をＡＣＳ１００へ送信する（Ｓ１０１）。
【０１００】
次に、ＡＣＳ１００の認可判定要求部１０４は、ＣＭＳ３００から受信した認可情報取得要求に含まれるユーザＩＤおよびサービスＩＤの組み合わせに対応する認可情報が認可情報格納部１０３に格納されているか否かを判定する（Ｓ１０２）。当該ユーザＩＤおよびサービスＩＤの組み合わせに対応する認可情報が認可情報格納部１０３に格納されている場合（Ｓ１０２：Ｙｅｓ）、認可判定要求部１０４は、ステップＳ１０９に示す処理を実行する。
【０１０１】
ここで、ステップＳ１０２が実行される前の認可情報格納部１０３には、例えば図１３（ａ）に示すようなデータが格納されているものとする。本シーケンス図で示される例では、ＣＭＳ３００から受信した認可情報取得要求に含まれるユーザＩＤおよびサービスＩＤの組み合わせに対応する認可情報が認可情報格納部１０３に格納されておらず（Ｓ１０２：Ｎｏ）、認可判定要求部１０４は、当該ユーザＩＤおよびサービスＩＤに基づいて、図４（ｅ）に示した登録情報取得要求を作成し、作成した登録情報取得要求をＰＭＳ２００へ送信する（Ｓ１０３）。
【０１０２】
ＰＭＳ２００の情報管理部２０３は、ＡＣＳ１００から受信した登録情報取得要求に含まれているユーザＩＤおよびサービスＩＤに基づいて、サービスポリシ情報格納部２０１およびユーザ属性情報格納部２０２から対応するユーザ属性情報およびサービスポリシ情報をそれぞれ取得する。そして、情報管理部２０３は、取得したユーザ属性情報およびサービスポリシ情報を含む登録情報取得応答（図４（ｆ）参照）を作成し、作成した登録情報取得応答をＡＣＳ１００へ送信する（Ｓ１０４）。
【０１０３】
次に、ＡＣＳ１００の認可判定要求部１０４は、ＰＭＳ２００から受信した登録情報取得応答に含まれているユーザ属性情報およびサービスポリシ情報を含む認可判定要求（図５（ｃ）参照）を作成し、作成した認可判定要求をＡｕＳ４００へ送信する（Ｓ１０５）。ＡｕＳ４００の認可判定部４０１は、ＡＣＳ１００から受信した認可判定要求に含まれるユーザ属性情報が、当該認可判定要求に含まれているサービスポリシ情報を満たすか否かを判定する（Ｓ１０６）。そして、認可判定部４０１は、認可判定結果を含む認可判定応答（図５（ｄ）参照）を作成し、作成した認可判定応答をＡＣＳ１００へ送信する（Ｓ１０７）。
【０１０４】
次に、ＡＣＳ１００の認可判定要求部１０４は、ＡｕＳ４００から受信した認可判定応答に基づいて、図５（ｅ）に示した認可情報を作成し、当該認可応答に含まれる判定結果がサービスの利用を許可する旨を示す場合に、当該認可情報を、対応するユーザＩＤおよびサービスＩＤ等の情報と共に認可情報格納部１０３に保存する（Ｓ１０８）。この時点で、認可情報格納部１０３内のデータは、例えば図１３（ｂ）に示すような構成になる。そして、認可判定要求部１０４は、図４（ｄ）に示した認可情報取得応答を作成し、作成した認可情報取得応答をＣＭＳ３００へ送信する（Ｓ１０９）。
【０１０５】
ＣＭＳ３００のＳＩＰメッセージ制御部３０４は、図４（ａ）に示した通信開始要求において、宛先をサービスＩＤに対応するサービスを提供するＳＰ６００のSIP-URIとし、ＢＯＤＹ部３０にＡＣＳ１００から受信した認可情報取得応答に含まれている認可情報を含めた通信開始要求を作成し、作成した通信開始要求をＳＰ６００へ送信する（Ｓ１１０）。
【０１０６】
ＳＰ６００のＳＩＰクライアント６０３は、ＣＭＳ３００から受信した通信開始要求に応じて、図４（ｂ）に示した通信開始応答を作成し、作成した通信開始応答をＣＭＳ３００へ送信する（Ｓ１１１）。ＣＭＳ３００のＳＩＰメッセージ制御部３０４は、ＳＰ６００から受信した通信開始応答の一部を書き換えてＵＳ５００へ送信する（Ｓ１１２）。そして、ＳＰ６００のサービスアプリケーション６０２は、ＵＳ５００へのサービスの提供を開始する（Ｓ１１３）。
【０１０７】
次に、ＡＣＳ１００の認可判定要求部１０４は、ステップＳ１０９において送信した認可情報取得応答内の認可情報に含まれているユーザＩＤおよびサービスＩＤを次サービスＩＤ特定部１０２へ送る。次サービスＩＤ特定部１０２は、次サービスＩＤ格納部１０１を参照して、当該サービスＩＤに対応付けられている次サービスＩＤを抽出することにより、次に提供されるべきサービスのサービスＩＤを特定する（Ｓ１１４）。
【０１０８】
次に、次サービスＩＤ特定部１０２は、抽出した次サービスＩＤを、認可判定要求部１０４から受け付けたユーザＩＤと共に認可判定要求部１０４へ返す。そして、認可判定要求部１０４は、次サービスＩＤ特定部１０２から受信したユーザＩＤおよびサービスＩＤを用いて、ステップＳ１０２からステップＳ１０８に示した処理Ａを実行する（Ｓ１１５）。ステップＳ１１５の処理が終了すると、認可情報格納部１０３内のデータは、例えば図１３（ｃ）に示すような構成になる。これにより、アクセス認可システム１０は、同一のユーザから次のサービスの提供を要求された場合に、認可情報格納部１０３内の認可情報をもとに迅速にサービスの提供を開始することができる。
【０１０９】
なお、本シーケンス図では、ステップＳ１１４およびＳ１１５で示される処理が、ステップＳ１１３で示される処理の後に実行されているが、本発明はこれに限られず、認可判定要求部１０４は、ステップＳ１０９で示される処理を実行してから、次のサービスの要求に対応する認可情報取得要求を受信するまでの間に、ステップＳ１１４およびＳ１１５で示される処理を実行すればよい。
【０１１０】
次に、第１実施例において、ＵＳ５００を介したユーザによる登録情報の更新に関する一連の処理について図１４を用いて説明する。
【０１１１】
まず、ＵＳ５００のＳＩＰクライアント５０３は、ユーザからの要求に応じて図６（ａ）に示した登録情報更新要求を作成し、作成した登録情報更新要求をＣＭＳ３００へ送信する（Ｓ２００）。ＣＭＳ３００のＳＩＰメッセージ制御部３０４は、ＵＳ５００から受信した登録情報更新要求に基づいて図６（ｃ）に示した登録情報更新要求を作成し、作成した登録情報更新要求をＡＣＳ１００へ送信する（Ｓ２０１）。
【０１１２】
ＡＣＳ１００の認可判定要求部１０４は、ＣＭＳ３００から受信した登録情報更新要求をＰＭＳ２００へ転送する（Ｓ２０２）。ＰＭＳ２００の情報管理部２０３は、ＡＣＳ１００から受信した登録要求更新要求に含まれているユーザＩＤに対応するユーザ属性情報格納部２０２内のユーザ属性情報を、当該登録情報更新要求に含まれているユーザ属性情報で更新する（Ｓ２０３）。そして、情報管理部２０３は、図６（ｄ）に示した登録情報更新応答を作成し、作成した登録情報更新応答をＡＣＳ１００へ送信する（Ｓ２０４）。
【０１１３】
次に、ＡＣＳ１００の認可判定要求部１０４は、ステップＳ２０１で受信した登録情報更新要求に含まれているユーザＩＤに対応する認可情報が認可情報格納部１０３に格納されているか否かを判定する（Ｓ２０５）。当該ユーザＩＤに対応する認可情報が認可情報格納部１０３に格納されていない場合（Ｓ２０５：Ｎｏ）、認可判定要求部１０４は、ステップＳ２１３に示す処理を実行する。
【０１１４】
ステップＳ２０１で受信した登録情報更新要求に含まれているユーザＩＤに対応する認可情報が認可情報格納部１０３に格納されている場合（Ｓ２０５：Ｙｅｓ）、認可判定要求部１０４は、当該認可情報に対応付けられているサービスＩＤを認可情報格納部１０３から抽出し、抽出したそれぞれのサービスＩＤについて、図６（ｅ）に示した認可情報削除要求を作成し、作成した認可情報削除要求を送信する（Ｓ２０６、Ｓ２０９）。本例では、ＳＰ６００−αとＳＰ６００−βにはサービスの提供を許可する旨を示す認可情報が既に渡されており、ＳＰ６００−γにはサービスの提供を許可する旨を示す認可情報が渡されていないものとする。
【０１１５】
ＳＰ６００−αおよびＳＰ６００−βのそれぞれのＳＩＰクライアント６０３は、通信管理テーブル格納部６０４を参照して、ＡＣＳ１００から受信した認可情報削除要求に含まれているユーザＩＤに対応するレコードを通信管理テーブル６０４０から全て削除する（Ｓ２０７、Ｓ２１０）。そして、ＳＩＰクライアント６０３は、図６（ｆ）に示した認可情報削除応答を作成し、作成した認可情報削除応答をＡＣＳ１００へ送信する（Ｓ２０８、Ｓ２１１）。
【０１１６】
次に、ＡＣＳ１００の認可判定要求部１０４は、ステップＳ２０１で受信した登録情報更新要求に含まれているユーザＩＤに対応する認可情報を認可情報格納部１０３から全て削除し（Ｓ２１２）、ステップＳ２０４で受信した登録情報更新応答をＣＭＳ３００へ転送する（Ｓ２１３）。ＣＭＳ３００のＳＩＰメッセージ制御部３０４は、ＡＣＳ１００から受信した登録情報更新応答に基づいて、図６（ｂ）に示した登録情報更新応答を作成し、作成した登録情報更新応答をＵＳ５００へ送信する（Ｓ２１４）。
【０１１７】
以上、本発明の第１実施例について説明した。上記説明から明らかなように、本実施例のアクセス認可システム１０によれば、ユーザから要求されたサービスの提供開始までのユーザの待ち時間を少なくすることができる。
【０１１８】
また、本実施例において、ＡＣＳ１００は、事前に行った認可判定の結果を保持し、ＣＭＳ３００から認可情報取得要求を受信した場合に、保持していた認可情報を用いて認可情報取得応答を返信する。これにより、実際にはユーザが提供を受けていないサービスに関する認可情報は、ＡＣＳ１００内に存在する。そのため、ユーザの属性情報が変更された場合に、認可判定のやり直しに伴う認可情報の削除を実行する必要があるが、認可情報が保存されている装置を少なくできるため、認可情報の削除に伴う通信トラフィックを低減することができる。
【０１１９】
＜実施例２＞
次に、本発明の第２実施例について説明する。
【０１２０】
図１５は、第２実施例におけるアクセス認可システム１０の構成を例示するシステム構成図である。アクセス認可システム１０は、アクセス制御サーバ（ＡＣＳ）１００、ポリシ管理サーバ（ＰＭＳ）２００、通信管理サーバ（ＣＭＳ）３００、認可サーバ（ＡｕＳ）４００、ユーザ端末（ＵＳ）５００、および複数のサービス提供サーバ（ＳＰ）６００を備える。なお、以下に説明する点を除き、図１５において、図１と同じ符号を付した構成は、図１における構成と同一または同様の機能を有するため説明を省略する。
【０１２１】
ＳＰ６００のＳＩＰクライアント６０３は、ＡＣＳ１００からユーザＩＤ、サービスＩＤ、および認可情報を含む認可情報送信通知を受信した場合に、受信したこれらの情報を通信管理テーブル格納部６０４に登録し、認可情報送信完了通知をＡＣＳ１００へ送信する。
【０１２２】
本実施例において認可情報送信通知は、例えば図１６（ａ）に示すように、sendAuthorizationAssertionNotifyタグを用いたＸＭＬメッセージとして作成される。図１６（ａ）は、認可情報送信通知のうち、本実施例の説明に必要な部分のみを示している。subjectタグにはユーザＩＤが記載される。resourceタグにはサービスＩＤが記載される。assertionタグには認可情報（図５（ｅ）参照）が記載される。seqタグには、認可情報送信通知と認可情報送信完了通知とを対応付けるためのリクエスト番号が記載される。
【０１２３】
また、本実施例において認可情報送信完了通知は、例えば図１６（ｂ）に示すように、sendAuthorizationAssertionReportタグを用いたＸＭＬメッセージとして作成される。図１６（ｂ）は、認可情報送信完了通知のうち、本実施例の説明に必要な部分のみを示している。statusタグには認可情報送信通知の受信結果が記載される。seqタグには、認可情報送信通知と認可情報送信完了通知とを対応付けるためのリクエスト番号が記載される。
【０１２４】
ＡＣＳ１００は、次サービスＩＤ格納部１０１、次サービスＩＤ特定部１０２、認可情報格納部１０３、認可判定要求部１０４、通信部１０５、およびサービス履歴格納部１０６を備える。
【０１２５】
認可情報格納部１０３には、例えば図１７に示すように、ＵＳ５００のユーザのSIP-URIを示すSubject１０３１、および、サービスＩＤを示すResource１０３２が、それぞれのレコードを識別する番号１０３０に対応付けて格納されている。
【０１２６】
サービス履歴格納部１０６には、例えば図１８に示すように、ユーザＩＤ１０６１およびサービスＩＤ１０６２の組み合わせ毎に、履歴テーブル１０６０が格納されている。それぞれの履歴テーブル１０６０には、ユーザＩＤ１０６１に対応するユーザに対して、サービスＩＤ１０６２に対応するサービスが提供された後に、当該ユーザに対して次に提供されたサービスのサービスＩＤを示す次サービスＩＤ１０６３が、当該次サービスＩＤ１０６３に対応するサービスが提供された回数１０６４に対応付けて格納されている。
【０１２７】
次サービスＩＤ特定部１０２は、認可判定要求部１０４からユーザＩＤおよびサービスＩＤを受け付けた場合に、次サービスＩＤ格納部１０１を参照して、当該サービスＩＤに対応付けられている次サービスＩＤが存在するか否かを判定する。当該サービスＩＤに対応付けられている次サービスＩＤが存在する場合、次サービスＩＤ特定部１０２は、当該次サービスＩＤを、認可判定要求部１０４から受け付けたユーザＩＤと共に認可判定要求部１０４へ送る。
【０１２８】
一方、認可判定要求部１０４から受け取ったサービスＩＤに対応付けられている次サービスＩＤが次サービスＩＤ格納部１０１内に存在しない場合、次サービスＩＤ特定部１０２は、サービス履歴格納部１０６を参照し、認可判定要求部１０４から受け取ったユーザＩＤおよびサービスＩＤに対応する履歴テーブル１０６０を特定する。そして、次サービスＩＤ特定部１０２は、特定した履歴テーブル１０６０を参照して、予め定められた閾値以上（例えば２０以上）の回数が対応付けられている次サービスＩＤを抽出し、抽出したサービスＩＤを、認可判定要求部１０４から受け取ったユーザＩＤと共に認可判定要求部１０４へ送る。図１８に示した例において、予め定められた閾値が２０回であるとすると、次サービスＩＤ特定部１０２は、２つのサービスＩＤを抽出することになる。
【０１２９】
なお、認可判定要求部１０４から受け取ったユーザＩＤおよびサービスＩＤに対応する履歴テーブル１０６０がサービス履歴格納部１０６内に存在しない場合、または、予め定められた値以上の回数が対応付けられている次サービスＩＤが履歴テーブル１０６０内に存在しない場合、次サービスＩＤ特定部１０２は、認可判定要求部１０４から受け取ったユーザＩＤを認可判定要求部１０４へ返す。
【０１３０】
認可判定要求部１０４は、通信部１０５を介して、ＣＭＳ３００から認可情報取得要求（図４（ｃ）参照）を受信した場合に、当該認可情報取得要求のsubjectタグで示されるユーザＩＤおよびresourceタグで示されるサービスＩＤの組み合わせが認可情報格納部１０３内に存在するか否かを判定する。当該ユーザＩＤおよびサービスＩＤの組み合わせが認可情報格納部１０３内に存在する場合、認可判定要求部１０４は、図４（ｄ）においてassertionタグを含まない認可情報取得応答を作成し、作成した認可情報取得応答を通信部１０５を介してＣＭＳ３００へ送信する。
【０１３１】
認可情報取得要求に含まれているユーザＩＤおよびサービスＩＤの組み合わせが認可情報格納部１０３内に存在しない場合、認可判定要求部１０４は、図４（ｅ）に示した登録情報取得要求を作成し、作成した登録情報取得要求を通信部１０５を介してＰＭＳ２００へ送信する。そして、通信部１０５を介して、図４（ｆ）に示した登録情報取得応答をＰＭＳ２００から受信した場合、認可判定要求部１０４は、図５（ｃ）に示した認可判定要求を作成し、作成した認可判定要求を、通信部１０５を介してＡｕＳ４００へ送信する。
【０１３２】
また、通信部１０５を介して図５（ｄ）に示した認可判定応答をＡｕＳ４００から受信した場合、認可判定要求部１０４は認可情報を作成する。そして、当該認可判定応答に含まれている認可判定結果が、サービスの提供を許可する旨を示す場合、認可判定要求部１０４は、作成した認可情報に含まれているユーザＩＤおよびサービスＩＤを認可情報格納部１０３に保存する。そして、認可判定要求部１０４は、認可情報取得応答（図４（ｄ）参照）を作成して、通信部１０５を介してＣＭＳ３００へ送信する。
【０１３３】
認可情報取得応答をＣＭＳ３００へ送信した後、認可判定要求部１０４は、当該認可情報取得応答の契機となった認可情報取得要求に含まれているユーザＩＤおよびサービスＩＤを次サービスＩＤ特定部１０２へ送る。そして、次サービスＩＤ特定部１０２からユーザＩＤおよび次サービスＩＤを受け取った場合、認可判定要求部１０４は、当該ユーザＩＤおよび次サービスＩＤの組み合わせが認可情報格納部１０３に登録されているか否かを判定する。
【０１３４】
当該ユーザＩＤおよび次サービスＩＤの組み合わせが認可情報格納部１０３に登録されていない場合、認可判定要求部１０４は、当該ユーザＩＤおよび次サービスＩＤを含む登録情報取得要求（図４（ｅ）参照）を作成してＰＭＳ２００へ送る。なお、当該ユーザＩＤおよび次サービスＩＤの組み合わせが認可情報格納部１０３に既に登録されている場合、または、次サービスＩＤ特定部１０２がユーザＩＤと共に次サービスＩＤを出力しなかった場合、認可判定要求部１０４は、予め認可判定を行う処理を実行しない。
【０１３５】
そして、認可判定要求部１０４は、ＰＭＳ２００から登録情報取得応答（図４（ｆ））を受け取り、受け取った登録情報取得応答に基づいて認可判定要求（図５（ｃ））を作成してＡｕＳ４００へ送る。そして、認可判定要求部１０４は、ＡｕＳ４００から認可判定応答（図５（ｄ））を受け取り、認可情報を作成する。そして、当該認可判定応答に含まれている認可判定結果が、サービスの提供を許可する旨を示す場合、認可判定要求部１０４は、作成した認可情報に含まれているユーザＩＤおよびサービスＩＤを認可情報格納部１０３に保存する。
【０１３６】
そして、認可判定要求部１０４は、作成した認可情報を含む認可情報送信通知（図１６（ａ）参照）を作成し、作成した認可情報送信通知を通信部１０５を介してＳＰ６００へ送信する。そして、認可判定要求部１０４は、通信部１０５を介して、図１６（ｂ）に示した認可情報送信完了通知を受信する。
【０１３７】
次に、第２実施例において、ユーザの要求に応じてサービスの提供が開始される場合のアクセス認可システム１０の一連の動作について図１９を用いて説明する。
【０１３８】
まず、ＵＳ５００のＳＩＰクライアント５０３は、ユーザからの要求に応じて図４（ａ）に示した通信開始要求を作成し、作成した通信開始要求をＣＭＳ３００へ送信する（Ｓ３００）。ＣＭＳ３００のＳＩＰメッセージ制御部３０４は、ＵＳ５００から受信した通信開始要求に基づいて図４（ｃ）に示した認可情報取得要求を作成し、作成した認可情報取得要求をＡＣＳ１００へ送信する（Ｓ３０１）。
【０１３９】
ＡＣＳ１００の認可判定要求部１０４は、ＣＭＳ３００から受信した認可情報取得要求に含まれるユーザＩＤおよびサービスＩＤの組み合わせが認可情報格納部１０３に格納されているか否かを判定する（Ｓ３０２）。当該ユーザＩＤおよびサービスＩＤの組み合わせが認可情報格納部１０３に格納されている場合（Ｓ３０２：Ｙｅｓ）、認可判定要求部１０４は、ステップＳ３０９に示す処理を実行する。
【０１４０】
ＣＭＳ３００から受信した認可情報取得要求に含まれるユーザＩＤおよびサービスＩＤの組み合わせが認可情報格納部１０３に格納されていない場合（Ｓ３０２：Ｎｏ）、認可判定要求部１０４は、当該ユーザＩＤおよびサービスＩＤに基づいて、図４（ｅ）に示した登録情報取得要求を作成し、作成した登録情報取得要求をＰＭＳ２００へ送信する（Ｓ３０３）。
【０１４１】
ＰＭＳ２００の情報管理部２０３は、ＡＣＳ１００から受信した登録情報取得要求に含まれているユーザＩＤおよびサービスＩＤに基づいて、サービスポリシ情報格納部２０１およびユーザ属性情報格納部２０２から対応するユーザ属性情報およびサービスポリシ情報をそれぞれ取得する。そして、情報管理部２０３は、取得したユーザ属性情報およびサービスポリシ情報を含む登録情報取得応答（図４（ｆ）参照）を作成し、作成した登録情報取得応答をＡＣＳ１００へ送信する（Ｓ３０４）。
【０１４２】
次に、ＡＣＳ１００の認可判定要求部１０４は、ＰＭＳ２００から受信した登録情報取得応答に含まれているユーザ属性情報およびサービスポリシ情報を含む認可判定要求（図５（ｃ）参照）を作成し、作成した認可判定要求をＡｕＳ４００へ送信する（Ｓ３０５）。ＡｕＳ４００の認可判定部４０１は、ＡＣＳ１００から受信した認可判定要求に含まれるユーザ属性情報が、当該認可判定要求に含まれるサービスポリシ情報を満たすか否かを判定する（Ｓ３０６）。そして、認可判定部４０１は、認可判定結果を含む認可判定応答（図５（ｄ）参照）を作成し、作成した認可判定応答をＡＣＳ１００へ送信する（Ｓ３０７）。
【０１４３】
次に、ＡＣＳ１００の認可判定要求部１０４は、ＡｕＳ４００から受信した認可判定応答に基づいて、図５（ｅ）に示した認可情報を作成し、当該認可応答に含まれる判定結果がサービスの利用を許可する旨を示す場合に、当該認可情報に含まれているユーザＩＤおよびサービスＩＤを認可情報格納部１０３に保存する（Ｓ３０８）。そして、認可判定要求部１０４は、図４（ｄ）に示した認可情報取得応答を作成し、作成した認可情報取得応答をＣＭＳ３００へ送信する（Ｓ３０９）。
【０１４４】
次に、ＣＭＳ３００のＳＩＰメッセージ制御部３０４は、図４（ａ）に示した通信開始要求において、宛先をサービスＩＤに対応するサービスを提供するＳＰ６００のSIP-URIとし、ＡＣＳ１００から受信した認可情報取得応答に含まれている認可情報を含めた通信開始要求を作成し、作成した通信開始要求をＳＰ６００へ送信する（Ｓ３１０）。
【０１４５】
ＳＰ６００のＳＩＰクライアント６０３は、ＣＭＳ３００から受信した通信開始要求に応じて、図４（ｂ）に示した通信開始応答を作成し、作成した通信開始応答をＣＭＳ３００へ送信する（Ｓ３１１）。ＣＭＳ３００のＳＩＰメッセージ制御部３０４は、ＳＰ６００から受信した通信開始応答の一部を書き換えてＵＳ５００へ送信する（Ｓ３１２）。そして、ＳＰ６００のサービスアプリケーション６０２は、ＵＳ５００へのサービスの提供を開始する（Ｓ３１３）。
【０１４６】
なお、ステップＳ３０２において、ＣＭＳ３００から受信した認可情報取得要求に含まれるユーザＩＤおよびサービスＩＤの組み合わせが認可情報格納部１０３に格納されていると判定された後に（Ｓ３０２：Ｙｅｓ）、ステップＳ３０９において送信される認可情報取得応答およびステップＳ３１０において送信される通信開始要求には、認可情報が含まれない。
【０１４７】
次に、ＡＣＳ１００の認可判定要求部１０４は、ステップＳ３０９において送信した認可情報取得応答内の認可情報に含まれているユーザＩＤおよびサービスＩＤを次サービスＩＤ特定部１０２へ送る。次サービスＩＤ特定部１０２は、次サービスＩＤ格納部１０１またはサービス履歴格納部１０６を参照して、当該サービスＩＤに対応付けられている次サービスＩＤを抽出することにより、次に提供されるべきサービスのサービスＩＤを特定する（Ｓ３１４）。
【０１４８】
次に、次サービスＩＤ特定部１０２は、特定した次サービスＩＤを、認可判定要求部１０４から受け付けたユーザＩＤと共に認可判定要求部１０４へ返す。そして、認可判定要求部１０４は、次サービスＩＤ特定部１０２から受信したユーザＩＤおよびサービスＩＤを用いて、ステップＳ３０２からステップＳ３０８に示した処理Ｂを実行する（Ｓ３１５）。
【０１４９】
そして、認可判定要求部１０４は、図１６（ａ）に示した認可情報送信通知をＳＰ６００へ送信する（Ｓ３１６）。ＳＰ６００のＳＩＰクライアント６０３は、受信した認可情報送信通知に含まれているユーザＩＤ、サービスＩＤ、および認可情報を通信管理テーブル格納部６０４に格納し、図１６（ｂ）に示した認可情報送信完了通知をＡＣＳ１００へ送信する（Ｓ３１７）。
【０１５０】
次に、第２実施例において、ＵＳ５００を介したユーザによる登録情報の更新に関する一連の処理について図２０を用いて説明する。
【０１５１】
まず、ＵＳ５００のＳＩＰクライアント５０３は、ユーザからの要求に応じて図６（ａ）に示した登録情報更新要求を作成し、作成した登録情報更新要求をＣＭＳ３００へ送信する（Ｓ４００）。ＣＭＳ３００のＳＩＰメッセージ制御部３０４は、ＵＳ５００から受信した登録情報更新要求に基づいて図６（ｃ）に示した登録情報更新要求を作成し、作成した登録情報更新要求をＡＣＳ１００へ送信する（Ｓ４０１）。
【０１５２】
ＡＣＳ１００の認可判定要求部１０４は、ＣＭＳ３００から受信した登録情報更新要求をＰＭＳ２００へ転送する（Ｓ４０２）。ＰＭＳ２００の情報管理部２０３は、ＡＣＳ１００から受信した登録要求更新要求に含まれているユーザＩＤに対応するユーザ属性情報格納部２０２内のユーザ属性情報を、当該登録情報更新要求に含まれているユーザ属性情報で更新する（Ｓ４０３）。そして、情報管理部２０３は、図６（ｄ）に示した登録情報更新応答を作成し、作成した登録情報更新応答をＡＣＳ１００へ送信する（Ｓ４０４）。
【０１５３】
次に、ＡＣＳ１００の認可判定要求部１０４は、ステップＳ４０１で受信した登録情報更新要求に含まれているユーザＩＤが認可情報格納部１０３に格納されているか否かを判定する（Ｓ４０５）。当該ユーザＩＤが認可情報格納部１０３に格納されていない場合（Ｓ４０５：Ｎｏ）、認可判定要求部１０４は、ステップＳ４１３に示す処理を実行する。
【０１５４】
ステップＳ４０１で受信した登録情報更新要求に含まれているユーザＩＤが認可情報格納部１０３に格納されている場合（Ｓ４０５：Ｙｅｓ）、認可判定要求部１０４は、当該ユーザＩＤに対応付けられているサービスＩＤを認可情報格納部１０３から抽出し、抽出したそれぞれのサービスＩＤについて、図６（ｅ）に示した認可情報削除要求を作成し、作成した認可情報削除要求を送信する（Ｓ４０６、Ｓ４０９）。本例では、ＳＰ６００−αとＳＰ６００−βにはサービスの提供を許可する旨を示す認可情報が既に渡されており、ＳＰ６００−γにはサービスの提供を許可する旨を示す認可情報が渡されていないものとする。
【０１５５】
ＳＰ６００−αおよびＳＰ６００−βのそれぞれのＳＩＰクライアント６０３は、通信管理テーブル格納部６０４を参照して、ＡＣＳ１００から受信した認可情報削除要求に含まれているユーザＩＤに対応するレコードを通信管理テーブル６０４０から全て削除する（Ｓ４０７、Ｓ４１０）。そして、ＳＩＰクライアント６０３は、図６（ｆ）に示した認可情報削除応答を作成し、作成した認可情報削除応答をＡＣＳ１００へ送信する（Ｓ４０８、Ｓ４１１）。
【０１５６】
次に、ＡＣＳ１００の認可判定要求部１０４は、ステップＳ４０１で受信した登録情報更新要求に含まれているユーザＩＤを含むレコードを認可情報格納部１０３から全て削除し（Ｓ４１２）、ステップＳ４０４で受信した登録情報更新応答をＣＭＳ３００へ転送する（Ｓ４１３）。ＣＭＳ３００のＳＩＰメッセージ制御部３０４は、ＡＣＳ１００から受信した登録情報更新応答に基づいて、図６（ｂ）に示した登録情報更新応答を作成し、作成した登録情報更新応答をＵＳ５００へ送信する（Ｓ４１４）。
【０１５７】
以上、本発明の第２実施例について説明した。本実施例のアクセス認可システム１０においても、ユーザから要求されたサービスの提供開始までのユーザの待ち時間を少なくすることができる。
【０１５８】
また、本実施例において、ＡＣＳ１００は、事前に行った認可判定の結果を、その認可判定結果を使用するＳＰ６００へ即座に送信する。これにより、ＡＣＳ１００からＣＭＳ３００へ送信される認可情報取得応答、および、ＣＭＳ３００からＳＰ６００へ送信される通信開始要求内に認可情報を記述する必要がない。そのため、ユーザからサービスの提供を要求されてから送受信される認可情報取得応答および通信開始要求のデータ量を少なくすることができる。従って、アクセス認可システム１０は、ユーザからサービスの提供を要求されてからのデータ通信にかかる時間を少なくすることができ、サービス提供開始までのユーザの待ち時間を少なくすることができる。
【０１５９】
＜実施例３＞
次に、本発明の第３実施例について説明する。本実施例のビジネスプロセス実行システム４０は、ＳＡＭＬによってアクセス制御を実現している複数のＷｅｂサービスをサービスシナリオに従って連携させることで１つのサービスを実現するものである。
【０１６０】
図２１は、第３実施例におけるビジネスプロセス実行システム４０の構成を例示するシステム構成図である。ビジネスプロセス実行システム４０は、ポリシ管理サーバ（ＰＭＳ）２００、認可サーバ（ＡｕＳ）４００、ユーザ端末（ＵＳ）５００、複数のサービス提供サーバ（ＳＰ）６００、サービス実行サーバ（ＳＥＳ）７００、および属性管理サーバ（ＡＳ）８００を備える。
【０１６１】
図２１に示すビジネスプロセス実行システム４０は、ユーザがＵＳ５００を介してＳＥＳ７００で提供されているサービスシナリオを利用する際に、ＳＥＳ７００がＡｕＳ４００と連携して当該ユーザに対して当該サービスシナリオに含まれるそれぞれのＷｅｂサービスの提供が許可されているか否かを判定する認可判定を行い、その結果に基づいてサービスシナリオに規定されている順番でそれぞれのＷｅｂサービスを順次呼び出す。
【０１６２】
次に、本実施例におけるビジネスプロセス実行システム４０の各構成要素が備える機能について説明する。なお、以下に説明する点を除き、図２１において、図１と同じ符号を付した構成は、図１における構成と同一または同様の機能を有するため説明を省略する。
【０１６３】
まず、ＳＥＳ７００について説明する。ＳＥＳ７００は、シナリオ格納部７０１、プロセス情報格納部７０２、シナリオ実行部７０３、および通信部７０４を備える。通信部７０４は、シナリオ実行部７０３からの指示に応じて、ネットワーク１１を介して他の装置と通信を行う。
【０１６４】
シナリオ格納部７０１には、例えば図２２に示すように、サービスシナリオ７０１１を、それぞれのサービスシナリオを識別するシナリオＩＤ７０１０に対応付けて格納している。ここで、サービスシナリオとは、例えば図２３に示すようにＸＭＬ形式で記述され、１つ以上のＳＰ６００で提供されているＷｅｂサービスをどの順序で連携させていくかを規定するものである。
【０１６５】
図２３には、シナリオＩＤが「Scenario1」であるサービスシナリオ５０が例示されている。図２３のサービスシナリオ５０には、それぞれのＷｅｂサービスを識別するサービスＩＤが「SpAlpha」であるＷｅｂサービスを実行した後に（記述５３参照）、サービスＩＤが「SpBeta」であるＷｅｂサービスが実行可能であれば（記述５５参照）、サービスＩＤが「SpBeta」であるＷｅｂサービスを実行し（記述５６参照）、さもなければサービスＩＤが「SpGamma」であるＷｅｂサービスを実行する（記述５８参照）という連携順序が規定されている。
【０１６６】
プロセス情報格納部７０２には、例えば図２４に示すように、それぞれのビジネスプロセスを識別するプロセスＩＤ７０２０に対応付けて、実行中のサービスシナリオのシナリオＩＤ７０２１、実行中のＷｅｂサービスのサービスＩＤを示す現在実行点７０２２、および実行が禁止されているＷｅｂサービスのサービスＩＤを示す禁止サービス７０２３が格納されている。図２４に示したプロセス情報格納部７０２において、プロセスＩＤが「１」のビジネスプロセスでは、シナリオＩＤが「Scenario1」であるサービスシナリオが実行中であり、その中でサービスＩＤが「SpAlpha」であるＷｅｂサービスが実行中であり、サービスＩＤが「SpGamma」であるＷｅｂサービスの実行が禁止されていることを示す情報等が格納されている。
【０１６７】
シナリオ実行部７０３は、通信部７０４を介してＵＳ５００から、ユーザＩＤおよびシナリオＩＤを含むサービス要求を受信した場合に、プロセスＩＤを生成し、生成したプロセスＩＤに対応付けて、当該シナリオＩＤをプロセス情報格納部７０２に登録する（このとき、現在実行点および禁止サービスの欄は空欄となる）。そして、シナリオ実行部７０３は、当該シナリオＩＤに対応するサービスシナリオをシナリオ格納部７０１から抽出して、当該サービスシナリオに実行順番が規定されているそれぞれのＷｅｂサービスのサービスＩＤを抽出する。そして、シナリオ実行部７０３は、例えば図２５（ａ）に示すような認可判定要求６０を生成し、生成した認可判定要求６０を通信部７０４を介してＡｕＳ４００へ送信する。
【０１６８】
認可判定要求６０には、例えば図２５（ａ）に示すように、それぞれの認可判定要求６０を識別する識別子（記述６１参照）と、認可判定の対象となるサービスシナリオに関する情報（記述６２参照）、および、当該サービスシナリオに含まれる１つ以上のＷｅｂサービスに関する情報（記述６３から記述６５参照）が含まれる。認可判定要求６０を識別する識別子には、例えばプロセスＩＤが用いられる。
【０１６９】
図２５（ａ）において、記述６２には、対象となるサービスシナリオのシナリオＩＤである「Scenario1」と、当該サービスシナリオに対する認可判定の対象となるユーザのユーザＩＤである「User1」とが記述されており、記述６３には、対象となるＷｅｂサービスのサービスＩＤである「SpAlpha」と、当該Ｗｅｂサービスに対する認可判定の対象となるユーザのユーザＩＤである「User1」とが記述されており、記述６４には、対象となるＷｅｂサービスのサービスＩＤである「SpBeta」と、当該Ｗｅｂサービスに対する認可判定の対象となるユーザのユーザＩＤである「User1」とが記述されており、記述６５には、対象となるＷｅｂサービスのサービスＩＤである「SpGamma」と、当該Ｗｅｂサービスに対する認可判定の対象となるユーザのユーザＩＤである「User1」とが記述されている。
【０１７０】
シナリオ実行部７０３は、認可判定要求６０に対する応答として、例えば図２５（ｂ）に示すような認可判定結果７０を、通信部７０４を介してＡｕＳ４００から受信する。認可判定結果７０には、それぞれの認可判定結果７０を識別する識別子（記述７１参照）と、認可判定の対象となるサービスシナリオに関する認可判定結果（記述７２参照）、および、当該サービスシナリオに含まれる１つ以上のＷｅｂサービスに関する認可判定結果（記述７３から記述７５参照）が含まれる。認可判定結果７０を識別する識別子には、対応する認可判定要求６０の識別情報が記述される。
【０１７１】
図２５（ｂ）に示した例おいて、記述７２には、対象となるサービスシナリオのシナリオＩＤである「Scenario1」と、当該サービスシナリオに対する認可判定結果が許可（Permit）である旨とが記述されており、記述７３には、対象となるＷｅｂサービスのサービスＩＤである「SpAlpha」と、当該Ｗｅｂサービスに対する認可判定結果が許可（Permit）である旨とが記述されており、記述７４には、対象となるＷｅｂサービスのサービスＩＤである「SpBeta」と、当該Ｗｅｂサービスに対する認可判定結果が許可（Permit）である旨とが記述されており、記述７５には、対象となるＷｅｂサービスのサービスＩＤである「SpGamma」と、当該Ｗｅｂサービスに対する認可判定結果が拒否（Deny）である旨とが記述されている。
【０１７２】
シナリオ実行部７０３は、ＡｕＳ４００から認可判定結果７０を受信した場合に、受信した認可判定結果７０に基づいて例えば図２６および図２７に示す禁止サービス登録処理を実行することにより、ユーザから要求されたサービスシナリオに含まれるそれぞれのサービスについて、禁止サービスとして登録すべきか否かを判定し、禁止サービスとして登録すべきと判定されたサービスのサービスＩＤを、プロセスＩＤに対応付けてプロセス情報格納部７０２に登録する。
【０１７３】
図２６において、まず、シナリオ実行部７０３は、ユーザから指定されたサービスシナリオが許可されているか否かを判定する（Ｓ５００）。ユーザから指定されたサービスシナリオが許可されていない場合（Ｓ５００：Ｎｏ）、シナリオ実行部７０３は、当該サービスシナリオに規定されている最初のＷｅｂサービスを禁止サービスとしてプロセスＩＤに対応付けてプロセス情報格納部７０２に登録し（Ｓ５０５）、シナリオ実行部７０３は、本フローチャートに示す処理を終了する。
【０１７４】
ユーザから指定されたサービスシナリオが許可されている場合（Ｓ５００：Ｙｅｓ）、シナリオ実行部７０３は、当該サービスシナリオに規定されている最初のＷｅｂサービスが許可されているか否かを判定する（Ｓ５０１）。最初のＷｅｂサービスが許可されていない場合（すなわち、認可判定結果が拒否である場合）（Ｓ５０１：Ｎｏ）、シナリオ実行部７０３は、ステップＳ５０５に示した処理を実行する。
【０１７５】
最初のＷｅｂサービスが許可されている場合（Ｓ５０１：Ｙｅｓ）、シナリオ実行部７０３は、ユーザから指定されたサービスシナリオに基づいて、次に提供されるべきＷｅｂサービスを特定し、当該次に提供されるべきＷｅｂサービスの中で、許可されているＷｅｂサービスが少なくとも１つ存在するか否かを判定する（Ｓ５０２）。次に提供されるべきＷｅｂサービスが全て許可されていない場合（Ｓ５０２：Ｎｏ）、シナリオ実行部７０３は、ステップＳ５０５に示した処理を実行する。
【０１７６】
次に提供されるべきＷｅｂサービスの少なくとも１つが許可されている場合（Ｓ５０２：Ｙｅｓ）シナリオ実行部７０３は、次に提供されるべきＷｅｂサービスの中で、許可されていないサービスがあればそのサービスのサービスＩＤを禁止サービスとしてプロセスＩＤに対応付けてプロセス情報格納部７０２に登録する（Ｓ５０３）。そして、シナリオ実行部７０３は、許可されている次のＷｅｂサービスについて後述する禁止判定処理を実行する（Ｓ６００）。
【０１７７】
次に、シナリオ実行部７０３は、次に提供されるべき全てのＷｅｂサービスが禁止サービスとしてプロセス情報格納部７０２に登録されているか否かを判定する（Ｓ５０４）。次に提供されるべき全てのＷｅｂサービスが禁止サービスとしてプロセス情報格納部７０２に登録されている場合（Ｓ５０４：Ｙｅｓ）、シナリオ実行部７０３は、ステップＳ５０５に示した処理を実行する。一方、次に提供されるべき少なくとも１つのＷｅｂサービスが禁止サービスとしてプロセス情報格納部７０２に登録されていない場合（Ｓ５０４：Ｎｏ）、シナリオ実行部７０３は、本フローチャートに示した処理を終了する。
【０１７８】
図２７は、シナリオ実行部７０３によって実行される禁止判定処理（Ｓ６００）の一例を示すフローチャートである。
【０１７９】
まず、シナリオ実行部７０３は、許可されている次のＷｅｂサービスの中で、未選択のＷｅｂサービスを１つ選択し（Ｓ６０１）、ユーザから指定されたサービスシナリオを参照して、選択したＷｅｂサービスの次に提供されるべきＷｅｂサービスが存在するか否かを判定する（Ｓ６０２）。選択したＷｅｂサービスの次に提供されるべきＷｅｂサービスが存在しない場合（Ｓ６０２：Ｎｏ）、シナリオ実行部７０３は、ステップＳ６０６に示す処理を実行する。
【０１８０】
選択したＷｅｂサービスの次に提供されるべきＷｅｂサービスが存在する場合（Ｓ６０２：Ｙｅｓ）、シナリオ実行部７０３は、ユーザから指定されたサービスシナリオに基づいて、ステップＳ６０１において選択されたＷｅｂサービスの次に提供されるべきＷｅｂサービスを特定し、当該次に提供されるべきＷｅｂサービスの中で、許可されているＷｅｂサービスが少なくとも１つ存在するか否かを判定する（Ｓ６０３）。
【０１８１】
次に提供されるべきＷｅｂサービスが全て許可されていない場合（Ｓ６０３：Ｎｏ）、シナリオ実行部７０３は、ステップＳ６０１において選択されたＷｅｂサービスのサービスＩＤを禁止サービスとしてプロセスＩＤに対応付けてプロセス情報格納部７０２に登録し（Ｓ６０５）、ステップＳ６０６に示す処理を実行する。
【０１８２】
次に提供されるべきＷｅｂサービスの中で、許可されているＷｅｂサービスが少なくとも１つ存在する場合（Ｓ６０３：Ｙｅｓ）、シナリオ実行部７０３は、許可されている次のＷｅｂサービスについて禁止判定処理を再帰呼び出しにより実行する（Ｓ６００）。そして、シナリオ実行部７０３は、ステップＳ６０１において選択されたＷｅｂサービスの次に提供されるべき全てのＷｅｂサービスが禁止サービスとしてプロセス情報格納部７０２に登録されているか否かを判定する（Ｓ６０４）。
【０１８３】
ステップＳ６０１において選択されたＷｅｂサービスの次に提供されるべき全てのＷｅｂサービスが禁止サービスとしてプロセス情報格納部７０２に登録されている場合（Ｓ６０４：Ｙｅｓ）、シナリオ実行部７０３は、ステップＳ６０５に示した処理を実行する。一方、ステップＳ６０１において選択されたＷｅｂサービスの次に提供されるべきＷｅｂサービスの少なくとも１つが、禁止サービスとしてプロセス情報格納部７０２に登録されていない場合（Ｓ６０４：Ｎｏ）、シナリオ実行部７０３は、許可されているＷｅｂサービスがステップＳ６０１において全て選択されたか否かを判定する（Ｓ６０６）。
【０１８４】
許可されているＷｅｂサービスがステップＳ６０１において全て選択されていない場合（Ｓ６０６：Ｎｏ）、シナリオ実行部７０３は、再びステップＳ６０１に示した処理を実行する。一方、許可されているＷｅｂサービスがステップＳ６０１において全て選択された場合（Ｓ６０６：Ｙｅｓ）、シナリオ実行部７０３は、本フローチャートに示した禁止判定処理を終了する。
【０１８５】
図２６および図２７に示した処理を実行した後、シナリオ実行部７０３は、プロセス情報格納部７０２を参照して、ユーザから要求されたサービスシナリオに規定されている最初のＷｅｂサービスが禁止サービスとしてプロセス情報格納部７０２に登録されていない場合に、当該最初のＷｅｂサービスを提供するＳＰ６００に対して、当該ＷｅｂサービスのサービスＩＤおよび当該Ｗｅｂサービスの提供対象となるユーザのユーザＩＤを含むサービス呼出を送信することにより、ユーザに一連のビジネスプロセスの提供を開始する。そして、シナリオ実行部７０３は、プロセス情報格納部７０２の現在実行点に、最初のＷｅｂサービスのサービスＩＤを登録する。なお、最初のＷｅｂサービスが禁止サービスとしてプロセス情報格納部７０２に登録されている場合、シナリオ実行部７０３は、指定されたサービスシナリオが実行できない旨をＵＳ５００に通知する。
【０１８６】
また、シナリオ実行部７０３は、ユーザから指定されたサービスシナリオに従って、順次ＷｅｂサービスをＳＰ６００に実行させる過程で、一連のビジネスプロセスの状態を示す情報を管理する。そして、サービスシナリオに従って、現在提供されているＷｅｂサービスの次に提供されるべきＷｅｂサービスが異なる分岐が存在する場合、シナリオ実行部７０３は、一連のビジネスプロセスの状態を示す情報に応じて、次に提供されるべきＷｅｂサービスを特定し、特定したＷｅｂサービスをＳＰ６００に実行させる。
【０１８７】
なお、一連のビジネスプロセスの状態を示す情報に応じて特定した、次に提供されるべきＷｅｂサービスが、禁止サービスとしてプロセス情報格納部７０２に登録されている場合、シナリオ実行部７０３は、Ｗｅｂサービスの提供が許可されてない旨と共に当該Ｗｅｂサービスに関する情報をＵＳ５００に通知する。これにより、シナリオ実行部７０３は、ＵＳ５００のユーザが、それ以降のＷｅｂサービスの提供を無駄に受けることを防止することができる。
【０１８８】
次に、ＡｕＳ４００について説明する。ＡｕＳ４００は、認可判定部４０１および通信部４０２を備える。認可判定部４０１は、通信部４０２を介してＳＥＳ７００から図２５（ａ）に示した認可判定要求６０を受信した場合に、当該認可判定要求６０に含まれているシナリオＩＤおよびサービスＩＤのそれぞれについて、例えば図２８（ｃ）に示すようなポリシ取得要求８２を作成し、作成したポリシ取得要求８２を通信部４０２を介してＰＭＳ２００へ送信する。図２８（ｃ）には、サービスシナリオに関するポリシを要求するポリシ取得要求８２が示されている。
【０１８９】
そして、通信部４０２を介してＰＭＳ２００から、例えば図２８（ｄ）に示すようなポリシ取得応答８３を受信した場合、認可判定部４０１は、当該ポリシ取得応答８３に示されているユーザのパラメータ（図２８（ｄ）の例では年齢）、および、ＳＥＳ７００から受信した認可判定要求６０に含まれているユーザＩＤを含む属性取得要求を作成し、作成した属性取得要求を通信部４０２を介してＡＳ８００へ送信する。本実施例において、属性取得要求は、例えば図２８（ａ）に示すようなデータ構造である。
【０１９０】
そして、通信部４０２を介してＡＳ８００から、例えば図２８（ｂ）に示すような属性取得応答８１を受信した場合、認可判定部４０１は、認可判定要求６０で指定されたシナリオＩＤに対応するサービスシナリオおよびサービスＩＤに対応するＷｅｂサービスのそれぞれについて、属性取得応答８１に含まれているユーザの属性が、ポリシ取得応答８３に含まれているサービスポリシを満たしているか否かを判定する認可判定を実行する。
【０１９１】
そして、認可判定部４０１は、図２５（ｂ）で説明した認可判定結果７０を作成し、作成した認可判定結果７０を通信部４０２を介してＳＥＳ７００へ送信する。また、認可判定部４０１は、それぞれのサービスＩＤにおいて、認可判定の結果が「許可」であるものについて、当該認可判定の結果を、対象となるユーザのユーザＩＤと共に、当該サービスＩＤに対応するＷｅｂサービスを提供するＳＰ６００に通知する。
【０１９２】
なお、本実施例では、１つの属性取得要求８０において１人のユーザのユーザ属性情報を要求するようにしているが、他の例として、１つの属性取得要求８０で複数のユーザのユーザ属性情報を要求するようにしてもよい。具体的には、属性取得要求８０内にユーザ毎にAttributeQueryタグを作成すればよい。また、本実施例では、１つのポリシ取得要求８２において１つのＷｅｂサービスのサービスポリシ情報を要求するようにしているが、他の例として、１つのポリシ取得要求８２で複数のＷｅｂサービスのサービスポリシ情報を要求するようにしてもよい。具体的には、ポリシ取得要求８２内にＷｅｂサービス毎にAttributeQueryタグを作成すればよい。このようにすることで、ＡｕＳ４００とＰＭＳ２００間の通信トラフィックを低減することができる。
【０１９３】
次に、ＰＭＳ２００について説明する。ＰＭＳ２００は、サービスポリシ情報格納部２０１、通信部２０４、シナリオポリシ情報格納部２０５、およびポリシ情報管理部２０６を備える。サービスポリシ情報格納部２０１には、図１０で説明した構造のデータが格納されている。シナリオポリシ情報格納部２０５には、例えば図２９に示すように、シナリオＩＤ２０５０に対応付けて、当該シナリオＩＤ２０５０に対応するサービスシナリオのシナリオポリシ情報の実体が格納されているＰＭＳ２００のメモリ内の場所を示す参照先アドレス２０５１が格納されている。
【０１９４】
ポリシ情報管理部２０６は、通信部２０４を介してＡｕＳ４００から図２８（ｃ）に示したポリシ取得要求８２を受信した場合に、当該ポリシ取得要求８２にサービスＩＤが格納されているならば、当該サービスＩＤに対応するサービスポリシ情報をサービスポリシ情報格納部２０１を参照して取得し、当該ポリシ取得要求８２にシナリオＩＤが格納されているならば、当該シナリオＩＤに対応するシナリオポリシ情報をシナリオポリシ情報格納部２０５を参照して取得する。そして、ポリシ情報管理部２０６は、取得したサービスポリシ情報またはシナリオポリシ情報を含むポリシ取得応答８３を作成し、作成したポリシ取得応答８３を通信部２０４を介してＡｕＳ４００へ送信する。
【０１９５】
次に、ＡＳ８００について説明する。ＡＳ８００は、ユーザ属性情報格納部８０１、属性情報管理部８０２、および通信部８０３を備える。通信部８０３は、属性情報管理部８０２からの指示に応じて、ネットワーク１１を介して他の装置と通信を行う。ユーザ属性情報格納部８０１には、例えば図１１で説明した構造のデータが格納されている。
【０１９６】
属性情報管理部８０２は、通信部８０３を介してＡｕＳ４００から図２８（ａ）に示した属性取得要求８０を受信した場合に、当該属性取得要求８０に格納されているユーザＩＤに対応するユーザ属性情報をユーザ属性情報格納部８０１から抽出する。そして、属性情報管理部８０２は、抽出したユーザ属性情報を含む属性取得応答８１を作成し、作成した属性取得応答８１を通信部８０３を介してＡｕＳ４００へ送信する。
【０１９７】
次に、ＳＰ６００について説明する。ＳＰ６００は、通信部６０１、サービスアプリケーション６０２、認可判定取得部６０６、および認可判定結果格納部６０７を備える。
【０１９８】
認可判定取得部６０６は、通信部６０１を介してＡｕＳ４００から、認可判定の結果が「許可」であるユーザのユーザＩＤを受信した場合に、受信したユーザＩＤを認可判定結果格納部６０７に格納する。なお、ＳＰ６００によって提供可能なＷｅｂサービスが複数存在する場合、ＡｕＳ４００は、ユーザＩＤおよび「許可」である認可判定の結果と共に、対象となるＷｅｂサービスのサービスＩＤをＳＰ６００へ送信し、認可判定取得部６０６は、認可判定の結果が「許可」であるユーザのユーザＩＤを、対象となるサービスのサービスＩＤと共に認可判定結果格納部６０７に格納する。
【０１９９】
サービスアプリケーション６０２は、通信部６０１を介してＳＥＳ７００からサービス呼出を受信した場合に、当該サービス呼出に含まれているユーザＩＤが認可判定結果格納部６０７に格納されているか否かを判定し、当該ユーザＩＤが認可判定結果格納部６０７に格納されている場合に、当該ユーザＩＤに対応するユーザに対してＷｅｂサービスの提供が許可されているものと判定し、当該ユーザＩＤに対応するユーザに対してＷｅｂサービスを提供する。
【０２００】
次に、第３実施例において、ユーザの要求に応じてＷｅｂサービスの提供が開始される場合のビジネスプロセス実行システム４０の一連の動作について図３０を用いて説明する。
【０２０１】
まず、ＵＳ５００の通信アプリケーション５０２は、ユーザからの要求に応じてサービス要求を作成し、作成したサービス要求を通信部５０１を介してＳＥＳ７００へ送信する（Ｓ７００）。ＳＥＳ７００のシナリオ実行部７０３は、通信部７０４を介してサービス要求を受信した場合に、プロセスＩＤを生成し、生成したプロセスＩＤに対応付けて、当該サービス要求に含まれているシナリオＩＤをプロセス情報格納部７０２に登録する。そして、シナリオ実行部７０３は、当該シナリオＩＤに対応するサービスシナリオをシナリオ格納部７０１から取得して（Ｓ７０１）、当該サービスシナリオに実行順番が規定されているそれぞれのＷｅｂサービスのサービスＩＤを抽出する。そして、シナリオ実行部７０３は、例えば図２５（ａ）に示した認可判定要求６０を生成し、生成した認可判定要求６０を通信部７０４を介してＡｕＳ４００へ送信する（Ｓ７０２）。
【０２０２】
次に、ＡｕＳ４００の認可判定部４０１は、通信部４０２を介してＳＥＳ７００から図２５（ａ）に示した認可判定要求６０を受信した場合に、後述する認可判定処理を実行する（Ｓ８００）。そして、認可判定部４０１は、図２５（ｂ）で説明した認可判定結果７０を作成し、作成した認可判定結果７０を通信部４０２を介してＳＥＳ７００へ送信する（Ｓ７０３）。そして、認可判定部４０１は、それぞれのサービスＩＤにおいて、認可判定の結果が「許可」であるものについて、当該認可判定の結果を、対象となるユーザのユーザＩＤと共に、当該サービスＩＤに対応するＷｅｂサービスを提供するＳＰ６００に通知する（Ｓ７０４）。それぞれのＳＰ６００の認可判定取得部６０６は、通信部６０１を介してＡｕＳ４００から受信した、認可判定の結果が「許可」であるユーザのユーザＩＤを認可判定結果格納部６０７に格納する（Ｓ７０５）。
【０２０３】
次に、ＳＥＳ７００のシナリオ実行部７０３は、ＡｕＳ４００から受信した認可判定結果に基づいて、図２６および図２７において説明した禁止サービス登録処理を実行する（Ｓ７０６）。そして、シナリオ実行部７０３は、プロセス情報格納部７０２を参照して、ユーザから要求されたサービスシナリオに規定されている最初のＷｅｂサービスが禁止サービスとしてプロセス情報格納部７０２に登録されているか否かを判定する（Ｓ７０７）。
【０２０４】
最初のＷｅｂサービスが禁止サービスとしてプロセス情報格納部７０２に登録されている場合（Ｓ７０７：Ｙｅｓ）、シナリオ実行部７０３は、指定されたサービスシナリオが実行できない旨を示すエラー通知をＵＳ５００へ送信する（Ｓ７０８）。一方、最初のＷｅｂサービスが禁止サービスとしてプロセス情報格納部７０２に登録されていない場合（Ｓ７０７：Ｎｏ）、シナリオ実行部７０３は、当該最初のＷｅｂサービスを提供するＳＰ６００αに対して、当該ＷｅｂサービスのサービスＩＤおよび当該Ｗｅｂサービスの提供対象となるユーザのユーザＩＤを含むサービス呼出を送信する（Ｓ７０９）。そして、シナリオ実行部７０３は、プロセス情報格納部７０２の現在実行点に、最初のＷｅｂサービスのサービスＩＤを登録する。
【０２０５】
次に、ＳＰ６００αのサービスアプリケーション６０２は、受信したサービス呼出に含まれているユーザＩＤが認可判定結果格納部６０７に格納されている場合に、当該ユーザＩＤに対応するユーザに対してＷｅｂサービスの提供が許可されているものと判定し、当該ユーザＩＤに対応するユーザのＵＳ５００に対してＷｅｂサービスを提供する（Ｓ７１０）。
【０２０６】
そして、Ｗｅｂサービスの提供が終了した場合、サービスアプリケーション６０２は、提供されたＷｅｂサービスの実行結果を示す情報と共に、当該Ｗｅｂサービスの提供が終了した旨をＳＥＳ７００に通知する（Ｓ７１１）。ＳＥＳ７００のシナリオ実行部７０３は、Ｗｅｂサービスの実行結果を示す情報に基づいて一連のビジネスプロセスの状態を示す情報を更新する。そして、シナリオ実行部７０３は、ユーザから指定されたサービスシナリオを参照して、次に提供されるべきＷｅｂサービスが存在するか否かを判定する（Ｓ７１２）。次に提供されるべきＷｅｂサービスが存在しない場合（Ｓ７１２：Ｎｏ）、シナリオ実行部７０３は、ビジネスプロセスの終了をユーザのＵＳ５００に通知する（Ｓ７１３）。
【０２０７】
次に提供すべきＷｅｂサービスが存在する場合（Ｓ７１２：Ｙｅｓ）、シナリオ実行部７０３は、当該次に提供すべきＷｅｂサービスを提供するＳＰ６００αに対して、当該ＷｅｂサービスのサービスＩＤおよび当該Ｗｅｂサービスの提供対象となるユーザのユーザＩＤを含むサービス呼出を送信する（Ｓ７１４）。そして、シナリオ実行部７０３は、プロセス情報格納部７０２の現在実行点に、当該次に提供すべきＷｅｂサービスのサービスＩＤを登録する。
【０２０８】
ＳＰ６００αのサービスアプリケーション６０２は、受信したサービス呼出に含まれているユーザＩＤが認可判定結果格納部６０７に格納されている場合に、当該ユーザＩＤに対応するユーザのＵＳ５００に対してＷｅｂサービスを提供する（Ｓ７１６）。そして、Ｗｅｂサービスの提供が終了した場合に、サービスアプリケーション６０２は、提供されたＷｅｂサービスの実行結果を示す情報と共に、当該Ｗｅｂサービスの提供が終了した旨をＳＥＳ７００に通知する（Ｓ７１１）。ＳＥＳ７００のシナリオ実行部７０３は、Ｗｅｂサービスの実行結果を示す情報に基づいて一連のビジネスプロセスの状態を示す情報を更新し、再びステップＳ７１２に示した処理を実行する。
【０２０９】
図３１は、認可判定処理（Ｓ８００）の一例を示すシーケンス図である。
【０２１０】
まず、ＡｕＳ４００の認可判定部４０１は、通信部４０２を介してＳＥＳ７００から図２５（ａ）に示した認可判定要求６０を受信した場合に、当該認可判定要求６０に含まれているシナリオＩＤおよびサービスＩＤのそれぞれについて、例えば図２８（ｃ）に示すようなポリシ取得要求８２を作成し、作成したポリシ取得要求８２を通信部４０２を介してＰＭＳ２００へ送信する（Ｓ８０１）。
【０２１１】
ＰＭＳ２００のポリシ情報管理部２０６は、通信部２０４を介してＡｕＳ４００から受信したポリシ取得要求８２にサービスＩＤが含まれている場合にはサービスポリシ情報格納部２０１を参照して対応するサービスポリシ情報を取得し、ポリシ取得要求８２にシナリオＩＤが含まれている場合にはシナリオポリシ情報格納部２０５を参照して対応するシナリオポリシ情報を取得する（Ｓ８０２）。そして、ポリシ情報管理部２０６は、取得したサービスポリシ情報またはシナリオポリシ情報を含むポリシ取得応答８３を作成し、作成したポリシ取得応答８３を通信部２０４を介してＡｕＳ４００へ送信する（Ｓ８０３）。
【０２１２】
ＡｕＳ４００の認可判定部４０１は、通信部４０２を介してＰＭＳ２００から受信したポリシ取得応答８３の内容を解析して、ポリシ取得応答８３に示されているユーザのパラメータおよびＳＥＳ７００から受信した認可判定要求６０に含まれているユーザＩＤを含む属性取得要求８０を作成し、作成した属性取得要求８０を通信部４０２を介してＡＳ８００へ送信する（Ｓ８０５）。
【０２１３】
ＡＳ８００の属性情報管理部８０２は、通信部８０３を介してＡｕＳ４００から受信した属性取得要求８０に格納されているユーザＩＤに対応するユーザ属性情報をユーザ属性情報格納部８０１から取得する。そして、属性情報管理部８０２は、取得したユーザ属性情報を含む属性取得応答８１を作成し、作成した属性取得応答８１を通信部８０３を介してＡｕＳ４００へ送信する（Ｓ８０７）。
【０２１４】
ＡｕＳ４００の認可判定部４０１は、認可判定要求６０で指定されたシナリオＩＤに対応するサービスシナリオおよびサービスＩＤに対応するＷｅｂサービスのそれぞれについて、ＡＳ８００から受信した属性取得応答８１に含まれているユーザの属性が、ポリシ取得応答８３に含まれているサービスポリシを満たしているか否かを判定する認可判定を実行する（Ｓ８０８）。
【０２１５】
以上、本発明の第３実施例について説明した。本実施例のビジネスプロセス実行システム４０によれば、ＳＰ６００で提供されているＷｅｂサービスの認可判定は、ＳＥＳ７００がＵＳ５００からサービス要求を受信してから、ＳＥＳ７００がＳＰ６００を呼び出すまでの間に行われる。また、ＡｕＳ４００は、認可判定を行った後にその結果をＳＰ６００へ送信し、ＳＰ６００がその結果を保存する。これにより、ＳＰ６００が呼び出された後に認可判定処理を行う必要がなく、ユーザの待ち時間を少なくすることができる。
【０２１６】
また、本実施例のビジネスプロセス実行システム４０では、ＳＥＳ７００がＵＳ５００から要求されたサービスシナリオに含まれるＷｅｂサービスを列挙して、認可判定をＡｕＳ４００に要求する。また、ＡｕＳ４００は認可判定結果をＳＰ６００へ送信し、ＳＰ６００が認可判定結果を保存する。すなわち、ＳＰ６００が保存している認可判定結果は、ＳＥＳ７００が実行しようとしているサービスシナリオに関係したものであるため、比較的短時間でＳＰ６００にＷｅｂサービスの呼び出しが行われる可能性が高く、認可判定結果を無駄に保存することを少なくすることができる。
【０２１７】
なお、上記した実施例におけるＡＣＳ１００、ＰＭＳ２００、ＣＭＳ３００、ＡｕＳ４００、ＵＳ５００、ＳＰ６００、ＳＥＳ７００、またはＡＳ８００は、例えば図３２に示すような構成のコンピュータ２０によって実現される。
【０２１８】
コンピュータ２０は、ＣＰＵ２１と、メモリ２２と、インターネットやＬＡＮ等のネットワーク１１を介して他のコンピュータ２０と通信を行うための通信装置２４と、キーボードやマウス等の入力装置を接続する入力インターフェイス２５と、モニタやプリンタ等の出力装置を接続する出力インターフェイス２６と、読取装置２７と、ハードディスク等の外部記憶装置２３とを備え、これらの各構成要素はバス２８を介して互いに接続されている。また、読取装置２７にはＩＣカードやＵＳＢメモリのような、可搬性を有する記憶媒体２９を接続することができる。
【０２１９】
コンピュータ２０は、ＡＣＳ１００、ＰＭＳ２００、ＣＭＳ３００、ＡｕＳ４００、ＵＳ５００、およびＳＰ６００の中のいずれか１つの装置として機能する。コンピュータ２０は、当該いずれか１つの装置の機能を実現するプログラムをメモリ２２にロードし、当該プログラムをＣＰＵ２１により実行することで、対応する装置の機能を実現する。これらのプログラムは、予め外部記憶装置２３に格納されていてもよく、必要なときに、読取装置２７または通信装置２４により当該コンピュータ２０が利用可能な媒体を介して、他の装置から取得されて外部記憶装置２３に格納されてもよい。
【０２２０】
媒体とは、例えば、読取装置２７に着脱可能な記憶媒体２９、または、通信装置２４に接続されているネットワーク１１またはネットワーク１１を伝搬する搬送波やディジタル信号を指す。そして、これらのプログラムは、一旦外部記憶装置２３に格納された後、そこからメモリ２２上にロードされてＣＰＵ２１に実行されてもよく、あるいは外部記憶装置２３に格納されることなく、直接メモリ２２上にロードされて、ＣＰＵ２１により実行されてもよい。
【０２２１】
また、上記した第１または第２実施例において、次サービスＩＤ特定部１０２は、現在提供されているサービスの１つ次に提供されるべきサービスのサービスＩＤを特定したが、他の例として、次サービスＩＤ特定部１０２は、現在提供されているサービスを含むワークフローにおいて、当該サービスの後に実行されるべき全てのサービスのサービスＩＤを全て特定して認可判定要求部１０４に提供するようにしてもよい。
【０２２２】
また、上記した第２実施例において、次サービスＩＤ特定部１０２は、現在提供されているサービスの次に提供されたサービスの回数を用いて次に提供されるべきサービスを推定したが、これ以外にも、ユーザの過去のサービス利用履歴や属性情報等を基にしてよく知られたデータマイニング手法により、次に要求される可能性の高いサービスを推定するようにしてもよい。
【０２２３】
また、上記した第３実施例では、ＳＥＳ７００によって提供されるサービスシナリオ、および、ＳＰ６００によって提供されるＷｅｂサービスの認可判定をＡｕＳ４００が一元的に判定しているが、本発明はそのような構成に限定されない。例えば、それぞれのＳＰ６００が、当該ＳＰ６００で提供されているＷｅｂサービスについての認可判定を実行するようにしてもよい。すなわち、ＳＰ６００内に、ＡｕＳ４００の機能が組み込まれていてもよい。また、ＰＭＳ２００またはＡＳ８００の機能もそれぞれのＳＰ６００内に組み込まれていてもよい。
【０２２４】
ＳＰ６００が当該ＳＰ６００で提供されているＷｅｂサービスについての認可判定を実行するようにすれば、認可判定のために交換されるメッセージを少なくすることができ、ネットワークを効果的に利用することができる。このような構成においても、ＳＥＳ７００からＳＰ６００にＷｅｂサービスの呼び出しが行われる前に認可判定処理を行い、各ＳＰ６００が認可判定結果を保存しているため、実際にＷｅｂサービスの呼び出しが行われても認可判定処理を行う必要がなく、Ｗｅｂサービスの提供を迅速に開始することができる。
【０２２５】
ＳＰ６００内にＡｕＳ４００の機能を組み込んだ場合のビジネスプロセス実行システム４０の動作は例えば図３３のようになる。なお、以下に説明する点を除き、図３３において、図３０と同じ符号を付した処理は、図３０における処理と同様であるため説明を省略する。
【０２２６】
ＳＥＳ７００のシナリオ実行部７０３は、シナリオ格納部７０１から取得したサービスシナリオからサービスＩＤを抽出して、例えば図２５（ａ）に示した認可判定要求６０を生成する。そして、シナリオ実行部７０３は、生成した認可判定要求６０を、抽出したサービスＩＤに対応するＷｅｂサービスを提供するそれぞれのＳＰ６００へ送信する（Ｓ７２０）。なお、シナリオ実行部７０３は、シナリオＩＤを含む認可判定要求６０を、いずれかのＳＰ６００へ送信することにより、ユーザから指定されたサービスシナリオの認可判定をいずれかのＳＰ６００に実行させる。
【０２２７】
それぞれのＳＰ６００は、図３１で説明した認可判定処理（Ｓ８００）を実行した後に、図２５（ｂ）で説明した認可判定結果７０を作成し、作成した認可判定結果７０をＳＥＳ７００へ送信する（Ｓ７２１）。そして、それぞれのＳＰ６００は、認可判定の結果が「許可」である場合に、当該認可判定の結果を、対象となるユーザのユーザＩＤと共に、認可判定結果格納部６０７に格納する（Ｓ７２２）。
【０２２８】
また、上記した第３実施例において、シナリオ実行部７０３は、ＵＳ５００からサービス要求を受信した場合に、当該サービス要求に含まれているシナリオＩＤに対応するサービスシナリオに実行順番が規定されているＷｅｂサービスの認可判定を一括して実行するが、本発明はこれに限定されない。例えば、シナリオ実行部７０３は、ユーザから指定されたサービスシナリオおよび当該サービスシナリオに規定されている最初のＷｅｂサービスについてＡｕＳ４００に認可判定を実行させ、当該サービスシナリオおよび当該最初のＷｅｂサービスのいずれも許可されている場合に、当該最初のＷｅｂサービスの提供を開始する。
【０２２９】
そして、当該最初のＷｅｂサービスが提供されている間に、シナリオ実行部７０３は、ユーザから指定されたサービスシナリオを参照して、当該サービスシナリオに規定されているそれぞれのＷｅｂサービスの認可判定をＡｕＳ４００に実行させてもよい。これにより、最初のＷｅｂサービスの提供が開始されるまでのユーザの待ち時間を低減することができる。なお、ＳＰ６００が最初のＷｅｂサービスの提供を開始した後に、シナリオ実行部７０３が図２６および図２７に示した禁止サービスの登録処理を実行して、最初のＷｅｂサービスが禁止サービスとしてプロセス情報格納部７０２に登録された場合、シナリオ実行部７０３は、即座に、ユーザのＵＳ５００に、それ以降のＷｅｂサービスの提供が受けられない旨のエラー通知を送信することが好ましい。あるいは、サービスシナリオの中に含まれるＷｅｂサービスの提供を開始した後に、当該Ｗｅｂサービスが禁止サービスとして登録された場合も、即座に、ＵＳ５００に、それ以降のＷｅｂサービスの提供が受けられない旨のエラー通知を送信することが好ましい。
【０２３０】
上記において、本発明を実施の形態を用いて説明したが、本発明の技術的範囲は上記実施の形態に記載の範囲には限定されない。上記実施の形態に、多様な変更または改良を加えることが可能であることが当業者に明らかである。その様な変更または改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。
【図面の簡単な説明】
【０２３１】
【図１】第１実施例におけるアクセス認可システム１０の構成を例示するシステム構成図。
【図２】通信管理テーブル格納部５０４に格納されるデータの構造を例示する図。
【図３】通信管理テーブル格納部６０４に格納されるデータの構造を例示する図。
【図４】通信開始要求、通信開始応答、認可情報取得要求、認可情報取得応答、登録情報取得要求、および登録情報取得応答のデータ構造を例示する図。
【図５】ユーザ属性情報、サービスポリシ情報、認可判定要求、認可判定応答、および認可情報のデータ構造を例示する図。
【図６】登録情報更新要求、登録情報更新応答、認可情報削除要求、および認可情報削除応答のデータ構造を例示する図。
【図７】アクセス履歴格納部３０３に格納されるデータの構造を例示する図。
【図８】第１実施例において認可情報格納部１０３に格納されるデータの構造を例示する図。
【図９】次サービスＩＤ格納部１０１に格納されるデータの構造を例示する図。
【図１０】サービスポリシ情報格納部２０１に格納されるデータの構造を例示する図。
【図１１】ユーザ属性情報格納部２０２に格納されるデータの構造を例示する図。
【図１２】第１実施例におけるアクセス認可システム１０のサービス提供開始処理を例示するシーケンス図。
【図１３】第１実施例において、サービス提供開始前、サービス提供開始後、および認可判定を予め行った後の認可情報格納部１０３の内容を例示する図。
【図１４】第１実施例におけるアクセス認可システム１０の登録情報更新処理を例示するシーケンス図。
【図１５】第２実施例におけるアクセス認可システム１０の構成を例示するシステム構成図。
【図１６】認可情報送信通知および認可情報送信完了通知のデータ構造を例示する図。
【図１７】第２実施例において認可情報格納部１０３に格納されるデータの構造を例示する図。
【図１８】サービス履歴格納部１０６に格納されるデータの構造を例示する図。
【図１９】第２実施例におけるアクセス認可システム１０のサービス提供開始処理を例示するシーケンス図。
【図２０】第２実施例におけるアクセス認可システム１０の登録情報更新処理を例示するシーケンス図。
【図２１】第３実施例におけるビジネスプロセス実行システム４０の構成を例示するシステム構成図。
【図２２】シナリオ格納部７０１に格納されるデータの構造を例示する図。
【図２３】サービスシナリオ５０のデータ構造を例示する図。
【図２４】プロセス情報格納部７０２に格納されるデータの構造を例示する図。
【図２５】認可判定要求６０および認可判定結果７０のデータ構造を例示する図。
【図２６】シナリオ実行部７０３によって実行される、禁止サービス登録処理を例示するフローチャート。
【図２７】禁止判定処理（Ｓ６００）を例示するフローチャート。
【図２８】属性取得要求８０、属性取得応答８１、ポリシ取得要求８２、およびポリシ取得応答８３のデータ構造を例示する図。
【図２９】シナリオポリシ情報格納部２０５に格納されるデータの構造を例示する図。
【図３０】第３実施例におけるビジネスプロセス実行システム４０の動作を例示するシーケンス図。
【図３１】第３実施例における認可判定処理（Ｓ８００）を例示するシーケンス図。
【図３２】ＡＣＳ１００、ＰＭＳ２００、ＣＭＳ３００、ＡｕＳ４００、ＵＳ５００、ＳＰ６００、ＳＥＳ７００、またはＡＳ８００の機能を実現するコンピュータ２０の構成を例示するハードウェア構成図。
【図３３】第３実施例におけるビジネスプロセス実行システム４０の動作の他の例を示すシーケンス図。
【符号の説明】
【０２３２】
１０・・・アクセス認可システム、１１・・・ネットワーク、２０・・・コンピュータ、２１・・・ＣＰＵ、２２・・・メモリ、２３・・・外部記憶装置、２４・・・通信装置、２５・・・入力インターフェイス、２６・・・出力インターフェイス、２７・・・読取装置、２８・・・バス、２９・・・記憶媒体、３０・・・ＢＯＤＹ部、３１・・・ＢＯＤＹ部、４０・・・ビジネスプロセス実行システム、１００・・・ＡＣＳ、１０１・・・次サービスＩＤ格納部、１０２・・・次サービスＩＤ特定部、１０３・・・認可情報格納部、１０４・・・認可判定要求部、１０５・・・通信部、１０６・・・サービス履歴格納部、２００・・・ＰＭＳ、２０１・・・サービスポリシ情報格納部、２０２・・・ユーザ属性情報格納部、２０３・・・情報管理部、２０４・・・通信部、２０５・・・シナリオポリシ情報格納部、２０６・・・ポリシ情報管理部、３００・・・ＣＭＳ、３０１・・・位置情報格納部、３０２・・・ログイン処理部、３０３・・・アクセス履歴格納部、３０４・・・ＳＩＰメッセージ制御部、３０５・・・通信部、４００・・・ＡｕＳ、４０１・・・認可判定部、４０２・・・通信部、５００・・・ＵＳ、５０１・・・通信部、５０２・・・通信アプリケーション、５０３・・・ＳＩＰクライアント、５０４・・・通信管理テーブル格納部、５０５・・・通信制御エンジン、６００・・・ＳＰ、６０１・・・通信部、６０２・・・サービスアプリケーション、６０３・・・ＳＩＰクライアント、６０４・・・通信管理テーブル格納部、６０５・・・通信制御エンジン、６０６・・・認可判定取得部、６０７・・・認可判定結果格納部、７００・・・ＳＥＳ、７０１・・・シナリオ格納部、７０２・・・プロセス情報格納部、７０３・・・シナリオ実行部、７０４・・・通信部、８００・・・ＡＳ、８０１・・・ユーザ属性情報格納部、８０２・・・属性情報管理部、８０３・・・通信部
【特許請求の範囲】
【請求項１】
クライアント側の通信装置からのサービスの要求に基づいて、当該通信装置を使用しているユーザに対して当該サービスの提供が許可されるか否かを判定する認可判定を行うアクセス認可システムであって、
ポリシ管理サーバと、
認可サーバと、
アクセス制御サーバと
を備え、
前記ポリシ管理サーバは、
クライアント側の通信装置のユーザを識別するユーザＩＤ毎に、当該ユーザのユーザ属性情報を格納するユーザ属性情報格納手段と、
サービスを識別するサービスＩＤ毎に、当該サービスの提供が許可されるユーザの条件を示すサービスポリシ情報を格納するサービスポリシ情報格納手段と、
前記アクセス制御サーバからユーザＩＤおよびサービスＩＤを含む登録情報取得要求を受信した場合に、当該ユーザＩＤに対応するユーザ属性情報を前記ユーザ属性情報格納手段から抽出すると共に、当該サービスＩＤに対応するサービスポリシ情報を前記サービスポリシ情報格納手段から抽出し、抽出したユーザ属性情報およびサービスポリシ情報を含む登録情報取得応答を前記アクセス制御サーバへ送信する情報管理手段と
を有し、
前記認可サーバは、
前記アクセス制御サーバからユーザ属性情報およびサービスポリシ情報を含む認可判定要求を受信した場合に、当該ユーザ属性情報が、当該サービスポリシ情報を満たすか否かを判定し、認可判定結果、当該認可判定結果の対象となるユーザのユーザＩＤ、および当該認可判定結果の対象となるサービスのサービスＩＤを含む認可判定応答を、前記アクセス制御サーバへ送信する認可判定手段を有し、
前記アクセス制御サーバは、
サービスＩＤ毎に、当該サービスＩＤに対応するサービスの次に提供されるべきサービスのサービスＩＤを格納する次サービスＩＤ格納手段と、
クライアント側の通信装置のユーザがサービスを利用可能か否かを示す認可情報の取得要求であって、当該ユーザのユーザＩＤおよび当該サービスのサービスＩＤを含む認可情報取得要求を受信した場合に、当該ユーザＩＤおよび当該サービスＩＤを含む登録情報取得要求を前記ポリシ管理サーバへ送信し、当該ユーザＩＤに対応するユーザ属性情報および当該サービスＩＤに対応するサービスポリシ情報を含む登録情報取得応答を前記ポリシ管理サーバから受信した場合に、当該ユーザ属性情報およびサービスポリシ情報を含む認可判定要求を前記認可サーバへ送信し、当該認可サーバから認可判定応答を受信した場合に、当該認可判定応答に含まれる認可判定結果、ユーザＩＤ、およびサービスＩＤを含む認可情報取得応答を出力する認可判定要求手段と、
前記認可判定要求手段が前記認可情報取得応答を出力した後に、当該認可情報取得応答に含まれる認可判定結果の対象であるサービスのサービスＩＤに基づいて前記次サービスＩＤ格納手段を参照して、当該サービスＩＤに対応するサービスの次に提供されるべきサービスのサービスＩＤを抽出し、抽出したサービスＩＤを、当該認可判定結果の対象であるユーザのユーザＩＤと共に前記認可判定要求手段へ送る次サービス特定手段と
を有し、
前記認可判定要求手段は、
前記認可情報取得応答を出力してから、当該認可情報取得応答に含まれるユーザＩＤと同一のユーザＩＤを含む認可情報取得要求を受信するまでの間に、前記次サービス特定手段から受け取ったユーザＩＤおよびサービスＩＤに対応するユーザ属性情報およびサービスポリシ情報を前記ポリシ管理サーバから取得し、当該ユーザ属性情報およびサービスポリシ情報を含む認可判定要求を前記認可サーバへ送信することにより、前記認可サーバに、当該ユーザＩＤに対応するユーザおよび当該サービスＩＤに対応するサービスの組み合わせについて認可判定を予め実行させることを特徴とするアクセス認可システム。
【請求項２】
請求項１に記載のアクセス認可システムであって、
前記アクセス制御サーバは、
ユーザＩＤおよびサービスＩＤの組み合わせ毎に、当該ユーザＩＤに対応するユーザが、当該サービスＩＤに対応するサービスの次に要求したサービスのサービスＩＤを格納するサービス履歴格納手段をさらに有し、
前記次サービス特定手段は、
当該認可情報取得応答に含まれる認可判定結果の対象であるサービスの次に提供されるべきサービスのサービスＩＤが、前記次サービスＩＤ格納手段に格納されていない場合には、前記サービス履歴格納手段を参照して、当該認可判定結果の対象であるサービスの次に提供されるべきサービスのサービスＩＤを推定し、推定したサービスＩＤ、および、当該認可判定結果の対象であるユーザのユーザＩＤを前記認可判定要求手段へ送ることを特徴とするアクセス認可システム。
【請求項３】
請求項２に記載のアクセス認可システムであって、
前記サービス履歴格納手段は、
ユーザＩＤおよびサービスＩＤの組み合わせ毎に、当該ユーザＩＤに対応するユーザが、当該サービスＩＤに対応するサービスの次に要求したサービスの要求回数の累積値をさらに格納し、
前記次サービス特定手段は、
当該認可情報取得応答に含まれる認可判定結果の対象であるサービスの次に提供されるべきサービスのサービスＩＤが、前記次サービスＩＤ格納手段に格納されていない場合には、前記サービス履歴格納手段を参照して、当該認可情報取得応答に含まれる認可判定結果の対象であるユーザのユーザＩＤおよびサービスのサービスＩＤの組み合わせに対応付けられているサービスＩＤの中で、予め定められた値以上の要求回数が対応付けられているサービスＩＤを、当該認可判定結果の対象であるサービスの次に提供されるべきサービスのサービスＩＤとして推定することを特徴とするアクセス認可システム。
【請求項４】
請求項１に記載のアクセス認可システムであって、
前記認可判定要求手段は、
前記認可情報取得応答を出力してから、当該認可情報取得応答に含まれるユーザＩＤと同一のユーザＩＤを含む認可情報取得要求を受信するまでの間に、前記次サービス特定手段から受け取ったユーザＩＤおよびサービスＩＤに対応するユーザ属性情報およびサービスポリシ情報を前記ポリシ管理サーバから取得し、当該ユーザ属性情報およびサービスポリシ情報を含む認可判定要求を前記認可サーバへ送信することにより、前記認可サーバから認可判定応答を受信し、受信した認可判定応答に含まれる認可判定結果を保持し、その後、保持している認可判定結果の対象であるユーザＩＤおよびサービスＩＤを含む認可情報取得要求を受信した場合に、当該認可判定結果、当該認可判定結果の対象であるユーザのユーザＩＤ、および当該判定結果の対象であるサービスのサービスＩＤを含む認可情報取得応答を出力することを特徴とするアクセス認可システム。
【請求項５】
請求項１に記載のアクセス認可システムであって、
前記認可判定要求手段は、
前記認可情報取得応答を出力してから、当該認可情報取得応答に含まれるユーザＩＤと同一のユーザＩＤを含む認可情報取得要求を受信するまでの間に、前記次サービス特定手段から受け取ったユーザＩＤおよびサービスＩＤに対応するユーザ属性情報およびサービスポリシ情報を前記ポリシ管理サーバから取得し、当該ユーザ属性情報およびサービスポリシ情報を含む認可判定要求を前記認可サーバへ送信することにより、前記認可サーバから認可判定応答を受信し、受信した認可判定応答に含まれる認可判定結果、当該判定結果の対象であるユーザのユーザＩＤ、当該判定結果の対象であるサービスのサービスＩＤを含む認可情報送信通知を、当該サービスを提供するサービス提供サーバへ予め送信することを特徴とするアクセス認可システム。
【請求項６】
請求項１に記載のアクセス認可システムであって、
前記認可判定要求手段は、
前記認可情報取得応答を出力してから、当該認可情報取得応答に含まれるユーザＩＤと同一のユーザＩＤを含む認可情報取得要求を受信するまでの間であって、前記アクセス制御サーバの処理負荷が予め定められた閾値未満の場合に、前記次サービス特定手段から受け取ったユーザＩＤおよびサービスＩＤに対応するユーザ属性情報およびサービスポリシ情報を前記ポリシ管理サーバから取得し、当該ユーザ属性情報およびサービスポリシ情報を含む認可判定要求を前記認可サーバへ送信することを特徴とするアクセス認可システム。
【請求項７】
クライアント側の通信装置のユーザを識別するユーザＩＤ毎に、当該ユーザのユーザ属性情報を格納するユーザ属性情報格納手段と、
サービスを識別するサービスＩＤ毎に、当該サービスの提供が許可されるユーザの条件を示すサービスポリシ情報を格納するサービスポリシ情報格納手段と、
ユーザＩＤおよびサービスＩＤを含む登録情報取得要求を受信した場合に、当該ユーザＩＤに対応するユーザ属性情報を前記ユーザ属性情報格納手段から抽出すると共に、当該サービスＩＤに対応するサービスポリシ情報を前記サービスポリシ情報格納手段から抽出し、抽出したユーザ属性情報およびサービスポリシ情報を含む登録情報取得応答を返す情報管理手段と
を有するポリシ管理サーバと、
ユーザ属性情報およびサービスポリシ情報を含む認可判定要求を受信した場合に、当該ユーザ属性情報が、当該サービスポリシ情報を満たすか否かを判定する認可判定を行い、認可判定結果、当該認可判定結果の対象となるユーザのユーザＩＤ、および当該認可判定結果の対象となるサービスのサービスＩＤを含む認可判定応答を返す認可判定手段
を有する認可サーバと
を備え、
クライアント側の通信装置からのサービスの要求に基づいて、当該通信装置を使用しているユーザに対する当該サービスの認可判定を行うアクセス認可システムに用いられるアクセス制御サーバであって、
サービスＩＤ毎に、当該サービスＩＤに対応するサービスの次に提供されるべきサービスのサービスＩＤを格納する次サービスＩＤ格納手段と、
クライアント側の通信装置のユーザがサービスを利用可能か否かを示す認可情報の取得要求であって、当該ユーザのユーザＩＤおよび当該サービスのサービスＩＤを含む認可情報取得要求を受信した場合に、当該ユーザＩＤおよび当該サービスＩＤを含む登録情報取得要求を前記ポリシ管理サーバへ送信し、当該ユーザＩＤに対応するユーザ属性情報および当該サービスＩＤに対応するサービスポリシ情報を含む登録情報取得応答を前記ポリシ管理サーバから受信した場合に、当該ユーザ属性情報およびサービスポリシ情報を含む認可判定要求を前記認可サーバへ送信し、当該認可サーバから認可判定応答を受信した場合に、当該認可判定応答に含まれる認可判定結果、ユーザＩＤ、およびサービスＩＤを含む認可情報取得応答を出力する認可判定要求手段と、
前記認可判定要求手段が前記認可情報取得応答を出力した後に、当該認可情報取得応答に含まれる認可判定結果の対象であるサービスのサービスＩＤに基づいて前記次サービスＩＤ格納手段を参照して、当該サービスＩＤに対応するサービスの次に提供されるべきサービスのサービスＩＤを抽出し、抽出したサービスＩＤを、当該認可判定結果の対象であるユーザのユーザＩＤと共に前記認可判定要求手段へ送る次サービス特定手段と
を有し、
前記認可判定要求手段は、
前記認可情報取得応答を出力してから、当該認可情報取得応答に含まれるユーザＩＤと同一のユーザＩＤを含む認可情報取得要求を受信するまでの間に、前記次サービス特定手段から受け取ったユーザＩＤおよびサービスＩＤに対応するユーザ属性情報およびサービスポリシ情報を前記ポリシ管理サーバから取得し、当該ユーザ属性情報およびサービスポリシ情報を含む認可判定要求を前記認可サーバへ送信することにより、前記認可サーバに、当該ユーザＩＤに対応するユーザおよび当該サービスＩＤに対応するサービスの組み合わせについて認可判定を予め実行させることを特徴とするアクセス制御サーバ。
【請求項８】
クライアント側の通信装置から要求された、複数のサービスから構成されるビジネスプロセスについて、当該通信装置のユーザに対して当該ビジネスプロセスに含まれる個々のサービスの提供が許可されるか否かを判定する認可判定を行うビジネスプロセス実行システムであって、
属性管理サーバと、
ポリシ管理サーバと、
認可サーバと、
サービス実行サーバと
を備え、
前記属性管理サーバは、
クライアント側の通信装置のユーザを識別するユーザＩＤ毎に、当該ユーザのユーザ属性情報を格納するユーザ属性情報格納手段と、
前記認可サーバからユーザＩＤを含む属性取得要求を受信した場合に、当該ユーザＩＤに対応するユーザ属性情報を前記ユーザ属性情報格納手段から抽出し、抽出したユーザ属性情報を含む属性取得応答を前記認可サーバへ送信する属性情報管理手段と
を有し、
前記ポリシ管理サーバは、
サービスを識別するサービスＩＤ毎に、当該サービスの提供が許可されるユーザの条件を示すサービスポリシ情報を格納するサービスポリシ情報格納手段と、
前記認可サーバからサービスＩＤを含むポリシ取得要求を受信した場合に、当該サービスＩＤに対応するサービスポリシ情報を前記サービスポリシ情報格納手段から抽出し、抽出したサービスポリシ情報を含むポリシ取得応答を前記認可サーバへ送信するポリシ情報管理手段と
を有し、
前記認可サーバは、
前記サービス実行サーバからユーザＩＤおよび１つ以上のサービスＩＤを含む認可判定要求を受信した場合に、当該ユーザＩＤを含む属性取得要求を前記属性管理サーバへ送信して、当該ユーザＩＤに対応するユーザ属性情報を取得すると共に、当該サービスＩＤを含むポリシ取得要求を前記ポリシ管理サーバへ送信して、当該サービスＩＤに対応するサービスポリシ情報を取得し、取得したユーザ属性情報が、取得したサービスポリシ情報を満たすか否かを判定し、サービスＩＤ毎の認可判定結果を含む認可判定応答を、前記サービス実行サーバへ送信する認可判定手段を有し、
前記サービス実行サーバは、
ビジネスプロセスに含まれる複数のサービスの提供順番を規定するサービスシナリオを、それぞれのサービスシナリオを識別するシナリオＩＤに対応付けて格納するシナリオ格納手段と、
クライアント側の通信装置からユーザＩＤおよびシナリオＩＤを含むサービス要求を受信した場合に、当該シナリオＩＤに対応するサービスシナリオを前記シナリオ格納手段から取得し、当該ユーザＩＤおよび取得したサービスシナリオに含まれているそれぞれのサービスのサービスＩＤを含む認可判定要求を前記認可サーバへ送信することにより、当該サービスシナリオに含まれているそれぞれのサービスの認可判定結果を取得し、当該サービスシナリオに含まれている一連のサービスの全てが許可されている場合に、当該サービスシナリオにおいて最初に提供されるべきサービスを実行するサービス提供サーバに、当該ユーザＩＤのユーザに対して当該サービスの提供を要求するシナリオ実行手段と
を有することを特徴とするビジネスプロセス実行システム。
【請求項９】
請求項８に記載のビジネスプロセス実行システムであって、
前記サービスシナリオには、あるサービスの次に提供されるべきサービスが条件に応じて異なる分岐が存在し、
前記サービス実行サーバは、
それぞれのプロセスを識別するプロセスＩＤ毎に、実行中のサービスシナリオのシナリオＩＤ、実行中のサービスのサービスＩＤ、および、提供が禁止されたサービスのサービスＩＤを格納するプロセス情報格納手段をさらに有し、
前記シナリオ実行手段は、
ユーザから指定されたサービスシナリオ内のそれぞれのサービスの認可判定結果を前記認可サーバから取得した場合に、プロセスＩＤを生成し、生成したプロセスＩＤに対応付けて、当該サービスシナリオのシナリオＩＤを実行中のサービスシナリオのシナリオＩＤとして前記プロセス情報格納手段に登録し、
当該サービスシナリオ内のそれぞれのサービスを対象として、当該対象となるサービスの次に提供されるべきサービスが存在する場合に、対象となるサービスが許可されていないか、または、次に提供されるサービスの全てが禁止されているならば、当該対象となるサービスのサービスＩＤを、提供が禁止されたサービスのサービスＩＤとして、生成したプロセスＩＤに対応付けて前記プロセス情報格納手段に登録し、当該対象となるサービスの次に提供されるべきサービスが存在しない場合に、対象となるサービスが許可されていないならば、当該対象となるサービスのサービスＩＤを、提供が禁止されたサービスのサービスＩＤとして、生成したプロセスＩＤに対応付けて前記プロセス情報格納手段に登録する禁止サービス登録処理を実行し、
それぞれのサービスを対象として実行した禁止サービス登録処理の結果、前記プロセス情報格納手段を参照して、最初に提供されるべきサービスが禁止されていない場合に、ユーザから指定されたサービスシナリオに含まれている一連のサービスの全てが許可されていると判定し、当該最初に提供されるべきサービスの実行を、当該サービスを提供するサービス提供サーバに要求すると共に、当該サービスのサービスＩＤを実行中のサービスシナリオのシナリオＩＤとして、生成したプロセスＩＤに対応付けて前記プロセス情報格納手段に登録することを特徴とするビジネスプロセス実行システム。
【請求項１０】
請求項８または９に記載のビジネスプロセス実行システムであって、
前記ポリシ管理サーバは、
シナリオＩＤ毎に、当該シナリオＩＤに対応するサービスシナリオの提供が許可されるユーザの条件を示すシナリオポリシ情報を格納するシナリオポリシ情報格納手段をさらに有し、
前記ポリシ情報管理手段は、
前記認可サーバからシナリオＩＤを含むポリシ取得要求を受信した場合に、当該シナリオＩＤに対応するシナリオポリシ情報を前記シナリオポリシ情報格納手段から抽出し、抽出したシナリオポリシ情報を含むポリシ取得応答を前記認可サーバへ送信し、
前記認可サーバは、
前記サービス実行サーバからシナリオＩＤをさらに含む認可判定要求を受信した場合に、当該シナリオＩＤを含むポリシ取得要求を前記ポリシ管理サーバへ送信して、当該シナリオＩＤに対応するシナリオポリシ情報をさらに取得し、前記属性管理サーバから取得したユーザ属性情報が、当該シナリオポリシ情報を満たすか否かを判定し、シナリオＩＤに対応付けた認可判定結果をさらに含む認可判定応答を、前記サービス実行サーバへ送信し、
前記シナリオ実行手段は、
前記クライアント側の通信装置から前記サービス要求を受信した場合に、当該サービス要求に含まれているシナリオＩＤをさらに含む認可判定要求を前記認可サーバへ送信することにより、当該シナリオＩＤに対応するサービスシナリオの認可判定結果をさらに取得し、当該サービスシナリオの実行が許可されている場合に、当該サービスシナリオに含まれている一連のサービスの全てが許可されているか否かを判定することを特徴とするビジネスプロセス実行システム。
【請求項１１】
請求項８から１０のいずれか一項に記載のビジネスプロセス実行システムであって、
前記認可判定手段は、
前記サービス実行サーバから受信した認可判定要求に応じて行った認可判定の結果を、認可判定の対象となったそれぞれのサービスを提供しているサービス提供サーバから、認可判定の対象となったユーザについての認可判定を要求される前に、当該サービス提供サーバへ送信することを特徴とするビジネスプロセス実行システム。
【請求項１２】
請求項８から１０のいずれか一項に記載のビジネスプロセス実行システムであって、
それぞれのサービス提供サーバは、前記認可サーバの機能を有し、
前記シナリオ実行手段は、
クライアント側の通信装置からユーザＩＤおよびシナリオＩＤを含むサービス要求を受信した場合に、当該シナリオＩＤに対応するサービスシナリオを前記シナリオ格納手段から取得し、当該ユーザＩＤおよび取得したサービスシナリオに含まれているサービスのサービスＩＤを含む認可判定要求を、それぞれのサービスを実行するサービス提供サーバへ送信することにより、当該サービスシナリオに含まれているサービスの認可判定結果を取得し、
それぞれのサービス提供サーバは、
前記サービス実行サーバから受信した認可判定要求に基づいて、当該認可判定要求に含まれるユーザＩＤのユーザに対してサービスの提供が許可されるか否かを判定する認可判定を実行し、認可判定結果および当該認可判定結果の対象となるサービスのサービスＩＤを含む認可判定応答を前記サービス実行サーバへ送信すると共に、当該ユーザＩＤに対応付けて当該認可判定結果を保持することを特徴とするビジネスプロセス実行システム。
【請求項１】
クライアント側の通信装置からのサービスの要求に基づいて、当該通信装置を使用しているユーザに対して当該サービスの提供が許可されるか否かを判定する認可判定を行うアクセス認可システムであって、
ポリシ管理サーバと、
認可サーバと、
アクセス制御サーバと
を備え、
前記ポリシ管理サーバは、
クライアント側の通信装置のユーザを識別するユーザＩＤ毎に、当該ユーザのユーザ属性情報を格納するユーザ属性情報格納手段と、
サービスを識別するサービスＩＤ毎に、当該サービスの提供が許可されるユーザの条件を示すサービスポリシ情報を格納するサービスポリシ情報格納手段と、
前記アクセス制御サーバからユーザＩＤおよびサービスＩＤを含む登録情報取得要求を受信した場合に、当該ユーザＩＤに対応するユーザ属性情報を前記ユーザ属性情報格納手段から抽出すると共に、当該サービスＩＤに対応するサービスポリシ情報を前記サービスポリシ情報格納手段から抽出し、抽出したユーザ属性情報およびサービスポリシ情報を含む登録情報取得応答を前記アクセス制御サーバへ送信する情報管理手段と
を有し、
前記認可サーバは、
前記アクセス制御サーバからユーザ属性情報およびサービスポリシ情報を含む認可判定要求を受信した場合に、当該ユーザ属性情報が、当該サービスポリシ情報を満たすか否かを判定し、認可判定結果、当該認可判定結果の対象となるユーザのユーザＩＤ、および当該認可判定結果の対象となるサービスのサービスＩＤを含む認可判定応答を、前記アクセス制御サーバへ送信する認可判定手段を有し、
前記アクセス制御サーバは、
サービスＩＤ毎に、当該サービスＩＤに対応するサービスの次に提供されるべきサービスのサービスＩＤを格納する次サービスＩＤ格納手段と、
クライアント側の通信装置のユーザがサービスを利用可能か否かを示す認可情報の取得要求であって、当該ユーザのユーザＩＤおよび当該サービスのサービスＩＤを含む認可情報取得要求を受信した場合に、当該ユーザＩＤおよび当該サービスＩＤを含む登録情報取得要求を前記ポリシ管理サーバへ送信し、当該ユーザＩＤに対応するユーザ属性情報および当該サービスＩＤに対応するサービスポリシ情報を含む登録情報取得応答を前記ポリシ管理サーバから受信した場合に、当該ユーザ属性情報およびサービスポリシ情報を含む認可判定要求を前記認可サーバへ送信し、当該認可サーバから認可判定応答を受信した場合に、当該認可判定応答に含まれる認可判定結果、ユーザＩＤ、およびサービスＩＤを含む認可情報取得応答を出力する認可判定要求手段と、
前記認可判定要求手段が前記認可情報取得応答を出力した後に、当該認可情報取得応答に含まれる認可判定結果の対象であるサービスのサービスＩＤに基づいて前記次サービスＩＤ格納手段を参照して、当該サービスＩＤに対応するサービスの次に提供されるべきサービスのサービスＩＤを抽出し、抽出したサービスＩＤを、当該認可判定結果の対象であるユーザのユーザＩＤと共に前記認可判定要求手段へ送る次サービス特定手段と
を有し、
前記認可判定要求手段は、
前記認可情報取得応答を出力してから、当該認可情報取得応答に含まれるユーザＩＤと同一のユーザＩＤを含む認可情報取得要求を受信するまでの間に、前記次サービス特定手段から受け取ったユーザＩＤおよびサービスＩＤに対応するユーザ属性情報およびサービスポリシ情報を前記ポリシ管理サーバから取得し、当該ユーザ属性情報およびサービスポリシ情報を含む認可判定要求を前記認可サーバへ送信することにより、前記認可サーバに、当該ユーザＩＤに対応するユーザおよび当該サービスＩＤに対応するサービスの組み合わせについて認可判定を予め実行させることを特徴とするアクセス認可システム。
【請求項２】
請求項１に記載のアクセス認可システムであって、
前記アクセス制御サーバは、
ユーザＩＤおよびサービスＩＤの組み合わせ毎に、当該ユーザＩＤに対応するユーザが、当該サービスＩＤに対応するサービスの次に要求したサービスのサービスＩＤを格納するサービス履歴格納手段をさらに有し、
前記次サービス特定手段は、
当該認可情報取得応答に含まれる認可判定結果の対象であるサービスの次に提供されるべきサービスのサービスＩＤが、前記次サービスＩＤ格納手段に格納されていない場合には、前記サービス履歴格納手段を参照して、当該認可判定結果の対象であるサービスの次に提供されるべきサービスのサービスＩＤを推定し、推定したサービスＩＤ、および、当該認可判定結果の対象であるユーザのユーザＩＤを前記認可判定要求手段へ送ることを特徴とするアクセス認可システム。
【請求項３】
請求項２に記載のアクセス認可システムであって、
前記サービス履歴格納手段は、
ユーザＩＤおよびサービスＩＤの組み合わせ毎に、当該ユーザＩＤに対応するユーザが、当該サービスＩＤに対応するサービスの次に要求したサービスの要求回数の累積値をさらに格納し、
前記次サービス特定手段は、
当該認可情報取得応答に含まれる認可判定結果の対象であるサービスの次に提供されるべきサービスのサービスＩＤが、前記次サービスＩＤ格納手段に格納されていない場合には、前記サービス履歴格納手段を参照して、当該認可情報取得応答に含まれる認可判定結果の対象であるユーザのユーザＩＤおよびサービスのサービスＩＤの組み合わせに対応付けられているサービスＩＤの中で、予め定められた値以上の要求回数が対応付けられているサービスＩＤを、当該認可判定結果の対象であるサービスの次に提供されるべきサービスのサービスＩＤとして推定することを特徴とするアクセス認可システム。
【請求項４】
請求項１に記載のアクセス認可システムであって、
前記認可判定要求手段は、
前記認可情報取得応答を出力してから、当該認可情報取得応答に含まれるユーザＩＤと同一のユーザＩＤを含む認可情報取得要求を受信するまでの間に、前記次サービス特定手段から受け取ったユーザＩＤおよびサービスＩＤに対応するユーザ属性情報およびサービスポリシ情報を前記ポリシ管理サーバから取得し、当該ユーザ属性情報およびサービスポリシ情報を含む認可判定要求を前記認可サーバへ送信することにより、前記認可サーバから認可判定応答を受信し、受信した認可判定応答に含まれる認可判定結果を保持し、その後、保持している認可判定結果の対象であるユーザＩＤおよびサービスＩＤを含む認可情報取得要求を受信した場合に、当該認可判定結果、当該認可判定結果の対象であるユーザのユーザＩＤ、および当該判定結果の対象であるサービスのサービスＩＤを含む認可情報取得応答を出力することを特徴とするアクセス認可システム。
【請求項５】
請求項１に記載のアクセス認可システムであって、
前記認可判定要求手段は、
前記認可情報取得応答を出力してから、当該認可情報取得応答に含まれるユーザＩＤと同一のユーザＩＤを含む認可情報取得要求を受信するまでの間に、前記次サービス特定手段から受け取ったユーザＩＤおよびサービスＩＤに対応するユーザ属性情報およびサービスポリシ情報を前記ポリシ管理サーバから取得し、当該ユーザ属性情報およびサービスポリシ情報を含む認可判定要求を前記認可サーバへ送信することにより、前記認可サーバから認可判定応答を受信し、受信した認可判定応答に含まれる認可判定結果、当該判定結果の対象であるユーザのユーザＩＤ、当該判定結果の対象であるサービスのサービスＩＤを含む認可情報送信通知を、当該サービスを提供するサービス提供サーバへ予め送信することを特徴とするアクセス認可システム。
【請求項６】
請求項１に記載のアクセス認可システムであって、
前記認可判定要求手段は、
前記認可情報取得応答を出力してから、当該認可情報取得応答に含まれるユーザＩＤと同一のユーザＩＤを含む認可情報取得要求を受信するまでの間であって、前記アクセス制御サーバの処理負荷が予め定められた閾値未満の場合に、前記次サービス特定手段から受け取ったユーザＩＤおよびサービスＩＤに対応するユーザ属性情報およびサービスポリシ情報を前記ポリシ管理サーバから取得し、当該ユーザ属性情報およびサービスポリシ情報を含む認可判定要求を前記認可サーバへ送信することを特徴とするアクセス認可システム。
【請求項７】
クライアント側の通信装置のユーザを識別するユーザＩＤ毎に、当該ユーザのユーザ属性情報を格納するユーザ属性情報格納手段と、
サービスを識別するサービスＩＤ毎に、当該サービスの提供が許可されるユーザの条件を示すサービスポリシ情報を格納するサービスポリシ情報格納手段と、
ユーザＩＤおよびサービスＩＤを含む登録情報取得要求を受信した場合に、当該ユーザＩＤに対応するユーザ属性情報を前記ユーザ属性情報格納手段から抽出すると共に、当該サービスＩＤに対応するサービスポリシ情報を前記サービスポリシ情報格納手段から抽出し、抽出したユーザ属性情報およびサービスポリシ情報を含む登録情報取得応答を返す情報管理手段と
を有するポリシ管理サーバと、
ユーザ属性情報およびサービスポリシ情報を含む認可判定要求を受信した場合に、当該ユーザ属性情報が、当該サービスポリシ情報を満たすか否かを判定する認可判定を行い、認可判定結果、当該認可判定結果の対象となるユーザのユーザＩＤ、および当該認可判定結果の対象となるサービスのサービスＩＤを含む認可判定応答を返す認可判定手段
を有する認可サーバと
を備え、
クライアント側の通信装置からのサービスの要求に基づいて、当該通信装置を使用しているユーザに対する当該サービスの認可判定を行うアクセス認可システムに用いられるアクセス制御サーバであって、
サービスＩＤ毎に、当該サービスＩＤに対応するサービスの次に提供されるべきサービスのサービスＩＤを格納する次サービスＩＤ格納手段と、
クライアント側の通信装置のユーザがサービスを利用可能か否かを示す認可情報の取得要求であって、当該ユーザのユーザＩＤおよび当該サービスのサービスＩＤを含む認可情報取得要求を受信した場合に、当該ユーザＩＤおよび当該サービスＩＤを含む登録情報取得要求を前記ポリシ管理サーバへ送信し、当該ユーザＩＤに対応するユーザ属性情報および当該サービスＩＤに対応するサービスポリシ情報を含む登録情報取得応答を前記ポリシ管理サーバから受信した場合に、当該ユーザ属性情報およびサービスポリシ情報を含む認可判定要求を前記認可サーバへ送信し、当該認可サーバから認可判定応答を受信した場合に、当該認可判定応答に含まれる認可判定結果、ユーザＩＤ、およびサービスＩＤを含む認可情報取得応答を出力する認可判定要求手段と、
前記認可判定要求手段が前記認可情報取得応答を出力した後に、当該認可情報取得応答に含まれる認可判定結果の対象であるサービスのサービスＩＤに基づいて前記次サービスＩＤ格納手段を参照して、当該サービスＩＤに対応するサービスの次に提供されるべきサービスのサービスＩＤを抽出し、抽出したサービスＩＤを、当該認可判定結果の対象であるユーザのユーザＩＤと共に前記認可判定要求手段へ送る次サービス特定手段と
を有し、
前記認可判定要求手段は、
前記認可情報取得応答を出力してから、当該認可情報取得応答に含まれるユーザＩＤと同一のユーザＩＤを含む認可情報取得要求を受信するまでの間に、前記次サービス特定手段から受け取ったユーザＩＤおよびサービスＩＤに対応するユーザ属性情報およびサービスポリシ情報を前記ポリシ管理サーバから取得し、当該ユーザ属性情報およびサービスポリシ情報を含む認可判定要求を前記認可サーバへ送信することにより、前記認可サーバに、当該ユーザＩＤに対応するユーザおよび当該サービスＩＤに対応するサービスの組み合わせについて認可判定を予め実行させることを特徴とするアクセス制御サーバ。
【請求項８】
クライアント側の通信装置から要求された、複数のサービスから構成されるビジネスプロセスについて、当該通信装置のユーザに対して当該ビジネスプロセスに含まれる個々のサービスの提供が許可されるか否かを判定する認可判定を行うビジネスプロセス実行システムであって、
属性管理サーバと、
ポリシ管理サーバと、
認可サーバと、
サービス実行サーバと
を備え、
前記属性管理サーバは、
クライアント側の通信装置のユーザを識別するユーザＩＤ毎に、当該ユーザのユーザ属性情報を格納するユーザ属性情報格納手段と、
前記認可サーバからユーザＩＤを含む属性取得要求を受信した場合に、当該ユーザＩＤに対応するユーザ属性情報を前記ユーザ属性情報格納手段から抽出し、抽出したユーザ属性情報を含む属性取得応答を前記認可サーバへ送信する属性情報管理手段と
を有し、
前記ポリシ管理サーバは、
サービスを識別するサービスＩＤ毎に、当該サービスの提供が許可されるユーザの条件を示すサービスポリシ情報を格納するサービスポリシ情報格納手段と、
前記認可サーバからサービスＩＤを含むポリシ取得要求を受信した場合に、当該サービスＩＤに対応するサービスポリシ情報を前記サービスポリシ情報格納手段から抽出し、抽出したサービスポリシ情報を含むポリシ取得応答を前記認可サーバへ送信するポリシ情報管理手段と
を有し、
前記認可サーバは、
前記サービス実行サーバからユーザＩＤおよび１つ以上のサービスＩＤを含む認可判定要求を受信した場合に、当該ユーザＩＤを含む属性取得要求を前記属性管理サーバへ送信して、当該ユーザＩＤに対応するユーザ属性情報を取得すると共に、当該サービスＩＤを含むポリシ取得要求を前記ポリシ管理サーバへ送信して、当該サービスＩＤに対応するサービスポリシ情報を取得し、取得したユーザ属性情報が、取得したサービスポリシ情報を満たすか否かを判定し、サービスＩＤ毎の認可判定結果を含む認可判定応答を、前記サービス実行サーバへ送信する認可判定手段を有し、
前記サービス実行サーバは、
ビジネスプロセスに含まれる複数のサービスの提供順番を規定するサービスシナリオを、それぞれのサービスシナリオを識別するシナリオＩＤに対応付けて格納するシナリオ格納手段と、
クライアント側の通信装置からユーザＩＤおよびシナリオＩＤを含むサービス要求を受信した場合に、当該シナリオＩＤに対応するサービスシナリオを前記シナリオ格納手段から取得し、当該ユーザＩＤおよび取得したサービスシナリオに含まれているそれぞれのサービスのサービスＩＤを含む認可判定要求を前記認可サーバへ送信することにより、当該サービスシナリオに含まれているそれぞれのサービスの認可判定結果を取得し、当該サービスシナリオに含まれている一連のサービスの全てが許可されている場合に、当該サービスシナリオにおいて最初に提供されるべきサービスを実行するサービス提供サーバに、当該ユーザＩＤのユーザに対して当該サービスの提供を要求するシナリオ実行手段と
を有することを特徴とするビジネスプロセス実行システム。
【請求項９】
請求項８に記載のビジネスプロセス実行システムであって、
前記サービスシナリオには、あるサービスの次に提供されるべきサービスが条件に応じて異なる分岐が存在し、
前記サービス実行サーバは、
それぞれのプロセスを識別するプロセスＩＤ毎に、実行中のサービスシナリオのシナリオＩＤ、実行中のサービスのサービスＩＤ、および、提供が禁止されたサービスのサービスＩＤを格納するプロセス情報格納手段をさらに有し、
前記シナリオ実行手段は、
ユーザから指定されたサービスシナリオ内のそれぞれのサービスの認可判定結果を前記認可サーバから取得した場合に、プロセスＩＤを生成し、生成したプロセスＩＤに対応付けて、当該サービスシナリオのシナリオＩＤを実行中のサービスシナリオのシナリオＩＤとして前記プロセス情報格納手段に登録し、
当該サービスシナリオ内のそれぞれのサービスを対象として、当該対象となるサービスの次に提供されるべきサービスが存在する場合に、対象となるサービスが許可されていないか、または、次に提供されるサービスの全てが禁止されているならば、当該対象となるサービスのサービスＩＤを、提供が禁止されたサービスのサービスＩＤとして、生成したプロセスＩＤに対応付けて前記プロセス情報格納手段に登録し、当該対象となるサービスの次に提供されるべきサービスが存在しない場合に、対象となるサービスが許可されていないならば、当該対象となるサービスのサービスＩＤを、提供が禁止されたサービスのサービスＩＤとして、生成したプロセスＩＤに対応付けて前記プロセス情報格納手段に登録する禁止サービス登録処理を実行し、
それぞれのサービスを対象として実行した禁止サービス登録処理の結果、前記プロセス情報格納手段を参照して、最初に提供されるべきサービスが禁止されていない場合に、ユーザから指定されたサービスシナリオに含まれている一連のサービスの全てが許可されていると判定し、当該最初に提供されるべきサービスの実行を、当該サービスを提供するサービス提供サーバに要求すると共に、当該サービスのサービスＩＤを実行中のサービスシナリオのシナリオＩＤとして、生成したプロセスＩＤに対応付けて前記プロセス情報格納手段に登録することを特徴とするビジネスプロセス実行システム。
【請求項１０】
請求項８または９に記載のビジネスプロセス実行システムであって、
前記ポリシ管理サーバは、
シナリオＩＤ毎に、当該シナリオＩＤに対応するサービスシナリオの提供が許可されるユーザの条件を示すシナリオポリシ情報を格納するシナリオポリシ情報格納手段をさらに有し、
前記ポリシ情報管理手段は、
前記認可サーバからシナリオＩＤを含むポリシ取得要求を受信した場合に、当該シナリオＩＤに対応するシナリオポリシ情報を前記シナリオポリシ情報格納手段から抽出し、抽出したシナリオポリシ情報を含むポリシ取得応答を前記認可サーバへ送信し、
前記認可サーバは、
前記サービス実行サーバからシナリオＩＤをさらに含む認可判定要求を受信した場合に、当該シナリオＩＤを含むポリシ取得要求を前記ポリシ管理サーバへ送信して、当該シナリオＩＤに対応するシナリオポリシ情報をさらに取得し、前記属性管理サーバから取得したユーザ属性情報が、当該シナリオポリシ情報を満たすか否かを判定し、シナリオＩＤに対応付けた認可判定結果をさらに含む認可判定応答を、前記サービス実行サーバへ送信し、
前記シナリオ実行手段は、
前記クライアント側の通信装置から前記サービス要求を受信した場合に、当該サービス要求に含まれているシナリオＩＤをさらに含む認可判定要求を前記認可サーバへ送信することにより、当該シナリオＩＤに対応するサービスシナリオの認可判定結果をさらに取得し、当該サービスシナリオの実行が許可されている場合に、当該サービスシナリオに含まれている一連のサービスの全てが許可されているか否かを判定することを特徴とするビジネスプロセス実行システム。
【請求項１１】
請求項８から１０のいずれか一項に記載のビジネスプロセス実行システムであって、
前記認可判定手段は、
前記サービス実行サーバから受信した認可判定要求に応じて行った認可判定の結果を、認可判定の対象となったそれぞれのサービスを提供しているサービス提供サーバから、認可判定の対象となったユーザについての認可判定を要求される前に、当該サービス提供サーバへ送信することを特徴とするビジネスプロセス実行システム。
【請求項１２】
請求項８から１０のいずれか一項に記載のビジネスプロセス実行システムであって、
それぞれのサービス提供サーバは、前記認可サーバの機能を有し、
前記シナリオ実行手段は、
クライアント側の通信装置からユーザＩＤおよびシナリオＩＤを含むサービス要求を受信した場合に、当該シナリオＩＤに対応するサービスシナリオを前記シナリオ格納手段から取得し、当該ユーザＩＤおよび取得したサービスシナリオに含まれているサービスのサービスＩＤを含む認可判定要求を、それぞれのサービスを実行するサービス提供サーバへ送信することにより、当該サービスシナリオに含まれているサービスの認可判定結果を取得し、
それぞれのサービス提供サーバは、
前記サービス実行サーバから受信した認可判定要求に基づいて、当該認可判定要求に含まれるユーザＩＤのユーザに対してサービスの提供が許可されるか否かを判定する認可判定を実行し、認可判定結果および当該認可判定結果の対象となるサービスのサービスＩＤを含む認可判定応答を前記サービス実行サーバへ送信すると共に、当該ユーザＩＤに対応付けて当該認可判定結果を保持することを特徴とするビジネスプロセス実行システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【公開番号】特開２００９−９９１３１（Ｐ２００９−９９１３１Ａ）
【公開日】平成２１年５月７日（２００９．５．７）
【国際特許分類】
【出願番号】特願２００８−２２５９６１（Ｐ２００８−２２５９６１）
【出願日】平成２０年９月３日（２００８．９．３）
【国等の委託研究の成果に係る記載事項】（出願人による申告）国等の委託研究の成果に係る特許出願（平成２０年度、独立行政法人情報通信研究機構 「次世代ネットワーク（ＮＧＮ）基盤技術の研究開発」委託研究、産業技術力強化法第１９条の適用を受ける特許出願）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
【公開日】平成２１年５月７日（２００９．５．７）
【国際特許分類】
【出願日】平成２０年９月３日（２００８．９．３）
【国等の委託研究の成果に係る記載事項】（出願人による申告）国等の委託研究の成果に係る特許出願（平成２０年度、独立行政法人情報通信研究機構 「次世代ネットワーク（ＮＧＮ）基盤技術の研究開発」委託研究、産業技術力強化法第１９条の適用を受ける特許出願）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
[ Back to top ]