判定装置、判定方法およびプログラム
【課題】 サービス提供者とサービス利用者との間が多対多のアクセスによるサービス提供を実現する場合、サービス提供の可否を事前に判定することは困難である。
【解決手段】 ノード階層種別とノード属性値とをそれぞれ含む第１ノード情報および第２ノード情報からなるノード組情報を少なくとも２つ以上含む判定要求について、予め定められた第１可否設定に基づいて、ノード組情報で指定されたノード組毎の第１アクセス可否判定結果を取得する第１可否判定手段と、予め定められた第２可否設定に基づいて、第１アクセス可否判定結果と、ノード組の第１ノード情報のノード階層種別および第２ノード情報のノード階層種別との組の組み合わせについて第２アクセス可否判定結果を取得する第２可否判定手段とを有する。
【解決手段】 ノード階層種別とノード属性値とをそれぞれ含む第１ノード情報および第２ノード情報からなるノード組情報を少なくとも２つ以上含む判定要求について、予め定められた第１可否設定に基づいて、ノード組情報で指定されたノード組毎の第１アクセス可否判定結果を取得する第１可否判定手段と、予め定められた第２可否設定に基づいて、第１アクセス可否判定結果と、ノード組の第１ノード情報のノード階層種別および第２ノード情報のノード階層種別との組の組み合わせについて第２アクセス可否判定結果を取得する第２可否判定手段とを有する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、判定装置、判定方法およびプログラムに関し、特にアクセス可否を判定する判定装置、判定方法およびプログラムに関する。
【背景技術】
【０００２】
近年、複数の処理要素が連携処理を行うサービスが広まっている。更に、サービス提供に対する可否判定が必要とされている。
【０００３】
例えば、非特許文献２は、ユーザがウェブサービスに対して要求することで、通信キャリア網越しのキャリア端末との通話を可能にするような３ＰＣＣ（３ｒｄ Ｐａｒｔｙ
Ｃａｌｌ Ｃｏｎｔｒｏｌ）サービスが提供されている。また、非特許文献３は、３ＰＣＣサービスにおけるＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）の使用方法について記載している。
【０００４】
このようなサービス提供の"可否を判定する"システムにおいては、１つ以上の処理要素を考慮する必要がある。処理要素には処理の主体と対象の組(以降、主対組)が存在する。例えば、３ＰＣＣサービスでは、主体としてウェブサービスと対象としてキャリア端末とからなる主対組と、主体としてユーザ端末と対象としてウェブサービスとからなる主対組との２つの主対組を要する。
【０００５】
一方、ネットワークなどを利用したサービスにおいて、不正なアクセス元からのアクセスを防ぐための技術が各種提案されている。
【０００６】
例えば、非特許文献１には、アクセス制御ポリシの書式仕様であるＸＡＣＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）が、記載されている。このＸＡＣＭＬは、アクセス主体とアクセス対象との組み合わせに対するアクセス可否を示すためのアクセス制御ポリシを記述することを可能にするものである。
【０００７】
また、例えば、アクセス制御の技術が特許文献１に記載されている。特許文献１記載の技術は、グループメンバすべてに設定されたアクセスポリシに対して、各グループのメンバ間のポリシに基づいて変換した結果を上書きすることにより、ポリシの正規化による管理コスト削減と適切なポリシカスタマイズとの両立を可能とする技術である。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２００３−３１６７４５号公報
【非特許文献】
【０００９】
【非特許文献１】ｏａｓｉｓ−ａｃｃｅｓｓ＿ｃｏｎｔｒｏｌ−ｘａｃｍｌ−２．０−ｃｏｒｅ−ｓｐｅｃ−ｏｓ http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-core-spec-os.pdf
【非特許文献２】ＥＴＳＩ ＥＳ ２０２ ３９１−２ Ｏｐｅｎ Ｓｅｒｖｉｃｅ Ａｃｃｅｓｓ （ＯＳＡ）； Ｐａｒｌａｙ Ｘ ＷｅｂＳｅｒｖｉｃｅｓ； Ｐａｒｔ２： Ｔｈｉｒｄ Ｐａｒｔｙ Ｃａｌｌ http://www.parlay.org/imwp/download.asp?ContentID=9594
【非特許文献３】ＢＣＰ ８５， ＲＦＣ ３７２５ Ｂｅｓｔ Ｃｕｒｒｅｎｔ Ｐｒａｃｔｉｃｅｓ ｆｏｒ Ｔｈｉｒｄ Ｐａｒｔｙ Ｃａｌｌ Ｃｏｎｔｒｏｌ （３ｐｃｃ） ｉｎ ｔｈｅ Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ （ＳＩＰ） http://www.ietf.org/rfc/rfc3725.txt
【発明の概要】
【発明が解決しようとする課題】
【００１０】
しかしながら、上記のサービス提供をサービス利用者からサービス提供者へのアクセスと捉えた場合、ＸＡＣＭＬは、アクセス制御ポリシに必要な汎用データモデルと、ポリシ形式を定めたものであり、３ＰＣＣなどの複数の処理要素が連携処理を行う技術分野への応用は開示されていない。
【００１１】
また、特許文献１記載の技術は、１つの主対組のみをアクセス制御の対象としており、例えば、グループ間のポリシとメンバ間のポリシに対する可否判定を総合的に捕らえてアクセス制御を行うことはできない。
【００１２】
従って、サービス提供者とサービス利用者との間が多対多のアクセスによるサービス提供を実現する場合、このようなサービス提供の可否を事前に判定することは困難であるという問題があった。つまり、サービス利用者がサービス提供の可否を事前に知ることは困難であり、例えば主体が３ＰＣＣサービスにサービス提供要求を送信したものの、実際はサービス提供に要する複数の主対組の内の少なくとも１つの主対組の可否判定が拒否になっているために、サービス提供要求が拒否されてしまい、結局は無駄になってしまうサービス提供要求を送信してしまうことを防ぐことができなかった。
【００１３】
本発明の目的は、上述した問題を解決する判定装置、判定方法およびプログラムを提供することにある。
【課題を解決するための手段】
【００１４】
本発明の判定装置は、ノード階層種別とノード属性値とをそれぞれ含む第１ノード情報および第２ノード情報からなるノード組情報を少なくとも２つ以上含む判定要求について、
予め定められた第１可否設定に基づいて、前記ノード組情報で指定されたノード組毎の第１アクセス可否判定結果を取得する第１可否判定手段と、
予め定められた第２可否設定に基づいて、前記第１アクセス可否判定結果と前記ノード組の第１ノード情報の前記ノード階層種別および第２ノード情報の前記ノード階層種別との組の組み合わせについて第２アクセス可否判定結果を取得する第２可否判定手段とを有する。
【００１５】
本発明の判定方法は、ノード階層種別とノード属性値とをそれぞれ含む第１ノード情報および第２ノード情報からなるノード組情報を少なくとも２つ以上含む判定要求について、
予め定められた第１可否設定に基づいて、前記ノード組情報で指定されたノード組毎の第１アクセス可否判定結果を取得し、
予め定められた第２可否設定に基づいて、前記第１アクセス可否判定結果と前記ノード組の第１ノード情報の前記ノード階層種別および第２ノード情報の前記ノード階層種別との組の組み合わせについて第２のアクセス可否を判定する。
【００１６】
本発明のプログラムは、ノード階層種別とノード属性値とをそれぞれ含む第１ノード情報および第２ノード情報からなるノード組情報を少なくとも２つ以上含む判定要求について、
予め定められた第１可否設定に基づいて、前記ノード組情報で指定されたノード組毎の第１のアクセス可否を判定し、
予め定められた第２可否設定に基づいて、前記第１アクセス可否判定結果と前記ノード組の第１ノード情報の前記ノード階層種別および第２ノード情報の前記ノード階層種別との組の組み合わせについて第２のアクセス可否を判定する処理をコンピュータに実行させる。
【発明の効果】
【００１７】
本発明によれば、サービス提供者とサービス利用者との間のサービス提供が多対多のアクセスによるものであってもサービス提供の可否を事前に判定することができる。
【図面の簡単な説明】
【００１８】
【図１】本発明の第１の実施形態の構成を示すブロック図である。
【図２】本発明の第１乃至４の実施形態におけるサービス提供可否判定要求の構造を示す図である。
【図３】本発明の第１および第４の実施形態における第１可否設定の構造を示す図である。
【図４】本発明の第１および第４の実施形態における第２可否設定の構造を示す図である。
【図５】本発明の第１の実施形態の全体の動作を示すシーケンス図である。
【図６】本発明の第１の実施形態におけるサービス提供可否判定要求の例を示す図である。
【図７】本発明の第１の実施形態における第２可否判定要求の構造と例とを示す図である。
【図８】本発明の第１の実施形態の第１判定部の動作を示すフローチャートである。
【図９】本発明の第１の実施形態の第２判定部の動作を示すフローチャートである。
【図１０】本発明の第２の実施形態の構成を示すブロック図である。
【図１１】本発明の第２および第３の実施形態における主対組設定の構造と例とを示す図である。
【図１２】本発明の第２の実施形態の全体の動作を示すシーケンス図である。
【図１３】本発明の第２の実施形態におけるサービス提供可否判定要求の例を示す図である。
【図１４】本発明の第２の実施形態における更新後サービス提供可否判定要求の構造と例とを示す図である。
【図１５】本発明の第３の実施形態の構成を示すブロック図である。
【図１６】本発明の第３の実施形態における更新後サービス提供可否判定要求の構造と例とを示す図である。
【図１７】本発明の第３の実施形態における第１可否設定の構造を示す図である。
【図１８】本発明の第３の実施形態における第２可否設定の構造を示す図である。
【図１９】本発明の第３の実施形態における第２可否判定要求の構造と例とを示す図である。
【図２０】本発明の第３の実施形態の全体の動作を示すシーケンス図である。
【図２１】本発明の第３の実施形態における更新後サービス提供可否判定要求の例を示す図である。
【図２２】本発明の第３の実施形態における更新後サービス提供可否判定要求の例を示す図である。
【図２３】本発明の第３の実施形態における第２可否判定要求の例を示す図である。
【図２４】本発明の第３の実施形態の第１判定部の動作を示すフローチャートである。
【図２５】本発明の第３の実施形態の第２判定部の動作を示すフローチャートである。
【図２６】本発明の第４の実施形態の構成を示すブロック図である。
【発明を実施するための形態】
【００１９】
次に、本発明の第１の実施形態について図面を参照して詳細に説明する。
【００２０】
まず、サービス提供者とサービス利用者間のサービスの提供について説明する。
【００２１】
このサービスは、少なくとも２つの終端ノードと任意の数の中継ノードを介して提供される。終端ノードおよび中継ノードのいずれか１つを主体ノード（一般的に、第１ノードとも呼ばれる）とし、他のいずれか１つを対象ノード（一般的に、第２ノードとも呼ばれる）とし、主体ノードと対象ノードの組を主対組（一般的に、ノード組とも呼ばれる）とすると、上記のサービスは少なくとも１つの主対組を含む。
【００２２】
終端ノードおよび中継ノードは、サービス提供者とサービス利用者間のサービス提供に要する主対組を識別するノード階層種別およびノード属性値をそれぞれ有している。
【００２３】
ノード階層種別とは、「加入者」、「端末」、「ＷＰＡＮ（Ｗｉｒｅｌｅｓｓ Ｐｅｒｓｏｎａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）端末」および「ウェブサービス」などの主体ノードおよび対象ノードの階層的な種別を示すものである。
【００２４】
ノード属性値とは、主体ノードおよび対象ノードを一意に識別する識別子、もしくは主体ノードのまとまりおよび対象ノードのまとまりを識別する代表識別子（例えば、正規表現を用いて示される識別子）である。ノード階層種別およびノード属性値は、例えばサービス提供に用いるＳＩＰリクエスト内のＦｒｏｍヘッダや、ＳＩＰ ＩＮＶＩＴＥリクエスト内ＳＤＰ（ＳＥＳＳＩＯＮ ＤＥＳＣＲＩＰＴＩＯＮ
ＰＲＯＴＯＣＯＬ）のｃ行、ＳＯＡＰ（ＳＩＭＰＬＥ ＯＢＪＥＣＴ ＡＣＣＥＳＳ ＰＲＯＴＯＣＯＬ）リクエスト内ネームスペースなどから形成される。
【００２５】
図１は、本発明の第１の実施形態の構成を示すブロック図である。
【００２６】
図１を参照すると、本発明の第１の実施形態は、サービス提供可否（一般的にアクセス可否とも呼ばれる）判定装置（一般的に判定装置とも呼ばれる）１００、通信端末９２０およびネットワーク９１０から構成されている。
【００２７】
通信端末９２０は、通信機能を有する情報処理機器であり、例えば携帯電話機、ＰＤＡあるいはパーソナルコンピュータ等であってよい。
【００２８】
通信端末９２０は、サービス提供者とサービス利用者間のサービス提供に関わるノードの階層種別やノードの属性値を予め取得し、例えば図２に示すようなサービス提供可否判定要求（一般的に判定要求とも呼ばれる）９２１をサービス提供可否判定装置１００へ送信する。
【００２９】
図２に示すサービス提供可否判定要求９２１は、主体ノード階層種別９２３および主体ノード属性値９２４（主体ノード階層種別９２３および主体ノード属性値９２４は、まとめて一般的に第１ノード情報とも呼ばれる）と対象ノード階層種別９２５および対象ノード属性値９２６（対象ノード階層種別９２５および対象ノード属性値９２６は、まとめて一般的に第２ノード情報とも呼ばれる）とを含む主対組（ノード組とも呼ばれる）情報（ノード組情報とも呼ばれる）９２２を少なくとも１つ含む。尚、主体ノード階層種別９２３および対象ノード階層種別９２５は、主体ノードおよび対象ノードの階層的な種別を示す情報である。主体ノード属性値９２４および対象ノード属性値９２６は、ノードを個別に識別する情報である。
【００３０】
サービス提供可否判定装置１００は、第１可否設定記憶部１６０と第２可否設定記憶部１７０と応答部１４０と第１判定部１１０と第２判定部１２０とを含む。
【００３１】
第１可否設定記憶部１６０は、主対組情報９２２と、この主対組情報９２２で特定される主対組におけるサービス提供の可否を判定する第１可否判定結果（第１アクセス可否判定結果とも呼ばれる）１６２とを含む第１可否設定１６１を記憶する。第１可否設定記憶部１６０に記憶されている第１可否設定１６１の構造を図３に示す。
【００３２】
尚、サービス提供に対する可否判定に用いる第１可否設定１６１の範囲は、以下の（ａ）、（ｂ）の２つの場合が考えられる。（ａ）サービス提供に対する可否判定に必要最低限の主対組に対応する可否設定とする場合。（ｂ）サービス提供に対する可否判定に関連するすべての主対組に対応する可否設定とする場合。（ａ）、（ｂ）のいずれを採用するかは、例えばシステム設定によって定めることができる。本実施形態では、システム設定により（ａ）が定められているものとして、説明する。
【００３３】
第２可否設定記憶部１７０は、例えば図４に示すように１つ以上の第２可否設定１７１を記憶する。第２可否設定１７１は、主対組情報９２２に含まれる主体ノード階層種別９２３および対象ノード階層種別９２５とこの主対組情報９２２に対する第１可否判定結果１６２との組の組み合わせに対応する第２可否判定結果（第２アクセス可否判定結果とも呼ばれる）１７２とからなる。即ち、第２可否設定１７１には、特定の主対組の組み合わせにおいてのサービス提供に対する可否判定が設定されている。
第２可否設定記憶部１７０に記憶されている第２可否設定１７１の構造を図４に示す。
【００３４】
応答部１４０は、通信端末９２０からサービス提供可否判定要求９２１を受信し、第１判定部１１０へ送信する。また、応答部１４０は、第２判定部１２０から第２可否判定結果１７２を受信し、受信した第２可否判定結果１７２に基づいてサービス提供可否判定要求９２１への応答を通信端末９２０へ送信する。
【００３５】
第１判定部１１０は、第１可否設定記憶部１６０に記憶された第１可否設定１６１を参照して、サービス提供可否判定要求９２１に含まれる各主対組情報９２２に対する第１可否判定結果１６２を取得し、サービス提供可否判定要求９２１と取得した第１可否判定結果１６２とに基づいて図７に示すような第２可否判定要求１１１を生成し、第２判定部１２０へ送信する。
【００３６】
第２判定部１２０は、第２可否設定記憶部１７０に記憶された第２可否設定１７１を参照して、サービス提供可否判定要求９２１に含まれる各主対組情報９２２の主体ノード階層種別９２３および対象ノード階層種別９２５とこの主対組情報９２２に対応する第１可否判定結果１６２との組みの組み合わせに対する第２可否判定結果１７２を取得し、この取得した第２可否判定結果１７２を応答部１４０へ送信する。
【００３７】
次に本実施形態の動作について図１〜図９を参照して詳細に説明する。
【００３８】
以下では、通信端末９２０がサービス提供（例えばＳＯＡＰリクエストを３ＰＣＣウェブサービスに送信する）試行前にサービス提供可否判定要求９２１をサービス提供可否判定装置１００へ送信し、これに応答してサービス提供可否判定装置１００が第２可否判定結果１７２を通信端末９２０へ送信する動作を例にして説明する。
【００３９】
前提として、通信端末９２０の利用者をＡ、Ａがサービス提供したい通信端末（図示しない）の利用者をＢとする。また、サービス提供に要するある１つの主対組情報９２２の主体ノード階層種別９２３を“端末”、主体ノード属性値９２４を“sip:terminal1@example.com”、対象ノード階層種別９２５を“端末”、対象ノード属性値９２６を“sip:terminal2@example.com”とし、この主対組情報９２２に対応する第１可否判定結果１６２は“許可”であるものとする。更に、サービス提供に要する他の１つの主対組情報９２２の主体ノード階層種別９２３を“ウェブサービス”、主体ノード属性値９２４を“ws1@example.com”、対象ノード階層種別９２５を“端末”、対象ノード属性値９２６を“sip:terminal2@example.com”とし、この主対組情報９２２に対応する第１可否判定結果１６２は“拒否”であるものとする。
【００４０】
図５は、本実施形態における全体の動作を示すシーケンス図である。
【００４１】
利用者Ａが通信端末９２０上でサービス提供したい利用者Ｂへのサービス提供操作を行うと、通信端末９２０は、ネットワーク９１０を経由してサービス提供可否判定装置１００に対して例えば図６に示すようなサービス提供可否判定要求９２１を送信する（ステップＳ５１０）。
【００４２】
このサービス提供可否判定要求９２１には、主体ノード階層種別９２３と主体ノード属性値９２４と対象ノード階層種別９２５と対象ノード属性値９２６とを含む主対組情報９２２が２つ含まれている。１つめの主対組情報９２２の主体ノード階層種別９２３は“端末”、主体ノード属性値９２４は“sip:terminal1@example.com”、対象ノード階層種別９２５は“端末”、対象ノード属性値９２６は“sip:terminal2@example.com”、２つめの主対組情報９２２の主体ノード階層種別９２３は“ウェブサービス”、主体ノード属性値９２４は“ws1@example.com”、対象ノード階層種別９２５は“端末”、対象ノード属性値９２６は“sip:terminal2@example.com”である。
【００４３】
次に、応答部１４０は、サービス提供可否判定要求９２１を第１判定部１１０に送信する（ステップＳ５１２）。
【００４４】
次に、第１判定部１１０は、例えば図３に示すような第１可否設定記憶部１６０の第１可否設定１６１を検索し、サービス提供可否判定要求９２１に含まれる１つ目の主対組情報９２２（主体ノード階層種別９２３“端末”、主体ノード属性値９２４“sip:terminal1@example.com”、対象ノード階層種別９２５“端末”、対象ノード属性値９２６“sip:terminal2@example.com”）に対する第１可否判定結果１６２“許可”を取得する。同様に、第１判定部１１０は、２つ目の主対組情報９２２（主体ノード階層種別９２３“ウェブサービス”、主体ノード属性値９２４“ws1@example.com”、対象ノード階層種別９２５“端末”、対象ノード属性値９２６“sip:terminal2@example.com”）に対する第１可否判定結果１６２“拒否”を取得する。
【００４５】
続けて、第１判定部１１０は、サービス提供可否判定要求９２１とこれに含まれる主対組情報９２２それぞれに対応する第１可否判定結果１６２とに基づいて図７に示すような第２可否判定要求１１１を生成し、第２判定部１２０に送信する（ステップＳ５１４）。
【００４６】
次に、第２判定部１２０は、例えば図４に示すような第２可否設定記憶部１７０の第２可否設定１７１を検索し、サービス提供可否判定要求９２１に含まれる１つ目の主対組情報９２２の主体ノード階層種別９２３“端末”、対象ノード階層種別９２５“端末”およびこの主対組情報９２２に対する第１可否判定結果１６２“許可”の組と、２つ目の主対組情報９２２の主体ノード階層種別９２３“ウェブサービス”、対象ノード階層種別９２５“端末”およびこの主対組情報９２２に対する第１可否判定結果１６２“拒否”の組との組み合わせに対する第２可否判定結果１７２“許可”を取得する。
【００４７】
続けて、第２判定部１２０は、第２可否判定結果１７２を応答部１４０に送信する（ステップＳ５１６）。
【００４８】
次に、応答部１４０は、サービス提供可否判定要求９２１に対するサービス提供可否判定結果として、第２可否判定結果１７２に基づいた応答をネットワーク９１０経由で通信端末９２０に送信する（ステップＳ５１８）。
【００４９】
図８は、図５のステップＳ５１４における第１判定部１１０の動作を示すフローチャートである。
【００５０】
まず、第１判定部１１０は、第１可否設定記憶部１６０を参照し、サービス提供可否判定要求９２１に含まれる主対組情報９２２に対応する第１可否設定１６１を検索する（ステップＳ１４１）。
【００５１】
続けて、第１判定部１１０は、検索した第１可否設定１６１から第１可否判定結果１６２を取得する（ステップＳ１４２）。
【００５２】
次に、第１判定部１１０は、サービス提供可否判定要求９２１に含まれる主対組情報９２２のすべてについてステップＳ１４１を実行したか否かを判定する（ステップＳ１４３）。そして、未実行の主対組情報９２２がある場合（ステップＳ１４３でＮＯ）、処理はステップＳ１４１へ進む。また、すべて実行済の場合（ステップＳ１４３でＹＥＳ）、処理はステップＳ１４６へ進む。
【００５３】
次に、第１判定部１１０は、サービス提供可否判定要求９２１とこれに含まれる主対組情報９２２それぞれに対応する第１可否判定結果１６２とに基づいて図７に示すような第２可否判定要求１１１を生成し、第２判定部１２０へ送信する（ステップＳ１４６）。
【００５４】
図９は、図５のステップＳ５１６における第２判定部１２０の動作を示すフローチャートである。
【００５５】
まず、第２判定部１２０は、第２可否設定記憶部１７０を参照し、サービス提供可否判定要求９２１に含まれる各主対組情報９２２の主体ノード階層種別９２３および対象ノード階層種別９２５とこの主対組情報９２２に対する第１可否判定結果１６２との組の組み合わせに対応する第２可否設定１７１を検索する（ステップＳ１６１）。
【００５６】
続けて、第２判定部１２０は、検索した第２可否設定１７１から第２可否判定結果１７２を取得する（ステップＳ１６２）。
【００５７】
次に、第２判定部１２０は、第２可否判定結果１７２を応答部１４０に送信する（ステップＳ１６４）。
【００５８】
上述した本実施形態における第１の効果は、サービス提供者とサービス利用者との間のサービス提供が多対多のアクセスによるものであってもサービス提供の可否を事前に判定することを可能にできる点である。
【００５９】
その理由は、第１判定部１１０が第１可否判定結果１６２を取得し、各主対組におけるサービス提供可否を判定し、第１可否判定結果１６２を利用して第２判定部１２０が第２可否判定結果１７２を取得し、主対組の組み合わせ全体におけるサービス提供可否を判定するようにしたからである。
【００６０】
上述した本実施形態における第２の効果は、特定の主対組情報９２２に対する可否を判定サービス提供の可否判定に反映することを可能にできる点である。
【００６１】
その理由は、第２可否判定結果が主対組情報９２２に含まれる主体ノード階層種別９２３と対象ノード階層種別９２５とこの主対組情報９２２に対する第１可否判定結果１６２との組の組み合わせに対してサービス提供可否を示すものであるようにしたからである。
【００６２】
次に本発明の第２の実施形態について図面を参照して説明する。
【００６３】
図１０は、本発明の第２の実施形態の構成を示すブロック図である。図１０を参照すると、本発明の第２の実施形態は、図１に示した第１の実施形態と比較して、サービス提供可否判定装置２００内に新たに主対組設定記憶部２８０と主対組更新部２３０とを備えている点、応答部１４０に代えて応答部２４０を備えている点で相違している。
【００６４】
応答部２４０は、通信端末９２０からサービス提供可否判定要求９２１を受信し、これを主対組更新部２３０へ送信する。また、応答部２４０は、主対組更新部２３０から図１４に示すような更新後サービス提供可否判定要求２３１を受信し、第１判定部１１０へ送信する。更に、応答部２４０は、第２判定部１２０から第２可否判定結果１７２を受信し、受信した第２可否判定結果１７２に基づいてサービス提供可否判定要求９２１への応答を通信端末９２０へ送信する。
【００６５】
図１４に示す更新後サービス提供可否判定要求２３１はサービス提供可否判定要求９２１と同様の構造を有するが、サービス提供可否判定要求９２１と異なる点として、更新後サービス提供可否判定要求２３１に含まれる主対組情報９２２の１つ以上が、後述する主対組更新部２３０によって追加された付加主対組情報２８２であることを含む。
【００６６】
主対組設定記憶部２８０は、例えば図１１に示すように、主体ノード階層種別９２３、主体ノード属性値９２４、対象ノード階層種別９２５および対象ノード属性値９２６を含む付加主対組情報（付加ノード組情報とも呼ばれる）２８２を主対組情報９２２に対応付けた主対組設定２８１を記憶する。付加主対組情報２８２は、特定のサービス提供に対する可否判定に必要な所定の主対組情報９２２であってよい。
【００６７】
主対組更新部２３０は、主対組設定記憶部２８０の主対組設定２８１を参照してサービス提供可否判定要求９２１に含まれる主対組情報９２２に対応する付加主対組情報２８２を取得し、これをサービス提供可否判定要求９２１に追加し、図１４に示すような更新後サービス提供可否判定要求２３１を応答部２４０へ送信する。
【００６８】
次に本実施形態の動作について図１０〜図１４を参照して詳細に説明する。
【００６９】
説明する動作の例および前提は、第１の実施形態と同様である。
【００７０】
図１２は、本実施形態における全体の動作を示すシーケンス図である。
【００７１】
利用者Ａが通信端末９２０上でサービス提供したい利用者Ｂへのサービス提供操作を行うと、通信端末９２０は、ネットワーク９１０を経由して、サービス提供可否判定装置２００の応答部２４０に対して例えば図１３に示すようなサービス提供可否判定要求９２１を送信する（ステップＳ５２０）。
【００７２】
このサービス提供可否判定要求９２１には、主体ノード階層種別９２３と主体ノード属性値９２４と対象ノード階層種別９２５と対象ノード属性値９２６とを含む主対組情報９２２が含まれている。主体ノード階層種別９２３は“端末”、主体ノード属性値９２４は“sip:terminal1@example.com”、対象ノード階層種別９２５は“端末” 対象ノード属性値９２６は“sip:terminal2@example.com”である。
【００７３】
次に、応答部２４０は、サービス提供可否判定要求９２１を主対組更新部２３０に送信する（ステップＳ５２２）。
【００７４】
次に、主対組更新部２３０は、例えば図７に示すような主対組設定記憶部２８０の主対組設定２８１を検索し、サービス提供可否判定要求９２１に含まれる主対組情報９２２（主体ノード階層種別９２３“端末”、主体ノード属性値９２４“sip:terminal1@example.com”、対象ノード階層種別９２５“端末”、対象ノード属性値９２６“sip:terminal2@example.com”）に対する付加主対組情報２８２（主体ノード階層種別９２３“ウェブサービス”、主体ノード属性値９２４“ws1@example.com”、対象ノード階層種別９２５“端末”、対象ノード属性値９２６“sip:terminal2@example.com”）を取得する。そして、取得した付加主対組情報２８２を主対組情報９２２としてサービス提供可否判定要求９２１に追加し、図１４に示すような更新後サービス提供可否判定要求２３１を応答部２４０へ送信する（ステップＳ５２４）。
【００７５】
次に、応答部２４０は、更新後サービス提供可否判定要求２３１を第１判定部１１０に送信する（ステップＳ５２６）。
【００７６】
以後の動作は、サービス提供可否判定要求９２１が更新後サービス提供可否判定要求２３１に、および応答部１４０が応答部２４０に変わっていることを除いて第１の実施形態のステップＳ５１４〜ステップＳ５１８における動作と同様であるので説明を省略する。
【００７７】
上述した本実施形態における効果は、第１の実施形態と同様の効果を有することに加えて、サービス提供者あるいはサービス利用者は、サービス提供に要するノードの内の一部を把握していない場合であっても、サービス提供の可否を事前に判定することを可能にできる点である。
【００７８】
その理由は、主対組更新部２３０がサービス提供可否判定要求９２１に特定のサービス提供に対する可否判定に必要な主対組情報９２２を追加するようにしたからである。
【００７９】
次に本発明の第３の実施形態について図面を参照して説明する。
【００８０】
図１５は、本発明の第３の実施形態の構成を示すブロック図である。図１５を参照すると、本発明の第３の実施形態は、図１０に示した第２の実施形態と比較して、主対組更新部２３０に代えて主対組更新部３３０を、第１可否設定記憶部１６０に代えて第１可否設定記憶部３６０を、第２可否設定記憶部１７０に代えて第２可否設定記憶部３７０を、第１判定部１１０に代えて第１判定部３１０を、第２判定部１２０に代えて第２判定部３２０を備えている点で相違している。
【００８１】
主対組更新部３３０は、主対組設定記憶部２８０の主対組設定２８１を参照してサービス提供可否判定要求９２１に含まれる主対組情報９２２に対応する付加主対組情報２８２を取得し、取得した付加主対組情報２８２および付加主対組フラグ（付加ノード組フラグとも呼ばれる）３６３“真”をサービス提供可否判定要求９２１に追加し、図１６に示すような更新後サービス提供可否判定要求３３１を応答部２４０へ送信する。
【００８２】
第１可否設定記憶部３６０は、例えば図１７に示すように主対組情報９２２および付加主対組フラグ３６３とこれらに対応する第１可否判定結果３６２とからなる第１可否設定３６１を記憶する。
【００８３】
第２可否設定記憶部３７０は、例えば図１８に示すように１つ以上の第２可否設定３７１を記憶する。第２可否設定３７１は、主対組情報９２２に含まれる主体ノード階層種別９２３および対象ノード階層種別９２５とこの主対組情報９２２に対する付加主対組フラグ３６３および第１可否判定結果３６２との組の組み合わせに対応する第２可否判定結果３７２とからなる。
【００８４】
第１判定部３１０は、第１可否設定記憶部３６０に記憶された第１可否設定３６１を参照して、サービス提供可否判定要求９２１に含まれる各主対組情報９２２および付加主対組フラグ３６３の組に対する第１可否判定結果３６２を取得し、サービス提供可否判定要求９２１と取得した第１可否判定結果３６２とに基づいて図１９に示すような第２可否判定要求３１１を生成し、第２判定部３２０へ送信する。
【００８５】
第２判定部３２０は、第２可否設定記憶部３７０に記憶された第２可否設定３７１を参照して、サービス提供可否判定要求９２１に含まれる各主対組情報９２２の主体ノード階層種別９２３および対象ノード階層種別９２５とこの主対組情報９２２に対応する付加主対組フラグ３６３および第１可否判定結果３６２との組みの組み合わせに対する第１可否判定結果３７２を取得し、この取得した第２可否判定結果３７２を応答部２４０へ送信する。
【００８６】
次に本実施形態の動作について図１１、図１５〜図２５を参照して詳細に説明する。
【００８７】
説明する動作の例および前提は、第２の実施形態と同様である。
【００８８】
図２０は、本実施形態における全体の動作を示すシーケンス図である。
【００８９】
ステップＳ５１０における動作は、第２の実施形態と同様であるので説明を省略する。
【００９０】
次に、応答部２４０は、サービス提供可否判定要求９２１を主対組更新部３３０に送信する（ステップＳ５３８）。
【００９１】
次に、主対組更新部２３０は、図１１に示すような主対組設定記憶部２８０の主対組設定２８１を検索し、サービス提供可否判定要求９２１に含まれる主対組情報９２２（主体ノード階層種別９２３“端末”、主体ノード属性値９２４“sip:terminal1@example.com”、対象ノード階層種別９２５“端末”、対象ノード属性値９２６“sip:terminal2@example.com”）に対する付加主対組情報２８２（主体ノード階層種別９２３“ウェブサービス”、主体ノード属性値９２４“ws1@example.com”、対象ノード階層種別９２５“端末”、対象ノード属性値９２６“sip:terminal2@example.com”）を取得する。続けて、主対組更新部２３０は、取得した付加主対組情報２８２を主対組情報９２２としてサービス提供可否判定要求９２１に追加する。更に、主対組更新部２３０は、この追加した主対組情報９２２に対する付加主対組フラグ３６３“真”を、サービス提供可否判定要求９２１に追加し、図１６に示すような更新後サービス提供可否判定要求３３１を応答部２４０へ送信する（ステップＳ５４０）。
【００９２】
次に、応答部２４０は、更新後サービス提供可否判定要求３３１を第１判定部３１０に送信する（ステップＳ５４２）。
【００９３】
次に、第１判定部３１０は、例えば図１７に示すような第１可否設定記憶部３６０の第１可否設定３６１を検索し、サービス提供可否判定要求９２１に含まれる１つ目の主対組情報９２２（主体ノード階層種別９２３“端末”、主体ノード属性値９２４“sip:terminal1@example.com”、対象ノード階層種別９２５“端末”、対象ノード属性値９２６“sip:terminal2@example.com”）と付加主対組フラグ３６３“真”が付加されていないこととに対する第１可否判定結果３６２“許可”を取得する。同様に、第１判定部１１０は、２つ目の主対組情報９２２（主体ノード階層種別９２３“ウェブサービス”、主体ノード属性値９２４“ws1@example.com”、対象ノード階層種別９２５“端末”、対象ノード属性値９２６“sip:terminal2@example.com”）と付加主対組フラグ３６３“真”が付加されていないこととに対する第１可否判定結果３６２“拒否”を取得する。更に同様に、第１判定部１１０は、３つ目の主対組情報９２２（主体ノード階層種別９２３“ウェブサービス”、主体ノード属性値９２４“ws1@example.com”、対象ノード階層種別９２５“端末”、対象ノード属性値９２６“sip:terminal2@example.com”）と付加主対組フラグ３６３“真”が付加されていることとに対する第１可否判定結果３６２“許可”を取得する。
【００９４】
続けて、第１判定部３１０は、サービス提供可否判定要求９２１とこれに含まれる主対組情報９２２それぞれに対応する第１可否判定結果３６２とに基づいて図１９に示すような第２可否判定要求３１１を生成し、第２判定部３２０へ送信する（ステップＳ５４４）。
【００９５】
次に、第２判定部３２０は、例えば図１８に示すような第２可否設定記憶部３７０の第２可否設定３７１を検索し、サービス提供可否判定要求９２１に含まれる１つ目の主対組情報９２２の主体ノード階層種別９２３“端末”、対象ノード階層種別９２５“端末”、付加主対組フラグ３６３“真”が付加されていないことおよびこの主対組情報９２２に対する第１可否判定結果１６２“許可”の組と、２つ目の主対組情報９２２の主体ノード階層種別９２３“ウェブサービス”、対象ノード階層種別９２５“端末”、付加主対組フラグ３６３“真”が付加されていないことおよびこの主対組情報９２２に対する第１可否判定結果１６２“拒否”の組と、３つ目の主対組情報９２２の主体ノード階層種別９２３“ウェブサービス”、対象ノード階層種別９２５“端末”、付加主対組フラグ３６３“真”が付加されていることおよびこの主対組情報９２２に対する第１可否判定結果１６２“許可”の組との組み合わせに対する第２可否判定結果３７２“許可”を取得する。
【００９６】
続けて、第２判定部３２０は、第２可否判定結果３７２を応答部２４０に送信する（ステップＳ５４６）。
【００９７】
次に、応答部２４０は、サービス提供可否判定要求９２１に対するサービス提供可否判定結果として、第２可否判定結果３７２に基づいた応答をネットワーク９１０経由で通信端末９２０に送信する（ステップＳ５４８）。
【００９８】
次に、動作の比較のために第２可否判定結果３７２“拒否”を取得する場合を説明する。
【００９９】
通信端末９２０は、ネットワーク９１０を経由してサービス提供可否判定装置１００に対して例えば図２１に示すようなサービス提供可否判定要求９２１を送信する（ステップＳ５１０）。
【０１００】
このサービス提供可否判定要求９２１には、１つめの主対組情報９２２の主体ノード属性値９２４が“sip:terminal9@example.com”であることが、第２可否判定結果３７２“許可”を取得する場合の説明と異なっている。
【０１０１】
次に、応答部２４０は、サービス提供可否判定要求９２１を主対組更新部３３０に送信する（ステップＳ５３８）。
【０１０２】
次に、主対組更新部３３０は、例えば図１１に示すような主対組設定記憶部２８０の主対組設定２８１を検索するが、サービス提供可否判定要求９２１に含まれる主対組情報９２２に対する付加主対組情報２８２を取得しない。続けて、主対組更新部３３０は、図２２に示すような更新後サービス提供可否判定要求３３１を応答部２４０へ送信する（ステップＳ５４０）。
【０１０３】
次に、応答部２４０は、更新後サービス提供可否判定要求３３１を第１判定部３１０に送信する（ステップＳ５４２）。
【０１０４】
次に、第１判定部３１０は、例えば図１７に示すような第１可否設定記憶部３６０の第１可否設定３６１を検索し、サービス提供可否判定要求９２１に含まれる１つ目の主対組情報９２２（主体ノード階層種別９２３“端末”、主体ノード属性値９２４“sip:terminal9@example.com”、対象ノード階層種別９２５“端末”、対象ノード属性値９２６“sip:terminal2@example.com”）と付加主対組フラグ３６３“真”が付加されていないこととに対する第１可否判定結果３６２“許可”を取得する。同様に、第１判定部１１０は、２つ目の主対組情報９２２（主体ノード階層種別９２３“ウェブサービス”、主体ノード属性値９２４“ws1@example.com”、対象ノード階層種別９２５“端末”、対象ノード属性値９２６“sip:terminal2@example.com”）と付加主対組フラグ３６３“真”が付加されていないこととに対する第１可否判定結果３６２“拒否”を取得する。
【０１０５】
続けて、第１判定部３１０は、サービス提供可否判定要求９２１とこれに含まれる主対組情報９２２それぞれに対応する第１可否判定結果３６２とに基づいて図２３に示すような第２可否判定要求３１１を生成し、第２判定部３２０へ送信する（ステップＳ５４４）。
【０１０６】
次に、第２判定部３２０は、例えば図１８に示すような第２可否設定記憶部３７０の第２可否設定３７１を検索し、サービス提供可否判定要求９２１に含まれる１つ目の主対組情報９２２の主体ノード階層種別９２３“端末”、対象ノード階層種別９２５“端末”、付加主対組フラグ３６３“真”が付加されていないことおよびこの主対組情報９２２に対する第１可否判定結果１６２“許可”の組と、２つ目の主対組情報９２２の主体ノード階層種別９２３“ウェブサービス”、対象ノード階層種別９２５“端末”、付加主対組フラグ３６３“真”が付加されていないことおよびこの主対組情報９２２に対する第１可否判定結果１６２“拒否”の組との組み合わせに対する第２可否判定結果３７２“拒否”を取得する。
【０１０７】
続けて、第２判定部３２０は、第２可否判定結果３７２を応答部２４０に送信する（ステップＳ５４６）。
【０１０８】
図２４は、図２０のステップＳ５４４における第１判定部３１０の動作を示すフローチャートである。
【０１０９】
まず、第１判定部３１０は、第１可否設定記憶部３６０を参照し、サービス提供可否判定要求９２１に含まれる主対組情報９２２と付加主対組フラグ３６３（付加主対組フラグ３６３“真”が付加されている場合は“真”、付加主対組フラグ３６３“真”が付加されていない場合は“偽”）とに対応する第１可否設定３６１を検索する（ステップＳ４４１）。
【０１１０】
続けて、第１判定部３１０は、検索した第１可否設定３６１から第１可否判定結果３６２を取得する（ステップＳ４４２）。
【０１１１】
次に、第１判定部３１０は、サービス提供可否判定要求９２１に含まれる主対組情報９２２のすべてについてステップＳ４４１を実行したか否かを判定する（ステップＳ４４３）。そして、未実行の主対組情報９２２がある場合（ステップＳ４４３でＮＯ）、処理はステップＳ１４１へ進む。また、すべて実行済の場合（ステップＳ４４３でＹＥＳ）、処理はステップＳ４４６へ進む。
【０１１２】
次に、第１判定部３１０は、サービス提供可否判定要求９２１とこれに含まれる主対組情報９２２それぞれに対応する第１可否判定結果３６２とに基づいて図１９に示すような第２可否判定要求３１１を生成し、第２判定部３２０へ送信する（ステップＳ４４６）。
【０１１３】
図２５は、図２０のステップＳ５４６における第２判定部３２０の動作を示すフローチャートである。
【０１１４】
まず、第２判定部３２０は、第２可否設定記憶部３７０を参照し、サービス提供可否判定要求９２１に含まれる各主対組情報９２２の主体ノード階層種別９２３および対象ノード階層種別９２５と付加主対組フラグ３６３（付加主対組フラグ３６３“真”が付加されている場合は“真”、付加主対組フラグ３６３“真”が付加されていない場合は“偽”）とこの主対組情報９２２に対する第１可否判定結果３６２との組の組み合わせに対応する第２可否設定３７１を検索する（ステップＳ４６１）。
【０１１５】
続けて、第２判定部３２０は、検索した第２可否設定３７１から第２可否判定結果３７２を取得する（ステップＳ４６２）。
【０１１６】
次に、第２判定部３２０は、第２可否判定結果３７２を応答部２４０に送信する（ステップＳ４６４）。
【０１１７】
上述した本実施形態における効果は、第２の実施形態と同様の効果を有することに加えて、通信端末９２０から受信したサービス提供可否判定要求９２１に含まれる主対組情報９２２と主対組更新部３３０の追加した主対組情報９２２（付加主対組情報２８２）とが同じ組み合わせである場合もそれぞれ異なる者として扱うことを可能にできる点である。
【０１１８】
その理由は、これらの主対組情報９２２を付加主対組フラグ３６３により区別するようにしたからである。
【０１１９】
次に本発明の第４の実施形態について図面を参照して説明する。
【０１２０】
図２６は、本発明の第４の実施形態の構成を示すブロック図である。図２６を参照すると、本発明の第４の実施形態は、第１判定手段４１０と第２判定手段４２０とを含むサービス提供可否判定装置４００から構成されている。
【０１２１】
第１判定部１１０は、例えば図３に示すような第１可否設定１６１に基づいて、例えば図２に示すようなサービス提供可否判定要求９２１に含まれる各主対組情報９２２について第１アクセス可否判定結果を取得する。
【０１２２】
第２判定部１２０は、例えば図４に示すような第２可否設定１７１に基づいて、第１アクセス可否判定結果である第1可否判定結果１６２と、サービス提供可否判定要求９２１に含まれる各主対組情報９２２の主体ノード階層種別９２３および対象ノード階層種別９２５との組の組み合わせに対する第２可否判定結果１７２により、アクセス可否を判定する。
【０１２３】
上述した本実施形態における効果は、サービス提供者とサービス利用者との間のサービス提供が多対多のアクセスによるものであってもサービス提供の可否を事前に判定することを可能にできる点である。
【０１２４】
その理由は、第１判定部１１０が各主対組におけるサービス提供可否を判定し、第２判定部１２０が第１判定部１１０の判定結果を利用して主対組の組み合わせ全体におけるサービス提供可否を判定するようにしたからである。
【０１２５】
以上の各実施形態で説明した各構成要素は、例えば、プログラムにより所定の処理をコンピュータに実行させてもよい。
【０１２６】
以上の各実施形態で説明した各構成要素は、必ずしも個々に独立した存在である必要はなく、複数の構成要素が１個のモジュールとして実現されたり、一つの構成要素が複数のモジュールで実現されたり、ある構成要素が他の構成要素の一部であったり、ある構成要素の一部と他の構成要素の一部とが重複していたり、といったような構成であってもよい。
【０１２７】
また、以上説明した各実施形態では、複数の動作をフローチャートの形式で順番に記載してあるが、その記載の順番は複数の動作を実行する順番を限定するものではない。このため、各実施形態を実施するときには、その複数の動作の順番は内容的に支障しない範囲で変更することができる。
【０１２８】
更に、以上説明した各実施形態では、複数の動作は個々に相違するタイミングで実行されることに限定されない。例えば、ある動作の実行中に他の動作が発生したり、ある動作の実行タイミングと他の動作の実行タイミングとの一部乃至全部が重複していたりしていてもよい。
【０１２９】
更に、以上説明した各実施形態では、ある動作が他の動作の契機になるように記載しているが、その記載はある動作と他の動作のすべての関係を限定するものではない。このため、各実施形態を実施するときには、その複数の動作の関係は内容的に支障しない範囲で変更することができる。また各構成要素の各動作の具体的な記載は、各構成要素の各動作を限定するものではない。このため、各構成要素の具体的な各動作は、各実施形態を実施する上で機能的、性能的、その他の特性に対して支障をきたさない範囲内で変更されて良い。
【０１３０】
尚、以上説明した各実施形態における各構成要素は、必要に応じ可能であれば、ハードウェアで実現されても良いし、ソフトウェアで実現されても良いし、ハードウェアとソフトウェアの混在により実現されても良い。
【０１３１】
また、各構成要素の物理的な構成は、以上の実施形態の記載に限定されることはなく、独立して存在しても良いし、組み合わされて存在しても良いしまたは分離して構成されても良い。例えば、購読端末、仲介端末および配信端末の各手段の機能の内の、複数の機能が１台の物理的な端末に同居してもよいし、一つの機能が分離して複数の端末に実装されてもよい。
【産業上の利用可能性】
【０１３２】
本発明は、インターネットや次世代通信網（ＮＧＮ（Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ Ｎｅｔｗｏｒｋ））を通じて携帯電話機などの通信端末間で行われるセッションシステムにおいて、セッションサービス提供時に可否判定を行うシステム、装置および方法に適用することができる。
【０１３３】
即ち、本発明は上述のようなシステム、装置および方法において、例えば、主体が３ＰＣＣサービスにサービス提供要求を送信したものの実際はサービス提供に要する主対組情報に対する可否判定の１つが拒否になっており、サービス提供要求が拒否されてしまって結局は無駄になってしまうサービス提供要求を送信することを未然に防止する機能を提供することができる。
【０１３４】
また、本発明は、特定の主対組に対する可否判定を、サービス提供の可否判定に反映することができる。このため、サービス提供者とサービス利用者間でサービス提供をしてもよいという合意があるにもかかわらず、主対組に対する可否判定の１つが拒否になっているためにサービス提供要求が拒否されてしまうというようなことを防ぐ機能を提供することができる。
【０１３５】
更にまた、本発明は、サービス提供者あるいはサービス利用者である主体が、対象までのサービス提供の可否判定の対象となる主対組、主対組の主体あるいは対象について把握していないものがある場合でも、サービス提供の可否をサービス提供前に問い合わせることを可能にする機能を提供することができる。
【０１３６】
更にまた、本発明は、サービス提供の可否判定の対象となる主対組の素性（例えば、サービス提供者あるいはサービス利用者が指定した場合、実施形態のサービス提供可否判定装置が指定した場合など）によって可否判定を変更する機能を提供することができる。
【符号の説明】
【０１３７】
１００ サービス提供可否判定装置
１１０ 第１判定部
１１１ 第２可否判定要求
１２０ 第２判定部
１４０ 応答部
１６０ 第１可否設定記憶部
１６１ 第１可否設定
１６２ 第１可否判定結果
１７０ 第２可否設定記憶部
１７１ 第２可否設定
１７２ 第２可否判定結果
２００ サービス提供可否判定装置
２３０ 主対組更新部
２３１ 更新後サービス提供可否判定要求
２４０ 応答部
２８０ 主対組設定記憶部
２８１ 主対組設定
２８２ 付加主対組情報
３１０ 第１判定部
３１１ 第２可否判定要求
３２０ 第２判定部
３３０ 主対組更新部
３３１ 更新後サービス提供可否判定要求
３６０ 第１可否設定記憶部
３６１ 第１可否設定
３６２ 第１可否判定結果
３６３ 付加主対組フラグ
３７０ 第２可否設定記憶部
３７１ 第２可否設定
３７２ 第２可否判定結果
４００ サービス提供可否判定装置
４１０ 第１判定手段
４２０ 第２判定手段
９１０ ネットワーク
９２０ 通信端末
９２１ サービス提供可否判定要求
９２２ 主対組情報
９２３ 主体ノード階層種別
９２４ 主体ノード属性値
９２５ 対象ノード階層種別
９２６ 対象ノード属性値
【技術分野】
【０００１】
本発明は、判定装置、判定方法およびプログラムに関し、特にアクセス可否を判定する判定装置、判定方法およびプログラムに関する。
【背景技術】
【０００２】
近年、複数の処理要素が連携処理を行うサービスが広まっている。更に、サービス提供に対する可否判定が必要とされている。
【０００３】
例えば、非特許文献２は、ユーザがウェブサービスに対して要求することで、通信キャリア網越しのキャリア端末との通話を可能にするような３ＰＣＣ（３ｒｄ Ｐａｒｔｙ
Ｃａｌｌ Ｃｏｎｔｒｏｌ）サービスが提供されている。また、非特許文献３は、３ＰＣＣサービスにおけるＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）の使用方法について記載している。
【０００４】
このようなサービス提供の"可否を判定する"システムにおいては、１つ以上の処理要素を考慮する必要がある。処理要素には処理の主体と対象の組(以降、主対組)が存在する。例えば、３ＰＣＣサービスでは、主体としてウェブサービスと対象としてキャリア端末とからなる主対組と、主体としてユーザ端末と対象としてウェブサービスとからなる主対組との２つの主対組を要する。
【０００５】
一方、ネットワークなどを利用したサービスにおいて、不正なアクセス元からのアクセスを防ぐための技術が各種提案されている。
【０００６】
例えば、非特許文献１には、アクセス制御ポリシの書式仕様であるＸＡＣＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）が、記載されている。このＸＡＣＭＬは、アクセス主体とアクセス対象との組み合わせに対するアクセス可否を示すためのアクセス制御ポリシを記述することを可能にするものである。
【０００７】
また、例えば、アクセス制御の技術が特許文献１に記載されている。特許文献１記載の技術は、グループメンバすべてに設定されたアクセスポリシに対して、各グループのメンバ間のポリシに基づいて変換した結果を上書きすることにより、ポリシの正規化による管理コスト削減と適切なポリシカスタマイズとの両立を可能とする技術である。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２００３−３１６７４５号公報
【非特許文献】
【０００９】
【非特許文献１】ｏａｓｉｓ−ａｃｃｅｓｓ＿ｃｏｎｔｒｏｌ−ｘａｃｍｌ−２．０−ｃｏｒｅ−ｓｐｅｃ−ｏｓ http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-core-spec-os.pdf
【非特許文献２】ＥＴＳＩ ＥＳ ２０２ ３９１−２ Ｏｐｅｎ Ｓｅｒｖｉｃｅ Ａｃｃｅｓｓ （ＯＳＡ）； Ｐａｒｌａｙ Ｘ ＷｅｂＳｅｒｖｉｃｅｓ； Ｐａｒｔ２： Ｔｈｉｒｄ Ｐａｒｔｙ Ｃａｌｌ http://www.parlay.org/imwp/download.asp?ContentID=9594
【非特許文献３】ＢＣＰ ８５， ＲＦＣ ３７２５ Ｂｅｓｔ Ｃｕｒｒｅｎｔ Ｐｒａｃｔｉｃｅｓ ｆｏｒ Ｔｈｉｒｄ Ｐａｒｔｙ Ｃａｌｌ Ｃｏｎｔｒｏｌ （３ｐｃｃ） ｉｎ ｔｈｅ Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ （ＳＩＰ） http://www.ietf.org/rfc/rfc3725.txt
【発明の概要】
【発明が解決しようとする課題】
【００１０】
しかしながら、上記のサービス提供をサービス利用者からサービス提供者へのアクセスと捉えた場合、ＸＡＣＭＬは、アクセス制御ポリシに必要な汎用データモデルと、ポリシ形式を定めたものであり、３ＰＣＣなどの複数の処理要素が連携処理を行う技術分野への応用は開示されていない。
【００１１】
また、特許文献１記載の技術は、１つの主対組のみをアクセス制御の対象としており、例えば、グループ間のポリシとメンバ間のポリシに対する可否判定を総合的に捕らえてアクセス制御を行うことはできない。
【００１２】
従って、サービス提供者とサービス利用者との間が多対多のアクセスによるサービス提供を実現する場合、このようなサービス提供の可否を事前に判定することは困難であるという問題があった。つまり、サービス利用者がサービス提供の可否を事前に知ることは困難であり、例えば主体が３ＰＣＣサービスにサービス提供要求を送信したものの、実際はサービス提供に要する複数の主対組の内の少なくとも１つの主対組の可否判定が拒否になっているために、サービス提供要求が拒否されてしまい、結局は無駄になってしまうサービス提供要求を送信してしまうことを防ぐことができなかった。
【００１３】
本発明の目的は、上述した問題を解決する判定装置、判定方法およびプログラムを提供することにある。
【課題を解決するための手段】
【００１４】
本発明の判定装置は、ノード階層種別とノード属性値とをそれぞれ含む第１ノード情報および第２ノード情報からなるノード組情報を少なくとも２つ以上含む判定要求について、
予め定められた第１可否設定に基づいて、前記ノード組情報で指定されたノード組毎の第１アクセス可否判定結果を取得する第１可否判定手段と、
予め定められた第２可否設定に基づいて、前記第１アクセス可否判定結果と前記ノード組の第１ノード情報の前記ノード階層種別および第２ノード情報の前記ノード階層種別との組の組み合わせについて第２アクセス可否判定結果を取得する第２可否判定手段とを有する。
【００１５】
本発明の判定方法は、ノード階層種別とノード属性値とをそれぞれ含む第１ノード情報および第２ノード情報からなるノード組情報を少なくとも２つ以上含む判定要求について、
予め定められた第１可否設定に基づいて、前記ノード組情報で指定されたノード組毎の第１アクセス可否判定結果を取得し、
予め定められた第２可否設定に基づいて、前記第１アクセス可否判定結果と前記ノード組の第１ノード情報の前記ノード階層種別および第２ノード情報の前記ノード階層種別との組の組み合わせについて第２のアクセス可否を判定する。
【００１６】
本発明のプログラムは、ノード階層種別とノード属性値とをそれぞれ含む第１ノード情報および第２ノード情報からなるノード組情報を少なくとも２つ以上含む判定要求について、
予め定められた第１可否設定に基づいて、前記ノード組情報で指定されたノード組毎の第１のアクセス可否を判定し、
予め定められた第２可否設定に基づいて、前記第１アクセス可否判定結果と前記ノード組の第１ノード情報の前記ノード階層種別および第２ノード情報の前記ノード階層種別との組の組み合わせについて第２のアクセス可否を判定する処理をコンピュータに実行させる。
【発明の効果】
【００１７】
本発明によれば、サービス提供者とサービス利用者との間のサービス提供が多対多のアクセスによるものであってもサービス提供の可否を事前に判定することができる。
【図面の簡単な説明】
【００１８】
【図１】本発明の第１の実施形態の構成を示すブロック図である。
【図２】本発明の第１乃至４の実施形態におけるサービス提供可否判定要求の構造を示す図である。
【図３】本発明の第１および第４の実施形態における第１可否設定の構造を示す図である。
【図４】本発明の第１および第４の実施形態における第２可否設定の構造を示す図である。
【図５】本発明の第１の実施形態の全体の動作を示すシーケンス図である。
【図６】本発明の第１の実施形態におけるサービス提供可否判定要求の例を示す図である。
【図７】本発明の第１の実施形態における第２可否判定要求の構造と例とを示す図である。
【図８】本発明の第１の実施形態の第１判定部の動作を示すフローチャートである。
【図９】本発明の第１の実施形態の第２判定部の動作を示すフローチャートである。
【図１０】本発明の第２の実施形態の構成を示すブロック図である。
【図１１】本発明の第２および第３の実施形態における主対組設定の構造と例とを示す図である。
【図１２】本発明の第２の実施形態の全体の動作を示すシーケンス図である。
【図１３】本発明の第２の実施形態におけるサービス提供可否判定要求の例を示す図である。
【図１４】本発明の第２の実施形態における更新後サービス提供可否判定要求の構造と例とを示す図である。
【図１５】本発明の第３の実施形態の構成を示すブロック図である。
【図１６】本発明の第３の実施形態における更新後サービス提供可否判定要求の構造と例とを示す図である。
【図１７】本発明の第３の実施形態における第１可否設定の構造を示す図である。
【図１８】本発明の第３の実施形態における第２可否設定の構造を示す図である。
【図１９】本発明の第３の実施形態における第２可否判定要求の構造と例とを示す図である。
【図２０】本発明の第３の実施形態の全体の動作を示すシーケンス図である。
【図２１】本発明の第３の実施形態における更新後サービス提供可否判定要求の例を示す図である。
【図２２】本発明の第３の実施形態における更新後サービス提供可否判定要求の例を示す図である。
【図２３】本発明の第３の実施形態における第２可否判定要求の例を示す図である。
【図２４】本発明の第３の実施形態の第１判定部の動作を示すフローチャートである。
【図２５】本発明の第３の実施形態の第２判定部の動作を示すフローチャートである。
【図２６】本発明の第４の実施形態の構成を示すブロック図である。
【発明を実施するための形態】
【００１９】
次に、本発明の第１の実施形態について図面を参照して詳細に説明する。
【００２０】
まず、サービス提供者とサービス利用者間のサービスの提供について説明する。
【００２１】
このサービスは、少なくとも２つの終端ノードと任意の数の中継ノードを介して提供される。終端ノードおよび中継ノードのいずれか１つを主体ノード（一般的に、第１ノードとも呼ばれる）とし、他のいずれか１つを対象ノード（一般的に、第２ノードとも呼ばれる）とし、主体ノードと対象ノードの組を主対組（一般的に、ノード組とも呼ばれる）とすると、上記のサービスは少なくとも１つの主対組を含む。
【００２２】
終端ノードおよび中継ノードは、サービス提供者とサービス利用者間のサービス提供に要する主対組を識別するノード階層種別およびノード属性値をそれぞれ有している。
【００２３】
ノード階層種別とは、「加入者」、「端末」、「ＷＰＡＮ（Ｗｉｒｅｌｅｓｓ Ｐｅｒｓｏｎａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）端末」および「ウェブサービス」などの主体ノードおよび対象ノードの階層的な種別を示すものである。
【００２４】
ノード属性値とは、主体ノードおよび対象ノードを一意に識別する識別子、もしくは主体ノードのまとまりおよび対象ノードのまとまりを識別する代表識別子（例えば、正規表現を用いて示される識別子）である。ノード階層種別およびノード属性値は、例えばサービス提供に用いるＳＩＰリクエスト内のＦｒｏｍヘッダや、ＳＩＰ ＩＮＶＩＴＥリクエスト内ＳＤＰ（ＳＥＳＳＩＯＮ ＤＥＳＣＲＩＰＴＩＯＮ
ＰＲＯＴＯＣＯＬ）のｃ行、ＳＯＡＰ（ＳＩＭＰＬＥ ＯＢＪＥＣＴ ＡＣＣＥＳＳ ＰＲＯＴＯＣＯＬ）リクエスト内ネームスペースなどから形成される。
【００２５】
図１は、本発明の第１の実施形態の構成を示すブロック図である。
【００２６】
図１を参照すると、本発明の第１の実施形態は、サービス提供可否（一般的にアクセス可否とも呼ばれる）判定装置（一般的に判定装置とも呼ばれる）１００、通信端末９２０およびネットワーク９１０から構成されている。
【００２７】
通信端末９２０は、通信機能を有する情報処理機器であり、例えば携帯電話機、ＰＤＡあるいはパーソナルコンピュータ等であってよい。
【００２８】
通信端末９２０は、サービス提供者とサービス利用者間のサービス提供に関わるノードの階層種別やノードの属性値を予め取得し、例えば図２に示すようなサービス提供可否判定要求（一般的に判定要求とも呼ばれる）９２１をサービス提供可否判定装置１００へ送信する。
【００２９】
図２に示すサービス提供可否判定要求９２１は、主体ノード階層種別９２３および主体ノード属性値９２４（主体ノード階層種別９２３および主体ノード属性値９２４は、まとめて一般的に第１ノード情報とも呼ばれる）と対象ノード階層種別９２５および対象ノード属性値９２６（対象ノード階層種別９２５および対象ノード属性値９２６は、まとめて一般的に第２ノード情報とも呼ばれる）とを含む主対組（ノード組とも呼ばれる）情報（ノード組情報とも呼ばれる）９２２を少なくとも１つ含む。尚、主体ノード階層種別９２３および対象ノード階層種別９２５は、主体ノードおよび対象ノードの階層的な種別を示す情報である。主体ノード属性値９２４および対象ノード属性値９２６は、ノードを個別に識別する情報である。
【００３０】
サービス提供可否判定装置１００は、第１可否設定記憶部１６０と第２可否設定記憶部１７０と応答部１４０と第１判定部１１０と第２判定部１２０とを含む。
【００３１】
第１可否設定記憶部１６０は、主対組情報９２２と、この主対組情報９２２で特定される主対組におけるサービス提供の可否を判定する第１可否判定結果（第１アクセス可否判定結果とも呼ばれる）１６２とを含む第１可否設定１６１を記憶する。第１可否設定記憶部１６０に記憶されている第１可否設定１６１の構造を図３に示す。
【００３２】
尚、サービス提供に対する可否判定に用いる第１可否設定１６１の範囲は、以下の（ａ）、（ｂ）の２つの場合が考えられる。（ａ）サービス提供に対する可否判定に必要最低限の主対組に対応する可否設定とする場合。（ｂ）サービス提供に対する可否判定に関連するすべての主対組に対応する可否設定とする場合。（ａ）、（ｂ）のいずれを採用するかは、例えばシステム設定によって定めることができる。本実施形態では、システム設定により（ａ）が定められているものとして、説明する。
【００３３】
第２可否設定記憶部１７０は、例えば図４に示すように１つ以上の第２可否設定１７１を記憶する。第２可否設定１７１は、主対組情報９２２に含まれる主体ノード階層種別９２３および対象ノード階層種別９２５とこの主対組情報９２２に対する第１可否判定結果１６２との組の組み合わせに対応する第２可否判定結果（第２アクセス可否判定結果とも呼ばれる）１７２とからなる。即ち、第２可否設定１７１には、特定の主対組の組み合わせにおいてのサービス提供に対する可否判定が設定されている。
第２可否設定記憶部１７０に記憶されている第２可否設定１７１の構造を図４に示す。
【００３４】
応答部１４０は、通信端末９２０からサービス提供可否判定要求９２１を受信し、第１判定部１１０へ送信する。また、応答部１４０は、第２判定部１２０から第２可否判定結果１７２を受信し、受信した第２可否判定結果１７２に基づいてサービス提供可否判定要求９２１への応答を通信端末９２０へ送信する。
【００３５】
第１判定部１１０は、第１可否設定記憶部１６０に記憶された第１可否設定１６１を参照して、サービス提供可否判定要求９２１に含まれる各主対組情報９２２に対する第１可否判定結果１６２を取得し、サービス提供可否判定要求９２１と取得した第１可否判定結果１６２とに基づいて図７に示すような第２可否判定要求１１１を生成し、第２判定部１２０へ送信する。
【００３６】
第２判定部１２０は、第２可否設定記憶部１７０に記憶された第２可否設定１７１を参照して、サービス提供可否判定要求９２１に含まれる各主対組情報９２２の主体ノード階層種別９２３および対象ノード階層種別９２５とこの主対組情報９２２に対応する第１可否判定結果１６２との組みの組み合わせに対する第２可否判定結果１７２を取得し、この取得した第２可否判定結果１７２を応答部１４０へ送信する。
【００３７】
次に本実施形態の動作について図１〜図９を参照して詳細に説明する。
【００３８】
以下では、通信端末９２０がサービス提供（例えばＳＯＡＰリクエストを３ＰＣＣウェブサービスに送信する）試行前にサービス提供可否判定要求９２１をサービス提供可否判定装置１００へ送信し、これに応答してサービス提供可否判定装置１００が第２可否判定結果１７２を通信端末９２０へ送信する動作を例にして説明する。
【００３９】
前提として、通信端末９２０の利用者をＡ、Ａがサービス提供したい通信端末（図示しない）の利用者をＢとする。また、サービス提供に要するある１つの主対組情報９２２の主体ノード階層種別９２３を“端末”、主体ノード属性値９２４を“sip:terminal1@example.com”、対象ノード階層種別９２５を“端末”、対象ノード属性値９２６を“sip:terminal2@example.com”とし、この主対組情報９２２に対応する第１可否判定結果１６２は“許可”であるものとする。更に、サービス提供に要する他の１つの主対組情報９２２の主体ノード階層種別９２３を“ウェブサービス”、主体ノード属性値９２４を“ws1@example.com”、対象ノード階層種別９２５を“端末”、対象ノード属性値９２６を“sip:terminal2@example.com”とし、この主対組情報９２２に対応する第１可否判定結果１６２は“拒否”であるものとする。
【００４０】
図５は、本実施形態における全体の動作を示すシーケンス図である。
【００４１】
利用者Ａが通信端末９２０上でサービス提供したい利用者Ｂへのサービス提供操作を行うと、通信端末９２０は、ネットワーク９１０を経由してサービス提供可否判定装置１００に対して例えば図６に示すようなサービス提供可否判定要求９２１を送信する（ステップＳ５１０）。
【００４２】
このサービス提供可否判定要求９２１には、主体ノード階層種別９２３と主体ノード属性値９２４と対象ノード階層種別９２５と対象ノード属性値９２６とを含む主対組情報９２２が２つ含まれている。１つめの主対組情報９２２の主体ノード階層種別９２３は“端末”、主体ノード属性値９２４は“sip:terminal1@example.com”、対象ノード階層種別９２５は“端末”、対象ノード属性値９２６は“sip:terminal2@example.com”、２つめの主対組情報９２２の主体ノード階層種別９２３は“ウェブサービス”、主体ノード属性値９２４は“ws1@example.com”、対象ノード階層種別９２５は“端末”、対象ノード属性値９２６は“sip:terminal2@example.com”である。
【００４３】
次に、応答部１４０は、サービス提供可否判定要求９２１を第１判定部１１０に送信する（ステップＳ５１２）。
【００４４】
次に、第１判定部１１０は、例えば図３に示すような第１可否設定記憶部１６０の第１可否設定１６１を検索し、サービス提供可否判定要求９２１に含まれる１つ目の主対組情報９２２（主体ノード階層種別９２３“端末”、主体ノード属性値９２４“sip:terminal1@example.com”、対象ノード階層種別９２５“端末”、対象ノード属性値９２６“sip:terminal2@example.com”）に対する第１可否判定結果１６２“許可”を取得する。同様に、第１判定部１１０は、２つ目の主対組情報９２２（主体ノード階層種別９２３“ウェブサービス”、主体ノード属性値９２４“ws1@example.com”、対象ノード階層種別９２５“端末”、対象ノード属性値９２６“sip:terminal2@example.com”）に対する第１可否判定結果１６２“拒否”を取得する。
【００４５】
続けて、第１判定部１１０は、サービス提供可否判定要求９２１とこれに含まれる主対組情報９２２それぞれに対応する第１可否判定結果１６２とに基づいて図７に示すような第２可否判定要求１１１を生成し、第２判定部１２０に送信する（ステップＳ５１４）。
【００４６】
次に、第２判定部１２０は、例えば図４に示すような第２可否設定記憶部１７０の第２可否設定１７１を検索し、サービス提供可否判定要求９２１に含まれる１つ目の主対組情報９２２の主体ノード階層種別９２３“端末”、対象ノード階層種別９２５“端末”およびこの主対組情報９２２に対する第１可否判定結果１６２“許可”の組と、２つ目の主対組情報９２２の主体ノード階層種別９２３“ウェブサービス”、対象ノード階層種別９２５“端末”およびこの主対組情報９２２に対する第１可否判定結果１６２“拒否”の組との組み合わせに対する第２可否判定結果１７２“許可”を取得する。
【００４７】
続けて、第２判定部１２０は、第２可否判定結果１７２を応答部１４０に送信する（ステップＳ５１６）。
【００４８】
次に、応答部１４０は、サービス提供可否判定要求９２１に対するサービス提供可否判定結果として、第２可否判定結果１７２に基づいた応答をネットワーク９１０経由で通信端末９２０に送信する（ステップＳ５１８）。
【００４９】
図８は、図５のステップＳ５１４における第１判定部１１０の動作を示すフローチャートである。
【００５０】
まず、第１判定部１１０は、第１可否設定記憶部１６０を参照し、サービス提供可否判定要求９２１に含まれる主対組情報９２２に対応する第１可否設定１６１を検索する（ステップＳ１４１）。
【００５１】
続けて、第１判定部１１０は、検索した第１可否設定１６１から第１可否判定結果１６２を取得する（ステップＳ１４２）。
【００５２】
次に、第１判定部１１０は、サービス提供可否判定要求９２１に含まれる主対組情報９２２のすべてについてステップＳ１４１を実行したか否かを判定する（ステップＳ１４３）。そして、未実行の主対組情報９２２がある場合（ステップＳ１４３でＮＯ）、処理はステップＳ１４１へ進む。また、すべて実行済の場合（ステップＳ１４３でＹＥＳ）、処理はステップＳ１４６へ進む。
【００５３】
次に、第１判定部１１０は、サービス提供可否判定要求９２１とこれに含まれる主対組情報９２２それぞれに対応する第１可否判定結果１６２とに基づいて図７に示すような第２可否判定要求１１１を生成し、第２判定部１２０へ送信する（ステップＳ１４６）。
【００５４】
図９は、図５のステップＳ５１６における第２判定部１２０の動作を示すフローチャートである。
【００５５】
まず、第２判定部１２０は、第２可否設定記憶部１７０を参照し、サービス提供可否判定要求９２１に含まれる各主対組情報９２２の主体ノード階層種別９２３および対象ノード階層種別９２５とこの主対組情報９２２に対する第１可否判定結果１６２との組の組み合わせに対応する第２可否設定１７１を検索する（ステップＳ１６１）。
【００５６】
続けて、第２判定部１２０は、検索した第２可否設定１７１から第２可否判定結果１７２を取得する（ステップＳ１６２）。
【００５７】
次に、第２判定部１２０は、第２可否判定結果１７２を応答部１４０に送信する（ステップＳ１６４）。
【００５８】
上述した本実施形態における第１の効果は、サービス提供者とサービス利用者との間のサービス提供が多対多のアクセスによるものであってもサービス提供の可否を事前に判定することを可能にできる点である。
【００５９】
その理由は、第１判定部１１０が第１可否判定結果１６２を取得し、各主対組におけるサービス提供可否を判定し、第１可否判定結果１６２を利用して第２判定部１２０が第２可否判定結果１７２を取得し、主対組の組み合わせ全体におけるサービス提供可否を判定するようにしたからである。
【００６０】
上述した本実施形態における第２の効果は、特定の主対組情報９２２に対する可否を判定サービス提供の可否判定に反映することを可能にできる点である。
【００６１】
その理由は、第２可否判定結果が主対組情報９２２に含まれる主体ノード階層種別９２３と対象ノード階層種別９２５とこの主対組情報９２２に対する第１可否判定結果１６２との組の組み合わせに対してサービス提供可否を示すものであるようにしたからである。
【００６２】
次に本発明の第２の実施形態について図面を参照して説明する。
【００６３】
図１０は、本発明の第２の実施形態の構成を示すブロック図である。図１０を参照すると、本発明の第２の実施形態は、図１に示した第１の実施形態と比較して、サービス提供可否判定装置２００内に新たに主対組設定記憶部２８０と主対組更新部２３０とを備えている点、応答部１４０に代えて応答部２４０を備えている点で相違している。
【００６４】
応答部２４０は、通信端末９２０からサービス提供可否判定要求９２１を受信し、これを主対組更新部２３０へ送信する。また、応答部２４０は、主対組更新部２３０から図１４に示すような更新後サービス提供可否判定要求２３１を受信し、第１判定部１１０へ送信する。更に、応答部２４０は、第２判定部１２０から第２可否判定結果１７２を受信し、受信した第２可否判定結果１７２に基づいてサービス提供可否判定要求９２１への応答を通信端末９２０へ送信する。
【００６５】
図１４に示す更新後サービス提供可否判定要求２３１はサービス提供可否判定要求９２１と同様の構造を有するが、サービス提供可否判定要求９２１と異なる点として、更新後サービス提供可否判定要求２３１に含まれる主対組情報９２２の１つ以上が、後述する主対組更新部２３０によって追加された付加主対組情報２８２であることを含む。
【００６６】
主対組設定記憶部２８０は、例えば図１１に示すように、主体ノード階層種別９２３、主体ノード属性値９２４、対象ノード階層種別９２５および対象ノード属性値９２６を含む付加主対組情報（付加ノード組情報とも呼ばれる）２８２を主対組情報９２２に対応付けた主対組設定２８１を記憶する。付加主対組情報２８２は、特定のサービス提供に対する可否判定に必要な所定の主対組情報９２２であってよい。
【００６７】
主対組更新部２３０は、主対組設定記憶部２８０の主対組設定２８１を参照してサービス提供可否判定要求９２１に含まれる主対組情報９２２に対応する付加主対組情報２８２を取得し、これをサービス提供可否判定要求９２１に追加し、図１４に示すような更新後サービス提供可否判定要求２３１を応答部２４０へ送信する。
【００６８】
次に本実施形態の動作について図１０〜図１４を参照して詳細に説明する。
【００６９】
説明する動作の例および前提は、第１の実施形態と同様である。
【００７０】
図１２は、本実施形態における全体の動作を示すシーケンス図である。
【００７１】
利用者Ａが通信端末９２０上でサービス提供したい利用者Ｂへのサービス提供操作を行うと、通信端末９２０は、ネットワーク９１０を経由して、サービス提供可否判定装置２００の応答部２４０に対して例えば図１３に示すようなサービス提供可否判定要求９２１を送信する（ステップＳ５２０）。
【００７２】
このサービス提供可否判定要求９２１には、主体ノード階層種別９２３と主体ノード属性値９２４と対象ノード階層種別９２５と対象ノード属性値９２６とを含む主対組情報９２２が含まれている。主体ノード階層種別９２３は“端末”、主体ノード属性値９２４は“sip:terminal1@example.com”、対象ノード階層種別９２５は“端末” 対象ノード属性値９２６は“sip:terminal2@example.com”である。
【００７３】
次に、応答部２４０は、サービス提供可否判定要求９２１を主対組更新部２３０に送信する（ステップＳ５２２）。
【００７４】
次に、主対組更新部２３０は、例えば図７に示すような主対組設定記憶部２８０の主対組設定２８１を検索し、サービス提供可否判定要求９２１に含まれる主対組情報９２２（主体ノード階層種別９２３“端末”、主体ノード属性値９２４“sip:terminal1@example.com”、対象ノード階層種別９２５“端末”、対象ノード属性値９２６“sip:terminal2@example.com”）に対する付加主対組情報２８２（主体ノード階層種別９２３“ウェブサービス”、主体ノード属性値９２４“ws1@example.com”、対象ノード階層種別９２５“端末”、対象ノード属性値９２６“sip:terminal2@example.com”）を取得する。そして、取得した付加主対組情報２８２を主対組情報９２２としてサービス提供可否判定要求９２１に追加し、図１４に示すような更新後サービス提供可否判定要求２３１を応答部２４０へ送信する（ステップＳ５２４）。
【００７５】
次に、応答部２４０は、更新後サービス提供可否判定要求２３１を第１判定部１１０に送信する（ステップＳ５２６）。
【００７６】
以後の動作は、サービス提供可否判定要求９２１が更新後サービス提供可否判定要求２３１に、および応答部１４０が応答部２４０に変わっていることを除いて第１の実施形態のステップＳ５１４〜ステップＳ５１８における動作と同様であるので説明を省略する。
【００７７】
上述した本実施形態における効果は、第１の実施形態と同様の効果を有することに加えて、サービス提供者あるいはサービス利用者は、サービス提供に要するノードの内の一部を把握していない場合であっても、サービス提供の可否を事前に判定することを可能にできる点である。
【００７８】
その理由は、主対組更新部２３０がサービス提供可否判定要求９２１に特定のサービス提供に対する可否判定に必要な主対組情報９２２を追加するようにしたからである。
【００７９】
次に本発明の第３の実施形態について図面を参照して説明する。
【００８０】
図１５は、本発明の第３の実施形態の構成を示すブロック図である。図１５を参照すると、本発明の第３の実施形態は、図１０に示した第２の実施形態と比較して、主対組更新部２３０に代えて主対組更新部３３０を、第１可否設定記憶部１６０に代えて第１可否設定記憶部３６０を、第２可否設定記憶部１７０に代えて第２可否設定記憶部３７０を、第１判定部１１０に代えて第１判定部３１０を、第２判定部１２０に代えて第２判定部３２０を備えている点で相違している。
【００８１】
主対組更新部３３０は、主対組設定記憶部２８０の主対組設定２８１を参照してサービス提供可否判定要求９２１に含まれる主対組情報９２２に対応する付加主対組情報２８２を取得し、取得した付加主対組情報２８２および付加主対組フラグ（付加ノード組フラグとも呼ばれる）３６３“真”をサービス提供可否判定要求９２１に追加し、図１６に示すような更新後サービス提供可否判定要求３３１を応答部２４０へ送信する。
【００８２】
第１可否設定記憶部３６０は、例えば図１７に示すように主対組情報９２２および付加主対組フラグ３６３とこれらに対応する第１可否判定結果３６２とからなる第１可否設定３６１を記憶する。
【００８３】
第２可否設定記憶部３７０は、例えば図１８に示すように１つ以上の第２可否設定３７１を記憶する。第２可否設定３７１は、主対組情報９２２に含まれる主体ノード階層種別９２３および対象ノード階層種別９２５とこの主対組情報９２２に対する付加主対組フラグ３６３および第１可否判定結果３６２との組の組み合わせに対応する第２可否判定結果３７２とからなる。
【００８４】
第１判定部３１０は、第１可否設定記憶部３６０に記憶された第１可否設定３６１を参照して、サービス提供可否判定要求９２１に含まれる各主対組情報９２２および付加主対組フラグ３６３の組に対する第１可否判定結果３６２を取得し、サービス提供可否判定要求９２１と取得した第１可否判定結果３６２とに基づいて図１９に示すような第２可否判定要求３１１を生成し、第２判定部３２０へ送信する。
【００８５】
第２判定部３２０は、第２可否設定記憶部３７０に記憶された第２可否設定３７１を参照して、サービス提供可否判定要求９２１に含まれる各主対組情報９２２の主体ノード階層種別９２３および対象ノード階層種別９２５とこの主対組情報９２２に対応する付加主対組フラグ３６３および第１可否判定結果３６２との組みの組み合わせに対する第１可否判定結果３７２を取得し、この取得した第２可否判定結果３７２を応答部２４０へ送信する。
【００８６】
次に本実施形態の動作について図１１、図１５〜図２５を参照して詳細に説明する。
【００８７】
説明する動作の例および前提は、第２の実施形態と同様である。
【００８８】
図２０は、本実施形態における全体の動作を示すシーケンス図である。
【００８９】
ステップＳ５１０における動作は、第２の実施形態と同様であるので説明を省略する。
【００９０】
次に、応答部２４０は、サービス提供可否判定要求９２１を主対組更新部３３０に送信する（ステップＳ５３８）。
【００９１】
次に、主対組更新部２３０は、図１１に示すような主対組設定記憶部２８０の主対組設定２８１を検索し、サービス提供可否判定要求９２１に含まれる主対組情報９２２（主体ノード階層種別９２３“端末”、主体ノード属性値９２４“sip:terminal1@example.com”、対象ノード階層種別９２５“端末”、対象ノード属性値９２６“sip:terminal2@example.com”）に対する付加主対組情報２８２（主体ノード階層種別９２３“ウェブサービス”、主体ノード属性値９２４“ws1@example.com”、対象ノード階層種別９２５“端末”、対象ノード属性値９２６“sip:terminal2@example.com”）を取得する。続けて、主対組更新部２３０は、取得した付加主対組情報２８２を主対組情報９２２としてサービス提供可否判定要求９２１に追加する。更に、主対組更新部２３０は、この追加した主対組情報９２２に対する付加主対組フラグ３６３“真”を、サービス提供可否判定要求９２１に追加し、図１６に示すような更新後サービス提供可否判定要求３３１を応答部２４０へ送信する（ステップＳ５４０）。
【００９２】
次に、応答部２４０は、更新後サービス提供可否判定要求３３１を第１判定部３１０に送信する（ステップＳ５４２）。
【００９３】
次に、第１判定部３１０は、例えば図１７に示すような第１可否設定記憶部３６０の第１可否設定３６１を検索し、サービス提供可否判定要求９２１に含まれる１つ目の主対組情報９２２（主体ノード階層種別９２３“端末”、主体ノード属性値９２４“sip:terminal1@example.com”、対象ノード階層種別９２５“端末”、対象ノード属性値９２６“sip:terminal2@example.com”）と付加主対組フラグ３６３“真”が付加されていないこととに対する第１可否判定結果３６２“許可”を取得する。同様に、第１判定部１１０は、２つ目の主対組情報９２２（主体ノード階層種別９２３“ウェブサービス”、主体ノード属性値９２４“ws1@example.com”、対象ノード階層種別９２５“端末”、対象ノード属性値９２６“sip:terminal2@example.com”）と付加主対組フラグ３６３“真”が付加されていないこととに対する第１可否判定結果３６２“拒否”を取得する。更に同様に、第１判定部１１０は、３つ目の主対組情報９２２（主体ノード階層種別９２３“ウェブサービス”、主体ノード属性値９２４“ws1@example.com”、対象ノード階層種別９２５“端末”、対象ノード属性値９２６“sip:terminal2@example.com”）と付加主対組フラグ３６３“真”が付加されていることとに対する第１可否判定結果３６２“許可”を取得する。
【００９４】
続けて、第１判定部３１０は、サービス提供可否判定要求９２１とこれに含まれる主対組情報９２２それぞれに対応する第１可否判定結果３６２とに基づいて図１９に示すような第２可否判定要求３１１を生成し、第２判定部３２０へ送信する（ステップＳ５４４）。
【００９５】
次に、第２判定部３２０は、例えば図１８に示すような第２可否設定記憶部３７０の第２可否設定３７１を検索し、サービス提供可否判定要求９２１に含まれる１つ目の主対組情報９２２の主体ノード階層種別９２３“端末”、対象ノード階層種別９２５“端末”、付加主対組フラグ３６３“真”が付加されていないことおよびこの主対組情報９２２に対する第１可否判定結果１６２“許可”の組と、２つ目の主対組情報９２２の主体ノード階層種別９２３“ウェブサービス”、対象ノード階層種別９２５“端末”、付加主対組フラグ３６３“真”が付加されていないことおよびこの主対組情報９２２に対する第１可否判定結果１６２“拒否”の組と、３つ目の主対組情報９２２の主体ノード階層種別９２３“ウェブサービス”、対象ノード階層種別９２５“端末”、付加主対組フラグ３６３“真”が付加されていることおよびこの主対組情報９２２に対する第１可否判定結果１６２“許可”の組との組み合わせに対する第２可否判定結果３７２“許可”を取得する。
【００９６】
続けて、第２判定部３２０は、第２可否判定結果３７２を応答部２４０に送信する（ステップＳ５４６）。
【００９７】
次に、応答部２４０は、サービス提供可否判定要求９２１に対するサービス提供可否判定結果として、第２可否判定結果３７２に基づいた応答をネットワーク９１０経由で通信端末９２０に送信する（ステップＳ５４８）。
【００９８】
次に、動作の比較のために第２可否判定結果３７２“拒否”を取得する場合を説明する。
【００９９】
通信端末９２０は、ネットワーク９１０を経由してサービス提供可否判定装置１００に対して例えば図２１に示すようなサービス提供可否判定要求９２１を送信する（ステップＳ５１０）。
【０１００】
このサービス提供可否判定要求９２１には、１つめの主対組情報９２２の主体ノード属性値９２４が“sip:terminal9@example.com”であることが、第２可否判定結果３７２“許可”を取得する場合の説明と異なっている。
【０１０１】
次に、応答部２４０は、サービス提供可否判定要求９２１を主対組更新部３３０に送信する（ステップＳ５３８）。
【０１０２】
次に、主対組更新部３３０は、例えば図１１に示すような主対組設定記憶部２８０の主対組設定２８１を検索するが、サービス提供可否判定要求９２１に含まれる主対組情報９２２に対する付加主対組情報２８２を取得しない。続けて、主対組更新部３３０は、図２２に示すような更新後サービス提供可否判定要求３３１を応答部２４０へ送信する（ステップＳ５４０）。
【０１０３】
次に、応答部２４０は、更新後サービス提供可否判定要求３３１を第１判定部３１０に送信する（ステップＳ５４２）。
【０１０４】
次に、第１判定部３１０は、例えば図１７に示すような第１可否設定記憶部３６０の第１可否設定３６１を検索し、サービス提供可否判定要求９２１に含まれる１つ目の主対組情報９２２（主体ノード階層種別９２３“端末”、主体ノード属性値９２４“sip:terminal9@example.com”、対象ノード階層種別９２５“端末”、対象ノード属性値９２６“sip:terminal2@example.com”）と付加主対組フラグ３６３“真”が付加されていないこととに対する第１可否判定結果３６２“許可”を取得する。同様に、第１判定部１１０は、２つ目の主対組情報９２２（主体ノード階層種別９２３“ウェブサービス”、主体ノード属性値９２４“ws1@example.com”、対象ノード階層種別９２５“端末”、対象ノード属性値９２６“sip:terminal2@example.com”）と付加主対組フラグ３６３“真”が付加されていないこととに対する第１可否判定結果３６２“拒否”を取得する。
【０１０５】
続けて、第１判定部３１０は、サービス提供可否判定要求９２１とこれに含まれる主対組情報９２２それぞれに対応する第１可否判定結果３６２とに基づいて図２３に示すような第２可否判定要求３１１を生成し、第２判定部３２０へ送信する（ステップＳ５４４）。
【０１０６】
次に、第２判定部３２０は、例えば図１８に示すような第２可否設定記憶部３７０の第２可否設定３７１を検索し、サービス提供可否判定要求９２１に含まれる１つ目の主対組情報９２２の主体ノード階層種別９２３“端末”、対象ノード階層種別９２５“端末”、付加主対組フラグ３６３“真”が付加されていないことおよびこの主対組情報９２２に対する第１可否判定結果１６２“許可”の組と、２つ目の主対組情報９２２の主体ノード階層種別９２３“ウェブサービス”、対象ノード階層種別９２５“端末”、付加主対組フラグ３６３“真”が付加されていないことおよびこの主対組情報９２２に対する第１可否判定結果１６２“拒否”の組との組み合わせに対する第２可否判定結果３７２“拒否”を取得する。
【０１０７】
続けて、第２判定部３２０は、第２可否判定結果３７２を応答部２４０に送信する（ステップＳ５４６）。
【０１０８】
図２４は、図２０のステップＳ５４４における第１判定部３１０の動作を示すフローチャートである。
【０１０９】
まず、第１判定部３１０は、第１可否設定記憶部３６０を参照し、サービス提供可否判定要求９２１に含まれる主対組情報９２２と付加主対組フラグ３６３（付加主対組フラグ３６３“真”が付加されている場合は“真”、付加主対組フラグ３６３“真”が付加されていない場合は“偽”）とに対応する第１可否設定３６１を検索する（ステップＳ４４１）。
【０１１０】
続けて、第１判定部３１０は、検索した第１可否設定３６１から第１可否判定結果３６２を取得する（ステップＳ４４２）。
【０１１１】
次に、第１判定部３１０は、サービス提供可否判定要求９２１に含まれる主対組情報９２２のすべてについてステップＳ４４１を実行したか否かを判定する（ステップＳ４４３）。そして、未実行の主対組情報９２２がある場合（ステップＳ４４３でＮＯ）、処理はステップＳ１４１へ進む。また、すべて実行済の場合（ステップＳ４４３でＹＥＳ）、処理はステップＳ４４６へ進む。
【０１１２】
次に、第１判定部３１０は、サービス提供可否判定要求９２１とこれに含まれる主対組情報９２２それぞれに対応する第１可否判定結果３６２とに基づいて図１９に示すような第２可否判定要求３１１を生成し、第２判定部３２０へ送信する（ステップＳ４４６）。
【０１１３】
図２５は、図２０のステップＳ５４６における第２判定部３２０の動作を示すフローチャートである。
【０１１４】
まず、第２判定部３２０は、第２可否設定記憶部３７０を参照し、サービス提供可否判定要求９２１に含まれる各主対組情報９２２の主体ノード階層種別９２３および対象ノード階層種別９２５と付加主対組フラグ３６３（付加主対組フラグ３６３“真”が付加されている場合は“真”、付加主対組フラグ３６３“真”が付加されていない場合は“偽”）とこの主対組情報９２２に対する第１可否判定結果３６２との組の組み合わせに対応する第２可否設定３７１を検索する（ステップＳ４６１）。
【０１１５】
続けて、第２判定部３２０は、検索した第２可否設定３７１から第２可否判定結果３７２を取得する（ステップＳ４６２）。
【０１１６】
次に、第２判定部３２０は、第２可否判定結果３７２を応答部２４０に送信する（ステップＳ４６４）。
【０１１７】
上述した本実施形態における効果は、第２の実施形態と同様の効果を有することに加えて、通信端末９２０から受信したサービス提供可否判定要求９２１に含まれる主対組情報９２２と主対組更新部３３０の追加した主対組情報９２２（付加主対組情報２８２）とが同じ組み合わせである場合もそれぞれ異なる者として扱うことを可能にできる点である。
【０１１８】
その理由は、これらの主対組情報９２２を付加主対組フラグ３６３により区別するようにしたからである。
【０１１９】
次に本発明の第４の実施形態について図面を参照して説明する。
【０１２０】
図２６は、本発明の第４の実施形態の構成を示すブロック図である。図２６を参照すると、本発明の第４の実施形態は、第１判定手段４１０と第２判定手段４２０とを含むサービス提供可否判定装置４００から構成されている。
【０１２１】
第１判定部１１０は、例えば図３に示すような第１可否設定１６１に基づいて、例えば図２に示すようなサービス提供可否判定要求９２１に含まれる各主対組情報９２２について第１アクセス可否判定結果を取得する。
【０１２２】
第２判定部１２０は、例えば図４に示すような第２可否設定１７１に基づいて、第１アクセス可否判定結果である第1可否判定結果１６２と、サービス提供可否判定要求９２１に含まれる各主対組情報９２２の主体ノード階層種別９２３および対象ノード階層種別９２５との組の組み合わせに対する第２可否判定結果１７２により、アクセス可否を判定する。
【０１２３】
上述した本実施形態における効果は、サービス提供者とサービス利用者との間のサービス提供が多対多のアクセスによるものであってもサービス提供の可否を事前に判定することを可能にできる点である。
【０１２４】
その理由は、第１判定部１１０が各主対組におけるサービス提供可否を判定し、第２判定部１２０が第１判定部１１０の判定結果を利用して主対組の組み合わせ全体におけるサービス提供可否を判定するようにしたからである。
【０１２５】
以上の各実施形態で説明した各構成要素は、例えば、プログラムにより所定の処理をコンピュータに実行させてもよい。
【０１２６】
以上の各実施形態で説明した各構成要素は、必ずしも個々に独立した存在である必要はなく、複数の構成要素が１個のモジュールとして実現されたり、一つの構成要素が複数のモジュールで実現されたり、ある構成要素が他の構成要素の一部であったり、ある構成要素の一部と他の構成要素の一部とが重複していたり、といったような構成であってもよい。
【０１２７】
また、以上説明した各実施形態では、複数の動作をフローチャートの形式で順番に記載してあるが、その記載の順番は複数の動作を実行する順番を限定するものではない。このため、各実施形態を実施するときには、その複数の動作の順番は内容的に支障しない範囲で変更することができる。
【０１２８】
更に、以上説明した各実施形態では、複数の動作は個々に相違するタイミングで実行されることに限定されない。例えば、ある動作の実行中に他の動作が発生したり、ある動作の実行タイミングと他の動作の実行タイミングとの一部乃至全部が重複していたりしていてもよい。
【０１２９】
更に、以上説明した各実施形態では、ある動作が他の動作の契機になるように記載しているが、その記載はある動作と他の動作のすべての関係を限定するものではない。このため、各実施形態を実施するときには、その複数の動作の関係は内容的に支障しない範囲で変更することができる。また各構成要素の各動作の具体的な記載は、各構成要素の各動作を限定するものではない。このため、各構成要素の具体的な各動作は、各実施形態を実施する上で機能的、性能的、その他の特性に対して支障をきたさない範囲内で変更されて良い。
【０１３０】
尚、以上説明した各実施形態における各構成要素は、必要に応じ可能であれば、ハードウェアで実現されても良いし、ソフトウェアで実現されても良いし、ハードウェアとソフトウェアの混在により実現されても良い。
【０１３１】
また、各構成要素の物理的な構成は、以上の実施形態の記載に限定されることはなく、独立して存在しても良いし、組み合わされて存在しても良いしまたは分離して構成されても良い。例えば、購読端末、仲介端末および配信端末の各手段の機能の内の、複数の機能が１台の物理的な端末に同居してもよいし、一つの機能が分離して複数の端末に実装されてもよい。
【産業上の利用可能性】
【０１３２】
本発明は、インターネットや次世代通信網（ＮＧＮ（Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ Ｎｅｔｗｏｒｋ））を通じて携帯電話機などの通信端末間で行われるセッションシステムにおいて、セッションサービス提供時に可否判定を行うシステム、装置および方法に適用することができる。
【０１３３】
即ち、本発明は上述のようなシステム、装置および方法において、例えば、主体が３ＰＣＣサービスにサービス提供要求を送信したものの実際はサービス提供に要する主対組情報に対する可否判定の１つが拒否になっており、サービス提供要求が拒否されてしまって結局は無駄になってしまうサービス提供要求を送信することを未然に防止する機能を提供することができる。
【０１３４】
また、本発明は、特定の主対組に対する可否判定を、サービス提供の可否判定に反映することができる。このため、サービス提供者とサービス利用者間でサービス提供をしてもよいという合意があるにもかかわらず、主対組に対する可否判定の１つが拒否になっているためにサービス提供要求が拒否されてしまうというようなことを防ぐ機能を提供することができる。
【０１３５】
更にまた、本発明は、サービス提供者あるいはサービス利用者である主体が、対象までのサービス提供の可否判定の対象となる主対組、主対組の主体あるいは対象について把握していないものがある場合でも、サービス提供の可否をサービス提供前に問い合わせることを可能にする機能を提供することができる。
【０１３６】
更にまた、本発明は、サービス提供の可否判定の対象となる主対組の素性（例えば、サービス提供者あるいはサービス利用者が指定した場合、実施形態のサービス提供可否判定装置が指定した場合など）によって可否判定を変更する機能を提供することができる。
【符号の説明】
【０１３７】
１００ サービス提供可否判定装置
１１０ 第１判定部
１１１ 第２可否判定要求
１２０ 第２判定部
１４０ 応答部
１６０ 第１可否設定記憶部
１６１ 第１可否設定
１６２ 第１可否判定結果
１７０ 第２可否設定記憶部
１７１ 第２可否設定
１７２ 第２可否判定結果
２００ サービス提供可否判定装置
２３０ 主対組更新部
２３１ 更新後サービス提供可否判定要求
２４０ 応答部
２８０ 主対組設定記憶部
２８１ 主対組設定
２８２ 付加主対組情報
３１０ 第１判定部
３１１ 第２可否判定要求
３２０ 第２判定部
３３０ 主対組更新部
３３１ 更新後サービス提供可否判定要求
３６０ 第１可否設定記憶部
３６１ 第１可否設定
３６２ 第１可否判定結果
３６３ 付加主対組フラグ
３７０ 第２可否設定記憶部
３７１ 第２可否設定
３７２ 第２可否判定結果
４００ サービス提供可否判定装置
４１０ 第１判定手段
４２０ 第２判定手段
９１０ ネットワーク
９２０ 通信端末
９２１ サービス提供可否判定要求
９２２ 主対組情報
９２３ 主体ノード階層種別
９２４ 主体ノード属性値
９２５ 対象ノード階層種別
９２６ 対象ノード属性値
【特許請求の範囲】
【請求項１】
ノード階層種別とノード属性値とをそれぞれ含む第１ノード情報および第２ノード情報からなるノード組情報を少なくとも２つ以上含む判定要求について、
予め定められた第１可否設定に基づいて、前記ノード組情報で指定されたノード組毎の第１アクセス可否判定結果を取得する第１可否判定手段と、
予め定められた第２可否設定に基づいて、前記第１アクセス可否判定結果と前記ノード組の第１ノード情報の前記ノード階層種別および第２ノード情報の前記ノード階層種別との組の組み合わせについて第２アクセス可否判定結果を取得する第２可否判定手段と
を有することを特徴とする判定装置。
【請求項２】
前記ノード組情報を少なくとも１つ以上含む判定要求に対して、当該判定要求に含まれる前記ノード組情報に対応する付加ノード組情報を追加するノード組更新手段
を有することを特徴とする請求項１記載の判定装置。
【請求項３】
前記ノード組更新手段は、前記付加ノード組情報を追加する場合に当該付加ノード組に対応する付加ノード組フラグを合わせて追加し、
前記第１判定手段は、前記付加ノード組フラグを含む前記第１可否設定に基づいて、前記付加ノード組情報で指定されたノード組毎の第１アクセス可否判定結果を取得し、
前記第２判定手段は、前記付加ノード組フラグを含む前記第２可否設定に基づいて、前記ノード組毎の第１アクセス可否判定結果と、当該ノード組みに対応する付加ノード組フラグと、当該ノード組の第１ノード情報のノード階層種別および第２ノード情報のノード階層種別との組の組み合わせについて第２アクセス可否判定結果を取得する
ことを特徴とする請求項２記載の判定装置。
【請求項４】
前記追加ノード組情報を記憶する手段
を有することを特徴とする請求項２または３記載の判定装置。
【請求項５】
前記第１可否設定を記憶する手段
を有することを特徴とする請求項１乃至４記載の判定装置。
【請求項６】
前記第２可否設定を記憶する手段
を有することを特徴とする請求項１乃至５記載の判定装置。
【請求項７】
ネットワークから前記判定要求を受信し、
当該判定要求に対する第２アクセス可否判定結果に基づいて当該判定要求に対する応答をネットワークへ送信する応答手段
を有することを特徴とする請求項１乃至６記載の判定装置。
【請求項８】
ノード階層種別とノード属性値とをそれぞれ含む第１ノード情報および第２ノード情報からなるノード組情報を少なくとも２つ以上含む判定要求について、
予め定められた第１可否設定に基づいて、前記ノード組情報で指定されたノード組毎の第１アクセス可否判定結果を取得するステップ、
予め定められた第２可否設定に基づいて、前記第１アクセス可否判定結果と前記ノード組の第１ノード情報の前記ノード階層種別および第２ノード情報の前記ノード階層種別との組の組み合わせについて第２アクセス可否判定結果を取得するステップ
を有することを特徴とする判定方法。
【請求項９】
前記ノード組情報を少なくとも１つ以上含む判定要求に対して、当該判定要求に含まれる前記ノード組情報に対応する付加ノード組情報を追加するステップ
を有することを特徴とする請求項８記載の判定方法。
【請求項１０】
前記付加ノード組情報を追加する場合に当該付加ノード組に対応する付加ノード組フラグを合わせて追加するステップ、
前記付加ノード組フラグを含む前記第１可否設定に基づいて、前記付加ノード組情報で指定されたノード組毎の第１アクセス可否判定結果を取得ステップ、
前記付加ノード組フラグを含む前記第２可否設定に基づいて、前記ノード組毎の第１アクセス可否判定結果と、当該ノード組みに対応する付加ノード組フラグと、当該ノード組の第１ノード情報のノード階層種別および第２ノード情報のノード階層種別との組の組み合わせについて第２アクセス可否判定結果を取得するステップ
を有することを特徴とする請求項９記載の判定方法。
【請求項１１】
ネットワークから前記判定要求を受信するステップ、
当該判定要求に対する第２アクセス可否判定結果に基づいて当該判定要求に対する応答をネットワークへ送信するステップ
を有することを特徴とする請求項８乃至１０のいずれかに記載の判定方法。
【請求項１２】
ノード階層種別とノード属性値とをそれぞれ含む第１ノード情報および第２ノード情報からなるノード組情報を少なくとも２つ以上含む判定要求について、
予め定められた第１可否設定に基づいて、前記ノード組情報で指定されたノード組毎の第１アクセス可否判定結果を取得し、
予め定められた第２可否設定に基づいて、前記第１アクセス可否判定結果と前記ノード組の第１ノード情報の前記ノード階層種別および第２ノード情報の前記ノード階層種別との組の組み合わせについて第２アクセス可否判定結果を取得する処理
をコンピュータに実行させることを特徴とするプログラム。
【請求項１３】
前記ノード組情報を少なくとも１つ以上含む判定要求に対して、当該判定要求に含まれる前記ノード組情報に対応する付加ノード組情報を追加する処理
をコンピュータに実行させることを特徴とする請求項１２記載のプログラム。
【請求項１４】
前記付加ノード組情報を追加する場合に当該付加ノード組に対応する付加ノード組フラグを合わせて追加し、
前記付加ノード組フラグを含む前記第１可否設定に基づいて、前記付加ノード組情報で指定されたノード組毎の第１アクセス可否判定結果を取得し、
前記付加ノード組フラグを含む前記第２可否設定に基づいて、前記ノード組毎の第１アクセス可否判定結果と、当該ノード組みに対応する付加ノード組フラグと、当該ノード組の第１ノード情報のノード階層種別および第２ノード情報のノード階層種別との組の組み合わせについて第２アクセス可否判定結果を取得する処理
をコンピュータに実行させることを特徴とする請求項１３記載のプログラム。
【請求項１５】
ネットワークから前記判定要求を受信し、
当該判定要求に対する第２アクセス可否判定結果に基づいて当該判定要求に対する応答をネットワークへ送信する処理
をコンピュータに実行させることを特徴とする請求項１２乃至１４のいずれかに記載のプログラム。
【請求項１】
ノード階層種別とノード属性値とをそれぞれ含む第１ノード情報および第２ノード情報からなるノード組情報を少なくとも２つ以上含む判定要求について、
予め定められた第１可否設定に基づいて、前記ノード組情報で指定されたノード組毎の第１アクセス可否判定結果を取得する第１可否判定手段と、
予め定められた第２可否設定に基づいて、前記第１アクセス可否判定結果と前記ノード組の第１ノード情報の前記ノード階層種別および第２ノード情報の前記ノード階層種別との組の組み合わせについて第２アクセス可否判定結果を取得する第２可否判定手段と
を有することを特徴とする判定装置。
【請求項２】
前記ノード組情報を少なくとも１つ以上含む判定要求に対して、当該判定要求に含まれる前記ノード組情報に対応する付加ノード組情報を追加するノード組更新手段
を有することを特徴とする請求項１記載の判定装置。
【請求項３】
前記ノード組更新手段は、前記付加ノード組情報を追加する場合に当該付加ノード組に対応する付加ノード組フラグを合わせて追加し、
前記第１判定手段は、前記付加ノード組フラグを含む前記第１可否設定に基づいて、前記付加ノード組情報で指定されたノード組毎の第１アクセス可否判定結果を取得し、
前記第２判定手段は、前記付加ノード組フラグを含む前記第２可否設定に基づいて、前記ノード組毎の第１アクセス可否判定結果と、当該ノード組みに対応する付加ノード組フラグと、当該ノード組の第１ノード情報のノード階層種別および第２ノード情報のノード階層種別との組の組み合わせについて第２アクセス可否判定結果を取得する
ことを特徴とする請求項２記載の判定装置。
【請求項４】
前記追加ノード組情報を記憶する手段
を有することを特徴とする請求項２または３記載の判定装置。
【請求項５】
前記第１可否設定を記憶する手段
を有することを特徴とする請求項１乃至４記載の判定装置。
【請求項６】
前記第２可否設定を記憶する手段
を有することを特徴とする請求項１乃至５記載の判定装置。
【請求項７】
ネットワークから前記判定要求を受信し、
当該判定要求に対する第２アクセス可否判定結果に基づいて当該判定要求に対する応答をネットワークへ送信する応答手段
を有することを特徴とする請求項１乃至６記載の判定装置。
【請求項８】
ノード階層種別とノード属性値とをそれぞれ含む第１ノード情報および第２ノード情報からなるノード組情報を少なくとも２つ以上含む判定要求について、
予め定められた第１可否設定に基づいて、前記ノード組情報で指定されたノード組毎の第１アクセス可否判定結果を取得するステップ、
予め定められた第２可否設定に基づいて、前記第１アクセス可否判定結果と前記ノード組の第１ノード情報の前記ノード階層種別および第２ノード情報の前記ノード階層種別との組の組み合わせについて第２アクセス可否判定結果を取得するステップ
を有することを特徴とする判定方法。
【請求項９】
前記ノード組情報を少なくとも１つ以上含む判定要求に対して、当該判定要求に含まれる前記ノード組情報に対応する付加ノード組情報を追加するステップ
を有することを特徴とする請求項８記載の判定方法。
【請求項１０】
前記付加ノード組情報を追加する場合に当該付加ノード組に対応する付加ノード組フラグを合わせて追加するステップ、
前記付加ノード組フラグを含む前記第１可否設定に基づいて、前記付加ノード組情報で指定されたノード組毎の第１アクセス可否判定結果を取得ステップ、
前記付加ノード組フラグを含む前記第２可否設定に基づいて、前記ノード組毎の第１アクセス可否判定結果と、当該ノード組みに対応する付加ノード組フラグと、当該ノード組の第１ノード情報のノード階層種別および第２ノード情報のノード階層種別との組の組み合わせについて第２アクセス可否判定結果を取得するステップ
を有することを特徴とする請求項９記載の判定方法。
【請求項１１】
ネットワークから前記判定要求を受信するステップ、
当該判定要求に対する第２アクセス可否判定結果に基づいて当該判定要求に対する応答をネットワークへ送信するステップ
を有することを特徴とする請求項８乃至１０のいずれかに記載の判定方法。
【請求項１２】
ノード階層種別とノード属性値とをそれぞれ含む第１ノード情報および第２ノード情報からなるノード組情報を少なくとも２つ以上含む判定要求について、
予め定められた第１可否設定に基づいて、前記ノード組情報で指定されたノード組毎の第１アクセス可否判定結果を取得し、
予め定められた第２可否設定に基づいて、前記第１アクセス可否判定結果と前記ノード組の第１ノード情報の前記ノード階層種別および第２ノード情報の前記ノード階層種別との組の組み合わせについて第２アクセス可否判定結果を取得する処理
をコンピュータに実行させることを特徴とするプログラム。
【請求項１３】
前記ノード組情報を少なくとも１つ以上含む判定要求に対して、当該判定要求に含まれる前記ノード組情報に対応する付加ノード組情報を追加する処理
をコンピュータに実行させることを特徴とする請求項１２記載のプログラム。
【請求項１４】
前記付加ノード組情報を追加する場合に当該付加ノード組に対応する付加ノード組フラグを合わせて追加し、
前記付加ノード組フラグを含む前記第１可否設定に基づいて、前記付加ノード組情報で指定されたノード組毎の第１アクセス可否判定結果を取得し、
前記付加ノード組フラグを含む前記第２可否設定に基づいて、前記ノード組毎の第１アクセス可否判定結果と、当該ノード組みに対応する付加ノード組フラグと、当該ノード組の第１ノード情報のノード階層種別および第２ノード情報のノード階層種別との組の組み合わせについて第２アクセス可否判定結果を取得する処理
をコンピュータに実行させることを特徴とする請求項１３記載のプログラム。
【請求項１５】
ネットワークから前記判定要求を受信し、
当該判定要求に対する第２アクセス可否判定結果に基づいて当該判定要求に対する応答をネットワークへ送信する処理
をコンピュータに実行させることを特徴とする請求項１２乃至１４のいずれかに記載のプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【公開番号】特開２０１０−１５７１７７（Ｐ２０１０−１５７１７７Ａ）
【公開日】平成２２年７月１５日（２０１０．７．１５）
【国際特許分類】
【出願番号】特願２００９−１５８（Ｐ２００９−１５８）
【出願日】平成２１年１月５日（２００９．１．５）
【出願人】（０００００４２３７）日本電気株式会社 (19,353)
【Ｆターム（参考）】
【公開日】平成２２年７月１５日（２０１０．７．１５）
【国際特許分類】
【出願日】平成２１年１月５日（２００９．１．５）
【出願人】（０００００４２３７）日本電気株式会社 (19,353)
【Ｆターム（参考）】
[ Back to top ]