特許 5740050 情報処理装置、情報処理方法、および情報処理プログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5740050

(24)【登録日】2015年5月1日

(45)【発行日】2015年6月24日

(54)【発明の名称】情報処理装置、情報処理方法、および情報処理プログラム

(51)【国際特許分類】

   G06Q 20/16 20120101AFI20150604BHJP

   G06Q 20/24 20120101ALI20150604BHJP

【ＦＩ】

   G06Q20/16 100

   G06Q20/24

【請求項の数】6

【全頁数】17

(21)【出願番号】特願2014-519735(P2014-519735)

(86)(22)【出願日】2013年4月30日

(86)【国際出願番号】JP2013062659

(87)【国際公開番号】WO2014178128

(87)【国際公開日】20141106

【審査請求日】2014年4月23日

【早期審査対象出願】

(73)【特許権者】

【識別番号】399037405

【氏名又は名称】楽天株式会社

(74)【代理人】

【識別番号】100088155

【弁理士】

【氏名又は名称】長谷川 芳樹

(74)【代理人】

【識別番号】100113435

【弁理士】

【氏名又は名称】黒木 義樹

(74)【代理人】

【識別番号】100144440

【弁理士】

【氏名又は名称】保坂 一之

(72)【発明者】

【氏名】飛内 英明

【審査官】 山本 雅士

(56)【参考文献】

【文献】 特開２０１０−２７７５３８（ＪＰ，Ａ）

【文献】 特開２００２−３２４１９９（ＪＰ，Ａ）

【文献】 特開２００９−２０５４３４（ＪＰ，Ａ）

【文献】 特開２００７−０９４８４４（ＪＰ，Ａ）

【文献】 特開２０１３−０１５８８１（ＪＰ，Ａ）

【文献】 特開２００３−１３２４００（ＪＰ，Ａ）

【文献】 特開２０１０−０７２８２０（ＪＰ，Ａ）

【文献】 特開２０１０−２５０４９８（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｑ １０／００ − ５０／３４

(57)【特許請求の範囲】

【請求項1】

クレジットカードを持たないユーザの端末から商取引での支払代行要求を受け付けたことに応じて、金銭に対応付けることが可能なポイントを記憶するポイント記憶部から、該商取引の決済金額に相当する該ユーザの保有ポイントを確保することで、該決済金額に相当する該保有ポイントが他の支払いに用いられないようにする確保部と、
クレジットカードと同様に利用可能な前払型支払手段の一回限り利用可能なカード番号を取得し、前記確保部により確保された保有ポイントに基づいて前記決済金額と同額の利用限度額を設定することで、該利用限度額が設定された該カード番号を含む該前払型支払手段のカード情報を前記商取引の決済のために提供する提供部とを備える情報処理装置。

【請求項2】

前記提供部が、前記商取引の決済のために前記カード情報を前記端末に送信する、
請求項１に記載の情報処理装置。

【請求項3】

前記提供部が、
前記カード情報とは異なるダミー情報を生成し、
前記カード情報を送信することなく、該端末に前記ダミー情報を送信し、
前記商取引において前記端末から前記ダミー情報を受信した受注処理装置からの要求に応じて、該ダミー情報に対応する前記カード情報を該受注処理装置に提供する、
請求項１に記載の情報処理装置。

【請求項4】

前記確保部が、前記ポイントが確保されたことを示す決済状況情報を前記端末に送信し、
前記提供部が、前記商取引において前記端末から前記決済状況情報を受信した受注処理装置からの要求に応じて、該決済状況情報に対応する前記カード情報を該受注処理装置に提供する、
請求項１に記載の情報処理装置。

【請求項5】

プロセッサを備える情報処理装置により実行される情報処理方法であって、
クレジットカードを持たないユーザの端末から商取引での支払代行要求を受け付けたことに応じて、金銭に対応付けることが可能なポイントを記憶するポイント記憶部から、該商取引の決済金額に相当する該ユーザの保有ポイントを確保することで、該決済金額に相当する該保有ポイントが他の支払いに用いられないようにする確保ステップと、
クレジットカードと同様に利用可能な前払型支払手段の一回限り利用可能なカード番号を取得し、前記確保ステップにおいて確保された保有ポイントに基づいて前記決済金額と同額の利用限度額を設定することで、該利用限度額が設定された該カード番号を含む該前払型支払手段のカード情報を前記商取引の決済のために提供する提供ステップとを含む情報処理方法。

【請求項6】

クレジットカードを持たないユーザの端末から商取引での支払代行要求を受け付けたことに応じて、金銭に対応付けることが可能なポイントを記憶するポイント記憶部から、該商取引の決済金額に相当する該ユーザの保有ポイントを確保することで、該決済金額に相当する該保有ポイントが他の支払いに用いられないようにする確保部と、
クレジットカードと同様に利用可能な前払型支払手段の一回限り利用可能なカード番号を取得し、前記確保部により確保された保有ポイントに基づいて前記決済金額と同額の利用限度額を設定することで、該利用限度額が設定された該カード番号を含む該前払型支払手段のカード情報を前記商取引の決済のために提供する提供部としてコンピュータを機能させるための情報処理プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明の一側面は、電子商取引での支払代行を実行する装置、方法、およびプログラムに関する。

【背景技術】

【0002】

従来から、クレジットカードによる決済を必須とする店舗があり、そのような店舗は特にオンライン上に多い。その店舗と取引をして支払いを行う際には、ユーザは自己のクレジットカードの情報（カード番号、名義、有効期限、セキュリティ・コードなど）を決済関連情報として当該店舗に提供する必要がある。

【0003】

