JP2002281020A - データ送受信システム、データ送受信方法およびその方法をコンピュータに実行させるプログラムを記録したコンピュータ読み取り可能な記録媒体 - Google Patents

Abstract

(57)【要約】 【課題】 カード会社Ａから交付されたカード番号をそ
の利用者Ｂが加盟店Ｃのホームページで入力・送信する
場合のように、異なる三者間を経由するデータの送受信
において、当該データの偽造・変造を防止するととも
に、最初の送信者と最後の受信者だけはデータの内容を
容易に閲覧することができるようにすること。 【解決手段】 第１の鍵により暗号化されたデータは第
２の鍵による変換を経て第３の鍵による復号が可能とな
るという関係にある、３つの鍵を三者に分配し、第１の
情報処理装置（１０１）はそのカード情報暗号化部３０
１ｅで、カード番号などを第１の鍵により暗号化し、こ
れを受信した第２の情報処理装置（１０２）は、さらに
これをカード情報変換部３０２ｄで第２の鍵により変換
し、これを受信した第３の情報処理装置（１０３）は、
これをカード情報復号部３０３ｆで第３の鍵により復号
する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は、立場の異なる三
者間を経由してデータの送受信をおこなうデータ送受信
システム、データ送受信方法およびその方法をコンピュ
ータに実行させるプログラムを記録したコンピュータ読
み取り可能な記録媒体に関する。

【０００２】

【従来の技術】現在、送信者と受信者との間の通信を安
全におこなうための暗号化技術としては、一般的に２つ
の方法、すなわち（１）共通秘密鍵方式と（２）公開鍵
方式とが広く知られている。

【０００３】（１）共通秘密鍵方式は、送信者Ａ・受信
者Ｂの双方が同じ鍵を保持し、Ａがその鍵で暗号化した
データを、Ｂが同一の鍵で復号する方式である。ただ
し、この方式では上記鍵の取得者（Ｂのように正当に入
手した者のほか、不正な手段で入手した者を含む）がデ
ータを変造（改竄）、あるいは偽造（捏造）の上、上記
鍵で暗号化をおこない、自己がＡであるように詐称して
第三者などに送信するいわゆる「なりすまし」を防止す
ることができない。

【０００４】他方（２）公開鍵方式の代表的なものにＲ
ＳＡがあるが、これは対になる２つの鍵を用意し、一つ
を秘密鍵として送信者Ａが、もう一つを公開鍵として受
信者Ｂが、それぞれ保持する方式である。Ａはこの秘密
鍵でデータを暗号化し、Ｂは当該データを、上記秘密鍵
と対になる公開鍵で復号する。ＡＢ間で受け渡しされる
公開鍵から、秘密鍵を特定することは現実的に不可能な
ので、秘密鍵が安全に管理されている限り当該鍵による
暗号化をおこなえるのはＡのみとなり、上述の「なりす
まし」の問題は発生しない。

【０００５】

【発明が解決しようとする課題】しかしながら、上記従
来技術に共通することは、いずれも送信者Ａと受信者Ｂ
の二者しか考慮していないことである。これに対し、現
実社会で発生する種々の取引、関係などはより複雑であ
って、立場の異なる二者以外に、さらに立場の異なる第
三者が関与することもしばしばである。

【０００６】たとえば、典型的にはクレジットカードに
よる決済がある。この取引にはカード会社、カード利用
者および加盟店の三者が関与している。この決済取引を
インターネットなどのネットワーク内において、たとえ
ば上記（２）の公開鍵方式により安全におこなおうとす
ると、その手順は図１１に示すようなものとなる。

【０００７】（ａ）鍵の受け渡し 事前に、カード会社Ａは自社用の一対の秘密鍵Ｋａと公
開鍵Ｋａ’とを生成し（１）、この公開鍵Ｋａ’を各加
盟店に送付しておく（２）。また、各加盟店はそれぞれ
自店用の一対の秘密鍵Ｋｃと公開鍵Ｋｃ’とを生成して
おく（３）。

【０００８】（ｂ）カード情報の受け渡し カードの利用を新規に申し込もうとする者は、まずその
本人用の秘密鍵Ｋｂと公開鍵Ｋｂ’とを生成する
（４）。そして、このうち公開鍵Ｋｂ’のみを、自己の
氏名や住所などの必要事項とともに、カード会社Ａに送
付する（５）。なお、この秘密鍵Ｋｂと公開鍵Ｋｂ’と
は、上記のようにＢが生成してＫｂ’をＡに渡すのでな
く、Ａが生成してＫｂをＢに渡すのであってもよい。

【０００９】つぎに、カード会社Ａは上記の申し込みを
受理すると、当該カード利用者Ｂのカード情報、具体的
にはＢのカード番号やＢから受け取った公開鍵Ｋｂ’、
その氏名や住所などを、Ａの秘密鍵Ｋａで暗号化（６）
の上、Ｂに送付する（７）。

【００１０】（ｃ）商品の発注／受注 そして、カード利用者Ｂは加盟店Ｃが開設するホームペ
ージなどで、希望の商品（有形の物品だけでなく、無形
のサービスなども含むものとする）を注文する。具体的
には、商品名や個数、金額などの注文内容を、Ｂの秘密
鍵Ｋｂにより暗号化し（８）、さらにこれにＡから受け
取ったカード情報を追加する（９）ことで、所定のフォ
ーマットの注文書を作成する。そして、この注文書全体
を上記ホームページからダウンロード（１０）した加盟
店Ｃの公開鍵Ｋｃ’で暗号化（１１）の上、加盟店Ｃに
送付する（１２）。

【００１１】加盟店Ｃでは、カード利用者Ｂから受け取
った注文書をＣの秘密鍵Ｋｃで復号し（１３）、さらに
復号後の注文書内の、Ａの秘密鍵Ｋａで暗号化されたカ
ード情報を、Ａから受け取った（２）Ａの公開鍵Ｋａ’
で復号する（１４）。

【００１２】この復号されたカード情報内には、上述の
ようにＢの公開鍵Ｋｂ’が含まれているので、これによ
り秘密鍵Ｋｂで暗号化された注文内容が復号できる（１
５）。また、Ｋｂ’による復号が成功したことをもっ
て、Ｃは上記注文内容がＫｂにより暗号化されていたこ
と、すなわち上記注文が秘密鍵Ｋｂを保持するＢ本人に
より発せられたことを確認することができる。

【００１３】（ｄ）代金の請求・決済 この後、所定の締め日が到来すると、加盟店Ｃはカード
会社Ａに対して、カード利用者Ｂの購入代金の支払いを
請求する（１６）。カード会社Ａでは利用総額の明細書
をカード利用者Ｂに送付して、その確認を得た後、カー
ド利用者Ｂの口座からの代金引き落としと、加盟店Ｃの
口座への代金振り込みをおこなう（１７）。

【００１４】このように、従来技術では複数の鍵による
暗号化と復号とを何度もおこなわなければならず、処理
が複雑・煩雑である。また、カード利用者Ｂはカード会
社Ａから送付されたカード情報（７）を、Ｋｃ’による
暗号化のみ（１１）で加盟店Ｃに送付する（１２）た
め、たとえば加盟店ＣがＫｃで復号したＢのカード情報
（１３）を流用して注文書を偽造し、Ｂになりすまして
他の加盟店に注文を出すことを防止できない。

【００１５】Ｂに送付される利用明細により、事後的な
チェックは可能であるものの、不正使用の発見が代金引
き落とし後に遅れることも多く、その時点ではＣの行方
が分からなくなっていることも多い。

