JP6743023B2 - 携帯端末を利用した決済システム - Google Patents

Description

本発明は、携帯端末を利用した決済システムおよび決済方法に係り、特に、スマートフォン等の携帯端末を利用してユーザのセキュリティチェックを行うと共に商品代金の決済を行う決済システムおよび決済方法に関するものである。

通常の商取引において、ユーザは現金またはクレジットカードまたはデビットカード等を用いて商品の購入代金、サービスや飲食の代金を支払うことがしばしば行われる。クレジットカードまたはデビットカード等のカードを用いて代金を支払う場合には、店舗側に備えられた業者端末の磁気カードリーダ部でユーザのカードを読み取り、商品の品名、金額、取引日時等を入力して印字された紙片を出力する。業者端末は一般的にはパソコンが用いられるが携帯端末が用いられることもある。カード決済のときにしばしば暗証番号の入力を求められることがある。この場合、店舗において暗証番号と共にクレジット情報等のカード情報が保存されてしまうために、暗証番号またはカード情報が悪用される恐れがある。一旦、暗証番号が盗まれると、キー入力のみで容易に不正使用することを許容してしまうという問題がある。特に、カードの不正使用や偽造という点については十分なセキュリティが備わっていない。

一方、符号化された情報を２次元的に配置したＱＲコードをカメラで撮像し、撮像した画像を文字等に復号するようにしたＱＲコードシステムが知られている（特許文献１を参照）。ＱＲコードは一般にカードに使用されているバーコード等に比較して情報量を飛躍的に多くできる特徴がある。また、人の指の指紋または静脈の血管を画像登録し個人認証をするシステムやセキュリティ・トークンを用いる方法もある。

他のカード決済方法として、店舗に備えられたカード読取装置から使用カードのカード情報を読み取り、このカード情報を店員の所持するスマートフォンで受信しこれを決済サーバへ送信して決済依頼をする。決済サーバは決済結果を店員のスマートフォンへ送信する。スマートフォンはこれを受信し撮影可能に表示する。顧客は己の携帯端末で表示された決済結果を撮影して取得する（特許文献２を参照）。
更に他のカード決済方法として、ユーザのスマートフォンに、クレジット会社名、クレジット番号、有効期間等を含むクレジット情報を搭載してクレジットカードの所持を不要にし、商取引の際に、クレジット情報を店舗側の受信端末へ送信する。受信端末は受信したクレジット情報をクレジット会社サーバへ送信してクレジット決済を依頼する。クレジット会社はクレジット情報に基づき個人認証の結果が正当であればクレジット決済が行われる（特許文献３を参照）。

カード決済においてはセキュリティの保持が非常に重要であり、特にパスワードや暗証番号やカード情報が盗用されないように個人認証と共にカード決済をするシステムが提案されている（特許文献４を参照）。
また、カードリーダが読み取ったカードデータを所定の法則でワンタイム使用コードへ変換して業者端末へ送信すると共にそのカードデータを金融機関へ送信し、金融機関では受信したカードデータを同じ法則でワンタイム使用コードへ変換し、業者から支払い要求があったときに業者から受信されたワンタイム利用コードと金融機関で変換したワンタイム使用コードを比較し適合すれば業者へ取引許可をするシステムがある（特許文献５を参照）。

特許文献１ ： 特開２００９−１８７１９８号 公報
特許文献２ ： 特開２０１３−２０６２５６号 公報
特許文献３ ： 特開２００５−１２８８９９号 公報
特許文献４ ： 国際公開ＷＯ−Ａ１−２０１３／１６８８１５号 公報
特許文献５ ： ＵＳ２００９/０２２２３８３Ａ１

上記したようなスマートフォンを用いた決済方法では、決済された金額情報が即時にユーザに渡らず、ユーザが目視で金額を確認するだけとなる場合があり、また、店舗側にはユーザが決済金額を確認したという証拠が残らないので、明瞭な取引とならない。しかも、クレジット情報や暗証番号が他人により不正に利用されたり盗用される恐れに対して十分な対策がなされていない。

これを解消するために、ユーザの携帯端末に記録されたカード情報を店舗の業者端末へ送信した後、業者端末からユーザ携帯端末に金額情報を送信し金額の確認を求め、ユーザは金額を確認し承認したことを店舗側に返信する方法も考えられるが、３回の通信プロセスがあるので決済処理が煩雑となる。

本発明の第１の目的は、ユーザの携帯端末と店舗業者の端末との間で一往復の通信をするのみで、ユーザには取引金額を自己の携帯端末に記録でき、一方、業者においてはユーザの取引の意思表明と取引金額の承諾を取得することができるようにした携帯端末を利用した決済システムおよび決済方法を提供することにある。

本発明の第２の目的は、暗証番号やカード情報を他人により不正に利用されないようにした高いセキュリティを有する携帯端末を利用した決済システムおよび決済方法を提供することにある。

本発明の上記第１の目的を達成するために、業者端末において、少なくとも業者自身を特定する業者ＩＤと請求金額を含む二次元コードを作成してディスプレイに表示し、その二次元コードをユーザの携帯端末で読み取り、それを解読してユーザ携帯端末のディスプレイに請求金額等を表示し、ユーザはその金額を確認し承認したことを運用会社サーバを介して業者端末に返信する。

