JP2007219665A - アクセス制御システム、アクセス制御方法およびアクセス制御プログラム - Google Patents

Abstract

【課題】Ｗｅｂサイトサーバが外部サーバに対してアクセス不可能な環境であっても、秘密情報を取得した第三者によるアクセスを検出してアクセスを拒否すること。
【解決手段】アクセス要求端末およびアクセス承認端末からアクセス要求およびアクセス承認を受け付けるアクセス制御サーバを構成し、アクセス要求端末からのアクセス要求と、アクセス承認端末からのアクセス承認とが揃ったことを条件としてアクセス要求端末によるアクセスを許可するよう構成する。また、アクセス要求端末とアクセス承認端末との対応付けをおこない、対応付けができたことを条件としてアクセス要求端末によるアクセスを許可するよう構成する。
【選択図】 図１

Description

この発明は、アクセス者によるアクセスを制御するアクセス制御システム、アクセス制御方法およびアクセス制御プログラムに関し、特に、Ｗｅｂサイトサーバが外部サーバに対してアクセス不可能な環境であっても、秘密情報を取得した第三者によるアクセスを検出してアクセスを拒否することができるアクセス制御システム、アクセス制御方法およびアクセス制御プログラムに関する。

近年、インターネットの普及により、個人ユーザがＷｅｂサイトにアクセスする機会が増大している。そして、かかるＷｅｂサイトにおいては、コンテンツ提供をおこなうにあたりユーザの認証と認可というアクセス制御を必要とすることが多々ある。

通常、個人ユーザのアクセス制御は、個人の端末とＷｅｂサイトサーバとの間であらかじめ交換したパスワードや鍵などの秘密情報を用いた認証に基づいておこなわれてきた。しかし、この手法によると、秘密情報が第三者に漏洩した場合にはユーザがＷｅｂサイトに秘密情報の失効を要求するまでの間、正規ユーザになりすました第三者によるＷｅｂサイトへのアクセスを許容してしまう危険性があった。

このため、上記した秘密情報の漏洩があった場合であっても、Ｗｅｂサイトサーバが第三者によるアクセスを検出し、アクセスを拒否する手法が提案されている。

たとえば、非特許文献１には、各ユーザに固有の条件付ＵＲＩ（Uniform Resource Identifier）を払い出しておき、ユーザがこの条件付ＵＲＩを用いてＷｅｂサイトサーバにアクセスすると、正規ユーザのメールアドレスに対してＷｅｂサイトアクセスのためのパスワードを送信する技術が開示されている。この従来技術によれば、条件付ＵＲＩが第三者に漏洩してしまった場合であっても正規ユーザへメールが届くので、正規ユーザはＷｅｂサイトへの秘密情報（条件付ＵＲＩ）の失効要求を迅速におこなうことができ、第三者によるアクセスを早期に防止することが可能となる。

また、非特許文献２には、各ユーザに固有のユーザＩＤを払い出しておき、ユーザがこのユーザＩＤを用いて第一端末（たとえば、パーソナルコンピュータ）からＷｅｂサイトサーバへアクセスすると、正規ユーザの第二端末（たとえば、携帯電話）に対してアクセス確認メールを送信する技術が開示されている。この従来技術によれば、ユーザＩＤが第三者に漏洩してしまった場合であっても正規ユーザの第二端末へメールが届くので、正規ユーザはＷｅｂサイトへの秘密情報（ユーザＩＤ）の失効要求を迅速におこなうことができ、第三者によるアクセスを早期に防止することが可能となる。

佐久間美能留、外３名、「条件付ＵＲＩを利用したユーザ認証方式の提案」、電子情報通信学会２００４年ソサイエティ大会Ｂ−７−５６ 外山将司、外３名、「マルチデバイス方式による認証操作のユーザビリティ向上」、電子情報通信学会２００５年ソサイエティ大会Ｂ−１９−１３

しかしながら、非特許文献１や非特許文献２に開示されている技術を用いた場合には、Ｗｅｂサイトサーバが正規ユーザに対してメールを送信することが必要となる。このように、Ｗｅｂサイトサーバがメールを送信する場合、Ｗｅｂサイトサーバはメールサーバなどの他のサーバに対してアクセスすることになる。しかし、Ｗｅｂサイトサーバが外部のサーバに対して能動的にアクセスすることは、Ｗｅｂサイトサーバからの情報漏えい防止の観点から好ましくない。

また、Ｗｅｂサイト管理者の立場からは、セキュリティポリシー上、外部サーバに対するアクセスを一律に禁止したいというニーズもある。したがって、Ｗｅｂサイトサーバが外部サーバへのアクセスを禁止されている環境においては、Ｗｅｂサイトサーバ側から正規ユーザに対してメールを送信することができず、非特許文献１や非特許文献２の技術を適用することができないという問題があった。

これらのことから、Ｗｅｂサイトサーバが外部サーバに対してアクセス不可能な環境であっても、秘密情報を取得した第三者によるアクセスを検出してアクセスを拒否するアクセス制御手法をいかにして実現するかが大きな課題となっている。

この発明は、上述した従来技術による問題点を解消するためになされたものであって、Ｗｅｂサイトサーバが外部サーバに対してアクセス不可能な環境であっても、秘密情報を取得した第三者によるアクセスを検出してアクセスを拒否することができるアクセス制御システム、アクセス制御方法およびアクセス制御プログラムを提供することを目的とする。

上述した課題を解決し、目的を達成するため、請求項１に係る発明は、アクセス者によるアクセスを制御するアクセス制御システムであって、第一端末からのアクセス要求を受け付けるアクセス要求受付手段と、第二端末からのアクセス承認を受け付けるアクセス承認受付手段と、前記アクセス要求受付手段が前記アクセス要求を受け付け、かつ、前記アクセス承認受付手段が前記アクセス承認を受け付けたことを条件として前記第一端末からのアクセスを許可するアクセス制御手段とを備えたことを特徴とする。

また、請求項２に係る発明は、上記の発明において、前記アクセス制御手段は、前記アクセス要求受付手段が受け付けた前記アクセス要求と前記アクセス承認受付手段が受け付けた前記アクセス承認とが対応することを条件として前記第一端末からのアクセスを許可することを特徴とする。

また、請求項３に係る発明は、上記の発明において、前記第一端末からの前記アクセス要求は、アクセス者を一意に識別するアクセス者識別子を含み、前記第二端末からの前記アクセス承認は、アクセス承認者を一意に識別するアクセス承認者識別子を含み、前記アクセス制御手段は、前記アクセス者識別子と前記アクセス承認者識別子とが対応することを条件として前記第一端末からのアクセスを許可することを特徴とする。

また、請求項４に係る発明は、上記の発明において、前記第一端末からのアクセスを許可するための認証情報を前記第二端末に対して送信する認証情報送信手段と、前記第一端末から前記認証情報を受け付ける認証情報受付手段とをさらに備え、前記アクセス制御手段は、前記認証情報送信手段が前記第二端末に対して送信した前記認証情報を前記認証情報受付手段が前記第一端末から受け付けた場合に、前記アクセス要求と前記アクセス承認とが対応すると判定することを特徴とする。

また、請求項５に係る発明は、上記の発明において、前記認証情報送信手段は、前記第一端末からの前記アクセス要求を受け付けるたびに異なる前記認証情報を生成して当該認証情報を送信することを特徴とする。

また、請求項６に係る発明は、上記の発明において、前記アクセス承認受付手段は、前記第二端末の認証に成功したことを条件として当該第二端末からの前記アクセス承認を受け付けることを特徴とする。

また、請求項７に係る発明は、上記の発明において、前記アクセス承認受付手段は、前記アクセス承認者識別子として前記第二端末を一意に識別する第二端末識別子を用いるものであって、共有秘密情報および／または前記第二端末識別子を用いて前記第二端末の認証をおこなうことを特徴とする。

また、請求項８に係る発明は、上記の発明において、前記アクセス承認受付手段は、前記第二端末との間に通信チャネルを設け、前記通信チャネル上の通信データの暗号化または前記通信チャネル自体のセキュア化をおこなうことを特徴とする。

また、請求項９に係る発明は、上記の発明において、前記アクセス承認受付手段が前記第二端末からの前記アクセス承認を受け付けた後に、当該第二端末に対して前記アクセス承認の内容を確認する承認内容確認手段をさらに備え、前記アクセス制御手段は、前記承認内容確認手段の確認結果に基づいて前記第一端末からのアクセスを制御することを特徴とする。

また、請求項１０に係る発明は、アクセス者によるアクセスを制御するアクセス制御方法であって、第一端末からのアクセス要求を受け付けるアクセス要求受付工程と、第二端末からのアクセス承認を受け付けるアクセス承認受付工程と、前記アクセス要求受付工程が前記アクセス要求を受け付け、かつ、前記アクセス承認受付工程が前記アクセス承認を受け付けたことを条件として前記第一端末からのアクセスを許可するアクセス制御工程とを含んだことを特徴とする。

また、請求項１１に係る発明は、アクセス者によるアクセスを制御するアクセス制御プログラムであって、第一端末からのアクセス要求を受け付けるアクセス要求受付手順と、第二端末からのアクセス承認を受け付けるアクセス承認受付手順と、前記アクセス要求受付手順が前記アクセス要求を受け付け、かつ、前記アクセス承認受付手順が前記アクセス承認を受け付けたことを条件として前記第一端末からのアクセスを許可するアクセス制御手順とをコンピュータに実行させることを特徴とする。

