JP2007048204A - 端末制御方法、端末装置及びプログラム - Google Patents

Abstract

【課題】 端末の機能追加が効率良く行えるようにする。
【解決手段】 端末が備えるデバイスを利用して実行するデバイス処理部１００と、端末に実装されたアプリケーションプログラム３１０，３２０，３３０と、アプリケーションプログラムを実行する際のユーザ設定を記憶するサービス定義ファイル３１２，３２２，３３２と、デバイス処理を判断してサービス定義ファイルで定義されたユーザ設定条件に該当する項目がデバイス処理で実行されたかを判断し、該当する項目が実行された場合に、アプリケーションプログラムに対して定義された処理を実行するブローカ２１０とを有する構成とした。
【選択図】 図２

Description

本発明は、例えば携帯電話端末などの情報処理端末に適用して好適な端末制御方法及びその制御を適用した端末装置、並びにその制御を実行するプログラムに関する。

従来、携帯電話端末などの情報処理端末においては、その端末の設定をユーザが指定したタイミングで自動的に行うようにしたものがある。例えば、簡単な例としては、ユーザが指定した時刻になると、自動的にタイマが作動して、呼び出し音を鳴らす処理が可能である。

このようなユーザの設定により作動する機能は、携帯電話端末に予め組み込まれたアプリケーションプログラムで実現されるものである。

特許文献１には、ユーザ設定で各種機能を実現できる携帯端末の例についての開示がある。
特開２００４−３１２６１９号公報

ところで、上述したユーザ設定に基づいて自動的に行われる機能は、端末内に予め設定していた閾値を使用して、時刻の到来などを判断するようにしてあり、設定できる項目も限られており、後から機能を追加するのは困難であった。即ち、例えばユーザが指定した時刻になると自動的にタイマを作動させる例の場合、「指定した時刻に音を鳴らす」という行為は、「指定した時刻」という条件以外の条件に変更することはできない。また、条件を複数追加するには、端末内の設定アプリケーションの修正も必要になるが、そのような修正は、通常は困難である。

従来の携帯電話の如き端末では、定められた設定項目で、設定可能な値をユーザに選択させていた。そのため、ダウンロード等で追加したアプリケーションに何か条件を設定したり、設定項目をダウンロードしたアプリケーションに伝えることは出来なかった。例えば、音楽再生用のアプリケーションに再生メッセージを渡す場合、再生するファイルを渡し、マナーモードのオン／オフに応じて情報を渡すことができるようにする等の設定項目を後から加えるような追加や修正は、困難であった。

本発明はかかる点に鑑みてなされたものであり、端末の機能追加が効率良く行えるようにすることを目的とする。

本発明は、端末が備えるデバイスを利用して実行するデバイス処理と、端末に実装されたアプリケーションプログラムと、アプリケーションプログラムを実行する際のユーザ設定を記憶するサービス定義ファイルと、デバイス処理を判断してサービス定義ファイルで定義されたユーザ設定条件に該当する項目がデバイス処理で実行されたかを判断し、該当する項目が実行された場合に、アプリケーションプログラムに対して定義された処理を実行するブローカとを有する構成としたものである。

このようにしたことで、例えばブローカは、デバイス処理を行うアプリケーションプログラムからの割り込みがあった場合に、サービス定義ファイルで定義されたユーザ設定条件に該当する項目に当てはまるかどうか判断し、当てはまった場合に、定義されたアプリケーションが実行されるようになる。

本発明によると、サービス定義ファイルを判断するブローカを設けて、アプリケーションの実行制御を行うようにしたので、サービス定義ファイルの追加などで簡単にユーザ設定条件の追加や修正などが行え、また処理を行うデバイスそのものの追加にも容易に対処できるようになる。

この場合、サービス定義ファイルは、アプリケーションプログラムに対して直列化して出力させて、ブローカがサービス定義ファイルを判断できるようにしたことで、デバイスが追加された場合でもメッセージを適切に受信できるようになる。

