JP2010114615A - 商品購入システム - Google Patents

Abstract

【課題】これまでよりもユーザがセキュリティ面での安心感を持つことのできる、より万全なセキュリティ環境でオンラインショッピングができるようにする。
【解決手段】ユーザは、復号キーとペアで作成された暗号キーと、クレジットカードに対応した識別子とが記憶されたクレジットカードデバイス２を所有する。ユーザ端末装置におけるオンラインショッピングでの商品の購入決定操作に応じては購入決定された商品の情報と識別子から成る購入情報と認証情報を送信する。認証情報は、購入情報のハッシュ値を暗号キーにより暗号化する。レジサーバ３は、購入情報と認証情報を受信すると、識別子と対応する復号キーにより認証情報を復号してハッシュ値を得る。また購入情報のハッシュ値を得る。これらのハッシュ値を比較して認証処理を実行する。
【選択図】図１４

Description

本発明は、インターネットに代表されるネットワーク経由でユーザ(消費者)が商品の購入を行えるように構築される商品購入システムに関する。

例えばオンラインショッピングやインターネットショッピングなどといわれるように、インターネットを利用して一般のユーザ(消費者)が商品を注文、購入できるようにされた環境が広く普及している現状にある。

このようなオンラインショッピングでの料金の支払い方法の１つとして、クレジットカードの利用が挙げられる。
オンラインショッピングにてクレジットカードを利用して商品を購入するときには、例えばユーザは、オンラインショップのWebページにおけるクレジットカード情報の入力フォームに対してクレジットカード情報を入力する。ここでのクレジット情報とは、クレジット会社やクレジット番号、クレジットカードの有効期限などとなる。そして、このように入力したクレジットカード情報を、オンラインショップに対して送信する。
オンラインショップ側では、受信した上記の個人情報におけるクレジットカード情報を利用して商品の代金についての決済を行ったうえで、ユーザが購入した商品の集荷、発想などを行う。

ここで、上記のクレジットカード情報は、第三者に漏洩してはならない情報であるため、例えば特許文献１などにも記載されるように、ネットワーク上での送受信に際しては、暗号化が施されるのが通常となっている。

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

上記のようにして現状のオンラインショッピングにおいて、クレジットカード情報などに代表される個人情報をネットワーク経由で送受信するときには、送受信データの暗号化によりその秘匿性を保つようにされている。
しかし、暗号化が施されているとはいえ、個人情報がネットワーク上で伝搬していることに代わりはない。現在の暗号化技術は非常に高度であり実質的には解読不可能とされているものの、暗号解読技術であるとか、コンピュータ装置の処理性能は日を追うようにして高度化している。
このような観点からすると、ユーザとしては、個人情報がネットワーク上で送受信されている以上、絶対的な安心感は得られないということがいえる。

そこで本発明は上記した課題を考慮して、ユーザが所有するクレジットカード対応記憶媒体と、ユーザ端末装置と、クレジットカード会社のサーバ装置とから成り、上記クレジットカード対応記憶媒体には、１のクレジットカードに対応する識別子であるクレジットカード対応識別子と、クレジットカード会社側にてペアキーとして生成した２つのキーの一方である暗号キーとが記憶され、上記ユーザ端末装置は、ネットワーク経由での通信を実現するための端末側通信手段と、上記クレジットカード対応記憶媒体をマウントするマウント手段と、ユーザの操作に応じて、ネットワーク上に存在する１以上のオンラインショップにアクセスして商品を検索し、検索した商品を仮想ショッピングカートに入れる処理を実行するもので、仮想ショッピングカートに入れた商品についての情報はローカルにて生成して保持する、店舗検索／商品検索／ショッピングカート管理手段と、商品の購入決定操作に応じては、上記仮想ショッピングカートに入っているとされる商品についての情報に基づいて、購入決定された商品に関連する情報と、マウントされたクレジットカード対応記憶媒体から読み出して取得したクレジットカード対応識別子とを少なくとも有する、購入情報を生成する購入情報生成手段と、所定の一方向ハッシュ関数を用いた演算により上記購入情報についてのハッシュ値を求める端末側ハッシュ演算手段と、上記ハッシュ値を、マウントされたクレジットカード対応記憶媒体から読み出して取得した上記暗号キーにより暗号化して認証情報を生成する認証情報生成手段と、平文の上記購入情報と、上記認証情報と、を上記サーバ装置に対してネットワーク経由で送信する送信手段とを備え、上記サーバ装置は、ネットワーク経由での通信を実現するための通信手段と、上記ユーザ端末装置から送信されてきた上記購入情報と上記認証情報とを受信して取得する受信取得手段と、取得した上記購入情報について、上記端末側ハッシュ演算手段と同じ一方向ハッシュ関数によりハッシュ値を求めるサーバ側ハッシュ演算手段と、上記ペアキーとして生成した２つのキーの他方を復号キーとして、１のクレジットカード対応識別子と対応付けて記憶管理する復号キー管理手段と、上記購入情報から取得したクレジットカード対応識別子に対応付けられている復号キーを検索する検索手段と、検索された復号キーにより、取得した上記認証情報について復号処理を行ってハッシュ値を復元する復元手段と、上記サーバ側ハッシュ演算手段により求めたハッシュ値と、上記復元手段により得られたハッシュ値とを比較した結果に基づいて認証成立の可否についての結果を出力する認証手段と、クレジットカード対応識別子に対応するクレジットカードごとに関連した必要な情報であり、そのクレジットカードの契約者についての個人情報を含むクレジットカード関連情報を記憶管理するクレジットカード関連情報管理手段と、上記認証手段により認証成立の結果が出力された場合において、取得した上記購入情報と、この購入情報から取得したクレジットカード対応識別子に対応するクレジットカード関連情報とを利用してユーザについての決済処理を行う決済手段とを備えて、商品購入システムを構成することとした。

上記構成により、本願発明は、これまでよりも万全で、ユーザにも確かな安心感が与えられるセキュリティ環境のもとで、オンラインショッピングを運営できる。

以降における発明を実施するための最良の形態（実施形態）については、下記の目次の順で説明する。

［目次］
＜１．システム概要＞
＜２．ユーザ端末装置＞
＜３．クレジットカードデバイス＞
＜４．レジサーバ＞
＜５．クレジットカードデバイス作成手順＞
＜６．ユーザ端末装置、レジサーバのアルゴリズム例＞
［６−１．ユーザ端末装置］
［６−２．レジサーバ］
［６−３．認証処理］

＜１．システム概要＞

図１は、本実施形態としての商品購入システムの構築例を示す図である。
本実施形態の商品購入システムは、図示するようにして、先ず、ネットワーク（インターネット）６上に存在するユーザ端末装置１、オンラインショップ４（４−Ａ，４−Ｂ）、レジサーバ３を備える。また、ユーザ端末装置１に装填されるクレジットカードデバイス２を必要とする。また、レジサーバ３を運営管理するクレジットカード会社５も含むものとしている。

ユーザ端末装置１は、例えばネットワーク（インターネット）との接続機能を有するパーソナルコンピュータ装置などとされ、本実施形態の商品購入システムに関しては商品の購買者となるユーザが使用する、ネットワーク６上の端末装置である。

ここでのユーザ端末装置１のユーザは、クレジットカード会社５のクレジットカードを契約して所有している者となる。そのうえで、クレジットカードデバイス２は、クレジットカード会社５から各ユーザに配布されるものである。配布の態様としては、クレジットカードと同じく、クレジットカード会社からユーザの自宅などに郵送、配達などによって送られてくるものとする。

