JP4577418B2 - 広告配信システム - Google Patents

Description

本発明は、広告配信システムに関する。

従来、ディスプレイを備えた情報機器において、ディスプレイを利用しなくても構わない状況にある場合（例えば、印刷実行中、あるいはスタンバイ状態となっている期間中など）に、情報機器のディスプレイに広告情報等を表示する技術が提案されている（例えば、特許文献１参照）。

この特許文献１に記載の技術において、情報機器は、あらかじめ登録してあるＵＲＬ（Uniform Resource Locator）や、あらかじめ登録してある所定のサーバから、広告情報等を取得可能な仕組みになっていた（特許文献１：段落［０００６］参照）。

また、広告情報を表示する技術としては、上記の他にも、コンテンツサーバから取得した広告情報を、クライアント側で表示する技術などが提案されている（例えば、特許文献２参照）。
特開２００２−７４１５５号公報 特開２００２−７８４４号公報

しかし、上記特許文献１，２に記載の技術において、クライアントは、あらかじめ登録された特定のアクセス先（ＵＲＬ，サーバ）にアクセスするだけであり、また、アクセス先となるサーバも、単に広告情報をクライアントに提供するだけであった。

そのため、広告情報を提供するために新たなアクセス先（ＵＲＬ，サーバ）を用意しても、それだけでは、新たなアクセス先をクライアント側に登録することはできず、クライアントが自ら新たなアクセス先にアクセスすることは不可能であった。また、それ故、新たなアクセス先となるサーバにおいても、当然ながらクライアントからの要求は到来せず、新たなアクセス先からクライアントへ広告情報を提供することは不可能であった。

したがって、例えば、新たなアクセス先となるサーバから、より多様な広告情報を提供したいと考えても、そのようなことを実現するのは困難であった。また、例えば、クライアントからのアクセスを新たなアクセス先に分散させたくても、クライアントは登録済みのサーバにしかアクセスしないので、登録済みのアクセス先へのアクセス集中を緩和することはできなかった。

本発明は、上記問題を解決するためになされたものであり、その目的は、クライアントに登録されていない新たなアクセス先から、クライアントに対して広告情報を提供可能とすることができる広告配信システムを提供することにある。

以下、本発明において採用した構成について説明する。
まず、請求項１に記載の広告配信システムは、ネットワークを介して通信可能な広告サーバとクライアントを備え、前記広告サーバから配信される広告データに基づいて前記クライアントが広告を表示するように構成された広告配信システムであって、前記クライアントは、前記ネットワーク上のアドレスを記憶するアドレス記憶手段と、前記アドレス記憶手段に記憶されたアドレスにアクセスすることにより、前記広告サーバにデータ配信を要求する配信要求手段と、前記配信要求手段による要求に応じて前記広告サーバからデータが配信された場合に、当該データを取得するデータ取得手段と、前記データ取得手段によって取得されたデータが、前記広告データであった場合に、当該広告データに基づいて広告を表示する情報表示手段と、前記データ取得手段によって取得されたデータが、新たなアクセス先のアドレスであった場合に、当該アドレスを前記アドレス記憶手段に記憶させるアドレス更新手段と、前記アドレス更新手段によって前記アドレス記憶手段に記憶されたアドレスが更新された場合に、前記配信要求手段による処理以降の処理を再実行させる再実行制御手段とを備え、前記広告サーバは、前記クライアントからデータの提供を要求された場合に、前記広告データまたは前記新たなアクセス先のアドレスのいずれを配信すべきかを判定する配信対象判定手段と、前記配信対象判定手段による判定結果に従って、前記広告データまたは前記新たなアクセス先のアドレスのいずれかを配信するデータ配信手段とを備え、さらに、前記ネットワーク上には、管理サーバが設けられ、前記管理サーバは、前記クライアントから伝達されたアドレスが、前記クライアントからのアクセスが制限された制限アドレスか否かを判定する制限アドレス判定手段と、前記制限アドレス判定手段によって制限アドレスと判定された場合に、その制限アドレスの代わりにアクセスすべき代替アドレスを、前記クライアントに対して配信する代替アドレス配信手段とを備え、前記クライアントは、前記データ取得手段によって取得されたデータが、新たなアクセス先のアドレスであった場合に、当該新たに取得されたアドレスを前記管理サーバに対して伝達することにより、前記新たに取得されたアドレスが前記制限アドレスか否かを問い合わせる新取得アドレス問い合わせ手段を備え、前記新取得アドレス問い合わせ手段による問い合わせの結果、前記管理サーバから前記代替アドレスが配信された場合には、前記アドレス更新手段は、前記代替アドレスを前記アドレス記憶手段に記憶させることを特徴とする。
また、請求項２に記載の広告配信システムは、ネットワークを介して通信可能な広告サーバとクライアントを備え、前記広告サーバから配信される広告データに基づいて前記クライアントが広告を表示するように構成された広告配信システムであって、前記クライアントは、前記ネットワーク上のアドレスを記憶するアドレス記憶手段と、前記アドレス記憶手段に記憶されたアドレスにアクセスすることにより、前記広告サーバにデータ配信を要求する配信要求手段と、前記配信要求手段による要求に応じて前記広告サーバからデータが配信された場合に、当該データを取得するデータ取得手段と、前記データ取得手段によって取得されたデータが、前記広告データであった場合に、当該広告データに基づいて広告を表示する情報表示手段と、前記データ取得手段によって取得されたデータが、新たなアクセス先のアドレスであった場合に、当該アドレスを前記アドレス記憶手段に記憶させるアドレス更新手段と、前記アドレス更新手段によって前記アドレス記憶手段に記憶されたアドレスが更新された場合に、前記配信要求手段による処理以降の処理を再実行させる再実行制御手段とを備え、前記広告サーバは、前記クライアントからデータの提供を要求された場合に、前記広告データまたは前記新たなアクセス先のアドレスのいずれを配信すべきかを判定する配信対象判定手段と、前記配信対象判定手段による判定結果に従って、前記広告データまたは前記新たなアクセス先のアドレスのいずれかを配信するデータ配信手段とを備え、さらに、前記ネットワーク上には、管理サーバが設けられ、前記管理サーバは、前記クライアントから伝達されたアドレスが、前記クライアントからのアクセスが制限された制限アドレスか否かを判定する制限アドレス判定手段と、前記制限アドレス判定手段によって制限アドレスと判定された場合に、その制限アドレスの代わりにアクセスすべき代替アドレスを、前記クライアントに対して配信する代替アドレス配信手段とを備え、前記クライアントは、前記アドレス記憶手段に記憶されたアドレスを前記管理サーバに対して伝達することにより、前記アドレス記憶手段に記憶されたアドレスが前記制限アドレスか否かを定期的または不定期に問い合わせる記憶済みアドレス問い合わせ手段を備え、前記記憶済みアドレス問い合わせ手段による問い合わせの結果、前記管理サーバから前記代替アドレスが配信された場合には、前記アドレス更新手段は、前記代替アドレスを前記アドレス記憶手段に記憶させることを特徴とする。

以上のように構成された広告配信システムにおいては、クライアントからの要求に応じて、広告サーバからクライアントへ、広告データまたは新たなアクセス先のアドレスが配信される。広告データが配信された場合、クライアントは、広告データに基づいて広告を表示する。一方、新たなアクセス先のアドレスが配信された場合、クライアントは、アドレス記憶手段に新たなアドレスを記憶し、新たなアドレスに対してデータの配信を要求する。なお、以降は、広告データまたは新たなアクセス先のアドレスいずれが配信されるかに応じて、上述の処理が再実行されることになる。

したがって、このような広告配信システムによれば、上記のようなアドレス変更を広告サーバ側で管理することができないシステムとは異なり、広告サーバは、様々な事情を考慮して最適と考えられるアドレスをクライアントに指示することができ、これにより、より最適な広告をクライアントに表示させることができる。

また、ネットワーク上に多数のクライアントが存在する場合に、すべてのクライアントからのアクセスが、初期値として設定されたアドレスだけに殺到するのを、アドレス変更によって回避するといったことも可能となる。
さらに、上記のような広告配信システムにおいては、何らかの事情で、広告データの取得元として問題のあるアクセス先になっている場合に、そのアドレスが管理サーバ側で制限アドレスとして登録される。
そして、クライアントが、新たに配信されたアドレス（請求項１）、あるいは、アドレス記憶手段に記憶されたアドレス（請求項２）について、管理サーバへの問い合わせを行った際、問い合わせのあったアドレスが制限アドレスであった場合、管理サーバはクライアントに代替アドレスを配信する。
したがって、このような広告配信システムによれば、クライアントが制限アドレスへアクセスするのを防止することができる。また、問題のない代替アドレスをクライアントに通知することで、適切な広告データの配信を行い、適切な広告をクライアントに表示させることができる。

次に、請求項３に記載の広告配信システムは、請求項１または請求項２に記載の広告配信システムにおいて、前記クライアントにおいて、前記情報表示手段は、前記制限状況問い合わせ手段が前記管理サーバからデータを取得できなかった場合に、予め記憶されているデフォルトの表示用データに基づいて情報を表示することを特徴とする。
この広告配信システムにおいては、管理サーバから応答が返らない場合に、デフォルトの表示用データに基づいて情報を表示する。したがって、このような広告配信システムによれば、管理サーバでの検証ができなかったアドレスに、クライアントが不用意にアクセスしてしまうのを回避することができる。
次に、請求項４に記載の広告配信システムは、請求項１〜請求項３のいずれか一項に記載の広告配信システムにおいて、前記ネットワーク上には、前記広告サーバとして、少なくとも第１，第２の広告サーバを含む複数の広告サーバが設けられ、前記第１の広告サーバにおいては、前記配信対象判定手段が前記新たなアクセス先のアドレスを配信すべきと判定した場合に、前記データ配信手段が、前記新たなアクセス先のアドレスとして、前記第２の広告サーバがアクセス先となるアドレスを提供することを特徴とする。

この広告配信システムにおいては、クライアントからの要求に応じて、第１の広告サーバは、第２の広告サーバがアクセス先となるアドレスを、新たなアクセス先のアドレスとしてクライアントに提供する。このアドレスを取得したクライアントは、アドレス記憶手段に記憶されたアドレスを新たなアドレスに変更し、新たなアドレスに対してデータの配信を要求する。その結果、クライアントがアクセスするアドレスは、第１の広告サーバから第２の広告サーバへ変更されることになる。