また、デバイス及びそのデバイスを利用して実行するデバイス処理を複数備えて、それぞれのデバイス処理用プログラムからのデータを直列化して出力させることで、ブローカがそれぞれのデバイス処理を簡単に判断できるようになり、アプリケーションの追加があっても、新しいデバイスのメッセージを正しく取得できるようになり、アプリケーションやデバイスの追加に容易に対処できるようになる。

以下、本発明の一実施の形態を、添付図面を参照して説明する。

図１は、本例の処理を行う携帯電話端末装置の構成例を示す図である。図１に従って構成を説明すると、アンテナ１１が接続された無線通信処理部１２では、基地局などとの間での無線送信及び受信を行う。受信した信号は、データ処理部１３に送られ、必要なデータの取り出し処理が行われて、音声データ受信時には、その受信音声データを音声処理部１４に供給して音声データ処理を行い、処理された音声信号をスピーカ１６から出力させる。また、マイクロフォン１６が拾った音声信号を音声処理部１４に供給して、伝送用の音声データとする処理を行い、処理された音声データをデータ処理部１３に送り、送信用のデータ構成とする。データ処理部１３で生成された送信データは、無線通信処理部１２で無線送信処理が行われて、アンテナ１１から無線送信される。

この端末装置でインターネットへのアクセスや電子メールデータの送受信などのデータの送受信が行われる際には、データ処理部１３で受信したデータが制御部２１側に送られ、メモリ２４に蓄積され、送信データについては、メモリ２４からデータ処理部１３に送られて、送信処理される。メモリ２４に蓄積されたメールデータやブラウザ閲覧用のデータに基づいて、表示部２２で対応した表示が行われる。また、ユーザが操作する操作キーなどで構成される操作部２３を備え、制御部２１が操作状態を判断し、操作に対応した動作状態や動作モードを設定する構成としてある。

また本例の端末装置は、ＧＰＳ（Global Positioning System）処理部２５を備え、ＧＰＳアンテナ２６で受信した測位用衛星からの信号に基づいて、端末装置の現在位置を測位することができる構成としてある。測位された位置情報は、制御部２１側で判断する。

さらに本例の端末装置は、非接触ＩＣカード部２７を備えて、近接したリーダ・ライタとの間で認証用の無線通信を行って、個人認証や課金処理などが行える構成としてある。この非接触ＩＣカード部２７での処理状態についても、制御部２１が監視して、認証状態などを表示できる構成としてある。

次に、本例の携帯電話端末装置に用意された各機能を動作させるソフトウェアを実行させる構成を、図２を参照して説明する。図２は、本例のランチャフレームワークコンポーネントを示した図である。このランチャフレームワークコンポーネントは、図１に示したメモリ２４が記憶したプログラムの制御部２１での実行で構成されるコンポーネントである。図２では、端末装置が備える各機能を実行するデバイスは、デバイスアプリケーション１００として示される。ここでは、デバイスアプリケーション１００として、ＧＰＳデバイスアプリケーション１１０、タイマアプリケーション１２０、非接触ＩＣカードアプリケーション１３０を備える。それぞれのアプリケーション１１０，１２０，１３０は、センシングインターフェイス１１１，１２１，１３１により、ランチャフレームワークコア２００のブローカ２１０と接続される。

ランチャフレームワークコア２００は、ブローカ２１０が、アプリケーションインターフェイス２２１を介して設定アプリケーション２２０と通信を行う。ブローカ２１０は、この端末に設定されたアプリケーションプログラムの実行を制御する。ここでは、アプリケーションとして、第１アプリケーション３１０と第２アプリケーション３２０と第３アプリケーション３３０とを備える。

