因特网和万维网的迅速出现建立了这样一种环境，在这种环境中， 世界各地的可以通过其个人计算机连接到因特网的人们一般都能访问 通过网站提供的信息世界。电子邮件(也叫作e-mail)也由于其使用 的方便性及其低廉的价格而被普遍使用。各领域中技术的发展刺激了 这些性能的出现，这类技术发展包括：微处理器(无论在计算速度方 面还是在小型化方面)，计算机操作系统和接口(例如，Windows、 Macintosh和Unix)，和因特网浏览器(例如，Netscape Navigator)。 技术的迅速发展通常又对生产力和全球经济产生了积极的影响。因此， 有了对高技术实体的刺激作用，将进一步提高与因特网有关的技术水 平。
在线论坛是一种通信交换，在这种在线论坛中，人们可以通过各 自的计算机系统之间的连续的电子传输进行相互通信。在线论坛或其 他任何类型的分布式计算机业务可以在诸如图1中所示的分布式计算 机系统中实现。论坛参与者(即计算机业务的用户)一般分散在广阔 的地域中，并通过各自的客户系统102(例如个人或膝上型计算机) 与一个或多个中央服务器系统100通信。实际上，服务器系统100一 般不是一个单一实体，而是一个互连服务器计算机的网络，这些服务 器计算机实际上可能是彼此分散的，它们每个都有各自的一组工作任 务和/或位于特定的地区。在这种情况下，各个服务器通过通信链路的 网络按众所周知的方式互连。一个这样的服务器系统是弗吉尼亚美国 在线有限公司(AOL)的“美国在线”。
每个客户系统102都运行客户软件，该软件使得它可以按有意义 方式与服务器系统100中所运行的相应软件通信。客户系统102通过 各种信道(比如，与电话线106连接的调制解调器104，或采用诸如 传输控制协议/网际协议(TCP/IP)等传输协议的直接因特网连接)与 服务器系统100通信。服务器系统100负责接收客户系统102的输入， 将输入信息的集合体(以及可能来自其他源的信息)转换成可用格式， 并将格式化信息重新发回到一个或多个客户102，以便在输出设备(如 显示屏)上显示。
因特网“文化”的一个特定方面是“聊天室”现象。聊天室是一 个虚拟空间(即电子信道)，在该虚拟空间中，一些具体的通信活动正 在进行。在某些情况下，该活动是一个应用程序(比如计算机游戏)。 在其他许多情况下，该活动是参与者之间的简单交谈，即聊天会话”。 参照图2，示出了一个聊天室200，在该聊天室中，各个参与者204(例 如，“Allens9”、“JOSHUAALEX”等)可以输入文本，这些文本出现 在每个参与者的计算机显示屏的滚动文本窗202中。在图2的例子中， 聊天室200中有22个参与者，参与者的身份(即屏幕名)列表于滚动 窗210中。参与者204可以通过在编辑框206中输入一行文本并激活 (例如，用定点设备比如鼠标单击)“发送”按钮208，来回应别的参 与者204的评论。于是，滚动文本窗202中的文本向上滚动，而新近 输入的这行文本将显示在滚动文本窗202的底部。在所示例子中，上 一个参与评论的参与者是JOSHUAALEX，他输入了“TEXAS”。
图2中所示的聊天室200是“公众的”，也就是说，它通常对访问 在线业务的任何用户都是开放的，并且它一般有多个参与者，这些参 与者是由计算机业务提供者安排到聊天室的，而且他们以前很有可能 彼此从来没有碰到过或者谈过话。公众论坛中参与者发表的评论可以 被该聊天室中的所有参与者看到。如果一个参与者需要某种保密，那 么，该参与者可以打开并进入“私人”聊天室(例如，通过单击“私 人聊天室”按钮212)，然后，邀请一个或多个其他参与者进入私人聊 天室，这样只有发起者及其被邀请者才能访问该私人聊天室。一旦进 入私人论坛，参与者就可以相互通信，而无需担心未被邀请的参与者 能看到他们的评论。此外，还可以有半公众聊天室，它是对指定的一 群用户开放的。
AOL建立了AOL Instant Messenger(AIMTM)系统。AIM系统 允许用户建立一个电子消息发送介质(称为“Buddy List”TM，表中 包括用户在线时经常与其交互的别的用户(比如朋友和家人))并向那 些用户发送即时消息(IM)。只要该用户的伙伴表中的一个成员在线， AIM系统就自动通知该用户。因此，两个伙伴就可以直接通信(即聊 天)，因为他们俩都在线而且彼此都知道对方在。
AOL在这方面的另一项开发是“恶行”(Evil)概念。这一概念的 出现是由于这样的事实：用户可能并实际上滥用这些性能提供给他们 的与别的用户即时通信并发送大量的信息的特权。这种滥用现象可能 发生在：例如，当用户发送一些具有令人讨厌的内容的消息时，或者 当用户由于向其他用户发送过多的消息而过度使用了AIM系统时。另 一种滥用形式可以发生在：  当一个用户向另一个用户传送一些含有大 量数据的文件时，这样，当接收者想打开或下载这些文件时，或者甚 至是执行其他活动时，接收者的计算机系统因处理接收到的这些文件 而变得迟缓。
AOL建立这种“恶行”概念是为了补救这种类型或其他类型的滥 用现象。如果用户发觉另一个用户正在使坏(例如反复发送不想要的 IM)，那么，被冒犯的用户可以使行为不端用户成为“恶行”用户或 向其发出警告，从而增加行为不端用户的“恶行”等级。使用户成为 “恶行”用户的影响力虽然一般较小但可以累积。随着时间的流逝， 如果一个用户被记录下有足够多次的恶行，那么，作为惩罚，可以故 意减慢这个用户使用系统资源(例如发送IM)的能力。如果滥用现象 依旧，甚至出现更多的恶行记录，那么滥用者最终可能被不知不觉地 终止进入计算机网络。这种基本想法的目的是为了在在线(特别是聊 天室)环境中推行计算机礼节和基本礼貌。给予用户互相记录“恶行” 的权力使得他们能够形成一个自我警备的社团，从而减轻因特网业务 提供者(ISP)必须实现这种警备功能的责任。关于恶行记录技术的进 一步的细节可以参见：1998年5月13日申请的美国序列号09/076,483， 名称为“Regulating Users of Online Forums”，以及1998年5月13 日申请的美国序列号09/076,484，名称为“Self-Policing，Rate Limiting Online Forums”，这两个申请在此作为参考。
尽管在聊天室中可以针对任何主题进行完全自由式的会话，然而， 聊天室通常有组织地围绕一个特定的主题进行讨论。聊天室现象的扩 散需要这样一种机制，以便最理想地使聊天室环境满足用户的要求。 例如，某个用户可能想与三个其他用户构成的一个特定的组就某个特 定主题进行私人交谈。或者，该用户可能想与两个都处在不同的远端 点的朋友共同玩某个特定的计算机游戏。现在，如果这种用户想参加 这类活动，那么该用户可以：1)寻找一个所需活动正在进行的现存聊 天室并尝试参加，而未必能控制其他参与者的身份或数量；或者2)向 想与其一起参加该活动的其他用户发送一个IM或电子邮件消息并邀 请他们参加。通常，邀请方用户可能根本未接收到响应(例如，如果 接收者对邀请不理睬)，也可能接收到对邀请的双态响应(即肯定或否 定)。
根据以上所述，本发明人认为需要一种有效且灵活的协商机制， 据此，想彼此进行通信或者说以其他方式交互的用户可以互相进行“交 易”，以便最终就相互可接受的通信(例如聊天室)或其他交互(例如 多用户计算机游戏)环境达成一致的意见。

