JP2008510400A - 連絡中継システム - Google Patents

Abstract

連絡中継システム（１）は、２つ以上のモバイル通信端末（２）によって形成される。これらのモバイル通信端末が相互の範囲内に入るときに、これらのモバイル通信端末は、直接無線連絡を経由してアドホック通信に入るように実現される。アドホック通信中に、１つまたは複数のショート・プロファイル（１６）が、一方の端末（２）から他方へと送信され、その後に伝送された１つ（または複数）のショート・プロファイル（１６）の受入れテストが実施され、肯定的な結果の場合には、さらなる通信が開始される。諸端末（２）は、サービス発見プロセスによるサービス発見について実現される。サービス発見プロセス中の１つ（または複数）のショート・プロファイル（１６）の送信は、サービス照会の受信に応じてサービス属性データとして実施される。

Description

本発明は、一般にモバイル通信端末の間の連絡中継(contact relaying)に関し、例えば連絡中継システムと、連絡中継に適したモバイル通信端末と、端末に対して連絡中継機能を与えるコンピュータ・プログラムに関する。

アドホック・ネットワーク技術、とりわけいわゆるブルートゥース技術や無線ＬＡＮ技術は、近年広く受け入れられている。ブルートゥース（登録商標）は、様々な会社からなる「分科会」によって１９９８年以来仕様が決められてきているローカル無線データ伝送システムであり、例えば２００１年２月２２日付けのブルートゥース・システム、バージョン１．１の仕様を意味する。現在最も広く使用されている無線ＬＡＮ技術は、ＩＥＥＥ８０２．１１に従って規格化されている。このようなアドホック・ネットワーク技術においては、このような他の端末の範囲内に入るモバイル通信端末は、以上のアドホックとの通信に入ることができ、これは、ユーザによる各構成対策のないことを意味する。ここしばらくの間は、セルラ・モバイル通信（例えば、ＧＳＭ、ＵＭＴＳ）用のモバイル電話も使用可能であり、それらのモバイル電話は、それらのセルラ無線送信／受信コンポーネントに加えてブルートゥース送信／受信コンポーネントも有する。これは、たいていは他のユニットと、例えば（これによって例えばモバイル・インターネット・アクセスのために「無線モデム」を受け入れる）ポータブル・コンピュータと、あるいはモバイル電話とハンドフリー呼び出しを行うための無線接続されたヘッドセット（ヘッドセット−マイクロフォン間の組合せ）とモバイル電話を無線でネットワークすることも意図される。

ブルートゥースの範囲内に配置された２つのモバイル電話は、それらのブルートゥース送信／受信コンポーネントを経由して直接に通信を行う（したがって、この場合１つのモバイル電話から各無線波の基地局へと、また前述とは逆に、あるいは隣接する基地局から他の近くに配置されたモバイル電話へと延びるはずの典型的なモバイル無線経路を使用してはいない）ことも示唆されてきている。

アドホック通信のためのブルートゥース技術の機能によって、互いにまだ知らないが、アドホック通信のためのそれらの相互範囲内に偶然にまた知らずに入ったにすぎない加入者間の通信を確立する提案がすでに存在している。例えば、（それにならって請求項１の特徴以前の部分が形成されている）ＤＥ１０１４９４９６Ａ１は、「連絡開始システム」を示唆しており、この連絡開始システムにおいては、セルラ・モバイル通信のためのモバイル電話は、それらの追加のブルートゥース送信／受信コンポーネントを経由して直接通信に入ることができる。トラフィックを制限するために、この通信は、２段階で構成される。すなわち、第１段階においては、ショート・プロファイルの転送だけが送信端末によって実施される。これは、例えば送信端末のユニット認識と一緒に実施される。ショート・プロファイルとユニット認識が、レシーバ端末に記憶されるある種の判断基準に準拠する場合、これは、第２段階においていわゆる詳細プロファイル（または代わりにこのような詳細プロファイルを呼び出す認証）を返信する。この特許文書においては、この通信プロトコルが、ブルートゥース・レベルでどのように実行されるべきかについては、詳細に説明されていない。しかし、最初にペアリングが、両方の端末の間においてブルートゥース・レベル上で確立されて、ショート・プロファイルを送信し、次いでこのショート・プロファイルはまた、おそらく詳細プロファイルの後続の送信のために使用することもできることが明らかであるように見える。

やはり２段階で動作する同様な連絡開始システムは、特許文書ＤＥ１９９２９１８６Ａ１やＤＥ１９９２９１８９Ａ１から知られている。

またＤＥ１０２１８８０１Ａ１は、ブルートゥース送信／受信コンポーネントを装備したセルラ・モバイル無線端末についての直接通信システムを開示している。利点として、そこではブルートゥース・アドホック・ネットワークの比較的短い範囲（これは１００ｍより短いことを意味する）に起因して、直接無線通信を経由して到達可能な加入者数は、比較的少ないことが述べられている。直接に到達することができる加入者数を増大させるために、１加入者から他の加入者への連絡プロファイルは、可能な後続の連絡確立を伴う連絡確立決定の目的のためだけでなく、各プロファイルのさらなる伝搬の目的のためにも送信されることが示唆されている。この目的で、受信端ユニットは、受信端ユニットが、おそらくこれらの他の加入者の範囲内に後で入るときに、諸プロファイルを記憶し、それらのプロファイルをこれらの他の加入者に対して送信する。

ブルートゥース技術は、Ｊ．Ｗｏｌｌｅｒｔの書籍：「Ｄａｓ Ｂｌｕｅｔｏｏｔｈ Ｈａｎｄｂｕｃｈ」、Ｆｒａｎｚｉｓ Ｖｅｒｌａｇ ２００２年、特に１５ページから４６ページ（「概要」）と、４７ページから１１９ページ（コア・プロトコル）と、１６４ページから１７４ページ（サービス発見プロトコル（Ｓｅｒｖｉｃｅ Ｄｉｓｃｏｖｅｒｙ Ｐｒｏｔｏｃｏｌ））において説明されている。サービス発見プロトコルは、「Ｓｐｅｃｉｆｉｃａｔｉｏｎ ｏｆ ｔｈｅ Ｂｌｕｅｔｏｏｔｈ Ｓｙｓｔｅｍ」、Ｖｅｒｓｉｏｎ１．１、２００１年、２月２２日、３３１ページから３９２ページに仕様が定められている。無線ＬＡＮ技術の説明は、例えばＡ． Ｔａｎｅｎｂａｕｍ、「Ｃｏｍｐｕｔｅｒ Ｎｅｔｗｏｒｋｓ」、第４版、２００３年、６８ページから７１ページ、および２９２ページから３０２ページ中で見出すことができる。

本発明は、１つまたは複数のモバイル通信端末により形成される連絡中継システムに関する。これらは、相互の範囲内に入るときに直接無線連絡を経由してアドホック通信に入るように実現される。アドホック通信中に、１つまたは複数のショート・プロファイルが１つの端末から他の端末に送信され、その後に１つ（または複数）の送信されたショート・プロファイルの受入れテストが実施され、その肯定的な完了の後に、さらなる通信が開始される。諸端末は、サービス発見プロセスに従ってサービス発見のために配置される。そのサービス発見プロセスの課程における１つ（または複数）のショート・プロファイルの送信は、サービス要求の受信に応じてサービス属性データとして実施される。

追加の態様は、前述のタイプの連絡中継システムに参加するように提供されるモバイル通信端末に関する。

追加の態様は、データ・キャリアに記憶され、またはモバイル通信端末に対して送信するのに適切な信号シーケンスとして存在するコンピュータ・プログラムに関する。モバイル通信端末上で実行されるときに、そのコンピュータ・プログラムは、前述のタイプの連絡中継システムにおける端末の機能を可能にする。

追加の特徴は、開示される諸デバイスや諸プロセスに含められ、あるいは当業者により、実施形態の以降の詳細な説明と添付図面から導き出すことができる。

次に本発明の実施形態が、添付図面を参照して例示の様式で説明される。

図１は、連絡中継システムにおける通信パートナーと通信経路とを可視化して示している。図１の詳細な説明の前に、最初に諸実施形態に関する様々な説明が与えられている。

