JP2011222008A - モバイルデバイスにおける支払い管理 - Google Patents

Abstract

【課題】非同期かつオフラインの請求書レビュー及び支払いをする方法とシステムを提供する。
【解決手段】モバイルデバイスのマネージャビリティエンジン上で作動された請求書支払い管理モジュールはオンライン請求書支払いサービスと通信する。請求書支払い管理モジュールは、支払期限が到来する請求書を含む請求書支払いに関する情報を受信し、請求書支払いクライアントアプリケーションに選択的情報を提示する。請求書支払者は、請求書支払いクライアントアプリケーションによりモバイルデバイス上で情報にアクセスし、支払い金額をレビューまたは変更できる。レビューと修正は、モバイルデバイスがオフラインの時に実行でき、モバイルデバイスがネットワークに接続できる時まで、修正は格納される。ネットワークが利用できるようになると、請求書支払い管理モジュールは支払い指示をオンライン請求書支払いサービスに送信する。
【選択図】図１

Description

本願はモバイル通信の分野に関し、特に、モバイルデバイスにおける金融データのセキュアなオフラインレビューの提供に関する。

近年、パーソナルオンライン金融サービスが普及している。これには、報告や請求書の支払いを自動化する、銀行その他の金融機関が提供する支払いサービスが含まれる。一般的には、請求書の支払いをする人は、パーソナルコンピュータを用いて、かかるサービスを利用して、支払う必要がある請求書に関する情報を受け取る。かかる情報には、最低支払い金額、支払い期限、公共機関やクレジットカード会社などの支払い先の識別情報が含まれる。システムによっては、請求書の支払いをする人は、パーソナルコンピュータを用いて、その情報を確認して、支払い期限の請求書の支払いを指示できる。支払人は、支払い金額、支払い日、請求書の支払いに用いるお金の出所などの支払い条件を変更または編集することを欲することもある。一部のオンラインの請求書支払いシステムは、新しい請求書や到来する支払いについて、電子メールベースの通知をする。他のシステムは、ウェブベースインタフェースを用いて、請求書情報にアクセスし、支払い指示を出すことができる。

本開示の実施形態を、添付した図面に示した実施例により説明するが、これは本開示を限定するものではない。同じ参照符号は同じ構成要素を示す。
本開示の様々な実施形態によるモバイル請求書支払いシステムにおける構成要素間の関係を示す高水準ブロック図である。 様々な実施形態による請求書支払いシステムの内部コンポーネントを示すブロック図である。 様々な実施形態による請求書支払い情報の閲覧と修正をするインタフェース例を示す図である。 様々な実施形態によるモバイル請求書支払い設定プロセスを示す図である。 様々な実施形態によるモバイル請求書支払いレビュー及び指示プロセスを示す図である。 様々な実施形態によるコンピューティング環境例を示す図である。

本開示の実施形態例は、非同期かつオフラインで、モバイルデバイスにおいて、請求書支払い情報のレビューと、請求書の支払いをする人からの支払い指示とを提供することにより、モバイルデバイスにおける既存のオンライン請求書支払い技術の弱点と欠点を解消する装置と方法を含むが、これに限定されない。モバイルデバイスはセキュアかつファームウェアベースの請求書支払い（ＢＰ）管理モジュールを利用する。このモジュールはモバイルデバイスのマネージャビリティエンジン（manageability engine）で動作することができる。様々な実施形態では、ＢＰ管理モジュールは、オンライン支払いサービス（例えば、銀行やクレジットカード）とセキュアに通信して、請求書情報を受信し、支払い指示を送信できる。様々な実施形態において、請求書支払い管理モジュールは、モバイルデバイスに請求書情報及び／または支払い指示を格納し、保持（maintain）し、そのデバイスがネットワークに接続できない時でも情報をレビューして修正できるようにする。これにより、オンライン支払いシステムに繰り返しログインしなくても、支払いをオフラインかつ非同期でレビューすることができる。

本システムの実施形態には、マネージャビリティエンジンとは別のアプリケーション環境において実行されるソフトウェアベースのクライアントアプリケーションも含まれる。このアプリケーション環境はなかんずく対ユーザ・フロントエンドを提供する。ユーザはこのクライアントアプリケーションにより、（認証後）請求書情報を見ることができる。また、ユーザはクライアントアプリケーションにより、支払い前に情報を変更することもできる。様々な実施形態において、ＢＰ管理モジュールはオンライン請求書支払いサービスと暗号化して通信することができ、クライアントアプリケーションはＢＰ管理モジュールとＢＰサービスとの間で送信される口座情報などの金銭情報に直接アクセスできない。これは、様々な実施形態において、ＢＰサービスとＢＰ管理モジュールとの間の直接ネットワーク接続として行え、またはＢＰクライアントソフトウェアを暗号化データの中継として用いることにより行える。

ここに例示した実施形態の様々な側面を、本技術分野の当業者が他の当業者に自らの業務内容を伝えるときに一般的に用いる用語を用いて説明する。しかし、当業者には言うまでもなく、説明した側面の一部だけで、別の実施形態を実施することもできる。例示する実施形態をよく理解してもらうために、説明のため、具体的な数、材料、構成を記載する。しかし、当業者には言うまでもなく、別の実施形態はその具体的な詳細情報がなくても実施することができる。他の場合、例示する実施形態を分かりにくくしないため、周知の特徴は省略または簡略化する。