より詳しい内容については後述するが、クレジットカードデバイス２には、本実施形態の商品購入システムをユーザが利用するのに必要な、アプリケーションプログラム（ショッピングアプリケーション）をはじめとするデータが記憶されている。このクレジットカードデバイス２をユーザ端末装置１にマウントしてショッピングアプリケーションを実行させることにより、ユーザは、このユーザ端末装置１に対する操作を行ったオンラインショップ４から所望の商品を選んで購入することができる。

なお、ユーザ端末装置１は、現実においては、多数がネットワーク６上に存在することになるが、ここでは、図示を簡単なものとすることの便宜などから、１つのみを示している。
また、クレジットカードデバイス２としての記憶媒体フォーマットは、現状であれば、ＵＳＢメモリなどといわれるリムーバブルメディアなどとすることが順当である。しかし、本願発明の下ではこのクレジットカードデバイス２の記憶媒体フォーマットについては特に限定されるべきではなく、例えばディスク状記録媒体、ＨＤＤその他の記憶媒体フォーマットを採用できる。

この図では、オンラインショップ４として、２つのオンラインショップ４−Ａ,４−Ｂの２つが示されている。オンラインショップ４としても、現実には多数がネットワーク６上に存在するが、図示を簡単なものとすることの便宜などから、ここでは２つのみを示している。
オンラインショップ４のそれぞれは、例えば自店が扱う商品を販売するためのＷｅｂサイトを提供するＷｅｂサーバ機能を有している。

レジサーバ３は、ここではクレジットカード会社５が運営するものとしている。なお、レジサーバ３の運営者としては、例えばクレジットカード会社と契約している外部金融機関などとされてもよい。
本実施形態の商品購入システムは、購入した商品の支払い方法として、クレジットカードによる支払いが可能とされている。レジサーバ３は、ユーザ端末装置１のユーザである購買者が、クレジットカード会社５との契約により自身が所持しているクレジットカードを利用して商品の購入を行う場合に、そのクレジットカードでの決済処理を実行する機能を有する。また、本実施形態の商品購入システムにおいては、購買者が購入（注文）した商品のオンラインショップ４への発注は、ユーザ端末装置１側から行うのではなく、レジサーバ３から行うものとなる。

ここで、上記した本実施形態の商品購入システムについて、購買者であるユーザの利用態様と、購買者による購買手続きなどに応じた各装置の動作の流れについて、概要的に説明しておく。

１．購買者であるユーザが、本実施形態の商品購入システムを利用して何らかの商品を購入したいと思ったとする。この場合、ユーザは、クレジットカードデバイス２をユーザ端末装置１に装填してマウントさせる。これにより、クレジットカードデバイス２に記憶されているショッピングアプリケーションが起動する。

２．例えばクレジットカード会社５と契約するオンラインショップ４は、各自で販売している商品の情報を提供するＷｅｂサイトを稼働させている。
ユーザ端末装置１においてクレジットカードアプリケーションが起動した状態では、ユーザは、クレジットカードアプリケーションのＧＵＩ(Graphical User Interface)に対する操作によって、任意のオンラインショップ４を検索してアクセスできる。そして、アクセスしたオンラインショップ４での商品検索、商品を買い物かごに入れる操作、買い物かごに入れた商品を注文する操作などを行うことができる。

３．ここで、ユーザが買いたいと思っている商品が買い物かごを全て入れることができたとする。そこで、ユーザは、クレジットカードアプリケーションに対して買い物かごにいれた商品を注文、購入する操作を行ったとする。なお、ここでは、商品の購入は、ユーザが所持しているクレジットカードで支払うことを前提とする。
この操作に応じては、ユーザ端末装置１のクレジットカードアプリケーションからレジサーバ３に対して、買い物かごに入っていた商品の内訳を示す内容を含む購入情報を送信する。
ここで、本実施形態としては、この購入情報の送信に際しては、クレジットカード番号をはじめ、ユーザの氏名、パスワードなど、個人情報の類を送信しない。そして、このように商品購入に際して個人情報をネットワーク上で送受信しなくとも、後述するようにして、ユーザは、適正に自身が注文した商品を購入できる。

４．購入情報を受信したレジサーバ３では、先ずしかるべき認証処理を実行する。この認証処理については後述する。そして、認証が成立したのであれば、この後のしかるべきタイミングで、受信した購入情報が示す注文された商品の内訳に従って、オンラインショップ４に対応した店舗に対して商品を発注する。この発注としては、発注する商品識別コード、商品ごとの個数、注文(購入)したユーザに商品を発送するのに必要なユーザ個人情報（ユーザの氏名、電話番号、住所(送付先)）などから成る発注情報を送信することになる。
また、レジサーバ３は、後述するようにして、購入情報を送信してきたユーザ端末装置１を使用しているユーザのクレジットカード番号を特定し、このクレジットカード番号を用いて決済を行う。決済金額は、購入情報の内容から知ることができる。

５．レジサーバ３は、上記の発注と決済を行うと共に、商品の注文、決済が行われたことを通知するメールを、ユーザ端末装置１のユーザのメールアドレス宛に送信する。このメールアドレスは、レジサーバ３がユーザ情報データベースに登録するユーザ情報に含まれている。

６．レジサーバ３からの発注を受けたオンラインショップ４対応の店舗では、発注された商品を集荷し、ユーザに発送する作業を行う。

＜２．ユーザ端末装置＞

図２は、ユーザ端末装置１の内部構成例を示している。なお、この場合には、ユーザ端末装置１としてのハードウェアは、パーソナルコンピュータであるものとしている。
先ずユーザ端末装置１は、ネットワーク６を経由しての通信を行うために、ネットワークインターフェース１４を備えている。このネットワークインターフェース１４が備えられることにより、ネットワーク経由での他のノードとの通信が可能になる。

ＣＰＵ(Central Processing Unit)１１は、例えばＨＤＤ（ハードディスクドライブ）１８にインストールされたＯＳ(Operating System)、及び各種のアプリケーションプログラム、また、ＲＯＭ１２に保持されているプログラムに従って各種の処理を実行可能とされる。
ＲＡＭ１３はＣＰＵ１１のための主記憶装置であり、ＣＰＵ１１が各種処理を実行するのに必要なデータやプログラム等が適宜保持される。

この場合の入出力インターフェース１５には、例えば、キーボードやマウスなどとされる入力デバイス１６が接続されており、この入力デバイス１６から出力されてくる操作信号を、ＣＰＵ１１が処理可能なデータに変換して、ＣＰＵ１１に対して出力するようにされている。

また、入出力インターフェース１５には、メディアドライブ１７が接続されている。このメディアドライブ１７は、各種所定フォーマットのリムーバブルメディアに対応してデータの記録再生が可能なように構成された各種のドライブを一括して示している。

また、入出力インターフェース１５には、データインターフェース１５Ａが接続されている。ここでのデータインターフェース１５は、各種所定のデータインターフェース規格に準拠した有線、もしくは無線によるデータ通信機能に対応したデバイス、ソフトウェアを一括して示したものである。

本実施形態においては、上記入出力インターフェース１５の１つとしてＵＳＢ(Universal Serial Bus)インターフェースを備えるものとする。また、本実施形態のクレジットカードデバイス２は、いわゆるＵＳＢメモリとしての形態を採るものとする。従って、クレジットカードデバイス２を使用する際には、入出力インターフェース１５としてのＵＳＢインターフェースにおけるジャック機構部に対してクレジットカードデバイス２のプラグ部分を差し込むようにする。これにより、例えば本実施形態では、プラグ・アンド・プレイ機能によって自動的にＵＳＢメモリがマウントされ、ここに記憶されているショッピングアプリケーションを起動させることができる。