請求項１、１０または１１の発明によれば、第一端末からのアクセス要求を受け付けるとともに、第二端末からのアクセス承認を受け付け、アクセス要求を受け付け、かつ、アクセス承認を受け付けたことを条件として第一端末からのアクセスを許可するよう構成したので、第一端末からのアクセスのみではアクセス制御を受けることができないので第二端末が第三者に乗っ取られない限り、たとえ秘密情報が漏洩した場合であっても第三者に成りすまされる危険性がないという効果を奏する。また、第一端末および第二端末からのアクセスを受け付ける、すなわち、端末側からのアクションをトリガーとしてアクセス制御をおこなうことで、Ｗｅｂサイトサーバはメールサーバなどの外部サーバに対して能動的にアクセスをおこなう必要がない。したがって、Ｗｅｂサイトサーバが外部サーバに対してアクセス不可能な環境であってもアクセス制御を実現することができるという効果を奏する。

また、請求項２の発明によれば、受け付けたアクセス要求とアクセス承認とが対応することを条件として第一端末からのアクセスを許可するよう構成したので、複数の第一端末からアクセスを受け付けた状況であっても、第二端末と対応付けられた第一端末を選択してアクセス制御を実現することができるという効果を奏する。

また、請求項３の発明によれば、第一端末からのアクセス要求は、アクセス者を一意に識別するアクセス者識別子を含み、第二端末からのアクセス承認は、アクセス承認者を一意に識別するアクセス承認者識別子を含み、アクセス者識別子とアクセス承認者識別子とが対応することを条件として第一端末からのアクセスを許可するよう構成したので、第二端末の正当性をアクセス者識別子と対応付けることで担保することができるという効果を奏する。

また、請求項４の発明によれば、第一端末からのアクセスを許可するための認証情報を第二端末に対して送信するとともに、第一端末から認証情報を受け付けることとし、第二端末に対して送信した認証情報を第一端末から受け付けた場合に、アクセス要求とアクセス承認とが対応すると判定するよう構成したので、第二端末から第一端末へと認証情報を流通させることで第一端末と第二端末とを動的に対応付けることができるという効果を奏する。

また、請求項５の発明によれば、第一端末からのアクセス要求を受け付けるたびに異なる認証情報を生成してこの認証情報を送信するよう構成したので、認証情報をワンタイム化することによって盗聴などによる認証情報漏えいの危険性を低減することができるという効果を奏する。

また、請求項６の発明によれば、第二端末の認証に成功したことを条件として第二端末からのアクセス承認を受け付けるよう構成したので、第二端末の認証を適切におこなうことによって第二端末の成りすましを効果的に防止することができるという効果を奏する。

また、請求項７の発明によれば、アクセス承認者識別子として第二端末を一意に識別する第二端末識別子を用いることとし、共有秘密情報および／または第二端末識別子を用いて第二端末の認証をおこなうよう構成したので、第二端末の成りすましを効果的に防止することができるとともに、第二端末における入力の手間を省くことができるという効果を奏する。

また、請求項８の発明によれば、第二端末との間に通信チャネルを設け、通信チャネル上の通信データの暗号化または通信チャネル自体のセキュア化をおこなうよう構成したので、第二端末との間の通信におけるセキュリティ性を向上させることができるという効果を奏する。

また、請求項９の発明によれば、第二端末からのアクセス承認を受け付けた後に、第二端末に対してアクセス承認の内容を確認することとし、この確認結果に基づいて第一端末からのアクセスを制御するよう構成したので、第一端末の属性やアクセス要求の内容に応じた適切なアクセス制御をおこなうことができるという効果を奏する。たとえば、第一端末の発アドレスを第二端末で確認したうえでアクセス制御をおこなったり、第一端末が情報書き込み権限を要求してきた場合に第二端末が権限内容を確認したうえでアクセス制御をおこなったりすることが可能となる。

以下に添付図面を参照して、この発明に係るアクセス制御手法の実施例１〜実施例４を詳細に説明する。なお、各実施例においては、本発明に係るアクセス制御手法を適用したアクセス制御サーバと、一般的なパーソナルコンピュータなどによって構成されるアクセス要求端末（特許請求の範囲に記載の「第一端末」に相当）と、一般的な携帯電話などによって構成されるアクセス承認端末（特許請求の範囲に記載の「第二端末」に相当）とからなるアクセス制御システムについて説明することとする。

また、実施例１においてはアクセス要求端末とアクセス承認端末とが一対一に対応する基本的な構成について、実施例２においてはアクセス承認端末に払い出したパスワードをアクセス要求端末で使用する構成について、実施例３においてはアクセス要求端末とアクセス承認端末とがＮ対一に対応する構成について、実施例４においてはアクセス要求端末とアクセス承認端末とがＮ対Ｍに対応する構成について、それぞれ説明することとする。

各実施例の説明に先だって、まず、本発明に係るアクセス制御手法を適用したアクセス制御システムの特徴について説明しておく。上記したように、本アクセス制御システムは、アクセス制御サーバと、アクセス要求端末と、アクセス承認端末とから構成される。そして、本アクセス制御システムは、アクセス要求端末からのアクセス要求およびアクセス承認端末からのアクセス承認の双方をアクセス制御サーバが「受け付ける」よう構成した点に主な特徴がある。

すなわち、アクセス制御サーバはアクセス要求端末からアクセス要求を受け付けた場合に、従来技術のようにメールサーバなどの外部サーバに対してメール送信を依頼する必要がない。したがって、アクセス制御サーバが外部サーバ（たとえば、メールサーバ）に対してアクセス不可能な環境においてもアクセス制御を実現することができる。

また、アクセス要求端末からのアクセス要求とアクセス承認端末からのアクセス承認とが揃わないとアクセス要求端末からのアクセスを許可しないので、アクセス要求に必要な秘密情報（たとえば、ユーザＩＤ）が第三者に漏洩した場合であっても、正規ユーザのアクセス承認端末が第三者の手に渡らない限り、第三者のアクセスを許容することがない。

また、アクセス制御サーバはアクセス要求端末からのアクセス要求とアクセス承認端末からのアクセス承認との対応付けをおこない、対応付けができたことを条件としてアクセス要求端末からのアクセスを許可するので、複数のアクセス要求端末からアクセス要求があった場合であってもアクセス承認端末と対応付けられたアクセス要求端末を選択してアクセス制御をおこなうことができる。

このように、本発明に係るアクセス制御手法を適用したアクセス制御サーバを用いることとすれば、Ｗｅｂサイトサーバが外部サーバに対してアクセス不可能な環境であっても、秘密情報を取得した第三者によるアクセスを検出してアクセスを拒否することが可能となる。

本実施例１では、アクセス要求端末とアクセス承認端末とが一対一に対応する基本的な構成について、図１〜図１１を用いて説明する。まず、本実施例１に係るアクセス制御システムの構成について図１を用いて説明する。

図１は、実施例１に係るアクセス制御システムの構成を示すブロック図である。同図に示すように、実施例１に係るアクセス制御システムは、アクセス制御サーバ１００と、アクセス要求端末８００と、アクセス承認端末９００とから構成される。なお、アクセス要求端末８００およびアクセス承認端末９００としては一般的なパーソナルコンピュータや携帯電話などの端末装置をそのまま用いることができる。

アクセス制御サーバ１００は、本実施例１の主要部をなす装置であり、アクセス要求受付部１１０と、アクセス制御処理部１２０と、有効リスト１３０と、承認受付部１４０と、ネットワーク通信機能１５０とを備えている。

アクセス要求受付部１１０はアクセス要求端末８００からのアクセス要求を受け付ける処理をおこなう処理部であり、承認受付部１４０はアクセス承認端末９００からのアクセス承認を受け付ける処理をおこなう処理部である。また、アクセス制御処理部１２０はアクセス要求受付部１１０が受け付けたアクセス要求および承認受付部１４０が受け付けたアクセス承認に基づいてアクセス制御をおこなう処理部である。

有効リスト１３０はアクセス者の識別子と、アクセス承認端末９００に固有の個体識別番号と、アクセス制御状態をあらわす有効フラグとを対応付けたリストであり、不揮発性ＲＡＭ（Random Access Memory）やハードディスク装置といった記憶部に格納される。また、ネットワーク通信機能１５０は、インターネットや携帯電話網などのネットワークを介してアクセス要求端末８００およびアクセス承認端末９００と通信をおこなう通信処理部である。

アクセス要求端末８００は、特許請求の範囲に記載の「第一端末」に相当する端末であり、たとえば、Ｗｅｂブラウズ機能を備えた一般的なパーソナルコンピュータで構成される。そして、このアクセス要求端末８００は、Ｗｅｂブラウズ部８１０およびネットワーク通信機能８２０を備えている。Ｗｅｂブラウズ部８１０はアクセス制御サーバ１００に対してリソースの要求・取得をおこなう処理部であり、一般的なＷｅｂブラウザをそのまま用いることができる。また、ネットワーク通信機能８２０はインターネットなどのネットワークを介してアクセス制御サーバ１００と通信をおこなう通信処理部である。

アクセス承認端末９００は、特許請求の範囲に記載の「第二端末」に相当する端末であり、たとえば、一般的な携帯電話で構成される。そして、このアクセス承認端末９００は、個体識別番号記憶部９１０およびネットワーク通信機能９２０を備えている。個体識別番号記憶部９１０はアクセス承認端末９００を一意に識別する識別子である個体識別番号を記憶する記憶部であり、不揮発性ＲＡＭなどの記憶デバイスで構成される。また、ネットワーク通信機能９２０は携帯電話網などのネットワークを介してアクセス制御サーバ１００と通信をおこなう通信処理部である。

図１に示したように、アクセス制御サーバ１００とアクセス要求端末８００とは、インターネットなどのネットワークを経由してＨＴＴＰ（Hyper Text Transfer Protocol）等のプロトコルを用いて相互に通信できるものとする。また、アクセス制御サーバ１００とアクセス承認端末９００とは、携帯電話網などのネットワークを経由して同じくＨＴＴＰ等のプロトコルを用いて相互に通信できるものとする。

