JP6788697B2 - 情報認証のための方法およびシステム - Google Patents

Description

分野
本出願は、コンピュータ技術の分野に関し、より具体的には、情報認証のための方法およびシステムに関する。

関連技術分野
コンピュータおよびネットワーク技術の持続的な発展により、ユーザがオンラインアカウントを介して様々なオペレーションを実行することは一般的なことである。例えば、ユーザは、これらの電子商取引ウェブサイトに登録されているアカウントを介して電子商取引ウェブサイト上で買い物をすることができる。

しかし、コンピュータおよびネットワーク技術の開発と共に、無許可のユーザによるアイデンティティ盗難の量も増えている。ユーザのアカウントやパスワードが侵害された時点で、悪意のあるユーザは、奪ったアカウントを介してオペレーションを実行する恐れがあり、それにより、正規ユーザは多大な損害を受ける。

アイデンティティ盗難の難易度を上げるために多くの方法が利用可能だが、そのようなアイデンティティ盗難のリスクは依然として残っている。

概要
本発明の一実施形態は、多人数認証を容易にするためのシステムを提供する。オペレーションの間、システムは、通信モジュールを介して、プライマリユーザから動作要求を受信する。次いで、システムは、認証要求を認証補助ユーザに送信し、認証補助ユーザから応答を受信する。それに続いて、システムは、認証補助ユーザから受信された応答に基づいて、動作要求を許可するかまたは拒否する。

この実施形態の変形形態では、認証要求を送信する前に、システムは、動作要求を許可するために少なくとも１人の認証補助ユーザからの認証が必要かどうかを判断する。

この実施形態の変形形態では、少なくとも１人の認証補助ユーザからの認証が必要かどうかを判断する間、システムは、少なくとも１つの既定のルールを受信された動作要求に適用する。

さらなる変形形態では、ルールは、動作要求と関連付けられた取引タイプに基づく。

さらなる変形形態では、ルールは、支払金額に基づく。

この実施形態の変形形態では、システムは、少なくとも１人の認証補助ユーザから受信された応答が、既定の閾値より大きい承認の尺度を示すかどうかをさらに判断する。

この実施形態の変形形態では、認証要求を認証補助ユーザに送信する間、システムは、電話番号、Ｅメールまたはインスタントメッセージに基づくテキストメッセージを認証補助ユーザに送信する。

この実施形態の変形形態では、動作要求を拒否する間、システムは、拒否の理由をプライマリユーザに送信する。

図面の簡単な説明
本明細書に組み込まれ、本明細書の一部を構成する本明細書の添付の図面は、本出願のいくつかの例示的な実施形態を示し、説明と共に、本出願を示す上で役立ち、本出願を制限しないものと解釈する。

本出願の実施形態による、多人数認証プロセスを容易にする例示的なコンピューティングシステムを示す。 本出願の実施形態による、情報認証のプロセスを示す。 本出願の実施形態による、情報認証の詳細なプロセスを示す。 本発明の実施形態による、多人数認証を容易にする例示的な認証システムを示す。

詳細な説明
本発明の実施形態は、一当事者の代わりに複数当事者がオンライン取引のための認証プロセスに参加できるようにすることによって、オンライン取引のセキュリティを改善する問題を解決する。従来の方式では、ユーザが対応するオンラインアカウントの正しいパスワードまたは他のタイプのユーザ認証情報を入力する限り、オンライン取引を進めることが認められている。ユーザのアカウント名およびパスワードが盗まれれば、重大な損害が生じ得る。それに加えて、オンライン取引についての決定を行う上で、単一のユーザが唯一の当事者ではない場合が多い。例えば、未成年者は、大量のオンライン購入を決める前に両親の承認を必要とする場合がある。企業環境では、決定またはオンライン取引の実現には、複数当事者の承認が必要とされる場合がある。

本発明の実施形態では、１人または複数の認証補助ユーザは、アカウントのための認証プロセスと関連付けられることが認められている。例えば、アカウントと関連付けられたオンライン取引を実行するため、プライマリユーザがアカウントの正しいパスワードを入力することに加えて、多くの認証補助ユーザからの承諾も必要とされる場合がある。このように、他の認証補助ユーザからの承諾無しではオンライン取引を進めることが認められないことがあるため、プライマリユーザのアカウント情報およびパスワードが盗まれても、損害を効果的に防ぐことができる。

本出願の目的、技術的解決法および利点をより明確にするため、本出願の技術的解決法は、本出願の特定の実施形態および対応する図面を参照して、以下で完全に詳細に説明する。明確には、本明細書で説明される実施形態は、単なる例示的なものであり、本出願のすべての実施形態ではない。本出願の実施形態に基づいて、創造的な取り組みを行うことなく当業者によって導き出される他のすべての実施形態は、本出願の保護範囲内に収まるものとする。

図１Ａは、本出願の実施形態による、多人数認証プロセスを容易にする例示的なコンピューティングシステムを示す。この例では、認証サーバ１１０は、プライマリユーザ１０１と通信する。また、認証サーバ１１０には、認証補助ユーザ１０２、１０４、１０６および１０８が結合される。取引サーバ１１２（例えば、電子商取引商人のデータセンタ）は、認証サーバ１１０と通信することができる。