本発明の上記第２の目的を達成するために、予め、ユーザと業者の所要事項はそれぞれ運用会社サーバに登録されており、ユーザ携帯端末と業者端末にはそれぞれアプリがダウンロードされている。取引時には、ダウンロードされたアプリのプログラムに基づいてユーザ携帯端末、業者端末および運用会社サーバとの間で通信が行われ、運用会社サーバがセキュリティチェックで適合と判断されたときのみ運用会社がクレジット会社等の金融機関との間で決済手続が実行し、決済が完了した後に決済完了をユーザ端末と業者端末に通知する。ここでのセキュリティチェックは、ユーザに対する個人認証、ユーザ携帯端末に対するセキュリティチェック、およびユーザのカード情報に対する与信チェックの全部または一部を含む。

本発明に係る携帯端末を利用した決済システムおよび決済方法によれば、取引の際の購入の意思確認および金額の確認を最小限の操作で適正に行うことができ、ユーザのセキュリティチェックが適合と判断されれば、カード情報を業者端末に渡すことなく、決裁処理を運用会社と金融機関との間で実行することができ、厳格なセキュリティの保持の下で商取引を実行することができる。

本発明に係るクレジット決済システムの一実施例を示す全体構成図 ユーザが会員登録する手順の一例を示すフロー図 業者が業者登録する手順の一例を示すフロー図 ユーザが会員登録後に運用会社サーバに対し操作をする場合の一例を示すフロー図 業者が業者登録後に運用会社サーバに対し操作をする場合の一例を示すフロー図。 ユーザと業者との間でクレジット決済取引を行う手順の一実施例を示すフロー図 図６の(1)の続きであって、ユーザ携帯端末と運用会社サーバとの間の処理手順の一実施例を示すフロー図 図６の(2)の続きであって、業者端末と運用会社サーバとの間の処理手順の一実施例を示すフロー図 図８の(3)の続きであって、運用会社サーバと業者端末の処理手順の一実施例を示すフロー図

以下図面に基づいて本発明の一実施例について説明する。
図１において、１はユーザが所有するユーザ携帯端末であって、通常は、入力装置２、ディスプレイ３、プロセッサ４、メモリ５等を備えたスマートフォンである。入力装置はカメラ６も含んでいる。８は店舗等の業者が備える業者端末であって、入力装置９、ディスプレイ１０、プロセッサ１１、メモリ１２等を備えている。業者端末はスマートフォンが好ましいが卓上型の端末であってもよい。１４は運用会社サーバであって、データベース１５、一時記憶装置１６、プロセッサ１７等を備えている。１９はクレジット会社サーバであってデータベース２０を備えている。これらユーザ端末装置１と業者端末８と運用会社サーバ１４とクレジット会社サーバ１９はインターネット回線等の通信媒体２２により接続されている。なお、図１では金融機関としてクレジット会社サーバ１９を例示したが、これに限らず銀行等の金融機関であってもよい。以下の説明ではクレジット会社とその会社が発行するクレジットカードを例にとって説明するが、本発明では、金融機関が発行するデビットカードやデビット機能を備えたキャッシュカード等を用いて決済することができる。

ユーザが本発明に係るシステムを利用するためには会員登録をしなければならない。図２はユーザがユーザ携帯端末を用いて会員登録するためのプロセッサ４の動作手順を示すフロー図である。なお、この会員登録は運用会社サーバ１４のプロセッサ１７とも連携して処理が実行される。

図２において、ユーザは携帯端末１を用いて会員登録２５を実行する。ステップ２６において、本システムを運用する運用会社の運用会社サーバにアクセスして運用会社のホームページから会員サイトを開く。ステップ２７にて会員サイト中の「新規登録」の項目をクリックすると、新規登録用の入力フォームが表示される。このフォームへの入力項目は、住所、氏名、電話番号、ユーザＩＤ、パスワード、メールアドレス、１つの代表的なクレジット名称、クレジット情報、クレジット名称ＩＤ等である。ユーザＩＤとパスワードは新規会員が所定の制約の下に任意に決定することができるものであり、ユーザを個人認証し特定するために用いられる。クレジット名称は新規会員がクレジットカードを特定するのに適する簡潔な名称である。新規に登録する場合は１つだけの代表的なクレジットカードを選定しその名称を決める。クレジット情報は、選定されたクレジットカードのクレジット会社名、クレジットカード番号、有効期限、所有者の氏名等のクレジット決済に必要な情報である。クレジット名称ＩＤは、クレジット名称を読み出して表示するために入力が要求されるものであり、機密性の高いクレジット情報の表示に高いセキュリティを持たせたものである。新規に会員登録する者は、ステップ２８で、上記の項目が新規登録データとして入力される。

次いで、ステップ２９において、入力された新規登録データを自己のメールアドレス宛に送信する。その結果、ユーザ携帯端末１は送信した新規登録データを受信することができる。受信した新規登録データの登録内容をチェックして新規登録データが正しく送受信されることを確認する。次にステップ３０において、運用会社サーバ１４に対して会員ＩＤとセキュリティＩＤの作成を依頼する。セキュリティＩＤはユーザ携帯端末を特定し認証するための基準となるＩＤである。

