JP2013033302A - 通信システム及び通信方法 - Google Patents

Abstract

【課題】 ネットワーク上における、なりすましによる被害を減らすことを目的とする。
【解決手段】 通信回線（１）を介して互いに接続されたホストサーバ（１０）と、当該ホストサーバからサービスを受ける少なくとも１個のクライアント端末（２０）と、を含み、クライアント端末から送信された混在テキストデータから、埋め込まれているアクセス開始日時に係るデータを抽出して直接読み込み可能なアクセス開始日時に変換し、そのアクセス開始日時と、矯正済みリアルタイムとを比較して当該アクセスの正当性を判定する。
【選択図】図１

Description

本発明は、ネットワークを介して接続されたホストサーバとクライアント端末からなる通信システム及びこれらによって実行される通信方法における、いわゆる「なりすまし」を防止する技術に関する。

インターネットなどの不特定多数が参加するネットワーク環境下において、サービスを受ける権利を持ったクライアント端末のみにサービスを提供する機能を持ったホストサーバは、接続してきたクライアント端末がサービスを受ける権利を有しているか否かの判断をまず行う。この際にクライアント端末が送信してきた文字、記号および数字で構成された端末IDやパスワードが正当であるかで判定する。ここで問題となるのが、いわゆる「なしすまし」である。「なりすまし」とは、他人の端末ＩＤ（ユーザーＩＤ）やパスワード等を盗用し、その他人のふりをしてネットワーク上で活動することをいう。悪意のある第三者によって通信盗聴やソーシャル・エンジニアリングなどの手段で端末ＩＤやパスワードを盗まれると、なりすまされてホストサーバシステムに接続される。その結果、ホストサーバは悪意のある第三者に不正にサービスを提供させられてしまい、それによって利用者（クライアント）は不利益を被る。例えばホストサーバシステムが金融機関のオンラインバンキングであれば利用者（クライアント）の口座から現金を不正に引き出されるという被害を受ける。また、会員制オンラインゲームであれば利用者（クライアント）が所有するレアアイテムやゲーム内通貨を横取りされるという被害を受ける。ネットワークを利用するエチケットとしてパスワードを定期的に、短期間に変更しましょうと呼びかけられているがパスワードを頻繁に変更する事は利用者にとっては煩わしい事である。

特許文献１には、個人情報を入手した者がその個人情報主であるユーザーにメールを送る場合に、そのメールに含まれることとなる識別情報（たとえば、サイト毎に使い分けるユーザーの匿名）プロセッサを利用して生成し、この識別情報の一致不一致を判定することによりなりすましを防止しようとする技術が開示されている。

特開２００３−６７５２４号公報

しかしながら、特許文献１が開示する技術はメールの送受信が前提となっており、メール以外の通信に利用することができないので、限られた範囲でしか有効でない。さらに、識別情報自体が第三者に盗用されたなら、その第三者はユーザーに対して簡単になりすましを行うことができてしまう。本発明は利用者が簡単に盗用できない方法により、なりすましによる被害を減らすことを目的とする。

上記目的を達成するために発明者は、簡単に盗用できないものとして、「アクセス開始日時」とリアルタイムとの誤差の程度により、本人かなりしすましかを判定することを思いついた。アクセス開始日時であれば、仮にこれを盗用できたとしても、刻々変化するリアルタイムとの誤差までも改変することができないからである。本発明の詳しい内容については、項を改めて説明する。なお、いずれかの請求項記載の発明を説明するに当って行う用語の定義等は、その記載順や発明のカテゴリー等の違いに関わらす、その性質上可能な範囲において他の請求項記載発明にも適用があるものとする。

（請求項１記載発明の特徴）
請求項１記載発明に係る通信システム（以下、適宜「請求項１のシステム」という）は、通信回線を介して互いに接続されたホストサーバと、当該ホストサーバからサービスを受ける少なくとも１個のクライアント端末と、を含む通信システムである。ここで、当該ホストサーバは、アクセスしてきたクライアント端末の端末ＩＤと予めクライアントＤＢに記憶してある基準ＩＤとの一致不一致を判定するＩＤ判定手段と、当該ＩＤ判定手段がＩＤ一致と判定したクライアント端末のＵＲＬから、当該アクセスに係るアクセス開始日時が直接読み込み不能に埋め込まれた混在テキストデータを抽出するデータ抽出手段と、当該データ抽出手段が抽出した混在テキストデータから、埋め込まれているアクセス開始日時に係るデータを抽出して直接読み込み可能なアクセス開始日時に変換する抽出変換手段と、当該抽出変換手段が抽出変換したアクセス開始日時と、矯正済みリアルタイムとを比較して当該アクセスの正当性を判定する正当性判定手段と、当該正当性判定手段が正当と判定したクライアント端末に対してサービス開始を許諾するサービス許諾手段と、を含めて構成してある。また、当該クライアント端末は、自己の端末ＩＤを当該ホストサーバに送信する送信手段と、当該ホストサーバに対する矯正済みアクセス開始日時に係るデータを、テキストデータに変換して他のテキストデータに直接読み込み不能に埋め込んで混在テキストデータを生成するデータ生成手段と、当該混在テキストデータを当該ホストサーバへ送信する送信手段と、を含めて構成してある。

請求項１のシステムによれば、ホストサーバのＩＤ判定手段が、端末ＩＤと基準ＩＤとの比較を行い、それらが一致した場合はデータ抽出手段がクライアント端末のＵＲＬから混在テキストデータを抽出する。この時点では、クライアント端末がなりすましかどうか分からない。次に、抽出交換手段が混在テキストデータから抽出し変換したアクセス開始日時と矯正済みリアルタイムとを比較して当該アクセスの正当性を判定する。判定は、正当性判定手段が行う。リアルタイムの矯正は、たとえば、ＮＴＰサーバから読み込んだ日時を基準にして行う。矯正済みリアルタイムを基準としたのは、日時のごまかしを排除するためである。アクセス正当性の判断は、アクセス開始日時と矯正済みリアルタイムとの誤差がゼロもしくは所定範囲内に入っているかいないかで判断し、入っていない場合をなりすましと判断する。両者間の誤差が所定範囲外であるなら、正当なアクセスであればかかるはずのない時間がかかっているので、その余分にかかった時間がなりすましのためにかかった時間と考えられるからである。アクセス正当性が確認できたところで、サービス許諾手段が当該クライアント端末に対してサービスを開始する。一方、端末ＩＤを送信したクライアント端末は、データ生成手段が生成した混在テキストデータを相手先であるホストサーバに送信する。アクセス開始日時を矯正済み、としたのは、上記同様にごまかしを排除するためである。クライアント端末は、以上を実行することによりホストサーバのサービスを受けることができる。クライアント端末が端末ＩＤや日時データを直接読み込み不能な形式でＵＲＬ文字列に変換してホストサーバに送信することにより、これを行わない場合と比べて、通信盗聴などのセキュリティ的な攻撃を受けた場合に端末ＩＤが解読されて盗まれる危険が少なくなる。また、解読されて盗まれ、なりすまされてホストサーバにアクセスしてきたとしても通信盗聴した日時データとなりすましアクセスの日時データが異なるためにホストサーバが正当性判定で不正と判定することが出来る。

（請求項２記載発明の特徴）
請求項２記載発明に係る通信システム（以下、適宜「請求項２のシステム」という）は、請求項１のシステムの好ましい態様として、前記抽出変換手段は、カラーコード化された混在テキストデータからアクセス開始日時を抽出変換するように構成してあり、前記データ生成手段は、テキストデータをカラーコード化することによって混在テキストデータを生成するように構成してある。

請求項２のシステムによれば、請求項１のシステムにおいて、混在テキストデータがカラーコード化されているので、そこに埋め込まれている矯正済みアクセス開始日時の読み取りがきわめて困難になる。アクセス開始日時とリアルタイムとの誤差の判定に加え、カラーコード化という障壁を設けることにより、なりすましをより確実に排除することができる。

