JP4317217B2 - 無線情報装置がそれ自身の挙動を自動変更できる方法 - Google Patents

Description

本発明は、無線情報装置がそれ自身の挙動を自動変更できる方法に関する。本発明の明細書で使用される用語「無線情報装置」は、１つ又は２つの無線通信機能を有する任意の機種の装置を含むように広範囲に解釈されるべきであり、無線電話、スマートフォン、通信機、パーソナルコンピュータ、コンピュータ、並びに、カメラ、ビデオレコーダ及び資産管理システム等の無線通信可能なアプリケーションに特化した装置を含む。しかし、これらに限定されない。また、用語「無線情報装置」は、ＧＳＭ又はＵＭＴＳ、ＣＤＭＡ及びＷＣＤＭＡ移動無線、Ｂｌｕｅｔｏｏｔｈ，ＩｒＤＡ等の任意の種類のネットワークを介して、任意の方法で通信できる装置を含む。

装置が環境又は装置の「状況」に従って、それ自身の挙動を自動変更できることは、「状況認識」コンピューティングの必要不可欠な基礎である。「状況」は、場所等の装置特有の変数、及び存在等（すなわち、装置を使用するエンドユーザの存在、傾向等）のエンドユーザ変数を含む。状況認識コンピューティングにおける１つの共通要素は、装置がそれ自身の状況認識を自動的に行なう必要があることであり、例えば、通常、ＧＰＳ等の場所探索機器、すなわち、近接するソースから場所情報を取得する機能を搭載した場所認識装置Ｉである。

装置に場所認識を搭載することにより、新しい機能を可能にする。例えば、装置の動作が危険である場所（例えば、病院又は航空機中）にある時、装置は自動的に電源を切る。

状況認識コンピューティングにおける複数ある前提のうちの１つは、状況認識装置がそれ自身の状況の解釈を自動的に取得することである。しかし、本発明は、状況情報を自動的に取得できる装置を対象とせず、従って、本発明は、当該分野における開発の一般的な要旨から外れる。その代わり、本発明は、エンドユーザが状況の種類情報を装置に手動入力するという場合を対象とする。

更に、従来の状況認識システムは、場所情報及び存在情報に重点を置く。本発明は、それらに重点を置いていないが、特に、時間依存情報を取扱う。

第１の面によると、無線情報装置がそれ自身の挙動を自動変更できる方法であって、
（ａ）エンドユーザが前記装置上で実行する第１のアプリケーションに時間依存情報を入力するステップと、
（ｂ）前記第１のアプリケーションから一般的なＡＰＩを提供する仲介サーバへと時間依存情報を供給するステップと、
（ｃ）前記一般的なＡＰＩ上において、前記仲介サーバから、前記装置上で実行される第２のアプリケーションに対して前記情報を供給するステップと、
（ｄ）前記第２のアプリケーションが前記情報に従って前記装置の前記挙動を適切に自動変更するステップとを備える方法が提供される。