实现方式可以包括下列特征的各种组合。
一种称为“汇集”(Rendezvous)协议的协议可用来通过将第一个 用户的活动建议发送给另一个用户，以便于计算机网络用户之间的交 互。该建议可以包括一个或多个描述所建议的活动的参数。然后可接 收来自该另一个用户的应答，比如接受、拒绝或反建议。根据接收到 的应答，用户可选择地参加或不参加所建议的活动。
一种这样的活动可以是在线“聊天”会话，而一个聊天建议的一 组典型的参数可以包括：聊天会话所针对的建议话题，和进行聊天会 话的建议信道。另一种典型的活动可以是在线计算机游戏，而指定的 参数可以确定参与该游戏的建议参与者。
接受表示同意该建议的所有参数。拒绝表示不同意该建议的至少 一个参数。反建议表示提出修改一个或多个建议参数。如果作出反建 议，那么可作出对该反建议的再次应答，这一应答也可以是接受、拒 绝或又一反建议。这一过程可以一直进行，直到出现接受或拒绝为止。
只要在接收应答之前，最初作出建议或反建议的用户都可以取消 建议或反建议。通常，这种取消应当包括一个取消理由。
在发出拒绝时，用户可以明确地或不明确地(无行动地)表明不 理睬该建议。
该协议允许用户发出消息(指“恶行”消息)，从而记录任何建议、 反建议或接受所带来的不愉快。“恶行”消息累积地(可能以指数形式 累积)影响接收者使用计算机系统资源的能力。
该协议的另一目的在于，通过使在线用户在达成一致意见之前可 以一直协商活动参数的方法，帮助在线用户形成一个最佳活动环境。 典型的活动包括交换话音消息、玩在线游戏、寻找一个客户计算机到 另一个客户计算机的路由、传送文件、直接即时消息发送、交换图形 表达方式(avatar)、加入聊天室或参加协作项目开发。
另一种可以利用“汇集”协议的可能的在线活动是电子商务。该 协议适用于商品或业务或者无形资产的销售/购买的协商。这种协商的 参数一般可能包括价格、型号、规格、颜色、交付细节和担保细节。
拒绝消息可以表明一个拒绝理由。一般理由如下：所建议的活动 未获该建议的接收者的客户计算机支持；所建议的活动遭该建议的接 收者拒绝；该建议的接收者明确地不理睬该建议；该建议超时；或者 该建议消息无法理解。
在一种实施方式中，汇集协议被实现成可能处在较大的计算机软 件应用程序中的计算机软件。协议软件明确地包含在计算机可读介质 中或传播的载波信号中。协议软件包括一些允许计算机系统进行在线 协商会话的指令。
这里所述的技术和机制可以提供一个或多个下列优点。汇集协议 为用户提供了协商交互式在线环境(聊天会话、在线游戏等)的特性 的能力。因此，用户可以定制和优化他们的在线环境，以便所有参与 者相互都友善相处。这一优化一般在环境协商开始之前进行。因此， 用户可以参加他自己所选择的符合其意愿的环境，而无需面临不想要 的或不满意的情况或参与者。
从后面的描述(包括附图和权利要求书)中还可以看到其他特征 和优点。

