JP2009539149A - 装置管理におけるタスク処理の方法、システムおよび機器 - Google Patents

Abstract

装置管理においてタスクを処理するための方法、システムおよび装置が開示される。カスタマイズされたタスクを行うことが端末装置の状態または行われる端末装置の操作によって影響されるときに、タスクは、トリガされ、所定のトリガ条件にしたがって行われることができる。方法は、端末装置の状態または行われる端末装置の操作によって影響されることがあるカスタマイズされたタスクを決定し、タスクを処理する仕方を選択するようユーザを促し、影響されるカスタマイズされたタスクをユーザの選択にしたがって処理するか、または、タスクを所定の処理モードにしたがって処理する。

Description

本発明は、通信分野に関し、より詳細には、装置管理におけるタスク処理の方法、システムおよび機器に関する。

現在、端末装置の機能はますます複雑になってきているため、端末ソフトウェアは、様々な故障を起こしがちである。端末装置は、たとえば、モバイル端末、パームコンピュータ、ノート型パソコン、組み込み機器、または、オンボードシステムを含んでもよいが、それらに限定されない。良好なユーザエクスペリエンスおよびサービスの質（ＱｏＳ）を効果的に保証し且つ端末装置のメンテナンスコストを減少するために、オープンモバイルアライアンス（Open Mobile Alliance）（ＯＭＡ）は、ＯＭＡ装置管理（ＤＭ）Ｖ１．２仕様を開発している。ＯＭＡ ＤＭ Ｖ１．２仕様は、装置管理用のアーキテクチャ全体、プロトコル、通信機構、セキュリティ等を規定するように設計された統一標準である。

仕様において、同期装置管理モード（１セッション中に管理操作が完了する）および非同期装置管理モード（数セッション中にＤＭ管理操作が完了する）に加えて、タスクスケジューリングモードも提供される。装置管理サーバ（ＤＭＳ）は、タスクおよびそのトリガ条件をスケジュールし、それらを端末装置へ送信してもよく、そのため、端末装置は、所定の時間または条件にしたがって、端末装置がオフラインのときでさえ、ＤＭＳ管理操作を自動的に行うことができる。このモードの目的は、ネットワークリソースの諸経費を減少し、ＤＭフレキシビリティを高め、装置管理プロセスのユーザエクスペリエンスを改良することである。タスクスケジューリングモードのフローチャートは、図１に示され、以下のステップを伴う。
１．サーバが端末へ通知を送信。
２．端末がサーバとのセッション接続を確立。
３．サーバが管理タスクを送信。
４．端末が、ユーザに、管理タスクに関する情報を促す。
５．ユーザが、管理タスクを受け入れる。
６．端末が、タスクの状態を報告。
７．サーバが、セッションを閉じる。
８．管理タスクの実行が影響されない状態において、端末装置が、管理タスクの条件をモニタ。たとえば、管理タスクの実行が影響されない状態は、ＳＴＡＮＤＢＹ状態であってもよい。
９．端末装置が、管理操作タスクの実行が影響されない状態において、管理タスクを実行。
１０．端末が、主導的にサーバとの接続を確立し、管理タスクの実行の状態を報告。
１１．サーバが、セッションを閉じる（サーバは、管理コマンドを送信し続けてもよい）。

上記フローから、管理操作タスクの実行が影響されない状態においてのみ、端末装置が管理タスクをモニタすることができることが理解されるだろう。しかし、端末装置へは、任意のときに、様々な例外が発生するだろう（たとえば、端末はバッテリの消耗のため自動的にオフになるか、または、端末はユーザによって設定されたタイミングで自動的にオフになるか、または、端末は端末の何らかのエラーのため自動的にオフになるか、または、端末はユーザからの何らかのふるまいのためオフになる）。これらの例外の発生は、管理タスクがトリガされて予め設定されたトリガ条件にしたがって正常に実行されるのを不可能にする。

本発明の実施形態は、装置管理におけるタスク処理の方法、システムおよび機器を提供し、そのため、スケジュールされたタスクは、タスクの実行が端末装置の現在の状態または端末装置の操作によって影響されるときに、トリガされて所定トリガ条件にしたがって正常に実行されてもよい。

本発明の実施形態は、スケジュールされたタスクの実行が端末装置の状態または端末装置の操作によって影響されるときにスケジュールされたタスクを決定し、スケジュールされたタスクを処理する仕方を選択するようユーザを促し、影響されたスケジュールされたタスクをユーザの選択にしたがって処理するか、または、スケジュールされたタスクを所定の処理する仕方で処理する、方法を提供する。

