JP2014524622A

JP2014524622A - 取引支払方法及びシステム

Info

Publication number: JP2014524622A
Application number: JP2014526367A
Authority: JP
Inventors: タオシアン、; シャオボリャオ、; ティエファリウ、; ダペンチャオ、; ユンシアフェン、; ミンチェン、
Original assignee: テンセントテクノロジー（シェンツェン）カンパニーリミテッド
Priority date: 2011-09-20
Filing date: 2012-06-15
Publication date: 2014-09-22
Also published as: WO2013040916A1; CA2844747A1; MX2014003427A; CN103020820A; US20140046850A1; KR20140070606A; EP2759968A1; AU2012313221A1; EP2759968A4; SG194639A1; TW201314600A; AP2014007582A0; RU2014115463A

Abstract

【課題】支払の安全性を向上させる取引支払方法及びシステムを提供する。
【解決手段】取引支払方法であって、通信番号を含むユーザの取引情報を取得するステップと、対話式音声応答プラットホームを通じて前記通信番号を呼び出し、ユーザが入力した支払パスワードを取得するステップと、前記支払パスワードと支払情報に対して認証を行い、認証を通過すれば支払を行うステップと、を有する。
【選択図】図１

Description

本発明は、２０１１年９月２０日に中国専利局に提出された、出願番号が２０１１１０２８０１２２７、発明の名称が「取引支払方法及びシステム」である中国特許出願の優先権を要求するものであり。当該中国特許出願の全ての内容は引用により本出願に組み合わせられる。

本発明は、ネットワーク技術に関し、特に、取引支払方法及びシステムに関する。

電子商取引の迅速な発展及び銀行電子化サービスのレベルの向上に伴い、銀行及びサードパーティの支払方法は絶えず革新している。現在既存の支払方法の種類は多数あり、従来のＰＯＳ支払、ＡＴＭ機支払、ネット銀行支払、モバイル銀行支払等の複数の支払方法を含み、人々に迅速かつ便利な支払方法を提供し、人々の日常生活に大きな便宜を与えている。

従来の取引支払方法は、通常、単一チャンネルの情報伝送方式を使用する。例えば、モバイル銀行は、モバイル通信運営業者のネットワークに頼って、ＷＡＰ技術に基づき携帯電話のユーザのためにアカウント照会、振込、払込、消費支払などの金融サービスを提供する。例えば、インターネット支払やネット銀行支払では、インターネットチャンネル或いは即時通信チャンネルで取引データが伝送される。

ところが、従来のこれらの取引支払い方法では、ユーザの身分情報を確認するとき様々な安全性の問題が存在する。例えば、モバイル銀行では、携帯電話が紛失しやすかったり、インターネット支払、ネット銀行支払では、通常、ユーザパスワードを認証するのみであり、ユーザの身分情報を認証する方法は単一である。このため、ユーザ端末ＰＣにトロイの木馬やウイルスが存在する場合にデータが盗まれやすい。したがって、従来の取引支払方法の安全性は高くない。

以上に鑑み、安全性を高める取引支払方法を提供する必要がある。

通信番号を含むユーザの支払情報を取得するステップと、
対話式音声応答プラットホームを通じて前記通信番号を呼び出し、ユーザが入力した支払パスワードを取得するステップと、
前記支払パスワードと支払情報に対して認証を行い、認証を通過すれば支払を行うステップと、
を有する取引支払方法。

好ましくは、前記ユーザの支払情報を取得するステップは、インターネットチャンネル又は即時通信チャンネルを通じて支払端末が提出したユーザの支払情報を取得するステップである。

好ましくは、前記通信番号はモバイル通信番号であり、対話式音声応答プラットホームを通じて前記モバイル通信番号を呼び出すステップの前に、
ＳＭＳプラットホームを通じて前記モバイル通信番号に対応するモバイル端末にＳＭＳ認証コードを配信するステップと、
前記モバイル端末が返信した返答認証コードを受け付けるステップと、
前記返答認証コードが前記ＳＭＳ認証コードと一致するか否かを判断し、そうであれば認証を通過し、そうでなければ認証を通過しないステップと、
をさらに有する。

好ましくは、対話式音声応答プラットホームを通じて前記モバイル通信番号を呼び出すステップの前に、
返答認証コードを返信したモバイル端末のモバイル通信番号を取得するステップと、
前記取得したモバイル通信番号が、予め記憶されているアカウント情報の中のモバイル通信番号と一致するか否かを認証し、そうであれば認証を通過し、そうでなければ認証を通過しないステップと、
をさらに有する。

