JP5479583B2 - 支払い端末を使ってなされるカード支払いの時点でユーザーからデータを取得する方法 - Google Patents

Description

本発明は、支払い端末を使ってなされるカード支払いの時点でユーザーからくるデータを取得する方法および該方法を実装するためのコンピュータ・プログラムに関する。

サービスまたはユーザーがなした購入についてのユーザーの意見を得る種々の手段が知られている。

たとえば、購入がインターネットによってリモートに行われ、購入者が販売者のために電子メール・アドレスを残した場合、販売者は、直接またはサービス・プロバイダーによって、購入からある時間後、購入者に、その購入に関する満足度を尋ねるオンライン・アンケートに記入するよう依頼する電子メールを送ることができる。

別の手段は、購入者に専門のサイト上で評価を残すよう依頼することからなる。そうした評価は、そのサイトの他のユーザーに自由に利用可能となる。こうして、たとえば、ある都市または地域におけるレストランを列挙し、レストラン・インデックスに加えて、任意的に、サイト管理者によるコメントを提供するサイトがある。消費者が、挙げられているレストランに関係する評価を残すことができるフォーラム領域である。

こうした型のコメントは、さまざまなユーザーによって与えられる評価格付けの平均からなる一種の統合された分類が伴うことができる。

現実には、たとえばレストラン・サイトでは、各レストランは非常に少数、しばしば十人に満たない人々によってのみ格付けされており、しばしばきわめて対照的な意見を含むようである。よって、集められた意見の代表性はきわめて低く、使うのが難しい。さらに、投票者が実際の消費者であったかどうかはしばしば不確かである。

したがって、信頼できる仕方で得られた、代表となるに十分な数の意見を収集することを可能にする意見を取得する信頼できる方法を確立することが特に有利である。

上述の欠点の一つまたは複数を解決するため、支払い端末を使ってなされるカード支払いの時点でユーザーからくるデータを取得する方法であって：
支払いトランザクションの終了後、前記支払い端末の画面上にデータ取得要求を提供する段階と；
前記支払い端末によって前記データを取得する段階と；
前記端末において取得された前記データを検証する段階と；
前記データが有効であれば、前記データを前記支払い端末から統合（consolidation）サーバーに送信し、ユーザーに対して前記端末の前記画面上において検証メッセージを提供する段階とを含む、
方法。

前記取得は最大時間期間パラメータを含むので、データが無効であると考えられるのは、前記データがこの最大時間期間後に取得された場合である。

この方法は、有利なことに、意見が系統的かつ迅速に、しかも販売者が投票を変更するために簡単に介入できることなく、得られるので、顧客からの信頼できる意見を収集することを可能にする。

以下は、個別的な特徴または実施形態である。

・前記方法は、前記データが無効である場合に、
・・前記支払い端末から前記統合サーバーに失敗情報を送信し；
・・前記端末の前記画面上で検証メッセージをユーザーに与える段階を含む；
・前記支払いトランザクションがスマート・カードを使う支払いトランザクションである場合、前記方法は、前記カードの存在に基づく検証のステップを含む。

・前記取得要求および前記支払い端末の画面上でのその提示は、前記統合サーバーによってパーソナル化され、次いで前記統合サーバーから前記支払い端末に送信される。

・前記端末から前記統合端末への前記データの送信は、前記統合サーバーによって送られた応答メッセージを受信すると、完了されたと前記端末によって考えられる。ここで、前記メッセージは、前記サーバーによって、前記データの前記サーバーによる検証の前に送られる。

・前記データが前記統合サーバーによって検証されない場合、前記データは前記統合サーバーによって統合されず、全体的な統計的結果は、取得要求全体の非統合により、検証されなかったデータによって影響されない。

・前記取得要求は調査キャンペーンを定義する要求の集合の一部であり、前記キャンペーンは、複数の支払いトランザクションが実行される一つまたは複数の支払い端末を介して実施されるので、前記パーソナル化は、前記複数の支払いトランザクションにわたって実施される前記キャンペーンの要求の集合の要求を分配するために、前記統合サーバーによって、実行される。それにより、前記支払い端末（単数または複数）によって集められるデータの統合は、統計的に有意な結果を得るために、統計的な大数の法則を使うことを可能にする。

・前記パーソナル化は、前記統合サーバーまたは前記ユーザーのカードからくる、ユーザーに関連付けられた個人を特定しないパラメータを考慮に入れる。

・前記取得要求は、複数のデータを相続いて収集するよう適応される。

・前記パーソナル化は、前記複数のデータの収集の可変の順序を定義し、前記可変の順序は、前記ユーザーまたは環境に関連付けられたパラメータに依存する。

・前記支払い端末は、前記取得要求または複数の取得要求を前記端末上に表示し、前記データまたは前記複数のデータを収集するための一連の命令のインタープリタを有するので、前記インタープリタは、どの一連の命令もエンドレスな実行につながり得ないよう、戻る方向に分岐する命令を遮断し、動作時間を制限する。

