(57)【要約】【解決手段】１つの観点では、本発明は通信ネットワークを通して複数のクライアント装置に広告を配信する広告配信システムを提供し、このシステムには少なくとも１つの広告サーバが含まれ、この広告サーバはクライアント装置に配信される広告を記憶し、各広告はソースアドレスにより指定される記憶位置に記憶され、このシステムには少なくとも１つのプレーリストサーバが含まれ、このプレーリストサーバは各クライアント装置に対して少なくとも１つのプレーリストを提供する。各クライアント装置に提供される少なくとも１つのプレーリストはクライアント装置によりダウンロードされる広告を識別することが好ましい。
2005513583.tif 000002
【特許請求の範囲】
【請求項１】
通信ネットワークを通して情報サーバシステムと情報を交換して広告を記憶するクライアント装置に対してプレーリスト応答を供給する特殊プレーリストサーバに汎用コンピュータを変えるソフトウェアにおいて、
クライアント装置により提示されるべき複数の選択された広告を識別するプレーリスト応答を発生させるプレーリスト応答発生機能と、
プレーリスト応答がクライアント装置に送信される通信ネットワークを通してのクライアント装置とのプレーリスト応答送信通信リンクをもたらす第１の通信機能とを具備し、
情報サーバシステムとプレーリストサーバが独立に制御されるソフトウェア。
【請求項２】
通信ネットワークを通してのクライアント装置とのプレーリスト要求受信機能をもたらす第２の通信機能をさらに具備し、
プレーリスト応答発生機能は、プレーリスト要求の受信に応答してクライアント装置により提示されるべき複数の選択された広告を識別するプレーリスト応答中に含まれるプレーリストを発生させるプレーリスト発生機能をさらに含む請求項１記載のソフトウェア。
【請求項３】
プレーリストサーバにより発生されたプレーリスト応答は更新されたプレーリストを含み、
クライアント装置により現在使用されているプレーリストは現在のプレーリストを含み、
クライアント装置が第１のプレーリストを受信したときに、現在のプレーリストは更新されたプレーリストにより置換される請求項１記載のソフトウェア。
【請求項４】
プレーリスト応答は、クライアント装置に命令して、現在のプレーリストを更新されたプレーリストで置換させる命令を含む請求項３記載のソフトウェア。
【請求項５】
プレーリストサーバにより発生されたプレーリスト応答は更新されたプレーリストを含み、
クライアント装置により現在使用されているプレーリストは現在のプレーリストを含み、
クライアント装置が第１のプレーリストを受信したときに、現在のプレーリストを更新されたプレーリストに連結させる請求項１記載のソフトウェア。
【請求項６】
プレーリスト応答は、クライアント装置に命令して、現在のプレーリストと更新されたプレーリストとを連結させる命令を含む請求項５記載のソフトウェア。
【請求項７】
プレーリスト応答はクライアント情報と更新されたプレーリストとを含む請求項１記載のソフトウェア。
【請求項８】
クライアント情報はクライアント装置による広告の提示を制御する請求項７記載のソフトウェア。
【請求項９】
クライアント情報はクライアント装置により提示される広告のターンオーバーレートを制御する請求項７記載のソフトウェア。
【請求項１０】
クライアント情報はクライアント装置がプレーリスト要求を発生させる周期を指定し、
プレーリスト応答発生機能はプレーリスト要求に応答してプレーリストを発生させる請求項７記載のソフトウェア。
【請求項１１】
クライアント情報は複数の広告の中で競合する広告間の最小時間分離を含む請求項７記載のソフトウェア。
【請求項１２】
クライアント情報はクライアント装置が各広告を提示する方法を命令する仕様を含む請求項７記載のソフトウェア。
【請求項１３】
広告が現在の広告と満了広告を含み、クライアント情報はクライアント装置が満了広告を提示する前にクライアント装置が現在の広告を提示する最小時間期間を含む請求項７記載のソフトウェア。
【請求項１４】
広告が現在の広告と満了広告を含み、クライアント情報はクライアント装置が満了広告を提示できる最大時間期間を含む請求項７記載のソフトウェア。
【請求項１５】
クライアント装置は、クライアント情報中に含まれている選択されたパラメータに応答して、広告を提示する持続性のある提示モードと短命の提示モードとを切り換える請求項７記載のソフトウェア。
【請求項１６】
プレーリストはプレーリストサーバとクライアント装置の両方においてチェックサムがとられ、それにより各チェックサムが発生され、各チェックサムが同一でないときに、クライアント装置により受信されたプレーリストは無視される請求項１記載のソフトウェア。
【請求項１７】
選択された広告はそれぞれ少なくとも１つの画像を含む請求項１記載のソフトウェア。
【請求項１８】
選択された広告はそれぞれオーディオデータを含む請求項１記載のソフトウェア。
【請求項１９】
通信ネットワークを通して情報サーバシステムと情報を交換し、広告サーバから広告を受信するクライアント装置に対してプレーリスト応答を供給する特殊プレーリストサーバに汎用コンピュータを変えるソフトウェアにおいて、
クライアント装置により提示されるべき複数の選択された広告を識別するプレーリスト応答を発生させるプレーリスト応答発生機能と、
プレーリスト応答がクライアント装置に送信される通信ネットワークを通してのクライアント装置とのプレーリスト応答送信通信リンクをもたらす第１の通信機能とを具備し、
情報サーバシステムとプレーリストサーバが独立に制御されるソフトウェア。
【請求項２０】
通信ネットワークを通してのクライアント装置とのプレーリスト要求受信機能をもたらす第２の通信機能をさらに具備し、
プレーリスト応答発生機能は、プレーリスト要求の受信に応答してクライアント装置により提示されるべき複数の選択された広告を識別するプレーリスト応答中に含まれるプレーリストを発生させるプレーリスト発生機能をさらに含む請求項１９記載のソフトウェア。
【請求項２１】
プレーリスト要求から選択された情報を抽出するプレーリスト要求パース機能と、
選択された情報をプレーリスト発生機能に供給してプレーリスト発生機能を開始させる選択された情報供給機能とをさらに具備する請求項２０記載のソフトウェア。
【請求項２２】
選択された情報は、クライアント装置をハードウェアクライアント装置とソフトウェアクライアント装置の１つとして識別する請求項２１記載のソフトウェア。
【請求項２３】
プレーリストサーバは、現在のプレーリストが有効であり、更新させる必要がない表示をクライアント装置に送信することにより、または更新されたプレーリストを含むプレーリスト応答をクライアント装置に送信することにより、プレーリスト要求に応答する請求項２１記載のソフトウェア。
【請求項２４】
選択された情報は、ユーザ人口統計とユーザ／クライアント装置の動作の少なくとも１つを含む請求項２１記載のソフトウェア。
【請求項２５】
プレーリスト応答は、ユーザ人口統計および／またはユーザ／クライアント装置の動作の１つに少なくとも部分的に基づいてプレーリストサーバにより発生される更新されたプレーリストを含む請求項２４記載のソフトウェア。
【請求項２６】
選択された情報は、クライアント装置と関係する現在のプレーリストの識別子を含む請求項２１記載のソフトウェア。
【請求項２７】
選択された情報は、クライアント装置による選択された広告の各グループの提示を制御する現在のプレーリストを識別するユーザデータフィールド中に記憶される情報を含み、
プレーリスト応答は、現在のプレーリストに基づいてプレーリストサーバにより発生された更新されたプレーリストを含む請求項２１記載のソフトウェア。
【請求項２８】
選択された情報は、ユーザデータフィールドに記憶された情報を含み、
プレーリスト応答は、ユーザデータフィールド中に含まれる情報に少なくとも部分的に基づいてプレーリストサーバにより発生される更新されたプレーリストを含む請求項２１記載のソフトウェア。
【請求項２９】
ユーザデータフィールドは、クライアント装置の利用ヒストリーを示す情報を含む請求項２８記載のソフトウェア。
【請求項３０】
ユーザデータフィールドは、クライアント装置上で動作する各ソフトウェアを識別するユーザデータフィールドを含む請求項２８記載のソフトウェア。
【請求項３１】
ユーザデータフィールドは、その上でソフトウェアが実行される、クライアント装置のオペレーティングシステムを識別する情報をさらに含む請求項３０記載のソフトウェア。
【請求項３２】
ユーザデータフィールドは、
クライアント装置上で動作する各ソフトウェアを識別する情報を含む第１のデータデータフィールドと、
その上で各ソフトウェアが実行される、クライアント装置のオペレーティングシステムを識別する情報を含む第２のユーザデータフィールドとを含み、
プレーリスト応答は、プレーリスト要求中に含まれる第１および第２のユーザデータフィールド中に含まれる情報に少なくとも部分的に基づいてプレーリストサーバにより発生される請求項２８記載のソフトウェア。
【請求項３３】
選択された情報は、規定された時間間隔にユーザがクライアント装置を使用した時間量に関する利用データを含む請求項２１記載のソフトウェア。
【請求項３４】
プレーリスト応答は、利用データに少なくとも部分的に基づいてプレーリストサーバにより発生される請求項３３記載のソフトウェア。
【請求項３５】
選択された情報は、クライアント装置により提示されたままにされる記憶された広告に対して要求される総表示時間量を指定する表示時間残存データフィールドを含む請求項２１記載のソフトウェア。
【請求項３６】
プレーリスト応答は、表示時間残存データフィールドに少なくとも部分的に基づいてプレーリストサーバにより発生される請求項３５記載のソフトウェア。
【請求項３７】
プレーリスト要求は、規定された時間間隔中にクライアント装置により広告が表示された総時間量を指定する最新使用の表示時間データフィールドを含む請求項２１記載のソフトウェア。
【請求項３８】
規定された時間間隔は本日を含む請求項３７記載のソフトウェア。
【請求項３９】
プレーリスト応答は、最新使用の表示時間データフィールドに少なくとも部分的に基づいてプレーリストサーバにより発生される請求項３７記載のソフトウェア。
【請求項４０】
規定された時間間隔は本日を含む請求項３９記載のソフトウェア。
【請求項４１】
選択された情報は、クライアント装置に関係する表示スクリーンの大きさを指定するクライアント装置表示スクリーンデータをさらに含む請求項２１記載のソフトウェア。
【請求項４２】
大きさはピクセルで表示された、表示スクリーンの高さ、幅および奥行を含む請求項４１記載のソフトウェア。
【請求項４３】
選択された情報は、クライアント装置のディストリビュータを識別するディストリビュータＩＤを含む請求項２１記載のソフトウェア。
【請求項４４】
ディストリビュータＩＤは、クライアント装置により提示される広告の少なくとも１つの特性を選択する際に使用される請求項４３記載のソフトウェア。
【請求項４５】
プレーリスト応答は、各ディストリビュータＩＤを有するクライアント装置よってのみ提示することができる広告を識別する更新されたプレーリストを含む請求項４４記載のソフトウェア。
【請求項４６】
選択された情報は、規定された最新時間間隔中にクライアント装置により表示されている広告に対応する広告識別子のリストを含む請求項２１記載のソフトウェア。
【請求項４７】
プレーリスト応答は、プレーリスト要求中で識別される規定された最新時間間隔で表示された広告に少なくとも部分的に基づいてプレーリストサーバにより発生される請求項４６記載のソフトウェア。
【請求項４８】
選択された情報は、
現在のプレーリストを識別する第１のユーザデータフィールドと、
ユーザ人口統計データを識別する第２のユーザデータフィールドと、
ユーザ／クライアント装置の動作データを識別する第３のユーザデータフィールドと、
クライアント装置の利用ヒストリーを識別する第４のユーザデータフィールドと、
クライアント装置上で動作する各ソフトウェアを識別する第５のユーザデータフィールドと、
クライアント装置の各オペレーティングシステムを識別する第６のユーザデータフィールドと、
規定された時間間隔にユーザがクライアント装置を使用した時間量を識別する第７のユーザデータフィールドと、
クライアント装置により提示されたままにされる記憶された広告に対して要求される総表示時間量を識別する第８のユーザデータフィールドと、
規定された時間間隔の間にクライアント装置により広告が提示された総時間量を識別する第９のユーザデータフィールドと、
クライアント装置と関係する表示スクリーンの大きさを識別する第１０のユーザデータフィールドと、
規定された最新の時間間隔で表示されていた広告に対応する広告識別子のリストと、の中の少なくとも２つを含む請求項２１記載のソフトウェア。
【請求項４９】
プレーリストサーバは、クライアント装置に対して、現在のプレーリストが有効であり、更新させる必要がないとの表示を送信するか、またはクライアント装置に対して、更新されたプレーリストを含むプレーリスト応答を送信することにより、プレーリスト要求に応答する請求項４８記載のソフトウェア。
【請求項５０】
プレーリスト応答は、第１ないし第１０のユーザデータフィールドの少なくとも２つに含まれるフィールドデータに応答してプレーリストサーバにより発生される請求項４８記載のソフトウェア。
【請求項５１】
プレーリスト応答は、第１ないし第１０のユーザデータフィールドおよび選択された情報中に含まれる広告識別子のリストの１つに応答してプレーリストサーバにより発生される請求項４８記載のソフトウェア。
【請求項５２】
プレーリスト応答は、各広告の１つに対する広告タイプを識別する更新されたプレーリストを含む請求項２１記載のソフトウェア。
【請求項５３】
広告タイプは、郵便切手広告に対応する請求項５２記載のソフトウェア。
【請求項５４】
広告タイプは、ツールバー広告に対応する請求項５２記載のソフトウェア。
【請求項５５】
広告タイプは、プラカード広告に対応する請求項５２記載のソフトウェア。
【請求項５６】
広告タイプは、広告のそれぞれ１つを提示する際にクライアント装置により使用されるタイミングを示す請求項５２記載のソフトウェア。
【請求項５７】
選択された情報は、クライアント装置のディストリビュータを識別する請求項２１記載のソフトウェア。
【請求項５８】
クライアント装置はソフトウェアクライアント装置を含み、
ディストリビュータは、ソフトウェアクライアント装置を実現する各ソフトウェアを提供し、
プレーリスト応答はディストリビュータの識別子に基づいてプレーリストサーバにより発生される請求項５７記載のソフトウェア。
【請求項５９】
クライアント装置はハードウェアクライアント装置を含み、
ディストリビュータは、ハードウェアクライアント装置をユーザに提供し、
プレーリスト応答はディストリビュータの識別子に基づいてプレーリストサーバにより発生される請求項５７記載のソフトウェア。
【請求項６０】
プレーリスト要求は、イクステンシブルマークアップラングエッジ（ＸＭＬ）プレーリスト要求を含む請求項２１記載のソフトウェア。
【請求項６１】
プレーリスト要求パース機能が文書タイプ定義（ＤＴＤ）を使用する請求項２１記載のソフトウェア。
【請求項６２】
複数のクライアント装置タイプの１つに対応する各ＤＴＤはプレーリストサーバにより記憶される請求項６１記載のソフトウェア。
【請求項６３】
ＤＴＤはプレーリスト要求中に埋め込まれる請求項６１記載のソフトウェア。
【請求項６４】
ＤＴＤは複数のクライアント装置タイプの１つに特定である請求項６３記載のソフトウェア。
【請求項６５】
プレーリスト要求は、イクステンシブルマークアップラングエッジ（ＸＭＬ）プレーリスト要求を含み、
プレーリスト要求は、ＸＭＬプレーリスト要求に関係するＤＴＤを識別する文書タイプ定義（ＤＴＤ）タグを含み、
プレーリストサーバはＤＴＤタグに対応する各ＤＴＤを記憶し、
プレーリスト要求パース機能は、ＤＴＤタグに対応するＤＴＤを使用する請求項２１記載のソフトウェア。
【請求項６６】
プレーリスト要求パース機能は、
プレーリスト要求の適格性を確認するイクステンシブルマークアップラングエッジ（ＸＭＬ）パース機能と、
オブジェクトを発生させるＸＭＬパース機能による確認後にプレーリスト要求を受信するプレーリスト解析機能と、
オブジェクトを受信してオブジェクトから質問を作り、その質問をプレーリストサーバデータベースに加えるデータベースドライバ機能とをさらに含む請求項２１記載のソフトウェア。
【請求項６７】
プレーリスト解析機能は、データベースドライバの出力を受信し、プレーリスト応答を構成する請求項６６記載のソフトウェア。
【請求項６８】
データベースドライバは、
プレーリスト解析機能とデータベースとの間の通信リンクをもたらすデータベース通信機能と、
少なくとも１つのＳＱＬステートメントを含む質問を行う質問機能と、
質問に応答してデータベース出力を検索し、データベース出力をプレーリスト解析機能に提供する検索機能とをさらに含む請求項６６記載のソフトウェア。
【請求項６９】
プレーリスト応答発生機能は、アクションコマンドとプレーリスト応答のうちの１つを発生させる請求項２０記載のソフトウェア。
【請求項７０】
プレーリスト応答は、クライアント情報と更新されたプレーリストのコンビネーションを含む請求項６９記載のソフトウェア。
【請求項７１】
更新されたプレーリストは、広告の選択されたものに対する、ネームと対応するユニフォームリソース識別子（ＵＲＩ）とを含む請求項７０記載のソフトウェア。
【請求項７２】
プレーリスト応答発生機能は、誤り伝えられたプレーリスト要求の受信に応答してアクションコマンドを発生させる請求項６９記載のソフトウェア。
【請求項７３】
アクションコマンドは、クライアント装置に新しいプレーリスト要求を送信させるように命令するエラーコードをさらに含む請求項７２記載のソフトウェア。
【請求項７４】
アクションコマンドは、クライアント装置によりユーザに対して提示可能なエラーメッセージをさらに含む請求項７２記載のソフトウェア。
【請求項７５】
アクションコマンドは、プレーリストサーバを制御するエンティティによりプレーリストサーバに発行されるコマンドに応答してクライアント装置により受信される広告のすべてをクライアント装置に削除させる請求項６９記載のソフトウェア。
【請求項７６】
プレーリスト応答は、クライアント情報と、選択された各広告に対する、ネームと対応するユニフォームリソース識別子（ＵＲＩ）とを含む更新されたプレーリストとを含む請求項２０記載のソフトウェア。
【請求項７７】
ＵＲＩは、広告サーバ上のそれぞれネーム付広告の記憶位置に対応する請求項７６記載のソフトウェア。
【請求項７８】
ＵＲＩはそれぞれネーム付広告に対する他の記憶装置上の位置にクライアント装置を向け直す広告サーバ上の位置を指定する請求項７６記載のソフトウェア。
【請求項７９】
ＵＲＩはそれぞれネーム付広告に対する広告サーバ上に配置された広告記憶位置にクライアント装置を向け直す広告サーバ上の位置を指定する請求項７６記載のソフトウェア。
【請求項８０】
クライアント情報は、クライアント装置による広告の提示を制御する請求項７６記載のソフトウェア。
【請求項８１】
クライアント情報はクライアント装置により提示される広告のターンオーバーレートを制御する請求項７６記載のソフトウェア。
【請求項８２】
クライアント情報はクライアント装置がプレーリスト要求を発生させる周期を指定する請求項７６記載のソフトウェア。
【請求項８３】
クライアント情報は複数の広告の中で競合する広告間の最小時間分離を含む請求項７６記載のソフトウェア。
【請求項８４】
クライアント情報はクライアント装置が各広告を提示する方法を命令する仕様を含む請求項７６記載のソフトウェア。
【請求項８５】
広告が現在の広告と満了広告を含み、
クライアント情報はクライアント装置が満了広告を提示する前にクライアント装置が現在の広告を提示する最小時間期間を含む請求項７６記載のソフトウェア。
【請求項８６】
クライアント情報はクライアント装置が満了広告を提示できる最大時間期間を含む請求項８５記載のソフトウェア。
【請求項８７】
クライアント情報中に含まれている選択されたパラメータに応答して、クライアント装置が、広告を提示する持続性のある提示モードと短命の提示モードとの間を切り換える請求項７６記載のソフトウェア。
【請求項８８】
プレーリストサーバにより発生されたプレーリスト応答は更新されたプレーリストを含み、
クライアント装置により現在使用されているプレーリストは現在のプレーリストを含み、
クライアント装置が第１のプレーリストを受信したときに、現在のプレーリストは更新されたプレーリストにより置換される請求項１９記載のソフトウェア。
【請求項８９】
プレーリスト応答は、クライアント装置に命令して、現在のプレーリストを更新されたプレーリストで置換させる命令を含む請求項８８記載のソフトウェア。
【請求項９０】
プレーリストサーバにより発生されたプレーリスト応答は更新されたプレーリストを含み、
クライアント装置により現在使用されているプレーリストは現在のプレーリストを含み、
クライアント装置が第１のプレーリストを受信したときに、現在のプレーリストを更新されたプレーリストに連結させる請求項１９記載のソフトウェア。
【請求項９１】
プレーリスト応答は、クライアント装置に命令して、現在のプレーリストと更新されたプレーリストとを連結させる命令を含む請求項９０記載のソフトウェア。
【請求項９２】
プレーリスト応答は、少なくとも１つの広告に対する、ネームと対応するユニフォームリソース識別子（ＵＲＩ）とを含む更新されたプレーリストを含む請求項１９記載のソフトウェア。
【請求項９３】
ＵＲＩは、広告サーバ上のそれぞれネーム付広告の記憶位置に対応する請求項９２記載のソフトウェア。
【請求項９４】
ＵＲＩはそれぞれネーム付広告に対する他の記憶装置上の位置にクライアント装置を向け直す広告サーバ上の位置を指定する請求項９２記載のソフトウェア。
【請求項９５】
ＵＲＩは広告サーバ上に配置された広告記憶位置にクライアント装置を向け直す広告サーバ上の位置を指定する請求項９２記載のソフトウェア。
【請求項９６】
プレーリスト応答は、クライアント情報と、広告の選択されたものに対する、ネームと対応するユニフォームリソース識別子（ＵＲＩ）とを含む更新されたプレーリストとを含む請求項１９記載のソフトウェア。
【請求項９７】
広告の選択されたものは、第１および第２の広告を含み、
第１および第２の広告に対する各ＵＲＩは第１および第２の広告が配置されている第１および第２の広告サーバを示している請求項９６記載のソフトウェア。
【請求項９８】
第１の広告サーバとプレーリストサーバは単一のエンティティにより制御される請求項９７記載のソフトウェア。
【請求項９９】
情報サーバシステム第２の広告サーバは単一のエンティティにより制御される請求項９７記載のソフトウェア。
【請求項１００】
プレーリスト応答発生機能はプレーリスト要求の受信に応答してプレーリストを発生させ、
プレーリスト応答は、クライアント情報と、広告の選択されたものに対する、ネームと対応するユニフォームリソース識別子（ＵＲＩ）とを含む更新されたプレーリストとの両方を含む請求項１９記載のソフトウェア。
【請求項１０１】
広告サーバは、第１および第２のエンティティにより制御される第１および第２の広告サーバを含み、
広告の選択されたものは、第１および第２の広告サーバ間に配信される請求項１００記載のソフトウェア。
【請求項１０２】
第１のエンティティは第１の広告サーバとプレーリストサーバを制御する請求項１０１記載のソフトウェア。
【請求項１０３】
情報サーバシステムは、第１および第２のエンティティとは独立した第３のエンティティにより制御される請求項１０１記載のソフトウェア。
【請求項１０４】
情報サーバシステムは、それぞれ第３および第４のエンティティにより制御される第１および第２の情報サーバを含み、
第１のエンティティは第３および第４のエンティティとは独立して動作される請求項１０１記載のソフトウェア。
【請求項１０５】
クライアント情報はクライアント装置による広告の提示を制御する請求項１００記載のソフトウェア。
【請求項１０６】
クライアント情報はクライアント装置により提示される広告のターンオーバーレートを制御する請求項１００記載のソフトウェア。
【請求項１０７】
クライアント情報はクライアント装置がプレーリスト要求を発生させる周期を指定し、
プレーリスト応答発生機能はプレーリスト要求に応答してプレーリストを発生させる請求項１００記載のソフトウェア。
【請求項１０８】
クライアント情報は複数の広告の中で競合する広告間の最小時間分離を含む請求項１００記載のソフトウェア。
【請求項１０９】
クライアント情報はクライアント装置が各広告を提示する方法を命令する仕様を含む請求項１００記載のソフトウェア。
【請求項１１０】
広告が現在の広告と満了広告を含み、クライアント情報はクライアント装置が満了広告を提示する前にクライアント装置が現在の広告を提示する最小時間期間を含む請求項１００記載のソフトウェア。
【請求項１１１】
広告が現在の広告と満了広告を含み、クライアント情報はクライアント装置が満了広告を提示できる最大時間期間を含む請求項１００記載のソフトウェア。
【請求項１１２】
クライアント装置は、クライアント情報中に含まれている選択されたパラメータに応答して、広告を提示する持続性のある提示モードと短命の提示モードとを切り換える請求項１００記載のソフトウェア。
【請求項１１３】
プレーリストはプレーリストサーバとクライアント装置の両方においてチェックサムがとられ、それにより各チェックサムが発生され、各チェックサムが同一でないときに、クライアント装置により受信されたプレーリストは無視される請求項１９記載のソフトウェア。
【請求項１１４】
選択された広告はそれぞれ少なくとも１つの画像を含む請求項１９記載のソフトウェア。
【請求項１１５】
選択された広告はそれぞれオーディオデータを含む請求項１９記載のソフトウェア。
【請求項１１６】
通信ネットワークを通して情報サーバシステムと情報を交換し、広告サーバから広告を受信するクライアント装置に対してプレーリスト応答を供給する特殊プレーリストサーバに汎用コンピュータを変えるソフトウェアにおいて、
クライアント装置により提示されるべき複数の選択された広告を識別するプレーリスト応答を発生させるプレーリスト応答発生機能と、
プレーリスト要求の適格性を確認するイクステンシブルマークアップラングエッジ（ＸＭＬ）パース機能と、
オブジェクトを発生させるＸＭＬパース機能による確認後にプレーリスト要求を受信するプレーリスト解析機能と、
オブジェクトを受信してオブジェクトから質問を作り、その質問をプレーリストサーバデータベースに加えるデータベースドライバ機能とを含む、プレーリスト要求から選択された情報を抽出するプレーリスト要求パース機能と、
データベースドライバ機能の出力を受信し、プレーリスト要求の受信に応答してクライアント装置により提供されるべき複数の選択された広告を識別するプレーリスト応答に含めるためにプレーリストを発生させるプレーリスト発生機能と、
選択された情報をプレーリスト応答発生機能に供給してプレーリスト発生機能を開始させる選択された情報供給機能と、
プレーリスト応答がクライアント装置に送信される通信ネットワークを通してのクライアント装置とのプレーリスト応答送信通信リンクをもたらす第１の通信機能と、
通信ネットワークを通してのクライアント装置とのプレーリスト要求受信機能をもたらす第２の通信機能とを具備し、
情報サーバシステムとプレーリストサーバが独立に制御されるソフトウェア。
【請求項１１７】
選択された情報は、クライアント装置をハードウェアクライアント装置とソフトウェアクライアント装置の１つとして識別する請求項１１６記載のソフトウェア。
【請求項１１８】
選択された情報は、ユーザ人口統計とユーザ／クライアント装置の動作の少なくとも１つを含む請求項１１６記載のソフトウェア。
【請求項１１９】
データベースドライバは、
プレーリスト解析機能とデータベースとの間の通信リンクをもたらすデータベース通信機能と、
少なくとも１つのＳＱＬステートメントを含む質問を行う質問機能と、
質問に応答してデータベース出力を検索し、データベース出力をプレーリスト解析機能に提供する検索機能とをさらに含む請求項１１６記載のソフトウェア。
【請求項１２０】
選択された情報は、クライアント装置による選択された広告の各グループの提示を制御する現在のプレーリストを識別するクライアント情報を含み、
プレーリスト応答は、現在のプレーリストに基づいてプレーリストサーバにより発生された更新されたプレーリストを含む請求項１１６記載のソフトウェア。
【請求項１２１】
選択された情報はクライアント情報を含み、
プレーリスト応答は、プレーリスト要求中に含まれるクライアント情報に少なくとも部分的に基づいてプレーリストサーバにより発生される更新されたプレーリストを含む請求項１１６記載のソフトウェア。
【請求項１２２】
クライアント情報は、クライアント装置の利用ヒストリーを示す情報を含む請求項１２１記載のソフトウェア。
【請求項１２３】
クライアント情報は、クライアント装置上で動作する各ソフトウェアを識別するユーザデータフィールドを含む請求項１２１記載のソフトウェア。
【請求項１２４】
ユーザデータフィールドは、その上でソフトウェアが実行される、クライアント装置のオペレーティングシステムを識別する情報をさらに含む請求項１２３記載のソフトウェア。
【請求項１２５】
クライアント情報はユーザデータフィールドを含み、
プレーリスト応答は、プレーリスト要求中に含まれるクライアント情報に少なくとも部分的に基づいてプレーリストサーバにより発生される請求項１２１記載のソフトウェア。
【請求項１２６】
選択された情報は、規定された時間間隔に対してユーザがクライアント装置を使用した時間量に関係する利用データを含む請求項１１６記載のソフトウェア。
【請求項１２７】
プレーリスト応答は、利用データに少なくとも部分的に基づいてプレーリストサーバにより発生される請求項１２６記載のソフトウェア。
【請求項１２８】
選択された情報は、クライアント装置により提示されたままにされる記憶された広告に対して要求される総表示時間量を指定する表示時間残存データフィールドを含む請求項１１６記載のソフトウェア。
【請求項１２９】
プレーリスト応答は、表示時間残存データフィールドに少なくとも部分的に基づいてプレーリストサーバにより発生される請求項１２８記載のソフトウェア。
【請求項１３０】
プレーリスト要求は、規定された時間間隔中にクライアント装置により広告が表示された総時間量を指定する最新使用の表示時間データフィールドを含む請求項１１６記載のソフトウェア。
【請求項１３１】
規定された時間間隔は本日を含む請求項１３０記載のソフトウェア。
【請求項１３２】
プレーリスト応答は、最新使用の表示時間データフィールドに少なくとも部分的に基づいてプレーリストサーバにより発生される請求項１３０記載のソフトウェア。
【請求項１３３】
規定された時間間隔は本日を含む請求項１３２記載のソフトウェア。
【請求項１３４】
選択された情報は、クライアント装置に関係する表示スクリーンの大きさを指定するクライアント装置表示スクリーンデータをさらに含む請求項１１６記載のソフトウェア。
【請求項１３５】
大きさはピクセルで表示された、表示スクリーンの高さ、幅および奥行を含む請求項１３４記載のソフトウェア。
【請求項１３６】
選択された情報は、クライアント装置のディストリビュータを識別するディストリビュータＩＤを含む請求項１１６記載のソフトウェア。
【請求項１３７】
ディストリビュータＩＤは、クライアント装置により提示される広告の少なくとも１つの特性を選択する際に使用される請求項１３６記載のソフトウェア。
【請求項１３８】
プレーリスト応答は、各ディストリビュータＩＤを有するクライアント装置よってのみ提示できる広告を識別する更新されたプレーリストを含む請求項１３６記載のソフトウェア。
【請求項１３９】
選択された情報は、規定された最新時間間隔中にクライアント装置により表示されている広告に対応する広告識別子のリストを含む請求項１１６記載のソフトウェア。
【請求項１４０】
プレーリスト応答は、プレーリスト要求中で識別される規定された最新時間間隔で表示された広告に少なくとも部分的に基づいてプレーリストサーバにより発生される請求項１３９記載のソフトウェア。
【請求項１４１】
選択された情報は、
現在のプレーリストを識別する第１のユーザデータフィールドと、
ユーザ人口統計データを識別する第２のユーザデータフィールドと、
ユーザ／クライアント装置の動作データを識別する第３のユーザデータフィールドと、
クライアント装置の利用ヒストリーを識別する第４のユーザデータフィールドと、
クライアント装置上で動作する各ソフトウェアを識別する第５のユーザデータフィールドと、
クライアント装置の各オペレーティングシステムを識別する第６のユーザデータフィールドと、
規定された時間間隔にユーザがクライアント装置を使用した時間量を識別する第７のユーザデータフィールドと、
クライアント装置により提示されたままにされる記憶された広告に対して要求される総表示時間量を識別する第８のユーザデータフィールドと、
規定された時間間隔の間にクライアント装置により広告が提示された総時間量を識別する第９のユーザデータフィールドと、
クライアント装置と関係する表示スクリーンの大きさを識別する第１０のユーザデータフィールドと、
規定された最新の時間間隔で表示されていた広告に対応する広告識別子のリストと、の中の少なくとも２つを含む請求項１１６記載のソフトウェア。
【請求項１４２】
プレーリストサーバは、クライアント装置に対して、現在のプレーリストが有効であり、更新させる必要がないとの表示を送信するか、またはクライアント装置に対して、更新されたプレーリストを含むプレーリスト応答を送信することにより、プレーリスト要求に応答する請求項１４１記載のソフトウェア。
【請求項１４３】
プレーリスト応答は、第１ないし第１０のユーザデータフィールドの少なくとも２つに含まれるフィールドデータに応答してプレーリストサーバにより発生される請求項１４１記載のソフトウェア。
【請求項１４４】
プレーリスト応答は、第１ないし第１０のユーザデータフィールドおよび選択された情報中に含まれる広告識別子のリストの１つに応答してプレーリストサーバにより発生される請求項１４１記載のソフトウェア。
【請求項１４５】
プレーリスト応答は、各広告の１つに対する広告タイプを識別する更新されたプレーリストを含む請求項１１６記載のソフトウェア。
【請求項１４６】
広告タイプは、郵便切手広告に対応する請求項１４５記載のソフトウェア。
【請求項１４７】
広告タイプは、ツールバー広告に対応する請求項１４５記載のソフトウェア。
【請求項１４８】
広告タイプは、プラカード広告に対応する請求項１４５記載のソフトウェア。
【請求項１４９】
広告タイプは、広告のそれぞれ１つを提示する際にクライアント装置により使用されるタイミングを示す請求項１４５記載のソフトウェア。
【請求項１５０】
選択された情報は、クライアント装置のディストリビュータを識別する請求項１１６記載のソフトウェア。
【請求項１５１】
クライアント装置はソフトウェアクライアント装置を含み、
ディストリビュータは、ソフトウェアクライアント装置を実現する各ソフトウェアを提供し、
プレーリスト応答はディストリビュータの識別子に基づいてプレーリストサーバにより発生される請求項１５０記載のソフトウェア。
【請求項１５２】
クライアント装置はハードウェアクライアント装置を含み、
ディストリビュータは、ハードウェアクライアント装置をユーザに提供し、
プレーリスト応答はディストリビュータの識別子に基づいてプレーリストサーバにより発生される請求項１５０記載のソフトウェア。
【請求項１５３】
プレーリスト要求は、イクステンシブルマークアップラングエッジ（ＸＭＬ）プレーリスト要求を含む請求項１１６記載のソフトウェア。
【請求項１５４】
プレーリスト要求パース機能が文書タイプ定義（ＤＴＤ）を使用する請求項１１６記載のソフトウェア。
【請求項１５５】
複数のクライアント装置タイプの１つに対応する各ＤＴＤはプレーリストサーバにより記憶される請求項１５４記載のソフトウェア。
【請求項１５６】
ＤＴＤはプレーリスト要求中に埋め込まれる請求項１５４記載のソフトウェア。
【請求項１５７】
ＤＴＤは複数のクライアント装置タイプの１つに特定である請求項１５６記載のソフトウェア。
【請求項１５８】
プレーリスト要求は、イクステンシブルマークアップラングエッジ（ＸＭＬ）プレーリスト要求を含み、
プレーリスト要求は、ＸＭＬプレーリスト要求に関係するＤＴＤを識別する文書タイプ定義（ＤＴＤ）タグを含み、
プレーリストサーバはＤＴＤタグに対応する各ＤＴＤを記憶し、
プレーリスト要求パース機能は、ＤＴＤタグに対応するＤＴＤを使用する請求項１１６記載のソフトウェア。
【請求項１５９】
プレーリスト解析機能は、データベースドライバの出力を受信し、プレーリスト応答を構成する請求項１１６記載のソフトウェア。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
この発明は一般的に電子メール（“ｅメール”）ソフトウェアおよびシステムの分野に関する。特にこの発明は広告主にサポートされるｅメールソフトウェアならびにこのような広告主にサポートされたｅメールソフトウェアがインストールされているクライアントコンピュータに広告を配信する方法およびシステムに関する。
【０００２】
【従来の技術】
この特許文書の開示の一部には著作権保護を受ける素材が含まれている。著作権の権利者は特許商標庁で明らかにされるときに特許文書あるいは特許開示のいずれかにより複写再生されることに対して何らの異議はないが、それ以外の場合にはいかなるすべての著作権を留保する。
【０００３】
この出願は１９９９年１２月８日に出願された仮特許出願第６０／１６９，６２２号に基づいている。この仮特許出願は参照により全体がここに組み込まれている。
【０００４】
電子メール（“ｅメール”）は近年いたるところで見られる通信形態になっている。一般的に、ｅメールは次のように機能する。ｅメールソフトウェアはクライアント装置、例えばパーソナルコンピュータ（ＰＣ）にインストールされ、このクライアント装置は通信ネットワークを通して複数の他のクライアント装置と通信するように装備あるいは構成されている。通信ネットワークへのアクセスは通信ネットワークサービスプロバイダ、例えばインターネットサービスプロバイダ（ＩＳＰ）および／またはプロプラエタリネットワークｅメールサービスプロバイダにより提供されることがあり、これらのサービスプロバイダによりユーザは１つ以上のｅメールアカウントを確立し、各アカウントは独特なｅメールアドレス、例えばｐｒｅｓｉｄｅｎｔ＠ｗｈｉｔｅｈｏｕｓｅ．ｇｏｖにより識別される。ｅメールソフトウェア、例えばｅメールクライアントはクライアント装置のユーザがｅメールメッセージを作り、通信ネットワークを通してｅメールメッセージを他のクライアント装置に送信し、通信ネットワークを通して他のクライアント装置から受信したｅメールメッセージを読めるようにする。ユーザはｅメールメッセージを同時に複数の受信者に送信することができ、この能力は時にはメーリングリストあるいは極端なケースでは大量のメーリングを使用することに関係する。典型的なｅメールクライアントはポストオフィスプロトコルバージョン３（ＰＯＰ３）、シンプルメールトランスファプロトコル（ＳＭＴＰ）、インターネットメールアクセスプロトコルバージョン４（ＩＭＡＰ４）、および／またはマルチパーパスインターネットメールイクステンション（ＭＩＭＥ）をサポートする。
【０００５】
各ＩＳＰおよび各プロプラエタリネットワークｅメールサービスプロバイダはｅメール通信システム（あるいは単に“ｅメールシステム”）を独立して運営および制御している。これらの独立的に運営されているｅメールシステムは双方向記憶送信通信システムであり、これらは互いにインターネットを通して相互接続されている。各ｅメールシステムには一般的に多数のｅメールサーバが含まれており、これらのｅメールサーバはインバウンドおよびアウトバウンドｅメールメッセージを記憶して、それらを送信し、それらをルーティングし、あるいは単にそれらをユーザ／意図された受信者に利用可能にする。異なるｅメールシステムが独立した制御エンティティにより運営され、制御される。インターネットの出現により、ユーザは到来ｅメールサーバ（あるいはサーバクラスタ）および送出ｅメールサーバ（クラスタ）の両方、すなわち単一エンティティの制御下における到来および送出のｅメールサーバの両方を提供する単一システムに制限されない。ＡＯＬおよびＪＵＮＯのようなプロプラエタリｅメールシステム以外のほとんどのｅメールクライアントは、第１のエンティティにより制御される到来ｅメールサーバ（クラスタ）およびまったく独立したエンティティである第２のエンティティにより制御される送出ｅメールサーバ（クラスタ）からｅメールを受信するように構成することができる。ほとんどのカジュアルｅメールユーザは単一のエンティティにより運営されている各サーバからダウンロードし、そして各サーバにアップロードしていることが理解されるであろう。
【０００６】
一般的に、ユーザがｅメールメッセージを送信し、あるいは受信メッセージをチェックしたいときには（これらの操作は、規定されたスケジュールにしたがって自動的に生じさせることができる）、ｅメールソフトウェアが起動される。起動されたとき、ｅメールソフトウェアは、
・  規定された通信メカニズム、例えばダイアルアップモデム、ＩＳＤＮ接続、ＤＳＬまたはＡＤＳＬ接続などを呼び出すことにより、規定された通信リンクを通してホストＩＳＰまたはｅメールサービスプロバイダとの接続または通信セッションをもたらし、
・  例えばＳＭＴＰサーバを通して、ホストＩＳＰまたはｅメールサービスプロバイダにより運営されているｅメールサーバシステムに送信されるべきことが望まれている何らかのｅメールメッセージを電子的に送るまたは運び、
・  例えばＰＯＰ３あるいはＩＭＡＰ４サーバを通してホストＩＳＰまたはｅメールサービスプロバイダによりクライアント装置に送信された何らかのインバウンドｅメールメッセージを受信し、
・  クライアント装置内の規定されたメモリ位置、例えばｅメールクライアントにより確立されたデフォルト位置またはユーザが選択した位置に何らかの受信ｅメールメッセージを記憶させる。
【０００７】
例示的なｅメールソフトウェアは、登録商標ユードラプロおよびユードラライト（以後時には一般的に“ユードラ”と呼ぶ）の下、本願の譲受人クゥアルコム・インコーポレーテッドにより販売されている商業的に入手可能なｅメールソフトウェアである。一般的に、ユードラプロｅメールソフトウェアはユーザに“完全機能セット”を提供し、ユードラライトｅメールソフトウェアはユーザに“縮小機能セット”を提供し、これはユードラプロｅメールソフトウェアにより提供される“完全機能セット”のサブセットである。ユードラプロｅメールソフトウェア（これの現在のバージョンは“ＥＰ４”と呼ぶ）はユーザにより（あるいはユーザに代わって他の誰かにより）支払がなされなければならず、したがって“ペイウェア”と見なすことができ、一方、ユードラライトｅメールソフトウェアは登録されたユーザに無料で提供され、したがって“フリーウェア”と見なすことができる。何らかのバージョンのユードラをインストールしている各クライアント装置は“ユードラクライアント”と見なすことができる。現在、インストールされたベースを持つ非常に多くのユードラクライアントが存在する。
【０００８】
本願の譲受人クゥアルコム・インコーポレーテッドはＥＵＤＯＲＡアドウェア（以下時には単に“アドウェア”と呼ぶ）と呼ばれる人気のあるＥＵＤＯＲＡｅメールソフトウェアの新しいバージョンを現在リリースする予定である。ユードラのこの新しいアドウェアバージョンは前に言及したユードラのペイウェアおよびフリーウェアバージョンも含むことになるすぐにリリースされる（“新しい”）ユードラソフトウェア製品内に含まれることになる。一般的にこのすぐにリリースされるユードラ製品内に含まれているユードラの各バージョンは独立したモードを構成し、ユードラの各バージョンは規定された基準または条件にしたがって自動的に起動し、あるいはモード間を切り換えることができ、あるいは規定されたユーザのアクション例えば登録、支払、選択などにしたがって、起動し、あるいはモード間を切り換えることができる。ユードラのこの新しいアドウェアバージョンおよび同じものを含んでいるマルチモード化ユードラｅメールソフトウェア製品は、一部には本願の譲受人の希望に動かされて、広告主により支払がなされる広告をユードラクライアントに配信することにより、ユードラのペイウェアバージョンによりユーザに提供される“完全機能セット”を無料でユーザに提供し、それにより支払／収益源を効果的にユーザから広告主にシフトさせている。したがって、この新しいユードラソフトウェア製品は“広告主にサポートされた”または“広告主に助成された”または単に“スポンサー付き”ソフトウェアとして見なすことができる。
【０００９】
ほとんどのインターネットサービスプロバイダ（ＩＳＰ）およびｅメールサービスプロバイダは均一の月極加入者料金をユーザに請求するが、プロバイダの中には利用に基づいて、例えば規定されたレベルを超えるオンライン時間に対して追加課金を未だに請求しているものもある。しかしながら、基本的なｅメールサービスを受けたいが、インターネットアクセスに対して支払の必要を感じない、あるいは支払を望まない多くのユーザが存在している。いくつかの会社は受信ｅメールメッセージとともに広告を受信することに同意しているユーザ／加入者に無料ｅメールサービスを提供することにより、この市場セグメントのニーズを取り扱っている。このように、広告主は無料ｅメールサービスをサポートあるいはこのスポンサーとなっている。
【００１０】
関連文献に基づくと、このような無料ｅメールサービスを提案し、提供した最初の会社は（“プロダクトビューインターラクティブ”としても知られている）フリーマークコミュニケーションであったと思われる。無料ｅメールサービスを提供するフリーマークのシステムおよび方法は国際公開番号ＷＯ９６／２４２１３のＰＣＴ公開された特許出願に開示されており、発明者Ｍａｒｖ  Ｇｏｌｄｓｃｈｍｉｔｔ氏およびＲｏｂｅｒｔ  Ａ．Ｙｏｕｎｇ氏の名前が付けられている米国出願第０８／３８２，１１８号に基づいて１９９５年２月１日の優先日を有している。この公開されたＰＣＴ特許出願の開示は特に参照によりここに組み込まれている。簡単に説明すると、この無料ｅメールシステムは添付物として、例えばグラフィカル画像ファイル（ＧＩＦ）添付物として加入者に送信されるｅメールメッセージに広告を添付した広告主により助成されていた。広告は加入者が受信ｅメールメッセージをオフラインで読んでいる間に見るために加入者のコンピュータに記憶されていた。プロモーション用のいくつかの文献では、フリーマークは添付広告を“郵便切手”として呼んでいた。フリーマークの文献では、加入者により受信された各メッセージは郵便切手が貼られた封筒として描かれていた。郵便切手は広告であった。
【００１１】
その後、ジューノオンラインサービスＬ．Ｐ．（以下単に“ＪＵＮＯ”）の名称の会社が無料ｅメールサービスを導入した。無料ｅメールサービスを提供するＪＵＮＯシステムおよび方法は米国特許第５，８０９，２４２号に開示されており、この米国特許は１９９８年１２月８日にＭａｒｓｈ氏らに発行され、この開示も特に参照によりここに組み込まれている。プロプラエタリＪＵＮＯｅメールシステムにより、加入者がプロプラエタリＪＵＮＯｅメールサーバシステムに接続してｅメールメッセージを送信および／または受信するときに、複数の広告が加入者にダウンロードされ、加入者がオフラインでｅメールメッセージを作りまたは読んでいるとき、すなわち加入者のコンピュータに前もってインストールされているＪＵＮＯｅメールソフトウェアを加入者が起動するときに表示するために、広告は加入者のコンピュータにローカル的に記憶される。ローカル的に記憶された広告は加入者のコンピュータ上に存在する表示スケジューラの制御下で表示され、動的な方法で広告を回転あるいは変化させることができる。これにより加入者に提示されている広告が連続的に変化して表示されることになる。プロプラエタリＪＵＮＯｅメールシステムのさまざまな他の観点および特徴は米国特許第５，８３８，７９０号に開示されており、これはＭｃＡｕｌｉｆｆｅ氏らに１９９８年１１月１７日に発行され、また米国特許第５，８４８，３９７号に開示されており、これはＭａｒｓｈ氏らに１９９８年１２月８日に発行され、これら両特許の開示も特に参照によりここに組み込まれている。
【００１２】
【発明が解決しようとする課題】
フリーマークおよびＪＵＮＯのプロプラエタリ無料ｅメールシステムの両システムにより、広告とｅメールメッセージの両者が単一のｅメールシステムに記憶され（例えばＪＵＮＯはユーザがサービスのために最初にサインアップしたときにユーザに割り当てられる（結びつけられる）単一の独特なサーバ上に両者を記憶する）、ｅメールシステムのすべての部分を制御している共通な制御エンティティの指図の下で加入者に配信される。無料ｅメールサービスを提供するためにはこれは望ましいシステムアーキテクチャであるかもしれないが、ｅメールシステムとは独立した広告主にサポートされたｅメールソフトウェア、すなわち特定のプロプラエタリｅメールサービスプロバイダに結びつけられていないが、公の標準規格例えばＰＯＰ３、ＳＭＴＰ、ＩＭＡＰ４などをサポートしているソフトウェアを配信することが目的であるシステムにとって適切なシステムアーキテクチャではない。さらに、無料ｅメールシステムのアーキテクチャは複数のｅメールアカウント、例えばビジネスアカウントとパーソナルｅメールアカウントを維持している多くの人々にとって適切ではない。先に言及したように、ユードラｅメールソフトウェアの完全機能バージョンがエンドユーザに対して無料で幅広く配信されることを可能にする広告収益を発生させるために、広告をユードラクライアントに配信するシステムおよび方法を提供する要求により本発明者は動機付けられた。さらに、本発明者はユニバーサルでありかつｅメールシステム独立である、すなわち何らかの特定のプロプラエタリｅメールサービスまたはサービスプロバイダに結びつけられていないｅメールソフトウェアを提供する要求により動機付けられた。
【００１３】
したがって、本発明者はペイウェア、フリーウェアおよびアドウェアを含むすぐにリリースされるマルチモード化ユードラｅメールソフトウェア製品を開発し、この新しいソフトウェア製品を備えたクライアントに対して広告を配信する新規なシステムおよび方法を考案した。以後完全に明らかになるように、この新規なシステムの目的およびアーキテクチャはプロプラエタリフリーマークおよびＪＵＮＯｅメールシステムのものとは根本的に異なっている。これに関して、すぐにリリースされるマルチモード化ユードラｅメールソフトウェア製品、ならびにこの新しいソフトウェア製品を備えたクライアントに対して広告を配信する新規なシステムおよび方法は、以下の開示およびそこで参照されている文書から完全に明らかになる多数の異なる発明を包含している。
【００１４】
先のおよび前述のものに基づくと、助成されたｅメールクライアントに対して技術的な必要性が現在存在し、これは先に説明した欠点を解消することが理解できるであろう。本発明は現在利用可能な技術の欠点および短所を解消して、技術的なこの必要性を満たす要望により動機付けられたものである。
【００１５】
その１つの観点では、本発明はｅメールソフトウェアがｅメールシステム独立であるような全ｅメールソフトウェア製品を助成するために（例えばｅメールソフトウェア製品の“フリーウェア”バージョンをエンドユーザに提供するために）、ｅメールソフトウェアが起動されるときに表示されるべき広告を自動的にダウンロードする自動広告ダウンロード機能を組み込んだｅメールソフトウェアを包含する。ｅメールソフトウェアはユニバーサルであるスタンドアローン製品であり、すなわちオープンな標準規格に準拠するサービスを含む、実質的にいかなるｅメールサービスプロバイダあるいはｅメールシステムとともに動作する。本発明はこのｅメールソフトウェアがインストールされている複数のクライアント装置に広告を自動的に配信するシステムおよび方法も包含する。
【００１６】
１つの観点にしたがうと、本発明は各ｅメール運営者により運営されている複数のｅメールサーバの少なくとも１つからｅメールメッセージを受信し、このような少なくとも１つのｅメールサーバにｅメールメッセージを送信するｅメールクライアントを提供する。ｅメールクライアントは１つ以上のｅメールシステムを運営している制御エンティティとは異なる制御エンティティにより運営されている広告サーバから少なくとも１つの広告を受信する。
【００１７】
他の観点にしたがうと、本発明はｅメールクライアントを実現する例えばｅメールクライアントソフトウェアを記憶する記録媒体を提供し、このｅメールクライアントはそれぞれｅメール運営者により運営されている複数のｅメールサーバの少なくとも１つからｅメールメッセージを受信し、このような少なくとも１つのｅメールサーバにｅメールメッセージを送信する。ｅメールクライアントはｅメールサーバとは独立して運営されている広告サーバから広告を自動的に受信する。
【００１８】
さらに別の観点にしたがうと、本発明は広告サーバ運営者により提供され、複数の独立して運営されるｅメールサーバと互換性があり、オープンなｅメール標準規格に基づくものを含む、ｅメールクライアントを動作させる方法も包含する。この方法は、ｅメールサーバの選択されたものとの間の周期的な送信および受信の少なくとも１つ、広告サーバ運営者から広告を周期的に受信し、広告サーバ運営者により提供される命令に応答して、受信された広告を表示するステップを含むことが好ましい。
【００１９】
さらに別の観点にしたがうと、本発明は複数のユーザにアドレスされた到来ｅメールメッセージを記憶する到来ｅメールサーバと、ユーザにより発生された送出ｅメールメッセージを送信またはルーティングする送出ｅメールサーバと、ｅメールサーバとは独立して運営される広告サーバと、各ユーザにより操作される複数のｅメールクライアントを含むｅメールシステムを提供する。各ｅメールクライアントが到来ｅメールサーバに記憶されている各ｅメールメッセージをチェックし、ｅメールクライアント上に記憶されている送出ｅメールメッセージを送出ｅメールサーバに送信し、ｅメールクライアントがオンラインの間に広告サーバから利用可能な広告をダウンロードすることが好ましい。
【００２０】
他の観点にしたがうと、本発明は通信ネットワークを通して複数の他のクライアント装置と通信するように構成されたクライアント装置上で使用するためのソフトウェアを包含する。クライアント装置はソフトウェアをクライアント装置にインストールするインストーラ機能と、ユーザがｅメールメッセージを送信したい場合にはいつでも通信ネットワークを通してクライアント装置とｅメールサービスプロバイダサーバシステムとの間の送信ｅメール通信リンクを確立し、ユーザが受信ｅメールメッセージをチェックしたい場合にはいつでもクライアント装置とｅメールサービスプロバイダサーバシステムとの間の受信ｅメール通信リンクを確立し、選択された広告ダウンロード時間において、通信システムを通してクライアント装置と広告配信サーバシステムとの間の広告ダウンロード通信リンクを確立する通信機能とを提供することが好ましい。さらにクライアント装置は、クライアント装置のユーザがｅメールメッセージを作成することができるようにするｅメール作成機能と、ユーザが送信ｅメール通信リンクを通してｅメールメッセージを他のクライアント装置に送信できるようにするｅメール送信機能と、ユーザが受信ｅメール通信リンクを通して他のクライアント装置からｅメールメッセージを受信できるようにするｅメール受信機能と、広告ダウンロード通信リンクを通して広告配信サーバシステムにより配信される広告をダウンロードする広告ダウンロード機能とを提供する。すべてのケースにおいて、ｅメールサービスプロバイダサーバシステムと広告配信サーバシステムは本発明にしたがって独立して制御されることに留意すべきである。
【００２１】
先の発明概念の他の多くの特徴、観点、利用、応用、利点、修正、変形および代替実施形態は以下の技術的な資料による裏付けから明らかになるであろう。この技術的な資料による裏付けはすべての目的に対してこの出願の不可欠な部分を構成する。さらに、先に説明されていない付加的な発明概念はこの技術的な資料による裏付けで開示されており、この出願はこのような付加的な発明概念をカバーすることを意図している。
【００２２】
さらに、本発明の先のおよび以下の説明で使用されているいくつかの用語を以下のように定義する。
【００２３】
用語：広告
説明：この用語は一次的なコンテンツ例えばｅメールメッセージに付加してクライアント装置に届けられるあるいは配信される何らかの二次的なコンテンツを広く含むことを意図している。クライアント装置により実現されるソフトウェア製品はこのｅメールメッセージを受信、送信、処理、表示および／または利用するように設計されている。例えばこの用語は、限定無く、有料広告、コミュニティサービスメッセージ、パブリックサービスアナウンス、システム情報メッセージまたはアナウンス、クロスプロモーションスポット、アートワーク、他の任意のグラフィック、マルチメディア、オーディオ、ビデオ、テキストあるいは他の二次的なデジタルコンテンツをカバーすることを意図している。それにもかかわらず、本発明の現在企図されている商業的な実施形態の主要な目的は有料広告を配信することであり、したがって本発明の好ましい実施形態にしたがうと、広告はもっぱら、あるいは少なくても主として有料広告であることが理解されるであろう。
【００２４】
用語：クライアント装置
説明：この用語はデジタルデータ処理および出力例えば表示能力を持つ任意の装置を広く含むことを意図しており、これらに限定されるものではないが、デスクトップコンピュータ、ラップトップコンピュータ、ハンドヘルドコンピュータ、ノートブックコンピュータ、パーソナルデジタルアシスタント（ＰＤＡ）、パームトップコンピュータ装置、インテリジェント装置、情報アプライアンス、ビデオゲームコンソール、情報キオスク、有線および無線パーソナル通信システム（ＰＣＳ）装置、スマートフォン、組み込みウェブブラウザを有するインテリジェントセルラ電話、ケーブル、衛星および／または地上放送テレビ用インテリジェントリモート制御装置、要求された能力を持つ他の任意の装置を含む。
【００２５】
用語：情報
説明：この用語はクライアント装置すなわち情報クライアント装置により表すことができる何らかの理解可能な形態の情報を広く含むことを意図しており、これらに限定されるものではないが、インターネットのような通信ネットワークを通して送信することができる、テキスト、文書、ファイル、グラフィックオブジェクト、データオブジェクト、マルチメディアコンテンツ、オーディオ／サウンドファイル、ビデオファイル、ＭＰＥＧファイル、ＪＰＥＧファイル、ＧＩＦファイル、ＨＴＭＬ文書、アプリケーション、フォーマットされた文書（例えばワードプロセッサおよび／またはスプレッドシート文書またはファイル）、ＭＰ３ファイル、アニメーション、写真、および他の任意の文書、ファイル、デジタルまたはマルチメディアコンテンツを含む。
【００２６】
用語：ｅメールメッセージ
説明：この用語はｅメールメッセージとこのメッセージに対する何らかの添付物を広く含むことを意図しており、これらに限定されるものではないが、インターネットのような通信ネットワークを通して送信することができる、テキスト、文書、ファイル、グラフィックオブジェクト、データオブジェクト、マルチメディアコンテンツ、オーディオ／サウンドファイル、ビデオファイル、ＭＰＥＧファイル、ＪＰＥＧファイル、ＧＩＦファイル、ＨＴＭＬ文書、アプリケーション、フォーマットされた文書（例えばワードプロセッサおよび／またはスプレッドシート文書またはファイル）、ＭＰ３ファイル、アニメーション、写真、および他の任意の文書、ファイル、デジタルまたはマルチメディアコンテンツを含む。
【００２７】
用語：ソフトウェアプロバイダ
説明：この用語はクライアント装置上にインストールされたマルチモードソフトウェア製品の開発者（複数の開発者）、販売者、ディストリビュータなどを広く含むことを意図している。
【００２８】
用語：メモリ
説明：この用語は直前で言及したクライアント装置を実現するためのコンピュータ読み取り可能なコードを記憶および／または組み込むことができる任意の装置を広く含むことを意図している。したがってこの用語はすべてのタイプの記録媒体、例えばＣＤ−ＲＯＭ、ディスク駆動装置（ハードまたはソフト）、磁気テープ、記録装置、例えばＤＲＡＭ、ＳＲＡＭ、ＥＥＰＲＯＭ、ＦＲＡＭおよびフラッシュメモリを含むメモリ装置を包含する。この用語は持続性の記憶装置と考えることができる任意のタイプの装置を含むことを意図していることに留意すべきである。特定用途向け集積回路（ＡＳＩＣ）がクライアント装置を実現するための命令を組み込むと考えることができる範囲では、ＡＳＩＣも用語“メモリ”の範囲内のものであると考えられる。
【００２９】
本発明のこれらおよび他のさまざまな特徴および観点は同一または類似の番号が全体を通して使用されている図面とともに、以下の詳細な説明を参照すると容易に理解できるであろう。
【００３０】
【発明の実施の形態】
添付図面を参照して実例となる実施形態および例示的な応用をこれから説明し、本発明の有効な技術を開示する。
【００３１】
本発明はここでは特定の応用に対して実例となる実施形態を参照して説明されているが、本発明はこれに限定されるものでないことを理解すべきである。通常の技能を有し、ここに提供されている技術にアクセスする者は本発明の範囲内および本発明が顕著な有用性を有する付加的な領域の付加的な修正、応用および実施形態を認識するであろう。
【００３２】
特定の図面を参照すると、図１は例示的なシステム構成１０を図示しており、このシステム構成１０は本発明の典型的な実施形態にしたがった機能を実行するのに適切なものである。この典型的な実施形態は、多数のユーザがｅメールメッセージを作成し、送信し、受信し、そして読むことができる電子メール（ｅメール）システムに関して一般的に説明されているが、本発明はそのように限定されるものではない。例えば、本発明はワイヤレスネットワークを通して株式相場を受信する特殊化されたソフトウェアを組み込んだパーソナルデジタルアシスタント（ＰＤＡ）に等しく適用することができる。したがって、本発明の原理はｅメールシステムのみに限定されるものとして考えるべきではなく、本発明の原理はソフトウェア機能のコアセットに対してさまざまな支払オプションを使用してそのソフトウェアがユーザに利用可能になるように例えばソフトウェアプロバイダのようなプロバイダが望むオンラインサービスに適用できる。
【００３３】
図１に示されているように、システム１０には複数のクライアントコンピュータ１００ａ、１００ｂ、…、１００ｎが含まれており、ｎは任意の正の整数を示している。一般的に１００で示されている各クライアントコンピュータは本発明にしたがってクライアントプログラムを実行するワークステーションまたはパーソナルコンピュータのいずれかにできることが好ましい。例示的なケースでは、クライアントコンピュータ１００ａ、１００ｂ、…、１００ｎはネットワーク２００例えばインターネットを通して複数のサーバ３０１−３０４に接続することができると有効であり、これらのサーバ３０１−３０４は以下でさらに詳細に説明する。代わりに、ネットワーク２００はローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、イントラネット、またはワイヤレスネットワークの１つあるいはこれらの組合せとすることができる。図１は制限のない例示的なシステムを図示しており、多数のクライアントを任意の多数のサーバに接続することができることが理解できるであろう。
【００３４】
図２は図１に図示されているクライアントコンピュータ１００ａ、１００ｂ、…、１００ｎの例示的な１つのさらに詳細なハードウェア構成を図示している。典型的な実施形態において、クライアントコンピュータ１００ａには（本発明の１つの例示的な実施形態にしたがったクライアントプログラムを含む）コンピュータプログラムを実行し、クライアントコンピュータ１００ａの動作を管理および制御する中央処理ユニット２０９が含まれている。例えばフロッピーディスクのような取り外し可能な記憶媒体との間でデータおよびコンピュータプログラムを読み書きするために、フロッピーディスク駆動装置のような記憶装置２０５が中央処理ユニット２０９に結合されている。中央処理ユニット２０９に結合された記憶装置２０６はコンピュータプログラムおよびデータを記憶するメカニズムも提供する。記憶装置２０６は高い記憶能力を持つハードディスクであることが好ましい。ＲＡＭのようなダイナミックメモリ装置２０７も中央処理ユニット２０９に結合されている。記憶装置２０５および２０６とともにダイナミックメモリ装置２０７はメモリの制限のない例であり、この用語は先に定義してあることに留意すべきである。クライアントコンピュータ１００ａには例えばキーボード２０３、マウス２０４、モニタ２０８、通信装置２０１のような典型的な入出力装置が含まれている。通信装置は有効にモデム、イーサネット、インターフェイスカードなどにすることできることが理解できるであろう。
【００３５】
図１を再度参照すると、各クライアントコンピュータ１００ａ、１００ｂ、…、１００ｎはネットワーク２００を通して例えばサーバ３０１−３０４のような任意のサーバと選択的に通信することができる。図１に図示されているコンピュータシステム１０では、各サーバは特殊化された機能を実行する。例示的なケースでは、サーバ３０１は登録機能を実行し、すなわち（以下でさらに詳細に説明するように）各クライアントコンピュータから登録情報を受け取り、サーバ３０２はクライアントコンピュータ１００ａ、１００ｂ、…、１００ｎに対してプレーリストを提供し、サーバ３０３はプレーリスト中で指定された広告を提供し、サーバ３０４は通常のｅメールシステムとして機能し、すなわちサーバシステムは到来ｅメールサーバと送出ｅメールサーバの両方を提供する。サーバ３０１および３０２のみが実際にソフトウェアプロバイダ、例えば好ましい実施形態ではクゥアルコム・インコーポレーテッドの直接的な制御を受ける必要があることに留意すべきである。しかしながらサーバ３０３も同様にソフトウェアプロバイダの制御の下にあると効果的である。ソフトウェアに対する参照はディスクベースのソフトウェアに限定されるように解釈すべでなく、命令がダイナミックメモリから読み出されようと、あるいはリードオンリーメモリ（ＲＯＭ）や他のさまざまなこのような装置にファームウェアとして記憶されようと用語“ソフトウェア”はプロセッサにより実行される命令として広く解釈すべきであることにも留意すべきである。
【００３６】
本発明の１つの観点にしたがうと、“ソフトウェア”はソフトウェア例えばすべてのユーザにより使用することができるユードラソフトウェアを含む（クライアント装置ごとに）単一のバイナリファイルとして提供できることが効果的である。このバイナリファイルはペイウェア、フリーウェアおよびアドウェアの３つの主要な動作モードの１つで動作する。ペイウェア動作モードでは、ユーザはソフトウェアプロバイダに支払をしてソフトウェアを使用しなければならない。フリーウェアはすべての使用に対して無料であるが、ペイウェアまたはアドウェアよりも少ない機能しかない。ペイウェアユーザは、ソフトウェアプロバイダが支払の際にペイウェアユーザに提供する登録コードにより支払を証明することが好ましい。このコードは外部からの承認を必要としないものであり、ユーザが動作させる権利を与えられているのがどのバージョンであるかを識別するのに十分なデータを含んでいる。ユードラのペイウェアバージョンのユーザは支払に続く暦年中に作られたユードラのすべてのバージョンの権利を与えられることに留意すべきである。ソフトウェアは、ソフトウェアに対する更新が利用可能であるかどうかを決定するために、周期ベースで予め定められたサイト例えばクゥアルコム・インコーポレーテッドに維持されているサイトをポーリングすることが好ましく、以下でさらに詳細に説明するように、更新が利用可能である場合には、ソフトウェアの更新を得るための小さいウェブページのオプションをソフトウェアがユーザに提供できることが有効である。
【００３７】
アドウェアはペイウェアのすべての機能を持つが、ユーザからの支払を要求しないことに留意すべきである。アドウェアが要求することはユーザが広告を表示して見ることであり、この広告はユーザがソフトウェアプロバイダサイトおよび／またはソフトウェアプロバイダにより指定された１つ以上のサイトからダウンロードする。ソフトウェアの最初の状態はアドウェアであることにも留意すべきである。
【００３８】
例示的な好ましい実施形態では、以下でさらに詳細に説明するように、各クライアントコンピュータは広告サーバ３０３からそっと、そして大きな帯域幅を取ることなく広告をダウンロードする。さらに、ソフトウェア例えばユードラの使用を大幅に損ねることがない方法で広告を表示できることが効果的である。図３および図４は例示的なユードラｅメールソフトウェアのメインスクリーンに統合された広告を図示している。
【００３９】
本発明の例示的な実施形態の機能および新規な特徴を説明する際に使用されているいくつかの用語は先に提示した。ユードラソフトウェアに関して本発明を完全に理解するのを促す付加的な用語を直後に提示する。
【００４０】
【表１】
2005513583.tif 000003
【００４１】
【表２】
2005513583.tif 000004
【００４２】
【表３】
2005513583.tif 000005
【００４３】
先に言及したように、“ソフトウェア”は、（要求された場合に）すべてのユーザにインストールして使用できるソフトウェア例えばユードラソフトウェアを含む単一のバイナリファイルとして提供できると有効である。このバイナリファイルはペイウェア、フリーウェアおよびアドウェアの３つの主要動作モードのうちの１つで動作する。本発明にしたがったソフトウェアプログラムのさまざまな機能のインストールおよび動作を、いくつかの状態フロー図を参照してこれからさらに詳細に説明する。この状態図は主なユーザ状態とそれらの間の遷移を図示している。フロー状態図では以下の規約が遵守される。
【００４４】
・  一段高くなったグレーの長方形はダイアログ中のボタンに対する概念的な名称である。
・  いくつかのパスはメニュー項目のラベルが付されている。これらの項目はナグを待つことなく、直接問題となっているウィンドウを作動させるために使用することができる。・  原則として、任意のダイアログまたはナグはキャンセルすることでき、ユーザが最初の状態に戻る余地を残す。
・  ウェブページはユーザ状態を変化させることができず、あるいはさらに多くのダイアログを発生させることができない。したがってすべてのウェブページはユーザの最初の状態に戻すように導く。
【００４５】
先に示した規約により、図５および図６を参照してユードラｅメールソフトウェアのインストールをこれから説明する。図５および図６はソフトウェアの１つのバージョンが新しいユーザ、古いユーザ、およびＥＰ４ユーザのうちの１人によりインストールされるときの状態遷移を図示している。ソフトウェアプロバイダはイントロダイアログ中に、完全機能セットに対する支払のためのオプション、あるいは縮小機能セットを有するソフトウェアを受け入れるためのオプションをユーザに与えないことに留意すべきである。ソフトウェアプロバイダは、ヘルプメニューを通して進むことによりソフトウェア機能セットのこれらの代替バージョンをユーザが獲得できる事実とともに、例えば図６に示されているものと同様なダイアログボックスを通してこれらのオプションを説明するが、ソフトウェアのデフォルトはアドウェアバージョンである。
【００４６】
図５に図示されているＥＰ４ユーザとボックス購入者により取られるパスは入念に作られるべきものに値する。図５において言及されているコード発生器はバイナリファイルのインストーラモジュールより例えば実現されることが有効であり、ユードラｅメールプログラムそのものにはない。ユーザがソフトウェアの４．ｘ−＞４．３更新機能を使用している場合には、ソフトウェアＥＰ４のコピーをサーチし、ソフトウェアのコピーを見つけたとき、コード発生器はユーザが登録コードファイルを発生させることを許容する。ユーザがすばらしいインストーラを実行していた場合には、インストーラは最初にＥＰ４のコピーを探すことなく登録コードの発生を許容する。このように登録された登録コードファイルは“ユードラは登録を必要とする：はい”と述べた１行を含む特別なものであることに留意すべきである。ユードラｅメールソフトウェアは、この１行のテキストを通知し、ユーザを未登録状態にし、その後ソフトウェアを登録するようにユーザに催促する。いったんユーザが登録すると、同じ登録コードがユーザに再送され、（現在のコードと同じであることから）ユードラｅメールソフトウェアはひっそりとそれを受け入れ、ｅメールソフトウェア中にフラグを登録する必要性をターンオフする。
【００４７】
図７はアドウェアユーザが登録アドウェアユーザになるプロセスの状態フロー図である。図示している例示のケースでは、登録プロセスはクライアントコンピュータ１００ａと登録サーバ３０１との間の相互対話を必要とし、クライアントコンピュータ１００ａと登録サーバ３０１はネットワーク２００を通して相互に接続されていることが理解できるであろう。図５に示されているアドウェアユーザは図７ではいくつかの代替メカニズムを通してソフトウェアプロバイダに登録する。例えば、広告ユーザは登録することを要望し、図３の最上部に図示されているツールバーから利用可能である“ヘルプ”プルダウンメニューを単に起動し、図８に示されているように支払＆登録オプションを選択する。代わりに、アドウェアユーザはナグボックスを、すなわち以下でさらに詳細に説明するように予め定められた時間にソフトウェアにより発生されるナグダイアログボックスを受信する。最後に広告ユーザはｅメールを通して登録を、すなわちサーバ３０１により発生され、ｅメールサーバ３０４を経由してクライアントコンピュータ１００ａに送信される登録コードを受信する。
【００４８】
図８に示されているように、支払＆登録ウィンドウはいくつかの選択ボタンを提供し、これらのボタンにより広告ユーザはアドウェアを登録し、ソフトウェアに対する支払をし、ユーザに利用可能なすべてのバージョンをリストアップし、人口統計情報を提供することにより、広告ストリームをカスタマイズまたは修正し、受信した登録コードを入力し、フリーウェアユーザに対して提示された縮小機能セットにダウングレードする。図９ないし図１３を参照。ユーザは登録コードを入力して、登録アドウェアユーザ、登録フリーウェアユーザ、および登録ペイウェアユーザのうちの１つになれることに留意すべきである。図１２参照。登録アドウェアユーザが登録ナグを受けないことを除いて、登録アドウェアユーザに対する状態フロー図と同じものにしたがってソフトウェアは動作することが理解できるであろう。
【００４９】
ソフトウェアプロバイダは外部からの承認を必要としない登録コードで有効に登録スキームを使用することができるので、登録を確認するためにデータベースを使用する必要はない。確認のためのアルゴリズムはいくつかの相反する制約を満足させる意図がある。すなわち安全であるが実現することが容易であり、ユーザにとって過度に煩わしいものでないことが必要である。ユードラｅメールソフトウェアは確認の開始時にその登録コードをチェックする。登録コードが無効である場合には、ユーザは未登録であると考えるべきである。ユーザが有料モードユーザである場合には、これはスポンサー付きモードに切り換えることを必要とする。これについてユーザは（示されていない）ダイアログボックスを使用して警告を受ける。このアラートの後にコードを再入力する機会が続く。登録コードを発生させるために必要な入力は次の通りである。
【００５０】
ＲｅｇＮａｍｅ：ユーザが登録したいネーム。ソフトウェアプロバイダはこれがユーザの本当のネームであることを暗示するが要求はしない。このネームが使用される唯一のことは登録である。ユーザにより与えられる。ソフトウェアプロバイダがこのネームをユーザから実際に集めるとき、ソフトウェアプロバイダはそれぞれＲｅｇＦｉｒｓｔＮａｍｅおよびＲｅｇＬａｓｔＮａｍｅと呼ばれる、ファーストネームおよびラストネームに関して尋ねる。ＲｅｇＮａｍｅはＲｅｇＦｉｒｓｔＮａｍｅ、１つのスペース、およびＲｅｇＬａｓｔＮａｍｅを連結することにより作られる。ファーストネームとラストネームのそれぞれは２０の有効な文字までに制限され、それを超えると文字は無視される。
ＲｅｇＭｏｎｔｈ：例えば８ビット（２０年）で１９９９年１月１日からの月数として表される登録の日付。すべて１は“決して満了しない”状況のために確保されている。
Ｐｒｏｄｕｃｔ：登録対象の製品を示す数字コード。ユーザは製品を選択する。ソフトウェアプロバイダはその選択を８ビットコードに変換する。
【００５１】
外部からの承認を必要としない登録コードを発生させる際に複数の登録コードアルゴリズムを使用できると有効であることが理解できるであろう。簡単に説明すると、ソフトウェアプロバイダは先にリストアップした入力を取り込み、それらのチェックサムをとり、（ＲｅｇＮａｍｅを含む）入力を混合し、さまざまなアルゴリズムの任意の１つにしたがって互いにチェックサムをとり、その結果を１６ビット数のストリングとしてエンコードする。エンコーディングとビット混合は逆にすることができ、そしてＲｅｇＮａｍｅと一緒にし、ＲｅｇＣｏｄｅの有効性を確認するためにチェックサムを使用することができることも理解できるであろう。
【００５２】
ソフトウェアプロバイダは、フリーウェア（ユードラライト）、アドウェア（スポンサー付き）、ペイウェア（ユードラプロ）のソフトウェアモードに対して独立してＲｅｇＣｏｄｅを記憶することに留意すべきである。１つの動作モードに対するＲｅｇＣｏｄｅの受け入れは、他のモードに対するＲｅｇＣｏｄｅを消失させるべきことを意味しない。
【００５３】
いったんＲｅｇＣｏｄｅが発生されると、ユーザはなんとかして有効なＲｅｇＣｏｄｅをユードラｅメールクライアントに入力する必要がある。これは以下の３つの方法のうちの１つで達成することができる。
【００５４】
・  手動。ユーザは値を入力コードダイアログボックスにタイプあるいはペーストすることができる。図１２参照。
・  ウィンドウ登録。ユードラ開始時に、ソフトウェアはウィンドウ登録（例えば、ソフトウェア＼クゥアルコム＼ユードラ＼チェック、Ｆネーム、Ｌネーム、Ｒコード）中のＲｅｇＣｏｄｅを探す。これらの選択物が見つかり、有効であるならば、ｅメールクライアントの選択レジスタあるいは関係するルックアップテーブルに値をコピーすべきである。・  ＲｅｇＣｏｄｅファイル：ユードラ開始時に、例示的なケースでは“ＲｅｇＣｏｄｅ．ｄａｔ”とネームが付けられたアプリケーションソフトウェアホルダー中のファイルを探す。これらの選択物が見つかり、有効であるならば、ｅメールクライアントの選択レジスタあるいは関係するルックアップテーブルに値をコピーすべきである。
【００５５】
ソフトウェアプロバイダは特別ケースＭＩＭＥ部分がユードラｅメールクライアントにメールされることを許容することにも留意すべきである。この部分を受信するユーザは情報を確認および入力するように自動的に依頼される。ユーザは添付物を再度後で実行することもできる。しかしながら、ユーザはユードラｅメールクライアントを使用して誰か他の人に添付物を送信することはできない。その理由はその部分を起動するためには特別なコンテンツタイプ属性（“ＲｅｇＣｏｄｅ”）が要求され、ユードラｅメールクライアントはそれらを送信することができないからである。
【００５６】
ＭＩＭＥ部分（およびＲｅｇＣｏｄｅファイル）のフォーマットは、ＲＦＣ８２２ヘッダスタイルフィールドを含むテキストファイルのものである。これは登録済ＭＩＭＥタイプのアプリケーション／ｖｎｄ．ｅｕｄｏｒａ．ｄａｔａを持つ。ＭＩＭＥ部分中に含まれているフィールドは次の通りである。
【００５７】
Ｅｕｄｏｒａ−Ｆｉｌｅ−Ｔｙｐｅ：これは常に最初のフィールドであり、ファイルの残部がどのような種類の情報を含んでいるかを記述している。その値は“ｒｅｇＦｉｌｅ”あるいは“Ｐｒｏｆｉｌｅ”である。
Ｅｕｄｏｒａ−Ｆｉｒｓｔ−Ｎａｍｅ：ＵＳ−ＡＳＣＩＩでの登録者のファースト（ギブン）ネーム。
Ｅｕｄｏｒａ−Ｌａｓｔ−Ｎａｍｅ：ＵＳ−ＡＳＣＩＩでの登録者のラスト（ファミリー）ネーム。
Ｅｕｄｏｒａ−Ｒｅｇ−Ｃｏｄｅ：登録システムにより生成された登録コード。
Ｐｒｏｆｉｌｅ：プロフィール情報。これは例えば１２７バイトのＡＳＣＩＩストリングのような比較的短い形態をとる。プロフィールは登録プロセス中に各ユーザに対して発生される。
Ｅｕｄｏｒａ−Ｎｅｅｄｓ−Ｒｅｇｉｓｔｒａｔｉｏｎ：このフィールドが“はい”を含んでいる場合には、ユーザはユードラのコピーを登録するように催促される。そのようにしなければソフトウェアプロバイダがそのデータベースに持たないＲｅｇＣｏｄｅを発生させるインストーラによりこれは使用される。
Ｍａｉｌｅｄ−ｔｏ：これは情報がメールされたアドレスである。このフィールドが存在し、ユーザのパーソナリティまたは“自分”ニックネームのいずれにも一致しない場合には、その情報に基づいて動作すべきではない。
【００５８】
Ｅｕｄｏｒａ−Ｆｉｌｅ−Ｔｙｐｅフィールドは存在していなければならないことに留意すべきである。先にリストアップされている他のフィールドは存在しても、あるいは存在していなくてもよい。
【００５９】
ユーザにメールされたＲｅｇＣｏｄｅは使用前に確認しなければならないことが理解できるであろう。使用するために、ＲｅｇＣｏｄｅは以下のテストを満たさなければならない。
【００６０】
・  有効性−無効ＲｅｇＣｏｄｅは無視すべきである。
・  直接性−ＲｅｇＣｏｄｅのＭａｉｌｅｄ−ｔｏフィールドはユーザのパーソナリティあるいはユーザの“自分”ニックネームの１つに対するアドレスを含んでいるべきである。
・  適用性−新しいＲｅｇＣｏｄｅは既存の有効なＲｅｇＣｏｄｅを自動的に無効にすべきではない。このポリシーに対する唯一の例外はペイウェアモードのＲｅｇＣｏｄｅがフリーウェアまたはアドウェアのＲｅｇＣｏｄｅを無効にすべきことであり、ユーザの既存のペイウェアモードのＲｅｇＣｏｄｅと同じであるペイウェアモードのＲｅｇＣｏｄｅを使用して“Ｅｕｄｏｒａ−Ｎｅｅｄｓ−Ｒｅｇｉｓｔｒａｔｉｏｎ”ナグをディセーブルにすることができる。
【００６１】
いったんＲｅｇＣｏｄｅが上記テストを満足することと決定されると、ユーザはこのコードを受け入れるように要請される。例示的な受け入れダイアログボックスが図１２に図示されている。
【００６２】
先に言及したように、１つの部分が他の部分の関数であることから、ＲｅｇＣｏｄｅは外部からの承認を必要としないものである。しかしながら、考慮すべき他の意味の“確認”がある。すなわちユードラの特定のバージョンとの使用に対してＲｅｇＣｏｄｅが“有効”であるかどうかである。これはＲｅｇＣｏｄｅ中の満了月と、ソフトウェアプロバイダがアプリケーション（プラグインや設定などにより上書きできない場所）に入れる設定月フィールドとを比較することにより達成される。満了月と設定月が対応する場合には、登録はｅメールクライアントにより有効であると見なされる。
【００６３】
図１４はフリーウェアユーザが登録済無料ユーザになることができるプロセスの状態フロー図を図示している。図７と図１４の状態フロー図は多くの観点において類似していることが理解できるであろう。しかしながら、図１４の状態フロー図は付加的なナグダイアログボックス、すなわち図１５に描かれているいわゆる機能ナグダイアログボックスがアドウェアおよびペイウェアのユーザに利用可能な拡張された機能を無料ユーザおよび登録済無料ユーザに気付かせることを可能にしている。フリーウェアユーザと登録済フリーウェアユーザに関して、登録済フリーウェアユーザは登録ナグダイアログボックスを受信しないことが理解できるであろう。フリーウェアユーザに人口統計情報を入力する代わりに完全機能を試みるオプションが与えられることを除いて、図１４に図示されている状態フロー図はアドウェアユーザ（図７）に適用可能なものに非常に類似していることが理解できるであろう。
【００６４】
この時点においてすべてのユーザは予め定められた間隔で（示されていない）更新ナグダイアログボックスを受信することにも留意すべきである。ユードラはｅメールセッション中に１週間に一度更新ページをチェックする。更新ページが変更されていた場合には、ユーザはユードラｅメールソフトウェアを更新するように催促される。ページが変更されていない場合であっても、ユーザは３０日のスケジュールで更新をチェックし、最新のソフトウェアバージョンを確実に持つように催促される。図１６の状態フロー図を参照。更新ナグは（もしあれば）ユーザにアップグレードする権利が与えられているバージョンをユーザに提示する。図１７参照。ナグ自体はユーザがダウンロードするためのユードラｅメールソフトウェアのバージョンへのリンクを持つＨＴＭＬ文書である。
【００６５】
図１８はボックスユーザが有料ユーザ、すなわちペイウェアユーザになることができるプロセスの例示的な状態フロー図を図示している。ソフトウェアプロバイダが特別にボックスユーザに提示する唯一のナグは登録ナグであることが理解できるであろう。いったんボックスユーザが登録すると、ボックスユーザは正規の有料ユーザにコンバートされる。しかしながらボックスユーザに対する支払期日はソフトウェアプロバイダにより特定の値にセットされるので、ソフトウェアプロバイダはボックスユーザがソフトウェアのどのバージョンを受信するかを、例えばユーザがソフトウェアプロバイダから無料で更新を受信する期間を制御することができることに留意すべきである。
【００６６】
ナグ（催促）の概念を導入したので、本発明にしたがったソフトウェア中で実現されるナグのさまざまな機能を説明するのに都合の良い時点である。２つの主な問題は（１）ソフトウェアプロバイダがどのようにユーザに催促するか、（２）ソフトウェアプロバイダがいつユーザに催促するかである。
【００６７】
ナグウィンドウはモードレスウィンドウであることが理想的である。ユーザはクローズボックスを使用してナグウィンドウを閉じることができ、あるいはアクション項目の１つをとることによりナグウィンドウを去らせることができ、あるいは単に開いたままにして、ナグウィンドウがウィンドウリスト中にあればどこへでもナグウィンドウをドリフトさせることができる。実現の制約のために、ウィンドウズのナグウィンドウはＭａｃＯＳのナグウィンドウと動作がわずかに異なる。このことを以下に説明する。ナグウィンドウはフローティングウィンドウである。ソフトウェアプロバイダはユーザがおそらくかなり短いオーダーでナグウィンドウを去らせることを予測する。しかしながらナグウィンドウはバックグランドタスクの実行を止めないことが理解できるであろう。
【００６８】
一度に開く各バラエティのナグウィンドウは多くて１つであり、同じバラエティの古いウィンドウをリサイクルすると有効であることに留意すべきである。すなわち、この次ユーザが催促される予定であるときに所定のナグウィンドウが依然として開いている場合には、そのウィンドウが再使用されて、ウィンドウスタックの一番上に戻される。ユーザに適用可能なすべてのナグはヘルプメニューからの選択によりユーザに利用可能であるので、ナグウィンドウの１つを不注意で去らせてしまったユーザは望む場合に自分自身に対して故意に催促できることにも留意すべきである。しなしながら、このような手動のナグ起動はナグタイマーをリセットしない。
【００６９】
ナグウィンドウは他のすべてのウィンドウの一番上に開かれることが好ましい。例えば“本日の情報”や他のダイアログボックスを含み、他のナグウィンドウを除いて、ユーザが手動でナグウィンドウより上に別の非ナグウィンドウを動かすまで、自動的に開かれるウィンドウはナグウィンドウより上に配置されない。ユードラｅメールソフトウェアのウィンドウズバージョンにおける実現の制約により、ナグを覆い隠すことができる唯一のウィンドウは他のフローティングウィンドウである。これは主にマルチ文書インターフェイス（ＭＤＩ）の子ウィンドウを最大化できるようにする要求によるものであることが理解できるであろう。それは、ウィンドウズプログラムマネージャのような、多くの人気のあるウィンドウズアプリケーションおよびユーティリティにより使用される標準的なウィンドウズインターフェイスや、ウィンドウズファイルマネージャであることに留意すべきである。ＭＤＩインターフェイスもＩＢＭによるコモンユーザアクセス（ＣＵＡ）標準セットの部品である。各ＭＤＩ準拠アプリケーションはテキストを編集する、データベースを管理する、スプレッドシートで作業するようなファイル特定のタスクに対して子ウィンドウを開いて可能性のあるタスクのいくつだけであるが指定することを可能にする。
【００７０】
図２０は本発明の例示的な実施形態にしたがったユードラｅメールソフトウェアのＭａｃＯＳバージョンにおけるナグウィンドウ表示に対するフローチャートを図示している。図２０では、シンボル（１）すなわち時間（１）により示されているように、ソフトウェアはちょうどインメールボックスを表している。ユードラｅメールソフトウェアはユーザに催促する必要があるかを決定し、シンボル（２）により示されているように、メールボックスの一番上にナグを置く。いくつかのメールが“フレッシュミート”メールボックスに到着する。通常、これは一番上で開く。しかしながら、ソフトウェアにより表示されている“新しい”ナグがあることから、すなわちいかなるものの後にもユーザが手動で移動させていないことから、シンボル（３）により示されているように“フレッシュミート”がその代わりにナグの下で開く。シンボル（４）により示されているように、ユーザは手動でフレッシュミートを前面に持ってくる。その後、メールがモアミートに到着したとき、ナグはもはや新しくなくなり、シンボル（５）により示されているように、モアミートは通常の方法により一番上で開くことができる。
【００７１】
何らかのウィンドウズ環境にナグウィンドウを配置することは一般的にかなり簡単である。ナグウィンドウはユーザがそれらを閉じるまで、他のフローティングウィンドウより上で、ＭＤＩボックスの外側に単に浮いている。全体的なマッキントッシュダイアグラムがＭＤＩボックス内で発生するとユーザが仮定した場合、このルールの例外は更新ナグであり、この更新ナグはＭａｃＯＳナグウィンドウのように機能する。これは更新ナグがウィンドウズ環境中で最大化されることがあることを示していることに特に留意すべきである。
【００７２】
ナグスケジュールの基本概念を先に紹介したが、この時点におけるナグスケジュールのさらに詳細な説明は本発明の例示的な好ましい実施形態にしたがったソフトウェアのある観点および機能を理解するのを助けるであろう。ユードラｅメールソフトウェアでは、各スケジュールは（最後を除けば）所定の期日（ナグベース）からの日数を表す１セットの数字である。ソフトウェアプロバイダはさらにユーザが催促を受けた最後の時（最後のナグ）を追跡しなければならない。ナグベースと最後のナグの両者は各タイプのナグに対して別々に追跡しなければならないことに留意すべきである。ソフトウェアプロバイダは例えば登録ナグと更新ナグに対する値を混合してはならない。ナグスケジュールの最後の数は反復間隔である。いったん他のナグがすべて使い尽くされると、ユーザはこの最後の数の日が経過するごとに催促される。
【００７３】
ナグスケジュールを理解するための最良の方法は、図２１に示されているようなタイムラインとしてスケジュールを見ることである。この特定のタイムラインは［０、４、９、１２、３］のナグスケジュールに対するものである。最後の数、すなわち（３日の）反復間隔が存在することから、１５日および１８日の時点に生じるナグが存在することに留意すべきである。したがって、図２１では、最後のナグよりも大きく、現在の日より小さいかあるいは等しいナグ日が存在する場合には、ユーザは催促される予定である。１つより多いナグ日が経過した場合、ユーザは依然として一度だけ催促される。
【００７４】
いったんナグウィンドウが開かれると、最後のナグが現在の日にリセットされることに留意すべきである。０の最後のナグ間隔は、規定されている期間が経過した後にそれ以上催促が行われないことを示していることにも留意すべきである。ユードラｅメールソフトウェアには、アプリケーションの開始時および各メールチェックの完了時に何らかの催促がなされることになっているか否かを決定するソフトウェアサブルーチンを含まれていると有効であることが理解できるであろう。後者のケースに関して、ソフトウェアはメールチェック中１週間に一度更新ページにおける修正期日をチェックする。更新ページが先週中に修正されていた場合には、ソフトウェアプロバイダはメールチェック中に更新情報をダウンロードし、自分のソフトウェア例えばユードラｅメールソフトウェアを更新するようにユーザに催促する。図１７参照。最後に、開かれているナグがもはや適切でないようにユーザの状態が変化したときには、ナグは閉じられ、もはや表示されないことに留意すべきである。
【００７５】
先の説明は広告に関するさまざまな問題についても簡単に触れている。これらの問題を直後にさらに詳しく説明する。特に、広告に関係する主なクライアント問題はソフトウェアがどのように広告を表示するか、ソフトウェアがいつ広告を表示するのか、ソフトウェアがどのようにして広告を獲得するのか、ソフトウェアプロバイダがどのようにして人口統計情報を獲得して送信するのか、ソフトウェアプロバイダはどのようにして広告が実際に表示されていることを確認するのかである。
【００７６】
図３を再度参照すると、ユードラｅメールソフトウェアのメインウィンドウはほぼ四角の広告とメインウィンドウの対向するコーナに３つの広告ボタンを示している。この特定のほぼ四角の広告は、１４４ピクセル高×１２８ピクセル幅であり、ソフトウェアは１４４ピクセル×１４４ピクセルと同じくらい大きい広告を受け入れることに留意すべきである。メールボックスにより使用可能なウィンドウの領域はほぼ３８％縮小されていることが理解できるであろう。しかしながら、コンテンツ領域は触れられないままであることも理解できるであろう。図４は代わりのメインウィンドウを図示しており、例えば下側の右コーナには小さいグラフィックあるいはプラカードが使用され、メインウィンドウがスポンサー付きであることを示している。
【００７７】
ソフトウェアプロバイダが広告主から受け取ることができる実際の情報は比較的簡単であることが理解できるであろう。図３の下側左手コーナに図示されているような標準的な広告に対して、広告は、１５Ｋよりも大きくなく、１４４ピクセル高×１４４ピクセル幅よりも大きくないＧＩＦファイルから構成される。このＧＩＦファイルはウェブセーフカラーパレットを使用することが好ましい。このパレットは時にはブラウザセーフパレットであり、８ビットにより規定可能な可能性ある２５６カラーのうち２１６カラーのみを含んでいる。残りの４０カラーはＭａｃおよびＰＣにおいて変化する。この４０の変化するカラーを無くすことにより、このパレットはクロスプラットフォームの使用に対して最適化される。さらに、ＧＩＦファイルは単一のユニフォームリソースネーム（ＵＲＮ）と関係していると有効であり、広告をクリックしたユーザがこのＵＲＮに向けられる。各広告主は以下でさらに詳細に説明するように、広告に対して所要のスケジュール情報も指定する。ソフトウェアプロバイダ例えばクゥアルコム・インコーポレーテッドに対して広告の送信を促進するために、広告主はＨＴＭＬ中に広告をラップしてもよい。ソフトウェアプロバイダはまたＨＴＭＬラップされた広告を使用することができると有効である。これはソフトウェアプロバイダが広告パラメータをＭＥＴＡタグとしてＨＴＭＬ中に含むことを可能とし、ソフトウェアプロバイダがリンクアドレスなどを指定することを可能にするからである。
【００７８】
さらに、ツールバーアイコンがその上ＧＩＦフォーマットで要求されるが、実際には混合フォーマットでクライアントに送られ、標準的なアイコンに変換される。さらに、図４に図示されているフリーウェアバージョンのスポンサーに対するプラカードは３１ピクセル高よりも大きくなく、８８ピクセル幅のオーダーとすべきであるが、正確な幅は実行時に変化させることができる。
【００７９】
ユーザが広告をクリックしたときに、ソフトウェアプロバイダは通常ユーザをソフトウェアプロバイダのクリックスルーカウンタに連れて行き、ユーザのブラウザを広告にリストアップされているリンクに向け直すことに留意すべきである。クリックスルーカウンタはソフトウェアプロバイダのサーバの１つ、例えばサーバ３０２および３０３の１つにできると効果的である。ソフトウェアプロバイダがサーバネーム、何らかの追跡情報、最終目的地ＵＲＮを含むＵＲＮを組み立て、サーバがユーザのブラウザを目的地ＵＲＮに向け直すことが理解できるであろう。
【００８０】
クリックスルーが試みられたときにユーザがオフラインである場合に、１つの複雑な状況が生じる。ユーザがオフラインであるとき、ソフトウェアによるいくつかの可能性あるアクションが起こりうる。例えば、ソフトウェアはオンラインセッションを開始することができる。代わりに、ソフトウェアは単にリンクヒストリーファシリティを使用してリンクにフラグを立てることができる。図２２および図２３を参照すると、ソフトウェアが維持しているウィンドウ／メニューが図示されており、これはほとんどのブラウザにより維持されているヒストリーリストと類似している。ソフトウェアがオフラインの間に広告がクリックされたときには、ソフトウェアはリンクをリンクヒストリーウィンドウに追加することが有効であり、ユーザは自分が前のｅメールセッション中にそのサイトを訪れることを望んだが不可能であったことが分かるように、このリンクにフラグを立てる。
【００８１】
さらに、ソフトウェアはユーザのブラウザがクリックスルーに応答するのを許容できるように構成されていると効果的である。ブラウザの中にはオフライン状態を処理するために独自の複雑な機能を持つものもあり、ソフトウェアプロバイダはユーザがそれらを信頼したいと思っているという認識を無視すべきでないことが理解できるであろう。代わりに、ソフトウェアはオンラインのときにおけるブラウザによる後のハンドリングのためにブラウザへのリンクの送信を許容してもよい。すなわちソフトウェアはユーザがソフトウェアプロバイダに対して次のオンライン時にリンクをユーザのブラウザに送信するように伝えることを許容することができる。
【００８２】
要約すると、ソフトウェアプロバイダは例示的で限定のないケースでは、広告主により提供されるすべての広告に対して以下の標準規格を要求する。
【００８３】
・  １４４×１４４ピクセルよりも大きくない。これよりも小さい広告は１４４×１４４ウィンドウの中央に配置され、標準的なフレームカラーで囲まれる。
・  ＧＩＦまたはＪＰＥＧ。ソフトウェアプロバイダはＧＩＦファイルをフォトショップ（ＰＮＧ）ファイルにコンバートできると有効であるが、これはトランスペアレントである。フォトショップにおけるガンマバグのために、ソフトウェアプロバイダは直接的に直ちにＰＮＧ広告を受け入れるものでないことに留意すべきである。
・  １５Ｋよりも大きくない。これは広告を送信するのに必要な帯域幅とともにユーザ帯域幅のグッドウィルコストを減少させる。
・  アニメーションなし。これは本発明の例示的な実施形態のユーザアスペクトに対する“控えめな”メッセージの基礎である。
・  ９００文字よりも多くない単一のＵＲＮ。ＵＲＮサイズに１Ｋの推測制限がある。カスタマのＵＲＮを９００文字に制限すると、ソフトウェアプロバイダがＵＲＮに注釈を付け、それでもなお１Ｋの制限内のままであることが可能となる。
・  ３１文字より多くないユーザフレンドリーなタイトルストリング。このストリングはリンクヒストリーウィンドウ中に表示され、ユーザが関係している何かであるべきである。
・  ウェブセーフカラーパレットを使用。先に述べたように、この２１６カラーパレットは２５６カラーシステムを持つユーザに対して最適化されている。
【００８４】
ツールバーボタンすなわち図３の上側の右手コーナのボタンは以下のことを除いて標準的な広告と同じ要求を持つことに留意すべきである。
【００８５】
・  １６×１６サイズおよび３２×３２サイズの両方が要求される。これらはクライアントがサポートするサイズであり、ソフトウェアプロバイダはその両方を必要とする。
・  ＧＩＦのみ。ソフトウェアはツールバー中ではＪＰＥＧ画像を描かない。
【００８６】
図４の下側右手コーナに図示されている共通ブランドスポット広告に関して、このスポットは以下のことを除いて標準的な広告と同じ要求を持つ。
【００８７】
・  ９５ピクセル幅×３１ピクセル高よりも大きくない。
・  ＧＩＦのみ。
【００８８】
図３に図示されている広告配置に関する１つの困難な問題は広告の真上に小さなウィンドウを配置することによりユーザが視界から広告を隠すことができることが比較的容易であることである。広告がスクリーン上にありかつカバーされていないことを決定するためにソフトウェアがチェックを実行することが効果的である。スクリーン状態がこれらの両基準を満たしていない場合には、ソフトウェアはユーザに催促して広告が覆われているのを止めさせ、あるいは自動的にウィンドウに再命令して広告が覆われているのを止めさせる。予め定められた期間に対してユーザが広告のカバーを持続する場合には、ソフトウェアは自動的にフリーウェアモードに移す。
【００８９】
ユードラｅメールプログラムのようなソフトウェアのアドウェアバージョンを提供するための主な理由の１つは広告主がソフトウェアのコストを助成することができるメカニズムを提供することであるから、すべてのユードラユーザが実際に広告を見ていることが確実であるようにソフトウェアプロバイダは明確に動機付けられる。他の方法を説明すると、例えばユーザが別の部屋にいる間にクライアントコンピュータ１００ａのスクリーン上に広告を表示することは、広告主に対する広告の費用を正当化しない。その理由のために、ソフトウェアには広告が提示されている間にユーザがコンピュータの前にいる実際の時間を測定できる機能が含まれている。
【００９０】
何らかの種類の目による決定的なファッシングデバイスがないことから、ソフトウェアがユーザの注意を測定することができる最良のものは、クライアントコンピュータ１００ａに対するユーザ入力を監視することであり、それにより表示装置２０８の前にユーザが存在することを確認する。クライアントコンピュータ１００ａに対する主要ユーザ入力装置がマウス２０４とキーボード２０３である場合には、ｅメールクライアントはユードラｅメールクライアントのアドウェアバージョンが最も前面にあるときにユーザによるマウスとキーボードの両者の操作を監視し、このアクティビィティを周期的に例えばソフトウェアプロバイダに報告する。言い換えると、マウスが大きく動いた場合、マウスボタンの状態が変化した場合、あるいはキーが押下または解放された場合にユーザが“存在し、アカウントされている”と考えられる。さらに、ソフトウェアは広告に対する“フェースタイム”としてこのような事象の前および後の期間を考慮する。本発明にしたがったソフトウェアの例示的なケースでは、ソフトウェアは期間を計測し、この期間のトータルの長さをｋフェイス間隔と呼ぶ。この値については過度に正確である必要はなく、説明している例示的な制限のないケースにおいて例えばユーザの事象により始まる６０秒のｋフェイス間隔を使用する。
【００９１】
ソフトウェアにより表示されている広告のフォーマットを説明したので、表示のために広告が実際に獲得される方法論の詳細な説明をこれから提示する。表示用広告を獲得するための一般的な方法論はメールチェック中、あるいはソフトウェアがライブネットワーク接続を検知した他の時間にクゥアルコム・インコーポレーテッドのサイトに接続し、広告をローカルキャシュにダウンロードすることである。個々のクライアントから請求書情報を集める必要をなくすために、広告をダウンロードする行為は、広告主に請求書を発行するトリガとすることができることが理解できるであろう。これに対して、ＪＵＮＯにより提供されるようなプロプラエタリシステムは、ユーザが何らかの理由のために自分のｅメールアカウントにアクセスしたときはいつでも、指定されたｅメールサーバに広告表示データをアップロードする。
【００９２】
広告をどのようにダウンロードするかについて妥当な決定を行うために、ソフトウェアプロバイダは広告ダウンロードがどのような影響をユーザに与えるのかについて何らかの考えを持つ必要がある。その影響を評価するために、ソフトウェアプロバイダは典型的なユードラユーザの習慣が何であるかについて、そして送信特性に関して広告は何に似ているのかについて仮定をしなければ（あるいは情報を集めなければ）ならない。ソフトウェアプロバイダが当て推量ではなくこれらの質問に対して理性的な回答を始めることができるように、アドウェアプロセスの一部はソフトウェアクライアントに計測を追加する。しかしながら、何らかの基本的な仮定で始めなければならない。例えば図２４はｅメールプログラム動作における広告送信の影響を決定する際に使用される仮定をリストアップしている表である。図２５は毎日加入者にダウンロードされるべき新しい広告数の帯域幅要求対加入者ベースの帯域幅要求をリストアップした表である。これらの計算の関係は次の通りである。目的が平均に対するもので、広告のターンオーバーが例えば３日である場合、図２５に図示されている表の一番上の行がソフトウェアプロバイダにより使用されるものとなる。最悪のケースすなわち最大帯域幅のシナリオは例えば２５広告を１日でターンオーバーさせることになる。これらの値は図２５において強調されている。
【００９３】
特定のユーザクラスに対してどの広告を示すべきかを決定するためとともに、特定の広告パラメータを送信するために、ソフトウェアプロバイダはプレーリストを使用すると効果的である。プレーリストは本質的にＵＲＮのリストであり、このＵＲＮから広告ごとのベースで実際の広告とともに１セットの属性値対をフェッチする。プレーリストの正確なフォーマットをまもなく詳細に説明する。直後に説明するように、プレーリストはクライアントが持つべき完全なセットの広告を特定するとともに、これらの広告を表示するためのパラメータも特定する。広告はプレーリスト中に現れるが、長い間表示するために（あるいはまったく）スケジューリングされないことに留意すべきである。プレーリスト中のこのような広告の存在は、将来の表示用にクライアント上に記憶させるためにクライアントに広告を引き出させる。プレーリストに対する一般的な要求は次の通りである。
【００９４】
１）プレーリストに対する要求は、どの広告をフェッチするようにユードラのコピーが要求されるかについてプレーリストサーバが決定するのを助ける情報を含む。
２）プレーリストは全体としてユードラに対するパラメータも含むことができ、これにはどれくらいの頻度で新しいプレーリストをチェックするかを修正する能力が含まれている。
３）プレーリストには、すべてのより古いプレーリストをこのプレーリストで置換するべきであるか否か、あるいはこのプレーリストと単に併合させるべきであるか否かを指定することが許容されている。このようなモデルを用いることをソフトウェアプロバイダが選択した場合には、併合機能はさらにウェブのような広告モデルを、例えば広告プールを回転させることを使用するモデルを許容することに留意すべきである。
【００９５】
図２６および図１を参照して基本的な広告フェッチプロセスをこれから説明する。図２６は本発明にしたがった例示的な広告フェッチプロセスの状態フロー図である。最初に、クライアントコンピュータ１００ａ上で実行されているクライアントソフトウェアはそれ自身をプレーリストサーバ３０２、例えばａｄｓ．ｅｕｄｏｒａ．ｃｏｍに結びつける。クライアントソフトウェア例えばユードラソフトウェアはプレーリストサーバ３０２に基本的なクライアント情報と、クライアントソフトウェアが現在インストールしているプレーリストのＩＤを提供する。ａｄｓ．ｅｕｄｏｒａ．ｃｏｍサーバは現在のプレーリストがいまなお有効であるとの表示で応答し、クライアントを異なるプレーリストサーバ例えば別のプレーリストサーバ３０２’に送信するために方向を向け直すハイパーテキストトランスファプロトコル（ＨＴＴＰ）を使用するか、あるいはプレーリストサーバ３０２からの新しいプレーリストで直接応答する。図２６参照。新しいプレーリストがプレーリストサーバ３０２から受信されたとき、クライアントソフトウェアは新しいプレーリストをその現在のセットの広告と比較し、プレーリストに含まれているＵＲＮにしたがって、さらに多くの広告サーバの１つから例えば図１に図示されている広告サーバ３０３から、ｅメールクライアントの広告キャッシュに存在しない広告をフェッチし始める。クライアントソフトウェアはまたプレーリスト中に現在現れていない広告を削除する。
【００９６】
クライアントソフトウェアは３日ごとに新しいプレーリストに対するチェックを実行すると効果的である。プレーリストチェック間の３日の間隔は任意であり、説明している本発明の例示的な好ましい実施形態にのみ適用可能であることに留意すべきである。おそらく多くのメールチェックに対して、プレーリストを満たすために必要とされる場合に広告がフェッチされることが好ましいことにも留意すべきである。さらに、ｅメールクライアントソフトウェアまたはクライアントコンピュータ１００ａのいずれのタスクにかかわらず、広告フェッチプロセスはメールチェックごとに１分に制限される。１分後、クライアントソフトウェアは広告サーバ３０３から接続を切る。これは広告フェッチ動作が終了したときにｅメールクライアントソフトウェアがプレーリストを満たしていないことを意味することが多い。これは許容可能である。ソフトウェアは残りの広告がダウンロードされている間に利用可能な広告を利用する。
【００９７】
さらに、ソフトウェアプロバイダはａｄｓ．ｅｕｄｏｒａ．ｃｏｍサーバ３０３と同等な複数のサーバを提供することができると有用である。これらのサーバはいくつかのユードラユーザコミュニティに対して、例えば１つのＩＳＰによりサービスされる会社のすべてのユーザなどに対して追加的な広告を提供することが理解できるであろう。他の方法を説明すると、近距離および長距離電話アクセスのような付加的なサービスを提供するＩＳＰは自身のカスタマベースに対してこれらのサービスをクロスプロモートしたいかもしれない。したがって、ＩＳＰはこのような局地化されたプロモーションを請け負うことができると有効である。ＩＳＰブランドのアドウェアｅメールクライアントに送信されるプレーリストは、この例でのＩＳＰにより維持される広告サーバ３０３’’にリンクされる。
【００９８】
１セットの利用可能な広告が与えられると、ソフトウェアはどの広告を次に表示するかを依然として選択する必要がある。これは伝え聞くところでは広告主の利益を最大にするために多くの選択がなされるウェブ広告業界において非常に刺激的なことであることが理解できるであろう。特に、さらに良いユーザ応答を発生させる広告が好ましい。その理由はこのような広告は追加的な収益を発生させるからである。すなわちこのような広告が表示されるウェブページのコンテンツにこのような広告が頻繁に結びつけられるからである。しかしながら、ソフトウェアプロバイダまたはクライアントソフトウェアのいずれかが、広告サービス上で現在実行されている広告スケジューリングアルゴリズムから大きな利益を得ることができる見込みはない。これは一部にはｅメールクライアントソフトウェアにより表示されている広告が、表示されているコンテンツから分離されているという事実によるものである。すなわちソフトウェアプロバイダまたはクライアントソフトウェアのいずれもユーザが見ている特定の広告のコンテンツを認識していないという事実によるものである。またこれは一部にはｅメールクライアントソフトウェアが“リアルタイム”で広告を要求しているのではなく、後の表示のためにバッチで広告を要求しているという事実によるものである。
【００９９】
先に述べたように、プレーリストはいくつかのグローバル入力を広告スケジューリングアルゴリズムに提供し、これには直後の表にリストアップされているパラメータを含まれている。
【０１００】
パラメータ：ＦａｃｅＴｉｍｅＱｕｏｔａ
説明：ｅメールクライアントソフトウェアが広告を示すことが想定されている１日当たりの時間量。
パラメータ：ＲｅｒｕｎＩｎｔｅｒｖａｌ
説明：“ランアウト”後にすなわち最大許容可能な時間が経過した後にこの期間を超えて広告を“再実行”すべきでない期間。
【０１０１】
さらに、広告スケジューリングに関係するプレーリスト中の広告ごとの入力を以下の表に示す。
【０１０２】
パラメータ：ＳｈｏｗＦｏｒ
説明：これは任意の所定時間に対して広告を示すべき秒数である。この数はＴＶ広告（例えば３０）のように小さくてもよく、あるいはビルボード（例えば、１時間に対して３６００、中断なし）のようにさらに大きくてもよい。
パラメータ：ＳｈｏｗＦｏｒＭａｘ
説明：この広告を示すための最大総時間。広告はこの時間後使い尽くされ、いったん新しい広告が到着すると廃棄すべきである。
パラメータ：ＤａｙＭａｘ
説明：この特定の広告を示すための１日当たりの最大回数。
パラメータ：ＢｌａｃｋＢｅｆｏｒｅ
説明：広告が表示される前に広告ウィンドウをブランクにすべき時間量。
パラメータ：ＢｌａｃｋＡｆｔｅｒ
説明：広告が表示された後に広告ウィンドウをブランクにすべき時間量。広告間の実際の時間が最大（ＢｌａｃｋＡｆｔｅｒ、ＢｌａｃｋＢｅｆｏｒｅ）であるように、ＢｌａｃｋＡｆｔｅｒは次の広告のＢｌａｃｋＢｅｆｏｒｅと同時に進み、ＢｌａｃｋＡｆｔｅｒ＋ＢｌａｃｋＢｅｆｏｒｅではない。
パラメータ：ＳｔａｒｔＤＴ
説明：この日付／時間より前に広告を実行すべきでない日付／時間（タイムゾーンはオプション）。
パラメータ：ＥｎｄＤＴ
説明：この日付／時間より後に広告を実行すべきでない日付／時間（タイムゾーンはオプション）。
【０１０３】
ソフトウェアプロバイダが計算するいくつかの値があり、これもスケジューリングアルゴリズムに入力される。これらのグローバル値は以下の表にリストアップされている。
【０１０４】
パラメータ：ＡｄＦａｃｅＴｉｍｅＴｏｄａｙ
説明：正規の広告が示されている現在の日に対する広告フェースタイムの総量。
パラメータ：ＴｏｔａｌＦａｃｅＴｉｍｅＴｏｄａｙ
説明：現在の日に対するフェースタイムの総量。
【０１０５】
ソフトウェアはまたこれらの値を追跡し、各広告についてこれらの値をソフトウェアプロバイダに報告する。
【０１０６】
パラメータ：ＮｕｍｂｅｒＳｈｏｗｎＴｏｄａｙ
説明：現在の日に示されている広告の回数。
パラメータ：ＴｈｉｓＳｈｏｗＴｉｍｅ
説明：現在の広告が受信されているフェースタイムの量。
パラメータ：ＬａｓｔＳｈｏｗｎＤａｔｅ
説明：ｅメールクライアントソフトウェアがこの広告を示した最後の日付／時間。
【０１０７】
ソフトウェアプロバイダは広告スケジューラの３つの主要状態、正規状態、ランアウト状態、および再実行状態を実現すると効果的である。正規状態では、ｅメールクライアントソフトウェアは正規の広告を表示し、それらをアカウントしていると効果的である。これはｅメールクライアント上に表示される広告の容量に対する課金を実際に発生させるものであることが理解できるであろう。これに対して、ランアウト状態はｅメールクライアントソフトウェアが十分な正規の広告を示して割り当てられたＦａｃｅＴｉｍｅＱｕｏｔａを満たしたときに選択され、広告キャッシュには表示するために利用可能な１つ以上のランアウト広告が含まれている。再実行状態では、ｅメールクライアントソフトウェアはその正規広告の規定量とランアウト広告の両方を使い果たし、すなわちｅメールクライアントソフトウェアは今は正規の広告を再表示しているが、ソフトウェアプロバイダはそれらに対して課金していない。
【０１０８】
ここで、ソフトウェアプロバイダが、配信されたユードラのコピーにラベルまたはブランドを付けるさまざまなＩＳＰ、本の出版社などにカスタムインストーラを提供できると効果的であることに留意すべきである。ソフトウェアプロバイダは、ディストリビュータが配信したクライアントにより発生した広告収益のパーセンテージでこれらのディストリビュータに信用貸しをする。これらの信用貸しは、先に説明した理由のために、アドウェアｅメールクライアントのそれぞれブランド付けられたバージョンに関係するクロスプロモーションアクティビィティにより相殺されることが理解できるであろう。
【０１０９】
直前の説明を行ったことにより、本発明にしたがった例示的なｅメールクライアントソフトウェアのさまざまな観点のさらに詳細な説明をこれから行うことができる。
【０１１０】
先に着目したように、プレーリストはソフトウェア中、例えばユードラｅメールソフトウェア中の広告のフェッチおよび表示を制御する方法である。プレーリストに関係する主な利点は、ユーザの登録または中央化ユーザデータベースを要求することのない、広告画像からの広告パラメータの分離、広告画像サーバの詳細な知識からのユードラクライアントの離隔、広告配信における中央化サーバ知能である。したがって、プレーリストは極めて柔軟なオブジェクトであることが理解できるであろう。例示的なケースでは、ユードラが実行する正確なセットの広告を特定して自己の広告を選択するアブストラクトＵＲＮを単に送信することから、プレーリストはユードラクライアントがどのように動作するかについて異なるレベルの制御を発揮することができる。プレーリストが最大の利点に対して使用される場合、プレーリストはソフトウェアプロバイダにユードラのようなソフトウェア中の広告表示を制御するパワフルなツールを与える。プレーリストが後に不適切であると考えられると、プレーリストはソフトウェアプロバイダに１日当たり１つの余分な短いネットワーク接続を費やさせる。
【０１１１】
図１および図２６に関して先に説明したように、クライアントコンピュータ１００ａはネットワーク２００を通して（異なるサーバ３０２’に向け直す）プレーリストサーバ３０２に接続される。そして、プレーリストサーバ３０２はネットワーク２００を通してプレーリストをクライアントコンピュータ１００ａに返す。その後、クライアントコンピュータ上のｅメールクライアントソフトウェアはプレーリスト中で指定された広告をフェッチする。
【０１１２】
広告フェッチプロセスを開始するために、ユードラクライアントからプレーリストサーバ３０２に送信されるプレーリスト要求は、バイナリコードの簡単なバーストではない。プレーリスト要求はユーザのために適切なプレーリストを作るまたは選択するために十分な情報をサーバ３０２に提供するために使用されるイクステンシブルマークアップラングエッジ（ＸＭＬ）コードのブロックである。プレーリスト要求中のこの情報を以下の表に示す。
【０１１３】
パラメータ：ＵｓｅｒＡｇｅｎｔ
説明：これは、プレーリスト、そのバージョン番号、および実行されているプラットフォームを要求するアプリケーションを識別するストリングである。
パラメータ：ＰｌａｙＬｉｓｔ
説明：これはクライアントが現在使用しているプレーリストを識別する。これはクライアントが１つより多いプレーリストを片づけている場合には複数の値を持つ。
パラメータ：Ｅｎｔｒｙ
説明：このクライアントにより最近示された広告のＩＤのリストである。エントリはそれらが属しているプレーリストの内部に入れ子にされる。各エントリは以下の関係する属性またはタイプのゼロまたはそれ以上のものを持つことができる（等号（＝）に続く番号は属性に付加された例示的な値を示しており、以下に提供されているエントリ属性の説明を行うために使用されている）。
説明：Ａｃｔｉｖｅ＝“０”：広告はもはや示されていない。
説明：ＩｓＲｕｎｏｕｔ＝“１”：広告はランアウト広告である。これはサーバが広告上でルックアップしなければならないことをセーブする。
説明：ＩｓＳｐｏｎｓｏｒ＝“１”：広告は、クゥアルコムロゴの代わりに示されるべき、スポンサー付き広告である。図４参照。
説明：ＩｓＢｕｔｔｏｎ＝“１”：広告はツールバーボタンである。
説明：Ｄｅｌｅｔｅｄ＝“１”：広告はユーザにより隠されている。これはツールバー広告に対してのみ許容されている。
説明：ＦａｃｅＴｉｍｅ：これは最後の７カレンダー日でユーザが使用したフェースタイムの量をリストアップしている。これはクライアントがいくつ広告を表示できそうかをサーバが決定することを可能にする。現在の日に対する値は今日の値（ＦａｃｅＴｉｍｅＵｓｅｄＴｏｄａｙ参照）と今日に対する先週の値のうちより大きいものである。
説明：ＦａｃｅＴｉｍｅＬｅｆｔ：これはクライアント広告キャッシュに依然として残されている広告により要求されるフェースタイムの総量である。
説明：ＦａｃｅＴｉｍｅＵｓｅｄＴｏｄａｙ：これは今日表示されている広告に向けてクライアントが使用したフェースタイムの量である。これは日付の厳しい広告を今日示すことができるか否かをサーバが決定するのに使用することができる。
説明：ＤｉｓｔｒｉｂｕｔｏｒＩＤ：ユードラのこのコピーを配信したＩＳＰまたは他の団体に対する手数料またはさもなければ報酬をプレーリストサーバが識別し、信用貸しできるように、このＩＤは報奨金システムに対して使用される。
説明：Ｐａｓｔｒｙ：これはプレーリストサーバが過去にユードラｅメールクライアントに与えていたクッキーである。これはサーバがセーブしたい任意の状態情報／設定を含むことができる。
説明：Ｐｒｏｆｉｌｅ：ソフトウェアプロバイダウェブページに元々入力され、その後／同時にｅメールクライアントに記憶されたプロフィール情報。
説明：Ｓｃｒｅｅｎ．ｈｅｉｇｈｔ：広告が示されているディスプレイのピクセルでの高さ。
説明：Ｓｃｒｅｅｎ．ｗｉｄｔｈ：広告が示されているディスプレイのピクセルでの幅。説明：Ｓｃｒｅｅｎ．ｄｅｐｔｈ：広告が示されているディスプレイの、ピクセルごとのカラー／ビットでのカラーの奥行。
説明：ＰｌａｙＬｉｓｔＶｅｒｓｉｏｎ：この特定のクライアントにより使用されるプレーリストルーチンのバージョン番号。
【０１１４】
これらのパラメータのすべてがおそらく同時にアクティブに使用されるわけではないことが理解できるであろう。いくつかは特定の動作モードをサポートするために存在し（以下を参照）、他のものでは使用されない。ここで、すべてのプレーリスト要求はＭＤ５によりチェックサムがとられることに留意すべきである。ＲＦＣ１３２１を参照−“ＭＤ５メッセージ−ダイジェストアルゴリズム”はｈｔｔｐ：／／ｗｗｗ．ｆａｃｓ．ｏｒｇ／ｒｆｃｓ／ｒｆｃ１３２１．ｈｔｍｌにある。プレーリストサーバ３０２はチェックサム確認に失敗した要求を無視することが好ましい。
【０１１５】
クライアントがプレーリスト要求を行った後、サーバ３０２はプレーリスト応答で返事をする。プレーリスト応答は２つの主要セクションに分割されることが好ましい。１つはクライアント情報セクションであり、広告に関する一般的なクライアント動作、すなわち広告がターンオーバーする速さを更新し、他の１つはプレーリスト自体であり、クライアントがフェッチすべき広告を記述している。プレーリストサーバ例えばサーバ３０２は空の応答も返し、これはｅメールクライアントが既に持っている広告でこれまでの方向を続けるべきであることを意味していることに留意すべきである。ちょうどプレーリスト要求のように、すべてのプレーリスト応答はＭＤ５によりチェックサムがとられることにも留意すべきである。ＭＤ５ダイジェストは１６進法でエンコードされ、プレーリスト応答の“チェックサム”ヘッダに入れられる。ｅメールクライアントはチェックサム確認に失敗したプレーリストを無視することが効果的である。
【０１１６】
プレーリスト応答のセクションを説明する前に、ｅメールクライアントはより良い表現がないためにあえて言えば、古いクライアントのバグ、サーバのバグなどにより混乱するようになることが多いことに留意すべきである。更新されたクライアントによってさえ受け継がれる悪いデータはシステムを適切に機能させるためには余りにもガーブル状態になることが多い。この状態を検出するようにクライアントをプログラムすることは可能であるが、タスクすなわちエラー検出を、さらに容易に変更できるサーバに残しておくことが好ましい。したがってクライアントが“混乱”していることをサーバが検出したとき、プレーリストサーバ３０２はたった１つのコマンド、リセットで応答する。クライアント情報はこれに続くべきではない。プレーリストはこれに続くべきではない。まさにリセットコマンドのみである。リセットコマンドを受信したとき、クライアントはその蓄積した広告データベースを廃棄し、プレーリスト、フェースタイムヒストリー、広告ヒストリー、広告キャッシュなどを含むものを記録する。アドウェアソフトウェアがまさに最初に実行される前にｅメールクライアントソフトウェアが持っていた元の状態にすべてがリセットされる。実地的な理由と、リンクヒストリーはユーザが見ることができるという理由の両方のために、リンクヒストリーはリセットコマンドから免除されることに留意すべきである。リセットが影響を及ぼさない広告データの他の唯一の項目は広告失敗カウンタである。この広告失敗カウンタはリセットにわたって維持すべきである。クライアントはプレーリストがなく、必要とされるプレーリストに対する別の要求をプレーリストサーバに行うことを認識すべきである。
【０１１７】
クライアント情報セクションはさまざまなクライアントパラメータを更新する。これらのパラメータを直後にリストアップする。
【０１１８】
パラメータ：ＲｅｑＩｎｔｅｒｖａｌ
説明：これは新しいプレーリストに対するチェックをする前にクライアントが待つべき時間数である。広告のターンオーバーが高い場合には、これは小さな数となる。１週間に一度あるいは１ヶ月に一度だけ新しいプレーリストに対するチェックがなされるように、スポンサー付きフリーウェアバージョンはここではかなり高い数を持つ。クライアントはゼロでないＳｈｏｗＦｏｒＭａｘ値を持つ広告を持ち、広告が多くの時間を使い果たしている場合も、新しいプレーリストをチェックする。
パラメータ：ＨｉｓｔＩｎｔｅｒｖａｌ
説明：この値は特定の広告を示したとクライアントが覚えていなければならない日数である。サーバが自由裁量でその特定のクライアントに対して競合するサービスの広告を表示する命令をしないことを選択できるように、クライアントはこれをプレーリストサーバに報告する。競合する広告はＨｉｓｔＩｎｔｅｒｖａｌ値により互いに分離される。
パラメータ：Ｐａｓｔｒｙ
説明：先に言及したクッキー。サーバは要求するどのような状態の情報もこのクッキーに記憶することができる。
パラメータ：Ｆｌｕｓｈ
説明：存在する場合、パラメータよりはコマンドがクライアントに古いプレーリストまたは広告を廃棄させる。フラッシュされた広告とプレーリストは完全に取り除かれ、もはや広告ヒストリーに現れない。
パラメータ：Ｗｉｄｔｈ
説明：クライアントが作るべき広告ウィンドウのピクセルでの幅。
パラメータ：Ｈｅｉｇｈｔ
説明：同じもののピクセルでの高さ。
パラメータ：ＦａｃｅＴｉｍｅＱｕｏｔａ
説明：ランアウト広告に移行させる前に、クライアントが正規の広告に対して振り向けるべきフェースタイムの秒数。
パラメータ：ＲｅｒｕｎＩｎｔｅｒｖａｌ
説明：広告が“再実行”される日数。すなわちすべての他の広告とランアウト広告が使い果たされた後に無料で示される日数。この時間は広告の最後の非再実行表示から測られる。
【０１１９】
先の説明から、クライアント情報セクションはプレーリストのパワフルな機能であることが理解できるであろう。これはソフトウェアプロバイダがグローバルな方法でアプリケーションを制御することを可能にし、これには１つの広告モデルから他の広告モデルに間をおかずにスムーズに移行することが含まれる。ソフトウェアプロバイダがプレーリストから導出した唯一の利点がこれである場合には、これのみでプレーリストを実現する価値があることが理解できるであろう。
【０１２０】
先に説明したように、プレーリスト応答は２つの主要セクションに分割される。１つはクライアント情報セクションであり、一般的なクライアントの動作を更新し、もう１つはプレーリスト自体であり、クライアントがフェッチすべき広告を記述している。プレーリスト自体は１つのグローバル値、ＰｌａｙＬｉｓｔＩＤを持つ。このＩＤはクライアントコンピュータ１００ａがプレーリストサーバ３０２に次に接続したときにクライアントがプレーリストサーバに返すＩＤ値である。プレーリストの残りは広告のリストである。各広告は多くのパラメータを持つことが許容されているが、任意の単一広告でそれらのすべてが使用されそうもなく、それらのいくつかはまったく使用されない可能性がある。パラメータにはスケジューリングパラメータが含まれ、これらは先に詳細に説明した。またパラメータには広告情報が含まれ、この広告情報には直後にリストアップした情報が含まれている。
【０１２１】
パラメータ：ＡｄＩＤ
説明：問題となっている広告に対する独特な識別子。６４ビット整数であり、その上位３２ビットはサーバのオーソリティＩＤであり、下位３２ビットはサーバオーソリティに独特な識別子である。
パラメータ：Ｔｉｔｌｅ
説明：その広告に言及するために使用されるヒューマンフレンドリーなストリング。
パラメータ：Ｓｒｃ
説明：表示すための実際の広告を獲得する場所を示すＵＲＮ。これはかなり特有なものであるか（例えばｈｔｔｐ：／／ｍｅｄｉａ４８．ｄｏｕｂｌｅｃｌｉｃｋ．ｎｅｔ／ｅｕｄｏｒａ／ｃｏｋｅ／ｄｒｉｎｋｃｏｋｅ．ｇｉｆ）、あるいはさらに一般的なもの（例えばｈｔｔｐ：／／ａｄｓ．ｄｏｕｂｌｅｃｌｉｃｋ．ｎｅｔ／ｅｕｄｏｒａ／ａｄ；ｏｒｄ＝１３６７８４４２１？）であってもよい。他の重要なプレーリスト機能は、クライアントソフトウェアが多くの異なるサーバから広告を引き出すことをプレーリストが許容することである。ソフトウェアプロバイダは例えばＤｏｕｂｌｅＣｌｉｃｋに属しているサーバと並行に自己のサーバを実行することができ、プレーリストに基づいて、各サーバまたはサーバのいくつかから広告を取り出す。Ｓｒｃタグ上にチェックサム属性が存在する場合がある。存在する場合には、その値は広告データの１６進数エンコードＭＤ５ダイジェストである。クライアントは広告データに対してこのチェックサムをチェックしてもよい。
パラメータ：ＩｓＢｕｔｔｏｎ
説明：この“広告”はツールバーボタンであるのか。そうである場合にはメイン広告から独立してスケジュール調整される。ツールバーボタンに対して意味のある唯一のスケジューリングパラメータはｓｔａｒｔＤＴおよびｅｎｄＤＴである。
パラメータ：ＩｓＳｐｏｎｓｏｒ
説明：この“広告”はスポンサープラカードであるのか。そうである場合にはメイン広告から独立してスケジュール調整される。
パラメータ：ＩｓＲｕｎｏｕｔ
説明：他のすべての広告が所定日に対する実行を終わった後にこの広告が実行されることが予定されているか。１つのアクティブＩｓＲｕｎｏｕｔのみがプレーリストの任意のクライアントのコレクションに存在する。
パラメータ：ＵＲＮ
説明：ユーザが広告をクリックしたときにユーザが向けられるサーバのユニフォームリソースネーム（例えばウェブサイトアドレス）。
【０１２２】
用語ユニフォームリソースネーム（ＵＲＮ）は、インターネットを通して利用可能なリソースに関係する短いストリングであるすべてのネーム／アドレスの包括的なセットを示していることに留意すべきである。したがって、ＵＲＮはユニフォームリソースロケータ（ＵＲＬ）とユニフォームリソース識別子（ＵＲＩ）の両方を含む。ＵＲＬはインターネット上の特定のリソースをどのようにアクセスするかについて明確な命令を持つＵＲＮスキームのサブセットである。ＵＲＩはＵＲＮの他のサブセットである。ＵＲＬとＵＲＩのサブセットは部分的にかさなってもよいことが理解できるであろう。用語ＵＲＮ、ＵＲＬおよびＵＲＩは交換可能に使用できると有効であることも理解できるであろう。どの用語が使用されても、可能性がある最も広い意味で、ネームが付けられたリソースを取り扱わなければならない。
【０１２３】
ちなみにすべてのパラメータが一度に使用されそうもないことにすでに言及した。実際、プレーリストは多くの広告モデルをサポートするのに十分柔軟性がある。プレーリストはいくつかの広告モデルにとっては不可欠であり、他の広告モデルにとっては役に立つが中心的でなく、さらに他の広告モデルにとっては少しだけ役に立つが、大きな障害を示さない。プレーリストの使用はソフトウェアプロバイダを何らかの特定広告モデルに傾かせない。ソフトウェアプロバイダが選択した任意の広告モデルをサポートするためにプレーリストを使用できると有用である。実際、ソフトウェアプロバイダがそのようにすることを決定した場合、プレーリストはソフトウェアプロバイダが広告モデル間を途中で切り換えることを許容する。以下の説明では、各広告モデルに対してどのようにプレーリストが使用されるかを示すための努力において、図３５および図３６に関していくつかの広告モデルを説明する。これは広告モデルに対してプレーリスト概念は完全な中立状態であることを示すことが理解できるであろう。
【０１２４】
図３５は持続的な広告に関係する広告モデルを図示しており、図３６は短命の広告モデルに関係するパラメータを図示している。ここで着目する１つのことは任意のセクションからの数個のパラメータがどのようにチャートに現れるかである。５個程度のパラメータを変化させることにより、アドウェアがこれらの２つの異なる広告モード間でシフトするようになると効果的であることが理解できるであろう。すなわち、それらのほとんどが広告モデルの選択に関係していないからである。パラメータは広告モデルにかかわらず使用されるかあるいは使用されない。例えば、ソフトウェアプロバイダは任意のモデルにおける広告の後にブランクスペースを実現することができ、ソフトウェアプロバイダは任意のモデルにおける広告の後にブランクスペースを入れるのを避けることができる。ほとんどのパラメータはこの重要な問題でないカテゴリに入る。
【０１２５】
短命の広告モデルに関して、ソフトウェアプロバイダが、多くの広告主または数人の広告主のみから、多くの広告を受け入れることが理解できるであろう。広告は多くの日に対して持続しないことから、比較的早いレートで使い果たされ、廃棄される。このモデルでは、プレーリストは追加的に使用される。クライアントが広告を使い果たすごとに、クライアントの既存の広告と混合するためにさらに数種の広告を記述する他のプレーリストを請求する。広告が割り当てられた時間を超えると、広告は廃棄される。この広告モデルでは、プレーリストサーバは実際広告用のパラメータを送信するためにのみ機能する。しかしながら、結局パラメータを何とかして送信しなければならないことから、これは許容可能なことである。
【０１２６】
ソフトウェアプロバイダが広告モデルを混合したい場合を考えると、例えばソフトウェアプロバイダが長い実行期間の広告と短命の広告の混合を提供したい場合を考える。この状況をどのように取り扱うかは化学量論に基づく。キャッシュの大部分が持続性の広告で、そしてわずかに短命の広告のみで満たされた場合、ソフトウェアプロバイダは単にＲｅｑＩｎｔｅｒｖａｌを増加し、持続性広告モデルにおける場合と同じようにプレーリストを使用することができる。言い換えると、ソフトウェアプロバイダは単にいくつかのランダムな広告を選んで、各プレーリストに入れ、さらにいくつかのランダムな広告を選んで、次のプレーリストに入れる。この次のプレーリストは翌日クライアントがフェッチするものである。他方、キャッシュが大部分短命の広告を含み、わずかな持続性広告のみを含む場合には、コンピュータシステム１０は複数のプレーリストを使用する。１つのプレーリストは先に説明したように持続性の広告をリストアップし、残りのフェースタイムは短命広告のプレーリストを使用して満たされる。
【０１２７】
先の説明は幅広い異なる広告モデルをサポートするためにプレーリストをどのように使用することができるかを示している。プレーリストがこれを行うことができる理由は、プレーリストは、実際ユードラとその広告との間における余分なレベルのサーバ制御に過ぎないからである。
【０１２８】
広告の重要性がアドウェアｅメールソフトウェアに対して与えられると、ソフトウェアプロバイダの重要な懸念事項は“アドウェアが広告を受信していない場合に何が起こるか”である。例えば、ユーザまたはＩＳＰはファイアウォールまたは他の手段を使用してユードラへの広告の流れを単にシャットオフするかもしれない。これが起きると、ユーザは広告を見ることなく、あるいは支払をすることなく、ユードラの完全機能バージョンを獲得するかもしれない。これは本発明にしたがった例示的なソフトウェアの１つの重要な観点を無効にする。一方、ユーザはハードウェアまたはソフトウェア問題、あるいは広告をフェッチするのを抑制する他の問題を持っているかもしれず、あるいはソフトウェアプロバイダの広告サーバは何らかの理由のためにダウンさえするかもしれない。ユーザはこのために責められるべきではない。
【０１２９】
ソフトウェアプロバイダは簡単な質問、すなわちユーザはメールを送信または受信しているのかを尋ねることにより、これらの２つの状況間を区別する。答えがはいの場合、広告がブロックされていることはソフトウェアプロバイダが取り扱う必要があるものであるとソフトウェアプロバイダは仮定する。ソフトウェアプロバイダがこの問題を取り扱う方法は、エスカレートする一連の広告失敗ナグによる。これらは２週間の間、あるいはソフトウェアが広告を受信するまで続けられる。２日ごとにソフトウェアは広告を受信し、ソフトウェアは広告失敗ナグタイマーを１日だけ減少させる。タイマーが終わった場合には、ソフトウェアはユーザに対してお詫びを表示し、フリーウェアバージョンに戻り、デッドビートユーザにより所有されているとしてユーザのソフトウェアにマークを付ける。デッドビートユーザは、ユーザがアドウェアに戻ろうとする時間に広告サーバに接続できる場合のみに、アドウェアに戻ることが許される。図３７ないし図３９参照。
【０１３０】
ソフトウェアプロバイダがユードラから退却する決定を行い、広告なしで人々にそれを使用させることを望むのであれば、ソフトウェアプロバイダは単に永久的な登録コードを公表することができることに留意すべきである。
【０１３１】
ソフトウェアプロバイダが知らなければならないものの１つは、ソフトウェアプロバイダが表示されていると思っている広告が実際に表示されていることであり、したがって頻繁にそして広告が表示されているとソフトウェアプロバイダが思っている限り、広告が表示されていることを確認することである。広告主との信頼性を維持することが非常に重要であることが理解できるであろう。例示的な監査スキームは以下の機能を含む。
【０１３２】
・  広告表示の回転ログを保持する。このログは１週間に一度めぐって来る。このログはユードラにおける累積的なフェースタイム、累積的な実行時間などの他の事象に加えて、広告が表示されたときに、広告が除去されたときに、広告がクリックされたときに広告関連事象を記録する。
・  ランダムで、ログを送信する許諾をユーザに尋ねる。１月当たり１００ユーザから１人の頻度で、ログをソフトウェアプロバイダに返すユーザの許諾を尋ねる。許諾が与えられた場合には、ログはＡＳＣＩＩでフォーマットされ、送出メッセージに入れられ、キューに入れられる。ユーザには監査する機会が与えられ、ユーザが望む場合には、ログ収集をキャンセルすることができる。図４０参照。
・  選択されたユーザに対して、ペストリーを届ける。ログのランダムな送信に加えて、ソフトウェアプロバイダはまたランダムにサーバとの詳細なトランザクションを監査する許諾を特定のユーザに対して尋ねる。これはソフトウェアプロバイダがクライアントおよびサーバの動作を相関させることを可能にする。
【０１３３】
例示的なユードラｅメールクライアントソフトウェアに適用可能な計測のさらなる詳細は図４１ないし図４４に提供されている。
【０１３４】
例えば図７、図１４、図１６、図１８および図１９に図示されているさまざまな状態フロー図は複数のウェブページ、すなわちソフトウェアプロバイダサーバの１つ例えば登録サーバ３０１からアクセスできるあるいは検索できるＨＴＭＬページに関係している。図１参照。これらのページとこれらのページにアクセスするためにソフトウェアが使用するＵＲＮの一般的な目的をこれから以下でさらに詳細に説明する。
【０１３５】
サーバがユーザを適切な位置に向けるのに役立てるために、あるいはウェブページベースのフォームである項目を予め満たしておくことによりユーザを援助するために、サーバ情報を与えることがクライアントにとって役に立つことが理解できるであろう。これはＵＲＮの質問部分の機能である。質問部分に入る可能性がある要素を以下にリストアップする。質問部分は２つのグループに分割されることに留意すべきである。第１のグループにはパーソナルであると考えられる項目が含まれ、適切なときのみにそれらを送信するように大きな注意を払うべきである。第２のグループにはプライバシーの問題になるとは考えられない項目が含まれている。
【０１３６】
Ｒｅａｌｎａｍｅ：ユーザの主なｅメールパーソナリティーからのリアルネームフィールド（ＥＰ４はＩＭＡＰ４（ＰＯＳ３も）ｅメールアカウントに対する複数のｅメールパーソナリティをサポートする）。
Ｒｅｇｆｉｒｓｔ：（もしあれば）ユーザが最後に登録したときのファーストネーム。
Ｒｅｇｌａｓｔ：（もしあれば）ユーザが最後に登録したときのラストネーム。
Ｒｅｇｃｏｄｅ：（もしあれば）ユーザの現在のユードラ登録コード。
ＯｌｄＲｅｇ：ユーザの古い形態のＲｅｇＣｏｄｅ。
ｅ−ｍａｉｌ：ユーザの主なパーソナリティからのｅメールアドレス。
Ｐｒｏｆｉｌｅ：ユーザが入力したプロフィール情報。
Ｄｅｓｔｉｎａｔｉｏｎ：これはユーザが訪れたいＵＲＮである。
Ａｄｉｄ：これはユーザがクリックした広告のＩＤである。
Ｐｌａｔｆｏｒｍ：ＭａｃＯＳ、Ｗｉｎｄｏｗｓ、Ｐａｌｍ、Ｎｉｎｔｅｎｄｏ６４など。
Ｐｒｏｄｕｃｔ：登録されている製品に対するソフトウェアプロバイダコードネーム。ユードラ、ＰＤＱＭａｉｌなど。
Ｖｅｒｓｉｏｎ：登録のために使用されている製品のバージョン番号。これはＭａｊｏｒ．Ｍｉｎｏｒ．Ｂｕｇｆｉｘ．Ｂｕｉｌｄ形態のものであるべきである。
ＤｉｓｔｒｉｂｕｔｏｒＩＤ：これはどのサイトが適用されるかのコードであり、これは次にこのユードラのカスタムブランド付きコピーをユーザに提供する見返りとしてサイトすなわちその制御エンティティが継続した収益ストリームを受け取ることを可能にする。Ａｃｔｉｏｎ：ユーザが行うことを要求したもの。登録、支払、紛失コードなど。
Ｍｏｄｅ：ペイウェア、アドウェアまたはフリーウェアのいずれか。
Ｔｏｐｉｃ：サポート項目に対して使用されるもの。これはサーバにどの特定の種類のサポートが必要であるかを伝える。
【０１３７】
一般的に、ソフトウェアプロバイダの非広告ＵＲＮのすべては、
ｈｔｔｐ：／／ｊｕｍｐ．ｅｕｄｏｒａ．ｃｏｍ／ｊｕｍｐ．ｃｇｉ？ａｃｔｉｏｎ＝ｗｈａｔｅｖｅｒ
で始まる。
【０１３８】
“ａｃｔｉｏｎ”値はユーザがどの機能を実行したいかを決定する。ソフトウェアプロバイダは、％エスケープを付けて、すなわち図４５に示されているチャートにしたがって、（例えば）パーセンテージ（％）またはアンパーサンド（＆）シンボルにより分離して、適当にさまざまな他の質問部分をＵＲＮに追加する。図４５で言及されているウェブページの各タイプの簡単な説明を直後に行う。
【０１３９】
支払ウェブページ：このウェブページはユーザのクレジットカード情報、ネーム、ｅメールアドレス、およびソフトウェアプロバイダがそのユーザについて編集するために欲しい他の情報であればどのようなものでも取得すべきである。いつか支払コードを紛失した場合に使用するための質問と回答も尋ねるであろう。これは公式登録ネームと登録コードを返信、例えば表示およびそしてｅメールすべきである。
フリーウェア登録ウェブページ：このウェブページは支払ウェブページからクレジットカード情報を抜いたのと同じ情報を取得すべきである。フリーウェア登録ウェブページはそれらの公式登録ネームおよび登録コードを返信（すなわち表示およびまたｅメール）すべきである。
アドウェア登録ウェブページ：このウェブページは支払ウェブページからクレジットカード情報を抜いたのと同じ情報を取得すべきである。アドウェア登録ウェブページはそれらの公式登録ネームおよび登録コードを返信（すなわち表示およびまたｅメール）すべきである。
ボックス登録ウェブページ：このウェブページはボックスインストーラまたはアップデータインストーラにより発生された登録を受け入れるために存在している。ボックス登録ウェブページは単にユーザのコードを受け入れ、それを確認し、それをメールで返信し、“登録ありがとうございます”のページまたはダイアログボックスを表示すべきである。
紛失コードウェブページ：このウェブページはユーザが自分の登録コードを見つけるのに役立つ。ユーザが登録／支払をするとき、ユーザはネーム、ｅメールアドレス、質問および回答を提供するように要請される。ユーザが紛失コードページに来ると、ユーザはネームとアドレスを尋ねられ、それが一致すると、ユーザは質問を尋ねられる。すべてが上手くいくと、ＲｅｇＣｏｄｅがユーザにメールされる。ユーザがメールを受信できない場合には、ユーザは電話をしなければならない。
更新ウェブページ：このウェブページはユーザに利用可能な更新をリストアップしなければならない。更新ウェブページはユーザが既に持っていない更新のみをリストアップし、どの更新が無料であるか、そしてどの更新にユーザが支払をする必要があるかを明確に示すことが理想的である。このウェブページはときどきユーザシステムにダウンロードされ、“オフライン”でユードラ中に表示されるので、小さく維持しておく必要がある。
アーカイブに入れられたバージョンウェブページ：このウェブページは、ユーザが必要となるものであればどのようなものでもユーザがダウンロードできるように、ユードラのすべてのバージョンをリストアップすべきである。
プロフィールウェブページ：このウェブページの目的は、ユーザに配信される広告が広告主によりさらに正確に目標付けられるように、人口統計情報を集めることである。このウェブページでは、ユーザは自分のパーソナルな好み、習慣など、例えば買い物の習慣、睡眠の習慣、服の好みなどについての一連の質問が尋ねられる。ユーザを識別する情報はこのウェブページ上で集められない。この情報はクッキーに変形され、ユードラにメールされ、ユードラディレクトリ（フォルダー）中にユーザの設定の一部として記憶される。プロフィールを受け入れる手順は以下に詳細に説明する登録コードを受け入れる手順と同じである。
サポートウェブページ：ソフトウェアプロバイダはユーザの問題を解決するたにいくつかのウェブページを必要とする。これらのウェブページに対して、ソフトウェアプロバイダは質問の“トピック”部分を使用して、必要な状況特定ヘルプにユーザを向ける。
【０１４０】
図１に図示されている全体的なシステムのクライアント側を説明したので、次にシステムのサーバ側を考える。しかしながらネットワークは技術的によく知られているものであるので、ネットワークは詳細に説明しない。
【０１４１】
特に、プレーリストサーバ（ＰＬＳ）またはサーブレット、すなわちプレーリスト要求に対応するアプレットをこれから詳細に説明する。ＰＬＳはサーバ側プログラムであり、このプログラムはＨＴＴＰ要求をサービスし、ＨＴＴＰ応答を返す。各要求は異なるスレッドを発し、クライアントとＰＬＳとの間の通信のデータフォーマットは例示的な実施形態では、ＸＭＬエンコードされることが理解できるであろう。ＰＬＳとの間は以下のジャバパッケージを使用して実現することができると有効である。
【０１４２】
【表４】
2005513583.tif 000006
【０１４３】
次に続くものは、サーブレットｄｏＰｏｓｔ方法が呼び出されたときのＰＬＳにおけるタスクフローの説明である。図４６を参照。ＰＬＳはＸＭＬ要求をパースし、クライアント更新要求を表すオブジェクトを作る。データアクセスはＳＡＸを使用して実行されることに留意すべきである。クライアント要求をログ処理するとき、ＰＬＳは（示されていない）いわゆるクライアント更新テーブルにクライアント要求情報を記憶させる。
【０１４４】
プレーリスト要求は任意の所定日中に１００ｎと一般的に示されているクライアントコンピュータに存在する複数のｅメールクライアントから受信できることが理解できるであろう。同じＳＱＬステートメントを繰り返し発行するとき、質問に対する応答で新しいステートメントを発生させるのではなく、むしろ準備されたステートメントを使用することの方がさらに効率的であることが理解できるであろう。ログ処理動作では、ソフトウェアプロバイダは以下の記号論を使用して反復したステートメントの発生を避けることができると有効である。
【０１４５】
ＰｒｅｐａｒｅｄＳｔａｔｅｍｅｎｔ  ｐｓ＝ｃｏｎｎ．ｐｒｅｐａｒｅＳｔａｔｅｍｅｎｔ（“ＩＮＳＥＲＴ  ＩＮＴＯ  ＣｌｉｅｎｔＵｐｄａｔｅ（日付、ユーザエージェント、ＰｌａｙＬｉｓｔＩＤ、Ｙ）値（？、？、？、？、…）”）。
【０１４６】
新しいプレーリストを発生させる際に、サーブレットがＳＱＬ質問とプログラミングフィルタリングの両方を使用できると有効であることに留意すべきである。これらのプロセスはデータベースをアクセスするときの衝突を防ぐために同期化されることも理解できるであろう。プレーリストを発生するための適切な疑似コードが図４７および図４８に示されている。図４７における第１ブロックの疑似コードは広告リストを発生させる。第１ブロックの疑似コードにより発生された広告リストはアクティブであって、予め定められた時間フレーム内に届けることができるすべての画像広告を保持していることが理解できるであろう。図４７でリストアップされた第２ブロックの疑似コードは広告を届けるために必要な時間を計算する。第３ブロックの疑似コードは図４８に図示されており、利用可能なフェースタイムを満たすために使用できる付加的な広告を決定する。言い換えると、ｅメールクライアントソフトウェアが満たすための残り時間を持っている場合に、発生されたプレーリストはランアウト広告によって、利用可能な時間を自動的に満たす。すなわち発生されたプレーリストは、広告ヒストリー中になく、また残されたゴールショータイムに適合するランアウト広告を見つける。
【０１４７】
ＸＭＬを発生させるときに、コメント、処理命令などを発生させると有用なことがよくある。パッケージＸＰライターは出力ＸＭＬコードすなわちファイル中に特定の種類のノードを作成する１セットの方法を提供する。以下のものはＸＭＬ出力を発生させる際にＰＬＳが使用する方法の短いリストである。
【０１４８】
・  エレメントを開始−開始タグ
・  エレメントを終了−終了タグまたは現在の開始タグを空エレメントとして閉じる
・  属性追加はタグネーム値対フォーマットに帰する
・  コメントはコメントを書く。
【０１４９】
ＰＬＳは、プレーリスト一般応答テーブルとプレーリスト特定応答テーブルの２つのテーブル中における要求に対する応答で発生された情報を記憶する。プレーリスト一般応答テーブルはクライアント情報セクションとプレーリスト発生情報を保持し、プレーリスト特定応答テーブルはエントリセクションを保持する。ＰＬＳが準備されたステートメントＡＰＩを使用して、質問に対する応答における性能を最適化できると有効であることが理解できるであろう。
【０１５０】
図４６を再度参照すると、この図はクラス図を示しており、プレーリストとともにプレーリスト応答の表示および表現を効果的に記述している。このクラス図には反復ＸＭＬライト方法コールが含まれており、これらの方法コールはＰＬＳにより使用されてプレーリストに関係するＸＭＬタグを発生させることが理解できるであろう。
【０１５１】
図４９に移ると、この図は主なプレーリストサーブレットクラスを示しており、プレーリストサーブレットを集約的に規定している。特に、プレーリスト要求クラスは要求を取り扱い、その後ＸＭＬ要求をクライアント更新オブジェクトにマッピングする一方、プレーリスト応答クラスは応答を取り扱い、クライアント更新応答をクライアントに書き戻す。さらに、プレーリスト発生クラスはプレーリストを発生させる一方、ＤＢマネージャクラスはデータベース接続プールを取り扱う。付加的な情報は図４９から直ちに明らかである。
【０１５２】
データベースを使用するすべての記憶動作を有効につなげることができることが図５０から理解できるであろう。先に言及したように、データベースに関するすべてのアクションはＭＭ．ＭｙＳＱＬパッケージにより実行される。
【０１５３】
要約すると、本発明の１つの例示的な実施形態は、通信ネットワークを通して情報サーバシステムと情報を交換して広告を記憶するクライアント装置に対してプレーリスト応答を供給する特殊プレーリストサーバに汎用コンピュータを変えるソフトウェアを含む。特に、このソフトウェアは、クライアント装置により提示されるべき複数の選択された広告を識別するプレーリスト応答を発生させるプレーリスト応答発生機能と、通信ネットワークを通してクライアント装置とのプレーリスト応答送信通信リンクを完成させる第１の通信機能とを実現する。この通信ネットワークを通してプレーリスト応答がクライアント装置に送信される。この場合、情報サーバシステムとプレーリストサーバは独立に制御される。プレーリストはクライアント装置例えばｅメールクライアント上の広告の提示例えば表示を命令するが、広告はこの好ましい実施形態におけるいくつかの方法においてクライアント装置により届けられるあるいは検索されると有効であることが理解できるであろう。この例示的な実施形態では、プレーリスト要求には広告識別子と広告提示命令が含まれていることが好ましく、対応するユニフォームリソースネーム（ＵＲＮ）を含めることができるが、省略してもよい。
【０１５４】
他の例示的な実施形態にしたがうと、本発明は通信ネットワークを通して情報サーバシステムと情報を交換し、広告サーバから広告を受信するクライアント装置に対してプレーリスト応答を供給する特殊プレーリストサーバに汎用コンピュータを変えるソフトウェアを含む。このソフトウェアにはクライアント装置により提示されるべき複数の選択された広告を識別するプレーリスト応答を発生させるプレーリスト応答発生機能と、通信ネットワークを通してクライアント装置とのプレーリスト応答送信通信リンクを確立する第１の通信機能とを含むと有効である。この通信ネットワークを通してプレーリスト応答がクライアント装置に送信される。情報サーバシステムとプレーリストサーバが独立に制御されることが好ましい。この例示的で制限のない本発明の実施形態は、プレーリストにより規定されている広告を届けるために、クライアント装置と専用広告サーバ（システム）との間の特定の通信チャネルを意図していることが理解できるであろう。この例示的な実施形態により使用されるプレーリスト要求には広告の提示および／または広告提示機能に関するクライアント装置の動作を命令する情報と、新しいプレーリストに含まれている広告に対するネームおよびＵＲＮの両方が含まれていることも理解できるであろう。
【０１５５】
さらに別の例示的な実施形態にしたがうと、本発明は通信ネットワークを通して情報サーバシステムと情報を交換し、広告サーバから広告を受信するクライアント装置に対してプレーリスト応答を供給する特殊プレーリストサーバに汎用コンピュータを変えるソフトウェアを提供する。このソフトウェアは次のものを含む。
【０１５６】
・  クライアント装置により提示されるべき複数の選択された広告を識別するプレーリスト応答を発生させるプレーリスト応答発生機能
・  プレーリスト要求から選択された情報を抽出するプレーリスト要求パース機能
・  データベースドライバ機能の出力を受信し、プレーリスト要求の受信に応答してクライアント装置により提供されるべき複数の選択された広告を識別するプレーリスト応答に含めるためにプレーリストを発生させるプレーリスト発生機能
・  選択された情報をプレーリスト応答発生機能に供給してプレーリスト発生機能を開始させる選択された情報供給機能
・  プレーリスト応答がクライアント装置に送信される通信ネットワークを通してのクライアント装置とのプレーリスト応答送信通信リンクを確立する第１の通信機能
・  通信ネットワークを通してのクライアント装置とのプレーリスト要求受信機能をもたらす第２の通信機能
情報サーバシステムとプレーリストサーバは独立に制御される。
【０１５７】
プレーリスト要求パース機能には、プレーリスト要求の適格性を確認するイクステンシブルマークアップラングエッジ（ＸＭＬ）パース機能、オブジェクトを発生させるＸＭＬパース機能による確認後にプレーリスト要求を受信するプレーリスト解析機能、オブジェクトを受信してオブジェクトから質問を作り、その質問をプレーリストサーバデータベースに加えるデータベースドライバ機能が含まれていることが好ましい。
【０１５８】
プレーリスト応答発生機能はプレーリスト要求の受信により開始され、例示的なケースではプレーリスト要求にはプレーリスト要求を供給しているクライアント装置により使用される現在のプレーリストのネームが含まれていることに留意すべきである。情報サーバに接続されている多くのクライアント装置のそれぞれはプレーリスト要求を発生させるが、本発明のこの特定観点の説明、すなわちプレーリストサーバは１つのクライアント装置のみを含むシステムの観点から最もよく理解することができる。例えばｅメールクライアント装置の実際の構成は多数のクライアント装置の使用を意図している。
【０１５９】
プレーリスト要求にはクライアント装置上で現在実行されているプレーリストに関する情報と、クライアント装置により記憶されている広告を提示例えば表示する際にクライアント装置によりなされる進行に関するデータを記憶するユーザデータフィールドとを含むことができると有用である。プレーリスト要求を通してプレーリストサーバに提供することができる情報の例示的で制限のないリストは以下のものを含む。
【０１６０】
・  現在のプレーリストを識別する第１のユーザデータフィールド
・  ユーザ人口統計データを識別する第２のユーザデータフィールド
・  ユーザ／クライアント装置の動作データを識別する第３のユーザデータフィールド
・  クライアント装置の利用ヒストリーを識別する第４のユーザデータフィールド
・  クライアント装置上で動作する各ソフトウェアを識別する第５のユーザデータフィールド
・  クライアント装置の各オペレーティングシステムを識別する第６のユーザデータフィールド
・  規定された時間間隔にユーザがクライアント装置を使用した時間量を識別する第７のユーザデータフィールド
・  クライアント装置により提示されたままである記憶された広告に対して要求される総表示時間を識別する第８のユーザデータフィールド
・  規定された時間間隔の間にクライアント装置により広告が提示された総時間量を識別する第９のユーザデータフィールド
・  クライアント装置と関係する表示スクリーンの大きさを識別する第１０のユーザデータフィールド
・  規定された最新の時間間隔で表示されていた広告に対応する広告識別子のリスト。
【０１６１】
プレーリスト要求パース機能はプレーリスト要求から選択された情報を抽出し、選択された情報と他の情報、例えばプレーリスト応答を発生させる際にプレーリストサーバを制御するエンティティにより提供される情報を使用することができると効果的である。プレーリスト要求には直前にリストアップした情報のすべてまたはサブセットが含まれていてよく、プレーリスト要求パース機能がユーザデータフィールドの少なくとも１つに含まれている情報を抽出することが理解できるであろう。少なくともプレーリストサーバによるプレーリスト要求の受信はプレーリスト応答の発生を開始させる。
【０１６２】
プレーリスト要求に応答して、プレーリスト応答発生機能はアクションコマンドとプレーリスト応答のうちの１つを発生させる。前者に関して、プレーリスト応答発生機能は誤り伝えられたプレーリスト要求の受信に応答してアクションコマンドを発生させることができると有効である。これは一般的にクライアント装置に新しいプレーリスト要求を送信するように命令するエラーコードと考えることができる。アクションコマンドにはクライアント装置によりユーザに対して提示可能な関連エラーメッセージを含めることができることが理解できるであろう。代わりに、アクションコマンドは、プレーリストサーバを制御するエンティティによりプレーリストサーバに発行されるコマンドに応答するクライアント装置により受信および／または記憶される広告のすべてをクライアント装置に削除させる。言い換えると、ソフトウェアプロバイダは既存の広告をフラッシュしたいときがあり、プレーリストサーバを制御するエンティティ、例えばソフトウェアプロバイダがコマンドをプレーリストサーバに送信し、このコマンドは、特定のプレーリスト要求例えばすべてのプレーリスト要求の中で特定のソフトウェアバージョンにより発生されたプレーリスト要求に対してプレーリストサーバがフラッシュコマンドで応答するようにさせる。後者に関して、以下に詳細に説明する。
【０１６３】
先に説明したように、プレーリスト応答にはクライアント情報、クライアント装置例えばＰＤＡ装置が選択された広告すなわちクライアント装置によるプレーリスト応答の受信に続く時間期間中に広告を提示例えば表示する方法に関する情報と、新しいプレーリストの両方が含まれていると有効である。例えばクライアント情報中に含まれている選択されたパラメータが、広告を提示する持続性のある提示モードと短命の提示モードとの間でクライアント装置を切り換えることができると有効である。クライアント情報は例示的なケースでは以下のことをすることができる。
【０１６４】
・  クライアント情報はクライアント装置により提示される広告のターンオーバーレートを制御することができる。
・  クライアント情報はクライアント装置がプレーリスト要求を発生させる周期を指定することができる。
・  クライアント情報は複数の広告の中で競合する広告間の最小時間分離を確立することができる。
・  クライアント情報はクライアント装置が各広告を提示する方法を命令する仕様を確立することができる。
【０１６５】
例えば、クライアント装置に利用可能な広告が現在の広告（有料広告）と満了広告（無料広告）の両方を含んでいるとき、クライアント装置が満了広告を提示する前にクライアント装置が現在の広告を提示する最小時間期間をクライアント情報は含む。クライアント情報はクライアント装置が満了広告を提示できる最大時間期間も確立してもよい。少なくとも、新しいプレーリストのために、新しいプレーリストを現在のプレーリストに連結するかまたは現在のプレーリストを廃棄するかのいずれかをクライアント装置に命令するコマンドまたは選択されたパラメータをプレーリスト応答が含んでいると有効である。クライアント装置動作のこの様相を制御するコマンドまたは選択されたパラメータは、確立された通信リンクを通してのクライアント装置によるプレーリスト応答の受信時に実行される。
【０１６６】
プレーリスト応答に含まれている新しいプレーリストには、選択された各広告に対するネームと対応するユニフォームリソースネーム（ＵＲＮ）が含まれている。広告サーバ上の各ネーム付広告の記憶位置あるいは各ネーム付広告に対して他の記憶装置上の位置にクライアント装置を向け直す広告サーバ上の位置のうちの１つにＵＲＮは対応できることが理解できるであろう。代わりに、ＵＲＮは各ネーム付広告に対して広告サーバ上に配置された広告記憶位置にクライアント装置を向け直す広告サーバ上の位置を指定する。この時点において、選択された各広告のネームとＵＲＮに加えて、新しいプレーリストにはまた、選択された各広告のそれぞれ１つに対する広告タイプ、すなわち郵便切手広告、ツールバー広告、あるいはプラカード広告を識別する情報が含まれていてもよいことに留意すべきである。
【０１６７】
本発明の少なくとも１つの例示的な実施形態では、サーバコンピュータ３０２上に記憶されているソフトウェアにより実現されるプレーリストサーバが、イクステンシブルマークアップラングエッジ（ＸＭＬ）中に書かれた、あるいはコーディングされたプレーリスト要求に応答すると有用であることに留意すべきである。ＸＭＬで発生された文書に関する当業者は、これらの文書例えばプレーリスト要求が関連した文書タイプ定義（ＤＴＤ）を持つことができると有効であると認識するであろう。システム性能を最適化するために、プレーリストサーバは利用可能なすなわちプレーリスト要求パース機能に利用可能なＤＴＤを持つべきである。ＤＴＤがプレーリストサーバに確実に利用可能にするためにいくつかのオプションがある。第１に、それぞれ異なるタイプのクライアント装置、例えばｅメールクライアント装置またはＰＤＡに対するＤＴＤは、プレーリストサーバにより記憶される。このケースでは、プレーリスト要求はＤＴＤタグのみを含むことが必要であり、このＤＴＤタグはプレーリスト要求パース機能により使用されるべき特定のＤＴＤを識別する。第２に、ＤＴＤはプレーリスト要求に埋め込むことができると有用である。いずれのケースでも、プレーリストサーバとクライアント装置は同じＤＴＤを暗黙的に使用する。
【０１６８】
ソフトウェアプロバイダは広告セキュリティに関して準備しなければならないことに留意すべきである。考えるべき２つのセキュリティ問題が実際に存在する。１つはクライアントが有効な広告を取得しているか否かであり（このクライアントセキュリティをコールする）、第２のものは有効なクライアントが広告をフェッチしているか否かである（このサーバセキュリティをコールする）。
【０１６９】
クライアントセキュリティは比較的重要性が低い。所定の人がユードラをだましてソフトウェアプロバイダにより送信されるもの以外の何らかの広告を表示させようとした場合、おそらく相当な量になっても構わない。１つ以上のサイトにおける多くのクライアントがそれを始めた場合に問題となることはないとまでは言えない。しかしながら、注意深く言葉で言い表されたライセンス契約書により、少なくとも多数のサイトがこの特定の問題を引き起こすアクションを避けるようにしなければならない。しかしながら、つまらない攻撃を避けるために、プレーリストと広告はＭＤ５（あるいは他のメカニズム）によりチェックサムを取ることができ、プレーリスト中にチェックサムを記録することができると有用である。クライアントは同じ秘密シードを使用してプレーリストと広告のチェックサムを取り、そのチェックサムをプレーリスト中のものと比較することができる。適切な広告を取得するのに失敗した場合には、これは広告を取得するのにまったく失敗したとして取り扱われる。
【０１７０】
サーバ側セキュリティは潜在的にさらに大きな問題である。ソフトウェアプロバイダは、ソフトウェアプロバイダが課金している広告をソフトウェアプロバイダのユーザが実際に見ているという理解に基づいて、広告の広告主に課金しようと考える。自信を持ってこれを行うために、ソフトウェアプロバイダは広告をダウンロードしているのは実際ユードラであり、多くの広告をフェッチするために書かれた何らかのローグプロセスでないか確認しなければならない。なぜ誰かが広告をフェッチするのに困っているのか？ソフトウェアプロバイダは“できるからだ”というアマチュアハッカーの動機を無視することができない。現実問題は広告収益すなわち広告助成金である。各広告フェッチは第３者に対して収益を発生させることから、第３者が多くの広告フェッチを生じさせる非常に顕著な財政上の動機が存在する。したがって、ユードラのコピーによりなされていない広告フェッチをソフトウェアプロバイダが防ぐ（および／または検出する）ことが肝要となる。ソフトウェアプロバイダが署名したディストリビュータとの契約書にこのようなフェッチが違反している場合には、これらのフェッチは詐欺の形態を構成することがある。
【０１７１】
詐欺を検出するいくつかの異なるアプローチがあり、これらは例えば広告サーバ３０３上で実行されているソフトウェアで実現させることができる。詐欺を防ぐためにソフトウェアプロバイダがどのような方法を結局使用しても、詐欺が生じた場合に詐欺を検出することも重要である。詐欺検出には２つの広いクラスがあり、それらは認証と統計解析である。
【０１７２】
認証は容易に理解することができ、ユードラの有効なコピーであることを証明することに広告をフェッチするプログラムが失敗した場合には、ソフトウェアプロバイダには可能性のある詐欺に対してアラートが発せられる。しかしながら、認証はそれ自身の解決すべき問題を提供し、不可能、非現実的あるいは単に不必要であるかもしれない。
【０１７３】
統計解析はいくつかの大きな利点を有するが、大きな欠点も持つ。この利点にはクライアントにおける最小作業（そして分解に対する無防備さがないなど）、クライアントまたはサーバのいずれかにおける実行時負担がないこと、すなわちアカウント実行中に“事実の後”ですべてのことを行うことができること、ソフトウェアプロバイダエンドから容易に変更可能であること、遡及的に適用される能力などが含まれる。統計解析に対する欠点には、統計解析が決して完全に確実とはならないこと、ソフトウェアプロバイダが適切な統計値を集めないかもしれないことが含まれる。
【０１７４】
ソフトウェアプロバイダが収集するあるいは計算するパラメータまたは統計測定のリストを直後に示す。
【０１７５】
ＣｌｉｅｎｔＩＤ：広告をフェッチするのに使用するためにいくつかの種類のクライアントＩＤを発生させることを避ける方法を見つけるのは困難である。ソフトウェアプロバイダはこのような識別子が外部からの承認を必要としないものであることを望むかもしれないが、ユードラのどの特定のインストールが実際に広告をフェッチするのかをソフトウェアプロバイダが知る必要のあることが好ましい。これは統計値を編集し、計算を実行する際に使用することができる。“インストール”により、ソフトウェアプロバイダは、その中にユードラメール構造を持つ単一の記憶システムディレクトリ（ＰＣ）またはフォルダー（Ｍａｃ）を意味するつもりで言っており、すなわちデータはｅメールクライアントと少なくとも１つのサーバとの間で交換され、本質的に必ずしもｅメールクライアント自体のデータではない。
ＩｐＡｄｄｒｅｓｓ：ソフトウェアプロバイダは発信ｅメールクライアントのＩＰアドレスにより要求のログをおそらく取りたいであろう。
ＤｉｓｔｒｉｂｕｔｏｒＩＤ：もちろん照会支払システムの基礎はソフトウェアプロバイダが広告をフェッチするクライアントに対するディストリビュータＩＤを記録するという事実である。ソフトウェアプロバイダはユーザが支払うときかあるいはソフトウェアを登録したときにこれを集めなければならない。
ＮｕｍＰａｉｄＵｓｅｒ：この統計値は所定のディストリビュータＩＤを持つ有料ユーザの数である。
ＮｕｍＣｌｉｅｎｔＩＤｓ：この統計値は所定のディストリビュータＩＤを持つクライアントＩＤの数である。
ＮｕｍＡｄｓＦｅｔｃｈｅｄ：特定のクライアントＩＤによりフェッチされた広告の数である。
先にリストアップしたパラメータを監視することから生データが入手可能であれば、以下のものは発生させることができる可能性ある統計測定値の例示的で非包括的なリストである。
ＮｕｍＡｄｓＦｅｔｃｈｅｄ：非常の多い数のフェッチされた広告を持つクライアントＩＤが疑わしい。
ＮｕｍＣｌｉｅｎｔＩＤｓ／ＮｕｍＰａｉｄＵｓｅｒｓ：ソフトウェアプロバイダはクレジットカード情報を集めこのカードに対して課金することから、有料ユーザは非常に確実な数である。したがって、有料ユーザは何人のクライアントをソフトウェアプロバイダが期待できるかについての有用な測定尺度として機能する。非常に高い比あるいは急に高くなる比を持つ特定のディストリビュータは調査するのにふさわしい。
【０１７６】
ソフトウェアプロバイダが非常に認識していなければならない問題の１つはユーザのプライバシーの保護である。すなわち、ユーザが知らずにソフトウェアプロバイダに提示した情報に基づいて一般的にユーザは広告を受信したくない。極端に声高で偏執的なユーザコミュニティ集団がある。これらの集団は集められている情報の実質的にすべての形態に、そして最も良好な情報にさえ反対する。比較的公認である装置のシリアル番号のようなものでさえ、完全に避けるべきものであると考えられる。ソフトウェアプログラムのシリアル番号はソフトウェアサプライヤにとってありふれたことのように見えるが、このタイプの“タグ付け”に反対するユーザが存在し、ソフトウェアプロバイダはこのようなユーザを認識すべきである。最大限可能な範囲までこのような懸念を避けるために、ソフトウェアプロバイダは以下の規定を含むコンフィデンシャル情報ポリシーを採用すべきである。
【０１７７】
・  許諾の取得−ソフトウェアプロバイダがユーザを識別する可能性がある何らかのデータを集め、あるいは広告主に送信する前に、ソフトウェアプロバイダはユーザの明示的な（図４０参照）あるいはほぼ明示的な許諾を得なければならない。ほぼ明示的なの用語は、例えばユーザがユードラのようなソフトウェアプログラムを登録したウェブページ中にソフトウェアプロバイダが特別なプライバシー警告を入れることを表すために使用されている。ここで、ユーザはデータをソフトウェアプロバイダに提出するためのアクションを明確に行うので、明示的な許諾は必要とされない。一方、ソフトウェアプロバイダは、自分がソフトウェアプロバイダに対して情報を与えているとは知らなかったと無分別なユーザが主張できる範囲を識別するために格別努力すべきであり、ソフトウェアプロバイダにとって比較的明確であるように見える場合であっても明示的な許諾を求めるべきである。
【０１７８】
・  データ分離−可能な範囲で、ソフトウェアプロバイダは登録情報から支払情報を分離することを維持すべきである。この両タイプの情報は人口統計情報などから分離したままにすべきである。データベースを相関させることは非常に誘惑的なことであるが、データベースが実際に相関されている場合にはソフトウェアプロバイダは潜在的な苦しい試練に直面する。さらに、ソフトウェアプロバイダはデータベースの相関が無くても依然として非常に目標が定められた広告を届けることができることから、データベースを分離させたままにすべきである。
・  ユーザの確認可能性−可能な範囲で、ソフトウェアプロバイダにより確立された保護は、パケットスニファでエンドユーザにより確認可能であるようにすべきである。ソフトウェアプロバイダはソフトウェアの例えばユードラのアクションのウオッチングを実行することさえも促進するかもしれない。ソフトウェアプロバイダは貴方のパーソナルデータを広告主に与えない“と言うことが１つのことである。これが事実であるかをユーザが確認できることはまったく別のことである。
・  強い公開性と個人の責任−ソフトウェアプロバイダはそのプライバシーポリシーについて明確で公開性を持つ必要があり、ソフトウェアプロバイダは内部的にプライバシーポリシーを尊重しなければならない。不都合な新聞報道を避けるためにソフトウェアプロバイダが行わなければならないこととしてソフトウェアプロバイダが単にプライバシーを見る場合には、ソフトウェアプロバイダはそれを不完全に行い、問題を巻き込むであろう。
【０１７９】
要約すると、本発明はマルチモード化ソフトウェア製品例えばｅメールソフトウェアを包含し、このソフトウェアには３つの“組み込みの”異なるバージョン（すなわち“モード”）が含まれ、この３つのバージョンには、ソフトウェア製品がユーザにより支払がなされたときに起動される“第１の完全機能セット”バージョン（すなわち“ペイウェア”バージョン）、ソフトウェア製品を助成するためにクライアント装置に届けられる広告を受け入れる同意（例えばデフォルトにより、あるいは明示的な同意により）をユーザがしたときに起動される“第２の完全機能セット”（すなわち“アドウェア”バージョン）、およびソフトウェア製品に支払がなされず、“第２の完全機能セット”バージョンが起動されないときに起動される“縮小機能セット”バージョン（すなわち“フリーウェア”バージョン）が含まれている。本発明はこのようなマルチモード化ソフトウェアがインストールされている非常に多数のクライアント装置に自動的に広告を配信するシステムおよび方法を包含している。第１および第２の完全機能セットはｅメールサポート機能に関して同一であることが理解できるであろう。第２の完全機能セットにはプレーリスト、広告フェッチ機能および表示機能が含まれ、これらは第１の完全機能セットにおけるものと固定的であることも理解できるであろう。
【０１８０】
さらに、本発明は先に述べたようなマルチモード化ソフトウェアをさらに包含し、マルチモード化ソフトウェアにはモード切り換え機能が含まれ、この機能は規定された状態を検出すると（例えば監視したユーザのアクティビィティレベルに、および／または規定された数より少ない広告がダウンロードされたことに基づいて、すなわち“デッドビートユーザ”基準に基づいて）、“アドウェア”バージョンから“フリーウェア”バージョンに自動的に切り換える。本発明はまたこのようなマルチモード化ソフトウェアがインストールされている多数のクライアント装置に広告を自動的に配信するシステムおよび方法も包含する。
【０１８１】
本発明は先に述べたようなマルチモード化ソフトウェアをさらに包含し、マルチモード化ソフトウェアにはモード切り換え機能が含まれ、この機能は規定された“広告失敗状態”例えば規定数の広告よりも少ない広告が規定された時間期間内にクライアント装置により受信および／または表示されたという状態の発生を検出したときに“アドウェア”バージョンから“フリーウェア”バージョンに自動的に切り換えることが先の説明から理解できるであろう。またマルチモード化ソフトウェアには“広告失敗ナグ”機能も含まれ、この機能は“最後のナグからの時間”を監視し、監視された“最後のナグからの時間”情報に基づいて、および／または累積広告ダウンロード／表示統計値または情報に基づいてダイナミックに変化する“ナグスケジュール”にしたがって“広告失敗ナグ”を発生させる。本発明はまたこのマルチモード化ソフトウェア製品がインストールされている多数のクライアント装置に広告を自動的に配信するシステム（および方法）も包含している。
【０１８２】
１つの例示的な実施形態では、本発明は先に述べたようなマルチモード化ソフトウェアをさらに包含し、このマルチモード化ソフトウェアにはナグ機能が含まれ、このナグ機能は現在起動されているソフトウェア製品の現在のモードに依存して、および／または最後のナグが発生されてからの時間に基づいて、および／または累積広告ダウンロード／表示統計値または情報に基づいて、および／または他の監視状態に基づいて異なるタイプのナグを発生させる。例えば異なるタイプのナグには“登録ナグ”、“ペイウェアナグ”、“アドウェアナグ”、“更新ナグ”、“広告失敗ナグ”を含めることができる。本発明はまたこのマルチモード化ソフトウェア製品がインストールされた多数のクライアント装置に自動的に広告を配信するシステム（および方法）も包含している。
【０１８３】
他の例示的な実施形態では、本発明はソフトウェアが起動されたときに表示されるべき広告を自動的にダウンロードする自動広告ダウンロード機能と、ユーザアクティビィティレベルを監視し、監視したユーザアクティビィティレベルに基づいて（例えば“離散的な”および／または“累積的な”広告表示パラメータに基づいて）クライアント装置におけるダウンロード広告の表示を制御する制御機能とを組み込んだソフトウェア製品（例えばｅメールソフトウェア）を包含している。本発明はまたこのソフトウェア製品がインストールされた多数のクライアント装置に自動的に広告を配信するシステムおよび方法も包含している。
【０１８４】
本発明はまたｅメールソフトウェア製品も包含しており、このソフトウェア製品はｅメールサーバシステムから離れて独立している遠隔サーバシステムから自動的に広告をダウンロードする制御機能を組み込んでいる。本発明はまたこのｅメールソフトウェア製品がインストールされたクライアント装置に自動的に広告を配信するシステムおよび方法も同様に包含している。特に、このシステムには広告の配信を監視し、管理し、制御する広告サーバシステムが含まれている。このシステムは制御エンティティ（例えば本発明の譲受人クゥアルコム・インコーポレーテッドにより運営されるもの）により制御される。この制御エンティティは、ｅメールソフトウェア製品がインストールされている特定のクライアント装置にｅメールサービスを提供するｅメールサーバシステムを制御する制御エンティティとは分離され独立している。したがって、ジューノオンラインサービスシステムとは明らかに対照的に、本発明のこの観点にしたがうと、広告サーバシステムとｅメールサーバシステムは独立的に動作し、すなわち分離され独立した制御エンティティの制御の下で動作する。
【０１８５】
本発明はまたソフトウェア製品例えばｅメールソフトウェアを包含し、このソフトウェアが、遠隔サーバシステムからソフトウェア製品がインストールされているクライアント装置に自動的に広告をダウンロードする自動広告ファイルダウンロード機能と、ダウンロードされた広告ファイル中に含まれている広告パラメータに基づいてクライアント装置におけるダウンロード広告の表示をローカル的に制御する制御機能とを組み込んでいると効果的である。ダウンロードされた広告ファイルには例えば（各広告に対して）、以下の広告パラメータのコンビネーションおよびサブコンビネーションが含まれる。すなわち、その特定広告の所定表示に対する最大広告表示時間、あるいはフェースタイム、その特定広告に対する最大総／累積広告表示時間、あるいはフェースタイム、一日当たりその特定広告を表示する最大回数、これより前にその特定広告を実行すべきでない日付／時間、これより後にその特定広告を実行すべきでない日付／時間のコンビネーションおよびサブコンビネーションがダウンロードされた広告ファイルに含まれる。本発明はまたこのソフトウェア製品がインストールされた多数のクライアント装置に自動的に広告を配信するシステムおよび方法も包含している。
【０１８６】
本発明はソフトウェア製品例えばｅメールソフトウェアを包含し、このソフトウェア製品は自動広告ダウンロード機能を組み込み、この機能は遠隔サーバシステム（例えばプレーリストサーバシステム）からプレーリストをフェッチし、このプレーリストはソフトウェア製品がインストールされているクライアント装置によりフェッチされるべき広告と、指定された広告が記憶されている広告サーバのソースアドレス（例えばＵＲＮ）とを指定し、またこの機能はフェッチされたプレーリスト中で指定された広告をフェッチし、フェッチされた広告をクライアント装置に記憶することが理解できるであろう。本発明はこのソフトウェア製品がインストールされているクライアント装置に広告を配信するシステムおよび方法をさらに包含し、このシステムはプレーリストサーバ（またはプレーリストサーバシステム）を含み、プレーリストサーバはクライアントプレーリスト識別子を持つ特定のクライアント装置からのプレーリスト要求に応答して、クライアントプレーリスト識別子により識別されたクライアントプレーリストをプレーリストサーバに記憶されている現在のプレーリスト（この現在のプレーリストはオプション的にその特定のクライアント装置に対してカスタマイズされているかもしれない）と比較し、クライアント装置によりフェッチされるべき新しい広告を指定する新しいプレーリストと、指定された新しい広告が記憶されている広告サーバのソースアドレスとをクライアント装置に返信する。
【０１８７】
オプション的に、クライアント装置にインストールされているソフトウェア製品の先に説明した自動広告ダウンロード機能はクライアント装置上に現在記憶されている広告のすべてあるいはプレーリストサーバが指定したもの、例えば現在のプレーリスト中で指定されていないものを削除（あるいは廃棄）することができる。およびまたはクライアント装置にインストールされているソフトウェア製品の先に説明した自動広告ダウンロード機能は新しいプレーリストを現在のクライアントプレーリストと併合させることができる。本発明はユードラアドウェアスキームで利用されるこの新規なプレーリスト／広告フェッチプロセスのいくつかの変形および構成の詳細も含んでいる。
【０１８８】
さらに、本発明はソフトウェア製品例えばｅメールソフトウェアを包含しており、このソフトウェア製品はカスタムインストーラを組み込んでおり、このカスタムインストーラはそのソフトウェア製品を配布する特定のソフトウェア製品ディストリビュータを識別する。本発明はさらにソフトウェア製品例えばｅメールソフトウェアも包含し、このソフトウェア製品はソフトウェア製品がインストールされているクライアント装置に遠隔サーバシステムから広告を自動的にダウンロードする自動広告ダウンロード機能と、そのソフトウェア製品を販売する特定のソフトウェア製品ディストリビュータを識別するカスタムインストーラとを組み込んでおり、これはソフトウェア製品ベンダーが広告主から受け取る広告収益の特定のソフトウェア製品ディストリビュータへの配分を促すためである。本発明はまたこのソフトウェア製品がインストールされた多数のクライアント装置に自動的に広告を配信するシステム（および方法）も包含している。このシステムにはクライアント装置からソフトウェア製品ディストリビュータＩＤ情報を受け取り、このソフトウェア製品ディストリビュータＩＤ情報を使用してソフトウェア製品ベンダーが広告主から受け取る広告収益の特定ソフトウェア製品のディストリビュータへの割り当てを促す中央制御ファシリティが含まれている。代わりに、あるいは付加的に、ソフトウェア製品の各コピーに関係するシリアル番号または参照コードに基づいて（例えば相互参照および／または相関テーブル）により、ソフトウェアベンダーにより配布された各ソフトウェア製品に対するソフトウェア製品ディストリビュータＩＤを識別する中央データベース機能を利用することができる。
【０１８９】
さらに、本発明はソフトウェア製品例えばｅメールソフトウェアを包含しており、このソフトウェア製品は、遠隔サーバシステムからソフトウェア製品がインストールされているクライアント装置に自動的に広告をダウンロードする自動広告ダウンロード機能と、ビルトイン“デッドマンタイマー”を利用してそれぞれ特定の広告ダウンロードセッションに対するタイムリミットを課す制御機能とを組み込んでおり、例えばクライアント装置は“デッドマンタイマー”により課されたタイムリミットの満了時に遠隔サーバシステムから切断される。本発明はまたこのソフトウェア製品がインストールされた多数のクライアント装置に自動的に広告を配信するシステム（および方法）も包含している。
【０１９０】
本発明はソフトウェア製品として例えばｅメールソフトウェアとして特徴付けることができ、このソフトウェア製品は遠隔サーバシステムからソフトウェア製品がインストールされているクライアント装置に広告を自動的にダウンロードする自動広告ダウンロード機能と、さまざまな新規な機能／機能性を有する、例えば広告関連統計値の回転ログを維持し、および／またはユーザの許諾でランダムにおよび／または統計ベースで広告有用性監査を実行する計測および監査モジュールとを組み込んでいることも理解できるであろう。本発明はまたこのソフトウェア製品がインストールされた多数のクライアント装置に自動的に広告を配信するシステム（および方法）も包含している。このシステムには、例えば広告配信システムの完全性および／または有効性を監視するために、ランダムまたは統計的方法で、選択されたクライアント装置から広告関連統計情報を獲得する中央制御ファシリティが含まれている。
【０１９１】
さらに、本発明はソフトウェア製品例えばｅメールソフトウェアを包含し、このソフトウェア製品は遠隔サーバシステムからソフトウェア製品がインストールされているクライアント装置に広告を自動的にダウンロードする自動広告ダウンロード機能と、例えばユーザが以前に訪れたリンクをユーザに対して以前に表示された広告とともに、それぞれにおける何らかのステータス情報をリストアップするリンクヒストリーウィンドウを含むグラフィックユーザインターフェイス（ＧＵＩ）を提供することにより、ユーザが以前に見た広告を見ることができるようにする“リンクヒストリー”機能とを組み込んでいる。例えば適切な広告リンクをシングルクリックすることにより、ユーザが表示用リンクヒストリーウィンドウ中にリストアップされている広告を選択できるようにし、例えば適切な広告リンクをダブルクリックすることにより、リンクヒストリーウィンドウ中にリストアップされている所定の広告のソースウェブサイトをユーザが訪れることできるようにするメカニズムを提供することが好ましい。本発明はまたこのソフトウェア製品がインストールされた多数のクライアント装置に自動的に広告を配信するシステム（および方法）も包含している。
【０１９２】
さらに、本発明はソフトウェア製品例えばｅメールソフトウェアを包含し、このソフトウェア製品は“最後のナグからの時間”を監視し、監視された“最後のナグからの時間”情報に基づいてダイナミックに変化する“ナグスケジュール”にしたがってユーザに催促する“ナグ”機能を組み込んでいる。
【０１９３】
最後に、本発明はソフトウェア製品例えばｅメールソフトウェアを包含し、このソフトウェア製品は遠隔サーバとの別々の通信セッション中に単一画像を提示する別々のファイル部分（例えば広告ファイル例えばＧＩＦファイルの別々のファイル部分）をダウンロードするダウンロード機能を組み込んでいる。本発明はさらにこのソフトウェア製品がインストールされた多数のクライアント装置に自動的に広告を配信するシステム（および方法）も包含している。
【０１９４】
本発明の現在好ましい実施形態を上記で詳細に説明したが、直接関係のある技術分野における当業者に明らかである、ここで教示した基本的な発明概念の多くの変形および／または修正は添付した特許請求の範囲中に規定されているように本発明の精神および範囲に依然として入るものである。
【図面の簡単な説明】
【図１】
図１は、ネットワークを通して独立に動作する複数のサーバ装置に接続された複数のクライアント装置を含むコンピュータシステムのハイレベルな図である。
【図２】
図２は、図１に示されているクライアント装置の典型的な１つのハイレベルな図である。
【図３】
図３は、本発明にしたがった例示的なｅメールソフトウェアアプリケーションのメインナビゲーションスクリーンにおける代替および無制限な配置を図示している。
【図４】
図４は、本発明にしたがった例示的なｅメールソフトウェアアプリケーションのメインナビゲーションスクリーンにおける代替および無制限な配置を図示している。
【図５】
図５は、ソフトウェアの１つのバージョンが新しいユーザ、古いユーザおよびＥＰ４ユーザの１人によりインストールされるときの状態遷移を図示している。
【図６】
図６は、図５に図示されている状態フロー図と関係しているダイアログボックスを図示している。
【図７】
図７は、広告ユーザが登録された。広告ユーザになるプロセスの例示的な状態フロー図を図示している。
【図８】
図８は、図７と関係しているダイアログボックスを図示している。
【図９】
図９は、図７と関係しているダイアログボックスを図示している。
【図１０】
図１０は、図７と関係しているダイアログボックスを図示している。
【図１１】
図１１は、図７と関係しているダイアログボックスを図示している。
【図１２】
図１２は、図７と関係しているダイアログボックスを図示している。
【図１３】
図１３は、図７と関係しているダイアログボックスを図示している。
【図１４】
図１４は、無料ユーザが登録された無料ユーザになることができるプロセスの例示的な状態フロー図を図示している。
【図１５】
図１５は、図１４に関係する付加的なダイアログボックスを図示している。
【図１６】
図１６は、本発明にしたがったソフトウェアを更新するためにすべてのユーザに気付かせるプロセスの例示的な状態フロー図を図示している。
【図１７】
図１７は、更新ナグに対応する例示的なダイアログボックスを図示している。
【図１８】
図１８は、ボックスユーザが有料ユーザになることができるプロセスの例示的な状態フロー図を図示している。
【図１９】
図１９は、有料ユーザが未払ユーザになるプロセスの例示的な状態フロー図を図示している。
【図２０】
図２０は、本発明の例示的な実施形態にしたがったユードラのｅメールソフトウェアのＭａｃＯＳバージョンに対する例示的なナグウィンドウ表示のタイムラインを図示している。
【図２１】
図２１は、本発明にしたがったソフトウェアにより使用されるナグスケジュールを図示している。
【図２２】
図２２は、本発明の例示的なソフトウェア実施形態において使用されるリンクヒストリーウィンドウのシミュレーションされたスクリーン検索である。
【図２３】
図２３は、本発明にしたがったｅメールクライアントがオフラインであることをユーザに気付かせるダイアログボックスである。
【図２４】
図２４は、ｅメールプログラム動作において広告送信の影響を決定する際に使用された仮定を図示している。
【図２５】
図２５は、加入者ベース対毎日ダウンロードすべき新しい広告の数に関する帯域幅要求をリストアップした表である。
【図２６】
図２６は、本発明にしたがった例示的な広告フェッチプロセスの状態フロー図である。
【図２７】
図２７は、本発明にしたがった例示的な実施形態における広告スケジュールを制御するアルゴリズムを集約的に図示している。
【図２８】
図２７は、本発明にしたがった例示的な実施形態における広告スケジュールを制御するアルゴリズムを集約的に図示している。
【図２９】
図２９は、本発明にしたがった例示的な実施形態における広告スケジュールを制御するアルゴリズムを集約的に図示している。
【図３０】
図３０は、本発明にしたがった例示的な実施形態における広告スケジュールを制御するアルゴリズムを集約的に図示している。
【図３１】
図３１は、本発明にしたがった例示的な実施形態における広告スケジュールを制御するアルゴリズムを集約的に図示している。
【図３２】
図は、本発明にしたがった例示的な実施形態における広告スケジュールを制御するアルゴリズムを集約的に図示している。
【図３３】
図３２は、本発明にしたがった例示的な実施形態における広告スケジュールを制御するアルゴリズムを集約的に図示している。
【図３４】
図３４は、本発明にしたがった例示的な実施形態における広告スケジュールを制御するアルゴリズムを集約的に図示している。
【図３５】
図３５は、本発明にしたがった例示的な実施形態において可能な広告表示の代替モードにおけるパラメータバリエーションを図示している。
【図３６】
図３６は、本発明にしたがった例示的な実施形態において可能な広告表示の代替モードにおけるパラメータバリエーションを図示している。
【図３７】
図３７は、本発明の１つの観点にしたがったｅメールクライアントソフトウェアにより有効に発生させることができる付加的なダイアログボックスを図示している。
【図３８】
図３８は、本発明の１つの観点にしたがったｅメールクライアントソフトウェアにより有効に発生させることができる付加的なダイアログボックスを図示している。
【図３９】
図３９は、本発明の１つの観点にしたがったｅメールクライアントソフトウェアにより有効に発生させることができる付加的なダイアログボックスを図示している。
【図４０】
図４０は、本発明にしたがったアドウェアソフトウェアの動作を監査することに関係する例示的なダイアログボックスを図示している。
【図４１】
図４１は、ソフトウェアの性能を監査するための有用なパラメータをリストアップしたものである。
【図４２】
図４２は、ソフトウェアの性能を監査するための有用なパラメータをリストアップしたものである。
【図４３】
図４３は、ソフトウェアの性能を監査するための有用なパラメータをリストアップしたものである。
【図４４】
図４４は、ソフトウェアの性能を監査するための有用なパラメータをリストアップしたものである。
【図４５】
図４５は、本発明の１つの観点にしたがった例示的なｅメールシステムとともに有効に使用することができる複数のウェブページの特徴を要約した表である。
【図４６】
図４６は、本発明にしたがった他の例示的な実施形態がｄｏＰｏｓｔ方法論にしたがって動作しているときのＸＭＬコードのオブジェクトへのマッピングおよびタスクフローを図示している。
【図４７】
図４８は、本発明にしたがってプレーリストを発生させる際に図１のサーバ３０２により使用することができる疑似コードのリストを集約的に図示している。
【図４８】
図４９は、本発明にしたがってプレーリストを発生させる際に図１のサーバ３０２により使用することができる疑似コードのリストを集約的に図示している。
【図４９】
図４９は、図１に図示されているサーバとクライアントコンピュータの少なくとも１つの間の要求と書込のハンドリングを図示している他のクラスの図である。
【図５０】
図５０は、他の観点にしたがったデータベースアクセスを図示している。
【図１】
2005513583.tif 000007
【図２】
2005513583.tif 000008
【図３】
2005513583.tif 000009
【図４】
2005513583.tif 000010
【図５】
2005513583.tif 000011
【図６】
2005513583.tif 000012
【図７】
2005513583.tif 000013
【図８】
2005513583.tif 000014
【図９】
2005513583.tif 000015
【図１０】
2005513583.tif 000016
【図１１】
2005513583.tif 000017
【図１２】
2005513583.tif 000018
【図１３】
2005513583.tif 000019
【図１４】
2005513583.tif 000020
【図１５】
2005513583.tif 000021
【図１６】
2005513583.tif 000022
【図１７】
2005513583.tif 000023
【図１８】
2005513583.tif 000024
【図１９】
2005513583.tif 000025
【図２０】
2005513583.tif 000026
【図２１】
2005513583.tif 000027
【図２２】
2005513583.tif 000028
【図２３】
2005513583.tif 000029
【図２４】
2005513583.tif 000030
【図２５】
2005513583.tif 000031
【図２６】
2005513583.tif 000032
【図２７】
2005513583.tif 000033
【図２８】
2005513583.tif 000034
【図２９】
2005513583.tif 000035
【図３０】
2005513583.tif 000036
【図３１】
2005513583.tif 000037
【図３２】
2005513583.tif 000038
【図３３】
2005513583.tif 000039
【図３４】
2005513583.tif 000040
【図３５】
2005513583.tif 000041
【図３６】
2005513583.tif 000042
【図３７】
2005513583.tif 000043
【図３８】
2005513583.tif 000044
【図３９】
2005513583.tif 000045
【図４０】
2005513583.tif 000046
【図４１】
2005513583.tif 000047
【図４２】
2005513583.tif 000048
【図４３】
2005513583.tif 000049
【図４４】
2005513583.tif 000050
【図４５】
2005513583.tif 000051
【図４６】
2005513583.tif 000052
【図４７】
2005513583.tif 000053
【図４８】
2005513583.tif 000054
【図４９】
2005513583.tif 000055
【図５０】
2005513583.tif 000056
【国際調査報告】
2005513583.tif 000057
2005513583.tif 000058