また、入出力インターフェース１５には、記憶媒体としてハードディスクを備えたＨＤＤ１８が接続されている。ＣＰＵ１１は、入出力インターフェース１５を介して、ハードディスクドライブ１８のハードディスクに対してデータやプログラム等の記録又は読み出しを行うことができるようにされている。
また、入出力インターフェース１５には、画像表示のためのディスプレイモニタ１９も接続されている。ＣＰＵ１１は、入出力インターフェース１５経由で表示制御を行うことで、ディスプレイモニタ１９においてしかるべき画像を表示させる。

＜３．クレジットカードデバイス＞

上記したように、本実施形態のクレジットカードデバイス２は、ＵＳＢメモリの形態を採るものとしている。
図３は、このクレジットカードデバイス２の記憶領域内を示している。
図示するようにして、この場合のクレジットカードデバイス２の記憶領域には、通常のＲＡＭ領域とともにＲＯＭ領域が設けられる。
ＲＡＭ領域は、通常にユーザ操作などに応じてアクセスしてデータを書き換えることのできる記憶領域である。これに対してＲＯＭ領域は、通常のユーザ操作によってはデータ書き換えを行うことのできない記憶領域である。
なお、以降の説明から理解されるように、ＲＯＭ領域には、クレジットカードデバイス２においてクレジットカード会社５側から予め提供するデータが記憶される。RAM領域には、クレジットカードデバイス２を利用してのオンラインショッピングが行われているときに、例えばショッピングカートの情報などが一時的に保持される。

そして、クレジットカードデバイス２のＲＯＭ領域には、ショッピングアプリケーション２１、カード対応識別子２２、及び暗号キー２３が記憶される。これらをクレジットカードデバイス２に書き込んで記憶させる作業は、クレジットカード会社５側で全て行う。

ショッピングアプリケーション２１は、オンラインショッピングを可能とするための各種機能を有するようにして作成されたアプリケーションプログラムである。このショッピングアプリケーション２１としてのプログラムについての機能別構成例を、図４に示す。

図４に示すように、ショッピングアプリケーション２１は、店舗アクセス処理部２１ａ、レジサーバ対応通信処理部２１ｂ、ショッピング画面制御機能部２１ｃ、ショッピングカート管理部２１ｄ、操作入力処理部２１ｅから成る。

店舗アクセス処理部２１ａは、ネットワーク(インターネット)上に存在するオンラインショップ４の検索、オンラインショップ４との接続・通信に関連した処理を実行する。
レジサーバ対応通信処理部２１ｂは、レジサーバ３との通信のための処理を実行する。
ショッピング画面制御機能部２１ｃは、ショッピング画面を表示するための制御を実行する。ショッピング画面は、アクセスするオンラインショップ４の選択、アクセスしたオンラインショップ４が提供する商品の選択、お気に入りへの商品登録、ショッピングカート（買い物かご）への商品登録、購入（注文）などのためのユーザ操作を可能とするＧＵＩ(Graphical User Interface)機能を有した画像である。

ショッピングカート管理部２１ｄは、ショッピングカートについての管理を実行する。例えばショッピング画面上で商品をショッピングカートに入れる操作が行われたことに応じては、指定された商品がショッピングカートに入れられたものとして登録する処理を実行する。このショッピングカートの情報は、例えばユーザ端末装置１のＲＡＭ１３に保持させておくようにしてもよいが、本実施形態としては、クレジットカードデバイス２のＲＡＭ領域に保持させておくようにする。
本実施形態のクレジットカードデバイス２としてのＵＳＢメモリでは、起動されたショッピングアプリケーション２１によるデータの編集（書き換え）、保存などのデータ処理、ファイル操作などは、そのショッピングアプリケーション２１が記憶されているクレジットカードデバイス２の記憶領域のみを利用して行うようにして構成されている。このような仕組みのクレジットカードデバイス２を使用すれば、例えば、店舗などにおかれている公衆用のパーソナルコンピュータを利用しても、そのパーソナルコンピュータに購入用のデータが残ることが無い。なお、このようにして、例えばUSBメモリなどにおいて、そこに記憶されているアプリケーションが、データ処理を、同じUSBメモリの領域を利用して実行するようにされる技術については、これまでに知られているものを採用すればよく、ここでは特に限定されるべきものではない。
なお、ショッピングカートの情報については、必要があれば、ネットワーク経由でオンラインショップ４、レジサーバ３にも通知するようにしてよい。

操作入力処理部２１ｅは、ショッピング画面に対して行われたとする操作（入力デバイス１６としての操作子に対して行われた操作）に応じた信号を入出力インターフェース１５経由で入力して解釈し、コマンドを生成する。そして、このコマンドを、例えば、店舗アクセス処理部２１ａ、レジサーバ対応通信処理部２１ｂ、ショッピング画面制御機能部２１ｃ、ショッピングカート管理部２１ｄのうちのしかるべき部位に渡す。このコマンドを受けて、店舗アクセス処理部２１ａ、レジサーバ対応通信処理部２１ｂ、ショッピング画面制御機能部２１ｃ、ショッピングカート管理部２１ｄが所要の処理を実行する。これにより、ショッピングアプリケーション２１としてのユーザ操作に応じた動作が得られる。

また、クレジットカードデバイス２が記憶するカード対応識別子２２は、クレジットカード会社５が発行しているクレジットカードごとに固有となるようにして与えられる識別子である。つまり、カード対応識別子とクレジットカード会社５が発行しているクレジットカードとは、１対１による対応関係を有する。
クレジットカード会社５は、所定の規則に従って、特定の１つのクレジットカードに対応するカード対応識別子２２を生成させる。そして、このカード対応識別子２２をクレジットカードデバイス２としてのＵＳＢメモリに書き込んで記憶させる。ここで、本実施形態としては、１つのクレジットカードデバイス２に記憶させるべきカード対応識別子は１つとしている。

暗号キー２３は、ショッピングアプリケーション２１が利用するもので、購入情報とともに送信する認証データの暗号化に用いる暗号鍵のデータである。
暗号キー２３は、後述するようにして、クレジットカード会社５により、クレジットカードごとに固有となるものとして作成されたうえで、クレジットカードデバイス２に書き込まれて記憶される。
ここで、１つの暗号キー２３が対応するクレジットカードは、同じクレジットカードデバイス２において書き込まれて記憶されるカード対応識別子２２が対応するクレジットカードと一致する。そして、暗号キー２３も、カード対応識別子２２と同様に、１つのクレジットカードデバイス２には１つのみが記憶される。
つまり、本実施形態では、１つのクレジットカードデバイス２が、１つのクレジットカードに対応するものとなる。

＜４．レジサーバ＞

図５は、レジサーバ３の内部構成例を示している。
この図に示されるレジサーバ３は、制御部３１、記憶部３２、及びネットワークインターフェース３３を備えて成るものとしている。
制御部３１は、例えばＣＰＵ、及びＲＡＭなどの主記憶装置から成るサーバコンピュータである。この制御部３１におけるＣＰＵが、記憶部３２に記憶されるプログラム３８を実行することで、レジサーバ３としての機能が実現される。

ネットワークインターフェース３３は、ネットワーク６を経由しての他のノードとの通信を実現するために設けられる。

記憶部３２は大容量の副記憶装置であり、そのハードウェアとしてはＨＤＤなどを採用できる。
この場合において、記憶部３２には、カード対応識別子データベース３４、カード関連情報データベース３５、復号キーデータベース３６、店舗データベース３７、プログラム３８が記憶されている。
プログラム３８は、上記しているたように、レジサーバ３としての機能実現のためのプログラムであり、制御部３１のＣＰＵが実行する。