图1示出了一种用于提供在线计算机业务的现有技术的分布式计 算机系统。
图2是一个表示现有技术的在线计算机聊天室论坛的一个例子的 屏幕画面。
图3是一个说明协商过程的协议流程图。
图4是一个状态转换值表。
图5是一个说明协商协议消息的数据格式的图表。
图6是一个协商协议中的数据字段的数据值表。
图7是一个协商协议消息中的TLV字段的参数表。
图8是一个说明客户错误消息的数据格式的图表。
图9是一个客户错误码数据字段的数据值表。
图10是一个表示聊天建议消息如何显示给始发该建议的在线计 算机用户的一个例子的屏幕画面。
图11是一个表示聊天建议消息如何显示给接收该建议的在线计 算机用户的一个例子的屏幕画面。
图12是一个表示客户错误(拒绝)消息如何显示给拒绝该建议的 在线计算机用户的一个例子的屏幕画面。
图13是一个表示客户错误(拒绝)消息如何显示给始发被拒绝的 建议的在线计算机用户的一个例子的屏幕画面。
图14是一个表示文件传送建议消息如何显示给接收该建议的在 线计算机用户的一个例子的屏幕画面。
图15示出了直接玩(计算机游戏)建议消息如何显示给始发该建 议的在线计算机用户的一个例子。
图16示出了直接玩反建议消息如何显示给接收原建议并回应以 反建议的在线计算机用户的一个例子。
各图中，相同的标号和标识表示相同的单元。