好ましくは、返答認証コードが認証に通過したステップ及び／又は返答認証コードを返信したモバイル端末のモバイル通信番号が認証に通過したステップの後、
前記支払情報に対してリスク情報点検を行うステップと、
をさらに有する。

好ましくは、対話式音声応答プラットホームを通じて前記通信番号を呼び出すステップの前に、及び／又は前記支払パスワードが認証に通過した後、
前記支払情報に対してリスク情報点検を行うステップと、
をさらに有する。

好ましくは、前記支払情報に対してリスク情報点検を行うステップは、
前記支払情報の中の業者限度額を取得し、前記業者限度額が所定の閾値より大きいか否かを検出し、そうであれば点検を通過せず、そうでなければ点検を通過するステップ、及び／又は
前記支払情報に基づきユーザがブラックリストユーザであるか否かを判断し、そうであれば点検を通過せず、そうでなければ点検を通過するステップと、
を有する。

好ましくは、前記の前記支払情報に対してリスク情報点検を行うステップは、
前記支払情報が予め記憶されているアカウント情報と一致するか否かを判断し、そうであれば点検を通過し、そうでなければ点検を通過しないステップと、
をさらに有する。

また、安全性を向上させる取引支払システムをさらに提供する必要がある。

取引支払システムであって、前記システムは電話支払システムと銀行システムとを含み、
電話支払システムは、
通信番号を含むユーザの支払情報を取得する支払情報取得モジュールと、
前記通信番号を呼び出し、ユーザが入力した支払パスワードを取得し、前記支払パスワードと支払情報を銀行システムに送信する対話式音声応答プラットホームと、を有し、
銀行システムは、前記支払パスワードと支払情報に対して認証を行い、認証を通過すれば支払を行う、取引支払システム。

好ましくは、前記支払情報取得モジュールは、インターネットチャンネル又は即時通信チャンネルを通じて支払端末が提出したユーザの支払情報を取得する。好ましくは、前記通信番号はモバイル通信番号であり、前記電話支払システムは、さらに、ＳＭＳプラットホームを含み、前記ＳＭＳプラットホームはＳＭＳを通じて前記モバイル通信番号に対応するモバイル端末にＳＭＳ認証コードを配信し、前記モバイル端末が返信した返答認証コードを受け付け、前記返答認証コードが前記ＳＭＳ認証コードと一致するか否かを判断し、そうであれば認証を通過し、そうでなければ認証を通過しない。

好ましくは、前記ＳＭＳプラットホームは、さらに、返答認証コードを返信したモバイル端末のモバイル通信番号を取得し、前記モバイル通信番号を前記銀行システムに送信し、
前記銀行システムは、さらに、前記取得したモバイル通信番号が予め記憶されたアカウント情報の中のモバイル通信番号と一致するか否かを認証し、そうであれば認証を通過し、そうでなければ認証を通過しない。

好ましくは、前記電話支払システムは、返答認証コードが認証に通過し、及び／又は返答認証コードを返信したモバイル端末のモバイル通信番号が認証に通過した後、前記支払情報に対してリスク情報点検を行うリスク制御システムをさらに有する。

好ましくは、前記リスク制御システムは、さらに、前記電話支払システムが対話式音声応答プラットホームを通じて前記通信番号を呼び出す前に、及び／又は前記支払パスワードが認証に通過した後、前記支払情報に対してリスク情報点検を行う。

好ましくは、前記リスク制御システムは、前記支払情報の中の業者限度額を取得し、前記業者限度額が所定の閾値より大きいか否かを検出し、そうであれば点検を通過せず、そうでなければ点検を通過し、及び／又は
前記リスク制御システムは、前記支払情報に基づきユーザがブラックリストユーザであるか否かを判断し、そうであれば点検を通過せず、そうでなければ点検を通過する。

好ましくは、前記リスク制御システムは、さらに、前記支払情報を前記銀行システムに送信し、
前記銀行システムは、さらに、前記支払情報が予め記憶されているアカウント情報と一致するか否かを判断し、そうであれば点検を通過し、そうでなければ点検を通過しない。