先に図３に示したようにクレジットカードデバイス２に記憶されるカード対応識別子２２は、クレジットカード会社５が発行しているクレジットカードと１対１となる対応関係を有する。
カード対応識別子データベース３４は、カード対応識別子とクレジットカードとの対応を示すデータベース情報であり、図６に示すように、例えばクレジットカードごとに固有に与えられる識別子であるカードＩＤごとに、カード対応識別子を対応付けた構造を有する。

カード関連情報データベース３５は、クレジットカードごとに関連した所定の属性項目から成るデータベース情報となる。
カード関連情報データベース３５は、例えば図７に示すように、カードＩＤに対して、契約者(ユーザ)の氏名、契約者の住所・送付先、メールアドレス、対応するクレジットカードの番号（クレジットカード番号）、対応するクレジットカードの有効期限、対応するクレジットカードの利用履歴、などの属性項目の情報が対応付けられた構造を有する。
なお、このカード関連情報データベース３５においてクレジットカード（カードＩＤ）ごとに対応付けられる属性情報の定義内容は、図７に示した内容に限定されるものではなく、実際に応じて、適宜追加・省略されてよい。

前述したように、ユーザ端末装置１（ショッピングアプリケーション２１）からレジサーバ３に対して購入情報を送信する際には、暗号キー２３により暗号化した形式の認証データも送信される。
レジサーバ３では、受信した認証データの暗号化を解く復号処理に際して復号キーを用いるが、この復号キーは、暗号キー２３ごとに異なるようにして固有に割り当てられるべきものとなる。
そして本実施形態では、暗号キー２３と復号キーとは１対１でペアとなる関係を有する（ペアキー）。つまり、公開鍵方式における公開鍵と個人鍵（秘密鍵）の関係と同様に、暗号キー２３により暗号化したデータは、この暗号キー２３とペアキーを成す他方のキーである復号キーでなければ復号できない。

ここで暗号キー２３は、前述のようにクレジットカードごとに異なる固有のものとして割り当てられるから、復号キーとしてもクレジットカードごとに異なるものとして固有に割り当てられるべきものであることになる。
記憶部３２における復号キーデータベース３６は、例えば図８に示すように、復号キーをカードＩＤに対応付けた構造を有して形成される。

また、記憶部３２における店舗データベース３７は、本実施形態の商品購入システムに参加するものとしてクレジットカード会社５と契約している店舗（ここではオンラインショップ４を運営する実店舗、販売業者の意味である）についての情報をデータベース化したものである。
例えば、図９に例示する店舗データベース３７は、店舗ＩＤと店舗情報とを対応付けた構造を有している。ここでの店舗情報は複数の所定の属性項目の情報から成る。店舗ＩＤは、例えば商品購入システム参加契約時などにおいてクレジットカード会社５がその店舗に割り当てるものである。また、属性項目としては、例えば店舗名、店舗所在地、クレジットカード会社５との連絡用のメールアドレスなどを挙げることができる。

＜５．クレジットカードデバイス作成手順＞

クレジットカードデバイス２は、クレジットカード会社５側にて、ＵＳＢメモリに図３に示した記憶内容を書き込んで仮想的にＲＯＭ化した状態とするようにして作成される。そして、このようにして作成したクレジットカードデバイス２を、例えば通常のクレジットカードなどと同様にして、郵送などにより、ユーザに配布する。

図１０のフローチャートは、上記のようにクレジットカード会社５側にて行う１個のクレジットカードデバイス２についての作成手順（データ書き込み手順）を示している。なお、この図に示す処理手順は、作業者が、情報処理装置（コンピュータ装置）に対する操作を行って、ステップごとに対応した作業を行うようにされてもよい。また、上記情報処理装置により自動実行するようにして構成することもできる。つまり、情報処理装置には、クレジットカードデバイス２をマウントした状態としておく。そのうえで、情報処理装置がプログラムに従って図１０のフローチャートとして示す処理を実行していくようにする。下記の説明では、情報処理装置が主体となって自動実行する場合を前提に説明する。
また、上記情報処理装置は、セキュリティが確保されているネットワーク範囲において、クレジットカード契約者についてのデータベース（カード契約者データベース）にアクセス可能な環境を有しているものとする。また、レジサーバ３にもアクセス可能な環境を有しているものとする。

図１０においてステップＳ１１では、マウントされたクレジットカードデバイス２に対してショッピングアプリケーションのデータを書き込む。
次のステップＳ１２において情報処理装置は、今回作成しているクレジットカードデバイス２が対応するクレジットカード（作成元クレジットカード）に対応するカード対応識別子を生成する。

カード対応識別子の生成処理としては、多様に考えられるが、例えば１つには、カード契約者データベースから作成元クレジットカードに対応したカード番号をはじめとする必要数の属性情報を読み出して取得し、これらの属性情報を利用した所定の不可逆方式の演算によって所定ビット数による数値を求めるようにすることが考えられる。このようにして求められた数値がカード対応識別子２２となる。
また、もう１つには、クレジットカード会社においてクレジットカードが登録された順番などに対応した数値を割り当てるようにすることが考えられる。このようなカード対応識別子の生成の仕方であれば、特に難しいカード対応識別子生成のための演算アルゴリズムを用意する必要が無く、また、カード対応識別子の管理も簡易化可能となる。

ステップＳ１３において情報処理装置は、クレジットカードデバイス２に対して、上記ステップＳ１２により生成したカード対応識別子２２を書き込む。
また、これとともにステップＳ１４として、ステップＳ１２により生成したカード対応識別子２２を、レジサーバ３のカード対応識別子データベース３４に登録する処理を実行する。
この際には、先ず、所定規則に従って、作成元クレジットカードに固有となるカードＩＤを生成する。そのうえで、この生成したカードＩＤとカード対応識別子とをレジサーバ３に渡して、カード対応識別子データベース３４への登録を指示する。この指示に応じて、レジサーバ３では、カード対応識別子データベース３４に対して、受け取ったカードＩＤとカード対応識別子とを対応付けて新規登録する。

次に情報処理装置は、ステップＳ１５により、作成元クレジットカードに固有となる暗号キー２３と復号キーのペア（ペアキー）を生成する。
この鍵の生成に際しては、例えば公開鍵暗号方式において個人鍵と公開鍵を生成するアルゴリズムを適用できる。

次に情報処理装置は、ステップＳ１６において、ステップＳ１５にて生成された暗号キー２３・復号キーのうち、暗号キー２３をクレジットカードデバイス２に書き込む。この処理までが実行される結果、図３に示したように、クレジットカードデバイス２の記憶領域においてショッピングアプリケーション２１、カード対応識別子２２、及び暗号キー２３のデータがそろって書き込まれたことになる。

また、ステップＳ１７によっては、ステップＳ１５にて生成された復号キーをレジサーバ３に保存させるための処理を実行する。
この処理に際しては、情報処理装置がレジサーバ３に対して復号キーを渡して保存を指示する。この指示に応答してレジサーバ３は、渡された復号キーを、先のステップＳ１４に対応して受け取ったカードＩＤと対応付け、復号キーデータベース３６に新規登録する。これにより、復号キーが、作成元クレジットカードと対応付けられた状態でレジサーバ３にて保存されたことになる。

上記したように、ステップＳ１６の処理が終了した段階により、クレジットカードデバイス２においてはＲＯＭ領域に記憶させるべきデータが書き込まれている状態にある。そこで、ステップＳ１８においては、ショッピングアプリケーション２１、カード対応識別子２２、及び暗号キー２３のデータが書き込まれた領域をＲＯＭ領域として設定するための処理を実行する。
これにより、或る１つのクレジットカードに対応したクレジットカードデバイス２が作成されたことになる。
そして、クレジットカード会社５は、先にも述べたように、このクレジットカードデバイス２を、対応する作成元クレジットカードの所有者（ユーザ）に対して発送などして受け渡すようにする。

