(57)【特許請求の範囲】
【請求項１】
通信システムにおいて，ユーザ移動性または個人移動性を実現するシステムであって，該システムは，
第１ターミナル装置を使用している，ユーザ・ドメイン内の第１のユーザ端末と，
ターミナル・ドメイン内に，前記第１ターミナル装置および第２，第３ターミナル装置を含み，
テレコム・ドメインを含み，
ユーザ移動性のサポートが，前記第１ターミナル装置内に置かれた，各ユーザ端末に対する複数の異なるエージェントの使用により実行され，その際，前記第１のユーザ端末に対する第１エージェントPD_UAaは前記テレコム・ドメイン内に置かれ，前記第１のユーザ端末に対する第２エージェントTDm_UAaは少なくとも前記ターミナル・ドメイン内の前記第１ターミナル装置に置かれ，前記第１，第２エージェントは前記第１のユーザ端末を含む相互作用をイネーブルにするために協働し，前記第１のユーザ端末は，同時に前記第１，第２ターミナル装置内で前記第１のユーザ端末の第２エージェントTDm_UAaを有することにより，前記第１，第２ターミナル装置の各々を同時に使用することができ，
さらに，それぞれ異なるユーザ端末に対する複数のエージェントが前記第１ターミナル装置内に置かれるように，前記第１のユーザ端末に対する前記第２エージェントTDm_UAaおよび第２のユーザ端末に対する第３エージェントが前記第１ターミナル装置内に置かれ，前記第１，第２のユーザ端末が，前記第１ターミナル装置を同時に使用／共用できる，ことを特徴とした前記システム。
【請求項２】
請求項１に記載のシステムにおいて，デフォルト・ユーザ端末が前記第１ターミナル装置に登録され，デフォルト・エージェントTD_UAが常に前記第１ターミナル装置に存在していることを特徴としたシステム。
【請求項３】
請求項１に記載のシステムにおいて，ユーザ・ドメイン内に存在しているオブジェクトにより起動された前記テレコム・ドメイン内に存在するオブジェクトについての動作は，エージェントTD_UAaに対して出され，次いで前記テレコム・ドメイン内のアドレス指定されたオブジェクトについて順次動作を呼び出すピア・オブジェクトPD_UAaに送られることを特徴としたシステム。
【請求項４】
請求項１に記載のシステムにおいて，前記テレコム・ドメイン内のオブジェクトによって起動された動作はエージェントPD_UAaに対してなされ，該エージェントPD_UAaは，前記TDm_UAaに配信されるために，それぞれのターミナル装置ｍのターミナル・エージェントTamに送り，正しいターミナル装置内のユーザ・エージェントは，前記ユーザ・エージェントに存在するオブジェクトについての動作を最終的に呼び出すことを特徴としたシステム。
【発明の詳細な説明】
発明の分野
本発明は、通信システム、特に電気通信システムにおけるサービスの可用性を改善する装置に関するものであり、このシステムは、分散したハードウェアおよびソフトウェアのコンポーネントを備えていて、これらが互いに相互作用して１以上のユーザに対しサービスを提供する。
より特定すると、本発明は、分散システムにおけるユーザ移動性（user mobility）サポートに関している。
さらにより特定すると、本発明は、エージェント技術の改良した利用に関するものである。
現行技術
オープン分散システムは、分散システムの１つのカテゴリであって、多数の異なったソースから得ることができる各コンポーネントから構成されており、そしてこれらが互いに単一の分散システムとして働くようになっている。
オープン分散システムは、分散システムに対しアプリケーション・インターフェースを提供し、そしてこのアプリケーションは、適当な任意のローカル・オペレーティング・システム上で走らせることができる。ＴＩＮＡアーキテクチャ（電気通信情報ネットワーク・アーキテクチャ（Telecommunications Information Network Architecture））は、電気通信アプリケーションに対するオープン分散システムの１つの特殊化であり、そして本発明は、とりわけこのようなＴＩＮＡアーキテクチャに関連して主に開発したものである。
ＴＩＮＡ−Ｃアーキテクチャは、個人（ユーザ）移動性問題に対処するものであるが、各ユーザに対し多数のエージェントを使用するものではない。さらに、このアーキテクチャは、例えば一人のユーザが同じまたは異なった能力の種々の端末を使用するのを許容する追加のコンステレーション（constellations）の許可、および同じ端末を何人かのユーザが使用することの許可に対処するものではない。
ＴＩＮＡの他には、分散システム上におけるユーザの移動性に対処するアーキテクチャはない。
結果として、特に分散システムに関連したユーザ移動性に対する増大する要求が存在し、そしてこれまで、分散システム用の適切な解決法が提案されてきていない。
発明の目的
本発明の目的は、通信システムにおけるサービスの改善した可用性、特に分散システムにおけるユーザ移動性のサポートの実装を提案することである。
本発明の別の目的は、ユーザが移動するのを可能にしながら依然としてアプリケーション／サービスに対するアクセスを可能にする装置を提供することである。
本発明のさらに別の目的は、改善した可用性を提供し、これで一人のユーザが同一のあるいは異なった能力のいくつかの端末を使用でき、これによって何人かのユーザが同じ端末を使用できるようにすることである。
本発明のさらに別の目的は、異なったユーザに属するが同じ端末上で走るオブジェクトの分離および保護を可能にする装置を提供することである。
本発明のさらなる目的は、各移動ユーザに対し多数のエージェントの改善した使用を提案することである。
発明の摘要
上記の目的は、プリアンブルで述べたタイプの装置において実現し、この装置は、主として、この装置にユーザ移動性サポートを導入して、これにより個人移動性を含むアプリケーション可用性を可能にすることを特徴とする。
より特定すると、上記目的は、分散システムに対する前記ユーザ移動性サポートを導入することにより実現する。
本発明のさらなる特徴および利点は、添付の図面を伴った以下の説明並びに添付の請求の範囲から明かとなる。
【図面の簡単な説明】
図１は、相互作用に関して定義したユーザ移動性を図示する概略図。
図２は、本発明の１実施形態、特にユーザ移動性サポートのために必要なユーザ・エージェントの導入を示す概略図。
図３は、移動ユーザが開始させる動作を図示する概略図。
図４は、テレコム・システム（telecom system）ドメイン内のオブジェクトが開始させる動作を図示する概略図。
図５は、登録（registration）データを記憶するための専用のオブジェクト・ユーザ登録手段を含む、本発明の１つの特定した実施形態を図示する概略図。
図６は、デフォルトのユーザ・ドメインをもつ相互作用を図示する概略図。
図７は、ユーザ・インターフェース・オブジェクトの機能を図示する概略図。
図８は、ローカル登録の１実施形態を図示する概略図。
図９は、ローカル登録用のプロシージャを図示する概略図。
図１０は、リモート登録のための１実施形態を図示する概略図。
図１１は、リモート登録用のプロシージャを図示する概略図。
図１２は、ローカル登録解除の１実施形態を図示する概略図。
図１３は、ローカル登録用のプロシージャのための１実施形態を図示する概略図。
図１４は、リモート登録解除を図示する概略図。
図１５は、リモート登録解除用のプロシージャを図示する概略図。
図１６は、多数端末登録の１例を図示する概略図。
図１７は、オブジェクト登録能力をもつユーザ登録オブジェクトの１実施形態を図示する概略図。
図１８は、ユーザ・オブジェクトの１つの登録の１実施形態を図示する概略図。
実施形態の詳細な説明
ユーザ移動性の定義
ここで、Telecom SystemNドメイン、TerminalmドメインおよびUseraドメインから成る例について考察する。Useraドメインは、Useraオブジェクトと、ＣＯ１と呼ぶ随意計算オブジェクトとから成っている。ここで、オブジェクトＣＯ１は、Terminalm内に物理的に常駐させたりあるいはさせなかったりすることができる。ユーザが１つの端末あるいはハードウェア・デバイスでもある場合には、ＣＯ１は、Terminalmドメイン上ではなくユーザ自体上に常駐させることができる。
ユーザ移動性を提供することは、ＣＯ１を含むユーザ・ドメイン全体が、移動しまた端末を変更できるようにし、しかも依然としてTelecom SystemNドメイン内に常駐するオブジェクトＣＯ２と相互作用することができるようにすることである。相互作用では、動作およびストリーム・フローの両方を意味する。これは、図１に示している。
エージェントの使用
次に、各ドメイン間の相互作用を可能にするのに必要なエージェントを導入する。Useraを表すため、PD_UAa（ProviderDomain_User_Agenta）と呼ぶエージェントを、Telecom SystemNドメインに導入する。このエージェントは、識別、認証、暗号化等のセキュリティ機能を引き受け、そしてこれは、ユーザの移動性をサポートする機能も担当する。TDm-UAa（TerminalDomain_User_Agenta）と呼ぶ別のエージェントをTerminalmドメイン内に導入することにより、Useraを表し、またTerminalmのセキュリティ機能を引き受ける。このUseraが別の端末例えばTerminalnも使用している場合、TDn_UAaもTerminalnドメイン上のそのユーザに対し定義する。
さらに、どの端末も所有者を有しなければならないこと、またこの所有者をその端末のデフォルトのユーザとして定義することが合理的である、と仮定する。合法でかつ稼働中の端末は、常に一人のデフォルト・ユーザを有することになる。このデフォルト・ユーザは、その端末に恒久的に登録される。ある端末に対するデフォルト・ユーザの定義により、我々は、その端末の使用を制限することもできるアクセス制御プロシージャを実装することができる。もちろん、デフォルト・ユーザは、別の端末にも登録することができるが、前者の登録は常に有効であり、そして我々は、多数端末登録の場合をもつことになる。したがって、Terminalmドメインに導入したデフォルト・ユーザを表すエージェントTD_UAmがある。これに対応して、Telecom SystemNドメインにエージェントPD_UAmを導入する。
加えて、我々は、Terminalmドメイン内のTelecom SystemNドメインを表すＳＰＡＮと、Telecom SystemNドメイン内のTerminalm表すTAmと、端末アクセス・ポイント（ポート）を表すTAPと、ネットワーク・アクセス・ポイントを表すＮＡＰのようなオブジェクトを有する。これは、図２に示している。
移動ユーザとテレコム・システム間の動作のイネーブル
動作は、UseraによりまたはTelecom SystemNドメイン内のオブジェクトのいずれかにより開始させることができるため、我々は、２つの場合について別々に考察する。
移動ユーザが開始する動作
ここで、ＣＯ１がオブジェクトＣＯ２に対する動作OpY()を呼び出したいと仮定する。この呼び出しは、直接には行われない。
先ず初めに、動作Call(CO2.OpY())をオブジェクトTD_UAaに対し発する。これは、ＣＯ２とTD_UAaとの間に関連がなければならないことを示す。この関連の定義は、以下の説明する。次に、TD_UAaは、そのピア・オブジェクト（peer-object）PD_UAaに対する動作Call(O2.OpY())を呼び出す。TD_UAaがこの動作要求を発するのに必要なものは、オブジェクトPD_UAaの識別子である。TD_UAaとPD_UAaの両方は、同じユーザを表し、またたった１つの固有のPD_UAaしかないため、TD_UAaにとっては、PD_UAaの識別子を見い出すことは問題ではない。実際に、これら２つのオブジェクトの両方は、これらが表すユーザの識別を保有している。
PD_UAaに対する動作Call(O2.OpY())は、ＳＰＡＮの動作
Call(PD_UAa.Call(CO2.OpY()))に変換する。ＳＰＡＮは、そのピア・オブジェクトTAmに対する動作要求Call(PD_UAa.Call(CO2.OpY()))を発する。この要求は、ＴＡＰに対する動作Call(TAmCall(PD_UAa.Call(CO2.OpY()))に変換する。次に、ＴＡＰは、この動作を、これが現在接続されているＮＡＰに送る。ＮＡＰは、次に動作要求Call(PD_UAa.Call(CO2.OpY()))をTAmに発する。TAmは次に、PD_UAaのCall(CO2.OpY())を呼び出す。このPD_UAaは、ここで、オブジェクトＣＯ２の動作OpY()を呼び出す。これは、動作OpY()の伝達で終わる。
ユーザ・ドメイン内のオブジェクトによる動作の呼び出しは、シームレスにサポートする。ユーザ・ドメインに要求する唯一の情報は、ＣＯ２が固定のｋＴＮ上に常駐している（またはテレコム・システム・ドメイン内の位置している）ことである。これ以外の追加の情報は、要求されない。これは、図３に示している。
テレコム・システム・ドメイン内のオブジェクトが開始させる動作
図４を参照する。
ここで、テレコム・システム・ドメイン内のオブジェクトＣＯ２が、ＣＯ１の動作OpX()を呼び出すことを希望していると仮定する。この動作は、PD_UAaの動作Call(CO1.OpX())に変換する。この変換を可能にするには、ＣＯ１がUseraドメインに属しそれ以外のどのユーザ・ドメインにも属していないことの情報が、テレコム・システム・ドメイン内で利用可能でなければならない。
TD_UAaは、次に、オブジェクトTD_UAaに対する動作Call(CO1.OpX())を呼び出す。これの最初の要求は、TD_UAaの識別子を見い出すことである。差し当たって、我々は、このような情報が利用可能であると仮定する。我々は、直ぐに、どのようにしてこれを見い出すかについて戻ることにする。その動作要求は、その後で、TAmに対する動作Call(TD_UAa.Call(CO1.OpX()))に変換する。これを行うには、PD_UAaは、TAmの識別子かあるいは端末例えばUseraが位置するTerminalmの識別を有しなければならない。
この必要な情報を獲得して移動ユーザに到達するプロシージャは、ロケーション・トラッキングとして一般に知られており、そしてこれは、ロケーションの登録（registration）および登録解除（deregistration）のプロシージャを補足することが多い。
差し当たっては、PD_UAaがどうにかして十分な情報を取得しそして正しいTerminal_agent、例えばTAmを呼び出す、と仮定する。このステップからステップ６まで、全ての動作は、端末移動性のハンドリングに関係している。TAmは、この呼び出しのそのピア−ピア・オブジェクトＳＰＡＮへの転送を、動作Call(SPAN.Call(TD_UAa.Call(CO1.OpX()))をＮＡＰに発することにより行う。ＮＡＰは、この呼び出しを、対応するＴＡＰに転送する。ＴＡＰは、次にＳＰＡＮのCall(TD_UAa.Call(CO1.OpX()))を呼び出す。ＳＰＡＮは、TD_UAaのCall(CO1.OpX())を呼び出す。最後に、TD_UAaは、オブジェクトＣＯ１の動作OpX()を呼び出す。これは、テレコム・システム・ドメイン内のオブジェクトが開始した動作の伝達で終了する。
我々は、これらプロシージャの成功のための条件が、ユーザが使用しているあるいはアクセスを有している現行の端末についての情報の可用性である、と判った。正式に言えば、テレコム・システム・ドメイン上に常駐するオブジェクトが開始させる動作の成功は、PD_UAaとTAとの間の関連性の定義に依存する。
Useraが移動しているとき、PD_UAaとTAとの間の関連性が、相関的に変化しており、したがって時には定義できないことがある。この関連性を決定するのに必要な動作は、ユーザ登録および登録解除として一般に呼ばれているプロシージャの一部分である。
ユーザ・ロケーションの登録および登録解除
ユーザ・ロケーションの登録および登録解除は、PD_UAとTAとの関連性を決定するプロシージャである。これには多くの方法があり、以下のセクションで説明する。
“オンザフライ（on-the-Fly）”方法
最も直線的な方法は、“オンザフライ（on-the-Fly）”方法である。この方法は、“怠惰（lazy）”とも呼ばれており、それは、必要となるまで、例えば要求が発されるまで何もすべきでないからである。テレコム・システム・ドメイン内に常駐するオブジェクトＣＯ２がUseraドメインに属するオブジェクトＣＯ１の動作を呼び出すことを希望するとき、要求をPD_UAaオブジェクトに発する。PD_UAaオブジェクトは、全てのTAに対しブロードキャストを発して、これらに移動ユーザについてのサーチすることを頼む。これらTAは、これらの片方、すなわちＳＰＡに対し、対応するTD_UAaをサーチするよう頼むことができる。ＳＰＡのいずれも成功しない場合、Useraに達することはできない。これの他には何もすることはできない。１つのＳＰＡがその移動Useraを見い出すことに成功した場合、これが、その対応TAに対し回答し、そしてこのTAは、再びPD_UAaに通知する。このとき、PD_UAaは、問題のTAに動作呼び出しを送ることができ、そして、このTAは、対応のＳＰＡにそれを送る。ＳＰＡは、この動作をTD_UAaオブジェクトに送り、そしてこのオブジェクトは、それをオブジェクトＣＯ１に送る。これで、相互作用がイネーブルされる。
この方法は、小さくかつ“地理的分散の低い”のシステム、すなわち少数の端末および少数のユーザをもつシステムに対しては、満足なものである。より大きなあるいは地理的に大きく分散したシステムに対しては、時間のかかるものとなり得る。ユーザを見い出すことあるいはそのユーザを見い出すのが可能でないと知るのにしばらくかかることがある。この方法はまた、テレコム・システム・ドメインにおいてかなりの活動を必要とする。システム内にｎ個の端末とｍ人のユーザがいる場合、最悪の場合には、ｍ人のユーザ全てを見い出すのにｍ×ｎのサーチ・プロシージャを同時に開始させることがある。この方法は、インターネットにおいて、サーチ・エンジンを別のウェブ・ページまたは情報場所のロケーションを識別するのに使用する時に、用いられている。
PD_UAとTAとの間の関連性の事前決定に基づく方法
PD_UAとTAとの間の関連性の事前決定に基づく別の方法がある。PD_UAは、前もって、移動ユーザがいずれかのTAとコンタクトをもっているか否か、またその特定のTAインスタンスとそれが関連しているかについて知っている。言い換えれば、PD_UAオブジェクトは、PD_UAとTAとの間の関連性を記憶する能力を有している。
単純な実装は、TA識別子を使用することであり、この識別子は、１つのTAに対する“分散透明（distribution transparent）”ポインタの一種である。この方法により、動作要求が発されるとき、実行時でかなりの時間が節約される。
このTA識別子は、必ずしもPD_UA内に組み込む必要はないが、別個の計算オブジェクト、例えばPD_UAオブジェクトに対し登録情報サービスを供するUser_Registrationとして実現することができる。このUser_Registrationオブジェクトには、いくつかのTA識別子を含ませることができるが、それは、一人のユーザに、いくつかの端末を同時に使用することを許容することができるからである。
必要な第２の情報は、対応するTD_UAの識別子である。この情報は、ユーザの識別と端末の識別から導き出すことができるが、これを記憶させることの方がより便利である。実行時に必要な処理が少なくなるにつれ、より短い応答時間が得られる。TD_UAおよびTAについての情報を含むUser_Registrationオブジェクトは、図５に示している。
ここで、問題は、PD_UAがTD_UAおよびTAについての情報をいかにして得ることができるか、そしてその更新を、ユーザの現実の移動との一致を保証するためにいつ行われるべきかである。
デフォルト登録
先に述べたように、どの端末も、この端末の所有者であるデフォルト・ユーザに関連させる。この場合、PD_UAとTA間の関連性は、常に定義する。我々は、これをデフォルト登録と呼ぶことができる。
再び、オブジェクトＣＯ２が、Useraドメインに属するオブジェクトＣＯ１の動作OpXを呼び出すこと希望している場合の例について考察することにする。ここで、Useraは、Terminalmのデフォルト・ユーザであると仮定する。動作要求Call(CO1.OpX())を受けると、PD_UAaは、User_Registrationaの動作Get_Registration()を呼び出す。User_Registrationaは、そのTD_UAおよびTAテーブルをチェックし、そしてデフォルトのTD_UAおよびTAの各識別子、すなわちTD_UAaとTAmとをPD_UAaに返す。PD_UAaは、TAmオブジェクトに対する動作Call(TD_UAa.Call(CO1.OpX()))の呼び出しに進む。このプロシージャは、全動作OpXが達成されるまで、前述のように続き続く。これは、図６に示している。
ローカル登録
ローカル登録は、UseraがUsermに属するTerminalmを使用することを希望している場合である。実際には、ローカル登録は、アクセス・セッションに属するものであり、このアクセス・セッションの目的は、ユーザがサービスにアクセスするのをイネーブルすることである。
続ける前に、ある種の要件をその端末に課さなければならない。何人かのユーザが同一の端末を使用してテレコム・システム・ドメインにアクセスできるようにするため、この端末は、何等かのよりローカルの“インテリジェンス”、すなわち、固定のネットワークにおいて使用されている現行の端末と比べより一層の処理および機能の能力をもたなければならない。我々は、TerminalmドメインにＵＩ（User_Interface）と呼ぶオブジェクトを導入する。このオブジェクトは、端末と各ユーザとの間の相互作用の監督および制御を担当する。ＵＩは、何人かのユーザが同一の端末を共有している場合に、異なったユーザ間でスイッチする機能を有する。要求時には、ＵＩはまた、新たなTD_UAオブジェクトを作成することにより、到来する新たなユーザをサービスすることができる。
図７において、我々は、３人のユーザがいる例について示す。UserbとUsercは、すでにTerminalmに登録されている。要求時には、ＵＩは、これら二人のユーザ間でスイッチ、すなわち、入力／出力チャンネルをTD_UAbまたはTD_UAcに接続することができる。このスイッチ要求は、コマンドNew-User()を入力するか、１つのキーを押すか、あるいはあるアイコン上でマウスをクリックするか等のような種々の異なった方法で実現することができる。
Useraが来てその端末を使用するのを希望するとき、このユーザは、要求New-Userを発する。ＵＩは、新しくかつ“一時的な”TD_UAオブジェクトを作成することができる。一時的とは、このTD_UAが、まだいずれのユーザ、より特定すると、このテレコム・システム・ドメインに対して知られておりかつ認識可能ないずれのPD_UAとも関連付けられていない、ということを意味している。この関連付けは、ローカル登録の実行が成功した後でのみ行われることになる。ＵＩはまた、入力／出力チャンネルをこのTD_UAに接続する。これで、Useraは、一時的TD_UAと相互作用することができることになる。
次に、我々の例に戻ることにする。Useraがユーザ自身をTerminalmに登録するのを希望するとする。動作New-User()を呼び出し、そして彼に割り当てられた一時的TD_UAを取得した後、Useraは、彼のユーザ識別子（または名前）をその一時的TD_UAに入力する（図８参照）。
ユーザ識別子から、一時的TD_UAは、動作LocalRegister()がそのPD_UAaに対し呼び出されなければならないことを知る対応するPD_UAaの計算インターフェース識別子（CII）を導き出す。したがって、この一時的TD_UAは、ＳＰＡＮに対し動作Call(PD_UAa.LocalRegister())を呼び出すことにより、動作LocalRegister()の伝達を開始する。この呼び出しは、ＴＡＰ、ＮＡＰを通して伝達し、そしてTAmに到達する。TAmは次に、PD_UAaに対しLocalRegister()動作を呼び出す。PD_UAaは、セキュリティ・プロシージャ（procedures）を開始する。図９に示すように、我々はここで、このセキュリティ・プロシージャが成功すると仮定する。PD_UAaは、User_Regaに対し動作Set-Registration（TD_UA，TAm）を呼び出し、これは、TD_UAおよびTAmの識別子をセーブする。PD_UAaは、TD_UAに対し状態ＯＫを回答し戻す。TD_UAは、PD_UAaの識別子をセーブし、そしてUseraに関連付けた恒久的エージェントとなる。TD_UAは、Terminalmに対するUseraの最終的な登録解除まで、生きたままに留まる。
リモート登録
リモート登録は、Useraが、彼がログインされていないリモートTerminalm上でアプリケーションを走らせるあるいはアプリケーションを受けることを希望するような場合である。Useraは、実際には、Terminalnにてログインされている。リモート登録を実行するには、Useraは、Terminaln上で登録アプリケーションを走らせなければならない。登録アプリケーションは、特別なアウトゴーイングのアプリケーションであって、アプリケーションの配達のための登録を可能にするものである。しかし、登録アプリケーションの設計は、この書類の範囲を超えたものである。
差し当たっては、登録アプリケーションは、Useraが、その希望するリモート端末、すなわちTerminalmの識別を入力するのを可能にする。
登録アプリケーションは、次に、PD_UAaに対しRegister(Termm)を呼び出す。
PD_UAaは、TAmすなわちTerminalmの端末エージェントに対し、動作Register(Usera)を呼び出す。ここで再び、登録を付与する前に、TAmは、この端末の使用のためユーザのアクセス制御を開始させることにより、Useraがユーザ自身をTerminalmに登録するのを許可されているかどうかチェックして、端末ユーザのプライバシーを保護する。Useraが許可されていない場合、TAmはその回答においてNotAllowed（不許可）状態をPD_UAaに返し、そしてこれは、登録アプリケーションに通知する。このとき、登録アプリケーションは、NotAllowedメッセージをUseraに配信する。
上記アクセス制御が成功したと仮定する。TAmは、その片方のＳＰＡＮに対し動作Register（PD-UAa）を呼び出す。通常のように、この動作呼び出しは、当然ながら、ＮＡＰおよびＴＡＰを通して伝達される。
図１０において、我々は、この説明の負担とならないようにするため、簡単に、端末移動性サポートに属するいくらかの動作をイタリックで提示している。
この呼び出しを受けると、ＳＰＡＮは、TD_UAa2を作成し、そしてTD_UAa2に対する動作Associate_with(PD_UAa)を呼び出して、PD_UAaの識別子のセーブを生じさせる。TD_UAa2は、このとき、Terminalmの登録解除までは存続することになる。ＳＰＡＮは、ＯＫ状態およびTD_UAa2の識別子をTAmに返し、そしてこれはまた、この同じ情報をPD_UAaに返す。
次に、PD_UAaは、User_Regaに対し動作Set_Registration(TD_UAa2,TAm)を呼び出し、そしてこれは、TD_UAa2およびTAmの識別子をセーブする。PD_UAaは、次にＯＫ状態を登録アプリケーションに返す。登録アプリケーションは、ＯＫ状態をTerminalmのUseraに対し配信する。これは、リモート登録を完了する。リモート登録のためのプロシージャは、図１１に示している。
ローカル登録解除
ユーザがある端末でのユーザ自身の活動を終了することを希望するとき、ユーザは、その端末から単にログアウトすればよい。この登録解除は、この同じ端末からローカル開始させる。
図１２に示した例について考察することにする。Terminalmに登録されたUseraは、ログアウトを希望している。このユーザは、ユーザ自身のアクセス・セッションを終了させ（節９．４参照）、そしてこれは、TD_UAへの終了要求をもたらす。この終了の前に、TD_UAは、PD_UAaに対する動作LocalDeregister()を呼び出す。この動作要求は、ＳＰＡＮに対する動作Call（PD_UAa.LocalRegister()に変換する。この動作は、ＴＡＰ、ＮＡＰを通して伝達し、そしてTAmに到達する。次に、TAmは、PD_UAaに対する動作LocalDeregister()を呼び出す。PD_UAaは、User_Regaの動作Reset_Registration(TD_UA,TAm)を呼び出し、そしてこれは、TD_UAおよびTAmの識別子をその内部テーブルから除去する。PD_UAaは、TD_UAに対し状態ＯＫを返す。これで、TD_UAは、それ自身を終了させることができる。ローカル登録解除のためのこのプロシージャは、図１３に示している。
リモート登録解除
ある端末におけるユーザ自身の活動を終了させるには、ユーザはまた、別の端末からリモートで登録解除を開始させることもできる。ここで、Useraが、このユーザ自身を、Userm（デフォルト・ユーザ）に属するTerminalmにおいて、別の端末すなわちTerminalnから登録解除することを希望している例について考えることにする。
このような登録解除を行うには、Useraは、Terminalnで走っている登録解除アプリケーションに対するアクセスを有して、このユーザが、リモート端末（この端末からこのユーザが登録解除を希望している）の識別を入力することができるようにならねばならない。このアクセスをもつと、その登録解除アプリケーションは、PD_UAaオブジェクトに対する動作Deregister(Termm)を呼び出す。
PD_UAaは、TD_UAa2すなわちUseraに割り当てたTerminalm上の端末ドメイン・ユーザ・エージェントに対する動作Deregister(Usera)を呼び出す。この動作は、図１４において点線で示している。物理的には、これは、TAmに対する動作に変換し、そして次に、TD_UAa2に到達する前に、ＮＡＰ、ＴＡＰ、ＳＰＡＮを介して伝達する。TD_UAa2オブジェクトは、PD_UAaの識別子を除去し、ＯＫ状態をPD_UAaオブジェクトに返し、そしてそれ自身を終了させる。
PD_UAaオブジェクトは、User_Regaオブジェクトに対し動作Reset_Registration(TD_UAa2,TAm)を呼び出して、TD_UAa2およびTAmの識別子のその内部テーブルからの除去を起こさせる。ＯＫ状態を受け取ると、PD_UAaオブジェクトは、ＯＫ状態を登録解除アプリケーションに返すことができ、そしてこの登録解除アプリケーションは、それをUseraに送ることもできる。これで、リモート登録解除が完了する。この登録解除のプロシージャは、図１５に示している。
多数端末登録のサポート
先に述べたように、一人のユーザに、いくつかの端末にて登録しそして同時にそれらを使用することを可能にしなければならない。
この状況を明らかにするため、図１６に示した例について考えることにする。Useraは、２つの端末、すなわちTerminalnとTerminalmで登録されており、そして２つの端末エージェントTD_UAa1およびTD_UAa2にそれぞれ関連付けられている。このユーザは、TerminalnとTerminalmでそれぞれ走っている２つの計算オブジェクトＣＯ１とＣＯ３を有している。ＣＯ１はＣＯ２と相互作用し、ＣＯ３はＣＯ４と相互作用し、ここで、ＣＯ２とＣＯ４は、テレコム・システム・ドメインに属している。
最初に、ＣＯ１が、ＣＯ２に対する動作OpX()を要求すると仮定する。この動作要求は、TD_UAa1に対する動作Call(CO2.OpX())に変換する。TD_UAa1オブジェクトは、次にテレコム・システム・ドメイン内のそのピア・オブジェクトPD_UAaに対する等価の動作Call(CO2.OpX())を呼び出し、そしてこれは、さらに、その要求をＣＯ２に配信する。これは、困難を伴わずに行えるが、それは、TD_UAa1がPD_UAaの識別子を知っているからである。同様に、ＣＯ３は、何の問題もなく、ＣＯ４に対する任意の動作を呼び出すことができる。この既存の機構は、ユーザ・ドメインから開始させる呼び出しをサポートするには十分である。その逆、すなわちオブジェクトＣＯ２がＣＯ１に対する動作を呼び出すこと、またはオブジェクトＣＯ４がオブジェクトＣＯ３を呼び出すことは、追加の情報および機能を必要とする。
次に、ＣＯ２がＣＯ１に対する動作OpY()を要求すると仮定する。再び、この動作要求は、PD_UAaに対する動作Call(CO1.OpY())に変換する。ここでの問題は、PD_UAaがどの端末上にＣＯ１が位置しているかを知らないことである。これが、その動作要求をTD_UAa1に転送すべきかあるいはTD_UAa2に転送すべきかを判断することができない。PD_UAaは、Useraが両端末、すなわちTerminalnとTerminalmとに登録されているとの情報しか保有しておらず、Useraの各オブジェクトのロケーションに関する知識を全く有していない。したがって、そのような情報は、それに供給しなければならないことは明かである。
したがって、テレコム・システム・ドメイン上のオブジェクトからの要求を受けることを希望するユーザ・ドメイン内のどのオブジェクトも、テレコム・システム・ドメイン内の何等かのオブジェクトにより登録されねばならず、それにより、PD_UAaオブジェクトが、そのユーザ・オブジェクトのロケーションを得るために照会することができねばならない。この情報を記憶させるのに都合の良い場所は、User_Registrationaオブジェクトとなる。
ユーザ・エージェントTD_UAa1とTD_UAa2とには、端末ドメイン内のユーザ・オブジェクトの登録を可能にする追加の動作を装備しなければならない。このような動作、例えばObjRegは、次のようなIDL/ODL仕様を有することができ、これにおいて、IDLは、ＣＯＲＢＡにおいて定義されたインターフェース定義言語として定義され、ODLは、オブジェクトの定義を可能にするIDLの拡張［ＴＩＮ９５ｈ］であるＴＩＮＡ−Ｃにより定義された、オブジェクト定義言語として定義される。
ObjReg（in ObjectId objectname，in objectId useragentname）objectnameは、登録されたオブジェクトの計算インターフェース識別子である。
useragentnameは、そのオブジェクトがどこに登録されるかについてのユーザ・エージェントの計算インターフェース識別子である。この引数は、登録がローカルに行われるときには必要でなく、したがって空となることがある。
ユーザ・エージェント（ＣＯ１またはＣＯ３）のこの登録は、ユーザ・オブジェクト自身によりあるいは何等かのプロキシ（proxy）・オブジェクトにより行うこともできる。
オブジェクトＣＯ１のための登録プロシージャは、図１８に示している。ユーザ・エージェント（TD_UAおよびPD_UA）は、登録情報をUser_registrationオブジェクトへ渡すためのリレーとして作用する。
TD_UAは、動作要求ObjReg(objectname,TD_UAname)を受けると、そのピア・オブジェクトPD_UAに対する動作UserObjReg(objectname，TD_UAname)を呼び出す。PD_UAは、さらに、同様の動作UserObjReg(objectname，TD_UAname)をそのUser_registrationオブジェクトに対し呼び出す。User_registrationオブジェクトは、この要求を受け取ったとき、オブジェクト登録情報をセーブする。したがって、その記憶能力は、そのような情報を包含するように拡張されねばならない。この内部データ構造は、種々の異なった方法で実施することができる。図１７には、その１例を示している。主テーブルの各行について、１つの端末において登録された全てのオブジェクトの識別子を含むObjectListを割り当てている。この機能をさらに強化するため、多数オブジェクト登録動作も、オブジェクトTD_UA、PD_UA、User_Registrationの各々に対し定義することもできる。
オブジェクトは、登録解除することもできる。オブジェクト登録解除のためのプロシージャ、並びにこの所要の動作は、登録に対するものとかなり類似したものである。動作UserObjDereg(objectname，TD_UAname)の受け取り時に、User_Registrationは、対応するObjectListをフェッチし、そしてその指定されたオブジェクトの識別子を除去する。主テーブルの１つの行を除去するとき、すなわち１つの端末についてのユーザ登録解除を実行するとき、対応のObjectListも削除する。
オブジェクトの登録動作および登録解除動作に加えて、User_registrationオブジェクトはまた、他のオブジェクトがオブジェクト登録情報を要求するために使用することのある動作GetObjReg(in ObjectId objectname，out ObjectId useragentname)も有しなければならない。
ＣＯ１にアドレスされたＣＯ２からの動作要求Call(CO1.OpY())を受け取ったときで、かつＣＯ１がテレコム・システム・ドメイン内にないとき、PD_UAaは、GetObjReg(CO1，AgentToCall)をそのUser_Registrationオブジェクトに対し呼び出す。TD_UAa1の識別子は、パラメータAgentToCallにおいて返す。PD_UAaは、TD_UAa1に対するCall(CO1.OpY())の呼び出しに進むことができる。この動作は、最終的にはTD_UAa1まで伝達し、そしてTD_UAa1はＣＯ１に対するOpYを呼び出す。この結果は、ＣＯ２へ戻るその同じ経路を使って返す。
発明の効果
・本発明は、分散システムにおいてユーザ移動性を提供する。
・本発明は、極めてフレキシブルであるが、それは、エージェント技法を使用し、これが、エージェントの内部実装の変更を、システムの残りの部分に対し影響を及ぼさずに可能にするからである。
・本発明は、固定あるいは移動であろうと、パブリックまたはプライベートであろうと、ローカル・エリアあるいはワイド・エリアであろうと、有線または無線であろう、任意のタイプのネットワークにおいて使用することができる。
・本発明は、何人かのユーザに同じ端末を使用できるようにもする。
・また、本発明は、一人のユーザに、いくつかの端末を同時に使用できるようにもする。
・本発明は、異なったユーザに属するオブジェクトを記録し分離することにより、ユーザのプライバシーを確保する。
【図１】
0004234210.tif 000002
【図２】
0004234210.tif 000003
【図３】
0004234210.tif 000004
【図４】
0004234210.tif 000005
【図５】
0004234210.tif 000006
【図６】
0004234210.tif 000007
【図７】
0004234210.tif 000008
【図８】
0004234210.tif 000009
【図９】
0004234210.tif 000010
【図１０】
0004234210.tif 000011
【図１１】
0004234210.tif 000012
【図１２】
0004234210.tif 000013
【図１３】
0004234210.tif 000014
【図１４】
0004234210.tif 000015
【図１５】
0004234210.tif 000016
【図１６】
0004234210.tif 000017
【図１７】
0004234210.tif 000018
【図１８】
0004234210.tif 000019