专利名称：管理计算机网络用户之间的协商的制作方法
技术领域：
本发明涉及管理计算机网络用户之间的通信。
背景技术：
因特网和万维网的迅速出现建立了这样一种环境，在这种环境中，世界各地的可以通过其个人计算机连接到因特网的人们一般都能访问通过网站提供的信息世界。电子邮件(也叫作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 LimitingOnline 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 InstantMessenger版本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来实现。
以上描述了本发明的一些实施方式。然而，应当理解，在不违背本发明的思想和范围的前提下，可以作出各种修改。因此，其他实施方式也在后面的权利要求书的范围内。
权利要求
1.一种计算机实现的有利于计算机网络用户之间的交互的方法，该方法包括将第一个用户的活动建议发送给另一个用户；该建议包括一个或多个描述所建议的活动的参数；接收来自该另一个用户的应答，这种应答包括接受、拒绝或反建议；和根据接收到的应答，有选择地参加活动。
2.权利要求1的方法，其中，所建议的活动包括聊天会话。
3.权利要求2的方法，其中，参数描述了聊天会话所针对的建议话题。
4.权利要求2的方法，其中，参数描述了进行聊天会话的建议信道。
5.权利要求1的方法，其中，所建议的活动包括在线游戏。
6.权利要求5的方法，其中，参数指定了参与所建议的在线游戏的建议参与者。
7.权利要求1的方法，其中，接受表示同意该建议的所有参数。
8.权利要求1的方法，其中，拒绝表示不同意该建议的至少一个参数。
9.权利要求1的方法，其中，反建议表示提出修改一个或多个建议参数。
10.权利要求1的方法，其中，参数完全描述了所建议的活动。
11.权利要求1的方法，其中，来自另一个用户的应答包括反建议，所述反建议包括一个或多个描述所建议的活动的参数，并且其中，反建议参数中至少有一个参数与建议的参数不同。
12.权利要求11的方法，还包括向反建议发出应答，该反建议应答包括接受、拒绝或第二个反建议。
13.权利要求12的方法，还包括反复应答进一步的反建议，直到出现接受或拒绝为止。
14.权利要求1的方法，还包括取消建议或反建议。
15.权利要求14的方法，其中，取消必须在接受或拒绝建议或反建议之前进行。
16.权利要求15的方法，其中，取消由发出该取消所应用到的建议或反建议的用户来发送。
17.权利要求16的方法，其中，取消包括一个取消理由。
18.权利要求1的方法，其中，应答还可以包括不理睬指示。
19.权利要求18的方法，其中，接收到不理睬指示表示拒绝建议或反建议。
20.权利要求18的方法，其中，用户以明确行动发出不理睬指示。
21.权利要求18的方法，其中，用户无行动地发出不理睬指示。
22.权利要求1的方法，还包括发送一个记录任何建议、反建议或接受所带来的不愉快的消息。
23.权利要求22的方法，其中，记录不愉快的消息包括“恶行”消息。
24.权利要求23的方法，其中，“恶行”消息累积地影响接收者使用计算机网络的能力。
25.权利要求24的方法，其中，累积影响按指数形式增长。
26.一种计算机实现的为涉及两个或两个以上计算机网络用户的在线活动形成一个最佳环境的方法，该方法包括允许第一个用户将在线活动建议发送给一个或多个其他用户，该建议指定了与所建议的在线活动有关的参数；和使第一个用户与一个或多个其他用户能够协商该建议的参数，直到达成一致意见为止。
27.权利要求26的方法，其中，在线活动包括一个或多个以下活动交换话音消息、玩在线游戏、寻找一个客户计算机到另一个客户计算机的路由、传送文件、直接即时消息发送、交换图形表达方式或加入聊天室。
28.权利要求26的方法，其中，在线活动包括电子商务。
29.权利要求26的方法，其中，在线活动包括合作开发项目。
30.权利要求26的方法，其中，允许第一个用户发送建议可利用协商协议来实现。
31.权利要求26的方法，其中，协商建议的参数包括有选择地交换一个或多个反建议消息，直到出现接受或拒绝为止。
32.一种有利于计算机网络用户之间的交互的协商协议，这种协议包括建议消息类型，它包括一些描述所建议的活动的参数；接受消息类型，它表示同意建议的所有参数；拒绝消息类型，它表示不同意建议的至少一个参数；和取消消息类型，用于撤销前一建议消息中所发出的建议。
33.权利要求32的协商协议，其中，建议消息类型可用来根据接收到的建议消息发出反建议消息，反建议消息包括至少一个与建议消息的参数不同的参数。
34.权利要求32的协商协议，其中，建议、接受、拒绝和取消消息类型可以用来协商一个或多个以下活动的参数交换话音消息、玩在线游戏、寻找一个客户计算机到另一个客户计算机的路由、传送文件、直接即时消息发送、交换图形表达方式或加入聊天室。
35.权利要求32的协商协议，其中，拒绝消息类型表示所建议的活动未获与该建议的接收者相关的客户计算机支持。
36.权利要求32的协商协议，其中，拒绝消息类型表示所建议的活动遭该建议的接收者拒绝。
37.权利要求32的协商协议，其中，拒绝消息类型表示该建议的接收者明确地不理睬该建议。
38.权利要求32的协商协议，其中，拒绝消息类型表示该建议超时。
39.权利要求32的协商协议，其中，拒绝消息类型表示该建议消息无法被理解。
40.一种基于计算机的有利于计算机网络用户之间的交互的系统，该系统包括两个或两个以上的客户计算机，这些客户计算机具有允许不同的用户相互交互的软件；和各客户计算机都支持的协商协议，这种协议允许用户协商在线活动的参数。
41.权利要求40的系统，其中，客户计算机中的软件允许用户在一个或多个以下活动中进行交互交换话音消息、玩在线游戏、寻找一个客户计算机到另一个客户计算机的路由、传送文件、直接即时消息发送、交换图形表达方式或加入聊天室。
42.权利要求40的系统，其中，客户计算机软件包括即时消息发送客户应用程序。
43.权利要求40的系统，其中，协商协议包括下列消息类型建议消息类型，它包括一些描述所建议的活动的参数；接受消息类型，它表示同意建议的所有参数；拒绝消息类型，它表示不同意建议的至少一个参数；和取消消息类型，用于撤销前一建议消息中所发出的建议。
44.权利要求43的系统，其中，在用户之间交换协商协议消息，直到相互都同意了在线活动的参数。
45.权利要求40的系统，还包括一种软件实现的机制，用于记录协商会话期间用户行为所带来的不愉快。
46.权利要求45的系统，其中，记录不愉快的机制使得一个用户可以影响另一个用户访问系统资源的能力。
47.一种计算机协议过程，用于在包括第一个用户和第二个用户的两个或两个以上在线计算机用户之间进行协商，其目的是为了在具有规定特性的环境中参加相互都满意的在线活动，该过程包括(a)由第一个用户向第二个用户发出一个建议消息，该建议消息规定了第一个用户所希望的特定环境特性；(b)由第二个用户向第一个用户发出第一应答，该应答包括表示同意该建议的接受消息，表示不同意该建议的至少一个方面的拒绝消息，或提出改变该建议的一个或多个方面的反建议；(c)如果第二个用户发出反建议，那么由第一个用户向第二个用户发出第二应答，该第二应答包括表示同意该反建议的接受消息，表示不同意该反建议的至少一个方面的拒绝消息，或提出改变该反建议的一个或多个方面的另一个反建议；和(d)重复步骤(b)和(c)，直到出现接受、拒绝或取消为止，取消表示撤消建议或反建议。
48.一种计算机实现的有利于计算机网络用户之间的电子商务交易的方法，该方法包括将第一个用户的电子商务交易的建议发送给另一个用户；该建议包括一个或多个描述所建议的交易的参数；接收来自该另一个用户的应答，这种应答包括接受、拒绝或反建议；和根据接收到的应答，有选择地完成所提出的交易。
49.权利要求48的方法，其中，电子商务交易包括商品/业务的销售/购买。
50.权利要求48的方法，其中，电子商务交易包括无形资产的销售/购买。
51.权利要求48的方法，其中，建议的参数包括价格、交付细节、型号、规格、颜色和担保细节。
52.一种明确包含在计算机可读介质中或传播载波信号中的计算机软件，用于有利于计算机网络用户之间的交互，这种软件包括一些可使计算机系统执行下述操作的指令允许第一个用户将在线活动建议发送给一个或多个其他用户，该建议指定了与所建议的在线活动有关的参数；和使第一个用户与一个或多个其他用户能够协商该建议的参数，直到达成一致意见为止。
全文摘要
在包括第一个用户和第二个用户的两个或两个以上在线计算机用户之间进行协商，其目的是为了在具有规定特性的环境中参加相互都满意的在线活动(例如，即时消息发送，在线游戏，聊天室，电子商务)，这种协商过程可按以下步骤来实现(a)由第一个用户向第二个用户发出一个建议消息，该建议消息规定了第一个用户所希望的特定环境特性；(b)由第二个用户向第一个用户发出第一应答，该应答包括表示同意该建议的接受消息，表示不同意该建议的至少一个方面的拒绝消息，或提出改变该建议的一个或多个方面的反建议；(c)如果第二个用户发出反建议，那么由第一个用户向第二个用户发出第二应答，该第二应答包括表示同意该反建议的接受消息，表示不同意该反建议的至少一个方面的拒绝消息，或提出改变该反建议的一个或多个方面的另一个反建议；和(d)重复步骤(b)和(c)，直到出现接受、拒绝或取消为止，取消表示撤消建议或反建议。协商会话期间一个用户的不规矩行为可遭到其他用户的反对，从而潜在地影响这个用户使用系统资源的能力。
文档编号A63F13/10GK1478352SQ00813518
公开日2004年2月25日 申请日期2000年8月4日 优先权日1999年8月4日
发明者哈里·W·莫里斯, 哈里 W 莫里斯, G 沃特金斯, 罗伯特·G·沃特金斯 申请人:美国在线服务公司