（請求項３記載発明の特徴）
請求項３記載発明に係る通信システム（以下、適宜「請求項３のシステム」という）は、通信回線を介して互いに接続されたホストサーバと、当該ホストサーバからサービスを受ける少なくとも１個のクライアント端末と、を含む通信システムである。ここで、当該ホストサーバは、アクセスしてきたクライアント端末の端末ＩＤと予めクライアントＤＢに記憶してある基準ＩＤとの一致不一致を判定するＩＤ判定手段と、当該ＩＤ判定手段がＩＤ一致と判定したクライアント端末が送信した当該アクセスに係るアクセス開始日時を意味するカラー画像データを受信するデータ受信手段と、当該データ受信手段が受信したカラー画像データをアクセス開始日時に変換する変換手段と、当該変換手段が変換したアクセス開始日時と、矯正済みリアルタイムとを比較して当該アクセスの正当性を判定する正当性判定手段と、当該正当性判定手段が正当と判定したクライアント端末に対してサービス開始を許諾するサービス許諾手段と、を含めて構成してある。また、当該クライアント端末は、自己の端末ＩＤを当該ホストサーバに送信する手段と、当該ホストサーバに対する矯正済みアクセス開始日時に係るデータを、カラー画像データに変換するデータ変換手段と、当該カラー画像データを当該ホストサーバへ送信する送信手段と、を含めて構成してある。

請求項３のシステムによれば、ホストサーバのＩＤ判定手段が、端末ＩＤと基準ＩＤとの比較を行い、それらが一致した場合にデータ受信手段がカラー画像データを受信する。この時点では、クライアント端末がなりすましかどうか分からない。次に、受信したカラー画像データを変換して得たアクセス開始日時と矯正済みリアルタイムとを比較して当該アクセスの正当性を判定する。判定は、正当性判定手段が行う。リアルタイムの矯正は、たとえば、ＮＴＰサーバから読み込んだ日時を基準にして行う。矯正済みリアルタイムを基準としたのは、日時のごまかしを排除するためである。アクセス正当性の判断は、アクセス開始日時と矯正済みリアルタイムとの誤差がゼロもしくは所定範囲内に入っているかいないかで判断し、入っていない場合をなりすましと判断する。両者間の誤差が所定範囲外であるなら、正当なアクセスであればかかるはずのない時間がかかっているので、その余分にかかった時間がなりすましのためにかかった時間と考えられるからである。アクセス正当性が確認できたところで、サービス許諾手段が当該クライアント端末に対してサービスを開始する。一方、端末ＩＤを送信したクライアント端末は、データ生成手段が生成したカラー画像データを相手先であるホストサーバに送信する。アクセス開始日時を矯正済み、としたのは、上記同様にごまかしを排除するためである。クライアント端末は、以上を実行することによりホストサーバのサービスを受けることができる。

（請求項４記載発明の特徴）
請求項４記載発明に係る通信システム（以下、適宜「請求項４のシステム」という）は、通信回線を介して互いに接続されたホストサーバと、当該ホストサーバからサービスを受ける少なくとも１個のクライアント端末と、を含むシステムである。ここで、当該ホストサーバは、アクセスしてきたクライアント端末の端末ＩＤと予めクライアントＤＢに記憶してある基準ＩＤとの一致不一致を判定するＩＤ判定手段と、リアルタイムクロックから得たアクセス開始日時データを、当該ＩＤ判定手段がＩＤ一致と判定したクライアント端末へ送信するデータ送信手段と、当該アクセス開始日時を検索可能に記憶する日時記憶手段と、当該クライアント端末から送信された端末使用者入力に係る入力アクセス開始日時が直接読み込み不能に埋め込まれたコード化データから入力アクセス開始日時データを抽出するデータ抽出手段と、当該データ抽出手段が抽出した入力開始日時データを、直接読み込み可能な入力アクセス開始日時に変換する抽出変換手段と、当該抽出変換手段が抽出した入力アクセス開始日時と、当該日時記憶手段が記憶するアクセス開始日時とを比較して当該アクセスの正当性を判定する正当性判定手段と、当該正当性判定手段が正当と判定したクライアント端末に対してサービス開始を許諾するサービス許諾手段と、を含めて構成してある。また、当該クライアント端末は、自己の端末ＩＤを当該ホストサーバに送信する手段と、受信したアクセス開始日時データに係るアクセス開始日時を端末使用者が目視できるように表示する表示手段と、端末使用者が入力アクセス開始日時を入力する日時入力手段と、当該日時入力手段から入力された入力アクセス開始日時に係るデータを、コード化データに変換する変換手段と、当該コード化データを当該ホストサーバに送信する送信手段と、を含めて構成してある。

請求項４のシステムによれば、ホストサーバのＩＤ判定手段が、端末ＩＤと基準ＩＤとの比較を行い、それらが一致した場合にリアルタイムクロックから得たアクセス日時を送信・記憶する。この時点では、クライアント端末がなりすましかどうか分からない。
次に、クライアント端末から送信されたコード化データから抽出した入力アクセス日時データを変換して直接読み込み可能な入力アクセス開始日時を得る。入力アクセス開始日時と記憶してあるアクセス開始日時とを比較して当該アクセスの正当性を判定する。アクセス正当性の判断は、入力アクセス開始日時とアクセス開始日時との誤差がゼロもしくは読み取り誤差の範囲内に入っているかいないかで判断し、入っていない場合をなりすましと判断する。両者間の誤差が所定範囲外であるなら、正当なアクセスであれば読み取ることのできたはずのアクセス開始日時が読み取れていないので、その入力アクセス開始日時は正当な端末使用者の入力によるものではないと考えられるからである。アクセス正当性が確認できたところで、サービス許諾手段が当該クライアント端末に対してサービスを開始する。一方、端末ＩＤを送信したクライアント端末は、日時入力手段から入力された入力アクセス日時に係るデータを相手先であるホストサーバに送信する。クライアント端末は、以上を実行することによりホストサーバのサービスを受けることができる。

（請求項５記載発明の特徴）
請求項５記載発明に係る通信方法（以下、適宜「請求項５の方法」という）は、通信回線を介して互いに接続されたホストサーバと、当該ホストサーバからサービスを受ける少なくとも１個のクライアント端末と、によって実行される通信方法である。ここで、当該ホストサーバは、アクセスしてきたクライアント端末の端末ＩＤと予めクライアントＤＢに記憶してある基準ＩＤとの一致不一致を判定するＩＤ判定ステップと、当該ＩＤ判定手段がＩＤ一致と判定したクライアント端末のＵＲＬから、当該アクセスに係るアクセス開始日時が直接読み込み不能に埋め込まれた混在テキストデータを抽出するデータ抽出ステップと、当該データ抽出手段が抽出した混在テキストデータから、埋め込まれているアクセス開始日時に係るデータを抽出して直接読み込み可能なアクセス開始日時に変換する抽出変換ステップと、当該抽出変換手段が抽出変換したアクセス開始日時と、矯正済みリアルタイムとを比較して当該アクセスの正当性を判定する正当性判定ステップと、当該正当性判定手段が正当と判定したクライアント端末に対してサービス開始を許諾するサービス許諾ステップ手段と、を実行する。また、当該クライアント端末は、自己の端末ＩＤを当該ホストサーバに送信するステップと、当該ホストサーバに対する矯正済みアクセス開始日時に係るデータを、テキストデータに変換して他のテキストデータに直接読み込み不能に埋め込んで混在テキストデータを生成するデータ生成ステップと、当該混在テキストデータを当該ホストサーバへ送信する送信ステップと、を実行する。