したがって、このような広告配信システムによれば、アドレスの変更を行ってもアクセス先が同一の広告サーバとなる場合とは異なり、アドレスの変更後は、第１の広告サーバへのアクセスに伴う負荷を、第２の広告サーバへ分散させることができる。

次に、請求項５に記載の広告配信システムは、請求項１〜請求項４のいずれか一項に記載の広告配信システムにおいて、前記広告サーバは、前記クライアントからデータ配信を要求された場合に、前記クライアント側から受け取ったクライアント情報に基づいて、前記クライアントが設置された地域を特定する地域特定手段を備え、前記配信対象判定手段は、前記地域特定手段によって特定された前記地域に対応した前記広告データを配信可能か否かに基づいて、配信可能な場合は、前記広告データを配信すべきと判定する一方、配信不能な場合は、前記地域特定手段によって特定された前記地域に対応した前記広告データを配信可能なアクセス先のアドレスを配信すべきと判定することを特徴とする。

この広告配信システムにおいて、広告サーバは、クライアント側から受け取ったクライアント情報に基づいて、クライアントが設置された地域を特定する。そして、クライアントが設置された地域に対応した広告データを配信可能な場合は、広告サーバからクライアントへ広告データが配信される。また、クライアントが設置された地域に対応した広告データを配信不能な場合は、クライアントが設置された地域に対応した広告データを配信可能なアクセス先のアドレスが、広告サーバからクライアントへ配信される。この場合、クライアントが新たなアクセス先にアクセスすることで、クライアントが設置された地域に対応した広告データが配信される。

したがって、このような広告配信システムによれば、広告サーバは、クライアントが設置された地域に対応した適切な広告データを配信することができる。
次に、請求項６に記載の広告配信システムは、請求項５に記載の広告配信システムにおいて、前記地域特定手段は、前記クライアントに割り当てられた電話番号を、前記クライアント情報として受け取り、当該電話番号に基づいて前記クライアントが設置された地域を特定することを特徴とする。

この広告配信システムにおいて、クライアントは、電話番号が割り当てられる機器である。具体的には、公衆電話網経由での通信機能（通話、ファクシミリ通信、およびデータ通信の内、少なくとも１つ）を備えた機器が、この広告配信システムにおけるクライアントとなる。この電話番号は、クライアントが設置された国や地域を絞り込むことができる情報であり、クライアントは、自身に割り当てられた電話番号を広告サーバに対して通知する。

したがって、このような広告配信システムによれば、広告サーバは、電話番号に基づいてクライアントが設置された地域を特定し、その地域に対応した適切な広告データを配信することができる。

次に、請求項７に記載の広告配信システムは、請求項５に記載の広告配信システムにおいて、前記地域特定手段は、前記クライアントにおいて設定された使用言語とグリニッジ標準時に対する時差とを、前記クライアント情報として受け取り、前記使用言語および前記時差に基づいて前記クライアントが設置された地域を特定することを特徴とする。

この広告配信システムにおいて、クライアント側では、使用言語とグリニッジ標準時に対する時差が設定される。グリニッジ標準時に対する時差は、クライアントが設置された国や地域を絞り込むことができる情報であり、加えて、使用言語を考慮することで、さらに、クライアントが設置された国や地域を絞り込むことができる。

したがって、クライアントが、クライアントにおいて設定された使用言語とグリニッジ標準時に対する時差を広告サーバに対して通知すれば、広告サーバは、クライアントが設置された地域を特定し、その地域に対応した適切な広告データを配信することができる。

次に、請求項８に記載の広告配信システムは、請求項１〜請求項７のいずれか一項に記載の広告配信システムにおいて、前記クライアントは、前記広告サーバから配信された前記広告データに関し、当該広告データの更新日時を記憶する更新日時記憶手段を備えていて、前記配信要求手段が、前記広告サーバにデータ配信を要求する際には、前記更新日時記憶手段に記憶された前記広告データの更新日時を、前記広告サーバへと伝達し、前記広告サーバにおいて、前記データ配信手段は、前記クライアントからデータ配信を要求された場合に、前記クライアント側から受け取った前記更新日時に基づいて、当該更新日時とは異なる更新日時を持つ前記広告データを、前記クライアントへ配信することを特徴とする。

この広告配信システムにおいて、クライアントは、広告サーバにデータ配信を要求する際に、更新日時記憶手段に記憶された広告データの更新日時を、広告サーバへと伝達する。そして、広告サーバは、クライアント側から受け取った更新日時に基づいて、当該更新日時とは異なる更新日時を持つ広告データを、クライアントへ配信する。

したがって、このような広告配信システムによれば、既にクライアントに配信済みの広告データとは、異なる広告データをクライアントへ配信することができ、クライアントは、前回表示された広告とは異なる新たな広告を表示することができる。

次に、請求項９に記載の広告配信システムは、請求項１〜請求項８のいずれか一項に記載の広告配信システムにおいて、前記クライアントにおいて、前記情報表示手段は、前記データ取得手段が前記広告サーバからデータを取得できなかった場合に、予め記憶されているデフォルトの表示用データに基づいて情報を表示することを特徴とする。

このような広告配信システムによれば、広告サーバから広告データが配信されなくてもデフォルトの表示用データに基づいて情報を表示することができる。

次に、本発明の実施形態について一例を挙げて説明する。
［広告配信システムの構成］
図１は、本発明の広告配信システムの一実施形態に相当する構成を示したブロック図である。

本実施形態の広告配信システムは、ＭＦＰ（Multifunction Peripheral）１、広告サーバ２Ａ〜２Ｄ、および管理サーバ３によって構成される。ＭＦＰ１は、ＬＡＮ（Local Area Network）５に接続され、ＬＡＮ５はルータ６を介してインターネット７に接続されている。

また、広告サーバ２Ａ，２Ｂ，２Ｃ，２Ｄ、および管理サーバ３は、いずれもインターネット７に接続され、これにより、ＭＦＰ１は、インターネット７経由で、広告サーバ２Ａ，２Ｂ，２Ｃ，２Ｄや管理サーバ３とデータ通信ができるようになっている。なお、インターネット７には、その他のサーバ８なども接続され、ＭＦＰ１は、その他のサーバ８にもアクセス可能な状態にある。

この広告配信システムにおいて、ＭＦＰ１は、本発明でいうクライアントに相当する装置であり、何らかの機能の作動中、もしくは、スタンバイ状態になると、広告サーバ２Ａ，２Ｂ，２Ｃ，２Ｄに対し、広告データの配信を要求する。広告サーバ２Ａ，２Ｂ，２Ｃ，２Ｄは、ＭＦＰ１から広告データの配信要求が到来した場合、広告データまたはＵＲＬを配信する。

広告データが配信された場合、ＭＦＰ１は広告データを取得する。また、ＵＲＬが配信された場合は、そのＵＲＬを取得し、そのＵＲＬへのアクセスが制限されていないかどうかを管理サーバ３に問い合わせる。この問い合わせを行った結果、アクセスが制限されていない場合、ＭＦＰ１は、配信されたＵＲＬにアクセスすることで、広告データの配信要求以降の処理を再実行する。

以上のような手順にて、ＭＦＰ１が広告データを取得できた場合、ＭＦＰ１は広告データに基づいて広告を表示する。これにより、何らかの機能の作動中、もしくは、スタンバイ状態になったことを契機として、ＭＦＰ１における広告表示が行われることになる。

［ＭＦＰの構成］
次に、ＭＦＰ１の構成について、さらに詳しく説明する。
ＭＦＰ１は、一般に複合機とも呼ばれる機器であり、スキャナ機能、プリンタ機能、コピー機能、ファクシミリ機能、電話機能、写真印刷機能、ネットワーク通信機能などを備えている。このＭＦＰ１は、ＣＰＵ１１、ＲＯＭ１２、ＲＡＭ１３、ＮＶ−ＲＡＭ（Non Volatile RAM）１４、プリント機構１５、スキャナ機構１６、液晶ディスプレイ１７、キースイッチ群１８、メモリカードリーダ／ライタ１９、ネットワークインターフェース２１、モデム２２、ＵＳＢ（Universal Serial Bus）インターフェース２３などを備えている。

これらの内、ＲＯＭ１２には、管理サーバ３のＵＲＬや、印刷中や待機中に表示させるデフォルトの画像データが記憶されている。
ＮＶ−ＲＡＭ１４には、ＭＦＰ１に関する設定等、電源断の際にも消失させたくない各種データが記憶されているが、本実施形態に関連するデータとしては「動作／参照ＵＲＬテーブル（図２（ａ）参照）」、「地域情報（図２（ｂ）参照）」などが記憶されている。

「動作／参照ＵＲＬテーブル」には、動作、ＵＲＬ、および最終更新時間を１組とするデータ群が、複数組（図２では６組）格納され、ＭＦＰ１の動作が決まれば、それに対応するＵＲＬおよび最終更新時間をテーブルから読み出し可能となっている。

本実施形態において、テーブル中の項目「ＵＲＬ」には、各動作に関連した広告の配信元が格納されている。いくつかの具体例を挙げれば、例えば「動作」＝“電話”に対応する「ＵＲＬ」には、電話に関連した広告の配信元が格納され、「動作」＝“スキャナ”に対応する「ＵＲＬ」には、スキャナに関連した広告の配信元が格納され…、といった具合に各「ＵＲＬ」に広告の配信元が格納されている。

また、この「動作／参照ＵＲＬテーブル」に格納された情報は、後述する処理の中で更新される場合があり、広告サーバから新たな広告データを取得した場合に、その広告データの更新日時が「最終更新時間」に格納される。「地域情報」には、ＭＦＰ１の「製品仕向け」（例えば、日本向け、米国向け…等々）と、ＭＦＰ１に割り当てられた「自電話番号」が格納されている。

なお、これら各種データの具体的な利用方法については、後述する処理の中で説明する。
プリント機構１５は、電子写真方式あるいはインクジェット方式といった周知の印刷方式でカラー印刷を実行可能に構成されたもので、後述する「写真印刷機能による印刷」を開始した際には、プリント機構１５による写真の印刷が行われる。