本発明の実施形態は、タスクを送信し、実行結果を受信するように構成された装置管理サーバと、装置管理サーバと相互作用するように構成された端末装置と、を含む端末装置管理システムを提供する。端末装置は、スケジュールされたタスクの実行が端末装置の状態または端末装置の操作によって影響されるときにスケジュールされたタスクを決定し、且つ、スケジュールされたタスクを処理する仕方を選択するようユーザを促し、影響されたスケジュールされたタスクをユーザの選択にしたがって処理するか、または、スケジュールされたタスクを所定の処理する仕方で処理するように構成された装置管理タスク例外処理モジュールをさらに含む。

本発明の実施形態は、装置管理サーバから送信されたスケジュールされたタスクを処理し、実行結果を戻すように構成された装置管理タスク処理モジュールと、装置管理サーバと端末装置との間で交換される信号を送信するように構成された、装置管理サーバと直接相互作用する装置管理クライアントモジュールと、スケジュールされたタスクの実行が端末装置の状態または端末装置の操作によって影響されるときにスケジュールされたタスクを決定し、且つ、スケジュールされたタスクを処理する仕方を選択するようユーザを促し、影響されたスケジュールされたタスクをユーザの選択にしたがって処理するか、または、スケジュールされたタスクを所定の処理する仕方で処理するように構成された装置管理タスク例外処理モジュールと、を含む端末装置を提供する。

本発明の実施形態によれば、決定条件が端末装置に設定される。決定条件に例外が発生するか否かを決定する機能をユーザが起動する場合には、例外のモニタリングが起動されてもよい。本発明の実施形態で、タスクは、例外があるときでさえモニタされてもよく、且つ、自動的に実行されてもよく、または、ユーザの選択にしたがって実行されてもよい。

例外時（スケジュールされたタスクの実行が、端末装置の現在の状態または端末装置の操作によって影響されるとき）でさえ、予め設定されたトリガ条件にしたがって通常にスケジュールされたタスクをトリガし実行する方法が、本発明の実施形態で提供される。

ユーザにとって、ユーザが端末装置で必要な操作を行うことができない場合には、端末装置の現在の状態は、スケジュールされたタスクの実行に影響を与えがちである。ユーザが端末装置に関連操作を行う場合には、端末装置の操作は、スケジュールされたタスクの実行に影響を与えがちである。スケジュールされたタスクの実行に影響を与える端末装置の操作は、次の場合にさらに分類されてもよい。すなわち、端末装置は、ＯＮ状態からＯＦＦ状態へ移行しようと試みる；端末装置は、ＯＦＦ状態からＯＮ状態へ移行する；ＯＮ状態の間に、端末装置は、端末装置のシステム時間を調節する。

端末装置がタスクを管理するときには、タスクの実行は、実行のデッドラインおよび実行の必要性によって限定される。上記２つの限定のため、タスクは、４つのタイプに分類されてもよい。すなわち、
タイプ１：実行は任意であり、デッドラインを超えないタスク；
タイプ２：実行は強制であり、デッドラインを超えないタスク；
タイプ３：実行は任意であり、デッドラインを超えるタスク；
タイプ４：実行は強制であり、デッドラインを超えるタスク；
である。

端末装置の操作は、以下の態様におけるスケジュールされたタスクに影響を与えることがある。

実施例１：端末装置は、ＯＮ状態からＯＦＦ状態へ移行しようと試みるが、これは、タスクの実行に影響を与える。この実施例のフローが図２に示され、次のステップを伴う。

Ｓ１１：決定条件を端末装置に設定。決定条件は以下を含む。

（１）例外の発生の決定条件。たとえば、端末装置のバッテリ電源が５％未満であるか、または、予め規定された電源切断時間に到達するか、または、ユーザがＯＦＦキーを押下している。

（２）影響されるタスクの決定条件。たとえば、８時間の時間期間が設定される。例外が発生する時間が、開始時間として採られ、８時間以内にトリガされるべきいずれのタスクが、影響を与えられるべきタスクとして決定される。

（３）処理規則。処理規則は、以下を含む。すなわち、所定の処理方針（サーバから送信されたおよび／またはユーザによって予め設定された処理方針）に基づいてタスクを処理する、ユーザの選択に基づいてまたはデフォルトの仕方でタスクを処理する。サーバから送信された処理方針は、少なくとも、即時実行、遅延実行および実行の放棄の１つ、および、サーバへの報告を含む。たとえば、タイプ１のタスクでは、ユーザは、タスクを即座に実行するか、または、タスクの実行を一定の時間点へ遅延するか、または、実行を放棄するか、を選んでもよい。タイプ２のタスクでは、実行の放棄は許可されない。タイプ３のタスクでは、ユーザは、即時実行または実行の放棄を選んでもよい。タイプ４のタスクでは、ユーザはいずれかの選択を行うことを許可されず、端末装置は、デフォルト設定に基づいて、タスクを即座に実行する。

