JP2017504090A - 送金を管理するための方法、デバイス及びシステム - Google Patents

Abstract

送金するための方法は、第１のクライアントデバイスによって支払金額を取得すること；第１のクライアントデバイスによってオフラインである第２のクライアントデバイスからアプリケーションアカウント情報を取得すること、ここで、アプリケーションアカウントは第２のクライアントデバイスにインストールされた送金アプリケーションのログインアカウントであり、且つ利用可能な資金を有する；及び第１のクライアントデバイスによって支払金額とアプリケーションアカウント情報を処理ユニットに送信することを含む。利用可能な資金が支払金額よりも大きい場合、処理ユニットは、ユーザの銀行口座から販売業者の口座に支払金額を送金する。利用可能な資金が支払金額未満である場合、第２のクライアントデバイスがインターネットに接続した時、第２のクライアントデバイスのユーザがアプリケーションアカウントの利用可能な資金を増加することができるように、処理ユニットは、ウエブページを第２のクライアントデバイスに送信する。

Description

本発明は、インターネット技術分野に関し、より具体的には、送金を管理するための方法、デバイス及びシステムに関する。

このセクションでの記述は、本開示に関連する背景情報を単に提供しており、従来の技術を構成してはいない。

オフライン支払のようなオフライン送金は、インターネットに接続されるユーザのデバイス（即ち、バイヤーのデバイス）を使用することのない送金を指す。オフライン送金は、その便利さのためにユーザにとっては好ましい。オフライン送金を行う一つの方法は、マネーカードのようなストアドバリューカードによるものであり、ユーザは、そのストアドバリューカードに前払いしてそのカードを指定の店で使用する。お金は、その値がゼロになるまで又は要求された支払金額未満になるまでストアドバリューカードから差し引かれる。

ストアドバリューカードは、一般的に、パスワードなしでの少額の支払いのために使用される。その安全性が低いために、ユーザは、一般的に、少額をそのカードに保ち、必要に応じて指定の場所でそのカードをリチャージする。ユーザは、特定の支払いのためにそのカードが十分な資金または金額を有するか否かを常に注意をしている必要がある。

従来技術の問題を解決するために、本発明は、送金における効率と便利さを向上するための送金を管理するための方法、デバイス及びシステムを提供する。

一形態では、送金を行うための方法は：第１のクライアントデバイスによって、支払金額を取得すること；第１のクライアントデバイスによって、オフラインである第２のクライアントデバイスからアプリケーションアカウント情報を取得すること、ここで、アプリケーションアカウントとは、第２のクライアントデバイスにインストールされた送金アプリケーションのログインアカウントであり、且つ利用可能な資金を有し；及び第１のクライアントデバイスによって、支払金額とアプリケーションアカウント情報を処理ユニットに送信することを含む。利用可能な資金が支払金額よりも大きい場合、処理ユニットは、ユーザの銀行口座から支払金額を販売業者のアカウントに転送する。利用可能な資金が支払金額未満である場合、第２のクライアントデバイスがインターネットに接続したとき、処理ユニットは、第２のクライアントデバイスのユーザがアプリケーションアカウントに利用可能な資金を増加するためのウエブページを第２のクライアントデバイスに送信する。

他の一形態では、処理ユニットは：第１のクライアントデバイスによって送信される支払金額を受信し且つ第２のクライアントデバイスからアプリケーションアカウント情報を取得するように構成される受信モジュール；アプリケーションアカウント情報に従って第２のクライアントデバイスのアプリケーションアカウントを決定するように構成される決定モジュール；及びアプリケーションアカウントに対応する銀行口座から第１のクライアントデバイスに対応する銀行口座に送金し、且つ支払金額に従って、アプリケーションアカウントの利用可能な資金から支払金額を差し引くように構成される管理モジュールを含む。

更に他の一形態では、第１のクライアントデバイスは：第２のクライアントデバイスから支払金額を取得して、且つアプリケーションアカウント情報を取得するように構成される取得モジュール；及び支払金額及びアプリケーションアカウント情報を処理ユニットに送信するように構成された送信モジュールを含み、それによって、処理ユニットは、アプリケーションアカウント情報に従って、第２のクライアントデバイスのアプリケーションアカウントを決定し、且つアプリケーションアカウントに対応する銀行口座から第１のクライアントデバイスに対応する銀行口座に送金し、次に、アプリケーションアカウントの利用可能な資金から支払金額を差し引く。

