(57)【要約】【課題】お金に関わるユーザフレンドリな取引を行う方法、及びシステムの提供。【解決手段】電子マネーシステムは、金、クレディットカード、及び他の組織された支払い形態を管理するために通例使用されるウオーレット又は財布をエミュレートする電子マネーシステムを利用する取引のために備えられる。ウオーレット又は財布内の手段へのアクセスは、認可されない支払いを避けるためにパスワードによって制限されている。アクセスが認可されるとき、支払い装置のグラフィック表示は、ユーザに支払方法を選択させるためにディスプレイ上に提示される。いったん支払い装置が選択されると、購買商品のサマリーがユーザに提示され、かつユーザは、取引の電子承認を入力し、或いはその取引をキャンセルする。電子承認すると、この注文を完了する電子取引が発生する。【選択図】図３２
2008186474.tif 000002
【特許請求の範囲】
【請求項１】
付属ディスプレイ(138, 400)を持つコンピュータにおいて認可を開始するための方法であって、前記コンピュータが、ネットワーク情報を送受信するためにネットワークに接続されているものにおいて、
（ａ）前記ネットワークを介して前記コンピュータを前記コンピュータから離れた所にあるネットワークサイトに接続するステップと、
（ｂ）前記ネットワークを介して前記ネットワークサイトと前記コンピュータとの間で情報をやり取りするステップと、
（ｃ）前記情報に応じて、少なくとも１つの支払い手段(1720,1730)を該支払い手段(1720)のビットマップイメージ(3200)として表示するステップと、
（ｄ）前記ビットマップイメージを使用して、前記少なくとも１つの支払い手段の中から１つの支払い手段(3200, 1720)を選択するステップと、
（ｅ）前記支払い手段(3200, 1720)に関連する情報(1700-1792)を使用して前記ネットワークにアクセスすることによって、前記ネットワークサイトを通した取引を処理し、該取引の認可を得るステップと
からなる方法。
【請求項２】
前記支払い手段は、発行者選択に従って表現される、請求項１に記載の方法。
【請求項３】
提案された取引のサマリー、及び前記支払い手段を使用して取引を完了することの同意を表示するステップを含む、請求項１に記載の方法。
【請求項４】
他の支払い手段への変更、前記取引を完了するための情報の入手、または前記支払い手段に関連する情報の閲覧を可能にするリンクを表示するステップを含む、請求項３に記載の方法。
【請求項５】
受け取った認可を表わす指示を表示するステップを含む、請求項３に記載の方法。
【請求項６】
商人、発行者、広告者、または代理店へのリンクを前記ディスプレイに埋め込むステップを含む、請求項１に記載の方法。
【請求項７】
プロバイダーのプラクティスに基づく選択を可能にするために前記支払い手段を変更するステップを含む、請求項１に記載の方法。
【請求項８】
前記ディスプレイ上で支払い手段が使用された各取引のリストを表示するステップを含む、請求項１に記載の方法。
【請求項９】
前記ディスプレイ上で認可された支払い手段に基づくオプションのメニューを表示するステップを含む、請求項１に記載の方法。
【請求項１０】
選択された支払い手段に基づいて処理を変更するステップを含む、請求項１に記載の方法。
【請求項１１】
付属ディスプレイ(136-138)を備え、入力デバイス(124)を備えたコンピュータ(100-138)において、ソフトウェア(180-186, 300-380, 400-480)の制御により、認可を開始するための装置であって、前記コンピュータが、ネットワーク情報(134-135)を送受信するためにネットワークに接続されているものにおいて、
（ａ）前記ソフトウェアの制御により、前記コンピュータが、該コンピュータと、遠くの場所に置かれたネットワークサイトとの間にネットワーク接続を確立し、
（ｂ）前記ソフトウェアの制御により、前記コンピュータが、前記ネットワークを介して該コンピュータと、前記遠くの場所に置かれたネットワークサイトとの間でデータを転送することにより、インターネット・コモン・ゲートウェイ（ＣＧＩ）を利用して該データをやり取りし、
（ｃ）前記ソフトウェアの制御により、前記コンピュータが、少なくとも１つの支払い手段(700-796, 1020, 1030, 1040)を該支払い手段のビットマップイメージとして前記ディスプレイ上に表示し、
（ｄ）前記ソフトウェアの制御により、前記コンピュータが、前記入力デバイスを使用して１つの支払い手段(1030)を選択し、
（ｅ）前記ソフトウェアの制御により、前記コンピュータが、前記選択された手段に関連する情報を使用して前記ネットワークを介して認可処理(600-640)を行い、それによって、前記ネットワークを通して取引を処理し、該取引のための認可を得ることを含む装置。
【請求項１２】
前記支払い手段は、発行者選択に従って表現される、請求項１１に記載の装置。
【請求項１３】
前記ソフトウェアの制御により、前記コンピュータが、認可中の処理に関連する追加機能を提供する他のディスプレイへのリンクを提供することを含む、請求項１１に記載の装置。
【請求項１４】
前記ソフトウェアの制御により、前記コンピュータが、提案された取引のサマリー、及び前記支払い手段を使用して取引を完了することの同意を表示することを含む、請求項１１に記載の装置。
【請求項１５】
他の支払い手段への変更、前記取引を完了するための情報の入手、または前記支払い手段に関連する情報の閲覧を可能にするリンクを含む、請求項１１に記載の装置。
【請求項１６】
前記ソフトウェアの制御により、前記コンピュータが、支払い手段の認証のための認可コードを前記ディスプレイ上に表示することを含む、請求項１４に記載の装置。
【請求項１７】
前記ソフトウェアの制御により、前記コンピュータが、認可を受けたことを表わす指示を前記ディスプレイ上に表示することを含む、請求項１４に記載の装置。
【請求項１８】
前記ソフトウェアの制御により、前記コンピュータが、商人、発行者、広告者、または代理店へのリンクを前記ディスプレイ上に埋め込むことを含む、請求項１１に記載の装置。
【請求項１９】
認可レベルを超過する支払い手段を表わす指示を前記表示手段上に表示することを含む、請求項１１に記載の装置。
【請求項２０】
前記ソフトウェアの制御により、前記コンピュータが、各商人についてデフォルト支払い手段を規定することを含む、請求項１１に記載の装置。
【請求項２１】
前記ソフトウェアの制御により、前記コンピュータが、支払い手段が使用された各取引のリストを表示することを含む、請求項１１に記載の装置。
【請求項２２】
前記支払い手段は、発行者選択に従って前記ディスプレイ上に表示される、請求項１１に記載の装置。
【請求項２３】
選択された支払い手段に基づいて支払い処理が実施される、請求項１１に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
[発明の分野]
本発明は、通信ネットワークを通して購入する商品やサービスにアクセスするための電子支払いあるいは他の認可（ａｕｔｈｏｒｉｚａｔｉｏｎ）に関するもので、特に、クレジットカード、現金あるいは商品へのその他の支払いについて実生活での取引によく似た人間工学的な図のあるユーザネットワークインターフェースに関する。
【背景技術】
【０００２】
[発明の背景]
本発明は、現金、小切手、クレジットカードや信用状に代わる経済上の交換手段として、電子通貨支払いや電子金銭送金を行うために、通貨システムを電子的に図に示すことに関する。電子通貨システムは、現金や、小切手や、カード支払いシステムと電子金銭送金との組み合わせであって、このシステムには多くの利点があるが、限界の少ないものである。このシステムは、通貨システムの加入者が経済上の価値として広く受け入れ交換するように設計された、通貨の電子的な表示を用いる。
【０００３】
今日、毎年、個人や機関の間で約３５００億回の硬貨及び通貨取引がある。硬貨や通貨取引が広く行われていることが、購入や料金や銀行口座への入金や引き出しのような個々の取引を自動化する上で制限となっている。個々の現金取引では、正確な金額の現金を用意するあるいはそのお釣りを支払う必要がある。さらに、紙幣や硬貨を取り扱い管理することは不便であり、個人にとっても金融機関にとっても費用のかさみ、時間のかかることである。
【０００４】
小切手は口座の金額以内ではいかなる金額をも書き込むことができるが、小切手は流通性に限界があり、ある物理的な入れ物から出す必要がある。紙を元にした小切手システムは現金取引の限界を完全になくすものではなく、現金を扱う際に生じる多くの不便さを兼ね備えていて、小切手を処理するために不可避的に生じる遅れを有するものである。このために電子取引はより低いコストでより便利になるように努めるとともに、より安全なものを目指してきた。
【０００５】
コンピュータを用いた電子金銭送金システム（ＥＦＴ）による自動化を行うことで、大きな取引についてこれらの点のあるものは改善されてきた。電子金銭送金は、基本的にはバンキングシステムでの中央に結ばれたコンピュータ取引を通じて行う価値交換プロセスである。ＥＦＴサービスは電子「小切手」を用いる支払い送金であり、それはまず大きな商業組織で用いられている。
【０００６】
自動交換所（ＡＣＨ）、そこではユーザが予め認可されたコードを入力して後で生じる支払い情報を入手することができる、やポイントオブセールスシステム（ＰＯＳ）、そこでは中央コンピュータとつないで取引が行われて、その取引が即座に承認あるいは非承認される、それらは小売りや商業組織で使われているＥＦＴシステムの例である。しかし、この種のＥＦＴシステムを通して行う支払いは、バンキングシステムなしでは行うことができないという限界がある。さらに、ＡＣＨ取引は通常営業時間外には行うことができない。
【０００７】
ホームバンキングを使った請求支払いサービスはＥＦＴシステムの例であって、それを使って家庭のコンピュータから個人が支払いをすることのできるものである。現在、ホームバンキングを始めている人は非常に少ない。パーソナルコンピュータで電話線を使って支払いや口座送金や情報サービスをしている銀行はあるが、その銀行の顧客のうち１％以下の人がそのサービスを利用しているだけである。ホームバンキングがよく利用されていない一つの理由は、この種のシステムでは、顧客が必要とするお金を入金したり引き出したりすることができないことである。
【０００８】
商人の口座と顧客の口座間のような、口座間で金銭を送金するオンラインシステムとして用いられている、現行のＥＦＴシステム、クレジットカードや信用状は、人間工学的インターフェースを持った自動取引システムの必要性を満たすことができない。非人間工学的インターフェースを持ったものではあるが、ＥＦＴシステムの例は米国特許第５，４７６，２５９号、第５，４５９，３０４号、第５，４５２，３５２号、第５，４４８，０４５号、第５，４７８，９９３号、第５，４５５，４０７号、第５，４５３，６０１号、５，４６５，２９１号、及び第５，４８５，５１０号に示されている。
【０００９】
ある形をした経済上の価値を配ることのできる自動化した便利な取引を行うためには、オフライン支払いをする傾向があった。例えば、従来の現金や小切手での支払いシステムに代えるものとして、キャッシュレス支払い取引で使うことのできるある形をした「電子マネー」について、多くのアイデアが提案されている。米国特許第４，９７７，５９５号「電子現金を使う方法と装置」及び米国特許第４，３０５，０５９号「調節金銭送金システム」を参照。
【００１０】
もっとよく知られている技術は、所定の金額で購入した磁気ストライプカードであり、そこから特定の購入について支払った価値を差し引くことのできるものである。経済上の価値がなくなったとき、そのカードは捨てられる。他の例は、メモリーカードあるいはいわゆるスマートカードである。それは特定の購入について同様に差し引くことのできる価値を示している情報を繰り返して格納することのできるものである。
【００１１】
現金に代わる取引に関する技術はよく開発されているが、そのような取引について更にユーザフレンドリーなシステムや方法が強く要望されている。このようにして、ユーザから自然に見え感じられる表示を取り扱うことのできるシステムが必要とされている。特に重要なことは、一般に受け入れられている標準的な支払いと同じであることによって受け入れられるものである。
【発明の開示】
【発明が解決しようとする課題】
【００１２】
[例示的実施形態の概要]
実施態様の概要 発明のこれら及び他の目的について、本発明の簡単な概要を述べる。以下の概要ではいくつかの簡略化や省略を行っていることがあるが、それらは本発明の特徴を目立つようにして示すために行ったものであり、その範囲を限定するものではない。当業者が発明の概念を実施し使用することができる程度に好ましい実施態様の詳細な記述は後のところで行う。
【００１３】
発明の広い概念によれば、電子通貨システムは好ましい実施態様による取引を提供する。その電子通貨システムは、現金、クレジットカード、その他の支払い手段を入れておくのに伝統的に用いられている札入れ、小銭入れ、スマートカード、手帳、小切手帳、小型鞄、その他の支払い手段を入れているホルダーに代わり得るものである。札入れへのアクセスはパスワードで制限されている。パスワードは暗号化することができ、あるいは機密情報へのアクセスを制限するために暗号化のキーを生み出したり、認可されていない支払いを避けるために使うことができる。アクセスが認可されたとき、ユーザディフォールト、その手段のユーザディフォールトあるいは支払い手段を入れておくホルダーのディフォールトとして、ディスプレイ上にその手段の表示（ビットマップ）がなされて、ユーザが特定の取引に使用する支払い手段を選択できるようになる。支払い手段が選択されると、購入する商品の合計が示されるので、ユーザはその取引に電子承認を与えるか取りやめるかを入力する。電子承認を与えたら、電子取引が開始されて、その注文が実行される。
【００１４】
上述及び他の目的、特徴及び利点は、図面を参照しながら発明の好ましい実施態様についての以下の詳細な説明から更によく理解できるであろう。図においては、 第１Ａ図は、好ましい実施態様による、代表的なハードウェア環境のブロックダイアグラムである。
【発明を実施するための最良の形態】
【００１５】
[詳細な説明 ]
本発明によるシステムの好ましい実施態様は、ＩＢＭ ＰＳ／２、アップルマッキントッシュコンピュータあるいはユニックスを基礎としているワークステーションのようなパーソナルコンピュータを使って行うのがよい。代表的なハードウェア環境は第１Ａ図に示されている。それは、マイクロ処理装置のような中央処理ユニット１１０とシステムバス１１２を介して結ばれている他の多くのユニットを有する、好ましい実施態様による、ワークステーションの典型的なハードウェア構成を示している。第１図に示しているワークステーションは、ランダムアクセスメモリ（ＲＡＭ）１１４、リードオンリーメモリ（ＲＯＭ）１１６、ディスク格納ユニット１２０のような周辺機器をバス１１２につないでいるＩ／Ｏアダプター１１８、キーボード１２４やマウス１２６やスピーカ１２８やマイクロフォン１３２及び／またはタッチスクリーン（図示せず）のような他のユーザインターフェース機器をバス１１２につないでいるユーザインターフェースアダプター１２２，ワークステーションを通信ネットワーク（例えば、データ処理ネットワーク）につないでいる通信アダプター１３４，及びバス１１２をディスプレイ機器につないでいるディスプレイアダプター１３６を含む。ワークステーションは通常、マイクロソフトウィンドウズオペレーティングシステム（ＯＳ）やＩＢＭ ＯＳ／２オペレーティングシステムやマックＯＳまたはユニックスオペレーティングシステムのようなオペレーティングシステムの上で動く。本発明はここに述べた以外のプラットフォームやオペレーティングシステムの上でも実施することができることは、当業者には明らかであろう。
【００１６】
好ましい実施態様はＪＡＶＡやＣやＣ＋＋言語を用いて書かれていて、オブジェクトオリエンティドなプログラミング手法を用いている。オブジェクトオリエンティドなプログラミング（ＯＯＰ）は複雑な用途に用いるのに広く使用されるようになってきた。ＯＯＰがソフトウェア設計や応用の主流になりつつあるので、種々なソフトウェア解法がＯＯＰの利点を使えるように適用する必要があるだろう。メッセージングインターフェースの一連のＯＯＰクラスとオブジェクトを与えるような電子メッセージングシステムのメッセージングインターフェースにＯＯＰのこれらの原理を適用する必要がある。
【００１７】
ＯＯＰはオブジェクトを用いてコンピュータソフトウェアを開発する手段であり、それは問題を解析し、システムを設計し、プログラムを作る段階を持つ。オブジェクトは、データと、それに関係する構造と手続きの集合体との両方を含むソフトウェアパッケージである。それはデータと、構造と手続きの集合体との両方を含んでいるので、特定の仕事を行うのに他の余分な構造、手続きあるいはデータを必要としない、自己完結成分として示すことができる。それ故に、ＯＯＰはコンピュータプログラムを、各々が特定の仕事を行うことになっているほとんど自律的な成分、いわゆるオブジェクトの集合体とする。データ、構造及び手続きをまとめて一つの成分あるいはモジュールにパッケージングするこの概念はカプセル化と呼ぶ。
【００１８】
一般に、ＯＯＰ成分は再使用のできるソフトウェアモジュールであり、それはオブジェクトの型に合ったインターフェースを提供し、成分を集合化したアーキテクチャーによって実行時にアクセスできる。成分集合化アーキテクチャーは一連のアーキテクチャーメカニズムであり、違ったプロセスにあるソフトウェアモジュールがお互いの能力や機能を使えるようにしている。これは一般に、アーキテクチャーを構成する共通の成分オブジェクトモデルを想定して実施される。
【００１９】
この点で、オブジェクトとオブジェクトのクラスを分けておくことは意味のあることである。オブジェクトは、よく単にクラスと呼ばれている、オブジェクトのクラスの一つの例である。オブジェクトのクラスは青写真とみることができる。そこから多くのオブジェクトを形成することができる。
【００２０】
ＯＯＰによって、プログラマーは他のオブジェクトの一部であるオブジェクトを作り出すことができる。例えば、ピストンエンジンを示しているオブジェクトは、ピストンを示しているオブジェクトと成分関係を持つという。実際、ピストンエンジンは、ピストン、バルブ、その他多くの部品を有している。ピストンがピストンエンジンの一要素であるという事実は、ＯＯＰでは２つのオブジェクトを論理的にまた語義的に示すことができるということである。
【００２１】
ＯＯＰはまた、他のオブジェクトに「従属」しているオブジェクトを作り出す。２つのオブジェクトがあり、一つがピストンエンジンを示しており、他のものがピストンがセラミックでできているピストンエンジンを示しているとき、その場合この２つのオブジェクトの関係は成分のそれではない。セラミックピストンエンジンはピストンエンジンを作るものではない。それはむしろピストンエンジンの一種であって、ピストンエンジンよりも一つ多く限定を持っている。そのピストンはセラミクでできている。この場合、セラミックピストンエンジンを示しているオブジェクトは派生オブジェクトと呼ばれる、そしてそれはピストンエンジンを示しているオブジェクトの特徴のすべてを引き継いでいて、それにさらなる限定や詳細さを加えている。セラミックピストンエンジンを示しているオブジェクトは、ピストンエンジンを示しているオブジェクトに「従属」している。これらのオブジェクトの関係は継承と呼ばれる。
【００２２】
セラミックピストンエンジンを示しているオブジェクトあるいはクラスが、ピストンエンジンを示しているオブジェクトの特徴をすべて継承しているとき、それはピストンエンジンクラスに定義されている標準ピストンエンジンの温度特性を引き継いでいる。しかし、セラミックピストンエンジンオブジェクトは、セラミックの特別な温度特性で優れていて、それはメタルピストンのものとはかなり違っている。それは元のものを越えて、セラミックピストンの持っている新しい機能を使っている。違った種類のピストンエンジンは違った特性を持つだろうが、それについての同じ基礎になる機能、例えばエンジンに使われるピストンの数、イグニッションの順、潤滑等を持つ。いかなるピストンエンジンオブジェクトにもあるこれらの機能の各々にアクセスするのに、プログラマーは同じ機能を同じ名前で呼ぶだろう。しかし、各種のピストンエンジンは同じ名前の陰にある違ったあるいは優れた実行機能を持つことがある。同じ名前の陰に違った実行機能を隠すこの能力のことを同質異形性と呼んでいて、それはオブジェクト間の連絡を非常に簡単にする。
【００２３】
成分関係、カプセル化、継承、及び同質異形性の概念を用いて、オブジェクトを実世界のすべてのものと同じように示すことができる。事実、オブジェクトオリエンティドなソフトウェアでオブジェクトとなりうるものの種類を決める上でのみ、実物の論理上の認識は限界がある。いくつかの典型的なカテゴリーは次のようである。
・ オブジェクトは、交通の流れシミュレーションにおける自動車、回路設計プログラムにおける電気部品、経済モデルにおける国、あるいは航空交通管制システムにおける飛行機のような物理的なオブジェクトを示すことができる。
・オブジェクトは、ウィンドウズ、メニューあるいは図オブジェクトのようなコンピュータユーザ環境の要素を示すことができる。
・オブジェクトは、人員ファイルや都市の緯度や経度の表のような目録を示すことができる。
・オブジェクトは、時間、角度、複素数、あるいは面上の点のようにユーザが定義したタイプのデータを示すことができる。
【００２４】
オブジェクトは論理上区別することのできるいかなる状況をも示すことができるという能力があるので、ソフトウェアの開発者はＯＯＰによって、実物のある特徴をモデル化してコンピュータプログラムを設計し実行することができる。その実物が、物理的な実体であっても、方法であっても、システムであっても、あるいはものの構成部分であっても。オブジェクトによってなにでも示すことができるので、将来より大きなソフトウェアプロジェクトの部分として使うことのできるオブジェクトを、ソフトウェア開発者は生み出すことができる。
【００２５】
ある新しいＯＯＰソフトウェアプログラムの９０％が前からあって再使用のできるオブジェクトからなる検証済みで既に存在する部品からできているならば、新しいソフトウェアプロジェクトの残りの１０％だけが最初から書かれなければならないだけである。９０％がよく検証された再使用のできるオブジェクトの在庫から使えるので、誤りの生じる領域はプログラムの１０％だけである。結果として、ソフトウェア開発者はＯＯＰによって前に作ったオブジェクトからオブジェクトを作ることができる。
【００２６】
この方法は複雑な機械を組立品や中間組立品から作るのに非常によく似ている。ＯＯＰ技術は、それ故に、ソフトウェアエンジニアリングをハードウェアエンジニアリングのようにする。そこでは、開発者がオブジェクトとして利用できる既存の部品からソフトウェアを組み立てる。このことによって、その開発スピードを上げるだけでなく、ソフトウェアの質を高める。
【００２７】
プログラミング言語は、カプセル化や、継承や、同質異形性や、成分関係などのＯＯＰ原則を完全にサポートしている。Ｃ＋＋言語の到来によって多くの商業的なソフトウェア開発者は、ＯＯＰを採用した。Ｃ＋＋は、機械が早く実行することのできるコードを提供するＯＯＰ言語である。更に、Ｃ＋＋は、商業応用にもシステムプログラミングプロジェクトにも適したものである。今までのところ、Ｃ＋＋は多くのＯＯＰプログラマーにはもっともよく使われている選択であったが、スモールトークや、コモンリスプオブジェクトシステム（ＣＬＯＳ）及びエイフルのように主要な他のＯＯＰ言語がある。加えて、ＯＯＰの能力が、パスカルのようなもっと従来からよく使われるコンピュータプログラミング言語にも付け加えることができる。
【００２８】
オブジェクトの利点を次のようにまとめることができる。
・オブジェクトとその対応するクラスによって、複雑なプログラミングの問題をより多くの小さく簡単な問題に下げる。
・カプセル化によって、お互いに関連のつけられる小さな独立したオブジェクトにデータを組織してデータの抽象を行う。カプセル化は、オブジェクト内のデータを偶然の損傷から保護するが、オブジェクト構成員の機能及び構造を呼び出すことで、他のオブジェクトがそのデータと相互作用をすることができるようになる。
・サブクラシングと継承とによって、そのクラスで使われる標準クラスから新しい種類のオブジェクトを派生させることを通してオブジェクトを拡張及び修正ができる。このようにして、新しい能力を最初から作る必要がなくなる。
・同質異形性と多重継承によって、種々のプログラマーが多くの違ったクラスの特性を混合し、合致させることができて、予想していたやり方で関係するオブジェクトと一緒に働くような特別のオブジェクトを生じさせることができる。
・クラス階層と含有階層によって、実世界のオブジェクトをモデル化して、その間の関係をモデル化する柔軟性のあるメカニズムを生じる。
・再使用のできるクラスのライブラリーは、多くの場合に有効であるが、それらにはある限界がある。例えば、* 複雑さ複雑なシステムでは、関係するクラスのクラス階層は何十あるいは何百というクラスがあるので全く混乱するものとなる。
・コントロールのフロークラスライブラリーの助けを借りて書いたプログラムはコントロールのフローを管理しなければならない。すなわち、それは特別なライブラリーから生み出されたすべてのオブジェクト間の相互作用をコントロールしなければならない。プログラマーはどの機能を、何回、どの種のオブジェクトにするかを決める必要がある。
・重複した努力クラスライブラリーを用いてプログラマーは多くの小さなコード部品を使用、再使用できるが、各プログラマーはそれらの部品を違ったやり方で組み合わせことになる。２人の別のプログラマーが同じ組み合わせのクラスライブラリーを用いて、全く同じことを行うのに、その内部構造、すなわち設計、の全く違った２つのプログラミングを書くのに、各プログラマーがそれぞれのやり方で何百という小さな意志決定を行っている。必然的に、小さなコード部品は少し違ったやり方で小さなことを行うことになるが、もっとうまくいくはずのものがそのようにはならないことがある。
【００２９】
クラスライブラリーは非常に柔軟性がある。プログラムがより複雑になったときに、更に多くのプログラマーが基本的な問題に基本的な解法を何度も何度も発明せざるを得ない。クラスライブラリーの概念の比較的新しい拡張は、クラスライブラリーのフレームワークを持つことである。このフレームワークは更に複雑であり、小規模パターンと、特定の応用分野での共通の要求と設計を行う大きなメカニズムの両方を持っている共に作用するクラスの大きな集合体である。それらは、パーソナルコンピュータで、メニュー、ウィンドウズ、ダイアローグボックス及び他の標準的なユーザインターフェース要素を表示するのに伴う混乱から応用プログラマーを解放するために、当初開発されたものである。
【００３０】
フレームワークはまた、あるプログラマーの書いたコードと他の人の書いたコードの間の相互作用について、プログラマーの思考方法の変化を示す。手続きプログラミングの最初の頃は、プログラマーはオペレーティングシステムから出されるライブラリーを呼び出して仕事を行ったが、基本的にはページの最初から最後までプログラムを実行した。そして、プログラマーは一人でコントロールのフローに責任を持っていた。これは給料小切手を出力したり、数表を計算したり、ただ一つの実行方法しかないプログラムで他の問題を解決するには適したものであった。
【００３１】
図を使ったユーザインターフェースの開発によって、この処理プログラミングのやり方が裏返しになってきた。このインターフェースによって、ユーザがプログラムの論理よりも、プログラムを運転し、ある行為をいつ行うかの意志決定を行うことができるようになってきた。今日、ほとんどのパーソナルコンピュータソフトウェアは、マウス、キーボード、その他のイベントをモニターしているループによってこれを行うようになっていて、ユーザの行う行為によってプログラマーのコードの適当な部分を呼び出す。プログラマーはもはや事柄の起こる順序を決める必要がない。代わりに、プログラムは予想できないときに、予想のつかない順序で呼び出される別々の部品に分けられている。このようにして、ユーザをコントロールすることをやめることで、開発者ははるかに使いやすいプログラムを作ることができる。それにも関わらず、開発者の書いたプログラムの個々の部品は今でも、ある仕事を行うのに、オペレーティングシステムの提供するライブラリーを呼び出して、イベントループで呼び出された後、プログラマーは各部分にあるコントロールのフローを決定しなければならない。応用コードは今でも一番高いところにある。
【００３２】
たとえイベントループプログラムがプログラマに対して多くのコードを書くことを要求したとしても、各々のアプリケーション毎に別けて書く必要はない。アプリケーションフレームワークのコンセプトは更にループコンセプトを伴う。ベーシックメニュー、ウィンドウを構成する全てのナット及びボルト、ダイアログボックスを処理すること、及びこれらの全てを一体化して働かせることに代えて、アプリケーションフレームワークを用いるプログラマは、アプリケーションコード及び適切なベーシックユーザインタフェースを使用することから開始する。続いて、これらから、彼らはフレームワークの一般的なケーパビリティを意図したプログラムの特有のケーパビリティで置き換えることにより築き上げる。
【００３３】
アプリケーションフレームワークはプログラマが零から書かなければならないであろうコードの総量を縮小させる。しかし、フレームワークはウィンドウを表示し、複写や貼り付けをサポートする等の全く一般的なアプリケーションであるので、プログラマはイベントループプログラムが許容するより多くの程度までの制御を廃することができる。フレームワークのコードは殆ど全てのイベントの取り扱い及び制御の流れを処理し、プログラマのコードはフレームワークがそれを必要とする時にのみコールされる（例えば、適切なデータ構造を作ったり操作するために）。
【００３４】
フレームワークプログラムを書くプログラマはユーザに対する制御を廃するのみでなく、プログラム内のフレームワークに対する制御の詳細な流れをも廃する。このアプローチは、カスタムコードを有し同様の問題に対して繰り返し創作された独立したプログラムに対立するものとして、インタスティングウェイにおいて共同で処理するより複雑なシステムの創作を許す。
【００３５】
従って、以上に述べたように、フレームワークは基本的には、与えられた問題の領域のための再利用可能な設計の解決法を構成するコオペレーティングクラスの集合である。それは、典型的にはデフォルト動作（例えば、メニュー及びウィンドウ用）を与えるオブジェクトを含み、プログラマは、フレームワークが適切な時刻にアプリケーションコードをコールするために、いくつかのデフォルト動作を継承すること及び他の動作を無効にすることによりそれを用いる。
【００３６】
フレームワークとクラスライブラリとの間には、３つの大きな相違がある。
・プロトコルに対する動作。 クラスライブラリは、プログラムにおける個々の動作を必要とする時にコールすることができる動作の本質的な集合である。一方、フレームワークは、動作のみでなく、フレームワークが与えるものに対してプログラマが与えられると想像するもののための命令を含む、動作が結合され得る方法を決定するプロトコル即ち命令セットを与える。
・無効に対するコール。 クラスライブラリと共に、プログラマがオブジェクトをインスタンス化し、メンバ関数をコールするコード。フレームワーク（例えば、フレームワークをクラスライブラリとして処理するため）と共にオブジェクトをインスタンス化しコールすることが可能であるが、フレームワークの再使用可能な設計の利点を全て活用するために、プログラマは代表的には無効にしフレームワークから呼ばれるコードを書く。フレームワークはそのオブジェクトの間における制御の流れを管理する。プログラムを書くことは、どのようにして異なる部分が共に動作すべきかを特定するよりもフレームワークにコールされる種々のソフトウェアの間における責任を分け合うことを意味する。
・設計に対するインプリメンテーション。 クラスライブラリと共に、プログラマがインプリメンテーションのみを再使用するが、フレームワークと共に彼らは設計を再使用する。フレームワークは、関係するプログラム又はソフトウェアの部分のファミリが動作する方法を具体化する。それは、与えられた領域における種々の特定の問題に適用可能である一般的な設計の解決法を表す。例えば、単一のフレームワークは、たとえ同一のフレームワークと共に生成された２つの異なるユーザインタフェースが全く異なるインタフェースの問題を解決するとしても、ユーザインタフェースが動作する方法を具体化する。
【００３７】
従って、種々の問題及びプログラミング業務に対する解決のためのフレームワークの開発を通じて、ソフトウェアの設計における重要な削減及び開発の努力がなされている。本発明の好ましい実施例は、インターネット上へドキュメントをインプリメントするためのハイパーテキストマークアップランゲジ（ＨＴＭＬ）を利用する。ＨＴＭＬは、あるプラットホームから他へ持ち運びできるハイパーテキストドキュメントを創作するために用いられる単純なデータフォーマットである。ＨＴＭＬドキュメントは、広い範囲の領域からの情報を表すために適切である一般的なセマンティックを伴うＳＧＭＬドキュメントである。ＨＴＭＬは１９９０年から世界的な情報の先駆けであるワールドワイドウェブにおいて使用されている。ＨＴＭＬは、ＩＳＯスタンダード８８７９：１９８６、情報処理テキスト及びオフィスシステム；スタンダードジェネラライズドマークアップランゲジ（ＳＧＭＬ）のアプリケーションである。
【００３８】
遡ると、ウェブの開発ツールは、クライアントからサーバに広がるような及び現存するコンピュータ資源を相互にオペレートするようなダイナミックなウェブアプリケーションを創作するための能力を制限されていた。最近まで、ＨＴＭＬがウェブに基礎を置く解決法の開発において使用される支配的な技術であった。しかし、ＨＴＭＬは以下の領域において不十分であることが証明された。即ち、
・ 性能が不十分。
・ ユーザインタフェースのケーパビリティが制限される。
・ 静的にウェブのページを生成することのみ可能。
・ 現存するアプリケーション及びデータについての相互的なオペレートの能力の欠如。
・ スケールに対して無力。
【００３９】
サンマイクロシステムのＪａｖａ言語はクライアント側の問題の多くを以下によって解決した。即ち、
・クライアント側での性能を改善すること。
・ダイナミックでリアルタイムなウェブアプリケーションの創作を可能とすること。
・広範で多様なユーザインタフェースのコンポーネントを創作する能力を与えること。
【００４０】
Ｊａｖａによれば、開発者は強いユーザインタフェース（ＵＩ）のコンポーネントを創作することができる。カスタム”widgets” （例えば、リアルタイムのストックティッカーやアニメ化されたアイコン）が創作され得るし、クライアント側の性能が改善される。ＨＴＭＬとは異なり、Ｊａｖａは、性能を改善するためのクライアントへの適切な処理をオフローディングして、クライアント側の有効化の考えをサポートする。ダイナミックでリアルタイムなウェブのページが創作され得る。上述のカスタムＵＩコンポーネントを用いることによっても、ダイナミックなウェブのページが創作され得る。
【００４１】
サンマイクロシステムのＪａｖａ言語は、”インターネットをプログラミングする”ための産業的に認知された言語として出現した。サンマイクロシステムは、Ｊａｖａを以下のように定義している。即ち、”単純で、オブジェクト指向で、分散された、インタプリートされた、強く、安全で、アーキテクチャに対して中立で、ポータブルで、高い性能を持ち、マルチスレッド動作し、ダイナミックで、バズワードにコンプライアントで、汎用のプログラミング言語で、Ｊａｖａはプラットホームから独立したＪａｖａアプレットの形態でのインターネットのプログラミングをサポートする。”Ｊａｖａアプレットは、開発者がウェブドキュメント（例えば、単純なアニメーション、ページの装飾、基本的なゲーム、等）に対して”インタラクティブなコンテント”を付加することを許すサンマイクロシステムのＪａｖａアプリケーションプログラミングインタフェース（ＡＰＩ）に従う、小さくて特殊化されたアプリケーションである。アプレットは、サーバからクライアントへコードを複写することにより、Ｊａｖａ互換ブラウザ（例えば、ネットスケープナビゲータ）内において実行する。言語の立場から見ると、Ｊａｖａのコアの構成セットはＣ＋＋に基礎を置く。サンマイクロシステムのＪａｖａの文献は、Ｊａｖａは基本的には”よりダイナミックなメソッドの解決法のためのオブジェクト的なＣからの拡張を伴うＣ＋＋”であると述べている。
【００４２】
Ｊａｖａと類似の機能を与える他の技術は、開発者及びウェブ設計者に対してインターネット及びパーソナルコンピュータのためのダイナミックなコンテントを構築するための手段を与えるために、マイクロソフト及びアクティブＸの技術により与えられる。アクティブＸは、アニメーション、３−Ｄバーチャルリアリティ、ビデオ及び他のマルチメディアのコンテントを開発するためのツールを含む。このツールはインターネットの基準を使用し、複数のプラットホーム上で動作し、１００以上の会社によってサポートされている。このグループの構築するブロックはアクティブＸコントロールと呼ばれ、開発者がハイパーテキストマークアップランゲジ（ＨＴＭＬ）に部分的なソフトウェアを埋め込むことを可能とする小さくて速いコンポーネントである。アクティブＸコントロールは、マイクロソフトのビジュアルＣ＋＋、ボーランドのデルフィ、マイクロソフトのビジュアルベーシックプログラミングシステム及び将来におけるマイクロソフトのＪａｖａのためのコードネーム”Ｊａｋａｒｔａ”と言う開発ツールを含む種々のプログラミング言語と共同して動作する。アクティブＸ技術は、また、開発者がサーバアプリケーションを創作することを許容するアクティブＸのサーバフレームワークを含む。この分野の通常の技術者は、本発明を実施するための不適当な実験なしでアクティブＸがＪａｖａの代わりに用いられ得ることを容易に認識するであろう。
【００４３】
図１Ｂはネイティブコードを用いるシステムの好ましい実施例のブロック図である。システムの主要なコンポーネントが第１Ｂ図を参照して以下に述べられる。商人ウェブサイト１８０は、商人の又は他のウェブサーバ通信システムにより与えられるショッピングコモンゲートウェイインタフェース（ＣＧＩ）１９０を含む。ＣＧＩは、アプリケーションがアクセスし、処理し、入って来るメッセージに応答することを許容するインタフェースである。産業上の用語は、ＣＧＩスクリプトを、プログラマがスクリプトな言語におけるウェブサーバアプリケーションを記述する方法として参照する。ＣＧＩスクリプトは、ソフトウェアのアプリケーションプログラムの一種である。商人は、代表的には、ＣＧＩスクリプトを生成するオーソライゼーションのためのプログラムをセットアップする。オーソリティのサーティフィケイトは、また、ウェブサーバを有し、サーティフィケイトの要求の取り扱いはＣＧＩスクリプトを利用するであろう。顧客は商人のサイトで買物をするためにこのシステムとインタラクトする。商人システムは、また、ペイウィンドウのヘルパーアプリケーションを使用している顧客から始まる支払いのトランザクションを受け取る。支払い命令１９２は、顧客が支払いを選択した時に商人システムにより生成されるマルチパーパスインターネットメールエクステンション（ＭＩＭＥ）メッセージを表すファイルである。このＭＩＭＥメッセージは、注文の情報と、商人に特有の支払い命令とを含む。注文の情報は、商品及びサービスの注文（ＧＳＯ）、送り先、商人のユニフォームリソースロケータ（ＵＲＬ）、商人のサーティフィケイト、商人の名前及びアドレス、及び注文に関連させられたトランザクションＩＤを含む。支払い命令は、商人の受け取る支払い文書と支払いのプロトコルの選択とを含む。
【００４４】
商人システムからのＭＩＭＥメッセージを受け取ると、ブラウザは、ブラウザにおいてヘルパーアプリケーションとして規定されるペイウィンドウのアプリケーションを起動する。ブラウザはＭＩＭＥメッセージをペイウィンドウに送り、ペイウィンドウは支払いを完了するために顧客とインタラクトする。この分野の通常の技術者は、Ｊａｖａ、ネットスケープ／オラクルのプラグイン及びアクティブＸが容易にこの実施例のアーキテクチャの基礎をなすＭＩＭＥメッセージの代わりになることを容易に理解するであろう。Ｊａｖａの実施例は、他の好ましい実施例に関連した他の例を与えられるための選択的な実施例として以下に説明される。
【００４５】
アドレス命令ファイル１９４は、ウォレットデータベースから彼又は彼女のアドレスを自動的に埋めるために顧客が商人ウェブのページ上のボタンをクリックする時に、商人システムにより生成されたＭＩＭＥメッセージを表す情報を含む。ＭＩＭＥメッセージは、商人のＵＲＬと、ウォレットデータベースから商人が捜すしているアドレスの型とを含む。ウォレットは顧客の送り先と請求書のアドレスとを含む。一旦ＭＩＭＥメッセージが商人システムから受け取られると、ブラウザは、ブラウザにおいてヘルパーアプリケーションとして規定されるベリフォン（ＶｅｒｉＦｏｎｅ）ウェブサイト１８４のアドレス徴用アプリケーション１７６を起動する。アドレス徴用アプリケーション１４６、１７６はアドレス徴用要求を完了するために顧客とインタラクトする。
【００４６】
銀行ウェブサイト１６２でのサーティフィケイト発行は銀行ウェブサイト１８２に帰属する。それは、顧客へのＳＥＴコンプライアント／Ｘ．５００サーティフィケイトの発行を利用する。このシステムのインプリメンテーションは１つの銀行から他について一様ではない。しかし、高いレベルで、このシステムは顧客の個人情報を収拾する。情報を処理した後、システムは顧客への支払い文書に従ってサーティフィケイトを発行する。
【００４７】
銀行ウェブサイト１８２での単一口座のウォレット１６０は、サーティフィケィト発行システムにより生成されたＭＩＭＥメッセージを表す。このＭＩＭＥメッセージはベリフォンウォレットを含む。ベリフォンウォレットは、単一の支払い文書とこれに関連するサーティフィケイトとを含む。安全上の理由から、プライベートキーはウォレットには含まれない。顧客がサーティフィケイトを発行した時、このＭＩＭＥメッセージはブラウザに送られる。ブラウザは、ブラウザにおいてヘルパーアプリケーションとして規定されるサーティフィケイトインストレーションアプリケーション１７４、１４４を起動する。サーティフィケイトインストレーションアプリケーション１７４、１４４はＭＩＭＥメッセージを読み、ウォレットデータベース１５８にウォレットをインストールする。
【００４８】
種々のヘルパーアプリケーション１９８、１７２、１７４、１７６は、以下のヘルパーアプリケーションを含み、顧客の買物の体験を楽にし効率良くするために与えられる。ペイウィンドウヘルパーアプリケーション１８８は、商人に対する支払いをオーソライズするため、彼らのウォレットを管理するため、彼らの既に完了した支払いのトランザクションを検査するため、及び、ウォレットについての家計の活動を行うため、顧客により利用される。このアプリケーションは顧客のデスクトップ上で”ヘルパー”アプリケーションとして規定される。ブラウザは、商人システムがＭＩＭＥメッセージの支払い要求を送る時に、このアプリケーションを起動する。
【００４９】
ペイウィンドウセットアップヘルパーアプリケーション１７２は、ヘルパーアプリケーション及び他のモジュールをウェブサイトから顧客のデスクトップ上にインストールするために、顧客により利用される。顧客が最初にアプリケーションをインストールしようとする時、顧客はデスクトップ上にヘルパーアプリケーションを持たない。従って、アプリケーションの最初のインストレーションは、顧客に２つのステップの実行を要求する。最初に、ユーザは彼らのデスクトップにシステムパッケージをダウンロードしなければならず、次に、ユーザはシステムの圧縮を解凍しインストールするためのセットアップを行わなければならない。その後、顧客が新しくリリースされたシステムソフトウェアを購入する度に、ブラウザは、適切な他のシステムモジュールを交替してインストールするこのヘルパーアプリケーションを起動する。
【００５０】
サーティフィケイトインストレーションヘルパーアプリケーション１７４は、銀行により発行されたウォレットをインストールするために利用される。銀行のサーティフィケイト発行ウェブシステムがベリフォンウォレットを含むＭＩＭＥメッセージを送る時、ブラウザはこのアプリケーションを起動する。このアプリケーションは、ウォレットに含まれた支払い文書が現存のウォレットに複写されるべきか又は新しいウォレットに維持されるべきかを決定するために、顧客に質問する。このアプリケーションは、その後、支払い文書及びサーティフィケイトをウォレットデータベース１５８にインストールする。
【００５１】
アドレス徴用ヘルパーアプリケーション１７６は、彼又は彼女のアドレスを特定のウォレットから直接商人システムに送るために、顧客により利用される。商人システムが顧客の送り先及び／又は請求先アドレスを要求ＭＩＭＥメッセージを送る時、ブラウザはこのアプリケーションを起動する。このアプリケーション１７６は、ウォレットが既に開いていないでかつ顧客に要求したアドレスが示されていないならば、ウォレットを開くために、顧客に質問する。一旦顧客がアドレスを承認すると、アプリケーションは要求した情報をＨＴＭＬフォームで商人に対して”投函する”。このフォームのＨＴＭＬフォーマットは標準化されている。この（アドレス徴用）構成を採用する全ての商人システムはこのフォームを受け入れている。加えて、ヘルパーアプリケーションを走らせるために要求される他のソフトウェアモジュールが存在する。最初の頃に、これらのモジュール及びヘルパーアプリケーションは、顧客により彼の又は彼女のデスクトップ上にダウンロードされインストールされる。その後、セットアップヘルパーアプリケーション１７２が将来リリースされるヘルパーアプリケーション及び他のソフトウェアモジュールを自動的にインストールする。アドレス徴用は実施例として説明されたので、この分野の通常の技術者は、服のサイズ、音楽の好み、母親の名前又は他の商人の助けになる情報もまた類似の手段を通じてアップロードされ得ることを、この実施例から離れることなく、容易に理解できるであろう。
【００５２】
第２図はＪａｖａに基礎を置く本発明の実施に関連する選択的な好ましい実施例を与える。Ｊａｖａは、インターネット及びＨＴＭＬを利用することを可能とするアプリケーションのためのネットワークアプリケーションである。Ｊａｖａは、彼らのネットワークアプリケーションの開発の速度を上げるためにサンマイクロシステムスにより開発されたオブジェクト指向言語である。
【００５３】
先に述べた固有の実施例とＪａｖａ版との間の相違のみが、論を明確にするために述べられる。商人ウェブサイト１８０における支払い命令アプレット２００は、顧客のデスクトップ１８６上のペイウィンドウアプレット２１０、２３０に対する注文情報を配達するための応答が可能である。この注文情報は、ペイウィンドウシステムのビューネイティブコードセクションにおいて述べられている支払い命令のＭＩＭＥメッセージに含まれているのと同一の情報を有する。
【００５４】
前記アプレットは商人により顧客に表示される支払いＨＴＭＬ１９２のページの一部である。前記アプレットは、支払いのページが商人システムＧＳＯ、送り先アドレス、商人、商人のサーティフィケイト、商人のＵＲＬ及びボタンテキストにより生成された時に、以上のパラメータが適切なデータでセットされることを要求する。アプレット２００は”ぺイ””ぺイウィンドウ使用”と呼ばれるボタン、即ち、ボタンテキストパラメータの値を表示する。一旦クリックされると、アプレットは上記の情報を顧客のデスクトップ上のぺイウィンドウアプレットに配達する。顧客は、支払いのトランザクションを完了するために、ぺイウィンドウ２１０のアプレットとインタラクトする。
【００５５】
商人ウェブサイト１８０のアドレス徴用アプレット２０４は、顧客の送り先及び／又は請求先を得るために、商人システム１８０により利用される。このアプレットは”Ｖウォレット”と呼ばれるボタン、即ち、ボタンテキストパラメータの値を表示する。一旦クリックされると、アプレット２０４は顧客のアドレスを利用してアドレスウィンドウアプレット２１４を起動する。アドレスウィンドウアプレット２１４は顧客とインタラクトして、アドレス情報を商人システム１８０に送る。アドレス情報は、その後、本来のシステムにおける処理と矛盾なく処理される。
【００５６】
銀行ウェブサイト１８２におけるサーティフィケイト発行ＣＧＩスクリプト１６２及び単一口座アプレット１６０は、本来のシステムにおいて述べたように処理される。銀行ウェブサイト１８２のサーティフィケイトインストレーションアプレット２２０は、顧客のサーティフィケイトを顧客のデスクトップに配達するために、サーティフィケイト発行ＣＧＩスクリプト１６２システムにより利用される。
【００５７】
顧客の買物を容易にし効率良くするために、種々のアプレットがウェブサイトで与えられる。これらのヘルパーアプリケーションは、セットアップアプレット２１２、ぺイウィンドウアプレット２１０及び上述したぺイウィンドウヘルパーアプリケーションのネイティブセクションに類似のアドレスウィンドウアプレット２１４を含む。
【００５８】
第３図は本発明の好ましい実施例に関連するアーキテクチャのブロック図である。アプリケーションのグラフィカルユーザインタフェース（ＧＵＩ）部分がイニシャライズされる関数ブロック３００において、処理が開始される。ＧＵＩアプリケーション３００は顧客に買物の過程において注文するため及び支払いを行うためのサポートを与える。ウォレットの生成；輸入、サーティフィケイト及び支払い方法の生成及びメンテナンス；及びトランザクション登録の検査及び報告のために与えられるＧＵＩコンポーネントも存在する。ヘルパーアプリケーション及びアプレットのための表示画面の設計、及びこれに関する論理は以下において個々に詳細に述べられる。
【００５９】
サーティフィケイトマネージャ３０４は、銀行からの顧客のサーティフィケイトの自動的なダウンローディング、顧客の及び商人のサーティフィケイトの有効化、及びサーティフィケイトの更新の自動的な徴用を管理する。
【００６０】
支払いマネージャ３０６は商人システムから受け取られた支払い要求を統合し、完了する。支払い要求は、本来のコードのインプリメンテーションにおけるＭＩＭＥメッセージを通して、又は、Ｊａｖａのインプリメンテーションにおけるアプレットを通して、受け取られる。受け取られた支払い要求は、最後のＧＳＯ、送り先の名前、商人のサーティフィケイト、商人のＵＲＬ、クーポン及び支払いの合計を含む。マネージャ３０６は、その後、支払いのとトランザクションをオーソライズし完了するために顧客とインタラクトするため、支払い関連ＧＵＩコンポーネントと通信する。マネージャは、また、顧客の支払い命令及び商人の好ましい支払いプロトコルに基づいて支払いのプロトコルを決定するために応答可能である。
【００６１】
マネージャ３０６は、特定のＨＴＴＰサイトに対する支払いを行うための支払いマネージャ３０６とのインタフェースへのＯＥＭを可能にする、適切に規定されたアプリケーションプログラミングインタフェース（ＡＰＩ）を含む。支払いマネージャ３０６に関連する詳細なロジックは第４図に表される。
【００６２】
支払いマネージャ３０６は支払いプロセスにおける標準的なオペレーションを実施する。例えば、一旦支払いが完了すると、レシート及びトランザクションは自動的にウォレットファイルに転送される。好ましい実施例に関連する支払いマネージャのアーキテクチャは第４図に表される。ユーザは、種々のトランザクション４１０、４０８、４０６、４０４及び４０２に応答しこれらを送るインタフェース４００を通して、支払いマネージャ４３０とインタフェースする。前記トランザクションは次のレコード、支払いレコード、レシート、支払い文書のアクセプタンス及びＧＳＯコンポーネントを含む。
【００６３】
次に、支払いマネージャ４３０はトランザクション４１４及びレシート４２０をウォレットマネージャ４２２に送り、支払い文書、サーティフィケイト及びプライベートキーをウォレットマネージャ４２２から受け取る。
【００６４】
支払いマネージャ４３０は、また、商人の氏メッセージ４６０、顧客のサーティフィケイト及びＰＫハンドル４５０、商人のＵＲＬ４４２、支払い４４０、単一のレシート４３４及びＧＳＯ，選択された支払いプロトコル及び選択された支払い文書４３２を含むトランザクションを、プロトコルマネージャ４７０に送りまた受け取る。支払いマネージャ４３０は、更に、関数ブロック４８０に示すように、支払いアプレットからの入力又は商人からのＭＩＭＥメッセージを受け取る。支払い処理の１つの状況は、支払いプロトコルを単一のＡＰＩのカプセルに入れる顧客支払いクラスライブラリ（ＣＰＣＬ）である。支払いプロトコルをカプセルに入れることにより、アプリケーションはプロトコルの多様性から隔離される。ＳＥＴプロトコルは、セキュアエレクトロニクトランザクション（ＳＥＴ）プロトコルのクライアント側のコンポーネントのインプリメンテーションを与える。サイバーキャッシュのマクロペイメントプロトコルのクライアント側のコンポーネントの完全なインプリメンテーションもまた与えられる。
【００６５】
ウォレットマネージャ４２２はウォレットに対して標準的なインタフェースを与える。それは、ウォレットデータベースの構造及び支払い文書のデータ構造を決定し、ウォレットへのアクセスを制御し、１つ以上のアプリケーションが同一のウォレットを開こうとしたかの並列的なチェックを与える。ウォレットマネージャ４２２へのインタフェースは、ウォレットマネージャとのインタフェース及びウォレットデータベースへのアクセスのためのＯＥＭを許容すると公開されている。ウォレットマネージャは以下のサブコンポーネントからなる。即ち、
・ウォレットアクセス・・・このコンポーネントはウォレット情報を読み書きするためのインタフェースを与える。
・トランザクションマネージャ・・・このコンポーネントは、ウォレットデータベースへのウォレットに対応するトランザクションを読み書きするためのインタフェースを与える。
支払い文書マネージャ。このコンポーネントは、特定の支払い文書アクセスコンポーネントへのコモンインタフェースを与える。
・クレジットカードアクセス、デビットカードアクセス、チェックアクセス・・・これらのコンポーネントは特定の支払い文書を処理する。
【００６６】
データマネージャは一般的なデータ項目及びデータベースのレコードの記憶及び回復を与える。データフィールド、インデックスフィールド又は全体のデータレコードはエンクリプトなもの（ｅｎｃｒｙｐｔｅｄ）としてマークされ、エンクリプションプロセスは広く自動化されている。データベースマネージャは、異なる支払い方法に適したデータベースのレコードについての特定の知識を持たない。このレイヤーは、新しい支払いの方法が導入された時に、要求される変更を小さくするように、分離されている。しかし、ＲＳＡキーの対及びサーティフィケイトは”単一の”データ形式として考慮されるであろう。このコンポーネントは、また、コンピュータのディスク上の又はスマートカードに含まれたウォレットファイルをサポートするアブストラクションを与える。
【００６７】
オープンデータベースコネクティビティ（ＯＤＢＣ）／Ｊａｖａデータベースコネクティビティ（ＪＤＢＣ）のコンポーネントは、正式なデータベースコンポーネントが要求されるデータベースコネクティビティを与える。スマートカードウォレットの実施例は，ウォレットデータがクリプトグラフィック（ｃｒｙｐｔｏｇｒａｐｈｉｃ）トークンにより蓄積され及び／又は守られることを許容する。
【００６８】
好ましい実施例は、個人的な情報及び好ましいインプリメンテーションのマルチプルな支払い方法についての情報を含む”ウォレット”からなる単一のファイル又はファイルのディレクトリを含む。これらの支払い方法（ビサカード、クレジットカード、スマートカード、マイクロペイメント等）は、また、口座番号、サーティフィケイト、キーの対、満期データ等のような情報を含む。ウォレットは、ウォレットを用いて行われた支払いの各々に関係する全てのレシート及びトランザクションレコードをも含むと予想される。クリプトグラフィックＡＰＩコンポーネントは、ＲＳＡ及び関連するクリプトグラフィックソフトウェア又はハードウェアのための標準的なインタフェースを与える。このサポートは、エンクリプション、シグネチャ、及びキーの生成を含む。キー交換アルゴリズムの選択、シンメトリックエンクリプションアルゴリズム、及びシグネチャアルゴリズムは、全てコンフィギュラブルであるべきである。基礎のクラスは一般的な動作を規定し、派生したクラスは種々のセマンティックオプション（例えば、クリプトグラフィに基づくハードウェアに対するクリプトグラフィに基づくソフトウェア）を取り扱う。
【００６９】
クリプトグラフィックなソフトウェアの部分はＲＳＡ及びＤＥＳのサポートを与える。これは、特定の顧客のための選択的なインプリメンテーションに依存するＳＵＮ、ＲＳＡ又はマイクロソフトのシステムのコンポーネントを利用することを与えるであろう。クリプトグラフィックなハードウェアは、クリプトグラフィＡＰＩの基礎を支え、かつ、クリプトグラフィエンジンのシェルフでクリプトグラフィソフトウェアを置換するために利用することが可能な低いレベルのＡＰＩを生成する。
【００７０】
メッセージシーケンスのチャートは、顧客、ブラウザ及び／又はスメル（Ｓｕｍｅｒｕ）システムの種々の主コンポーネントの間のメッセージ／データの流れを述べる。システムの主コンポーネントは、ｖＰＯＳ、ペイウィンドウ、及び支払いゲートウェイを含む商人システムである。商人システムは、顧客が買物をし、ペイウィンドウアプリケーションにより送られた支払いトランザクションを受け取り、及び取得した銀行へ支払いトランザクションを送ることを許容する。顧客支払いクラスライブラリ（ＣＰＣＬ）モジュールは、支払いトランザクションを安全に顧客から商人に送るアプリケーション内のレイヤーである。
【００７１】
第５図は本発明の好ましい実施例に関連する顧客支払いメッセージシーケンスの図である。この図は、顧客、ブラウザ、商人システム、ペイウィンドウアプリケーション、及びＣＰＣＬの間におけるメッセージの流れを表す。このメッセージの流れは、注文が完了して顧客が支払いを選択した時から、支払いが証明されてレシートが顧客に戻される時までの支払いのプロセスを述べる。
【００７２】
ペイウィンドウアプリケーションの本来のインプリメンテーションとＪａｖａのインプリメンテーションとの間の相違は、ペイウィンドウへの注文情報の配達にある。一旦注文情報がペイウィンドウにより受け取られると、メッセージ／データの流れは双方のインプリメンテーションで同一である。本来のインプリメンテーションの場合、注文情報はＭＩＭＥメッセージを通して配達される。このＭＩＭＥメッセージはドキュメントファイルを通してブラウザによりペイウィンドウへ送られる。Ｊａｖａのインプリメンテーションの場合、注文情報はアプレットを通してペイウィンドウへ配達される。商人システムは、注文を次にペイウィンドウへ配達するブラウザへ注文情報と共にアプレットを送る。一旦注文が受け取られると、ペイウィンドウは顧客及び支払いプロセスの完了のためのプロトコルモジュールとインタラクトする。
【００７３】
注文入力と注文計算のクリック５２０
このメッセージは消費者の注文入力と‘注文計算’ボタンをクリックすることを表す。消費者のショッピング体験は、支払いプロセスを高輝度にする目的として全てこの一つのメッセージフローに集約される。実際になされるショッピングプロセスはさまざまであるが、注文を生成する目的は変わらない。
【００７４】
注文５３０
このメッセージはＨＴＭＬ形式によりブラウザにより商店に送られる注文情報を表す。
【００７５】
ＧＳＯ，ＰＰＰ，ＡＩ
商店の証明およびＵＲＬを伴うＰａｙｍｅｎｔ Ａｐｐｌｅｔ５４０ 注文を受け取ると、商店システムは支払いの額を計算する。このメッセージは、ＧＳＯ，ＰＰＰ，ＡＩ、商店証明およびＵＲＬを含むジャバのＰａｙｍｅｎｔアプレットにより支払い額を明細化する商店システムにより送られるＨＴＭＬページを開く。
【００７６】
Ｐａｙｍｅｎｔ Ａｐｐｌｅｔを実行する５４５
ジャバイネーブルブラウザは、Ｐａｙｍｅｎｔアプレットを実行する。このアプレットは、消費者がクリックするように“Ｐａｙ”と呼ばれるボタンを表示する。これは、商店により提供されるＨＴＭＬページに埋め込まれている。
【００７７】
Ｐａｙをクリックする５５０
このメッセージは、支払いの額を確認した後に消費者によりブラウザにＰａｙボタンのクリックを表す。
【００７８】
ＧＳＯ，ＰＰＰ，ＡＩ
商店の証明およびＵＲＬ５６０このメッセージはジャバアプレットにより搬送されるＧＳＯ，ＰＰＰ，ＡＩ，商店の証明およびＵＲＬを表す。ここで、ジャバアプレットはＰａｙＷｉｎｄｏｗアプリケーションにそれらを引き渡す。
【００７９】
商店証明５６２
このメッセージは商店の有効性をチェックするためのＣＰＣＬモジュールに送られる商店の証明を表す。
【００８０】
商店の有効性５６４
ＣＰＣＬモジュールは商店の証明を確認し、そしてこのメッセージを商店が有効な商店であるかないかを示すＰａｙＷｉｎｄｏｗにこのメッセージを送る。
【００８１】
Ｗａｌｌｅｔ，Ｐａｙｍｅｎｔ装置５６６
このメッセージは消費者に表示されるウァレット（書類入れ）および支払い装置を表す。ウァレットからの全ての支払い装置が消費者に示さることはない。商店により受け入れられたものだけが示されるだけである。
【００８２】
Ｐａｙｍｅｎｔ装置５６８
このメッセージは、消費者により選択される支払い装置を示す。このメッセージは“Ｓｅｌｅｃｔ Ｐａｙｍｅｎｔ Ｍｅｔｈｏｄ”ウィンドウの支払い画像上でユーザがダブルクリックした時にその時のデザインで作成される。
【００８３】
ＧＳＯ５７０
これは、“Ｍａｋｅ Ｐａｙｍｅｎｔ Ａｕｔｈｏｒｉｚａｔｉｏｎ”スクリーンにおいてＧＳＯが消費者に表示されることを指示する。
【００８４】
ＰａｙｍｅｎｔのＡｕｔｈｏｒｉｚａｔｉｏｎ５７２
このメッセージは、消費者による支払いのオーソライゼイションを表す。消費者は、“Ｐａｙｍｅｎｔ Ａｕｔｈｏｒｉｚａｔｉｏｎ”スクリーンで“Ａｐｐｌｅｔ”ボタンをクリックすることにより支払いを認める。
【００８５】
Ｐａｙｍｅｎｔ Ｐｒｏｔｏｃｏｌを決める５７４
消費者が支払いを認めると、支払いプロトコルが商店のＰａｙｍｅｎｔ Ｐｒｏｔｏｃｏｌ Ｐｒｅｆｅｒｅｎｃｅと消費者が選択した支払い装置に基づいてＰａｙ Ｗｉｎｄｏｗにより決められる。
【００８６】
Ｐａｙｍｅｎｔ Ａｕｔｈｏｒｉｚａｔｉｏｎ５７５
これらのメッセージは、商店のＵＲＬ，ＧＳＯ，使用する支払いプロトコル（ＰＰ）、口座番号、証明書およびプロトコルモジュールに送られる支払い装置に関係した個人キーハンドル（ＰＫ）を表す。
【００８７】
Ｐａｙｍｅｎｔ Ａｕｔｈｏｒｉｚａｔｉｏｎを伴うＧＳＯ５７６
このメッセージは、商店システムにプロトコルモジュールにより送られる支払い装置を示す。このＧＳＯ，ＰＩ、消費者証明およびＰＫは支払いプロトコルに基づいてパッケージされる。
【００８８】
署名された領収書５７８
このメッセージは、商店からのプロトコルモジュールにより受領されたデジタル的に署名された送信領収書を示す。
【００８９】
ハッシュされた値をもつ安全な領収書５８０
デジタル的にサインされた取引領収書は、将来の参照のためにＰａｙＷｉｎｄｏｗによりセーブされる。
【００９０】
支払い成功５８２
これは、取引領収書と‘Ｐａｙｍｅｎｔ Ｓｕｃｃｅｓｓｆｕｌ’が消費者に表示されることを表す。
【００９１】
[望ましい実施例によるＰａｙＷｉｎｄｏｗの必要条件]
支払いアプリケーションについての消費者の要求には、特定のターゲットのハードウェアプラットフォームをサポートすること、公衆ネットワーク上での支払い情報の通信、簡単な構成とアクセス可能性、簡単化された注文入力と取引の遂行を保証すること、安全に確実に支払い情報を記憶すること、幅広い多様な支払い装置を提供すること、消費者の好みの店のＵＲＬを持つこと、店を訪れるために支払いウィンドウからブラウザを開くこと、レコードを保持し、そして取引データに対するレコードを出力すること、ショッピングのアシスタンスを提供すること、一個のアプリケーションしかない多数のユーザをサポートすること、特定の商店に受入られる商店の証明と支払い形式表示すること、デジタルの資格認定を扱うこと、単一の支払い形態しかない多数の口座を提供すること、商店値の付加もしくはロイヤルティプログラムをサポートすること、およびサポートは他のクライアントの装置に移動可能でなければならないことのような様々な必要な条件がある。
【００９２】
一個の商店は、支払いアプリケーションに対してセットされた異なる必要条件を持ち、それは矛盾のない情報フォーマット、ロイヤルティとブランド化の機会、消費者が選択する多数の支払いタイプ、商店の記憶装置としっかり一体であること、システムから商店の記憶装置にリンクすること、システムを利用するリスク管理と割合のより良いことを含む。リンクは２つのディスプレイの間のハイパーテキスト結合、シングルディスプレイにおけるエリア間のポイント−ツウ−ポイント接続、ユニフォーム・リソース・ロケータ（ＵＲＬ）、インデックス、ある実行エリアから他の実行エリアに制御を移すことの容易なアドレスもしくは他の手段を参照することである（機械、ネットワーク・ロケーションもしくは人工衛生リンケージおよびマイクロウェーブ送信においてさえ交差して）。
【００９３】
この発明に従う望ましい実施例は、電子支払いをなす消費者により使用されるソフトウェアアプリケーションを提供する。それは消費者のワークステーションで実行され、そしてＷＷＷブラウザへのフリー・スタンディング・アプリケーション、もしくは消費者アプリケーションに埋め込まれているのいずれかであり、そして消費者が特定のアイテムに対する注文プロセスを実行した時にはいつも要求され、そして支払う用意をするものである。望ましい実施例に従うＰａｙＷｉｎｄｏｗアプリケーションは、多数のローカルユーザをサポートする。各ユーザのデータは、独立に記憶されそして安全にされている。プログラムのスタートアップにおいて、ユーザはＩＤとパスワードにより署名しなければならない。あらゆる情報（ローカルディスクもしくはフロッピィ上での）は、プログラムが要請される度にユーザにより入力されたパスワードで暗号化される。
【００９４】
Ｐａｙｍｅｎｔ装置
社会的、経済的および文化的ファクタに関係する様々な大きさの取引および異なる支払い装置に従って、多数の支払い装置に対してサポートが要求される。今日多くあるように、商人から購入する消費者はその個人の好みに依存した支払い方法の選択を持たねばならない。そのサポートされる支払いは、クレジットカード、電子チェック、電子マネー、マイクロ−ペイメント（電子コイン）、請求カードおよびスマートカードを含む。
【００９５】
安全な支払いプロトコル
望ましい実施例に従う核となる特徴の一つは、安全性と信頼性のある方法で支払いを受けることおよびなす能力である。インターネットにおける安全な支払いは、本発明の他の概念に従って支払い解決をする今日のＰｏｉｎｔ ｏｆ Ｓａｌｅ（ＰＯＳ）ターミナルと同じように安全で信頼できるようになっている。安全性のプロトコルの選択は、技術設計的配慮で考慮できる一方、その解決を素早くマーケットに供することにおいて高い市場価値がある。
【００９６】
支払いプロセス
支払いプロセスは、管理的機能から切り離されている。消費者が商店から購入することを決めると、依頼人はユーザ名とウォレットパスワード、そして商店および注文情報を表示し、ユーザがウォレットから支払い装置を選択し、そして注文容認とデジタル領収書を表示して捕獲する。基本的に支払い装置として、メンバーシップ、識別性、証明もしくはオーソリティの証拠であるなんらかの装置を利用できる。例えば、ビデオメンバーシップのためのカードがインターネットを介して電子的にビデオをチェックアウトするのに利用される。
【００９７】
サポートされている取引
望ましい実施例に従うアプリケーションは、セールを生成することおよび取引タイプを書き換えることができる。それはまた、ユーザの望みのファイルに基づいてアドレスの自動設定（ｆｉｌｌ−ｉｎ）を提供し、そしてもし、取引が開始された時にいかなる情報も明細化されないなら、最終支払い取引から情報が不履行情報として利用される。
【００９８】
ショッピングサポート（ショッビングコンパニオン）
望ましい実施例に従うアプリケーションは、また、商店および消費者が訪問のリンケージの前によくかよった商店からのＵＲＬをもつ支払いとショッビング情報を共有する。
【００９９】
管理機能
アプリケーションの利用を簡単にするために、実際の支払いと管理的機能が独立している。ユーザはオンラインの支払いプロセスの実行を試みている間に管理情報を示されない。それ故に、次の管理的機能がサポートされる。
【０１００】
日付管理
日付は、ユーザの要求により基本的に周期的にディスクに自動的にバックアップされる。ユーザはさまざまな方法でバックアップの内容を見ることができる。例えば、ユーザは、バックアップ、記憶されたあらゆるデータ、選択されたユーザ情報のみ、もしくは支払い履歴情報以外のあらゆるものから選択して再記憶できる。データを出力は、またｅメールに対する選択されたデジタル領収書もしくは注文確認に対してサポートされ、もしくは銀行もしくは他の商店との論争解決を印刷することをサポートする。データ出力は、会計プログラムであるＱｕｉｃｋｅｎ，Ｍｉｃｒｏｓｏｆｔ Ｍｏｎｅｙ ａｎｄ Ｍａｎａｇｉｎｇ ｙｏｕｒ ｍｏｎｅｙに提供される。
【０１０１】
領収書と取引履歴管理
領収書と取引履歴管理はまた、時間、支払い装置タイプ、商店による、および遂行された、遂行されなかったもしくはペンデイングの取引による注文履歴を見るために提供される。パージ注文履歴取引がまた時間もしくは支払い装置タイプにより注文履歴ファイルをパージするために提供される。クレジットカード番号、満了日、名前、小切手アドレス、公衆キー証明を含むなされた注文に対するデジタル領収書を示す他のレポートが提供される。注文確認は、またなされたあらゆる注文に対して送信され、そしてもしアイテムが外部会計管理プログラムに出力されるなら、出力ステータスタグが生成される。
【０１０２】
ユーザ管理
さまざまなユーザ管理装置が提供される。それらは、新しいユーザが生成される時に、ユーザに対する空のウァレットを作り、そしてユーザに対してデフォルトパスワードをセットする特徴を含む。削除ユーザ、変更ユーザパスワード、およびユーザとしての署名がまた提供され、しかしユーザのパスワードが活性化されることを要求する。ユーザのビューリストがまた提供され、そしてシステムに定義されたユーザを調べるためにパスワードは必要としない。
【０１０３】
ウァレット管理
ウァレットはユーザ特定であり、そしてウァレットが有効に属するユーザに特定である必要がある。望ましい実施例は新しい支払い装置を付加するため、支払い装置を削除するため、支払い装置のリストと支払い装置を修正するための処理を提供する。
【０１０４】
Ｌｏｙａｌｔｙ Ｐｒｏｇｒａｍ Ｃｏｕｐｏｎ
商店が使用できる他のロイヤルティプログラムと同様にクーポンがまた受け入れられ、そして装置が、ロイヤルティプログラム状態を見るため、そして存在するクーポンを見るために提供される。
【０１０５】
共通動作性
本発明の望ましい実施例は、多くのブラウザと商店システムと共通的に動作する。ブラウザおよび商人に交差する共通動作性の要求はベースレベル機能に適用される。
【０１０６】
スマートカード統合
スマートカードの統合は、消費者に他の支払い方法を提供し（スマトカードの記憶値）、ウァレット情報の携帯性（キー、支払い、支払い情報）。
【０１０７】
国際的ローカライゼーションの必要条件
特定の国へのローカライゼーションに対するサポートは、多数の世界中の国向けの製品に構築される。
【０１０８】
第６図は、本発明の望ましい実施例に応じた支払いユーザインタフェースの詳細ロジックを説明するフローチャートである。処理は機能ブロック６００から開始し、その機能ブロックはジャバアプレットとして埋め込まれたインターネトブラウザが支払いボタンの選択を検出するものであり、そしてテストが、ウァレットが開かれているかどうかを決定するために決定ブロック６１０で実行される。もし、そうなら、その時、支払い方法が機能ブロック６３０で決定され、そしてもしユーザが処理をキャンセルするなら、その時６３２で制御がインターネットブラウザに戻される。もし、ユーザが機能ブロック６３４で支払いオーソライゼイションを選択したら、その時、ユーザが機能ブロック６５０で示されるようにオーソライズをキヤンセルできるなら、機能ブロック６４０で示されるように支払いオーソライズを受け入れ、もしくは機能ブロック６３０へ制御を移動する６３５で示されるように支払い方法を変更する。もし、テストが決定ブロック６１０で実行それた時、ウァレットが開いていなかったら、その時ウァレットは、機能ブロック６２０で示されるように開かれ、そして制御が第７図で示される論理と一致する処理のために６２２でＡｄｍｉｎｉｓｔｒａｔｉｏｎ Ｓｃｒｅｅｎに渡るか、もしくはもしユーザが処理をキャンセルするなら、その時制御は６２４で示されるインターネットブラウザに戻される。
【０１０９】
第７図は、望ましい実施例に従う支払いウィンドウの管理モードに関連する詳細論理のフローチャートである。アプリケーションがデスクトップに置かれた時、処理が機能ブロック７００で始まる。ユーザは、多くの利用可能な選択をもつＰａｙＷｉｎｄｏｗ７１０を最初に見る。もし、ユーザがウァレット７２０を選択したなら、その時機能ブロック７２１でウァレットが開かれ、そして制御が支払いの特定の様式が選択されるように機能ブロック７２２に渡され。支払いの特定の様式が７２４で選択されたら、もしくは支払い選択が７２６でキャンセルされたら、その時、制御が機能ブロック７２０でメインウィンドウに戻される。しかし、もし、ユーザが機能ブロック７２１で新しいウァレットを開くことを選択したなら、その時、さらに処理するために、制御は管理機能ブロック７４０に渡される。
【０１１０】
もし、ユーザがメインウィンドウ７１０から管理モードを選択したら、その時他のテストが、ウァレットが開かれているかどうかを決定するために決定ブロック７３２で実行される。もし、ウァレットが開かれているなら、その時、さらに処理するために管理機能ブロック７４０に渡される。もし、ユーザがメイン支払いウィンドウ７１０からレジスタ処理７１２を選択するなら、その時、８００で第８図に詳細に示されるレジスタ機能ブロックに渡される。もし、ユーザがレポート処理を選択するなら、その時、さらに処理するために、制御が第８図のレポート機能ブロックと８６０に渡される。もし、ユーザがバックアップ／再記憶７１６を選択するなら、その時バックアップもしくは再記憶が、上記のような望ましい実施例に従ってオペレーティングシステムツールを利用して実行される。
【０１１１】
もし、ウァレットが決定ブロック７３２で開かれないように決定されたら、その時、制御がウァレットを開くように機能ブロック７３４に渡される。ウァレットが開かれた後、それから制御が支払いを選択するように機能ブロック７３６に渡されるか、もしくはユーザが操作をキャンセルするなら、制御がメインウィンドウ７１０に渡され、もしくはこれが新しいウァレットであるなら、その時制御が管理機能ブロックに７４０に渡される。
【０１１２】
制御が管理機能ブロックに渡される時、その時、もしウァレットタブが選択されたら、その時制御は機能ブロック７５０で管理ウァレットページに渡り、そしてもしユーザがブラウジングに関心があるなら、その時、ファイルオープンダイアログが機能ブロック７６０で開始され、もしくは処理からウァレットを移動する要求が受け取られたら、移動確認ダイアログが機能ブロック７７０で開始される。もし、ユーザが管理優先を変更することに関心があるなら、その時制御が機能ブロック７８０に渡される。もし、支払い管理処理が選択されたら、その時、機能ブロック７９６に示されるように証明がインストールされる機能ブロック７９０で示されるように管理支払いページに渡される。確認ダイアローグが機能ブロック７９４で付加できるか、もしくは移動確認ダイアローグが機能ブロック７９２で処理される。管理処理がなされた時、制御が機能ブロック７１０のメインウィンドウに戻される。
【０１１３】
第８図は、望ましい実施例に従うレジスタおよびレポート処理に関連する管理モード処理のフローチャートである。もし管理レジスタタスクが処理されるなら、制御が通過する８００で処理が始まる。レジスタ機能は、機能ブロック８０２で理解され、そしてもし詳細機能が処理されるなら、制御が、商店サイトへのホットリンクが望まれるかどうかを決定するために機能ブロック８５０に渡される。もし、そうなら、その時、制御がブラウザを起動しそして８５６で商店サイトに行くために、８５２を介して渡される。もし、そうでないなら、その時、制御がレジスタ機能８０２に戻り８５８を介して渡される。もし、見いだした機能が処理されるなら、その時、制御が、見いだした操作が特定のアイテム８４４に対して実行され、もしくは見いだした次の操作が８４２で実行される機能ブロック８４０に渡される。
【０１１４】
見いだされた処理が達成されたかあるいは８４６でキャンセルされた時、制御がメインレジスタスクリーンに戻される。もし、カストマイズレジスタ処理が望まれるなら、その時、制御がレジスタをカストマイズするために機能ブロック８３０に渡される。もし、クリア操作が必要なら、その時、制御がレジスタをクリアするために８３２に渡される。カストマイズ操作が達成される時、その時、制御がメインレジスタ処理に戻るように渡される。もし、レジスタ削除の操作が必要なら、その時、制御が機能ブロック８２０に渡され、そして削除確認ダイアログが機能ブロック８２２で処理される。最終的に、もし、出力レジスタ操作が要求されるなら、その時、制御が機能ブロック８１０に渡され、そしてファイルオープンダイアログが機能ブロック８１２で開始される。ダイアログが達成される時、その時制御が機能ブロック８０２に戻される。
【０１１５】
もし、レポートボタンが管理支払いスクリーンで押されたなら、その時、機能ブロック８８０でレポートをカストマイズするために、８８２でレポートをクリアするために、もしくは機能ブロック８７４でファイルオープンダイアログを介して達成されるレポートを８７２で出力するために、制御がレポート機能ブロック８７０に８６０で渡される。
【０１１６】
ＰａｙＷｉｎｄｏｗ
第９図は、望ましい実施例に従う支払いウィンドウ表示の実施例である。支払いウィンドウ９８０は、適切なパスワードが入力点９３０を介して入力されたらユーザにパースビットイメージ９００もしくはウァレットビットイメージ９１０、９２０のようなグラフィック様式の利用可能な支払い装置ホルダーのリストを示す。スクロールバー９２２は、スクロールされるべき利用可能な支払い方法を許容するように提供され、もしくは上向き矢印９２４もしくは下向き矢印９２６を選択することが利用可能な支払い方法を調べるために使用できる。加えるに、９７０を開くため、新しいウァレット９６０を作るため、そして支払い９５０をキャンセルためにスクリーンのボタンで提供されるエリアがある。キャンセルボタン９５０は、支払いキャンセルスクリーンの表示を要請する。最終的にメッセージ領域は、システムメッセージ９４０に通信するためにスクリーンのボタンを提供される。
【０１１７】
もし、ユーザがマウスボタンの右か左を押せば、ウィンドウの焦点はそれに応じてシフトする。ＣＰＵに接続されたキーボードのタブキーは、ディスプレイ上で様々な制御の間にハイライトを動かしたりもしくは循環するのに利用される。もし、入力キーが押されたら、ハイライトされた制御が活性化される。例えば、もし、情報がパスワードフィールド９３０に入力された後に入力キーが押されたら、その時、パスワードは、有効なパスワードが入力されたかどうかを決定するためにパスワードファイルでチェックする。ウァレットのリストボックスは、システムにインストールされたあらゆるウァレットを示すシングル選択リストボックスである。ユーザは、開くべきウァレットを選択するのにマウスもしくはキーボートを利用出来る。新しいボタン９６０は、新しいウァレットファイルを作り、そしてウァレット情報入力のために‘Ａｄｍｉｎｉｓｔｒａｔｉｏｎ’を表示する。
【０１１８】
支払い装置
第１０図は、好適具体例に従い、ユーザが選択するためのビットマップイメージとして表される支払い装置のリストを表している。支払い装置は、クレディットカード、キャッシュカード、スマートカード、電子キャッシュ、マイクロペイメント、及び電子小切手を含んでいる。オープンボタン９７０は、支払い装置スクリーンを呼び出す。セレクトボタン１０００をクリックすることにより、命令の詳細が表示される認可スクリーンに制御は移る。第１０図に表された支払い装置は、ユーザの実際のカードに事実上同一のグラフィックイメージ、支払い装置保持者ネーム、装置ネーム、会員期間及び終了日のような情報を持つバンク・アメリカード・ＶＩＳＡ１０４０を含んでいる。このようなイメージは、ユーザのカードをスキャニングし或いはメーカのテンプレートを利用しそしてユーザネームを表すテキストを付加することにより得ることができる。チェブロン当座勘定１０２０はまた、好適具体例においてサポートされている別のタイプの支払い装置であるユーザの当座勘定を表す拡大チェブロンロゴを備えている。ウエルズ・ファルゴ・ＶＩＳＡ１０３０支払い装置がまた、好適具体例に従い提供される。実際のＶＩＳＡカードの実際的な表示が第１０図に表されているが、当業者は、他のユーザ限定のグラフィック又はテキスト情報が支払い装置を表すために利用することができるということを容易に認識するであろう。キャンセルボタン１０１０を押すと、支払いキャンセルスクリーンに戻る。ボブのウオーレット１０５０を選択すると、ボブのウオーレットパスワード９３０を入力するために開いたウオーレットの表示スクリーンに戻る。いずれかの支払い装置をダブルクリックすると、その特別の支払い装置のための認可スクリーンに入る。支払い装置アイコンをクリックすると、その周りに境界を付して、それが選択されたことを示す。この境界の一例が、ジェーンの財布１０６０に対して示され、かつジェーンの財布と関連したグラフィックは、１０６０で示されるような開いた位置におけるグラフィックである開いた状態の証印を有している。同様に、もし、ボブのウオーレット１０５０のような一つのウオーレットが選択されるならば、このウオーレットと関連したグラフィックは、色の変更、又は、開いたウオーレットを描くグラフィックのようなオープンの証印によって表すことができるであろう。
【０１１９】
好適具体例に従うソースコードが、詳細なロジック開示の別の形態として以下に提供される。WalletBrowserPanelクラスは、そこに含まれるウオーレット及び支払い装置を表示する。それは、PasswordEntryPanel、ImageSelectorPanel及びImageItemクラスを利用する。PasswordEntryPanelクラスは、ユーザからの与えられたウオーレットのためのパスワードを受け取る。ImageSelectorPanelクラスは、ウオーレットアイコン及び支払い装置イコンを表示し、かつユーザにウオーレット又は装置を選択／選択解除させる。スクリーン上のアイコンの表示は、ImageItemクラスによって管理されている。
【０１２０】
【表１】
2008186474.tif 000003
【表２】
2008186474.tif 000004
【表３】
2008186474.tif 000005
【表４】
2008186474.tif 000006
【表５】
2008186474.tif 000007
【表６】
2008186474.tif 000008
【表７】
2008186474.tif 000009
【表８】
2008186474.tif 000010
【０１２１】
認可（ａｕｔｈｏｒｉｚａｔｉｏｎ）
第１１図は、好適具体例に従う認可表示スクリーンである。認可スクリーンは、取引の詳細を表示し、かつ一つの特別の取引の全ての詳細についてユーザが調べるのを容易にする。それはまた、ユーザが取引を受け入れ又はキャンセルし、或いは特別の取引のための支払方法を変更するのを可能にする。ウエブページ上の支払いボタンは、一つのウオーレットが既に開かれているときこのスクリーンを始動する。支払い変更方法１１００は、ユーザが異なる支払い装置を選択するのを可能にするために支払い装置スクリーンを表示し、かつ第９図に示された支払いウインドー表示に制御を移す。オーダータブ１１１０は、オーダー、取引先又はアドレスに関する取引についての情報ページの表示を制御する。アクセプトボタン１１４０を押すと、ユーザの取引受け入れを信号し、かつそれは、取引データをウオーレットのレジスタに記録し、第１２図に１２００で示されるようにＰＡＩＤ受け入れを表示する。キャンセルボタン１１５０を押すと、第１３図に１３００で示されるように支払いキャンセルスクリーンを表示する。
【０１２２】
支払いウインドーメイン
第１４図は、本発明の好適具体例に従い、メインスクリーンを例示している。このスクリーンは、ユーザがローカルモードでアプリケーションを起動しかつ支払いウインドーが管理モードで動作しているということを示すとき表示される。このアプリケーションは、デスクトップから起動する。スクリーンコントロールは、支払いウインドースクリーンを表示しかつユーザが新たなウオーレットを開き或いは作成するのを可能にするウオーレット選択ボタン１４０１を含んでいる。別のボタン、リポートボタン１４１０は、それが選択されるときリポートウインドーの一例を開く。レジスターボタン１４２０を選択すると、多様なレジスタ取引からユーザが選択するのを可能にするレジスターウインドーを開く。管理ボタン１４３０の選択は、ユーザが種々の管理タスクを実行するのを可能にする管理スクリーンを開く。もしユーザがバックアップ／回復ボタン１４５０を選択するならば、そのときバックアップ／回復ダイアログが開始される。最終的に、終了ボタン１４６０の選択は、スクリーンを閉じ、かつこのアプリケーションを終了させる。
【０１２３】
管理
第１５図は、好適具体例に従う管理表示スクリーンの例示である。これは、ウオーレット、支払い方法及びユーザ選択設定に関係する情報を入力するためのメインスクリーンである。この情報は、組織化され、そしてグループ化されたデータのページに提示される。管理表示は、ユーザによるボタンの選択に応答して第１４図の管理ボタン１４３０から起動される。ウオーレットタブ１５１０は、現在アクティブなウオーレットに属する関連情報のページの管理を制御する。ユーザは、情報ページを変更するためにマウス又はキーボードを利用することができる。完了ボタン１５９０は、それが選択されるときウオーレット内に新たな情報を保存する。キャンセルボタン１５９５は、それが選択されるとき、この変更を捨て去り、表示スクリーンを閉じる。
【０１２４】
第１６図は、好適具体例に従う管理ウオーレットページの表示を例示している。ユーザは、ウオーレットの名前をエントリーフィールド１６６０に入力しなければならず、ウオーレットの所有者は１６７０に入力されなければならず、名前を付けたウオーレットに相当するパスワードは、１６７５に入力されなければならず、パスワードエントリーは、パスワードの英字及び数字の代わりに入力された文字と共に表示され、かつ確認パスワードがエントリフィールド１６７８に入力されなければならない。確認パスワード１６７８は、１６７５で入力されたパスワードに一致しなければならない。ブラウズボタン１６８０は、ファイルオープンダイアログを開いて、ウオーレットのリストをユーザに提示して、このプロセスへの入力として使用するウオーレットアイコンファイルから選択する。ウオーレット削除ボタン１６８５は、現在のウオーレットをこのシステムから取り除き、かつ削除の前に確認メッセージボックスを表示する。
【０１２５】
第１５図の支払い管理タブ１５２０は、第１７図に示されるようにスクリーンを開始する。第１７図は、好適具体例に従う支払い管理ウインドーである。ユーザは、支払い方法の情報を観察し又は編集するために管理スクリーンの支払いページを使用することができる。
【０１２６】
リストボックスコントロール１７１０は、このウオーレット内に現在インストールされている全ての支払い方法を表示する。ユーザは、リストボックスコントロールをスクロールして、所有者に利用可能の全ての支払い方法１７６０を見ることができる。ユーザは、その情報を見る前に支払い方法を選択しなければならない。この選択は、ユーザが必要とする支払い方法上にカーソルを位置決めし、かつマウスボタンをクリックするか又は支払方法としてそのカードを選択するための入力キーを押すことによって達成される。カードネーム編集フィールド１７５０は、このシステムが支払いのために現在選択した方法を参照するために利用する名前を表示し又は編集するために使用される。カードタイプデータエントリフィールド１７６０は、支払方法の種々のタイプに相当する。このタイプの多くは、マスターカード、ＶＩＳＡ、ディスカバーのように、ユーザに対してあらかじめ定められている。
【０１２７】
関連したカード番号エントリフィールド１７８０はまた、カード番号を表示しかつ／又は編集するために備えられている。エントリフィールド１７８２はまた、カードの終了日を表示しかつ／又は編集するために備えられている。証明書ダイアログボックス１７８４ボタンがまた、付属書の開始、即ち証明書の編集のために備えられている。チェックボックスコントロール１７９２がまた、もしユーザが選択したカードに特別のウオーレットのためのデフォルトの支払方法を望むならば、備えられる。ウオーレットが開かれる毎に特別の支払方法を選択する必要がないので、これは魅力的な特徴である。支払い方法のホルダー（即ち、ウオーレット、財布、ブリーフケース、スマートカード）が選択されるとき、お気に入りのクレディットカードが通常容易な読み出しのために便利なロケーションに記憶されているユーザのウオーレットを並べるために、人間工学が十分考慮されている。２つの他のボタンが、支払方法のホルダーに支払方法を付加し１７８６，かつそこから削除するために１７９０備えられている。削除ボタン１７９０は、支払い方法の削除の前に確認メッセージを表示する。プロセスの完了１７４２を意味するボタン及びプロセスをキャンセル１７４６するボタンがまた供えられる。
【０１２８】
第１８図は、好適具体例に従う管理選択ページの例示である。アドレスライン１エディットコントロール１８１０が、特別のユーザのために第一のシップメントアドレスラインを観察し、又は編集するために使用される。アドレスライン２エディットコントロール１８２０が、特別のユーザのために第二のシップメントアドレスラインを観察し又は編集するために使用される。シティクレディットコントロール１８３０が、特別のユーザのためにシップメントシティを編集し又は観察するために使用される。ステートエディットコントロール１８５０は、特別のユーザのためのシップメントステートを編集し又は観察するために使用される。ジップコードエディットコントロール１８６０は、特別のユーザのためのシップメントジップを編集し又は観察するために使用される。カントリエディットコントロール１８４０は、特別のユーザのためのシップメントカントリを編集し又は観察するために使用される。プロセスの完了１８７０を意味するボタン及びプロセスをキャンセル１８８０するためのボタンがまた、備えられる。
【０１２９】
第１９図は、好適具体例に従うウインドーコントロールを例示している。アクティブウインドーの名前は常に、ユーザによる容易な認識のために上左側コーナー１９３０に表示される。上右側コーナーは、表示を最小化し１９００，表示を最大化し１９１０，そして表示を閉じる１９２０ための３つのボタンを有している。当業者は、過度の試作もなく前述したツールに代えて、他のウインドー表示ツールを用いることができるということを容易に理解するであろう。タッチ表示スクリーンをまた、マウス又はキーボードが適切でないかもしれない環境のために用いることができるであろう。人は、リビングルーム又は安楽いすの快適さから観察し、選択し、購買のために支払うテレビ受像機とインターフェースするリモートコントロール装置（赤外線）を使って操作されるディスプレイさえ想定することができるであろう。
【０１３０】
第２０図は、本発明の好適具体例に従うレジスタ表示である。このレジスタ表示は、発生順に全ての取引のリストを表示し、かつウオーレットと関連した取引をユーザがナビゲートしかつ調査するのを可能にする。ユーザはまた、特別の取引のサーチ及びいずれかの取引の詳細な取引情報の調査のオプションを有している。最後に、ユーザは、商品のシップメントリストと共に、バンクステートメントに対して取引を承諾させることができる。このディスプレイは、管理スクリーンからレジスタボタンを選択することにより開始される。ユーザは、レジスタ表示の単一の例のみを作成することができ、そのため、マウスボタンの追加のクリックは、単一レジスタ表示ウインドーにフォーカスを設定するためにのみ利用される。レジスタ表示上のアイテムをクリックすると、カーソルが現在表示されているエリアと関連したヒットレコードに選択ハイライトを設定する。ダブルクリックすると、現在選択されたレコード上の追加の詳細をもたらす。
【０１３１】
もしユーザがタブキーを押すならば、カーソルは表示上の次のコントロールに移動し、かつそれをハイライトする。もしユーザがエントリキーを押すならば、ハイライトされたボタンは、レジスタ表示上に呼び出される。取引レコードがハイライトされるとき、上矢印キーを押すと、ハイライト（選択されたアイテム）は先行するレコードに移動する。取引レコードがハイライトされるとき、下矢印を押すと、ハイライト（選択されたエリア）は次のレコードに移動する。ホームキーを選択すると、ハイライトをレジスタレポート内の第一のレコードにセットし、そして同様に、終了キーを押すと、ハイライトをレジスタレポート内の最後のレコードをセットする。レジスタ表示上の詳細ボタン２０１０を選択すると、レジスタ詳細ダイアログが開かれる。ファインドボタン２０２０を選択すると、レジスタファインドダイアログが開かれる。カストマイズボタン２０３０を選択すると、レジスタカストマイズダイアログが開かれる。いったんユーザが特別のレジスタをカストマイズすると、カストマイズボタン２０３０は、アクティブフィルタが定義されるということを支持するためにカラードットシンボルを表示する。もしデリートボタン２０４０が選択されるならば、そのときハイライトしたレジスタは、適切な確認メッセージボックスが表示され、かつ肯定的に選択された後削除される。さらに、出力ボタン２０５０を選択すると、ユーザとの出力ダイアログが開かれる。最後に、クローズボタン２０６０を選択すると、レジスタスクリーンが閉じる。スクロールバー２０９０がまた、単一ページを越えて延びるレコードをユーザにスクロールさせるために備えられている。各レコードに対して、日付２０８０，時間２０８２，支払い装置２０８４，アイテム２０８６，額２０８８，支払い２０７０及び受け取り２０７２エントリが、列表示で提供される。支払い２０７０及び受け取り２０７２は、クレディットカード支払いをするときレコードをユーザにチェック／承諾させる。
【０１３２】
第２１図は、好適具体例に従うレジスタ詳細表示である。レジスタ詳細表示は、取引の特別の全ての詳細をユーザに観察させ、或いは調べることを可能にする。この表示は、ユーザがハイライトされた取引レコードをダブルクリックするとき、或いはユーザがレジスタ表示の第２０図に例示されたような詳細２０３０ボタンを押すとき起動される。オーダータブ２１００コントロールは、表示上の情報ページを選択する。ゴーツー商人サイトボタン２１１０ボタンは、インターネットブラウザを起動し、かつそれを商人ウエブページにセットする。シップツーアドレス２１２０は、選択された商人のためのアドレス情報にリンクを提供する。メモ２１５０エディットコントロールは、各取引に対して短いメモテキストを観察／エディットするために使用される。支払い２１７０チェックボックスは、彼又は彼女がクレディットカード支払いをするときレコードをユーザにチェック／確認させる。受け取り２１６０チェックボックスは、彼／彼女が商品を受け取るときレコードをユーザにチェック／確認させる。完了２１４０は、レジスタ詳細ダイアログを閉じ、かつそのフォ一カスをレジスタに戻す。
【０１３３】
レジスタファインド
第２２図は、好適具体例に従うレジスタファインド表示である。ユーザは、取引レコードのサーチのためにこの表示を利用する。第２０図を参照して説明したようなレジスタ表示のファインドボタン２０２０は、この表示を開始するために使用される。起算日２２００コントロールは、取引の開始日を入力するために使用される。終了日２２１０コントロールは、取引の終了日を入力するために使用される。コンボボックス２２２０は、ウオーレット内の全ての支払い方法をリストするために使用される。プルダウン２２２５コントロールは、ユーザに表示されるべき支払方法のリストを生じる。アイテム２２３０コントロールは、サーチのターゲットアイテムの全て又は一部を入力するために使用される。商人コンボ２２４０表示は、ウオーレット内の商人名の全てをリストする。アイテム２２５０コントロールは、必要とされる特別の商人名の選択のために表示されるべき商人名の全てのリストを生じる。メモ２２６５エディットコントロールは、サーチすべきメモの全部又は一部を入力するために使用される。キャンセル２２９５ボタンは、レジスタファインドダイアログをキャンセルし、そして閉じる。ファインド２２９５ボタンはサーチコマンドをスタートする。ファインドダイアログは、サーチの間開いたままであり、かつこのレジスタのサーチ結果は、ハイライトされる。サーチアップ２２６０ボタン及びダウン２２７０ボタンは、ファインドオペレーションの方向を決める。ファインドネクスト２２８０ボタンは、次のレジスタレコードを位置決めするためにサーチを継続する。
【０１３４】
第２３図は、好適具体例に従うレジスタカストマイズ表示である。この表示は、ユーザに取引レコードのためのレコードフィルタを作成させるダイアログを容易にする。それは、フィルタを保存し、呼び出し、かつ削除する機能を提供する。保存されたフィルタは、好適具体例に従い、支払いウインドーのレジスタ及びレポート機能の間で共有される。この表示を開始するために、ユーザは、レジスタスクリーンのカストマイズボタン２０３０を選択する。起算日２３４０エントリフィールドは、この日以後のレコードを示すための開始日をユーザに入力させる。終了日２３５０エントリフィールドは、この日を含むこの日までのレコードを示すための終了日をユーザに入力させる。アイテム２３６０エントリフィールドは、フィルタパラメータとしてアイテムフィールドの全て又は一部をユーザに入力させる。受け取り２３６５ボタンは、フィルタパラメータとして受け取りフラグをユーザに選択させる。支払い２３７０ボタンは、フィルタパラメータとして支払いフラグをユーザに選択させる。メモフィールド２３８０は、フィルタパラメータとしてメモフィールドの全て又は一部をユーザに入力させる。ユーザは、入金２３９５ボックスを利用するフィルタパラメータとして一以上の支払い方法を選択することができる。このマルチ選択リストボックスは、ユーザが選択すべきウオーレット内の全ての支払い方法を表示する。商人ボックス２３９７は、フィルタパラメータとして一以上の商人をユーザに選択させる。このマルチ選択リストボックスは、ユーザが選択すべき取引レジスタ内の商人名の全てを表示する。フィルタ２３１０は、コンボボックスを使い、かつ記憶されたフィルタ名を選択し又は入力することにより、ユーザがフィルタに名前を付け、記憶し、かつ読み出すのを可能にする。メモ２３２０ボタンは、表示上に特定されたパラメータにフィルタ２３１０ボックス内に現れる名前を割り当てる。削除２３３０ボタンは、コンボボックスを使ってユーザにフィルタを選択させ、そしてそれを削除する。クリア２３８５ボタンは、フィルタパラメータの全てをユーザにクリアさせる。ＯＫボタンは、フィルタを作動させ、そしてカストマイズダイアログを閉じる。レジスタのカストマイズボタンは、アクティブフィルタを指示するドットを表示する。
【０１３５】
第２４図は、レジスタ情報のための出力ターゲットを指向するためのレジスタ出力表示である。例えば、ユーザは、レジスタ表示の結果を出力するためのターゲットとしてプリンタ又はファイルを選択することができる。出力表示は、レジスタ表示の出力ボタンを押すことによって起動される。ユーザは、プリンタへのレジスタ表示情報の出力を開始するためにプリンタボタン２４００をクリックする。ユーザは、タイプ２４２０コンボボックスから選択されたファイルフォーマットのファイルにレジスタ情報を出力するためにイクスポートボタン２４１０を選択する。ユーザは、テキストエントリフィールド２４３０における出力ファイルのためのパス／ネームを特定する。ユーザは、ブラウザ２４３５ボタンを選択しかつ出力ファイルパス及びファイルネームを設定することによりファイル保存ダイアログをオープンすることができる。キャンセル２４５０ボタンは、このオペレーションをキャンセルし、かつダイアログ表示を閉じる。ＯＫ２４６０ボタンは、ダイアログを閉じ、かつレジスタスクリーンの出力を開始する。
【０１３６】
レポート
第２５図は、好適具体例に従うウオーレットのレポートである。この表示は、レポートをカストマイズする際に使用するための予めフォーマットされたレポートである。ユーザは、支払いウインドー表示のボタンを押すことによりレポートを起動する。カストマイズボタン２５００は、レジスタカストマイズダイアログを開く。もしカラードットがカストマイズボタン２５００内に現れるならば、そのときフィルタは目下アクティブである。出力ボタン２５１０は、出力ダイアログを開く。完了２５２０ボタンは、レポートウインドーを閉じる。レポートタイプリストボックス２５３０は、レポートタイプコンボボックスを使うことにより予めフォーマットされたレポートタイプをユーザに選択させる。ユーザはまた、レポートソートフィールドを設定するためにフィールド２５４０，２５５０，２５６０，２５７０，２５８０、又は２５９０のいずれかを選択することができる。この選択されたソートフィールドは、ソートフィールド内に太字として現れる。
【０１３７】
レポートカストマイズ
第２６図は、好適具体例に従うレポートカストマイズ表示を例示している。このスクリーンは、取引レコードのためのレコードフィルタをユーザに作成させる。それは、フィルタを保存し、読み出し、そして削除する機能を提供する。保存されたフィルタは、支払いウインドーのレジスタとレポート機能の間で共有される。この表示を開始するために、ユーザは、レポートスクリーンのカストマイズボタンを選択する。起算日２６９２エントリフィールドは、この日以後のレコードを示すための開始日をユーザに入力させる。終了日２６９４エントリフィールドは、この日を含むこの日までのレコードを示すための終了日をユーザに入力させる。アイテム２６９０エントリフィールドは、フィルタパラメータとしてアイテムフィールドの全て又は一部をユーザに入力させる。受け取り２６８４ボタンは、フィルタパラメータとして受け取りフラグをユーザに選択させる。支払い２６８２ボタンは、フィルタパラメータとして支払いフラグをユーザに選択させる。メモフィールド２６８０は、フィルタパラメータとしてメモフィールドの全て又は一部をユーザに入力させる。ユーザは、入金２６３０ボックスを利用するフィルタパラメータとして一以上の支払い方法を選択することができる。このマルチ選択リストボックスは、ユーザが選択するためのウオーレット内の全ての支払い方法を表示する。商人ボックス２６４０は、フィルタパラメータとして一以上の商人をユーザに選択させる。このマルチ選択リストボックスは、ユーザが選択するためのレポート内の全ての商人名を表示する。フィルタ２６００は、コンボボックスを使い、かつ記憶されたフィルタネームを選択し又は入力することによりユーザがフィルタの名前を付け、記憶し、かつ読み出すのを可能にする。メモ２６１０ボタンは、表示上に特定されたパラメータにフィルタ２６１０ボックス内に現れる名前を割り当てる。削除２６２０ボタンは、コンボボックスを使ってユーザにフィルタを選択させかつそれを削除する。レポートヘッダ２６６０エントリフィールドは、レポートのタイトルとして表示するための情報をユーザに入力させる。クリア２６７０ボタンは、フィルタパラメータの全てをユーザにクリアさせる。ＯＫ２６５０ボタンは、フィルタを作動させ、かつこのカストマイズダイアログを閉じる。レポートのカストマイズボタンは、アクティブフィルタを指示するドットを表示する。
【０１３８】
レポート出力
第２７図は、好適具体例に従うレポート出力表示である。ユーザは、このダイアログを利用する出力ターゲットを選択することができる。この表示は、レポート表示の出力ボタン２５１０を選択することにより起動される。ユーザは、このダイアログを使って選択のターゲットを選択することができる。ユーザは、もしレポートからの出力がプリンタにターゲットされるならば、プリンタ２７１０チェックボックスを選択する。この作用は、イクスポートボタンの下で全てのコントロールを不能にする。ユーザは、イクスポートファイルにレポートを出力するためにイクスポートボタン２７２０を選択する。この作用は、全てのイクスポートボタンコントロールを可能にする。ユーザは、プルダウンメニュー２７３０を利用するイクスポートオペレーションのためのファイルフォーマットを選択する。ユーザは、パスデータエントリフィールド２７４０を使って出力ファイルのためのパス／ファイルネームを選択する。ブラウズボタン２７５０は、ファイルパス又はファイルネームをブラウズしかつセットするためにファイル保存ダイアログをユーザに開かせる。キャンセルボタン２７７０は、このオペレーションをキャンセルし、かつダイアログを閉じる。ＯＫボタン２７６０は、このダイアログを閉じ、かつ出力プロセスを開始する。
【０１３９】
前述したレジスタ及びレポート機能のための別の具体例において、クイッケンのような別個の会計上のアプリケーションプログラムは、インターネットプログラムによってヘルパーアプリケーションとして利用することができるであろう。この特徴は、クイッケンアプリケーションとセットになった他の会計取引についてレポートするサンプルを可能にする追加の利点を有するであろう。別の具体例は、圧縮するものとしてイメージファイルを記憶しかつ読み出すためにＪＰＥＧフォーマット又はＧＩＦフォーマット化ファイルを利用することができるであろう。これらの標準は、この技術分野において十分公知であり、そして、グラフィックファイル及びビットマップイメージを保存するために必要な記憶量を減らすために効果的であることがわかった。
【０１４０】
支払い装置ホルダー
第２８図は、好適具体例に従う種々の支払い装置ホルダーを例示している。マネークリップが、２８００及び２８０２に示されている。種々のウオーレットが、２８１０，２８１４，２８３０及び２８５０で閉じた位置に、かつ２８１２，２８１６，２８４０及び２８６０で開いた位置に示されている。閉じた位置における財布は、２８２０で、かつ開いた位置において２８２２で描かれている。最後に、スマートカードが２８７０で閉じた位置で、かつ２８８０で開いた位置で示されている。当業者は、この描画が、ＪＰＥＧ、ＧＩＦ又は他のスペースを保存する表示として記憶することができるビットマップイメージの表示であるということを認識するであろう。
【０１４１】
証明書プロセス
支払い装置は、それがコンピュータネットワーク上で使用することができる前に証明書発行権限者によって証明されなければならない。クレディットカード支払いの場合に、発行者は、カード発行銀行の一つでなければならないが、しかし、それはまた、商人（例えばＳＥＡＲＳ）、取引取得銀行又はＶＩＳＡ又はマスターカードのような団体であるかもしれない。
【０１４２】
支払い装置情報は、消費者のウオーレットに記憶される。支払い装置を認証する証明書は、安全なデータベースにおけるそのデータと共に記憶されるであろう。証明書を取得するプロセスは、後述の通りである。証明書は、予め構成されたウオーレット内で消費者に引き渡すことができる。消費者は、証明書発行権限者又はこの発行権限者の代理人によって認可される支払い装置ビットマップを含む支払い装置と関連した必要な詳細と共にこの証明書を包含するウオーレットを受け取る。
【０１４３】
証明書の取得
消費者は、証明書発行権限者に情報を与え、或いは与えさせるであろう。第２９図は、好適具体例に従う証明書発行フォームの例示である。ユーザは、オンラインで、ペーパー上にこのフォームを満たし、そしてそれをメールし、或いは彼の銀行又はクレディットカード会社にそれを与えさせることができる。消費者供給のデータは通常、消費者ソフトウエアにより発生したセキュリティキー対に属するパブリックキーを包含するであろう。この情報は通常、消費者のアドレスにメールされ、かつ消費者からの電話コールによって作動するであろう。証明書権限者は、この情報をとり、かつそれを使用して、彼が実際支払い方法を使用する権利があるということを確認する。このプロセスは通常、達成するために数日かかる。情報は通常、もし一つあるならば、物理スペースにおける組織発行支払い方法と、かつクレディットエージェンシーと交換されるであろう。証明書情報は、消費者のソフトウエア内にロードされて、オンラインで進める支払い処理を可能にする。
【０１４４】
ある場合に、消費者は、彼が所有することを望む支払い装置ホルダー（ウオーレット）についての詳細を選択することができるであろう。これは、ホルダーを表すアイコン、アクセスパスワード、又は他の情報であるかもしれない。この証明書を作成した後、発行権限者は、使用する用意のあるカスタム支払い装置ホルダーを作成するために証明書アプリケーションにおいて受け取った情報を使用することができる。この支払い装置ホルダーは、次の情報を含むであろう。カードナンバー２９００及び終了日２９０２を含む支払い装置情報。ネーム２９０４，アドレス２９０６，社会保障番号２９０８，及び誕生日２９１０を含む個人情報。
【０１４５】
関連した証明書（例えばＸ５０９標準）、関連したパブリックキー、又はある場合にパブリック／プライベートキー対（例えばＲＳＡ）、及び支払い装置を表す認可ビットマップは、要求する消費者に提供される。第３０図は、好適具体例に従う証明書発行応答を例示している。ＶＩＳＡカードのための認可ビットマップは、３０００で示されている。また、デフォルト支払いホルダー３０１０及びデフォルト支払いホルダーネームが、証明書発行によって提供される。消費者が支払い装置ホルダー３０１０を取得した後、支払い装置ホルダーは、支払い装置ホルダーの彼の集合において彼は直接視ることができる。第３１図は、好適具体例に従う支払い装置ホルダーの集合を例示している。予め限定された支払い装置ホルダー３１００は、証明書発行フォームによりデフォルトに基づいて予め限定されたジョンのウオーレットと同じである。第３２図は消費者がＶＩＳＡカードに満たしかつ認可を得ることから生じる予め定められた支払い装置ホルダー３２１０と関連したデフォルト支払い装置ビットマップ３２００を例示している。
【０１４６】
第３３図は、好適具体例に従うカードホルダーのためのブランクに記入した選択支払い装置を例示している。支払い装置ホルダーが支払い状況において開かれる次の時に、証明書発行権限者認可装置ビットマップは、支払い装置を選択するために使用し、かつ購買をするためにそれを利用することができる。第３４図は、本発明の好適具体例に従い新たに限定されたＶＩＳＡカードを利用するコーヒー購買を例示している。
【図面の簡単な説明】
【０１４７】
【図１Ａ】好ましい実施形態による、ハードウェア環境を示すブロックダイアグラムである。
【図１Ｂ】好ましい実施態様による、システムのブロックダイアグラムである。
【図２】発明をＪＡＶＡベースで実施する場合に行うべき他の好ましい実施態様を示す。
【図３】本発明の好ましい実施態様による、アーキテクチャーブロックダイアグラムである。
【図４】好ましい実施態様による、支払いマネジャーに関する詳細なロジックを示す。
【図５】発明の好ましい実施態様で、消費者支払いメッセージシーケンスダイアグラムである。
【図６】発明の好ましい実施態様による、支払いウィンドウユーザインターフェースの詳細なロジックを述べているフローチャートである。
【図７】好ましい実施態様による、支払いウィンドウアドミニストレーションモードに関する詳細なロジックのフローチャートである。
【図８】好ましい実施態様による、レジスターで処理を行うアドミニストレーションモードとレポート処理のフローチャートである。
【図９】好ましい実施態様による、支払いウィンドウディスプレイの図である。
【図１０】好ましい実施態様による、ユーザが選択することのできる支払方法のリストの図である。
【図１１】好ましい実施態様による、認可を与えるディスプレイ画面である。
【図１２】好ましい実施態様による、支払い済み（ＰＡＩＤ）のオーサライズを与えるディスプレイである。
【図１３】好ましい実施態様による、認可の取り消しディスプレイ画面である。
【図１４】発明の好ましい実施態様による、主画面を示す。
【図１５】好ましい実施態様による、アドミニストレーションディスプレイ画面の図である。
【図１６】好ましい実施態様による、札入れアドミニストレーションページのディスプレイを示す。
【図１７】好ましい実施態様による、支払いアドミニストレーションウィンドウである。
【図１８】好ましい実施態様による、アドミニストレーションプリファレンスページの図である。
【図１９】好ましい実施態様による、ウィンドウコントロールを示す。
【図２０】発明の好ましい実施態様による、レジスターディスプレイである。
【図２１】好ましい実施態様による、レジスターディテイルディスプレイである。
【図２２】好ましい実施態様による、レジスターファインドディスプレイである。
【図２３】好ましい実施態様による、レジスターカスタマイズディスプレイである。
【図２４】レジスター情報の出力対象を示すレジスター出力ディスプレイである。
【図２５】好ましい実施態様による、札入れのレポートである。
【図２６】好ましい実施態様による、レポートカスタマイズディスプレイを示す。
【図２７】好ましい実施態様による、レポート出力ディスプレイである。
【図２８】好ましい実施態様による、支払い手段の「開」「閉」アイコンを示している一組のイメージを示す。
【図２９】好ましい実施態様による、認証発行形式の図である。
【図３０】好ましい実施態様による、認証発行応答を示す。
【図３１】好ましい実施態様による、支払い手段ホルダーの一つの集合を示す。
【図３２】好ましい実施態様による、ディフォールト支払い手段ビットマップを示す。
【図３３】好ましい実施態様による、カードホルダーのブランクを埋めた選択された支払い手段を示す。そして、
【図３４】発明の好ましい実施態様による、新しく定義したＶＩＳＡカードを用いてコーヒを購入することを示している。
【図１Ａ】
2008186474.tif 000011
【図１Ｂ】
2008186474.tif 000012
【図２】
2008186474.tif 000013
【図３】
2008186474.tif 000014
【図４】
2008186474.tif 000015
【図５】
2008186474.tif 000016
【図６】
2008186474.tif 000017
【図７】
2008186474.tif 000018
【図８】
2008186474.tif 000019
【図９】
2008186474.tif 000020
【図１０】
2008186474.tif 000021
【図１１】
2008186474.tif 000022
【図１２】
2008186474.tif 000023
【図１３】
2008186474.tif 000024
【図１４】
2008186474.tif 000025
【図１５】
2008186474.tif 000026
【図１６】
2008186474.tif 000027
【図１７】
2008186474.tif 000028
【図１８】
2008186474.tif 000029
【図１９】
2008186474.tif 000030
【図２０】
2008186474.tif 000031
【図２１】
2008186474.tif 000032
【図２２】
2008186474.tif 000033
【図２３】
2008186474.tif 000034
【図２４】
2008186474.tif 000035
【図２５】
2008186474.tif 000036
【図２６】
2008186474.tif 000037
【図２７】
2008186474.tif 000038
【図２８】
2008186474.tif 000039
【図２９】
2008186474.tif 000040
【図３０】
2008186474.tif 000041
【図３１】
2008186474.tif 000042
【図３２】
2008186474.tif 000043
【図３３】
2008186474.tif 000044
【図３４】
2008186474.tif 000045