【００１６】そして、事前予防のためには結局、個々の
加盟店が信用できるかどうかをカード会社Ａあるいはカ
ード利用者Ｂが取引の都度調査するしかなくなるが、Ａ
がインターネット上の店舗を漏れなく調査することは現
実的でなく、またＢからの個別の問い合わせ（Ｃが正規
の加盟店であるかどうか、など）に逐一Ａが応じるのも
負担が大きい。また、Ｂ個人の調査能力には限界がある
ことから、クレジットカードを持っていても、Ｃによる
カード番号の不正使用をおそれて電子決済を躊躇するユ
ーザーも多い。

【００１７】逆に、加盟店としても、受け付けた注文書
の作成者がカード利用者本人であるか、あるいは加盟店
を装うなどして当該利用者からカード情報を入手した不
正取得者であるかの区別がつかないため、別途電子メー
ルなどで本人の確認を取らざるを得ない。しかし、作業
負担が大きいわりにたとえば確認メールの到着／不着で
本人と押し問答になるケースもあり、必ずしも安全に代
金が回収できるとは言えない。

【００１８】なお、上記のほか一回しか使用できないカ
ード番号を送付する方式、専用のプロバイダを介して取
引をおこなうことで、カード番号の送付を避ける方式な
ども提案されているが、毎回発行の手間がかかり、受け
取り相手も特定できない、プロバイダがマージンを取る
ことが多く、出店数が少ないなどの欠点がある。また、
プリペイドカードにより利用額／損害額を一定限度に制
限する方式などもあるが、購入の手間がかかる上に少し
でも限度額を超えるものは購入できず、使いにくいとい
った問題がある。

【００１９】このように、従来技術で安全なカード決済
が難しいのは、従来の暗号化・復号化技術がもっぱら二
者間の通信を念頭に置いており、三者間の安全な通信を
おこなう用途には最適化されていないためである。

【００２０】この発明は上記従来技術による問題点を解
決するため、異なる三者間を経由するデータの送受信に
おいて、当該データの偽造・変造を防止するとともに、
最初の送信者と最後の受信者だけはデータの内容を容易
に閲覧することが可能なデータ送受信システム、データ
送受信方法およびその方法をコンピュータに実行させる
プログラムを記録したコンピュータ読み取り可能な記録
媒体を提供することを目的とする。

【００２１】

【課題を解決するための手段】上述した課題を解決し、
目的を達成するため、請求項１に記載の発明にかかるデ
ータ送受信システムは、第１、第２および第３の情報処
理装置間でデータを送受信するデータ送受信システムに
おいて、前記第１の情報処理装置がデータを第１の鍵に
より変換する第１の変換手段と、前記第１の変換手段に
より変換されたデータを送信する第１の送信手段と、を
備え、前記第２の情報処理装置が前記第１の送信手段か
ら送信されてきたデータを受信する第１の受信手段と、
前記第１の受信手段により受信されたデータを第２の鍵
により変換する第２の変換手段と、前記第２の変換手段
により変換されたデータを送信する第２の送信手段と、
を備え、前記第３の情報処理装置が前記第２の送信手段
から送信されてきたデータを受信する第２の受信手段
と、前記第２の受信手段により受信されたデータを第３
の鍵により変換する第３の変換手段と、を備えたことを
特徴とする。

【００２２】この請求項１に記載の発明によれば、変換
後のデータの取得者はその直前の変換元による変換前の
データを捏造し、あるいは変換後のデータから復元した
変換前のデータを改竄して、当該変換元と同一の変換を
施すことはできない。

【００２３】また、請求項２に記載の発明にかかるデー
タ送受信システムは、第１および第２の情報処理装置間
でデータを送受信するデータ送受信システムにおいて、
前記第１の情報処理装置が第１の鍵により変換されたデ
ータをさらに第２の鍵により変換する第１の変換手段
と、前記第１の変換手段により変換されたデータを送信
する送信手段と、を備え、前記第２の情報処理装置が前
記送信手段から送信されてきたデータを受信する受信手
段と、前記受信手段により受信されたデータを第３の鍵
により変換する第２の変換手段と、を備えたことを特徴
とする。

【００２４】この請求項２に記載の発明によれば、変換
後のデータの取得者はその直前の変換元による変換前の
データを捏造し、あるいは変換後のデータから復元した
変換前のデータを改竄して、当該変換元と同一の変換を
施すことはできない。

【００２５】また、請求項３に記載の発明にかかるデー
タ送受信システムは、前記請求項１または請求項２に記
載の発明において、前記第１の鍵により変換されたデー
タは、前記第２の鍵により変換されさらに前記第３の鍵
により変換されると前記第１の鍵による変換前の元のデ
ータとなることを特徴とする。

【００２６】この請求項３に記載の発明によれば、変換
後のデータの取得者はその直前の変換元による変換前の
データを捏造し、あるいは変換後のデータから復元した
変換前のデータを改竄して、当該変換元と同一の変換を
施すことはできない一方で、２つ前の変換元による変換
前のデータは復元することができる。

【００２７】また、請求項４に記載の発明にかかるデー
タ送受信方法は、第１、第２および第３の情報処理装置
間でデータを送受信するデータ送受信方法において、前
記第１の情報処理装置で、データを第１の鍵により変換
する第１の変換工程と、前記第１の変換工程で変換され
たデータを、前記第１の情報処理装置から前記第２の情
報処理装置に送信する第１の送信工程と、前記第２の情
報処理装置で、前記第１の送信工程で送信されてきたデ
ータを第２の鍵により変換する第２の変換工程と、前記
第２の変換工程で変換されたデータを、前記第２の情報
処理装置から前記第３の情報処理装置に送信する第２の
送信工程と、前記第３の情報処理装置で、前記第２の送
信工程で送信されてきたデータを第３の鍵により変換す
る第３の変換工程と、を含んだことを特徴とする。

【００２８】この請求項４に記載の発明によれば、変換
後のデータの取得者はその直前の変換元による変換前の
データを捏造し、あるいは変換後のデータから復元した
変換前のデータを改竄して、当該変換元と同一の変換を
施すことはできない。

【００２９】また、請求項５に記載の発明にかかるデー
タ送受信方法は、第１および第２の情報処理装置間でデ
ータを送受信するデータ送受信方法において、第１の鍵
により変換されたデータを、前記第１の情報処理装置で
さらに第２の鍵により変換する第１の変換工程と、前記
第１の変換工程で変換されたデータを、前記第１の情報
処理装置から前記第２の情報処理装置に送信する送信工
程と、前記送信工程で送信されてきたデータを、前記第
２の情報処理装置で第３の鍵により変換する第２の変換
工程と、を含んだことを特徴とする。

【００３０】この請求項５に記載の発明によれば、変換
後のデータの取得者はその直前の変換元による変換前の
データを捏造し、あるいは変換後のデータから復元した
変換前のデータを改竄して、当該変換元と同一の変換を
施すことはできない。

【００３１】また、請求項６に記載の発明にかかるデー
タ送受信方法は、前記請求項４または請求項５に記載の
発明において、前記第１の鍵により変換されたデータ
は、前記第２の鍵により変換されさらに前記第３の鍵に
より変換されると前記第１の鍵による変換前の元のデー
タとなることを特徴とする。

【００３２】この請求項６に記載の発明によれば、変換
後のデータの取得者はその直前の変換元による変換前の
データを捏造し、あるいは変換後のデータから復元した
変換前のデータを改竄して、当該変換元と同一の変換を
施すことはできない一方で、２つ前の変換元による変換
前のデータは復元することができる。

