(57)【要約】      （修正有）【課題】相互に所望のオンライン活動に参加可能な交渉機構を提供する。【解決手段】２人以上のオンライン・コンピュータ・ユーザー間での交渉が、（ａ）第１のユーザーから第２のユーザーへ、第１のユーザーが希望する特定の環境を特定する提案メッセージを発し、（ｂ）第２のユーザーから第１のユーザーへ、提案への同意、提案の少なくとも１つの特徴への不同意を示す拒絶メッセージ、又は、提案の１つ以上の特徴を変更するよう申し入れる逆提案を含む応答を発し、（ｃ）第２のユーザーが逆提案を発するならば、第１のユーザーから第２のユーザーへ、逆提案への同意を示す受け入れメッセージ、逆提案の少なくとも１つの特徴への不同意を示す拒絶メッセージ、又は、逆提案の１つ以上の特徴を変更するよう申し入れる別の逆提案を含む第２の応答を発し、（ｄ）受け入れ、拒絶又は取消しが生じるまで（ｂ）及び（ｃ）を反復することによって達成される。【選択図】図３
2009193591.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータ・ネットワークのユーザー間の対話を容易にするための、コンピュータをベースとするシステムであって、
異なるユーザーに互いに対話することを許容するソフトウエアを有する２つ以上のクライアント・コンピュータと、
前記クライアント・コンピュータのそれぞれによりサポートされた交渉プロトコルであって、提案と逆提案とのユーザー対話を可能にするように該提案及び逆提案を表すメッセージ通信を用いてユーザーにオンライン活動のパラメータを交渉することを許容する交渉プロトコルと、
を備えたシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、コンピュータ・ネットワークのユーザー間の通信管理に関する。
【背景技術】
【０００２】
インターネット及びワールド・ワイド・ウェブの急速な登場により、世界中の誰でも、パーソナル・コンピュータを通じてインターネットに接続することができるのであれば、ウェブ・サイトを介して大量の情報へのアクセスがあまねく可能であるような環境が生じている。また、電子メール（ｅメールとしても知られている）は、その利用の簡便さと低コストとによって、極めて一般的なものとなった。このような可能性が生じた理由は、様々な領域における技術的進歩の刺激による。ここでいう技術的領域には、マイクロプロセッサ（計算速度及び小型化の両方）、コンピュータのオペレーティング・システム及びインターフェース（例えば、ウィンドウズ（登録商標）、マッキントッシュ及びユニックス）並びにインターネット・ブラウザ（例えば、ネットスケープ・ナビゲータ）などが含まれる。また、技術の増大が急速であるために、生産性に対する、更には世界経済一般に対する、直接的なプラスの影響が生じている。従って、ハイテク企業が、インターネット関係の技術分野における更なる進展を作り出すことへのインセンティブが存在している。
【０００３】
オンライン・フォーラムとは、人々が各自のコンピュータ・システムの間での連続的な電子的伝送を通じて他の人間と意志疎通ができる通信の相互交換である。オンライン・フォーラムは、又は、それ以外のどのようなタイプの分散型コンピュータ・サービスでも、図１に示されているような分散型のコンピュータ・システム上に実現することができる。フォーラムの参加者（コンピュータ・サービスのユーザーに等しい）は、通常、広い地理的領域に散らばっており、それぞれのクライアント・システム１０２（例えば、パーソナル又はラップトップ・コンピュータ）を通じて、１又は複数の中央サーバ・システム１００と通信を行う。実際には、サーバ・システム１００は、通常、単一の一体的な存在ではなく、相互に接続されたサーバ・コンピュータのネットワークである。これらのサーバ・コンピュータは、おそらくは物理的に相互に分散し、それぞれがそれ自体のいくつかの任務及び／又は特定の地理的領域を担当している。そのような場合に、個々のサーバは、通信リンクのネットワークによって既知の態様で相互に接続されている。そのようなサーバ・システムの１つに、米国バージニア州所在のアメリカ・オンライン社による「アメリカ・オンライン」がある（ＡＯＬ）。
【０００４】
各クライアント・システム１０２は、サーバ・システム１００上で動作している対応のソフトウェアと意味のある態様で通信することを可能にするクライアント・ソフトウェアを動作させる。クライアント・システム１０２は、トランスファ・コントロール・プロトコル／インターネット・プロトコル（ＴＣＰ／ＩＰ）などの転送プロトコルを用い、電話回線１０６に接続されたモデム１０４や直接的なインターネット接続など、様々なチャネルを通じてサーバ・システム１００と通信する。サーバ・システム１００は、クライアント・システム１０２からの入力を受け取り、入力情報（そしておそらくは他のソースからの情報）の集合体を有用なフォーマットに操作し、フォーマットのなされた情報をディスプレイ・スクリーンなどの出力装置に提供するために１又は複数のクライアント１０２に再伝送する、という役割を有している。
【０００５】
インターネット「文化」に特有の側面として、「チャット・ルーム」現象がある。チャット・ルームとは、ある特有の通信活動が継続されている仮想的な空間（すなわち、電子的なチャネル）を指す。ある場合には、この活動は、コンピュータ・ゲームなどのアプリケーションである。また、それ以外の多くの場合には、この活動は、参加者の間での単純な会話又は「チャット・セッション」である。図２を参照すると、チャット・ルーム２００が図解されており、そこでは、様々な参加者２０４（例えば、アレンズ９（Allens9）や、ジョシュアアレックス（JOSHUAALEX）など）がテキストを入力することができ、入力されたテキストは、各参加者のコンピュータのディスプレイ・スクリーン上に示されているスクロール式のテキスト・ウィンドウ２０２に現れる。図２の例では、チャット・ルーム２００には２２人の参加者がおり、参加者たちのＩＤ（又は、「スクリーン・ネーム」）がスクロール式ウィンドウ２１０にリスト化されている。参加者２０４は、編集ボックス２０６の中にある長さのテキストを入力し、送信（SEND）ボタン２０８を付勢する（例えば、マウスなどのポインタ装置を用いてクリックする）ことによって、他の参加者２０４のコメントに応えることができる。そうすると、スクロール式テキスト・ウィンドウ２０２にあるテキストが上方向にスクロールし、新たに入力されたテキストのラインがスクロール式テキスト・ウィンドウ２０２の底部に表示される。この図解されている例では、コメントを入力した最終の参加者はジョシュアアレックスであり、彼は「テキサス（TEXAS）」と入力している。
【０００６】
図２に示されているチャット・ルーム２００は「公的」なものである。公的というのは、このチャット・ルームが、アクセスしているオンライン・サービスのどのユーザーにも広く開かれていることを意味する。そして、通常は、コンピュータ・サービス・プロバイダによってこのチャット・ルームに配置され、おそらくはそれまでお互いに会ったことも話したこともなかった複数の人間が参加している。公的フォーラムの参加者によるコメントは、チャット・ルームのすべての参加者に送られる。ある参加者が何らかのプライバシを望む場合には、その参加者は、「私的（プライベート）な」チャット・ルームを開いてそこに入ることができ（例えば、「プライベート・ルーム」ボタン２１２をクリックすることによって）、そうした後で、そのプライベート・チャット・ルームに自分以外の１人又は複数人の参加者を招待することができる。そうすると、このプライベート・チャット・ルームには、それを作った人間と招かれた者だけが排他的にアクセスすることができるようになる。いったんプライベート・フォーラムに入れば、参加者たちは、招かれていない参加者に自分たちのコメントを見られてしまうことをおそれることなく、相互に通信することができる。また、半私的（セミ・パブリック）なチャット・ルームを設け、特定のユーザーからなるグループにだけオープンとすることも可能である。
【０００７】
ＡＯＬは、ＡＯＬインスタント・メッセンジャ（ＡＩＭＴＭ）システムを作成している。このＡＩＭシステムによると、ユーザーは、「バディ・リスト」（Buddy ListTM、仲間リスト）として知られている電子メッセージング媒体を作成することが可能になる。このバディ・リストは、ユーザーがオンラインで対話することが多い人間によって構成され、ユーザーは、リスト内のユーザーにインスタント・メッセージ（ＩＭ）を送ることができる。ＡＩＭシステムは、あるユーザーのバディ・リストのメンバーがオンラインとなると、そのユーザーに自動的に知らせる。従って、これら２人のバディ（仲間）は、直接に通信（例えば、チャット）することができる。というのは、この２人は共にオンラインであり互いの存在を知らされているからである。
【０００８】
この分野におけるＡＯＬの開発物には、これ以外に、「悪意」のコンセプトがある。このコンセプトは、ユーザーが、直ちに他人と通信を行い大量の情報を送ることができるために、自分たちに与えられている特権を濫用するおそれがあり実際にも濫用しているという事実を認識することから生まれたものである。このような濫用は、例えば、あるユーザーが、不快なコンテンツを含むメッセージを送ったり、あまりに多くのメッセージを他のユーザーに送付することによりＡＩＭシステムを過渡に使用したりするときに、生じうる。これ以外の濫用形態が、ユーザーが大量のデータを含むファイルを他のユーザーに送るときに生じることがある。そのような場合には、受け手側がファイルを開く若しくはダウンロードしようとすると、又は、他の活動を行おうとすると、受信ファイルの処理のために、受け手側のコンピュータ・システムの動作速度が減速されてしまうのである。
【０００９】
悪意というコンセプトをＡＯＬが作り出したのは、上述の及びそれ以外のタイプの濫用からの救済を試みようとしたためである。あるユーザーが、別のユーザーがよくない振る舞いをしている（例えば、望まれていないＩＭを何度も送るなど）のを知ると、この感情を害された側のユーザーは、よくない振る舞いをしているユーザーに対して悪意を付与する（evil）すなわち警告を行うことにより、よくない振る舞いをしているユーザーの悪意のレベルを増加させることができる。ユーザーに対して悪意を付与することの効果は、小さいのであるが、累積的であるのが通常である。ある時間経過の間に、あるユーザーに対して一定回数の悪意が付与されると、そのユーザーがシステム・リソースを使用する（例えば、ＩＭを送る）能力は、罰として、徐々に減速される。それでも濫用が継続し更に多くの悪意が付与される場合には、結果的に、その濫用者を、コンピュータ・ネットワークから意に反してログオフさせることができる。この背後にある考えは、オンライン（そして特に、チャット・ルーム）環境におけるコンピュータ・エチケットと基本的な礼儀とを促進させようとすることにある。ユーザー相互に「悪意を付与する」権限をもたせることは、ユーザーが、自己治安維持型（self-policing）社会を作り出すことを可能にし、従って、インターネット・サービス・プロバイダ（ＩＳＰ）が治安維持機能を実行することを不要とする。悪意付与技術に関するこれ以上の詳細は、１９９８年５月１３日に出願された"Regulating Users of Online Forums"と題する米国特許出願第０９／０７６，４８３号と、１９９８年５月１３日に出願された"Self-Policing, Rate Limiting Online Forums"と題する米国特許出願第０９／０７６，４８４号とにおいて見ることができる。これらの米国特許出願は、本出願において援用する。
【００１０】
チャット・ルームを任意の主題に関する完全に自由な形式の対話に開かれたものにすることは可能ではある。しかし、チャット・ルームは、議論が特定の主題に関係するものとなるように構成するのが一般的である。チャット・ルーム現象が急増したことで、ユーザーのニーズを満足させるようにチャット・ルームの環境を最適に構成する機構に対する必要性が生じている。例えば、あるユーザーが、他の３人のユーザーで構成される特定のグループと特定の主題に関して私的な会話をもちたいと希望することがあるだろう。あるいは、そのユーザーが、別のリモート・サイトにいる２人の友人と一緒に特定のコンピュータ・ゲームをしたいこともあるだろう。現時点では、ユーザーは、そのような活動に関わりたいと思った場合には、１）希望する活動が行われている既存のチャット・ルームを見つけ、そのチャット・ルームに参加することを試みるか、２）その活動に一緒に関わりたいと思っている他のユーザーにＩＭ又はｅメール・メッセージを送り、参加を呼びかけるか、のいずれかが可能である。通常は、参加を呼びかけている側のユーザーは、応答を全く受け取らない（例えば、受け手が呼びかけを無視する場合）か、又は、その呼びかけに対するバイナリ形式の応答（すなわち、イエス又はノー）を受け取ることになる。
【発明の概要】
【発明が解決しようとする課題】
【００１１】
以上に鑑み、われわれ発明者たちは、強力かつ柔軟性のあるネゴシエーション機構であって、それによれば、相互に通信する又はそれ以外の相互作用をすることを希望するユーザーが相互に「取引（バーゲン）」を行い、最終的には相互に承認可能な通信（例えば、チャット・ルーム）やそれ以外の相互作用（例えば、複数ユーザーによるコンピュータ・ゲーム）のコンテキストに関して合意することができるようなネゴシエーション機構が必要とされていることを認識した。
【課題を解決するための手段】
【００１２】
実施は、下記の特徴の種々の組み合わせを含む。
「ランデブー」プロトコルと呼ばれるプロトコルが、他のユーザーの活動のために第１のユーザーの提案を送信することにより、コンピュータ・ネットワークのユーザー間の相互作用を容易にするよう設計される。提案は、提案された活動を表す１つ以上のパラメータを含む。他のユーザーからの、受け入れ、拒絶又は逆提案のような応答が受け取られる。受け取られた応答に依存して、ユーザーは提案された活動に選択的に参加する又は参加しない。
【００１３】
こうした活動の一つは、オンライン「チャット」セッションであり、チャットのための提案に対する典型的なパラメータの組は、チャット・セッションが注目する提案されたトピックと、チャット・セッションが行われる提案されたチャネルとを含む。他の典型的な活動はオンライン・コンピュータ・ゲームであり、その特定のパラメータは、ゲームにおける提案された参加者を識別することができる。
【００１４】
受け入れは、提案の全パラメータへの同意を示す。拒絶は、提案の少なくとも一つのパラメータへの不同意を示す。逆提案は、提案パラメータの１つ以上を修正するための申し出である。逆提案がなされると、逆提案に対する更なる応答をすることができ、この応答も受け入れ、拒絶又は更なる逆提案であり得る。このシーケンスは受け入れ又は拒絶が生じるまで際限なく生じる。
【００１５】
提案又は逆提案の取り消しは、該取り消しが応答の受信の前に生じない限り、提案又は逆提案を最初にしたユーザーによって発せられる。典型的には、こうした取り消しはその理由を含むべきである。
【００１６】
拒絶を発する際、ユーザーは、提案が（不活動により）明示的に又は暗示的に無視されていることを示す。
プロトコルにより、ユーザーは、「悪意」メッセージと呼ばれるメッセージ、提案に対する文書による不快、逆提案又は受け入れを送出することができる。悪意メッセージはコンピュータ・システムのリソースに対してアクセスする受信者の能力に対する累積的な（及び、潜在的には指数的な）影響を有する。
【００１７】
プロトコルの一つの目的は、同意に達するまで活動のパラメータを交渉することができるようにすることで、オンライン・コンピュータ・ユーザーが活動のための最適な環境を作ることを援助する。典型的な活動は、ボイス・メッセージの交換、オンライン・ゲームの実行、１つのクライアント・コンピュータから他のクライアント・コンピュータへのルートの発見、ファイルの転送、ダイレクト・インスタント・メッセージング、アバターの交換、チャット・ルームへの参加、又は、共同プロジェクト開発への関与を含む。
【００１８】
ランデブー・プロトコルを利用することができる他の潜在的なオンライン活動は、ｅコマースである。そのプロトコルは商品又はサービス或いは無形資産の販売／購入の交渉である。こうした交渉のパラメータは、典型的には、値段、モデル、スタイル、色、配達の詳細及び保証の詳細を含む。
【００１９】
拒絶メッセージは、拒絶の理由を示し得る。典型的な理由は、以下のとおりである。すなわち、提案された活動は提案の受信者と関連するクライアント・コンピュータによってサポートされていない。提案された活動は提案の受信者によって否定された。提案の受信者は提案を明らかに無視した。提案はタイムアウトになった。又は、提案メッセージは理解し得ない。
【００２０】
一つの実施の形態においては、ランデブー・プロトコルは、コンピュータ・ソフトウェア・アプリケーション内に存在し得るコンピュータ・ソフトウェアとして実現され得る。プロトコル・ソフトウェアは、コンピュータ読み取り可能な媒体又は伝搬する搬送信号において現実的に実施される。プロトコル・ソフトウェアは、コンピュータ・システムにオンライン交渉セッションを行わせる命令を含む。
【００２１】
本明細書で記述する技術及び機構は、一つ以上の下記の利点をもたらす。ランデブー・プロトコルは、対話型オンライン環境（チャット・セッション、オンライン・ゲーム等）の特徴を交渉する能力をユーザーに与える。その結果、ユーザーは、全参加者に対して相互に同意することができるよう、オンライン環境を調整し最適化することができる。典型的には、この最適化は、環境が交渉を開始する前に生じる。したがって、ユーザーは、不要又は不所望の事態や参加者に出会うことなく、しかもユーザーの希望に沿って、選択し合意する環境に参加することができる。
【００２２】
追加の特徴及び利点は、図面及び請求項を含む以下の記述から明らかになるであろう。
【図面の簡単な説明】
【００２３】
【図１】オンライン・コンピュータ・サービスを提供するために用いられる形式の従来の分散型コンピュータ・システムを示す図である。
【図２】従来のオンライン・コンピュータ・チャット・ルーム・フォーラムの例を示すスクリーンである。
【図３】交渉プロセスのプロトコルを示すフローチャートである。
【図４】状態遷移値のテーブルである。
【図５】交渉プロトコル・メッセージのデータ・フォーマットを示す図である。
【図６】交渉プロトコルにおけるデータ・フィールドに対するデータ値のテーブルである。
【図７】交渉プロトコル・メッセージ内のＴＬＶフィールドのパラメータのテーブルである。
【図８】クライアント・エラー・メッセージのデータ・フォーマットを示す図である。
【図９】クライアント・エラー・コードのデータ・フィールドに対するデータ値のテーブルである。
【図１０】提案を発するオンライン・コンピュータ・ユーザーに対してチャット提案メッセージがどう現れるかの例を示すスクリーン・ショットである。
【図１１】提案を受け取るオンライン・コンピュータ・ユーザーに対してチャット提案メッセージがどう現れるかの例を示すスクリーン・ショットである。
【図１２】提案を拒絶するオンライン・コンピュータ・ユーザーに対してチャット提案メッセージがどう現れるかの例を示すスクリーン・ショットである。
【図１３】拒絶されている提案を発したオンライン・コンピュータ・ユーザーに対してクライアント・エラー（拒絶）メッセージがどう現れるかの例を示すスクリーン・ショットである。
【図１４】提案を受け取るオンライン・コンピュータ・ユーザーに対してファイル転送提案メッセージがどう現れるかの例を示すスクリーン・ショットである。
【図１５】提案を発するオンライン・コンピュータ・ユーザーに対してダイレクト・プレイ（コンピュータ・ゲーム）提案メッセージがどう現れるかの例を示す。
【図１６】元の提案を受け取り且つ逆提案に応答するオンライン・コンピュータ・ユーザーに対してダイレクト・プレイ逆提案メッセージがどう現れるかの例を示す。
【００２４】
なお、種々の図面における同じ参照番号及び指示は同様の要素を指す。
【発明を実施するための形態】
【００２５】
本発明者は、２人以上のコンピュータ・ユーザー間で交渉して相互の有益な通信又は多ユーザー対話環境を整える機構である（「ランデブー」プロトコルと呼ばれる。）交渉プロトコルを開発した。ランデブー・プロトコルの一つの実施はＡＯＬインスタント・メッセンジャ（ＡＩＭ）システムにあり、そのシステムはコンピュータ・ネットワークのユーザーがインスタント・メッセージ（ＩＭ）を交換する、又は「チャット」セッションに参加するのを可能にし、更にユーザーに、ユーザーの仲間が直接の会話を容易にするためオンライン状態にあるときを知らせる。ランデブー・プロトコルは、ソフトウエア開発者がソフトウエア・アプリケーションにおいて様々なユーザー交渉機能を実現するため用いる汎用フレームワークを提供する。ＡＩＭシステムはユーザーがチャットし、ＩＭを送りまた送り返し、ファイルを転送するのを可能にするのであるが、そのＡＩＭシステムはランデブー・プロトコルの１つの特定のアプリケーションを代表する。一般的に、ランデブー・プロトコルは通常標準ＴＣＰ／ＩＰプロトコル内で動作するが、しかしＴＣＰ／ＩＰプロトコル以外のいずれの適切なプロトコルを代わりに用いてもよい。この点に関しては、信頼できる接続を促進するプロトコルが好ましい。
【００２６】
ランデブー・プロトコルは、柔軟性に富むボディを別のユーザーとチャットするかさもなければ対話するイベントに加える。それは、ユーザーが例えばある一定のプレーヤとコンピュータ・ゲームをプレイする又は特定の話題を私的なチャット・ルームで話し合う特定の環境で特定の活動に参加するのを望み得ることを認める。ランデブーは、「蚤の市型」の交渉を対話環境のパラメータを交渉するためのモデルとして用いる。とりわけ、ユーザーが制御するのを望み得るパラメータの種類には、他の参加者の数及びそれら参加者の身元が含まれる。例えば、多分ユーザーは、オンライン状態の間であるが３人の特定の個人とのみブリッジをプレイするのを楽しみ、又は多分ユーザーは、新しいオンライン・ゲームについて他のコンピュータ・ゲーム熱狂者と通信するのを欲する。ランデブー・プロトコルは、ユーザーがそのようなパラメータの影響を受けている通信セッションを提案するのを可能にする。更に、ランデブーは、そのような提案の受信者がその提案を受諾又は拒絶するばかりでなく、提案されたパラメータの１つ以上のものを修正する代案で応答するのを可能にする。
【００２７】
ランデブー・プロトコルは、ＡＩＭシステムの基礎構造として働く。ＡＩＭシステムにおける仲間間の基本メッセージは、クライアント間基本メッセージ、略してＩＣＢＭと呼ばれる。ＩＣＢＭは「ペイロード」を含むと言われ、その「ペイロード」はＩＣＢＭの情報内容を保持する。インスタント・メッセージ（ＩＭ）は実際上直ちに受信者に対して表示される電子メール・メッセージに似ているが、そのインスタント・メッセージ（ＩＭ）はＩＣＢＭペイロードの一例である。一般的に、ランデブー・ベースのメッセージは、ＩＣＢＭペイロードの別の例である。（以下に説明されるランデブー・メッセージの１つのタイプ、即ちクライアント・エラー・メッセージがあり、それがＩＣＢＭではないことに注目されたい。）
前述したように、ＡＩＭシステムの１つの特徴は、別のユーザーに「悪意を付与」する能力である。第１のユーザーに悪影響を与えた他のユーザーにより取られた行動によりユーザーが悩まされた場合に、ユーザーは、その他のユーザーに対して悪意を付与する能力を用いるかも知れない。例えば、第１のユーが一連のＩＭを仲間（第２のユーザー）に送るが、しかし第３のメッセージ後に、仲間は、第１のユーザーがこれら全ての退屈なメッセージで第２のユーザーを悩ますのを止めるよう要求するメッセージを送り返すと仮定する。これにも拘わらず、第１のユーザーはメッセージを送り続ける。第２のユーザーは困るようになり、発信者に悪意を付与する又は警告しようと決心する。悪意を一般的に任意のＩＣＢＭ上で用いることができる。（クライアント・エラー・メッセージはＩＣＢＭではないので、それは、以下に説明される理由のため悪意を付与されることができないことに注目されたい。）
ランデブー・プロトコル・プロセスを用いてパラメータを交渉するプロセスが、図３のフローチャートにより示されている。１人以上の他のユーザーと対話するのを欲して、例えば特定のチャット・ルーム環境をセットアップするユーザー（「発信者」と呼ぶ。）は、「提案」メッセージを仲間に送ることによりランデブー・セッションを始める（ステップ３０１）。その「提案」メッセージは、希望する対話、この例では、指定されたチャット・ルーム環境（例えば、題目、参加者等）に対する発信者の提案を含む。
【００２８】
提案メッセージを送った後の任意の時間（しかし、交渉プロセスが受信者による受け入れ又はタイムアウトのようなある他のイベントの結果として終わる前）に、発信者がその提案を取り消すのを希望する場合、これは、取消しメッセージを送ることにより達成される（ステップ３０３）。取消しメッセージにより、発信者は取消のための理由を提供することができる。３つの有効な種類の取消し理由は、「不明」、「ユーザー要求」及び「タイムアウト」を含む。正常な取消し、即ち発信者の考えが変わり、発信者が対話に参加するのを欲しない状態は、取消し理由を「ユーザー要求」と指定することにより指示される。「タイムアウト」は、受信者が提案に対して適時に応答することをしそこない、そして発信者が応答を待つのを諦め、従ってその提案を表から取り外したとき、取消し理由として与えられる。取消しメッセージのための理由が知られていない場合、取消し理由フィールドは「不明」を指示する。
【００２９】
元の提案が取り消されなかったと仮定すると、提案の受信者は、その提案に対して幾つかの異なる方法で応答し得る（ステップ３０５）。受信者が応答し得る１つの方法は、受け入れメッセージを送ることにより提案どおりに正確にその提案を受け入れる仕方である。これは、ランデブー・セッションを成功裏に終わらせ、そして提案の発信者及び提案の受信者が希望する対話（例えば、チャット・ルーム）活動に参加するのを可能にする。上記の実行に対して、ランデブー・セッションが成功裏に終わることができる（即ち、関係者がランデブー・セッションを介して同意されたオンライン活動に参加する）唯一の方法は、受け入れメッセージによるものである。
【００３０】
しかし、アプリケーション開発者の目的によっては、ランデブー・プロトコルを使用して、他の状態（例えば、ある環境において、提案を拒否する受信者の失敗）が終了（ターミネーション）に成功する結果となるようにすることができる。
【００３１】
受信者が応答するための別の方法は、クライアント・エラー・メッセージを送出することによって、提案を拒否することである（ステップ３０９）。クライアント・エラー・メッセージは、発信者に拒否の理由を通知するフィールドを有している。可能性のある理由として、次のようなものが含まれる。
【００３２】
１）サポートされていない提案（例えば、受信者のコンピュータが対応できるように構成されていない）
２）否定された提案
３）無視された提案
４）タイムアウトになった提案
５）破綻したパラメータ
６）オンラインであるが利用不可／ビジー。
【００３３】
「サポートされていない提案」は、受信者のコンピュータが申込みを受けたインタラクションに従事するよう適切に構成されていないときは、適正な理由となる。「否定された提案」は、提案受信者がインタラクションへの従事を望まないことを示す、提案の明確な拒絶である。「無視された提案」は、受信者が提案を無視することを積極的に選択したことを示すものである。「タイムアウトになった提案」は、ある長さの時間内に受信者が応答するのに失敗したことを示すものである。「破綻したパラメータ」は提案メッセージ自体が理解できない、例えば、提案メッセージが送信中に混乱し、その結果受信者のコンピュータが読み取れないことを表す。「オンラインであるが利用不可／ビジー」は、受信者がその時点では他の作業で非常にビジーであり、そうでなければ関心があるとき、適正な応答となる。例えば、受信者が仕事または学校のためのプロジェクトに対するリサーチを行っていてオンラインにあるとき、仲間の一人がオンライン・コンピュータ・ゲームをすることを提案するような場合、受信者は、多分「オンラインであるが利用不可／ビジー」という理由を明示するクライアント・エラー・メッセージで応答することになるであろう。受信者は、このことを、受信した各提案に対し「ビジー」メッセージを用いて自動的に応答するソフトウェア・スイッチを設定することによって行うことが可能である。
【００３４】
このような実装において、クライアント・エラー・メッセージは、悪意とならないランデブー・メッセージの唯一の型式である。他の全てのランデブー・メッセージ型式は、悪意となることになる。この設計の決定の理由は、ユーザが幾つかのインタラクションへの従事を単に拒否したという理由で「悪意」とすることは、「悪意」の目的にかなうことにならず、目的はユーザにコンピュータ・リソースの濫用に対して警告することである。しかし、ランデブー・プロトコルを実装して、１つまたは複数の利用不可なメッセージを、実装者の目的によって、悪意またはそうではないようにすることは可能である。
【００３５】
受信者による別の可能性のある応答は、発信者に対して提案メッセージを送り返すことによって、提案を修正することである（ステップ３１１）。このメッセージには、受信者による逆提案が含まれる。これが、両当事者が結果として生じるチャット・ルームまたは他のインタラクション（例えば、１対１ゲーム）環境の詳細について交渉する基本的手段である。例えば、ユーザーＡが、ユーザーＢとエキスパート・レベルでブリッジのオンライン・コンピュータ・ゲームをすることを望むと仮定する。しかし、ユーザーＢは、エキスパート・レベルよりは中間レベルを望み、代わりに中間レベルでゲームをすることを提案する逆提案をユーザーＡに送る。第２の例として、ユーザーＸとユーザーＹが一緒にリサーチ・プロジェクトに関係するものと仮定し、彼らはチャット・ルームに入ることを望み、そこで彼らのトピックについてしばしば議論するものとする。ユーザーＸは、ユーザーＹに彼らが以前に入ったことのある特定のチャット・ルームで会うことを提案する。しかし、ユーザーＹはより良い情報を提供してくれる可能性のある別のチャット・ルームのことを聞いて、ユーザーＹは、代わりに新しいチャット・ルームで会う逆提案をユーザーＸに送る。
【００３６】
一旦逆提案が送られると、逆提案の受信者は、元の提案を受信した元の提案の受信者が有していたものと同じオプション（受け入れ、クライアント・エラー・メッセージによる拒否、または提案メッセージによる別の逆提案を送信）を有する。即ち、逆提案は新たな提案として有効に取り扱われる。逆提案の送信者は、元の提案者が元の提案を取り消すオプションを有していたと同じく、取消しメッセージにより逆提案を取り消すオプションを有している。このようにして、ランデブー・セッションは、ユーザーのどちらもあるオンライン活動で同意するか、一方がクライアント・エラー・メッセージによりセッションを終了することを決定するまで、議論を継続する。
【００３７】
ランデブー・プロトコルの代表例を、図４のランデブー状態遷移表に示す。状態遷移表は、ランデブー・セッションの可能性のある３つの状態を挙げている。状態１は提案発信者のものであり、状態２は提案受信者のものであり、状態３は終了状態で、そこでランデブー・セッションは終了する。一旦提案が送信されると、それによってランデブー・セッションが開始され、提案発信者は状態１に入り、提案受信者は状態２に入る。
【００３８】
状態１において、５つの可能なイベントの１つが発生し、これらは、状態１内で５つのサブ状態によって示される。受け入れメッセージが受け取られると（即ち、サブ状態１．１）、ランデブー交渉が成功であり、ユーザーは、サブ状態３．１に行き、そこで、ランデブー・セッションが終了し、且つオンライン同意活動が開始する。クライアント・エラー・メッセージが受け取られると（即ち、サブ状態１．２）、ランデブー交渉が不成功であり、ユーザーはサブ状態３．２に行き、そこで、ランデブー・セッションが終了し、且つユーザーは、彼らのやりとりを停止する。逆提案が受け取られると（即ち、サブ状態１．３）、ユーザーは、その逆提案に関して提案受信者になり、状態２に入る。タイム・アウト（サブ状態１．４）が生じるか、或いは、取消しメッセージが送られる（サブ状態１．５）と、交渉セッションは、サブ状態３．３に行くことによって取消され、そこで、ランデブー・セッションが終了し、且つユーザーは、彼らのやりとりを停止する。
【００３９】
状態２において、４つの可能なイベントが生じ、これらは、一般に状態１にリストされる５つの可能なイベントに対応する（状態２における第４のイベント（即ち、サブ状態２．４）は、状態１における第４のイベント（即ち、サブ状態１．４）或いは第５のイベント（即ち、サブ状態１．５）に対応する）。提案受信者として、状態２におけるユーザーは、受け入れメッセージ（サブ状態２．１）、クライアント・エラー・メッセージ（サブ状態２．２）、逆提案（サブ状態２．３）のいずれかを送ることができる。第４の可能性は、取消しメッセージ（サブ状態２．４）の受け取りである。受け入れメッセージが送られると、ランデブー交渉が成功であり、ユーザーは、サブ状態３．１に行き、そこで、ランデブー・セッションが終了し、且つオンライン同意活動が開始する。クライアント・エラー・メッセージが送られると、ランデブー交渉が不成功であり、ユーザーは、サブ状態３．２に行き、そこで、ランデブー・セッションが終了し、且つユーザーは、彼らのやりとりを停止する。逆提案が送られると、ユーザーは、提案発信者になり、状態１に入る。取消しメッセージが受け取られると、交渉セッションは、サブ状態３．３に行くことによって取消され、そこで、ランデブー・セッションが終了し、且つユーザーは、彼らのやりとりを停止する。
【００４０】
状態３において、ランデブー・セッションが３つの方法の１つで終了する。成功である交渉、サブ状態３．１は、受け入れメッセージが提案メッセージに応答して送られるときに発生する。この場合に、二人のユーザーは、オンライン同意のやりとりに従事している。不成功である交渉、サブ状態３．２は、クライアント・エラー・メッセージが提案メッセージに応答して送られるときに発生する。この場合に、ランデブー・セッションに巻き込まれたユーザーは、彼らのやりとりを停止する。取消された交渉、サブ状態３．３は、提案メッセージが送られた後であるが応答を受け取る前に、取消しメッセージが送られるときに発生する。この場合に、ランデブー・セッションに関係するユーザーは、彼らのやりとりを停止する。状態３内の３つの全ての場合において、ランデブー・セッションは、その特定のランデブー・セッションの一意の識別子であるランデブー「クッキー」の使用停止によって示される様に、終了される。
【００４１】
ランデブー・メッセージ（クライアント・エラー・メッセージを除く）の構成およびフォーマットを示す図が、図５に示されている（クライアント・エラー・メッセージは、ＩＣＢＭではないので、それは、以下に示されたそれ自体のフォーマットを有する。）。ランデブー・メッセージはＩＣＢＭペイロードであるので、また全てのＩＣＢＭは、標準ＴＣＰ／ＩＰプロトコルを使用しているので、ランデブー・メッセージ（クライアント・エラー・メッセージ以外）における最初の２つのフィールド５０１および５０３は、ＴＣＰ／ＩＰヘッダーであり、且つＩＣＢＭヘッダーである。ＩＣＢＭヘッダーは、ランデブー・メッセージであるようなメッセージを識別する。次のフィールド５０５は、ランデブー・メッセージ・タイプを規定し、２バイト長を有する。有効メッセージ・タイプは、提案、取消し、受け入れを含む。図５に示されたフィールドに対する有効データ値は、図６に与えられている。ここに示されたように、メッセージ・タイプのフィールドは、提案メッセージに対して０、取消しメッセージに対して１、或いは受け入れメッセージに対して２を含むことができる。
【００４２】
図５を再び参照すると、ランデブー・メッセージにおける次のフィールド５０７は、８バイト長であり、「クッキー」と呼ばれる。「クッキー」は、特定のランデブー交渉セッションに対する一意の識別子として働く。従って、同じランデブー・セッションの一部である全てのＩＣＢＭは同じ「クッキー」を有するが、新たなランデブー・セッションは、新たな「クッキー」を有する。次のフィールド５０９は、ＵＵＩＤ（ユニバーサルな一意の識別子）と呼ばれる、６４バイトのフィールドである。このフィールドは、所望のサービス・タイプを特定する。
【００４３】
図６を再び参照すると、ランデブー・プロトコルでアクセス可能な７つの標準タイプのサービスがある。即ち、「ＡＯＬトーク」、「ダイレクト・プレー」、「ファイル転送」、「ルート・ファインダ」、「ダイレクトＩＣＢＭ」、「アバター交換」、および「チャット」である。これらのサービスのいくつかは、ＡＯＬインスタント・メッセンジャ，バージョン２．０で利用可能である。（ＵＵＩＤの最初の１２のキャラクタのみが図６に示されていることに留意されたい。与えられた７つの全てのＵＵＩＤに対して、最後の２０のキャラクタは、１１Ｄ１−８２２２−４４４５５３５４００００  である。）  「ＡＯＬトーク」は、ユーザーがオーディオ・メッセージを相互に交換可能なＡＯＬ互換音声システムを引用する。「ダイレクト・プレー」は、オンライン・コンピュータ・ゲームをプレーすることを引用する。「ファイル転送」は、ドキュメント、スプレッドシート、或いは絵またはグラフィック・データ・ファイルのような、コンピュータ・ファイルを、一方のユーザーから別のユーザーに転送可能にする。「ルート・ファインダ」は、「ファイアウォール」が所望のアプリケーションへのダイレクト・ルートをブロックしている状況（例えば、ユーザーが職場でオンラインの状態である場合に、ファイアウォール、すなわち、指定したネットワーク・トラフィックをブロックするソフトウエア・エージェントを設定することは、雇い主にとって普通である）において、ユーザーが別のアプリケーションに対するインターネット・ルートを見い出すのを可能にする。「ダイレクトＩＣＢＭ」（即ち、発信者と受信者のクライアント・コンピュータの間のダイレクトＴＣＰ／ＩＰ接続を介してＩＣＢＭを送ること）は、ユーザーがＡＩＭシステムに対する主サーバーを通す必要なしにＩＭを相互に直接的に交換することを可能にし、より高い速度の処理とより高いプライバシーを与える。ダイレクトＩＣＢＭの処理能力によって、ユーザーに「悪意な処理を使用する能力を失わせるということ、またそれが、主ＡＩＭサーバーによって通常与えられるコンピュータ・ハッカーに対するプロテクションも除去するということに留意されたい。ダイレクトＩＣＢＭの処理能力はまた、ファイアウォールを貫通する問題を経験し得る。「アバター交換」は、ユーザーがスクリーン上のユーザーの個性を典型的に示すイメージを交換することを可能にする。「アバター」は、このイメージに対する用語であり、それは、漫画、線描、或いは写真のような、任意の図形描写であり得る。「チャット」は、チャット・ルームでの典型的なオンラインの対話を引用し、これは、メッセージをタイピングし、それらをあちこちに送ることによって典型的に実行される。
【００４４】
ランデブー・プロトコルは、上記した７つの標準サービス・タイプに限定されるものではない。可能な複数の手段として、例えば、ユーザーが特定目的のユーザー・インターフェースにアクセスして、これら自体のＵＵＩＤ及び対応するアプリケーションを生成することができるようにしたものが含まれる。
【００４５】
図５を再度参照する。次のフィールド５１１は、オーダーされた３個、すなわち、「タイプ(Type)」、「長さ（Length）」、「値（Value）」を１組としたものであり、したがって、このフィールドは、「ＴＬＶ」フィールドと称せられる。ＴＬＶフィールドは、１５個迄の確保されたパラメータに、アプリケーション特定パラメータを加えたものである。図７は、タイプ・フィールドにおける１５の潜在的な確保されたパラメータ、及びそれらの対応する番号を示しており、ＴＬＶフィールドは、ランデブー・プロセスにおいて特別に交渉されている情報を含んでいる。ＴＬＶフィールドにおける第１のパラメータは、「ＩＣＢＭチャネル」であり、すなわち「ランデブー・チャネル」に等価である。このパラメータは、オンライン・ゲーム又はチャット等の、要求されているＩＣＢＭの種類を識別する。
【００４６】
ＴＬＶフィールドにおける次の３つのパラメータは、「ランデブーＩＰアドレス」、「提案者ＩＰアドレス」、及び「認証ＩＰアドレス」と称される。ＩＰアドレスすなわちインターネット・プロトコル・アドレスは、任意のコンピュータ又はインターネット上の仮想ロケーションの識別子である。ランデブーＩＰアドレスは、提案された対話が発生する場所のＩＰアドレスである。提案者ＩＰアドレスは、発信元のコンピュータの実際のＩＰアドレスである。認証ＩＰアドレスは、一次ＡＩＭサーバによって見られる発信元のコンピュータのＩＰアドレスである。実際のＩＰアドレスに付随するコンピュータが「アドレス翻訳ファイアウォール」に隠れていて、不当使用（例えば、コンピュータ・ハッキング）に対して保護されている場合等において、認証ＩＰアドレスは、実際のＩＰアドレスと相違している。この状況において、認証ＩＰアドレスを使用することにより、ファイアウォールに隠れているユーザーが、提案者ＩＰアドレス（実際のＩＰアドレス）ではなく認証ＩＰアドレスに向けられた任意の応答を有することによって、他のユーザーと通信することが可能となる。認証ＩＰアドレスはまた、不当なＩＰアドレスを他のユーザーに提供することである「スプーフィング(spoofing)」を防止することができる。
【００４７】
ＴＬＶフィールドの次のパラメータは、「ポート」であり、これは、ランデブー・チャネルに関する「転送制御プロトコル：ＴＣＰ）ポートの値である。より一般には、「ポート」は、ＴＣＰによって使用される論理チャネル識別子である。
【００４８】
ＴＬＶフィールドにおける次の２つのパラメータは、「ダウンロードＵＲＬ」及び「ベリファイ・ダウンロード（Verify Download）ＵＲＬ」である（ＵＲＬは、「ユニバーサル・リソース・ロケイタ」であり、その仕様は、ＲＦＣ１７３８に記載されている）。「ダウンロードＵＲＬ」は、どのようなサービスが要求されているかについてのソフトウエア又は他のデータをダウンロードする指令である。インターネット・リソースの殆どは、ＵＲＬを有している。なお、ＵＲＬは、ウエブサイト以外のリソースを指定することができるが、一般に、ウエブサイト・アドレスと称せられている。例えば、ユーザーがブリッジ等のコンピュータ・ゲームで遊びたいと仮定すると、該ゲームに参加するために、ブリッジ・ソフトウエアをユーザーのパーソナル・コンピュータ・ワークステーションにダウンロードする必要がある。「ベリファイ・ダウンロードＵＲＬ」は、前述のパラメータと同一の基本情報コンテンツを有しているが、一次ＡＩＭサーバによって、保護目的で追加がなされる。
【００４９】
ＴＬＶフィールドにおける次のパラメータは、「シーケンス番号」であり、これは１増分カウンタであって、特定のランデブー交渉セッション内における各要求を反復する（例えば、すべての提案及び逆提案）は、同一のランデブー・クッキーを有している）。オリジナル要求はシーケンス番号１が付けられ、第１の逆提案はシーケンス番号２が付けられ、以降同様である。
【００５０】
ＴＬＶフィールドの次のパラメータは、「取消し理由」であり、これは、与えられたランデブー交渉セッションがキャンセルされる理由を示す。（上記した）有効な理由には、「未知」、「ユーザー・リクエスト」、及び「タイムアウト」が含まれている。
【００５１】
ＴＬＶフィールドの次のパラメータは、「インビテーション」である。これは、任意のテキスト列であり、かつ、一般に、人間が読むことができる言語で通信するために用いられる。例えば、ユーザーＰがユーザーＱとオンラインでチェス・ゲームをすることを希望していると仮定する。ユーザーＰは、ユーザーＱに対して提案メッセージを送り、「こんにちはＱさん。チェスゲームをしませんか？」のインビテーションを送る。
【００５２】
ＴＬＶフィールドにおける最後の２つのリザーブされたパラメータは、「インバイト・マイム・キャラクタ・セット(Invite Mime Character Set)」及び「インバイト・マイム・ランゲージ(Invite Mime Language)」である。これらのパラメータは、インビテーションにおいて使用されている文字セット及び言語をそれぞれ特定する。文字セットが「ＵＳ−ＡＳＣＩＩ」、「ＩＳＯ−８８５９−１」、及び「ＵＮＩＣＯＤＥ−２−０」を含んでいると仮定する。マイム・プロトコルについて、有効値はＩＳＯ６３９、ＩＳＯ３１６６及びＲＦＣ１７６６によって指定されている。所望ならば、国名（例えば、英国-UK）も含ませることができる。
【００５３】
最後に、再度図５を参照する。ランデブー・メッセージは、アプリケーション特定パラメータのフィールド５１３を含んでいる。該アプリケーション特定パラメータは、ＴＬＶフィールドの一部ではあるが、リザーブされた範囲（すなわち、最初の１５個のパラメータ）以外のものである。これらパラメータは、アクセスすべきアプリケーション又はサービスに関連している。例えば、オンラインで行われる異なるコンピュータ・ゲームは、通常、このフィールド中に異なるパラメータの組を有している。
【００５４】
上述のように、クライアント・エラー・メッセージは、標準ランデブー・メッセージ・フォーマットから特定的に除かれるが、その理由は、「悪意」の対象ではないように設計されているからである。それはＩＣＢＭではないが、「ＩＣＢＭクライアント・エラー」メッセージと呼ばれる関連するメッセージ・タイプである。従って、それはそれ自体のデータ・フォーマットを有しており、それは図８に示されている。何れのＩＣＢＭクライアント・エラー・メッセージの最初の２つのフィールド８０１および８０３も、ＴＣＰ／ＩＰヘッダおよびＩＣＢＭクライアント・エラー・ヘッダである。次のフィールド８０５はクッキーであり、それは、同じランデブー・セッション内のランデブー・メッセージのものと同じ値である（即ち、クライアント・エラー・クッキーは、そのクライアント・エラー・メッセージにより応答される提案メッセージのクッキーと同じ値を必然的に有する）。次のフィールド８０７はＩＣＢＭチャネルと呼ばれ、これは、ランデブー交渉自体が生ずるチャネルの値である（通常は２である）。（クライアント・エラーとの関連においては、ＩＣＢＭチャネル・フィールドは、ランデブー・メッセージのＴＬＶフィールドの同じ名前のパラメータとは異なるものであり、そこにおいては、ＩＣＢＭチャネル・パラメータは、提案されたインタラクションが生ずるチャネルを指すものであり、ランデブー交渉自体が生ずるチャネルを指すものではない、ということに注意されたい。）。
【００５５】
最後のフィールド８０９はクライアント・エラー・コードである。図９を参照すると、クライアント・エラー・コードに対しての可能な値が示されている。これらの値は、上述の、クライアント・エラー・メッセージに対しての６つの考えられ得る理由に対応する。
【００５６】
図１０、１１、１２、１３、１４は、ランデブーに関連する交渉の間にＡＩＭのユーザにより見られるスクリーン・ショットの例を示す。上述のように、ＡＩＭは、ランデブー・プロトコルの１つの特定的な実施形態である。図１０は、どのように提案メッセージ１０００が発信者（originator）に対して現れるのかを示す。図１０において、提案される活動はチャットであり、予定される受信者（recipient）のスクリーン名１００２は「ｙｉｐｓｔｅｒ６６６」である。提案メッセージ１０００は、発信者がメッセージ・ボックスの右下隅の「Ｓｅｎｄ（送信）」ボタン１００４をクリックすると、受信者へ送られる。
【００５７】
図１１は、受信者に現れる提案メッセージ１０００を示す。メッセージ・ボックス１１０２は、提案の発信者のスクリーン名１１０４（この場合、「ｊｉｍｇｒｏｍａｄａ」）と、意図される活動１１０６（「Ｂｕｄｄｙ  Ｃｈａｔ（バディ・チャット）」）と、提案された活動のチャネル又は位置１１０８（「ｊａｇ  Ｃｈａｔ００」という名前のチャット部屋）と、テキストの招待用短信１１１０「Ｊｏｉｎ  ｍｅ  ｉｎ  ｔｈｉｓ  Ｂｕｄｄｄｙ  Ｃｈａｔ（このバディ・チャットで私と仲間になろう）」とを示す。受取側は、右下隅の「Ｇｏ  Ｃｈａｔ（チャットへ進む）」ボタン１１１２をクリックすることにより提案を受け入れる選択を行え、「Ｄｅｃｌｉｎｅ（辞退）」ボタン１１１４をクリックすることにより提案を拒否する選択を行え、また、応答しないことにより提案をタイムアウトとすることができる。（提案を、逆提案を呈示することにより変更するオプションは、このスクリーン・ショットでは示していない。）。
【００５８】
図１２はポップアップ・ウインドウ１２００を示し、これは、受信者が提案を拒否すると決定したときに現れる。これは、「Ｄｅｃｌｉｎｅ」ボタン１１１４をクリックした結果として受信者のスクリーンに現れるメッセージ・ボックスである。この「Ｄｅｃｌｉｎｅ  Ｉｎｖｉｔａｔｉｏｎ（招待を辞退）」メッセージ１２００は、提案の受信者が「ＯＫ」ボタン１２０２をクリックしたときに、提案の発信者へ送信される。提案が不快なものであったり、煩わしいものであり、そのため、受信者が、その発信者を「悪意」のある者としたい場合に、受信者は、「Ｗａｒｎ（警告）」ボタンをクリックすることにより、それを行うことができる。受信者は、ブロック・ボタン１２０６により、この発信者（ｊｉｍｇｒｏｍａｄａ）から将来に提案を受信するのを阻止できる。
【００５９】
図１３において、提案の発信者は、提案の受信者から、拒否メッセージ１３００を受信している。この拒否メッセージ１３００は、定義では、クライアント・エラー・メッセージ型であり、そのため、提案の発信者は、その提案が拒否されたとしても、その受信者を「悪意」のある者とする機会を持てない。提案の発信者が使える唯一のオプションは、「ＯＫ」ボタンをクリックすることである。
【００６０】
図１４は、ユーザが別のユーザからファイル転送リクエストを受信するときに現れるウインドウ１４００のスクリーン・ショットを示す。ファイル転送は、ランデブー・プロトコルによりサポートされる１つの活動である。受信者は、提案（即ち、ファイル転送）の受け入れに対応して「ＯＫ」１４０２をクリックし、ファイル転送リクエストを受け入れるか、または拒否に対応して「Ｃａｎｃｅｌ（キャンセル）」１４０４をクリックし、リクエストを拒否する。
【００６１】
図１５において、オンライン・コンピュータ・ゲーム提案メッセージ１５００の描写を示す。提案の発信者１５０２、Ｕｓｅｒ＿Ａ（ユーザーＡ）は、参加者１５０６（Ｕｓｅｒ＿ＡおよびＵｓｅｒ＿Ｂ）で特定のゲーム１５０４（コントラクト・ブリッジ）をエキスパート・レベル１５１０で行うことを望んでいる。図１５は、Ｕｓｅｒ＿Ｂ（ユーザーＢ）に受信された提案メッセージがどのように見えるかを示し、このユーザーＢは、メッセージ・ボックスの下部の適当なボタンをクリックして応答する機会を有する。ユーザーＢがこの提案により傷つけられた場合には、「Ｗａｒｎ」ボタン１５１２をクリックすることにより、それを登録することができる。ユーザーＢが、その提案を、穏やかなものとして受け入れたい場合には、「Ａｃｃｅｐｔ（受け入れ）」ボタン１５１４をクリックする。ユーザーＢが、オンラインのブリッジを全く行いたくない場合には、「Ｄｅｃｌｉｎｅ」ボタン１５１６をクリックする（また、ユーザーＢが何れのボタンもクリックしなければ、タイムアウトにより、提案は最終的に辞退される）。ユーザーＢが、行うことには同意するが、示されたパラメータ（例えば、ゲーム１５０４、参加者１５０６、型１５０８、レベル１５１０）の１つ以上のものについて同意しない場合には、ユーザーＢは「Ｍｏｄｉｆｙ（変更）」ボタンをクリックして逆提案を呈示することができる。
【００６２】
図１６は、その様な逆提案ボックス１６００が、初期提案を修正したいと望んでいるユーザー（即ち、図１５及び図１６の両方に示された例ではUser_B）に対して、どの様に表示されるかを示す。逆提案は、新たな提案として働き、且つUser_Bが逆提案の提案者であるので、発信者（Originator）１６０２はここではUser_Bである。この逆提案は、同じランデブー交渉セッションの一部なので、前記初期提案に対するクッキーは逆提案に対するクッキーと同じになることに注意されたい。しかしながら、初期提案に対する連続番号は１に等しく、逆提案に対する連続番号は２に等しい。クッキー及び連続番号は、どちらも、このランデブー交渉セッションに関連するユーザーには見えないソフトウエア・パラメータである。
【００６３】
図１６を再度参照して、User_BがUser_Aとオンライン・ブリッジをすることに同意するのが望ましい。しかしながらUser_Bは、コントラクト・ブリッジよりむしろ他のタイプのブリッジ（デュプリケート・ブリッジ）１６０８を好み、更にまたUser_Bは熟練レベルでなく中間レベル１６１０で遊ぶことを好む。そこでこれらのパラメータが、逆提案ボックス１６００内で修正され、User_Aに送り返される。そしてUser_Aは、応答のための同じ選択肢（即ち警告、受け入れ、拒否、または修正）を持ち、ランデブー交渉セッションは、このような方法で、承諾（即ち、最近の提案の受信者が「受け入れ（Accept）」をクリックする）、拒絶（即ち、最近の提案の受信者が「拒絶（Decline）」をクリックする）、または中止（即ち、最近の提案の送り主が、提案を送った後で応答を受け取る前に「取消し（Cancel）」ボタンをクリックして中止する）で終わるまで継続する。
【００６４】
上述のランデブー・プロトコルに対する他の実装及び使用が可能である。一般に、ランデブー・プロトコルは、２人以上のユーザーや２台以上のクライアント・コンピュータに、通信または対話セッションのパラメータの交渉を許すことが望ましいときは何時でも使うことができる。例えば、ランデブー・セッションは、電子商取引応用において、買手と売手が、商品、サービス、保証または他の任意の有形無形の資産の販売の提示に関する価格や他の条件の問答をすることを許すために用いることができる。更に、ランデブー・プロトコルは、共同プロジェクト開発環境（例えば「ロータス・ドミノ」（登録商標））において、文書などの変更を協議するために用いることができる。
【００６５】
ここで説明した技術、方法及びシステムは、電子的内容が交換され、閲覧され、アクセスされ、さもなければ操作される、任意の計算または処理環境において応用できる。ここで説明したシステム及び技術の種々の実装が、デジタル電子回路、ソフトウエア、またはこれらの組み合わせにおいて実現できる。ここで説明した技術や方法の１つ以上を用いるシステムまたは他の装置が、コンピュータ・プログラムを用いて構成されたコンピュータ可読の記憶媒体として実装でき、このように構成された記憶媒体は、コンピュータ・システムを、特定の予め定義された仕方で入力上で動作させ、及び／または出力を発生させるようにする。その様なコンピュータ・システムは、データ記憶システム及び適当な入力及び出力装置からデータ及び命令を受け取り、且つそれらへデータ及び命令を送る、１つ以上のプログラム可能な処理装置を含む。
【００６６】
各コンピュータ・プログラムは、高水準の手続型またはオブジェクト指向のプログラム言語、または必要ならアッセンブリまたは機械語で実現され得、いずれにせよこの言語はコンパイルまたはインタープリター言語である。適当な処理装置は、例えば、汎用及び専用のマイクロプロセッサの両方を含む。
【００６７】
一般的に、処理装置は読み取り専用記憶装置及び／またはランダム・アクセス記憶装置から命令及びデータを受け取る。コンピュータ・プログラム命令及びデータを具体的に実現するために適当な記憶装置には、EPROM、EEPROM及びフラッシュ記憶装置のような半導体記憶装置、内蔵ハード・ディスク及び着脱式ディスクのような磁気ディスク、光磁気ディスク、及びCD-ROMディスクを含む全ての形式の不揮発性記憶装置を含む。
【００６８】
前述の全てのものは、特別に設計されたASIC（特定用途向けIC）で実現され、補足され得る。
本発明の多くの実施例が説明された。それにもかかわらず、本発明の精神及び範囲を逸脱せずに種々の変更が可能であることは理解できるであろう。従って、他の実施例も、本願の請求項の範囲に含まれるものである。
【図１】
2009193591.tif 000003
【図２】
2009193591.tif 000004
【図３】
2009193591.tif 000005
【図４】
2009193591.tif 000006
【図５】
2009193591.tif 000007
【図６】
2009193591.tif 000008
【図７】
2009193591.tif 000009
【図８】
2009193591.tif 000010
【図９】
2009193591.tif 000011
【図１０】
2009193591.tif 000012
【図１１】
2009193591.tif 000013
【図１２】
2009193591.tif 000014
【図１３】
2009193591.tif 000015
【図１４】
2009193591.tif 000016
【図１５】
2009193591.tif 000017
【図１６】
2009193591.tif 000018