このような取引の態様に関し、ユーザに代わってクレジットカードによる決済を行う仕組みが知られている。例えば下記特許文献１には、決済代行サービス機関に登録加入するだけで、多数の店舗において指定の決済手段に関わらず決済を可能とするクレジット決済代行サーバが記載されている。このサーバは、クライアントからのアクセスに応じて、クレジット決済の依頼入力及びサイト選択入力を催告する画面情報を該クライアントに送信する手段と、該クライアントからのサイト選択入力に応じて、該クレジット決済における債権者のサイト画面を該クライアントに向けて中継する中継手段と、該クライアントからの該依頼入力に応じて、該クレジット決済に用い得る決済番号を該サイト画面に転送する転送手段とを含む。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】特開２００２−１３３３３４号公報

【発明の概要】

【発明が解決しようとする課題】

【0005】

しかしながら、上記特許文献１に記載の仕組みでは、他の取引の決済にもそのまま利用し得る決済関連情報（債務通知情報）をユーザ端末に提供する仕様を採用している。ユーザ端末の表示画面に決済関連情報を表示させない場合や、ワンタイムの決済関連情報（クレジットカード番号）を発行する場合でも、ユーザ端末に決済関連情報を提供する点は変わらない。そのため、ユーザ端末に提供された決済関連情報が決済サービスの提供者の想定しない取引の決済に利用され、損失が発生する可能性がある。

【0006】

そこで、ユーザが店舗に支払うべき金銭をユーザから受領して店舗に納付する決済サービスにおいて、当該サービスの提供者が不測の損失を被るリスクを軽減することが望まれている。

【課題を解決するための手段】

【0007】

本発明の一側面に係る情報処理装置は、商取引を成立させるために必要な情報を受注処理装置に提供するユーザ端末からの代行要求に関連付けて、当該商取引に係る決済金額に相当する価値を当該商取引が成立する前に確保する確保部と、確保された価値を特定するための価値特定データを、商取引に係る決済金額を支払うための支払手段を特定する決済関連情報として、ユーザ端末を介して受注処理装置に提供する価値特定データ提供部とを備える。

【0008】

本発明の一側面に係る情報処理方法は、商取引を成立させるために必要な情報を受注処理装置に提供するユーザ端末からの代行要求に関連付けて、当該商取引に係る決済金額に相当する価値を当該商取引が成立する前に確保する確保ステップと、確保された価値を特定するための価値特定データを、商取引に係る決済金額を支払うための支払手段を特定する決済関連情報として、ユーザ端末を介して受注処理装置に提供する価値特定データ提供ステップとを含む。

【0009】

本発明の一側面に係る情報処理プログラムは、商取引を成立させるために必要な情報を受注処理装置に提供するユーザ端末からの代行要求に関連付けて、当該商取引に係る決済金額に相当する価値を当該商取引が成立する前に確保する確保部と、確保された価値を特定するための価値特定データを、商取引に係る決済金額を支払うための支払手段を特定する決済関連情報として、ユーザ端末を介して受注処理装置に提供する価値特定データ提供部とをコンピュータに実行させる。

【0010】

本発明の一側面に係るコンピュータ読取可能な記録媒体は、商取引を成立させるために必要な情報を受注処理装置に提供するユーザ端末からの代行要求に関連付けて、当該商取引に係る決済金額に相当する価値を当該商取引が成立する前に確保する確保部と、確保された価値を特定するための価値特定データを、商取引に係る決済金額を支払うための支払手段を特定する決済関連情報として、ユーザ端末を介して受注処理装置に提供する価値特定データ提供部とをコンピュータに実行させる情報処理プログラムを記憶する。

【0011】

このような側面においては、商取引の決済金額に相当する価値が確保されるので、決済サービスの提供者はその確保した価値を受注処理装置の運営者（店舗）に支払えばよい。したがって、ユーザが店舗に支払うべき金銭をユーザから受領して店舗に納付する決済サービスにおいて、当該サービスの提供者が被るリスクを軽減することができる。

【0012】

他の側面に係る情報処理装置では、クレジットカードのカード番号と同一形式のＩＤ情報であってクレジットカードの加盟店においてクレジットカードと同様に利用可能な前払型支払手段のＩＤ情報を取得し、該ＩＤ情報と価値特定データとを関連付けて記憶部に記憶させる第１記録部と、受注処理装置から価値特定データを受信した場合に、該価値特定データに対応付けて記憶部に記憶されている又は記憶されるべきＩＤ情報を該受注処理装置に提供するＩＤ情報提供部とをさらに備えてもよい。

【0013】

他の側面に係る情報処理装置では、価値特定データが、カード番号と同一形式でありかつＩＤ情報と異なるダミー番号であり、ダミー番号を、一回に限り利用できる番号として、決済処理装置に記憶させる第２記録部をさらに備えてもよい。

【0014】

他の側面に係る情報処理装置では、価値特定データが、受注処理装置ごとに割り当てられるダミー番号と、商取引ごとに設定される付属情報とを含んでもよい。

【0015】

他の側面に係る情報処理装置では、価値特定データ提供部が、ユーザ端末に、受注処理装置に提供されるべき決済関連情報を入力するためのウェブページに配置される所定の入力欄にダミー番号および付属情報を自動的に挿入させてもよい。

【0016】

他の側面に係る情報処理装置では、価値特定データが、商取引の決済金額に相当する価値が確保されたことを示す決済状況情報であり、価値特定データ提供部が、ユーザ端末に、受注処理装置に送信されるべき情報を記憶する端末記憶部に決済状況情報を記憶させてもよい。

【0017】

他の側面に係る情報処理装置では、価値特定データ提供部が、ユーザ端末に、受注処理装置に提供されるべき決済関連情報を入力するためのウェブページに配置される所定の入力欄を無効にさせてもよい。