以上の取引支払方法及びシステムでは、電話支払システムが支払情報を受信した後、対話式音声応答プラットホームを通じて支払い情報におけるモバイル通信番号を自動的に呼び出し、ユーザが入力した支払パスワードを取得し、且つ支払パスワードと支払情報を認証する。支払端末が提出する支払情報を取得するのに使用するチャンネルと対話式音声応答プラットホームが使用するチャンネルが異なるため、支払パスワードと支払情報を認証するとき、不審者が偽のウェブサイト、トロイの木馬、ウイルスによってユーザの支払情報を捕獲する可能性を減少させ、よって安全性を向上させることができる。

一の実施例における取引支払方法のフロー模式図。もう一つの実施例における取引支払方法のフロー模式図。一の実施例において、リスク情報点検を行うフロー図。一の実施例における取引支払システムの構造模式図。もう一つの実施例における電話支払システムの構造模式図。

図１に示すように、一の実施例において、取引支払方法であって、以下のステップを含む。

ステップＳ１０２、支払端末がユーザの支払情報を取得する。当該支払情報は通信番号を含み、支払い端末は当該支払情報を電話支払システムに提出する。

支払端末は、コンピュータ、テレビ、モバイル通信端末及び他の埋め込み型電子装置であってもよく、ウェブブラウザを通じて注文書を提出し、または即時通信ツールを通じて注文書を提出して、注文書データを生成する。注文書データは、ユーザ情報、業者情報、購入した商品の情報等を含む。このうち、ユーザ情報は、ユーザ登録アカウント番号、ユーザ名称、送付先住所、連絡先等を含む。業者情報は売主情報であり、例えば店舗名称、住所、連絡先等であり、購入した商品情報は購入数量、購入価格、支払金額等を含む。

支払端末を通じて注文書を提出し、支払が確認された後、ユーザの支払情報を取得する。ユーザの支払情報は銀行カード番号、ユーザ身分情報、注文書関連情報を含み、このうちユーザ身分情報は身分証明書情報（ユーザ氏名及び身分証明書番号等を含む）、支払パスワード、通信番号（モバイル通信番号であってもよく、固定通信番号であってもよい）、即時通信番号、連絡住所等を含むがこれに限らず、注文書関連情報は支払金額等を含む。一の実施例において、ユーザが注文書データを提出した後、告示欄がポップアップしてユーザに支払情報を記入するように告示してもよい。具体的には、支払端末は、インターネットチャンネルまたは即時通信チャンネルを通じて支払情報を電話支払システムに提出し、電話支払システムは、インターネットチャンネル又は即時通信チャンネルを通じて支払端末が提出したユーザの支払情報を取得する。

ステップＳ１０４、電話支払チャンネルは、対話式音声応答プラットホームを通じて前記通信番号を呼び出してユーザが入力した支払パスワードを取得し、支払パスワードと支払情報を銀行システムに送信する。

具体的には、電話支払システムには対話式音声応答プラットホーム（ＩｎｔｅｒａｃｔｉｖｅＶｏｉｃｅＲｅｓｐｏｎｓｅ、ＩＶＲ）が設置されており、ＩＶＲプラットホームを通じて支払情報にある通信番号を呼び出す。当該通信番号に対応する通信端末は呼び出しを受け付け、当該通信端末を持っているユーザが受け取った後、通信端末はＩＶＲプラットホームと接続を設立し、通信端末は、ＩＶＲプラットホームから音声チャンネルを通じて配信された音声告示を受け付け、ユーザは音声告示に従って支払パスワードを入力する。端末は、支払パスワードを電話支払システムにアップロードし、電話支払システムは、支払パスワードと支払情報を取引メッセージとして整理し、銀行システムに送信する。

ステップＳ１０６、銀行システムは、支払パスワードと支払情報を認証し、認証を通過した場合は支払を行う。

具体的には、銀行システムは、銀行支払システムであってもよく、任意の取引プラットホーム上の支払システムでもよい。銀行システムは、ユーザのアカウント情報を予め記憶しており、ユーザのアカウント情報は、身分証明書情報、開いた銀行カード番号、連絡住所、モバイル通信番号、支払パスワードなどを含む。銀行システムは、支払パスワードと支払情報を受け付けた後、ユーザが入力した支払パスワードが正しいか否かを認証し、且つ支払情報がユーザのアカウント情報と合致するかを認証し、正しければ認証を通過し、直接引き落としを行う。

もう一つの実施例において、銀行システムが支払を完了した後、電話支払システムに通知し、電話支払システムによりユーザの注文書状態などを変更する。