液晶ディスプレイ１７（情報表示手段の一例）は、ＭＦＰ１の状態やその他の情報を表示する装置で、本実施形態においては、広告の表示を行う際に液晶ディスプレイ１７が利用される。

メモリカードリーダ／ライタ１９は、メモリカード１９Ａに対するデータの読み書きを行う装置で、後述する「写真印刷機能による印刷」を開始した際には、メモリカード１９Ａに格納された写真データが読み出されて、プリント機構１５による印刷が行われる。

なお、ＭＦＰ１は、ネットワークインターフェース２１を介して、上述のＬＡＮ５に接続されている。また、ＭＦＰ１は、モデム２２を介して公衆電話網３１に接続され、これにより、ファクシミリ機能、および電話機能が利用可能となっている。さらに、ＭＦＰ１は、ＵＳＢインターフェース２３を介してＰＣ（Personal Computer）３３に接続され、これにより、ＭＦＰ１が備える各種機能をＰＣ３３から制御可能となっている。

［広告サーバおよび管理サーバが管理するデータ］
次に、広告サーバ２Ａ，２Ｂ，２Ｃ，２Ｄおよび管理サーバ３が管理するデータについて、図３および図４に基づいて、さらに詳細に説明する。

広告サーバ２Ａは、ＵＲＬ「ｗｗｗ．△□△□．ｃｏ．ｊｐ」が割り当てられたサーバで、機能的には、広告データの配信のみを行う標準的な広告サーバとなっている。この広告サーバ２Ａにおいては、随時更新可能な広告データとして、複数のイメージファイル（図３には３種を例示）が用意され、それら各イメージファイルの最終更新日時が管理されている。

広告サーバ２Ｂは、ＵＲＬ「ｗｗｗ．△□△×．ｃｏ．ｊｐ」が割り当てられたサーバで、本実施形態では、現在広告データを提供していないサーバとなっている。すなわち、この広告サーバ２Ｂは、過去には広告サーバとして運用されていたものの、現時点では広告サーバとしての運用はなされていないものである。

ただし、広告サーバ２Ｂが広告サーバとしての運用を停止しても、その事実をＭＦＰ１側で認識していない場合、ＭＦＰ１からのアクセスを受ける可能性はある。そのため、広告サーバ２Ｂは、ＭＦＰ１からの広告データ配信要求があった場合、広告データの代わりに、参照先ＵＲＬの変更要求を配信する。このとき配信される「参照先ＵＲＬ」は、広告サーバ２Ａに割り当てられたＵＲＬ「ｗｗｗ．△□△□．ｃｏ．ｊｐ」となっている。

なお、詳しくは後述するが、この参照先ＵＲＬが配信されると、以降、ＭＦＰ１は、広告サーバ２Ｂへのアクセスを行わず、その代わりに、広告サーバ２Ａへのアクセスを行うようになる。

広告サーバ２Ｃは、ＵＲＬ「ｗｗｗ．△□××．ｃｏ．ｊｐ」が割り当てられたサーバで、本実施形態では、上述の広告サーバ２Ｂ同様、参照先ＵＲＬの変更要求を配信するサーバとして機能している。ただし、本実施形態において、この広告サーバ２Ｃは、好ましくない挙動を示す状態に陥っていることを想定しており、これは、本発明を実施する上で理想的には存在しない方がよいものを、あえて例示したものである。

具体的には、この広告サーバ２Ｃから配信される「参照先ＵＲＬ」＝“ｗｗｗ．◆◆◆◆．ｃｏ．ｊｐ”は、第三者によって不正に書き換えられたものとなっている。このＵＲＬは、例えば、その他のサーバ８に割り当てられたＵＲＬなどであり、その他のサーバ８は好ましくないコンテンツ等を配信するサーバなどになっている。

つまり、広告サーバ２Ｃの保持する情報が不正に書き換えられたことが原因で、広告サーバ２Ｃは、その他のサーバ８がアクセス先となるＵＲＬへの変更をＭＦＰ１に要求する状態に陥っているのである。

このような問題に対し、管理サーバ３は、図４に示すようなブラックリストを管理し、ＭＦＰ１が「ｗｗｗ．◆◆◆◆．ｃｏ．ｊｐ」にアクセスするのを制限している。このブラックリストは随時更新される。なお、この制限の具体的手法については、後述する処理の中で説明する。

広告サーバ２Ｄは、ＵＲＬとして「ｗｗｗ．△×△×．ｃｏ．ｊｐ」が割り当てられたサーバで、本実施形態では、地域別に異なる広告データを配信する広告サーバとなっている。

具体的には、この広告サーバ２Ｄにおいては、随時更新可能な広告データとして、複数のイメージファイル（図３には３種を例示）が用意され、それら各イメージファイルの最終更新日時が管理されている。また、この広告サーバ２Ｄにおいては、地域別参照ＵＲＬ変更テーブルが管理されている。

ＭＦＰ１から広告データの配信要求があった場合、広告サーバ２Ｄは、ＭＦＰ１から伝達された地域情報が、地域別参照ＵＲＬ変更テーブル中の「地域」に登録されているか否かを確認し、登録されていなければ、広告データを配信する。一方、登録されていれば、広告データの代わりに、「地域」に対応する「参照ＵＲＬ」をＭＦＰ１に対して配信する。

［ＭＦＰおよび各サーバにおいて実行される処理］
次に、ＭＦＰ１、広告サーバ２Ａ，２Ｂ，２Ｃ，２Ｄ、および管理サーバ３において実行される処理について、図５〜図８に基づいて説明する。なお、この広告配信システムは、状況によってシステムの挙動が変わるので、以下の説明においては、具体的な状況を想定しながら、７つの事例（以下、事例１〜事例７と称する）について説明することにする。

《事例１》：通常に広告を表示する場合
以下に説明する《事例１》は、ＭＦＰ１のアクセス先が広告サーバ２Ａとなっていて、その結果、通常に広告を表示することになる事例である。なお、この広告配信システムは、ＭＦＰ１において、何らかの機能の作動中、もしくは、スタンバイ状態になったことを契機として、ＭＦＰ１における広告表示を行うものであるが、《事例１》〜《事例６》においては「写真印刷機能による印刷」を開始したことを契機として、広告表示を行う場合を想定した説明を行うことにする。

まず、ＭＦＰ１において、メモリカードリーダ／ライタ１９にメモリカード１９Ａがセットされ、ＭＦＰ１において写真印刷機能による印刷を開始すると、それに連動して、ＭＦＰ１は図５に示す処理を開始する。

この処理を開始すると、ＭＦＰ１は、「動作／参照ＵＲＬテーブル」を検索して、写真印刷に対応するＵＲＬの広告サーバ２Ａに広告データを要求する（Ｓ１０５）。この処理ステップＳ１０５（以下、「処理ステップＳ１０５」のことを単に「Ｓ１０５」と表記、他の処理ステップについても同様）において、ＮＶ−ＲＡＭ１４内の「動作／参照ＵＲＬテーブル」において、「動作」＝“写真印刷”に対応するデータ群は、図９（ａ）に例示したような内容になっている。また、ＮＶ−ＲＡＭ１４内の「地域情報」は、図９（ｂ）に例示したような内容になっている。

そして、これらの情報を基に、Ｓ１０５では、図９（ｃ）に例示したような「ＵＲＬ」をアクセス先として、広告サーバ２Ａに広告データの配信が要求され、その際、図９（ｃ）に例示したようなデータ形式で「最終更新時間」、および「製品仕向け情報」と「自電話番号」を含む「地域情報」が、広告サーバ２Ａに伝達されることになる。

こうしてＭＦＰ１から広告サーバ２Ａへ広告データの配信要求が伝達されると、これを契機として、広告サーバ２Ａ側では、図６に示す処理が開始される。
この処理を開始すると、広告サーバ２Ａは、まず、無条件参照ＵＲＬ変更ありか否かを判断する（Ｓ２０５）。ここで、この《事例１》の場合、広告サーバ２Ａは、図３に例示した通り、無条件参照ＵＲＬ変更に関する情報を持っていないので、Ｓ２０５は無条件参照ＵＲＬ変更は“なし”と判断される（Ｓ２０５：なし）。なお、Ｓ２０５で“あり”との判断を行うケースについては、後述する《事例２》において説明する。

続いて、広告サーバ２Ａは、地域別参照ＵＲＬ変更テーブルを参照し、参照先ＵＲＬの変更ありか否かを判断する（Ｓ２１０）。ここで、この《事例１》の場合、広告サーバ２Ａは、図３に例示した通り、「地域別参照ＵＲＬ変更テーブル」を持っていないので、Ｓ２１０では参照ＵＲＬ変更は“なし”と判断される（Ｓ２１０：なし）。なお、Ｓ２１０で“あり”との判断を行うケースについては、後述する《事例４》，《事例５》において説明する。

Ｓ２１０で“なし”との判断を行った場合、広告サーバ２Ａは、ＩＭＡＧＥテーブルを検索し、ＭＦＰ１から送られて来た最終更新時間よりも新しいイメージファイルを抽出する（Ｓ２１５）。そして、抽出結果として、１以上のイメージファイルが得られた場合は（Ｓ２２０：あり）、抽出されたイメージファイルの中で最も古いものと、そのイメージファイルの最終更新時間をＭＦＰ１に対して送信し（Ｓ２２５）、広告サーバ２Ａ側の処理を終了する。

このＳ２２５では、図９（ｄ）に例示したような「イメージファイル」＝“Ｃａｍｅｒａ２．ｉｍｇ”と、そのイメージファイルの「最終更新時間」などが、ＭＦＰ１に伝達されることになる。

なお、Ｓ２２０において、抽出結果として、１つもイメージファイルが得られなかった場合は（Ｓ２２０：なし）、全てのイメージファイルの中で最も古いものと、そのイメージファイルの最終更新時間をＭＦＰ１に対して送信し（Ｓ２３０）、広告サーバ２Ａ側の処理を終了する。

つまり、Ｓ２１５〜Ｓ２３０では、ＭＦＰ１から送られて来た最終更新時間よりも新しいイメージファイルがあれば、その中で最も古いものが広告データとしてＭＦＰ１に配信され、ＭＦＰ１から送られて来た最終更新時間よりも新しいイメージファイルがなければ、広告サーバ２Ａが保持するイメージファイルの中で最も古いものが広告データとしてＭＦＰ１に配信される。