更に他の一形態では、送金を管理するためのシステムは、第１のクライアントデバイス、第２のクライアントデバイス及び処理ユニットを含む。第１のクライアントデバイスは、支払金額を取得して、第２のクライアントデバイスからアプリケーションアカウント情報を取得して、且つ支払金額とアプリケーションアカウント情報を処理ユニットに送信するように構成される。処理ユニットは、支払金額とアプリケーションアカウント情報を受信し、アプリケーションアカウント情報に基づいて第２のクライアントデバイスのアプリケーションアカウントを決定し、且つアプリケーションアカウントに対応する銀行口座から第１のクライアントデバイスに対応する銀行口座へ送金し、次に、アプリケーションアカウントにおける利用可能な資金から支払金額を差し引くように構成される。

本開示の更なる態様は、以下において、部分的に明白であり且つ部分的に指摘される。本開示の様々な態様は、個別的に又は互いに組合せて実行されることができることが理解されるべきである。また、本開示の特定の例示的形態を指摘する詳細な記載及び図面は、単に説明目的を意図しており且つ本開示の範囲を制限するものと解釈されるべきではないことが理解されるべきである。

本開示がより良く理解されるように、例として与えられる本開示の様々な形態が記述され、添付の図面が参照される。

本開示の教示に係る送金を管理するための方法を実施するための例示的環境のブロック図である。 本発明の第１の実施形態に係る送金を管理するための方法のフローチャートである。 本発明の第１の実施形態に係る送金を管理するための方法のフローチャートである。 本発明の一実施形態に係る処理ユニットのブロック図である。 本発明の一実施形態に係る第１のクライアントデバイスのブロック図である。 本発明の第２の実施形態に係る処理ユニットのブロック図である。

この発明の他の態様、特徴、及び利点は、添付の図面と併用される以下の詳細な記載から明白になる。以下の記載は、実際上単なる例示であり、本開示やその開示の用途又は使用を制限する意図はない。

図１は、本明細書で開示される実施形態のいずれかに係る送金を管理する方法を実施するための例示的環境１０のブロック図である。この送金を管理する方法は、第１のクライアントデバイス１２、第２のクライアントデバイス１４、及び処理ユニット１６を使用して実施することができる。第１と第２のクライアントデバイス１２と１４は、送金アプリケーションがインストールされる。処理ユニット１６は、送金アプリケーションのバックエンドサーバである。第１のクライアントデバイス１２は、販売時点管理（ＰＯＳ）マシン、モバイル端末又はディスク端末のような販売業者側の端末であってもよい。第２のクライアントデバイス１４は、スマートフォン、タブレット、ＰＣのようなユーザ（又はバイヤー）側のモバイルデバイスである。少なくともユーザは、アプリケーションアカウントを介しての送金を行うために、送金アプリケーションのアプリケーションアカウント（又はログインアカウント）を持つ必要がある。販売業者側の第１のクライアントデバイス１２のみが、アプリケーションアカウントを介してユーザが送金を行うことができるようにインターネットに接続されていることが必要である。

第２のクライアントデバイス１４のアプリケーションアカウントは、アプリケーションアカウントにある［資金］を使用してユーザが支払を行うことができるように、最初に、資金の限度内で所定の金額の［資金供給］をする。実際に、アプリケーションアカウントには現金は無い。しかしながら、アプリケーションアカウントは、一つ以上のユーザの銀行口座に繋がっている。ユーザが、送金アプリケーションでアプリケーションアカウントを開く場合、ユーザは、処理ユニット１６又はユーザの銀行が所定の額までユーザの銀行口座からお金を取り出すことを許可する。従って、ユーザが支払を行う場合に、支払金額は、アプリケーションアカウントにおける利用可能な資金（それは、所定の金額に最初は等しい）から差し引かれてもよい。処理ユニットは、ユーザの銀行口座から支払金額を引き出し、且つ販売業者の銀行口座にその支払金額を預けてもよい。アプリケーションアカウントにおける利用可能な資金は、ユーザがアプリケーションアカウントを介して支払いを行う毎に、減少する。アプリケーションアカウントにおける［資金］を保護するために、処理ユニット１６は、デフォルトによって又はユーザの命令に従って、アプリケーションアカウントの資金に対する資金の限度を設定することができる。アプリケーションアカウントにおける「利用可能な資金」を使用する送金は、検証又はパスワード無しに生じ得るので、資金の限度は、第２のクライアントデバイスが失われる又は盗まれた場合、その損失を制限できる。

第１の実施形態

図２を参照すると、本発明の第１の実施形態に係る送金を行う方法２０がここで記述される。ユーザが、商品やサービスに対して支払いを望む時に、販売業者側の第１のクライアントデバイス１２は、ステップ２２で、支払金額を得る。その支払金額は、製品上のバーコードを走査してその商品の価格を得るためにバーコードスキャナを使用することによって、又は第１のクライアントデバイス１２に支払い金額をマニュアルで入力することによってのように、様々な方法を介して第１のクライアントデバイス１２によって得られてもよい。第１のクライアントデバイス１２は、任意ではあるが、ユーザが支払金額を確認するために支払金額をデータ処理ページ上に表示してもよい。