ユーザは、タイプ１、２または３のタスクの処理方針を予め設定してもよい。それに応じて、タイプ１、２または３のタスクを実行しなければならないときには、ユーザは、再度選択をすることを促されず、代わりに、タスクは、予め設定された処理方針に基づいて、直接実行される。

Ｓ１２：上記決定条件が設定された後に、ユーザは、設定された決定条件を起動すること、または、起動しないことを選択することができる。ユーザが決定条件を起動しないことを選択した場合には、その後の操作は、先行技術のものと同一であり、そのため、ユーザは、例外が発生したときに端末装置によって指摘（リマインド）されない。ユーザが決定条件を起動することを選択した場合には、例外はモニタされる。

Ｓ１３：例外がある。たとえば、１８：００に端末装置のバッテリ電源が５％未満である。

Ｓ１４：設定された決定条件に基づいて、１８：００の時間を開始時間として使用し、スケジュールされたタスクのいずれが、次の８時間にトリガされるべきか否かを見出す。そのようなタスクがある場合には、そのタスクは、影響されたタスクとして決定される。明らかに、タスクは、１つであっても２つ以上であってもよい。そのようなタスクがない場合には、操作は行われない。

Ｓ１５：タスクが複数のタスクから取り出される。

Ｓ１６：ユーザからの相互作用が、設定された決定条件および処理規則に基づいて要請されるか否かが決定される。

Ｓ１７：ユーザの相互作用が要請される場合には（すなわち、ユーザの許可を要請する場合には）、ユーザは、タスクを処理する仕方を選択するように促される。たとえば、現在取り出されたタスクがタイプ１に属する場合には、ユーザは、タスクを即座に実行するか、または、実行しないか、または、遅延して一定の時間点で実行するか、のいずれかを選択してもよい。

Ｓ１８：ユーザからの相互作用が要請されない場合には、端末装置は、所定の処理方針またはデフォルト設定に基づいて、タスクを直接処理する。たとえば、タスクは直接実行されてもよい。

Ｓ１９：スケジュールされたタスクがユーザの選択で処理された後に、または、所定の処理方針またはデフォルト設定に基づいて端末装置によって処理された後に、影響される他のタスクがあるか否かが決定される。影響されるタスクがある場合には、ステップＳ１５へ進み、上記処理フローを継続する。影響されるタスクがない場合には、すべての影響されるタスクが処理されたことを示し、端末装置は、次の電源切断操作に進む。

実施例２：端末装置は、ＯＦＦ状態からＯＮ状態へ移行しようと試みる。この実施例のフローが図３に示され、以下のステップを伴う。

Ｓ２１：決定条件が端末装置に設定され、決定条件は以下を含む。

（１）検出を開始するための決定条件。たとえば、端末装置がオンにされるたびに検出が行われる。

（２）影響されたタスクの決定条件。たとえば、処理されなければならないが、端末装置の電源を切断する最後の持続時間中に処理されていないタスクが、識別される。

（３）処理規則。処理規則は、以下を含む。すなわち、所定の処理方針（サーバから送信されたおよび／またはユーザによって予め設定された処理方針）に基づいてタスクを処理する、ユーザの選択に基づいてまたはデフォルトの仕方でタスクを処理する。サーバから送信された処理方針は、少なくとも、即時実行、遅延実行および実行の放棄の１つ、サーバへの報告を含む。たとえば、タイプ１のタスクでは、ユーザは、タスクを即座に実行するか、または、タスクの実行を一定の時間点へ遅延するか、または、実行を放棄するか、を選択してもよい。タイプ２のタスクでは、実行の放棄は許可されない。タイプ３のタスクでは、ユーザは、即時実行または実行の放棄を選択してもよい。タイプ４のタスクでは、ユーザはいずれかの選択を行うことを許可されず、端末装置は、デフォルト設定に基づいて、タスクを即座に実行する。

ユーザは、タイプ１、２または３のタスクの処理方針を予め設定してもよい。それに応じて、タイプ１、２または３のタスクを実行しなければならないときには、ユーザは、再度選択をすることを促されず、代わりに、タスクは、予め設定された処理方針に基づいて、直接実行される。

