CN1360782A - 在不同网络的匿名用户之间智能建立会话的分布式系统 - Google Patents

Abstract

一种网络为用户提供一种简单安全的方式与其它用户或服务建立通过IP网络或例如PSTN的其它网络运行的通信会话。某种意义上,该网络可以安排两个或更多用户(例如人)和/或服务之间的通信服务。提供了多个不同的服务器群集,且每个群集可链接在一些。在一些实施例中,每个群集包括多个服务器。用户在某一特定群集中注册并被赋予唯一的系统/网络ID。在一些实施例中,消息不是在用户间直接发送,而是通过其中一个用户的服务器上提供的至少一个中间路由服务(RS)来发送。因此,在一些实施例中,用户可以使他/她的个人信息对其它用户隐藏或屏蔽,即使是在与其它用户进行通信时也可以如此。在一些实施例中,用户可与另一用户建立会话而无需知道另一用户正在使用的客户设备(例如,PC、移动电话等),这是因为所述网络安排用户间的通信(例如文本聊天会话、语音聊天会话(PC对PC、PC对PSTN或者PC对移动电话)、万维网会议或寻呼(PC对PC、PC对SMS)),而不管被呼叫用户正在使用的客户设备。因此,网络允许用户间的任何一个上述通信服务,并且发起用户无需知道另一用户当前是通过他/她的PC联机,还是可通过寻呼机或移动电话被联系。

Description

这是1999年5月10日提出的美国临时专利申请顺序号No.60133401继续，通过引用将其公开结合在此，并因此要求其优先权。

在不同网络的匿名用户之间智能建立会话的分布式系统

发明领域

本发明涉及随用户可用性而变的所述用户之间、及所述用户和通信设备之间或通信设备之间建立通信会话的一种系统及相应方法。

发明背景

使用通信工具(例如，移动电话、PC、电子邮件等)的用户一般面临两个基本任务：确定要与其进行通信的其它用户的设备地址，并建立与该设备的通信会话。视用户正在使用的设备而定，这些任务一般会有所不同。例如，在具有消息接发能力的移动电话上，用户通常通过在其本机地址簿中找到其它用户来确定用户位置，然后通过电话拨打那个用户的电话号码来与那个用户建立语音会话，或者键入短文本消息(STM)并发送该消息给其它用户，短文本消息可发送到其它用户的移动电话或电子邮件。视被叫方电话营运商而定，他/她可以或不可以接收这些呼叫。

作为另一个示例，使用基于PC的文本聊天软件的某个用户可以有其它用户的列表，该列表中的其它用户可以启动与这个用户的聊天会话。然而，他们仅在它人登录时才可实现此操作；在它人注销后，他们无法确定如何与它人取得联系，也无法使它人意识道有人在尝试与他取得联系。

因此，要解决的问题可能包括任一或所有下述问题。如何不依赖于设备而使联系信息可用并可集中配置，并向用户提供用于所有通信的单一地址。如何告知用户可参加某种通信会话。如何不依赖于设备地启动与另一用户的通信会话(即联系)，并因此无需知道所述联系的任何设备地址。如何在采取或不采取直接干预的情况下，使用户可集中控制应如何处理发送给他们的呼叫。在主叫方和被叫方设备位于可能由不同服务提供商运营的不同网络时，如何确保这些功能的互操作性。如何防止其它用户更改用户的联系信息或路由设置，或以其它方式模仿另一人。如何允许用户在中心位置阻止讨厌的人与他/她联系。如何使一个以上的组织/公司/营运商以有效和/或可互操作的方式提供在此描述的服务。

SS7系统在设置电话呼叫时允许路由判定中的智能(例如参见贝尔通信研究所(Bell Communications Research)首创的智能网络(IN)体系结构)，其中用于呼叫的服务逻辑与交换设施分开，从而允许添加或更改服务而无需重新设计交换设备。称为高级智能网络(AIN)的更新版IN引入了服务独立体系结构的概念，其中，根据诸如日时、主叫方身份、呼叫类型等因素，电话号码的给定部分可由不同服务作不同解释。AIN使添加新服务变得简单，而无需安装新的电话设备。

统一消息接发系统允许用户基本上提供一个用于各种通信选项的地址，选项一般包括电话呼叫、语音邮箱、传真和电子邮件。所有消息一般存储在一个中央收件箱中，用户可从不同设备访问该收件箱，有时可使用媒体转换(例如，将文本消息转换成语音)。这有效地减少了用户需要给出的设备地址数。有许多公司在用统一消息接发产品。

许多公司创建了运行在因特网之上的网络，允许用户互相发送短文本消息并监视其它用户的状态，这里，状态通常定义为用户当前是否连接到网络。这种功能当前被视作称为IMPP(即时消息接发与出现协议(Instant Messaging and Presence Protocol))的IETF标准。

会话开始协议(Session Initiation Protocol)(SIP)正在成为IETF标准的过程中，并已被定位为基于IP的网络中的SS7的继承者。该协议基本上允许用户邀请其它用户通过因特网进行任意通信会话，并同时允许这些邀请的任意路由。

用于SS7中的上述IN和AIN方法受限于电话网络，且不易于延伸到诸如因特网的其它网络。因此，没有简单的方式可通告其它用户进行通信的可用性；除通过有限的接口外，也没有简单的方式可供用户配置其路由。即时消息接发系统一般仅限于基于IP的系统，且通常不允许跨越不同的网络进行通信。大多数这样的系统依赖于要连接到系统的用户，以便使其路由有效，并且它们向其它用户公开网络地址，这可能会成为一个安全隐患。此外，大多数系统依赖集中式体系结构，这会使得在许多提供商中分布用户数据库和业务变得困难。

通常，许多系统着手解决上述部分问题。然而，技术上需要用于以更全面的方式处理上述一个或多个问题的系统/网络和相应方法。

发明概要

一种系统包括松散联合的服务器群集的网络，及连接到群集的任意多的客户终端(即客户)。终端/客户可以是在某一操作系统下运行的软件实体，也可以是在可访问群集的某一通信网络上运行的任何其它设备。用户在某一特定群集中注册，并被赋予唯一的用户ID。此用户ID与群集ID(CID)一起形成了整个系统中全局唯一的用户ID(UID)。用户可以是指人或通过某一客户终端或通过其它方法/系统连接到群集的任何其它实体。终端可以访问群集中运行的任意多的服务，或访问在其它群集中运行的服务(“服务”是可具有任意功能的软件实体)。终端与群集间的连接是安全的，并且在一些实施例中可使用加密。

可以在每个群集中提供的基本服务包括例如：1)动态用户属性，称为联机状态或用户的“出现”，它允许用户和客户在中心定义和修改链接到所述用户和客户的数据点；这些改变可以手动(明确由用户进行)或自动(由某一客户或服务器端逻辑进行)的；2)联系列表和联系通知，它允许用户预订并被通告其它用户的联机状态，和/或被通告其它用户的出现信息的变化；以及3)路由服务，它允许用户向其它用户发送通信会话请求(即邀请)，以及对如何根据用户的当前出现信息来处理这些邀请进行配置。

路由服务允许用户向其它用户发送邀请来建立通过任意网络的任意通信会话(例如，文本聊天会话、语音聊天会话、万维网会议等)。请求不是直接在用户间发送，而是由发送/邀请用户的路由服务把邀请发送给接收用户的路由服务。接收用户的路由服务按照相同接收用户指定的逻辑来确定如何处理请求及什么服务可用于处理请求。例如，接收用户的路由服务可将邀请转发给接收用户的客户，可忽略邀请，可将邀请转发给接收用户的移动电话，或者可将邀请转发给接收用户的收件箱以便该用户以后读取该邀请。

群集与群集中的服务对要建立的会话进行必要的最低设置，这样，无需在用户间交换网络地址，因此保留用户的匿名。由于用户可以是软件实体及人，因此系统允许在用户和任意数据服务之间的通信会话。在一些实施例中，系统不需要运行所有用户的中央数据库，而是群集可将请求转发给其它群集，并因此确保系统中所有群集的连接性。

本申请为用户提供了伙伴列表(buddy list)(即联系列表)。用户可将其它用户添加到此列表并将它们分成组。利用本申请，用户可以知道他/她的伙伴列表(即，联系列表)中用户的联机状态，并在这些用户状态改变时得到通知。此外，用户可设置他/她自己的联机状态，使他/她自己不被讨厌的用户看见，并通过简单双击便可向他/她的伙伴列表中的用户发送任何种类的消息。

在一些实施例中，消息不是在用户间直接发送，而是通过至少一个在其中一个用户的服务器上提供的中间路由服务(RS)来发送。因此，在一些实施例中，用户可将他/她的个人信息隐藏或屏蔽，不让其它用户知道，即使是他/她在与其它用户进行通信时也可以如此。在一些实施例中，用户可与另一用户建立会话而无需知道另一用户正在使用的客户设备(例如，PC、移动电话等)，因为网络安排用户间的通信(例如，文本聊天会话、语音聊天会话(PC到PC、PC到PSTN或者PC到移动电话)、万维网会议或寻呼(PC到PC、PC到SMS))，而不管被叫用户正在使用的客户设备。因此，网络允许用户间的任何一个上述通信服务，并且发起用户无需知道另一用户当前是否通过他/她的PC联机，或者是否可通过寻呼机或移动电话与另一用户取得联系。

附图简述

图1是按照本发明一个实施例的多个连接在一起的服务器群集的示意图。

图2是按照本发明一个实施例的图1中群集的其中一个的示意图。

图3是按照本发明一个实施例的的功能图，说明第一用户(具有客户A，诸如PC)如何向另一用户(具有客户B，诸如PC)发送邀请消息，其中客户B的路由服务将邀请消息转发给客户B。

图4是按照本发明一个实施例的功能图，说明第一用户(客户A)如何向另一用户(客户B)发送邀请消息，其中，因为客户B的客户未联机，因而客户B的路由服务将邀请转发给客户B的移动电话。

图5是按照本发明一个实施例的功能图，说明第一用户(客户A)如何向另一用户发送邀请消息，该另一用户是诸如软件实体的服务，其中该软件实体的代理或路由服务将所述消息转发给软件实体，以便可以在第一用户和软件实体间设置通信。

图6是按照本发明一个实施例的功能图，它说明用户间的连接可通过群集转发。

图7是按照本发明一个实施例的客户示例性方面的视图，象用户的显示屏(例如，PC显示器)上呈现的那样，其中，客户应用程序在启动时会提示用户输入用户名称、密码和/或服务器地址，输入后，客户可连接到相应的用户服务器并与其建立安全通信。

图8说明按照本发明一个实施例的用户的示例性联系列表，象在用户的终端/客户的显示屏上呈现的那样。

图9说明多个不同类型邀请消息的菜单列表，用户可从中选择发送给另一用户的消息类型，此图说明按照本发明一个实施例的在用户的终端/客户的显示屏上呈现菜单列表的方式。

图10是按照本发明一个实施例的功能图，说明每个营运商如何可以运行一个或多个群集，其中，每个群集可与另一个群集通信，以便可从一个群集上的用户发送邀请/消息/数据给另一个群集上的用户。

图11是说明服务结构的功能图(例如，在各个服务器之间、服务器与各个客户和数据库之间的通信链接)。

图12(a)是按照本发明一个实施例的说明图11的示例性映射功能如何运行。

图12(b)是按照本发明一个实施例的说明赋予用户的用户身份(UID)，该身份可适用于整个应用或系统/网络。

图13是按照本发明一个实施例的功能方框图，说明图11中群集的示例性部件，还说明群集如何可与诸如客户、其它群集和/或因特网的其它实体进行通信。

图14是按照本发明一个实施例的流程图，说明某个用户向另一个用户发送邀请消息时所采取的步骤。

图15是按照本发明一个实施例的流程图，说明某个用户(例如，Carl)设置与至少一个其它客户(例如，Anne)的聊天会话时所采取的步骤。

图16通过用户服务说明按照本发明一个实施例的在用户服务器上的示例性数据结构。

图17说明按照本发明一个实施例的用于示例性连接服务器上的联系状态服务的示例性数据结构。

图18a说明按照本发明一个实施例为联系列表服务所存储的数据结构，该数据结构可存储在数据库中并在需要时被检索。

图18b说明按照本发明一个实施例的用户简档的数据结构。

图19是按照本发明一个实施例的说明用户(或用户的客户)的登录过程或顺序的示意图。

图20是按照本发明一个实施例的说明用户(或用户的客户)的注销过程或顺序的示意图。

图21是按照本发明一个实施例的说明联系B1的登录/注销过程或顺序的示意图，其中用户或用户的客户可监视联系B1，并知道该联系何时变为联机及何时注销。

图22是一个示意图，说明将联系添加到用户的联系列表或从中删除联系的用户或客户过程期间所采取的步骤。

图23是一个示意图，说明在将另一用户添加到用户的看不见列表(blinder list)或从中删除另一用户的用户或客户过程期间所采取的步骤。

图24是一个示意图，说明按照本发明一个实施例的用户转化他/她的看不见用户列表时所采取的步骤(即消息顺序，所述顺序类似于用户被添加到看不见列表的顺序)。

图25是一个表，说明按照本发明一个实施例的用于联系列表功能的数据库操作的总结(例如，查询数据库)。

图26说明按照本发明一个实施例的管理工具/服务的位置和/或功能。

本发明一些示范实施例的详细说明

在下述说明中，为说明目的而不是限制，阐明了特定的细节，诸如特定的实施例、网络体系结构、信令流、协议、技术等，以便于理解本发明。然而，本领域的技术人员明白，可在脱离这些特定细节的其它实施例中实施本发明。在一些示例中，对众所周知的方法、接口、设备、协议和信令技术的详细说明从略，以免不必要的细节使本发明的说明不明显。

