JP5312342B2 - ハンドオーバ・コンビニエンス・インフォメーション・サービス（ｈａｎｄｏｖｅｒｃｏｎｖｉｎｉｅｎｃｅｉｎｆｏｍａｔｉｏｎｓｅｒｖｉｃｅ（ＨＯＣＩＳ）） - Google Patents

ハンドオーバ・コンビニエンス・インフォメーション・サービス（ｈａｎｄｏｖｅｒｃｏｎｖｉｎｉｅｎｃｅｉｎｆｏｍａｔｉｏｎｓｅｒｖｉｃｅ（ＨＯＣＩＳ）） Download PDF

Info

Publication number
JP5312342B2
JP5312342B2 JP2009538650A JP2009538650A JP5312342B2 JP 5312342 B2 JP5312342 B2 JP 5312342B2 JP 2009538650 A JP2009538650 A JP 2009538650A JP 2009538650 A JP2009538650 A JP 2009538650A JP 5312342 B2 JP5312342 B2 JP 5312342B2
Authority
JP
Japan
Prior art keywords
hocis
ptkv
tln
terminal system
network
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2009538650A
Other languages
English (en)
Other versions
JP2010511335A (ja
JP2010511335A5 (ja
Inventor
シンドラー，シグラム
シェーンベルグ，デルテ
シュルツェ，ヨーガン
Original Assignee
シグラム シンドラー ベタイリグンクスゲゼルシャフト エムベーハー
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by シグラム シンドラー ベタイリグンクスゲゼルシャフト エムベーハー filed Critical シグラム シンドラー ベタイリグンクスゲゼルシャフト エムベーハー
Publication of JP2010511335A publication Critical patent/JP2010511335A/ja
Publication of JP2010511335A5 publication Critical patent/JP2010511335A5/ja
Application granted granted Critical
Publication of JP5312342B2 publication Critical patent/JP5312342B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0083—Determination of parameters used for hand-off, e.g. generation or modification of neighbour cell lists
    • H04W36/0085—Hand-off measurements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0055—Transmission or use of information for re-establishing the radio link
    • H04W36/0058—Transmission of hand-off measurement information, e.g. measurement reports
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W68/00—User notification, e.g. alerting and paging, for incoming communication, change of service or the like
    • H04W68/12—Inter-network notification

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Description

本発明は、ＨＯ（ハンドオーバ）が行われる１次通信プロセス（すなわち１次遠隔通信プロセス、すなわち１次ＴＫプロセス（ＴＫはテレコミュニケーション、遠隔通信の省略形）すなわちＰＴＫＶ）の加入者（省略形ＴＬＮ）のための、自動的かつネットワーク透過的な「ハンドオーバ・コンビニエンス・インフォメーション・サービス」法（ＨＯＣＩＳ法）を開示する−このＨＯプロセスは、「本来のＨＯ」に属する任意の先行／後続時間を含む場合がある。
「コンビニエンス・インフォメーション・サービス」はこの場合特に、このＰＴＫＶ−ＴＬＮがこのＨＯＣＩＳを必ずしも要求していないのに、この要求されていないサポートを快適または役に立つと感じるサービスを言う。それはあたかも、例えば航空機の乗客が、その出発または到着する空港で、付随するアナウンス、指示、注意（＝コンビニエンス・インフォメーション・サポート）をそのように感じるのと同様である。しかしそのようなしばしば画一的な措置とは異なって、ＨＯＣＩＳは、それを受ける人が、通常は個別の状況に合わせて形成することができる。このようなＰＴＫＶ−ＴＬＮのＨＯＣＩＳは、そのＨＯプロセスの間、この本来のＨＯ−それは将来起こりうるもの、その時点におけるもの、あるいは過去のものであり得る−に関する情報を当人に転送することによって行われる。またこの情報は、少なくとも１つの２次ＴＫプロセス（略してＳＴＫＶ）の少なくとも１つのシステムにおける少なくとも１つの人ではないモジュールＭ（ＨＯＣＩＳ）によって、これらのＴＬＮのために準備されたものである。
Ａ．従来のＨＯ技術とこのＨＯＣＩＳ法の革新的特性とを比較する
従来のＨＯ技術は、ＨＯを矮小化してその技術的核心だけのプロセスとして見ている。すなわち従来の技術が着目するのは下記の通り。
（ａ）そのＨＯに直接かかわる端末システム、および場合によってはそのユーザだけに着目する−いずれにせよ、（将来起こりうる、またはその時点の、または過去の）ＨＯに間接的にかかわる端末システムユーザは、直接かかわる端末システムから情報を受けない−そして／または、
（ｂ）端末システムのＨＯという点では、その「基本的な接続性」だけに着目する−同様に端末システムのユーザがネットワークにログインするとき、そのユーザの「アプリケーション接続性」も、いずれにせよ着目されない−そして／または、
（ｃ）端末システムのＨＯを、そのための技術的設定に基づく「ファイナル・セルフランナ」としてのみ着目する−すなわち、任意に早期開始して、かついつでも端末システムユーザが動的に形成できるプロセスとしては、そしてまたこのユーザがこのＨＯをまったく回避する場合もあるプロセスとしては、着目しない。
それに対してこのＨＯＣＩＳ法は、−将来起こりうる、またはその時点の、または過去のＨＯに対して−従来のＨＯ技術のＨＯ法の、上記（ａ）〜（ｃ）で除外された３つの特性を実現する。
このＡ章では、上記最後の段落の言明が正しいことを示すため、実際に上記ＨＯ法のいずれもが、（ａ）で除外されていると主張される特性だけでさえも、それを実現しないことを示す。したがって本章は、（ｂ）および（ｃ）で除外されていると主張される諸特性が実現されていないことの証明を行う必要はない。しかしこれらの諸特性は、従来のＨＯ技術を大きく超えているので、これら諸特性が実現されていないことの証明は根本にかかわる−しかしその証明を詳細に述べるのはきわめて労大きい。なぜならば、従来のＨＯ技術においては、これら諸特性に対する言及がほとんどないからである。そのような言及があれば、そこから上記の証明を開始して、一貫的かつ全体的に証明を行うことができるところであるが。
通信プロセスのハンドオーバ（ＨＯ）を、それ自体として見ると下記の通り。
■特にパケット交換による、および回線交換によるＴＫネットワーク間のものは、すでに特許ＤＥ１９６４５３６８およびＥＰ０９２９８８４の保護範囲に属する。しかし両特許とも、本発明が解決する「ＨＯインフォメーション／サポート」問題についてはまったく言及しない：すなわち、通信プロセスの少なくとも１人の加入者が、他の加入者におけるＨＯによっていら立つ場合があり、それはその加入者が、この通信プロセスにおいてデータ伝送に、何らかの−加入者にはまったく理解できない−損害（例えば中断／遅延／品質変化／費用の変化等々）を受けるからであるということについて、まったく言及しない。その結果としては、上記の両文書は、この問題に何の解決も試みない。しかし本発明によるＨＯＣＩＳ法からは、この問題を解決する技術が得られる。それを後に説明する。
■特に「シームレス（ｓｅａｍｌｅｓｓ）なＭＩＨ」（＝「Ｍｅｄｉａ Ｉｎｄｅｐｅｎｄｅｎｔ ＨＯ」）−これはＴＫプロセスのＴＬＮには感知できない−は、ＵＳ２００６／００９９９４８Ａ１が、電話通話に関するものについて議論している。この特許の背景技術の項と本発明による方法の説明の項は、従来の技術を正しく説明している。そしてヴィヴェク・グプタらによる「ＩＥＥＥ８０２．２１概観出版物」（ＤＣＮ２１−０６−０７０６−００−００００）は、ＨＯ実現の様々な技術的バリエーションについて、上記文書よりも広範囲に議論している。従来のＨＯ技術に関する最新の出版物−例えばＷＯ２００７／００４８４６Ａ２およびＷＯ２００６／１２４５１４Ａ２−でも、ＭＩＨへの注目が強調されている。
これらすべての文書に明記されているのは、従来のＨＯ技術すべてにおいて、ＨＯに際してＰＴＫＶのＴＬＮに生じ得る上記のいら立ちについてである。
○上記のいら立ちは、−ＨＯでいかなるＨＯ技術が用いられようと−従来のＨＯ技術によっては問題を解決できないため、独自の解決法を必要とするような、独自の問題とは見なされていない。そして、
○ましてや、少なくとも１つの追加的かつ独自の「２次通信プロセス」、すなわち「２次ＴＫプロセス」（ＳＴＫＶ）あるいは「ＨＯＣＩＳ通信プロセス／ＴＫプロセス」を必要とすることにはならず、その際場合によっては「ＨＯＣＩＳサーバ」を援用することにはならない。
したがって従来のＨＯ技術は、ＨＯＣＩＳ法の形態を取る本問題解決法と、何ら関係のないものである。
■通信プロセスのハンドオーバは、特にＯＳＩ参照モデル（ＯＳＩ＝ｏｐｅｎ ｓｙｓｔｅｍｓ ｉｎｔｅｒｃｏｎｎｅｃｔｉｏｎ）のＬ７層で実現され−上記の「ＩＥＥＥ８０２．２１概観出版物」で徹底的に言及されている−Ｌ．−Ｊ．ＣｈｅｎのＵＳＨＡモデル（ＵＳＨＡ＝Ｕｎｉｖｅｒｓａｌ Ｓｅａｍｌｅｓｓ Ｈａｎｄｏｖｅｒ Ａｒｃｈｉｔｅｃｔｕｒｅ）のアーキテクチャによって可能である（ＵＣＬＡ Ｃｏｍｐｕｔｅｒ Ｓｃｉｅｎｃｅ Ｄｅｐａｒｔｍｅｎｔ Ｔｅｃｈｎｉｃａｌ Ｒｅｐｏｒｔ ＣＳＤ−ＴＲ Ｎｏ． ０４００１２）。しかしこのＵＳＨＡモデルは、いわばＨＯ実現の技術だけに限定されている：したがってこのモデルは、本発明によるＨＯＣＩＳ法とは、やはりまったく無関係である−その理由は、前記の列挙事項ですでに概略を述べたが、後に詳細に説明する。
■また、今日まで多くの注目を集めているものとして、Ｓｔｅｆａｎｏｖ（２１．１１．２００６：「Ｅｎｔｗｕｒｆ ｕｎｄ ｌｍｐｌｅｍｅｎｔｉｅｒｕｎｇ ｅｉｎｅｒ Ｖｉｓｕａｌｉｓｉｅｒｕｎｇｓｓｏｆｔｗａｒｅ ｆｕｅｒ ‘Ｓｅａｍｌｅｓｓ Ｈｏｎｄｏｖｅｒ’ ｉｎ ｄｒａｈｔｌｏｓｅｎ Ｎｅｔｚｅｎ」）およびＳｏｎｎｅｎｂｅｒｇ（２７．０６．２００５：「Ｓｅａｍｌｅｓｓ Ｖｅｒｔｉｃａｌ Ｈａｎｄｏｆｆ」）の著作の記載がある。著者たちは、ＨＯＣＩＳ法によって解決された問題が「ＨＯ技術の手の届かないところ」にあって、従来のＨＯ技術によっては解決できないことを−特に従来のＨＯ技術の概略を−再度確認した。解決できない原因は、ここで参照されている従来のＨＯ技術が、「通信プロセスの加入者のＨＯ問題」は、ＨＯ技術的方法によっては、すなわち「シームレスＨＯ」によってはもともと不可避であるという想定に、基づいているためである。
■通信プロセスのハンドオーバは、Ｂｉｒｎｉｅらの特許（２７．０２．２００７、ＵＳ７，１８４，７６５，Ｂ１）、およびＢａｒｔｌｅらの特許（２５．０１．２０００、ＵＳ６，０１８，６５５。２４．０３．１９９８、ＵＳ５，７３２，３４７。２４．０２．１９９８、ＵＳ５，７２２，０６８）の対象物でもある。これらの特許はすべて確かに、接続遮断前、または携帯型端末システムのＨＯの間、またはその後において−その理由のいかんにかかわらず−端末システムユーザに対して音響信号を与える。しかし、このプロセスに直接かかわる端末システムユーザのＨＯＣＩＳに関しては、これらの特許は何も開示せず、このようなユーザについてはこれら特許に何ら記載されていない。
■またこのハンドオーバは、間接的にかかわる通信プロセスの加入者の副次的な「有用情報」が付随するものについて、Ｇ．Ａ．Ｍｉｌｌｓ−ＴｅｔｔｅｙおよびＤ．Ｋｏｔｚの著作が議論している（Ｍｏｂｉｌｅ Ｖｏｉｃｅ ｏｖｅｒ ＩＰ（ＭＶＯＩＰ）：Ａｎ Ａｐｐｌｉｃａｔｉｏｎ−ｌｅｖｅｌ Ｐｒｏｔｏｃｏｌ ｆｏｒ Ｃａｌｌ Ｈａｎｄ−ｏｆｆ ｉｎ Ｒｅａｌ Ｔｉｍｅ Ａｐｐｌｉｃａｔｉｏｎｓ，Ｐｒｏｃ．ｏｆ ｔｈｅ 「２１．ＩＥＥＥ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｐｅｒｆｏｒｍａｎｃｅ，Ｃｏｍｐｕｔｉｎｇ，ａｎｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｃｏｎｆｅｒｅｎｃｅ」，Ａｐｒｉｌ ２００２）。この著作は、モビリティから生じる特殊なＨＯ問題に対して、「Ｍｏｂｉｌｉｔｙ Ａｌｅｒｔ Ｍｅｓｓａｇｅ」をもって始まる解決法を開発することにより、従来のＨＯ技術を、従来の純技術的方向においてさらに発展させている（この著作の第３．１項および３．２項を参照）。このメッセージは確かにＨＯ関連情報ではあるが、直接かかわらない「ｈｏｓｔ ｓｙｓｔｅｍ」のためのものであって、ホストシステムのユーザのためのものではない−すなわちＨＯにおいてそのホストシステムの反応が早すぎないようにするためのものである（なぜならば加入者データ伝送のためのＬ３接続が、ＩＰ番号切り替えのため一時的に中断するからである）。ＭＶＯＩＰ−ＰＤＵ（Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ）の受信は、オプションとして確かに「ｕｓｅｆｕｌ ｍｅｓｓｓａｇｅ ｔｏ ｔｈｅ ｕｓｅｒ ｄｕｒｉｎｇ ｔｈｅ ｈａｎｄ−ｏｆｆ ｐｒｏｃｅｓｓ」の作動を生じる。しかしこのメッセージの意味内容は、ＨＯＣＩＳにおけるものとは別物である。この特殊なＭＶＯＩＰ−ＰＤＵ、すなわち「Ｍｏｂｉｌｉｔｙ Ａｌｅｒｔ」メッセージは、実際に少なくとも次の７つの点で、ＨＯＣＩＳとはそれぞれ根本的に異なる。それを下記に示す。
◆第１には、
○ＨＯＣＩＳ法のＨＯ関連情報は、ＨＯＣＩＳ端末システムのユーザをサポートするため同ユーザに向けられる。ＭＶＯＩＰ法で行われるように、ユーザが利用する端末システム（「ホスト」システムと呼ばれる）に向けられることはなく、端末システムをサポートすることもない。すなわち、例えば電話する人に向けられるのであって、その電話機に向けられるのではない。
○この種のＨＯ関連情報は、（この情報を伝達する端末システムの）ユーザに、送信側の機器によって決定されたＨＯシチュエーション固有の意味内容を伝達する。この意味内容は、ＩＰ番号切り替えとは何の関係もない−このことは、ＭＶＯＩＰ法の「Ｍｏｂｉｌｉｔｙ Ａｌｅｒｔ」によっては不可能である。
○受信された本発明ＨＯ関連情報のコーディング、および／または伝送、および／またはプレゼンテーションは、加入者の受信機システムにおいて、加入者が行うことができる−これもＭＶＯＩＰ法では不可能である。なぜならば、ＨＯ関連情報の前記内容がまったく存在しないからである（その理由は、前記列挙各項目に記載した）。
したがって本発明による同等なＨＯ関連情報が、個々のＨＯステータスに関する情報によって、ＨＯに直接かかわるＰＴＫＶ−ＴＬＮのＨＯＣＩＳに用いられる。このステータス情報は、他の端末システムから加入者に伝達してあったものである。それに対して、「Ｍｏｂｉｌｉｔｙ Ａｌｅｒｔ」ＰＤＵは、それとはまったく別の目的に用いられる：このＰＤＵは、（ＨＯに「間接的に」かかわる）ホストシステムの制御に用いられ、このシステムのユーザは、この場合まったく何の役割も果たさない。直接かかわる端末システムによっては内容的に決定されない、ユーザ宛のローカルな「ｕｓｅｆｕｌ ｍｅｓｓａｇｅ」は、この状況に何の変化も生じない−このメッセージは、ＨＯＣＩＳ法によるＨＯ関連情報ではない。
◆第２には、本発明によるＨＯ関連情報のためには、ＭＶＯＩＰ−／「Ｍｏｂｉｌｉｔｙ Ａｌｅｒｔ」−ＰＤＵに対して絶対的に閉じられている伝送経路−すなわち加入者データが利用する伝送経路−が存在する。したがってこのことも、このＰＤＵがＨＯＣＩＳ法によるＨＯ関連情報でないことを示す。
すなわち特には、ＨＯＣＩＳ法の場合−ＭＶＯＩＰ法の場合とは異なって−受信側ホストシステムは、受信できるようにするため、通信プロセスにおいて、このようなＨＯ関連情報を受信したかどうか、耳を澄ます必要はない（「ｌｉｓｔｅｎ」は、例えば今日の携帯型電話機は通話中不可能である）。
○むしろこのようなＨＯ関連情報は、そのターゲット端末システムから常に受信され（あるいはこのシステムによってローカルに準備され）、そして加入者に必ず通知される−すなわちＭＶＯＩＰ法の際のような「ホスト」の受信指向の関与が行われることがない。
○ましてこの場合、受信側ホストシステムは、ＨＯＣＩＳ法の場合、その「プロトコルスタック」の１つをアドレス指定する特定のＰＤＵに耳を澄ます必要がない。したがって、
○本発明によるＨＯＣＩＳ法は、今日の携帯型電話機ユーザをもサポートすることができる。これはＭＶＯＩＰ法には絶対不可能なことである。
◆第３に本発明によるＨＯＣＩＳは、ＨＯに間接的にかかわるＰＴＫＶ−ＴＬＮに、任意のその時点の、または将来起こりうる、または遡及されたＨＯについてＨＯ関連情報を、直接かかわる端末システムに請求する可能性を与える。ＭＶＯＩＰ法は、この種の可能性を何ら提供しない。このこともまた、ＭＶＯＩＰ−ＰＤＵがＨＯＣＩＳ法によるＨＯ関連情報を何ら含まないことを示す。
◆第４にＭＶＯＩＰ法は、その可能性あるスタート時点に関しても、ＨＯＣＩＳ法とはまったく比較にならない。ＭＶＯＩＰ法は、携帯型（すなわち直接かかわる）端末システムがＩＰアドレス切り替えを行うまさにそのときに、スタートされる。ＨＯＣＩＳ法が正確にこの時点にスタートする可能性は排除されている−ＨＯＣＩＳ法は常により早期にスタートする。なぜならばＨＯＣＩＳ法は、そのスタート時にＩＰアドレス切り替えが行われて初めて、課された要求を満足できなくなるからである。ＨＯＣＩＳ法は、ＨＯがこのように非常に遅い技術手法にはまったく依存せず、常にＩＰアドレスがまず同じ状態であるときにスタートされる。なぜならばネットワークの何らかの利用品質が変化し（例えばネットワークの利用コストまたはジッタ）、あるいは品質安定を求めるユーザの予防的要求が、通信プロセス中に自然発生的に生じるからである。あるいはＩＰアドレス切り替えが行われても、ＨＯＣＩＳ法がまったくスタートされない（なぜならばＨＯＣＩＳ法は、シームレスなＨＯがまもなく行われることを、前もって知っているからである）。このこともやはり、ＭＶＯＩＰ−ＰＤＵが、ＨＯＣＩＳ法によるＨＯ関連情報であり得ないことを示す。
◆第５にＭＶＯＩＰ法は、ＨＯＣＩＳ法に適合された信号−この信号は、ＰＴＫＶの端末システム外で生じ、そして／または同システム外に存在することができることを特性とする−を明示的に除外し（ＭＶＯＩＰ法はそもそもＳＴＫＶというものに関知しない）、したがってＰＴＫＶ−ＴＬＮのＨＯＣＩＳのあらゆる可能性を除外する。
◆第６にＭＶＯＩＰ法は、そのＰＴＫＶ−ＴＬＮがＨＯ関連情報を携帯型端末システム以外のものから得ることを、明示的に除外する−同法はこのような情報を使用する必要があっても、それをＴＬＮに伝達できない−しかしＨＯＣＩＳ法ではこれが意図されている。
◆第７にＭＶＯＩＰ法は、ＭＶＯＩＰ−ＰＤＵなどが、ＨＯに直接かかわるＰＴＫＶ−端末システムに送信され、同システムのＴＬＮがそれについて知らせを受けることを、明示的に除外する−しかしＨＯＣＩＳ法は、直接かかわるＴＬＮにＨＯ関連情報を伝達するのに適している。
この７つの相違点だけでも、ＭＶＯＩＰ法がＨＯＣＩＳ法−ここでは、間接的にかかわるＰＴＫＶ−ＴＬＮのためのＨＯＣＩＳ生成の方法−を、いかなる点でも先取りしていないことと、ＭＶＯＩＰ法が、（その印刷物に開示されていないだけの）ＨＯＣＩＳ法の特殊ケースではないことを示している：すなわちＭＶＯＩＰ法の「Ｍｏｂｉｌｉｔｙ Ａｌｅｒｔ」メッセージは、通信技術上場合によっては有意義な、かつＴＬＮには視認不可能な、多くのＨＯＣＩＳプロトコルパラメータ、すなわちＨＯＣＩＳ法の本発明による実施形態における同パラメータの１つという意味を持つだけである。しかもこのパラメータは、かかわりを持つ加入者のその時点におけるＨＯ、または将来起こりうるＨＯに関しては、１次ＴＫプロセスのＴＬＮのＨＯＣＩＳと何の関係もない。−ここではこのパラメータに着目しない。
従来のＨＯ技術との比較を要約して、技術的重要部分に注目すると：ＯＳＩ接続においてＨＯに含まれる「サービス連続性」は下記のようにして求められる。
■従来のＨＯ技術の場合、まずこのＯＳＩ接続のユーザに対して−いずれにせよＨＯに間接的にかかわるユーザに対して−このＨＯを隠すことによって、ＨＯメカニズム的方法で、上記「サービス連続性」が求められる。このＯＳＩ接続を利用するＰＴＫＶ−ＴＬＮが単純な自動機械に過ぎない場合、これらの自動機械は、今日では通常このような手順に依存する−すなわちサービス連続性は、ここではＰＴＫＶのＯＳＩ接続のモジュール内部で（すなわち大部分がモジュールのＬ２層で）生成されなければならない。さもなければサービス連続性は、そのユーザ自動機械のために設けられる必要はない−例えば人間のようなＨＯを理解するＴＬＮには必要がない。
■ＨＯＣＩＳ法の場合、（このＯＳＩ接続の）ＰＴＫＶ−ＴＬＮでこのＨＯが適切に意識されることによって、すなわちこれらＴＬＮの「ＨＯ理解に基づく」方法によって求められる。ＨＯを理解するＰＴＫＶ−ＴＬＮ例えば人間が、このＰＴＫＶのＯＳＩ接続を利用する場合、ＴＬＮはしばしばこの手順に依存する。そうするとこれらＴＬＮは、単純な自動機械とは心理的にしばしばまったく異なる構造となる。例えばＨＯを理解するＰＴＫＶ−ＴＬＮ、例えば人間は、このＨＯが実際に行われる前に、ＨＯ関連情報を必ず得たいかもしれない。そして／または単純な自動機械よりも、それに弾力的に反応できることを望むかもしれない−その結果として、独自の２次−／ＨＯＣＩＳ−ＴＫプロセスが通信技術的にもたらされ、このプロセスは、ＰＴＫＶおよびＨＯプロセスといずれにせよ時間的にオーバラップして、ＰＴＫＶ−ＴＬＮのためＨＯＣＩＳをもたらす。するとこのようなＳＴＫＶは、少なくとも１つのＨＯＣＩＳシステムを、このサービス連続性の獲得に関与させることができる−これは例えば間接的にＨＯにかかわるＰＴＫＶ−ＴＬＮへのＳＴＫＶの連続性、かつ多くの場合早期に開始され、そして／またはより長く維持される当該連続性をともなう。この連続性は、ＰＴＫＶ−ＴＬＮに都合よくＨＯ関連情報を供給できるようにして、このＴＬＮにサービス連続性を保証する。
したがってこのサービス連続性は、ＰＴＫＶ−ＴＬＮにおいてその要求に応じて、少なくとも１つのＳＴＫＶを用いて生成される−その他の方法ではＴＬＮにこのサービス連続性を保証できない−すなわちこれは、ＰＴＫＶのＯＳＩ接続のモジュール外部で生成される場合である。
上記前者の場合、すなわち従来のＨＯ技術によって求められたシームレスなＭＩＨの場合、ユーザのＰＴＫＶ−ＯＳＩ接続でＨＯが行われるとき、ユーザの端末システムにおいて、このように理解されたサービス連続性を保証するためＨＯＣＩＳを行って、このＰＴＫＶ−ＴＬＮが不利な損害を受けるのを、このＨＯによって回避することは、純理論的には余計なこととされる場合もあろう。しかしこの工学技術的文脈の中で「純理論」とは何のことかは、誰でも知っている−純理論とはしばしば「足音だけが大げさな」ものである（この点については第Ｂ章の最後から３番目の段落参照）。
それとは反対に、本発明によるＨＯＣＩＳ法は、ＰＴＫＶにおけるＨＯの際、次のことを生じる。すなわち、少なくとも１人／１つのＰＴＫＶ−ＴＬＮ、すなわち（このＰＴＫＶのＯＳＩ接続において）それにかかわる端末システムのユーザが、少なくとも１つのＨＯ関連情報を、ほかでもない「コンビニエンス・インフォメーション・サポート」のため、このＨＯを経由して／に際して受け取る−このＨＯがＰＴＫＶに不利な損害を与えないよう、あるいはＰＴＫＶ−ＴＬＮがＨＯをよりよく形成できるよう、あるいは回避できるよう、あるいはその種のことができるようにするためである（ここで用いられた用語法については、第Ｂ章参照）。
換言するならば、ＨＯＣＩＳ法は、ＰＴＫＶ−ＴＬＮの理解レベルで、ＨＯにおける「サービス連続性」を得る（そして、技術的方法によってこれらのＴＬＮに対してＨＯを隠すことができるという、従来のＨＯ技術の大部分による錯覚を内蔵する要求、または「ｗｉｓｈｆｕｌ ｔｈｉｎｋｉｎｇ」を放棄する）。そのため本方法は、少なくとも１つのＨＯＣＩＳサーバ／ＩＡＤ（Ｉｎｔｅｇｒａｔｅｄ Ａｃｃｅｓｓ Ｄｅｖｉｃｅ）／端末システムにおける少なくとも１つの人ではないＭ（ＨＯＣＩＳ）モジュール（図５に記載）を用いて、ＨＯをこの目的に使用する（特に第Ｄ章参照）。
したがってＨＯＣＩＳ法は、その目的方向のため、技術的通信における「コンビニエンス」技術の未来分野、そしてまさに初めて開発された分野に属する。すなわちその意図性において、「ＨＯ技術」の古典的分野には属さない。ＨＯＣＩＳ法は、そのようなＨＯ技術と共通するものはない。その理由を下記に述べる。
■本方法は、ＨＯによってＰＴＫＶ−ＴＬＮに生じる将来起こりうる、またはその時点で生じている心理的な問題を解決できるようにする。そのため本方法は、適切な時点および表示において、ＨＯにかかわるＰＴＫＶ−ＴＬＮに「コンビニエンス・インフォメーション・サポート」が与えられることを可能にする。
■しかし本方法は、ＰＴＫＶ端末システムにＨＯを生じることができる方法−すなわち技術的に単純な問題を解決できる方法−ではなく、上記の漠然とした心理的問題を解決するのに必要な技術的複雑性を具現するものである。
ＨＯＣＩＳ法のこの大きな技術的複雑性については、特に第Ｄ章、さらに特には図５の説明に記載する。
独国特許発明第１９６４５３６８号明細書 欧州特許第０９２９８８４号明細書 米国特許出願公開第２００６／００９９９４８号明細書 国際公開第２００７／００４８４６号パンフレット 国際公開第２００６／１２４５１４号パンフレット 米国特許第７１８４７６５号明細書 米国特許第６０１８６５５号明細書 米国特許第５７３２３４７号明細書 米国特許第５７２２０６８号明細書
ヴィヴェグ・グプタ他著、「ＩＥＥＥ８０２．２１概観出版物」、（ＤＣＮ２１−０６−０７０６−００−００００） Ｌ．−Ｊ．Ｃｈｅｎ著、「ＵＣＬＡ Ｃｏｍｐｕｔｅｒ Ｓｃｉｅｎｃｅ Ｄｅｐａｒｔｍｅｎｔ Ｔｅｃｈｎｉｃａｌ Ｒｅｐｏｒｔ ＣＳＤ−ＴＲ Ｎｏ． ０４００１２」 Ｓｔｅｆａｎｏｖ著、「Ｅｎｔｗｕｒｆ ｕｎｄ ｌｍｐｌｅｍｅｎｔｉｅｒｕｎｇ ｅｉｎｅｒ Ｖｉｓｕａｌｉｓｉｅｒｕｎｇｓｓｏｆｔｗａｒｅ ｆｕｅｒ ‘Ｓｅａｍｌｅｓｓ Ｈｏｎｄｏｖｅｒ’ ｉｎ ｄｒａｈｔｌｏｓｅｎ Ｎｅｔｚｅｎ」、（２１．１１．２００６） Ｓｏｎｎｅｎｂｅｒｇ著、「Ｓｅａｍｌｅｓｓ Ｖｅｒｔｉｃａｌ Ｈａｎｄｏｆｆ」、（２７．０６．２００５） Ｇ．Ａ．Ｍｉｌｌｓ−Ｔｅｔｔｅｙ、Ｄ．Ｋｏｔｚ著、（Ｍｏｂｉｌｅ Ｖｏｉｃｅ ｏｖｅｒ ＩＰ（ＭＶＯＩＰ）：Ａｎ Ａｐｐｌｉｃａｔｉｏｎ−ｌｅｖｅｌ Ｐｒｏｔｏｃｏｌ ｆｏｒ Ｃａｌｌ Ｈａｎｄ−ｏｆｆ ｉｎ Ｒｅａｌ Ｔｉｍｅ Ａｐｐｌｉｃａｔｉｏｎｓ，Ｐｒｏｃ．ｏｆ ｔｈｅ 「２１．ＩＥＥＥ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｐｅｒｆｏｒｍａｎｃｅ，Ｃｏｍｐｕｔｉｎｇ，ａｎｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｃｏｎｆｅｒｅｎｃｅ」，Ａｐｒｉｌ ２００２）
Ｂ．ＨＯＣＩＳ法の用語／概念および本質
ＨＯＣＩＳ法は、今日の姿の無線通信ネットワークを利用する際に、ＨＯを「コンビニエント」にするためのものである。より詳しく言うと、本方法は、同ネットワークのユーザに簡単な方法で快適な確実性を伝達できるようにする。ＨＯＣＩＳ法は−今日では通常このネットワークの外部で行うものである−ネットワークを使用するとき、ネットワーク間において、将来起こりうるＨＯあるいはその時点の避けられないＨＯに、「粗さ」が生じる可能性があるとき、それを持続的にかつ快適な方法でネットワークに知らせ、ネットワークをサポートする。
したがって今のところ下記について予測できないということだけからも、ＨＯＣＩＳ法の魅力が生じる。
■例えば電話通話におけるＨＯにとって問題となる現在の無線ＴＫネットワークすべてが、現在議論されている「シームレスＨＯ」法の１つを、いつ可能とするか。
■これら「シームレスＨＯ」法は、通信プロセスの加入者にとって、実際に完全に透過的（＝感知不可能／妨害とならない）となるかどうか。
■市場がこれらの（もしかしたら単に憶測上の）「シームレスＨＯ」法を−ＨＯがコスト変化を含意するにもかかわらず、ＨＯがより長く継続し、またはまったく失敗しても、同方法がＨＯに関して通信プロセス加入者にまったく知らせないこととともに−そもそも受け入れるかどうか、あるいは市場が、ＨＯＣＩＳ法の方を好むかどうか（この加入者へのＨＯに関する予防的情報手段／サポート手段をともなう）。
ただしこの場合、この「シームレスＨＯ」哲学が、いずれにせよ基本的なＨＯ問題をまったく無視していることを例外とする。このＨＯ問題は、複数の経済分野の予測可能な多重的なオーバラップから生じるものである。これら経済分野は、携帯型ネットワークユーザのための様々な無線ＴＫネットワークを持ち、この無線ＴＫネットワークは、大きさにおいてもその能力上の特性においても非常にさまざまであり、通常はアクセスが簡単で、多くは民間のものである。この第Ｂ章の末尾、特に第Ｄ．４．９項の末尾で、ここに述べた視点を詳細に説明する。
１次遠隔通信プロセス（ＰＴＫＶ）の端末システムの将来起こりうる、またはその時点のＨＯのため、本発明は、次の目的で様々な（ネットワーク透過的な）手段を含む。これらの手段は、このＰＴＫＶの少なくとももう１つの端末システムで、人または人ではないユーザに、そして特にＰＴＫＶの加入者（ＴＬＮ）としてＨＯに間接的にかかわる少なくとも１人／１つに、このＨＯに関して「コンビニエント・インフォメーション・サービス」を与えるためのものである。多くの場合、このＨＯＣＩＳは、間接的にＨＯにかかわるＰＴＫＶ−ＴＬＮのため、その要求がなくてもスタートし、したがって「社会的」相貌を持つ。これを明確に記述できるよう、ここではそれに必要な用語と付随する概念を説明する。
本発明の対象物は、包括的なＨＯＣＩＳ法と、それを実現するための包括的な装置である（包括的とは、自らの種類の多数のバリエーションを許すものをいう）。本願における両者の説明−用語および概念も同様−は、純機能的、すなわち完全に抽象的であって、具体的な実体的実現、すなわち実施形態に絶対に依存しない。しかし説明上の理由から、本方法、本装置、およびこれらの用語／概念の可能性ある実体的実現についても、時には説明する。その場合、次のことに留意されたい。すなわち、これら用語／概念に関する下記の説明は−すべてＯＳＩ−ＲＭ（ＯＳＩ参照モデル）−本発明による方法／装置の本質を説明するためのものである。したがってその他の通信技術的問題を根本的に説明しようというものではなく、多くの箇所でまったく直接、本願の特許請求の範囲における文言の実際的意味を説明する。第Ｄ章の下記の説明で、個別に詳細を説明する。
ここで前置きすると、通信プロセスのＨＯは、通信ネットワーク、および／またはネットワークのアクセスポイント、および／またはネットワークのアクセスポイントのファシリティのうち、少なくとも２つの間で行われる。したがって本発明は、「垂直な」ＨＯ、すなわち異なるネットワーク間のＨＯだけでなく、同じネットワークのアクセスポイント、および／またはファシリティ間のＨＯ、いわゆる「水平な」ＨＯ、および両種ＨＯのあらゆる混合物にも着目する。
ここで本願の用語と概念（＝意味＝意味内容＝セマンティクス。正確には、通信技術的なプラグマティクスとも）に議論を移す。
概念に関する（すなわち純機能的、完全に抽象的）事項−この項は重要である−
■抽象的な「通信プロセス」、すなわち「遠隔通信プロセス、ＴＫプロセス、ＴＫＶ」は、人の、および／または人ではない「加入者」（ＴＬＮ）間で行われる。これら加入者はさらには「ユーザ」であり−あるいは加入者の代理／部分機能／補完機能である。これらは例えば、電話応答機、メールボックス、ＭＰ３プレイヤー、ＩＶＲシステム、文書−／手書き−／グラフィック−／シンボル−／言語−／・・−／ＤＴＭＦ−発生器／ＤＴＭＦ検出器／インタプリタ／フィルタの能動的および／または受動的種類、一般的には「通信アプリケーションシステム」である（下記参照）−いずれも「端末システム」のものであって（下記参照）、この端末システムに属する。この場合これらの端末システムは、少なくとも１つのネットワークへのアクセスを持つ。ネットワーク／端末システム／ユーザは共同して、ＴＫＶの（抽象的な）技術的実現を生じる。
ここで次の場合に、
○通信プロセス、すなわちＴＫＶは、
◆「将来起こりうる」である：同プロセスのため、同プロセスに関与するＴＫＶ端末システムが、具体的措置を確かに実行するが、同ＴＫＶ端末システムの機器においてはまだ実行されない場合である（これらＴＫＶ端末システムの少なくとも１つにおいて、少なくとも１人／１つのＴＫＶ−ＴＬＮで初めて実行される場合については、下記参照）。
◆「その時点の」ものである：少なくとも１つのこのような端末機器でこれがすでに行われている場合である。
◆「スタート」または「開始」されている：上記両ケースのいずれについてもいう。
◆「遡及的」または「終了した」という：同プロセスのため、同プロセスに関与するいずれのＴＫＶ端末機器においても、具体的措置が行われなくなった場合である。
したがってＴＫＶが開始／スタートされたのは遅くとも、その端末システムの１つの少なくとも１つの端末機器（例えば電話機）が、そのＴＫＶに該当する措置をスタート・開始したときであることに留意されたい（例えば受話器を取り上げる、あるいはローカルな入力／出力、あるいはＴＫＶに何らかの関与をしている者による電話呼び出し先の電話番号の選択、あるいは時間経過すると呼び出しが行われるタイマの手動または自動スタート等々）。
○その時点のＴＫＶは、
◆ＴＬＮデータ交換がそのＴＫＶにおいて開始されるまで、「接続確立中」にある。
◆このＴＬＮデータ交換が開始されると、ただちに「開始中」となる。
◆ＴＬＮ情報交換が開始されると、ただちに「実行中」となる。
この場合、ＴＫＶ−ＴＬＮの少なくとも１つの「ＴＬＮデータ」または「ＴＬＮ情報」の交換が、少なくとも１つのＴＫＶ端末システムと、同端末システムがその時点で利用するネットワーク間で開始されると、ただちに「交換」が開始される。この場合ＴＬＮデータまたはＴＬＮ情報は、最終的な／当初のＴＬＮ感知可能な／生成可能な情報である。この情報は、この端末システムを用いて、この（人のまたは人ではない）ＴＬＮ宛て／ＴＬＮから出力され、または入力され、または選択されたものである。ＴＬＮデータとＴＬＮ情報の相違点は、ＴＬＮデータが通常は、ＴＫＶに場合によって必要となる管理（＝生成、中断、終了等々）のために交換されるのに対して、ＴＬＮ情報は、ＴＶＫの目的遂行のために交換される点である。両者のケースとも、ＴＬＮあるいは上記に挙げた代理／部分機能等々の間で行われる）。
本願は、少なくとも２種類の通信プロセス、すなわちＴＫプロセス、またはＴＫＶを区別する：すなわち１次通信プロセス、すなわち１次ＴＫプロセス、またはＰＴＫＶと−それぞれＨＯが１つずつ属する−少なくとも１つの２次通信プロセス、すなわち２次ＴＫプロセス、またはＳＴＫＶ、またはＨＯＣＩＳ−ＴＫＶである。いずれのＴＫＶも、自らのＯＳＩ接続を持つ（下記参照）。しかし両種のＴＫＶとそれらの端末システムは、その抽象的および／または実体的実現においては、その利用する抽象的／実体的な操作手段が、ほとんど同じものである場合もあれば、異なる場合もある。
これらのＴＫＶ用語／概念は、普遍的なものであって、すなわちＨＯまたはＨＯプロセスが通信プロセス／ＴＫＶであるならば、それらのＨＯまたはＨＯプロセスに用いられる−この場合のＨＯ／ＨＯプロセスは第３の種類のＴＫＶとなる。あるＨＯまたはＨＯプロセスが、（遠隔）通信プロセスであるかどうかは、ＨＯが行われる間のそのＴＫ技術が、ＨＯの基盤となるＰＴＫＶのＴＬＮ間の通信を含意するかどうかに依存するが、これは重要なことではない：ＨＯＣＩＳ法は、両者の場合に適用可能である−そして第１の場合には、ＨＯ−ＴＫＶを場合によって利用でき、そして／またはこれをＰＴＫＶと見なすことができる。これについては、第Ｄ章の最後の図５の説明で触れる。
遅くとも今述べたＴＫコンフィギュレーションまでの結果として、請求項１の文言／意味内容は、ＨＯの点で、１つまたは複数のＰＴＫＶ、および１つまたは複数のＳＴＫＶに関するものであることを、ここで指摘しておきたい。
■本願で用いられる通信技術用語は、国際標準「ＩＳＯ ７４９８−１，Ｉｎｆｏｒｍａｔｉｏｎ Ｔｅｃｈｎｏｌｏｇｙ − Ｏｐｅｎ Ｓｙｓｔｅｍｓ Ｉｎｔｅｒｃｏｎｎｅｃｔｉｏｎ − Ｂａｓｉｃ Ｒｅｆｅｒｅｎｃｅ Ｍｏｄｅｌ：Ｔｈｅ ｂａｓｉｃ ｍｏｄｅｌ」、短縮してＩＳＯ／ＯＳＩ−参照モデル、またはＯＳＩ−ＲＭと呼ばれるものにおいて定義されている。この規格は、標準的な当業者のため、本願のアイデア上／構想上の拘束力ある基盤を形成する。
上記の説明として：独立請求項１および８０に記載の本発明によるＨＯＣＩＳ法／−装置は−その「疑似自然言語的」文言にもかかわらず−ＯＳＩ−ＲＭで定義された用語／概念に基づく。すなわち、ＯＳＩ−ＲＭの通信技術的精細化／限定を受けている。すなわち「純自然言語的」意味の数多くの不確かさが消去されている。
本発明によるＨＯＣＩＳ法／−装置の説明は、ＯＳＩ−ＲＭの用語／概念を広範囲に利用している。これらの用語／概念は、請求項１および８０の疑似自然言語的文言／意味内容では用いられておらず−ＯＳＩ−ＲＭの「人工言語」に属する。したがってこの説明は、ＯＳＩ−ＲＡＭの人工言語／概念による標準的当業者の表現能力の明晰さを利用する。標準的な当業者はこれを、ＨＯＣＩＳ法／−装置に関する各独立請求項の疑似自然言語的記述が正しく理解されているか確認するのに、役立つと考えることであろう。ＯＳＩ−ＲＭの人工言語／−概念については、第Ｄ章も参照されたい。ＯＳＩ−用語／概念の下記の使用について、そして特に本願におけるＯＳＩ−ＲＭの人工言語／−概念については、前もってさらにコメントしたい。本願は、これら人工言語／−概念を、
○一方では完全には総括できないので、その代わりとして上記の国際標準の参照を指示する。その際疑問点があれば、本願が基準となる。
○他方ではいくつかの箇所で、ＨＯプロセスと付随するＨＯＣＩＳプロセスの際の実情に関して、これら人工言語／−概念を具体化する（第Ｄ章参照）。
ＯＳＩ参照モデルによる用語上／概念上、各末端システムの任意の２つの間、例えばＡとＺの間において、いずれのｎポイント通信プロセス（ｎ≧２）にも、抽象的な「ＯＳＩ接続」が存在する−この接続は、これら両末端システムにおける通信アプリケーションシステムに延びる。これを下記に説明する。
いずれのＯＳＩ接続も、ＯＳＩ−ＲＭに従って、少なくとも７つの「上下に積層する」抽象的な「Ｌｉ接続」（１≦ｉ≦７）に細分され、この接続を用いて、両者末端システムＡとＺの間で通信プロセスが行われる（ここで「Ｌ」は「ｌａｙｅｒ」の略である）。
ＯＳＩ−ＲＭはこれをもって−いずれのＯＳＩ接続でも、Ｌｉ接続の常に原理としては同じである「抽象化セマンティクス」の「７層」に基づいて−「ＯＳＩ通信アーキテクチャ」を定義する。このアーキテクチャ自体は、すべてのＯＳＩ接続の基本的な抽象化セマンティクスのこの「７層構造」を基盤とする。通信アーキテクチャのこの基本的な７つの抽象化層を、ＯＳＩ−ＲＭは−個々のＯＳＩ接続にまったく依存せず−容易に思いつく方法としてそれぞれを「Ｌｉ」（１≦ｉ≦７）と呼んでいる。
個々のＯＳＩ接続においては、いずれの「ｉ」に対しても、複数のＬｉ接続を与えることができる。いずれのこのようなＬｉ接続も、その実現のために、同じＯＳＩ接続の少なくとも１つのＬｊ接続を利用しなければならない（この場合常にｊ＜ｉである）−ただし下記を例外とする。
○Ｌ７接続であって（すなわちｉ＝７）、そのために他のＬ７接続を利用できるもの。
○Ｌ１接続であって、そのために通常「物理媒体」を利用するもの。
この場合、複数のＯＳＩ接続において１つのＬｋ接続を利用できる（１≦ｋ≦７）。あるいは、複数のＬｋ＋ｉ接続の１つのＯＳＩ接続においても同様である（１≦ｉ≦７−ｋ）。
ＯＳＩ接続のＬ７接続は、しばしば「通信接続」と呼ばれる。なぜならばこの接続で唯一重要なのは、このＯＳＩ接続の基礎となる独自のＴＫプロセス、または同プロセスをサポートする「通信アプリケーションシステム」（後者は、ＯＳＩ接続の少なくとも両端末システムに設けられている）としての「通信」だからである。すなわちＬ７接続は、この通信で−場合によっては人のＴＬＮが操作する通信アプリケーションシステムの通信で−利用される情報伝送（＝Ｌ１〜Ｌ４の機能）、情報細分（＝Ｌ５の機能）、および情報プレゼンテーション（＝Ｌ６の機能）のモダリティから抽象化される：Ｌ７接続はこの「通信アプリケーション」通信における「インタラクション」だけに関知する。
ＴＫプロセスのＯＳＩ接続は、下記の場所と時間に「存在」する。
○場所的には、（ＴＫプロセスの）両者端末システムＡとＺの間だけではなく−より正確には、これら両端末システムＡおよびＺの間には、このＯＳＩ接続のＬ３接続が存在する−そのＬ７接続を用いて、これら端末システムＡおよびＺの通信アプリケーションシステム間、またはＴＬＮ間にも存在する。
○時間的には、ＴＫプロセスが開始するとただちに存在し−特にその時点以降は、ＴＫプロセスの通信アプリケーションシステム間、またはＴＬＮ間に、このＯＳＩ接続のＬ７接続が存在する−そして両者の通信アプリケーションシステムまたはＴＬＮが、ＴＫプロセスが終了したと見なすまで、存在を継続する（これをＯＳＩ−ＲＭは、Ｌ７接続とＯＳＩ接続の終了としてモデル化している）。
その後このＯＳＩ接続が存在するが、ただし−ＯＳＩ接続を生成するための通信アプリケーションシステムの通信が開始されるので、すなわちＴＫプロセスが開始されるので−最も遅い場合で、ＯＳＩ接続／ＴＫプロセスを生成する（通信プロセスの）ＴＬＮの端末システムＡまたはＺの端末機器で、この接続／プロセスのため何らかの措置が行われる時点以降に存在する。しかしまだこの時点では、このＯＳＩ接続の何らかのＬｉ（１≦ｉ≦７）は、（抽象的に）実現される必要がなく、あるいは実現不可能である。したがってＬｉ接続の存在は、同接続の（抽象的な）実現または実現可能性を含意しない。より一般的にいえば：ＯＳＩ接続とともにその少なくとも７つのＬｉ接続も存在するが、そのうちＬｊ接続は１つも−そしてこのＯＳＩ接続で他のＬｉ接続との共同動作は−抽象的に実現される必要がない（ＯＳＩ−ＲＭは、実体的な実現／実行にいずれにせよ着目しない）。Ｌｉ接続の（抽象的な）実現は、その時点で（抽象的に）利用されている間だけ存在すればよい。
このことは、端末システムＡからＺの間のＯＳＩ接続が、その少なくとも１つのＬ３接続が実現されていなくても、あるいは実現不可能であっても、このＴＫＶのために存続することを含意する。これは端末システムのＨＯでしばしば生じることである。
いずれにせよＰＴＫＶ−ＯＳＩ接続のＬ７接続が、ＨＯケースにおいて存続することは、本発明によるＨＯＣＩＳ法によって保証できる（第Ａ章参照）。なぜならば本方法によれば、ＰＴＫＶ−ＯＳＩ接続に例えばＬ３接続の中断を生じても、このＰＴＫＶが（すなわちＰＴＫＶ−ＯＳＩ接続が）まだ終了していないことを、ＡまたはＺにおける少なくとも１人／１つのＰＴＫＶ−ＴＬＮが常に知っていることができるからである−この場合ＴＬＮは、ＨＯＣＩＳ法がなくても、Ｌ７が未終了であることをたまたま知っていることがある。なぜならばこの未終了は、ＴＬＮにとってそのアプリケーション通信から得られるからである。このアプリケーション通信は、ＴＬＮが、Ｌ３接続中断に先行する数秒間に行ったものである。ＨＯＣＩＳ法は、このような場合、対応するＴＬＮの推測を裏づけし、あるいはその推測を修正する。後者は例えば、ＨＯに直接かかわるＴＬＮが、ＨＯが行われる間に−すなわちＬ３接続中断の間に−ＯＳＩ−／Ｌ７接続を一方的に終了する場合である。
ここで再度指摘しておきたいのは、本発明の方法においては、ＰＴＫＶ−ＯＳＩ接続が、それに属するＳＴＫＶ−ＯＳＩ接続と同じ端末システムを接続する必要がないことである。しかし両者とも、それぞれ着目されているＴＬＮは同一である（これについでは第Ｄ章で詳論する）。
■抽象的な「端末システム」は、抽象的な人のユーザ、および／または人ではないユーザ（＝ユーザ自動機械）、および／またはユーザの前記に挙げた代理／部分機能−すべてＴＫＶ−ＴＬＮと見なされる−だけでなく、次のような抽象的な「端末機器」を含む。この最後に挙げる端末機器は、１つの端末システム中の端末機器全体をまとめて、下記では時には同様に「端末機器」と呼ばれることがある。すなわち、例えばＬＡＮ、ＷＬＡＮ、大型コンピュータ、データベース、ＰＢＸ、ＲＡＳ、ファイヤウォール、あらゆる種類のスイッチのそれぞれの全体をまとめたもの、またネットワークアクセス、ＩＡＤ、オン／オフ機器のそれぞれの全体をまとめたものといった、人ではない機能グループである。人ではない機能グループ（の抽象的または実体的な実現物）を、下記ではしばしば「モジュール」と呼ぶ。
■端末システムの抽象的な個々の「端末機器」を、互いに別個に着目することができる。特には下記の各端末機器である。
○「終端端末機器」。常に電子的／物理的／音響的／光学的な「論理ユーザ表面」を備える（このユーザ表面はしばしば携帯型である。すなわち携帯型電話機に設けられたもの）。
○「非終端端末機器」。その「ネットワーク・ターミネータ」（ＮＴ＝「Ｎｅｔｗｏｒｋ Ｔｅｒｍｉｎａｔｏｒ」）のためネットワーク固有の「端末アダプタ」（ＴＡ）を備えるものまたは備えないもの。いずれにせよすぐ上記で概略説明したユーザ表面を備えない。この場合、
○加入者端末と、端末システムの非終端端末機器が、物理的／通信技術的インタフェースおよび／またはその他の端末機器を介して、互いに共同動作するが、これらインタフェースや最後に挙げた端末機器のうち通常は若干だけが、標準化されている。そして
○非終端端末機器と（およびそのＴＡおよび付随するＮＴ。第Ｃ章参照）、終端端末機器とは、１つの実体的な実現物に組み込むことができる−特には１つの携帯型端末機器（例えば携帯型電話機）に組み込むことができる。そうすると前者の非終端端末機器も同様に携帯型となる。
本願の請求項１は、ＨＯＣＩＳ−ＴＫＶまたはＳＴＫＶの端末システムに少なくとも１つの機能モジュール「Ｍ（ＨＯＣＩＳ）」が存在することを含意する。このＭ（ＨＯＣＩＳ）は、請求項１の文言／意味内容の精緻な理解を得られやすくするため、第Ｄ章に詳しく説明したように、機能を十分に細分化されている。ＯＳＩ−ＲＭに合致した端末システムを（特に第Ｄ章でさらに説明する）モジュールに細分化することについては、ＯＳＩ−ＲＭが、一瞥したところ、端末システム細分化を回避するように見えるが、実際にはそれを行っていることを述べておく。理解のために言えば、その原因は、通信アプリケーションの細分化が必要と考えられるからである（これは、ＨＯＣＩＳ法の抽象的な実現のために絶対必要と考えられ、通常は端末システムにおけるＬ７層に組み込まれている、抽象的なＨＯＣＩＳ通信アプリケーションと同様である）。この必要性は、Ｌ７層に関する諸規定で（関連する国際標準を挙げるならば、１９９４年のＩＳＯ／ＩＥＣ７４９８、それと同一のＩＴＵ−Ｔ Ｒｅｃｏｍｍｅｎｄａｔｉｏｎ Ｘ．２００の特に３２／３３ページ、専門の国際標準として１９９４年のＩＳＯ／ＩＥＣ ９５４５、およびそれと同一のＩＴＵ−Ｔ Ｒｅｃｏｍｍｅｎｄａｔｉｏｎ Ｘ．２０７）、ＯＳＩ−ＲＭに合致する抽象的な通信アプリケーションの機能構造の定義につながる。最後に挙げた通信アプリケーションは、論理的には、同アプリケーションが行われる端末システムの同アプリケーションに対応する機能細分化を含意する−しかもその細分化は、これら端末システムに設けられた、そしてＯＳＩ−ＲＭに合致する、抽象的な通信アプリケーションの端末システム領域におけるものである。
■抽象的な「サーバ」、または「サーバ端末システム」または「人のＴＫプロセスの加入者を持たない端末システム」は、次のようなネットワークにおける機能グループである−そのネットワーク運用者の管理下にあろうとなかろうと−すなわち、本願において同様に端末システム／端末機器と見なされるが、後者の端末機器は終端的／非終端ものに細分化されない、このような機能グループである。
■抽象的な「システム」は、端末システム／端末機器であるか、または１つのネットワークにいずれにせよ組み込まれているコンピュータであるかの、いずれかである。
■ＰＴＫＶ−またはＳＴＫＶ−ＯＳＩ接続におけるサーバおよび／またはシステムの可能性ある多数のＬｉリレー上の役割について、本願は、そのすべてを個別に説明する必要はない−その点については、図５におけるリレーの例の議論が、標準的な当業者に説明を与える。ここで重要なのは特に、−ＰＴＫＶのＨＯに属する−ＨＯＣＩＳ−ＴＫＶにおける（定置型のまたは携帯型の）「ＨＯＣＩＳサーバ」および／または「ＨＯＣＩＳシステム」であって、かつ１つまたは複数のＨＯＣＩＳ接続の少なくとも１つにおける端末としての当該サーバおよび／またはＨＯＣＩＳシステムである（図５のうち最後の各図についての第Ｄ章の説明参照）。この端末システムは、ネットワークにおけるＨＯＣＩＳサーバまたはＨＯＣＩＳシステムでもあり得る。
■ＰＴＫＶ端末システム（とそのＰＴＫＶ−ＴＬＮ）は、次のような場合、ＨＯに、将来起こりうることとして、またはその時点で、または遡及的に「直接かかわる」と言う。それは、その当該端末システムが、そのネットワークアクセスポイント（このポイントを経由してＰＴＫＶがルーティングされている）において、ＨＯプロセスの間、Ｌ３層において、一方では全体的にまたは部分的に、他方では持続的にまたは一時的に、ネットワーク／ネットワークアクセスポイント／インターネットファシリティ／利用標識の切り替えを、将来的に、または現在、または遡及的に行う場合、かつ当該端末システムのＰＴＫＶ−ＯＳＩ接続（あるいは同端末システムのＰＴＫＶ）を維持する場合である。ＰＴＫＶ端末システム（およびそのＴＬＮ）は、このＨＯに直接かかわらない場合、このＨＯに間接的にかかわるという。
■本願は、次のような場合だけに着目すればよい。それは、１つのＰＴＫＶにおいて、ある１つの時点に、ＨＯがただ１つだけ存在する場合−すなわち抽象的な「単一の直接かかわるシステム」のＨＯが存在する場合である。あるＰＴＫＶが、抽象的な「複数の直接かかわるシステム」のＨＯをも取り扱う−これは実際の場では重要なことである−という印象を与えるとき、それらＰＴＫＶの実施形態のいずれによっても、次のことを容易に示すことができる。それは、これらの実施形態が、実際には、時間的にオーバラップする「単一の直接かかわるシステム」のＨＯの列を取り扱うことに基づくことである。
その結果として：
○ＨＯ／ＨＯプロセスに対して、上記の将来起こりうる／その時点の／遡及されたＴＫＶ属性付与が適用可能となる。
○ＰＴＫＶ−ＯＳＩ接続あるいはそのＰＴＫＶの（抽象的な）実現が、ｎ≧２個のＰＴＫＶシステムを含むので、このＰＴＫＶでは１つのＨＯにｎ−１個のシステムが間接的にかかわる。
■１つのＰＴＫＶのＨＯに関するＨＯＣＩＳ−ＴＫＶあるいはＳＴＫＶに対し、次のことが適用される。すなわち、ＨＯＣＩＳ−ＴＫＶは、本発明による「信号」あるいは「ＨＯＣＩＳ信号」の存在−少なくとも１つのＰＴＫＶ−および／または附随するＨＯＣＩＳ−ＴＫＶ、あるいはＳＴＫＶシステムの中であれば、それがどこであろうと、どのような状態であろうと−の発見とともに開始／スタートする。ＳＴＫＶにとって、上記の将来起こりうる／その時点の／遡及されたＴＫＶ属性付与は、このスタート時点をもって適用可能となる。
ＨＯＣＩＳ法におけるＰＴＫＶ、そのＨＯおよびＳＴＫＶのスタート時点は、−別段の言及がない限り−時間的には任意の順序で指定されたものとすることができる。
ＨＯＣＩＳ−ＴＫＶ、あるいはＳＴＫＶ、あるいはそのＳＴＫＶ−ＯＳＩ接続−これらはＰＴＫＶの将来起こりうる、またはその時点の、または遡及されたＨＯに関するもの−は、特に下記の場合に限り、このＰＴＫＶと関係あるものとすることができる。すなわち、ＰＴＫＶが、その（抽象的および／または実体的）実現のために、すなわちそのＳＴＫＶ−ＯＳＩ接続、すなわちそのＳＴＫＶ−Ｌｉ接続の実現のために、ＰＴＫＶ−ＯＳＩ接続のＬｉ接続の１つまたは複数（すなわちＰＴＫＶ端末システムにおける当該接続の端末ポイントの抽象的および／または実体的な実現）を利用できる場合である。しかしこれら両ＯＳＩ接続の実現（抽象的および／または実体的実現物の状態で）は、互いに完全に独立して行うこともできる。
この場合重要なのは、ＨＯＣＩＳ法が、（何らかのモダリティの）ＨＯＣＩＳシステムからＴＬＮへのＨＯ関連情報の転送に基づくことだけである−これは（請求項１に記載する）そのため必要なＨＯＣＩＳ−ＯＳＩ接続が実現される場合とまったく同じである。このＯＳＩ接続のＨＯＣＩＳ−ＴＫＶ／２次ＴＫＶのスタートが、ＰＴＫＶ−および／またはＨＯＣＩＳ−／２次システムにおける（ＨＯＣＩＳ）信号の存在によって行われることも、ＨＯＣＩＳ法の妨げにはならない。
特に次のことに留意するべきである。これらシステムの少なくとも１つにおいて、この種の（ＨＯＣＩＳ）信号の実現／発生／存在の方法には、何の限定もないことである。これは何らかのＨＯ関連情報の実現／発生／存在と混同されてはならないが、本願で個別に説明する必要はない。
■そのときどきに着目されるＨＯＣＩＳ法−より正確には、その抽象的な実施例に着目されたＨＯＣＩＳ−ＴＫＶ−は、ＰＴＫＶのＨＯに一意的に割り当てられる。
■ＳＴＫＶはその時点のＨＯを何ら含意しない。ＳＴＫＶは、例えば将来起こりうるＨＯに属する。
■（ＰＴＫＶの将来起こりうる、またはその時点の、または遡及されたＨＯに関する）ＳＴＫＶは、少なくとも１つのＭ（ＨＯＣＩＳ）が準備したＨＯ関連情報をこのＰＴＫＶのＴＬＮに伝達しようとする試行を、少なくとも１回開始したことを含意する。
この「伝達の試行」は、下記２つの○印のいずれかを意味する（図５とその説明を参照）。
○
◆少なくとも１つのＰＴＫＶ−／ＳＴＫＶ−システムにおけるＭ（ＨＯＣＩＳ）による、少なくとも１つのネットワーク経由／からのＨＯ関連情報送信／受信の試行。
◆および／またはこのプロセスＴＬＮ宛て／からのローカルな上記情報伝達／受け取りの試行。
○あるいは、このＴＬＮの端末機器のＭ（ＨＯＣＩＳ）が、ローカルで−例えば「Ｔｉｍｅ ｏｕｔ」メカニズムに基づいて、前もってこれら両者Ｍ（ＨＯＣＩＳ）間で合意されたプロトコルにより（これらいずれも当業者には知られていることである）−このような情報を発生したが、その際この情報はネットワーク経由で送信されたり、そして／または受信されたりすることがなかった。
これは本発明の核心であって、請求項１の文言／意味内容を基盤とする−これを下記では（特に第Ｄ章で）繰り返し詳細に説明する。
■「ＨＯ関連情報」は、少なくともＨＯに直接かかわる端末システムを経由する、最終的にＴＬＮに感知可能な情報である。この情報は、
○そのためにＭ（ＨＯＣＩＳ）により検出され、準備され、転送された後、
○終端ＳＴＫＶ−／ＰＴＫＶ−端末システムにおいてそのＰＴＫＶ−ＴＬＮに伝達される。
上記の情報は最終的には、ＨＯにかかわる（そして本願の例では通常人の）ＰＴＫＶ−ＴＬＮに関しての、ＨＯＣＩＳ法の「ＨＯ・コンビニエンス・インフォメーション・サポート適性」に対応する。この情報は最終的に、ＴＬＮの「自動化された」そして／または物理的なそして／またはシンタックス的なそして／またはセマンティックなそして／またはプラグマティック／メンタルな感知能力の抽象化レベルのため／抽象化レベル上で、構想され／表現され／コード化され／プレゼンテーションされ／固定される：
○プラグマティック／メンタル／物理的には、ＨＯ関連情報は、特にこのようなＰＴＫＶのＴＬＮのためにＨＯＣＩＳを提供したいという願望により、構想されている。このＴＬＮのうち少なくとも１人／１つのＰＴＫＶ−ＴＬＮが携帯型である（したがって将来はその理由だけで、ＨＯがしばしば生じるかもしれない）。しかもその結果として、その携帯型のＴＬＮは通常、他のＴＬＮに歓迎されていると感じることになる。ＨＯ関連情報は確かに何らかの理由でこのＴＬＮに重要である限り−その時点のＰＴＫＶに基本的なＴＫイベントが生じるとき、ネットワーク情報と料金情報を含むことができる。しかし、そのような「プラグマティックな／メンタルな／心理的な瑣末事」に限定されてはならない。むしろＨＯＣＩＳは、「これらＴＬＮの心」に取り入らなければならず、これらのＴＬＮを、そのＰＴＫＶとＰＴＫＶのＨＯに関して、信頼性ある／喜ばしいと感じられる情報を−できるだけ弾力的に、思いやりをもって、そして個別の状況に合わせて−供給しなければならない。ここで留意されたいのは、ＨＯＣＩＳは、例えばＴＬＮに対して、その短期間に順次通過するＷＬＡＮへの絶えざる新たなチェックインを、完全に免除できることである。そして、ＴＬＮからの指定によっては、ネットワーク切り替えだけをＴＬＮに知らせる。標準的な当業者は、ＴＬＮに伝達されたＨＯ関連情報については通例として−複雑なＨＯＣＩＳについてはただちに−その情報／ＨＯＣＩＳが本発明によるものであるか、あるいは上記の瑣末事に属するものであるか判断できる。関連する従来の技術は、この瑣末事を最初からすでに開発している。
○セマンティック／シンタックス的には、ＨＯ関連情報は、情報一般に慣行となっているように、例えば人間の自然言語、および／または文書、および／またはマークなどの形で表示される。しかしこのことは、その他の表示、例えばＴＫに慣行的なシンタックス上のコード化、例えば意図的に標準化されたもので当業者には知られているＰＤＵ、例えば「ＡＳＮ．１−ＰＤＵ」の形のものや、これらの何らかの種類のセマンティック用例を除外しない。
このことは、ＨＯ関連情報の形成／表示のバリエーションを含意する。
○１つにはＴＬＮに妥当なＨＯＣＩＳとしてのバリエーション。このＨＯＣＩＳは、少なくとも１つの「ＨＯＣＩＳ−ＳＤＵ」（ＳＤＵ＝Ｓｅｒｖｉｃｅ Ｄａｔａ Ｕｎｉｔ）に基づく。この場合ＳＤＵは、少なくとも１つの「ＨＯＣＩＳ−ＩＤＵ」（＝Ｉｎｔｅｒｆａｃｅ Ｄａｔａ Ｕｎｉｔ）を用いる実体的な実現とは区別されなければならない。本願は、このＨＯＣＩＳ−ＩＤＵには着目しない。
○もう１つには、ＴＫに妥当な少なくとも１つの「ＨＯＣＩＳ−ＰＤＵ」（ＰＤＵ＝Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ）としてのバリエーション。本願は、このＯＳＩ用語法を単純化して、ＳＤＵをも同様にＰＤＵと見なす。したがってＨＯ関連情報は、本願においては、常にそのように理解されたＨＯＣＩＳ−ＰＤＵである。
前記に述べたことをＯＳＩ−ＲＭに合わせて簡単に表現できるよう、さらに下記について説明したい。
○ＰＴＫＶ／ＳＴＫＶ−ＴＬＮに関して、抽象的概念「ＨＯ関連情報」は、上記の少なくとも１つのＨＯＣＩＳ−ＳＤＵを含む。このＳＤＵは、このＳＤＵをもたらすものでＯＳＩ−ＲＭに定められた「ＨＯＣＩＳサービス要素」の少なくとも１つを用いて、このＴＬＮに伝達される。この場合、
○これらの抽象的な「ＨＯＣＩＳ−ＳＥ（サービス要素）」は、通常はＨＯＣＩＳ措置の可能性ある実体的実現を、このＴＬＮのため、ＨＯに関して指定する。
実体的実現あるいはＨＯＣＩＳ法の実施形態の特性には、本願は着目しない。
すなわち、下記において用語「ＨＯ関連情報」、「ＨＯＣＩＳ」、「ＨＯＣＩＳサービス」は、最終的には類義語である。ただしこの場合、これらの用語は、（その時点の、または将来起こりうる、または遡及された）実体的ＰＴＫＶの実体的ＴＬＮの最終的な実体的情報を、そのＰＴＫＶの（その時点の、または将来起こりうる、または遡及された）実体的ＨＯに関して、ＯＳＩ−ＲＭに合致する方法でモデル化するものとする。
■ＨＯＣＩＳ−ＴＫＶは、ＨＯに関して、ＰＴＫＶ−ＴＬＮのＨＯＣＩＳを得るが（そしてそれとともに、このＨＯまたはＨＯに関するメッセージの発信／変形／抑圧を劣化させるが）、その際、ＰＴＫＶ−／ＨＯ−実現に必要なネットワークを変化させない。後者（ネットワーク）は、ＰＴＫＶのための請求項１によるＨＯＣＩＳ−ＴＫＶを受けることを何ら必要としない。なぜならば、前者（ＨＯＣＩＳ）は、通常はその基盤となるＳＴＫＶ−ＯＳＩ接続のＬ４〜Ｌ７層に根を下ろしているからである−これは、ＨＯＣＩＳのＨＯ関連情報が「ＨＯＣＩＳの」ＰＴＫＶ−ＯＳＩ接続に関するものであっても同じである。したがってＳＴＫＶは完全に「ネットワーク透過的」であり、実体的に実行することもできる。
■端末システム／−機器のユーザは下記を行うことができる。
○場合によっては自らのため、ユーザに提供されたＨＯＣＩＳの表示、および／またはＨＯＣＩＳ受け取りのモダリティを決定／削減／遮断する−短くいえば、「コンフィギュレーション」する−しかもこれを、本来のＨＯの実行前、およびまたは実行中、および／または実行後の時間に行う。
○ＨＯＣＩＳを、任意のその他のプロセス／アプリケーションと交換する。
○少なくとも１つのＨＯＣＩＳの受け取りを、少なくとも１つの方法で確認しなければならず、あるいは確認する必要がないとき、このような確認／非確認は、ＨＯＣＩＳ−ＴＫＶの経過を変更でき、あるいは変更できない。
■端末システムとネットワークの関係について、ネットワークに対する端末システムの基本的な接続性、ならびに端末システムのインターネット接続性、およびネットワークを経由する端末システムの通信アプリケーション接続性を区別しなければならない：
端末システムについていうと、
○ネットワークへの端末システムの「基本的な接続性」は、Ｌ１およびＬ２でこのネットワークから、少なくとも１つのＰＤＵを受信できると、ただちに得られる（そうすると、端末システムがすでに「基本的なＨＯ」を実行済みである）。
○端末システムがネットワーク経由で他のインターネット端末システムへの接続を利用できると、ただちにネットワーク経由の「インターネット接続性」が得られる−このことは、端末システムのＬ１／Ｌ２接続性だけでなく、このネットワークへの端末システムの「管理上の接続性」、すなわち端末システムがこのネットワークで「チェックイン」されていることを前提とする（第Ｄ章の最後の図５の説明参照）。そして、
○「ＨＯＣＩＳ接続性」、すなわちネットワーク経由「特定のアプリケーション・インターネット接続性」は、端末システムがネットワーク経由でその他のインターネット端末システムへの接続を利用できると、ただちに得られる。この場合このインターネット接続は、この特定の通信アプリケーションシステムを介してルーティングされなければならない。
本願は−別段の言及をしない限り−このすぐ上記に述べた基本的な接続性とＨＯＣＩＳ接続性だけを区別するので、後者は特定のアプリケーション・インターネット接続性をも、特には「ネットサーフィン・インターネット接続性」すなわち「ＷＬＡＮサーフィン・インターネット接続性」をも含む。
基本的にのみネットワークに接続された端末システムは−端末システムが、ネットワークを経由するそのインターネット接続性を実現するため、このネットワークを利用したい場合−直接かかわりを持たされてこのネットワークのサービスフィーチャー間でＨＯを実行しなければならない。端末システムは、このＨＯにおいて、このネットワークで端末システムが利用するサービスフィーチャー間で、「Ｌ１＋Ｌ２サービス」と「Ｌ１＋Ｌ２＋Ｌ３サービス」を切り替えなければならない。
ネットワークへの端末システムの基本的なＨＯと、このネットワークシステムにおけるこの端末システムのチェックインとの間に存在する相違にも、留意されたい。前者は、このネットワークに対するこの端末システムに必要なＴＫ措置であって、この端末システムが、続いてこのネットワークにおいてチェックインを実行できるようにするためのものである。この場合、ネットワークにおける端末システムのチェックインは、この端末システムによるネットワークの広範囲な利用可能性、特にこの端末システムのインターネット接続性を含意する必要はまだない−このことは標準的な当業者すべてが知っていることである。
ネットワークへの端末システムの基本的な接続性の確認は、ＨＯＣＩＳ法においては特に重要とされている：この確認によって、ＨＯＣＩＳ法のスタート時点が決定される。
■さらに下記の概念の説明が必要である。
○
「ペア」のＳＴＫＶ−／ＰＴＫＶ−システム：少なくとも２つのＳＴＫＶ−またはＰＴＫＶ−システムのこの属性／特性は、これらのシステムがＳＴＫＶまたはＰＴＫＶにおいて互いに通信することを意味する。ここでは、実施形態、すなわちＨＯＣＩＳ法の実体的な実現において、１つのシステムが少なくとも１つのＳＴＫＶシステムと、ＰＴＫＶシステムとを含むことができることを、想起されたい−このことは、抽象的には１つのＳＴＫＶ−またはＰＴＫＶシステムが、そのペアになるシステムそれぞれ１つだけによって、このＴＫＶに対応するＳＴＫＶ−またはＰＴＫＶ−ＯＳＩ接続を操作する、ということに何の変わりも生じない。
○ＳＴＫＶ−／ＰＴＫＶ−システムの「能動的な通信試行」：この概念は、当該システムの試行であって、少なくとも１つのネットワークを経由して少なくとも１つのＰＤＵをペアになるもう１つのシステムに送信し、そして／またはそれらが受信されたことの何らかの確認を受け取ろうとすることを言う。
ＨＯＣＩＳ法の基本的に新規な点について、第Ｂ章で多くの言葉を用いて基本的な説明をしたが、それらの点を下記に、わずかな言葉と現場指向により繰り返し説明する：ＨＯＣＩＳ法は、ＰＴＫＶの端末システムの１つの将来起こりうる、またはその時点の、またはより早い時点の−ＨＯに関して、少なくとも１つのＨＯＣＩＳあるいはＨＯＣＩＳ措置によって、少なくとも１人／１つのＰＴＫＶ−ＴＬＮをサポートすることを意図する。ＨＯＣＩＳ／ＨＯＣＩＳ措置は、少なくとも１つのＰＴＫＶ−またはＳＴＫＶ−端末システムに少なくとも１つのＨＯＣＩＳ信号が存在することが確認されることにより、スタートされる。その結果として、それに関するＨＯ関連情報が、少なくとも１人／１つのＰＴＫＶ−ＴＬＮに伝達される（ＴＬＮのＳＴＫＶ端末システムがＨＯ関連情報を受け取った後、またはそれに代わる方法としてＨＯ関連情報が自動的に構成された後）。しかしＴＬＮがこのＨＯＣＩＳを受け取るのは、ＴＬＮがＨＯ関連情報をリクエストしたからではなく、このＨＯによって受ける劣化をできるだけ不利なものにしないためである。したがってＨＯＣＩＳ法は「社会的に」根拠付けられている。
したがってＨＯＣＩＳ法は、ＰＴＫＶ端末システムに、将来起こりうる、そして／またはその時点の、または遡及されたＨＯの点で、従来は決して考え付かなかった方法を与える。より正確にいえば、ＨＯＣＩＳ法はＰＴＫＶ−端末システム／−端末機器に、ＨＯに関して−ＴＬＮをサポートするために−これらＴＬＮに対するまったく新しい種類の「社会的」挙動を与える：この種のアイデアは、従来はその痕跡すらなかったものである。
この理由だけで、ＨＯＣＩＳ法は、従来のＨＯ技術と根本的に区別される（第Ａ章参照）。すなわち従来の技術は、「人間相互間の」ＨＯ問題を無視する−すなわちＨＯの場合、少なくとも１人／１つの間接的にかかわるＰＴＫＶの加入者が、このＨＯとその進行によって少なくとも一時的に暗闇の中に放置され、これにより場合によっては著しくいら立たせられ、ましてこの加入者はそれに対して何らかの反応をすることができない、という問題である。この加入者は、「ＨＯに関するユーザの利害がまったく無視されていること」を、そもそも問題として把握していない。
ＨＯＣＩＳ法は、この実際にある問題の解決法の技術的核心である：したがって本願は、その技術を用いれば、あらゆるＰＴＫＶ−ＴＬＮが、（その要求に応じて）このＰＴＫＶにおける（将来起こりうる、またはその時点の、またはそれより早い時点の）ＨＯについて知らされ／サポートされることが可能となる、このような技術の基礎を開示する−ＨＯに直接かかわらないＴＬＮも同じである。
したがってＨＯＣＩＳ法は、ＴＬＮをシームレスなＭＩＨでサポートするのにも適している。このサポートの重要性の例を挙げれば：ＷＬＡＮ技術により大きなファイルをＰＤＡ（Ｐｅｒｓｏｎｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）にダウンロードするとき、ユーザはそのため利用されるＷＬＡＮの外に移動する。ここでＭＩＨ法を介入させて、高価な、そして／または非常に遅いＧＳＭネットワーク上でダウンロードを継続させるべきであろうか？それともＷＬＡＮが使用できて初めて、ＭＩＨ法を継続するべきであろうか？それともＭＩＨ法を場合によってはまったく中断するべきであろうか？ユーザにこれらの別法について知らせたくなければ−これは、シームレスなＭＩＨの際には意図されていることである−市場要請を回避することとなろう。
本発明によるＨＯＣＩＳ法は、ＷＬＡＮ／Ｆｅｍｔｏｃｅｌｌと携帯型ネットワーク間のＨＯの際に有意義であるが、このことは、その他すべてのネットワーク／部分ネットワーク／ネットワークタイプにも、それらが請求項文言／−意味内容に含まれているなら当てはまる。特に「携帯型ネットワーク／携帯型ネットワークローミングにおけるＨＯ」で有意義である−これは、本願の実施例／図面が最初に挙げたケースだけを具体化していても同じである。
ＨＯＣＩＳ法は、ユーザがそのリアルまたはバーチャルなローカル・アプリケーションシステム、例えばＭＳ−ＷｏｒｄまたはＭＳ−Ｅｘｐｌｏｒｅｒ、または自動車のナビゲーションシステムを用いて作業する場合について、公知のユーザサポートを根本的に発展させたものである。本方法がこのサポートの根本的発展形であるのは、次の理由からである。すなわち、ユーザがこの作業の際、従来はその時点の行動の決定要素に対してのみサポートしていて、この決定要素は、ユーザに知られており、そして自動的には変化しない影響範囲を反映する。しかしＨＯＣＩＳ法は、ユーザを、さらにユーザのその時点の行動の新しい種類の決定要素に関して、新しい方法でサポートする。この決定要素は、ユーザに知られていない、ユーザが見ると自動的に変化する、そしてユーザが影響を与え得る領域を反映する（この場合：そこにあるあらゆる種類のＨＯ関連イベントに関して）。したがってＨＯＣＩＳ法の根本的革新は、ＨＯにおけるＴＬＮのその時点の行動の新しい種類の決定要素に関し、ＰＴＫＶのＴＬＮに対する新しい種類の「コンビニエンス・インフォメーション・サポート」である。
第Ｂ章を終わるに当たって、次のことを注記したい。ＨＯＣＩＳ法のここまでの説明では、ＨＯに間接的にかかわるＰＴＫＶ−ＴＬＮのサポート、またはそのＦＭＣ電話機が前面に出たが、このことは、本願の下記の各章にも当てはまる。特に第Ｂ章は、ＨＯＣＩＳ法の本質を明らかにするためのものであるため、ここで次のことをはっきりと指摘し、短く根拠付けする。すなわち、本方法は、ＨＯに直接かかわるＰＴＫＶ−ＴＬＮをサポートすることもできることと、なぜそれができるかということである−しかもこの指摘と根拠付けは、ＦＭＣ電話機の一般的に知られた実際の例と、その基本的なＩＡＤ接続性の確認について行われる（この場合、請求項１は、この「ＦＭＣ」にも、「電話」にも、「ＩＡＤ」にも、限定されない）。
（ＨＯに直接かかわるＰＴＫＶ−ＴＬＮ＝ＦＭＣ電話機ユーザのための）本発明による方法のこの特殊な実施例におけるＨＯＣＩＳは、ＨＯＣＩＳ法の市場重要性を示威する。その中でＨＯＣＩＳは、特に実際の場でのＦＭＣ利用単純化の潜在的な可能性を明らかにする。すなわちこのような「ＨＯコンビニエンス・インフォメーション・サポート」は−ＦＭＣ電話機がその基本的なＩＡＤ接続性（上記参照）を確認した後−下記と明確に区別される：
■このイベントを介する電話機による、今日知られているユーザ情報。この情報は、ユーザに対して、
○結果としてのみ、電話機上で非瑣末的なユーザアクティビティにアクセス可能であり、そして
○後者の実行は、電話機上のその他あらゆるユーザアクティビティを抑制し、そして
○この両者とも、この将来起こりうるＨＯの評価／強制／不利益甘受／背景調査可能性／回避可能性等々に関してサポートしない。
■しかし将来のユーザＨＯＣＩＳは、この不十分なユーザ情報とはまったく異なって、
○電話機上のユーザアクティビティを何ら要求しない。そして／または
○それに対するユーザアクティビティを何ら妨害しない。そして
○ユーザを特にＨＯに関して非常に広範囲にサポートできる−例えばそのため、ＨＯＣＩＳはこのＩＡＤへの「ワンタッチＨＯ」を可能とする（そのためＨＯＣＩＳは、基礎的に接続されたＩＡＤをただちに自動化し、そして背景で、ユーザがＨＯＣＩＳでチェックインするか、そしてＨＯＣＩＳを特定の目的、例えば上記の「ネットサーフィン」のために利用できるかを点検する）−その結果としてユーザは、このワンタッチＨＯを利用して、ＦＭＣ電話機の基本的なＩＡＤ接続性から、（このＩＡＤを経由する）同電話機のインターネット接続性を、あるいは同電話機のネットサーフィン・インターネット接続性（追加的にそのホームＩＡＤをも経由して）を生じることができる。
このような（ＨＯＣＩＳ法によって実現される）ワンタッチＨＯ、またはゼロタッチＨＯ（例えば電話機ユーザがこのＨＯのためにコンフィギュレーションするもの）によれば、ＨＯＣＩＳ法を用いないときよりも、ＦＭＣ電話機の利用をはるかに快適に、しかも通常は安価にすることができる−その結果としてＨＯＣＩＳ法は、ＨＯに直接かかわるＰＫＴＶ−ＴＬＮから、歓迎すべきものと見なされる。
この場合、（例えばワンタッチＨＯによって）ＨＯに直接かかわる電話機のユーザのためのＨＯＣＩＳが、同じＨＯに間接的にかかわるＰＴＫＶ−ＴＬＮのための、さらに上記に説明したＨＯＣＩＳを、シームレスに補完することができる。下記の第Ｄ章、特にＤ．４．９と図５、特に図５ｏ〜ｒの説明により、この点について十分理解することができる。
本発明の一実施形態におけるＨＯ関連でしばしば生じるＴＫ配置を示す図である。 本発明の一実施形態における、ファシリティＨＯをただ１つだけ可能とするが、ネットワークＨＯを可能とせず、すべての「ＧＳＭ／ＧＰＲＳだけの」電話機に対してはこのようなＨＯを可能とするＨＯ−ＴＫ配置を示す図である。 本発明の一実施形態における「ハンドオーバ・コンビニエンス・インフォメーション・サポート」（ＨＯＣＩＳ）を実現するための機能上の手順段階を示す図である。 本発明の一実施形態におけるＨＷ及びＳＷ構成要素を示す図である。 本発明の一実施形態におけるＰＴＫＶ−またはＳＴＫＶ−ＯＳＩ接続におけるサーバおよび／またはシステムの可能性ある多数のＬｉリレーを示す図である。
Ｃ．ＨＯＣＩＳ法の実施形態のバリエーション−上記以外の付随する通信技術的用語／概念の説明
この第Ｃ章でのＨＯＣＩＳ法のスケッチと、付随する図１および２は、携帯型端末機器を用いる電話呼び出しでのＨＯＣＩＳ法への着目に限定されない。特に、少なくとも１つの携帯型および／または無線ネットワークを用いる、（ほとんど）リアルタイムでの、２つのＰＴＫＶにおけるＨＯに限定されない。これらの特殊ケースは、例えばＥメールに基づくＰＴＫＶのように、ＴＬＮが同時に関与する必要がない「同期されない」ＰＴＫＶを含まない。また少なくとも１つの固定ネットワークの関与の下にあるＨＯを含まない。そして無線ネットワーク内部のＨＯだけに接触する（例えば「Ｆｅｍｔｏｃｅｌｌｓ」またはＷｉＦｉ−ＷＬＡＮを、そしてＧＳＭ／ＣＤＭＡ／ＵＭＴＳ／Ｗｉｍａｘ等々のネットワークにおける類似の構成物を用いて）。−当然のことながら、これによって、ＨＯＣＩＳ法のここでは着目されない付随する特殊ケースが、請求項文言／意味内容の保護範囲から除外されることはない。
したがってこれらのスケッチは、頻繁に「モビリティによって生じる」、かつＨＯＣＩＳ法が役立ち得るＴＫ配置で予想される、ＨＯのいくつかを示すだけのものである。この場合これらのスケッチは特に、ＨＯＣＩＳ法を−少なくとも１つの人ではないＭ（ＨＯＣＩＳ）モジュールを用いて−全体的にあるいは部分的に特に下記において実現できることを示す。
１．携帯型ネットワーク電話機、または少なくとも無線電話機。
２．携帯型または固定型のＩＡＤ（ＩＡＤ＝Ｉｎｔｅｇｒａｔｅｄ Ａｃｃｅｓｓ Ｄｅｖｉｃｅ。ＷＬＡＮのＩＡＤである。これらＩＡＤの先行モデルは、技術的にはより簡単であって、「Ａｃｃｅｓｓ Ｐｏｉｎｔｓ」、ＡＰと呼ばれた。この場合ＩＡＤのＷＬＡＮは、ＧＳＭ／ＣＤＭＡ／ＵＭＴＳ／Ｗｉｍａｘ等々のネットワークの「Ｆｅｍｔｏｃｅｌｌ」であり得る）。
３．通信ネットワーク内、またはそれにつながるシステム／サーバ／ＩＡＤ。
上記ＨＯＣＩＳ法の実現は、場合によっては、別の場所のＰＴＫＶのＴＬＮのためのものである。
下記の議論では、通信ネットワークの端末システムから同ネットワークへの「アクセス」という概念が非常に重要なので、まずその−標準的な当業者には知られていることであるが−意味内容を（本願には十分な範囲で）説明する：ここで考えられている当業者的定義によれば、ネットワークの（抽象的な）端末システムは（この端末システムはネットワークにチェックイン済みである。上記参照）次のような時点で、このネットワークへの「アクセス」を得る。その時点とは、端末システムが、下記の接続のＯＳＩ層Ｌ１〜Ｌ３で、Ｌ３データ伝送を操作できる時点である。
■このネットワークの少なくとも１つの（抽象的な）アクセスポイントとの接続。
■このネットワークを経由する、このネットワークの少なくとも１つの端末システムとの接続。
この結果特に、ネットワークの端末システムは、ネットワークへのアクセスを必ずしも常時持つ必要はない−これについては、携帯型ネットワークの端末システムの場合にしばしばそうであることが、知られている。
このネットワークへの「アクセスポイント」は、この場合（特にこのネットワークへの／ネットワークからのデータ伝送のため、ネットワークの将来の利用またはその時点の利用の場合）、Ｌ１〜Ｌ３層の機能能力に対する法的／営業的および場合によっては技術的責任が（このネットワークのプロバイダからこの端末システム／端末機器の責任者に）移行する箇所である。この箇所は、端末システム／端末機器とネットワーク間の「データ伝送区間」（ＤＵＥＡ）上にある。アクセスポイントにおけるＤＵＥＡのネットワーク側の（抽象的な）終端は、「ネットワーク終端」（「ｎｅｔｏｗｏｒｋ ｔｅｒｍｉｎａｔｏ」、ＮＴ）と呼ばれ、アクセスポイントにおけるこのＤＵＥＡのユーザ側の（抽象的な）終端機器は、「端末アダプタ」ＴＡと呼ばれる。ネットワークアクセスポイントの実体的な実現において、これら両者の（抽象的な）機能ユニット、ＮＴおよびＴＡは、非常に広範囲に組み込まれている−これは携帯型電話機の場合、通常行われていることである。
ネットワークアクセスおよびネットワークアクセスポイントという両概念のこの説明によって、ＨＯに直接かかわり得る携帯型（抽象的な）端末システム／端末機器、特に今日では（抽象的な）携帯型電話機が、１つの終端、および３つの非終端、（抽象的な）端末機器を含み得ることは明らかである：
■この終端端末機器は、本発明ではまず、ＴＫＶの（抽象的な）音響的／光学的／機械的なユーザ表面の（抽象的な）実現に用いられる。そして、
■これら通常３つの（抽象的な）非終端端末機器は、ＨＯにおいて、携帯型端末システム／機器と少なくとも２つの異なる携帯型ネットワーク／アクセスポイント／ファシリティとの共同動作に用いられる−この場合、後者は、「Ｆｅｍｔｏｃｅｌｌ」バリエーションの領域が、任意にわずかだけ互いに異なることがある。これら３つの非終端端末機器とは、
○一方においては、端末機器間の（抽象的な）データ交換のための（抽象的な）「スイッチ」−このスイッチは、場合によって限界的なものであり得る。例えばフェムトセル技術を用いる場合である−であり、そして
○他方においては、ネットワーク／アクセスポイント／ファシリティそれぞれのための２つのＴＡ／ＮＴである（Ｆｅｍｔｏｃｅｌｌ技術の場合、ＴＡ／ＮＴがただ１つのことがある）。
「直接のＨＯ」に関する電話機の能力が、一方では、ＧＳＭ／ＣＤＭＡ／ＵＭＴＳ／サテライト／Ｗｉｍａｘ等々のネットワークに関するものであり、他方ではインターネットに接続されたＷｉＦｉ−またはＦｅｍｔｏｃｅｌｌＷＬＡＮに関するものである場合、この電話機は「ＦＭＣ電話機」と呼ばれることがある（ＦＭＣ＝Ｆｉｘｅｄ／Ｍｏｂｉｌｅ Ｃｏｎｖｅｒｇｅｎｃｅ）：すなわちこの電話機は、インターネットの固定ネットワーク技術の、およびＧＳＭ／ＣＤＭＡ／ＵＭＴＳ／サテライト／Ｗｉｍａｘ等々のネットワークの携帯型ネットワークすなわち電話システムの、それぞれのユーザビリティの収束をサポートする。
図１はこのことを、抽象的なＦＭＣ電話機を用いる例で示す（第Ｃ．０項は、グラフィックなシンボルマークの意味を説明する）。この電話機は、
■一方においては、ＧＳＭ−ＴＡ／−ＮＴを経由して−これらはＦＭＣ電話機に内蔵されている−ＧＳＭ携帯型ネットワークへの一時的なアクセスを持つ（この場合、ＧＳＭ−ＤＵＥＡは、ＧＳＭネットワークの最も近いアンテナと、携帯型ＦＭＣ電話機におけるＧＳＭ−ＮＴとの間でＧＳＭネットワークに属する。いわゆる「無線インタフェース」である）。そして、
■他方においては、ＩＥＥＥ８０２．ｘｘ−ＴＡ／−ＮＴ−やはりＦＭＣ電話機に内蔵されている−を経由して、さらにＷＬＡＮへの一時的なアクセスを持つ（この場合、一時的なＩＥＥＥ８０２．ｘｘ−ＤＵＥＡは、ＩＥＥＥ８０２．ｘｘ−ＩＡＤとＦＭＣ電話機のＩＥＥＥ８０２．ｘｘ−ＮＴとの間でＷＬＡＮに属する。いわゆる「ＷＬＡＮ無線インタフェース」である）。このＷＬＡＮは、その「ａＤＳＬモデム」−ＴＡを経由してインターネット固定ネットワークへの（すなわち同固定ネットワークの「ａＤＳＬスプリッタ」ＮＴと電話ツイストペアケーブル−／ａＤＳＬ−ＤＵＥＡへの）アクセスを持つ。
ここで、ＩＡＤが無線インタフェース側に（＝非インターネット側に）「スイッチ」を備えることに留意されたい（ＦＭＣ電話機が無線インタフェース側にこれを備えるのと正確に同じ）：図１に記載するように、ＦＭＣ電話機とＩＡＤ間の（まったく同一の通信プロセスのための）データ伝送は、一方では、ＷＬＡＮ−ＮＴ（とパケット交換型のＷＬＡＮ）を経由して、他方では、ＧＳＭ−ＮＴ（と回線交換型のＧＳＭ−ＮＴ）を経由して行うことができる。
上記から、ＧＳＭ／ＣＤＭＡ／ＵＭＴＳの特性が見て取れる：このネットワークの場合、すべてのベースステーションが−大規模セルのプロバイダなので、技術的／ライセンス法規的／財政的条件として−大規模プロバイダとしての法的および営業的責任下にあり、したがって技術革新の実践導入が遅い。それに対してＩＥＥＥ８０２．ｘｘ−ＩＡＤ／−ＡＰは、それぞれ多数の小規模プロバイダとしての法的および営業的責任下にあるので、あらゆる種類の技術革新を−本願と同様に−短期間で使用できるようにするプラットフォームを提供する。
またＦＭＣ電話機は−図２に示すように（第Ｃ．０項参照）−１つのＴＡ／ＮＴだけで間に合わせることができ、例えば回線交換型およびパケット交換型のＧＳＭネットワークのためならば、１つの共通なＧＳＭ−／ＧＰＲＳ−ＴＡ／ＮＴだけで間に合わせることができる。したがってこの場合、ＩＥＥＥ８０２．ｘｘ−ＩＡＤをまったく省くことができる。にもかかわらずここでは通信プロセスにおいて、通常は高価な回線交換型のＬ３接続だけの利用と、少なくとも一部は若干安価なパケット交換型のＬ３接続の間で切り替えが可能である。この種の切り替えは、ネットワークＨＯではなくて、ファシリティＨＯである（第Ｂ章参照）。
さらに図５ｘでは、左側にＨＯに直接かかわる加入者を示す。右側の表示は、ＨＯＣＩＳ法が、特に通信プロセスの加入者として、このＨＯに間接的にのみかかわるものを予定することを示す。
Ｃ．０．図１および２の説明
図１で、１方向矢印は、その指し示す四角形中の表示内容に属する。双方向矢印は、データ伝送区間（ＤＵＥＡ）を表す。２つの傾斜する楕円形は、それぞれ回線交換型ネットワークを表す（例えばＧＳＭ／ＣＤＭＡ／ＵＭＴＳ／サテライト等々。ここでは「ネットワークＩ」ともいう）。そして楕円形の中に、ＩＥＥＥ８０２．ｘｘ−ＷＬＡＮ（「ネットワークＩＩ」）が、そのＩＥＥＥ８０２．ｘｘ−ＩＡＤ／ＡＰとともに組み込まれている。このＩＡＤ／ＡＰは、通常はインターネットへのアクセスを常時持っている（「ネットワークＩＩＩ」）。ＩＡＤ／ＡＰの信号の強さが十分である領域を、その周囲の実線の円で示す。これと同心の破線の円は、信号の強さが降下すること、または消えることを示す。
ネットワークＩＩが１次通信プロセスのコストにとって意味があるのは、ＡとＢとの間のネットワークＩＩではなく、ネットワークＩとネットワークＩＩＩだけである。したがってこれら両ネットワークはＨＯにとっても基準となる。この着目方法の場合、ＨＯ端末機器全体は、下記に関して、加入者ＡとＢ間の１次通信プロセスの中にある。
■ＦＭＣ電話機だけからなるネットワークＩと
■ＦＭＣ電話機とそのＩＥＥＥ８０２．ｘｘ−ＩＡＤとからなるネットワークＩＩＩ。
この場合、ＦＭＣ電話機はネットワークＩへのアクセスを常時持ち、ＩＡＤはネットワークＩＩＩへのアクセスを持つ。
ネットワークＩＩＩに着目するならば、ＨＯ端末機器全体は、ＩＡＤ＋ＦＭＣ電話機である。
ＦＭＣ電話機に着目するならば、
■この電話機は、ネットワークＩとネットワークＩＩに関して、ＨＯ端末システム全体である。
■しかしネットワークＩＩＩに関しては、上記のＨＯ端末機器の一部に過ぎない。
１次通信プロセスに着目するならば、ＦＭＣ電話機だけでなく、ＦＭＣ電話機＋ＩＡＤもまた、ＨＯ端末機器全体と見なすことができる。
図２には、（ただ１つのネットワークの）２つのファシリティに関する、すなわち
■「回線交換」ファシリティに関する、および
■「パケット交換」ファシリティに関する
ＨＯ端末機器全体を記載するが、これはＧＳＭ電話機だけに設けられているものである。
Ｃ．１．ＦＭＣ電話機だけにおけるＨＯＣＩＳ法の実施例
図１では左右両側とも下記を示す：
Ｉ．携帯型ネットワーク（ここではＧＳＭ基盤のもの）と、
ＩＩ．ＩＥＥＥ８０２．ｘｘ−無線ネットワーク（「ｘｘ」は例えば、ＷＬＡＮの場合「１１」、ＷＩＭＡＸの場合「１６」）と付随するＩＥＥＥ８０２．ｘｘ−ＩＡＤ
ＩＩＩ．上記にはインターネットへのアクセスをともなう。
ならびに、ネットワークＩ／ネットワークＩＩへの、地域を限定されない／限定されるアクセスをともなうＦＭＣ電話機。
ＦＭＣ技術のマーケット導入の初期段階では、図１は、ＨＯ関連でしばしば生じるＴＫ配置である。下記にスケッチするＨＯシチュエーションの例Ａ）〜Ｈ）では、左側のＦＭＣ電話機が、その時点の、または将来起こりうるＨＯに直接（または間接的に。これについてはここではこれ以上詳論しない）かかわるものであり得る：
Ａ）Ａユーザは、Ｉ．セルだけでなくＩＩ．セルにもあって、後者セルからちょうどＢユーザと電話しているにもかかわらず、後者セルを離れる。
Ｂ）Ａユーザは、Ｉ．セルだけでなくＩＩ．セルにもあって、後者セルからちょうどＢユーザを呼び出し、後者ユーザは「ｃａｌｌ ｓｅｔ−ｕｐ」手順をまだ終了していないにもかかわらず、Ａユーザは後者セルを離れる。
Ｃ）Ａユーザは、Ｉ．セルだけでなくＩＩ．セルにもあって、後者セルからちょうどＢユーザと電話しているときに、後者セルの境界領域に来る。
Ｄ）Ａユーザは、Ｉ．セルだけでなくＩＩ．セルにもあって、後者セルからちょうどＢユーザを呼び出しているときに（すなわち後者ユーザが「ｃａｌｌ ｓｅｔ−ｕｐ」手順をまだ終了していないときに）、後者セルの境界領域に来る。
Ｅ）ＡユーザはＩ．セルにあって、Ｉ．セルからちょうどＢユーザと電話しているときに、ＩＩ．セルに入る。
Ｆ）ＡユーザはＩ．セルにあって、Ｉ．セルからちょうどＢユーザを呼び出しているときに（すなわち後者ユーザが「ｃａｌｌ ｓｅｔ−ｕｐ」手順をまだ終了していないときに）、ＩＩ．セルに入る。
Ｇ）ＡユーザはＩ．セルにあって、Ｉ．セルからちょうどＢユーザと電話しているときに、ＩＩ．セルの境界領域に入る。
Ｈ）ＡユーザはＩ．セルにあって、Ｉ．セルからちょうどＢユーザを呼び出しているときに（すなわち後者ユーザが「ｃａｌｌ ｓｅｔ−ｕｐ」手順をまだ終了していないときに）、ＩＩ．セルの境界領域に入る。
本発明によるＨＯＣＩＳ法は、このほか類似する多数の将来起こりうる、あるいはその時点のＨＯシチュエーションの中で、スタート／動作させ／期間を切ることができる。加入者情報／加入者サポートをどのようにして実現するかについても、例示を省く。
第Ｃ．１項では、ＦＭＣ電話機Ａだけに−場合によっては電話機Ｂがサポートすることにより−本発明によるＨＯＣＩＳ法の実行を託している。その結果として、ＡがそのＷＬＡＮのアクセス可能領域を離れると、ただちに同方法実行のためのＦＭＣ電話機ＡとＢ間の「インターネット接続性」はキャンセルされる。
図２のＨＯ−ＴＫ配置は、図１のＨＯ−ＴＫ配置と２つの点で区別される。図２の配置は、１つにはファシリティＨＯをただ１つだけ可能とするが、ネットワークＨＯを可能としない。しかしもう１つには、すべての「ＧＳＭ／ＧＰＲＳだけの」電話機に対してはこのようなＨＯを可能とする。
Ｃ．２．定置型ＩＡＤだけにおけるＨＯＣＩＳ法の実施例
ここでは再び、図１のＨＯ−ＴＫ配置を出発点とする。しかしすべてのＨＯプロセスにおいて−８つの例を上記Ａ）〜Ｈ）に略記した−本発明によるＨＯＣＩＳ法は、ＦＭＣ電話機Ａの定置型ＩＥＥＥ８０２．ｘｘ−ＩＡＤで実行される。ＨＯＣＩＳ法実行を実行するためこのＩＡＤとＦＭＣ電話機との「インターネット接続性」時間インターバルは、第Ｃ．１項の場合にそのため利用できる「インターネット接続性」時間インターバルよりも大きい−このためＣ．１の場合よりも、ＡユーザのＨＯに関して、ＢユーザのＨＯＣＩＳの改善が可能となる。
例えば上記のケースＡで、ＩＥＥＥ８０２．ｘｘ−ＩＡＤ Ａは、その電話通話の間、インターネットを経由するＦＭＣ電話機ＢへのＬ３接続を、ＨＯＣＩＳの利用に供することができる。これは、Ａ側のＩＥＥＥ８０２．ｘｘ接続性がキャンセルされていることを、Ｌ３接続を経由してＢユーザに通知できるようにするためである。そしてさらには、上記のケースのいくつかにおいて、ＩＥＥＥ８０２．ｘｘ−ＩＡＤ Ａは、電話呼び出し／通話の将来起こりうるそして／または実際のＨＯが危険な段階にあるとき、Ｌ３接続を経由して両方の通信パートナーにＨＯＣＩＳを可能とする−特にＡによってＨＯに間接的にのみかかわりを持たされた通信パートナーＢに、これを可能とする。Ｂは、ＡによるＨＯの技術的なＨＯの危険性／必要性について、さもなければ何も知らない。この場合、ＨＯに直接かかわるＩＡＤは、直接かかわる終端端末機器に可能／有意義である以上に、はるかに早い段階でＨＯＣＩＳ法を開始し、そして／またはより長くその動作を行う。
Ｃ．３．インターネットサーバだけにおけるＨＯＣＩＳ法の実施例
ＦＭＣ電話機とそのＩＡＤ／ＡＰは、−図１に、インターネットのサーバだけを付け加えることになるほか−図１に記載するとまったく同様に配置することができる。したがってこの他の図は不要である。
ＨＯＣＩＳ法を実現するためにこのＴＫコンフィギュレーションを用いることが重要なのは、次の理由からである。すなわち、今日では何百万というすでにインストールされているＩＥＥＥ８０２．ｘｘ−ＩＡＤ／ＡＰと、それらのＩＥＥＥ８０２．ｘｘ／ＧＳＭ／ＣＤＭＡ等々の各電話機自体の大部分は−技術的に不十分なため−何らかのＨＯＣＩＳ機能を果たすことができない。しかし適切に構想された「ＨＯＣＩＳインターネットサーバ」（すでに通常の操作に用いられているＳＩＰサーバ、またはアナウンスメントサーバなどを、ＨＯＣＩＳのため適切に拡張したもの）を、上記ＩＡＤ／ＡＰおよび電話機のために動作させることができる。そのためには、サーバは、ＨＯに関するそれらの接続性の品質を観察し、ＨＯ関連情報を用いて、電話機のユーザのために同情報から導き出されたＨＯＣＩＳサービスを実現する。またサーバは、これら電話機の代わりとなって、あるいは電話機を経由して、これらＨＯ関連情報を準備する。
Ｃ．４．本発明によるＨＯＣＩＳ法の混合デザイン的な実施例
本方法が、上記でスケッチされた抽象的な「ＨＯＣＩＳサービスの設計バリエーション」３つすべてを使用できれば、本発明の方法によるＨＯＣＩＳ機能の品質が多くの点で改善できることは、容易に理解される。方法に関する請求項１の文言は、この「混合設計の長所の視点」を考慮に入れている：その文言／意味内容は、ＨＯＣＩＳ法のプロセス（第Ｂ章参照）の３種類すべてにおけるあらゆる「機能配分の視点」から独立している。
ＨＯＣＩＳ法は、その他何らかのサービスとの共同動作に限定されない−そのサービスが誰によって提供および／または実現されようと、例えばＭＩＨサービスとの共同動作にも限定されない。このような機能配分や操作の可能性を説明するため、１つの例を挙げる：
ＧＳＭネットワークプロバイダは、ＦＭＣ電話機からそのＧＳＭネットワークへのＷＬＡＮ呼び出しに対して、自らのＧＳＭネットワークに、一種の（魅力的な料金の）「スタンバイ」接続を構えることもできよう。そして、このようなＷＬＡＮ呼び出しに対して、常時かつ遅延なしで、（ＦＭＣ電話機とそのＩＡＤとの間のＬ３接続のための）「ローカルなＧＳＭフォールバック」、あるいは（ＦＭＣ電話機と第２の電話機との間のＬ３接続のための）「グローバルなＧＳＭフォールバック」を実行することもできよう−ただしこれには、携帯型ネットワークプロバイダが、このような「事前ＨＯサービス」にともなう諸問題を安価に解決できることが、前提条件となる。まずは本発明によるＨＯＣＩＳ法との共同動作が、そのプロバイダを実際にユーザに親切に、そして市場で魅力的にするであろう。すなわち、ユーザへの親切性を向上させるＨＯＣＩＳ法なしには、電話通話のこのようなＧＳＭフォールバック（言い換えればＨＯ）から、「サービス連続性」の希望の品質を決して得られないであろう。
■特に、グローバルなＧＳＭフォールバックが実行され、それについては、直接にはこのＨＯにかかわらない加入者が、次のことにより、暗黙のうちにのみ知らされる場合に、上記の品質は得られない。すなわち、その時点の電話接続が思いがけず中断し、続いてその加入者の電話機で改めて呼び出し音が鳴り、その加入者は呼び出しを受け入れた後で、たった今中断された通信プロセスを続行できることを思いがけず確認することによって、知らされる場合である−ただしこの場合、加入者は、その通信プロセスにとってのネットワーク切り替えをともかく感知し、中断を単に障害と感じないものとする。
■直接かかわる加入者もまた、ＧＳＭフォールバックの継続を介して、少なくとも部分的に暗闇の中に置かれる可能性がある。この加入者は、−彼の側から何らかの作動は行うが、その後は−他のＧＳＭ呼び出しが通信パートナーに「割り込まない」限り、通信プロセスのＧＳＭフォールバックが実際に成功裡に行われるかどうか、何も知らない。
■そして両方の加入者とも、−携帯型ネットワークプロバイダが事前ＨＯサービスを行っているのに−どこかでネットワークが一時的に短時間動かなくなったため、何らかの理由で、そのＧＳＭフォールバックが遅延する場合、さらに混乱することがあり得る。
この例は−ＨＯにおいてサービス連続性の高い品質を得るためには−「シームレスなＭＩＨ」でも、多くの場合、ユーザに親切なＨＯＣＩＳ法によるサポートを必要とする、ということを示す。この場合、このＨＯＣＩＳ法の具体的実現は、内容、機能配分、他のサービスとの調整の点で、何の限定も受けない。
Ｃ．５．ＨＯＣＩＳ法のユーザによる制御
ＨＯＣＩＳに関する前記各章で、その内容的な、そしてＨＯに時間的に近いユーザ情報の視点が前面に出て来たが、ここでは、ＨＯＣＩＳ法がその他の重要な視点の形成をも可能とすることに、短く触れたい。ＨＯＣＩＳ法は、ＨＯＣＩＳプロセスにおける少なくとも１人のユーザに、ＨＯＣＩＳを用いて下記を行う能力を与える：
■少なくとも１つのＨＯおよび／またはユーザにかかわるＨＯＣＩＳプロセスと、ユーザの過去および場合によっては未来に関する、いつもそれぞれ異なるその時点のステータス情報を呼び出す能力（自動車または航空機のナビゲーションシステムの場合と同様である）。
■少なくとも１つのＨＯおよび／またはユーザにかかわるＨＯＣＩＳプロセスの続行に関する、いつもそれぞれ異なるその時点の指示を入力する能力。
■ユーザの利用に供されている機能の選択および／またはユーザの端末機器におけるこのＨＯＣＩＳの表示に関する、いつもそれぞれ異なる指示を入力する能力。
ＨＯＣＩＳのここに挙げられた、ユーザが決定可能な機能と、そのローカルな−そして時間的な−表示のいくつかの例を、本願のいくつかの箇所で挙げている。それによれば、これらの機能やそのローカルな表示の内容の詳細は、本願の対象物ではない。本願の特許請求の範囲では、ＨＯＣＩＳ法の本発明による機能の基本的事実のみを取り扱う。すなわち（通信プロセスの端末機器にＨＯＣＩＳ信号が存在する場合の）第Ｂ章に詳しく示したＨＯに直接かかわる端末システム／−機能の「社会的」な反応機能を取り扱う。しかし本願の特許請求の範囲は、その反応の内容や表示の形成に何ら限定を加えるものではない。
Ｃ．６．本発明のＨＯＣＩＳ法／−装置のモデル化に関する追加事項
ＯＳＩ−ＲＭに基づくモデル化、および／または本発明による抽象的なＨＯＣＩＳ法／−装置の原理については、第Ｂ章で議論した。この原理の応用は、本願において、抽象的なＨＯＣＩＳ法システムおよび抽象的なＨＯＣＩＳ装置システムに到達する。これらのシステムは、第Ｂ章で、まとめてＨＯＣＩＳシステム（あるいはＳＴＫＶシステム）と呼んだものである。ＯＳＩ−ＲＭによれば、両方の種類のＨＯＣＩＳシステムとも、抽象的な機能構成要素（＝機能グループ）を含み、ＯＳＩ−ＲＭはこれらの構成要素を「エンティティ」と呼ぶ。これらのエンティティが、通信アプリケーションのＯＳＩ接続やそのサービスの抽象的実現に重要な場合だけ、ＯＳＩ−ＲＭはこれらのエンティティまたは機能構成要素に着目する。
ここに存在する通信アプリケーションは、本発明の場合２つの部分からなり、ＨＯＣＩＳ法と、ＨＯＣＩＳ装置−したがって上記２つの種類のＨＯＣＩＳシステム−とで構成される。これらシステムの上記のエンティティ、あるいは機能構成要素は、ＨＯＣＩＳ法またはＨＯＣＩＳ装置の実体的実現（＝実施形態）として、これら実施形態のソフトウェア−および／またはハードウェア−構成要素に、必ず再び見出される。
したがって本願は、特にＨＷ−／ＳＷ−機能構成要素からなるその抽象的なＨＯＣＩＳ装置に着目する−本願は、その装置を「ＳＴＫＶ装置」とも呼ぶ。請求項８０参照−この場合、機能的ＨＯＣＩＳ構成要素のＨＷ／ＳＷへの割り当ては全然重要ではない。重要なのは、抽象的なＨＯＣＩＳ装置の機能的構成要素の抽象的な実現が、次のものを用いて実現できるということだけである。
■独自のかつ機能的なＨＯＣＩＳ装置のＨＷ／ＳＷ構成要素、または
■同機能のそして／または機能上適切なＰＴＫＶのＨＷ−／−ＳＷ−構成要素、または
■まったく別のＴＫＶおよび／またはシステムの、同機能のそして／または機能上適切なＨＷ／ＳＷ構成要素（例えば、少なくとも１つのＯＳの、そしてこのＯＳに管理されている機能ＨＷ構成要素の上記ＨＷ／ＳＷ構成要素）。
第１のケースを除いて、「抽象的なＨＷ／ＳＷ ｒｅｓｏｕｒｃｅ ｓｈａｒｉｎｇ」が、ＨＯＣＩＳ装置構成要素と、別な上記システムの機能構成要素との間で行われる。この抽象的なＨＷ／ＳＷ ｒｅｓｏｕｒｃｅ ｓｈａｒｉｎｇは、これらＨＯＣＩＳ装置の実体的実現あるいは実施形態として再び見出されることがあり、あるいは見出されることがないが、前者の場合に「実体的なＨＷ／ＳＷ ｒｅｓｏｕｒｃｅ ｓｈａｒｉｎｇ」と呼ばれる。すなわち：ＰＴＫＶ−ＴＬＮにＨＯＣＩＳを与えたい場合、そのＰＴＫＶ−ＴＬＮにおける機能的なＨＯＣＩＳ装置端末システムで、このようなＨＯＣＩＳ装置を抽象的に実現するにあたっては、そのＴＬＮのＰＴＫＶの、そして／またはＯＳの、（そしてこのＯＳに管理されている機能的ＨＷ構成要素の）、それぞれ同機能のまたは機能上適切なＨＷ／ＳＷ構成要素を、抽象的なｒｅｓｏｕｒｃｅ ｓｈａｒｉｎｇによって共用することができる。
対偶論法による推論として：ＴＬＮのＨＯＣＩＳ装置端末システムの抽象的な実現は、場合によっては、ＴＬＮの少なくとも１つのＰＴＫＶ端末システムの独自かつ抽象的なＨＷ拡張を何ら必要としない。なぜならば、後者端末システムの抽象的なＨＷ構成要素は、「抽象的なＨＷ ｒｅｓｏｕｒｃｅ ｓｈａｒｉｎｇ」による抽象的な実現に、十分だからである。このことは、この実体的ＰＴＫＶ端末システムを用いてのＨＯＣＩＳ装置端末システムの実体的な実現にも当てはまる。しかしこのことは、ＨＯＣＩＳ装置端末システムの実施形態、すなわち実体的実現にとって、請求項８０を実現できるために必要な特性ではない。
抽象的なＨＯＣＩＳ装置端末システム−ＨＯＣＩＳ法に関する独立請求項は、実行可能と見なされる、そして全体をＭ（ＨＯＣＩＳ）と呼ばれる、何らかの機能的なＨＯＣＩＳ−ＳＷ構成要素だけを取り扱う−は、下記の抽象的なＨＷ−／ＳＷ−構成要素を含む（図４参照）。これら構成要素は請求項８０〜９１に記載の手段を実現するために用いられる：
■同端末システムのＳＷ構成要素とＨＯ関連情報とを記憶するための、少なくとも１つのメモリ（２）。Ｍ（ＨＯＣＩＳ）の同メモリを含む。
■これらＳＷ構成要素の機能を実現するための、少なくとも１つのプロセッサ（３）。
■少なくとも１つのネットワークを経由するＨＯ関連情報の、少なくとも１つの送信−／受信−構成要素（４）。
■ＨＯ関連情報の、少なくとも１つの収集−および／または準備−構成要素（５）。
■ＴＬＮ宛てのＨＯ関連情報の、少なくとも１つの伝達−／利用−構成要素（６）。
■複数のＨＷ構成要素を備える場合、その共同動作のための、少なくとも１つのインタフェース（１）。
本願は、ここではまず、ＨＯＣＩＳ法／−装置の実施形態を対象とする。これらの実施形態は、ＰＴＫＶ−ＴＬＮにいずれにせよ存在する実体的なＰＴＫＶ端末システム、そして／または実体的なＰＴＫＶ−サーバ／−ＩＡＤによって実現されている。そのためこれら端末システムなどには、さらにＨＯＣＩＳモジュールが少なくとも１つずつ設けられている（これによりこれら端末システムなどは、特殊な実体的ＰＴＫＶ−＆ＳＴＫＶシステムとなっている）。しかし本願の保護範囲は、このような実施形態には限定されず、−請求項１〜９１の文言／意味内容によって−ＴＬＮの上記実体的ＰＴＫＶシステムに例えば追加的なＨＷ機器が少なくとも１つずつ付け加えられている、ＨＯＣＩＳ法／装置の多数の実施形態を含む。
ＨＯＣＩＳシステムの抽象的なＨＷ／ＳＷ構成要素のモデル化をめぐる上記の議論−第Ｄ章でさらに詳しく行うが−は、純粋技術的な種類の（請求項の文言／意味内容による）ＨＯＣＩＳ特性を基本的に説明するためだけのものである。ある１つの具体的なＨＯＣＩＳ実施形態は、これら特性を実現するかどうかによって、その実施形態が本願の保護範囲に介入するかどうかを判断できる。
Ｃ．７．ＨＯＣＩＳ−ＩＳＲサーバとしてのＭ（ＨＯＣＩＳ）デザイン（ＩＳＲ＝Ｉｎｔｅｒａｃｔｉｖｅ Ｓｉｇｎａｌ Ｒｅｓｐｏｎｓｅ）
本発明によるＨＯＣＩＳ法の（より正確には、同方法のためのＭ（ＨＯＣＩＳ）の）、大量消費市場の興味を引く抽象的／具体的実現／実行コンセプトは、ＨＯＣＩＳ−ＩＳＲサーバである（第Ｄ章と、図５ｊ〜ｌ参照）。このようなＨＯＣＩＳ−ＩＳＲサーバは、何らかのデータ流中で何らかの信号の発生を発見して、それに反応することができる。そのとき同サーバは、信号に関係する加入者に適切なＨＯＣＩＳを供給する。
１次通信プロセスの加入者によるＨＯＣＩＳ−ＩＳＲサーバへのログオン、および／または照会は、音声によって、そして／またはキー組み合わせまたはＳＭＳの入力によって、または同加入者側で何ら入力を行わずに、ＩＳＰ（Ｉｎｔｅｒｎｅｔ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ）、またはＭＳＰ（Ｍａｎａｇｅｍｅｎｔ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ）、または第三者の側で入力することによって行うことができる。サーバは、「ＨＯＣＩＳ−Ｓｉｇｎａｌ−Ｒｅｓｐｏｎｓｅ」を−サーバが探している信号を、観察中のデータ流中に発見する場合−そのことを知らされるべき加入者に対し、やはりあらゆる任意のネットワークを経由して行うことができる。そのネットワークから、加入者の電話機は、メッセージを受信することができる。
Ｄ．請求項１の文言／意味内容の理解明確化のために
この第Ｄ章は、本願の意味内容および／または保護範囲が、本願の意図的に抽象的に構想された特許請求の範囲の文言、したがって網羅する範囲が明らかに広くなった特許請求の範囲の文言からではなく、本願の非常に限られた具体的な実施例説明から求められたり、それらの説明に限定されたりするのを防ぐのに、役立てるためである−これは確かに「特許論理上」は奇妙なことであり、特に特許法上まったく許容されないことであるが、それでも本願の筆者たちにとっては、彼らの別な特許においては法的な争いの中で生じたことがあり、したがって本願の文言の非常に強い特性となる。（特許の解釈方法／意味内容の特定方法のその他の方法よりも）請求項の文言による特許の解釈方法が優先することは、すなわちあらゆる特許法規の基準に、誤解の余地なく確定されている。
上記２つの理由から、第Ｄ章は、本願の発明の本質を、特に方法に関する独立請求項１と、特にはそれに続く多数の請求項によって−しかも、従属請求項グループにおける本発明の（包括的な）ＨＯＣＩＳ法の個々の本質的特性を、目的に合わせて開示することによって−明らかにしている。技術上この種の複雑な方法の（例えば本発明によるＨＯＣＩＳ法の）明確な本質は、−標準的な当業者ならわかるように−下記の古典的な特許出願書構成要素だけからは、推論できない。
（ａ）一般的に構想された請求項１の文言／意味内容。
（ｂ）具体的な実施形態の特別な説明（場合によっては図が付されている）。
しかし請求項１の文言／意味内容の本質について、明確な理解をこのように簡単に得られるようにするということには、多数の従属請求項を用いてこの意味内容の表示をツリー状展開することを伴う。しかもこの意味内容は、方法上の特性を開示する従属請求項グループに区分される（これについてはＤ．１項で説明した）。この場合、この手順が、方法に関するただ１つの独立請求項の意味内容（この意味内容は、（ｂ）を考慮の下に、欧州特許条約による（ａ）の解釈によって確定されている）の明確化も含むかどうかは、これ以上議論の必要はなかろう。
これによれば、理解を明確化するために、同等な従属請求項と従属請求項グループによって、請求項８０および８２の装置に関する独立請求項の意味内容の表示をツリー状に展開することについて、別個に議論することは不要と思われる。
しかし前もって２つの−一部は本願中ですでに述べた−視点に言及したい：
■本発明による方法／装置のそれぞれの本質的特性には−特に本発明による方法／装置のそれぞれの特性の「全体的関係」によっては−本願に挙げない限定は何ら加えられない。その全体的関係を正当化する言葉が本願にないという理由からは、このような「全体的関係」が誰によって推測されようと、どのような構造であろうと、そのような限定は加えられない。
■本願の請求項文言／意味内容すべてが、本発明による方法／装置のこれらの諸特性の本質だけを定義するので、本願は、−標準的な当業者には明らかな−これら諸特性の具体的な実現バリエーション、本発明の実施形態のいずれかにおける同バリエーションについて何ら述べない。むしろこれらの諸特性は、「機能的」、あるいは「抽象的」、したがって概念的なものである。
Ｄ．１．請求項１の請求項グループと、理解明確化の簡単化
たった今述べたことを考慮に入れながら、本願は、請求項１の文言／意味内容の理解明確化を容易にする。そのため本願は、同文言／意味内容を、従属請求項２〜７９でツリー状に展開して示し、これらツリー状に展開したものすべてを１１の「従属請求項グループ」に細分する：いずれのこのような従属請求項グループでも、そこで説明される諸特性、および／またはそれら特性のバリエーションは、（このグループの個々の従属請求項を用いて）直接対比され、すなわち、このような従属請求項に開示されることがない場合よりも、はるかに明らかに示される−その結果として、下記では、いずれの従属請求項グループもその「意味内容の焦点」のキャッチフレーズのような説明だけですでに、（欧州特許条約による請求項１の文言／意味内容の）特性／特性バリエーション／特性組み合わせの明確な理解を与える。この従属請求項のテクニックは、したがって、この明確な理解を得るのを非常に容易にする。
より正確に、別な言葉で再度述べると：請求項１による実施形態の個々の特性、またはそれら特性のバリエーションの理解は、これら従属請求項グループとそれぞれの短い説明とによって、不可避のものとなり、精細になる。これら従属請求項グループ（とこの第Ｄ章におけるそれらの短い説明）は、したがって、請求項１の文言／意味内容の明確な理解を得るのを、これら両者の記述をツリー状に展開することによって−請求項１の文言／意味内容だけから、理解を得るのは、考えの上では確かに絶対的に明確であるが、心理的には複雑であり、これと比べて−単純化することができる。この場合、請求項１の文言／意味内容の望ましい明確な理解を得るのをこのように容易化しても−従属請求項でそれら文言／意味内容をツリー状に展開することによれば−その文言／意味内容は決して変化を受けない。したがって、（この領域に対する「系統立て」および「完全性」という概念は、通常まったく定義できないから、という理由だけでも）このようなツリー状展開は、通常は、系統的にも、完全にも行うことはできないということ、そしてこのツリー状展開は、例えばそれぞれの特性／特性のバリエーション間で考えられかつ可能性ある相互依存のいくつかを示すことができるだけだということは、重要なことではない。
下記で行われた従属請求項グループの形成が有利なことを、従属請求項１０〜１９の例で証明する（Ｄ．５項も参照）。これらの従属請求項は、ＨＯＣＩＳ法における「プロセスの一時性」という特性を開示し、特には、本方法がどのような組み合わせでこの特性バリエーションを実現できるかを、意識させる−したがってその直接の結果として、請求項１の文言／意味内容におけるこれら特性バリエーションとその意味について、明確な理解を得るのが簡単になる。
ご覧のように、この従属請求項グループは、「プロセスの一時性」という特性のバリエーションに関して、少なくとも１０の組み合わせ可能性から構成される。この組み合わせ可能性をここでは、１０の「オーバラップ従属請求項」にツリー状に展開して示す。ＨＯＣＩＳ法に関する独立請求項の従属請求項グループは、請求項１による３つのプロセス（ＰＴＫＶ、ＳＴＫＶ、ＨＯ）の一時的なオーバラップの可能性について、必ずしもすべてを、したがって、これら特性バリエーションすなわちこの種のオーバラップに関して、ＨＯＣＩＳ法のすべての「特殊ケース」の必ずしもすべてを、明示的に開示しない。しかしＨＯＣＩＳ法のこの特性に属する「スペシャルケースグループ」すべては、これら１０の従属請求項によって、内容的に細部にわたって説明されている。その結果、ここに記載されたオーバラップ可能性に関する明確／精細な理解に基づけば、その他のこの種のオーバラップ可能性（あるいは特性バリエーションの組み合わせ）のいずれもが、標準的な当業者にとっては、この従属請求項グループに示されたこの種のオーバラップ／組み合わせの明らかなバリエーションに過ぎない。
したがってこのオーバラップ可能性についての明確／精細な理解に基づけば、この種のオーバラップを伴うＨＯＣＩＳプロセスは−この特殊な従属請求項グループで明示的には示されていないという理由だけでは−本発明のＨＯＣＩＳ法の保護範囲に属さないと、見なすことはできない。
ここで再び特殊な請求項グループ１０〜１９にかかわりなく、下記では、請求項１の文言／意味内容を明確に理解するために、この従属請求項テクニックを一貫して用いる。すなわち標準的な当業者には、このような従属請求項の網は、そのグループに属する「特殊ケースグループ」の要素であって、かつ請求項１の文言／意味内容に沿っているものすべてを、すでに開示する。あらゆるこのような請求項グループの網は、次のものを識別する。
■１つには、（請求項１の文言／意味内容によるＨＯＣＩＳ法の）少なくとも１つの特性およびそのバリエーションのグループ。および、
■もう１つには、これらの特性とそのバリエーションの組み合わせ可能性。
論理的には、上記によれば、着目された従属請求項グループに属する−より正確には、この請求項グループによってツリー状に展開されて表示される請求項１の文言／意味内容の理解に属する−ＨＯＣＩＳ法のすべての「特殊ケースグループ」は、同方法の「特殊ケースグループ」、すなわちこの特性や特性バリエーションの集合の組み合わせ可能性すべてに対応する同グループからなる。この場合、着目された従属請求項グループが、この／これらの特性およびそのバリエーションの組み合わせ可能性を、基本的な形で示した後は、これらすべての組み合わせ可能性の決定は、確かに時には非常に大規模であるが通常は些細な、「機械的」アクティビティである。しかし、このような従属請求項グループに関する下記の否認を参照されたい。
したがって１つの特性−特性バリエーションの組み合わせを持つ、本発明によるＨＯＣＩＳ法の１つの特殊ケース、すなわち、上記の特性集合／特性バリエーション集合を開示する従属請求項グループの少なくとも１つの従属請求項において、そこに明示的に示されていない特殊ケースは、請求項１の文言／意味内容によっては開示されていないと見なすことはできない−これら従属請求項グループの１つが、そのグループが識別した特性集合／特性バリエーション集合の組み合わせ可能性について、必ずしもそのすべてを使い尽くさないからという理由だけでも、そのように見なすことはできない（そのためにこの従属請求項グループは、付随する特殊ケースをすべて明示的に列挙する）。むしろ本発明によるＨＯＣＩＳ法のこのような特殊ケースは、通常、この従属請求項グループによって開示可能であると見なさなければならない。なぜならばこのグループからは−請求項１の文言／意味内容の理解を精細化／明確化するため−このグループの特殊な特性／特性バリエーションおよびその組み合わせ（例えばこの従属請求項が示すような組み合わせ）を、まず導き出すことができるからである。
この従属請求項テクニックを省略したいなら、そしてＨＯＣＩＳ法の特殊ケースのうち、同方法に付随する請求項の少なくとも１つに明示的に開示されている特殊ケースだけを、請求項１の文言／意味内容および／または同項の保護範囲に属すると見なしたいなら、このような保護範囲のこの種の定義は、無限大の個数の付随する請求項を必要とするであろう。しかしそのような省略は実際的でなく、法による「標準的な当業者」の姿に反することとなろう。彼は、従属請求項に関連する特性集合／特性バリエーション集合とその組み合わせの認識能力を、否認することになる。
付言するならば、従属請求項、そのすべての特性および／または特性バリエーション、そのすべての有意性ある組み合わせ可能性のいずれについても、その識別には、上記に述べたような統一的な系統立ては存在しない。請求項１の文言／意味内容に関する理解形成／−精細化／−明確化の各段階は、むしろそのときどきに独自に実行されなければならないが、これは通常はまったく単純であり、そして下記のように行われる。
■多くの場合、冗長的に行われる−「高度に冗長的」とまでは言えないにしても−すなわち１つの特性、または特性バリエーション、または組み合わせ可能性が、複数の従属請求項グループ、そして／またはそれら従属請求項グループの１つによって、１つ以上の（部分的）従属請求項で説明される。
■しかし時には非冗長的に行われる。すなわち、１つの特性／特性バリエーションが、正確に１つの（部分的）従属請求項によって、すべての従属請求項の集合において説明される−このため、これらの特性／特性バリエーション／それらの組み合わせは、「構成されている」ように見えるかもしれないが、これにより遅くともその箇所で明確に理解されることに変わりはない（これら特性等が、説明の他の箇所では明示的に除外される場合でも）。
そして上記の各段階は、決して従属請求項の集合に基づくだけではない。なぜならば、１つの特性、または特性バリエーション、またはそれらの組み合わせ可能性の１つについて、その説明を、
■本願での本発明による方法の別の説明において、行うことができるからである−ただしこの場合、請求項１の文言／意味内容が、この特性、および／または特性バリエーション、および／またはそれらの組み合わせを、決して除外しないものとする。
そして／または、
■その説明が、請求項１の文言／意味内容から直接得られるからである−ただしこの場合、この特性、または特性バリエーション、または組み合わせ可能性が、本発明による方法のこの他の説明において、決して除外されないものとするからである。
上記２つの列挙内容には、説明したばかりの「多数の従属請求項を用いるテクニック」／「従属請求項グループを用いるテクニック」に関する明らかな否認が含まれる。これら列挙内容が含意するのは、このテクニックを用いても、請求項１の文言／意味内容には、必ずしもすべてのその分岐事項に、またその網羅する範囲全体に、「従属請求項によって明示的に示されている」という述語を付加できないということである。むしろこのテクニックが用いられるのは、すべてこれらの分岐事項および全てを網羅する範囲の一種の「ハード・コア」に、「請求項によって明示的に示されている」という述語を付加するためだけである。請求項１の文言／意味内容が−その分岐の精緻さ、またはその網羅する範囲の点で−このハード・コアをはみ出す場合、そのことの確認は、標準的な当業者の手に任されている。
にもかかわらず、従属請求項形成には不可欠な、これらの認識／分析各段階の実行には、大きな利点がともなう：これらの従属請求項からは、請求項１の文言／意味内容に関する多数の特性と特性バリエーション、それらの組み合わせを一望することができる。これらは、不可避的に多数の従属請求項または部分的従属請求項を、明示的にアドレス指定／開示しなければならない。それは、求められている請求項１の文言／意味内容の明確／精細な理解を、簡単に得られるようにするためである。
ここまでは、この従属請求項テクニックを使用することの−必要性の証明ではないにしても−一般的な正当化である。この場合、基礎にある技術的方法は、ソフトウェア工学の領域に達するもので、本願においてもその通りである。したがって、その利点を下記に再度要約するのが妥当であろう。
ＨＯＣＩＳ法のここに示す具体的ケースでは、請求項１の文言／意味内容の「ハード・コア」の証明だけで、すでに大量である。しかし標準的な当業者はただちに、それでもこの証明が人を疲れさせるものでないことを認識する−すなわち、このハード・コアをはみ出る請求項１の文言／意味内容は、精緻でもあり、広範囲でもある。請求項１の文言／意味内容のこの−多くの従属請求項と従属請求項グループによって−明示的に示された「ハード・コア」は、請求項１の文言／意味内容における「道標システム」に過ぎず、決して当業者を疲れさせるものではない。このことからまず、上記ハード・コアを用いて誘導され／獲得された明確／精細な理解が得られる。
個々の請求項または従属請求項グループをＤ．５で説明する前に、Ｄ．２〜Ｄ．４項で、請求項１の文言／意味内容を詳細に理解するための概念的手段を説明する。
■Ｄ．２項は、まず請求項１の文言／意味内容の「理解明確化を簡単なものにする」ための本願のストラテジを示し、この目的のため、請求項１の個々の重要な文言／意味内容を説明する。
■Ｄ．３項は、この請求項１理解の「明確化を簡単化するストラテジ」をサポートし、そのため、簡単にグラフィック表示可能なＨＯＣＩＳ参照モデル（ＨＯＣＩＳ−ＲＭ）を、このストラテジの基盤に置く−すなわちこのモデルは、Ｄ．２ですでに説明した請求項１の文言／意味内容の理解の精細化／明確化を簡単なものにする。
■Ｄ．４項は、この請求項１理解の「明確化を簡単なものにするストラテジ」を、Ｄ．３を超える範囲にわたってサポートし、そのため、どのようにしてＨＯＣＩＳ−ＲＭのグラフィックを利用すると、請求項１の文言／意味内容の明確な理解が非常に簡単になるのか、１８個の図５を用いて、その例を図示する。
標準的な当業者は、請求項１の文言／意味内容の明確な理解を得るためのものとして、Ｄ．２〜Ｄ．４に図示されているすべての観察方法と手順を知っている。これらの方法、手順は本願の解釈をサポートする−すなわち、本願における上記方法・手順の説明は、当業者には、それらの応用を単純化するのに用いられるだけである。
Ｄ．２〜Ｄ．４項の説明−請求項１の基盤となる本発明ＨＯＣＩＳ法の諸特性について、その明確な理解のための説明−の後では、方法に関する従属請求項グループの明確な理解は、Ｄ．５項でわずかな語を用いるだけで得ることができる。
Ｄ．２．請求項１の文言／意味内容について、ＯＳＩ−ＲＭによってその理解を明確化／簡単化する
請求項１の文言は自然言語であって、その意味内容は直接理解でき、一意的である。図３ａのフローチャートは、その機能上の手順段階を示す。図中の箱は、ＨＯＣＩＳ法を請求項１に従ったものとするためには、いかなる手順段階の実現が同方法の実施形態を満足するかを示す。この関連で、本願では、個別あるいは全体的なＨＯ関連情報のそれぞれの内容または特性には着目せず、誰が誰にそれら情報を伝達するか、そしてそれらの情報が存在することだけに着目することを、記憶されたい。したがって特にここでは、固有のいかなる意味内容が、そもそもＨＯ関連情報を表示するのか、それをいつ通信プロセス加入者に表示するのかには、着目しない。ただし、上記の情報が「ＨＯと何らかの関係を持つ」という事実だけを例外とする（このことは、本発明による方法の具体的実施形態におけるあらゆるＨＯ関連情報にとって、疑いもなく確認できることである）。
Ｄ．２．１
標準的な当業者は、彼にとって扱いやすい−自然言語としての−ＯＳＩ−ＲＭ用語／概念に習熟しているので、彼のため、下記の疑似請求項１’によって、請求項１文言の意味内容の理解を明確化したい。この場合、両者文言の意味は同一なのに、疑似請求項１’は、請求項１の文言とは異なる文言である。図３ｂのフローチャートは、疑似請求項１’の機能上の手順段階を示す。
１’：
請求項１に記載の方法であって、すなわち、ＴＬＮのためそのＨＯＣＩＳ端末システム（すなわちＨＯＣＩＳ−ＯＳＩ接続の端末システム）において、（ＯＳＩ参照モデルによる、すなわちＨＯＣＩＳ−ＯＳＩ接続を用いて実現された）ＨＯＣＩＳサービスとして着目された方法であって、当該方法は、
Ｉ．上記ＨＯＣＩＳサービスが、ＨＯＣＩＳ−ＯＳＩ接続で、少なくとも１つの人ではないモジュールＭ（ＨＯＣＩＳ）によって、そのため準備されたＨＯ関連情報をＴＬＮに伝達し、
ＩＩ．またこのＨＯＣＩＳサービスは、１次−および／または２次ＴＫプロセスの少なくとも１つの端末システムまたはサーバで、少なくとも１つのそのための信号の存在が確認されるとともに開始するという、上記ＨＯＣＩＳサービスの特性を持ち、
また当該方法は、少なくとも下記の各段階、すなわち
ａ）上記ＩＩに記載の少なくとも１つの信号が存在するか、少なくとも１回点検する。そして
ｂ）上記Ｉに記載するサービスを実現する、
という各段階から構成される、方法。
疑似請求項１’の意味内容が、請求項１の意味内容より大きくないことは、標準的な当業者には明らかである。なぜならば、前者の文言は、その意味内容を後者より大きくするような一般化の余地がないからである。
しかしそれと反対に、疑似請求項１’における請求項１の意味内容の明確化とともに−ＨＯＣＩＳ法の意味内容の説明にＯＳＩ−ＲＭの用語／概念をより広範囲に利用することによって−請求項１の意味内容の限定が行われる可能性が、排除されなければならない。この場合、疑似請求項１’の意味内容／保護範囲が、請求項１のそれより小さくなり、そして疑似請求項１’は請求項１の真正の従属請求項となることとなろう。
続く疑似請求項１’’は、請求項１と比べて疑似請求項１’の仮説的な限定を明示的に示す：疑似請求項１’’に記載のＨＯＣＩＳ法は、論理的には請求項１の通りであるが、請求項１’の通りではない（なぜならば後者の限定を満足しないからである）。
１’’：
請求項１に記載のＨＯＣＩＳ法であって、下記が当てはまるもの：
ａ）この場合のＨＯ関連情報の伝達は、疑似請求項１’に記載のＨＯＣＩＳサービスではない。および／または
ｂ）この場合の伝達開始は、疑似請求項１’に記載のＨＯＣＩＳサービス開始である。
疑似請求項１’’によるＨＯＣＩＳ法が存在しないこと−疑似請求項１’は請求項１と比べて何ら限定を含まないこと−の証明は、瑣末なことである：疑似請求項１’’によるＨＯＣＩＳ法が存在するという仮定は、ただちに矛盾を生じる。なぜならば、そのことは標準的な当業者には、疑似請求項１’の通りであること、したがって疑似請求項１’’の通りではないことが証明されるからである。このことは上記の仮定と矛盾する。
請求項１の文言／意味内容の前者の理解を、この第Ｄ章では、さらに多数の説明によって明確化する。この場合、請求項１に関するこれらすべての説明は、そのいわんとするところに従って、疑似請求項１’にも適用する。
ＨＯＣＩＳ法の本質に関する下記の理解の明確化は、疑似請求項１’の文言による説明、すなわち、標準的な当業者が習熟している「ＯＳＩ−ＲＭの人工言語／概念」に基づく文言の説明を、ときどき用いる。しかし「ＯＳＩ−ＲＭの人工言語／概念」のいずれの明示的な使用も、次の場合に冗長である。すなわち、本発明によるＨＯＣＩＳ法／装置およびそれに付随する特許請求の範囲の文言について、自然言語による説明だけが、それら装置／文言の意味内容を、明確かつ誤解の余地なく定義する場合、すなわちその両義的な解釈の可能性を排除する場合、すなわちＯＳＩ−ＲＭの要請に対応する場合である。ＯＳＩ−ＲＭの人工言語／概念に対するこのような明示的な関係付け−例えばＳＴＫＶについての、すなわちより正確にはＳＴＫＶ−ＯＳＩ接続についての、請求項１に記載の関与構造の説明における当該関係付け−は、標準的な当業者のためにのみ、すなわち自然言語による請求項１について下記の理解明確化を、その当業者が正しく理解しているかの自己確認のためにのみ、意図されている。
Ｄ．２．２．まず請求項１が除外しないものについて、いくつか簡単な説明を行う。
■請求項１の文言／意味内容は、（ＰＴＫＶのＨＯに割り当てられている）本発明のＨＯＣＩＳ法にとって、「ＴＬＮ間の人／自動機械通信プロセスに対する限定」を含まない。すなわち、ＨＯに間接的にかかわる人な加入者（Ｌ７上にある）と、加入者の中で直接かかわる人ではないＭ（ＨＯＣＩＳ）、すなわち自動機械（同モジュールの中で何らかのＬｉ層に組み込まれているもの。ただし１≦ｉ≦７）との間の上記の限定を含まない。むしろこの文言／意味内容は、人／人の、および自動機械／自動機械の通信プロセスを形成する（第Ｂ章におけるＴＬＮの定義を参照）。
■請求項１は、「ＨＯＣＩＳ端末システムにおける内部通信に関する技術的詳細」を関知しない−請求項１は、「ＨＯ関連情報の伝達」という表現を包括的な意味で用い、従ってこの表現は何ら限定を含まない。「ＨＯ関連情報の伝達」という概念は特に、ＴＬＮにこの情報がいつのときか、そして何らかの方法で、知らせとして提供することを可能とする−ＴＬＮがその情報を実際に知らなければならないということは、この概念に含意されない。
■請求項１におけるＨＯ関連情報のＴＬＮへの「伝達」という概念は、特にこの伝達の通信技術的またはローカルな実現に関して、抽象化を行う。より正確に言うと、ＴＬＮへのこの伝達は、これにかかわる両方のＨＯＣＩＳシステム間でネットワークを経由して、ＴＬＮ端末システムの何らかの機能を取り入れながら行われ、あるいはローカルでＴＬＮ端末システム内だけで行われる。
■請求項１におけるＴＬＮに伝達するためのＨＯ関連情報の「準備」という概念は、その情報が人ではないモジュールＭ（ＨＯＣＩＳ）−ＴＬＮまたはその他のＨＯＣＩ端末システムにあるもの−に捕捉され、ＴＬＮに伝達するためそこから転送されることを含む。したがって、どこからＨＯ関連情報がＴＬＮに達するかには、ただ２つのバリエーションがある。この情報が準備されるのは、他のＨＯＣＩＳ端末システムのＭ（ＨＯＣＩＳ）によって、そして／またはＴＬＮ−ＨＯＣＩＳ端末システムのＭ（ＨＯＣＩＳ）によってである。今日の電話機は、本発明によるＨＯＣＩＳを、後者の方法で実現することはできないが、前者の方法によればおそらく可能である（図５の説明を参照）。
■請求項１に記載する「ＨＯＣＩＳ信号の存在の点検」という概念は、やはり何ら限定を受けていない：この概念は、その関係する可能性ある端末システム、および／またはＨＯＣＩＳ信号の存在の形態、および／またはその信号の種類について、まったく何ら記述しない。ＨＯＣＩＳ信号の存在の点検は、特にＨＯＣＩＳ端末システムで行われ、まったくいつでも開始できる。この場合、将来起こりうるＨＯが、点検を行う／点検された将来起こりうるＨＯＣＩＳ端末システムよりも、多数存在することができる。このことは、本発明の具体的実施形態において、ＰＴＫＶ端末システムとＳＴＫＶ端末システムを同一のものとすることができることと、矛盾しない（次の次の段落参照）。
請求項１によれば、ＨＯＣＩＳ法の具体的実施形態は、次の場合、ただちに本願の求める保護権に入る。それは、この実施形態が−将来起こりうるまたはその時点のＨＯに関して、何らかの端末システムにおける何らかのＨＯＣＩＳ信号の存在について、たった今議論した点検を行った後−このＨＯ関連情報の（このＨＯに適切にかかわるＴＬＮへの）伝達をスタートする場合である。すなわち、これは、ＴＬＮへのこの伝達がある程度成功することは、上記の保護権に入ることにとって、重要ではないということである。
ＴＬＮのＰＫＴＶおよび少なくとも１つのＳＴＫＶのためのＴＬＮの端末機器の相互の相違／同一性に関して、そして（人ではない）機能モジュールＭ（ＨＯＣＩＳ）に関して、そして請求項１におけるＨＯ関連情報のオリジナリティ／伝達に関しては、前記各章項ですでに述べたことと、さらに本項で挙げることに関して、特に下記に留意されたい：
■これらＰＴＫＶ機器とＳＴＫＶ機器は、１人／１つのＴＬＮの場合（抽象的な実現においても、具体的な実現においても）、同一でもあり得るし、あるいは一部または全体が互いに異なるものでもあり得る。後者の場合、ＴＫＶごとに、そして／またはＨＯごとに、そして／またはＴＬＮごとに異なるものであり得る。
■１つまたは複数のＨＯＣＩＳ端末システムが（より正確には、これらシステムそれぞれのＭ（ＨＯＣＩＳ）を用いて）、ＨＯ関連情報の成立および／または伝達に関与することができる。
■ＨＯ関連情報の成立、そして／またはそのＴＬＮへの伝達は、少なくとも１つのＭ（ＨＯＣＩＳ）に対し、すなわちそのシステムに対し、「静的に」前もって調和しているものであり得る。すなわち、このＭ（ＨＯＣＩＳ）システムでのみ少なくとも１つの特定の条件が発生する場合、そして／または少なくとももう１つのシステムを援用の下に、上記の成立、および／またはＰＴＫＶのＴＬＮに対するＨＯ関連情報の伝達が行われ、この場合、このＭ（ＨＯＣＩＳ）システムは、ＴＬＮ−ＨＯＣＩＳ端末システム自体であり得る。
前記に述べたことは、特に次のことを除外しない。
■ＨＯＣＩＳ−ＴＫＶのＴＬＮの少なくとも１人／１つが、そのＨＯＣＩＳ−ＯＳＩ接続の少なくとも１つの１つまたは両端末システムにおいて−その端末システムのいずれにおいても、その時点のＳＴＫＶ−ＴＬＮが、場合によってはどの時点でも常時あるいは一時的に切り替えを行うことができる−自動機械である。
■ＨＯが行われるＰＴＫＶの少なくとも１つの端末システムおよび／またはＴＬＮが、このＨＯに割り当てられたＨＯＣＩＳ−ＴＫＶのすべてのＨＯＣＩＳ端末システム／ＨＯＣＩＳ−ＴＫＶ−ＴＬＮと異なり、またその逆も真である。
■少なくとも１つのＰＴＫＶ端末システムが、（このＨＯに割り当てられたＨＯＣＩＳプロセスの）ＨＯＣＩＳ端末システムが利用するネットワークと、別なネットワークを利用し、この場合、両端末システムとも、少なくとも１つの共通なＰＴＫＶ−／ＳＴＫＶ−ＴＬＮを備えており、あるいは備えていない。
Ｄ．３．請求項１の文言／意味内容の理解を、ＨＯＣＩＳ−ＲＭに基づいて明確化する
前項における請求項１の文言／意味内容の基本的な理解明確化は、ＯＳＩ−ＲＭを基盤とすることにより行われた。ここでＤ．３項およびＤ．５項が示すのは、その理解の明確化／簡単化が容易に思いつかれるＨＯＣＩＳ−ＴＫＶが存在するということ、そしてそれらＨＯＣＩＳ−ＴＫＶの説明には、共通の「ＨＯＣＩＳ参照モデル」（ＨＯＣＩＳ−ＲＭ）が基盤となるということである−なぜならば、そうすることによって、他の場合にはこれらＨＯＣＩＳ−ＴＫＶのいずれもが必要とする説明の多くが、不要になるからである。
この第Ｄ章の冒頭に記載した課題は、本願の筆者に、彼の他の通信技術に関する特許に関して、腹立たしいことながら与えられたものであるが、この課題に直面すると、請求項１について、簡単にその理解を得て／理解を明確化するための、この−通常の状況では限度を超えていると見なされる−苦労は、正当化されるように見える。通常ならば、標準的な当業者が、請求項１のレクチャーの基盤として、自ら自然にこのようなモデルを用いるところであろう。
ＨＯＣＩＳ−ＲＭは、ＯＳＩ−ＲＭ（特に上記のＬ７標準）の基盤となる一般的原理、すなわちＴＫＶあるいは通信アプリケーションの分析の一般的原理から、必然的に得られる。下記に説明する当該Ｍ（ＨＯＣＩＳ）の特殊なモジュール細分化は、この場合ＨＯＣＩＳ法独特のものである。Ｍ（ＨＯＣＩＳ）のこの特殊なモジュール細分化と、図５におけるその利用は、ある特定のＨＯＣＩＳ法について、下記を簡単かつ明確に認識するのに非常に役立つ：
■そのＨＯＣＩＳ法が請求項１に該当するもの（あるいは疑似請求項１’に該当するもの）であるかないか。そしてこのことが、
■抽象的実現実施だけでなく、具体的実現実施においてもそうであるか。
ＨＯＣＩＳ−ＲＭおよび１８面にわたる図５についての下記の説明は詳細なものであるが、ご容赦いただきたい：
■標準的な当業者は、瑣末的ではない通信技術的方法について、その考え方としての基盤を、この種のＯＳＩ−ＲＭに基づいてモデル化するのが必要であることを知っている。このモデル化は、その説明文言が簡単かつ誤解なく理解されるようにするためである−すなわち標準的な当業者は、そのためＨＯＣＩＳ−ＲＭが必要なことを知っている。
■１８面の図５は、ＨＯＣＩＳ法の適用に関する理解を簡単化するのに用いられる−これらの図は、同方法の数多くの使用可能性のうち、重要なものだけを示す。
さて、ＨＯＣＩＳ−ＲＭの構造について。この図５の目的と領域についてだけ、われわれは、若干簡単化された（上記にすでに述べた）想定を行う。すなわち、抽象的なＳＴＫＶ端末機器の抽象的実現は、抽象的なＰＴＫＶ端末機器内で（すなわちここでは：抽象的な電話機および／または抽象的なサーバ／ＩＡＤで行われる）行われる、という仮定である。そうすればＰＴＫＶ−ＴＬＮには、独自のＨＯＣＩＳ端末機器は存在しない。しかしこの簡単化は、少なくとも１つの抽象的ＨＯＣＩＳ端末機器の抽象的な実現を、下記のようにして行うことを除外しない。
■複数の抽象的なＰＴＫＶ端末機器を用いて行う（すなわち「分散」する）。そして／または
■すべてを抽象的なＰＴＫＶ端末機器の外部で行う（すなわち「スワップアウト」する）。
−上記両者とも、図５のうち最後の各図で用いられている。この簡単化は、この方法に関する独立請求項にとってはいずれにせよ重要ではない（なぜならば、この独立請求項は、実現の視点から完全に抽象化するからである）。そして装置に関する従属請求項は、それが装置に関する独立請求項の基盤でないことを、明示的に開示する。
ＨＯＣＩＳ−ＲＭを説明するため、われわれは、ここで図５の最も重要な構造要素に着目する（これらの図の細部については、Ｄ．４項で説明する）。なぜならば、これらの図はＨＯＣＩＳ−ＲＭの本質的部分だからである。本質的部分は、機能的なＭ（ＨＯＣＩＳ）モジュールとそのＭ−Ｌｏ／Ｍ−Ｈｉモジュールに細分化されたものであり、そしてＭ−Ｌｏ／Ｍ−Ｈｉモジュール間に延びる点線である。（その他これらの図は、ＨＯＣＩＳ−ＲＭ自体にとっては重要でない若干の付属物を含み、これら付属物についてはそれを取り囲むものだけを示す。その２つの例として：太い両方向矢印。それぞれ１つのＴＫＶ−ＯＳＩ接続を表すものである。そして端末システムのボックス。これらはそれぞれ少なくとも１つのＭ（ＨＯＣＩＳ）を含み、その下に説明を付して、現実との関係を簡単に記した）。いかなるエンティティ、すなわちＰＴＫＶのモジュールが存在するかは、ここではまったく重要でないことに留意されたい−ただしＰＴＫＶ端末システムだけは例外とする。これについては上記を参照−したがって同システムは、ここには図示していない。
ＨＯＣＩＳ−ＲＭは、ＯＳＩ−ＲＭに応じた第４〜７層の抽象化レベルと意味内容に関して、そしてＭ（ＨＯＣＩＳ）に関して、今日しばしば実地適用されている簡単化を行う（例えば、Ｊ．Ｓｃｈｉｌｌｅｒ、Ｍｏｂｉｌｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ、１７ページ、ＩＳＢＮ−１３：９７８−０−３２１−１２３８１−７を参照）：ここで「Ｌ７」とは、ＯＳＩ−ＲＭのＬ４〜Ｌ７のすべてをいう−この場合、Ｌ７という太字印刷は、後続の表示を簡単化するため、ＯＳＩ−ＲＭ用語／概念を拡大したことを識別できるようにするためである。したがってこの表記法の簡単化は、ＯＳＩ−ＲＭの用語／概念−太字印刷なしでその後も用いられる−の変更も、請求項１の文言の意味内容の変更も含意しない。この簡単化に対応して、図５は、これらＨＯＣＩＳ−ＴＫＶ端末システム−これらシステムは、上記の簡単化のため、多くの場合ＰＴＫＶ端末システムでもある。上記参照−のうち、それぞれＬ７−Ｍ（ＨＯＣＩＳ）モジュールによる「Ｌ７−ＨＯＣＩＳ機能」を実現するものだけを示す。ここで言う実現するものは、上記左右の略式のＬ７−ＨＯＣＩＳ端末システム中で、ハッチングされた面によって示されている。ＯＳＩ−ＲＭの場合、Ｌ７−Ｍ（ＨＯＣＩＳ）すなわち「Ｌ７エンティティ」のＬ７−ＨＯＣＩＳインタラクションによるＬ７−ＨＯＣＩＳ機能は、ＨＯＣＩＳ−ＯＳＩ接続において、および同接続を用いて−より正確には、そのＬ７−ＨＯＣＩＳ−ＯＳＩ接続において、または同接続を用いて−実現される。
（図５冒頭の各図では２つの）Ｌ７−ＨＯＣＩＳ端末システムボックスについて若干説明する。ボックスの内側２つの欄は、それぞれＬ７−Ｍ（ＨＯＣＩＳ）を示すが、外側２つの欄は、各Ｌ７−Ｍ（ＨＯＣＩＳ）がその端末システムにおいて（抽象的に）実現される箇所を示す。すなわち、抽象的な電話機、あるいはＩＡＤ、またはその抽象的なユーザ、すなわち（存在するのであれば）ＴＬＮを示す。
後者すなわち外側の欄は、１つのＬ７−Ｍ（ＨＯＣＩＳ）を下記の抽象的実現レベル、すなわち抽象化レベルに区分する：
■上側の抽象化レベルは、Ｌ７−Ｍ（ＨＯＣＩＳ）の抽象的インタラクションのエンティティ−それが誰とのインタラクションであろうと−をモデル化する。請求項１に記載するＴＬＮにＨＯ関連情報を伝達するためである。
■下側の抽象化レベルは、Ｌ７−Ｍ（ＨＯＣＩＳ）の抽象的なインタラクションのエンティティ−それが誰とのインタラクションであろうと−をモデル化する。この情報の少なくとも一部のＨＯ関連の意味内容を補足／変更／廃棄／生成／等々するためである。すなわち、ＨＯ関連情報を（そして、上記のＬ７拡大によって付け加わったＯＳＩ−ＲＭのＬ４〜Ｌ６の意味内容を）、請求項１に従って伝達する前に準備する。
それに応じてＨＯＣＩＳ−ＲＭでは、あらゆるＬ７−Ｍ（ＨＯＣＩＳ）−エンティティ／モジュールが、「Ｌ７−Ｍ（ＨＯＣＩＳ）−Ｈｉ」 −エンティティ／モジュールおよび「Ｌ７−Ｍ（ＨＯＣＩＳ）−Ｌｏ」 −エンティティ／モジュールから構成される。
下記では、接頭語の「Ｌ７−」および接尾語の「−エンティティ／モジュール」を、多くの場合に省略する−また文字列「（ＨＯＣＩＳ）」および「ＨＯＣＩＳ」を省略することも多くなり、特にモジュールを表示するときにそうである。
下記に関するさらなる詳細も、ＨＯＣＩＳ−ＲＭにおいては着目しない。
■各ＨＯＣＩＳ−ＯＳＩ接続における各２つのＭ−ＨｉまたはＭ−Ｌｏの両種類インタラクション−誰とのインタラクションであろうと−に関する詳細、および
■伝達されるＨＯ関連情報に関する詳細。
ある１つのＨＯＣＩＳ−ＴＫＶが請求書１に記載のものか、そうでないかという問題は、ＨＯＣＩＳ−ＴＫＶ端末システムにおけるＭ−Ｈｉ−およびＭ−Ｌｏ−モジュールの、ＨＯ関連情報のＴＬＮへの供給および伝達への「関与」が決定する：このＳＴＫＶの少なくとも１つのＬ７−ＨＯＣＩＳ−ＯＳＩ接続への、Ｍ−Ｈｉ−およびＭ−Ｌｏ−モジュールの関与が決定する（すぐ理解できることである）。
それに応じて、ＳＴＫＶのＨＯＣＩＳ−ＲＭでは、そもそもそのＳＴＫＶの少なくとも１つのＬ７−ＳＴＫＶ−ＯＳＩ接続だけが着目され、この場合、このＨＯＣＩＳ−ＲＭは、
■当該接続のＴＬＮとのインタラクションを、ＴＬＮに対応するＭ−Ｈｉとのインタラクションとしてモデル化し、そして
■端末機器とのインタラクションを、当該機器に対応するＭ−Ｌｏとしてモデル化する。
換言するならば、ＨＯＣＩＳ−ＲＭにおいては、ＰＴＫＶ−／ＳＴＫＶ端末システムにおけるＰＴＫＶ−／ＳＴＫＶ−ＴＬＮが、Ｈ−Ｈｉによってモデル化され、Ｍ−Ｌｏは、端末システムのＨＯ関連情報の準備機能をモデル化する。したがってこれらのペア−（最後に挙げた機能、Ｍ−Ｌｏ）および（ＴＬＮ、Ｍ−Ｈｉ）−は、ＨＯＣＩＳ−ＲＭにおいてそれぞれが同義語である。しかし両者の同義語ペアのいずれにおいても、インタラクションのセマンティックスは、ＨＯＣＩＳ−ＲＭの範囲外にある。
ＨＯＣＩＳ−ＲＭにおいて、ＨＯ関連情報の準備と伝達の際、Ｍ−ＬｏまたはＭ−Ｈｉの「関与」という用語／概念は、非常に重要視される。この用語／概念は、Ｍ−ＬｏまたはＭ−Ｈｉが、請求項１によるＨＯ関連情報の伝達に「関与」することを記述する。ただしこの場合、これら情報は、これらモジュールの一部または全体によって、何らかの方法で生成され、そして／または捕捉され、そして／または内容あるいは表示が変更され、そして／または準備され、そして／または転送され、そして／または受信され、そして／または使用されるものとする。Ｍ−ＬｏまたはＭ−Ｈｉのこの関与は、それぞれのＭ（ＨＯＣＩＳ）が関与することを表す。この関与は通常は自動的に行われるが、場合によってはＴＬＮが起動することもできる。
このような関与を行うＨＯＣＩＳ−ＲＭのＭ−ＬｏまたはＭ−Ｈｉを、本願は、「リレー」あるいは「Ｌ７−リレー」と呼ぶ。（したがってＬ７−リレーは、ＯＳＩ−ＲＭのＬｉ独特の少なくとも１つのリレーについて、その概念を拡大したものである−より高次のＬｉ接続をＬ７接続とする、上記の概念上の拡大に従って）。ＨＯ関連情報伝達のイニシエータモジュールおよび宛先モジュールの両者のリレーは、この伝達の「エンドポイント」と呼ばれる。この場合、（請求項１に従って）宛先モジュールは常にＭ−Ｈｉであり、ＨＯ関連情報の伝達には、常に少なくとも１つのＭ−Ｌｏが関与する。ＨＯ関連情報伝達のこれら両者のイニシエーター−および宛先−ＨＯＣＩＳエンドポイントを、この伝達のその他の「リレーポイント」と区別するために、図５では、前者のエンドポイントを太い点または中空の点で、そして後者のリレーポイントを太い×印で表示する。２つのＳＴＫＶ端末システム間における、そして伝達のエンドポイントによって決定されるＨＯＣＩＳ関係は、一時的にまたは常時、そしてまた双方向または単一方向のものとして存在することができ、あるいはまったく存在する可能性がない。
簡単な場合、請求項１に記載するような２つのＳＴＫＶ端末システム間のＨＯ関連情報の伝達には、ＨＯに直接かかわる１つのＭ−Ｌｏと、間接的にかかわる１つのＭ−Ｈｉだけが、エンドポイントとして関与する。これらＭ−ＬｏとＭ−Ｈｉを、直接かかわるＭ−Ｈｉの電話機に内在する部分を経由して（下記参照）「リレー」して、これら両者を関与させる。あるいは間接的にかかわるＭ−Ｌｏを経由して、これら両者を関与させる。ただしこの場合、これらは両端末システム中にあるものとする。
１８面の図５中の点線は、−ＨＯ関連情報の伝達のため−Ｍ−Ｌｏ／Ｍ−Ｈｉをこのような関与に取り込む順序と、そのときどきの基本的なリレー機能を示す。点線のこのような経過を、ＨＯ関連情報伝達における「関与構造」と呼ぶ。
ＨＯＣＩＳ−ＲＭは、−例えば図５に示す簡単化のために限定された−請求項１の文言／意味内容の明確な理解を容易にする。特に、請求項１に記載するＨＯ関連情報のＭ−Ｈｉへの伝達において、この情報が下記において準備されたことは、容易に理解される。
■Ｍ−ＨｉのＨＯＣＩＳ端末システムとは異なるＨＯＣＩＳ端末システムにおいて。
■そして／またはこのＭ−ＨｉのＨＯＣＩＳ端末システムにおいて。
Ｄ．４．請求項１の文言／意味内容の理解を、図５によって簡単化する
ここでは、請求項１の文言／意味内容の明確な理解を、ＨＯＣＩＳ−ＲＭと１８面の図５を用いて容易化することについて述べる。この場合、すでに前記に述べた簡単化は、そのまま維持される。
Ｄ．４．１．
図５のＨＯＣＩＳ−ＲＭに関して不明瞭な部分が生じるのを防ぐため、特に次のことに留意されたい。
■Ｍ−Ｈｉと、Ｍ−Ｈｉによってモデル化された現実の電話機ユーザ（ＨＯＣＩＳ−ＲＭの外部に存在する）の感知−／生成−／理解機能との間の（抽象的な）インタラクションは、場所的には大部分が当該ユーザの頭の中で行われるが、一部はその電話機で行われる（電話の人間／機械のインタフェースの抽象的ハードウェア（例えばマイクロフォン、スピーカ、ディスプレイ、キーボードなど）であるため）。このことは、図５におけるＭ−Ｈｉの下辺のうち、低い方の部分に相当する。
■Ｍ−Ｌｏと、Ｍ−Ｌｏによってモデル化されたＨＯ関連情報の現実の準備機能（ＨＯＣＩＳ−ＲＭの外部に存在する）とは、本発明によって、Ｍ−Ｈｉがこのインタラクションの結果を知ることができるようにしなければならない。すなわち本発明によって、Ｍ−ＬｏはＭ−Ｈｉとコミュニケーションでき、そのため必要なＭ−Ｈｉ機能を含む（例えば、Ｍ−Ｈｉ宛のＨＯ関連の言語情報を生成し、Ｍ−Ｈｉへの音声チャンネルにフェードインさせるため）−これは、この電話機のユーザがＨＯＣＩＳ−ＴＫＶに関与しているかどうかに依存しない（例えば、同ユーザが電話機を自分でスイッチオフしている場合）。このことは、図５におけるＭ−Ｌｏの上辺のうち、高い方の部分に相当する。
したがってＭ（ＨＯＣＩＳ）のＭ−Ｈｉ／Ｍ−Ｌｏは、ＨＯＣＩＳ法において−およびＨＯＣＩＳ−ＲＭは−それぞれ「本来の」抽象化レベルに限定されていない：むしろＨＯＣＩＳ−ＲＭにおいては、Ｍ−ＨｉおよびＭ−Ｌｏの機能の部分が、それぞれ他の抽象化レベルに組み込まれていて、これらの部分はときどき「非本来的な」Ｍ−Ｈｉ／Ｍ−Ｌｏと呼ばれる。
Ｍ（ＨＯＣＩＳ）のエンティティ／モジュールを、ＨＯＣＩＳ−ＲＭの２つの抽象化レベルに区分することによって、本出の特許請求の範囲における文言／意味内容の理解を明確化するための、ある特定の−非常に技術的な−方法が容易になる。しかしこの区分は、省略することができる：その場合、請求項のいずれもこの区分を用いない。請求項すべてがＭ（ＨＯＣＩＳ）の厳格な区分を行わず、その代わりにいくつかの−そのような区分と比べて、より日常言語に近い、より簡単な、そしてまったく十分な−Ｍ（ＨＯＣＩＳ）属性を利用する。この属性を、Ｄ．４．１２項で要約／定義する。
Ｄ．４．２．
まず図５ａ〜ｂは、請求項１が、次のようなＨＯＣＩＳ法を含まないことを示す。すなわち、そのＳＫＴＶ−ＯＳＩ接続が（上記に述べたとおり、ＰＴＫＶ−ＯＳＩ接続には着目しない）、具象化されたＨｉ接続のみ、あるいはＬｏ接続のみのどちらかを、ＯＳＩ−ＲＭのＬ４〜Ｌ７に持つ、ＨＯＣＩＳ法である。それらの関与構造に基づく両種類のＨＯＣＩＳ−ＯＳＩ接続を、請求項１の保護範囲から除外する理由は−従来のＨＯＣＩＳ技術というものが存在しないため、それらの接続が従来のＨＯＣＩＳ技術に対応しないにもかかわらず（第Ａ章参照）−図５ａの関与構造が、明らかな（したがって保護可能な）ＨＯＣＩＳ技術を提供し、そして図５ｂの関与構造が何らＨＯＣＩＳ技術を提供しないからである：
■図５ａでは２人の電話通話者が、Ｈｉ接続を用いて、ＨＯに関して何らかの話し合いをしている−したがってお互いのために何らかのＨＯＣＩＳを実現していると推測される−しかしこのＨＯに直接かかわる、請求項１に記載するこの端末システムの人ではないモジュールは、このようなＨＯＣＩＳ−ＯＳＩ接続に（したがって同接続中を転送されるＨＯ関連情報に）関与しない。
■図５ｂでは、ＨＯに間接的にかかわる電話機ユーザは、このようなＨＯＣＩＳに関与しない。なぜならば、この場合のＨＯＣＩＳ−ＯＳＩ接続は−この接続は、Ｌ４〜Ｌ７に上記のＬｏ接続のみを含む−間接的にかかわるＭ−Ｈｉを関与させない。すなわち、このＨＯＣＩＳ接続は、そのＴＬＮにＨＯ関連情報を伝達しない。
しかし、請求項１に記載するＳＴＫＶ−ＯＳＩ接続が、さらにＨｉ接続および／またはＬｏ接続を含むとしても、それが同ＯＳＩ接続を妨害することはないことに、留意されたい。
Ｄ．４．３．
図５ｃ〜ｆの４面はまず、（例えば将来起こりうる、またはその時点の）ＨＯに間接的にかかわる電話機がＭ−Ｌｏを含まない点で単純な、請求項１に記載のＨＯＣＩＳ−ＯＳＩ接続のうちただ４つについて、その関与構造を示す−すなわちこの電話機の実現は、ＨＯＣＩＳ法を何らサポートしない。すなわち今日通常用いられる電話機である。
これら４つのＨＯＣＩＳ−ＯＳＩ接続の請求項１に記載するこの関与構造は、従って実用上重要なものであるが、この関与構造はさらに、ＨＯに間接的にかかわるＰＴＫＶ−ＴＬＮのためのＨＯＣＩＳの点で、請求項１に記載の発明の本質の核心を示す（直接かかわるＰＴＫＶ−ＴＬＮにとってのＨＯＣＩＳ法の重要性については、下記で観察する）。両者ＰＴＫＶ−ＴＬＮのいずれが、後続の図５それぞれで、ＨＯＣＩＳによるそのときどきの利益を得るかを、グラフィックに強調するため、そのＴＬＮに（他方のＴＬＮよりも）太い輪郭で表示した−これは、そのＭ−Ｈｉに「関与構造の末端がある」ＴＬＮでもある。
より正確には、これら４つの関与構造にひとたび習熟すると、図５ｉまでの「請求項１に記載する関与構造」は、ＨＯに間接的にかかわるＰＴＫＶ−ＴＬＮのためのＨＯＣＩＳに関して、誤解を招くものをもはや開示しない。特にここでコメントしたいのは−間接的にかかわる電話機がＭ−Ｌｏを含まない場合−両者端末システム間のコミュニケーションのためには、ＳＴＫＶのＨＯにかかわる情報を交換するために「音声チャンネル」だけが存在するということである（他方では、そのため例えば音声チャンネルに平行する「データチャンネル」が、ＳＴＫＶのＨＯ関連の非音声情報のため存在する場合がある）。
これら４つの図では、間接的にかかわる電話機ユーザが、彼に自然言語で伝達される（そして「音声チャンネル」を経由して伝達される）ＨＯＣＩＳを正しく理解することだけを想定する。このユーザのモデル化はこのことを−すなわち同ユーザがこのＨＯＣＩＳを正しく解釈することができることを−表し、この場合このモデル化は、同ユーザがＭ−Ｈｉを持つことを認める。すなわち、まったく「ＨＯを理解しない」または不在の、間接的にかかわるＴＬＮのモデル化は、Ｍ−Ｈｉを予想しない。
■図５ｃでは、ＨＯに直接かかわる電話機のユーザは、ＨＯＣＩＳ−ＴＫＶと何の関係もない。彼の本来的なＭ−Ｈｉはそれに関与しない（その電話機内の部分、すなわち彼の非本来的なＭ−Ｈｉだけが関与する。上記参照）−これは何らかの理由、例えば彼がＨＯＣＩＳ−ＴＫＶによって邪魔されたくなく、したがって彼のＨＯＣＩＳインタラクションを一時的に遮断しているため、あるいは彼が単純にそれを気に留めないため、といった理由による。この場合、ＨＯに直接かかわる本来的なＭ−ＬｏがＨＯＣＩＳ−ＴＫＶを起動し、ＨＯ関連情報を、間接的にかかわる本来的なＭ−Ｈｉに伝達する−この場合、前者から後者への伝達は、直接かかわる非本来的なＭ−Ｈｉと、間接的にかかわる非本来的なＭ−Ｈｉの中でリレーされる。この場合、第１のＭ−Ｈｉリレーは、請求項１に記載するＨＯ関連情報の伝達に関して、このリレーに対応する「解釈機能」を実現する（この場合：直接かかわるＭ−ＬｏのＨＯ関連情報のため、同内容のメッセージを人の言語で生成し、これを音声チャンネルで、間接的にかかわる非本来的なＭ−Ｈｉに、すなわち、まずこのメッセージをＴＬＮにリレーするスピーカまたはバッファに、フェードインする−これは、直接かかわるＭ−Ｌｏが、このＨＯ関連情報あるいはＨＯＣＩＳをＴＬＮに与えたいのが、いつであろうと同じである）。
■図５ｄが５ｃと異なるのは、ＳＴＫＶすなわちそのＨＯＣＩＳ−ＯＳＩ接続が、直接かかわる本来的なＭ−Ｈｉによって（すなわち直接かかわるＴＬＮのモデルによって）起動される点である。そうするとこの接続は、直接かかわる本来的なＭ−Ｌｏ（すなわち直接かかわる電話機のモデル）を関与させる（間接的にかかわる本来的なＭ−Ｈｉに伝達するため、ＨＯ関連情報を準備するためである）−その後は、５ｃと同様に進行する。直接かかわる非本来的なＭ−Ｈｉにおける、この経路上のリレーは、請求項１に記載するＨＯ関連情報の伝達に関して、このリレーに対応する（５ｃに追加された）解釈機能を実現する。すなわち、ＨＯＣＩＳ−ＯＳＩ接続の直接かかわるイニシエータによって選択された、かつ直接かかわる電話機の、かつＭ−Ｌｏで相応に捕捉されたものとしての、ＨＯ関連情報の選択を解釈する。
■図５ｅが５ｄと異なるのは、直接かかわるＭ−Ｌｏが、そのＭ−Ｈｉ（＝ＴＬＮ）によって選択されたＨＯ関連情報を−この情報は、間接的にかかわるＭ−Ｈｉに伝達するために、Ｍ−Ｌｏに対応して準備されている−確かに準備するが、その情報を、グラフィックなディスプレイを介して、自らのＴＬＮＭ−Ｈｉにだけに伝達できる点である。このＴＬＮ（＝直接かかわる本来的なＭ−Ｈｉ）は、この情報を、単独で例えば人の言語によるメッセージに「パッケージ」し、このＨＯ関連情報を、直接かかわる非本来的なＭ−Ｈｉ、すなわちそのマイクロフォンにリレーする−その後は図５ｃと同様に進行する。この場合、直接かかわるＴＬＮは、（図ｄに追加された）リレーとして反応する。
■図５ｆが５ｃと異なるのは、ＨＯに直接かかわる電話機ユーザがいないことである。これは、実際の状況として、例えば、直接かかわるＬ７−Ｍ−ＬｏがＨＯＣＩＳ−ＯＳＩ接続を起動する時点で、この電話機のユーザが、該当するＨＯの基礎となるＰＴＫＶを一時的に中断して、彼の電話機を別なＰＴＫＶ（今回のＨＯとは何の関係もないもの）に一時的に関与させることに相当する。その結果として彼は、前者のＰＴＫＶに関するＳＴＫＶについて何も知ることができない。このことは、直接かかわる本来的なＭ−Ｈｉが欠如することによって、ＨＯＣＩＳ−ＲＭの存在を証明する。したがってこのＨＯＣＩＳ法の場合、直接かかわるＭ−Ｌｏは、図５ｃのＭ−Ｈｉが備える機能の存在を証明する。
これらの図の関与構造で、次のことに留意されたい。
■これら関与構造のいくつかで、１つのモジュールが多重に関与している。請求項１によれば、このことは決して障害とはならない。特に請求項１は多重関与を必要とはしないので、下記の各図では、１つの関与構造における１つのモジュールの複数のリレーポイントのうち、ただ１つが証明される場合が増えている。このことは、次の事項と矛盾しない。
■非本来的なＭ−ＬｏにおけるＭ（ＨＯＣＩＳ）機能は、その非本来的なＭ−Ｈｉにおいて存在を証明でき、その逆もまた真である。その結果としてＨＯＣＩＳ−ＲＭは、前記両機能を、１つのＭ−ＨｉＬｏにまとめることもできよう−これにより時に生じる美的カテゴリの損傷は除外する。しかしこの損傷は、標準的な当業者であればそれを認識するであろう。そのためこの場合重要ではない。
ここまで説明した４面の図についてさらにコメントしたいのは、これらの図は、請求項１に記載する、ＨＯＣＩＳプロセスでのＨＯ関連情報の伝達の関与構造、かつそこでは間接的にかかわる電話機がＨＯＣＩＳプロセスをサポートできない（なぜならば、図中でモデル化されているように、この電話機はＭ−Ｌｏ機能を持たないからである）、このような関与構造すべてを示すものではないということである。すなわち標準的な当業者ならただちに認識することであるが、上記最後の４種類のＨＯＣＩＳ−ＯＳＩ接続すべてを、間接的にかかわるＰＴＫＶ−ＴＬＮによっても起動できる−例えばＤＴＭＦコードのキーを叩くことによって、または自然言語によるコマンドを入力したり、ＳＭＳメッセージまたはその他の信号を何らかのネットワークを経由して送信したりすることによってである（対応する機能別のＭ−Ｈｉによってモデル化可能である）。その受信のためには、直接かかわるＨ−Ｈｉおよび／またはＭ−Ｌｏが適切に反応する。付随する関与構造は、これまでの説明で明らかであり、ここではさらなる説明または議論を必要としない。
請求項１の文言／意味内容が、次のようなＨＯＣＩＳ法をも含むという事実に関する議論も、同様に不必要であろう。そのＨＯＣＩＳ法とは、前記文言／意味内容で求められる少なくとも１つのＨＯ関連情報の伝達前に、あるいは伝達時に、何らかの間において、何らかのさらなる情報交換、および／または何らかのインタラクションを意図する、このようなＨＯＣＩＳ法である。
請求項１に記載の最も基本的な「関与構造」ですでにこのように多様な種類があることは、次のことによって強調される。すなわち、左側または左右両側で着目されている電話機がＦＭＣ電話機であって、これらの場合、ＧＳＭ／ＣＤＭＡ−およびＷＬＡＮ−／Ｆｅｍｔｏｃｅｌｌ−機能が、様々なＨＯＣＩＳ機能を持つことである。こうして可能となった新たな関与構造は、前記の関与構造から「直線的に導き出し可能な」固定／携帯型の組み合わせなので、本願はこれらの関与構造についてこれ以上議論しない−なぜならば、標準的な当業者はこれら関与構造を難なく識別できるからである。すなわち、図５のＨＯＣＩＳコンフィギュレーションの例は、さらに簡単化された想定、つまり固定および携帯型のコンポーネントのＨＯＣＩＳ機能は、そのコンフィギュレーションが同一であるという想定である。請求項１はこのような限定を行わない−請求項１は、そもそもＴＫネットワークに関する限定を、明らかに意図しない。
Ｄ．４．４．
図５ｇ〜ｈの両図は図５ｃ〜ｄ両図に対応する関与構造を示すが、これらの関与構造は、間接的にかかわる電話機もまた完全なＭ（ＨＯＣＩＳ）を、すなわちＭ−Ｌｏをも含むことによって、可能となっている−「ＨＯを理解する」ＰＴＫＶ−ＴＬＮを伴ういずれの端末システムも、Ｍ−Ｈｉを含む−その結果として、両端末システムの間には、「音声チャンネル」だけでなく「データチャンネル」も、ＨＯ関連情報の伝達のために存在することがあり得る。両電話機やそれらのＴＬＮの間には、これまで通常はただ１つだった「コミュニケーションチャンネル」、すなわち「音声チャンネル」を補完するもの、またはそれに代わるものとして、ＨＯＣＩＳ法が、これらの機能を利用し、両Ｍ−Ｌｏの間で「データチャンネル」を動作させる。音声チャンネルまたは少なくとも１つのその他のネットワークバリエーションが利用するのと同じネットワークのデータチャンネルは、同じネットワークパラメータを用いることができる。
「サーバを用いない」ＨＯ関連情報伝達（通常は「加入者から加入者への」伝達）の場合、その関与構造に関するこれまでの議論を終えるに当たって、次のことをコメントしたい。すなわち、ここに例示したシナリオにおいて、ＨＯに直接かかわる端末機器であってＭ−Ｌｏを持たないもの−すなわち今日の「ＧＳＭ／ＣＤＭＡ専用」、または「ＷＬＡＮ専用」、または「ＦＭＣ専用」電話機−は、ＨＯＣＩＳ法を、より正確には、ＳＴＫＶを自らは起動できない。しかしこの端末機器が、ＨＯＣＩＳ−サーバ／−ＩＡＤ（またはＨＯＣＩＳ−電話機）と共同動作する場合、状況を変えることができる。この場合、これらＨＯＣＩＳ端末システムは、１つの「バーチャルなＭ−Ｌｏ」を実現する。それを下記に説明する。
Ｄ．４．５．
図５ｉ〜ｒの１０面はさらに、何らかのＨＯ関連情報をＰＴＫＶ／ＳＴＫＶ−ＴＬＮに伝達する場合の、請求項１に当てはまる関与構造の最も簡単な例を示すが、ここでは、図５ｉ〜５ｎの６面において、「ＨＯＣＩＳサーバ」−好ましくは「ＨＯＣＩＳ−ＩＡＤ」の特性を持つもの−の機能を援用する。ＨＯＣＩＳ−ＩＡＤをさらにもう１つ利用する場合については、図５ｏ〜５ｒの４面で説明する。
■これら１０面の図は、次の点を除いて、最も簡単な関与構造を示す。次の点とは、上記に説明した請求項１に当てはまるすべての関与構造が、ＨＯ関連情報伝達の際に繰り返されるが、それが、この伝達の基盤となるＳＴＫＶ−ＯＳＩ接続において、サーバ／ＩＡＤをＬ３−ルータとして利用することによって繰り返される点である。この場合、このサーバ／ＩＡＤは、ＨＯＣＩＳ通信アプリケーション自体に対しては、共同作用しない。より正確には、このＨＯＣＩＳ−ＯＳＩ接続のＬ４〜Ｌ７は、このサーバ／ＩＡＤを利用することをまったく意図しないので、その関与構造はＨＯＣＩＳ−サーバ／−ＩＡＤによっては変更できず、これはすでに上記で理解された通りである。
■むしろ下記ではサーバ／ＩＡＤが、少なくとも１つのＨＯＣＩＳ通信アプリケーション自体に対して共同作用する（より正確には、そのＯＳＩ接続におけるＬ７接続に対して）：このサーバ／ＩＡＤは、その少なくとも１つのＭ（ＨＯＣＩＳ）モジュールとともに、それらの関与構造に属する。このケースは特に、（将来起こりうる、またはその時点の）ＨＯにかかわる電話機自体が、ＨＯＣＩＳプロセスをサポートできない場合（この電話機がＭ（ＨＯＣＩＳ）を含まず、したがって普通の電話機である場合）に重要である：そうすると少なくとも１つのサーバ／ＩＡＤにおける適切な「代理Ｍ（ＨＯＣＩＳ）」が、この種の「非ＨＯＣＩＳ」電話機のＰＴＫＶ／ＳＴＫＶにおける、「ＨＯＣＩＳの不十分な点」を補償することができる−これについては下記で説明する。
■ＨＯＣＩＳサーバとＨＯＣＩＳ−ＩＡＤの相違点は、この場合特に、前者が通常技術的に「ＷＬＡＮから独立して」実現されていて、通常は「ＷＬＡＮから独立している」管理の下にあるのに対して、後者は通常何らかの方法で、少なくとも１つのＷＬＡＮにともかく依存している点である。
■これら１０面の図は結局、請求項１に当てはまる関与構造であってかつＨＯＣＩＳ−サーバ／−ＩＡＤを持つもののうち、−従来の簡単化を超える−追加的な簡単化を基礎とする点で、最も簡単な関与構造の例を示す。−すなわち、ＳＴＫＶ−ＯＳＩ接続の関与構造に、それぞれただ１つだけＨＯＣＩＳ−サーバ／−ＩＡＤが属する例である。しかしこのことは、ＴＬＮ−ＳＴＫＶ端末システムが、ある１つの時点で、ＳＴＫＶをただ１つだけサポートすることを意味しない。それを図５ｑ〜ｒの２面の図で、詳細に議論する。
標準的な当業者は、遅くとも、ＨＯＣＩＳ法（少なくとも１つのＨＯＣＩＳ−サーバ／−ＩＡＤによるサポートがあるものまたはないもの）の具体的実施形態に対するこの−図５ｉ〜ｒの１０面に関する下記の列挙事項を含む−理解に基づいて、次のことを問題なく確認できる。すなわち、ＨＯＣＩＳ−サーバ／−ＩＡＤのＯＳＩ接続の関与構造が、上記の簡単化のいずれも実現しない場合でも、その関与構造が、請求項１に当てはまるか、当てはまらないかを、確認できる。
■図５ｉは、「ＨＯＣＩＳ−ＩＡＤを含む簡単なＨＯＣＩＳコンフィギュレーション」に対する特に簡単な見方を示す：この図の右側のＭ（ＨＯＣＩＳ）は、５ｃ〜ｈのそれに相当する。他方で左側のＭ（ＨＯＣＩＳ）は、ＨＯＣＩＳ−ＩＡＤと、直接かかわる端末システムを区別せず、両者を１つのものとしてそれを基盤とする。説明上の理由から、ＰＴＫＶ−およびＳＴＫＶ−ＯＳＩ接続は、ここでは（以下においても）互いに別々に示されている。この場合両者ＯＳＩ接続の
○右側は、Ｍ（ＨＯＣＩＳ）の場合、共通なＰＴＫＶ−／ＳＴＫＶ−端末システムに末端があり、
○左側は、（ＰＴＫＶ−ＯＳＩ−接続の）ＰＴＫＶ−Ｌ７接続だけでなく、（ＳＴＫＶ−ＯＳＩ−接続の）ＳＴＫＶ−Ｌ７接続も、互いに独立して、それぞれＴＬＮ−ＰＴＫＶ−またはＴＬＮ−ＳＴＫＶ−端末システムに、または、ＰＴＫＶ−ＩＡＤ−またはＳＴＫＶ−ＩＡＤ−端末システムに（あるいはこれらを混合したものに）末端を持つことができる。したがって図５ｉでは、特にＳＴＫＶに関して−直接かかわる電話機のＭ−Ｈｉ−および／またはＭ−Ｌｏ−機能の全体または一部を、ＩＡＤ内で組み合わせ、あるいは両者の機器に相補的に配分し、あるいはＩＡＤだけに設けることができる。図５ｊ〜ｎはこのことをツリー状展開する。この場合、次の段落の関与構造を出発点とする。
したがって図５ｉでは、ＨＯＣＩＳ−ＩＡＤが−当該ＩＡＤがサポートする少なくとも１つのＳＴＫＶに関して−少なくとも下記３つのそれぞれ異なるＭ（ＨＯＣＩＳ）を含むことができる：
○間接的にかかわる電話機をともなうＩＡＤのＳＴＫＶのためのＭ−Ｈｉ。
○直接かかわる電話機をともなうＩＡＤのＳＴＫＶのためのＭ−Ｈｉ。
○Ｍ−Ｌｏ。その全体または一部が、これまで電話機内部のものと見なされていた直接かかわるＭ−Ｌｏの機能を実現できるもの−したがってＩＡＤ中のこのＭ−Ｌｏは、電話機またはそのユーザの上記の「代理Ｍ−Ｌｏ」、すなわちＩＡＤにおけるユーザの「バーチャルなＭ−Ｌｏ」である。
ＰＴＫＶ／ＳＴＫＶ端末システムの、またはそのユーザの、バーチャルなＭ−Ｌｏについては、下記でさらにしばしば言及し、−Ｄ．４．１２項に挙げた理由から−「バーチャルなＭ（ＨＯＣＩＳ）」と呼ぶ。これはＭ−Ｌｏ情報収集／−伝達を、場合によっては電話機内部のＭ−Ｌｏよりも良好に実現できる。そして例えばさらに、両方の電話機のＭ−Ｈｉ間の音声チャンネルへのアクセスを持つが、他方で電話機内部の直接かかわるＭ−Ｌｏは、間接的にかかわるＭ−Ｈｉへのアクセスをすでに失ってしまっている。
ここでは、ＳＴＫＶシステムのバーチャルなＭ（ＨＯＣＩＳ）／Ｍ−Ｌｏの接続性上の特性を指摘したい：このバーチャルなＭ−Ｌｏからの／によるＰＴＫＶ−ＴＬＮへのＨＯ関連情報の伝達には次のような場合がある。
■当該伝達には、ＳＴＫＶ端末システムにリレーを必要とする場合がある。本願は、このようなリレーが追加的Ｍ−Ｌｏ機能を含まない場合（またはそれ自体がＭ−Ｌｏである場合）、このリレーが存在しないと見なす−本願は、ＴＬＮ−ＰＴＫＶ／ＳＴＫＶ端末システムのそのようなバーチャルなＭ−Ｌｏを、当該端末システムに属するものと見なす場合がある。
■上記伝達は、「ＰＴＫＶチャンネル」に適した抽象的な情報チャンネル、かつＴＬＮにつながる同チャンネルを少なくとも１つ用いて、抽象的にいつも実現できる−いずれにせよ、ＰＴＫＶ端末システムのそもそも何らかの接続性が存在する場合のことである（図５ｐの説明を参照）。これは通常、このような抽象的実現の実体的実現に対しても当てはまる。
■上記伝達は、その単一方向性と低帯域要件があるため、それに適した放送ネットワーク／−ネットワーク特性を介しても、実現することができる。
標準的な当業者は、これらのケースすべてにおいて、これらＨＯ関連情報がＴＬＮに、このＰＴＫＶデータチャンネルの情報表示の形でのみ提供できるとは、結論付けられないことを知っている。例えば：このＰＴＫＶデータチャンネルが音声チャンネルであるならば、端末機器が適切なＤＴＭＦ機能を利用できるならば、そしてそれを十分に柔軟な的にプログラミングを実現をできるならば−これらの条件は今日多くの市販電話機に与えられている−ＨＯ関連情報をテキストとしてもユーザに提供することができる。またこの種の情報表示変換を放棄するならば（すぐ上記で言及したＴＬＮへの音声チャンネルを用いる場合に）、ＴＬＮ端末システムにおけるリレーを省けることを容易に思いつく−これは今日市販の電話機のユーザのＨＯＣＩＳとして、ＨＯＣＩＳ−ＩＡＤによるものを可能とし、その際これら電話機に何らかの変更を加える必要がない。ＩＡＤにサポートされたこの種のＨＯの大きな経済的重要性については請求項７０〜７９およびＤ．５項に記載する。
この場合、ＩＡＤにおけるバーチャルなＭ−Ｌｏには、その直接かかわるＷＬＡＮ−／Ｆｅｍｔｏｃｅｌｌ電話機の将来起こりうる、またはその時点のＨＯに関して、最終的にＴＬＮに伝達されるＨＯ関連情報の必ずしもすべてが、提供されるわけではない。むしろ「ＨＯ関連情報」の定義は、次のことを許容する。すなわち、このＭ−Ｌｏ（例えば直接かかわるＰＴＫＶ端末システムに関するＨＯ関連情報の当該Ｍ−Ｌｏによる収集）のすべてまたは一部が、少なくとも１つのＨＯＣＩＳ−サーバ／−ＩＡＤ／−電話に移し変えられること、そしてこのようにして場合によって共同して得られたＭ−Ｌｏ情報を−直接かかわる端末システムのＭ−Ｌｏによって捕捉されたのではないＨＯ関連情報が、このＭ−Ｌｏ情報に含まれていても−、ＴＬＮに伝達することを許容する。したがって請求項１にとって、直接かかわるＳＴＫＶ端末機器のためのバーチャルなＭ−Ｌｏ−例えばＳＴＫＶ−サーバ／−ＩＡＤにおけるもの−は、ＳＴＫＶ端末機器内部のＭ−Ｌｏと等価である。
すなわち特には、あるＳＴＫＶにおいて直接かかわるＴＬＮ−ＳＴＫＶ端末システムが、内部のＭ−Ｌｏを何ら含まないが、バーチャルなＭ−Ｌｏを（例えばサーバ／ＩＡＤ／電話に）持つ場合でも、このＳＴＫＶ関与構造は、このＴＬＮ−ＳＴＫＶ端末システムにおいてスタートする−すなわち、このバーチャルなＭ−Ｌｏの全体または一部を含む、ＳＴＫＶ端末システムにおいて、スタートするのではない。
下記で前面に出て来るのは、図５ｉにおいて、ＨＯＣＩＳ−サーバ／−ＩＡＤと、直接かかわる電話機との間では、請求項１に記載のＨＯＣＩＳ−ＴＫＶ／ＨＯＣＩＳ法（およびその関与構造）が、明示的に示されなかったということ−しかし本願にとって、特にこのように構造化されたＨＯＣＩＳ−ＴＫＶあるいはＳＴＫＶが重要であることから、これら両者はその理解の明確化を必要とすることである。このため図５ｊ〜ｎの５面の場合、したがって直接かかわるＳＴＫＶ／ＰＴＫＶ端末システムのＴＬＮは、太い輪郭を持つことになる。
Ｄ．４．６
図５ｊ〜ｋでは、（左側に示した）電話自体はＨＯＣＩＳ能力がないが、（右側に示した）ＩＡＤは、今説明したばかりのバーチャルなＭ−Ｌｏを含む。標準的な当業者は、このバーチャルなＭ−ＬｏにＨＯ関連情報を供給する、例えばＨＯＣＩＳ−ＩＡＤの内部または外部における「ＰＴＫＶの信号」などの適切な評価を供給する、様々な技術的方法を知っている。いずれにせよ、こうしてＨＯＣＩＳ−ＩＡＤは、ＨＯに直接かかわる電話機のためのＨＯＣＩＳ−ＴＫＶを操作することができる−しかもこれは、当該ＩＡＤのバーチャルなＭ−Ｌｏによってである（これについては上記で説明した）。
■図５ｊでは、ＨＯＣＩＳ−ＩＡＤのバーチャルなＭ−Ｌｏが、その準備したＨＯ関連情報を、電話機におけるＭ−Ｈｉすなわち電話機のユーザに伝達する−そしてＨＯＣＩＳ−ＩＡＤと非ＨＯＣＩＳ電話機との間にＳＴＫＶ（ＯＳＩ接続とその関与構造とを含む）を実現する。このバーチャルなＭ−Ｌｏが、ＰＴＫＶの「音声チャンネル」を利用したければ、同チャンネルに「書き込み」することができる−これには、音声チャンネルをＨＯＣＩＳ−ＩＡＤ経由でルーティングすることは、必ずしも必要でない。なぜならば、ＨＯ関連情報のそこでの「混合」は、請求項１に当てはまるもう１つのＳＴＫＶシステムを用いて、例えばＴＫネットワークで、実現できるからである。
■図５ｋが５ｊと相違する点は、ＨＯＣＩＳ−／ＳＴＫＶ−ＩＡＤが、Ｍ−ＨｉすなわちＳＴＫＶ−ＴＬＮ（このＳＴＫＶ−ＴＬＮと電話機におけるＰＴＫＶ−／ＳＴＫＶ−ＴＬＮとの間のＳＴＫＶのＴＬＮ）を含む点である。このＳＴＫＶ−ＴＬＮは、彼がどのようにして、直接かかわるＴＬＮのＭ−ＨｉへのＳＴＫＶ−ＯＳＩ接続を利用するかを、決定する−すなわちこのことは、図５ｊに示すように、バーチャルなＭ−Ｌｏによっては前もって決められていない。この場合、ＩＡＤのＭ−Ｈｉは、インテリジェントに動作する（両者ＳＴＫＶ−ＯＳＩ接続の間のＬ７−リレーとして、これら接続はそれぞれ、このＳＴＫＶ−ＩＡＤと、直接または間接的にＨＯにかかわるＴＬＮとの間にある）。そしてこのＭ−Ｈｉは、例えば両者ＴＬＮへの両者ＳＴＫＶが、互いに自立的、独立的に経過することなく、内容的に互いに適合されているようにする−その結果として、このＭ−Ｈｉは、これら２つのＳＴＫＶを、両者ＳＴＫＶ−／ＰＴＫＶ−ＴＬＮ間のただ１つの均質なＳＴＫＶとする（すなわち、ただ１つのＳＴＫＶ−ＯＳＩ接続と関与構造を持つものとする）。
両図では次のことに留意されたい：いずれのＭ（ＨＯＣＩＳ）も、一方の電話機ユーザにＨＯ関連情報を伝達するため、両者ユーザが同じ端末システムに組み込まれていない場合は、もう１つのネットワークをＰＴＫＶとして利用する−このことは当然先行するすべての各図にも当てはまる。
Ｄ．４．７．
図５ｌが図５ｋと異なるのは、基本的に次の点だけである。すなわち、電話機側にＭ−Ｌｏも存在し、したがって特にＨＯ関連情報の収集が、ＨＯＣＩＳ電話機でも、ＨＯＣＩＳ−ＩＡＤでも実行可能である、という点である。このＭ−Ｌｏによって可能となるＨＯＣＩＳ法のバリエーションの関与構造は、図５ｋにおけるのと同じである。これについてはその根拠をすでに上記で述べた。この点に関し図５ｊとの類似点は明らかであり、したがって説明を省略する。
Ｄ．４．８．
図５ｍおよび５ｎでは、ＨＯＣＩＳ−ＩＡＤが、直接かかわる電話機のためのバーチャルなＭ−Ｌｏを含まないか、あるいは１つ含む。したがって、直接かかわる電話機を経由するＨＯ関連情報の収集／準備／伝達を行う能力がなく、あるいは能力がある。ＨＯＣＩＳ−ＩＡＤは、両方の電話のためのバーチャルなＭ−Ｌｏを含むことができ、これら電話機自体は、両方がＨＯＣＩＳ能力を持つ必要はない（すなわち内部のＭ−Ｌｏを持つ必要はない）。前者の場合、その収集は、したがって電話機のうち次のような少なくとも１つにおいて行われなければならない。すなわち、ＨＯ関連情報を自らを経由して収集／準備／伝達できるようにしたい場合、自らのための内部のＭ−Ｌｏを必要とする電話機、そして／または、ＨＯ関連情報を他方の電話を経由して収集／準備／伝達できるようにしたい場合、他方の電話のためのバーチャルなＭ−Ｌｏを必要とする電話機においてである。しかしすべてのケースとも、ＨＯＣＩＳ−ＩＡＤの両者のＭ−Ｈｉ−これらは、図では別々のものとしてではなく、１つの共通なＭ−Ｈｉとして図示されている−において、ＨＯ関連情報の「調和」と、両者ＰＴＫＶ−ＴＬＮへの当該情報伝達を、少なくとも１つのＨＯに関してさらに行うことができる−これは、そのＨＯに関して両ＴＬＮ間に、すでに言及した均質なＳＴＫＶを得るためである−この場合、そのため用いられるすべてのＯＳＩ接続は、様々に異なるネットワーク、あるいはただ１つのネットワークを経由して実現される場合があり、また時間的に任意の弾力的な方法バリエーションで行われる。
Ｄ．４．９．
図５ｏ〜ｒの４面は、次のようなシチュエーションをモデル化する。すなわち、左側の電話機は、自らのため新たに基本的な接続性を確認するが、他方では（図５ｏの場合）、１つのＰＴＫＶを維持する。そのＰＴＫＶは、ＩＡＤの（例えばＷｉＦｉ技術またはＦｅｍｔｏｃｅｌｌ技術に基づく）ＷＬＡＮを経由して、またはその他のＧＳＭ／ＣＤＭＡ／ＵＭＴＳ／Ｗｉｍａｘなどのネットワークを経由して、ルーティングされて（電話機に接続されて）いる。あるいは（図５ｐの場合）、ＰＴＫＶを維持しないが、上記ネットワークの１つにチェックインされ、あるいは（図５ｑおよびｒの場合）、上記ネットワークのいずれにもチェックインされていない（第Ｂ章参照）−その結果この電話機は、この４ケースすべてにおいて、将来起こりうるＨＯに直接かかわっている。この基本的な接続性を、電話機ではなくネットワークが確認する場合も、同じことが当てはまる−したがってそのことをここでは再度議論しない。したがって直接かかわるＳＴＫＶ／ＰＴＫＶ端末システムにあるＴＬＮを、今後太い輪郭で示すことに留意されたい。
これら４つのケース５ｏ〜ｒは、したがってあるいは特に、次のことだけを説明する。
■電話機が基本的な接続性に入ること−そこから出ることではない。
■電話機ユーザにＨＯＣＩＳの可能性があること−ＨＯＣＩＳ−ＩＡＤ−ＴＬＮの可能性があることではない。
■この基本的な接続性が両側に存在する、あるいはまったく存在しないケース。
上記と相補的なケース−すなわち上記３つの条件の少なくとも１つが満足されないケース−については、ここでは説明しない。これらのケースに適していて、請求項１に当てはまるＨＯＣＩＳ法は、その図およびその容易に思いつかれる組み合わせによってもいずれにせよ表示されない場合、この第Ｄ章の議論からやはり「直線的」に得られる。
これらＨＯＣＩＳ法のそれぞれが非常に重要であることは、第Ｂ章の末尾ですでに強調した。付随するこれら４面の図とその説明は、これまで議論された「ＴＫコンフィギュレーション」における技術的複雑性と比較して、若干それとは別な、そして／またはそれに追加される複雑性を明らかにする。これら複雑性は、ＨＯＣＩＳの基盤にあるものである。この場合、この技術的複雑性は、基本的に変わらないままである：すなわち、ＨＯシチュエーションの点で電話機ユーザをサポートすることを指向し−このＨＯシチュエーションの技術的問題の解決を指向していない（第Ｂ章の末尾参照）。
図５ｏ：電話機がいずれかの箇所でチェックインされて、ＰＴＫＶをサポートする場合における、新たな基礎的接続性。基本的にここでは、前記で議論したＴＫ配置と、そのＨＯＣＩＳ関与構造のいずれをも、出発点とすることができる。この関与構造に、ここでは新たな基礎的接続性の発見がさらに加わる。図５ｏは、特に図５ｍを出発点とし、そして、新たなＨＯＣＩＳ−ＩＡＤ（図５ｍのＴＫコンフィギュレーションの下にあるもの）と、ＳＴＫＶ−ＯＳＩ接続の関与構造とを示す。当該接続は、電話機が新たなＨＯＣＩＳ−ＩＡＤ（これを新たなＳＴＫＶ端末システムとして）まで構築するものである。ここで留意されたいのは、ＰＴＫＶ−ＯＳＩ接続−より正確には：そのＬ３接続のルーティング−は、それらが将来この新たなＨＯＣＩＳ−ＩＡＤを経由して導かれるのか、それともさらに図５ｍに記載のＴＫコンフィギュレーションのＨＯＣＩＳ−ＩＡＤを経由して導かれるのかには、影響されないということである。
直接かかわるＳＴＫＶ／ＰＴＫＶ端末システムにおけるＳＴＫＶ／ＰＴＫＶ−ＴＬＮに伝達されるいずれのＨＯ関連情報も、請求項１に当てはまるのは、そのＨＯ関連情報が、現実のまたはバーチャルなＭ−Ｌｏによって（すなわち、図５ｏに示すように、その電話機自体におけるＭ−Ｌｏによって、または、例えばそのＰＴＫＶのルーティングにその時点で、または将来起こりうる時点で適しているＩＡＤに設けられているＭ−Ｌｏによって）準備される場合である。この場合特に下記に留意されたい。
■このＨＯ関連情報が、例えば何らかの方法でＳＴＫＶまたはＰＴＫＶの１つに入ることができ、そしてＰＴＫＶ−ＴＬＮ、または右側に示したＰＴＫＶ／ＳＴＫＶ端末システムのＭ−Ｈｉに次のことをさせることができる。すなわち、左側に示したＰＴＫＶ／ＳＴＫＶ端末システムにおける誰かに命令して、場合によっては新たなＩＡＤに対するＨＯを実行させることができる。
■図５ｎの左側に示すＰＴＫＶ／ＳＴＫＶ端末システムのＭ−Ｌｏを、そこからスワップアウトしたものとすることができる−これについては上記で説明した−その結果、このＰＴＫＶ−ＴＬＮは、非ＨＯＣＩＳ−ＦＭＣ電話または非ＦＭＣ電話を用いる場合でも、このＨＯＣＩＳを知ることができる（このとき、さらなる各ＨＯＣＩＳ措置および／またはＨＯ措置が、場合によって必要となるが、これは、標準的な当業者にとっては、ここで得られた理解によって明らかなことなので、これ以上立ち入った説明を必要としない）。そして
■上記２つ目の事項は、例えば新たなＩＡＤがＦｅｍｔｏｃｅｌｌの能力がある場合、あるいは別なネットワークのベースステーションである場合には、ますます当てはまる。
図５ｐ：電話機がいずれかの箇所でチェックインされるが、本来のＰＴＫＶをサポートしない場合における、新たな基礎的接続性。より正確に見ると、ここでは将来起こりうるＨＯに直接かかわる端末システムが、ＰＴＫＶを一貫してサポートすることができる（図５ｏと同様）−すなわちこの場合、この端末システムは、同時に２つのネットワークにチェックインされて、２つのＰＴＫＶを、例えばそれぞれ１つずつのネットワークを経由して、サポートする能力がある（このことは、場合によってすでに図５ｏの理解の際に考慮されるべきである。特にこれら両者のＰＴＫＶの１つは、「ＩＰＴＶ」−ＫＴＶまたは「ＩＰＲａｄｉｏ」−ＴＫＶまたはその他の「ＩＰＢｒｏａｄｃａｓｔ」−ＴＫＶ等とすることができる。これらのＴＫＶは、他方のＰＴＫＶとは異なるネットワーク、または異なるネットワーク特性を利用する）。
ここで説明したいのはむしろ、将来起こりうるＨＯに直接かかわる端末が上記の能力を持たない場合、まだ存在しないＰＴＫＶに関して、ＨＯＣＩＳ法における新たなＩＡＤ接続性を、場合によって考慮することについてである。
この点に関して、図５ｐでは、この端末システムがちょうどチェックインされている（そして場合によっては、何らかのＧＳＭ／ＣＤＭＡ／ＵＭＴＳ／Ｗｉｍａｘ／サテライトなどのネットワークのベースステーションとなる）ＩＡＤと、新たなＩＡＤだけに着目すればよい。
ここでまず理解する必要があるのは、ＨＯに直接かかわる電話機が、すでにこのシチュエーションでも−この電話機が、人のＴＬＮ間の「本来の」ＰＴＫＶ、前記では暗黙のうちに原則として受け入れて来た当該ＰＴＫＶが存在しない、またはまだ存在しない場合でも−請求項１に記載するＰＴＫＶをサポートすることである。これは「管理用ＰＴＫＶ」であって、人の電話ユーザが、ＩＡＤ（図５ｐでは右上に示されているもの）における電話機のチェックイン時に、自らと、このＩＡＤの自動機械ＴＬＮとの間で生成したものである。ユーザは、このチェックインから、ネットワークからのチェックアウトまで、この管理用ＰＴＫＶと明示的および／または暗黙のうちに共同動作し、またこの管利用ＰＴＫＶは、（Ｌ１上の）電話機の当初の基本的な接続性を拡張して、（Ｌ１〜Ｌ３上の）インターネット接続性とする。
したがって本願では、本来のＰＴＫＶは、しばしばＴＬＮによって−通常は彼が携帯型である場合−初めて開始することができる。それは、ＴＬＮのため、例えばＩＡＤによる実行中の管理用ＰＴＫＶが存在した後、すなわち、この管理用ＰＴＫＶを用いて、このＩＡＤにおける彼のチェックインが成功した後のことである。
その後は、上記で説明した図５のすべてにおいてすでに、ＨＯに直接かかわるＴＬＮのため、実行中の管理用ＰＴＫＶが存在する−しかしこの管理用ＰＴＫＶに着目が必要となるのは、ここが初めてである。それは、請求項１の文言／意味内容が、直接かかわるＴＬＮに関してこれらおよび後続のＴＫコンフィギュレーションをも捕捉することと、どのようにして捕捉するかを、示すためである。ここで留意されたいのは、請求項１は、そのＰＴＫＶが人／人のＰＴＫＶ等であることを要求しないことである（この点については、請求項グループ７０〜７９に関する後記のコメントを参照）。
さらに簡単／明瞭に見て取れることは、請求項１に該当する管理用ＰＴＫＶが、このようにアプリオリに存在する（場合によってはすでに実行中であり、これにより起動された本来のＰＴＫＶに追加されるものとして存在する）ことである。ただしこの場合、管理用ＰＴＫＶは、（図５ｐの右上に示した）ＩＡＤにおけるチェックイン直後、そして最初の本来のＰＴＫＶがスタートする前に、すでにもう１つの「管理用の端末間通信アプリケーション」をスタートする。それは、まずそのアプリケーションによって少なくとも１つの本来のＰＴＫＶをスタートするためである−例えば、直接かかわる電話機とその「ホームＩＡＤ」間に、（管理用の端末間通信アプリケーションとして）「ネットサーフィン接続」をスタートする。
また図５ｏの説明の最後の段落（３つの列挙事項を含む）は、このＴＫコンフィギュレーションにも当てはまる。
図５ｑおよびｒ：電話機がチェックインされていない場合の、新たな基礎的ＩＡＤ接続性。より正確に観察すると、ここで端末システムは、２つのネットワークに同時にチェックインされる能力がある場合（したがってこの端末システムが、２つの平行する管理用ＰＴＫＶをその両者のＩＡＤで、すなわち１ネットワークあたり１つの管理用ＰＴＫＶをサポートできる場合）、必ずどこかでチェックインされることが可能である。この場合、この端末システムは−図５ｐとは異なって−両者のネットワークを経由して、同時にさらに１つずつ本来のＰＴＫＶを、互いに独立してであろうとそうでなかろうと、操作するには適していない。
ここではむしろ、上記の能力を持たない端末システムのためのＨＯＣＩＳを説明する。このＨＯＣＩＳは、その端末システムが、その新たな基礎的ＩＡＤ接続性を確認した直後におけるもの（この場合ＩＡＤは、場合によってはさらに、ＧＳＭ／ＣＤＭＡ／ＵＭＴＳ／Ｗｉｍａｘ／サテライトなどの何らかのネットワークのベースステーションのためのものである）、すなわち、この確認に続く将来起こりうる、そして／またはその時点のＩＡＤにおける端末システムチェックインの際のものである−これにより端末システムは、その基本的な接続性を拡張して、そのユーザのインターネット接続性とする（そしてこのインターネット接続性を、例えばネットサーフィン通信アプリケーションによって最初からサポートする）。それを下記に説明する。
これを説明するため、図５ｑは、ただ１つのＩＡＤへの基本的な接続性を持つ端末システムを示す。このＩＡＤを経由して（すなわちそのネットワークを経由して）、端末システムはそのＴＬＮのインターネット接続性を可能とすることができる−他方で図５ｒは、端末システムが複数のＩＡＤへの基本的な接続性を持つことができるが、そのＴＬＮには、インターネット接続性として、これらＩＡＤのただ１つを経由するものだけを可能とすることができることを示す（端末システムは、これらＩＡＤが正確に１つを経由するこのインターネット接続性が実際に生じる前に、そして場合によってはそれと平行して、少なくとも１つの別のＩＡＤを経由するインターネット接続性を生成できるか／できないかを確認しているのであるが）。
図５ｐの説明から容易に見て取れることであるが、端末システムは、このシチュエーションにおいても−端末システムがまだネットワークにチェックインされていないが、すでにネットワークへの基本的な接続性を確認済みの場合−すでに請求項１に当てはまるＰＴＫＶ、すなわち図５ｐですでに説明した管理用ＰＴＫＶをサポートする。この管理用ＰＴＫＶは、定義によれば、この端末システムのために／において基本的な接続性を確認した時点以降、この端末システムのＴＬＮのために存在する（第Ｂ章参照）。覚えておいていただきたいが、この管理用ＰＴＫＶは次のような目的を持つ。すなわち、新たなＩＡＤの自動化されたＴＬＮを経由して、基本的なＨＯにかかわるＰＴＫＶ端末システムの（通常は人の）ＴＬＮのためのインターネット接続性を−後者ＴＬＮとの共同作業として−生成し、維持し、このＩＡＤからチェックアウトするときに終了する、という目的である。
管理用ＰＴＫＶによってインターネット接続性を生成する間、請求項１に記載のＨＯＣＩＳは、（基本的なＨＯにかかわるＰＴＫＶ端末システムにおける）ＴＬＮに対して、実際に通常のこととして、方向付けおよび判断のための重要なサポートを提供する。これは、下記を考えるならばただちに理解される（第Ｂ章および例えば従属請求項７０〜７９を参照）。
■ＰＴＫＶ端末システムが新たな基礎的接続性を確認した時点で、このＰＴＫＶ端末システムがそのＴＬＮのために−より正確には、このＰＴＫＶ端末システムのＭ−Ｌｏが、そのＴＬＮのために−すでに
○一方では請求項１に該当する管理用ＰＴＫＶをスタート済みであり（上記参照）、
○他方では、このスタートが請求項１に該当する最初の管理用ＰＴＫＶスタートである必要はなく、この時点で、少なくとも１つの別な平行する管理用ＰＴＫＶを、このＭ−Ｌｏによってすでにスタート済みとすることができる（このことは、例えば互いにオーバラップするＷＬＡＮの場合に生じ得る）。そして、
■このＴＬＮは、新たなＩＡＤおよびそのネットワークを経由する将来起こりうるインターネット接続性（場合によっては通信アプリケーションによる。上記参照）によって、通常は、
○−管理用ＰＴＫＶの基本的なＨＯに属する−「管理用ＳＴＫＶ」について何かを知りたいとされるのは（知りたいとされるとしてもそれは）、このインターネット接続性（場合によっては通信アプリケーションを含む）が実際に生成可能な場合に限られる。他方では、新たな基礎的接続性自体は、通常はＴＬＮの関心をまったく引かない。これは特に、この接続性がそのため目的とする通信アプリケーション（例えば上記のそのため目的とするネットサーフィンアプリケーション）を利用できない場合にそうである（この場合留意されたいのは、管理用ＰＴＫＶ端末システムによる基礎的接続性の確認は、同システムにより／においてＨＯＣＩＳ信号の存在が確認されることと同じ意味、したがってこのＰＴＫＶの基礎的ＨＯに属する管理用ＳＴＫＶのスタートと同じ意味である）。そしてこの場合、
○ＴＬＮはこの将来起こりうるインターネット接続性を、完全自動的に、または単純な措置によって、すなわち例えば、そのＴＬＮ−ＰＴＫＶ−および／またはＴＬＮ−ＳＴＫＶ−端末システムの少なくとも１つにおける、少なくとも１つの機器の「ｚｅｒｏ ｔｏｕｔｃｈ」または「ｏｎｅ ｔｏｕｔｃｈ」によって、使用できることを希望する。
上記の諸説明は、例えば電話機のユーザが、図５にスケッチされて上記に説明された様々なバリエーションのＨＯを、利用したい、または評価したい、または回避したい、または背景調査したい、または受け取らなければならない場合、ＨＯＣＩＳ法がその電話機のユーザに、実際に重要な方向付け／判断のサポートおよび単純化を与えることを、誤解の余地なく示す。一方では、経済分野にとって無視できない、常在的かつ持続的な、あらゆる場所のあらゆる人に対する、ＴＫサービス提供の氾濫に直面して、そして他方では、この分野におけるすべての人の常に増大する不可避的なモビリティに、そして迅速に増大するそれらの人数に直面して、特にＴＫコンフィギュレーション５ｏ〜ｒ（とそれを理解すること）は重要である：これらのコンフィギュレーションから特に明瞭に認められるのは、ＨＯＣＩＳ法と、それを装備したＴＫ端末機器によって、携帯型ＴＫサービスユーザが、この氾濫をできるだけ簡単に利用できるようになるということと、いかにして利用できるようになるかその方法である−すなわち、これらユーザからすべてのＴＫ技術個別情報（例えば彼らの基礎的接続性に関する情報）を遠ざけることができるようにする。そしてＴＫ技術の素人に期待される、そして素人の要請に対応してコンフィギュレーション可能な、より多くのＨＯ−「ｃｏｎｖｉｎｉｅｎｃｅ ｉｎｆｏｒｍａｔｏｎ ｓｕｐｐｏｒｔ」を、自動化された方法でこれらユーザに提供できるようにする（例えばＨＯ決定の際には、ユーザには見えない状態でその技術的および経済的品質が前もって点検され、良好と見られたものが選択される。そして自動化された方法で、あるいはユーザによるＴＫ端末機器のワンタッチによって、このユーザが利用できる−これによりユーザにとって、物理的および心理的に複雑な要素と、広範囲にわたる心理的な不完全さとは、その大部分が軽減される。これら複雑な要素と不十分さは、上記の氾濫を処理するため、今日のユーザ表面において、ユーザに課されるはずのものである。
Ｄ．４．１０．
ＨＯＣＩＳ−ＯＳＩ接続の関与構造の特殊な例に関する上記の議論から、次のことを明らかにしたい：これらの関与構造により、ＨＯＣＩＳ法の本質について、包括的かつ明確な理解が容易に得られる。すなわち、関与構造とそれに関する図５は、請求項１の文言／意味内容をツリー状展開することはできない−この展開を行うのは、まず請求項１の多くの従属請求項と、従属請求項グループである。しかしこれら上記の説明は、請求項１に記載する数多いＨＯＣＩＳ法のいずれに対しても、多数の抽象的な実行バリエーションが存在することの例を再び示す。この場合、これらバリエーションには、特にＨＯＣＩＳ機能をその他のサーバやＴＫネットワークに様々に配分することが含まれる。
Ｄ．４．１１．
このような関与構造の例についての議論に従って、請求項１に記載のＨＯＣＩＳ法またはそのスタート条件に関し、もう１つの一般的な−一部は冗長的な−コメント／メモを下記に記載する。
■ＨＯ関連情報、あるいはＨＯＣＩＳ情報、あるいはＳＴＫＶ情報のＰＴＫＶ−ＴＬＮへの伝達は、この情報のターゲットＰＴＫＶ端末機器、またはターゲットＳＴＫＶ機器にとって、
○十分透過的（＝見えない状態で）に行うことができる。その場合は、ＴＬＮに伝達するためこの情報を準備するモジュール、すなわちＴＬＮ端末システムまたはその他の端末システムなどにおける当該モジュールが、この情報を、このＴＬＮのＰＴＫＶ言語で、そしてＰＴＫＶが利用するネットワークを経由して伝達する。その結果、このターゲットＰＴＫＶ端末システム／ターゲットＳＴＫＶ端末システムの、ＴＬＮの下にある少なくとも１つの機器が、この情報を、ＨＯＣＩＳ情報としては認識できず、最初にこのＰＴＫＶ−ＴＬＮがそれを認識し、そして、
○上記伝達は、見える状態で行うことができる。その場合は、Ｍ−Ｌｏが、ターゲットＰＴＫＶ端末機器またはターゲットＳＴＫＶ端末機器のＭ−Ｌｏに、ＨＯＣＩＳ−ＰＤＵとして（そして場合によってはＰＴＫＶが利用するそれとは異なるネットワークを経由して）、この情報を伝達する。最初は後者のＭ−Ｌｏが、ＴＬＮが感知できるＨＯ関連情報を、そこから抽象化して、ＰＴＫＶ−ＴＬＮに伝達する。
■ＳＴＫＶは、少なくとも１回、人ではないＭ（ＨＯＣＩＳ）のＨＯ関連情報を、ＰＴＫＶ−ＴＬＮに伝達しなければならない。こうして伝達された情報がＨＯ関連のものなのかどうか、そしてそれはいつＨＯ関連であるのかについては、ここで詳細に説明する必要はない−それは通常は明らかなことであって、いずれにせよ標準的な当業者は、疑義のあるときでもこれを認識できる、ということで十分である。特に下記について考慮される。すなわち、ＨＯ関連情報は、
○多数のそれぞれ異なるコーディング、および／または様々に異なる表示の形でも、
○他のおよび／または様々に異なるフィルタ／他の情報への投影との、多数のそれぞれ異なる組み合わせ／オーバラップの形で、
現れる場合がある。ＨＯ関連情報が、そのターゲットＴＬＮをそのようなものとして最終的に認識できる限り、上記その他の情報のうちいずれも、ＨＯ関連情報を非ＨＯ関連情報とすることはない。
■ＰＴＫＶ−ＴＬＮへのＨＯ関連情報の伝達は、下記のように行うことができる。
○この伝達は、少なくとも１つのネットワークを経由するそのＰＴＫＶ／ＳＴＫＶ端末システムへの、この情報の−伝達に先行する−伝送を要求することができる。すなわち「間接的に行う」ことができる。この場合、このような伝送のモダリティは、ＨＯＣＩＳ法にとって重要ではない（そして、ＨＯ関連情報がバーチャルなＭ（ＨＯＣＩＳ）によって伝送される場合、ネットワークを経由する伝送は重要である。図５ｉの説明を参照）。このようなケースは、ＰＴＫＶ−ＴＬＮがこのＨＯに間接的にかかわる場合に生じる。
○この伝達は、上記ＰＴＫＶ／ＳＴＫＶ端末システム自体で（またはその少なくとも１つのバーチャルなＭ（ＨＯＣＩＳ）で、図５ｉの説明参照）生じたものであり得る場合、「直接行う」ことができる。このケースは、ＰＴＫＶ−ＴＬＮがこのＨＯに直接かかわる場合に生じる。直接伝達されたＨＯ関連情報は、上記端末システムの（またはバーチャルなＭ（ＨＯＣＩＳ）の）少なくとも１つの「ＨＯＣＩＳ試行」の結果である。この試行は、そのペアになるＭ（ＨＯＣＩＳ）を少なくとも１つ持つ少なくとも１つのネットワークを経由して、「ＨＯＣＩＳ接続」を、すなわち、ＴＬＮに少なくとも１つのＨＯ関連情報を−第Ｂ章に説明したように−伝達するに適し、かつその能力ある「ＨＯＣＩＳ−ＯＳＩ接続」を、生成しようとするものである（他のケースにおいては、このＨＯＣＩＳ接続は、ＨＯＣＩＳ−ＯＳＩ接続ではない）。
すなわち、このＰＴＫＶ／ＳＴＫＶ端末システムのＭ（ＨＯＣＩＳ）（またはそのバーチャルなＭ（ＨＯＣＩＳ））は、上記システムへのその時点の接続性を改善するため、少なくとも１つのＰＤＵを上記システムに送信している。このＭ（ＨＯＣＩＳ）のこのような能動的な通信試行ＨＯ関連情報を確実に得るためのもの−の結果は、まったく様々に異なるものが生じる可能性がある：例えば
◆Ｍ（ＨＯＣＩＳ）は、上記システムへのＴＬＮ接続性改善の作業を継続できるよう、その期待する少なくとも１つのＨＯＣＩＳ−ＰＤＵを受け取らない。あるいは、
◆何らかのプロトコルを実行し、そしてＨＯＣＩＳ−ＯＳＩ接続に基づいて、「ＨＯＣＩＳ接続性」へのＴＬＮ接続性を改善する。
すべてのケースにおいて、−このＭ（ＨＯＣＩＳ）に由来する−上記結果を含むＨＯ関連情報のＰＴＫＶ−ＴＬＮへの伝達が行われる。
前段落で括弧に囲まれたテキスト部分は、ＴＬＮ−ＰＴＫＶ／ＳＴＫＶ端末システムの、またはその少なくとも１つのＰＴＫＶ−ＴＬＮのバーチャルなＭ（ＨＯＣＩＳ）が、ＨＯＣＩＳ試行をスタートさせることができることを、明示的に示す。この試行は、このシステム／ＴＬＮの「バーチャルなＨＯＣＩＳ試行」、別な場合は「リアルなＨＯＣＩＳ試行」と呼ばれる。
バーチャルなＨＯＣＩＳ試行において、バーチャルなＭ（ＨＯＣＩＳ）は、例えばＩＡＤに組み込まれるものとし、このＩＡＤのＷＬＡＮには、非ＨＯＣＩＳ−ＦＭＣ電話機がちょうどチェックインされた状態とすることができる−そしてＨＯ関連情報のＰＴＫＶ−ＴＬＮ（電話機ユーザ）への「直接伝達」は、通常はその音声チャンネルを経由して行われるであろう（この伝達の視点については、請求項８０に関するコメントで、もう一度詳しく取り扱う）。
■特に「ＨＯＣＩＳ信号」という用語の意味に関して、次のことをコメントする／想起されたい：
○ＨＯＣＩＳ信号は、−あらゆるＨＯＣＩＳ−ＰＤＵ、ＨＯＣＩＳ−ＳＤＵ、ＨＯＣＩＳ−等々と同様に−ＨＯ関連情報であって、ＨＯに関してデジタル表示される情報の抽象的なキャリアである−これについては第Ｂ章ですでに詳論した。そして「値のパラメータ」および／または「参照パラメータ」を含むことができる。前者パラメータは、そのパラメータ値自体を含むが、後者パラメータは、その値またはその値が識別される箇所の参照を指示する。このようなＨＯ信号が少なくとも１つの端末システム内に存在するためには、その信号の、可能性ある少なくとも１つの参照パラメータの値が、その端末システムに存在する必要はない。
○端末機器／端末システムにおけるＨＯＣＩＳ信号の存在、またはＨＯ関連情報の準備は、それら信号／情報のローカルな生成、および／またはローカルな受け取り、および／またはネットワークを経由する受信によって成立する。それらの技術的および時間的なモダリティについて、ここで議論する必要はない。
○このようなＨＯＣＩＳ信号またはＨＯ関連情報の受け取り／受信／送信は、次のようなプロセス／サービス／アプリケーションによって、またはそれらに対して行われる。これらプロセス等は、本発明によるＨＯＣＩＳ法とは何ら関係がないので、ここでは着目しない。しかしこのようなプロセス／サービス／アプリケーションは、上記のローカルな、またはローカルでない受け取り／伝達、またはネットワークを経由する送信／受信によって、本発明による方法を利用し、したがって請求項１の保護範囲に介入する−そしてこのことは、部分的なＨＯＣＩＳ信号、またはＨＯ関連の部分的情報に関する場合にも、当てはまる（しかしこの場合、介入の原因が上記だけにとどまらない場合がある）。
■その他、ＨＯＣＩＳプロセス（あるいはＨＯＣＩＳ−ＴＫＶ）という用語と、ＳＴＫＶという用語が、本願においては同義語であることを想起されたい−すなわち両者は特に「２つのＴＬＮプロセス」である必要はなく、ｎ≠２として「ｎ個のＴＬＮプロセス」であることが可能である。したがって、
○請求項１の文言の最初の段落を、次のように変えることができる。
「ハンドオーバ・コンビニエンス・インフォメーション・サポート（ｈａｎｄｏｖｅｒ ｃｏｎｖｅｎｉｅｎｃｅ ｉｎｆｏｍａｔｉｏｎ ｓｕｐｐｏｒｔ）」（ＨＯＣＩＳ）を実現する方法であって、少なくとも１つのＨＯＣＩＳを実現する−２次遠隔通信プロセス（ＳＴＫＶ）の加入者（ＴＬＮ）のため、前記ＴＬＮの、原因となる少なくとも１つの１次遠隔通信プロセス（ＰＴＫＶ）における少なくとも１つのＨＯに関して、上記ＨＯＣＩＳを実現する方法であって、
この場合、・・・
ここで請求項１に意味内容は変更されていない。したがってＨＯＣＩＳ法は、１つのＳＴＫＶ法と見なしてよいことが、根拠付けられている。
○方法に関するすべての従属請求項の導入部分の文言「ＨＯＣＩＳ法」によって、付随するただ１つのＨＯＣＩＳ−ＴＫＶあるいはＳＴＫＶ、または付随するＨＯＣＩＳ−ＴＫＶあるいはＳＴＫＶの全体を表すことができる。
■第Ｂ章末尾で指摘したことを想起されたい。すなわち、本発明による方法は、ＰＴＫＶのＨＯに間接的にかかわるＰＴＫＶ−ＴＬＮだけでなく、このＨＯに直接かかわるＰＴＫＶ−ＴＬＮをもサポートできる。請求項１の「ｊ」のケースは、間接的にかかわるＴＬＮに相当し、請求項１の「ｊｊ」のケースは、直接かかわるＴＬＮに相当する。前者のケースは、特に従属請求項６９までにツリー状展開され、特に図５ｃ〜ｉで説明されている。第２のケースは、特に従属請求項７０〜７９でツリー状展開され、特に図５ｉ〜ｒで説明されている。
■請求項１の文言における様々な「または／あるいは」は、ＨＯ関連情報がいずれにせよ１つのＳＴＫＶだけに知られている可能性がある限り、多くの場合重要でない−したがってこれらの「または／あるいは」は、ＨＯＣＩＳ法の実体的実現において、ＰＴＫＶの実体的実現が、ＳＴＫＶのＨＯ関連情報の準備と伝達を生じることだけを、特には本来のＭ−Ｌｏの、および／または非本来的なＭ−ＬｏまたはＭ−Ｈｉ等々の実体的な実現を生じることだけを、想起させる。より正確に観察するならば、削減されて抽象的なものだけとなった請求項１の文言は、概念上の細部の説明を必要とする。説明の必要性は、文言との関係から、ＨＯＣＩＳ法の実体的実現という視点を生む。
■最後に次のことをもう一度指摘したい。それは、請求項１の文言／意味内容は、自らが例えば本来的なＰＴＫＶに常に関係するとか、したがっていつかはその存在と、管理用ＰＴＫＶへの関連付けが排除されるとかは、決していわないということである。このような限定は許容されないということは、従属請求項９０〜１００と図５ｏ〜ｒに、明示的に詳論されている。
Ｄ．４．１２．
すでにＤ．４．１項末尾で予告したことであるが、本願の特許請求の範囲における文言／意味内容は−単純化のため−Ｍ（ＨＯＣＩＳ）をＭ−ＬｏおよびＭ−Ｈｉに細分化するという方法を、援用しないで済ますことができる。このＤ．４項のこれまでの列挙事項から、次のような結論が得られる。すなわち、それら列挙事項に記載されたものの本質は、いくつかの単純なＭ（ＨＯＣＩＳ）属性を用いて、把握することができる。この目的のため、下記の定義を行う：
■Ｍ（ＨＯＣＩＳ）「全体」とは、下記に定義されるＭ（ＨＯＣＩＳ）の１つまたは複数であることを表す。
■「インテリジェントな」 Ｍ（ＨＯＣＩＳ）とは、前記に定義されたＭ−Ｈｉ機能を持つそれを表す。
■「ノンインテリジェントな」 Ｍ（ＨＯＣＩＳ）とは、前記に定義されたＭ−Ｌｏ機能を持つそれを表す。
重要なのは両者の機能の区別である：その実現に人間が関与していないか、あるいは人間の存在を必要とする−これはいずれにせよ標準的な当業者なら判断できる−あらゆるＭ（ＨＯＣＩＳ）機能を、本願では、Ｍ−Ｌｏ機能と見なすことができる（その「インテリジェンス」の状態が、誰かしらにはいずれにせよ「人」なものという印象を与えるとしても）。そしてこれらの機能は、ノンインテリジェントなＭ（ＨＯＣＩＳ）のものである。したがって「人ではないＭ（ＨＯＣＩＳ）」は、「ノンインテリジェントなＭ（ＨＯＣＩＳ）」と同義語である。
■「バーチャル」なＭ（ＨＯＣＩＳ）とは、前記で（図５ｉの説明で）定義されたバーチャルなＭ−Ｌｏ機能と、そのローカリティを表す−したがって諸定義によればノンインテリジェントである。
これら「インテリジェントな／ノンインテリジェントなＭ（ＨＯＣＩＳ）」という用語は、前記の説明すべてにおいて、「Ｍ−Ｌｏ／Ｍ−Ｈｉ」という用語を、１対１で代替する。
最後にこれらＤ．２からＤ．４の各項は、次のことを指摘する。すなわち、従属請求項で適用されている文言の短縮形は、請求項１の文言よりも、−特に「少なくとも」というしつこい決まり文句を、ときに省略することによって−読みやすさを簡単化するためだけのものである。したがって請求項１の意味内容の一般化とは、何の関係もない。同じことが、請求項グループの番号が増加するにつれて通常短くなる後続請求項グループのコメントにはさらに、その意図するところに従って当てはまる。請求項１へのコメントでひとたびいわれたことは、後続のコメントでも有効性を保ち、常に繰り返す必要がないだけでなく、コメントを簡単に読みやすく／理解しやすくするためであれば、その言葉遣いの不正確さを許容する。
Ｄ．５．各請求項と請求項グループについて、細部にわたるその他の説明
請求項２〜９のグループ：ここでは、本発明によるＨＯＣＩＳ法の基盤となるＰＴＫＶの、および／またはその少なくとも１つの端末システムの、暗黙のうちに想定される様々な特性をいくつか、明示的に開示する。
請求項１０〜１９のグループ：この請求項グループについては、Ｄ．１項で詳細に議論した。「この請求項グループは、このＨＯＣＩＳ法の特殊ケースのこのクラスの特性として、３つの異なるプロセスのスタート、および／または実行、および／または終了のオーバラップと、それらの組み合わせ可能性とによって特性付けられたものを識別し、その識別は、本発明によるＨＯＣＩＳ法の明示的に開示された特殊ケースを用いて行う。」
各請求項グループに関する下記のコメントは、それぞれ導入部として各請求項グループに共通で同じ決まり文句−上記では引用符をつけ、斜体で書かれた部分−で始まる。ただしその中で、太く書かれた部分は例外で、各請求項グループに独特のものである。しかし下記では、このステレオタイプで各請求項グループに共通な文言があることを、それぞれ「．．．．」という４つの点で表した。これに続いて、引用符を付けられ、斜体かつ太字で書かれたその請求項グループ独特の事項を記載したが、これを上記の太字のテキストの位置に挿入されたい。
請求項２０〜２３のグループ：．．．．「ＨＯだけのオーバラップ」
この請求項グループは、本願で、このグループに可能なバリエーションすべてを完全に列挙したり、またはこのグループだけの基盤となる「バリエーション特性」を、簡単に理解できる方法で短くかつ的確に表示したりすることは、実際上不可能であることを示す−バリエーションが数多く、そして複雑であることだけですでに不可能である。特に留意されたいのは、この請求項グループが、請求項１がただ１つのＨＯを持つＰＴＫＶへの限定や、１つのＨＯに直接または間接的にかかわる端末システムをそれぞれ１つだけ持つＰＴＫＶへの限定を何ら含まないことである（これについては第Ｂ章を参照）。
請求項２４〜２６のグループ：．．．．「直接かかわる端末システムの接続性」
この請求項グループでアドレス指定されているＨＯＣＩＳ法使用シナリオのタイプについては、方法に関する請求項の最後のグループで、十分に説明する。
請求項２７〜３３のグループ：．．．．「ネットワークの諸特性」
請求項３４〜４３のグループ：．．．．「様々な抽象化レベルとネットワーク」および「ＰＴＫＶ−ＰＤＵおよび／またはＳＴＫＶ−ＰＤＵのモダリティ」
請求項４４〜５６のグループ：．．．．「ＨＯＣＩＳおよび／または端末機器の反応および／または少なくとも１つの非ＨＯＣＩＳアプリケーション／プロセスによる当該端末機器の利用」
請求項５７〜６５のグループ：．．．．「ＨＯ関連情報の送信／受信／交換」
請求項６６〜６９のグループ：．．．．「ＨＯ関連情報における品質上の原因」
請求項７０〜７９のグループ：．．．．「ＩＡＤ接続性およびＩＡＤサポートにおけるＨＯＣＩＳ」
最後に挙げたグループがそれ自体２つの請求項グループであることは、すぐ理解できる。両グループとも当てはまるのは、請求項１と比較すると、従属請求項７０による意味内容の限定だけが存在し、この限定は次の文言で行われていることである。
ノンインテリジェントなＭ（ＨＯＣＩＳ）・・・・、この場合、
■後者に挙げたモジュールが、少なくとも１つのＩＡＤまたはサーバに、そして／または上記のＴＬＮ−ＰＴＫＶ／ＳＴＫＶ端末システムに設けられており、そして／または
■ＴＬＮ宛のＨＯ関連情報は次のことを述べ、すなわち、当該ＴＬＮが、ＨＯの後、新たなネットワークに実際に・・・・
すなわち、
＋）ノンインテリジェントなＭ（ＨＯＣＩＳ）は、ここでＩＡＤまたはサーバに、そして／またはそこでＰＴＫＶ−ＴＬＮにＨＯ関連情報が伝達されるＰＴＫＶ／ＳＴＫＶ端末システムに−すなわち他のＳＴＫＶ端末システムではない−、設けられなければならない−このことは、請求項１の文言／意味内容について、下記に説明する理解の明確化を余儀なくさせる。そして／または
＋＋）ＴＬＮのＨＯ関連情報（すなわちＨＯＣＩＳにおける彼宛のメッセージ）は、ここで明確なさらなる限定が課され、特に、
○その情報がＴＬＮに最終的に伝達される前に、いずれにせよ彼に表示される少なくとも１つの選択肢に関して、−誰によってであろうと、そのＳＴＫＶにおいて／ＳＴＫＶのために−少なくとも１つの（場合によっては手間のかかる）点検が実行されなければならない（この場合、この表示は、場合によってもう１つのＴＬＮインタラクション、例えば宣伝的種類のインタラクションを含む場合がある。そして／またはその選択肢固有の、そして／またはその他のもの固有のものである場合がある）
○選択肢に応じて、（誰による選択であろうと）その選択後、場合によっては少なくとも１つの（場合によっては手間のかかる）措置を、−誰によってであろうと、そのＳＴＫＶにおいて／ＳＴＫＶのために−その選択肢実現のために実行しなければならない。この場合、上記のさらなるＴＬＮインタラクションが、ここでも行われる場合がある。
上記の限定＋）は−これは、確かにまず従属請求項７１〜７９によるものであるが、ここではそのことを前もって指摘しておく−次の限りにおいて、上記の理解明確化を余儀なくさせる。すなわち、請求項１の文言／意味内容に関するいくつかの限定的な想定が、すなわち間違った想定が、最初の情報収集の際に「自然な状態で」生じるとしても、上記の限定が、これらの想定が許容されないことを認識することを余儀なくさせる限りにおいてである。例えば、この限定に基づけば次のことを容易に認識できる：
■例えば図５ｊ〜ｒに示されるような付随する多くのシナリオにおいて、請求項１を、少なくとも２つのそれぞれ異なる方法によって、実現することができる。例えば、１つには「本来のＰＴＫＶ」を基礎に置くことにより、２つには「管理用のＰＴＫＶ」を基礎に置くことによってである（これらの用語については、図５ｐについての上記の説明を参照）。請求項１によるＰＴＫＶは、本来のＰＴＫＶによっても、管理用のＰＴＫＶによっても実現できる。
■請求項１は、そのＴＬＮ−ＰＴＫＶ−および／または−ＳＴＫＶ端末システムと、そのＴＬＮが、複数の本来のＰＴＫＶおよび／または複数の管理用ＰＴＫＶの（抽象的および／または実態的な）実現に関与するかどうかについては、何もいわない。したがってこの点に関する限り、請求項１による方法のそこから生じる形成可能性について、限定を何ら行わない。したがって例えばＨＯＣＩＳ法において、ある特定のＴＬＮに宛てた、第１のＰＴＫＶに関する第１のＳＴＫＶの少なくとも１つのＨＯ関連情報は、そのＴＬＮに、このＨＯＣＩＳ法の第２のＰＴＫＶに関する第２のＳＴＫＶのＨＯ関連情報を伝達できる。この場合、両者のＳＴＫＶ、および／またはそれらの端末システム、および／またはそれらのネットワーク／アクセスポイント／ファシリティは、互いに異なる。このことは、例えば次の場合、実際的重要性を持つ。すなわち、このＴＬＮのための第１のＳＴＫＶ端末システムの実態的実現の、全体としてまたは一部分が、第２のＳＴＫＶ端末システムの実現と異なる場合である−両者端末システムは、例えば互いに異なるネットワークパラメータをもって動作する。
さらには、請求項７０の限定によっては、同請求項がさらに、１つのＨＯにおいて通常すべてのＰＴＫＶ−ＴＬＮに関するものであり、かつこれらのＴＬＮは、直接かかわるものも、間接的にかかわるものも含むことに、何の変わりも生じない。このことは、後続の２つの請求項グループにも当てはまる−付随する図５ｉ〜ｒでは、特に直接かかわるＴＬＮ、またはそのＰＴＫＶ／ＳＴＫＶ端末システムが着目されるとしても。
請求項７０〜７５のグループ：．．．．「接続性においての直接かかわるＭ（ＨＯＣＩＳ）」
このグループは、請求項７０を、図５ｊ〜ｎに従ってツリー状に展開する。
請求項７６〜７９のグループ：．．．．「基本的な接続性においての直接かかわるＭ（ＨＯＣＩＳ）」
このグループは、請求項７０を、図５ｏ〜ｒに従ってツリー状に展開する。
請求項８０〜８２のグループ：
請求項８０は、抽象的なＨＯＣＩＳ法、かつ場合によっては請求項１に記載のＨＯＣＩＳ法より一般的なＨＯＣＩＳ法を実現するための、（包括的な）抽象的なＨＯＣＩＳ装置を開示する。従属請求項８１は、この請求項８０に記載のＨＯＣＩＳ装置の機能を、請求項１または従属請求項２〜７９のいずれか一項に記載の特に１つのＨＯＣＩＳ法を抽象的に実現するに必要なものに限定する。
抽象的なＨＯＣＩＳ装置と、そのＰＴＫＶ−ＴＬＮにおけるＨＯＣＩＳ装置端末システムとの、抽象的な構造のモデルについては、すでにＣ．６項で述べた。そこで説明された−機能上自明のものと常に考えることができ、したがって可能性ある−抽象的なｒｅｓｏｕｒｃｅ ｓｈａｒｉｎｇに基づけば、ＳＴＫＶ装置構成要素が、いずれにせよ不可欠のものとして存在するＰＴＫＶ装置構成要素を共同利用するか、しないかは、抽象的なものにおいては重要でないことである。
ここで留意されたいこととして、抽象的なＨＯＣＩＳ装置およびそのＰＴＫＶ−ＴＬＮにおける端末システムのこの抽象的な構造は、実体的な実現、すなわち抽象的なＨＯＣＩＳ装置端末システムの実施形態の全体または一部が、ＰＴＫＶ−ＴＬＮの独自な実体的ＨＯＣＩＳ機器にあることを許容する（すなわち、そこには少なくとも１つの物理的なＰＴＫＶ端末システムがいずれにせよ存在するが、この端末システムに設けられる必要はない）。実体的ＰＴＫＶ−および／またはＨＯＣＩＳ−端末機器がこのように分離することは、次のことに原因を求めることができる−しかしそこに求めなければならないというのではない−すなわち、これらの端末システムが、ｒｅｓｏｕｃｅｓ ｓｈａｒｉｎｇの実体的・技術的理由からは、ケイパブルでないということである（このことは、例えば今日の「ＷＬＡＮだけの電話」および同電話から離れたところにある「ＧＳＭだけの電話」の場合、これらの間でＰＴＫＶが人のＨＯにおいて切り替わるのは、通常生じることである）。上記の分離のその他の理由は、ＰＴＫＶ−および／またはＳＴＫＶ−モジュールの間で、全種類にわたっては互換性がないことであろう。しかし将来においては、ＴＬＮの要望として、そのすべてのＰＴＫＶに関するすべてのＨＯＣＩＳとすべてのＨＯ関連情報を、効果的に集中化された方法で、それに適した少なくとも１つのＨＯＣＩＳ機器で得たいということも含まれることもあろう。このＨＯＣＩＳ端末機器は、コンビニエンス上の理由から、したがって少なくとも１つの通常はこれと異なる構想のＰＴＫＶ端末機器（この端末機器は、様々なネットワーク／アクセスポイント／サービスフィーチャーを経由して、複数の同時的で様々なＰＴＫＶをサポートすることができる）の少なくとも１つから、分離されたものとするべきであろう。
次に証明したいのは、ＨＯＣＩＳ装置の２つの機能、すなわち「（何らかの手段によるＴＬＮへのＨＯ関連情報の）直接または直接の伝達」と「（伝達手段からのＨＯ関連情報の、ＴＬＮによる）直接利用」は、そのときどきに、これら２つの機能が直観的に示唆するものを生じる：
■Ｍ（ＨＯＣＩＳ）または準備手段によるＴＬＮへのＨＯ関連情報の「直接伝達」の場合、この伝達は直接ＴＬＮに対して行われる−これが可能なのは、このＴＬＮとこの手段とが、同じＯＳＩ端末システムに属し、またはこの手段が前記ＯＳＩ端末システムのバーチャルなＭ（ＨＯＣＩＳ）である場合だけである（図５ｉについての上記の説明参照）。
別な場合−すなわち、ＴＬＮおよび上記手段が同じＯＳＩ端末システムに属さず、そしてこの手段がＴＬＮ−ＯＳＩ端末システムのバーチャルなＭ（ＨＯＣＩＳ）でない場合−この手段によるＴＬＮへの伝達は、ＴＬＮ−ＯＳＩ端末システムにおいて、両者の間にそのペアになるもう１つの手段を中間接続することを必要とする。したがって「直接伝達」である。
■ＴＬＮによる（ＨＯ関連情報を伝達する）手段の「直接利用」の場合、直接伝達機能の実行に、ＴＬＮが直接関与する−これは、当然のことであるが、上記で議論された条件下でのみ可能である。
最後に、装置に関する独立請求項の根本にあるもの−および方法に関する独立請求項の根本にあるものとの基本的相違−を説明したい。それによれば、請求項８０〜８２に記載のＨＯＣＩＳ装置は、請求項８０〜８２に記載の数多くの諸手段を含む。これら諸手段は、少なくとも手段内部で、そして少なくとも１つのネットワークを用いて互いに結合されている。しかしこのネットワークは、自明のことであるが上記の装置に関する独立請求項の文言に収められておらず、これら諸手段を実現するコンピュータシステムもそれと同様である。この多数の諸手段は、相互間およびＰＴＫＶ−ＴＬＮとの−適切に制御された−共同動作において、後者ＴＬＮに、このＰＴＫＶにおけるＨＯに関して希望のＨＯＣＩＳを実現するのに適している。このような多数の諸手段を含む装置が、ＨＯＣＩＳ装置である。１つのＨＯＣＩＳ装置だけの場合、すなわちこのような制御機能を持たない同装置の場合、その装置が何か有意義なことをすることは、知られていないことに留意されたい。
むしろＨＯＣＩＳ装置を用いるＴＬＮにとって、ＨＯＣＩＳは、これら諸手段とＴＬＮとの共同動作を適切に制御して初めて、実行される。このように制御されたＨＯＣＩＳ実行のプロセスが、本願によるＨＯＣＩＳ−ＴＫＶあるいはＳＴＫＶである。１つの方法に従って諸手段使用の制御がこの関連で行われるが、その方法がＨＯＣＩＳ法である。ここで留意されたいのは、このような制御方法は、これら諸手段自体に明示的に関係付ける必要はなく、各手段それぞれの機能の使用を−本願で述べたように−制御できる（したがって諸手段に暗黙のうちに関係付けることができる）。
ＨＯＣＩＳ装置の各制御方法−少なくとも１つのＨＯに関して希望のＨＯＣＩＳ実行／ＳＴＫＶを実現するためのもの−には、このＨＯＣＩＳ装置を実現する装置関連独立請求項が、上記制御に基づくＳＴＫＶにおけるＨＯ関連情報の交換に関して、明確な限定を加える（この交換は、装置の各手段が相互間で、そしてＨＯＣＩＳ装置を利用するＰＴＫＶ−ＴＬＮとの間で、行うものである）。この限定の範囲によって、大部分の（しかしまだ可能性の段階の、そして実践上興味ある）制御方法が請求項１を、したがって本発明によるＨＯＣＩＳ法を実現することになる。そしてその逆として、独立請求項１に当てはまるいずれのＨＯＣＩＳ法も、装置関連独立請求項に当てはまるＨＯＣＩＳ装置を制御して、同装置を利用するＰＴＫＶ−ＴＬＮが希望するＨＯＣＩＳを実行させるのに、実際に適していることは、容易に理解できる。
上記最後の３つの段落で、本発明によるＨＯＣＩＳ装置と本発明によるＨＯＣＩＳ法との間の基本的相違を説明した。
請求項８３〜９１のグループ：．．．．「ＨＯＣＩＳ手段によって生じるバリエーション」
これらの従属請求項は、装置タイプのいくつかの特性、または特性の組み合わせを明示する。

Claims (9)

  1. ＯＳＩ接続である少なくとも一つの第１遠隔通信の受信者である人に少なくとも一つの情報を提供する方法であって、
    前記第１遠隔通信における少なくとも一つのハンドオーバに関して、ハンドオーバの実施に寄与しない少なくとも一つのハンドオーバ関連情報が受信者に提供され、
    人ではないモジュールが関与する、ＯＳＩ接続である少なくとも一つの第２遠隔通信において、前記受信者に前記ハンドオーバ関連情報が提供され、
    前記ハンドオーバ関連情報は、第１遠隔通信及び第２遠隔通信の少なくとも一つに関連する少なくとも一つの端末システムによって受信者に伝達され、
    この伝達は、前記少なくとも一つの端末システムに少なくとも一つの信号が存在することを検出することよって開始されることを特徴とする方法。
  2. 前記少なくとも一つのハンドオーバ関連情報がネットワークを介して受信者の端末システムに提供されることを特徴とする請求項１に記載の方法。
  3. 前記少なくとも一つのハンドオーバ関連情報は、自動的に、すなわち要求を受けることなく受信者に伝達されることを特徴とする請求項１又は２に記載の方法。
  4. 前記少なくとも一つのハンドオーバ関連情報は、実際のハンドオーバに関連することを特徴とする請求項１から３のいずれか一項に記載の方法。
  5. 前記少なくとも一つのハンドオーバ関連情報は、将来起こり得るハンドオーバに関連することを特徴とする請求項１から３のいずれか一項に記載の方法。
  6. 前記人ではないモジュールは、受信者の端末システムでは無い第２遠隔通信の端末システムに組み込まれていることを特徴とする請求項１から５のいずれか一項に記載の方法。
  7. 前記人ではないモジュールは、受信者の第２遠隔通信の端末システムに組み込まれていることを特徴とする請求項１から５のいずれか一項に記載の方法。
  8. 前記少なくとも一つのハンドオーバ関連情報はそれ以前のハンドオーバに関連することを特徴とする請求項１に記載の方法。
  9. 受信者である人にＯＳＩ接続である少なくとも一つの第１遠隔通信の情報を提供するシステムであって、
    前記第１遠隔通信における少なくとも一つのハンドオーバに関して、ハンドオーバの実施に寄与しないハンドオーバ関連情報を作成する手段と、
    ＯＳＩ接続である少なくとも一つの第２遠隔通信を受信者に提供する手段と、
    少なくとも一つの第２遠隔通信において受信者に前記ハンドオーバ関連情報を提供するモジュールと、
    を有し、ハンドオーバ関連情報は第１遠隔通信及び第２遠隔通信の少なくとも一方に関連する少なくとも一つの端末システムによって受信者に伝達され、
    前記手段は、ハンドオーバを示す少なくとも一つの信号が存在することに基づく決定に伴い伝達を開始することを特徴とするシステム。
JP2009538650A 2006-12-01 2007-12-03 ハンドオーバ・コンビニエンス・インフォメーション・サービス（ｈａｎｄｏｖｅｒｃｏｎｖｉｎｉｅｎｃｅｉｎｆｏｍａｔｉｏｎｓｅｒｖｉｃｅ（ＨＯＣＩＳ）） Active JP5312342B2 (ja)

Applications Claiming Priority (113)

Application Number Priority Date Filing Date Title
US86815906P 2006-12-01 2006-12-01
US60/868,159 2006-12-01
DE102006057717 2006-12-01
DE102006057717.5 2006-12-01
US86951406P 2006-12-11 2006-12-11
US60/869,514 2006-12-11
DE102006059142.9 2006-12-11
DE102006059142 2006-12-11
DE102006059207 2006-12-13
DE102006059207.7 2006-12-13
US86994006P 2006-12-14 2006-12-14
US60/869,940 2006-12-14
US87166506P 2006-12-22 2006-12-22
US60/871,665 2006-12-22
DE102006062662.1 2006-12-27
DE102006062662 2006-12-27
US88238706P 2006-12-28 2006-12-28
DE102006062675 2006-12-28
US60/882,387 2006-12-28
DE102006062675.3 2006-12-28
US88326707P 2007-01-03 2007-01-03
US60/883,267 2007-01-03
DE102007001321.5 2007-01-03
DE102007001321 2007-01-03
US88386507P 2007-01-08 2007-01-08
US60/883,865 2007-01-08
DE102007001474 2007-01-08
DE102007001474.2 2007-01-08
US88509207P 2007-01-16 2007-01-16
DE102007003640 2007-01-16
DE102007003640.1 2007-01-16
US60/885,092 2007-01-16
US88601107P 2007-01-22 2007-01-22
DE102007003646.0 2007-01-22
US60/886,011 2007-01-22
DE102007003646 2007-01-22
US88699807P 2007-01-29 2007-01-29
DE102007005224 2007-01-29
US60/886,998 2007-01-29
DE102007005224.5 2007-01-29
US88812907P 2007-02-05 2007-02-05
US60/888,129 2007-02-05
DE102007006459 2007-02-05
DE102007006459.6 2007-02-05
US89021807P 2007-02-16 2007-02-16
US60/890,218 2007-02-16
DE102007008318.3 2007-02-16
DE102007008318 2007-02-16
US89227207P 2007-03-01 2007-03-01
DE102007010852.6 2007-03-01
US60/892,272 2007-03-01
DE102007010852 2007-03-01
US89316807P 2007-03-06 2007-03-06
US60/893,168 2007-03-06
DE102007011453.4 2007-03-06
DE102007011453 2007-03-06
US89423907P 2007-03-12 2007-03-12
DE102007012683.4 2007-03-12
US60/894,239 2007-03-12
DE102007012683 2007-03-12
US91008207P 2007-04-04 2007-04-04
DE102007016775.1 2007-04-04
US60/910,082 2007-04-04
DE102007016775 2007-04-04
US91302407P 2007-04-20 2007-04-20
DE102007019752 2007-04-20
US60/913,024 2007-04-20
DE102007019752.9 2007-04-20
US91773607P 2007-05-14 2007-05-14
DE102007022874 2007-05-14
DE102007022874.2 2007-05-14
US60/917,736 2007-05-14
US94334707P 2007-06-12 2007-06-12
DE102007027627 2007-06-12
US60/943,347 2007-06-12
DE102007027627.5 2007-06-12
US94654307P 2007-06-27 2007-06-27
DE102007030580.1 2007-06-27
DE102007030580 2007-06-27
US60/946,543 2007-06-27
US94772107P 2007-07-03 2007-07-03
DE102007031414 2007-07-03
DE102007031414.2 2007-07-03
US60/947,721 2007-07-03
US94873407P 2007-07-10 2007-07-10
US60/948,734 2007-07-10
DE102007032806.2 2007-07-10
DE102007032806 2007-07-10
US95006907P 2007-07-16 2007-07-16
DE102007034892 2007-07-16
DE102007034892.6 2007-07-16
US60/950,069 2007-07-16
US95107907P 2007-07-20 2007-07-20
US60/951,079 2007-07-20
DE102007034290 2007-07-20
DE102007034290.1 2007-07-20
US95680407P 2007-08-20 2007-08-20
DE102007039872.9 2007-08-20
DE102007039872 2007-08-20
US60/956,804 2007-08-20
US98566707P 2007-11-06 2007-11-06
US60/985,667 2007-11-06
DE102007053363 2007-11-06
DE102007053363.4 2007-11-06
US98823207P 2007-11-15 2007-11-15
US60/988,232 2007-11-15
DE102007055022 2007-11-15
DE102007055022.9 2007-11-15
US99035407P 2007-11-27 2007-11-27
DE102007057274.5 2007-11-27
US60/990,354 2007-11-27
DE102007057274 2007-11-27
PCT/EP2007/010485 WO2008064918A2 (de) 2006-12-01 2007-12-03 Handover convenience informationsservice (hocis)

Publications (3)

Publication Number Publication Date
JP2010511335A JP2010511335A (ja) 2010-04-08
JP2010511335A5 JP2010511335A5 (ja) 2011-01-27
JP5312342B2 true JP5312342B2 (ja) 2013-10-09

Family

ID=39434325

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2009538650A Active JP5312342B2 (ja) 2006-12-01 2007-12-03 ハンドオーバ・コンビニエンス・インフォメーション・サービス（ｈａｎｄｏｖｅｒｃｏｎｖｉｎｉｅｎｃｅｉｎｆｏｍａｔｉｏｎｓｅｒｖｉｃｅ（ＨＯＣＩＳ））

Country Status (3)

Country Link
EP (1) EP2098091B1 (ja)
JP (1) JP5312342B2 (ja)
WO (1) WO2008064918A2 (ja)

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2322051B (en) * 1994-04-28 1998-12-16 Motorola Inc Communications system
JPH1118132A (ja) * 1997-06-19 1999-01-22 Matsushita Electric Ind Co Ltd ハンドオーバー通知機能付移動機
US7184765B1 (en) * 1999-08-27 2007-02-27 Lucent Technologies Inc. Enhanced roaming notification of call handoffs
JP3338809B2 (ja) * 1999-10-26 2002-10-28 日本電気通信システム株式会社 移動体電話通信システム及び移動体電話通信システム間チャンネル切り替え方式
DE10042961A1 (de) 2000-08-31 2002-03-14 Siemens Ag Verfahren und technisches Gerät zur Aufrechterhaltung einer Funkverbindung
US7161914B2 (en) * 2002-04-11 2007-01-09 Ntt Docomo, Inc. Context aware application level triggering mechanism for pre-authentication, service adaptation, pre-caching and handover in a heterogeneous network environment
CA2497533A1 (en) * 2002-09-03 2004-03-18 Interdigital Technology Corporation A method and system for user initiated inter-device, inter-system, and inter-internet protocol address handoff
WO2006095652A1 (ja) * 2005-03-07 2006-09-14 Nec Corporation 移動通信端末及びハンドオーバ動作の通知方法
US8102811B2 (en) * 2005-03-07 2012-01-24 Lg Electronics Inc. Providing mobility management protocol information to a mobile terminal for performing handover in a mobile communication system
KR20060098019A (ko) * 2005-03-08 2006-09-18 삼성전자주식회사 듀얼모드 단말기에서 핸드오버 방법
US20080070575A1 (en) * 2006-09-15 2008-03-20 Holger Claussen Method of administering call handover between cells in a communications system

Also Published As

Publication number Publication date
JP2010511335A (ja) 2010-04-08
EP2098091B1 (de) 2013-08-28
WO2008064918A2 (de) 2008-06-05
WO2008064918A8 (de) 2008-08-28
EP2098091A2 (de) 2009-09-09

Similar Documents

Publication Publication Date Title
WO2019024604A1 (zh) 一种应用与网络切片的关联方法、装置和通信系统
CN110061901B (zh) 提供状态信息的方法和装置
US8571474B2 (en) Performing routing of a phone call through a third party device
JP5222306B2 (ja) ＶｏＩＰ呼び出しの際、マネージド・ハンドオーバ（ＭａｎａｇｅｄＨａｎｄｏｖｅｒ（ＭＨＯ））を用いる「ネットサーフィン」
CN105357240A (zh) 远程协助的控制方法及装置
US8391456B2 (en) Dynamic configuration of call controls for communication peripherals
US20110003585A1 (en) Communication mode swapping for telecommunications devices
EP1290829B1 (en) Call handling device for connecting a wireless communications device to a communications network
WO2017028567A1 (zh) 网络电话连接处理方法及装置
US8494123B2 (en) On-hold visual menu from a user's communications device
CN112867074B (zh) 数据传输方法、电子设备及存储介质
US20090279680A1 (en) Method and system for performing routing of a phone call based on mutual contacts of a contact list
JP5312342B2 (ja) ハンドオーバ・コンビニエンス・インフォメーション・サービス（ｈａｎｄｏｖｅｒｃｏｎｖｉｎｉｅｎｃｅｉｎｆｏｍａｔｉｏｎｓｅｒｖｉｃｅ（ＨＯＣＩＳ））
CN103634766A (zh) 一种来电转接方法、装置、系统及相关设备
JP2007306511A (ja) 無線通信端末及び無線通信方法
US9998956B2 (en) Managed handover process
KR101740611B1 (ko) 다중 번호 서비스를 위한 통신 단말 및 그 통신 단말의 정보 구분 표시 방법
EP2923516B1 (en) Wlan-iad handover process
CN107534599A (zh) 管理呼出呼叫的布置
KR101094898B1 (ko) 메신저 서비스 제공 방법 및 장치
KR100930740B1 (ko) 이동통신 단말기에서 메시지 전달 기능을 이용한 채팅 방법
JP2005328573A (ja) マルチコール端末，マルチコール端末用回路及びマルチコール端末によるマルチコール通話呼数変更方法
CN113068193B (zh) 信息处理方法、装置及设备和存储介质
KR101521967B1 (ko) 그룹 통화를 제공하는 디바이스, 서버 및 방법
Inoue et al. Decentralized ubiquitous networking server for context-aware seamless services

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20090717

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20101201

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20101201

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20101201

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20111115

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20111116

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20120215

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20120222

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20120314

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20120322

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20120416

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20120424

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20120514

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20120925

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20121218

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20121227

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20130115

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20130123

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20130325

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20130611

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20130702

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

Ref document number: 5312342

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250