もう一つの実施例において、ステップＳ１０４の前に、支払情報に対してリスク情報を点検するステップを更に含む。支払情報のリスク情報点検を通過して初めてＩＶＲプラットホームが通信番号を呼び出すことにより、呼び出し前の安全性を確保することができる。本実施例またはもう一つの実施例において、ステップＳ１０６で支払パスワードに対して認証を通過した後、支払情報に対してリスク情報点検のステップを更に含む。支払パスワードの認証を通過した後でも支払い情報はまだ変更できる場合があるため、支払情報のリスク情報点検を通過して初めて銀行システムが引き落としを行うことにより、さらに支払の安全性を向上させることができる。

支払端末による支払情報の提出とＩＶＲプラットホームによる支払パスワードの取得ではそれぞれ異なるチャンネルを通じてデータ伝送が行われるため、二つのチャンネルで支払情報を認証することができ、安全性を向上させる。さらに、電話支払システムが支払情報を受け付けた後、ＩＶＲプラットホームを通じて支払情報の中の通信番号を自動的に呼び出して支払パスワードを取得するが、従来のユーザが自発的にＩＶＲプラットホームを呼び出して支払パスワードを提供する方法と比べ、支払パスワードを提供するユーザが通信番号に対応する端末の保持者であることを確認できる。支払パスワードが盗まれた場合でも、提供された通信番号を自動的に呼び出すことにより、支払を効果的に阻止することができ、さらに安全性を向上させる。

図２に示すように、もう一つの実施例において、取引支払方法であって、以下のステップを含む。

ステップＳ２０２、支払端末がユーザの支払情報を取得する。当該支払情報はモバイル通信番号を含み、支払端末は支払情報を電話支払システムに提出する。

ステップＳ２０４、ＳＭＳプラットホームを通じてモバイル通信番号に対応するモバイル端末にＳＭＳ認証コードを配信する。

ステップＳ２０６、モバイル端末が返信した返答認証コードを受け付ける。

具体的には、モバイル端末がＳＭＳを受け付けた後、ユーザが返答認証コードを入力し、返答認証コードをＳＭＳプラットホームに返信する。

ステップＳ２０８、返答認証コードとＳＭＳ認証コードが一致するか否かを判断し、一致する場合はステップＳ２１０に進み、一致しない場合は終了する。

一つの実施例において、返答認証コードとＳＭＳ認証コードが一致しない場合、ＳＭＳを配信してユーザが返信した認証コードが間違っており、支払が完了できないことを告示する。このように、ＳＭＳチャンネルを通じてデータを伝送し、再度支払情報について認証することにより、安全性をさらに向上させる。

ステップＳ２１０、返答認証コードを返信したモバイル端末のモバイル通信番号を取得する。

ステップＳ２１２、銀行システムを通じて取得したモバイル通信番号が、予め記憶されたアカウント情報にあるモバイル通信番号が一致するか否かを認証し、一致する場合はステップＳ２１４に進み、一致しない場合は終了する。

銀行システムには、予めユーザのアカウント情報が記憶されており、当該アカウント情報には、ユーザが銀行カードを開いたときに提供したモバイル通信番号が含まれる。銀行システムが取得したモバイル通信番号と予め記憶されているアカウント情報のモバイル通信番号が一致した場合は、認証を通過し、そうでなければ、認証を通過しない。

一つの実施例において、認証を通過しない場合、銀行システムは電話支払システムに通知する。電話支払システムは、ＳＭＳプラットホームを通じてモバイル端末にＳＭＳを配信し、ユーザに認証を通過せず、支払が完了できないことを告示してもよい。銀行システムを通じて返答認証コードを返信したモバイル通信番号に対して認証を行うことにより、モバイル端末の保持者が銀行カードのユーザであることを確認し、モバイル端末の紛失により銀行カードの金銭が紛失するリスクを回避し、安全性を更に向上させる。

また、モバイル通信番号を呼び出す前に、ＳＭＳ認証コードに対して認証を行い、且つ返答認証コードを返信したモバイル通信番号に対して認証を行うことにより、モバイル通信端末の呼び出し転送により発生する安全性の問題を回避することができる。

ステップＳ２１４、支払情報に対してリスク情報点検を行い、点検を通過した場合はステップＳ２１６に進む。

ステップＳ２１６、電話支払システムは、ＩＶＲプラットホームを通じてモバイル通信番号を呼び出し、ユーザが入力した支払パスワードを取得し、支払パスワードと支払情報を銀行システムに送信する。