首先，要指出的是，在大多数情况下软件设计图中的符号符合UML(统一建模语言)标准。相同的符号用于数据图和类图。读者因此应注意是否正在描述数据结构或常规类。在高级顺序图中，单箭头用于无应答的消息，而双箭头用于在来回通信的具体细节不重要情况下的请求-应答消息对。

在即时应用的环境，熟悉附图及一些术语会有所帮助。因此，下面阐明多个定义，这些定义用于本申请及由此得到的专利。

在此使用的一些术语的定义/词汇表

“共同体”：某用户可通过他/她的应用程序与其相互作用的一组用户。可以有许多不同的共同体，或者可以有单个全局共同体。这由服务器被分组在一起的方式以及用户连接到哪些服务器来定义。

“应用”：这指本发明的整个系统/网络，包括做为一个整体的客户端软件、服务器端软件、储存的数据以及此系统的功能性。

“客户”：用于从客户或用户端访问应用的软件。

“后端”：给定客户直接或间接连接的服务器、网络和软件的集合(即其本地群集、加上本地群集连接的任何群集)。

“群集”：连接到高速、可靠和安全网络的服务器加数据库的集合。后端是互连的群集的集合。

“本地群集”：给定客户直接连接的群集。

“用户”：通过客户访问应用的实体、人或软件。

“框架”：后端服务器公用的应用框架。

“服务”：服务是驻留在例如服务器上的软件实体，它为服务器的客户提供一组功能。它提供的该组功能由协议说明指定，该说明以非模糊方式定义了如何使用服务。

“服务创建者”：编写服务程序的程序员。

“客户应用者”：用于程序员的术语，所述程序员对后端系统创建客户。

“消息”：从一个用户发送到另一用户的一条信息。

“控制消息”：从客户发送到服务器、从服务器发送到客户或者在服务器之间发送的一条信息。控制消息用于访问系统中其它部件的功能性。

“请求”：由客户启动并发送给服务器的控制消息。

“应答”：从服务器发送到客户以应答请求的控制消息。

“通知”：由服务器启动并发送给客户的控制消息。

“响应”：从客户发送到服务器以响应通知的控制消息。

“通信模式”：用于实时通信的方法，例如此文中用于语音通信的方法。

“谈话”：实时进行的两个或更多用户间的对话。

“消息类型”：消息中发送的信息类型，例如短文本消息。

“CS”：连接服务器，这可以指服务器软件和/或运行该软件的机器。具体指代应参照上下文理解。

“DB”：关系数据库，最好包括运行它的机器。

“UMF”：用户映射功能，这在概念上是单一的实体，但实际应用在每个CS、US和ICS，因此可为多个实体。UMF虽然可以存储在其它部件中，但最好存储在DB中。

“GRID”：用于联系列表中联系的组标识符。

“CID”：群集标识符。

“ICS”：群集中服务器，可指服务器软件和/或运行它的机器。具体指代应可参照上下文理解。

“ICSID”：群集中服务器标识符。

“UID”：用户标识符。

“US”：用户服务器，可指服务器软件和/或运行它的机器，具体指代应可参照上下文理解。

“USID”：用户服务器标识符。

“消息储存库”：一种实体，它可代表用户接收一种或多种类型消息并至少在用户检索前将它们存储，例如传真机。

“设备”：一种实体，它可作为一个或多个谈话端点或作为用于一种或多种消息类型的消息储存库，或两者均可。并且，设备可发送一种或多种类型的消息。GSM电话是它的一个示例，它是短文本消息储存库及语音谈话的谈话端点。

“简档”：一组路由，其中每个路由可用于伙伴/联系列表中定义的一个用户或用户组。对于每个用户，每种通信模式均有一个路由，在这种意义上，简档是完整的。

本发明的示例性实施例说明

按照本发明一些实施例，系统/网络包括多个客户应用程序(例如可由各个用户操作的Win32)以及具有多个群集的后端服务器系统(例如运行在Windows NT上)。一个主要功能是为用户提供一种简单安全的方式来与其它用户或服务建立通过IP网络或诸如PSTN的其它网络运行的任意通信会话。它也为营运商(营运商是运行或管理至少一个群集者)提供一个综合环境，在该环境中向其用户配置增值服务(例如搜索引擎服务、数据库服务、购物服务、用于向用户发送诸如股票价格的股票信息的服务、使用户可通过在应用外的视频会议服务器设置视频会议的视频会议服务等)，并能够对用户的使用进行收费，也为他们提供了一种方式通过IP网络来链接其安装的服务基础。基本上，系统/网络的环境是作为中介服务，且可以安排两个或更多人(或其各自的客户/PC/电话)之间的通信服务，以及安排对增值服务的访问，增值服务是指基于通信的一些服务，而不是其它服务。对服务的访问可通过在不同操作平台上运行的轻量客户来提供，也可通过基于浏览器的服务器的网关来提供，诸如WAP(无线应用协议)。以系统/网络的用户管理功能、安全、验证和收费特性作为其基础，系统/网络被设计成使增值服务(VAS)的构建和操作变得容易。由于系统/网络被设计成提供可达性和移动性，因此用户将能够从实际上任一通信设备—计算机、移动电话、手持设备等—访问他/她的数据或服务，确保广泛触及系统/网络的增值服务。

图1说明可互相通信的系统/网络的多个群集，而图2说明图1实施例中的示例性群集1。参照图2，系统/网络的基本设备包括多个互连的服务器3，每个服务器运行多个服务5。这样的服务器的集合称为群集1，如图2所示。群集1定义了服务5的地址空间，并提供服务彼此连接的低级连接性，以及与外部服务器的连接。通过一些众所周知的构建于一般流模型之上的协议，每个服务可提供对其功能性的访问。因此，一个服务可根据名称请求另一个服务，并使用服务特定协议与其建立连接。

外部用户7和其各自客户11(例如，用户的PC、移动电话和/或PDA)可通过特殊连接服务连接到群集中的服务，该特殊连接服务一般在群集的防火墙9的边界的服务器(连接服务器)上运行，并收听特定端口上的连接。在一些实施例中，通过所述服务建立的流是安全的并且被加密，例如在Win32客户情况下使用SSH2.0协议。同样，群集1连同所有被连接的用户7和客户11可以形成虚拟专用网，其中可以自由建立服务间的连接。如图1所示，也可在不同群集1的服务和/或用户7之间建立连接。这样的连接将通过特殊的群集间的服务，这可以限制实际可用的服务。在本发明的最佳实施例中，群集之间的连接也是安全的并且被加密。

所述体系结构之外的其它服务器和软件也可形成设备的组成部分。同样，它们被视为群集的一部分，示例为健壮数据库13(例如，Oracle 8)和不同的操作与维护工具，服务器3、用户7和/或客户11可与所述工具进行通信。

一些服务器3一般被设置有给定配置的服务，并且这些服务器有时可按某给定名称来访问，例如，如下文所述，运行用于外部客户的连接服务的服务器称为连接服务器，虽然它们与其它服务器在体系结构上并无不同。

在本发明的一些实施例中，群集1在默认情况下将运行一组基本服务。在示例性实施例中，这组基本服务可提供以下特性：1)允许每个用户(或用户的客户)7在所有群集中具有唯一身份；2)通过使用所述身份，为每个用户7提供连接群集1并由群集1安全验证的能力；3)为每个用户7提供定义与该身份相关任意数据集的能力(此数据持续存在或存储于数据库13中，且此数据在此称为用户的“出现”数据)；4)为每个用户7提供将与其身份相关的动态状态信息和/或出现信息公布的能力(简单的情况下，此状态或出现可以是用户当前是否在他/她的PC上联机)；5)为每个用户7提供监视给定组的其它用户7(在相同或不同的群集中)的状态/出现，以及被通告其任何变化；以及6)为每个用户7提供使用按名称或其它有用准则的查询来查找其它用户身份的能力。

参照图3-6，系统/网络的一个功能是为用户7提供与其它用户7建立任意通信会话的可能性。不同类型(如语音或文本)的通信可在不同实施例中建立。系统/网络使用“邀请”来处理相互通信信道的初始发现。此处，“邀请”也可指邀请消息或INVITE，为简单起见而称为“邀请”。

邀请基本上是一个用户7向另一用户请求以某一给定类型的通信加入他/她。在一些实施例中，这些邀请的格式可遵循称为SIP(会话启动协议)的IETF标准。客户11一般将支持某一给定的通信类型集，并将知道如何创建每种类型的SIP邀请。当用户7想与另一用户建立通信时，他/她将调用其客户11种的某一功能，请求客户向某一被选用户发送给定类型的邀请。用户的客户11则将形成正确的SIP消息并将该消息发送给群集中的特定服务，称为路由服务(RS)。在一些最佳实施例中，每个在其用户服务器(US)上具有特定路由服务。

在一些实施例中，路由服务(RS)是在收到消息的情况下被调用，但也许是在发送用户的情况下被调用。RS的一个功能是决定如何处理邀请消息。这样，消息从不在用户间直接发送，而是始终从一个用户到另一个用户的路由服务(RS)。路由服务的判定逻辑对用户而言是本地的，因此可由用户7按照用户的需要来编程，而且虽然它通常受到能以一种简单方式将其控制的用户需要限制，但它的复杂度仍可根据需要设计。无论逻辑怎样，路由服务均可以执行两个操作而结束：忽略邀请，或者将邀请转发到接受给定通信类型邀请的某一其它服务。接受邀请的服务称为设备处理程序。在本发明的一些实施例中，客户11是示例性类型的设备处理程序。

设备处理程序是一个通信端点，路由服务可将邀请发送到该端点。设备处理程序专用于连接其它网络。例如，要将文本寻呼(textpage)法送到移动蜂窝电信网络，接受文本寻呼的设备处理程序被安装，它查找接收方移动号码，然后将所有相关信息发送到某一标准寻呼网关，如SMS网关。另一方面，设备处理程序可允许电话呼叫。当前有两种这样的设备处理程序可供使用：一种是连接爱立信IP电话(Ericsson IP Telephony)系统，因而使得语音聊天(Voice Chat)邀请可在PSTN网络上结束。另一种设备允许文本寻呼路由到GSM网络。所有的服务和设备处理程序均可访问数据库中的管理信息，例如，用于检查用户的帐户及使用特定服务的许可。这允许在数据库中服务计帐集中化。使用服务SDK，可容易地在系统中创建并部署服务。这样，对路由到新网络或现有服务的支持可容易地添加到系统。

参照图3，第一用户A(具有客户A)要向用户B(具有客户B)发送邀请消息。如设备处理程序所示，连接的客户11可作为一些类型的邀请的合格端点将自己呈现给用户B的RS。例如，如果用户A如图3所示向用户B发送文本聊天邀请且用户B配置了他/她的RS，这样，当他/她连接到群集时，所有邀请应转发到他/她的客户11，用户B的RS相应地发送邀请消息，且邀请在用户B的客户11结束，用于用户B访问。这种情况下，假定在用户B的客户11上存在将接受并处理此特定邀请的某一代码。

如图4所示，在其它示例中，设备处理程序不是用户的客户11，而是在群集中运行(例如在服务器或其它设备上)的实际服务10。这些服务10一般连接一些外部设备或网络12(例如电话或其它网络)，将邀请转换为适合于所述设备或网络12的任何信令协议。在图4中，用户B已指示：当用户B不联机时，他/她的RS将邀请消息转发到他/她的移动电话14。因此，用户B的RS将邀请消息转发到连接外部蜂窝电信网络(例如GSM)的服务10，这又使该消息转发到网络并最终到用户的移动电话14。这样，设备处理程序10可将邀请转换为到用户的实际电话呼叫。

如前面所述，邀请机制不限制路由服务(RS)安排的通信类型。实际的通信类型可能仅受用于处理它们的设备处理程序10(和/或客户设备11)的限制。另一用户希望如此。在一些实施例中，会话协商并不隐含地涉及到交换用户的网络地址，诸如IP号或电话号码。此方法的优点包括保密性及用户无需担心如何联系其它用户这一事实。从用户7给出一个邀请，被叫用户7(即被叫方)的路由服务(RS)将决定应如何处理此邀请，而呼叫用户7(即主叫方)无需知道用户之间的通信信道如何设置及在什么网络上。这样，例如，语音会话可能在电话系统中结束，而呼叫方对此不知晓。然而，网络地址是否实际上结束交换以及是否可以在路由协议和/或应用框架控制之外，这由所调用的实际通信逻辑确定。因此，在本发明的一些实施例中，有关是否应为所有通信类型维护用户匿名性的决定由操作群集的营运商确定。

如上所述，可通过使用作为特定类型服务的设备处理程序来延伸群集1的功能。它们是可添加到群集的附加服务的简单示例。从体系结构的角度来看，假设有适当的SDK，对何种服务可添加到群集并无限制。这开辟了用于创建可能连接一些对应客户模块的复杂增值服务的通路，提供了上述基本服务之外的功能。

参照图5，通过使用专门的客户10，产生附加服务16的另一入口点。这些是实际上使用客户/服务器协议来表明其自己为系统中任何其它用户的服务16。此类“人工”用户16称为代理。从用户的角度来说，代理看上去象任何其它的用户，即他/她可监视其状态并向它发送邀请。不同之处在于：当在用户7与代理16之间建立通信时，它实际上是用户和某一软件实体之间的相互作用形式。通信的类型可以为语音或文本类型，但更可能为代理和用户的机器上安装的某一专门的客户软件之间的某种定制数据通信。此类型的延伸性允许新颖有趣的服务。

如上所述，许多服务可提供对收费资源的访问，诸如电话系统、蜂窝电信网络、联机购物网络等。这需要一种控制用户7访问这些资源的方法及监视这些资源使用的方法。在一些实施例中，按照本发明的系统/网络可支持用户帐户类型的概念，其中每个帐户类型提供对某组服务的访问。这样，可容易地管理对服务使用的控制。对于更详细的收费，每个服务可相应地定义其自身的计张政策与条例。一些服务可能选择只记录所有活动以便将来计算，而其它服务可能动态监视用户及其当前帐户状况，如果信用降为零，则可能会终止会话。