次に、図１に示した有効リスト１３０の例について図２を用いて説明する。図２は、図１に示した有効リスト１３０の一例を示す図である。アクセス制御サーバ１００はアクセス者とアクセス承認者とを１対１に対応付けるため、この有効リスト１３０を保持する。

図２に示すように、有効リスト１３０は、ユーザＩＤと、個体識別番号と、有効フラグとを項目として含んだ情報である。ここで、ユーザＩＤはアクセス者を一意に識別する識別子であり、個体識別番号はアクセス承認端末９００を一意に識別する端末固有の識別子である。そして、ユーザＩＤと個体識別番号とからなる対はあらかじめ登録されているものとする。

また、有効フラグはアクセス者のアクセス制御状態をあらわすフラグであり、たとえば、「１」であればアクセス許可中、「０」であればアクセス不許可中という状態をそれぞれあらわす。

次に、実施例１に係るアクセス制御処理の処理手順について図３を用いて説明する。図３は、実施例１に係るアクセス制御処理の処理手順を示すシーケンス図である。同図に示すように、まず、アクセス承認端末９００はアクセス制御サーバ１００に対して個体識別番号「Ｕ」を含んだ承認通知メッセージを送信する（ステップＳ１１０）。なお、ステップＳ１１０において送信される承認通知メッセージはＨＴＴＰ要求メッセージとして送信されるものとする。

ここで、ステップＳ１１０において用いられる画面例について図４を用いて説明しておく。図４は、アクセス承認端末９００に表示される承認通知画面の一例を示す図である。同図に示すように、アクセス承認端末９００には承認を促すメッセージと個体識別番号送信ボタンとが表示される。そして、承認者が図４に示した「個体識別番号送信」ボタンを押下すると、承認通知メッセージがアクセス制御サーバ１００に対して送信されることになる。

図３の説明に戻ってアクセス制御処理の処理手順について説明をつづける。アクセス承認端末９００から承認通知を受け取ったアクセス制御サーバ１００は承認処理を実行する（ステップＳ１２０）。ここで、この承認処理の詳細な処理手順について図５を用いて説明しておく。図５は、図３に示した承認処理の処理手順を示すフローチャートである。同図に示すように、アクセス制御サーバ１００はアクセス承認端末９００から受け付けた個体識別番号が有効リスト１３０に登録されているか否かを判定する（ステップＳ１２１）。

そして、登録されている場合には（ステップＳ１２１，Ｙｅｓ）有効リスト１３０における対応する行の有効フラグを「１」に設定し（ステップＳ１２２）、承認成功として処理を終了する。一方、登録されていない場合には（ステップＳ１２１，Ｎｏ）承認失敗として処理を終了する。

図３の説明に戻ってアクセス制御処理の処理手順について説明をつづける。承認処理（ステップＳ１２０）を実行したアクセス制御サーバ１００はアクセス承認端末９００に対して承認結果を通知する（ステップＳ１３０）。この承認結果通知はＨＴＴＰ応答メッセージとして送信され、承認の成功／失敗という結果を含むものとする。

ここで、ステップＳ１３０において用いられる画面例について図６を用いて説明しておく。図６は、アクセス承認端末９００に表示される承認通知画面の一例を示す図である。同図に示すように、アクセス承認端末９００には承認結果および承認解除の手順を示すメッセージと承認解除ボタンとが表示される。そして、承認者が図６に示した「承認解除」ボタンを押下すると、承認解除要求メッセージがアクセス制御サーバ１００に対して送信されることになる（ステップＳ１７０参照）。

図３の説明に戻ってアクセス制御処理の処理手順について説明をつづける。アクセス者がアクセス制御サーバ１００へアクセスしようとする場合、アクセス者によって操作されたアクセス要求端末８００はアクセス制御サーバ１００に対してユーザＩＤを含んだアクセス要求をおこなう（ステップＳ１４０）。

ここで、ステップＳ１４０において用いられる画面例について図７を用いて説明しておく。図７は、アクセス要求端末８００に表示されるアクセス要求画面の一例を示す図である。同図に示すように、アクセス要求端末８００にはユーザＩＤの入力エリア、送信ボタン、キャンセルボタンおよびアクセス承認端末９００からの個体識別番号送信が必要である旨のメッセージが表示される。アクセス者が入力エリアにユーザＩＤを入力して「送信」ボタンを押下すると、ユーザＩＤがアクセス制御サーバ１００に対して送信されることになる。

図３の説明に戻ってアクセス制御処理の処理手順について説明をつづける。アクセス要求端末８００からユーザＩＤを受け取ったアクセス制御サーバ１００はアクセス制御処理を実行する（ステップＳ１５０）。ここで、このアクセス制御処理の詳細な処理手順について図８を用いて説明しておく。図８は、図３に示したアクセス制御処理の処理手順を示すフローチャートである。

図８に示すように、アクセス要求端末８００からユーザＩＤを受け取ったアクセス制御サーバ１００は、受け取ったユーザＩＤが有効リスト１３０に登録されており、かつ、対応する有効フラグが「１」であるか否かを判定する（ステップＳ１３１）。そして、ステップＳ１３１の判定条件を満たした場合には（ステップＳ１３１，Ｙｅｓ）、アクセス制御成功として処理を終了する。一方、ステップＳ１３１の判定条件を満たさない場合には（ステップＳ１３１，Ｎｏ）、アクセス制御失敗として処理を終了する。

図３の説明に戻ってアクセス制御処理の処理手順について説明をつづける。アクセス制御処理（ステップＳ１５０）を実行したアクセス制御サーバ１００は、アクセス制御処理の判定結果をアクセス要求端末８００に対して通知する（ステップＳ１６０）。

ここで、ステップＳ１６０において用いられる画面例について図９を用いて説明しておく。図９は、アクセス要求端末８００に表示されるアクセス制御結果画面の一例を示す図である。同図に示すように、アクセス要求端末８００には認証結果が表示される。そして、認証を許可する旨の結果である場合（図９の場合）には、サービス提供画面へのリンク情報が表示され、アクセス者はこのリンクをたどることによってサービス提供を受けることができるようになる。

図３の説明に戻ってアクセス制御処理の処理手順について説明をつづける。図６において既に説明したように、アクセス承認者はいったん与えた承認を解除することも可能である。そこで、以下では、この承認解除の処理手順について説明することとする。承認者が図６に示した「承認解除」ボタンを押下すると、個体識別番号「Ｕ」を含んだ承認解除要求メッセージがアクセス制御サーバ１００に対して送信される（ステップＳ１７０）。

つづいて、承認解除要求メッセージを受け付けたアクセス制御サーバ１００は、承認解除処理を実行する（ステップＳ１８０）。ここで、この承認解除処理の詳細な処理手順について図１０を用いて説明する。図１０は、図３に示した承認解除処理の処理手順を示すフローチャートである。

図１０に示すように、アクセス承認端末９００から個体識別番号「Ｕ」を含んだ承認解除要求メッセージを受け付けたアクセス制御サーバ１００は、この個体識別番号「Ｕ」が有効リスト１３０に登録されているか否かを判定する（ステップＳ１８１）。そして、有効リスト１３０に登録されている場合には（ステップＳ１８１，Ｙｅｓ）、有効リスト１３０における対応する行の有効フラグを「０」に設定し（ステップＳ１８２）、承認解除成功として処理を終了する。一方、個体識別番号が有効リスト１３０に登録されていない場合には（ステップＳ１８１，Ｎｏ）、承認解除失敗として処理を終了する。

つづいて、承認解除処理（ステップＳ１８０）を実行したアクセス制御サーバ１００は、アクセス承認端末９００に対して承認解除結果を通知する（ステップＳ１９０）。この承認結果通知はＨＴＴＰ応答メッセージとして送信され、承認解除の成功／失敗という結果を含むものとする。

ここで、ステップＳ１９０において用いられる画面例について図１１を用いて説明する。図１１は、アクセス承認端末９００に表示される承認解除結果画面の一例を示す図である。同図に示すようにアクセス承認端末９００には承認解除の結果が表示される。

上述したように、本実施例１によれば、アクセス承認端末からあらかじめ承認通知を受け付けているという条件の下でアクセス者のアクセス制御処理をおこなうことができる。また、アクセス承認端末の正当性を個体識別番号によって確認することで、アクセス承認端末の利用者は承認のための情報を入力する必要がないので、入力の手間を省きつつアクセス承認端末のなりすましを効果的に防止することができる。

なお、上記した実施例１では、アクセス承認端末から個体識別番号を受け付ける場合について示したが、個体識別番号のかわりにアクセス承認端末の発アドレスを用いたり、アクセス承認端末から承認用パスワードなどの秘密情報を受け付けたりするよう構成することもできる。

また、上記した実施例１では、サーバ側が有効リストを保持し、この有効リストを用いることによってアクセス者とアクセス承認端末との対応付けをおこなう場合について示したが、アクセス要求がアクセス承認端末の識別子を含み、サーバ側ではアクセス要求に含まれるアクセス承認端末の識別子がアクセス承認端末と対応していることを条件としてアクセス制御をおこなうこととしてもよい。たとえば、サーバがユーザＩＤと個体識別番号とを鍵によって含むアクセスコードをあらかじめアクセス者に払い出しておき、アクセス要求受け付けの際に鍵によってアクセスコードからユーザＩＤと個体識別番号を取り出して対応関係をとるよう構成することもできる。

本実施例２では、アクセス承認端末に払い出したパスワードをアクセス要求端末で使用する構成について、図１２〜図２２を用いて説明する。まず、本実施例２に係るアクセス制御システムの構成について図１２を用いて説明する。

