JP2018503176A - データサービスの処理 - Google Patents

Abstract

データサービスを処理する例示的な方法は、以下の操作を含む。第１のユーザによって第２のユーザに開始され、データサービスのサービス限度額をもたらすデータサービス要求を取得し、データサービス要求に従って第２のユーザによって採用されたデータソースリストを取得し、データソースリストに従ってサービス限度額のための資金額を第１のユーザに対応する第１の口座に移動する。本開示の技術的解決策は、データソースリストに従って第１のユーザに対応する第１の口座にサービス限度額を移動し、不十分な単一データソースによって引き起こされるデータサービスの中断を回避し、これによりデータサービスを促進し、データサービスのサービス品質を向上させる。

Description

（関連する特許出願の相互参照）
本出願は、その全体を参照することにより本出願に含まれる、２０１４年１２月１８日に出願された、「Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ｐｒｏｃｅｓｓｉｎｇ Ｄａｔａ Ｓｅｒｖｉｃｅ（データサービスを処理する方法及び装置）」と題される中国特許出願第２０１４１０８００４２４．６号の外国優先権を主張する。

本開示は、インターネット技術分野に関し、より詳細には、データサービスを処理する方法及び装置に関する。

オンラインショッピングの普及率が高まるにつれて、買い手と売り手は、インターネットオペレータによって提供されるネットワークプラットフォーム上で商品と現金を交換する。商品を受け取った後、買い手が商品にいくつかの問題を見つけた場合、買い手は売り手に払い戻しを要求する場合が多い。ネットワークの安全な取引では、売り手に現金がまだ支払われていない場合、売り手の担保付口座の現金は買い手に払い戻される。さらに、現金が既に売り手に支払われており、買い手が払い戻しを求めた場合、買い手に払い戻すために売り手の口座に十分な現金があるという保証メカニズムが必要である。

従来の技術では、売り手は購入者への払い戻しのために独占的に使用される一定の金額、すなわち保証金を入金するように求められている。買い手に正常な払い戻しを保証するためには、売り手に十分な保証金があることを保証する必要がある。保証金は本質的に売り手の資金に属しているため、十分な資金を常に維持することは困難である。さらに、保証金は売り手の資金を占有し、払い戻しが売り手の資金流動性に影響を与えるため、そのような保証金を買い手に返却する。従来の技術では買い手への払い戻しのための単一のソースしかないため、異なる資金源間の交換可能性はない。

本概要は、以下の発明を実施するための形態でさらに説明する概念の選択を簡略化した形で紹介するために提供される。本概要は、請求された主題のすべての重要な特徴または基本的な特徴を特定することを意図するものではなく、請求される主題の範囲を決定する助けとして単独で使用されることも意図していない。例えば、用語「ｔｅｃｈｎｉｑｕｅ（ｓ） ｏｒ ｔｅｃｈｎｉｃａｌ ｓｏｌｕｔｉｏｎ（ｓ）（技術（複数可）または技術的解決策（複数可））」は、上記の文脈によって、本開示にわたって許容される装置（複数可）、システム（複数可）、方法（複数可）及び／またはコンピュータ可読命令を指す場合がある。

上記を考慮して、本開示は、新しい技術的解決策を提供し、単一のデータソースによるデータサービス中断を引き起こす技術的問題を解決するために適用可能である。

上記の目的を達成するために、本発明は以下の技術的解決策を提供する。
本開示の第１の態様に基づき、本開示は、データサービスを処理する方法を提供し、それは次のものを備える以下の操作を含んでもよい。
第１のユーザによって第２のユーザに開始され、データサービスのサービス限度額をもたらすデータサービス要求を取得し、
データサービス要求に従って第２のユーザによって採用されたデータソースリストを取得し、そして
データソースリストに従って第１のユーザに対応する第１の口座にサービス限度額のための資金額を移動する。

本開示の第２の態様に基づき、本開示は、以下のモジュールを含んでもよいデータサービスを処理する装置を提供する。
第１のユーザによって第２のユーザに開始され、データサービスのサービス限度額をもたらすデータサービス要求を取得する第１の取得モジュールと、
第１の取得モジュールにより取得されたデータサービス要求に従って、第２のユーザが採用したデータソースリストを取得する第２の取得モジュールと、そして
第２の取得モジュールによって取得されたデータソースリストに従って、サービス限度額のための資金額を第１のユーザに対応する第１の口座に移動する移動モジュールと、を含む。