オペレーションの間、プライマリユーザ１０１は、取引要求を起こし、認証サーバ１１０に要求を送信する。この要求を受信次第、認証サーバ１１０は、補助ユーザ１０２、１０４、１０６および１０８に認証要求を送信する。これらの４人の補助ユーザの各々は、認証要求を承認または承諾するか（例えば、ユーザ名やパスワードなどの彼ら自身の認証情報を提供することによって）、あるいは、認証要求を拒否することができる。

認証サーバ１１０が４人の補助ユーザ１０２、１０４、１０６および１０８から承認または拒否を受信した時点で、認証サーバ１１０は、プライマリユーザ１０１によって要求された取引を進めることを許可するか、または、プライマリユーザ１０１からの取引要求を拒否することができる。一実施形態では、取引を進めることが承認されると、認証サーバ１１０は、取引要求を取引サーバ１１２に転送することができ、これを受けて、取引サーバ１１２は、取引要求を処理し、対応する取引を実現する。

補助ユーザ１０２、１０４、１０６および１０８は、プライマリユーザ１０１が事前に決定し、プライマリユーザ１０１のアカウントと関連付けることができることに留意されたい。任意選択により、これらの補助ユーザは、プライマリユーザ１０１以外のエンティティが指定することもできる。例えば、企業環境では、プライマリユーザ１０１は、オフィス備品を購入する責任を有する従業員であり得る。ある特定のタイプの購入の場合、補助ユーザ１０２、１０４、１０６および１０８は、異なる部署からの責任者であり得、発注書の発行には、これらの４人のすべての補助ユーザからの承認が必要とされる。

また、認証サーバ１１０は、一連のルールを実装することも可能であり、その結果、プライマリユーザ１０１によって要求されたある特定の取引は、補助ユーザからの追加の承認を得ることなく認証サーバ１１０による承認を得ることができる一方で、ルールを満たす取引を進めるには、補助ユーザからの追加の承認が必要とされるであろう。例えば、プライマリユーザ１０１は、生活費を支払うために彼の両親から提供されたクレジットカードを使用する大学生であり得る。認証サーバ１１０は、クレジットカード会社のサービスの一部であり得る。認証サーバ１１０は、プライマリユーザ１０１によって要求されたある特定のタイプの取引が追加の補助ユーザによる承認を受けることを要求する一連のルールを格納することができる。例えば、ルールは、所定の金額のある特定のタイプの取引（＄１００未満の食料またはガスに対する支払いなど）は、追加の承認を得ることなく処理できると指定することができる。他のタイプの支払い（例えば、電子機器に対する支払い、娯楽に対する支払いまたは既定の限度額を超える支払い）の処理は、学生の両親からの追加の承認を必要とする。

認証サーバ１１０とそれぞれの補助ユーザとの間の通信はいかなる形態でもあり得ることに留意されたい。例えば、認証サーバ１１０は、承認を得るために、補助ユーザ１０２に、Ｅメール、テキストメッセージを送信することも、音声電話をかけることもできる。

図１Ｂは、本出願の実施形態による、情報認証のプロセスを示す。オペレーションの間、認証サーバは、プライマリユーザに属するアカウントを介してプライマリユーザによって送信された動作要求を受信する（動作Ｓ１０１）。プライマリユーザがアカウントを介して動作または取引を実行することを希望する際、プライマリユーザは、最初に、動作要求を認証サーバに送信する必要があることに留意されたい。動作要求は、これに限定されないが、支払要求を含み得る。その上、プライマリユーザは、必ずしもアカウントの所有者であるわけではない。動作要求はアカウント情報のみ保持するため、認証サーバは、任意選択により、プライマリユーザがアカウントの所有者であるかどうかを判断しないことを選択することができる。

例えば、プライマリユーザが電子商取引ウェブサイトで買い物する際、プライマリユーザは、電子商取引ウェブサイトに登録されているアカウントＡを介して１つの商品を購入することができ、プライマリユーザは、アカウントＡを介して電子商取引ウェブサイトの認証サーバに支払要求を送信することができ（支払要求が動作要求である）、支払要求はアカウントＡの情報のみを保持するため、この事例では、認証サーバは、プライマリユーザがアカウントＡの所有者であるかどうかを判断しないことを選択することができる。

それに続いて、認証サーバは、アカウントに対応する既定の認証補助ユーザを検索する（動作Ｓ１０２）。アカウントに対応する認証補助ユーザは、アカウントの所有者が事前に決定することができる。アカウントを介してプライマリユーザによって送信された動作要求を受信次第、認証サーバは、プライマリユーザによって入力されたアカウントのパスワードを認証することができる。パスワードに基づく認証に成功した場合は、認証サーバは、そのアカウントに対してアカウントの所有者によって事前に決定されている認証補助ユーザおよび認証補助ユーザの連絡先情報を検索することができる。パスワードに基づく認証に失敗した場合は、サーバは、認証補助ユーザと連絡を取ることなく、動作要求に対応する動作の実行を直接拒否することができる。

