JP7003039B2 - 許可管理及びリソース制御の方法及び装置 - Google Patents

Description

本願は、２０１６年１月８日に出願され「許可管理及びリソース制御の方法及び装置」と題された中国特許出願第２０１６１００１１９６２．６号の優先権を主張し、上記中国特許出願は参照によってその全体が本明細書に組み込まれる。

本願は、コンピュータ技術の分野に関し、特に、許可管理及びリソース制御の方法及び装置に関する。

社会の継続的な発展に伴い、社会的監視のために、例えば集められた資金の開示など、リソースを開示する組織が増えている。

現在、慈善団体が資金集めを行う場合、通常、銀行口座を開設する必要がある。その後、寄付者は、寄付者が開設した銀行口座から慈善団体の口座へ寄付金を送金できる。

既存の技術では、寄付者により送信された、送金額を含む資金送金要求を受信した後、サーバは寄付者の口座から対応する金額を直接的に引き出し、引き出した金額を慈善団体の口座へ送金する。その後、慈善団体は集められた資金を開示できる。

しかし、口座のリソース（慈善基金など）にアクセスしてその使用が許されるのは口座名義人に限られる（例えば、慈善団体のみが慈善団体の口座の資金にアクセスしてこれを使用することが許されている）ので、口座のリソースを開示する必要がある場合、口座名義人は別の方法で口座のリソースを開示しなければならない。一般の人々は慈善団体の口座に直接アクセスできないため、開示されたリソースは信頼できないかもしれない（例えば、一般の人々は、慈善団体が開示した寄付の金額及び用途に疑いを抱くかもしれない）。したがって、他のユーザが特定のユーザのアカウント（口座を含む）に対してある一定のアクセス権を持つことをどのように許可するかは、解決すべき課題になり得る。

本願の実施は、既存の技術に関する課題、すなわち、別のユーザは、特定のアカウント（口座を含む）へアクセスして制御することができない、という課題を解決するための許可管理及びリソース制御の方法及び装置を提供する。

本願の実施は、許可管理の方法を提供する。前記方法は：第１のアカウント（口座を含む）を第２のアカウント（口座を含む）に関連付けるためにユーザによって送信された要求を、サーバによって受信するステップと；前記第１のアカウント（口座を含む）を前記第２のアカウント（口座を含む）に関連付けるステップと；前記第２のアカウント（口座を含む）に対する部分的な許可を前記第１のアカウント（口座を含む）に付与するステップと；を含む。

本願の実施は、リソース制御の方法を提供する。前記方法は：第２のアカウント（口座を含む）を操作するために第１のアカウント（口座を含む）によって送信された操作要求を、サーバによって受信するステップであって、前記操作要求が操作タイプ情報を含む、受信するステップと；前記第１のアカウント（口座を含む）が前記第２のアカウント（口座を含む）に関連付けられているかどうかを判断するステップと；前記判断するステップが肯定（yes）である場合、前記第２のアカウント（口座を含む）によって与えられた前記第１のアカウント（口座を含む）への許可が前記操作タイプ情報に対応する許可を含むかどうかを判断するステップと、肯定の場合前記操作タイプ情報に対応する操作を実行するステップと、否定の場合前記操作タイプ情報に対応する操作の実行を拒否するステップと、前記判断するステップが否定（no）である場合、前記操作タイプ情報に対応する操作の実行を拒否するステップと；を含む。

本願の実施は、許可管理の装置を提供する。前記装置は：第１のアカウント（口座を含む）と第２のアカウント（口座を含む）とを関連付けるためにユーザにより送信された要求を受信するように構成された受信モジュールと；前記第１のアカウント（口座を含む）を前記第２のアカウント（口座を含む）に関連付けるように構成された関連付けモジュールと；前記第２のアカウント（口座を含む）に対する部分的な許可を前記第１のアカウント（口座を含む）に付与するように構成された許可付与モジュールと；を含む。

本願の実施は、リソース制御の装置を提供する。前記装置は：第２のアカウント（口座を含む）を操作するために第１のアカウント（口座を含む）によって送信された操作要求を受信するように構成された受信モジュールであって、前記操作要求は操作タイプ情報を含む、受信モジュール受信モジュールと；
前記第１のアカウント（口座を含む）が前記第２のアカウント（口座を含む）に関連付けられているかどうかを判断するように構成された判断モジュールと；前記判断モジュールの判断結果が肯定である場合、前記第２のアカウント（口座を含む）によって与えられた前記第１のアカウント（口座を含む）への許可が前記操作タイプ情報に対応する許可を含むかどうかを判断し、肯定の場合前記操作タイプ情報に対応する操作を実行し、否定の場合前記操作タイプ情報に対応する操作の実行を拒否し、前記判断モジュールの判断結果が否定である場合、前記操作タイプ情報に対応する操作の実行を拒否するように構成された、実行モジュールと；を含む。