Ｓ２２：上記決定条件が設定された後に、ユーザは、設定された決定条件を起動すること、または、起動しないことを選択してもよい。ユーザが決定条件を起動しないことを選択した場合には、その後の操作は、先行技術のものと同一であり、そのため、ユーザは、例外が発生したときに端末装置によって指摘（リマインド）されない。ユーザが決定条件を起動することを選択した場合には、例外はモニタされる。

Ｓ２３：ユーザは端末装置をオンにする。たとえば、端末装置は２０：００にオフにされており、次いで、今、２２：００にオンにされる。

Ｓ２４：処理されなければならないが、２０：００〜２２：００の時間期間の間にはまだ処理されていないタスクがあるか否かに関して、チェックが行われる。明らかに、処理されなければならないが、時間期間の間にはまだ処理されていない２つ以上のタスクがあってもよい。

Ｓ２５：タスクが複数のタスクから取り出される。

Ｓ２６：ユーザからの相互作用が、設定された決定条件および処理規則に基づいて要請されるか否かが決定される。

Ｓ２７：ユーザの相互作用が要請される場合には、ユーザは、タスクを処理する仕方を選択するように促される。たとえば、現在取り出されたタスクがタイプ１に属する場合には、ユーザは、タスクを即座に実行するか、または、実行しないか、または、遅延して一定の時間点で実行するか、のいずれかを選択してもよい。あるいは、現在抽出されたタスクがタイプ３に属する場合には、ユーザは、タスクを即座に実行するか、または、実行しないか、を選択してもよい。

Ｓ２８：ユーザからの相互作用が要請されない場合には、端末装置は、所定の処理方針またはデフォルト設定に基づいて、タスクを直接処理する。たとえば、タスクは直接実行されてもよい。

Ｓ２９：タスクがユーザの選択で処理された後に、または、所定の処理方針またはデフォルト設定に基づいて端末装置によって処理された後に、実行すべき他のタスクがあるか否かが決定される。実行すべきタスクがある場合には、ステップＳ２５へ進み、上記処理フローを継続する。実行すべきタスクがない場合には、すべての影響されるタスクが処理されたことを示す。

実施例３：端末装置の時間は、タスクの実行が影響されるように調節される。

Ｓ３１：決定条件が、端末装置に設定され、決定条件は以下を含む。

（１）検出を開始するための決定条件。たとえば、端末装置の時間が調節されるたびに検出が行われる。

（２）影響されたタスクを決定するための条件。たとえば、処理されなければならないが、システム時間の調節によって生じたスキップされた（skipped）時間期間中に処理されていないタスクが、識別される。

（３）処理規則。処理規則は、以下を含む。すなわち、所定の処理方針（サーバから送信されたおよび／またはユーザによって予め設定された処理方針）に基づいてタスクを処理する、ユーザの選択に基づいてまたはデフォルトの仕方でタスクを処理する。サーバから送信された処理方針は、少なくとも、即時実行、遅延実行および実行の放棄の１つ、サーバへの報告を含む。たとえば、タイプ１のタスクでは、ユーザは、タスクを即座に実行するか、または、タスクの実行を一定の時間点へ遅延するか、または、実行を放棄するか、を選択してもよい。タイプ２のタスクでは、実行の放棄は許可されない。タイプ３のタスクでは、ユーザは、即時実行または実行の放棄を選択してもよい。タイプ４のタスクでは、ユーザはいずれかの選択を行うことを許可されず、端末装置は、タスクを即座に実行する。

ユーザは、タイプ１、２または３のタスクの処理方針を予め設定してもよい。それに応じて、タイプ１、２または３のタスクを実行しなければならないときには、ユーザは、再度選択をすることを促されず、代わりに、タスクは、予め設定された処理方針に基づいて、直接実行される。

Ｓ３２：上記決定条件が設定された後に、ユーザは、設定された決定条件を起動すること、または、起動しないことを選択してもよい。ユーザが決定条件を起動しないことを選択した場合には、その後の操作は、先行技術のものと同一であり、そのため、ユーザは、例外が発生したときに端末装置によって指摘（リマインド）されない。ユーザが決定条件を起動することを選択した場合には、例外はモニタされる。

Ｓ３３：端末装置の時間が調節される。たとえば、システム時間は２０：００から２２：００へ調節される。

Ｓ３４：処理されなければならないが、２０：００〜２２：００の時間期間の間にはまだ処理されていないタスクがあるか否かに関して、チェックが行われる。明らかに、処理されなければならないが、時間期間の間にはまだ処理されていない２つ以上のタスクがあってもよい。

Ｓ３５：タスクが複数のタスクから取り出される。

Ｓ３６：ユーザからの相互作用が、設定された決定条件および処理規則に基づいて要請されるか否かが決定される。

