CN101411172A - 传递附加数据的电信呼叫 - Google Patents

Abstract

用户访问目的地，如呼叫中心6；呼叫中心生成用于插入到用户的个人地址簿(例如，在服务器3上)中的记录，该个人地址簿包含中心6的电话号码和关于事务的元数据。为了稍后就同一事件作出呼叫，用户利用他的电话或者通过单独的终端来选择地址簿条目，并且进行呼叫。中心6通过呼叫线路标识(CLI)接收到用户的电话号码，将其翻译(在8)成数据地址，由此它可以从3上的个人电话簿中“拉”出元数据。另选的是，服务器3可以将中心的电话号码翻译成数据地址，从而将元数据“推”入中心。

Description

传递附加数据的电信呼叫

技术领域

本发明涉及在电信系统中进行呼叫，特别是但不限于进行电话呼叫。

背景技术

电话用户在联系一个机构(特别是通过呼叫中心)时，往往因为发现由于多种原因他们无法在一次会话中完成事务处理而感到气馁。用户需要以更多的信息再次呼叫盖呼叫中心，或者呼叫中心承诺回电但没有这样做。无论哪种方式，用户都不得不向呼叫中心进行再一次的电话呼叫，以继续事务处理，而且经常不得不再一次经过一系列的语音菜单而到达正确的部门，每个语音菜单都需要按键(DTMT)输入，然后不得不重新解释先前查询的状态。

众所周知，呼叫中心接收客户的呼叫线路标识符(CLI)并用它来确定将入局呼叫路由到哪个代理站(US 4,987,587；US 5,537,470专为断开的主叫方；WO 2004/054209)。

同样众所周知的是，呼叫中心通过用户输入来接收客户标识，并用它来确定将入局呼叫路由到哪个代理站(US 4,932,021；US 5,537,470(电话信用卡编号用做标识符))。

众所周知，呼叫中心接收客户的CLI，并用它来获取客户数据(US6,327,359)。

在点击-拨号系统中，用户点击网页上的按钮以建立到呼叫中心的电话呼叫，众所周知的，提示用户输入诸如账号、电话号码等数据。(US6,792,102：网络服务器还记录了参与网络会话的代理的标识使得电话呼叫可以被路由至相同的代理)。

发明内容

本申请在权利要求中做了限定。

附图说明

下面参照附图来描述本发明的一些实施方式，附图中：

图1是电信网络的图示；

图2、4和6是例示了图1的网络的多种运行模式的图示；

在图1所示的本发明第一实施方式中，用户拥有电话1和计算机终端2。服务器3为该用户(以及其它用户)提供个人地址薄工具。个人地址薄(PAB)的核心是数据存储器，其中为特定用户存储了一组条目，每个条目都包含个人或者机构的名称以及此个人或者机构的电话号码。此处使用了表述“个人地址薄”，因为它是现有技术中的习惯用语：然而，应该注意的是，对于本发明的目的而言，个人或者机构的地址是不需要的，所以该地址薄中实际可以不包含任何地址。生成这些条目的方式将稍后描述。

用户使用其计算机终端，经由合适的数据网络4(例如互联网)来访问服务器。假设用户会通过一些登录/认证过程来获得对此PAB功能的访问(图中均未示出)。

用户的终端和PAB服务器为该用户提供了图形用户界面(GUI)，该用户随后可以借此在终端上查看地址薄条目，或者至少查看它们所包含的名称，并且例如通过在上面点击来选择该用户希望进行电话呼叫的名称。这样的操作向PAB发出了一条命令，即，获取电话号码并通过呼叫服务器5向所选目的地发起电话呼叫。呼叫服务器通过公共交换电话网(PSTN)7在该电话与希望的目的地(本例中为呼叫中心6)之间建立电话呼叫。可以理解，到此为止我们描述的这个功能都是常规的。因此，我们没有具体描述在服务器和终端上为该目的而提供的软件。

假定PSTN支持呼叫线路指示(CLI)的信令，并且对实现PAB/点击-拨号服务的呼叫服务器5的点击可以将呈现给目的地的呼叫线路标识设置为与用户电话的条目号码相对应。