以上のように、具体的には、モバイル通信番号に対応するモバイル端末は呼び出しを受け付け、当該モバイル端末を持っているユーザが受け取った後、モバイル端末とＩＶＲプラットホームは接続を設立する。モバイル端末は、ＩＶＲプラットホームが音声チャンネルを通じて配信した音声告示を受け付け、ユーザが音声告示に基づいて支払パスワードを入力し、モバイル端末は支払パスワードを電話支払システムにアップロードする。電話支払システムは、支払パスワードと支払情報を取引メッセージとして整理し、銀行システムに送信する。

ステップＳ２１８、銀行システムは、支払パスワードと支払情報に対して認証を行い、認証を通過すれば支払を行う。

具体的には、銀行システムは支払パスワードが正しいか否かを認証し、及び支払情報があらかじめ記憶されたアカウント情報と一致するか否かを認証し、肯定的であれば認証を通過し、直接引き落とし、そうでなければ、電話支払システムに通知し、ＩＶＲプラットホームにより音声告示をモバイル端末に配信し、パスワードが間違っているか或いは支払情報が誤っていることをユーザに告示する。

一の実施例において、上記の支払情報に対してリスク情報点検を行うステップは、取引情報の中の業者限度額を取得し、当該業者限度額が所定の閾値を上回るか否かを検出し、そうであれば、点検を通過せず、そうでなければ点検を通過するステップを含む。業者限度額は、注文書の取引限度額、例えば一回の取引における数量、金額等であり、所定の閾値の数量、金額を超える取引はリスク（銀行カードが盗用されている可能性など）があると考えられるため、点検を通過しない。このようにして、効果的に支払の安全性を向上させることができる。

本実施例において、又はもう一つの実施例において、支払情報に対してリスク情報点検を行うステップは、支払情報に基づいてユーザがブラックリストユーザであるか否かを判断し、そうであれば点検を通過せず、そうでなければ点検を通過するステップをさらに含む。ユーザの取引に不良な記録が存在する場合、例えば支払情報の認証が二回失敗した場合は、当該ユーザを不法とみなし、ユーザの身分情報をブラックリストに追加する。ブラックリストにあるユーザは、リスク情報点検を行うとき点検を通過せず、即ち不法ユーザは支払を完了させることができない。このようにして、不法ユーザが再度取引を行うことを回避し、支払の安全性をさらに向上させる。

もう一つの実施例において、支払情報に対してリスク情報点検を行うステップは、電話支払システムが支払情報を銀行システムに送信し、銀行システムにより支払情報が予め記憶されているアカウント情報と一致するか否かを判断し、そうであれば点検を通過し、そうでなければ点検を通過しないステップをさらに含む。

図３に示すように、一の実施例において、ステップＳ２１４において、支払情報に対してリスク情報点検を行う手順は以下の通りある。

ステップＳ３０２、支払情報に基づいて、ユーザがブラックリストユーザであるか否かを判断し、そうであればフローを終了し、そうでなければステップＳ３０４に進む。

ステップＳ３０４、支払情報に基づいて、業者限度額が所定の閾値より大きいか否かを判断し、そうであればフローを終了し、そうでなければステップＳ３０６に進む。

ステップＳ３０６、点検済みの支払情報が存在するか否かを判断し、そうであればステップ２１６に進み、その後のフローに進み、そうでなければステップＳ３０８に進む。

ステップＳ３０８、ユーザに支払情報を記入するよう告示する。

ステップＳ３１０、ユーザが記入した支払情報に対してリスク情報点検を行う。

ステップＳ３１０において、支払情報に対してリスク情報点検を行う手順は以上に示したため、ここでは説明しないこととする。

一の実施例において、ステップＳ２１８で支払パスワードの認証を通過しても、更に支払情報に対してリスク情報点検を行ってもよく、例えば支払情報に基づいて、業者限度額が所定の閾値を上回るか否かを判断することができる。支払パスワードが認証を通過した後に、ユーザが支払情報を変更する可能性があるため、再度リスク情報点検を行うことにより、さらに安全性を向上させることができる。

図４に示すように、一の実施例において、支払端末１０と、電話支払システム２０と、銀行システム３０と、を有する取引支払システムであって、
支払端末１０はユーザの支払情報を取得する。当該支払情報は通信番号を含み、支払端末１０は、さらに、支払情報を電話支払システム２０に提出する。

電話支払システム２０は、ＩＶＲプラットホーム２０２を含み、ＩＶＲプラットホーム２０２は通信番号を呼び出し、ユーザが入力した支払パスワードを取得し、且つ支払パスワードと支払情報を銀行システム３０に送信する。

