CN101107837A

CN101107837A - 数据处理的过程

Info

Publication number: CN101107837A
Application number: CNA2005800471649A
Authority: CN
Inventors: 伊登·德万
Original assignee: SMS Card Ltd
Current assignee: SMS Card Ltd
Priority date: 2004-11-25
Filing date: 2005-11-25
Publication date: 2008-01-16
Also published as: GB0517058D0; GB0425925D0; GB2420644A; GB2425192A; US20070202881A1

Abstract

在用于自动提供有关兴趣项目的信息的系统和方法中，每个这种项目的电话号码都被存储，并且对信息的用户请求对应到相关电话号码的地址。对于每一个这样的查询，都派生出一个用户号码，并且自动发送对应于该项目的数据给用户。该项用户请求典型就是语音呼叫，数据可以无需用户进一步的动作就被发送给该用户。用户号码的、请求细节的日志可以被累加并存储在用于分析或进一步数据检索的数据库中。本系统和方法可以有效地用于提供个人联系信息或财产信息。

Description

数据处理的过程

发明领域

本发明涉及了用于提供并使用供给响应于一项请求的联系信息的系统。本发明还特别但并非排他地涉及到一种方法，该方法用于发送以消息形式的联系信息给可使用消息的设备，以响应用户号码的语音呼叫。

背景技术

名片交换已经成为被广泛接受的快速便捷发布联系信息的方式。名片的存储功能为许多个人提供了历史参考点，从而使名片获得成功。然而，名片可能丢失或过时且需要单独携带(可能和很多其他卡一起)以便使用。名片因此产生了一个自然的两面性，个人保存名片增加了丢卡的风险，但是，卡的存储，例如卡索引，就防止轻易读取卡中所包含的信息。

随着具有高性能存储器功能的移动电话和个人数字助手(PDA)使用的增加，将联系信息电子化地保存在这些移动设备上已经迫切需要了。然而，把联系信息从名片上传到这些移动设备需要消耗时间。众所周知，可以从一个移动设备直接向另一个发送联系信息，但信息的数量和信息的格式是有限的，且如此直接的电子传送比起简单的名片交换要复杂得多并消耗更多的时间。

在这一方面，本发明的目的就是克服和改善与现有的发布联系信息有关的问题。

发明内容

根据本发明第一方面提出了一种用于提供响应请求的联系信息的方法，该方法包括步骤：把第一位用户的联系信息及其电话号码保存在联系信息数据库中；从第二位用户接收一个地址为第一位用户电话号码的请求；从所述的请求中，为所述的第二位用户派生出一个目的号码；从联系信息数据库中检索分配给所述第一位用户电话号码的联系信息；以及自动使得所述被检索的的联系信息对于使用被派生的目的号码的所述第二位用户来说可利用。

联系信息可以包括很广的范围领域，包括：姓名、公司、地址、电子邮箱地址、电话号码、万维互联网站地址等。第一位用户电话号码可以是标准数字交换号码/ISDN号码。然而在本发明某些实施例中，与第二位用户联接的通信设备(一般至少包含语音)的任一标识符都可以被使用。此方式可包括通过IP服务的语音标识符。

另一方面，本发明还为其他类型的信息提供了更广泛的应用，这些将在下面描述。

在一个实施例中，该项请求是对所述第一位用户号码的语音呼叫。在另一实施例中，虽然提示可以被用来能够选择提交选项，但联系信息并不需要来自第二个用户的输入就可以有用。请求还可以通过SMS或电子邮件来发出。

在此方式，通过对适当号码进行单独请求或呼叫，广义的联系信息可以容易地被用于个人请求。用户号码一般可包含在个人的名片中。此时的号码可以被快速容易地仅仅通过名片就进行发布，且接收方也可以通过简单的单独呼叫而在方便的时间请求联系信息。在某些实施例中，一旦被联接上，呼叫者就可以简单挂机以使得所被请求的联系信息对他或她可用。

在一实施例中，所检索的联系信息被发送到所述第二位用户的目的号码，且可以方便地使用电子化的格式，其在一实施例中允许直接电子化地被输入到存储设备中。

举例来讲，为了使用本系统，某一个人可以被传送其中带有用户号码的名片。在任一稍后方便的时间，该名片的接收者可以从所谓的手机(或其他可使用消息的设备)呼叫(或如果支持的话可以发送SMS文本消息)号码。然后，相关的信息(一般为有关个人名片的信息)在一实施例中，就以能直接存储的格式作为信息而被发送回呼叫(或如果支持的话，就是SMS文本)的号码。

名片上包含这样的号码使得该名片(虽然该号码可以被同等地而非名片本身进行发布)的接收者可以快速在手机或其他联系信息设备上获取相关联系细节。

在一实施例中，所检索的联系信息以SMS消息形式发送给所述用户，然而，联系信息也可以用电子名片、V卡、flash消息、多媒体信息/多媒体服务(MMI/MMS)消息、或其他适当的格式被发送。有效地，联系信息可以包含能作为图片和视频消息被发送的图像数据。使用图片消息，就可能发送例如名片的图像、个人的照片，或公司标志。还可以安排为当某人呼叫或被叫时显示这样的图像。这就可以极大地帮助识别和记忆第一位用户。

值得提倡的是，第二位用户能够选择使信息可利用或被发送的格式。如果请求被SMS消息发出，一个关键字或词就以指定的期待格式(例如，SMS消息的“text”，或名片的“bus”等等)包含于该项请求中。

重要的是，信息可以被存储并由请求该信息的个人快速容易的使用。因而，希望其格式应与第二位用户预期的应用程序兼容。随着用户需求的变化，其中使该信息可用的新格式也能够被提供，而不需要调整下面的联系信息。

被检索的联系信息可以附加或可选地通过语音而被提供。声音可以被用户记录下来并作为音频文件存储在联系信息数据库中，或可以通过利用文本到语音的方式而从被保存的该文本信息中提供出来。当没有被要求以电子化格式或用户不能收到电子化格式的信息(例如，通过固话线路)时，这就可为用户获取信息提供了简便的方法。

在一实施例中，第二个用户的目的号码是从被接收到的请求中自动派生出来的。此操作的首选方式是使用有关所接收请求的呼叫者线识别(CLI)，以从发送该项请求中建立号码。这一号码可以被用作目的号码。另外，如果CLI号码被识别为已经被包含在联系信息数据库中，它就可以被用作一引用来检索信息能被发送到的另一号码。在这种情况，信息可以有选择或附加地通过电子邮件而被发送到一个电子信箱地址里。

该号码可能被自动检索到的而不需回答呼叫；这就使得信息将能够被提供而对于请求用户的呼叫或呼叫接收来说并不需要付费(在某一免费电话号码的情况下)。

不是总能自动确定第二位用户的目的号码，第二位用户可以被提示目的号码。例如可以用语音提示。第二位用户然后就可以通过键盘或语音来输入号码，该号码可以利用技术手段从语音解释成文本。

方便地，可采用一自动序列的动作(包括默认和依赖性动作)来确定第二位用户的目的号码，并可选来提供所请求的信息。在一个实施例中，如果某CLI号是可使用消息的，则该CLI号就被用作目的号码，并且联系信息是由SMS消息发送的。如果某CLI号不是可使用消息的，则可使用消息号码的提示就被提供，并且/或者联系信息也附带语音提示。

在一实施例中，与第二位用户的界面是通过能提供一些自动的或基于用户的提示的交互语音响应(IVR)来提供的。这就增加了系统的灵活性并使联系信息对大量具有不同需求的各种用户都是可利用的。如果需要的话，用户就可以通过菜单系统得到引导。这就能给用户一些选择，诸如希望在其中接收联系信息的选择格式。但还是想要保持请求过程短暂并易于使用。

在一个实施例中，联系信息数据库包括：至少一个所述第一位用户电话号码，从而在发生一个请求的时刻第二位用户就可以与第一位用户的电话号码连接。通常，多于一个电话号码可以被存储，且第二位用户可以附加选择一个被连接的号码，或可以连接到一默认号码，并且，如果必要，就顺序连接到第二个或第三个号码，例如，假若第一个号码没有得到回答的话。

这样的方法提供了具有得到最新的联系信息能力的或被连接到任意已可利用的联系号码能力的呼叫者。因此，这就允许将被使用的号码作为一个联系的单独点，从而提供了可以通过办公室、家庭、手机找到的某人的或可以提供电子邮箱地址、传真号、办公室地址或其他联系信息的单独号码。