为讨论的目的，假设由于用户先前已经联系过该机构所以和运行呼叫中心6的机构相对应的PAB条目已经被放置在PAB中，并且进一步假设呼叫中心应该在接收到与先前的事务相关的呼叫时，将该呼叫路由到先前处理该事务的同一操作员(或者到熟悉这类事务的操作员)和/或获取与先前事务相关的数据呈现给操作员，使他或她可以更有效地处理该呼叫。

为此目的，将元数据存储在PAB中。在本例中，存储的元数据是先前处理该事务的操作员的电话分机号码，以及用以标识事务的事务号码，从而呼叫中心可以利用该事务号码来获取数据。作为分机号码的备选方案，为了允许相同的分机在不同的时间由不同的代理来使用，呼叫中心可改为存储专用于先前处理该呼叫的代理的标识并且利用它的呼叫中心功能来定位该代理。元数据的性质可能会有所不同：例如它可以只包含事务号码，从而呼叫中心还必须查找分机号码；反之，它也可以包含所有需要的数据，从而呼叫中心不必查找自身的记录。在后一种情况下，呼叫中心可以避免存储大量关于客户的个人数据，而是依靠客户来提供和管理存储器。这样，仍然可以为终端用户提供高度个性化和定制的服务，但却没有信息存储和管理的负担。此外，用户可以控制所披露的元数据。

在另选实施中，用户可拥有带图形用户界面的移动电话1a：这种情况下，移动电话GUI可以代替计算机终端。这种版本的操作将不会单独描述，因为其基本上与已经描述的相同。GUI可以利用http协议以及SyncML格式(其详细说明可从开放移动联盟(Open Mobile Alliance)获得)恰当地与PAB进行通信。

当PSTN呼叫建立后，呼叫中心接收到发讯用户的CLI。下面我们将描述两种可选的机制，由此元数据也被传送到呼叫中心。

这两种机制都需要使用图2中的另一个服务器8，该服务器提供了从电话号码到相关数据网络地址的翻译。在本例中，假定该服务器是ENUM服务器，(按照IETF文档RFC2916和RFC3761中描述的)它使用像域名系统(DNS)这样的翻译机制将E.164号码(例如，常规电话号码)翻译为数据地址。为了描述的目的，我们假定数据地址是通用资源定位符(URL)，如LDAP地址。

该处理从头开始表示在图3的流程图中。这里我们假设呼叫中心属于一家保险公司。

步骤101-用户与PAB3交互，如上文所述，以发起到该保险公司的呼叫。用户拥有该公司的保单，其详情存储在PAB中与该公司的电话号码相关的条目中。所存储的详情可以采用各种不同的形式。例如，在该保险公司的系统中唯一标识该用户的简单密钥。或者，详情可能明确地包含诸如持有保单的类别、保单的届满日期，以及来自终端用户上一次呼叫的日期的信息。换言之，所存储的信息可以是指向保险公司存有的数据的指针，或者可以是公司未存的附加信息。

步骤102-PAB通过PSTN发起到该保险公司的语音呼叫。该呼叫的CLI被设置为用户的电话号码。同时，PAB将所选条目标记为“呼叫进行中”。

步骤103-保险公司的呼叫中心6接收到该入局呼叫，并经由互联网4向ENUM服务器8发送利用该CLI在ENUM数据库中进行查找的请求。在这种情况下，服务器返回用户的PAB的URL。

步骤104-保险公司呼叫中心6利用在步骤103中获得的地址来建立到终端用户的PAB的数据连接，并且向PAB 3发送声明呼叫中心的电话号码的请求。(如果URL是对PAB服务器通用的而不是专用于该用户的PAB的URL，则也发送用户的电话号码)。PAB利用这一信息从PAB条目中获取元数据，并将其发送给呼叫中心。注意，如果PAB包含多于一个与呼叫中心的电话号码相匹配的条目，则它会从被标记为“呼叫进行中”的一条中获取元数据。呼叫中心现在可以利用这个信息，例如，来定制呈现给用户的语音菜单、将呼叫路由到适当的部门或者获取存储在呼叫中心系统中的与用户相关联的其它信息。

另选的是，PAB本身可以采取主动，如图4和图5的流程图中所示。

步骤201-如上述步骤101那样，用户选择与其期望呼叫的号码相对应的PAB条目；PAB获取保险公司呼叫中心的电话号码，以及相关联的元数据。