本发明人开发出了一种协商协议，称为“汇集”协议，该协议提 出了一种机制，用于在两个或两个以上计算机用户之间协商安排一种 相互都满意的通信或多用户交互环境。该汇集协议的一种实现方式是， 在AOL Instant Messenger(AIM)系统中，允许计算机网络用户交换 即时消息(IM)或参加“聊天”会话，并当用户的伙伴中的任一成员 在线时就通知该用户，以便于直接交谈。该汇集协议提出了一种通用 框架，软件开发者在软件应用程序中可以利用这种框架实现各种用户 协商功能性。这种允许用户聊天、来回发送IM和传送文件的AIM系 统体现了汇集协议的一种具体应用。总的来说，汇集协议一般在标准 TCP/IP协议范围内操作，但也可以采用任何合适的协议来取代 TCP/IP。关于这一点，最好采用有利于可靠连接的协议。
汇集协议将一种充分的灵活性应用于聊天场合或其他与另一个用 户的交互场合。可以认识到，用户可能想参加具体情况下的特殊活动， 例如，与其他一些玩家玩一个计算机游戏，或者在私人聊天室谈论一 个特定主题。汇集将“跳蚤市场式”协商作为一种协商交互环境的参 数的模式。其中，用户可能想控制的参数类型包括其他参与者的人数 以及那些参与者的身份。例如，也许某个用户在线时喜欢打桥牌，但 只能与特定的三个人打；或者，也许某个用户想就一个新的在线游戏 与其他计算机游戏爱好者进行通信。汇集协议允许用户提出针对这些 参数的通信会话主题。此外，汇集允许这些建议的接收者不仅可以接 受或拒绝该建议，而且可以回应以一个修改一个或多个所建议参数的 反建议。
汇集协议用作AIM系统的基本结构。AIM系统中的伙伴之间的 基本消息被称为客户间基本消息(缩写为ICBM)。ICBM被认为含有 “有效载荷”，它保存有ICBM的信息内容。即时消息(IM)是ICBM 有效载荷的一个例子，该消息很象一个可以立即被展现给接收者的 e-mail消息。通常，一个基于汇集的消息是ICBM有效载荷的另一个 例子。(应当注意，下面将要描述的还有一种汇集消息，即客户错误消 息，它不是ICBM。)
如上所述，AIM系统的一个特性在于能使另一个用户成为“恶行” 用户。比如说，当第一个用户被另一个影响他的用户的行为所侵扰时， 第一个用户可以利用“恶行”性能来对付该另一个用户。例如，假定 第一个用户发送一连串IM给一个伙伴(第二个用户)，但在第三个消 息后，该伙伴发回一个消息，请求第一个用户停止用所有这些讨厌的 消息来打扰第二个用户。尽管如此，第一个用户却继续发送消息。第 二个用户很恼火，便决定使发件人成为“恶行”用户或向其发出警告。 通常，在任意ICBM中都可以使用“恶行”。(应当注意，由于客户错 误消息不是ICBM，因此，对下述原因不能记录其“恶行”。)
利用汇集协议处理过程来协商参数的过程如图3中的流程图所 示。一个想与一个或多个其他用户交互比如想建立一个特定的聊天室 环境的用户(称为“始发者”)，通过将一个“建议”消息发送给一个 伙伴(步骤301)，开始进行汇集会话。建议消息包括始发者关于所 想要的交互的建议，本例中所想要的交互是一个指定的聊天室环境(例 如，话题、参与者等)。
如果在发送了建议消息后(但在由于其他某一事件(比如接收者 的接受或超时)导致的协商过程结束之前)的任何时候，始发者想取 消该建议，那么，这可以通过发出一个取消消息(步骤303)来实现。 取消消息允许始发者提出一个取消理由。三种有效的取消理由包括“不 知道”、用户请求”和“超时”。通过说明取消理由是“用户请求”， 可以表示正常的取消(即始发者改变主意而不想参加交互)。当接收者 不能及时地应答该建议而始发者放弃等待应答于是从表中取消掉该建 议时，认为“超时”是取消理由。如果不知道取消消息的理由，那么 取消理由字段将指示“不知道”。
假定原建议未被取消，那么该建议的接收者可以按几种不同的方 式来应答该建议(步骤305)。接收者可以应答的一种方式是，通过发 送接受消息来接受完全如所提出的建议(步骤307)。这样就使汇集会 话成功结束，从而允许建议的始发者和建议的接收者参加所希望的交 互(如聊天室)活动。应当注意，对于上述实现方式，汇集会话能成 功结束(即各方参加经汇集会话商定的在线活动)的唯一方式是要借 助接受消息。然而，根据应用程序开发者的目标，可以实现汇集协议， 以使其他条件(例如，在某些情况下，接收者反对建议失败时)也能 导致成功结束。
接收者应答的另一种方式是，通过发送客户错误消息来拒绝该建 议(步骤309)。客户错误消息具有一个告知始发者拒绝理由的字段。 可能的理由如下：
1)建议未获支持(例如，接收者的计算机不能支持)
2)建议遭拒绝
3)建议不被理睬
4)建议超时
5)错误参数
6)在线但不方便/忙
“建议未获支持”是当接收者的计算机配置不适用于参加所建议 交互时的一个正当理由。“建议遭拒绝”是对建议的明确拒绝，表示该 建议的接收者不喜欢参加这一交互。“建议不被理睬”表示接收者主动 选择不理睬该建议。“建议超时”表示接收者未能在某一时间段内应答。 “错误参数”表示建议消息本身无法被理解，例如，如果建议消息在 传输中出错因此无法被接收者的计算机所辩认。“在线但不方便/忙” 是当接收者可能感兴趣但此刻忙于其他活动时的一个正当理由。例如， 如果当接收者在线正从事工作中的或学校里的科研工作时，他的伙伴 之一建议他们一起玩在线计算机游戏，那么，该接收者大概会回应以 一个说明理由“在线但不方便/忙”的客户错误消息。该接收者可能通 过设置一种软件开关来回应，这种软件开关可以自动对接收到的每个 建议都回应以“忙”消息。
应当注意，在这一实现方式中，客户错误消息是仅有的不能记录 其“恶行”的汇集消息。对于其他所有汇集消息类型，都可以记录其 恶行。决定这样设计的理由是，仅仅因为用户拒绝参加某一交互而使 其成为“恶行”用户并不是“恶行”的目的，它是为了警告用户不要 滥用计算机资源。然而，汇集协议可以这样实施，即根据实施者的要 求，对于任意一个或多个可用消息，可以记录其恶行也可以不记录其 恶行。
接收者的另一种可能的应答是，通过向始发者发回一个建议消息 来修改原建议(步骤311)。这一消息包括接收者的反建议。这是双方 之间争议最终聊天室细节或其他交互(例如一对一游戏)环境的基本 方法。例如，假定用户A想与用户B玩在线专家级桥牌计算机游戏。 用户A向用户B提出这一建议。然而，用户B更喜欢中级而不喜欢专 家级，因此，用户B向用户A发出一个反建议，建议玩中级游戏。作 为第二个例子，假定用户X和用户Y一起参与某个研究项目，并且他 俩都想进入能经常讨论其主题的聊天室。用户X向用户Y建议他们到 以前他们去过的一个特定的聊天室会面。然而，用户Y听说过另一个 可以提供更好的信息的聊天室，因此，用户Y向用户X发回一个反建 议，建议他俩到这一新聊天室会面。
一旦反建议被发送，该反建议的接收者也就具有与原建议的接收 者一旦接收到原建议时所具有的相同的选择(即接受，通过客户错误 消息拒绝，或通过建议消息发送另一个反建议)。也就是说，实际上将 反建议作为一个新建议来处理。反建议的发送方可以选择通过取消消 息来取消反建议，就象原建议者可以选择取消原建议那样。这样，汇 集会话可以继续来回，直到这些用户要么同意某在线活动要么其中一 个用户决定通过客户错误消息终止会话为止。
如图4中所示，在汇集状态转换表中提供了该汇集协议的一种表 示方式。状态转换表列出了一个汇集会话的三种可能的状态：状态1 是建议的始发者的状态；状态2是建议的接收者的状态；而状态3是 结束状态，在该状态中，汇集会话结束。一旦发送一个建议，从而启 动汇集会话，该建议的始发者就进入状态1，而建议的接收者就进入 状态2。
在状态1中，将发生5个可能事件之一；这5个事件用状态1中 的5个子状态来表示。如果接收到接受消息(即子状态1.1)，则汇集 协商成功，于是用户进至子状态3.1，在此，汇集会话结束而所商定的 在线活动开始。如果接收到客户错误消息(即子状态1.2)，那么汇集 协商失败，于是用户进至子状态3.2，在此，汇集会话结束而用户终止 其交互。如果接收到反建议(即子状态1.3)，那么该用户成为针对该 反建议的建议接收者从而进入状态2。如果发生超时(子状态1.4)或 者发送了取消消息(子状态1.5)，那么通过进至子状态3.3取消该协 商会话，在此，汇集会话结束而用户终止其交互。
在状态2中，可发生4个可能的事件；这些事件一般与状态1中 所列出的5个可能的事件相应(状态2中的第4个事件(即子状态2.4) 与状态1中的第4个(即子状态1.4)或第5个(即子状态1.5)事件 相应)。作为建议的接收者，状态2中的用户可以发送接受消息(子状 态2.1)、客户错误消息(子状态2.2)或反建议(子状态2.3)。第4种 可能性是接收取消消息(子状态2.4)。如果发送了接受消息，则汇集 协商成功，于是用户进至子状态3.1，在此，汇集会话结束而所商定的 在线活动开始。如果发送了客户错误消息，那么汇集协商失败，于是 用户进至子状态3.2，在此，汇集会话结束而用户终止其交互。如果发 送了反建议，那么该用户成为该建议的始发者从而进入状态1。如果 接收到取消消息，那么通过进至子状态3.3取消该协商会话，在此， 汇集会话结束而用户终止其交互。
在状态3中，汇集会话以三种方式之一结束。当根据建议消息发 送了接受消息时，协商成功(子状态3.1)。在这种情况下，两个用户 将参加所商定的在线交互。当根据建议消息发送了客户错误消息时， 协商失败(子状态3.2)。在这种情况下，参与汇集会话的用户将终止 其交互。当在发送了建议消息后但在接收到应答之前发送了取消消息 时，发生取消协商(子状态3.3)。在这种情况下，参与汇集会话的用 户将终止其交互。在状态3中的所有这三种情况下，汇集会话都结束， 这用终止使用汇集“Cookie”来表示，这种汇集“Cookie”是该特定 汇集会话所特有的标识符。
图5中示出了一个说明汇集消息(客户错误消息除外)的组成部 分和格式的图表。(由于客户错误消息不是ICBM，因此它具有它本身 的格式，如下所述。)由于汇集消息是一个ICBM有效载荷，并且由 于所有ICBM都使用标准的TCP/IP协议，因此，汇集消息(客户错 误消息除外)中的前两个字段501和503是TCP/IP标题和ICBM标 题。ICBM标题将该消息标识为是一个汇集消息。下一个字段505定 义汇集消息类型，其长度为两个字节。有效消息类型包括建议、取消 和接受。图6中给出了图5中所示的这些字段的有效数据值。正如该 图中所示，消息类型字段可以包括表示建议消息的“0”、表示取消消 息的“1”或表示接受消息的“2”。
再参照图5，汇集消息中的下一个字段507长度为8个字节，称 为Cookie。Cookie作为特定汇集协商会话所特有的标识符；因此，作 为同一汇集会话的组成部分的所有ICBM都具有相同的Cookie，但一 个新汇集会话将具有一个新的Cookie。下一个字段509是一个64个 字节的字段，称为UUID(通用独特标识符)。该字段指定所需业务类 型。再参照图6，图中有7种能用汇集协议访问的标准的业务类型： “AOL通话”、“直接玩”、“文件传送”、“路由探测器”、“直接ICBM”、 “图形表达方式交换”和“聊天”。这些业务中有几种在AOL Instant Messenger版本2.0中可用。(应当注意，图6中只示出了UUID的前 十二个字符。对于所给出的所有7个UUID，最后二十个字符是 11D1-8222-444553540000。)“AOL通话”是指与AOL兼容的的允许 用户相互交换音频消息的话音体系。“直接玩”是指玩在线计算机游戏。 “文件传送”允许将计算机文件(比如文本，电子数据表，或者图象 或图形数据文件)从一个用户传送到另一个用户。“路由探测器”允许 用户在下述情况下找到另一个应用的因特网路由：“防火墙”阻止到所 需应用的直达路由(例如，如果用户在工作时在线，那么雇主通常设 置一些防火墙，即一些阻止指定的网络业务的软件代理)。“直接 ICBM”(即通过始发者的客户计算机与接收者的客户计算机之间的直 接TCP/IP连接发送ICBM)允许用户彼此直接地而不必通过AIM系 统的主服务器来交换IM，从而使速率更高保密性更强。应当注意，直 接ICBM性能使用户不能利用“恶行”记录性能，并且它还丧失了主 AIM服务器通常所提供的防计算机黑客攻击的能力。直接ICBM性能 还可能在穿过防火墙时遇到一些问题。“图形表达方式交换”允许用户 交换通常表示用户屏幕个性的图象。“图形表达方式”是这种图象的术 语，它可以是任意图形描述，比如，卡通画、图画或照片。“聊天”是 指聊天室中的一般在线会话；这种聊天一般是通过键入消息并来回发 送消息来完成的。
汇集协议并不局限于上述7种标准业务类型。可能的实现方式包 括允许用户例如通过进入专用用户界面以形成其自身的UUID以及相 应的应用。
再参照图5，下一个字段511是一组有序三位字节，每个有序三 位字节包括类型、长度和值；因此，这一字段称为“TLV”字段。TLV 字段含有多达15个的预留参数，加上一些应用程序专用参数。参照图 7，图中示出了类型字段中的15种可能的预留参数及其相应的编号， TLV字段包含有汇集过程中专门要协商的信息。TLV字段中的第一个 参数是“ICBM信道”；即“汇集信道”。这一参数确定所建议的ICBM 的种类，比如在线游戏或聊天。
TLV字段中的接下来的三个参数称为“汇集IP地址”、“建议者 IP地址”和“验证的IP地址”。IP地址即网际协议地址是任何计算机 的独特标识符或因特网上的虚拟位置。汇集IP地址是所建议的交互可 能发生的IP地址。建议者IP地址是始发者的计算机的实际IP地址。 验证的IP地址是主AIM服务器所看到的始发者的计算机的IP地址。 当(有时就是这样)与实际IP地址相应的计算机在地址转换防火墙后 面以便提供某种保护来防止非法使用(即计算机破坏程序)时，验证 的IP地址不同于实际IP地址。在那种情况下，验证的IP地址的使用 使得在防火墙后面的用户可以通过使任何应答被发向验证的IP地址 而不是发向始发者的(即实际的)IP地址来与其他用户进行通信。验 证的IP地址还可防止“电子欺骗”(即向另一个用户提供假IP地址的 行为)。
TLV字段中的下一个参数称为“端口”，这是汇集信道的传输控 制协议(TCP)端口的值。更一般地说，“端口”是TCP所用的逻辑 信道标识符。
TLV字段中的接下来的两个参数称为“下载URL”和“验证下载 URL”(URL＝统一资源定位符；其详细说明参见RFC1738)。下载 URL是一个用于为所建议的任何业务下载软件或其他数据的指令。大 多数因特网资源都具有URL；URL通称为Web站点地址，尽管URL 可能指向不是Web站点的资源。例如，如果用户想玩计算机游戏(如 桥牌)，那么，为了参与该游戏，桥牌软件必须被下载到其个人计算机 工作站中。验证下载URL具有与前一参数相同的基本信息内容，但为 了保护性原因它可以由主AIM服务器增加。
TLV字段中的下一个参数称为“序号”，这是一个单升计数器， 它针对某一特定汇集协商会话中的每个建议(即具有相同汇集Cookie 的所有建议和反建议)进行迭代。原建议被赋予一个等于1的序号， 第一个反建议被赋予一个等于2的序号，依次类推。
TLV字段中的下一个参数称为“取消理由”，它指出取消所给出 的汇集协商会话的理由。有效理由(如上所述)包括“不知道”、“用 户请求”和“超时”。
TLV字段中的下一个参数称为“邀请”。这是一个随意文本串， 一般用来以人类可读语言来通信。例如，假定用户P想与用户Q一起 下在线国际象棋。用户P将向用户Q发送一个建议消息，该邀请可以 显示：“嗨，Q，想不想下国际象棋？”
TLV字段中的最后两个参数称为“邀请Mime字符集”和“邀请 Mime语言”。这些参数分别规定了邀请中所使用的字符集和语言。所 支持的字符集包括“US-ASCII”、“ISO-8859-1”和“UNICODE-2-0”。 对于Mime协议，有效值由ISO639、ISO3166和RFC1766来确定。 需要的话，还可以包括国家(例如English-UK)。
最后，再次参照图5，汇集消息包括应用程序专用参数的字段513。 这些应用程序专用参数也是TLV字段的一部分，但其类型字段不在预 留范围(即前15个参数)内。这参数取决于要访问的应用程序或业务。 例如，可以在线玩的不同的计算机游戏通常在这一字段中将具有不同 的参数组。
如上所述，客户错误消息专门被排除于标准汇集消息格式之外， 因为客户错误消息不会被记录为“恶行”。尽管它不是ICBM，然而， 它是一个相关的消息类型，称为“ICBM客户错误”消息。这样，它 就具有其本身的数据格式，如图8中所示。任何ICBM客户错误消息 中的前两个字段801和803是TCP/IP标题和ICBM客户错误标题。 下一个字段805是Cookie，它与同一汇集会话中的汇集消息中的值相 同(即，客户错误Cookie必定具有与客户错误消息所应答的建议消息 中的Cookie相同的值)。下一个字段807称为ICBM信道，它是汇集 协商自身发生时所在的信道的值(通常等于2)。(应当注意，在客户 错误环境中，ICBM信道字段不同于汇集消息的TLV字段中的同名称 参数，其中，ICBM信道参数是指所建议的交互可能发生的信道，而 不是汇集协商自身发生的信道。)
最后一个字段809是客户错误码。参照图9，给出了客户错误码 的可能值。这些值与如上所述的客户错误消息的6种可能的理由相应。
图10、11、12、13和14示出了AIM的用户在与汇集相关的协商 期间所看到的屏幕画面的例子。如上所述，AIM是汇集协议的一种具 体的实现方式。图10示出了一个建议消息1000如何显示给始发者。 图10中，所建议的活动是聊天，而预定接收者的屏幕名1002是 “vipster666”。当始发者单击消息框的右下角的“发送”按钮1004时， 建议消息1000被发送给接收者。
图11示出了显示给接收者的建议消息1100。消息框1102示出了 建议始发者的屏幕名1104(本例中为“jimgromada”)、预定活动1106 (“伙伴聊天”)、所建议的活动的信道或位置1108(名叫“jag Chat00” 的聊天室)和正文邀请行1110“加入我的这一伙伴聊天”。接收者可以 通过单击右下角的“去聊天”按钮1112选择接受该建议，可以通过单 击“拒绝”按钮1114选择拒绝该建议，或者可以不作应答使得该建议 超时。(该屏幕画面中未示出通过提出反建议来修改该建议的选择。)
图12示出了当接收者决定拒绝该建议时所出现的弹出窗口1200。 这是单击“拒绝”按钮1114后在接收者的屏幕上出现的消息框。当该 建议的接收者单击“确定”按钮1202时，“拒绝邀请”消息1200将发 送到建议的始发者。如果，由于该建议被认为是冒犯的或令人讨厌的， 接收者想使始发者成为“恶行”用户，那么接收者可以通过单击“警 告”按钮来实现。“阻止”按钮1206使得收方可以阻止该始发者 (iimgromada)将来的建议。
图13中，建议的始发者已接收到来自建议的接收者的拒绝消息 1300。由于这一拒绝消息1300按规定是一个客户错误消息类型，因此， 即使建议被拒绝，建议的始发者也没有机会使接收者成为“恶行”用 户。建议的始发者所能进行的唯一选择是单击“确定”按钮。
图14示出了当一个用户接收到另一个用户的文件传送请求时所 出现的一个窗口1400的屏幕画面。文件传送是汇集协议所支持的活动 之一。接收者分别根据该建议(即文件传送)的接受和拒绝，可以通 过单击“确定”1402来接受该文件传送请求，或通过单击“取消”1404 来拒绝该请求。
图15中，示出了在线计算机游戏建议消息1500的描述。建议的 始发者1502(用户A)想与参与者1506(用户A和用户B)玩专家级 的某一特定游戏(定约桥牌)。图15说明了建议消息如何显示给有机 会通过单击消息框底部的适当按钮来应答的用户B。如果用户B被该 建议所冒犯，那么可以通过单击“警告”按钮1512来记录这一冒犯。 如果用户B想接受所提出的建议，则应当单击“接受”按钮1514。如 果用户B根本不想打在线桥牌，则应当单击“拒绝”按钮1516(或者， 如果用户B不单击任何按钮，最终通过超时来拒绝该建议)。如果用户 B想玩但不同意一个或多个所示参数(例如，游戏1504，参与者1506， 类型1508，等级1510)，那么可以通过单击“修改”按钮以便允许用 户B提出一个反建议。
图16表示这种反建议框1600如何显示给想修改原建议的用户(即 图15和图16中所述例子中的用户B)。现在，始发者1602是用户B， 因为反建议作为一个新的建议，而用户B正在发出该反建议。应当注 意，由于这一反建议是同一汇集协商会话的一部分，因此，原建议的 Cookie将与反建议的Cookie相同。然而原建议的序号将等于1，而反 建议的序号将等于2。Cookie和序号都是软件参数，这些参数对参加 汇集协商会话的用户而言是透明的。
再参照图16，用户B同意与用户A打在线桥牌。然而，用户B 更喜欢一种不同类型1608的桥牌(加倍(duplicate)桥牌)而不喜欢 定约桥牌，而且用户B更喜欢中级1610而不喜欢专家级。因此，在将 发回给用户A的反建议消息框1600中修改了这些参数。然后，用户A 将有同样的应答选择(即，警告、接受、拒绝或修改)，并且，该汇集 协商会话按这种方式继续进行，直到出现下列三种情况之一时才结束： 接受(即，最近建议的接收者单击“接受”)，拒绝(即，最近建议的 接收者单击“拒绝”)，或取消(即，最近建议的发送方在发送了建议 后但在接收到应答之前通过单击“取消”按钮来取消)。
上述汇集协议的其他实现和使用方式也是可行的。总之，只要想 使两个或两个以上的用户或者两个或两个以上的客户计算机协商通信 或交互会话的参数，就可以使用这种汇集协议。例如，汇集协议可用 于电子商务应用中，以便买方和卖方对与商品、业务、证券或其他任 何有形或无形资产的报价表有关的价格或其他方面进行讨价还价。此 外，汇集协议还可以应用于协作项目开发环境(例如Lotus Domino)， 以便协商对文件等的改变。
这里所述的技术、方法和系统可以应用于任何可以交换、查看、 存取或以其它方式操纵电子内容的计算或处理环境。这里所述的系统 和技术的各种实现方式可以用数字电子电路来实现，或者用计算机硬 件、固件、软件来实现，或者用它们的组合方式来实现。利用这里所 述的一种或多种技术和方法的一种系统或其他装置可以实现成一种计 算机可读的存储介质，并配置以计算机程序，这样配置的存储介质使 得计算机系统以专门的预定方式来对输入进行操作和/或产生输出。这 种计算机系统可以包括一个或多个可编程处理器(这些处理器接收来 自数据存储系统的数据和指令，和将数据和指令发送到该数据存储系 统)，和一些合适的输入和输出设备。
每一计算机程序都可以用高级程序或面向对象的编程语言来实 现，或者，需要的话，可以用汇编或机器语言来实现；在任何情况下， 语言都可以是一种编译或翻译解释的语言。合适的处理器包括例如通 用和专用微处理器。
通常，处理器可以接收来自只读存储器和/或随机存取存储器的指 令和数据。适用于真实存放计算机程序指令和数据的存储器件包括所 有类型的非易失性存储器，其中包括：半导体存储器件，如EPROM、 EEPROM和快闪存储器件；磁盘，如内置硬盘和活动硬盘；磁光盘； 和CD-ROM盘。
上述任意器件都可以由专门设计的ASIC(专用集成电路)来补 充，或者可以用专门设计的ASIC来实现。
以上描述了本发明的一些实施方式。然而，应当理解，在不违背 本发明的思想和范围的前提下，可以作出各种修改。因此，其他实施 方式也在后面的权利要求书的范围内。