JP5062666B2

JP5062666B2 - 携帯通信端末

Info

Publication number: JP5062666B2
Application number: JP2007108279A
Authority: JP
Inventors: 修花田
Original assignee: Kyocera Corp
Current assignee: Kyocera Corp
Priority date: 2007-04-17
Filing date: 2007-04-17
Publication date: 2012-10-31
Anticipated expiration: 2027-04-17
Also published as: JP2008270963A

Description

本発明は、大容量のコンテンツデータ配信を受信する携帯通信端末に関する。

近年、携帯電話機等の携帯通信端末は多機能化が進んでおり、音声通話に加えて高速なデータ通信が可能になってきている。高速なデータ通信を行うために、例えば下り方向（基地局から携帯通信端末への方向）のデータ伝送速度を高めたｃｄｍａ２０００１ｘＥＶ−ＤＯ（Evolution Data Only(or Optimized）)と称される通信方式（以降、ＥＶ−ＤＯと称する）により、高速データ通信を行うことが可能である。
特許文献１には、ｃｄｍａ２０００１ｘとＥＶ−ＤＯとの両方の通信方式に対応した通信機器が開示されている。
特開２００６−３３９９１６号公報

ＥＶ−ＤＯにおいては、通信エリア内の全ユーザに向けて効率の良いデータ転送方式を提供するマルチキャスト通信方式であるＢＣＭＣＳ（Broadcast/Multicast Services）が利用可能である。
ＢＣＭＣＳとは、従来の無線通信システムのように無線帯域を時間或いは符合で細かく分け、それぞれを基地局と携帯通信端末間の１対１で使用してユニキャスト通信を行うのではなく、テレビやラジオと同様に、１個のデータサーバ等から複数の携帯通信端末に向けて送信を行い、複数の携帯通信端末が同時に送信されたデータを受信する通信方式である。
通常、ＥＶ−ＤＯは、データ通信に特化した高速通信方式であり、携帯通信端末ごとに異なるタイムスロットを割り当て、各端末は割り当てられたタイムスロットを受信する方式である。
これに対して、ＢＣＭＣＳでは、時分割されたスロットのうち、端末個別に割り当てられるのではなく、ＢＣＭＣＳ用の解放スロットを基地局から送信することとなり、受信側の全端末が一様にこのＢＣＭＣＳ用スロットを受信することとなる。つまり、基地局の負荷としては、同じデータを送出しているに過ぎず、トラフィックに与える影響が非常に小さい。このため、大容量のデータ配信にも適している。

ＢＣＭＣＳには、複数の携帯通信端末に同じデータを送信する際に、送信に使用するタイムスロットやチャネルが共通で済むため、どれだけ多くの携帯通信端末が一度に同じデータを受信しても、回線が込み合うことが無く、ユニキャスト方式と比較して飛躍的に通信効率がよくなっている、という利点がある。ただし、１台の携帯通信端末が受信に失敗した場合でも、その都度受信に失敗したデータを再送していたのでは、他の携帯通信端末への送信が途切れてしまうため、データの再送を行うことができない。このため、予め最も電波状況が悪い携帯通信端末に合わせてノイズに強い変調を使用し、強力なエラー訂正符号を利用することにより再送を不要としている。

上述したようにＢＣＭＣＳを利用すれば、複数の携帯通信端末に向けて同時に大容量のデータ（動画等）を配信することができるようになる。
ＢＣＭＣＳを利用して配信されるデータは、携帯通信端末の記憶部中の専用の領域に格納される。サイズが大きいデータを取得し、再送が生じないよう確実に取得データを格納するために、ＢＣＭＣＳ用の記憶領域が、予め携帯通信端末の記憶部内に予約領域として確保されている必要がある。また、受信したデータの使用後には、必要に応じて予約領域を開放する必要がある。

すなわち、記憶部内に予約領域を確保する機能がない携帯通信端末、予約領域の動的な確保及び開放を行うことができない携帯通信端末、予約可能な領域の数や容量が十分でない携帯通信端末では、ＢＣＭＣＳによる通信に適していない。