さらに、説明する実施形態の理解に最も役立つように、様々な動作を複数の個別の動作として順次説明する。しかし、説明の順序は、これらの動作がその順序に依存することを示唆すると解してはならない。特に、これらの動作は説明の順序で実施する必要はない。

「一実施形態では」という言葉を繰り返し用いる。この言葉は一般的には同じ実施形態を指すものではないが、同じ実施形態を指すこともある。文脈に反しない限り、「有する」や「含む」という言葉は同義である。「Ａ／Ｂ」は「ＡまたはＢ」を意味する。「Ａ及び／またはＢ」は「（Ａ）、（Ｂ）、または（ＡかつＢ）」を意味する。「Ａ、Ｂ、及びＣのうち少なくともひとつ」とは、「（Ａ）、（Ｂ）、（Ｃ）、（ＡかつＢ）、（ＡかつＣ）、（ＢかつＣ）、または（Ａ、Ｂ、かつＣ）」を意味する。

図１は、本開示の様々な実施形態によるモバイル請求書支払いシステムに含まれる構成要素間の関係と通信を示すブロック図である。図示したように、様々な実施形態において、請求書支払い者１９０は、そのモバイルデバイス１０５を介してオンラインＢＰサービスを利用できる。様々な実施形態において、モバイルデバイス１０５は、ＢＰ管理モジュール１００を含む。このモジュールは、オンラインＢＰサービス１２０と通信して、請求書支払い情報を受信し、オンライン支払いサービス１２０に支払い指示を出せる。様々な実施形態において、以下に説明するように、ＢＰ管理モジュールはマネージャビリティエンジン（ＭＥ）１５０において動作できる。

様々な実施形態において、本システムは、ＢＰクライアントアプリケーション１１０も有する。様々な実施形態において、このＢＰクライアントアプリケーションは、ＭＥ１５０とは別の独立したアプリケーション環境１１２などの、モバイルデバイスのアプリケーション環境で動作してもよい。ＢＰクライアントアプリケーション１１０は、ＢＰ管理モジュール１００からすべての、または一部の金銭情報を受信できる。このＢＰクライアントアプリケーション１１０は、請求書支払者１９０と、ディスプレイ１３５及び１つ以上の入力手段（input facilities）１４５（例えば、タッチスクリーン、キーボード、ボイスコントロール）を用いてコミュニケーションできる。実施形態では、オンラインＢＰサービス１２０とＢＰクライアントアプリケーション１１０との間を図示したように分離することにより、支払い情報へのアクセスにソフトウェアアプリケーションのみを利用するよりも、セキュリティが向上する。ＢＰ管理モジュール１００は、マネージャビリティエンジン（manageability engine）１５０内で動作し、ＢＰクライアントアプリケーション１５０があるアプリケーション環境１１２とは分離されているので、クライアントアプリケーション１１０よりも、口座番号、パスワード、支払い履歴などのセンシティブ（sensitive）な金銭情報に対して、よりセキュアなリポジトリを提供でき、クライアントアプリケーションが所望の情報を利用できるようにして、請求書支払者にその所望の情報のみを選択的に表示できる。別の実施形態では、クライアントアプリケーションはオンライン支払いサービスと、破線の矢印で示したように、限定的に通信できる。例えば、ＢＰクライアントアプリケーション１１０は、オンラインＢＰサービス１２０とＢＰ管理モジュール１００の間の暗号化通信の中継器として機能するものであってもよい。かかる実施形態では、ＢＰクライアントアプリケーション１１０は、それが中継する暗号化通信に直接的にアクセスすることはできず、ＢＰ管理モジュール１００に依存して、表示及び編集する請求書支払い情報を供給してもらう。

図２は、オンラインＢＰサービス１２０と、（アプリケーション環境１１２を実行する）ＢＰクライアントアプリケーション１１０と、（マネージャビリティエンジン１５０で実行される）ＢＰ管理モジュール１００とに含まれる構成要素を示すブロック図である。図示した実施形態は様々なソフトウェアモジュールやファームウェアモジュールのグループ化や分割を具体的に示しているが、言うまでもなく別の実施形態では、これらのモジュールは結合されても、分割されても、削除されてもよい。

オンラインＢＰサービス１２０は、サーバ（図示せず）を有してもよく、様々なモジュールを有する。次に、オンラインＢＰサービスは、セキュア管理エンジン（ＭＥ）通信サービスモジュール２１０を有する。様々な実施形態では、このモジュールは、ＭＥのＢＰ管理モジュールに送信される情報を暗号化し、ＢＰ管理モジュール１００から送信された情報を復号する。上記の通り、様々な実施形態では、セキュアＭＥ通信サービス２１０は、この通信を、ＢＰクライアントアプリケーション１１０の中継を用いて実行できる。他の実施形態では、セキュアＭＥ通信サービス２１０は、３Ｇネットワークなどを介して、ＢＰ管理モジュール１００に直接的に通信できる。ＢＰ管理モジュール１００は、中継無しに、このような直接アクセスを提供することができる。