本願の実施は、許可管理及びリソース制御の方法及び装置を提供する。この方法において、サーバは、第１のアカウント（口座を含む）を第２のアカウント（口座を含む）に関連付けるためにユーザによって送信されたリクエストを受信し、第１のアカウント（口座を含む）を第２のアカウント（口座を含む）に関連付け、第２のアカウント（口座を含む）に対する部分的な許可を第１のアカウント（口座を含む）に付与する。この方法では、第２のアカウント（口座を含む）に対する部分的な許可が第２のアカウント（口座を含む）に対応するリソース情報を確認するという許可である場合、ユーザは第１のアカウント（口座を含む）を用いて第２のアカウント（口座を含む）に対応するリソースの状況を識別できる。したがって、ユーザは第２のアカウント（口座を含む）の部分的なアクセス権及び制御権を得ることができるため、開示されたリソース情報は信頼に足るものとなる。

添付の図面は、本願のさらなる理解を提供することを意図しており、本願の一部を構成する。本願の例示的な実施および実施の説明は、本願を説明することを意図しており、本願に対する限定を構成するものではない。添付図面は以下のとおりである。

図１は、本願の実施による、許可管理工程を示す。

図２は、本願の実施よる、リソース制御工程を示す。

図３は、本願の実施による、許可管理装置を示す概略構造図である。

図４は、本願の実施よる、リソース制御装置を示す概略構造図である。

本願の目的、技術的解決法、および利点をより明瞭にするために、本願の特定の実施および対応する添付図面を参照して、本願の技術的解決法について以下に説明する。明らかに、記載された実施は本願の実施の全てではなくむしろそのうちのいくつかに過ぎない。創作努力なしに本願の実施に基づいて当業者によって得られる他の実施は、本願の保護範囲内に入るものとする。

図１は、本願の実施による許可管理の工程を示す。許可管理の工程は以下のステップを含む。

Ｓ１０１：サーバは、第１の口座と第２の口座とを関連付けるためにユーザによって送信された要求を受信する。

既存の出願では、ユーザは自分の口座にアクセスして、これを制御でき、ユーザが別のユーザの口座にログインしたときに限り、別のユーザの口座にアクセスして、これを制御できる。しかし、別のユーザの口座にログインできるようにすると、セキュリティ上の問題を引き起こす可能性がある。

低いセキュリティリスクでユーザが別のユーザの口座の部分的なアクセス権及び制御権を得るために、ユーザは第１の口座を第２の口座に関連付ける要求（関連付け要求）をサーバへ送信できる。第１の口座は、関連付け要求を送信するユーザの口座（つまり、関連付け要求を送信したユーザによって開設された口座）である。第２の口座は、ユーザが部分的なアクセス権及び制御権を取得する必要がある口座である。関連付け要求は、申込要求であっても友達要求であってもよい。更に、関連付け要求は、第１の口座の口座識別子と第２の口座の口座識別子とを含む。

例えば、慈善団体が受け取った寄付金額を確認するために、ユーザＡは、慈善団体の口座にある慈善団体の寄付金額を確認する許可を得る必要があると仮定すると、ユーザＡは、ユーザＡの口座（すなわち、第１の口座）を慈善団体の口座（すなわち、第２の口座）と関連付ける申込要求を送信できる。申込要求は、ユーザＡの口座の識別子と慈善団体の口座の識別子とを含む。

Ｓ１０２：第１の口座を第２の口座に関連付ける。

本願のこの実施では、第１の口座を第２の口座に関連付けるためにユーザによって送信された関連付け要求を受信した後、サーバは、関連付け要求に含まれる第１の口座の識別子と第２の口座の識別子とに基づき、第１の口座を第２の口座に直接的に関連付けることができる。

本願では、複数の第１の口座が１つの第２の口座に関連付けられてもよく、また１つの第１の口座が複数の第２の口座に関連付けられてもよいことに留意されたい。

先の実施例を続けると、ユーザＡの口座を慈善団体の口座に関連付けるために、ユーザＡによって送信された申込要求を受信した後、サーバは、ユーザＡの口座の識別子と慈善団体の口座の識別子とに基づき、ユーザＡの口座を慈善団体の口座に関連付ける。

Ｓ１０３: 第２の口座に対する部分的な許可を第１の口座に付与する。

本願のこの実施では、第１の口座を第２の口座に関連付けると、サーバは第２の口座にアクセスするために第１の口座に部分的な許可を付与でき、ユーザは、その後、第２の口座に対する部分的な許可によって付与された操作を第１の口座から実行できる。部分的な許可は、第２の口座を開くユーザによって予め設定できる。

本願において、先に述べた部分的な許可は、以下のタイプのうちの少なくとも１つを含んでよい：
タイプ１：第２の口座に対応するリソース情報を確認する許可
タイプ２：第２の口座へリソースを振り込む（移す、移動させる）許可
タイプ３：第２の口座によって実行される操作について採決する許可

もちろん、許可は上記の３つのタイプに限定されず、更に他の許可を含むことができる。第２の口座のユーザは、実際の実施に基づいて、許可を事前設定できる。ここでは詳細を述べない。

先の実施例を続けると、慈善団体の予め設定された許可が慈善団体の慈善寄付金額を確認する許可であると仮定すると、ユーザＡの口座を慈善団体の口座に関連付けた後、サーバは慈善寄付の金額確認の許可をＡの口座に付与できるので、その後、ユーザＡは、ユーザＡの口座を利用して慈善団体の口座の慈善寄付金額を確認できる。