步骤202-PAB利用保险公司呼叫中心的电话号码，通过网络4在服务器8(例如，ENUM数据库)中进行查找。该查找返回一个与呼叫中心相关的地址(例如URL)。如果需要，可以将它缓存在PAB中以减少查找的次数。

步骤203-PAB利用在步骤202中获得的地址，通过网络4建立到呼叫中心6的数据连接，并且推送存储在PAB条目中的与保险公司相关的信息以及该信息涉及的标识了用户的其它详情(例如，该用户的个人电话号码)。呼叫中心将这些信息存储在缓冲存储器中。

步骤204-PAB通过PSTN7发起到保险公司的语音呼叫。该呼叫的CLI被设置为终端用户的电话号码，并且允许呼叫中心在它的缓冲存储器中寻找匹配条目，由此将入局呼叫与它在步骤203中获取的信息关联起来。呼叫中心这时可以按照在上述步骤104中概述的任何方式来使用在步骤3中获得的信息。

图2和4例示了两种基本机制，呼叫中心可以通过它们对存储在终端用户的PAB中的相关信息进行访问。第一种机制实质上是“拉模式”，即首先发现PAB的地址，然后呼叫中心从PAB中拉出信息。第二种机制实质上是“推模式”，即在接收到相关的语音呼叫之前，PAB将信息推送到呼收中心。

显然，这两种模式的变化都是可行的。例如在拉模式下，当PAB被呼叫中心联系时，它也可以进行ENUM查找以获得能够验证联系的来源与呼叫中心的电话号码存在某种关联的信息。

另外，虽然上面的描述是针对PAB 3位于远离用户的某处的情况下，但是当PAB位于用户的计算机终端2或电话1a中时，也可以实现同样的功能。

图6示出了一个另选版本，其中用户在这种情况下从电话设备1b，1c只进行电话访问，电话设备1b，1c不具备借以访问PAB的任何GUI功能(例如，使用基本的、模拟电话)。在这些情况下，终端用户发起到PAB3的语音呼叫(按照与他们可能访问网络宿主(network-hosted)语音信箱服务几乎相同的方式)。

PAB包含一个提供(语音或者DTMF驱动的)菜单系统的语音合成器，使用户可以搜索PAB并发起期望的呼叫。PAB与连接到PSTN的呼叫中心互动，以建立到所选目的地的呼叫。因此，在这种情况下，一条语音路径存在于终端用户、PAB/呼叫服务器和目的地之间。如图所示，该语音路径包含两条PSTN链路；然而，如果需要，呼叫服务器5a也可以被设置成建立单个呼叫，如图1所示，就像在根据需要来提供在网络中建立呼叫的工具的特定类型的点击-拨号系统中所进行的那样。这方面的例子是在英国由英国电信股票上市公司提供的批发万维网呼叫连接(Wholesale Web Call Connect)。

图7的流程图示出了下列步骤：

701用户通过电话1b或者1c呼叫PAB。

702 PAB使用它的语音合成器向用户读出一个选项列表：例如，“你的家里，按1，你的办公室，按2，你的医生，按3，你的保险公司，按41......”。

704用户在电话的DTMF(或者其它的)键盘上键入所需选项的号码。

705 PAB接收到该信令，中断其宣读，从元数据中获取保险公司(在该例中)的电话号码，然后从图3中的步骤102或者图5中的步骤202开始操作。

图2和4中的查找机制也适用于本例。

刚才描述的处理在很多情况下完全令人满意。然而，在多人共享一个电话号码的情况下(这在固定线路中很常见而且也会发生在移动电话的情况中)，如果两个人共享一个电话号码却希望拥有独立的个人地址薄，则可能会在步骤103或者202的翻译处理中造成不明确。此外，在第二种情况下，如果用户从另一个电话而不是与他的PAB相关联地注册在ENUM服务器上的那一个(或者几个)电话上发起呼叫，则系统将不会如上述描述那样工作。

因此，更可取的是，我们将呼叫的CLI设为终端用户的个人电话号码(例如，07000 123456)。这个号码唯一标识了终端用户，而与他们实际上使用的电话设备无关。这个号码在某种意义上是一个虚拟的电话号码，虽然它与电话相关联，却不与任何特定的电话永久关联。这使得系统能够分辨出在同一电话上打电话的两个用户。因此，家庭成员有效地“共享”同一个固定电话号码，但是仍能能够利用该系统分辨出各个成员。同样，用户可以从任何电话上拨打电话。当然，当访问PAB时用户有必要标识自己，因为PAB不能仅从入局CLI上来分辨用户。