オンラインＢＰサービス１２０もＢＰ管理モジュール２１５を有する。様々な実施形態では、ＢＰ管理モジュール２１５は、モバイルデバイスの請求レビュー及び修正モジュールの相手として機能し、これにより請求書支払者は支払い手続の詳細をモニター、レビュー、及び更新できる。様々な実施形態では、ＢＰ管理モジュール２１５は、本明細書で説明するモバイルＢＰ技術に用いる様々なソフトウェア及びファームウェアモジュールをモバイルデバイスに提供する役にたつ。これには、ＭＥファームウェアモジュールにおける暗号化（cryptography secrets）の提供や請求書支払者のセキュアなパスワード設定の支援が含まれる。また、オンラインＢＰサービス１２０は、ユーザプラットフォーム認証モジュール２２０も有する。このモジュールは、様々な金融機関に対して、オンラインＢＰサービスを用いて、様々な請求書支払者の認証を提供できる。

様々な実施形態では、ＢＰクライアントアプリケーション１１０は、様々なモジュールを有し得る。上記の通り、これらのモジュールはソフトウェアで実施され、モバイルデバイスのＣＰＵ上のアプリケーション環境１１２で実行される。以下に説明するように、ある実施形態では、ＢＰクライアントアプリケーション１１０は、アプリケーション環境１１０専用のプロセッサで実行し、別のプロセッサを用いてＭＥ１５０を動作させてもよい。様々な実施形態において、ＢＰクライアントアプリケーション１１０は、請求書支払い履歴、支払い期限、支払い金額などの情報を請求書支払者に提供するユーザインターラクションモジュール２２５を有する。様々な実施形態において、請求書支払者は、ユーザインターラクションモジュール２２５により、提案された支払い金額を編集したり（例えば、最低支払金額以上に支払を増額したり）、まだ設定されていない新しい支払いを入力したりできる。上記の通り、ユーザインターラクションモジュール２２５は、１つ以上の表示及び／または入力デバイスを介して、請求書支払者とインターラクトできる。

また、様々な実施形態において、請求書支払者とのインターラクションは、ユーザインターラクションモジュール２２５だけを介して行うものでなくてもよい。例えば、請求書支払者は、自分の請求書支払い情報を見たい時、ＢＰ管理モジュール１００の一部で直接的に提供されるテキストボックスその他の入力手段を介してパスワードを入力できる。これは、ＢＰ管理モジュール１００の支援により行える。ＢＰ管理モジュール１００は、ディスプレイに直接的にメッセージを送り、テキスト入力を受け取る。クライアントアプリケーションなどのソフトウェアは送信された情報にアクセスしない。この直接的な通信により、請求書支払者のためのセキュリティが向上する。請求書支払者は自分のパスワードその他の情報がユーザインターラクションモジュール２２５その他のソフトウェアによりアクセスされることを欲しない。様々な実施形態において、例示したユーザＢＰ通信モジュール２３０は、ＢＰ管理モジュール１００と定期的に通信して、ＢＰ管理モジュール１００がオンラインＢＰサービス１２０から請求書支払い情報の更新を受けたか判断し、ユーザが自分のアイデンティティの認証を受けると、新しい情報を受信する準備ができたことをユーザに通知（alert）できる。

ＢＰクライアントアプリケーション１１０は、ＢＰサービス通信中継モジュール２３５も有する。上記の通り、様々な実施形態において、このモジュールは、オンラインＢＰサービス１２０とＢＰ管理モジュール１００との間の暗号化通信が送信されるがソフトウェアベースのＢＰクライアントアプリケーションによりアクセスされない中継器として機能する。別の実施形態において、このモジュールは、オンラインＢＰサービス１２０とＭＥ１５０のＢＰ管理モジュール１００の間のすべての通信に用いられなくてもよく、まったく用いられなくてもよい。様々な実施形態において、ＢＰ管理モジュール１００とＢＰクライアントアプリケーション１１０との間の通信は、アプリケーション環境１１２で実行されるＨＥＣＩ（Host Embedded Controller Interface）ドライバ２４０により行われる。

図２もＢＰ管理モジュール１００を示す。これは管理エンジン１５０のファームウェアで実行される。説明のため、ＭＥは１つ以上のファームウェアモジュールを有すものとする。このファームウェアモジュールがＢＰ管理モジュール１００などの管理アプリケーションをサポートして、ファームウェアで実行させる。様々な実施形態において、これらの管理モジュールは、ＭＥにより、ＣＰＵ以外のグラフィックス及びメモリコントローラハブなどのマイクロコントローラで実行される。様々な実施形態において、ＭＥは補助パワーで実行され、ＣＰＵよりも大きなパワー状態において利用できる。これにより、モバイルデバイスがオフラインであるときに、ＢＰ管理モジュール１００が請求書支払い情報を受信し、請求書支払い指示を送る機会が多くなる。様々な実施形態において、上記の通り、ＭＥによりネットワーク通信への直接的なアクセスと入出力デバイスとの通信ができる。様々な実施形態において、ＭＥはこれらの通信にＨＥＣＩインタフェース２８０と、ＭＥオペレーティングシステム（ＯＳ）２７０と、ＭＥカーネル２７５とを用いるが、これは言うまでもないであろう。ＭＥ ＯＳ２７０とＭＥカーネル２７５は、本技術分野で知られたＭＥ ＯＳとＭＥカーネルのどれかで実施できる。

