JP6479769B2 - 顧客制御口座の施錠機能を提供する方法及びシステム - Google Patents

Description

関連出願のクロスレファレンス
この出願は、２０１３年４月２６日に出願されたアメリカ合衆国予備特許出願第６１／８１６，６３１の優先権を請求する２０１３年９月９日に出願されたアメリカ合衆国特許出願第１４／０２２，０４１の優先権を請求するものであり、両出願ともに本出願により全部にわたって一体化されるものである。

最近、一般の人が利用している電子口座の数は、大幅に増加している。この増加は、電子口座の不正アクセスにより生じた身元詐欺及び関連する損害への一般消費者が受けやすい傾向が相応の増加を伴っている。口座への不正アクセスは、消費者の経済的福祉を危うくし、社会全体に大きな詐欺関連コストをもたらすため、金融機関や支払サービスに関連付けられる電子口座は特に懸念されている。

近年、ユーザに電子口座のより高度なセキュリティを可能にするための方法が導入されている。その他の幾つかの進歩のうち、より緊密な検証プロトコルの作成及び実施の大幅な向上、より正確な不正検出方法及びより速い詐欺応答技術などを含んでいる。特に、消費者が知っていること、消費者が持っているもの、消費者は何者かという、それぞれの検証方法を組み合わせる検証プロトコルが身元詐欺や電子口座への不正アクセスの可能性を大幅に軽減している。更に、不正行為に関連する損害をより迅速に特定し、制限できるように、多くの技術が、潜在的な詐欺の対象になるデータを処理し、分析するため、より迅速な手段を利用しようとするだけでなく、通信を高速化する手段も利用している。しかし、悪徳当事者にとって、これらのシステムを回避するインセンティブは巨大であり、財務及び電子セキュリティ産業が継続的に一歩先を行くために革新する必要がある。

不正検出及び口座保護のための多くの方法は、取引に関与する様々な装置に対する及び装置間での暗号化された認証情報の作成、割り当て及び交換に集中している。従って、取引のために使用される装置は、これらの認証情報を格納し、操作するために十分に堅牢でなければならない。これは多くの場合、詐欺防止と口座のセキュリティために、専用の口座アクセス装置のオンボード処理やストレージコンポーネントを使用することによって実現される。

本発明の特定の実施形態において、口座を施錠するためのコンピュータ組込方法が提供される。この方法は、口座保有者からのＳＭＳメッセージを介して口座施錠リクエストを受信するステップを含んでいる。この方法は、また、ＳＭＳメッセージの受信に直接応答して、口座に設けられた施錠機能を係合するステップを含んでいる。この方法は、更に、施錠機能が係合されている間に口座からの資金の移動を制限するステップを含んでいる。

本発明の特定の実施形態では、電子金融口座の施錠機能をユーザに提供するためのコンピュータ組込方法が提供される。この方法は、ユーザに関連付けられた装置からサーバ装置に電子金融口座を施錠するためのリクエストを受信するステップを含んでいる。リクエストは、通信システムのショートメッセージコンポーネントまたはデータメッセージコンポーネントを介してルーティングされる。ユーザに関連付けられている装置は、通信システムを介して通信するために使用される。この方法は、また、サーバ装置と通信しているプロセッサを使用し、電子金融口座を施錠するリクエストに応答して、施錠口座コマンドを生成するステップを含んでいる。施錠口座コマンドが金融取引のための電子金融口座の利用を制限するために使用される。この方法は、また、サーバ装置において、電子金融口座を施錠解除するためのリクエストを受信するステップを含んでいる。この方法は、プロセッサを使用し、口座施錠を解除するリクエストに応答して、口座施錠解除コマンドを生成するステップを含んでいる。口座施錠解除コマンドは、電子金融口座に関連付けられた機能を回復するために使用される。ユーザは、電子金融口座の所有者である。

本発明の特定の実施形態において、電子決済口座にセキュリティを提供するためのコンピュータ組込方法が提供される。この方法は、電子決済口座を管理するステップを含んでいる。電子決済口座は、口座保有者が金融機関により管理されている支払口座から支払いを行うことができる。この方法はまた、口座保有者からサーバ装置に施錠リクエストを受信することを含んでいる。この方法はまた、施錠リクエストの受信に直接に応答して施錠コマンドを生成することを含んでいる。この方法はまた、金融機関に施錠コマンドを送信することを含んでいる。施錠コマンドは、支払口座に資金源口座からの振替を制限するよう金融機関に指示をする。

本発明の実施形態による口座制御システムのブロック図である。 本発明の実施形態による口座保有者の指示で口座を施錠するための一連の手段を示すフローチャートである。 本発明の実施形態による支払口座で使用する口座制御システムのブロック図である。 本発明の実施形態による電子金融口座のユーザ制御口座施錠機能を提供するための一連の手段を示すフローチャートである。 本発明の実施形態による資金源と支払口座との間に障壁を提供する方法を示すフローチャートである。

本開示は、電子口座に関する。特に、本開示は、電子口座の機能性及び電子金融口座へのアクセスを修正することに関する。以下の明細書では、説明の目的のために、多くの実施例及び具体的な詳細は、本開示の完全な理解を提供するために記載されている。しかしながら、本開示は、これらの実施例において、特徴の一部または全部、単独または以下に記載される他の特徴との組み合わせを含んでいること、また一般的に電子口座のアクセスとセキュリティの分野における経験を持つ者に知られている本特許出願に記載の特徴及び概念の変更及び均等物を含む得ることは、この分野の通常の知識を有する者にとって明らかであろう。

本特許出願では、様々な方法、プロセス及び手順が詳述されている。特定のステップが特定の順序で記載されているが、そのような順序は、主に便宜と明瞭さのためである。特定のステップは、複数回繰り返すことがあり、（それらのステップは他の方法で別の順序で記載されていても）他のステップの前後に発生することがあり、または他のステップと並行して発生する可能性があってもよい。第２ステップが開始される前に、最初のステップを完了しなければならない場合にのみ、第２ステップは、最初のステップに従うことが求められる。このような状況は、特に文脈から明らかでないときに指摘される。特定のステップは省略してもよい。省略が著しく別のステップに影響を与える場合にのみ、特定のステップが必要である。

本特許出願では、種々のコンピュータ組込方法、プロセス及び手順が記載されている。様々なアクション（受信、保存、送信、通信、表示など）は、アクションがユーザによって許可、開始または引き起こされても、また、ハードウェア装置がコンピュータプログラム、ソフトウェア、ファームウェアなどによって制御されても、ハードウェア装置により実行されると理解されるべきである。また、データが概念や実世界のオブジェクトを表すことができる場合であっても、ハードウェア装置がデータ上で作動していると理解すべきであり、従って、その限りにおいて、「データ」としての明示的なラベル付けが省略されているのである。例えば、ハードウェア装置は、「記録を格納する」と記載されている場合、それはハードウェア装置が記録を表すデータを格納すると理解されるべきである。