在某些应用中，希望它可以区分用户可以连接的不同种类的号码。例如，为了呼叫一将被连接的手机，第一位用户可能必须支付额外费用。

在一个实施例中，本方法进一步允许第一位用户输入或更新在数据库中所保有的联系信息。一些用户选项也可以被选择，诸如信息在其中被提供的默认格式，或可以被连接的第二位用户的优选号码。

与名片不同，保存在数据库中的信息可以被更新。这就意味着，如果多年以前就拥有名片的那些人需要提供包含一被分配的相应于数据库记录的号码，那么，他们所需要做的所有事就是，诸如呼叫(或如果支持的话，SMS文本)作为最新联系信息的号码，或另外请求连接到任意已经可利用的最新的号码。同样，如果该号码是属于一公司的，那它就可以被分配到一个特定位置或部门，并且，如果在某位置或部门中的人员发生变动，则联系信息就可能被要求更新。

如果第二位用户的目的号码被保存在请求数据库中，本方法可以提供增加的功能。这种情况，第一位用户可以被提供向第一位用户发出的请求的细节。细节可以包括请求的日期和时间，发生请求的号码以及信息响应于那些请求而被发送到的目的号码。请求报告可以有选择地发送给第一位用户。每天或每月所做的请求报告例如可以自动地在每天或每月的最后时刻(如果适当的话)被提供。

根据本发明的第二个方面，提出了一种用于提供响应请求的联系信息的系统，该系统包括：一个用于接收来自与第一位用户号码有地址联系的第二位用户的请求的输入界面，一个用于从所述请求中为所述第二位用户派生目的号码的处理器，一个用于存储与用户号码相关的联系信息的数据库，以及一个用于自动把与第一位用户号码相关的联系信息发送给所述第二位用户目的号码的输出界面。

本系统的一实施例还进一步包括一个允许所述第一位用户输入或更新与所述第一位用户号码相关的联系信息的用户界面。用户界面有希望是基于万维网(Web)的，从而使得用户可以自由地订阅服务和输入信息，或者更新信息。

根据本发明的第三个方面，提出了一种为自动发布响应请求的联系信息而建立订户联系信息数据库的方法，所述方法包括：允许订户在所述数据库中输入或更新联系信息；以及，提供订户一个或多个请求联系信息可以被寻址到的订阅号码。

订户通常可具有提供手工输入联系信息的能力，或通过其他存储位置来下载信息。本方法可要求输入一定的域(或字段)，也可以要求选择一定的选项。

一特定且有用的选项允许订户获得和/或控制多个订阅号码。这就特别适用于希望获得大“块”号码的公司。系统管理员然后就可以在该公司内单独分配号码。用户界面由希望是具有不同的安全级别，因而可以给用户组赋予权限。根据访问数据库的用户的安全级，一定的区域可以被编辑而其它的被锁定。例如，公司名称或位置域可只能被“块”管理员编辑。管理员可以有选择地分配不同的安全级和权限。

连续号码的块，或者说容易被记忆的号码很受欢迎并被有选择地发布，例如支付的费用，或仅仅如果某一最小号码的块被请求的话。

根据本发明的第四个方面，提供了一种用于监控订户联系信息系统使用情况的方法，所述系统包括用于存储订户号码和用于订户的相关的联系信息的订户数据库，并且所述系统允许用户从所述数据库中远程请求所述的联系信息。本方法包括：从用户处接收可以被寻址到订户号码的请求；从所述请求派生用户目的号码；以及，在使用情况数据库中创建包括所述被请求的订户号码及其相应的用户目的号码的所述请求的记录。

能够看到本发明的方法和系统可以有效地扩展到建立联系信息数据库以及监控和记录与该信息相关的交易。

本方法可以用于提供给订户对特定订户号码进行的请求的、以及与那些请求相关的用户目的号码的记录。这样的记录可以通过电子邮件发送给用户。

另外一个有用的选项是提供用户一个曾经发出的请求的、或与特定的用户目的号码有关的请求的，以及与那些请求被发出的订户号码相关的请求的记录。以此方式的用户可以对他或她以前所请求过的所有或任一联系人的联系信息进行监控。在一实施例中，该记录包括为响应那些请求而已被返回的联系信息，或可选或附加地，在所述订户数据库中与那些订户号码当前相关的联系信息。

举例来说，如果某人由于丢失了手机而丢失了其联系人列表和/或联系信息，本方法就可能非常有用了。对于通过使用请求而已经装载了大多数/全部号码的用户来说，所有以前被请求过的信息都可以被下载到新电话上或通过电子邮件发送。有鉴于订户被分类成组，与发给/来自那个组的任意一个成员的请求有关的数据可以被整理比较。一份报告然后就可以被提供给该组的一个或多个成员，例如，该组的管理员。

应该明白，可以对所记录的数据进行大量不同的数据提取和比较，并且，可以有潜力生成相应大量范围的报告。

根据本发明的第五个方面，提供了一种用于从第二位用户给第一位用户传送信息的方法，此方法包括如下步骤：从第二位用户接收对第一位用户号码的语音呼叫；记录来自所述的第二位用户的语音信息；从用户数据库中检索被分配给所述第一位用户号码的电子邮件地址；以及，通过电子邮件自动向所述第一位用户发送所记录的消息。

在一实施例中，该消息以经过数字化编码的音频文件形式而被发送给所述第一位用户，但也可以被使用语音到文本的处理过程来进行处理，并以文本形式发送给所述第一位用户。

本发明可以通过自资助方式有利地实现。在此情况，订户可以免费注册服务并获得一号码，而收入来自让发出请求的用户付费的方式。发出请求本身的基本费用和发出请求所花的时间的附加费用都可以通过电信提供商来支付，例如，在英国使用0871号码的情况。

额外费用的服务，诸如连接手机号码的请求的功能、可记忆的号码或一组号码，可以付费方式提供给用户。

因此，本发明可以相关于个人联系信息进一步描述，然而，值得提醒的是，下面发明的概念和相关的好处可以扩展到其他类型的信息。

根据本发明的其他方面，提出了一种用于为了响应用户的请求而自动提供对象项数据的方法，其包括如下步骤：

把用于第一对象项的和第一对象项电话号码的对象项数据存储在数据库中；

从用户处接收地址为所述第一对象项电话号码的查询；

从所述查询中为所述用户派生用户号码；

从所述数据库中检索所述第一对象项电话号码相应的所述第一对象项数据；以及

自动地将所述第一对象项数据发送给所述用户号码。

在一实施例中，用户查询是对所述第一对象项电话号码的声音呼叫，且对象项数据是以下面一个或多个形式发送给用户：SMS信息，WAP宣传，flash信息或视频流。

在此方式，用户可仅仅通过拨出一个被分配的号码就对感兴趣的项目发出一查询。用户不需要保存号码并可以几乎同时收到所选项目的数据。用户通常发出查询并在手机、PDA或其他移动数据支持的设备上收到数据。

某一实施例所述的数据库包括所述用户号码和相应的电子邮件地址，而在进一步的实施例中，对象项数据是附加或可选发送到那个电子邮件地址的。

值得提倡的是对每个项目保存多个电话号码，每个电话号码都对应一个单独项目。以此方式，一些渠道就可以被定义，每个电话号码都对应一个确定渠道。这就使得系统操作员从到来的查询中既可以获得所选择的对象项也可以获得诸如用于对项目进行广告的一类媒介的另一条信息。

方便地，数据库另外包括了每个项目的呼叫处理代理的数据，且本方法还另外包括自动把用户的查询传送到呼叫处理代理的步骤。

本发明的进一步特性提供了一种用于管理对象项查询的方法，包括如下步骤：

把用于第一对象项、第一对象项电话号码、和第一对象项呼叫处理代理数据这三者的对象项数据存储在数据库中；

从用户处接收地址为所述第一对象项电话号码的查询；

从所述数据库中检索所述呼叫处理代理数据和相应于所述第一对象项电话号码的对象项细节；

自动将所述用户查询传送给使用所述代理数据的所述第一呼叫处理代理；以及

自动使得相应于所述用户查询的第一对象项细节对所述呼叫处理代理可利用。