ＢＰ管理モジュール１００は、ユーザ認証モジュール２５５を有する。様々な実施形態において請求書支払者は、このモジュールにより、ＢＰクライアントアプリケーション１１０などを介してセンシティブな金銭情報を請求書支払者に表示する前に、自分のアイデンティティを認証できる。別の実施形態では、ユーザ認証は、ＭＥのＢＰ管理モジュールではなくて、少なくとも部分的にクライアントアプリケーションにより実行される。ＢＰ管理モジュール１００は、請求書レビューモジュール２６０も有する。このモジュールは、請求書支払者に請求書情報を提供し、請求書支払者から支払い指示を受信する。この指示には請求書支払者がする編集や修正を含む。様々な実施形態において、請求書レビューモジュール２６０は、これらの編集をオンラインＢＰサービス１２０に送信し、このサービスにより支払いが為されるようにする。このように、様々な実施形態において、請求書レビューモジュールは、口座番号、パスワード、請求履歴、最低支払額などのセンシティブ（sensitive）な金銭情報にアクセスし、及び／またはそれを保持できる。請求書レビューモジュール２６０は、また、ユーザに表示するため、例えばユーザ認証モジュール２５５によりユーザが認証されると、ＢＰクライアントアプリケーションにこの情報の一部を選択的に、または全部を提供できる。ユーザによるレビューのために選択的に提供される情報は、センシティブな金銭情報を誤って漏らさない（avoid the inadvertent sharing）ように選択する。

さらに、ＢＰ管理モジュールは、オンラインＢＰサービス１２０と通信するように構成されたサーバ通信モジュール２６５を有する。例えば、上記の通り、サービス通信モジュール２６５は、オンラインＢＰサービス１２０と暗号化通信をできる。一部の実施形態では、これはＢＰクライアントアプリケーションを中継器として用いて行う。他の一部の実施形態では、サービス通信モジュール２６５はオンラインＢＰサービスと直接的に通信する。様々な実施形態において、サーバ通信モジュール２６５はネットワーク接続に依存してオンラインＢＰサービスと通信するが、ユーザ認証モジュール２５５と請求書レビューモジュール２６０は、モバイルデバイスがネットワークに接続されていない間も動作するように構成してもよい。この構成により、ユーザは、モバイルデバイスがオフラインの時でも、支払いの詳細をレビューして修正を加えることができる。

図３は、請求書支払者にレビュー用に表示するユーザインタフェースの一例を示す。上記の通り、様々な実施形態において、図３に示したインタフェースは、請求書レビューモジュール２６０が受信した情報を用いて、ユーザインターラクションモジュール２２５により提供される。図示した実施例では、列３１０と３２０は、公共機関その他の債権者のそれぞれに対して、請求書支払者が以前に支払った金額を示す。例えば、２００９年９月には、請求書支払者は、ガス会社（natural gas utility）に対して１８０ドルを支払っている。図示した実施例のように、様々な実施形態において、システムは過去の支払金額に、シェーディングその他の履歴であることを表す表示を施して表示する。

また、ユーザインタフェースは、列３３０に示した金額のように、支払い期限が到来するものも表示する。この実施例では、列３３０には、欄（element）３４０のように、未払い金額が事前に入っている。一部の実施形態では、この金額はオンラインＢＰサービス１２０が様々な債権者機関と通信して取得したものである。例えば、ユーザインタフェースには、支払わなければならない最低金額に応じた支払期限金額が事前に入っていてもよい。一部の実施形態では、支払期限金額は支払期限とともに表示してもよい。一部の実施形態では、ユーザインタフェースには金額が事前に入れられておらず、請求書支払者が任意の金額を入力できる手段（facility）をユーザインタフェースが提供する。ユーザインタフェースは総支払済み金額、総未支払い金額、総支払い期限金額などの金銭情報を表示することもできる。様々な実施形態において、ユーザインタフェースは口座番号やパスワード、さらには銀行名やサービス名などの識別情報などのセンシティブなデータは表示を省略する。これにより、モバイルデバイスが悪意のある人間の手に渡ったり、請求書支払者以外のユーザが画面を見たりした場合に、個人情報の盗難を避ける役に立つ。

図３のユーザインタフェースに示したように、請求書支払者がユーザインタフェースの様々な要素とインターラクト（interact）できるようになっている。図中、インターラクトできる要素には下線を付してある。例えば、請求書支払者は、事前入力されている各金額をクリック、ポイント、または選択して、変更することができる。また、ユーザインタフェースは別のインターラクション（interactions）も提供する。例えば、請求書支払者は、例えば、要素３５０を選択して金額を表示するかしないか選択でき、要素３６０を選択して支払金額にした変更をキャンセルでき、要素３７０を選択してＢＰ指示を出すリマインダを要求でき、要素３８０を選択して編集モードに入れ、要素３９０を選択してオンラインＢＰサービスに（編集をキャンセルせずに）支払い指示を送信できる。別の実施形態では、図示した要素を省略してもよいし、他の要素を付加してもよい。