【0018】

他の側面に係る情報処理装置では、ＩＤ情報提供部が、受注処理装置から価値特定データを受信した後にＩＤ情報を取得してもよい。

【0019】

他の側面に係る情報処理装置では、クレジットカードのカード番号と同一形式のＩＤ情報であってクレジットカードの加盟店において確保された価値を上限とする範囲内で一回に限りクレジットカードと同様に利用可能な前払型支払手段のＩＤ情報を取得する取得部をさらに備え、価値特定データが、取得部により取得されるＩＤ情報であってもよい。
本発明の一側面に係る情報処理装置は、クレジットカードを持たないユーザの端末から商取引での支払代行要求を受け付けたことに応じて、該商取引の決済金額に相当する該ユーザの保有ポイントをポイント記憶部から確保する確保部と、クレジットカードと同様に利用可能な前払型支払手段のカード番号を取得し、確保部により確保された保有ポイントに基づく利用限度額を設定することで、該カード番号および該利用限度額を含む該前払型支払手段のカード情報を商取引の決済のために提供する提供部とを備える。
本発明の一側面に係る情報処理方法は、プロセッサを備える情報処理装置により実行される情報処理方法であって、クレジットカードを持たないユーザの端末から商取引での支払代行要求を受け付けたことに応じて、該商取引の決済金額に相当する該ユーザの保有ポイントをポイント記憶部から確保する確保ステップと、クレジットカードと同様に利用可能な前払型支払手段のカード番号を取得し、確保ステップにおいて確保された保有ポイントに基づく利用限度額を設定することで、該カード番号および該利用限度額を含む該前払型支払手段のカード情報を商取引の決済のために提供する提供ステップとを含む。
本発明の一側面に係る情報処理プログラムは、クレジットカードを持たないユーザの端末から商取引での支払代行要求を受け付けたことに応じて、該商取引の決済金額に相当する該ユーザの保有ポイントをポイント記憶部から確保する確保部と、クレジットカードと同様に利用可能な前払型支払手段のカード番号を取得し、確保部により確保された保有ポイントに基づく利用限度額を設定することで、該カード番号および該利用限度額を含む該前払型支払手段のカード情報を商取引の決済のために提供する提供部としてコンピュータを機能させる。
他の側面に係る情報処理装置では、カード番号が一回に限り利用可能であってもよい。
他の側面に係る情報処理装置では、提供部が、商取引の決済のためにカード情報を端末に送信してもよい。
他の側面に係る情報処理装置では、提供部が、カード情報とは異なるダミー情報を生成し、カード情報を送信することなく、該端末にダミー情報を送信し、商取引において端末からダミー情報を受信した受注処理装置からの要求に応じて、該ダミー情報に対応するカード情報を該受注処理装置に提供してもよい。
他の側面に係る情報処理装置では、確保部が、ポイントが確保されたことを示す決済状況情報を端末に送信し、提供部が、商取引において端末から決済状況情報を受信した受注処理装置からの要求に応じて、該決済状況情報に対応するカード情報を該受注処理装置に提供してもよい。

【発明の効果】

【0020】

本発明の一側面によれば、ユーザが店舗に支払うべき金銭をユーザから受領して店舗に納付する決済サービスにおいて、当該サービスの提供者が不測の損失を被るリスクを軽減することができる。

【図面の簡単な説明】

【0021】

【図1】実施形態に係る電子商取引システム（ＥＣシステム）の全体構成を示す図である。

【図2】図１に示す支払代行サーバのハードウェア構成を示す図である。

【図3】図１に示す支払代行サーバの機能構成を示すブロック図である。

【図4】第１実施形態に係るＥＣシステムの動作を示すシーケンス図である。

【図5】第１実施形態に係るＥＣシステムの動作を示すシーケンス図である。

【図6】第２実施形態に係るＥＣシステムの動作を示すシーケンス図である。

【図7】第２実施形態に係るＥＣシステムの動作を示すシーケンス図である。

【図8】第３実施形態に係るＥＣシステムの動作を示すシーケンス図である。

【図9】第３実施形態に係るＥＣシステムの動作を示すシーケンス図である。

【図10】実施形態に係る情報処理プログラムの構成を示す図である。

【発明を実施するための形態】

【0022】

以下、添付図面を参照しながら本発明の実施形態を詳細に説明する。なお、図面の説明において同一又は同等の要素には同一の符号を付し、重複する説明を省略する。

【0023】

（第１実施形態）
第１実施形態に係る電子商取引システム（ＥＣシステム）１について説明する。このＥＣシステム１は、クレジットカードを持たないユーザもクレジット決済が必須のオンライン・ショッピング・サイト（ＥＣサイト）で商取引ができる仕組みを備えたコンピュータ・システムである。

【0024】

ユーザは購入したい商品をオンライン・ショッピング・サイトで選択して決済手続を行う。このサイトではクレジットカードでの決済が必須なので、通常であればユーザはクレジットカードを所持していないと購入手続を済ませることができない。しかし本実施形態では、クレジットカードを持たないユーザはそのサイトでクレジット払いの代行（以下では「支払代行」という）を選択して、バーチャルプリペイドカードの情報を支払代行会社から取得する。バーチャルプリペイドカードとはクレジットカードの仕組みを利用した前払型支払手段であり、クレジットカードと同様のカード番号および付属情報（有効期限およびセキュリティ・コード）で定義される。ユーザはそのカード情報を用いることで、クレジットカード保有者と同様にそのサイトで商品を購入することができる。支払代行会社は、ユーザが店舗に支払うべき金銭をユーザから受領して店舗に納付する決済サービス（支払代行サービス）を提供する。

