特許 6961840 サービス処理方法および装置、ならびに電子デバイス

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6961840

(24)【登録日】2021年10月15日

(45)【発行日】2021年11月5日

(54)【発明の名称】サービス処理方法および装置、ならびに電子デバイス

(51)【国際特許分類】

   G06Q 50/10 20120101AFI20211025BHJP

   G06Q 30/06 20120101ALI20211025BHJP

【ＦＩ】

   G06Q50/10

   G06Q30/06

【請求項の数】20

【全頁数】36

(21)【出願番号】特願2020-564424(P2020-564424)

(86)(22)【出願日】2019年6月18日

(65)【公表番号】特表2021-524107(P2021-524107A)

(43)【公表日】2021年9月9日

(86)【国際出願番号】CN2019091756

(87)【国際公開番号】WO2020029687

(87)【国際公開日】20200213

【審査請求日】2021年1月14日

(31)【優先権主張番号】201810887465.1

(32)【優先日】2018年8月6日

(33)【優先権主張国】CN

【早期審査対象出願】

(73)【特許権者】

【識別番号】520015461

【氏名又は名称】アドバンスド ニュー テクノロジーズ カンパニー リミテッド

(74)【代理人】

【識別番号】100188558

【弁理士】

【氏名又は名称】飯田 雅人

(74)【代理人】

【識別番号】100205785

【弁理士】

【氏名又は名称】▲高▼橋 史生

(72)【発明者】

【氏名】フェンウェイ・ワン

(72)【発明者】

【氏名】フイメイ・へ

(72)【発明者】

【氏名】ユ・チー

【審査官】 牧 裕子

(56)【参考文献】

【文献】 中国特許出願公開第１０７６２２４１２（ＣＮ，Ａ）

【文献】 特開２００２−３５２３３３（ＪＰ，Ａ）

【文献】 米国特許出願公開第２０１５／００３９３８８（ＵＳ，Ａ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｑ １０／００ − ９９／００

Ｇ１６Ｈ １０／００ − ８０／００

(57)【特許請求の範囲】

【請求項1】

サービスを処理するためのコンピュータにより実施される方法であって、
ユーザ端末から送信される情報を受信するステップであり、
前記情報が、前記ユーザ端末に対応する第1のユーザの信用値があらかじめ決定された値に達するとき、前記第1のユーザが、あらかじめ決定された時間期間内に第2のユーザにあらかじめ決定されたリソース量以上を送信すると確約する場合、前記第1のユーザによって送信されるリソース量と、前記第2のユーザによって前記第1のユーザに提供されるサービスオブジェクトに対応する標準のリソース量の比率が、第1の比率aとして定義され、0<a<1であることを備える、ステップと、
前記あらかじめ決定された時間期間内に、前記第1のユーザによって前記第2のユーザに送信される実際のリソース量が、前記あらかじめ決定された量未満であるとき、指定された最終期限までに前記第2のユーザに差額リソースを送信することを、前記第1のユーザに行わせるために、差額補償プロセスをトリガするステップであり、
前記差額リソースの量と前記標準のリソース量の比率が、第2の比率bとして定義され、0<b≦1-aである、ステップと
を含む方法。

【請求項2】

差額補償プロセスをトリガするステップが、
前記第1のユーザに通知を送信するステップ、および/または
自動的に、前記第1のユーザに対応するユーザリソースプールから前記差額リソースを差し引き、前記第2のユーザに前記差額リソースを送信するステップ
を含む、請求項1に記載の方法。

【請求項3】

前記第1のユーザが、前記指定された最終期限までに前記第2のユーザに前記差額リソースを送信することができないとき、前記第1のユーザに対して信用破綻プロセスを開始するステップ
をさらに含む、請求項1に記載の方法。

【請求項4】

前記第1のユーザに対して信用破綻プロセスを開始する前記ステップが、
前記第1のユーザの前記信用値を下げるステップ、前記第1のユーザのサービスへの参加を制限するステップ、および信用ブラックリストに前記第1のユーザを追加するステップ
のうちの少なくとも1つを含む、請求項3に記載の方法。

【請求項5】

前記第1のユーザが、その信用値が前記あらかじめ決定された値に達する、少なくとも1人の関連ユーザを有し、前記第1のユーザおよび関連ユーザの各々が、前記あらかじめ決定された時間期間内に前記第2のユーザに前記あらかじめ決定されたリソース量以上を送信すると前記確約するとき、
前記第1の比率aの値を減少させるステップ
をさらに含む、請求項1に記載の方法。

【請求項6】

前記あらかじめ決定された時間期間内に、前記第1のユーザによって前記第2のユーザに送信される実際のリソース量が、前記あらかじめ決定された量以上であるが、前記あらかじめ決定された時間期間内に、前記少なくとも1人の関連ユーザによって前記第2のユーザに送信される実際のリソース量が、前記あらかじめ決定された量未満であるとき、
前記指定された最終期限までに前記第2のユーザに調整リソースを送信することを、前記第1のユーザに行わせるために、調整補償プロセスをトリガするステップであって、
前記調整リソースの量と前記標準のリソース量の比率が、第3の比率cとして定義され、前記第3の比率cの値が、前記第1の比率aの前記減少された値に等しい、ステップ
をさらに含む、請求項5に記載の方法。

【請求項7】

前記第1のユーザが、その信用値が前記あらかじめ決定された値に達する、少なくとも1人の関連ユーザを有し、前記あらかじめ決定された時間期間内に、前記第1のユーザおよび関連ユーザの各々によって前記第2のユーザに送信される実際のリソース量が、前記あらかじめ決定された量以上であるとき、
前記第1のユーザに返金リソースを送信することを、前記第2のユーザに行わせるために、返金プロセスをトリガするステップであって、
前記返金リソースの量と前記標準のリソース量の比率が、第4の比率dとして定義され、0<d<aである、ステップ
をさらに含む、請求項1に記載の方法。

【請求項8】

サービスを処理するためのコンピュータにより実施される方法であって、
ユーザ端末から送信される情報を受信するステップであり、
前記情報が、前記ユーザ端末に対応する第1のユーザが少なくとも1人の関連ユーザを有し、前記第1のユーザおよび関連ユーザの各々の信用値があらかじめ決定された値に達するとき、前記第1のユーザおよび関連ユーザが、あらかじめ決定された時間期間内に第2のユーザにあらかじめ決定されたリソース量以上の総リソース量を送信すると確約する場合、前記第1のユーザによって送信されるリソース量と、前記第2のユーザによって前記第1のユーザに提供されるサービスオブジェクトに対応する標準のリソース量の比率が、第1の比率aとして定義され、0<a<1であることを備える、ステップと、
前記あらかじめ決定された時間期間内に、前記第1のユーザおよび関連ユーザによって前記第2のユーザに送信される実際の総リソース量が、前記あらかじめ決定された量未満であるとき、指定された最終期限までに前記第2のユーザに差額リソースを送信することを、前記第1のユーザに行わせるために、差額補償プロセスをトリガするステップであり、
前記差額リソースの量と前記標準のリソース量の比率が、第2の比率bとして定義され、0<b≦1-aである、ステップと
を含む方法。

【請求項9】

前記第1のユーザが、前記指定された最終期限までに前記第2のユーザに前記差額リソースを送信することができないとき、前記第1のユーザに対して信用破綻プロセスを開始するステップ、または
前記第1のユーザが、前記指定された最終期限までに前記第2のユーザに前記差額リソースを送信することができないとき、前記第1のユーザおよび関連ユーザに対して信用破綻プロセスを開始するステップ
をさらに含む、請求項8に記載の方法。

【請求項10】

サービスを処理するための装置であって、
ユーザ端末から送信される情報を受信するように構成された受信ユニットであり、
前記情報が、前記ユーザ端末に対応する第1のユーザの信用値があらかじめ決定された値に達するとき、前記第1のユーザが、あらかじめ決定された時間期間内に第2のユーザにあらかじめ決定されたリソース量以上を送信すると確約する場合、前記第1のユーザによって送信されるリソース量と、前記第2のユーザによって前記第1のユーザに提供されるサービスオブジェクトに対応する標準のリソース量の比率が、第1の比率aとして定義され、0<a<1であることを備える、受信ユニットと、
前記あらかじめ決定された時間期間内に、前記第1のユーザによって前記第2のユーザに送信される実際のリソース量が、前記あらかじめ決定された量未満であるとき、指定された最終期限までに前記第2のユーザに差額リソースを送信することを、前記第1のユーザに行わせるために、差額補償プロセスをトリガするように構成された、第1のトリガリングユニットであり、
前記差額リソースの量と前記標準のリソース量の比率が、第2の比率bとして定義され、0<b≦1-aである、第1のトリガリングユニットと
を備える装置。

【請求項11】

前記第1のトリガリングユニットが、
前記第1のユーザに通知を送信すること、および/または
自動的に、前記第1のユーザに対応するユーザリソースプールから前記差額リソースを差し引き、前記第2のユーザに前記差額リソースを送信すること
を行うように特に構成される、請求項10に記載の装置。

【請求項12】

前記第1のユーザが、前記指定された最終期限までに前記第2のユーザに前記差額リソースを送信することができないとき、前記第1のユーザに対して信用破綻プロセスを開始するように構成された、処理ユニット
をさらに備える、請求項10に記載の装置。

【請求項13】

前記処理ユニットが、
前記第1のユーザの前記信用値を下げること、前記第1のユーザのサービスへの参加を制限すること、および信用ブラックリストに前記第1のユーザを追加すること
のうちの少なくとも1つを実施するように構成される、請求項12に記載の装置。

【請求項14】

前記第1のユーザが、その信用値が前記あらかじめ決定された値に達する、少なくとも1人の関連ユーザを有し、前記第1のユーザおよび関連ユーザの各々が、前記あらかじめ決定された時間期間内に前記あらかじめ決定された量以上であるリソース量を前記第2のユーザに送信すると前記確約するとき、前記第1の比率aの値を減少させるように構成された、調整ユニット
をさらに備える、請求項10に記載の装置。

【請求項15】

前記あらかじめ決定された時間期間内に、前記第1のユーザによって前記第2のユーザに送信される実際のリソース量が、前記あらかじめ決定された量以上であるが、前記あらかじめ決定された時間期間内に、前記少なくとも1人の関連ユーザによって前記第2のユーザに送信される実際のリソース量が、前記あらかじめ決定された量未満であるとき、
前記指定された最終期限までに前記第2のユーザに調整リソースを送信することを、前記第1のユーザに行わせるために、調整補償プロセスをトリガするように構成された、第2のトリガリングユニットであって、
前記調整リソースの量、対、前記標準のリソース量が、第3の比率cとして定義され、前記第3の比率cの値が、前記第1の比率aの前記減少された値に等しい、第2のトリガリングユニット
をさらに備える、請求項14に記載の装置。

【請求項16】

前記第1のユーザが、その信用値が前記あらかじめ決定された値に達する、少なくとも1人の関連ユーザを有し、前記あらかじめ決定された時間期間内に、前記第1のユーザおよび関連ユーザの各々によって前記第2のユーザに送信される実際のリソース量が、前記あらかじめ決定された量以上であるとき、
前記第1のユーザに返金リソースを送信することを、前記第2のユーザに行わせるために、返金プロセスをトリガするように構成された、第3のトリガリングユニットであって、
前記返金リソースの量、対、前記標準のリソース量が、第4の比率dとして定義され、ただし、0<d<aである、第3のトリガリングユニット
をさらに備える、請求項10に記載の装置。

【請求項17】

サービスを処理するための装置であって、
ユーザ端末から送信される情報を受信するように構成された受信ユニットであり、
前記情報が、前記ユーザ端末に対応する第1のユーザが少なくとも1人の関連ユーザを有し、前記第1のユーザおよび関連ユーザの各々の信用値があらかじめ決定された値に達するとき、前記第1のユーザおよび関連ユーザが、あらかじめ決定された時間期間内に第2のユーザにあらかじめ決定されたリソース量以上の総リソース量を送信すると確約する場合、前記第1のユーザによって送信されるリソース量と、前記第2のユーザによって前記第1のユーザに提供されるサービスオブジェクトに対応する標準のリソース量の比率が、第1の比率aとして定義され、0<a<1であることを備える、受信ユニットと、
前記あらかじめ決定された時間期間内に、前記第1のユーザおよび関連ユーザによって前記第2のユーザに送信される実際の総リソース量が、前記あらかじめ決定された量未満であるとき、指定された最終期限までに前記第2のユーザに差額リソースを送信することを、前記第1のユーザに行わせるために、差額補償プロセスをトリガするように構成された、トリガリングユニットであり、
前記差額リソースの量と前記標準のリソース量の比率が、第2の比率bとして定義され、0<b≦1-aである、トリガリングユニットと
を備える装置。

【請求項18】

前記第1のユーザが、前記指定された最終期限までに前記第2のユーザに前記差額リソースを送信することができないとき、前記第1のユーザに対して信用破綻プロセスを開始するように構成された、第1の処理ユニット、または
前記第1のユーザが、前記指定された最終期限までに前記第2のユーザに前記差額リソースを送信することができないとき、前記第1のユーザおよび関連ユーザに対して信用破綻プロセスを開始するように構成された、第2の処理ユニット
をさらに備える、請求項17に記載の装置。

【請求項19】

電子デバイスであって、
プロセッサと、
プロセッサ実行可能命令を記憶するための記憶デバイスと
を備え、
前記プロセッサが、請求項1から7のいずれか一項において定義された方法を実施するために、前記プロセッサ実行可能命令を実行するように構成される、電子デバイス。

【請求項20】