第１アプリケーション３１０は、マナーモード設定アプリケーション３１１を備え、マナーモード設定アプリケーションサービス定義ファイル３１２を有する。第２アプリケーション３２０は、壁紙アプリケーション３２１を備え、壁紙アプリケーションサービス定義ファイル３２２を有する。第３アプリケーション３３０は、ブラウザアプリケーション３３１を備え、ブラウザアプリケーションサービス定義ファイル３３２を有する。各アプリケーション３１１，３２１，３３１は、ランチャインターフェイス３１３，３２３，３３３を介してブローカ２１０と接続してある。ランチャインターフェイス３１３，３２３，３３３は、本例の場合、直列化された形式のデータを受信した場合に、元の形式のデータに変換して、アプリケーションプログラムに渡す。

各設定アプリケーション３１１，３２１，３３１は各アプリケーションのサービス定義ファイル３１２，３２２，３３２を読み込み、ユーザにデバイスと、そのデバイスの動作の条件が当てはまった場合にどのような行動を起こすかをユーザに選択させる。

ブローカ２１０では、ユーザが設定した条件に当てはまる項目があるかどうかをデバイスアプリケーションからの割り込みがある度にチェックを行い、当てはまる項目があった場合、設定されたアプリケーションを呼び出し、定義されたメッセージを通知する。

例えば、駅に着いた際にマナーモードにするアプリケーションがあるとして、それとＧＰＳデバイスアプリケーションを接続する場合を例にすると、センサとしてＧＰＳデバイスアプリケーション１１０が接続され、アプリケーションにはマナーモード設定アプリケーションが接続される。マナーモード設定アプリケーションのサービス定義ファイルは下記のような項目となっているとする。

〈サービス〉
〈名前〉マナーモード設定〈／名前〉
〈パラメータ type="ON/OFF" name="Switch" ／〉
〈起動タイプ type="HOGEHOGE" ／〉
〈／サービス〉

この例では、サービスは「マナーモード設定」というサービス１つが定義されており、パラメータとしてオン／オフを選択できるタイプの項目である。

マナーモード設定アプリはブローカからランチャＩ／Ｆを通じて呼び出される。ランチャＩ／Ｆではサービス定義ファイルに従ってユーザが指定した値を取得することができる。上記ではマナーモードのオン／オフを指定したため、"Switch"という名前のプロパティを取得し、オンであった場合はマナーモードをオンにし、イベントを終了する。

上述したサービス定義ファイルは、アプリケーションプログラムが起動・設定させることのできるサービスを記述するものである。以下、このサービス定義ファイルについて説明すると、本例のサービス定義ファイルは別ファイルとなっており、汎用性を持たせる言語で記述してある。そのため、組み込みアプリケーションだけでなく、ダウンロードして後から追加したアプリケーションにも対応する事が出来る。サービス定義ファイルはランチャの設定アプリから読み込まれ、ユーザに選択肢を提供することとなる。

サービス定義ファイルの構造としては、例えば汎用メタ記述言語で記述されている以下のようなファイルである。
〈サービス〉
〈名前〉マナーモード設定〈／名前〉
〈パラメータ type="ON/OFF" name="Switch" ／〉
〈起動タイプ type="HOGEHOGE" ／〉
〈／サービス〉

ここでは一つのサービスに対して、名前とパラメータが指定されている。また選択できる起動タイプにはHOGEHOGEが設定されている。

パラメータはユーザが入力する項目を表す。入力の種別は［type］で表し、あらかじめ用意されたプリミティブ型とデバイス毎に定義するオリジナル型の場合はデバイスアプリケーション経由で設定することが出来、イベントに応じてアプリケーションにメッセージを送信する際に同時に送信される。本例の場合、一つのアプリケーションが複数のサービスを提供することも可能で、複数のパラメータを指定することも可能である。

アプリケーションに渡すパラメータは、プリミティブ型とオリジナル型の２種類に分別される。プリミティブ型はランチャにはじめから組み込まれた型である。例えばオン／オフ，テキスト，数値，ＵＲＬ，ファイル選択，リスト，時間等の型が用意されている。オン／オフの場合は入力ボックスがオンとオフの項目となり、ユーザはオンまたはオフのどちらかを選択することとなる。テキストの場合はテキスト入力状態となり、テキストを設定することが可能である。