図４は、本明細書で説明する実施形態を利用するモバイルデバイスにおける請求書支払いの設定プロセスの一例を示す。図示したように、本プロセスはＭＥ１５０上で実行されるＢＰ管理モジュール１１０と、請求書支払者１９０などのユーザと、アプリケーション環境１１２で実行されるＢＰクライアントアプリケーション１１０と、オンラインＢＰサービス１２０との間の通信に係わる。本プロセスはアクション４０１に始まり、ユーザがオンラインＢＰサービスと通信して、ＭＥベースのＢＰサービスの設定を開始する。次に、アクション４０２において、オンラインＢＰサービスがモバイルプラットフォームにアプリケーションをインストールする。様々な実施形態において、これはＭＥにおけるＢＰ管理モジュールのインストールも含む。次に、アクション４０３において、ＢＰ管理モジュールとオンラインＢＰサービスが互いにトラスト（trust）を確立する。様々な実施形態において、このアクションは、トラストを提供し維持するための１つ以上の暗号鍵及び／または署名済み証明書の交換を含み得る。各アクションは１つ以上の動作を含み得る。

次に、アクション４０４において、ＢＰクライアントアプリケーションとオンラインＢＰサービスも互いにトラスト（trust）を確立し、ポリシー情報（policy information）を交換する。様々な実施形態において、ポリシー情報は支払いベースのポリシーを含む。この支払いベースのポリシー（payment-based policies）は、例えば、ユーザが金額を変更できるか、誰が支払いをするか、及び／または事前に金額をいかに計算するかという事項を含む。次に、アクション４０５において、ポリシーとオンライン支払い明細をＢＰ管理モジュールに送る。様々な実施形態において、これらの明細は、アクション４０４で確立したポリシーによって、例えば暗号化した形式で、パススルー（pass through）される。

次に、アクション４０６において、ユーザはモバイルＢＰシステムを利用するサービスアグリーメントを受諾するように要求（prompt）される。例えば、ＢＰクライアントアプリケーションによりアグリーメント文書に同意を求められる。アクション４０７において、ユーザはサービスアグリーメントを受諾するなどして、フィードバックする。アクション４０８において、そのフィードバックがオンラインＢＰサービスに送られると、ユーザはサービスのアカウントの設定を開始できる。次に、アクション４０９において、ユーザはオンラインＢＰサービスの支払いアカウントを設定する。様々な実施形態において、ＢＰ管理モジュールはそのアカウントを設定する手段（facility）を提供してもよい。他の実施形態において、ＢＰ管理モジュールはそのような手段を提供せずに、オンラインＢＰサービスから請求書アカウント情報を直接的に受信してもよい。

図５は、本明細書で説明する実施形態を利用するモバイルデバイスにおける請求書支払いの設定プロセスの一例を示す。図示したように、本プロセスはＭＥ１５０上で実行されるＢＰ管理モジュール１１０と、請求書支払者１９０などのユーザと、アプリケーション環境１１２で実行されるＢＰクライアントアプリケーション１１０と、オンラインＢＰサービス１２０との間の通信に係わる。本プロセスはアクション５０１で始まり、支払期限が到来する請求書及び／または請求書支払いの明細を示した情報が、ＭＥ１５０上のＢＰ管理モジュール１１０に送信される。様々な実施形態において、この情報は、定期的に送信され、例えば、ＢＰ管理モジュール１１０がオンラインＢＰサービス１２０に新しい請求書支払い情報を定期的に要求するのに応じて送信される。一部の実施形態では、請求書支払い情報は、要求に応じてではなく、オンラインＢＰサービス１２０からＢＰ管理モジュール１１０に直接的に送信されてもよい。様々な実施形態では、ＭＥ１５０に送信される請求書情報は送信前に暗号化され、ＢＰ管理モジュール１１０により受信後に復号される。

上記の通り、一部の実施形態では、アクション５０２−５０７は、ＢＰ管理モジュール１００とＢＰクライアントアプリケーション１１０とが実行されるモバイルデバイスがネットワークに接続されていない時でも実行できる。本プロセスのこの部分は斜線を施した領域で示した。このように、アクション５０２において、ＢＰクライアントアプリケーション１１０は、モバイルデバイスがネットワークに現在接続されているかどうかにかかわらず、ＭＥ１５０のＢＰ管理モジュール１００をチェックして、新しい、または更新された請求書支払い情報を求める。上記のチェックについて、これは定期的に行ってもよいし、ＭＥ１５０からＢＰクライアントアプリケーション１１０に送信される、新しい情報を受信したとのメッセージの結果として行ってもよい。アクション５０３において、ＢＰクライアントアプリケーション１１０は、請求書支払者が請求書について後でリマインドして欲しいと表示したか、再びチェックする。このチェックに応じて、ＭＥ１５０のＢＰ管理モジュール１００は、アクション５０４においてＢＰクライアントアプリケーション１１０に請求書情報を提供する。