使得所述第一对象项细节可利用的步骤和传送用户查询的步骤是有希望基本同步执行的。值得理解的是，通过提供与查询的主题相关的细节，本方法允许呼叫处理代理用更明智和更有效的手段来管理查询。

在一个实施例中，方法还包括一步一步地从所述查询为所述用户派生用户号码的步骤并使得所述用户号码对所述呼叫处理代理可利用。如果数据库方便地包括了相应的用户细节，这些还可用于所述呼叫处理代理。

值得理解的是，对象项可以是系统用户潜在感兴趣的任意项目。本发明由于使得用户可以找到所关心的、具有相关号码的经广告宣传的产品，而特别适合但并不局限于销售行业。例如，产品的范畴可以包括简要的产品描述和电话号码。返回的细节可以是关键尺寸，组装说明，技术框图或甚至是安装/使用的视频序列演示。

号码的呼叫可以自动地通过合适的帮助桌面被传送，且帮助桌面操作员可以自动被提供与正发生的呼叫有关的产品的细节。

本发明的一个首选实施例涉及到财产和财产销售，并且有用的对象项是一份财产而且对象项数据包含财产细节。

财产细节可以因此由预期的买主仅仅通过呼叫FSB(销售公告板，For Sale Board)上的号码得以快速和容易的以例如文本、图像和/或视频的形式获得。邻近的其他财产可以被发送到预期的买主，如果他们有兴趣的话。

本发明的进一步方面提供了一种为自动处理用户查询而创建财产管理数据库的方法，此方法包括如下步骤：

允许卖方向所述数据库输入财产细节；

为每个财产分配一个或多个财产电话号码，每一财产查询都可以被确定地址；

为每个用户查询都派生用户号码；以及

为每个查询都存储所述的用户号码和所述的财产电话号码。

一般来说，通过提供有价值的营销分析工具，这就使得查询报告做好准备。

如果一个呼叫处理代理被分配给每个财产且查询被自动地传送到适当的呼叫处理代理，那么，呼叫的结果(连接/挂起/没回应等)也可以被用来记录和报告。

根据本发明这一方面的实施例可以容易用目前的不动产代理系统进行集成。

本发明的一个进一步方面提供了一种为自动处理用户查询而创建对象项管理数据库的方法，该方法包括如下步骤：

允许卖方向所述数据库输入对象项细节；定义多个渠道；为每个对象项都分配多个对象电话号码，对于这些对象电话号码来说，查询可以被确定地址，每个对象电话号码都相应于一个单独对象项和一个单独渠道；为每个用户查询都派生用户号码；以及，为每个查询都存储所述的用户号码、对象项和相应于所述对象电话号码的渠道。

本发明的这一特性有利地允许每个查询有两类被存储的信息，第一类信息与后来将被查询的对象有关，而第二类信息可以是操作员定义的域。所述第二类信息的特定且有用的域是查询已从中被获得的源或媒介。

本发明的一个进一步方面提供了一种用对象请求可以被寻址到的电话号码来标记对象项的方法，此方法包括如下步骤：提供一系列未被分配的电话号码；打印许多带有所述未被分配的电话号码的标记；在第一对象项上显示所述标记的第一个；以及，把在所述第一标识上的号码顺序分配给所述第一对象项，使得每个对象项都被分配所述系列电话号码中的一个不同号码。

本发明的一个更进一步方面提供了一种分配用于在所述财产查询可以寻址到电话号码的财产位置中显示的财产位置电话号码的方法，此方法包括如下步骤：

提供一系列用于在财产位置处进行显示的、未被分配的电话号码；

在第一财产位置处显示所述未被分配的电话号码之一；以及

顺序把所述被显示的电话号码分配给所述的第一财产位置以使得每个位置都被分配所述系列电话号码中的一个不同号码。

这就提供了用于管理FSB的方便机制。

附图说明

本发明现在可以通过带有相应参考附图的实例而得到描述，其中：

图1是根据一个实施例的SMS卡系统的一个原理框图；

图2a图示了根据一个实施例的SMS卡系统的呼叫处理流程图；

图2b图示了根据一个实施例的SMS卡系统的呼叫的进一步特性的处理流程图；

图3图示了根据一个实施例的呼叫者与SMS卡持有者连接的处理流程图；

图4是根据一个实施例用于结合本文所描述的系统的登录和注册界面的截屏；

图5图示了一个实施例的被用户用于设置SMS卡的数据输入截屏；

图6是一个让用户为个人分配SMS卡号码的屏幕的截屏；

图7图示了一个实施例中用于提示用户确认注册已经成功的确认截屏；

图8图示了在一个进一步的实施例中的可被用户用于设置SMS卡号码一个界面截屏；

图9图示了一个实施例中可被用户用于把已经被输入到SMS卡系统中的信息个性化的截屏；

图10图示了一个实施例中的让用户能够把SMS卡传送给所选择的信息通信设备的用户界面截屏；

图11图示了一个实施例中的团体登录截屏；

图12图示了一个实施例中的允许一个例如为公司的用户购买一顺序号码块的截屏；

图13图示了根据一个实施例的一个付款截屏；

图14图示了一个实施例中的购买确认截屏；

图15是图示一个进一步实施例的SMS卡系统呼叫处理的一个原理框图；

图16是图示根据一个实施例的呼叫者和注册用户连接处理的一个原理框图；

图17是结合本发明实施例的系统概况；

图18是根据本发明实施例的呼叫处理和数据库管理系统的流程图；

图19图示了与图2的流程兼容的数据库结构；

图20是可选择的数据库结构；

图21图示了一个用户界面的流程；

图22图示了一个代理管理的流程。

具体实施方式

实现本文所描述的SMS卡系统需要使用许多装置，现在就参考图1来介绍。

一个或多个输入界面110、112可以被提供来接收到来的信息请求。一个输入界面110可以接收从手机或有线电话或固话等到来的电话呼叫。第二个输入界面112可以被提供来接收以SMS消息112或其他电子消息形式的信息的请求。

通过电话输入界面110所接收到的请求可以被交互语音识别(IVR)和响应界面114处理。IVR界面114可以和呼叫者进行通讯以提供所请求的信息并提示呼叫者获取来自呼叫者的诸如选项选择的信息。

通过SMS或其他消息通信系统接收的请求可以被路由到消息通讯器设备116。消息通讯器设备116可以在消息通信网络和SMS卡系统之间提供一界面以用来在该系统和请求用户之间接收和/或发送消息。

处理器118可以被提供来接收经由任意界面的请求输入并分析这些请求，获取例如来自联系信息数据库120的请求信息，并以预期的格式输出信息。处理器118可以进一步被连接到万维网界面122来接收新的或被更新的订户信息。处理器可以分析和/或格式化通过万维网界面122所接收到的数据并将信息存储或更新到联系信息数据库120。

总之，如下一个或多个方法可以被提供来使用户通过利用SMS卡号码能够获取信息：

选项1：例如通过手机或固定电话来呼叫SMS卡号码。

选项2：向SMS卡号码发送SMS消息。

选项1：用户呼叫SMS卡号码。如果用户使用了手机并且没有拒绝自己的号码，则他们就被提供挂机并以默认格式接收SMS卡的选项或者通过响应一些提示，用户可以连接到可用的号码、收听信息或选择其愿意用来接收SMS卡的格式(被提供的格式可包括如下一个或多个：SMS、Flash、图片消息、名片、V卡、电子邮件)。

如果用户拒绝了自己的号码或从固话呼叫，则他们可以被请求键入SMS卡将要发送到的手机号码，并且可以被提供挂机和以默认格式接收SMS卡的选项。用户还可以响应一些提示并可以被连接到可用的号码、收听信息、或响应提示来确定其愿意用的SMS卡格式(被提供的格式包括如下一个或多个：SMS、Flash、图片消息、名片、V卡、电子邮件)。

选项2：用户向SMS卡号码发送SMS消息。如果发送给SMS卡号码的信息包含一条或多条预先确定的关键词，用户就可以用与关键词有关的格式发送SMS卡，此外还可以用默认格式发送SMS卡。

通过例如使用手机或固话网络来呼叫处理SMS卡号码(上面描述的选项1)的一个实施例，用如下方式展示：

a)用户呼叫SMS卡号码

b)IVR系统回答呼叫