次に、第１のクライアントデバイス１２は、ステップ２４で、ユーザのアプリケーションアカウント情報を得る。第１のクライアントデバイス１２は、第１のクライアントデバイス１２と第２のクライアントデバイス１４との間の短距離通信（ブルートゥース通信のような）によって、又は中にユーザのアプリケーションアカウント情報を含む画像コードを走査することによってのように様々な方法を介して第２のクライアントデバイス１４からユーザのアプリケーションアカウント情報を得てもよい。画像コードは、例えば、バーコード、又はユーザが支払い開始ページを開くために送金アプリケーションにログインすると、第２のクライアントデバイス１４に表示される二次元コードであってもよい。ユーザのアプリケーションアカウント情報は、ユーザのアプリケーションアカウントにおける利用可能な資金及びユーザの識別情報を含んでもよい。

画像コードは、アプリケーションアカウントにおける利用可能な資金の変化を反映するために、ユーザが送金アプリケーション上で支払い開始ページを開く毎に、変化され且つ更新されてもよい。或いは、画像コードは、利用可能な資金の変化を反映するために、ユーザが支払を行った後毎に、変化されてもよい。画像コードは、送金アプリケーション又は処理ユニット１６によって自動的に又はユーザによって手作業で更新されてもよい。

ステップ２２で支払金額を及びステップ２４でユーザのアプリケーションアカウント情報を受け取ると、第１のクライアントデバイス１２は、支払処理のために処理ユニット１６に支払請求を送信し且つ処理ユニットは、ステップ２６で、ユーザアプリケーションアカウントに十分な資金があるか否かを決定する。ユーザのアプリケーションアカウントが十分な資金を有する場合、次に、処理ユニット１６は、ステップ２８で、第２のクライアントデバイスに対応するユーザの銀行口座から第１のクライアントデバイスに対応する販売業者の銀行口座に送金を行い、ユーザのアプリケーションアカウントにある利用可能な資金から支払金額を差し引く。

ユーザが送金アプリケーションのアプリケーションアカウントを開くと、アプリケーションアカウントは、一つ以上のユーザの銀行口座に繋げられてもよい。また、アプリケーションアカウントは、唯一つのクライアントデバイスに繋げられてもよい。従って、一つ以上のユーザの銀行口座は、ユーザのアプリケーションアカウントと第２のクライアントデバイスに繋げられてもよい。ユーザは、支払金額が引き出されるデフォルト銀行口座として一つの銀行口座を指定できる。

ユーザのアプリケーションアカウントは、「現金」を有さず、従って、アプリケーションアカウントにおける「利用可能な資金」は、ユーザがなんら検証やパスワード無しでオフラインで使用することができる金額を単に指している。アプリケーションアカウントの資金の限度は、ユーザがなんら検証やパスワード無しで使用できる最大の金額を指す。支払金額は、ユーザの銀行口座から販売業者の銀行口座に実際に送金される。従って、第２のデバイスがインターネットに接続されない時、ユーザのアプリケーションアカウントは、ユーザがパスワードを入力すること無しで支払できるように資金を有する仮想マネーカードと類似する。しかしながら、ストアドバリューカードとは異なり、ユーザのアプリケーションアカウントは、アプリケーションアカウントに価値を補充するために、事前決定されたアカウントに前払いすることをユーザに求めない。支払金額に等しいお金は、ユーザが特定の購入に対する支払を行う毎に、所定の金額までユーザの銀行口座から取り出されることができる。ユーザがアプリケーションアカウントを開き、資金の限度を指定すると、ユーザは、処理ユニット１６又はユーザの銀行がユーザの銀行口座から資金の限度に等しい所定の金額を取り出すことを許可した。従って、処理ユニット１６は、支払金額がユーザの銀行口座から実際に引き出される前に、ユーザが支払いを行うことを可能とする。

或いは、処理ユニット１６は、資金の限度に等しい所定の金額を取り出すことができ、且つユーザがアプリケーションアカウントを開き且つ資金の限度を設定すると、処理ユニット１６が制御する一つのアカウントにその所定の金額を貯金することができる。次に、処理ユニット１６は、ユーザがアプリケーションアカウントにおける利用可能な資金まで使用するまで、ユーザが支払いを行う毎に、処理ユニット１６に対応するアカウントから販売業者のアカウントに支払金額を送金することができる。

販売業者のアカウントは、アプリケーションアカウントまたは販売業者の銀行口座であってもよい。販売業者が、送金アプリケーションをインストールすると、販売業者は、ユーザからの支払いを受領するために銀行口座を指定することができ、それによって、処理ユニット１６は、支払金額を販売業者の銀行口座に送金することができる。