参照图6，由于用户7具有全局唯一身份，用户之间的连接可以通过群集1转发(即从一个群集1到另一群集1)。这可通过专用服务，即通过群集间服务来完成，该服务担当不同群集中服务之间的代理。从所涉及服务的角度来看，该代理最好是透明或基本透明的。仅有的限制是群集营运商可配置群集间服务，以便仅允许远程访问有限的服务组。因此，营运商特定增值服务可安排专门用于给定群集。

在用户7看来，客户11对用户来说是一个小的难以觉察的应用程序，它在用户的PC上以封闭形式显示为桌面上的小球。如图7所示，用户7启动应用程序后，他/她被提示要求输入其用户身份，该身份包括到其营运商的地址和要安全验证的密码。此时，客户11连接到相应服务器3并与之建立安全连接。连接经严格验证，并也可能使用已知加密技术进行了加密，因而不会因恶意攻击而被破坏。

如果登录成功，所述球会被打开，显露多种功能并显示用户/客户可使用的功能。已知一个这样的功能为联系列表(例如，图8示出这样的一个列表的一部分)。此列表由用户维护，并可以包括诸如用户知道并与其联系过的其它个人，以及任选地包括其它用户的地址或ID。在一些实施例中，该列表可显示这些其它用户的联机状态。此状态反映给定用户当前是否登录到系统，从而给出是否可立即和该用户7取得联系的信息。实际上，用户可指定可能状态的范围，例如，通知其它用户自己确实联机，但希望不被打扰或暂时没空。通过定义文件夹可容易地组织该列表，也可从不同显示模式进行选择。用户可以输入新的联系，其方式是通过键入联系的系统/网络身份(用户ID或UID)(如果知道的话)，或者在目录服务中启动搜索，其中可以按诸如名称、电子邮件等准则的各种准则进行搜索。图12(b)示出分配给用户的示例性UID。

通过使用附加SDK，可以开放客户11的体系结构。这允许开发者将新的通信模块类型添加到客户，例如建立与某一远程服务的数据通信会话。这样，客户可用作更复杂应用的基础，但仍可从基本客户提供的整个下层用户和安全模型中获益。客户/服务器协议也可用于创建完全新型的客户类型，允许开发者将表明自己为用户的服务集成到其它用户。最好由客户使用的安全协议是SSH(安全外壳协议)，一般被认为该协议是当今最先进的协议之一。它使用一般在大多数防火墙上开放的专用端口号22。对于由外接附件建立的通信会话，安全问题由附件开发者和使用的通信协议决定。登录用户专用的所有信息，如其联系列表和收件箱，均在客户机器上被隐藏并被加密，从而使频繁用户的网络业务量最小。客户是完全可定位的，并可以共同标记(co-branded)用于特定营运商。

关于服务器3，按照本发明一个实施例的示例性服务器设置包括服务器3的网络和一个数据库13。这样的最小设置称为群集，并提供系统/网络的小管理结构。每个服务器3可配置成运行一定配置的服务。每个这样的服务是本发明的系统/网络的某一组成部分，或者是营运商安装的某一其它服务。其中一个可用的基本服务是处理客户11对群集1访问的连接和验证服务。这是从IP网络到群集的单一访问点，并且群集应另外被视为在可信或安全的LAN中运行。通过添加运行此服务的更多服务器3，可扩大整个群集以处理可能大量的同时连接。另一组服务与用户7相关，并处理信息请求、联机状态传播及邀请的路由。而且，可通过添加运行这些服务的更多服务器3来扩大这些功能。最后，特定服务处理与其它群集的连接，因而允许不同群集和提供商的用户进行通信。下面将更详细地论述服务器3的链接。

群集1的所有这些服务可与数据库13相互作用，该数据库是所有不变数据的存储库。这包括用户特定数据、服务特定数据与管理数据。数据库可以扩缩，安排冗余并如营运商所需般的健壮，所有这些均视需要而定。可使用Oracle数据库，但系统/网络可适合其它类型的数据库。因此，在本发明的一些实施例中，所有此类信息集中存储在用户的群集1的数据库13中的服务器端，并在用户7登录时下载到用户的客户11。这使得无需预先定制便可使用与系统/网络兼容的任何安装的客户。

通过从此联系列表选择用户，多个功能可供选择用户7使用。开始时，选择用户7可显示有关给定联系(例如，列表中的选定用户)的信息。此信息可以是联系实际上为其自身定义的项目组合，例如更喜欢的昵称和其它公共信息。此外，可供选择用户7使用的一个功能是向列表中选定的联系发送邀请的能力。此处的邀请概念很一般并可使用称为SIP(会话启动协议)的即将到来的标准协议。如前面所述，邀请可以是从一个用户7发送到另一个用户7的请求，请求另一个用户7参加邀请用户7给定类型的通信会话。作个比较，通过电话拨打一个人的号码实质上是向这个人发送邀请(以电话振铃的形式)。

对于可发送的邀请种类并无限制。为发送用户7提供了至少几个基本类型的邀请，以及在他们建立通信会话时处理相应通信会话的必需逻辑。参照图9，这些基本类型包括以下内容：1)寻呼：这包括短文本消息(它们是最简单的邀请类型，虽然它们不包含来自接收端的确认)；2)文本聊天：这些邀请可以建立用户之间的实时文本聊天会话；3)语音聊天：这些邀请可以建立用户之间的实时语音会话；以及4)万维网会议：这些邀请允许用户在Web上共享导航，因而一个用户的Web导航在另一用户的浏览器上会反映出来。

按照本发明的最佳实施例，一个值得注意的方面是如何在接收端处理邀请。在最佳实施例中，邀请从不直接从发送用户7发送到接收用户7或接收用户的客户。相反，至少利用一个RS，如上所述。当然，可以忽略联机状态而发送邀请，因此接收方可能根本未联机。邀请被提交到接收用户的RS，该RS在接收用户的用户服务器(US)上连续运行。接收RS按照用户指定的逻辑和可用的后端服务来决定如何处理邀请。作为简单的示例，视优先权而定，简单的文本寻呼可以三种不同的方式处理：如果用户联机，则用户可选择立即得到有关这样的寻呼的通知(例如图3)。他也可以指定：如果联机但标记为“请勿打扰”时，消息将转到其收件箱以便将来读取。最后，他可以决定：如果不联机时，文本寻呼应作为SMS消息转发到其移动电话(或其它寻呼网络)(例如图4)。这同样适用于所有其它类型的邀请。因此，语音聊天邀请实际上可以作为电话呼叫结束，条件是营运商在后端提供了该服务，或者如果两个用户均联机时，可作为纯粹的IP呼叫结束。

由于更多的服务和网络挂到本发明的系统/网络，因而此功能变得越来越有用。它也是客户11延伸到诸如智能电话和PDA的其它类型终端的基础。面对所述复杂性，路由服务为主叫方(邀请者)和被叫方(被邀请者)均提供好处。对于主叫方，它隐藏了有关在任一给定时间如何定位及与给定人员/用户7取得联系的杂乱细节。对于被叫方，它允许他/它控制谁可与他/它取得联系及如何取得联系，而无需向主叫方公开诸如电话号码或网络地址的任何个人信息。因此，本发明的一些实施例基本上定义了用户7的唯一身份，该身份可用于与其它用户和/或服务通信，使用所有可用的通信协议/类型，同时还保持高度安全性和匿名性。

最低设置可包括运行所有必需服务的单一服务器及运行数据库的一台机器。然而，在最佳实施例中，每个群集提供了多台服务器3，如本申请的附图所示。

群集1的管理最好由特定管理客户来处理，该管理处理数据库记录，并且还显示从群集发出的警告和记录。

因此，正如上述内容所述那样，本发明的系统/网络是轻量服务器框架，提供简单安全的用户模型及到外部服务的邀请路由。这样，它对可与其挂到它的服务并无任何重要限制，而是还允许对用户和计帐的统一接口。虽然实际个人用户信息被安全保持在用户注册的群集的管理边界内，然而不同群集中的用户可以互相通信。

下面所述是本发明某些方面的更详细说明。

关于可伸缩性，在本发明的一些最佳实施例中，后端能支持数千万用户的用户基础(user base)，数百万同时联机的用户。实际上，这意味着应用于多个群集间分割负载，应用于在机器、处理器、进程、线程等之间每个群集中分割负荷，以及应用于负荷平衡时，后端可实际上具有无限的可伸缩性。单个群集1本身中可能会对其可扩展性具有上限，但作为许多不同群集1互连的整个后端可进行无实际限制的伸缩。此处，群集在可伸缩性方面受所用数据库13的可伸缩性限制；在可伸缩性上不存在其它任何实际限制。由于现在只要投入资金，数据库13便可得到很好地扩展(虽然并不是没有限制)，因此，这可视为好的设计选择。

关于健壮，假设硬件运行无错误，在一些实施例中，每个服务器的可用时间最好超过99.9％，且网络的可用时间最好超过99.99％。当出现诸如硬件错误的异外错误时，可接受最长3-5分钟的时滞。基本上，在服务器3停机或中止时，另一台服务器必须自动接管其角色。另外，故障的任何单个点，诸如数据库、甚至硬件部件(如网络)，最好是冗余的并且在其出现故障时自动由其它部件接管。

通常希望客户与后端之间的通信尽可能安全，从实际立场上看这合乎理由。实现它的最好方法是在连接到客户时使用验证，并使用强大的加密技术将客户与后端之间的所有消息编码。

在本发明的一些实施例中，每个营运商可运行服务器群集(或多个群集)来为其用户组服务。这些分布式服务器群集最好可相互操作，以便维护整个共同体。另外，最好通过同时使用预防措施和防范措施，尽可能防止兜售信息。

对于整个体系结构，应使用符合应用设计需要的任何标准。此外，需要与后端基本服务集成的任何附加服务最好以“插件程序”方式连接到它。

现在转到整个服务器结构，参考图10。每个营运商运行服务器3的一个或多个群集1。每个群集1在高速、可靠安全的LAN上运行。通过使用两个(或多个)一样的LAN，可增强可靠性，从而提供n-1/n的冗余，其中，n是同样LAN的个数。通过将LAN保持在锁定的场所，可增强安全性。群集1通过网络连接17互连，网络连接最好是高速的，但可认为它不可靠也不安全。注意这并不表示按照本发明一些方面的通过此网络17的通信将是不安全的；它是指由于网络17(例如，分组交换数字网络)不提供安全保证，因此本发明的一些方面最好提供安全保证。还要指出的是，认为群集间网络不可靠的原因是指群集间没有要求具有可靠网络；它并不表示营运商需要时无法设置可靠的网络19。签于后端的需要，图10说明了每个群集1中服务器3的细分。一步的说明如下。

图11说明包括多台服务器3和一个数据库13的示例性群集1。许多客户11连接到群集1。群集中的服务器3包括用户服务器(US)19、连接服务器(CS)21和群集内服务器(ICS)23。下面表1中的所述内容为图11的群集1中的某些服务器3在本发明一些实施例中具有的一些作用的列表。

                   表1-后端中的服务器及其作用

缩写	全名	说明
			ICS	群集内服务器	需要时连接到远程ICS。收听来自远程ICS的连接。预订其它群集的用户状态，以便维护本地用户的正确联系状态。将本地用户状态转发到预订的远程ICS，以便维护远程用户的正确联系状态。将消息从远程ICS转发到本地US。将消息从本地CS转发到远程ICS。
DB	数据库	需要持续保存的所有数据可保持在每个群集的单个逻辑数据库13中。
			US	用户服	为给定的用户组维护用户状态。为这些用户跟踪

	务器	联系列表与看不见列表。跟踪这些用户的路由。将用户的状态变化转发到感兴趣的CS和ICS。通过RS路由这些用户的寻呼。
			UMF	用户映射功能	将给定的本发用户映射到特定US。通过与另一群集的用户相关的CID将该用户映射到特定ICS。监视群集中服务器的状态。在服务器出现故障、被添加或被删除时重新调整映射，并在需要时通知其它服务器。负荷平衡US和ICS。
CS	连接服务器	收听来自客户的连接。将有关连接客户的状态更新转发到处理它们的US。从US为连接客户的联系列表预订状态变化。将状态变化转发到客户。将寻呼从连接的客户转发到US，反之亦然。

在本发明的一些实施例中，除非两台服务器3中的软件实体正在进行通信，否则将不维持两台服务器之间的连接，就这种意义上来说，服务器3之间的连接不必为静态。然而，服务器3之间的连接可以共享，这样，如果两台服务器之间的连接已经开始，而服务器上的两个其它软件实体要相互作用时，已经开始的连接将会被共享，而不是开始一个新连接。

关于用户标识和映射，每个用户7被指定一个用户ID(UID)，可适用于整个应用。每个群集1分配有一个群集ID(CID)。CID以众所周知的方式被编码到每个UID中，如图12(b)所示。每个用户服务器(US)19指定有一个用户服务器ID(USID)。将本地UID(称本地是因为其CID为本地群集标识符)映射到USID，这是用户映射功能(UMF)25的任务。图12(a)说明了在本发明的一些实施例中映射机制如何起作用的示例。如果用户服务器崩溃、被除去或被添加，则映射是动态，因为它可变化。

群集内服务器23指定有群集服务器标识ICSID。每个ICS处理所有远程用户7，这些用户7具有映射到一组CID的UID。将远程用户的UID映射到ICSID是UMF 25的任务。此映射是动态的，方式与本地UID到USID的映射一样，且原因相同。每个具有标识ICSID的群集内服务器23处理一组远程CID(或CID的一部分)。将属于远程群集(即具有远程CID)的UID映射到ICSID是UMF的任务。此映射是动态的，方式与RID到USID的映射一样，且原因相同。

                表2--UID到其它标识符的映射

映射	缩写	注释
			群集ID(UID)	CID	静态映射