Ｓ３７：ユーザの相互作用が要請される場合には（すなわち、ユーザの許可を要請する場合には）、端末装置は、ユーザがタスクを処理する仕方を選択するように促す。たとえば、現在抽出されたタスクがタイプ１に属する場合には、ユーザは、タスクを即座に実行するか、または、実行しないか、または、遅延して後の時間点で実行するか、のいずれかを選択してもよい。あるいは、現在抽出されたタスクがタイプ３に属する場合には、ユーザは、タスクを即座に実行するか、または、実行しないか、を選択してもよい。

Ｓ３８：ユーザからの相互作用が要請されない場合には、端末装置は、所定の処理方針またはデフォルト設定に基づいて、タスクを直接処理する。たとえば、タスクは直接実行されてもよい。

Ｓ３９：タスクがユーザの選択で処理された後に、または、所定の処理方針またはデフォルト設定に基づいて端末装置によって処理された後に、実行すべき他のタスクがあるか否かが決定される。実行すべきタスクがある場合には、ステップＳ３５へ進み、上記処理フローを継続する。実行すべきタスクがない場合には、すべての影響されるタスクが処理されたことを示す。

実施例４：端末装置の現在の状態は、スケジュールされたタスクの実行に影響を与える。この実施例のフローが図４に示され、以下のステップを伴う。

Ｓ４１：決定条件が、端末装置に設定され、決定条件は以下を含む。

（１）例外が発生するか否かを決定するための条件。すなわち、タスクのトリガ点が到達するときには、端末装置はＯＦＦ状態にある。

（２）影響されたタスクを決定するための条件。すなわち、端末装置がＯＦＦ状態にあるときに実行すべきタスク。

（３）自動電源投入が許可されるか否かの条件。たとえば、端末装置がエアプレーンモード（airplane mode）にあるときのみ、自動電源投入は許可されない。

（４）タスクが実行されてもよいか否かを決定するための条件。たとえば、現在の電力が５％を超えるときのみ、タスクは実行されてもよい。または、信号強度の閾値を設定する。

（５）処理規則。処理規則は、以下を含む。すなわち、所定の処理方針（サーバから送信されたおよび／またはユーザによって予め設定された処理方針）に基づいてタスクを処理する、ユーザの選択に基づいてまたはデフォルトの仕方でタスクを処理する。サーバから送信された処理方針は、少なくとも、即時実行、遅延実行および実行の放棄の１つ、サーバへの報告を含む。たとえば、タイプ１のタスクでは、ユーザは、タスクを即座に実行するか、または、タスクの実行を一定の時間点へ遅延するか、または、実行を放棄するか、を選択してもよい。タイプ２のタスクでは、実行の放棄は許可されない。タイプ３のタスクでは、ユーザは、即時実行または実行の放棄を選択してもよい。タイプ４のタスクでは、ユーザはいずれかの選択を行うことを許可されず、端末装置は、タスクを即座に実行する。

ユーザはまた、タイプ１、２または３のタスクの処理方針を予め設定してもよい。それに応じて、タイプ１、２または３のタスクを実行しなければならないときには、ユーザは、再度選択をすることを促されず、代わりに、タスクは、予め設定された処理方針に基づいて、直接実行される。

Ｓ４２：上記決定条件が設定された後に、ユーザは、設定された決定条件を起動すること、または起動しないこと、を選択してもよい。ユーザが決定条件を起動しないことを選択した場合には、その後の操作は、先行技術のものと同一であり、そのため、ユーザは、例外が発生したときに端末装置によって指摘（リマインド）されない。ユーザが決定条件を起動することを選択した場合には、例外はモニタされる。

Ｓ４３：例外が発生するとき、たとえば、ユーザは、端末装置の現在の位置情報を１９：００にＤＭＳへ戻すようにタスクをスケジュールするが、端末装置は、１９：００にはＯＦＦ状態にあるとき。明らかに、１９：００には実行すべき２つ以上のタスクがあってもよい。

Ｓ４４：端末装置は、電源投入条件が現在満足されているか否かを決定する。

Ｓ４５：ユーザがエアプレーンモードを起動していなかった場合には、自動電源投入が許可されることが決定される。その後、端末装置は、電力が許せば、自動的に電源投入される。

Ｓ４６：電源投入後に、端末装置は、タスクを実行する条件が現在満足されているか否かを決定する。

Ｓ４７：電力が許せば、且つ、信号が、タスクを実行するための要件に合致する場合には、タスクが複数のタスクから取り出される。