上記の技術的解決策からわかるように、本開示は、データソースリストに従って第１のユーザに対応する第１の口座に限度額内の資金額を移動し、不十分な単一データソースによって引き起こされるデータサービスの中断を回避し、データサービスを促進し、データサービスのサービス品質を向上させる。

本開示の例示的な実施形態に基づいてデータサービスを処理する例示的な方法の概略フローチャートを示す。 本開示の別の例示的な実施形態に基づいてデータサービスを処理する例示的な方法の概略フローチャートを示す。 本開示の別の例示的な実施形態に基づいて例示的なデータソースリストの概略図を示す。 本開示の例示的な実施形態に基づいて例示的なサーバの構造概略図を示す。 本開示の例示的な実施形態に基づいてデータサービスを処理する例示的な装置の構造概略図を示す。 本開示の別の例示的な実施形態に基づいてデータサービスを処理する例示的な装置の構造概略図を示す。

例示的な実施形態を本明細書で詳細に説明し、例を添付図面に示す。以下の説明が添付図面を含む場合、他に示されない限り、異なる図面における同じ番号は、同じまたは同様の要素を表す。以下の例示的実施形態に記載された実施態様は、本開示と一致する実施態様のすべてを表すものではない。むしろ、それらは、請求の範囲において請求される本開示のいくつかの態様と一致する装置及び方法の単なる例である。

本開示で使用される用語は、特定の実施形態のみを説明するためのものであり、本開示を制限するものではない。本開示及び添付の請求の範囲で使用される単数形「ａ」、「ａｎ」及び「ｔｈｅ」は、文脈上他に明白に別途示されていない限り、複数形も含むことが意図される。本明細書で使用される「ａｎｄ／ｏｒ（及び／または）」という用語は、言及されている１つまたは複数の関連する項目の可能な組合せのいずれかまたはすべてを特定し、含むことがさらに理解される。

本開示は、様々な種類の情報を記載するために第１、第２、第３などの用語を使用することができるが、そのような情報はそれに限定されないことを理解しなければならない。それらの用語は、同じタイプの情報を区別するためだけに使用される。例えば、本開示の範囲から逸脱することなく、第１の情報を第２の情報とさらに呼んでもよく、同様に、第２の情報を第１の情報と呼んでもよい。特定の言語の文脈に応じて、本明細書で使用される「Ｉｆ」（もし）は、「ｗｈｅｎ（場合）」、「ｉｎ ｔｈｅ ｃａｓｅ ｔｈａｔ（その場合に）」、または「ｉｎ ｒｅｓｐｏｎｓｅ ｔｏ ｄｅｔｅｒｍｉｎｉｎｇ ｔｈａｔ（その判断に応答して）」と解釈されてもよい。

本開示は、第１のユーザによって第２のユーザに開始されたデータサービス要求を取得し、データサービス要求に従って第２のユーザによって採用されたデータソースリストを取得し、データソースリストに従って第１のユーザに対応する第２の口座にサービス限度額のための資金額を移動し、データソースの多様性を保証し、単一のデータソースによって引き起こされるデータサービスの中断を回避する。本開示をさらに説明するために、以下の例示的な実施形態が提供される。

図１を参照すると、図１は、本開示の例示的な実施形態に基づくデータサービスを処理する例示的な方法を示し、それはサーバに適用することができ、以下の操作を含んでもよい。

１０２において、第１のユーザによって第２のユーザに開始されたデータサービス要求が取得される。データサービス要求は、データサービスのサービス限度額をもたらす。