会員ＩＤとセキュリティＩＤの作成依頼を受けた運用会社サーバ１４は、ステップ３２で会員ＩＤと認証ＩＤ１を設定しこれらを会員毎にデータベース１５に登録する。次いで、ステップ３３において変換ロジックを用いて認証ＩＤ１をセキュリティＩＤに変換しこれを登録する。変換ロジックは特許文献４に記載されているように、ＩＤビットデータをＩＤマップアドレスを用いて認証ＩＤに変換した方法と同様な方法で認証ＩＤをセキュリティＩＤに変換することができる。しかし、他の変換ロジックを用いて認証ＩＤをセキュリティＩＤに変換してもよい。変換ロジックは会員毎に異なり会員毎にデータベースに登録される。ステップ３４で会員ＩＤとセキュリティＩＤをユーザ携帯端末へ送信する。

ユーザ携帯端末は、ステップ３６で会員ＩＤとセキュリティＩＤを受信しこれらをメモリ５に登録する。そしてステップ３７にて各携帯端末に付与されている本携帯端末特有の個体識別番号であるユーザ端末ＩＤ１を取得する。ステップ３８において、ユーザ携帯端末は運用会社サーバに対して会員ＩＤ、セキュリティＩＤ、ユーザ端末ＩＤ１および新規登録データを登録するように依頼をする。

運用会社サーバは、ステップ４０において、会員ＩＤ、認証ＩＤ１、セキュリティＩＤ、ユーザ端末ＩＤ１、新規登録データをリンクしてデータベース１５に登録して処理を終了する。なお、ユーザ端末ＩＤ１はこれを変換ロジックを用いて変換した結果をユーザ端末ＩＤ１ｃとして登録してもよい。

以上はユーザの会員登録について説明したものであるが、次に店舗等の業者の業者登録をするときのプロセッサ１１の動作手順について図３に基づき説明する。

図３において、業者は業者端末８を用いて業者登録４５を実行する。先ずステップ４６で、業者は本システムを運用する運用会社の運用会社サーバにアクセスして運用会社のホームページから業者サイトを開く。ステップ４７で業者サイト中の「新規登録」の項目をクリックすると、新規登録用の入力フォームが表示される。このフォームへの入力項目は、名称、支店名、住所、代表者名、電話番号、メールアドレス、業者振込口座情報、ユーザＩＤ、パスワード等である。ユーザＩＤとパスワードは新規登録業者が所定の制約の下に任意に決定することができ、業者を認証し特定するために用いられる。新規に業者登録する者は、ステップ４８で、上記入力項目にそれぞれ新規登録データとして入力する。新規登録データを入力した後、ステップ４９で新規登録データを運用会社サーバ１４へ送信する。

運用会社サーバ１４は、ステップ５１で新規登録データを受信しこれをデータベース１５に登録する。

一方、業者端末８は、ステップ５３において運用業者サーバへ業者の承認を依頼すると、運用会社サーバはステップ５５で業者ＩＤを作成し、ステップ５６でその業者ＩＤを添付して承認メールを業者端末へ送信する。

業者端末８は、ステップ５８で承認メールを受信し、ステップ５９で承認メールに添付された業者ＩＤを業者端末のメモリに登録し、処理を終了する。

ユーザが会員登録をした後のユーザの運用会社サーバに対する会員の操作６２について図４に基づき説明する。

図４において、ユーザがユーザ携帯端末を操作してステップ６３において運用会社サーバの会員サイトを開き、ステップ６４でユーザＩＤとパスワードの入力欄にそれらを入力すると、ステップ６５で「会員アプリダウンロード」、「会員情報変更」、「クレジット情報追加・変更」、「決済履歴」、「アプリ停止」等の項目が表示される。

ステップ６５において、「会員アプリダウンロード」をクリックすると、ステップ６７で会員ＩＤとユーザ端末ＩＤ１を読み出し、これらを添付して運用会社サーバ１４に会員アプリダウンロードを依頼する。なお、会員アプリはユーザが業者との商取引でクレジット決済を行うときに必要な会員情報とプログラムが含まれている。

運用会社サーバ１４は、ステップ６９で受信した会員ＩＤに対応する会員情報に基づいて作成された会員アプリを選択し、ステップ７０において、受信したユーザ端末ＩＤ１がステップ４０で登録されたユーザ端末ＩＤ１と比較して一致するかどうかのセキュリティチェックを行う。セキュリティチェックがＯＫであればステップ７１で会員アプリを当該ユーザ携帯端末１へ送信する。もしセキュリティチェックが不合格のＮＯと判定されればユーザ携帯端末へ会員アプリのダウンロード不可の通知をする。ユーザ端末ＩＤ１はユーザ携帯端末固有の個体識別番号であるから、登録の時に用いられた携帯端末と同一端末に対してのみ、会員アプリのダウンロードが許容されることになる。

ユーザ携帯端末１はステップ７３で会員アプリを受信した時はこれをメモリ５に登録し、ステップ７４で会員アプリのアイコンを作成してディスプレイ３に表示して処理を終了する。なお、ステップ７６でダウンロード不可の通知を受けた時は、図２で操作されたユーザ携帯端末とは異なる端末で操作したかどうかを確認し再度会員アプリのダウンロードを試みる。これにより、会員アプリは、正当なユーザ以外の者による操作でダウンロードされることを防止している。または、会員登録に用いたユーザ携帯端末以外の端末にダウンロードされることをも防止している。これにより、会員登録した当初のユーザとその携帯端末は不正使用や盗用から保護されることになる。