第３のタイプの許可では、サーバは、第２の口座に関連付けられた第１の口座の採決結果に基づき、第２の口座によって実行される操作を引き続き許可又は拒否できることに留意されたい。すなわち、サーバが第２の口座から別の口座へ資金を振り込むために操作要求を受信すると、第１の口座は振込操作について採決できるように、サーバは第２の口座に関連付けられた第１の口座による採決操作を開始できる。その後、サーバは、第１の口座の採決結果を収集し、第１の口座の採決結果に基づき、第２の口座によって実行される振込操作を許可又は拒否できる。もちろん、操作を実行する前に、第２の口座はサーバを介して第１の口座に対して採決を能動的に手ほどきすることができるので、第１の口座はその操作について採決できる。

場合によっては、第２の口座に対する部分的な許可が第２の口座に対応するリソース情報を確認する許可である場合、ユーザは第１の口座を用いて第２の口座に対応するリソースの状況を識別できる。かくして、ユーザが第２の口座の部分的なアクセス権及び制御権を取得できるので、開示されたリソース情報は信頼できる。

実施によっては、ユーザは、第１の口座を第２の口座と関連付けるための関連付け要求をサーバへ送信することによって、第２の口座に対する部分的な許可を取得できる。そうすれば、部分的な許可を付与されているので、第２の口座に対して操作を実行できる。しかし、第２の口座の口座情報（またはアカウント情報）が漏れる可能性がある。

本願では、口座はプライベート口座（private account、プライベートアカウント）とパブリック口座（public account、パブリックアカウント）の２種類に分類される。どの口座もパブリック口座に関連付けることができ、パブリック口座は別のパブリック口座に関連付けることもできる。どの口座もプライベート口座に関連付けることはできないが、プライベート口座はどのパブリック口座にも関連付けることができる。サーバは、第１の口座を第２の口座に関連付けるためにユーザによって送信された関連付け要求を受信した後、関連付け要求に含まれる第２の口座の識別子に基づき、第２の口座がパブリック口座であるかどうかを判断できる。肯定である場合、サーバは第１の口座を第２の口座に関連付ける。否定である場合、サーバはユーザに関連付けが失敗したことを通知する。

本願で提供される許可管理の方法は、上記の通りである。図２に示すように、サーバが第１の口座を第２の口座に関連付けた後、第１の口座は、第２の口座に対する部分的な許可によって付与された操作を実行できる。

図２は、本願の実施による、リソース制御の工程を示す。リソース制御の工程には以下のステップが含まれる。

Ｓ２０１：サーバは第２の口座を操作するために第１の口座から送信された操作要求を受信する。

本願では、ユーザが第１の口座を使用して第２の口座で操作を実行する必要がある場合、サーバは先ず第１の口座によって送信された要求を受信する。操作要求には操作タイプ情報（operation type information）が含まれる。操作タイプ情報は、ユーザが第２の口座に対して行う必要がある操作を記録する。更に、操作要求は、第１の口座の口座識別子と第２の口座の口座識別子とを含む。第１の口座の識別子と第２の口座の識別子は、操作要求を送信する第１の口座が第２の口座に関連付けられているかどうかを判断するために用いられる。

上記の実施例を続けると、ユーザＡが慈善団体の口座の慈善寄付金額を確認する必要があると仮定すると、サーバは、慈善団体の口座を操作するためにユーザＡの口座によって送信された要求を受信する。操作要求には、慈善寄付金額確認タイプ（すなわち、操作タイプ情報）、ユーザＡの識別子、及び慈善団体の口座の識別子が含まれる。

Ｓ２０２：第１の口座が第２の口座に関連付けられているかどうかを判断し、肯定である場合、ステップＳ２０３を実行する。否定である場合、ステップＳ２０５を実行する。

本願では、第２の口座に関連付けられた口座のみが、第２の口座によって与えられた部分的な操作許可を有することができる。したがって、サーバは、第２の口座を操作するために第１の口座によって送信された要求を受信した後、第１の口座が第２の口座に関連付けられているかどうかを先ず判断でき、肯定である場合、ステップＳ２０３を実行する。否定である場合、ステップＳ２０５を実行する。

上記の実施例を続けると、サーバは、操作要求に含まれるユーザＡの識別子と慈善団体の口座の識別子とに基づき、操作要求を送信した口座が慈善団体の口座に関連付けられていると判断し、Ｓ２０３を実行する。

Ｓ２０３：第２の口座によって第１の口座に付与された許可が、操作タイプ情報に対応する許可を含むかどうかを判断し、肯定の場合、ステップＳ２０４を実行する。否定の場合、Ｓ２０５を実行する。

Ｓ２０４：操作タイプ情報に応じた操作を実行する。

実施によっては、第２の口座で第１の口座が実行する操作は、第２の口座によって付与された部分的な許可に含まれない可能性がある。したがって、本願では、第１の口座が第２の口座に関連付けられていると判断した後、サーバは、第２の口座によって第１の口座に付与された許可が、操作タイプ情報に対応する許可を含むかどうかを続けて判断でき、肯定の場合、操作タイプ情報に対応する操作を実行する。否定の場合、操作タイプ情報に対応する操作を拒否し、操作タイプ情報に対応する操作が第２の口座で実行できないことをユーザに通知する操作失敗メッセージを第１の口座へ送信する。