本特許出願に記載の本発明の特定の実施形態は、ユーザが口座に関連付けられた施錠機能を係合することにより、口座の機能性を制限することを可能にする。施錠機能は、ユーザ名とパスワードの組み合わせ、ＰＯＳ端末での個人識別番号（ＰＩＮ）のエントリーあるいは磁気ストライプカードまたは近接通信（ＮＦＣ）装置を使用して認証情報の提供などのような定期的にシステムにアクセスするキーの使用にかかわらず、口座へのアクセスを施錠するまたは口座の機能性を制限するメタキーの使用を含むことができる。蓄えられている資金の使用またはクレジットの提供を介して取引を行うことが可能である金融口座である状況では、施錠が係合中に施錠機能が口座からの資金の移動を制限することができる。施錠機能は、口座保有者が送信した施錠解除リクエストに応じて、施錠を係合または解除することができる。そのリクエストは、テキストメッセージまたはＳＭＳに対応した通信を介して送信することができる。このような状況では、テキストメッセージまたはＳＭＳの対応した通信の情報内容は、施錠メッセージまたは施錠解除メッセージと呼ぶことができる。一般に、本特許出願の施錠メッセージ及び施錠リクエストに関連する開示は、施錠解除メッセージ及び施錠解除のリクエストにも適用される。以下の開示では、テキストメッセージと全てのＳＭＳ対応の通信は、両方ともショートメッセージと言う。

図１は、本発明の具体的な実施形態に従って利用できるシステム１００を示す。システム１００は、口座保有者に関連付けられている装置１０１、ショートメッセージコンポーネント１０３を備えた通信システム１０２、サーバ装置１０４、口座１０５及びオプションの第２装置１０６を含んでいる。ユーザに関連付けられている装置１０１は、単に施錠リクエストを送信する目的のためにのみ一時的に関連付けることができ、または、より恒久的にユーザに関連付けることができる。例えば、ユーザに関連付けられている装置１０１は、ユーザの携帯電話であってもよい。また、装置１０１は、システム１００と共に使用するために特別に設計されたモバイル装置であってもよい。装置１０１は、通信システム１０２を介して使用することができる。通信システム１０２は、携帯電話ネットワーク、インターネット、知的財産で保護された通信ネットワーク、旧来の電話システム（ＰＯＴＳ）、またはこれらの様々なネットワークの任意の組み合わせを含むことができる。サーバ装置１０４は、図において、単一の機械として示されているが、口座施錠機能が多くの口座保有者に提供されるならば、本特許出願に記載の方法を促進するために、一般に、組み合わせて作動する複数の機械が必要とされることであろう。個々の機械は、同じデータセンター内にあってもよく、または、口座施錠機能が提供された地理的に広いエリアに拡大してもよい。このような本特許出願に記載の実施形態と組み合わせて使用されるサーバ装置１０４のようなサーバは、代替組織が管理する口座１０５を補強するために使用されるスタンドアローン機能として、口座施錠機能を提供する組織体によって実行され得る。しかし、サーバ装置１０４などのサーバは、また、口座１０５を管理する同じ組織体によって提供され得る。例えば、支払サービスプロバイダは、両方の口座１０５を管理し、サーバ装置１０４を操作することができ、口座のセキュリティサービスプロバイダは、別の組織体によって提供される電子口座１０５に追加のセキュリティを提供するために、サーバ装置１０４を操作することができる。

任意の第２装置１０６は、施錠リクエスト及び／または施錠解除リクエストを送信するために使用できる。任意の第２装置１０６は、異なる当事者が施錠機能の係合に参加できるようにすることができ、または、２つの異なるチャネルを介してユーザにサーバ装置１０４と通信することを要求することによって、システム全体のセキュリティの追加のレイヤを提供することができる。任意の第２装置１０６がユーザに関連付けられている状況の例としては、任意の第２装置１０６は、パーソナルコンピュータ、ユーザの自宅の電話、専用アプリケーションを実行しているスマートフォン、または、サービスプロバイダが提供する施錠解除リクエストを発する目的とする特別な装置であってもよい。任意の第２装置１０６がユーザの他に誰かの制御下にある状況の例として、不正監視サービスまたは他の口座サービス組織体は、様々なリソースからの情報を収集し、そして、これらのソースを使ってなされた決心基づいて、施錠解除リクエストを発することができる。このサービスは、例えば、電話を介してユーザに連絡し、口座が施錠された理由または施錠解除リクエストが発せられた理由をユーザに求めることができる。また、口座が施錠された状況では、口座の施錠を解除することを許可する前に、特定のセキュリティチェックを実行することができる。任意の第２装置は、通信システム１０２を使用してサーバ装置１０４と通信することができ、より一般的にはインターネット、物理的なメール、ファックス、携帯電話ネットワーク、有線電話ネットワーク、またはサーバ装置１０４と第２装置１０６との間の通信を容易にするために構成された専門のネットワークのような通信の任意の形式を介してサーバ装置と通信することができる。図示されているように、第２装置１０６は、上述した２つのチャネル通信の増強したセキュリティを提供するために、別個のチャネルを介してサーバ装置１０４と通信を行う。

図２は、施錠機能が金融口座のために提供される本発明の様々な実施形態を説明するために使用することができる方法２００を図示している。方法２００は、口座保有者から、ショートメッセージを介して、口座が施錠リクエストを受信するステップ２０１から開始する。例えば、ステップ２０１は、装置１０１とする携帯電話を介して、口座保有者から口座１０５を施錠するためのリクエスト及びショートメッセージコンポーネント１０３を受信するサーバ装置１０４を含んでいる。ステップ２０２では、ステップ２０１に受信されたリクエストの受信に応答して、施錠機能が係合される。ステップ２０３では、施錠機能が係合されている間に、口座からの資金の移動が制限される。ステップ２０１がショートメッセージを送信する口座保有者によって早められ得るという事実は、高帯域通信回線を介して高度な電子装置について例示されたウェブポータルとは異なり、口座保有者が自分の携帯電話の使用及び標準無線電話通信ネットワークを介して、ほとんどの場合にショートメッセージサービスにアクセスすることができるという重要な利点を提供する。また、ショートメッセージは、施錠リクエストが音声回線電話システムを経由して送信された場合に必要とされる大規模なグループの顧客サービス担当者を雇用することなく、システム１００によって処理することができる。また、対話型音声認識（ＩＶＲ）サービスを使用してこのようなシステムが実装された場合でも、同じメッセージを提供するために聴覚チャネルを介してＩＶＲシステムにダイヤルすることよりも、施錠リクエストは、一般的に非常に少ない情報を必要とし、短いメッセージを送信することが容易であるため、ショートメッセージシステムの使用はより便利である。

方法２００のいくつかの変形例は、ステップ２０１において送信された施錠メッセージの結果と、その後、施錠機能が係合している間に、口座の機能性が制限される程度によって異なる。例えば、口座が金融口座の場合では、施錠リクエストは、施錠リクエストが口座の内外での口座全ての転送を完全に停止するよう、口座に発生する全ての金融取引を防止することができる。例えば、限定されている機能性は、格納された価値口座に関連付けられたデビット機能の全て、または、クレジット口座のラインに関連付けられた全てのデビット機能であってもよい。別の実施例として、デビットカード口座は、ＡＴＭでの現金の引き出し、またはＰＯＳ端末でのデビットカードを使用した購入するため使用の制限をしてもよい。一般的に、口座への資金の流入に関連した詐欺の危険がより少ないため、そのようなアプローチは、有用性の減少がより限られている、追加されたセキュリティに関して魅力的な取引を提示する。同じく、方法２００は、また、施錠機能が係合中、資金の事前承認に基づく振替が許可される可能性があるステップ２０４から構成し得る。従って、施錠リクエストの導入にもかかわらず、サーバ装置１０４または口座１０５による施錠リクエストの受信に先立って承認された取引が予定通り継続される。この機能のより具体的な実施例は、他の振替が制限されている一方で、口座の内外に生じることが許される自動請求書の支払いまたは直接預金給与支払額の支払いを許可することである。同様の実施例として、施錠が係合中の場合でも、出費口座の自動トップアップ機能は受け入れられたままにすることができる。

