(57)【要約】【課題】複数の属性情報が記載された属性証明書の失効を管理する際の処理負荷を低減して、ユーザの利便性を高める。【解決手段】ＡＣＲＬ管理装置１２０が、属性証明書に含まれた属性情報の失効状態を表す部分失効情報を生成して格納する（ステップＳ１１０）。ユーザ端末２０が、属性証明書をサーバ３０に送信する（ステップＳ１０２等）。サーバ３０が、ＡＣＲＬ管理装置１２０に格納された部分失効情報とユーザ端末２０から受信した属性証明書に含まれた属性情報とを照合することによって、該属性情報の有効性を検証する（ステップＳ１０５等）。サーバ３０が、有効状態であると検証された属性情報を取得する（ステップＳ１０６）。【選択図】図６
2008011098.tif 000002
【特許請求の範囲】
【請求項１】
失効情報生成装置が、属性証明書に含まれた複数の属性情報それぞれの失効状態を表す部分失効情報を生成する第１ステップと、
前記失効情報生成装置が、第１ステップにて生成した部分失効情報をそれぞれの属性情報の特定情報と対応付けて格納する第２ステップと、
サービス提供先装置が、属性証明書をサービス提供元装置に送信する第３ステップと、
前記サービス提供元装置が、前記第３ステップにて前記サービス提供先装置により受信した属性証明書に含まれた属性情報に応じて、前記第２ステップにて該属性情報の特定情報と対応付けられて格納された部分失効情報を参照することによって、該属性情報の有効性を検証する第４ステップと
を備えることを特徴とする属性情報検証方法。
【請求項２】
失効情報生成装置が、属性証明書に含まれた複数の属性情報それぞれの失効状態を表す部分失効情報を生成する第１ステップと、
前記失効情報生成装置が、第１ステップにて生成した部分失効情報をそれぞれの属性情報の特定情報と対応付けて格納する第２ステップと、
サービス提供先装置が、属性証明書をサービス提供元装置に送信する第３ステップと、
前記サービス提供元装置が、前記第３ステップにて前記サービス提供先装置により受信した属性証明書に含まれた属性情報に対する有効性検証の要求信号を前記失効情報生成装置に送信する第５ステップと、
前記失効情報生成装置が、前記第５ステップにて受信した有効性検証の要求信号によって特定される属性情報に応じて、該属性情報の特定情報と対応付けて前記第２ステップにて格納した部分失効情報を参照することによって、該属性情報の有効性を検証する第６ステップと、
前記失効情報生成装置が、前記第６ステップにおける有効性検証の結果を表す信号を前記サービス提供元装置に送信する第７ステップと
を備えることを特徴とする属性情報検証方法。
【請求項３】
前記失効情報生成装置が、一度失効された属性情報が更新されることによって有効状態になったときに、該有効状態になった属性情報を該一度失効された属性情報の特定情報と対応付けて格納する第８ステップを更に備え、
前記第４ステップ又は前記第６ステップにおいては、一度失効された属性情報の特定情報に対応付けられて格納された属性情報は有効状態であると判断されることを特徴とする請求項１又は請求項２記載の属性情報検証方法。
【請求項４】
属性証明書に含まれた複数の属性情報それぞれの失効状態を表す部分失効情報を生成する生成手段と、
前記生成手段が生成した部分失効情報をそれぞれの属性情報の特定情報と対応付けて格納する格納手段と、
属性情報の特定情報と対応付けられて格納された部分失効情報の送信を要求する旨の失効情報要求信号をサービス提供元装置から受信する失効情報要求受信手段と、
前記失効情報要求受信手段が受信した失効情報要求信号に応じた部分失効情報を前記格納手段から読み出し、該読み出した部分失効情報を前記サービス提供元装置に送信する失効情報送信手段と
を備えることを特徴とする失効情報生成装置。
【請求項５】
属性証明書に含まれた複数の属性情報それぞれの失効状態を表す部分失効情報を生成する生成手段と、
前記生成手段が生成した部分失効情報をそれぞれの属性情報の特定情報と対応付けて格納する格納手段と、
属性情報に対する有効性検証の要求信号をサービス提供元装置から受信する検証要求受信手段と、
前記検証要求受信手段が受信した有効性検証の要求信号によって特定される属性情報に応じて、該属性情報の特定情報と対応付けて前記格納手段が格納した部分失効情報を参照することによって、該属性情報の有効性を検証する第２検証手段と、
前記第２検証手段による検証の結果を表す信号を前記サービス提供元装置に送信する検証結果送信手段と
を備えることを特徴とする失効情報生成装置。
【請求項６】
複数の属性情報を含んで構成される属性証明書をサービス提供先装置により受信する属性証明書受信手段と、
前記属性証明書受信手段が受信した属性証明書に含まれた属性情報に対応付けられた部分失効情報の送信を要求する旨の失効情報要求信号を失効情報生成装置に送信する失効情報要求手段と、
前記失効情報要求手段が送信した失効情報要求信号に応じた部分失効情報を前記失効情報生成装置から受信する失効情報受信手段と、
前記属性証明書受信手段が受信した属性証明書に含まれた属性情報に応じて、前記失効情報受信手段が受信した部分失効情報を参照することによって、該属性情報の有効性を検証する第１検証手段と
を備えることを特徴とするサービス提供元装置。
【請求項７】
複数の属性情報を含んで構成される属性証明書をサービス提供先装置により受信する属性証明書受信手段と、
前記属性証明書受信手段が受信した属性証明書に含まれた属性情報に対する有効性検証の要求信号を失効情報生成装置に送信する検証要求手段と、
前記検証要求手段が送信した有効性検証の要求信号に応じた有効性検証の結果を表す信号を受信する検証結果受信手段と
を備えることを特徴とするサービス提供元装置。
【請求項８】
複数の属性情報を含んで構成される属性証明書をサービス提供元装置に送信するサービス提供先装置、請求項４記載の失効情報生成装置、及び請求項６記載のサービス提供元装置を備えることを特徴とする属性情報検証システム。
【請求項９】
複数の属性情報を含んで構成される属性証明書をサービス提供元装置に送信するサービス提供先装置、請求項５記載の失効情報生成装置、及び請求項７記載のサービス提供元装置を備えることを特徴とする属性情報検証システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、属性情報検証方法、失効情報生成装置、サービス提供元装置、及び属性情報検証システムに関するものである。
【背景技術】
【０００２】
従来、例えば所定のデータの配信、或いは所定のウェブサイトへの接続許可等のサービスを提供する装置が、サービス利用者の個人情報等が記載された属性証明書を用いて、サービス利用者の本人認証等を行うといった技術が知られている（例えば、特許文献１参照）。
【０００３】
有効な属性情報に基づいて本人認証等を行うために、属性証明書に記載された属性情報が失効となった場合には、例えば従来のＡＣＲＬ（Attribute Certificate Revocation List）に該属性証明書を特定する例えばシリアル番号を記載しておく。そして、本人認証の際に、上記ＡＣＲＬを参照し、該ＡＣＲＬにシリアル番号が記載された属性証明書は失効されたものであると判断することが一般的に行われている。
【特許文献１】特開２００４−３０４２２７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
従来の技術において、例えば複数の属性情報が記載された属性証明書におけるある１つの属性情報が失効となったときに、該属性証明書のシリアル番号がＡＣＲＬに記載され、該属性証明書は失効されたものと取り扱われる。すなわち、失効された１つの属性情報以外の他の有効の属性情報も失効されたものとして取り扱われてしまう。このことは、従来は、属性証明書の全体に対して失効或いは有効にすることはできたものの、属性証明書を部分的に失効或いは有効にすること、つまり属性証明書が含む属性情報のそれぞれを失効或いは有効にすることはできなかったことに起因する。そして、まだ有効な属性情報を活用して、属性証明書を用いた本人認証等を継続するためには、失効された属性情報を該属性証明書から削除してから、有効な属性情報のみが記載された新しい属性証明書を再発行すること等の処理が必要とされていた。
【０００５】
ところで、例えばサービスを提供する装置の数が増えたこと等を理由に、１つの属性証明書に記載される属性情報の数が増えた場合には、属性情報の何れかが失効される回数も増えるため、それに伴って古い属性証明書の失効処理と新しい属性証明書の再発行処理等も頻繁になる。このため、場合によっては、それらの処理がネットワークや装置に与える負荷が大きくなる他、サービスを利用する側の利便性が低下する。
【０００６】
そこで、本発明は上記に鑑みてなされたもので、複数の属性情報が記載された属性証明書の失効を管理する際の処理負荷を低減して、ユーザの利便性を高めることが可能な属性情報検証方法、失効情報生成装置、サービス提供元装置、及び属性情報検証システムを提供することを目的とする。
【課題を解決するための手段】
【０００７】
上記課題を解決するために、本発明の属性情報検証方法は、失効情報生成装置が、属性証明書に含まれた複数の属性情報それぞれの失効状態を表す部分失効情報を生成する第１ステップと、失効情報生成装置が、第１ステップにて生成した部分失効情報をそれぞれの属性情報の特定情報と対応付けて格納する第２ステップと、サービス提供先装置が、属性証明書をサービス提供元装置に送信する第３ステップと、サービス提供元装置が、第３ステップにてサービス提供先装置により受信した属性証明書に含まれた属性情報に応じて、第２ステップにて該属性情報の特定情報と対応付けられて格納された部分失効情報を参照することによって、該属性情報の有効性を検証する第４ステップとを備える。
【０００８】
また、本発明の失効情報生成装置は、属性証明書に含まれた複数の属性情報それぞれの失効状態を表す部分失効情報を生成する生成手段と、生成手段が生成した部分失効情報をそれぞれの属性情報の特定情報と対応付けて格納する格納手段と、属性情報の特定情報と対応付けられて格納された部分失効情報の送信を要求する旨の失効情報要求信号をサービス提供元装置から受信する失効情報要求受信手段と、失効情報要求受信手段が受信した失効情報要求信号に応じた部分失効情報を格納手段から読み出し、該読み出した部分失効情報をサービス提供元装置に送信する失効情報送信手段とを備える。
【０００９】
また、本発明のサービス提供元装置は、複数の属性情報を含んで構成される属性証明書をサービス提供先装置により受信する属性証明書受信手段と、属性証明書受信手段が受信した属性証明書に含まれた属性情報に対応付けられた部分失効情報の送信を要求する旨の失効情報要求信号を失効情報生成装置に送信する失効情報要求手段と、失効情報要求手段が送信した失効情報要求信号に応じた部分失効情報を失効情報生成装置から受信する失効情報受信手段と、属性証明書受信手段が受信した属性証明書に含まれた属性情報に応じて、失効情報受信手段が受信した部分失効情報を参照することによって、該属性情報の有効性を検証する第１検証手段とを備える。
【００１０】
また、本発明の属性情報検証システムは、複数の属性情報を含んで構成される属性証明書をサービス提供元装置に送信するサービス提供先装置、上記失効情報生成装置及びサービス提供元装置を備える。
【００１１】
このような本発明の属性情報検証方法、失効情報生成装置、サービス提供元装置、及び属性情報検証システムによれば、属性証明書に含まれた複数の属性情報の中で例えばある属性情報が失効となったときに、その旨を表す部分失効情報を生成する。この部分失効情報は、当該属性情報の特定情報と対応付けられて失効情報生成装置に格納される。そして、サービス提供元装置は、属性情報の特定情報と対応付けられた部分失効情報を参照し、該属性情報の失効可否を確認することができる。
【００１２】
以上より、本発明においては、属性証明書に含まれた属性情報の失効を管理するために、例えば属性証明書の本体を失効させる処理、失効された属性情報を該属性証明書から削除する処理、及び有効な属性情報のみが記載された新しい属性証明書を再発行する処理等を行わない。これに対して、失効された属性情報の特定情報と対応付けられて格納された部分失効情報を用いて、何れの属性情報が現時点で失効されているかが検証可能である。このため、本発明によれば、上記処理等にかかる負荷を低減して、ユーザの利便性を高めることができる。
【００１３】
また、属性情報検証方法は、失効情報生成装置が、属性証明書に含まれた複数の属性情報それぞれの失効状態を表す部分失効情報を生成する第１ステップと、失効情報生成装置が、第１ステップにて生成した部分失効情報をそれぞれの属性情報の特定情報と対応付けて格納する第２ステップと、サービス提供先装置が、属性証明書をサービス提供元装置に送信する第３ステップと、サービス提供元装置が、第３ステップにてサービス提供先装置により受信した属性証明書に含まれた属性情報に対する有効性検証の要求信号を失効情報生成装置に送信する第５ステップと、失効情報生成装置が、第５ステップにて受信した有効性検証の要求信号によって特定される属性情報に応じて、該属性情報の特定情報と対応付けて第２ステップにて格納した部分失効情報を参照することによって、該属性情報の有効性を検証する第６ステップと、失効情報生成装置が、第６ステップにおける有効性検証の結果を表す信号をサービス提供元装置に送信する第７ステップとを備える。
【００１４】
また、失効情報生成装置は、属性証明書に含まれた複数の属性情報それぞれの失効状態を表す部分失効情報を生成する生成手段と、生成手段が生成した部分失効情報をそれぞれの属性情報の特定情報と対応付けて格納する格納手段と、属性情報に対する有効性検証の要求信号をサービス提供元装置から受信する検証要求受信手段と、検証要求受信手段が受信した有効性検証の要求信号によって特定される属性情報に応じて、該属性情報の特定情報と対応付けて格納手段が格納した部分失効情報を参照することによって、該属性情報の有効性を検証する第２検証手段と、第２検証手段による検証の結果を表す信号をサービス提供元装置に送信する検証結果送信手段とを備える。
【００１５】
また、サービス提供元装置は、複数の属性情報を含んで構成される属性証明書をサービス提供先装置により受信する属性証明書受信手段と、属性証明書受信手段が受信した属性証明書に含まれた属性情報に対する有効性検証の要求信号を失効情報生成装置に送信する検証要求手段と、検証要求手段が送信した有効性検証の要求信号に応じた有効性検証の結果を表す信号を受信する検証結果受信手段とを備える。
【００１６】
また、属性情報検証システムは、複数の属性情報を含んで構成される属性証明書をサービス提供元装置に送信するサービス提供先装置、上記失効情報生成装置及びサービス提供元装置を備える。
【００１７】
これらの発明によれば、サービス提供元装置は、有効性検証の結果を表す信号を失効情報生成装置から受信することによって、何れの属性情報が現時点で失効されているかを知ることができる。すなわち、部分失効情報がその生成元である失効情報生成装置から外部に送出されることなく、サービス提供元装置は属性情報の有効性を検証することができる。このため、属性情報の失効を管理する際の処理負荷を低減し、ユーザの利便性を高めつつも、例えば外部に送出されることによる部分失効情報の改竄を防止できる。
【００１８】
また、属性情報検証方法は、失効情報生成装置が、一度失効された属性情報が更新されることによって有効状態になったときに、該有効状態になった属性情報を該一度失効された属性情報の特定情報と対応付けて格納する第８ステップを更に備え、第４ステップ又は第６ステップにおいては、一度失効された属性情報の特定情報に対応付けられて格納された属性情報は有効状態であると判断されるようにしても良い。
【００１９】
この発明によれば、属性証明書に含まれたある属性情報が一度失効されて後で有効に更新された場合、属性情報の失効を管理するために、例えば属性証明書の本体を失効させる処理、失効された属性情報を該属性証明書から削除する処理、有効となった属性情報を該属性証明書に書き込む処理、及び有効な属性情報のみが記載された新しい属性証明書を再発行する処理等を行わない。これに対して、一度失効された属性情報の特定情報と対応付けられて格納された属性情報がある場合には、その属性情報を有効なものであると判断する。このことにより、過去に一度失効された属性情報が検証時点で有効状態に更新されているか否かが検証可能である。このため、この発明によれば、上記処理等にかかる負荷を低減して、ユーザの利便性を高めることができる。
【発明の効果】
【００２０】
本発明によれば、複数の属性情報が記載された属性証明書の失効を管理する際の処理負荷を低減して、ユーザの利便性を高めることができる。
【発明を実施するための最良の形態】
【００２１】
以下、添付図面を参照して本発明にかかる失効情報生成装置、サービス提供元装置、属性情報検証システム、及び属性情報検証方法の好適な実施形態を詳細に説明する。なお、図面の説明において同一の要素には同一の符号を付し、重複する説明を省略する。
【００２２】
［第１実施形態］
本発明の第１実施形態における課金情報検証システム（属性情報検証システム）１は、サービスの提供元装置からサービスの提供先装置へ所定のサービスが提供されるために、属性証明書に記載された課金情報（例えばクレジットカード番号など）の有効性を検証するシステムである。課金情報検証システム１の基本的な構成について、図１を参照しながら説明する。図１は課金情報検証システム１の構成概要図である。図１に示すように、課金情報検証システム１は、属性証明書管理装置１０、ユーザ端末（サービス提供先装置）２０、及びサーバ（サービス提供元装置）３０を備えて構成される。なお、図１ではユーザ端末２０とサーバ３０とが単数として図示されているが、実際の課金情報検証システム１の構成ではユーザ端末２０とサーバ３０とが複数存在する。以下、課金情報検証システム１の各構成要素について詳細に説明する。
【００２３】
属性証明書管理装置１０は、属性証明書等を管理するものである。図２は、属性証明書管理装置１０のハードウェア構成図である。属性証明書管理装置１０は、物理的には、図２に示すように、ＣＰＵ１１、主記憶装置であるＲＡＭ１２及びＲＯＭ１３、入力デバイスであるキーボード及びマウス等の入力装置１４、ディスプレイ等の出力装置１５、ネットワークカード等のデータ送受信デバイスである通信モジュール１６、及びハードディスク等の補助記憶装置１７を含むコンピュータシステムとして構成されている。後述する属性証明書管理装置１０の各機能は、図２に示すＣＰＵ１１、ＲＡＭ１２等のハードウェア上に所定のソフトウェアを読み込ませることにより、ＣＰＵ１１の制御のもとで通信モジュール１６、入力装置１４、出力装置１５を動作させると共に、ＲＡＭ１２や補助記憶装置１７におけるデータの読み出し及び書き込みを行うことで実現される。
【００２４】
図１に戻り、属性証明書管理装置１０は、属性証明書発行装置１１０及びＡＣＲＬ管理装置（失効情報生成装置）１２０を備えて構成される。属性証明書発行装置１１０は、属性証明書を生成してユーザ端末２０に発行するものであり、例えば属性証明書発行機関（ＡＡ）に設置される。属性証明書発行装置１１０は、通信網４０を介して、ユーザ端末２０と通信可能なように構成されている。通信網４０は、例えばインターネット網、ＰＤＣ（Personal Digital Cellular）網、ＩＭＴ（International MobileTelecommunication）２０００網等の無線通信網である。
【００２５】
図３は、属性証明書発行装置１１０が生成した属性証明書の一例を示す。図３に示すように、属性証明書には特定情報としてシリアル番号（図３においては「○○番」）が付されている。また、属性証明書には、例えば「名前」、「住所」、「前回購入品目」、「クレジットカード番号」等、ユーザ端末２０のユーザのプライバシーに関する属性情報が複数含まれている。以下の第１実施形態における説明においては、図１に示したユーザ端末２０とサーバ３０の間で課金を行うために、「名前」、「住所」、「クレジットカード番号」の３つの属性情報が有効なものとして必要であることを仮定する。これに対して、「前回購入品目」は、ユーザ端末２０とサーバ３０以外の装置間でサービスの授受を行うときに、その有効性が問われることを仮定する。すなわち、１つの属性証明書には複数の装置用の属性情報が含まれる。図１に戻り、属性証明書発行装置１１０は、このように生成した属性証明書を、通信網４０を介して、ユーザ端末２０に発行する。この発行処理は、属性証明書発行装置１１０からユーザ端末２０へ属性証明書の電子データを送信することで行われる。
【００２６】
ＡＣＲＬ管理装置１２０は、失効された属性証明書及び属性情報のリストであるＡＣＲＬ（Attribute Certificate Revocation List）を生成して管理するものである。ＡＣＲＬ管理装置１２０は、通信網５０を介して、サーバ３０と通信可能なように構成されている。通信網５０は、例えばインターネット網等の通信網である。ＡＣＲＬ管理装置１２０は、機能的には、ＡＣＲＬ生成部（生成手段）１２１、ＡＣＲＬ格納部（格納手段）１２２、ＡＣＲＬ要求受信部（失効情報要求受信手段）１２３、及びＡＣＲＬ要求応答部（失効情報送信手段）１２４を備える。以下、ＡＣＲＬ管理装置１２０の各構成要素について詳細に説明する。
【００２７】
ＡＣＲＬ生成部１２１は、属性証明書毎にＡＣＲＬを生成するものである。ＡＣＲＬ生成部１２１は、例えばある属性証明書に含まれた属性情報が失効となったときに、該属性証明書のシリアル番号を記載した該属性証明書用のＡＣＲＬを生成する。ＡＣＲＬに記載された属性証明書のシリアル番号は、該属性証明書の本体の失効状態を表す。また、ＡＣＲＬ生成部１２１は、失効された属性情報の属性名（属性情報の特定情報）をＡＣＲＬに記載する。ＡＣＲＬに記載された属性情報の属性名は、該属性情報の失効状態を表す。更に、ＡＣＲＬ生成部１２１は、一度失効された属性情報が更新されることによって有効状態になったときに、該有効状態になった属性情報を該失効状態の属性情報の属性名に対応付けてＡＣＲＬに格納する。なお、ＡＣＲＬに記載された属性名は本発明における部分失効情報に相当し、部分失効情報を生成して格納することは、失効された属性情報の属性名を特定してＡＣＲＬに記載することに相当する。
【００２８】
図４は、ＡＣＲＬ生成部１２１が生成したＡＣＲＬの一例を示す。図４に示すＡＣＲＬにはシリアル番号として「○○番」と記載されており、このことは、このＡＣＲＬが図３に示したシリアル番号「○○番」の属性証明書用のＡＣＲＬであることを表す。更に、ＡＣＲＬに「○○番」と記載されたことは、シリアル番号が「○○番」である属性証明書は、失効された属性情報を少なくとも１つ以上含んでおり、少なくとも部分的には失効されたものであることを表す。また、ＡＣＲＬには、属性名として「住所」と記載されている。このことは、「○○番」の属性証明書に含まれた「住所」という属性名の属性情報は、失効されたものであることを表す。同様に、ＡＣＲＬには、属性名として「クレジットカード番号」と記載されている。このことは、「○○番」の属性証明書に含まれた「クレジットカード番号」という属性名の属性情報は、失効されたものであることを表す。
【００２９】
一方、図４には、属性名「住所」に対応付けて「東京都○○区××村１−２−３」と記載されている。このことは、「住所」という属性名の属性情報は一度失効されたが、更新されることによって現時点では有効状態になったこと、及び該更新された内容は「東京都○○区××村１−２−３」であることを表す。すなわち、「住所」という属性名の属性情報はもはや失効状態ではないことを表す。このことは、例えば、ユーザ端末２０のユーザの住所が変更され、その旨を表す信号がユーザ端末２０からＡＣＲＬ管理装置１２０に送信されたときなどに起こる。
【００３０】
これに対して、属性名「クレジットカード番号」に対応付けては何も記載されていない。このことは、「クレジットカード番号」という属性名の属性情報は失効されたままであることを表す。このことは、例えば、ユーザ端末２０のユーザがクレジットカードを紛失してしまい、新しいクレジットカードを再発給されるまでにはクレジットカードで課金を行う全てのサービスに対して停止を要望する旨を表す信号が、ユーザ端末２０からＡＣＲＬ管理装置１２０に送信されたときなどに起こる。
【００３１】
更に、図４には属性名として「住所」と「クレジットカード番号」が記載されており、図３に示した属性証明書に記載された全ての属性名が記載されているわけではない。このことは、図３に示した属性証明書が失効されてはいるが、全ての属性情報に対して失効されたわけではなく、「クレジットカード番号」に対してのみ失効されていること、つまり属性証明書は部分的に失効されていることを表す。これに対して、例えば、ＡＣＲＬに、「名前」、「住所」、「前回購入品目」、「クレジットカード番号」等の全ての属性名が記載された場合には、該属性証明書に含まれた属性情報の全てが失効されており、該属性証明書は完全に失効されたものであることを表す。
【００３２】
図１に戻り、ＡＣＲＬ生成部１２１は、このように生成したＡＣＲＬをＡＣＲＬ格納部１２２に出力する。そして、ＡＣＲＬ格納部１２２は、ＡＣＲＬ生成部１２１から入力されたＡＣＲＬを格納する。
【００３３】
ＡＣＲＬ要求受信部１２３は、特定のＡＣＲＬを要求する旨を表すＡＣＲＬ要求信号をサーバ３０から受信するものである。ＡＣＲＬ要求信号は、例えば、任意の属性証明書のシリアル番号である。ＡＣＲＬ要求受信部１２３は、サーバ３０から受信した該シリアル番号をＡＣＲＬ要求応答部１２４に出力する。
【００３４】
ＡＣＲＬ要求応答部１２４は、ＡＣＲＬ要求受信部１２３から入力されたシリアル番号に対応したＡＣＲＬをサーバ３０に送信するものである。ＡＣＲＬ要求応答部１２４は、まずＡＣＲＬ要求受信部１２３から入力されたシリアル番号でＡＣＲＬ格納部１２２内を検索し、該シリアル番号が記載されたＡＣＲＬが見つかった場合には、該ＡＣＲＬをサーバ３０に送信する。一方、検索の結果、該シリアル番号が記載されたＡＣＲＬがＡＣＲＬ格納部１２２内で見つからなかった場合には、その旨を表す信号をサーバ３０に送信する。
【００３５】
ユーザ端末２０は、サービス提供先の携帯端末等の装置であって、本実施形態においては例えば携帯電話機である。図５は、ユーザ端末２０のハードウェア構成図である。ユーザ端末２０は、物理的には、図５に示すように、ＣＰＵ２１、主記憶装置であるＲＡＭ２２及びＲＯＭ２３、操作ボタンなどの操作部２４、ＬＣＤ（Liquid Crystal Display）やＥＬ（Electro Luminescence）などの出力装置２５、属性証明書管理装置１０とサーバ３０との間でデータの送受信を無線で行う無線通信部２６、メモリディバイス等の補助記憶装置２７を備えて構成される。後述するユーザ端末２０の各機能は、図５に示すＣＰＵ２１、ＲＡＭ２２等のハードウェア上に所定のソフトウェアを読み込ませることにより、ＣＰＵ２１の制御のもとで操作部２４、出力装置２５、無線通信部２６を動作させると共に、ＲＡＭ２２や補助記憶装置２７におけるデータの読み出し及び書き込みを行うことで実現される。
【００３６】
このようなユーザ端末２０において、ＲＡＭ２２及び補助記憶装置２７は、記憶可能な容量に制限があり、例えば複数の属性証明書を格納するほどの大量のメモリ容量を確保することは困難である。このため、ユーザ端末２０は、例えば課金を伴うサービスを複数のサーバから提供される場合に、該複数のサーバのそれぞれがユーザ端末２０のユーザに対する課金情報を確認するときに必要とする属性情報の全てをまとめて記載した１つの属性証明書（図３参照）を保持する。
【００３７】
図１に戻り、ユーザ端末２０は、通信網４０を介して、属性証明書発行装置１１０及びサーバ３０と通信可能なように構成されている。このユーザ端末２０は、機能的には、属性証明書受信部２１、サービス要求部２２及びサービス授受部２３を備える。
【００３８】
属性証明書受信部２１は、通信網４０を介して、属性証明書発行装置１１０により発行された属性証明書を受けるものである。属性証明書受信部２１は、属性証明書発行装置１１０から取得した属性証明書をサービス要求部２２に出力する。
【００３９】
サービス要求部２２は、通信網４０を介して、サーバ３０に、例えば所定のデータの配信等のサービスを要求するものである。ユーザ端末２０が任意のサーバから該サービスを受けるためには、ユーザ端末２０は自端末のユーザの課金情報をサーバ３０に認証させる必要がある。このため、サービス要求部２２は、該サービスの要求信号をサーバ３０に送信すると共に、属性証明書受信部２１から入力された属性証明書をサーバ３０に送信する。
【００４０】
サービス授受部２３は、サービス要求部２２がサーバ３０に送信したサービス要求信号等に対する応答信号として、サーバ３０からの該サービスの提供を受け入れるものである。
【００４１】
サーバ３０は、サービスの提供元の装置である。サーバ３０は、属性証明書管理装置１０と同様に、物理的な構成要素として、ＣＰＵ、ＲＡＭ、ＲＯＭ、入力装置、出力装置、通信モジュール、補助記憶装置などを含むコンピュータシステムとして構成されている（図２参照）。サーバ３０は、通信網４０を介して、ユーザ端末２０と通信可能なように構成されている。また、サーバ３０は、通信網５０を介して、ＡＣＲＬ管理装置１２０と通信可能なように構成されている。
【００４２】
サーバ３０は、機能的には、サービス要求受信部（属性証明書受信手段）３１、ＡＣＲＬ要求部（失効情報要求手段）３２、ＡＣＲＬ受信部（失効情報受信手段）３３、第１有効性検証部（第１検証手段）３４、属性情報取得部３５、及びサービス提供部３６を備える。
【００４３】
サービス要求受信部３１は、通信網４０を介して、ユーザ端末２０からのサービス要求信号を受信する。更に、ユーザ端末２０のユーザの課金情報を確認するために、サービス要求受信部３１は、ユーザ端末２０から属性証明書を受信する。サービス要求受信部３１は、ユーザ端末２０から受信した属性証明書をＡＣＲＬ要求部３２及び第１有効性検証部３４に出力する。また、サービス要求受信部３１は、ユーザ端末２０から受信したサービス要求信号をサービス提供部３６に出力する。
【００４４】
ＡＣＲＬ要求部３２は、通信網５０を介して、ＡＣＲＬ要求信号をＡＣＲＬ管理装置１２０に送信するものである。ＡＣＲＬ要求信号は、例えば、ＡＣＲＬ要求部３２がサービス要求受信部３１から入力された属性証明書のシリアル番号である。ＡＣＲＬ要求信号は、当該シリアル番号に対応付けてＡＣＲＬ管理装置１２０に格納されたＡＣＲＬを要求する旨を表す。
【００４５】
ＡＣＲＬ受信部３３は、ＡＣＲＬ要求部３２がＡＣＲＬ管理装置１２０に送信したＡＣＲＬ要求信号に応じて、ＡＣＲＬ管理装置１２０から送信されたＡＣＲＬ等を受信するものである。ＡＣＲＬ要求部３２が送信したシリアル番号が記載されたＡＣＲＬがＡＣＲＬ管理装置１２０に有る場合に、ＡＣＲＬ受信部３３は該ＡＣＲＬを受信する。一方、該シリアル番号が記載されたＡＣＲＬがＡＣＲＬ管理装置１２０に無い場合に、ＡＣＲＬ受信部３３はその旨を表す信号を受信する。ＡＣＲＬ受信部３３は、ＡＣＲＬ管理装置１２０から受信したＡＣＲＬ等を第１有効性検証部３４に出力する。
【００４６】
第１有効性検証部３４は、ＡＣＲＬ受信部３３から入力されたＡＣＲＬ等に基づいて、サービス要求受信部３１から入力された属性証明書の有効性を検証するものである。第１有効性検証部３４は、例えば、図４に示したようなＡＣＲＬをＡＣＲＬ受信部３３から入力され、且つ図３に示したような属性証明書をサービス要求受信部３１から入力された場合に、シリアル番号「○○番」の属性証明書は、失効された属性情報を少なくとも１つ以上含んでおり、少なくとも部分的には失効されたものであると判断する。また、この場合に、第１有効性検証部３４は、「○○番」の属性証明書に含まれた属性名「住所」の属性情報は、一度失効されたが、後ほど更新されることによって現時点では有効状態のものであると判断する。そして、該更新された内容は「東京都○○区××村１−２−３」であると判断する。また、同様な場合において、第１有効性検証部３４は、「○○番」の属性証明書に含まれた属性名「クレジットカード番号」の属性情報が失効されたままであると判断する。また、同様な場合において、第１有効性検証部３４は、図３の属性証明書の全ての属性情報が図４のＡＣＲＬに記載されてはいないこと、及び属性名「住所」は現時点では有効状態であることから、図３の属性証明書は完全に失効されたものではなく、部分的に失効されたものであると判断する。
【００４７】
上記のことに対して、例えば、ＡＣＲＬ要求部３２がＡＣＲＬ管理装置１２０に送信したシリアル番号が記載されたＡＣＲＬはＡＣＲＬ管理装置１２０に無かったことを表す信号をＡＣＲＬ受信部３３から入力され、且つ図３に示したような属性証明書をサービス要求受信部３１から入力された場合に、第１有効性検証部３４は、シリアル番号が「○○番」である属性証明書は失効された属性情報を１つも含んでおらず、完全に有効状態のものであると判断する。
【００４８】
第１有効性検証部３４は、有効性検証の対象とした属性証明書、及び該検証の結果を表す信号を属性情報取得部３５に出力する。そして、属性情報取得部３５は、該結果に基づいて、該属性証明書に含まれた属性情報を取得する。
【００４９】
具体的に、例えば、上述した仮定のようにユーザ端末２０とサーバ３０の間で課金が行われる際に、属性情報取得部３５が取得対象とする属性情報は、図３に示す複数の属性情報の中で、「名前」、「住所」、「クレジットカード番号」の３つである。そして、属性情報取得部３５が、有効性検証の結果を表す信号として、「○○番」の属性証明書は部分失効されており、「クレジットカード番号」だけが失効状態であること（上記図３及び図４における例と同じ）を表す信号を受信したとする。この場合に、属性情報取得部３５は、取得対象である「クレジットカード番号」が失効されていることを理由に、「クレジットカード番号」を取得しない。そして、属性情報取得部３５は、「クレジットカード番号」を取得しなかったことを表す信号をサービス提供部３６に出力する。
【００５０】
これに対して、例えば、属性情報取得部３５が、シリアル番号が「○○番」である属性証明書は失効された属性情報を１つも含んでおらず完全に有効状態であることを表す信号を受信したとする。この場合に、属性情報取得部３５は、取得対象である「名前」、「住所」、「クレジットカード番号」の全ての属性情報が有効状態であるので、該３つの属性情報を該属性証明書から取得する。なお、「前回購入品目」は元々取得対象ではないので取得しない。そして、属性情報取得部３５は、取得した３つの属性情報をサービス提供部３６に出力する。
【００５１】
サービス提供部３６は、属性情報取得部３５から入力された属性情報等を参照して、ユーザ端末２０のユーザに対する課金情報を確認し、その確認の結果に応じて、サービス要求受信部３１から入力されたサービス要求信号に応じたサービスをユーザ端末２０に提供するものである。サービス提供部３６は、例えば、属性情報取得部３５から「クレジットカード番号」を取得しなかったことを表す信号を入力された場合には、ユーザ端末２０のユーザに対する課金情報を確認するための全ての属性情報が揃っていないので、課金情報は確認できず、ユーザ端末２０に該サービスを提供しない。
【００５２】
これに対して、サービス提供部３６は、例えば、「名前」、「住所」、「クレジットカード番号」の３つの属性情報を属性情報取得部３５から入力され、且つ該３つの属性情報が当該課金を行うために適したものである場合（例えば、「クレジットカード番号」が正しいクレジットカード番号である場合など）には、ユーザ端末２０に該サービスを提供する。一方、例えば、「名前」、「住所」、「クレジットカード番号」の３つの属性情報を属性情報取得部３５から入力されたものの、該３つの属性情報が当該課金を行うために適したものではない場合（例えば、「クレジットカード番号」が間違ったクレジットカード番号である場合など）には、サービス提供部３６は、ユーザ端末２０に該サービスを提供しない。
【００５３】
続いて、課金情報検証システム１により行われる動作（属性情報検証方法）について、図６を参照しながら説明する。図６は、課金情報検証システム１の動作を示すシーケンス図である。
【００５４】
まず、属性証明書発行装置１０が、図３に示したような属性証明書をユーザ端末２０用の属性証明書として生成し、通信網４０を介してユーザ端末２０に発行する（Ｓ１０１）。ステップＳ１０１は、サービス提供先のユーザ端末２０がサービス提供元のサーバ３０にサービスの要求をする前に行われる動作である。以下では、ユーザ端末２０がサーバ３０にサービスの要求をする際に行われる動作を説明する。
【００５５】
ユーザ端末２０が、通信網４０を介して、サーバ３０にサービスを要求する。ユーザ端末２０は、該サービスの要求信号と共に、ステップＳ１０１にて発行された属性証明書をサーバ３０に送信する（ステップＳ１０２）。
【００５６】
次に、サーバ３０が、通信網５０を介して、ＡＣＲＬ要求信号をＡＣＲＬ管理装置１２０に送信する。ＡＣＲＬ要求信号は、ステップＳ１０２にてユーザ端末２０から受信した属性証明書のシリアル番号「○○番」である（ステップＳ１０３）。
【００５７】
次に、ＡＣＲＬ管理装置１２０が、ステップＳ１０３にて受信したシリアル番号「○○番」が記載されたＡＣＲＬを自装置が保持しているか否かを確認する。この動作は、該シリアル番号でＡＣＲＬ格納部１２２内を検索することで行われる。ＡＣＲＬ管理装置１２０はＡＣＲＬ生成処理（後述するステップＳ１１０を参照）をまだ行ってないので、シリアル番号「○○番」が記載されたＡＣＲＬは見つからない。このため、ＡＣＲＬ管理装置１２０は、ステップＳ１０３にて受信したシリアル番号「○○番」が記載されたＡＣＲＬは無いことを表す信号をサーバ３０に送信する（ステップＳ１０４）。
【００５８】
次に、サーバ３０が、ステップＳ１０２にてユーザ端末２０から受信した属性証明書及び該属性証明書に含まれた属性情報に対する有効性を検証する。この動作は、ステップＳ１０４にてＡＣＲＬ管理装置１２０から受信した信号に基づいて行われる。すなわち、ステップＳ１０４にて、シリアル番号「○○番」が記載されたＡＣＲＬは無いことを表す信号を受信したため、サーバ３０は、ステップＳ１０２にてユーザ端末２０から受信した属性証明書は有効状態であると判断する（ステップＳ１０５）。
【００５９】
次に、サーバ３０が、ステップＳ１０２にてユーザ端末２０から受信した属性証明書に含まれた属性情報を取得する。サーバ３０は、ユーザ端末２０のユーザの課金情報を確認するために、「名前」、「住所」、「クレジットカード番号」の３つの属性情報を読み取る（ステップＳ１０６）。
【００６０】
次に、サーバ３０が、ステップＳ１０６にて読み取った「名前」、「住所」、「クレジットカード番号」の３つの属性情報を用いて、ユーザ端末２０のユーザに対する課金情報を確認する（ステップＳ１０７）。
【００６１】
次に、サーバ３０が、ステップＳ１０７における課金情報が該サービスを許可するために適したものである場合（例えば、「クレジットカード番号」が正しいクレジットカード番号である場合など）に、ステップＳ１０２にて受信したサービスの要求信号に応じたサービスをユーザ端末２０に提供する（ステップＳ１０８）。
【００６２】
以上、ユーザ端末２０が送信した属性証明書の本体が有効な場合について説明した。一方、以下においては、ユーザ端末２０が送信した属性証明書が部分的に失効されている場合について説明する。ただし、以下においては、ユーザ端末２０のユーザは、「東京都○○区××村１−２−３」の所に引越したこと、及びクレジットカードを紛失したことを仮定する。
【００６３】
ユーザ端末２０が、ＡＣＲＬ管理装置１２０に、「住所」においては「東京都○○区××村１−２−３」の内容に変更すること、及び「クレジットカード番号」は失効させることを依頼する。この動作は、例えば、「住所」及び「クレジットカード番号」を表す信号をユーザ端末２０からＡＣＲＬ管理装置１２０へ送信し、且つ「東京都○○区××村１−２−３」を表す信号を「住所」を表す信号に対応付けてＡＣＲＬ管理装置１２０へ送信することなどで行われる（ステップＳ１０９）。
【００６４】
次に、ＡＣＲＬ管理装置１２０が、ステップＳ１０９にてユーザ端末２０から受信した信号に基づいてＡＣＲＬを生成する。図４は、ステップＳ１０９の依頼に応じてＡＣＲＬ管理装置１２０が生成したＡＣＲＬを示す（ステップＳ１１０）。
【００６５】
次に、ユーザ端末２０が、通信網４０を介して、サーバ３０にサービスを要求する。ユーザ端末２０は、該サービスの要求信号と共に、ステップＳ１０１にて発行された属性証明書をサーバ３０に送信する（ステップＳ１１）。
【００６６】
次に、サーバ３０が、通信網５０を介して、ＡＣＲＬ要求信号をＡＣＲＬ管理装置１２０に送信する。ＡＣＲＬ要求信号は、ステップＳ１１１にてユーザ端末２０から受信した属性証明書のシリアル番号「○○番」である（ステップＳ１１２）。
【００６７】
次に、ＡＣＲＬ管理装置１２０が、ステップＳ１１２にて受信したシリアル番号「○○番」が記載されたＡＣＲＬを自装置が保持しているか否かを確認する。この動作は、該シリアル番号「○○番」でＡＣＲＬ格納部１２２内を検索することで行われる。ステップＳ１１０にて、ＡＣＲＬ管理装置１２０はシリアル番号「○○番」を記載したＡＣＲＬを生成したので、該ＡＣＲＬが見つかりサーバ３０に送信される（ステップＳ１１３）。
【００６８】
次に、サーバ３０が、ステップＳ１１１にてユーザ端末２０から受信した属性証明書及び該属性証明書に含まれた属性情報に対する有効性を検証する。この動作は、ステップＳ１１３にて受信されたＡＣＲＬに基づいて行われる。すなわち、サーバ３０は、該ＡＣＲＬが送信されてきたことを理由に、シリアル番号が「○○番」である属性証明書は、失効された属性情報を少なくとも１つ以上含んでおり、少なくとも部分的には失効されたものであると判断する。
【００６９】
また、サーバ３０は、「住所」に対応付けられて「東京都○○区××村１−２−３」が記載されていることを理由に、「○○番」の属性証明書に含まれた属性名「住所」の属性情報は、一度失効されたが、更新されることによって有効状態になったものであると判断する。そして、該更新された内容は「東京都○○区××村１−２−３」であると判断する。また、ＡＣＲＬには「クレジットカード番号」と記載されており、「クレジットカード番号」には何も対応付けられていないことを理由に、「○○番」の属性証明書に含まれた属性名「クレジットカード番号」の属性情報は、失効されたままであると判断する。
【００７０】
以上より、サーバ３０は、自サーバがユーザ端末２０のユーザの課金情報を確認するために必要な３つの属性情報の全てが有効状態であるとは限らないので、該３つの属性情報の全てを取得することはできず、ユーザ端末２０のユーザに対する課金情報が確認できない（ステップＳ１１４）。このため、サーバ３０は、テップＳ１０２にて受信したサービスの要求信号に応じたサービスをユーザ端末２０に提供できないことを表す信号をユーザ端末２０に送信する（ステップＳ１１５）。
【００７１】
続いて、第１実施形態の作用及び効果について説明する。本実施形態によれば、属性証明書に含まれたある属性情報が失効された場合、有効な属性証明書に含まれた有効な属性情報を取得するために、例えば属性証明書の本体を失効させる処理、失効された属性情報を該属性証明書から削除する処理、及び有効な属性情報のみが記載された新しい属性証明書を再発行する処理等を行わない。これに対して、ＡＣＲＬに属性証明書のシリアル番号が記載されたか否かによって、該属性証明書に対する有効性を検証することが可能であり、且つ部分失効情報を用いて（ＡＣＲＬに該属性情報の属性名が記載されたか否かによって）、何れの属性情報が失効状態にあるかが検証可能である。このため、有効な属性証明書に含まれた有効な属性情報が取得可能であり、属性証明書を失効させてからまた再発行するなどの処理を行うために大きな手間がかかることを防止できる。したがって、第１実施形態によれば、上記処理等にかかる負荷を低減して、ユーザの利便性を高めることができる。
【００７２】
［第２実施形態］
以下、本発明の第２実施形態にかかるアクセス情報検証システム２を説明する。アクセス情報検証システム２は、例えばある会社の社内において、ある社員の端末から該社員の属する部署の共有フォルダへアクセスすることを許可するために、該社員用の属性証明書に記載されたアクセス情報（例えば所属部署名など）の有効性を検証するシステムである。このとき、例えば該部署用の共有フォルダには該部署に所属する社員のみがアクセス可能であることを仮定する。以下では、前述した第１実施形態における説明と異なる部分を中心に、アクセス情報検証システム２を説明する。
【００７３】
アクセス情報検証システム２の基本的な構成について、図７を参照しながら説明する。図７はアクセス情報検証システム２の構成概要図である。図７に示すように、アクセス情報検証システム２は、属性証明書管理装置１０、社員端末（サービス提供先装置であり、第１実施形態におけるユーザ端末２０に相当）２００、及び共有フォルダ管理装置（サービス提供元装置であり、第１実施形態におけるサーバ３０に相当）３００を備えて構成される。なお、図７では社員端末２００と共有フォルダ管理装置３００とが単数として図示されているが、実際のアクセス情報検証システム２の構成では社員端末２００と共有フォルダ管理装置３００とが複数存在する。以下、アクセス情報検証システム２の各構成要素について詳細に説明する。
【００７４】
属性証明書発行装置１１０は、属性証明書を生成して社員端末２００に発行する。図８は、属性証明書発行装置１１０が生成した属性証明書の一例を示す。図８に示すように、属性証明書には特定情報としてシリアル番号（図８においては「○△番」）が付されている。また、属性証明書には、例えば「名前」、「社員番号」、「入社日」、「所属部署名」等、社員端末２００のユーザである社員に関する情報が複数含まれている。以下では、社員端末２００が共有フォルダ管理装置３００の管理する共有フォルダへアクセスすることを許可されるために、「名前」、「社員番号」、「所属部署名」の３つの属性情報が有効なアクセス情報として必要であることを仮定する。これに対して、「入社日」は、社員端末２００と共有フォルダ管理装置３００以外の装置間でアクセスを制御されるときに、その有効性が問われることを仮定する。
【００７５】
図７に戻り、ＡＣＲＬ管理装置１２０は、ＡＣＲＬを生成して管理するものであり、通信網５０を介して、共有フォルダ管理装置３００と通信可能なように構成されている。ＡＣＲＬ管理装置１２０は、機能的には、ＡＣＲＬ生成部（生成手段）１２１、ＡＣＲＬ格納部（格納手段）１２２、有効性検証要求受信部（検証要求受信手段）１２５、第２有効性検証部（第２検証手段）１２６、及び検証結果送信部（検証結果送信手段）１２７を備える。
【００７６】
図９は、ＡＣＲＬ生成部１２１が生成したＡＣＲＬの一例を示す。図９に示すＡＣＲＬにはシリアル番号として「○△番」と記載されており、このことは、このＡＣＲＬが図８に示したシリアル番号「○△番」の属性証明書用のＡＣＲＬであることを表す。更に、ＡＣＲＬに「○△番」と記載されたことは、シリアル番号が「○△番」である属性証明書は、失効された属性情報を少なくとも１つ以上含んでおり、少なくとも部分的には失効されたものであることを表す。また、ＡＣＲＬには、属性名として「所属部署名」と記載されている。このことは、「○△番」の属性証明書に含まれた「所属部署名」は、失効されたものであることを表す。一方、図９には、属性名「所属部署名」に対応付けて「総務部」と記載されている。このことは、「所属部署名」という属性名の属性情報は一度失効されたが、更新されることによって有効状態になったこと、及び該更新された内容は「総務部」であることを表す。すなわち、「所属部署名」という属性名の属性情報はもはや失効状態ではないことを表す。したがって、シリアル番号「○△番」の属性証明書ももはや失効状態ではないこととなる。これらのことは、例えば、社員端末２００の社員の部署が例えば営業部から総務部へと変更されたときなどに起こる。
【００７７】
図７に戻り、有効性検証要求受信部１２５は、特定の属性証明書及び該属性証明書に含まれた属性情報に対する有効性の検証を求める旨を表す有効性検証要求信号を共有フォルダ管理装置３００から受信するものである。有効性検証要求信号は、例えば有効性検証の対象となる属性証明書である。有効性検証要求受信部１２５は、共有フォルダ管理装置３００から受信した属性証明書を第２有効性検証部１２６に出力する。
【００７８】
第２有効性検証部１２６は、有効性検証要求受信部１２５から入力された属性証明書、及び該属性証明書に含まれた属性情報に対する有効性を検証するものである。第２有効性検証部１２６は、該属性証明書及び該属性情報とＡＣＲＬ格納部１２２に格納されたＡＣＲＬとを照合することにより、該属性証明書及び該属性情報に対する有効性を検証する。
【００７９】
具体的に、第２有効性検証部１２６が、例えば図８に示したような属性証明書を有効性検証要求受信部１２５から入力されたと仮定する。この場合に、第２有効性検証部１２６は、まず該属性証明書のシリアル番号「○△番」でＡＣＲＬ格納部１２２内を検索する。検索の結果、該シリアル番号「○△番」が記載された例えば図９に示したようなＡＣＲＬを見つけた場合に、第２有効性検証部１２６は、該属性証明書が失効されたものであると判断する。一方、該ＡＣＲＬには、「名前」、「社員番号」、「入社日」、「所属部署名」等の全ての属性名が記載されてはいないので、該属性証明書は属性情報の全てが失効されたものではなく部分的に失効されたものであると判断される。また、第２有効性検証部１２６は、「○△番」の属性証明書に含まれた属性名「所属部署名」の属性情報は、一度失効されたが、後ほど更新されることによって有効状態になったものであると判断する。更に、該更新された内容は「総務部」であると判断する。以上より、第２有効性検証部１２６は、有効性検証要求受信部１２５から入力された属性証明書は現時点では有効状態であると判断する。これらのことに対して、上記検索の結果、例えば該シリアル番号が記載されたＡＣＲＬがＡＣＲＬ格納部１２２内で見つからなかった場合には、シリアル番号「○△番」の属性証明書は、失効された属性情報を１つも含んでおらず、有効状態のものであると判断される。
【００８０】
第２有効性検証部１２６は、上記判断の結果を表す検証結果信号を検証結果送信部１２７に出力する。検証結果信号としては、上述したように属性証明書に含まれた属性情報が全て有効であることを表す信号や、属性証明書に含まれた属性情報が部分的に失効であることを表す信号の他に、例えば、属性証明書に含まれた属性情報が全て失効であることを表す信号、属性証明書或いは属性情報の失効可否が不明であることを表す信号などがある。また、更新されて有効になった属性情報がある場合には、該更新された属性情報が検証結果信号に含まれる。検証結果送信部１２７は、第２有効性検証部１２６から入力された検証結果信号を、通信網５０を介して、ＯＣＳＰ（Online Certificate Status Protocol）レスポンスとして共有フォルダ管理装置３００に送信する。
【００８１】
社員端末２００は、共有フォルダ管理装置３００の管理する共有フォルダ（当該社員の属する部署の共有フォルダ）にアクセスするために用いられる端末である。第２実施形態において、社員端末２００は記憶可能な容量に制限があり、例えば複数の属性証明書を格納するほどの大量のメモリ容量を確保することは困難であることを仮定する。
【００８２】
共有フォルダ管理装置３００は、社員端末２００のアクセスの対象となる共有フォルダを管理する装置である。この共有フォルダ管理装置３００は、例えば各部署の共有フォルダ毎に設けられる。共有フォルダ管理装置３００は、機能的には、サービス要求受信部（属性証明書受信手段）３１、有効性検証要求部（検証要求手段）３７、検証結果受信部（検証結果受信手段）３８、属性情報取得部３５、及びサービス提供部３６を備える。
【００８３】
サービス要求受信部３１は、通信網４０を介して、社員端末２００からのサービス要求信号を受信する。第２実施形態において、サービス要求信号は、社員端末２００の社員が属する部署の共有フォルダへのアクセス要求信号である。また、サービス要求受信部３１は、社員端末２００の社員のアクセス情報を確認するために、社員端末２００から属性証明書を更に受信する。サービス要求受信部３１は、社員端末２００から受信した属性証明書を有効性検証要求部３７及び属性情報取得部３５に出力する。また、サービス要求受信部３１は、社員端末２００から受信したサービス要求信号をサービス提供部３６に出力する。
【００８４】
有効性検証要求部３７は、通信網５０を介して、有効性検証要求信号をＡＣＲＬ管理装置１２０に送信するものである。有効性検証要求信号は、例えばサービス要求受信部３１から入力された属性証明書である。
【００８５】
検証結果受信部３８は、有効性検証要求部３７がＡＣＲＬ管理装置１２０に送信した有効性検証要求信号に対するＯＣＳＰレスポンスとして、有効性の検証結果信号をＡＣＲＬ管理装置１２０から受信するものである。該検証結果信号は、サービス要求受信部３１が社員端末２００から受信した属性証明書及び該属性証明書に含まれた属性情報に対する失効可否を表す。検証結果受信部３８は、受信した検証結果信号を属性情報取得部３５に出力する。
【００８６】
属性情報取得部３５は、検証結果信号を検証結果受信部３８から入力され、該検証結果信号に基づいて、サービス要求受信部３１から入力された属性証明書に含まれた属性情報を取得する。
【００８７】
具体的に、例えば、前述した仮定のように社員端末２００が共有フォルダ管理装置３００の管理する共有フォルダへアクセスする際に、属性情報取得部３５が取得対象とする属性情報は、図８に示す複数の属性情報の中で「名前」、「社員番号」、「所属部署名」の３つである。この場合に、例えば、「○△番」の属性証明書に含まれた「名前」及び「社員番号」の属性情報は有効であり、且つ「所属部署名」は一度失効されたが、「総務部」という内容で更新されていることを表す信号を、属性情報取得部３５が検証結果信号として受信したことを仮定する。なお、この仮定は、前述したように、図８の属性証明書に対して図９のＡＣＲＬが見つかった場合のことである。この場合に、属性情報取得部３５は、有効状態である「名前」及び「社員番号」の属性情報を取得すると共に、「所属部署名」が現時点では有効であるため、当該更新した内容（「総務部」）で「所属部署名」を取得する。そして、属性情報取得部３５は、取得した３つの属性情報をサービス提供部３６に出力する。
【００８８】
これに対して、例えば、シリアル番号が「○△番」である属性証明書は、取得対象である「名前」、「社員番号」、「所属部署名」の中で、現時点で失効された属性情報を１つ以上も含んでいることを表す信号を、属性情報取得部３５が受信したとする。この場合に、属性情報取得部３５は、現時点で失効された該属性情報を取得せず、その旨を表す信号をサービス提供部３６に出力する。
【００８９】
サービス提供部３６は、属性情報取得部３５から入力された属性情報等を参照して、社員端末２００のユーザに対するアクセス情報を確認し、その確認の結果に応じて、サービス要求受信部３１から入力されたアクセス要求信号に応じたアクセス許可を社員端末２００に与えるものである。サービス提供部３６は、「名前」、「社員番号」、「所属部署名」の中で取得できなかった属性情報が１つ以上あることを表す信号を属性情報取得部３５から入力された場合には、社員端末２００の社員に対するアクセス情報の全てを確認できないので、社員端末２００が当該共有フォルダにアクセスすることを許可しない。
【００９０】
これに対して、サービス提供部３６は、属性情報取得部３５から「名前」、「社員番号」、「所属部署名」の３つの属性情報を入力され、且つ該３つの属性情報が当該共有フォルダにアクセスするために適したものである場合には、社員端末２００が該共有フォルダにアクセスすることを許可する。一方、例えば、属性情報取得部３５から「名前」、「社員番号」、「所属部署名」の３つの属性情報を入力されてはいるが、該３つの属性情報が当該共有フォルダにアクセスするために適したものではない場合には、サービス提供部３６は、社員端末２００が該共有フォルダにアクセスすることを許可しない。
【００９１】
続いて、アクセス情報検証システム２により行われる動作（属性情報検証方法）について、図１０を参照しながら説明する。図１０は、アクセス情報検証システム２の動作を示すシーケンス図である。
【００９２】
まず、属性証明書発行装置１０が、図８に示したような属性証明書を社員端末２００用の属性証明書として生成し、通信網４０を介して社員端末２００に発行する（Ｓ２０１）。なお、ステップＳ２０１の動作が行われる前に、社員は「営業部」に配属されたことを仮定する。このため、ステップＳ２０１にて発行された属性証明書の「所属部署名」には「営業部」と記載されている。ステップＳ２０１は、社員端末２００が例えば営業部の共有フォルダにアクセスを要求する前に行われる動作である。以下では、社員端末２００が営業部の共有フォルダにアクセスする際に行われる動作を説明する。
【００９３】
社員端末２００が、通信網４０を介して、営業部の共有フォルダへのアクセス要求信号を営業部の共有フォルダ管理装置に送信する。社員端末２００は、当該アクセス要求信号と共に、ステップＳ２０１にて発行された属性証明書を営業部の共有フォルダ管理装置に送信する（ステップＳ２０２）。
【００９４】
次に、営業部の共有フォルダ管理装置が、通信網５０を介して、有効性検証要求信号をＡＣＲＬ管理装置１２０に送信する。有効性検証要求信号は、ステップＳ２０２にて社員端末２００から受信した属性証明書である（ステップＳ２０３）。
【００９５】
次に、ＡＣＲＬ管理装置１２０が、ステップＳ２０３にて受信した属性証明書及び該属性証明書に含まれた属性情報に対する有効性を検証する。ＡＣＲＬ管理装置１２０は、まずステップＳ２０３にて受信した属性証明書のシリアル番号の「○△番」が記載されたＡＣＲＬを自装置が保持しているか否かを確認する。この動作は、該シリアル番号でＡＣＲＬ格納部１２２内を検索することで行われる。ＡＣＲＬ管理装置１２０はＡＣＲＬ生成処理（後述するステップＳ２１０を参照）をまだ行ってないので、シリアル番号「○△番」が記載されたＡＣＲＬは見つからない。このため、ＡＣＲＬ管理装置１２０は、ステップＳ２０３にて受信したシリアル番号「○△番」の属性証明書は有効であると判断し（ステップＳ２０４）、その旨を表す検証結果信号をＯＣＳＰレスポンスとして営業部の共有フォルダ管理装置に送信する（ステップＳ２０５）。
【００９６】
次に、ステップＳ２０３にてＡＣＲＬ管理装置１２０に送信した属性証明書が有効であることを表す検証結果信号を受信した営業部の共有フォルダ管理装置は、該属性証明書に含まれた属性情報を取得する。営業部の共有フォルダ管理装置は、社員端末２００の社員のアクセス情報として、「名前」、「社員番号」、「所属部署名」の３つの属性情報を読み取る（ステップＳ２０６）。
【００９７】
次に、営業部の共有フォルダ管理装置が、ステップＳ２０６にて読み取った「名前」、「社員番号」、「所属部署名」の３つの属性情報を用いて、社員端末２００の社員に対するアクセス情報を確認する（ステップＳ２０７）。
【００９８】
次に、ステップＳ２０７におけるアクセス情報が該アクセスを許可するために適したものである場合（例えば、「所属部署名」の内容が「営業部」である場合など）に、営業部の共有フォルダ管理装置は、ステップＳ２０２にて受信したアクセス要求信号に応じて、社員端末２００が営業部の共有フォルダへアクセスすることを許可する（ステップＳ２０８）。
【００９９】
以上、社員端末２００の社員が「営業部」に配属され、社員端末２００が提示した属性証明書のアクセス情報が営業部の共有フォルダにアクセスするために適した場合について説明した。一方、以下では、社員端末２００の社員の所属部署が、「営業部」から「総務部」へと変更された場合について説明する。
【０１００】
社員端末２００が、ＡＣＲＬ管理装置１２０に、「所属部署名」の内容を「営業部」から「総務部」へと更新することを依頼する。この動作は、例えば、「総務部」を表す信号を「所属部署名」を表す信号に対応付けてＡＣＲＬ管理装置１２０へ送信することで行われる（ステップＳ２０９）。
【０１０１】
次に、ＡＣＲＬ管理装置１２０が、ステップＳ２０９にて社員端末２００から受信した信号に基づいてＡＣＲＬを生成する。図９は、ステップＳ２０９の依頼に応じてＡＣＲＬ管理装置１２０が生成したＡＣＲＬを示す（ステップＳ２１０）。
【０１０２】
次に、社員端末２００が、通信網４０を介して、総務部の共有フォルダへのアクセス要求信号を総務部の共有フォルダ管理装置に送信する。社員端末２００は、当該アクセス要求信号と共に、ステップＳ２０１にて発行された属性証明書を総務部の共有フォルダ管理装置に送信する（ステップＳ２１１）。
【０１０３】
次に、総務部の共有フォルダ管理装置が、通信網５０を介して、有効性検証要求信号をＡＣＲＬ管理装置１２０に送信する。有効性検証要求信号は、ステップＳ２１１にて社員端末２００から受信した属性証明書である（ステップＳ２１２）。
【０１０４】
次に、ＡＣＲＬ管理装置１２０が、ステップＳ２１２にて受信した属性証明書及び該属性証明書に含まれた属性情報に対する有効性を検証する。ＡＣＲＬ管理装置１２０は、まずステップＳ２１２にて受信した属性証明書のシリアル番号の「○△番」が記載されたＡＣＲＬを自装置が保持しているか否かを確認する。ステップＳ２１０にて、ＡＣＲＬ管理装置１２０はシリアル番号「○△番」を記載したＡＣＲＬを生成したので、該ＡＣＲＬが見つかる。
【０１０５】
ＡＣＲＬ管理装置１２０は、該ＡＣＲＬが見つかったことを理由に、シリアル番号が「○△番」である属性証明書は失効されたものと判断する。一方、ＡＣＲＬ管理装置１２０は、「所属部署名」に対応付けられて「総務部」と記載されていることを理由に、「○△番」の属性証明書に含まれた属性名「所属部署名」の属性情報は、一度失効されたが、後ほど更新されたことによって現時点では有効状態になったと判断する。そして、該更新された内容は「総務部」であると判断する。このことによって、該属性証明書も現時点では有効状態になったと判断される。ＡＣＲＬ管理装置１２０は、該属性証明書が現時点においては有効であるということ、及び「所属部署名」の更新内容は「総務部」であることを表す検証結果信号をＯＣＳＰレスポンスとして総務部の共有フォルダ管理装置に送信する（ステップＳ２１４）。
【０１０６】
次に、ステップＳ２１２にてＡＣＲＬ管理装置１２０に送信した属性証明書が有効であることを表す検証結果信号を受信した総務部の共有フォルダ管理装置は、該属性証明書に含まれた属性情報を取得する。総務部の共有フォルダ管理装置は、社員端末２００の社員のアクセス情報として、「名前」、「社員番号」、「所属部署名」の３つの属性情報を読み取る。「所属部署名」の属性情報を取得する際に、総務部の共有フォルダ管理装置は、属性証明書に記載された内容ではなく、ＡＣＲＬに記載された内容、つまりステップＳ２１４の検証結果信号が表す内容を読み取る（ステップＳ２１５）。
【０１０７】
次に、総務部の共有フォルダ管理装置が、ステップＳ２１５にて読み取った「名前」、「社員番号」、「所属部署名」の３つの属性情報を用いて、社員端末２００の社員に対するアクセス情報を確認する（ステップＳ２１６）。
【０１０８】
次に、ステップＳ２１６におけるアクセス情報が該アクセスを許可するために適したものである場合（例えば、「所属部署名」の内容が「総務部」である場合など）に、総務部の共有フォルダ管理装置は、ステップＳ２１１にて受信したアクセス要求信号に応じて、社員端末２００が総務部の共有フォルダへアクセスすることを許可する（ステップＳ２１７）。
【０１０９】
続いて、第２実施形態の作用及び効果について説明する。第２実施形態によれば、属性証明書に含まれたある属性情報が一度失効されて後で有効に更新された場合、有効な属性証明書に含まれた有効な属性情報を取得するために、例えば属性証明書の本体を失効させる処理、失効された属性情報を該属性証明書から削除する処理、有効となった属性情報を該属性証明書に書き込む処理、及び有効な属性情報のみが記載された新しい属性証明書を再発行する処理等を行わない。これに対して、共有フォルダ管理装置３００は、該失効状態の属性情報の属性名と対応付けられてＡＣＲＬに記載された該有効状態の属性情報を取得する。このため、更新されて有効状態となった属性情報が取得可能であり、該有効状態となった属性情報を該属性証明書に書き込んでからまた新しい属性証明書を再発行するなどの処理を行うために大きな手間がかかることを防止できる。したがって、第２実施形態によれば、上記処理等にかかる負荷を低減して、ユーザの利便性を高めることができる。
【０１１０】
また、第２実施形態によれば、共有フォルダ管理装置３００は、有効性の検証の結果をＡＣＲＬ管理装置１２０から受信することによって、何れの属性証明書が失効状態にあるか、及び何れの属性情報が失効状態にあるかを知ることができる。このため、ＡＣＲＬがその生成元であるＡＣＲＬ管理装置１２０から外部に送出されることなく、共有フォルダ管理装置３００は属性証明書及び属性情報に対する有効性の検証ができる。このため、例えばＡＣＲＬが外部に送出され改竄されること等を防止することができる。
【０１１１】
以上、本発明の好適な実施形態について説明したが、本発明は上記実施形態に限定されないことは言うまでもない。
【０１１２】
例えば、上記実施形態においては、説明を簡略にするために、各装置間でのデータの送受信に際して暗号化することを省略しているが、実際のシステムの構成においては、各装置間で暗号化されたデータが送受信される。この場合には、例えば公開鍵を発行する認証局（ＣＡ）に設置される公開鍵管理装置等を更に設けても良い。
【０１１３】
また、例えば、上記実施形態においては、属性証明書のシリアル番号と、属性情報の属性名と、属性情報が更新された場合にはその内容とを１つのＡＣＲＬにまとめて格納しているが、それぞれを別々のリストとして格納しても良い。このとき、ＡＣＲＬ管理装置１２０は、例えば、失効した属性証明書のリストである本体ＡＣＲＬ、失効した属性情報のリストである部分失効ＡＣＲＬ、更新された属性情報のリストである部分再発行ＡＣＲＬ等をそれぞれ別々に格納することができる。
【０１１４】
また、例えば、上記第２実施形態においては、共有フォルダ管理装置３００は、有効性検証要求信号として属性証明書をＡＣＲＬ管理装置１２０に送信しているが、属性証明書そのものを送信せずに、属性証明書を特定する情報（例えばシリアル番号）及び該属性証明書に含まれた属性情報を特定する情報（例えば属性名）だけを送信するようにしても良い。この場合には、属性証明書が通信網上で送出される回数が少なくなるため、例えば属性証明書が外部装置によって改竄されること等を防止することができる。
【図面の簡単な説明】
【０１１５】
【図１】第１実施形態の課金情報検証システム１の構成概要図である。
【図２】属性証明書発行装置１０等のハードウェア構成図である。
【図３】属性証明書の一例を示す図である。
【図４】ＡＣＲＬの一例を示す図である。
【図５】ユーザ端末２０等のハードウェア構成図である。
【図６】課金情報検証システム１の動作を示すシーケンス図である。
【図７】第２実施形態のアクセス情報検証システム２の構成概要図である。
【図８】属性証明書の一例を示す図である。
【図９】ＡＣＲＬの一例を示す図である。
【図１０】アクセス情報検証システム２の動作を示すシーケンス図である。
【符号の説明】
【０１１６】
１…課金情報検証システム、２…アクセス情報検証システム、１０…属性証明書管理装置、１１０…属性証明書発行装置、１２０…ＡＣＲＬ管理装置、１２１…ＡＣＲＬ生成部、１２２…ＡＣＲＬ格納部、１２３…ＡＣＲＬ要求受信部、１２４…ＡＣＲＬ要求応答部、１２５…有効性検証要求受信部、１２６…第２有効性検証部、１２７…検証結果送信部、２０…ユーザ端末、２００…社員端末、３０…サーバ、３００…共有フォルダ管理装置、３１…サービス要求受信部、３２…ＡＣＲＬ要求部、３３…ＡＣＲＬ受信部、３４…第１有効性検証部、３５…属性情報取得部、３６…サービス提供部、３７…有効性検証要求部、３８…検証結果受信部、４０，５０…通信網。
【図１】
2008011098.tif 000003
【図２】
2008011098.tif 000004
【図３】
2008011098.tif 000005
【図４】
2008011098.tif 000006
【図５】
2008011098.tif 000007
【図６】
2008011098.tif 000008
【図７】
2008011098.tif 000009
【図８】
2008011098.tif 000010
【図９】
2008011098.tif 000011
【図１０】
2008011098.tif 000012