上記の実施例を続けると、サーバは、ユーザＡに付与され事前に記憶された許可に基づいて、慈善寄付金額の確認が、許可されているかどうかを判断する。慈善寄付金額の確認が、許可された操作タイプである場合、慈善寄付金額をユーザＡに提供できる。

Ｓ２０５：操作タイプ情報に応じた操作の実行を拒否する。

上記方法に基づき、第２の口座によって付与された第１の口座に対する部分的な許可が第２の口座に対応するリソース情報を確認する許可である場合、ユーザは第１の口座を用いて第２の口座に対応するリソースの状況を識別できる。したがって、ユーザが第２の口座の部分的なアクセス権及び制御権を取得できるので、開示されたリソース情報は信頼できる。

第１の口座によって送信された操作要求に含まれる操作タイプは、リソース確認又は他の操作タイプであってもよい。例えば、実施によっては、ユーザは、第１の口座を使用して第２の口座へリソースを振り込む場合がある。したがって、本願では、第２の口座は、第２の口座に関連付けられた第１の口座に、第２の口座へリソースを振り込む許可を付与できる。言い換えれば、ユーザは、第１の口座を使用することによって、対応するリソースを第２の口座へ振り込むことができる。要求に含まれる操作タイプがリソース振込タイプであり、更に、振り込むリソース金額が含まれている場合、サーバは第１の口座から対応するリソース金額を引き出して第２の口座に追加できる。

例えば、慈善団体の口座によってユーザＡの口座に付与された許可が、リソースを慈善団体の口座へ振り込む許可であると仮定すると、サーバは、慈善団体の口座を操作するためにユーザＡの口座から送信された要求を受け取る。操作要求には、慈善寄付の振込である操作タイプと、ユーザＡの口座の識別子と、１００元（ＲＭＢ）（振り込まれる慈善寄付金額）とが含まれる。サーバは、操作要求を送信する口座が慈善団体の口座に関連付けられており、操作要求に含まれる慈善寄付の振込は許可された操作タイプであると判断する。したがって、サーバはユーザＡの口座から１００元を引き出し、慈善団体の口座に追加することができる。

本願では、口座間のインタラクション（対話性）を強化するために、本願でのサーバは、第１の口座から第２の口座へ振り込まれたリソースの総数を特定し、第１の口座から振り込まれたリソースの総数を識別する、対応したリソース振込ラベル（またはリソース移動ラベル）を設定できる。第１の口座の口座情報をユーザに提供する前に、サーバは第１の口座の口座情報にリソース振込ラベルを追加することができる。

上記の実施例を続けると、ユーザＡが自分の口座（つまり第１の口座）から２００元を慈善団体の口座に振り込み、その後、自分の口座から慈善団体の口座へ１００元を振り込んだと仮定すると、サーバは計算によって、ユーザＡの口座から慈善団体の口座に振り込まれた合計金額が３００元であることを知り、次に、ユーザＡの口座の２００元を識別する振込ラベルを、３００元を識別する振込ラベルに変更する。続いて、第１の口座の口座情報をユーザＡ及び別のユーザに提供する前に、サーバは、ユーザＡの口座情報に３００元を識別する振込ラベルを追加することができる。

具体的には、本願では、以下の方法を用いることができる。すなわち、数間隔（number interval）は分割（division）によって得られ、各間隔に対応する１つのリソース振込ラベルが設定される。ユーザが第１の口座を使用して第１の口座に関連付けられた第２の口座へリソースを振り込むたびに、第１の口座から第２の口座へ振り込まれたリソースの総数が確定される必要がある。振り込まれたリソースの総数が属する数間隔に対応するリソース振込ラベルが、数間隔に基づいて第１の口座に対して設定される。

加えて、ユーザが一の又は複数の第１の口座を使用して第１の口座に関連付けられた第２の口座の制御を強化するために、本願では、第２の口座によって送信された操作要求を受信した後、サーバは第２の口座に関連付けられた第１の口座について採決を開始できる。第１の口座は、第２の口座を使用して操作が実行されるかどうかを決めることを採決できる。具体的には、サーバは、第２の口座によって実行される操作について採決するために、第１の口座から採決要求を受信する。言い換えると、採決要求に含まれる操作タイプ情報は投票であり、採決要求に含まれる投票タイプ（投票タイプには「賛成」と「反対」を含むことができる）に基づいて投票が行われる。所定の条件が満たされると、サーバは、第２の口座に関連付けられた第１の口座の投票結果を収集し、投票結果に基づき、第２の口座によって実行される操作を許可又は拒否する。所定の条件は、投票に参加した第１の口座の数が閾値より多いこと、又は所定の投票期限が満了したこと、であってもよい。