本実施形態は、直接無線連絡を経由してアドホック通信に入ることができるモバイル通信端末に関する。一般的に、この直接無線連絡は、比較的短い範囲を有しており、典型的な範囲は、例えば（使用される技術と無線波についての伝搬条件に応じて）数１０〜１００ｍの範囲にある。一部の実施形態においては、アドホック通信はブルートゥース技術に基づいて実施される。それに対して他の実施形態は、例えば規格ＩＥＥＥ８０２．１１による無線ＬＡＮプロトコルに基づいている（追加の実施形態においては、端末は、ブルートゥースを経由して、またＷＬＡＮも経由して選択的にアドホック通信を実施するように配置することもできる）。

これらの実施形態においては、諸端末は、サービス発見プロセスによるサービス発見のために設けられる。例えばブルートゥースの実施形態においては、これは、（例えば、２００１年、２月２２日付のバージョン１．１における）ブルートゥース分科会によって仕様が定められたＳＤＰ（ｓｅｒｖｉｃｅ ｄｉｓｃｏｖｅｒｙ ｐｒｏｔｏｃｏｌサービス発見プロトコル）である。名前によって示唆されるように、ブルートゥース技術におけるＳＤＰは、たいていサービス発見のための役割を果たし、これは、範囲内に配置された他のブルートゥース・デバイスがある種のサービスを提供する場合に見出すこと（またはより一般的に他のデバイスがどのサービスを提供するかを見出すこと）が、ブルートゥース・デバイスをイネーブルにすることであることを意味する。これは、一実施例を用いて説明することができる。すなわち、最初にブルートゥース技術の意図されるアプリケーションは、コンピュータのようなデバイスと、オフィス環境におけるその入力デバイスと出力デバイスとの無線接続であった。このような２つのデバイスは、いわゆるリンク・マネージャを介して接続を確立することができるが、しかしこれらのデバイスは、そのサービスが、それぞれ他のデバイスによって供給されるリンク・マネージャのレベル上の情報を受信しない。例えば、プリンタに接続されるべき新しく導入されたラップトップ・コンピュータでは、どのプリンタがその環境内にあり、どのプリント・サービスをそのラップトップ・コンピュータが提供するかという質問が行われる。ＳＤＰの支援を介して、ラップトップは、今や範囲内のデバイスから所望の情報を、したがって、例えばプリンタが仮にもそれらのデバイスの中にあるかどうか、またどのプリント・サービスをそのラップトップは、おそらく提供することができるかの情報を取り出すことができる。しかし、これらの実施形態においては、アドホック通信技術（例えば、ブルートゥースまたはＷＬＡＮ）の他の適用、したがって特別に設けられたモバイル通信端末に基づいた連絡中継システムが、説明されている。したがってこれらの端末は、これらの端末が相互の範囲内に入るときに直接無線連絡を経由して特別な種類のアドホック通信に入るように提供され、この直接無線連絡においては、１つまたは複数のショート・プロファイルが一方から他方に送信され、この直接無線連絡の後に、送信された１つ（または複数）のショート・プロファイルの受入れテストが実施され、この受入れテストの肯定的な結果の場合に通信が開始されており、これについては、後でより詳細に説明する。

いくつかの実施形態においては、それらの端末は、１つまたは複数のセルラ・モバイル電話ネットワーク（例えば、ＧＳＭモバイル電話またはＵＭＴＳモバイル電話）における無線通信のためのモバイル通信端末である。したがって直接無線通信を経由して連絡中継を実施する機能は、これらのセルラ・モバイル通信デバイスの追加機能である。

以上のフレームワークにおいて、ブルートゥース技術のようなアドホック通信技術において提供されるサービス発見機能は、モバイル通信端末の間の前記連絡中継のために使用することができることが今や理解できるであろう。このようなサービス発見プロセスは、例えばブルートゥースを用いた場合にもそうであるように、一般的に他のデバイスから各サービス要求を受信する端末デバイスが、サービス属性データを返信することによりそれに対して答えることを提供する。連絡中継システムの現在のフレームワークにおいては、サービス発見プロセス中の１つ（または複数）のショート・プロファイルの送信は、サービス要求の受信に応じたサービス属性データの形態で実施することができることが認識された。

連絡中継システムにおいては、諸端末のうちの１つは、連絡要求を送信するクライアントの機能を有し、他の端末は、その要求にサービス（これはその要求に対する応答を意味する）を行うサーバの機能を有する。基本的に、諸端末のうちの１つは、クライアントとして機能することだけができ、他の１つは、サーバとして機能することだけができること（またはその端末は、原理的には両方の機能を実施することができるが、クライアントまたはサーバとしてのみ機能するようにユーザによって構成されること）が可能である。しかし、他の実施形態においては、それらの端末は、それらの端末がクライアントおよびサーバとして同時に準じて機能することができるように実現される。例えば、このような端末は、連続的に他のデバイスに対して連絡中継要求を送信し（したがって、クライアントとして機能し）、同時に他のデバイスの連絡中継要求をサービスする（したがって、サーバとして機能する）ことができる。いくつかの実施形態においては、同じ端末中で実現される両方の機能は、異なるプロセスを介して、したがってクライアント・プロセスとサーバ・プロセスを介して実装される。これらのプロセスは、並列に実行される（端末には、両方のプロセスが、厳密な定義に従って同時に実行されないように、一般的に直接無線連絡のための１つのプロセッサと１つの送信／受信コンポーネントだけが装備されることが理解される。この意味は、実質的な同時実行の印象がユーザの心に生じるようにこれらのプロセスが、十分頻繁に交代して交互に実行されることである）。

知られているアドホック通信技術は、デバイスが、プレゼンス要求(presence request)を送信することを介して範囲内に配置される他の端末を検出することができる可能性を与える。ブルートゥース技術においては、いわゆる照会がこの目的を果たす。アドホック・ネットワークにおいては、一般的に（「リンク」とも呼ばれるブルートゥース内の）接続がデバイス間で確立され、これらのデバイスは、互いの間で通信を行い、これを介してチャネルが占有される。ブルートゥースにおいては、（ＩＳＯ−ＯＳＩ参照モデルのレイヤ２ａにおいて実施される）共通のエア・インターフェースに対する多重アクセスは、時分割多重化を伴う周波数ホッピング・プロシージャを介して実施される。この目的で、接続された諸デバイスは、ある種の以前に合意された周波数ホッピング・シーケンスを使用し、この周波数ホッピング・シーケンスでは、接続された諸デバイスの諸クロックは同期される必要がある。しかし、他のデバイスの範囲内に新たにやって来る諸デバイスは、このような共通のホッピング・スキームも共通のタイミングも知らない。このような諸デバイスが互いを見出すことができるようにするために、特別な組合せパターンが、アドホック・ネットワーク技術において提供され、これは、ホッピング・パターンやタイミングのような合意を必要とはしない。例えばブルートゥースにおいては、特別なホッピング・パターンが固定された様式における照会について事前に定義される。他の端末が照会を開始している場合に、プレゼンス要求に応答する用意ができている諸端末は、それ故にある種のタイム・スロットにおけるいわゆる照会スキャン間隔内において聴取し、おそらくプレゼンス応答(presence reply)、いわゆるＦＨＳパケットを返信する。そのＦＨＳパケットから、要求する端末は要求された端末のタイミング情報を受信する。

本実施形態においては、連絡中継クライアント機能を有する１つ（または複数）の端末は、範囲内に配置される他の端末を見出すためにプレゼンス要求を恒久的に送信するように設けられる（以上で説明されたように、クライアント機能を有する端末は、同時に他のクライアント・デバイスのためのサーバとして機能することもできる）。プレゼンス要求は、一般的に数秒（例えば、１秒から２秒）の間しか続かないので、「恒久的」は、例えば１０秒から５分ごとにプレゼンス要求が送信されていることを意味する。一部の端末は、他の端末からのプレゼンス要求について「聞こえない」ので、プレゼンス要求を送信するときにクライアントとサーバとして動作する２つの端末が偶然に同期する場合には、これらの端末が互いに他を見出すことができない結果と共に相互の遮断が生じる可能性がある。このような遮断を回避するために、いくつかの実施形態においては、クライアント機能を伴う端末が、ランダムな様式でそれらの送信されたプレゼンス要求の間の時間間隔を変更する。