【0025】

図１に示すように、ＥＣシステム１はユーザ端末Ｔｕ、支払代行サーバ（情報処理装置）１０、受注サーバ（受注処理装置）２０、および決済サーバ（決済処理装置）３０を備えている。これらのサーバ１０，２０，３０はそれぞれ、対応のデータベース（記憶装置）Ｄ１０，Ｄ２０，Ｄ３０と連携する。

【0026】

ユーザ端末Ｔｕ、支払代行サーバ１０、および受注サーバ２０はインターネットなどのネットワークを介して相互接続されている。支払代行サーバ１０、受注サーバ２０、および決済サーバ３０はインターネットや専用線などのネットワークを介して相互接続されている。支払代行サーバ１０はインターネットや専用線などのネットワークを介してデータベースＤ１０に直接または間接的にアクセスできる。受注サーバ２０は同様のネットワークを介してデータベースＤ２０に直接または間接的にアクセスできる。決済サーバ３０は同様のネットワークを介してデータベースＤ３０に直接または間接的にアクセスできる。各データベースＤ１０，Ｄ２０，Ｄ３０はそれぞれ、互いに同期する機能を有する複数の記憶装置で構成されていてもよい。なお、ＥＣシステム１におけるユーザ端末Ｔｕおよび各サーバの台数はいくつでもよい。

【0027】

ユーザ端末Ｔｕは、オンサイン・ショッピング・サイトのユーザが使用する端末である。ユーザ端末Ｔｕは商品購入のためのユーザ操作に応じて受注サーバ２０にＨＴＴＰリクエストを送信し、そのリクエストに応じて受注サーバ２０から送られてきた各種のウェブページ（ＨＴＴＰレスポンス）をディスプレイ上に表示する。一連の購入手続の中でユーザ端末Ｔｕは支払代行サーバ１０と通信することで決済に必要な情報を取得するが、この支払代行に関する処理については後述する。ユーザ端末Ｔｕの種類は限定されず、例えば据置型又は携帯型のパーソナルコンピュータでもよいし、高機能携帯電話機（スマートフォン）や携帯電話機、携帯情報端末（ＰＤＡ）などの携帯端末でもよい。

【0028】

受注サーバ２０は、オンライン・ショッピング・サイトをユーザに提供するコンピュータである。受注サーバ２０の運営者は個々の店舗であってもよいし、オンライン・ショッピング・モールの管理者であってもよい。受注サーバ２０はユーザ端末ＴｕからのＨＴＴＰリクエストに応じてそのサイトのウェブページをデータベースＤ２０から読み出してユーザ端末Ｔｕに送信する。例えば、受注サーバ２０は商品ページや、買い物かごページ、決済手続のページ（決済ページ）、購入の最終確認を行うためのページ（確認ページ）などをユーザ端末Ｔｕに提供するが、ユーザ端末Ｔｕに提供されるウェブページはこれらに限定されない。

【0029】

決済ページは、商取引の決済手段を特定するための決済関連情報をユーザ端末Ｔｕから受注サーバ２０に送信するためのウェブページである。この決済ページは、クレジットカードで決済するか、それとも支払代行を依頼するかをユーザに選択させるためのユーザ・インタフェースを備えている。このインタフェースは例えばＪａｖａＳｃｒｉｐｔ（商標または登録商標）により実現可能であるが、実現手法はこれに限定されない。

【0030】

決済サーバ３０は、クレジットカードまたはバーチャルプリペイドカードによる決済を実行するコンピュータであり、クレジット会社により運営される。この決済サーバ３０は下記の機能を備える。

【0031】

・クレジットカードまたはバーチャルプリペイドカードを発行する機能。
・加盟店（受注サーバ２０の運営者）から送信される照会情報に含まれる照会金額が、当該照会情報に係る支払者に対応するカード番号の利用可能額以下である場合に限り、承認情報を返信する機能。承認情報は、照会金額が利用可能額以下であり、かつ、カード番号が有効である場合に限って返信されてもよい。
・承認情報を返信した場合に利用可能額から照会金額が減額されるよう、カード番号に対応するデータを変更する機能。
・カード番号に対応するユーザから回収される資金を加盟店に納付するための決済処理を加盟店からの売上情報に基づいて行う機能。

【0032】

支払代行サーバ１０は、支払代行に関する処理を実行するコンピュータであり、支払代行会社により運営される。オンライン・ショッピング・サイトの運営者またはクレジット会社が支払代行サーバ１０を管理してもよい。

【0033】

支払代行サーバ１０のハードウェア構成を図２に示す。支払代行サーバ１０は、オペレーティングシステムやアプリケーション・プログラムなどを実行する１以上のＣＰＵ１０１と、ＲＯＭおよびＲＡＭで構成される主記憶部１０２と、ハードディスクやフラッシュメモリなどで構成される補助記憶部１０３と、ネットワークカードあるいは無線通信モジュールで構成される通信制御部１０４と、キーボードやマウスなどの入力装置１０５と、ディスプレイなどの出力装置１０６とを備えている。

【0034】

後述する支払代行サーバ１０の各機能的構成要素は、ＣＰＵ１０１又は主記憶部１０２の上に所定のソフトウェアを読み込ませ、ＣＰＵ１０１の制御の下で通信制御部１０４や入力装置１０５、出力装置１０６などを動作させ、主記憶部１０２又は補助記憶部１０３におけるデータの読み出しおよび書き込みを行うことで実現される。処理に必要なデータやカードデータベースは主記憶部１０２又は補助記憶部１０３内に格納される。

【0035】