另一个改进是针对每个电话号码，维持对特定用户是唯一还是通用的记录。唯一的号码将包括个人电话号码，以及因为它属于仅居住了一人的地址下的固定电话，或者是只被一人使用的移动电话而事实上是个人电话号码的普通电话号码。通用号码将包括通常被一人以上使用的电话的号码。接收到CLI后，呼叫中心6检查记录以确定该CLI是否被记录为对特定用户唯一。如果是，则进行先前描述的操作；另一方面，如果号码是通用的，则呼叫中心可以进入可借以确定主叫方的身份的附加对话。该记录可以维持在呼叫中心本身处，但更优地是在服务器8中，因此，在图3的查找处理中，该信息将在步骤104中被获得。如果希望将ENUM服务器修改为返回两个或多个数据地址，每个都带有一个伴随名称，则该对话可用来确定哪个名称与主叫方相匹配。

我们还设想了这个系统没有地址薄，或者至少没有元数据的一个版本。在这个版本中，用户通过常规的PAB向呼叫中心进行电话呼叫，呼叫中心确定CLI是否唯一，如前段中所述。我们对这个版本的优选实现是用个人电话号码替换CLI，如前所述。然而，该“唯一性查找”可在没有CLI替换的情况下使用，在这种情况下，它甚至可以用于在常规的电话上发起的电话拨号。

我们现在讨论生成PAB条目的问题。需要生成它的一种情况是用户第一次打电话到呼叫中心。如果用户需要就相同的主题再一次联系呼叫中心，例如继续定购过程，或者因为本次呼叫被中断，则创建PAB条目可能是非常方便的。这个处理在图8的流程图中作了描述。

在步骤401，用户向呼叫中心进行电话呼叫。呼叫中心接收到用户的CLI。

步骤402-呼叫中心对ENUM服务器8进行查找，如前述步骤103中所描述的那样。然后它获得了PAB的URL。

步骤403-呼叫中心生成“新条目”消息，该消息包含用户的电话号码以及要加入到用户的PAB中的条目。如上所述，该条目包含机构的名称、其呼叫中心的电话号码以及事务号码。

步骤404-呼叫中心经由网络4将此消息传输到PAB。

步骤405-PAB中心接收到该消息。在这一点上，如果需要，可以包括安全检查。例如，PAB可以被设置成维持一份成员名称(或者电话号码)的列表，从而用户同意的成员被允许加入条目。随后可以将入局消息与该列表进行核对，只有当发讯方在名单上时才添加消息。另选的是，用户可以被警告(通过语音声明或通过他的计算机终端)该企图，并给予批准或者不批准所提条目的机会，使得用户可以对包含在PAB中的消息的披露进行控制。

步骤406-(如果安全检查通过)条目被添加到PAB中。

一个另选的或另外的安全功能是呼叫中心在它的“新条目”消息中包含其自身的数据网络地址，而PAB接收到它之后将进行查找(如步骤202那样)，以便将呼叫中心的电话号码翻译成它的数据地址(反之亦然)，并检查结果是否与“新条目”消息中的数据相匹配。

当用户拥有与PAB通信的计算机终端时，向PAB发送“新条目”消息的一种另选方案是向用户发送(例如，通过电子邮件)XML格式的文档，使用户可以选择允许(或不允许)PAB软件来分析以更新PAB条目。

一个次优操作是呼叫中心在电话上表示一系列指令，使用户在其终端上进行键入。

PAB也(或代替的)可以在与呼叫中心的语音呼叫过程中被增加和修改/更新，我们可以考虑一些更普遍的情况。最简单和最明显的是由用户来管理PAB(通过一些适当的GUI或者语音界面)，例如，删除不想要的或不正确的信息或者手动修改任何他们想要呼叫中心知道的一般偏好。

第二种情况是，PAB由于一个相关的事务而被更新，该事务(尚)未与语音呼叫相关。例如，用户可能点击网页上的超链接或者打开电子邮件的附件，从而访问信息，该信息随后被存储在PAB中的适当条目中。这种更普遍的机制开创了一些进一步使用的情况：