口座施錠が係合中の口座の機能性の低下は、取引の特定の分類に使用する口座の不能性につながることがある。この分類は、取引に関与する商人、取引に関連する商人の特定の識別性、取引の地理的位置、取引時間、取引に関わる金額、または関連する取引の頻度という種類によって設定することができる。施錠機能は、特定の商人、特定の物理的な店舗、またはキャッシュアクセスの場所での口座の使用を防ぐことができ、あるいは、その代わりに、特定の商人、物理的な店舗、または、キャッシュアクセスの場所での使用を除き、全ての他の目的のための口座の使用を防ぐことができる。地理的な制限に関しては、施錠機能は、口座保有者の郵便番号の範囲外に配置されているＰＯＳ端末での口座の任意の使用、オンライン取引における口座の任意の使用、または、口座保有者によって特定された事前の選定場所とは別の州や国における口座の任意の使用を防ぐことができる。施錠機能は、所定の金額を超えた全ての取引の口座の使用を防ぐことができる。許可されていない取引の分類は、施錠リクエストを受信する前に事前に承認されなかった全ての取引であり得る。許可されていない取引の分類は、また、多数の大速度の取引に先行された又は同時に起った取引、または、多数の大速度を伴う取引あるいは一定の金銭的な閾値を超えた数限られた全ての取引であり得る。

施錠機能が係合中の口座の機能性の低下は、また、口座に関連付けられた自動化のレベルであるかもしれない。例えば、機能性の低下が口座に関連付けられた検証ステップ数の増加に関連することがあり得る（例えば、施錠機能は、普段、取引が検証ステップなしで実行される場合、取引を実行するためにＰＩＮまたは２ステップの検証が必要とされるモードに口座を切り替える）。別の実施例として、検証ステップ数の増加は、各取引が、装置１０１などのユーザ装置を介して確認されなければならないという要件を含むことができる（例えば、施錠機能が係合されているときに、ユーザ装置１０１を介して各取引のための確認応答をリクエストする確認リクエストがユーザ装置１０１に送信される）。別の実施例として、検証ステップの増加数は、ユーザが事前の取引を事後に承認するリクエストを含むことがあり得る。より具体的に、「任意の町におけるドラッグストアでも＄５．６８の支払いを確認してください」という取引の詳細を含む取引を行った後、ユーザ装置１０１にＳＭＳメッセージを受信することがあり得る。ユーザがＳＭＳ応答で取引を確認し、そうしない限り、自分の口座を別の取引のために利用できない。このアプローチの利点は、ユーザが迅速に取引を行うことができ、自分の都合の良い時に、取引の間に取引を確認する追加のステップを扱うことができるということであろう。これは、更に、口座に対するセキュリティの高度性を提供しながら、取引を行うことができる速度を加速させるであろう。

口座の機能性を低下させることとは別に、施錠機能は、また、口座が取引の確保により資する状態に置かれることもある。例えば、施錠機能は、口座の全ての取引が、口座保有者に通知が送信されることにつながる状態に口座を設定することができる。このアプローチは、各取引がユーザによって検証されるという要件のために口座の自動化が低下することとは異なり、その理由は取引が口座保有者による更なるアクションなしで承認される。また、口座保有者が承認または開始しなかった取引が行われた場合、口座保有者は、その取引をほぼ瞬時に検出することができるので、口座はまだ詐欺を容易に抑止することができる状態にある。この機能は、施錠リクエストが送信される前に、事前に承認されていない取引の場合のみに、アラートが送られるように設定でき得る。アラートは、上記の構成可能な施錠機能によってスクリーニングされた取引の場合に送信されるように、設定することができる（例えば、アラートは、特定の地理的領域外の取引、または特定の加盟店での取引の場合に送信される）。最後に、不正監視システムによる懸念が十分な程度に上昇した取引だけが、ユーザへの通知のトリガとなるような機能も、また、設定することができる。

上記の口座１０５のための施錠機能の特性は、ユーザ、施錠機能の管理者、または口座の管理者によって設定し得る。プリセットは、装置１０１を介して、ショートメッセージコマンドの使用を含む任意の数のチャンネルを介してユーザが構成することができる。別の実施例として、ユーザがウェブポータルにアクセスし、施錠機能が係合した後でも、口座がまだ正常に機能するように特定の商人、特定の物理的な店舗、または、特定の地理的な場所を選択することができる。また、ユーザは、金融口座の全ての使用がカットオフされる選択することにより、または、ＡＴＭでの現金引き出しなどの他の機能性が許容されながら、オンライン購入またはＰＯＳ取引など、特定の用途のみが限定されるように選択することにより、口座の機能性を低下させる構成とし得る。口座の管理者に施錠機能を構成できる能力を提供することによって、口座の使用を制限する施錠機能の程度に合わせて、管理者が特定のユーザに関連するリスクのレベルを調整できるようになり、格別な利点を提供し得るであろう。例えば、口座の管理者は、不正取引の発生率が高いことに気づいた領域のガソリンスタンドでの全ての口座の使用を停止するように、施錠機能を設定することができる。

方法２００の変形例も、また、施錠及び施錠解除機能の相対的な特性に関して異なる。前述したように、本特許出願に記載の本発明の特定の実施形態では、ユーザは、口座を施錠解除することによって、施錠機能が係合されたときに削除された口座の機能性を回復することができる。この施錠解除アクションは、最初に口座を施錠するために使用され、記述されたものと同じメタキーを含むことができる。本特許出願の施錠アクションがリクエストされ、開始され、また、実行される方法に関する全ての開示は、施錠解除アクションがリクエストされ、開始され、また、実行される方法に適用される。しかしながら、本発明の実施形態は、同じ方法及びシステムが施錠アクション及び施錠解除アクションに適用される状況に限定されるものではない。実際に、本開示は、具体的に、アクションが異なる方法及びシステムを使用して処理されている実施形態を含んでいる。例えば、施錠リクエスト及び施錠解除リクエストは、サーバ１０４への異なる経路を通ってもよい。施錠アクションはユーザの携帯電話から送信されるショートメッセージを介して開始することができるが、施錠解除アクションは口座管理サービスに電話を介して送信することが必要になることがある。他の例として、施錠リクエストは、ショートメッセージサービス１０３を介して送信することができる一方、施錠解除リクエストは、ウェブブラウザを介してアクセス可能なウェブポータルを介して送信される。ウェブポータルは、任意の第２装置１０６によって提供できる。施錠リクエスト及び施錠解除リクエストは、サーバに送信される方法に応じて変化することができるという事実とは別に、それらの効果に応じて変化することができる。一般的に、施錠リクエスト及び施錠解除リクエストはそれぞれを打ち消しあうが、施錠解除リクエストは、口座をアイドル状態から施錠状態に転換することができ、そしてアイドル状態から特性が異なる施錠解除状態に遷移するような、別の特性を持ってもよい。施錠解除アクションは部分的に低下した機能性を回復することができ、機能性が完全に回復される前に、追加の手順に従うことが必要になる場合がある。実際には、本特許出願で提供される様々な特定の施錠リクエスト及び施錠解除リクエストの実施例は、任意の組み合わせで使用することができるが、一般的に、任意の開示された施錠リクエストまたは施錠解除リクエストが相手の作用を逆転するマッチングする施錠リクエストまたは施錠解除リクエストと組み合わせることが想定されるべきである。