図２では支払代行サーバ１０が１台のコンピュータで構成されているが、支払代行サーバ１０は複数台のコンピュータで構成されていてもよい。

【0036】

図３に示すように、支払代行サーバ１０は機能的構成要素として受付部１１、確保部１２、および番号提供部１３を備える。本発明において番号提供部１３は価値特定データ提供部、第１記録部、ＩＤ情報提供部、第２記録部、および取得部として機能し得る。

【0037】

受付部１１は、支払代行の依頼をユーザ端末Ｔｕから受け付ける機能要素である。ユーザが決済ページで支払代行を選択すると、ユーザ端末Ｔｕは支払代行サーバ１０に支払代行要求を送信する。支払代行要求は、オンライン・ショッピング・サイト上での商取引の決済金額（購入金額）とを少なくとも含む信号である。受付部１１はその決済金額を確保部１２に出力する。

【0038】

確保部１２は、商取引の決済金額に相当する価値を確保する機能要素である。ここで「価値の確保」とは、ユーザが保有する価値（金銭、ポイント、クレジット会社による与信など）のうちクレジット会社への支払金に相当する分をデータベースＤ１０などの記録媒体に記録することで、その支払金に相当する価値が他の支払いに用いられないようにする処理である。

【0039】

確保の手法は価値の種類によって異なる。例えば、価値が金銭であれば、確保部１２はユーザから金融機関に払い込まれた前払金の金額を金融機関サーバ（図示せず）に問い合わせることで、決済金額に相当する金銭を確保してもよい。この場合には、確保部１２は支払代行要求に関連する受付番号を含む問合せ信号を金融機関サーバに送信し、その受付番号に対応する前払金額のデータを金融機関サーバから受信する。

【0040】

価値がポイントであれば、確保部１２は各ユーザのポイントを記憶するポイント・データベースにアクセスして、決済金額に相当するポイントを確保してもよい。この際に、確保部１２は変換レートを用いてポイントを金銭に変換してもよい。なお、データベースＤ１０がポイント・データベースを兼ねてもよい。この場合には、確保部１２はユーザＩＤに対応するポイントデータをポイント・データベースから読み出すことで、ユーザのポイントを取得する。

【0041】

価値がクレジット会社による与信であれば、確保部１２は、支払代行の対価をユーザのクレジットカードで支払うことをクレジット会社に保証する通知を決済サーバ３０に送信し、その保証に対する与信を決済サーバ３０から取得する。

【0042】

このように価値を確保する手法は様々であるが、いずれにしても確保部１２は確保した価値を番号提供部１３に出力する。

【0043】

番号提供部１３は、クレジット決済に必要なカード情報を提供する機能要素である。カード情報はバーチャルプリペイドカードのカード番号および付属情報を含み、付属情報は有効期限およびセキュリティ・コードを含む。バーチャルプリペイドカードのカード番号は、クレジットカードと同一形式のＩＤ情報であり、利用限度額の範囲内で利用できる番号である。本実施形態ではそのカード番号は一回に限り利用できる。このカード番号には、確保部１２により確保された価値が利用限度額として設定される。したがって、本実施形態ではこのカード番号が価値特定データである。

【0044】

番号提供部１３は確保した価値とを含む発行要求を生成して決済サーバ３０に送信する。決済サーバ３０はその要求に応じて、一つのカード番号を割り当てると共にそのカード番号の有効期限、セキュリティ・コード、および利用限度額を設定する。また、決済サーバ３０はカード番号、付属情報（有効期限およびセキュリティ・コード）をカード情報として支払代行サーバ１０に送信する。また、決済サーバ３０は利用限度額が更に関連付けられたそのカード情報をデータベースＤ３０に格納する。

【0045】

番号提供部１３は受信したカード情報を確保した価値と関連付けてデータベースＤ１０に格納すると共に、そのカード情報をユーザ端末Ｔｕに送信する。ユーザ端末Ｔｕはそのカード情報を受信して決済ページ上の入力欄に設定する。このようにカード情報が自動的に挿入されることで、ユーザはカード情報の入力を省略して、決済を確定する操作を実行する。この決済操作およびその後に行われる一連の処理（例えば、入力内容の確認から注文完了通知までの処理）は、クレジットカードを用いた従来の購入処理と同様である。

【0046】

次に、図４，５を用いて、ＥＣシステム１の動作を説明するとともに本実施形態に係る情報処理方法について説明する。

【0047】

オンライン・ショッピング・サイト上でのユーザ操作に応じてユーザ端末Ｔｕと受注サーバ２０との間で商品検索や商品選択などの前処理が実行され（ステップＳ１０１）、その後ユーザが決済ページで支払代行を選択すると（ステップＳ１０２）、ユーザ端末Ｔｕは支払代行要求を支払代行サーバ１０に送信する（ステップＳ１０３）。

【0048】

支払代行サーバ１０では、受付部１１がその支払代行要求を受け付け、確保部１２がその申請で示される決済金額に相当する価値を確保する（ステップＳ１０４、確保ステップ）。続いて、番号提供部１３が発行要求を決済サーバ３０に送信し（ステップＳ１０５）、その要求に応じて決済サーバ３０から送られてきたカード情報（カード番号および付属情報）を受信する（ステップＳ１０６）。これらステップＳ１０５，Ｓ１０６の処理に関連して、番号提供部１３および決済サーバ３０はカード情報をデータベースＤ１０，Ｄ３０にそれぞれ記憶する。

【0049】

続いて、番号提供部１３はそのカード情報をユーザ端末Ｔｕに送信し（ステップＳ１０７、価値特定データ提供ステップ）。ユーザ端末Ｔｕはそのカード情報を決済ページの入力欄に挿入する（ステップＳ１０８）。