次に、アクション５０５において、ＢＰクライアントアプリケーション１１０はＢＰ管理モジュール１００から受信した請求書情報をユーザに表示する。上記の通り、セキュリティの観点から、この表示はＢＰ管理モジュール１００が知っている情報の選択的な一部のみであってもよい。次に、アクション５０６において、ユーザはＢＰクライアントアプリケーション１１０に支払い金額（及び／または支払金額への編集）を提供する。上記の通り、これは、図３に示したユーザインタフェースなどにより、ＢＰクライアントアプリケーション１１０のユーザインターラクションモジュール２２５を用いて実行される。次に、アクション５０７において、ユーザから受け取った更新は、ＭＥ１５０中のＢＰ管理モジュール１００により保存される。様々な実施形態において、この更新はＢＰ管理モジュール１００に直接的に送られ、ＢＰ管理モジュール１００によりＭＥ１５０で利用可能な記憶手段に保存される。別の実施形態において、この更新は、ＢＰクライアントアプリケーション１１０により、アプリケーション環境１１２とＭＥ１５０の両方がアクセス可能な記憶手段に格納される。この場合、ＢＰクライアントアプリケーション１１０は、ＢＰ管理モジュール１００に、変更があったとの表示（indication）を送り、ＢＰ管理モジュール１００がその更新を読み出せるようにする。

更新を受け取ると、アクション５０８において、ＢＰ管理モジュール１００は、更新された請求書支払い指示をオンラインＢＰサービス１２０に送る。上記の通り、更新された指示はＭＥ１５０のＢＰ管理モジュール１００によりオンラインＢＰサービス１２０に直接的に送信してもよいし、中継手段（relaying intermediary）としてＢＰクライアントアプリケーション１１０を用いて送信してもよい。様々な実施形態において、ＢＰ指示は送信に先立ちＢＰ管理モジュール１００により暗号化されてもよいし、オンラインＢＰサービス１２０により受信後に復号されてもよい。次にアクション５０９において、オンラインＢＰサービス１２０は、ＢＰ管理モジュール１００に、更新された指示を受信したとのアクノレッジメント（acknowledgment）を送る。オンラインＢＰサービス１２０は支払い指示を実行する。

本明細書に記載した方法と装置は、所望の構成の好適なハードウェア、ファームウェア、及び／またはソフトウェアを用いるシステムで実施できる。図６は、一実施形態としてシステム例６００を示す。このシステム例６００は、少なくともプロセッサ６０４ａ及び６０４ｂと、前記プロセッサの少なくとも一方と結合したシステム制御ロジック６０８と、システム制御ロジック６０８と結合したメモリ６１２と、システム制御ロジック６０８と結合した不揮発性メモリ（ＮＶＭ）／記憶部６１６と、システム制御ロジック６０８と結合した１つ以上の通信インタフェース６２０とを有する。様々な実施形態において、システム６００はＣＰＵベースのソフトウェアシステム、管理エンジンシステム、またはこれらの組み合わせのコンポーネントを有する。

一実施形態において、システム制御ロジック６０８は、プロセッサ６０４ａと６０４ｂの少なくとも一方に、及び／またはシステム制御ロジック６０８と通信する好適なデバイスまたはコンポーネントに、好適なインタフェースを提供する好適なインタフェースコントローラを含む。プロセッサには、アプリケーション環境を動作させる専用アプリケーションプロセッサ６０４ａと、これとは別の、マネージャビリティエンジンを動作させるサービスプロセッサ６０４ｂとが含まれる。本システムはさらに別のプロセッサやプロセッシングコア（図示せず）を有していてもよい。

システム制御ロジック６０８は、一実施形態では、メモリ６１２とのインタフェースを提供する１つ以上のメモリコントローラを含む。システムメモリ６１２は、例えばシステム６００のデータ及び／または命令をロード及び格納するために用いられる。システムメモリ６１２は、一実施形態では、ＤＲＡＭ（dynamic random access memory）などの好適な揮発性メモリを含んでいてもよい。

システム制御ロジック６０８は、一実施形態では、ＮＶＭ／記憶部６１６及び通信インタフェース６２０とのインタフェースを提供する１つ以上の入出力（Ｉ／Ｏ）コントローラを含む。

ＮＶＭ／記憶部６１６は、例えばデータ及び／または命令を格納するために用いられる。ＮＶＭ／記憶部６１６は、フラッシュメモリなどの不揮発性メモリを含み、及び／またはハードディスクドライブ（ＨＤＤ）、ソリッドステートドライブ、コンパクトディスク（ＣＤ）ドライブ、デジタルバーサタイルディスク（ＤＶＤ）ドライブなどの不揮発性記憶デバイスを含み得る。

ＮＶＭ／記憶部６１６は、システム６００がインストールされているデバイスの物理的に一部である記憶リソースを含み、そのデバイス（必ずしもその一部ではない）によりアクセス可能である。例えば、ＮＶＭ／記憶部６１６は通信インタフェース６２０を介してネットワークによりアクセス可能である。