図１２は、実施例２に係るアクセス制御システムの構成を示すブロック図である。同図に示すように、実施例２に係るアクセス制御システムは、アクセス制御サーバ２００と、アクセス要求端末８００と、アクセス承認端末９００とから構成される。なお、アクセス要求端末８００およびアクセス承認端末９００は、実施例１と同様であるので詳細な説明を省略することとする。

アクセス制御サーバ２００は、アクセス要求受付部２１０と、パスワード生成部２２０と、認証情報通知部２３０と、パスワードテーブル２４０と、アクセス制御処理部２５０と、ネットワーク通信機能２６０とを備えている。

アクセス要求受付部２１０はアクセス要求端末８００からのアクセス要求を受け付ける処理をおこなう処理部である。また、パスワード生成部２２０は、アクセス要求受付部２１０が受け付けたアクセス要求に基づいてワンタイムパスワードを生成する処理をおこなう処理部である。

認証情報通知部２３０は、アクセス承認端末９００からのアクセスを受け付けるとともに、パスワード生成部２２０が生成したワンタイムパスワードをアクセス承認端末９００に対して通知する処理をおこなう処理部である。また、パスワードテーブル２４０は、パスワード生成部２２０が生成したワンタイムパスワードを一時的に保持するためのテーブルであり、不揮発性ＲＡＭ（Random Access Memory）やハードディスク装置といった記憶部に格納される。

アクセス制御処理部２５０は、アクセス要求端末８００からパスワードを受け付け、受け付けたパスワードとパスワードテーブル２４０に一時的に記憶されているパスワードとを対比することによって検証し、アクセス要求端末８００のアクセス制御をおこなう処理部である。また、ネットワーク通信機能２６０は、インターネットや携帯電話網などのネットワークを介してアクセス要求端末８００およびアクセス承認端末９００と通信をおこなう通信処理部である。

図１２に示したように、アクセス制御サーバ２００とアクセス要求端末８００とは、インターネットなどのネットワークを経由してＨＴＴＰ（Hyper Text Transfer Protocol）等のプロトコルを用いて相互に通信できるものとする。また、アクセス制御サーバ２００とアクセス承認端末９００とは、携帯電話網などのネットワークを経由して同じくＨＴＴＰ等のプロトコルを用いて相互に通信できるものとする。

次に、図１２に示したパスワードテーブル２４０の例について図１３を用いて説明する。図１３は、図１２に示したパスワードテーブル２４０の一例を示す図である。アクセス制御サーバ２００はアクセス者とアクセス承認者とを１対１に対応付け、さらに、パスワード生成部２２０が生成したワンタイムパスワードを一時的に記憶するために、このパスワードテーブル２４０を保持する。

図１３に示すように、パスワードテーブル２４０は、ユーザＩＤと、個体識別番号と、セッションＩＤと、パスワードとを項目として含んだ情報である。ここで、ユーザＩＤはアクセス者を一意に識別する識別子であり、個体識別番号はアクセス承認端末９００を一意に識別する端末固有の識別子である。そして、パスワードはパスワード生成部２２０が生成したワンタイムパスワードであり、セッションＩＤは各セッションを一意に識別する識別子である。なお、ユーザＩＤと個体識別番号とはあらかじめ登録されているものとする。

次に、実施例２に係るアクセス制御処理の処理手順について図１４を用いて説明する。図１４は、実施例２に係るアクセス制御処理の処理手順を示すシーケンス図である。同図に示すように、アクセス者がアクセス制御サーバ２００へアクセスしようとする場合、アクセス者によって操作されたアクセス要求端末８００はアクセス制御サーバ２００に対してユーザＩＤを含んだアクセス要求をおこなう（ステップＳ２１０）。

ここで、ステップＳ２１０において用いられる画面例について図１５を用いて説明しておく。図１５は、アクセス要求端末８００に表示されるアクセス要求画面の一例を示す図である。同図に示すように、アクセス要求端末８００にはユーザＩＤの入力エリア、送信ボタンおよびキャンセルボタンが表示される。アクセス者が入力エリアにユーザＩＤを入力して「送信」ボタンを押下すると、ユーザＩＤがアクセス制御サーバ２００に対して送信されることになる。

図１４の説明に戻ってアクセス制御処理の処理手順について説明をつづける。アクセス要求端末８００からユーザＩＤを受け取ったアクセス制御サーバ２００はセッションＩＤ生成処理を実行する（ステップＳ２２０）。ここで、このセッションＩＤ生成処理の詳細な処理手順について図１６を用いて説明しておく。図１６は、図１４に示したセッションＩＤ生成処理の処理手順を示すフローチャートである。

図１６に示すように、アクセス要求端末８００からユーザＩＤを受け取ったアクセス制御サーバ２００は、受け取ったユーザＩＤがパスワードテーブル２４０に登録されているか否かを判定する（ステップＳ２２１）。そして、受け取ったユーザＩＤがパスワードテーブル２４０に登録されている場合には（ステップＳ２２１，Ｙｅｓ）、たとえば１０桁の乱数としてセッションＩＤを生成し（ステップＳ２２２）、生成したセッションＩＤをユーザＩＤと対応付けてパスワードテーブル２４０に登録する（ステップＳ２２３）。そして、セッションＩＤ生成成功として処理を終了する。

一方、ステップＳ２２１において受け取ったユーザＩＤがパスワードテーブル２４０に登録されていないと判定された場合には（ステップＳ２２１，Ｎｏ）、セッションＩＤ生成失敗として処理を終了する。

図１４の説明に戻ってアクセス制御処理の処理手順について説明をつづける。セッションＩＤ生成処理（ステップＳ２２０）を実行したアクセス制御サーバ２００は、アクセス要求端末８００に対してセッションＩＤ生成結果を通知するとともにパスワード入力を促す画面を表示する（ステップＳ２３０）。ここで、ステップＳ２３０において用いられる画面例について図１７を用いて説明しておく。図１７は、アクセス要求端末８００に表示されるパスワード入力画面の一例を示す図である。

図１７に示すように、アクセス要求端末８００には、アクセスを正常に受け付けてアクセス承認端末９００に対してパスワードを送信する旨のメッセージ、パスワードの入力エリア、送信ボタンおよびキャンセルボタンが表示される。なお、アクセス者がアクセス承認端末９００に送信されたパスワードを入力エリアに入力して「送信」ボタンを押下するとこのパスワードおよびセッションＩＤがアクセス制御サーバ２００に対して送信されることになる。

図１４の説明に戻ってアクセス制御処理の処理手順について説明をつづける。アクセス承認端末９００は自端末の認証を要求するためにアクセス制御サーバ２００に対して認証要求メッセージを送信する（ステップＳ２４０）。なお、この認証要求メッセージにはアクセス承認端末９００を一意に識別する個体識別番号「Ｕ」が含まれる。ここで、ステップＳ２４０において用いられる画面例について図１８を用いて説明しておく。図１８は、アクセス承認端末９００に表示される認証要求画面の一例を示す図である。

図１８に示すように、アクセス承認端末９００には認証要求をおこなう旨のメッセージと個体識別番号送信ボタンとが表示される。そして、承認者が図１８に示した「個体識別番号送信」ボタンを押下すると、認証要求メッセージがアクセス制御サーバ２００に対して送信されることになる。

図１４の説明に戻ってアクセス制御処理の処理手順について説明をつづける。アクセス承認端末９００からの認証要求を受け付けたアクセス制御サーバ２００は、パスワード生成処理を実行する（ステップＳ２５０）。ここで、このパスワード生成処理の詳細な処理手順について図１９を用いて説明しておく。図１９は、図１４に示したパスワード生成処理の処理手順を示すフローチャートである。

図１９に示すように、アクセス承認端末から個体識別番号を含んだ認証要求を受け付けたアクセス制御サーバ２００は、受け付けた個体識別番号がパスワードテーブル２４０に登録されており、かつ、対応するセッションＩＤが登録されているか否かを判定する（ステップＳ２５１）。

そして、ステップＳ２５１の判定条件を満たした場合には（ステップＳ２５１，Ｙｅｓ）、たとえば４桁の乱数としてパスワードを生成し（ステップＳ２５２）、生成したパスワードを個体識別番号と対応付けてパスワードテーブル２４０に登録する（ステップＳ２５３）。そして、パスワード生成成功として処理を終了する。一方、ステップＳ２５１の判定条件を満たさない場合には（ステップＳ２５１，Ｎｏ）、パスワード生成失敗として処理を終了する。

図１４の説明に戻ってアクセス制御処理の処理手順について説明をつづける。パスワード生成処理を実行したアクセス制御サーバ２００は、パスワード生成結果通知メッセージをアクセス承認端末９００に対して送信する（ステップＳ２６０）。なお、このパスワード生成結果通知メッセージはＨＴＴＰ要求メッセージとして送信される。

ここで、ステップＳ２６０において用いられる画面例について図２０を用いて説明する。図２０は、アクセス承認端末９００に表示されるパスワード生成結果通知画面の一例を示す図である。同図に示すように、アクセス承認端末９００には、認証を完了した旨のメッセージおよびアクセス要求端末８００がアクセス制御サーバ２００にアクセスする際に用いるパスワードが表示される。

図１４の説明に戻ってアクセス制御処理の処理手順について説明をつづける。図１４のステップＳ２７０に示したように、アクセス承認者はアクセス者に対してステップＳ２６０で通知されたパスワードを通知する。このパスワード通知は、たとえば、アクセス承認者からアクセス者に対して口頭でおこなわれる。なお、パスワード通知を電話やメールなどの通信手段でおこなうこととしてもよい。また、アクセス承認端末９００からアクセス要求端末８００に対して有線あるいは無線のデータ通信をおこなうことによってかかるパスワードを通知することとしてもよい。