【0050】

バーチャルプリペイドカードの情報が決済ページに自動的に挿入された後の処理は従来と同様である。すなわち、ユーザ端末Ｔｕはカード情報を決済関連情報として受注サーバ２０に送信する（ステップＳ１０９）。したがって、本実施形態では支払代行サーバ１０はユーザ端末Ｔｕを介して受注サーバ２０にカード番号（ＩＤ情報）を提供する。続いて、受注サーバ２０がその情報に基づいて決済サーバ３０に与信照会を行い（ステップＳ１１０）、決済サーバ３０がその問合せに対して承認する（ステップＳ１１１）。

【0051】

バーチャルプリペイドカードの利用が承認されると、ユーザ端末Ｔｕと受注サーバ２０が協働して購入完了のための後処理（確認ページの表示や注文確定の処理など）を実行する（ステップＳ１１２）。これにより購入処理が完了する。その後、受注サーバ２０は取得したカード情報を用いて売上請求に関する処理を実行する（ステップＳ１１３）。

【0052】

以上説明したように、本実施形態によれば、商取引の決済金額に相当する価値が確保されるので、決済サービスの提供者（支払代行会社）はその確保した価値をクレジット会社を介してオンライン・ショッピング・サイトの運営者に支払えばよい。したがって、ユーザが店舗に支払うべき金銭をユーザから受領して店舗に納付する決済サービス（支払代行サービス）において、当該サービスの提供者が被るリスクを軽減することができる。

【0053】

受注サーバ２０の運営者はユーザが支払代行を選択できるようにオンライン・ショッピング・サイトを改良する必要がある。しかし、この改良は、ＨＴＭＬソースファイルの中に、外部のＪａｖａＳｃｒｉｐｔ（商標または登録商標）のソースファイルを参照するためのコードを追記するという簡単なものである。したがって、受注サーバ２０の運営者はその簡単な修正をするだけで本発明の仕組みを導入できる。

【0054】

（第２実施形態）
第２実施形態は、バーチャルプリペイドカードの情報（カード情報）をユーザに提示しない点で第１実施形態と異なる。以下では第１実施形態と異なる点について特に説明する。

【0055】

本実施形態では、番号提供部１３はユーザに提示するダミーのカード情報（以下では「ダミー情報」という）を生成する。ダミー情報は、ダミーのカード番号（ダミー番号）およびダミーの付属情報を含む。ダミー番号はクレジットカードの番号と同一形式であり且つバーチャルプリペイドカードの番号と異なる番号である。番号提供部１３は商取引ごとにダミー番号および付属情報を割り当ててもよい。あるいは、番号提供部１３は、受注サーバ２０ごとに割り当てられたダミー番号を用いると共に付属情報については商取引ごとに設定してもよい。この場合には、各受注サーバ２０は固定的に割り当てられたダミー番号を繰り返し使うことができるので、ダミー情報を用いる処理が簡単になる。

【0056】

続いて、番号提供部１３は支払代行要求に応答してダミー情報をユーザ端末Ｔｕに送信する。また、番号提供部１３は第１実施形態と同様にバーチャルプリペイドカードの情報を取得する。具体的には、番号提供部１３は確保した価値、およびダミー情報を含む発行要求を生成して決済サーバ３０に送信する。この発行要求はダミー情報を決済サーバ３０に記録させる役割も担う。決済サーバ３０は第１実施形態と同様にカード情報を生成すると共に、そのカード情報をダミー情報と関連付けてデータベースＤ３０に記憶する。また、決済サーバ３０はカード情報を支払代行サーバ１０に送信する。番号提供部１３はそのカード情報を受信し、確保した価値、ダミー情報、およびカード情報を関連付けてデータベースＤ１０に格納する。したがって、本実施形態ではダミー番号が価値特定データである。

【0057】

ユーザ端末Ｔｕは番号提供部１３から送信されたダミー情報を受信して決済ページ上の入力欄に設定する。このようにダミー情報が自動的に挿入されると、ユーザは決済を確定する操作を実行する。この操作に応じてユーザ端末Ｔｕと受注サーバ２０との間で購入手続きを完了させるための一連の処理（例えば、入力内容の確認から注文完了通知までの処理）が実行される。この処理の中で、受注サーバ２０はダミー情報を用いて決済サーバ３０に対して与信照会を実行する。

【0058】

受注サーバ２０は、購入手続を完了させた後の任意の時期にダミー情報を支払代行サーバ１０に送信する。番号提供部１３はそのダミー情報に対応するカード情報をデータベースＤ１０から読み出して受注サーバ２０に送信する。受注サーバ２０はそのカード情報を用いて決済サーバ３０に与信照会をした上で、その後、今回の決済金額を含む売上請求を実行する。

【0059】

次に、図６，７を用いて、ＥＣシステム１の動作を説明するとともに本実施形態に係る情報処理方法について説明する。

【0060】

ステップＳ２０１〜Ｓ２０４の処理は第１実施形態におけるステップＳ１０１〜Ｓ１０４の処理と同じである。続いて、番号提供部１３がダミー情報を生成してユーザ端末Ｔｕに送信する（ステップＳ２０５，Ｓ２０６、価値特定データ提供ステップ）。

【0061】

また、番号提供部１３は発行要求を決済サーバ３０に送信し（ステップＳ２０７）、その要求に応じて決済サーバ３０から送られてきたカード情報（カード番号および付属情報）を受信する（ステップＳ２０８）。これらステップＳ２０６，Ｓ２０７の処理に関連して、番号提供部１３および決済サーバ３０は、ダミー情報及びカード情報を関連付けてデータベースＤ１０，Ｄ３０にそれぞれ記憶する。