以上のような手順で広告データの配信が行われる際、ＭＦＰ１側では、図５に示すように、広告サーバ２Ａから応答があったか否かを判断する（Ｓ１１０）。ここで、応答がない場合は（Ｓ１１０：なし）、タイムアウトか否かを判断し（Ｓ１１５）、タイムアウトでない場合は（Ｓ１１５：ＮＯ）、短時間（例えば、数秒）の待機を行って（Ｓ１２０）、Ｓ１１０へと戻ることにより、広告サーバ２Ａからの応答を待つ。

そして、広告サーバ２Ａから応答があった場合（Ｓ１１０：あり）、ＭＦＰ１は、広告サーバから配信されたデータを取得し、その応答種別が、広告データとなるイメージファイルの配信であったか、参照ＵＲＬの変更要求であったかを判断する（Ｓ１２５）。

ここで、広告サーバ２Ａの場合は、イメージファイルの配信しか行わないので、Ｓ１２５では“イメージファイル”との判断がなされ（Ｓ１２５：イメージファイル）、その場合、取得した広告データ（イメージファイル）を、液晶ディスプレイ１７に表示する（Ｓ１３０）。

その結果、液晶ディスプレイ１７には、例えば、図３に例示した“Ｃａｍｅｒａ２．ｉｍｇ”に相当する画像が表示されることになる。なお、この“Ｃａｍｅｒａ２．ｉｍｇ”は、写真印刷に関連する製品の広告用写真となっており、写真印刷を行っている利用者にとっては興味のある内容となるので、高い広告効果を期待することができる。

そして、以上のような広告表示を行ったら、ＭＦＰ１は、「動作／参照ＵＲＬテーブル」の「写真印刷」に対応する「ＵＲＬ」の「最終更新時間」を、広告サーバ２Ａから送られた最終更新時間に変更し（Ｓ１４０）、ＭＦＰ１側の処理を終了する。このＳ１４０により、「動作／参照ＵＲＬテーブル」の内容は、図９（ｅ）に例示したような内容に書き換えられることになる。

《事例２》：広告サーバ応答が参照ＵＲＬ変更の場合
（管理サーバブラックリストにＵＲＬが無い場合の例）
次に説明する《事例２》は、ＭＦＰ１のアクセス先が広告サーバ２Ｂとなっていて、その結果、参照ＵＲＬの変更が行われることになる事例である。

ＭＦＰ１において、ＮＶ−ＲＡＭ１４内の「動作／参照ＵＲＬテーブル」が、図１０（ａ）に例示したような内容、「地域情報」が、図１０（ｂ）に例示したような内容になっている場合、既に説明したＳ１０５では、図１０（ｃ）に例示したような「ＵＲＬ」をアクセス先として、広告サーバ２Ｂに広告データの配信が要求され、その際、図１０（ｃ）に例示したようなデータ形式で「最終更新時間」、および「製品仕向け情報」と「自電話番号」を含む「地域情報」が、広告サーバ２Ｂに伝達される。

こうしてＭＦＰ１から広告サーバ２Ｂへ広告データの配信要求が伝達されると、これを契機として、広告サーバ２Ｂ側では、図６に示す処理が開始され、広告サーバ２Ｂは、無条件参照ＵＲＬ変更ありか否かを判断する（Ｓ２０５）。

ここで、広告サーバ２Ｂは、図３に例示したように、無条件参照ＵＲＬ変更に関する情報を持っている。そのため、広告サーバ２Ｂの場合、Ｓ２０５では無条件参照ＵＲＬ変更は“あり”（Ｓ２０５：あり）と判断される。

この場合、広告サーバ２Ｂは、「参照先ＵＲＬ変更要求」と、それに対応する参照先変更ＵＲＬを送信し（Ｓ２３５）、広告サーバ２Ｂ側の処理を終了する。このＳ２３５では、図１０（ｄ）に例示するように、“ＣＨＡＮＧＥ ＵＲＬ”といったテキストデータにて、「参照先ＵＲＬ変更要求」が送信されるとともに、それに対応する参照先変更ＵＲＬとして“ｗｗｗ．△□△□．ｃｏ．ｊｐ”といったＵＲＬ（この事例では、広告サーバ２ＡのＵＲＬ）が送信される。

以上のような手順で参照先ＵＲＬ変更要求の配信が行われる際、ＭＦＰ１側では、図５に示すように、既に説明したＳ１１０〜Ｓ１２０を繰り返すことで、広告サーバ２Ｂからの応答を待っている。

そして、広告サーバ２Ｂから応答があった場合（Ｓ１１０：あり）、ＭＦＰ１は、広告サーバから配信されたデータを取得し、その応答種別が、広告データとなるイメージファイルの配信であったか、参照ＵＲＬ変更要求であったかを判断する（Ｓ１２５）。

ここで、広告サーバ２Ｂの場合は、参照ＵＲＬ変更要求が返されるので、Ｓ１２５では“参照ＵＲＬ変更要求”との判断がなされ（Ｓ１２５：参照ＵＲＬ変更要求）、その場合、参照ＵＲＬ変更要求と同時に受信したＵＲＬが管理サーバ３のブラックリストに記載されているか否かを、管理サーバ３に対して問い合わせる（Ｓ１４５）。

Ｓ１４５では、図１０（ｅ）に例示したような「ＵＲＬ」をアクセス先として、管理サーバ３に更新ＵＲＬの確認が要求され、その際、図１０（ｅ）に例示したようなデータ形式で「確認対象ＵＲＬ」が伝達される。

こうしてＭＦＰ１から管理サーバ３へ問い合わせ（更新ＵＲＬ確認の要求）が伝達されると、これを契機として、管理サーバ３側では、図７に示す処理が開始される。
この処理を開始すると、管理サーバ３は、まず、ブラックリストの問題ＵＲＬに、問い合わせのあったＵＲＬが記載されているか否かを検索し（Ｓ３０５）、記載ありか否かを判断する（Ｓ３１０）。

具体的には、Ｓ３０５では、上記Ｓ１４５によってＭＦＰ１から管理サーバ３へと伝達されたＵＲＬが、図４に例示したブラックリストに登録されているか否かが検索される。図１０（ｅ）に例示した確認対象ＵＲＬ“ｗｗｗ．△□△□．ｃｏ．ｊｐ”の場合であれば、図４に例示したブラックリストには登録されていないので、Ｓ３１０では記載“なし”と判断されることになる（Ｓ３１０：なし）。

この場合、管理サーバ３は、「記載なし（ＮＯ ＬＩＳＴＥＤ）」をＭＦＰ１に送信し（Ｓ３１５）、管理サーバ３側の処理を終了する。Ｓ３１５では、図１０（ｆ）に例示したようなデータ形式で、ブラックリストに記載されていない旨の情報“ＮＯ ＬＩＳＴＥＤ”が送信される。なお、この《事例２》において、“ＮＯ ＬＩＳＴＥＤ”に引き続くデータ格納領域には、特に利用されないダミーデータ（図１０（ｆ）では“ＮＯＮＥ”）が埋め込まれている。このデータ格納領域の利用方法は《事例３》において説明する。

以上のような手順でＵＲＬ確認要求に対する応答が行われる際、ＭＦＰ１側では、図５に示すように、管理サーバ３から応答があったか否かを判断する（Ｓ１５０）。ここで、応答がない場合は（Ｓ１５０：なし）、タイムアウトか否かを判断し（Ｓ１５５）、タイムアウトでない場合は（Ｓ１５５：ＮＯ）、短時間（例えば、数秒）の待機を行って（Ｓ１６０）、Ｓ１５０へと戻ることにより、管理サーバ３からの応答を待つ。

そして、管理サーバ３から応答があった場合（Ｓ１５０：あり）、ＭＦＰ１は、確認対象ＵＲＬがブラックリストに記載されていたか否かを判断する（Ｓ１６５）。
ここで、この《事例２》の場合、広告サーバ２Ｂから配信されたＵＲＬは、上述の通り、ブラックリストに記載されておらず、管理サーバ３からは「記載なし（ＮＯ ＬＩＳＴＥＤ）」という情報が伝達されているので、Ｓ１６５では、記載なしとの判断がなされる（Ｓ１６５：記載なし）。

この場合、ＭＦＰ１は、「動作／参照ＵＲＬテーブル」の写真印刷に対応するＵＲＬを広告サーバから変更要求された新しいものに変更する（Ｓ１７０）。このＳ１７０により、「動作／参照ＵＲＬテーブル」の写真印刷に対応するＵＲＬは、図１０（ｇ）に例示する通り、広告サーバ２ＢのＵＲＬから広告サーバ２ＡのＵＲＬに書き換えられることになる。

そして、ＭＦＰ１は、Ｓ１７０を終えたら、再びＳ１０５へと戻る。これにより、図５に示した処理が最初から再実行されることになる。ただし、この時点では、Ｓ１７０の処理により、「動作／参照ＵＲＬテーブル」の写真印刷に対応するＵＲＬが広告サーバ２ＡのＵＲＬに変更済みなので、引き続いて実行される処理は、既に説明した《事例１》相当の処理となる。

すなわち、Ｓ１０５では、図１０（ｈ）に例示したような「ＵＲＬ」をアクセス先として、広告サーバ２Ａに広告データの配信が要求され、その際、図１０（ｈ）に例示したようなデータ形式で「最終更新時間」、および「製品仕向け情報」と「自電話番号」を含む「地域情報」が伝達される。これに応じて、広告サーバ２Ａからは、Ｓ２２５（またはＳ２３０）により、図１０（ｉ）に例示したような「イメージファイル」＝“Ｃａｍｅｒａ２．ｉｍｇ”と、そのイメージファイルの「最終更新時間」などが、ＭＦＰ１に配信される。そして、ＭＦＰ１は、配信された「イメージファイル」に基づいて広告表示を行うとともに、Ｓ１４０により、「動作／参照ＵＲＬテーブル」の内容を、図１０（ｊ）に例示したような内容に書き換える。以上のような《事例１》相当の処理が実行されることになる。