【００３３】また、請求項７に記載の発明にかかるプロ
グラムは、前記請求項４〜請求項６のいずれか一つに記
載された方法をコンピュータによって実施させることが
可能となる。

【００３４】

【発明の実施の形態】以下に添付図面を参照して、この
発明によるデータ送受信システム、データ送受信方法お
よびその方法をコンピュータに実行させるプログラムを
記録したコンピュータ読み取り可能な記録媒体の好適な
実施の形態を詳細に説明する。

【００３５】（実施の形態１）まず、この発明の実施の
形態１によるデータ送受信システムのシステム構成につ
いて説明する。図１は、実施の形態１によるデータ送受
信システムのシステム構成を示す説明図である。図中、
１０１はカード会社Ａの管理するコンピュータ、１０２
はカード利用者Ｂの保持するコンピュータ、１０３は加
盟店Ｃの管理するコンピュータであり、１００は上記の
各コンピュータを相互に接続するネットワーク、具体的
にはインターネットを示している。

【００３６】つぎに、この発明の実施の形態１によるデ
ータ送受信システムを構成する、個々のコンピュータの
ハードウエア構成について説明する。図２は、実施の形
態１によるコンピュータ１０１〜１０３のハードウエア
構成の一例を示す説明図である。なお、以下では説明の
便宜上、各コンピュータは同一のハードウエア構成を有
するものとする。

【００３７】同図において、２０１は装置全体を制御す
るＣＰＵを、２０２は基本入出力プログラムを記憶した
ＲＯＭを、２０３はＣＰＵ２０１のワークエリアとして
使用されるＲＡＭを、それぞれ示している。

【００３８】また、２０４はＣＰＵ２０１の制御にした
がってＨＤ（ハードディスク）２０５に対するデータの
リード／ライトを制御するＨＤＤ（ハードディスクドラ
イブ）を、２０５はＨＤＤ２０４の制御にしたがって書
き込まれたデータを記憶するＨＤを、それぞれ示してい
る。また、２０６はＣＰＵ２０１の制御にしたがってＦ
Ｄ（フロッピー（登録商標）ディスク）２０７に対する
データのリード／ライトを制御するＦＤＤ（フロッピー
ディスクドライブ）を、２０７はＦＤＤ２０６の制御に
したがって書き込まれたデータを記憶する着脱自在のＦ
Ｄを、それぞれ示している。

【００３９】また、２０８はカーソル、メニュー、ウィ
ンドウ、あるいは文字や画像などの各種データを表示す
るディスプレイを、２０９は通信回線２１０を介してイ
ンターネット１００への／からのデータの送受信をおこ
なうネットワークＩ／Ｆ（インターフェース）を、それ
ぞれ示している。また、２１１は文字、数値、各種指示
などの入力のための複数のキーを備えたキーボードを、
２１２は各種指示の選択や実行、処理対象の選択、カー
ソルの移動などをおこなうマウスを、それぞれ示してい
る。

【００４０】また、２１３は文字や画像を光学的に読み
取るスキャナを、２１４は文字や画像を用紙上に印刷す
るプリンタを、２１５は着脱可能な記録媒体であるＣＤ
−ＲＯＭを、２１６はＣＤ−ＲＯＭ２１５に対するデー
タのリードを制御するＣＤ−ＲＯＭドライブを、２００
は上記各部を接続するためのバスまたはケーブルを、そ
れぞれ示している。

【００４１】つぎに、この発明の実施の形態１によるデ
ータ送受信システムの機能的構成について説明する。図
３は、実施の形態１によるデータ送受信システムの構成
を機能的に示す説明図である。

【００４２】同図に示すように、カード会社Ａのコンピ
ュータ１０１は鍵生成部３０１ａ、鍵記憶部３０１ｂ、
鍵送信部３０１ｃ、カード情報記憶部３０１ｄ、カード
情報暗号化部３０１ｅおよびカード情報送信部３０１ｆ
を含む構成である。

【００４３】また、カード利用者Ｂのコンピュータ１０
２はカード情報受信部３０２ａ、カード情報記憶部３０
２ｂ、鍵受信部３０２ｃ、カード情報変換部３０２ｄ、
注文書作成部３０２ｅおよび注文書送信部３０２ｆを含
む構成である。

【００４４】また、加盟店Ｃのコンピュータ１０３は鍵
受信部３０３ａ、鍵記憶部３０３ｂ、鍵送信部３０３
ｃ、注文書受信部３０３ｄ、カード情報記憶部３０３ｅ
およびカード情報復号部３０３ｆを含む構成である。

【００４５】なお、上記各部は各コンピュータのＨＤ２
０５やＦＤ２０７、あるいはＣＤ−ＲＯＭ２１５などの
各種記録媒体からＲＡＭ２０３に読み出されたプログラ
ムの命令にしたがって、ＣＰＵ２０１などが命令処理を
実行することにより、後述するそれぞれの機能を実現す
るものである。また、特にカード利用者Ｂのコンピュー
タ１０２内の上記各部は、具体的にはブラウザのプラグ
インにより実現される。

【００４６】図４は、図６で後述する商品の発注／受注
処理に先立って、上記各部によりおこなわれる鍵の受け
渡し処理の手順を示すフローチャートである。以下この
フローチャートに沿って、上記各部の機能を説明する。

【００４７】ステップＳ４０１で、まずカード会社Ａの
コンピュータ１０１は、その鍵生成部３０１ａにより以
下で説明するＹ鍵・Ａ鍵・Ｕ鍵の３つの鍵を生成する。
これらの鍵は、「Ｙ鍵で暗号化されたものはＡ鍵による
変換後でなければＵ鍵で復号することはできず、Ａ鍵で
暗号化されたものはＵ鍵による変換後でなければＹ鍵で
復号することはできず、またどの鍵、あるいはどの２つ
の鍵の組み合わせによっても他の鍵を特定することは困
難である」という条件を満たさなければならない。

【００４８】このような３つの鍵はどのようにして求め
てもよいが、ここでは従来技術の公開鍵方式の一種であ
る、ＲＳＡ方式における鍵の導出方法を拡張・応用して
求める方法を示す。

【００４９】ＲＳＡで使用される秘密鍵と公開鍵の２つ
の鍵は、下記のようにして導出される。まず、２つの素
数ＰおよびＱを選び、「Ｎ＝Ｐ＊Ｑ」と「Ｌ＝最小公倍
数（Ｐ−１、Ｑ−１）」の２つの値を求める。そして、
「Ｄ＊Ｍ＝ｎ＊Ｌ＋１」が成立するＤとＭを求め（ただ
しｎは任意の正の整数）、Ｄを秘密鍵、Ｍを公開鍵とす
る。

【００５０】これらを使って、下記の計算式により暗号
化と復号をおこなう。なお、「Ｄａｔａ ＾Ｄ」はＤａ
ｔａのＤ乗を、また「ｍｏｄ Ｎ」はＮで割った余りを
取るという剰余演算を、それぞれ示している。 暗号化：Ｃｏｄｅｄ＝（Ｄａｔａ ＾Ｄ）ｍｏｄ Ｎ 復号 ：Ｄａｔａ ＝（Ｃｏｄｅｄ ＾Ｍ）ｍｏｄ Ｎ

【００５１】これに対して本発明では３つの鍵が必要な
ので、「Ｄ＊Ｍ＝ｎ＊Ｌ＋１」が成立するＤとＭを求め
る代わりに、「Ｙ＊Ａ＊Ｕ＝ｎ＊Ｌ＋１」が成立する
Ｙ、ＡおよびＵを求める。ただしＹ、Ａ、Ｕはそれぞれ
ｎ＊Ｌ＋１であってはならない。このようなＹ、Ａおよ
びＵの組は、「Ｄ（ｉ）＊Ｍ（ｉ）＝ｎ＊Ｌ＋１」を満
足するＤとＭの組から、下記により求めることができ
る。