ステップ６５において、「会員情報変更」が選択されたときは、運用会社サーバ１４において、氏名、住所、電話番号、メールアドレス、ユーザＩＤ、またはパスワード等を変更登録することができる。ステップ６５で、「クレジット情報追加・変更」が選択されたときは、ステップ８０で、最大５個までのクレジット名称とそれに伴うクレジット情報を追加登録することができ、また、登録された一部のクレジット名称とそのクレジット情報を変更または削除することができる。最大５個までとしたのは無制限にクレジット情報を追加出来ないようにしたもので、最大５個は便宜的に定めたものである。ステップ６５で「決済履歴」が選択されたときは、ステップ８４で、過去のクレジット決済をした履歴をデータベース１５から読み出して閲覧することができる。ステップ６５で「アプリ停止」が選択されたときは、ステップ８４で、ダウンロードされた会員アプリの使用を停止処理することができる。

業者登録をした後に業者が業者端末８で行うことができる運用会社サーバ１４に対する操作８６について図５に基づき説明する。

図５において、業者が業者端末を操作してステップ８７において運用会社サーバの業者サイトを開き、ステップ８８でユーザＩＤとパスワードの入力欄にそれらを入力すると、「業者アプリダウンロード」および「業者情報の変更」等の項目が表示される。業者アプリは、本システムを利用して業者が商取引行うために必要な機能、例えば、請求金額等を含む請求情報をＱＲコード化する機能、タイマ機能および通信機能を実行するプログラム、および、商取引に必要な情報を含んでいる。

ステップ８９において「業者アプリダウンロード」をクリックすると業者ＩＤの入力欄が表示される。ステップ９０でその入力欄に業者ＩＤを入力して運用会社サーバ１４に業者アプリのダウンロードを依頼する。

業者アプリのダウンロード依頼を受信した運用会社サーバは、ステップ９２で受信した業者ＩＤがデータベース１５に登録されている業者ＩＤと一致しているかどうかをチェックする。その結果、ＯＫであれば、ステップ９３で業者アプリを当該業者端末へ送信する。

業者端末８は、ステップ９５で業者アプリを受信しこれをメモリ１２に登録し、ステップ９６で業者アプリのアイコンを作成してディスプレイに表示する。一方、運用会社サーバにおけるステップ９２でチェックの結果がＮＯであれば、業者端末におけるステップ９８でダウンロード不可の表示がされる。このようにステップ９２のチェックにより、業者アプリが不正にダウンロードされることを防止している。

次に、ユーザが店舗において商品を購入する際にクレジット決済１００を行う手順について図６から図９に基づき説明する。

図６において、ユーザと店舗との間で商取引に合意が成立した場合、業者端末８では、ステップ１０１においてディスプレイに表示された業者アプリのアイコンをクリックすると、ステップ１０２で、ユーザＩＤとパスワードの入力画面が現れるので、これに業者のユーザＩＤとパスワードを入力し、ログインする。ログイン後の画面に「決済金額入力」と「ＱＲコード作成」の項目が表示されるので、業者はステップ１０３で「決済金額入力」欄に請求金額を入力し、ステップ１０４で「ＱＲコード作成」欄をクリックする。その結果、業者ＩＤと請求金額と受注明細番号を含む請求情報がＱＲコード化されステップ１０５でＱＲコードが表示される。

一方、ユーザ携帯端末１では、商取引の合意が成立したときに、ステップ１０７において、ディスプレイに表示された会員アプリアイコンをクリックすると、ユーザＩＤとパスワードとログインを含む項目が表示される。ステップ１０８でユーザＩＤとパスワードを入力し、ログインする。ここで、ＷＯ−Ａ１−２０１３／１６８８１５号公報に記載されているように個人認証が行われるが、ここでは説明を省略する。次いで、ステップ１０９でクレジット名称ＩＤを入力すると、運用会社サーバ１４のデータベース１５に登録されている一個または複数個のクレジット名称が表示されると共に、一括払いか分割払いか、分割払いの場合は何回払いかを選択する「支払方法」項目と、「ＱＲコード読込」項目等が表示される。

引き続き、ステップ１１０において、最大５個のクレジット名称がディスプレイ上に表示される。ステップ１１１でユーザが支払いに利用しようとするクレジット名称を指定し、ステップ１１２で支払回数を入力する。なお、デビットカードの場合は即時決済となるので、ステップ１１２は不要となりスキップされる。

ステップ１１３でクレジット名称と支払回数を確認し決定する。次いでステップ１１４で、ユーザ携帯端末に内蔵されたＱＲコードリーダを起動すると共にカメラ６を起動し、ステップ１１５において、ステップ１０５で業者端末８に表示されたＱＲコードをカメラ６で撮影して読み込む。ステップ１１７で読み込まれたＱＲコードを解析し、ステップ１１８で解析結果がＯＫか否か判定する。ここでＮＯであれば、再びステップ１１５に戻りＱＲコードの読み込みをやり直す。ステップ１１８でＯＫであれば、ユーザ携帯端末１のプロセッサ４の動作は図７のフローへと進む。ユーザ携帯端末のステップ１０７から１１４と業者端末のステップ１０１から１０４は一般にそれぞれ同時並行に進められる。なお、ＱＲコードを用いて説明したがこれに限らず２次元コードであればバーコードであってもよい。また、ＱＲコードではなくユーザが目視できる請求情報を表示し、ユーザが請求情報をユーザ携帯端末に入力することもできる。