c)如果用户在任意时间挂起而没有选择合法的选项和IVR系统已能够获取呼叫号码且呼叫号码是手机号码(或其他支持消息的设备)，则IVR系统会指示后端系统向呼叫号码发送SMS卡。SMS卡会以SMS卡号码持有者默认格式进行发送。

d)如果用户保持在线，他们将会被请求按“1”来接收SMS卡信息或按“2”来收听SMS卡信息，或保持与[办公室/专线/手机/家庭]的连通。然而，如果多于一个的号码已是可用的，用户就可被提供一个附加选项，即，按“3”来选择要呼叫的联系号码。

按“1”

如果IVR系统不能获取呼叫号码或呼叫号码不是手机(或其他支持消息的设备)号码，则IVR系统会(例如，用已经录音的声音)请求用户输入要SMS卡发送的手机(或其他支持消息的设备)号码。

IVR系统然后会(通过已经录音的声音)请求用户选择他们愿意用的SMS卡格式，用户然后可以用他们的电话键盘(DTMF)选择他们愿意用的格式。格式可以包括：SMS、图像、Flash、多媒体信息/多媒体服务(MMI/MMS)、名片、V卡等。IVR系统然后会指示后端系统用所选择的格式向呼叫号码发送SMS卡。

按“2”

如果一个WAV文件被上传，它就会被重新播放，此外，所有被存储的SMS卡信息会通过使用文本2语音软件按格式而被顺序提示(在一个实施例中，用户可能够选择信息被提示的顺序)。

按“3”(如果多于1个号码可用于呼叫)

IVR系统会请求选择将被接通的联系号码，即：按“1”用于手机，按“2”为办公室号码，按“3”呼叫家里。如果号码是手机或其他高速率设备号码，则待连接的选项可以被提供，如果呼叫者付费或者SMS卡号码所有者支付相关费用的话。

处理发送SMS到SMS卡号码(上面描述的选项2)的一个实施例现在将被更详细地描述。

a)用户发送SMS消息到SMS卡号码。

b)SMS处理系统会发出消息到后端系统，如果该消息不包含关键词，SMS卡会以SMS卡号码持有者默认格式被发送到SMS消息来自于其中的号码。

c)如果SMS消息包含关键词，后端系统将会以关键词适用的格式把SMS卡发送给曾发送该SMS消息的号码。关键词的例子可以包括：“SMS”表示SMS消息，“PIC”或“PICTURE”表示为图片消息，“FLASH”为Flash消息，“MMI”或“MMS”为MMS(多媒体)消息格式，“B”“BUS”“BUSINESS”“BCARD”为名片格式，或“V”“VCARD”为V卡格式。

根据一个实施例的SMS卡服务的应用现在将参考图2a，2b和3来更加详细地介绍。

如上所述，为了检索与注册用户有关的信息，发出请求的用户可以电话接通SMS卡号码。如图2a所示，系统可以根据下面的过程进行确认处理：

a)接收呼叫的界面可以联系后端系统(例如，处理器和联系信息数据库)来检查已被呼叫的SMS卡号码有一个相关的经注册用户(步骤210)。

b)以此方式，系统确定被呼叫的号码是否合法(步骤212)。

c)如果该号码不合法，举例来说，如果数据库中没有相关的用户，则一条记录消息就会被播放给那个发出请求的用户(步骤214)，例如“你呼叫的号码作为系统的一部分可用于注册。请进入www.smscard.co.uk了解详情。谢谢你的呼叫。”呼叫然后就会结束(步骤216)。

d)如果号码合法，可用选项的细节会被发送给发出请求的用户(步骤218)，例如一条记录信息就会显示“谢谢你呼叫SMS卡名片存储服务。为了检索信息，现在就请在你的电话键盘上按1或保持在线以便与SMS卡用户连接”。本文所描述的进一步的选项可以被提供。

e)如果呼叫者按1，则信息以默认格式被传送到发出请求的用户。

f)如果呼叫者保持在线(步骤222)，则系统会设法使用户与使用默认联系方法的注册用户相连接。

图2b原理性图示了根据一实施例，检索信息或与注册用户连接的处理过程。

a)当从发出请求的用户中接收到电话呼叫时，系统确定发出这个请求用户的呼叫者线标识(CLI)是否与手机的CLI相关(步骤250)。

b)如果CLI不是手机CLI，系统就会播放一条记录信息给呼叫者以请求该呼叫者输入该CLI应被发送到的手机号码(步骤252)。

c)用户输入的号码可以被系统找到(步骤254)，例如通过使用拨号音多频率(DTMF)系统。

d)系统然后可检查输入的号码以确保该号码对应于可以接收默认格式的信息的设备(步骤256)。例如在英国，系统可以通过检查号码是以077，078或079开头来验证输入的号码是手机号码。

e)如果输入的号码不能接收默认类型的消息，则一条出错消息会被发送给用户(步骤258)且系统使用户能够输入另外一个号码，例如“你输入的号码不合法，请再次输入”。

f)如果发出呼叫的用户的号码是手机号码，或如果被验证的手机号码已被输入，则用户就会被呈现一个数字选项(步骤260)，例如“请从下面的选项选择。如以普通文本方式接收SMS卡信息，按1。以名片方式，按2。以V卡方式，按3”。

g)如果该呼叫者按了1，系统就会联系到后端系统以指示后端系统生成并发送SMS消息(步骤262)。

h)如果呼叫者按了2，系统会联系到后端系统指示后端系统生成并发送名片(步骤264)。

i)如果呼叫者按了3，系统会联系到后端系统指示后端系统生成并发送V卡(步骤266)。

j)一旦信息被发送，会通过如下的语音信息得到请求用户的确认(步骤268)，“信息已经被发送。如结束本次呼叫请现在挂机或保持在线以便与SMS卡用户连接”。

图3图示了一个实施例处理用户与注册用户连接的过程：

a)在发出请求的用户的请求中，注册用户首选的固话号码从后端系统中被找到(步骤310)，例如从一联系信息数据库中。

b)呼叫被连接到所找到的号码(步骤312)。

c)如果呼叫被应答，则所述发出请求的用户和所述已被注册的用户都被连接(步骤314)。

d)如果呼叫被被应答，则某一条消息就可能发送给所述请求用户，例如“按3留下语音消息或保持联机尝试另一号码” (步骤316)。在另外的实施例中，系统可以从后端系统中找到下一个联系号码并试图用那个联系号码联系所述注册用户。

e)如果下一个联系号码是可用的(步骤318)，则系统会尝试连接注册用户到这个号码。

f)在本实施例中，如果没有下一个联系号码可用，则注册用户的电子邮箱地址从后端系统中被检索到(步骤320)并且一条例如“抱歉此时我们无法与你连接，请在铃声后留下信息。挂机发出信息[铃声]”的信息可以发送给用户(步骤322)。

g)请求用户的信息就可以例如然后按电子邮件方式发送给用户的WAV文件的形式进行记录(步骤324)。

h)如果注册用户没有电子邮箱地址，则一条例如“抱歉此时我们无法与你连接，请稍后再试”的出错信息在呼叫结束之前就可被发送给请求用户(步骤326)。

图15图示了处理呼叫SMS卡系统的进一步实施例。此处理过程类似于图2a示出的过程，但包括了附加的“启动挂机”处理(步骤1510)，此处理过程可以在请求用户从其中挂机的呼叫期间的任意点被执行。系统可以侦听贯穿该呼叫的挂机事件，然后就可以通过确定一条SMS是否已经被发送到请求用户来开启启动挂机处理(步骤1512)。如果SMS已经被发送，则该呼叫和处理就可以结束(步骤1514)。如果没有SMS已被发送，系统就可确定请求用户的呼叫设备是否为支持消息的设备。例如在英国，系统可以通过确定CLI是否以077，078或079开头来确定呼叫设备是否为手机。如果呼叫设备是支持消息的，系统然后就可以使得后端系统以默认格式生成和发送一信息给请求用户的CLI(步骤1518)，例如以SMS消息格式(步骤1520)。

图16图示了把请求用户与注册用户进行连接处理的进一步实施例。此处理过程类似于图3的介绍，但注册用户的下一个号码是自动地从后端系统找到的并且号码的存在与否可以被用来确定请求用户是否连接到另一号码或通过使用注册用户的电子邮件地址而直接留下了信息。该处理过程还包括了确定对用户的呼叫是否已超时的步骤。如果呼叫超时，请求用户然后就可以被邀请利用注册用户的电子邮件地址留下了信息。