請求項５の方法によれば、ホストサーバが、端末ＩＤと基準ＩＤとの比較を行い、それらが一致した場合はクライアント端末のＵＲＬから混在テキストデータを抽出する。この時点では、クライアント端末がなりすましかどうか分からない。次に、混在テキストデータから抽出し変換したアクセス開始日時と矯正済みリアルタイムとを比較して当該アクセスの正当性を判定する。リアルタイムの矯正は、たとえば、ＮＴＰサーバから読み込んだ日時を基準にして行う。矯正済みリアルタイムを基準としたのは、日時のごまかしを排除するためである。アクセス正当性の判断は、アクセス開始日時と矯正済みリアルタイムとの誤差がゼロもしくは所定範囲内に入っているかいないかで判断し、入っていない場合をなりすましと判断する。両者間の誤差が所定範囲外であるなら、正当なアクセスであればかかるはずのない時間がかかっているので、その余分にかかった時間がなりすましのためにかかった時間と考えられるからである。アクセス正当性が確認できたところで、当該クライアント端末に対してサービスを開始する。一方、端末ＩＤを送信したクライアント端末は、生成した混在テキストデータを相手先であるホストサーバに送信する。アクセス開始日時を矯正済み、としたのは、上記同様にごまかしを排除するためである。クライアント端末は、以上を実行することによりホストサーバのサービスを受けることができる。

本発明によれば、なりすましによる被害を効率的に減らすことができる。

実施形態に係わる全体の構成を示す図である。 実施形態に係わるホストサーバ１０の構成を示すブロック図である。 実施形態に関わるクライアント端末２０の構成を示すブロック図である。 実施形態に係わるＵＲＬの構成を示す図である。 実施形態に係わるデータの流れを示す図である。 実施形態に係わるクライアント端末２０でのＵＲＬ変換フローチャートである。 実施形態に係わるホストサーバ１０でのＵＲＬ逆変換フローチャートである。 変形例１に係わるクライアント端末２０でのＵＲＬ変換フローチャートである。 変形例１に係わるホストサーバ１０でのＵＲＬ逆変換フローチャートである。 変形例２に係わるデータの流れを示す図である。

以下、本発明の一実施形態について説明する。図１は本発明の一実施形態の全体構成を示すブロック図である。

（通信システムの概要）
通信システム１は、通信回線であるインターネット５０を介して互いに接続されたホストサーバ１０と、少なくとも１個のクライアント端末２０と、を含めて構成してある。

ホストサーバ１０はインターネット５０を介して予め定められたクライアント端末２０にサービスを提供し、かつ、それ以外のコンピュータには本発明に係るサービスを提供しない機能をもつコンピュータである。サービスとはオンラインバンキングや、会員制ネットゲームなどであり、２４時間３６５日ノンストップで動いている。ホストサーバ１０にはＩＰアドレス＝ａａａ．ａａａ．ａａａ．ａａａが割り当てられている。クライアント端末２０はホストコンピュータ１０から予めサービスを受ける権利をもったコンピュータである。クライアント端末２０はサービスを受けたいときにだけ利用者によって電源を投入されて動作を行う。クライアント端末２０にはＩＰアドレス＝ｂｂｂ．ｂｂｂ．ｂｂｂ．ｂｂｂが割り当てられている。図１に示すクライアント端末２０はいわゆるパーソナルコンピュータに限定されず、通信機能付きＰＤＡ（Personal Digital Assistant）や通信機能付きゲーム機、携帯電話機などのネットワークを介して、ホストサーバよりサービスの提供を受ける機能を持つ端末という概念とする。

ＮＴＰサーバ３０は原子時計などの高精度な日時情報をNetwork Time Protocolによってインターネット５０上の機器に配信するコンピュータである。ＮＴＰサーバ３０にはＩＰアドレス＝ｔｔｔ．ｔｔｔ．ｔｔｔ．ｔｔｔが割り当てられている。ホストサーバ１０と、クライアント端末２０と、ＮＴＰサーバ３０はそれぞれが通信回線であるインターネット５０と接続されている。この実施形態ではIPV4で動作しているものとし、上記のａａａ、ｂｂｂおよびｔｔｔは１Ｂｙｔｅの数値、すなわち１０進数表現で０〜２５５の任意の値をさす。本発明はIPV4の環境下に限られたものではなくIPV6の環境下やIPV4とIPV6の混在した環境下でも実施可能である。図１ではクライアント端末２０およびＮＴＰサーバ３０は１つしか描かれていないが複数存在してもかまわない。複数存在する場合はそれぞれ別のＩＰアドレスが割り当てられるものとする。図１で示すインターネット５０にはＤＮＳホストサーバ（Domain Name System Server）などの公共ホストサーバも含まれている概念とする。

（ホストサーバの構成）
図２はホストサーバ１０の構成を示すブロック図である。ＣＰＵ１００はCentral Processing Unitすなわち中央演算装置でありプログラムを実行して、計算や判断や他のブロックへの指示命令を行う。ＣＰＵ１００は、ＩＤ判定手段１００ａ、データ抽出手段１００ｂ、抽出変換手段１００ｃ、正当性判定手段１００ｄ、サービス許諾手段１００ｅとして機能する。通信装置１５０は、送受信手段として機能する。ＲＡＭ１１０はRandom Access Memoryの略でありＣＰＵ１００がプログラムを実行する際にワークエリアとして利用する。ＲＡＭ１１０は電源を切ると記憶したデータが消えてしまう。

記憶装置１２０はプログラムや各種のデータを記憶し、かつ、電源を切ってもデータが消えない機能をもつ記憶手段である。記憶装置１２０にはハードディスクのような磁気記憶装置、ＣＤやＤＶＤのような光記憶装置、フラッシュメモリのような半導体記憶装置、およびこれらの組み合わせが用いられる。本実施形態の記憶装置１２０には基本ソフト（ＯＳ）や、アプリケーションプログラムや、各種のデータが記憶されている。これらに加え、記憶装置１２０にはクライアントＤＢが置かれている。符号ＰＣＩＤ１２１はクライアント端末２０に予め割り当てられた端末特定番号であり、ホストサーバ１０の記憶装置１２０と後述するクライアント端末２０の記憶装置２２０に同じ内容の符号が記憶されている。ＰＣＩＤ１２１はクライアント端末２０を特定できる番号であり、予めホストサーバ１０の運営者がこれを決めてクライアント端末２０の利用者に配布しても良いし、利用者がクライアント端末２０を特定できる文字列や数字列、それらを組み合わせた符号をＰＣＩＤ１２１として運営者に登録して用いても良い。クライアント端末２０を特定できる符号としてはマザーボード基板などに表示されているシリアル番号や、ＢＩＯＳ（Basic Input/Output System）番号を使用することができる。

操作装置１３０は運営者がホストサーバ１０を操作するとき、データを入力するときに利用するマンマシン入力装置である。キーボードやマウスおよびタッチパネルなどが用いられる。表示装置１４０は運営者がホストサーバ１０から情報を受け取るときに利用するマンマシン出力装置である。ＣＲＴディスプレイや液晶ディスプレイ（表示手段）およびプリンタなどが用いられる。

通信装置１５０はホストサーバ１０が自分以外の装置と通信を行うときに用いる。本実施例ではインターネット５０を介して通信を行うためにＩＰ（Internet Protocol）通信を行う事が出来る有線ＬＡＮ装置や、無線ＬＡＮ装置である。ＭＡＣアドレス１５１は通信装置１５０に書き込まれた固有の６Byteの数値である。唯一固有の数値である事から装置の識別に用いられる。

リアルタイムクロック１６０は日時情報を保持するカレンダー付き時計である。バッテリーバックアップされておりホストサーバ１０の電源を切っても日時情報をバッテリーが切れない限り保持する。リアルタイムクロック１６０は何らかの手段で日時合わせを行わないと１日あたり数秒から数十秒の誤差が発生する。本実施例のホストサーバ１０は２４時間３６５日ノンストップで動いており、ＣＰＵ１００はプログラムによって定期的にインターネット５０を介してＮＴＰサーバ３０に日時情報の問い合わせを行い、リアルタイムクロック１６０の日時合わせを行っている。したがって、上記日時情報は「矯正済み」の日時情報である。バス１９０は接続された各ブロック間のデータ伝送を行う。

