(57)【特許請求の範囲】
【請求項１】
クライアントとサーバ間で要求に応じたデータ通信を行うデータ通信システムにおいて、
上記クライアントは、
操作手段と、
ユーザの上記操作手段に対する操作に応じて、上記クライアントと上記サーバとの取引内容を示す情報を含むクライアントリクエストを生成し、該クライアントリクエストを上記サーバに送信するクライアントリクエスト手段と、
上記サーバから第１のサーバレスポンスを受信すると、該第１のサーバレスポンスに含まれる時刻情報で示される時刻と、上記クライアントに含まれる内部時計で検出された現在の時刻との差である第１の時刻差を算出し、該第１の時刻差が上記第１のサーバレスポンスに含まれる許容時刻差以内であるか否かを確認し、該確認結果及び上記クライアントに含まれる内部時計で検出された現在の時刻を示す時刻情報を含むクライアントレスポンスを生成して上記サーバに送信するクライアントレスポンス手段と、
上記クライアントレスポンスに含まれた上記時刻情報で示される時刻に基づいて算出される第２の時刻差が上記許容時刻差以内でないことを示す確認結果が含まれる第２のサーバレスポンスを上記サーバから受信すると、上記サーバとの通信を停止する手段とを備え、
上記サーバは、
上記クライアントから上記クライアントリクエストを受信すると、該クライアントリクエストに基づいて、上記取引内容に対応するサービス及び該サービスに関する上記許容時刻差を検索し、検索した上記サービス、上記許容時刻差及び上記サーバに含まれる内部時計で検出された現在の時刻を示す時刻情報を含む上記第１のサーバレスポンスを生成して上記クライアントに送信する第１のサーバレスポンス手段と、
上記第１の時刻差が上記許容時刻差以内でないことを示す確認結果が含まれる上記クライアントレスポンスを上記クライアントから受信した場合に、上記クライアントとの通信を停止し、上記第１の時刻差が上記許容時刻差以内であることを示す確認結果が含まれる上記クライアントレスポンスを上記クライアントから受信した場合に、上記クライアントレスポンスに含まれる時刻情報で示される時刻と、上記サーバの内部時計で検出された現在の時刻との差である第２の時刻差を算出し、該第２の時刻差が上記許容時刻差以内であるか否かを確認し、該確認結果及び上記サーバの時刻情報を含む第２のサーバレスポンスを生成して上記クライアントに送信する第２のサーバレスポンス手段と、
を備えたことを特徴とするデータ通信システム。
【請求項２】
上記許容時刻差が設定可能である
ことを特徴とする請求項１に記載のデータ通信システム。
【請求項３】
上記クライアントリクエストと、上記クライアントレスポンスと、上記第１および第２のサーバレスポンスとにはそれぞれ署名情報が含まれている
ことを特徴とする請求項１または２に記載のデータ通信システム。
【請求項４】
上記クライアントリクエストと、上記クライアントレスポンスと、上記第１および第２のサーバレスポンスは、いずれも上記クライアント及び上記サーバにおいて保存される
ことを特徴とする請求項１〜３のいずれかに記載のデータ通信システム。
【請求項５】
上記クライアント及び上記サーバは、上記クライアントに含まれる内部時計で検出される時刻を補正するクライアント時刻情報補正手段及び上記サーバに含まれる内部時計で検出される時刻を補正するサーバ時刻情報補正手段を有する
ことを特徴とする請求項１〜４のいずれかに記載のデータ通信システム。
【請求項６】
クライアントとサーバ間で要求に応じたデータ通信を行うデータ通信方法において、
ユーザの操作手段に対する操作に応じて、上記クライアントと上記サーバとの取引内容を示す情報を含むクライアントリクエストを生成し、該クライアントリクエストを上記クライアントから上記サーバに送信するステップと、
上記クライアントから上記クライアントリクエストを受信すると、該クライアントリクエストに基づいて、上記取引内容に対応するサービス及び該サービスに関する許容時刻差を検索し、検索した上記サービス、上記許容時刻差及び上記サーバに含まれる内部時計で検出された現在の時刻を示す時刻情報を含む上記第１のサーバレスポンスを生成して上記サーバから上記クライアントに送信するステップと、
上記サーバから上記第１のサーバレスポンスを受信すると、該第１のサーバレスポンスに含まれる時刻情報で示される時刻と、上記クライアントに含まれる内部時計で検出された現在の時刻との差である第１の時刻差を算出し、該第１の時刻差が上記第１のサーバレスポンスに含まれる許容時刻差以内であるか否かを確認し、該確認結果及び上記クライアントに含まれる内部時計で検出された現在の時刻を示す時刻情報を含むクライアントレスポンスを生成して上記クライアントから上記サーバに送信するステップと、
上記第１の時刻差が上記許容時刻差以内でないことを示す確認結果が含まれる上記クライアントレスポンスを上記クライアントから受信した場合に、上記クライアントとの通信を停止し、上記第１の時刻差が上記許容時刻差以内であることを示す確認結果が含まれる上記クライアントレスポンスを上記クライアントから受信した場合に、上記クライアントレスポンスに含まれる時刻情報で示される時刻と、上記サーバの内部時計で検出された現在の時刻との差である第２の時刻差を算出し、該第２の時刻差が上記許容時刻差以内であるか否かを確認し、該確認結果及び上記サーバの時刻情報を含む第２のサーバレスポンスを生成して上記サーバから上記クライアントに送信するステップと、
上記第２の時刻差が上記許容時刻差以内でないことを示す確認結果が含まれる第２のサーバレスポンスを上記サーバから受信すると、上記サーバとの通信を停止するステップと、
を備えたことを特徴とするデータ通信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、例えば、クライアントとサーバ間で要求に応じて行われるデータ通信に適用して好適なデータ通信システム及びデータ通信方法に関する。
【背景技術】
【０００２】
例えば、インターネットを利用した商品の販売など、近年ではネットワークを利用したオンライン取り引きが盛んになっている。また、株式のオンライントレードなどもその一つである。株式のように時々刻々と変化するデータに関しての取り引きでは、いつ、誰がその取り引きを行ったかという情報が大変重要になってくる。
【０００３】
現在では、サーバで過去の取引情報を管理したり、ユーザに取り引き通知を電子メールを介して行うという手法も利用されている。この過去の取引情報を参照すれば、取引の時期や実行者を検索して取引が可能な時刻や時間帯を知ることができる。
【０００４】
また、データベース接続情報、外部時刻源接続情報等の設定情報をパスワードつき暗号鍵により暗号化して設定情報ファイルに保存し、データベース接続処理、外部時刻源接続処理等の際には、設定情報ファイルから読み出した暗号化された設定情報を復号化し、各処理を実行し、設定情報の改ざんを防止するタイムスタンプシステムが開示されている（特許文献１参照）。
【特許文献１】特開２００４−２６６５３７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかし、上述したサーバで過去の取引情報を管理する方法では、サーバ側で保存される過去の取引情報の改ざんなどを行なうことができる可能性が残っているため、取引が可能な時刻や時間帯が限られているサービスでは、取引がこの時刻や時間帯で行われたか否かを判別することができないという不都合があった。
【０００６】
また、特許文献１に記載の技術は、公開鍵暗号基盤を用いたタイムスタンプサービスを開示しているのみであり、この場合では、システムが大規模になることがあり、また、その時刻に通信が行われたことを示すものではなく、その時刻にそのデータが存在していたことを示すのみであるため、このデータを参照しても、取引の時期や実行者を検索することができないという不都合があった。
【０００７】
そこで、本発明は、サービスの可能な相手であることを時刻情報に基づいて自動的に判別することができると共に、取引情報の改ざんを防止して改ざんされた情報によるサービスの否認を防止することができるデータ通信システム及びデータ通信方法を提供することを目的とするものである。
【課題を解決するための手段】
【０００８】
上記課題を解決するため、本発明は、ユーザの操作手段に対する操作に応じて、クライアントとサーバとの取引内容を示す情報を含むクライアントリクエストを生成し、該クライアントリクエストをクライアントからサーバに送信する。そして、クライアントからクライアントリクエストを受信すると、該クライアントリクエストに基づいて、取引内容に対応するサービス及び該サービスに関する許容時刻差を検索し、検索したサービス、許容時刻差及びサーバに含まれる内部時計で検出された現在の時刻を示す時刻情報を含む第１のサーバレスポンスを生成してサーバからクライアントに送信する。次に、サーバから第１のサーバレスポンスを受信すると、該第１のサーバレスポンスに含まれる時刻情報で示される時刻と、クライアントに含まれる内部時計で検出された現在の時刻との差である第１の時刻差を算出し、該第１の時刻差が第１のサーバレスポンスに含まれる許容時刻差以内であるか否かを確認し、該確認結果及びクライアントに含まれる内部時計で検出された現在の時刻を示す時刻情報を含むクライアントレスポンスを生成してクライアントからサーバに送信する。続いて、第１の時刻差が許容時刻差以内でないことを示す確認結果が含まれるクライアントレスポンスをクライアントから受信した場合に、クライアントとの通信を停止し、第１の時刻差が許容時刻差以内であることを示す確認結果が含まれるクライアントレスポンスをクライアントから受信した場合に、クライアントレスポンスに含まれる時刻情報で示される時刻と、サーバの内部時計で検出された現在の時刻との差である第２の時刻差を算出し、該第２の時刻差が許容時刻差以内であるか否かを確認し、該確認結果及びサーバの時刻情報を含む第２のサーバレスポンスを生成してサーバからクライアントに送信する。そして、第２の時刻差が許容時刻差以内でないことを示す確認結果が含まれる第２のサーバレスポンスをサーバから受信すると、サーバとの通信を停止する。
【００１１】
クライアントからサーバあるいはサーバからクライアントに送信されるメッセージ（レスポンス）の時間情報を付随させて各々自端末の時刻情報と相手の時刻情報を比較し、時間差がプロファイル情報に基づく設定値より大きい場合にはネゴシエーションに対してエラーを返すことができるため、互いの取り引き時刻をしぼり込むことを可能にすることにより、取引可能な時刻を自動的に判別することができる。
【００１６】
さらに、クライアント、サーバ間のメッセージに対して署名付けを行い、さらにメッセージはクライアント及びサーバに保存することにより、クライアントにとってはサーバ側を、サーバにとってはクライアント側の否認防止をする証拠とすることができる。また、P2P（ピアツーピア）などの不特定多数の個人間で直接情報のやり取りを行なう場合の小規模の取り引きなどにも応用することができる。
【発明の効果】
【００１７】
本発明によれば、サービスの可能な相手であることを時刻情報に基づいて自動的に判別することにより、取り引き時刻をしぼり込み、サービスに応じて取引の相手を限定することができる。また、取引情報の改ざんを防止して改ざんされた情報によるサービスの否認を防止することができる。
【発明を実施するための最良の形態】
【００１８】
以下に、本発明の実施の形態について、適宜、図面を参照しながら詳細に説明する。
図１は、本実施の形態によるデータ通信システムの構成図である。図１は、データ通信システムにおける各端末間の接続をあらわしたものである。
【００１９】
図１において、例えば、パーソナルコンピュータ（ＰＣ）１１、パーソナルデジタルアシスタント（ＰＤＡ）１２、送信部１３−２及び受信部１３−１からなる個人認証デバイス１３、サーバ１４、パーソナルコンピュータ（ＰＣ）１５、パーソナルデジタルアシスタント（ＰＤＡ）１６、送信部１７−２及び受信部１７−１からなる個人認証デバイス１７など様々な端末がネットワーク（有線・無線）１８を介して接続される。
【００２０】
ここで、送信部１３−２及び受信部１３−１からなる個人認証デバイス１３、送信部１７−２及び受信部１７−１からなる個人認証デバイス１７は、例えば、携帯電話による商品の注文とベンダー装置による認証後の課金と商品引渡し、自動料金収受システムのＥＴＣ（Electronic  Toll  Collection）カードによる有料道路の通過と読取装置による認証後の課金などの、公開鍵と秘密鍵により認証を行ってセキュリティを保つことができるものである。
【００２１】
また、ネットワーク（有線・無線）１８による接続形式に関しても、例えば、無線による近距離通信（Bluetoothよりも低速で伝送距離も短いが代わりに省電力で低コストのZigbee（ジグビー）, データを1GHz程度の極めて広い周波数帯に拡散して送受信を行なうＵＷＢ（Ultra Wide Band）など）、又は有線によりキーボードやマウス、モデム、ジョイスティックなどの周辺機器とパソコンを結ぶデータ伝送路であるＵＳＢ（Universal Serial Bus）接続など様々な形態が適用される。
【００２２】
また、ネットワーク（有線・無線）１８による通信路は、特定のパス又はすべてのパスを暗号化することも可能であり、これらを暗号化することでセキュリティ強度はさらに上がることになる。
【００２３】
本実施の形態のデータ通信システムにより、上述したパーソナルコンピュータ（ＰＣ）１１、パーソナルデジタルアシスタント（ＰＤＡ）１２、送信部１３−２及び受信部１３−１からなる個人認証デバイス１３、サーバ１４、パーソナルコンピュータ（ＰＣ）１５、パーソナルデジタルアシスタント（ＰＤＡ）１６、送信部１７−２及び受信部１７−１からなる個人認証デバイス１７などの各端末機器が持つ時刻情報を利用してデータ通信のためのネゴシエーションを行うことにより、端末間のデータのやりとりの時刻をある一定の範囲内で特定することができる。
【００２４】
また、上述したパーソナルコンピュータ（ＰＣ）１１、パーソナルデジタルアシスタント（ＰＤＡ）１２、送信部１３−２及び受信部１３−１からなる個人認証デバイス１３、サーバ１４、パーソナルコンピュータ（ＰＣ）１５、パーソナルデジタルアシスタント（ＰＤＡ）１６、送信部１７−２及び受信部１７−１からなる個人認証デバイス１７などの各端末間でやりとりされるデータをそれぞれ保存することにより、その時刻及びデータをやりとり後に改ざんしたり、改ざんされたデータにより相手を否認したりすることを防止することができる。
【００２５】
図２は、各端末間のメッセージの送受信のシーケンス図である。図２は、各端末間のメッセージのやり取りのシーケンスを簡略化して図示したものである。
図２において、まず、メッセージなどの要求を送る側の端末をクライアント２１とし、要求を受ける側の端末をサーバ２２とする。また、図中、上から下に向けて時間軸が設けられている。
【００２６】
このとき、Ｔ１時刻で、クライアント２１はサーバ２２にネゴシエーションの要求を出す。Ｔ２時刻で、サーバ２２はクライアント２１からの要求を基に対象となるサービスの条件を示すプロファイルを選択し、選択されたプロファイル情報にサーバ２２の持つ時刻情報を付加してクライアント２１に送信する。
【００２７】
このサーバ２２から送信されるプロファイル情報には、サービスを受ける際の時刻情報の誤差範囲も含まれ、この値は厳密な時刻が必要な著作権を有するコンテンツの提供サービスでは狭く、そうでもないサービスは広く設定される。また、誤差範囲の設定の有無も選択可能である。
【００２８】
Ｔ３時刻で、サーバ２２からのレスポンスを受信したクライアント２１は、自端末の時刻情報とサーバ２２から送られてきた時刻情報を比較し、この比較結果がプロファイル情報に示される誤差範囲内に含まれるか否かをチェックする。このチェックが成功すれば、クライアント２１は、プロファイル情報を満足するサービスを選択できるかどうかのネゴシエーションを行い、ネゴシエーションの成功又は失敗を示すクライアントネゴシエーション結果を自端末の時刻情報をつけてサーバ２２に送信する。
【００２９】
Ｔ４時刻で、サーバ２２は、自端末の時刻情報とクライアントの時刻情報を比較し、この比較結果をクライアント２１からのネゴシエーション結果に対して受け入れるか否かを判断し、受け入れるのであればネゴシエーションの成功、受け入れないのであればネゴシエーションの失敗を示すサーバネゴシエーション結果をサーバからのレスポンスとしてクライアント２１に送信する。
【００３０】
ここで、各メッセージは各端末により署名付けがされ、改ざんができないようにしてある。また、各メッセージは各端末にデータ通信による取引情報として保存され、検証のときに利用される。また、クライアントからの要求に対して、サーバから拒否された場合にはＴ３時刻、Ｔ４時刻のシーケンスは行われない。
【００３１】
図３は、各端末間で送受信されるメッセージの内容を示すシーケンス図である。図３は、図２で示されたシーケンスで送信されるデータを表している。
図３において、まず、メッセージなどの要求を送る側の端末をクライアント３１とし、要求を受ける側の端末をサーバ３２とする。また、図中、上から下に向けて時間軸が設けられている。また、各メッセージのフォーマットを左から先頭に配置した例を示している。
【００３２】
はじめに、Ｔ１１時刻で、クライアント３１からクライアントリクエスト３３として、リクエスト３３−１、データ３３−２、その２つの情報（リクエスト３３−１、データ３３−２）の署名３３−３及び証明書３３−４をサーバ３２に送信する。証明書３３−４は、クライアントリクエスト３３及び後述するクライアントレスポンス３５の署名の検証に用いられる。
【００３３】
Ｔ１２時刻で、サーバ３２はクライアントリクエスト３３に対するサーバレスポンス（１）３４として、レスポンス（サーバ側）３４−１、プロファイル（許容時刻差）３４−２、時刻情報（サーバ側）３４−３、データ３４−４、その４つの情報（レスポンス（サーバ側）３４−１、プロファイル（許容時刻差）３４−２、時刻情報（サーバ側）３４−３、データ３４−４）に対する署名３４−５及び証明書３４−６をクライアント３１に送信する。証明書３４−６はサーバレスポンス（１）３４及び後述するサーバレスポンス（２）３６で署名の検証に利用される。
【００３４】
Ｔ１３時刻で、クライアント３１はサーバ３２からのサーバレスポンス（１）３４に対してネゴシエーションを行い、ネゴシエーションの結果をクライアントレスポンス３５として、レスポンス（クライアント側）３５−１、時刻情報（クライアント側）３５−２、データ３５−３及びこれにその３つの情報（レスポンス（クライアント側）３５−１、時刻情報（クライアント側）３５−２、データ３５−３）に対する署名３５−４を付加してサーバ３２に送信する。
【００３５】
Ｔ１４時刻で、サーバ３２はクライアントレスポンス３５に対してこれを受け入れるかどうかの判断を行い、判断結果をサーバレスポンス（２）３６として、レスポンス（サーバ側）３６−１、時刻情報（サーバ側）３６−２、データ３６−３及びその３つの情報（レスポンス（サーバ側）３６−１、時刻情報（サーバ側）３６−２、データ３６−３）の署名３６−４をクライアント３１に送信する。
ここで、クライアントレスポンス３５の各項目はクライアント３１、サーバ３２のネゴシエーション拒否などによるデータ通信エラーの場合には含まれない場合もある。
【００３６】
なお、上述した署名３３−３及び証明書３３−４、署名３４−５及び証明書３４−６、署名３５−４及び署名３６−４は、例えば、ＳＳＬ（Secure Socket Layer）などのインターネット上で情報を暗号化して送受信するプロトコルを用いることにより、データを暗号化し、プライバシーに関わる情報や課金の際のクレジットカード番号、企業秘密などを安全に送受信することができる。
【００３７】
このＳＳＬは公開鍵暗号や秘密鍵暗号、デジタル証明書、ハッシュ関数などのセキュリティ技術を組み合わせ、データの盗聴や改ざん、なりすましを防ぐことができる暗号化方式である。
例えば、上述した署名は秘密鍵として用いられ、各メッセージの複数の情報を暗号化する際にハッシュ値が生成される。また、上述した証明書は公開鍵として用いられ、署名単独では公開鍵が本人のものであるか確認できないが、証明書を署名に付属させることにより、データが改ざんされていないことと共に、データの作成者を認証局を通して証明することができる。
【００３８】
図４はクライアント側の動作を示すフローチャートである。
図４において、まず、クライアントは、証明書及び送信すべきデータの準備を行う（ステップＳ１）。具体的には、図３に示したクライアントリクエスト３３としてのデータ３３−２及び証明書３３−４を準備する。例えば、データ３３−２はデータ通信の必須事項などを記載し、さらに、認証局に証明書を発行してもらうことによって、データの出所を確実にする。証明書は、認証局が発行する、デジタル署名解析用の公開鍵が真正であることを証明するデータである。
【００３９】
次に、クライアントは、リクエストの作成を行う（ステップＳ２）。具体的には、図３に示したクライアントリクエスト３３としてのリクエスト３３−１を作成する。例えば、商品の購入やコンテンツのダウンロードのリクエストを示す各アイコンに対してクリックで選択することによりリクエスト３３−１を作成することができる。
【００４０】
さらに、クライアントは、署名の作成を行う（ステップＳ３）。具体的には、図３に示したクライアントリクエスト３３としての２つの情報（リクエスト３３−１、データ３３−２）の署名３３−３を作成する。例えば、２つの情報（リクエスト３３−１、データ３３−２）を秘密鍵である署名３３−３により暗号化する際にハッシュ値を生成する。署名は、デジタル文書の正当性を保証するために付けられる暗号化された署名情報である。
【００４１】
ここで、クライアントは、図３に示したクライアントリクエスト３３をサーバ３２に送信する（ステップＳ４）。すると、クライアントは、図３に示したサーバ３２からのサーバレスポンス（１）３４を受信する（ステップＳ５）。
そこで、クライアントは、証明書による検証を行う（ステップＳ６）。具体的には、図３に示したサーバ３２からのサーバレスポンス（１）３４の証明書３４−６を公開鍵として用いて署名３４−５の検証を行う。
【００４２】
証明書は、公開鍵暗号方式の応用によって、文書の作成者を証明し、かつその文書が改竄されていないことを保証するものである。署名者であるサーバは、自身の秘密鍵を用いて暗号化した署名３４−５を文書に付加して送る。受取人であるクライアントは、署名者であるサーバの公開鍵を用いて署名３４−５を復号化することによりハッシュ値が生成される。このハッシュ値がサーバから送信された４つの情報を署名３４−５により暗号化することにより生成されるハッシュ値と一致して、サーバから送信された複数の情報が正しい内容かどうか確認をする。これは、第三者による偽造防止の他、署名者がその文書を作成したことの証明にも用いることができる。
【００４３】
次に、クライアントは、サーバの受入を許可するか否かの判断をする（ステップＳ７）。具体的には、ステップＳ６の検証の結果によりサーバから送信された複数の情報が正しい内容である場合には、サーバの受入を許可し、正しい内容でない場合には、サーバの受入を拒否する。
【００４４】
ステップＳ７の判断でサーバの受入を許可するときは、レスポンスの検証を行う（ステップＳ８）。具体的には、図３に示したサーバ３２からのサーバレスポンス（１）３４のレスポンス（サーバ側）３４−１、プロファイル（許容時刻差）３４−２、時刻情報（サーバ側）３４−３、データ３４−４が改ざんされていないかどうかをチェックする。
ステップＳ７の判断でサーバの受入を許可しないとき、及びステップＳ８の判断でレスポンスの検証が失敗のときは、ステップＳ１３へ移行する。
【００４５】
ステップＳ８の判断でレスポンスの検証が成功のときは、拒否レスポンスをするか否かの判断をする（ステップＳ９）。具体的には、図３に示したサーバ３２へのクライアントレスポンス３５により拒否レスポンスをすることなく処理を終了するか否かの判断をする。ステップＳ９の判断で拒否レスポンスをするときは、そのまま処理を終了する。
【００４６】
ステップＳ９の判断で拒否レスポンスをしないときは、クライアントは、プロファイルの確認を行う（ステップＳ１０）。具体的には、図３に示したサーバ３２からのサーバレスポンス（１）３４のプロファイル（許容時刻差）３４−２を確認する。
次に、クライアントは、自端末の時刻を取得する（ステップＳ１１）。具体的には、クライアントは、内部時計から自端末の図３に示した時刻情報（クライアント側）３５−２を取得する。
【００４７】
そして、クライアントは、ネゴシエーションを行う（ステップＳ１２）。具体的には、クライアントは、自端末の時刻情報とサーバから送られてきた時刻情報を比較し、この比較結果がプロファイル情報に示される誤差範囲内に含まれるか否かをチェックする。このチェックが成功すれば、クライアントは、プロファイル情報を満足するサービスを選択できるかどうかのネゴシエーションを行う。
【００４８】
そこで、クライアントは、レスポンス及びデータの準備を行う（ステップＳ１３）。具体的には、ステップＳ１２のネゴシエーションの成功又は失敗を示すクライアントネゴシエーション結果と自端末の時刻情報を用意する。ステップＳ７の判断でサーバの受入を許可しないとき、及びステップＳ８の判断でレスポンスの検証が失敗のときは、ネゴシエーションの失敗を示すクライアントネゴシエーション結果となる。
【００４９】
次に、クライアントは、レスポンスを作成する（ステップＳ１４）。具体的には、図３に示したサーバ３２へのクライアントレスポンス３５としてレスポンス（クライアント側）３５−１を作成する。
そして、クライアントは、署名を行う（ステップＳ１５）。具体的には、図３に示したサーバ３２へのクライアントレスポンス３５として３つの情報（レスポンス（クライアント側）３５−１、時刻情報（クライアント側）３５−２、データ３５−３）に対する署名３５−４を行う。
【００５０】
そこで、クライアントは、サーバへの送信を行う（ステップＳ１６）。具体的には、図３に示したサーバ３２へのクライアントレスポンス３５として、レスポンス（クライアント側）３５−１、時刻情報（クライアント側）３５−２、データ３５−３及びこれにその３つの情報（レスポンス（クライアント側）３５−１、時刻情報（クライアント側）３５−２、データ３５−３）に対する署名３５−４を付加してサーバ３２に送信する。
【００５１】
次に、クライアントは、サーバからの受信を行う（ステップＳ１７）。具体的には、図３に示したサーバレスポンス（２）３６を受信する。
そこで、クライアントは、レスポンスの検証を行う（ステップＳ１８）。具体的には、図３に示したサーバ３２からのサーバレスポンス（２）３６としてのレスポンス（サーバ側）３６−１、時刻情報（サーバ側）３６−２、データ３６−３が改ざんされていないかどうかをチェックする。
【００５２】
ステップＳ１８の判断でレスポンスの検証が成功のときは、成功レスポンスをするか否かの判断をする（ステップＳ１９）。具体的には、図３に示したサーバ３２からのサーバレスポンス（２）３６としてのレスポンス（サーバ側）３６−１、時刻情報（サーバ側）３６−２、データ３６−３が改ざんされていないときは、成功レスポンスとして処理をする。
【００５３】
ステップＳ１８の判断でレスポンスの検証が失敗のとき、及びステップＳ１９の判断で成功レスポンスをしないときは、そのまま終了する。
ステップＳ１９の判断で成功レスポンスをするときは、クライアントは、ネゴシエーションの成功の処理を行う。
【００５４】
これにより、証明書の検証を行うことにより、クライアントは、サーバ側を受け入れていいどうかの判断を行い、時刻情報に基づいて信頼されていないサーバとのネゴシエーションを行わないようにすることができる。
【００５５】
図５はサーバ側の動作を示すフローチャートである。
図５において、サーバは、クライアントからの受信を待つ（ステップＳ２１）。具体的には、図３に示したクライアント３１からのクライアントリクエスト３３の受信を待つ。
サーバは、クライアントからの受信をすると（ステップＳ２２）、証明書による検証を行う（ステップＳ２３）。具体的には、図３に示したクライアント３１からのクライアントリクエスト３３の証明書３３−４を公開鍵として用いて署名３３−３の検証を行う。
【００５６】
次に、サーバは、クライアントの受入を許可するか否かの判断をする（ステップＳ２４）。具体的には、ステップＳ２３の検証の結果によりクライアントから送信された複数の情報が正しい内容である場合には、クライアントの受入を許可し、正しい内容でない場合には、クライアントの受入を拒否する。
【００５７】
ステップＳ２４の判断でクライアントの受入を許可するときは、サーバは、リクエストの検証を行う（ステップＳ２５）。具体的には、図３に示したクライアント３１からのクライアントリクエスト３３のリクエスト３３−１、データ３３−２が改ざんされていないかどうかをチェックする。
【００５８】
ステップＳ２５の判断でリクエストの検証が成功のときは、サーバは、リクエストの受入を許可するか否かの判断をする（ステップＳ２６）。具体的には、図３に示したクライアント３１からのクライアントリクエスト３３により成功又は拒否レスポンスをするか否かの判断をする。
【００５９】
ステップＳ２４の判断でクライアントの受入を許可しないとき、ステップＳ２５の判断でリクエストの検証が失敗のとき及びステップＳ２６の判断で拒否レスポンスをするときは、ステップＳ３２へ移行する。
ステップＳ２６の判断でリクエストの受入を許可するときは、サーバは、リクエストサービス及びプロファイルの検索を行う（ステップＳ２７）。具体的には、図３に示したクライアント３１からのクライアントリクエスト３３のリクエスト３３−１に対応するサービス及びプロファイルの検索を行う。
【００６０】
そこで、サーバは、レスポンス、証明書及びデータの準備を行う（ステップＳ２８）。具体的には、ステップＳ２７の検索結果によるサービスを示すレスポンス３４−１、プロファイル４３−２及びデータ３４−４を用意する。
次に、サーバは、自端末の時刻を取得する（ステップＳ２９）。具体的には、サーバは、内部時計から自端末の図３に示した時刻情報（サーバ側）３４−３を取得する。
【００６１】
次に、サーバは、レスポンスを作成する（ステップＳ３０）。具体的には、図３に示したクライアント３１へのサーバレスポンス（１）３４としてレスポンス（サーバ側）３４−１を作成する。
そして、サーバは、署名を行う（ステップＳ３１）。具体的には、図３に示したクライアント３１へのサーバレスポンス（１）３４として４つの情報（レスポンス（サーバ側）３４−１、プロファイル（許容時刻差）３４−２、時刻情報（サーバ側）３４−３、データ３４−４）に対する署名３４−５を行う。
【００６２】
そこで、サーバは、クライアントへの送信を行う（ステップＳ３６）。具体的には、図３に示したクライアント３１へのサーバレスポンス（１）３４として、レスポンス（サーバ側）３４−１、プロファイル（許容時刻差）３４−２、時刻情報（サーバ側）３４−３、データ３４−４及びこれにその４つの情報（レスポンス（サーバ側）３４−１、プロファイル（許容時刻差）３４−２、時刻情報（サーバ側）３４−３、データ３４−４）に対する署名３４−５を付加してクライアント３１に送信する。
【００６３】
ステップＳ２４の判断でクライアントの受入を許可しないとき、ステップＳ２５の判断でリクエストの検証が失敗のとき及びステップＳ２６の判断で拒否レスポンスをするときは、サーバは、レスポンス及びデータの準備を行う（ステップＳ３２）。具体的には、ステップＳ２４の判断でクライアントの受入を許可しない、ステップＳ２５の判断でリクエストの検証が失敗及びステップＳ２６の判断で拒否レスポンスをするサーバレスポンス（１）３４の結果と自端末の時刻情報を用意する。
【００６４】
次に、サーバは、レスポンスを作成する（ステップＳ３３）。具体的には、図３に示したクライアント３１へのサーバレスポンス（１）３４としてレスポンス（サーバ側）３４−１を作成する。
そして、サーバは、署名を行う（ステップＳ３４）。具体的には、図３に示したクライアント３１へのサーバレスポンス（１）３４として４つの情報（レスポンス（サーバ側）３４−１、プロファイル３４−２、時刻情報（サーバ側）３４−３、データ３４−４）に対する署名３４−５を行う。
【００６５】
そこで、サーバは、クライアントへのレスポンス送信を行って、処理を終了する。（ステップＳ３５）。具体的には、図３に示したクライアント３１へのサーバレスポンス（１）３４として、レスポンス（サーバ側）３４−１、プロファイル３４−２、時刻情報（サーバ側）３４−３、データ３４−４）及びこれにその４つの情報（レスポンス（サーバ側）３４−１、プロファイル３４−２、時刻情報（サーバ側）３４−３、データ３４−４））に対する署名３４−５を付加してクライアント３１に送信する。
【００６６】
次に、サーバは、クライアントからの受信を行う（ステップＳ３７）。具体的には、図３に示したクライアントレスポンス３５を受信する。
そこで、サーバは、レスポンスの検証を行う（ステップＳ３８）。具体的には、図３に示したクライアント３１からのクライアントレスポンス３５としてのレスポンス（クライアント側）３５−１、時刻情報（クライアント側）３５−２、データ３５−３が改ざんされていないかどうかをチェックする。
【００６７】
ステップＳ３８の判断でレスポンスの検証が成功のときは、サーバは、拒否レスポンスをするか否かの判断をする（ステップＳ３９）。具体的には、図３に示したクライアントレスポンス３５としてのレスポンス（クライアント側）３５−１、時刻情報（クライアント側）３５−２、データ３５−３が改ざんされていないときは、成功レスポンスとして処理をする。
ステップＳ３８の判断でレスポンスの検証が失敗のとき、及びステップＳ３９の判断で拒否レスポンスをするときは、ステップＳ４２へ移行する。
【００６８】
次に、サーバは、自端末の時刻を取得する（ステップＳ４０）。具体的には、サーバは、内部時計から自端末の図３に示した時刻情報（サーバ側）３６−２を取得する。
そして、サーバは、ネゴシエーションを行う（ステップＳ４１）。具体的には、サーバは、自端末の時刻情報とクライアントから送られてきた時刻情報を比較し、この比較結果がクライアントレスポンス３５に示される誤差範囲内に含まれるか否かをチェックする。このチェックが成功すれば、サーバは、クライアントレスポンス３５を満足するサービスを選択できるかどうかのネゴシエーションを行う。
【００６９】
そこで、サーバは、レスポンス及びデータの準備を行う（ステップＳ４２）。具体的には、ステップＳ４１のネゴシエーションの成功又は失敗を示すサーバネゴシエーション結果と自端末の時刻情報を用意する。ステップＳ３８の判断でレスポンスの検証が失敗のとき、及びステップＳ３９の判断で拒否レスポンスをするときは、ネゴシエーションの失敗を示すサーバネゴシエーション結果となる。
【００７０】
次に、サーバは、レスポンスを作成する（ステップＳ４３）。具体的には、図３に示したクライアント３１へのサーバレスポンス（２）３６としてレスポンス（サーバ側）３６−１を作成する。
そして、サーバは、署名を行う（ステップＳ４４）。具体的には、図３に示したクライアント３１へのサーバレスポンス（２）３６として３つの情報（レスポンス（サーバ側）３６−１、時刻情報（サーバ側）３６−２、データ３６−３）に対する署名３６−４を行う。
【００７１】
そこで、サーバは、クライアントへの送信を行う（ステップＳ４５）。具体的には、図３に示したクライアント３１へのサーバレスポンス（２）３６として、レスポンス（サーバ側）３６−１、時刻情報（サーバ側）３６−２、データ３６−３）及びこれにその３つの情報（レスポンス（サーバ側）３６−１、時刻情報（サーバ側）３６−２、データ３６−３）に対する署名３６−４を付加してクライアント３１に送信する。
【００７２】
これにより、サーバは、同じく信頼されていないクライアントを受け入れないように、証明書の検証を行い、時刻情報に基づいて信頼されていないクライアントとのネゴシエーションを行わないようにすることができる。
【００７３】
図６は時刻及びサービスのネゴシエーションの動作を示すフローチャートである。
図６において、クライアント及びサーバは、自端末時刻情報、相手端末時刻情報、プロファイル時刻誤差許容範囲を取得する（ステップＳ５１）。
次に、クライアント及びサーバは、自端末時刻情報と相手端末時刻情報との時刻差がプロファイル時刻誤差許容範囲内であるか否かを判断する（ステップＳ５２）。
【００７４】
ステップＳ５２の判断で自端末時刻情報と相手端末時刻情報との時刻差がプロファイル時刻誤差許容範囲内であるときは、クライアント及びサーバは、サービスごとのネゴシエーションを行う（ステップＳ５３）。
そして、クライアント及びサーバは、ネゴシエーションが成功したか否かを判断する（ステップＳ５４）。
ステップＳ５４の判断でネゴシエーションが成功したときは、ネゴシエーション成功の処理を行う（ステップＳ５５）。ステップＳ５２の判断で自端末時刻情報と相手端末時刻情報との時刻差がプロファイル時刻誤差許容範囲内でないとき、及びステップＳ５４の判断でネゴシエーションが成功しないときは、ネゴシエーション失敗の処理を行う（ステップＳ５６）。
【００７５】
このように、クライアント及びサーバは、プロファイルに基づいた時刻のネゴシエーションを行い、成功した場合にはサービスごとのネゴシエーションを行う。この２つのネゴシエーションに成功することにより、クライアントとサーバの相互間で全体としてのデータ通信のネゴシエーションに成功する。
【００７６】
図７は、各端末の構成例を示す機能ブロック図である。
図７において、クライアント及びサーバは、同様の機能を有するように構成されている。クライアント及びサーバは、データの送受信を行うデータ送受信部７２，８２と、データ解析及びデータ生成を行うデータ解析・生成部７３，８３と、プロファイルに基づいた時刻のネゴシエーションを行うネゴシエーションルーチン部７４，８４とを有している。
【００７７】
また、クライアント及びサーバは、生成されたデータに対する署名の生成及び解析されたデータに対する署名の検証を行う署名生成・検証部７７，８７と、署名による暗号化及び復号化を行う暗号化モジュール部７８，８８と、送受信される通信履歴データ（ログ）の保存を行うログ保存部７９，８９とを有している。
さらに、クライアント及びサーバは、ネゴシエーションに用いる時刻情報を提供する内部時計部７５，８５と、時刻情報を補正する内部時計補正機能部７６，８６とを有している。
【００７８】
上述した暗号化モジュール部７８，８８はソフトウェア、ハードウェアの両方で構成することが考えられるが、改ざんに対する耐久性のあるハードウェアモジュールのほうがセキュリティの強度は高いといえる。また、各端末は内部時計部７５，８５を持っているが、正確な時刻情報を維持するために、内部時計補正機能部７６，８６をオプションで利用できる。例えば、電波時計、ＧＰＳ（Global Positioning System: 全地球測位システム）、ＮＴＰ（Network Time Protocol：コンピュータの内部時計を、ネットワークを介して正しく調整するプロトコル）を利用した補正などが考えられる。
【００７９】
また、署名生成・検証部７７，８７による検証に関しては、上述したＳＳＬなどの通常の公開鍵暗号の署名検証の技術を利用することができ、さらに、各端末のログ保存部７９，８９に通信履歴データ（ログ）を保存することにより、データの改ざんや、否認を防止することができる。
【００８０】
上述した本実施の形態によれば、クライアント、サーバ間のメッセージに時刻情報を付加することにより、各端末がそのメッセージを作成した時刻を知ることができる。
また、クライアント、サーバ間のメッセージに署名をつけることにより、相手に自端末以外のメッセージ及び、改ざんされた場合の検知を行うができる。
【００８１】
さらに、クライアント、サーバ間のメッセージを通信履歴データ（ログ）として保存することにより、署名がついているため時刻も含めたデータの否認防止の証拠として利用できる。
また、様々なプロファイルを選択することによりサービスに応じて時刻の誤差範囲を設定することができる。
また、公開鍵暗号基盤のタイムスタンプのような大規模な設備が必要ないので、簡単な構成で実現することができる。
【００８２】
また、ネットワークに接続されていない端末同士でもＰ２Ｐなどを利用することができる。
さらに、お互いの機器にログを残すことにより、サービス提供後のサーバメッセージの変更などの不正にもクライアントの通信履歴データ（ログ）を利用して相手を否定するこができる。同様に、クライアント側のメッセージの改ざんも否定するこができる。
【００８３】
このようにして、上述した本実施の形態による公開鍵暗号及び端末時刻情報を用いたデータ通信時刻保証及び否認防止技術によれば、クライアント、サーバ間のメッセージにそのときの時間情報を付随させて自端末の時刻情報と比較し、時間差が設定値より大きい場合にはネゴシエーションにエラーを返すことにより、取り引き時刻をしぼり込むことを可能にすることができる。
【００８４】
さらに、そのメッセージに署名付けを行い、さらに通信履歴データ（ログ）としてクライアント、サーバに残すことにより、クライアントにとってはサーバ側を、サーバにとってはクライアント側の否認防止をする証拠とするこができる。また、Ｐ２Ｐといった小規模の取り引きなどにも応用することができる。
【００８５】
なお、上述した本実施の形態に限らず、本発明の要旨の範囲内であれば、適宜、その構成を変更しうることは言うまでもない。
【図面の簡単な説明】
【００８６】
【図１】本実施の形態によるデータ通信システムの構成図である。
【図２】各端末間のメッセージの送受信のシーケンス図である。
【図３】各端末間で送受信されるメッセージの内容を示すシーケンス図である。
【図４】クライアント側の動作を示すフローチャートである。
【図５】サーバ側の動作を示すフローチャートである。
【図６】時刻及びサービスのネゴシエーションの動作を示すフローチャートである。
【図７】各端末の構成例を示す機能ブロック図である。
【符号の説明】
【００８７】
１１…パーソナルコンピュータ（ＰＣ）、１２…パーソナルデジタルアシスタント（ＰＤＡ）、１３…個人認証デバイス、１３−１…受信部、１３−２…送信部、１４…サーバ、１５…パーソナルコンピュータ（ＰＣ）、１６…パーソナルデジタルアシスタント（ＰＤＡ）、１７−２…送信部、１７−１…受信部、１７…個人認証デバイス、１８…ネットワーク（有線・無線）、２１…クライアント、２２…サーバ、３１…クライアント、３２…サーバ、７２，８２…データ送受信部、７３，８３…データ解析・生成部、７４，８４…ネゴシエーションルーチン部、７７，８７…署名生成・検証部、７８，８８…暗号化モジュール部、７９，８９…ログ保存部、７５，８５…内部時計部、７６，８６…内部時計補正機能部
【図１】
0004600248.tif 000002
【図２】
0004600248.tif 000003
【図３】
0004600248.tif 000004
【図４】
0004600248.tif 000005
【図５】
0004600248.tif 000006
【図６】
0004600248.tif 000007
【図７】
0004600248.tif 000008