図７において、ＱＲコードの解析結果がＯＫであれば、ステップ１２０において、業者端末から取得された請求金額とチップ金額入力欄と合計支払金額とその合計支払金額の承認ボタンが表示される。チップ金額入力欄は当初はゼロが表示され合計支払金額欄には請求金額が表示される。ユーザがチップを支払う場合にはチップ金額入力欄に支払うチップ金額を入力すると、合計支払金額欄は請求金額とチップ金額が加算された金額が表示される。

ステップ１２１では、ユーザは合計支払金額を確認しその支払を了承したとき承認ボタンをクリックする。この承認ボタンのクリック操作をトリガとしてステップ１２２以降の決済処理手続が開始する。

ステップ１２２でユーザ携帯端末に固有の個体識別番号であるユーザ端末ＩＤ２を取り込む。そして、ステップ１２３で、ユーザ端末ＩＤ２、業者ＩＤ、請求金額、チップ金額、合計支払金額、受注明細番号、クレジット名称、支払回数およびセキュリティＩＤを決済データとして運用会社サーバへ送信する。なお、ユーザ端末ＩＤ２およびセキュリティＩＤはユーザ携帯端末を特定すると共にそれを認証するためのものである。セキュリティＩＤはステップ３６でメモリ5に登録されている。決済データを送信する際に、現にメモリ５に登録されているセキュリティＩＤが決済データに付加される。

運用会社サーバ１４は、ステップ１２５において、ユーザ携帯端末１から受信した決済データを一時記憶装置１６に登録する。次いで、ステップ１２６で一時記憶装置に登録されたクレジット名称を読み出して対応するクレジット情報を取得し、これをクレジット会社サーバ１９へ送信してユーザのクレジットカードの与信チェックを依頼する。クレジット会社サーバ１９はステップ１９１で与信チェックを行い、そのチェック結果を与信結果として運用会社サーバ１４へ返信する。運用会社サーバはステップ１２７で与信結果を受信し、これを一時記憶装置１６に登録すると共にユーザ携帯端末へ送信する。ユーザ携帯端末はステップ１２４で与信結果を受信し決済データとして登録して終了する。
図８は、図６における業者端末のステップ１０５でＱＲコードを表示したステップ１２７の後に続くプロセッサ１１の動作を示すフロー図である。

図８において、ステップ１２８で６０秒タイマがスタートする。そして、ステップ１２９で経過時間が６０秒に達したか否かをチェックする。ステップ１２９で経過時間が未だ６０秒に達していなければ、ここでＯＫと判断されステップ１３０に進む。ステップ１３０では、図６のステップ１０４でＱＲコードに含まれた業者ＩＤと合計支払金額と受注明細番号を添付して、これらの情報を含んだ決済データの取得を運用会社サーバ１４に要求する。なお、添付データは取引を特定できる最小限のデータであればよい。

運用会社サーバ１４では、ステップ１３２において、一時記憶装置１６にステップ１２５で保存されたデータの中から業者ＩＤ、請求金額、チップ、合計支払金額、受注明細番号を含む決済データを検索する。ステップ１３３で、検索結果を業者端末に送信する。ステップ１３２の検索において当該決済データを見出すことができなかった時は決済データを含まない検索結果を業者端末へ送信する。

業者端末のステップ１３５で検索結果を受信し、ステップ１３６において受信した検索結果の中にユーザ端末ＩＤ２等を含む決済データが含まれているか否か判断する。ここでＮＯと判断されればステップ１２９へ戻る。このようにして、６０秒の間、一時記憶装置のデータの検索を繰り返し行い、経過時間が６０秒に達すると、ステップ１３８でタイムオーバとなりこの動作を停止する。

ステップ１３２での検索の結果、決済データが見つかった時は、ステップ１３３で決済データを業者端末８へ送信する。ステップ１３６において、ユーザ端末ＩＤ２等の決済データが含まれていると判断されたときは、ステップ１３７へ進む。ここで、業者端末８は運用会社サーバ１４に対してセキュリティチェックを要求する。

運用会社サーバ１４は、ステップ１３９でセキュリティチェック要求を受けたとき、ステップ４０で登録されたユーザ端末ＩＤ１を読み出すと共にステップ１３３で検索された決済データの中からユーザ端末ＩＤ２を読み出し、図９のステップ１４１へ進み、ここでＩＤ１とＩＤ２が比較される。なお、ステップ４０においてユーザ端末ＩＤ１がユーザ端末ＩＤ１ｃにロジック変換されて登録されているときは、同ロジックを使ってユーザ端末ＩＤ２をユーザ端末ＩＤ２ｃに変換し、ステップ１４１でＩＤ１ｃとＩＤ２ｃが比較される。

図９のステップ１４１において、登録されていたユーザ端末ＩＤ１と決済データ中のユーザ端末ＩＤ２を比較し一致しているか否か判断する。ここで、不一致であればステップ１４２で、クレジット決済ができない旨の通知を(4)を通して業者端末に送信する（図８）。そして、業者端末ではステップ１４３でディスプレイ１０にクレジット決済ができない旨の表示がされ処理を終了する。この場合は再度操作をやり直すことになる。これにより、ユーザ自身が新規登録当初に使用したユーザ携帯端末以外の端末からは決済ができないようにしており、他人による不正使用を防いでいる。このセキュリティチェックはユーザ携帯端末の認証を行うものである。