例えば、慈善団体の口座によってユーザＡの口座に付与された許可が、慈善団体の口座によって実行される操作について行う採決であると仮定すると、サーバは、ユーザＡの口座から、慈善団体の口座によって実行される振込操作について採決する要求を受信する。サーバは、操作要求を送信する口座が慈善団体の口座に関連付けられていると判断し、操作要求に含まれる投票タイプ（すなわち、操作タイプ情報）に関連付けられた権利が、与えられた権利の１つであると判断する。したがって、採決要求に含まれる投票タイプ（投票タイプが「賛成」であると仮定して）に基づいて、慈善団体の口座によって実行される振込操作についてサーバが採決する。慈善団体が予め設定した条件は以下であることが想定される；第１の口座が５票を超えて投票に参加し、「賛成」票が投票総数の５０％を超える場合、第２の口座は別の口座に資金を振り込むことができる。この条件で、サーバが統計収集を通じて投票数が７であり、「賛成」票が６票であるとサーバが識別した場合、サーバは慈善団体の口座への資金の振込を許可する。

最後に、上記リソースは、物的リソース、仮想通貨等であってもよいことに留意すべきである。ここでは詳細を述べない。

以上、本願の実施で提供される許可管理の方法及びリソース制御の方法について説明した。同じ概念に基づいて、本願の実施は、２つの装置、すなわち、図３に示す許可管理の装置と図４に示すリソース制御の装置とを提供する。

図３は、本願の実施による、許可管理の装置を示す概略構造図である。この装置は：第１の口座を第２の口座に関連付けるためにユーザによって送信された要求を受信するように構成された受信モジュール３０１と；第１の口座を第２の口座に関連付けるように構成された関連付けモジュール３０２と；第２の口座に対する部分的な許可を第１の口座に付与するように構成された許可付与モジュール３０３と；を含む。

部分的な許可は、第２の口座に対応するリソース情報を確認する許可、第２の口座にリソースを振り込む許可、及び第２の口座によって実行される操作について採決する許可、の少なくとも１つを含む。サーバは、第２の口座に関連付けられた第１の口座の投票結果に基づいて、第２の口座によって実行される操作を許可又は拒否する。

図４は、本願の実施による、リソース制御の装置を示す概略構造図である。この装置は以下を含む。すなわち、第２の口座を操作するために第１の口座によって送信された要求を受信するように構成された受信モジュール４０１であって、操作要求が操作タイプ情報を含む、受信モジュールと；第１の口座が第２の口座に関連付けられているかどうかを判断するように構成された判断モジュール４０２と；実行モジュール４０３であって、判断モジュール４０２の判断結果が肯定である場合、第２の口座によって第１の口座に与えられた許可が操作タイプ情報に対応する許可を含むか否かを判断し、その結果、肯定の場合操作タイプ情報に対応する操作を実行し、否定の場合操作タイプ情報に対応する操作の実行を拒否し、判断モジュール４０２の判断結果が否定である場合、操作タイプ情報に対応する操作を拒否するように構成された実行モジュール。

操作タイプ情報は、リソース情報確認タイプを含み；実行モジュール４０３は、具体的には、第２の口座に対応するリソース情報を取得し、取得したリソース情報を第１の口座へ提供するように構成される。

操作タイプ情報はリソース振込タイプ（またはリソース移動タイプ）を含み、操作要求は振り込まれるリソースの数を更に含み、実行モジュール４０３は、具体的には、第１の口座からリソースの数に対応するリソースを引き出し、それらを第２の口座に追加するように構成される。

この装置は：第１の口座から第２の口座へ振り込まれたリソースの総数を特定し；リソースの総数に基づいて第１の口座に対応するリソース振込ラベルを設定し；第１の口座の口座情報をユーザへ提供する前に、第１の口座の口座情報にリソース振込ラベルを追加するように構成されたラベル付けモジュール４０４を更に含む。

操作要求は、前記第１の口座が前記第２の口座によって実行される操作について採決する要求を含む。操作タイプ情報は投票タイプを含む。実行モジュール４０３は、具体的に：操作要求に含まれる投票タイプに基づいて、第２の口座によって実行される操作について採決し、所定の条件が満たされた場合、第２の口座に関連付けられた第１の口座の投票結果を収集し、投票結果に基づいて、第２の口座によって実行される操作を許可又は拒否するように構成される。

リソースは金額を含む。

典型的な構成では、コンピューティングデバイスは、１つまたは複数のプロセッサ（ＣＰＵ）、入力／出力インターフェイス、ネットワークインターフェイス、およびメモリを含む。

メモリは、非永続性メモリ、ランダムアクセスメモリ（ＲＡＭ）、不揮発性メモリ、および／またはコンピュータ可読媒体内の他の形態、例えば読み出し専用メモリ（ＲＯＭ）、フラッシュメモリ（フラッシュＲＡＭ）を含む。メモリは、コンピュータ可読媒体の一例である。