電子デバイスであって、
プロセッサと、
プロセッサ実行可能命令を記憶するための記憶デバイスと
を備え、
前記プロセッサが、請求項8から9のいずれか一項において定義された方法を実施するために、前記プロセッサ実行可能命令を実行するように構成される、電子デバイス。

【発明の詳細な説明】

【技術分野】

【0001】

本明細書で説明する1つまたは複数の実施形態は、サービス処理の分野に関し、詳細には、サービスを処理するための方法、装置、および電子デバイスに関する。

【背景技術】

【0002】

関連技術では、様々なサービス対話シナリオが関連することが多い。一例として、ネットワークデータ共有シナリオでは、異なるユーザが、互いに自分自身のネットワークデータを共有することができる。たとえば、第1のユーザは、ネットワークデータが共有のために利用可能になるための標準のリソース量を設定し得る。それによって、いかなる他のユーザも、第1のユーザから対応するネットワークデータを取得するために、標準のリソース量に対応する量のネットワークデータを共有しなければならない。このようにして、長期の持続可能な共有をユーザ間で維持することができ、データ共有アクティビティの増加に役立つ。

【発明の概要】

【課題を解決するための手段】

【0003】

この点に鑑みて、本明細書で説明する1つまたは複数の実施形態は、サービスを処理するための方法、装置、および電子デバイスを提供する。

【0004】

この目的で、1つまたは複数の実施形態の主題について、以下のような具体性とともに本明細書で説明する。

【0005】

本明細書で説明する1つまたは複数の実施形態の第1の態様によれば、本明細書は、サービスを処理するための方法を提供し、方法は、

【0006】

ユーザ端末から送信される情報を受信するステップであって、情報が、ユーザ端末に対応する第1のユーザの信用値があらかじめ決定された値に達するとき、第1のユーザが、あらかじめ決定された時間期間内に第2のユーザにあらかじめ決定されたリソース量以上を送信すると確約する場合、第1のユーザによって送信されるリソース量と、第2のユーザによって第1のユーザに提供されるサービスオブジェクトに対応する標準のリソース量の比率が、第1の比率aとして定義され、ただし、0<a<1であることを備える、ステップと、

【0007】

あらかじめ決定された時間期間内に、第1のユーザによって第2のユーザに送信される実際のリソース量が、あらかじめ決定された量未満である場合、指定された最終期限までに第2のユーザに差額リソースを送信することを、第1のユーザに行わせるために、差額補償プロセスをトリガするステップであって、ここにおいて、差額リソースの量と標準のリソース量の比率が、第2の比率bとして定義され、ただし、0<b≦1-aである、ステップとを含む。

【0008】

本明細書で説明する1つまたは複数の実施形態の第2の態様によれば、本明細書は、サービスを処理するための方法を提供し、方法は、

【0009】

ユーザ端末から送信される情報を受信するステップであって、情報が、ユーザ端末に対応する第1のユーザが少なくとも1人の関連ユーザを有し、第1のユーザおよび関連ユーザの各々の信用値があらかじめ決定された値に達するとき、第1のユーザおよび関連ユーザが、あらかじめ決定された時間期間内に第2のユーザにあらかじめ決定された総リソース量以上を送信すると確約する場合、第1のユーザによって送信されるリソース量と、第2のユーザによって第1のユーザに提供されるサービスオブジェクトに対応する標準のリソース量の比率が、第1の比率aとして定義され、ただし、0<a<1であることを備える、ステップと、

【0010】

あらかじめ決定された時間期間内に、第1のユーザおよび関連ユーザによって第2のユーザに配信される実際の総リソース量が、あらかじめ決定された量未満である場合、指定された最終期限までに第2のユーザに差額リソースを送信することを、第1のユーザに行わせるために、差額補償プロセスをトリガするステップであって、ここにおいて、差額リソースの量と標準のリソース量の比率が、第2の比率bとして定義され、ただし、0<b≦1-aである、ステップとを含む。

【0011】

本明細書で説明する1つまたは複数の実施形態の第3の態様によれば、本明細書は、サービスを処理するための装置を提供し、装置は、

【0012】

ユーザ端末から送信される情報を受信するための受信ユニットであって、情報が、ユーザ端末に対応する第1のユーザの信用値があらかじめ決定された値に達するとき、第1のユーザが、あらかじめ決定された時間期間内に第2のユーザにあらかじめ決定されたリソース量以上を送信すると確約する場合、第1のユーザによって送信されるリソース量と、第2のユーザによって第1のユーザに提供されるサービスオブジェクトに対応する標準のリソース量の比率が、第1の比率aとして定義され、ただし、0<a<1であることを備える、受信ユニットと、

【0013】

あらかじめ決定された時間期間内に、第1のユーザによって第2のユーザに送信される実際のリソース量が、あらかじめ決定された量未満である場合、指定された最終期限までに第2のユーザに差額リソースを送信することを、第1のユーザに行わせるために、差額補償プロセスをトリガするための、第1のトリガリングユニットであって、ここにおいて、差額リソースの量と標準のリソース量の比率が、第2の比率bとして定義され、ただし、0<b≦1-aである、第1のトリガリングユニットとを含む。

【0014】

本明細書で説明する1つまたは複数の実施形態の第4の態様によれば、本明細書は、サービスを処理するための装置を提供し、装置は、

【0015】

ユーザ端末から送信される情報を受信するための受信ユニットであって、情報が、ユーザ端末に対応する第1のユーザが少なくとも1人の関連ユーザを有し、第1のユーザおよび関連ユーザの各々の信用値があらかじめ決定された値に達するとき、第1のユーザおよび関連ユーザが、あらかじめ決定された時間期間内に第2のユーザにあらかじめ決定された総リソース量以上を送信すると確約する場合、第1のユーザによって送信されるリソース量と、第2のユーザによって第1のユーザに提供されるサービスオブジェクトに対応する標準のリソース量の比率が、第1の比率aとして定義され、ただし、0<a<1であることを備える、受信ユニットと、

【0016】

あらかじめ決定された時間期間内に、第1のユーザおよび関連ユーザによって第2のユーザに送信される実際の総リソース量が、あらかじめ決定された量未満である場合、指定された最終期限までに第2のユーザに差額リソースを送信することを、第1のユーザに行わせるために、差額補償プロセスをトリガするための、トリガリングユニットであって、ここにおいて、差額リソースの量と標準のリソース量の比率が、第2の比率bとして定義され、ただし、0<b≦1-aである、トリガリングユニットとを含む。

【0017】

本明細書で説明する1つまたは複数の実施形態の第5の態様によれば、本明細書は電子デバイスを提供し、電子デバイスは、

【0018】

プロセッサと、

【0019】

プロセッサ実行可能命令を記憶するための記憶デバイスとを含み、

【0020】

ここにおいて、プロセッサが、上記の第1の態様による方法を実施するために、実行可能命令を実行するように構成される。

【0021】

本明細書で説明する1つまたは複数の実施形態の第6の態様によれば、本明細書は電子デバイスを提供し、電子デバイスは、

【0022】

プロセッサと、

【0023】

プロセッサ実行可能命令を記憶するための記憶デバイスとを含み、

【0024】

ここにおいて、プロセッサが、上記の第2の態様による方法を実施するために、実行可能命令を実行するように構成される。

【図面の簡単な説明】

【0025】

【図1】例示的な実施形態による、サービスを処理するための方法の流れ図である。

【図2】例示的な実施形態による、サービスを処理するための別の方法の流れ図である。

【図3】例示的な実施形態による、サービスを処理するためのシステムの構造を示す概略図である。

【図4】例示的な実施形態による、取引シナリオにおけるサービス対話を示す概略図である。

【図5】例示的な実施形態による、別の取引シナリオにおけるサービス対話を示す概略図である。

【図6】例示的な実施形態による、さらなる取引シナリオにおけるサービス対話を示す概略図である。

【図7】例示的な実施形態による、割引アクティビティを作成する概略図である。

【図8】例示的な実施形態による、作成された割引アクティビティの概略図である。

【図9】例示的な実施形態による、買い手にアクティビティ内容を示す概略図である。

【図10】例示的な実施形態による、差分を返金するように買い手に通知する概略図である。

【図11】例示的な実施形態による、返金詳細説明インターフェースを示す概略図である。

【図12】例示的な実施形態による装置の構造を示す概略図である。

【図13】例示的な実施形態による、サービスを処理するためのデバイスのブロック図である。

【図14】例示的な実施形態による別の装置の構造を示す概略図である。

【図15】例示的な実施形態による、サービスを処理するための別のデバイスのブロック図である。

【発明を実施するための形態】

【0026】

次に、例示的な実施形態を詳細に参照し、その例が添付の図面に示されている。図面が以下で参照されるときは常に、同じ参照番号は、別段に規定されていない限り、図面の全体にわたって同じまたは類似の要素を指すために使用されるようになる。以下の例示的な実施形態において記載される実装形態は、本明細書で説明する1つまたは複数の実施形態に一致するすべての実装形態を表さない。それよりも、それらの実装形態は、添付の特許請求の範囲において詳述するような、説明する1つまたは複数の実施形態のいくつかの態様に一致する装置および方法の例にすぎない。

【0027】

他の実施形態では、方法ステップは、必ずしも図示および本明細書で説明するものと同じ順序で実行されるとは限らないことがあることに留意されたい。いくつかの他の実施形態では、本明細書で説明するよりも多いまたは少ない方法ステップが含まれることがある。加えて、本明細書で説明する単一のステップを、他の実施形態では、複数の分割されたステップとして説明することがあり、本明細書で説明する複数のステップを、他の実施形態では、単一の組み合わせられたステップとして説明することがある。

【0028】

図1は、例示的な実施形態による、サービスを処理するための方法の流れ図である。図1に示されるように、方法は、サービスプラットフォーム上で実施可能であり、以下で詳述するようなステップを含み得る。

【0029】

ステップ102で、ユーザ端末から送信される情報を受信すること。情報は、ユーザ端末に対応する第1のユーザの信用値があらかじめ決定された値に達するとき、第1のユーザが、あらかじめ決定された時間期間内に第2のユーザにあらかじめ決定されたリソース量以上を送信すると確約する場合、第1のユーザによって送信されるリソース量と標準のリソース量の比率が、第1の比率aとして定義され、ただし、0<a<1であることを備える。標準のリソース量は、第2のユーザによって第1のユーザに提供されるサービスオブジェクトに対応する。

【0030】

一実施形態では、サービスプラットフォームおよび第2のユーザは、事前に互いに交渉し、あらかじめ決定された時間期間の開始時間および終了時間、あらかじめ決定された時間期間の持続時間、あらかじめ決定された量の値、第1の比率aの値、第2の比率bの値など、サービスルールに関する契約を結び得る。第1のユーザは、これらのサービスルールを再検討し、これらのサービスルールについて同意するとき、上記の情報の形成を許可し、サービスプラットフォームに形成を送信し、それによって以下の確約をし得る。確約は、あらかじめ決定された時間期間内に、第1のユーザが、第2のユーザにあらかじめ決定されたリソース量以上を支払うようにし、同じあらかじめ決定された時間期間内に、第1のユーザが、サービスオブジェクトに対応する標準のリソース量を支払うのではなく、第1の比率aに基づいて、第2のユーザから対応するサービスオブジェクトを得ることができるようにすることを含み得る。

【0031】

一実施形態では、上記の確約が履行されることを保証するため、または履行の確率を高めるために、サービスプラットフォームは、第1のユーザの信用状態を検証し得る。第1のユーザの信用値が、あらかじめ決定された値に達する(たとえば、それ以上である)場合、第1のユーザが高い信用を有し、第1のユーザの確約が受け入れられ、第1のユーザが、あらかじめ決定された時間期間内に第1の比率aにおいて、第2のユーザからサービスオブジェクトを取得する資格があるようになることを示す。第1のユーザの信用値が、あらかじめ決定された値に達しない場合、第1のユーザが低い信用を有し、第1のユーザの確約が受け入れられず、第1のユーザが、標準のリソース量で第2のユーザのサービスオブジェクトを取得しなければならないようになり得ることを示す。信用値は、限定はしないが、スコア、番号、格付けなどの形式であり得る。

【0032】

一実施形態では、第1のユーザの信用値は、サービスプラットフォーム自体から取り出され得る。すなわち、サービスプラットフォームは、ユーザ信用査定能力を有し得る。代替的に、信用値は、信用管理プラットフォームから取り出され得る。すなわち、サービスプラットフォームは、信用管理プラットフォームから信用値を取り出し得る。

【0033】

一実施形態によれば、ネットワークデータ共有シナリオでは、サービスプラットフォームは共有管理プラットフォームであり得、第1のユーザは、あらかじめ決定された時間期間内にあらかじめ決定された量以上のネットワークデータ(すなわち、第1のユーザによって第2のユーザに送信されることになるリソース)を第2のユーザと共有すると確約し、第1のユーザの信用状態が要件を満たすとき、第1の比率aにおいて、第2のユーザから対応するネットワークデータ(すなわち、第2のユーザによって共有のために提供されるネットワークデータ)が取得され得るようにするために、共有管理プラットフォームに情報を送信し得る。たとえば、1GBのネットワークデータを有する第2のユーザの場合、等価交換の原理に基づいて、対応する標準のリソース量が1GBに設定される。一般的な場合、第1のユーザは、第2のユーザの同量のネットワークデータを得る前に、第2のユーザと1GBのネットワークデータを共有しなければならないようになる。しかしながら、第1のユーザが、10日(すなわち、あらかじめ決定された時間期間)以内に第2のユーザと20GB以上(すなわち、あらかじめ決定された量)のネットワークデータを共有すると確約する場合、第1のユーザが第2のユーザと長期のデータ共有を維持する意思があることを示す。次いで、第1のユーザは、その時間期間内に1GBを取得するために0.8GBを共有する(すなわち、第1の比率a=80%)という優先的共有方式を用いて、第2のユーザのネットワークデータを取得する資格があるようになる。この優先的共有方式は、第1のユーザが、アップリンクおよびダウンリンク帯域幅など、自分の限られたネットワークリソースのより多くを、第2のユーザのネットワークデータの取得に割り振ることを可能にし、したがって、第1のユーザのデータ共有アクティビティを促す点で有利である。この確約ベースの優先的共有方式の幅広い適用によって、ネットワーク環境内のネットワークデータの有効な共有が可能になる。