・カードの暗証番号（PINコード）はN桁を有するので、前記インタープリタはN−Pより多くのデータの入力を禁止する。ここで、Pは1以上である。これは、前記端末において悪意をもってロードされた一連の命令がユーザーに、銀行カードの秘密のコードを入力させることを防止するためである。

・前記統合サーバーは、取得されたデータを、該取得されたデータの取得時刻を介して、ユーザーを性格付ける、個人を特定しないデータに関連付ける。

本発明の第二の側面では、コンピュータ・プログラムが、支払い端末のようなモバイル・デバイスのコンピュータ可読媒体上に記録された、上記の方法のステップを実装するためのプログラム・コード命令を含む。

本発明の第三の側面では、統計的情報収集システムが統合サーバーを有する。統合サーバーは、複数の支払いトランザクションを実行する一つまたは複数の支払い端末に接続され：
・ユーザーに尋ねるべき質問のリストの記憶部と；
・前記複数の支払い端末についての問い合わせプランを計算するコンピュータであって、前記プランは、各支払いトランザクションについて、前記質問のリストの部分集合を定義する、コンピュータと；
・各端末に、前記質問の部分集合を取得要求の形で送信し、前記端末に割り当てられた質問に対応するデータを収集するための各支払い端末との通信インターフェースであって、前記端末（単数または複数）は上述した取得方法を実装するよう設計されている、インターフェースと；
・ユーザーによって返される答えのリストの記憶部と；
・大数の法則を使った取得されたデータの統合のための統計コンピュータとを有する。

本発明は、以下の記述に鑑み、また付属の図面を参照することで、よりよく理解できる。以下の記述は、あくまでも例として与えられているものである。

ある実施形態に基づく取得システムの概略図である。 本発明のある実施形態に基づく取得方法のフローチャートである。 本発明のある実施形態に基づく取得方法のフローチャートである。 図２の方法の代替のフローチャートである。 本発明のある実施形態に基づく統合方法のフローチャートである。 本発明のある実施形態に基づく支払い端末上の仮想マシンの命令の実行の部分的な図解である。 本発明のある実施形態に基づく通信プロトコルのある側面を示す概略図である。

図１を参照するに、支払い端末１は、スマート・カード５のための接続媒体３と、画面７と、キーパッド９と、またデータ・ネットワーク１３との通信のための手段１１とを有する。これらの要素のすべては自己完結した端末内に組み合わされることができるし、あるいは分離され、あるいは重複されることもできる。たとえば、複数のキーパッドおよび複数の画面があることも可能である。このデータ・ネットワークにより、支払い端末１は支払いサーバー１５、統合サーバー１７およびリモート・メンテナンス・サーバー１９に接続される。

スマート・カード５、支払い端末１および支払い端末１５は好ましくは事実上最新の規格、たとえばEMV（Eurocard/Mastercard/Visa［ユーロカード／マスターカード／ビザ］）規格４．２に準拠する。この規格はウェブサイトhttp://www.emvco.com/specifications.aspx?id=155でダウンロードできる。

支払いサーバーは、たとえば、銀行または金融機関によって管理される安全なサーバーである。メンテナンス・サーバーおよび統合サーバーは、サーバー型のコンピューティング機械である。メンテナンス・サーバーはたとえば、端末のメンテナンスを受け持つコンピュータ・サービス会社によって管理される。統合サーバーは、質問キャンペーンの準備、答えの収集および統計的な統合を可能にする。それはたとえば、満足度解析キャンペーンを専門とするマーケティング・サービス会社によって、あるいは提供されたサービスに関する顧客満足度に関する情報を絶えず求めている販売者によって、使用される。

一つまたは複数の調査キャンペーンにおいて尋ねられる質問が定義され、ステップ２において統合サーバー１７に記憶される。統合サーバー１７は、ステップ４において、各端末および各消費者について、日付、時刻および顧客の注文番号といったパラメータに基づいて、その顧客に尋ねられる質問または質問の部分集合を定義するコンピュータをもつ。質問プランはステップ８でインターフェース６を介してネットワーク１３に、次いで、ステップ１０で関連する支払い端末に送信される。

端末は、ステップ１２で答えをネットワーク１３に提出する。ステップ１４では、これらの答えが統合サーバー１７に与えられる。このサーバーは、ステップ１６において支払い端末から受信された答えに従ってすべての調査の結果を確立し、ステップ１８において調査の完全な結果を呈示する統計コンピュータを有する。

他の実施形態では、前記の種々の記憶部およびコンピュータはたとえば、同じ統合サーバー中に組み合わされていなくてもよい。

図２は、図１を参照して述べた手段を使った取得方法のある実施形態のフローチャートである。種々のフローを見ることができるようにするよう、ステップを実行する各手段が図のいちばん上の行に示されており、所与の手段によって実行されるステップはその縦の線上に位置される。システムは特に、図１の種々のサーバーを含む。