コンピュータ可読媒体は、任意の方法または技術を使用して情報を記憶することができる永続的、非永続的、移動可能および移動不可能な媒体を含む。情報は、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータであり得る。コンピュータ記憶媒体の例には、相変化メモリ（ＰＲＡＭ）、スタティックランダムアクセスメモリ（ＳＲＡＭ）、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）、別のタイプのランダムアクセスメモリ、リードオンリーメモリ（ＲＯＭ）、ＥＥＰＲＯＭ（Electrically Erasable Programmable Read-Only Memory）、フラッシュメモリ、または他のメモリ技術、コンパクトディスクリードオンリーメモリ（ＣＤ－ＲＯＭ）、ＤＶＤ（Digital Versatile Disc）、または他の光学記憶装置、磁気カセット、磁気テープ／磁気ディスク記憶装置、または他の磁気記憶デバイス、またはコンピューティングデバイスによってアクセス可能な情報を格納するために使用することができる他の非一時的媒体を含む。本明細書の定義に基づくと、コンピュータ可読媒体は、変調データ信号および搬送波などのコンピュータ可読の一時媒体（transitory media）を含まない。

用語「含む（include）」、「含む（contain）」、またはその任意の他の変形は、非排他的な包含を含むように意図されているので、一連の要素は、それらの要素を含むだけでなく、明示的に列挙されていない他の要素を含むか、またはそのようなプロセス、方法、商品、またはデバイスに固有の要素を更に含む。「一つを含む（includes a ...）」の前にある要素は、それ以上の制約がなければ、前記要素を含むプロセス、メソッド、商品、またはデバイスに追加の同一要素が存在することを排除しない。

当業者は、本願の実施が、方法、システム、またはコンピュータプログラム製品として提供され得ることを理解すべきである。したがって、本願は、ハードウェアのみの実施、ソフトウェアのみの実施、またはソフトウェアとハードウェアの組み合わせを有する実施の形態を用いることができる。更に、本願は、コンピュータ使用可能プログラムコードを含む、１つまたは複数のコンピュータ使用可能記憶媒体（ディスクメモリ、ＣＤ－ＲＯＭ、光学メモリなどを含むがこれに限定されない）上に実装されるコンピュータプログラム製品の形態とすることができる。