《事例３》：広告サーバ応答が参照ＵＲＬ変更の場合
（第三者に参照先を書き換えられた広告サーバにアクセス、
且つ、変更先ＵＲＬが管理サーバのブラックリストにある場合の例）
次に説明する《事例３》は、ＭＦＰ１のアクセス先が広告サーバ２Ｃとなっていて、その結果、参照ＵＲＬの変更が行われることになる事例である。

ＭＦＰ１において、ＮＶ−ＲＡＭ１４内の「動作／参照ＵＲＬテーブル」が、図１１（ａ）に例示したような内容、「地域情報」が、図１１（ｂ）に例示したような内容になっている場合、既に説明したＳ１０５では、図１１（ｃ）に例示したような「ＵＲＬ」をアクセス先として、広告サーバ２Ｃに広告データの配信が要求され、その際、図１１（ｃ）に例示したようなデータ形式で「最終更新時間」、および「製品仕向け情報」と「自電話番号」を含む「地域情報」が、広告サーバ２Ｃに伝達される。

こうしてＭＦＰ１から広告サーバ２Ｃへ広告データの配信要求が伝達されると、これを契機として、広告サーバ２Ｃ側では、図６に示す処理が開始され、広告サーバ２Ｃは、無条件参照ＵＲＬ変更ありか否かを判断する（Ｓ２０５）。

ここで、広告サーバ２Ｃは、図３に例示したように、無条件参照ＵＲＬ変更に関する情報を持っているため、既に説明した《事例２》同様、Ｓ２３５により、図１１（ｄ）に例示するように、“ＣＨＡＮＧＥ ＵＲＬ”といったテキストデータにて、「参照先ＵＲＬ変更要求」が送信されるとともに、それに対応する参照先変更ＵＲＬとして“ｗｗｗ．◆◆◆◆．ｃｏ．ｊｐ”といったＵＲＬ（この事例では、その他のサーバ８のＵＲＬ）が送信される。

この“参照ＵＲＬ変更要求”を取得したＭＦＰ１は、図１１（ｅ）に例示したような「ＵＲＬ」をアクセス先として、管理サーバ３に更新ＵＲＬの確認を要求し、その際、図１１（ｅ）に例示したようなデータ形式で「確認対象ＵＲＬ」を、管理サーバ３へ伝達する（Ｓ１４５）。

こうしてＭＦＰ１から管理サーバ３へ問い合わせ（更新ＵＲＬ確認の要求）が伝達されると、これを契機として、管理サーバ３側では、図７に示す処理が開始され、管理サーバ３は、ブラックリストの問題ＵＲＬに、問い合わせのあったＵＲＬが記載されているか否かを検索し（Ｓ３０５）、記載ありか否かを判断する（Ｓ３１０）。

ここで、上記Ｓ３０５までの処理の流れは、上述の《事例２》と全く同様である。しかし、この《事例３》においては、上記Ｓ１４５によってＭＦＰ１から管理サーバ３へと伝達されたＵＲＬがブラックリストに登録されており、この点で《事例２》とは相違する。

すなわち、図１１（ｅ）に例示した確認対象ＵＲＬ“ｗｗｗ．◆◆◆◆．ｃｏ．ｊｐ”の場合、図４に例示したブラックリストに登録されているので、Ｓ３１０では記載“あり”と判断されることになる（Ｓ３１０：あり）。

この場合、管理サーバ３は、「記載あり（ＢＬＡＣＫ ＬＩＳＴＥＤ）」と、ＭＦＰ１から受信したＵＲＬに対応する修正ＵＲＬを送信する（Ｓ３２０）。すなわち、Ｓ３２０では、図１１（ｆ）に例示したようなデータ形式で、ブラックリストに記載されていない旨の情報“ＢＬＡＣＫ ＬＩＳＴＥＤ”が送信される。

また、この“ＢＬＡＣＫ ＬＩＳＴＥＤ”に引き続くデータ格納領域には、上記《事例２》とは異なり、「ＭＦＰ１から受信したＵＲＬに対応する修正ＵＲＬ」が格納されて、これらのデータがＭＦＰ１へと送信される。

なお、「ＭＦＰ１から受信したＵＲＬに対応する修正ＵＲＬ」は、図４に示したブラックリストから読み出されたものであり、図４および図１１（ｆ）に例示した修正ＵＲＬは、広告サーバ２ＡのＵＲＬ“ｗｗｗ．△□△□．ｃｏ．ｊｐ”となっている。

以上のような手順でＵＲＬ確認要求に対する応答が行われるので、ＭＦＰ１は、確認対象ＵＲＬがブラックリストに記載されていたか否かを判断する（Ｓ１６５）。
ここで、この《事例３》の場合、広告サーバ２Ｃから配信されたＵＲＬは、上述の通り、ブラックリストに記載され、管理サーバ３からは「記載あり（ＢＬＡＣＫ ＬＩＳＴＥＤ）」という情報が伝達されているので、Ｓ１６５では、記載ありとの判断がなされる（Ｓ１６５：記載あり）。

この場合、ＭＦＰ１は、「動作／参照ＵＲＬテーブル」の写真印刷に対応するＵＲＬを管理サーバから指定された修正ＵＲＬに変更する（Ｓ１７５）。このＳ１７５により、「動作／参照ＵＲＬテーブル」の写真印刷に対応するＵＲＬは、図１１（ｇ）に例示する通り、広告サーバ２ＣのＵＲＬから広告サーバ２ＡのＵＲＬに書き換えられることになる。

そして、ＭＦＰ１は、Ｓ１７５を終えたら、再びＳ１０５へと戻る。これにより、図５に示した処理が最初から再実行されることになる。ただし、この時点では、Ｓ１７５の処理により、「動作／参照ＵＲＬテーブル」の写真印刷に対応するＵＲＬが広告サーバ２ＡのＵＲＬに変更済みなので、引き続いて実行される処理は、既に説明した《事例１》相当の処理となる。

すなわち、Ｓ１０５では、図１１（ｈ）に例示したような「ＵＲＬ」をアクセス先として、広告サーバ２Ａに広告データの配信が要求され、その際、図１１（ｈ）に例示したようなデータ形式で「最終更新時間」、および「製品仕向け情報」と「自電話番号」を含む「地域情報」が伝達される。これに応じて、広告サーバ２Ａからは、Ｓ２２５（またはＳ２３０）により、図１１（ｉ）に例示したような「イメージファイル」＝“Ｃａｍｅｒａ２．ｉｍｇ”と、そのイメージファイルの「最終更新時間」などが、ＭＦＰ１に配信される。そして、ＭＦＰ１は、配信された「イメージファイル」に基づいて広告表示を行うとともに、Ｓ１４０により、「動作／参照ＵＲＬテーブル」の内容を、図１１（ｊ）に例示したような内容に書き換える。以上のような《事例１》相当の処理が実行されることになる。

《事例４》：広告サーバ応答が通常の広告の場合
（地域別参照ＵＲＬ変更テーブルに基づき、
参照先ＵＲＬを変更しない場合の例）
次に説明する《事例４》は、ＭＦＰ１のアクセス先が広告サーバ２Ｄとなっていて、且つ、参照ＵＲＬの変更が行われない事例である。

ＭＦＰ１において、ＮＶ−ＲＡＭ１４内の「動作／参照ＵＲＬテーブル」が、図１２（ａ）に例示したような内容、「地域情報」が、図１２（ｂ）に例示したような内容になっている場合、既に説明したＳ１０５では、図１２（ｃ）に例示したような「ＵＲＬ」をアクセス先として、広告サーバ２Ｄに広告データの配信が要求され、その際、図１２（ｃ）に例示したようなデータ形式で「最終更新時間」、および「製品仕向け情報」と「自電話番号」を含む「地域情報」が、広告サーバ２Ｄに伝達される。

こうしてＭＦＰ１から広告サーバ２Ｄへ広告データの配信要求が伝達されると、これを契機として、広告サーバ２Ｄ側では、図６に示す処理が開始される。この《事例４》の場合、Ｓ２０５では、上述の《事例１》同様、無条件参照ＵＲＬ変更は“なし”と判断され（Ｓ２０５：なし）、広告サーバ２Ｄは、地域別参照ＵＲＬ変更テーブルを参照し、参照先ＵＲＬの変更ありか否かを判断する（Ｓ２１０）。

ここで、この《事例４》の場合、広告サーバ２Ｄは、図３に例示した通り、「地域別参照ＵＲＬ変更テーブル」を持っているので、Ｓ２１０では参照ＵＲＬ変更は“あり”と判断される（Ｓ２１０：あり）。

Ｓ２１０で“あり”との判断を行った場合、広告サーバ２Ｄは、受信した仕向け国／電話番号を、地域別参照ＵＲＬ変更テーブルで検索し（Ｓ２４０）、検索結果ありか否かを判断する。図１２（ｃ）に例示した「仕向け国／電話番号」は“８１＄＄＄＄＄＄＄＄＄＄”（ただし、“＄”の部分は電話番号で、「地域別参照ＵＲＬ変更テーブル」に登録されていない数字列）であり、Ｓ２４０では、この「仕向け国／電話番号」が、図３に例示した「地域別参照ＵＲＬ変更テーブル」に登録されているか否かを検索する。

そして、この《事例４》の場合、Ｓ２４５では、検索結果なしとの判断がなされ（Ｓ２４５：なし）、その結果、Ｓ２１５へと進むことになる。なお、Ｓ２１５へ進んだ後は、広告サーバ２Ｄでの処理となる点を除き、《事例１》と同様の処理が、広告サーバ２Ｄで行われることになり、その結果、Ｓ２２５では、図１２（ｄ）に例示したような「イメージファイル」＝“ＣａｍｅｒａＣ．ｉｍｇ”と、そのイメージファイルの「最終更新時間」などが、ＭＦＰ１に伝達されることになる。

また、ＭＦＰ１側では、広告サーバ２Ｄから取得した広告データ（イメージファイル）が、液晶ディスプレイ１７に表示され（Ｓ１３０）、「動作／参照ＵＲＬテーブル」の「写真印刷」に対応する「ＵＲＬ」の「最終更新時間」は、広告サーバ２Ｄから送られた最終更新時間に変更され（Ｓ１４０）、ＭＦＰ１側の処理が終了する。このＳ１４０により、「動作／参照ＵＲＬテーブル」の内容は、図１２（ｅ）に例示したような内容に書き換えられることになる。