本実施形態においては、クライアント端末は、（以前に送信されたプレゼンス要求に対するその応答によって）その発見の後に他の端末に、連絡中継に関連したサービス要求を送信し、発見するとすぐに今やサーバとして動作している発見された端末は、サービス属性データとして保存された１つ（または複数）のショート・プロファイルを再送信する。ブルートゥース内では、いわゆるサービス・クラスが、デバイスが提供する各サービスに割り付けられる。各サービス・クラスは、ブルートゥース内で例えば１２８ビットの数であるＵＵＩＤ（Ｕｎｉｖｅｒｓａｌ Ｕｎｉｑｕｅ Ｉｄｅｎｔｉｆｉｅｒ：普遍的な固有の識別子）を有する。各サービス・クラス識別子に対して（もっと正確には、「サービス・レコード」と呼ばれるサービス・クラス識別子によって識別されるサービス・クラスの各識別された設定に対して）各サービスの特性を記述するブルートゥース・データを割り付けることができる。これらのブルートゥース・データは、サービス属性と呼ばれている。サービス属性は、ブルートゥース内の属性識別子と属性値とを含み、これらは、システムの独立性を実現するためにブルートゥース規格において規定されたデータ・タイプと属性サイズによって記述される。ブルートゥース規格においては、いくつかのサービス・クラスが、固定された様式で、ある種の標準サービスについて事前に定義されている（それによって関連するサービス・クラスは、すでにあらかじめ決定されている）のに対して、いくつかのサービス・クラス識別子は、固定した様式で事前に占有されてはおらず、例えば自由な様式で非標準サービスのために使用することができる。本実施形態においては、これらの自由なサービス識別子のうちの１つは、「連絡中継サービス」のために使用される。その後にこのサービス・クラス識別子は、「ＫＶＤ」と呼ばれる。

ブルートゥースＳＤＰにおいては、各ＰＤＵ（Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ：プロトコル・データ・ユニット）を送信することを介してそれぞれ表される様々な種類のサービス発見要求が提供される。様々なＰＤＵは、たいていはサーバ側ＳＤＰプロセスが、要求があるとすぐに返信する「データ深さ」において異なっている。したがって、例えば要求されたサービスがサーバによって提供されるのにすぎない場合には、ＳＤＰプロセスからのすべてのレコードに対してリファレンスを返信するにすぎないＰＤＵが存在する。ここで関心のある他のＰＤＵにおいては、ＳＤＰプロセスが要求されたサービスを提供する場合、ＳＤＰプロセスは、クライアントに対するサービス要求に応じて各サービス・クラス識別子の下でそのＳＤＰプロセス中に保存されたサービス属性データだけを返信する。本実施形態においては、クライアントはまた、サービス・クラス識別子「ＫＶＤ」を有するサービス・クラスについてのサービス要求をサーバに送信し、それによってＰＤＵを送信することを介して、このＰＤＵは、このサービス識別子の下でそのＰＤＵに保存されたサービス属性データをサーバに返信させる。サーバは、ＳＤＰ中にそれがサービス「ＫＶＤ」を提供するかどうかを検査し、肯定的な場合にＫＶＤサービス属性データをクライアントに対して送信する。この返信されたサービス属性データは、サーバ中に保存され、連絡中継システムの要求するユーザに対して送信するために開放されるショート・プロファイルである。例えば、各ショート・プロファイルは、（専用のサービス属性識別子を有する）サービス属性を形成する。１つのショート・プロファイルだけが記憶される場合、サーバはそれに応じて１つのサービス属性を送信するだけであり、いくつかのショート・プロファイルの場合には、サーバは、それに応じていくつかのサービス属性を送信する。

「ペアリング」とも呼ばれる、ブルートゥース・プロトコルにおける複数の端末の間の接続は、各端末デバイスのタイミングとホッピング・シーケンスに関するマッチングを含むだけでなく、１つの接続コードに対する合意と、さらに認証、暗号化なども含む。本実施形態においては、それらの端末は、サービス要求通信中（これは、サービス要求を送出し、サービス属性データの形式でショート・プロファイルを返信している間を意味する）にはまだペアリングされていない。諸デバイスは、照会の後にデバイスのタイミングとホップ・シーケンスをマッチングさせているが、ただし諸デバイスは、（接続コード、認証などの使用を伴って）通信チャネルをまだ確立はしていない。接続コードの使用を介したケーブル割り付けを伴うこのような接続は、後でより詳細に説明しているように、本連絡中継システム間においては後で実施される。それ故に、このショート・プロファイル処理フェーズにおいては、接続確立プロシージャのために必要とされる努力を回避することができる。

本実施形態においては、クライアントとして機能する端末が設けられ、そのためにその端末は、クライアント端末に記憶されるプロファイル情報を比較することを介してサーバとして機能する端末から１つ（または複数）のショート・プロファイルの受信の後に受入れテストを実施する。いくつかの実施形態においては、ショート・プロファイルはまた、この受入れテストの目的でクライアント端末に記憶され、そのためにこの受入れテストにおいては、クライアントに記憶されたそれ自体のショート・プロファイルとサーバから受信されたショート・プロファイルの比較が実施される。ショート・プロファイルの比較は、例えば全体のショート・プロファイルまたは部分的なショート・プロファイルのこれらのテストのうちの複数のテストから形成される同一性テスト、相補性テスト、またはハイブリッド・テストを含む。同一性テストにおいては、その名前から理解することができるように同一性がテストされる。相補性テストにおいては、２つのショート・プロファイルが互いに相補的であるかどうかがテストされ、したがって（例えば、それらのプロファイルの一方が、検索プロファイルとして指定され、他方が、入札プロファイルとして指定される場合には）適合が存在する。類似性テストにおいては、完全な同一性（および／または相補性）はないが、ある種の最小限の一致(congruence)（または相補性）だけが必要とされる。この結果、同じテスト・タイプは、同じショート・プロファイルに適用される必要はなく、さらなる部分の同一性について、またもしかすると他の部分だけの類似性について、ショート・プロファイルのある部分についての相補性を必要とする可能性がある。１つ（または複数）のプロファイルの一部分だけ（またはそれらのフォワード符号(forward sign)だけが同一性、相補性、または類似性についてテストされるが）、しかし他の部分（例えば、それらのリア符号(rear sign)）が、テストにおいて考慮されていない「グループ・テスト」も可能である。

本実施形態においては、それらのショート・プロファイルは、照会中またはサービス発見確認中にクライアントに送信されるサーバ端末のデバイス識別子と一緒に、ショート・プロファイルによって表される連絡プロファイルの固有の識別を可能にする情報を含んでいる（ところで、「表される」は、ショート・プロファイルが、連絡プロファイルと同じ量の情報を含んでいることを意味してはいない。どちらかといえば、それはその名前がすでに示しているように、連絡プロファイルよりも少ない情報しか含んでいないことになる）。この情報は、例えばプロファイル・スキーム識別子（これは、連絡プロファイルが基づいている連絡プロファイル・スキームの識別子を意味する）と、（サーバが、使用可能な同じプロファイル・タイプのうちのいくつかの連絡プロファイルを有する場合における）プロファイル数と、（ショート・プロファイルによって表される連絡プロファイルがサーバ中で変更されるたびに増分される）実現化カウンタ(actualization counter)である。各実施形態においては、（元のサーバのデバイス識別子を含む）他の端末から以前に受信されたすべてのショート・プロファイルは、クライアントに記憶される。受入れテストのフレームワークにおいては、ショート・プロファイルが以前にすでに受信されたかどうかが、次にこれらの記憶された識別データと、実際に受信されたショート・プロファイルと同じ連絡プロファイルを表す現在のショート・プロファイルと共に受信された識別データとの比較を介して検査される（実現化(actualization)が表された連絡プロファイル中で行われている場合に、このテストは実現化カウンタを含み、それはまだ知られていないプロファイルとして考えられる）。クライアントがこのテストにおいて、受信されたショート・プロファイルが、クライアントにすでに知られている連絡プロファイル（およびしたがって連絡中継に関して以前にすでに処理されている連絡プロファイル）を表すことを決定する場合、クライアントは、このすでに知られているショート・プロファイルを除外し、これは、後でより詳細に説明しているように、クライアントが、クライアントについてのさらなる通信を開始しないことを意味し、これは、例えばそれぞれの要求が連絡プロファイルを完了しないことを意味する。

一部の実施形態においては、このテスト・メカニズムは、専用プロファイルがクライアント中において変更される場合、たぶんそのクライアントによって接触される、知られているプロファイルが、「知られていないもの」として設定されることに関して改良される。これは、クライアントが、その専用のプロファイル変更を介して知られるようになっているだけのプロファイル、すなわちクライアントがそのショート・プロファイルをすでに以前に受信しているプロファイルをサーバから次に呼び出すことになるという影響を及ぼす（この対策なしには、クライアントは、ショート・プロファイルを知られているものと考えるはずであり、したがってそれによって表されるプロファイルを呼び出さないはずである）。