オリジナル型としては、ユーザからの入力以外の複雑な型や、デバイス依存な型を指定することができるものである。例えば、ＧＰＳから取得した現在位置や、非接触ＩＣアプリケーションから入力されたバイナリデータ等を表すことができる。これらは各デバイスアプリケーションがバイナリにシリアライズし、ハンドリングされたアプリケーションがデシリアライズする事によってデータの受け渡しが可能である。

オリジナル型はデバイスアプリケーションを呼び出してユーザに設定させること、イベント発生時にデバイスアプリケーションから値を取得することも可能である。ＧＰＳの場合、イベント設定時にユーザに地図から位置を選択させることも可能であるが、イベント発生時に現在位置を送信させることも可能である。

イベント発生時はブローカが型名とマッピングしているデバイスアプリケーションを呼び出し値を取得する。例えば"LAST_GPS_LOCATION"のような型を指定しておくと、マッピングされたＧＰＳアプリケーションを呼び出し、最後に取得した位置情報を返す。

データはセンシングインターフェイス１１１，１２１，１３１（図２）を通じてバイナリにシリアライズされ、アプリケーションにイベントと同時に送信される。

プリミティブ型と違い、オリジナル型はバイナリであるため、各デバイスアプリケーション、もしくはアプリケーションの仕様を元にデシリアライズして各アプリケーションで使用される。

アプリケーションの端末へのインストール時には、サービス定義ファイルをデプロイする。アプリケーションは単独で動作することが可能であるが、デプロイされたサービスはランチャコアのフレームワークから起動・呼び出しが出来るようになる。

設定アプリケーション２２０（図２）は、サービス定義ファイルをグラフィカルに表示し、ユーザとのインターフェイスとなるコンポーネントである。即ち、ランチャコアのユーザインターフェイスとなる部分が設定アプリケーションである。設定アプリケーションはサービス定義ファイルをグラフィカルに表示する処理を行う。設定アプリケーションを立ち上げると、例えば図３に示した設定画面のような画面が端末装置の表示部２２に表示される。

例えば、プリミティブ型のオン／オフがサービス定義ファイルに指定されている場合、設定アプリケーションはオン／オフを選択させるようなリストボックスを表示させる。時間を入力するプリミティブ型の場合、時間が表示され、ユーザ操作で選択を行うことになる。

設定アプリケーション２２０は、ユーザからの複数のイベント設定を受け付け、イベントリストを保存しておく。設定したイベントは編集を行ったり、削除を行ったりすることが可能である。ブローカ２１０と設定アプリケーション２２０は独立しており、ブローカ２１０は常駐しイベントが発生した場合に設定アプリケーション２２０が保存している設定項目を読み出す。

図３の例では、マナーモード設定アプリで設定できる項目はマナーモード設定であり、オプションとしてはオン／オフである。条件ボタンを押すと、センシングデバイスを選択することができ、ここで接続しているＧＰＳデバイスアプリケーション１１０と接続する。図４は、このときの条件での接続状態を示した図であり、ＧＰＳデバイスアプリケーション１１０からの入力を契機にアラームアプリケーションと接続されて、アラームアプリケーションからのオンというパラメータを同時にユーザに通知する。

ユーザが設定ボタンを押すと、ＧＰＳアプリケーションに制御が移され、場所を設定するモードになる。場所の設定が完了すると、マナーモードの設定は完了する。なお、条件は複数追加することができる。例えばタイマアプリケーションの設定で午後、ＧＰＳアプリケーションの設定で自宅を設定した場合、午後自宅に帰宅したという条件を設定することができる。

このようにしてユーザは、設定した場所に近づくとマナーモードのスイッチをオンにするイベントをマナーモード設定アプリに対して設定したことになる。これらは設定アプリを立ち上げることでいつでも設定を変更／追加／削除が出来る。