つづいて、ステップＳ２７０でパスワードを通知されたアクセス者が、通知されたパスワードを図１７に示したパスワード入力画面のパスワード入力エリアに入力して送信ボタンを押下すると、パスワードおよびセッションＩＤを含んだメッセージがアクセス制御サーバ２００に対して送信される（ステップＳ２８０）。

そして、ステップＳ２８０のメッセージを受け付けたアクセス制御サーバ２００は、アクセス制御処理を実行する（ステップＳ２９０）。ここで、このアクセス制御処理の詳細な処理手順について図２１を用いて説明しておく。同図に示すように、ステップＳ２８０のメッセージを受け付けたアクセス制御サーバ２００は、メッセージに含まれるセッションＩＤおよびパスワードが対応付けられてパスワードテーブル２４０に登録されているか否かを判定する（ステップＳ２９１）。

そして、セッションＩＤおよびパスワードが対応付けられてパスワードテーブルに登録されている場合には（ステップＳ２９１，Ｙｅｓ）、アクセス制御成功として処理を終了する。一方、ステップＳ２９１の判定条件を満たさない場合には（ステップＳ２９１，Ｎｏ）、アクセス制御失敗として処理を終了する。

図１４の説明に戻ってアクセス制御処理の処理手順について説明をつづける。アクセス制御処理を実行したアクセス制御サーバ２００は、アクセス制御結果をアクセス要求端末８００に対して通知する（ステップＳ２９５）。ここで、ステップＳ２９５において用いられる画面例について図２２を用いて説明する。図２２は、アクセス要求端末８００に表示されるアクセス制御結果画面の一例を示す図である。

図２２に示すように、アクセス要求端末８００にはアクセス要求端末８００には認証結果が表示される。そして、認証を許可する旨の結果である場合（図２２の場合）には、サービス提供画面へのリンク情報が表示され、アクセス者はこのリンクをたどることによってサービス提供を受けることができるようになる。

上述したように、本実施例２によれば、アクセス承認端末からあらかじめ承認通知を受け付けているという条件の下でアクセス者のアクセス制御処理をおこなうことができる。また、アクセス承認端末に対して認証情報（たとえば、パスワード）を通知し、承認者からアクセス者へ認証情報を流通させることによって、アクセス承認端末とアクセス要求端末とを動的に対応付けてアクセス制御をおこなうことが可能となる。

したがって、アクセス承認端末を所持する承認者が所望するタイミングで所望するアクセス者にアクセス権限を与えることができる。また、認証情報をワンタイム化することによって認証情報漏洩による成りすましを効果的に防止することができる。

なお、上記した実施例２では、アクセス承認端末から個体識別番号を受け付ける場合について示したが、個体識別番号のかわりにアクセス承認端末の発アドレスを用いたり、アクセス承認端末から承認用パスワードなどの秘密情報を受け付けたりするよう構成することもできる。

また、上記した実施例２では、サーバ側がパスワードテーブルを保持し、このパスワードテーブルを用いることによってアクセス者とアクセス承認端末との対応付けをおこなう場合について示したが、アクセス要求がアクセス承認端末の識別子を含み、サーバ側ではアクセス要求に含まれるアクセス承認端末の識別子がアクセス承認端末と対応していることを条件としてアクセス制御をおこなうこととしてもよい。たとえば、サーバがユーザＩＤと個体識別番号とを鍵によって含むアクセスコードをあらかじめアクセス者に払い出しておき、アクセス要求受け付けの際に鍵によってアクセスコードからユーザＩＤと個体識別番号を取り出して対応関係をとるよう構成することもできる。

本実施例３では、アクセス要求端末とアクセス承認端末とがＮ対一に対応する構成について、図２３〜図３７を用いて説明する。まず、本実施例３に係るアクセス制御システムの構成について図２３を用いて説明する。

図２３は、実施例３に係るアクセス制御システムの構成を示すブロック図である。同図に示すように、実施例３に係るアクセス制御システムは、アクセス制御サーバ３００と、複数台のアクセス要求端末８００と、アクセス承認端末９００とから構成される。なお、アクセス要求端末８００およびアクセス承認端末９００は、実施例１と同様であるので詳細な説明を省略することとする。

アクセス制御サーバ３００は、本実施例３の主要部をなす装置であり、アクセス要求受付部３１０と、アクセス制御処理部３２０と、アクセスリスト３３０と、承認受付部３４０と、ネットワーク通信機能３５０とを備えている。

アクセス要求受付部３１０はアクセス要求端末８００からのアクセス要求を受け付ける処理をおこなう処理部であり、承認受付部３４０はアクセス承認端末９００からのアクセス承認を受け付ける処理をおこなう処理部である。また、アクセス制御処理部３２０はアクセス要求受付部３１０が受け付けたアクセス要求および承認受付部３４０が受け付けたアクセス承認に基づいてアクセス制御をおこなう処理部である。

アクセスリスト３３０はアクセス者の識別子と、アクセス承認端末９００に固有の個体識別番号と、アクセス者のアクセス要求状態をあらわすアクセスフラグと、アクセス制御状態をあらわす有効フラグとを対応付けたリストであり、不揮発性ＲＡＭ（Random Access Memory）やハードディスク装置といった記憶部に格納される。また、ネットワーク通信機能３５０は、インターネットや携帯電話網などのネットワークを介してアクセス要求端末８００およびアクセス承認端末９００と通信をおこなう通信処理部である。

図２３に示したように、アクセス制御サーバ３００とアクセス要求端末８００とは、インターネットなどのネットワークを経由してＨＴＴＰ（Hyper Text Transfer Protocol）等のプロトコルを用いて相互に通信できるものとする。また、アクセス制御サーバ３００とアクセス承認端末９００とは、携帯電話網などのネットワークを経由して同じくＨＴＴＰ等のプロトコルを用いて相互に通信できるものとする。

次に、図２３に示したアクセスリスト３３０の例について図２４を用いて説明する。図４は、図２３に示したアクセスリスト３３０の一例を示す図である。アクセス制御サーバ３００はアクセス者とアクセス承認者とを対応付けるため、このアクセスリスト３３０を保持する。

図２３に示すように、アクセスリスト３３０は、ユーザＩＤと、個体識別番号と、アクセスフラグと、有効フラグとを項目として含んだ情報である。ここで、ユーザＩＤはアクセス者を一意に識別する識別子であり、個体識別番号はアクセス承認端末９００を一意に識別する端末固有の識別子である。そして、ユーザＩＤと個体識別番号とからなる対はあらかじめ登録されているものとする。なお、実施例１とは異なり、ユーザＩＤと個体識別番号とは１対１に対応する必要はなく複数のユーザＩＤが同一の個体識別番号と対応していてもよいものとする。

また、アクセスフラグはアクセス者のアクセス要求状態をあらわすフラグであり、たとえば、「１」であればアクセス要求を受けて付けている状態を、「０」であればアクセス要求を受け付けていない状態をそれぞれあらわしている。なお、有効フラグは、実施例１と同様に、アクセス者のアクセス制御状態をあらわすフラグであり、たとえば、「１」であればアクセス許可中、「０」であればアクセス不許可中という状態をそれぞれあらわす。

次に、実施例３に係るアクセス制御処理の処理手順について図２５を用いて説明する。図２５は、実施例３に係るアクセス制御処理の処理手順を示すシーケンス図である。同図に示すように、アクセス者はアクセス要求端末８００を操作することによってアクセス制御サーバ３００にアクセスし、図２６に示すアクセス要求画面にユーザＩＤを入力したうえで送信ボタンを押下してアクセス制御サーバ３００へユーザＩＤを送信する（ステップＳ３１０）。

つづいて、アクセス制御サーバ３００はアクセス要求受付処理を実行する（ステップＳ３２０）。図２７に示すように、アクセス制御サーバ３００はアクセス要求端末８００から受け取ったユーザＩＤがアクセスリスト３３０に登録されているか否かを判定し（ステップＳ３２１）、登録されている場合には（ステップＳ３２１，Ｙｅｓ）、アクセスリストのユーザＩＤに対応するアクセスフラグを１に設定し（ステップＳ３２２）、受け付け成功として処理を終了する。一方、ステップＳ３２１の判定条件を満たさない場合には（ステップＳ３２１，Ｎｏ）、受付失敗として処理を終了する。

そして、アクセス制御サーバ３００は、アクセス要求端末８００に対して受付結果を通知し（ステップＳ３３０）、受付成功の場合については承認待ちを指示するとともに、追って承認状況を確認することを促す。なお、ステップＳ３３０において用いられるアクセス制御待ち画面の例については図２８に示している。

つづいて、アクセス認証端末９００がアクセス制御サーバ３００に対して認証要求メッセージを送信する（ステップＳ３４０）。なお、この認証要求メッセージは個体識別番号「Ｕ」を含むものとする。また、ステップＳ３４０において用いられる認証要求送信画面の例については図２９に示している。

そして、認証要求メッセージを受け付けたアクセス制御サーバ３００はアクセス承認端末認証処理を実行する（ステップＳ３５０）。図３０に示すように、アクセス制御サーバ３００は、アクセス承認端末９００から受け付けた個体識別番号に対応する行がアクセスリスト３３０に１つ以上存在するか否かを判定し（ステップＳ３５１）、存在しない場合には（ステップＳ３５１，Ｎｏ）認証失敗として処理を終了する。一方、存在する場合には（ステップＳ３５１，Ｙｅｓ）、アクセスリスト３３０の個体識別番号に対応した行のうち、アクセスフラグが１、かつ、有効フラグが０に設定された行のユーザＩＤをアクセス待ちリストとして抽出し（ステップＳ３５２）、認証成功として処理を終了する。

