(57)【要約】【課題】メンバの持つ権限の委譲を容易に実現するコミュニティサービスを提供する。【解決手段】共通の趣味や背景を持つメンバ２により構成されるコミュニティにおいて、サービスの利用権など各種権限を持つ委譲メンバからの要求に応じて、時間帯や回数、料金負担などの条件付での権限委譲を証明する委譲証明書を、被委譲メンバに対して発行する。被委譲メンバが権限を行使する際には、被委譲メンバの認証および権限を行使する条件を満たしているか否かの検証をおこない、サービス提供事業者３に対して検証結果を証明するライセンス証明書を発行し、さらに権限の行使により料金が発生する場合は、委譲証明書に基づきメンバに分割請求を行う。【選択図】  図１
2004206187.tif 000002
【特許請求の範囲】
【請求項１】
ユニークな識別情報で管理されるメンバの集合であるコミュニティにおいて、前記コミュニティに属する前記メンバが保持する、サービス提供事業者が提供するサービスの利用に必要な権限の管理を行うコミュニティ管理システムであって、
ライセンス管理部を備え、
前記ライセンス管理部は、
前記デジタル情報サービスの享受に関わる権限を保持する委譲メンバが、前記権限を被委譲メンバに委譲する際に、前記権限の委譲を証明する委譲証明書を発行し、
前記被委譲メンバが、前記サービス提供事業者の端末に当該委譲権限の行使要求を行った際に、前記サービス提供事業者端末からの要求に基づき、前記委譲権限の行使要求が行使条件を満たしているか否かを検証し、行使条件を満たしている場合に、ライセンス証明書を、前記サービス提供事業者端末に発行し、前記サービス提供者事業者端末が、前記被委譲メンバ端末へサービスを提供することを可能にすることを特徴とするコミュニティ管理システム。
【請求項２】
請求項１記載のコミュニティ管理システムにおいて、
前記委譲証明書は、前記委譲メンバを特定する情報と、被委譲メンバを特定する情報と、前記委譲権限に関する情報と、当該委譲権限の行使条件と、当該委譲証明書を失効させるための無効化条件と、からなることを特徴とするコミュニティ管理システム。
【請求項３】
請求項２記載のコミュニティ管理システムにおいて、
前記ライセンス管理部は、前記サービス提供事業者端末から、前記委譲権限が行使されたことの通知を受け付け、
前記委譲権限の行使ログを生成し、
前記委譲証明書に含まれている失効条件を検証し、失効条件を満たしている場合は前記委譲証明書を無効化する
ことを特徴とするコミュニティ管理システム。
【請求項４】
請求項２記載のコミュニティ管理システムにおいて、
前記委譲証明書は、前記委譲権限に基づいて提供される前記サービスに関わる料金の決済方法を含み、
さらに、前記コミュニティ管理システムは、
前記サービス提供事業者端末から、前記提供した前記サービスに関わる代金請求書を受け付け、
前記決済方法に応じて、決済代行処理を行うコミュニティ決済代行部とを備えることを特徴とするコミュニティ管理システム。
【請求項５】
請求項４記載のコミュニティ管理システムにおいて、
前記コミュニティ決済代行部は、前記委譲メンバ端末に、前記委譲権限が行使されたことを通知することを特徴とするコミュニティ管理システム。
【請求項６】
請求項１記載のコミュニティ管理システムにおいて、
前記メンバの本人性および／または属性に関するメンバ情報を管理し、前記被委譲メンバが前記委譲された権限を行使する際の要求に応じて、前記メンバの本人性証明書および／または属性証明書を発行するコミュニティメンバ管理部を備え、
前記ライセンス管理部は、前記ライセンス証明書の発行に際して、
前記委譲証明書と、前記被委譲メンバの本人性証明書および／または属性証明書とに基づき、前記委譲権限の行使要求が行使条件を満たしているか否かを検証することを特徴とするコミュニティ管理システム。
【請求項７】
請求項１記載のコミュニティ管理システムにおいて、
前記ライセンス管理部は、
複数の前記委譲証明書からなる委譲証明書群を識別する統合ＩＤを発行し、
前記メンバ端末または前記サービス提供事業者端末との間で、該統合ＩＤにより、複数の前記委譲証明書を管理することを特徴とするコミュニティ管理システム。
【請求項８】
請求項４記載のコミュニティ管理システムにおいて、
前記コミュニティ決済代行部は、前記委譲書に記載されている決済条件に従い、少なくともひとりの委譲メンバおよび／または被委譲メンバに対する決済処理を行うことを特徴とするコミュニティ管理システム。
【請求項９】
請求項１記載のコミュニティ管理システムにおいて、
前記コミュニティメンバ管理部は、前記被委譲メンバが前記委譲権限に基づいて提供を受けた前記サービスについて、前記サービスを提供したサービス提供事業者端末から前記委譲権限の行使結果の通知を受け、前記委譲メンバ端末へ当該行使結果を通知し、
前記被委譲メンバの持つ委譲権限と、当該被委譲メンバが該委譲権限を行使した結果を管理し、
所定の基準に基づき前記被委譲メンバの信用ポイントを算出し、
他メンバ端末から参照可能な状態で登録することを特徴とするコミュニティ管理システム。
【請求項１０】
請求項９記載のコミュニティ管理システムにおいて、
権限を委譲する前記委譲メンバは、該権限の委譲先である被委譲メンバを検索する際に、前記信用ポイントを参照することを特徴とする
コミュニティ管理システム。
【請求項１１】
請求項１０記載のコミュニティ管理システムにおいて、
前記コミュニティメンバ管理部は、
前記委譲メンバの信用ポイントを、当該委譲メンバが権限を委譲された回数および／または当該委譲権限を行使した回数を元に算出することを特徴とするコミュニティ管理システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、何らかの共通の基準に合致する個人の集合であるネットワーク上のコミュニティにおいて、個人が所有している権限を他のメンバに委譲した場合のアクセス制御技術に関する。
【０００２】
【従来の技術】
現在、電子的な本人の認証や特定の方法として公開鍵基盤技術（ＰＫＩ：Ｐｕｂｌｉｃ  Ｋｅｙ  Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）があり、企業や個人が行政へ申請する際の業務の電子化に利用されている。申請業務においては、当事者本人が申請するとは限らず、代理人が申請する場合があり、この場合、当事者本人から代理人に対して資格や権限の委譲が必要になる。資格や権限を証明する技術として権限管理基盤（ＰＭＩ：Ｐｒｉｖｉｌｅｇｅ  Ｍａｎａｇｅｍｅｎｔ  Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）と属性証明書がある。
【０００３】
これらの基盤技術を使って、ネットワークに接続されたコンピュータ上のハードウェアやソフトウェア、データ等のリソースへの代理アクセス技術が提案されている。その一つとしては、特許文献１に記載のアクセス権限委譲装置、共有リソース管理システム及びアクセス権限設定方法がある。該発明ではアクセス権限を有する委譲者が対象リソースに対するアクセス権限の一時的譲渡又は権限の一部の限定的な譲渡を証明する委譲証明書を発行する。被委譲者は該証明書を取得し、さらに代理処理要求データと被委譲者の署名を加えたアクセス要求書を生成し、リソースを管理しているリソース管理サーバは該アクセス要求書を受け取り、署名およびアクセス要求が適正であるか否かの検証を行う。
【０００４】
また、特許文献２では、委譲対象のオンライン・サービスを管理するサービス提供事業者に対して、委譲証明書の電子署名の検証および有効期間内に委譲者により無効化されているか否かの検証を行う証明書サービスが提案されている。これにより委譲証明書を発行した後であっても、委譲者が該証明書を無効化することが可能であることを特徴としている。
【０００５】
また、委譲された権限を行使することにより新たに料金が発生する場合は、委譲者または被委譲者のどちらが料金を負担するか明確にし、負担者が支払う資力を持っているか否かを調査し、請求を行う必要がある。特許文献３は、決済事業者により発行された決済トークンを委譲者が被委譲者に委譲し、商品販売事業者は被委譲者より取得した決済トークンを検証し決済事業者に対して請求を行い、決済事業者は使用された決済トークンに応じて委譲者に請求を行う方法を開示している。これにより料金の請求を委譲者に対して確実に行うことを特徴としている。
【０００６】
【特許文献１】
特開２００２−１６３２３５号公報
【特許文献２】
米国特許出願公開第２００２／００８３０１４号明細書
【特許文献３】
米国特許出願公開第２００１／０００５８３９号明細書
【０００７】
【発明が解決しようとする課題】
特許文献１に記載の代理アクセス技術は、代理人である被委譲者がリソースを管理しているリソース管理サーバにアクセス要求を行った際、該被委譲者より受け付けた委譲証明書に記載の「権限行使のための行使条件」を該リソース管理サーバが常に検証し、アクセスを許可するか判定している。しかし、例えばデジタルコンテンツなどのリソースを管理しているサービス事業者が、別の事業者やメンバが発行した委譲証明書に記載の行使条件を解釈するためには、両者の間で行使条件の意味やフォーマットを事前に決めておく必要や、全てのサービス事業者が該行使条件を検証する機能が必要である。このため、権限を委譲できる対象や行使条件として設定可能な条件が制限され、新しい行使条件の作成や変更の度に発行者とサービス事業者の間で交渉が必要となる。
【０００８】
また、上記技術では委譲証明書や、本人証明のための公開鍵証明書や、権限を証明する属性証明書の管理を委譲者や被委譲者側で行っており、コストや手間がかかりメンバにとって利便性の低いものとなっている。さらに、サービス事業者側でもアクセスしてきた被委譲者の本人性を検証することに手間がかかる。
【０００９】
また、上記技術では委譲証明書に示される委譲者と被委譲者はそれぞれひとり（単数）である。しかし、例えばある音楽コンテンツを視聴する権限を一定期間だけ特定のグループ全員に委譲するといった、被委譲者が複数の場合の権限委譲や、サッカーチケットを購入する際、買いたい人を募ってチケットを購入するための決済権を集め、団体購入割引によりチケットをまとめて安く購入したい場合など、委譲者が複数の場合の権限委譲には、上記技術では対応できない。
【００１０】
また、友人や家族や同じ企業内のメンバ間など、委譲者と被委譲者とが既知であり、お互いの信用度が高い場合はよいが、ネットワーク上で形成された、何らかの共通の基準に合致する個人の集合であるコミュニティのメンバ同士など、相手の信用度が不明な場合には、委譲者が委譲する相手を選ぶための指標となる信用度情報の管理が必要である。
【００１１】
【課題を解決するための手段】
本発明は、委譲証明書の募集、発行、管理、検証、無効化といったライフサイクルを集中的に代行して管理し、メンバのもつ権限の委譲を容易に実現する。
【００１２】
本発明のコミュニティ管理システムは、ユニークな識別情報で管理されるメンバの活動によって成立するネットワーク上のコミュニティに対して、該メンバに関わる情報を管理し、該メンバを認証し、認証成功を証明する証明書を発行するコミュニティメンバ管理部と、権限を有する第１のメンバ端末からの要求に応じて委譲証明書を発行し、権限を委譲された第２のメンバ端末からの要求に応じて委譲証明書に対応付けられた一時的なＩＤを発行し、第２のメンバ端末からアクセス要求と該ＩＤを受け付けたサービス提供事業者端末からの要求に応じて該委譲証明書に含まれている行使条件を満たしているか否かの検証を行い、検証結果を示したライセンス証明書を発行し、第２のメンバの証明書または属性証明書と、該委譲証明書、および該ライセンス証明書を該サービス提供事業者に送信するライセンス管理部と、委譲された権限を行使することにより発生した料金に対する請求書を該サービス提供事業者から受付、該委譲証明書に含まれている決済条件に従って各メンバに分割して課金し、決済代行処理を行うコミュニティ決済代行部を備えることを特徴とする。
【００１３】
上記委譲証明書では委譲対象者として該コミュニティメンバ、該コミュニティ単位、該コミュニティ内での役割（ロールという）単位、またはその組み合わせで指定でき、上記ライセンス管理部では該コミュニティの第３のメンバ端末よりアクセス要求を受け付けると、上記コミュニティメンバ管理部より発行される該第３のメンバの属性を証明する該属性証明書と該委譲証明書より行使条件を満たしているか否かの検証し、上記ライセンス証明書を発行することを特徴とする。
【００１４】
上記ライセンス管理部では複数の上記委譲証明書を関連付けて管理し、該委譲証明書群を示す統合ＩＤを発行し、第２または第３のメンバ端末および上記サービス提供事業者端末との間で該統合ＩＤによる該委譲証明書群の指定を可能とする委譲証明書統合部を備えることを特徴とする。
【００１５】
上記コミュニティメンバ管理部において、上記メンバ毎に権限を委譲された回数、行使した回数を元に信用度を表す信用ポイントを算出し、第１のメンバが委譲する第２のメンバを検索または募集する際の条件として該信用ポイントを利用できることを特徴とする。
【００１６】
なお、本明細書において、本人性証明書、属性証明書、委譲証明書、ライセンス証明書などの各種文書は、いずれも、デジタル化データとして作成されるもので、ネットワークを介して送受信することが出来るものである。
【００１７】
【発明の実施の形態】
（ネットワーク構成）
図１は、本発明を適用したコミュニティ管理システムを提供するサービス（以下，本サービス）におけるネットワーク構成を示す。
【００１８】
本コミュニティ管理システム１を運営し、コミュニティサービスを提供する事業者（以下、コミュニティサービス事業者と呼ぶ）としては、コミュニティサービス事業者や通信事業者などが想定される。
【００１９】
図１において、メンバ端末２−１ないし２−ｎ、サービス提供事業者端末３−１ないし３−ｍ、決済事業者端末４−１ないし４−ｐ、および第三者機関としての認証局が有する認証局端末５は、例えばインターネットなどのネットワーク６を介して、該コミュニティ管理システム１に接続されている。
【００２０】
本サービスに登録しているメンバは、メンバ端末２−１ないし２−ｎを用いてコミュニティ管理システム１にアクセスし、コミュニティに参加し、後述する権限委譲等のサービスを利用できる。
【００２１】
デジタルコンテンツ配信事業者やネットオークション事業者、チケット販売事業者など、ネットワーク上で各種サービスを提供している事業者（以下、サービス提供事業者という）は、サービス提供事業者端末３−１ないし３−ｍを用いてコミュニティ管理システム１にアクセスし、メンバの認証情報や委譲証明書を取得し、メンバにサービスを提供する。また、本サービスに登録しているメンバに対する料金の請求をコミュニティ管理システム１に対して送信することが出来る。
【００２２】
決済事業者端末４−１ないし４−ｐを用いる銀行，クレジット会社、コンビニエンスストア等の料金の支払いを行う事業者（以下、決済事業者という）は、コミュニティサービス事業者が兼ねても良いし、事業者であってもよい。また、決済事業者端末は複数の決済事業者が共同で運営するものであっても良い。
【００２３】
認証局端末５を利用する認証局は、コミュニティサービス事業者や、各種サービス提供事業者、メンバなどに対し電子証明書を発行する第三者機関である。  認証局端末５は、委譲証明書、本人性証明書、属性証明書、ライセンス証明書など各種証明書に施された署名を検証するための、公開鍵および公開鍵証明書を、サービス提供事業者が取得および／または検証するために利用する。また、事前に公開鍵証明書はコミュニティ管理事業者により認証局に登録されているものである。また、公開鍵や公開鍵証明書の取得、検証のステップは、以下の実施例中、必要に応じて行われるものであり、特記していない。
【００２４】
（システム構成）
コミュニティ管理システム１のシステム構成および機能モジュール構成を具体的に説明する。該コミュニティ管理システム１は、コミュニティ管理サーバ１０、メンバ管理サーバ１１、提携サービス事業者管理サーバ１２、決済サーバ１３より構成されている。また、ネットワーク６が省略されて図示されている。
【００２５】
メンバ管理サーバ１１、提携サービス事業者管理サーバ１２、決済サーバ１３は本サービスを運営する事業者が既に持っている、メンバ管理、提携サービス事業者管理、決済管理等を行う既存の設備を想定しており、コミュニティ管理サーバ１０は該事業者が新たに追加したサーバ装置である。
【００２６】
さらに、コミュニティ管理サーバ１０はコミュニティメンバ管理部２１、ライセンス管理部２２、コミュニティ決済代行部２３、メンバ情報ＤＢ２４、コミュニティ情報ＤＢ２５、権限委譲情報ＤＢ２６、請求情報ＤＢ２７より構成されている。なお、ここでは１つのサーバ装置によりコミュニティ管理サーバ１０の機能を実現しているが、複数の装置により実現するようにしてもよい。
【００２７】
コミュニティメンバ管理部２１はネットワーク６を介して、メンバ端末２−１ないし２−ｎと接続され、各種ウェブコンテンツを生成してネットワークに公開する。そして新規コミュニティメンバの登録処理、コミュニティの新規登録、各種サービスを利用する際のメンバ認証処理と、メンバの本人性を証明する本人性証明書の発行と発行ログの管理、および／または該メンバの属性を証明する属性証明書の発行と発行ログの管理を行う。また、コミュニティメンバであるメンバ毎に、他メンバから権限を委譲された回数、行使した回数等の指標を元にメンバの信用度を表す信用ポイントを算出し管理する。
【００２８】
また、コミュニティメンバ管理部２１はメンバ情報が登録されるメンバ情報管理テーブルをメンバ情報ＤＢ２４に保持している。このメンバ情報管理テーブルには例えばメンバＩＤ、氏名、ハンドル名、年齢、住所、メールアドレス、興味を持っている事柄、決済情報（例えばクレジットカード番号など）などのメンバの属性が登録される。これらの情報は、メンバ管理サーバ１１が既に持っているメンバ情報を参照するデータであってもよい。さらにメンバがコミュニティに参加した場合、参加したコミュニティのコミュニティＩＤ、コミュニティ名、コミュニティ契約年月日、コミュニティ内での該メンバのロール（管理者など）、コミュニティにおいて委譲した権限に関する情報（例えば委譲証明書ＩＤ）、コミュニティにおいて委譲された権限に関する情報（例えば委譲証明書ＩＤ）、コミュニティにおいて権限を委譲された回数、委譲された権限を行使した回数、などのコミュニティに関連した属性が、上記メンバ情報管理テーブルに追加される。
【００２９】
また、コミュニティメンバ管理部２１は、権限を行使するための一時的なセッション情報を管理するセッション情報管理テーブルをメンバ情報ＤＢ２４に保持している。このセッション情報管理テーブルには、例えば一時的なセッションに割り振られるハンドルＩＤ、認証されたメンバの本人性証明書および／または属性証明書、または該証明書のＩＤ、行使する委譲された権限に関する情報（例えば委譲証明書ＩＤ）などの、委譲された権限を行使するのに必要な情報が一時的に保存される。
【００３０】
また、コミュニティメンバ管理部２１はメンバがコミュニティを新規作成した際に登録されるコミュニティ情報管理テーブルをコミュニティ情報ＤＢ２５に保持している。このコミュニティ情報管理テーブルには例えばコミュニティＩＤ、コミュニティ名、コミュニティの興味の対象、メンバ数、メンバのリスト、コミュニティ管理者名、契約しているサービス提供事業者名などが登録される。
【００３１】
ライセンス管理部２２はネットワーク６を介して、メンバ端末２−１ないし２−ｎと接続され、メンバ端末２−１ないし２−ｎからの要求に応じて、権限の委譲情報を記した委譲証明書の発行、該委譲証明書に含まれている行使条件を満たしているか否かの検証、該条件を満たしていることを証明するライセンス証明書の発行、委譲証明書の無効化、および発行したライセンス証明書の発行ログを管理する。
【００３２】
また、ライセンス管理部２２は委譲証明書を発行した際に登録される委譲証明書管理テーブルを権限委譲情報ＤＢ２６に保持する。該管理テーブルには例えば証明書ＩＤ、発行者、有効か無効かを示すステータス、行使された回数、失効期日、などが登録される。
【００３３】
また、ライセンス管理部２２は、複数の委譲証明書を一つの統合ＩＤで管理するための委譲書統合情報テーブルを権限委譲情報ＤＢ２６に保持する。該管理テーブルには例えば統合ＩＤ、関連付けられる複数の委譲証明書のＩＤ、などが登録される。
【００３４】
また、ライセンス管理部２２はネットワーク６を介して、サービス提供事業者端末３−１ないし３−ｍと接続され、サービス提供事業者端末３−１ないし３−ｍからの要求に応じてアクセスしてきたメンバの証明書と該委譲証明書および該ライセンス証明書を送信する。
【００３５】
コミュニティ決済代行部２３は、委譲された権限を行使することにより発生した料金に対する請求書を該サービス提供事業者端末３−１ないし３−ｍからネットワーク６を介して受け付け、該請求書と該委譲証明書に含まれている決済条件に従って該当するメンバに対する分割請求書を作成し、決済サーバ１３を介して決済代行処理を行う。決済サーバ１３はネットワーク６を介して、決済事業者端末４−１ないし４−ｐと接続されている。
【００３６】
決済条件は、下記に示す、委譲メンバと被委譲メンバでの料金の負担方法のいずれかに従って決定する。
(1) 委譲メンバと被委譲メンバが1対1の場合：委譲メンバまたは被委譲メンバまたは両方に分割
(2) 委譲メンバと被委譲メンバが多対1の場合：委譲メンバで分割、または被委譲メンバだけ、または両方に分割
(3) 委譲メンバと被委譲メンバが1対多、または多対多の場合：委譲メンバで分割、または被委譲メンバで分割または委譲された権限を行使した人のみ
また、コミュニティ決済代行部２３はサービス提供事業者より受け付けた請求書および該当するメンバに対して作成した分割請求書を請求情報ＤＢ２７に保持する。
【００３７】
（ハードウェア構成）
コミュニティ管理サーバ１０は図２に示すように、メモリ１０１、各種プログラム（コミュニティ管理プログラム、ＯＳ等）および各種データが格納されたハードディスクなどの二次記憶装置（ハードディスクという）１０２、ハードディスク１０２からメモリ１０１にプログラム（例えば、コミュニティ管理プログラム１００）をロードしそれを実行するＣＰＵ１０３、入出力インターフェース１０４、これらの間をつなぐバスなどの通信線１０５を有している。そして、入出力インターフェース１０４には表示装置１０６、入力装置（キーボード等）１０７、可搬型記憶媒体が装着されるドライブ１０８、通信回線との間のデータ伝送を制御するネットワーク制御装置１０９、等が接続されている。
【００３８】
このコミュニティ管理サーバ１０は、ＣＰＵ１０３が、コミュニティ管理プログラム１００を実行することによって、コミュニティサービスを提供する上記２１、２２、２３の機能構成部を実現する。
【００３９】
図１に示すその他の端末、すなわち、メンバ管理サーバ１１、提携サービス事業者管理サーバ１２、決済サーバ１３、サービス提供事業者端末３、決済事業者端末４、認証局端末５は、ハードディスク１０２内のプログラムが異なる以外は、コミュニティ管理サーバ１０と同様の構成を備える。
【００４０】
（本人性証明書）
図３は、上記コミュニティメンバ管理部２１により発行、管理される本人性証明書３０のデータ構成例を表している。本人性証明書３０は、認証されたメンバの本人性を証明するためのデータであり、認証されたメンバを識別する認証者識別情報（例えばメンバＩＤ）を記述したデータと、発行者のコミュニティサービス事業者によってこれらのデータに施されたデジタル署名、などから構成される。図３に示す本人性証明書３０には、証明書ＩＤ、メンバＩＤ、認証ドメイン名、コミュニティ名、認証方法、有効期間、発行者名、発行者連絡先、発行日時、およびデジタル署名が含まれている。
【００４１】
（属性証明書）
図４は、上記コミュニティメンバ管理部２１により発行、管理される属性証明書３１のデータ構成例を表している。属性証明書３１は、認証されたメンバの属性を証明するためのデータであり、認証されたメンバの属性を識別する、ロールや性別や所属しているコミュニティ名などの属性情報を記述したデータと、発行者のコミュニティサービス事業者によってこれらのデータに施されたデジタル署名、などから構成される。図４に示す属性証明書３１には、証明書ＩＤ、ハンドル名、ロール、認証ドメイン名、コミュニティ名、認証方法、有効期間、発行者名、発行者連絡先、発行日時、およびデジタル署名が含まれている。
【００４２】
（委譲証明書）
図５は、上記ライセンス管理部２２により発行、管理される委譲証明書３２のデータ構成例を表している。委譲証明書３２とは権限を所有するメンバが権限を持たないメンバに対して権限を委譲することを証明するデータであり、委譲証明書３２として必要なデータは、委譲者を識別する情報（委譲メンバＩＤ等）、被委譲者を識別する情報（被委譲メンバＩＤ等）または被委譲者の属性を識別する情報（コミュニティ名等）、および委譲権限を特定するデータと、発行者のコミュニティサービス事業者によってこれらのデータに施されたデジタル署名、などである。
【００４３】
図５に示す委譲証明書３２には、証明書ＩＤ、委譲メンバＩＤ、被委譲メンバＩＤ、コミュニティ名、認証ドメイン名、対象プロバイダ、対象サービス、対象権限、権限を行使するための行使条件（ここでは例として期間、時間帯、認証方法）、該委譲証明書を無効化するための失効条件（ここでは例として失効期日、行使回数）、発行者名、発行者連絡先、発行日時、およびデジタル署名が含まれている。
【００４４】
（ライセンス証明書）
図６は、上記ライセンス管理部２２により発行、管理されるライセンス証明書３３のデータ構成例を表している。図６に示すライセンス証明書３３には、証明書ＩＤ、本人性証明書３０および／または属性証明書３１、委譲証明書３２、行使条件に対する判定結果（ここでは例として有効期間、時間帯、回数、および全体に対する判定結果）、発行者名、発行者連絡先、発行日時、およびデジタル署名が含まれている。ライセンス証明書は、委譲証明書３２の情報を元に、権限を行使する条件を満たしているか否かを判定した結果を示したデータであり、一つ以上の行使条件を判定した結果のデータと、発行者のコミュニティサービス事業者によってこれらのデータに施されたデジタル署名が含まれる。図６では、本人性証明書３０または属性証明書３１、および委譲証明書３２の写しが含まれているが、各証明書への参照情報であっても良い。
【００４５】
以上図３から図６に挙げた各証明書は、認証や認可等セキュリティに関する表明を記述するための仕様であるＳＡＭＬ（Ｓｅｃｕｒｉｔｙ  Ａｓｓｅｒｔｉｏｎ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）などの既存の標準技術を用いて作成可能である。
【００４６】
以下に本発明の実施例を説明する。ただし前提条件として、既に従来の方法でメンバがコミュニティサービス事業者と契約しており、またコミュニティに参加しているものとする。さらに、サービス提供事業者はメンバがコミュニティサービス事業者と該サービス提供事業者の両方と契約している場合、両事業者がそれぞれ持つメンバを識別するための情報（例えばメンバＩＤ）を対応付けるマッピングテーブル既に持っているものとする。このテーブルは両事業者および該メンバの承諾を得て作成されるもので、シングル・サインオン等に関連した技術として公知な技術を用いて作成しているとする。
【００４７】
図７には、第１の実施形態であるコミュニティ管理システムによる委譲証明書のライフサイクルの集中的な代行管理に係るシステム構成図を示す。
【００４８】
サービス提供事業者（ここでは位置情報サービスプロバイダ）のサービス利用権限を持つ委譲メンバ２−Ａと、権限を委譲される被委譲メンバ２−Ｂはコミュニティサービス事業者と契約しており、コミュニティ（ここでは老人介護コミュニティ４１）に参加している。位置情報サービスプロバイダはコミュニティサービス事業者と提携している。委譲メンバ端末２−ａ、被委譲メンバ端末２−ｂ、コミュニティ管理システム１およびサービス提供事業者端末３−ａはネットワーク６を介して互いに接続する。
【００４９】
以下、位置情報サービスプロバイダと契約している委譲メンバ２−Ａが同じ老人介護コミュニティ４１に参加している被委譲メンバ２−Ｂに、位置情報サービスの利用権を行使条件（期間、時間帯、認証方法等）付きで委譲する場合を例にして説明する。
【００５０】
（委譲証明書発行要求処理）
権限を委譲する最初の処理として委譲メンバ２−Ａが被委譲メンバ２−Ｂに対して委譲証明書３２を発行する手順を図８に示す。委譲メンバ２−Ａはまず端末２−ａより契約しているコミュニティ管理システム１のコミュニティメンバ管理部２１にアクセスし、ログイン情報（例えばメンバＩＤとパスワード）を入力する（２０１）。
【００５１】
メンバ認証が完了する（２０２）と委譲メンバ２−Ａは委譲証明書発行申請画面にアクセス（２０３、２０４）し、被委譲メンバ２−Bの検索、選択と委譲内容の入力を行う（２０５）。
【００５２】
コミュニティ管理システム１ではライセンス管理部２２において入力を受信し、委譲可能な権限か否か、必要事項が入力されているか否かを判断（２０６）した上で、委譲可能であれば被委譲メンバ端末２−ｂに対して委譲内容と、委譲を受けるか否かの確認を求める受領確認通知を送信する（例えばメールにて送信する）（２０７）。委譲不可能の場合は、委譲メンバ２−Ａに対して差し戻し、再入力を求める。受領確認通知を受け取った被委譲メンバ２−Ｂは権限の委譲を受けるか否か判断（２０８）し、端末２−ｂより結果を送信する。
【００５３】
ライセンス発行部２２は、被委譲メンバ２−Ｂが委譲を受ける場合は委譲メンバ２−Ａより入力された情報を元に委譲証明書３２を発行し、権限委譲情報ＤＢ２６内の委譲証明書管理テーブルに登録する（２０９）。
【００５４】
また、コミュニティメンバ管理部２１は、このとき委譲証明書３２に一意に割り振られる証明書ＩＤを、メンバ情報ＤＢ２４内の委譲メンバ２−Ａおよび被委譲メンバ２―Ｂのメンバ情報管理テーブルに登録する。そして、委譲メンバ２−Ａに委譲証明書発行要求の結果が通知する（２１０）。
【００５５】
（委譲証明書発行申請画面）
図９に上記ステップ２０５において委譲内容を入力する委譲証明書発行申請画面の例を示す。図９中３０１は申請者である委譲メンバを識別する情報であり、ここではコミュニティ名とメンバＩＤである。３０２では委譲対象者を入力する。指定方法として特定メンバの指定、特定のロール（例えば管理者ロールなど）の指定、またはコミュニティの指定が可能となっている（ここでは特定メンバとして被委譲メンバを指定）。また、特定メンバの指定の際にメンバ情報２４よりコミュニティメンバの中で特定の条件（例えば、後述する信用ポイント）を持つメンバを検索し、特定メンバを決定することが可能となっている。具体的には、図９中の検索ボタンを押すと検索画面が表示され、メンバIDや信用ポイントに基づいて検索出来るように構成すればよい。また、メンバの一覧および信用ポイントを表示する画面やメンバの属性一覧まで表示する一覧画面より検索するようにしても良い。
【００５６】
３０３では対象権限の入力を行う。ここでは例として指定できる権限としてサービス利用権と商品購入権が選択できるようになっている。また、サービス利用権の詳細情報として、例えば対象サービス、委譲権限種類、サービス提供者、行使条件（ここでは例として委譲期間、時間帯、認証方法、利用回数が指定できる）が入力できる。また、商品購入権の詳細情報として、例えば店舗指定、金額指定、カテゴリ指定、期間指定、商品指定、数量指定、料金負担、受取り方法が入力できる。本実施例ではサービス利用権を委譲する例を示している。商品購入権を用いた実施例は後述する。さらに、３０４では委譲証明書を無効化するための失効条件を指定する。失効条件としては失効期日、権限が行使された行使回数などが指定可能である。
【００５７】
（委譲権限の行使）
被委譲メンバ２−Ｂが委譲された権限を行使する手順のフロー図を図１０に示す。被委譲メンバ２−Ｂはまず端末２−ｂより契約しているコミュニティ管理システム１のコミュニティメンバ管理部２１にアクセスし、ログイン情報（例えばメンバＩＤとパスワード）を入力する（４０１）。
【００５８】
メンバ認証が完了する（４０２）と被委譲メンバ２−Ｂは利用可能権限一覧画面にアクセスし、行使する権限を選択する（４０３）。
【００５９】
コミュニティ管理システム１のコミュニティメンバ管理部２１ではまずセッションＩＤを発行する。このセッションＩＤはコミュニティ管理システム１に一意に対応付けられたシステムＩＤと、一時的でランダムな文字、数字等から構成するハンドルＩＤと、を予め決めておいた形式に従って組み合わせて構成する。つぎに、被委譲メンバの本人性を証明する本人性証明書を発行し、保存する。さらに該本人性証明書および選択された行使権限に対応する委譲証明書が該ハンドルＩＤから一意に特定できるよう、メンバ情報ＤＢ２４のセッション情報管理テーブルにハンドルＩＤと各証明書または証明書ＩＤを保存する。これらは、セッションＩＤと対応付けた形でメモリ上やデータベースのテーブルに保存される。
次に、該セッションＩＤを被委譲メンバ端末２−ｂに送信する（４０４）。
【００６０】
セッションＩＤは悪意のあるメンバによる改ざん、偽造による危険を減らすため暗号化して送信することが望ましい。さらに、被委譲メンバ端末１−ｂとコミュニティ管理システム１およびサービス提供事業者端末３−ａ間のネットワーク６では、悪意のある第３者により盗聴される危険があるため、Ｓｅｃｕｒｅ  Ｓｏｃｋｅｔ  Ｌａｙｅｒ（ＳＳＬ）等の暗号化通信技術を用いて通信路の機密性を確保し、セッションＩＤを送受信することが望ましい。次に、被委譲メンバは端末２−ｂよりサービス提供事業者端末３−ａにアクセスし、委譲された権限の行使、すなわちサービスの提供を要求する。この際、セッションＩＤを通知する（４０５）。
【００６１】
サービス提供事業者は受け取ったセッションＩＤを解読し、システムＩＤよりコミュニティ管理システム１を特定し、サービス提供事業者端末３−ａより、セッションＩＤを元にコミュニティ管理システム１に対してライセンス証明書３３の発行を要求する（４０６）。
【００６２】
この際、盗聴や改ざん、成りすまし等のセキュリティ上の危険を避けるため、サービス提供事業者端末３−ａとコミュニティ管理システム１間のネットワーク６では、ＳＳＬ等の暗号化通信技術を用いて情報の暗号化、クライアント認証、サーバ認証を行う必要がある。次にコミュニティ管理システム１のライセンス管理部２２ではセッションＩＤに含まれるハンドルＩＤよりメンバ情報ＤＢ２４のセッション情報管理テーブルを検索し、委譲証明書３２および本人性証明書３０を特定し、権限を行使する条件を満たしているか否かを検証する。具体的には認証されたメンバが委譲されたメンバ本人か、委譲証明書に含まれている行使条件である委譲期間、時間帯、認証方法等を満たしているか、などを検証する（４０７）。
【００６３】
検証した結果、権限の行使を認められないときはその旨をサービス提供事業者端末３−ａに通知し、権限の行使が拒否される（４０８）。
【００６４】
権限の行使が認められた場合は、検証した結果のデータと、本人性証明書３０または該証明書への参照データ、委譲証明書３２からなるライセンス証明書３３を発行し、要求元のサービス事業者端末３−ａに送信する（４０９）。
【００６５】
サービス提供事業者は受信したライセンス証明書３３に施されているデジタル署名の正しさを検証し、次に行使条件の検証結果を確認し、被委譲メンバ２−Ｂに権限の行使を許可する（４１０）。
【００６６】
許可された被委譲メンバ２−Ｂは権限を行使し、サービス提供を享受する。本実施例では、ネットワーク上で提供される位置情報サービスプロバイダの位置情報サービスを被委譲メンバ端末２−ｂより利用する（４１１）。
【００６７】
次に、サービス提供事業者は端末３−ａよりコミュニティ管理システム１のライセンス管理部２２に対して行使結果の通知を行う（４１２）。
【００６８】
コミュニティ管理システム１のライセンス管理部２２はコミュニティメンバ管理部２１を介しては委譲メンバ端末２−ａに権限が行使されたことを通知する（４１３）。また、コミュニティメンバ管理部２１は、信用ポイントを計算し、信用ポイントおよび行使情報をメンバ情報管理テーブルへ登録（信用ポイントの計算および利用方については後ほど詳細に説明する）する。ライセンス管理部２２では行使ログを作成すると共に、委譲証明書に含まれている失効条件（失効期日や行使回数）を検証し、失効条件を満たしている場合は、権限委譲情報ＤＢ２６内の委譲証明書管理テーブルに保持されている該委譲証明書のステータスを無効に変更する。（４１４）。
【００６９】
また、上記実施例では処理ステップ４１３において権限が行使された後に委譲メンバ２−Ａに権限が行使されたことを通知しているが、ライセンス証明書３３を発行する前の４０９ステップにおいて委譲メンバ２−Ａに権限が行使されることを通知してもよい。さらに必要であれば委譲メンバ２−Ａからの同意を得てからライセンス証明書３３を発行してもよい。これにより、委譲した権限が不正に利用されていないかを、委譲メンバ２−Ａが早期に確認することが出来る。
【００７０】
以上により、権限をもつメンバが他のメンバに権限を委譲する際、委譲証明書３２の発行、管理、検証、無効化をコミュニティ管理システム１が行うことにより、メンバ、サービス提供事業者の負担を少なくし、権限の柔軟な委譲が可能になる。
【００７１】
（特定の属性をもつグループに対する権限委譲）
上記実施例では委譲メンバと被委譲メンバの関係がそれぞれひとり（単数）あったが、次に、委譲メンバがひとり以上の特定の属性を持つ者に対して行使条件付きで権限を委譲する第２の実施例を示す。ここで、特定のメンバ属性とは、例えば参加しているコミュニティ名、コミュニティ内で特定のロール（管理者など）などが挙げられる。
【００７２】
（委譲証明書発行要求処理）
実施例２において委譲証明書を発行するフローは図８に示すフローと同様であり、図８を用いて差分事項を説明する。まず、委譲メンバはステップ２０５において図９に示す委譲証明書発行申請画面より申請情報を入力する際、委譲対象者指定欄３０２より特定ロールまたはコミュニティを入力する。委譲証明書発行要求を受け取ったコミュニティ管理システム１は必要に応じて、委譲対象者指定欄３０２に記載された事項に合致する被委譲者を２０７、２０８ステップの受領確認処理を行う（例えばコミュニティに委譲する際はコミュニティの管理者が該受領確認処理を行うか、または省略可能である）。２０９ステップにおいて、上記申請情報に従い、被委譲メンバを識別する為の情報としてコミュニティ名または特定ロールまたはその組み合わせを用いて、特定ロールまたはコミュニティに対して委譲証明書３２を発行する。
【００７３】
（委譲権限の行使）
次に、実施例２において委譲された権限を行使するフローは図１０に示すフローと同様であり、図１０を用いて差分事項を説明する。
【００７４】
被委譲メンバがコミュニティ管理システム１にアクセス（４０１）し、メンバ認証（４０２）された後に、利用可能権限一覧画面より、該特定の属性を持つメンバに対して委譲された権限を選択する（４０３）と、コミュニティ管理システム１はまず、実施例１と同様にセッションＩＤを発行する。次に実施例１の本人性証明書３０とは異なる、メンバの属性を証明する属性証明書３１を発行する。次にコミュニティ管理システム１は該属性証明書および選択された行使権限に対応する委譲証明書がセッションＩＤに含まれるハンドルＩＤから一意に特定できるよう、メンバ情報ＤＢ２４のセッション情報管理テーブルにハンドルＩＤと各証明書または証明書ＩＤを保存する。そして、該被委譲メンバ端末に送信する（４０４）。
【００７５】
セッションＩＤを受信した被委譲メンバはサービス提供事業者端末にアクセスし、セッションＩＤをもとに委譲された権限の行使を要求する（４０５）。
【００７６】
サービス提供事業者は受け取ったセッションＩＤを元にコミュニティ管理システム１に対してライセンス証明書３３の発行を要求する（４０６）。
【００７７】
ステップ４０７において、コミュニティ管理システム１では権限を行使する条件を満たしているか否かを検証する（４０７）。
【００７８】
この際、認証されたメンバが要求された属性を持っているか検証する。検証した結果、権限の行使が認められた場合は、検証した結果のデータと属性証明書３１、委譲証明書３２からなるライセンス証明書３３を発行する（４０９）。
【００７９】
この際、属性証明書として必要なデータはメンバの属性を証明する情報であり、個人を特定する情報（例えばメンバ名など）は必ずしも必要ではない。つまり、匿名による権限の行使や、複数メンバからなるグループによる行使が可能になる。ライセンス証明書３３の発行からのステップ（４１０ないし４１４）は実施例１と同様なので説明を割愛する。
【００８０】
以上により、委譲メンバが特定の属性を持つ者またはグループに対して権限を委譲可能とした。また、委譲された特定の属性を持つ被委譲メンバが匿名で委譲された権限を行使可能とした。
【００８１】
図１１には、第３の実施形態である多対１権限委譲を利用したコミュニティに対するグループ課金に係るシステム構成図を示す。委譲メンバ２−Ｄないし２−Ｎおよび代表メンバ２−Ｃはコミュニティサービス事業者と契約しており、コミュニティ（ここではスポーツ応援コミュニティ４２）に参加している。また、委譲メンバ２−Ｄないし２−Ｎおよび代表メンバ２−Ｃは、メンバ情報ＤＢ２４のメンバ情報管理テーブルに商品を購入した際の決済を行うための情報（例えばクレジットカード番号など）を登録しているとする。また、サービス提供事業者（ここではチケット販売事業者）はコミュニティサービス事業者と提携している。委譲メンバ端末２−ｄないし２−ｎ、代表メンバ端末２−ｃ、コミュニティ管理システム１およびサービス提供事業者端末３−ｂはネットワーク６を介して互いに接続する。
【００８２】
以下、上記委譲メンバ２−Ｄないし２−Ｎが同じスポーツ応援コミュニティ４２に参加している代表メンバ２−Ｃに、決済権を購入対象、購入期限、支払い負担割合、などの条件付で委譲し、委譲されたメンバが一括してチケット販売事業者よりチケットを購入する例を説明する。
【００８３】
（権限委譲募集処理）
実施例１および２では委譲メンバが図９の委譲証明書発行申請画面より委譲証明書の発行要求を行うことから始めたが、実施例３では委譲を望むメンバ（代表メンバという）２−Ｃが他のコミュニティメンバに対して権限委譲を依頼する実施の形態を示す。図１２はこのような場合の手順を示すフロー図である。
【００８４】
代表メンバ２−Ｃはまず端末２−ｃより契約しているコミュニティ管理システム１のコミュニティメンバ管理部２１にアクセスし、ログイン情報（例えばメンバＩＤとパスワード）を入力する（５０１）。
【００８５】
メンバ認証が完了する（５０２）と代表メンバ２−Ｃは権限委譲募集画面（権限委譲募集画面については後述する）より募集情報を入力する（５０３）。
【００８６】
コミュニティ管理システム１ではライセンス管理部２２において入力を受信し、募集情報を入力された募集対象および応募条件情報とメンバ情報ＤＢ２４のメンバ情報管理テーブルに基づき募集対象者を選別し通知する（５０４）。
【００８７】
通知を受けた委譲メンバ２−Ｄないし２−Ｎは端末２−ｄないし２−ｎよりコミュニティ管理システム１の応募画面にアクセスし、認証情報を送信する（５０５）。
【００８８】
コミュニティ管理システム１では認証処理（５０６）を行ったあと、募集が締め切られているか検証し（５０７）、締め切っていない場合は委譲募集内容が表示される応募画面（５０８）を送信する。既に締め切られている場合は応募失敗通知を送信する。委譲メンバは募集内容に承諾する場合（５０９）は、端末２−ｄないし２−ｎより委譲証明書発行要求を送信する（５１０）。
【００８９】
発行要求を受け取ったコミュニティ管理システム１のライセンス管理部２２では、委譲証明書を発行、保存する（５１１）。
【００９０】
この際、委譲証明書には委譲募集画面より指定された情報に基づき、対象商品の指定や料金負担の条件等を含めておく。次に、委譲募集画面により入力された募集締め切り条件（例えば締め切り期日など）を満たしているか検証し（５１２）、満たしている場合は、集まった委譲証明書を一つのＩＤで管理できるよう、各委譲証明書の証明書ＩＤと、管理用に割り当てられた統合ＩＤをデータとする委譲書統合情報を権限委譲情報ＤＢ２６の委譲書統合情報テーブルに作成する（５１３）。満たしていない場合は募集を続ける。
【００９１】
そして、代表メンバ端末２−ｃに委譲証明書取得通知を送信し、代表メンバ２−Ｃは、図１４に示すように権限を行使する（５１４）。
【００９２】
上述のように、複数の人が代表者（一人）に権限を委譲する場合（多対１）、統合ＩＤを用いることによりトランザクションを１回にすることが出来るので、代表者が人数分の委譲証明書に対応したセッションＩＤをサービス提供事業者に渡したり、サービス提供事業者も、証明書の分だけコミュニティ管理システムとの間で取得トランザクションを行ったりする必要がない。
【００９３】
また、１対１の委譲の場合でも、複数の権限の委譲が必要するにも統合ＩＤを適用可能である。
【００９４】
（権限委譲募集画面）
図１３に上記ステップ５０３における権限委譲募集画面の例を示す。６０１は提案者である代表メンバ２−Ｃを識別する情報（ここではコミュニティ名とメンバＩＤ）が示されている。６０２では募集対象者を指定する。指定方法として特定メンバの指定、特定のロール（例えば管理者ロールなど）の指定、またはコミュニティメンバ全員の指定が可能となっている（ここではコミュニティメンバ全員を指定）。６０３では対象権限の指定を行い、図９委譲証明書発行申請画面における対象権限３０３と同じ内容が指定できる。
【００９５】
本実施例３では商品購入権を委譲する例を示している。６０４では委譲メンバの応募条件、例えば、年齢制限、性別制限、地域制限、など、を指定する。６０５では募集を締め切る条件（例えば、締め切り期日、目標委譲証明書数など）の指定を行う。
【００９６】
（コミュニティに対するグループ課金）
図１４は代表メンバ２−Ｃが委譲された権限を用いてサービス提供事業者（ここではチケット販売事業者）より商品（ここではチケット）を購入し、料金の請求を受けたコミュニティ管理システム１が委譲証明書に従って各委譲メンバから料金を徴収する手順を示したフロー図である。
【００９７】
被委譲メンバである代表メンバ２−Ｃがコミュニティ管理システム１よりセッションＩＤを取得するステップは図１０の４０１ないし４０４の処理と同様である。ただし、４０４のステップでは委譲証明書ＩＤの代わりに統合ＩＤをハンドルＩＤと対応付けて、メンバ情報ＤＢ２４のセッション情報管理テーブルに保存する。また、上記実施例１と同様に代表メンバ端末１−ｃとコミュニティ管理システム１およびサービス提供事業者端末３−ｂ間のネットワーク６では、ＳＳＬ等の暗号化通信技術を用いて情報を暗号化して送受信することが望ましい。
【００９８】
セッションＩＤを取得した代表メンバ２−Ｃは端末２−ｃよりサービス提供事業者端末３−ｂにアクセスし、商品の購入、すなわちサービスの提供を要求する。この際、決済部としてコミュニティサービス事業者のコミュニティ代行決済部２３を指定し、セッションＩＤを通知する（７０１）。
【００９９】
サービス提供事業者は受け取ったセッションＩＤを元にコミュニティ管理システム１のコミュニティ代行決済部２３に対して与信要求をする（７０２）。
【０１００】
次にコミュニティ代行決済部２３ではセッションＩＤに含まれるハンドルＩＤおよびメンバ情報ＤＢ２４のセッション情報管理テーブルより本人性証明書または／および属性証明書および統合ＩＤを特定する。さらに、統合ＩＤおよび権限委譲情報ＤＢ２６の委譲書統合情報テーブルより委譲証明書を特定し、権限を行使する条件を満たしているか否かを検証する。具体的には、認証されたメンバが委譲されたメンバであるか否か、委譲証明書にて指定された商品であるか、値段は指定金額を超えていないか、などを検証する（７０３）。
【０１０１】
検証した結果、購入を認められないときはその旨をサービス提供事業者端末３−ｂに通知し、購入が拒否される（７０４）。
【０１０２】
委譲条件を満たしている場合は、与信確認結果のデータを要求元のサービス提供事業者端末３−ｂに送信する（７０５）。
【０１０３】
購入した商品は少なくとも代表メンバ２−Ｃまたは委譲メンバ２−Ｄないし２−Ｎに対して提供され、サービスが提供されることになる（７０６）。
【０１０４】
この際、商品が電子チケットなど、ネットワークで送付可能なデジタルコンテンツの場合は、端末２−ｃまたは２−ｄないし２−ｎへの電子メールなどによる電子送付に必要な情報（電子メールアドレスなど）が必要である。また、紙のチケットのような物の場合は、送付するための住所や氏名等の情報が必要である。
【０１０５】
サービス提供事業者端末３はこれら商品送付に必要な個人情報を代表メンバ端末２−ｃから直接取得するか、コミュニティ管理システム１から取得し商品を送付する。送付に際して個人情報の流出を防ぐためには、たとえば、特開２００２−５５９１９号に開示されているような、コミュニティ管理システムを介してメンバの個人情報をサービス提供事業者に公開することなく、商品や広告の送付を実現する技術を用いればよい。
【０１０６】
これらの方法により商品を代表メンバ２−Ｃ（または、メンバ端末２−ｃ）または委譲メンバ２−Ｄないし２−Ｎ（または、メンバ端末２−ｄないし２−ｎ）に対して提供する。次に、サービス提供事業者端末３は請求書を作成し、コミュニティ管理システム１に送信する。
【０１０７】
請求書を受信したコミュニティ管理システム１では、コミュニティ決済代行部２３が、委譲証明書に含まれている料金負担条件に従って各委譲メンバおよび代表メンバに対して分割請求処理を行い、決済サーバ１３を介して各メンバの決済事業者端末４−１ないし４−ｋに対して、決済要求を送信する（７０８）。次に委譲メンバ端末２−ｄないし２−ｎに権限が行使されたことを通知する（７０９）。
【０１０８】
最後に、行使ログの作成、および信用ポイントの計算、信用ポイントおよび行使情報のメンバ情報管理テーブルへの登録を行うと共に、委譲証明書に含まれている失効条件（失効期日や行使回数）を検証し、失効条件を満たしている場合は権限委譲情報ＤＢ２６内の委譲証明書管理テーブルに保持されている該委譲証明書のステータスを無効に変更する（７１０）。
【０１０９】
以上により、多数の委譲メンバから代表メンバへの多対１権限委譲を実現した。また、決済権の委譲を利用したサービス提供事業者からコミュニティに対する一括請求を実現した。これにより、メンバ側では共同で商品を購入することにより団体割引等のサービスを受けることが可能となる。さらに商品を購入した際にメンバ間で直接金銭のやり取りをする必要がなくなる。また、クレジットカード番号などの個人情報をサービス提供事業者および共同購入者に公開することなく商品の購入が可能となる。サービス提供事業者側でも大量のメンバに対して一度に販売でき、また、請求処理を１回に集約できる。
【０１１０】
（信頼ポイントの計算、利用）
上述したように、被委譲メンバが権限を行使した後に、コミュニティ管理システム１において信用ポイントの計算が行われている（図１０ステップ４１４、図１４ステップ７１０）。
【０１１１】
この信用ポイントはネットワーク上のコミュニティにおいて相手の信用度が不明な場合に委譲メンバが委譲する相手（被委譲メンバ）を選ぶための指標となるものである。以下その方法および利用方法について説明する。
【０１１２】
該信用ポイントは、上記信用ポイントを計算する処理ステップ（実施例１：図１０ステップ４１４、実施例３：図１４ステップ７１０）において、予めコミュニティ管理者により定められている計算方法によって、複数の指標データを元に計算され、コミュニティ管理システム１のコミュニティメンバ管理部２１は、メンバ情報ＤＢ２４内のメンバ情報管理テーブルに登録する。指標データの例として、権限の被委譲回数、委譲された権限の行使回数、該コミュニティに在籍している日数などメンバ情報管理テーブルに記録されている被委譲メンバの幾つかの情報が利用可能である。信用ポイントの計算は、例えば
信用ポイント＝（権限の行使回数）÷（権限の被委譲回数）×１００
といった計算方法によって算出される。この信用ポイントはコミュニティ内でランキング形式などにより、他メンバが参照可能なように、例えばホームページなどで公開される。
【０１１３】
以上のように、権限の被委譲回数などをもとに上記信用ポイントを計算しコミュニティ内で公開することにより、相手の信用度が不明な場合に委譲メンバが委譲する相手を選ぶための一つの指標として用いることが出来る。
【０１１４】
【発明の効果】
本発明によれば、ネットワーク上のコミュニティに参加するメンバが、各自のもつ権限の委譲を容易に実現することができる。
【図面の簡単な説明】
【図１】コミュニティ管理システムが提供するサービスにおけるネットワーク構成と、システム構成および機能モジュール構成を示す図である。
【図２】コミュニティ管理システムを構成する各装置のハードウェア構成を示す図である。
【図３】証明書のデータ構成例である。
【図４】属性証明書のデータ構成例である。
【図５】委譲証明書のデータ構成例である。
【図６】ライセンス証明書のデータ構成例である。
【図７】実施例１に係るコミュニティ管理システムを提供するサービス構成を概念的に示す説明図である。
【図８】委譲証明書発行要求処理のフロー図である。
【図９】委譲証明書発行申請画面の例である。
【図１０】委譲権限の行使処理のフロー図である。
【図１１】コミュニティ管理システムを提供するサービス構成を概念的に示す説明図である。
【図１２】権限委譲募集および委譲承諾処理のフロー図である。
【図１３】権限委譲募集画面の例である。
【図１４】コミュニティに対するグループ課金処理のフロー図である。
【符号の説明】１…コミュニティ管理システム、２…メンバ端末、３…サービス提供事業者端末、４…決済事業者端末、５…認証局端末、６…ネットワーク、１０…コミュニティ管理サーバ、１１…メンバ管理サーバ、１２…提携サービス事業者管理サーバ、１３…決済サーバ、３０…本人性証明書、３１…属性証明書、３２…委譲証明書、３３…ライセンス証明書
【図１】
2004206187.tif 000003
【図２】
2004206187.tif 000004
【図３】
2004206187.tif 000005
【図４】
2004206187.tif 000006
【図５】
2004206187.tif 000007
【図６】
2004206187.tif 000008
【図７】
2004206187.tif 000009
【図８】
2004206187.tif 000010
【図９】
2004206187.tif 000011
【図１０】
2004206187.tif 000012
【図１１】
2004206187.tif 000013
【図１２】
2004206187.tif 000014
【図１３】
2004206187.tif 000015
【図１４】
2004206187.tif 000016