ステップ１４１でＩＤ１とＩＤ２が一致と判断されたときは、ステップ１４４で決済データ中のセキュリティＩＤを読み出し、このセキュリティＩＤを変換ロジックを用いて認証ＩＤ２に変換する。この変換ロジックは図２のステップ３３における変換ロジックと同一のものを用いる。ステップ３３では認証ＩＤ１をセキュリティＩＤに変換したが、ここでは逆にセキュリティＩＤを認証ＩＤ２に変換する。このように変換ロジックを逆方向に変換するために利用できるように設計することは当業者であれば容易になし得ることである。

ステップ１４４では更にステップ４０で登録した認証ＩＤ１をデータベース１５から読み出す。そして、ステップ１４５で、読み出された認証ＩＤ１と変換された認証ＩＤ２が一致しているか否か判断する。ここで一致していないと判断されればステップ１４２へ進み、上記と同様に決済ができない旨の通知を業者端末へ送信する。このように不一致となる場合は、ユーザ携帯端末1から運用会社サーバ１４に送信され一時記憶装置１６に記憶されたセキュリティＩＤが、何らかの理由で新規登録当初のステップ３６において登録されたセキュリティＩＤと異なるものであったことになる。このことは、ユーザ携帯端末を利用する時間の経過の中でセキュリティＩＤが何らかの理由で変化したことを意味する。セキュリティＩＤが変化するのは何らかのトラブルがあったためであり、このチェック機能を備えることによりトラブルの発生時に取引が回避されるようにしている。これによりクレジット決済のセキュリティを向上させている。

一方、ステップ１４５で一致と判断されれば、ユーザ携帯端末が新規登録当初に指定されたセキュリティＩＤが今も正当かつ正常に機能していると判断されたことになる。次いで、ステップ１４６でセキュリティチェックの結果はＯＫである旨の通知を業者端末へ送信する。この場合、セキュリティチェックＯＫの通知に一時記憶装置から読みだした与信結果とクレジット名称を添付してもよい。

一方、業者端末は、ステップ１５０でセキュリティチェックＯＫの通知を受信したとき、ステップ１５１において、ステップ１２４で登録した与信結果を読み出す。なお、ステップ１２４を省略してステップ１３５で受信した与信結果を使うようにしてもよい。そして、ステップ１５２で与信結果は承認であるか否か判定する。ステップ１５２でＮＯと判定されれば、ステップ１５５で運用会社サーバに与信結果がＮＯであること通知する。与信結果ＮＯの通知を受けると、運用会社サーバではステップ１４２において決済不可の通知を業者端末へ送信する。業者端末ではステップ１４３でディスプレイ１０に決済不可の表示をして動作を終了する。このようにユーザの引き落し口座の与信チェックを行い取引の安全を確保することができる。与信が得られない場合は別のクレジットカードを用いて決済手続をするか現金支払いになる。

一方、ステップ１５２でＯＫと判定されたときは、ステップ１５７でクレジット名称を含む決済データを添付して運用会社サーバ１４に支払いを要求する。この支払要求は自動的に行われるが、業者が与信チェックを含むセキュリティチェックＯＫの確認と取引内容の確認後に確認ボタンをクリックして支払要求をしてもよい。

運用会社サーバでは、支払要求を受けたとき、ステップ１６０で受信したクレジット名称からデータベース１５に登録されたクレジット情報を読み出す。そして、ステップ１６１においてクレジット情報と決済データに基づいてクレジット会社サーバ１９との間でクレジット決済手続きを実行する。即ち、クレジット会社は運用会社サーバからの決済要求に従ってクレジット決済を実行し決済完了データを返信する。そして、クレジット会社からクレジット決済完了データを受けると、ステップ１６３へ進み、ここで決済完了データを業者端末８とユーザ携帯端末１へ送信すると共にクレジット完了データを決済履歴としてデータベース１５に登録してフローを終了する。ここでクレジット決済完了データは、業者ＩＤ、決済金額、チップ金額、合計支払金額、受注明細番号、クレジット名称、支払回数およびセキュリティＩＤを含んでいる。なお、ユーザは図４のステップ６５と８２において当該ユーザに係る決済履歴データをデータベース１５から閲覧することができる。業者もまたデータベースに登録された当該業者に係る決済履歴データを閲覧することができる。このことは国際公開公報ＷＯ−Ａ１−２０１３／１６８８１５号に記載されている。

業者端末ではステップ１６３から受信した決済完了データをステップ１６５で受信しディスプレイ１０に決済完了の表示をする。一方、ユーザ携帯端末はステップ１６３から送信された決済完了データをステップ１６７で受信しディスプレイ３に決済完了の表示をする。

以上に説明したシステムを利用して商取引を行うためには、ユーザ携帯端末１および業者端末８はそれぞれこのシステムに従った動作を実行する会員アプリまたは業者アプリを運用会社サーバ１４から予めダウンロードしなければならない。ユーザおよび業者は、運用会社サーバに登録したユーザＩＤとパスワードを用いなければ、自己のユーザ携帯端末または業者端末に会員アプリまたは業者アプリをダウンロードすることができないので、他人が会員アプリまたは業者アプリをダウンロードすることはできない。これにより、不正な商取引が発生することを未然に防いでいる。

以上に説明したシステムを利用した商取引においては、ユーザがクレジット情報を新規登録およびその後に追加登録する際に、機密性の高いクレジット情報を代表するものとしてクレジット名称をクレジット情報とリンクして登録する。それ以降に行われる商取引では、クレジット情報を業者に提示することなくクレジット名称を用いて決済取引ができるようにしている。このため、機密保持が必要なクレジット情報は業者端末に知らせることがないのでその拡散を防止できる。結果として、クレジット情報が他人により不正に使用される恐れを大幅に減らすことができる。