（クライアント端末の構成）
図３はクライアント端末２０の構成を示すブロック図である。クライアント端末２０の構成は、上述したホストサーバ１０のそれと基本的に同じであるから、同じ部材名で番号のみが異なる場合は、クライアント端末２０の部材とホストサーバ１０の部材は同じ構成であるものであるとしそれらの説明を省略する。以下の説明では、異なる点について説明する。

クライアント端末２０は、ＣＰＵ２００、ＲＡＭ２１０、記憶装置２２０、操作装置２３０、表示装置２４０、通信装置２５０、及びリアルタイムクロック２６０を備えている。ＣＰＵ２００は、各種基本機能を実行するとともに、ホストサーバ１０に対する矯正済みアクセス開始日時に係るデータを、テキストデータに変換して他のテキストデータに直接読み込み不能に埋め込んで混在テキストデータを生成するデータ生成手段として機能する。ＰＣＩＤ２２１はクライアント端末２０に予め割り当てられた端末特定番号であり、ホストサーバ１０の記憶装置１２０とクライアント端末２０の記憶装置２２０に同じ内容の符号が記憶されている。通信装置２５０は、自己の端末ＩＤを当該ホストサーバに送信する送信手段と、混在テキストデータを当該ホストサーバへ送信する送信手段としての機能を有する。ＭＡＣアドレス２５１は通信装置２５０に書き込まれた固有の６Byteの数値である。唯一固有の数値である事から装置の識別に用いられる。

図４はインターネット上の各種ホストサーバやネットワーク装置をアクセスするときに、アクセスする場所を指定するのに用いられるＵＲＬ（Uniform Resource Locator）の一例である。スキームはプロトコル名を用いる事が多く、図４ではｈｔｔｐ（HyperText Transfer Protocol）を用いることを示している。ホスト名はアクセスするＩＰアドレスを文字で示している。インターネット上のＤＮＳホストサーバ（Domain Name System Server）にホスト名を問い合わせるとＤＮＳホストサーバはそのホスト名が示すＩＰアドレスを回答する。パス名は各種ホストサーバやネットワーク装置の内部のアクセスすべき場所を示す。よって、図４に示すＵＲＬはインターネット上のwww.xyz.co.jpという名前が示すＩＰアドレスを持つ装置の／ａａａ１２ｉｄ／ｒ＝１０１ｇ＝１０２ｂ＝１０３という場所をｈｔｔｐというプロトコルでアクセスすることを示している。

以下より各装置の動作を説明する。
クライアント端末２０はホストサーバ１０にアクセスすることによって各種のサービスを受ける。オンラインバンキングや会員制ネットゲームなどのサービスを提供するホストサーバ１０は不特定の相手にサービスを提供するのではなく、予め定められた相手のみに、たとえば正規会員にサービスを提供する。インターネット５０は不特定の相手が発した通信信号（パケット）も存在する。ホストサーバ１０とクライアント端末２０は図５に示す動作によって通信の可否を判断する。

クライアント端末２０の利用者は予めホストサーバ１０の運営者に対してオンラインバンキングであれば口座を開設したり、会員制ネットゲームであれば正規会員になるなどしてサービスを受ける権利を得る。
運営者は利用者にホストサーバ１０をアクセスするための固有の端末特定番号であるＰＣＩＤ１２１（２２１）決めて、それを利用者に通知したり、利用者が運営者にシリアル番号やＢＩＯＳ番号といったクライアント端末２０を特定できる符号を通知するなどして、運営者と利用者とが同じＰＣＩＤ１２１（２２１）を保有する。運営者はホストサーバ１０の記憶装置１２０内のクライアントＤＢにそれを記憶させる。利用者はホストサーバ１０をアクセスするために使用するクライアント端末２０のＭＡＣアドレス２５１を運営者に通知し、運営者はホストサーバ１０の記憶装置１２０に利用者のＰＣＩＤ２２１に関連づけてＭＡＣアドレス２５１を記憶させる。なお、クライアント端末２０のＭＡＣアドレス２５１はコンピュータの筐体に記載されているものを読み取ったり、IPCONFIG命令を用いたりすることで利用者は容易にそれを知る事が出来る。

利用者がクライアント端末２０の電源を入れるとＣＰＵ２００は記憶装置２２０から基本ソフトを読み込み実行する。基本ソフトが起動した後に利用者は操作装置２３０を介してクライアント端末２０へインターネット５０への通信を行うためのブラウザを起動する操作を行う（Ｓ１００）。利用者はクライアント端末２０のリアルタイムクロック２６０を合わせるためにＮＴＰサーバ３０に日時問い合わせを行う。日時問い合わせは基本ソフト（ＯＳ）に含まれている機能を用いても良いし、日時問い合わせ専用のユーティリティソフトを用いても良い（Ｓ１０１）。ＮＴＰサーバ３０は日時問い合わせに対しての返答を返し、リアルタイムクロック２６０は校正される（Ｓ１０２）。なお、Ｓ１０１とＳ１０２はクライアント端末２０のリアルタイムクロック２６０が予め正確であると判っているときは省略して良い。

利用者はブラウザでホストサーバ１０のTop Pageをアクセスする。Top PageはHTML言語やスクリプト言語などのWEB記述言語で書かれており、クライアント端末２０の表示装置２４０にはWEB記述言語に従って利用者のＰＣＩＤ２２１やＭＡＣアドレス２５１の入力を促すメッセージと入力枠が表示される。利用者が操作装置２３０を介してそれらを入力して「ＯＫ」ボタン等をクリックするとWEB記述言語がＰＣＩＤ２２１、ＭＡＣアドレス２５１そしてリアルタイムクロック２６０が示す日時情報をカラーコード化してブラウザのＵＲＬ入力枠に書き込む。なお、利用者がクライアント端末２０でホストサーバ１０をアクセスするたびにＰＣＩＤ２２１とＭＡＣアドレス２５１を入力するのは煩わしいので初回のアクセス以降はブラウザもしくはクライアント端末２０の基本ソフト（ＯＳ）がＰＣＩＤ２２１とＭＡＣアドレス２５１を記憶装置２２０に記憶し、２回目以降のアクセスの際は自動的に入力枠に書き込まれても良い（Ｓ１０３）。ブラウザはＵＲＬ入力枠に書き込まれたホスト名をＤＮＳに問い合わせて、ホストサーバ１０のＩＰアドレスがａａａ．ａａａ．ａａａ．ａａａであることを知り、ホストサーバ１０をアクセスする（Ｓ１０４）。

ホストサーバ１０はクライアント端末２０から受け取ったＵＲＬを解読してＰＣＩＤ２２１、ＭＡＣアドレス２５１そしてアクセス開始日時情報を得る。ホストサーバ１０は記憶装置１２０内のクライアントＤＢに予め記憶してあるＰＣＩＤ１２１および、それに関連づけられたＭＡＣアドレスがＵＲＬを解読して得たＰＣＩＤ２２１およびＭＡＣアドレス２５１と一致しているかを調べる。また、ホストサーバ１０はリアルタイムクロック１６０の示す日時情報とＵＲＬを解読して得たアクセス開始日時情報がほぼ一致するかを調べる。ここでいうほぼ一致とは利用者がクライアント端末２０の操作装置２３０を用いて入力する時間とクライアント端末２０から送信されて、インターネット５０を介して、ホストサーバ１０に受信されるまでに時間的な通信遅延があるのでこれらの遅れを受容するためである。具体的には特段の理由が無い限り遅延時間は最大で数３０秒を見込めばよい。すなわち、ホストサーバ１０のリアルタイムクロック１６０の示す日時情報と、ＵＲＬを解読して得たアクセス開始日時情報の差が３０秒以内かを調べる（Ｓ１０５）。