認証補助ユーザの連絡先情報は、これらに限定されないが、携帯電話番号、インスタントメッセージアカウント情報、Ｅメールアドレス、同じ認証サーバ上のアカウントまたは認証補助ユーザの安全なメッセージシステムにおける任意の形態のユーザ識別子を含み得る。

依然として上記の例を使用すると、アカウントＡに関し、アカウントＡの所有者は、対応する認証補助ユーザとしてユーザｕを事前に決定し、ユーザｕの連絡先情報を認証サーバ上に格納することができる。アカウントＡを介してプライマリユーザによって送信された支払要求を受信する際、認証サーバは、最初に、アカウントＡのパスワードを認証する。認証に成功した場合は、サーバは、アカウントＡに対応する認証補助ユーザｕの連絡先情報を検索することができる。認証に失敗した場合は、サーバは、動作要求を直接拒否することができる。

次に、認証サーバは、動作要求に関する認証問い合わせ情報を、識別された認証補助ユーザに送信する（動作Ｓ１０３）。アカウントに対応する認証補助ユーザおよび認証補助ユーザの連絡先情報を識別次第、認証サーバは、動作要求に関する認証問い合わせ情報を認証補助ユーザに送信することができる。

例えば、識別された認証補助ユーザの連絡先情報が携帯電話番号の場合は、認証サーバは、テキストメッセージを介して、動作要求に関する認証問い合わせ情報を識別された認証補助ユーザに送信することができる。認証補助ユーザの連絡先情報がインスタントメッセージアカウントの場合は、認証サーバは、動作要求に関する認証問い合わせ情報を補助ユーザのインスタントメッセージアカウントに送信することができる。

さらに、上記で説明される同じ例を使用すると、サーバは、補助ユーザｕがプライマリユーザによる支払いを認めているかどうかについて問い合わせるために、テキストまたはインスタントメッセージを介して、支払要求に示されるプライマリユーザによって注文された商品の情報、要求された支払金額、支払要求の時間情報および同様のものを補助ユーザｕに送信することができる。例えば、認証サーバは、「アカウントＡが〜時〜分に商品ｓを購入し、現在、ｘの支払いを要求しています。承諾する場合はＹでまたは拒否する場合はＮで返答してください。」というショートメッセージをユーザｕの携帯電話番号に送信することができる。

認証補助ユーザの連絡先情報がインスタントメッセージアカウントまたはＥメールアドレスの場合は、上記の認証問い合わせ情報は、対応するインスタントメッセージアカウントまたはＥメールアドレスに送信することもできる。補助ユーザの連絡先情報が認証サーバ上のアカウントの場合は、認証補助ユーザがアカウントを介してシステムにログインしたと判断次第、認証サーバは、メッセージ、ウェブページへのリンクまたは警告を介して、認証問い合わせ情報を認証補助ユーザにプッシュすることもできる。

次いで、認証サーバは、認証補助ユーザによって返された認証容認情報が受信されたかどうかを判断する（動作Ｓ１０５）。認証容認情報が受信されていない場合または補助ユーザが否認もしくは拒否を返した場合は、認証サーバは、動作要求を拒否する（動作Ｓ１０６）。既定の時間（例えば、５分）内に認証補助ユーザから情報が受信されない場合は、サーバは、認証補助ユーザは動作要求を拒否したと見なすことができる。

認証サーバが認証補助ユーザによって返された認証容認情報を受信した場合は、認証サーバは、動作要求に対応する動作の実行を許可することができる（動作Ｓ１０５）。既定の時間（例えば、５分）内に認証補助ユーザから情報が受信されない場合は、サーバは、認証補助ユーザは動作要求を拒否したと見なすことができる。すなわち、サーバは、認証補助ユーザは認証拒否情報を返したと見なし、従って、関連処理を進める。

依然として上記の例を使用すると、アカウントＡと関連付けられた認証補助ユーザｕの携帯電話番号に「アカウントＡが〜時〜分に商品ｓを購入し、現在、ｘの支払いを要求しています。承諾する場合はＹでまたは拒否する場合はＮで返答してください。」というショートメッセージを送信次第、認証サーバは、ユーザｕによって返されたショートメッセージの内容をモニタすることができる。内容「Ｙ」のショートメッセージがユーザｕから受信された場合は、認証サーバは、ユーザｕによって返された認証容認情報が受信されたと判断し、従って、プライマリユーザによって送信された支払要求に対応する動作の実行を許可する（すなわち、プライマリユーザがアカウントＡを介して商品ｓを購入ために支払いｘを行うことを許可する）。内容「Ｎ」のショートメッセージがユーザｕから受信された場合は、認証サーバは、ユーザｕは認証要求を拒否したと判断し、従って、プライマリユーザによって送信された支払要求に対応する動作の実行を拒否する。