また、上記実施例においては、ユーザが新規登録する際に、会員ＩＤとセキュリティＩＤの作成を運用会社サーバに依頼し、その結果、会員ＩＤとセキュリティＩＤが運用会社サーバおよびユーザ携帯端末に登録されているので、それ以降は、会員ＩＤまたはセキュリティＩＤはユーザの個人認証としてまたはユーザ携帯端末を特定するための情報として利用することができる。

更に、ユーザが新規登録する際に、ユーザ携帯端末自体に固有に与えられている個体識別番号を読み込み、これをユーザ端末ＩＤ１として運用会社サーバのデータベースに登録し、それ以降に行われる商取引毎に、個体識別番号をユーザ端末ＩＤ２として自動的に読み出し、ＩＤ１とＩＤ２を比較することによってユーザ携帯端末を認証チェックしているので、所定のユーザ携帯端末を利用した取引に対してのみクレジット決済を許容している。従って、他人が会員ＩＤ、パスワードまたはセキュリティＩＤを盗用したとしても、ユーザ端末ＩＤ１を有する携帯端末以外の携帯端末ではクレジット決済をすることができないようにしている。

更に、以上に説明したシステムを利用した商取引においては、商品購入の合意ができた後、業者が業者端末に請求金額等を入力すると、業者端末は、請求金額、業者ＩＤ等の取引に必要な商品データを含んだＱＲコード等の二次元的コードを作成してディスプレイに表示する。ユーザ携帯端末は、表示されたＱＲコードを内蔵のカメラで撮影し、これを解析してディスプレイに請求金額等を表示する。ユーザは請求金額等を確認し承認ボタンをクリックすると、商品データにユーザのクレジット名称等を付加した決済データが運用会社サーバの一時記憶装置に登録される。そして、運用会社は一時記憶装置に登録されたクレジット名称からクレジット情報を読み出し、これをクレジット会社へ送信し与信承認チェックを求める。運用会社は、クレジット会社の与信承認チェックの結果としての与信結果を取得し、この与信結果を用いてユーザの引き落し口座の与信を確認後に決済取引するので、決済取引の安全を確保できる。

上記実施例では、ユーザの操作はＱＲコードを読み取り承認ボタンをクリックするだけであり、また業者の操作は商品情報を提示するだけであるから、ユーザ携帯端末と業者端末と運用会社サーバとの間の通信手順は必要最小限に単純化することができ、特に、ユーザと業者間での通信は一回のみに単純化してクレジット決済が完結する。

以上の説明では、クレジット決済について例を取って説明したが、これに限らずデビットカードあるいはデビットカード機能を備えたキャッシュカードを用いることができる。また、運用会社サーバがクレジット会社との間で決済取引を実行する場合を説明したが、クレジット会社に限らず銀行を含む一般的な金融機関であってもよい。

なお、実施例ではクレジット決済を例にして説明しているため、クレジット情報の語を用いたが、デビットカード情報も含む概念としてカード情報の語を用いてもよい。但し、クレジットカード等のカードを発行することなくカード情報に相当する情報をユーザ携帯端末にダウンロードすることにより本発明のシステムを実行することができるので、カードが発行されない場合であっても、当該情報をカード情報と称することにする。同様に、複数のカードの内の１つを指定する場合においても、カードの発行がなくてもカード指定の語を用いる。また、上記説明ではクレジット名称の語を用いているが、デビットカードやキャッシュカード等の決済情報およびカードを発行しない決済情報を代表するニックネームとしてカード名称の語を用いる。

上記の実施例では、店頭で商品を購入する場合を想定して説明したが、レストランやサービス業における支払にも適用できるし、インターネットを介したネット取引にも適用することができる。

また、上記実施例ではユーザ携帯端末を用いて支払決済をする場合について説明したが、例えば、自宅でネット取引を行う場合は設置型のパソコンを用いることもできる。この場合、ユーザは業者端末から送信されたＱＲコードを自宅のパソコンのディスプレイ上に表示し、その表示されたＱＲコードをユーザ携帯端末で読み取ることにより取引を行うことがでる。このようにＱＲコードは、業者端末のディスプレイ、ユーザのパソコンのディスプレイまたは第三者のパソコンのディスプレイに表示されてもよく、いずれかのパソコンに表示されたＱＲコードをユーザ携帯端末で撮像することにより本発明に係るシステムでの商取引を遂行することができる。
なお、本発明の精神を逸脱することなく種々の変更をすることができる。

１ ユーザ携帯端末
２ 入力装置
３ ディスプレイ
４ プロセッサ
５ メモリ
６ カメラ
８ 業者端末
９ 入力装置
１０ ディスプレイ
１１ プロセッサ
１２ メモリ
１４ 運用会社サーバ
１５ データベース
１６ 一時記憶装置
１７ プロセッサ
１９ クレジット会社サーバ
２０ データベース

Claims (12)