ホストサーバ１０はクライアント端末２０から受け取ったＰＣＩＤ２２１とＭＡＣアドレス２５１が予め記憶装置１２０内のクライアントＤＢに記憶してある値と一致し、かつ、受け取ったアクセス開始日時情報がリアルタイムクロック１６０の示す値と数３０秒以内の差であればクライアント端末２０にアクセス許可を意味する信号を送信すると共に、以後、通信が切断されるまでクライアント端末２０にサービスを提供する。ＰＣＩＤ２２１またはＭＡＣアドレス２５１が不一致だった、または受け取ったアクセス開始日時情報がリアルタイムクロック１６０の示す値と数３０秒を超える差があればクライアント端末２０にアクセス拒否を意味する信号を送信するとともに、以後、通信を拒否する。具体的な通信拒否の方法としてはクライアント端末２０からホストサーバ１０へのＩＰパケットのヘッダー情報にある送信元ＩＰアドレスを読み取って、クライアント端末２０のＩＰアドレスであるｂｂｂ．ｂｂｂ．ｂｂｂ．ｂｂｂであるパケットを捨てれば良い（Ｓ１０６）。

クライアント端末２０はホストサーバ１０からアクセス許可を意味する信号を受信したならば以後、続けてホストサーバ１０のサービスを受ける。あるいはアクセス拒否を意味する信号を受信したならばホストサーバ１０側から通信を拒否される（Ｓ１０７）。

これよりクライアント端末２０がＰＣＩＤ２２１、ＭＡＣアドレス２５１そしてアクセス開始日時情報をＵＲＬに変換する方法を図６を用いて説明する。ＰＣＩＤ２２１の形式の一例として半角文字と数字の組み合わせでABDC00112233という１２字すなわち１２Byteで構成されるとする。ＭＡＣアドレスは６Byteである。アクセス開始日時情報の一例として年を西暦で４桁、月を２桁、日を２桁、時間を時分秒を各２桁づつ割り当てて６桁としアクセス開始日時情報合計で１４字すなわち１４Byteで構成するものとする。上記よりＰＣＩＤ２２１、ＭＡＣアドレス２５１そしてアクセス開始日時情報を合わせたものは合計で１２＋６＋１４＝３２Byteで表されるひとまとめのデータ列として表す事が出来る（Ｓ５１）。

３２Byteのデータ列を変換表や変換式に従って３原色を表すＲ（赤）、Ｇ（緑）、Ｂ（青）のパラメータに変換する。変換の一例をあげるとASCIIコード表によればＰＣＩＤ２２１であるABCD00112233を変換すると文字Ａは４１Ｈという１Byteに変換される。なお、Ｈは１６進数記述である事を示すシンボルとする。同様にして文字Ｂは４２Ｈに、文字Ｃは４３Ｈに変換されＰＣＩＤ２２１全体としては４１Ｈ、４２Ｈ、４３Ｈ、４４Ｈ、３０Ｈ、３０Ｈ、３１Ｈ、３１Ｈ、３２Ｈ、３２Ｈ、３３Ｈ、３３Ｈという１２Byteに変換される。ＭＡＣアドレス２５１は元々が６Byteであるのでそのまま使用する。アクセス開始日時情報は全て数字で表される１４字であるのでASCIIコード表の０から９を表す３０Ｈから３９Ｈにそれぞれ変換される。上記ではASCIIコード表という既知の変換表を用いたが、これに限定されるものではなく他の変換表を用いても良いし、変換した値を逆変換で元の値に戻せる変換式を用いるのであれば数学的に変換してもよい。また、ホストサーバ１０とクライアント端末２０が同じ共通鍵を持ち合ってＤＥＳ等の既存の暗号変換手法を用いても良い。また、ホストサーバ１０が公開鍵と秘密鍵を作成し、公開鍵を公開して、クライアント端末２０がその公開鍵を使って暗号変換して送信し、それを受信したホストサーバ１０が秘密鍵で解読する公開鍵暗号手法を用いても良い。WEB言語だけでは処理しきれない変換式や暗号手法を用いるために運営者がクライアント端末２０用の変換処理ソフトウエアを作成し、ＣＤなどの媒体に書き込んでサービスを受ける権利を持つ利用者に送付し、クライアント端末２０にインストールして貰ってもらう。またはActiveX（登録商標）やJAVA（登録商標）などの技術を使ってブラウザ経由でクライアント端末２０にインターネット５０を介してインストールしても良い。

次に変換した３２Byteデータ列をＲ、Ｇ、Ｂに振り分ける。振り分けの一例として３２Byteデータ列の先頭から１Byte目、２Byte目、・・・３２Byte目と順番をつけて、その順番を３で割って剰余が１となるグループ、２となるグループ、０となるグループに分け、それぞれのグループをＲ、Ｇ、Ｂのグループとする。具体的にはＰＣＩＤ２２１部分を例に挙げると４１Ｈ、４２Ｈ、４３Ｈ、４４Ｈ、３０Ｈ、３０Ｈ、３１Ｈ、３１Ｈ、３２Ｈ、３２Ｈ、３３Ｈ、３３Ｈの１２Byteのデータ列をＲグループが４１Ｈ（１番目）、４４Ｈ（４番目）、３１Ｈ（７番目）、３２Ｈ（１０番目）の４Byteのデータ列となり、Ｇグループが４２Ｈ（２番目）、３０Ｈ（５番目）、３１Ｈ（８番目）、３３Ｈ（１１番目）の４Byteのデータ列となり、Ｂグループが４３Ｈ（３番目）、３０Ｈ（６番目）、３２Ｈ（９番目）、３３Ｈ（１２番目）の４Byteのデータ列となるように分割する。すなわちＲ、Ｇ、Ｂの各パラメータに変換する。以下同様にしてＭＡＣアドレス２５１部分とアクセス開始日時情報部分を表すByteのデータ列もＲ、Ｇ、Ｂの各パラメータに変換する（Ｓ５２）。

Ｒ、Ｇ、Ｂの各パラメータであるByteのデータ列はバイナリー形式であるのでテキストデータ（文字形式）で表されるＵＲＬにはそのままでは使用できないのでテキストデータに変換する。バイナリー形式を文字形式に変換する一例として１６進数表記に変換する。１Byteは０〜２５５までを表現でき、これを０からＦまでの１６進数で表すと２桁で表現できる。すなわち１Byteを２文字で表す事になる。具体的には上記のＰＣＩＤ２２１部分のＲのグループである４１Ｈ、４４Ｈ、３１Ｈ、３２Ｈの４Byteのデータ列は41443132という８文字のテキストデータ（文字列）に変換される。同様にしてＧ、ＢのグループやＭＡＣアドレス２５１部分、アクセス開始日時情報部分のByte列もテキストデータに変換される（Ｓ５３）。

そしてＵＲＬのパス名部分にＲ、Ｇ、Ｂのどのグループに含まれるのかを示すr=、g=、b=の符号の後に該当するテキストデータを続けて記載して付加する（Ｓ５４）。

これよりホストサーバ１０がクライアント端末２０から受信したＵＲＬのテキストデータからＰＣＩＤ２２１、ＭＡＣアドレス２５１およびアクセス開始日時情報を取得して、クライアント端末２０のアクセスの許可するか拒否するかを判断する方法を図７を用いて説明する。

ホストサーバ１０はクライアント端末２０から受信したＵＲＬのテキストデータ（文字列）からスキームを示す箇所と、ホスト名を示す箇所を取り除くなどしてＰＣＩＤ２２１、ＭＡＣアドレス２５１およびアクセス開始日時情報が埋め込まれた箇所のテキストデータを取得する。（Ｓ６１）