受入れテストの否定的な結果の後に、各連絡プロファイルについてさらなる連絡確立通信は実施されない。しかし肯定的な結果の場合には、その連絡確立通信は実施される。一部の実施形態においては、クライアント端末とサーバ端末とのペアリングが、このさらなる通信の目的で確立される。前述のように、ペアリングの確立は、例えばブルートゥースの場合には通信コードにより識別される通信チャネルの占有の使用である。このチャネル上の以降の通信は、例えば実施し、認証し、かつ／または符号化することができる。一部の実施形態においては、今やペアリングされた接続の下で実施されるクライアントとサーバ端末の間のさらなる通信は、その関連するショート・プロファイルが受入れテストを正常に合格している完全な連絡プロファイルの伝送を含んでいる（いくつかのショート・プロファイルが、このテストを肯定的に合格している場合には、その通信は、それ故にこれらの複数の連絡プロファイルの伝送を含んでいる）。一部のこれらの実施形態においては、この連絡プロファイル伝送は、ペアリングされた接続チャネルを経由して１つ（または複数）の各連絡プロファイルを伝送するための要求を送信するクライアントとして機能する端末と、ペアリングされた接続チャネルを経由１つ（または複数）の各連絡プロファイルを伝送することを介してこの要求に応答するサーバ端末とを介して実施される。

一部の実施形態においては、連絡確立プロシージャは、実質的に連絡プロファイルを伝送することにより完了され、ユーザは、次に例えば連絡プロファイル中に含まれるデータを閲覧することができ、またもしかするとセルラ無線ネットワークを経由して音声接続またはメッセージの伝送の目的で連絡プロファイル中にリストアップされた電話番号を手動で選択することができる。

他の実施形態においては、クライアントとして機能する端末は、受信された連絡プロファイルにさらなるテスト、いわゆる「連絡開始テスト」を受けさせる。このテストにおいては、受信された連絡プロファイル、またはその一部分は、専用プロファイルとの同一性、相補性、類似性について、あるいはそれ自体のプロファイル中に設けられた条件の実現（例えばしきい値に合格しないなど）についてテストされる。

連絡開始テストの肯定的な結果の場合に、クライアントとして機能する端末は、実際の連絡確立を開始する。その結果、様々な実施形態は、連絡確立の（端末の同じ実施形態中において選択的にまたは組み合わせて選択することができる）異なる方法、すなわち直接無線通信を経由した、サーバ端末との音声連絡確立と、セルラ無線通信を経由したサーバ端末または他の端末との音声連絡確立と、直接無線通信を経由したサーバ端末へのメッセージの送信と、セルラ無線通信を経由したサーバ端末または他の端末に対するメッセージの送信と、セルラ無線通信を経由したコード・サービスに対するメッセージの送信とを実現する。諸メッセージは、例えば習慣的にブルートゥース、あるいはＳＭＳ−サービスまたはＭＭＳ−サービスのメッセージを伴ういわゆるビジネス・カードとすることができる。セルラ無線システムを経由した音声連絡確立とメッセージ送信は、もちろんサーバ端末または他の端末の電話番号が、送信された連絡プロファイル中に含まれていることを必要とする。代わりに、プロファイル・ジェネレータ（これは、サーバを意味する）は、（電話番号のような）非匿名のデータの代わりに連絡プロファイルを有するコード番号を配信することを介してコード・サービスを介して最初にその匿名性を維持することができ、ここでコード番号とその身元（例えば、その電話番号）の関連付けは、信頼できるコード・サービスに知られているだけである。クライアント端末は、送信されたコード番号を提供するその連絡確立メッセージをこのコード・サービスに対して送信する。後者のコード・サービスは、次にそれに知られている割り付けに基づいてプロファイル・プロバイダに対して（例えばクライアント端末に対して）その連絡確立メッセージを渡す。

いくつかの実施形態においては、連絡プロファイルを表すショート・プロファイルは、連絡プロファイル中にユーザが入力し、または連絡プロファイルにおいて端末が生成するデータに依存することなく、固定された様式で連絡プロファイルが基づいているプロファイル・スキームを介して決められる。その場合には、連絡プロファイルは、いわば連絡プロファイルが基づいているプロファイル・スキームのインジケータである。他の実施形態においては、ショート・プロファイルを表す連絡プロファイルは、連絡プロファイルが基づいているプロファイル・スキームを介して部分的に決められ、連絡プロファイル中にユーザが入力し、または連絡プロファイルにおいて端末が生成するデータに部分的に依存する。これらの実施形態においては、端末は、それらを表すショート・プロファイルにユーザが自動的に入力する設定されたデータを符号化するように設けられる。

一部の実施形態においては、連絡プロファイルは、指定言語（例えば、ＸＭＬ）のシンタックスの形で存在し、関連する事前に定義されたプロファイル・スキームは、例えば（ＸＭＬ−）ドキュメント・タイプおよび（ＸＭＬ−）スキーム定義として与えられる。

一部の実施形態においては、それらの端末は、連絡プロファイルを事前に定義するプロファイル・スキームが、セルラ・モバイル通信ネットワークを経由してダウンロードすることができ、ユーザのために個別の連絡プロファイルを確立するためにユーザからのプロファイル・スキームをダウンロードした後に、個々のデータを端末に入力することができるように設けられる。

一部の実施形態においては、実施された連絡中継の頻度（およびしたがって「ヒット」の確率）は、他のユーザからのプロファイル、すなわち他のユーザへそれらを伝搬するいわゆる異質プロファイルを吸収する端末ユニットを介して増大させられる。他のデバイス中に記憶される異質プロファイルは、例えば以前の連絡中継中に他の端末デバイスから受信されたプロファイルである。異質プロファイルの伝搬をさらに加速するために、また（例えば、定常的な）異質プロファイル伝搬デバイスを設けることもできる。

本連絡中継システムは、技術的な観点からより良好な理解をするためにいくつかの端末を有する全体システムとしてここでは説明されている。（これが単独では通信を行うことができないときにはまた、少なくとも２つのこのようなデバイスがそのために必要とされるので）もちろん、本発明は、単一の端末の形ですでに実施されている。このような端末は、たいていは単一の端末として動作させられているので、特許請求の範囲が単一の端末も対象とすることは正当化される。もちろん、全体システムの以前と後続の全体の説明は、単一デバイスにも関連している。

説明される様式における連絡中継システム（したがって、説明される連絡中継機能）に参加する諸端末の適切さは、前述では、ほとんどの実施形態においてソフトウェア・アプリケーションを介して、したがって各端末のプロセッサによって処理されているコンピュータ・プログラムを介して得られる。プログラムは、例えば（ＪＡＶＡ（登録商標）処理端末においては）ＪＡＶＡ、または端末プロセッサのマシン・コードでプログラムすることができる。一部の実施形態においては、それらの端末は、最初に（したがって、製造から）このプログラムが装備されており、他の実施形態においては、プログラムはそれらの端末中にダウンロードすることができる。したがって、このようなプログラムは、例えばデータ・キャリア上に記憶され、あるいはモバイル通信端末へと伝送するのに適切な信号シーケンスとして存在するトレード動作の目的になる。端末は、例えばその端末のもしかすると使用可能なＷＡＰ機能の助けを伴ってセルラ無線を経由してインターネットを介してプログラムをダウンロードすることができる。したがって、プログラムを特許請求の範囲の対象とすることが正当化される。

次に図１に戻ると、これは、通信パートナーと連絡中継システム１における経路の図を示している。図１においては、２つの通信パートナーだけが、各端末２の形態で例示のように示されており、ここでは場合によっては、それが図８に示されるように２つより多いこのような端末２を範囲内に配置することができる。モバイル端末ＭＥ２、ＭＥ３、ＭＥ４が、相互の範囲内にあり、ここで２つのモバイル端末ＭＥ３とＭＥ４はまた、対応するショート・プロファイル１６を有する。範囲は、図８においては、モバイル端末の周囲の同心リングを用いて示される。