创建SMS卡号码的处理过程现在将参考截屏图4到7来详细描述。

为了创建SMS卡，用户可以访问万维网界面，例如用户可以进入一个特别的网站。用户可以看到如图4所示的登录和注册界面。如果用户以前没有注册，那么该用户可以点击“Get an SMSCard”按钮410来获得SMS卡号码。

用户然后就可以看到如图5所示的数据条目输入屏幕并可以适当输入他们公司或个人信息。如果SMS卡号码是以用户名义(如为了公司)而被设置的，则“Editable”(“可编辑”)510标志就可以被选择来指明该信息应可被用户编辑。数据条目输入屏幕还使得默认信息格式能够被选择。

提示514和连接516标志可以使用户能够定义相关信息在名片传送时是否应该被发布以及相关号码是否应该被用于把请求用户与注册用户进行连接的尝试。

SMS卡号码就可以通过例如使用如图6所示的屏幕而被分配给某个人。然后，个人可能个性化SMS卡号码或个性化可以在号码被分派的时间完成。

初始的注册用户可以使用“contact us”(“联系我们”)特征。

如图7所示的确认截屏然后可以被呈现给用户以确认注册成功并提供给用户一组通行码。为了附加的安全性，除了预先选择登录名和密码以外，通行码的部分还可以在用户登录时被请求。

可以提供与系统连接的进一步界面的截屏由图8到14来图示描述。

图8图示了在一个进一步的实施例中的用于实用户能够设置SMS卡号码一个界面截屏。

图9图示了一个实施例中被用户用于把已经被输入到SMS卡系统中的信息个性化的截屏，例如，编辑任意可编辑的域以及，定义信息是否应该被提示或传送给请求用户或者，号码是否应该提供来使请求用户能够与注册用户连接。

图10所示的界面屏幕可以使用户能够向所选择的信息传输设备发送SMS卡。SMS卡格式可以被选择且信息传输设备的号码可以在SMS卡被发送之前被输入。

图11图示了一个实施例中的团体登录截屏，它可用于使团体用户能够访问、监控和更新他们的帐号。例如，用户可以为任何付费形式的服务购买更多的信用或修改与SMS卡有关的信息。

进一步界面截屏可以被提供给已付费服务或给被提供的在本身欠费的号码上的SMS卡服务。例如，图12图示了一个实施例中的允许例如为公司的用户购买一组号码块的截屏。

图13图示了根据一个实施例的一个付款截屏，安全的付费系统被期望提供来与本系统连接。

如图14所示的确认截屏，可以被提供来确认用户所购买的产品和全部费用。

在一些实施例中，有可能定义例如公司标志的与SMS卡有关的图像。电子邮件然后可以随着用于一些形式的卡(如，MMS多媒体信息信息或图片消息)的名片进行传送。

系统的使用可以进行监控并记录日志，这就可以使得能够生成指示了系统详细使用和关键性能的报告。

一种具有许多特征的完整的呼叫处理和联系信息管理系统和方法已经被描述了，系统的特征可以被修改、省略、增加或替代并被单独提供或与其他特性组合提供。特别地，每一个子菜单特征或处理选项或流程图上的分支都可以适时进行修改或替代或结合成另外一个系统的一个独立特性。值得理解的是，提示可以通过使用各种不同的介质(语音，声音，视频或甚或其他)进行提供并且，除非上下文有明确地要求，具体实例都应该作为隐含的、对一般提示的参考。类似地，所有对具体通讯介质或协议(如电话，文本，多媒体信息，图像，声音，电子邮件等)的参考都意图包括任意适当的一般通讯介质或协议(包括现有标准的派生，除非另外明确要求)。

如图17所示，提供了一个带有唯一国家价格电话号码(nationalrate telephone numbers)池的不动产代理系统。当一份财产(房产)由不动产代理负责时，该财产在分配处理104中就被分配覆盖多个营销渠道的多个唯一国家价格电话号码。财产细节、被分配的号码和相应的媒介渠道被存储在数据库106。

财产用显示的相关电话号码做广告。号码可以被显示在报纸广告，或位于该财产处的用于销售的公告板(FSB)上。

当系统用户从他们的手机呼叫了任意一个号码(由虚线110所示)时，则该呼叫在呼叫界面108被处理，并且财产细节就从数据库中进行检索。包有被检索财产细节的文本信息被自动生成并发送回用户，如箭头112所示，包含进一步细节的消息，或在附近区域的类似财产的细节的WAP发布消息也可以被发送给用户。文本可以包括例如卧室数量、客厅数量、卫生间数量、诸如新厨房或大花园等房产的特色特征以及询价。

此外，呼叫界面108还自动把到来的呼叫路由到根据从数据库找到的代理细节来交易那个财产的代理118(由虚线114所示)。呼叫可以被转送到用于排队的办公室，到一个具体的DDI号码，或经过管理的两者结合。同时，从数据库所找到的呼叫者细节和/或财产细节如箭头116所示而被呈现给呼叫所发送到的代理。这些可以例如通过电子邮件或通过具有快速刷新速率的专门网站来实现。

每一次对系统的呼叫都被记入日志，并且在预先定义的间隔，即使办公室未开门，具有对所有财产的所有询问细节的报告也自动地由分析模块120生成。这一信息被提供给代理，然后，曾经可能已被错过的询问可以在更方便的时间跟进。

上面介绍的示例性系统和方法各种要素现在将被更详细地描述。

电话号码分配

放在不动产代理中的每个财产都被分配多个唯一电话号码。这些是根据诸如销售公告板、报纸、杂志和其他刊登财产广告的媒体来分配的。

每个号码都被终止于或是分部办公室的主要号码或是正在处理特定财产的代理机构其中的一个特定的代理。该代理也被记录在中心网站。

一旦财产被售出，那个号码就可以被返回代理池以用于重新分配。

一般号码分配

当一个财产被放入代理列表，代理就会拥有一个被媒体根据每一财产所预先分配的号码池。在大多数情况下，系统将从可使用的池中以可能的人工代用装置(manual override)来自动分配一个号码，例如，对于高价值的财产会被分派一个珍藏号而不是一个普通号。

销售公告板号码分配

当列出某一财产的时候，销售公告板号码是没有被预先分配给该财产的。然后，任何销售公告板都可以被用于针对任一财产，这就使得签约承包商更加方便。

当一个板放在外面时，承包商需要针对财产来注册号码。这可以用两种方式实现：

简单形式的第一种办法是在站点完成并被返回到指示针对哪些财产哪些号码已被分配的代理机构。这可以在板被替换之后通过例如所摄制的照片来得到验证。

首选的方法是，承包者拨通销售公告板(它在一个免费循环中)上的号码并被提示输入财产代码。可以重新摄制一个照片用于验证处理过程。

用户界面

当呼叫者拨通一被分配的号码时，交互语音响应(IVR)系统查找包含关于财产信息的有关数据库记录，并且组合上呼叫者的电话号码(CLI)，该号码然后被实时显示给代理。这可能或是一个搜索组或是直接指向一个具体代理。

对于呼叫者，这是透明的并且呼叫可以快速指向与呼叫相关的财产。如果用户事先已经在系统中(例如通过网站)注册了他们带有电子邮件地址的细节，则财产细节就可以用电子邮件发送给他们，可选采用所执行的代理能看到和感觉到的格式。

在预先限定的时间结尾，如，每一天，代理机构或代理被发送带有与他们有关的所有被呼叫的财产(包括了媒体、呼叫时间和日期、呼叫持续时间和呼叫者CLI等)细节的电子邮件。

审核跟踪

这可以保证，即使在办公室已关闭或呼叫已被停止的情况下，也不会引起当代理仅在更方便的时间返回呼叫的任何损失。此外，通过通过分析由媒体来的每次呼叫，允许代理机构更紧密跟踪具体营销媒体，以保证其每次呼叫都可以被利用。例如可以是一个媒体关注一个方面同时另一个媒体关注另一不同的方面。

如果该项呼叫针对一个具体代理而被终止，则其允许管理团队准确地评估针对于电话呼叫数目的性能，从而优化训练要求。还允许代理机构测量特定财产的成功率。

自动数据返回

呼叫者被发送一包含所有关于财产的诸如卧室数目、特点、位置以及询价等重点信息的文本消息。此外，移动互联网(WAP)会话也可以被启用以允许用户接收财产的图像和诸如房间面积等进一步的细节。