テキストデータ内のr=、g=、b=の符号の後に続く１６進数を表すテキストデータをそれぞれＲ、Ｇ、Ｂの３つのグループの各パラメータとして読み取る。（Ｓ６２）

Ｒ、Ｇ、Ｂの各パラメータのテキストデータは１６進数を表す０〜Ｆまでの文字で構成されている。これを変換表または変換式を使ってByteデータ列に変換する。本実施例ではASCIIコード表を用いて変換を行う。テキストデータの先頭から２文字づつ取り出して、その２文字が表す１６進数の値の１Byteデータに変換していく。そして変換したByteデータをＲ→Ｇ→Ｂの順番で１Byteずつ連結していき３２Byteのデータ列にする。（Ｓ６３）

このデータ列は先頭より１２ByteがＰＣＩＤ２２１を表し、１３Byte目から１８Byte目までの６ByteがＭＡＣアドレス２５１を表し、１９Byte目から最後の３２Byte目までの１４Byteがアクセス開始日時情報を表すのでそれぞれに分割して取り出す（Ｓ６４）。

ホストサーバ１０のＣＰＵ１００はクライアント端末２０より受信したＵＲＬを変換して得たＰＣＩＤ２２１とＭＡＣアドレス２５１を、予め記憶装置１２０内のクライアントＤＢに記憶していたＰＣＩＤ１２１および、それに関連づけられたＭＡＣアドレスと比較して一致していればＳ６８６に進み、不一致ならばＳ６７に進む（Ｓ６５）。

ホストサーバ１０のＣＰＵ１００はクライアント端末２０より受信したＵＲＬを変換して得たアクセス開始日時情報とリアルタイムクロック１６０から得た日時情報を比較して差が数３０秒以内であればＳ６８に進み、差が３０秒を超えるのであればＳ６７に進む（Ｓ６６）。

ホストサーバ１０はクライアント端末２０のアクセスを拒否する。（Ｓ６７）
ホストサーバ１０はクライアント端末２０のアクセスを許可してサービスを提供する。（Ｓ６８）

以上、本発明の実施形態について説明したが、本発明は以下のように、さまざまな様態で実施可能である。

＜変形例１＞
前述の実施形態ではクライアント端末２０はＰＣＩＤ２２１、ＭＡＣアドレス２５１、アクセス開始日時情報をテキストデータに変換してＵＲＬに付加してホストサーバ１０をアクセスした。これらを２４bitＢＭＰ形式などのカラー画像データに変換してホストサーバ１０に送信して、ホストサーバ１０がカラー画像データをＰＣＩＤ２２１、ＭＡＣアドレス２５１、アクセス開始日時情報に逆変換してアクセスの許可及び拒否を決定しても良い。以下にその方法を説明する。

ホストサーバ１０の運営者はクライアント端末２０においてＰＣＩＤ２２１、ＭＡＣアドレス２５１、アクセス開始日時情報をカラー画像データに変換してホストサーバ１０に送信するソフトウエアを製作し、ＣＤなどの媒体に書き込んでサービスを受ける権利を持つ利用者に送付し、クライアント端末２０にインストールしてもらう。または、ActiveXやJAVAなどの技術を使ってブラウザ経由でクライアント端末２０にインターネット５０を介してインストールしても良い。
運営者は、ホストサーバ１０においてクライアント端末２０から受信したカラー画像データをＰＣＩＤ２２１、ＭＡＣアドレス２５１、アクセス開始日時情報に逆変換するソフトウエアを作成してホストサーバ１０にインストールする。

利用者がクライアント端末２０を用いてホストサーバ１０をアクセスする動作は前述の実施形態と同一であるので説明は省略する。これよりクライアント端末２０がＰＣＩＤ２２１、ＭＡＣアドレス２５１そしてアクセス開始日時情報をカラー画像データに変換する方法を図８を用いて説明する。

ＰＣＩＤ２２１の形式の一例として半角文字と数字の組み合わせでABDC00112233という１２字すなわち１２Byteで構成されるとする。ＭＡＣアドレス２５１は６Byteである。アクセス開始日時情報の一例として年を西暦で４桁、月を２桁、日を２桁、時間を時分秒を各２桁づつ割り当てて６桁とし日時情報合計で１４字すなわち１４Byteで構成するものとする。上記よりＰＣＩＤ２２１、ＭＡＣアドレス２５１そしてアクセス開始日時情報を合わせたものは合計で１２＋６＋１４＝３２Byteで表されるひとまとめのデータ列として表す事が出来る（Ｓ７１）。

３２Byteのデータ列を変換表や変換式に従って３原色を表すＲ（赤）、Ｇ（緑）、Ｂ（青）のパラメータに変換する。変換の一例をあげるとASCIIコード表によればＰＣＩＤ２２１であるABCD00112233を変換すると文字Ａは４１Ｈという１Byteに変換される。なお、Ｈは１６進数記述である事を示すシンボルとする。同様にして文字Ｂは４２Ｈに、文字Ｃは４３Ｈに変換されＰＣＩＤ２２１全体としては４１Ｈ、４２Ｈ、４３Ｈ、４４Ｈ、３０Ｈ、３０Ｈ、３１Ｈ、３１Ｈ、３２Ｈ、３２Ｈ、３３Ｈ、３３Ｈという１２Byteに変換される。ＭＡＣアドレス２５１は元々が６Byteであるのでそのまま使用する。アクセス開始日時情報は全て数字で表される１４字であるのでASCIIコード表の０から９を表す３０Ｈから３９Ｈにそれぞれ変換される。上記ではASCIIコード表という既知の変換表を用いたが、これに限定されるものではなく他の変換表を用いても良いし、変換した値を逆変換で元の値に戻せる変換式を用いるのであれば数学的に変換してもよい。また、ホストサーバ１０とクライアント端末２０が同じ共通鍵を持ち合ってＤＥＳ等の既存の暗号変換手法を用いても良い。また、ホストサーバ１０が公開鍵と秘密鍵を作成し、公開鍵を公開して、クライアント端末２０がその公開鍵を使って暗号変換して送信し、それを受信したホストサーバ１０が秘密鍵で解読する公開鍵暗号手法を用いても良い。

次に変換した３２Byteデータ列をＲ、Ｇ、Ｂに振り分ける。振り分けの一例として３２Byteデータ列の先頭から１Byte目、２Byte目、・・・３２Byte目と順番をつけて、その順番を３で割って剰余が１となるグループ、２となるグループ、０となるグループに分け、それぞれのグループをＲ、Ｇ、Ｂのグループとする。具体的にはＰＣＩＤ２２１部分を例に挙げると４１Ｈ、４２Ｈ、４３Ｈ、４４Ｈ、３０Ｈ、３０Ｈ、３１Ｈ、３１Ｈ、３２Ｈ、３２Ｈ、３３Ｈ、３３Ｈの１２Byteのデータ列をＲグループが４１Ｈ（１番目）、４４Ｈ（４番目）、３１Ｈ（７番目）、３２Ｈ（１０番目）の４Byteのデータ列となり、Ｇグループが４２Ｈ（２番目）、３０Ｈ（５番目）、３１Ｈ（８番目）、３３Ｈ（１１番目）の４Byteのデータ列となり、Ｂグループが４３Ｈ（３番目）、３０Ｈ（６番目）、３２Ｈ（９番目）、３３Ｈ（１２番目）の４Byteのデータ列となるように分割する。すなわちＲ、Ｇ、Ｂの各パラメータに変換する。以下同様にしてＭＡＣアドレス２５１部分とアクセス開始日時情報部分を表すByteのデータ列もＲ、Ｇ、Ｂの各パラメータに変換する（Ｓ７２）。