【００５２】 Ｙ ＝Ｄ（０） Ａ（ｉ）＝Ｄ（ｉ） Ｕ（ｉ）＝（Ｍ（０）＊Ｍ（ｉ）−１）ｍｏｄ Ｌ＋１

【００５３】そして、これら３つの鍵をもちいて、暗号
化と復号とを下記計算式によりおこなう。 暗号化：Ｃｏｄｅｄ ＝（Ｄａｔａ ＾Ｙ）ｍｏｄ Ｎ ・・・（１） 変換 ：Ｃｏｄｅｄ２＝（Ｃｏｄｅｄ ＾Ａ）ｍｏｄ Ｎ ・・・（２） 復号 ：Ｄａｔａ ＝（Ｃｏｄｅｄ２ ＾Ｕ）ｍｏｄ Ｎ ・・・（３）

【００５４】なお、図６で後述するように（１）式によ
る暗号化はカード会社Ａにおける処理、（２）式による
変換はカード利用者Ｂにおける処理、また（３）式によ
る復号は加盟店Ｃにおける処理となる。

【００５５】なお、暗号化も復号も広義では変換に含ま
れ、ただ変換の目的や結果に着目してこのように呼ぶほ
うが分かりやすいので、以下では変換のうち特に変換前
のデータが平文であるような変換を暗号化、逆に変換後
のデータが平文であるような変換を復号と、それぞれ呼
ぶことにする。

【００５６】図４に戻り、つぎにステップＳ４０２でカ
ード会社Ａのコンピュータ１０１は、上記で生成した３
つの鍵をその鍵記憶部３０１ｂに格納する。また、ステ
ップＳ４０３で上記のうちＡ鍵とＵ鍵とを、その鍵送信
部３０１ｃから加盟店Ｃのコンピュータ１０３、具体的
にはその鍵受信部３０３ａに送信する。そして、ステッ
プＳ４０４で加盟店Ｃのコンピュータ１０３は、受信し
た２つの鍵をその鍵記憶部３０３ｂに格納する。

【００５７】なお、鍵を導出する計算式からも分かるよ
うに、一つのＹ鍵に対応するＡ鍵とＵ鍵との組は複数存
在する。そして、一つのカード会社Ａに対して複数存在
する加盟店Ｃ以下の各加盟店には、カード会社Ａが保持
する一つのＹ鍵に対応する、それぞれ異なるＡ鍵とＵ鍵
との組が渡される。

【００５８】つぎに、図５は図６で後述する商品の発注
／受注処理に先立って、図３に示す各部によりおこなわ
れるカード情報の受け渡し処理の手順を示すフローチャ
ートである。以下このフローチャートに沿って、上記各
部の機能の説明を続ける。なお、このフローチャートに
よる処理は、カード会社Ａが申込者Ｂからのカード利用
申し込みを受理した時点で開始される。

【００５９】ステップＳ５０１で、まずカード会社Ａの
コンピュータ１０１は、そのカード情報記憶部３０１ｄ
内の顧客データベースに、当該申込者（カード利用者
Ｂ）のカード情報、具体的にはそのカード番号、氏名、
住所、電話番号などを登録する。

【００６０】ステップＳ５０２で、カード会社Ａのコン
ピュータ１０１はそのカード情報暗号化部３０１ｅにお
いて、カード情報記憶部３０１ｄから取り出したカード
利用者Ｂのカード情報を、鍵記憶部３０１ｂから取り出
したＹ鍵により暗号化する。すなわち、上述の（１）式
にしたがって、「Ｄａｔａ」（ここでは平文のカード情
報）から「Ｃｏｄｅｄ」（Ｙ鍵で暗号化後のカード情
報）を作成する。

【００６１】つぎに、ステップＳ５０３でカード会社Ａ
のコンピュータ１０１は、Ｙ鍵による変換後のカード情
報を、そのカード情報送信部３０１ｆからカード利用者
Ｂのコンピュータ１０２、具体的にはそのカード情報受
信部３０２ａに送信する。そして、ステップＳ５０４で
カード利用者Ｂのコンピュータ１０２は、上記で受信し
たカード情報をそのカード情報記憶部３０２ｂに格納す
る。

【００６２】つぎに、図６はこの発明の実施の形態１に
よるデータ送受信システムにおける、商品の発注／受注
処理の手順を示すフローチャートである。以下このフロ
ーチャートに沿って、図３に示す各部の機能の説明を続
ける。なお、このフローチャートによる処理は、カード
利用者Ｂが加盟店Ｃのホームページなどで商品を発注し
たとき、具体的には所定の注文フォームなどに必要事項
を入力して、「ＯＫ」ボタンなどをクリックした時点で
開始される。

【００６３】ステップＳ６０１でカード利用者Ｂのコン
ピュータ１０２は、その鍵受信部３０２ｃにより、加盟
店Ｃのコンピュータ１０３に対してそのＡ鍵を送信する
よう要求する。そして、加盟店Ｃのコンピュータ１０３
はその鍵送信部３０３ｃで上記要求を受信すると、鍵記
憶部３０３ｂに格納されたＡ鍵を取り出して、要求元の
鍵受信部３０２ｃに返信する。

【００６４】つぎに、ステップＳ６０２でカード利用者
Ｂのコンピュータ１０２は、そのカード情報変換部３０
２ｄにおいて、カード情報記憶部３０２ｂから取り出し
たカード情報を上記で受信したＡ鍵により変換する。す
なわち、上述の（２）式にしたがって、「Ｃｏｄｅｄ」
（Ｙ鍵で暗号化後のカード情報）から「Ｃｏｄｅｄ２」
（Ｙ鍵で暗号化後さらにＡ鍵で変換されたカード情報）
を作成する。

【００６５】そして、ステップＳ６０３でカード利用者
Ｂのコンピュータ１０２は、その注文書作成部３０２ｅ
により、商品名や個数などからなる平文の注文内容に上
記で変換後のカード情報を付加することで、所定のフォ
ーマットの注文書を作成する。この後、ステップＳ６０
４でこの注文書を注文書送信部３０２ｆから送信し、こ
れが加盟店Ｃのコンピュータ１０３の注文書受信部３０
３ｄにより受信される。

【００６６】つぎに、ステップＳ６０５で加盟店Ｃのコ
ンピュータ１０３は、上記で受信した注文書内のカード
情報をそのまま（すなわち、Ｙ鍵により暗号化されＡ鍵
により変換された状態のまま）カード情報記憶部３０３
ｅに格納する。他方、ステップＳ６０６でそのカード情
報復号部３０３ｆにおいて、受信した注文書内のカード
情報をＵ鍵により復号する。すなわち、上述の（３）式
にしたがって、「Ｃｏｄｅｄ２」（Ｙ鍵で暗号化後さら
にＡ鍵で変換されたカード情報）から元の「Ｄａｔａ」
（平文のカード情報）を復元する。

【００６７】つぎに図７は、この発明の実施の形態１に
よるデータ送受信システムにおける、各コンピュータ間
でのデータの流れを模式的に示す説明図である。

【００６８】（ａ）鍵の受け渡し まず、事前にカード会社ＡにおいてＹ鍵・Ａ鍵・Ｕ鍵を
生成し（１）、Ａ鍵とＵ鍵の複数の組み合わせの中から
一つを選んで、各加盟店に送付しておく（２）。