上記の方法によれば、サーバは、プライマリユーザがアカウントの所有者であるかどうかを判断しないことを選択することができるが、動作要求は、アカウントの認証補助ユーザが動作要求を認めた場合にのみ、許可することができる。従って、ユーザのアカウントおよびパスワードが奪われた場合、すなわち、動作要求を送信しているプライマリユーザがアカウントの所有者ではない場合は、無許可のユーザが正しいパスワードを入力しても、無許可のユーザは、認証補助ユーザの承認無しでは、アカウントを介して、いかなる動作も実行することができない。このように、ユーザのアカウントおよびパスワードが盗まれても、依然として、アカウントの所有者にいかなる損害も及ばないことを保証することができる。

それに加えて、本発明の実施形態は、インターネットの未成年のユーザに対する保護を提供することができる。例えば、子供の保護者は、アカウントの認証補助ユーザとして設定することができ、インターネット上で子供によって実行される動作は、保護者が認めて動作を許可した場合にのみ、実行を許可することができる。

一般に、認証サーバは、受信された動作要求が認証補助ユーザからの追加の承認を必要とするかどうかを判断するために、ルールを実装することができる。例えば、図１Ｂに示される動作Ｓ１０１では、アカウントを介してプライマリユーザによって送信された動作要求が支払要求の場合は、動作Ｓ１０２において認証サーバがアカウントに対応する既定の認証補助ユーザを検索する前に、サーバは、動作要求によって要求された支払金額が既定の閾値より大きいかどうかを判断することができる。金額が閾値より大きい場合は、サーバは、認証補助ユーザからの追加の承認を必要とすると判断し、アカウントに対応する認証補助ユーザを検索する。そうでなければ、サーバは、補助ユーザからの追加の承認を必要とすることなく、動作要求に対応する動作の実行を直接許可することができる。既定の金額は、実際のニーズに従って定義することができるか、または、アカウントの所有者が定義することができる（例えば、＄５００）。

同様に、サーバがアカウントに対応する既定の認証補助ユーザを検索する前、サーバは、受信された動作要求のタイプが既定の動作要求タイプであると判断することができる。受信された動作要求のタイプが既定の動作要求タイプである場合は、サーバは、認証補助ユーザが動作要求を認めるかどうかについて問い合わせするために、アカウントに対応する既定の認証補助ユーザを検索する。そうでなければ、サーバは、動作要求に対応する動作の実行を直接許可することができる。既定のタイプの動作要求は、支払要求、ユーザ情報変更要求または同様のものであり得る。例えば、認証サーバは、プライマリユーザによって送信された動作要求が支払要求またはユーザ情報変更要求である場合にのみ、認証補助ユーザからの追加の承認を必要とし得る。他のタイプの動作要求（例えば、ログイン要求、商品問い合わせ要求または同様のもの）に関しては、動作を直接許可することができる。

従って、認証サーバが既定のルールまたは閾値に基づいて認証補助ユーザからの追加の承認は必要ないと判断した場合は、認証サーバは、プライマリユーザが正しいパスワードを入力した後に、動作要求に対応する動作の実行を許可することができる。さらに、サーバは、アカウントに対応する既定のセキュリティ質問をプライマリユーザに送信することができ、プライマリユーザがセキュリティ質問に正しく答えた場合にのみ、動作の実行を許可することができる。

いくつかの実施形態では、アカウントの所有者は、アカウントに対する複数の認証補助ユーザを事前に定義することができ、動作要求を承認するために、認証補助ユーザ全員からの承認の一部のみを必要とする。例えば、認証サーバは、アカウントに対応する認証補助ユーザを識別し、認証問い合わせ情報をこれらの補助ユーザに送信することができる。次いで、認証サーバは、認証補助ユーザの総数に対する認証容認情報を返す認証補助ユーザの数の比率が既定の閾値より大きいかどうかを判断することができる。比率が閾値より大きい場合は、サーバは、動作要求を許可する。そうでなければ、サーバは、動作要求を拒否する。既定の閾値は、実際のニーズに従って定義することができるか、または、アカウントの所有者が定義することができる。

例えば、アカウントＡに関し、アカウントＡの所有者がｎ人の認証補助ユーザを事前に定義したと想定すると、１人の認証補助ユーザが動作の実行を拒否すれば動作の実行は許可されないという基準に従って、既定の閾値（承認を与える補助ユーザの絶対数である）は、ｎ−１と定義することができる。従って、認証サーバは、すべての認証補助ユーザが要求に対する承認を返した場合にのみ、動作要求を許可する。

さらなる例では、システムが多数決原則を採用した場合は（すなわち、要求を拒否する補助ユーザよりも承認を与える補助ユーザの方が多い限り）、５０％の比率を使用することができる。すなわち、補助ユーザの総数に対する承認する補助ユーザの比率が５０％より大きい限り、認証サーバは、動作要求を許可することができる。動作要求を許可するための閾値を設定する他の方法も可能である。