専用のデータ領域を記憶領域内に確保するためには、例えばＦＡＴ（File Allocation Table）等のファイルシステムを使用する方法がある。ＦＡＴファイルシステムは、ディスク総容量に対し管理領域が少なくて済むという特徴を有し、また実装が容易であるため、よく利用されているファイルシステムである。
ＦＡＴはパーティション（記憶領域を論理的に分割して使用する）と呼ばれる機能を有しており、パーティション分割を行うことにより上述した予約領域の確保等を実現することは可能であるが、パーティション分割を行うと、分割以前から格納されていたデータを破損してしまう恐れがあるため、ＢＣＭＣＳでは、予約領域は携帯通信端末の記憶部の一部として存在する必要がある。このため、ＦＡＴファイルシステムをＢＣＭＣＳに対応した携帯通信端末の記憶部のファイルシステムとして利用するには適していない。

本発明は上記した不利益を解消するためになされたものであり、大容量のデータ通信を行う際に、記憶領域内に予約領域の確保及び開放を行うことができる携帯通信端末を提供することを目的とする。

上述した目的を達成するために、第１の発明の携帯通信端末は、各種データを格納する記憶部と、公衆通信網を介してＢＣＭＣＳ通信により、コンテンツサーバからデータを取得する通信部と、前記通信部により取得したコンテンツのデータを前記記憶部に格納するよう制御する制御部と、を備え、前記制御部は、該当するコンテンツの種類ごとに、ユーザが前記コンテンツサーバに対してユーザ登録すると、前記記憶部に、登録された前記コンテンツの種類に対応するディレクトリを作成するとともに、前記コンテンツサーバに対してユーザが前記コンテンツの種類ごとに登録を解除すると、当該種類に対応した前記ディレクトリを開放する。

好適には、前記制御部は、前記公衆通信網から配信される所定のデータの格納に要する容量を、予め前記公衆通信網から取得して、当該所定のデータの格納に要する容量を前記記憶部の空き領域と比較し、空き領域の方が大きければ、前記所定のデータを格納するためのデータ領域を前記記憶部に確保するとともに、前記データ領域の容量に前記所定のデータを特定する情報を対応付けて、前記記憶部に記憶されるテーブルに登録する予約処理と、前記通信部によりデータの取得が生じ、取得するデータが前記情報に基づいて前記所定のデータであると判定される場合には、当該データを前記データ領域に格納するとともに前記テーブルに登録される前記データ領域の容量を前記所定のデータの格納に対応した値に更新し、取得するデータが前記情報に基づいて前記所定のデータではないと判定される場合には、当該データが、前記記憶部の空き容量から前記テーブルに登録した前記データ領域の容量を差し引いた容量に対して格納可能であるか否かの判定を行う格納処理と、を実行可能である。
好適には、前記テーブルは、前記データ領域の容量に対し所定のフラグ値を対応付けて登録され、前記制御部は、前記予約処理において、前記データ領域を確保した際には前記テーブルにおけるフラグ値を、前記データ領域の確保がなされたことを示す値とする。

好適には、前記制御部は、ユーザの登録に応じて作成される前記ディレクトリの名称を前記所定のデータを特定する情報に関連した名称とする。

好適には、前記制御部は、前記公衆通信網から前記所定のデータを取得するための所定のアプリケーションプログラムを含む複数種類のアプリケーションプログラムを実行可能であって、前記記憶部に前記ディレクトリを生成する際に、当該ディレクトリの名称を前記所定のアプリケーションプログラムに対応した名称とする。

好適には、前記制御部は、前記ディレクトリを生成する際に、当該ディレクトリの名称を、前記所定のデータに含まれる前記コンテンツの種類に関する名称とする。

好適には、前記制御部は、前記ディレクトリの開放時に、当該ディレクトリ内のデータを削除する。

本発明によれば、大容量のデータ通信を行う際に、記憶領域内に予約領域の確保及び開放を行うことができる携帯通信端末を提供することができる。

以下、本発明の携帯通信端末の実施形態として、携帯端末１００について説明する。
本実施形態の携帯端末１００は、例えば携帯電話機である。
携帯端末１００の構成の一例を図１に示す。
図１に示すように、携帯端末１００は、通信部１、記憶部２、制御部３、マイク４、スピーカ５、操作部６、表示部７を有する。