【００６９】（ｂ）カード情報の受け渡し また、各カード利用者のカード情報をこのＹ鍵で暗号化
の上（３）、各人に送付しておく（４）。

【００７０】（ｃ）商品の発注／受注 商品の注文時には、カード利用者Ｂは加盟店Ｃのホーム
ページなどからそのＡ鍵をダウンロードして（５）、Ｙ
鍵で暗号化後のカード情報をさらにこのＡ鍵で変換し
（６）、これを平文の注文内容に追加（７）して注文書
を作成し、加盟店Ｃに送付する（８）。なお、これらの
処理はブラウザのプラグインにより、注文フォームの送
信時に自動的に実行され、特段の操作は必要ない。そし
て、加盟店Ｃではカード利用者Ｂから受け取った注文書
内のカード情報をバックアップするとともに、これをＵ
鍵により復号する（９）。

【００７１】（ｄ）代金の請求・決済 この後所定の締め日が到来すると、加盟店Ｃはカード会
社Ａに対して、バックアップしておいたカード情報を請
求書に添付して、各利用者の購入代金の支払いを請求す
る（１０）。

【００７２】カード会社Ａでは利用総額の明細書を各利
用者に送付するとともに、提出されたカード情報のバッ
クアップがＵ鍵で正常に復号できない場合、加盟店Ｃに
よる偽造の疑いがあると判断し、注文主とされている利
用者に別途購入有無の確認を求める。そして、この確認
が得られた場合や、Ｕ鍵での復号に異常がなかった場合
には、各利用者の口座からの代金引き落としと、各加盟
店の口座への代金振り込みをおこなう（１１）。

【００７３】図１１で示した従来技術に比較して、図７
に示す本発明では鍵の個数が半分で、暗号化や復号の手
続きも簡略化されていることが分かる。また、カード利
用者Ｂから加盟店Ｃに渡る（８）カード情報は、カード
会社Ａから送付されてきたカード情報（４）がさらにＡ
鍵で変換された（６）ものであり、加盟店Ｃではこれを
Ｕ鍵で復号して平文に戻す（９）ことはできても、Ａ鍵
による変換前の状態（すなわち、Ｙ鍵により暗号化され
ただけの状態）に戻すことはできない。

【００７４】したがって、加盟店Ｃによる注文書の偽造
は自店宛以外不可能である。なぜなら、他の加盟店Ｃ’
に対する注文書の偽造には、必ずＹ鍵により暗号化され
ただけの状態の（すなわち、カード会社Ａから送付され
たままの状態の）カード情報が必要だからである。

【００７５】逆に、他の加盟店Ｃ’は、受け取った注文
書内のカード情報部分が自己のＵ’鍵で復号できれば、
当該カード情報はカード会社Ａから送付された状態のカ
ード情報を保持するカード利用者Ｂ、すなわち正当な権
利者によって自己のＡ’鍵で変換されたものと分かり、
不正目的の加盟店Ｃがカード利用者Ｂになりすますなど
して、注文書を偽造したものではないと判断できる。

【００７６】以上説明したように実施の形態１によるデ
ータ送受信システムでは、３つの鍵による単純な暗号化
でありながら、カード情報の偽造が非常に困難なので、
三者間でのカード決済を簡易かつ安全におこなうことが
できる。

【００７７】なお、上記では混乱を避けるため説明を省
略したが、鍵送信部３０１ｃから鍵受信部３０３ａへの
鍵の送信（図７の（２））、カード情報送信部３０１ｆ
からカード情報受信部３０２ａへのカード情報の送信
（同（４））、および注文書送信部３０２ｆから注文書
受信部３０３ｄへの注文書の送信（同（８））時には、
Ｙ鍵・Ａ鍵・Ｕ鍵とは別の通信用の鍵によって通信内容
を暗号化する。ただ、特に前二者については厳重な秘密
保持が必要なので、オンラインでなくオフライン、たと
えば郵便などによって送付をおこなうようにしてもよ
い。

【００７８】（実施の形態２）さて、上述した実施の形
態１は三者が実際に取引に関与する例であったが、現実
社会には共通の知人や公的機関の発行した推薦状、紹介
状、保証書、証明書などを信用して二者間で取り引きす
るケースなど、実質的に三者が関与しているとみること
ができる取引も存在する。そして、このような取引にお
いても、各種書面の偽造や変造がしばしば問題となるの
で、以下で説明する実施の形態２のように、３つの鍵に
よる暗号化や復号を各種の証書類に応用するのであって
もよい。

【００７９】図８は、実施の形態２によるデータ送受信
システムのシステム構成を示す説明図である。図中、８
０１は証明者Ａの保持するコンピュータ、８０２は被証
明者Ｂの保持するコンピュータ、８０３は被証明者Ｂと
取り引きする相手方Ｃの保持するコンピュータであり、
８００は上記の各コンピュータを相互に接続するネット
ワーク、具体的にはインターネットを示している。な
お、各コンピュータのハードウエア構成は、図２に示し
た実施の形態１のそれと同様であるものとする。

【００８０】つぎに、図９は実施の形態２によるデータ
送受信システムの構成を機能的に示す説明図である。同
図に示すように、証明者Ａのコンピュータ８０１は鍵記
憶部９０１ａ、鍵選択部９０１ｂ、鍵送信部９０１ｃ、
証明事項記憶部９０１ｄ、証明書作成部９０１ｅ、証明
書暗号化部９０１ｆおよび証明書送信部９０１ｇを含む
構成である。

【００８１】また、被証明者Ｂのコンピュータ８０２は
証明書受信部９０２ａ、鍵受信部９０２ｂ、証明書変換
部９０２ｃおよび証明書送信部９０２ｄを含む構成であ
る。また、取引先Ｃのコンピュータ８０３は鍵受信部９
０３ａ、鍵記憶部９０３ｂ、鍵送信部９０３ｃ、証明書
受信部９０３ｄおよび証明書復号部９０３ｅを含む構成
である。

【００８２】なお、上記各部は各コンピュータのＨＤ２
０５やＦＤ２０７、あるいはＣＤ−ＲＯＭ２１５などの
各種記録媒体からＲＡＭ２０３に読み出されたプログラ
ムの命令にしたがって、ＣＰＵ２０１などが命令処理を
実行することにより、後述するそれぞれの機能を実現す
るものである。

【００８３】つぎに、図１０は実施の形態２によるデー
タ送受信システムにおける、証明書発行・提出処理の手
順を示すフローチャートである。以下このフローチャー
トに沿って、図９に示す各部の機能を説明する。

【００８４】ステップＳ１００１で、まず取引先Ｃのコ
ンピュータ８０３はその鍵受信部９０３ａから、証明者
Ａのコンピュータ８０１に対してＡ鍵とＵ鍵とを送信す
るよう要求する。この要求をその鍵送信部９０１ｃによ
り受信した証明者Ａのコンピュータ８０１は、ステップ
Ｓ１００２でその鍵選択部９０１ｂにより、あらかじめ
生成されて鍵記憶部９０１ａに格納されているＡ鍵とＵ
鍵との対のうち、まだ他の個人などに使用されていない
いずれかの一対を選択する。そして、ステップＳ１００
３でこの選択されたＡ鍵とＵ鍵とを、鍵送信部９０１ｃ
から要求元の鍵受信部９０３ａに返信する。

【００８５】取引先Ｃのコンピュータ８０３は、受信し
たＡ鍵とＵ鍵とを、ステップＳ１００４でその鍵記憶部
９０３ｂに格納するとともに、ステップＳ１００５でそ
の鍵送信部９０３ｃから、被証明者Ｂのコンピュータ８
０２の鍵受信部９０２ｂに送信する。