Ｓ４８：ユーザからの相互作用が、設定された決定条件および処理規則に基づいて要請されるか否かが決定される。

Ｓ４９：ユーザの相互作用が要請される場合には（すなわち、ユーザの許可を要請する場合には）、端末装置は、ユーザがタスクを処理する仕方を選択するように促す。たとえば、抽出されたタスクがタイプ１に属する場合には、ユーザは、タスクを即座に実行するか、または、実行しないか、または、遅延して後の時間点で実行するか、のいずれかを選択してもよい。

Ｓ４１０：ユーザからの相互作用が要請されない場合には、端末装置は、所定の処理方針またはデフォルト設定に基づいて、タスクを直接処理する。たとえば、端末装置の位置情報は、ＤＭＳへ直接戻される。

Ｓ４１１：タスクがユーザの選択で処理された後に、または、所定の処理方針またはデフォルト設定に基づいて端末装置によって処理された後に、実行すべき他のタスクがあるか否かが決定される。実行すべきタスクがある場合には、ステップＳ４７へ進み、上記処理フローを継続する。実行すべきタスクがない場合には、すべての影響されるタスクが処理されたことを示し、フローはステップ４１２へ進む。

Ｓ４１２：端末装置は、自動的に電源切断される。

ＯＭＡ ＤＭによって規定された装置管理の全体的アーキテクチャ、プロトコル、および、ＤＭシステムの通信機構、さらに、セキュリティ等に基づいて、本発明の実施形態は端末装置管理システムも提供し、これは、スケジュールされたタスクを、上記ＤＭプロトコルを使用することによって、端末装置の管理のために端末装置へ送信するように構成される。

４つのタスク処理フローが、例外の影響下で上記されている。ＯＭＡ ＤＭ仕様において、ＤＭサーバは、ＭＯ（マネージャオブジェクト）（Manager Object）を管理することによって装置制御および管理を行う。端末装置の管理タスクを送信する処理において、まず、管理オブジェクトツリーが、スケジュールされたタスクのために設定される。ＯＭＡ ＤＭにおけるスケジュールされたタスク管理オブジェクトの基本的記載が、以下にリストされる。

ノードＳｃｈｅｄＩＤは、スケジュールされたタスクの識別を特定する。Ｓｔａｔｅは、スケジュールされたタスクの状態を特定する。Ｃｏｎｄは、スケジュールされたタスクを実行するための条件であり、時間規則ＴｉｍｅｒノードおよびイベントノードＥｖｅｎｔ ｎｏｄｅを含む。Ｔａｓｋノードは、タスクの実行内容を記録する。加えて、本発明の実施形態にしたがった例外処理方針に合致するように、Ｅｘｃｅｐｔｉｏｎノードを設定すべきである。Ｅｘｃｅｐｔｉｏｎノードは、スケジュールされたタスクが影響されるときの処理方針を記載する。ノードは、以下のような値を取ってもよい。

本発明の実施形態にしたがって、端末装置管理システムは、互いに連結された端末装置（すなわち、本発明にしたがった端末装置）および装置管理サーバを含む。装置管理サーバと端末装置との間の通信は、ＤＭプロトコルを経由して行われる。

図５に示されるように、端末装置（すなわち、本発明の実施形態にしたがった端末装置）は、カスケード状に接続された、装置管理クライアントモジュールと、装置管理タスク処理モジュールと、装置管理タスク例外処理モジュールと、をさらに含んでもよい。装置管理サーバは、装置管理タスクフレームワークモジュールをさらに含んでもよく、これは、ＤＭプロトコルを経由して、装置管理クライアントモジュールと通信する。

あるいは、図６に示されるように、端末装置（すなわち、本発明の実施形態にしたがった端末装置）は、それぞれ装置管理クライアントモジュールに接続された、装置管理タスク処理モジュールと、装置管理タスク例外処理モジュールと、をさらに含んでもよい。装置管理サーバは、装置管理タスクフレームワークモジュールをさらに含んでもよく、これは、ＤＭプロトコルを経由して、装置管理クライアントモジュールと通信する。

装置管理タスクフレームワークモジュールは、タスクを端末装置へ送信するように構成され、端末装置から戻った相互作用結果および実行結果を処理する。

装置管理タスク処理モジュールは、装置管理クライアントモジュールによって送信されたＤＭプロトコルを備えた装置管理サーバから送信されたスケジュールされたタスクを処理し、装置管理クライアントモジュールを経由して実行結果を戻すように構成される。スケジュールされたタスクは、タスクをインストールする／設定することと、タスクの条件をモニタすることと、タスクを制御することと、タスクをトリガすることと、を含んでもよい。装置管理タスク処理モジュールは、さらに、装置管理例外処理モジュールから送信された相互作用結果を送信するようにも構成される。