つづいて、アクセス制御サーバ３００は、アクセス承認端末９００に対してアクセス制御結果およびアクセス待ちリストを通知する（ステップＳ３６０）。なお、ステップＳ３６０において用いられる認証結果通知画面の例については図３１に示している。

アクセス制御結果およびアクセス待ちリストを通知されたアクセス承認端末９００では、アクセス承認者が表示されたアクセス待ちリストの中からアクセスを承認する相手を選択し、選択結果をアクセス制御サーバ３００に対して送信する（ステップＳ３７０）。

アクセス承認端末９００から選択結果を通知されたアクセス制御サーバ３００は、承認処理を実行する（ステップＳ３８０）。図３２に示すように、チェック（選択）されたユーザＩＤのリストを受け取ったアクセス制御サーバ３００は、チェックされたユーザＩＤが１つ以上存在するか否かを判定する（ステップＳ３８１）。そして、チェックされたユーザＩＤがない場合には（ステップＳ３８１，Ｎｏ）、承認結果を未承認として処理を終了する。一方、チェックされたユーザＩＤが１つ以上存在する場合には（ステップＳ３８１，Ｙｅｓ）、アクセスリスト３３０の該当するユーザＩＤを含む行の有効フラグを１に設定し（ステップＳ３８２）、承認結果を承認として処理を終了する。

つづいて、アクセス制御サーバ３００は、アクセス承認端末９００に対して承認結果を通知する（ステップＳ３９０）。なお、ステップＳ３９０において用いられる承認結果通知画面の例については図３３に示している。図３３に示すように、アクセス承認者は、表示されたアクセス待ちリストから、さらに、承認相手を選択してアクセス制御サーバ３００に送信したり、いったん承認済みとしたアクセス者の承認を解除したりすることができる。

また、アクセス要求端末８００は、アクセス承認端末９００による承認が完了してアクセスが許可された否かを確認するために、図２８に示した承認状況確認のためのリンクをたどることによって、アクセス制御サーバ３００に対してユーザＩＤを含んだアクセス制御確認を送信する（ステップＳ４００）。

このアクセス制御確認を受け付けたアクセス制御サーバ３００は、アクセス許可判定処理を実行する（ステップＳ４１０）。図３４に示すように、アクセス制御サーバ３００は、アクセス要求端末８００から受け付けたユーザＩＤがアクセスリスト３３０に登録されているか否かを判定する（ステップＳ４１１）。そして、受け付けたユーザＩＤがアクセスリスト３３０に登録されていない場合には（ステップＳ４１１，Ｎｏ）、アクセス不許可として処理を終了する。一方、受け付けたユーザＩＤがアクセスリスト３３０に登録されている場合には（ステップＳ４１１，Ｙｅｓ）、受け付けたユーザＩＤに対応するアクセスリスト３３０の行における有効フラグが１に設定されているか否かを判定する（ステップＳ４１２）。

そして、かかるユーザＩＤに対応する有効フラグが１に設定されていない場合には（ステップＳ４１２，Ｎｏ）、アクセス不許可として処理を終了する。一方、有効フラグが１に設定されている場合には（ステップＳ４１２，Ｙｅｓ）、アクセス許可として処理を終了する。

つづいて、アクセス制御サーバ３００は、アクセス要求端末８００に対してアクセス許可結果を通知する（ステップＳ４２０）。なお、ステップＳ４２０において用いられるアクセス許可結果画面の例については図３５に示している。

ところで、アクセス承認者は、いったん与えた承認を解除することも可能である。以下では、この承認解除手順について説明する。アクセス承認者は図３３に示した承認結果通知画面に表示された承認解除送信ボタンを押下すると、アクセス承認端末９００は、個体識別番号を含んだ承認解除要求をアクセス制御サーバ３３０に対して送信する（ステップＳ４３０）。

この承認解除要求を受け付けたアクセス制御サーバ３００は、承認解除処理を実行する（ステップＳ４４０）。図３６に示すように、アクセス制御サーバ３００は、アクセス承認端末９００から受け付けた個体識別番号がアクセスリスト３３０に登録されているか否かを判定する（ステップＳ４４１）。そして、受け付けた個体識別番号がアクセスリスト３３０に登録されていない場合には（ステップＳ４４１，Ｎｏ）、承認解除失敗として処理を終了する。一方、アクセスリスト３３０に登録されている場合には（ステップＳ４４１，Ｙｅｓ）、該当するエントリ（行）すべてについて有効フラグを０に設定し（ステップＳ４４２）、承認解除成功として処理を終了する。

つづいて、アクセス制御サーバ３００は、アクセス承認端末９００に対して承認解除結果を通知する（ステップＳ４５０）。なお、この承認解除結果には承認解除成功／失敗の旨が含まれるものとする。また、ステップＳ４５０において用いられる承認解除結果通知画面の例については図３７に示している。

上述したように、本実施例３によれば、アクセス承認端末からあらかじめ承認通知を受け付けているという条件の下でアクセス者のアクセス制御処理をおこなうことができる。また、アクセス承認端末の正当性を個体識別番号によって確認することで、アクセス承認端末の利用者は承認のための情報を入力する必要がないので、入力の手間を省きつつアクセス承認端末のなりすましを効果的に防止することができる。

さらに、アクセス承認端末への問合わせ課程を含んだアクセス制御をおこなうことにより、複数のアクセス要求端末がアクセスしてきている場合であっても、各アクセス要求端末の属性やアクセス要求の内容に応じた適切なアクセス制御をおこなうことが可能である。

なお、上記した実施例３では、アクセス承認端末から個体識別番号を受け付ける場合について示したが、個体識別番号のかわりにアクセス承認端末の発アドレスを用いたり、アクセス承認端末から承認用パスワードなどの秘密情報を受け付けたりするよう構成することもできる。

また、上記した実施例３では、サーバ側がアクセスリストを保持し、このアクセスリストを用いることによってアクセス者とアクセス承認端末との対応付けをおこなう場合について示したが、アクセス要求がアクセス承認端末の識別子を含み、サーバ側ではアクセス要求に含まれるアクセス承認端末の識別子がアクセス承認端末と対応していることを条件としてアクセス制御をおこなうこととしてもよい。たとえば、サーバがユーザＩＤと個体識別番号とを鍵によって含むアクセスコードをあらかじめアクセス者に払い出しておき、アクセス要求受け付けの際に鍵によってアクセスコードからユーザＩＤと個体識別番号を取り出して対応関係をとるよう構成することもできる。

本実施例４では、アクセス要求端末とアクセス承認端末とがＮ対Ｍに対応する構成について、図３８〜図５２を用いて説明する。まず、本実施例４に係るアクセス制御システムの構成について図３８を用いて説明する。

図３８は、実施例４に係るアクセス制御システムの構成を示すブロック図である。同図に示すように、実施例４に係るアクセス制御システムは、アクセス制御サーバ４００と、複数台のアクセス要求端末８００と、アクセス承認端末９００とから構成される。なお、アクセス要求端末８００およびアクセス承認端末９００は、実施例１と同様であるので詳細な説明を省略することとする。

アクセス制御サーバ４００は、本実施例４の主要部をなす装置であり、アクセス要求受付部４１０と、アクセス制御処理部４２０と、アクセスリスト４３０と、承認受付部４４０と、ネットワーク通信機能４５０とを備えている。

アクセス要求受付部４１０はアクセス要求端末８００からのアクセス要求を受け付ける処理をおこなう処理部であり、承認受付部４４０はアクセス承認端末９００からのアクセス承認を受け付ける処理をおこなう処理部である。また、アクセス制御処理部４２０はアクセス要求受付部４１０が受け付けたアクセス要求および承認受付部４４０が受け付けたアクセス承認に基づいてアクセス制御をおこなう処理部である。

アクセスリスト４３０はアクセス者の識別子と、アクセス承認端末９００に固有の個体識別番号とを２次元の表とし、２次元の表の各要素にアクセス制御状態をあらわす３ビットの有効フラグを格納したリストであり（図３９参照）、不揮発性ＲＡＭ（Random Access Memory）やハードディスク装置といった記憶部に格納される。また、ネットワーク通信機能４５０は、インターネットや携帯電話網などのネットワークを介してアクセス要求端末８００およびアクセス承認端末９００と通信をおこなう通信処理部である。

図３８に示したように、アクセス制御サーバ４００とアクセス要求端末８００とは、インターネットなどのネットワークを経由してＨＴＴＰ（Hyper Text Transfer Protocol）等のプロトコルを用いて相互に通信できるものとする。また、アクセス制御サーバ４００とアクセス承認端末９００とは、携帯電話網などのネットワークを経由して同じくＨＴＴＰ等のプロトコルを用いて相互に通信できるものとする。

次に、図３８に示したアクセスリスト４３０の例について図３９を用いて説明する。図３９は、図３８に示したアクセスリスト４３０の一例を示す図である。アクセス制御サーバ４００はアクセス者とアクセス承認者とを対応付けるため、このアクセスリスト４３０を保持する。

図３９に示すように、アクセスリスト４３０は、ユーザＩＤと個体識別番号とを各辺とする２次元の表であり、表の各要素には３ビットの有効フラグが格納されている。なお、この有効フラグのうち１ビット目はあらかじめ登録されているものとする。

そして、各ビットの意味は以下のとおりである。１ビット目が１の場合、対応するユーザＩＤのユーザに対して対応する個体識別番号の承認者が承認権をもつことを意味する。また、２ビット目が１の場合、対応するユーザＩＤのユーザがアクセス要求をおこなってアクセス制御待ちであることを意味する。また、３ビット目が１の場合、対応する個体識別番号の承認者が対応するユーザＩＤのユーザに対して承認を与えたことを意味する。