施錠リクエスト及び施錠解除リクエストを異なるチャネルを介して提供するように要求することで特定の利点を実現することができる。まず、口座の施錠アクションの効果は、一般的に、施錠解除アクションより詐欺のリスクを軽減させ、口座保有者のより多くの不満の危険性を生じる。そのため、施錠機能が提供すべきリスクの相対的な関心事及び口座保有者の利便性に応じて、それぞれのアクションは、より利便性はなくなるが、より安全であるチャネルに限定することができる。詐欺は主な関心事だった例では、施錠リクエストは、ショートメッセージサービス、ウェブポータル、または、当面の消費者代表やＩＶＲシステムへの電話の呼び出しを介して受けてもよいが、施錠解除リクエストは、当面の消費者代表への電話の呼び出しによってのみ受けることができる。異なるチャネルが他のものよりも安全であることはさておき、２つの通信チャネルは危険に曝される可能性が少ないので、施錠機能にアクセスするために必要とする複数のチャネルを持つことの必要性自体がセキュリティを提供することになる。

本特許出願中に開示された方法の大部分は、口座の名目上の状態を施錠解除状態として取り上げているが、本開示は、このような方法で使用される方法を制限するものではない。実際、施錠された状態で名目上の口座を保ち、口座保有者がすぐに口座を使用するために必要とされる場合にのみ、口座の施錠を解除するために、本特許出願の記載による便利な施錠及び施錠解除手順を利用することによって、多くの利点を実現することができる。より詳細に後述するように、テキストメッセージまたは以下で記載する他の方法を経由して口座を便利に施錠または施錠解除する可能性は、保有者に取引を行うための必要な間だけ口座を施錠解除させることができ、その後、口座を施錠状態に戻す。

方法２００の特定の変形例は、また、施錠機能または施錠解除機能の一時的な性質に関して異なっている。施錠機能または施錠解除機能は、その持続時間が制限されることため、一時的である。施錠解除機能を備えた金融口座の場合は、限定された取引回数が許容されているか、施錠機能が再係合される前に一定の金融手当が費やされ得るという機能が一時的であってもよい。例えば、方法２００は、施錠リクエストの期間が一時的に制限される２０５、２０６及び２０７のステップを含むことができる。ステップ２０５では、口座の施錠機能が解除される。ステップ２０６において、施錠機能が係合された時間を測定することができる。ステップ２０７では、監視対象期間が予め設定された期間を超えたときに、施錠機能を外すことができる。予め設定される時間は、口座の施錠リクエストを受信する前に口座保有者から受信した通信によって設定することができるか、口座の管理者によって予め設定することができる。

施錠と施錠解除状態の一時的な性質に関して、施錠リクエスト及び施錠解除リクエストは、ユーザによって設定可能である。例えば、ユーザは、口座が施錠解除される特定の期間を選定することができる。これは、単一の設定時間であってもよいし、繰り返しの期間であってもよい。ユーザは、全ての平日午前中に口座の停止を解除し、他の全ての期間は口座を停止したままとする指定ができる。ユーザは、口座が１５分間施錠解除状態のままを保ち、自動的に施錠状態に戻す指定ができる。別の実施例として、ユーザは、口座が自動的に施錠状態に戻る前に、施錠解除期間に取引回数または費やすことができる特定の金額を選定することができる。もっと具体的には、ユーザは、＄１００分の支出または合計５回の取引のために口座を削除することができる。口座が＄１００分の支出または合計５回の取引のために使用された後、口座が施錠状態に戻る。ドル限度は、ドル金額を超える最終的な取引が拒否されるようなハードシーリング、またはドル金額を超える最終的な取引が、口座が施錠状態に戻る前に、先に承認されるようなソフトシーリングに設定することができる。施錠と施錠解除状態の一時的な性質に関して、施錠リクエスト及び施錠解除リクエストは、サーバ１０４及び／または口座１０５の管理者によって設定が可能である。例えば、管理者は、施錠解除アクションの持続時間を一定の時間に限定されるよう義務付けることができ、ユーザがその予め設定された最大限度を超える期間を設定させないことができる。ユーザによって設定可能な一時的制限のいずれかが管理者によって設定されたシーリングを持つことができる。

方法２００の変形例は、また、施錠リクエストを依頼するメッセージの内容に関して異なるものである。別の例として、施錠機能の複数の種類が単一の口座に許容されている状況では、メッセージは、内容を介して、現在どの施錠機能がリクエストされているかを示すことができる。従って、方法２００は、口座の第２の施錠リクエストが受信されるステップ２０７及び第２の施錠機能が係合されるステップ２０８を含むように変更することができる。２つの施錠機能は、口座の機能性を阻害する程度が異なることがある。機能は、施錠リクエストまたは施錠解除リクエストが必要とする情報の内容に関して異なることがある。ショートメッセージを介して送信される施錠リクエストの場合には、ユーザが特定の施錠リクエストを送信するために必要なテキストの内容の種類を記憶する必要があることから、各施錠リクエストを送信する利便性に対して利用可能な機能の範囲間にトレードオフがつくられる。

施錠リクエストメッセージは、様々な形態をとることができる。例えば、リクエストは、装置１０１を介してユーザから送信されるテキストメッセージでありうる。テキストメッセージは、ＰＩＮのような、具体的にユーザを特定する口座サーバ１０４に知られているコードを含むことができる。テキストメッセージは、特定の電子口座を識別するための情報を含んでいることができる。これは、システム１００は、単一のユーザが独立した複数の口座を施錠することを可能にする場合に特に有用である。しかし、このようなシステムでは、グローバル施錠コマンドが、単一の施錠リクエストに基づいて、複数の口座に送信することができるので、ユーザが特定の口座を識別することを必要としない。テキストメッセージは、施錠機能がリクエストされているかどうか及び施錠機能のどの種類がリクエストされているかを識別するためのテキスト文字列を含めることができる。これは、システム１００は、ユーザが装置１０１を介して複数の機能を実行することを可能にする場合に特に有用である。例えば、ユーザは、ショートメッセージサービスを介して自分の口座残高にアクセスすることができる場合、テキスト文字列「ＬＯＣＫ」を使用して特定された施錠リクエストをテキスト文字列「ＢＡＬ」を使用して区別できる。

別の施錠機能は、別のテキスト文字列によって識別することができる。例えば、モバイル装置を介して口座の全ての取引を承認するユーザからの確認を必要とする状態に設定された口座の施錠機能は、「ＣＯＮＦＩＲＭ」テキスト文字列を含んでいる施錠リクエストメッセージを使用して係合され得る。他の例として、事前承認取引がまだ許可された状態に口座を設定するメッセージからメッセージを区別するために、「ＦＲＥＥＺＥ」または「ＦＲＺ」などのテキスト文字列を使用して、口座を全ての取引が許容されない完全にシャットダウン状態に設定できる。この施錠リクエストメッセージの代替種は、テキスト文字列「ＳＴＯＰ」を使用して特定することができる。