例えば、第１のユーザは、電子商取引（Ｅコマース）プラットフォームの買い手であってもよく、第２のユーザは、Ｅコマースプラットフォームの売り手であってもよい。この場合、データサービス要求は、買い手がオンラインショッピング後に商品を返品する場合に、買い手によって売り手に開始された払い戻し要求であってもよい。第１のユーザはさらに、物流会社であってもよく、第２のユーザは、Ｅコマースプラットフォームの売り手であってもよい。この場合、データサービス要求は、物流会社によって売り手に開始された物流貨物を差し引く要求であってもよい。第１のユーザはまた、売り手であってもよく、第２のユーザは買い手であってもよい。買い手が定期的に売り手に支払いをしたり、売り手に返済したりする場合、データサービス要求は、第１のユーザが、買い手に対応する限度額の現金の合計を支払うように求める要求であってもよい。データサービス要求はサービスラベルを搬送し、サービスラベルを使用することによって、買い手が、売り手から払い戻しを要求し、物流会社が売り手に物流貨物を差し引くように要求し、または売り手が買い手に定期的に支払いを行うように要求するなどのデータサービスが識別される。

１０４において、データサービス要求に従って第２のユーザによって採用されたデータソースリストが取得される。

この例示的な実施形態では、データソースリストは、Ｅコマースプラットフォームで第２のユーザによって記憶された口座残高（口座残高は、ユーザによって自由に使用されるユーザ口座内の資金額に属する）と、第２のユーザの口座に記憶されているが、Ｅコマースプラットフォームによって凍結され、自由に引き出されるのではなく特定のサービスでのみ使用されるＥコマースプラットフォームに第２のユーザによって提供される保証金と、第三者からの第三者資金提供（例えば、銀行システム）（第三者から提供された口座に記憶され、第三者との間で関連契約に署名することを要求する）を含み、そこにおいて第三者が支払った資金額はＥコマースプラットフォームを通じて取得され、そのような第三者資金提供は第二のユーザに利用料金を支払うことを要求し、第三者と契約を結んでいるユーザには資金が提供される場合がある。したがって、第２のユーザによって採用されたデータソースリストは、第２のユーザの実際の状況に従って決定することができ、上記の１つまたは複数の例あるいはそれらの任意の組み合わせを含んでもよい。この例示的な実施形態では、ユーザは、買い手または売り手のいずれかであってもよく、特定の状況に従って決定されてもよい。具体的には、残高、保証金、第三者資金提供などのデータソースリスト内の資金額は、サーバに記憶された対応する口座の資金データであってよく、それは口座資金の形式で記憶されてもよい。確かに、資金額データは、独立したデータベースに記憶されてもよいし、あるいは異なるデータベースに記憶されてもよく、本開示の例示的な実施形態では特に限定されない。

１０６において、サービス限度額のための資金額は、データソースリストに従って、第１のユーザに対応する第１の口座に移動される。

この例示的な実施形態では、異なるユーザが異なる残高、異なる保証金を有し、第三者と異なる契約を締結しているため、異なるユーザのデータソースリストにおいて、各データソースも異なり、データソースリストにおける各データソースは、異なる限度額がある。したがって、データソースリストを使用して各データソースを最大限に調整することによって、さまざまなデータサービス要求の要件が満たされる。

上記の例示的な実施形態からわかるように、本開示は、データソースリストに従って、第１のユーザに対応する第１の口座にサービス限度額を移動し、単一のデータソースによって引き起こされるデータサービスの中断を回避し、さらに、データサービスを促進し、データサービスのサービス品質を向上させる。

図２Ａを参照すると、それは、本開示の別の例示的な実施形態に基づいてデータサービスを処理する別の例示的な方法の概略フローチャートである。例示的に、第１のユーザが第２のユーザに払い戻しを要求する場合、この方法は以下の操作を含む。

２０２において、第１のユーザによって第２のユーザに開始されたデータサービス要求が取得される。データサービス要求は、第２のユーザ用の払い戻し限度額をもたらす。

２０２の詳細な説明については、１０２の関連する説明を参照することができ、これ以上説明されない。

２０４において、第２のユーザによって採用されたデータソースリストが、データサービス要求に従って取得される。

この例示的な実施形態では、第２のユーザがＥコマースプラットフォームに基づく売り手である場合、売り手のデータソースリストは、Ｅコマースプラットフォームにおける売り手の口座残高、Ｅコマースプラットフォームに提供される保証金、売り手と第三者（例えば、銀行やＥコマースプラットフォーム）との間の契約に基づく資金額を含んでもよい。別の実施形態では、売り手は第三者との如何なる資金提供契約にも署名しない場合がある。この場合、データソースリストは、Ｅコマースプラットフォーム内の売り手の口座残高と、Ｅコマースプラットフォームに提供された保証金とを含んでもよい。