通信部１は、図１に図示しない通信ネットワークを介してサーバ装置と各種データの送受信を行う。各種データとは、例えば、音声通話やメール等のデータ、動画データや音楽データ等である。
また、通信部１は、後述する制御部３の制御により、ＢＣＭＣＳにより所定のコンテンツサーバ等から配送される大容量のデータを受信し、後述する記憶部２に記憶する。

記憶部２は、携帯端末１００の各動作に使用される各種データを記憶する。各種データとは、例えば、通信部１が通信ネットワークを介してサーバ装置から受信したメールや、音声データ、画像データ、動画データ、また携帯端末１００上で動作するアプリケーション等のプログラムやその動作に必要なデータの類である。
また、記憶部２は、後述する制御部３の制御により、ＢＣＭＣＳにより通信部１が受信したデータを格納するための領域を確保し、当該データが不必要になった時点で当該領域の開放を行う。

記憶部２に記憶されるデータはファイル単位で管理されており、各ファイルは、名前を付けられたディレクトリ（ファイルのグループ）によって整理される。このように、記憶部２は、一般的なファイルシステム（例えばＦＡＴ）により構築されている。

制御部３は、携帯端末１００の動作を統括的に制御する。
マイク４及びスピーカ５は、携帯端末１００における音声入力デバイス及び音声出力デバイスである。
操作部６は、携帯端末１００における入力デバイスであり、例えばテンキーや方向キー等からなる。
表示部７は、携帯端末１００における表示デバイスであり、例えばＬＣＤ（Liquid Crystal Display）や有機ＥＬディスプレイからなる。

また、制御部３は、種々のアプリケーションプログラムを動作させ、種々の機能を実行する。
アプリケーションプログラムは、携帯端末１００上で実行される様々な機能を提供するためのソフトウェアであり、制御部３がアプリケーションプログラムを実行させることにより、当該アプリケーションプログラムに対応したアプリケーションが動作し、例えば通信部１及び記憶部２、マイク４、スピーカ５、操作部６、表示部７等を制御して、例えば、音声通話、メール送受信、ウェブページ閲覧、音楽再生等の様々な機能を実現する
これらのアプリケーションプログラムは、記憶部２に記憶されている。

制御部３は、アプリケーションプログラムの実行時にそのアプリケーションプログラムに対応したアプリケーションが動作時に使用する記憶部２のデータ領域を管理するファイル管理部３１をさらに有する。
ファイル管理部３１は、アプリケーションの動作時には、記憶部２内に当該アプリケーションの動作に必要なデータファイルを格納するためのデータ領域の管理を行う。
特に、ファイル管理部３１は、ＢＣＭＣＳにより大容量のデータを取得するＢＣＭＣＳアプリケーション（本発明の所定のアプリケーション）の動作時には、記憶部２内に取得したデータファイルを格納するためのデータ領域を確保する。そして、確保したら、確保したことを予約領域テーブルに記憶する。

ここで、ＢＣＭＣＳアプリケーションの動作について説明する。
制御部３は、ＢＣＭＣＳアプリケーションの動作を制御する構成として、ＢＣＭＣＳ制御部３２を有する。
ＢＣＭＣＳ制御部３２は、通信部１を介して通信中の基地局を介してＢＣＭＣＳのコンテンツサーバにユーザ登録を行い、ユーザ登録がコンテンツサーバに認証されたら、利用可能なＢＣＭＣＳのコンテンツデータをコンテンツサーバから取得し、当該取得した番組データの内容に応じてＢＣＭＣＳの通信プロトコルを制御する。
コンテンツサーバには種々のコンテンツが記憶されており、ＢＣＭＣＳ制御部３２は、ユーザの要求に応じて、取得したいコンテンツにはユーザ登録を行うことによって、当該コンテンツのコンテンツデータを取得できる仕組みになっている。
具体的には、例えば、コンテンツサーバに天気に関するコンテンツデータとニュースに関するコンテンツデータが存在した場合に、天気に関するコンテンツデータをユーザが取得した場合には、ＢＣＭＣＳ制御部３２はコンテンツサーバの天気に関するコンテンツに対するユーザ登録を行うことにより、天気に関するコンテンツデータを取得することができるようになる。ただし、天気に関するコンテンツに対するユーザ登録を行っても、ニュースに関するコンテンツにもユーザ登録を行わなければ、ニュースに関するコンテンツデータを取得することはできない。