銀行システム３０は、支払パスワードと支払情報に対して認証を行い、認証を通過すれば支払を行う。

一の実施例において、ユーザが支払端末１０を通じて注文書を提出し、注文書データはユーザ情報、業者情報、購入した商品の情報などを含む。このうち、ユーザ情報は、ユーザ登録アカウント番号、ユーザ名称、送付先住所、連絡先等を含む。業者情報は、売主情報であり、例えば店舗名称、住所、連絡先等であり、購入した商品の情報は購入数量、購入価格、支払金額等を含む。

支払端末を通じて注文書を提出し、支払が確認された後、ユーザの支払情報を取得する。ユーザの支払情報は、銀行カード番号、ユーザ身分情報、注文書関連情報を含み、このうちユーザ身分情報は、身分証明書情報（ユーザ氏名及び身分証明書番号等を含む）、支払パスワード、通信番号（モバイル通信番号であってもよく、固定通信番号であってもよい）、即時通信番号、連絡住所等を含むがこれに限らず、注文書関連情報は支払金額等を含む。一の実施例において、ユーザが注文書データを提出した後、告示欄がポップアップしてユーザに支払情報を記入するように告示するようにしてもよい。具体的には、支払端末１０は、インターネットチャンネルまたは即時通信チャンネルを通じて支払情報を電話支払システム２０に提出する。

さらに、電話支払システム２０は、支払情報取得モジュールを含むことができ、インターネットチャンネル又は即時通信チャンネルを通じて支払端末１０が提出したユーザの支払情報を取得することができる。

一の実施例において、ＩＶＲプラットホーム２０２を通じて支払情報の中の通信番号を呼び出し、当該通信番号に対応する通信端末は呼び出しを受け付け、当該通信端末を持っているユーザが受け取った後、通信端末はＩＶＲプラットホーム２０２と接続を設立する。通信端末は、ＩＶＲプラットホーム２０２から音声チャンネルを通じて配信された音声告示を受け付け、ユーザは音声告示に従って支払パスワードを入力する。通信端末は、支払パスワードを電話支払システム２０にアップロードし、電話支払システム２０により支払パスワードと支払情報を取引メッセージとして整理し、銀行システム３０に送信する。

具体的には、銀行システム３０は、銀行支払システムであってもよく、任意の取引プラットホーム上の支払システムでもよい。銀行システム３０は、ユーザのアカウント情報を予め記憶しており、ユーザのアカウント情報は身分証明書情報、開いた銀行カード番号、連絡住所、モバイル通信番号、支払パスワードなどを含む。銀行システム３０は、支払パスワードと支払情報を受け付けた後、ユーザが入力した支払パスワードが正しいか否かを認証し、且つ支払情報がユーザのアカウント情報と合致するかを認証し、正しければ認証を通過し、直接引き落としを行って、支払を完了させる。

もう一つの実施例において、電話支払システム２０は、さらに、注文書を管理するためのコア支払システム（図示せず）を有してもよい。銀行システム３０が支払を完了させた後、コア支払システムに通知し、コア支払システムにより注文書状態を変更し当該注文書状態を支払端末１０に返信する。

もう一つの実施例において、図５に示すように、電話支払システム２０は、さらに、ＳＭＳプラットホーム２０４を有し、ＳＭＳプラットホーム２０４は、ＳＭＳを通じて支払情報の中のモバイル通信番号に対応するモバイル端末にＳＭＳ認証コードを配信し、当該モバイル端末が返信した返答認証コードを受け付け、返答認証コードがＳＭＳ認証コードと一致するか否かを判断し、そうである場合は認証を通過し、そうでなければ認証を通過しない。

一の実施例において、ＳＭＳプラットホーム２０４は、さらに、返答認証コードを返信したモバイル端末のモバイル通信番号を取得し、当該モバイル通信番号を銀行システム３０に送信する。本実施例において、銀行システム３０は、さらに、取得したモバイル通信番号が予め記憶されているアカウント情報の中にあるモバイル通信番号と一致するか否かを認証し、そうであれば認証を通過し、そうでなければ認証を通過しない。

一の実施例において、図５に示すように、電話支払システム２０は、返答認証コードが認証に通過し及び／又は返答認証コードを返信したモバイル端末のモバイル通信番号が認証を通過した後、支払情報に対してリスク情報点検を行うリスク制御システム２０６をさらに有する。