端末２のうちの一方は、図１に示される実施例におけるクライアント３の役割を引き受け、他方の端末は、サーバ４の役割を引き受ける。端末２は、セルラ・モバイル無線用のモバイル端末（例えば、モバイル電話）であり、これらのモバイル端末は、同じまたは他の無線ネットワークの、あるいは有線ネットワークの他の参加者と通常の様式でセルラ無線ネットワーク（例えば、ＧＳＭまたはＵＭＴＳ）の基地局５に無線連絡を経由してモバイル通信に入ることができる。端末２には、さらに送信／受信コンポーネント６が装備され、この送信／受信コンポーネントは、他の各デバイス、ここでは例えばブルートゥース送信／受信コンポーネントとの短距離のアドホック通信を可能にする。これらのブルートゥース送信／受信コンポーネント６を介して、２つの端末は、それらの端末がブルートゥース範囲内に入るときに、直接にアドホック通信に入ることができ、それによって一般にその基地局５とのセルラ無線ネットワークを経由する通信経路を回避することができる。端末２は、特定の様式でプログラムされ、そのために直接アドホック通信のためのそれらの所定の機能を連絡中継システム１のフレームワーク内で使用して、端末２のユーザには一般に知られていない、ある種の連絡判断基準が満たされる場合には一般にその範囲に到達している、連絡中継システムの他の参加者との連絡を確立する。この連絡中継の場合には、いくつかの段階の通信ステップが、前記条件の実現に応じて行われ、これについては、可視化するために図１に示され、またこれについては、後続の図面を参照してさらに詳細に説明されることになる。したがって、クライアント端末３は、直接無線チャネルを経由してプレゼンス照会１３を送信し、このプレゼンス照会は、他の中でもとりわけサーバ端末４によって受信され、各照会応答１４で直接無線チャネルを経由して応答される。さらに、クライアント端末３は、直接無線連絡を経由してサーバ端末４に記憶されたショート・プロファイルについてのサービス検索照会１５を送信し、このサービス検索照会に対してこのサーバ端末は、対応するサービス検索応答で応答し、これは、そのショート・プロファイル１６の伝送を意味する。受入れテストを実施した後に、クライアント端末３は、サーバ端末４に対してプロファイル要求１７を送信し、このプロファイル要求に対してこのサーバ端末は、直接無線連絡を経由して（例えば、ＸＭＬフォーマットにおける）要求された連絡プロファイル１８を返送することによって応答する。伝送された連絡プロファイル１８を検査した後にクライアント端末３がサーバ端末４との連絡を確立したいと思っていることが明らかになると、クライアント端末は、様々な可能な方法のうちの１つで特定の連絡を確立しようと試みる。この連絡確立の試みは、この場合にも直接ブルートゥース無線連絡、例えば個人専用のショート・メッセージ（「ブルートゥース・ビジネス・カード」）を送信することによって、あるいはブルートゥース・チャネルを経由した音声接続を確立することによって実施することができ、これについては、図１に、「連絡確立照会１９」として示される。次いで、例えばブルートゥース無線経路の使用によって連絡確立要求１９に応答し、例えばそれ自体のビジネス・カードの再伝送することによって、または音声接続要求を受け入れることによって、二者間の連絡を確立することは、サーバ端末４の責任であり、これについては、図１に「連絡確立応答２０」として示されている。実際の連絡確立は、例えば両方の端末２がもはや直接無線連絡のための範囲内にないときに、セルラ無線ネットワークを経由して実施することもできる。例えば、サーバ端末４のモバイル無線番号が、含まれるプロファイル中にリストアップされていたときに、クライアント端末３は、セルラ無線音声接続７を確立しようと試み、あるいはクライアント端末は、セルラ無線ネットワークを経由して上記に対してメッセージ８を送信する（図１に、これは、「ＳＭＳ直接」によって指定されている）。他の実施形態においては、コード・サービス９のコード番号をこの伝送される連絡プロファイル１８中に含めることができる。次いで、クライアント端末３は、セルラ・モバイル無線ネットワークを経由して例えば（「コード・サービスに対するＳＭＳ」として指定される）コード・メッセージ１０をコード・サービス９に対して送信する。これは、コード・メッセージ１０中に含まれるコードをサーバ端末４に割り付け、セルラ・モバイル無線ネットワークを経由して（今や復号化されている）コード・メッセージ１０’を送信する。

最終的には、セルラ・モバイル無線ネットワークは、端末２が、例えばプロファイル・スキーム・サービス１２によって配信されているプロファイル・スキーム１１をダウンロードする方法としての役割も果たす。最初には互いに知られていない端末２に送信されたプロファイルが、それぞれ他方の端末によって「理解」されるようにするために、これらのプロファイルは、ある種のプロファイル・テンプレート、したがってプロファイル・テンプレート１１に対応する必要がある。基本的には、端末２が供給されるときに、このようなプロファイル・スキームは、固定された様式で事前に決定することができる。このような所定のプロファイル・スキームだけに限定されるときには、少なくとも古い方の端末２は、その端末の製造後に作成されたにすぎない連絡中継内容に特に適合化されるプロファイルを使用する可能性をもたないはずであるので、このような連絡中継サービスは、比較的融通の利かないものになるはずである。この点においてより多くの柔軟性を得るために、それらの端末が、セルラ・モバイル無線ネットワークを経由してプロファイル・スキーム・サービス１２から後の任意の時点に新しいプロファイル・スキーム１１をダウンロードすることができ、これらのダウンロードされたプロファイル・スキーム１１が、各端末２に自動的に機能的に結合されるように、端末２はプログラムされ、そのためにユーザは、それが連絡中継システム１における説明された方法で使用することができるプロファイル・スキーム１１からデータを入力することによって連絡プロファイル１８（したがって、プロファイル・スキーム１１の設立）を生成することができるようになる。

図２は、直接無線連絡を経由した連絡中継通信プロセスを階層化して視覚化するためのクライアント３とサーバ４の概略的な階層図を示している。実際の通信は、最下層レイヤ上で、したがってクライアント３とサーバ４の送信／受信コンポーネント６の間の無線連絡を経由して行われる。ブルートゥース技術によれば、周波数ホッピング・プロセス、データ・チャネルを管理すること、諸デバイスをアドレス指定することなどを実現するいわゆるベース・バンド２１が、最下層レイヤ上に存在する。いわゆるセキュリティ・レイヤに、またＩＳＯ−ＯＳＩ参照モデルの中継レイヤに部分的に割り付けることができるいわゆるＬ²ＣＡＰレイヤ２２（論理リンク制御と採用レイヤ制御）がその上に位置している（ブルートゥースの場合には、それらのタスクを伴うレイヤは、ＯＳＩモデルで正確に示すことはできない）。ブルートゥースの場合には、次にトランスポート・レイヤ、すなわちＲＦＣＯＭＭインターフェース２５が来る。これらの２つのレイヤの間に、ブルートゥースの場合にはＳＤＰを介して実現されるサービス認識プロセス２９が存在する（その構造によって、そのサービス認識プロセスは、特別なＯＳＩレイヤに完全には割り付けることができない）。ＷＬＡＮを介して、サービス認識プロセスは、適切なポート上で指定された独立なプロセスによっていつでも示すことができる。実際のクライアント・プロセス２３またはサーバ・プロセス２４、およびインターフェース２５上に、特に連絡中継についてサービスを行い、クライアント・アプリケーション２７とサーバ・アプリケーション２８を備えるアプリケーション２６が配置される。クライアント・アプリケーション２７またはサーバ・アプリケーション２８には、サービス属性を有するサービス・レコード（ショート・プロファイル）が記憶されるサービス登録データベース４８が属する。連絡中継アプリケーション２６は、各サービス認識プロセス２９中における代表的な連絡プロファイル１８によるショート・プロファイル１６を記憶することを開始し、そのために前述のようにこれらのショート・プロファイル１６は、サービス属性データとしてサービス検索要求のフレーム中においてサーバ４からクライアント３へ転送することができる。前述の照会プロシージャとサービス要求プロシージャは、ブルートゥース技術ではレベル２２と２９にすでに実装されており、そのために連絡中継アプリケーション２６は、ある種の様式でこれらのプロシージャを開始する必要があるだけである。サービス検索要求１５に転送されたショート・プロファイル１６がクライアント・プロセス２３から連絡中継クライアント・アプリケーション２７に手渡されるときに、実際のアプリケーション２６の動作は開始され、次いで連絡中継クライアント・アプリケーションは、前述の受入れテストと共に開始される。その後に、もしかするとサーバ端末４の連絡中継サーバ・アプリケーション２８に対する連絡プロファイル要求１７の伝送と、要求された連絡プロファイル１８の再伝送が、後続の実際の連絡確立と同様に続く。

