JP2000512405A - 認可装置を使って電子ネットワーク認可をするシステム、方法及びそれを行う機器 - Google Patents

Abstract

(57)【要約】 電子マネーシステムは、金、クレディットカード、及び他の組織された支払い形態を管理するために通例使用されるウオーレット又は財布をエミュレートする電子マネーシステムを利用する取引のために備えられる。ウオーレット又は財布内の手段へのアクセスは、認可されない支払いを避けるためにパスワードによって制限されている。アクセスが認可されるとき、支払い装置のグラフィック表示は、ユーザに支払方法を選択させるためにディスプレイ上に提示される。いったん支払い装置が選択されると、購買商品のサマリーがユーザに提示され、かつユーザは、取引の電子承認を入力し、或いはその取引をキャンセルする。電子承認すると、この注文を完了する電子取引が発生する。

Description

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

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ， ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，Ｌ Ｕ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ， ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＫＥ，ＬＳ，ＭＷ，Ｓ Ｄ，ＳＺ，ＵＧ)，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ ，ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＬ，ＡＭ，ＡＴ，ＡＵ ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ， ＣＮ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，Ｇ Ｂ，ＧＥ，ＧＨ，ＨＵ，ＩＬ，ＩＳ，ＪＰ，ＫＥ，ＫＧ ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ， ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，Ｎ Ｏ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ ，ＳＩ，ＳＫ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＵＡ，ＵＧ， ＵＳ，ＵＺ，ＶＮ，ＹＵ (72)発明者 パーマ，ビピンカマ、ジー アメリカ合衆国キャリフォーニア州95014、 カパーティノ、オーリンジ・トリー・レイ ン 10554番

Claims (1)

1. 【特許請求の範囲】 １．ネットワーク情報（１１０，４３０）を受信しかつ送信するためのネットワ ークに接続された付属ディスプレイを持つコンピュータ（１３８，４００）にお いて認可を開始するための方法において、 （a）少なくとも１つの手段（１７２０，１７３０）に該手段（１７２０）の ビットマップイメージ（３２００）として表示するステップと、 （b）１つの手段（３２００，１７２０）を選択するステップと、 （c）処理のために前記手段（３２００，１７２０）と関連した情報（１７０ ０−１７９２）を利用するステップと、 から成る前記認可を開始するための方法。 ２．この手段が、発行者選択に従い代表される請求項１に記載の方法。 ３．前記手段との取引を完了するために提案された取引及び協定のサマリーを提 示する認可ディスプレイを提供するステップを含む請求項１に記載の方法。 ４．別の手段に変更し、取引を完了するための情報を得、或いはこの手段と関連 した情報を調査するのを容易にするリンクを含む請求項３に記載の方法。 ５．受け取った認可を表す証印を表示するステップを含む請求項３に記載の方法 。 ６．ディスプレイ上で商人、発行者、広告者又は代理店にリンクを埋め込むステ ップを含む請求項１に記載の方法。 ７．プロバイダーのプラクティスに基づいた選択のために可能にされる手段を変 更する請求項１に記載の方法。 ８．一つの手段がディスプレイ上で使用された各取引のリストを表示するステッ プを含む請求項１に記載の方法。 ９．ディスプレイ上で認可された手段に基づいたオプションのメニューを表示す るステップを含む請求項１に記載の方法。 １０．選択された手段に基づいた処理を変更するステップを含む請求項１に記載 の方法。 １１．ネットワーク情報（１３４−１３５）を受信しかつ送信するためのネット ワークに接続された入力装置（１２４）及び付属ディスプレイ（１３６−１３８ ）を持ち、ソフトウエア（１８０−１８６，３００−３８０，４００−４８０） の制御の下で、コンピュータ（１００−１３８）において、認可を開始するため の装置において、 （a）少なくとも１つの手段にディスプレイ上でこの手段（７００−７９６， １０３０，１０４０及び１０２０）のビットマップイメージとして表示するソフ トウエアの制御の下にあるコンピュータと、 （b）１つの手段（１０３０）を選択するソフトウエア（７００−７９６）の 制御の下にあるコンピュータ（１１０）の制御の下にある入力装置（１２４）と 、 （c）認可処理のために選択された手段と関連した情報を利用するソフトウエ アの制御の下にあるコンピュータと、 から成る前記認可を開始するための装置。 １２．前記手段が、発行者選択に従い代表される請求項１１に記載の装置。 １３．ソフトウエアの制御の下にある前記コンピュータが、認可されるプロセス と関連した追加の機能を提供する他のディスプレイにリンクを提供する請求項１ １に記載の装置。 １４．ソフトウエアの制御の下にある前記コンピュータが、前記手段との取引を 完了するために提案された取引及び協定のサマリーを提示する請求項１１に記載 の装置。 １５．別の手段に変更し、取引を完了するための情報を得、或いは、この手段と 関連した情報を調査することを容易にするリンクを含む請求項１１に記載の装置 。 １６．ソフトウエアの制御の下にある前記コンピュータが、ディスプレイ上で１ つの手段を証明するための認可コードの入力を促す請求項１４に記載の装置。 １７．ソフトウエアの制御の下にある前記コンピュータが、ディスプレイ上で受 け取った認可を表す証印を表示する請求項１４に記載の装置。 １８．ソフトウエアの制御の下にある前記コンピュータが、ディスプレイ上で承 認、発行者、広告者、又は代理店へのリンクを埋め込む請求項１１に記載の装置 。 １９．ソフトウエアの制御の下にある前記コンピュータは、ディスプレイ上の認 可レベルを超える手段を表す証印を表示する請求項１１に記載の装置。 ２０．ソフトウエアの制御の下にある前記コンピュータは、ディスプレイ上の各 商人のためのデフォルト手段を限定する請求項１１に記載の装置。 ２１．ソフトウエアの制御の下にある前記コンピュータは、一つの手段が使用さ れた各取引のリストを表示する請求項１１に記載の装置。 ２２．該手段は、ディスプレイ上で発行者選択に従い代表される請求項１１に記 載の装置。 ２３．支払い処理が、選択された手段に基づいている請求項１１に記載の方法。