次に、実施例４に係るアクセス制御処理の処理手順について図４０を用いて説明する。図４０は、実施例４に係るアクセス制御処理の処理手順を示すシーケンス図である。同図に示すように、アクセス者はアクセス要求端末８００を操作することによってアクセス制御サーバ４００にアクセスし、図４１に示すアクセス要求画面にユーザＩＤを入力したうえで送信ボタンを押下してアクセス制御サーバ４００へユーザＩＤを送信する（ステップＳ５１０）。

つづいて、アクセス制御サーバ４００はアクセス要求受付処理を実行する（ステップＳ５２０）。図４２に示すように、アクセス制御サーバ４００はアクセス要求端末８００から受け取ったユーザＩＤがアクセスリスト４３０に登録されているか否かを判定し（ステップＳ５２１）、登録されている場合には（ステップＳ５２１，Ｙｅｓ）、このユーザＩＤに対応するアクセスリスト４３０のすべてのエントリの中で、１ビット目が１であるすべてのエントリについて２ビット目を１に設定し（ステップＳ５２２）、受け付け成功として処理を終了する。一方、ステップＳ５２１の判定条件を満たさない場合には（ステップＳ５２１，Ｎｏ）、受付失敗として処理を終了する。

そして、アクセス制御サーバ４００は、アクセス要求端末８００に対して受付結果を通知し（ステップＳ５３０）、受付成功の場合については承認待ちを指示するとともに、追って承認状況を確認することを促す。なお、ステップＳ５３０において用いられるアクセス制御待ち画面の例については図４３に示している。

つづいて、アクセス認証端末９００がアクセス制御サーバ４００に対して認証要求メッセージを送信する（ステップＳ５４０）。なお、この認証要求メッセージは個体識別番号「Ｕ」を含むものとする。また、ステップＳ５４０において用いられる認証要求送信画面の例については図４４に示している。

そして、認証要求メッセージを受け付けたアクセス制御サーバ４００はアクセス承認端末認証処理を実行する（ステップＳ５５０）。図４５に示すように、アクセス制御サーバ４００は、アクセス承認端末９００から受け付けた個体識別番号がアクセスリスト４３０に登録されているか否かを判定し（ステップＳ５５１）、登録されていない場合には（ステップＳ５５１，Ｎｏ）認証失敗として処理を終了する。一方、登録されている場合には（ステップＳ５５１，Ｙｅｓ）、アクセスリスト４３０の個体識別番号に対応したエントリのうち、先頭から２ビットが１１に設定されているエントリについてのユーザＩＤをアクセス待ちリストとして抽出し（ステップＳ５５２）、認証成功として処理を終了する。

つづいて、アクセス制御サーバ４００は、アクセス承認端末９００に対してアクセス制御結果およびアクセス待ちリストを通知する（ステップＳ５６０）。なお、ステップＳ５６０において用いられる認証結果通知画面の例については図４６に示している。

アクセス制御結果およびアクセス待ちリストを通知されたアクセス承認端末９００では、アクセス承認者が表示されたアクセス待ちリストの中からアクセスを承認する相手を選択し、選択結果を個体識別番号とあわせてアクセス制御サーバ４００に対して送信する（ステップＳ５７０）。

アクセス承認端末９００から選択結果を通知されたアクセス制御サーバ４００は、承認処理を実行する（ステップＳ５８０）。図４７に示すように、チェック（選択）されたユーザＩＤのリストを受け取ったアクセス制御サーバ４００は、チェックされたユーザＩＤが１つ以上存在するか否かを判定する（ステップＳ５８１）。そして、チェックされたユーザＩＤがない場合には（ステップＳ５８１，Ｎｏ）、承認結果を未承認として処理を終了する。一方、チェックされたユーザＩＤが１つ以上存在する場合には（ステップＳ５８１，Ｙｅｓ）、アクセスリスト４３０の該当する個体識別番号およびユーザＩＤで特定されるエントリの中から、先頭から２ビットが１１であるものについて末尾の３ビット目を１に設定し（ステップＳ５８２）、承認結果を承認として処理を終了する。

つづいて、アクセス制御サーバ４００は、アクセス承認端末９００に対して承認結果を通知する（ステップＳ５９０）。なお、ステップＳ５９０において用いられる承認結果通知画面の例については図４８に示している。図４８に示すように、アクセス承認者は、表示されたアクセス待ちリストから、さらに、承認相手を選択してアクセス制御サーバ４００に送信したり、いったん承認済みとしたアクセス者の承認を解除したりすることができる。

また、アクセス要求端末８００は、アクセス承認端末９００による承認が完了してアクセスが許可された否かを確認するために、図４３に示した承認状況確認のためのリンクをたどることによって、アクセス制御サーバ４００に対してユーザＩＤを含んだアクセス制御確認を送信する（ステップＳ６００）。

このアクセス制御確認を受け付けたアクセス制御サーバ４００は、アクセス許可判定処理を実行する（ステップＳ６１０）。図４９に示すように、アクセス制御サーバ４００は、アクセス要求端末８００から受け付けたユーザＩＤがアクセスリスト４３０に登録されているか否かを判定する（ステップＳ６１１）。そして、受け付けたユーザＩＤがアクセスリスト４３０に登録されていない場合には（ステップＳ６１１，Ｎｏ）、アクセス不許可として処理を終了する。一方、受け付けたユーザＩＤがアクセスリスト４３０に登録されている場合には（ステップＳ６１１，Ｙｅｓ）、受け付けたユーザＩＤに対応するアクセスリスト４３０のすべてのエントリが１１１あるいは０００に設定されているか否かを判定する（ステップＳ６１２）。

そして、ステップＳ６１２の判定条件を満たしていない場合には（ステップＳ６１２，Ｎｏ）、アクセス不許可として処理を終了する。一方、ステップＳ６１２の判定条件を満たしている場合には（ステップＳ６１２，Ｙｅｓ）、アクセス許可として処理を終了する。

つづいて、アクセス制御サーバ４００は、アクセス要求端末８００に対してアクセス許可結果を通知する（ステップＳ６２０）。なお、ステップＳ６２０において用いられるアクセス許可結果画面の例については図５０に示している。

ところで、アクセス承認者は、いったん与えた承認を解除することも可能である。以下では、この承認解除手順について説明する。アクセス承認者は図４８に示した承認結果通知画面に表示された承認解除送信ボタンを押下すると、アクセス承認端末９００は、個体識別番号を含んだ承認解除要求をアクセス制御サーバ４３０に対して送信する（ステップＳ６３０）。

この承認解除要求を受け付けたアクセス制御サーバ４００は、承認解除処理を実行する（ステップＳ６４０）。図５１に示すように、アクセス制御サーバ４００は、アクセス承認端末９００から受け付けた個体識別番号がアクセスリスト４３０に登録されているか否かを判定する（ステップＳ６４１）。そして、受け付けた個体識別番号がアクセスリスト４３０に登録されていない場合には（ステップＳ６４１，Ｎｏ）、承認解除失敗として処理を終了する。一方、アクセスリスト４３０に登録されている場合には（ステップＳ６４１，Ｙｅｓ）、該当するエントリすべてについて末尾のビットを０に設定し（ステップＳ６４２）、承認解除成功として処理を終了する。

つづいて、アクセス制御サーバ４００は、アクセス承認端末９００に対して承認解除結果を通知する（ステップＳ６５０）。なお、この承認解除結果には承認解除成功／失敗の旨が含まれるものとする。また、ステップＳ４５０において用いられる承認解除結果通知画面の例については図５２に示している。

上述したように、本実施例４によれば、アクセス承認端末からあらかじめ承認通知を受け付けているという条件の下でアクセス者のアクセス制御処理をおこなうことができる。また、アクセス承認端末の正当性を個体識別番号によって確認することで、アクセス承認端末の利用者は承認のための情報を入力する必要がないので、入力の手間を省きつつアクセス承認端末のなりすましを効果的に防止することができる。

さらに、アクセス承認端末への問合わせ課程を含んだアクセス制御をおこなうことにより、複数のアクセス要求端末がアクセスしてきている場合であっても、各アクセス要求端末の属性やアクセス要求の内容に応じた適切なアクセス制御をおこなうことが可能である。

なお、上記した実施例４では、アクセス承認端末から個体識別番号を受け付ける場合について示したが、個体識別番号のかわりにアクセス承認端末の発アドレスを用いたり、アクセス承認端末から承認用パスワードなどの秘密情報を受け付けたりするよう構成することもできる。

また、上記した実施例４では、複数のアクセス承認者からの承認を順不同で受け付ける場合について示したが、アクセス承認者間に序列を設けることとし、下位承認者の承認状況に応じて承認受付可否を判定することによってあらかじめ定めた序列に従った承認を次々と受け付けるようにしてアクセス制御をおこなうこととしてもよい。

また、上記した実施例４では、サーバ側がアクセスリストを保持し、このアクセスリストを用いることによってアクセス者とアクセス承認端末との対応付けをおこなう場合について示したが、アクセス要求がアクセス承認端末の識別子を含み、サーバ側ではアクセス要求に含まれるアクセス承認端末の識別子がアクセス承認端末と対応していることを条件としてアクセス制御をおこなうこととしてもよい。たとえば、サーバがユーザＩＤと個体識別番号とを鍵によって含むアクセスコードをあらかじめアクセス者に払い出しておき、アクセス要求受け付けの際に鍵によってアクセスコードからユーザＩＤと個体識別番号を取り出して対応関係をとるよう構成することもできる。