《事例５》：広告サーバ応答が参照ＵＲＬ変更の場合
（地域別参照ＵＲＬ変更テーブルに基づいて 参照先ＵＲＬを変更、
且つ、管理サーバブラックリストにＵＲＬが無い場合の例）
次に説明する《事例５》は、ＭＦＰ１のアクセス先が広告サーバ２Ｄとなっていて、且つ、参照ＵＲＬの変更が行われる事例である。

ＭＦＰ１において、ＮＶ−ＲＡＭ１４内の「動作／参照ＵＲＬテーブル」が、図１３（ａ）に例示したような内容、「地域情報」が、図１３（ｂ）に例示したような内容になっている場合、既に説明したＳ１０５では、図１３（ｃ）に例示したような「ＵＲＬ」をアクセス先として、広告サーバ２Ｄに広告データの配信が要求され、その際、図１３（ｃ）に例示したようなデータ形式で「最終更新時間」、および「製品仕向け情報」と「自電話番号」を含む「地域情報」が、広告サーバ２Ｄに伝達される。

こうしてＭＦＰ１から広告サーバ２Ｄへ広告データの配信要求が伝達されると、これを契機として、広告サーバ２Ｄ側では、図６に示す処理が開始される。この《事例５》の場合も、Ｓ２０５では、上述の《事例１》、《事例４》同様、無条件参照ＵＲＬ変更は“なし”と判断され（Ｓ２０５：なし）、広告サーバ２Ｄは、地域別参照ＵＲＬ変更テーブルを参照し、参照先ＵＲＬの変更ありか否かを判断する（Ｓ２１０）。

ここで、この《事例５》の場合、広告サーバ２Ｄは、図３に例示した通り、「地域別参照ＵＲＬ変更テーブル」を持っているので、《事例４》同様、Ｓ２１０では参照ＵＲＬ変更は“あり”と判断される（Ｓ２１０：あり）。

Ｓ２１０で“あり”との判断を行った場合、広告サーバ２Ｄは、受信した仕向け国／電話番号を、地域別参照ＵＲＬ変更テーブルで検索し（Ｓ２４０）、検索結果ありか否かを判断する。

図１３（ｃ）に例示した「仕向け国／電話番号」は“８１０５２８２４＊＊＊＊”（ただし、“＊”の部分は電話番号で、「地域別参照ＵＲＬ変更テーブル」に登録されていると見なされる数字列）であり、この《事例５》の場合、Ｓ２４５では、検索結果ありとの判断がなされる（Ｓ２４５：あり）。

この場合、ＭＦＰ１は、「参照先ＵＲＬ変更要求」と「地域別参照ＵＲＬ変更テーブル」に記載された「ＭＦＰより受信した仕向け国／電話番号に対応するＵＲＬ」を参照先変更ＵＲＬとして送信し（Ｓ２５０）、広告サーバ２Ｄ側の処理を終了する。

このＳ２５０では、図１３（ｄ）に例示するように、“ＣＨＡＮＧＥ ＵＲＬ”といったテキストデータにて、「参照先ＵＲＬ変更要求」が送信されるとともに、それに対応する参照先変更ＵＲＬとして“ｗｗｗ．△□△□．ｃｏ．ｊｐ”といったＵＲＬ（この事例では、広告サーバ２ＡのＵＲＬ）が送信される。

なお、この“参照ＵＲＬ変更要求”を取得したＭＦＰ１は、上述の《事例２》と同等な処理を実行することになる。すなわち、図１３（ｅ）に例示したような「ＵＲＬ」をアクセス先として、管理サーバ３に更新ＵＲＬの確認を要求し、その際、図１３（ｅ）に例示したようなデータ形式で「確認対象ＵＲＬ」を、管理サーバ３へ伝達する。

この場合、管理サーバ３も、上述の《事例２》と同等な処理を実行することになり、具体的には、図１３（ｅ）に例示した確認対象ＵＲＬ“ｗｗｗ．△□△□．ｃｏ．ｊｐ”の場合であれば、図４に例示したブラックリストには登録されていないので、管理サーバ３は、図１３（ｆ）に例示したようなデータ形式で、ブラックリストに記載されていない旨の情報“ＮＯ ＬＩＳＴＥＤ”が送信される。

そして、この応答を取得したＭＦＰ１においては、「動作／参照ＵＲＬテーブル」の写真印刷に対応するＵＲＬが広告サーバから変更要求された新しいものに変更され（Ｓ１７０）、「動作／参照ＵＲＬテーブル」の写真印刷に対応するＵＲＬは、図１３（ｇ）に例示する通り、広告サーバ２ＤのＵＲＬから広告サーバ２ＡのＵＲＬに書き換えられることになる。

そして、ＭＦＰ１は、Ｓ１７０を終えたら、再びＳ１０５へと戻る。これにより、図５に示した処理が最初から再実行されることになる。ただし、この時点では、Ｓ１７０の処理により、「動作／参照ＵＲＬテーブル」の写真印刷に対応するＵＲＬが広告サーバ２ＡのＵＲＬに変更済みなので、引き続いて実行される処理は、既に説明した《事例１》相当の処理となる。

すなわち、Ｓ１０５では、図１３（ｈ）に例示したような「ＵＲＬ」をアクセス先として、広告サーバ２Ａに広告データの配信が要求され、その際、図１３（ｈ）に例示したようなデータ形式で「最終更新時間」、および「製品仕向け情報」と「自電話番号」を含む「地域情報」が伝達される。これに応じて、広告サーバ２Ａからは、Ｓ２２５（またはＳ２３０）により、図１３（ｉ）に例示したような「イメージファイル」＝“Ｃａｍｅｒａ２．ｉｍｇ”と、そのイメージファイルの「最終更新時間」などが、ＭＦＰ１に配信される。そして、ＭＦＰ１は、配信された「イメージファイル」に基づいて広告表示を行うとともに、Ｓ１４０により、「動作／参照ＵＲＬテーブル」の内容を、図１３（ｊ）に例示したような内容に書き換える。以上のような《事例１》相当の処理が実行されることになる。

《事例６》：広告サーバ、または管理サーバからの応答がない場合
以下に説明する《事例６》では、上記《事例１》〜《事例５》において、広告サーバ２Ａ〜２Ｄまたは管理サーバ３からの応答がない場合について説明する。

上記《事例１》〜《事例５》において、ＭＦＰ１は、既に説明した通り、Ｓ１１０〜Ｓ１２０により、広告サーバ２Ａ〜２Ｄからの応答を待つ。また、Ｓ１５０〜Ｓ１６０により、管理サーバ３からの応答を待つ。

ただし、何らかの事情で、広告サーバ２Ａ〜２Ｄまたは管理サーバ３からの応答が返らない場合、Ｓ１１５およびＳ１５５では、タイムアウトであるとの判断がなされ（Ｓ１１５：ＹＥＳ）、その場合は、印刷中である旨を液晶ディスプレイ１７に表示して（Ｓ１８０）、ＭＦＰ１側の処理を終了する。

すなわち、広告サーバ２Ａ〜２Ｄから広告データを取得できない場合や、広告サーバ２Ａ〜２Ｄから変更要求された参照ＵＲＬがブラックリストに登録されているか否かについて、管理サーバ３での確認をとれない場合は、広告表示や参照ＵＲＬの変更を行わず、印刷中である旨のデフォルト表示を行う。

《事例７》：記憶済みＵＲＬの更新処理
以下に説明する《事例７》は、上述の《事例１》〜《事例６》とは異なり、ＭＦＰ１において、ある程度の時間が経過したときに実行される処理について説明するものである。この処理は、ＭＦＰ１が起動された後、ＭＦＰ１が待機状態となっている期間に実行される処理である。

この処理を開始すると、図８に示すように、ＭＦＰ１は、待機時間計測タイマをスタートさせる（Ｓ４０５）。このＳ４０５によるスタート後、タイマはハードウェア的にカウントアップされる。そして、ＭＦＰ１は、短時間の待機を行い（Ｓ４１０）、待機時間計測タイマでの計測時間が所定時間（例えば１時間）を経過したか否かを判断し（Ｓ４１５）、経過していない場合は（Ｓ４１５：所定時間（１時間）未経過）、Ｓ４１０へと戻って待機を続ける。

一方、Ｓ４１５において、待機時間計測タイマでの計測時間が所定時間（例えば１時間）を経過したと判断した場合（Ｓ４１５：所定時間（１時間）経過）、ＭＦＰ１は、「動作／参照ＵＲＬテーブル」に記載される「動作」の数（本実施形態の場合“６”）が、変数Ｎの値以下か否かを判断する（Ｓ４２０）。

ここで、Ｓ４２０において、「動作」の数（本実施形態の場合“６”）が変数Ｎの値を超えていれば（Ｓ４２０：Ｎを超える）、変数Ｎに１をセットして（Ｓ４２５）、Ｓ４３０へと進む。また、変数Ｎの値以下であれば（Ｓ４２０：Ｎ以下）、Ｓ４２５をスキップしてＳ４３０へと進む。

こうしたＳ４３０へと進んだら、「動作／参照ＵＲＬテーブル」のＮ番目の動作に対応するＵＲＬが、管理サーバ３のブラックリストに記載されているか否かを、管理サーバ３に対して問い合わせる（Ｓ４３０）。

こうしてＭＦＰ１から管理サーバ３へ問い合わせが伝達されると、これを契機として、管理サーバ３側では、図７に示す処理が開始される。なお、図７に示す処理については、既に上記《事例２》や《事例３》においても説明したので、ここでの説明は省略する。

Ｓ４３０の後、ＭＦＰ１は、管理サーバ３から応答があったか否かを判断する（Ｓ４３５）。ここで、応答がない場合は（Ｓ４３５：なし）、タイムアウトか否かを判断し（Ｓ４４０）、タイムアウトでない場合は（Ｓ４４０：ＮＯ）、短時間（例えば、数秒）の待機を行って（Ｓ４４５）、Ｓ４３５へと戻ることにより、管理サーバ３からの応答を待つ。