支払金額が、販売業者のアカウントに送金された後、処理ユニット１６は、ステップ３０で、その支払いが成功したことを示す通知を第１のクライアントデバイス１２に送信する。第２のクライアントデバイス１２は、第２のクライアントデバイス１４がインターネットに接続されているか否かに従って、そのような通知を受信してもよいし受信しなくてもよい。第２のクライアントデバイス１２がインターネットに接続されていると、処理ユニット１６は、また、支払いが成功したことを示す通知を第２のクライアントデバイス１２に送信し且つ取引の記載、取引の時間、差し引かれた金額、及び残りの利用可能な資金といったアプリケーションアカウント情報の更新を行う。ユーザが支払いを行う時に第２のデバイス１４がインターネットに接続されていない場合、処理ユニット１６は、処理ユニット１６が第２のユーザクライアント１４がインターネットに接続されたことを検出すると、直ちにアプリケーションアカウント情報のアップデートを第２のユーザクライアント１４に送信する。

ステップ２２からステップ３０は、第２のクライアントデバイス１４が完全にオフラインである場合に実行できる。第１のクライアントデバイス１２のみが、処理ユニット１６と通信するためにインターネットに接続されることが必要である。

一方で、処理ユニット１６が請求された支払いを行うためにユーザのアプリケーションアカウントにある利用可能な資金が十分でないことを決定すると、処理ユニット１６は、ステップ３２で資金が不十分であることの通知を第１のクライアントデバイス１２に送信する。次に、処理ユニット１６は、ステップ３４で第２のクライアントデバイス１４がインターネットに接続されているか否かを決定する。第２のクライアントデバイス１４がインターネットに接続していない場合、次に、処理ユニット１６は、ステップ３６で支払いが断られたことを示す通知を第１のクライアントデバイス１２に送信する。第２のクライアントデバイス１２がインターネットに接続されている場合、次に、処理ユニット１６は、資金が不十分であることの通知を第２のクライアントデバイス１４に送信し、且つステップ３８でユーザがアプリケーションアカウントをリチャージすることを望むか否かを尋ねる質問を送信する。ユーザがアプリケーションアカウントをリチャージすることを望まない場合、処理ユニット１６は、ステップ３６で支払が断られたことを示す通知を第１のクライアントデバイス１２と第２のクライアントデバイス１４の両方に送信する。

ユーザが、ステップ３８でアプリケーションアカウントをリチャージする自分の意図を確認すると、次に、処理ユニット１６は、リチャージページを第２のユーザクライアント１２に送信し、ユーザは、ステップ４０でそのリチャージ金額を選択できる。処理ユニット１６は、デフォルト資金の限度又は安全のためにユーザがアプリケーションアカウントを開く時にユーザによって設定される資金の限度を記憶することができる。選択されたリチャージ金額がデフォルト又は事前設定資金限度内である場合、次に、処理ユニット１６は、ステップ４２で銀行口座選択ページを第２のユーザクライアント１４に送信する。選択されたリチャージ金額がデフォルト又は事前設定資金限度を超えると、処理ユニット１６は、第２のクライアントデバイス１６に対して警告を送信し、ユーザにリチャージ金額を変更することを求める。

銀行口座選択ページは、ユーザが送金アプリケーションでアプリケーションアカウントを開く場合、アプリケーションアカウントに繋げられた一つ以上のユーザの銀行口座を含んでもよい。ユーザは、お金がデフォルト銀行口座から販売業者の口座に送金されることができるようにデフォルト銀行口座を指定してもよい。ユーザは、支払いを行うための銀行口座選択ページの銀行口座を変更又は追加する選択肢を有していてもよい。希望の銀行口座を選択すると、処理ユニット１６は、ステップ４６で検証のためにパスワード入力ページを第２のクライアントデバイスに送信する。パスワードは、ユーザの銀行口座に対するパスワードである必要はない。パスワードは、アプリケーションアカウントへのログインのためのパスワードであってもよい。

ユーザがパスワードを入力した後、次に、処理ユニット１６は、ステップ４８でユーザのＩＤを検証する。検証が失敗すると、処理ユニット１６は、再び、第２のクライアントデバイス１４にそのパスワードの入力ページを送信する。検証が成功すると、次に、処理ユニット１６は、ユーザのアプリケーションアカウントをリチャージし、また、ステップ５０でユーザの銀行口座から販売業者の口座へ支払金額を送金する。このステップでは、第２のクライアントデバイス１４におけるアプリケーションアカウントに対応するユーザの銀行口座から第１のクライアントデバイス１２に対応する販売業者の銀行口座への送金が発生する。