装置管理タスク例外処理モジュールは、端末装置によって設定されたスケジュールされたタスクを実行するための条件に基づいて、タスクを実行する際に例外をモニタするように構成される（時間、イベント等を含む）。あるいは、例外処理用の処理方針が、装置管理タスク例外処理モジュールに設定されてもよい（たとえば、タスクがトリガ条件を見逃した後に、タスクは放棄され、ＤＭサーバに報告される）。

例外が発生するときには、装置管理タスク例外処理モジュールは、予め設定された処理方針またはシステムデフォルト処理方針にしたがって処理し、次いで、処理結果を装置管理タスク処理モジュールへ戻す。

装置管理タスク例外処理モジュールは、装置管理タスク処理モジュールおよび装置管理クライアントモジュールを経由して装置管理サーバへ処理結果を戻すために、装置管理タスク処理モジュールとのインタフェースを有する。または、装置管理タスク例外処理モジュールは、装置管理クライアントモジュールを経由して直接装置管理サーバへ処理結果を戻すために、装置管理クライアントモジュールとのインタフェースを有する。

装置管理クライアントモジュールは、装置管理サーバと直接相互作用し、装置管理サーバと端末装置との間で交換される信号を送信するように構成される。言い換えると、装置管理クライアントモジュールは、装置管理サーバから送信されたスケジュールされたタスクを装置管理タスク処理モジュールへ送信し、装置管理タスク処理モジュールのタスク例外結果を装置管理サーバへ送信し、さらに、装置管理タスク例外処理モジュール相互作用結果を装置管理サーバへ送信するように構成される。

上述のように、本発明の実施形態にしたがって端末装置に決定条件を設定することによって、ユーザが決定条件における例外の発生を決定する機能を起動する場合に、例外モニタリングが可能になる。

例外が発生しそうになる前に、すなわち、端末装置がＯＮ状態からＯＦＦ状態へ移行しようと試みる前に、端末装置は、現在の時間を開始時間として採り、予め設定された時間期間内に影響されるスケジュールされたタスクを決定し、決定されたタスクを予め処理する。このようにして、影響されるタスクを予測する効果が達成されてもよい。

例外が発生するときには、すなわち、端末装置がＯＦＦ状態にあり且つスケジュールされたタスクを実行する時間に到達しているときには、端末装置は自動的に電源投入される。タスクが実行された後に、端末装置は、自動的に電源切断される。

例外が発生しそうになった後、すなわち、端末装置がＯＦＦ状態からＯＮ状態へ移行するか、または、端末装置がシステム時間を調節した後に、実行しなければならないがまだ実行されていないタスクがあるか否かに関する検出が行われ、検出されたタスクが処理される。このようにして、改善の効果が達成される。

本発明の実施形態にしたがって、タスクは、例外条件においてでさえモニタされてもよく、ユーザの選択にしたがって行われるかまたは自動的に行われる。

本発明の精神および範囲から逸脱せずに様々な変更および修正が可能であることは、当業者には明らかである。したがって、本発明は、本発明の特許請求の範囲および等価物内に入るすべての修正および変更をカバーすることを意図する。

先行技術のタスクスケジューリングモードを示すフローチャートである。 本発明の実施形態にしたがった方法でＯＮ状態からＯＦＦ状態へ移行するときの端末装置のタスク処理フローチャートである。 本発明の実施形態にしたがった方法でＯＦＦ状態からＯＮ状態へ移行するときの端末装置のタスク処理フローチャートである。 本発明の実施形態にしたがった方法でタスクを実行する、ＯＦＦ状態にある端末装置のタスク処理フローチャートである。 本発明の実施形態にしたがった第１のシステムの構成を示す概略図である。 本発明の実施形態にしたがった第２のシステムの構成を示す概略図である。

Claims (17)

1. 装置管理におけるタスク処理の方法であって、
   スケジュールされたタスクの実行が端末装置の状態または端末装置の操作によって影響されるときにスケジュールされたタスクを決定し、
   スケジュールされたタスクを処理する仕方を選択するようユーザを促し、前記影響されたスケジュールされたタスクをユーザの選択にしたがって処理するか、または、前記スケジュールされたタスクを所定の処理する仕方で処理する、
   方法。
