(57)【要約】【課題】コンピュータによる通信において、発信者は、数多くの通信方法の中から通信方法を決定しなければならない。【解決手段】発信者クライアントシステムと着信者クライアントシステムとの間の通信は、通信プログラムのリストから適当な通信プログラムを選択することに基づく。その通信プログラムのリストは、着信者の通信環境に基づいて決定される。【選択図】      図１
2006318019.tif 000002
【特許請求の範囲】
【請求項１】
発信者と着信者との間で通信するための方法であって、
第１のクライアントシステムにおいてログオンシーケンスを実行するためにサーバシステムと通信し、前記第１のクライアントシステムは、前記第１のクライアントシステムに関連付けられる許可リストを有し、前記サーバシステムは、前記第１のクライアントシステムから離隔され、
前記第１のクライアントシステムから前記サーバシステムに前記許可リストを通信し、
前記サーバシステムから一つ以上の第２のクライアントシステムに前記許可リストを通信することができ、
前記許可リストは、前記第１のクライアントシステムの第１のユーザと通信するために用いることができる一つ以上の通信プログラムを特定することを特徴とする方法。
【請求項２】
前記許可リストは、前記クライアントシステムに導入され、かつ前記クライアントシステムの所在地において用いることができる通信プログラムに少なくとも基づくことを特徴とする請求項１に記載の方法。
【請求項３】
前記一つ以上の通信プログラムは、ユーザによって選択された通信プログラムを含むことを特徴とする請求項１に記載の方法。
【請求項４】
前記サーバシステムで第３のクライアントシステムからログオンシーケンスを実行し、前記第３のクライアントシステムは、前記第３のクライアントシステムに関連付けられる第２の許可リストを有し、
前記第２の許可リストを前記サーバシステムに通信し、
前記サーバシステムから前記第２のクライアントシステムに前記第２の許可リストを通信し、
前記第２の許可リストは、前記第３のクライアントシステムと通信するために用いることができる一つ以上の通信プログラムを特定することを特徴とする請求項１に記載の方法。
【請求項５】
前記第１のクライアントシステムは、さらに、前記第１のクライアントシステムに関連付けられるバディリストを有し、前記バディリストは、前記一つ以上の第２のクライアントシステムを含むことを特徴とする請求項１に記載の方法。
【請求項６】
前記許可リストを変更して、変更されたリストを作成し、前記変更されたリストを前記サーバシステムに通信し、
前記変更されたリストを、前記一つ以上の第２のクライアントシステムに通信することができ、前記一つ以上の第２のクライアントシステムは、前記変更されたリスト内の通信プログラムの中から選択された通信プログラムを用いて、前記第１のクライアントシステムと通信することができることを特徴とする請求項１に記載の方法。
【請求項７】
前記許可リストを作成する手順において、
前記第１のクライアントシステムに記憶される第１の複数の通信プログラムを指示する第１の情報を入手し、
第２の複数の通信プログラムを指示する第２の情報を入手し、前記第２の通信プログラムは、前記第１のクライアントシステムの所在地に基づく、第２の情報を入手し、
前記許可リストは、前記第１の複数の通信プログラム及び前記第２の複数の通信プログラムに共通する通信プログラムを含むことを特徴とする請求項１に記載の方法。
【請求項８】
前記許可リストを作成する手順において、さらに、ユーザが予め定めた通信プログラムのリストを表す第３の複数の通信プログラムを示す第３の情報を入手することを含み、前記許可リストは、前記第１の複数の通信プログラム、前記第２の複数の通信プログラム及び前記第３の複数の通信プログラムに共通する通信プログラムを含むことを特徴とする請求項７に記載の方法。
【請求項９】
クライアントシステムの間で通信する方法であって、
第１のクライアントにおいてサーバから複数の許可リストを受信し、各前記許可リストは、複数の第２のクライアントの中の一つの第２のクライアントに関連付けられ、一つ以上の通信プログラムに関連付けられる情報を含み、
前記第１のクライアントにおいて前記許可リストを表す情報を提供し、
前記第１のクライアントにおいて、前記第２のクライアントのうちの一つ以上を特定する通信要求を受信し、
前記許可リストに基づいて、前記一つ以上の第２のクライアント毎に通信プログラムを判定し、前記通信プログラムを用いて、前記一つ以上の第２のクライアントと通信し、前記通信要求に応じることを含むことを特徴とする方法。
【請求項１０】
各前記許可リストは、関連する前記第２のクライアントにおいてユーザによって作成されることを特徴とする請求項９に記載の方法。
【請求項１１】
前記一つ以上の第２のクライアントから一つ以上の変更されたリストを受信し、前記変更されたリストは、前記第２のクライアントが、異なる１組の通信プログラムを特定するために前記第２のクライアントに関連する許可リストを変更する際に作成されることを特徴とする請求項９に記載の方法。
【請求項１２】
前記第１のクライアントは、関連する許可リストが前記第１のクライアントによって受信された全ての第２のクライアントに関連付けられるバディリスト上にあることを特徴とする請求項９に記載の方法。
【請求項１３】
ネットワーク化された通信システムであって、
複数のクライアントシステムと、
前記クライアントシステムとデータ通信するサーバシステムと、
前記複数のクライアントシステムの中の第１のクライアントシステムと、
前記複数のクライアントシステムの中の第２のクライアントシステムと、を備え、
前記第１のクライアントシステムは、
前記第１のクライアントシステム上で動作することができる一つ以上の通信プログラムの第１のリストを作成する手順と、
前記第１のクライアントシステムの所在地において用いることができる一つ以上の通信プログラムの第２のリストを作成する手順と、
少なくとも前記第１のリスト及び前記第２のリストに基づいて許可リストを作成する手順と、
前記許可リストを前記サーバシステムに通信する手順と、を前記第１のクライアントシステムに実行させるために構成されたプログラムコードを含み、
前記第２のクライアントシステムは、前記第２のクライアントシステムに前記サーバシステムから許可リストを受信させるために構成されたプログラムコードを含み、前記許可リストに関連付けられるクライアントシステムとの通信は、前記許可リストの中に含まれる通信プログラムを用いて行うことができ、
前記サーバシステムは、
前記第１のクライアントシステムから許可リストを受信する手順と、
前記第１のクライアントシステムに関連付けられるバディリストから一つ以上のバディクライアントシステムを特定する手順と、
前記許可リストを一つ以上の前記バディクライアントシステムに通信する手順と、を前記サーバシステムに実行させるために構成されたプログラムコードを含むことを特徴とするネットワーク化されたシステム。
【請求項１４】
前記許可リストを前記サーバシステムに通信する手順は、ログオンシーケンス中に実行されることを特徴とする請求項１３に記載のシステム。
【請求項１５】
前記許可リストは、前記第１のリスト及び前記第２のリストに共通の通信プログラムを含むことを特徴とする請求項１３に記載のシステム。
【請求項１６】
前記第１のクライアントシステムの前記プログラムコードは、さらに、ユーザによって選択された一つ以上の通信システムの第３のリストを作成する手順を前記第１のクライアントシステムに実行させるために構成され、前記許可リストは、さらに、前記第３のリストに基づくことを特徴とする、請求項１３に記載のシステム。
【請求項１７】
前記許可リストは、前記第１のリスト、前記第２のリスト及び前記第３のリストに共通の通信プログラムを含むことを特徴とする請求項１３に記載のシステム。
【請求項１８】
サーバシステムとデータ通信し、他のクライアントシステムと通信するために構成されるクライアントシステムであって、
前記クライアントシステムは、
前記クライアントシステムに導入される通信プログラムと、前記クライアントシステムの物理的な所在地に応じて用いることができる通信プログラムとに基づいて許可リストを作成する手順と、
前記許可リストを前記サーバシステムに通信する手順と、を実行するために構成されるプログラムコードを含み、
前記許可リストを、前記他のクライアントシステムの中の第１のクライアントシステムに通信することができ、前記第１のクライアントシステムは、前記許可リストにおいて特定される通信プログラムを用いて、前記クライアントシステムと通信することができることを特徴とするクライアントシステム。
【請求項１９】
前記プログラムコードは、さらに、ログインシーケンスを実行するために前記サーバシステムと通信する手順を実行するように構成され、前記許可リストを通信することは前記ログインシーケンス中に実行されることを特徴とする、請求項１８に記載のクライアントシステム。
【請求項２０】
前記クライアントシステムは、前記クライアントシステムに関連付けられるバディリストを有し、前記バディリストは、前記第１のクライアントシステムを含むことを特徴とする請求項１８に記載のクライアントシステム。
【請求項２１】
前記許可リストの作成は、さらに、ユーザによって選択された通信プログラムに基づき、前記許可リストは、前記クライアントシステムに導入される通信プログラム、前記クライアントシステムの前記所在地に応じて用いることができる通信プログラム、及び、前記ユーザによって選択された通信プログラムに共通する通信プログラムを含むことを特徴とする、請求項１８に記載のクライアントシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はネットワークによる通信に関し、特に、ネットワークを構成するユーザ間で通信するのに適した一つ又は複数の通信プログラムを選択することに関する。
【背景技術】
【０００２】
コンピュータによる通信は、電子メール（以下、Ｅメール）、インスタントメッセージ（以下、ＩＭ）、ボイスオーバーインターネットプロトコル（以下、ＶｏＩＰ）、テレビ会議などを含む、多数の通信形態を提供する。結果として、発信（あるいは通信）を開始しようとする人（発信者）は、数多くの通信方法の中から通信方法を決定しなければならない場合がある。通信方法を選択する際には、発信の時刻、発信の相手（着信者）、着信者の居場所、着信者が利用することができる技術、等を考慮してもよい。この決定過程は、ピア・ツー・ピア（Ｐ２Ｐ）ネットワークのようなプライベートネットワークでは重要になる可能性がある。状況によっては、発信者は着信することを確認したい場合があり、発信を試みる前に、着信できるか否かを予め知る（着信できない場合には、発信しようとする過程を回避する）ことを望む場合がある。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
例えば、１日のうちで発信が行われる時刻が重要である場合がある。着信者は、１日のうちでも時刻が異なれば、別の通信形態を望む場合がある。着信者は、夜間（例えば、就寝中）にはＩＭよりもＥメールを望むかもしれない。着信者の居場所によって、都合のよい通信方法が決まる場合もある。例えば、着信者が、たまたまインターネットカフェで喫茶しており、帯域幅が限られているか、あるいはサービス品質が不十分である場合には、その着信者はＶｏＩＰよりもＩＭを望むかもしれない。着信者が、一つの通信方法を特に望むこともある。着信者のシステムに導入されているデバイスも決定的な要因である。以下において、用語「通信環境」は、着信者と通信するために発信者が考慮すべき、着信者に関する一群の要因を表す。
【０００４】
したがって、通信環境は、日時、着信者の居場所、着信者の好み等を含んでもよい。通信しようとする際に、着信者のクライアントシステムがオンラインであるか、オフラインであるかも、通信環境の一部と見なされる場合がある。例えば、Ｐ２Ｐネットワークでは、ユーザがＰ２Ｐネットワークにログオンしている場合、そのユーザは「オンライン」である。また、ユーザがネットワークからログオフしている場合、そのユーザは「オフライン」である。ユーザがログオンしているが、ユーザのＰＣ（ラップトップあるいは他の適当な通信装置）が、ある時間にわたって休止している場合、あるいはそうでなくても、ユーザが通信を利用することができないことを示す場合には、そのユーザも「オフライン」であると見なすことができる。オンライン／オフライン状態は一般的に「存在（プレゼンス）」と呼ばれる。着信者の存在情報を用いて、適当な通信形態を決定することができる。例えば、着信者がオンラインである場合には、ＩＭが適当な通信形態である場合がある。それに対して、着信者がオフラインである場合には、携帯電話が適当である場合がある。
【課題を解決するための手段】
【０００５】
本発明は、発信者と着信者との間で通信するための方法であって、第１のクライアントシステムにおいてログオンシーケンスを実行するためにサーバシステムと通信し、前記第１のクライアントシステムは、前記第１のクライアントシステムに関連付けられる許可リストを有し、前記サーバシステムは、前記第１のクライアントシステムから離隔され、前記第１のクライアントシステムから前記サーバシステムに前記許可リストを通信し、前記サーバシステムから一つ以上の第２のクライアントシステムに前記許可リストを通信することができ、前記許可リストは、前記第１のクライアントシステムの第１のユーザと通信するために用いることができる一つ以上の通信プログラムを特定することを特徴とする。
【発明の効果】
【０００６】
本発明によって、発信者が着信者と通信するために選択することができる１組の通信プログラムが自動的に判定される。そのリストは、着信者の通信環境に基づいて、着信者のクライアントシステムにおいて判定される。そのリストは、着信者に関するバディリストを用いて、発信者のクライアントシステムに配信することができる。
【発明を実施するための最良の形態】
【０００７】
本発明の態様、利点および新規の特徴は、以下に記載される本発明の説明及び添付の図面から明らかになるであろう。
【０００８】
図１は、本発明の実施の形態による「許可リスト」の概念の説明図である。許可リストは、着信者クライアントシステムにおいて利用することができる通信プログラムを特定する。クライアントシステム（着信者クライアントシステム又は発信者クライアントシステム）の典型的な例には、パーソナルコンピュータ（ＰＣ）、ラップトップコンピュータ、携帯情報端末（ＰＤＡ）及びネットワーク上で通信するための他の適当な装置が含まれる。典型的な通信プログラムには、モデムで通信するためのモデムプログラムが含まれる。ネットワーク型の通信プログラムは、種々のインスタントメッセージ技術、ＶｏＩＰ等を含む。テレビ会議ソフトウエアシステムも別の型の通信プログラムである。Ｅメールクライアントもさらに別の型の通信プログラムである。
【０００９】
図１は、図中に斜線によって示される、許可リスト１０２を作成するための１つの方法を示す。クライアント有効リスト１１２はクライアントシステム装置に導入されている通信プログラムのリストである。クライアント有効リスト１１２は自動的に作成することができる。たとえば、マクロソフトウインドウズ（登録商標）レジストリデータベースを検査して、そのシステムに導入されている通信プログラムのリストを取得することができる。あるいは、クライアント有効リスト１１２は、ユーザが手作業で作成することができる。クライアント有効リスト１１２は導入されている通信プログラムを表すため、おそらく、装置ごとに一つのクライアント有効リスト１１２のみが存在する。しかしながら、クライアントシステム装置は、複数のユーザのための種々の通信装置の組を使用できるように構成することができる。その場合、複数のクライアント有効リストが存在することになる。
【００１０】
利用することができる通信方法は、クライアントシステム装置が位置する場所、たとえばオフィス、自宅、ホテルの部屋、空港、インターネットカフェなどによって異なる可能性がある。ロケーション有効リスト１１４は、クライアントシステム装置と通信することができる所定の場所に適した通信プログラムを特定する。たとえば、所定のサイトのＩＳＰのようなネットワーク事業者（又は他のネットワーク管理者）が、そのサイトのユーザを、特定のアプリケーションプログラム又は特定のプロトコルに限定する場合もある。例えば、ファイアウォール及びプロキシがＨＴＴＰプロトコルのみを許可する場合がある。そのようなロケーション毎に１つのロケーション有効リスト１１４が存在する。典型的には、クライアントシステム装置には、一つ以上のロケーション有効リストが格納される。あるいは、サーバ上に所定のロケーション有効リストを記憶して、他の人が再利用することができる。これは、ホテル、空港等の公共の場所に関連するリストの場合に好都合であろう。例えば、ホテルが提供する通信サービスに適した通信プログラムを指示するロケーション有効リストを、そのホテルが提供することができる。こうして、ユーザが空港から、例えばホテルに移動するときに、ロケーション有効リストが切り替わり得る。
【００１１】
ユーザプリファレンスリスト１１６は、ユーザが通信するために用いることを望む通信プログラムを特定する。例えば、自分のコンピュータがＶｏＩＰ機能を有する場合であっても、ユーザはＥメール及びＩＭを望む場合がある。ユーザプリファレンスリスト１１６を用いて、許可リスト１０２内の通信プログラムのリストをさらに限定することができる。
【００１２】
許可リスト１０２は、上記の三つのリスト、すなわちクライアント有効リスト１１２、ロケーション有効リスト１１４及びユーザプリファレンスリスト１１６のそれぞれに共通する通信プログラムのリストを含む。許可リストは、このように着信者によって作成され、着信者クライアントシステム、その所在地及びそのユーザを考慮に入れた通信プログラムを反映する。
【００１３】
クライアント有効リスト１１２、ロケーション有効リスト１１４及びユーザプリファレンスリスト１１６が図１にベン図で表される。許可リスト１０２は、他の３つのリストの共通部分から生成される集合である。その共通部分が空リスト（すなわち、三つのリスト全てに共通する通信プログラムがない）を生成する場合、本発明の特定の実施形態によれば、クライアント有効リスト１１２及びロケーション有効リスト１１４のみの共通部分に基づいて、許可リスト１０２を作成することを試みる。
【００１４】
クライアント有効リスト１１２及びロケーション有効リスト１１４のみに基づいて許可リスト１０２を決定してもよいことの理論的根拠は、これらの２組の通信プログラムが、クライアントシステム装置と通信するために必要とされる「最低限の能力」を表すことである。第１に、クライアント有効リスト１１２は、着信者のクライアントシステム装置に導入されている通信プログラムを特定し、着信者のシステムの通信能力を表している。第２に、ロケーション有効リスト１１４は、そのリストに関連付けられる場所において使うことができる通信プログラムを特定する。
【００１５】
クライアント有効リスト１１２がモデムプログラムを含む場合には、自動ボーレート調整によってボーレートの差を調整できるものと仮定すると、モデムプログラムを有するいずれの発信者クライアントシステムも着信者と通信することができる。クライアント有効リスト１１２がベンダーＸ社由来のＶｏＩＰ通信パッケージを含む場合には、ベンダーＸ社と互換性のあるＶｏＩＰ通信パッケージを有するいずれの発信者クライアントシステムもその着信者と通信することができる。同様に、ロケーション有効リスト１１４がベンダーＺ社由来の特殊なＩＭ通信プログラムを特定する場合には、互換性のあるＩＭ通信プログラムを有するいずれの発信者も着信者と通信することができる。クライアント有効リスト１１２及びロケーション有効リスト１１４の共通部分が空集合である場合には、許可リスト１０２は空リストであり、着信者と通信できないことを示す。
【００１６】
図１に示す概念を二つの例によって示す。着信者クライアントシステムのためのクライアント有効リスト１１２が以下の通信プログラムを含むものと仮定する。
ＡＢＣ‐モデム‐プログラム
ＸＹＺ‐ＶｏＩＰ‐プログラム
着信者クライアントシステムの現在の所在地（例えば、ホテル）に関連付けられるロケーション有効リスト１１４が以下のプログラムを含むものと仮定する。
ＳＰＣＬ‐ＶｏＩＰ‐プログラム
この例では、ＸＹＺ‐ＶｏＩＰ‐プログラム及びＳＰＣＬ‐ＶｏＩＰ‐プログラムには互換性がなく、例えば、それらのプログラムが専用プロトコルを用いるものと仮定される。ユーザプリファレンスリスト１１６は空であると仮定する。上記の二つのリストに基づくと、両方のリストに共通する通信プログラムが存在しないので、許可リスト１０２は空である。いずれのリストもＶｏＩＰプログラムを有するが、いずれも他方のプログラムと連携しないので、共通のＶｏＩＰプログラムは存在しない。
【００１７】
次の例では、ロケーション有効リスト１１４がＪＫ‐モデム‐プログラムを含むように更新される結果、以下のプログラムを含むものと仮定される。
ＳＰＣＬ‐ＶｏＩＰ‐プログラム
ＪＫ‐モデム‐プログラム
大部分のモデム装置が標準化された通信形式を使用し，基本モデムコマンドセット（例えば、ＡＴコマンド）に対応するため、問題なく、全てのモデムが互換性を有するものと仮定することができる。再び、ユーザプリファレンスリスト１１６は空であると仮定する。すると、この例では、許可リスト１０２は以下のプログラム識別子を含む。
ＡＢＣ‐モデム‐プログラム
ＪＫ‐モデム‐プログラム
次の例では、ユーザプリファレンスリスト１１６が以下の通信プログラムを指定するものと仮定する。
ＩＭ‐プログラム
さらに、ロケーション有効リスト１１４が以下のプログラムを指定するものと仮定する。
ＳＰＣＬ‐ＶｏＩＰ‐プログラム
ＪＫ‐モデム‐プログラム
クライアント有効リスト１１２、ロケーション有効リスト１１４及びユーザプリファレンスリスト１１６の間に共通する通信プログラムは存在しない。結果として、許可リスト１０２は、クライアント有効リスト１１２及びロケーション有効リスト１１４に基づいて決定され、先に説明したように、二つのモデムプログラムを含む。
【００１８】
図２は、本発明に従って構成される簡単なネットワークを示す。特定の実施態様では、そのネットワークはＰ２Ｐ（ピア・ツー・ピア）ネットワークである。クライアントシステム２１２、２１４のユーザがサーバ２０２にログオンしている。上記のように、ユーザクライアントシステム２１２、２１４は、ネットワーク上で通信するように構成される任意の種類の通信装置を介してネットワークに接続することができる。クライアントシステムは、ログインシーケンス及び関連するタスクを実行するために用いられるプログラムを含む。例えば、後に説明する図４及び図６に示す処理を、適当なソフトウエアで実行することができる。
【００１９】
「バディ」及び「バディリスト」の概念はよく知られている。簡単に述べると、通信ネットワークに接続される２人のユーザ間の特定の関係が「バディ」として知られている。バディは通常、互いに認証し合った関係を示す。例えば、バディ関係を確立するために、Ｅメールの交換を行うことができる。ＩＭ及びマイクロソフトウインドウズ（登録商標）メッセンジャーのような通信技術は、バディリストを用いる。バディリストは、ユーザに関連付けられており、そのユーザのバディを記載する。このため、一つのクライアントシステムが、そのクライアントシステムの各ユーザに一つのバディリストを、一つ又は複数有することがある。
【００２０】
ユーザ（ユーザＡ、ユーザＢ）がサーバ２０２にログオンするとき、ログオンしたユーザの存在がオフラインからオンラインに切り替わる。そのような存在情報は典型的にはサーバによって管理される。その後、バディリストを用いて、サーバ２０２は、そのユーザのバディに、そのユーザのネットワーク上での存在が変化したことを通知することができる。バディリストは、サーバ２０２に記憶されてもよいし、ログオンシーケンスの一部としてサーバ２０２に通信されてもよい。そのユーザのログインしているバディは、通知によって、そのユーザの存在を知ることができる。あるいは、ユーザのクライアントシステムがその通知を実行することができるが、その場合、そのクライアントシステムは、バディ毎の存在情報を取得しなければならない。
【００２１】
本発明の実施形態の例によれば、ユーザがログオンする際、さらに、ユーザのバディリストに従って、ユーザの許可リストが配信される。図３は、本発明のこの態様を図示する。ユーザＢがサーバ２０２にログオンすると、ユーザＢのクライアントシステム２１４は、ユーザＢの許可リストを、ユーザＢとバディ関係にあるユーザ、すなわちユーザＢのバディリスト３０２内のユーザに通信する。例えば、ユーザＡは、ユーザＢのバディリストに記載されているので、ユーザＢの許可リストを受信する。同様に、別のユーザ、すなわちユーザＣがログオンする場合には、ユーザＣのクライアントシステム２１６は、ユーザＣのバディリスト３０４に従って、ユーザＣの許可リストを通信する。
【００２２】
許可リスト１０２は、他のユーザによって呼び出されるか、又は通信を確立する相手となり得る１人以上のユーザを有する各クライアントシステムに関連付けられる。そのようなクライアントシステムは、着信者クライアントシステムと呼ばれる。逆に、ユーザが発信するクライアントシステムは、発信者クライアントシステムと呼ばれる。当然、大抵の場合、クライアントシステムは、発信者クライアントシステム及び着信者クライアントシステムの両方になることができる。
【００２３】
図４のフローチャートは、サーバ２０２に送信されることになる許可リスト１０２を有するクライアントシステムの処理の流れを示す。ステップ４０１では、ユーザが、許可リスト１０２の作成を開始する動作を実行する。例えば、ユーザは、システムにログオンするか、又は既にログオンしている場合には、自分のクライアント有効リスト１１２及び／又はユーザプリファレンスリスト１１６を更新してもよい。あるいは、ユーザは、新たな場所に移動してもよい。例えば、ユーザはラップトップコンピュータを持ってオフィスからインターネット設備のあるカフェに移動する場合があり、その結果、ロケーション有効リスト１１４が変更される。
【００２４】
ステップ４０２では、クライアント有効リスト１１２、ロケーション有効リスト１１４及びユーザプリファレンスリスト１１６について、共通の通信プログラムの有無が検査される。ステップ４０３において、共通の通信プログラムがあるか否かが判定される。共通のプログラムが存在する場合、ステップ４０７において、その共通のプログラムを含む許可リスト１０２が作成される。共通のプログラムが存在しない場合、ステップ４０４において、クライアント有効リスト１１２及びロケーション有効リスト１１４のみについて、共通の通信プログラムの有無が検査される。ステップ４０５において、共通のプログラムが存在すると判定される場合には、ステップ４０７が実行されて、新たな許可リスト１０２が作成される。ステップ４０５において、共通のプログラムが存在しないものと判定される場合には、ステップ４０６において、空の新たな許可リスト１０２が作成される。なお、「共通の」プログラムは、後に説明されるように、同一のプログラム及び互換性のあるプログラムを含む。
【００２５】
新たな許可リスト１０２の処理は、ステップ４０８に進む。ステップ４０８において、新たなリストが以前に作成された許可リストと比較され、以前のバージョン及び新たなバージョンが「互換性のある」通信プログラムを含むか否かが判定される。いくつかの通信方法の場合に、そのリストの２つのバージョンがそれぞれ同一のプログラムを特定する必要はない。上記の例において言及されたように、異なるベンダーから供給される場合でも、モデムプログラムに互換性がある場合がある。図には示さないが、上記のステップ４０８及びステップ４０２において、ある形式の互換表を用いて互換性のあるプログラムを特定することができる。
【００２６】
ステップ４０８において、新たな許可リスト１０２が以前に作成されたリストと同じであると判定された場合、処理はステップ４０１に戻り、別のきっかけとなる動作を待つ。新たな許可リスト１０２が以前のリストと異なるものと判定された場合には、新たな許可リスト１０２がサーバ２０２に通信される。
【００２７】
ここで、図５を参照して、サーバ２０２における許可リスト１０２の処理について説明する。図５に示す処理は、ステップ５０１において、クライアントシステム、例えば図２に示す着信者クライアントシステム２１４から許可リスト１０２を受信することによって開始する。ステップ５０２では、そのクライアントシステムに関連付けられるバディリストが参照される。バディリストは典型的には、サーバ２０２がアクセス可能な記憶装置に記憶される。あるいは、バディリストは、新たな許可リストとともに、クライアントシステムによってサーバに通信されてもよい。他の代替形態も同様に用いることができることは当業者には理解されよう。
【００２８】
ステップ５０３では、バディリストにおいて特定されたいずれかのバディがオンラインであるか否かが判定される。当然、「オンライン」の定義は実施態様によって変わる可能性がある。本発明では、バディリストに記載されるバディのクライアントシステム（たとえば図２のシステム２１２）がオンラインである場合、そのクライアントシステムに新たな許可リストを通知することができると仮定される。
【００２９】
バディがいずれもオンラインでない場合、処理は単にステップ５０１に戻り、クライアントシステムからの別の新たな許可リスト１０２を待つ。そうでない場合には、ステップ５０４において、オンラインであるバディ毎に、そのバディのクライアントシステムとの通信が実行され、新たな許可リストが通信される。これを達成するために、「プッシュ技術」として知られるインターネット技術を用いることができる。新たな許可リスト１０２を、そのバディのクライアントシステムに「プッシュ」することができる。あるいは、バディのクライアントシステムは、単に、新たな許可リストが存在することを通知され、そのクライアントシステムは都合のよいときにその情報を入手してもよい。Ｅメールを用いて、新たな許可リストを通信することもできる。バディ毎に異なる通信方法が用いられてもよい。例えば、バディ−１はＥメールによって新たな許可リスト１０２を通信されてもよく、一方、バディ−２には、新たな許可リスト１０２がプッシュされてもよい。全てのバディが取り扱われた後、処理はステップ５０１に戻り、別の新たな許可リストの到着を待つ。
【００３０】
ここで、図６を参照して、許可リスト１０２を通知されたクライアントシステムにおける処理について説明する。ステップ６０１では、新たな許可リスト１０２が受信されるか、それ以外の方法でサーバ２０２によって通信されたときに処理が開始する。サーバが単に新たな許可リスト１０２が存在することを通知する場合、クライアントシステムは、その内容を何らかの方法でサーバから入手しなければならない。
【００３１】
クライアントシステムは一つ以上の着信者リストを保持し、そのクライアントシステムにおいてユーザが通信を開始することができる着信者を特定することができる。例えば、図７は、ユーザに対して表示され得る着信者リストに含まれる情報を示す。図示されるように、その情報は、着信者の識別情報と、その着信者に関連付けられる通信プログラムのリストとを含む。新たな許可リストを受信すると、ステップ６０２において、許可リストに関連付けられる着信者の着信者リストが、新たな許可リストに含まれる情報を反映するように更新される。
【００３２】
ここで、図７を参照する。各着信者リストに含まれる情報は、例えば、グラフィカルユーザインターフェース（ＧＵＩ）を介してユーザに対して表示されてもよい。図７に示すＧＵＩの例は、一つ以上の着信者リストに含まれる情報を表形式で表示する。表示される着信者のリストはユーザに依存する。例えば、各ユーザは、独自の着信者リストを有する場合がある。ＧＵＩは、各着信者を特定するためのバディフィールドを含んでもよい。着信者ボタン７０２は、各着信者に関連付けられてもよい。各着信者に関する利用可能リストフィールドに、その着信者と通信するために利用することができる通信プログラムを列挙することができる。各通信プログラムに関連付けられる「ボタン」７０４が図示される。図示するように、所定の着信者が利用することができない通信プログラムのボタンは、暗く表示することができる（図７の斜線の網掛け）。ユーザは、着信者ボタン又は暗く表示されていない通信プログラムボタンを「クリック」して、その着信者との通信を開始することができる。
【００３３】
図６に戻る。ステップ６０３において、着信者ボタンが押されたことが検出された場合、ステップ６０４において、「押された」着信者ボタンに関連付けられる着信者リストが空であるか否か判定される。着信者リストが空である場合、ステップ６０５において、適当なメッセージが表示される。着信者リストが空でない場合、ステップ６０６において、利用可能な通信方法のうちの１つが選択される。着信者リストが、選択することができる複数の通信プログラムを含む場合、いくつかの選択基準を用いることができる。例えば、着信者は、プログラムのリストを優先順（望ましい順）に並べることができる。その優先情報は許可リスト１０２に含まれ、発信者クライアントシステムは、その優先順に基づいて選択を実行することができる。あるいは、その選択は、所定の基準に基づいてもよい。たとえば、ＶｏＩＰが利用可能である場合には、ＶｏＩＰを利用し、そうでない場合にはＩＭを試みる、等である。
【００３４】
別の実施形態では、発信者は通信ボタン７０４のうちの１つをクリックしてもよい。すると、選択された通信プログラムを用いて、着信者との通信を開始することができる。
【００３５】
さらに別の実施形態では、図７に示されるＧＵＩに、ユーザが通信するための２人以上の着信者を選択できるようにするための機能を設けることができる。例えば、バディフィールド内の１人以上の着信者の周囲に「選択ボックス」を描く。一つの通信プログラムを選択するための基準として、選択された着信者の間で共通であるプログラムを用いることができる。選択された着信者の間に共通のプログラムが存在しない場合には、複数の基準を用いることができる。
【００３６】
図４に戻る。ユーザがネットワークからログアウトするときに、空の許可リスト１０２を用いることができる。サーバ２０２は、ログアウトシーケンスを検出すると、システムをログオフしているユーザのバディに空の許可リストを送信することができる。このとき、空の許可リストを受信したバディのＧＵＩは、その着信者の全てのボタンを暗くして表示することによって、その着信者と通信することができないことを表示する。空の許可リストを通信する代わりに、オンラインであるが、通信することができない着信者と、ログアウトしている着信者とを区別することが望ましい場合もある。その場合、サーバは、空の許可リストを送信する代わりに、着信者がログオフしていることを示すものを通信することができる。
【図面の簡単な説明】
【００３７】
【図１】本発明の実施の形態による、許可リストの作成の例を示す図である。
【図２】本発明の実施の形態を示すシステムレベルのブロック図である。
【図３】本発明による許可リストの配信を示す図である。
【図４】着信者側における本発明の態様を示す簡略化されたフローチャートである。
【図５】サーバにおける本発明の態様を示す簡略化されたフローチャートである。
【図６】発信者側における本発明の態様を示す簡略化されたフローチャートである。
【図７】本発明による簡略化されたグラフィカルユーザインターフェースを示す図である。
【図１】
2006318019.tif 000003
【図２】
2006318019.tif 000004
【図３】
2006318019.tif 000005
【図４】
2006318019.tif 000006
【図５】
2006318019.tif 000007
【図６】
2006318019.tif 000008
【図７】
2006318019.tif 000009
【外国語明細書】
TITLE OF INVENTION      METHOD AND APPARATUS FOR CHOOSING A BEST PROGRAM FOR COMMUNICATION
TECHNICAL FIELD
[01]    The present invention relates to networked communication and in particular to selecting suitable communication program(s) for communication among networked users.
BACKGROUND OF THE INVENTION
[02]    Computer-based communications offer many forms of communication including electronic mail (hereafter email), instant messaging (hereafter IM), voice over internet protocol (hereafter VoIP), video conferencing, and so on.  Consequently, a person (the caller) who wants to initiate a call (or a communication) may have to decide from among many communication methods.  Factors that might be taken into consideration when choosing a communication method might include when the call is being made, to whom (the callee) the call is being made, where the callee is located, the technology that is available to the callee, and so on.  This decision making process can become significant in private networks such as peer-to-peer (P2P) networks.  In some situations, the caller may want to be certain that she reach the callee and may want to know ahead of time, before making the attempt, whether can be reached or not (and if not, avoid the process of attempting the call).
[03]    For example, the time of day the call is made may be important.  The callee might prefer one form of communication over another at different times of the day; the callee might prefer email in the evening time (e.g., while asleep) rather than IM.  The callee’s location may dictate the suitable communication method; e.g., the callee may prefer IM over VoIP if she happens to be having coffee at an Internet cafe where bandwidth might be limited or the quality of service is inadequate.  The callee may have specific preferences for a communication method.  The devices installed on a callee's system is also a determinative factor.  The term "communication environment" will be used herein to represent the collection of factors that are associated with the callee, and which must be given consideration by a caller in order to communicate with the callee.
[04]    Thus, the communication environment might include such things as time of day, callee's location, and callee's preference(s).  Whether the callee client system is on-line or off-line might be considered to be part of the communication environment when attempting to communicate.  Thus, in a P2P network, a user is "on-line" if she is logged onto the P2P network.  A user is "off-line" if she is logged off the network.  A user could also be considered "off-line" if he is logged on but his PC (laptop, or some other suitable communication device) has been idle for a period of time, or otherwise indicates that he is not available for communication.  The on-line/off-line state is commonly referred to as "presence."  The callee's presence information can be used to determine a suitable form of communication; e.g., if the callee is on-line then IM may be a suitable and form of communication; whereas if the callee is off-line, a cell phone call might be appropriate.
SUMMARY OF THE INVENTION
[05]    The present invention provides automated determination of a set of communication programs from which a caller can choose to communicate with a callee.  The list is determined at the callee client system, and is based on the callee's communication environment.  The list can be distributed to caller client systems using a buddy list associated with the callee.
BRIEF DESCRIPTION OF THE DRAWINGS
[06]    Aspects, advantages and novel features of the present invention will become apparent from the following description of the invention presented in conjunction with the accompanying drawings, wherein:
Fig. 1 shows an example of producing a permitted list according to an illustrative embodiment of the present invention;
Fig. 2 shows a system-level block diagram illustrating an embodiment of the present invention;
Fig. 3 illustrates distribution of the permitted list in accordance with the present invention;
Fig. 4 is a simplified flow chart highlighting aspects of the present invention at the callee side;
Fig. 5 is a simplified flow chart highlighting aspects of the present invention at the server;
Fig. 6 is a simplified flow chart highlighting aspects of the present invention at the caller side; and
Fig. 7 is a simplified graphical user interface in accordance with the present invention.
DESCRIPTION OF THE SPECIFIC EMBODIMENTS
[07]    Fig. 1 introduces the notion of a "permitted list" according to an illustrative embodiment of the present invention.  The permitted list identifies those communication programs that are available at a callee client system.  Typical examples of a client system (whether a callee client system or a caller client system) include personal computers (PC), laptop computers (laptop), personal data assistants (PDA), and other suitable devices for communication over a network.  Typical communication programs include modem programs for communication with a modem.  Network type communication programs include various instant messaging techniques, voice over IP, and so on.  Video conferencing software systems are another type of communication program.  Email clients are yet another type of communication program.
[08]    Fig. 1 shows one method for producing a Permitted List 102, shown in the figure by hatched lines.  A Client Valid List 112 is a list of communication programs that are installed on the client system device.  The Client Valid List 112 can be generated automatically.  For example, the Microsoft Windows(R) registry database can be inspected to obtain a list of communication programs installed in the system.  Alternatively, the Client Valid List 112 can be manually created by the user.  It is likely, there is only one Client Valid List 112 per device since the list represents the installed communication programs.  However, it is possible that the client system device can be configured to enable different sets of communication devices for users.  In that case, there would be multiple Client Valid Lists.
[09]    The communication methods that are available is likely to vary depending on where the client system device is located; e.g., office, home, hotel room, airport, an Internet cafe, and so on.  A Location Valid List 114 identifies the suitable communication programs for a given location which permit communication with a client system device.  For example, a network operator such as an ISP (or other network administrator) at a given site might restrict users at that site to specific application programs or a particular protocol; firewalls and proxies may permit only HTTP protocols, for instance.  There is a Location Valid List 114 for each such location.  Typically, one or more Valid Location Lists will be stored locally on the client system device.  Alternatively, predefined Location Valid Lists can be stored on a server and reused by others.  This could be convenient for lists associated with public places, such as hotels, airports, and so on.  For example, a hotel can provide a Location Valid List indicating what communication programs are appropriate for the communication services offered by the hotel.  Thus, when a user moves from the airport, say, to the hotel, the Location Valid List could change.
[10]    A User Preference List 116 identifies those communication programs that the user prefers to use for communications.  For example, the user may have preference for email and IM, even though her computer is capable of VoIP.  The User Preference List 116 can be used to further narrow the list of communication programs in the Permitted List 102.
[11]    The Permitted List 102 comprises the list of communication programs that are common to each of the foregoing three lists, namely, the Client Valid List 112, the Location Valid List 114, and the User Preference List 116.  The Permitted List is thus created by the callee, and reflects communication programs from the point of view of the callee client system, its location, and its users.
[12]    The Client Valid List 112, the Location Valid List 114, and the User Preference List 116 are represented in Fig. 1 as Venn diagrams.  The Permitted List 102 is the set that results from the intersection of the other three lists.  If that intersection results in the NULL list (i.e., there are no communication programs common to all three lists), then in accordance with a particular embodiment of the present invention, an attempt is made to produce a Permitted List 102 based on an intersection of only the Client Valid List 112 and the Location Valid List 114.
[13]    The rationale behind allowing the Permitted List 102 to be determined based only on the Client Valid List 112 and the Location Valid List 114 is that these two sets of communication programs represent a "minimum capability" required for communication with the client system device.  First, the Client Valid List 112 identifies those communication programs installed on the callee client system device, and represent the communication capability(ies) of the callee's system.  Second, the Location Valid List 114 identifies those programs which will work at that the location associated with that list.
[14]    If the Client Valid List 112 includes a modem program, then any caller client system that has a modem program can communicate with the callee, assuming that differences in baud rate can be accommodated by autobauding.  If the Client Valid List 112 includes a VoIP communication package from vendor X, then any caller client system with a VoIP communication package that is compatible with vendor X can communicate with the callee.  Similarly, if the Location Valid List 114 identifies a special IM communication program from vendor Z, then any caller with a compatible IM communication program can communicate with the callee.  If the intersection of the Client Valid List 112 and the Location Valid List 114 is NULL, then the Permitted List 102 is an empty list indicating that the callee cannot be contacted.
[15]    A couple of examples will illustrate ideas shown Fig. 1.  Suppose the Valid Client List 112 for a callee client system includes the following communication programs:
ABC-Modem-Program
XYZ-VoIP-Program
Suppose the Location Valid List 114 associated with the current location (e.g., a hotel) of the callee client system includes the following programs:
SPCL-VoIP-Program
It is assumed for this example that XYZ-VoIP-Program and SPCL-VoIP-Program are incompatible; e.g., they may use proprietary protocols.  Assume that the User Preference List 116 is empty.  Based on the above lists, the Permitted List 102 will be empty because there is no communication program that is common to both lists.  Though both lists each have a VoIP program, neither will work with the other, and so there is no common VoIP program.
[16]    In the next example, suppose the Location Valid List 114 is updated to include JK-Modem-Program, so the list includes the following:
SPCL-VoIP-Program
JK-Modem-Program
Since the vast majority of modem devices use standard communication formats and support a basic modem command set (e.g., the AT commands), it can be safely assumed that all modem programs are compatible.  Again, it is assumed that the User Preference List 116 is empty.  In this example, then, the Permitted List 102 will contain the following program identifiers:
ABC-Modem-Program
JK-Modem-Program
[17]    For the next example, assume the User Preference List 116 specifies the following communication program:
IM-Program
Assume further that the Location Valid List 114 specifies:
SPCL-VoIP-Program
JK-Modem-Program
There are no communication programs that are common among the Client Valid List 112, the Location Valid List 114, and the User Preference List 116.  Consequently, the Permitted List 102 will be determined based on the Client Valid List 112 and the Location Valid List 114, and will include the two modem programs as discussed above.
[18]    Fig. 2 shows a simple network configured in accordance with the present invention.  In a particular implementation, the network is a P2P (peer-to-peer) network.  Users on client systems 212, 214 log onto a server 202.  As indicated above, user client systems 212, 214 can connect to the network via any kind of communication device that is configured for communication on the network.  The client system includes the programs used to perform the login sequence and related tasks.  For example, the processing shown in Figs. 4 and 6, to be discussed below can be performed with suitable software.
[19]    The notion of "buddies" and "buddy lists" is well known.  Briefly, a particular relationship between two users connected to a communication network is known as a "buddy."  A buddy usually indicates a mutually authenticated relationship.  For example, an exchange of emails can take place to establish a buddy relationship.  Communication techniques such as IM and Microsoft Windows(R) Messenger use buddy lists.  A buddy list is associated with a user, and lists that user's buddy's.  Thus, a client system might have one or more buddy lists, one for each user of the client system.
[20]    When a user (User A, User B) logs onto the server 202, the user's presence changes from off-line to on-line; such presence information is typically manage by the server.  Using the buddy list, the server 202 can then notify the user's buddies of her change in presence on the network.  The buddy list can be stored on the server 202, or the buddy list can be communicated to the  server as part of the logon sequence.  The user's buddies who are logged in can then be informed of the user's presence.  Alternatively, the user's client system can perform the notification, which may include having to obtain the presence information for each buddy.
[21]    In accordance with the illustrative embodiment of the present invention, a further action that occurs when a user logs on is that the user's permitted list is distributed according to her buddy list.  Fig. 3 graphically illustrates this aspect of the invention.  Thus, when User B logs onto the server 202, its client system 214 will communicate User B's Permitted List to users who have a buddy relationship with User B; i.e., users in User B's buddy list 302.  For example, User A is on User B's buddy list, and so will receive User B's Permitted List.  Similarly if another user, User C, logs on, then User C's client system 216 will communicate her Permitted List according to her buddy list 304.
[22]    The Permitted List 102 is associated with each client system having one or more users to whom other users might call, or other establish communication.  Such a client system is referred to as a callee client system.  Conversely, client systems from which users make calls are referred to a caller client systems.  It can be appreciated of course that in most cases, a client system can be a caller client system and a callee client system.
[23]    The flowchart of Fig. 4 highlights the process flow of a client system that has a Permitted List 102 to be sent to the server 202.  At step 401, a user performs an action that initiates creating a Permitted List 102.  For example, the user might log onto the system or, having already logged on, make an update to her Client Valid List 112 and/or to her User Preference List 114.  Or, the user may move to a new location; e.g., she might take a laptop computer from the office to an Internet-equipped cafe, thus causing the Location Valid List 114 to change.
[24]    In a step 402, the Client Valid List 112, the User Preference List 114, and the Location Valid List 116 are inspected for common communication programs.  A determination is made in a step 403 whether there are any common communication programs.  If there are common programs, then a Permitted List 102 is created in as step 407 that contains the common programs.  If there are no common programs, then just the Client Valid List 112 and the Location Valid List 116 are inspected for common communication programs, in a step 404.  If in a step 405, it is determined that there are common programs, the step 407 is performed to produce a new Permitted List.  If it is determined in step 405 that there are no common programs, then an empty new Permitted List 102 is created in a step 406.  It is noted that "common" programs includes identical programs and compatible programs as discussed below.
[25]    Processing of the new Permitted List 102 proceeds with a step 408, where the new list is compared with a previously created Permitted List to determine if the previous version and the new version contain "compatible" communication programs.  It can be appreciated that for some communication methods, it is not necessary that the two versions of the list each identifies the identical program.  As noted in the above example, modem programs from different vendors may be compatible, despite being from different vendors.  Though not shown, it can be appreciated that some form of compatibility table can be used to identify compatible programs, in step 408 and in step 402 above.
[26]    If it is determined in step 408 that the new Permitted List 102 is the same as the previously created list, then processing returns to step 401 to await another triggering action.  If it is determined that the new Permitted List 102 is different from the previous list, then the new Permitted List is communicated to the Server 202.
[27]    Referring now to Fig. 5, processing of the Permitted List 102 at the server 202 will be discussed.  The processing shown in Fig. 5 begins, in a step 501, with receiving a Permitted List 102 from a client system; e.g., callee client system 214 shown in Fig. 2.  In a step 502, the buddy list associated with the client system is consulted.  The buddy list typically is stored on storage that is accessible by the server 202.  Alternatively, the buddy list can be communicated to the server by the client system along with the new Permitted List.  Those of ordinary skill can appreciate that other alternatives can be employed, as well.
[28]    A determination is made in a step 503 whether any of the buddies identified in the buddy list are on-line.  It can be appreciated, of course, that the definition of "on-line" is likely to vary from one implementation to another.  For the purpose of the present invention, it is presumed that if the client system (e.g., system 212, Fig. 2) of a buddy listed in the buddy list is on-line, it is then possible to inform that client system of the new Permitted List.
[29]    If none of the buddies are on-line, then processing simply returns to step 501 to await another new Permitted List 102 from a client system.  Otherwise, in a step 504, for each buddy that is on-line, a communication is made with that buddy's client system informing it of the new Permitted List.  Internet technology known as "push technology" can be used to achieve this.  The new Permitted List 102 can be "pushed" to the buddy's client system.  Alternatively, the buddy's client system can simply be informed of the existence of the new Permitted List, allowing the client system to obtain the information at its convenience.  Emailing can be used to communicate the new Permitted List.  Different communication methods might be used for different buddies; e.g., Buddy-1 might be informed of the new Permitted List 102 by email, while the new Permitted List 102 might be pushed to Buddy-2.  After all the buddies are handled, processing returns to step 501 to await the arrival of a another new Permitted List.
[30]    Referring now to Fig. 6, processing at a client system that is notified of the Permitted List 102 is discussed.  In a step 601, processing begins when a new Permitted List 102 is received, or otherwise communicated by the server 202.  If the server simply communicates the existence of the new Permitted List 102, then the client system will have to obtain its contents in some way from the server.
[31]    The client system maintains one or more callee lists, identifying callees with whom users at the client system can initiate a communication.  Fig. 7, for example, illustrates information contained in a callee list as it might be displayed to a user.  As can be seen, the information includes an identification of a callee and a list of communication programs associated with the callee.  Upon receiving a new Permitted List, the callee list of the callee associated with the Permitted List is updated in a step 602 to reflect the information contained in the new Permitted list.
[32]    Referring to Fig. 7 for a moment, the information contained in each callee list can be displayed to a user; e.g., via a graphical user interface (GUI).  The GUI exemplar shown in Fig. 7 displays the information that is contained in one or more callee lists in tabular format.  The list of callees that is displayed can be dependent on the user; for example, each user may have her own list of callees.  The GUI can include a Buddy field to identify each callee.  A callee button 702 can be associated with each callee.  An Available List field associated with each callee can be used to list the communication programs that are available for communicating with that callee.  The figure shows "buttons" 704 associated with each communication program.  The buttons of those communication programs that are unavailable for a given callee can be grayed out, as shown in the figure.  A user can "click" on a callee button, or on a non-grayed out communication program button to initiate communication with that callee.
[33]    Returning to Fig. 6, if a callee button press is detected in a step 603, then a determination is made in a step 604 as to whether the callee list associated with the "pressed" callee button is empty or not.  If the callee list is empty, then an appropriate message is displayed at a step 605.  If the callee list is not empty, then one of the available communication methods is selected at a step 606.  Where the callee list contains more than one communication program from which to choose, some selection criteria can be used.  For example, the callee can order the list of programs in terms of preference.  The preference information can be included in the Permitted List 102 so that the caller client system can then make a selection based on those preferences.  Alternatively, the selection can be based on predetermined criteria; e.g., use VoIP if it is available, if not then try IM, and so on.
[34]    In an alternative embodiment, the caller can click on one of the communication buttons 704.  Communication with the callee can then be initiated with the selected communication program.
[35]    In yet another embodiment, the GUI shown in Fig. 7 can be provisioned with a feature to allow the user to select more than one callee for communication; e.g., drawing a "selection box" around one or more callees in the Buddy field.  The criterion for a communication program can be a program that is common among the selected callees.  Criteria can be used in cases where there is no common program among the selected callees.
[36]    Referring back to Fig. 4, the empty Permitted List 102 can be used when a user logs out of the network.  When the server 202 detects a log out sequence, it can send an empty Permitted List to the buddies of the user that is logging off the system.  The GUI of a buddy receiving the empty Permitted List will then show all the buttons grayed out for that callee, thus indicating that the callee cannot be reached.  Instead of communicating an empty Permitted List, it might be desirable to distinguish between a callee who is on-line but cannot be reached versus a callee who has logged out.  In that case, the server can communicate some indication of a callee having logged off instead of sending an empty Permitted List.
1.      A method for communicating between a caller and a callee comprising:
communicating with a server system to perform a logon sequence at a first client system, said first client system having associated therewith a permitted list, said server system being separate from said first client system; and
communicating said permitted list from said first client system to said server system,
wherein said permitted list can be communicated from said server system to one or more second client systems,
wherein said permitted list identifies one or more communication programs that can be used to communicate with a first user on said first client system.
2.      The method of claim 1 wherein said permitted list is based at least on communication programs that are installed on said client system and which can be used at the location of said client system.
3.      The method of claim 1 wherein said one or more communication programs comprises user-selected communication programs.
4.      The method of claim 1 further comprising:
performing a logon sequence with said server system from a third client system, said third client system having associated therewith a second permitted list;
communicating said second permitted list to said server system; and
communicating said second permitted list from said server system to some of said second client systems,
wherein said second permitted list identifies one or more communication programs that can be used to communicate with said third client system.
5.      The method of claim 1 wherein said first client system further has associated therewith a buddy list, wherein said buddy list comprises said one or more second client systems.
6.      The method of claim 1 further comprising modifying said permitted list to produce a modified list and communicating said modified list to said server system, wherein said modified list can be communicated to said one or more second client systems, whereby said one or more second client systems can communicate with said first client system using a communication program selected from among communication programs in said modified list.
7.      The method of claim 1 wherein said step of producing a permitted list comprises:
obtaining first information indicative of a first plurality of communication programs that are stored in said first client system; and
obtaining second information indicative of a second plurality of communication programs, said second communication programs being based on a location of said first client system,
wherein said permitted list comprises those communication programs which are common to said first and second plurality of communication programs.
8.      The method of claim 7 wherein said step of producing a permitted list further comprises obtaining third information indicative of a third plurality of communication programs that represent a user’s predetermined list of communication programs, wherein said permitted list comprises those communication programs which are common to said first, second, and third  plurality of communication programs.
9.      A method for communicating among client systems comprising:
receiving at a first client a plurality of permitted lists from a server, wherein each permitted list is associated with a second client from among a plurality of second clients and comprises information associated with one or more communication programs;
presenting at said first client information representative of said permitted lists;
receiving at said first client a communication request identifying one or more of said second clients; and
based on said permitted lists, determining a communication program for each of said one or more second clients, and using said communication program to communicate with said one or more second clients to service said communication request.
10.     The method of claim 9 wherein each permitted list is created by a user at its associated second client.
11.     The method of claim 9 further comprising receiving one or more modified lists from one or more second clients, a modified list being produced when a second client modifies its associated permitted list to identify a different set of communication programs.
12.     The method of claim 9 wherein said first client is on a buddy list associated with every second client whose associated permitted list has been received by said first client.
13.     A networked communication system comprising:
a plurality of client systems; and
a server system in data communication with said client systems,
a first client system from among said plurality of client systems comprising program code configured to operate said first client system to perform steps of:
creating a first list of one or more communication programs that are operable on said first client system;
creating a second list of one or more communication programs that can be used at the location of said first client system;
creating a permitted list based at least on said first and second lists; and
communicating said permitted list to said server system,
a second client system from among said plurality of client systems comprising program code configured to operate said second client system to receive a permitted list from said server system, wherein communication to a client system associated with said permitted list can be made using a communication program contained therein,
said server system comprising program code configured to operate said server system to perform steps of:
receiving a permitted list from said first client system;
identifying one or more buddy client systems from a buddy list associated with said first client system; and
communicating said permitted list to one or more of said buddy client systems.
14.     The system of claim 13 wherein said step of communicating said permitted list to said server system is performed during a logon sequence.
15.     The system of claim 13 wherein said permitted list comprises communication programs common to said first list and to said second list.
16.     The system of claim 13 wherein said program code of said first client system is further configured to operate said first client system to perform a step of creating a third list of one or more user-selected communication programs, wherein said permitted list is further based on said third list.
17.     The system of claim 13 wherein said permitted list comprises communication programs common to said first list, to said second list, and to said third list.
18.     A client system in data communication with a server system and configured for communication with other client systems, said client system comprising program code configured to perform method steps of:
creating a permitted list based on communication programs that are installed in said client system and on communication programs that can be used depending on a physical location of said client system; and
communicating said permitted list to said server system,
wherein said permitted list can be communicated to first client systems from among said other client systems, so that said first client systems can communicate with said client system using communication programs identified in said permitted list.
19.     The client system of claim 18 wherein said program code is further configured to perform a method step of communicating with said server system to perform a login sequence, wherein said communicating said permitted list is performed during said login sequence.
20.     The client system of claim 18 wherein said client system has associated therewith a buddy list, wherein said buddy list comprises said first client systems.
21.     The client system of claim 18 wherein said creating a permitted list is further based on user-selected communication programs, wherein said permitted list comprises communication programs that are common to those installed in said client system, those that can be used depending on said location of said client system, and said user-selected communication programs.
ABSTRACT OF THE DISCLOSURE
Communication between a caller client system and a callee client system is based on selection of a suitable communication program from a list of communication programs.  The list of communication programs is determined based on the callee's communication environment.
REPRESENTATIVE DRAWING
Fig. 1
2006318019.tif 000010
2006318019.tif 000011
2006318019.tif 000012
2006318019.tif 000013
2006318019.tif 000014