データ取得方法は以下の段階を含む：
・カード５によって与えられる受け入れ（ステップ２２）後の、支払いトランザクションの終了（ステップ２０）。これはたとえば、EMV規格４．２の「10.11 Completion」の段階に対応する。この結果しばしば、端末の表示画面上に「支払いが受け入れられました」というメッセージにつながる。他の場合では、たとえば、磁気ストリップ・カードの場合、受け入れはシステムによって与えられてもよい。
・取得動作の開始（ステップ２４）。
・支払い端末の画面７上でのパーソナル化されたデータ取得要求の提示（ステップ２６）。
・支払い端末のキーパッド９上でのデータの取得（ステップ２８）。
・取得されたデータの端末内での検証（ステップ３０）。
・データが有効確認された場合、
１．データの記録（ステップ３２）、
２．支払い端末から統合サーバー１７へのデータの送信（ステップ３４）、
３．検証メッセージのユーザーへの呈示（ステップ３６）。これは、スマート・カードの場合、端末の画面７上での、カードを取り出してよいという許諾であってもよい。
・データが有効確認されない場合、
４．失敗を記録（ステップ３８）、
５．該失敗の支払い端末から統合サーバー１７への送信（ステップ４０）、
６．スマート・カードの場合、端末の画面７上での、カードの取り出しを許諾するメッセージのユーザーに対する呈示。

取得ステップ２８は、データの入力のための最大時間期間を含む。この時間期間後は、データは無効であると考えられ、端末はセッションを打ち切ってもよい。これは支払いのコンテキストでは特に有利である。実際、この時点では、顧客および販売者の両方はトランザクション全体が迅速に行われることを望む。しかしながら、最大時間期間がデータ入力のために与えられないと、端末は、入力待ちモードでブロックされうる。さらに、たとえば販売者が端末を受け継ぎ、自分で質問に答えることをできるようにすることにより、正しくない答えが残される機会を与えることもありうる。これを防ぐために、数秒、たとえば５ないし１０秒の最大時間期間が、質問を読み、理解し、ほとんど自発的に答えを入力できるようにするための良好な妥協点である。

同様に、入力時間期間は、支払い端末中のカードの義務的な存在によって制限されてもよい。実際、端末中にカードが存在する限り、顧客がまだ端末を保持しているか端末の近くにいると想定することは合理的である。よって、「支払いが受け入れられました」および「カードを取り出してください」というメッセージがリンクされる通常のスマート・カード支払い図において、取得ステップの集合は、有利には、これら二つのメッセージの間に実行される。

記載される方法は、命令からなるコンピュータ・プログラム、たとえばスクリプトの形で有利に実装することができる。その際、記載される方法の実行にあたって支払い端末の種々の手段を制御するために、このコンピュータ・プログラムは支払い端末の制御手段内にインストールされる。

統合サーバーはまた、質問を用意し、支払い端末に送り、端末から送られた情報を収集し、それを送信または合成するコンピュータ・プログラムをも有する。次いでこの合成は、販売者を格付けおよび比較するためのウェブサイトの形で消費者に呈示されることができる。

データ取得要求は、パーソナル化された質問の形であることができる。パーソナル化は、統合サーバーによって、該サーバーによって受信される要求に基づいて達成される。よって、質問自身が、時や場所、ビジネス自身または他のパラメータに応じて変化しうる。画面およびディスプレイ上に現れる他のメッセージもパーソナル化されることができ、これらも取得要求のパーソナル化である。

端末がリアルタイムで統合サーバーに接続される場合、尋ねるべき質問をパーソナル化するために、取得要求は有利には、顧客によってなされた、統合サーバーに知られている購入を考慮に入れることができる。

データの検証は、十分信頼できるデータを得るために、十分な信頼度をもって、データが実際に顧客によって入力されたことを保証することを可能にする。

端末は一般に小さな画面をもち、顧客は一般にトランザクションを完了させようと急いでいるので、質問の数およびその複雑さは最小限にする必要がある。よって、単一のキーパッド入力によって答えられる三つの簡単な質問を超えないことが、人間工学的に有利であると考えられうる。

この制限は、この情報収集方法を使う調査キャンペーンが、電話、インターネット・アンケートなどによって実施される「通常の」調査キャンペーンよりずっと少ない情報を得るということを意味しうる。そうした通常のキャンペーンはしばしば、複数の選択肢のある二十ほどの質問や、一部の質問への答えに基づくアンケート経路ツリーなどを含む。

この制限は、種々の人々または会社によって必要とされる複数の調査キャンペーンが同時に実施されることをも妨げうる。

この制限を克服し、統計的に「通常の」キャンペーンと同じ品質をもつ結果を得るために、統計的な大数の法則を使うことが提案される。それにより、サービスについてのユーザー意見の変化を判別し、あるいは異なるが比較可能な活動をもつ企業によって提供されるユーザー意見を、または異なる時間期間、たとえば午前と午後もしくは週日と週末に与えられたサービスに対するユーザー意見を比較するために、統計的に有効な結果を得ることが可能になる。