＜６．ユーザ端末装置、レジサーバのアルゴリズム例＞
［６−１．ユーザ端末装置］

クレジットカード会社５からクレジットカードデバイス２を受け取ったユーザは、先にも述べたように、ユーザ端末装置１にクレジットカードデバイス２をマウントしてショッピングアプリケーション２１を起動させた環境とすることで、オンラインショップ４が提供する商品を購入する、オンラインショッピングを行える。
なお、ショッピングアプリケーション２１を起動させる際には、クレジットカードデバイス２のマウントが認識されたことに応じて、そのままユーザが操作可能な状態にまで自動的に起動させてもよいのであるが、セキュリティの観点からすれば、例えばパスワード入力による認証処理を介在させた上で起動されるようにすることが好ましい。
つまり、クレジットカードデバイス２のマウントが認識された後には、先ず、ショッピングアプリケーション２１としては、パスワード入力のためのプログラムを起動させる。これにより、例えばユーザ端末装置１のディスプレイモニタ１９にはパスワードの入力ボックスが表示される。そこで、ユーザは、この入力ボックスにパスワードを入力して認証処理を実行させる。パスワードが正しければ、以降においてユーザが操作可能な状態にまでショッピングアプリケーション２１が起動を完了するが、パスワードが間違っていればショッピングアプリケーション２１は自動的に終了する。
なお、このショッピングアプリケーション２１の起動のためのパスワードとしては、例えばクレジットカード会社５に対してユーザが登録したパスワードを使用することが考えられる。この場合には、図１０のステップＳ１１によるショッピングアプリケーション２１の書き込み時において、ユーザが登録したパスワードも書き込むようにすればよい。
もしくは、クレジットカードデバイス２がユーザに渡された後において、ショッピングアプリケーション２１に対する所定操作により、ユーザが設定できるようにすることが考えられる。この場合には、ショッピングアプリケーション２１は、例えば自身が記憶されているのと同じＲＯＭ領域に対して、設定されたパスワードを書き込む処理を行うようにする。この場合のＲＯＭ領域は、物理的に書き込みが不可に設定されるのではなく、論理的に外部からの通常のアクセスによっては書き込みができないようにされている。従って、ショッピングアプリケーション２１に対する適正な操作によってであれば、ショッピングアプリケーション２１の処理として、このパスワードのような予め許可されたデータについてはＲＯＭ領域に対する書き込み、書き換えを行うことができる。ただし、このようして書き込まれたデータを、通常にアクセスして読み出したり、書き換えたりすることはできない。

図１１のフローチャートは、上記のようにして起動されたショッピングアプリケーション２１のプログラムに従ってユーザ端末装置１が実行する処理手順（アルゴリズム）例を示している。
ステップＳ１０１においてユーザ端末装置１は、ショッピングアプリケーション２１のＧＵＩに対するオンラインショップ４の検索のための操作が行われたことに応じて、この操作を入力する。そして、ステップＳ１０２により検索されたオンラインショップ４の商品を提示するショッピング画面を生成し、これを画像として表示するための制御を実行する。

ユーザは、つまり、上記ステップＳ１０２により表示されたショッピング画面に対する操作として、商品を探すための操作（商品検索操作）を行う。ユーザ端末装置１は、ステップＳ１０３によりこの操作を入力して、ステップＳ１０４としての処理により、検索された商品を提示したショッピング画面を生成し、これを画像として表示させるための制御を実行する。

例えばユーザは、検索して提示された商品が気に入れば、これをショッピングカート（買い物かご）に入れる操作を行うことができる。ユーザ端末装置１は、ステップＳ１０５によりこの商品をショッピングカート（買い物かご）に入れる操作を受け付け、ステップＳ１０６により、ショッピングカートに入っている商品についての情報から成るショッピングカート購入情報を生成し登録保持する。また、既にショッピングカート情報が登録保持されているのであれば、今回の操作に応じてショッピングカートに入れるべき商品についての情報を新たに追加してショッピングカート情報を更新する。

なお、現状における一般的な態様として、ショッピングカートは、オンラインショップごとのウェブサイト上で個々に独立して設けられる。これに対して、本実施形態においては、クレジットカード会社５と契約しているオンラインショップ４の商品であれば、まとめてショッピングカートに入れることができる。本実施形態の場合、ショッピングカートとしてのＧＵＩ画像を表示は、ユーザ端末装置１が上記のようにして生成して保持するショッピングカート情報に基づいて行われるものとする。

なお、ここではフローチャートにより処理を示していることの都合上、上記ステップＳ１０１、Ｓ１０２によるオンラインショップ４の検索操作に応じたＧＵＩ処理、上記ステップＳ１０３、Ｓ１０４による商品検索操作に応じたＧＵＩ処理、及びステップＳ１０５、Ｓ１０６に応じたショッピングカートに入れる操作に応じたＧＵＩ処理を、順序立てて示している。しかし、実際のプログラム構成としては、適宜、操作などに応じて、これらのＧＵＩ処理の間での移行が可能なようにされている。

ここでユーザが、上記ステップＳ１０１、Ｓ１０２に対応するオンラインショップ４の検索、ステップＳ１０３、Ｓ１０４による商品検索、及びステップＳ１０５、Ｓ１０６に応じたショッピングカートに入れる操作を適宜行ったうえで、そのときにショッピングカートに入っている商品を購入しようと決めたとする。このときユーザは、例えばショッピングアプリケーションのＧＵＩ画面に対して購入決定のための操作を行う。ステップＳ１０７は、ユーザ端末装置１がこの購入決定操作を受け付ける処理となる。

ユーザ端末装置１は、ステップＳ１０７により上記のように購入決定操作を受け付けたことに応じて、ステップＳ１０８以降の処理を実行する。
ステップＳ１０８においてユーザ端末装置１は購入情報と認証情報を生成する。

ステップＳ１０８により生成される購入情報の内容例を図１２に模式的に示す。
この図に示されるように、購入情報は、Ｍ個の店舗単位購入情報１〜Ｍ、及びカード対応識別子２２から成る。
店舗単位購入情報１〜Ｍのそれぞれは、購入決定操作時においてショッピングカートに入れられていた商品の情報をオンラインショップ４ごとの括りでまとめるようにして形成される。
また、購入情報におけるカード対応識別子２２は、ショッピングアプリケーションが起動されたクレジットカードデバイス２のＲＯＭ領域において記憶されていたものと同じ値を有する。
つまり、ユーザ端末装置１（ショッピングアプリケーション）は、ステップＳ１０８により購入情報を生成する際において、クレジットカードデバイス２のＲＯＭ領域からカード対応識別子２２のデータを読み出して、購入情報のデータ構造における所定の位置に格納する。

上記店舗単位購入情報１〜Ｍごとについて、ここでは、店舗ＩＤ、単位商品情報１〜Ｎ、及び送料、合計金額から成るものとしている。
先ず、店舗ＩＤには、現店舗単位購入情報が対応する１つのオンラインショップ４に対応した店舗ＩＤの値が格納される。店舗ＩＤは、図９にて説明したようにクレジットカード会社５と契約している店舗（オンラインショップ４）ごとに固有となるように、クレジットカード会社５が割り当てた識別子であり、この店舗ＩＤは、各オンラインショップ４に通知される。ショップ単位購入情報において記述される店舗ＩＤは、例えば同じショップ単位購入情報において単位商品情報として記述される商品をショッピングカートに入れた際において、その商品を提供販売するオンラインショップ４からユーザ端末装置１に通知されたものを利用している。