さらなる実施形態では、認証システムは、補助ユーザが認証要求を拒否する理由を提供できるようにすることができる。例えば、補助ユーザによって返された拒否理由は、「アカウントが侵害されており、動作は、許可されたユーザによって実行されたものではない」であり得る。認証サーバは、さらに、動作要求を拒否次第、プライマリユーザに拒否理由を提示することができる。

図２は、本出願の実施形態による、情報認証の詳細なプロセスを示す。オペレーションの間、認証サーバは、アカウントを介してプライマリユーザによって送信された動作要求を受信する（動作Ｓ２０１）。次いで、認証サーバは、プライマリユーザによって提供されたパスワードを認証する（動作Ｓ２０２）。パスワードに基づく認証に失敗した場合は、認証サーバは、動作要求に対応する動作を拒否する（動作Ｓ２０８）。

プライマリユーザのパスワードに基づく認証に成功した場合は、認証サーバは、プライマリユーザがそれを通じて動作要求を送信したアカウントに対応する既定の認証補助ユーザの検索へと進む（動作Ｓ２０３）。次いで、認証サーバは、動作と関連付けられた認証問い合わせ情報を、識別された認証補助ユーザに送信する（動作Ｓ２０４）。

次に、認証サーバは、認証を拒否する認証補助ユーザに対する、容認（すなわち、承認）を返す認証補助ユーザの比率を演算する（動作Ｓ２０５）。この例では、閾値は上記で説明されるような比率に基づくことに留意されたい。他の公式（承認を与える認証ユーザのパーセンテージなど）または承認する補助ユーザの絶対数も使用することができる。

次いで、認証サーバは、比率が既定の閾値より大きいかどうかを判断する（動作Ｓ２０６）。比率が既定の閾値より大きい場合は、認証サーバは、動作要求に対応する動作の実行を許可する（動作Ｓ２０７）。そうでなければ、認証サーバは、動作を拒否する（動作Ｓ２０８）。

動作要求に対応する動作の実行が拒否された後、認証拒否情報の拒否理由情報をプライマリユーザに提示することができる。

図３は、本発明の実施形態による、多人数認証を容易にする例示的な認証システムを示す。認証システム３００は、プロセッサ３１０と、メモリ３２０と、ストレージデバイス３３０とを含む。ストレージ３３０は、通常、上記で説明される方法を実行するために、メモリ３２０にロードしてプロセッサ３１０によって実行できる命令を格納する。一実施形態では、ストレージ３３０内の命令は、通信管理モジュール３３２、補助ユーザ管理モジュール３３４、認証モジュール３３６および動作要求管理モジュール３３８を実装することができ、それらはすべて、様々な手段を通じて互いに通信することができる。

いくつかの実施形態では、モジュール３３２、３３４、３３６および３３８は、ハードウェアにおいて部分的にまたは全体的に実装することができ、プロセッサ３１０の一部であり得る。さらに、いくつかの実施形態では、システムは、別個のプロセッサおよびメモリを含まない場合もある。代わりに、それらの特定のタスクの実行に加えて、モジュール３３２、３３４、３３６および３３８は、別々にまたは協働して、特殊な目的の演算処理エンジンの一部であり得る。

ストレージ３３０は、プロセッサ３１０によって実行されるプログラムを格納する。具体的には、ストレージ３３０は、多人数認証を可能にするためのシステム（アプリケーション）を実装するプログラムを格納する。オペレーションの間、アプリケーションプログラムは、ストレージ３３０からメモリ３２０にロードし、プロセッサ３１０によって実行することができる。その結果、システム３００は、上記で説明される機能を実行することができる。システム３００は、任意選択のディスプレイ３８０、キーボード３６０およびポインティングデバイス３７０とさらに結合することができ、１つまたは複数のネットワークインタフェースを介してネットワーク３８２と結合することもできる。

オペレーションの間、通信管理モジュール３３２は、例えば、システム３００上の通信ポート（ネットワークインタフェースカードなど）を介して、プライマリユーザから動作要求を受信する。彼の個々の認証情報でプライマリユーザを認証次第、補助ユーザ管理モジュール３３４は、プライマリユーザがそれを介して動作要求を送信するアカウントと関連付けられた１人または複数の補助ユーザを識別する。それに続いて、認証モジュール３３６は、識別された補助ユーザに認証問い合わせを送信し、対応する応答を受信する。補助ユーザから受信した応答に基づいて、認証モジュール３３６は、十分な数の認証容認（承認）が受信されたかどうかを判断する。それに従って、動作要求管理モジュール３３８は、動作要求を許可するかまたは拒否するかを判断する。

いくつかの実施形態では、補助ユーザ管理モジュール３３４は、動作要求に適用されるある特定のルール（支払金額閾値または動作要求に対応するオンライン取引のタイプなど）に基づいて、補助ユーザ承認が必要かどうかを判断することができる。それに加えて、認証モジュール３３６は、補助ユーザから受信される承認に対して既定の閾値を適用することができる。