【0034】

一実施形態によれば、買い物シナリオでは、サービスプラットフォームは取引プラットフォームであり得、買い手ユーザは、あらかじめ決定された時間期間内にあらかじめ決定された金額以上の売り手ユーザにおける消費(すなわち、買い手ユーザによって売り手ユーザに送信されることになるリソース)を確約し、買い手ユーザの信用状態が要件を満たすとき、買い手ユーザが、第1の比率aにおいて、売り手ユーザから製品(すなわち、売り手ユーザによって提供されるサービスオブジェクト)を購入することができるようにするために、取引プラットフォームに情報を送信することができる。たとえば、1,000元の表示価格を有する売り手ユーザの製品Hのために、すなわち、その製品を購入するために、買い手ユーザは、一般に売り手ユーザに1,000元を支払う必要がある。しかしながら、買い手ユーザが、30日(すなわち、あらかじめ決定された時間期間)以内に3,000元(すなわち、あらかじめ決定された金額)以上の消費額を売り手ユーザに確約する場合、買い手ユーザが売り手ユーザからの長期消費を確約する意思があることを示し、買い手ユーザは、30日以内に(第1の比率a=80%に相当する)20%割引を取得するようになる。たとえば、買い手ユーザは、上述の製品Hを800元で購入することができる。一方では、買い手ユーザは、売り手ユーザのところで事前に消費者カードにリチャージする必要がなく、破産または他の理由による買い手ユーザの財産損失のリスクが回避され、他方では、売り手ユーザは、上記の確約に基づいて、事前に消費額を確定することができる。したがって、買い手と売り手の両方の相互利益になる。

【0035】

一実施形態では、あらかじめ決定された時間期間は、あらかじめ決定された開始時間および終了時間によって定義された、固定された期間であり得る。たとえば、開始時間は2018年6月10日であり得、終了時間は2018年7月9日であり得、次いで、あらかじめ決定された時間期間は、2018年6月10日から2018年7月9日までである。

【0036】

別の実施形態では、あらかじめ決定された時間期間は、固定された開始時間または終了時間を有するのではなく、あらかじめ決定された持続時間、たとえば、1か月であり得る。たとえば、第1のユーザが、2018年6月10日にサービスプラットフォームに情報を送信する場合、あらかじめ決定された時間期間は、その日から1か月の間続くことになる。別の例として、第1のユーザが、2018年7月12日にサービスプラットフォームに情報を送信する場合、あらかじめ決定された時間期間は、2018年7月12日から1か月の間続くことになる。

【0037】

一実施形態では、リソースおよびサービスオブジェクトのタイプは、サービスシナリオによって異なり得る。たとえば、ネットワークデータ共有シナリオでは、リソースは、第1のユーザによって所有されたネットワークデータであり得、サービスオブジェクトは、第2のユーザによって所有されたネットワークデータであり得る。第1のユーザは、本明細書の技術的解決策に基づいて、第1の比率aの優先的共有方式を取得することができ、第1のユーザが、第2のユーザのネットワークデータを取得するために、より多くのネットワークリソースを割り振ることができるようになる。第1のユーザが、確約を遵守することができないとき、第2のユーザは、第2の比率bによるネットワークデータ補償を取得することができる(たとえば、第2のユーザは、後で、他のユーザと共有されたネットワークデータの量を低減し得る)。別の例として、取引シナリオでは、リソースは資金であり得、第1のユーザは買い手であり得、サービスオブジェクトは製品であり得、第2のユーザは売り手であり得る。買い手は、本明細書の技術的解決策に基づいて、製品のために第1の比率aの割引を取得し得、売り手は、買い手が確約を遵守することができないとき、第2の比率bの補償を受けることができる。

【0038】

一実施形態では、サービスプラットフォームは、第1のユーザおよび第2のユーザがオンラインで互いに対話することを可能にし得る。たとえば、サービスプラットフォームによって提供された対話型ウェブページ上で、第1のユーザは、サービスオブジェクトの紹介情報をブラウズし、サービスオブジェクトのための注文を提出し得る。第1のユーザが、情報を通して対応する確約をし、第1のユーザの信用値が要件を満たすとき、サービスプラットフォームは、サービスオブジェクトに対応する標準のリソース量および第1の比率aに基づいて、第1のユーザによって送信されることになるリソース量を計算し、次いで、注文の処理を推進し得る。

【0039】

一実施形態では、第1のユーザおよび第2のユーザは、オフラインで互いに対話し得る。たとえば、第1のユーザから情報を受信すると、サービスプラットフォームは、第1のユーザの信用値が要件を満たす場合、第1のユーザにクレデンシャルを提供し得、第1のユーザは、第2のユーザにクレデンシャルを提示することによって、第2のユーザから優先的な第1の比率aを取得することができる。別の例として、第2のユーザにクレデンシャルを示すのではなく、第1のユーザは、サービスプラットフォームを介して、単に対応するリソース量を第2のユーザに送信することができ、次いで、サービスプラットフォームは、第1のユーザによってすでに送信された情報に基づいて、第1の比率aに一致するように、第1のユーザによって送信される必要があるリソース量を自動的に構成する。

【0040】

ステップ104で、あらかじめ決定された時間期間内に、第1のユーザによって第2のユーザに実際に送信されるリソース量が、あらかじめ決定された量未満であるとき、指定された最終期限までに第2のユーザに差額リソースを送信することを、第1のユーザに行わせるために、差額補償プロセスがトリガされ得、ここにおいて、差額リソースの量と標準のリソース量の比率が、第2の比率bとして定義され、ただし、0<b≦1-aである。

【0041】

一実施形態では、第1のユーザは、サービスプラットフォームに情報を送信することを介して確約し、第1のユーザが、優先的な第1の比率aを取得するために、第2のユーザのところであらかじめ決定されたリソース量を事前に蓄積する必要がないようにし、いずれかの予期せぬ出来事による、第2のユーザが事前に蓄積されたリソースを返すことができなくなるリスクを回避し得る。第2のユーザは、あらかじめ決定されたリソース量が取得され得ることを保証するために、第1のユーザの事前に対話する意思を固定することができる。第1のユーザが、確約を遵守することができない場合でも、第2のユーザは、依然として、サービスプラットフォームから第2の比率bにおいて差額リソースを取得するようになる。このようにして、第1のユーザによって行われた確約は、サービスプラットフォームによって承認およびサポートされ得、それによって確約の信用性が向上する。

【0042】

一実施形態では、指定された最終期限は、あらかじめ決定された時間期間の終了後に開始する時間期間であり得、開始時間、終了時間、持続時間などが、サービスプラットフォームによって設定され得る。たとえば、あらかじめ決定された時間期間の終了時間は、あらかじめ決定された最終期限の開始時間として設定され得、別のあらかじめ決定された時間期間は、あらかじめ決定された最終期限の持続時間として設定され得る。別の例では、あらかじめ決定された時間期間の終了時間は、あらかじめ決定された最終期限の開始時間として設定され得、現在の月の最終日の午後24:00が、あらかじめ決定された最終期限の終了時間として設定され得る。本明細書は、本明細書で説明する1つまたは複数の実施形態に限定されない。

【0043】

一実施形態では、サービスプラットフォームは、第1のユーザに通知を送信し、指定された最終期限までに第2のユーザに差額リソースを送信するように、第1のユーザに通知し得る。サービスプラットフォームは、たとえば、あらかじめ決定された時間期間の終了直後、最終期限の中間点において、最終期限の終了前のある時間において、最終期限の間の各自然日の固定された時間においてなどを含む時間において、1つまたは複数のそのような通知を送信し得る。本明細書は、本明細書で説明する1つまたは複数の実施形態に限定されない。

【0044】

一実施形態では、サービスプラットフォームは、自動的に、第1のユーザに対応するユーザリソースプールから差額リソースを差し引き、第2のユーザに送信し得る。たとえば、ネットワークデータ共有シナリオでは、ユーザリソースプールは、第1のユーザによって保持されたすべてのネットワークデータであり得、共有管理プラットフォームは、第1のユーザに対するペナルティとして、ダウンロードの順序またはデフォルトの順序に従って、ネットワークデータの一部を削除し得る。取引シナリオでは、ユーザリソースプールは、第1のユーザの口座であり得る。サービスプラットフォームが口座から差し引くことを許可されている(第1のユーザが、そうするように行った確約によって、サービスプラットフォームを許可し得るか、または控除機関を取得することさえもが、サービスプラットフォームが確約を認めるための必須条件である)場合、サービスプラットフォームは、差額リソースに対応する金額を直接差し引き、第2のユーザの口座に差し引き額を送金することができる。

【0045】

いくつかの実施形態では、最初に、サービスプラットフォームは、第1のユーザに通知を送信し、最終期限までに第2のユーザに差額リソースを送信するように、第1のユーザに通知し得る。次いで、第1のユーザがそうすることができない場合、サービスプラットフォームは、自動的に、第1のユーザに対応するユーザリソースプールから差額リソースを差し引き、第2のユーザに送信し得る。

【0046】

一実施形態では、第1のユーザが、最終期限までに第2のユーザに差額リソースを送信することができない場合、サービスプラットフォームは、たとえば、第1のユーザの信用値を下げることを含み得る、信用破綻プロセスをトリガし得る。第1のユーザの信用値が、サービスプラットフォームによって維持される場合、サービスプラットフォームは、自動的に信用値を下げ得る。さもなければ、信用値が信用管理プラットフォームによって管理される場合、サービスプラットフォームは、信用管理プラットフォームにフィードバックを提供し、信用値を下げるように、信用管理プラットフォームに要求し得る。別の例として、信用破綻プロセスは、第1のユーザが、もはや本明細書で説明する解決策から利益を得ることができないように、およびいかなるサービスオブジェクトも、標準のリソース量を支払うという代償を払って取得しなければならないように、第1のユーザのサービスへの参加を制限することを含み得る。さらに別の例として、信用破綻プロセスは、第1のユーザを信用ブラックリストに追加すること、およびこの情報を他のプラットフォームと共有することを含み、第1のユーザへの将来の悪影響を引き起こし得る。限定はしないが、信用破綻プロセスはまた、他の対策、または複数の対策の組合せを含み得る。

【0047】

一実施形態では、第1のユーザが、その信用値があらかじめ決定された値に達する、少なくとも1人の関連ユーザを有するとき、第1のユーザおよび関連ユーザの各々が、あらかじめ決定された時間期間内にあらかじめ決定されたリソース量以上を第2のユーザに送信すると確約する場合、第1のユーザが、第2のユーザによるサービスに参加するように関連ユーザを勧誘することに相当し、したがって、サービスの規模が拡大する。それに応答して、サービスプラットフォームは、第1のユーザへのインセンティブとして、第1のユーザおよび関連ユーザの各々が、より少ないリソース量を支払うことができるように、第1の比率aの値を減少させ得る。1人または複数のそのような関連ユーザが存在し得、そのような関連ユーザの各々は、あらかじめ決定された時間期間内にあらかじめ決定されたリソース量以上を第2のユーザに送信すると確約するべきである。

【0048】

第1のユーザおよび関連ユーザの各々が、あらかじめ決定された時間期間内にあらかじめ決定された量未満である実際のリソース量を送信しているとき、第2のユーザに差額リソースを送信することを、第1のユーザに行わせるために、ステップ104におけるプロセスがトリガされ得る。一実施形態では、「第1のユーザ」および「関連ユーザ」は、役割タイプである。ユーザAおよびユーザBが、互いに関連して、第2のユーザによるサービスに参加するとき、ユーザAの観点からすれば、ユーザAが「第1のユーザ」として解釈され、ユーザBが「関連ユーザ」として解釈され得、ユーザBの観点からすれば、ユーザBが「第1のユーザ」として解釈され、ユーザAが「関連ユーザ」として解釈され得る。したがって、ステップ104で、第1のユーザによってのみ、第2のユーザに差額リソースを送信するとして説明したが、実際には、第2のユーザをあらゆる損失から保護するために、関連ユーザもまた、第2のユーザに差額リソースを送信することが必要とされ得る。別の実施形態では、「第1のユーザ」は、最初に第2のユーザによるサービスに参加し、次いで、同じくそのサービスに参加するように「関連ユーザ」を勧誘し得る。たとえば、ユーザAは、最初に第2のユーザによるサービスに参加し、次いで、同じくそのサービスに参加するように、ユーザBを勧誘し得る。この場合、ユーザAは常に「第1のユーザ」として識別され、ユーザBは「関連ユーザ」として識別されるようになる。したがって、ユーザAは、第2のユーザに差額リソースを送信することが必要とされ得るが、ユーザBは、第2のユーザに差額リソースを送信すること、またはいくつかの条件下で(たとえば、ユーザBが第2のユーザと取引することが初めてである場合)そうしないことのいずれかのように構成され得る。

【0049】