そして、管理サーバ３から応答があった場合（Ｓ４３５：あり）、ＭＦＰ１は、確認対象ＵＲＬがブラックリストに記載されていたか否かを判断する（Ｓ４５０）。ブラックリストに記載されていない場合、上記《事例２》でも説明した通り、管理サーバ３からは「記載なし（ＮＯ ＬＩＳＴＥＤ）」という情報が伝達される。また、ブラックリストに記載されている場合は、上記《事例３》でも説明した通り、管理サーバ３からは「ＢＬＡＣＫ ＬＩＳＴＥＤ」という情報が伝達される。

ＭＦＰ１は、管理サーバ３から「ＢＬＡＣＫ ＬＩＳＴＥＤ」という情報が伝達された場合（Ｓ４５０：記載あり）、「動作／参照ＵＲＬテーブル」のＮ番目の動作に対応するＵＲＬを、管理サーバ３から指定された修正ＵＲＬに変更する（Ｓ４５５）。

このようなＳ４５５を実行すれば、過去に「動作／参照ＵＲＬテーブル」に登録済みとなっていたＵＲＬが、その後、管理サーバ３のブラックリストに登録された場合でも、登録済みのＵＲＬを修正ＵＲＬで更新することができる。

なお、Ｓ４５５を終えた場合、Ｓ４５０でブラックリストに記載がなかった場合（Ｓ４５０：記載なし）、またはＳ４４０でタイムアウトと判定された場合は（Ｓ４４０：ＹＥＳ）、いずれの場合とも、変数Ｎをカウントアップして（Ｓ４６０）、Ｓ４０５へと戻る。これにより、以降は、概ね所定時間（１時間）が経過する毎に、変数Ｎに対応する「動作」について、「動作／参照ＵＲＬテーブル」に登録済みとなっていたＵＲＬの確認が行われることになる。

［本実施形態の効果］
以上説明したように、上記広告配信システムによれば、広告サーバ２Ａ〜２Ｄから広告データが配信された場合、ＭＦＰ１は、上記Ｓ１３０によって広告を表示する。一方、広告サーバ２Ａ〜２Ｄから新たなアクセス先のアドレス（ＵＲＬ）が配信された場合、ＭＦＰ１は、Ｓ１７０により、「動作／参照ＵＲＬテーブル（本発明でいうアドレス記憶手段、更新日時記憶手段の一例に相当）」に記憶されたアドレスを新たなアドレスに変更し、Ｓ１０５へと戻ることで、新たなアドレスに対してデータの配信を要求する。

したがって、このような広告配信システムによれば、上記のようなアドレス変更を広告サーバ側で管理することができないシステムとは異なり、《事例２》で示した広告サーバ２Ｂのように、最適と考えられるアドレスをＭＦＰ１に指示することができ、これにより、より最適な広告をＭＦＰ１に表示させることができる。

また、ネットワーク上に多数のクライアント（例えばＭＦＰ１）が存在する場合に、すべてのクライアントからのアクセスが、初期値として設定されたアドレスだけに殺到するのを、アドレス変更によって回避するといったことも可能となる。特に、広告サーバ２Ａ，２Ｂが、ハードウェアとして別々のサーバになっていれば、アドレスの変更を行ってもアクセス先が同一のサーバとなる場合とは異なり、アドレスの変更後は、広告サーバ２Ｂへのアクセスに伴う負荷を、広告サーバＡへ分散させることができる。

また、広告サーバ２Ｄは、ＭＦＰ１から受け取った地域情報に基づいて、地域に対応した広告データを配信するか（＝《事例４》）、ＭＦＰ１が設置された地域に対応した広告データを配信可能なアクセス先のアドレスを配信する（＝《事例５》）。後者（＝《事例５》）の場合、ＭＦＰ１が新たなアクセス先にアクセスすることで、ＭＦＰ１が設置された地域に対応した広告データがＭＦＰ１に対して配信される。

したがって、このような広告配信システムによれば、広告サーバ２Ａ，２Ｄは、ＭＦＰ１が設置された地域に対応した適切な広告データを配信することができる。
また、広告サーバ２Ａ〜２Ｄは、Ｓ２１５〜Ｓ２３０により、ＭＦＰ１側から受け取った更新日時に基づいて、当該更新日時とは異なる更新日時を持つ広告データを、ＭＦＰ１へ配信する。

したがって、このような広告配信システムによれば、既にＭＦＰ１に配信済みの広告データとは、異なる広告データをＭＦＰ１へ配信することができ、ＭＦＰ１は、前回表示された広告とは異なる新たな広告を表示することができる。

さらに、この広告配信システムにおいては、広告サーバ２Ｃのように、何らかの事情で、広告データの取得元として問題のあるアクセス先になっている場合に、そのアドレスが管理サーバ３側でブラックリストに登録される。そして、ＭＦＰ１が、Ｓ１４５により、新たに配信されたアドレスについて管理サーバ３への問い合わせを行った際、問い合わせのあったアドレスがブラックリスト登録済みの制限アドレスであった場合、管理サーバ３はＭＦＰ１に代替アドレス（修正ＵＲＬ）を配信する。

したがって、このような広告配信システムによれば、ＭＦＰ１が制限アドレスへアクセスするのを防止することができる。また、問題のない代替アドレスをＭＦＰ１に通知することで、適切な広告データの配信を行い、適切な広告をクライアントに表示させることができる。

また、既に「動作／参照ＵＲＬテーブル」に登録済みとなっていたＵＲＬについても、Ｓ４３０により、管理サーバ３への問い合わせを行うことができ、問い合わせのあったアドレスがブラックリスト登録済みの制限アドレス（問題ＵＲＬ）であった場合、管理サーバ３はＭＦＰ１に代替アドレス（修正ＵＲＬ）を配信することができる。

加えて、ＭＦＰ１は、広告サーバ２Ａ〜２Ｄ、管理サーバ３から応答が返らない場合に、Ｓ１８０により、デフォルトの表示用データに基づいて情報を表示する。したがって、広告データが取得できないまま、何ら表示ができない状態に陥ったり、管理サーバ３での検証ができなかったＵＲＬに、ＭＦＰ１が不用意にアクセスしてしまったりするのを、回避することができる。

［変形例等］
以上、本発明の実施形態について説明したが、本発明は上記の具体的な一実施形態に限定されず、この他にも種々の形態で実施することができる。

例えば、上記実施形態においては、様々な状況を説明する都合上、４つの広告サーバ２Ａ〜２Ｄを例示したが、少なくとも１つの広告サーバがあれば、本発明の広告配信システムは構成可能である。

また、上記実施形態で例示した広告サーバ２Ｃに関しては、あえて好ましくない状況になっているものを想定して説明を行ったが、このような好ましくない状況になっているものが存在しなくてもよいことはもちろんである。

さらに、上記実施形態で、より好ましい実施形態として、管理サーバ３を設ける事例について説明したが、本発明の最も基本的な構成において、管理サーバ３を設けるか否かは任意である。

加えて、上記実施形態では、「写真印刷機能による印刷」を開始したことを契機として、広告表示を行う場合を例に挙げて詳細に説明したが、図２（ａ）に例示した他の５種の動作についても、同様の広告表示処理を実行できる。なお、図２（ａ）に例示した他の５種の動作の内、「デフォルト」は、ＭＦＰ１がスタンバイ状態になった場合などを想定したものである。

この場合、上記実施形態では「写真印刷機能による印刷」を想定していたため、図３には写真関連の広告として、カメラの広告、フォトプリンターの広告、三脚の広告、写真印刷用紙の広告、ビデオカメラの広告などを例示していたが、他の機能の実行中に表示される広告データは、それら他の機能に対応した内容とされていることが好ましい。

例えば、ファクシミリ機能の作動中であれば、新型ファクシミリ装置の広告や、ファクシミリ用の消耗品の広告を表示する。スキャナ機能の作動中であれば、スキャナ関連の広告を表示する。これらは、「動作／参照ＵＲＬテーブル（図２参照）」に登録されたＵＲＬを、各機能に対応した広告を配信するＵＲＬとすることで実現できる。

すなわち、クライアントは、複数の機能を実行可能に構成され、クライアント側記憶手段には各機能に対応した広告サーバのＵＲＬが記憶され、クライアントが各機能を作動させる際には、その機能に対応したＵＲＬから受信した広告情報を表示させる、という構成を採用することで、利用者が使用している機能に対応した広告の表示を行うことができるので、利用者の関心を引くことができ、広告の効果を高めることができるのである。

また、クライアントは、広告サーバ側へ広告データの配信を要求するタイミングとして、クライアント側の各機能が作動を開始する際に、その機能に対応づけて記憶されているＵＲＬの広告サーバへ広告データを要求すると好ましい。このようなタイミングで広告データを取得すれば、まさに広告の表示が必要となるタイミングで、最新の広告データを取得できるので、表示が必要か否かを問わず、事前に広告データを取得しておくような仕組みを採用した場合に比べ、無駄に広告サーバとの通信が行われる回数を削減することができる。

また、上記実施形態では、ＭＦＰ１が「製品仕向け／自電話番号」を「地域情報」として広告サーバ２Ａ〜２Ｄに伝達する例を示したが、これは、他の情報であってもよい。例えば、独自に取り決めた地域コードを、ＭＦＰ１や広告サーバ２Ａ〜２Ｄが認識できるように構成されていてもよい。あるいは、ＭＦＰ１において設定された使用言語とグリニッジ標準時に対する時差とを、ＭＦＰ１から広告サーバ２Ａ〜２Ｄに伝達し、広告サーバ２Ａ〜２Ｄは、上記使用言語および時差に基づいてＭＦＰ１が設置された地域（国）を特定するようにしてもよい。使用言語は、例えば液晶ディスプレイ１７に文字を表示させるために必要な設定値である。また、グリニッジ標準時はＭＦＰ１の時刻設定に必要な設定値である。このようにＭＦＰ１を使用するにあたって必要な設定値を「地域情報」として用いることで、広告サーバに確実に「地域情報」を送信することができる。