これらの意見は、比較されるべきさまざまなコンテキストにおいて、上記の方法を使って収集される。

この意見収集の系統的な性質のため、同じ質問に対する多数の答えを得ることが可能になる。統計上の法則（大数の法則）は、統計的に有効な結果を得るためには、関連するユーザーの代表的なサンプルの意見を得ることが十分であることを保証してくれる。統計的に有効な結果とは、すなわち、関連するすべてのユーザーに問い合わせることによって得られるであろう平均的な結果にほとんど確実に近いものである。こうして、多数の顧客に問い合わせし、各顧客については実施される調査キャンペーン（単数または複数）のために尋ねられる質問の集合のうちの限られた数についてのみ質問することにより、大数の法則により、実施されるキャンペーンまたは全キャンペーンの質問全部についての顧客全部の意見の代表的な測定を得ることが可能となる。統合サーバーが、全部の質問が同じキャンペーンからきたかのように、キャンペーンの全部を組み合わせ、各顧客には少数の質問だけをすることを可能にする。

しかしながら、これらの結果が効果的に使われることができるためには、次のことを確かにすることが重要である。
・各質問に対する答えの数が統計的に有効になるよう十分多い、あるいは答えの数がユーザーに対して、このデータを使う人に知らせるために、示される；
・考慮される各時間期間についておよび各端末についての結果が比較可能であり、統計的に正しい仕方で組み合わされることができる。

一例として、二つの異なる端末を持つ店を考える。
・端末T1は一日にその顧客たちに３０回ある質問をし、この質問に対して平均格付け５を得、次いで、同じ日の間に４７０の顧客に他の質問をする。すると、平均が５である３０の格付けは５００ユーザーを代表する。
・端末T2は一日にその顧客たちに３０回同じ質問をし、平均格付け３を得、他の顧客は一切ない。

端末T1上で３０の質問のサンプルによって得られた平均５は５００の顧客の意見の代表であり、端末T2上で３０の質問のサンプルによって得られた平均３は３０の顧客の意見の代表である。５３０の顧客の意見を代表する平均は、たとえ代表サンプルが同じサイズであったとしても、３と５の平均を得ることによって計算することはできない。その平均は、それぞれの別個の平均によって表される母集団に基づく重み付けによって計算する必要がある。よって、この場合、(5×500＋3×30)/530、すなわち約4.89である。

統計的に有効な結果を比較できるようにするため、本方法は以下の段階を含む：
・統合サーバー上で、調査が開始される前に、調査を要求する人々が尋ねるべき質問をプログラムし、顧客意見を比較したいコンテキストを定義できるようにする。これらのコンテキストは、たとえば、企業として、企業の一部として、企業のグループとして、時間期間として、または時間期間のグループとして、あるいはこれらの基準の組み合わせとして定義できる。

・統合サーバーによって、調査が実施されている間に、
・・各時間期間についての、各ポイントオブセール端末でなされる支払いの数の初期推定を、次いで任意的に履歴推定を記憶する。この推定により、これらの統計的に有効なサンプルを得ることを可能にする、ポイントオブセール端末の最小数および最小時間期間を決定することができる。これらの推定は、質問が顧客に尋ねられる頻度に依存する。その質問が顧客十人のうち一人に尋ねられる場合、質問が五人のうち一人に尋ねられる場合に比べ、たとえば５０の答えを得るために、二倍の支払いトランザクションをもつことが必要である。これらの推定は、プログラムされるときに提供される選択肢において明示的または暗黙的に、調査を要求する人物の目に留まるようにされる。
・・結果を統合する際に、統計的に有効なサンプルが明らかに得られたことを検証する。または尋ねられた質問の数または得られた答えの数を表示する。

・各支払い端末によって、統合サーバーに結果のすべてを提出する：
・・質問が尋ねられた日時；
・・尋ねられた質問の識別子；
・・投票または顧客が投票しなかったことを示す情報；
・・たとえ一つも質問がされなかったとしても、各支払いトランザクションの日時。

調査の結果を参照する人々に、統計的に有効な結果を呈示するために、統合サーバーによって、この情報に統計的計算規則を適用する。特に、平均、標準偏差といった統計的な値を、十分大きなサンプルによって表現される母集団についての有効な重みを用いて、計算する。

多数の顧客に少数の質問がされることを可能にするこの大数の法則の使用は、上述した支払い手段を使うキャンペーンに限定されない。実際、良好な回答率を得るために、アンケートへの反応が非常に迅速であることが望ましい他の環境において使うことができる。たとえば、インターネットまたは電子メールを媒体として使う調査キャンペーンにおいてこの統計的技法を使うことが可能である。

ある代替では、本方法は、同じ支払い端末コンテキストでの、単一の質問ではなく一連の質問に対する顧客の意見を収集することを可能にする。実際、ある種の支払い端末はコンテキストを使って、質問に対してのみならずそのような一連の質問に対してユーザーの意見を尋ねることを可能にする。これらのコンテキストは、コンテキストが顧客との長期にわたる対話を可能にする、奨励するまたは要求する場合を含む。