あらかじめ決定された時間期間内の場合、第1のユーザは、第2のユーザにあらかじめ決定された量以上を送信するが、第2のユーザに送信される少なくとも1人の関連ユーザの実際のリソース量は、あらかじめ決定された量未満である。言い換えれば、第1のユーザは確約を遵守しているが、関連ユーザはしていない。この場合、サービスプラットフォームは、第1のユーザが、指定されたあらかじめ決定された最終期限までに第2のユーザに調整リソース量を送信することになるように、調整補償プロセスをトリガし得る。調整リソース量は、第1の比率aの減少に等しい、標準のリソース量に対する第3の比率cにおけるものである。たとえば、aがデフォルトで80%に等しく、サービスへの第1のユーザおよび関連ユーザの共同参加により、a'=60%に減少される場合、cはその減少に等しく、すなわち、c=a-a'=80%-60%=20%である。言い換えれば、第1のユーザは、もはや減少された第1の比率a'の割引を享受することができないが、第1のユーザは、依然として、第2のユーザにすべての差額リソースを返金する必要なしに、第1の比率aの割引から利益を得ることができる。

【0050】

一実施形態では、その信用値があらかじめ決定された値に達する、第1のユーザに関連付けられた少なくとも1人のユーザが存在するとき、第1のユーザと関連ユーザの両方が第2のユーザに送信することになる初期リソース量は、第2のユーザのサービスオブジェクトに関連付けられた標準のリソース量に対する第1の比率aにおけるものであり得る。すなわち、第1の比率aは、まったく減少されない。その後、第1のユーザおよび関連ユーザの各々が、あらかじめ決定された時間期間内にあらかじめ決定された量以上である実際のリソース量を第2のユーザに送信する場合、サービスプラットフォームは、第2のユーザが、標準のリソース量に対する第4の比率dにおけるリソース量を、第1のユーザに返金することになるように、返金プロセスをトリガし得、ただし、0<d<aである。これは、第1のユーザおよび関連ユーザが彼らの確約を遵守することへのインセンティブとして、サービスのために第1のユーザおよび関連ユーザによって提供されるリソース量における低減に相当する(すなわち、実際に送信されるリソース量は、最初に送信された量から、第2のユーザからの返金を差し引いたものに等しい)。

【0051】

図2は、例示的な実施形態による、サービスを処理するための別の方法の流れ図である。図2に示されるように、方法は、サービスプラットフォーム上で使用され、以下で詳述するようなステップを含み得る。

【0052】

ステップ202で、ユーザ端末から送信される情報を受信すること。情報は、ユーザ端末に対応する第1のユーザが少なくとも1人の関連ユーザを有し、第1のユーザおよび関連ユーザの各々の信用値があらかじめ決定された値に達するとき、第1のユーザおよび関連ユーザが、あらかじめ決定された時間期間内に第2のユーザにあらかじめ決定されたリソース量以上の総リソース量を送信すると確約する場合、第1のユーザによって送信されるリソース量と、第2のユーザによって第1のユーザに提供されるサービスオブジェクトに対応する標準のリソース量の比率が、第1の比率aとして定義され、ただし、0<a<1であることを備える。

【0053】

一実施形態では、サービスプラットフォームおよび第2のユーザは、事前に互いに交渉し、あらかじめ決定された時間期間の開始時間および終了時間、あらかじめ決定された時間期間の持続時間、あらかじめ決定された量の値、第1の比率aの値、第2の比率bの値など、サービスルールに関する契約を結び得る。第1のユーザおよび関連ユーザは、これらのサービスルールを再検討し、これらのサービスルールについて同意するとき、上記の情報の形成を許可し、サービスプラットフォームに形成を送信し、それによって以下の確約をし得る。確約は、あらかじめ決定された時間期間内に、第1のユーザおよび関連ユーザが、第2のユーザにあらかじめ決定された総リソース量以上を送信するようにし、同じ時間期間内に、第1のユーザおよび関連ユーザが、サービスオブジェクトに対応する標準のリソース量を支払うのではなく、第1の比率aにおいて、第2のユーザから対応するサービスオブジェクトを得ることができるようにすることを含み得る。第1のユーザおよび関連ユーザは、第2のユーザによるサービスに同時に参加し得るか、または第1のユーザが最初に参加し、次いで、関連ユーザを勧誘する。本明細書は、本明細書で説明する1つまたは複数の実施形態に限定されない。

【0054】

一実施形態では、上記の確約が履行されることを保証するため、または履行の確率を高めるために、サービスプラットフォームは、第1のユーザおよび関連ユーザの信用状態を検証し得る。第1のユーザおよび関連ユーザの信用値が、両方ともあらかじめ決定された値に達する(たとえば、それ以上である)場合、第1のユーザおよび関連ユーザが高い信用を有し、彼らの確約が受け入れられ、第1のユーザおよび関連ユーザが、あらかじめ決定された時間期間内に第1の比率aにおいて、第2のユーザからサービスオブジェクトを取得する資格があるようになることを示す。第1のユーザおよび関連ユーザの信用値のいずれかが、あらかじめ決定された値に達しない場合、彼らが低い信用を有し、彼らの確約が受け入れられず、彼らが、標準のリソース量で第2のユーザのサービスオブジェクトを取得しなければならないようになり得ることを示し得る。信用値は、限定はしないが、スコア、番号、格付けなどの形式であり得る。

【0055】

一実施形態では、第1のユーザおよび関連ユーザの信用値は、サービスプラットフォーム自体から取り出され得る。すなわち、サービスプラットフォームは、ユーザ信用査定能力を有し得る。代替的に、信用値は、信用管理プラットフォームから取り出され得る。すなわち、サービスプラットフォームは、信用管理プラットフォームから、第1のユーザおよび関連ユーザの信用値を取り出し得る。

【0056】

一実施形態によれば、ネットワークデータ共有シナリオでは、サービスプラットフォームは共有管理プラットフォームであり得、第1のユーザおよび関連ユーザは、あらかじめ決定された時間期間内にあらかじめ決定された量以上のネットワークデータ(すなわち、第1のユーザおよび関連ユーザによって第2のユーザに送信されることになるリソース)を第2のユーザと共有すると確約し、第1のユーザおよび関連ユーザの信用状態が要件を満たすとき、彼らが、第1の比率aにおいて、第2のユーザから対応するネットワークデータ(すなわち、第2のユーザによって共有のために提供されるネットワークデータ)を取得することができるようにするために、共有管理プラットフォームに情報を送信し得る。たとえば、1GBのネットワークデータを有する第2のユーザの場合、等価交換の原理に基づいて、対応する標準のリソース量が1GBに設定され、一般的な場合、第1のユーザおよび関連ユーザは、第2のユーザの同量のネットワークデータを得ることができるようになる前に、第2のユーザと1GBのネットワークデータを共有しなければならないようになる。しかしながら、第1のユーザおよび関連ユーザが、10日(すなわち、あらかじめ決定された時間期間)以内に第2のユーザと20GB以上(すなわち、あらかじめ決定された量)のネットワークデータを共有すると確約し、第1のユーザおよび関連ユーザが第2のユーザと長期のデータ共有を維持する意思があることを示す場合、第1のユーザおよび関連ユーザは、その時間期間内に1GBを取得するために0.8GBを共有する(すなわち、第1の比率a=80%)という優先的共有方式を用いて、第2のユーザのネットワークデータを得る資格があるようになる。この優先的共有方式は、第1のユーザおよび関連ユーザが、彼らの限られたアップリンクおよびダウンリンク帯域幅または他のネットワークリソースのより多くを、第2のユーザのネットワークデータの取得に割り振ることを可能にし、したがって、第1のユーザおよび関連ユーザのデータ共有アクティビティを促す点で有利である。この確約ベースの優先的共有方式の幅広い適用によって、ネットワーク環境内のネットワークデータの有効な共有が可能になる。

【0057】

一実施形態によれば、買い物シナリオでは、サービスプラットフォームは取引プラットフォームであり得、買い手ユーザおよび関連する買い手ユーザは、あらかじめ決定された時間期間内にあらかじめ決定された金額以上の売り手ユーザにおける消費(すなわち、買い手ユーザおよび関連する買い手ユーザによって売り手ユーザに送信されることになるリソース)を確約し、買い手ユーザおよび関連する買い手ユーザの信用状態が両方とも要件を満たすとき、彼らが、第1の比率aにおいて、売り手ユーザから製品(すなわち、売り手ユーザによって提供されるサービスオブジェクト)を取得することができるようにするために、取引プラットフォームに情報を送信することができる。たとえば、1,000元の表示価格を有する売り手ユーザの製品Hのために、すなわち、その製品を得るために、買い手ユーザおよび関連する買い手ユーザは、売り手ユーザに1,000元を支払う必要がある。しかしながら、買い手ユーザおよび関連する買い手ユーザが、30日(すなわち、あらかじめ決定された時間期間)以内に3,000元(すなわち、あらかじめ決定された金額)以上の消費額を売り手ユーザに確約する場合、彼らが売り手ユーザからの長期消費を確約する意思があることを示し、彼らは、30日以内に20%割引(すなわち、第1の比率a=80%)を取得するようになる。たとえば、彼らは、上述の製品Hを800元で購入することができる。一方では、買い手ユーザおよび関連する買い手ユーザは、売り手ユーザのところで事前に消費者カードにリチャージする必要がなく、破産または他の理由による買い手ユーザおよび関連する買い手ユーザの財産損失のリスクが回避され、他方では、売り手ユーザは、上記の確約に基づいて、事前に消費額を確定することができる。したがって、買い手と売り手の両方の相互利益になる。

【0058】

一実施形態では、あらかじめ決定された時間期間は、あらかじめ決定された開始時間および終了時間によって定義された、固定された期間であり得る。たとえば、開始時間は2018年6月10日であり得、終了時間は2018年7月9日であり得る。この場合、あらかじめ決定された時間期間は、2018年6月10日から2018年7月9日までである。

【0059】

一実施形態では、あらかじめ決定された時間期間は、固定された開始時間または終了時間を有するのではなく、あらかじめ決定された持続時間、たとえば、1か月であり得る。たとえば、第1のユーザが、2018年6月10日にサービスプラットフォームに情報を送信する場合、あらかじめ決定された時間期間は、その日から1か月の間続くことになる。別の例として、第1のユーザが、2018年7月12日にサービスプラットフォームに情報を送信する場合、あらかじめ決定された時間期間は、2018年7月12日から1か月の間続くことになる。

【0060】

一実施形態では、リソースおよびサービスオブジェクトのタイプは、サービスシナリオによって異なり得る。たとえば、ネットワークデータ共有シナリオでは、リソースは、第1のユーザおよび関連ユーザによって所有されたネットワークデータであり得、サービスオブジェクトは、第2のユーザによって所有されたネットワークデータであり得る。第1のユーザおよび関連ユーザは、本明細書の技術的解決策に基づいて、第1の比率aの優先的共有方式を取得し、彼らが、第2のユーザのネットワークデータを取得するために、より多くのネットワークリソースを割り振ることができるようにし得る。第1のユーザおよび関連ユーザが、確約を遵守することができないとき、第2のユーザは、第2の比率bによるネットワークデータ補償を取得することができる(たとえば、第2のユーザは、後で、他のユーザと共有されたネットワークデータの量を低減し得る)。別の例として、取引シナリオでは、リソースは資金であり得、第1のユーザおよび関連ユーザは買い手であり得、サービスオブジェクトは製品であり得、第2のユーザは売り手であり得る。買い手は、本明細書の技術的解決策に基づいて、製品のために第1の比率aの割引を取得し得、売り手は、買い手が確約を遵守することができないとき、第2の比率bの補償を受けることができる。

【0061】

一実施形態では、サービスプラットフォームは、第1のユーザおよび関連ユーザがオンラインで第2のユーザと対話することを可能にし得る。たとえば、サービスプラットフォームによって提供された対話型ウェブページ上で、第1のユーザおよび関連ユーザは、サービスオブジェクトの紹介情報をブラウズし、サービスオブジェクトのための注文を提出し得る(第1のユーザが注文を提出し、関連ユーザによるその提出の確認が後続し得、代替的に、第1のユーザおよび関連ユーザが別個の注文を提出し得、次いで、サービスプラットフォームが、その2人のユーザ間の関連付けに基づいて、それらの注文を単一の注文に結合する)。第1のユーザおよび関連ユーザが、情報を通して対応する確約をし、第1のユーザおよび関連ユーザの信用値が要件を満たすとき、サービスプラットフォームは、サービスオブジェクトに対応する標準のリソース量および第1の比率aに基づいて、第1のユーザまたは関連ユーザによって送信されることになるリソース量を計算し、次いで、注文の処理を推進し得る。

【0062】

一実施形態では、第1のユーザおよび関連ユーザは、オフラインで第2のユーザと対話し得る。たとえば、情報を受信すると、サービスプラットフォームは、第1のユーザおよび関連ユーザの信用値が要件を満たす場合、第1のユーザおよび関連ユーザに別個のクレデンシャルを提供し得、第1のユーザおよび関連ユーザは、第2のユーザに彼らのクレデンシャルを提示することによって、第2のユーザから優先的な第1の比率aを取得することができる。別の例として、クレデンシャルを提示するのではなく、第1のユーザおよび関連ユーザは、サービスプラットフォームを介して、単に対応するリソース量を第2のユーザに送信することができ、次いで、サービスプラットフォームは、第1のユーザおよび関連ユーザによってすでに送信された情報に基づいて、第1の比率aに一致するように、第1のユーザおよび関連ユーザによって送信される必要があるリソース量を自動的に構成する。

【0063】

ステップ204で、あらかじめ決定された時間期間内に、第1のユーザおよび関連ユーザによって第2のユーザに実際に送信されるリソース量が、あらかじめ決定された量未満であるとき、第2の比率bとして定義される、標準のリソース量に対する差額リソースを送信することを、第1のユーザに行わせるために、差額補償プロセスがトリガされ得、ただし、0<b≦1-aである。