単位商品情報１〜Ｎのそれぞれは、購入決定操作時においてショッピングカートに入っていた商品のうち、現店舗単位購入情報における店舗ＩＤが示すオンラインショップ４にて提供・販売していた各１つの商品についての所定の情報から成る。ここでは、１つの単位商品情報は、対応する商品についての商品識別子、対応する商品の購入個数、対応する商品についての購入個数分の金額（商品金額＝単価×購入個数）などとされている。

送料には、単位商品情報１〜Ｎにより示される全商品を配達する際において必要になる送料の額が示される。

また、合計金額には、単位商品情報１〜Ｍごとの商品金額と送料とを合計した金額が示される。つまり、今回の購入決定操作に対応して、現店舗単位購入情報が対応するオンラインショップ４に対してユーザが支払うべき総額が示される。

なお、本実施形態では、上記単位商品情報、送料、合計金額の各情報は、ステップＳ１０４に応じたショッピングカートに商品を入れる操作に応じて、ステップＳ１０５により、ショッピングカート情報として生成するものとする。購入情報生成時には、ショッピングカート情報における単位商品情報、送料、合計金額を利用する。
なお、購入情報の内容としては、上記図１２に示したものに限定されるべきではなく、例えば実際の運用などに対応して適宜変更されてよい。

また、ステップＳ１０８においては、上記購入情報とともに認証情報も生成するが、ユーザ端末装置１（ショッピングアプリケーション２１）による認証情報の生成については、認証関連処理として後述する。

ステップＳ１０９においてユーザ端末装置１はレジサーバ３に対してアクセスする。ショッピングアプリケーション２１は、予めレジサーバ３のアドレス（ＵＲＬ）のデータを保持しており、このアドレスを指定してアクセス制御を行う。
そして、上記のアクセス処理によってユーザ端末装置１とレジサーバ３との間での接続が確立されたとすると、ユーザ端末装置１は、ステップＳ１１０により、先のステップＳ１０８にて生成した購入情報と認証情報を、レジサーバ３に対して送信する。

［６−２．レジサーバ］

図１３のフローチャートは、レジサーバ３が、上記図１１のステップＳ１１０によりユーザ端末装置１から送信されてくる購入情報及び認証情報の受信に応答して実行する商品発注、決済までの処理手順例を示している。なお、この図に示す処理は、レジサーバ３における制御部３１を形成するＣＰＵが、記憶部３２に記憶されているプログラム３８を実行することによって実現されるものとしてみることができる。なお、このようなプログラムは、リムーバブルの記憶媒体に記憶させて保存しておくことが可能であり、このようなリムーバブルの記憶媒体からレジサーバ３にインストールするようにして、記憶部３２などとしての記憶装置に記憶させることができる。

ここでは、ステップＳ２０１により、レジサーバ３が、図１１のステップＳ１１０により送信された購入情報及び認証情報を受信して取得するものとしている。

次にレジサーバ３は、ステップＳ２０２の処理として、上記ステップＳ２０１により取得した購入情報において格納されるカード対応識別子を抽出する。

次のステップＳ２０３においては、上記ステップＳ２０１により取得した購入情報、認証情報、及び上記ステップＳ２０２により抽出したカード対応識別子を利用して、認証処理を実行する。この認証処理についてのより詳細な手順については後述するが、認証処理によって認証が成立した場合には、今回のステップＳ２０１にて受信した購入情報の送信者が正しいユーザであり、例えばなりすましなどによる間違ったユーザではないこと、送信された購入情報の内容に改ざんがないことが証明され、否認防止が図られる。また、認証が不成立の場合には、なりすましと情報改ざんの少なくともいずれかが行われたことを意味するものとなる。

ステップＳ２０４においては、上記ステップＳ２０２による認証処理結果として、認証が成立したか否かについての判別を行う。
ステップＳ２０４において認証は不成立であるとして否定の判別結果が得られた場合には、ステップＳ２１６に進んで、今回ステップＳ２０１により受信した購入情報・認証情報の送信元のユーザ端末装置１に対して、購入不可の通知を行う。

これに対してステップＳ２０４において認証が成立したとして肯定の判別結果が得られたのであれば、ステップＳ２０５以降の手順に進む。
先ず、レジサーバ３は、ステップＳ２０５により、先のステップＳ２０２にて抽出したカード対応識別子と、記憶部３２に記憶されているカード対応識別子データベース３４とを照合し、続くステップＳ２０６により、照合結果として、照合したカード対応識別子に対応付けられているカードＩＤを、カード対応識別子データベース３４から検索する。

次にレジサーバ３は、ステップＳ２０７により、上記ステップＳ２０６にて検索したカードＩＤと対応付けられている属性項目の情報をカード関連情報データベースから取得する。

次のステップＳ２０８においてレジサーバ３は、上記ステップＳ２０７にて取得した属性項目における所定の情報と、予め定めた購入可能ユーザとしての資格を満たす条件とを照合し、今回購入情報を送信してきたユーザ（クレジットカード契約者）が購入可能ユーザであるか否かについて判別する。購入可能ユーザの条件としては、例えば、現日時においてクレジットカードの有効期限を経過していないこと、利用履歴情報が示すこれまでの利用履歴から、例えば今回の購入情報から求められる支払総額を合算した借入金額がクレジット限度額を超えていないこと、利用停止の条件を満たすような支払いの延滞がないこと、などとなる。
ステップＳ２０８において購入可能ユーザではないとして否定の判別結果が得られた場合には、ステップＳ２１６により、購入情報・認証情報の送信元のユーザ端末装置１に対して購入不可通知を行う。
これに対してステップＳ２０８において購入可能ユーザであるとの判定結果が得られ、肯定の判別結果となった場合には、ステップＳ２０９以降の発注、決済のための処理に進む。

ステップＳ２０９においては、今回のステップＳ２０１にて受信取得した購入情報における店舗単位購入情報に付した番号を示す変数ｍについて初期値として１を代入する。従って、変数ｍとしては、自然数であり、かつ、その最大値は購入情報における店舗単位購入情報の数Ｍとなる。

ここで、これまでの説明から理解されるように、本実施形態においては、これまでであればオンラインショップ４ごとに対して送信されるべき商品の注文、支払いに関する情報が、商品の注文が行われたオンラインショップ４をまとめたかたちで購入情報として、一括に、レジサーバ３に対して送信されるようになっている。
このために、先ず、レジサーバ３としては、ユーザが購入・注文した商品を提供するオンラインショップ４ごとに対して、商品を発注する必要がある。ステップＳ２１０〜Ｓ２１３の処理は、このための処理となる。

ステップＳ２１０においてレジサーバ３は、今回のステップＳ２０１にて受信取得した購入情報から、店舗単位購入情報ｍを抽出する。
次にレジサーバ３は、ステップＳ２１１により、店舗単位購入情報ｍにおいて格納される店舗ＩＤに対応するオンラインショップ４に向けての発注処理を行う。
つまり、店舗単位購入情報ｍにおいて格納される店舗ＩＤに対応する店舗（オンラインショップ４）に向けての商品発注情報を生成する。この商品発注情報においては、発注する商品を示す情報（商品識別情報）、商品ごとの注文個数を示す情報、これらの注文された商品についての金額の内訳の情報、注文したユーザに対応した送り先（住所）の情報などとなる。これらの情報のうち、例えば、商品識別情報、その個数を示す情報、これらの注文された商品についての金額の内訳の情報は、店舗単位購入情報ｍの記述内容から生成できる。また、送り先（住所）の情報などは、ステップＳ２０７によりカード関連情報データベースから取得した情報から得ることができる。
そして、このようにして生成した商品発注情報を、店舗単位購入情報ｍに対応する店舗に対して、しかるべき手段で送信する。このときの送信は、ネットワーク経由でもよいが、その際には、何らかの方式によるプライベートネットワークとするなど、安全とされるネットワーク通信の方式、技術を採用することが好ましい。