用户服务器ID(本地UID)	USID	UMF知到的，动态映射
			群集内服务器ID(远程UID)	ICSID	UMF知到的，动态映射

UID是URI，例如以joe＠net.com形式。在＠符号后的部分是CID。此UID选择是用于将来与其它系统的互操作性和兼容性，即SIP(用于会话启动)。

在一些实施例中，后端的特性和最佳健壮性会要求可靠的网络协议。并且，系统的要求会要求可靠、经验证和/或加密的通信媒体。因此，在一些实施例中，会为所有服务器互通信以及客户和连接服务器之间的通信选择运行于TCP/IP之上的SSH协议。本领域的技术人员将认识到其它协议也可用于其它实施例中。SSH揭示了称为“连接”和“流”的抽象。连接是可以验证和加密的、且可以提供数据完整性的两台计算机之间的端对端连接。流是不同计算机上的两个软件实体之间的命名双向流量控制流。许多流可以在任一给定连接上打开，在连接上它们可以被复用并分别进行流量控制。作为模拟，可以将连接想成一根电缆，而流是电缆内许多分开的绝缘铜线。

图13说明将本发明的系统/网络分成部件的方式以及部件之间的一些从属性。各个部件在整个系统/网络中具有不同的责任。

可见，用户服务器(US)19包括联机状态服务31、用户路由服务(RS)33、设备处理程序35、会话服务37、用户属性服务39、负荷平衡服务41及联系列表服务43。连接服务器(CS)21包括联机状态服务代理51、联系状态服务53和许多类属代理54。群集内服务(ICS)23包括许多类属代理55。作为这些服务器中每个服务器基础的框架包括UMF25、通知广播57、验证59、I/O模型61、协议编译程序63及资源与故障检测65。在一些实施例中，操作和维护(O&M)服务器64处理系统配置(例如提供/分配用户)和/或监视服务器/客户。

仍参照图13，联机状态服务31存储用户的联机状态，并将这些状态变化广播到预订的联系状态服务。联机状态服务代理51位于客户11与US 19之间，它转发更改客户的用户联机状态的请求；在客户的US出现故障时，它处理故障容限。如果US出现故障，代理51将尝试与US崩溃后UMF 25已为用户分配的US 19联系，并在该服务器上建立用户的联机状态。联系状态服务53从每个用户的客户的联系列表预订该用户的联机状态。联系列表服务43存储每个用户的联系列表，允许用户7访问并管理该列表，并允许其它服务读取该列表(看不见列表可以是联系列表中的一个组)。路由服务(RS)33接收来自用户消息，并按照驻留在发送用户和接收用户端并可由任一端用户设置的路由逻辑，将消息发送给正确的设备。RS 33允许用户访问和管理其路由表。

类属代理54、55驻留在CS 21或ICS 23上。此部件的责任是充当哑比特转发代理，将比特转发到驻留在US 19上的许多不同服务。服务器上的每个设备处理程序35可接收消息，将消息传送到用户或外部系统(诸如SMS)，存储消息，对消息操作等。因此，设备处理程序35可充当到外部系统的桥梁。用户属性服务39允许用户7读取和改变其自己的用户简档，以及读取所访问的其它用户7的简档的那些部分。

在客户11首次连接到后端时，验证59处理客户11的验证，它是框架部件67的一部分。通知广播57允许后端部件在几个信道上向群集中的所有其它部件广播消息，并收听一些信道上的消息。如图13所示，通知广播57也是框架部件67的一部分。虽然协议编译程序63生成的代码成为系统的一部分(它被生成用于每个服务的一部分)，但它本身不必成为系统的一部分。协议编译程序63将PDL(协议说明语言)文件编译成用于客户和服务器两者的代码，其中所述文件是客户和服务器之间或服务器与服务器之间协议的抽象定义，所述代码实现这些协议的传送，并隐藏协议消息如何在客户和服务器之间来回发送的复杂性。I/O模型61处理线程组合(threadpooling)与同步、数据库连接组合(database connection pooling)、I/O使用、定时报警等，并抽取这些用于其它服务。资源和故障检测功能65收听US 19、ICS 23和CS 21的故障，并在其中之一关闭时，通过通知广播机制广播消息。同样，这是作为CS、US、ICS和O&M服务器中每个服务器基础的框架部件的一部分。用户映射功能25将用户ID映射到用户服务器。此功能是分段定义的，仅按需要定义功能段。另外有一种机制，它将一段时间内未使用的分段收回并不定义。该功能对DB 13继续存在。该功能为CS和ICS(用户服务器ID(UID)和群集内服务器ID(UID))保持用户ID到服务器的映射。框架67因此负责提供写入服务的合适环境，这显然(对服务而言)确保了可收缩性和健壮性。

负荷平衡服务41以负荷平衡资源使用的方式分配群集外部的资源。此处的概念是：客户11可能要使用群集中尚未执行、但形成应用一个组成部分的服务器的服务，因而应将这些服务在概念上作为群集的一部分分配(和管理)。会话服务37处理会话创建、设置和管理，以及会话成员之间的数据传送。

管理工具允许系统管理员改变系统的一些设置，添加新用户等。它们负责向群集中所有部件通知对这些部件有影响的设置的变化。

数据库抽象层69提供群集中用于访问数据库13的统一方式。层69提供对几个LDO(逻辑数据对象)的访问，这些对象是DB 13中的用户定义(即由服务创建者定义的)对象，并提供数据库存储的某一数据结构的抽象。

框架67的职责包括如下：

A.提供一个有效处理问题的环境，所述问题有诸如I/O、定时报警、线程组合、消息广播、数据库连接组合和记录，隐藏服务创建者的复杂性的问题。

B.向服务创建者揭示抽象，这使服务创建者工作更容易。这些概念包括与I/O、数据库及其中存储的数据、警报、消息广播(通知)与记录相关的抽象。

C.在提供的数据抽象中执行数据隐藏。

D.如果有效，重新使用现有数据抽象对象实例。

E.提供指定协议说明的非模糊方法。

F.执行某一进程，假如有协议说明，这可输出代码，执行如何对协议请求进行编码的细节，用于通过线路发送请求，以及如何使用框架提供的I/O原语(primitive)。本质上，此进程向服务创建者和客户执行者隐瞒了使用服务的客户不运行于相同计算机上的事实。

G.唯一地标识服务实例并提供这些实例的登记，以便可连接到以前存在的实例。

H.向服务创建者隐瞒以下事实：当服务创建者的服务与相同服务的其它实例或不同服务的实例通信时，这些实例可能在相同群集中不同的计算机上，或者甚至在远程群集中的计算机上。

I.确保所有通信中的验证、安全和完整性，以便服务创建者可始终认为这些方面是不成问题的。

在框架67中向服务揭示的线程模型有时称为出租房间。房间定义为“引入租户的环境”。租户仅租用房间的事实意味着不可能始终在相同环境(即，在相同线程上)引入租户，但由于租户每次住在一间房中，模拟可引伸理解为一个租户从不会同时在多于一个环境中引入(即任何时候租户拥有的代码中不会有多于一个的线程是有效的)。服务是“租户拥有的”。我们这么说的意思是用于给定服务的给定实例的代码连到租户。因此，服务创建者在编写服务时可假定出租房间模型，根本不需担心线程问题。框架保持线程池，线程会根据需要添加到池中直至达到最大。随后，在需要完成工作时，这些线程会被重新使用。每个线程一次在一个租户且仅在一个租户中有效。需要完成工作时，框架会一直等待直至线程可用，然后将分配任务(需要处理的事件说明)交给它，并在这段时间将它标记为不可用。线程结束后会通知框架，这因而会使线程在线程池中恢复为可用状态。使用线程池的原因是：由于更多的线程被分配用于进行不同的作业，直到最大值(系统相关)，因而性能得以提高。这意味着我们一次只能有最大数量的线程，但却有许多需要同时进行的作业，这需要公平分享可用的处理能力。线程池方法解决了这两个问题。

至于I/O 61，框架67最好对客户与服务器之间、群集中的服务器之间及不同群集中的服务器之间的所有通信使用SSH标准协议的工具。SSH向所有通信提供验证、加密和完整性。它还提供称为连接和流的抽象。流是框架中使用的主要I/O抽象。框架向服务揭示相当于SSH流的抽象。

关于连接请求，框架中的服务的实例仅在流连到它时才存在。现在将讨论将流附到服务的过程。流用两个显式参数和一个暗含参数打开。暗含参数是打开流的用户的UID，我们将称它为源UID。显式参数是流的名称和UID，我们将流的名称叫作“流类型”，我们将UID称为目标UID。此UID可以是打开流的用户的UID，或者是不同用户的UID。前面提到过框架的一个责任是唯一地标识服务的实例。现在可以定义组成此唯一标识的内容：如上所述，它是连接到服务的流的类型及目标UID。

创建服务时，要创建两个主要部分：流可以连到的对象，称为流连接器；及知道把连接请求连接到何处的对象，称为定位器。也可以创建执行服务的实际功能的部分。在初始化时，基于框架的服务器以定位器处理的流类型的名义来记录服务器所知道的所有定位器。任一给定定位器均记录为对象，该对象知道将某一类型或某些类型的流的连接请求连接到何处。

现在可以解释如何处理连接请求。框架从SSH收到流类型X和目标UIDY的连接请求时，它找到已记录用于流类型X的定位器，并将连接请求传给该定位器。定位器检查目标UID、Y，并依据UID的内容，执行以下操作之一：1)创建新租户和新流连接器，将该流连接器连到租户，并将流连接到新流连接器，然后将新租户记录为“流类型X和目标UIDY的服务所连到的租户”(如果不明白，再读一遍，这很重要；记住所述有关如何标识服务实例的内容)；或者，2)它找到已记录用于流类型X和目标UIDY的现有租户，并将流连接到已连到该租户的流连接器；3)它创建新租户(如上所述)，而不管是否已存在用于相同(X，Y)对的租户。在对服务的“相同”实例的不同连接不必共享状态时，这是适当的。

流连接器查看连接请求的源UID，并依据正在连接的对象来决定是否要接受连接。在这方面，不同服务将有不同的表现。单个定位器事实上可以记录为用于一个以上的流类型的定位器。这表示单个服务事实上可以接受一个以上流类型的连接。在加上协议说明中指定的单个协议运用于各个流这一事实时，我们看到这种模型开始看上去象是我们在执行C++类，该类继承于一个或多个纯抽象基类。

由于我们已讨论了细节，现在可回顾并看看整个情形。每个服务具有“类型”，这是该服务接受连接的流的类型。每个服务实例由单个用户(目标UID)“拥有”。服务创建者可决定他/她是否要将到一个对(服务类型，目标UID)的所有连接连到服务的单个实例，或始终连到新实例。

直到现在，我们假定请求连接的流的实体是客户。事实是：服务只需指定它们要连接的源UID、目标UID和服务类型，便可自已将流连接到相同服务的其它实例，或不同服务的实例。这表示我们现在具有的框架支持客户与服务器之间及服务器与服务器之间的抽象流I/O。

有时，服务的实例必需发送广播消息(称为通知)到“所有感兴趣方”，但却不知道它们是谁。框架提供了一种方法和功能57，用于进行此操作以及用于收听感兴趣的通知。框架提供给服务的抽象如下所述。服务可发送通知(只是带有任意数据的二进制信息包)到特定命令信道。服务可收听特定命名信道，并在通知到达这些信道之一时，将接收一个呼叫到其代码中。

PDL是协议说明语言的缩写。这是用于客户和服务之间的协议的非模糊定义的框架解决方案(我们在此环境讨论客户时，也讨论打开流的服务)。PDL编译程序63是一个软件工具，在客户端与服务器端两者上，它将PDL作为输入，并给出多个代码。在客户端，它给出COM DLL，COM DLL执行专用于每个协议的COM接口，该接口允许客户应用程序使用协议，好象是一个普通的COM对象。在服务器端，它产生两个主要内容：使服务充当到协议的客户的代码；及使服务执行协议的代码。执行服务的代码分成两个部分：允许服务创建者回叫客户的对象，好象客户是驻留在与服务相同的进程空间的C++类，以及完全抽象的C++类，服务创建者必须继承该类以执行协议中定义的方法。这两个部分都足够高度抽象，以致服务创建者选择的话可以忽略下层I/O抽象是流这一事实(他甚至可以忽略在进行的任何I/O这一事实)。服务创建者对复杂性要做出的唯一让步是所有呼叫是异步的，即如果他要将“返回值”送回客户，他必须通过新的单独方法呼叫进行此操作。注意虽然PDL和PDL编译程序63由框架提供，以减轻手写协议堆栈的痛苦，但如果服务创建者选择要使用下层流抽象，他/她可以使用该抽象。此外，PDL生成代码使程序员可对其内部进行稍微改动，以改变其行为。

数据库抽象层69的任务是使服务创建者可容易地访问数据，隐藏数据，组合数据库连接及重新使用数据对象。服务创建者可看到的数据库抽象层的主要部分是记录与几个LDO(逻辑数据对象)。LDO是某一特定类型数据的抽象，即用于关系数据库中一个特定表或一组表的抽象。通常，它是结合服务创建而由服务创建者自己或单独的LDO创建者创建的。如果LDO选择隐藏他们表示的数据，则它们可以处理此操作。记录是记录现有LDO的位置。LDO与服务一样，由类型及“拥有”它们的UID记录。在服务需要LDO时，它向记录要求由特定用户拥有的特定类型的LDO。记录随后类似于定位器对连接请求作用那样进行作用，即它可创建请求类型的新LDO，或重新使用当前存在的LDO。数据库连接的池由数据库抽象层维护。这在功能和设计上与框架维护的线程池相似。