【0064】

一実施形態では、第1のユーザおよび関連ユーザは、サービスプラットフォームに情報を送信することを介して確約し、第1のユーザおよび関連ユーザが、優先的な第1の比率aを取得するために、第2のユーザのところであらかじめ決定されたリソース量を事前に蓄積する必要がないようにし、いずれかの予期せぬ出来事による、第2のユーザが事前に蓄積されたリソースを返すことができなくなるリスクを回避し得る。第2のユーザは、あらかじめ決定されたリソース量が取得され得ることを保証するために、第1のユーザおよび関連ユーザの事前に対話する意思を固定することができる。第1のユーザおよび/または関連ユーザが、確約を遵守することができない場合でも、第2のユーザは、依然として、サービスプラットフォームから第2の比率bにおいて差額リソースを取得するようになる。このようにして、第1のユーザおよび関連ユーザによって行われた確約は、サービスプラットフォームによって承認およびサポートされ得、それによって確約の信用性が向上する。

【0065】

一実施形態では、あらかじめ決定された最終期限は、あらかじめ決定された時間期間の終了後に開始する時間期間であり得、開始時間、終了時間、持続時間などが、サービスプラットフォームによって設定され得る。たとえば、あらかじめ決定された時間期間の終了時間は、あらかじめ決定された最終期限の開始時間として設定され得、別のあらかじめ決定された時間期間は、あらかじめ決定された最終期限の持続時間として設定され得る。別の例では、あらかじめ決定された時間期間の終了時間は、あらかじめ決定された最終期限の開始時間として設定され得、現在の月の最終日の午後24:00が、あらかじめ決定された最終期限の終了時間として設定され得る。本明細書は、本明細書で説明する1つまたは複数の実施形態に限定されない。

【0066】

一実施形態では、サービスプラットフォームは、第1のユーザ(または、第1のユーザおよび関連ユーザ)に通知を送信し、最終期限までに第2のユーザに差額リソースを送信するように、第1のユーザおよび関連ユーザに通知し得る。サービスプラットフォームは、たとえば、あらかじめ決定された時間期間の終了直後、あらかじめ決定された最終期限の中間点において、あらかじめ決定された最終期限の終了前のある時間において、あらかじめ決定された最終期限の間の各自然日の固定された時間においてなどを含む時間において、1つまたは複数のそのような通知を送信し得る。本明細書は、本明細書で説明する1つまたは複数の実施形態に限定されない。

【0067】

一実施形態では、サービスプラットフォームは、能動的に、第1のユーザに対応するユーザリソースプールから差額リソースを差し引き、第2のユーザに送信し得る。たとえば、ネットワークデータ共有シナリオでは、ユーザリソースプールは、第1のユーザによって保持されたすべてのネットワークデータであり得、共有管理プラットフォームは、第1のユーザに対するペナルティとして、ダウンロードの順序またはデフォルトの順序に従って、ネットワークデータの一部を削除し得る。取引シナリオでは、ユーザリソースプールは、第1のユーザの口座であり得る。サービスプラットフォームが口座から差し引くことを許可されている(第1のユーザが、そうするように行った確約によって、サービスプラットフォームを許可し得るか、または控除機関を取得することさえもが、サービスプラットフォームが確約を認めるための必須条件である)場合、サービスプラットフォームは、差額リソースに対応する金額を直接差し引き、第2のユーザの口座に差し引き額を送金することができる。

【0068】

一実施形態では、最初に、サービスプラットフォームは、第1のユーザ(または、第1のユーザと関連ユーザの両方)に通知を送信し、指定された最終期限までに第2のユーザに差額リソースを送信するように、第1のユーザ(または、第1のユーザおよび関連ユーザ)に通知し得る。次いで、第1のユーザがそうすることができない場合、サービスプラットフォームは、自動的に、第1のユーザに対応するユーザリソースプールから差額リソースを差し引き、第2のユーザに送信し得る。

【0069】

一実施形態では、第1のユーザが、あらかじめ決定された最終期限までに第2のユーザに差額リソースを送信することができない場合、サービスプラットフォームは、たとえば、第1のユーザの信用値を下げることを含み得る、信用破綻プロセスをトリガし得る。第1のユーザの信用値が、サービスプラットフォームによって維持される場合、サービスプラットフォームは、自動的に信用値を下げ得る。さもなければ、信用値が信用管理プラットフォームによって管理される場合、サービスプラットフォームは、信用管理プラットフォームにフィードバックを提供し、信用値を下げるように、信用管理プラットフォームに要求し得る。別の例として、信用破綻プロセスは、第1のユーザが、もはや本明細書で説明する解決策から利益を得ることができないように、およびいかなるサービスオブジェクトも、標準のリソース量を支払うという代償を払って取得しなければならないように、第1のユーザのサービスへの参加を制限することを含み得る。さらに別の例として、信用破綻プロセスは、第1のユーザを信用ブラックリストに追加すること、およびこの情報を他のプラットフォームと共有することを含み、第1のユーザへの将来の悪影響を引き起こし得る。限定はしないが、信用破綻プロセスはまた、他の対策、または複数の対策の組合せを含み得る。

【0070】

一実施形態では、第1のユーザが、指定された最終期限までに第2のユーザに差額リソースを送信することができない場合、サービスプラットフォームは、第1のユーザに対して信用破綻プロセスをトリガし得る。言い換えれば、「第1のユーザ」および「関連ユーザ」は、自分自身の信用状態のみに対する責任があり、もう1人の信用状態に対する責任はない。

【0071】

一実施形態では、第1のユーザが、最終期限までに第2のユーザに差額リソースを送信することができない場合、サービスプラットフォームは、第1のユーザと関連ユーザの両方に対して、信用破綻プロセスをトリガし得る。この場合、「第1のユーザ」および「関連ユーザ」は、もう1人の信用状態に対する責任がある。このことは、第1のユーザおよび関連ユーザが互いを監視し、差額リソースの適時の配信の確率を高めるために役立つ。

【0072】

図3は、例示的な実施形態において提供される、サービスを処理するためのシステムのアーキテクチャを示す概略図である。図3に示されるように、システムは、サーバ31、ネットワーク32、モバイルフォン33、34、PC35などを含み得る。サーバ31は、スタンドアロンのホストマシンを組み込む物理的なサーバ、またはホストマシンの集合によって提供された仮想サーバのいずれかであり得る。サーバ31は、たとえば、支払いプラットフォームである、本明細書で説明するサービスプラットフォームを提供し得る。モバイルフォン33、34の各々は、第1のユーザまたは関連ユーザによって使用される電子デバイスであり得、第1のユーザまたは関連ユーザに関して本明細書で説明するサービス機能を実施する能力を有するクライアントアプリケーション1を稼働させ得る。第1のユーザおよび関連ユーザの各々は、個人、企業などであり得る。限定はしないが、モバイルフォン33、34に加えて、第1のユーザまたは関連ユーザはまた、PC、タブレット、ノートブック、携帯情報端末(PDA)、またはウェアラブルデバイス(たとえば、スマートグラス、スマートウォッチなど)など、別のタイプの電子デバイスを使用し得る。PC35は、第2のユーザによって使用される電子デバイスであり得、PC35は、第2のユーザに関して本明細書で説明するサービス機能を実施することが可能なクライアントアプリケーション2を稼働させ得る。第2のユーザは、マーチャントなどであり得る。限定はしないが、PC35に加えて、第2のユーザはまた、モバイルフォン、タブレット、ノートブック、携帯情報端末(PDA)、またはウェアラブルデバイス(たとえば、スマートグラス、スマートウォッチなど)など、別のタイプの電子デバイスを使用し得る。モバイルフォン33、34、およびPC35は、様々なワイヤードネットワークまたはワイヤレスネットワークのうちの1つであり得る、ネットワーク32を介して、サーバ31と対話し得る。ネットワーク32の例には、公衆交換電話網(PSTN)およびインターネットが含まれ得る。

【0073】

以下の説明は、図3のシステムがサービスを処理する、例示的なコンテキストにおいて与えられる。ユーザAがモバイルフォン33を使用し、ユーザBがモバイルフォン34を使用し、マーチャントがPC35を使用し、サーバ31が支払いプラットフォームを提供すると仮定すると、次いで、ユーザA、ユーザB、マーチャント、および支払いプラットフォームは、本明細書におけるサービス処理解決策を実施するために、データ対話を実施することができる。図4は、例示的な実施形態による、取引シナリオにおけるサービス対話の概略図である。図4に示されるように、サービス対話のプロセスは、以下のステップを含み得る。

【0074】

ステップ401で、支払いプラットフォームとマーチャントとの間でアクティビティ契約が署名される。

【0075】

本明細書で説明する一実施形態によれば、取引シナリオでは、ユーザは、自分自身の信用に基づいて、消費確約をすることができ、マーチャントに前払いすることなく、対応する消費割引を享受することができる。したがって、支払いプラットフォームは、ユーザがアクティビティに参加することを可能にする最小信用値、あらかじめ決定された取引額、割引期間、ユーザのための取引割引、不履行の場合の割引額のための返金方式などについての合意を達成するために、事前にマーチャントと交渉し得る。

【0076】

一実施形態では、支払いプラットフォームとマーチャントとの間の交渉に基づいて、支払いプラットフォームは、マーチャントによって確認および署名された割引条件を受信し得る。割引条項は、上記で説明した交渉内容、および他の交渉内容をカバーし、支払いプラットフォームおよびマーチャントが情報に基づく交渉結果に達することができるようにする。

【0077】

ステップ402で、支払いプラットフォームは、ユーザAについてのアクティビティ情報を公開する。

【0078】

一実施形態では、ユーザAが、ウェブページなど、マーチャントについての情報を閲覧中であるとき、支払いプラットフォームは、ユーザAにアクティビティ契約についてのアクティビティ情報を提供し、ユーザAがその情報を閲覧し、アクションを取ることができるようにし得る。

【0079】

一実施形態では、ユーザAが、ウェブページなど、マーチャントについての情報を能動的に閲覧していないときでも、支払いプラットフォームは、依然として、ユーザAに対してアクティビティ情報を利用可能にし、ユーザAがその情報を閲覧し、アクションを取ることができるようにし得る。

【0080】

ステップ403で、ユーザAは、支払いプラットフォームに、アクティビティに参加するための申込書を提出する。

【0081】

一実施形態では、ユーザAがアクティビティに関心があるとき、ユーザAは、アクティビティ情報に基づいて、許可要求を作成し、ユーザAが対応する利益を取得するために、アクティビティ情報内に含まれているルールを守る意思があることを示し得る。次いで、ユーザAは、支払いプラットフォームに許可要求を送信し得、許可要求は、上記の実施形態で説明したような、第1のユーザによってサービスプラットフォームに送信される情報に相当する。許可要求は、ユーザAの確約する意思を示すための情報の一実装形態と見なされ得る。

【0082】

ステップ404で、支払いプラットフォームは、ユーザAに割引へのアクセスを与えるか否かを決定するために、ユーザAの信用値を検証する。

【0083】

一実施形態では、ユーザAがマーチャントに対して消費確約をすることを伴うので、マーチャントは、ユーザAが実際に確約を遵守することができることを確認する必要があり、確約に従わない場合、関連する優先的な資本を取り下げることができる。これは、ユーザAの信用値を用いて達成することができ、すなわち、信用値があらかじめ決定された値に達する場合、ユーザAが高い信用を有し、アクティビティに参加することが可能にされることが決定され、さもなければ、ユーザAの信用値があらかじめ決定された値に達しない場合、ユーザAが低い信用を有し、アクティビティに参加することが可能にされないことが決定される。

【0084】

一実施形態では、アクティビティ契約は、ユーザが参加後1か月以内に1,000元以上の累積額のマーチャントとの取引を確約する場合、ユーザが同じ期間内に20%の割引を取得し、ユーザが表示価格の80%のみを支払うことができるようになること、および、ユーザが確約を遵守することができない場合、ユーザが20%割引を取り消すように、ユーザが取得したいかなる割引額も埋め合わせることになることを含み得る。

【0085】

たとえば、ユーザAが、マーチャントから300元の表示価格をもつアイテムを買うことを望むと仮定すると、ユーザAが、アクティビティ契約において指定された割引期間(たとえば、1か月間)内であるとき、ユーザAは、20%割引を享受することができ、300×80%=240元のみを支払う必要がある。ユーザAがアクティビティに参加しないか、または割引期間内ではないとき、ユーザAは、正規の値段、すなわち、300元を支払う必要がある。

【0086】

ステップ405で、ユーザAがマーチャントからの消費を有するとき、マーチャントは、ユーザAの識別子を取得し得る。

【0087】

一実施形態では、ユーザAは、モバイルフォン33において支払いインターフェースを開くことができ、支払いインターフェースは、ユーザAのアイデンティティに関連付けられたQRコード(登録商標)を含み得る。マーチャントは、ユーザAの識別子(平文または暗号文)を取得するために、PC35に関連付けられたスキャニングデバイスを通して、QRコード(登録商標)をスキャンし得る。

【0088】

ステップ406で、マーチャントは、支払いプラットフォームに、ユーザAの識別子を含んでいる認証要求を送信し得る。

【0089】

一実施形態では、支払いプラットフォームは、許可要求中に含まれた識別子に基づいて、識別子に、マーチャントによって提供された割引の資格があるか否か問い合わせ、マーチャントに認証結果を返し得る。

【0090】

ステップ407で、マーチャントは、支払いプラットフォームによって返された許可結果を受信し、消費額を決定する。

【0091】