別の施錠解除機能は、同様に別のテキスト文字列によって識別することができる。単一のコマンドが施錠状態の間で口座を切り替えるために使用できるように、口座が施錠機能の特定の種類のみを提供する状況においても、施錠機能を係合している状態と係合していない状態の間に切り替えるため、２つの異なるコマンドがユーザから必要とされるようなシステムを設計することが有益である。２つのコマンドを必要とすることで、自分の口座がどの状態に置かれているかをユーザが忘れることを防止することになるであろう。別のテキスト文字列の例としては、前述の「ＳＴＯＰ」の機能は、その特定の施錠を解除するには、「ＵＮＳＴＯＰ」コマンドとペアにすることができる。施錠コマンドと同様に、施錠解除コマンドも、特定の口座を識別するため、または、口座の状態の変更をリクエストする当事者の身元を確認するための追加情報を必要とし得る。係合された特定の施錠及び施錠解除の機能の特定の変化に関する情報を含んでいるように、テキスト文字列を修正することができる。例えば、テキスト文字列「ＵＮＳＴＯＰ１０」は、「ＳＴＯＰ」コマンドに対応する特定の施錠された状態に戻る前に、口座保有者が自分の口座を１０分間施錠解除状態に切り替えることを望んでいることを示し得る。ユーザが、一時的または金融的制限に基づいて、一時的な施錠解除期間を指定することができるように、施錠機能をより高度に変化させた状況において、２つを区別するためにドル記号などの追加シンボルを使用することができる。例えば、「ＵＮＳＴＯＰ＄１０」はユーザに＄１０が費やされるまで口座の施錠を解除したいことを示し、「ＵＮＳＴＯＰ１０」はユーザが１０分間自分の口座の施錠を解除したいことを示す。

ＰＩＮが必要とされ得るが、施錠リクエスト及び施錠解除リクエストメッセージには、必ずしも、そのユーザを識別するためにユーザが入力した情報を含む必要はないであろう。代わりに、ユーザのアイデンティティを、通信自体の性質から決定することができる。例えば、サーバ１０４は、通信システム１０２を介して送信されたテキストメッセージから情報を剥ぎ取ることにより、ユーザの識別を決定することができる。これらの状況では、口座保有者のアイデンティティを決定するために、メッセージから発信者ＩＤ情報を剥ぎ取ることができる。リクエストはまた、ソフトウエアトークン発生器または装置１０１によって生成されるリクエストに追加されるハードウェア識別子などの装置１０１に関連付けられたユーザ識別情報で満たすことができる。ハードウェア識別子は、ＳＩＭチップまたは任意の不揮発性記憶装置のようなリムーバブルメモリによって製造または追加されるため、装置内のＲＯＭ内に符号化することができる。ハードウェア識別子は、装置が製造された後の装置１０１のサブシステムによって検出された装置に関連付けられた欠陥シグナチャーであってもよい。ユーザは、装置１０１によって取り込まれた任意の種類のバイオメトリック入力、または、装置１０１と組み合わせて使用できるサービスプロバイダが出するユーザ識別子を使用して識別することができる。

方法２００のある変形態様は、また、施錠機能が関連付けられた口座のタイプと、どのような種類の振替がステップ２０４において許容されるかについて異なっている。図１をもう一度参照すると、電子口座１０５は、どのような電子口座でもよい。例えば、その口座は、オンラインショッピングポータル、電子メール口座、オンラインメディアアクセス口座、銀行口座、または、オンラインサービス口座のように、サービスを管理するために使用される口座でもよい。一般に、この特許出願において記載される電子口座１０５は、そのような口座と類似のものでよく、従って、本発明の譲受人によってその全部が所有され、あらゆる目的についてその全部が参考として関連している、２０１３年１月３１日に出願された「自己認証ピアツピア取引」と題するアメリカ合衆国特許出願第１３／７５５，４２１号、２０１３年３月５日に出願された「複数の事前承認レベルを伴う取引」と題するアメリカ合衆国特許出願第１３／７８６，４０８号及び２０１３年３月１４日に出願された「資金源選択性のある購入方法」と題するアメリカ合衆国特許出願第６１／７８２，５９３号に記載されている、付随する全ての機能を包含し得る。より一般的には、当該口座は支払口座に関連付けられた資金源であり得るし、ステップ２０４で許容される振替はその口座から直接実行される標準的な支払いであり得るが、ステップ２０３で制限される振替は資金源から支払口座への振替である得る。

図３は、より具体的に、システム１００における口座１０５とサービス装置１０４の相互関係を図示したものである。そのシステムは、当該口座が支払口座に関連付けられているという特殊な状況にあり、その支払口座は支払サービスによって管理されており、当該支払サービスは金融機関によって維持された口座に蓄えられた関連資金を有している。システム３００は、図１に示されているサーバ装置１０４を備えている。図３によって図示されている実施形態では、サーバ１０４が支払サービスによって管理され、口座保有者に支払口座１０５の制御を提供するために利用される。支払サービスは、ユーザにサーバ３０１及び預金またはクレジット口座３０２を管理する金融機関と共同して、口座１０５に蓄えられた資金に対するアクセスを与える。システム３００に示されている金融機関によって管理される２つの口座は、資金源として使用される要求払預金口座３０３と、支払システムを使用する支払いを実行するために使用する支払サービスユーザ口座３０４である。要求払預金口座３０３は、金融機関により管理されているどのような種類の標準口座であってもよい。口座３０３及び３０４は、別々の金融機関によって管理され得る。支払システムの「金銭の入金」または「金銭の出金」のために、資金は、口座３０３及び３０４間を振替する。金融機関の制約事項を条件として、支払サービスはその口座保有者に、当該２つの口座の間で金銭の振替機能を提供するので、支払口座１０５は、金銭が口座間で流動するチャンネルと一体となるように図示されている。この特定の例においては、施錠リクエストは特殊な種類の取引が生じないようにすることができる。この特定な施錠機能が作用するとき、口座３０３から３０４への金銭の流動を全くなくすことができる。口座保有者は、支払サービスによってどの程度の金銭が信用の対象となるのかを決定することができ、自己資金の残額を安全に保つ施錠リクエストの付加的セキュリティに依存しつつ、支払口座の利用可能資金の便宜を得ることができるから、このことは有益である。その他の実施形態では、施錠機能は、人々がシステムから承認されていない方法で金銭を振替することを防ぐために、どちらの方向にも金銭の流動をしないように設定され得る。

電子口座のために、ユーザ制御の口座施錠機能を提供する、コンピュータで実行される他の方法４００が、図４に図示されている。電子口座は、口座１０５を参照して上述された口座のいずれでもよい。方法４００は、施錠リクエストを受信するステップ４０１を含んでいる。本発明の特定の実施形態では、ステップ４０１の施錠リクエストは、サーバ装置１０４のようなサーバ装置で、装置１０１のようなユーザと関連付けられた装置から、受信される電子口座１０５のような電子口座を施錠するリクエストである。本発明の特定の実施形態では、そのリクエストはショートメッセージ１０３のようなショートメッセージを有する通信システム１０２のような通信システムを介して伝送される。本発明の特定の実施形態では、当該装置が通信システム１０２のような通信システムを介し行う通信に使用される。