その後、処理ユニット１６は、ステップ５２で、その支払いが成功したことを示す通知を第１クライアントデバイス１２と第２のクライアントデバイス１４の両方に送信する。加えて、処理ユニット１６は、アプリケーションのアップデート済み利用可能な資金、支払履歴、購買の記載、購買の時間のようなユーザのアプリケーションアカウント情報を更新してもよく、更新レポートを第２のユーザクライアント１４に送信する。

アプリケーションアカウントをリチャージすることに関連するステップにおいて、リチャージ金額と銀行口座のユーザの選択及びパスワードの入力は、ユーザがアプリケーションアカウントを開いた場合に最初に同意された所定の金額に加えて、ユーザの銀行口座からリチャージ金額を越えるお金を引き出すことに対して処理ユニットとユーザの銀行に対するユーザの許可を構成することに留意されたい。従って、アプリケーションアカウントをリチャージした後、ユーザは、何らの検証やパスワード無しで、アプリケーションアカウントの資金を使用し続けることができる。最初に同意されたよりも多くのお金をユーザの銀行口座から引き出すことが必要な場合は、常に、パスワードを処理ユニットのログインアカウントに送信すること等によってユーザのＩＤを検証する必要がある。

第２の実施形態

図３を参照すると、送金する方法を実行するための送金アプリケーションのバックエンドサーバのような処理ユニット１６は：第１のクライアントデバイスによって送信される支払金額を受信し、且つ第２のクライアントデバイスからアプリケーションアカウント情報を得るように構成される受信モジュール４１０；ＩＤ情報に従って第２のクライアントデバイスのアプリケーションアカウントを決定するように構成される決定モジュール４２０；及びユーザの銀行口座から販売業者の銀行口座に送金し、アプリケーションアカウントの利用可能な資金から支払金額を差し引くように構成される管理モジュール４３０を含む。

第２のクライアントデバイスからアプリケーションアカウント情報を得るステップは、第２のクライアントデバイスに表示された画像コードを走査することによってアプリケーションアカウント情報を読み込むことを含んでもよい。アプリケーションアカウント情報は、アカウント識別情報及びユーザＩＤ情報を含む。

決定モジュール４２０は、アプリケーションアカウント情報に含まれるアカウント識別情報及びユーザＩＤ情報に基づいて、アプリケーションアカウント情報を検証し、且つＩＤ検証をパスすると、第２のクライアントデバイスのアプリケーションアカウントがアカウント識別に対応するアカウントであると決定するように構成される。

管理モジュール４３０は、更に、利用可能な資金が支払金額よりも少ない場合、パスワード確認通知を第２のクライアントデバイスに送信し、正常に検証された第２のクライアントデバイスによって送信された送金パスワードを受信した後、アプリケーションアカウントに対応する銀行口座から第１のクライアントデバイスに対応する銀行口座に送金するように構成される。

好ましくは、管理モジュール４３０は、更に、銀行口座の残りの資金が支払金額未満である場合、銀行口座を変更する要求を第２のクライアントデバイスに送信し；且つ第２のクライアントデバイスによって送信された銀行口座情報を受信した後、アプリケーションアカウントに対応する銀行口座から第１のクライアントデバイスに対応する銀行口座に送金し、アプリケーションアカウントの利用可能な資金から支払金額を差し引くように構成される。

好ましくは、管理モジュール４３０は、更に、資金限度リセット要求を満たすと、アプリケーションアカウントの利用可能な資金の限度を最初の資金の限度にセットするように構成されるリセットモジュールを含む。

好ましくは、リセットモジュールは、資金限度リセット期間が満了すると、アプリケーションアカウントの利用可能な資金の限度を最初の資金の限度に設定する、又は第２のクライアントデバイスによって送信された上限をリセットするための要求を受信し送金パスワードの確認に成功した後、アプリケーションアカウントの利用可能な資金の限度を最初の資金の限度にセットするように構成されている。

好ましくは、リセットモジュールは、更に、アプリケーションアカウントの利用可能な資金の限度を最初の上限に設定した後、アプリケーションアカウントの現在の利用可能な資金の限度を第２のクライアントデバイスに送信するように構成される送信モジュールを含む。

好ましくは、リセットモジュールは、更に、アプリケーションアカウントに対応する銀行口座から第１のクライアントデバイスに対応する銀行口座に送金して、アプリケーションアカウントの利用可能な資金の限度から支払金額を差し引いた後に、支払金額と支払金額が差し引かれた現在利用可能な資金の限度を送信するように構成される送信モジュールを含む。

図４を参照すると、第１のクライアントデバイス１２は、第２のクライアントデバイスから支払金額とアプリケーションアカウント情報を得るように構成される取得モジュール５１０；支払金額とアプリケーションアカウント情報を処理ユニット１６に送信するように構成される送信モジュール５２０を含んでもよく、それによって、処理ユニット１６がアプリケーションアカウント情報に従って第２のクライアントデバイスのアプリケーションアカウントを決定し、アプリケーションアカウントに対応する銀行口座から第１のクライアントデバイスに対応する銀行口座に送金し、次に、支払金額に従って、アプリケーションアカウントの利用可能な資金の限度から支払金額を差し引く。好ましくは、取得モジュール５１０は、第２のクライアントデバイス上に表示された画像コードを走査することによって、アプリケーションアカウント情報を得て、且つ読み込むように構成される。