図３は、クライアント・デバイス３とサーバ・デバイス４との間の通信の時間シーケンスと、デバイス３、４中で行われる処理ステップをタイミング図に基づいて可視化している。瞬間Ｔ１において、クライアント・デバイスは、例えばＩＤパケットの形態の照会を送信し、サーバ・デバイス４は、この照会を瞬間Ｔ２に受信する。サーバ・デバイス４は、例えばＦＨＳパケットの形態の照会応答を返信することにより、瞬間Ｔ３においてその照会に対して応答し、この照会応答はＴ４において、クライアント・デバイス３によって受信される。したがって、Ｔ１からＴ４は照会フェーズを形成する。この照会フェーズ中には、クライアント・デバイス３とサーバ・デバイス４は、それぞれ他のデバイスのタイミングについての知識はなく、ペアリングが形成されていない（これは、接続コードを伴う接続がまだ存在しないことを意味する）。

照会応答を介して、クライアント・デバイス３は、サーバ・デバイス４の存在について学習する。さらに、クライアント・デバイスは、サーバ・デバイス４からタイミング情報を受信し、このタイミング情報は、同期化のために後続の通信に使用されている。瞬間Ｔ５において、クライアント・デバイスは、サービス識別子「ＫＶＤ」に対するＳＤＰ要求を送信し、サーバ・デバイスは、このＳＤＰ要求をＴ６において受信する。次いでサーバ・デバイスは、識別子「ＫＶＤ」についてサーバ・デバイスに記憶されたサービス属性データ、したがってそのショート・プロファイル１６を呼び出し、それらのショート・プロファイルをＴ７においてクライアント・ユニット３に対して送信し、このクライアント・ユニットは、それらのショート・プロファイルをＴ８において受信する。Ｔ８の瞬間からほとんどＴ９まで、クライアント・ユニット３は、受信されたショート・プロファイルの受入れテストを実施する。Ｔ５からほとんどＴ９までのフェーズはショート・プロファイル処理フェーズである。その中で行われる通信は、照会フェーズで生成されたタイミング情報に基づいているが、またこのフェーズにおいては、ペアリングがまだ実施されていない（これは、ＳＤＰ通信においては、接続コードを伴う接続がやはりまだ存在していなかったことを意味する）。

受入れテストの肯定的な結果の場合には、クライアント・デバイス３は、次にペアリングを確立し、これは、サーバ・ユニット４に対する接続パラメータ／チャネル割り付けを有する接続を意味しており、Ｔ９においてプロファイル要求をサーバ・ユニットに送信し、サーバ・ユニットは、Ｔ１０においてこのプロファイル要求を受信する。Ｔ１１において、サーバ・ユニット４は、要求された１つ（または複数）の連絡プロファイルを返信し、クライアント・デバイス３は、Ｔ１２においてその連絡プロファイルを受信する。次いで、クライアント・デバイス３は、ほとんどＴ１３まで連絡プロファイル・テストを実施し、肯定的な結果の場合には、一部の実施形態において瞬間Ｔ１３において、例えば連絡メッセージをサーバ・デバイス４に送信し、サーバ・デバイスは、Ｔ１４においてこの連絡メッセージを受信する。もしかするとサーバ・デバイス４は、この場合にも連絡メッセージに対して応答することがある。Ｔ９からほとんどＴ１３までのタイム・スパンは、連絡プロファイル処理フェーズを形成し、後続の時間間隔は、特定の連絡確立フェーズを形成する。連絡プロファイル処理フェーズ中におけるおよび（ブルートゥースを経由して実施される限りの）連絡プロファイル確立フェーズにおける通信は、クライアント・デバイス３とサーバ・デバイス４との間の（接続パートナー／チャネル割り付けを伴う）ペアリング接続のフレームワークにおいて実施される。

図４は、図２の連絡中継アプリケーション２６の抽象アーキテクチャ図である。図２において端末上にはアプリケーション２６のクライアント部分だけが、他の端末上にはアプリケーション２６のサーバ部分だけが示されており、図４は、クライアントのアプリケーション／プロセス２７、２３と、サーバのアプリケーション／プロセス２８、２４が同じ端末デバイス上に実装されることを視覚化している。したがってこれらは、２つの並列のプロセスであり、これらは実質的に互いに独立しているが、これらは、同期化の目的のために互いに影響を及ぼし合う。図４のアーキテクチャ図において、アプリケーション２６は、階層化された様式で示され、それによってスタック・レイヤ３１と、管理レイヤ３２と、ＧＵＩレイヤ３３（ＧＵＩ＝グラフィック・ユーザ・インターフェース）と、永続性メモリ・レイヤ３４とを有する。スタック・レイヤ３１においては、クライアント２７、２３とサーバ２８、２４とは並列に実行される。管理レイヤ３２は、管理のための役割を果たし、この管理は、連絡プロファイルの監視、確立、操作を意味する。ＧＵＩレイヤ３３は、ユーザに対するプロファイル管理と、テスト結果の記述などを可能にする。永続性メモリ・レイヤ３４は、最終的に様々な連絡プロファイルを永続的に記憶する。

管理レイヤ３２の区域には、ＧＵＩレイヤ３３に到達するプロファイル管理コンポーネント３５が存在する。これを用いて、ユーザは、たいていは連絡プロファイル１８を設定し、変更し、再検討し、ここでこれらの連絡プロファイルは、永続性ストレージ・レイヤ３４中の専用プロファイル・メモリに記憶される。以上で説明されるように、クライアント・アプリケーション２７は、それが受信されたショート・プロファイル１６に基づいて決定するような場合、それが、（ショート・プロファイル１６によって表される）連絡プロファイル１８をすでに知っているこのような場合には、連絡確立を開始しない。したがって、クライアントから受信されたショート・プロファイルが記憶されているデータベース３７が、知られているプロファイルについて提供される。前述のように、（専用プロファイル・メモリ３６において）適切な連絡プロファイル１８を設定し、または変更した後に、もしかするとこの変更により影響を受ける、他のデバイスのプロファイル１８は、切り捨てられるべきではない。それに応じて、プロファイル管理コンポーネント３５は、もしかすると影響を受けた、他のデバイスのプロファイルに関連したこれらのショート・プロファイル１６をデータベース３７から除去することにより、このようなプロファイル確立またはプロファイル変更において、知られているプロファイルのデータベース３７に影響を及ぼす。

専用のプロファイル・メモリ・ストレージ３６の他に、永続性メモリ・レイヤ３４は、受信された連絡プロファイル１８のための追加メモリ３８と、パスオン連絡プロファイル１８のためのメモリ３９とを有する。クライアント２７から、すなわち他の端末から受信された連絡プロファイル１８は、メモリ３８に記憶される。結果表示コンポーネント４０において、これらの受信されたプロファイル１８は、ユーザにとって閲覧可能である。受信されたプロファイル１８の処理に相補的に、サーバ・アプリケーション２８は、他の端末からの照会を受信するとすぐに専用プロファイル・メモリから送信されるべき専用プロファイルを取り出す。したがって、メモリ区域３９は、パスオン・プロファイル１８のためのクライアント２７とサーバ２８との間のブリッジを形成する。後で説明しているように、これらのパスオン・プロファイル１８は、次に追加の照会デバイスに伝えることができる、他のデバイス（またはやはり異質プロファイルを処理するサーバ）からの異質プロファイルである。このようなプロファイルの入力は、クライアント２７を経由して実行されるが、それらの出力は、サーバ２８を経由して実行され、パスオン・プロファイルは、一方ではクライアント２７によってメモリ区域３９に書き込むことができ、他方ではサーバ２８によってメモリ区域から読み出すことができる。

図５は、図２のサービス認識プロセス２９の内容を可視化している。このプロセスは、それぞれがサービス・クラスの設定を構成するいくつかのサービス・レコードが記憶されるデータベースを提供する。例えば、サービス「ヘッドセット」についてのＵＵＩＤ「１１０８」を有するサービス・レコード４１と、ファイル転送サービスについてのＵＵＩＤ１１０６を有する追加のサービス・レコード４１’が存在する。最終的には、ここで関心のあるサービス・レコード４１”は、ＵＵＩＤ「ＫＶＤ」を用いて示される。サービス・レコード４１、４１’、４１”のそれぞれは、単一のサービス属性４２の形態の関連するサービス属性データを有する。連絡中継サービス・レコード４１”においては、サービス属性は、ショート・プロファイル１６であり、これらのショート・プロファイルは、照会するクライアント・プロセス２３に対するサービス要求中に連絡中継システムに対して（これはＵＵＩＤ「ＫＶＤ」に対することを意味する）送信される。リストアップされたＵＵＩＤ値は、ブルートゥース分野についての例示にすぎない。ＷＬＡＮの場合には、それらは、対応するポート番号に反映される。