ブローカ２１０は、センサから入力されたイベントとユーザが設定したイベント群のマッチングを図り、イベントのハンドリングを行うコアコンポーネントである。また、この振る舞いがランチャコアのフレームワークとなる。図５は、ブローカ２１０の処理例を示した図である。図５に示したように、例えばＧＰＳアプリケーションからの割り込み発生で、ユーザ設定項目をサービス定義ファイルから参照して、該当するアプリケーションプログラムをパラメータと共に呼び出す。

本例のブローカは、デバイスの接続とイベントのハンドリングを行うコンポーネントである。このコンポーネントはデバイスからのイベントとユーザが設定した項目を設定アプリケーションのデータベースからマッチングをとり、ユーザが指定したイベントを発生させる事を行う常駐コンポーネントである。ブローカは、ユーザが指定した設定項目にマッチングしているかどうかをチェックするが、判定自体はセンシングインターフェイスを通じて各デバイスアプリケーションが行う。

ブローカは、図６に示したフローチャートに示すように動作する。図６に従って動作例を説明すると、ブローカは待機状態で常駐している。動作の契機は各センシングデバイスからの割り込みである。センシングデバイスから割り込みを受けると、設定項目ループに入り（ステップＳ１１）、割り込み元のデバイスに対応づけられた設定項目を抽出し、未チェックの設定項目があるか否か判断し（ステップＳ１２）、未チェックの設定項目がある場合に、ユーザ設定項目のデータを取得する（ステップＳ１３）。そして、割り込み発生デバイスが条件に含まれているか判断し（ステップＳ１４）、含まれている場合には設定されている条件を取得して（ステップＳ１５）、さらに割り込み発生デバイスが条件に含まれているか判断し（ステップＳ１６）、条件チェックループ処理を行う（ステップＳ１７，Ｓ１８，Ｓ１９）。そして、全ての条件を満たしているか判断し（ステップＳ２０）、満たしている場合に、該当するアクションを実行させる制御を行う（ステップＳ２１）。そして、項目設定ループが終了するまで繰り返される（ステップＳ２２）。

このフローチャートに示した動作は、それぞれ抽出した設定項目に対し、イベントを発生させて良いか判定を行う処理である。ただし、ブローカ自体は判定を行わず、センシングデバイスに対応したデバイスアプリケーションに判定を行わせる。デバイスアプリケーションが真の判定を行った場合、ブローカは対応するアプリケーションメッセージを送信する。

この際、アプリケーションが起動していなかった場合は起動を試み、起動していた場合はメッセージを送信する。メッセージはサービス定義ファイルで定義されているパラメータ群で、ＸＭＬのような汎用的なフォーマットで送信することとなる。

例えば、ＧＰＳデバイスアプリケーションからの割り込みの場合、位置情報を取得するとブローカに対して位置情報をポストする。ここでブローカはＧＰＳデバイスアプリケーションに対応づけられているイベントを検索し、現在の位置情報と対応づけられたイベントがあるかどうかをＧＰＳデバイスアプリケーションに対して投げ、設定した範囲だった場合は対応づけられたアプリケーション、この場合はマナーモード設定アプリケーションを呼び出す。なお、該当するアプリケーションが起動していない場合はアプリケーションを起動させ、メッセージを投げることになる。

また、各デバイスを作動させるデバイスアプリケーションは、図１に示したように、センシングインターフェイスを実装している特別なアプリケーションである。

ここで、ブローカへの割り込み通知について説明すると、デバイスアプリケーションは、デバイスドライバとつながったコンポーネントである。デバイスドライバから割り込みを受けた場合、ブローカに対して通信を行い、デバイスによる割り込みが行われたことを通知する。