コンテンツデータには、例えばＢＣＭＣＳデータの送信開始時刻や終了時刻、データのフォーマット形式、識別番号などの情報が含まれる。なお、コンテンツサーバは、複数の種類のコンテンツデータを配信しており、それぞれのコンテンツデータごとに内容が異なっている。また、ＢＣＭＣＳ制御部３２は、コンテンツデータの取得が終了したら、コンテンツサーバへのユーザ登録を解除する。
ＢＣＭＣＳにおける受信時の動作は、以下の通りである。
制御部３は、待ち受け中（通信部１による通話やデータ通信を行っていない状態）においては、通信部１にページングチャネルやコントロールチャネルにてＢＣＭＣＳ配信されるデータが生じたことを示すビットが検出される、或いはユーザ登録時にＢＣＭＣＳコンテンツサーバから指定された時刻が到来したことを検出すると、ＢＣＭＣＳデータの受信の処理に遷移する。すなわち、通信部１にて受信するチャネル・タイムスロットをＢＣＭＣＳデータの配信されているチャネル・タイムスロットに変更し、受信を行う。そして、受信したデータをデコードしつつ記憶部２に記憶する。エンドコードの検出等によりＢＣＭＣＳデータの受信完了を検出すると、制御部３は、通信部１を通常待ち受けのページングチャネルやコントロールチャネルの監視状態に戻し、待ち受け状態に戻ることとなる。

ＢＣＭＣＳ制御部３２は、上述したようにＢＣＭＣＳコンテンツサーバから取得したＢＣＭＣＳのコンテンツデータに含まれる画像データや音声データを復号化し、復号化した画像データを図１に図示しないディスプレイ装置において画像として表示する処理や、復号化した音声データを図１に図示しないスピーカにおいて音声として出力する処理を行う。
また、ＢＣＭＣＳ制御部３２は、コンテンツデータを収得する際のコンテンツサーバへのユーザ登録と同時にＢＣＭＣＳのコンテンツデータの容量に応じてファイル管理部３１に対して記憶部２内にデータ領域を確保させる要求を行い、確保させたデータ領域に取得したコンテンツデータを書き込ませる。さらに、ＢＣＭＣＳ制御部３２は、コンテンツデータを取得し終わり、コンテンツサーバからユーザ登録を解除する際には、ファイル管理部３１に確保させたデータ領域を解放させる。

ファイル管理部３１が記憶部２にデータ領域を確保するとは、ＢＣＭＣＳアプリケーション以外のアプリケーションからのデータ書き込みを禁止するデータ領域を制御部３が記憶部２内に用意することを意味している。
以下、ファイル管理部３１がＢＣＭＣＳアプリケーション動作時に記憶部２に確保する予約領域に関する情報を記憶する予約領域テーブルについて説明する。
予約領域テーブルの一例を図２に示す。

図２に示すように、予約領域テーブルは、ディレクトリ名に関連付けて、そのディレクトリの予約フラグ、予約容量、空き容量、確保日時、解放日時を記憶するテーブルである。
ディレクトリ名とは、ＢＣＭＣＳアプリケーションの動作時にファイル管理部３１が記憶部２に確保するデータ領域のディレクトリの名称である。
ディレクトリは、例えばＢＣＭＣＳ制御部３２が取得するコンテンツごとにファイル管理部３１によって確保される。すなわち、ファイル管理部３１は、ＢＣＭＣＳ制御部３２の要求に応じて一度ディレクトリを確保したなら、そのディレクトリには同一の内容のコンテンツデータしか書き込まないようになっている。
ファイル管理部３１は、ＢＣＭＣＳ制御部３２が取得するコンテンツデータごとに別々の名称のディレクトリを確保し、確保したディレクトリにそのコンテンツに関するデータを書き込む。

