(58)【調査した分野】(Int.Cl.,DB名)
送信側クライアントによって、サーバに、オブジェクトセット及び前記オブジェクトセットに関連付けられる取り出しパスワードを生成させるように、前記サーバに対してインタラクション要求を開始することであって、前記オブジェクトセットは、前記送信側クライアントが所定の口座に移動する資金の金額に対応する、ことと、
前記サーバから返される要求応答を受信することであって、前記要求応答は、前記取り出しパスワードを含む、ことと、
それぞれの受信側ユーザが、受信側クライアントを介して、前記サーバに対し同じ前記取り出しパスワードを含む取り出し要求を開始し、前記オブジェクトセットに対応する前記資金の金額を取得できるようにするために、提示用の前記取り出しパスワードを複数の受信側ユーザに提供することであって、前記取り出しパスワードを入力する受信側ユーザの前記受信側クライアントは、前記取り出し要求に対する応答メッセージによって示される範囲内の資金の金額を受け取る、ことと
を含む、方法。
前記オブジェクトセットを生成することは、前記オブジェクトセットを作成することと、前記送信側クライアントの前記資金の金額を、前記オブジェクトセットに追加することと、を含み、前記資金の金額を配信することは、前記オブジェクトセット内の前記資金の金額を、前記複数の受信側クライアントに配信することを含む、請求項5に記載の1つまたは複数のコンピュータ可読媒体。
前記オブジェクトセットを生成することは、前記オブジェクトセットを作成することと、前記オブジェクトセットを前記送信側クライアントの前記資金の金額に関連付けることと、を含み、前記資金の金額を配信することは、前記送信側クライアントの前記オブジェクトセットに関連付けられた前記資金の金額を取得することと、取得した前記資金の金額を、前記複数の受信側クライアントに配信することと、を含む、請求項5に記載の1つまたは複数のコンピュータ可読媒体。
前記送信ユニットは、さらに、前記取り出しパスワードを含む表示画像を生成し、前記表示画像を前記要求応答に追加し、前記表示画像を含む前記要求応答を、前記送信側クライアントに送信する、請求項14に記載の装置。
前記配信ユニットは、さらに、オブジェクト配信比率を決定し、前記資金の金額、及び前記オブジェクト配信比率に少なくとも一部基づいて、実際の配信量を取得し、前記実際の配信量に対応する前記資金の金額を、前記受信側クライアントに配信する、請求項14に記載の装置。
前記配信ユニットは、さらに、前記受信側ユーザによって入力された数を前記取り出し要求から取得し、前記受信側ユーザによって入力された前記数が、前記資金の金額と等しいことに応じて、前記資金の金額を前記受信側クライアントに配信する、請求項19に記載の装置。
【発明を実施するための形態】
【0018】
図1は、サービス実施におけるシナリオ100を説明する概略図である。本開示の実施形態の技術的解決手段は、例えば、「赤い封筒」配信サービス、支払いサービスなどを実施する、異なるユーザ間に関連するサービスを実現することができる。赤い封筒配信サービスは、赤い封筒の形態でのユーザの資金または別の仮想アイテムの別のユーザへの配信と言ってもよい。関係するサービスが実施されるとき、既存の技術では、概して、サービスを開始するために、サービス開始ユーザが正確なサービス受信ユーザを知っている必要がある。さらに、URLアドレスまたはURLを含む2次元コードが、概して、サービス受信ユーザに通知するために生成される必要があり、非常に複雑な実施プロセスを有する。例えば、
図1は、「赤い封筒」配信サービスが実施例として用いられる、シナリオ100を示している。ユーザAが、ユーザB、ユーザCなどとデータのインタラクションを行うつもりである場合、ユーザAは、ユーザB、ユーザCなどの各々を、目的オブジェクトとして指定する必要があり、ユーザの数が多いときには、ユーザAは、大量の時間リソースを消費することになる。さらに、ユーザAが、ユーザB、ユーザCなどを指定するために、ユーザB、ユーザCなどが、ユーザAの関連ユーザである必要がある。例えば、ユーザB、ユーザCなどが、「友達」などとして、予めユーザAの連絡先に記録される必要がある。さらに、このプロセスでは、サービス受信ユーザ、例えば、ユーザB及びユーザCが、さらに、ユーザAによって開始されるサービスのサービスリンク、例えば、URLまたは2次元コードを介して、対応するサービスにアクセスし完了する必要があり、したがって、比較的複雑なサービス実施プロセスを有する。
【0019】
したがって、本開示は、赤い封筒サービス、支払いサービス、またはネットワークを介して実施され得る他のサービスなどの関連サービスを、比較的簡単なやり方で実施する、サービス実施方法、支払い方法、及び装置を提供する。
図2は、本開示の例示的な実施形態による、端末側に基づくサービス実施方法200のフローチャートを示す。
図2に示すように、方法200は、送信側クライアントに対応する端末において適用され、以下の方法ブロックを含んでもよい。
【0020】
S202において、送信側クライアントは、サーバに、オブジェクトセット及びオブジェクトセットに関連付けられる取り出しパスワードを生成させるように、サーバに対してインタラクション要求を送信し、オブジェクトセットは、送信側クライアントのプリセットオブジェクトに対応する。
【0021】
実施態様では、プリセットオブジェクトは、任意の形態のインタラクションデータを含んでもよい。実施例として、プリセットオブジェクトは、クーポン、電子グリーティングカード、現金ギフトなどの仮想アイテムであってもよい。これに対応して、オブジェクトセットは、仮想アイテムのセットであってもよい。仮想オブジェクトは、種々のサービス実施のための関連サービスに対応すると理解され得る。例えば、プリセットオブジェクトは、支払いサービスにおいては資金であってもよく、小売業者が商業活動サービスを開始するとき、プリセットオブジェクトはクーポンであってもよい、などである。
【0022】
実施態様では、送信側クライアントによって開始されるインタラクション要求に基づき、サーバは、1つまたは複数のオブジェクトセットを生成してもよく、各オブジェクトセットに対応するプリセットオブジェクトそれぞれの数は、1つまたは複数であってもよい。本開示は、オブジェクトセットの数、またはオブジェクトセットに対応するプリセットオブジェクトの数について、いかなる制限も有しない。実施態様では、インタラクション要求は、実施されるべきサービスに向けた要求であってもよい。例えば、支払いサービスが実施されるとき、要求は、支払い要求であってもよく、または、赤い封筒サービスが実施されるとき、要求は、赤い封筒サービス要求であってもよい。実施態様では、要求は、要求されるサービスを識別する識別情報などを伝達してもよい。さらに、要求は、サービス開始者、即ち、送信側クライアント上の送信側ユーザのユーザ識別子(ユーザのアカウント情報など)を含んでもよい。さらに、要求は、また、対応する受信側ユーザの情報などを伝達してもよい。種々の実際の適用シナリオに従って、要求は、関連するサービスの円滑な実施を容易にするための、対応する情報を含んでもよい。例えば、受信側ユーザについて全く制限が設定されない場合、受信側ユーザの情報は含まれないことがある、などである。
【0023】
実施態様では、取り出しパスワードは、文字列の形態であってもよい。文字列は、1つまたは複数の文字のビットを含んでもよく、各ビットの文字は、数字、英字、漢字、または記号などのうちの任意の形態であってもよい。取り出しパスワードに含まれる文字の数及び文字の組み合わせ方法は、実際の要件(複数可)または構成解決手段(複数可)に基づいて決定されてもよい。
【0024】
S204において、サーバによって返される要求応答が受信され、要求応答は、取り出しパスワードを含む。
【0025】
実施例として、要求応答は、取り出しパスワードを直接含んでもよく、送信側クライアントが、取り出しパスワードを構成する文字列を、要求応答から直接取得してもよい。
【0026】
別の実施例として、要求応答は、取り出しパスワードを取得するために使用されるリンクを含んでもよく、それは、取り出しパスワードを要求応答に間接的に含むことと等価である。送信側クライアントは、次いで、リンクにアクセスして、対応する取り出しパスワードを取得し、取り出しパスワードを形成する文字列を取得してもよい。
【0027】
別の実施例では、取り出しパスワードを含む表示画像が生成されてもよく、表示画像が、要求応答に含まれてもよい。
【0028】
S206において、受信側ユーザが、受信側クライアントを介して、サーバに対し取り出しパスワードを含む取り出し要求を送信し、オブジェクトセットに対応するプリセットオブジェクトを取得可能にするために、取り出しパスワードが、受信側ユーザに表示用に提供される。
【0029】
実施態様では、送信側クライアントが、取り出しパスワードを要求応答から直接取得することができる場合、または、要求応答内のリンクにアクセスすることによって、取り出しパスワードを直接取得することができる場合、送信側クライアントは、取り出しパスワードを受信側ユーザに直接表示してもよい。代替的には、送信側クライアントは、取り出しパスワードを含む表示画像を生成し、表示画像を提示用に受信側ユーザに提供してもよい。追加的には、または代替的には、実施態様では、要求応答は、表示画像を直接含んでもよく、送信側クライアントは、表示画像を直接使用してもよい。
【0030】
取り出しパスワードまたは表示画像が表示されるとき、取り出しパスワードまたは表示画像は、受信側ユーザの受信側クライアントに送信されてもよく、または受信側ユーザによって閲覧可能なソーシャルネットワーキングプラットフォームに共有されてもよく、または受信側ユーザに直接口述されるなどであってもよい。
【0031】
要求応答が、取り出しパスワードに関連付けられるアクセスリンクを含む場合、送信側クライアントが、また、受信側ユーザにリンクを表示用に直接提供してもよいことは明らかである。表示による手法は、取り出しパスワードまたは表示画像についての手法と同様であり、したがって、本明細書では繰り返して説明しない。
【0032】
実施態様では、「送信側クライアント」は、送信側ユーザの登録アカウントがログインするアプリケーションを指す。アプリケーションは、任意の端末デバイスに位置してもよい。同様に、「受信側クライアント」は、受信側ユーザの登録アカウントがログインするアプリケーションを指し、アプリケーションは、また、任意の端末デバイスに位置してもよい。
【0033】
図2の実施形態に対応して、
図3は、本開示の例示的な実施形態による、サーバ側に基づくサービス実施方法300のフローチャートを示す。
図3に示すように、方法300は、サーバに適用され、以下の方法ブロックを含んでもよい。
【0034】
S302において、送信側クライアントによって開始されるインタラクション要求に従って、オブジェクトセット、及びオブジェクトセットに関連付けられる取り出しパスワードが生成され、オブジェクトセットは、送信側クライアントのプリセットオブジェクトに対応する。
【0035】
実施態様では、「オブジェクトセットを生成すること」の実施例として、サーバが、オブジェクトセットを作成し、送信側クライアントのプリセットオブジェクトをオブジェクトセットに追加してもよい。これに対応して、サーバが、オブジェクトセットに対応するプリセットオブジェクトを、受信側クライアントに配信するとき、サーバは、実際には、オブジェクトセット内のプリセットオブジェクトを受信側クライアントに配信してもよい。
【0036】
実施態様では、「オブジェクトセットを生成すること」の別の実施例として、サーバが、オブジェクトセットを作成し、オブジェクトセットを送信側クライアントのプリセットオブジェクトに関連付けてもよい。これに対応して、サーバが、オブジェクトセットに対応するプリセットオブジェクトを、受信側クライアントに配信するとき、サーバは、実際には、送信側クライアントのオブジェクトセットに関連付けられたプリセットオブジェクトを取得し、プリセットオブジェクトを受信側クライアントに配信してもよい。
【0037】
送信側クライアントにおけるプリセットオブジェクトは、送信側クライアントのユーザに対応するプリセットオブジェクトを指してもよく、プリセットオブジェクトは、サーバまたは他のデバイスに記憶された、資金などのリソースであってもよい。
【0038】
S304において、送信側クライアントが、取り出しパスワードを受信側ユーザに提示用に提供可能にするために、取り出しパスワードを含む要求応答が、送信側クライアントに返される。
【0039】
S306において、取り出しパスワードを含み、受信側クライアントを介して受信側ユーザによって開始される取り出し要求に従って、オブジェクトセットに対応するプリセットオブジェクトが、受信側クライアントに配信される。
【0040】
実施態様では、サーバは、オブジェクト配信比率を決定し、プリセットオブジェクトの数、及びオブジェクト配信比率に従って、実際の配信量を取得するように計算してもよい。サーバは、次いで、実際の配信量に対応するプリセットオブジェクトを、受信側クライアントに配信してもよい。実施態様では、「オブジェクト配信比率」は、100%などの、任意の事前定義された比率であってもよい。代替的には、「オブジェクト配信比率」は、リアルタイムに生成されるランダムな比率、例えば、0〜100%のうちの任意の値であってもよい。
【0041】
実施態様では、受信側ユーザは、さらに、オブジェクトセット内のプリセットオブジェクトの数を予想し、入力してもよい。それに応じて、サーバは、ユーザによって入力された数を取り出しリクエストから取得してもよい。ユーザによって入力された数が、プリセットオブジェクトの数と等しいとき、サーバは、プリセットオブジェクトを受信側クライアントに配信する。この場合の配信のやり方は、上述したやり方、即ち、プリセットオブジェクトが、予め定義される、またはリアルタイムに生成されるオブジェクト配信比率に従って配信されるやり方と同様であることは明らかである。
【0042】
前述の実施態様から分かるように、開示された方法は、送信側クライアントのインタラクション要求を受信し、受信側ユーザが、受信側クライアントを介して、取り出しパスワードのみに基づき、対応するオブジェクトセットからプリセットオブジェクトを取り出すことを可能にするように、対応するオブジェクトセット及び取り出しパスワードを生成する。これにより、送信側クライアントと受信側クライアントとの間のインタラクションプロセスを簡略化し、送信側クライアントと受信側クライアントとの間で直接的なインタラクションを必要とすることなく、取り出しパスワードの通知及び使用を実現する。したがって、サービス実施のプロセスが簡略化され、サービス実施の効率が改善される。
【0043】
送信側クライアント、受信側クライアント、及びサーバ間のインタラクションのプロセスが関係するため、これら3者間のインタラクションのプロセスについて、
図4と併せた実施例として、ユーザA及びユーザB間のインタラクションプロセスを用いて、以下で詳細に説明する。
図4は、本開示の例示的な実施形態による、サービス実施方法400のフローチャートを示す。
図4に示すように、方法400は、以下の方法ブロックを含んでもよい。
【0044】
S402において、送信側ユーザの役割をするユーザAが、送信側クライアントを通じて、サーバに対しインタラクション要求を開始及び送信する。
【0045】
実施態様では、説明用の実施例として、「赤い封筒」配信サービスが用いられる。サービス実施のための本開示の技術的解決手段が、他のデータインタラクションプロセスにおけるサービス実施シナリオに明らかに適用可能であり、本開示において限定されないことを、当業者が理解すべきであることは明らかである。
【0046】
ユーザAによって赤い封筒配信を実施するための「Alipay(商標)」アプリケーションが、実施例として用いられる。ユーザAは、
図5に示す「Alipay(商標)」アプリケーションインタフェース500の「新年の赤い封筒」テキスト、または対応する「赤い封筒」パターンをトリガとして、赤い封筒生成インタフェースに入ってもよい。例えば、
図6は、赤い封筒生成インタフェース600の一形態、即ち「赤い封筒ソリティア」を示している。ユーザが、「赤い封筒の金額」を入力し、「赤い封筒に入れる」をクリックすると、「赤い封筒ソリティア」の生成が完了する。さらに、「Alipay(商標)」アプリケーションは、ユーザAのログインアカウント、「赤い封筒の金額」に対する入力、及び「赤い封筒ソリティア」の赤い封筒の種類などの情報に基づいて、サーバに対し、対応するインタラクション要求を開始してもよい。
【0047】
S404において、サーバは、ユーザAによって開始されるインタラクション要求に従って、オブジェクトセット及びオブジェクトセットに関連付けられる取り出しパスワードを生成する。
【0048】
実施態様では、「赤い封筒」配信の適用シナリオにおいて、オブジェクトセットは、サーバによって生成される仮想口座を含み、「赤い封筒」に対応してもよい。仮想口座は、ユーザAの口座a内の資金に対応してもよく、資金の額は、ユーザによって入力される「赤い封筒の金額」である。
【0049】
実施態様では、取り出しパスワードは、例えば、5分などの、あるライフサイクルを有してもよい。ライフサイクル満了後、サーバは、取り出しパスワードとオブジェクトセットとの対応関係を削除し、取り出しパスワードを再利用してもよい。実施態様では、サーバは、再利用される取り出しパスワードを再利用データベースに記憶してもよく、次回インタラクション要求が受信されるときに、再利用データベースから取り出しパスワードを直接選択して使用してもよい。それによって、取り出しパスワードを生成するプロセスをスキップする。
【0050】
実施態様では、
図7は、本開示の例示的な実施形態による、パスワード生成のフローチャートを示す。
図7に示すように、それらのプロセス700は、以下を含んでもよい。
【0051】
S702は、インタラクション要求に対応するパスワード生成シリアル番号を生成する。
【0052】
実施態様では、パスワード生成シリアル番号は、各インタラクション要求に対して取り出しパスワードが生成されるときに配信される、ID情報(即ち、識別情報)であってもよい。例えば、インクリメンタルIDは、インクリメンタルシーケンスを用いて、パスワード生成シリアル番号として機能するように生成されてもよい。
【0053】
S704は、パスワード生成シリアル番号を疑似乱数に変換する。
【0054】
実施態様では、パスワード生成シリアル番号を疑似乱数に変換することは、対応して生成される取り出しパスワードのランダム性の向上を容易にし、ひいては、取り出しパスワードの生成ルール(複数可)の検出を回避し、取り出しパスワードの高いセキュリティを保証する。
【0055】
既存の技術において疑似乱数を生成するために使用される処理関数(複数可)が、パスワード生成シリアル番号を疑似乱数に変換するための本開示の技術的解決手段に適用されてもよく、それは、本開示において限定されないことに留意すべきである。例えば、処理関数は、任意のインクリメンタルIDを100ずつ増加させてもよい。インクリメンタルID=1の実施例では、対応する疑似乱数101が得られてもよい。
【0056】
S706は、取り出しパスワードについて事前設定されたパスワードの種類に従って、対応するコードブックを選択する。
【0057】
実施態様では、パスワードの種類は、文字の数及び文字の組み合わせ方法などの情報を含んでもよい。取り出しパスワードは、文字列の形態であってもよく、文字の数は、文字列を構成する文字の数である。例えば、「0000」の文字の数は4であり、「adf94d」の文字の数は6である。文字の組み合わせ方法は、「全ての文字が数字」及び「最後の文字が数字で、他の文字が英字」などの、文字列の各ビットの文字それぞれの種類である。各文字は、数字、英字、漢字、または特殊記号などの任意の種類のものであってもよく、本開示では限定されない。
【0058】
実施態様では、各コードブックは、疑似乱数内の対応する平文文字と、文字の組み合わせ方法における対応する暗号文文字との間のマッピング関係を含んでもよい。例えば、疑似乱数が101で、文字の組み合わせ方法が「最後の文字が数字で、他の文字が英字」であるとき、疑似乱数101は、少なくとも2つのコードブックに対応する。第1のコードブックは、「数字(平文)→数字(暗号文)」のマッピング関係を含み、第2のコードブックは、「数字(平文)→英字(暗号文)」のマッピング関係を含む。
【0059】
S708は、コードブックに従って疑似乱数を変換し、取り出しパスワードを取得する。
【0060】
実施態様では、第1のコードブックにおいて、平文「1」に対応する暗号文が、「8」であり、第2のコードブックにおいて、平文「0」に対応する暗号文が、「z」である場合、疑似乱数101に対応する取り出しパスワードは、8z8である。
【0061】
S406は、取り出しパスワードを含む要求応答を、サーバからユーザAに返す。
【0062】
実施態様では、取り出しパスワードは、文字列であってもよい。文字列は、1つまたは複数のビットの文字を含んでもよく、各ビットの文字は、数字、英字、漢字、または記号などの任意の形態であってもよい。サーバは、次いで、取り出しパスワードの文字列を要求応答に直接含め、要求応答をユーザAに送信してもよい。代替的には、サーバは、取り出しパスワードを含む表示画像を生成し、表示画像をユーザAに送信してもよい。
【0063】
表示画像が生成されるとき、サーバは、事前定義された固定テンプレートに静的に基づいて、表示画像を生成してもよい。代替的には、複数のテンプレートが事前定義されてもよく、サーバは、現在の取り出しパスワードに対応するテンプレートIDを生成し、テンプレートIDに対応する画像属性テンプレートを取得して、画像属性テンプレートに従って表示画像を動的に生成してもよい。実施態様では、表示画像のスタイルの多様性を確保するため、及び対応するルールが容易に検出されることを防止するために、画像属性テンプレートは、背景画像、背景色、テキスト色、テキストサイズ、及びスタイルの種類などの、複数の異なる属性の任意の組み合わせを含んでもよい。
【0064】
ユーザAの送信側クライアントが、サーバによって返された取り出しパスワードを受信するとき、表示画像もまた、ローカルに生成されてもよいことは、明らかである。そのような生成の方法は、サーバでの生成方法と類似であり(必要な画像属性テンプレートがローカルに存在しない場合、サーバからダウンロードされてもよい)、本明細書では重複して説明しない。
【0065】
S408において、ユーザAは、受信側ユーザの役割をするユーザBに表示用の取り出しパスワードを、提示用に提供する。
【0066】
実施態様では、「表示画像」が、実施例として用いられる。送信側クライアントは、
図8に示すように、インタフェース800を介して表示画像をユーザAに表示してもよく、ユーザAは、表示画像をユーザBに表示する。例えば、
図8に示すインタフェースを用いて、ユーザAは、表示画像をローカルに記憶し、ソーシャルアプリケーションを介してソーシャルネットワーキングプラットフォームに表示画像を共有してもよい。それによって、ユーザBは、ユーザAによってソーシャルネットワーキングプラットフォームで共有されている、表示画像内の取り出しパスワードを見ることができる。
【0067】
ユーザAが、さらに、他のやり方で取り出しパスワードの表示を実現してもよいことは明らかである。例えば、ユーザAは、例えばインスタントメッセージを用いて、表示画像をユーザBに直接送信してもよい。代替的には、ユーザAは、さらに、言語コミュニケーション及び放送などの何らかのやり方で、取り出しパスワードをユーザBに通知してもよい。
【0068】
S410において、ユーザBは、受信側クライアントを通じて、サーバに対し取り出し要求を開始及び送信する。取り出し要求は、ユーザAが提示用に提供した取り出しパスワードを含む。
【0069】
実施態様では、ユーザBの受信側クライアントは、アカウントログインを完了した「Alipay(商標)」アプリケーションであってもよい。ユーザは、
図5に示すアプリケーションインタフェース内の「赤い封筒パスワード」をクリックすることによって、
図9に示すパスワード入力インタフェース900に入ってもよく、ユーザAが提示用に提供したような、取り出しパスワードを入力してもよい。例えば、パスワードは「0521」である。
【0070】
S412において、サーバは、取り出しパスワードに対応するオブジェクトセットを決定し、オブジェクトセット内のプリセットオブジェクトをユーザBに配信する。
【0071】
実施態様では、プリセットオブジェクトを配信するルール(複数可)について、複数の異なる方法が存在してもよい。例示的な実施形態として、ユーザBが正しい取り出しパスワードを入力した後、サーバは、プリセット比率に従って、対応するオブジェクトセットに対応するプリセットオブジェクトを、ユーザBに配信してもよい。プリセット比率は、例えば、100%など、予め定義される配信比率であってもよい。代替的には、プリセット比率は、リアルタイムに生成されるランダムな比率であってもよく、ランダムな比率は、0%〜100%の間の任意の値であってもよい。
【0072】
図6に示す「赤い封筒ソリティア」に対応し、
図9に示すパスワード入力インタフェースに基づく、例としての実施形態では、ユーザBが、正しい取り出しパスワードを入力した後、サーバは、ユーザBに対応する受信側クライアントに応答メッセージを返してもよい。受信側クライアントは、さらに、
図10に示す金額入力インタフェース1000を提示してもよい。ユーザBは、赤い封筒に対応する現金ギフトの金額(即ち、オブジェクトセットに対応するプリセットオブジェクトの数)を予想し、予想した数字を入力してもよい。予想した数字は、次いで、サーバに送信されてもよく、サーバは、この数字が、取り出しパスワードに対応する、オブジェクトセットに対応するプリセットオブジェクトの数と同一であるかどうかを判断する。同一である場合、プリセット比率(即ち、予め定義される配信比率、またはリアルタイムに生成されるランダムな比率)に従って、配信が行われる。同一でない場合、配信が行われないか、または配信比率が(例えば、それらが同一であるイベントでのプリセット比率よりも低く)低下される。
【0073】
実施態様では、ユーザBが正しい取り出しパスワードを入力した後、サーバは、赤い封筒に対応する現金ギフトの金額(即ち、対応するオブジェクトセットに対応するプリセットオブジェクトの数)に基づいて、現金ギフトの金額(即ち、プリセットオブジェクトの数)が属する数値範囲を、ユーザBに対応する受信側クライアントに返される応答メッセージに追加してもよい。例えば、現金ギフトの金額が1〜9元であるというメッセージが、
図10に示す金額入力インタフェースにおいて提供される。
【0074】
赤い封筒に対応する資金(または、オブジェクトセットに対応する他の形態のプリセットオブジェクト)を移転する複数の異なる方法が、データインタラクションのプロセスに存在してもよいことに留意すべきである。2つの考えられるそれらの形態について、以下の実施例を用いて説明する。
【0075】
1.前払い
図11は、本開示の例示的な実施形態による、資金移転1100の概略図を示す。
図11に示すように、ユーザAが、送信側クライアントを通じてサーバに対しインタラクション要求を開始した後、サーバは、ユーザAによって入力された赤い封筒の金額に基づいて、対応する金額の資金をユーザAに対応する口座aから直接引き出し、引き出した資金を、赤い封筒に対応する赤い封筒口座に移転してもよい。ユーザBは、次いで、正しい取り出しパスワードをサーバに提供してもよい。ある金額の資金が、ユーザBに配信される必要があるという判断に応じて、その金額の資金が、赤い封筒口座から引き出され、ユーザBに対応する口座bに移転されてもよい。
【0076】
2.リアルタイムの支払い
図12は、本開示の例示的な実施形態による、別の資金移転1200の概略図を示す。
図12に示すように、ユーザAが、送信側クライアントを通じてサーバに対しインタラクション要求を開始した後、ユーザAによって入力された赤い封筒の金額に基づいて、サーバは、赤い封筒口座に資金を移転することなく(任意で、口座のこの部分の資金が凍結されてもよい)、ユーザAに対応する口座a内の対応する金額の資金と、赤い封筒に対応する赤い封筒口座との関連付けを確立してもよい。代替的には、赤い封筒口座は、口座aとして考えられてもよく、赤い封筒識別情報を用いて識別されてもよい。ユーザBが、正しい取り出しパスワードをサーバに提供し、ある金額の資金がユーザBに配信される必要があることを確認した後、取り出しパスワードと赤い封筒との対応関係、及び赤い封筒口座と口座aとの対応関係に基づいて、口座bによって必要とされる資金が、口座aから取得されるべきという判断が行われる。次いで、必要な金額の資金が、口座aから口座bへ直接移転される。
【0077】
開始側クライアントによって開始されるインタラクション要求は、本開示の実施形態における、サービス受信者のユーザ情報を含んでもよいことに留意する。例えば、ユーザAが、赤い封筒サービスを開始する場合、ユーザB、ユーザC、及びユーザDなどの仲間が、インタラクション要求におけるパスワードに従って、赤い封筒を取り出すように指定されてもよく、インタラクション要求において指定されるユーザ(複数可)によって入力される取り出しパスワードのみが、有効である。代替的には、インタラクション要求は、また、取り出しパスワードに従って対応するサービスを完結することができるユーザの種類(例えば、ユーザAと友達関係を有するユーザ)などを指定してもよい。
【0078】
本開示の実施形態では、パスワードは、サービスを実施するためのインタフェースとして使用されてもよい。リンクアドレス、または2次元コードを介してサービスインタフェースを実装する既存の技術と比較して、本開示は、簡単かつ高速であり、より高いサービス実施効率を有する。
【0079】
図13は、本開示の例示的な実施形態による、端末側に基づく電子デバイス1300の概略構造図である。
図13に示すように、電子デバイス1300は、プロセッサ(複数可)1302、内部バス(複数可)1304、ネットワークインタフェース(複数可)1306、キャッシュ(複数可)1308、及び不揮発性記憶デバイス(複数可)1310を、ハードウェアレベルで含んでもよい。電子デバイス1300が、他のサービスによって必要とされるハードウェアをさらに含んでもよいことは、明らかである。プロセッサ(複数可)1302は、対応するコンピュータプログラムを不揮発性記憶デバイス(複数可)1310からキャッシュ(複数可)1308に読み出し、コンピュータプログラムを走らせてもよく、それにより、サービス実施装置1312を論理レベルで形成する。ソフトウェア実施態様以外にも、本開示が、論理デバイス、またはソフトウェア及びハードウェアの組み合わせなどの、他の方法の実施態様を含んでもよいことは明らかである。言い換えると、以下のような処理手続き(複数可)を実行するエンティティは、様々な論理ユニットに限定されず、ハードウェアまたは論理デバイスも含んでもよい。
【0080】
図14を参照すると、実施態様では、サービス実施装置1400は、送信側クライアントの端末において適用されてもよく、1つまたは複数のプロセッサ1402、入力/出力(I/O)インタフェース1404、ネットワークインタフェース1406、及びメモリ1408を含んでもよい。
【0081】
メモリ1408は、例えば、非永続記憶デバイス、ランダムアクセスメモリ(RAM)、及び/または、読み取り専用メモリ(ROM)もしくはフラッシュRAMなどの不揮発性内部記憶などの、コンピュータ可読媒体の形態を含んでもよい。メモリ1408は、コンピュータ可読媒体の実施例である。
【0082】
コンピュータ可読媒体は、永続型または非永続型、リムーバブルまたは非リムーバブルな媒体を含んでもよく、それは、任意の方法または技術を用いて、情報の記憶を実現してもよい。情報は、コンピュータ可読命令、データ構造、プログラムモジュール、またはその他のデータを含んでもよい。コンピュータ記憶媒体の実施例は、相変化メモリ(PRAM)、スタティックランダムアクセスメモリ(SRAM)、ダイナミックランダムアクセスメモリ(DRAM)、その他の種類のランダムアクセスメモリ(RAM)、読み取り専用メモリ(ROM)、電気的消去可能なプログラマブル読み取り専用メモリ(EEPROM)、高速フラッシュメモリ、もしくはその他の内部記憶技術、コンパクトディスク読み取り専用メモリ(CD−ROM)、デジタル多用途ディスク(DVD)、もしくはその他の光記憶、磁気カセットテープ、磁気ディスク記憶、もしくはその他の磁気記憶デバイス、または任意のその他の非伝送媒体を含むが、これらに限定されない。コンピュータ記憶媒体は、コンピューティングデバイスによってアクセスされ得る情報を記憶するために使用されてもよい。本明細書で定義するように、コンピュータ可読媒体は、変調データ信号及び搬送波などの、一時的媒体を含まない。
【0083】
実施態様では、メモリ1408は、プログラムユニット1410、及びプログラムデータ1412を含んでもよい。実施態様では、プログラムユニット1410は、要求開始ユニット1414、応答受信ユニット1416、及びパスワード表示ユニット1418を含んでもよい。
【0084】
要求開始ユニット1414は、送信側クライアントが、サーバに、オブジェクトセット及びオブジェクトセットに関連付けられる取り出しパスワードを生成させるように、サーバに対してインタラクション要求を開始できるようにしてもよく、オブジェクトセットは、送信側クライアントのプリセットオブジェクトに対応する。応答受信ユニット1416は、サーバから返される要求応答を受信してもよく、要求応答は、取り出しパスワードを含む。パスワード表示ユニット1418は、受信側ユーザが、受信側クライアントを通じて、サーバに対し取り出しパスワードを含む取り出し要求を開始し、オブジェクトセットに対応するプリセットオブジェクトを取得可能にするために、取り出しパスワードを表示用に受信側ユーザに提供してもよい。
【0085】
実施態様では、パスワード表示ユニット1418は、さらに、取り出しパスワードを含む表示画像を生成してもよく、または、要求応答に含まれる表示画像を取得してもよく、及び、表示画像を表示用に受信側ユーザに提供してもよい。
【0086】
実施態様では、パスワード表示ユニット1418は、表示画像を受信側クライアントに送信すること、または表示画像をソーシャルネットワーキングプラットフォームで共有することによって、表示画像を表示用に受信側ユーザに提供してもよい。
【0087】
実施態様では、パスワード表示ユニット1418は、以下のような手法、
取り出しパスワードに対応するテンプレートIDを生成すること、または要求応答に含まれるテンプレートIDを取得することと、
テンプレートIDに対応する画像属性テンプレートを、ローカルデータまたはサーバから取得することと、
画像属性テンプレートに従って、表示画像を動的に生成することと、を用いて、取り出しパスワードを含む表示画像を生成してもよい。
【0088】
図15は、本開示の例示的な実施形態による、サーバに基づく電子デバイス1500の構造図である。
図15を参照すると、ハードウェアレベルにおいて、電子デバイス1500は、プロセッサ(複数可)1502、内部バス(複数可)1504、ネットワークインタフェース(複数可)1506、キャッシュ(複数可)1508、及び不揮発性記憶デバイス(複数可)1510を、ハードウェアレベルで含んでもよい。電子デバイス1500が、他のサービスによって必要とされるハードウェアをさらに含んでもよいことは、明らかである。プロセッサ(複数可)1502は、対応するコンピュータプログラムを不揮発性記憶デバイス(複数可)1510からキャッシュ(複数可)1508に読み出し、コンピュータプログラムを走らせてもよく、それにより、サービス実施装置1512を論理レベルで形成する。ソフトウェア実施態様以外にも、本開示は、論理デバイス、またはソフトウェア及びハードウェアの組み合わせなどの、他の方法の実施態様を含んでもよいことは明らかである。言い換えると、以下のような処理手続き(複数可)を実行するエンティティは、様々な論理ユニットに限定されず、ハードウェアまたは論理デバイスも含んでもよい。
【0089】
図16を参照すると、実施態様では、サービス実施装置1600は、サーバに適用されてもよく、1つまたは複数のプロセッサ1602、入力/出力(I/O)インタフェース1604、ネットワークインタフェース1606、及びメモリ1608を含んでもよい。
【0090】
メモリ1608は、例えば、非永続記憶デバイス、ランダムアクセスメモリ(RAM)、及び/または、読み取り専用メモリ(ROM)もしくはフラッシュRAMなどの不揮発性内部記憶などの、コンピュータ可読媒体の形態を含んでもよい。メモリ1608は、前述の説明において説明したコンピュータ可読媒体の実施例である。
【0091】
実施態様では、メモリ1608は、プログラムユニット1610、及びプログラムデータ1612を含んでもよい。実施態様では、プログラムユニット1610は、生成ユニット1614、送信ユニット1616、及び配信ユニット1618を含んでもよい。
【0092】
生成ユニット1614は、送信側クライアントによって開始されるインタラクション要求に従って、オブジェクトセット、及びオブジェクトセットに関連付けられる取り出しパスワードを生成してもよく、その場合に、オブジェクトセットは、送信側クライアントのプリセットオブジェクトに対応する。送信ユニット1616は、送信側クライアントが、取り出しパスワードを表示用に受信側ユーザに提供可能にするために、取り出しパスワードを含む要求応答を、送信側クライアントに返してもよい。配信ユニット1618は、取り出しパスワードを含み、受信側クライアントを通じて受信側ユーザによって開始される取り出し要求に従って、オブジェクトセットに対応するプリセットオブジェクトを、受信側クライアントに配信してもよい。
【0093】
実施態様では、生成ユニット1614は、
インクリメンタルシーケンスを用いて、インタラクション要求に対応するパスワード生成シリアル番号を生成することと、
パスワード生成シリアル番号を処理するように構成される分散型ノードデバイスを決定すること、及び分散型ノードデバイスについて事前設定された上昇値を取得することと、
疑似乱数を取得するために、上昇値に従ってパスワード生成シリアル番号を増加させることと、
取り出しパスワードについて事前設定されたパスワードの種類に従って、対応するコードブックを選択すること、及び、取り出しパスワードを取得するために、コードブックに従って疑似乱数を変換することと、を含む手法を用いて、取り出しパスワードを生成してもよい。
【0094】
実施態様では、パスワードの種類は、ビット数、及び各ビットの文字の種類を含んでもよい。
【0095】
実施態様では、送信ユニット1616は、さらに、取り出しパスワードを含む表示画像を生成し、送信側クライアントに送信される要求応答に表示画像を追加してもよい。
【0096】
実施態様では、送信ユニット1616は、
取り出しパスワードに対応するテンプレートIDを生成すること、または要求応答に含まれるテンプレートIDを取得することと、
テンプレートIDに対応する画像属性テンプレートを、ローカルデータまたはサーバから取得することと、
画像属性テンプレートに従って、表示画像を動的に生成することと、を含む手法を用いて、取り出しパスワードを含む表示画像を生成してもよい。
【0097】
実施態様では、生成ユニット1614は、オブジェクトセットを作成すること、及び送信側クライアントのプリセットオブジェクトをオブジェクトセットに追加することによって、オブジェクトセットを生成してもよい。配信ユニット1618は、オブジェクトセット内のプリセットオブジェクトを受信側クライアントに配信することによって、オブジェクトセットに対応するプリセットオブジェクトを、受信側クライアントに配信してもよい。
【0098】
実施態様では、生成ユニット1614は、オブジェクトセットを作成すること、及びオブジェクトセットを送信側クライアントのプリセットオブジェクトに関連付けることによって、オブジェクトセットを生成してもよい。配信ユニット1618は、送信側クライアントのオブジェクトセットに関連付けられるプリセットオブジェクトを取得すること、及びプリセットオブジェクトを受信側クライアントに配信することによって、オブジェクトセットに対応するプリセットオブジェクトを受信側クライアントに配信してもよい。
【0099】
実施態様では、配信ユニット1618は、さらに、オブジェクト配信比率を決定し、プリセットオブジェクトの数及びオブジェクト配信比率に従って、実際の配信量を取得するように計算し、実際の配信量に対応するプリセットオブジェクト(複数可)を、受信側クライアントに配信してもよい。
【0100】
実施態様では、配信ユニット1618は、さらに、ユーザによって入力された数を、取り出し要求から取得し、ユーザによって入力された数が、プリセットオブジェクトの数と等しいときに、プリセットオブジェクト(複数可)を受信側クライアントに配信してもよい。
【0101】
より具体的には、本開示の技術的解決手段は、「支払い」シナリオに適用可能である。例えば、
図4に示す実施形態に含まれる「赤い封筒」配信は、実際には、ユーザAがユーザBに「支払い」を行うプロセスに属している。したがって、「支払い」シナリオに基づいて、本開示は、
図17及び
図18に示す、例としての支払い方法を提供する。
【0102】
図17は、本開示の例示的な実施形態による、端末側に基づく支払い方法1700のフローチャートを示す。方法1700は、送信側クライアントに対応する端末において適用され、以下の方法ブロックを含んでもよい。
【0103】
S1702において、支払人クライアントは、サーバにトランザクションイベントを作成させ、トランザクションイベントに対応するトランザクションパスワードを生成させるために、サーバに対し支払い要求を開始する。トランザクションイベントは、支払人クライアントに関連付けられたプリセット値のトランザクション金額に対応する。
【0104】
S1704において、サーバによって返される要求応答が受信され、要求応答は、トランザクションパスワードを含む。
【0105】
S1706において、トランザクションパスワードは、受取人が、受取人クライアントを通じて、サーバに対しトランザクションパスワードを含む支払い要求を開始し、トランザクションイベントに対応するトランザクション金額を請求することができるようにするために、受取人に表示用に提供される。
【0106】
これに対応して、
図18は、本開示の例示的な実施形態による、サーバ側に基づく支払い方法1800のフローチャートを示す。方法1800は、サーバにおいて適用され、以下の方法ブロックを含んでもよい。
【0107】
S1802において、支払人クラインアントによって開始される支払い要求に基づいて、トランザクションイベントが作成され、トランザクションイベントに対応するトランザクションパスワードが生成される。トランザクションイベントは、支払人クライアントに関連付けられるプリセット値のトランザクション金額に対応する。
【0108】
S1804において、支払人クライアントが、トランザクションパスワードを表示用に受取人に提供することができるようにするために、トランザクションパスワードを含む要求応答が、支払人クライアントに返される。
【0109】
S1806において、トランザクションパスワードを含み、受取人クライアントを通じて受取人によって開始される支払い要求に従って、トランザクションイベントに対応するトランザクション金額が、受取人クライアントに配信される。
【0110】
図19は、前述の実施形態に基づいて、本開示の例示的な実施形態による、支払いシナリオ1900の概略図を示す。
図19に示すように、ユーザAがスーパマーケットに買い物に行き、チェックアウトカウンタで支払い動作を行う必要がある時に続いて、そのプロセスの詳細が、下記に含まれてもよい。
1)チェックアウトカウンタが、ユーザAが購入した品目をスキャンすると、支払いが必要な金額が、xとして決定される。
【0111】
2)ユーザAは、支払人クライアント上で金額xを入力し、金額xに対応する支払い要求をサーバに対して開始する。サーバは、対応するトランザクションイベント、及びトランザクションイベントに関連付けられる支払いパスワードを生成し、支払いパスワードをユーザAに返す。
【0112】
実施態様では、サーバは、ユーザAによって入力された金額xに基づいて、ユーザAに対応する口座aから金額xのトランザクション資金を引き出し、資金をトランザクションイベントに対応するトランザクション口座に移転する。これが、単に実施例として用いられ、
図12に対応する処理方法もまた、使用されてもよいことは明らかである。
【0113】
3)ユーザAは、例えば、チェックアウトカウンタの従業員に、支払いパスワードを含む画像を見せることによって、または支払いパスワードの内容を従業員に口頭で伝えることによって、チェックアウトカウンタに支払いパスワードを表示する。
【0114】
4)チェックアウトカウンタは、サーバに対して清算要求を開始し、清算は、支払いパスワードを含む。サーバは、次いで、支払いパスワードに対応するトランザクション口座から、チェックアウトカウンタに対応する会計口座に金額xを移転してもよい。
【0115】
実施態様では、チェックアウトカウンタは、ユーザAによって入力された金額xとの検証を行うために、トランザクション金額の値を清算要求に追加してもよい。それらが等しい場合、支払いが完了する。等しくない場合、支払いは却下される。
【0116】
5)支払いが完了した後、サーバは、ユーザA及びチェックアウトカウンタ個々に通知してもよい。
【0117】
図20は、本開示の例示的な実施形態による、端末側に基づく電子デバイス2000の構造図である。典型的な構成では、電子デバイス2000は、1つまたは複数のプロセッサ(CPU)、入力/出力インタフェース、ネットワークインタフェース、及びメモリを含んでもよい。例えば、電子デバイス2000は、
図20に示すように、プロセッサ(複数可)2002、内部バス(複数可)2004、ネットワークインタフェース(複数可)2006、キャッシュ(複数可)2008、及び不揮発性記憶デバイス(複数可)2010を、ハードウェアレベルで含んでもよい。電子デバイス2000が、他のサービスによって必要とされるハードウェアをさらに含んでもよいことは、明らかである。プロセッサ(複数可)2002は、対応するコンピュータプログラムを不揮発性記憶デバイス(複数可)2010からキャッシュ(複数可)2008に読み出し、コンピュータプログラムを走らせてもよく、それにより、支払い装置2012を論理レベルで形成する。ソフトウェア実施態様以外にも、本開示は、論理デバイス、またはソフトウェア及びハードウェアの組み合わせなどの、他の方法の実施態様を含んでもよいことは明らかである。言い換えると、以下のような処理手続き(複数可)を実行するエンティティは、様々な論理ユニットに限定されず、ハードウェアまたは論理デバイスも含んでもよい。
【0118】
図21を参照すると、実施態様では、支払い装置2100は、支払人クライアントの端末において適用されてもよい。実施態様では、支払い装置2100は、1つまたは複数のプロセッサ2102、入力/出力(I/O)インタフェース2104、ネットワークインタフェース2106、及びメモリ2108を含んでもよい。
【0119】
メモリ2108は、例えば、非永続記憶デバイス、ランダムアクセスメモリ(RAM)、及び/または、読み取り専用メモリ(ROM)もしくはフラッシュRAMなどの不揮発性内部記憶などの、コンピュータ可読媒体の形態を含んでもよい。メモリ2108は、前述の説明において説明したコンピュータ可読媒体の実施例である。
【0120】
実施態様では、メモリ2108は、プログラムユニット2110、及びプログラムデータ2112を含んでもよい。実施態様では、プログラムユニット2110は、要求開始ユニット2114、応答受信ユニット2116、及びパスワード表示ユニット2118を含んでもよい。
【0121】
要求開始ユニット2114は、支払人クライアントが、サーバにトランザクションイベントを作成させ、トランザクションイベントに対応するトランザクションパスワードを生成させるために、サーバに対し支払い要求を開始できるようにしてもよい。その場合に、トランザクションイベントは、支払人クライアントに関連付けられたプリセット値のトランザクション金額に対応する。応答受信ユニット2116は、サーバによって返される要求応答を受信してもよく、要求応答は、トランザクションパスワードを含む。パスワード表示ユニット2116は、受取人が、受取人クライアントを通じて、サーバに対しトランザクションパスワードを含む支払い要求を送信し、トランザクションイベントに対応するトランザクション金額を請求することができるようにするために、トランザクションパスワードを受取人に対して表示してもよい。
【0122】
図22は、本開示の例示的な実施形態による、サーバに基づく電子デバイス2200の構造図である。典型的な構成では、電子デバイス2200は、1つまたは複数のプロセッサ(CPU)、入力/出力インタフェース、ネットワークインタフェース、及びメモリを含んでもよい。例えば、電子デバイス2200は、
図22に示すように、プロセッサ(複数可)2202、内部バス(複数可)2204、ネットワークインタフェース(複数可)2206、キャッシュ(複数可)2208、及び不揮発性記憶デバイス(複数可)2210を、ハードウェアレベルで含んでもよい。電子デバイス2200が、他のサービスによって必要とされるハードウェアをさらに含んでもよいことは、明らかである。プロセッサ(複数可)2202は、対応するコンピュータプログラムを不揮発性記憶デバイス(複数可)2210からキャッシュ(複数可)2208に読み出し、コンピュータプログラムを走らせてもよく、それにより、支払い装置2212を論理レベルで形成する。ソフトウェア実施態様以外にも、本開示は、論理デバイス、またはソフトウェア及びハードウェアの組み合わせなどの、他の方法の実施態様を含んでもよいことは明らかである。言い換えると、以下のような処理手続き(複数可)を実行するエンティティは、様々な論理ユニットに限定されず、ハードウェアまたは論理デバイスも含んでもよい。
【0123】
図23を参照すると、実施態様では、支払い装置2300は、サーバにおいて適用されてもよい。実施態様では、支払い装置2300は、1つまたは複数のプロセッサ2302、入力/出力(I/O)インタフェース2304、ネットワークインタフェース2306、及びメモリ2308を含んでもよい。
【0124】
メモリ2308は、例えば、非永続記憶デバイス、ランダムアクセスメモリ(RAM)、及び/または、読み取り専用メモリ(ROM)もしくはフラッシュRAMなどの不揮発性内部記憶などの、コンピュータ可読媒体の形態を含んでもよい。メモリ2308は、前述の説明において説明したコンピュータ可読媒体の実施例である。
【0125】
実施態様では、メモリ2308は、プログラムユニット2310、及びプログラムデータ2312を含んでもよい。実施態様では、プログラムユニット2310は、要求処理ユニット2314、要求応答ユニット2316、及びトランザクション支払いユニット2318を含んでもよい。
【0126】
要求処理ユニット2314は、支払人クラインアントによって開始される支払い要求に基づいて、トランザクションイベントを作成し、トランザクションイベントに対応するトランザクションパスワードを生成してもよい。その場合に、トランザクションイベントは、支払人クライアントに関連付けられたプリセット値のトランザクション金額に対応する。要求応答ユニット2316は、支払人クライアントが、トランザクションパスワードを受取人に対して表示することができるようにするために、トランザクションパスワードを含む要求応答を、支払人クライアントに返してもよい。トランザクション支払いユニット2318は、トランザクションパスワードを含み、受取人クライアントを通じて受取人によって開始される支払い要求に従って、トランザクションイベントに対応するトランザクション金額を、受取人クライアントに配信してもよい。
【0127】
「comprise(備える)」、「include(含む)」などの用語、及びそれらの任意の他の変形は、非排他的な包含を含むように意図されることに、さらに留意すべきである。一連の要素を含むプロセス、方法、製品、もしくはデバイスは、それらの要素だけでなく明示的に列挙されていない他の要素も含み、またはそのようなプロセス、方法、製品、もしくはデバイス内に既に存在する要素をさらに含む。さらなる制限がない状態では、「include a/an ...(1つの...を含む)」という句によって定義される要素は、プロセス、方法、製品、またはデバイス内に存在するものからいかなる他の類似の要素も除外しない。
【0128】
上述の説明は、単なる本開示の例示的な実施形態であり、本開示を限定することを意図するものではない。本開示の思想及び原理から逸脱することなく行われる、いかなる修正、等価な置換、及び改良も、本開示の保護範囲内に入るものとする。