本例においては、ブローカにデバイス毎の割り込み通知を意識させないため、割り込み通知は全て直列化された形式でブローカに渡す。このことによって、デバイスが増えた場合でも、ブローカを修正する必要はなくなる。即ち、図７に示すように、例えばＧＰＳ処理部２５（図１）からの割り込み発生がＧＰＳデバイスアプリケーションにあると、割り込み通知を示すデータを直列化したデータとして、ブローカに渡す。各デバイスアプリケーションは、図２に示すようにセンシングインターフェイスを持ち、ブローカからのリクエストに応えるよう実装される。

デバイス側の条件の設定は複雑である。例えばタイマの条件設定では、時間の設定（○○時△△分□□秒を設定）や午前・午後の設定を行うこともある。またＧＰＳによる位置の設定では、例えば図８に示したように、地図を端末に表示させて、その地図中に、条件となる位置や範囲（図８では範囲を円で地図中に表示）を示して設定することができる。図８の例では、表示された範囲内に入った時に、起動されるようにしてある。或いは、表示された範囲から出た場合に、起動するようにしてもよい。緯度経度を指定して、範囲や場所を設定するようにしてもよい。

本例の場合には、デバイスが増える毎にブローカを修正することのないよう、条件設定インターフェイスを持ち、デバイス毎に条件設定を行わせる。即ち、図９に示すように、設定アプリケーションからの条件設定インターフェイスの呼び出しで、ユーザの条件入力を行わせる表示があり、その表示に基づいてユーザ操作を行うことで条件が設定される。

条件を設定すると、その条件を直列化し設定アプリケーションに応答する。デバイス毎の複雑な設定は直列化によって一つのバイナリに変換される。このことによって、ブローカや設定アプリケーションはデバイス毎の条件を気にする必要がなくなり、どのようなアプリケーションが追加されても対処できるようになる。

図６のフローチャートでの条件チェックループに相当する条件判定インターフェイスは、設定した条件にマッチしているかどうかを判定する。判定はブローカが条件にマッチするデバイスを発見した場合に呼び出す。ここで、設定された条件の直列化された形式と、デバイスからの割り込みの直列化された形式を条件判定インターフェイスに渡し、条件に当てはまっているか否かを返答する。図１０は、条件判定インターフェイスの処理例を示した図でありブローカからデバイス割り込みのデータとユーザ設定条件のデータがあると、条件判定インターフェイスで判定される。

そして、ランチャインターフェイス（図２）を通じてイベントを通知されたアプリケーションプログラム（プログラム３１１，３２１，３３１のいずれか）は、プリミティブ型のパラメータと、直列化された形式のオリジナル型を渡されることになる。ここで、ランチャインターフェイスは、直列化された形式のデータを元の形式のデータに変換して渡す処理が行われる。そのため、デシリアライザインターフェイスを持ち、直列化された形式のデータを、それぞれのデバイスアプリケーションのメッセージへ復元する。

ランチャインターフェイスは、発生したイベントを受け取るためのインターフェイスである。ブローカはイベントを検知すると、ランチャインターフェイスを通じてアプリケーションにメッセージエンベロープを発行する。イベントを受け取ったアプリケーションはサービス定義ファイルに従ったパラメータを受信する。パラメータには、プリミティブ型の場合とオリジナル型の場合が存在する。プリミティブ型の場合は名前を指定してパラメータを受信し、オリジナル型の場合は受信したバイナリファイルをデバイスアプリケーションのデシリアライザインターフェイスを用いて、直列化形式から元メッセージ形式（例えば経度×××、緯度×××など）に変換して、データを取り出す。図１１は、その場合の例を示した図である。

イベントが発生した段階でアプリケーションが起動していない場合、アプリケーションを起動させる。この際、起動タイプはランチャにより受信で、メッセージエンベロープを発行する。

イベントが発生した段階でアプリケーションが動作している場合、アプリケーションにメッセージが発行する。メッセージのパラメータにメッセージエンベロープが添付されているため、このエンベロープから各種パラメータを取り出す。