第３の実施形態

図５を参照すると、本実施形態に係る送金を管理するためのシステムは、第１のクライアントデバイス１２、第２のクライアントデバイス１４、及び送金アプリケーションのバックエンドサーバのような処理ユニット１６を含む。第１のクライアントデバイス１２は、支払金額を得て、第２のクライアントデバイスからアプリケーションアカウント情報を得て、且つ支払金額とアプリケーションアカウント情報を処理ユニットに送信するように構成される。処理ユニット１６は、支払金額とアプリケーションアカウント情報を受信し；アプリケーションアカウント情報に従って第２のクライアントデバイスのアプリケーションアカウントを決定し、且つアプリケーションアカウントに対応する銀行口座から第１のクライアントデバイスに対応する銀行口座に送金し、次に、アプリケーションアカウント情報に従って、アプリケーションアカウントの利用可能な資金の限度から支払金額を差し引くように構成される。

処理ユニット１９００は、一つ以上のＣＰＵ１９２２（又は一つ以上のプロセッサ）と記憶ユニット１９３２、アプリケーション１９４２又はデータ１９４４を記憶するための一つ以上の記憶媒体１９３０（一つ以上の大容量記憶デバイスのような）を含んでもよい。より具体的には、記憶ユニット１９３２と記憶媒体１９３０は、一時記憶装置又は固定記憶装置であってもよい。記憶媒体１９３０に記憶されたアプリケーションは、一つ以上のモジュール（図示せず）を含んでもよく、これらのモジュールの各々は、連続する命令を含んでもよい。更に、ＣＰＵ１９２２は、記憶媒体１９３０に記憶された命令を実行するために記憶媒体１９３０と通信してもよい。

処理ユニット１９００は、一つ以上の電源１９２６、一つ以上の有線又は無線ネットワークインターフェース１９５０、一つ以上の入力／出力インターフェース１９５８、一つ以上のキーボード１９５６、Ｗｉｎｄｏｗｓ Ｓｅｒｖｅｒ（商標登録）、Ｍａｃ ＯＳ Ｘ（商標登録）、Ｕｎｉｘ（商標登録）、Ｌｉｎｕｘ（商標登録）、ＦｒｅｅＢＳＤ（商標登録）のような一つ以上のオペレーティングシステム１９４１を含んでもよい。

処理ユニット１９００は、記憶ユニット、記憶装置に格納され、且つ第１のクライアントデバイスによって送信される支払金額を受信し、且つ第２のクライアントデバイスからアプリケーションアカウント情報を取得すること；アプリケーションアカウント情報に従って、第２のクライアントデバイスのアプリケーションアカウントを決定すること；アプリケーションアカウントに対応する銀行口座から第１のクライアントデバイスに対応する銀行口座に送金し、且つ支払金額に従って、アプリケーションアカウントの利用可能な資金の限度から支払金額を差し引くことの命令を実行するための一つ以上の処理が割り当てられた一つ以上のプログラムを含んでもよい。

本実施形態において設けられる第１のサーバは、一つ以上のＣＰＵ（又は一つ以上のプロセッサ）と記憶装置、アプリケーション又はデータを記憶するための一つ以上の記憶媒体（一つ以上の大容量記憶デバイスのような）を含んでもよい。より具体的には、記憶装置及び記憶媒体１９３０は、一時記憶装置又は固定記憶装置であってもよい。記憶媒体に記憶されたアプリケーションは、一つ以上のモジュール（図示せず）を含んでいてもよく、それらのモジュールの各々は、連続する命令を含んでもよい。更に、ＣＰＵは、記憶媒体に記憶された命令を実行するために記憶媒体１９３０と通信してもよい。

第１のクライアントデバイスは、記憶装置に記憶され且つ以下の命令、即ち、支払金額を取得すること、第２のクライアントデバイスからアプリケーションアカウント情報を取得すること、及び支払金額とアプリケーションアカウント情報を処理ユニットに送信することを実行する一つ以上の処理が割り当てられた一つ以上のプログラムを含んでもよい。そのように、処理ユニットは、アプリケーションアカウント情報に従って、第２のクライアントデバイスのアプリケーションアカウントを決定し、アプリケーションアカウントに対応する銀行口座から第１のクライアントデバイスに対応する銀行口座に送金し、次に、アプリケーションアカウント情報に従って、アプリケーションアカウントの利用可能な資金の限度から支払金額を差し引く。