【００８６】また、ステップＳ１００６で被証明者Ｂの
コンピュータ８０２は、その証明書受信部９０２ａから
証明者Ａのコンピュータ８０１に対して、証明書の発行
要求を送信する。この発行要求をその証明書送信部９０
１ｇで受信した証明者Ａのコンピュータ８０１は、ステ
ップＳ１００７でその証明書作成部９０１ｅにより、証
明事項記憶部９０１ｄに蓄積された各種の証明事項、た
とえば住所や生年月日などの中から、上記発行要求中で
指定された事項を抽出して、所定のフォーマットの証明
書を作成する。

【００８７】そして、この証明書をステップＳ１００８
で証明書暗号化部９０１ｆにより、Ｙ鍵で暗号化の上、
ステップＳ１００９で証明書送信部９０１ｇから、要求
元の証明書受信部９０２ａに返信する。なお、このＹ鍵
で暗号化後の証明書を、以下では「証明書の原本」ある
いは単に「原本」と呼ぶ。

【００８８】そして、ステップＳ１０１０で被証明者Ｂ
のコンピュータ８０２は、その証明書変換部９０２ｃに
より、証明者Ａから受信した証明書の原本を取引先Ｃか
ら受信したＡ鍵で変換する。その後、ステップＳ１０１
１でこの変換後の原本を、証明書送信部９０２ｄから取
引先Ｃのコンピュータ８０３の証明書受信部９０３ｄに
送信する。

【００８９】そして、ステップＳ１０１２で取引先Ｃの
コンピュータ８０３は、上記で受信した変換後の原本
を、その証明書復号部９０３ｅでＵ鍵により復号する。

【００９０】なお、被証明者Ｂは証明者ＡのＹ鍵が入手
できない限り、架空の証明書をＹ鍵で暗号化して、あた
かも証明者Ａから発行されたかのように見せかけたり
（すなわち偽造）、あるいは証明者Ａから受け取った原
本をＹ鍵で復号し、内容を改竄の上、再びＹ鍵で暗号化
したりする（すなわち変造）ことはできない。また、取
引先Ｃも被証明者Ｂから受け取った証明書を、その保持
するＵ鍵により平文に戻せるだけで、証明者ＡのＹ鍵が
入手できない以上、その偽造や変造は不可能である。無
理にこれらをおこなえば、Ｕ鍵による復号が不能か異常
となるので、不正行為の事実が発覚する。

【００９１】したがって、Ｙ鍵の管理が万全である限
り、証明書の受領者は逐一その証明者に照会しなくて
も、受け取った証明書がＵ鍵で正常に復号できたことを
もって、当該証明書が真正なものであることを確認でき
る。

【００９２】また、被証明者がある取引先用に変換した
証明書は、他の取引先では復号できないので（取引先ご
とにＡ鍵とＵ鍵とが異なるため）、紛失などの事故があ
っても意図しない相手に証明書を復号されてしまうこと
がない。被証明者が原本の変換の時点で、変換に使用す
る鍵により、当該証明書を閲覧できる相手を限定できる
と言ってもよい。

【００９３】なお、上記の証明者としては政府などの公
的機関、証明書としては戸籍謄本や住民票などの公的書
類が代表的なものであるが、これに限らず証明者や証明
書の記載事項はどのようなものであってもよい。

【００９４】たとえば、あるソフトウエアの登録ユーザ
ーであって、一定期間にわたって登録住所に製品案内な
どが届いているユーザーは、それだけで住所の安定し
た、比較的信用できる顧客とみることができる。そこ
で、ソフトウエアの開発元が証明機関となり、ユーザー
登録日や登録製品名、最後に郵便物の送達が確認された
日などの各種事項のうち、各登録ユーザーから指定され
た任意の事項について証明書を作成し、暗号化の上交付
する。

【００９５】インターネットの匿名性により、通信販売
やオークションなどでは詐欺などのトラブルが多発して
おり、たとえば通販会社では据え置き電話のある個人・
法人に顧客を絞ったり（携帯電話では信用が取れないた
め）、他の会社などから顧客リストを購入したりして、
多くの費用と労力をかけて顧客の選別をおこなってい
る。また、オークションでは各人の取引履歴を公開して
いるものもあるが、信用できる参加者でも最初は信用０
であり、逆に信用できない参加者でも別のＩＤを取得す
れば容易に別人を装うことができてしまう。

【００９６】この点、上述のように簡単に運用でき、し
かも偽造・変造が困難なユーザー証明書であれば、通販
会社やオークションの主催者は、前もって証明書を提出
させるだけで、比較的信用できるユーザーに注文者や参
加者を絞り込むことができる。

【００９７】また、被証明者としても、登録ユーザーと
いう従来評価されていなかった一種のステータスを、個
人の評価に結びつけることができる。さらに、証明機関
であるソフトウエア会社は、証明書の発行時やＡ鍵・Ｕ
鍵の交付（あるいは貸与）時に手数料を徴収できるほ
か、登録ユーザーの地位が社会的に評価されることにと
もない、ユーザー登録率の向上を期待することができ
る。

【００９８】そして、こうしたオープンな証明のシステ
ムが広く運用されることで、従来おこなわれていた顧客
リストの闇取引がなくなり、意図しない相手への個人情
報の漏洩が低減してゆくことを期待できる。

【００９９】なお、実施の形態２による取引先とは、必
ずしも通信販売やオークションなどの売買取引の相手方
に限らない。たとえば、参加者をあるソフトウエアの登
録ユーザーに限定している掲示板などにおいて、その管
理者にＵ鍵とＡ鍵を、また参加希望者にユーザー証明書
を、当該ソフトウエアの開発元からそれぞれ交付するよ
うにすれば、開発元への問い合わせや開発元からの回答
を要せず、管理者限りで容易に各希望者の参加資格の有
無を確認することができる。

【０１００】また、上述の実施の形態２では、被証明者
からその取引先に対して証明書を提出するようにした
が、被証明者が多数の取引先に同一の証明をおこなわな
ければならないときは、逆に取引先のほうから被証明者
の証明書を取りにゆくようにしてもよい。

【０１０１】たとえば、被証明者はその開設するホーム
ページに、ソフトウエア会社から取得したユーザー証明
書と当該ソフトウエアのロゴを貼り付け、ロゴがクリッ
クされると専用のｃｇｉが起動するようにしておく。そ
して、このｃｇｉは起動時に閲覧者（すなわち取引先）
の保持するＡ鍵を要求し、取得したＡ鍵で証明書の原本
を変換の上、当該閲覧者に返信する。閲覧者は取得した
証明書をその保持するＵ鍵で復号して、当該被証明者の
ユーザー登録の詳細を確認することができる。

【０１０２】また、上述の実施の形態２では、一対のＡ
鍵とＵ鍵を特定の個人・法人に限定的に交付すること
で、証明書の内容がそれ以外の部外者に閲覧されること
を避けたが、逆に証明書の内容が世間にアピールしたい
ようなもの、一般への表示が義務づけられているもの、
あるいは少なくとも誰に見られても差し支えないような
ものであれば、これらの鍵を証明機関で公開するように
してもよい。

【０１０３】たとえば、被証明者は「徳島太郎は一太郎
Ｖｅｒ．○の登録ユーザーです」という一文からなる証
明書を、当該ソフトウエアの開発元に申し込んで発行し
てもらう（もちろんＹ鍵により暗号化されているのでこ
の平文が読めるわけではない）。そして、当該開発元の
ホームページからダウンロードした汎用のＡ鍵で、この
証明書を変換し、このソフトウエアで作成した文書に埋
め込んでおく。文書の閲覧者は、上記ホームページから
ダウンロードした汎用のＵ鍵で変換後の証明書を復号
し、上記平文を得る。