基于万维网界面

用户可以另外登录万维网页以便发挥系统特性的进一步优势。与万维网页的互联网链接可以包括在例如发送给用户的SMS消息中。当用户登录到该网站时，他们被请求通过键入他们的电话号码(应该是他们从中向系统发出请求查询的号码)来登录。然后，这就可以带来他们发送查询时显示为有兴趣的一个或多个财产的细节问题。有关用户的进一步细节可以被获取，然后，那就可以用类似财产勾划和定位。特别值得提倡的是获取用户的电子邮件地址以使得细节可以在响应将来的查询时通过电子邮件进行发送。一个示例性用户界面流程在图21中被图示。

用户万维网页以例如通过邮政编码/城市/国家、邮政编码距离、代理选择、卧室/卫生间数量、房子类型、价格范围等等的搜索设施为特征。用户还可以当财产成为可用的时候订阅被发送的细节，这还包括了通过SMS、MMS多媒体信息、电子邮件、以及代理呼叫等等的通知提示。

用户万维网页可以被标记为来自特殊不动产代理的网页，搜索特征可以仅仅局限于包括被那个不动产代理列出的结果。

查询日志

每次对系统的呼叫都被记入日志并且媒体的细节、代理、每个财产呼叫的次数以及每个代理呼叫的次数都被记录。

通过使用这些信息，代理机构可以快速认清和识别具体到哪里的财产应该根据价格、大小、位置和其他因素而做广告，财产如何针对初始显示的兴趣执行，以及代理如何针对到来询问的次数执行。

呼叫处理代理屏幕

当针对一财产的呼叫进行时，IVR系统把呼叫发送到处理那个财产的办公室或代理。同时，它执行一个提出财产细节的数据库查询并输入呼叫者的电话号码。财产地址、财产代码、到来的呼叫号码、以及媒体渠道都可以被确定。

细节通过可以足够快速刷新的代理万维网页被提供给代理使得该代理在呼叫被应答之前或同时就可理解呼叫者的概况。

多于一个的代理号码可以被分配给一个财产以使得查询呼叫可以围绕多个目的号码进行传送。例如一个对特定财产的查询可被顺序地发送到一个代理的专线、代理的手机号、可选的代理号码并最终发送到办公室交换机。在每一个例子中，如果呼叫没有被连接，则按顺序地直接连到下一个号码。

代理然后就可以被分配给目的号码(通常为国内直拨DDI)，一个代理可以被分配到的几个目的号码。这就提供了一个对多个财产和多个代理之间可管理的多对多的关系并使得在设计上有很大的灵活性。

例如，假若代理已被设置为叫做“办公监视”并被分派到所有的目的号码，那么，该代理就会接收有关所有呼叫的信息。如果每个财产的最后一个目的号码已是办公室主交换机号码，并且所有代理都拥有交换机号码，则，在一个呼叫没有得到回答并移动通过了目的号码的时候，呼叫者细节就会当最后一个目的号码被呼叫时变成对所有代理可用。

代理的万维网页可以提供一个用于管理到来的呼叫的工具。代理可以被实时地通知有关于传送与该ID有关的号码的呼叫。如果所有的呼叫都被传送到主办公室号码，则所有的用户都可以看到财产细节。一旦呼叫被某一操作者回答了，则万维网屏幕就被更新为指示那个呼叫已经被应答了。

渠道分配

下面是一个示例性渠道分配：

1号-销售公告板

2号-本地报纸

3号-国家出版物

4号-家庭杂志

5号-邮寄广告

报告生成

可以被代理所生成的报告包括：

呼叫的全部数量

被应答的呼叫的数量

被错过的呼叫的数量

所有遗漏的号码所包括的财产细节的列表

通过媒体呼叫的数量

通过数量进行的分析

通过财产呼叫的数量

通过媒体的分析

下面是如图18所示的接收一到来的用户呼叫的流式处理过程。一个到来的、对注册系统号码的呼叫被接收(步骤202)，并且在204步，日期、时间和到来号码被保存。如果到来的号码是被识别为FSB代理的号码，则一个FSB代理例程就在206步开始，在以下更详细描述。

如果呼叫不是来自于FSB代理，则数据库进行财产细节的访问(步骤208)，和进行诸如电子邮件地址的任一注册用户的信息的访问(步骤210)。在212步，确定一个用户是否已经被发送了当前财产细节。如果细节以前没有被发送(这是该特定用户首次拨通这一特定号码)，那么，一SMS在214步就被发送给用户，并且，可选地，用户还在216步收到电子邮件。如果细节已经被发送(举例来说，如果用户正回呼以登记注册进一步的兴趣/做出购买)，则214和216步就被跳过，并且在218步呼叫被默认地登录成未应答。用户呼叫然后被连接到与到来的查询号码有关的第一代理号码。如果用户在呼叫被回答以前挂机，则呼叫状态被从未应答更新为未被处理。如果呼叫被连接则状态被更新为应答。最终，如果用户保持在线但呼叫一直不能被连接(举例来说，如果代理目的号码占线)则在220步与代理有关的下一个号码就被呼叫。

FSB代理例程在206步开始，在那里来自代理的最后呼叫的细节被检索。如果这个代理在最后30分钟内没有呼叫过这个号码，则在208步，代理被提示输入识别待被分派号码的财产(刚被代理建立在FSB上的财产)的财产代码。财产细节从数据库中被找到，并在210步发送给FSB代理以用于确认目的。如果代理在最后30分钟内呼叫了这个号码，则代理就被认为正回呼确认财产细节，并在212步被提示指明细节是否正确。如果正确，则数据库用新的号码分配进行更新。如果不正确，代理就返回208步重新输入财产代码。

与本发明实施例兼容数据库结构如图19所示。IVR信息表被用于存储由用户拨叫的号码和用户自己的号码。该表引用链接表304来发现有关的、然后可以被用于从财产信息表306中检索财产细节的财产代码。

该链接表也被用于存储到来的呼叫可以被传送到的多达3个代理目的号码。根据以上详细描述的处理的呼叫传送的引出，呼叫细节可以追加到如下三个表之一，未应答呼叫表308，应答呼叫表310或未被处理呼叫表312。表308，310和312存储了报告可以从中运行以提供对上述代理进行呼叫统计的原始数据。

允许代理管理和维护系统的代理系统管理界面以及一示例性流程如图22所示。当在2201步登录到系统管理区域时，代理被呈现一些选项，分支2202允许代理找到未应答的或其他被登录的查询。分支2203允许代理创建一个新渠道。分支2204允许代理向系统输入一个新财产。分支2205和2206使得FSB代理和呼叫处理代理将被分别设立。这些功能可以由用户在屏幕上执行，或也可以作为自动例程的一部分来执行，并且可以被代理用现有的计算机系统进行控制。

数据库和相关系统可以被代理、或它们的万维网开发商或所有代理或一组代理公共的中心管理员来管理维护。正如已经提到的，上面介绍的系统具备了如下益处：

代理可以被提醒错失的呼叫并可以回呼那个用户。

系统可以容易地集成到代理网站和现有的数据库。

通过自动和/或手工处理过程，用户可以被勾划轮廓发送他们电话上并且新财产的细节可直接被发送到他们电话上。

用户可以注册到系统并可以容易地研究其查询所寻址到的财产。系统还可以通过电子邮件把这些细节自动发送到已经被注册的电子邮件地址。

Claims

1.一种用于响应于用户请求而自动提供对象项数据的方法，包括如下步骤：

把用于第一对象项和第一对象项电话号码的对象项数据存储在数据库中；

从用户处接收地址为所述第一对象项电话号码的查询；

从所述查询中为所述用户派生用户号码；

从所述数据库中检索与所述第一对象项电话号码对应的第一对象项数据；以及

自动地把所述第一对象项数据发送给所述用户号码。

2.根据权利要求1所述的方法，其中，所述用户查询是对所述第一对象项电话号码的语音呼叫。

3.根据权利要求1或2所述的方法，其中，所述第一对象项数据被发送给所述用户而不需要进一步动作。

4.根据权利要求1至3中任一项所述的方法，其中，所述第一对象项数据以下面一个或多个形式被发送给所述用户：SMS消息，WAP发布，flash消息或视频流。

5.根据权利要求1至4中任一项所述的方法，其中，所述用户号码是所述用户查询的呼叫者线标识(CLI)号码。