図６は、（例示の値、したがってプロファイル１８を有する）プロファイル・スキーム１１と、関連するショート・プロファイル１６をショート・プロファイル・スキーム４４と一緒に可視化している。その示される実施例は、（「ＣＡ」によって表される）自動車を検索する（「Ｓ」によって表される）ための事前に定義されたプロファイル・スキームである。プロファイル・スキーム１１は、事前に定義された意味を用いてある種の値を仮定することができる一連の属性を含んでいる。例えば、「上位グループ」、「サブグループ」、「最大円」、「連絡データ」、「名前」、「電話」などのような属性が存在する。一部のこれらの属性では、ユーザは、連絡プロファイルを作成するときにユーザ・インターフェースにおいていくつかの可能性の間で、したがってプロファイル・スキーム１１の設定を選択することができる。例えば、上位グループでは、「車」、「トラック」、「オートバイ」が、選択のために提供される。「車」を選択するときには、プロファイル管理コンポーネント３５は、それぞれのコード（ここでは「０１」）を連絡プロファイル１８に入力する。他の属性では、フォーマットの制限があり、例えば数字だけを電話番号の下に入力することができる。さらに、ユーザが、そのような制限なしにデータを入力することができる１つまたは複数の属性（例えば、「自由テキスト」）が存在する。最終的には、その値が自動的にシステムによって導き出される属性、例えばプロファイル識別子（「プロファイル−ＩＤ」）、「実現化カウンタ」、「実現化日付」、「プロファイル番号」があり、これらの値は、プロファイル管理コンポーネント３５によって自動的に生成される。プロファイル−ＩＤは、例えばサービス発見（プロセスを経由したアプリケーション）２７、２３中にクライアントが使用して、（ブルートゥースＳＤＰの場合には）サービス認識プロセス２９からある種のショート・プロファイルをピックアップする（これは、プロファイル識別子は、サービス要求中にサービス属性識別子として使用することもできることを意味する）。異なる実現化を区別できるようにするために、実現化カウンタと、もしかすると実現化日付が提供され、これらの実現化属性はシステムによって値が満たされている。プロファイル番号の値はまた、システムによって割り付けられる。したがって、誰かが、例えば数台の車を購入し、または販売したいと思っている民間セールスマンが、同じプロファイル名をもついくつかのプロファイルを使用するときには、プロファイル番号は、同じタイプのいくつかの連絡プロファイルを区別する役割を果たす。さらに、多数の態様でサーバの状態を表すステータス・ビットが存在する。プロファイル・スキーム１１は、例えばＸＭＬドキュメント定義またはＸＭＬスキームの形式で存在する。

プロファイル・スキーム１１の各設定（これは、「値で」満たされた各連絡プロファイル１８を意味する）は、ショート・プロファイル１６によって表される。図６においては、ショート・プロファイル・スキーム４４の一実施例と、連絡プロファイル１８を表す各ショート・プロファイル１６とが示され、このショート・プロファイルは、例示の様式で図６に示される。「表される」は、ここではショート・プロファイル１６が、完全な連絡プロファイル１８の全部の情報を含んでいることを意味してはいない。もっと正確に言えば、受入れテスト中に第１のフィルタリングを可能にするこの情報の一部分で十分である。例示のショート・プロファイル・スキーム４４は、属性、すなわち「基本タイプ」（固有の）「名前」、「プロファイル番号」、「上位グループ」、「サブグループ」、「実現化番号」を含んでいる。これらの属性の値は、代表する連絡プロファイル１８の基礎となるプロファイル・スキーム１１によって部分的に事前に設定され、他方、これらはユーザまたはシステムが表される連絡プロファイル１８に入力している値によって事前に定義される。第１のクラスに、例えば基本タイプと固有のプロファイル名が属する。基本タイプと固有のプロファイル名は、第１のクラスに属する。図６に実施例に示されるように、基本タイプは、例えば（「検索」についての）「Ｓ」であり、固有名は、（「車」についての）「ＣＡ」である。さらなる基本タイプは、例えば入札プロファイルについての「Ｂ」と、等しい「品質」のプロファイルについての「Ｈ」（ハッシュ）であり、これらは、（入札プロファイルや検索プロファイルのような）肯定的な受入れテストについて相補的な様式でペアリングすることはできないが、同じペアリングを必要とする。残りの属性は、第２のクラスに属する。これらは、ユーザまたはシステムが、表される連絡プロファイル１８に入力している値からもたらされる。そこでもたらされるショート・プロファイル１６は、図６に与えられた実施例では、「ＳＣＡ０２０１０１４」と呼ばれる。連絡プロファイル１８からのショート・プロファイル１６についてのこれらの属性値の推論は、プロファイル管理コンポーネント３５によって自動的に行われる。

図７は、「異質プロファイル」１８の伝搬を可視化している。端末２は、端末２がクライアント３として動作するときにサーバ４として機能する他の端末から連絡プロファイル１８を絶えず受信する。連絡プロファイル１８のこの転送の主要な機能は、前述したように、クライアント端末３は、連絡プロファイル１８に基づいて、クライアント端末が各サーバ端末４に対する連絡を確立したいと望むかどうかを絶えずテストすることができることである。図７に示される実施形態において、サーバ端末４からクライアント端末３への連絡プロファイル１８の送信は、追加の機能を有し、したがって連絡プロファイル１８のさらなる伝搬を（およびそれによって増加も）有する。図４に示されるように、パスオン・プロファイルについてのメモリ３９に基づいて、クライアント・アプリケーション２７は、このメモリ３９を経由してサーバ・アプリケーション２８に対してパスオン・プロファイルを提供し、次にこのサーバ・アプリケーションは、追加の照会するクライアント端末に対してこのパスオン・プロファイルを伝える。これらの照会する連絡プロファイル１８が一般に「専用」連絡プロファイルではないことになるので、これらも「異質プロファイル」と呼ばれる。一部の実施形態では、すべての受信されたプロファイル１８は、無差別に伝えられる。他の実施形態においては、この伝搬は、ある種の条件が満たされるときに実施されるだけである。例えば、確立または最後の実現化が、ある種のしきい値などを超えて進まないので、そのプロファイル、またはその寿命が、ある種のプロファイル・タイプに属するプロファイル１８だけが伝えられる。他の実施形態においては、他の種類の伝搬条件が設定され、したがって伝搬は、友人、または友人の友人についてのネットワーク内で実施されるだけである。これによって、潜在的な受信者がこのリスト中に含まれる場合には、「友人」（したがって信頼可能な受信者）のリストがテストされる。伝搬は、このようなリスト化された受信者に対して実施されるだけである。

図７に示される実施形態においては、連絡中継システムの多数の参加者についての多数の呼び出し可能な連絡プロファイル１８（したがって「異質プロファイル」）を含む定常的プロファイル配信サーバ４３も設けられる。クライアント機能を有する端末２が定常的プロファイル・サーバ４３の範囲内に来るときに、端末２は、多数のこのような連絡プロファイルをロードすることもできる。このような配信サーバ４３の適用は、したがって異質プロファイルの配信を加速する。

前述の実施形態は、連絡中継通信を比較的低いトラフィック負荷で実施することができる連絡中継システムを示している。

本明細書中で述べられているすべての出版物および既存のシステムは、参照により本明細書に組み込まれている。

本発明の教示に基づいて構築されたある種の製品について本明細書中で説明しているが、本特許の範囲は、それだけには限定されない。それとは反対に、本特許は、文字どおりにまたは等価性により添付の特許請求の範囲の範囲に含まれる、本発明の教示によるすべての実施形態を包含している。

連絡中継システムにおける通信パートナーと通信経路を示す概略図である。 通信プロセスの平面に関連した可視化のためのクライアントとサーバの階層化スキームを示す図である。 クライアントとサーバの間の通信とタイミング図に基づいたクライアントおよびサーバ内の処理ステップとを可視的に示す図である。 端末における連絡中継アプリケーションの抽象アーキテクチャ図である。 サービス登録データベースの可視化図である。 プロファイル・スキームと関連するショート・プロファイルを可視化した図である。 異質プロファイルが追加してプログラムされる一実施形態を可視化した図である。 モバイル端末の範囲を可視化した図である。