【０１０４】なお、Ａ鍵とＵ鍵とはホームページで公開
するのでなく、ソフトウエア自体に組み込んでおき、た
とえばメニューから「ユーザー証明書の埋め込み」を選
択すると、指定されたデータがＡ鍵により変換されて文
書に組み込まれ、また「ユーザー証明書の表示」を選択
すると、文書に埋め込まれた変換後のデータがＵ鍵で復
号されて表示されるようにしてもよい。

【０１０５】また、交付された証明書に、当該証明書を
埋め込む文書のハッシュキーを添付して、その全体をＡ
鍵で変換した上で当該文書に埋め込むようにしてもよ
い。この文書の閲覧者は、Ｕ鍵で変換後のハッシュキー
をＹ鍵を保持する開発元に送付し、Ｙ鍵で復号されたハ
ッシュキーの返信を受けて、手元で計算したハッシュキ
ーの値と一致するかどうかを確認する。そして、両者が
一致していれば、当該文書には改竄がないものと判断す
ることができる。

【０１０６】なお、上述した実施の形態１および２で
は、データの授受に関与するのがカード会社・カード利
用者・加盟店、あるいは証明者・被証明者・被証明者の
相手方の三者であったために、Ｙ鍵・Ａ鍵・Ｕ鍵の三種
類の鍵を生成するようにしたが、当事者数（厳密には、
立場の異なる当事者数。当事者の種別、などと言っても
よい）がそれより多ければ、その数と同数の鍵を生成し
て本発明を応用することができるのは言うまでもない。

【０１０７】

【発明の効果】以上説明したように請求項１に記載の発
明によれば、第１、第２および第３の情報処理装置間で
データを送受信するデータ送受信システムにおいて、前
記第１の情報処理装置がデータを第１の鍵により変換す
る第１の変換手段と、前記第１の変換手段により変換さ
れたデータを送信する第１の送信手段と、を備え、前記
第２の情報処理装置が前記第１の送信手段から送信され
てきたデータを受信する第１の受信手段と、前記第１の
受信手段により受信されたデータを第２の鍵により変換
する第２の変換手段と、前記第２の変換手段により変換
されたデータを送信する第２の送信手段と、を備え、前
記第３の情報処理装置が前記第２の送信手段から送信さ
れてきたデータを受信する第２の受信手段と、前記第２
の受信手段により受信されたデータを第３の鍵により変
換する第３の変換手段と、を備えたので、変換後のデー
タの取得者はその直前の変換元による変換前のデータを
捏造し、あるいは変換後のデータから復元した変換前の
データを改竄して、当該変換元と同一の変換を施すこと
はできず、これによって、異なる三者間を経由するデー
タの送受信において、当該データの偽造・変造を防止す
ることが可能なデータ送受信システムが得られるという
効果を奏する。

【０１０８】また、請求項２に記載の発明によれば、第
１および第２の情報処理装置間でデータを送受信するデ
ータ送受信システムにおいて、前記第１の情報処理装置
が第１の鍵により変換されたデータをさらに第２の鍵に
より変換する第１の変換手段と、前記第１の変換手段に
より変換されたデータを送信する送信手段と、を備え、
前記第２の情報処理装置が前記送信手段から送信されて
きたデータを受信する受信手段と、前記受信手段により
受信されたデータを第３の鍵により変換する第２の変換
手段と、を備えたので、変換後のデータの取得者はその
直前の変換元による変換前のデータを捏造し、あるいは
変換後のデータから復元した変換前のデータを改竄し
て、当該変換元と同一の変換を施すことはできず、これ
によって、異なる三者間を経由するデータの送受信にお
いて、当該データの偽造・変造を防止することが可能な
データ送受信システムが得られるという効果を奏する。

【０１０９】また、請求項３に記載の発明によれば、前
記請求項１または請求項２に記載の発明において、前記
第１の鍵により変換されたデータは、前記第２の鍵によ
り変換されさらに前記第３の鍵により変換されると前記
第１の鍵による変換前の元のデータとなるので、変換後
のデータの取得者はその直前の変換元による変換前のデ
ータを捏造し、あるいは変換後のデータから復元した変
換前のデータを改竄して、当該変換元と同一の変換を施
すことはできない一方で、２つ前の変換元による変換前
のデータは復元することができ、これによって、異なる
三者間を経由するデータの送受信において、当該データ
の偽造・変造を防止するとともに、最初の送信者と最後
の受信者だけは当該データの内容を容易に閲覧すること
が可能なデータ送受信システムが得られるという効果を
奏する。

【０１１０】また、請求項４に記載の発明によれば、第
１、第２および第３の情報処理装置間でデータを送受信
するデータ送受信方法において、前記第１の情報処理装
置で、データを第１の鍵により変換する第１の変換工程
と、前記第１の変換工程で変換されたデータを、前記第
１の情報処理装置から前記第２の情報処理装置に送信す
る第１の送信工程と、前記第２の情報処理装置で、前記
第１の送信工程で送信されてきたデータを第２の鍵によ
り変換する第２の変換工程と、前記第２の変換工程で変
換されたデータを、前記第２の情報処理装置から前記第
３の情報処理装置に送信する第２の送信工程と、前記第
３の情報処理装置で、前記第２の送信工程で送信されて
きたデータを第３の鍵により変換する第３の変換工程
と、を含んだので、変換後のデータの取得者はその直前
の変換元による変換前のデータを捏造し、あるいは変換
後のデータから復元した変換前のデータを改竄して、当
該変換元と同一の変換を施すことはできず、これによっ
て、異なる三者間を経由するデータの送受信において、
当該データの偽造・変造を防止することが可能なデータ
送受信方法が得られるという効果を奏する。

【０１１１】また、請求項５に記載の発明によれば、第
１および第２の情報処理装置間でデータを送受信するデ
ータ送受信方法において、第１の鍵により変換されたデ
ータを、前記第１の情報処理装置でさらに第２の鍵によ
り変換する第１の変換工程と、前記第１の変換工程で変
換されたデータを、前記第１の情報処理装置から前記第
２の情報処理装置に送信する送信工程と、前記送信工程
で送信されてきたデータを、前記第２の情報処理装置で
第３の鍵により変換する第２の変換工程と、を含んだの
で、変換後のデータの取得者はその直前の変換元による
変換前のデータを捏造し、あるいは変換後のデータから
復元した変換前のデータを改竄して、当該変換元と同一
の変換を施すことはできず、これによって、異なる三者
間を経由するデータの送受信において、当該データの偽
造・変造を防止することが可能なデータ送受信方法が得
られるという効果を奏する。

【０１１２】また、請求項６に記載の発明によれば、前
記請求項４または請求項５に記載の発明において、前記
第１の鍵により変換されたデータは、前記第２の鍵によ
り変換されさらに前記第３の鍵により変換されると前記
第１の鍵による変換前の元のデータとなるので、変換後
のデータの取得者はその直前の変換元による変換前のデ
ータを捏造し、あるいは変換後のデータから復元した変
換前のデータを改竄して、当該変換元と同一の変換を施
すことはできない一方で、２つ前の変換元による変換前
のデータは復元することができ、これによって、異なる
三者間を経由するデータの送受信において、当該データ
の偽造・変造を防止するとともに、最初の送信者と最後
の受信者だけは当該データの内容を容易に閲覧すること
が可能なデータ送受信方法が得られるという効果を奏す
る。

