(57)【要約】      （修正有）【課題】携帯端末を利用したクレジット決済において顧客情報のセキュリティ確保する決済処理システムを提供する。【解決手段】カードリーダと、これとは別体の携帯端末とからなる決済処理システムであって、カードリーダは、クレジットカードから記録決済情報を読み取るための手段と、読み取った記録決済情報のうち決済必要情報を残さないでこれを暗号化決済情報とする手段と、暗号化決済情報を残さないで携帯端末に暗号化決済情報を送信する手段とを有し、携帯端末は、暗号化決済情報を受信する手段と、商品情報を取得するための手段と、取得した商品情報と受信した暗号化決済情報とを関連付けて記憶する手段と、現在送信すべき暗号化決済情報と関連付けられた商品情報に関連付けて暗号化決済情報の送信命令を受け付ける手段と、受付けた送信命令に応じて決済処理サーバに対して暗号化決済情報を送信するための手段とを有する決済処理システム。【選択図】図１
2012252665.tif 000002
【特許請求の範囲】
【請求項１】
クレジットカードなどから決済のための情報である決済情報を読み取るカードリーダと、
カードリーダとは別体で、カードリーダから決済情報を受信し、その決済情報のなかで決済処理に必要な情報である決済必要情報を決済処理のためのサーバである決済処理サーバに送信する携帯端末と、
からなる決済処理システムであって、
カードリーダは、
クレジットカードから決済情報である記録決済情報を読み取るための第一決済情報読取部と、
読み取った記録決済情報のうち決済必要情報を残さないでこれを暗号化決済情報とする第一暗号化部と、
暗号化決済情報を残さないで携帯端末に暗号化決済情報を送信する対携帯端末送信部と、
を有し、
携帯端末は、
暗号化決済情報を受信する受信部と、
商品情報を取得するための商品情報取得部と、
取得した商品情報と、受信した暗号化決済情報とを関連付けて記憶する記憶部と、
現在送信すべき暗号化決済情報と関連付けられた商品情報に関連付けて暗号化決済情報の送信命令を受け付ける送信命令受付部と、
受付けた送信命令に応じて決済処理サーバに対して暗号化決済情報を送信するための送信部と、
を有する決済処理システム。
【請求項２】
商品情報取得部は、一次元コードまたは二次元コードである商品情報を読み取るための商品情報読取手段を有する請求項１に記載の決済処理システム。
【請求項３】
携帯端末は、
送信が成功した暗号化決済情報を送信成功後ただちに記憶部から消去する消去部と、
送信部から送信された暗号化決済情報の送信日付をその暗号化決済情報に関連付けて記憶部に記憶されている商品情報に関連付けて記録する送信日付記録部と、
を有する請求項１または２に記載の決済処理システム。
【請求項４】
送信命令受付部は、
商品情報取得部から取得され、かついまだに決済処理サーバに前記対応する送信が成功していない商品情報を送信命令受付のために選択可能に表示する表示手段を有する請求項１から３のいずれか一に記載のクレジット決済処理システム。
【請求項５】
クレジットカードなどから決済のための情報である決済情報を読み取るカードリーダと、カードリーダとは別体で、カードリーダから決済情報を受信し、その決済情報のなかで決済処理に必要な情報である決済必要情報を決済処理のためのサーバである決済処理サーバに送信する携帯端末とからなる決済処理システムを用いた決済方法であって、
カードリーダが、クレジットカードから決済情報である記録決済情報を読み取るための決済情報読取ステップと、
カードリーダが、読み取った記録決済情報のうち決済必要情報を残さないでこれを暗号化決済情報とする暗号化ステップと、
カードリーダが、暗号化決済情報を残さないで携帯端末に暗号化決済情報を送信する対携帯端末送信ステップと、
携帯端末が、暗号化決済情報を受信する受信ステップと、
携帯端末が、一次元コードまたは二次元コードである商品情報を読み取る商品情報読取ステップと、
携帯端末が、読み取った商品情報と受信した暗号化決済情報とを関連付けて記憶する記憶ステップと、
携帯端末が、現在送信すべき暗号化決済情報と関連付けられた商品情報に関連付けて暗号化決済情報の送信命令を受け付ける送信命令受付ステップと、
携帯端末が、受け付けた送信命令に応じて決済処理サーバに対して暗号化決済情報を送信する送信ステップと、
を有する決済処理方法。    
【請求項６】
コンピュータに請求項５に記載の決済処理方法を実行させるためのプログラム。
【請求項７】
クレジットカードなどから決済のための情報である決済情報を取得し、その決済情報のなかで決済処理に必要な情報である決済必要情報を決済処理のためのサーバである決済処理サーバに送信する携帯端末を有する決済処理システムであって、
携帯端末は、
クレジットカードから決済情報である記録決済情報を読み取るための第二決済情報読取部と、
読み取った記録決済情報のうち決済必要情報を残さないでこれを暗号化決済情報とする第二暗号化部と、
商品情報を取得するための商品情報取得部と、
取得した商品情報と、暗号化決済情報とを関連付けて記憶する記憶部と、
現在送信すべき暗号化決済情報と関連付けられた商品情報に関連付けて暗号化決済情報の送信命令を受け付ける送信命令受付部と、
受付けた送信命令に応じて決済処理サーバに対して暗号化決済情報を送信するための送信部と、
を有する決済処理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、携帯端末を利用して行うクレジットカードなどの決済処理システム、同システムを利用する決済処理方法および同方法をコンピュータに実行させるためのプログラムに関する。
【背景技術】
【０００２】
顧客が店舗から購入した商品・サービスの対価支払いをクレジットカードなどを用いて行う決済処理が広く普及しているが、特に最近では、携帯端末でクレジットカードなどから決済に必要な情報を取得し、これをサーバに送信して決済処理を行う方法が広まりつつある。例えば、特許文献１には、店舗が所持する携帯電話を利用して、顧客の携帯電話から読み取った顧客情報および店舗の情報を店舗の携帯電話からクレジット会社側のサーバに送信し、クレジット会社側で所定の比較・判断を行ってクレジット決済を行うことを可能にした決済システムが開示されている（特許文献１参照）。また、非特許文献１には、スマートフォンおよび専用カードリーダを利用したクレジット決済方法が開示されている。同文献に記載のクレジット決済方法は、専用カードリーダでクレジットカードから決済情報を読み取るともに、カードリーダ側でこれを暗号化してスマートフォンに送信し、スマートフォンは、受信した暗号化された決済情報をサーバに送信し、サーバからクレジットカード決済センターに決済情報を送信して、決済処理を行うようにしたものである。その際、カードリーダおよびスマートフォンにおいては暗号化された決済情報の復号化を一切行わないこととし、これによって顧客情報のセキュリティに万全を期することとしている（非特許文献１参照）。なお、非特許文献１には、２０１１年４月１３日に日本クレジットカード協会から発表された「スマートフォン決済の安全基準に関する基本的な考え方」に準拠してサービスを提供することが記載されている。「スマートフォン決済の安全基準に関する基本的な考え方」は、スマートフォン等を活用したクレジットカード決済において、クレジットカード会員にとって、安心・安全にクレジットカード利用ができる環境を提供することを目的とするものであり、このための具体的な基準として、スマートフォン決済アプリケーションにおいて、カード会員情報等を承認処理完了後に保存しないこと、暗号化された会員情報等のデータについてスマートフォン等での暗号化解除、直接閲覧、編集および復号等を行ってはならないことなどがうたわれている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００７−３２３２４９号公報
【非特許文献】
【０００４】
【非特許文献１】ロイヤルゲート・プレスリリース（２０１１年４月１５日付け）「スマートフォン型クレジットカード決済リーダー正式発表」（ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｒｏｙａｌｇａｔｅ．ｃｏ．ｊｐ／ｐｒｅｓｓ／ｉｎｄｅｘ．ｈｔｍｌ）
【発明の概要】
【発明が解決しようとする課題】
【０００５】
以上の状況に照らせば、今後スマートフォンなどの携帯端末を利用したクレジット決済がさらに普及することが見込まれるとともに、「スマートフォン決済の安全基準に関する基本的な考え方」に沿った顧客情報のセキュリティ確保が益々重要になると考えられる。そこで、本発明の解決すべき課題は、携帯端末を利用したクレジット決済において顧客情報のセキュリティ確保をより徹底することにある。
【課題を解決するための手段】
【０００６】
以上の課題を解決するため、第一の発明は、クレジットカードなどから決済のための情報である決済情報を読み取るカードリーダと、カードリーダとは別体で、カードリーダから決済情報を受信し、その決済情報のなかで決済処理に必要な情報である決済必要情報を決済処理のためのサーバである決済処理サーバに送信する携帯端末とからなる決済処理システムであって、カードリーダは、クレジットカードから決済情報である記録決済情報を読み取るための第一決済情報読取部と、読み取った記録決済情報のうち決済必要情報を残さないでこれを暗号化決済情報とする第一暗号化部と、暗号化決済情報を残さないで携帯端末に暗号化決済情報を送信する対携帯端末送信部とを有し、携帯端末は、暗号化決済情報を受信する受信部と、商品情報を取得するための商品情報取得部と、取得した商品情報と、受信した暗号化決済情報とを関連付けて記憶する記憶部と、現在送信すべき暗号化決済情報と関連付けられた商品情報に関連付けて暗号化決済情報の送信命令を受け付ける送信命令受付部と、受付けた送信命令に応じて決済処理サーバに対して暗号化決済情報を送信するための送信部とを有する決済処理システムを提供する。
【０００７】
また、第二の発明は、第一の発明を基礎として、商品情報取得部は、一次元コードまたは二次元コードである商品情報を読み取るための商品情報読取手段を有する決済処理システムを提供する。
【０００８】
また、第三の発明は、第一または第二の発明を基礎として、携帯端末は、送信が成功した暗号化決済情報を送信成功後ただちに記憶部から消去する消去部と、送信部から送信された暗号化決済情報の送信日付をその暗号化決済情報に関連付けて記憶部に記憶されている商品情報に関連付けて記録する送信日付記録部とを有する記載の決済処理システムを提供する。
【０００９】
また、第四の発明は、第一から第三のいずれか一の発明を基礎として、送信命令受付部は、商品情報取得部から取得され、かついまだに決済処理サーバに前記対応する送信が成功していない商品情報を送信命令受付のために選択可能に表示する表示手段を有するクレジット決済処理システムを提供する。
【００１０】
また、第五の発明は、クレジットカードなどから決済のための情報である決済情報を読み取るカードリーダと、カードリーダとは別体で、カードリーダから決済情報を受信し、その決済情報のなかで決済処理に必要な情報である決済必要情報を決済処理のためのサーバである決済処理サーバに送信する携帯端末とからなる決済処理システムを用いた決済方法であって、カードリーダが、クレジットカードから決済情報である記録決済情報を読み取るための決済情報読取ステップと、カードリーダが、読み取った記録決済情報のうち決済必要情報を残さないでこれを暗号化決済情報とする暗号化ステップと、カードリーダが、暗号化決済情報を残さないで携帯端末に暗号化決済情報を送信する対携帯端末送信ステップと、携帯端末が、暗号化決済情報を受信する受信ステップと、携帯端末が、一次元コードまたは二次元コードである商品情報を読み取る商品情報読取ステップと、携帯端末が、読み取った商品情報と受信した暗号化決済情報とを関連付けて記憶する記憶ステップと、携帯端末が、現在送信すべき暗号化決済情報と関連付けられた商品情報に関連付けて暗号化決済情報の送信命令を受け付ける送信命令受付ステップと、携帯端末が、受け付けた送信命令に応じて決済処理サーバに対して暗号化決済情報を送信する送信ステップとを有する決済処理方法を提供する。
【００１１】
また、第六の発明は、コンピュータに第五の発明に係る決済処理方法を実行させるためのプログラムを提供する。
【００１２】
また、第七の発明は、クレジットカードなどから決済のための情報である決済情報を取得し、その決済情報のなかで決済処理に必要な情報である決済必要情報を決済処理のためのサーバである決済処理サーバに送信する携帯端末を有する決済処理システムであって、携帯端末は、クレジットカードから決済情報である記録決済情報を読み取るための第二決済情報読取部と、読み取った記録決済情報のうち決済必要情報を残さないでこれを暗号化決済情報とする第二暗号化部と、商品情報を取得するための商品情報取得部と、取得した商品情報と、暗号化決済情報とを関連付けて記憶する記憶部と、現在送信すべき暗号化決済情報と関連付けられた商品情報に関連付けて暗号化決済情報の送信命令を受け付ける送信命令受付部と、受付けた送信命令に応じて決済処理サーバに対して暗号化決済情報を送信するための送信部とを有する決済処理システムを提供する。
【発明の効果】
【００１３】
本発明により、携帯端末を利用したクレジット決済において顧客情報のセキュリティ確保をより徹底することが可能となる。
【図面の簡単な説明】
【００１４】
【図１】本発明に係る決済処理システムを用いた決済処理全般の仕組みについて説明するための概念図
【図２】実施例１の決済処理システムの機能ブロックの一例を示す図
【図３Ａ】実施例１の決済処理システムにおけるカードリーダのハードウェア構成の一例を示す概略図
【図３Ｂ】実施例１の決済処理システムにおける携帯端末のハードウェア構成の一例を示す概略図
【図４】実施例１の決済処理システムにおける処理の流れの一例を示す図
【図５】実施例２の決済処理システムの機能ブロックの一例を示す図
【図６】実施例２の決済処理システムにおける携帯端末のハードウェア構成の一例を示す概略図
【図７】実施例２の決済処理システムにおける処理の流れの一例を示す図
【図８】実施例３の決済処理システムの機能ブロックの一例を示す図
【図９】実施例３の決済処理システムにおける携帯端末のハードウェア構成の一例を示す概略図
【図１０】実施例３の決済処理システムにおける処理の流れの一例を示す図
【図１１】実施例４の決済処理システムの機能ブロックの一例を示す図
【図１２】実施例４の決済処理システムにおける携帯端末のハードウェア構成の一例を示す概略図
【図１３】実施例４の決済処理システムにおける処理の流れの一例を示す図
【図１４】実施例５の決済処理システムの機能ブロックの一例を示す図
【図１５】実施例５の決済処理システムにおける携帯端末のハードウェア構成の一例を示す概略図
【図１６】実施例５の決済処理システムにおける処理の流れの一例を示す図
【符号の説明】
【００１５】
０１００、０２００  決済処理システム
０１１０、０２１０  カードリーダ
０１２０、０２２０  携帯端末
０１３０、０２３０  クレジットカード
０１４０、０２４０  決済処理サーバ
０１５０            カード発行会社サーバ
０２１１            第一決済情報読取部
０２１２            第一暗号化部
０２１３            対携帯端末送信部
０２２１            受信部
０２２２            商品情報取得部
０２２３            記憶部
０２２４            送信命令受付部
０２２５            送信部
【発明を実施するための形態】
【００１６】
以下に、本発明の実施例を説明する。実施例と請求項の相互の関係は以下のとおりである。実施例１は主に請求項１などに関し、実施例２は主に請求項２、５、６などに関し、実施例３は主に請求項３などに関し、実施例４は主に請求項４などに関し、実施例５は主に請求項７などに関する。なお、本発明はこの実施例に何ら限定されるものではなく、その要旨を逸脱しない範囲において、種々なる態様で実施しうる。
【実施例１】
【００１７】
<概要>
本実施例の決済処理システムは、カードリーダと、カードリーダとは別体の携帯端末とからなる決済処理システムである。カードリーダは、クレジットカードから決済情報を読み取り、このうち決済必要情報を残さないで暗号化し、かつ暗号化した決済情報（暗号化決済情報）をカードリーダに残さないで携帯端末に暗号化決済情報を送信するようになっている。携帯端末は、この暗号化決済情報を受信し、別途取得する商品情報と暗号化決済情報を関連付けた上で、送信命令を受け付けると、暗号化決済情報を決済処理サーバに対して送信する。
【００１８】
はじめに、本発明に係る決済処理システムを用いた決済処理全般の仕組みについて概略を説明する。
【００１９】
図１は、本発明に係る決済処理システムを用いた決済処理全般の仕組みについて説明するための概念図である。本図に示すように、本発明に係る「決済処理システム」０１００は、「カードリーダ」０１１０と、「携帯端末」０１２０とを有する。ここでは、ある顧客（クレジットカード所持者）（「顧客Ａ」とする）がある店舗（「店舗Ｂ」とする）において商品であるチョコレート「ＸＹＺ」（価格１５ドル）（「商品Ｃ」とする）をクレジットカード決済によって購入する場合を例に、決済処理の仕組みについて説明する。
【００２０】
まず、（１）顧客Ａが所持するクレジットカードを例えば本図に示したような接触型のカードリーダに接触させることでカードリーダがクレジットカードの決済情報を読み取る。決済情報は、例えば、クレジットカードのＩＤ（本図の例では、クレジットカード発行会社を特定するための会社名、カードの名称などを表す「ＡＢＣ」という文字およびカード所持者を一意的に識別するための「１２３４  ５６７８  ９０１２  ３４５６」という１６桁の数字からなる）、クレジットカードの有効期限などである。
【００２１】
次に、（２）カードリーダは読み取った決済情報を暗号化する。暗号化の方法は公知の方法を用いればよい。この暗号化の際、もとの決済情報がカードリーダに残らないようにするため、もとの決済情報を消去するなどの処理が行われる。これは、顧客情報のセキュリティ確保のためである。
【００２２】
（３）暗号化された決済情報（暗号化決済情報）は、携帯端末（典型的にはスマートフォン）に対して送信され、携帯端末がこれを受信する。送受信の方法としては、例えば、Ｂｌｕｅｔｏｏｔｈ（登録商標）規格に基づく短距離無線通信方法を用いることが考えられる。
【００２３】
一方、（４）携帯端末は、商品情報も取得する。この取得は、例えば商品Ｃのパッケージに印刷されたバーコードなどの一次元コードまたは二次元コードを携帯端末が備える読み取り機能を用いて読み取ることにより実行される。このように一次元コードまたは二次元コードを読み取って取得される商品情報としては、商品を一意的に特定するためのＩＤ（ユニークＩＤ）が考えられる。また、商品情報の取得は、このようにして読み取ったユニークＩＤに基づいて、携帯端末自身が保持するテーブルなどにおいて当該ユニークＩＤに関連付けられている情報を取得する形で行ってもよい。このような形で取得される商品情報としては、例えば、商品の価格が考えられる。この場合、例えば携帯端末自身が保持するテーブルにおいて商品ＣのユニークＩＤと価格（１５ドル）が関連付けられており、バーコードリーダで読み取った商品Ｃを示すユニークＩＤに基づいて当該商品の価格（１５ドル）を商品情報として取得することができる。
【００２４】
以上の処理により、携帯端末は、暗号化決済情報と商品情報とを取得することになる。携帯端末はこれら取得した両情報を関連付けて記憶する。
【００２５】
また、携帯端末が取得した商品情報を自身の表示画面に表示するようにしてもよい。そこで、（５）顧客Ａは、自分が買おうとしている商品Ｃの内容と価格をこの表示画面で確認し、間違いがなければ表示画面上に表示された「ＯＫ」ボタンを示すアイコンを押下（クリック）する。携帯端末は、この押下動作による入力信号を受け付けることで、現在送信すべき暗号化決済情報と関連付けられた商品情報に関連付けて暗号化決済情報の送信命令を受け付けることになる。
【００２６】
（６）この送信命令を受け付けると、携帯端末は、暗号化決済情報を決済処理サーバ０１４０に送信する。
【００２７】
（７）なお、本発明に係る決済処理システムにおける処理とは直接関係はないが、決済処理サーバは、受信した暗号化決済情報を復号してカード発行会社のサーバ０１５０に送信するようにしてもよい。これは、カード発行会社が当該クレジットカードを用いた決済処理に承諾を与えないと当該決済処理が実行できない仕組みになっている場合に対応する処理である。この場合には、カード発行会社が当該クレジットカードを用いた決済処理に承諾を与えることでその後の決済処理が可能となる。
【００２８】
同様に、本発明の構成外における処理として、（８）決済処理サーバの管理者等から店舗Ｂに対する代金立替払い処理、（９）カード発行会社から代金立替払い者に対する代金支払い処理、（１０）顧客Ａからカード発行会社に対する代金支払い処理が行われてもよい。これによって、本発明に係る決済処理システムを利用した決済処理が全体として完結する。なお、（８）〜（１０）は処理の内容を列挙したものにすぎず、（８）がその性質上（９）に先立って行われるものであることを除けば、この順序で行われる必要があることまで意味するものではない。
【００２９】
<構成>
（決済処理システム）
本実施例の決済処理システムの構成について以下説明する。図２は、本実施例の決済処理システムの機能ブロックの一例を示す図である。本図に示すように、「決済処理システム」０２００は、「カードリーダ」０２１０と、「携帯端末」０２２０とを有する。
【００３０】
（カードリーダ）
次に、各部の構成について詳細に説明する。まず、カードリーダの構成について説明する。カードリーダは、「第一決済情報読取部」０２１１と、「第一暗号化部」０２１２と、「対携帯端末送信部」０２１３とを有する。カードリーダは接触型カード、非接触型カード、接触型および非接触型カード（いわゆるハイブリッドカード）のいずれに対応するものであってもよい。また、カードリーダは対応する携帯端末専用のものであってもよいし、汎用のものであってもよい。
【００３１】
（第一決済情報読取部）
第一決済情報読取部は、クレジットカードから決済情報である記録決済情報を読み取るためのものである。「クレジットカード」には、即時払いのデビットカードは含まれないが、本システムと同様の構成をデビットカードを用いた決済に適用することも可能である。
【００３２】
「記録決済情報」は決済に必要な情報としてクレジットカードに記録されている情報であって、例えば、利用者の所持するクレジットカードの会社および所持者を識別するための記号・番号、カードの有効期限が該当する。
【００３３】
読取りのための具体的な方法としては公知技術を利用すればよく、例えば、クレジットカードが接触型のカードである場合には、接触型カードに対応するカードリーダが用いられ、クレジットカードとカードリーダを接触させて行う通信により記録決済情報を取得するように構成される。カードが非接触型のカードである場合には、非接触型カードに対応するカードリーダが用いられ、カードリーダとカードとの間で行われる無線通信によって記録決済情報を取得するように構成される。
【００３４】
（第一暗号化部）
第一暗号化部は、第一決済情報読取部が読み取った記録決済情報のうち決済必要情報を残さないでこれを暗号化決済情報とするように構成されている。「決済必要情報」とは、記録決済情報のうち、決済処理を行うのに必要不可欠な情報を言う。一般に、上で記録決済情報として挙げたもののうち、最低限クレジットカードの記号・番号がわかれば決済処理は可能であると考えられることから、決済必要情報にはこれらが含まれていれば足りる。
【００３５】
決済必要情報を暗号化決済情報とする際に、元の決済必要情報（即ち、暗号化される前の決済必要情報）を残さないようにするための構成としては、例えば、暗号化決済情報が生成されたか否か判断し、生成されたと判断された場合に、決済必要情報を消去するという構成などが考えられる。
【００３６】
これに関連して、カードリーダ内に決済必要情報が保持されているか否かを視覚的に判断可能とするために、例えばカードリーダに決済必要情報が保持されている場合と保持されていない場合を区別して示すためのインジケータを設けるようにしてもよい。具体的には、例えば赤色と緑色のように互いに色が異なる二つのＬＥＤランプをカードリーダに備え、カードリーダ内に決済必要情報が保持されている状態のときは赤色ＬＥＤランプを点灯させ、カードリーダ内に決済必要情報が保持されていない状態のときは緑色ＬＥＤランプを点灯させるといったように点灯させるランプの色で状態を区別できるようにしてもよい。この構成によれば、暗号化決済情報が生成されたときに消去されるべき決済必要情報が確実に消去されたかどうかを点灯しているランプの色で判断することが可能となる。また、この構成による別の効果として、カードリーダがクレジットカードから記録決済情報を読み取った際に読取りに成功したか否かをランプの色で判断するという効果を得ることもできる。例えば、記録決済情報の読取りに成功したのであれば当該情報中に含まれている決済必要情報が保持されている状態であるので、赤色ＬＥＤランプが点灯し、このことから成功したことを知ることができる。あるいは、このような視覚的な方法に代えて、あるいはこれに加えて、聴覚的な方法でカードリーダ内に決済必要情報が保持されているか否かを示すようにしてもよい。例えば、保持されていないときは「決済必要情報が保持されていません」といったように声で知らせたり、ブザー音などの音で知らせたりといった方法が考えられる。
【００３７】
また、カードリーダが記録決済情報を読み取った後未だ暗号化決済情報を生成する前にカードリーダの電源が何らかの事情で切られた場合、カードリーダが記録決済情報中に含まれる決済必要情報を自動的に消去するように構成されていてもよい。このための構成としては、例えば、記録決済情報の読取りに係る手順として読み取った記録決済情報を揮発性メモリにのみ格納するという処理手順を実行するプログラムを定めておけばよい。
【００３８】
暗号化の方法は公知の方法を用いればよい。例えば、暗号化と復号化で同じ鍵を使う暗号方式である共通鍵暗号方式を用いる場合には、共通暗号鍵アルゴリズムとして、例えば、データを６４ビット長のブロックに分割して各ブロックを５６ビット長の鍵で暗号化するアルゴリズムであるＤＥＳ（Ｄａｔａ  Ｅｎｃｒｙｐｔｉｏｎ  Ｓｔａｎｄａｒｄ）を用いることなどが考えられる。また、公開鍵と秘密鍵の対になる二つの鍵を使ってデータの暗号化／復号化を行う方法である公開鍵暗号方式を用いる場合には、大きな二つの素数を利用して公開鍵、秘密鍵を生成する方法であるＲＳＡ（Ｒｉｖｅｓｔ、Ｓｈａｍｉｒ，Ａｄｅｌｍａｎ）を用いることなどが考えられる。
【００３９】
第一暗号化部が行う暗号化の特徴は、暗号化に際して決済必要情報を残さないようにする点にある。このための構成として、例えば、暗号化決済情報が生成されたかどうかの判断を行い、生成されたと判断された場合には、第一暗号化部が決済必要情報を消去するようにすればよい。
【００４０】
（対携帯端末送信部）
対携帯端末送信部は、暗号化決済情報を残さないで携帯端末に暗号化決済情報を送信するように構成される。暗号化決済情報を残さないための構成としては、上と同様、例えば、暗号化決済情報が送信されたかどうかの判断を行い、送信されたと判断された場合には、対携帯端末送信部が暗号化決済情報を消去するようにすればよい。その際、暗号化決済情報が送信されたかどうかを対携帯端末送信部が判断することを可能にするため、例えば、暗号化決済情報を携帯端末が受信した場合には、携帯端末からカードリーダに対して受信した旨を示す情報を返信するようにしておくことが考えられる。このような構成によれば、かかる情報の返信があれば、カードリーダ（対携帯端末送信部）が暗号化決済情報が確かに携帯端末に送信されたことを知ることができるので、これに基づいて暗号化決済情報を消去することができる。
【００４１】
以上の構成の結果、暗号化決済情報が携帯端末に送信された暁には、カードリーダには決済必要情報も暗号化決済情報も一切残らないこととなり、顧客情報のセキュリティの保護が保たれる。
【００４２】
なお、何らかのトラブルなどによりカードリーダから携帯端末に対する暗号化決済情報の送信が成功しない場合も考えられるところ、このような不測の事情によってカードリーダ内に暗号化決済情報が残ってしまうという事態が生じないようにするため、例えば対携帯端末送信部が所定時間内（例えば２秒以内）もしくは所定回数以内（例えば５回以内）のトライアルによって送信に成功しなかった場合には、自動的にその暗号化決済情報を消去するようにしてもよい。また、その場合に、上述のインジケータを利用して、暗号化決済情報の送信が成功しなかったにもかかわらず暗号化決済情報が消去されたことを示すランプの点灯（例えば緑色ランプの点滅）を行うようにしてもよい。
【００４３】
暗号化決済情報の生成前に電源が切れた場合と同様に、暗号化決済情報の送信前に何らかの事情で電源が切れた場合についても、暗号化決済情報を自動的に消去するように構成されていることが望ましい。このための構成の一例は暗号化決済情報の生成前に電源が切れた場合について述べたところと同様である。
【００４４】
（携帯端末）
次に、携帯端末の構成について説明する。携帯端末は、「受信部」０２２１と、「商品情報取得部」０２２２と、「記憶部」０２２３と、「送信命令受付部」０２２４と、「送信部」０２２５とを有する。携帯端末として典型的に想定されているのは、ｉＰｈｏｎｅ（登録商標）、Ａｎｄｒｏｉｄ（登録商標）などをプラットフォームとするスマートフォン、即ち、携帯電話またはＰＨＳと携帯情報端末を融合したものである。しかし、本発明にいう携帯端末はスマートフォンに限られず、カードリーダからの受信機能およびネットワークを介してサーバへの送信機能を有する携帯端末が広く含まれる。
【００４５】
なお、カードリーダと携帯端末は通例一対一に対応しているが、複数のカードリーダと一の携帯端末が対応するものであってもよい。これは、例えば、複数の小規模店舗がそれぞれ独自のカードリーダを保有するとともに、一台の携帯端末を共有するような場合を想定したものである。
【００４６】
（受信部）
受信部は、カードリーダから送信された暗号化決済情報を受信するように構成されている。上述のように、受信部が暗号化決済情報を受信した場合には、その旨を示す情報をカードリーダに対して返信するように構成されていることが望ましい。
【００４７】
（商品情報取得部）
商品情報取得部は、商品情報を取得するためのものである。「商品情報」とは、顧客であるクレジットカード所持者が店舗である携帯端末所持者から購入しようとしている商品またはサービスに関する情報をいう。例えば、商品・サービスの対価は必須の商品情報として考えられるが、このほか、商品・サービスの内容を一意的に特定するためのＩＤや商品の個数などを含んでいてもよい。
【００４８】
取得される商品情報は複数であってもよい。例えば、１回の買い物（１回のクレジット払い）で複数種類の商品を購入する場合には、商品の種類ごとに商品情報が取得されるので商品情報は複数となる。
【００４９】
なお、処理の流れについて後述するように、商品情報の取得と、暗号化決済情報の受信の時間的前後は問わないが、好適には暗号化決済情報の受信が先に行われることが望ましい。その理由は以下のとおりである。
即ち、実際の買い物の場面を考えると、顧客がまず買いたい商品をレジに持ってきたので店員がその商品情報を携帯端末で読み取ったとする。しかし、その後顧客が何らかの事情（例えばクレジットカードを忘れたといった事情）で買い物をしないまま帰ってしまった場合、読み取った商品情報は携帯端末に残ったままとなる。その後、別の新たな顧客が来て商品をレジに持ってきたので店員がその商品情報を携帯端末で読み取り、顧客のクレジットカードの決済情報を読み取ったとする。すると、この決済情報と関連付けられる商品情報の中に前の顧客が買おうとしていた商品に係る商品情報も含まれてしまい、買い物に混乱が生じる。そこで、ある段階で前の顧客に係る商品情報を消去する必要があるが、上のように先に商品情報が取得されるケースだと、商品情報を消去するタイミングを人為的判断（例えば、店員が前の顧客はもはや戻ってくることはないだろうと判断したとき）に委ねざるを得ず、適切でない。
そこで、暗号化決済情報の受信を商品情報の取得より先に行う（従って、カードリーダが行う決済情報の取得および暗号化も商品情報の取得より先に行われることとなる）ようにすれば、以下の構成をとることが可能となり、上のような混乱を避けることが可能となる。即ち、暗号化決済情報が受信され、商品情報の取得が行われた後に、暗号化決済情報が携帯端末から決済処理サーバに対して送信されないうちに、カードリーダが新たな決済情報を読み取り、これを暗号化して携帯端末に送信してきた場合には、携帯端末は自身が保持している商品情報を自動的に消去するという構成である。これによれば、実際の買い物の場面において、まず顧客のクレジットカードの決済情報をカードリーダで読み取り、その後顧客がレジに持ってきた商品の商品情報を読み取ったにもかかわらずその顧客が何らかの事情でその買い物をしないで帰ってしまった後に、新たな別の顧客が来たので顧客のクレジットカードの決済情報をカードリーダで読み取った場合には、自動的に前の顧客の商品情報が消去されるので、上のような混乱を避けることができる。
【００５０】
（記憶部）
記憶部は、取得した商品情報と、受信した暗号化決済情報とを関連付けて記憶するように構成されている。関連付けのための具体的構成については後述のハードウェア構成についての説明中で述べる。
【００５１】
（送信命令受付部）
送信命令受付部は、現在送信すべき暗号化決済情報と関連付けられた商品情報に関連付けて暗号化決済情報の送信命令を受け付けるように構成されている。「現在送信すべき暗号化決済情報」は、決済処理のために決済処理サーバに送信しようとしている暗号化決済情報である。また、商品情報は記憶部においてこの暗号化決済情報と関連付けられたものである。送信命令の受付けは、例えば携帯電話の決定キーの押下による入力信号を受け付けることで行われ、その際における現在送信すべき暗号化決済情報と商品情報との関連付けは、例えば上記入力の受付が表示画面に商品情報が表示されている際に行われた場合にその表示されている商品情報に関連付けられて記憶部に記憶されている暗号化決済情報を関連付けるべき暗号化決済情報であると判断することで可能である。
【００５２】
（送信部）
送信部は、受け付けた送信命令に応じて決済処理サーバに対して暗号化決済情報を送信するように構成されている。暗号化決済情報を送信する際には、当該暗号化決済情報に関連付けられて記憶されている商品情報のうち決済に必要な情報も読み出され、当該暗号化決済情報とともに送信される。商品情報のうち決済に必要な情報には、少なくとも商品・サービスの価格が含まれるが、一般にはこれだけで足りると考えられる。また、送信に際しては、携帯端末を一意的に識別するためのＩＤも暗号化決済情報などともに送信される。これは、立替払い者が誰に対して立替払いをすればよいかを知る手掛かりとするためである。なお、複数の小規模店舗が一台の携帯端末を共有する場合のように、複数のカードリーダと一の携帯端末が対応する場合には、同様の目的から、カードリーダを一意的に識別するためのＩＤも暗号化決済情報などともに送信される。
【００５３】
なお、顧客情報のセキュリティの保護の観点からは、決済処理サーバに対する暗号化決済情報の送信後は、携帯端末にも暗号化決済情報が残らないようにすることが望ましい。このための構成については、別の実施例にて後述する。また、暗号化決済情報の送信が成功する前であっても、カードリーダについて述べたところと同様に、携帯端末についても何らかの事情で電源が切れたり送信を試みたが成功しなかったりといった事態が生じることが考えられる。そこで、顧客情報のセキュリティ保護の万全を期するため、このような事態が発生した場合には、カードリーダについて述べたところと同様の構成により携帯端末が暗号化決済情報の消去を行うように構成されていることが望ましい。
【００５４】
その後、決済処理サーバにおいて、図１を用いて上述したような要領で処理を行うことにより、関連するすべての決済処理を完結させることが可能となる。
【００５５】
（ハードウェア構成）
次に、本実施例の決済処理システムのハードウェア構成について説明する。
はじめにカードリーダのハードウェア構成について説明する。図３Ａは本実施例における決済処理システムにおけるカードリーダのハードウェア構成の一例を示す概略図である。本例のカードリーダの第一決済情報読取部と、対携帯端末送信部は、「記憶装置（記録媒体）」０３０１と、「メインメモリ」０３０２と、「ＣＰＵ」０３０３と、「Ｉ／Ｏ」０３０４とから構成される。第一暗号化部は「記憶装置（記録媒体）」と、「メインメモリ」と、「ＣＰＵ」とから構成される。
【００５６】
これらは「システムバス」０３０５などのデータ通信経路によって相互に接続され、情報の送受信や処理を行う。記憶装置はＣＰＵによって実行される各種プログラムなどを記憶している。またメインメモリは、プログラムがＣＰＵによって実行される際の作業領域であるワーク領域を提供する。また、このメインメモリや記憶装置にはそれぞれ複数のメモリアドレスが割り当てられており、ＣＰＵで実行されるプログラムは、そのメモリアドレスを特定しアクセスすることで相互にデータのやりとりを行い、処理を行うことが可能になっている。本例では、決済情報読取りプログラムと、暗号化プログラムと、対携帯端末送信プログラムが記憶装置に記憶されており、これらのプログラムは例えば電源投入とともに自動的に記憶装置から読み出されてメインメモリに常駐する。
【００５７】
次に、各部に係るハードウェア構成について具体的に説明する。まず、第一決済情報読取部に係るハードウェア構成について説明する。決済情報読取プログラムは、クレジットカードなどから決済のための情報である決済情報を読み取る処理を行う。具体的には、例えばカードリーダが接触型のクレジットカードに対応するものである場合には、決済情報読取プログラムは、クレジットカードに搭載されたＩＣモジュール端子とカードリーダの端子を接触させて行う通信により記録決済情報を取得する処理を行う。カードリーダが非接触型のクレジットカードに対応するものである場合には、決済情報読取プログラムは、カードリーダが備えるコイルから磁界を発生させ、かざされたカードとの間で無線通信を行うことによって、記録決済情報を取得する処理を行う。
【００５８】
次に、第一暗号化部に係るハードウェア構成について説明する。暗号化プログラムは、上記処理によって読み取られメインメモリに格納されている記録決済情報に含まれる決済必要情報のうち決済必要情報を残さないでこれを暗号化決済情報とする処理を行う。暗号化のための具体的な構成については既に述べたとおりである。
【００５９】
次に、対携帯端末送信部に係るハードウェア構成について説明する。対携帯端末送信プログラムは、暗号化決済情報を残さないで携帯端末に暗号化決済情報を送信する処理を行う。送信の具体的処理としては、例えば既に述べたＢｌｕｅｔｏｏｔｈ（登録商標）規格に基づく短距離無線通信方法を用いるものや赤外線通信方法を用いるものが挙げられる。
【００６０】
次に、携帯端末のハードウェア構成について説明する。図３Ｂは本実施例における決済処理システムにおける携帯端末のハードウェア構成の一例を示す概略図である。本例の携帯端末の受信部と、商品情報取得部と、送信命令受付部と、送信部は、「記憶装置（記録媒体）」０３０１と、「メインメモリ」０３０２と、「ＣＰＵ」０３０３と、「Ｉ／Ｏ」０３０４とから構成される。記憶部は「記憶装置（記録媒体）」と、「メインメモリ」と、「ＣＰＵ」とから構成される。
【００６１】
これらも「システムバス」０３０５などのデータ通信経路によって相互に接続され、情報の送受信や処理を行う。その余の点もカードリーダのハードウェア構成について説明したところと同様である。本例では、受信プログラムと、商品情報取得プログラムと、記憶プログラムと、送信命令受付プログラムと、送信プログラムが記憶装置に記憶されており、これらのプログラムも例えば電源投入とともに自動的に記憶装置から読み出されてメインメモリに常駐する。
【００６２】
次に、各部に係るハードウェア構成について具体的に説明する。まず、受信部に係るハードウェア構成について説明する。受信プログラムは、カードリーダから送信された暗号化決済情報をＩ／Ｏを介して取得する。具体的な受信方法の例はカードリーダの送信方法について述べたとおりである。
【００６３】
次に、商品情報取得部に係るハードウェア構成について説明する。商品情報取得プログラムは、商品情報を取得する処理を行う。具体的には、例えば、携帯端末に備えられているキーなどのインターフェイスを操作して購入対象である商品・サービスの価格を示す数値が入力された場合に、当該入力信号を受け付けることで、商品情報である商品の価格が取得される。あるいは、携帯端末にバーコードなどの読取り機能が備えられている場合には、当該機能を用いて、商品のパッケージなどに印刷されているバーコードを読み取ることで商品情報を取得するようにしてもよい。
【００６４】
次に、記憶部に係るハードウェア構成について説明する。記憶プログラムは、上記処理によって取得した商品情報と、受信した暗号化決済情報とを関連付けて記憶する処理として、これら情報をメインメモリに格納する処理を行う。関連付けのための構成としては、例えば、受信した暗号化決済情報を格納する際に特定の識別情報を付し、その後この暗号化決済情報が送信される前に取得された商品情報にもすべてこれと同一の識別情報を附する形で両者に同一の識別情報を付しておき、一方の識別情報を読み出すと両者が同時に読み出されるという構成などを用いればよい。
【００６５】
次に、送信命令受付部に係るハードウェア構成について説明する。送信命令受付プログラムは、現在送信すべき暗号化決済情報と関連付けられた商品情報に関連付けて暗号化決済情報の送信命令を受け付ける処理を行う。送信命令の受付けは、例えば携帯端末に表示された「ＯＫ」ボタンを表すアイコンを押下（クリック）する操作により入力された信号を受け付けることで行われる。
【００６６】
次に、送信部に係るハードウェア構成について説明する。送信プログラムは、受付けた送信命令に応じて決済処理サーバに対して暗号化決済情報を送信するための処理を行う。具体的には、メインメモリに格納されている暗号化決済情報を読み出し、Ｉ／Ｏを介してネットワークで接続された決済処理サーバに対して当該情報を送信する。その際、当該暗号化決済情報に関連付けられて記憶されている商品情報のうち決済に必要な情報も読み出され、当該暗号化決済情報とともに送信される。
【００６７】
<処理の流れ>
図４は、本実施例における決済処理システムにおける処理の流れの一例を示す図である。
まず、決済情報読取ステップＳ０４０１において、カードリーダがクレジットカードから決済情報である記録決済情報を読み取る。
次に、暗号化ステップＳ０４０２において、カードリーダが読み取った記録決済情報のうち決済必要情報を残さないでこれを暗号化決済情報とする。
次に、対携帯端末送信ステップＳ０４０３において、カードリーダが暗号化決済情報を残さないで携帯端末に暗号化決済情報を送信する。
次に、受信ステップＳ０４０４において、携帯端末が暗号化決済情報を受信する。
次に、商品情報読取ステップＳ０４０５において、携帯端末が商品情報を取得する。
【００６８】
ステップＳ０４０１〜Ｓ０４０４における処理とステップＳ０４０５における処理の順序の前後は問わない。しかしながら、上述したように、前の顧客が買おうとした商品の商品情報が残ったまま後の顧客のクレジットカードの決済情報が読み取られた場合の混乱を避けるための構成を可能にするとの観点からは、本図に示すような、ステップＳ０４０１〜Ｓ０４０４における処理がステップＳ０４０５における処理よりも先に行われることが望ましい。
次に、記憶ステップＳ０４０６において、携帯端末が取得した商品情報と受信した暗号化決済情報とを関連付けて記憶する。
次に、送信命令受付ステップＳ０４０７において、携帯端末が現在送信すべき暗号化決済情報と関連付けられた商品情報に関連付けて暗号化決済情報の送信命令を受け付ける。
次に、送信ステップＳ０４０８において、携帯端末が受け付けた送信命令に応じて決済処理サーバに対して暗号化決済情報を送信する。
【００６９】
<効果>
本実施例の発明により、携帯端末を利用したクレジット決済において顧客情報のセキュリティ確保をより徹底することが可能となる。
【実施例２】
【００７０】
<概要>
本実施例の決済処理システムは、実施例１の決済処理システムと基本的に共通するが、商品情報取得部が一次元コードまたは二次元コードである商品情報を読み取るための商品情報読取手段を有する点に特徴がある。
【００７１】
<構成>
（全般）
図５は、本実施例の決済処理システムの機能ブロックの一例を示す図である。本図に示すように、「決済処理システム」０５００の「携帯端末」０５２０の「商品情報取得部」００５２２は「商品情報読取手段」０５２６を有する。以下、商品情報読取手段の構成について説明する。その余の構成は実施例１の決済処理システムの構成と同じであるから説明を省略する。
【００７２】
（商品情報取得部：商品情報読取手段）
商品情報読取手段は、一次元コードまたは二次元コードである商品情報を読み取るためのものである。一次元コードにはバーコードが含まれる。
【００７３】
（ハードウェア構成）
図６は本実施例における決済処理システムのハードウェア構成の一例を示す概略図である。本例の決済処理システムの携帯端末の商品情報読取手段を含む商品情報取得部は、「記憶装置（記録媒体）」０６０１と、「メインメモリ」０６０２と、「ＣＰＵ」０６０３と、「Ｉ／Ｏ」０６０４とから構成される。その余の携帯端末の全般的なハードウェア構成は実施例１で述べたところと同様である。
【００７４】
商品情報取得プログラムは、一次元コードまたは二次元コードである商品情報を読み取る処理を行う。具体的には、例えば、携帯端末に備えられているバーコードリーダなどの読取り手段を用いて商品のパッケージなどに印刷されているバーコードなどの一次元コードまたは二次元コードを読み取ることで商品情報を取得する処理を行う。
【００７５】
その余の各部の構成は、実施例１で図３Ｂを用いて述べたところと同様であるので、説明を省略する。
【００７６】
<処理の流れ>
図７は、本実施例の決済処理システムにおける処理の流れの一例を示す図である。
商品情報読取ステップＳ０７０５において、携帯端末が一次元コードまたは二次元コードである商品情報を読み取る。
その余の処理の流れは実施例１で図４を用いて述べたところと同様であるので、説明を省略する。
【００７７】
<効果>
本実施例の発明により、商品情報の取得をバーコードリーダなどを用いて簡単に行うことができ、決済をより迅速・正確に行うことが可能となる。
【実施例３】
【００７８】
<概要>
本実施例の決済処理システムは、実施例１または２の決済処理システムと基本的に共通するが、携帯端末は、送信が成功した暗号化決済情報を送信成功後ただちに記憶部から消去する手段と、送信された暗号化決済情報の送信日付をその暗号化決済情報に関連付けて記憶されている商品情報に関連付けて記録する手段を有する点に特徴がある。
【００７９】
<構成>
【００８０】
（全般）
図８は、本実施例の決済処理システムの機能ブロックの一例を示す図である。本図に示すように、「決済処理システム」０８００の「携帯端末」０８２０は「消去部」０８２７と、「送信日時記録部」０８２８を有する。以下、消去部および送信日時記録部の構成について説明する。その余の構成は実施例１または２の決済処理システムの構成と同じであるから説明を省略する。
【００８１】
（消去部）
消去部は、送信が成功した暗号化決済情報を送信成功後ただちに記憶部から消去するように構成されている。本構成の目的は、顧客情報のセキュリティの保護をさらに図るために、暗号化決済情報を携帯端末側に残さないことにある。すでに実施例１の構成で述べたようにカードリーダに暗号化決済情報が残らないことが担保されているので、本実施例の構成による消去後はカードリーダ、携帯端末を含む決済処理システム内において暗号化決済情報を復号することは不可能となり、顧客情報のセキュリティが一層確実に保護されることとなる。消去のための具体的構成は、実施例１でカードリーダに暗号化決済情報が残らないようにするための構成について述べたところと同様の構成を用いればよい。
【００８２】
その際、暗号化決済情報が送信されたかどうかを携帯端末が判断することを可能にするため、実施例１においてカードリーダ・携帯端末間での送受信について述べたところと同様に、例えば、暗号化決済情報を決済処理サーバが受信した場合には、決済処理サーバから携帯端末に対して受信した旨を示す情報を返信するようにしておくことが考えられる。
【００８３】
なお、送信が成功した後に消去を行うようにしているのは、送信に失敗した場合には再度送信を試みるために暗号化決済情報を保持ししている必要があるためである。ただし、送信が成功しないまま暗号化決済情報が携帯端末に残ってしまうことを防ぐ必要があることは実施例１で述べたところと同様である。従って、本実施例の携帯端末は、送信が成功しない場合であっても実施例１に述べたのと同様の場合には、同様の構成によって、暗号化決済情報を消去する手段も有していることが望ましい。
【００８４】
ただし、カードリーダ・携帯端末間の送受信の場合と異なり、暗号化決済情報を決済処理サーバに送信しようとしている時点は、顧客がその商品の購入意思を示し、店舗がこれを承諾していた時点である（法律的にいえば顧客・店舗間の売買契約が成立している）。従って、送信が成功しなかった場合に顧客の意思を無視して自動的に暗号化決済情報を消去してしまうのは好ましくない。そこで、このような場合に暗号化決済情報を消去するか否かについて顧客の承諾を介在させてもよい。このための構成としては、携帯端末が、送信に失敗したと判断した場合に、実施例１で述べたのと同様のインジケータを利用して例えば、赤色のＬＥＤランプを点滅させるとともに、表示画面に「送信に失敗しました。このまま終了してもよろしいですか。」といったメッセージを「ＯＫ」ボタンとともに表示し、顧客が承諾する場合に顧客等によって押下された当該ボタンからの入力信号を受け付けて暗号化決済情報を消去するようにすればよい。
【００８５】
（送信日付記録部）
送信日付記録部は、送信部から送信された暗号化決済情報の送信日付をその暗号化決済情報に関連付けて記憶部に記憶されている商品情報に関連付けて記録するように構成されている。本構成の目的は、店舗が売上票などを作成する上で必要な情報として、決済情報が送信された日付や必要に応じて時刻を残しておく必要があるためである。従って、ここでいう送信日付には文字通りの日付のほか時刻が含まれ得る。一方、送信日付は顧客情報とは直接関係がないので、これを残しても顧客情報のセキュリティの保護には反しないことからこのように構成したものである。従って、送信日付以外であっても、顧客情報のセキュリティ保護に反しない範囲であれば送信日付とともに記憶するようにしてもよい。このような情報としては、例えば、送信された暗号化決済情報に関連付けられた携帯端末のＩＤ、商品情報などが考えられる。
【００８６】
（ハードウェア構成）
図９は本実施例における決済処理システムのハードウェア構成の一例を示す概略図である。本例の決済処理システムの携帯端末の消去部と送信日付記録部は、「記憶装置（記録媒体）」０９０１と、「メインメモリ」０９０２と、「ＣＰＵ」０９０３と、「Ｉ／Ｏ」０９０４とから構成される。その余の携帯端末の全般的なハードウェア構成は実施例１で述べたところと同様である。
【００８７】
消去プログラムは、送信が成功した暗号化決済情報を送信成功後ただちに記憶部から消去する処理を行う。具体的には、例えば、消去プログラムが暗号化決済情報の送信が成功したか否かの判断を行い、成功したとの判断結果が得られた場合には、メインメモリに格納されている暗号化決済情報を消去する処理を行う。
【００８８】
送信日付記録プログラムは、送信部から送信された暗号化決済情報の送信日付をその暗号化決済情報に関連付けて記憶部に記憶されている商品情報に関連付けて記録する処理を行う。具体的には、送信が成功したとの判断結果とともにその送信日付を送信日付記録プログラムが取得すると、当該プログラムは当該送信日付をメインメモリに記録する。さらに、送信日付は顧客情報とは関係がなく、かつ相当期間保存することが必要となるものであることから、不揮発性のメモリ（記憶装置）にも記録される。
【００８９】
その余の各部の構成は、実施例１または２で図３Ｂ、図６を用いて述べたところと同様であるので、説明を省略する。
【００９０】
<処理の流れ>
図１０は、本実施例の決済処理システムにおける処理の流れの一例を示す図である。
暗号化決済情報の送信が成功したか否かの判断ステップＳ１００９において送信が成功したとの判断結果が得られた場合には、消去ステップＳ１０１０において携帯端末が暗号化決済情報を送信成功後ただちに記憶部から消去する。
次に送信日付記録ステップＳ１０１１において、携帯端末が送信部から送信された暗号化決済情報の送信日付をその暗号化決済情報に関連付けて記憶部に記憶されている商品情報に関連付けて記録する。
その余の処理の流れは実施例１または２で図４、図７を用いて述べたところと同様であるので、説明を省略する。
【００９１】
<効果>
本実施例の発明により、顧客情報のセキュリティの保護に反しない範囲で、取引に必要な情報を残すことが可能となる。
【実施例４】
【００９２】
<概要>
本実施例の決済処理システムは、実施例１から３のいずれか一の決済処理システムと基本的に共通するが、携帯端末の送信命令受付部が、商品情報取得部から取得され、かついまだに決済処理サーバに前記対応する送信が成功していない商品情報を送信命令受付のために選択可能に表示する表示手段を有する点に特徴がある。
【００９３】
<構成>
（全般）
図１１は、本実施例の決済処理システムの機能ブロックの一例を示す図である。本図に示すように、「決済処理システム」１１００の「携帯端末」１１２０の「送信命令受付部」１１２４は、「表示手段」１１２９を有する。以下、表示手段の構成について説明する。その余の構成は実施例１から３のいずれか一の決済処理システムの構成と同じであるから説明を省略する。
【００９４】
（携帯端末：送信命令受付部：表示手段）
表示手段は、商品情報取得部から取得され、かついまだに決済処理サーバに前記対応する送信が成功していない商品情報を送信命令受付のために選択可能に表示するように構成されている。本構成の目的は、顧客の購入の便宜を考えたものであり、例えば顧客が複数の商品・サービスを購入候補として選択した後、まだ決済情報が送信される前、即ち、まだ決済処理サーバに送られてその後の手続が進められる決済内容が確定していない間において、最終的にどれを購入するかを顧客が選択可能にすることにある。具体的には、例えば携帯端末の表示画面に購入商品のリストが表示されるとともに、商品ごとに購入するかどうかの決定アイコン（例えば「購入する」、「購入しない」という文字を含むアイコン）やチェックボックスが表示され、顧客が「購入する」をクリックした商品ないしボックスにチェックを入れた上で例えば「ＯＫ」ボタン（アイコン）を押下（クリック）して選択した商品だけが最終的な購入対象として決定され、これにかかる商品情報が、これを関連付けた暗号化決済情報とともに決済処理サーバに送信されるように構成される。従って、ここでいう「送信が成功してない」というのは、「送信を試みたがエラーが生じた場合」を排除するものではないが、「まだ送信を試みる前である状態」を含む概念であり、典型的にはむしろ後者を想定したものである。
【００９５】
なお、最終的に選択された商品情報だけを暗号化決済情報とともに決済処理サーバに送信するための構成としては、例えば、選択されなかった商品に係る商品情報を、決済処理サーバへの暗号化決済情報の送信前に消去するようにすればよい。そのタイミングおよび対象の判断は、顧客によるアイコンのクリックなどをトリガーとして行うことが可能である。
【００９６】
（ハードウェア構成）
図１２は本実施例における決済処理システムのハードウェア構成の一例を示す概略図である。本例の決済処理システムの携帯端末の表示手段を含む送信命令受付部は、「記憶装置（記録媒体）」１２０１と、「メインメモリ」１２０２と、「ＣＰＵ」１２０３と、「Ｉ／Ｏ」１２０４と、Ｉ／Ｏを介して接続されるディスプレイ１２０５とで構成されている。その余の携帯端末の全般的なハードウェア構成は実施例１で述べたところと同様である。
【００９７】
表示プログラムは、商品情報取得部から取得され、かついまだに決済処理サーバに前記対応する送信が成功していない商品情報を送信命令受付のために選択可能に表示する処理を行う。具体的には、例えば、表示プログラムが暗号化決済情報の送信が成功したか否かの判断を行い、成功してないとの判断結果が得られた場合には、メインメモリに格納されている商品情報をディスプレイに表示する処理を行う。これにより例えば顧客による「購入する」アイコンのクリックによる入力信号を受け付けてその後の決済処理を実施例１などと同様に進めることが可能となる。
【００９８】
その余の各部の構成は、実施例１から３のいずれか一で図３Ｂなどを用いて述べたところと同様であるので、説明を省略する。
【００９９】
<処理の流れ>
図１３は、本実施例の決済処理システムにおける処理の流れの一例を示す図である。
表示ステップＳ１３０７において携帯端末が商品情報取得部から取得され、かついまだに決済処理サーバに前記対応する送信が成功していない商品情報を送信命令受付のために選択可能に表示する。
なお、ステップＳ１３０７とステップＳ１３０８の処理順序は逆であってもよい。
その余の処理の流れは実施例１から３のいずれか一で図４などを用いて述べたところと同様であるので、説明を省略する。
【０１００】
<効果>
本実施例の発明により、顧客の購入の便宜を図ることが可能となる。
【実施例５】
【０１０１】
<概要>
本実施例の決済処理システムは、実施例１などで述べた決済処理システムと基本的に共通するが、カードリーダを備えずに、他の手段でクレジットカードの情報を携帯端末に入力することで、同様の決済処理を行うものである。
【０１０２】
<構成>
（全般）
図１４は、本実施例の決済処理システムの機能ブロックの一例を示す図である。本図に示すように、「決済処理システム」１４００は「携帯端末」１４２０を有する。携帯端末は、「第二決済情報読取部」１４２１と、「第二暗号化部」１４２２と、「商品情報取得部」１４２３と、「記憶部」１４２４と、「送信命令受付部」１４２５と、「送信部」１４２６とを有する。以下、携帯端末の各部の構成について説明する。
【０１０３】
（第二決済情報読取部）
第二決済情報読取部は、クレジットカードから決済情報である記録決済情報を読み取るためのものである。実施例１〜４の決済処理システムでは記録決済情報の読取りはカードリーダが行うように構成されていたが、本実施例では携帯端末が行う点がこれと異なる。具体的な読取りの方法としては、例えば、クレジットカードが非接触型のカードである場合に、携帯端末が実施例１で述べた非接触型のカードリーダと同様の機能を備えており、かざされたカードとの間で無線通信を行うことによって、記録決済情報を取得する処理を行う方法が考えられる。また、他の方法として、顧客の携帯端末に記憶されている決済情報を短距離無線通信もしくは赤外線通信を用いて本システムの携帯端末が読み取るという方法が考えられる。さらに、クレジットカード上に視認可能に記載されている情報を携帯端末が備える撮像機能を用いて撮像し、画像処理技術を用いて読み取るようにしてもよい。
【０１０４】
本実施例の構成の目的は、携帯端末を利用したクレジット決済においてカードリーダを不要にした点にあり、これによって、より簡易な設備で決済処理を行うことが可能となる。このような構成の本発明を利用すれば、例えば簡易な設備しか有しない露店商などでも、顧客情報のセキュリティを十分保護することが可能な環境の下で決済処理を行うことが可能となる。
【０１０５】
（第二暗号化部）
第二暗号化部は、読み取った記録決済情報のうち決済必要情報を残さないでこれを暗号化決済情報とするように構成される。暗号化のための具体的な構成は、実施例１で述べたところと同様である。読み取った記録決済情報のうち決済必要情報を残さないことの目的およびそのための構成も実施例１で述べたところと同様である。
【０１０６】
（商品情報取得部、記憶部、送信命令受付部、送信部）
これら各部の構成は、実施例１で述べたところと同様である。
【０１０７】
（ハードウェア構成）
図１５は本実施例における決済処理システムの携帯端末のハードウェア構成の一例を示す概略図である。本例の携帯端末の第二決済情報読取部と、商品情報取得部と、送信命令受付部と、送信部は、「記憶装置（記録媒体）」１５０１と、「メインメモリ」１５０２と、「ＣＰＵ」１５０３と、「Ｉ／Ｏ」１５０４とから構成される。第二暗号化部と、記憶部は「記憶装置（記録媒体）」と、「メインメモリ」と、「ＣＰＵ」とから構成される。
【０１０８】
これらも「システムバス」１５０５などのデータ通信経路によって相互に接続され、情報の送受信や処理を行う。その余の点も実施例１のカードリーダおよび携帯端末のハードウェア構成について説明したところと同様である。本例では、決済情報読取プログラムと、暗号化プログラムと、商品情報取得プログラムと、記憶プログラムと、送信命令受付プログラムと、送信プログラムが記憶装置に記憶されており、これらのプログラムも例えば電源投入とともに自動的に記憶装置から読み出されてメインメモリに常駐する。
【０１０９】
次に、各部に係るハードウェア構成について具体的に説明する。まず、第二決済情報読取部に係るハードウェア構成について説明する。決済情報読取プログラムは、クレジットカードからＩ／Ｏを介して記録決済情報を読み取る処理を行う。具体的には、例えばクレジットカードが非接触型のカードである場合に、携帯端末に備えるコイルから磁界を発生させ、かざされたカードとの間で無線通信を行うことによって、記録決済情報を取得する処理を行う。取得された記録決済情報はメインメモリに一旦格納される。
【０１１０】
次に、第二暗号化部に係るハードウェア構成について説明する。暗号化プログラムは、上記処理によって読み取られメインメモリに格納されている記録決済情報に含まれる決済必要情報のうち決済必要情報を残さないでこれを暗号化決済情報とする処理を行う。具体的な暗号化のためのハードウェア構成は、実施例１でカードリーダのハードウェア構成について述べたところと同様である。
【０１１１】
商品情報取得部、記憶部、送信命令受付部、送信部に係るハードウェア構成については、実施例１において携帯端末のハードウェア構成について述べたところと同様である。
【０１１２】
<処理の流れ>
図１６は、本実施例の決済処理システムにおける処理の流れの一例を示す図である。
まず、記録決済情報の読取りステップ（２）Ｓ１６０１において、携帯端末がクレジットカードから記録決済情報を読み取る。
次に、暗号化ステップ（２）Ｓ１６０２において、携帯端末が読み取った記録決済情報のうち決済必要情報を残さないでこれを暗号化決済情報とする。
商品情報取得ステップＳ１６０３、記憶ステップＳ１６０４、送信命令受付ステップＳ１６０５、送信ステップＳ１６０６における処理は、実施例１で図４を用いて説明した処理の流れにおける対応するステップにおける処理と同様である。
【０１１３】
<効果>
本実施例の発明により、携帯端末を利用したクレジット決済においてカードリーダを不要とすることができ、より簡易な設備で決済処理を行うことが可能となる。
【図１】
2012252665.tif 000003
【図２】
2012252665.tif 000004
【図３Ａ】
2012252665.tif 000005
【図３Ｂ】
2012252665.tif 000006
【図４】
2012252665.tif 000007
【図５】
2012252665.tif 000008
【図６】
2012252665.tif 000009
【図７】
2012252665.tif 000010
【図８】
2012252665.tif 000011
【図９】
2012252665.tif 000012
【図１０】
2012252665.tif 000013
【図１１】
2012252665.tif 000014
【図１２】
2012252665.tif 000015
【図１３】
2012252665.tif 000016
【図１４】
2012252665.tif 000017
【図１５】
2012252665.tif 000018
【図１６】
2012252665.tif 000019