従って、本発明は、アプリケーションに時間依存情報を入力するエンドユーザの非常に特定の場合を取扱う。例えば、時間依存情報は、予定表アプリケーション又は日程表アプリケーションにおける特定の時間に対する入力（例えば、「会議」、「ボブと昼食」、「旅行」、「飛行」等）であってもよい。装置上の異なるアプリケーションは、その情報を利用して、装置の挙動を適切に変更できる。例えば、日程表アプリケーションにおいて、「会議」が午前１０時から午前１１時まで継続することが一覧表示されると仮定する。その時間中、装置の電話アプリケーション（装置の電話機能の制御を可能にする）は、自動的に「着信音オフ」プロファイル等の適切なプロファイルに設定され、それにより、装置は、着信の際、着信音を発生する代わりに振動する。用語「アプリケーション」は、１つ以上の機能を実行するソフトウェアの任意の構成を含むように広範囲に解釈されるべきである。従って、用語「アプリケーション」は、オペレーティングシステムの要素または部分、ユーティリティ、クライアントコンポーネント、サーバコンポーネント等を含む。特に、第２のアプリケーションは、エンドユーザに固有のインタフェースを提供するアプリケーションとは対称的に、ＯＳシステムサービスでもよい。
第１のアプリケーションは、仲介サーバを介して、第２のアプリケーションにデータを間接的に送信する。用語「サーバ」は、通常、広義では、他のコンピュータプログラムにサービスを提供するコンピュータプログラムを意味するように使用される。サーバは、第１のアプリケーションと第２のアプリケーションとを分離する絶縁層として動作する（用語「絶縁層」は、設計パターンにおける技術用語である）。それにより、１つ以上の第１のアプリケーション（すなわち、ユーザが時間依存情報を入力できるアプリケーション、例えば、（ａ）エンドユーザが異なる規定された時間に起こる約束、会議、行事等を入力できる予定表アプリケーション、及び（ｂ）エンドユーザが装置にアラームを発生させたい時間を入力できるアラームアプリケーション）が存在することが可能になる。更に、サーバは、これら任意の第１のアプリケーションが時間依存情報（又は、更に具体的には、この時間依存情報に関連する第１のアプリケーションから送信されたデータ）に応答する任意の数の他のアプリケーションに対してデータを送信することを可能にする。従って、装置は、スリープモードであってもよいが、電源管理アプリケーションは、アラームが鳴った時に通常モードに復帰されるように設定される。この場合、第１のアプリケーションはアラームアプリケーションであり、第２のアプリケーションは電源管理アプリケーションである。更に、サーバは、第２のアプリケーションが実行することを保証し、必要に応じて第２のアプリケーションを起動できる。
従って、本発明のアプローチは、体系化され且つシステム化された方法を装置に提供し、エンドユーザが手動入力した時間依存情報を高度に使用する。

予定表アプリケーションの入力（例えば、「午前１０時から午前１１時まで会議」）に対して、エンドユーザは、メニューリスト（すなわち、エンドユーザが異なるオプションを選択することを可能にする任意の種類のユーザインタフェース）から、その入力に適用するラベルを選択してもよい。ラベルは、第２のアプリケーションにより実行されるべき挙動変更の種類を規定する。従って、「会議」、「昼食」、「旅行」又は「飛行」等の入力に対して、エンドユーザは、その事象に関連付けられる可能性のある挙動変更のポップアップメニューを起動してもよい。これらは、以下の選択可能なオプションを含んでもよい。
（ａ）電話プロファイル（例えば、着信音オフ、バイブレータ、着信音オン、ボイスメールへ転送等）を変更する。
（ｂ）装置の着信音を変更する。
（ｃ）装置のユーザインタフェースを変更する。
（ｄ）電話機能性をオフにする。
（ｅ）装置の全体をオフにする。
（ｆ）装置を節電モードに切り替える。
（ｇ）通信ハードウェア（例えば、ＧＰＳ、ＩＲ、Ｂｌｕｅｔｏｏｔｈ、無線ＬＡＮモジュール）の１つ以上の項目をオフにする。

一般に、第２のアプリケーションは、第１のアプリケーションからのデータにより判定された時間間隔の間、そのデータに従って、装置の挙動を適切に自動変更する。例えば、会議中の１時間は、着信音オフモードにする。

別の例として、電話機に、節電モード、平日睡眠時間、土曜日睡眠時間、日曜日睡眠時間等を設定するためにエンドユーザが入力する複数組の時間を使用して、予定表アプリケーションにおける平日用ダイアログに類似するダイアログを得ることもできる。

第１のアプリケーションからのデータによる挙動変更と、エンドユーザにより第１のアプリケーション又は第２のアプリケーションに直接入力された異なる挙動変更との間に競合が発生する場合、その異なる挙動変更が優先してもよい。すなわち、異なる種類の変更には、異なる優先順位が割り当てられてもよい。従って、エンドユーザは、アラームが鳴った時、又は鳴った直後に、装置を直接スリープモードに戻し、上述の例を継続してもよい。

１つの実現方法において、動的に確定する事象の優先度は決定論的である。すなわち、全ての事象は、正確に挙動するように決定されることを保証しなければならない。１つの事象が別の事象より高い優先順位を有する場合、このことは、全ての状況下において（「この場合に限り」）そのとおりでなければならない。２つの事象が同一の優先順位を有する場合、それら事象は、毎回、同一の結果になるように決定される必要がある。