Claims (30)

1. 互いの範囲に入るときに直接無線連絡を経由してアドホック通信を確立するように設けられ、１つまたは複数のショート・プロファイル（１６）が一方の端末（２）から他方に伝送されており、その後に前記伝送された１つまたは複数のショート・プロファイル（１６）の受入れテストが実施され、その肯定的な結果の後にさらなる通信が開始される、２つ以上のモバイル通信端末（２）によって確立される連絡中継システム（１）であって、
   前記端末（２）が、サービス発見プロセスによるサービス発見に対して設けられ、
   前記１つまたは複数のショート・プロファイル（１６）の前記伝送が、サービス要求（１５）の受信に応じてサービス発見プロセスのコンテキストにおいてサービス属性データとして実施されることを特徴とする連絡中継システム。
2. 連絡中継プロセス中に前記端末（２）のうちの少なくとも１つが、サーバ（３）の機能を有し、前記端末（２）のうちの少なくとも１つが、クライアント（４）の機能を有する請求項１に記載の連絡中継システム。
3. 前記端末（２）が、クライアント機能とサーバ機能を同時に備え、様々なプロセスによって、すなわちクライアント・プロセス（２７）とサーバ・プロセス（２８）によって実装され、これらのプロセス（２７、２８）が並列に実行される請求項２に記載の連絡中継システム。
4. 前記モバイル通信端末（２）が、１つまたは複数のセルラ・モバイル通信ネットワーク中の無線通信において提供され、直接無線連絡機能が、これらのセルラ・モバイル通信端末（２）の追加機能である請求項１から３の一項に記載の連絡中継システム。
5. 前記端末（２）が、ブルートゥース・プロトコルに基づいた直接無線通信のために提供される請求項１から４の一項に記載の連絡中継システム。
6. 前記サービス発見プロセスが、ブルートゥース・サービス発見プロトコルである請求項５に記載の連絡中継システム。
7. 前記端末（２）が、無線ＬＡＮプロトコルに基づく直接無線のために提供される請求項１から６の一項に記載の連絡中継システム。
8. クライアント機能（３）を有する前記端末が、範囲内に配置される他の端末（２）を発見するためにプレゼンス照会（１３）を永続的に送信する請求項２から７の一項に記載の連絡中継システム。
9. クライアント機能（３）を有する前記端末が、ランダムな様式で前記プレゼンス照会（１３）の間の時間間隔を変更する請求項８に記載の連絡中継システム。
10. 前記クライアント端末（３）が、他の端末（２）を発見するとすぐに前記プレゼンス照会（１３）に対するその応答に基づいて前記サービス要求（１５）を他の端末（２）に送信し、すぐにこの発見された端末（２）が、サーバとしてそれに記憶された前記１つまたは複数のショート・プロファイルをサービス属性データとして前記クライアント端末（３）に送信する請求項８または９に記載の連絡中継システム。
11. 前記端末（２）が、前記サービス要求（１５）を送信し、前記１つまたは複数のショート・プロファイル（１６）をサービス属性データとして再送信するときにペアリングされない請求項１から１０の一項に記載の連絡中継システム。
12. クライアント（３）として機能する前記端末は、前記端末が、前記サーバ端末（４）からの前記１つまたは複数のショート・プロファイル（１６）の受信の後に、前記クライアント端末（３）に記憶されるプロファイル情報との比較を介して前記受入れテストを実施するように実現される請求項２から１１の一項に記載の連絡中継システム。
13. 前記受入れテストは、前記クライアント端末（３）が、前記サーバ端末（４）から受信された前記１つまたは複数のショート・プロファイル（１６）をそれ自体のショート・プロファイルと比較することにより実施される請求項１２に記載の連絡中継システム。
14. 前記ショート・プロファイル比較が、同一性テスト、相補性テスト、類似性テスト、あるいは前記完全または部分的なショート・プロファイル（１６）についてのこれらのテストのうちの２つ以上から組み合わされたハイブリッド・テストを含む請求項１３に記載の連絡中継システム。
15. 前記ショート・プロファイル比較が、以前に受信されたショート・プロファイル（１６）を検出するためのプロファイル・バージョン比較を含む請求項１３または１４に記載の連絡中継システム。
16. 前記受入れテストの肯定的な結果の後に、クライアント端末（３）とサーバ端末（４）のペアリングが実施される請求項２から１５の一項に記載の連絡中継システム。
17. 前記ショート・プロファイル（１６）が連絡プロファイル（１８）を表し、さらなる通信が、その関連するショート・プロファイル（１６）が前記受入れテストを合格している前記各連絡プロファイル（１８）を送信することを含む請求項２から１６の一項に記載の連絡中継システム。
18. 前記連絡プロファイル（１８）の伝送は、クライアント（３）として機能する前記端末が、前記連絡プロファイル（１８）を伝送する要求をサーバ（４）として機能する前記端末に送信し、前記サーバ端末が、この要求に対する応答として前記各連絡プロファイルを前記クライアント端末に送信することにより実施される請求項２から１７の一項に記載の連絡中継システム。
19. クライアント（３）として機能する前記端末が、前記受信された連絡プロファイル（１８）に連絡開始テストを受けさせ、その肯定的な結果の後に実際の連絡開始を開始させる請求項１８に記載の連絡中継システム。
20. 実際の連絡をすることが、以下の方法、すなわち直接無線通信を経由して前記サーバ端末（４）と音声連絡をすること、セルラ通信を経由して前記サーバ端末（４）または他の端末と音声連絡をすること、直接無線通信を経由して前記サーバ端末（４）にメッセージを送信すること、セルラ通信を経由して前記サーバ端末（４）または他の端末にメッセージを送信すること、セルラ通信を経由してコード・サービス（９）にメッセージを送信すること、のうちの１つまたは複数を介して実施される請求項１９に記載の連絡中継システム。
21. 連絡プロファイル（１８）を表す前記ショート・プロファイル（１６）が、ユーザによって前記連絡プロファイル（１８）中に入力され、または前記端末（２）によって前記連絡プロファイル（１８）において生成される値に依存することなく、前記連絡プロファイル（１８）が基づいているプロファイル・スキーム（１１）によって不変とされる請求項１から２０の一項に記載の連絡中継システム。
22. 連絡プロファイル（１８）を表す前記ショート・プロファイル（１６）が、ユーザによって前記連絡プロファイル（１８）中に入力され、または前記端末（２）によって前記連絡プロファイル（１８）において生成される値に部分的に依存する請求項１から２０の一項に記載の連絡中継システム。
23. 前記端末（２）が、それらを表す前記ショート・プロファイル（１６）にユーザによって入力される前記値を符号化するために提供される請求項２２に記載の連絡中継システム。
24. 前記連絡プロファイルが、宣言言語のシンタックスの形で実現され、関連する事前に定義されたプロファイル・スキームが、ドキュメント・タイプまたはスキームの定義として提供される請求項１から２３の一項に記載の連絡中継システム。
25. 前記端末（２）が、セルラ・モバイル通信ネットワークを経由して連絡プロファイル（１８）を事前に定義するプロファイル・スキーム（１１）をダウンロードすることができるように、またプロファイル・スキーム（１１）をダウンロードした後にユーザに個別の連絡プロファイル（１８）を作成するためにユーザによってその中に個々の値を入力することができるように提供される請求項４から２４の一項に記載の連絡中継システム。
26. 前記端末（２）が、他のユーザを起源とするプロファイル（１８）、いわゆる異質プロファイルを受信し、それらのプロファイルを他のユーザにさらに配信するように提供される請求項１から２５の一項に記載の連絡中継システム。
27. 前記端末（２）に記憶される前記異質プロファイル（１８）が、以前の連絡中継中に他の端末から受信されたプロファイルである請求項２６に記載の連絡中継システム。
28. 前記異質プロファイル（１８）が、異質プロファイル配信デバイス（４３）から受信されたプロファイルである請求項２６または２７に記載の連絡中継システム。
29. 請求項１から２８の一項に記載の連絡中継システム（１）に参加するように設けられたモバイル通信端末（１）。
30. ストレージ媒体上に記憶されるか、モバイル通信端末（２）に伝送するのに適した信号シーケンスとして提供されるコンピュータ・プログラムであって、モバイル通信端末（２）上で実行されるときに請求項１から２８の一項に記載の連絡中継システム（１）における端末（２）の機能を可能にするコンピュータ・プログラム。

Images