上述の実施形態における送金を管理するためのデバイスは、例として説明されるように、実施中に幾つかの機能モジュールに分割されることに留意するべきである。しかしながら、実務において、デバイスは、異なる機能に従って異なる機能モジュールに分割されてもよい。別言すれば、そのデバイスの内部構造は、機能の一部又は全体を実行するために異なる機能モジュールに分割されてもよい。加えて、送金を管理するためのデバイスは、先に記述された方法を実施するために使用される。従って、その方法に関する詳細な記載は、明瞭にするためにここでは省略される。

本明細書で記述される実施形態のいずれにおいても、送金を行うための方法は、（バイヤーの）第２のクライアントデバイスがオフラインである時実行することができる。支払金額がアプリケーションアカウントの利用可能な資金未満である場合、検証やパスワードは必要とされない。資金の限度は、ユーザのデバイスが紛失された又は盗まれた場合に損失を制限するために、ユーザによって又はデフォルトによって事前設定されてもよい。アプリケーションアカウントの資金が不十分である場合、第２のクライアントデバイスは、ユーザの銀行口座を使用してアプリケーションアカウントをリチャージし、且つ支払を行うためにインターネットに接続されてもよい。ユーザのＩＤは、アプリケーションアカウントがリチャージされる前に検証される必要がある。従って、送金アプリケーションのアプリケーションアカウントによって、ユーザは、パスワード無しで且つアプリケーションアカウントの利用可能な残資金が減っていることについて心配すること無く容易に支払を行うことができる。支払金額が利用可能な資金よりも多い場合、ユーザの銀行口座のお金は、アプリケーションアカウントに対するバックアップを提供する。この状況で、ユーザのＩＤは安全性を向上するために検証する必要がある。

ハードウェアによって又は関連するハードウェアをプログラムで命令することによって、上述の実施形態におけるステップの一部又は全部を達成することが当業者には理解される。そのようなプログラムは、読み込み専用メモリ、磁気ディスクや光ディスク等のようなコンピュータ可読記憶媒体に記憶されてもよい。

本発明は、現在最も実務的且つ好適な実施形態であると考えられているものに関連して記述されたが、本発明は、開示の実施形態に制限されるものではなく、反対に、本発明の精神と範囲内に含まれる様々な変形例と等価な配置をカバーすることを意図していることが理解されるべきである。

Claims (20)

1. 送金するための方法であって、
   第１のクライアントデバイスによって支払金額を取得すること；
   前記第１のクライアントデバイスによってオフラインである第２のクライアントデバイスからアプリケーションアカウント情報を取得すること、ここで、前記アプリケーションアカウントとは、前記第２のクライアントデバイスにインストールされた送金アプリケーションのログインアカウントであり、且つ前記アプリケーションアカウントは利用可能な資金を有し；及び
   前記第１のクライアントデバイスによって前記支払金額と前記アプリケーションアカウント情報を処理ユニットに送信すること；を備え、
   前記利用可能な資金が前記支払金額よりも大きい場合、前記処理ユニットは、ユーザの銀行口座から販売業者の口座に前記支払金額を送金し、利用可能な資金が支払金額未満である場合、前記第２のクライアントデバイスがインターネットに接続したとき、前記処理ユニットは、前記第２のクライアントデバイスのユーザが前記アプリケーションアカウントの前記利用可能な資金を増加するためのウエブページを前記第２のクライアントデバイスに送信する方法。