ディレクトリの名称はどのような名称であっても良いが、本実施形態では、一例として、ＢＣＭＣＳ制御部３２がコンテンツの内容に関連した名称を付けることとする。例えば、「ｓｐｏｒｔｓ」、「ｎｅｗｓ」、「ｗｅａｔｈｅｒ」…といったディレクトリ名とする。或いは、コンテンツとは関係なく、「ＢＣＭＣＳ０００」、「ＢＣＭＣＳ００１」、「ＢＣＭＣＳ００２」…といった名称のディレクトリとしても良い。
ＢＣＭＣＳ制御部３２が、基地局を経由してコンテンツサーバからデータを取得する際に、コンテンツに応じたディレクトリ名をファイル管理部３１に指定すると、ファイル管理部３１がその名称のディレクトリがデータ領域内に既に存在する場合はそのディレクトリを確保し、無い場合は、指定された名称のディレクトリを生成する。ファイル管理部３１のディレクトリ確保・生成時の処理については、詳細は後述する。

予約フラグは、そのディレクトリが既にＢＣＭＣＳ制御部３２が取得するコンテンツデータのために確保されているか否かを示すフラグであり、「０」であった場合には、そのディレクトリが確保されていない（確保及び使用可能である）ことを、「１」であった場合はそのディレクトリが既に確保されて使用不能であることを示している。
予約容量は、ＢＣＭＣＳアプリケーションが必要とする容量を基に決定された、確保される領域のデータ容量である。

空き容量は、予約容量を確保したときのそのディレクトリの空き容量を示している。すなわち、そのディレクトリ内にすでにデータファイルが存在する場合、ディレクトリ全体のデータ容量から既に存在するデータファイルのデータ容量を差し引いたデータ容量が空き容量である。
確保日時は、そのディレクトリがＢＣＭＣＳアプリケーションによって確保された日時を、解放日時は、そのディレクトリがファイル管理部３１によって解放された日時を示している。

以下、ＢＣＭＣＳアプリケーション動作時のファイル管理部３１の動作例について説明する。
ＢＣＭＣＳ制御部３２が、コンテンツサーバにユーザ登録をすると共に、ファイル管理部３１に対して記憶部２内にデータ領域（ディレクトリ）を確保するように要求する。ファイル管理部３１は、ＢＣＭＣＳ制御部３２の要求に応じて記憶部２内にディレクトリを確保する。
図３は、ファイル管理部３１がＢＣＭＣＳ制御部３２の要求に応じて記憶部２内にディレクトリを確保する場合の動作例を示したフローチャートである。
ステップＳＴ１：
ファイル管理部３１は、ＢＣＭＣＳ制御部３２が指定するディレクトリの名称をＢＣＭＣＳ制御部３２から取得する。また、このときにファイル管理部３１は、ＢＣＭＣＳ制御部３２がコンテンツサーバより登録を行うコンテンツが必要とする容量に関する情報も取得する。
ステップＳＴ２：
ファイル管理部３１は、予約領域テーブルを参照し、ＢＣＭＣＳ制御部３２が指定するディレクトリ名がテーブル内に存在する場合はステップＳＴ３に進み、存在しない場合はステップＳＴ４に進む。
ここで、存在する場合というのは、既にＢＣＭＣＳ制御部３２が記憶部２に記憶させようとするコンテンツデータに関する他のデータが既に記憶部２に記憶されている、或いはされていた（既にデータが削除された場合もある、データ削除の処理については後述）場合を意味している。

ステップＳＴ３：
ファイル管理部３１は、記憶部２に記憶された予約領域テーブルの予約フラグを参照し、ＢＣＭＣＳ制御部３２に指定されたディレクトリの予約フラグが「０」であった場合（予約（確保）されていない場合）はステップＳＴ５に進み、予約フラグが「１」であった場合（予約されていた場合）には処理を終了する。
ステップＳＴ４：
ファイル管理部３１は、記憶部２のデータ領域内にＢＣＭＣＳ制御部３２に指定されたディレクトリ名のディレクトリを生成してステップＳＴ５に進む。

ステップＳＴ５：
ファイル管理部３１は、記憶部２の空き容量を取得する。
ステップＳＴ６：
ファイル管理部３１は、ＢＣＭＣＳ制御部３２が要求してきたコンテンツデータの容量（ＢＣＭＣＳが必要とするデータ容量）よりもステップＳＴ５において取得した空き容量の方が大きい場合はステップＳＴ７に進み、そうでない場合は処理を終了する。