そのような調査を注文する人は、一般に、日時および言語といった外的な条件に基づくのみならず、前の質問に対する顧客の答えにも基づいて、顧客に種々の質問をしようとする。

このデータの一部は、ユーザーの支払いカードに存在するデータから得ることができる。たとえば、質問が呈示される言語は一般に、端末が使われている国の通常の言語である。しかしながら、カードに記憶されているデータからユーザーの好ましい言語を推定することがしばしば可能である。すると、ユーザーの好ましい言語で、あるいはその国の通常の言語より普通に理解される言語で質問を表現することができる。これは、外国の顧客をもつ販売者にとって特に有益である。

一般に、支払い適用の時点において、カード・データから推定される情報の通信を要求することが可能である。該情報は、秘密性およびセキュリティを危殆化させないようユーザーを特定することを可能にしない情報であるが、ユーザーに尋ねられる質問が調整されることを可能にする。このデータを「個人を特定しない」と呼ぶが、これは：言語（質問が表現される言語を調整するため）、性別（文法上の一致のため）などを含む。

そのような動的な一連の質問〔質問のシーケンス〕が考慮に入れられるようにするため、本方法は：
・統合サーバーによって、調査を要求する人物が、これらの動的なシーケンスを表現できるようにする；
・統合サーバーによって、これらのシーケンスを計算用の表現（すなわち、タグによって特徴付けられる動作）で表す。これが、端末中のインタープリタが前記シーケンスを適正に実行できるようにする；
・支払いアプリケーションによって、ユーザーを特定することを可能にしないある種の情報を、質問を有するインタープリタに通信する。質問の表現を調整できるようにするためである。
・端末内のインタープリタによって、各動作を順次実行し、たとえば次の質問を選択するために外部および内部両方の情報にアクセスし、ユーザーの投票を収集し、その結果を記憶する。特に、日付、時刻、購入者の話す言語または以前の質問に与えられた答えを含む基準を評価する。

図４は、図１を参照して述べた手段を使った、上記の取得方法のある実施形態のフローチャートである。したがって、調査を注文する人が投票トランザクションにおいて尋ねられる質問のリストを指定できるようにし、内部パラメータ（トランザクション時間期間、以前の値など）または外部パラメータ（日付、時刻、担持者が話す言語、顧客ランク）の考慮を可能にする図２を参照して述べた方法の代替である。図２と同様、ステップを実行する各手段が、図のいちばん上の行に示されており、所与の手段によって実行されるステップはその縦の線上にある。

ステップ２４、２６、２８、３０、３６およびＡは図２と同一である。ステップ２０はステップ２１によって置き換えられている。ステップ３２はステップ３１、３３、３５によって置き換えられている。ステップ３４はステップ３７と番号を振り直されている。

図２を参照するに、以下のステップが追加されている。
・トランザクションの終了および担持者について匿名の情報の転送（ステップ２１）。
・調査を要求する人物によって所望されるプログラミングに基づく、尋ねるべき質問の選択（ステップ２５）およびこのプログラミングに基づく、外部パラメータ（日付、時刻、顧客のランク、顧客が話す言語）の考慮およびこれが最初の質問でなければ、内部パラメータ（質問リストの履歴、前記リストに応答するのに費やされた時間および前記質問リスト中の以前の投票など）の考慮。
・投票の記録（ステップ３１）。
・調査を要求する人物によって所望されるプログラミングに基づく、尋ねるべき別の質問の存在の判定（ステップ３３）。
・トランザクションの終了（ステップ３５）。
・統合サーバーへの投票の提出（ステップ３７）。

答えがタイムスタンプ付けされている場合、これは、答えを他の情報と照合〔マッチング〕することをも可能にする。該情報は、なされた購入のように匿名でもよいし、あるいは購入者の連絡先情報のように非匿名でもよい。

企業にとって、この照合を実行することは、統計的研究を先に進めるために特に有利でありうる。この方法は、特に、購入の匿名性を維持しつつ非常に精密な研究を実施することを可能にする。

図５は、匿名のままであることのできるデータを照合し、実施される調査がさらに先に進められることを可能にするための方法のある実施形態のフローチャートである。さまざまなフローが表示できるようにするため、ステップを実行する各手段が図のいちばん上の行に示されており、所与の手段によって実行されるステップはその縦の線上に位置される。システムは特に、図１の種々のサーバーを含む。

データを照合する方法は：
・図２に基づくステップ３４または図４に基づくステップ３７の後の投票の提出から得られたタイムスタンプ付けされた投票データの抽出（ステップ４６）。
・日付および時刻による投票データの時間順のソート（ステップ４８）。
・なされた購入のリストなど、投票結果と照合されねばならないデータの抽出（ステップ４０）。
・日付によって照合されるべきデータを時間順にソート（ステップ５２）。
・時刻の一致の検証および異なるコンピュータのクロック調整における差に基づいて必要なら時刻の調整（ステップ５４）。
・調整後に同じタイムスタンプをもつデータで対をつくる（ステップ５６）。