6.根据权利要求1至5中任一项所述的方法，其中，所述数据库包括：所述的用户号码和相应的电子邮件地址，以及其中，所述第一对象项数据被发送到该电子邮件地址。

7.根据权利要求1至6中任一项所述的方法，其中，包括所述用户号码的用户查询数据被存储在所述数据库中。

8.根据权利要求1至7中任一项所述的方法，其中，所述对象项是财产，以及其中，所述对象项数据包括了财产细节。

9.根据权利要求8所述的方法，其中，多个电话号码被保存用于每项财产，每一个电话号码都对应于一项单独财产。

10.根据权利要求9所述的方法，其中，多个渠道被定义，每一个电话号码都对应于一项单独财产和一个单独渠道。

11.根据权利要求10所述的方法，其中，所述电话号码被显示在广告媒体上，每一渠道都对应于不同的广告媒介。

12.根据权利要求1至11中任一项所述的方法，其中，所述数据库还附加包括第一对象项呼叫处理代理数据，以及其中，所述方法还附加包括步骤：自动将所述用户查询传送给使用所述代理数据的第一呼叫处理代理。

13.一种用于管理对象项查询的方法，包括如下步骤：

从用户处接收地址为所述第一对象项电话号码的查询；

自动将所述用户查询传送给使用所述代理数据的第一呼叫处理代理；以及

自动使得相应于所述用户查询的第一对象项细节对所述呼叫处理代理可用。

14.根据权利要求13所述的方法，其中，使得所述第一对象项细节可用的过程和传送用户查询的过程基本同步执行。

15.根据权利要求13或14所述的方法，进一步包括如下步骤：从所述查询中为所述用户派生用户号码以及使得所述用户号码对所述呼叫处理代理可用。

16.根据权利要求13至15中任一项所述的方法，其中，所述数据库包括：所述用户号码和相应的用户细节，以及，使得所述用户细节对所述呼叫处理代理可用。

17.根据权利要求13至16中任一项所述的方法，其中，所述对象项是用于销售的财产，以及其中，所述对象项数据包括财产细节。

18.根据权利要求13至17中任一项所述的方法，其中，多项查询可以被同步地传送到所述呼叫处理代理。

19.根据权利要求13至18中任一项所述的方法，其中，所述多项查询可以被同步地显示给所述呼叫处理代理。

20.根据权利要求13至19中任一项所述的方法，其中，相应多个对象项细节和/或用户号码和/或用户细节也被显示给所述呼叫处理代理。

21.根据权利要求13至20中任一项所述的方法，进一步包括如下步骤：从所述查询中为所述用户派生用户号码，以及自动将所述第一对象项数据发送给所述用户号码。

22.一种为自动处理用户查询而建立对象项管理数据库的方法，包括如下步骤：

允许卖方向所述数据库输入对象项细节；

为每个对象项都分配一个或多个对象电话号码，这些对象电话号码对查询而言可以被寻址到；

为每个用户查询都派生用户号码；以及

为每个查询存储所述用户号码和所述对象电话号码。

23.根据权利要求22所述的方法，其中查询包括寻址所述一个或多个对象电话号码的语音呼叫。

24.根据权利要求22或23所述的方法，其中所述用户号码是所述用户查询的呼叫者线标识(CLI)号码。

25.根据权利要求22至24中任一项所述的方法，进一步包括：为每个对象项都分配呼叫处理代理数据以及响应于一个寻址到对象电话号码的查询，检索被分配给所述对象电话号码的呼叫处理代理数据，以及自动向使用所述代理数据的呼叫处理代理传送所述用户查询。

26.根据权利要求22至25中任一项所述的方法，进一步包括：向所述呼叫处理代理提供一份地址为一个或多个所述对象电话号码的查询的报告。

27.根据权利要求26所述的方法，其中，所述报告包括一定时间段所进行的所有查询。

28.根据权利要求22至27中任一项所述的方法，其中，多个电话号码被保存用于每一对象项，每一个电话号码都对应于一个单独对象项。

29.根据权利要求28所述的方法，其中，多个渠道被定义，每一个对象电话号码都相应于一个单独对象项和一个单独渠道。

30.根据从属于权利要求26的权利要求29所述的方法，其中，所述报告是根据渠道来对查询进行分类的。

31.根据权利要求22至30中任一项所述的方法，进一步包括：监控和存储一项查询是否连接到所述呼叫处理代理。

32.一种为自动处理用户查询而建立对象项管理数据库的方法，包括如下步骤：

允许卖方向所述数据库输入对象项细节；

定义多个渠道；

为每个对象项都分配多个对象电话号码，对这些对象电话号码而言，查询可以被确定地址，每个对象电话号码都对应于一个单独对象项和一个单独渠道；

为每个用户查询都派生用户号码；以及

为每个查询存储所述用户号码，对象项和相应于所述对象电话号码的渠道。

33.根据权利要求22至32中任一项所述的方法，其中，所述对象项包括财产。

34.一种把用于在财产查询可以被寻址到电话号码的财产位置中显示的电话号码分配给所述财产位置的方法，包括如下步骤：

提供一系列用于在财产位置处显示的未被分配的电话号码；

在所述第一财产位置处显示所述未被分配的电话号码之一；以及

顺序把所述被显示的电话号码分配给所述第一财产位置以使得每个位置都被分配为所述一系列电话号码中的一个不同号码。

35.根据权利要求34所述的方法，其中，所述分配步骤是通过一个地址为所述被显示的电话号码的分配呼叫来实现的。

36.根据权利要求34或35所述的方法，其中，所述分配步骤包括：

从所述分配呼叫中接收一标识所述第一财产的代码。

37.根据权利要求34或35所述的方法，其中，所述分配步骤包括：

从所述分配呼叫中接收一标识所述第一财产的语音消息。

38.根据权利要求34至37中任一项所述的方法，进一步包括：从

所述分配呼叫中派生一分配号码，以及针对已知的分配号码列表来验证所述分配号码。

39.根据权利要求34至38中任一项所述的方法，进一步包括：向所述分配号码发送所述被标识的第一财产的图像。

40.一种用于标记带有对象请求可以被寻址到的电话号码的对象项的方法，包括如下步骤：

提供一系列未被分配的电话号码；

打印多个带有所述未被分配的电话号码的标记；

在第一对象项上显示所述标记的第一个；以及

把有关所述第一标记的号码顺序分配给所述第一对象项，使得每个对象项都被分配所述一系列电话号码中的一个不同号码。

41.一种用于响应于请求提供联系信息的方法，包括如下步骤：

在联系信息数据库中存储与第一用户相关的联系信息，

以及第一用户电话号码；

从第二用户处接收地址为所述第一用户电话号码的请求；

从所述请求中为所述第二用户派生目的号码；

从所述联系信息数据库中检索被分配到所述第一用户电话号码的联系信息；以及

自动使得所述被检索的联系信息对使用所述被派生的目的号码的第二用户可用。

42.根据权利要求41所述的方法，其中，所述请求是对所述第一用户号码的语音呼叫。

43.根据权利要求41或42所述的方法，其中，所述联系信息不需要经过第二用户的进一步处理而可用。

44.根据权利要求41至43中任一项所述的方法，其中，所检索的联系信息被发送给所述第二用户的目的号码。

45.根据权利要求4所述的方法，其中，所检索的联系信息以允许用直接电子化输入到存储设备的格式而被发送给所述第二用户。

46.根据权利要求44或45所述的方法，其中，所检索的联系信息作为SMS消息而被发送给所述第二用户。

47.根据权利要求44或45所述的方法，其中，所检索的联系信息以如下之一的方式而被发送给所述第二用户：电子名片、V卡、flash消息、或MMI/MMS。

48.根据权利要求41至47中任一项所述的方法，其中，所检索的联系信息包括图像数据。

49.根据权利要求48所述的方法，其中，所述图像信息作为图像消息而被发送给所述第二用户。

50.根据权利要求41至49中任一项所述的方法，其中，所述联系信息以被分配的默认格式可用。

51.根据权利要求44至50中任一项所述的方法，其中，所述第二用户可以从可用的格式列表中选择所述联系信息在其中被发送的格式。

52.根据权利要求41至51中任一项所述的方法，其中，所检索的联系信息是通过语音提示而被提供的。