ステップＳＴ７：
ファイル管理部３１は、ＢＣＭＣＳ制御部３２が要求してきたディレクトリを確保したとして、予約領域テーブルの予約フラグを「１」に更新し、同時に確保日時を更新する。
以上のようにして、ファイル管理部３１はＢＣＭＣＳ制御部３２の要求に従いデータ領域を確保する。確保されたデータ領域（ディレクトリ）は、要求されたデータ容量よりも大きいデータ領域なので、ＢＣＭＣＳ制御部３２が通信部１を介してコンテンツサーバから取得したコンテンツデータは確保されたディレクトリに格納可能である。
このようにしてデータ領域内の所定の容量のデータ領域（ディレクトリ）がファイル管理部３１により確保されることにより、確保されたディレクトリにＢＣＭＣＳ制御部３２により取得されたコンテンツデータが書き込まれる用意ができたことになる。

次に、ファイル管理部３１が、ＢＣＭＣＳ制御部３２が通信部１を介して取得したデータを記憶部２のデータ領域に書き込む場合の動作例について説明する。
図４は、ファイル管理部３１が、ＢＣＭＣＳ制御部３２が取得したコンテンツデータを、ＢＣＭＣＳ制御部３２が指定するディレクトリに書き込む場合の動作例を説明するためのフローチャートである。
ステップＳＴ１１：
ファイル管理部３１は、記憶部２に記憶された予約領域テーブルの予約フラグを参照し、ＢＣＭＣＳ制御部３２に指定されたディレクトリの予約フラグが「１」であった場合（予約（確保）されていた場合）はステップＳＴ１２に進み、予約フラグが「０」であった場合（予約されていない場合）には処理を終了する。
ステップＳＴ１２：
ファイル管理部３１は、予約領域テーブルの空き容量を参照し、ＢＣＭＣＳ制御部３２に指定されたディレクトリの空き容量情報を取得する。

ステップＳＴ１３：
ファイル管理部３１は、ＢＣＭＣＳ制御部３２が要求してきたデータ容量（ＢＣＭＣＳが必要とするデータ容量）よりもステップＳＴ１２において取得した空き容量の方が大きい場合はステップＳＴ１４に進み、そうでない場合は処理を終了する。
ステップＳＴ１４：
ファイル管理部３１は、ＢＣＭＣＳ制御部３２が指定したディレクトリにＢＣＭＣＳ制御部３２が取得したデータを書き込む。

ステップＳＴ１５：
ファイル管理部３１は、ステップＳＴ１４において書き込んだデータの分、空き容量を減らして予約情報テーブルを更新する。
このようにして、ファイル管理部３１はＢＣＭＣＳ制御部３２が取得したデータを書き込む。書き込まれたデータは、ＢＣＭＣＳ制御部３２によって使用される。

次に、新たなコンテンツデータを受信する際に空き容量が足りず、古いコンテンツデータを削除したい、或いは、ＢＣＭＣＳ制御部３２がディレクトリに書き込まれたデータの使用が終了した、等の場合には、ＢＣＭＣＳ制御部３２の要求に従いデータフォルダから当該コンテンツデータの削除を行う。
図５は、ファイル管理部３１が、ディレクトリに書き込まれたデータの削除を行う際の動作例を示すフローチャートである。
ステップＳＴ２１：
ファイル管理部３１は、予約領域テーブルを参照し、ＢＣＭＣＳ制御部３２が指定したディレクトリの予約フラグが「１」であればステップＳＴ２２に進み、「０」であれば処理を終了する。
ステップＳＴ２２：
ファイル管理部３１は、ＢＣＭＣＳ制御部３２が指定したデータの削除を行う。

ステップＳＴ２３：
ファイル管理部３１は、ステップＳＴ２２においてデータが削除されたことにより変化した空き容量を反映して予約領域テーブルを更新する。
このようにして、ファイル管理部３１はＢＣＭＣＳ制御部３２により使用され終わったデータや古いデータの削除を行う。

ＢＣＭＣＳ制御部３２は、コンテンツサーバへのユーザ登録を解除する際には、記憶部２に確保されたディレクトリに記憶されたデータが削除した後に、通信部１にてコンテンツサーバへ接続するとともにユーザ登録を解除し、同時に、記憶部２に確保されたディレクトリを開放する処理をファイル管理部３１に対して要求する。ディレクトリの解放を要求するのは、確保されたディレクトリには１つのコンテンツに関するデータしか書き込むことができないため、ディレクトリを開放しないと新たなコンテンツのためにディレクトリを確保する記憶部２のデータ容量がなくなってしまうからである。

