携帯通信装置およびその制御プログラム
【課題】不要なデータを削除し、かつ、有用なデータを残す携帯通信装置を提供する。
【解決手段】外部の広告配信用サーバーから広告データを取得し、かつその広告データを再度取得し得るようにインデックスを取得する通信部と、データ格納部と、広告データとインデックスとを対応付けてデータ格納部に格納しかつ削除し得るデータ管理部と、表示部と、表示部に広告データを表示させ、表示させた時刻を閲覧履歴として記録する閲覧制御部とを備え、データ管理部は、データ格納部の空き容量が閾値を下回ったとき、予め定められた第１期間より前に取得されたが取得後に閲覧履歴の記録がない広告データおよび対応付けられたインデックスを削除し、かつ第１期間と等しいかそれより短い第２期間の間に閲覧履歴の記録がない広告データについてその広告データを削除するがそれに対応付けられたインデックスを残す携帯通信装置。
【解決手段】外部の広告配信用サーバーから広告データを取得し、かつその広告データを再度取得し得るようにインデックスを取得する通信部と、データ格納部と、広告データとインデックスとを対応付けてデータ格納部に格納しかつ削除し得るデータ管理部と、表示部と、表示部に広告データを表示させ、表示させた時刻を閲覧履歴として記録する閲覧制御部とを備え、データ管理部は、データ格納部の空き容量が閾値を下回ったとき、予め定められた第１期間より前に取得されたが取得後に閲覧履歴の記録がない広告データおよび対応付けられたインデックスを削除し、かつ第１期間と等しいかそれより短い第２期間の間に閲覧履歴の記録がない広告データについてその広告データを削除するがそれに対応付けられたインデックスを残す携帯通信装置。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、広告配信用サーバーから広告データを取得して表示する携帯通信装置およびその制御プログラムに関する。
【背景技術】
【０００２】
スマートフォンのように通信機能、ウェブサイトの閲覧機能および電子メールの送受信機能を備えたモバイル機器の普及に伴って、広告配信システムが普及している。前記広告配信システムは、広告主である各企業や店舗等から通信を介して複数のモバイル機器に広告としての電子データを送付し、ユーザーは受信した広告を用いてその企業のウェブサイトにアクセスして必要な情報を入手したり、広告に特典として付与されているクーポンをその店舗で利用したりする。非接触技術の発達により、その広告が記憶された端末を、店頭のリーダライタへかざすだけでクーポンとして使用することも可能になっている。また、このような広告は文字が主体のメールマガジンとは異なり静止画や動画を用いることができるためにインパクトが大きく、広告手段として広く普及しつつある。
【０００３】
このように、ユーザーの明示の指示なく蓄積されていくデータの消去に関して、幾つかの技術が提案されている。
まず、特に音楽ソフトや映像ソフトのリッピングに関する技術として次のものが挙ある。記録媒体から読み出したデータを、本登録の指示が為されずとも仮登録データとして記憶媒体に対して記録しておき、本登録データとして記録されるべきデータが上記仮登録データとして記録されていた場合に、記録媒体から該データを読み出してこれを記録するための動作を省略可能とする技術である。さらに、記憶媒体から読み出したデータを仮登録データとして上記記憶手段に対して記録するのに応じ、該データとともにその記録時刻も記録しておく。そして、この記録時刻の情報を元に、上記記憶手段の記憶容量の状態に応じて、仮登録データとして記録されているデータのうち最も記録時刻が古いデータから順に消去可能としていく（例えば、特許文献１参照）。
【０００４】
また、後掲の特許文献２には、次の技術が記載されている。ＣＰＵ１０は、記憶装置１４に蓄積されている画像ファイルの画像種類をプリンタ１５によってプリントするプリンタ画像、ＦＡＸ１６によってファクシミリ送受信するファックス画像、プリンタ１５によって複写するコピー画像、及びスキャナ１７によって入力したスキャナ画像を、各画像ごとに画像管理テーブルに登録する。そして、画像種類ごとに消去する優先順位を付与し、画像ファイルの蓄積の際に記憶装置１４の空き容量を検査し、その検査に基づいて画像ファイルを蓄積する領域の容量が足らないと判断したとき、記憶装置１４から優先順位に基づいて画像ファイルを消去して画像データを蓄積可能な容量の領域を作成する。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００４−３９１１４号公報
【特許文献２】特開２００１−８８３７２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
前述のように、静止画や動画を用いた広告が普及しつつある。一方で、静止画や動画は文字に比べてデータ容量が大きい。配信された広告は、それを受信したモバイル機器の記憶領域に格納されるため、前記記憶領域を圧迫することになりかねない。
これに対して、前記記憶領域に格納された広告データ容量をモニタする機能を設け、データ容量が予め定められた値に達した場合は広告データを削除するという方法が考えられる。しかし、内容にかかわらず広告データを削除してしまうと、ユーザーが必要とする有用な情報まで削除することになりかねない。
【０００７】
あるいは、受信した広告のうちユーザーにとって必要なものにユーザーがチェックをしておき、チェックがついていないものを削除する方法も考えられる。しかし、ユーザーが都度チェックを入れるのは操作が煩雑であり、チェックを付けられた広告が蓄積していくといずれ容量が足りなくなってしまう。
【０００８】
この発明は、以上のような事情を考慮してなされたものであって、ユーザーの明示の指示なく蓄積されるデータによってデータを格納するメモリの空き容量が逼迫したとき、ユーザーの手を煩わすことなく不要なデータを削除しかつユーザーにとって有用なデータを残す携帯通信装置およびその制御プログラムを提供するものである。
【課題を解決するための手段】
【０００９】
この発明は、外部の広告配信用サーバーから広告データを取得し、かつその広告データを前記サーバーから再度取得し得るようにその広告データのインデックスを取得する通信部と、データの格納領域を提供するデータ格納部と、前記通信部が取得した前記広告データおよび前記インデックスを互いに対応付けて前記データ格納部に格納し、かつ前記広告データおよび前記インデックスを削除し得るデータ管理部と、ユーザーによる操作を受付ける操作部と、データを表示する表示部と、前記操作部が受付けた所定の操作に応答して前記表示部に広告データを表示させ、表示させた時刻を閲覧履歴として記録する閲覧制御部とを備え、前記データ管理部は、前記データ格納部の空き容量が閾値を下回ったとき、予め定められた第１期間より前に取得されたが取得後に閲覧履歴の記録がない広告データおよびその広告データに対応付けられたインデックスを削除し、かつ前記第１期間と等しいかそれより短い第２期間の間に閲覧履歴の記録がない広告データについてその広告データを削除するがその広告データに対応付けられたインデックスを残すことを特徴とする携帯通信装置を提供する。
【００１０】
また異なる観点から、この発明は、コンピュータに、外部の広告配信用サーバーから広告データを取得し、かつその広告データを前記サーバーから再度取得し得るようにその広告データのインデックスを取得する通信部と、データの格納領域を提供するデータ格納部に、前記通信部が取得した前記広告データと前記インデックスとを対応付けて格納し、かつ前記広告データおよび前記インデックスを削除し得るデータ管理部と、ユーザーの操作を受付ける操作部が受付けた所定の操作に応答して表示部に広告データを表示させ、表示させた時刻を閲覧履歴として記録する閲覧制御部としての処理を実行させ、前記データ管理部は、前記データ格納部の空き容量が閾値を下回ったとき、予め定められた第１期間より前に取得されたが取得後に閲覧履歴の記録がない広告データおよびその広告データに対応付けられたインデックスを削除し、かつ前記第１期間と等しいかそれより短い第２期間の間に閲覧履歴の記録がない広告データについてその広告データを削除するがその広告データに対応付けられたインデックスを残すことを特徴とする携帯通信装置用の制御プログラムを提供する。
【発明の効果】
【００１１】
この発明の携帯通信装置において、前記データ管理部は、前記データ格納部の空き容量が閾値を下回ったとき、予め定められた第１期間より前に取得されたが取得後に閲覧履歴の記録がない広告データおよびその広告データに対応付けられたインデックスを削除し、かつ前記第１期間と等しいかそれより短い第２期間の間に閲覧履歴の記録がない広告データについてその広告データを削除するがその広告データに対応付けられたインデックスを残すので、最近閲覧されていない広告データは不要なものとしてユーザーの手を煩わすことなく削除し、その一方で、最近閲覧された広告データは再度取得可能なようにインデックスは残しつつ広告データ自体を削除して空き容量を確保することができる。よって、過去に取得した広告データが、利用されることなく無意味に蓄積されていくのを防止することができる。
【００１２】
この発明において、閲覧用広告データは、好ましくは静止画あるいは動画の画像データを含む。また、好ましくは、閲覧用広告データは、インターネット上のウェブサイトで提供される広告であり、携帯通信装置はインターネットに接続してそのウェブサイトを閲覧する機能を有するものである。携帯通信装置の具体的な態様としては、所謂スマートフォンと呼ばれる高機能な携帯電話が代表的な態様である。ただし、この発明はこれに限定されず、電話機能を持たない携帯情報端末や、一般的な携帯電話などを含む。
【００１３】
通信部は、外部のサーバーと通信する。通信の方式は特に限定しないが、例えば携帯電話の通信規格であるＣＤＭＡ−２０００やＷ−ＣＤＭＡ、モバイル端末用のＷｉＭＡＸ、無線ＬＡＮの通信規格であるＩＥＥＥ８０２．１１規格準拠の方式が挙げられる。以上の無線通信に限らず、イーサネット（登録商標）やＵＳＢの有線通信や両者の併用に対応したものであってもよい。前記通信部は、後述する実施形態における端末通信部に対応する。
また、インデックスは、対応する広告データを広告配信用サーバーから取得するために必要な情報であって、広告配信用サーバーのアクセス先や、そのサーバーに格納された広告データのうちで、対象の広告データを特定する情報である。広告データを特定する情報の具体的な態様は、例えば、広告主の企業名あるいは企業ＩＤ、同じ広告主が提供する広告データのいずれのものかを特定するカタログ名あるいはカタログＩＤ、そのカタログの配信日時である。
【００１４】
データ格納部は、データを格納するメモリである。その具体的な態様としては、例えば、スタティックＲＡＭ、ＤＲＡＭあるいはフラッシュメモリが挙げられる。前記データ格納部は、後述する実施形態における格納部に対応する。
また、データ管理部および閲覧制御部は、ＣＰＵあるいはマイクロコンピュータ（以下、簡単のため単にＣＰＵと記す）がメモリに記憶された制御プログラムを実行することによってその機能が実現されるものであってもよい。なお、データ管理部と閲覧制御部とは同じＣＰＵによってその機能が実現されてもよいが、異なるＣＰＵで実現されてもよい。前記データ管理部および前記閲覧制御部は、後述する実施形態における端末制御部によって実現される機能の一部に相当する。
【００１５】
表示部は、前記通信部が受信した情報、装置の状態、操作に係る情報やオブジェクトをユーザーに提示するものである。その具体的な態様は、例えば、液晶表示装置や有機ＥＬ表示装置である。操作部は、ユーザーによる操作を受付けるもので、その具体例としては、前記表示部の表面に配置されるタッチパネルが挙げられる。この場合、操作部の一要素として前記表示装置に操作ボタン等のオブジェクトを表示してもよい。
【図面の簡単な説明】
【００１６】
【図１】この発明の携帯通信装置としての端末およびその携帯通信装置と通信する広告配信用サーバーの構成を示すブロック図である。
【図２】図１の配信スケジュールデータベースに登録されるデータの一例を示す説明図である。
【図３】図１のカタログデータベースに登録されるデータの一例を示す説明図である。
【図４】図１の格納部に格納されるデータの一例を示す説明図である。
【図５】この発明に係る端末制御部が実行する処理の例を示す第１のフローチャートである。
【図６】この発明に係る端末制御部が実行する処理の例を示す第２のフローチャートである。
【図７】この発明の携帯通信装置と通信するサーバーの広告配信処理の一例を示すフローチャートである。
【発明を実施するための形態】
【００１７】
以下、この発明の好ましい態様について説明する。
前記データ管理部は、前記データ格納部にインデックスが格納されている広告データについては前記操作部が再表示の操作を受付けることを許容し、その再表示の操作に応答して前記データ格納部に広告データが格納されているか否かを判断し、格納されていないときは前記インデックスを用いて前記サーバーの広告データを前記通信部に再度取得させてもよい。このようにすれば、最近閲覧された広告データについては、再表示の操作によって広告データの閲覧が可能となり、その際にデータ管理部は、データ格納部に格納されたインデックスを用いて前記サーバーにアクセスし広告データを取得することができる。
【００１８】
また、前記データ管理部は、前記閲覧制御部により前記広告データの閲覧のため表示がなされその閲覧が終了した後、前記広告データを前記データ格納部から削除してもよい。このようにすれば、広告データの閲覧がなされた後にその広告データが削除されインデックスのみ残されるので、広告データを残す場合に比べてデータ格納部の空き容量を確保しておくことができる。
【００１９】
前記データ管理部は、空き容量が前記閾値を下回ったとき、前記閲覧履歴の記録がある広告データについて、前記サーバーの広告データが取得された後に更新されているか否かを前記通信部に前記サーバーとの通信を行わせて問合せ、更新されている場合、その広告データと対応するインデックスとを前記サーバーから取得し、前記データ格納部に格納してもよい。このようにすれば、ユーザーの手を煩わすことなく広告データが更新され、再表示の操作を受付けたときに最新の内容をユーザーに提供することができる。
この発明の好ましい態様は、ここで示した複数の態様のうち何れかを組み合わせたものも含む。
【００２０】
以下、図面を用いてこの発明をさらに詳述する。なお、以下の説明は、すべての点で例示であって、この発明を限定するものと解されるべきではない。
この発明は、広告配信用のサーバーとそのサーバーから広告が配信される一以上の携帯通信装置（以下、端末ともいう）で構成される。
前記サーバーは、配信すべき広告の電子データを格納しており、前記端末に対して電子データを送信する。前記端末は、前記サーバーからの電子データを受信し、その電子データをデータ格納部の記憶領域に一旦格納し、電子データが表す広告をユーザーに提示する。前記サーバーの具体的な態様は、インターネットを介して外部とやり取り可能なファイルサーバである。前記端末の具体的態様の一例はインターネットにアクセス可能なスマートフォンである。
【００２１】
≪携帯通信装置および広告配信用サーバーの構成≫
図１は、この発明の携帯通信装置としての端末およびその携帯通信装置と通信する広告配信用サーバーの構成を示すブロック図である。図１に示すように、端末１１は、端末制御部１３、端末通信部１５、表示部１７、操作部１９および格納部２１を有する。また、サーバー３１は、サーバー通信部３３、サーバー制御部３５、配信スケジュールデータベース３７およびカタログデータベース３９を有する。
サーバー制御部３５は、サーバー３１の中核をなす中央処理装置（ＣＰＵ）およびそのＣＰＵが動作するための周辺回路、例えば、バス、メモリ、割り込み等の制御に係るハードウェアおよびソフトウェアに対応する。サーバー通信部３３は、端末１１や他の図示しない外部の機器と通信を行うためのインターフェイス回路および通信制御ソフトウェアに対応する。
【００２２】
配信スケジュールデータベース３７は、広告主である企業等から配信を依頼されたカタログデータの配信に係るデータを格納するデータベースである。カタログデータは、この発明の広告データに相当する。ここで、配信に係るデータとは、各カタログデータをいつ、どの配信グループへ配信を行うかといった配信スケジュールに係るデータである。この配信スケジュールに従って、サーバー制御部３５が各端末へカタログデータの配信を行うように制御する。
【００２３】
図２は、図１の配信スケジュールデータベース３７に登録されるデータの一例を示す説明図である。図２に示すように、登録されるデータは、配信日時、カタログID、カタログ名、企業名、企業ID、配信先で構成されている。カタログIDは、後述のカタログデータベース３９のカタログIDと一致しており、カタログIDを参照することによって両者の対応が得られる。カタログIDは、各カタログを他のカタログと識別するために各カタログに割り当てられる固有のデータである。カタログ名は人間がカタログの内容を認識しやすいように付与された名称である。企業IDは、各広告主を他の広告主と識別するため各広告主に割り当てられる固有のデータである
【００２４】
サーバー制御部３５は、配信スケジュールデータベース３７を参照して、配信日時が到来したカタログのカタログIDを参照する。また、そのカタログの配信先を取得する。そして、カタログデータベース３９を参照し、同一のカタログIDを有するカタログのデータを読み出して端末１１や他の図示しない端末のうち前記配信先に登録された端末にそのデータを配信する。
カタログデータベース３９は、広告データの実体であるカタログデータを格納するデータベースである。
【００２５】
図３は、図１のカタログデータベース３９に登録されるデータの一例を示す説明図である。図３に示すように、登録されるデータは、カタログＩＤ、カタログ名およびカタログデータ自体である。カタログデータベース３９に格納されたカタログデータは、カタログIDおよびカタログ名を用いて管理される。
サーバー通信部３３は、サーバー３１からのカタログ配信データを配信先の端末に配信する機能を有している。
【００２６】
サーバー制御部３５は、サーバー３１が実行すべきデータの処理や管理を行う。サーバー制御部３５が実行する処理は、配信スケジュールデータベース３７に登録されたカタログのうち配信日時が到来したものを決定する処理を含む。さらに、決定されたカタログに係るカタログIDを用いて、カタログデータベース３９に格納されたカタログデータを呼び出す処理および呼び出したカタログデータを登録された配信先へ配信する処理を含む。
端末１１は、この発明の携帯通信端末装置であって、広告データの配信先である端末の代表例として図１に示している。端末１１および図示しない他の端末は、固有の端末IDを有している。配信スケジュールデータベース３７には、この端末IDをグループ化した配信先が登録されている。サーバー制御部３５は、配信スケジュールデータベース３７に登録された配信先に基づいて、それぞれの広告データの配信先を特定する。
【００２７】
端末制御部１３は、端末通信部１５、表示部１７、操作部１９および格納部２１の動作を制御するもので、その構成要素としてＣＰＵ、その周辺回路およびＣＰＵが実行する制御ソフトウェアを含む。端末制御部１３は、端末１１とサーバー３１との間における通信の制御、サーバー３１から受信するデータの管理、例えば、格納部２１の空き容量が閾値に満たなくなった場合のデータの削除など各種の制御を行う。
端末通信部１５は、サーバー３１からカタログデータの配信や、再度の取得などに係る通信を行うための通信インターフェイス回路およびその制御ソフトウェアである。この実施形態においては、無線LANの通信方式が用いられるものとしている。
表示部１７は、端末１１の状態やユーザーによる操作に応じた表示やメッセージをユーザーに提供するものである。この実施形態においては、液晶表示装置が用いられるものとする。端末制御部１３は、表示部１７に表示させる内容を制御する。表示の内容には、カタログデータの受信、カタログデータの削除、カタログデータが更新された旨のメッセージが含まれる。
【００２８】
操作部１９は、端末１１に対するユーザーの操作を受付ける。この実施形態では、表示部１７の表面に配置されるタッチパネルである。
格納部２１は、カタログデータおよびそれに付加されるデータを格納する読み書き可能な不揮発性メモリである。この実施例において、格納部２１はさらに閲覧履歴を格納する。また、端末制御部１３が実行する制御プログラムを格納する。
サーバー３１から配信されたカタログデータは、配信先の一つである端末１１の端末通信部１５を経由して、格納部２１に配信の都度格納されていく。
【００２９】
図４は、図１の格納部２１に格納されるデータの一例を示す説明図である。図４に示すように、格納部２１は、「配信日時」、「カタログID」、「カタログ名」、「企業名」、「企業ID」、「カタログデータ」、「閲覧履歴」および「目次のみ」の各項目についてデータを格納する。それらの項目のうち、「配信日時」、「カタログID」、「カタログ名」、「企業名」および「企業ID」は、配信スケジュールデータベース３７に登録されたものと同一であって、カタログデータと共にサーバー３１から提供される。端末制御部１３は、サーバー３１から配信されるそれらのデータをカタログデータと共に格納部２１に格納する。これら、カタログデータ以外の項目は、この発明のインデックスに相当する。
【００３０】
「閲覧履歴」の項目は、配信されたカタログデータをユーザーが閲覧したか否かを示すデータである。初期値は、「無」である。端末制御部１３は、カタログデータが閲覧された場合に、閲覧されたカタログの「閲覧履歴」に対して「有」を示すデータを格納する。また、端末制御部１３は、後述のカタログデータ削除時に、「閲覧履歴」が「有」の場合には、カタログデータの削除を行わず、更新されたカタログデータがあるか否かの問合せをサーバー３１に対して行う。
【００３１】
更新されたカタログデータがサーバー３１にある場合には、そのカタログデータを受信して格納部２１のカタログデータを置き換える。一方、サーバー３１のカタログデータが更新されていない場合は、格納部２１のカタログデータを削除し、さらに、「目次のみ」の項目に目次のみ格納されている旨を示すデータを格納する。図４の「○」印に相当するものである。なお、初期値は、目次が格納されていないかまたはカタログデータが格納されていることを示すデータである。図４の無印に相当するものである。図４で「目次のみ」の「○」印は、カタログデータ自身は格納部２１に格納されていないが、ユーザーが閲覧を希望する場合にはサーバー３１にアクセスしてカタログデータを取得し閲覧することが可能であることを示している。
【００３２】
すなわち、端末制御部１３は、格納部２１の空き容量が閾値に満たなくなった場合に、格納部２１に格納されているデータの一部を削除して、空き容量を確保する。削除するデータは、「閲覧履歴」の有無に基づいて決定する。さらにこのとき、「閲覧履歴」が「有」のカタログデータを単に残すだけでなく、カタログデータを自動更新するかあるいは大きな容量を占めるカタログデータを削除して、必要に応じてサーバー３１から取得できるようにしておくのである。
以上の処理によって端末制御部１３は、配信されたカタログデータが活用されないまま格納部２１に蓄積されることを防止し、格納部２１の空き容量を確保する。
【００３３】
≪端末制御部の処理≫
続いて、端末制御部１３が実行する処理の例を説明する。
図５および図６は、この発明に係る端末制御部が実行する処理の例を示すフローチャートである。この発明に関連する処理のみを記載している。前記処理は、サーバー３１から配信されるカタログデータを受信して格納部２１に格納する処理を含む。さらに、格納部２１の空き容量が少ないときに格納部２１に格納されたデータの一部を削除する処理を含む。また、サーバー３１にアクセスして更新されたカタログデータを取得する処理および操作部が受付けた所定の操作に応答してカタログデータを閲覧する処理を含む。
【００３４】
以下、フローチャートに沿って端末制御部が実行する処理を説明する。図５に示すように、端末制御部１３は、外部からデータを受信した場合に、そのデータが広告データ、即ち、サーバー３１から配信されたカタログデータか否かを判断する（ステップＳ１１）。カタログデータでなければ（ステップＳ１１のＮｏ）、ルーチンは後述するステップＳ５１へ進み、閲覧に関する処理を行う。
【００３５】
受信したデータがカタログデータであれば（ステップＳ１１のＹｅｓ）、端末制御部１３は、そのカタログデータおよびカタログデータに付加されている「配信日時」、「カタログID」、「カタログ名」、「企業名」および「企業ID」のデータを格納部２１に格納する（ステップＳ１３）。また、図示していないが、受信したカタログデータに係るバナーを表示部１７の一部の表示領域に表示させてもよい。あるいは、この時点で即座に表示するのではなく、ユーザーがカタログデータに関連する内容について検索や閲覧を行ったときに、表示部１７の一部にバナーを表示させてもよい。
【００３６】
続いて、端末制御部１３は、格納部の空き容量が閾値を下回ったか否かを調べる（ステップＳ１５）。この閾値は、受信データを格納するメモリ領域の容量に対して予め定められている。なお、変形例として端末１１のユーザーがこの閾値を設定、変更可能であってもよい。
空き容量が閾値を下回っておらずまだ十分な余裕があると判断した場合（ステップＳ１５のＮｏ）、端末制御部１３は、後述するステップＳ５１へ進み、閲覧に関する処理を行う。一方、格納部２１の空き容量が閾値を下回っていると判断した場合（ステップＳ１５のＹｅｓ）、端末制御部１３は、格納部２１に格納されたデータの一部を削除する処理を行う。即ち、端末制御部１３は、カタログの閲覧履歴を参照する（ステップＳ１７）。この実施形態でカタログの閲覧履歴は、格納部２１に格納されているものとしている。ただし、これに限定されるものでなく、格納部２１と別の、図１に図示しない不揮発性メモリに格納されていてもよい。
【００３７】
続いて端末制御部１３は、図４に示す格納部２１に格納されたデータを参照しながら、格納部に格納されたカタログデータのうち「閲覧履歴」が「無」のデータを抽出し（ステップＳ１９）、以下の処理を行う。まず、受信した後に一度も閲覧されていないカタログデータを抽出する。抽出されたカタログデータは、ユーザーにとって興味のないものかあるいは受信してからの期間が短いものと考えられる。そこで、端末制御部１３は、「配信日時」に基づいて、抽出されたカタログデータが現時点から二週間より前に受信されたものか否かを調べる（ステップＳ２１）。勿論、二週間という期間は一例であってこれに限定されるものではない。また、この期間がユーザーによって設定および変更可能であってもよい。
【００３８】
カタログデータが二週間より前に受信されたものの場合（ステップＳ２１のＹｅｓ）、端末制御部１３はそのカタログデータおよびそのカタログデータに係るインデックスを削除する（ステップＳ２３）。ユーザーにとって興味のないものと考えられるからである。受信後二週間が経過していない場合は（ステップＳ２１のＮｏ）削除しない。続いて、端末制御部１３は、抽出された全てのカタログデータについて受信後の経過期間を判断したか調べる（ステップＳ２５）。また、判断していないカタログデータが残っている場合（ステップＳ２５のＮｏ）、ルーチンは残りのカタログデータのうち次のものを対象として（ステップＳ２７）、前述のステップＳ２１に戻り、残りのカタログデータについて受信後の経過期間を判断する。
【００３９】
抽出された全てのカタログデータについて受信後の経過期間を判断したら（ステップＳ２５のＹｅｓ）、端末制御部１３は閲覧履歴があるカタログデータを抽出し（ステップＳ２９）、以下の処理を行う。まず、端末制御部１３は、「配信日時」に基づいて、抽出されたカタログデータが現時点から遡って一週間以内に閲覧されているか否かを調べる（ステップＳ３１）。一週間以内に閲覧されていない場合、そのカタログデータはユーザーにとって繰り返し閲覧する程の興味はないものと考えられる。勿論、一週間という期間は一例であってこれに限定されるものではない。ただし、この期間（以下、第２期間とする）は、前記ステップＳ２１で判断基準とされる期間（以下、第１期間とする）と等しいかそれよりも短い。第１期間より前に取得されたが閲覧履歴の記録がないカタログデータについては、ステップＳ２１の判定およびステップＳ２３の処理で格納部２１から削除されている。よって、このステップＳ３１では前記第１期間の以後に取得されたが閲覧履歴の記録がないものを対象にするのが合理的である。ステップＳ２１およびＳ２３と重複する処理を避けるためである。なお、この第２期間がユーザーによって設定および変更可能であってもよい。
【００４０】
カタログデータが一週間以上閲覧されていない場合（ステップＳ３１のＹｅｓ）、端末制御部１３はそのカタログデータを削除する（ステップＳ３３）。ただし、そのカタログデータに係るインデックスは削除せずに残しておく。ユーザーにとって全く興味のないものとまではいえないため、再度閲覧される可能性があるからである。直近一週間の間に閲覧されている場合は（ステップＳ３１のＮｏ）カタログデータを削除しない。続いて、端末制御部１３は、抽出された全てのカタログデータについて直近の閲覧の有無を判断したか調べる（ステップＳ３５）。また、判断していないカタログデータが残っている場合（ステップＳ３５のＮｏ）、ルーチンは残りのカタログデータのうち次のものを対象として（ステップＳ３７）、前述のステップＳ３１に戻り、残りのカタログデータについて直近の閲覧の有無を判断する。
【００４１】
抽出された全てのカタログデータについて受信後の経過期間を判断した後（ステップＳ３５のＹｅｓ）、端末制御部１３は閲覧履歴のあるカタログデータについてカタログID、企業IDおよび配信日時を配信元のサーバー３１に送信し、カタログデータが更新されているか否かを問い合わせる（ステップＳ３９）。カタログIDだけでなく企業IDを送信するのは、同一カタログIDの更新を調べるだけでなく、同一企業の他のカタログIDの更新有無および新たなカタログIDの有無を調べて更新および／または新たに追加されたカタログデータを取得できるようにするためである。ここで、図５のフローチャートでは、閲覧履歴のある全てのカタログデータについて問合せを行うようにしている。変形例として、前記ステップＳ３１で判断基準とされた期間（一週間）内に閲覧があったカタログデータのみについて問合せを行うようにしてもよい。
【００４２】
問合せの後、端末制御部１３はサーバー３１からの回答を待つ（ステップＳ４１）。説明を簡単にするためステップＳ４１のフローチャートはループしているが、この間に端末制御部としてのＣＰＵは当然ながら他の処理を並行して行ってもよい。サーバー３１からの回答に更新されたカタログデータが付与されていた場合（ステップＳ４３）、端末制御部１３は、受信したカタログデータを格納部２１の該当する記憶領域に格納する（ステップＳ４５）。そして、ルーチンは前述のステップＳ１１へ戻り、新たなカタログデータの受信に備えて待機する。なお、サーバー３１からの回答に更新されたカタログデータが付与されていない場合（ステップＳ４３のＮｏ）も、ルーチンはステップＳ１１へ戻って待機する。
【００４３】
続いて、端末制御部１３が実行する閲覧の処理について図６のフローチャートに沿って説明する。
図５におけるステップＳ１１の判定がＮｏまたは図５のステップＳ１５の判定がＮｏの場合、続いて端末制御部１３は、カタログデータの閲覧の処理を行う。まず、端末制御部１３は、操作部１９が、カタログの閲覧を指示する操作を受付けているか否かを調べる（図６のステップＳ５１）。この操作は、例えば、表示部１７に表示されたバナーにユーザーがタッチするなど、予め定められた操作である。
【００４４】
閲覧の指示に係る操作が受付けてられていないとき、端末制御部１３は閲覧に係る処理を何も行わず、ルーチンは前述のステップＳ１１へ進む。一方、閲覧の指示に係る操作が受付けてられている場合、端末制御部１３は、その操作に対応するカタログデータが格納部２１に格納されているか否かを調べる（ステップＳ５３）。カタログデータが格納されている場合は（ステップＳ５３のＹｅｓ）、そのカタログデータを格納部２１から読み出して表示部１７に表示させる（ステップＳ５５）。表示を終えた後、ルーチンは前述のステップＳ１１へ進む。
【００４５】
一方、カタログデータが格納されていない場合（ステップＳ５３のＮｏ）、端末制御部１３は格納部２１に格納されているそのカタログデータに係るインデックスを用いて、サーバー３１にカタログデータを要求する（ステップＳ５７）。この要求には、取得すべきカタログデータのカタログIDを付加する。なお、格納部２１からカタログデータもインデックスも削除されたものについては、そもそもバナーを表示部１７に表示させないように端末制御部１３が制御している。
【００４６】
端末制御部１３は、カタログデータの要求に対するサーバー３１からの回答を待つ（ステップＳ５９）。サーバー３１からの回答を受信したら（ステップＳ５９のＹｅｓ）、端末制御部１３は、回答にカタログデータが付加されているか否かを調べる（ステップＳ６１）。カタログデータが付加されてない場合（ステップＳ６３）、サーバー３１との通信が確立できなかったり、その広告データの配信サービスが終了していたりする何らかの事情によってカタログデータが取得できなかった旨を表示部１７に表示させる（ステップＳ６３）。そして、ルーチンは前述のステップＳ１１へ進む。
【００４７】
一方、サーバーからの回答にカタログデータが付加されていたら（ステップＳ６１のＹｅｓ）、受信したカタログデータを格納部２１に格納し、かつ、表示部１７に表示させる（ステップＳ６５）。そして、ユーザーがそのカタログデータの閲覧を終了するのを待って（ステップＳ６７）、受信したカタログデータを格納部２１から削除する（ステップＳ６９）。そして、ルーチンは前述のステップＳ１１へ進む。
以上が、端末制御部１３が実行する処理である。
【００４８】
≪サーバー制御部の処理≫
続いて、端末１１と通信するサーバー３１側の広告配信処理について説明する。
図７は、この発明の携帯通信装置と通信するサーバーの広告配信処理の一例を示すフローチャートである。図７の処理は、図１に示すサーバー制御部３５により実行される。図７に沿って処理の手順を説明する。
【００４９】
サーバー３１のカタログデータベース３９には、配信すべきカタログデータが格納され、配信スケジュールデータベース３７には、前記カタログデータについての配信スケジュールが格納されている。サーバー３１は、例えば、広告配信サービスを提供する事業者が管理しており、前記事業者は、広告主との契約に応じてカタログデータベース３９および配信スケジュールデータベース３７にデータを登録し、かつ、登録されたデータを更新したり削除したりする。
【００５０】
サーバー制御部３５は、リアルタイムクロックを含んでおり、図２に示す配信スケジュールデータベースに格納された各データの「配信日時」が到来したか否かを逐次監視する。何れかのカタログデータについて配信日時が到来したとき（ステップＳ１０１のＹｅｓ）、対応するカタログIDに基づいてカタログデータベース３９からカタログデータを読み出して、対応する「配信先」として定義された端末に配信する。その際、カタログデータに「配信日時」、「カタログID」、「カタログ名」、「企業名」および「企業ID」を付加する。そして、ルーチンは次のステップＳ１０５へ進む。
【００５１】
前記ステップＳ１０１で、配信日時の到来したものがなかったときは（ステップＳ１０１のＮｏ）、ルーチンはステップＳ１０５へ進む。
ステップＳ１０５へ進み、端末側からカタログデータの更新有無の問合せを受けた場合の処理を行う。即ち、端末１１および図１に図示しない他の何れかの端末からカタログデータの更新有無の問合を受けたか否かを調べる。なお、前記問合せにはカタログIDと企業IDが付加されている。前記問合せを受信していない場合（ステップＳ１０５のＮｏ）、ルーチンは後述するステップＳ１２１へ進み、カタログデータの要求を受けた場合の処理を行う。
【００５２】
一方、前記問合せを受信した場合は（ステップＳ１０５のＹｅｓ）、その問合せに付加された企業IDおよび配信日時に基づいて、その企業の他のカタログデータについても更新されたものがあるかを調べ、かつ、新たに追加されたカタログデータが有るかを調べる（ステップＳ１０７）。更新あるいは追加されたものがなければ（ステップＳ１０９のＮｏ）、問合せ元の端末へその旨を送信する（ステップＳ１１３）。一方、更新あるいは追加されたものがあれば（ステップＳ１０９のＹｅｓ）、そのカタログデータに「配信日時」、「カタログID」、「カタログ名」、「企業名」および「企業ID」を付加して問合せをした端末へ送信する（ステップＳ１１５）。そして、ルーチンは前述のステップＳ１０１へ戻り配信日時が到来したか否かの監視を続ける。
【００５３】
次に、カタログデータの要求を受けた場合の処理について説明する。前記ステップＳ１０５の判定がＮｏの場合に続けて実行する処理である。サーバー制御部３５は、端末１１および図１に図示しない何れかの端末からカタログデータの要求を受けたか否かを調べる（ステップＳ１２１）。要求がなければ（ステップＳ１２１のＮｏ）、ルーチンは前述のステップＳ１０１へ進む。
【００５４】
要求を受けた場合（ステップＳ１２１のＹｅｓ）、サーバー制御部３５は、その要求に付加されたカタログIDに対応するカタログデータがカタログデータベース３９に格納されているか否かを調べる（ステップＳ１２３）。カタログデータがあれば、要求を送信した端末にそのカタログデータを送信する（ステップＳ１２７）。カタログデータがすでに削除されている等の事情により対応するカタログデータが見つからない場合、サーバー制御部３５は、該当するカタログデータがない旨を前記端末に送信する（ステップＳ１２９）。そして、ルーチンは前述のステップＳ１０１へ進む。
以上が、サーバー側の処理である。
【００５５】
前述した実施の形態の他にも、この発明について種々の変形例があり得る。それらの変形例は、この発明の範囲に属さないと解されるべきものではない。この発明には、請求の範囲と均等の意味および前記範囲内でのすべての変形とが含まれるべきである。
【符号の説明】
【００５６】
１１：端末
１３：端末制御部
１５：端末通信部
１７：表示部
１９：操作部
２１：格納部
３１：サーバー
３３：サーバー通信部
３５：サーバー制御部
３７：配信スケジュールデータベース
３９：カタログデータベース
【技術分野】
【０００１】
この発明は、広告配信用サーバーから広告データを取得して表示する携帯通信装置およびその制御プログラムに関する。
【背景技術】
【０００２】
スマートフォンのように通信機能、ウェブサイトの閲覧機能および電子メールの送受信機能を備えたモバイル機器の普及に伴って、広告配信システムが普及している。前記広告配信システムは、広告主である各企業や店舗等から通信を介して複数のモバイル機器に広告としての電子データを送付し、ユーザーは受信した広告を用いてその企業のウェブサイトにアクセスして必要な情報を入手したり、広告に特典として付与されているクーポンをその店舗で利用したりする。非接触技術の発達により、その広告が記憶された端末を、店頭のリーダライタへかざすだけでクーポンとして使用することも可能になっている。また、このような広告は文字が主体のメールマガジンとは異なり静止画や動画を用いることができるためにインパクトが大きく、広告手段として広く普及しつつある。
【０００３】
このように、ユーザーの明示の指示なく蓄積されていくデータの消去に関して、幾つかの技術が提案されている。
まず、特に音楽ソフトや映像ソフトのリッピングに関する技術として次のものが挙ある。記録媒体から読み出したデータを、本登録の指示が為されずとも仮登録データとして記憶媒体に対して記録しておき、本登録データとして記録されるべきデータが上記仮登録データとして記録されていた場合に、記録媒体から該データを読み出してこれを記録するための動作を省略可能とする技術である。さらに、記憶媒体から読み出したデータを仮登録データとして上記記憶手段に対して記録するのに応じ、該データとともにその記録時刻も記録しておく。そして、この記録時刻の情報を元に、上記記憶手段の記憶容量の状態に応じて、仮登録データとして記録されているデータのうち最も記録時刻が古いデータから順に消去可能としていく（例えば、特許文献１参照）。
【０００４】
また、後掲の特許文献２には、次の技術が記載されている。ＣＰＵ１０は、記憶装置１４に蓄積されている画像ファイルの画像種類をプリンタ１５によってプリントするプリンタ画像、ＦＡＸ１６によってファクシミリ送受信するファックス画像、プリンタ１５によって複写するコピー画像、及びスキャナ１７によって入力したスキャナ画像を、各画像ごとに画像管理テーブルに登録する。そして、画像種類ごとに消去する優先順位を付与し、画像ファイルの蓄積の際に記憶装置１４の空き容量を検査し、その検査に基づいて画像ファイルを蓄積する領域の容量が足らないと判断したとき、記憶装置１４から優先順位に基づいて画像ファイルを消去して画像データを蓄積可能な容量の領域を作成する。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００４−３９１１４号公報
【特許文献２】特開２００１−８８３７２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
前述のように、静止画や動画を用いた広告が普及しつつある。一方で、静止画や動画は文字に比べてデータ容量が大きい。配信された広告は、それを受信したモバイル機器の記憶領域に格納されるため、前記記憶領域を圧迫することになりかねない。
これに対して、前記記憶領域に格納された広告データ容量をモニタする機能を設け、データ容量が予め定められた値に達した場合は広告データを削除するという方法が考えられる。しかし、内容にかかわらず広告データを削除してしまうと、ユーザーが必要とする有用な情報まで削除することになりかねない。
【０００７】
あるいは、受信した広告のうちユーザーにとって必要なものにユーザーがチェックをしておき、チェックがついていないものを削除する方法も考えられる。しかし、ユーザーが都度チェックを入れるのは操作が煩雑であり、チェックを付けられた広告が蓄積していくといずれ容量が足りなくなってしまう。
【０００８】
この発明は、以上のような事情を考慮してなされたものであって、ユーザーの明示の指示なく蓄積されるデータによってデータを格納するメモリの空き容量が逼迫したとき、ユーザーの手を煩わすことなく不要なデータを削除しかつユーザーにとって有用なデータを残す携帯通信装置およびその制御プログラムを提供するものである。
【課題を解決するための手段】
【０００９】
この発明は、外部の広告配信用サーバーから広告データを取得し、かつその広告データを前記サーバーから再度取得し得るようにその広告データのインデックスを取得する通信部と、データの格納領域を提供するデータ格納部と、前記通信部が取得した前記広告データおよび前記インデックスを互いに対応付けて前記データ格納部に格納し、かつ前記広告データおよび前記インデックスを削除し得るデータ管理部と、ユーザーによる操作を受付ける操作部と、データを表示する表示部と、前記操作部が受付けた所定の操作に応答して前記表示部に広告データを表示させ、表示させた時刻を閲覧履歴として記録する閲覧制御部とを備え、前記データ管理部は、前記データ格納部の空き容量が閾値を下回ったとき、予め定められた第１期間より前に取得されたが取得後に閲覧履歴の記録がない広告データおよびその広告データに対応付けられたインデックスを削除し、かつ前記第１期間と等しいかそれより短い第２期間の間に閲覧履歴の記録がない広告データについてその広告データを削除するがその広告データに対応付けられたインデックスを残すことを特徴とする携帯通信装置を提供する。
【００１０】
また異なる観点から、この発明は、コンピュータに、外部の広告配信用サーバーから広告データを取得し、かつその広告データを前記サーバーから再度取得し得るようにその広告データのインデックスを取得する通信部と、データの格納領域を提供するデータ格納部に、前記通信部が取得した前記広告データと前記インデックスとを対応付けて格納し、かつ前記広告データおよび前記インデックスを削除し得るデータ管理部と、ユーザーの操作を受付ける操作部が受付けた所定の操作に応答して表示部に広告データを表示させ、表示させた時刻を閲覧履歴として記録する閲覧制御部としての処理を実行させ、前記データ管理部は、前記データ格納部の空き容量が閾値を下回ったとき、予め定められた第１期間より前に取得されたが取得後に閲覧履歴の記録がない広告データおよびその広告データに対応付けられたインデックスを削除し、かつ前記第１期間と等しいかそれより短い第２期間の間に閲覧履歴の記録がない広告データについてその広告データを削除するがその広告データに対応付けられたインデックスを残すことを特徴とする携帯通信装置用の制御プログラムを提供する。
【発明の効果】
【００１１】
この発明の携帯通信装置において、前記データ管理部は、前記データ格納部の空き容量が閾値を下回ったとき、予め定められた第１期間より前に取得されたが取得後に閲覧履歴の記録がない広告データおよびその広告データに対応付けられたインデックスを削除し、かつ前記第１期間と等しいかそれより短い第２期間の間に閲覧履歴の記録がない広告データについてその広告データを削除するがその広告データに対応付けられたインデックスを残すので、最近閲覧されていない広告データは不要なものとしてユーザーの手を煩わすことなく削除し、その一方で、最近閲覧された広告データは再度取得可能なようにインデックスは残しつつ広告データ自体を削除して空き容量を確保することができる。よって、過去に取得した広告データが、利用されることなく無意味に蓄積されていくのを防止することができる。
【００１２】
この発明において、閲覧用広告データは、好ましくは静止画あるいは動画の画像データを含む。また、好ましくは、閲覧用広告データは、インターネット上のウェブサイトで提供される広告であり、携帯通信装置はインターネットに接続してそのウェブサイトを閲覧する機能を有するものである。携帯通信装置の具体的な態様としては、所謂スマートフォンと呼ばれる高機能な携帯電話が代表的な態様である。ただし、この発明はこれに限定されず、電話機能を持たない携帯情報端末や、一般的な携帯電話などを含む。
【００１３】
通信部は、外部のサーバーと通信する。通信の方式は特に限定しないが、例えば携帯電話の通信規格であるＣＤＭＡ−２０００やＷ−ＣＤＭＡ、モバイル端末用のＷｉＭＡＸ、無線ＬＡＮの通信規格であるＩＥＥＥ８０２．１１規格準拠の方式が挙げられる。以上の無線通信に限らず、イーサネット（登録商標）やＵＳＢの有線通信や両者の併用に対応したものであってもよい。前記通信部は、後述する実施形態における端末通信部に対応する。
また、インデックスは、対応する広告データを広告配信用サーバーから取得するために必要な情報であって、広告配信用サーバーのアクセス先や、そのサーバーに格納された広告データのうちで、対象の広告データを特定する情報である。広告データを特定する情報の具体的な態様は、例えば、広告主の企業名あるいは企業ＩＤ、同じ広告主が提供する広告データのいずれのものかを特定するカタログ名あるいはカタログＩＤ、そのカタログの配信日時である。
【００１４】
データ格納部は、データを格納するメモリである。その具体的な態様としては、例えば、スタティックＲＡＭ、ＤＲＡＭあるいはフラッシュメモリが挙げられる。前記データ格納部は、後述する実施形態における格納部に対応する。
また、データ管理部および閲覧制御部は、ＣＰＵあるいはマイクロコンピュータ（以下、簡単のため単にＣＰＵと記す）がメモリに記憶された制御プログラムを実行することによってその機能が実現されるものであってもよい。なお、データ管理部と閲覧制御部とは同じＣＰＵによってその機能が実現されてもよいが、異なるＣＰＵで実現されてもよい。前記データ管理部および前記閲覧制御部は、後述する実施形態における端末制御部によって実現される機能の一部に相当する。
【００１５】
表示部は、前記通信部が受信した情報、装置の状態、操作に係る情報やオブジェクトをユーザーに提示するものである。その具体的な態様は、例えば、液晶表示装置や有機ＥＬ表示装置である。操作部は、ユーザーによる操作を受付けるもので、その具体例としては、前記表示部の表面に配置されるタッチパネルが挙げられる。この場合、操作部の一要素として前記表示装置に操作ボタン等のオブジェクトを表示してもよい。
【図面の簡単な説明】
【００１６】
【図１】この発明の携帯通信装置としての端末およびその携帯通信装置と通信する広告配信用サーバーの構成を示すブロック図である。
【図２】図１の配信スケジュールデータベースに登録されるデータの一例を示す説明図である。
【図３】図１のカタログデータベースに登録されるデータの一例を示す説明図である。
【図４】図１の格納部に格納されるデータの一例を示す説明図である。
【図５】この発明に係る端末制御部が実行する処理の例を示す第１のフローチャートである。
【図６】この発明に係る端末制御部が実行する処理の例を示す第２のフローチャートである。
【図７】この発明の携帯通信装置と通信するサーバーの広告配信処理の一例を示すフローチャートである。
【発明を実施するための形態】
【００１７】
以下、この発明の好ましい態様について説明する。
前記データ管理部は、前記データ格納部にインデックスが格納されている広告データについては前記操作部が再表示の操作を受付けることを許容し、その再表示の操作に応答して前記データ格納部に広告データが格納されているか否かを判断し、格納されていないときは前記インデックスを用いて前記サーバーの広告データを前記通信部に再度取得させてもよい。このようにすれば、最近閲覧された広告データについては、再表示の操作によって広告データの閲覧が可能となり、その際にデータ管理部は、データ格納部に格納されたインデックスを用いて前記サーバーにアクセスし広告データを取得することができる。
【００１８】
また、前記データ管理部は、前記閲覧制御部により前記広告データの閲覧のため表示がなされその閲覧が終了した後、前記広告データを前記データ格納部から削除してもよい。このようにすれば、広告データの閲覧がなされた後にその広告データが削除されインデックスのみ残されるので、広告データを残す場合に比べてデータ格納部の空き容量を確保しておくことができる。
【００１９】
前記データ管理部は、空き容量が前記閾値を下回ったとき、前記閲覧履歴の記録がある広告データについて、前記サーバーの広告データが取得された後に更新されているか否かを前記通信部に前記サーバーとの通信を行わせて問合せ、更新されている場合、その広告データと対応するインデックスとを前記サーバーから取得し、前記データ格納部に格納してもよい。このようにすれば、ユーザーの手を煩わすことなく広告データが更新され、再表示の操作を受付けたときに最新の内容をユーザーに提供することができる。
この発明の好ましい態様は、ここで示した複数の態様のうち何れかを組み合わせたものも含む。
【００２０】
以下、図面を用いてこの発明をさらに詳述する。なお、以下の説明は、すべての点で例示であって、この発明を限定するものと解されるべきではない。
この発明は、広告配信用のサーバーとそのサーバーから広告が配信される一以上の携帯通信装置（以下、端末ともいう）で構成される。
前記サーバーは、配信すべき広告の電子データを格納しており、前記端末に対して電子データを送信する。前記端末は、前記サーバーからの電子データを受信し、その電子データをデータ格納部の記憶領域に一旦格納し、電子データが表す広告をユーザーに提示する。前記サーバーの具体的な態様は、インターネットを介して外部とやり取り可能なファイルサーバである。前記端末の具体的態様の一例はインターネットにアクセス可能なスマートフォンである。
【００２１】
≪携帯通信装置および広告配信用サーバーの構成≫
図１は、この発明の携帯通信装置としての端末およびその携帯通信装置と通信する広告配信用サーバーの構成を示すブロック図である。図１に示すように、端末１１は、端末制御部１３、端末通信部１５、表示部１７、操作部１９および格納部２１を有する。また、サーバー３１は、サーバー通信部３３、サーバー制御部３５、配信スケジュールデータベース３７およびカタログデータベース３９を有する。
サーバー制御部３５は、サーバー３１の中核をなす中央処理装置（ＣＰＵ）およびそのＣＰＵが動作するための周辺回路、例えば、バス、メモリ、割り込み等の制御に係るハードウェアおよびソフトウェアに対応する。サーバー通信部３３は、端末１１や他の図示しない外部の機器と通信を行うためのインターフェイス回路および通信制御ソフトウェアに対応する。
【００２２】
配信スケジュールデータベース３７は、広告主である企業等から配信を依頼されたカタログデータの配信に係るデータを格納するデータベースである。カタログデータは、この発明の広告データに相当する。ここで、配信に係るデータとは、各カタログデータをいつ、どの配信グループへ配信を行うかといった配信スケジュールに係るデータである。この配信スケジュールに従って、サーバー制御部３５が各端末へカタログデータの配信を行うように制御する。
【００２３】
図２は、図１の配信スケジュールデータベース３７に登録されるデータの一例を示す説明図である。図２に示すように、登録されるデータは、配信日時、カタログID、カタログ名、企業名、企業ID、配信先で構成されている。カタログIDは、後述のカタログデータベース３９のカタログIDと一致しており、カタログIDを参照することによって両者の対応が得られる。カタログIDは、各カタログを他のカタログと識別するために各カタログに割り当てられる固有のデータである。カタログ名は人間がカタログの内容を認識しやすいように付与された名称である。企業IDは、各広告主を他の広告主と識別するため各広告主に割り当てられる固有のデータである
【００２４】
サーバー制御部３５は、配信スケジュールデータベース３７を参照して、配信日時が到来したカタログのカタログIDを参照する。また、そのカタログの配信先を取得する。そして、カタログデータベース３９を参照し、同一のカタログIDを有するカタログのデータを読み出して端末１１や他の図示しない端末のうち前記配信先に登録された端末にそのデータを配信する。
カタログデータベース３９は、広告データの実体であるカタログデータを格納するデータベースである。
【００２５】
図３は、図１のカタログデータベース３９に登録されるデータの一例を示す説明図である。図３に示すように、登録されるデータは、カタログＩＤ、カタログ名およびカタログデータ自体である。カタログデータベース３９に格納されたカタログデータは、カタログIDおよびカタログ名を用いて管理される。
サーバー通信部３３は、サーバー３１からのカタログ配信データを配信先の端末に配信する機能を有している。
【００２６】
サーバー制御部３５は、サーバー３１が実行すべきデータの処理や管理を行う。サーバー制御部３５が実行する処理は、配信スケジュールデータベース３７に登録されたカタログのうち配信日時が到来したものを決定する処理を含む。さらに、決定されたカタログに係るカタログIDを用いて、カタログデータベース３９に格納されたカタログデータを呼び出す処理および呼び出したカタログデータを登録された配信先へ配信する処理を含む。
端末１１は、この発明の携帯通信端末装置であって、広告データの配信先である端末の代表例として図１に示している。端末１１および図示しない他の端末は、固有の端末IDを有している。配信スケジュールデータベース３７には、この端末IDをグループ化した配信先が登録されている。サーバー制御部３５は、配信スケジュールデータベース３７に登録された配信先に基づいて、それぞれの広告データの配信先を特定する。
【００２７】
端末制御部１３は、端末通信部１５、表示部１７、操作部１９および格納部２１の動作を制御するもので、その構成要素としてＣＰＵ、その周辺回路およびＣＰＵが実行する制御ソフトウェアを含む。端末制御部１３は、端末１１とサーバー３１との間における通信の制御、サーバー３１から受信するデータの管理、例えば、格納部２１の空き容量が閾値に満たなくなった場合のデータの削除など各種の制御を行う。
端末通信部１５は、サーバー３１からカタログデータの配信や、再度の取得などに係る通信を行うための通信インターフェイス回路およびその制御ソフトウェアである。この実施形態においては、無線LANの通信方式が用いられるものとしている。
表示部１７は、端末１１の状態やユーザーによる操作に応じた表示やメッセージをユーザーに提供するものである。この実施形態においては、液晶表示装置が用いられるものとする。端末制御部１３は、表示部１７に表示させる内容を制御する。表示の内容には、カタログデータの受信、カタログデータの削除、カタログデータが更新された旨のメッセージが含まれる。
【００２８】
操作部１９は、端末１１に対するユーザーの操作を受付ける。この実施形態では、表示部１７の表面に配置されるタッチパネルである。
格納部２１は、カタログデータおよびそれに付加されるデータを格納する読み書き可能な不揮発性メモリである。この実施例において、格納部２１はさらに閲覧履歴を格納する。また、端末制御部１３が実行する制御プログラムを格納する。
サーバー３１から配信されたカタログデータは、配信先の一つである端末１１の端末通信部１５を経由して、格納部２１に配信の都度格納されていく。
【００２９】
図４は、図１の格納部２１に格納されるデータの一例を示す説明図である。図４に示すように、格納部２１は、「配信日時」、「カタログID」、「カタログ名」、「企業名」、「企業ID」、「カタログデータ」、「閲覧履歴」および「目次のみ」の各項目についてデータを格納する。それらの項目のうち、「配信日時」、「カタログID」、「カタログ名」、「企業名」および「企業ID」は、配信スケジュールデータベース３７に登録されたものと同一であって、カタログデータと共にサーバー３１から提供される。端末制御部１３は、サーバー３１から配信されるそれらのデータをカタログデータと共に格納部２１に格納する。これら、カタログデータ以外の項目は、この発明のインデックスに相当する。
【００３０】
「閲覧履歴」の項目は、配信されたカタログデータをユーザーが閲覧したか否かを示すデータである。初期値は、「無」である。端末制御部１３は、カタログデータが閲覧された場合に、閲覧されたカタログの「閲覧履歴」に対して「有」を示すデータを格納する。また、端末制御部１３は、後述のカタログデータ削除時に、「閲覧履歴」が「有」の場合には、カタログデータの削除を行わず、更新されたカタログデータがあるか否かの問合せをサーバー３１に対して行う。
【００３１】
更新されたカタログデータがサーバー３１にある場合には、そのカタログデータを受信して格納部２１のカタログデータを置き換える。一方、サーバー３１のカタログデータが更新されていない場合は、格納部２１のカタログデータを削除し、さらに、「目次のみ」の項目に目次のみ格納されている旨を示すデータを格納する。図４の「○」印に相当するものである。なお、初期値は、目次が格納されていないかまたはカタログデータが格納されていることを示すデータである。図４の無印に相当するものである。図４で「目次のみ」の「○」印は、カタログデータ自身は格納部２１に格納されていないが、ユーザーが閲覧を希望する場合にはサーバー３１にアクセスしてカタログデータを取得し閲覧することが可能であることを示している。
【００３２】
すなわち、端末制御部１３は、格納部２１の空き容量が閾値に満たなくなった場合に、格納部２１に格納されているデータの一部を削除して、空き容量を確保する。削除するデータは、「閲覧履歴」の有無に基づいて決定する。さらにこのとき、「閲覧履歴」が「有」のカタログデータを単に残すだけでなく、カタログデータを自動更新するかあるいは大きな容量を占めるカタログデータを削除して、必要に応じてサーバー３１から取得できるようにしておくのである。
以上の処理によって端末制御部１３は、配信されたカタログデータが活用されないまま格納部２１に蓄積されることを防止し、格納部２１の空き容量を確保する。
【００３３】
≪端末制御部の処理≫
続いて、端末制御部１３が実行する処理の例を説明する。
図５および図６は、この発明に係る端末制御部が実行する処理の例を示すフローチャートである。この発明に関連する処理のみを記載している。前記処理は、サーバー３１から配信されるカタログデータを受信して格納部２１に格納する処理を含む。さらに、格納部２１の空き容量が少ないときに格納部２１に格納されたデータの一部を削除する処理を含む。また、サーバー３１にアクセスして更新されたカタログデータを取得する処理および操作部が受付けた所定の操作に応答してカタログデータを閲覧する処理を含む。
【００３４】
以下、フローチャートに沿って端末制御部が実行する処理を説明する。図５に示すように、端末制御部１３は、外部からデータを受信した場合に、そのデータが広告データ、即ち、サーバー３１から配信されたカタログデータか否かを判断する（ステップＳ１１）。カタログデータでなければ（ステップＳ１１のＮｏ）、ルーチンは後述するステップＳ５１へ進み、閲覧に関する処理を行う。
【００３５】
受信したデータがカタログデータであれば（ステップＳ１１のＹｅｓ）、端末制御部１３は、そのカタログデータおよびカタログデータに付加されている「配信日時」、「カタログID」、「カタログ名」、「企業名」および「企業ID」のデータを格納部２１に格納する（ステップＳ１３）。また、図示していないが、受信したカタログデータに係るバナーを表示部１７の一部の表示領域に表示させてもよい。あるいは、この時点で即座に表示するのではなく、ユーザーがカタログデータに関連する内容について検索や閲覧を行ったときに、表示部１７の一部にバナーを表示させてもよい。
【００３６】
続いて、端末制御部１３は、格納部の空き容量が閾値を下回ったか否かを調べる（ステップＳ１５）。この閾値は、受信データを格納するメモリ領域の容量に対して予め定められている。なお、変形例として端末１１のユーザーがこの閾値を設定、変更可能であってもよい。
空き容量が閾値を下回っておらずまだ十分な余裕があると判断した場合（ステップＳ１５のＮｏ）、端末制御部１３は、後述するステップＳ５１へ進み、閲覧に関する処理を行う。一方、格納部２１の空き容量が閾値を下回っていると判断した場合（ステップＳ１５のＹｅｓ）、端末制御部１３は、格納部２１に格納されたデータの一部を削除する処理を行う。即ち、端末制御部１３は、カタログの閲覧履歴を参照する（ステップＳ１７）。この実施形態でカタログの閲覧履歴は、格納部２１に格納されているものとしている。ただし、これに限定されるものでなく、格納部２１と別の、図１に図示しない不揮発性メモリに格納されていてもよい。
【００３７】
続いて端末制御部１３は、図４に示す格納部２１に格納されたデータを参照しながら、格納部に格納されたカタログデータのうち「閲覧履歴」が「無」のデータを抽出し（ステップＳ１９）、以下の処理を行う。まず、受信した後に一度も閲覧されていないカタログデータを抽出する。抽出されたカタログデータは、ユーザーにとって興味のないものかあるいは受信してからの期間が短いものと考えられる。そこで、端末制御部１３は、「配信日時」に基づいて、抽出されたカタログデータが現時点から二週間より前に受信されたものか否かを調べる（ステップＳ２１）。勿論、二週間という期間は一例であってこれに限定されるものではない。また、この期間がユーザーによって設定および変更可能であってもよい。
【００３８】
カタログデータが二週間より前に受信されたものの場合（ステップＳ２１のＹｅｓ）、端末制御部１３はそのカタログデータおよびそのカタログデータに係るインデックスを削除する（ステップＳ２３）。ユーザーにとって興味のないものと考えられるからである。受信後二週間が経過していない場合は（ステップＳ２１のＮｏ）削除しない。続いて、端末制御部１３は、抽出された全てのカタログデータについて受信後の経過期間を判断したか調べる（ステップＳ２５）。また、判断していないカタログデータが残っている場合（ステップＳ２５のＮｏ）、ルーチンは残りのカタログデータのうち次のものを対象として（ステップＳ２７）、前述のステップＳ２１に戻り、残りのカタログデータについて受信後の経過期間を判断する。
【００３９】
抽出された全てのカタログデータについて受信後の経過期間を判断したら（ステップＳ２５のＹｅｓ）、端末制御部１３は閲覧履歴があるカタログデータを抽出し（ステップＳ２９）、以下の処理を行う。まず、端末制御部１３は、「配信日時」に基づいて、抽出されたカタログデータが現時点から遡って一週間以内に閲覧されているか否かを調べる（ステップＳ３１）。一週間以内に閲覧されていない場合、そのカタログデータはユーザーにとって繰り返し閲覧する程の興味はないものと考えられる。勿論、一週間という期間は一例であってこれに限定されるものではない。ただし、この期間（以下、第２期間とする）は、前記ステップＳ２１で判断基準とされる期間（以下、第１期間とする）と等しいかそれよりも短い。第１期間より前に取得されたが閲覧履歴の記録がないカタログデータについては、ステップＳ２１の判定およびステップＳ２３の処理で格納部２１から削除されている。よって、このステップＳ３１では前記第１期間の以後に取得されたが閲覧履歴の記録がないものを対象にするのが合理的である。ステップＳ２１およびＳ２３と重複する処理を避けるためである。なお、この第２期間がユーザーによって設定および変更可能であってもよい。
【００４０】
カタログデータが一週間以上閲覧されていない場合（ステップＳ３１のＹｅｓ）、端末制御部１３はそのカタログデータを削除する（ステップＳ３３）。ただし、そのカタログデータに係るインデックスは削除せずに残しておく。ユーザーにとって全く興味のないものとまではいえないため、再度閲覧される可能性があるからである。直近一週間の間に閲覧されている場合は（ステップＳ３１のＮｏ）カタログデータを削除しない。続いて、端末制御部１３は、抽出された全てのカタログデータについて直近の閲覧の有無を判断したか調べる（ステップＳ３５）。また、判断していないカタログデータが残っている場合（ステップＳ３５のＮｏ）、ルーチンは残りのカタログデータのうち次のものを対象として（ステップＳ３７）、前述のステップＳ３１に戻り、残りのカタログデータについて直近の閲覧の有無を判断する。
【００４１】
抽出された全てのカタログデータについて受信後の経過期間を判断した後（ステップＳ３５のＹｅｓ）、端末制御部１３は閲覧履歴のあるカタログデータについてカタログID、企業IDおよび配信日時を配信元のサーバー３１に送信し、カタログデータが更新されているか否かを問い合わせる（ステップＳ３９）。カタログIDだけでなく企業IDを送信するのは、同一カタログIDの更新を調べるだけでなく、同一企業の他のカタログIDの更新有無および新たなカタログIDの有無を調べて更新および／または新たに追加されたカタログデータを取得できるようにするためである。ここで、図５のフローチャートでは、閲覧履歴のある全てのカタログデータについて問合せを行うようにしている。変形例として、前記ステップＳ３１で判断基準とされた期間（一週間）内に閲覧があったカタログデータのみについて問合せを行うようにしてもよい。
【００４２】
問合せの後、端末制御部１３はサーバー３１からの回答を待つ（ステップＳ４１）。説明を簡単にするためステップＳ４１のフローチャートはループしているが、この間に端末制御部としてのＣＰＵは当然ながら他の処理を並行して行ってもよい。サーバー３１からの回答に更新されたカタログデータが付与されていた場合（ステップＳ４３）、端末制御部１３は、受信したカタログデータを格納部２１の該当する記憶領域に格納する（ステップＳ４５）。そして、ルーチンは前述のステップＳ１１へ戻り、新たなカタログデータの受信に備えて待機する。なお、サーバー３１からの回答に更新されたカタログデータが付与されていない場合（ステップＳ４３のＮｏ）も、ルーチンはステップＳ１１へ戻って待機する。
【００４３】
続いて、端末制御部１３が実行する閲覧の処理について図６のフローチャートに沿って説明する。
図５におけるステップＳ１１の判定がＮｏまたは図５のステップＳ１５の判定がＮｏの場合、続いて端末制御部１３は、カタログデータの閲覧の処理を行う。まず、端末制御部１３は、操作部１９が、カタログの閲覧を指示する操作を受付けているか否かを調べる（図６のステップＳ５１）。この操作は、例えば、表示部１７に表示されたバナーにユーザーがタッチするなど、予め定められた操作である。
【００４４】
閲覧の指示に係る操作が受付けてられていないとき、端末制御部１３は閲覧に係る処理を何も行わず、ルーチンは前述のステップＳ１１へ進む。一方、閲覧の指示に係る操作が受付けてられている場合、端末制御部１３は、その操作に対応するカタログデータが格納部２１に格納されているか否かを調べる（ステップＳ５３）。カタログデータが格納されている場合は（ステップＳ５３のＹｅｓ）、そのカタログデータを格納部２１から読み出して表示部１７に表示させる（ステップＳ５５）。表示を終えた後、ルーチンは前述のステップＳ１１へ進む。
【００４５】
一方、カタログデータが格納されていない場合（ステップＳ５３のＮｏ）、端末制御部１３は格納部２１に格納されているそのカタログデータに係るインデックスを用いて、サーバー３１にカタログデータを要求する（ステップＳ５７）。この要求には、取得すべきカタログデータのカタログIDを付加する。なお、格納部２１からカタログデータもインデックスも削除されたものについては、そもそもバナーを表示部１７に表示させないように端末制御部１３が制御している。
【００４６】
端末制御部１３は、カタログデータの要求に対するサーバー３１からの回答を待つ（ステップＳ５９）。サーバー３１からの回答を受信したら（ステップＳ５９のＹｅｓ）、端末制御部１３は、回答にカタログデータが付加されているか否かを調べる（ステップＳ６１）。カタログデータが付加されてない場合（ステップＳ６３）、サーバー３１との通信が確立できなかったり、その広告データの配信サービスが終了していたりする何らかの事情によってカタログデータが取得できなかった旨を表示部１７に表示させる（ステップＳ６３）。そして、ルーチンは前述のステップＳ１１へ進む。
【００４７】
一方、サーバーからの回答にカタログデータが付加されていたら（ステップＳ６１のＹｅｓ）、受信したカタログデータを格納部２１に格納し、かつ、表示部１７に表示させる（ステップＳ６５）。そして、ユーザーがそのカタログデータの閲覧を終了するのを待って（ステップＳ６７）、受信したカタログデータを格納部２１から削除する（ステップＳ６９）。そして、ルーチンは前述のステップＳ１１へ進む。
以上が、端末制御部１３が実行する処理である。
【００４８】
≪サーバー制御部の処理≫
続いて、端末１１と通信するサーバー３１側の広告配信処理について説明する。
図７は、この発明の携帯通信装置と通信するサーバーの広告配信処理の一例を示すフローチャートである。図７の処理は、図１に示すサーバー制御部３５により実行される。図７に沿って処理の手順を説明する。
【００４９】
サーバー３１のカタログデータベース３９には、配信すべきカタログデータが格納され、配信スケジュールデータベース３７には、前記カタログデータについての配信スケジュールが格納されている。サーバー３１は、例えば、広告配信サービスを提供する事業者が管理しており、前記事業者は、広告主との契約に応じてカタログデータベース３９および配信スケジュールデータベース３７にデータを登録し、かつ、登録されたデータを更新したり削除したりする。
【００５０】
サーバー制御部３５は、リアルタイムクロックを含んでおり、図２に示す配信スケジュールデータベースに格納された各データの「配信日時」が到来したか否かを逐次監視する。何れかのカタログデータについて配信日時が到来したとき（ステップＳ１０１のＹｅｓ）、対応するカタログIDに基づいてカタログデータベース３９からカタログデータを読み出して、対応する「配信先」として定義された端末に配信する。その際、カタログデータに「配信日時」、「カタログID」、「カタログ名」、「企業名」および「企業ID」を付加する。そして、ルーチンは次のステップＳ１０５へ進む。
【００５１】
前記ステップＳ１０１で、配信日時の到来したものがなかったときは（ステップＳ１０１のＮｏ）、ルーチンはステップＳ１０５へ進む。
ステップＳ１０５へ進み、端末側からカタログデータの更新有無の問合せを受けた場合の処理を行う。即ち、端末１１および図１に図示しない他の何れかの端末からカタログデータの更新有無の問合を受けたか否かを調べる。なお、前記問合せにはカタログIDと企業IDが付加されている。前記問合せを受信していない場合（ステップＳ１０５のＮｏ）、ルーチンは後述するステップＳ１２１へ進み、カタログデータの要求を受けた場合の処理を行う。
【００５２】
一方、前記問合せを受信した場合は（ステップＳ１０５のＹｅｓ）、その問合せに付加された企業IDおよび配信日時に基づいて、その企業の他のカタログデータについても更新されたものがあるかを調べ、かつ、新たに追加されたカタログデータが有るかを調べる（ステップＳ１０７）。更新あるいは追加されたものがなければ（ステップＳ１０９のＮｏ）、問合せ元の端末へその旨を送信する（ステップＳ１１３）。一方、更新あるいは追加されたものがあれば（ステップＳ１０９のＹｅｓ）、そのカタログデータに「配信日時」、「カタログID」、「カタログ名」、「企業名」および「企業ID」を付加して問合せをした端末へ送信する（ステップＳ１１５）。そして、ルーチンは前述のステップＳ１０１へ戻り配信日時が到来したか否かの監視を続ける。
【００５３】
次に、カタログデータの要求を受けた場合の処理について説明する。前記ステップＳ１０５の判定がＮｏの場合に続けて実行する処理である。サーバー制御部３５は、端末１１および図１に図示しない何れかの端末からカタログデータの要求を受けたか否かを調べる（ステップＳ１２１）。要求がなければ（ステップＳ１２１のＮｏ）、ルーチンは前述のステップＳ１０１へ進む。
【００５４】
要求を受けた場合（ステップＳ１２１のＹｅｓ）、サーバー制御部３５は、その要求に付加されたカタログIDに対応するカタログデータがカタログデータベース３９に格納されているか否かを調べる（ステップＳ１２３）。カタログデータがあれば、要求を送信した端末にそのカタログデータを送信する（ステップＳ１２７）。カタログデータがすでに削除されている等の事情により対応するカタログデータが見つからない場合、サーバー制御部３５は、該当するカタログデータがない旨を前記端末に送信する（ステップＳ１２９）。そして、ルーチンは前述のステップＳ１０１へ進む。
以上が、サーバー側の処理である。
【００５５】
前述した実施の形態の他にも、この発明について種々の変形例があり得る。それらの変形例は、この発明の範囲に属さないと解されるべきものではない。この発明には、請求の範囲と均等の意味および前記範囲内でのすべての変形とが含まれるべきである。
【符号の説明】
【００５６】
１１：端末
１３：端末制御部
１５：端末通信部
１７：表示部
１９：操作部
２１：格納部
３１：サーバー
３３：サーバー通信部
３５：サーバー制御部
３７：配信スケジュールデータベース
３９：カタログデータベース
【特許請求の範囲】
【請求項１】
外部の広告配信用サーバーから広告データを取得し、かつその広告データを前記サーバーから再度取得し得るようにその広告データのインデックスを取得する通信部と、
データの格納領域を提供するデータ格納部と、
前記通信部が取得した前記広告データおよび前記インデックスを互いに対応付けて前記データ格納部に格納し、かつ前記広告データおよび前記インデックスを削除し得るデータ管理部と、
ユーザーによる操作を受付ける操作部と、
広告を表示する表示部と、
前記操作部が受付けた所定の操作に応答して前記表示部に広告データを表示させ、表示させた時刻を閲覧履歴として記録する閲覧制御部とを備え、
前記データ管理部は、前記データ格納部の空き容量が閾値を下回ったとき、予め定められた第１期間より前に取得されたが取得後に閲覧履歴の記録がない広告データおよびその広告データに対応付けられたインデックスを削除し、かつ前記第１期間と等しいかそれより短い第２期間の間に閲覧履歴の記録がない広告データについてその広告データを削除するがその広告データに対応付けられたインデックスを残すことを特徴とする携帯通信装置。
【請求項２】
前記データ管理部は、前記データ格納部にインデックスが格納されている広告データについては前記操作部が再表示の操作を受付けることを許容し、その再表示の操作に応答して前記データ格納部に広告データが格納されているか否かを判断し、格納されていないときは前記インデックスを用いて前記サーバーの広告データを前記通信部に再度取得させる請求項１に記載の携帯通信装置。
【請求項３】
前記データ管理部は、前記閲覧制御部により前記広告データの閲覧のため表示がなされその閲覧が終了した後、前記広告データを前記データ格納部から削除する請求項２に記載の携帯通信装置。
【請求項４】
前記データ管理部は、空き容量が前記閾値を下回ったとき、前記閲覧履歴の記録がある広告データについて、前記サーバーの広告データが取得された後に更新されているか否かを前記通信部に前記サーバーとの通信を行わせて問合せ、更新されている場合、その広告データと対応するインデックスとを前記サーバーから取得し、前記データ格納部に格納する請求項１〜３の何れか一つに記載の携帯通信装置。
【請求項５】
コンピュータに、
外部の広告配信用サーバーから広告データを取得し、かつその広告データを前記サーバーから再度取得し得るようにその広告データのインデックスを取得する通信部と、
データの格納領域を提供するデータ格納部に、前記通信部が取得した前記広告データおよび前記インデックスを互いに対応付けて前記データ格納部に格納し、かつ前記広告データおよび前記インデックスを削除し得るデータ管理部と、
ユーザーの操作を受付ける操作部が受付けた所定の操作に応答して表示部に広告データを表示させ、表示させた時刻を閲覧履歴として記録する閲覧制御部としての処理を実行させ、
前記データ管理部は、前記データ格納部の空き容量が閾値を下回ったとき、予め定められた第１期間より前に取得されたが取得後に閲覧履歴の記録がない広告データおよびその広告データに対応付けられたインデックスを削除し、かつ前記第１期間と等しいかそれより短い第２期間の間に閲覧履歴の記録がない広告データについてその広告データを削除するがその広告データに対応付けられたインデックスを残すことを特徴とする携帯通信装置用の制御プログラム。
【請求項１】
外部の広告配信用サーバーから広告データを取得し、かつその広告データを前記サーバーから再度取得し得るようにその広告データのインデックスを取得する通信部と、
データの格納領域を提供するデータ格納部と、
前記通信部が取得した前記広告データおよび前記インデックスを互いに対応付けて前記データ格納部に格納し、かつ前記広告データおよび前記インデックスを削除し得るデータ管理部と、
ユーザーによる操作を受付ける操作部と、
広告を表示する表示部と、
前記操作部が受付けた所定の操作に応答して前記表示部に広告データを表示させ、表示させた時刻を閲覧履歴として記録する閲覧制御部とを備え、
前記データ管理部は、前記データ格納部の空き容量が閾値を下回ったとき、予め定められた第１期間より前に取得されたが取得後に閲覧履歴の記録がない広告データおよびその広告データに対応付けられたインデックスを削除し、かつ前記第１期間と等しいかそれより短い第２期間の間に閲覧履歴の記録がない広告データについてその広告データを削除するがその広告データに対応付けられたインデックスを残すことを特徴とする携帯通信装置。
【請求項２】
前記データ管理部は、前記データ格納部にインデックスが格納されている広告データについては前記操作部が再表示の操作を受付けることを許容し、その再表示の操作に応答して前記データ格納部に広告データが格納されているか否かを判断し、格納されていないときは前記インデックスを用いて前記サーバーの広告データを前記通信部に再度取得させる請求項１に記載の携帯通信装置。
【請求項３】
前記データ管理部は、前記閲覧制御部により前記広告データの閲覧のため表示がなされその閲覧が終了した後、前記広告データを前記データ格納部から削除する請求項２に記載の携帯通信装置。
【請求項４】
前記データ管理部は、空き容量が前記閾値を下回ったとき、前記閲覧履歴の記録がある広告データについて、前記サーバーの広告データが取得された後に更新されているか否かを前記通信部に前記サーバーとの通信を行わせて問合せ、更新されている場合、その広告データと対応するインデックスとを前記サーバーから取得し、前記データ格納部に格納する請求項１〜３の何れか一つに記載の携帯通信装置。
【請求項５】
コンピュータに、
外部の広告配信用サーバーから広告データを取得し、かつその広告データを前記サーバーから再度取得し得るようにその広告データのインデックスを取得する通信部と、
データの格納領域を提供するデータ格納部に、前記通信部が取得した前記広告データおよび前記インデックスを互いに対応付けて前記データ格納部に格納し、かつ前記広告データおよび前記インデックスを削除し得るデータ管理部と、
ユーザーの操作を受付ける操作部が受付けた所定の操作に応答して表示部に広告データを表示させ、表示させた時刻を閲覧履歴として記録する閲覧制御部としての処理を実行させ、
前記データ管理部は、前記データ格納部の空き容量が閾値を下回ったとき、予め定められた第１期間より前に取得されたが取得後に閲覧履歴の記録がない広告データおよびその広告データに対応付けられたインデックスを削除し、かつ前記第１期間と等しいかそれより短い第２期間の間に閲覧履歴の記録がない広告データについてその広告データを削除するがその広告データに対応付けられたインデックスを残すことを特徴とする携帯通信装置用の制御プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【公開番号】特開２０１３−１０５１９９（Ｐ２０１３−１０５１９９Ａ）
【公開日】平成２５年５月３０日（２０１３．５．３０）
【国際特許分類】
【出願番号】特願２０１１−２４６６２７（Ｐ２０１１−２４６６２７）
【出願日】平成２３年１１月１０日（２０１１．１１．１０）
【出願人】（０００００５０４９）シャープ株式会社 (33,933)
【Ｆターム（参考）】
【公開日】平成２５年５月３０日（２０１３．５．３０）
【国際特許分類】
【出願日】平成２３年１１月１０日（２０１１．１１．１０）
【出願人】（０００００５０４９）シャープ株式会社 (33,933)
【Ｆターム（参考）】
[ Back to top ]