至于UMF 25，下面描述了框架如何知道特定服务实例驻留于哪个服务器。服务按类型和目标UID来标识。用户映射功能(UMF)25是分段定义的功能，它指定把给定UID的服务实例设置在哪个US上。如果该服务器关闭，UMF会改变其映射，因此该服务器上的用户几乎立即可以重新连接并从群集中未关闭的US接收服务。如果一个服务器添加到群集，UMF会开始将该服务器用于新的连接，直至服务器容量满为止。用户映射功能(UMF)25本身最好存储在数据库中，但用于保持功能正确的代码在基于框架的每个服务器3(19，21，23)上执行。在连接到其它群集的群集1中，最好有两个UMF：内部UMF和外部UMF。内部UMF由CS和US用于确定US与ICS的位置，及由ICS用于为本地群集UID确定US的位置。外部UMF由ICS用于为外部UID确定ICS的位置。

类属代理54、55虽然在逻辑上不是框架的一部分(它是一种服务)，但类属代理54、55是提供给框架的核心服务之一。类属代理充当从一个流到另一个流的比特转发代理。在CS 21上，类属代理54以下面所述方式使用：类属代理被记录用于后端中客户应该要访问的每个协议。在类属代理得到连接请求(类型＝x，源UID＝y，目标UID＝z)时，它会接受请求，然后要求其框架用参数(x，y，z)打开流。由于内UMF正在CS 21上使用，这将打开到服务目标UIDz的US 19的流，或到ICS 23的流，ICS 23充当了到用户z所驻留的群集的桥梁。在其它服务器类型上(例如，US和/或ICS)，类属代理55以相同的方式使用。这里，不同之处在于，对于来自外部群集的连接请求，使用内部映射功能，而对于来自本地群集中的连接请求，使用外部映射功能。正如从上述分析中可看到的一样，框架流模型、UMF和ICS上的类属代理允许服务连接到网络中可联系上的任何用户的服务，除要连接的服务类型和用户UID外，无需知道任何细节。

由路由服务(RS)33来处理路由，如UMF所指示一样，路由服务33驻留在用于给定用户的US上。例如，如图3所示，当用户A向用户B发送消息时，会出现下列情况：1)用户A的客户将消息发送到用户A的路由服务；2)在用户A的US 19上，用户A的路由服务33会将消息与一些其它参数作为输入数据，运行其“输出路由逻辑”(通过决定向用户B的US上的用户B的路由服务发送消息，该路由逻辑可能会结束)；3)用户B的路由服务33从用户A的路由服务接收消息，并在上面运行其“输入路由逻辑”(通过决定向用户B的客户(如果连接)发送消息并存储消息，该路由逻辑可能会结束)。任选地，用户A的客户可接收消息并弹出带有新消息的窗口。消息(如应用于路由服务的一样)是字符串，例如，它可以按照SIP标准被格式化。消息正文的格式取决于消息类型。在用于给定用户的RS 33中，输出路由逻辑与输入路由逻辑均可决定将消息转发到设备处理程序(并且一旦设备处理程序对其进行处理后可随意对其进一步进行处理)，在给定用户的消息箱中存储消息，将消息传送到不同用户的路由服务，或者将消息传送到给定用户的客户。用户可以请求在以下情况将传送的接受发送给他们：a)他们发送的消息存储在接收者的消息箱中；b)他们发送的消息发送到正在接收的用户的客户。

为防止兜售信息与服务拒绝攻击(denial-of-service attack)，在一些实施例中可能不允许发送具有多接收者消息。这表示如果客户要将相同消息发送给15个用户，则客户要做的是将相同消息发送15次。这表示在这样的实施例中，服务器无法用于将消息复用给用户，因此使服务拒绝攻击更难以执行，也使向多个接收者发送消息变得耗时。

此处，设备是可以接收消息的任何东西。每个设备可接收一个特定消息类型或一组类型的消息(例如，从RS 33)。每个设备还有一个特定的类型，即设备类型。与该类型相关的是它可接收的消息类型组，及任选地用于标识设备的标识符类型(例如，用于电话终端的电话号码)。称为“设备处理程序”的软件部件代表系统中的设备。一些情况下，设备是纯粹概念上的，且设备处理程序本身实际上可看作设备。除所有设备处理程序可处理相同协议这一事实外，设备处理程序是每个方面的一般服务。此协议允许路由服务33将消息传送到设备处理程序供处理，并由设备处理程序将其传回。

在专用伪编程语言复制路由树中，可执行路由逻辑(即为决定如何处理消息而做出哪种选择)，例如由RS 33执行，所述路由树本质上是一个节点树，其中所有非叶节点是判定点，而叶节点是作用节点。判定节点的判定可依据许多参数作出，所述参数包括要路由的消息内容、时间和日期、数据库某些部分的状态等。对于每个用户，可以指定几个不同命名的路由简档。每个路由简档包含路由树指定路由逻辑。路由简档可由客户定义。一个路由简档用作输入消息的路由简档是始终有效的(使用哪个路由简档可由客户定义)，并且只要客户发送消息，它便指定哪个路由简档用于输出消息。这样，不同路由简档可用于不同情况，即一个路由简档用于用户在上班时，一个路由简档用于用户在家时，一个路由简档用于用户联机时，等等。

对于会话启动(即邀请另一用户加入会话，接收邀请等)，在一些实施例中，可使用会话启动协议的子集(SIP，[1])。例如，使用的SIP方法包括INVITE(邀请)、ACK和CANCEL方法。例如，在Handley/Schulzrinne/Schooler/Rosenberg所著的“SIP：会话启动协议”(Internet Draft，Internet Engineering Task Force，Aug.1998)中解释了SIP，通过引用将其公开结合在此。这些足以使用户启动会议并邀请其它用户加入，也足以使两个用户启动点对点会议。有关会话说明，使用了会话说明协议(Session Description Protocol)。例如，在M.Handley与V.Jacobsen所著“SDP：会话说明协议”(RFC 2327，Internet Engineering Task Force，April，1998)中解释了会话说明协议，通过引用将其公开结合在此。

本发明中可使用不同类型的路由方案。在一些实施例中，系统插入件可定义与下述最佳方案一起使用的其自己的路由方案。在一个最佳实施例中，表3中的下述内容是最佳路由方案的消息类型(例如，寻呼、自动应答、邀请请求、邀请应答等)。如有必要，可添加更多的类型。

                表3-路由方案定义的消息类型

寻呼	一个用户发给另一个用户的短文本消息。
		自动应答	对用户发送消息的自动响应。
邀请请求	一个用户发送给另一用户的参加会议的邀请。消息的正文包含SIP INVITE(SIP邀请)请求标题。
		邀请应答	对参加会议邀请的应答。消息的正文具有SIP INVITE应答标题。

邀请设置请求	一旦被邀请用户同意参加就发送的会话设置请求，例如，SIP ACK请求。
		邀请设置应答	会话设置应答，按SIP ACK应答方式。
邀请取消请求	邀请取消，例如，SIP CANCEL。
		邀请结束请求	离开会话时发送，按SIP BYE的方式。

用户的“收件箱”是用户的路由服务33的一部分。收件箱接收发给用户的任何一种消息。收到消息时，如果用户联机，它会向用户(或用户的客户)发送消息通知。用户可列举存储在收件箱中的消息标识符，及每个消息是否已读或未读。用户可从收件箱检索消息，将其标记为已读或未读，或者删除消息。用户还可以将消息存储在收件箱中。在一些实施例中，共同体营运商将定期检查很大的收件箱(即大容量)，通知用户(通过寻呼用户的方式)如果用户不整理收件箱，其收件箱中的最早的X个消息将被删除，并向用户7指出完成整理的最后期限。这将是管理工具和数据库方案的一个功能。另外，如果消息做了相应的标记，收件箱可发送存储的收到消息。

图14是流程图，说明第一用户(例如用户1)如何使用网络的一个或多个群集与第二用户(例如，用户2)建立通信会话(例如，语音聊天、文本聊天等等)。第一和第二用户可分配到相同群集，或者分配到网络的不同群集。另外，第一和第二用户可分配到相同用户服务器(US)19，但更可能分配到不同的用户服务器19。开始时，第一用户想向第二用户发送有关会话的邀请消息(即一个INVITE消息)[步骤151]。第一用户可查看第一用户的联系列表中的第二用户的UID(注意UID无需包括第二用户的网络地址，诸如第二用户的电话号码或IP地址，因而在一定程度上保持了与通信会话相关的匿名性)。在第一用户请求时，第一用户的客户(例如PC或电话)形成并发送INVITE消息到第一用户的US和该US上第一用户的RS33[步骤153]。第一用户的US上的第一用户的RS 33运行其输出路由逻辑并确定如何处理消息[步骤155]。例如，RS可忽略消息[步骤157]，但更可能决定将消息转发到第二用户的US 19上的第二用户的RS 33(在相同或不同群集)[步骤159]。第二用户的RS 33接收该INVITE消息，并如第二用户编程的那样运行其输入路由逻辑，以确定如何处理INVITE消息[步骤161]。例如，第二用户的RS 33的路由记录可使RS进行以下操作：1)将INVITE消息作为SMS消息转发到第二用户的移动电话或象寻呼机一样的一些其它寻呼网络设备(例如，如果第二用户当前不联机)[步骤163]；2)将INVITE消息转发到第二用户的收件箱[步骤165]；3)将INVITE消息直接转发到第二用户的当前联机客户(例如PC)[步骤167]；和/或4)将INVITE消息传送到另一用户的RS 33[步骤169]。在出现4)所述情况下，另一个用户可以忽略、拒绝或接受邀请[步骤171]。要不然，第二用户可以象此处所述的一样，忽略、拒绝或接受INVITE消息的邀请[步骤173]。

除发送寻呼外，路由服务33的一个功能是作为一种工具，用户可通过这种工具在任何一种会话中约会他人，例如电话呼叫、文本聊天、视频会议等。为说明约会如何工作，最好举一些示例：一个示例是两个用户均在使用其计算机；另一个示例是一个用户在使用其计算机，而另一个用户在使用其电话；再一个示例是两个用户均在使用其电话。注意，这些示例的任一示例中，呼叫方除被叫方的标识符(UID和系统/网络电话号码两者)外，无需知道有关被叫方的任何标识信息。实际上，除非被叫方特别允许，否则呼叫方决不能通过系统/网络找出被叫方的联系信息。

例如，对于PC对PC的约会，参照图15，设想Carl要邀请Anne与William和他一起进行文本聊天会议。Carl将先通过其客户11邀请Anne。Carl的客户11将通过在Carl的会话服务(正在Carl的US 19上运行)中创建会话来开始，然后它将会话地址(例如，会话名称，carl＠phonecompany.com)编码到SIP INVITE消息中[步骤73]并将其发送给Anne[步骤75]。按照各个用户对其各自的RS进行编程的方式，INVITE消息将由Carl的RS 33和Anne的RS 33进行定向。正常情况下，如果Anne联机，INVITE消息将得定向到Anne的客户(例如，Anne的PC)。Anne随后确定是接收还是拒绝邀请[步骤77]。如果Anne决定接收邀请，则这将使她的客户11连接到INVITE消息中编码的会话[步骤79]。如果Anne决定拒绝，则她可以忽略INVITE消息[步骤8]，或可发送拒绝消息到Carl的客户[步骤83]。要邀请William，Carl将使用其客户将William添加到会话中。William将收到INVITE消息，以同样的方式接受邀请并加入会话。

为说明另一个示例，考虑PC对电话约会(例如，参见图4)。Carl(用户A)在使用他的计算机(例如PC)，并想与Anne(用户B)进行语音聊天。Carl在其客户11中选择此选项，客户11随后将如上述一样发送SIP INVITE消息给Anne。然而，Anne不在使用计算机(即Anne的客户11未联机)。收到消息后，Anne的路由服务33指出她未联机，但她已要求将Carl的语音聊天转发到她的GSM电话。因此，Anne的RS 33将消息与电话号码一起发送，以呼叫专门为处理这种INVITE消息而创建的设备处理程序10。设备处理程序10在有关的外部语音网关12中设置到Anne的呼叫支路(call leg)，在网关中设置一个临时号码，如果Carl呼叫Anne，该网关将使Carl连接到已设置给Anne的呼叫支路，随后送回SIP INVITE消息的应答，告诉Carl的客户11有关Anne暂时移到刚设置的临时号码。Carl的客户11呼叫该号码(使用某个IP电话系统)，听到振铃，Anne进行应答以完成约会。

作为另一个示例，考虑电话对PC约会。假定Anne要使用她的GSM电话(即Anne的客户)呼叫William。她拨打William的电话号码(由于电话系统仅支持电话号码作为地址，而不支持系统/网络UID，因此这种双重映射是必要的)。语音网关接收到此号码的任何呼叫设置请求，包括Anne的呼叫设置请求。它与有关的设备处理程序联系并询问该设备处理程序将呼叫路由到何处。设备处理程序通过William的US服务器和RS 33将SIP INVITE消息发送给William。William接受输入的语音聊天，这使得他的客户(即William的PC)把对包含电话号码的SIP INVITE的“接受”响应送回，他的客户在他正在使用的IP电话系统中登记约会。William在他的RS 33中的路由逻辑把消息路由回发送原SIP INVITE的完全相同的设备处理程序。收到消息后，该设备处理程序将消息中的电话号码回送到语音网关，它相应地将呼叫转发给William。William的客户弹出“输入呼叫”对话框，由William决定应答。

对于又一个示例，考虑电话对电话约会。假定William想呼叫Carl。他拿起电话(William的客户)，并拨打Carl的电话号码。除Carl的RS 33中他的路由逻辑指出他脱机外，这种情况与上述电话对PC约会的情况相同，因此通过Carl的指令/编程将他为自己脱机时指定的INVITE消息和电话号码发送到一个设备处理程序，该设备处理程序对INVITE的回答是“暂时离开”消息，这使INVITE回到发起INVITER的设备处理程序，随后回到把呼叫转发到指定号码的语音网关。