■可以创建电子邮件附件，它提供了音频会议服务的电话号码以及标识了要加入的特定会议的信息。该信息将针对该会议服务电话号码的条目而被存储于PAB中。对这个号码发起呼叫会将附加的存储信息传播到音频会议服务，使用户能够自动连接到正确的音频会议，而不需要拨打任何特别的授权代码。

■可以创建电子邮件附件或者超链接对象，它的作用像电子礼券一样。一如以住，信息与一个电话号码相关联地被存储在PAB中。当经由PAB向呼叫中心发起呼叫时，电子礼券将会被提供给呼叫中心并且可以某种方式来使用，从而对终端用户提供激励。

■在进一步的PAB增加的情况下，运行在用户的个人计算机上的应用程序可能拥有增加和更新该用户的PAB的权力。在一种设想的情况下，应用程序监测用户的计算机系统和网络连接的“健康”(例如，以确保所有相关的网络服务，如IP连接、DNS、电子邮件等都工作正常)。有关这些服务的配置和状态的信息存储在PAB中，在各种情况下都与相关服务供应商的电话帮助台号码相关联。如果出现了一些故障，并且终端用户通过他们的PAB发起了对帮助台之一的呼叫，则他们的计算机系统的最新状态可以自动提供给该帮助台，以帮助诊断故障。

进一步的增强方案(可用于其他情况)是对与存储的信息相关联的届满时间/数据进行编码。这个数据可由PAB或者呼叫中心来解释以确定存储的数据是否能有效使用和/或它是否应该予以删除。在音频会议的情况下，存储的信息在安排的会议时间过后将到期。另一种可能是，呼叫中心在完成特定事务处理后，向PAB发送消息，指示它删除相关的条目；或者用新条目来代替它。

在全部上述情况中，多次提到PAB发起呼叫的目的地是呼叫中心。应该理解的是，这仅代表了一种设想的情况。一般而言，任何适当配置的目的地都可以替代上述情况中的呼叫中心，即，能够解析出入局呼叫的CLI、利用元数据，并且(在本发明的特定实施方式中需要时)在某些数据库中进行CLI的查找并建立与PAB的数据连接以便从PAB中获取、增加、更新或者删除信息的目的地。

我们已经提到了一些与安全和隐私有关的问题。一般而言，可以设想各种不同的、已知的机制来消除安全顾虑，特别是确保用户的PAB在未经适当授权和检查的情况下不被访问或更新。这涉及从在释放或允许更新PAB信息之前提示用户到利用机制来验证呼叫中心的身份并确保它只能访问和更新与它有关的条目。

提供控制使得终端用户可以选择性地向呼叫中心披露关于PAB的信息是非常重要的。在某些情况下，他们可能希望释放所有的相关信息以获得尽可能最好的体验。而在其它情况下他们可能希望以“匿名的”方式出现。

我们所描述的此系统的基本概念是要在基本PAB数据(例如一家公司的地址和电话号码)上增加在该PAB中与该条目中相对存储的其它信息。

这些附加的存储信息的种类基本上是没有限制的，下面提供了一些示例：

·对于从一家公司购买的的产品，产品ID、序列号等的存储。这些信息可以用来将终端用户路由到适当的部门并将产品信息自动呈现给呼叫中心代理。

·用户偏好的存储，全体偏好或者专用于任何特定呼叫中心的偏好。终端用户可以将这些偏好存储在它们的PAB中以使得这些愿望可以被提交给任何呼叫中心使其表现得似乎(a)“理解”他们以及(b)能够/愿意这么做。这些用户偏好可能包括优选语言或者对于缩短语音菜单的偏好。

·保单的届满日期的存储。该信息可用来根据届满日期的临近程度来倾向性地选择呈现给用户的语音菜单。例如，假设在大多数的保单持续期间，任何从该用户发来的呼叫都更可能是关于索赔，所以要路由到索赔部门的选项可首先呈现。随着保单结束的临近，假设从该用户发来的呼叫更可能关于续订保单，所以语音菜单可以被构建为首先呈现这一选项。