一の実施例において、リスク制御システム２０６は、さらに、電話支払システム２０がＩＶＲプラットホーム２０２を通じて通信番号を呼び出すステップの前に、支払情報に対してリスク情報点検を行う。本実施例又はもう一つの実施例において、リスク制御システム２０６は、さらに、支払パスワードが認証を通過した後、支払情報に対してリスク情報点検を行う。

一の実施例において、リスク制御システム２０６は、支払情報の中の業者限度額を取得し、業者限度額が所定の閾値を上回るか否かを検出し、そうであれば点検を通過せず、そうでなければ点検を通過する。本実施例又はもう一つの実施例において、リスク制御システム２０６は、さらに、支払情報に基づいて、ユーザがブラックリストユーザであるか否かを判断し、そうであれば点検を通過せず、そうでなければ点検を通過する。

一の実施例において、リスク制御システム２０６は、さらに、支払情報を銀行システム３０に送信する。本実施例において、銀行システム３０は、さらに、支払情報が予め記憶されているアカウント情報と一致するか否かを判断し、そうであれば点検を通過し、そうでなければ点検を通過しない。

以上の取引支払方法及びシステムにおいて、モバイル端末、インターネット、ＩＶＲプラットホーム、ＳＭＳプラットホーム等複数の通信チャンネルを通じて、ユーザの支払情報を収集し、ユーザの支払情報が全部盗み取られる難易度を大幅に増大させ、よって非対面式の支払の安全性を向上させる。

以上の取引支払方法及びシステムにおいて、ＳＭＳ認証を通じてモバイル端末の保持者を確認し、銀行システムを通じて銀行カード保持者の身分、モバイル通信番号などの情報を確認し、複数の通信チャンネルを通じてユーザの身分情報を認証し、安全な支払を確保する。

当業者は、コンピュータプログラムを通じて関連するハードウェアに指令することにより以上の実施例の方法のすべて又は一部のフローを実現することができ、前記のプログラムはコンピュータ読込可能な記憶媒体に記憶することができ、当該プログラムを実行するときに上記各方法の実施例のフローを含むことができることを理解する。ただし、前記の記憶媒体は、テープ、光学ディスク、ＲＯＭ（Ｒｅａｄ―ＯｎｌｙＭｅｍｏｒｙ）又はＲＡＭ（ＲａｎｄｏｍＡｃｃｅｓｓＭｅｍｏｒｙ）等であってもよい。

以上の実施例は本発明のいくつかの実施形態を示したにすぎず、当該説明は比較的に具体的であり、詳しいものとなっているが、本発明の特許範囲を限定するものと理解してはならない。指摘しなければならないことは、当業者にとって、本発明の趣旨を逸脱しないことを前提に、ある程度の変更や改良を行うことができ、これらは本発明の保護範囲に含まれる。したがって、本発明特許の保護範囲は添付された特許請求の範囲を基準とする。

Claims