方法４００は、施錠コマンドを生成するステップ４０２を含んでいる。本発明の特定の実施形態では、ステップ４０２は、サーバ装置１０４のようなサーバ装置と通信状態にあるプロセッサによって実行される。この関係はサーバ装置１０４の一部であるプロセッサの可能性を排除しない。発明の特定の実施形態では、施錠コマンドはステップ４０１を施錠するリクエストに応じて生成され、電子口座１０５のような電子口座に関連付けられた機能性を制限するために使用される。ステップ４０２は、施錠リクエストを送るために使用されるメッセージの内容に基づいて、生成するタイプの施錠コマンドを識別することから構成される。例えば、関連付けられた口座が単一種類の施錠リクエストについて修正のみできた状況では、施錠リクエストが受信されたときに、更に処理されずに施錠コマンドが発生されることがあり得た。しかし、複数の可能性のある施錠機能が異なった口座のために利用できる状況では、施錠リクエストは施錠コマンドを生成するために分析される必要があり得る。以前に考察した例を使用するために、施錠リクエストは“ＳＴＯＰ１０”のような文字列を含み、ステップ４０２が口座に対するアクセスが１０日間限定された状態に保持されるべきと判断する、そのコマンドを詳細に分析することから構成される。施錠コマンドに対する施錠リクエストメッセージの内容を実際に解読することについては、送られるコマンドが求められた結果をもたらすように、前もって口座保有者に提供されるインストラクションに依存する必要があることもある。４０２の施錠コマンドの生成は、施錠リクエストが受信され、実行に移されたことの確認をユーザに返信することを含んでいる。例えば、文字列“ＳＴＯＰ１０”を受信した後で、「停止が１０日間口座に設置されました」というテキストメッセージが口座保有者の電話に送られ得る。そのテキストメッセージはどのような機能が当該停止によって制限されたかの記述とその特定施錠機能を解除する方法についての指示もまた含むことができる。

施錠コマンドはいろいろな方法で電子口座１０５に影響を及ぼすことができる。例えば、サーバ装置１０４と電子口座１０５が同じ当事者によって作動されているならば、サーバは共通のファイヤウオールの背後の電子口座と通信し、その口座に機能性を制限するよう直接に指示することができる。電子口座１０５とサーバ１０４が異なった当事者によって管理されているならば、コマンドは公的または私的なネットワークによって送信され、電子口座１０５の管理者によって選択的に取り扱われ得る。管理者とサーバ装置１０４と１０５の通信は、公的または私的なキー暗号化標準の組み合わせを使用して暗号化され得る。他の実施例として、サーバ装置１０４の管理者は、電子口座１０５の施錠機能が稼働されるべきことを依頼するために、２当事者の従業者間で電話交信のような他の手段を介して、電子口座の管理者と連絡することができる。本発明の特定の実施形態では、施錠コマンドが発生され、電子口座に伝えられ、一切の人為的介在なくして、または、更なる処理をせずに、そのコマンドは自動的にその効果を奏する。従って、施錠コマンドが発生され、電子口座に伝えられ後、そのコマンドは直接その効果を奏する。

方法４００は、施錠解除リクエストを受信するステップ４０３を含んでいる。本発明の特定の実施形態では、ステップ４０３が施錠解除リクエストを受信するサーバ装置１０４のようなサーバに関与する。施錠解除リクエストは、ユーザ装置１０１のようなユーザに関連付けられた装置によって送信され、選択的には装置１０６によって送信され得る。上述した通り、施錠解除リクエストは、一般的には、施錠リクエストと調整されている。そのリクエストの内容は、ユーザを識別し、解凍されるべきではない口座を特定し、その結果、未解凍行動で回復するための特定の機能性について、その程度をもまた特定することができる。リクエストが受信されたという事実は、特定の口座と機能性がそのリクエストに関係しているという推定に使用され得る。簡単な例としては、リクエストは、最小の情報を必要とする施錠された状態と施錠解除された状態間の簡単なトグルであったというような特定がされる１レベルの機能性を持った１つの口座システムである。同様に、上述した通り、メッセージ自体はユーザを識別するために使用でき、予め定義されたルール集は、特定の口座と回復する機能性の特定の程度に対するリクエストの内容を図表にすることができる。

前述したように、施錠と施錠解除のリクエストは、口座保有者の携帯電話からショートメッセージサービスを介して、または、口座保有者から施錠機能の管理者にメッセージの伝送をするその他の通信チャンネルを介して、送信され得る。施錠と施錠解除機能は、ユーザが特定の場所にいるという信号を発する位置識別サービスによってトリガされるユーザに関連付けられた装置から送られたコマンドに基づいて、共にまた開始され得る。例えば、ユーザが特定のエリアにいたときに、ユーザの電話のＧＰＳロケータが、ショートメッセージを自動的に送信するアプリケーションで構成され得る。他の実施例として、特定された商人は、ユーザ装置をトリガして、サーバ１０４のようなサーバにメッセージを送信する、ユーザ装置との通信を行う無線ローカルエリアネットワークに関する知的財産で保護されている標準を使用し得る。商人はユーザが特定の場所に入ったとき検出できるユーザ装置に関連付けられた識別子によってユーザを識別できる。その識別子は上述の知的財産によって保護を受けているネットワーク、ＦＦＩＤリーダまたはどの種類でもよいＮＦＣシステムを使用して検出することができる。ユーザが自己の住所の郵便番号から離れたことが検出されると、自動的に施錠リクエストをユーザ装置に送信させることによって、ユーザが旅行のとき、ユーザが自動的に自己の口座を施錠するアプローチもまた実行できた。これらの実施形態は、予め規定されたエリアに出入りすることを除いて、ユーザにとって確認行為を要しない。

ユーザが特定の場所にいると表示する確認行為を介して、口座保有者の装置から施錠及び施錠解除が送信されることができる。これらの実施形態に従って、商人はユーザが相互作用できるその店のＮＦＣタグまたはＱＲコード（登録商標）を表示して、自己の装置からサーバ１０４のようなサーバに施錠または施錠解除リクエストを送信するように、ユーザの装置をトリガすることによって、確認的に口座を施錠解除することができる。例えば、チェクアウトカウンタにいるユーザはＱＲコードを走査して、自分の電話からサーバ１０４に施錠解除リクエストを送信でき、取引が終了していたら、ＱＲコードをもう一度走査して施錠リクエストを送信することができる。これらのアプローチは、ユーザが実際に店にいて取引を行うまで、ユーザが自己の口座を施錠状態に保持することを有益的に許容するであろう。