メモリ６１２とＮＶＭ／記憶部６１６は、ＢＰロジックの一時的及び永続的なコピーを含む。図示した実施例では、このロジックは請求書支払いクライアントロジック６２４ａと請求書支払い管理ロジック６２４ｂとを両方とも含む。請求書支払いクライアントロジック６２４ａと請求書支払い管理ロジック６２４ｂは、プロセッサ６０４ａと６０４ｂの少なくとも一方により実行されると、システム６００に、本明細書で説明するいずれかのモジュールに関して説明する請求書情報レビュー及び請求書支払い指示を実行させる命令を含む。一部の実施形態では、追加的に、または代替的に、ＢＰクライアントロジック６２４ａとＢＰ管理ロジック６２４ｂの一方または両方は、システム制御ロジック６０８内にある。

通信インタフェース６２０は、ネットワークにより、及び／またはその他の好適なデバイスにより通信するインタフェースをシステム６００に提供する。通信インタフェース６２０は好適なハードウェア及び／またはファームウェアを含み得る。通信インタフェース６２０は一実施形態では、ネットワークアダプタ、ワイヤレスネットワークアダプタ、電話モデム、及び／またはワイヤレスモデムなどを含む。ワイヤレス通信の場合、通信インタフェース６２０は一実施形態では１つ以上のアンテナを用いる。

一実施形態では、プロセッサ６０４のうち少なくとも１つは、システム制御ロジック６０８の１つ以上のコントローラのロジックとともにパッケージされ得る。一実施形態では、プロセッサ６０４のうち少なくとも１つは、システム制御ロジック６０８の１つ以上のコントローラのロジックとともにパッケージされ、システムインパッケージ（ＳｉＰ）を構成し得る。一実施形態では、プロセッサ６０４のうち少なくとも１つは、システム制御ロジック６０８の１つ以上のコントローラのロジックと同じダイ（die）に集積され得る。一実施形態では、プロセッサ６０４のうち少なくとも１つは、システム制御ロジック６０８の１つ以上のコントローラのロジックと同じダイ（die）に集積され、システムオンチップ（ＳｏＣ）を構成し得る。

様々な実施形態において、システム６００のコンポーネントはより多くても少なくてもよく、及び／またはそのアーキテクチャは異なるものであってもよい。

本開示において「一実施形態」とは、その実施形態に関して説明する具体的な機能、構造、特徴などが本発明に含まれる少なくとも１つの実施形態に含まれることを意味している。したがって、「一実施形態」と言っても、必ずしも同じ実施形態を指しているとは限らない。さらに、こうした具体的な機能、構造、特徴は、例示した具体的な実施形態以外の他の好適な形式で構成してもよく、かかる形式はすべて本願の特許請求の範囲に含まれる。

具体的な実施形態を例示して説明したが、当業者には言うまでもなく、例示して説明した具体的な実施形態は、本開示の実施形態の範囲から逸脱することなく、幅広い別の、及び／または等価な実施形態で置き換えることができる。本願は、本明細書で説明した実施形態の適応や変形を含むものである。それゆえ、本開示の実施形態は請求項及びその等価物によってのみ限定されるものである。

Claims (16)

1. コンピュータにより実行される支払い管理方法であって、
   コンピューティングデバイスにおいて、ネットワークに結合しているとき、請求書支払者の介入なしに自動的に、ネットワークを介して、オンライン請求書支払いサービスから、前記請求書支払者の過去の請求書支払いまたは支払期限が到来する請求書を示す情報を、前記コンピューティングデバイスのアプリケーション環境とは独立に動作するように構成された、前記コンピューティングデバイスのマネージャビリティエンジンにより、前記請求書支払者に代わって受信し、記憶する段階と、
   前記コンピューティングデバイスにおいて、前記ネットワークに結合しているかどうかに係わらず、前記アプリケーション環境を介して、１つ以上の請求書の１つ以上の支払いをする１つ以上の支払い指示を受信し、
   前記コンピューティングデバイスにおいて、前記ネットワークに結合しているかどうかに係わらず、受信した前記支払い指示を記憶する段階と、
   前記コンピューティングデバイスにおいて、前記ネットワークを介して前記オンライン請求書支払いサービスに接続されているとき、前記マネージャビリティエンジンにより、前記オンライン請求書支払いサービスに前記支払い指示を送信し、前記１つ以上の支払いを行う段階とを有する方法。
2. 前記コンピューティングデバイスにおいて、前記過去の請求書支払いまたは支払期限が到来する請求書を表示する段階をさらに有する、請求項１に記載の方法。
3. 前記コンピューティングデバイスにおいて、前記過去の請求書支払いまたは支払期限が到来する請求書の表示、前記支払い指示の受信、前記支払い指示の記憶、または前記支払い指示の送信の前に、ユーザのアイデンティティを認証する段階をさらに有する、請求項２に記載の方法。
4. 情報を受信する段階は、
   前記コンピューティングデバイスにおいて、前記マネージャビリティエンジンにより、前記オンライン請求書支払いサービスから暗号化した情報を受信する段階と、
   前記コンピューティングデバイスにおいて、前記マネージャビリティエンジンにより、前記暗号化した情報を復号する段階とを有し、または、
   前記オンライン請求書支払いサービスに前記支払い指示を送信する段階は、
   前記コンピューティングデバイスにおいて、前記マネージャビリティエンジンにより、前記支払い指示を暗号化して、暗号化した支払い指示を生成する段階と、
   前記コンピューティングデバイスにおいて、前記マネージャビリティエンジンにより、前記オンライン請求書支払いサービスに暗号化した前記支払い指示を送信する段階とを有する、請求項１に記載の方法。