【0062】

ユーザ端末Ｔｕは支払代行サーバ１０から受信したダミー情報を決済ページの入力欄に挿入する（ステップＳ２０９）。続いて、ユーザ端末Ｔｕはユーザ操作に応じてダミー情報を決済関連情報として受注サーバ２０に送信する（ステップＳ２１０）。したがって、本実施形態では支払代行サーバ１０はユーザ端末Ｔｕを介して受注サーバ２０にダミー番号を提供する。

【0063】

受注サーバ２０はそのダミー情報に基づいて決済サーバ３０に与信照会を行い（ステップＳ２１１）、決済サーバ３０がその問合せに対して承認する（ステップＳ２１２）。続いて、受注サーバ２０は決済手続を確認するための確認ページをユーザ端末Ｔｕに送信する（ステップＳ２１３）。その後、ユーザ端末Ｔｕと受注サーバ２０が協働して残りの処理（注文確定の処理など）を実行し（ステップＳ２１４）、これにより購入処理が完了する。

【0064】

その後、受注サーバ２０は支払代行サーバ１０にダミー情報を送信することでカード情報を取得し（ステップＳ２１５，Ｓ２１６）、今度はそのカード情報を用いて決済サーバ３０に対する与信照会を実行する（ステップＳ２１７）。決済サーバ３０がその問合せに対して承認すると（ステップＳ２１８）。受注サーバ２０はその後、そのカード情報を用いて売上請求に関する処理を実行する（ステップＳ２１９）。

【0065】

本実施形態において、番号提供部１３は受注サーバ２０からダミー情報を受信した後に決済サーバ３０からカード情報を取得してもよい。これは、ステップＳ２０７，Ｓ２０８の処理がステップＳ２１５とステップＳ２１６との間で実行されることを意味する。この場合には、カード情報を生成する処理が後ろに移動する分だけ決済サーバ３０側においてカード情報を記憶する時間が短くなるので、そのカード情報に基づく支払いを行う支払代行会社のリスクを軽減することができる。

【0066】

以上説明したように、本実施形態においても、ユーザが店舗に支払うべき金銭をユーザから受領して店舗に納付する決済サービスにおいて、当該サービスの提供者（支払代行会社）が被るリスクを軽減することができる。

【0067】

オンライン・ショッピング・サイトの運営者はオンライン・ショッピング・サイトを改良すると共に、売上請求の前にダミー情報をカード情報に変換する処理を実装する必要があるが、その改良は比較的簡単である。

【0068】

加えて、本実施形態では支払代行サーバ１０がバーチャルプリペイドカードの情報をユーザ端末に送信しないので、支払代行会社が不測の損失を被るリスクをさらに軽減することが可能である。また、サーバ側においてカード番号を再利用することも可能になる。

【0069】

本実施形態ではバーチャルプリペイドカードの情報をユーザに提供しないので、ユーザがそのカード情報を他の商取引に利用する蓋然性が低い。したがって、これらの実施形態において与信照会（ステップＳ２１１，Ｓ２１２，Ｓ２１７，Ｓ２１８）を省略してもよい。

【0070】

（第３実施形態）
第３実施形態は、バーチャルプリペイドカードの情報（カード情報）をユーザに提示することなく決済を完了する点では第２実施形態と同じであるが、支払代行サーバ１０はダミー情報をユーザに提供しない。本実施形態では、支払代行サーバ１０は決済金額に相当する価値が確保されたことをユーザ端末Ｔｕ経由で受注サーバ２０に通知し、受注サーバ２０はその通知を信頼して購入手続を完了させる。以下では第１実施形態と異なる点について特に説明する。

【0071】

本実施形態では、確保部１２は、第１実施形態と同様に決済金額に相当する価値を確保すると、支払代行を承認することを示すメッセージを支払代行要求への応答としてユーザ端末Ｔｕに送信する。このメッセージは、価値が確保されて商取引の決済が完了したことを示す決済状況情報であり、本実施形態ではこれが価値特定データに相当する。

【0072】

本実施形態では、オンライン・ショッピング・サイトに関するＨＴＴＰセッションは決済が完了したか否かを示す決済フラグを含む。ユーザ端末Ｔｕはその決済フラグをＨＴＴＰクッキー（Ｃｏｏｋｉｅ）などの仕組みを用いて端末内の記憶部に保持しており、受信したメッセージに基づいてその決済フラグを未決済（ＯＦＦ）から決済完了（ＯＮ）に変更する。この処理において、ユーザ端末Ｔｕは支払代行サーバ１０から提供される暗号データを決済完了フラグと共に端末内の記憶部に書き込んでもよい。暗号データは、例えば、支払代行会社のＩＤおよび支払代行サービスの受付番号をハッシュ値に変換することで得られる値でもよい。フラグの変更は、ユーザ端末Ｔｕが決済状況情報を記憶することに相当する。また、ユーザ端末Ｔｕは決済ページ内のカード情報入力欄を無効にする。

【0073】

入力欄が無効化された後、ユーザは購入を確定する操作を実行する。受注サーバ２０は、「ＯＮ」に設定された決済フラグを受信すると、決済サーバ３０と通信することなく、残った処理（例えば、入力内容の確認から注文完了通知までの処理）を実行して購入手続を完了させる。

【0074】

番号提供部１３は第１実施形態と同様にバーチャルプリペイドカードの情報を取得する。すなわち、番号提供部１３は確保した価値を含む発行要求を生成して決済サーバ３０に送信し、その要求に応じて決済サーバ３０から送られてきたカード情報をデータベースＤ１０に記憶する。この一連の処理の中で、決済サーバ３０も第１実施形態と同様にカード情報をデータベースＤ３０に格納する。