如上所述，也可提供有利于事情的服务，这些事情如了解其它用户的联机状态，设置您的联机状态(如果你是用户7)，及在分层列表中存储您的联系。这些服务由下列部件提供：联机状态服务31和联机状态服务代理51；联系状态服务53；及联系列表服务43。

图16示出在每个用户服务器(US)19上由用户服务保持的数据结构。这只是一个说明最重要数据元素的草图。图17以相同方式示出在每个连接服务器上联系状态服务的数据结构。这两种数据结构均被认为是不稳定的，且出于效率原因而保持在存储器中。用户的联机状态由把用户看作某人的联系的CS 21从负责的US 19预订。连接到用户的客户的CS可更新用户的联机状态(通过用户服务/用户服务代理)和他/她的联系列表。当US 19得到对尚未载入的用户的联系列表请求时，它从数据库载入该用户数据。用户数据在任一CS21正在使用它时保持已载入状态，在所有CS释放数据后，可以从存储器中将其卸载。数据可在某种高速缓冲存储器中保持一段时间，以便可从该处迅速载入。通过检查存储在CS上的数据版本号并将它与存储在US上的数据版本号相比较，列表的版本属性所起的作用是能够了解何时更新CS中的高速缓冲存储器。

在CS 21上的联系状态服务53中，每个连接的用户具有一个联系列表。联系状态服务预订它从US上相应用户服务注视的每个联系的联机状态。发送状态更新时滤出看不见用户是用户服务的责任。图18a示出了存储用于联系列表服务43的数据结构。此信息存储在数据库13中，并在需要时被检索。每个用户具有一个看不见列表和一个可见列表，每次有一个列表有效。如果看不见列表有效，则除看不见列表中的那些用户外，所有用户可看到此用户的联机状态。另一方面，如果是可见列表有效，则只有可见列表上的用户可看到此用户的联机状态。

参照图19，为了访问本发明的系统/网络，用户7必须先登录。图19说明了用户U₁登录到系统上时的消息序列示例。在CS 21收到验证请求时，它先检查密的真实性。用户可能未注册等。随后执行验证。在该示例中，用户的UID以前尚未使用过，因此，CS必须向UMF请求USID。UMF25选择一个可用的具有最小负荷的US 19负责该UID。CS现在在负责的US 19上设置U₁的联机状态，并检索联系列表。在该示例中，U₁具有一个联系，即B₁。该联系的状态必须从该联系的相应US来取得。此后，CS预订B₁的联机状态。仅在B₁联机时联系用户B₁的US 19才应答。CS和客户在默认情况下假定联系脱机，直至他们收到状态消息。

图20示出用户U₁在后端注销时消息序列的示例。现在，CS 21向负责U₁的US 19发送注销消息。US向所有预订方发送状态消息，保存用户数据并将其卸载。

图21示出联系B₁登录和注销时的消息序列示例。用户U₁正通过用户U₁的联系状态服务注视B₁。在联系用户B₁开始联机时，用户B₁的US将B₁的联机状态发送给所有预订的CS 21。这样，用户可以监控整个系统/网络上不同联系用户B的状态，而联系用户B不知道它们的状态正受监控。

图22示出用户7把联系添加到他/她的联系列表且随后将其再次删除时的消息序列的示例。在数据库13中的保持更新联系列表是US的责任。如图22所示，在某些实施例中，用户作为联系在另一用户的联系列表上添加或删除时，已添加到另一用户的联系列表的用户会收到通知。一个用户7可添加分配或未分配相同群集到添加用户的联系列表的其它用户。

图23示出用户把系统/网络的另一用户添加到他/她的看不见列表且随后再将其删除时的消息序列的示例。在某些实施例中，在数据库13中保持更新的看不见列表是US的责任(即，添加用户7的US 19的责任)。注意，在用户A添加用户B到他的看不见列表时，用户B不会得到任何关于此的通知。也就是说，用户B将不知道他或她在用户A的看不见列表中。图24示出用户转化他/她的看不见用户列表时消息序列的示例。此序列类似于将用户添加到看不见列表时的序列。

图25中所示是联系列表功能所需的数据库13操作的总结。正如所看到的一样，在最佳实施例中，给定用户7的用户服务器负责有关特定用户的联系列表功能的大多数动作。

会话服务37处理会话管理。启动会话(即召开会议或启动文件传输)的用户拥有会话。其它用户7得到该会话的邀请，邀请包含了如何连接该会话的指示。会话的拥有者可邀请其它用户(通过一般消息路由机制)，将用户踢出组外及对用户进行消音而使其成为听者，和/或结束该会话以使所有用户退出该会话。进入会话只能通过邀请，且这最好由保持可进入会议的用户列表的会话管理服务器来处理。会话的拥有者在邀请其它用户时，他/她对此列表进行添加。

为每个用户7存储某一数据组。数据保持在密钥/值对呼叫属性中。这些属性可以是供每个人查看的全局属性，或者保密为仅由用户本人访问或可进行访问控制。图18b示出了按照本发明实施例的用户简档的数据结构。给定用户的用户属性服务39控制在这方面的功能和存储。另外，某些实施例中可提供“找到用户”服务，用于使客户可以通过搜索用户属性(与用户属性服务39中相同的属性)找到其它本地群集用户的用户ID。

对于每个群集，存在单个可伸缩且健壮的相关数据库13，它包含系统使用的且必须持久的所有数据。对于较小设置，这可以是运行诸如Oracle或Informix等数据库的单一计算机。对于有大量用户有更高稳定性要求的更大设置，将使用对相同数据库进行读写的高性能计算机群集，并且，例如，数据库可驻留于镜像热机交换RAID装置。这样，可实现任何级别的冗余及实际处理任何数量用户的能力，而仍可选择运行小而便宜的设置。数据库13最好包含为每个用户保持的简档信息。数据库将还为每个用户包含联系列表和看不见列表。联系列表是组的分层结构，其中一个用户可以属于不止一个组，一个组包含其所含的所有用户及以递归方式包含其所含组中的所有用户。同样在数据库中存储用于每个用户的不同路由的简档的数据，以及描述当前哪个简档有效的数据等。每个用户的收件箱最好存储在数据库中。这是按存储时间排列的一系列消息，及有关这些消息是否已读或未读的消息。同样存储消息的事务处理历史记录。可能的事务处理包括ADDED、DELETED、DESTROYED、MARKEDREAD及MARKED UNREAD。对于服务器系统，DELETED和DESTROYED事务处理是等效的(即，它们从数据库删除消息)，但在客户中保存为两个单独的事务处理来使灵活性提高(例如，客户要从其本地高速缓存及从服务器两者删除消息时，它使用DELETED；仅要从服务器删除消息时，使用DESTROYED；不同的事务处理将允许客户的其它实例提供相同的终端用户经验)。另外，在一些实施例中，后端服务器的所有设置均存储在数据库中，来自系统的记录，包括用于管理的记录与用于计帐的记录，同样存储在数据库中。在一些实施例中，除与客户的位置有关的设置外，例如防火墙设置，用于每个用户的客户的所有设置也存储在数据库中。

现在转到可伸缩性，我们来定义用于确定可伸缩性的数学模型。参考下面的表4。

         表4-限于在数学模型中使用的符号

符号	定义
		A	所有用户的集。
N	‖A‖，即用户总数。
		n	联机用户的数量。
B(u)	用户u的联系列表。假定B(u)A。
		L(u)	u的看不见列表。除L(u)中的用户外的所有用户可以看到u的联机L(u)A。
P(u)	有权看到u的联机状态的用户。只允许P(u)中的用户看到u的联机状态。P(u)A。(P(u)或L(u)为空。)
		Ncs	连接服务器的数量。
Nus	用户服务器的数量。
		NR	用户区的数量。用户空间被划分成NR个区。每个区有N/NR个用户。
f	任一给定联系列表中的平均联系数。假定为一个常量。
		l	任一给定看不见列表中的平均用户数。假定为一个常量。

N和n对路由服务在US(CS不参与路由)上所造成多大负荷的影响是感兴趣的事情。为简化起见，我们假定有下列条件：1)联机用户平均分布在所有CS上。每个CS上连接的用户的数量为n/N_CS；2)要求根据路由逻辑决定单个消息的路由的工作；3)在用户消息的路由已确定时要求发送消息到其目的地的工作是个常量；以及4)每个用户每个时间单位需要路由的消息数量是个常量。假设有这些假定条件，路由服务在每个CS上造成的负荷大约为： $o\[\frac{n}{N_{\mathrm{CS}}}(\mathrm{\λ}+\mathrm{\μ})\mathrm{\Ω}\]$

由于(+).是不变的，因此，在n随着增加N_CS而增加时，我们可使服务在每个US上造成的负荷保持不变。

关于连接服务器21，N和n对联系列表服务在每个US上所引起负荷的影响是感兴趣的事情。为简化起见，我们假定有下列条件：

·联机用户平均分布在所有CS上。每个用户上的

  连接的用户数量为n/N_CS。

·所有联系列表的大小为f。

·对于每个用户，每个单位时间从客户传来的事件

  数是一个常量。这样的事件包括：登录、注销、

  改变用户状态、把用户添加到B(u)、从B(u)删除

  用户等。因而对于每个预订的联系，每个时间单

  位从US传来的预订消息数也是一个常量。

·遵循上一个假设条件，我们假定来自单个连接的

  客户的事件所造成的给定CS上的负荷是不变

  的，表示为。另外，我们假定来自单个联系的

  预订事件所造成的给定CS上的负荷是不变的，

  表示为。

·在每个CS上的连接的用户与相同CS上的其它

  连接的用户不具有任何相互联系。此外，未连接

  的用户不具有连接到相同CS的联系。这是最坏

  的情况，通常，连接的用户共享一些联系，即某

  两个连接的用户x和y将对遵循相同联系z的联

              机状态感兴趣-用户x和y共享联系z。假设出

              现这种情况，任一CS要预订fn/N_CS个用户。

由此，假设有这些假定条件，我们可以看到在任一CS上的服务造成的负荷可大约为： $o\[\frac{n}{N_{\mathrm{CS}}}\mathrm{\α}+\frac{n}{N_{\mathrm{CS}}}\mathrm{f\β}\]=o\[\frac{n}{N_{\mathrm{CS}}}(\mathrm{\α}+\mathrm{f\β})\]$

由于+f是不变的，显然通过在n增长时添加更多CS到网络，在每个CS上的负荷便可保持不变。因此，网络的CS部分是可伸缩的。

最可能的是在每个CS上将出现某一联系共享，从而降低其负荷。然而，在N增长时，将会拒绝联系共享。这是明显的，因为连接的用户可具有来自用户空间A中任何地方的联系，而任何两个用户共享其f联系的机会随着A的增长而降低。经验表明，在象本发明的系统中，用户将按团(clique)来分组。在一个团中，每个用户几乎具有每一个其他用户的联系列表中的所有其它用户。(注意团的数学定义更强。在数学团中，每个用户将具有其联系列表中的所有其它用户。)如果用户连接到CS的方式使其可能与该CS上某个其它连接的用户处于一个团中，则会增加联系共享的机会。例如，按用户的地理位置将用户连接到CS，则可能性或许会增加。

类似于连接服务器上的前面部分，N和n对每个US 19上的联系列表服务所造成负荷有多大影响是要考虑的事情。我们假定下列条件：

·联机用户和联机用户的联系列表中的用户平均分

  布在所有CS上。每个US上的用户数量为n/N_CS。

·所有联系列表的大小为f。

·对于每个用户，每个时间单位来自CS的事件数

  是一个常量。从而，对于每个用户，每个时间单

  位需要发送到CS的预订更新数也是一个常量。

·来自单个联机客户的事件所造成的给定US上的

          负荷是不变的，表示为。需要发送到单个CS

          的有关单个用户的预订更新所造成的负荷是不变

          的，表示为。

          网络足够大，因此N_US＞＝f。在CS中没有联系共

          享出现。因此，单个用户的预订更新必须发送到

          f个US。这是最坏的情况。假设有这些假定条件，服务在任一US上导致的负荷大约为： $o\[\frac{n}{N_{\mathrm{US}}}\mathrm{\θ}+\frac{n}{N_{\mathrm{US}}}\mathrm{f\ω}\]=o\[\frac{n}{N_{\mathrm{US}}}(\mathrm{\θ}+\mathrm{f\ω})\]$

对于连接服务器，通过在n增长时添加更多US到网络，在每个US上的负荷便可保持不变。因此，网络的US部分是可伸缩的。

至于可靠性问题，群集1是异步分布式系统，它包括下列分立部件：1)连接服务器；2)用户服务器；3)用户映射功能；4)数据库；5)内部网络；6)外部网络；7)客户；8)群集内服务器。我们假定内部网络和数据库实现其自己冗余且达到近100％可用时间。为满足其可靠性要求，共同体服务器网络因而必须能够处理以下类型的错误：1)客户故障；由CS检测，仅影响有故障的客户；2)外部网络故障，失去与一个或一个以上客户的连接；由连接服务顺21和客户检测，通过丢弃服务器端上的该会话状态并从客户建立新连接来进行纠正；3)连接服务器故障，导致损失CS的硬件或软件故障；由连接的客户检测，并通过客户重新连接来进行纠正；4)用户服务器故障，导致损失用户服务器的硬件或软件故障；由连接的CS和/或UMF检测，并通过从UMF删除对受影响US的所有映射，并向所有CS广播一个请求，这些CS选择性地冲洗其UMF高速缓存(受影响的CS随后丢弃与损失的US 19相关的任何会话状态，并重新连接到其它新分配的US)；5)群集内服务器故障；与US故障的情况相同；6)用户映射功能故障；由US 19检测，并由重新启动UMF25的US来纠正。