第１のアプリケーションからのデータによる挙動変更と第１のアプリケーション又は第２のアプリケーションに直接入力された異なる挙動変更との間に競合が発生する場合、競合解決コンポーネントは、優先する挙動変更を判定する。競合を解決するように設計されたコンポーネントは、事前に規定された競合状況及び適切な競合解決判定のリストを有することができる。コンポーネントは、それらの所定の入力を行なう必要がある。事前に規定された競合リストは、導出規則を含んでもよい。すなわち、静的状況ではなく代数代入を許可するため、リストは、動的であり、互換性の問題を引き起こすことはない。これにより、第三者のシステムによる加入及び発行が容易になる。

更に、解除コンポーネントが提供されてもよい。解除コンポーネントは、第１のアプリケーションからのデータによる挙動変更が不適切であるかを判定し、その挙動変更を解除にする。従って、上述のように、装置は、スリープモードから自動的に復帰され、アラームを発生してもよい。しかし、装置は、航空機内にあるため起動すべきではないことをその装置に通知する場所センサを有してもよい。この状況においては、復帰の挙動変更は解除されるであろう。

仲介サーバが、競合解決コンポーネント及び無効コンポーネントを提供してもよい。

更に、エンドユーザが、装置上で実行する第１のアプリケーションに時間依存情報を入力することが可能である。また、第２の異なる装置上で実行する第２のアプリケーションが、時間依存情報に関連するデータを、第１のアプリケーションから直接又は間接的に受信することが可能である。その後、第２のアプリケーションは、そのデータに従って、第２の装置の挙動を適切に自動変更する。

このように、例えば、１つの装置に設定されたアラーム通知は、完全に異なる装置上で実行するアプリケーション内の挙動又はアプリケーションによる挙動を引き起こすために使用されてもよい。２つの装置は、無線リンクを介して接続されてもよい。従って、アラーム通知は、ウェブカメラをトリガして起動させ、画像をウェブサイトに送信してもよい。

第２の面によると、自身の挙動を自動変更するようにプログラムされた無線情報装置であって、
（ａ）エンドユーザが前記装置上で実行する第１のアプリケーションに時間依存情報を入力することと、
（ｂ）前記第１のアプリケーションから一般的なＡＰＩを提供する仲介サーバへと時間依存情報が供給されることと、
（ｃ）前記一般的なＡＰＩ上において、前記仲介サーバから、前記装置上で実行される第２のアプリケーションに対して前記情報が供給されることと、
（ｄ）前記第２のアプリケーションが前記情報に従って前記装置の前記挙動を適切に自動変更することとを可能にする装置が提供される。

本発明は、シンビアンリミテッドにより提供される、無線情報装置のシンビアンＯＳにおいて、時間依存情報の「絶縁層」を使用することにより実現される。絶縁層は、エンドユーザが最初に時間依存情報を入力する送信側アプリケーション（例えば、予定表アプリケーション又は日程表アプリケーション；アラームアプリケーション等）から、アプリケーション及び任意のシステムサーバを区別し、分離する。従って、予定表アプリケーションは、絶縁層（シンビアンＯＳの実装における「変更サーバ」）に時間依存情報を提供できる。このサーバである絶縁層は、時間依存情報データを必要とする任意のクライアントに対し、一般的なＡＰＩを介して、時間依存情報データに対するアクセス権を与える。クライアントは、無線情報装置上のクライアントに制限されず、エンドユーザが時間依存情報を入力するためのシステムを有さない完全に異なる装置上に存在してもよい。従って、エンドユーザが時間依存情報を入力する装置は、事前に設定した時間にわたり、完全に異なる装置の挙動を制御するために使用される。

時間依存情報絶縁層方法に対する利点は、多く存在する。

・アプリケーション開発者及びネットワークオペレータは、時間認識アプリケーションの詳細を理解する必要なく、時間ベースのアプリケーションを開発できる。開発者及びオペレータは、単にＡＰＩを使用する必要があるにすぎない。

・エンドユーザにより入力される時間依存情報を必要とする装置上の任意のアプリケーション又はリソースは、直ちにその情報を容易に取得できる。この時間依存情報は、全ＯＳにおいて入手可能である。アラーム通知は、独立したアラームアプリケーションにのみ限定されず、任意の他のアプリケーションにおける挙動を開始するためにも使用される。