53.根据权利要求41至52中任一项所述的方法，其中，如果所述请求的呼叫者线识别(CLI)号码是支持SMS消息的，则，

所检索的联系信息是被SMS消息提供的，以及其中，所检索的联系信息是被另外可选地通过语音而提示给所述第二用户的。

54.根据权利要求41至53中任一项所述的方法，其中，所述第二用户的目的号码是从所述第二用户所接收到的请求中自动地派生出的。

55.根据权利要求54所述的方法，其中，所述第二用户的目的号码是第二用户的请求的呼叫者线识别(CLI)号码。

56.根据权利要求54所述的方法，其中，所述联系信息数据库包括第二用户的请求的呼叫者线识别(CLI)号码，以及其中，

所述第二用户目的号码是从所述数据库被检索的，所检索的号码与CLI号码有关。

57.根据权利要求41至56中任一项所述的方法，进一步包括：对第二用户目的号码做出提示，其中，所述第二用户的目的号码是由第二用户响应所述提示而输入的。

58.根据权利要求41至57中任一项所述的方法，其中，所述第二用户的目的号码是所述请求的CLI号码，如果所述号码是支持消息的话，以及，对请求目的号码的所述第二用户另外发出声音提示。

59.根据权利要求41至58中任一项所述的方法，其中，所述联系信息数据库包括所述第一用户的电话号码，所述方法还进一步包括：在发出请求的时刻，把所述第二用户连接到所述第一用户的电话号码。

60.根据权利要求59所述的方法，其中，所述联系信息数据库包括所述第一用户的多于一个的电话号码，以及其中，如果所述第一用户的第一个电话号码在一定时间内没应答，则所述第二用户就可以被连接到另一个电话号码。

61.根据权利要求41至60中任一项所述的方法，其中，所述联系信息数据库包括多种类型的联系信息。

62.根据权利要求41至61中任一项所述的方法，进一步包括：允许所述第一用户输入或更新在联系信息数据库中被分配给所述第一用户号码的联系信息。

63.根据权利要求41至62中任一项所述的方法，其中，所述第一用户可以从所支持的格式中选择一个在其中发送被请求的联系信息的默认格式。

64.根据权利要求41至63中任一项所述的方法，其中，所述第二用户的目的号码被存储在请求数据库中。

65.根据权利要求64所述的方法，进一步包括：向所述第一用户自动提供在所述请求数据库中存储的目的号码的细节。

66.根据权利要求65所述的方法，其中，用于一天内所接收到的请求的目的号码被提供给所述第一用户。

67.根据权利要求64至66中任一项所述的方法，其中，所述目的号码的细节通过电子邮件被自动地发送给所述第一用户。

68.一种用于响应于请求提供联系信息的系统，包括：

输入界面，用于接收来自与第一用户号码有地址联系的第二用户的请求；

处理器，用于从所述请求中为所述第二用户派生目的号码；

数据库，用于存储与用户号码相关的联系信息；以及

输出界面，用于自动地把与所述第一用户号码相关的联系信息发送给所述第二用户目的号码。

69.根据权利要求68所述的系统，其中，所述输入界面是基于语音的界面。

70.根据权利要求69所述的系统，其中，所述输入界面包括一个IVR界面。

71.根据权利要求68、69或70所述的系统，其中，所述输出界面是一种SMS通信器。

72.根据权利要求68至71中任一项所述的系统，进一步包括用户界面，其允许所述第一用户输入或更新与所述第一用户号码相关的联系信息。

73.根据权利要求72所述的系统，其中，所述用户界面允许所述第一用户选择默认的、所述联系信息在其中被发送的格式。

74.根据权利要求72或73所述的系统，其中，所述用户界面允许第一用户选择在进行请求时可以被连接到第二用户的电话号码。

75.根据权利要求72、73或74所述的系统，其中，所述用户界面允许第三用户授权给第一用户以输入或更新与所述第一用户号码相关的联系信息。

76.根据权利要求72至75中任一项所述的系统，其中，所述用户界面是基于万维网的。

77.一种创建用于自动发布响应请求的联系信息的订户联系信息数据库的方法，包括：

允许订户在所述数据库中输入或更新联系信息；以及提供所述订户一个或多个请求联系信息可以被寻址到的订阅号码。

78.根据权利要求77所述的方法，其中，响应于来自地址为所述订阅号码的用户的请求，与订阅号码相关的联系信息被自动发送给用户。

79.根据权利要求77或78所述的方法，其中，订户可以手工输入联系信息。

80.根据权利要求77至79中任一项所述的方法，其中，订户可以向所述数据库下载信息。

81.根据权利要求77至80中任一项所述的方法，其中，订户可以选择所述联系信息在其中被发布的默认格式。

82.根据权利要求77至80中任一项所述的方法，其中，订户被提供有多个订阅号码，以及其中，所述订户可以授权为所选择的订阅号码输入或更新联系信息到被选择的子用户。

83.根据权利要求82所述的方法，其中，订户可以为所述多个订阅号码中的一些或所有号码下载联系信息。

84.根据权利要求77至83中任一项所述的方法，其中，订户可以预览将要被发布的联系信息。

85.一种用于监控订户联系信息系统使用情况的方法，所述系统包括用于存储订户号码和订户的相关联系信息的订户数据库，以及所述系统允许用户远程请求来自所述数据库的联系信息，所述方法包括：

从用户处接收一个可以被寻址到订户号码的请求；

从所述请求中派生用户目的号码；以及

在使用情况数据库中创建包括所请求的订户号码及其相应的用户目的号码的请求的记录。

86.根据权利要求85所述的方法，其中，被分配给所述订户号码的联系信息是从订户数据库中被检索的，并被自动发送给被派生出的用户目的号码。

87.根据权利要求85或86所述的方法，其中，所检索的联系信息是由SMS消息发送的。

88.根据权利要求85至87中任一项所述的方法，其中，对联系信息的请求包括语音呼叫。

89.根据权利要求85至87中任一项所述的方法，其中，对联系信息的请求包括SMS消息。

90.根据权利要求85至89中任一项所述的方法，其中，所述被派生出的用户目的号码是所述请求从中已被收到的号码。

91.根据权利要求85至90中任一项所述的方法，进一步包括：提供订户记录，其形成对特定订户号码的请求，以及可选地与那些请求相关的用户目的号码。

92.根据权利要求91所述的方法，其中所述的请求的纪录包括在一定时间段内所有被接收到的请求。

93.根据权利要求91或92所述的方法，其中所述的请求的纪录在一定时间段的结尾被自动发送给所述订户。

94.根据权利要求91、92或93所述的方法，其中所述的请求的纪录通过电子邮件而被发送给所述订户。

95.根据权利要求85至94中任一项所述的方法，进一步包括：提供用户纪录，被形成的，或者与详细用户目的号码相关的，以及相应于那些被形成的请求的订户号码的请求。

96.根据权利要求95所述的方法，其中所述的请求的纪录包括响应于那些请求而已被返回的联系信息。

97.根据权利要求95所述的方法，其中所述的请求的纪录包括在所述订户数据库中当前与那些订户号码有关的联系信息。

98.根据权利要求95、96或97所述的方法，其中所述的请求的纪录是通过电子邮件发送给所述用户的。

99.根据权利要求95、96或97所述的方法，其中所述的请求的纪录是通过SMS消息发送给所述用户的。

100.根据权利要求85至99中任一项所述的方法，其中，订户可以被分类成组，以及其中，来自与一组订户相关的使用情况数据库的纪录被提供给所述组中的一个或多个成员。

101.根据权利要求100所述的方法，其中，被请求给一组订户的每个订户号码的纪录被提供给所述组的一个或多个成员。

102.一种从第二用户向第一用户传送消息的方法，包括如下步骤：从第二用户接收对第一用户号码的语音呼叫；

记录来自所述第二用户的语音消息；

从用户数据库中检索被分配给所述第一用户号码的电子邮件地址；以及

通过电子邮件自动把所述被记录的消息发送给所述第一用户。

103.根据权利要求102所述的方法，其中，所述消息是以经过数字化编码的音频文件形式发送给所述第一用户的。

104.根据权利要求102或103所述的方法，其中，所述消息是通过使用语音到文本的处理过程来进行处理的，并以文本形式而被发送给所述第一用户。

105.任意一种基本参考本文附图进行描述的方法。

106.一种基本参考本文附图进行描述的系统。