また、広告サーバ２Ａおよび２Ｄは、ＭＦＰ１から送られて来た最終更新時間よりも新しいイメージファイルがあれば、その中で最も古いものが広告データとしてＭＦＰ１に配信され、ＭＦＰ１から送られて来た最終更新時間よりも新しいイメージファイルがなければ、広告サーバ２Ａが保持するイメージファイルの中で最も古いものが広告データとしてＭＦＰ１に配信されるが、これに限られない。例えば、ＭＦＰ１から送られてきた最終更新時間以外の最終更新時間に対応付けられたイメージファイルをランダムに選択して配信してもよい。

なお、上記実施形態では、広告サーバ２Ａ〜２Ｄまたは管理サーバ３から新たなアクセス先であるＵＲＬが送信された場合に、「動作／参照ＵＲＬテーブル」に記憶されていたＵＲＬを新しいＵＲＬに書き換えることによって、ＵＲＬの変更を行っていた。しかし、記憶されていたＵＲＬに追加して新しいＵＲＬを記憶してもよい。

広告配信システムの構成を示したブロック図。 ＭＦＰが記憶するデータについての説明図。 広告サーバが保持するデータについての説明図。 管理サーバが保持するブラックリストの説明図。 ＭＦＰにおいて実行される広告表示処理のフローチャート。 広告サーバにおいて実行される処理のフローチャート。 管理サーバにおいて実行される処理のフローチャート。 ＭＦＰにおいて実行される記憶済みＵＲＬ確認処理のフローチャート。 《事例１》における各種データの説明図。 《事例２》における各種データの説明図。 《事例３》における各種データの説明図。 《事例４》における各種データの説明図。 《事例５》における各種データの説明図。

１・・・ＭＦＰ、２Ａ，２Ｂ，２Ｃ，２Ｄ・・・広告サーバ、３・・・管理サーバ、５・・・ＬＡＮ、６・・・ルータ、７・・・インターネット、８・・・その他のサーバ、１１・・・ＣＰＵ、１２・・・ＲＯＭ、１３・・・ＲＡＭ、１４・・・ＮＶ−ＲＡＭ、１５・・・プリント機構、１６・・・スキャナ機構、１７・・・液晶ディスプレイ、１８・・・キースイッチ群、１９・・・メモリカードリーダ／ライタ、１９Ａ・・・メモリカード、２１・・・ネットワークインターフェース、２２・・・モデム、２３・・・ＵＳＢインターフェース、３１・・・公衆電話網、３３・・・ＰＣ。

Claims (9)

1. ネットワークを介して通信可能な広告サーバとクライアントを備え、前記広告サーバから配信される広告データに基づいて前記クライアントが広告を表示するように構成された広告配信システムであって、
   前記クライアントは、
   前記ネットワーク上のアドレスを記憶するアドレス記憶手段と、
   前記アドレス記憶手段に記憶されたアドレスにアクセスすることにより、前記広告サーバにデータ配信を要求する配信要求手段と、
   前記配信要求手段による要求に応じて前記広告サーバからデータが配信された場合に、当該データを取得するデータ取得手段と、
   前記データ取得手段によって取得されたデータが、前記広告データであった場合に、当該広告データに基づいて広告を表示する情報表示手段と、
   前記データ取得手段によって取得されたデータが、新たなアクセス先のアドレスであった場合に、当該アドレスを前記アドレス記憶手段に記憶させるアドレス更新手段と、
   前記アドレス更新手段によって前記アドレス記憶手段に記憶されたアドレスが更新された場合に、前記配信要求手段による処理以降の処理を再実行させる再実行制御手段と
   を備え、
   前記広告サーバは、
   前記クライアントからデータの提供を要求された場合に、前記広告データまたは前記新たなアクセス先のアドレスのいずれを配信すべきかを判定する配信対象判定手段と、
   前記配信対象判定手段による判定結果に従って、前記広告データまたは前記新たなアクセス先のアドレスのいずれかを配信するデータ配信手段と
   を備え、さらに、
   前記ネットワーク上には、管理サーバが設けられ、
   前記管理サーバは、
   前記クライアントから伝達されたアドレスが、前記クライアントからのアクセスが制限された制限アドレスか否かを判定する制限アドレス判定手段と、
   前記制限アドレス判定手段によって制限アドレスと判定された場合に、その制限アドレスの代わりにアクセスすべき代替アドレスを、前記クライアントに対して配信する代替アドレス配信手段と
   を備え、
   前記クライアントは、
   前記データ取得手段によって取得されたデータが、新たなアクセス先のアドレスであった場合に、当該新たに取得されたアドレスを前記管理サーバに対して伝達することにより、前記新たに取得されたアドレスが前記制限アドレスか否かを問い合わせる新取得アドレス問い合わせ手段
   を備え、
   前記新取得アドレス問い合わせ手段による問い合わせの結果、前記管理サーバから前記代替アドレスが配信された場合には、前記アドレス更新手段は、前記代替アドレスを前記アドレス記憶手段に記憶させる
   ことを特徴とする広告配信システム。
2. ネットワークを介して通信可能な広告サーバとクライアントを備え、前記広告サーバから配信される広告データに基づいて前記クライアントが広告を表示するように構成された広告配信システムであって、
   前記クライアントは、
   前記ネットワーク上のアドレスを記憶するアドレス記憶手段と、
   前記アドレス記憶手段に記憶されたアドレスにアクセスすることにより、前記広告サーバにデータ配信を要求する配信要求手段と、
   前記配信要求手段による要求に応じて前記広告サーバからデータが配信された場合に、当該データを取得するデータ取得手段と、
   前記データ取得手段によって取得されたデータが、前記広告データであった場合に、当該広告データに基づいて広告を表示する情報表示手段と、
   前記データ取得手段によって取得されたデータが、新たなアクセス先のアドレスであった場合に、当該アドレスを前記アドレス記憶手段に記憶させるアドレス更新手段と、
   前記アドレス更新手段によって前記アドレス記憶手段に記憶されたアドレスが更新された場合に、前記配信要求手段による処理以降の処理を再実行させる再実行制御手段と
   を備え、
   前記広告サーバは、
   前記クライアントからデータの提供を要求された場合に、前記広告データまたは前記新たなアクセス先のアドレスのいずれを配信すべきかを判定する配信対象判定手段と、
   前記配信対象判定手段による判定結果に従って、前記広告データまたは前記新たなアクセス先のアドレスのいずれかを配信するデータ配信手段と
   を備え、さらに、
   前記ネットワーク上には、管理サーバが設けられ、
   前記管理サーバは、
   前記クライアントから伝達されたアドレスが、前記クライアントからのアクセスが制限された制限アドレスか否かを判定する制限アドレス判定手段と、
   前記制限アドレス判定手段によって制限アドレスと判定された場合に、その制限アドレスの代わりにアクセスすべき代替アドレスを、前記クライアントに対して配信する代替アドレス配信手段と
   を備え、
   前記クライアントは、
   前記アドレス記憶手段に記憶されたアドレスを前記管理サーバに対して伝達することにより、前記アドレス記憶手段に記憶されたアドレスが前記制限アドレスか否かを定期的または不定期に問い合わせる記憶済みアドレス問い合わせ手段
   を備え、
   前記記憶済みアドレス問い合わせ手段による問い合わせの結果、前記管理サーバから前記代替アドレスが配信された場合には、前記アドレス更新手段は、前記代替アドレスを前記アドレス記憶手段に記憶させる
   ことを特徴とする広告配信システム。
3. 前記クライアントにおいて、
   前記情報表示手段は、前記制限状況問い合わせ手段が前記管理サーバからデータを取得できなかった場合に、予め記憶されているデフォルトの表示用データに基づいて情報を表示する
   ことを特徴とする請求項１または請求項２に記載の広告配信システム。
4. 前記ネットワーク上には、前記広告サーバとして、少なくとも第１，第２の広告サーバを含む複数の広告サーバが設けられ、
   前記第１の広告サーバにおいては、前記配信対象判定手段が前記新たなアクセス先のアドレスを配信すべきと判定した場合に、前記データ配信手段が、前記新たなアクセス先のアドレスとして、前記第２の広告サーバがアクセス先となるアドレスを提供する
   ことを特徴とする請求項１〜請求項３のいずれか一項に記載の広告配信システム。
5. 前記広告サーバは、
   前記クライアントからデータ配信を要求された場合に、前記クライアント側から受け取ったクライアント情報に基づいて、前記クライアントが設置された地域を特定する地域特定手段
   を備え、
   前記配信対象判定手段は、前記地域特定手段によって特定された前記地域に対応した前記広告データを配信可能か否かに基づいて、配信可能な場合は、前記広告データを配信すべきと判定する一方、配信不能な場合は、前記地域特定手段によって特定された前記地域に対応した前記広告データを配信可能なアクセス先のアドレスを配信すべきと判定する
   ことを特徴とする請求項１〜請求項４のいずれか一項に記載の広告配信システム。
6. 前記地域特定手段は、前記クライアントに割り当てられた電話番号を、前記クライアント情報として受け取り、当該電話番号に基づいて前記クライアントが設置された地域を特定する
   ことを特徴とする請求項５に記載の広告配信システム。
7. 前記地域特定手段は、前記クライアントにおいて設定された使用言語とグリニッジ標準時に対する時差とを、前記クライアント情報として受け取り、前記使用言語および前記時差に基づいて前記クライアントが設置された地域を特定する
   ことを特徴とする請求項５に記載の広告配信システム。
8. 前記クライアントは、
   前記広告サーバから配信された前記広告データに関し、当該広告データの更新日時を記憶する更新日時記憶手段
   を備えていて、
   前記配信要求手段が、前記広告サーバにデータ配信を要求する際には、前記更新日時記憶手段に記憶された前記広告データの更新日時を、前記広告サーバへと伝達し、
   前記広告サーバにおいて、
   前記データ配信手段は、前記クライアントからデータ配信を要求された場合に、前記クライアント側から受け取った前記更新日時に基づいて、当該更新日時とは異なる更新日時を持つ前記広告データを、前記クライアントへ配信する
   ことを特徴とする請求項１〜請求項７のいずれか一項に記載の広告配信システム。
9. 前記クライアントにおいて、
   前記情報表示手段は、前記データ取得手段が前記広告サーバからデータを取得できなかった場合に、予め記憶されているデフォルトの表示用データに基づいて情報を表示する
   ことを特徴とする請求項１〜請求項８のいずれか一項に記載の広告配信システム。

Images