(57)【特許請求の範囲】
【請求項１】
第1のユーザのリソース送信要求を受信するステップであり、前記リソース送信要求が、送信されるべきリソース、前記リソースに一致するユーザ質問、または前記リソースに対応する位置情報のうちの少なくとも1つを含む、ステップと、
第2のユーザが、前記位置情報に基づく検索によって前記リソースを取得するとき、前記ユーザ質問に基づいて前記第2のユーザを検証するために、前記位置情報をリリースするステップと、
前記第2のユーザが前記リソースの質問検証条件をトリガしたかどうかを検出するステップと、
前記第2のユーザが前記質問検証条件をトリガしたことを検出したことに応答して、前記送信されたリソースに対応する前記ユーザ質問を前記第2のユーザに送信するステップと、
前記ユーザ質問に対する回答を前記第2のユーザから受信するステップと、
ユーザ情報に基づいて、前記第2のユーザによって送信されたリソース取得要求の量、または検証時間の量をカウントすることによって、前記回答の検証を実行するステップと、
前記検証が成功したと判断したことに応答して、前記リソースを前記第2のユーザに送信するステップと
を含むリソース送信のための方法。
【請求項２】
前記第1のユーザの前記リソース送信要求を受信するステップの前に、前記方法が、
前記第1のユーザによって送信された償還情報取得要求を受信するステップと、
前記償還情報取得要求に基づいて、リソース償還情報を生成するステップと、
前記リソース償還情報を前記第1のユーザにフィードバックするステップとをさらに含む
請求項1に記載の方法。
【請求項３】
第1のユーザのリソース送信要求を受信する前記ステップが、
前記第1のユーザによって送信され、前記リソース償還情報をリソースとして使用する前記リソース送信要求を受信するステップであり、前記リソース償還情報が、少なくとも商品償還コードを含む、ステップを含む
請求項2に記載の方法。
【請求項４】
前記第1のユーザによって送信された前記償還情報取得要求を受信するステップの前に、前記方法が、
前記第1のユーザとリソース償還サービスを提供するオフラインマーチャントとの間の取引に関する取引情報を受信するステップと、
前記第1のユーザに対するリソース送信クエリを開始するステップとをさらに含む
請求項2に記載の方法。
【請求項５】
前記第1のユーザによって送信された前記償還情報取得要求を受信するステップが、
前記リソース送信クエリに基づいて、前記第1のユーザによって送信された商品償還コード要求を受信するステップを含む
請求項4に記載の方法。
【請求項６】
前記リソース償還情報を生成し、前記第1のユーザに前記リソース償還情報をフィードバックするステップが、
前記取引情報に基づいて、前記第1のユーザのユーザ情報および前記オフラインマーチャントのユーザ情報を決定するステップと、
前記第1のユーザの前記ユーザ情報および前記オフラインマーチャントの前記ユーザ情報に対応するリソース償還コードを生成するステップと、
前記リソース償還コードを前記第1のユーザおよび前記オフラインマーチャントにフィードバックするステップとを含む
請求項5に記載の方法。
【請求項７】
前記第1のユーザによって送信された前記償還情報取得要求を受信するステップが、
前記第1のユーザによって送信され、前記第1のユーザのユーザ情報、およびリソース償還サービスを提供するオフラインマーチャントのユーザ情報を含む商品償還コード要求を受信するステップ
を含む、請求項2に記載の方法。
【請求項８】
前記リソース送信要求が、仮想レッドエンベロープ送信要求を含む、請求項1から7のいずれか一項に記載の方法。
【請求項９】
前記第1のユーザの前記リソース送信要求を受信するステップが、
前記第1のユーザの前記仮想レッドエンベロープ送信要求を受信するステップであり、前記仮想レッドエンベロープ送信要求が、送信されるべき商品償還コード、前記商品償還コードに一致するユーザ質問、および仮想レッドエンベロープに対応する位置情報のうちの少なくとも1つを含む
請求項8に記載の方法。
【請求項１０】
前記位置情報をリリースするステップが、
前記第2のユーザが、前記位置情報に基づく検索によって前記仮想レッドエンベロープを取得するとき、前記ユーザ質問に基づいて前記第2のユーザを検証するために、前記位置情報をリリースするステップと、
前記検証が成功したと判断したことに応答して、前記仮想レッドエンベロープにおける前記商品償還コードを前記第2のユーザに送信するステップとを含む
請求項9に記載の方法。
【請求項１１】
リソース取得要求の前記量または検証回数の前記量が指定された量を超えていると判断したことに応答して、所定のオーバーランプロンプト情報を前記第2のユーザにフィードバックするステップ
をさらに含む、請求項1に記載の方法。
【請求項１２】
前記送信されたリソースの前記質問検証条件をトリガするステップが、
前記位置情報に基づいて識別された前記リソースを取得する要求をサーバに送信するステップ、または
第2のユーザの位置が前記リソースの前記位置の指定された範囲内にあることを検出するステップ
を含む、請求項1に記載の方法。
【請求項１３】
前記位置情報に基づいて識別された前記リソースを取得する前記要求を前記サーバに送信するステップが、
現在の位置に関する情報を決定するステップと、
前記位置の指定された範囲内で、前記位置情報を検索するステップと、
前記識別されたリソースを取得する指示を受信するステップと、
前記取得要求を生成するステップと、
前記取得要求を前記サーバに送信するステップと
を含む、請求項12に記載の方法。
【請求項１４】
前記方法が、
サーバによってフィードバックされたオーバーランプロンプト情報を受信し、表示するステップ
をさらに含む、請求項1に記載の方法。
【請求項１５】
請求項1から14のいずれか一項に記載の前記方法を実行するように構成された複数のモジュールを含むリソース送信のための装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、コンピュータ技術の分野に関し、特に、リソース送信方法および装置に関する。
【背景技術】
【０００２】
情報技術が発展するにつれて、エンドユーザデバイスまたはエンドユーザデバイス上で実行されているアプリケーションを使用することによって、リソース(ファイルまたはアカウントクォータなど)をユーザ間で送信することができる。
【０００３】
既存の技術には拡張現実(Augmented Reality, AR)とロケーションベースサービス(Location Based Service, LBS)とを組み合わせ、従来のインスタント送信モードを変更するリソース送信モードがある。本モードでは、リソース送信者(以下では第1のユーザと呼ぶ)は、エンドユーザデバイスを使用することによって、任意の位置において、あるターゲットオブジェクト(たとえばあるオブジェクト)の画像を収集し、収集された画像および位置に関する情報に基づいて、リソースが送信されるように設定することができる。対応して、リソース取得者(以下では第2のユーザと呼ぶ)は、第1のユーザによって送信されたリソースを取得するために、エンドユーザデバイスを使用することによって、同じ位置において、同じターゲットオブジェクトの画像を収集できる。
【０００４】
たとえば、ARレッドエンベロープ(AR Red Envelope, 紅包)のシナリオでは、第1のユーザは、携帯電話を使用することによって、ある位置において、特定のオブジェクトの写真を収集し、写真に基づいて、ARレッドエンベロープを送信することができる。第2のユーザは、位置特定サービスを使用することによって、第1のユーザがARレッドエンベロープを送信する位置を識別することができる。その位置に到着した後、第2のユーザは、携帯電話を使用することによって、同じオブジェクトの画像を収集することによって、ARレッドエンベロープを取得することができる。
【０００５】
しかしながら、記載したリソース送信モードでは、第2のユーザは、対応するターゲットオブジェクトを検索し、リソースの位置において画像を収集するのに比較的長い時間を費やす可能性がある。明らかに、第2のユーザは、この方法でリソースを取得するのにより多くの時間を費やす可能性がある。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
本出願の実装形態は、既存の技術での拡張現実と位置特定サービスとを組み合わせることによって、リソースを取得することが不便であるという問題を軽減するためのリソース送信方法および装置を提供する。
【課題を解決するための手段】
【０００７】
本出願の一実装形態は、第1のユーザのリソース送信要求を受信するステップであり、リソース送信要求が、少なくとも、送信されるべきリソース、リソースに一致するユーザ質問、およびリソースに対応する位置情報を含む、ステップと、第2のユーザがリリースされた位置情報に基づく検索によってリソースを取得するとき、ユーザ質問に基づいて第2のユーザを検証するために、位置情報をリリースするステップと、検証の成功後、リソースを第2のユーザに送信するステップとを含むリソース送信方法を提供する。
【０００８】
本出願の一実装形態は、リソース送信動作を受信するステップと、リソース送信動作に基づいて、リソース送信要求を生成するステップであり、リソース送信要求が、少なくとも、送信されるべきリソース、リソースに一致するユーザ質問、およびリソースに対応する位置情報を含む、ステップと、サーバが位置情報をリリースし、ユーザ質問に基づいて、位置情報に基づいてリソースを取得する第2のユーザを検証し、検証の成功後、リソースを第2のユーザに送信するように、リソース送信要求をサーバに送信するステップとを含むリソース送信方法をさらに提供する。
【０００９】
本出願の一実装形態は、第2のユーザが送信されたリソースの質問検証条件をトリガしたかどうかを検出するステップと、第2のユーザがユーザ質問に基づいて検証されるべき回答をフィードバックするように、第2のユーザが質問検証条件をトリガしたことを検出したことに応答して、送信されたリソースに対応するユーザ質問を第2のユーザに送信するステップと、第2のユーザによってフィードバックされた検証されるべき回答を受信し、検証するステップと、検証が成功すると、リソースを第2のユーザに送信するステップとを含むリソース送信方法をさらに提供する。
【００１０】
本出願の一実装形態は、リソースの質問検証条件がトリガされた後、サーバによって送信され、送信されたリソースに対応するユーザ質問を受信するステップであり、リソースが、第1のユーザによってサーバに送信され、サーバが、そのリソースの位置情報をリリースする、ステップと、サーバが、検証されるべき回答を検証し、検証の成功後、リソースをフィードバックするように、ユーザ質問に基づいて検証されるべき回答をサーバにフィードバックするステップと、サーバによってフィードバックされたリソースを取得するステップとを含むリソース送信方法をさらに提供する。
【００１１】
本出願の一実装形態は、第2のユーザによって送信された商品償還(Merchandise Redemption)コードを受信するステップと、記憶された商品償還コードに基づいて、第2のユーザによって送信された商品償還コードを検証するステップであり、第1のユーザとの取引に関する情報がサーバに送信された後、サーバによって、記憶された商品償還コードが生成され、送信される、ステップと、検証の成功後、第2のユーザのための商品償還コードに対応する商品を提供するステップとを含むリソース送信方法をさらに提供する。
【００１２】
本出願の一実装形態は、第1のユーザのリソース送信要求を受信するように構成された受信モジュールであり、リソース送信要求が、少なくとも、送信されるべきリソース、リソースに一致するユーザ質問、およびリソースに対応する位置情報を含む、受信モジュールと、第2のユーザがリリースされた位置情報に基づく検索によってリソースを取得するとき、ユーザ質問に基づいて第2のユーザを検証するために、位置情報をリリースし、検証の成功後、リソースを第2のユーザに送信するように構成されたリリースモジュールとを含むリソース送信装置をさらに提供する。
【００１３】
本出願の一実装形態は、リソース送信動作を受信するように構成された受信モジュールと、リソース送信動作に基づいて、リソース送信要求を生成するように構成された要求生成モジュールであり、リソース送信要求が、少なくとも、送信されるべきリソース、リソースに一致するユーザ質問、およびリソースに対応する位置情報を含む、要求生成モジュールと、サーバが位置情報をリリースし、ユーザ質問に基づいて、位置情報に基づいてリソースを取得する第2のユーザを検証し、検証の成功後、リソースを第2のユーザに送信するように、リソース送信要求をサーバに送信するように構成された送信モジュールとを含むリソース送信装置をさらに提供する。
【００１４】
本出願の一実装形態は、第2のユーザが送信されたリソースの質問検証条件をトリガしたかどうかを検出するように構成された検出モジュールと、第2のユーザがユーザ質問に基づいて検証されるべき回答をフィードバックするように、第2のユーザが質問検証条件をトリガしたことを検出したことに応答して、送信されたリソースに対応するユーザ質問を第2のユーザに送信するように構成された質問フィードバックモジュールと、第2のユーザによってフィードバックされた検証されるべき回答を受信し、検証するように構成された検証モジュールと、検証が成功すると、リソースを第2のユーザに送信するように構成されたリソース送信モジュールとを含むリソース送信装置をさらに提供する。
【００１５】
本出願の一実装形態は、リソースの質問検証条件がトリガされた後、サーバによって送信され、送信されたリソースに対応するユーザ質問を受信するように構成された受信モジュールであり、リソースが、第1のユーザによってサーバに送信され、サーバが、そのリソースの位置情報をリリースする、受信モジュールと、サーバが、検証されるべき回答を検証し、検証の成功後、リソースをフィードバックするように、ユーザ質問に基づいて検証されるべき回答をサーバにフィードバックするように構成された回答送信モジュールと、サーバによってフィードバックされたリソースを取得するように構成された取得モジュールとを含むリソース送信装置をさらに提供する。
【００１６】
本出願の一実装形態は、第2のユーザによって送信された商品償還コードを受信するように構成された受信モジュールと、記憶された商品償還コードに基づいて、第2のユーザによって送信された商品償還コードを検証するように構成された検証モジュールであり、第1のユーザとの取引に関する情報がサーバに送信された後、サーバによって、記憶された商品償還コードが生成され、送信される、検証モジュールと、検証の成功後、第2のユーザのための商品償還コードに対応する商品を提供するように構成されたリソース提供モジュールとを含むリソース送信装置をさらに提供する。
【００１７】
本出願の実装形態は、リソース送信方法および装置を提供する。この方法に基づいて、以下を実装できる。
【００１８】
リソースをサーバに送信するとき、リソース送信者(すなわち、第1のユーザ)は、リソースに一致するユーザ質問をサーバにさらに送信する。ユーザ質問は、リソース取得者(すなわち、第2のユーザ)を検証するために使用される。サーバはさらに、リソースの位置情報として第1のユーザの位置情報を取得する。次いで、別のユーザが、位置特定サービスに基づいて、位置情報に対応するリソースを識別できるように、サーバは位置情報をリリースする。もちろん、リソースを識別するユーザがリソースを取得する必要があると、サーバは、第1のユーザによって設定されたユーザ質問に基づいて、第2のユーザを検証することができる。第2のユーザの検証が成功したときにのみ、サーバは、リソースをユーザに送信し、したがって、ユーザは、リソースを取得する。
【００１９】
既存の技術と比較して、ユーザ質問は、リソース取得者が指定された位置において特定のターゲットオブジェクトを検索し、画像を収集するという面倒なプロセスを軽減するように設定される。したがって、リソースを便利に、簡単に取得することができ、リソース取得プロセスを単純化することができる。
【００２０】
本明細書に記載された添付の図面は、本出願のさらなる理解を提供するために使用され、本出願の一部を構成する。本出願の概略的な実装形態、および実装形態の説明は、本出願を説明するために使用されており、本出願に対する不適切な制限を構成するものではない。添付の図面において、以下の通りである。
【図面の簡単な説明】
【００２１】
【図１ａ】本出願の一実装形態による、リソース送信方法の基礎となるアーキテクチャを示す概略図である。
【図１ｂ】本出願の一実装形態による、リソース送信プロセスを示す概略図である。
【図１ｃ】本出願の一実装形態による、リソース送信プロセスを示す概略図である。
【図２ａ】本出願の一実装形態による、実際のアーキテクチャの一例を示す概略図である。
【図２ｂ】本出願の一実装形態による、実際のアーキテクチャの一例を示す概略図である。
【図３ａ】本出願の一実装形態による、リソース取得プロセスを示す概略図である。
【図３ｂ】本出願の一実装形態による、リソース取得プロセスを示す概略図である。
【図３ｃ】本出願の一実装形態による、リソース取得プロセスを示す概略図である。
【図４ａ】本出願の一実装形態による、仮想ギフトパケットの一例を示す概略図である。
【図４ｂ】本出願の一実装形態による、仮想ギフトパケットの一例を示す概略図である。
【図５】本出願の一実装形態による、リソース送信装置の一例を示す概略構造図である。
【図６】本出願の一実装形態による、リソース送信装置の一例を示す概略構造図である。
【図７】本出願の一実装形態による、リソース送信装置の一例を示す概略構造図である。
【図８】本出願の一実装形態による、リソース送信装置の一例を示す概略構造図である。
【図９】本出願の一実装形態による、リソース送信装置の一例を示す概略構造図である。
【発明を実施するための形態】
【００２２】
本出願の目的、技術的解決策、および利点をより明確にするために、以下は、本出願における特定の実装形態および対応する添付の図面を参照して、本出願の技術的解決策を明確かつ包括的に説明する。明らかに、記載された実装形態は、本出願の実装形態のすべてではなく、ほんの一部にすぎない。創造的な取り組みなしに本出願の実装形態に基づいて当業者によって取得されるすべての他の実装形態は、本出願の保護範囲内に入るものとする。
【００２３】
上記で説明したように、既存の技術でのARとLBSとを組み合わせるリソース送信モードでは、リソースを取得しようとしているユーザは、別のユーザによって送信されたリソースを取得するために、ある位置に到着し、その位置において特定のターゲットオブジェクトの画像を収集する必要がある(たとえば、カップ、机、椅子など、その位置における任意のオブジェクト、またはその位置における任意のスペースエリア)。しかしながら、ユーザは通常、その位置に到着した後、その位置において特定のターゲットオブジェクトを探すのに多くの時間を費やす必要がある。明らかに、この方法は、リソースを入手しようとしているユーザにとって非常に面倒で不便である。
【００２４】
上記に基づいて、本出願は、リソース送信方法を提供する。ユーザ質問方法を使用することによって、リソースを取得しようとしているユーザは、別のユーザによって送信されたリソースを取得するために、指定された位置において特定のターゲットオブジェクトを検索する代わりに、対応するエンドユーザデバイスにユーザ質問に対応する正しい回答を入力するだけでよく、それによって、リソース取得が容易になる。
【００２５】
本出願の実装形態に記載されているリソースは、限定はしないが、マルチメディアファイル(ビデオファイル、オーディオファイル、または動画など)、文字メッセージ、口座金額、合計、仮想商品(仮想レッドエンベロープなど)、およびリソース償還コード(Resource Redemption Code)を含むことに留意する価値がある。リソースは、エンドユーザデバイスにローカルに記録することができ、またはエンドユーザデバイスを使用するユーザのアカウントに記憶することができる。ここでは、本出願に制限は課されない。
【００２６】
図1aに示すアーキテクチャは、本出願の実装形態におけるリソース送信方法に使用することができ、第1のユーザ(すなわち、リソース送信者)、第2のユーザ(すなわち、リソース取得者)、およびサーバを含む。
【００２７】
サーバは、サービスプロバイダ(たとえば、ウェブサイト、銀行、または電気通信事業者)のバックエンドにあるサービスサーバとすることができる。第1のユーザまたは第2のユーザは、ユーザ、またはユーザによって使用されるエンドユーザデバイスと理解することができることが、図1aからわかる。第1のユーザまたは第2のユーザは、エンドユーザデバイスにおいて動作しているアプリケーション、またはエンドユーザデバイスのオペレーティングシステムのリソース送信機能を使用することによって、リソースの送信および取得を実施することができる。本出願の実装形態のいくつかの説明では、第1のユーザまたは第2のユーザは、エンドユーザデバイスを使用するユーザと理解することもできる。エンドユーザデバイスは、限定はしないが、スマートフォン、スマートウォッチ、タブレットコンピュータ、コンピュータ、およびキャッシュレジスタを含み得る。
【００２８】
もちろん、実際には、第1のユーザは、別のユーザによって送信されたリソースも取得できる。したがって、第1のユーザは、リソース取得者(すなわち、第2のユーザ)と見なすことができる。同様に、第2のユーザも別のユーザにリソースを送信できる。したがって、第2のユーザは、リソース送信者(すなわち、第1のユーザ)と見なすことができる。ここでは、本出願に制限は課されない。
【００２９】
以下は、本出願の実装形態において提供されるリソース送信方法を詳細に説明する。
【００３０】
リソース送信段階:
【００３１】
図1aに示されるアーキテクチャに基づいて、サーバ側で、本出願の本実装形態において提供されるリソース送信プロセスが図1bに示されており、以下のステップを含む。
【００３２】
S101。第1のユーザのリソース送信要求を受信する。
【００３３】
リソース送信要求は、少なくとも、送信されるべきリソース、リソースに一致するユーザ質問、およびリソースに対応する位置情報を含む。
【００３４】
本出願の本実装形態において、第1のユーザによって送信されるリソース送信要求は、第1のユーザによって設定されたリソースの量、リソース取得許可(たとえば、任意のユーザがリソースを取得できること、または第1のユーザの友人のみがリソースを取得できることを第1のユーザが設定することができる)、および第1のユーザのユーザ情報(たとえば、ユーザIDおよびアカウント名)などの情報をさらに含むことができる。ここでは、制限は課されない。
【００３５】
既存の技術でのターゲットオブジェクト画像を収集するための方法とは異なり、本出願の本実装形態では、第1のユーザは、対応するユーザ質問およびあらかじめ定義された回答を設定し、ユーザ質問は、リソース取得者を検証するために使用される。リソース取得者は、あらかじめ定義された回答と一致する回答情報を入力した後にのみ、リソースを取得することができることを理解することができる。
【００３６】
ユーザ質問およびあらかじめ定義された回答は、ユーザ定義方法で第1のユーザによって、または質問ライブラリ(具体的には、質問ライブラリから第1のユーザによって選択される)を使用することによって設定することができる。ここでは、制限は課されない。さらに、ユーザ質問のフォーマットは、単語、数字、および記号などの文字によって形成されたテキストフォーマットとすることができ、または音声または短いビデオなどのマルチメディアフォーマットとすることができる。対応して、あらかじめ定義された回答のフォーマットは、ユーザ質問のフォーマットに一致させることができる。同様に、本出願の本実装形態におけるユーザ質問およびあらかじめ定義された回答のフォーマットは、本出願に対する制限を構成しない。
【００３７】
位置情報は、位置特定サービス(たとえば、記載されたLBS)に基づいて第1のユーザによって決定された、現時点における第1のユーザの位置に関する情報とすることができ、または、もちろん、リソースプロバイダに対応する位置情報とすることができる。
【００３８】
S102。第2のユーザがリリースされた位置情報に基づく検索によってリソースを取得するとき、ユーザ質問に基づいて第2のユーザを検証するために、位置情報をリリースし、検証の成功後、リソースを第2のユーザに送信する。
【００３９】
サーバは、リソースの位置情報を決定した後、位置情報をリリースすることができる。リリースされた位置情報は、位置特定サービスを使用することによって、別のユーザによって識別することができることを理解できる。したがって、リソースを識別するユーザは、リソースを取得することができる。第1のユーザがリソースのためのユーザ質問およびあらかじめ定義された回答を設定するので、ユーザ質問およびあらかじめ定義された回答に基づいて、第2のユーザに対して検証が行われる。第2のユーザは、第2のユーザにおける検証の成功後にのみ、リソースを取得できる。言い換えれば、サーバは、検証の成功後、第1のユーザのリソースをリソース取得者(すなわち、第2のユーザ)に送信することができる。
【００４０】
記述されたステップを使用することによって、リソースをサーバに送信している間に、リソース送信者(すなわち、第1のユーザ)はさらに、リソースに一致するユーザ質問およびあらかじめ定義された回答をサーバに送信する。ユーザ質問およびあらかじめ定義された回答は、リソース取得者(すなわち、第2のユーザ)を検証するために使用される。サーバはさらに、リソースの位置情報として第1のユーザの位置情報を取得する。次いで、別のユーザが、位置特定サービスに基づいて、位置情報に対応するリソースを識別できるように、サーバは位置情報をリリースする。もちろん、リソースを識別するユーザがリソースを取得する必要があると、サーバは、第1のユーザによって設定されたユーザ質問およびあらかじめ定義された回答に基づいて、第2のユーザを検証することができる。第2のユーザに対する検証が成功したときにのみ、サーバは、リソースをユーザに送信し、したがって、ユーザはリソースを取得する。
【００４１】
既存の技術と比較して、ユーザ質問は、リソース取得者が指定された位置において特定のターゲットオブジェクトを検索し、画像を収集するという面倒なプロセスを軽減するように設定される。したがって、リソースを便利に、簡単に取得することができ、リソース取得プロセスを単純化することができる。
【００４２】
第1のユーザでは、本出願の本実装形態において提供されるリソース送信プロセスが図1cに示されており、以下のステップを含む。
【００４３】
S111。リソース送信動作を受信する。
【００４４】
リソース送信動作は、リソースをサーバに送信するようにエンドユーザデバイスに指示するために、第1のユーザのエンドユーザデバイス対して、第1のユーザによって開始することができる。実際には、リソース送信動作は、送信される必要があるリソースの設定動作、およびユーザ質問およびあらかじめ定義された回答の編集動作を含むことができる。ここでは、本出願に制限は課されない。
【００４５】
S112。リソース送信動作に基づいてリソース送信要求を生成する。
【００４６】
ユーザが送信動作を開始した後、エンドユーザデバイスは、対応するリソース送信要求を生成するために、リソース、ユーザ質問、およびリソース送信動作に対応するあらかじめ定義された回答を決定することができる。したがって、本出願の本実装形態において、リソース送信要求は、少なくとも、送信されるべきリソース、リソースに一致するユーザ質問、およびリソースに対応する位置情報を含む。
【００４７】
S113。サーバが位置情報をリリースし、ユーザ質問に基づいて、位置情報に基づいてリソースを取得する第2のユーザを検証し、検証の成功後、リソースを第2のユーザに送信するように、リソース送信要求をサーバに送信する。
【００４８】
サーバが第1のユーザによって送信されたリソース送信要求を受信した後、後続のステップは、前に説明した方法を参照して、サーバによって実行することができる。簡単のために、詳細はここでは省略する。
【００４９】
図1bおよび図1cに示された説明された方法に基づいて、第1のユーザによって送信されるリソースは、リソースを償還するための情報(たとえば、商品償還コード)、すなわち、本出願のいくつかの実装形態では、実際にはリソース償還情報とすることができる。言い換えれば、第2のユーザは、第1のユーザによって送信されたリソース償還情報を取得した後、リソース償還情報を使用して、あるリソースを償還することができる。
【００５０】
本シナリオにおける方法では、アーキテクチャを図2aに示すことができる。図1aに示すアーキテクチャと比較すると、リソースプロバイダが図2aのアーキテクチャに追加されている。リソースプロバイダは、オフラインマーチャント、電気通信事業者、銀行などを含むことができる。リソース償還情報は、記載された方法でサーバによって生成することができる。図2aに示すアーキテクチャでは、サーバは、リソース償還情報サービスを提供することを理解されたい。言い換えれば、サーバは、(通常、第1のユーザがリソースプロバイダによって提供されたリソースを取得したとき)同じリソース償還情報を第1のユーザおよびリソースプロバイダに送信することができる。
【００５１】
たとえば、図2aに示すアーキテクチャに基づくと、第1のユーザは、オフラインマーチャント(すなわち、リソースプロバイダ)のある商品を購入した後(ただし、第1のユーザは、購入した商品を保持していない)、サーバによって提供されるリソース償還情報サービスを使用することができる。言い換えれば、サーバは、同じ商品償還コードを第1のユーザおよびオフラインマーチャントに別々に送信する。説明した例と同様に、第1のユーザは、商品償還コードを、送信されるべきリソースとしてサーバに送信し、サーバを使用することによって、商品償還コードの位置をリリースする。第2のユーザは、商品償還コードを取得した後、商品をオフラインマーチャントから償還することができ、オフラインマーチャントは、記憶されたリソース償還コードに基づいて、検証を実行することができる。
【００５２】
実際には、図2aに示されたサーバは、サービスプラットフォーム(たとえば、支払いプラットフォームまたは銀行)のサーバと見なすことができる。言い換えれば、第1のユーザとリソースプロバイダとの間のリソース対話(たとえば、第1のユーザはリソースプロバイダからある商品を購入する)は、サーバのサポートにより完了する。したがって、サーバは、アカウントなどの識別子、およびプラットフォーム上の第1のユーザおよびリソースプロバイダのユーザIDに基づいて、リソース償還情報を第1のユーザおよびリソースプロバイダに送信する。明らかに、サーバは、同じリソース償還情報を第1のユーザおよびリソースプロバイダに送信する。
【００５３】
図2bに示すアーキテクチャに基づくと、第1のユーザは、最初に、リソース償還情報を取得する必要があり、次いで、サーバがリソース償還情報の位置をリリースするように、リソース送信要求をサーバに送信することがわかる。
【００５４】
したがって、第1のユーザでは、リソース送信動作を受信するステップの前に、方法は、サーバが償還情報取得要求に対応するリソース償還情報をフィードバックするように、償還情報取得要求をサーバに送信するステップと、送信されるべきリソースと決定されたリソース償還情報を受信するステップとをさらに含む。
【００５５】
対応して、サーバでは、第1のユーザのリソース送信要求を受信するステップの前に、方法は、第1のユーザによって送信された償還情報取得要求を受信するステップと、償還情報取得要求に基づいてリソース償還情報を生成し、リソース償還情報を第1のユーザにフィードバックするステップとをさらに含む。したがって、第1のユーザのリソース送信要求を受信するステップは、第1のユーザによって送信され、リソース償還情報をリソースとして使用するリソース送信要求を受信するステップを含む。
【００５６】
第1のユーザは、次の2つのケースでリソース償還情報を取得することができる。
【００５７】
ケース1:第1のユーザがリソースプロバイダ(たとえば、オフラインマーチャント)との取引を完了した後、サーバは、第1のユーザに、リソース償還情報を取得するかどうかを能動的に問い合わせる。
【００５８】
ケース2:第1のユーザは、リソースプロバイダ(たとえば、オフラインマーチャント)との取引を完了した後いつでも、リソース償還情報を取得する動作を能動的に開始することができる。
【００５９】
以下は、実際に2つのケースを説明している(リソース償還情報は、商品償還コードであり、リソースプロバイダは、オフラインマーチャントである)。
【００６０】
ケース1:
【００６１】
サーバは、支払いサービスを提供する。言い換えれば、第1のユーザとオフラインマーチャントの両方が、サーバによって提供される支払いサービスを使用する。したがって、第1のユーザおよびオフラインマーチャントが取引を完了した後、サーバは、取引情報を取得する。サーバでは、第1のユーザによって送信された償還情報取得要求を受信するステップの前に、方法は、第1のユーザとリソース償還サービスを提供するオフラインマーチャントとの間の取引に関する情報を受信するステップと、第1のユーザに対するリソース送信クエリを開始するステップとをさらに含む。
【００６２】
取引情報は、取引注文番号、取引における2人のユーザのユーザ情報などを含むことができる。
【００６３】
したがって、第1のユーザが商品償還コードを取得しようとしている場合、第1のユーザは、サーバのクエリに基づいて対応する要求を送信することができる。さらに、リソース償還情報を生成し、第1のユーザにリソース償還情報をフィードバックするステップは、取引情報に基づいて、第1のユーザのユーザ情報およびオフラインマーチャントのユーザ情報を決定するステップと、第1のユーザのユーザ情報およびオフラインマーチャントのユーザ情報に対応するリソース償還コードを生成するステップと、リソース償還コードを第1のユーザおよびオフラインマーチャントにフィードバックするステップとを含む。
【００６４】
ケース2:
【００６５】
第1のユーザは、オフラインマーチャントからある商品を購入した後、商品償還コード要求を能動的に開始する。第1のユーザでは、サーバに償還情報取得要求を送信するステップは、第1のユーザのユーザ情報、およびリソース償還サービスを提供するオフラインマーチャントのユーザ情報を取得するステップと、第1のユーザのユーザ情報およびオフラインマーチャントのユーザ情報を含む商品償還コード要求をサーバに送信するステップとを含む。
【００６６】
対応して、サーバでは、第1のユーザによって送信された償還情報取得要求を受信するステップは、第1のユーザによって送信され、第1のユーザのユーザ情報、およびリソース償還サービスを提供するオフラインマーチャントのユーザ情報を含む商品償還コード要求を受信するステップを含む。
【００６７】
もちろん、記載された内容は、本出願に制限を課すものではない。
【００６８】
さらに、本シナリオの別の方法では、リソース償還情報を、リソースプロバイダによって生成することができる。
【００６９】
たとえば、図2bに示すアーキテクチャに基づくと、第1のユーザは、オフラインマーチャントからある商品を購入する。したがって、オフラインマーチャントは、第1のユーザのための商品償還コード(すなわち、リソース償還情報)を生成することができる。したがって、第1のユーザは、商品償還コードを送信されるべきリソースとして使用し、商品償還コードをリソース送信要求に追加し、リソース送信要求をサーバに送信することができ、サーバは、リソースの位置情報をリリースする。したがって、商品償還コードを取得する別のユーザは、商品償還コードを使用して、対応するオフラインマーチャントにおいて第1のユーザによって購入された商品を償還することができる。
【００７０】
もちろん、実際には、第1のユーザに関するリソース償還情報を生成した後、リソースプロバイダは、第1のユーザがリソース償還情報をサーバに送信するように、インスタントメッセージング(IM)、ショートメッセージサービス(SMS)などを使用することによって、リソース償還情報を第1のユーザに送信することができる。ここでは、制限は課されない。
【００７１】
もちろん、ここでは、本出願に制限は課されない。
【００７２】
別のユーザは、位置特定サービスに基づいてリソース情報を識別し、さらに、サーバが第1のユーザによって送信されたリソースの位置をリリースするので、リソースを取得することができる。以下は、リソース取得プロセスについて説明する。
【００７３】
リソース取得段階:
【００７４】
第2のユーザでは、本出願の本実装形態において提供されるリソース送信プロセスが図3aに示されており、以下のステップを含む。
【００７５】
S301。リソースの質問検証条件がトリガされた後、サーバによって送信され、送信されたリソースに対応するユーザ質問を受信する。
【００７６】
リソースが、第1のユーザによってサーバに送信され、サーバが、そのリソースの位置情報をリリースする。
【００７７】
本出願の本実装形態において、質問検証条件をトリガするステップは、以下を含むことができる。第2のユーザは、位置特定サービスに基づいて、送信されたリソースを能動的に検索し、リソースを取得する、または、サーバは、第2のユーザの位置が、送信されたリソースの位置の指定された範囲内にあることを検出する。
【００７８】
言い換えれば、送信されたリソースの質問検証条件をトリガするステップは、リリースされた位置情報に基づいて識別されたリソースを取得する要求をサーバに送信するステップ、または第2のユーザの位置が、送信されたリソースの位置の指定された範囲内にあることを検出するステップを含む。
【００７９】
第2のユーザが質問検証条件をトリガすると、サーバは、対応するユーザ質問を第2のユーザに送信する。
【００８０】
もちろん、本出願の本実装形態では、第2のユーザは、位置特定サービスを使用することによって、第1のユーザがリソースを送信する位置について検索することができる。言い換えれば、リリースされた位置情報に基づいて識別されたリソースを取得する要求をサーバに送信するステップは、現在の位置に関する情報を決定するステップと、位置の指定された範囲内で、リリースされたリソース位置情報を検索するステップと、識別されたリソースを取得することの指示を受信するステップと、取得要求を生成するステップと、取得要求をサーバに送信するステップとを含む。
【００８１】
S302。サーバが、検証されるべき回答を検証し、検証の成功後、リソースをフィードバックするように、ユーザ質問に基づいて検証されるべき回答をサーバにフィードバックする。
【００８２】
上記で説明したように、第1のユーザは、サーバに送信されたリソースについて対応するユーザ質問を設定する。したがって、サーバは、検証のために、リソースに対応するユーザ質問を第2のユーザに送信する。
【００８３】
S303。サーバによって送信されたリソースを取得する。
【００８４】
上記は、第2ユーザ側に基づく実行処理である。サーバでは、本出願の実装形態は、リソース送信方法をさらに提供する。図3bに示されるように、方法は、以下のステップを含む。
【００８５】
S311。第2のユーザが送信されたリソースの質問検証条件をトリガしたかどうかを検出する。
【００８６】
質問検証条件をトリガするステップは、前に説明した内容と同じである。言い換えれば、第2のユーザが送信されたリソースの質問検証条件をトリガしたかどうかを検出するステップは、送信されたリソースについて第2のユーザによって送信されたリソース取得要求を検出し、受信するステップ、または、第2のユーザの位置が、送信されたリソースの位置の指定された範囲内にあることを検出するステップを含む。
【００８７】
S312。第2のユーザがユーザ質問に基づいて検証されるべき回答をフィードバックするように、第2のユーザが質問検証条件をトリガしたことを検出したことに応答して、送信されたリソースに対応するユーザ質問を第2のユーザに送信する。
【００８８】
S313。第2のユーザによってフィードバックされた検証されるべき回答を受信し、検証する。
【００８９】
S314。検証が成功すると、リソースを第2のユーザに送信する。
【００９０】
説明した内容と同様に、図2aまたは図2bに示すアーキテクチャも、リソース取得段階で使用できる。本出願の本実装形態では、サーバが第2のユーザについて対応する制限条件を設定することに留意する価値がある。図3bに示す方法は、リソース取得要求を送信する第2のユーザのユーザ情報を決定するステップと、ユーザ情報に基づいて、第2のユーザによって送信されたリソース取得要求の量、または検証時間の量をカウントするステップと、リソース取得要求の量または検証回数の量が指定された量を超えると、所定のオーバーランプロンプト情報を第2のユーザにフィードバックするステップとをさらに含む。第2のユーザがサーバによって設定された制限条件を超えると、第2のユーザはリソースを取得できないことがわかる。
【００９１】
対応して、第2のユーザでは、方法は、サーバによってフィードバックされたオーバーランプロンプト情報を受信し、表示するステップをさらに含む。言い換えれば、第2のユーザのエンドユーザデバイスは、リソースを現在取得することができないことを示すために、オーバーランプロンプト情報を表示する。
【００９２】
もちろん、特定の時間期間内で、量に対する制限が有効であり得る。たとえば、量は、自然日ごとに有効になり、量は、次の自然日に更新される。ここでは、本出願に制限は課されない。
【００９３】
もちろん、図2aのリソースプロバイダでは、本出願の実装形態は、リソースプロバイダ側に基づくリソース送信方法を提供する。図3cに示すように、方法は、以下のステップを含む。
【００９４】
S321。第2のユーザによって送信されたリソース償還情報を受信する。
【００９５】
S322。記憶されたリソース償還情報に基づいて、第2のユーザによって送信されたリソース償還情報を検証する。
【００９６】
第1のユーザとの取引に関する情報がサーバに送信された後、サーバによって、記憶されたリソース償還情報が生成され、送信される。
【００９７】
S323。検証の成功後、第2のユーザのためのリソース償還情報に対応するリソースを提供する。
【００９８】
言い換えれば、リソースプロバイダは、最初に、第1のユーザとの支払いなどの動作を完了し、したがって、いくつかのリソースは、第1のユーザに属し(たとえば、第1のユーザがある商品を購入する場合、商品は第1のユーザに属する)、サーバによって生成されたリソース償還情報がさらに取得される。対応して、第1のユーザは、サーバを使用することによって、リソース償還情報の位置をリリースすることができる。したがって、リソース償還情報を取得する第2のユーザは、最初に第1のユーザに属するリソースをリソースプロバイダから取得することができる。
【００９９】
もちろん、図2bのリソースプロバイダでは、同様のステップを実行することができる。簡単のために、詳細はここでは省略する。
【０１００】
本出願の本実装形態におけるリソース送信方法が仮想レッドエンベロープのシナリオに適用可能であることに留意する価値がある。以下は、仮想レッドエンベロープのシナリオに基づく本出願の本実装形態において説明された方法を説明する(本シナリオで説明された方法ステップの概略フローチャートは提供されない)。
【０１０１】
まず、第1のユーザとオフラインマーチャントとの間の取引が完了する。言い換えれば、第1のユーザは、オフラインマーチャントからある商品を購入し、サーバを使用することによって、商品償還コードを取得する。
【０１０２】
上記に基づいて、仮想レッドエンベロープを送信するプロセスは以下の通りである。
【０１０３】
このシナリオでは、サーバ側において、以下のステップを含めることができる。
【０１０４】
S401。第1のユーザによって送信された仮想レッドエンベロープ、仮想レッドエンベロープに一致するレッドエンベロープの質問、およびレッドエンベロープの回答を受信する。仮想レッドエンベロープ送信要求は、送信されるべき商品償還コード、商品償還コードに一致するユーザ質問、および仮想レッドエンベロープに対応する位置情報のうちの少なくとも1つを含む。
【０１０５】
S402。第2のユーザがリリースされた位置情報に基づく検索によって仮想レッドエンベロープを取得するとき、ユーザ質問に基づいて第2のユーザを検証するために、位置情報をリリースし、検証の成功後、仮想エンベロープにおける商品償還コードを第2のユーザに送信する。
【０１０６】
第1のユーザ側において、以下のステップを含めることができる。
【０１０７】
S501。レッドエンベロープ送信動作を受信する。
【０１０８】
S502。レッドエンベロープ送信動作に基づいて、仮想レッドエンベロープ送信要求を生成し、仮想レッドエンベロープ送信要求は、送信されるべき商品償還コード、商品償還コードに一致するユーザ質問、および仮想レッドエンベロープに対応する位置情報のうちの少なくとも1つを含む。
【０１０９】
S503。仮想レッドエンベロープ送信要求をサーバに送信し、したがって、サーバが位置情報をリリースし、レッドエンベロープの質問に基づいて、位置情報に基づいて仮想レッドエンベロープを取得する第2のユーザを検証し、検証の成功後、仮想レッドエンベロープにおける商品償還コードを第2のユーザに送信する。
【０１１０】
仮想レッドエンベロープを送信するプロセスにおいて、第1のユーザは、エンドユーザデバイスを使用して、実際に仮想レッドエンベロープが送信されるように設定することができる。たとえば、第1のユーザは、オフラインマーチャントからある商品を購入し、商品償還コードを取得すると、仮想レッドエンベロープを送ることができる(商品償還コードはサーバによって生成される)。図4aに示すように、仮想レッドエンベロープインターフェースが第1のユーザのエンドユーザデバイスインターフェースに表示され、第1のユーザは、仮想レッドエンベロープインターフェースでレッドエンベロープの質問およびレッドエンベロープの回答を設定することができる。エンドユーザデバイスは、ユーザが「レッドエンベロープ」コントロールをタップした後、説明された方法ステップに基づいて、仮想レッドエンベロープをサーバに送信することができる。簡単のために、詳細はここでは省略する。
【０１１１】
仮想レッドエンベロープを取得するプロセスは以下の通りである。
【０１１２】
サーバ側において、以下のステップを含めることができる。
【０１１３】
S601。第2のユーザが送信された仮想レッドエンベロープのレッドエンベロープ質問検証条件をトリガしたかどうかを検出する。
【０１１４】
S602。第2のユーザがレッドエンベロープの質問検証条件をトリガしたことを検出したことに応答して、仮想レッドエンベロープに対応するレッドエンベロープの質問を第2のユーザに送信する。
【０１１５】
S603。仮想レッドエンベロープにおける商品償還コードを第2のユーザに送信する。
【０１１６】
第2のユーザ側において、以下のステップを含めることができる。
【０１１７】
S701。仮想レッドエンベロープの質問検証条件がトリガされた後、サーバによって送信され、送信された仮想レッドエンベロープに対応するレッドエンベロープの質問を受信する。
【０１１８】
S702。サーバが、検証されるべき回答を検証し、検証の成功後、仮想レッドエンベロープにおける商品償還コードをフィードバックするように、レッドエンベロープの質問に基づいて検証されるべき回答をサーバにフィードバックする。
【０１１９】
S703。サーバによってフィードバックされた商品償還コードを取得する。
【０１２０】
図4aに示す例に基づいて、第2のユーザが仮想レッドエンベロープを取得すると、図4bのようにエンドユーザデバイスのインターフェースを示すことができる。言い換えれば、第2のユーザは、レッドエンベロープのロックを解除するために、インターフェースに表示されたレッドエンベロープの質問についての検証されるべき回答として対応する情報を入力する必要がある。さらに、本出願の本実装形態では、第2のユーザは、第1のユーザとのインスタントメッセージングチャットを開始するために、レッドエンベロープインターフェース上の機能オプション「TAに助けを求める」をタップして、第1のユーザに、レッドエンベロープの質問に対する回答を問い合わせることができる。
【０１２１】
商品償還プロセス:
【０１２２】
第2のユーザは、商品償還コードを取得した後、オフラインマーチャントから商品を償還することができる。言い換えれば、商品償還プロセスは、オフラインマーチャント側において、以下のステップを含むことができる。
【０１２３】
S801。第2のユーザによって送信された商品償還コードを受信する。
【０１２４】
S802。記憶された商品償還コードに基づいて、第2のユーザによって送信された商品償還コードを検証し、第1のユーザとの取引に関する情報がサーバに送信された後、サーバによって、記憶された商品償還コードが生成され、送信される。
【０１２５】
S803。検証の成功後、第2のユーザのための商品償還コードに対応する商品を提供する。
【０１２６】
上記は、本出願の実装形態において提供されるリソース送信方法を説明している。同じ考えに基づいて、本出願の一実装形態は、リソース送信装置をさらに提供する。
【０１２７】
図5に示すように、リソース送信装置は、サーバ側に配置され、第1のユーザのリソース送信要求を受信するように構成された受信モジュール501であり、リソース送信要求が、少なくとも、送信されるべきリソース、リソースに一致するユーザ質問、およびリソースに対応する位置情報を含む、受信モジュール501と、第2のユーザがリリースされた位置情報に基づく検索によってリソースを取得するとき、ユーザ質問に基づいて第2のユーザを検証するために、位置情報をリリースし、検証の成功後、リソースを第2のユーザに送信するように構成されたリリースモジュール502とを含む。
【０１２８】
装置は、第1のユーザによって送信された償還情報取得要求を受信し、償還情報取得要求を受信した後、リソース償還情報を生成し、リソース償還情報を第1のユーザにフィードバックするように構成された償還情報モジュール503をさらに含む。
【０１２９】
受信モジュール501は、第1のユーザによって送信され、リソース償還情報をリソースとして使用するリソース送信要求を受信する。
【０１３０】
リソース償還情報は、少なくとも商品償還コードを含む。
【０１３１】
償還情報モジュール503は、第1のユーザによって送信された償還情報取得要求を受信する前に、第1のユーザとリソース償還サービスを提供するオフラインマーチャントとの間の取引に関する情報を受信し、第1のユーザに対するリソース送信クエリを開始し、リソース送信クエリに基づいて、第1のユーザによって送信された商品償還コード要求を受信し、取引情報に基づいて、第1のユーザのユーザ情報およびオフラインマーチャントのユーザ情報を決定し、第1のユーザのユーザ情報およびオフラインマーチャントのユーザ情報に対応するリソース償還コードを生成し、リソース償還コードを第1のユーザおよびオフラインマーチャントにフィードバックする。
【０１３２】
償還情報モジュール503は、第1のユーザによって送信され、第1のユーザのユーザ情報、およびリソース償還サービスを提供するオフラインマーチャントのユーザ情報を含む商品償還コード要求を受信する。
【０１３３】
もちろん、実際の仮想レッドエンベロープのシナリオでは、受信モジュール501は、第1のユーザの仮想レッドエンベロープ送信要求を受信し、仮想レッドエンベロープ送信要求は、送信されるべき商品償還コード、商品償還コードに一致するユーザ質問、および仮想レッドエンベロープに対応する位置情報のうちの少なくとも1つを含み、リリースモジュール502は、第2のユーザがリリースされた位置情報に基づく検索によって仮想レッドエンベロープを取得するとき、ユーザ質問に基づいて第2のユーザを検証するために、位置情報をリリースし、検証の成功後、仮想エンベロープにおける商品償還コードを第2のユーザに送信する。
【０１３４】
本出願の一実装形態はさらに、第1のユーザ側にリソース送信装置を提供する。図6に示すように、装置は、リソース送信動作を受信するように構成された受信モジュール601と、リソース送信動作に基づいて、リソース送信要求を生成するように構成された要求生成モジュール602であり、リソース送信要求が、少なくとも、送信されるべきリソース、リソースに一致するユーザ質問、およびリソースに対応する位置情報を含む、要求生成モジュール602と、サーバが位置情報をリリースし、ユーザ質問に基づいて、位置情報に基づいてリソースを取得する第2のユーザを検証し、検証の成功後、リソースを第2のユーザに送信するように、リソース送信要求をサーバに送信するように構成された送信モジュール603とを含む。
【０１３５】
装置は、サーバが償還情報取得要求に対応するリソース償還情報をフィードバックするように、償還情報取得要求をサーバに送信し、送信されるべきリソースと決定されたリソース償還情報を受信するように構成された償還情報取得モジュール604をさらに含む。
【０１３６】
リソース償還情報は、少なくとも商品償還コードを含む。
【０１３７】
償還情報取得要求をサーバに送信する前に、償還情報取得モジュール604は、オフラインマーチャントとの取引に関する情報をサーバに送信し、取引情報に基づいてサーバによって開始されたリソース送信クエリを受信する。
【０１３８】
償還情報取得モジュール604は、第1のユーザのユーザ情報、およびリソース償還サービスを提供するオフラインマーチャントのユーザ情報を取得し、第1のユーザのユーザ情報およびオフラインマーチャントのユーザ情報を含む商品償還コード要求をサーバに送信する。
【０１３９】
もちろん、実際の仮想レッドエンベロープのシナリオでは、受信モジュール601は、レッドエンベロープ送信動作を受信し、要求生成モジュール602は、レッドエンベロープ送信動作に基づいて、仮想レッドエンベロープ送信要求を生成し、仮想レッドエンベロープ送信要求は、送信されるべき商品償還コード、商品償還コードに一致するユーザ質問、および仮想レッドエンベロープに対応する位置情報のうちの少なくとも1つを含み、送信モジュール603は、仮想レッドエンベロープ送信要求をサーバに送信し、したがって、サーバが位置情報をリリースし、レッドエンベロープの質問に基づいて、位置情報に基づいて仮想レッドエンベロープを取得する第2のユーザを検証し、検証の成功後、仮想レッドエンベロープにおける商品償還コードを第2のユーザに送信する。
【０１４０】
リソース取得段階では、本出願の一実装形態はさらに、サーバ側にリソース送信装置を提供する。図7に示すように、装置は、第2のユーザが送信されたリソースの質問検証条件をトリガしたかどうかを検出するように構成された検出モジュール701と、第2のユーザがユーザ質問に基づいて検証されるべき回答をフィードバックするように、第2のユーザが質問検証条件をトリガしたことを検出したことに応答して、送信されたリソースに対応するユーザ質問を第2のユーザに送信するように構成された質問フィードバックモジュール702と、第2のユーザによってフィードバックされた検証されるべき回答を受信し、検証するように構成された検証モジュール703と、検証が成功すると、リソースを第2のユーザに送信するように構成されたリソース送信モジュール704とを含む。
【０１４１】
検出モジュール701は、送信されたリソースについて第2のユーザによって送信されたリソース取得要求を検出し、受信する、または、第2のユーザの位置が、送信されたリソースの位置の指定された範囲内にあることを検出する。
【０１４２】
装置は、リソース取得要求を送信する第2のユーザのユーザ情報を決定し、ユーザ情報に基づいて、第2のユーザによって送信されたリソース取得要求の量、または検証時間の量をカウントし、リソース取得要求の量または検証回数の量が指定された量を超えると、所定のオーバーランプロンプト情報を第2のユーザにフィードバックするように構成されたオーバーランプロンプトモジュール705をさらに含む。
【０１４３】
もちろん、実際の仮想レッドエンベロープのシナリオでは、検出モジュール701は、第2のユーザが送信された仮想レッドエンベロープのレッドエンベロープ質問検証条件をトリガしたかどうかを検出し、質問フィードバックモジュール702は、第2のユーザがレッドエンベロープの質問検証条件をトリガしたことを検出したことに応答して、仮想レッドエンベロープに対応するレッドエンベロープの質問を第2のユーザに送信し、リソース送信モジュール704は、仮想レッドエンベロープにおける商品償還コードを第2のユーザに送信する。
【０１４４】
本出願の一実装形態はさらに、第2のユーザ側にリソース送信装置を提供する。図8に示すように、装置は、リソースの質問検証条件がトリガされた後、サーバによって送信され、送信されたリソースに対応するユーザ質問を受信するように構成された受信モジュール801であり、リソースが、第1のユーザによってサーバに送信され、サーバが、そのリソースの位置情報をリリースする、受信モジュール801と、サーバが、第1のユーザによって送信されたあらかじめ定義された回答に基づいて、検証されるべき回答を検証し、検証の成功後、リソースを第2のユーザにフィードバックするように、ユーザ質問に基づいて検証されるべき回答をサーバにフィードバックするように構成された回答送信モジュール802と、サーバによって送信されたリソースを取得するように構成された取得モジュール803とを含む。
【０１４５】
送信されたリソースの質問検証条件をトリガすることは、リリースされた位置情報に基づいて識別されたリソースを取得する要求をサーバに送信すること、または第2のユーザの位置が、送信されたリソースの位置の指定された範囲内にあることを検出することを含む。
【０１４６】
装置は、現在の位置に関する情報を決定し、位置の指定された範囲内で、リリースされたリソース位置情報を検索し、識別されたリソースを取得することの指示を受信し、取得要求を生成し、取得要求をサーバに送信するように構成されたリソース検索モジュール804をさらに含む。
【０１４７】
受信モジュール801は、サーバによってフィードバックされたオーバーランプロンプト情報を受信し、表示する。
【０１４８】
もちろん、実際の仮想レッドエンベロープのシナリオでは、受信モジュール801は、仮想レッドエンベロープの質問検証条件がトリガされた後、サーバによって送信され、送信された仮想レッドエンベロープに対応するレッドエンベロープの質問を受信し、回答送信モジュール802は、サーバが、検証されるべき回答を検証し、検証の成功後、仮想レッドエンベロープにおける商品償還コードをフィードバックするように、レッドエンベロープの質問に基づいて検証されるべき回答をサーバにフィードバックし、取得モジュール803は、サーバによってフィードバックされた商品償還コードを取得する。
【０１４９】
オフラインマーチャントでは、本出願の一実装形態は、リソース送信装置をさらに提供する。図9に示すように、装置は、第2のユーザによって送信されたリソース償還コードを受信するように構成された受信モジュール901と、記憶されたリソース償還コードに基づいて、第2のユーザによって送信されたリソース償還情報を検証するように構成された検証モジュール902であり、第1のユーザとの取引に関する情報がサーバに送信された後、サーバによって、記憶されたリソース償還情報が生成され、送信される、検証モジュール902と、検証の成功後、第2のユーザのためのリソース償還情報に対応するリソースを提供するように構成されたリソース提供モジュール903とを含む。
【０１５０】
もちろん、実際の仮想レッドエンベロープのシナリオでは、受信モジュール901は、第2のユーザによって送信された商品償還コードを受信し、検証モジュール902は、記憶された商品償還コードに基づいて、第2のユーザによって送信された商品償還コードを検証し、サーバによって、記憶された商品償還コードが生成され、送信され、リソース提供モジュール903は、検証の成功後、第2のユーザのための商品償還コードに対応する商品を提供する。
【０１５１】
1990年代には、技術の改善がハードウェアの改善(たとえば、ダイオード、トランジスタ、スイッチなどの回路構造の改善)であるか、ソフトウェアの改善(方法手順の改善)であるかは明らかに区別できる。しかしながら、技術が発展するにつれて、多くの方法手順に対する現在の改善は、ハードウェア回路構造に対する直接的な改善と考えることができる。設計者は通常、対応するハードウェア回路構造を得るために、改良された方法手順をハードウェア回路にプログラムする。したがって、方法手順は、ハードウェアエンティティモジュールを使用することによって改善することができる。たとえば、プログラマブル論理デバイス(PLD)(たとえばフィールドプログラマブルゲートアレイ(FPGA))は、そのような集積回路であり、PLDの論理機能は、デバイスプログラミングを介してユーザによって決定される。設計者は、チップ製造者に特定用途向け集積回路チップの設計および製造を要求することなく、デジタルシステムをPLDに「統合」するためのプログラミングを実行する。さらに、現在、この種のプログラミングは、大部分は、集積回路チップを手動で製造する代わりに、「論理コンパイラ」ソフトウェアを使用することによって実装される。プログラミングは、プログラムの開発およびコンパイルに使用されるソフトウェアコンパイラに似ている。しかしながら、コンパイル前の元のコードは、特定のプログラミング言語で記述する必要がある。この言語は、ハードウェア記述言語(HDL)と呼ばれる。Advanced Boolean Expression Language(ABEL)、Alteraハードウェア記述言語(AHDL)、Confluence、Cornell Universityプログラミング言語(CUPL)、HDCal、Java(登録商標)ハードウェア記述言語(JHDL)、Lava、Lola、MyHDL、PALASM、およびRubyハードウェア記述言語(RHDL)など、多くの種類のHDLがある。現在、超高速集積回路ハードウェア記述言語(VHDL)およびVerilogが最も一般的に使用されている。当業者であれば、いくつかの記載されたハードウェア記述言語を使用することによって、方法手順が論理的にプログラムされ、集積回路にプログラムされると、論理的方法手順を実装するハードウェア回路を容易に取得できることも理解されたい。
【０１５２】
コントローラは、任意の適切な方法を使用することによって実装され得る。たとえば、コントローラは、マイクロプロセッサ、またはプロセッサ、またはコンピュータ可読媒体、論理ゲート、スイッチ、特定用途向け集積回路(ASIC)、プログラマブル論理コントローラ、あるいはマイクロプロセッサまたはプロセッサによって実行することができる(ソフトウェアまたはファームウェアなどの)コンピュータ可読プログラムコードを記憶する内蔵マイクロプロセッサであり得る。コントローラの例には、限定はしないが、ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20、およびSilicone Labs C8051F320のマイクロプロセッサがある。メモリコントローラは、メモリの制御論理の一部として実装することもできる。当業者はまた、コンピュータ可読プログラムコードを使用することによってコントローラを実装することに加えて、コントローラが論理ゲート、スイッチ、特定用途向け集積回路、プログラマブル論理コントローラ、内蔵マイクロコントローラなどの形態で同じ機能を実装することを可能にする方法ステップにおいて論理プログラミングを実行できることも知っている。したがって、コントローラは、ハードウェア構成要素と見なすことができ、コントローラ内で様々な機能を実装するように構成された装置も、ハードウェア構成要素内の構造と見なすことができる。代替的に、様々な機能を実装するように構成された装置は、この方法を実装するためのソフトウェアモジュールとハードウェア構成要素内の構造の両方と見なすことができる。
【０１５３】
説明した実装形態に記載したシステム、装置、モジュール、またはユニットは、コンピュータチップまたはエンティティによって実装することができ、あるいは特定の機能を有する製品を使用することによって実装することができる。典型的な実装デバイスは、コンピュータである。コンピュータは、たとえば、パーソナルコンピュータ、ラップトップコンピュータ、携帯電話、カメラ付き携帯電話、スマートフォン、パーソナルデジタルアシスタント、メディアプレーヤ、ナビゲーションデバイス、電子メールデバイス、ゲーム機、タブレットコンピュータ、ウェアラブルデバイス、またはこれらのデバイスうちの任意の組合せとすることができる。
【０１５４】
説明しやすいように、説明した装置は、機能を様々なユニットに分割することによって説明される。もちろん、本出願が実装されるとき、各ユニットの機能は、1つまたは複数のソフトウェアおよび/またはハードウェアにおいて実装され得る。
【０１５５】
当業者であれば、本発明の実装形態が、方法、システム、またはコンピュータプログラム製品として提供され得ることを理解されたい。したがって、本発明は、ハードウェアのみの実装形態、ソフトウェアのみの実装形態、またはソフトウェアとハードウェアの組合せを用いた実装形態の形を使用することができる。さらに、本発明は、コンピュータで使用可能なプログラムコードを含む1つまたは複数のコンピュータ使用可能な記憶媒体(限定はしないが、ディスクメモリ、CD-ROM、光学メモリなどを含む)上に実装されるコンピュータプログラム製品の形態を使用することができる。
【０１５６】
本発明は、本発明の実装形態に基づく方法、デバイス(システム)、およびコンピュータプログラム製品のフローチャートおよび/またはブロック図を参照して説明される。フローチャートおよび/またはブロック図内の各プロセスおよび/または各ブロック、ならびにフローチャートおよび/またはブロック図内のプロセスおよび/またはブロックの組合せを実装するためにコンピュータプログラム命令を使用できることを理解されたい。これらのコンピュータプログラム命令は、汎用コンピュータ、専用コンピュータ、内蔵プロセッサ、または任意の他のプログラマブルデータ処理デバイスのプロセッサに提供されて機械を生成することができ、したがって、コンピュータまたは別のプログラマブルデータ処理デバイスのプロセッサによって実行される命令は、フローチャート内の1つまたは複数のプロセスおよび/またはブロック図内の1つまたは複数のブロックにおいて特定の機能を実施するための装置を生成する。
【０１５７】
これらのコンピュータプログラム命令は、コンピュータまたは任意の他のプログラマブルデータ処理デバイスに、特定の方法で動作するように命令することができるコンピュータ可読メモリに記憶することができ、したがって、コンピュータ可読メモリに記憶された命令は、命令装置を含むアーティファクトを生成する。命令装置は、フローチャート内の1つまたは複数のプロセス内および/またはブロック図内の1つまたは複数のブロック内で特定の機能を実施する。
【０１５８】
これらのコンピュータプログラム命令は、コンピュータまたは別のプログラマブルデバイス上で一連の動作およびステップが実行されるように、コンピュータまたは別のプログラマブルデータ処理デバイスにロードすることができ、それによってコンピュータ実施処理が生成される。したがって、コンピュータまたは別のプログラマブルデバイス上で実行される命令は、フローチャート中の1つまたは複数のプロセスおよび/またはブロック図中の1つまたは複数のブロックにおいて特定の機能を実施するためのステップを提供する。
【０１５９】
典型的な構成では、コンピューティングデバイスは、1つまたは複数のプロセッサ(CPU)、1つまたは複数の入出力インターフェース、1つまたは複数のネットワークインターフェース、および1つまたは複数のメモリを含む。
【０１６０】
メモリは、非永続的メモリ、ランダムアクセスメモリ(RAM)、不揮発性メモリ、および/または読取り専用メモリ(ROM)またはフラッシュメモリ(フラッシュRAM)などコンピュータ可読媒体内にある別の形態を含むことができる。メモリは、コンピュータ可読媒体の一例である。
【０１６１】
コンピュータ可読媒体は、任意の方法または技術を使用することによって情報記憶を実装することができる永続的、非永続的、移動可能、および移動不能の媒体を含む。情報は、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータとすることができる。コンピュータ記憶媒体は、限定はしないが、パラメータランダムアクセスメモリ(PRAM)、スタティックランダムアクセスメモリ(SRAM)、ダイナミックランダムアクセスメモリ(DRAM)、または別のタイプのランダムアクセスメモリ(RAM)、読取り専用メモリ(ROM)、電気的消去可能プログラマブル読取り専用メモリ(EEPROM)、フラッシュメモリまたは別のメモリ技術、コンパクトディスク読取り専用メモリ(CD-ROM)、デジタル多用途ディスク(DVD)または別の光学ストレージ、磁気テープ/磁気ディスクメモリまたは別の磁気記憶デバイス、あるいはコンピューティングデバイスによってアクセスされ得る情報を記憶するために使用され得る任意の他の非送信媒体を含む。本明細書の定義に基づいて、コンピュータ可読媒体は、一時的コンピュータ可読媒体(一時的媒体)、たとえば、変調されたデータ信号およびキャリアを含まない。
【０１６２】
さらに、用語「含む」、「含む」、またはそれらの任意の他の変形は、非排他的な包含をカバーするものとし、したがって、要素のリストを含むプロセス、方法、商品、またはデバイスは、それらの要素を含むだけでなく、明示的に挙げられていない他の要素をも含み、あるいはそのようなプロセス、方法、商品、またはデバイスに固有の要素をさらに含むことに留意する価値がある。より多くの制約なしに、「〜を含む」が先行する要素は、要素を含むプロセス、方法、商品、またはデバイスにおける追加の同一の要素の存在を排除しない。
【０１６３】
当業者であれば、本出願の実装形態が、方法、システム、またはコンピュータプログラム製品として提供され得ることを理解されたい。したがって、本出願は、ハードウェアのみの実装形態、ソフトウェアのみの実装形態、またはソフトウェアとハードウェアの組合せを用いた実装形態の形を使用することができる。さらに、本出願は、コンピュータ使用可能プログラムコードを含む1つまたは複数のコンピュータ使用可能記憶媒体(限定はしないが、ディスクメモリ、CD-ROM、光メモリなどを含む)上に実装されるコンピュータプログラム製品の形態を使用することができる。
【０１６４】
本出願は、たとえばプログラムモジュールなど、コンピュータによって実行されるコンピュータ実行可能命令の一般的な文脈で説明することができる。一般に、プログラムモジュールは、特定のタスクを実行するため、または特定の抽象データ型を実装するためのルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。本出願は、分散コンピューティング環境においても実施することができる。分散コンピューティング環境では、通信ネットワークを介して接続された遠隔処理デバイスによってタスクが実行される。分散コンピューティング環境では、プログラムモジュールは、記憶デバイスを含むローカルとリモートの両方のコンピュータ記憶媒体に配置することができる。
【０１６５】
本明細書における実装形態はすべて漸進的な方法で記載されている。実装形態の同一または類似の部分については、実装を参照することができる。各実装形態は、他の実装形態との違いに焦点を当てている。特に、システムの実装形態は方法の実装形態と基本的に似ており、したがって、簡単に説明されている。関連部分については、方法の実装形態の部分的な説明を参照できる。
【０１６６】
前の説明は、本出願の単なる実装形態であり、本出願を制限するためのものではない。当業者は、本出願に対して様々な修正および変更を加えることができる。本出願の意図および原理内で行われる任意の修正、等価の置換、改良などは、本出願の特許請求の範囲内に含まれるものとする。
【符号の説明】
【０１６７】
501  受信モジュール
502  リリースモジュール
503  償還情報モジュール
601  受信モジュール
602  要求生成モジュール
603  送信モジュール
604  償還情報取得モジュール
701  検出モジュール
702  質問フィードバックモジュール
703  検証モジュール
704  リソース検証モジュール
705  オーバーランプロンプトモジュール
801  受信モジュール
802  回答送信モジュール
803  取得モジュール
804  リソース検索モジュール
901  受信モジュール
902  検証モジュール
903  リソース提供モジュール
【図１ａ】
0006763088.tif 000002
【図１ｂ】
0006763088.tif 000003
【図１ｃ】
0006763088.tif 000004
【図２ａ】
0006763088.tif 000005
【図２ｂ】
0006763088.tif 000006
【図３ａ】
0006763088.tif 000007
【図３ｂ】
0006763088.tif 000008
【図３ｃ】
0006763088.tif 000009
【図４ａ】
0006763088.tif 000010
【図４ｂ】
0006763088.tif 000011
【図５】
0006763088.tif 000012
【図６】
0006763088.tif 000013
【図７】
0006763088.tif 000014
【図８】
0006763088.tif 000015
【図９】
0006763088.tif 000016