·并非专用于任何特定呼叫中心的一般用户信息(例如，地址详情)的存储。在这种情况下，用户的地址信息可以通过PAB以电子方式来提供，以便能被呼叫中心代理立即获得。这在这种情况下可能是特别有益的，即，该呼叫是用户第一次与公司联系，所以该公司没有存储其任何详细资料。

上面讨论的本发明的实施方式是在假定语音呼叫是经由PSTN作出的情况下描述的；然而，利用综合业务数字网(ISDN)也同样可以很好地实施上述实施方式。此外，也可以适应其它类型的电信呼叫，例如数字电话(甚或多媒体)呼叫。因此，在基于互联网的语音呼叫(VoIP)的情况下，系统以基本上相同的方式运行，不同点仅在于相当于主叫方电话号码的是其会话发起协议(SIP)地址，该SIP地址像CLI一样被传送到接收方。因此，在VoIP版本中，在上文描述提到的传输或CLI的查找会改为引用该SIP号码。

Claims (21)

1、一种操作电话系统的方法，该方法包括以下步骤：

用户访问存有多个条目的存储器，每个条目都包含一电话号码；

在该用户选择了条目后，建立从该用户的电话设备到由所选条目中包含的电话号码所标识的目的地电话设备的呼叫，所述呼叫向目的地电话设备发送了该用户的电话号码；

其特征在于，所述条目中的至少一些还包含附加数据，并且该方法还包括以下步骤：

目的地设备接收到所述呼叫后，将所述用户电话号码翻译成该存储器的访问装置的数据地址并向所述数据地址发送对于附加数据的请求；

所述存储器访问装置接收到所述请求后，将该附加数据发送给目的地电话设备。

2、一种操作电话系统的方法，该方法包括以下步骤：

用户访问存有多个条目的存储器，每个条目都包含一电话号码；

在该用户选择了条目后，建立从该用户的电话设备到由所选条目中包含的电话号码所标识的目的地电话设备的呼叫，所述呼叫向目的地电话设备发送了该用户的电话号码；

其特征在于，所述条目中的至少一些还包含附加数据，并且该方法还包括以下步骤：

该用户选择了条目后，将所选条目中包含的电话号码翻译成目的地电话设备的数据地址并将该附加数据发送至所述数据地址；

在目的地电话设备处，将该附加数据与入局呼叫关联起来。

3、一种操作电话系统的方法，所述电话系统包括：用于存储与用户有关的多个条目的存储器，每个条目都包含一电话号码；以及访问装置，用户可以由此来查阅该存储器并向与存储在其中的电话号码相对应的目的地发起电话呼叫，该方法包括以下步骤：

进行从用户站到目的地站的电话呼叫，所述呼叫向目的地站发送了该用户的电话号码；

在目的地站处，生成一条包含目的地站的电话号码的消息，并发送所述消息；

接收所述消息并将其中的电话号码插入到该存储器的条目中；

用户接着选择了该存储器中的条目后，利用所述电话号码建立从用户站到目的地站的电话呼叫。

4、根据权利要求3所述的方法，其中这些存储器条目能够容纳附加数据，该消息包含了与电话呼叫主题相关的附加数据，并且向存储器的条目中插入电话号码的步骤包括将该附加数据插入到该条目中。

5、根据权利要求3或4所述的方法，该方法包括以下步骤：在发送该消息之前，将用户电话号码翻译成该消息指向的数据地址。

6、根据权利要求3、4或5所述的方法，其中该存储器位于远程服务器上。

7、根据权利要求3或从属于权利要求3的权利要求4～6中任意一项所述的方法，该方法包括以下步骤：目的地站接收到后续呼叫后，将所述用户电话号码翻译成该存储器的访问装置的数据地址并向所述数据地址发送针对附加数据的请求；

所述存储器访问装置接收到所述请求后，将该附加数据发送给目的地电话设备。

8、根据权利要求3或从属于权利要求3的权利要求4～6中任意一项所述的方法，该方法包括以下步骤：用户选择了条目后，将所选条目中包含的电话号码翻译成目的地电话设备的数据地址并将该附加数据发送至所述数据地址；

在目的地电话设备处，将该附加数据与入局呼叫关联起来。

9、根据权利要求1、2、7或8所述的方法，其中翻译是通过向远程服务器发送包含了待翻译的电话号码的询问消息并从该远程服务器接收回复消息来执行的。