上記の実施は、本願の単なる実施であり、本願を限定するものではない。当業者であれば、本願に様々な修正や変更を加えることができる。本願の精神および原理から逸脱することなくなされた任意の修正、均等物の置換、または改良は、本願の請求の範囲の範囲内に入るものとする。
［第１の局面］
許可管理の方法であって：
第１のアカウントを第２のアカウントに関連付けるためにユーザによって送信された要求を、サーバによって受信するステップと；
前記第１のアカウントを前記第２のアカウントに関連付けるステップと；
前記第２のアカウントに対する部分的な許可を前記第１のアカウントに付与するステップと；を備える、
許可管理の方法。
［第２の局面］
前記部分的な許可は、前記第２のアカウントに対応するリソース情報を確認する許可、前記第２のアカウントへリソースを移す許可、及び前記第２のアカウントによって実行される操作について採決する許可、のうちの少なくとも１つを含み；
前記サーバは、前記第２のアカウントに関連付けられた第１のアカウントの採決結果に基づいて、前記第２のアカウントによって実行される操作を許可又は拒否する、
第１の局面に記載の方法。
［第３の局面］
リソース制御の方法であって：
第２のアカウントを操作するために第１のアカウントによって送信された操作要求を、サーバによって受信するステップであって、前記操作要求が操作タイプ情報を含む、受信するステップと；
前記第１のアカウントが前記第２のアカウントに関連付けられているかどうかを判断するステップであって、
肯定（yes）である場合、前記第２のアカウントによって与えられた前記第１のアカウントへの許可が、前記操作タイプ情報に対応する許可を含むかどうかを判断し、肯定の場合前記操作タイプ情報に対応する操作を実行し、否定の場合前記操作タイプ情報に対応する操作の実行を拒否し、
否定（no）である場合、前記操作タイプ情報に対応する操作の実行を拒否する、判断するステップと；を備える、
リソース制御の方法。
［第４の局面］
前記操作タイプ情報は、リソース情報確認タイプを含み、
前記操作タイプ情報に対応する操作を実行する前記ステップは、具体的に：
前記第２のアカウントに対応するリソース情報を取得するステップと；
前記取得されたリソース情報を前記第１のアカウントに提供するステップと；を備える、
第３の局面に記載の方法。
［第５の局面］
前記操作タイプ情報は、リソース移動タイプを含み；
前記操作要求は、移動させるリソースの数を更に含み；
前記操作タイプ情報に対応する操作を実行する前記ステップは、具体的に：
前記リソースの数に対応するリソースを前記第１のアカウントから引き出して前記第２のアカウントに追加するステップを備える、
第３の局面に記載の方法。
［第６の局面］
前記第１のアカウントから前記第２のアカウントに移動させたリソースの総数を特定するステップと；
前記リソースの総数に基づいて、前記第１のアカウントにリソース移動ラベルを設定し、前記第１のアカウントのアカウント情報をユーザへ提供する前に、前記第１のアカウントのアカウント情報に前記リソース移動ラベルを追加するステップと；を更に備える、
第５の局面に記載の方法。
［第７の局面］
前記操作要求は、前記第１のアカウントが前記第２のアカウントによって実行される操作について採決する要求を含み；
前記操作タイプ情報は、採決タイプを含み；
前記操作タイプ情報に対応する操作を実行する前記ステップは、具体的に：
前記操作要求に含まれる投票タイプに基づき、前記第２のアカウントによって実行される前記操作について採決するステップと；
所定の条件が満たされた場合、前記第２のアカウントに関連付けられた前記第１のアカウントの投票結果を収集するステップと；
前記投票結果に基づき、前記第２のアカウントによって実行される前記操作を許可又は拒否するステップと；を備える、
第３の局面に記載の方法。
［第８の局面］
前記リソースは金額を含む、
第１の局面乃至第７の局面のいずれかに記載の方法。
［第９の局面］
許可管理の装置であって：
第１のアカウントと第２のアカウントとを関連付けるためにユーザにより送信された要求を受信するように構成された受信モジュールと；
前記第１のアカウントを前記第２のアカウントに関連付けるように構成された関連付けモジュールと；
前記第２のアカウントに対する部分的な許可を前記第１のアカウントに付与するように構成された許可付与モジュールと；を備える、
許可管理の装置。
［第１０の局面］
前記部分的な許可は：
前記第２のアカウントに対応するリソース情報を確認する許可、前記第２のアカウントにリソースを移す許可、及び前記第２のアカウントによって実行される操作について採決する許可、のうちの少なくとも１つを含み；
サーバは、前記第２のアカウントに関連付けられた第１のアカウントの投票結果に基づき、前記第２のアカウントによって実行される前記操作を許可又は拒否する；
第９の局面に記載の装置。
［第１１の局面］
リソース制御の装置であって：
第２のアカウントを操作するために第１のアカウントによって送信された操作要求を受信するように構成された受信モジュールであって、前記操作要求は操作タイプ情報を含む、受信モジュールと；
前記第１のアカウントが前記第２のアカウントに関連付けられているかどうかを判断するように構成された判断モジュールと；
前記判断モジュールの判断結果が肯定である場合、前記第２のアカウントによって与えられた前記第１のアカウントへの許可が前記操作タイプ情報に対応する許可を含むかどうかを判断し、肯定の場合前記操作タイプ情報に対応する操作を実行し、否定の場合前記操作タイプ情報に対応する操作の実行を拒否し、
前記判断モジュールの判断結果が否定である場合、前記操作タイプ情報に対応する操作の実行を拒否するように構成された、実行モジュールと；を備える、
リソース制御の装置。
［第１２の局面］
前記操作タイプ情報は、リソース情報確認タイプであり；
前記実行モジュールは具体的に、前記第２のアカウントに対応するリソース情報を取得し、取得された前記リソース情報を前記第１のアカウントへ提供するように構成された、
第１１の局面に記載の装置。
［第１３の局面］
前記操作タイプ情報はリソース移動タイプを含み、前記操作要求は移動させるリソースの数を更に含み；
前記実行モジュールは、具体的に、前記第１のアカウントから前記リソースの数に対応するリソースを引き出し、それらを前記第２のアカウントに追加するように構成された、
第１１の局面に記載の装置。
［第１４の局面］
ラベル付けモジュールであって：前記第１のアカウントから前記第２のアカウントへ移動させたリソースの総数を特定し；前記リソースの総数に基づいて前記第１のアカウントに対応するリソース移動ラベルを設定し；前記第１のアカウントのアカウント情報をユーザに提供する前に、前記第１のアカウントの前記アカウント情報に前記リソース移動ラベルを追加するように構成された、ラベル付きモジュールを更に備える、
第１３の局面に記載の装置。
［第１５の局面］
前記操作要求は、前記第１のアカウントが前記第２のアカウントによって実行される操作について採決する要求を含み；
前記操作タイプ情報は採決タイプを含み；
前記実行モジュールは、具体的に、前記操作要求に含まれる採決タイプに基づき、前記第２のアカウントによって実行される前記操作について採決し、所定の条件が満たされた場合、前記第２のアカウントに関連付けられた第１のアカウントの投票結果を収集し、前記投票結果に基づいて、前記第２のアカウントによって実施される前記操作を許可又は拒否するように構成された、
第１１の局面に記載の装置。
［第１６の局面］
前記リソースは金額を含む、
第９の局面乃至第１５の局面のいずれかに記載の装置。

Claims (8)