一実施形態では、認証結果が、ユーザAに割引の資格があることを示す場合、PC35は、割引認証に基づいて、消費額の割引計算を実施し、計算された金額を実際の消費額として取り得る。認証結果が、ユーザAに割引の資格がないことを示す場合、PC35は、割引計算を実施せず、ユーザAが支払うことになる実際の消費額として、消費のための割引なしの標準額を直接取るようになる。

【0092】

ステップ408で、決定された消費額に基づいて、マーチャントは、支払いプラットフォームに支払い要求を送信する。

【0093】

ユーザAが支払うことになる実際の消費額を決定するために、ステップ406〜407を実施するのではなく、マーチャントは、代替的に単に、実際の取引額を計算することなく、ステップ408で、支払いプラットフォームに、ユーザAの識別子と消費のための標準額とを提供し得る。次いで、支払いプラットフォームは、ユーザAの識別子に取引割引の資格があるか否かに基づいて、実際の消費額を決定する。

【0094】

ステップ409で、支払い要求に応答して、支払いプラットフォームは、ユーザAに支払い通知を送信し、ユーザAから支払いの確認を受信すると、支払いを完了する。

【0095】

一実施形態では、モバイルフォン33は、再検討のためにユーザAに支払いインターフェースを提示することができ、支払いインターフェースは、製品、マーチャント、表示価格、割引価格などについての情報を含み得る。ユーザAが、情報が正しいと確認した後、ユーザAは、支払いインターフェースにおいて「支払いを確認」をトリガするか、または他の方法を使用して、支払いプラットフォームに支払い確認を返すことをモバイルフォン33に行わせ得る。支払いプラットフォームは、ユーザAに関連付けられた口座から対応する金額を差し引き、マーチャントが支払いプラットフォームまたは他の金融機関においてマーチャント口座を開設しているとき、マーチャントの口座に差し引き額を送金し、このようにして支払いを完了し得る。

【0096】

ステップ410で、支払いプラットフォームは、ユーザAとマーチャントの両方に支払い結果を通知する。

【0097】

ステップ411で、支払いプラットフォームは、確約が履行されるか否かを検証する。

【0098】

一実施形態では、支払いプラットフォームは、ユーザAがアクティビティ契約において指定された消費確約に達しているか否かを決定するために、アクティビティ契約において指定された時間期間後、ユーザAの消費を集計することができる。

【0099】

たとえば、割引期間中にユーザAによってマーチャントから購入された製品の表示価格が、合計3,000元になる場合、20%割引のために、ユーザAによって実際に支払われた総額は、3,000×80%=2,400元であり、1,000元(あらかじめ決定された金額)よりも大きい。したがって、ユーザAは、取引確約を履行しており、割引額を返金する必要がない。

【0100】

別の例として、割引期間中にユーザAによってマーチャントから購入された製品の表示価格が、合計1,200元になる場合、20%割引のために、ユーザAによって実際に支払われた総額は、1200×80%=960元であり、1,000元(あらかじめ決定された金額)未満である。したがって、ユーザAは、取引確約を履行することができず、割引額を返金する必要がある。

【0101】

ステップ412で、ユーザAが取引確約を履行することができない状況では、支払いプラットフォームは、ユーザAに、マーチャントに割引額を返金するための割引返金通知を送信する。

【0102】

一実施形態では、モバイルフォン33は、返金最終期限までにマーチャントに割引額を返金するように、ユーザAに通知するために、支払いプラットフォームによってユーザAに送信された割引返金通知を表示し得、割引返金通知は、返金のための理由(ユーザAが取引確約を履行することができない)、返金されることになる割引額、返金が支払われることになる最終期限などを含み得る。

【0103】

一実施形態では、通知は、支払いプラットフォームによって提供されたクライアントアプリケーションからのアプリケーション内メッセージ、ショートメッセージサービス(SMS)、インスタントメッセージ、電子メール、電話に出ると再生される音声メッセージなど、任意の形式を取り得る。本明細書は、本明細書で説明する1つまたは複数の実施形態に限定されない。

【0104】

ステップ413で、支払いプラットフォームは、返金が支払われたか否かを検証する。

【0105】

一実施形態では、返金最終期限までに、支払いプラットフォームは、ユーザAが割引額を返金する前に、ユーザAに複数の通知を送信し得る。

【0106】

別の実施形態では、ユーザAが事前に自動返金機能を可能にしている場合、支払いプラットフォームは、ユーザAの口座から割引額を自動的に差し引き、返金最終期限が満了する前に、マーチャントの口座に差し引き額を送金し、したがって、ユーザAが不注意または何らかの他の理由による、満了前に割引額を返金できなくなることを回避し得る。

【0107】

ステップ414で、ユーザAが割引額を返金することができない場合、支払いプラットフォームは、ユーザAの信用値を下げ、かつ/あるいは他の割引アクティビティへのユーザAの参加を制限する。

【0108】

一実施形態では、ユーザAが、返金最終期限までに割引額を返金することができない場合、支払いプラットフォームは、ペナルティとして、たとえば、ユーザAの信用値を下げること、他の割引アクティビティへのユーザAの参加を制限することなどを含む、信用破綻プロセスをトリガし得る。信用破綻プロセスはまた、他のペナルティ措置を含むこともあり、本明細書は、本明細書で説明する1つまたは複数の実施形態に限定されない。

【0109】

マーチャントの割引アクティビティに単独で参加することに加えて、ユーザAは、ユーザBなど、他の関連ユーザと一緒に参加し得る。互いに関連付けられるユーザAおよびユーザBが割引アクティビティに一緒に参加する一実施形態について、以下で説明する。以下の実施形態の他にも、3人以上の関連ユーザが割引アクティビティに一緒に参加することも可能である。

【0110】

図5は、例示的な実施形態による、別の取引シナリオにおけるサービス対話を示す概略図である。図5に示されるように、サービス対話のプロセスは、以下で詳述するようなステップを含み得る。

【0111】

ステップ501で、支払いプラットフォームとマーチャントとの間でアクティビティ契約が署名される。

【0112】

ステップ502で、支払いプラットフォームは、ユーザAについてのアクティビティ情報を公開する。

【0113】

一実施形態では、ステップ501〜502における詳細については、図4に示されたステップ401〜402に関して与えられた上記の説明を参照することができ、その詳細な説明の繰返しは、本明細書で省略される。

【0114】

ステップ503で、ユーザAは、アクティビティに参加するようにユーザBを勧誘し、ユーザBから勧誘の確認を受信する。

【0115】

一実施形態では、ユーザAは、マーチャントの割引アクティビティに一緒に参加するように、ユーザBを勧誘し得る。ユーザBは、自分自身の裁量で、勧誘を受け入れるかまたは断るかを選び得る。

【0116】

ステップ504で、ユーザAは、支払いプラットフォームに、アクティビティに参加するための申込書を提出する。

【0117】

一実施形態では、ユーザBは、割引アクティビティにおいて勧誘された参加者であるので、ユーザAのみが、支払いプラットフォームに、アクティビティに参加するための申込書を提出する必要がある。言い換えれば、ユーザAは、ユーザAとユーザBの両方を表し得る。別の実施形態では、ユーザAおよびユーザBは、支払いプラットフォームに別個の申込書を提出し得る。ステップ503における、ユーザAとユーザBとの間の勧誘動作に基づいて、支払いプラットフォームは、ユーザAからユーザBの間の関連付けを知っていることがあり、したがって、ユーザAおよびユーザBを、割引アクティビティにおける関連する参加者として識別し得る。

【0118】

ステップ505で、支払いプラットフォームは、ユーザAおよびユーザBに割引へのアクセスを与えるか否かを決定するために、ユーザAおよびユーザBの信用値を検証する。

【0119】

一実施形態では、ユーザAの信用値があらかじめ決定された値に達するが、ユーザBの信用値がそうではないとき、支払いプラットフォームは、図4に示されるように、割引アクティビティにおいて、Bの参加を受け入れず、ユーザAの参加のみを許可し得る。同様に、ユーザBの信用値があらかじめ決定された値に達するが、ユーザAの信用値がそうではないとき、支払いプラットフォームは、割引アクティビティにおいて、ユーザAの参加を受け入れないことがあり、ユーザBの参加のみを可能にする。

【0120】

一実施形態では、ユーザAおよびユーザBの各々の信用値があらかじめ決定された値に達するとき、支払いプラットフォームは、ユーザAおよびユーザBの各々が関連する参加者として割引アクティビティに参加することを可能にし、割引へのアクセスを彼らの各々に与え得る。ユーザAおよびユーザBが参加するための2つのオプションがあり得る。

【0121】

オプション1:ユーザAおよびユーザBが、同じ確約を共有する。たとえば、図4では、ユーザAのみが確約するとき、確約は、ユーザAが1か月以内に1,000元以上のマーチャントにおける消費額を有する場合、ユーザAが20%の割引を取得することができるというものである。ユーザAおよびユーザBが同じ確約を共有するとき、確約は、ユーザAおよびユーザBが1か月以内に1,000元以上のマーチャントにおける消費総額を有する場合、ユーザAとユーザBの両方が20%の割引を取得することができるというものである。共有の確約をすることによって、各ユーザは、各ユーザが確約するために必要である消費額を低減し、確約を履行する難しさを低減することができる。加えて、これは、複数のユーザの間で割引アクティビティを広げ、促進する際に有用である。

【0122】

オプション2:ユーザAおよびユーザBが、別個であるが関連する確約をする。たとえば、確約は、ユーザAが1か月以内にマーチャントにおいて1,000元を超える消費額を有する場合、ユーザAが少なくとも20%割引を得ることができること、ユーザBが1か月以内にマーチャントにおいて1,000元を超える消費額を有する場合、ユーザBが少なくとも20%割引を得ることができること、ユーザAおよびユーザBの各々が、1か月以内にマーチャントにおいて1,000元を超える消費額を有する場合、ユーザAとユーザBの両方が40%割引を得ることができることを含み得る。次いで、ユーザの各々は、図4に示されたものと同じ確約を別個にするが、複数のユーザが彼らの確約を遵守することができる場合、彼らは、さらに大きい割引を取得することができ、ユーザが互いに監視し、規則を守らせることを促す。

【0123】

ステップ506で、マーチャントからのユーザA(またはB)のいずれかの消費があると、マーチャントは、ユーザA(またはB)の識別子を取得し得る。

【0124】

ステップ507で、マーチャントは、支払いプラットフォームに、ユーザA(またはB)の識別子を含んでいる認証要求を送信し得る。

【0125】

ステップ508で、マーチャントは、支払いプラットフォームからの認証結果から、消費額を決定する。

【0126】

ステップ509で、決定された消費額に基づいて、マーチャントは、支払いプラットフォームに支払い要求を送信する。

【0127】

ステップ510で、支払い要求に応答して、支払いプラットフォームは、ユーザA(またはB)に支払い通知を送信し、ユーザA(またはB)から支払いの確認を受信すると、支払いを完了する。

【0128】

ステップ511で、支払いプラットフォームは、ユーザA(またはB)およびマーチャントの各々に支払い結果を知らせる。

【0129】

一実施形態では、ステップ506〜511における詳細については、図4に示されたステップ405〜410に関して与えられた上記の説明を参照することができ、その詳細な説明の繰返しは、本明細書で省略される。

【0130】

ステップ512で、支払いプラットフォームは、確約の履行を検証する。

【0131】

ステップ513で、いずれかの確約が履行されない場合、支払いプラットフォームは、各違反ユーザに、マーチャントに割引額を返金するための割引返金通知を送信する。

【0132】

一実施形態では、ユーザAおよびユーザBが一緒に共有の確約している状況では、以下のケースが可能である。

【0133】

ケース1:1か月間以内のマーチャントからのユーザAおよびユーザBの消費総額が、1,000元に達する。この場合、ユーザAおよびユーザBが確約を履行しており、割引額を返金する必要がないことが決定される。

【0134】

ケース2:1か月間以内のマーチャントからのユーザAおよびユーザBの取引総額が、1,000元に達しない。この場合、ユーザAおよびユーザBが確約を履行することができず、ユーザAおよびユーザBによってそれぞれ購入された製品に基づいて、割引額を返金する必要があることが決定される。ユーザAが、20%の割引において200元の表示価格をもつ製品を購入しており、すなわち、ユーザAが実際に200×80%=160元のみを支払ったと仮定すると、次いで、ユーザAは、割引額、すなわち、200×(1-80%)=40元を返金することになる。ユーザBが、20%の割引において600元の表示価格をもつ製品を購入しており、すなわち、ユーザBが実際に600×80%=480元のみを支払ったと仮定すると、次いで、ユーザBは、割引額である600×(1-80%)=120元を返金することになる。

【0135】

いくつかの実施形態では、ユーザAおよびユーザBは、別個であるが関連する確約を有し、複数の状況があり得る。

【0136】

ケース1:ユーザAの消費総額が1か月間以内に1,000元に達し、ユーザBの消費総額もまた1か月間以内に1,000元に達するとき、ユーザAおよびユーザBの各々が彼らの確約を履行しており、したがって、いかなる割引額を返金することもなく、40%の割引の資格があることが決定される。

【0137】

ケース2:1か月間以内のマーチャントからのユーザAの消費総額が1,000元に達するが、ユーザBの消費総額がそうではないとき、ユーザAおよびユーザBが彼らの確約を履行することができず、割引額を返金するべきであることが決定される。ユーザAは、自分個人の確約を履行しているので、ユーザAには20%の関連割引の資格があるが、ユーザAとユーザBの両方が自分個人の確約を履行する場合のみに資格が与えられる40%割引の資格はない。たとえば、ユーザAが、40%割引において200元の表示価格をもつ製品を購入しており、すなわち、実際に200×60%=120元のみを支払っている場合、ユーザAは、追加の割引額、すなわち、200×(80%-60%)=40元を返金することになる。ユーザBが、40%割引において600元の表示価格をもつ製品を購入しており、すなわち、実際に600×60%=360元のみを支払っている場合、ユーザBは、割引の全額、すなわち、600×(1-60%)=240元を返金するべきである。

