(57)【特許請求の範囲】
【請求項１】
文書に対してデジタル的に署名する方法であって、
デジタル的に署名する対象となる前記文書をパーソナルコンピュータにおいて受信するステップと、
前記文書をサーバーへと転送するステップと、
前記サーバーにおいて前記文書のハッシュを生成するステップと、
前記サーバーから信用のおけるサードパーティへ前記ハッシュと前記文書とを転送するステップと、
前記信用のおけるサードパーティから移動端末へ前記ハッシュを転送するステップと、
前記移動端末において前記文書のハッシュに対しデジタル的に署名するステップと
を含むことを特徴とする方法。
【請求項２】
前記転送のステップは、ＳＳＬ又はＴＳＬを用いて前記文書を転送するステップを含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記ＰＣにおいてデジタル署名をリクエストするステップをさらに含むことを特徴とする請求項１に記載の方法。
【請求項４】
文書に対してデジタル的に署名するシステムであって、
デジタル的に署名する対象となる前記文書を受信し、前記文書を転送するパーソナルコンピュータと、
前記パーソナルコンピュータから前記文書を受信し、前記文書のハッシュを生成し、前記ハッシュと前記文書とを転送するサーバーと、
前記サーバーから前記ハッシュと前記文書とを受信し、前記ハッシュを転送する信用のおけるサードパーティ装置と、
前記信用のおけるサードパーティ装置から前記ハッシュを受信し、前記ハッシュに対しデジタル的に署名する移動端末と
を含むことを特徴とするシステム。
【請求項５】
文書に対してデジタル的に署名するシステムであって、
デジタル的に署名する対象となる前記文書を受信し、前記文書を転送するパーソナルコンピュータと、
前記パーソナルコンピュータから前記文書を受信し、前記文書のハッシュを生成し、前記ハッシュと前記文書とを信用のおけるサードパーティへ転送するサーバーと、
前記信用のおけるサードパーティから前記ハッシュを受信し、前記ハッシュに対しデジタル的に署名する移動端末と
を含むことを特徴とするシステム。
【発明の詳細な説明】
【０００１】
技術分野
本発明は文書へのデジタル署名に係り、とりわけ、個人の端末装置を使用して文書に対しデジタル的に署名する技術に関する。
【０００２】
本発明の背景
ＷＡＰ／ＷＩＮプロトコルを使用することにより、移動電話、ラップトップコンピュータ及びパーソナル・デジタル・アシスタントのような個人的に信用のおける装置を強力な署名生成装置へとすることができる。この署名生成装置を利用すれば、ＰＣやウェブサイトその他などのいずれからのデータに対しても署名することができる。現在、移動端末のようなＰＴＤ（Personal Trusted Device：個人的な信用のおける装置）を使用してデジタルシグニチャ（デジタル署名）を実現するには、たったの１つの方法が存在するだけである。その方法は WML-Script function signTEXT を使用する方法である。このsignTEXT function（signTEXT関数）は入力としてテキストをうけとって、受け取ったテキストをユーザーに対して表示する関数である。これによりユーザーは署名を作成することができる。信頼モデルは非常にシンプルである。ユーザーが見ているものが、まさにユーザーが署名するものであることを、ユーザーに対して確認の義務を負わせることで信頼モデルが成り立っている。これをＷＹＳＩＷＹＳ原理と呼ぶ。
【０００３】
デジタル方式で文書に署名する際にＰＴＤを使用する現在のシステムの主な問題はＷＹＳＩＷＹＳ原理である。この問題はＰＴＤのディスプレイ能力が制限されているために生じる。すなわち、移動端末のようなＰＴＤ装置上で大きな文書を表示することは一般に不可能である。その上、移動端末のバッファリング能力や内容を構文解析する能力は非常に限定されており、また受信されたフォーマットに従って、正しく文書を表示するための適切なアプリケーションを具備することも移動端末には困難である。例えば、Ｗｏｒｄ（ワード）の文書を受信したとすれば、ＰＴＤはワード形式を表示する能力を備えていなければこれを表示することができないのである。
【０００４】
このように、ハッシュと呼ばれる、文書全体のうちの小さな代表部又は表現だけは別として、文書全体に対して、ユーザーが実際にデジタル方式で署名することはできていない。これはＷＹＳＩＷＹＳの信頼モデルに違反するものであり、ユーザーは、彼が署名しようとしているものが、彼が署名しようと考えているものであることをもはや確認することができないのである。よって、署名が必要とされる文書の必要な部分の全てをユーザーが閲覧することを可能にしつつ、文書に対してデジタル署名するために移動端末のようなＰＴＤ装置を使用することも可能にするための改善された方法が必要とされているといえる。
【０００５】
発明の概要
本発明は、ＰＴＤを使用してデジタル方式で文書に署名する方法に関連する上述の問題及び他の問題を解決するものであり、また、実質的に文書の全体を閲覧する機会をユーザーに提供するものである。また、デジタル署名の対象となる文書は、潜在的に文書を表示可能な第１のロケーション（第１の場所にある装置）で受信される。文書の表現は第１のロケーションで生成され、文書の表現は個人的な信用のおける装置 （ＰＴＤ） へと送信される。ユーザーは第１のロケーションで完全な文書を閲覧した後に個人信用装置（ＰＴＤ）においてデジタル方式で文書の表現又は代表部に署名することができる。
【０００６】
発明の詳細な説明
まず、図面の図１を参照する。この図には、文書１０と文書１０のハッシュ１５とが例示されている。文書１０はテキストのコピーなどから構成されており、これには契約書、手紙、販売受領書あるいはその他のユーザーによって署名されることが必要とされている全てアイテムが含まれうる。ハッシュ１５には文書に付随している情報のリストが含まれている。この情報には、例えば、文書のタイトル、文書番号／文書ＩＤ 、著者の名前／ＩＤなどが含まれうるものであり、ハッシュ表現は数字、アルファベット数字や符号が含まれうる。
【０００７】
次に、図２を参照する。この図には移動端末２０のような個人的な信用のおける装置をデジタル方式で文書１０に署名するために使用する方法についての一般的な例が示されている。移動端末２０のほかに、個人的な信用のおける装置は、ラップトップコンピュータ、パーソナル・デジタル・アシスタント、ポケットベルあるいは他の移動電子装置であってもよい。文書１０は、ＰＣ、信用のおけるサーバー又は一時的に議論される他のエリアのようないずれかの閲覧ロケーション（閲覧場所にある装置）２５へと転送される。文書１０は、閲覧ロケーション２５に提供され、文書１０に対してデジタル的に署名をしたいと希望しているユーザーによってその全てが表示可能となっている。ハッシュ１５は閲覧ロケーション２５又は閲覧ロケーション２５と関連する場所で作成され、ハッシュ１５は無線回線又は有線回線を介してを移動端末２０へと送信可能となっている。ユーザーが閲覧ロケーション２５において文書１０の全体を閲覧でき、移動端末２０においてデジタル方式でハッシュ１５に対して署名することができる。
【０００８】
図３には、第１の実施形態が例示されており、とりわけ信用のおけるＰＣ３０を使用してデジタルシグニチャを得るための方法が例示されている。この実施形態では、文書１０を含め、信用されているＰＣ３０に含まれている情報は正確なものであることを前提としており、唯一、保護が必要とされているのは信用されているＰＣ３０と移動端末２０との間の通信チャンネル３２である。通信チャンネル３２には、データを送信するためにペアとなっているシリアルケーブル、赤外線リンク又はＢｌｕｅｔｏｏｔｈ（Ｂｌｕｅｔｏｏｔｈは、テレフォンアクティボラゲット ＬＭ エリクソンの商標である。）を利用可能である。この実施形態において唯一の必要条件は、信頼のおけるＰＣ３０が認証済みであり、データの完全性が通信回線３２上で保護されることである。
【０００９】
次に図４を参照する。ステップ３５においてデジタル方式で署名するため、文書１０を信用のおけるＰＣ３０が受信する。移動端末２０が適切な信用されているＰＣ３０と接続されていることを確認すべく、ステップ４０において、移動端末２０は信用されているＰＣ３０を認証しなければならい。認証が実行された後、通信チャンネル３２がステップ ４５において確立され、ステップ５０において文書１０のハッシュ１５が移動端末２０へと送信される。ユーザーは信用されているＰＣ３０において文書１０の全体を閲覧し、ステップ５５において移動端末２０を使用してデジタルシグニチャを提供する。デジタルシグニチャは暗証番号を移動端末２０へと入力することによって自動的に提供されたものであってもよい。
【００１０】
図５は、ＰＣ６０内に含まれているブラウザ６５に実装可能な暗号モジュール７０を使用する他の実施形態が示されている。暗号モジュール７０はブラウザ６５内に統合されており、ＰＫＣＳ＃１１とＭＳ ＣＡＰＩのような暗号処理を実行する。暗号モジュール７０をブラウザ７０に統合するため、暗号モジュール７０が使用される前には、暗号モジュール７０の信頼性と完全性とがＰＣのオペレーティングシステムかブラウザ６５によって検証されなければならない。図６で例示されるように、暗号モジュール７０はハッシュ１５に従って署名されたあと移動端末２０へと送信される文書１０を表示する。また、図３や図４と関連して説明したように、移動端末２０もまた認証処理を実行し、ＰＣ６０と移動端末２０との間の通信チャネル７５の完全性を保護するようにしてもよい。
【００１１】
次に、図７を参照する。この図には、暗号モジュール７０を利用してデジタルシグニチャを得るための方法に関するフローチャートが例示されている。署名の対象となる文書１０は、ステップ８０において受信され、ステップ８５においてブラウザ６５を使用し暗号モジュール７０によって表示される。移動端末２０はステップ９０において、ＰＣ６０と暗号モジュール７０とに確証を与え、ステップ９５において、通信チャンネル７５を確立する。文書１０のハッシュ１５はステップ１００において移動端末２０ へと送信され、ステップ１０５においてハッシュ１５が移動端末２０ディスプレイ装置上に表示されるようになる。ユーザーは、ステップ１１０において、移動端末において表示されたハッシュ１５を閲覧し、暗号モジュール７０で表示された文書１０を閲覧し、文書１０に対してデジタルシグニチャを提供する。
【００１２】
次に、図８を参照する。この図には信用のおけるパーティ１１５が利用される場合において、文書１０のデジタルシグニチャを得るためのさらに他の実施形態が例示されている。本実施形態は、文書１０を受信したあと、ＰＣ１２０がウェブサーバー１２５を経由して文書を１０信用のおけるパーティ１１５へと転送するものである。ウェブサーバー１２５内おいて、サーブレット１３０がハッシュ１５を生成し、この生成されたハッシュ１５は移動端末２０においてユーザーによって署名されるものである。ハッシュ１５と文書１０は、ウェブサーバー１２５から、信用のおけるパーティ１１５へと転送され、通信チャンネル１３５を経由して移動端末２０へとハッシュが転送される。データはＳＳＬやＴＬＳプロトコルなどを使用して、ＰＣ１２０からウェブサーバー１２５へ、さらにウェブサーバー１２５から信用されているパーティ１１５へと送信される。
【００１３】
次に、図９を参照する。この図には、信用されているパーティ１１５を経由し、移動端末２０のような個人的な信用のおける装置を使用してデジタルシグニチャを得るための方法を例示したフローチャートが示されている。署名の対象となる文書１０は、ステップ１４０においてＰＣ１２０により受信され、ステップ１４５において、ユーザーがＰＣ１２０に対しデジタルシグニチャを要求（リクエスト）する。ステップ１１５において、信用されているパーティ１１５は、ＰＣ１２０を認証し、そのあと、ＰＣ１２０からウェブサーバー１２５、信用されているパーティ１１５へのコネクションを確立する。あるいは、ＰＣ１２０は事前にセキュアな状態で識別済みにしておいてもよく、取引に関して信用されているパーティ１１５のファイルに、予め移動端末２０が登録されていてもよい。
【００１４】
ＰＣ１２０が認証されたあと、ステップ１５５において、デジタルシグニチャの要求（リクエスト）が文書１０とともにウェブサーバー１２５へと送信される。サーブレット１３０は、提供された文書１０からハッシュ１５を生成する。ステップ１６５において、文書１０を伴うハッシュ１５とデジタルシグニチャの要求とが、ウェブサーバー１２５から信用のおけるパーティ１１５へと送信される。ステップ１７０において、信用されているパーティ１１５は、通信チャンネル１３５を介して移動端末２０へとハッシュ１５を送信する。信用のおけるサードパーティにおいて文書が閲覧されたあとに、ステップ１８０において、移動端末２０はデジタルシグニチャを供給し、ステップ１８５において、移動端末２０は、信用のおけるパーティ１１５へとデジタルシグニチャを通知する。ステップ１９０において、信用のおけるパーティは提供されたデジタルシグニチャを有効にし、ＰＣ１２０と移動端末２０の双方において署名の対象となるトランザクションを更新して通知する。
【００１５】
次に、図１０を参照する。この図には、ＰＣ２００が文書１０をストリーミングデータとして移動端末２０へと送信するさらに他の実施形態が示されている。ストリーミングデータを使用することについての一般的な概念は、ハッシュだけでなくデータの全部又は大部分もまた、シグニチャを生成するために移動端末２０へと送信されることにある。署名されるべきデータはＰＣ２００において表示され、移動端末２０へとストリーミングされる。なお、移動端末２０の小さな画面を通してはユーザーに対して文書の全体を表示できず、また、一般に、サイズの大きな文書を十分に記憶できるほど移動端末２０の内部バッファーは大きくないという問題がいまだに存在している。これは図１１及び図１２でさらに詳しく説明する２つの解決方法のいずれか１つを使用することで解決できるであろう。
【００１６】
次に、図１１を参照する。この図には、ステップ２０５において、ユーザーがＰＣ２００のマウスを利用し、必須と考える適切なテキスト選択する方法を例示している。ステップ２１０において、選択されたテキストとハッシュ１５とが移動端末へと送信される。ユーザーは提供されたテキストとハッシュ１５を閲覧した後に、ステップ１１５において、受信された情報にデジタル方式で署名する。
【００１７】
次に、図１２を参照する。この図には、ステップ２２０においてユーザーが移動端末２０のボタン又は起動ポイントをトリガーすることを可能にした他の実施形態を例示している。移動端末２０は、ステップ２２５においてトリガーに応答し、移動端末２０のバッファーに格納されている現在のコンテンツを表示する。ステップ２３０において、ユーザーは閲覧しているものに基づいてデジタル方式で文書に署名することができる。
【００１８】
移動端末２０は、大きな文書１０を記憶することも表示することもできないが、その代わりＰＣから文書１０のテキストを受信して、受信したテキストからハッシュ１５を演算して生成することはできる。移動端末２０において演算により生成されたハッシュ１５は、移動端末２０内において、ユーザーが署名するように促されているＰＣによって送信されたハッシュ１５と比較される。バイト計算のような他のチェック処理も移動端末２０において実行されてもよい。この処理は、ハッシュコード１５を適用される文書１０が要求されている文書であることを検証するために使用される。ハッシュコード１５を計算するためのバイト文字列の一部として文書バイトカウントを含めることが好ましいかもしれない。上述のステップは、ユーザー自らが署名していると考えているものに対してユーザーが実際に署名していることについて、さらに追加のセキュリティ防衛手段をユーザーに提供するものである。
【００１９】
次に、図１３を参照する。この図には、顧客のＰＣ２５０、売り手のサーバー２５５及び顧客の移動体電子取引（ＭｅＴ）装置２６０とが含まれた、デジタルシグニチャを提供するさらに他の実施形態が例示されている。顧客のＰＣ２５０はウェブブラウザ２６５を備えており、これによりユーザーはインターネットのようなネットワークを介して売り手のサーバー２５５へとアクセスすることが可能となる。顧客のＰＣ２５０にはさらに、移動体電子端末パーソナルプロキシ（ＭＰＰ）２７０が含まれており、このＭＰＰ２７０により、顧客のＰＣ２５０、売り手のサーバー２５５及び顧客の移動体電子取引装置２６０間の電子商取引をコントロールする。ＭＰＰ２７０はウェブブラウザ２６５を通してアクセスされる。ＭＰＰ２７０は顧客のＰＣ２５０によって実行可能なソフトウェアモジュールを備えている。ブラウザ２６５とＭＰＰ２７０との間の通信、及びＭＰＰ２７０と売り手のサーバー２５５との間の通信には、ＴＣＰ／ＩＰを経由して（移動体電子取引の特定のヘッダー情報を扱うように拡張されている）ＨＴＴＰプロトコルを使用する。ＭＰＰ２７０は、顧客のＰＣ２５０が移動体電子取引装置２６０のためのサーバーとしての機能することを可能にしている。移動体電子取引装置２６０へとアクセスしているときに、支払いが要求されると、提供された認証情報 （パスワード、ＰＩＮなど）をユーザーに要求する。
【００２０】
顧客ＰＣに搭載されているアプリケーション２７５は、電子商取引に関する様々な機能を提供する。本発明の方法についての以下の説明において、アプリケーション２７５はデジタルシグニチャ機能を提供するが、その際に、売り手のサーバー２５５から提供されるデータ文字列は、アプリケーション２７５によって追加されたデジタル信号をさらに備えていてもよい。
【００２１】
ウェブサーバー２８０は、ＰＣ２５０内のサービスへと接続するための能力を移動端末に提供する。ＷＡＰゲートウェイ２８５は、顧客のＰＣ２５０を通じ、ＷＡＰプロトコルを使用してインターネットへとアクセスする能力を、移動体電子取引装置２６０のような無線装置に提供するものである。インターネットのようなＴＣＰ／ＩＰネットワークとＷＡＰネットワークとの間のインターフェイスとしてＷＡＰゲートウェイ２８５は動作する。ＷＡＰゲートウェイ２８５はＷＡＰプロトコルとＴＣＰ／ＩＰプロトコルとの間で変換を行なうのである。
【００２２】
ブルートゥースプロトコルを使用し限定されて定義されたエリア内において、ブルートゥース（ＢＴ）スタック２９０により、顧客のＰＣ２５０は移動体電子取引装置と短距離無線回線を確立する。本発明では、ブルートゥースプロトコルを使用した短距離無線回線を利用するものとして説明しているが、顧客のＰＣに近接した移動体電子取引装置２６０や他の情報装置へとアクセス可能にするものであれば、他の短距離無線プロトコルであっても本発明にとって有用であることは理解できるであろう。
【００２３】
移動体電子取引装置２６０は、移動電話、ラップトップコンピュータ、パーソナル・デジタル・アシスタント、あるいは電子商取引を成立させるのに必要な情報を有している他の同じように構成された全ての移動電子装置のいずれかによって構成することができる。売り手のサーバー２５５には、顧客のＰＣ２５０やウェブサーバー３００と電子商取引を成立させるために必要となる機能や、インターネットのようなネットワークへと売り手のサーバーをアクセス可能とする機能を実現するアプリケーション２９５を備えている。
【００２４】
次に、図１４を参照する。この図は、顧客のＰＣ２５０、売り手のサーバー２５５及び移動体電子取引装置２６０との間で、ＭＰＰ２７０がデジタルシグニチャの実行要求をコントロールする手法を例示したフローチャートを示している。ステップ３０５において、要求（リクエスト）がウェブブラウザ２６５からＭＰＰ２７０へと送信される。ステップ３１０において、ＭＰＰ２７０は、売り手のサーバー２５５のウェブサーバー３００へとこの要求を転送する。この要求には特定のアイテムを購入するためのリクエストや、すでに購入した製品をダウンロードするためのリクエストなどが含まれるかもしれない。
【００２５】
このリクエストを処理するために、売り手のサーバー２５５は顧客からのデジタルシグニチャを必要とする。ステップ３１５において売り手のサーバー２５５は特定のデータ文字列と、このデータ文字列に付加されるべきデジタルシグネチャの要求とを含む応答（レスポンス）を送信することにより、この要求に応える。ＭＰＰ２７０からの要求に対する売り手の応答には、特定のＨＴＴＰ１．１ヘッダーを有するＵＲＩが含まれている（例えば、「http://merchantsite.com/responsesite/」や「文字列への署名」における移動体電子取引署名(Mobile electronic transaction-sign））。これには、移動体電子取引装置２６０へのインストラクションが含まれている。これは、たとえば、添付のデータ文字列に対して署名し、デジタル署名されたデータ文字列を指定のＨＴＴＰサイトへと返信するようにとのインストラクションなどである。ＭＰＰ２７０は、ほとんどの要求や応答を通過させるだけで、特別な処理を実行することはない。しかし、いったん移動体電子取引コマンドが要求や応答に含まれていることを発見すると、ＭＰＰ２７０は動作を開始する。ＭＰＰ２７０は移動体電子取引コマンドＨＴＴＰヘッダーに含まれていることを認識すると、ステップ３２０において、デジタルシグニチャが要求されたことを示す通知をブラウザ２６５へと送信する。同様にデジタル信号の要求以外の移動体電子取引コマンドが利用可能であることは理解されるべきである。デジタルシグニチャが得られる一方、ウェブブラウザ２６５は、ＰＲＡＧＭＡ ＲＥＦＲＥＳＨ（すなわちリロードのときにキャッシュせずにサーバーから取って来ること）ヘッダーコマンドを有するページを表示することになろう。
【００２６】
売り手のサーバー２５５からの応答に含まれているデータ文字列は、ステップ３２５において、顧客のＰＣ２５０に含まれているアプリケーション２７５へと転送される。受信されたデータ文字列に応答し、ステップ３３０において、アプリケーション２７５はコマンドをブルートゥーススタック２９０へと送信する。このコマンドは、ブルートゥーススタック２９０に対して、可能であれば、移動体電子取引装置２６０を起動するよう指示するコマンドである。ステップ３３５において、ブルートゥースを使用して移動体電子取引装置２６０にＡＴコマンドを送信することによりｍ移動体電子取引装置２６０の起動が達成される。この起動に応答し、ステップ３３６において、移動体電子取引装置２６０は、移動体電子取引装置２６０の同じアプリケーションを要求する。移動体電子取引装置２６０内のアプリケーションは、ステップ３４０において、デジタルシグニチャ（応答）を含む要求を提供するＷＭＬスクリプトコードを実行する。ステップ３４５において、ブルートゥーススタック２９０とＷＡＰゲートウェイ２８５とを経由してウェブサーバー２８０へと、デジタルシグニチャを含む応答が送信される。この応答はアプリケーション２７５へと渡される。アプリケーション２７５は、ステップ３５０において、提供されたデータ文字列にデジタルシグニチャを追加し、ステップ３５５において、ブルートゥーススタック２９０に完成したシグニチャを通知する。
【００２７】
ステップ３６０において、アプリケーション２７５はデジタル方式で署名されたデータ文字列をＭＰＰ２７０へと返信する。ＭＰＰ２７０は、ステップ３６５において、ブラウザにデータ文字列の完全な署名を通知する。これはブラウザに、データ文字列が署名されたという表示を表示させるためにＵＲＩの再ロードを開始させるためのものである。ステップ３７０において、ＭＰＰは、署名されたデータ文字列に含まれている当初のＨＴＴＰヘッダー（http://merchantsite.com/responsesite/）に搭載されていたＵＲＬへとＨＴＴＰ要求を送信する。ステップ３７５において、署名されたデータ文字列を受信すると、売り手のサーバー２５５内のウェブサーバー３００は、ＭＰＰに応答を返信し、顧客ＰＣのウェブブラウザ２６５に取引が成立したことを通知する。
【００２８】
これは強調しておくべきことであるが、本明細書において「含む／含んでいる」との言葉が使用される時は、特定の機能、数、ステップ及び構成要素が存在していることを意図しており、他の一以上の機能、数、ステップ、構成要素又はこれらのグループの追加や存在を除外することを意味しているわけではない。
【００２９】
上述の説明は本発明を実施するための好ましい実施形態であって、この説明によって発明の範囲が必然的に限定されるべきではない。本発明の範囲は請求項によって定義される。
【図面の簡単な説明】
本発明の方法及び装置についてのより完璧な理解は、添付図面と関連付けて以下の詳細な説明を参照することにより得られよう。
【図１】  図１は文書と文書のハッシュとの間の関係を例示しているブロック図である。
【図２】  図２は閲覧場所に関連したデジタル方式で文書に署名するための移動端末の使用例を示す図である。
【図３】  図３は信用のおけるＰＣと移動端末との組み合わせを使用してデジタルシグニチャを提供する第１の実施形態を例示した図である。
【図４】  図４は図３の方法を例示しているフローチャートである。
【図５】  図５は暗号モジュール及び移動端末を使用してデジタルシグニチャを得る他の実施形態を示した図である。
【図６】  図６はＰＣと移動端末における文書及びハッシュの表示例示した図である。
【図７】  図７は図５の方法を例示したフローチャートである。
【図８】  図８は ＰＣ、信用のおける団体及び移動端末との間でデジタルシグニチャを得る方法を例示した図である。
【図９】  図９は図８の方法を例示したフローチャートである。
【図１０】  図１０はデジタルシグニチャを得るためにＰＣと移動端末との間でストリーミングデータを使用する例を示した図である。
【図１１】  図１１は図１０に例示されたストリーミングデータを利用する 第１の方法を例示したフローチャートである。
【図１２】  図１２は図１０に示されたストリーミングデータを利用する第２の方法を例示した図である。
【図１３】  図１３はさらに他の実施形態にかかる顧客のＰＣ、売り手のサーバー及び顧客の移動端末と、その間の相互作用を例示した図である。
【図１４】  図１４は図１３に示されたシステムにかかる方法を例示したフローチャートである。
【図１】
0004808903.tif 000002
【図２】
0004808903.tif 000003
【図３】
0004808903.tif 000004
【図４】
0004808903.tif 000005
【図５】
0004808903.tif 000006
【図６】
0004808903.tif 000007
【図７】
0004808903.tif 000008
【図８】
0004808903.tif 000009
【図９】
0004808903.tif 000010
【図１０】
0004808903.tif 000011
【図１１】
0004808903.tif 000012
【図１２】
0004808903.tif 000013
【図１３】
0004808903.tif 000014
【図１４】
0004808903.tif 000015