2. 前記利用可能な資金が前記支払金額よりも大きい場合、前記処理ユニットは、前記ユーザの銀行口座から前記販売業者の口座にユーザのＩＤを検証することなく前記支払金額を送金する請求項１に記載の方法。
3. 更に、前記処理ユニットが前記ユーザのＩＤを検証した後に、前記処理ユニットによって、前記アプリケーションアカウントの前記利用可能な資金を増加することを備える請求項１に記載の方法。
4. 更に、前記第２のクライアントデバイスに対応する前記アプリケーションアカウントの前記利用可能な資金から前記支払金額を差し引くことを備える請求項１に記載の方法。
5. 更に、前記処理ユニットによって前記アプリケーションアカウントに対する資金の限度を事前設定することを備える請求項１に記載の方法。
6. 前記資金の限度は、前記ユーザのＩＤの検証無しに、前記ユーザが使用できる金額である請求項５に記載の方法。
7. 前記アプリケーションアカウントは、一つ以上の銀行口座に繋げられる請求項１に記載の方法。
8. 更に、前記第２のクライアントデバイスに対応する前記銀行口座を使用することによって、前記処理ユニットによって前記アプリケーションアカウントをリチャージすることを備える請求項１に記載の方法。
9. 更に、前記アプリケーションアカウントをリチャージする前記ステップの前に、前記処理ユニットによって検証のために前記第２のクライアントデバイスからパスワードを取得することを備える請求項８に記載の方法。
10. 前記第２のクライアントデバイスからアプリケーションアカウント情報を取得することの前記ステップは、前記第２のクライアントデバイス上に表示された画像コードを走査することを備える請求項１に記載の方法。
11. 更に、前記処理ユニットによって前記第２のクライアントデバイスから銀行口座情報を取得することを備える請求項１０に記載の方法。
12. 更に、前記処理ユニットによって、前記アプリケーションアカウントの前記利用可能な資金の更新を前記第２のクライアントデバイスへ送信することを備える請求項１に記載の方法。
13. 処理ユニットであって、
    第１のクライアントデバイスによって送信される支払金額を受信し且つ第２のクライアントデバイスからＩＤ情報を取得するように構成される受信モジュール；
    前記ＩＤ情報に従って前記第２のクライアントデバイスのアプリケーションアカウントを決定するように構成される決定モジュール；及び
    前記アプリケーションアカウントに対応する銀行口座から前記第１のクライアントデバイスに対応する銀行口座に送金し、且つ前記支払金額に従って、前記アプリケーションアカウントの利用可能な資金の限度から前記支払金額を差し引くように構成される管理モジュールを備える処理ユニット。
14. 前記アプリケーションアカウント情報は、アカウント識別情報及びユーザＩＤ情報を備え、前記決定モジュールは、前記アプリケーションアカウント情報に含まれる前記アカウント識別情報と前記ユーザＩＤ情報に従って前記アプリケーションアカウント情報を検証し、且つ前記ユーザＩＤが検証されると、前記第２のクライアントデバイスの前記アプリケーションアカウントを前記アカウント識別情報に対応するアカウントであると決定するように構成される請求項１３に記載の処理ユニット。
15. 前記管理モジュールは、更に：
    前記利用可能な資金の限度が前記支払金額より小さい場合、パスワード確認通知を前記第２のクライアントデバイスに送信し；及び
    正常に検証された前記第２のクライアントデバイスによって送信された送金パスワードを受信した後、前記アプリケーションアカウントに対応する前記銀行口座から前記第１のクライアントデバイスに対応する前記銀行口座に送金するように構成される請求項１３に記載の処理ユニット。
16. 前記管理モジュールは、更に：
    前記アプリケーションアカウントに対応する前記銀行口座の残りの金額が前記支払金額よりも小さい場合、銀行口座を変更するための要求を前記第２のクライアントデバイスに送信し；及び
    前記第２のクライアントデバイスによって送信された銀行口座情報を受信した後、前記銀行口座情報に対応する前記銀行口座から前記第１のクライアントデバイスに対応する前記銀行口座に送金し、前記アプリケーションアカウントの前記利用可能な資金の限度から前記支払金額を差し引くように構成される請求項１３に記載の処理ユニット。
17. 更に、事前設定された上限リセット必要条件を満たすと、前記アプリケーションアカウントの前記利用可能な資金の限度を事前設定された最初の上限に設定するように構成されるリセットモジュールを備える請求項１３に記載の処理ユニット。
18. 前記リセットモジュールは：
    事前設定された上限リセット期間を満了すると、前記アプリケーションアカウントの前記利用可能な資金の限度を前記最初の上限に設定する；又は
    前記第２のクライアントデバイスによって送信された上限をリセットするための要求を受信し前記送金パスワードの確認が成功した後、前記アプリケーションアカウントの前記利用可能な資金の限度を前記最初の上限に設定するように構成される請求項１３に記載の処理ユニット。
19. 更に、前記アプリケーションアカウントの前記利用可能な資金の限度を前記最初の上限に設定した後、前記アプリケーションアカウントの現在の利用可能な資金の限度を前記第２のクライアントデバイスに送信するように構成される送信モジュールを備える請求項１３に記載の処理ユニット。
20. 送金を管理するためのシステムであって、
    第１のクライアントデバイス；
    第２のクライアントデバイス；及び
    処理ユニットを備え、
    前記第１のクライアントデバイスは、現在の支払金額を取得して、前記第２のクライアントデバイスからＩＤ情報を取得して、且つ前記支払金額と前記ＩＤ情報を前記処理ユニットに送信するように構成され；及び
    前記処理ユニットは、前記支払金額と前記ＩＤ情報を受信し、前記ＩＤ情報に従って前記第２のクライアントデバイスのアプリケーションアカウントを決定し、且つ前記アプリケーションアカウントに対応する銀行口座から前記第１のクライアントデバイスに対応する銀行口座に送金し、次に、前記支払金額に従って、前記アプリケーションアカウントの利用可能な資金の限度から前記支払金額を差し引くように構成されるシステム。

Images