支払い端末中のコンピュータ・プログラムのインストールが、サーバー、通常は端末メンテナンス・サーバーが支払い端末上の対応するプログラムのインストールのために好適であることを要求することも注意しておくべきである。これらの動作は、ある種の場合には、支払い端末のリモート・メンテナンスおよびソフトウェア更新の動作の際になされることができる。

統合サーバーと諸端末との間の通信を保証するよう意図されたコンピューティング技法は、端末上での上記の方法の動作を可能にするために、以下のパラメータを考慮に入れる必要がある。
・諸端末が地理的に分散している。
・幅広い多様な型の端末がある。
・端末のコンピューティング能力およびメモリは限られている。
・端末のネットワーク接続モードは、時に、たとえばリモート・サイトにおけるように、遅く、気まぐれである。
・ビジネスのための支払いの本質的な性質を考えれば、端末は利用可能なままである必要がある。
・支払いトランザクションに使われるデータおよびプログラムのセキュリティが危殆化されてはならない。
・関連する電子キャッシュ・システムに関わりなくすべての端末上に投票アプリケーションがインストールされることができることを考えると、統合サーバーによってサービスされる端末の数は電子キャッシュ・システムによってサービスされる端末の数より多い。
・カード担持者の個人データのセキュリティが保持される必要がある。特に、「フィッシング」のいかなる可能性も禁じなければならない。「フィッシング」とは、悪意をもってユーザーの秘密データ（PIN）を得ることをいう。

これらの条件のもとで、既知の方法は、以下の点において補強できる。

端末中の、質問のシーケンスを実行することを受け持つソフトウェア部分（図４のフローチャートにおけるステップ３３および２４）の生産のための従来技術は、スクリプト言語をインタープリットするまたは仮想マシンが事前コンパイルによって得られた命令のシーケンスを実行することからなる。これら二つのアプローチは、一般に、実行が終了することや、「フィッシング」がないことを保証してくれない。実際、端末が一般的なスクリプト・インタープリタまたは一般的なプログラミング言語をインタープリットする仮想マシンを組み込む場合、次のことが可能となってしまう。
・スクリプトを端末に送信し、前記スクリプトの実行が決して終了しないようにする。これは、支払い端末の可用性にマイナスの影響を与える。
・スクリプトを端末に送信し、前記スクリプトの実行がユーザーのPINコードを必要とするようにし、カード保有者の知らないうちに、PINコードを収集してスクリプトの所有者に返送する。

さらに、端末からデータを収集するための既知のプロトコルは、安全であり（機微な情報が危殆化されるのを防ぐ）、信頼でき（トランザクション・データが失われるのを防ぐ）、やりとりにおける若干の複雑さにつながる。特に、これらの機能を保証するためには、接続交換および切断に加えて、複数のメッセージ交換が必要となる。この安全性、信頼性および複雑さは、以下の要求の考慮においては、適合でもなければ必要でもない。
・関連する電子キャッシュ・システムに関わりなくすべての端末上に投票アプリケーションがインストールされることができることを考えると、投票のために統合サーバーによってサービスされる端末の数は電子キャッシュ・システムによってサービスされる端末の数より多い。
・投票が統計的で純粋に情報のための性質であることにより、送信の完全な信頼性は要求されない。
・投票の匿名の性質により、個人データのセキュリティ保護は要求されない。

実行が系統的に終了されることを保証するため、支払い端末は好適には以下を有する。

・命令のシーケンスをインタープリットできる仮想マシン。各命令は、たとえばタグによって特徴付けられ、たとえば試験および動作を含む：
・・試験は、単純な試験、たとえばブール値の検証または二つの値の比較、に限定される。これらの値は一定であってもよいし、あるいは時刻、日付または言語のような外部データの限られたリストから取ってもよい。試験が失敗したら、動作は実行されず、次の動作が考慮される。
・・動作は下記に限定される：
・・・命令において指定されている画面を表示し、前記データを収集する動作。
・・・正の数の命令がスキップされることを可能にするスキップ動作。この数は、正であることしかできない。よって、シーケンスを戻ることは不可能である。
・・・さまざまな値操作動作：インクリメント、ブール値変更、コピー。

・仮想マシンとは別個であり、前記仮想マシンの表示および収集命令によって呼び出されるモジュールが、画面を表示し、単一のデータを収集する動作を実行する。統合サーバーがこのモジュールの実行をパラメータ化する機能は、仮想マシンとは別個であるため、限定される。
・・・このモジュールは一つのデータしか収集できない。
・・・このデータは一つの数字または文字しか含まない。

これらの命令シーケンスは、キャンペーンを要求する人々によって表現された質問および質問シーケンス・プログラミングから、統合サーバーによって生成される。

