(57)【特許請求の範囲】
【請求項１】
検索条件に基づいて、データベースから目的とするデータを取得するようにする処理手段と、
前記処理手段により取得された目的とするデータを記憶保持するメモリ手段と、
前記処理手段において前記検索条件に従ったデータを取得する処理を行うことにより得られる結果情報を取得する取得手段と、
前記検索条件と、前記取得手段を通じて取得された前記結果情報とを関連付けたテーブル情報を記憶保持するテーブル記憶手段と、
前記処理手段で用いられるクロック信号を発生させる処理クロック信号発生手段と、
前記メモリ手段へのアクセスのためのクロック信号を発生させるメモリクロック信号発生手段と、
新たに指示するようにされた検索条件に基づいて、前記処理手段においてデータを取得する処理を実行する場合において、前記検索条件と前記検索条件に基づいて参照する前記テーブル記憶手段の前記テーブル情報とに基づいて、必要があると判断した場合に、前記処理クロック信号発生手段と前記メモリクロック信号発生手段との一方あるいは両方を制御して、発生させるクロック信号の周波数を高くするように制御するクロック信号制御手段と
を備えることを特徴とする情報処理装置。
【請求項２】
請求項１に記載の情報処理装置であって、
前記結果情報は、前記検索条件にしたがって前記処理手段により取得されたデータの件数である結果件数と、前記処理手段においての前記検索条件に従ったデータ取得処理にかかった時間である取得時間とであり、
前記取得手段は、前記取得時間を計測する計測手段を含むことを特徴とする情報処理装置。
【請求項３】
請求項２に記載の情報処理装置であって、
前記クロック信号制御手段は、前記検索条件が演算を伴うものであり、前記検索条件に基づいて参照する前記テーブル記憶手段の対応するテーブル情報の結果件数が少なく、かつ、当該テーブル情報の取得時間が多い場合には、前記処理クロック信号発生手段を制御して、前記処理手段で用いられるクロック信号の周波数を高くするように制御することを特徴とする情報処理装置。
【請求項４】
請求項２に記載の情報処理装置であって、
前記クロック信号制御手段は、前記検索条件が演算を伴うものであり、前記検索条件に基づいて参照する前記テーブル記憶手段の対応するテーブル情報の結果件数が多く、かつ、当該テーブル情報の取得時間も多い場合には、前記処理クロック信号発生手段と前記メモリクロック信号発生手段とを制御して、前記処理手段で用いられるクロック信号と前記メモリ手段へのアクセスのためのクロック信号との両方の周波数を高くするように制御することを特徴とする情報処理装置。
【請求項５】
請求項２に記載の情報処理装置であって、
前記クロック信号制御手段は、前記検索条件が演算を伴わないものであり、前記検索条件に基づいて参照する前記テーブル記憶手段の対応するテーブル情報の結果件数が多く、かつ、当該テーブル情報の取得時間も多い場合には、前記メモリクロック信号発生手段を制御して、前記メモリ手段へのアクセスのためのクロック信号の周波数を高くするように制御することを特徴とする情報処理装置。
【請求項６】
検索条件に基づいて、データベースから目的とするデータを取得する処理を行う処理工程と、
前記処理工程において取得した目的とするデータを所定のメモリに記録する記録工程と、
前記処理工程においての前記検索条件に従ったデータを取得する処理を行うことにより得られる結果情報を取得する取得工程と、
前記検索条件と、前記取得工程を通じて取得した前記結果情報とを関連付けたテーブル情報をテーブル記憶手段に記録するテーブル形成工程と、
新たに指示するようにされた検索条件に基づいて、前記処理工程を通じてデータを取得する処理を行う場合に、前記検索条件と前記検索条件に基づいて参照する前記テーブル記憶手段の前記テーブル情報とに基づいて、必要があると判断した場合に、前記処理手段で用いられるクロック信号と、前記メモリへのアクセスのためのクロック信号との一方あるいは両方の周波数を高くするように制御するクロック信号制御工程と
を有することを特徴とする情報処理装置におけるクロック信号制御方法。
【請求項７】
データを取得する処理を行う処理手段と、前記処理手段により取得されたデータを記憶保持するデータメモリと、前記処理手段を通じてデータを取得する処理を行うことにより得られる結果情報を取得する取得手段と、テーブル情報を記憶保持するテーブルメモリと、前記処理手段で用いられるクロック信号を形成する処理クロック信号形成手段と、前記データメモリへのアクセスのためのクロック信号を形成するメモリクロック信号形成手段と、前記処理クロック信号形成手段と前記メモリクロック信号形成手段との一方あるいは両方を制御するクロック信号制御手段とを備えた情報処理装置に搭載されたコンピュータにより実行されるプログラムであって、
前記処理手段を機能させ、検索条件に基づいて、データベースから目的とするデータを取得する処理を行う処理ステップと、
前記処理ステップを通じて取得した目的とするデータを前記データメモリに記録する記録ステップと、
前記処理ステップにおいての前記検索条件に従ったデータを取得する処理を行うことにより得られる結果情報を、前記取得手段を通じて取得する取得ステップと、
前記検索条件と、前記取得ステップを通じて取得した前記結果情報とを関連付けたテーブル情報を前記テーブルメモリに記録するテーブル形成ステップと、
新たに指示するようにされた検索条件に基づいて、前記取得ステップからの処理を行う場合に、前記検索条件と前記検索条件に基づいて参照する前記テーブルメモリの前記テーブル情報とに基づいて、必要があると判断した場合に、前記クロック制御手段が、前記処理クロック信号形成手段と前記メモリクロック信号形成手段との一方あるいは両方を制御して、前記処理手段で用いられるクロック信号と前記データメモリへのアクセスのためのクロック信号との一方あるいは両方を制御するクロック信号制御ステップと
を前記コンピュータに実行させることを特徴とするクロック信号制御プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、例えば、携帯電話端末やＰＤＡ（Personal Digital Assistants）などと呼ばれる携帯情報端末などの装置、当該装置におけるクロック信号の制御に用いられる方法及びプログラムに関する。
【背景技術】
【０００２】
携帯型の種々の情報処理装置の基盤となるいわゆるハードディスクプラットフォームでは、低消費電力化のために、クロック制御が可能なものが存在する。携帯電話の場合、例えば、米国のＴｅｘａｓ  Ｉｎｓｔｒｕｍｅｎｔｓ社が提供する「ＯＭＡＰ（Open Multimedia Application Platform）」と呼ばれるＣＰＵ（Central Processing Unit）コアやルネサステクノロジ社が提供する「ＳＨ−Ｍｏｂｉｌ  Ｇ２」と呼ばれるチップセットにおいては、特定の設定を行うことで、ＣＰＵやメモリバスのクロック制御を実行できるようにされている。
【０００３】
また、ＰＣ（Personal Computer）やサーバーでは、プロファイラやタスクマネジャなどのソフトウェアによって、ＣＰＵの負荷や動作しているプログラムを監視し、プラットフォームが自動的に、クロック制御を行う仕組みが存在する。
【０００４】
しかしながら、携帯電話などのいわゆる携帯機器では、携帯機器が備えるハードウェア資源の機能、性能、容量などのいわゆるリソースの問題もあり、上述もしたように特別なハードウェアプラットフォームを使用する場合やＰＣなどのようにリソースに余裕のある場合を除いては、ハードウェアプラットフォームの機能としてクロック制御を実現することは難しい。
【０００５】
このため、携帯機器では、クロック制御が必要なアプリケーションがその動作シーケンス中にクロック制御処理を実行するようにしている場合が多い。例えば、後に記す特許文献１には、「カメラ動作シーケンスにシステムクロックの制御を組み入れ、バッテリー電圧の状態に関わらずシステムの処理内容に応じてクロック周波数を切り替えることで、消費電力の低減及びバッテリー使用効率の向上を達成させる。」という技術が開示されている。
【０００６】
なお、上述した特許文献１は、以下に示す通りである。
【特許文献１】特開２００３−６０９６４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
ところで、上述した特許文献１に記載された技術の場合、ある処理ブロックについて、その処理量が一定であり、当該処理ブロックにおける処理量と、電源リソース（電源資源）のトレードオフについて予想出来る場合には、消費電力の低減及びバッテリー使用効率の向上を達成でき、問題は無い。つまり、その処理ブロックでのデータ処理量が一定であり、異なる周波数のクロック信号を用いたときの消費電力が正確に把握できる場合には、当該処理ブロックにおけるクロック制御（クロック信号の周波数の制御）を適切に行うことが可能である。
【０００８】
しかしながら、携帯電話などの携帯機器の場合には、動的に増加・減少する複数のデータを処理するケースがままあり、データ一つ一つの処理時間についても、変動が大きい。例えば、携帯電話に搭載されたカメラ機能において、ＶＧＡ（Video Graphics Array）規格の通常モード（解像度が６４０×４８０ピクセルのモード）と、ＳＶＧＡ（Super VGA）規格の高画質モード（解像度が８００×６００ピクセルのモード）とがあった場合、通常モードで撮影を行った場合と高画質モードで撮影を行った場合とでは、データ量は大きく異なり、処理時間も変わることになる。
【０００９】
また、データベースから目的とするデータを検索して取得するような場合にも、検索条件に応じて、取得するデータの数も異なるし、検索・取得処理にかかる処理時間も異なることになる。このように、基本的には同じ処理でありながら、用いる処理モードや処理条件等に応じて、処理対象のデータの量や処理の結果得られるデータの数が異なり、処理時間に差が生じる場合も多い。
【００１０】
この場合、処理対象のデータ量の影響を受けることなく、クロック制御を行うために、細かな単位でクロック制御を行うようにすることが考えられる。しかし、クロック制御そのものについても、細かな単位で連続して行うようにした場合には、クロック制御のための処理量が見過ごすことの出来ない処理量となるため、ＣＰＵに係る負荷などを考慮すると推奨できない。
【００１１】
以上のことにかんがみ、この発明は、取得されるデータの数や処理時間が異なるために、適切なクロック制御の難しいデータ取得・検索を行う処理において、消費電力を増大させること無く、適切にクロック制御を行って処理の高速化を実現することを目的とする。
【課題を解決するための手段】
【００１２】
上記課題を解決するため、請求項１に記載の発明の情報処理装置は、
検索条件に基づいて、データベースから目的とするデータを取得するようにする処理手段と、
前記処理手段により取得された目的とするデータを記憶保持するメモリ手段と、
前記処理手段において前記検索条件に従ったデータを取得する処理を行うことにより得られる結果情報を取得する取得手段と、
前記検索条件と、前記取得手段を通じて取得された前記結果情報とを関連付けたテーブル情報を記憶保持するテーブル記憶手段と、
前記処理手段で用いられるクロック信号を発生させる処理クロック信号発生手段と、
前記メモリ手段へのアクセスのためのクロック信号を発生させるメモリクロック信号発生手段と、
新たに指示するようにされた検索条件に基づいて、前記処理手段においてデータを取得する処理を実行する場合において、前記検索条件と前記検索条件に基づいて参照する前記テーブル記憶手段の前記テーブル情報とに基づいて、必要があると判断した場合に、前記処理クロック信号発生手段と前記メモリクロック信号発生手段との一方あるいは両方を制御して、発生させるクロック信号の周波数を高くするように制御するクロック信号制御手段と
を備えることを特徴とする。
【００１３】
この請求項１に記載の発明の情報処理装置によれば、指示するようにされた検索条件にしたがって処理手段によりデータを取得する処理が実行され、この結果得られた目的とするデータはメモリ手段に記憶される。このとき、処理手段による処理の結果得られる結果情報が取得手段により取得される。そして、検索条件と取得された結果情報とは関連付けられて、テーブル情報としてテーブル記憶手段に記憶される。
【００１４】
そして、新たに指示するようにされた検索条件にしたがって処理手段を通じてデータを取得する処理を行う場合には、新たに指示するようにされた当該検索条件と、当該検索条件にしたがって参照されるテーブル記憶手段のテーブル情報とに基づいて、クロック信号制御手段により、処理クロック信号発生手段とメモリクロック信号発生手段との一方または両方が制御され、処理手段で用いられるクロック信号とメモリ手段へのアクセスのためのクロック信号（処理手段とメモリ手段との間においてデータをやり取りする場合に用いるクロック信号）との一方あるいは両方が制御するようにされる。
【００１５】
これにより、検索条件と、当該検索条件にしたがって参照されるテーブル記憶手段のテーブル情報とに基づいて、今回実行するデータ取得処理が、処理の高速化のボトルネックとなっているかを判断し、処理のボトルネックとなっている場合において、処理手段で用いられるクロック信号とメモリ手段へのアクセスのためのクロック信号との一方あるいは両方の周波数を高くし（クロックアップを行って）、処理の高速化を実現すると共に、ボトルネック部分においてのみクロックアップすることにより、不必要に電力を消費することも無いようにすることができるようにされる。
【００１６】
また、請求項２に記載の発明の情報処理装置は、請求項１に記載の情報処理装置であって、
前記結果情報は、前記検索条件にしたがって前記処理手段により取得されたデータの件数である結果件数と、前記処理手段においての前記検索条件に従ったデータ取得処理にかかった時間である取得時間とであり、
前記取得手段は、前記取得時間を計測する計測手段を含むことを特徴とする。
【００１７】
この請求項２に記載の発明の情報処理装置によれば、取得手段は、処理手段を通じて行うデータを取得する処理にかかった処理時間である取得時間を計測する計測手段を含み、取得手段は、処理手段によるデータを取得する処理により取得されたデータの件数である結果件数と取得時間とを結果情報として取得することができるようにされる。
【００１８】
これにより、テーブル記憶手段には、検索条件と、結果件数と、取得時間とが関連付けられたテーブル情報が記憶保持されることになり、これらの情報をも用いて、前記処理手段で用いられるクロック信号と前記メモリ手段へのアクセスのためのクロック信号との一方あるいは両方の周波数を高くする必要があるか否かを適切に判断することができるようにされる。
【００１９】
また、請求項３に記載の発明の情報処理装置は、請求項２に記載の情報処理装置であって、
前記クロック信号制御手段は、前記検索条件が演算を伴うものであり、前記検索条件に基づいて参照する前記テーブル記憶手段の対応するテーブル情報の結果件数が少なく、かつ、当該テーブル情報の取得時間が多い場合には、前記処理クロック信号発生手段を制御して、前記処理手段で用いられるクロック信号の周波数を高くするように制御することを特徴とする。
【００２０】
この請求項３に記載の発明の情報処理装置によれば、検索条件に演算を行う条件を含み、当該検索条件に基づいて参照されるテーブル記憶手段のテーブル情報の結果件数が少なく、かつ、当該テーブル情報の取得時間が多い場合には、新たな検索条件に応じたデータ取得処理は、処理手段における処理に時間がかかると判断して、処理手段で用いられるクロック信号のみの周波数を高くさせるように（アップさせるように）制御する。
【００２１】
これにより、処理手段における処理に時間がかかる場合をボトルネックとなる部分として適切に特定し、この特定した場合においてのみ、処理手段での処理を効果的に高速化して、データ取得処理全体の高速化を実現することができるようにされる。また、不必要な場合にクロック信号の周波数を高くすることも無いので、消費電力を増大させることも無い。
【００２２】
また、請求項４に記載の発明の情報処理装置は、請求項２に記載の情報処理装置であって、
前記クロック信号制御手段は、前記検索条件が演算を伴うものであり、前記検索条件に基づいて参照する前記テーブル記憶手段の対応するテーブル情報の結果件数が多く、かつ、当該テーブル情報の取得時間も多い場合には、前記処理クロック信号発生手段と前記メモリクロック信号発生手段とを制御して、前記処理手段で用いられるクロック信号と前記メモリ手段へのアクセスのためのクロック信号との両方の周波数を高くするように制御することを特徴とする。
【００２３】
この請求項４に記載の情報処理装置によれば、検索条件に演算を行う条件を含み、当該検索条件に基づいて参照されるテーブル記憶手段のテーブル情報の結果件数が多く、かつ、当該テーブル情報の取得時間が多い場合には、新たな検索条件に応じたデータ取得処理は、処理手段における処理と、メモリ手段へのデータの記録処理とに時間がかかると判断して、処理手段で用いられるクロック信号と、メモリ手段へのアクセスのためのクロック信号との両方の周波数を高くするように制御する。
【００２４】
これにより、処理手段における処理にも、また、メモリ手段へのデータの記録処理にも時間がかかる場合をボトルネックとなる部分として適切に特定し、この特定した場合においてのみ処理手段での処理とメモリ手段へのデータの記録処理との両方を効果的に高速化して、データ取得処理全体の高速化を実現することができるようにされる。また、不必要な場合にクロック信号の周波数を高くすることも無いので、消費電力を増大させることも無い。
【００２５】
また、請求項５に記載の発明の情報処理装置は、請求項２に記載の情報処理装置であって、
前記クロック信号制御手段は、前記検索条件が演算を伴わないものであり、前記検索条件に基づいて参照する前記テーブル記憶手段の対応するテーブル情報の結果件数が多く、かつ、当該テーブル情報の取得時間も多い場合には、前記メモリクロック信号発生手段を制御して、前記メモリ手段へのアクセスのためのクロック信号の周波数を高くするように制御することを特徴とする。
【００２６】
この請求項５に記載の情報処理装置によれば、検索条件に演算を行う条件を含まず、当該検索条件に基づいて参照されるテーブル記憶手段のテーブル情報の結果件数が多く、かつ、当該テーブル情報の取得時間も多い場合には、新たな検索条件に応じたデータ取得処理は、メモリ手段へのデータの記録処理に時間がかかると判断して、メモリ手段へのアクセスのためのクロック信号のみをアップさせるように制御する。
【００２７】
これにより、メモリ手段へのデータの記録処理に時間がかかる場合をボトルネックとなる部分として適切に特定し、この特定した場合においてのみ、メモリ手段へのデータの記録処理を効果的に高速化することによって、データ取得処理全体の高速化を実現することができるようにされる。また、不必要な場合にクロック信号の周波数を高くすることも無いので、消費電力を増大させることも無い。
【発明の効果】
【００２８】
この発明によれば、処理毎に取得されるデータの数や処理時間が異なるために、適切なクロック制御の難しい、データの取得・検索を行う処理において、消費電力を増大させること無く、適切にクロック制御を行って処理の高速化を実現することが出来る。
【発明を実施するための最良の形態】
【００２９】
以下、図を参照しながら、この発明の一実施の形態について説明する。以下に説明する実施の形態においては、この発明を携帯電話端末に適用した場合を例にして説明する。
【００３０】
［実施の形態の携帯電話端末の構成について］
まず、この実施の形態の携帯電話端末の構成について説明する。図１は、この発明の一実施の形態が適用された、携帯電話端末の構成例を説明するためのブロック図である。図１に示すように、この実施の形態の携帯電話端末には、制御信号の伝送に用いられる制御ライン（制御バス）１０１と、種々のデータの伝送に用いられるデータライン（データバス）１０２とが設けられている。
【００３１】
制御ライン１０１には、図１に示すように、ＣＰＵ（Central Processing Unit）１３０、通信回路１０４、ＲＯＭ（Read Only Memory）１０９、ＲＡＭ（Random Access Memory）１１０、ＥＥＰＲＯＭ（Electrically Erasable and Programmable ROM）１１１、表示制御部１１２、押下検出部１１５、鳴音制御部１１６、ＬＡＮ（Local Area Network）モジュール１１８、カメラモジュール１２０、ＵＳＢ（Universal Serial Bus）インターフェース（以下、ＵＳＢＩ／Ｆと略称する。）１２１、時計回路１２２、クロック信号発生部１４０が接続されている。
【００３２】
また、データライン１０２には、図１に示すように、通信回路１０４、ＲＯＭ１０９、ＲＡＭ１１０、ＥＥＰＲＯＭ１１１、表示制御部１１２、押下検出部１１５、Ｄ／Ａ変換器１０５、Ａ／Ｄ変換器１０８、鳴音制御部１１６、ＬＡＮモジュール１１８、カメラモジュール１２０、ＵＳＢＩ／Ｆ１２１、時計回路１２２が接続されている。
【００３３】
さらに、通信回路１０４には、送受信アンテナ１０３が接続され、表示制御部１１２には、表示部としてのＬＣＤ（Liquid Crystal Display）１１３が接続され、押下検出部１１５には、キー操作部１１４が接続され、ＬＡＮモジュール１１８には、ＬＡＮ用送受信アンテナ１１９が接続されている。
【００３４】
また、Ｄ／Ａ変換器１０５と鳴音制御部１１６とには、受話器としても用いられるスピーカ１０６が接続され、Ａ／Ｄ変換器１０８には、送話器として用いられるマイクロホン(図１においては、マイクと記載。)１０７が接続されている。なお、ここでは、鳴音制御部１１６とＤ／Ａ変換器１０５には、スピーカ１０６が接続されるものとして説明したが、これに限るものではない。そのそれぞれ個別のスピーカを設けるようにすることももちろん可能である。
【００３５】
また、この実施の形態の携帯電話端末は、図示しないが、例えば、充電式バッテリパックを電源として用い、当該携帯電話端末の電源がオンにされている場合に、各回路部分に駆動電源を供給する電源供給回路を備えたものである。
【００３６】
そして、この実施の形態の携帯電話端末は、ＣＰＵ１３０と、ＲＯＭ１０９と、ＲＡＭ１１０と、ＥＥＰＲＯＭ１１１とによりマイクロコンピュータを構成し、このマイクロコンピュータが、この実施の形態の携帯電話端末の各部を制御する制御部としての機能を有するようになっている。
【００３７】
［携帯通信端末の基本的な動作について］
次に、図１に示した構成を有するこの実施の形態の携帯電話端末の動作について説明する。まず、自機への着信時の処理、すなわち、自機にかかってきた電話に応答する場合の処理について説明する。送信されてくる着信通知信号は、送受信アンテナ１０３、通信回路１０４により受信選局される。通信回路１０４において選局された信号は、通信回路１０４において復調され、この復調された信号が制御ライン１０１を介してＣＰＵ１３０に通知するようにされる。
【００３８】
ＣＰＵ１３０は、受信選局した信号が、自機宛の着信通知信号である場合には、例えば、ＲＯＭ１０９に予め用意されている着信メロディなどの着信音を形成する着信音データを読み出して、これを鳴音制御部１１６に供給する。鳴音制御部１１６は、これに供給された着信音データからアナログ信号の着信音を形成し、これをスピーカ１０６に供給する。これにより、スピーカ１０６からは、着信音が放音され、着信があることが当該携帯電話端末の使用者に通知される。
【００３９】
同じように、ＣＰＵ１３０は、自機宛の着信通知信号を検出すると、図示しない振動装置（バイブレータ）を制御して振動させることにより、この振動によって着信があることを当該携帯電話端末の使用者に通知するようにすることもできるようにされている。なお、着信音による着信通知と、振動による着信通知との両方を同時に用いるようにすることも可能であるし、また、どちらか一方のみを用いるようにすることも可能である。
【００４０】
着信音により、あるいは、振動により、当該携帯電話端末の使用者が自己の携帯電話端末に着信があることに気付いた場合には、使用者は、キー操作部１１４に設けられた通話開始キー(オフフックキー)を操作することになる。通話開始キーが操作された場合には、これが押下検出部１１５により検出され、制御ライン１０１を通じてＣＰＵ１３０に通知される。
【００４１】
ＣＰＵ１３０は、押下検出部１１５からの通話開始キーが押下されたことの通知を受け付けると、通信回路１０４を制御して、応答信号を送出するなどの所定の通信回線の接続処理を行なう。これにより、自機に電話をかけてきた通信端末と、自機との間に通信回線が接続され、通話が行なえるようになる。
【００４２】
すなわち、電話をかけてきた相手先からの信号は、送受信アンテナ１０３、通信回路１０４を通じて受信選局されると共に、通信回路１０４において復調するなどの処理が行われてベースバンド信号とされ、これがデータライン１０２を通じてＤ／Ａ変換器１０５に供給される。
【００４３】
Ｄ／Ａ変換器１０５は、これに供給されたベースバンド信号をアナログ信号に変換して、これをスピーカ１０６に供給する。これにより、相手先から送信されて来た信号に応じた音声がスピーカ１０６より放音される。
【００４４】
また、この携帯電話端末の使用者からの音声は、マイクロホン１０７により集音され、アナログの電気信号としてＡ／Ｄ変換器１０８に供給される。Ａ／Ｄ変換器１０８は、これに供給されたアナログ音声信号をデジタル信号に変換し、データライン１０２を通じて通信回路１０４に供給する。
【００４５】
通信回路１０４は、これに供給されたデジタル信号を含む送信信号を形成して送受信アンテナ１０３を通じて送信する。これにより、ユーザーの音声が通信の相手先に送信するようにされる。このようにして、自機にかかってきた電話に応答し、電話をかけて来た相手先との間に通信回線を接続して通話を行なうようにすることができる。
【００４６】
また、この実施の形態の携帯電話端末から電話をかける場合には、例えば、携帯電話端末のキー操作部１１４に設けられている数字キーを押下操作して目的とする相手先の電話番号を入力するようにすると、押下操作された数字キーが押下検出部１１５により検出され、制御ライン１０１を通じてＣＰＵ１３０に通知される。ＣＰＵ１３０は、これを例えばＲＡＭ１１０に一時記憶し、通話開始キーが押下操作されたことを検出すると、受け付けた電話番号を含む発信信号を形成し、これを通信回路１０４、送受信アンテナ１０３を通じて送信する。
【００４７】
この発信信号は、基地局や交換機などの電話会社側の設備を通じて目的とする相手先の電話端末に送信するようにされる。そして、この発信信号に応じて、相手先が応答操作を行なった時には、相手先から応答信号が送信されて来るので、この応答信号を受信すると、ＣＰＵ１３０の制御により、通信回路１０４は、その目的とする相手先との間に通信回線が接続されたことを確認し、前述した自機への着信に応答して通話を行う場合と同様に、送受信アンテナ１０３、通信回路１０４、Ｄ／Ａ変換器１０５、スピーカ１０６、マイクロホン１０７、Ａ／Ｄ変換器１０８を通じて通話を行なうことができるようにされる。
【００４８】
なお、電話をかける場合には、携帯電話端末に予め登録しておくようにするいわゆる電話帳データの中から目的とする相手先の電話番号を選択し、通話開始キーを押下操作することにより、発信を行なうようにすることもできる。
【００４９】
また、電話がかかってきたときに、電話をかけて来た相手先の電話番号を表示したり、あるいは、現在時刻を表示したり、あるいは、上述の電話帳データの登録時や選択時において、電話番号やその電話番号に対応する氏名や名称を表示したり、あるいは、種々のガイダンスメッセージや警告メッセージなどを表示したりするために、表示制御部１１２、ＬＣＤ１１３が設けられている。すなわち、表示制御部１１２は、ＣＰＵ１３０の制御に応じて、ＬＣＤ１１３に各種の情報を表示する。なお、ＬＣＤ１１３は、比較的に大きな表示画面を有するものあり、種々の表示情報を視認性良くユーザーに提供することができるようにしている。
【００５０】
このようにして、この実施の形態の携帯電話端末は、かかってきた電話に対して応答したり、目的とする相手先に対して電話をかけたりすることができるものである。
【００５１】
さらに、この実施の形態の携帯電話端末は、例えば電話会社側の提供する機能を経由して、インターネットにアクセスし、目的とするホームページにアクセスして情報の検索を行ったり、必要な情報をダウンロードしたり、あるいは、電子メールの送受信を行うこともできるようにされている。
【００５２】
この実施の形態の携帯電話端末を通じてインターネットに接続する場合には、ユーザーは、キー操作部１１４に設けられている所定のインターネット接続キーを操作することにより、これが押下検出部１１５によって検出されて、インターネットへの接続要求が押下検出部１１５から制御ライン１０１を通じてＣＰＵ１３０に通知される。
【００５３】
これに応じてＣＰＵ１３０は、制御ライン１０１を通じて通信回路１０４を制御し、通信回路１０４においてインターネットへの接続要求を形成して、これが送受信アンテナ１０３を通じて送信される。このインターネットへの接続要求を受信した電話会社側のシステムは、当該要求に応じて、要求元の携帯電話端末をインターネットに接続するようにする。
【００５４】
これにより、この実施の形態の携帯電話端末はインターネットに接続され、目的とするサーバーにアクセスし、パケットデータを送受することにより、必要な情報の提供を要求し、これに応じた情報の提供を受けたりするなどのことができるようにされる。
【００５５】
また、この実施の形態の携帯電話端末は、キー操作部１１４、押下検出部１１５を通じて文字入力を行い、この入力した文字を、表示制御部１１２を通じて表示部１１３に表示して確認しながら、送信する電子メールをＥＥＰＲＯＭ１１１の送信フォルダ内に作成することもできるようにしている。この場合、入力された文字情報は、ＣＰＵ１３０の制御により、データライン１０２を通じて、ＥＥＰＲＯＭ１１１、表示制御部１１２に供給するようにされる。
【００５６】
このようにして、ＥＥＰＲＯＭ１１１内の送信フォルダに形成された送信用の電子メールは、キー操作部１１４に対して電子メールを送信する操作を行うことによって、これが押下検出部１１５で検出されて、制御ライン１０１を通じてＣＰＵ１３０に通知される。ＣＰＵ１３０は、通信回路１０４を制御し、ＥＥＰＲＯＭの送信フォルダ内に作成された電子メールを指示された相手先のメールサーバに送信することができるようにされる。
【００５７】
また、自機への電子メールが自己のメールサーバに蓄積されている場合には、自機宛の電子メールの受信を指示する操作をキー操作部１１４に対して行うと、これが押下検出部１１５によって検出されて制御ライン１０１を通じてＣＰＵ１３０に通知される。この場合、ＣＰＵ１３０は、通信回路１０４を制御し、自己のメールサーバにアクセスして、自機宛の電子メールをダウンロードしてきて、これをＥＥＰＲＯＭ１１１の受信フォルダに格納する。
【００５８】
このようにしてＥＥＰＲＯＭ１１１内の受信フォルダに格納された自機宛の電子メールは、ＣＰＵ１３０の制御により読み出されて、データライン１０２を通じて表示制御部１１２に供給され、当該表示制御部１１２を通じてＬＣＤ１１３に供給されて、その表示画面に表示することができるようにされている。これにより、相手先からの自機宛の電子メールを取得して、ＬＣＤ１１３に表示して、これを読むこともできるようにされる。
【００５９】
このように、この実施の形態の携帯電話端末は、単に電話通信を行うことができるだけでなく、インターネットへの接続機能をも備え、インターネットを通じて情報の取得や電子メールの送受信などをも行うことができるものである。すなわち、この実施の形態の携帯電話端末は、広域通信機能としては、電話通信の他、インターネットを通じてのデータ通信をも行うことができるものである。
【００６０】
さらに、この実施の形態の携帯電話端末は、上述もしたように、ＬＡＮモジュール１１８をも備えており、所定のＬＡＮに接続して、当該所定のＬＡＮに接続されている機器間においても、通信を行う機能をも供えたものである。また、カメラモジュールをも備え、被写体の画像を撮影して、これをデジタル画像データとして取り込み、ＥＥＰＲＯＭ１１１に格納して、必要に応じて読み出して表示制御部１１２を通じてＬＣＤ１１３に供給して、ＬＣＤ１１３の表示画面に表示するなどして利用することができるものである。
【００６１】
また、この実施の形態の携帯電話端末は、ＵＳＢＩ／Ｆ１２１をも備え、ＵＳＢＩ／Ｆを備えた種々の外部機器を接続することもできるものである。例えば、ＵＳＢメモリを接続して、ＥＥＰＲＯＭ１１１に格納されているデジタル画像データを当該ＵＳＢメモリにバックアップしたり、また、ＵＳＢＩ／Ｆ１２１を通じてパーソナルコンピュータに接続して、データをパーソナルコンピュータのハードディスクにバックアップしたり、パーソナルコンピュータから種々のデータの提供を受けたりすることができるようにされる。
【００６２】
また、時計回路１２２は、いわゆるカレンダ機能を備え、現在年月日、現在曜日、現在時刻を提供することができると共に、ＣＰＵ１３０の制御に応じて、処理時間を計測したりするなど、種々の時間間隔を計測するなどのことも出来るものである。
【００６３】
また、図１において、クロック信号発生部１４０は、この実施の形態の携帯電話端末の各部に供給するクロック信号を発生させて、目的とする部分に供給するものである。クロック信号発生部１４０は、クロック信号の供給先毎に異なる周波数のクロック信号を形成して供給することができるものである。
【００６４】
例えば、ＣＰＵ１３０を駆動させるためにＣＰＵ１３０で用いられるいわゆるＣＰＵクロック信号や、メモリへのアクセスのためのクロック信号、すなわち、ＣＰＵ１３０と各メモリとの間でデータをやり取りし、メモリに対してデータを記録したり、メモリからデータを読み出したりする場合に用いられるクロック信号であるいわゆるメモリバスクロック信号、その他、各部で用いられる種々のクロック信号をクロック信号発生部１４０は発生させることができるものである。
【００６５】
また、クロック信号発生部１４０は、ＣＰＵ１３０の制御に応じて、発生させるクロック信号毎にその周波数を変えることもできるものである。例えば、ＣＰＵクロック信号だけの周波数を変えたり、メモリバスクロック信号だけの周波数を変えたり、ＣＰＵクロック信号とメモリバスクロック信号との両方の周波数をそれぞれに変えたりするなどのことが可能である。
【００６６】
［データの取得・検索処理について］
そして、図１に示したこの実施の形態の携帯電話端末においては、データベースを前提としたシステム形態が適用されている。図２は、この実施の形態の携帯電話端末に適用されるデータベースシステムの構成例を説明するためのブロック図である。図２に示すように、この実施の形態の携帯電話端末に適用されたデータベースシステムの構成例は、ＵＩ（User Interface）層１０、ミドルウェア層２０、物理層３０からなっている。
【００６７】
ＵＩ層は、ユーザーによって直接に利用される各種のアプリケーションソフトウェア１１からなる部分である。物理層３０は、ＯＳ（Operating System）や各種ハードウェア資源からなるいわゆるプラットフォーム部分である。この例のデータベースシステムの物理層３０は、図２に示すように、メールデータベース（図２ではメールＤＢと記載。）３１ａ、画像データベース（図２では画像ＤＢと記載。）３１ｂ、音楽データベース（図２では音楽ＤＢと記載。）３１ｃなどの各種のデータベースと、ＣＰＵ（Central Processing Unit）１３０やＲＯＭ１０９、ＲＡＭ１１０、ＥＥＰＲＯＭ１１１といった種々のメモリなどを備えると共に、図示しないが、これらを利用するためのソフトウェアであるＯＳをも備えるものである。
【００６８】
なお、物理層３０に設けられるようにされる種々のデータベース（ＤＢ）には、この実施の形態の携帯電話端末に内蔵されたＲＯＭ１０９、ＲＡＭ１１０やＥＥＰＲＯＭ１１１、あるいは、ＵＳＢＩ／Ｆ１２１に接続されるフラッシュメモリーに形成されるものや、通信回路１０４及び送受信アンテナ１０３を通じて接続可能とされるネットワーク上のサーバー装置に設けられたデータベースや、ＬＡＮモジュール１１８及びＬＡＮ用送受信アンテナ１１９を通じて接続されるＬＡＮに接続された記憶装置などに設けられたデータベースをも含まれる。したがって、物理層３０は、通信機能を実現するハードウェア部分をも含んでいる。
【００６９】
そして、ミドルウェア層２０は、図に示すように、ＵＩ層と物理層との間に位置するソフトウェアの総称であり、ユーザーアプリケーションとプラットフォームとを結びつける機能を有する部分である。この例のデータベースシステムのミドルウェア層２０は、図２に示すように、メールデータ収集ソフトウェア（図２ではメールデータ収集と記載。）２１ａ、画像データ収集ソフトウェア（図２では画像データ収集と記載。）２１ｂ、音楽データ収集ソフトウェア（図２では音楽データ収集と記載。）２１ｃなどの種々のデータ収集ソフトウェアや、検索条件判断システム（図２では検索条件判断と記載。）２２、ＤＢＭＳ（Database Management System）２３、クロック制御システム（図２ではクロック制御と記載。）２４等を備えたものである。
【００７０】
メールデータ収集ソフトウェア２１ａ、画像データ収集ソフトウェア２１ｂ、音楽データ収集ソフトウェア２１ｃなどの種々のデータ収集ソフトウェアは、ＵＩ層のアプリケーションソフトウェアからの指示に応じてデータを収集する機能を担うものである。また、検索条件判断システム２２は、各種のデータ収集ソフトウェアからの検索条件を解析し、当該検索条件に基づいて、ＤＢＭＳと協働することにより、目的とするデータベースから目的とするデータを収集するようにする部分である。また、ＤＢＭＳ２３は、データベースを維持し、運用するための種々のソフトウェアからなるものである。
【００７１】
そして、クロック制御システム２４は、図２に示すように、検索条件判断システム２２に接続され、詳しくは後述するが、検索条件判断システム２２と協働することにより、この実施の形態の携帯電話端末において行われるデータの取得・検索処理時において、処理の高速化を阻むボトルネック部分のみにおいて、用いられるクロック信号の周波数を上げることによって（クロックアップすることによって）、データの取得・検索処理の高速化を実現するようにしている。
【００７２】
すなわち、図１に示した構成を有し、図２に示したデータベースシステムが適用されたこの実施の形態の携帯電話端末においては、ＣＰＵ１３０が機能し、自機に搭載されたＲＯＭ１０９、ＲＡＭ１１０、ＥＥＰＲＯＭ１１１に形成されているデータベース、通信回路１０４を通じてアクセスするネットワーク上のデータベース、ＬＡＮモジュール１１８を通じてアクセスする所定のＬＡＮに接続された外部機器に形成されているデータベース、あるいは、ＵＳＢＩ／Ｆ１２１に接続されたＵＳＢメモリモジュール（フラッシュメモリドライブ）に形成されたデータベースから、目的とするデータを取得したり所定の条件に合致するデータだけを検索して取得したりすることができるものである。
【００７３】
このように、目的とするデータベースからすべてのデータを取得する処理や目的とするデータベースから条件に合致したデータだけを検索して取得する処理を、この明細書においては、データの取得・検索処理という。なお、この実施の形態においては、データベースという文言は、技術的にデータベースとして整えられたものの他、例えば、メールホルダなどの所定のデータが蓄積されるファイルやフォルダなどを含むものである。
【００７４】
そして、データの取得・検索処理においては、できるだけ携帯電話端末のユーザーの待ち時間を少なくすることが望ましい。このため、データの取得・検索処理の実行時において、用いられるクロック信号の周波数をアップさせるようにして、処理の高速化を図ることが考えられる。
【００７５】
しかしながら、データの取得・検索処理は、検索条件に応じて、取得されるデータの量も異なるし、取得・検索処理にかかる時間も異なってくる。このため、データの取得・検索処理の実行時において、常にクロック信号の周波数をアップさせるようにしても、取得されるデータの量が少なく、さほど処理時間のかからないような場合にまでクロック信号の周波数がアップするようしてしまったのでは、無駄に消費電力を増大させてしまうことにもなりかねない。
【００７６】
そこで、この実施の形態の携帯電話端末においては、データの取得・検索処理を行う場合において、実際に処理に時間がかかるボトルネック部分を特定し、この特定したボトルネック部分においてのみ、クロック信号の周波数を高くし、ボトルネック部分における処理を高速化して、データの取得・検索処理全体の処理の高速化を図るようにしている。
【００７７】
また、この場合、ボトルネック部分以外の部分では、通常通りの周波数のクロック信号を用いるようにするので、ボトルネック部分以外の部分において、クロック信号の周波数が必要以上に高くなることはなく、無駄に消費電力を増やすことも無いようにしている。
【００７８】
このため、この実施の形態の携帯電話端末においては、データの取得・検索処理を行う場合において、データの取得・検索処理に用いる検索条件と、過去の取得・検索処理についての結果情報（管理情報）とに基づいて、データの取得・検索処理におけるボトルネック部分を適切に特定し、この特定したボトルネック部分においてのみ、目的とするクロック信号の周波数を制御するクロック制御を適切に行うことができるようにしている。
【００７９】
以下に、クロック信号の適切な制御をも行うことができるようにした、この実施の形態の携帯電話端末においてのデータの取得・検索処理について具体的に説明する。図２を用いて説明したデータベースシステムにおいて、検索条件は、ＳＱＬ（Structured Query Language）を用いて記述される。ＳＱＬ文を用いて記述された検索条件からは、（Ａ）演算が必要な処理か／必要ない処理か、（Ｂ）検索結果が１つか／複数かの２つを予測することができる。（Ａ）については、ソートの有無やマッチング条件の有無等により判断することが可能である。また、（Ｂ）については、主キーとの完全一致条件の有無によって判断可能である。
【００８０】
そして、このことから、ＳＱＬ文で記述された検索条件については、以下のように分類することができる。すなわち、ＳＱＬ文で記述された検索条件は、  
（１）演算が必要で、検索結果が１つであるもの  
（２）演算が必要で、検索結果が複数であるもの  
（３）演算が不要で、検索結果が１つであるもの  
（４）演算が不要で、検索結果が複数であるもの  
の４つに分類することができる。
【００８１】
この場合において、（１）と（３）の場合、すなわち、検索結果が１つである場合には、取得されるデータは１つであるので、殆どの場合、取得・検索処理自体は高速であり、クロックアップの必要は無い。しかし、（２）と（４）の場合には、ＳＱＬ文の検索条件だけでは、処理に時間がかかるか否かを判断することは困難である。
【００８２】
そこで、検索条件が上記の（２）、（４）の場合については、過去の取得・検索処理についての結果情報をも考慮して、クロックアップが必要な処理か（時間のかかる処理か）を判断することができるようにしている。ここで、過去の取得・検索処理についての結果情報は、以下に説明するように、過去の取得・検索処理において用いた検索条件と、当該過去の取得・検索処理における検索結果件数と当該過去の取得・検索処理にかかった時間を示す取得時間とを関連付けたものである。
【００８３】
図３は、この実施の形態の携帯電話端末において用いられる過去の取得・検索処理についての結果情報である検索条件−取得時間テーブルの一例を説明するための図である。この例の検索条件−取得時間テーブルは、この実施の形態の携帯電話端末の例えばＲＡＭ１１０に形成され、データの取得・検索処理が行われる毎に、新たなデータが付加するようにされる。
【００８４】
そして図３に示すように、この例の検索条件−取得時間テーブルは、用いられた検索条件（ＳＱＬ文）と、当該検索条件に応じて取得・検索処理を行ったときに取得したデータの数である検索結果件数と、当該検索条件に応じて取得・検索処理を行ったときの処理にかかった時間（目的とするデータの取得にかかった時間）を示す取得時間が関連付けられて管理データ（テーブル情報）として記憶保持するようにされたものである。
【００８５】
ここで、検索条件は、ＳＱＬ文によって記述されたものであり、検索結果件数は、当該検索条件にしたがって携帯電話端末の所定のメモリに取得されたデータの件数である。また、取得時間は、検索条件に従ったデータの取得・検索処理を実行する場合に、当該処理と並行してこの実施の形態の携帯電話端末の時計回路１２２の機能を用いて計測するデータの取得・検索処理の開始から終了までの時間である。
【００８６】
具体的に、図３に示した検索条件−取得時間テーブルの場合、１行目の管理データは、検索条件が、フォルダＡ（ＦｏｌｄｅｒＡ）から全てのデータを取得することを指示するものであり、当該検索条件に従った処理により、１０００件のデータが取得され、このときの取得時間（処理時間）が５００［ｍｓ］であることを示している。
【００８７】
また、２行目の管理データは、検索条件が、フォルダＡ（ＦｏｌｄｅｒＡ）から全てのデータを取得し、取得したデータを列名ディスプオーダー（ＤｉｓｐＯｒｄｅｒ）順に並べ替えることを指示するものであり、当該検索条件に従った処理により、１０００件のデータが取得され、このときの処理時間が８００［ｍｓ］であることを示している。
【００８８】
また、３行目の管理データは、検索条件が、送信メール（ＳｅｎｄＭａｉｌ）からフォルダＩＤ（Ｆｏｌｄｅｒ  ＩＤ）が「０（ゼロ）」のデータを全て取得し、取得したデータをＵＴＣ（Coordinated Universal Time）順、ローＩＤ（Ｒｏｗ  ＩＤ）順に並べ替えることを指示するものであり、当該検索条件に従った処理により、１００件のデータが取得され、このときの処理時間が３００［ｍｓ］であることを示している。
【００８９】
また、４行目の管理データは、検索条件が、送信メールからローＩＤ（Ｒｏｗ  ＩＤ）が「２」であるデータを取得することを指示するものであり、当該検索条件に従った処理により、１件のデータが取得され、このときの処理時間が１０［ｍｓ］であることを示している。
【００９０】
このように、取得・検索処理が行われるごとに、検索条件と、検索結果件数と、取得時間とからなる管理データ（テーブル情報）が、この実施の形態の携帯電話端末のＲＡＭ１１０に、図３に一例を示したように形成される検索条件−取得時間テーブルに記録される。そして、当該検索条件−取得時間テーブルの結果情報により、どのような検索条件にしたがってデータの取得・検索処理を行った場合に、いくつのデータが取得でき、その時の取得時間（処理時間）は何ミリ秒［ｍｓ］かを把握することができるようにしている。
【００９１】
そして、データの取得・検索処理において、用いる検索条件が、上述した（２）演算が必要で、検索結果が複数である場合と、（４）演算が不要で、検索結果が複数である場合とにおいては、当該検索条件に基づいて、図３に示したように構成される検索条件−取得時間管理テーブルを参照し、クロックアップが必要か否かを判断する。
【００９２】
なお、今回用いる検索条件に基づいて、検索条件−取得時間管理テーブルを参照するのであるが、基本的に検索条件が完全に一致するデータを参照するようにし、検索条件が完全に一致するデータが存在しない場合には、今回用いる検索条件と、データを取りに行く場所（テーブル名）が同じで、データの取得条件レベル（取得対象は全データか一部データか）が同じで、並べ替えなどの処理レベルが同じであるデータを参照するようにする。
【００９３】
例えば、今回用いる検索条件が、「Ｓｅｌｅｃｔ  ＊  ｆｒｏｍ  ＳｅｎｄＭａｉｌ  ｗｈｅｒｅ  Ｆｏｌｄｅｒ  ＩＤ＝０  ｏｒｄｅｒ  ｂｙ  Ａ  ｄｅｓｃ．Ｂ  ｄｅｓｃ」であったとすると、図３に示した検索条件−取得時間管理テーブルには、完全に一致する検索条件を有するデータは存在しない。しかし、図３に示した検索条件−取得時間管理テーブルの３行目には、データを取りに行く場所が「ＳｅｎｄＭａｉｌ」で、データの取得条件レベルが「一部データ（Ｆｏｌｄｅｒ  ＩＤ＝０）」で、並べ替えなどの処理レベルが同じであるデータが同じであるデータが存在するので、この３行目のデータを参照するようにする。
【００９４】
このように、データを取りに行く場所、データの取得条件レベル、並べ替えなどの処理レベルが同じであれば、データの抽出条件や、並べ替えのためのキー情報（いわゆるソートキー）が異なっていても、同等の処理内容になることが予想できるので、検索条件−取得時間管理テーブルの当該データを参照する。
【００９５】
なお、データの抽出条件が複数のデータを取得するものと、ただ１つのデータを取得するものとでは、取得条件レベルが異なるので、参照するデータの対象となることは無い。しかし、ソートキーの数が異なるくらいであれば参照するようにしてもよい。例えば、データを取りに行く場所、データの取得条件レベルは同じであるが、用いるソートキーの数が異なる場合、用いるソートキーの数の差が２以内であれば、参照データとして用いるようにするなどのことができる。
【００９６】
そして、検索条件が上記の（２）、（４）の場合については、今回用いる検索条件に基づいて、既にＲＡＭ１１０に形成されている検索条件−検索時間管理テーブルを参照する。ここで、該当する管理データが検索条件−検索時間管理テーブルに存在しない場合には、クロックアップは行うことなく、通常のクロック信号を用いて、データの取得・検索処理を行う。検索条件−検索時間管理テーブル内に該当する管理データが存在する場合には、その管理データに基づいて、クロック制御の内容を定める。
【００９７】
すなわち、  
（ａ）参照した管理データの検索結果件数が小件数であれば、クロックアップは行わない。  
（ｂ）上記（２）の検索条件（演算が必要で、検索結果が複数）を用いる場合であって、参照した管理データの検索結果件数が少なく、取得時間が長い場合には、ＣＰＵクロックアップを行う。  
（ｃ）上記（２）の検索条件（演算が必要で、検索結果が複数）を用いる場合であって、参照した管理データの検索結果件数が多く、取得時間が多い場合には、ＣＰＵクロックアップとメモリバスクロックアップとの両方を行う。  
（ｄ）上記（４）の検索条件（演算が不要で、検索結果が複数）を用いる場合であって、参照した管理データの検索結果件数が少なく、取得時間が多い場合には、クロックアップは行わない。  
（ｅ）上記（４）の検索条件（演算が不要で、検索結果が複数）を用いる場合であって、参照した管理データの検索結果件数が多く、取得時間も多い場合には、メモリバスクロックアップを行う。
【００９８】
上記（ａ）の場合にクロック信号の周波数のアップ制御（クロックアップ）を行わないのは、検索条件が複数のデータを取得する条件となっていても、過去の同様の処理において取得されたデータが少ないために、データの取得・検索処理自体に大きな負荷はかからず、通常の周波数のクロック信号によって迅速に処理可能であると判断できるためである。
【００９９】
また、上記（ｂ）の場合にＣＰＵクロック信号の周波数のアップ制御（ＣＰＵクロックアップ）を行うのは、検索条件が演算を含んでおり、過去の同様の処理において、取得されたデータが少ないにも関わらず、取得時間が長いというのは、データの取得・検索処理自体（演算処理自体）に時間がかかっており、ＣＰＵにおける処理の高速化を行う必要があると判断できるためである。
【０１００】
また、上記（ｃ）の場合にＣＰＵクロックアップとメモリバスクロック信号の周波数のアップ制御（メモリバスクロックアップ）との両方を行うのは、検索条件に演算を含んでおり、過去の同様の処理において、取得されたデータも多く、また、取得時間も多いということは、データの取得・検索処理（演算処理）と、当該処理により取得したデータのメモリへの書き込み処理との両方に時間がかかり、ＣＰＵにおける処理と、取得データのメモリへの書き込み処理との両方の高速化を行う必要があると判断できるからである。
【０１０１】
また、上記（ｄ）の場合にＣＰＵクロック信号やメモリバスクロック信号の周波数のアップ制御（クロックアップ）を行わないのは、検索条件に演算を含まず、また、過去の同様の処理において、取得されたデータが少ないにも関わらず、取得時間が多いという状況は、ＣＰＵの処理や取得データのメモリへの書き込み処理といった当該携帯電話端末における処理に起因するものではないと判断することができるからである。例えば、データを取りに行く場所であるデータベースが外部ネットワーク上など、当該携帯電話端末内に存在しない場合であって、ネットワーク処理待ち等で時間がかかっている場合などがあると想定でき、このような場合には、どのクロック信号の周波数をアップさせても、データの取得・検索処理の高速化には寄与することができないと判断することができるからである。
【０１０２】
また、上記（ｅ）の場合に、メモリバスクロックアップを行うのは、検索条件に演算を含まないにも関わらず、過去の同様の処理においては、取得されたデータも多く、また、取得時間も多いという状況は、取得したデータのメモリへの書き込み処理に時間がかかっており、取得データのメモリへの書き込み処理の高速化を行う必要があると判断できるからである。
【０１０３】
［データの取得・検索処理時のクロック制御処理について］
次に、この実施の形態の携帯電話端末において、データの取得・検索処理時に行われるクロック処理の概要について説明する。図４は、この実施の形態の携帯電話端末において行われるクロック制御処理の概要について説明するためのブロック図である。この実施の形態の携帯電話端末においては、単に検索条件（処理内容）に基づいて、データの取得・検索処理が負荷の重いくボトルネックとなるか否かを判断するのではない。過去に行われたデータの取得・検索処理についての検索条件−取得時間管理テーブルの管理データ（テーブル情報）をもフィードバックさせることにより、今回用いる検索条件にしたがって行うデータの取得・検索処理が負荷の重い、ボトルネックとなる処理か否かを判断するようにしているのである。
【０１０４】
すなわち、データの取得・検索処理を行う場合には、当該処理に先立って、ＵＩ層１０のアプリケーションソフトウェア１１を通じて受け付けて、ミドルウェア層２０の対応するデータ収集ソフトウェア２１を通じて供給される検索条件に基づいて、ミドルウェア層２０の検索条件判断システム２２が、検索条件判断処理Ｓ１を行って、クロック制御が必要か否かを判断する。
【０１０５】
検索条件判断処理Ｓ１においての判断結果と、図３に示した検索条件−取得時間管理テーブルの管理データをも考慮して、ミドルウェア層２０のクロック制御システム２４が、クロック制御判断処理Ｓ２を行う。ここでは、上述もしたように、検索条件から検索結果が複数であり、当該検索条件に基づいて参照する検索条件−取得時間管理テーブルの対応するデータが、上述した（ｂ）、（ｃ）、（ｅ）である場合に、クロック制御を行うようにする。
【０１０６】
この後、ミドルウェア層２０のＤＢＭＳ２３が機能してデータの取得・検索処理Ｓ３を実行する。この場合、この実施の形態の携帯電話端末においては、ＣＰＵ１３０が時計回路１２２を制御し、当該取得・検索処理にかかることになる取得時間を計測する取得時間計測処理Ｓ４を実行する。そして、この取得計測処理Ｓ４においては、用いられた検索条件と、取得・検索処理を通じて取得できたデータの件数である検索結果件数と、計測した取得時間とを関連付けた管理データ（テーブル情報）形成して、これを検索条件−取得時間管理テーブルに記録する。これにより、取得・検索処理が実行されるごとに、取得・検索処理に関する情報（取得・検索処理を行うことにより得られる結果情報）がフィードバックするようにされる。
【０１０７】
このように、この実施の形態の携帯電話端末において、データの取得・検索処理時には、データの取得・検索処理についての結果情報（検索条件、検索結果件数、取得時間）をフィードバックするようにして、適切にボトルネックとなる処理を特定し、この特定したボトルネックとなるデータの取得・検索処理時においてのみクロック制御を適切に行うことができるようにしている。これにより、データの取得・検索処理において、真に必要な場合にだけクロックアップを行うことにより、データの取得・検索処理の迅速化を実現すると共に、無駄に消費電力を増やすことも無いようにしている。
【０１０８】
すなわち、この実施の形態の携帯電話端末においては、ＣＰＵ１３０がデータの取得・検索処理を行うが、当該データの取得・検索処理により得られた目的とするデータは、例えば、ＲＡＭ１１０に一時記憶して利用することができるようにされる。また、ＣＰＵ１３０がデータの取得・検索処理を行った場合には、ＣＰＵ１３０は、取得したデータの件数（検索結果件数）を把握することができるし、また、時計回路１２２を制御して、データの取得・検索処理にかかった処理時間である取得時間を計測して把握することができるようにしている。
【０１０９】
このようにして、データの取得・検索処理を行うことによってＣＰＵ１３０が取得した検索結果件数や取得時間である結果情報は、図３を用いて説明したように、例えばＲＡＭ１１０に検索条件と関連付けられて記憶保持され、検索条件をキー情報として参照することができるようにされている。
【０１１０】
そして、ＣＰＵ１３０は、データの取得・検索処理を行うごとに、用いる検索条件と、当該検索条件に基づいて参照する結果情報とを考慮し、今回の検索条件にしたがって行うデータの取得・検索処理は、時間のかかるボトルネックとなる処理か否かを適切に判断し、必要がある場合には、クロック信号発生部１４０を制御して、ＣＰＵ１３０が用いるＣＰＵクロック信号と、メモリへのアクセスに用いるメモリバスクロック信号との一方または両方のクロックアップを行うことができるようにしている。
【０１１１】
したがって、この実施の形態の携帯電話端末においては、ＣＰＵ１３０が、処理手段としての機能を実現し、ＲＡＭ１１０がメモリ手段、データメモリとしての機能を実現し、ＣＰＵ１３０と時計回路１２２とが取得手段としての機能を実現し、ＲＡＭ１１０が、テーブル記憶手段、テーブルメモリとしての機能を実現し、クロック信号発生部１４０が、処理クロック信号形成手段、メモリクロック信号形成手段としての機能を実現し、ＣＰＵ１３０がクロック信号制御手段としての機能を実現するようにしている。
【０１１２】
［携帯電話端末におけるデータの取得・検索処理時のクロック制御処理の具体例］
次に、この実施の形態の携帯電話端末において実行されるデータの取得・検索処理時のクロック制御処理の詳細について、図５〜図８のフローチャートを参照しながら説明する。図５〜図７は、この実施の形態の携帯電話端末において実行されるデータの取得・検索処理時のクロック制御処理の詳細を説明するためのフローチャートであり、図８は、図５〜図７に示したステップＳ１０８、ステップＳ１２４、ステップＳ１２７、ステップＳ１３０、ステップＳ１３３、ステップＳ１４３、ステップＳ１４６、ステップＳ１４９で実行されるデータ取得・検索処理を説明するためのフローチャートである。
【０１１３】
この実施の形態の携帯電話端末においては、電源が投入されている間においては、ＣＰＵ１３０によりいわゆるメインルーチンの処理が起動され、キー操作部１１４を通じてのユーザーからの指示入力待ちとなっており、ユーザーからの指示入力を受け付けると、当該メインルーチンの中で、図５〜図７に示すクロック制御処理が呼び出されて実行される。
【０１１４】
そして、ＣＰＵ１３０は、キー操作部１１４を通じて受け付けた指示入力に応じて実行する処理が、データの取得・検索処理か否かを判断する（ステップＳ１０１）。このステップＳ１０１の判断処理は、キー操作部１１４を通じて受け付けた指示入力の内容に基づいて判断することができる。
【０１１５】
ステップＳ１０１の判断処理において、実行する処理がデータの取得・検索処理ではないと判断したときには、この図５〜図７に示す一連の処理を抜け、メインルーチンに戻って指示入力に応じた他の処理を実行することになる。ステップＳ１０１の判断処理において、実行する処理がデータの取得・検索処理であると判断したときには、ＣＰＵ１３０は、指示入力に応じて検索条件を生成する（ステップＳ１０２）。
【０１１６】
なお、ステップＳ１０２の処理においては、指示入力に応じて、データを取りに行く場所（テーブル名）、データの取得条件（全部か所定の一部か）、並べ替えは必要かなどの条件が特定できるので、これらに基づいて実行するデータの取得・検索処理のための検索条件をＳＱＬ文として生成するようにされる。
【０１１７】
そして、ＣＰＵ１３０は、ステップＳ１０２において生成された検索条件から、取得・検索処理の結果得られるデータの数である検索結果件数が複数になるか否かを判断する（ステップＳ１０３）。このステップＳ１０３においては、ＳＱＬで記述された検索条件のデータの取得条件に基づいて、検索結果件数が単数か複数かを判断することができる。
【０１１８】
ステップＳ１０３の判断処理において、検索結果件数が複数でない（検索結果件数が単数である）と判断したときには、当該検索条件にしたがって行うデータの取得・検索処理には大きな負荷がかかることは無く、迅速に処理可能であるので、ＣＰＵ１３０は、ステップＳ１０８の処理に進み、クロックアップすることなく（ステップＳ１０８）、データの取得・検索処理を実行して（ステップＳ１０９）、図５〜図７に示す一連の処理を終了する。
【０１１９】
なお、図５〜図７のフローチャートにおいて、例えばステップＳ１０８などの点線で示した「クロックアップせず」とのブロックは、クロックアップしないのであるから、本来何の処理も行わないものであるが、クロックアップする場合の処理順序との違いを明確にするために記載するようにしているものである。
【０１２０】
ステップＳ１０３の判断処理において、検索結果件数が複数であると判断したときには、ＣＰＵ１３０は、ステップＳ１０２において生成された検索条件に基づいて、後述もするように、この実施の形態の携帯電話端末のＲＡＭ１１０に形成される検索条件−取得時間管理テーブルを参照し、該当する管理データを取得するようにする（ステップＳ１０４）。
【０１２１】
このステップＳ１０４においては、上述もしたように、今回用いる検索条件に基づいて、基本的に検索条件が完全に一致するデータを参照するようにし、検索条件が完全に一致するデータが存在しない場合には、今回用いる検索条件と、データを取りに行く場所（テーブル名）が同じで、データの取得条件レベル（取得対象は全データか一部データか）が同じで、並べ替えなどの処理レベルが同じであるデータを参照する。
【０１２２】
そして、ＣＰＵ１３０は、ステップＳ１０４において該当する管理データが取得できたか否かを判断する（ステップＳ１０５）。ステップＳ１０５の判断処理において、該当する管理データが無かったと判断したときには、当該検索条件にしたがって行うデータの取得・検索処理の負荷の大きさを判断するための情報は存在しないので、ＣＰＵ１３０は、ステップＳ１０８の処理に進み、クロックアップすることなく（ステップＳ１０８）、データの取得・検索処理を実行して（ステップＳ１０９）、図５〜図７に示す一連の処理を終了する。
【０１２３】
ステップＳ１０５の判断処理において、該当する管理データが取得できたと判断したときには、この取得した管理データの検索結果件数を検索結果件数Ａとして取得し（ステップＳ１０６）、当該検索結果件数Ａが予め決められた規定値Ｎより小さいか否かを判断する（ステップＳ１０７）。ここで規定値Ｎは、通常の周波数のクロック信号を用いたＣＰＵ１３０における処理やメモリへの記録処理において、処理時間が問題にならないほどの件数、例えば、数十件程度の件数である。なお、規定値Ｎは、携帯電話端末のリソースなどを考慮し、適宜の値とするようにすればよい。
【０１２４】
ステップＳ１０７の判断処理において、検索結果件数Ａが予め決められた規定値Ｎより小さいと判断したときには、通常の周波数のクロック信号を用いたＣＰＵ１３０における処理やメモリへの記録処理に時間がかかることは無いと判断できるので、ＣＰＵ１３０は、クロックアップすることなく（ステップＳ１０８）、データの取得・検索処理を実行して（ステップＳ１０９）、図５〜図７に示す一連の処理を終了する。
【０１２５】
ステップＳ１０７の判断処理において、検索結果件数Ａが予め決められた規定値Ｎより小さくない（検索結果件数Ａが予め決められた規定値Ｎ以上である）と判断したときには、ＣＰＵ１３０は、ステップＳ１０２において生成した検索条件が演算処理を伴いものか否かを判断する（ステップＳ１１０）。このステップＳ１１０においては、検索条件に、データの並べ替え（ソート）やデータの付け合せ（マッチング）等の指示が存在する場合には演算処理を伴うものであると判断でき、データの並べ替え（ソート）やデータの付け合せ（マッチング）等の指示が無い場合には、演算処理を伴わないものであると判断できる。
【０１２６】
そして、ステップＳ１１０の判断処理において、検索条件が演算処理を伴うものであると判断したときには、図６に示す検索結果が複数で演算が必要な場合の処理を実行し、ステップＳ１１０の判断処理において、検索条件が演算処理を伴わないものであると判断したときには、図７に示す検索結果が複数で演算が不要な場合の処理を実行することなる。
【０１２７】
まず、ステップＳ１１０の判断処理において、検索条件が演算処理を伴うものであると判断した場合の処理について説明する。この場合には、図６に示すステップＳ１２１の処理に進み、ＣＰＵ１３０は、ステップＳ１０４において参照した検索条件−取得時間管理テーブルの該当管理データの検索結果件数（ステップＳ１０６において取得した検索結果件数Ａ）が、少ないか否かを判断する（ステップＳ１２１）。換言すれば、ステップＳ１２１の判断処理は、今回用いる検索条件と同一か同程度の検索条件を用いた過去のデータの取得・検索処理により取得できたデータの件数（検索結果件数Ａ）が少ないか否かを判断するものである。
【０１２８】
そして、ステップＳ１２１の判断処理においては、平均的なデータの取得・検索処理（通常のデータの取得・検索処理）を行う場合において、通常の周波数のクロック信号を用いたＣＰＵ１３０における処理やメモリへの記録処理に、ある程度の時間（例えば、ユーザーがデータの取得・検索処理においての処理時間に対して感じ取る時間的な感覚に明らかに影響を及ぼし始める程度の時間）がかかるようになるデータ件数であり、例えば、検索結果件数Ａが１００件未満であれば結果件数は少なく（「少」であり）、１００以上であれば結果件数は多い（「多」である）と判断することができる。
【０１２９】
なお、ここでは、検索結果件数Ａが少ないか否かを判断するための基準値の一例として「１００件」という値を用いるようにしたが、これに限るものではない。ＣＰＵ１３０の性能やメモリへのアクセス性能などに応じて適宜の値を用いるようにする。すなわち、ＣＰＵ１３０の性能やメモリへのアクセス性能が良いものである場合には、検索結果件数Ａが少ないか否かを判断するための基準値としては、２００件、３００件、…というように、より大きな値を用いるようにし、逆に、ＣＰＵ１３０の性能やメモリへのアクセス性能が悪いものである場合には、８０件、６０件、…というように、より小さな値を用いるようにする。
【０１３０】
ステップＳ１２１の判断処理において、通常のデータの取得・検索処理の場合にはＣＰＵ１３０においての処理時間に影響を及ぼすほどのデータ件数ではない、すなわち、検索結果件数は少ないと判断した場合には、ＣＰＵ１３０は、図５に示したステップＳ１０４で参照した取得件数−取得時間管理テーブルの該当する管理データの取得時間が多いか（長いか）否かを判断する（ステップＳ１２２）。換言すれば、ステップＳ１２２の判断処理は、今回用いる検索条件と同じか同程度の検索条件を用いた過去のデータの取得・検索処理にかかった処理時間（取得時間）が多いか（長いか）か否かを判断するものである。
【０１３１】
このステップＳ１２２の判断処理においては、該当する管理データの取得時間が、ユーザーがデータの取得・検索処理においての処理時間に対して感じ取る時間的な感覚に明らかに影響を及ぼし始める程度の時間、例えば、１００ミリ秒[ｍｓ]以上である場合には、多い（長い）と判断することができ、１００ｍｓ未満の時間であれば、少ない（短い）と判断することができる。
【０１３２】
もちろん、この場合に用いる時間も、１００ｍｓに限るものではなく、種々の条件、例えば、クロック制御を行う頻度等を考慮して、２００ｍｓ、３００ｍｓ、…というようにより大きな値を用いるようにすることも可能であるし、８０ｍｓ、６０ｍｓ、…というように、より小さな値を用いるようにすることも可能である。
【０１３３】
ステップＳ１２２の判断処理において、該当する管理データの取得時間が多いと判断したときには、ＣＰＵ１３０は、クロック信号発生部１４０を制御して、ＣＰＵ１３０で用いられ、ＣＰＵ１３０における処理速度を決定するＣＰＵクロック信号の周波数を所定の周波数にまでアップさせる（ステップＳ１２３）。
【０１３４】
このステップＳ１２３においては、ＣＰＵ１３０で用いられる通常のクロック周波数が、例えば、数百メガヘルツ［ＭＨｚ］であった場合には、さらに１００ＭＨｚアップさせるというようにする。もちろん、これは一例であり、ＣＰＵ１３０の性能に応じて、数百ＭＨｚ以上にアップさせるようにすることもできる。
【０１３５】
そして、ステップＳ１２３においてＣＰＵクロックアップした後に、ＣＰＵ１３０は、詳しくは図８を用いて後述するデータの取得・検索処理を実行する（ステップＳ１２４）。このステップＳ１２４の処理が終了すると、ＣＰＵ１３０は、クロック信号発生部１４０を制御して、ＣＰＵ１３０で用いるクロック信号の周波数を元の周波数に復旧し（ステップＳ１２５）、この図５〜図７に示す一連の処理を終了する。
【０１３６】
また、ステップＳ１２２の判断処理において、該当する管理データの取得時間は多くない（少ない）と判断したときには、すなわち、過去に行った同等の取得・検索処理において、検索結果件数も、取得時間も多くない場合には、今回行おうとしているデータの取得・検索処理に時間のかかる可能性は低いので、ＣＰＵ１３０は、クロック信号の周波数をアップさせることなく（ステップＳ１２６）、データの取得・検索処理を実行して（ステップＳステップＳ１２７）、この図５〜図７に示す一連の処理を終了する。
【０１３７】
また、ステップＳ１２１の判断処理において、検索結果件数は少ないと判断した場合にも、ＣＰＵ１３０は、ステップＳ１２２の判断処理と同様に、図５に示したステップＳ１０４で参照した取得件数−取得時間管理テーブルの該当する管理データの取得時間が多いか（長いか）否かを判断する（ステップＳ１２８）。
【０１３８】
ステップＳ１２８の判断処理において、該当する管理データの取得時間が多いと判断したときには、ＣＰＵ１３０は、クロック信号発生部１４０を制御して、ＣＰＵ１３０で用いられ、ＣＰＵ１３０における処理速度を決定するＣＰＵクロック信号の周波数と、メモリへの取得データの書き込み等に用いられるメモリバスクロック信号の周波数とを所定の周波数にまでアップさせる（ステップＳ１２９）。
【０１３９】
このステップＳ１２９においても、ステップＳ１２３においての処理と同様に、通常用いられているＣＰＵクロック信号やメモリバスクロック信号の周波数が、例えば、数百メガヘルツ（ＭＨｚ）であった場合には、さらに１００ＭＨｚアップさせるというようにする。もちろん、これは一例であり、ＣＰＵ１３０やメモリなどの性能に応じて、さらに高い周波数、例えば数百ＭＨｚ以上にアップさせるようにすることもできる。
【０１４０】
そして、ステップＳ１２９においてＣＰＵクロックとメモリバスクロックの周波数をアップさせた後に、ＣＰＵ１３０は、詳しくは図８を用いて後述するデータの取得・検索処理を実行する（ステップＳ１３０）。このステップＳ１３０の処理が終了すると、ＣＰＵ１３０は、クロック信号発生部１４０を制御して、ＣＰＵクロックとメモリバスクロックとの周波数を元の周波数に復旧し（ステップＳ１３１）、この図５〜図７に示す一連の処理を終了する。
【０１４１】
また、ステップＳ１２８の判断処理において、該当する管理データの取得時間は多くない（少ない）と判断したときには、過去に行った同等の取得・検索処理において、検索結果件数も少なく、取得時間も多くないので、今回行おうとしているデータの取得・検索処理に時間のかかる可能性は低いので、ＣＰＵ１３０は、クロック信号の周波数をアップさせることなく（ステップＳ１３２）、データの取得・検索処理を実行して（ステップＳステップＳ１３３）、この図５〜図７に示す一連の処理を終了する。
【０１４２】
このように、図６に示した処理は、今回用いる検索条件に演算処理を含み、過去に行った同等の取得・検索処理（今回用いる検索条件と完全に一致する検索条件を用いた、あるいは、同等の処理内容となる検索条件を用いた取得・検索処理）において、検索結果件数が少なく、かつ、取得時間が多い場合（上述した（ｂ）の場合)にはＣＰＵ１３０に処理負荷のかかるボトルネックとなる処理と判断してＣＰＵクロックアップを行い、また、検索結果件数が多く、かつ、取得時間も多い場合（上述した（ｃ）の場合）には、ＣＰＵ１３０における処理とメモリへのデータの書き込み処理とに負荷のかかるボトルネックとなる処理と判断してＣＰＵクロックアップとメモリバスクロックアップとの両方を行うようにしている。
【０１４３】
次に、ステップＳ１１０の判断処理において、検索条件が演算処理を伴わないものであると判断した場合の処理について説明する。この場合には、図７に示すステップＳ１４１の処理に進み、ＣＰＵ１３０は、ステップＳ１０４において参照した検索条件−取得時間管理テーブルの該当管理データの検索結果件数（ステップＳ１０６において取得した検索結果件数Ａ）が、少ないか否かを判断する（ステップＳ１４１）。
【０１４４】
このステップＳ１４１の判断処理は、図６に示したステップＳ１２１の判断処理の場合と同様に、今回用いる検索条件と同一か同程度の検索条件を用いた過去のデータの取得・検索処理により取得できたデータの件数（検索結果件数Ａ）が少ないか否かを判断するものである。
【０１４５】
したがって、このステップＳ１４１の判断処理もまた、平均的なデータの取得・検索処理（通常のデータの取得・検索処理）を行う場合において、通常の周波数のクロック信号を用いたＣＰＵ１３０における処理やメモリへの記録処理に、ある程度の時間（例えば、ユーザーがデータの取得・検索処理においての処理時間に対して感じ取る時間的な感覚に明らかに影響を及ぼし始める程度の時間）がかかるようになるデータ件数であり、例えば、検索結果件数Ａが１００件未満であれば結果件数は少なく（「少」であり）、１００以上であれば結果件数は多い（「多」である）と判断する。
【０１４６】
もちろん、ここでは、検索結果件数Ａが少ないか否かを判断するための基準値の一例として「１００件」という値を用いるようにしたが、これに限るものではない。ＣＰＵ１３０の性能やメモリへのアクセス性能などに応じて適宜の値を用いるようにする。すなわち、ＣＰＵ１３０の性能やメモリへのアクセス性能が良いものである場合には、検索結果件数Ａが少ないか否かを判断するための基準値としては、２００件、３００件、…というように、より大きな値を用いるようにし、逆に、ＣＰＵ１３０の性能やメモリへのアクセス性能が悪いものである場合には、８０件、６０件、…というように、より小さな値を用いるようにする。
【０１４７】
ステップＳ１４１の判断処理において、検索結果件数Ａは少ないと判断した場合には、取得時間が多くても、少なくても、ＣＰＵ１３０は、クロック信号の周波数をアップさせることなく（ステップＳ１４２）、データの取得・検索処理を実行して（ステップＳ１４３）、この図５〜図７に示す一連の処理を終了する。
【０１４８】
すなわち、検索条件に演算処理を含まず、検索結果件数も少なく、取得時間も少ない場合には、ＣＰＵ１３０での処理やメモリへのデータの書き込みに時間がかかることも無いので、クロックアップは行わない。
【０１４９】
また、検索条件に演算処理を含まず、検索結果件数も少なく、取得時間が多い場合には、検索条件に応じてＣＰＵ１３０にかかる負荷も少なく、検索結果件数も少ないので、データをメモリに書き込む処理に時間がかかることも無いにも関わらず、取得時間だけが多いという状況は、例えばデータベースがこの実施の形態の携帯電話端末内には無く、外部ネットワーク上に存在する場合などであって、ネットワーク処理待ち等の携帯電話端末の外部の外的要因によって取得時間がかかることが想定できる。このように、外的要因により、取得時間がかかる場合には、携帯電話端末内のクロック信号の周波数をいくらアップさせても、処理の迅速化を促進することができない場合があるため、携帯電話端末内のクロックアップは行わないこととしている。
【０１５０】
ステップＳ１４１の判断処理において、検索結果件数Ａは少なくない（多い）と判断した場合には、ＣＰＵ１３０は、図５に示したステップＳ１０４で参照した取得件数−取得時間管理テーブルの該当する管理データの取得時間が多いか（長いか）否かを判断する（ステップＳ１４４）。このステップＳ１４４の判断処理は、図６に示したステップＳ１２２やステップＳ１２８の判断処理と同様に、今回用いる検索条件と同じか同程度の検索条件を用いた過去のデータの取得・検索処理にかかった処理時間（取得時間）が多いか（長いか）か否かを判断するものである。
【０１５１】
ステップＳ１４４の判断処理において、取得時間が多いと判断した場合には、検索条件に演算処理を含まないために、ＣＰＵ１３０にかかる負荷は少ないが、検索結果件数が多く、かつ、取得時間が多いということは、取得・検索処理によって得られたデータをメモリに書き込むために時間がかかると判断することができる。したがって、ステップＳ１４４の判断処理において、取得時間が多いと判断した場合には、ＣＰＵ１３０は、クロック信号発生部１４０を制御し、メモリバスクロック信号の周波数をアップさせる（ステップＳ１４５）。
【０１５２】
このステップＳ１４５においては、図６に示したステップＳ１２９の処理の場合と同様に、通常用いられているメモリバスクロック信号の周波数が、例えば、数百メガヘルツ（ＭＨｚ）であった場合には、さらに１００ＭＨｚアップさせるというようにする。もちろん、これは一例であり、メモリなどの性能に応じて、さらに高い周波数、例えば、数百ＭＨｚ以上にアップさせるようにすることも可能である。
【０１５３】
そして、ステップＳ１４５においてメモリバスクロックの周波数をアップさせた後に、ＣＰＵ１３０は、詳しくは図８を用いて後述するデータの取得・検索処理を実行する（ステップＳ１４６）。このステップＳ１４６の処理が終了すると、ＣＰＵ１３０は、クロック信号発生部１４０を制御して、メモリバスクロックの周波数を元の周波数に復旧し（ステップＳ１４７）、この図５〜図７に示す一連の処理を終了する。
【０１５４】
また、ステップＳ１４４の判断処理において、取得時間は多くない（少ない）と判断したときには、検索条件に演算処理を含まず、検索結果件数も少なく、取得時間も少ない場合には、ＣＰＵ１３０に処理負荷がかかることも無く、また、取得したデータのメモリへの書き込みに時間がかかることも無いので、ＣＰＵ１３０は、クロック信号の周波数をアップさせることなく（ステップＳ１４８）、データの取得・検索処理を実行して（ステップＳステップＳ１４９）、この図５〜図７に示す一連の処理を終了する。
【０１５５】
このように、図７に示した処理は、今回用いる検索条件に演算処理を含まず、過去に行った同等の取得・検索処理（今回用いる検索条件と完全に一致する検索条件を用いた、あるいは、同等の処理内容となる検索条件を用いた取得・検索処理）において、検索結果件数が多く、かつ、取得時間が多い場合（上述した（ｅ）の場合)にはメモリへのデータの書き込み処理に負荷のかかるボトルネックとなる処理と判断してメモリバスクロックアップを行うようにしている。
【０１５６】
[データの取得・検索処理について]
次に、図８を用いて、図５〜図７に示したステップＳ１０８、ステップＳ１２４、ステップＳ１２７、ステップＳ１３０、ステップＳ１３３、ステップＳ１４３、ステップＳ１４６、ステップＳ１４９において実行されるデータの取得・検索処理について説明する。
【０１５７】
データの取得・検索処理においては、ＣＰＵ１３０は、今回用いる検索条件のデータを取りに行く場所（目的とするデータベース）、データの取得条件、並べ替えなどの演算条件にしたがって、目的とするデータベースにアクセスし、目的とするデータを取得して、並べ替えて所定のメモリ（例えばＲＡＭ１１０の所定の領域など）に書き込んで蓄積するというように、一連のデータの取得・検索処理を開始する（ステップＳ２０１）。
【０１５８】
ステップＳ２０１の処理と同時に、ＣＰＵ１３０は、時計回路１２２を制御し、今回のデータの取得・検索処理に掛かる時間（取得時間）の計測を開始する（ステップＳ２０２）。そして、ＣＰＵ１３０は、開始させたデータの取得・検索処理が終了するまで待ち状態となり（ステップＳ２０３）、当該取得・検索処理が終了したと判断した場合には、今回の取得・検索処理により取得したデータの件数（検索取得件数）と、今回の取得・検索処理に
かかった時間（取得時間）とを特定する（ステップＳ２０４）。
【０１５９】
そして、ＣＰＵ１３０は、今回用いた検索条件と、検索結果件数と、取得時間とを関連付けた管理データを、ＲＡＭ１１０の検索条件−取得時間管理テーブルに記録し（ステップＳ２０５）、このデータの取得・検索処理を終了する。この管理データの生成、及び管理データの検索条件−取得時間管理テーブルへの記録が、データの取得・検索処理の結果のフィードバックとなる。
【０１６０】
この図８に示す処理は、図５〜図７のフローチャートを用いて説明したように、ステップＳ１０９、ステップＳ１２７、ステップＳ１３３、ステップＳ１４３、ステップＳ１４９においては、従来通り通常の周波数のクロック信号が用いられて実行され、ステップＳ１２４においては、ＣＰＵクロックアップがされた後に実行され、ステップＳ１３０では、ＣＰＵクロックアップとメモリバスクロックアップとがされた後に実行され、また、ステップＳ１４６においては、メモリバスクロックアップがされた後に実行される。
【０１６１】
すなわち、図５〜図７を用いて説明したように、この実施の形態の携帯電話端末においては、ＣＰＵ１３０が、データの取得・検索処理を実行しようとする場合に、用いる検索条件と、当該検索条件と同一又は同等の検索条件が用いられた過去のデータの取得・検索処理においての検索取得件数や取得時間に基づいて、今回行おうとしているデータの取得・検索処理が、時間がかかるボトルネックとなる処理か否かを適切に把握し、ボトルネックとなる処理である場合に、ＣＰＵクロック信号とメモリバスクロック信号との一方又は両方を適切に制御してクロック周波数をアップさせ、データの取得・検索処理の高速化を実現すると共に、クロックアップに伴う消費電力の増加をも必要最小限に抑えることができるようにしている。
【０１６２】
さらに言えば、この実施の形態の携帯電話端末においては、データの取得・検索処理において、ボトルネックとなるデータの取得・検索処理を適切に把握すると共に、ボトルネックとなっている原因が、ＣＰＵにおける処理に起因するものか、メモリへのデータの書き込みに起因するものか、あるいは、その両方に起因するものかを適切に判断し、必要なクロック信号、すなわち、ＣＰＵクロック信号とメモリバスクロック信号との一方又は両方を適切に制御することができるようにしている。
【０１６３】
［実施の形態の効果について］
上述した実施の形態の携帯電話端末においては、目的とするデータを取得する際に、適切なクロックアップが実現できるために、応答性能、バッテリーもちの両方を最適化できる。また、データベースへアクセスするクライアントは、クロック制御を意識せず、適切なクロックアップが実現できる。
【０１６４】
また、図４を用いて説明したように、フィードバック系を持った処理系の採用により、アルゴリズムの問題と、データアクセス速度の問題とを切り分けて制御できるため、アクセス先の物理レイヤの変化に柔軟に対応できる。
【０１６５】
すなわち、アルゴリズムの問題とは、図２において点線で示したＵＩ層１０のアプリケーションソフトウェア１１とミドルウェア層２０のメールデータ収集ソフトウェア２１ａなどのデータ収集ソフトウェアの処理内容の問題である。また、データアクセス速度の問題とは、図２におけるミドルウェア層２０の検索条件判断システム２２やクロック制御システム２４の問題である。
【０１６６】
そして、クロック制御は、図２におけるミドルウェア層２０の検索条件判断システム２２やクロック制御システム２４で対応できるため、アプリケーションソフトウェアの作成においては、クロック制御について考慮する必要はなくなり、目的とするデータの取得・検索のみを考慮すればよいので、アクセス先の物理レイヤの変化等を十分に考慮し、適切なアプリケーションソフトウェアやデータ収集ソフトウェアを作成することができる。
【０１６７】
［変形例］
なお、上述した実施の形態においては、単に、ＣＰＵクロック信号やメモリバスクロック信号の周波数を高くすることを説明したが、クロック信号の制御をより詳細に行うようにすることもできる。例えば、参照する検索条件−取得時間管理テーブルの検索結果件数や取得時間に範囲を設け、参照した管理データの検索結果件数や取得時間に応じて、クロック信号の周波数をどの程度アップさせるかを決めるようにすることもできる。
【０１６８】
例えば、検索結果件数が１００件〜３００件であれば、クロック信号の周波数を１００ＭＨｚアップさせ、検索結果件数が３０１件から５００件であれば、クロック信号を２００ＭＨｚアップさせるというようにすることもできる。同様に、取得時間についても、取得時間が１００ｍｓ〜５００ｍｓであれば、クロック信号の周波数を１００ＭＨｚアップさせ、取得時間が５０１ｍｓ〜７００ｍｓであれば、クロック信号の周波数を２００ＭＨｚアップさせるようにすることもできる。
【０１６９】
また、検索結果件数と取得時間とを組み合わせた条件により、クロック信号の周波数をどの程度アップさせるかを決めるようにしてもよい。例えば、検索結果件数が１００件〜３００件であり、取得時間が３００ｍｓ以下であれば、クロック信号を１００ＭＨｚアップさせ、検索結果件数が３０１件〜５００件であり、取得時間が３０１ｍ〜５００ｍｓであれば、クロック信号を２００ＭＨｚアップさせるなどというようにすることも可能である。
【０１７０】
このように、細かくクロック信号の周波数を制御する場合にも、ＣＰＵクロック信号とメモリバスクロック信号とのいずれを制御するかは、図５〜図７を用いて説明した処理により決まることになる。
【０１７１】
また、上述した実施の形態においては、図６のステップＳ１２３に示したように、ＣＰＵクロック信号だけを制御したり、また、図６のステップＳ１２９に示したように、ＣＰＵクロック信号とメモリバスクロック信号のとの両方を制御するようにしたり、また、図７のステップＳ１４５に示したように、メモリバスクロック信号だけを制御したりする場合があることを説明した。
【０１７２】
そして、いずれの場合であっても、ＣＰＵクロック信号とメモリバスクロック信号とを同程度にクロックアップすることも可能であるし、ＣＰＵクロック信号とメモリバスクロック信号とでは、全く異なる周波数になるように制御することも可能である。例えば、ＣＰＵクロック信号とメモリバスクロック信号とをそれぞれに１００ＭＨｚアップさせるように制御したり、ＣＰＵクロック信号は１００ＭＨｚアップさせるが、メモリバスクロック信号は２００ＭＨｚアップさせるというように、それぞれ別個の周波数となるように制御したりすることができる。どのように制御するかは、この発明を適用する装置のリソース等に応じて適切に決めればよい。
【０１７３】
［フィードバックする情報の縮小］
上述した実施の形態の携帯電話端末においては、フィードバックする情報として、データの取得・検索処理における検索結果件数と取得時間との両方を用いるようにした。しかし、これに限るものではない。例えば、携帯電話端末に搭載するシステムの構成を簡素化したい場合もある。
【０１７４】
このような場合には、検索結果件数と取得時間との一方を用いて、クロック信号の制御を行うようにしてもよい。例えば、検索条件と検索結果件数とだけを用い、検索条件が複数の検索結果件数となるものであり、かつ、過去の同一あるいは同程度の取得・検索処理の検索結果件数が多い場合においてのみ、ＣＰＵクロック信号とメモリバスクロック信号との一方あるいは両方の周波数をアップさせるようにし、それ以外の場合には、クロック信号の周波数のアップを行わないようにしたりすることができる。
【０１７５】
また、検索条件と取得時間とだけを用い、検索条件が複数の検索結果件数となるものであり、かつ、過去の同一あるいは同程度の取得・検索処理の取得時間が多い場合においてのみ、ＣＰＵクロック信号とメモリバスクロック信号との一方あるいは両方の周波数をアップさせるようにし、それ以外の場合には、クロック信号の周波数のアップを行わないようにしたりすることができる。
【０１７６】
図６、図７のフローチャートからも分かるように、上述のように、検索条件に加えて、検索結果件数と取得時間との内の何れか一方を考慮するようにしても、ある程度のクロック制御（簡略化したクロック制御）が可能である。また、検索結果件数を用いる場合よりも、取得時間を用いるようにしたほうが、より適切なクロック制御が可能となる。また、この場合に、ＣＰＵクロック信号とメモリバスクロック信号とのどちらか一方を制御するのか、あるいは、その両方を制御するのかは、処理の高速化や消費電力の観点から検討し、選択するようにすればよい。
【０１７７】
しかし、図１〜図８を用いて説明した実施の形態の携帯電話端末の場合のように、検索条件に加えて、過去の同一あるいは同程度の取得・検索処理の検索結果件数と取得時間との両方を考慮することにより、より適切なクロック制御を行うことが可能であり、好ましい。
【０１７８】
[その他]
なお、上述した実施の形態の携帯電話端末においては、クロック信号発生部１４０が、各部に供給する種々のクロック信号を形成するものとして説明したが、これに限るものではなく、異なるクロック信号を発生させる複数のクロック信号発生部を設けるように構成することももちろん可能である。
【０１７９】
また、上述した実施の形態においては、この発明を携帯電話端末に適用した場合を例にして説明したが、これに限るものではない。機能的に十分な余裕のハードウェアプラットフォームを用いることが難しいために、リソースの問題等が発生し、パーソナルコンピュータなどで行われているようなクロック制御ができない装置、すなわち、ＰＤＡ（Personal Digital Assistants）等と呼ばれる携帯情報端末、電子手帳など、持ち運ばれて利用され、データの取得・検索処理を行う各種の携帯型電子機器（いわゆるモバイル機器）に、この発明は適用して好適なものである。
【図面の簡単な説明】
【０１８０】
【図１】この発明の一実施の形態が適用された携帯電話端末を説明するためのブロック図である。
【図２】図１に示した携帯電話端末に適用されたシステムモデル（データベースシステム）の一例を説明するための図である。
【図３】図１に示した携帯電話端末で用いられる検索条件−取得時間テーブルの一例を説明するための図である。
【図４】図１に示した携帯電話端末において行われるクロック制御処理の概要について説明するためのブロック図である。
【図５】図１に示した携帯電話端末において実行されるデータの取得・検索処理時のクロック制御処理の詳細を説明するためのフローチャートである。
【図６】図５に続くフローチャートである。
【図７】図５に続くフローチャートである。
【図８】図５〜図７の処理の中で実行されるデータ取得・検索処理を説明するためのフローチャートである。
【符号の説明】
【０１８１】
１０１…制御ライン（制御バス）、１０２…データライン（データバス）、１０３…送受信アンテナ、１０４…通信回路、１０５…Ｄ／Ａ変換器、１０６…スピーカ、１０７…マイクロホン、１０８…Ａ／Ｄ変換器、１０９…ＲＯＭ、１１０…ＲＡＭ、１１１…ＥＥＰＲＯＭ、１１２…表示制御部、１１３…表示部、１１４…キー操作部、１１５…押下検出部、１１６…鳴音制御部、１１８…ＬＡＮモジュール、１１９…ＬＡＮ用送受信アンテナ、１２０…カメラモジュール、１２１…ＵＳＢＩ／Ｆ、１２２…時計回路、１３０…ＣＰＵ、１４０…クロック信号発生部
【図１】
0005073462.tif 000002
【図２】
0005073462.tif 000003
【図３】
0005073462.tif 000004
【図４】
0005073462.tif 000005
【図５】
0005073462.tif 000006
【図６】
0005073462.tif 000007
【図７】
0005073462.tif 000008
【図８】
0005073462.tif 000009