(58)【調査した分野】(Int.Cl.,DB名)
前記処理モジュールは、前記第一アカウントのアカウントレベルを判定し、且つ、アカウントレベルと余分なリソースとの間の予め設定された対応性関係に従って前記第一アカウントに対応する前記余分なリソースを判定するように構成される、請求項4に記載の装置。
【発明の概要】
【0006】
本出願の実施形態は、ビジネスリソースを処理する現時点の技術の手順が複雑であるという問題を解決するべく、リソース処理方法及び装置を提供している。
【0007】
本出願の一実施形態によるリソース処理方法は、端末によって送信された認証情報及びビジネスリソース量情報を受け取るステップであって、認証情報は、第一アカウントとの間の関連付け関係を有し、且つ、端末は、第二アカウントと
バインドされている、ステップと、認証情報と第一アカウントとの間の予め確立された関連付け関係に従って、認証情報に対応する第一アカウントを判定するステップと、ビジネスリソース量情報に従って、且つ、第一アカウントのビジネスリソースから、ビジネスリソース量情報に対応するビジネスリソースを取得し、且つ、取得されたビジネスリソースを第二アカウントに転送するステップと、を有する。
【0008】
本出願の一実施形態による別のリソース処理方法は、サーバが、認証情報と第一アカウントとの間の予め確立された関連付け情報に従って、認証情報に対応する第一アカウントを判定するようにするべく、端末により、認証情報及びビジネスリソース量情報をサーバに送信するステップと、
バインドされた第二アカウントを通じて端末により、サーバによって送信されると共にビジネスリソース量情報に対応するビジネスリソースを受け取るステップであって、ビジネスリソースは、ビジネスリソース量情報に従って第一アカウントのビジネスリソースからサーバによって取得される、ステップと、を有する。
【0009】
本出願の一実施形態による別のリソース処理方法は、端末により、認証情報を生成するための要求を受け取るステップと、サーバが、認証情報を生成するための要求に従って一意の認証情報を生成し、且つ、認証情報と第一アカウントとの間の関連付け関係を確立するようにするべく、認証情報を生成するための要求をサーバに送信するステップであって、認証情報と第一アカウントとの間の関連付け関係は、サーバが、第二アカウントと
バインドされた端末によって送信された認証情報に従って、認証情報に対応する第一アカウントを判定し、且つ、判定された第一アカウントのビジネスリソースから規定された量のビジネスリソースを取得するようにするべく、使用される、ステップと、を有する。
【0010】
本出願の一実施形態による別のリソース処理方法は、端末によって送信された資金認証情報及び金額情報を受け取るステップであって、資金認証情報は、第一アカウントとの間の関連付け情報を有し、且つ、端末は、第二アカウントと
バインドされている、ステップと、資金認証情報と第一アカウントとの間の予め確立された関連付け関係に従って、資金認証情報に対応する第一アカウントを判定するステップと、金額情報に従って、且つ、第一アカウントの資金から、金額情報に対応する資金を取得し、且つ、取得された資金を第二アカウントに転送するステップと、を有する。
【0011】
本出願の一実施形態による別のリソース処理方法は、端末によって送信された資金認証情報及び金額情報を受け取るステップであって、資金認証情報は、第一アカウントとの間の関連付け関係を有し、且つ、端末は、第二アカウントと
バインドされている、ステップと、資金認証情報と第一アカウントとの間の予め確立された関連付け関係に従って、資金認証情報に対応する第一アカウントを判定するステップと、金額情報に対応する資金金額が第一アカウントの資金金額を超過しているかどうかを判定するステップと、はいである場合に、第一アカウントに対応する信用資金を判定し、信用資金から金額情報に対応する資金を取得し、且つ、取得された資金を第二アカウントに転送し、或いは、第一アカウントの資金及び第一アカウントの判定された信用資金から金額情報に対応する資金を取得し、且つ、取得された資金を第二アカウントに転送するステップと、いいえである場合に、第一アカウントの資金から金額情報に対応する資金を取得し、且つ、取得された資金を第二アカウントに転送するステップと、を有する。
【0012】
本出願の一実施形態による別のリソース処理方法は、サーバが、資金認証情報と第一アカウントとの間の予め確立された関連付け関係に従って、資金認証情報に対応する第一アカウントを判定するようにするべく、端末により、資金認証情報及び金額情報をサーバに送信するステップと、
バインドされた第二アカウントを通じて端末により、サーバによって送信されると共に金額情報に対応する資金を受け取るステップであって、資金は、金額情報に従って第一アカウントの資金からサーバによって取得される、ステップと、を有する。
【0013】
本出願の一実施形態による別のリソース処理方法は、端末により、資金認証情報を生成するための要求を受け取るステップと、サーバが、資金認証情報を生成するための要求に従って一意の資金認証情報を生成し、且つ、資金認証情報と第一アカウントとの間の関連付け情報を確立するようにするべく、資金認証情報を生成するための要求をサーバに送信するステップであって、資金認証情報と第一アカウントとの間の関連付け関係は、サーバが、第二アカウントと
バインドされた端末によって送信された資金認証情報に従って、資金認証情報に対応する第一アカウントを判定し、且つ、第一アカウントの資金から規定された金額の資金を取得するようにするべく、使用される、ステップと、を有する。
【0014】
本出願の一実施形態によるリソース処理装置は、端末によって送信された認証情報及びビジネスリソース量情報を受け取るように構成された受信モジュールであって、認証情報は、第一アカウントとの間の関連付け関係を有し、且つ、端末は、第二アカウントと
バインドされている、受信モジュールと、認証情報と第一アカウントとの間の予め確立された関連付け関係に従って、認証情報に対応する第一アカウントを判定するように構成された判定モジュールと、ビジネスリソース量情報に従って、且つ、第一アカウントのビジネスリソースから、ビジネスリソース量情報に対応するビジネスリソースを取得し、且つ、取得されたビジネスリソースを第二アカウントに転送するように構成された処理モジュールと、を有する。
【0015】
本出願の一実施形態による別のリソース処理装置は、サーバが、認証情報と第一アカウントとの間の予め確立された関連付け関係に従って、認証情報に対応する第一アカウントを判定するようにするべく、認証情報及びビジネスリソース量情報をサーバに送信するように構成された送信モジュールと、端末と
バインドされた第二アカウントを通じて、サーバによって送信されると共にビジネスリソース量情報に対応するビジネスリソースを受け取るように構成された受信モジュールであって、ビジネスリソースは、ビジネスリソース量情報に従って第一アカウントのビジネスリソースからサーバによって取得される、受信モジュールと、を有する。
【0016】
本出願の一実施形態による別のリソース処理装置は、認証情報を生成するための要求を受け取るように構成された受信モジュールと、サーバが、認証情報を生成するための要求に従って一意の認証情報を生成し、且つ、認証情報と第一アカウントとの間の関連付け関係を確立するようにするべく、認証情報を生成するための要求をサーバに送信するように構成された送信モジュールであって、認証情報と第一アカウントとの間の関連付け関係は、サーバが、第二アカウントと
バインドされた端末によって送信される認証情報に従って、認証情報に対応する第一アカウントを判定し、且つ、判定された第一アカウントのビジネスリソースから規定された量のビジネスリソースを取得するようにするべく、使用される、送信モジュールと、を有する。
【0017】
本出願の一実施形態による別のリソース処理装置は、端末によって送信された資金認証情報及び金額情報を受け取るように構成された受信モジュールであって、資金認証情報は、第一アカウントとの間の関連付け関係を有し、且つ、端末は、第二アカウントと
バインドされている、受信モジュールと、資金認証情報と第一アカウントとの間の予め確立された関連付け関係に従って、資金認証情報に対応する第一アカウントを判定するように構成された判定モジュールと、金額情報に従って、且つ、第一アカウントの資金から、金額情報に対応する資金を取得し、且つ、取得された資金を第二アカウントに転送するように構成された処理モジュールと、を有する。
【0018】
本出願の一実施形態による別のリソース処理装置は、端末によって送信された資金認証情報及び金額情報を受け取るように構成された受信モジュールであって、資金認証情報は、第一アカウントとの間の関連付け情報を有し、且つ、端末は、第二アカウントと
バインドされている、受信モジュールと、資金認証情報と第一アカウントとの間の予め確立された関連付け関係に従って、資金認証情報に対応する第一アカウントを判定するように構成された判定モジュールと、金額情報に対応する資金金額が第一アカウントの資金金額を超過しているかどうかを判定し、はいである場合に、第一アカウントに対応する信用資金を判定し、信用資金から金額情報に対応する資金を取得し、且つ、取得された資金を第二アカウントに転送し、或いは、第一アカウントの資金及び第一アカウントの判定された信用資金から金額情報に対応する資金を取得し、且つ、取得された資金を第二アカウントに転送し、いいえである場合に、第一アカウントの資金から金額情報に対応する資金を取得し、且つ、取得された資金を第二アカウントに転送するように構成された処理モジュールと、を有する。
【0019】
本出願の一実施形態による別のリソース処理装置は、サーバが、資金認証情報と第一アカウントとの間の予め確立された関連付け関係に従って、資金認証情報に対応する第一アカウントを判定するようにするべく、資金認証情報及び金額情報をサーバに送信するように構成された送信モジュールと、端末と
バインドされた第二アカウントを通じて、サーバによって送信されると共に金額情報に対応する資金を受け取るように構成された受信モジュールであって、資金は、金額情報に従って第一アカウントの資金からサーバによって取得される、受信モジュールと、を有する。
【0020】
本出願の一実施形態による別のリソース処理装置は、資金認証情報を生成するための要求を受け取るように構成された受信モジュールと、サーバが、資金認証情報を生成するための要求に従って一意の資金認証情報を生成し、且つ、資金認証情報と第一アカウントとの間の関連付け関係を確立するようにするべく、資金認証情報を生成するための要求をサーバに送信するように構成された送信モジュールであって、資金認証情報と第一アカウントとの間の関連付け関係は、サーバが、第二アカウントと
バインドされた端末によって送信された資金認証情報に従って、資金認証情報に対応する第一アカウントを判定し、且つ、第一アカウントの資金から規定された金額の資金を取得するようにするべく、使用される、送信モジュールと、を有する。
【0021】
本出願の実施形態は、リソース処理方法及び装置を提供する。方法によれば、一適用シナリオにおいては、第一ユーザは、第一ユーザが第二ユーザからビジネスサービスを取得するプロセスにおいて端末装置を携帯する必要がなく、第二ユーザによって使用されると共に第二ユーザの独自の第二アカウントと
バインドされた端末を使用することのみが必要とされている。第一ユーザの独自の第一アカウントとの間の関連付け関係を有する認証情報及び対応するビジネスリソース量情報を入力することにより、対応するビジネスリソースの量を第二ユーザの第二アカウントに転送することができる。この結果、ビジネスリソースを異なるユーザの間において転送することが格段に便利となる。
【発明を実施するための形態】
【0024】
以下、本出願の目的、技術的解決策、及び利点について更に明らかにするべく、本出願の特定の実施形態及び添付の図面を参照し、本出願の技術的解決策について明瞭に且つ十分に説明することとする。記述されている実施形態は、本出願の実施形態の、すべてはなく、いくつかであるに過ぎないことが明らかである。本出願の実施形態に基づいて、且つ、発明の努力を伴うことなしに、当業者によって取得可能であるすべてのその他の実施形態は、本出願の範囲に含まれる。
【0025】
図1に示されているように、本出願の一実施形態によるリソース処理方法は、以下のステップを有する。
【0026】
S101:端末によって送信された認証情報及びビジネスリソース量情報を受け取る。
【0027】
ここで、認証情報は、第一アカウントとの間の関連付け関係を有し、且つ、端末は、第二アカウントと
バインドされている。
【0028】
本出願の一実施形態においては、端末は、モバイル端末又はコンピュータ端末であってもよく、第一アカウントは、第一ユーザ(即ち、上述の需要側ユーザ)のアカウントであってもよく、且つ、対応する方式により、第二アカウントは、第二ユーザ(即ち、上述の供給側ユーザ)のアカウントであってもよい。認証情報は、アカウント内のビジネスリソースの認証情報であってもよく、且つ、例えば、文字、数字、又は符号を有する文字ストリングであってもよい。ビジネスリソース量情報は、第一アカウントから第二アカウントに転送されるべきビジネスリソースの量を反映している。ビジネスリソースの対応する量が第一アカウントから第二アカウントに転送された際に、第一ユーザは、第二ユーザによって提供されるビジネスサービスを取得することができる。
【0029】
例えば、本出願の一実施形態におけるビジネスリソースは、アカウントに属すると共にオンラインドライブ上において保存されているデータファイル、人員グループ分け情報、及び要員管理アカウントに属する資金、並びに、これらに類似したものなどの、異なるアカウントの間において転送及び交換される能力を有する様々なリソースであってもよい。
【0030】
本出願の一実施形態による一適用シナリオにおいては、上述のステップS101との関係において、第一ユーザが認証情報及びビジネスリソース量情報を第二アカウントと
バインドされた端末に入力するものと見なすことができる。
【0031】
S102:認証情報と第一アカウントとの間の予め確立された関連付け関係に従って、認証情報に対応する第一アカウントを判定する。
【0032】
認証情報は、アカウント内のビジネスリソースの認証情報であることから、認証情報は、対応するアカウント(第一アカウント)内のビジネスリソースと関連付けられている。その結果、認証情報を通じて、認証情報との間の関連付け関係を有するアカウントを判定することができる。同様に、本出願の実施形態においては、認証情報を通じて、認証情報との間の関連付け関係を有する第一アカウントを判定することができる。
【0033】
対応する認証情報を通じて任意のアカウントを判定することが可能であり、且つ、従って、一つの認証情報片が一つのアカウントに一意に対応していることに留意されたい。即ち、認証情報は、一意である。
【0034】
S103:ビジネスリソース量情報に従って、第一アカウントのビジネスリソースから、ビジネスリソース量情報に対応するビジネスリソースを取得し、且つ、取得されたビジネスリソースを第二アカウントに転送する。
【0035】
上述のように、ビジネスリソース量情報は、ビジネスサービスを取得するべく必要とされるビジネスリソースの量を反映している一方で、アカウントは、通常、対応するビジネスリソースを含む。対応するアカウントが認証情報に従って判定された際に、ビジネスリソースの対応する量をアカウントから取得することができる。換言すれば、本出願の一実施形態による一適用シナリオにおいては、第一ユーザによって使用されるべきビジネスリソースの量をビジネスリソース量情報に従って判定することが可能であり、ビジネスリソースの対応する量を第一アカウントのビジネスリソースから取得することが可能であり、且つ、取得されたビジネスリソースを第二アカウントに転送することができる。
【0036】
本出願の実施形態における上述のプロセスは、(限定を伴うことなしに、ウェブサイト、銀行、通信事業者、及びこれらに類似したものを含む)サービスプロバイダのバックエンドサービスシステム内のサーバによって実行することができることに留意されたい。即ち、第一ユーザ及び第二ユーザは、いずれも、その個々のアカウント(即ち、第一アカウント及び第二アカウント)をサービスシステム内において登録しているが、これは、本出願に対する限定を構成するものではない。
【0037】
上述のステップは、一適用シナリオにおいては、第一ユーザが、第一ユーザが第二ユーザからビジネスサービスを取得するプロセスにおいて、端末装置を携帯する必要なく、第二ユーザによって使用されると共に第二ユーザの独自の第二アカウントと
バインドされた端末を使用することのみが必要とされているという点において、従来技術と異なっていることが明らかである。第一ユーザの独自の第一アカウントとの間の関連付け関係を有する認証情報及び対応するビジネスリソース量情報を入力することにより、対応する量のビジネスリソースを第二ユーザの第二アカウントに転送することができる。この結果、ビジネスリソースを異なるユーザの間において転送することが格段に便利になる。
【0038】
上述のように、第一ユーザが第二ユーザからビジネスサービスを取得するプロセスにおいて、第一ユーザは、認証情報を第二アカウントと
バインドされた端末に入力することのみが必要とされており、且つ、その結果、サーバは、認証情報に従って第一アカウントを一意に判定することが可能であり、且つ、第一アカウントのビジネスリソースから対応するビジネスリソースを取得することができる。換言すれば、認証情報と第一アカウントとの間の1対1の関連付け関係が事前に確立されており、且つ、この1対1の関連付け関係は、サーバが、認証情報に従って、任意のその他のアカウントではなく、第一アカウントのみを判定し得ることを保証している。
【0039】
本出願の一実施形態においては、認証情報と第一アカウントとの間の関連付け関係を予め確立するステップは、第一アカウントによって送信された認証情報を生成するための要求を受け取るステップと、受け取った認証情報を生成するための要求に従って一意の認証情報を生成するステップと、生成された認証情報と第一アカウントとの間の関連付け関係を確立するステップと、を有する。
【0040】
一例においては、実際的な一適用シナリオにおいては、第一ユーザは、グローバルに一意である認証情報を生成するようにサーバに対して要求するべく、事前に、その第一アカウントを介して要求を送信することができる。サーバが認証情報を生成する際に、第一アカウントとの間の関連付け情報が確立される。その結果、第一ユーザは、認証情報を直接的に使用することができる。
【0041】
又、認証情報がサーバによって生成される上述の方式に加えて、認証情報は、本出願の実施形態における一方式として、ユーザによって独立的に設定されることも可能である。異なるユーザが同一の認証情報を設定する可能性がある。この状況の発生を防止するべく、サーバは、ユーザによって独立的に設定された認証情報の一意性をチェックすることができる。例えば、ユーザAは、「aaa」という文字ストリングとなるように、認証情報を独立的に設定する。サーバは、「aaa」という文字ストリングの一意性をチェックする。「aaa」と同一であると見出される文字ストリングが存在していない際には、サーバは、「aaa」という文字ストリングをユーザAのアカウントと関連付けられた認証情報であると判定することができる。これは、本出願に対してなんらの制限をも課すものではない。
【0042】
更には、実際的な一用途においては、ユーザが、別のユーザからのビジネスサービスの取得のプロセスにおいて、認証情報を使用する場合に、認証情報の漏洩のリスクが存在している。認証情報が使用された後の漏洩のリスクを回避又は低減するべく、本出願の一実施形態における方法は、認証情報を生成した際に時間の計測を開始するステップと、計測された時間の長さが予め設定された長さに到達した際に、認証情報と第一アカウントとの間の関連付け関係を解消するステップと、を更に有する。
【0043】
換言すれば、認証情報は、有効期間を有する。即ち、認証情報は、予め設定された時間の長さの後に、無効となる。本出願の一実施形態においては、予め設定される長さは、12時間、24時間、及びこれらに類似したものであってもよく、これは、実際のニーズに従って設定することが可能であり、且つ、本出願に対する制限ではない。
【0044】
更には、実際的な一適用シナリオにおいては、ユーザが別のユーザからビジネスサービスを取得するプロセスにおいて、ビジネスリソース量情報に対応するビジネスリソースの量が、ユーザの独自のアカウントのビジネスリソースの量を超過している可能性がある。このようなケースにおいては、ビジネスサービスを取得するプロセスに失敗する場合があり、サービスプロバイダは、様々なアカウントについて、ある種の追加ビジネスリソースを提供することができる。本出願の一実施形態においては、追加ビジネスリソースは、余分なリソースと呼称することができる。従って、ユーザのアカウント内のビジネスリソースの量がビジネスリソース量情報に対応するビジネスリソースの量を下回っている際にも、サーバは、ユーザがビジネスサービスの取得のプロセスを完了させるように、そのアカウントの余分なリソースからビジネスリソースを取得することができる。
【0045】
これに基づいて、ビジネスリソース量情報に従って、且つ、第一アカウントのビジネスリソースから、ビジネスリソース量情報に対応するビジネスリソースを取得するステップは、ビジネスリソース量情報に対応するビジネスリソースの量が第一アカウントのビジネスリソースの量を超過しているかどうかを判定するステップと、はいである場合に、第一アカウントに対応する余分なリソースを判定し、且つ、余分なリソースからビジネスリソース量情報に対応するビジネスリソースを取得し、或いは、第一アカウントのビジネスリソース及び判定された余分なリソースからビジネスリソース量情報に対応するビジネスリソースを取得するステップと、いいえである場合に、第一アカウントのビジネスリソースからビジネスリソース量情報に対応するビジネスリソースを取得するステップと、を有する。
【0046】
一例においては、ビジネスリソース量情報に対応するビジネスリソースの量が第一アカウントのビジネスリソースの量を超過しているケースにおいては、サーバがビジネスリソースを取得する二つの方式が存在しており、第一の方法は、サーバが第一アカウントに対応する余分なリソースからビジネスリソース量情報に対応するビジネスリソースを取得するというものであり、第二の方式は、サーバが、まず、第一アカウントのすべてのビジネスリソースを取得し、且つ、次いで、取得されたビジネスリソースの量がビジネスリソース量情報に対応するビジネスリソースの量と等しくなるように、第一アカウントに対応する余分なリソースから残りのビジネスリソースを取得するというものである。
【0047】
ビジネスリソース量情報に対応するビジネスリソースの量が第一アカウントのビジネスリソースの量を超過していない場合には、ビジネスリソースの対応する量は、第一アカウントのビジネスリソースから直接的に取得することができる。
【0048】
例えば、ユーザAの第一アカウントA’内のビジネスリソースの量が2であると仮定した場合に、サーバは、10単位の余分なリソースを第一アカウントA’に対して割り当てる。同時に、ユーザAが別のユーザからビジネスサービスを取得するプロセスにおいて、ビジネスリソース量情報に対応するビジネスリソースの量が5であると仮定した場合に、ユーザAが認証情報及びビジネスリソース量情報を別のユーザの端末上において入力した際に、サーバは、まず、第一アカウントA’内において2単位のビジネスリソースを取得することになり、且つ、次いで、取得されたビジネスリソースの量が5となるように、第一アカウントA’の余分なリソースから3単位のビジネスリソースを取得することになろう。或いは、この代わりに、サーバは、第一アカウントA’の余分なリソースから5単位のビジネスリソースを直接的に取得することもできる。
【0049】
第一アカウントA’内のビジネスリソースの量がビジネスリソース量情報に対応するビジネスリソースの量を下回っていないケースにおいては、サーバは、第一アカウントA’のビジネスリソースから直接的にビジネスリソースを取得することが可能であり、これについての例を通じた説明は、本明細書においては、省略することとする。
【0050】
実際的な一用途においては、第一アカウントに対応する余分なリソースは、通常、そのアカウントのレベルと関係付けられている。換言すれば、サービスプロバイダは、通常、異なるレベルを有するアカウントに対して異なる量の余分なリソースを割り当てることになろう。従って、第一アカウントに対応する余分なリソースを判定するステップは、第一アカウントのアカウントレベルを判定するステップと、アカウントレベルと余分なリソースとの間の予め設定された対応性関係に従って第一アカウントに対応する余分なリソースを判定するステップと、を有する。
【0051】
本出願の実施形態における余分なリソースは、ユーザの独自のアカウント内のビジネスリソースではなく、サービスプロバイダによって提供されていることに留意されたい。余分なリソースは、ある種の信用リソースであるものと見なすことができる。従って、ユーザが余分なリソースを使用する際には、ユーザは、設定された期間の後に、使用された余分なリソースを返すことになる。本出願の実施形態における一方式として、サービスプロバイダは、設定された期間の後に、ユーザのアカウントから対応する量のビジネスリソースを差し引くことができる。これは、本出願に対してなんらの制限をも課すものではない。
【0052】
これに加えて、上述のプロセスが実際的な一適用シナリオにおいて実行された後に、サーバは、取得されたビジネスリソースを直接的に第二アカウントに転送してはいないことに留意されたい。通常、サーバは、取得されたビジネスリソースを第三者アカウント内において一時的に保存することになり、第一アカウント内のビジネスリソースの取得のそれぞれのプロセスに対応する詳細な情報を生成することになり、且つ、第一ユーザによる確認のために、第一アカウントを介して詳細な情報を第一ユーザに表示することになろう。即ち、本出願の一実施形態においては、第二アカウントに転送する前に、方法は、第一アカウントによって送信された確認命令を受け取るステップを更に有する。
【0053】
第一ユーザによる確認の理由は、第一ユーザの第一アカウントの認証情報を学習した後に、別のユーザが、第一ユーザが認知してはいない状態において、ビジネスリソースを、悪意を持って取得することを防止するという点にある。確認命令により、第一ユーザは、毎回、自身によって入力された認証情報を事実上識別することができる。認証情報が第一ユーザ自身によって入力されてはいないプロセスの場合には、第一ユーザは、第一アカウントを介して否認命令を送信することが可能であり、否認命令を受信した際に、サーバは、第一アカウントから取得されたビジネスリソースを第一アカウントに返すことになる。
【0054】
本出願の実施形態における一方式として、サーバが、設定された期間内において、第一アカウントによって送信された確認命令を受け取らない場合には、サーバは、第三者アカウント内において一時的に保存されているビジネスリソースを第二アカウントに転送することができる。ここで、設定される期間は、例えば、7日間、10日間、及びこれらに類似したものなどのように、実際のニーズに従って設定することが可能であり、これは、本出願に対する制限を構成するものではない。
【0055】
更には、本出願の実施形態における一方式として、第一ユーザが第一アカウントを介して否認命令を、悪意を持って送信することを防止するべく、第二ユーザは、第一ユーザが認証情報及びビジネスリソース量情報を入力したことを証明するべく、対応する証明情報を、第二アカウントを介してサービスプロバイダに対してファイリングすることが可能であり、これは、サービスプロバイダのバックエンドサービスシステムによって判定されることになる。これは、本出願に対してなんらの制限をも課すものではない。
【0056】
上述の説明は、サーバ側に基づいた実行プロセスである。実際的な一用途においては、本出願の一実施形態は、認証情報及びビジネスリソース量情報を送信する端末側用のリソース処理手順を更に提供している。
図2に示されているように、方法は、以下のステップを有する。
【0057】
S201:サーバが、認証情報と第一アカウントとの間の予め確立された関連付け関係に従って、認証情報に対応する第一アカウントを判定するようにするべく、端末により、認証情報及びビジネスリソース量情報をサーバに送信する。
【0058】
上述の実施形態と同様に、本明細書における端末は、第二アカウントと
バインドされた端末であり、且つ、認証情報は、第一アカウントとの間の関連付け関係を有する。従って、これについての説明は、本明細書においては省略することとする。
【0059】
S202:
バインドされた第二アカウントを通じて端末により、サーバによって送信されると共にビジネスリソース量情報に対応するビジネスリソースを受け取る。この場合に、ビジネスリソースは、ビジネスリソース量情報に従って第一アカウントのビジネスリソースからサーバによって取得されている。
【0060】
第二アカウントと
バインドされた端末が認証情報及びビジネスリソース量情報をサーバに送信した後に、サーバは、認証情報に従って、対応する第一アカウントを判定することが可能であり、第一アカウントからビジネスリソースを取得することが可能であり、且つ、ビジネスリソースを第二アカウントに転送することができる。
【0061】
従って、本出願の実施形態に対応する実際的な一適用シナリオにおいては、第一ユーザは、ビジネスサービスを転送するプロセスにおいて、自身の独自の端末装置を使用する必要がない。この代わりに、対応する認証情報及びビジネスリソース量情報を第二アカウントと
バインドされた端末を通じて直接的に入力することにより、ビジネスサービスを転送するプロセスを完了させることが可能であり、この結果、ユーザによって開始されるビジネスサービスを転送するプロセスが格段に便利なものになる。
【0062】
これに加えて、本出願の実施形態における認証情報は、第一アカウントと関連付けられており、且つ、第一アカウントの生成は、通常、第一アカウントにおいて第一ユーザによって送信された対応する動作に基づいている。従って、本出願の一実施形態に従って、リソース処理方法が更に提供される。
図3に示されているように、方法は、以下のステップを有する。
【0063】
S301:端末により、認証情報を生成するための要求を受け取る。
【0064】
端末は、本明細書においては、第一アカウントと
バインドされた端末であり、且つ、認証情報を生成するための要求は、端末上において対応する動作を実行する第一ユーザによって送信することができる。
【0065】
S302:サーバが、認証情報を生成するための要求に従って、一意の認証情報を生成し、且つ、認証情報と第一アカウントとの間の関連付け関係を確立するようにするべく、認証情報を生成するための要求をサーバに送信する。この場合に、認証情報と第一アカウントとの間の関連付け関係は、サーバが、第二アカウントと
バインドされた端末によって送信された認証情報に従って認証情報に対応する第一アカウントを判定し、且つ、判定された第一アカウントのビジネスリソースから規定された量のビジネスリソースを取得するようにするべく、使用される。
【0066】
認証情報を生成するための要求を受け取った際に、サーバは、対応する認証情報を生成することになり、且つ、第一アカウントとの間の関連付け関係を確立することになろう。即ち、第一アカウントを認証情報によって一意に判定することが可能であり、且つ、次いで、サーバは、判定された第一アカウントのビジネスリソースから規定された量のビジネスリソースを更に取得することができる。本明細書における規定された量のビジネスリソースは、上述のビジネスリソース量情報に対応するビジネスリソースの量である。詳細なプロセスは、上述のものとまったく同一であり、この説明は、本明細書においては省略することとする。
【0067】
これに加えて、第一ユーザが、ビジネスリソースを第二ユーザの独自の第二アカウントに転送する動作を開始する際に、サーバは、第一ユーザが確認するように、確認を第一ユーザの独自の第一アカウントに送信することになる。従って、本出願の実施形態においては、方法は、端末が、サーバによって送信された確認要求を受け取り、確認要求のためのユーザによる動作に従って確認命令を生成し、且つ、サーバが、取得されたビジネスリソースを確認命令に従って第二アカウントに転送するようにするべく、確認命令をサーバに返すというステップを更に有する。
【0068】
要すれば、本出願の実施形態においては、第一ユーザが、ユーザによって開始されるビジネスサービスの転送のプロセスにおいて、端末装置を使用又は携帯する必要がなくなるように、従来技術とは異なるリソース処理方法が提供されている。その代わりに、第二ユーザによって使用されると共に第二アカウントと
バインドされた端末を通じて対応する認証情報及びビジネスリソース量情報を入力することにより、対応するビジネスサービスの量を第二アカウントに転送することが可能であり、この結果、ユーザによって開始されるビジネスサービスの転送のプロセスが格段に便利になる。
【0069】
又、本出願の上述の説明は、実際の用途においては、顧客間(C2C)Eコマースのサービスアーキテクチャにも適用可能である。上述のリソース処理手順について明らかに説明するべく、以下、ビジネスサービスが資金であり、且つ、ビジネスリソース量情報が金額情報である、シナリオについて説明することとする。
【0070】
このような一シナリオにおいては、第一ユーザは、第二ユーザからビジネスサービスを取得することができる。この時点において、第一ユーザは、対応する資金を第二ユーザに支払う必要がある。第一ユーザが端末を携帯していないケースにおいては、第一ユーザは、資金支払プロセスを完了させるべく、第二ユーザの端末を使用することができる。
【0071】
これに基づいて、本出願の一実施形態に従って、リソース処理方法が提供される。
図4に示されているように、方法は、以下のステップを有する。
【0072】
S401:端末によって送信された資金認証情報及び金額情報を受け取る。この場合に、資金認証情報は、第一アカウントとの間の関連付け関係を有し、且つ、端末は、第二アカウントと
バインドされている。
【0073】
S402:資金認証情報と第一アカウントとの間の予め確立された関連付け関係に従って、資金認証情報に対応する第一アカウントを判定する。
【0074】
S403:金額情報に従って、且つ、第一アカウントの資金から、金額情報に対応する資金を取得し、且つ、取得された資金を第二アカウントに転送する。
【0075】
第一ユーザは、支払い対象の金額及び資金認証情報を第二ユーザの端末上において直接的に入力することが可能であり(端末は、第二ユーザの独自の第二アカウントと
バインドされている)、且つ、次いで、サーバは、資金認証情報に従って、第一ユーザの独自の第一アカウントから対応する金額の資金を差し引くことが可能であり、且つ、取得された資金を第二アカウントに対して支払うことができることがわかる。このような方式は、第一ユーザがなんらの端末装置をも携帯していないケースにおいて、支払動作を完了させることが可能であり、この結果、支払いがより便利になることが明らかである。
【0076】
対応する方式により、本出願の一実施形態に従って、リソース処理方法が更に提供される。
図5に示されているように、方法は、以下のステップを有する。
【0077】
S501:端末によって送信された資金認証情報及び金額情報を受け取る。この場合に、資金認証情報は、第一アカウントとの間の関連付け関係を有し、且つ、端末は、第二アカウントと
バインドされている。
【0078】
S502:資金認証情報と第一アカウントとの間の予め確立された関連付け関係に従って、資金認証情報に対応する第一アカウントを判定する。
【0079】
S503:金額情報に対応する資金金額が第一アカウントの資金金額を超過しているかどうかを判定し、はいである場合に、ステップS504に進み、いいえである場合には、ステップS505に進む。
【0080】
S504:第一アカウントに対応する信用資金を判定し、信用資金から金額情報に対応する資金を取得し、且つ、取得された資金を第二アカウントに転送し、或いは、第一アカウントの資金及び第一アカウントの判定された信用資金から金額情報に対応する資金を取得し、且つ、取得された資金を第二アカウントに転送する。
【0081】
S505:第一金額の資金から金額情報に対応する資金を取得し、且つ、取得された資金を第二アカウントに転送する。
【0082】
従って、本出願の実施形態においては、サービスプロバイダは、ユーザが、そのアカウント内の信用資金を使用することにより、支払動作を完了させることができるように、信用サービスを提供することができる。アカウントに対応する信用資金は、通常、アカウントレベルに関係付けられている。即ち、相対的に高いレベルを有するアカウントは、相対的に大きな金額の信用資金を有する。詳細は、上述の説明に類似しており、この説明は、本明細書においては省略することとする。
【0083】
第二ユーザによって使用される端末の場合には、本出願の一実施形態に従って、リソース処理方法が更に提供される。
図6に示されているように、方法は、以下のステップを有する。
【0084】
S601:サーバが、資金認証情報と第一アカウントとの間の予め確立された関連付け関係に従って、資金認証情報に対応する第一アカウントを判定するようにするべく、端末により、資金認証情報及び金額情報をサーバに送信する。
【0085】
S602:
バインドされた第二アカウントを通じて端末により、サーバによって送信されると共に金額情報に対応する資金を受け取る。この場合に、資金は、金額情報に従って第一アカウントの資金からサーバによって取得されている。
【0086】
対応する方式により、第一ユーザによって使用される端末の場合には、本出願の一実施形態に従って、リソース処理方法が更に提供される。
図7に示されているように、方法は、以下のステップを有する。
【0087】
S701:端末により、資金認証情報を生成するための要求を受け取る。
【0088】
S702:サーバが、資金認証情報を生成するための要求に従って一意の資金認証情報を生成し、且つ、資金認証情報と第一アカウントとの間の関連付け関係を確立するようにするべく、資金認証情報を生成するための要求をサーバに送信する。この場合に、資金認証情報と第一アカウントとの間の関連付け関係は、サーバが、第二アカウントと
バインドされた端末によって送信された資金認証情報に従って資金認証情報に対応する第一アカウントを判定し、且つ、第一アカウントの資金から規定された金額の資金を取得するようにするべく、使用される。
【0089】
要すれば、C2Cサービスアーキテクチャにおいて本出願の実施形態によるリソース処理方法を使用することにより、第一ユーザは、端末装置を使用又は携帯する必要がない。この代わりに、第一ユーザは、第二ユーザの端末を直接的に使用することが可能であり(端末は、第二ユーザの独自の第二アカウントと
バインドされている)、且つ、資金認証情報を入力することにより、支払動作を完了させることが可能であり、この結果、支払動作がより便利になる。
【0090】
以上、本出願の実施形態によるリソース処理方法について説明した。同一の概念に基づいて、本出願の一実施形態は、リソース処理装置を更に提供している。
図8に示されているように、装置は、端末によって送信された認証情報及びビジネスリソース量情報を受け取るように構成された受信モジュール802であって、認証情報は、第一アカウントとの間の関連付け関係を有し、且つ、端末は、第二アカウントと
バインドされている、受信モジュールと、認証情報と第一アカウントとの間の予め確立された関連付け関係に従って、認証情報に対応する第一アカウントを判定するように構成された判定モジュール802と、ビジネスリソース量情報に従って、且つ、第一アカウントのビジネスリソースから、ビジネスリソース量情報に対応するビジネスリソースを取得し、且つ、取得されたビジネスリソースを第二アカウントに転送するように構成された処理モジュール803と、を有する。
【0091】
一例においては、判定モジュール802は、第一アカウントによって送信された認証情報を生成するための要求を受け取り、受け取られた認証情報を生成するための要求に従って一意の認証情報を生成し、且つ、生成された認証情報と第一アカウントとの間の関連付け関係を確立するように構成されている。
【0092】
これに基づいて、上述の装置は、認証情報を生成する際に時間の計測を開始し、且つ、計測された時間の長さが予め設定された長さに到達した際に、認証情報と第一アカウントとの間の関連付け関係を解消するように構成された有効時間計測モジュール804を更に有する。
【0093】
いくつかの実施形態においては、処理モジュール803は、例えば、ビジネスリソース量情報に対応するビジネスリソースの量が第一アカウントのビジネスリソースの量を超過しているかどうかを判定し、はいである場合に、第一アカウントに対応する余分なリソースを判定し、且つ、余分なリソースからビジネスリソース量情報に対応するビジネスリソースを取得し、或いは、第一アカウントのビジネスリソース及び判定された余分なリソースからビジネスリソース量情報に対応するビジネスリソースを取得し、いいえである場合に、第一アカウントのビジネスリソースからビジネスリソース量情報に対応するビジネスリソースを取得するように、構成されている。
【0094】
別の例においては、処理モジュール803は、第一アカウントのアカウントレベルを判定し、且つ、アカウントレベルと余分なリソースとの間の予め設定された対応性関係に従って第一アカウントに対応する余分なリソースを判定するように構成されている。
【0095】
これに加えて、第二アカウントに転送する前に、受信モジュール802は、第一アカウントによって送信された確認命令を受け取るように更に構成されている。
【0096】
本出願の実施形態は、リソース処理装置を更に提供している。
図9に示されているように、装置は、サーバが、認証情報と第一アカウントとの間の予め確立された関連付け関係に従って認証情報に対応する第一アカウントを判定するようにするべく、認証情報及びビジネスリソース量情報をサーバに送信するように構成された送信モジュール901と、端末と
バインドされた第二アカウントを通じて、サーバによって送信されると共にビジネスリソース量情報に対応するビジネスリソースを受け取るように構成された受信モジュール902であって、ビジネスリソースは、ビジネスリソース量情報に従って第一アカウントのビジネスリソースからサーバによって取得される、受信モジュールと、を有する。
【0097】
本出願の一実施形態は、リソース処理装置を更に提供している。
図10に示されているように、装置は、認証情報を生成するための要求を受け取るように構成された受信モジュール1001と、サーバが、認証情報を生成するための要求に従って一意の認証情報を生成し、且つ、認証情報と第一アカウントとの間の関連付け関係を確立するようにするべく、認証情報を生成するための要求をサーバに送信するように構成された送信モジュール1002であって、認証情報と第一アカウントとの間の関連付け関係は、サーバが、第二アカウントと
バインドされた端末によって送信された認証情報に従って認証情報に対応する第一アカウントを判定し、且つ、判定された第一アカウントのビジネスリソースから規定された量のビジネスリソースを取得するようにするべく、使用される、送信モジュールと、を有する。
【0098】
これに基づいて、上述の装置は、サーバによって送信された確認要求を受け取り、確認要求のためのユーザによる動作に従って確認命令を生成し、且つ、サーバが、取得されたビジネスリソースを確認命令に従って第二アカウントに転送するようにするべく、確認命令をサーバに返すように構成された確認命令モジュール1003を更に有する。
【0099】
C2Cサービスアーキテクチャに基づいた一シナリオにおいては、本出願の一実施形態は、リソース処理装置を更に提供している。
図11に示されているように、装置は、端末によって送信された資金認証情報及び金額情報を受け取るように構成された受信モジュール1101であって、資金認証情報は、第一アカウントとの間の関連付け関係を有し、且つ、端末は、第二アカウントと
バインドされている、受信モジュールと、資金認証情報と第一アカウントとの間の予め確立された関連付け関係に従って、資金認証情報に対応する第一アカウントを判定するように構成された判定モジュール1102と、金額情報に従って、且つ、第一アカウントの資金から、金額情報に対応する資金を取得し、且つ、資金を第二アカウントに転送するように構成された処理モジュール1103と、を有する。
【0100】
図12に示されているように、本出願の一実施形態は、リソース処理装置を更に提供しており、この装置は、端末によって送信された資金認証情報及び金額情報を受け取るように構成された受信モジュール1201であって、資金認証情報は、第一アカウントとの間の関連付け関係を有し、且つ、端末は、第二アカウントと
バインドされている、受信モジュールと、資金認証情報と第一アカウントとの間の予め確立された関連付け関係に従って、資金認証情報に対応する第一アカウントを判定するように構成された判定モジュール1202と、金額情報に対応する資金金額が第一アカウントの資金金額を超過しているかどうかを判定し、はいである場合には、第一アカウントに対応する信用資金を判定し、信用資金から金額情報に対応する資金を取得し、且つ、資金を第二アカウントに転送し、或いは、第一アカウントの資金及び第一アカウントの判定された信用資金から金額情報に対応する資金を取得し、且つ、資金を第二アカウントに転送し、いいえである場合に、第一アカウントの資金から金額情報に対応する資金を取得し、且つ、資金を第二アカウントに転送するように構成された処理モジュール1203と、を有する。
【0101】
図13に示されているように、本出願の実施形態は、リソース処理装置を更に提供しており、この装置は、サーバが、資金認証情報と第一アカウントとの間の予め確立された関連付け関係に従って、資金認証情報に対応する第一アカウントを判定するようにするべく、資金認証情報及び金額情報をサーバに送信するように構成された送信モジュール1301と、端末と
バインドされた第二アカウントを通じて、サーバによって送信されると共に金額情報に対応する資金を受け取るように構成された受信モジュール1302であって、資金は、金額情報に従って第一アカウントの資金からサーバによって取得される、受信モジュール1302と、を有する。
【0102】
図14に示されているように、本出願の一実施形態は、リソース処理装置を更に提供しており、この装置は、資金認証情報を生成するための要求を受け取るように構成された受信モジュール1401と、サーバが、資金認証情報を生成するための要求に従って一意の資金認証情報を生成し、且つ、資金認証情報と第一アカウントとの間の関連付け関係を確立するようにするべく、資金認証情報を生成するための要求をサーバに送信するように構成された送信モジュール1402であって、資金認証情報と第一アカウントとの間の関連付け関係は、サーバが、第二アカウントと
バインドされた端末によって送信された資金関連付け情報に従って資金認証情報に対応する第一アカウントを判定し、且つ、第一アカウントの資金から規定された金額の資金を取得するようにするべく、使用される、送信モジュールと、を有する。
【0103】
通常の構成においては、演算装置は、一つ又は複数のプロセッサ(CPU)、入出力インタフェース、ネットワークインタフェース、及びメモリを含む。
【0104】
メモリは、揮発性メモリ、ランダムアクセスメモリ(RAM:Random Access Memory)、並びに/或いは、例えば、読み出し専用メモリ(ROM:Read-Only Memory)又はフラッシュメモリなどの不揮発性メモリなどの、コンピュータ可読媒体を含むことができる。メモリは、コンピュータ可読媒体の一例である。
【0105】
コンピュータ可読媒体は、永久的な、揮発性の、可動型の、且つ、非可動型の、媒体を含み、これらは、任意の方法又は技術を通じて情報ストレージを実装することができる。情報は、コンピュータ可読構造、データ構造、プログラムモジュール、又はその他のデータであってもよい。コンピュータのストレージ媒体の例は、限定を伴うことなしに、演算装置からアクセス可能である情報を保存するべく使用され得る、相変化RAM(PRAM:Phase-change RAM)、スタティックRAM(SRAM:Static RAM)、ダイナミックRAM(DRAM:Dynamic RAM)、その他のタイプのランダムアクセスメモリ(RAM)、読み出し専用メモリ(ROM)、電気的に消去可能なプログラム可能な読み出し専用メモリ(EEPROM:Electrically Erasable Programmable Read-Only Memory)、フラッシュメモリ又はその他のメモリ技術、コンパクトディスク読み出し専用メモリ(CD−ROM:Compact Disk Read-Only Memory)、デジタルバーサタイルディスク(DVD:Digial Versatile Disc)又はその他の光メモリ、カセット、カセット及びディスクメモリ又はその他の磁気メモリ装置、或いは、任意のその他の非送信媒体を含む。本明細書における定義によれば、コンピュータ可読媒体は、変調されたデータ信号及び搬送波などの一時的な媒体を含んではいない。
【0106】
「含む(including)」や「有する(comprising)」という用語又はこれらの任意のその他の変形は、一連の要素を有するプロセス、方法、物品、又は装置が、これらの要素を有するのみならず、明らかに列挙されてはいないその他の要素をも有するように、或いは、プロセス、方法、物品、又は装置に固有である要素を更に有するように、非排他的包含を含むことを意図していることに更に留意されたい。更なる制限が存在しない際には、「一つの〜を有する(comprising one...)」という記述によって定義された要素は、定義された要素を有するプロセス、方法、物品、又は装置内における更なる類似の要素を排除するものではない。
【0107】
当業者は、本出願の実施形態は、方法、システム、又はコンピュータプログラムとして提供され得ることを理解するであろう。従って、本出願は、完全なハードウェア実施形態、完全なソフトウェア実施形態、或いは、ソフトウェアとハードウェアとを組み合わせた実施形態として実装することができる。更には、本出願は、その内部にコンピュータ使用可能なプログラムコードを有する一つ又は複数のコンピュータ使用可能ストレージ媒体(限定を伴うことなしに、磁気ディスクメモリ、CD−ROM、光メモリ、及びこれらに類似したものを含む)上において実装されたコンピュータプログラムプロダクトの形態において実装することができる。
【0108】
上述の本出願の実施形態は、例示を目的としたものに過ぎず、且つ、本出願を限定するべく使用されるものではない。当業者であれば、本出願を様々な方法によって変更又は変形することができる。本出願の精神及び原理内において実施されるすべての変更、等価な置換、又は改善は、本出願の請求項の範囲に含まれる。