【0138】

同様に、1か月間以内のマーチャントからのユーザAの消費総額が1,000元に達しないが、ユーザBの消費総額が達するとき、次いで、ユーザAは、個人の確約の不履行のために、割引の全額を返金するべきである。たとえば、ユーザAが、40%割引において200元の表示価格をもつ製品を購入しており、すなわち、実際に200×60%=120元のみを支払っている場合、ユーザAは、割引額、すなわち、200×(1-60%)=80元を返金することになる。ユーザBは、自分個人の確約を履行しており、したがって、ユーザBには20%の関連割引の資格があるが、ユーザAとユーザBの両方が自分個人の確約を履行する場合のみに資格が与えられる40%割引の資格はない。ユーザBが、40%割引において600元の表示価格をもつ製品を購入しており、すなわち、実際に600×60%=360元のみを支払っている場合、ユーザBは、割引額、すなわち、600×(80%-60%)=120元を返金するべきである。

【0139】

ケース3:1か月間以内のマーチャントからのユーザAの消費総額が1,000元に達しておらず、1か月間以内のマーチャントからのユーザBの消費総額も1,000元に達しないとき、ユーザAおよびユーザBが彼らの確約を履行することができず、割引額を返金するべきであることが決定される。たとえば、ユーザAが、40%割引において200元の表示価格をもつ製品を購入しており、すなわち、実際に200×60%=120元のみを支払っている場合、ユーザAは、割引額、すなわち、200×(1-60%)=80元を返金することになる。ユーザBが、40%割引において600元の表示価格をもつ製品を購入しており、すなわち、実際に600×60%=360元のみを支払っている場合、ユーザBは、割引の全額、すなわち、600×(1-60%)=240元を返金するべきである。

【0140】

一実施形態では、ユーザAが割引額を返金するべきであるとき、支払いプラットフォームは、ユーザAに割引返金通知を送信し得る。同様に、ユーザBが割引額を返金するべきである場合、支払いプラットフォームは、ユーザBに割引返金通知を送信し得る。ユーザAおよびユーザBは関連する参加者であるので、たとえば、ユーザAのみが割引額を返金するべきであるが、ユーザBはその必要がないときでも、ユーザBが、返金を支払うようにユーザAに通知すること、またはユーザAの経済的な圧迫を緩和するために、ユーザAの代わりに金額の少なくとも一部を返金することさえできるように、ユーザBに割引返金通知を送信することも可能である。

【0141】

ステップ514で、支払いプラットフォームは、返金が支払われたか否かを検証する。

【0142】

ステップ515で、ユーザAまたはユーザBが、間に合うように割引額を返金することができない場合、支払いプラットフォームは、ユーザAまたはユーザBの信用値を下げ、かつ/あるいは他の割引アクティビティへのユーザAまたはユーザBの参加を制限する。

【0143】

一実施形態では、ユーザAおよびユーザBの信用状態は、互いに無関係であり得る。この場合、たとえば、ユーザAが適時に割引額を返金することができないが、ユーザBがいかなる割引額も返金する必要がないか、または割引額を返金している場合、ユーザAのみがペナルティを受けることがあり、ユーザBは受けないことがある。

【0144】

一実施形態では、ユーザAおよびユーザBの信用状態は、互いに関連付けられ得る。この場合、たとえば、ユーザBがいかなる割引額も返金する必要がないか、または割引額を返金しているときでも、ユーザAが適時に割引額を返金することができない限り、ユーザAとユーザBの両方がペナルティを受けるようになる。いくつかの実施形態では、ユーザBに対するペナルティの方が小さくなり得る。

【0145】

図6は、例示的な実施形態による、さらに別の取引シナリオにおけるサービス対話を示す概略図である。図6に示されるように、サービス対話のプロセスは、以下で詳述するようなステップを含み得る。

【0146】

ステップ601で、支払いプラットフォームとマーチャントとの間でアクティビティ契約が署名される。

【0147】

ステップ602で、支払いプラットフォームは、ユーザAに、アクティビティについての情報を公開する。

【0148】

ステップ603で、ユーザAは、アクティビティに参加するようにユーザBを勧誘し、ユーザBから勧誘の確認を受信する。

【0149】

ステップ604で、ユーザAは、支払いプラットフォームに、アクティビティに参加するための申込書を提出する。

【0150】

一実施形態では、ステップ601〜604における詳細については、図5に示されたステップ501〜504に関して与えられた上記の説明を参照することができ、その詳細な説明の繰返しは、本明細書で省略される。

【0151】

ステップ605で、支払いプラットフォームは、ユーザAおよびユーザBに割引へのアクセスを与えるか否かを決定するために、ユーザAおよびユーザBの信用値を検証する。

【0152】

一実施形態では、ユーザAの信用値があらかじめ決定された値に達するが、ユーザBの信用値がそうではないとき、支払いプラットフォームは、図4に示されるように、ユーザBの参加を受け入れず、ユーザAの参加のみを許可し得る。同様に、ユーザBの信用値があらかじめ決定された値に達するが、ユーザAの信用値がそうではないとき、支払いプラットフォームは、ユーザAの参加を受け入れず、ユーザBの参加のみを許可し得る。

【0153】

一実施形態では、ユーザAおよびユーザBが、別個であるが関連する確約をする。たとえば、確約は、ユーザAが1か月以内にマーチャントにおいて1,000元を超える消費額を有する場合、ユーザAが少なくとも20%割引を得ることができること、ユーザBが1か月以内にマーチャントにおいて1,000元を超える消費額を有する場合、ユーザBが少なくとも20%割引を得ることができること、ユーザAおよびユーザBの各々が、1か月以内にマーチャントにおいて1,000元を超える消費額を有する場合、ユーザAとユーザBの両方が40%割引を得ることができることを含み得る。次いで、ユーザの各々は、図4に示されたものと同じ確約を別個に行うが、複数のユーザが彼らの確約を遵守することができる場合、彼らは、さらに大きい割引を取得することができ、ユーザが互いに監視し、規則を守らせることを促す。

【0154】

ステップ606Aで、ユーザAは、20%の割引における、マーチャントにおける消費を有する。

【0155】

ステップ606Bで、ユーザBは、20%の割引における、マーチャントにおける消費を有する。

【0156】

一実施形態では、ステップ605〜606で実施される認証および支払いプロセスにおける詳細については、図4に示されたステップ405〜410に関して与えられた上記の説明を参照することができ、その詳細な説明の繰返しは、本明細書で省略される。

【0157】

ステップ607で、支払いプラットフォームは、確約の履行を検証する。

【0158】

ステップ608で、ユーザAおよびユーザBの各々が自分個人の確約を履行している場合、支払いプラットフォームは、マーチャントに返金通知を送信する。

【0159】

一実施形態では、ユーザAの消費総額が1か月間以内に1,000元に達し、ユーザBの消費総額もまた1か月間以内に1,000元に達するとき、ユーザAおよびユーザBの各々が彼らの確約を履行しており、したがって、40%の割引の資格があることが決定される。しかしながら、ユーザAおよびユーザBは、実際には20%の割引において消費するので、マーチャントは、ユーザAおよびユーザBの各々に、20%の追加の割引に相当する金額を返金することになり、すなわち、総割引は40%である。

【0160】

一実施形態では、指定された1か月間以内のマーチャントからのユーザAの取引総額が1,000元に達するが、ユーザBの取引総額が達しない場合、ユーザAは、初期の20%割引のみの資格があり、マーチャントからの返金の形式における追加の20%割引の資格はない。他方では、ユーザBは、マーチャントに20%割引額を返金するべきであり、より詳細については、図5の実施形態の上記の説明を参照することができる。同様に、1か月間以内のマーチャントからのユーザBの取引総額が1,000元に達し、ユーザAの取引総額が達しない場合、ユーザBは、初期の20%割引のみの資格があるが、マーチャントからの返金の形式における追加の割引の資格はなく、ユーザAは、マーチャントに20%割引額を返金することになる。

【0161】

一実施形態では、指定された1か月間以内のマーチャントからのユーザAの購入総額とユーザBの購入総額のどちらも1,000元に達しない場合、図5の実施形態とともに上記で説明したものと同様に、彼らの各々が、マーチャントに20%割引額を返金することになる。

【0162】

ステップ609で、支払いプラットフォームは、マーチャントによって返金が支払われたか否かを検証する。

【0163】

ステップ610で、マーチャントが適時に返金を支払うことができない場合、支払いプラットフォームは、その信用値を下げるか、またはマーチャントの他のそのような割引アクティビティの開始を制限し得る。

【0164】

一実施形態では、支払いプラットフォームは、指定された最終期限までに、ユーザAおよびユーザBに返金を支払うように、マーチャントに通知し得る。たとえば、マーチャントがそうすることができない場合、支払いプラットフォームは、自動的にマーチャントの口座から対応する金額を差し引き、ユーザAおよびユーザBのそれぞれの口座に差し引き額を送金し得る。これは、自動返金手法を必然的に伴うものである。別の場合には、マーチャントが、支払いプラットフォームがマーチャントの口座からいかなる金額も自動的に差し引くことを許可していない場合、またはマーチャントがそのような許可を与えているが、口座内の残高が十分ではなく、マーチャントが指定された最終期限までにユーザAおよびユーザBに返金を支払うことができなくなる場合、支払いプラットフォームは、マーチャントにペナルティを科すことがある。

【0165】

取引シナリオにおける割引アクティビティについて、例として図7〜図11に示されたインターフェースを参照しながら、以下で説明する。

【0166】

図7は、例示的な実施形態による、割引アクティビティを作成する概略図である。図7に示されるように、マーチャントは、アクティビティ作成インターフェース700を通して、ブランド「X」のための割引アクティビティを作成し得る。アクティビティ作成インターフェース700を介して、アクティビティ期間、確約消費額、基本割引、優先割引などが構成され得る。したがって、アクティビティ期間の全体にわたって、割引アクティビティの参加者が「優先割引」においてブランド「X」の製品を買うことが可能にされる。しかしながら、アクティビティ期間内の参加者の累積消費額が「確約消費額」に達しない場合、参加者は「基本割引」のみの資格があり、「優先割引と基本割引」との間で生じる差分を返金することになる。構成を完了した後、マーチャントは、「作成を確認」オプションをアクティブ化することによって、割引アクティビティの作成を確認し、様々な買い手がその情報を見て、割引アクティビティに参加することができるように、取引プラットフォームを通して、割引アクティビティを公開し得る。

【0167】

図8は、例示的な実施形態による、作成された割引アクティビティを示す概略図である。図8に示されるように、マーチャントは、アクティビティ提示インターフェース800内で作成された様々な割引アクティビティを閲覧および管理し得る。たとえば、アクティビティ提示インターフェース800内に提示された「01 確約されたアクティビティ」は、マーチャントによって最近作成された割引アクティビティであり得る。割引アクティビティは、14日の「アクティビティ期間」と、200元の「確約消費額」と、8%の「基本割引」と、12%の「優先割引」とを有する。本明細書で詳細に説明しないが、「02 確約されたアクティビティ」として示されたものなど、他の割引アクティビティもまた、アクティビティ提示インターフェース800内に提示され得る。マーチャントは、買い手がそれ以上、この情報を見ること、またはアクティビティに参加することができないようにするために、対応する「除去」オプションをアクティブ化することによって、「01 確約された割引アクティビティ」を除去し得る。本明細書でさらに詳細に説明しないが、マーチャントはまた、その「アクティビティ期間」、「確約消費額」、「基本割引」、「優先割引」などに変更を行うために、任意の作成された割引アクティビティを編集し得る。

【0168】

図9は、例示的な実施形態による、買い手にアクティビティ内容を示す概略図である。図9に示されるように、買い手は、取引プラットフォーム上のアクティビティ提示インターフェース900内で、アクティビティについての情報を閲覧し得る。アクティビティ提示インターフェース900は、買い手が割引アクティビティを完全に理解し、買い手が参加時に取得することができる利益および義務を知ることができるように、マーチャントが、アクティビティ作成インターフェース700を使用して作成された割引アクティビティを買い手に提示するために使用され得る。そのような利益は、たとえば、「12%の優先割引」を含み得るのに対して、そのような義務は、たとえば、「2018年8月1日から2018年8月14日までの期間内に、200元以上の店での累積消費額」および「期間内の消費額が200元に達しない状況における、優先割引と基本割引(8%)との間に生じる差分の返金」を含み得る。任意の割引アクティビティに対して、買い手は、アクティビティ提示インターフェース900内で対応する「参加を確認」オプションをアクティブ化することによって、参加のための申込書を提出し得る。

【0169】

図10は、例示的な実施形態による、買い手が差分を返金することを必要とする通知を概略的に示す。アクティビティ期間内に割引アクティビティに参加している買い手の実際の消費額が、確約消費額に達しないとき、返金通知が、取引プラットフォームから買い手に送信され、図10に示されるように、通知表示インターフェース1000内に表示され得る。返金通知は、買い手が参加している割引アクティビティについての情報、返金のための理由、割引された金額などを、買い手に知らせ得る。買い手は、通知表示インターフェース1000内で「割引を返金」オプションをアクティブ化することによって、返金を開始し得る。

【0170】