次のことは容易に信じられる。
・実行が終了しない命令の有限シーケンスを生成することは不可能である。
・表示し、データを収集するための前記モジュールの単一の実行によって、ユーザーの秘密コードを収集することは不可能である。
・画面ディスプレイおよび投票収集モジュールの実行回数を、秘密コード中の数字または文字の数（しばしば４）より厳密に少なくなるよう制限することにより、カードの秘密コードが収集されることを防止できる。

このように、たとえ端末と交換サーバーの間の交換が悪意のある攻撃によって危殆化されたとしても、攻撃者が、端末に、ユーザーに自分のカードの秘密コードを入力させるような質問または質問リストを実行させることは不可能であろう。

このアプローチへの代替は、カードが取り出された後にのみ、複数のデータを収集するために動的な質問シーケンスの実行を可能にすることからなる。これにより、ユーザーに対して明確に、今のコンテキストがもはや支払いやカード使用のコンテキストではないことを示すのである。

一例として、図６は、命令シーケンスから選択されたいくつかのステップを示している。第一ステップ６１では、試験は、成功であれば、インタープリタがステップ６２を無視して直接第三ステップを考えることにつながる。ステップ６１が失敗したら、ステップ６２の動作が実行される。この動作は、画面が表示され、データが捕捉されることを可能にする前記別個のモジュールへの呼び出しを含む。画面の表示および投票の捕捉はインタープリタによって直接は許容されない。それにより、制御されない表示および捕捉を生じる命令シーケンスを受け入れることは不可能になる。ステップ６１とステップ６２の間に実行される可能性のある命令のスキップは、「前方」にのみ許容され、よって、いかなる命令の有限シーケンスも終了することを保証する。

端末の数の膨大さおよび匿名で、統計的で、純粋に情報用という結果の性質を考慮に入れつつ端末プログラミングの配布および投票の収集を保証するため、データ伝送プロトコルは以下の特徴を有する。

・端末と統合サーバーとの間の標準的な交換。これは次の交換に限定される（図７のａ）。
・・端末による接続を確立する要求および統合サーバーによる受け入れ。この交換は交換パラメータを確立することに限定される。
・・端末による要求メッセージ。該メッセージは投票の結果のサーバーへの送信を含む。
・・サーバーによる応答メッセージ。該メッセージは必要であれば端末の新しいプログラミングを含む。
・・端末による切断要求。それに続いてサーバーによる受け入れ。

・呼び出しの際の失敗の場合、端末は、たとえば図７のｃにおいてパラメータTimeBetweenAttempts〔試行間の時間〕によって示されるような規則的な間隔で、呼び出しが成功するまで、あるいは呼び出しの所定回数（図７のｃのパラメータNumberofAttemps〔試行回数〕）に達するまで、その試みを繰り返す。

・標準的な交換が、たとえば二つの標準的な交換の間の日数（図７のｂにおけるTimeBetweenCalls〔呼び出し間の時間〕）およびそのような交換のために予期される時間（図７のｂにおけるCallTime〔呼び出し時間〕）によって決定される規則的な間隔で繰り返される。

・端末の数の多さのため、サーバーは、各要求の処理に最小限の時間を割くことが必要になる。したがって、返送メッセージを送信する前に、要求メッセージの受信に際してデータの訂正を完全に検証することは可能ではない。端末は、通常の応答メッセージの受信に際して、送信されたデータをそのメモリから消去するよう求められる。したがって、データが失われる可能性がある。

・統合サーバーは、次のようにして結果が失われる可能性を補償して、結果の統計的有効性を保証し続ける。
・・投票は平均、標準偏差または他の統計的値の計算の考慮に入れられない。
・・投票トランザクションは、平均、標準偏差または他の統計的値を計算するために使われるトランザクションの数には算入されない。

したがって、上記のプロトコルは、統合サーバーによって効率的にサービスされる端末の数を増やすために、各要求についての処理時間期間を最適化する。この最適化は、データの損失のリスクにおいて達成される。しかしながら、このデータの損失は、データのすべてを考慮に入れている結果が統計的に無効になることにはつながらない。

本発明について、図面および上記の記述において詳細に図示し、説明してきた。これは、本発明をこの単一の記述に限定するのではなく、例解するものであり、例として与えられているものと考えなければならない。数多くの代替的な実施形態が可能である。

たとえば、支払いサーバー、統合サーバーおよび端末のメンテナンス・サーバーは、二つの機械に、またさらには単一の機械に組み合わせることができる。対照的に、支払い端末、データ処理、表示、キーパッドおよびインターフェースの種々の機能が相異なるデバイスに分離されることもできる。統合サーバーの種々の機能についても同様である。数多くの他の代替的な実施形態が可能である。

請求項において、「含む」の語は他の特徴を排除しない。単数形の表現は複数を排除しない。

Claims (15)