2. 前記所定の処理する仕方は、予め設定された処理方針か、または、システムのデフォルトの処理方針を含む、請求項１に記載の方法。
3. 前記予め設定された処理方針は、装置管理サーバから送信された処理方針と、ユーザによって予め設定された処理方針と、の少なくとも一方を含む、請求項２に記載の方法。
4. 前記端末装置が前記スケジュールされたタスクの実行に影響を与えがちである状態が、ＯＦＦ状態であるか、または、
   前記端末装置が、ＯＮ状態からＯＦＦ状態へ移行するか、または、電源投入されるか、または、システム時間を調節するか、の操作を行おうと試みるときに、前記スケジュールされたタスクの実行が影響されがちであるか、
   である請求項１に記載の方法。
5. 前記端末装置がＯＦＦ状態にあり、且つ、前記スケジュールされたタスクを実行する時間に到達するときに、前記端末装置は、自動的に電源投入され、次いで、前記スケジュールされたタスクが完了した後に、自動的に電源切断される、請求項４に記載の方法。
6. 前記端末装置が自動的に電源投入される前に、前記端末装置がユーザの設定にしたがって電源投入されることが現在許可されるか否かに関して決定が行われる、請求項５に記載の方法。
7. 前記スケジュールされたタスクが実行される前に、前記端末装置は、前記スケジュールされたタスクの実行が前記端末装置の条件下で許可されるか否かに関して決定する、請求項６に記載の方法。
8. 前記端末装置がＯＮ状態からＯＦＦ状態へ移行する操作を行うときに、前記端末装置は、現在の時間を開始時間として採り、予め設定された時間期間内に影響されるべきスケジュールされたタスクを決定する、請求項４に記載の方法。
9. 電源投入操作を行った後に、前記端末装置は、実行されていないがＯＦＦ状態が続いている時間期間内に実行しなければならないスケジュールされたタスクを決定する、請求項４に記載の方法。
10. 前記システム時間を調節する操作を行った後に、前記端末装置は、実行されていないが前記時間調節によって生じたスキップ時間期間内に実行しなければならないスケジュールされたタスクを決定する、請求項４に記載の方法。
11. ユーザが選択することができる前記スケジュールされたタスクを処理する仕方は、即時実行、遅延実行、および、実行の放棄を含む、請求項１に記載の方法。
12. 前記スケジュールされたタスクを処理する仕方は、ユーザが選択を行うために、タスクのタイプにしたがってユーザに提供される、請求項１１に記載の方法。
13. 端末装置管理システムであって、
    スケジュールされたタスクを送信して実行結果を受信するように構成された装置管理サーバと、
    前記装置管理サーバと相互作用するように構成された端末装置と、
    を備え、
    前記端末装置は、さらに、スケジュールされたタスクの実行が前記端末装置の状態または前記端末装置の操作によって影響されるときにスケジュールされたタスクを決定し、且つ、前記スケジュールされたタスクを処理する仕方を選択するようユーザを促し、前記影響されたスケジュールされたタスクをユーザの選択にしたがって処理するか、または、前記スケジュールされたタスクを所定の処理する仕方で処理するように構成された装置管理タスク例外処理モジュールを備える、
    端末装置管理システム。
14. 前記装置管理サーバは、スケジュールされたタスクを前記端末装置へ送信し、前記所定の処理する仕方を前記端末装置へ送信し、前記端末装置から戻った相互作用結果および実行結果を処理するように構成された装置管理タスクフレームワークモジュールを備える、請求項１３に記載のシステム。
15. 装置管理サーバから送信されたスケジュールされたタスクを処理し、実行結果を戻すように構成された装置管理タスク処理モジュールと、
    前記装置管理サーバと前記端末装置との間で交換される信号を送信するように構成された、前記装置管理サーバと直接相互作用する装置管理クライアントモジュールと、
    スケジュールされたタスクの実行が前記端末装置の状態または前記端末装置の操作によって影響されるときにスケジュールされたタスクを決定し、且つ、前記スケジュールされたタスクを処理する仕方を選択するようユーザを促し、前記影響されたスケジュールされたタスクをユーザの選択にしたがって処理するか、または、前記スケジュールされたタスクを所定の処理する仕方で処理するように構成された装置管理タスク例外処理モジュールと、
    を備える端末装置。
16. 前記装置管理タスク例外処理モジュールは、前記装置管理タスク処理モジュールおよび前記装置管理クライアントモジュールを通して処理結果を戻すように構成されるか、または、装置管理タスク例外処理モジュールは、前記装置管理クライアントモジュールを通して直接前記処理結果を戻すように構成される、請求項１５に記載の端末装置。
17. 前記装置管理タスク例外処理モジュールは、前記装置管理サーバから送信された所定の処理する仕方を受信して保存するように構成される、請求項１５に記載の端末装置。

Images