次に、ここまで説明した処理が具体的に実行される例を、図１３及び図１４のフローチャートを参照して説明する。図１３はＧＰＳ測位で検出された位置に基づいてマナーモード設定を行う場合の処理例であり、図１４はＧＰＳ測位で検出された位置に基づいてマナーモード解除に関する処理例であり、フローチャートそのものは、既に説明した図６のブローカ動作フローとほぼ同じである。

図１３に示したマナーモード設定例について説明すると、ステップＳ１３でのデータ取得時に、ＧＰＳデバイスアプリケーション条件である、品川駅近辺に入った場合、その位置の緯度経度と半径と、出入りの条件として外からその範囲に入った場合を取得し、呼び出す機能が、マナーモード設定アプリケーションであり、パラメータがマナーモードオンであるとする。そして、ステップＳ１４での条件判断で、条件が満たされることが判断され、ステップＳ１５で、ＧＰＳデバイスアプリケーションから現在の位置情報をバイナリ化されたデータとして取得する。バイナリ化されたデータは、直列化されたデータとして送り、ステップＳ１８の条件チェックで判定を得る。

そして、ステップＳ２０で、ここでの条件である、品川駅近辺３００ｍに入ったか否かが判断され、その条件を満たしている場合に、ステップＳ２１で、マナーモード設定アプリケーションに対して、マナーモードオンというパラメータを送り、マナーモードを設定させる。マナーモードが設定されると、例えばこの端末装置への電話の着信時に呼び出し音を鳴らさないと共に、所定回数以上の呼び出しで自動的に留守番応答が行われる。

次に、図１４に示したマナーモード解除例について説明すると、ステップＳ１３でのデータ取得時に、ＧＰＳデバイスアプリケーション条件である、川崎駅近辺に入った場合、その位置の緯度経度と半径と、出入りの条件として外からその範囲に入った場合と、タイマデバイスアプリケーション条件である、夕方から深夜まで（例えば午後５時から深夜０時まで）の時間の条件を取得し、呼び出す機能が、マナーモード設定アプリケーションであり、パラメータがマナーモードオフであるとする。そして、ステップＳ１４での条件判断で、条件が満たされることが判断され、ステップＳ１５で、ＧＰＳデバイスアプリケーションから現在の位置情報をバイナリ化されたデータとして取得する。バイナリ化されたデータは、直列化されたデータとして送り、ステップＳ１８の条件チェックで判定を得る。

そして、ステップＳ２０で、ここでの条件である、川崎駅近辺に夕方から深夜までの時間帯に入ったか否かが判断され、その条件を満たしている場合に、ステップＳ２１で、マナーモード設定アプリケーションに対して、マナーモードオフというパラメータを送り、マナーモードの設定を解除させる。マナーモードの設定が解除することで、例えばこの端末装置への電話の着信時に呼び出し音を鳴らすと共に、自動的な留守番応答をしない状態となる。

このようにして、ユーザが設定した任意の条件で、マナーモードなどの端末が備える機能の自動設定ができるようになる。

なお、ここまで説明した例では、ＧＰＳによる測位位置に応じて、マナーモードの設定を行う処理例について説明したが、その他の設定も可能である。例えば図１２に示すように、位置情報に基づいて、地域情報のダウンロードを行い、地域情報とブラウザを連携させた表示を行うようにしてもよい。

本発明の一実施の形態による端末の例を示すブロック図である。 本発明の一実施の形態によるランチャフレームワークコンポーネントの例を示す構成図である。 本発明の一実施の形態による設定画面例を示す説明図である。 本発明の一実施の形態による条件接続の例を示す説明図である。 本発明の一実施の形態によるブローカの処理例を示す説明図である。 本発明の一実施の形態によるブローカの動作例を示すフローチャートである。 本発明の一実施の形態による割り込み通知と直列化変換の例を示すブロック図である。 本発明の一実施の形態による条件設定例を示す説明図である。 本発明の一実施の形態によるユーザ条件入力例を示す説明図である。 本発明の一実施の形態による条件判定インターフェイスの例を示す説明図である。 本発明の一実施の形態によるデシリアライザインターフェイスの例を示す説明図である。 本発明の一実施の形態によるランチャコアフレームワークと地域情報のダウンロードの例を示す説明図である。 本発明の一実施の形態によるマナーモード設定例を示すフローチャートである。 本発明の一実施の形態によるマナーモード解除例を示すフローチャートである。