２０６において、データソースリスト内の各データソースの制限パラメータ情報が決定される。

この例示的な実施形態では、制限パラメータ情報は、少なくとも、現行限度額、最大支払い限度額、各データソース用の予備限度額などを含む。例えば、図２Ｂに示すように、売り手のデータソースリストには、資金源１ ２１４、資金源２ ２２０、資金源３ ２２２が含まれていると判断される。例えば、資金源１、資金源２、資金源３の額は、売り手の口座残高、Ｅコマースプラットフォームに提供された保証金、及びそれぞれ売り手と第三者（例えば、銀行またはＥコマースプラットフォーム）との間の合意に基づく資金額である。例えば、口座残高の現行限度額は４００元である。Ｅコマースプラットフォームに提供される保証金は１０００元であり、保証金の予備限度額は５００元である。第三者と締結した契約に基づく資金額の上限は１０００元であり、第三者用の現行限度額は２０００元である。

２０８において、各データソースの制限パラメータ情報に従って各データソースからの支払い用のデータ限度額が決定される。

データソースリストでは、売り手の口座残高に上限がない場合がある。ただし、保証金はユーザに属するが、凍結されているため、指定されたデータサービスのみが保証金を使用してもよい。さらに、保証金の使用は、売り手とＥコマースプラットフォームプロバイダとの間の契約を遵守する必要がある。第三者からの資金額は第三者に属するため、第三者と売り手との間の契約に基づいている必要があり、指定されたデータサービスでのみ使用することができる。例えば、売り手とＥコマースプラットフォームプロバイダとの間の契約において、少なくとも１０００元の保証金を前払いしなければならないと定められており、５００元以下を売り手が自由に使用することができる（すなわち、保証金の予備限度額は５００元である）。資金額に関しては、売り手と第三者との間で、第三者資金提供の上限が５００元であることが合意されている。例えば、払い戻し限度額は２０００元であり、２０６で決定された口座残高の現行限度額は４００元であり、保証金の自由に使える限度額は５００元であり、第三者資金提供の限度額は１０００元である。したがって、買い手の限度額は４００＋５００＋１０００＝１９００元である。この場合、２０２において、買い手によって売り手に要求された払い戻し限度額が３００元であると決定された場合、３００元が売り手の口座残高から直接支払われる。払い戻し限度額が５００元の場合は、最初に売り手の口座残高から４００元が差し引かれ、次いで１００元が売り手の保証金から差し引かれる。払い戻し限度額が１０００元の場合、最初に売り手の口座残高から４００元が差し引かれ、次いで、売り手の保証金から５００元が差し引かれ、最後に１００元が第三者から支払われ、それによって払い戻し限度額が１０００元に達する。この例示的な実施形態における控除シーケンスは、例えば、最初に第三者資金提供、次に保証金、そして最後にユーザの口座残高などの設定された順序で実行されてもよい。

２１０において、データ限度額のための資金額は、各データソースから支払うためのデータ限度額に従って、第１のユーザに対応する第１の口座に移動される。

例示的な実施形態では、各データソースから支払われたデータ限度額は中間口座に移動され、データ限度額用の資金額は中間口座を介して第１のユーザに対応する第１の口座に移動され、移動された資金額は、第２の利用者によって他の目的、すなわち特定の目的のための特定の資金として使用されないことを保証する。さらに、中間口座は、Ｅコマースプラットフォーム上に設定された口座であってもよい。例えば、２０８での操作により、データソースリストを使用して買い手に十分な払い戻し限度額が提供されたと判断された場合、１０００元の払い戻し限度額が買い手の口座に移動される。図２Ｂに示すように、第１のユーザは、複数の買い手（例えば、買い手１及び買い手２）であってもよい。複数の買い手が同じ売り手に要求した場合、上記と同様の方法を採用して各買い手の払い戻し限度額を決定する。