図６に、ディレクトリ解放時のファイル管理部３１の動作例を示す。
図６は、ディレクトリ解放時のファイル管理部３１の動作例を示すフローチャートである。
ステップＳＴ３１：
ファイル管理部３１は、ディレクトリ解放時の予約領域テーブルを参照し、ＢＣＭＣＳ制御部３２が指定したディレクトリの予約フラグが「１」であればステップＳＴ３２に進み、「０」であれば処理を終了する。
ステップＳＴ３２：
ファイル管理部３１は、予約領域テーブルを参照し、ＢＣＭＣＳ制御部３２が指定したディレクトリの空き容量が予約容量と同じでない場合、すなわち、ＢＣＭＣＳ制御部３２が指定したディレクトリ内に、まだデータが残っていた場合には、ステップＳＴ３３に進み、そうでない場合にはステップＳＴ３４に進む。

ステップＳＴ３３：
ファイル管理部３１は、ＢＣＭＣＳ制御部３２に指定されたディレクトリ内に残っていたデータファイルを削除する。
ステップＳＴ３４：
ファイル管理部３１は、予約領域テーブルを更新（ＢＣＭＣＳ制御部３２に指定されたディレクトリの予約フラグを「１」から「０」に更新し、さらに予約容量及び空き容量を「０」に更新して解除日時を更新）する。

このようにして、ファイル管理部３１は、確保していたディレクトリを開放し、ＢＣＭＣＳ制御部３２の次なるディレクトリ生成の要求に応えることができるようになる。
なお、ファイル管理部３１は、ＢＣＭＣＳ制御部３２以外のアプリケーションの要求に従い、予約領域テーブルにより管理される確保されたディレクトリ以外のデータ領域にデータファイルを書き込む場合には、以下のように動作する。
図７は、予約領域以外に書き込みを行う場合のファイル管理部３１の動作例を説明するためのフローチャートである。

ステップＳＴ４１：
ファイル管理部３１は、記憶部２の空き容量を取得する。ここでいう空き容量は、記憶部２の全体のデータ容量から、既に書き込まれているデータの容量と、予約領域の合計容量とを除いた容量のことを指している。
ステップＳＴ４２：
ファイル管理部３１は、アプリケーションが書き込みを要求するデータ容量が、ステップＳＴ４１において取得した空き容量よりも小さい場合にはステップＳＴ４３に進み、そうでない場合は書き込み不可として処理を終了するか、或いは、図５に示すデータ削除処理を行うことを要求する。

ステップＳＴ４３：
ファイル管理部３１は、アプリケーションが書き込みを要求するデータファイルを記憶部２のデータ領域に書き込む。
以上のようにして、ファイル管理部３１は、ＢＣＭＣＳ制御部３２以外のアプリケーションの要求に従い、予約領域テーブルにより管理される確保されたディレクトリ以外のデータ領域にデータファイルを書き込む。

以上説明したように、本実施形態の携帯端末１００によれば、ＢＣＭＣＳ制御部３２は、コンテンツサーバにユーザ登録すると同時に、コンテンツサーバから取得するコンテンツデータを格納するためのデータ領域（ディレクトリ）をファイル管理部３１に確保させ、ファイル管理部３１は確保したディレクトリにはＢＣＭＣＳ制御部３２が取得した１種類のコンテンツデータのみを格納させるため、大容量のデータを配信するＢＣＭＣＳによるコンテンツデータを格納するための領域を確保できる。
また、本実施形態の携帯端末１００によれば、ＢＣＭＣＳ制御部３２が、記憶部２のディレクトリに格納したコンテンツデータの全てを使用し終わり削除した後には、コンテンツサーバに対して行っていたユーザ登録を解除すると同時に、ファイル管理部３１に記憶部２内に確保していたディレクトリを開放させるため、ＢＣＭＣＳによる大容量のコンテンツデータにより記憶部２が埋まってしまい、他のデータを記憶できない、という事態を回避することができる。