5. 前記オンライン請求書支払いサービスから暗号化した情報を受信する段階は、前記コンピューティングデバイスにおいて、前記オンライン請求書支払いサービスから前記マネージャビリティエンジンにより暗号化した情報を受信し、クライアントアプリケーションは暗号化していない形式で前記情報にアクセスしない段階を有する、請求項４に記載の方法。
6. 前記オンライン請求書支払いサービスに暗号化した前記支払い指示を送信する段階は、前記コンピューティングデバイスにおいて、前記オンライン請求書支払いサービスに前記マネージャビリティエンジンにより暗号化した支払い指示を送信し、クライアントアプリケーションは暗号化していない形式で前記情報にアクセスしない段階を有する、請求項４に記載の方法。
7. 前記コンピューティングデバイスにおいて、前記ネットワークに接続されているとき、前記請求書支払者の介入なしに自動的に、前記マネージャビリティエンジンにより、前記オンライン請求書支払いサービスをチェックして、前記情報に対する更新を求める段階をさらに有する、請求項１に記載の方法。
8. 情報を受信する段階は、前記コンピューティングデバイスにおいて、前記ネットワークに接続されているときに、前記オンライン請求書支払いサービスに前記情報を求める要求を送信せずに、前記オンライン請求書支払いサービスから前記情報を受信する段階を有する、請求項１に記載の方法。
9. １つ以上のコンピュータプロセッサと、
   前記コンピュータプロセッサに結合したネットワーキングインタフェースと、
   前記１つ以上のコンピュータプロセッサにより作動されるアプリケーション環境とは独立に、前記１つ以上のコンピュータプロセッサにより作動されるように構成されたマネージャビリティエンジンと、
   前記請求書支払い管理モジュールの作動に応じて、前記システムに次の段階を実行させる、前記マネージャビリティエンジンにより作動されるように構成された請求書支払い管理モジュールとを有する、支払い管理システム：
   前記ネットワーキングインタフェースを介してオンライン請求書支払いサービスから請求書支払者に関連する過去の請求書支払いまたは支払期限が到来する請求書を示す情報を、前記請求書支払者の介入なしに、ソフトウェアベースのクライアントアプリケーションが前記情報にアクセスすることなしに、受信する段階と、
   前記ソフトウェアベースのクライアント請求書支払アプリケーションが前記支払い指示にアクセスすることなしに、前記ネットワークインタフェースを介して前記オンライン請求書支払いサービスに、受信した支払い指示を送信する段階と、
   前記ソフトウェアベースのクライアント請求書支払いアプリケーションは、前記１つ以上のプロセッサにより作動され、前記ソフトウェアベースのクライアント請求書支払いアプリケーションの作動に応じて、前記システムに、次の段階を実行させるように構成された：
   前記過去の請求書支払いまたは支払期限が到来する請求書を提示する段階と、
   １つ以上の請求書の１つ以上の支払いをする支払い指示を受信する段階。
10. 前記１つ以上のコンピュータプロセッサに結合し、前記請求書支払い指示を記憶するように構成された記憶手段をさらに有する、請求項９に記載のシステム。
11. 前記ソフトウェアベースのクライアント請求書支払いアプリケーションは、前記ネットワーキングインタフェースがネットワークに結合しているかどうかにかかわらず、情報を提示し、支払い指示を受信するように構成された、請求項９に記載のシステム。
12. 前記請求書支払い管理モジュールは、前記マネージャビリティエンジンにより作動される、前記オンライン請求書支払いサービスから受信した過去の請求書支払いまたは支払期限が到来する請求書を示す暗号化された情報を復号し、前記オンライン請求書支払いサービスに送信する前に請求書支払い指示を暗号化するように構成された、請求項９に記載のシステム。
13. 前記請求書支払い管理モジュールは、前記マネージャビリティエンジンにより作動される、前記ソフトウェアベースのクライアント請求書支払いアプリケーションに復号した情報を提供して前記請求書支払者に提示するように構成された請求書レビューモジュールをさらに有する、請求項１２に記載のシステム。
14. 前記請求書支払いモジュールは、前記マネージャビリティエンジンにより作動される、前記ソフトウェアベースのクライアント請求書支払いアプリケーションに情報を提供する前に、前記請求書支払者のアイデンティティを認証するように構成されたユーザ認証モジュールを有する、請求項１３に記載のシステム。
15. 前記ソフトウェアベースのクライアント請求書支払いアプリケーションは、前記マネージャビリティエンジンの前記請求書支払い管理モジュールと前記オンライン請求書支払いサービスとの間で暗号化した情報を中継するように構成されたサーバ通信中継モジュールを有する、請求項１２に記載のシステム。
16. 前記請求書支払い管理モジュールは、前記ソフトウェアベースのクライアント請求書支払いアプリケーションとは独立して、前記マネージャビリティエンジンを介して、前記オンライン請求書支払いサービスと直接的に通信するように構成された、請求項１２に記載のシステム。

Images