この例示的な実施形態では、説明のために、データソースリストを使用して、売り手の資金源を説明する。売り手の資金源は、売り手とＥコマースプラットフォームプロバイダと第三者との間で締結された異なる契約に依存するため、売り手の資金源には異なる限度額がある。したがって、資金源の額のリストを使用して各データソースを最大限に調整することによって、買い手の払い戻しサービスが保証され、払い戻し中の買い手に対するサービス品質が向上する。

上述した例示的な実施形態に基づいて、方法は以下の操作をさらに含んでもよい。

データソースリストに従って決定された支払い限度額がサービス限度額未満の場合、データサービス失敗の指示メッセージが第１のユーザに送信される。

例えば、買い手は売り手に２０００元の払い戻しを要求する。しかし、売り手の口座残高は２００元であり、自由に使える保証金の限度額は５００元で、第三者の現行口座は１０００元である。この場合、支払い限度額は２００＋５００＋１０００＝１７００元であり、これは２０００元の払い戻し限度額よりも小さい。買い手にデータサービス失敗の指示メッセージを返す必要がある。このような指示メッセージは、売り手が払い戻し限度額を買い手に支払うことができるまで待つように買い手に通知し、データサービス要求は再び開始される。

さらに図２Ｂを参照すると、買い手が売り手２１２に払い戻しを要求するシナリオでは、買い手が売り手から支払うことを要求する「ｓｅｒｖｉｃｅ ｌｉｍｉｔ（サービス限度額）」が費用額ａである。費用額ａが不履行によって、売り手の残高口座から生じた場合、売り手の残高口座が十分であれば、売り手に払い戻しを要求する買い手の操作は正常に行われる。また売り手の残高勘定が不十分な場合は、他の資金源を試す必要がある。例えば、資金源が資金源１ ２１４から「Ｔｒａｎｓｆｅｒ−ｏｕｔ ｆｕｎｄ（支払い資金）」２１６に支払われた後、そのような資金額を中間口座２１８に移動して、資金額が他の目的、すなわち特定の目的のための特定資金用に売り手２１２によって使用されないことを保証してよい。この時点で、データソースリストが取得される。代替的に、「Ｆｕｎｄ Ｓｏｕｒｃｅ１（資金源１）」２１４は、「Ｔｒａｎｓｆｅｒ−ｏｕｔ ｆｕｎｄ（支払い資金）」２１６においてさらに凍結されてもよい。これに対応して、資金源１ ２１４、資金源２ ２２０、資金源３ ２２２からの資金額は、対応する制限パラメータ情報によって制限される。制限パラメータ情報には、例えば、最小額、最大額、割当、特定通貨などが含まれる。さらに、資金源からの資金額が十分であっても、資金を支払う操作は、依然として買い手の実際の要件に従って決定されてもよい。資金源リストのあらゆる資金源が要件を満たせない場合、別の資金源が発生する場合がある。すべての資金源の合計限度額が依然としてサービス限度額を満たせない場合、それに応じてサービス要求が失敗する。図２Ｂに示すように、買い手１ ２２４（１）及び買い手２ ２２４（２）など複数の買い手が存在する可能性がある。

物流会社が売り手に物流貨物の支払いを要求し、売り手が買い手に定期的な支払いを要求するシナリオの具体的な実施態様については、買い手が売り手に払い戻しを要求する上記のシナリオを参照することができ、本明細書ではこれ以上説明しない。

データサービスを処理する方法に対応して、本開示は図３に示されるように、本開示の例示的な実施形態に基づく例示的なサーバの構造概略図をさらに提供する。図３を参照すると、ハードウェアの観点から、サーバ３００は、プロセッサ３０２、内部バス３０４、ネットワークインタフェース３０６、内部メモリ３０８、及び不揮発性メモリ（ＮＶＭ）３１０を含んでもよい。

内部メモリ３０８及びＮＶＭ３１０は、メモリまたはコンピュータ可読媒体の例である。本明細書で定義されるように、コンピュータ可読媒体は、変調データ信号及び搬送波などの一時媒体を含まない。