ステップＳ２１２においては、現在の変数ｍについて最大値Ｍ以上であるか否かについて判別する。ここで変数ｍが最大値Ｍ未満であるとして否定の判別結果が得られた場合には、未だ、発注処理を完了していない店舗が残っていることになる。そこでこの場合には、ステップＳ２１３により変数ｍをインクリメントしてステップＳ２１０に戻る。
これに対して、変数ｍが最大値Ｍ以上になったとしてステップＳ２１２において肯定の判別結果が得られた場合には、全ての店舗についての発注処理が完了したことになる。そこで、この場合にはステップＳ２１４、Ｓ２１５の処理を実行する。

ステップＳ２１４においては、決済処理を実行する。ここでの決済処理は、先ず、今回の購入情報の送信を行ったとするクレジットカード契約者（ユーザ）に対するクレジットカードによる支払いのための請求に関する処理を行う。支払金額は、購入情報から求めることができる。
また、先にも述べたように、本実施形態では、ユーザが購入・注文した商品についての情報は、購入情報として、複数のオンラインショップ４でまとめたかたちでレジサーバ３に対して送信されてくる。
そこでステップＳ２１４の決済処理として、今回の購入情報により商品が注文された店舗（オンラインショップ４）ごとに対する、支払いのための処理も実行する。この支払金額も購入情報における店舗単位購入情報から求めることができる。

そして、ここまでの処理が完了したとされるとステップＳ２１５により決済通知メールを作成し、例えば今回の商品購入・注文をしたとされるユーザのメールアドレスに対して送信する。このメールアドレスは、例えば図７に示すようにしてカード関連情報データベース３５において格納されている。

また、図１３には示していないが、上記のようにして１回の購入情報、認証情報についての処理が完了した段階で、レジサーバ３としては、今回の決済に使用したとするクレジットカードに対応するカード対応識別子として、今回使用したものとは別の値のものを生成する。つまりカード対応識別子の更新・再生成を行う。そして、カード対応識別子データベース３４、カード関連情報データベース３５、復号キーデータベース３６における今回使用したカード対応識別子を、更新したカード対応識別子に書き換える。
また、更新したカード対応識別子を、購入情報・認証情報の送信元のユーザ端末装置１（ショッピングアプリケーション２１）に送信して、書き換えを指示する。この指示に応答して、ユーザ端末装置１のショッピングアプリケーション２１は、クレジットカードデバイス２において記憶されているカード対応識別子２２について、受信したカード対応識別子の値に書き換える。これにより、カード対応識別子としては、一回の購入情報・認証情報の送受信（セッション）ごとに変更されることになり、セキュリティの強化が図られる。

［６−３．認証処理］

続いては、本実施形態のユーザ端末装置１とレジサーバ３との間で行われる認証の手続きに関連した処理（認証関連処理）について図１４を参照して説明する。図１４においては、ユーザ端末装置１とレジサーバ３とが示されている。この図は、図１１のステップＳ１０８における認証情報の生成、ステップＳ１１０における認証情報の送信、また、図１３におけるステップＳ２０１における認証情報及び購入情報の受信と、ステップＳ２０２によるカード対応識別子の抽出、及びステップＳ２０３による認証処理に対応した処理を模式的に示している。また、この図においても、ユーザ端末装置１（ショッピングアプリケーション２１）、レジサーバ３が実行する処理についてはステップ番号を付している。以降の説明は、このステップ番号に従って行う。

図１４において、先ずユーザ端末装置１（ショッピングアプリケーション２１）は、ステップＳ３０１としての処理により、生成した購入情報１００についてハッシュ演算を行ってハッシュ値１０１を求める。なお、ここでのハッシュ演算は、一方向ハッシュ関数を利用して行う。
次にユーザ端末装置１（ショッピングアプリケーション２１）は、クレジットカードデバイス２のＲＯＭ領域に記憶されている暗号キー２３を利用して、ステップＳ３０２として示すように、ハッシュ値１０１について暗号化を行う。この暗号化されたハッシュ値１０１が認証情報１０２となる。

そして、ユーザ端末装置１は、購入情報１００と認証情報１０２とを送信データ１０３として送信する。この送信データがレジサーバ３にて受信取得されることになる。
なお、本実施形態においては、認証情報１０２については暗号化された形式としているが、購入情報１００については暗号化せずに平文のまま送信していることに留意されたい。これは、購入情報には、購入した商品と店舗に関する情報のみであって、商品を購入、注文したユーザの名前、住所、クレジットカードに関する情報などの個人情報として扱われる情報は一切含まれていないことによる。つまり、例えばネットワーク上で盗まれたとしても特に問題になる情報ではなく、暗号化を施すことの必要性はないといえる。このことに基づいて、本実施形態では購入情報については平文のまま送信している。
もちろん、購入情報について何らかの方式により暗号化を施すことも可能であるが、例えば暗号化を施さないことでそれだけ処理を軽くできる。

レジサーバ３では、送信データ１０３について、図示するようにして購入情報１００と認証情報１０２に分離する。そして、購入情報については、ステップＳ３０４により、ステップＳ３０１と同じハッシュ関数による一方向ハッシュ演算を行ってハッシュ値１１０を得る。
また、レジサーバ３は、ステップＳ３０５により、購入情報１００からカード対応識別子２７を抽出する。次に、ステップＳ３０６により、復号キーデータベース３６から、抽出したカード対応識別子２７と対応付けられている復号キー１１１を読み出して取得する。
上記のようにして取得された復号キー１１１は、ユーザ端末装置１側にてステップＳ３０２の暗号化処理で利用した暗号キー２３とペアとなるものとして生成されたものである。

次にレジサーバ３は、ステップＳ３０７により、送信データ１０３から分離した認証情報（暗号化されたハッシュ値１０１）について、復号キー１１１を利用して復号処理を実行して、ハッシュ値１０１を復元する。

ここまでの手順により、レジサーバ３においては、購入情報１００をハッシュ演算して求めたハッシュ値１１０と、認証情報１０２を復号キー１１１により復号して得たハッシュ値１０１とを有している。
そこで、レジサーバ３においては、ステップＳ３０８により、上記２つのハッシュ値１１０とハッシュ値１０１とを比較する処理を実行する。

上記ステップＳ３０８において２つのハッシュ値が一致していたとする。
ここで、レジサーバ３がステップＳ３０４により送信データ１０３から分離した購入情報をハッシュ演算して求められるハッシュ値１１０と、ユーザ端末装置１側でステップＳ３０１のハッシュ演算により求められるハッシュ値１０１は、本来は、一致しているはずである。また、ユーザ端末装置１側でステップＳ３０１のハッシュ演算により求められたハッシュ値１０１は、認証情報１０２としてレジサーバ３側に送信されるので、復号キー１１１により復号してレジサーバ３側にて得られるハッシュ値１０１も、ハッシュ値１１０と一致しているべきことになる。
従って、ステップＳ３０８の比較処理の結果、ハッシュ値１０１とハッシュ値１１０とが一致していれば、送受信された購入情報には改ざんがなかったと判定できる。