・時間依存情報は、異なるシステムサーバに容易に供給される。例えば、採用すべき電源モードを判定するシステムサーバは、時間依存情報に従って、夜間にはオフモード、夕方にはスリープモードにすること等ができる。

・発行／加入ＡＰＩを使用することにより、任意のそのような認証済サーバは、任意の時間認識アプリケーション（例えば、日程表アプリケーション）により発行された時間依存情報を利用できる。

更に詳細な例は以下の通りである。エンドユーザが規定の時間の間に会議があることを予定表アプリケーションに入力し、且つ会議の時間が予定表アプリケーションのデータに保持されると仮定する。更に、装置プロファイル設定が電話アプリケーション中に存在すると仮定する。これにより、装置の着信／電話転送の挙動が決定される。

本発明は、独立機構を提供し、独立機構により、「送信側」である予定表アプリケーションと「受信側」である電話アプリケーションとの間のデータ通信が可能になる。本発明において、受信側アプリケーションが挙動する方法は、送信側アプリケーションにより事前に指示される。上述の例における挙動では、会議中、装置のプロファイルを会議モードに変更し、会議終了後、元のモードに戻す。

予定表アプリケーションは、電話アプリケーションと通信する必要がある。要するに、予定表アプリケーションは、特定の時間には、「会議プロファイルに切り替える」こと、及び、その後、元のプロファイルに切り替えることを、電話アプリケーションに対して示す必要がある。（電話アプリケーションはプロファイルを使用してプログラムされ、異なる電話会社は異なるプロファイルを作成する。従って、予定表アプリケーションが各予定表の入力の種類に対して使用するプロファイルをユーザに問い合わせることができるように、予定表アプリケーションは、電話アプリケーションが使用するプロファイルを電話アプリケーションに問い合わせる必要があるだろう。）
全てのアプリケーションは、シンビアンＯＳにおいてＵＩＤを有する。ＵＩＤは、全てのアプリケーション（システムサーバを含む）が登録される変更サーバを有することを可能にし、アプリケーションが実際に受信側アプリケーションを起動することなくデータあるいはメッセージを他のアプリケーションへ送信することを可能にする。

考慮すべき実用上の問題がいくつか存在する。
１．会議が早く終了した場合、ユーザは、プロファイルを手動入力で変更してもよい。これによって、プロファイルのデータに従って会議が公式に終了する時間に予定表アプリケーションによるプロファイルを元に戻す試みが、おそらく無効にされるはずである。
２．更に、ユーザは、会議が現在終了したことを示すメニューオプションを使用でき、予定表の会議の終了時間は、現在の時間に自動的に更新される。
３．時計は、会議に関して、予定表アプリケーションに警告する。予定表アプリケーションは、ＵＩＤ（電話アプリケーションに対する）及び電話アプリケーションに対するメッセージ中の機能番号から構成されるメッセージを変更サーバに送信し、電話アプリケーションが現在使用しているプロファイルを示す。予定表アプリケーションは、ＵＩＤ（電話アプリケーションに対する）、メッセージＵＩＤ及びパッケージ記述子中のメッセージから構成されるメッセージを変更サーバに送信する。パッケージ記述子中のメッセージは、１つのプロファイル切り替えメッセージのデータ構造から構成される。１１時に元に戻すというメッセージは、現在のプロファイルを記憶しなければならず且つ何らかのアラーム機能に対する要求を実現する電話アプリケーションに依存するため、電話アプリケーションに対して、そのメッセージを送信しないことが最善である。従って、午前１０時から午前１１時の会議の例を使用すると、１１時に、予定表アプリケーションは、予定表アプリケーションが格納した元のプロファイルに戻すメッセージを送信する。このメッセージは、元に戻す優先順位のメッセージでもよい。ユーザ（又は、より高い優先順位のもの）が会議中にプロファイルを変更する場合、この元に戻すメッセージは無視される。

プロファイルを事前に設定されたものに設定し直すことは、その時間に達した時、何の意味も持たないものである可能性がある（例えば、より高い優先順位の事象の割込みがあった可能性がある）。