本発明は上述した実施形態には限定されない。
すなわち、本発明の実施に際しては、本発明の技術的範囲またはその均等の範囲内において、上述した実施形態の構成要素に関し様々な変更、コンビネーション、サブコンビネーション、並びに代替を行ってもよい。

図１は、携帯端末１００の構成の一例を示す図である。図２は、予約領域テーブルの一例を示す図である。図３は、ファイル管理部３１がＢＣＭＣＳアプリケーションの要求に応じて記憶部２内にディレクトリを確保する場合の動作例を示したフローチャートである。図４は、ファイル管理部３１が、ＢＣＭＣＳアプリケーションが取得したデータを、ＢＣＭＣＳアプリケーションが指定するディレクトリに書き込む場合の動作例を説明するためのフローチャートである。図５は、ファイル管理部３１が、ディレクトリに書き込まれたデータの使用終了後に当該データの削除を行う際の動作例を示すフローチャートである。図６は、ディレクトリ解放時のファイル管理部３１の動作例を示すフローチャートである。図７は、予約領域以外に書き込みを行う場合のファイル管理部３１の動作例を説明するためのフローチャートである。

符号の説明

１００…携帯端末、１…通信部、２…記憶部、３…制御部、３１…ファイル管理部、３２…ＢＣＭＣＳ制御部、４…マイク、５…スピーカ、６…操作部、７…表示部

Claims

各種データを格納する記憶部と、
公衆通信網を介してＢＣＭＣＳ通信により、コンテンツサーバからデータを取得する通信部と、
前記通信部により取得したコンテンツのデータを前記記憶部に格納するよう制御する制御部と、
を備え、
前記制御部は、
該当するコンテンツの種類ごとに、ユーザが前記コンテンツサーバに対してユーザ登録すると、前記記憶部に、登録された前記コンテンツの種類に対応するディレクトリを作成するとともに、
前記コンテンツサーバに対してユーザが前記コンテンツの種類ごとに登録を解除すると、当該種類に対応した前記ディレクトリを開放する
携帯通信端末。
前記制御部は、
前記公衆通信網から配信される所定のデータの格納に要する容量を、予め前記公衆通信網から取得して、当該所定のデータの格納に要する容量を前記記憶部の空き領域と比較し、空き領域の方が大きければ、前記所定のデータを格納するためのデータ領域を前記記憶部に確保するとともに、前記データ領域の容量に前記所定のデータを特定する情報を対応付けて、前記記憶部に記憶されるテーブルに登録する予約処理と、
前記通信部によりデータの取得が生じ、取得するデータが前記情報に基づいて前記所定のデータであると判定される場合には、当該データを前記データ領域に格納するとともに前記テーブルに登録される前記データ領域の容量を前記所定のデータの格納に対応した値に更新し、取得するデータが前記情報に基づいて前記所定のデータではないと判定される場合には、当該データが、前記記憶部の空き容量から前記テーブルに登録した前記データ領域の容量を差し引いた容量に対して格納可能であるか否かの判定を行う格納処理と、
を実行可能である
請求項１に記載の携帯通信端末。
前記テーブルは、前記データ領域の容量に対し所定のフラグ値を対応付けて登録され、
前記制御部は、前記予約処理において、前記データ領域を確保した際には前記テーブルにおけるフラグ値を、前記データ領域の確保がなされたことを示す値とする
請求項２に記載の携帯通信端末。
前記制御部は、ユーザの登録に応じて作成される前記ディレクトリの名称を前記所定のデータを特定する情報に関連した名称とする
請求項１ないし３のいずれか一項に記載の携帯通信端末。
前記制御部は、前記公衆通信網から前記所定のデータを取得するための所定のアプリケーションプログラムを含む複数種類のアプリケーションプログラムを実行可能であって、前記記憶部に前記ディレクトリを生成する際に、当該ディレクトリの名称を前記所定のアプリケーションプログラムに対応した名称とする
請求項１ないし３のいずれか一項に記載の携帯通信端末。
前記制御部は、前記ディレクトリを生成する際に、当該ディレクトリの名称を、前記所定のデータに含まれる前記コンテンツの種類に関する名称とする
請求項３に記載の携帯通信端末。
前記制御部は、前記ディレクトリの開放時に、当該ディレクトリ内のデータを削除する
請求項１に記載の携帯通信端末。