この詳細な説明で説明されるデータ構造およびコンピュータ命令は、通常、コンピュータ可読記憶媒体上に格納され、コンピュータ可読記憶媒体は、コンピュータシステムによる使用のためのコードおよび／またはデータを格納できるいかなるデバイスまたは媒体でもあり得る。コンピュータ可読記憶媒体は、これらに限定されないが、揮発性メモリ、不揮発性メモリ、磁気および光学記憶装置（ディスクドライブ、磁気テープ、ＣＤ（コンパクトディスク）、ＤＶＤ（デジタル多用途ディスクまたはデジタルビデオディスク）など）、あるいは、現在知られているかまたは後に開発されるコンピュータ可読媒体の格納が可能な他の媒体を含む。

詳細な説明の項目で説明される方法およびプロセスは、コードおよび／またはデータとして具体化することができ、コードおよび／またはデータは、上記で説明されるように、コンピュータ可読記憶媒体に格納することができる。コンピュータシステムが、コンピュータ可読記憶媒体上に格納されたコードおよび／またはデータを読み取って実行する際、コンピュータシステムは、データ構造およびコードとして具体化されてコンピュータ可読記憶媒体内に格納された方法およびプロセスを実行する。

その上、本明細書で説明される方法およびプロセスは、ハードウェアモジュールまたは装置に含めることができる。これらのモジュールまたは装置は、これらに限定されないが、特定用途向け集積回路（ＡＳＩＣ）チップ、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、特定の時間に特定のソフトウェアモジュールもしくはコードの断片を実行する専用もしくは共有プロセッサ、および／または、現在知られているかもしくは後に開発される他のプログラマブル論理デバイスを含み得る。ハードウェアモジュールまたは装置が起動されると、ハードウェアモジュールまたは装置は、それらの中に含まれる方法およびプロセスを実行する。

上記の説明は、当業者が実施形態の作成および使用を行えるようにするために提示され、特定のアプリケーションおよびその要件の文脈において提供される。開示される実施形態への様々な変更は、当業者であれば容易に明らかであり、本明細書で定義される一般原則は、本開示の精神および範囲から逸脱することなく、他の実施形態およびアプリケーションに適用することができる。従って、本発明は、示される実施形態に限定されないが、本明細書で開示される原則および特徴と一致する最大範囲が与えられる。

Claims (23)

1. 多人数認証を容易にするためのコンピュータ実施方法であって、
   複数の認証補助ユーザをアカウントに関連付けることを求める第１の要求を、前記アカウントの所有者から通信モジュールを介して受信するステップと、
   前記アカウントを前記認証補助ユーザと関連付けるデータをストレージデバイスに格納するステップと、
   動作を実行することを求める第２の要求を、プライマリユーザから前記通信モジュールを介して受信するステップであって、前記第２の要求は、前記アカウントを前記認証補助ユーザと関連付ける前記データを格納するステップに続いて受信される、ステップと、
   プロセッサが、前記第２の要求における前記動作のタイプを判断するステップと、
   前記タイプが前記認証補助ユーザからの承認を必要とする第１の既定の動作タイプであると判断することに応じて、
   前記認証補助ユーザの各々に認証要求を送信するステップであって、前記認証要求は、前記アカウントの情報を含み、前記プライマリユーザの情報を含まない、ステップと、
   前記認証補助ユーザの全体より少なく、かつ第１の既定の閾値より大きい第１のパーセンテージである、前記認証補助ユーザの第１のサブセットから承認の応答を受信することに応じて、前記第２の要求を許可するステップと、
   既定の期間内に第１の認証補助ユーザから応答がないことを検出することに応じて、当該応答がないことを拒否の応答を受信したものとしてカウントするステップと、
   前記認証補助ユーザの前記全体より少なく、かつ前記第１の既定の閾値に基づく第２の規定の閾値より大きい第２のパーセンテージである、前記認証補助ユーザの第２のサブセットから拒否の応答を受信することに応じて、前記第２の要求を拒否するステップと、を含み、
   前記第２のサブセットから前記拒否の応答を受信する前に、前記方法はさらに、
   前記第２のサブセットのうちの少なくとも１人の第２の認証補助ユーザが、前記認証要求を受信するステップと、
   前記認証要求に応じて、前記少なくとも１人の第２の認証補助ユーザが前記拒否の理由を提供するステップと、
   前記通信モジュールが、前記少なくとも１人の第２の認証補助ユーザによって提供された前記拒否の前記理由を受信するステップと、を含み、
   前記第２のサブセットから前記拒否の応答を受信することに続いて、前記方法はさらに、
   前記プライマリユーザと関連付けられたデバイス上に、前記少なくとも１人の第２の認証補助ユーザによって提供された前記拒否の前記理由を表示するステップを含む、
   方法。
2. 前記タイプが前記第１の既定の動作タイプでないと判断することに応じて、前記第２の要求を許可するステップをさらに含む、請求項１に記載の方法。
3. 前記タイプが前記第１の既定の動作タイプであるかどうかを判断するステップが、
   少なくとも１つの既定のルールを前記受信された第２の要求に適用するステップをさらに含む、請求項２に記載の方法。