符号の説明

１１…アンテナ、１２…無線通信処理部、１３…データ処理部、１４…音声処理部、１５…スピーカ、１６…マイクロフォン、２１…制御部、２２…表示部、２３…操作部、２４…メモリ、２５…ＧＰＳ処理部、２７…非接触ＩＣカード部、１００…デバイスアプリケーション、１１０…ＧＰＳデバイスアプリケーション、１２０…タイマアプリケーション、１３０…非接触ＩＣカードアプリケーション、２００…ランチャフレームワークコア、２１０…ブローカ、２２０…設定アプリケーション、３１０…第１アプリケーション、３１１…マナーモード設定アプリケーション、３１２…マナーモード設定アプリケーションサービス定義ファイル、３２０…第２アプリケーション、３２１…壁紙アプリケーション、３２２…壁紙アプリケーションサービス定義ファイル、３３０…第３アプリケーション、３３１…ブラウザアプリケーション、３３２…ブラウザアプリケーションサービス定義ファイル

Claims (5)

1. 端末が備えるデバイスを利用して実行するデバイス処理と、
   端末に実装されたアプリケーションプログラムと、
   前記アプリケーションプログラムを実行する際のユーザ設定を記憶するサービス定義ファイルと、
   前記デバイス処理を判断し、前記サービス定義ファイルで定義されたユーザ設定条件に該当する項目が、前記デバイス処理で実行されたかを判断し、該当する項目が実行された場合に、前記アプリケーションプログラムに対して定義された処理を実行するブローカとを有することを特徴とする
   端末制御方法。
2. 請求項１記載の端末制御方法において、
   前記サービス定義ファイルは、前記アプリケーションプログラムに対して直列化したデータで伝えて、前記ブローカが前記サービス定義ファイルを判断できるようにしたことを特徴とする
   端末制御方法。
3. 請求項１記載の端末制御方法において、
   前記デバイス及びそのデバイスを利用して実行するデバイス処理は複数備え、それぞれのデバイス処理用プログラムからのデータを直列化して、前記ブローカがそれぞれのデバイス処理を判断できるようにしたことを特徴とする
   端末制御方法。
4. 処理を実行するデバイス機能部と、
   アプリケーションプログラムを記憶するアプリケーションプログラム記憶部と、
   前記アプリケーションプログラム記憶部に記憶されたアプリケーションプログラムを実行する際のユーザ設定を記憶するサービス定義ファイル記憶部と、
   前記デバイス機能部での処理実行状態を判断し、前記サービス定義ファイル記憶部に記憶されたファイルで定義されたユーザ設定条件に該当する項目が、前記デバイス機能部で実行されたかを判断し、該当する項目が実行された場合に、前記アプリケーションプログラム記憶部に記憶されたアプリケーションプログラムに対して、定義された処理を実行する制御部とを備えることを特徴とする
   端末装置。
5. 端末に実装されるプログラムにおいて、
   端末が備えるデバイスを利用して実行するデバイス処理プログラムと、
   端末に実装されたアプリケーションプログラムと、
   前記アプリケーションプログラムを実行する際のユーザ設定を記憶するサービス定義ファイル作成プログラムと、
   前記デバイス処理プログラムの実行状況を判断し、前記サービス定義ファイル作成プログラムで作成されたサービス定義ファイルで定義されたユーザ設定条件に該当する項目が、前記デバイス処理プログラムで実行されたかを判断し、該当する項目が実行された場合に、前記アプリケーションプログラムに対して定義された処理を実行する制御プログラムとを有することを特徴とする
   プログラム。

Images