サーバ３００は、（図３に示されている）入力及び出力インタフェースなどの他のサービスによって必要とされるハードウェアも含んでもよい。プロセッサ３０２は、対応するコンピュータ実行可能命令またはコンピュータプログラムをＮＶＭ３１０から内部メモリ３０８に読み込んだ後、コンピュータ実行可能命令またはコンピュータプログラムを実行することにより、論理レベルでデータサービス３１２を処理する装置を形成してよい。確かに、ソフトウェア実施態様に加えて、本開示は、他の形式の実施態様、例えば、論理デバイスまたはソフトウェアとハードウェアの組み合わせなども含んでもよい。すなわち、処理操作を実行するエンティティは、論理ユニットに限定されず、ハードウェアまたは論理デバイスであってもよい。

図４を参照すると、ソフトウェアの実行に関して、データサービスを処理する例示的な装置３１２は、第１の取得モジュール４０２、第２の取得モジュール４０４、及び移動モジュール４０６を含んでもよい。

第１の取得モジュール４０２は、第１のユーザによって第２のユーザに開始されるデータサービスのサービス限度額をもたらすデータサービス要求を取得する。第２の取得モジュール４０４は、第１の取得モジュール４０２が取得したデータサービス要求に応じて、第２のユーザが採用したデータソースリストを取得する。移動モジュール４０６は、サービス限度額のための資金額を、第２の取得モジュール４０４によって取得されたデータソースリストに従って、第１のユーザに対応する第１の口座に移動する。

図５を参照すると、例えば、第２の取得モジュール４０４は、以下のユニットを含んでもよい。
データサービス要求に応じてデータサービスのタイプを決定する第１の決定部５０２と、
データサービスのタイプに応じて第２のユーザが採用するデータソースリストを決定する第２の決定部５０４。

例えば、移動モジュール４０６は、以下のユニットを含んでもよい。
データソースリスト内の各データソースの制限パラメータ情報を決定する第３の決定部５０６と、
第３の決定部５０６によって決定された各データソースの制限パラメータ情報に基づいて、各データソースから支払われるデータ限度額を決定する第４の決定部５０８と、
第４の決定部さらに５０８によって決定される各データソースから支払われるデータの限度額に応じて第１のユーザに対応する第１の口座へデータ限度額のための資金額を移動する移動部５１０。さらに移動部５１０は、各データソースから支払われたデータ限度額を中間口座に移動する受入補助部（図５には図示せず）と、中間口座を介して第１のユーザに対応する第１の口座にデータ限度額用の資金額を移動する支払い補助部（図５では図示せず）とを含んでもよい。

任意に、制限パラメータ情報は、現行限度額、最大支払い限度額、及び各データソースの予備限度額を含んでもよい。

第４の決定ユニット５０８は、以下の補助部を含んでもよい。
データソースリストの各データソース内の現行限度額と対応する最大支払い限度額との間のサイズ関係を決定する第１の決定補助部５１２と、
第１の決定補助部５１２が、現行限度額は最大支払い限度額未満であると判定した場合には、現行限度額と予備限度額との差に対応する限度額を第１の口座に支払うことを決定する第２の決定部５１４。

さらに、第２の取得モジュール４０４によって取得されたデータソースリストに従って決定された支払い限度額が、第１の取得モジュール４０２によって取得されたサービス限度額未満である場合、装置３１２は、データサービス失敗の指示メッセージを第１のユーザに送信する送信モジュール５１６をさらに含んでもよい。

したがって、本発明では、移動モジュール４０６は、第２の取得部４０４が取得したデータソースリストに基づいて、第１のユーザに対応する第１の口座にサービス限度額を移動し、不十分な単一データソースによって生じるデータサービスの中断を回避し、よってデータサービスを促進し、データサービスのサービス品質を向上させる。

用語「ｃｏｍｐｒｉｓｅ（備える）」、「ｉｎｃｌｕｄｅ（含む）」及びその変形は、非排他的な包含をカバーすることが意図されており、「ｉｎｃｌｕｄｉｎｇ ａ ｐｒｏｃｅｓｓ， ａ ｍｅｔｈｏｄ， ａｎ ａｒｔｉｃｌｅ ｏｒ ａ ｄｅｖｉｃｅ ｏｆ ａ ｓｅｒｉｅｓ ｏｆ ｅｌｅｍｅｎｔｓ（一連の要素のプロセス、方法、物品または装置を含む）」という表現は、これらの要素を含むだけでなく、明示的に列挙されていない他の要素を含むか、またはプロセス、方法、物品または装置の固有の要素をさらに備える。さらに限定することなく、「ｉｎｃｌｕｄｉｎｇ ａ．．．（１つの．．．を含む）」という文によって定義される要素は、要素のプロセス、方法、物品または装置において追加の同一要素を排除するものではない。