4. 前記既定のルールが、支払金額に基づく、請求項３に記載の方法。
5. 前記認証要求が、前記プライマリユーザによって注文された商品の情報、要求された支払金額、前記認証要求に関連付けられた時間情報のうちの１つまたは複数を含む、請求項１に記載の方法。
6. 前記認証補助ユーザの各々に前記認証要求を送信することに応じて、前記方法がさらに、
   前記認証補助ユーザの各々から応答を受信するステップと、
   受信された承認の応答の第１の数を決定するステップと、
   前記認証補助ユーザの総数に対する前記第１の数の比率が前記第１の既定の閾値より大きいかどうかに基づいて前記第２の要求を許可または拒否するステップと、を含む、請求項１に記載の方法。
7. 前記認証要求をそれぞれの認証補助ユーザに送信するステップが、電話番号、Ｅメールまたはインスタントメッセージに基づくテキストメッセージを前記それぞれの認証補助ユーザに送信するステップを含む、請求項１に記載の方法。
8. 前記第２の要求を拒否するステップが、前記プライマリユーザに拒否の理由を送信するステップを含む、請求項１に記載の方法。
9. 前記認証要求を送信するステップが、前記プライマリユーザが前記第２の要求を送信する際に使用される前記アカウントに関連付けられたそれぞれの認証補助ユーザを検索するステップをさらに含む、請求項１に記載の方法。
10. 前記プライマリユーザが要求する動作のタイプを承認するために必要となる認証補助ユーザの既定の閾値を特定することを求める閾値定義要求を前記プライマリユーザから受信するステップをさらに含む、請求項１に記載の方法。
11. 前記アカウントの所有者ではないユーザから、新たな動作を実行することを求める第３の要求を受信するステップと、
    前記アカウントの前記所有者によって特定された条件に基づいて、前記新たな動作がそれぞれの認証補助ユーザからの承認を必要とすると判断するステップと、
    前記それぞれの認証補助ユーザから第２の応答を受信するステップと、
    前記それぞれの認証補助ユーザから受信された前記第２の応答に基づいて前記第３の要求を拒否するステップと、をさらに含む請求項１に記載の方法。
12. 前記第２の要求を許可または拒否するステップが、
    前記アカウントに関連付けられたセキュリティ質問を前記プライマリユーザに送信するステップと、
    前記プライマリユーザから前記セキュリティ質問に対する正しい回答を受信することに応じて、前記第２の要求を許可するステップと、をさらに含む、請求項１に記載の方法。
13. 命令を格納する非一時的な記憶媒体であって、
    前記命令はプロセッサによって実行されると、前記プロセッサに多人数認証を容易にするための方法を実行させ、前記方法は、
    複数の認証補助ユーザをアカウントに関連付けることを求める第１の要求を、前記アカウントの所有者から通信モジュールを介して受信するステップと、
    前記アカウントを前記認証補助ユーザと関連付けるデータをストレージデバイスに格納するステップと、
    動作を実行することを求める第２の要求を、プライマリユーザから前記通信モジュールを介して受信するステップであって、前記第２の要求は、前記アカウントを前記認証補助ユーザと関連付ける前記データを格納するステップに続いて受信される、ステップと、
    前記プロセッサが、前記第２の要求における前記動作のタイプを判断するステップと、
    前記タイプが前記認証補助ユーザからの承認を必要とする第１の既定の動作タイプであると判断することに応じて、
    前記認証補助ユーザの各々に認証要求を送信するステップであって、前記認証要求は、前記アカウントの情報を含み、前記プライマリユーザの情報を含まない、ステップと、
    前記認証補助ユーザの全体より少なく、かつ第１の既定の閾値より大きい第１のパーセンテージである、前記認証補助ユーザの第１のサブセットから承認の応答を受信することに応じて、前記第２の要求を許可するステップと、
    既定の期間内に第１の認証補助ユーザから応答がないことを検出することに応じて、当該応答がないことを拒否の応答を受信したものとしてカウントするステップと、
    前記認証補助ユーザの前記全体より少なく、かつ前記第１の既定の閾値に基づく第２の規定の閾値より大きい第２のパーセンテージである、前記認証補助ユーザの第２のサブセットから拒否の応答を受信することに応じて、前記第２の要求を拒否するステップと、を含み、
    前記第２のサブセットから前記拒否の応答を受信する前に、前記方法はさらに、
    前記第２のサブセットのうちの少なくとも１人の第２の認証補助ユーザが、前記認証要求を受信するステップと、
    前記認証要求に応じて、前記少なくとも１人の第２の認証補助ユーザが前記拒否の理由を提供するステップと、
    前記通信モジュールが、前記少なくとも１人の第２の認証補助ユーザによって提供された前記拒否の前記理由を受信するステップと、を含み、
    前記第２のサブセットから前記拒否の応答を受信することに続いて、前記方法はさらに、
    前記プライマリユーザと関連付けられたデバイス上に、前記少なくとも１人の第２の認証補助ユーザによって提供された前記拒否の前記理由を表示するステップを含む、
    非一時的な記憶媒体。