对于记录、检查和/或跟踪能力，系统中的所有相关事件可记录到数据库13。这些分成两个主要类别：管理员感兴趣的事件和可用于计帐的事件。对于每个事件，均会存储事件的日期和时间以及对事件负责的用户。每个事件具有类型，并可能附有一些附加数据。当记录由用户通过客户到服务器协议发送给CS的请求时，可能也会存储用户的IP地址。管理员可以使用专用管理工具或简单的SQL查询执行管理任务，诸如查看在一行中哪些用户帐户尝试验证自己一次或多次但未能成功(以检测入侵尝试)；对某个时间或整天登录的用户数进行计数，或查看系统崩溃前及崩溃时发生的事件(以尝试获得对崩溃原因的了解)。共同体营运商可使用他们喜欢的任何装置从服务器收集数据用于计帐。

对于安全性和用户验证，在本发明的一些实施例中，每个注册的用户在本地群集1中具有一个分配的用户ID。作为注册过程的一部分，用户选择用于访问其帐户的密码。每次连接时，用户将其用户ID和密码提供给群集1。至于服务器验证，每个CS 21配有一个公用/私有密钥对。密钥对的公用密钥由某一认证授权(CA)证明。每次客户连接到CS时，它会获得一份服务器的公用密钥及相关的证明。通过检查该证明以及通过用CA核实该证明尚未撤消，客户可核实公用密钥的真实性。收到服务器的公用密钥并核实其真实性后，客户以一种类似于用户验证的方式，通过密码询问响应来验证服务器。

对于通信安全和客户-服务器通信，在本发明的一些实施例中，客户和CS之间的所有通信是安全的。SSH 2.0协议用于所有客户-服务器的通信。SSH 2.0处理服务器验证、客户验证、数据完整性确认及数据加密。客户通过打开多个SSH信道，与服务器群集上的各个不同服务连接，其中每个信道是个单独的虚拟流。对于服务器-服务器通信，假定处理用户服务器19、UMF 25及连接服务器21之间通信的网络是安全的，且防止了未经授权的访问。在本发明一些实施例中，US之间的通信以及UMF与CS之间的通信既未验证也未加密。CS 21与US 19之间的通信可使用SSH 2.0协议。对于这样的连接，禁用了服务器验证、用户验证、数据完整性确认及数据加密，因此仅需要使用复用SSH工具的流。共同体营运商之间的通信最好被加密，且使用公用密钥加密技术对两端进行验证。SSH 2.0协议可用于这样的通信，且通过公用/私有加密技术和密钥核实，执行相互服务器验证。对于物理安全性，需要由共同体营运商对硬件进行安全保护，以防止未经授权的访问和篡改，其中硬件包括运行数据库13的主机、CS 21、US 19、UMF 25、网络路由器、桥接器、网络线缆和群集1中的任何其它部分。如果群集的一部分受到有形危害，则由于群集的任一部分均可能包含或载有敏感信息，如CS的私有密钥、用户的保密信息和通信等，因此整个系统的安全性会崩溃。

此外，要注意的是连接服务器位于不安全的因特网和拥有群集1的安全的内部网之间。连接服务处理可以明文形式看到所有连接的服务业务，并且还以明文形式包含其自身的私有密钥。因为连接服务器对不安全的因特网连接是开放的，并处理所有客户通信，因此可以说它们是发挥了防火墙的功能。每个CS 21有两个网络接口，一个到不安全的因特网，一个到安全的内部网。在这两个网络之间不执行路由。在一些实施例中，连接服务器能够记录每个连接和连接尝试。记录项包括的信息如连接尝试日的日期和时间、源IP地址、用于任何验证尝试的用户ID及验证失败的原因。对于成功的连接，连接服务器另外记录了断开连接的时间和每个方向上传送的数据量。在一些实施例中，最好由共同体营运商过滤并检查从因特网指定到连接服务器的业务，以防止入侵并留意入侵尝试。

后端每个部件的设置最好存储在DB中，一旦启动后，部件可从DB中读取设置。这些设置最好是可通过管理工具来配置的，该工具具有到每个后端部件的连接，并在必要时可将设置的变化通知部件。图26说明群集1中管理工具的位置。将用户添加到应用及从应用删除用户由单独的管理工具处理，基本上是该工具产生新的UID，然后将用户的信息写入数据库。应该可以从命令行运行此管理工具，以便于CGI程序等一起使用。

从上可见，用户7能够创建新简档，删除简档，编辑简档等，并应能够设置当前哪个简档有效。智能路由基于所述用户当前有效的简档，并基本上表示在另一特定用户试图使用特定模式的通信与所述用户连接时，所述用户将路由到可处理该通信模式的一个谈话端点或消息储存库。根据简档中的设置，其它用户将路由到一个自动答复器，或接通到用户的GSM等，其中答复器回答所述其它用户：所述用户不喜欢他且不想接收其呼叫。

以下这些模式的通信/谈话类型应可用：文本、语音和视频。以下这些消息类型可使用：语音(VM)、短文本消息(STM)、电子邮件(EM)、通知(发送用来通知有关STM外的其它消息的传送)(UM)。可支持下列设备。我们列出了这些设备可存储的消息类型、可参与的谈话类型及可发送的消息类型。

表5

设备	用于这些消息类型的储存库	用于这些谈话类型的端点	可发送这些类型的消息
				收件箱	STM，NM
客户		文本、语音	STM
				标准电话		语音
GSM电话	STM，NM	语音
				自动答复器		文本，语音
网页			STM
				寻呼机	STM，NM
电子邮件客户	STM，EM		STM，EM
				语音	VM
邮箱
				传真机	STM，EM

应可以按需要创建其它设备(例如，谈话代理)。至于上述设备，自动答复器设备基本上是用户7可设置为使用语音和/或文本对不同用户进行不同应答的设备。此设备是本系统/网络的一个组成部分。在语音谈话中，仅客户11能够启动多于两个用户之间的语音会议。收件箱接收发送给用户的所有STM以及消息传送的通知(例如，系统将电子邮件路由到用户的传真机时)。用户可指定想要告知的消息传送的类型。客户可访问收件箱，并通知用户新的消息到达收件箱。如果用户A试图以用户B不支持的通信模式或消息类型与用户B联系(即用户B具有的设备不能参与该模式的通信或者不能接收该消息类型)，系统会将此通知用户A。

至于文本会议，这样的会议在每次会议可处理数十个用户。启动会议的用户最好在会议中具有所有权，这使该用户可邀请用户参加会议，将用户踢出会议，以及使用户不语。对于语音会议，此类会议可处理的用户量最好不少于应用所依赖的MCU或相当部件可处理的数量。启动会议的用户7最好在会议中具有所有权，这使他/她可邀请用户参加会议，将用户踢出会议，以及使用户不语。至于万维网会议，这是赋予用户7可加入同浏览与其相同网页的所有其它用户一道的文本会议或语音会议的特性的名称，。在万维网会议中，没有用户具有所有权。万维网会议组具有最多X个用户的规模(这可以应用的管理员设置)。如果超过此量的用户查看相同的网页，它们将被分成具有不超过X个用户的小组。万维网会议的用户接口使用户可容易创建其自身的文本、语音或视频会议，及邀请用户参加此会议。它也将使用户可容易查看会议中其它哪些用户可加入语音会议或视频会议。

对于语音邮件集成，用户7可通过应用来列举其语音邮箱的内容(即，查看有多少个消息，消息何时到达等)，并管理他/她的语音邮箱(即，删除消息等)。用户7也可以使用应用处理其邮箱中的任一消息。用户7也可以使用他/她的标准电子邮件程序发送消息(例如，单击联系的电子邮件地址)。用户在有新电子邮件(每X分钟检查)时可能会收到通知。如果有新邮件，用户能够容易地使系统/网络打开他/她的电子邮件程序以读取消息。除此功能外，应用可将不同的消息类型转发到用户的电子邮箱。用户可具有专用于本发明的系统/网络的电子邮件地址，这样，系统/网络可路由电子邮件，也可实现匿名性。

本发明的系统/网络最好设计为可通过许多不同客户/用户访问。应用后端的功能可从任何客户访问(虽然可能需要桥接工作)。几个客户在该应用的范围内。“全客户”以文本和语音能力为特色，是具有到服务器的持续连接的标准GUI程序。此类型的客户是在我们说“用户应能够做X”时通常所指的一种客户，即此类型的客户是允许用户做X的那种类型客户。其它客户是此类型客户的剥离版本(strip down version)，或是受限的客户。“瘦客户(thin client)”是全客户的剥离版本，缺乏其一个或多个特性(例如，音频聊天)。“万维网客户”是一个很基本的应用客户，它只可以使用户访问已形式允许浏览器(form-enabled browser)，以向共同体中的任何人发送寻呼。无需满足什么要求便能够通过万维网等接收寻呼。万维网客户也可选择性地使用户转换当前在使用的简档。万维网客户可选择性地使用户查看其收件箱的内容并读取接收的消息。“电话客户”是允许用户拨打给定号码(按语音邮件的方式)并转换当前在使用的简档的客户。

例如，访问应用的用户有两种类别。对于付费客户(即电话公司终端用户)，要求是无论他们在何处登录到应用，用户经验是一致的(即，无数据存储在客户端)。对于因特网终端用户不做此要求。

后端管理至少可通过命令行工具或等同物进行管理，并任选地通过用户接口工具进行管理。如何处理用户注册可以根据每个电话公司来决定；一种情况下，它可通过由电话公司员工明确输入数据并运行管理工具进行；另一种情况下，它可通过运行管理工具、带有直接从用户收集的数据的CGI脚本或等同物进行。

后端上有关管理的一个特征是记录信息。可能记录关于营运商有关的系统操作的每个细节。记录哪些细节可通过管理工具来配置。可能容易地将记录数据从系统输入到其它软件包供分析和归档。

在本发明的一些实施例中，系统尽可能多的部分可具有到系统其它部分的定义明确的接口，且尽可能独立，因而有利于系统执行中的插入方法。这就是例如电话集成的不同部分的实现可以分割到几个单独组的原因。它也可用于在将来与至今不相干系统的兼容，例如对话代理技术。

应用可为用户提供单一、集中化的地址簿，该地址簿存储共同体中有关每个用户的用户信息，例如，它可以存储每个用户的全名和电子邮件、共同体名称及用户ID。它可选择性地存储其它内容，如兴趣、主页URL、电话号码等。共同体名称和电子邮件可以是公共信息。对于其它信息，用户可通过指定连同用户一起的组或组的逆，并将这些组与布尔算子相结合，来定义哪些用户可查看信息，哪些用户不可查看信息。在所有实施例中，用户无需能够浏览地址簿(即通过它寻呼)。然而，他们可依据对名称、电子邮件和共同体名称字段中整个字符串或部分字符串的搜索，能够在地址簿中找到用户。此外，可能依据整个用户ID找到用户。如果地址簿中许多用户符合搜索模式，则启动搜索的用户将看到所有这些用户，并要求依据尽可提供的有关每个用户的其它信息，在他们之间做出选择。例如，一旦用户Snooglepops在地址簿中找到用户Muffin，Snooglepops可将Muffin添加到其个人的伙伴列表(即联系列表)，并且还可以向Muffin发送寻呼而不将他/她添加到伙伴列表，以及能够请求Muffin加入会议。

伙伴列表(也称为联系列表)是一组用户。这些用户可由所述用户组织为分层结构的组。用户可位于不止一个组。所述用户可创建与消除组，将用户添加到组中，或从组中删除用户，以及能够在组之间移动或复制用户，及将组从分层结构中的一位置移到另一个位置。组是用户和组的容器(container)。默认情况下，存在下列组：

表6

每人(Everybody)	此组包括属于相同共同体的所有用户，不论这些用户当前联机与否。在用户界面中看不到此组，但在指定访问数据时可使用此组。
		伙伴(Buddy)	这是您全部伙伴的总和，伙伴列表分层结构的根。
不可见(Invisible)	这是该用户添加讨厌用户的特殊组。该用户的联机状态是此组中的用户无法看到的(这可以通过向这些用户始终显示该用户处于离线状态来实现)，且此组中用户发送的消息从不会到达该用户(虽然对于讨厌用户，发送无内容消息将指示该消息未被接收)。此组不是伙伴列表分层结构的一部分，而是处于单独的分层结构中。
		经常联系(Frequentcontacts)	此组包括该用户最近发送寻呼或启动会议所涉及的X个用户，其中X是可由用户设置的优先选择。此组无法用于访问控制。

用户可选择在另一用户将其添加到那个用户的伙伴/联系列表时被通告。另外，通过匆匆看一下伙伴列表，用户可看到他/她的伙伴的联机状态。伙伴列表可提供伙伴联机状态改变的可视通知，以及提供任选的用户可设置的音频通知。用户可以查看存储在整个地址簿中的信息以了解他/她的伙伴列表中的任何用户。

至于寻呼，用户可向他/她的伙伴列表上的任何用户以及使用地址簿找到的任何用户发送短文本消息(STM)。接收用户是否可看到这些消息取决于接收者的联机状态以及接收者是否发送用户看不到自己。接收消息的默认方式是通过客户。除此之外，用户可指定能接收SMS消息的GSM电话号码，可以下列方式之一使用(用户可设置的)：1)用户可指定将用户的RS 33允许传到客户的所有消息转发到GSM电话；2)用户可指定将用户离开其终端或离线时到达的所有消息转发到GSM电话。

可能存在短文本消息的最大长度，或者短文本消息在通过SMS转发到GSM电话时可能被缩短，实现哪一项是设计决定。发送短文本消息时，是否应答另一用户发送的消息，用户可选择他/她以前配置的库存消息并用作消息的正文。当该用户被不在他/她的伙伴列表中的用户寻呼时，被寻呼用户可将寻呼用户添加到他/她的伙伴列表，也可容易地应答此消息而不将该寻呼用户添加到他/她的伙伴列表。用户被寻呼时，该用户可容易地邀请寻呼发送者加入文本或语音会议。在一些实施例中，消息可能表示为紧急消息。在一些实施例中，用户可能基于用户组和各个用户来选择消息的多个接收者。消息可以发送到的总用户数可受到限制，以防此功能用于发送兜售信息。