カラー画像データの形式の１つである２４bitＢＭＰ形式は１画素あたり赤（Ｒ）、緑（Ｇ）、青（Ｂ）がそれぞれ２５５階調、すなわち１Byteの値で表されるため１画素が３Byteで表される。Ｒ、Ｇ、Ｂの各パラメータであるByteのデータ列を１番目から１組にまとめて１画素として表してカラー画像データに変換する。そして２４bitＢＭＰ形式に従って画像の縦横の大きさなどを表すヘッダー情報を付加してカラー画像データ（ＢＭＰ画像ファイル）を生成する（Ｓ７３）。

生成したカラー画像データはクライアント端末２０からホストサーバ１０へ送信される。

これよりホストサーバ１０がクライアント端末２０から受信したカラー画像データからＰＣＩＤ２２１、ＭＡＣアドレス２５１およびアクセス開始日時情報を取得して、クライアント端末２０のアクセスを許可するか拒否するかを判断する方法を図９を用いて説明する。

ホストサーバ１０はクライアント端末２０からカラー画像データ受信する（Ｓ８１）。

カラー画像データから２４bitＢＭＰ形式に従ってヘッダー情報を削除して、画素情報を取り出し、Ｒ、Ｇ、Ｂの各パラメータに分解する（Ｓ８２）。

Ｒ、Ｇ、Ｂの各パラメータを変換表または変換式に従ってByteデータ列に変換する。これはクライアント端末２０で行われた変換の逆変換を行うと言う事である（Ｓ８３）。

Byteデータ列をＰＣＩＤ２２１、ＭＡＣアドレス２５１およびアクセス開始日時情報に変換する（Ｓ８４）。

ホストサーバ１０のＣＰＵ１００はクライアント端末２０より受信したカラー画像データを変換して得たＰＣＩＤ２２１とＭＡＣアドレス２５１を、予め記憶装置１２０内のクライアントＤＢに記憶していたＰＣＩＤ１２１および、それに関連づけられたＭＡＣアドレスと比較して一致していればＳ８６に進み、不一致ならばＳ８７に進む（Ｓ８５）。

ホストサーバ１０のＣＰＵ１００はクライアント端末２０より受信したカラー画像データを変換して得たアクセス開始日時情報とリアルタイムクロック１６０から得た日時情報を比較して差が数３０秒以内であればＳ８８に進み、差が数３０秒を超えるのであればＳ８７に進む（Ｓ８６）。

ホストサーバ１０はクライアント端末２０のアクセスを拒否する。（Ｓ８７）
ホストサーバ１０はクライアント端末２０のアクセスを許可してサービスを提供する（Ｓ８８）。

実施形態ではホストサーバ１０とクライアント端末２０はインターネット５０を介してＮＴＰサーバ３０より正確な日時情報を得ていた。本発明は以下に説明する変形例のようにＮＴＰサーバ３０を用いない形態でも実施可能である。
＜変形例２＞

以下より図１においてＮＴＰサーバ３０が無い形態において、変形例２の動作を図１０に示すデータの流れ図を用いて説明する。利用者がクライアント端末２０の電源を入れるとＣＰＵ２００は記憶装置２２０から基本ソフトを読み込み実行する。基本ソフトが起動した後に利用者は操作装置２３０を介してクライアント端末２０へインターネット５０への通信を行うためのブラウザを起動する操作を行う（Ｓ９１）。

クライアント端末２０の利用者はブラウザでホストサーバ１０のTop Pageにアクセスする（Ｓ９２）。
クライアント端末２０からアクセスを受けたホストサーバ１０のＣＰＵ１００はリアルタイムクロック１６０からアクセス開始日時の情報を得てその値をＲＡＭ１１０に記憶すると共に、HTML言語やスクリプト言語などのWEB記述言語を用いてにアクセス開始日時を示す時計をブラウザ上に表示するWEBページを作成する。また、利用者がブラウザに表示された時計を読み取って、その日時の値を入力する入力枠と、ＰＣＩＤ２２１とＭＡＣアドレス２５１を入力する入力枠と、入力された値をホストサーバ１０に送信する送信ボタンをブラウザに表示するWEBページを作成する。そして、クライアント端末２０に作成したWEBページを送信する（Ｓ９３）。なお、ブラウザに表示される時計の形状は長針と短針で時刻を表すアナログ時計を表した物でも良いし、数値で時刻を表すデジタル時計やこれらを組み合わせた物でも良い。ようするに利用者が目視して時刻を判別できる表示であればよい。なお、ホストサーバ１０のリアルタイムクロック１６０は日本標準時や世界標準時に合致していなくても良い。

ホストサーバ１０からWEBページを受信したクライアント端末２０は受信したWEB記述言語に従ってブラウザにホストサーバ１０がクライアント端末２０からのアクセス開始日時を示した時計の画像と入力枠を表示する。また、利用者のＰＣＩＤ２２１やＭＡＣアドレス２５１の入力を促すメッセージと入力枠も表示される。利用者はブラウザに表示された時計の画像を目視して時計が示している時刻を判断して、操作装置２３０を介してその時刻の値を入力枠に打ち込む、また同様にＰＣＩＤ２２１とＭＡＣアドレス２５１を入力枠に打ち込む。そして送信ボタンをクリックするとWEB記述言語がＰＣＩＤ２２１、ＭＡＣアドレス２５１そして時刻情報をカラーコード化してブラウザのＵＲＬ入力枠に書き込む。（Ｓ９４）
ブラウザはＵＲＬ入力枠に書き込まれたホスト名をＤＮＳホストサーバに問い合わせて、ホストサーバ１０のＩＰアドレスがａａａ．ａａａ．ａａａ．ａａａであることを知り、ホストサーバ１０に送信する（Ｓ９５）

ホストサーバ１０はクライアント端末２０から受け取ったＵＲＬを解読してＰＣＩＤ２２１、ＭＡＣアドレス２５１そして時刻情報を得る。ホストサーバ１０は記憶装置１２０に予め記憶してあるＰＣＩＤ１２１および、それに関連づけられたＭＡＣアドレスがＵＲＬを解読して得たＰＣＩＤ２２１およびＭＡＣアドレス２５１と一致しているかを調べる。
また、ホストサーバ１０はＲＡＭ１１０に記憶してあるクライアント端末２０からのアクセス開始日時とＵＲＬを解読して得た時刻がほぼ一致するかを調べる。ここでいうほぼ一致の意味はクライアント端末２０に表示された時計の長針と短針からなる時刻を利用者が目視して読み取ったときのあいまいさによる誤差である。利用者が健常者であれば３分程度の誤差を見込めばよい。すなわち、ホストサーバ１０がWEB記述言語で表示した時刻に対して、ＵＲＬを解読して得た時刻の差が３分以内かを調べる。（Ｓ９６）

ホストサーバ１０はクライアント端末２０から受け取ったＰＣＩＤ２２１とＭＡＣアドレス２５１が予め記憶装置１２０に記憶してある値と一致し、かつ、WEB言語で表示したクライアント端末２０からのアクセス開始日時を表す時計の画像に対して、利用者がその時計の画像を読みとってクライアント端末２０に入力した時刻が３分以内の差であればクライアント端末２０にアクセス許可を意味する信号を送信すると共に、以後、通信が切断されるまでクライアント端末２０にサービスを提供する。ＰＣＩＤ２２１またはＭＡＣアドレス２５１が不一致だった、または受け取った時刻がWEB記述言語で表示した時計の画像の示す時刻に対して３分を超える差があればクライアント端末２０にアクセス拒否を意味する信号を送信するとともに、以後、通信を拒否する。具体的な通信拒否の方法としてはクライアント端末２０からホストサーバ１０へのＩＰパケットのヘッダー情報にある送信元ＩＰアドレスを読み取って、クライアント端末２０のＩＰアドレスであるｂｂｂ．ｂｂｂ．ｂｂｂ．ｂｂｂであるパケットを捨てれば良い（Ｓ９７）。