14. 前記方法がさらに、
    前記タイプが前記第１の既定の動作タイプでないと判断することに応じて、前記第２の要求を許可するステップを含む、請求項１３に記載の非一時的な記憶媒体。
15. 前記タイプが前記第１の既定の動作タイプであるかどうかを判断するステップが、
    少なくとも１つの既定のルールを前記受信された第２の要求に適用するステップをさらに含む、請求項１４に記載の非一時的な記憶媒体。
16. 前記既定のルールが、支払金額に基づく、請求項１５に記載の非一時的な記憶媒体。
17. 前記認証要求が、前記プライマリユーザによって注文された商品の情報、要求された支払金額、前記認証要求に関連付けられた時間情報のうちの１つまたは複数を含む、請求項１３に記載の非一時的な記憶媒体。
18. 前記認証補助ユーザの各々に前記認証要求を送信することに応じて、前記方法がさらに、
    前記認証補助ユーザの各々から応答を受信するステップと、
    受信された承認の応答の第１の数を決定するステップと、
    前記認証補助ユーザの総数に対する前記第１の数の比率が前記第１の既定の閾値より大きいかどうかに基づいて前記第２の要求を許可または拒否するステップと、を含む、請求項１３に記載の非一時的な記憶媒体。
19. 前記第２の要求を拒否するステップが、前記プライマリユーザに拒否の理由を送信するステップを含む、請求項１３に記載の非一時的な記憶媒体。
20. 多人数認証を容易にするためのコンピュータシステムであって、
    プロセッサと、
    前記プロセッサと結合され、命令を格納するメモリと、を含み、前記命令は前記プロセッサによって実行されると、前記プロセッサに方法を実行させ、前記方法は、
    複数の認証補助ユーザをアカウントに関連付けることを求める第１の要求を、前記アカウントの所有者から通信モジュールを介して受信するステップと、
    前記アカウントを前記認証補助ユーザと関連付けるデータをストレージデバイスに格納するステップと、
    動作を実行することを求める第２の要求を、プライマリユーザから前記通信モジュールを介して受信するステップであって、前記第２の要求は、前記アカウントを前記認証補助ユーザと関連付ける前記データを格納するステップに続いて受信される、ステップと、
    プロセッサが、前記第２の要求における前記動作のタイプを判断するステップと、
    前記タイプが前記認証補助ユーザからの承認を必要とする第１の既定の動作タイプであると判断することに応じて、
    前記認証補助ユーザの各々に認証要求を送信するステップであって、前記認証要求は、前記アカウントの情報を含み、前記プライマリユーザの情報を含まない、ステップと、
    前記認証補助ユーザの全体より少なく、かつ第１の既定の閾値より大きい第１のパーセンテージである、前記認証補助ユーザの第１のサブセットから承認の応答を受信することに応じて、前記第２の要求を許可するステップと、
    既定の期間内に第１の認証補助ユーザから応答がないことを検出することに応じて、当該応答がないことを拒否の応答を受信したものとしてカウントするステップと、
    前記認証補助ユーザの前記全体より少なく、かつ前記第１の既定の閾値に基づく第２の規定の閾値より大きい第２のパーセンテージである、前記認証補助ユーザの第２のサブセットから拒否の応答を受信することに応じて、前記第２の要求を拒否するステップと、を含み、
    前記第２のサブセットから前記拒否の応答を受信する前に、前記方法はさらに、
    前記第２のサブセットのうちの少なくとも１人の第２の認証補助ユーザが、前記認証要求を受信するステップと、
    前記認証要求に応じて、前記少なくとも１人の第２の認証補助ユーザが前記拒否の理由を提供するステップと、
    前記通信モジュールが、前記少なくとも１人の第２の認証補助ユーザによって提供された前記拒否の前記理由を受信するステップと、を含み、
    前記第２のサブセットから前記拒否の応答を受信することに続いて、前記方法はさらに、
    前記プライマリユーザと関連付けられたデバイス上に、前記少なくとも１人の第２の認証補助ユーザによって提供された前記拒否の前記理由を表示するステップを含む、
    コンピュータシステム。
21. 前記方法がさらに、
    前記タイプが前記第１の既定の動作タイプでないと判断することに応じて、前記第２の要求を許可するステップを含む、請求項２０に記載のコンピュータシステム。
22. 前記タイプが前記第１の既定の動作タイプであるかどうかを判断するステップが、
    少なくとも１つの既定のルールを前記受信された第２の要求に適用するステップをさらに含む、請求項２１に記載のコンピュータシステム。
23. 前記認証補助ユーザの各々に前記認証要求を送信することに応じて、前記方法がさらに、
    前記認証補助ユーザの各々から応答を受信するステップと、
    受信された承認の応答の第１の数を決定するステップと、
    前記認証補助ユーザの総数に対する前記第１の数の比率が前記第１の既定の閾値より大きいかどうかに基づいて前記第２の要求を許可または拒否するステップと、を含む、請求項２０に記載のコンピュータシステム。

Images