1. 請求金額を含む請求情報を二次元コードに変換してディスプレイに表示する業者端末（８）と、
   該二次元コードを撮像し解析して請求情報をディスプレイに表示し、該請求情報を承認したとき、ユーザ特定ＩＤを含む決済のために必要な決済データを運用会社サーバへ送信するユーザ携帯端末（１）と、
   前記業者端末に係る業者情報および前記ユーザ携帯端末に係る会員情報を登録したデータベース（１５）と、前記ユーザ携帯端末から受信した前記決済データを記憶する一時記憶装置（１６）を有する運用会社サーバ（１４）と、
   を備え、
   前記運用会社サーバは、前記一時記憶装置に記憶された前記決済データ中の前記ユーザ特定ＩＤと前記データベースに登録された会員情報に基づき前記ユーザ携帯端末のセキュリティチェックを行い、そのセキュリティチェックの結果が適合であれば、前記決済データに基づき金融機関との間で決済手続を実行し、決済が完了したときに決済完了通知を前記業者端末へ送信する、
   運用会社サーバは、業者登録をするときに、業者ＩＤを作成しデータベースに業者情報として登録し、該業者ＩＤを業者端末へ送信し、
   業者端末は、受信した業者ＩＤをメモリに登録し、該業者ＩＤを含む前記二次元コードを表示した後、前記運用会社サーバに前記請求金額と前記業者ＩＤを添付して前記一時記憶装置に登録された前記決済データの検索を要求し、その検索の結果前記決済データの存在が確認できたときは前記セキュリティチェックを依頼し、
   前記運用会社サーバは、セキュリティチェック依頼を受けたとき、前記セキュリティチェックを行う、
   携帯端末を利用した決済システム。
2. 請求項１において、
   前記ユーザ特定ＩＤはユーザ携帯端末の個体識別番号に係るユーザ端末ＩＤ２であって、
   前記セキュリティチェックは、前記ユーザ端末ＩＤ２と、前記会員情報に含まれたユーザ端末ＩＤ１であって予め当該ユーザ携帯端末から取得し運用会社サーバのデータベースに登録された該ユーザ端末ＩＤ１と、を比較することにより行われる、前記決済システム。
3. 請求項１において、
   前記ユーザ特定ＩＤは新規会員登録の際に運用会社サーバから付与されユーザ携帯端末のメモリに保存したセキュリティＩＤであって、
   前記セキュリティチェックは、前記一時記憶装置に記憶されたセキュリティＩＤと前記運用会社が付与した際に前記データベースに登録されたセキュリティＩＤとを比較することにより行われる、前記決済システム。
4. 請求項１において、
   前記運用会社サーバは、ユーザの新規会員登録の際に、認証ＩＤ１を設定し、この認証ＩＤ１を所定の変換ロジックを用いてセキュリティＩＤに変換し、該認証ＩＤ１と該セキュリティＩＤを新規登録データとリンクして前記会員情報として前記データベースに登録すると共に、このセキュリティＩＤを前記ユーザ携帯端末に送信し、
   前記ユーザ携帯端末は、受信した前記セキュリティＩＤをメモリに登録し、
   前記ユーザ特定ＩＤは前記メモリに登録されているセキュリティＩＤであって、
   前記運用会社サーバは前記セキュリティＩＤを前記変換ロジックを用いて認証ＩＤ２に変換し、該認証ＩＤ２と前記データベースから読み出された前記認証ＩＤ１とを比較することによりセキュリティチェックを行う、前記決済システム。
5. 請求項１において、
   前記運用会社サーバは、予めデータベースにユーザの１つまたは複数個のカード情報と各カード情報を指称するカード名称をリンクして前記会員情報として登録し、
   前記決済データは１つまたは複数個のカード名称の１つを指定するカード指定情報を含み、
   前記運用会社サーバは、前記決済データ中の前記カード指定情報に基づき前記データベースからカード情報を取得し、該カード情報に基づき金融機関との間で決済手続を実行する、前記決済システム。
6. 請求項５において、
   前記ユーザ携帯端末は、予めカード名称ＩＤを登録しておき、このカード名称ＩＤを入力したとき、前記カード名称を指定する画面がディスプレイ上に表示されるようにした、前記決済システム。
7. 請求項１において、
   前記運用会社サーバは、前記検索の依頼を受けたとき前記請求金額と前記業者ＩＤを含む決済データの存在を検索し、そして、前記セキュリティチェックの依頼を受けたときは前記決済データ中の前記ユーザ特定ＩＤに基づきセキュリティチェックを行う、前記決済システム。
8. 請求項１において、
   前記二次元コードはＱＲコードである（１０４、１０５、１１５）、前記決済システム。
9. 請求項１において、
   前記ユーザ携帯端末において、前記請求情報を承認する操作がされたとき、この操作をトリガとして前記運用会社は前記業者端末と前記金融機関との間で決済手続を開始する、前記決済システム。
10. 請求項1において、
    前記運用会社サーバは、前記ユーザ携帯端末から前記決済データを受信したとき、該決済データを前記一時記憶装置に登録すると共に前記金融機関に該決済データに係る与信チェックを依頼し、該金融機関から返信された与信結果を前記一時記憶装置に登録し、該与信結果が適合である場合は前記決済手続を実行する、前記決済システム。
11. 請求項１０において、
    前記業者端末は前記運用会社サーバの一時記憶装置から前記与信結果を取得し、該与信結果が適合であるときに前記運用会社に前記請求金額の支払要求をし、
    前記運用会社は該支払要求を受けたときに前記決済手続を実行する、前記決済システム。
12. 請求項１０において、
    前記業者端末は前記一時記憶装置から前記与信結果と共に前記決済データを取得したとき前記運用会社サーバにセキュリティチェックを依頼し、そのセキュリティチェック結果が適合の返信を受けたときに前記支払要求をする、前記決済システム。