クライアント端末２０はホストサーバ１０からアクセス許可を意味する信号を受信したならば以後、続けてホストサーバ１０のサービスを受ける。あるいはアクセス拒否を意味する信号を受信したならばホストサーバ１０側から通信を拒否される（Ｓ９８）。

変形例２は変形例１と組み合わせて、クライアント端末２０はＰＣＩＤ２２１、ＭＡＣアドレス２５１、時刻をＵＲＬに文字列として付加するのではなく、カラー画像データに変換してホストサーバ１０に送信する。ホストサーバ１０は受信したカラー画像データを逆変換して照合を行う。という方法を採っても良い。

１ 通信システム
１０ ホストサーバ
２０ クライアント端末
３０ ＮＴＰサーバ
５０ インターネット
１００，２００ ＣＰＵ
１００ａ ＩＤ判定手段
１００ｂ データ抽出手段
１００ｃ 抽出変換手段
１００ｄ 正当性判定手段
１００ｅ サービス許諾手段
１１０，２１０ ＲＡＭ
１２０，２２０ 記憶装置
１２１，２２１ ＰＣＩＤ
１３０，２３０ 操作装置
１４０，２４０ 表示装置
１５０，２５０ 通信装置
１５１，２５１ ＭＡＣアドレス
１６０，２６０ リアルタイムクロック
１９０，２９０ バス

Claims (5)

1. 通信回線を介して互いに接続されたホストサーバと、当該ホストサーバからサービスを受ける少なくとも１個のクライアント端末と、を含み、
   当該ホストサーバは、
   アクセスしてきたクライアント端末の端末ＩＤと予めクライアントＤＢに記憶してある基準ＩＤとの一致不一致を判定するＩＤ判定手段と、
   当該ＩＤ判定手段がＩＤ一致と判定したクライアント端末のＵＲＬから、当該アクセスに係るアクセス開始日時が直接読み込み不能に埋め込まれた混在テキストデータを抽出するデータ抽出手段と、
   当該データ抽出手段が抽出した混在テキストデータから、埋め込まれているアクセス開始日時に係るデータを抽出して直接読み込み可能なアクセス開始日時に変換する抽出変換手段と、
   当該抽出変換手段が抽出変換したアクセス開始日時と、矯正済みリアルタイムとを比較して当該アクセスの正当性を判定する正当性判定手段と、
   当該正当性判定手段が正当と判定したクライアント端末に対してサービス開始を許諾するサービス許諾手段と、を含み、
   当該クライアント端末は、
   自己の端末ＩＤを当該ホストサーバに送信する送信手段と、
   当該ホストサーバに対する矯正済みアクセス開始日時に係るデータを、テキストデータに変換して他のテキストデータに直接読み込み不能に埋め込んで混在テキストデータを生成するデータ生成手段と、
   当該混在テキストデータを当該ホストサーバへ送信する送信手段と、を含む、
   ことを特徴とする通信システム。
2. 前記抽出変換手段は、カラーコード化された混在テキストデータからアクセス開始日時を抽出変換するように構成してあり、
   前記データ生成手段は、テキストデータをカラーコード化することによって混在テキストデータを生成するように構成してある
   ことを特徴とする請求項１記載の通信システム。
3. 通信回線を介して互いに接続されたホストサーバと、当該ホストサーバからサービスを受ける少なくとも１個のクライアント端末と、を含み、
   当該ホストサーバは、
   アクセスしてきたクライアント端末の端末ＩＤと予めクライアントＤＢに記憶してある基準ＩＤとの一致不一致を判定するＩＤ判定手段と、
   当該ＩＤ判定手段がＩＤ一致と判定したクライアント端末が送信した当該アクセスに係るアクセス開始日時を意味するカラー画像データを受信するデータ受信手段と、
   当該データ受信手段が受信したカラー画像データをアクセス開始日時に変換する変換手段と、
   当該変換手段が変換したアクセス開始日時と、矯正済みリアルタイムとを比較して当該アクセスの正当性を判定する正当性判定手段と、
   当該正当性判定手段が正当と判定したクライアント端末に対してサービス開始を許諾するサービス許諾手段と、を含み、
   当該クライアント端末は、
   自己の端末ＩＤを当該ホストサーバに送信する手段と、
   当該ホストサーバに対する矯正済みアクセス開始日時に係るデータを、カラー画像データに変換するデータ変換手段と、
   当該カラー画像データを当該ホストサーバへ送信する送信手段とを含む、
   ことを特徴とする通信システム。
4. 通信回線を介して互いに接続されたホストサーバと、当該ホストサーバからサービスを受ける少なくとも１個のクライアント端末と、を含み、
   当該ホストサーバは、
   アクセスしてきたクライアント端末の端末ＩＤと予めクライアントＤＢに記憶してある基準ＩＤとの一致不一致を判定するＩＤ判定手段と、
   リアルタイムクロックから得たアクセス開始日時データを、当該ＩＤ判定手段がＩＤ一致と判定したクライアント端末へ送信するデータ送信手段と、
   当該アクセス開始日時を検索可能に記憶する日時記憶手段と、
   当該クライアント端末から送信された端末使用者入力に係る入力アクセス開始日時が直接読み込み不能に埋め込まれたコード化データから入力アクセス開始日時データを抽出するデータ抽出手段と、
   当該データ抽出手段が抽出した入力開始日時データを、直接読み込み可能な入力アクセス開始日時に変換する抽出変換手段と、
   当該抽出変換手段が抽出した入力アクセス開始日時と、当該日時記憶手段が記憶するアクセス開始日時とを比較して当該アクセスの正当性を判定する正当性判定手段と、
   当該正当性判定手段が正当と判定したクライアント端末に対してサービス開始を許諾するサービス許諾手段と、を含み、
   当該クライアント端末は、
   自己の端末ＩＤを当該ホストサーバに送信する手段と、
   受信したアクセス開始日時データに係るアクセス開始日時を端末使用者が目視できるように表示する表示手段と、
   端末使用者が入力アクセス開始日時を入力する日時入力手段と、
   当該日時入力手段から入力された入力アクセス開始日時に係るデータを、コード化データに変換する変換手段と、
   当該コード化データを当該ホストサーバに送信する送信手段と、を含む、
   ことを特徴とする通信システム。
5. 通信回線を介して互いに接続されたホストサーバと、当該ホストサーバからサービスを受ける少なくとも１個のクライアント端末と、によって実行される通信方法であって、
   当該ホストサーバは、
   アクセスしてきたクライアント端末の端末ＩＤと予めクライアントＤＢに記憶してある基準ＩＤとの一致不一致を判定するＩＤ判定ステップと、
   当該ＩＤ判定手段がＩＤ一致と判定したクライアント端末のＵＲＬから、当該アクセスに係るアクセス開始日時が直接読み込み不能に埋め込まれた混在テキストデータを抽出するデータ抽出ステップと、
   当該データ抽出手段が抽出した混在テキストデータから、埋め込まれているアクセス開始日時に係るデータを抽出して直接読み込み可能なアクセス開始日時に変換する抽出変換ステップと、
   当該抽出変換手段が抽出変換したアクセス開始日時と、矯正済みリアルタイムとを比較して当該アクセスの正当性を判定する正当性判定ステップと、
   当該正当性判定手段が正当と判定したクライアント端末に対してサービス開始を許諾するサービス許諾ステップ手段と、を実行し、
   当該クライアント端末は、
   自己の端末ＩＤを当該ホストサーバに送信するステップと、
   当該ホストサーバに対する矯正済みアクセス開始日時に係るデータを、テキストデータに変換して他のテキストデータに直接読み込み不能に埋め込んで混在テキストデータを生成するデータ生成ステップと、
   当該混在テキストデータを当該ホストサーバへ送信する送信ステップと、を実行する
   ことを特徴とする通信方法。

Images