通信番号を含むユーザの支払情報を取得するステップと、
対話式音声応答プラットホームを通じて前記通信番号を呼び出し、ユーザが入力した支払パスワードを取得するステップと、
前記支払パスワードと支払情報に対して認証を行い、認証を通過すれば支払を行うステップと、
を有する取引支払方法。
前記ユーザの支払情報を取得するステップは、インターネットチャンネル又は即時通信チャンネルを通じて支払端末が提出したユーザの支払情報を取得するステップであることを特徴とする請求項１に記載の取引支払方法。
前記通信番号はモバイル通信番号であり、対話式音声応答プラットホームを通じて前記モバイル通信番号を呼び出すステップの前に、
ＳＭＳプラットホームを通じて前記モバイル通信番号に対応するモバイル端末にＳＭＳ認証コードを配信するステップと、
前記モバイル端末が返信した返答認証コードを受け付けるステップと、
前記返答認証コードが前記ＳＭＳ認証コードと一致するか否かを判断し、そうであれば認証を通過し、そうでなければ認証を通過しないステップと、
をさらに有することを特徴とする請求項１に記載の取引支払方法。
対話式音声応答プラットホームを通じて前記モバイル通信番号を呼び出すステップの前に、
返答認証コードを返信したモバイル端末のモバイル通信番号を取得するステップと、
前記取得したモバイル通信番号が、予め記憶されているアカウント情報の中のモバイル通信番号と一致するか否かを認証し、そうであれば認証を通過し、そうでなければ認証を通過しないステップと、
をさらに有することを特徴とする請求項３に記載の取引支払方法。
返答認証コードが認証に通過したステップ及び／又は返答認証コードを返信したモバイル端末のモバイル通信番号が認証に通過したステップの後、
前記支払情報に対してリスク情報点検を行うステップと、
をさらに有することを特徴とする請求項４に記載の取引支払方法。
対話式音声応答プラットホームを通じて前記通信番号を呼び出すステップの前に、及び／又は前記支払パスワードが認証を通過した後、
前記支払情報に対してリスク情報点検を行うステップと、
をさらに有することを特徴とする請求項１に記載の取引支払方法。
前記の前記支払情報に対してリスク情報点検を行うステップは、
前記支払情報の中の業者限度額を取得し、前記業者限度額が所定の閾値より大きいか否かを検出し、そうであれば点検を通過せず、そうでなければ点検を通過するステップ、及び／又は
前記支払情報に基づきユーザがブラックリストユーザであるか否かを判断し、そうであれば点検を通過せず、そうでなければ点検を通過するステップと、
を有することを特徴とする請求項５または６に記載の取引支払方法。
前記の前記支払情報に対してリスク情報点検を行うステップは、
前記支払情報が予め記憶されているアカウント情報と一致するか否かを判断し、そうであれば点検を通過し、そうでなければ点検を通過しないステップと、
をさらに含むことを特徴とする請求項７に記載の取引支払方法。
取引支払システムであって、前記取引支払システムは電話支払システムと銀行システムとを含み、
電話支払システムは、
通信番号を含むユーザの支払情報を取得する支払情報取得モジュールと、
前記通信番号を呼び出し、ユーザが入力した支払パスワードを取得し、前記支払パスワードと支払情報を銀行システムに送信する対話式音声応答プラットホームと、を有し、
銀行システムは、前記支払パスワードと支払情報に対して認証を行い、認証を通過すれば支払を行うことを特徴とする取引支払システム。
前記支払情報取得モジュールは、インターネットチャンネル又は即時通信チャンネルを通じて支払端末が提出したユーザの支払情報を取得することを特徴とする請求項９に記載の取引支払システム。
前記通信番号はモバイル通信番号であり、前記電話支払システムは、さらに、ＳＭＳプラットホームを含み、前記ＳＭＳプラットホームはＳＭＳを通じて前記モバイル通信番号に対応するモバイル端末にＳＭＳ認証コードを配信し、前記モバイル端末が返信した返答認証コードを受け付け、前記返答認証コードが前記ＳＭＳ認証コードと一致するか否かを判断し、そうであれば認証を通過し、そうでなければ認証を通過しないことを特徴とする請求項９に記載の取引支払システム。
前記ＳＭＳプラットホームは、さらに、返答認証コードを返信したモバイル端末のモバイル通信番号を取得し、前記モバイル通信番号を前記銀行システムに送信し、
前記銀行システムは、さらに、前記取得したモバイル通信番号が予め記憶されたアカウント情報の中のモバイル通信番号と一致するか否かを認証し、そうであれば認証を通過し、そうでなければ認証を通過しないことを特徴とする請求項１１に記載の取引支払システム。
前記電話支払システムは、返答認証コードが認証に通過し、及び／又は返答認証コードを返信したモバイル端末のモバイル通信番号が認証を通過した後、前記支払情報に対してリスク情報点検を行うリスク制御システムをさらに有することを特徴とする請求項１２に記載の取引支払システム。
前記リスク制御システムは、さらに、前記電話支払システムが対話式音声応答プラットホームを通じて前記通信番号を呼び出す前に、及び／又は前記支払パスワードが認証を通過した後、前記支払情報に対してリスク情報点検を行うことを特徴とする請求項１３に記載の取引支払システム。
前記リスク制御システムは、前記支払情報の中の業者限度額を取得し、前記業者限度額が所定の閾値より大きいか否かを検出し、そうであれば点検を通過せず、そうでなければ点検を通過し、及び／又は
前記リスク制御システムは、前記支払情報に基づきユーザがブラックリストユーザであるか否かを判断し、そうであれば点検を通過せず、そうでなければ点検を通過することを特徴とする請求項１３又は１４に記載の取引支払システム。
前記リスク制御システムは、さらに、前記支払情報を前記銀行システムに送信し、
前記銀行システムは、さらに、前記支払情報が予め記憶されているアカウント情報と一致するか否かを判断し、そうであれば点検を通過し、そうでなければ点検を通過しないことを特徴とする請求項１５に記載の取引支払システム。