有两种不同的用户接口可用于启动谈话或向另一用户发送消息，一种用于无经验的用户，一种用于有经验的用户。操作用于无经验用户的界面要花费更多时间，但使用更容易，带有更多有用的动作说明和更多图片等，以便在操作时帮助用户。

用户的客户最好可显示所有以前输出和输入的消息的列表，还有这些消息发送的日期和时间、发送方/接收方及消息的内容。用户应能够从此记录中删除消息以节省空间。用户应可以通过两个标准之一或组合这两个标准来限制显示的消息：是否是输出或输入消息以及消息发送用户/接收用户。此外，也许可只显示实际消息(无通知)。

发送到用户收件箱的短文本消息(STM)可直接从收件箱读取。在通知把消息传送到某一消息储存库的通知消息的情况下，用户也许可请求应用检索该消息。应用随后可检查消息储存库，了解该消息是否仍存在，并且如有可能，会检索该消息。对于语音邮件和电子邮件的一些情况下，这是可能的，而对于传真消息的情况，这是不可能的。

用户可设置库存消息的分类(“我走了”、“我忙着”等)。自动应答是指应用代表用户自动使用这些库存消息之一。每个用户具有一个联机状态，它定义是否可与该用户取得联系以及在另一用户寻呼他/她时使用哪个自动应答(可能不使用自动应答，且用户自己可自由回答)。对于此版本应用，有一固定的联机状态集供用户从中选择，如下表7所示：

表7

联机且可达(Onlineand available)	所有消息(除了看不到自己的用户发来的消息外)可到达。
		联机但没空(Online butoccupied)	只有紧急消息直接到达，其它的由用户选择的库存消息自动应答，并在该用户改变到“联机且可达”模式时显示给该用户。
联机但离开终端(Online but away fromterminal)	消息不直接到达。在此模式时，该用户可选择对发送给自己的消息进行自动应答。
		脱机，不可达	与前面的相同。

用户可以指定即使其联机状态为“请勿打扰”(do not disturb)时可到达他/她的用户或用户组。伙伴列表中定义的任何一个所述组或所述组的逆(即不在所述组中的所有用户)可用于对此进行指定。对于每个可用联机状态，可以有一个类属的、准备好的库存应答。对于表示消息通过SMS已转发或复制到用户的GSM电话的每个联机状态，也可以有一个准备好的库存应答。用户可以选择是否让消息发送者知道其消息被路由到该用户的GSM电话。无需满足什么要求便能够使用SMS对消息进行回答或能够从SMS系统向用户发送消息。

关于文本会议，用户7可向他/她的伙伴列表上的任一用户或者向他/她使用地址簿找到的任一用户发送要求加入由发起用户主持的文本聊天会议的请求。请求可附带为何做出请求的用户解释。收到加入聊天会议的请求后，接收用户可选择参加会议或不参加会议，或者选择忽略请求(在您让某一用户看不见您而该用户邀请您参加会议时，便会发生此情况)。用户的响应可附带他做出响应的原因。一旦会议开始，发起用户在会议中具有特殊权限，可以邀请其它用户参加会议(可能附带解释)，将用户踢出会议(可能附带解释)，和/或给予或剥夺在会议中发言的权利。会议的所有用户可使用文本进行聊天，并且会议会显示不同用户发送的消息历史记录(例如，IRC等)。所有用户也可以简单的方式表现(如在IRC中一样)其感情，即，让其它用户知道他们在微笑。文本会议可能可以处理至少20至30个用户。在一些实施例中，具有特殊权限的用户退出会议时，会议最好被解散。

在语音会议实施例中，语音会议是文本会议加上使用语音进行聊天的功能。在多个用户同时说话时，他们分别输入的声音会混合在一起，形成输出。音频质量可能取决于编解码器，且可能取决于可用带宽。假定使用GSM编解码器，但这样的假定不是要求必备的。只有具有接收和发送语音信号能力的用户可参加语音会议。

至于用户7之间的视频会议，视频会议是语音会议加上看到当前声音最大的用户的能力。只有具有接收和发送语音和视频信号的用户可参加视频会议。另一选择是用户7之间执行万维网会议。

本应用针对可访问因特网且在电话公司具有帐户，并从电话公司收到了其应用的用户。这些用户是想使用因特网通信的包括新手到老手的任何人。本应用也针对访问因特网且通过因特网收到了其应用(不是通过电话公司)的用户。这些用户是想使用因特网通信的包括新手到老手的任何人。

实际上，共同体营运商是电话公司的技术人员。可以想到他们使用命令行工具管理系统、设置支持网关和服务器等，他们在进行此种工作方面受过培训。

在一些实施例中，对于用户7的客户，终端用户要求可能如下：

·28.8波特调制解调器连接，视编解码器而定的用于语

  音的更高带宽

·Windows 95或更新操作系统、Windows NT或更新操

  作系统、WindoWs CE或MacOS操作系统

·16Mb内存(Windows CE版本为4Mb)

后端软件可在Windows NT和几个主流Unix操作系统(至少Solaris)上运行。只要对服务器机器(处理器的数量/速率，内存大小，带宽，I/O速率)投入更多资金，它可以得到很好的扩展。

在一些实施例中，客户端应用可通过SOCKS防火墙工作，而系统管理员无需进行任何特殊设置，也可让系统管理员打开很有限数量的端口通过其它防火墙工作。客户端应用可能是个小应用。我们假定功能丰富(虽然不必具备全部功能)的安装程序版本可装于一个标准软盘(1.44Mb)。应用可能具有明显快的启动时间，且其UI可在所有环境下作出响应。

客户端应用的整体健壮性可比得上其它终端用户软件。特别是，它可以：1)以简明语言通知用户与他有关的任何错误消息。如果连接丢失，自动地使用户尝试重新连接。2)在应用的后端软件已更新时通知用户，并向用户指出下载新版本客户软件的位置；和/或3)在客户软件正在进行连接并且发现应用的后端已更新时，客户软件可自动下载并安装其新的版本。

因此，虽然是关于最佳的示例实施例来描述本发明，但可以理解此公开内容只是对本发明的说明和示范。因此，本发明只受后附权利要求书的范围的限制。

Claims (20)

1.一种用于允许各个用户与其它用户建立通信的服务器网络，所述网络包括：

第一和第二服务器群集，每个群集包括用于执行用户服务的至少一个用户服务器和用于连接到其它群集中的远程群集内服务器的群集内服务器；

所述第一群集中的所述用户服务器包括用于分配到所述第一群集的第一用户的路由服务，并且所述第二群集中的所述用户服务器包括用于分配到所述第二群集的第二用户的路由服务；

其中所述第一用户可以发送通信邀请消息或请求给所述第二用户，而无需知道正由所述第二用户利用的客户类型，其中通过所述第一群集中的所述用户服务器、所述第一群集中的所述群集内服务器、所述第二群集中的所述群集内服务器及所述第二群集中的所述用户服务器，所述消息或请求被转发给所述第二用户的客户；以及

其中用于所述第二群集的所述用户服务器中的所述第二用户的所述路由服务将所述邀请消息或请求转发给所述第二用户的客户。

2.如权利要求1所述的网络，其特征在于所述第二用户的客户包括个人计算机(PC)、移动电话和寻呼机的其中之一。

3.如权利要求1所述的网络，其特征在于每个群集还包括用于把所述群集连接到各个用户的各个客户的至少一个连接服务器，并且每个群集还包括数据库，用户服务器可以从所述数据库访问用户信息。

4.如权利要求3所述的网络，其特征在于每个群集包括多个用户服务器、多个群集内服务器和多个连接服务器。

5.如权利要求1所述的网络，其特征在于：在每个群集中，所述用户服务器执行用于各个用户的路由服务，并使各个用户可以监视所述网络中其它被选用户的联机状态。

6.如权利要求1所述的网络，其特征在于所述第一用户向所述第一群集注册并被赋予一个唯一用户身份(UID)，所述UID包括专门标识所述第一群集的群集标识符，以致所述第一用户的UID构成所述网络中全局唯一的ID；以及

其中所述第二用户向所述第二群集注册并被赋予一个唯一用户身份(UID)，所述UID包括唯一标识所述第二群集的群集标识符，以致所述第二用户的UID构成所述网络中全局唯一的ID。

7.如权利要求1所述的网络，其特征在于：当所述第一用户正在使用个人计算机(PC)作为客户时，所述第一和第二群集允许所述第一用户和第二用户以下列方式中的每一种方式互相通信：1)使用PC对PC通信的文本聊天；2)使用PC对PSTN电话通信的语音聊天；以及3)使用PC对移动电话通信的语音聊天。

8.如权利要求7所述的网络，其特征在于：当所述第一用户正在使用个人计算机(PC)作为客户时，所述第一和第二群集允许所述第一用户和第二用户以另外的下列方式中的每一种方式互相通信：4)使用PC对PC通信的寻呼；5)使用PC对SMS通信的寻呼；以及6)万维网会议。

9.一种创建第一和第二用户之间的通信会话的方法，所述方法包括以下步骤：

所述第一用户的客户在所述第一用户的用户服务器中创建通信会话；

所述第一用户的所述客户将所述会话的地址编码到邀请消息中；

所述第一用户的所述客户通过至少一个中间服务器把所述邀请消息发送到所述第二用户的用户服务器；

在所述第二用户的所述用户服务器上，所述第二用户的路由服务把所述邀请消息转发给所述第二用户的客户；以及

所述第二用户的所述客户接受所述邀请消息并连接到所述通信会话。

10.如权利要求9所述的方法，其特征在于所述第一用户的所述用户服务器、所述第二用户的所述用户服务器及所述至少一个中间服务器中的每一个都在服务器的第一群集中，且所述第一和第二用户中的每一个用户都分配有包含有群集标积符的用户标识符(UID)。

11.如权利要求9所述的方法，其特征在于：视所述第二用户当前正在使用的所述客户而定，所述通信可以是PC对PC、PC对PSTN电话及PC对移动电话中的每一种，且所述第一用户在发送所述邀请消息时无需知道所述第二用户当前正在使用的客户类型。

12.如权利要求9所述的方法，其特征在于所述第一用户的所述客户通过至少一个中间服务器把所述邀请消息发送给所述第二用户的用户服务器的所述步骤不需要所述第一用户或所述至少一个中间服务器知道所述第二用户的网络地址，所述网络地址诸如有IP地址或电话号码，由此可在所述第一和第二用户间设置通信，同时保持高度匿名性。

13.一种在第一和第二用户间建立通信会话的方法，所述方法包括以下步骤：

提供至少一个服务器群集，并为所述第一用户提供用户服务器和为所述第二用户提供用户服务器；

所述第一用户的客户将有关所述通信会话的邀请消息通过连接服务器发送给所述第二用户的所述用户服务器；

所述第二用户的所述用户服务器确定是否要将所述邀请消息转发给所述第二用户的PC或所述第二用户的移动电话，这取决于所述第二用户的所述PC的联机状态，并且相应地，所述第二用户的所述用户服务器将所述邀请消息转发给所述PC和所述移动电话中的一个；以及

所述第二用户通过所述PC或移动电话接收所述邀请消息并接受所述邀请。

14.一种网络，它包括：

第一群集和第二群集；

所述第一和第二群集中的每一个都包括多个与数据库进行通信的用户服务器、用于连接到外部用户客户的至少一个连接服务器及用于与所述网络的其它群集进行通信的至少一个群集内服务器；以及

其中所述群集使连接到所述第一群集的第一用户可以与所述第二群集的第二用户建立通信会话，而所述第一用户不用知道所述第二用户的IP地址或电话号码。

15.如权利要求14所述的网络，其特征在于：通过利用包括群集标识符的所述第二用户的网络用户标识符(UID)，所述第一用户可将有关所述会话的邀请消息发送给所述第二用户。

16.如权利要求14所述的网络，其特征在于：视所述各个用户当前在使用的所述客户而定，所述群集和所述网络允许所述第一和第二用户间的所述通信会话为以下中的每一个：1)使用PC对PC通信的文本聊天；2)使用PC对PSTN电话通信的语音聊天；以及3)使用PC对移动电话通信的语音聊天。

17.一种登录到网络并使用网络的方法，所述网络包括多个群集服务器，所述方法包括以下步骤：

提供用户在使用的客户；

提供一个群集，所述群集包括连接服务器、至少一个用户服务器、映射功能及数据库；

所述客户发送登录请求给所述连接服务器；

所述连接服务器检查输入密码的有效性；

所述连接服务器从所述映射功来请求用户服务器ID，且所述映射功能选择用于所述用户的所述群集中的用户服务器；

所述连接服务器在所述被选用户服务器上设置所述用户的联机状态；以及

所述连接服务器预订另一用户的联机状态，以便所述用户可以监视所述另一用户的所述联机状态。

18.一种在包括多个服务器群集的网络中第一用户监视第二用户状态的方法，所述方法包括以下步骤：

为与第一连接服务器进行通信的所述第一用户提供客户；

为与第二连接服务器和第一用户服务器中的每一个进行通信的所述第二用户提供客户；

当所述第二用户的所述客户登录到所述网络时，所述第二连接服务器将表示所述登录的状态信息转发给所述第一用户服务器；

所述第一用户服务器将有关所述第二用户的所述状态的信息转发给所述第一连接服务器；以及

所述第一连接服务器将有关所述第二用户的所述状态的信息转发给所述第一用户的所述客户，以便所述第一用户可以监视所述第二用户的所述状态。

19.如权利要求18所述的方法，其特征在于还包括以下步骤：所述第二用户将所述网络的第二和第三用户添加到与所述第二用户相关的看不见列表，以便防止所述第二和第三用户监视所述第二用户的所述状态。

20.如权利要求18所述的方法，其特征在于所述第二用户的所述状态包括所述第二用户是否登录到所述网络。

Images