また、ユーザ端末装置１側でのステップＳ３０２による暗号化処理に用いる暗号キー２３は、複合キー１１１とペアとなるものとして、１枚のクレジットカードに固有となるものとしてクレジットカード会社５にて作成されたものであり、クレジットカードデバイス２に記憶された状態で、そのクレジットカードの所有者に送られる。
つまり、暗号キー２３はクレジットカードデバイス２ごとに異なるものであり、１つの暗号キー２３は、対応するクレジットカードの所有者であるユーザしか所有し得ない、ということになる。
従って、レジサーバ３側にてカード対応識別子２７に対応する復号キー１１１により認証情報１０２を復号できたということは、即ち、今回送信されてきた購入情報は、復号キー１１１に対応するカード対応識別子が示すクレジットカードの所有者が、そのクレジットカードに対応するクレジットカードデバイス２を利用して送信してきたものであると判定できることになる。また、暗号キー２３の所有者は、ハッシュ値１０１を復号できた復号キー１１１に対応するクレジットカードの所有者の１名に限定されるのであるから、ユーザによる否認も防止できることになる。

これまでの説明から理解されるように、本実施形態においては、クレジットカードデバイス２を所有するユーザがユーザ端末装置１を使用してオンラインショッピングを行うのにあたり、商品の購入、注文を通知する情報のやりとりは、ユーザ端末装置１とオンラインショップ４との間では一切行われることが無い。本実施形態では、商品の購入、注文を通知する情報は、購入情報として、ユーザ端末装置１とレジサーバ３との間のみにおいて送受信される。また、先にも述べたように、購入情報には、商品を購入・注文するユーザの個人情報は含まれない。ちなみに、購入情報において格納されるカード対応識別子は、１つのクレジットカードと一義的に対応するものではある。しかし、カード対応識別子とクレジットカードとの対応を示す情報は、レジサーバ３においてのみ存在するのであるから、ネットワーク上を流れる過程においては、例えば所定ビット数により数値を羅列したものでしかなく、レジサーバ３以外のところで第三者が、カード対応識別子から、これに対応するクレジットカードを特定することは不可能である。

このようにして本実施形態においては、オンラインショッピングにあたって、商品を購入・注文するユーザの個人情報がネットワーク上で伝達されることがない。情報がネットワーク上で伝達されなければ、その情報をネットワーク上で盗聴することはそもそも不可能であるから、本実施形態では、オンラインショッピングのための通信に際しての個人情報の漏洩は万全に防がれることになる。
そのうえで、本実施形態では、図１４により説明した認証処理を行うこととしている。これにより、先に記載したように、購入情報の改ざん及びなりすましについての判定、否認防止が図られ、より万全なセキュリティを得ているものである。

また、例えばこれまでのインターネットセキュリティ技術を有効に用いてセキュリティを強化しても、ネットワーク上において個人情報が流れるということについては、特にインターネットセキュリティ技術を熟知していないような一般のユーザにとっては不信感が残ることになる。しかし、本実施形態のようにして、オンラインショッピングに際して個人情報がネットワーク上に一切流れない仕組みとすれば、上記のようなユーザの不信感も完全に取り除くことができる。

なお、これまでの実施形態の説明では、ユーザ操作に応じてオンラインショッピングを実現するためのプログラム、即ちショッピングアプリケーション２１は、クレジットカードデバイス２に記憶されて、クレジットカードデバイス２がマウントされたときに応じて起動されるものとしている。しかし、これは一例であって、例えばユーザ端末装置１に対してインストールするようにしてＨＤＤ１８に記憶させて、これを起動させるような態様としてもよい。

本実施形態に対応する商品購入システムの構成例を示す図である。 ユーザ端末装置の構成例を示す図である。 クレジットカードデバイス２の記憶内容例を示す図である。 ショッピングアプリケーション２１としての機能別構成例を示す図である。 レジサーバの内部構成例を示す図である。 カード対応識別子データベースの構造例を示す図である。 カード関連情報データベースの構造例を示す図である。 復号キーデータベースの構造例を示す図である。 店舗データベースの構造例を示す図である。 クレジットカードデバイス作成のための手順例を示すフローチャートである。 ユーザ端末装置が実行する処理手順例を示すフローチャートである。 購入情報の構造例を示す図である。 レジサーバが実行する処理手順例を示すフローチャートである。 認証処理の手順例を示す図である。

符号の説明

１ ユーザ端末装置、２ クレジットカードデバイス、３ レジサーバ、４（４−Ａ，４−Ｂ） オンラインショップ、５ クレジットカード会社、２１ ショッピングアプリケーション、２２ カード対応識別子、２３ 暗号キー、３４ カード対応識別子データベース、３５ カード関連情報データベース、３６ 復号キーデータベース、３７ 店舗データベース

Claims (1)

1. ユーザが所有するクレジットカード対応記憶媒体と、ユーザ端末装置と、クレジットカード会社のサーバ装置とから成り、
   上記クレジットカード対応記憶媒体には、１のクレジットカードに対応する識別子であるクレジットカード対応識別子と、クレジットカード会社側にてペアキーとして生成した２つのキーの一方である暗号キーとが記憶され、
   上記ユーザ端末装置は、
   ネットワーク経由での通信を実現するための端末側通信手段と、
   上記クレジットカード対応記憶媒体をマウントするマウント手段と、
   ユーザの操作に応じて、ネットワーク上に存在する１以上のオンラインショップにアクセスして商品を検索し、検索した商品を仮想ショッピングカートに入れる処理を実行するもので、仮想ショッピングカートに入れた商品についての情報はローカルにて生成して保持する、店舗検索／商品検索／ショッピングカート管理手段と、
   商品の購入決定操作に応じては、上記仮想ショッピングカートに入っているとされる商品についての情報に基づいて、購入決定された商品に関連する情報と、マウントされたクレジットカード対応記憶媒体から読み出して取得したクレジットカード対応識別子とを少なくとも有する、購入情報を生成する購入情報生成手段と、
   所定の一方向ハッシュ関数を用いた演算により上記購入情報についてのハッシュ値を求める端末側ハッシュ演算手段と、
   上記ハッシュ値を、マウントされたクレジットカード対応記憶媒体から読み出して取得した上記暗号キーにより暗号化して認証情報を生成する認証情報生成手段と、
   平文の上記購入情報と、上記認証情報と、を上記サーバ装置に対してネットワーク経由で送信する送信手段とを備え、
   上記サーバ装置は、
   ネットワーク経由での通信を実現するための通信手段と、
   上記ユーザ端末装置から送信されてきた上記購入情報と上記認証情報とを受信して取得する受信取得手段と、
   取得した上記購入情報について、上記端末側ハッシュ演算手段と同じ一方向ハッシュ関数によりハッシュ値を求めるサーバ側ハッシュ演算手段と、
   上記ペアキーとして生成した２つのキーの他方を復号キーとして、１のクレジットカード対応識別子と対応付けて記憶管理する復号キー管理手段と、
   上記購入情報から取得したクレジットカード対応識別子に対応付けられている復号キーを検索する検索手段と、
   検索された復号キーにより、取得した上記認証情報について復号処理を行ってハッシュ値を復元する復元手段と、
   上記サーバ側ハッシュ演算手段により求めたハッシュ値と、上記復元手段により得られたハッシュ値とを比較した結果に基づいて認証成立の可否についての結果を出力する認証手段と、
   クレジットカード対応識別子に対応するクレジットカードごとに関連した必要な情報であり、そのクレジットカードの契約者についての個人情報を含むクレジットカード関連情報を記憶管理するクレジットカード関連情報管理手段と、
   上記認証手段により認証成立の結果が出力された場合において、取得した上記購入情報と、この購入情報から取得したクレジットカード対応識別子に対応するクレジットカード関連情報とを利用してユーザについての決済処理を行う決済手段とを備える、
   商品購入システム。

Images