1. リソース制御のための方法であって、
   サーバによって、第２のアカウントを操作するために第１のアカウントによって送信された操作要求を受信するステップであって、前記操作要求は、ｉ）前記第１のアカウントが前記第２のアカウントによって実行される、リソースを移すための操作に投票するための要求と、ｉｉ）投票タイプを含む操作タイプ情報とを含む、ステップ（Ｓ２０１）と、
   前記第１のアカウントが前記第２のアカウントに関連付けられていることを判断するステップ（Ｓ２０２）と、
   前記第２のアカウントによって与えられた前記第１のアカウントへの許可が前記操作タイプ情報に対応する許可を含むことを判断するステップ（Ｓ２０３）と、
   前記操作タイプ情報に対応する操作を実行するステップであって、前記操作は、前記操作要求に含まれる投票タイプに基づいて前記第２のアカウントによって実行される、前記リソースを移すための操作に投票するステップと、所定の条件が満たされた場合、前記第２のアカウントに関連付けられた第１のアカウントの投票結果を収集するステップと、前記投票結果に基づいて前記第２のアカウントによって実行される、前記リソースを移すための操作を許可又は拒否するステップとを含み、前記所定の条件は、前記投票に参加した前記第１のアカウントの数が閾値より多いことを備える、ステップ（Ｓ２０４）と
   を備え、
   前記投票結果に基づいて前記第２のアカウントによって実行される前記リソースを移すための操作を拒否するステップが、前記操作タイプ情報に対応する、前記第２のアカウントによって実行される、前記リソースを移すための操作の実行を拒否するステップ（Ｓ２０５）を備え、
   前記投票結果に基づいて前記第２のアカウントによって実行される前記リソースを移すための操作を許可するステップが、（ｉ）前記第１のアカウントから前記リソースを引き出し、かつ前記第２のアカウントに前記リソースを追加するステップと、（ｉｉ）前記リソースに基づいて前記第１のアカウントに対して対応するリソース移動ラベルを設定するステップと、（ｉｉｉ）前記第１のアカウントのアカウント情報をユーザに提供する前に、前記リソース移動ラベルを）前記第１のアカウントの前記アカウント情報に追加するステップとを備える、
   方法。
2. 前記第１のアカウントを前記第２のアカウントに関連付けるためにユーザによって送信された要求を、前記サーバによって受信するステップ（Ｓ１０１）と、
   前記第１のアカウントを前記第２のアカウントに関連付けるステップ（Ｓ１０２）と、
   前記第２のアカウントに対する部分的な許可を前記第１のアカウントに付与するステップ（Ｓ１０３）と
   をさらに備える、請求項１に記載の方法。
3. 前記部分的な許可は、前記第２のアカウントに対応するリソース情報を確認する許可、前記第２のアカウントへリソースを移す許可、及び前記第２のアカウントによって実行される操作について採決する許可のうちの少なくとも１つを含み、
   前記サーバは、前記第２のアカウントに関連付けられた第１のアカウントの投票結果に基づいて、前記第２のアカウントによって実行される操作を許可又は拒否する、
   請求項２に記載の方法。
4. 前記リソースは金額を含む、請求項１～３のいずれか一項に記載の方法。
5. リソース制御のための装置であって、
   第２のアカウントを操作するために第１のアカウントによって送信された操作要求を受信するように構成される受信モジュールであって、前記操作要求は、ｉ）前記第１のアカウントが前記第２のアカウントによって実行される、リソースを移すための操作に投票するための要求と、ｉｉ）投票タイプを含む操作タイプ情報とを含む、受信モジュールと、
   前記第１のアカウントが前記第２のアカウントに関連付けられていることを判断するように構成される判断モジュールと、
   実行モジュールであって、
   前記第２のアカウントによって与えられた前記第１のアカウントへの許可が前記操作タイプ情報に対応する許可を含むことを判断することと、
   前記操作タイプ情報に対応する操作を実行することであって、前記操作は、前記操作要求に含まれる投票タイプに基づいて前記第２のアカウントによって実行される、前記リソースを移すための操作に投票することと、所定の条件が満たされた場合、前記第２のアカウントに関連付けられた第１のアカウントの投票結果を収集することと、前記投票結果に基づいて前記第２のアカウントによって実行される、前記リソースを移すための操作を許可又は拒否することとを含み、前記所定の条件は、前記投票に参加した前記第１のアカウントの数が閾値より多いことを備える、実行することと
   を行うように構成される、実行モジュールと
   を備え、
   前記投票結果に基づいて前記第２のアカウントによって実行される前記リソースを移すための操作を拒否することが、前記操作タイプ情報に対応する、前記第２のアカウントによって実行される、前記リソースを移すための操作の実行を拒否することを備え、
   前記投票結果に基づいて前記第２のアカウントによって実行される前記リソースを移すための操作を許可することが、（ｉ）前記第１のアカウントから前記リソースを引き出し、かつ前記第２のアカウントに前記リソースを追加することと、（ｉｉ）前記リソースに基づいて前記第１のアカウントに対して対応するリソース移動ラベルを設定することと、（ｉｉｉ）前記第１のアカウントのアカウント情報をユーザに提供する前に、前記リソース移動ラベルを）前記第１のアカウントの前記アカウント情報に追加することとを備える、
   装置。
6. 前記第１のアカウントを前記第２のアカウントに関連付けるためにユーザによって送信された要求を受信するように構成される受信モジュールと、
   前記第１のアカウントを前記第２のアカウントに関連付けるように構成される関連付けモジュールと、
   前記第２のアカウントに対する部分的な許可を前記第１のアカウントに付与するように構成された許可付与モジュールと
   をさらに備える、請求項５に記載の装置。
7. 前記部分的な許可は、前記第２のアカウントに対応するリソース情報を確認する許可、前記第２のアカウントへリソースを移す許可、及び前記第２のアカウントによって実行される操作について採決する許可のうちの少なくとも１つを含み、
   サーバは、前記第２のアカウントに関連付けられた第１のアカウントの投票結果に基づいて、前記第２のアカウントによって実行される操作を許可又は拒否する、
   請求項６に記載の装置。
8. 前記リソースは金額を含む、請求項５～７のいずれか一項に記載の装置。

Images