一実施形態では、買い手が通知表示インターフェース1000内で「割引を返金」オプションをアクティブ化すると、買い手は、図11に示されるように、買い手が実際に返金することになる差分を示す、返金詳細説明インターフェース1100にナビゲートすることができる。たとえば、基本割引額は8元であるが、総額12元が、優先割引に基づいて買い手のために実際に割り引かれたと仮定すると、そのため、買い手は、差分を埋め合わせるために、4元を返金するべきである。買い手は、返金詳細説明インターフェース1100内で「すぐに返金」オプションをアクティブ化することによって、返金を支払い得る。

【0171】

図12は、例示的な実施形態による装置の概略構造図である。図12を参照すると、装置は、ハードウェアレベルにおいて、プロセッサ1202と、内部バス1204と、ネットワークインターフェース1206と、メモリ1208と、不揮発性記憶デバイス1210とを含む。装置はまた、サービス処理のために必要な他のハードウェアを含み得る。プロセッサ1202は、不揮発性記憶デバイス1210からメモリ1208に対応するコンピュータプログラムを読み込み、論理レベルにおいて、サービスを処理するためのデバイスを形成するように、そのコンピュータプログラムを実行するように構成される。このソフトウェア実装形態以外に、本明細書で説明する1つまたは複数の実施形態は、論理デバイス実装形態、組み合わせられたソフトウェア/ハードウェア実装形態など、他の実装形態を除外しない。言い換えれば、以下で説明するプロセスは、以下の様々な論理ユニットによってのみでなく、ハードウェアまたは論理デバイスによっても実行可能である。

【0172】

図13を参照すると、ソフトウェア実施形態では、装置はサービスプラットフォームに適用され、

【0173】

ユーザ端末から送信される情報を受信するための受信ユニット1301であって、情報が、ユーザ端末に対応する第1のユーザの信用値があらかじめ決定された値に達するとき、第1のユーザが、あらかじめ決定された時間期間内に第2のユーザにあらかじめ決定されたリソース量以上を送信すると確約する場合、第1のユーザによって送信されるリソース量と、第2のユーザによって第1のユーザに提供されるサービスオブジェクトに対応する標準のリソース量の比率が、第1の比率aとして定義され、ただし、0<a<1であることを備える、受信ユニット1301と、

【0174】

あらかじめ決定された時間期間内に、第1のユーザによって第2のユーザに送信される実際のリソース量が、あらかじめ決定された量未満である場合、第1のユーザが、指定された最終期限までに第2のユーザに差額リソースを送信するように、差額補償プロセスをトリガするための、第1のトリガリングユニット1302であって、ここにおいて、差額リソースの量と標準のリソース量の比率が、第2の比率bとして定義され、ここにおいて、0<b≦1-aである、第1のトリガリングユニット1302とを含み得る。

【0175】

場合によっては、第1のトリガリングユニット1302は、

【0176】

第1のユーザに通知を送信すること、および/または

【0177】

自動的に、第1のユーザに対応するユーザリソースプールから差額リソースを差し引き、第2のユーザに送信することを行うように構成され得る。

【0178】

場合によっては、装置は、

【0179】

第1のユーザが、最終期限までに第2のユーザに差額リソースを送信することができない場合、第1のユーザに対して信用破綻プロセスを開始するための処理ユニット1303をさらに含み得る。

【0180】

場合によっては、処理ユニット1303は、

【0181】

第1のユーザの信用値を下げること、第1のユーザのサービスへの参加を制限すること、および信用ブラックリストに第1のユーザを追加することのうちの少なくとも1つのために構成され得る。

【0182】

場合によっては、装置は、

【0183】

第1のユーザが、その信用値があらかじめ決定された値に達する、少なくとも1人の関連ユーザを有し、第1のユーザおよび関連ユーザの各々が、あらかじめ決定された時間期間内にあらかじめ決定されたリソース量以上を第2のユーザに送信すると確約する場合、第1の比率aの値を減少させるための調整ユニット1304をさらに含み得る。

【0184】

場合によっては、装置は、

【0185】

あらかじめ決定された時間期間内に、第1のユーザによって第2のユーザに送信される実際のリソース量が、あらかじめ決定された量以上であるが、あらかじめ決定された時間期間内に、少なくとも1人の関連ユーザによって第2のユーザに送信される実際のリソース量が、あらかじめ決定された量未満である場合、第1のユーザが、指定された最終期限までに第2のユーザに調整リソースを送信するように、調整補償プロセスをトリガするための、第2のトリガリングユニット1305をさらに含み得る。調整リソースの量、対、標準のリソース量は、第3の比率cとして定義され、第3の比率cは、第1の比率aの減少された値に等しい。

【0186】

場合によっては、装置は、

【0187】

第1のユーザが、その信用値があらかじめ決定された値に達する、少なくとも1人の関連ユーザを有し、あらかじめ決定された時間期間内に、第1のユーザおよび関連ユーザの各々によって第2のユーザに送信される実際のリソース量が、あらかじめ決定された量以上である場合、第2のユーザが第1のユーザに返金リソースを送信するように、返金プロセスをトリガするための、第3のトリガリングユニット1306であって、ここにおいて、返金リソースの量、対、標準のリソース量が、第4の比率dとして定義され、ただし、0<d<aである、第3のトリガリングユニット1306をさらに含み得る。

【0188】

図14は、例示的な実施形態による装置の概略構造図である。図14を参照すると、装置は、ハードウェアレベルにおいて、プロセッサ1402と、内部バス1404と、ネットワークインターフェース1406と、メモリ1408と、不揮発性記憶デバイス1410とを含む。装置はまた、サービス処理のために必要な他のハードウェアを含み得る。プロセッサ1402は、不揮発性記憶デバイス1410からメモリ1408に対応するコンピュータプログラムを読み込み、論理レベルにおいて、サービスを処理するための装置を形成するように、そのコンピュータプログラムを実行するように構成される。このソフトウェア実装形態以外に、本明細書で説明する1つまたは複数の実施形態は、論理デバイス実装形態、組み合わせられたソフトウェア/ハードウェア実装形態など、他の実装形態を除外しない。言い換えれば、以下で説明するプロセスは、以下の様々な論理ユニットによってのみでなく、ハードウェアまたは論理デバイスによっても実行可能である。

【0189】

図15を参照すると、ソフトウェア実施形態では、装置はサービスプラットフォームに適用され、

【0190】

ユーザ端末から送信される情報を受信するための受信ユニット1501であって、情報が、ユーザ端末に対応する第1のユーザが少なくとも1人の関連ユーザを有し、第1のユーザおよび関連ユーザの各々の信用値があらかじめ決定された値に達するとき、第1のユーザおよび関連ユーザが、あらかじめ決定された時間期間内に第2のユーザにあらかじめ決定された総リソース量以上を送信すると確約する場合、第1のユーザによって送信されるリソース量と、第2のユーザによって第1のユーザに提供されるサービスオブジェクトに対応する標準のリソース量の比率が、第1の比率aとして定義され、ここにおいて、0<a<1であることを備える、受信ユニット1501と、

【0191】

あらかじめ決定された時間期間内に、第1のユーザおよび関連ユーザによって第2のユーザに送信される実際の総リソース量が、あらかじめ決定された量未満である場合、第1のユーザが、指定された最終期限までに第2のユーザに差額リソースを送信するように、差額補償プロセスをトリガするための、トリガリングユニット1502であって、ここにおいて、差額リソースの量と標準のリソース量の比率が、第2の比率bとして定義され、ただし、0<b≦1-aである、トリガリングユニット1502とを含み得る。

【0192】

場合によっては、装置は、

【0193】

第1のユーザが、指定された最終期限までに第2のユーザに差額リソースを送信することができない場合、第1のユーザに対して信用破綻プロセスを開始するための第1の処理ユニット1503をさらに含み得る。

【0194】

場合によっては、装置は、

【0195】

第1のユーザが、指定された最終期限までに第2のユーザに差額リソースを送信することができない場合、第1のユーザおよび関連ユーザに対して信用破綻プロセスを開始するための第2の処理ユニット1504をさらに含み得る。

【0196】

詳細には、上記の実施形態において説明したシステム、装置、モジュール、またはユニットは、コンピュータチップもしくはエンティティによって、またはいくつかの機能をもつ製品によって実装され得る。典型的な実装形態はコンピュータであり、コンピュータは、詳細には、パーソナルコンピュータ(PC)、ラップトップ、セルフォン、カメラフォン、スマートフォン、個人デジタルアシスタント、メディアプレーヤ、ナビゲーションデバイス、電子メール送信および受信デバイス、ゲームコンソール、タブレット、ウェアラブルデバイス、またはそれらのいずれかの任意の組合せの形態であり得る。

【0197】

典型的な構成では、コンピュータは、1つまたは複数のプロセッサ(CPU)、入出力(I/O)インターフェース、ネットワークインターフェース、およびメモリを組み込む。

【0198】

メモリは、コンピュータ可読媒体の中でも、揮発性メモリ、ランダムアクセスメモリ(RAM)、および/または、読取り専用メモリ(ROM)もしくはフラッシュメモリ(フラッシュRAM)などの不揮発性メモリを含む、様々な形態であり得る。これらのメモリは、コンピュータ可読媒体の例である。

【0199】

コンピュータ可読媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータなどの情報を記憶するための任意の方法または技術において実装された、揮発性および不揮発性、リムーバブルおよび非リムーバブル媒体を含む。コンピュータ記憶媒体の例には、限定はしないが、相変化ランダムアクセスメモリ(PRAM)、スタティックランダムアクセスメモリ(SRAM)、ダイナミックランダムアクセスメモリ(DRAM)もしくは他のタイプのランダムアクセスメモリ(RAM)、読取り専用メモリ(ROM)、電気的消去可能プログラマブル読取り専用メモリ(EEPROM)、フラッシュメモリもしくは他のメモリ技術、コンパクトディスク読取り専用メモリ(CD-ROM)、デジタル多用途ディスク(DVD)もしくは他の光ストレージ、磁気テープカセット、磁気ディスク、量子メモリ、グラフェンベースの記憶媒体もしくは他の磁気記憶デバイス、または、コンピューティング機器によって情報を記憶するために使用され、アクセスされ得る任意の他の非一時的媒体が含まれる。本明細書で使用する場合、コンピュータ可読媒体は、被変調データ信号および搬送波など、一時的コンピュータ可読媒体を含まない。

【0200】

また、「備える(comprise)」、「含む(include)」という用語、およびそれらの任意の変形態は、非排他的包含をカバーするものであり、要素の列挙を備えるプロセス、方法、物品、または装置が、必ずしもそれらの要素に限定されず、明確に列挙されていないか、またはそのようなプロセス、方法、物品、もしくは装置に固有ではない他の要素を含み得るようになることにも留意されたい。「...を備える」の前に来る要素は、さらなる制約なしに、その要素を備えるプロセス、方法、物品、または装置における追加の同等の要素の存在を排除するものではない。

【0201】

本明細書の特定の実施形態について上記で説明したが、添付の特許請求の範囲の範囲内の他の実施形態もある。場合によっては、特許請求の範囲に記載されているアクションまたはステップは、実施形態内とは異なる順序で実行されるが、なお、望ましい結果を達成することが可能である。加えて、添付の図面に図示されたプロセスは、望ましい結果を達成するために、必ずしも図示の特定の順序、または順番を必要としない。いくつかの実装形態では、マルチタスキングおよび並列処理が実現可能または有利であり得る。

【0202】

本明細書で説明する1つまたは複数の実施形態で使用する用語は、特定の実施形態を例示するためのものにすぎず、本明細書で説明する1つまたは複数の実施形態を限定するものではない。本明細書で説明する1つまたは複数の実施形態において、ならびに特許請求の範囲において使用する場合、単数形の「1つの(a)」、「1つの(an)」、および「その(the)」は、文脈によって別段に明確に示されていない限り、複数形を同様に含むものとする。さらに、本明細書で使用する「および/または(and/or)」という用語は、関連する列挙された項目のうちの1つまたは複数のあらゆる組合せを含むことを理解されたい。

【0203】

「第1の(first)」、「第2の(second)」、「第3の(third)」などの用語は、本明細書で説明する1つまたは複数の実施形態において、様々なタイプの情報を説明するために使用され得るが、そのような情報がこれらの用語に限定されないことを理解されたい。これらの用語は、同じタイプの情報の間で区別するためにのみ役立つ。たとえば、本発明の範囲から逸脱することなく、「第1の情報」は「第2の情報」と呼ばれることもある。同様に、「第2の情報」は「第1の情報」と呼ばれることもある。文脈に応じて、本明細書で使用する「場合(if)」という用語は、「とき(when)」、「すると(upon)」、または「...決定に応答して(in response to determination ...)」と解釈され得る。

【0204】

上記で提示したものは、本明細書で説明する1つまたは複数の実施形態の好ましい実装形態にすぎず、いかなる意味においても、本明細書で説明する1つまたは複数の実施形態を限定するものではない。本明細書で説明する1つまたは複数の実施形態の趣旨および原理から逸脱することなく行われるあらゆる変更、均等な代替物、改変などは、すべて本明細書で説明する1つまたは複数の実施形態の範囲内に包含されるものである。

【符号の説明】

【0205】

31 サーバ
32 ネットワーク
33、34 モバイルフォン
35 PC
700 アクティビティ作成インターフェース
800、900 アクティビティ提示インターフェース
1000 通知表示インターフェース
1100 返金詳細説明インターフェース
1202、1402 プロセッサ
1204、1404 内部バス
1206、1406 ネットワークインターフェース
1208、1408 メモリ
1210、1410 不揮発性記憶デバイス
1301、1501 受信ユニット
1302 第1のトリガリングユニット
1303 処理ユニット
1304 調整ユニット
1305 第2のトリガリングユニット
1306 第3のトリガリングユニット
1502 トリガリングユニット
1503 第1の処理ユニット
1504 第2の処理ユニット

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】