上記の説明は、本開示の単なる例示的な実施形態であり、本開示を制限するものではない。本開示の趣旨及び原理を用いてなされた任意の修正、同等の置換、改善などは、本開示の範囲に含まれるべきである。

Claims (20)

1. 第１のユーザによって第２のユーザに開始され、データサービスのサービス限度額をもたらすデータサービス要求を取得し、
   前記データサービス要求に従って前記第２のユーザによって採用されたデータソースリストを取得し、
   前記データソースリストに従って、前記第１のユーザに対応する第１の口座に前記サービス限度額のための資金額を移動する、
   ことを含む方法。
2. 前記データサービス要求に従って前記第２のユーザによって採用された前記データソースリストを取得することは、
   前記データサービス要求に従って前記データサービスのタイプを決定し、
   前記データサービスの前記タイプに従って前記第２のユーザによって採用された前記データソースリストを決定する、
   ことを含む、請求項１に記載の方法。
3. 前記データソースリストに従って前記第１のユーザに対応する前記第１の口座に前記サービス限度額のための前記資金額を移動することは、
   前記データソースリスト内の各データソースの制限パラメータ情報を決定し、
   前記各データソースの前記制限パラメータ情報に従って、前記各データソースから支払われるデータ限度額を決定し、
   前記各データソースから支払われた前記データ限度額に従って前記第１のユーザに対応する前記第１の口座に、前記データ限度額のための前記資金額を移動する、
   ことを含む、請求項１に記載の方法。
4. 前記制限パラメータ情報は、
   前記各データソースの現行限度額と、
   前記各データソースの最大支払い限度額と、
   前記各データソースの予備限度額と、
   を含む、請求項３に記載の方法。
5. 前記各データソースの前記制限パラメータ情報に従って前記各データソースから支払われる前記データ限度額を決定することは、
   前記各データソースの前記現行限度額と前記各データソースの前記最大支払い限度額との間のサイズ関係を決定し、
   前記現行限度額が前記最大支払い限度額未満であると判定したことに応答して、前記現行限度額と前記予備限度額との間の差に対応する限度額を前記第１の口座に移動する、
   請求項４に記載の方法。
6. 前記各データソースから支払われた前記データ限度額に従って、前記データ限度額のための前記資金額を、前記第１のユーザに対応する前記第１の口座に移動することは、
   前記各データソースから支払われた前記各データ限度額を中間口座に移動し、
   前記中間口座を介して前記第１のユーザに対応する前記第１の口座に、前記データ限度額のための前記資金額を移動する、
   ことを含む、請求項４に記載の方法。
7. 前記データソースリストに従って決定された支払い限度額が、前記サービス限度額未満であると判定することに応答して、データサービス失敗の指示メッセージを前記第１のユーザに送信すること、
   をさらに含む、請求項１に記載の方法。
8. 第１のユーザによって第２のユーザに開始され、データサービスのサービス限度額をもたらすデータサービス要求を取得する第１の取得モジュールと、
   前記データサービス要求に従って前記第２のユーザによって採用されたデータソースリストを取得する第２の取得モジュールと、
   前記データソースリストに従って、前記第１のユーザに対応する第１の口座に前記サービス限度額のための資金額を移動する移動モジュールと、
   を含むサーバ。
9. 前記第２の取得モジュールは、
   前記データサービス要求に従って前記データサービスのタイプを決定する第１の決定部と、
   前記データサービスの前記タイプに従って前記第２のユーザが採用した前記データソースリストを決定する第２の決定部と、
   を含む、請求項８に記載のサーバ。