【0075】

受注サーバ２０は購入手続を終えた後の任意の時期にカード情報を支払代行サーバ１０に要求する。番号提供部１３はその要求に応じてカード情報を受注サーバ２０に送信する。受注サーバ２０はそのカード情報を用いて、その後、決済金額を含む売上請求を実行する。

【0076】

次に、図８，９を用いて、ＥＣシステム１の動作を説明するとともに本実施形態に係る情報処理方法について説明する。

【0077】

ステップＳ３０１〜Ｓ３０４の処理は第１実施形態におけるステップＳ１０１〜Ｓ１０４の処理と同じである。その後、確保部１２は支払代行要求に対して決済を承認したことを示すメッセージをユーザ端末Ｔｕに送信する（ステップＳ３０５、価値特定データ提供ステップ）。

【0078】

ユーザ端末Ｔｕはそのメッセージを受信すると、ＨＴＴＰセッション内の決済フラグを「ＯＦＦ」から「ＯＮ」に更新する（すなわち、決済フラグを有意にする）と共にカード情報の入力欄を無効化する（ステップＳ３０６）。この際に、ユーザ端末Ｔｕは暗号データを記憶してもよい。続いて、ユーザ端末Ｔｕは更新された決済フラグを含む決済関連情報（この決済関連情報は暗号データを含んでもよい）をユーザ操作に応じて受注サーバ２０に送信する（ステップＳ３０７）。

【0079】

受注サーバ２０はその決済情報を受信すると、ユーザ端末Ｔｕと協働して残りの処理（注文確定の処理など）を実行し（ステップＳ３０８）、これにより購入処理が完了する。受注サーバ２０は、ステップＳ３０７，Ｓ３０８の処理の間に、支払代行サーバ１０に暗号データを送信することで、価値が確保されていることを確認してもよい。

【0080】

一方、支払代行サーバ１０では、番号提供部１３が発行要求を決済サーバ３０に送信し（ステップＳ３０９）、その要求に応じて決済サーバ３０から送られてきたカード情報（カード番号および付属情報）を受信する（ステップＳ３１０）。その後、番号提供部１３は、購入手続を完了させた受注サーバ２０からの要求に応じてカード情報を受注サーバ２０に送信する（ステップＳ３１１，Ｓ３１２）。その後、受注サーバ２０はそのカード情報に基づく売上請求を実行する（ステップＳ３１３）。

【0081】

本実施形態ではバーチャルプリペイドカードの情報をユーザに提供しないので、ユーザがそのカード情報を他の商取引に利用する蓋然性が低い。したがって、本実施形態では与信照会を行っていない。

【0082】

本実施形態において、番号提供部１３は受注サーバ２０からカード情報を要求された後に決済サーバ３０からカード情報を取得してもよい。これは、ステップＳ３０９，Ｓ３１０の処理がステップＳ３１１とステップＳ３１２との間で実行されることを意味する。この場合には、カード情報を生成する処理が後ろに移動する分だけ決済サーバ３０側においてカード情報を記憶する時間が短くなるので、そのカード情報に基づく支払いを行う支払代行会社のリスクを軽減することができる。

【0083】

以上説明したように、本実施形態においても、ユーザが店舗に支払うべき金銭をユーザから受領して店舗に納付する決済サービスにおいて、当該サービスの提供者（支払代行会社）が被るリスクを軽減することができる。また、第１実施形態と同様に、オンライン・ショッピング・サイトの運営者はオンライン・ショッピング・サイトの簡単な改良を行うだけで、本発明の仕組みを導入できる。

【0084】

加えて、本実施形態においても、支払代行サーバ１０がバーチャルプリペイドカードの情報をユーザ端末に送信しないので、支払代行会社が被るリスクをさらに軽減することが可能である。また、サーバ側においてカード番号を再利用することも可能になる。

【0085】

次に、図１０を用いて、コンピュータを第１〜第３実施形態に係る支払代行サーバ１０として機能させるための情報処理プログラムＰについて説明する。

【0086】

情報処理プログラムＰは、メインモジュールＰ１０、受付モジュールＰ１１、確保モジュールＰ１２、および番号提供モジュールＰ１３を備える。

【0087】

メインモジュールＰ１０は、支払代行を統括的に制御する部分である。メインモジュールＰ１０、受付モジュールＰ１１、確保モジュールＰ１２、および番号提供モジュールＰ１３を実行することにより実現される機能はそれぞれ、上記の受付部１１、確保部１２、および番号提供部１３の機能と同様である。

【0088】

情報処理プログラムＰは、例えば、ＣＤ−ＲＯＭやＤＶＤ−ＲＯＭ、半導体メモリ等の有形の記録媒体に固定的に記録された上で提供されてもよい。また、情報処理プログラムは、搬送波に重畳されたデータ信号として通信ネットワークを介して提供されてもよい。

【0089】

以上、本発明をその実施形態に基づいて詳細に説明した。しかし、本発明は上記実施形態に限定されるものではない。本発明は、その要旨を逸脱しない範囲で様々な変形が可能である。

【符号の説明】

【0090】

１…電子商取引システム、１０…支払代行サーバ、１１…受付部、１２…確保部、１３…番号提供部（価値特定データ提供部、第１記録部、ＩＤ情報提供部、第２記録部、および取得部）、２０…受注サーバ、３０…決済サーバ、Ｄ１０，Ｄ２０，Ｄ３０…各データベース、Ｐ…情報処理プログラム、Ｐ１０…メインモジュール、Ｐ１１…受付モジュール、Ｐ１２…確保モジュール、Ｐ１３…番号提供モジュール。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】