【０１１３】また、請求項７に記載の発明によれば、前
記請求項４〜請求項６のいずれか一つに記載された方法
をコンピュータに実行させるプログラムを記録したこと
で、当該プログラムをコンピュータで読み取ることが可
能となり、これによって、前記請求項４〜請求項６のい
ずれか一つに記載された方法をコンピュータによって実
施することが可能な記録媒体が得られるという効果を奏
する。

【図面の簡単な説明】

【図１】実施の形態１によるデータ送受信システムのシ
ステム構成を示す説明図である。

【図２】実施の形態１によるデータ送受信システムを構
成する、個々のコンピュータのハードウエア構成の一例
を示す説明図である。

【図３】実施の形態１によるデータ送受信システムの構
成を機能的に示す説明図である。

【図４】実施の形態１によるデータ送受信システムにお
ける、鍵の受け渡し処理の手順を示すフローチャートで
ある。

【図５】実施の形態１によるデータ送受信システムにお
ける、カード情報の受け渡し処理の手順を示すフローチ
ャートである。

【図６】実施の形態１によるデータ送受信システムにお
ける、商品の発注／受注処理の手順を示すフローチャー
トである。

【図７】実施の形態１によるデータ送受信システムにお
ける、各コンピュータ間でのデータの流れを模式的に示
す説明図である。

【図８】実施の形態２によるデータ送受信システムのシ
ステム構成を示す説明図である。

【図９】実施の形態２によるデータ送受信システムの構
成を機能的に示す説明図である。

【図１０】実施の形態２によるデータ送受信システムに
おける、証明書発行・提出処理の手順を示すフローチャ
ートである。

【図１１】従来技術によるデータ送受信システムにおけ
る、各コンピュータ間でのデータの流れを模式的に示す
説明図である。

【符号の説明】

１００ インターネット １０１ カード会社Ａのコンピュータ １０２ カード利用者Ｂのコンピュータ １０３ 加盟店Ｃのコンピュータ ２００ バスまたはケーブル ２０１ ＣＰＵ ２０２ ＲＯＭ ２０３ ＲＡＭ ２０４ ＨＤＤ ２０５ ＨＤ ２０６ ＦＤＤ ２０７ ＦＤ ２０８ ディスプレイ ２０９ ネットワークＩ／Ｆ ２１０ 通信回線 ２１１ キーボード ２１２ マウス ２１３ スキャナ ２１４ プリンタ ２１５ ＣＤ−ＲＯＭ ２１６ ＣＤ−ＲＯＭドライブ ３０１ａ 鍵生成部 ３０１ｂ 鍵記憶部 ３０１ｃ 鍵送信部 ３０１ｄ カード情報記憶部 ３０１ｅ カード情報暗号化部 ３０１ｆ カード情報送信部 ３０２ａ カード情報受信部 ３０２ｂ カード情報記憶部 ３０２ｃ 鍵受信部 ３０２ｄ カード情報変換部 ３０２ｅ 注文書作成部 ３０２ｆ 注文書送信部 ３０３ａ 鍵受信部 ３０３ｂ 鍵記憶部 ３０３ｃ 鍵送信部 ３０３ｄ 注文書受信部 ３０３ｅ カード情報記憶部 ３０３ｆ カード情報復号部 ８００ インターネット ８０１ 証明者Ａのコンピュータ ８０２ 被証明者Ｂのコンピュータ ８０３ 取引先Ｃのコンピュータ ９０１ａ 鍵記憶部 ９０１ｂ 鍵選択部 ９０１ｃ 鍵送信部 ９０１ｄ 証明事項記憶部 ９０１ｅ 証明書作成部 ９０１ｆ 証明書暗号化部 ９０１ｇ 証明書送信部 ９０２ａ 証明書受信部 ９０２ｂ 鍵受信部 ９０２ｃ 証明書変換部 ９０２ｄ 証明書送信部 ９０３ａ 鍵受信部 ９０３ｂ 鍵記憶部 ９０３ｃ 鍵送信部 ９０３ｄ 証明書受信部 ９０３ｅ 証明書復号部

Claims (7)

【特許請求の範囲】
1. 【請求項１】 第１、第２および第３の情報処理装置間
   でデータを送受信するデータ送受信システムにおいて、 前記第１の情報処理装置は、 データを第１の鍵により変換する第１の変換手段と、 前記第１の変換手段により変換されたデータを送信する
   第１の送信手段と、を備え、 前記第２の情報処理装置は、 前記第１の送信手段から送信されてきたデータを受信す
   る第１の受信手段と、 前記第１の受信手段により受信されたデータを第２の鍵
   により変換する第２の変換手段と、 前記第２の変換手段により変換されたデータを送信する
   第２の送信手段と、を備え、 前記第３の情報処理装置は、 前記第２の送信手段から送信されてきたデータを受信す
   る第２の受信手段と、 前記第２の受信手段により受信されたデータを第３の鍵
   により変換する第３の変換手段と、 を備えたことを特徴とするデータ送受信システム。
2. 【請求項２】 第１および第２の情報処理装置間でデー
   タを送受信するデータ送受信システムにおいて、 前記第１の情報処理装置は、 第１の鍵により変換されたデータをさらに第２の鍵によ
   り変換する第１の変換手段と、 前記第１の変換手段により変換されたデータを送信する
   送信手段と、を備え、 前記第２の情報処理装置は、 前記送信手段から送信されてきたデータを受信する受信
   手段と、 前記受信手段により受信されたデータを第３の鍵により
   変換する第２の変換手段と、 を備えたことを特徴とするデータ送受信システム。
3. 【請求項３】 前記第１の鍵により変換されたデータ
   は、前記第２の鍵により変換されさらに前記第３の鍵に
   より変換されると前記第１の鍵による変換前の元のデー
   タとなることを特徴とする前記請求項１または請求項２
   に記載のデータ送受信システム。
4. 【請求項４】 第１、第２および第３の情報処理装置間
   でデータを送受信するデータ送受信方法において、 前記第１の情報処理装置で、データを第１の鍵により変
   換する第１の変換工程と、 前記第１の変換工程で変換されたデータを、前記第１の
   情報処理装置から前記第２の情報処理装置に送信する第
   １の送信工程と、 前記第２の情報処理装置で、前記第１の送信工程で送信
   されてきたデータを第２の鍵により変換する第２の変換
   工程と、 前記第２の変換工程で変換されたデータを、前記第２の
   情報処理装置から前記第３の情報処理装置に送信する第
   ２の送信工程と、 前記第３の情報処理装置で、前記第２の送信工程で送信
   されてきたデータを第３の鍵により変換する第３の変換
   工程と、 を含んだことを特徴とするデータ送受信方法。
5. 【請求項５】 第１および第２の情報処理装置間でデー
   タを送受信するデータ送受信方法において、 第１の鍵により変換されたデータを、前記第１の情報処
   理装置でさらに第２の鍵により変換する第１の変換工程
   と、 前記第１の変換工程で変換されたデータを、前記第１の
   情報処理装置から前記第２の情報処理装置に送信する送
   信工程と、 前記送信工程で送信されてきたデータを、前記第２の情
   報処理装置で第３の鍵により変換する第２の変換工程
   と、 を含んだことを特徴とするデータ送受信方法。
6. 【請求項６】 前記第１の鍵により変換されたデータ
   は、前記第２の鍵により変換されさらに前記第３の鍵に
   より変換されると前記第１の鍵による変換前の元のデー
   タとなることを特徴とする前記請求項４または請求項５
   に記載のデータ送受信方法。
7. 【請求項７】 前記請求項４〜請求項６のいずれか一つ
   に記載された方法をコンピュータに実行させるプログラ
   ム。