10. 前記移動モジュールは、
    前記データソースリスト内の前記各データソースの制限パラメータ情報を決定する第３の決定部と、
    前記各データソースの前記制限パラメータ情報に従って前記各データソースから支払われるデータ限度額を決定する第４の決定部と、
    前記各データソースから支払われた前記データ限度額に従って前記第１のユーザに対応する前記第１の口座に、前記データ限度額のための前記資金額を移動する移動部と、
    を含む、請求項８に記載のサーバ。
11. 前記制限パラメータ情報は、
    前記各データソースの現行限度額と、
    前記各データソースの最大支払い限度額と、
    前記各データソースの予備限度額と、
    を含む、請求項１０に記載のサーバ。
12. 前記第４の決定部は、
    前記各データソースの前記現行限度額と前記各データソースの前記最大支払い限度額との間のサイズ関係を決定する第１の決定補助部と、
    前記現行限度額が、前記最大支払い限度額未満であると判定したことに応答して、前記現行限度額と前記予備限度額との間の差に対応する限度額を前記第１の口座に移動する第２の決定補助部と、
    を含む、請求項１１に記載のサーバ。
13. 前記移動手段は、
    前記各データソースから支払われた前記各データ限度額を中間口座に移動する受入補助部と、
    前記中間口座を介して前記第１のユーザに対応する前記第１の口座に、前記データ限度額のための前記資金額を移動する支払い補助部と、
    を含む、請求項１１の記載に記載のサーバ。
14. 前記データソースリストに従って決定された前記支払い限度額が前記サービス限度額未満であると判定することに応答して、データサービス失敗の指示メッセージを前記第１のユーザに送信する送信モジュール、
    をさらに含む、請求項８に記載のサーバ。
15. 操作を実行するために１つまたは複数のプロセッサによって実行可能なコンピュータ実行可能命令が記憶された１つまたは複数のメモリであって、前記操作は、
    第１のユーザによって第２のユーザに開始されるデータサービスのサービス限度額をもたらすデータサービス要求を取得し、
    前記データサービス要求に従って前記第２のユーザによって採用されたデータソースリストを取得し、
    前記データソースリストに従って、前記第１のユーザに対応する第１の口座に前記サービス限度額のための資金額を移動することを含む、
    前記１つまたは複数のメモリ。
16. 前記データサービス要求に従って前記第２のユーザによって採用された前記データソースリストを取得することは、
    前記データサービス要求に従って前記データサービスのタイプを決定し、
    前記データサービスの前記タイプに従って前記第２のユーザによって採用された前記データソースリストを決定すること、
    を含む、請求項１５に記載の１つまたは複数のメモリ。
17. 前記データソースリストに従って前記サービス限度額のための前記資金額を前記第１のユーザに対応する前記第１の口座に移動することは、
    前記データソースリスト内の各データソースの前記制限パラメータ情報を決定し、
    前記各データソースの前記制限パラメータ情報に従って、前記各データソースから支払われるデータ限度額を決定し、
    前記各データソースから支払われた前記データ限度額に従って前記第１のユーザに対応する前記第１の口座に、前記データ限度額のための前記資金額を移動する、
    ことを含む、請求項１６に記載の１つまたは複数のメモリ。
18. 前記制限パラメータ情報は、
    前記各データソースの現行限度額と、
    前記各データソースの最大支払い限度額と、
    前記各データソースの予備限度額を含む、
    請求項１７に記載の１つまたは複数のメモリ。
19. 前記各データソースの前記制限パラメータ情報に従って前記各データソースから払われる前記データ限度額を決定することは、
    前記各データソースの前記現行限度額と前記各データソースの前記最大支払い限度額との間のサイズ関係を決定し、
    前記現行限度額が前記最大支払い限度額未満であると判定したことに応答して、前記現行限度額と前記予備限度額との間の差に対応する限度額を前記第１の口座に移動することを含む請求項１８に記載の１つまたは複数のメモリ。
20. 前記各データソースから支払われた前記データ限度額に従って、前記データ限度額のための前記資金額を、前記第１のユーザに対応する前記第１の口座に移動することは、
    前記各データソースから支払われた前記各データ限度額を前記中間口座に移動し、
    前記中間口座を介して前記第１のユーザに対応する前記第１の口座に、前記データ限度額のための前記資金額を移動する、
    ことを含む、請求項１８に記載の１つまたは複数のメモリ。