地域的に自動リクエストがサーバ１０４に送信される態様は、管理をする口座１０５に責任を持つ当事者によって予め構成され得る。しかし、当該態様は、口座保有者自身によっても構成され得た。口座保有者は、例えば、施錠または施錠解除リクエストが施錠機能を持った管理者に自動的に送信されるよう、特定場所を構成することができる。その特定場所は、特定の地域または場所のインターラクティブマップを参照するウエブアプリケーションを介して、ユーザによって設定され得る。地理的な場所は、口座保有者が、特定の商人を選定して自動的に設定することができる。ユーザによって提供された商人選定情報は、口座の管理者によって知られている場所情報または施錠機能と組み合わされ、口座保有者が選定された商人によって運営されている店舗に入ったときはいつでも、施錠または施錠解除リクエストが送信されることができる。例えば、管理者は、商人システムによって自動的に検出されるユーザリストに口座保有者を追加することができる。その代わりに、管理者は商人の位置に関連付けられたＧＰＳ座標の所定リストに依存することができ、ユーザ位置がそのリストの座標に整列したときはいつでも、施錠または施錠解除リクエストを自動的に送信することができる。口座保有者は、また、スマートフォンアプリケーションを使って、特定の位置を選定することができる。そのアプリケーションは、直ぐ上で記載したウェブポータルの機能を有することができる。口座保有者は、サービスプロバイダと特定の関係を持っているストアの事務員に知らせることによって特定の位置を選択できる。これらの機能のいくつかを特に利用する実施例として、口座保有者は、ユーザが地方のコンビニエンスストアのような特定の場所に入ったときはいついでも、未凍結コマンドが自動的に送れるように、自分の口座を構成できる。

方法４００は、施錠解除コマンドを生成するステップ４０４を含んでいる。本発明の特定の実施態様において、サーバ装置１０４は、口座を施錠解除するリクエストに応答して、口座施錠解除コマンドを生成するために使用される。本発明の特定の実施態様において、口座施錠解除コマンドは、電子口座に関連付けられた機能を回復するために使用される。施錠解除コマンドが口座に影響を及ぼす態様は、施錠コマンドを参照して上述した事項のいずれであってもよい。

本発明の特定の実施態様において、方法４００は、確認コードを送信するステップ４０５、検証の保持ステップ４０６及び確認コードを検証するステップ４０７を含んでいる。前述した通り、口座を施錠解除することは、一般に、口座を凍結するよりもっと大きいリスクを口座に与えるから、ステップ４０４で施錠解除コマンドを生成する前に、ステップ４０３で受信されるリクエストに関連する方法は、施錠コマンドに関連付けられる事項よりもっと高度に制約を受け得る。ステップ４０５で送信される確認コードは、ユーザの携帯電話のようなユーザに関連付けられた装置に送信され得る。そして、ユーザは、携帯電話やその他の通信手段を使用して、サーバ装置にそのコードを機械的に繰り返して戻すことができる。確認コードは、ステップ４０４で未凍結コマンドを発生する前に,ステップ４０７のサーバ装置によって受信され検証され得る。このアプローチは、ユーザは、一般的に、取引を認証するために、携帯電話を所持している者のみであろう。他のチャンネルが使用される場合には、口座保有者は取引を開始するために使用される方法と取引を検証するために検証用に必要とされる第２チャンネルの両方にアクセスが必要となるという事実によって提示された保証と組み合わせられ得る。例えば、ユーザがステップ４０７で受信した一時的なコードを入力するように促され、ステップ４０４の施錠解除リクエストの発生にプロセスを移動する前に、ユーザ名とパスワード確認を使用して、施錠機能の管理者によって提示されたウェブポータルに対するユーザログインをステップ４０７は含むことができた。

本発明の実施形態に従って支払口座に保証を提供するコンピュータで実行される方法５００は、図３と図５を参照して記載され得る。方法５００は、支払口座１０５のような電子支払口座が支払サービスによって管理される持続ステップ５０１を含んでいる。口座１０５は、前に記載した口座１０５の全ての特性を引き受けることができる。特に、口座１０５は、図３を参照して記載されたように、金融機関によって管理された支払口座に接続されているという状況を含むことができる。方法５００は、ステップ５０２の施錠リクエストの受信とステップ５０３の施錠リクエストの受信に応答して施錠リクエストの発生を続行する。コンピュータで実行される方法５００は、また、支払サービスによって管理される電子支払口座用支払口座を提供する金融機関に施錠コマンドが送信されるステップ５０４を含んでいる。これらのステップは、施錠及び施錠解除リクエストがいかに送信され、施錠機能の特性が必要とされるかに関して、これまでに考察された施錠及び施錠解除リクエストを参照して、既に考察された全ての変形を含むものである。特に、ステップ５０３で発生された施錠コマンドは、金融機関が支払サービスに関連付けられた口座への全ての振替を防ぐインストラクションを含むことができる。例えば、コマンドは口座３０３から図３の口座３０４への全ての振替を隔離するインストラクションを含んでもよい。コンピュータで実行される方法は、また、施錠解除リクエストがサーバ装置１０４で受信されるステップ５０５と施錠解除コマンドが発生され金融機関に送信されるステップ５０６及び５０７を含むことができる。ステップ５０６及び５０７は、当然、施錠解除コマンドが施錠コマンドの代わりに金融機関に伝達されるという例外はあるが、ステップ５０２及び５０３を反映する。本発明の特定の実施形態では、施錠解除コマンドは、資金が口座保有者の裁量で銀行口座から支払口座へ振替され得る状態に口座を復帰することができる。

金融機関がステップ５０４と５０７で送信される施錠と施錠解除コマンドに応答する態様が電子支払口座の特性に依存する。電子支払口座１０５は、図３の口座３０３の代わりにいろいろな資金源を持ってもよい。例えば、資金源はクレジットまたは金融口座によって管理される蓄えられた資金口座であり得るし、または、金融機関が十分必要な情報を持ち、資金源から支払口座３０４に振替を開始するための資金源であり得る。蓄えられた資金口座は、標準の要求払預金口座であってもいい。これらの状況では、金融機関は、口座３０３によって表されている資金源から支払口座３０４への全ての振替を防ぐ施錠コマンドに応答し得る。金融機関は、また、その代わり、ある期間完全に支払口座を不能にする口座３０４に関連付けられた全ての振替を制限することができるが、電子支払口座のいかなる不正使用から口座保有者を保護することにもなる。

背景技術の項で記載したアプローチの幾つかと比較すると、本特許出願の実施形態の中には安全な口座認証情報を格納し処理することができるハイエンドの装置を必要としていないものである。その代わり、この特許出願中に記載されている施錠リクエストを送信するショートメッセージを使うものは、ローエンドの携帯電話またはその他の簡単な携帯可能な装置を必要とするのみである。その結果、本特許出願に記載されている実施形態は、スマートフォンのようなもっと精巧な携帯可能装置に限定されない。精巧ではない携帯装置のマーケットは相当なものであるから、これには顕著な便益があり、従って、詐欺取引に使用することが増加していることは、依然重要な課題である。更に、関係のある口座保有者が、既にスマートフォンユーザである状況にあり、複雑な詐欺の検出と口座セキュリティアップリケーションの導入は、関連するシステムとプログラムの開発とメンテナンスが依然必要であり、従って、もっと簡単なアプローチはこれらの努力に関連するコストを削除することになり得る。最後に、スマートフォン、ローエンド携帯電話及びその他の携帯装置で使用され得るようなシステムを提供することは、格別な便益がある。

先の記載において、関与する全てのメッセージは、例えば、有線または無線音声、データチャンネルなどのような、多くの手段を介して、送信され得ることが理解されている。これらの手段は、プライベートまたは明らかに安全な通信手段、例えば、暗号化された音声、データチャンネルなどであってよい。通信手段は、(i)電子メールメッセージ、音声電話、データメッセージ、テキストメッセージ、その他のアプリケーションを介して送信されるメッセージのような携帯装置に対して及び／または携帯装置からのメッセージ(例えば、フェイスブック、リンクドイン、スカイプなど)（ii)デスクトップコンピュータのようなステイショナリデバイスまたはテレビジョンのブラウザランニングに対して及び／またはブラウザランニングから送信された同種のメッセージを含んでいる。