なお、上記した各実施例では、本発明を実現する各装置を機能面から説明したが、各装置の各機能はパーソナルコンピュータやワークステーションなどのコンピュータにプログラムを実行させることによって実現することもできる。

すなわち、上述した各種の処理手順は、あらかじめ用意されたプログラムをコンピュータ上で実行することによって実現することができる。そして、これらのプログラムは、インターネットなどのネットワークを介して配布することができる。さらに、これらのプログラムは、ハードディスク、フレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤなどのコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行することもできる。

以上のように、本発明に係るアクセス制御システム、アクセス制御方法およびアクセス制御プログラムは、サーバにアクセスする端末のアクセス制御に有用であり、特に、サーバが他のサーバにアクセスすることが禁止されている状況において端末のアクセス制御をおこないたい場合に適している。

実施例１に係るアクセス制御システムの構成を示すブロック図である。 図１に示した有効リストの一例を示す図である。 実施例１に係るアクセス制御処理の処理手順を示すシーケンス図である。 アクセス承認端末に表示される承認通知画面の一例を示す図である。 図３に示した承認処理の処理手順を示すフローチャートである。 アクセス承認端末に表示される承認通知画面の一例を示す図である。 アクセス要求端末に表示されるアクセス要求画面の一例を示す図である。 図３に示したアクセス制御処理の処理手順を示すフローチャートである。 アクセス要求端末に表示されるアクセス制御結果画面の一例を示す図である。 図３に示した承認解除処理の処理手順を示すフローチャートである。 アクセス承認端末に表示される承認解除結果画面の一例を示す図である。 実施例２に係るアクセス制御システムの構成を示すブロック図である。 図１２に示したパスワードテーブルの一例を示す図である。 実施例２に係るアクセス制御処理の処理手順を示すシーケンス図である。 アクセス要求端末に表示されるアクセス要求画面の一例を示す図である。 図１４に示したセッションＩＤ生成処理の処理手順を示すフローチャートである。 アクセス要求端末に表示されるパスワード入力画面の一例を示す図である。 アクセス承認端末に表示される認証要求画面の一例を示す図である。 図１４に示したパスワード生成処理の処理手順を示すフローチャートである。 アクセス承認端末に表示されるパスワード生成結果通知画面の一例を示す図である。 図１４に示したアクセス制御処理の処理手順を示すシーケンス図である。 アクセス要求端末に表示されるアクセス制御結果画面の一例を示す図である。 実施例３に係るアクセス制御システムの構成を示すブロック図である。 図２３に示したアクセスリストの一例を示す図である。 実施例３に係るアクセス制御処理の処理手順を示すシーケンス図である。 アクセス要求端末に表示されるアクセス要求画面の一例を示す図である。 図２５に示したアクセス要求受付処理の処理手順を示すフローチャートである。 アクセス要求端末に表示されるアクセス制御待ち画面の一例を示す図である。 アクセス承認端末に表示される認証要求送信画面の一例を示す図である。 図２５に示したアクセス承認端末認証処理の処理手順を示すフローチャートである。 アクセス承認端末に表示される認証結果通知画面の一例を示す図である。 図２５に示した承認処理の処理手順を示すフローチャートである。 アクセス承認端末に表示される承認結果通知画面の一例を示す図である。 図２５に示したアクセス許可判定処理の処理手順を示すフローチャートである。 アクセス要求端末に表示されるアクセス許可結果画面の一例を示す図である。 図２５に示した承認解除処理の処理手順を示すフローチャートである。 アクセス承認端末に表示される承認解除結果通知画面の一例を示す図である。 実施例４に係るアクセス制御システムの構成を示すブロック図である。 図３８に示したアクセスリストの一例を示す図である。 実施例４に係るアクセス制御処理の処理手順を示すシーケンス図である。 アクセス要求端末に表示されるアクセス要求画面の一例を示す図である。 図４０に示したアクセス要求受付処理の処理手順を示すフローチャートである。 アクセス要求端末に表示されるアクセス制御結果画面の一例を示す図である。 アクセス承認端末に表示される認証要求画面の一例を示す図である。 図４０に示したアクセス承認端末認証処理の処理手順を示すフローチャートである。 アクセス承認端末に表示される認証結果画面の一例を示す図である。 図４０に示した承認処理の処理手順を示すフローチャートである。 アクセス承認端末に表示される承認結果通知画面の一例を示す図である。 図４０に示したアクセス許可判定処理の処理手順を示すフローチャートである。 アクセス要求端末に表示されるアクセス許可結果画面の一例を示す図である。 図４０に示した承認解除処理の処理手順を示すフローチャートである。 アクセス承認端末に表示される承認解除結果通知画面の一例を示す図である。

符号の説明

１００ アクセス制御サーバ
１１０ アクセス要求受付部
１２０ アクセス制御処理部
１３０ 有効リスト
１４０ 承認受付部
１５０ ネットワーク通信機能
２００ アクセス制御サーバ
２１０ アクセス要求受付部
２２０ パスワード生成部
２３０ 承認情報通知部
２４０ パスワードテーブル
２５０ アクセス制御処理部
２６０ ネットワーク通信機能
３００ アクセス制御サーバ
３１０ アクセス要求受付部
３２０ アクセス制御処理部
３３０ アクセスリスト記憶部
３４０ 承認受付部
３５０ ネットワーク通信機能
４００ アクセス制御サーバ
４１０ アクセス要求受付部
４２０ アクセス制御処理部
４３０ アクセスリスト記憶部
４４０ 承認受付部
４５０ ネットワーク通信機能

Claims (11)

1. アクセス者によるアクセスを制御するアクセス制御システムであって、
   第一端末からのアクセス要求を受け付けるアクセス要求受付手段と、
   第二端末からのアクセス承認を受け付けるアクセス承認受付手段と、
   前記アクセス要求受付手段が前記アクセス要求を受け付け、かつ、前記アクセス承認受付手段が前記アクセス承認を受け付けたことを条件として前記第一端末からのアクセスを許可するアクセス制御手段と
   を備えたことを特徴とするアクセス制御システム。
2. 前記アクセス制御手段は、
   前記アクセス要求受付手段が受け付けた前記アクセス要求と前記アクセス承認受付手段が受け付けた前記アクセス承認とが対応することを条件として前記第一端末からのアクセスを許可することを特徴とする請求項１に記載のアクセス制御システム。
3. 前記第一端末からの前記アクセス要求は、アクセス者を一意に識別するアクセス者識別子を含み、
   前記第二端末からの前記アクセス承認は、アクセス承認者を一意に識別するアクセス承認者識別子を含み、
   前記アクセス制御手段は、
   前記アクセス者識別子と前記アクセス承認者識別子とが対応することを条件として前記第一端末からのアクセスを許可することを特徴とする請求項２に記載のアクセス制御システム。
4. 前記第一端末からのアクセスを許可するための認証情報を前記第二端末に対して送信する認証情報送信手段と、
   前記第一端末から前記認証情報を受け付ける認証情報受付手段と
   をさらに備え、
   前記アクセス制御手段は、
   前記認証情報送信手段が前記第二端末に対して送信した前記認証情報を前記認証情報受付手段が前記第一端末から受け付けた場合に、前記アクセス要求と前記アクセス承認とが対応すると判定することを特徴とする請求項２に記載のアクセス制御システム。
5. 前記認証情報送信手段は、
   前記第一端末からの前記アクセス要求を受け付けるたびに異なる前記認証情報を生成して当該認証情報を送信することを特徴とする請求項４に記載のアクセス制御システム。
6. 前記アクセス承認受付手段は、
   前記第二端末の認証に成功したことを条件として当該第二端末からの前記アクセス承認を受け付けることを特徴とする請求項１〜５のいずれか一つに記載のアクセス制御システム。
7. 前記アクセス承認受付手段は、
   前記アクセス承認者識別子として前記第二端末を一意に識別する第二端末識別子を用いるものであって、
   共有秘密情報および／または前記第二端末識別子を用いて前記第二端末の認証をおこなうことを特徴とする請求項６に記載のアクセス制御システム。
8. 前記アクセス承認受付手段は、
   前記第二端末との間に通信チャネルを設け、前記通信チャネル上の通信データの暗号化または前記通信チャネル自体のセキュア化をおこなうことを特徴とする請求項１〜７のいずれか一つに記載のアクセス制御システム。
9. 前記アクセス承認受付手段が前記第二端末からの前記アクセス承認を受け付けた後に、当該第二端末に対して前記アクセス承認の内容を確認する承認内容確認手段
   をさらに備え、
   前記アクセス制御手段は、
   前記承認内容確認手段の確認結果に基づいて前記第一端末からのアクセスを制御することを特徴とする請求項１〜８のいずれか一つに記載のアクセス制御システム。
10. アクセス者によるアクセスを制御するアクセス制御方法であって、
    第一端末からのアクセス要求を受け付けるアクセス要求受付工程と、
    第二端末からのアクセス承認を受け付けるアクセス承認受付工程と、
    前記アクセス要求受付工程が前記アクセス要求を受け付け、かつ、前記アクセス承認受付工程が前記アクセス承認を受け付けたことを条件として前記第一端末からのアクセスを許可するアクセス制御工程と
    を含んだことを特徴とするアクセス制御方法。
11. アクセス者によるアクセスを制御するアクセス制御プログラムであって、
    第一端末からのアクセス要求を受け付けるアクセス要求受付手順と、
    第二端末からのアクセス承認を受け付けるアクセス承認受付手順と、
    前記アクセス要求受付手順が前記アクセス要求を受け付け、かつ、前記アクセス承認受付手順が前記アクセス承認を受け付けたことを条件として前記第一端末からのアクセスを許可するアクセス制御手順と
    をコンピュータに実行させることを特徴とするアクセス制御プログラム。

Images