10、根据上述权利要求中任意一项所述的方法，其中临近该用户的所述电话设备而定位的该用户的数据终端用来访问该存储器并从中选择条目。

11、根据上述权利要求中任意一项所述的方法，其中该用户的电话设备包括该用户借以访问存储器并从中选择条目的图形用户界面。

12、根据上述权利要求中任意一项所述的方法，其中条目由语音合成器翻译成可听到的形式并且发送给用户的电话设备，而用户通过键盘或者经由语音识别器来选择条目。

13、根据上述权利要求中任意一项所述的方法，其中该存储器位于远程服务器上。

14、根据权利要求10所述的方法，其中该存储器位于该数据终端中。

15、根据权利要求11所述的方法，其中该存储器位于该用户的电话设备中。

16、根据上述权利要求中任意一项所述的方法，其特征在于，通过仅参照该用户的所述电话设备的电话号码以外的方法来确定该用户的身份，以及在呼叫中插入一存储号码作为该用户的所述电话号码，该存储号码并非该用户的所述电话设备的与所述身份相关联地记录的所述电话号码。

17、一种操作电话系统的方法，该方法包括以下步骤：

用户访问存有多个条目的存储器，每个条目都包含一电话号码；

在该用户选择了条目后，建立从该用户的电话设备到由所选条目中包含的电话号码所标识的目的地电话设备的呼叫，所述呼叫向目的地电话设备发送了该用户的电话号码；

其特征在于，通过仅参照该用户的所述电话设备的电话号码以外的方法来确定该用户的身份，以及在呼叫中插入一存储号码作为该用户的所述电话号码，该存储号码并非该用户的所述电话设备的与所述身份相关联地记录的所述电话号码。

18、一种操作电信系统的方法，该方法包括以下步骤：

用户访问存有多个条目的存储器，每个条目都包含一地址；

在该用户选择了条目后，建立从该用户的电信设备到由所选条目中包含的地址所标识的目的地电信设备的呼叫，所述呼叫向目的地电信设备发送了该用户的地址；

其特征在于，所述条目中的至少一些还包含附加数据，并且该方法还包括以下步骤：

目的地设备接收到所述呼叫后，将所述用户地址翻译成该存储器的访问装置的数据地址并向所述数据地址发送对于附加数据的请求；

所述存储器访问装置接收到所述请求后，将该附加数据发送给目的地电信设备。

19、一种操作电信系统的方法，该方法包括以下步骤：

用户访问存有多个条目的存储器，每个条目都包含一地址；

在该用户选择了条目后，建立从该用户的电信设备到由所选条目中包含的地址所标识的目的地电信设备的呼叫，所述呼叫向目的地电信设备发送了该用户的地址；

其特征在于，所述条目中的至少一些还包含附加数据，并且该方法还包括以下步骤：

该用户选择了条目后，将所选条目中包含的地址翻译成目的地电信设备的数据地址并将该附加数据发送至所述数据地址；

在目的地电信设备处，将该附加数据与入局呼叫关联起来。

20、一种操作电信系统的方法，所述电信系统包括：用于存储与用户有关的多个条目的存储器，每个条目都包含一地址；以及访问装置，用户可以由此来查阅该存储器并向与存储在其中的地址相对应的目的地发起电信呼叫，该方法包括以下步骤：

进行从用户站到目的地站的电话呼叫，所述呼叫向目的地站发送了该用户的地址；

在目的地站处，生成一条包含目的地站的地址的消息，并发送所述消息；

接收所述消息并将其中的地址插入到该存储器的条目中；

用户接着选择了该存储器中的条目后，利用该条目中包含的所述地址建立从用户站到目的地站的电话呼叫。

21、一种操作电信系统的方法，该方法包括以下步骤：

用户访问存有多个条目的存储器，每个条目都包含一地址；

在该用户选择了条目后，建立从该用户的电信设备到由所选条目中包含的地址所标识的目的地电信设备的呼叫，其中所述呼叫向目的地电信设备发送了该用户的电信地址；

其特征在于，通过仅参照该用户的所述电信设备的地址以外的方法来确定该用户的身份，以及在呼叫中插入一存储地址作为该用户的所述地址，该存储地址并非该用户的所述电信设备的与所述身份相关联地记录的所述地址。

Images