1. 支払い端末を使ってなされるカード支払いの時点でユーザーからくるデータを取得する方法であって：
   ・支払いトランザクションの終了後、前記支払い端末の画面上にデータ取得要求を提供する段階と；
   ・前記支払い端末によって前記データを取得する段階と；
   ・前記端末において取得された前記データを検証する段階と；
   ・前記データが有効であれば、前記データを前記支払い端末から統合サーバーに送信し、ユーザーに対して前記端末の前記画面上において検証メッセージを提供する段階とを含み、
   前記取得は最大時間期間パラメータを含み、前記データがこの最大時間期間後に取得された場合には前記データは無効とみなされる、
   方法。
2. 請求項１記載の方法であって、前記データが無効である場合に：
   ・前記支払い端末から前記統合サーバーに失敗情報を送信し；
   ・前記端末の前記画面上で検証メッセージをユーザーに与える段階をも含む、方法。
3. 請求項１記載の方法であって、前記支払いトランザクションがスマート・カードを使う支払いトランザクションである場合、前記方法は、前記カードの存在に基づく検証のステップを含む、方法。
4. 請求項１記載の方法であって、前記取得要求および前記支払い端末の前記画面上でのその提示は、前記統合サーバーによってパーソナル化され、次いで前記統合サーバーから前記支払い端末に送信される、方法。
5. 請求項１ないし４のうちいずれか一項記載の方法であって、前記端末から前記統合端末への前記データの送信は、前記統合サーバーによって送られた応答メッセージを受信すると、完了されたと前記端末によってみなされ、前記メッセージは、前記サーバーによって、前記データの前記サーバーによる検証の前に送られる、方法。
6. 請求項５記載の方法であって、前記データが前記統合サーバーによって有効確認されない場合、前記データは前記統合サーバーによって統合されず、全体的な統計的結果は、取得要求全体の非統合により、有効確認されなかったデータによって影響されることがない、方法。
7. 請求項１ないし６のうちいずれか一項記載の方法であって、前記取得要求は調査キャンペーンを定義する要求の集合の一部であり、前記キャンペーンは、複数の支払いトランザクションが実行される一つまたは複数の支払い端末を介して実施され、前記パーソナル化は、前記複数の支払いトランザクションにわたって実施される前記キャンペーンの要求の集合の要求を分配するために、前記統合サーバーによって、実行され、それにより、前記支払い端末（単数または複数）によって集められるデータの統合は、統計的に有意な結果を得るために、統計的な大数の法則を使うことを可能にする、方法。
8. 請求項４記載の方法であって、前記パーソナル化は、前記統合サーバーまたは前記ユーザーのカードからくる、ユーザーに関連付けられた個人を特定しないパラメータを考慮に入れる、方法。
9. 請求項４記載の方法であって、前記取得要求は、複数のデータを相続いて収集するよう適応される、方法。
10. 請求項９記載の方法であって、前記パーソナル化は、前記複数のデータの収集の可変の順序を定義し、前記可変の順序は、前記ユーザーまたは環境に関連付けられたパラメータに依存する、方法。
11. 請求項１記載の方法であって、前記支払い端末は、前記取得要求または複数の取得要求を前記端末上に表示し、前記データまたは前記複数のデータを収集するための一連の命令のインタープリタを有し、前記インタープリタは、どの一連の命令もエンドレスな実行につながり得ないよう、戻る方向に分岐する命令を遮断し、動作時間を制限する、方法。
12. 請求項１１記載の方法であって、カードのPINコードはN桁を有し、前記インタープリタはN−Pより多くのデータの入力を禁止し、ここで、Pは1以上であり、それにより、前記端末において悪意をもってロードされた一連の命令がユーザーに、銀行カードの秘密のコードを入力させることを防止する、方法。
13. 請求項１記載の方法であっって、前記統合サーバーは、取得されたデータを、該取得されたデータの取得時刻を介して、ユーザーを性格付ける、個人を特定しないデータに関連付ける、方法。
14. 請求項１ないし１３のうちいずれか一項記載の方法の段階を実装するために、支払い端末のようなモバイル・デバイスのコンピュータ可読媒体上に記録されたプログラム・コード命令を含むコンピュータ・プログラム。
15. 統合サーバーを有する統計的情報収集システムであって、前記統合サーバーは、複数の支払いトランザクションを実行する一つまたは複数の支払い端末に接続され：
    ・ユーザーに尋ねるべき質問のリストの記憶部と；
    ・前記複数の支払い端末についての問い合わせプランを計算するコンピュータであって、前記プランは、各支払いトランザクションについて、前記質問のリストの部分集合を定義する、コンピュータと；
    ・各端末に、前記質問の部分集合を取得要求の形で送信し、前記端末に割り当てられた質問に対応するデータを収集するための各支払い端末との通信インターフェースであって、前記端末（単数または複数）は請求項１ないし１１のうちいずれか一項記載の方法を実装するよう設計されている、インターフェースと；
    ・ユーザーによって返される答えのリストの記憶部と；
    ・大数の法則を使うことによる取得されたデータの統合のための統計コンピュータとを有する、
    システム。

Images