上述の記載は、本発明の態様がどのように実行されるかの例示に沿っていろいろな実施形態を説明したものである。例えば、直接通信、Ｕ.Ｓ.メール、電話交信、テキストメッセージ、データメッセージまたは電子メール、有線または無線あるいはデータチャンネル、暗号化されたものまたはされてないものなどの全てが通信手段とみなされ得る。携帯装置は、携帯電話、双方向ページャ、タブレットまたはノートブックコンピュータなどであってもよい。

上述の実施例は、唯一の実施形態とみなされるべきではなく、次の特許請求範囲で定義されているような、本件開示の柔軟性と利点を説明するために提示されている。上述の開示と次の特許請求範囲に基づきその他のアレンジメント、実施形態、手段及び均等なものについては、この分野において通常の知識を有する者にとって明らかであり、特許請求範囲によって定義された趣旨と範囲から逸脱しないで使用され得る。

Claims (14)

1. 電子金融口座のための口座施錠機能をユーザに提供するための、コンピュータにより実行される方法であって、
   前記ユーザに関連付けられた第１装置からサーバ装置において前記電子金融口座を施錠するリクエストを受信することを備え、前記リクエストは通信システムのショートメッセージコンポーネントまたはデータメッセージコンポーネントを介して届けられ、前記ユーザに関連付けられた前記第１装置は前記通信システムを介して通信することに使用され、前記方法はさらに、
   前記サーバ装置と通信するプロセッサを使用し、前記電子金融口座を施錠する前記リクエストに応答し、施錠口座コマンドを生成することを備え、前記施錠口座コマンドは金融取引用の前記電子金融口座の使用を制限するために使用され、前記方法はさらに、
   前記サーバ装置において前記ユーザによって作動される第２装置から前記電子金融口座を施錠解除するリクエストを受信することと、
   前記第１装置が前記第２装置と同じでないとき、前記プロセッサを使用し前記口座を施錠解除する前記リクエストに応答して口座施錠解除コマンドを生成することとを備え、前記口座施錠解除コマンドは前記電子金融口座に関連付けられた機能性を回復するために使用され、前記第１装置が前記第２装置と同じであるとき、前記プロセッサは前記口座施錠解除コマンドを生成せず、
   前記ユーザは前記電子金融口座の所有者である、コンピュータにより実行される方法。
2. 更に、前記口座施錠機能が行なわれている間に、前記電子金融口座から事前承認された資金の振替を許容することを備え、前記事前承認の振替は前記施錠する前記リクエストに先立って前記ユーザから受信された情報によって承認される、請求項１に記載のコンピュータにより実行される方法。
3. 更に、前記口座施錠機能が行なわれた時間を計ることと、
   前記時間が予め設定された時間を超えたとき、前記口座施錠機能を解除することとを備え、
   前記予め設定された時間は前記施錠する前記リクエストの原文に基づいて設定される、請求項１に記載のコンピュータにより実行される方法。
4. 更に、口座保有者からＳＭＳメッセージを介して第２の施錠するリクエストを受信することと、
   前記ＳＭＳメッセージの受信に応答して前記電子金融口座のために提供された第２の口座施錠機能を行うこととを備え、
   前記口座施錠機能及び前記第２の口座施錠機能はそれぞれが前記電子金融口座の前記機能性を抑止することに関する程度が異なり、
   前記施錠する前記リクエストは、テキストメッセージを介して送信され、
   前記テキストメッセージ及びＳＭＳメッセージはそれらの原文内容に関して異なる、請求項１に記載のコンピュータにより実行される方法。
5. 前記施錠口座コマンドは前記電子金融口座に対してデビットに関与する取引に前記口座が使用されるのを制限するために使用される、請求項１に記載のコンピュータにより実行される方法。
6. 前記電子金融口座を施錠する前記リクエストはテキストメッセージを介して送信される、請求項１に記載のコンピュータにより実行される方法。
7. 更に、サーバ装置から、前記通信システムの前記ショートメッセージコンポーネントまたは前記データメッセージコンポーネントを使用して前記ユーザに関連付けられた前記装置に届けられるべき暫定確認コードを送信することと、
   前記暫定確認コードを送信するステップの後に、前記暫定確認コードを受信し検証することと、
   前記口座を施錠解除する前記リクエストを受信するステップの後に、前記暫定確認コードを検証するステップが成功裏に完了するまで、前記口座施錠解除コマンドを生成するステップの実行を保留することとを備える、請求項１に記載のコンピュータにより実行される方法。
8. 前記電子金融口座を施錠する前記リクエストは所定の地理的位置が適合する前記ユーザの地理的位置に基づいて自動的に発生される、請求項１に記載のコンピュータにより実行される方法。
9. 電子支払口座にセキュリティを提供するためのコンピュータにより実行される方法であって、
   サーバ装置が前記電子支払口座を管理することを備え、前記電子支払口座は金融機関によって管理されている金融機関支払口座からの支払いの実行を口座保有者に許容し、前記方法は、
   前記サーバ装置が口座保有者から第１装置を介して施錠リクエストを受信することと、
   前記サーバ装置が前記施錠リクエストの受信に直接応答して施錠コマンドを生成することと、
   前記サーバ装置が前記施錠コマンドを前記金融機関に送信することとをさらに備え、前記施錠コマンドは資金源口座から前記金融機関支払口座への振替を制限するために前記金融機関に指示することを含み、
   前記サーバ装置が施錠解除リクエストを前記口座保有者から第２装置を介して受信することと、
   前記第１装置が前記第２装置と同じでないとき、前記サーバ装置が前記施錠解除リクエストの受信に応答して施錠解除コマンドを発生し、前記第１装置が前記第２装置と同じであるとき、前記サーバ装置が前記施錠解除リクエストの受信に応答して前記施錠解除コマンドを発生しないことと、
   前記施錠解除コマンドの発生後に、前記サーバ装置が前記施錠解除コマンドを前記金融機関に送信することとを更に備える、コンピュータにより実行される方法。
10. 前記資金源口座は銀行口座である、請求項９に記載のコンピュータにより実行される方法。
11. 更に、施錠機能が行なわれている間に、前記電子支払口座から事前承認された資金の振替を許容することを備え、前記事前承認の振替は前記施錠リクエストの受信に先立って前記口座保有者から受信された情報によって承認される、請求項９に記載のコンピュータにより実行される方法。
12. 更に、前記施錠機能が行なわれた時間を計ることと、
    前記時間が予め設定された時間を超えたとき、前記施錠機能を解除することとを備え、
    前記予め設定された時間は前記施錠リクエストの原文に基づいて設定される、請求項９に記載のコンピュータにより実行される方法。
13. 前記施錠解除リクエストは、限られた時間、前記電子支払口座を施錠解除するリクエストである、請求項９に記載のコンピュータにより実行される方法。
14. 前記施錠リクエストは、本質的にショートメッセージサービスコンポーネントから構成される通信チャンネルを介して前記口座保有者から受信される、請求項９に記載のコンピュータにより実行される方法。

Images