競合解決は、このアプローチの特殊な機能である。それは、送信側アプリケーション（アプリケーションに特化した、状況に関する情報を有する）又は中間変更サーバ（汎用装置に特化した、装置の状態に関する情報を有する）でもよい。変更サーバは、一般に、優先順位競合解決又は仲介を実行するのに最適な場所に位置付けられるであろう。例えば、エンドユーザが空港の休憩室で会議を開始し、飛行機に搭乗する時にも継続する場合、電話機は、空港により、エアインタフェース無線をオフにするように指示される。これは、プロファイルを変更するより重要なことである。装置がＰＤＡとして機能する場合、装置は、変更プロファイル設定を依然として優先できる。それにより、電話機は、エンドユーザが飛行機を降りた時に適切なモードとなる。

Claims (13)

1. 無線情報装置がそれ自身の挙動を自動変更できる方法であって、
   （ａ）エンドユーザが前記装置上で実行する第１のアプリケーションに時間依存情報を入力するステップと、
   （ｂ）前記第１のアプリケーションから一般的なＡＰＩを提供する仲介サーバへと前記時間依存情報を供給するステップと、
   （ｃ）前記一般的なＡＰＩ上において、前記仲介サーバから、前記装置上で実行される第２のアプリケーションに対して前記情報を供給するステップと、
   （ｄ）前記第２のアプリケーションが前記情報に従って前記装置の前記挙動を適切に自動変更するステップと
   を備える方法。
2. 前記第１のアプリケーションは、日程表アプリケーション又は予定表アプリケーションであり、前記時間依存情報は、前記日程表アプリケーション又は前記予定表アプリケーションに対する入力である請求項１記載の方法。
3. 前記エンドユーザは、前記入力に対して適用するラベルをメニューリストから選択し、前記ラベルは、前記第２のアプリケーションにより実行される挙動変更の種類を規定する請求項２記載の方法。
4. 前記第１のアプリケーションは、アラームアプリケーションであり、前記時間依存情報は、アラーム時間を規定する請求項１記載の方法。
5. 前記第２のアプリケーションは、前記装置の電話機能の制御を可能にする電話アプリケーションである請求項１から４のいずれか１項に記載の方法。
6. 前記挙動を変更するステップは、
   （ａ）電話プロファイルを変更すること、
   （ｂ）前記装置の着信音を変更すること、
   （ｃ）前記装置のユーザインタフェースを変更すること、
   （ｄ）電話機能をオフにすること、
   （ｅ）前記装置の全体をオフにすること、
   （ｆ）前記装置を節電モードに切り替えること、
   （ｇ）通信ハードウェアの１つ以上の項目をオフにすること
   のうちの１つである請求項１から５のいずれか１項に記載の方法。
7. 前記第１のアプリケーションからの前記情報による前記挙動変更と前記第１のアプリケーション又は前記第２のアプリケーションに直接入力された異なる挙動変更との間に競合が発生する場合、前記異なる挙動変更が優先する請求項１から６のいずれか１項に記載の方法。
8. 前記第１のアプリケーションからの前記情報による前記挙動変更と前記第１のアプリケーション又は前記第２のアプリケーションに直接入力された異なる挙動変更との間に競合が発生する場合、競合解決コンポーネントが優先する挙動変更を判定する請求項１から７のいずれか１項に記載の方法。
9. 解除コンポーネントは、前記第１のアプリケーションからの前記情報による挙動変更が不適切であるかを判定し、前記挙動変更を解除する請求項１から８のいずれか１項に記載の方法。
10. 前記競合解決コンポーネントは、前記サーバである請求項９記載の方法。
11. 前記解除コンポーネントは、前記サーバである請求項９記載の方法。
12. 前記第２のアプリケーションは、前記第１のアプリケーションからの前記情報により規定された時間間隔の間、前記情報に従って、前記装置の前記挙動を適切に自動変更する請求項１から１１のいずれか１項に記載の方法。
13. 自身の挙動を自動変更するようにプログラムされた無線情報装置であって、
    （ａ）エンドユーザが前記装置上で実行する第１のアプリケーションに時間依存情報を入力することと、
    （ｂ）前記第１のアプリケーションから一般的なＡＰＩを提供する仲介サーバへと前記時間依存情報が供給されることと、
    （ｃ）前記一般的なＡＰＩ上において、前記仲介サーバから、前記装置上で実行される第２のアプリケーションに対して前記情報が供給されることと、
    （ｄ）前記第２のアプリケーションが前記情報に従って前記装置の前記挙動を適切に自動変更することと
    を可能にする装置。