CN1314060A - 用于移动电话业务的自动传送和信息系统 - Google Patents

Abstract

用于在电话网中自动和无缝地传送移动电话呼叫的一种系统和方法。该系统包括一个电话网接口盒、一台计算机和一个客户文件。该客户文件具有若干条包括一个空间关键字和一个客户电话号码的记录。一种系统实施例(1500)使用代表主叫用户移动电话瞬时位置的一个空间坐标(1502)作为到一个实时处理(1510)的输入,该处理从客户文件中识别出与主叫电话(110)位置对应的一个或多个客户服务位置(1460)。

Description

用于移动电话业务的自动传送和信息系统

发明领域

本发明一般涉及电话业务和传送技术，更具体地说，涉及自动传送电话呼叫以及可选地提供关于客户位置的信息的系统。

发明背景

在竞争日益激烈的商界中，常常需要自动传送拨向一个“1-800”号码或等效号码的电话呼叫，该号码对应一个本地商店、特许经营店、分支机构、经销商或服务公司(下文的服务位置)，其服务区域包括需要该“1-800”号码相关的产品或服务的主叫位置。例如，一个人可以从美国的任何一部电话拨打1-800-Italian，而向主叫电话位置送比萨饼的MyPizza(一个假想公司)服务位置处的电话就将会振铃。

以前有好几种简单的方式自动把呼叫传送到地理位置上邻近主叫的一个服务位置处。这些传送技术基于向与始发呼叫具有相同电话区号和前缀的位置、具有相同5位邮区代码的位置、具有相同城市名称的所有邮区、或以上位置的组合传送呼叫。有许多不同的术语用于描述一个10位电话号码的各个组成部分。在通信行业内，它被称为NPA-NXX-XXXX，其中NPA是区号，NXX是前缀或局号，XXXX是后缀或线路号码。例如，在10位电话号码619-942-9999中，619是NPA或区号；942是NXX、前缀或局号；9999是XXXX、后缀或线路号码。通常具有同一区号和前缀的所有电话号码由同一线路中心提供服务。一个线路中心是由单个电话公司支局提供服务的地理区域。线路中心通常是一台交换机，但也可以是多台交换机，通常可为大约十个局号提供服务。通过电话公司的定义，线路中心不会出现重叠。

A．现有的传送系统

地球是一个球体，它表面上的任何点都可以通过几个世纪以前发明的一种纬度和经度球面坐标系统来定义。使用这种坐标系统、球面三角学和一台计算机，可以计算出地球上任何两个位置之间的距离，并确定一个位置是否在另一个位置的指定半径之内，或确定一个位置是否包含在定义为球面多边形的一个不规则服务区域内。

几年前，AT&T实现了通过使用自动号码标识(ANI)沿电话网传送主叫电话号码的技术，以便于计费。某些电话网具有的“主叫ID”特性使用ANI技术识别主叫方的电话号码。由于一台现代电话交换机只不过是一台专用计算机，因此对于处理呼叫的交换机来说，在一个记录表(具有上亿条记录)中查找具有指定服务位置电话号码的主叫电话号码、并向服务电话号码传送呼叫是一种简单的处理过程。

不过，在这种传送系统经济可行和成为实用业务之前，还有几个非常棘手的问题需要解决。第一个问题首先是确定美国任何一个电话号码的纬度和经度，并在每年有百分之二十的消费人群移动和公司不断有营业点开张和关闭的情况下保持数据更新。第二个问题是为了产生到服务位置电话号码表的主叫电话号码并在一个不断变化的环境中保持其更新，需要进行大量的球面三角计算，其计算量超出当前速度最快的计算机几个数量级。

为了解决这些问题，需要几种关键数据库和技术。作为1990调查的一个部分，美国人口普查局建立了一个被称为TIGER(地志学综合地理编码和索引)的美国国内纬度和经度绘制地图，它几乎包含了美国的每个街区。一个街区是每一端都与其他街道相交的一段街道。所有街区的TIGER记录包含一段街道每个端点的纬度和经度坐标，其精确度在正负三十英尺内，而且对于大部分街区来说，包括街道每一侧的起点和终点地址范围。在人口普查局没有完成地址范围设定的地方，私人公司已填补上了空白，并在新的街道产生时更新TIGER。

过去，美国邮政业务(“邮政局”)把美国分成了称为邮区(区域改进规划，zip)代码的投递区域，以便于自动分发邮件。在九位数字(zip+4)的级别上，这些邮区代码通常可以对应每段街区的一个单侧。除了在地理区域上把美国划分成小的邮政投递区域之外，邮政局还制定了地点和街道的命名规则。对于希望其邮费打折的直接邮寄者来说，他们必须规范化自己的邮寄地址，以符合邮政局的命名规则，并提供一个zip+4代码。为了简化邮政地址规范化和zip+4编码处理，邮政局提供了一种国内Zip+4地址编码规则，并保证几种商用软件包可以正确地规范化地址，并且有略多于99％的地址记录在邮政局的测试文件上。

近来，邮政局和一些私人公司完成了邮局Zip+4地址编码规则与TIGER的映射，生成的文件包含带有纬度和经度重心的zip+4代码(一个zip+4重心大致是一个zip+4代码的地理中心)。这种类型的文件被称为zip+4纬度和经度重心文件100(图1a)。这些重心在95％的时间内都是正确的，它与根据特定zip+4代码的街道地址接收邮件的房屋或公司的距离在正负105英尺之内。目前，规范化地址和产生由zip+4代码组成的识别物理位置的清单(例如本发明的电话号码主清单)已经是一种非常可靠和经济的处理。

为了使自动电话呼叫传送处理成为一种经济可行和实用业务，还利用了通信技术的其他变化和改进。美国电信基础结构的改进已改变了电信的成本结构。目前从路易斯安那到纽约的电话呼叫成本与从路易斯安那到圣地亚哥的呼叫成本大致相同。因此，中心传送系统硬件和设备所处的物理位置已无关紧要，或者换句话说，它可以位于美国国内的任何地方。

通信技术的另一种改进是地理信息系统的出现，该系统常被称为GIS。这些系统可以通过交互式地图收集和显示几乎美国任何区域、任何大小或形状、任何地方的任何数据。这些系统的普及推动了处理地理信息的复杂技术和算法的发展。我们关注的主要是地理信息与电话号码，特别是10位号码的链接。

通过降低处理的计算机负荷，已减轻了置换可达十亿次的球面三角计算的复杂处理要求。与进行复杂的三角球面计算不同的是使用一种其小于其计算机负荷千分之一的技术。这种技术基于从每个服务位置作多圆锥投影，并进行简单的二维距离平方测试。每一纬度大约是68.9404英里。不过，每一经度代表的英里数是随纬度而变化的。在特定的纬度上，每一经度代表的英里数等于纬度的余弦值乘以68.9404。通过使用服务位置作为纬度点并已知主叫点的纬度和经度，很容易得到一个纬度和经度增量，将其转换成英里，并进行简单的距离计算，即“距离=SQRT(X**2+Y**2)”。对于在纬度40°上相距100英里的两个位置，这种多圆锥投影技术产生的距离计算误差约为12英尺。不过，为了得到一种用于高呼叫业务量应用的实用、有效和经济可行的传送处理方法，还需要采取其他降低计算量的措施。

B．现有传送系统的处理

原有用于向一个服务位置传送“1-800”电话号码呼叫的技术存在以下三个问题中的一个或多个：

(1)许多这样的传送系统精确度都很差，不能处理像比萨饼投送特许店之类具有指定特许区域边界的小服务区。例如，特许区域可以是一个不规则形状的多边形。与精确度大约在10英里左右的原有系统相比，最好有一个精确度在105英尺之内的更精确的系统。这种系统借助美国几乎每部非移动电话在地球上通常表示为一个纬度和经度的已知物理位置，可采用非常精确的测量判定。在其他国家也可以使用其他坐标系统。

(2)传送系统中的另一个问题是它们把美国分成了许多任意定义的大区域，如果最近的位置与主叫不在同一个人为产生的区域内，就不能把呼叫传送到最近的服务位置。许多情况下，位于一个局号区域或5位邮区代码边界的主叫距离具有不同邮区代码或电话前缀的服务位置要比距离呼叫传送的位置近得多。最好有一种无缝系统，它不使用人为产生、使得呼叫只能在其内部传送的区域，例如电话线路中心、电话前缀、或5位邮区代码。一个公司也许希望可以选择向最近的分支传送一个呼叫，该分支的服务区域可定义为包括主叫位置的一个预定半径，例如5英里，或是包括主叫位置的一个预定不规则多边形。另外，一个公司也许希望可以选择向其服务区域定义为包括主叫位置的一个预定半径或是包括主叫位置的一个不规则多边形的任何分支(而不是最近的分支)传送呼叫。

(3)最后，现有的传送系统常常依赖于第三方的电话号码簿，这种号码簿由于印刷、关键条目以及光学字符识别(OCR)扫描时间的滞后总是不太准确，而且不包括未列出的号码。美国有30％以上的电话号码没有列出，其中包括公共付费电话和进入公司及家庭、只列出了一条线路的多条线路。随着所列用户和公司的位置和相关信息发生变化，这类号码簿中的信息很快就会过时。因此，最好有一种能比原有系统正确传送更大比例呼叫的系统。在美国，这种系统将需要直接访问AT&T电话号码总表。这种系统最好使用包括未列出电话号码的每日更新数据，并涉及在电话公司保有的受管制电话数据库和第三方保有的客户数据库之间传送信息。

上面讨论的三个缺点导致用户业务量和满意度更低，因人工异常处理由于各种原因不能传送的呼叫使得成本更高，同时运行中的维护成本也高。人工异常处理通常需要实际操作员介入“1-800”呼叫。

其他原有系统要求用户响应来自该系统的语音提示，在按键式键盘上输入其邮区代码或电话前缀。根据主叫在键盘上输入的数据向一部目的电话传送电话呼叫。其他类似系统只是通过一条语音消息简单地通知用户本地销售商所用的另外一个电话号码，该号码需要人工拨打，而不能自动传送呼叫。最好有一种系统不需要任何额外的用户交互或输入。这种系统通过使用可以由受管制的电话公司在国内的基础上访问的标准电话分组中的最少10位电话号码，可以是全自动的。电话分组包括完整的始发和目的电话号码。

自动电话传送系统的基本原理是包括一个自动识别主叫方电话号码的装置。在Kaplan的美国专利第5,163,087号中揭示了这种系统。这种系统把主叫方的自动号码标识(ANI)转换成原来由被叫方定义的一个用户数据库关键字。这个数据库关键字，例如用户帐号，就取代了ANI信息被提供给被叫方，使得被叫公司的计算机可以处理该关键字，以进行查询并向公司代理提供用户信息。该系统假定主叫在以前已呼叫过该公司，以便向公司代理提供信息，生成了一条用户记录或其他类似信息。Kaplan系统向一个公司位置传送数据库关键字而不是国内的若干服务位置。向公司传送数据库关键字需要一个综合业务数字网(ISDN)或类似设备，这对于公司来说是一项额外的负担。

自动传送系统应当不需要向最终目的地传送数据库关键字或消息，而只用ANI信息作为到一个表的索引，该表包含把一个国家划分成小地理区域的方式，例如邮政业务的zip+4代码。这些划分还可用于访问可能位于国内任何地方的若干服务位置中的一个。Riskin的美国专利第4,757,267号中描述了当前的一种电话呼叫传送系统。Riskin使用自动号码标识(ANI)从主叫向作为被叫、处于同一区号和前缀(10位电话号码的前六位，“6位号码”)内的销售商传送呼叫。因为6位号码代表的区域较大，在该区域内可能有几个销售商，所以通常要从几个位置的清单中按照随机或是为每个位置分配一个加权比例的方式选择出销售商位置。或者向主叫提供一个在较大地理区域内可选的销售商位置清单，因为系统不知道哪个服务位置更接近用户。Riskin使用6位号码同时确定主叫位置和服务位置。Riskin使用准确度在正负2300英尺内的一种坐标系统，假定主叫位置就是为主叫的6位局号服务的中心局交换机位置(该位置与其实际位置可能相距0到5英里)，同时假定销售商位置就是为销售商位置的6位局号服务的中心局交换机位置(该位置与其实际位置可能相距0到5英里)。最好有一种系统能使用主叫和服务位置电话号码的所有10位数字以及与GIS型数据库关联的号码位置的实际街道地址(使用准确度在30英尺内的一种坐标系统和相应的坐标数据)，提供地理精确度在105英尺内的主叫和目的电话定位。

因此我们需要一种自动电话传送系统，它能通过在没有任何人为干预的情况下传送拨至单个国内电话号码的绝大部分呼叫从而降低成本；能通过为客户提供单个、易记忆、免去长途或普通话费的国内电话号码增强市场竞争优势；能得到地理上非常精确的结果；能使公司围绕每个服务位置定义任何所需大小和形状的用户服务区域。最好的一点是，客户可以把每个位置的服务区域定义为任意大小半径的一个区域或任意大小或形状的一个多边形。客户可以混用半径和多边形定义，也可以使服务区域重叠或不重叠。

主叫常常可以不需要真正完成到公司服务位置的一次电话呼叫，而是需要关于该公司的信息。例如，主叫可能想确定三个最近的服务位置，或更具体地说，主叫想知道该公司是否还营业，或是否有某项所需服务等等。

C．现有的语音响应单元应用

通常，具有一个到上万个服务位置的公司、非营利性组织和政府机构一般为用户提供了多个电话号码联系点，通常每个服务位置、部门或个人至少有一个电话号码。这对于用户和可能用户来说，要寻找、记住、拨打和连接正确的所需位置或服务的实体内部电话号码是一个很大的负担。在电子商务的新时代，这些实体已开始使用空电话号码作为他们的优选的单一初始用户联系点。这些空号是一些容易记忆的电话号码，例如一家公司选择的1-800-FLORIST。这些空电话号码通常以“800”、“888”或“900”作为区号，“555”或“950”作为本地局号前缀。

基于拨打这些空号的呼叫业务量很大，用户需要每周七天和每天24小时的扩展服务时间，为了降低电话占线和接通时间，产生了许多使用语音响应单元(VRU)应答空号呼叫的空号广告器。空号的迅速增长和VRU的应用产生了一种需要，即通过现在所谓的智能呼叫处理，由VRU自动应答更高比例的呼叫。

在本文中，自动智能呼叫处理被定义为在VRU上捕获网络提供的数据，例如ANI和所拨号码识别业务(DNIS)，以及主叫提供的数据，例如通过按键式话机键盘输入的双音多频(DTMF)或主叫直接说话得到的数据。智能VRU还能通过播放预先录下的消息、产生呼叫指定的测试消息和向主叫播放、以及/或传送和连接主叫与服务位置来进行解密、认证、处理和满足主叫的请求。与之相反，半自动呼叫处理意味着用户请求的片段可以通过智能呼叫处理自动完成，但是该请求的某些部分仍然需要一个工作的操作员在呼叫期间的支持。

另一类自动智能呼叫处理包括客户不愿使用语音响应功能但要使用系统的自动传送特性的情况。这时，可以用一个不具备语音/话音特性的网络终接点接口(NTPI)盒替代VRU。

VRU或NTPI盒为了处理更高比例的主叫请求，就必须能够即时访问更多的信息。这就要求实时访问存储在不同计算机系统中的许多不同数据库。计算机联网技术和联网标准的最新发展、速度和带宽的提高以及长途数据通信成本的降低已使广域联网变得普遍和实用。计算机网络业务支持的各种计算机接口应用，例如Compuserve^,AmericaOnline^,Microsoft Network^TM和Internet，在一定程度上已说明了这一点。

在具有近20亿个接入点的国内通信网中，大部分接入点只带有简单的按键式或老式转盘电话的输入和输出功能，VRU或NTPI交换机数据库访问主要限于客户专有的按电话号码索引的用户数据库。这种访问方式对于现有用户呼叫的许多应用是可行的。不过，对于新用户、新公司或服务于不同目标市场的新应用，这些内部数据库覆盖的范围就太小了，无法使VRU数据库的查询应用成为经济可行的。另一方面，又有一些不包含电话号码的国家级数据库，例如GDT Zip+4纬度和经度文件。因此，在VRU电话呼叫处理应用中没有使用这些数据库及其不包含电话号码字段的派生数据库。

能使几乎没有数量限制的数据对于VRU或NTPI直接可用所缺少的环节是要产生一个标准的、精确的、可以分配给美国和美国领土内所有电话号码的全局数据库链接关键字。这一关键字需要作为电话号码和空间、地理及客户服务位置数据库之间的直接和/或转换链接机制，其中服务区域可以是任意定义的大小和形状。由于上述数据库共有的一个特性是其地理/空间位置、定义和/或关系，因此我们所需要的是一种可靠的全局分层地理/空间链接关键字，这里被称为空间关键字。使用空间关键字，向主叫提供信息和/或连接主叫与一个服务位置的许多VRU应用就可以实现自动化处理。

我们可以从VRU或NTPI盒与空间链接或空间关键字链接的几种实施例中作出选择。这些实施例包括：(1)使用一个主控表和一个自动生成的客户表，前者包括主叫提供的电话号码，该号码带有对应的空间关键字，后者链接空间关键字与客户服务位置信息。(2)当传送速度非常重要或需要与当前通信网兼容时，使用单个表来链接电话号码与其他电话号码。通信网通常需要很长的引导时间来导入新技术。由于这种实施例只使用单个表，从通信网的角度来看，它是实现最简单的实施例。(3)当高呼叫量和业务处理速度没有问题以及/或计算机存储资源有限、而且应用不需要空间关键字与空间关键字索引的其他数据库链接时，使用实时空间处理来联结准确的主叫位置与准确的服务位置。这种系统是更新最简单的实施例，可以单独维护所需文件。

现来的实时呼叫处理方法不够精确。典型的现有方法使用区号和局号(6位)而不是美国电话号码所有的十位数字。例如，Riskin专利使用Bellcore的V&H坐标系统识别主叫位置和服务位置，其精确度在正负五英里之内。这种现有系统没有使用对服务位置的精确服务区域定义，而是使用客户定义的围绕主叫位置的搜索半径。但是，主叫位置定义为与主叫电话物理连接的电话交换机的V&H坐标，因此搜索半径实际上围绕的是每台电话交换机。搜索半径用于访问一个V&H坐标交叉索引的服务位置文件，以得到一个可能服务位置清单。然后进行计算，以确定主叫交换机的位置与每个可能服务位置所用交换机位置之间的距离。该信息用于产生最后的服务位置清单。

我们需要的是一种可以精确地确定主叫或主叫提供的电话号码位置和服务位置的系统。另外需要客户能够精确定义围绕每个服务位置的服务区域。还需要能够迅速传送电话呼叫，使主叫不会注意到它的进行。为此不再需要原有系统为了确定服务位置所采用的计算主叫位置到服务位置之间距离的不精确方法。这里所提到的系统可精确地确定上述两点距离的能力为进一步在多个主叫服务位置之间进行选择和提供一个服务位置到主叫的距离信息提供了一个极有价值的信息项。

我们还需要通过使用系统中的实时处理，以便能够利用由坐标定义的一个移动或便携式电话的瞬时位置识别一个或多个主叫服务位置。实时处理可以为主叫实时(在运动中)计算一个或多个服务位置。在一个实施例中，系统将从电话网中获得移动电话的坐标，例如纬度和经度。其他实施例可以使用其他坐标类型或实时处理之外的处理方式。

在所有需要的实施例中，最好使用与一个客户服务位置对应的具有任何所需大小和形状的服务区域。另外，最好可选地允许客户向主叫提供服务区域信息。例如，这种选项最好使用具有语音/话音特性的NTPI盒实现，该NTPI盒通过一个服务位置ID或电话号码与一个包括客户服务信息的文件链接。例如，可选的客户服务位置信息可以包括向主叫提供诸如向所选服务位置邮寄、取和/或送某种物品所用的地址；向主叫提供预存储的到服务位置的微区域方向；或向主叫提供该位置的营业时间、停业时间或工作时间。

发明概述

本发明包括一种通过连接主叫与一个服务位置和/或向主叫提供与服务位置有关的信息来自动处理电话呼叫的系统和方法。

本发明提供了一种用于传送所有已公开和未公开的电话号码的方法，其中包括未列出的号码、第二条未公开的公司线路、移动电话和公共付费电话。本发明还提供了一种方法，通过把用户的呼叫准确地传送到正确合法的特许区域内，从而合法地实现与经销商和总经销商之间达成协议的特许区域定义相一致。另外，本发明提供了一种方法，根据包括邮政地理区域、普查地理区域、通信地理区域、专用网格坐标地理区域和所有传统地理区域在内的任何地理区域定义，从而准确地传送电话呼叫。

本发明提供了一种用于自动传送和处理不满足预置客户协议的用户呼叫的方法。这种“异常处理”过程向一个执行预置异常处理协议的“实际”操作员传送呼叫。本发明还提供了一种方法，用于把不相关的地理信息系统和数据库技术、通信系统和数据库技术、邮政系统和数据库技术、以及计算机技术集成为一种公共应用驱动的结构。另外，本发明提供了一种方法，用于动态和瞬时地更新和集成客户和主控表，而没有任何时间延迟。而且，本发明还提供了一种方法，用于自动化处理用户通过使用用户接口输入的信息，该处理自动向用户所要求的目的地传送电话呼叫。

本发明提供了一种双表系统，以便通过使用主叫电话号码、确定该位置的空间关键字、并在空间上链接关键字与服务位置来确定主叫对应电话的准确位置，其中服务位置的服务区域可以定义为任意大小或形状。或者可以用一个主叫提供的电话号码替代主叫的电话号码，这时的服务位置是与主叫提供的电话号码对应的一个电话的位置。这一处理开始于从第一个表中检索通信网捕获的一个10位主叫电话号码及其对应的空间关键字。然后，从自动处理生成的第二个表中检索具有对应的空间关键字的记录，该处理可通过算术运算来建立空间关键字与任意大小和形状的服务区域之间的空间覆盖关系。最后，向通信网回送与被检索的服务位置相关的数据，以便连接主叫和一个所选服务位置，或作进一步的网络处理。

该系统的关键部分包括一个主叫位置识别器，用于根据空间关键字和传送内核识别主叫或主叫提供的电话号码的准确空间和地理位置。传送内核使用一个被拨号码来有效地确定哪一个按地理位置定义的客户服务区域包括主叫提供的电话号码位置，并确定从主叫位置到其中每个服务位置的距离和方向。

与现有系统所用的人工处理创建和维护一个主叫电话号码到服务位置电话表相比，本发明提供了自动表创建处理的生成和维护优点。自动生成的客户表通过以下处理创建：访问一个服务区域清单，每次访问一个区域，以便确定哪些空间关键字(例如ZIP+4)在每个服务区域内；计算从每个ZIP+4到服务位置的距离；对于每个包含的ZIP+4，向一个文件内写入一条记录；并根据ZIP+4和距离升序对该文件进行分类和排序。

在一个实时处理实施例中，系统确定一个主叫的纬度和经度，并根据这个纬度和经度，在空间上确定一个可为主叫位置服务的可能位置清单。然后系统对清单中的每个可能位置进行一次详细的空间测试，以确定主叫的纬度和经度是否在服务位置的服务区域内。如果在服务区域内，就确定从主叫到服务位置的距离并将其添加到服务位置清单中。处理完所有可能位置之后，根据距离按降序对服务清单排序，并向应用作业流回送，以便由电话网用于传送呼叫。

为了进行有效的实时处理，使用了一个服务区域窗口文件。这个文件中的每条记录包括一个服务位置电话号码或ID以及根据所用径向定义的服务区域或多边形定义的服务区域的纬度和经度端点确定的一个纬度/经度窗口。

双表系统(主控和客户表)的一种派生物是包括一个客户服务位置表的三表系统。或者，客户服务位置表也可以被包含在单表系统或实时处理系统中。因此，客户服务位置表是对这些系统中任何一种的改进。

在双表系统中，主控表和客户表用于确定主叫提供的电话号码与服务位置的空间服务关系。不过，在有多个服务位置为一个主叫服务的呼叫处理中，为了给主叫选择最佳服务位置，还需要其他一些不具有任何空间属性的与服务位置相关的数据，例如营业时间、营业天数、产品存货等。这些数据存储在被称为客户服务位置表的第三个表中最有效。在这个根据服务位置标识(ID)或服务位置电话号码来进行索引的表中，每个服务位置有一条记录。该表中还包含各种可以通过语音响应单元播放给主叫的信息数据，例如服务位置、名称、地址、到一个服务位置的大致方向、一个终端电话号码、一个传真号码等等。

本发明的一个方面包括一种电话网呼叫处理系统，它具有：一个呼叫译码模块能接收一个被拨号码以及与一个主叫电话的瞬时位置对应的主叫空间坐标；一个实时处理模块，它响应被拨号码和主叫空间坐标，以便提供与一个所选服务位置对应的客户服务位置电话号码，其中如果主叫空间坐标被包含在一个具有客户定义的任意所要大小和形状设置的地理服务区域内，则提供该服务位置；和一个出局呼叫模块，用于向电话网传送所提供的客户服务位置电话号码。

本发明的另一个方面包括一种用于电话网的实时呼叫处理方法，该方法包括：接收一个被拨电话号码以及与一个主叫电话的瞬时位置对应的主叫空间坐标；响应被拨电话号码和主叫空间坐标，提供与一个所选服务位置对应的客户服务位置电话号码，其中如果主叫空间坐标被包含在一个具有客户定义的任意所要大小和形状设置的地理服务区域内，则选择该服务位置；并向电话网传送所提供的客户服务位置电话号码。

本发明还有一个方面包括一种可根据主叫位置传送用于移动电话的呼叫的自动呼叫处理系统和方法。该系统的一个实施例包括：一个呼叫译码模块，它能接收与一个主叫电话的瞬时位置对应的主叫空间坐标；一个中心交换机处理，它能检索出与一个所选客户服务位置对应的主叫空间坐标相关数据，其中中心交换机处理使用一个客户数据库，并且该客户数据库根据若干客户服务位置而生成，每个客户服务位置具有一个客户定义的任意所要大小和形状的对应服务区域；一个出局呼叫模块用于向电话网传送所述主叫空间坐标相关数据。

本发明还有一个方面包括电话网中一种可根据主叫位置传送用于移动电话的呼叫的自动呼叫处理系统，该系统具有：一个入局接收模块，它能接收与一个移动电话主叫的瞬时位置对应的主叫空间坐标；一个呼叫进程处理，它响应主叫空间坐标，以便提供一个客户服务位置电话号码，其中如果主叫空间坐标被包含在一个具有客户定义的任意所要大小和形状设置的地理服务区域内，则提供该服务位置；以及一个出局呼叫模块，它向电话网传送所提供的客户服务位置电话号码。

附图简述

图1a是在本发明当前优选的客户表创建处理中使用的文件方框图；

图1b是本发明中使用图1a表创建处理结果的部分动态中心交换机链接处理的方框图；

图1c是本发明当前优选的互联一个主叫电话与一个目的电话的中心交换机链接处理实施例的系统级示意图；

图2是说明用于图1c系统的一个传送网实例的地图；

图3是使用半径定义的服务区域创建图1c系统所用客户表的顶层处理流程图；

图4是说明图3所示处理的描述中一个所用示范区域的地图；

图5是图3中182所示的邮区窗口清单功能的流程图；

图6是图5中262所示的邮区窗口功能的流程图；

图7是图3中184所示的初始邮区清单功能的流程图；

图8是图7中322所示的从邮区清单中删除重复记录功能的流程图；

图9是图3中186所示的最终邮区清单功能的流程图；

图10是图3中188所示的zip+4位置半径检查功能的流程图；

图11是图3中196所示的最接近主叫的服务位置功能的流程图；

图12a是使用多边形定义的服务区域为图1系统创建客户表的顶层处理流程图；

图12b是图12a处理中所用文件的方框图；

图13是说明图12a所示处理的描述中一个所用示范区域的示意图；

图14是图12a中612所示的邮区窗口清单功能的流程图；

图15是图14中680所示的邮区窗口功能的流程图；

图16是图12a中614所示的初始邮区清单功能的流程图；

图17是图16中752所示的从邮区清单中删除重复记录功能的流程图；

图18是图12a中616所示的最终邮区清单功能的流程图；

图19a和19b是图12a中618所示的线路索引文件功能的流程图；

图20是图12a中620所示的zip+4位置多边形检查功能的流程图；

图21是图20中936所示的多边形内一点的检查功能的流程图；

图22是说明客户表创建处理所用文件和处理的方框图，其中客户表是用于单表系统第一实施例的一个电话号码到电话号码的表；

图23是说明单表系统第二实施例的合并操作所用文件和处理的方框图；

图24是图23中1040所示的匹配和添加功能的流程图；

图25是图24中1050所示的创建主控表清单子程序的流程图；

图26是图24中1052所示的创建客户表清单子程序的流程图；

图27是一个单表系统的方框图，包括交换机上所用的网络配置；

图28是一个呼叫处理链接过程实施例的流程图，该过程使用图22或图23以及图27的网络配置互联主叫电话处的主叫和目的电话；

图29是本系统的实时处理实施例所用文件和处理的方框图；

图30是一个实时处理系统方框图，包括呼叫处理中心所用的网络配置；

图31是图29中1212所示的服务区域窗口文件创建处理的流程图；

图32是图31中1250所示的半径纬度/经度功能的流程图；

图33是图31中1252所示的多边形纬度/经度功能的流程图；

图34是图31中1254所示的写服务区域窗口功能的流程图；

图35是图29中1220所示的实时处理顶层流程图，该处理创建一个服务位置清单，其服务区域包括主叫位置；

图36是图35中1346所示的初始服务区域清单功能的流程图；

图37是图35中1348所示的主叫位置在服务区域端点内的测试功能流程图；

图38是图37中1380所示的主叫在服务区域内的测试功能流程图；

图39是一个呼叫处理链接过程实施例的流程图，该过程使用图29的表和图30的网络配置互联主叫电话处的主叫和目的电话；以及

图40是一个呼叫处理链接过程实施例的流程图，该过程使用图29的表和图30的网络配置互联在固定位置主叫电话处或移动主叫电话处的主叫和目的电话。

优选实施例的详细描述

优选实施例的以下详细描述给出了对某些特定实施例的描述，以便于理解权利要求。不过，本发明可以用权利要求定义和涵盖的许多种不同方法来实现。

下面将参考附图，其中相同的代号在全文中代表相同的部分。

为了方便，对优选实施例的讨论将按照以下十六个主要部分进行：

Ⅰ．系统概述；

Ⅱ．传送实例；

Ⅲ．通用客户表创建处理；

Ⅳ．用于半径定义的服务区域的客户表创建处理；

Ⅴ．用于最接近主叫的服务区域的客户表创建处理；

Ⅵ．用于多边形定义的服务区域的客户表创建处理；

Ⅶ．单表系统概述；

Ⅷ．单表系统表创建处理；

Ⅸ．用于单表系统的计算机-电话集成网络配置；

Ⅹ．单表系统实例；

Ⅺ．实时处理系统概述；

Ⅻ．用于实时处理系统的计算机-电话集成网络配置；

ⅩⅢ．实时处理：创建服务区域窗口文件的脱线处理；

ⅩⅣ．实时处理：创建服务位置清单的呼叫期间处理，其服务区域包括主叫提供的电话号码位置；

ⅩⅤ．实时处理系统实例；

ⅩⅥ．带有移动电话的实时处理；

ⅩⅦ．其他移动电话实施例；以及

ⅩⅧ．总结

Ⅰ．系统概述

本发明包括一种自动电话传送系统，它接收来自一个公共服务商，例如AT&T或AT&T AMERICAN TRANSTECH的输入。该输入包括一个更新的国内电话号码、通信基础结构和异常处理支持清单。

将要描述的是用于自动和无缝地从一部主叫电话向客户选择的一部目的电话传送电话呼叫的系统和方法。如果某个客户愿意的话，可以向主叫提供与客户服务位置有关的可选信息。另外，还要描述根据客户建立的准则来创建传送系统所用数据表的一种方法。以下讨论的数据表也可以称为文件或数据库。

参考图1a，在创建本发明的“1-800”传送中所用的主叫电话号码到服务位置电话号码表时，需要进行的计算数和必须测试的置换数减少了。因此，邮区窗口文件104(图1a)和对该文件作空间访问和操作的处理105是本发明的一个部分。应当理解邮区窗口文件104只是可以包括不同类型空间关键字的空间窗口文件的一种实施例。邮区窗口文件104包含一个所有邮区代码的清单，该代码可表示一个十分之一纬度和经度(0.1°)的空间窗口。通过使用一组纬度和经度端点(最小值和最大值)代表处理105中的一个服务区域，可以生成一个能覆盖服务区域的5位邮区代码清单。之后，就只需要对每个服务位置和一个很小的zip+4代码子集进行一次“服务区域内”测试，该子集包含在每个服务区域返回的5位邮区代码清单内。下文将进一步解释文件104和处理105，并给出一个实例。

在一个实施例中，通过建立一个动态链接的更新系统，解决了更新问题以及为每个使用自动电话传送系统的公司或客户进行连续更新和周期性地重建具有上十亿条记录的电话号码到电话号码表的成本问题。与为每个客户建立一个电话号码到电话号码表不同的是，如图1b所示，建立了两个通过zip+4代码链接的表。使用邮政业务的Zip+4代码地址编码规则和商业上可提供的软件，例如GROUP 1软件公司提供的CODE-1^(用于主计算机和大型机)或AccuMail^(用于个人计算机或小型机)，为每个具有相应物理街道地址的电话号码分配一个zip+4代码，并建立一个主控电话号码到Zip+4代码表107(图1b)(“主控表”)。目前由AT&T AMERICAN TRANSTECH保存的优选主控表通过电话号码进行索引或排序，并且每日更新。当添加、改变或删除电话号码时，更新该表。另外还要周期性地更新该表，以处理每个季度约一百次左右的5位邮区代码变化，例如当一个新的邮区代码产生时，必须为新代码区域内的电话号码分配一个新的zip+4代码。与美国的43,000个邮区代码(5位)相比，这只是非常少量的变化。还要对该表作周期性的更新，以处理NPA-NXX分裂。在传送呼叫时，本系统允许所有用户使用同一个主控电话号码到Zip+4代码表107。

在单个客户的基础上，使用标准的“服务区域内”确定处理，根据其纬度和经度重心坐标，28,000,000以上个zip+4代码中的每一个被独立分配给了一个或多个服务位置。

这样，本发明就创建了一个客户Zip+4代码到服务位置电话号码表106(“客户表”，图1a和1b)。为每个客户或一个客户拥有的每个“1-800”电话号码创建一个不同的表。客户表创建处理一次处理一条客户位置记录。处理每条记录需要的程序是该位置服务区域定义：即半径或多边形的函数。一个中间客户文件一旦生成，就可以通过删除不是最接近主叫的位置来降低磁盘存储要求。下文将描述生成半径和多边形的客户表记录以及生成一个“最近位置”客户文件的创建后处理。

然后，最好把客户表106提供给AT&T AMERICAN TRANSTECH，以在呼叫处理中心进行集中传送。该表通过zip+4代码索引或排序，并在每个客户添加或删除位置以及改变电话号码时进行更新，同时周期性地进行更新，以处理邮政局邮区代码变化和电话网NPA-NXX分离。

使用当前的优选系统，主控表107和客户表106都是由不同的组织独立保存的。使用zip+4代码作为一个空间关键字链接，如图1b所示，就可以动态链接主控表107中的主叫电话号码与客户表106中的一个服务位置电话号码，并自动传送呼叫。空间关键字是识别由坐标集定义的一个指定地理区域、线路或点的单个号码。对于点或三角之类的简单地理符号，空间关键字可以是地理坐标描述的编码形式。

邮政zip+4代码是用于链接主控表和客户表的优选空间关键字，不过一些其他较小的地理区域也能具有唯一的空间关键字，例如zip+6代码区域，普查街区、或极小的纬度/经度网格、矩形、窗口或方格。在用户不断移动和公司正在营业、停业和/或搬家的环境下，这种双表索引方式提供了高得多的自动传送速率和更高比例被正确传送的呼叫。另外，双表索引方式还可以用作被管制的电话号码信息与客户销售信息之间的“防火墙”或缓冲器，以服从政府的管制。

本发明的系统使用AT&T通信网，在大约40毫秒的时间内直接从主叫向最近的服务位置传送电话呼叫。Riskin描述的系统使用一台专用小交换机截取呼叫，利用客户录音消息应答呼叫，并请求主叫等待，同时它要用大约15,000毫秒的时间寻找最近的服务位置，然后将呼叫转移到给服务位置。

为传送一次呼叫，本发明的系统在具有100,000,000条以上记录的主控表中查找主叫的10位电话号码，检索出识别主叫电话的空间关键字，在具有28,000,000条以上记录的客户表中查找该空间关键字，并检索出为主叫的空间关键字或位置服务的服务位置电话号码。Riskin描述的系统在它只有18,000个唯一坐标、64,000条记录的交换局号文件中查找主叫的6位局号，检索出该局号的V-H(垂直-水平)坐标，交叉该V-H坐标，并开始对N条记录的客户服务位置数据库进行二进制迭代的、基于V-H关键字的大小搜索。Riskin系统通过这一处理进行迭代，调整被搜索的地理区域的大小，直到检索出若干个落在预定范围内的服务位置。然后，Riskin计算到每个服务位置的距离。如果有一个以上的位置符合最近距离的标准，随机选择一个位置作为最近的服务位置。

Ⅱ．传送实例

在更详细地讨论客户表的创建之前，首先讨论该表和主控表在“1-800”传送实例中的使用是很有帮助的。参考图1c所示的中心交换机处理108和图2所示传送网络，下面将给出电话呼叫传送的一个实例。在这个例子中，主叫通过他位于CA 92075-2064 Solana Beach的Stevens大街498号的话机(619-755-5666)拨打1-800-Italian订购“MyPizza”的比萨饼。当然，本发明不局限于使用“800”电话号码，其他号码也可以在其他实施例中使用。

图1c包括处理状态以及114、132和146处平行四边形所示的数据。同样，中心局交换机处理将如下所述，在一台交换机内进行。

自动向主叫的本地MyPizza餐馆传送呼叫涉及的步骤如下：

1．“位置A”160(图2)处的主叫在模块110(图1c)拨打1-800-Italian，例如订购一个比萨饼。

2．根据所拨的1-800和主叫的长途服务商，该呼叫由不同的电话公司传送到佛罗里达洲Jacksonville的一个智能中心交换机上，如图2的“位置B”162所示。与交换机有关的处理在图1c中如状态112之前的虚线以下和状态148之后的虚线以上所示。中心交换机111最好是一台可从AT&T得到的“4 ESS^TM”数字交换机。交换机包括一台通用计算机(未示出)，例如带有存储器的一台网络控制点计算机。

3．Jacksonville交换机一旦接收到呼叫，就通过进行自动号码标识(ANI)的呼叫译码硬件112，从主叫信息分组114中提取出主叫的电话号码。优选的信息分组114对应于交换机111中可用的SS7 TCAP消息的操作参数字段。Kaplan的美国专利第5,163,087号中描述了执行ANI的硬件，该文献在此作为参考被包含。与1-800-Italian等效的号码是1-800-482-5426，信息分组显示如下：分组：……6197555666……18004825426……

“1-800”号码是一个IN-WATS(入局广域电话业务)号码，必须由一个广域服务商转换成一个要向交换机111传送的POTS(普通老式电话业务)号码。一旦接收到这个POTS号码，交换机111就又把它转换为WATS格式。

4．然后，在判决状态116，处理108确定客户是否选择为主叫提供通过一个按键式话机键盘或其他装置输入一个电话号码的选项。在其他实施例中，可以输入其他字符，例如信用卡号码、帐号或产品订购信息，以实现系统的其他特性。在当前的优选实施例中，该电话号码代表主叫希望诸如投送一件产品或进行一项服务的位置。举例来说，如果客户有一个诸如800-FLORIST的电话号码并需要可选的输入特性，主叫可以选择把鲜花投送到与主叫输入电话号码对应的地址。如果判决状态116的判决结果为肯定，处理108转移到状态118，以捕获主叫输入的电话号码。然后使用该号码替代信息分组中的主叫号码进行下一步处理。不过，如果判决状态116的判决结果是否定，就不改变初始主叫号码，处理108转移到判决状态120。

5．在判决状态120，处理108确定信息分组中的主叫号码是否是移动电话号码。交换机111的计算机内显示移动电话号码的文件当前由AT&T AMERICAN TRANSTECH保存，并在需要时更新。在美国，为移动电话分配的是来自一个前缀集的号码，该前缀集对于每个区号唯一。因此移动电话号码文件只需要包含区号和前缀组合(6位)来识别主叫号码是一个移动电话号码。因为判决状态120判断出的移动电话用户不对应一个固定位置，所以处理108要转移到状态128进行无法传送的异常处理。然后一个操作员将请求来自移动电话主叫的位置信息。关于状态128的其他信息将在下文提供。如果主叫没有使用移动电话，处理108从状态120前进到状态122。

6．在状态122，处理108执行查找功能，即最好使用一个实施例中众所熟知的索引顺序存取法(ISAM)来查找主叫电话号码，以索引主控电话号码到Zip+4表107(图1b)。ISAM是一种众所熟知的搜索方法，在Peterson和Silberschatz所著的《操作系统原理》一书中有关于它的描述。在其他实施例中，一种确定器用于确定合适的空间关键字。其他查找或确定技术可用于其他实施例。“系统概述”部分中描述了主控表107。举例来说，主控表107的一个片段如表1所示。该表由电话号码来索引，并且还包含主叫号码所在物理地址的zip+4代码132。

表1

举例：主控电话号码到Zip+4表片段

电话号码        Zip+4

6197555664    920751111

6197555665    920141313＞  6197555666    920752064

6197555668    920071234

7．在判决状态126进行一次测试，以确定主叫号码是否在主控表中列出。如果没有，处理108转移到状态128，在此提供操作员助理来传送呼叫。状态128的无法传送呼叫异常处理被用于主控表107或客户表(图1a)记录缺失、有误或主叫使用一部移动电话的情况。在当前的优选实施例中，操作员助理由AT&T AMERICAN TRANSTECH提供。通常，只有很少一部分主叫号码没有在主控表107中列出。如果主叫号码没有在主控表107中列出，处理108前进到判决状态130，以便确定分组114中是否存在与主叫号码对应的zip+4代码132。如果没有，处理108转移到128，如前面所述，在此提供操作员助理来传送呼叫。如果主控表107中存在zip+4代码132，处理108转移到状态134。

8．因为信息分组114也包括所拨号码，处理108在状态134打开与具有电话号码800-482-5426的客户对应的客户Zip+4到服务位置表A 106a。客户表106是根据主叫所拨电话号码从若干客户表中选出的。如果需要，客户表B 106b和其他表可用于其他客户或同一客户的其他电话号码，例如另一个“800”号码。客户表由本发明的受让人、客户或受让人指定的第三方创建。客户表有两种类型。如果要向最近位置或者为一个不覆盖多边形商业区域服务的服务位置传送呼叫，对于每个zip+4代码，第一型客户表只包含具有相应服务电话号码146和距离的一条记录。当客户希望在为主叫服务的多种可选服务区域中作随机或加权选择或为主叫提供选择时，第二型客户表可以包含每个zip+4代码的多条记录，每条记录具有不同的服务电话号码和距离。处理108使用索引顺序存取法在MyPizza客户表106a中查找主叫的zip+4代码。

9．在判决状态140进行一次测试，以确定zip+4代码132是否在客户表106a中列出。如果没有，处理108转移到状态128，在此提供操作员助理来传送呼叫。如果客户表106a中存在该zip+4代码，处理108前进到状态142，以便确定是否有用于zip+4代码132的客户电话清单。如果没有，处理108转移到状态144，在此提供操作员助理来传送呼叫、提供信息、或进行由客户决定的其他操作。状态142处可能出现否定的测试结果，例如当没有服务区域包括主叫方位置的服务位置存在时。状态144的异常处理用于正确传送了呼叫但是主叫方没有得到期待的结果、即不能令人满意地完成呼叫(正如在状态142、152和154中)的情况。这时，客户可以在能够由自动处理过程完成的一个可选操作集之中进行选择。一种示范的异常处理消息如下：“很抱歉，目前没有可以为您服务的服务位置。如果您希望与业务代表通话，请按0。”

如果有一个与zip+4代码132对应的客户电话号码，处理108前进到状态148。举例来说，客户表106a的一个片段如表2所示。

表2

举例：800-482-5426客户表片段

Zip+4        电话号码      距离(英里)

920752060    6199423366    3.1456

920752062    6199423366    2.1682＞  920752064    6194817777    1.2864

920752065    6197591111    0.1234

10．找到主叫的zip+4代码132和对应的服务电话号码146之后，交换机在状态148通过电话网传送信息分组，使得与号码619-481-777对应的电话振铃。

11．在模块150，位于“位置C”164(图2)、即CA 92014-1909 DelMar的ViA De La 2688号的MyPizza店内的电话进行振铃。

12．如果客户服务位置处的电话“占线”152或“无应答”154，处理108前进到前面所述的异常处理状态144。例如，在客户的请求下，状态144的异常处理可以向下一个最近的服务位置传送呼叫。否则，如果“占线”或“无应答”情况不存在，电话呼叫被应答，主叫可以订购一张比萨饼。

Ⅲ．通用客户表创建处理

下面将描述为每个客户或每个“800”或类似客户号码生成或创建一个客户表106的处理105(图1a)。该处理最好在一台通用计算机、例如AT&T 3600 UNIX主机上进行。正如前面提到的，本发明包括两种类型的服务区域定义：半径和多边形。下面将讨论如何把这两种定义归入客户表创建处理。另外，还要讨论从客户表中删除较长距离记录的创建后处理，以创建一个只包含到主叫的最近服务位置的客户表。这种处理用来在没有为主叫提供选择的装置并且只可以向通信网传递一个服务位置电话号码的应用中减少磁盘存储量。下面将利用一个假想的食品服务公司给出一个处理步骤实例。

用于每种服务区域定义的处理使用如图1a所示的四个输入文件。“系统概述”一节已简单讨论了Zip+4重心文件和邮区窗口文件。下面进一步讨论每个输入文件。以下讨论仍然参考图1a。A．客户服务位置文件

第一个文件是包含客户提供的服务位置清单的一个客户服务位置文件109。服务位置及其服务区域通过一个纬度/经度位置和一个半径或者一个纬度/经度位置和一个纬度/经度多边形来定义。结合图3(半径)的状态174和图12a(多边形)的状态604将提供关于文件109的更多细节。B．Zip+4 Lat Lon重心文件

第二个文件是以前描述的Zip+4纬度和经度重心文件100或Zip+4_Lat_Lon重心文件。该文件可以从美国邮政业务局或者地理数据技术公司(GDT)获得。C．邮区阵列文件

第三个文件是根据Zip+4纬度和经度重心文件100生成的邮区阵列文件103，它提供了三个提高处理效率的优点。

第一个优点是创建了一个阵列行号等于一个5位邮区代码的阵列。它提供了一种非常有效的索引5位邮区代码的方法，其中5位邮区代码的数值是阵列的行号。

第二个优点是一旦访问到阵列中的5位邮区代码，就能知道这个5位邮区代码的第一个zip+4代码在Zip+4纬度和经度重心文件100中精确的字节偏移。使用这种方法，可以在超过28,000,000条记录的Zip+4纬度和经度重心文件100中非常迅速地找到一个5位邮区代码的第一条zip+4记录的位置，并读取该代码的所有zip+4记录。

邮区阵列文件103的第三个优点是，对于每个五位邮区代码，该文件包含该5位邮区代码中所有zip+4代码的纬度和经度最小值及最大值。通过查看一个半径或多边形服务区域的端点集是否与5位邮区代码端点重叠，如果预先确定了5位邮区代码中的zip+4端点与半径或多边形服务区域没有空间重叠，就不用测试5位邮区代码中的每个zip+4端点。

邮区阵列文件103是使用GDT或邮政局提供的Zip+4纬度和经度重心文件100生成的。重心文件100中的每条记录包含一个zip+4号码、以及为每个zip+4定义的纬度和经度重心。一个如下所述的四步骤邮区阵列文件创建处理101用于生成邮区阵列文件103：

1．)把一个99,999行、6列的32位整数阵列初始化为零。第一列初始化为之后用作5位邮区代码的行号。

2．)对于一个5位邮区代码，按顺序读取Zip+4纬度和经度重心文件100中的每条zip+4记录。注意5位邮区代码中第一条zip+4记录的字节偏移。初始化临时变量，再将它们用来为当前5位邮区代码确定zip+4重心的纬度和经度最小值及最大值。然后向下一步骤传递当前5位邮区代码中所有zip+4代码的最大和最小纬度及经度值。

3．)每次5位邮区代码发生变化时，对于邮区阵列文件103中前一5位邮区代码的位置，把5位邮区代码内第一个zip+4的字节偏移以及5位邮区代码内所有zip+4代码的纬度和经度最小值及最大值写入存储区。然后重新初始化纬度和经度最小值及最大值，对下一个5位邮区代码重复上一步骤和当前步骤，直到Zip+4重心文件100末尾。

4．)一旦到达Zip+4重心文件100末尾，向存储区写入最后一条5位邮区代码记录，然后把存储在存储区内的邮区阵列文件写入一个大容量存储设备，例如一个磁盘。

邮区阵列文件103每一行的列定义如下：

列(1)是5位邮区代码号；

列(2)是该行邮区代码中最小编号的zip+4在Zip+4_Lat_Lon重心文件中所处位置的字节偏移；

列(3)是该行邮区代码的最小纬度(zip_lat_min)；

列(4)是该行邮区代码的最大纬度(zip_lat_max)；

列(5)是该行邮区代码的最小经度(zip_lon_min)；以及

列(6)是该行邮区代码的最大经度(zip_lon_max)。D．邮区窗口(Zip windows)文件

第四个文件是Zip_windows文件104。这个文件用于在地球上根据纬度及经度定义的区域和理论上可触及该区域的邮区代码之间建立一个链接。该链接的优点是使得对邮政地理区域的空间搜索要快得多和有效得多。

Zip_windows文件104是根据GDT或邮政局的Zip+4纬度和经度重心文件100、使用通过一个5位邮区代码内的Zip+4端点产生的纬度和经度5位邮区代码端点而生成的。基本原理是把地球划分成十分之一(0.1°)纬度和经度的矩形，例如，该矩形在40°纬度处的长和宽约为6.9英里和5.2英里，然后列出覆盖每个矩形的所有邮区代码。

Zip_windows文件104通过Zip_windows文件创建处理102来生成，该处理从超过28,000,000条记录的Zip+4重心文件100中读取每条记录，并写入一条包含一个纬度和经度(lat/lon)窗口及一个5位邮区代码的对应记录。lat/lon窗口字段通过以下处理生成：将以度数为单位的纬度乘以10，提取乘积的整数部分(INT)，将整数部分乘以10,000，然后加上以度数为单位的经度与10相乘后所得乘积的整数部分。

例如，假设输入zip+4记录是920141909，纬度是北纬32.9862，经度是西经117.2522，则输出邮区窗口记录的lat/lon窗口字段将是3291172，邮区代码字段将是92104。所有记录都被写入一个初始或临时Zip_windows文件(未示出)之后，就根据lat/lon窗口值或带有对应的5位邮区代码的关键字对该文件分类，并删除重复记录。然后向最终的Zip_windows文件104写入由lat/lon窗口关键字和对应的5位邮区代码组成的每条记录。如图4所示，四个lat/lon窗口210、212、214、216分别对应邮区窗口关键字3301172、3301171、3291172、3291171。

描述了客户表创建处理所用的输入文件之后，下面将分别描述三种不同服务区域定义下的创建处理。

Ⅳ．用于半径定义的服务区域的客户表创建处理

下面将参考图3和图4，描述用于半径定义的服务区域的客户表创建处理170。处理170是图1a所示客户表创建处理105的一种特定形式。

处理170开始于起始状态172，并转移到状态174，在该状态中，客户以机读形式提供一个关于服务位置的客户服务位置文件109(图1a)，该表带有的信息和格式如表3所示。文件109可由一个常用的字处理程序或数据库程序来生成，并通过软盘或其他合适的媒质来递交。表3包括名为MyPizza Ristorante的一个服务位置218的示范信息。图4的地图说明了部分相同的信息，其中包括一个圆220，它表示自MyPizza Ristorante开始的2.5英里半径范围为服务区域。

            表3

    ASCII字符形式的记录服务位置名称(30)字节        ：MyPizza Ristorante地址(36)字节                ：2688 Via De La Valle城市(30)字节                ：Del Mar州(2)字节                   ：CA邮区代码(9)字节             ：92014电话号码(10)字节            ：61948177770.1英里为单位的半径(9)字节  ：25当然，在其他实施例中也可以采用其他形式、信息和格式。

处理170转移到状态176，使用Group 1和地理数据技术等公司的商用软件，对文件109中的服务位置清单进行地址标准化、zip+4编码和纬度及经度地理编码。表4是添加了纬度和经度的一条标准化记录。

                        表4服务位置名称(30)字节          ：MYPIZZA RISTORANTE地址(36)字节                  ：2688 VIA DE LA VALLE城市(30)字节                  ：DEL MAR州(2)字节                     ：CA邮区代码(9)字节               ：920141909电话号码(10)字节              ：61948177770.1英里为单位的半径(9)字节    ：25度为单位的纬度(10)字节        ：32.9862度为单位的经度(12)字节        ：-117.2522

处理170转移到状态178，产生每一纬度为68.9404英里的一个常数，并把邮区阵列文件103(图1a)读入计算机内存。在状态180，处理170从服务位置记录文件中读取一条记录，并计算服务位置处每一经度的英里数。每一经度的英里数=68.9404*COSINE(纬度)。对于表4内给出的实例，在纬度32.9862处，求得每一经度为57.8297英里。

处理170转移到功能182，产生服务位置触及的一个邮区窗口清单。触及一个邮区窗口意味着至少有部分服务区域在该邮区窗口内或覆盖该窗口。图4说明了表4中给出的示范邮区窗口210、212、214、216。下文将结合图5进一步描述功能182。

处理170转移到功能184，产生一个触及由功能182识别出的任何一个邮区窗口的5位邮区代码清单。该邮区清单按升序排列，重复的邮区代码在功能184中被删除。下文将根据图7进一步描述功能184。

处理170转移到功能186，从功能184产生的邮区清单中删除不在状态174中指定的服务位置半径内的5位邮区代码，并产生最终邮区清单。下文将根据图9进一步描述功能186。

处理170转移到功能188，在与邮区指针清单(由功能186生成)一起使用的最终邮区清单(同样由功能186生成)中检索与邮区代码对应的所有zip+4记录，并确定zip+4是否在服务区域半径上或之内。这一判决还能得到从服务位置到zip+4重心的距离(zip+4重心存储在Zip+4重心文件100中)。如果确定zip+4是在服务区域半径上或之内，就向一个原始客户表写入一条记录，该记录包括zip+4代码、即时服务位置的客户电话号码、以及zip+4重心到服务位置的距离。下文将根据图10进一步描述功能188。

处理170转移到功能190，确定是否还有客户服务记录需要处理。如果有，对下一条服务位置记录重复状态180到188的循环。如果已经为即时客户表处理完所有服务位置记录，处理170前进到状态192。在状态192，处理170对通过功能188写入的原始记录进行分类，按照zip+4代码升序排列，如果同一zip+4代码出现多次，则按距离降序排列。如果有多个服务位置的服务区域覆盖同一个zip+4，这个zip+4代码可能会出现多次。

转移到状态194，确定客户是否选择了生成距离主叫最近的服务位置客户表的创建后选项。如果没有，除了在状态198向生成系统计算机加载文件之外，客户表创建处理就算完成了。不过，如果正如判决状态194的判决结果，客户选择了“最近服务位置”的创建后选项，则处理170就转移到功能196，以完成客户表创建处理。下文将根据图11进一步描述功能196。

如果客户在判决状态194没有选择“最近服务位置”选项，处理170就转移到状态196，在状态192经过排序的客户表被加载到电话网交换机111(图1c)的计算机中，并建立了对zip+4代码的一个索引关键字。功能196或状态198一经完成，客户表创建处理就在状态200结束。

下面参考图5，描述图3中定义的功能182。功能182通过首先计算一个位置的纬度和经度端点产生该位置所触及的一个邮区窗口清单。在计算中，纬度和经度均采用绝对值。

在本发明的另一个实施例中，根据纬度或经度的极性向窗口关键字分配了一个前缀。美国位于西北象限，用于这个象限的关键字是零(0)。一个前缀零对数字关键字的值没有影响。其他象限是东北，北半球英国格林威治本初子午线圈以东；西南，南半球本初子午线圈以西；以及东南，南半球本初子午线圈以东。

因为世界上几乎所有国家都只在一个象限内，所以使用纬度和经度的绝对值可以正常工作。在少数例外(两个象限内)的国家中，可以使用不同的坐标系统，例如英国使用的传统测量系统。

处理170从图5所示的起始状态252开始，转移到状态254，计算服务区域的纬度端点。下面将使用几种缩写：“min”代表最小值，“max”代表最大值，“lat”代表纬度，“lon”代表经度，“site”代表服务区域的地点或位置。Site_lat_min=site_lat-半径(英里数)/每一纬度的英里数；Site_lat_max=site_lat+半径(英里数)/每一纬度的英里数。计算表4给出的示范服务位置和半径，得：

Site_lat_min=32.9862-2.5/68.9404=32.9499；

Site_lat_max=32.9862+2.5/68.9404=33.0228.处理继续在状态256，在此计算服务区域的经度端点：Site_lon_min=site_lon-半径(英里数)/每一经度的英里数；Site_lon_max=site_lon+半径(英里数)/每一经度的英里数。计算表4给出的示范服务位置和半径，得：

Site_lon_min=117.2522-2.5/57.8297=117.2089；

Site_lon_max=117.2522-2.5/57.8297=117.2954。

处理170转移到状态258和260，分别根据该位置的纬度和经度，产生邮区窗口的最小值和最大值。使用以上范例计算求得：

Site_lat_Window_min=Int(10*site_lat_min)=329；

Site_lat_Window_max=Int(10*site_lat_max)=330；

Site_lon_window_min=Int(10*site_lon_min)=1172；

Site_lon_window_max=Int(10*site_lon_max)=1172；

处理170转移到功能262，根据纬度最小和最大值以及经度最小和最大值产生邮区窗口，并将其存储在不同于Zip_windows文件104(图1a)的一个邮区窗口清单(zip_window_list)中。下面将根据图6进一步描述功能262。功能182返回图3中的状态264。

下面参考图6，描述图5中定义的功能262。功能262创建用于服务位置的实际zip_window_list。该模块开始于起始状态270，并转移到状态272，置变量1为零(0)，置变量J等于该位置纬度窗口的最小值。经过状态272的初始化之后，处理170转移到状态274，在此置变量K等于该位置经度窗口的最小值。转移到状态276，变量1的值加一。

在状态278，通过将变量J的值乘以10000，再加上变量K的值，计算zip_window_list中由变量1识别或寻址的一个值。状态280确定K的值是否达到最大值，如果没有，K的值在状态282加一(1)，并执行到状态276的循环。如果K达到了该位置的最大经度值，处理170转移到状态284，以便确定J的值是否达到了最大值，如果没有，J的值在状态286加一(1)，并执行到状态274的循环。如果J的值达到了该位置的最大纬度值，功能262返回图5的状态288。

继续以根据图5给出的范例为例，功能262的结果如下：

Zip_window_list(1)=3291172

Zip_window_list(2)=3301172

下面参考图7，描述图3中定义的功能184。功能184产生触及到功能182(图5)指定的邮区窗口的一个5位邮区代码清单。处理170从起始状态300开始，转移到状态302，检索前面描述的Zip_windows文件104(图1a)和功能182生成的zip_window_list。Zip_windows文件104通过邮区窗口(zip_window)关键字索引，并包含一个触及该邮区窗口的所有邮区代码清单。表5给出了与图4对应的一个示范Zip_windows文件104。

        表5

窗口      邮区代码

3291172    92014

3291172    92075

3291172    92130

3301172    92007

3301172    92014

3301172    92024

3301172    92029

3301172    92075

处理170转移到状态304，将变量K的值初始化为零(0)，变量J的值初始化为一(1)。然后，处理170在状态306推进到Zip_windows文件104中关键字与变量J所寻址的zip_window_list值相等的记录。在状态308，读取状态306中找出的记录，得到zip_window和对应的邮区代码。转移到状态310，变量K加一(1)，在其后的状态312中，向通过变量K寻址的一个邮区清单(zip_list)写入状态308中读出的邮区代码。然后在判决状态314进行一次检查，以便确定来自状态308的zip_window值是否大于通过变量J寻址的zip_window_list值。如果否，返回状态308读取Zip_windows文件104中的下一条记录。

如果判决状态314的结果为真，处理转移到判决状态316，以确定J的值是否等于zip_window_list中的窗口数目。如果不等，J的值加一(1)，并进行返回状态306的循环，以处理下一窗口。如果判决状态316为真，则zip_window_list中的所有窗口均已被处理，功能184转移到状态320，在此按降序对5位邮区代码的zip_list排序。继续参考以上范例，在状态320之后，zip_list如下所示：

        92007

        92014

        92014

        92024

        92029

        92075

        92075

        92130处理170转移到功能322，删除zip_list中的重复记录，产生一个deduped_zip_list。下文将参考图8进一步描述功能322。功能184返回图3的状态324。

下面将参考图8，描述图7中定义的功能322。功能322从经过图7状态320排序的zip_list中删除重复的5位邮区代码。处理170从起始状态340开始，转移到状态342，并把zip_list的第一条记录定义为deduped_zip_list的第一条记录。转移到状态344，将变量L置为一(1)，变量J置为二(2)。然后，处理170在判决状态346确定通过J寻址的zip_list值是否等于通过“J减一”寻址的zip_list值。如果不等，变量L在状态348加一，令deduped_zip_list中通过L寻址的下一条记录等于zip_list中通过J寻址的记录。

如果判决状态346的结果为真或者状态350完成时，处理170转移到判决状态352，以确定变量J的值是否等于zip_list中的邮区代码数。如果不等，变量J在状态354加一，处理170返回状态346，以检查zip_list中的下一条记录。不过，如果状态352确定zip_list中的所有邮区代码均已被检查过，功能322则返回图7的状态356。继续参考以上范例，完成功能322之后的deduped_zip_list如下所示：

                92007

                92014

                92024

                        92029

                        92075

                        92130

下面参考图9，描述图3中定义的功能186。功能186通过检查邮区边界端点以及从邮区阵列文件103中获取到Zip+4_Lat_Lon重心文件100(图la)起点的偏移，创建一个最终邮区(zip_final)清单和邮区指针(zip_pointer)清单。这一程序删除了不触及服务区域半径所覆盖区域的邮区代码。处理170从起始状态370开始，转移到状态372，并访问邮区阵列文件103(图1a)。功能186使用邮区阵列文件103(图1a)中如前面所述的所有列。转移到状态374，将变量1置为零，变量J置为一。转移到状态376，置变量M等于deduped_zip_list中通过J寻址的记录，该清单来自功能的184。

使用功能182中算出的位置信息和来自邮区阵列表的信息，在判决状态378到384进行一系列检查。在判决状态378，处理170确定site_lat_max是否小于通过变量M寻址的邮区阵列记录的zip_lat_min。如果是，处理170转移到判决状态386。如果否，处理进入判决状态380。在判决状态380，处理170确定site_lat_min是否大于通过变量M寻址的邮区阵列记录的zip_lat_max。如果是，处理170转移到判决状态386。如果否，处理进入判决状态382。

在判决状态382，处理170确定site_lon_max是否小于通过变量M寻址的邮区阵列记录的zip_lon_min。如果是，处理170转移到判决状态386。如果否，处理进入判决状态384。在判决状态384，处理170确定site_lon_min是否大于通过变量M寻址的邮区阵列记录的zip_lon_max。如果是，处理170转移到判决状态386。如果否，处理进入判决状态392。达到状态392时，已确定这个邮区代码确实触及该位置半径覆盖的区域。在状态392，变量1加一，在状态394，处理170在通过1寻址的zip_final清单记录中写入值M。转移到状态396，处理170在通过1寻址的zip_pointer清单记录中写入通过变量M寻址的邮区阵列文件记录的字节偏移，然后处理转移到状态386。

如果判决状态378到384中任何一个为真，就不再使用deduped_zip_list中当前的这条邮区代码记录。在判决状态386，确定是否已检查了deduped_zip_list中的所有记录。如果否，J在状态388加一，处理170返回状态376检查下一条记录。如果状态386确定已检查完所有记录，功能186返回图3的状态398。继续参考以上范例，完成功能186之后的zip_final清单如下所示：

                92007

                92014

                92075

                92130

下面参考图10，描述图3中定义的功能188。功能188读取通过zip_final清单和zip_pointer清单共同识别出的所有zip+4记录，并确定zip+4重心是否在该位置半径之内。处理170从起始状态420开始，转移到状态422，提取zip_final清单、zip_pointer清单和Zip+4重心文件100。在状态424，将变量J置为一。处理170转移到状态426，跳至Zip+4重心文件100中的一个地址，该地址包含在通过变量J寻址的zip_pointer清单中。之后在状态428，读取来自状态426地址的zip+4纬度/经度记录。Zip+4重心文件100(图1a)按zip+4升序排列，该文件中的每条记录包含三个字段：zip+4代码、以度为单位的纬度和以度为单位的经度。处理170转移到状态430，计算从服务位置到zip+4重心的距离。该位置的纬度和经度从状态176获得，而zip+4纬度和经度从状态428获得。处理170转移到状态432，确定来自状态430的距离平方是否大于半径的平方(可从状态174获得)。如果否，zip+4代码在该位置半径之内，处理170转移到状态434，以便去写下一条原始客户表的zip+4电话号码记录。该记录包含zip+4代码、客户服务位置的电话号码以及距离平方的平方根。

如果距离平方大于半径平方，zip+4代码在该位置半径之外，处理转移到判决状态436。处理170在状态436确定当前的zip+4代码是否大于10000乘以通过变量J寻址的zip_final清单记录值加上9999。通过在5位zip+4邮区代码后加上9999，比较当前zip+4与当前邮区代码下的最高可能编号zip+4的值。例如，如果邮区代码是92007，那么该邮区代码下的最高可能编号是920079999。读取邮区代码92007的zip+4记录时，如果读取的zip+4记录大于920079999，就已经经过了92007代码的zip+4记录终点，处理170转向zip_final清单中的下一个邮区代码。如果判决状态436为假，处理170转移到状态438，并推进至Zip+4重心文件100中同一5位邮区代码的下一条zip+4记录。下一条记录通过返回状态428而被读取。

如果判决状态436为真，处理170转移到判决状态440，确定是否已读取了zip_final清单中的所有记录。如果否，变量J在状态442加一，处理返回状态426，对zip_final清单中的下一个5位邮区代码重复该程序。如果状态440确定已处理完所有的5位邮区代码，功能188返回图3的状态444。继续参考以上范例，状态434结束时原始客户表中的一条样本记录如下所示：

样本记录：920752064 6194817777 1.2865

Ⅴ．用于最接近主叫的服务区域的客户表创建处理

“最近”处理，即功能196(图3)是一种根据半径定义的服务区域、多边形定义的服务区域或两种类型混合的服务区域创建一个客户表106的创建后处理。“最近”处理的主要功能是降低磁盘存储量和清除多边形数字化错误，后者会导致非重叠服务区域中的错误重叠。必须先完成半径处理中的状态172到194(图3)或多边形处理中的状态602到624(图12a)，以生成一个可由创建后处理196去降低大小或清除错误的中间客户表。

下面参考图11，描述图3中定义的功能196。功能196删除分配的多个zip+4代码，并保留具有最短距离的一个。功能196从起始状态500开始，在状态192结束时访问已排序中间客户表(未示出)。转移到状态504，置变量“last_zip+4”等于零值。然后在状态506从第一条记录开始，从中间客户表中读取一条记录。转移到状态508，判断刚从状态506的记录中读取的zip+4是否等于last_zip+4。如果否，在状态510向客户表106写入当前记录，之后在状态512设置变量last_zip+4等于当前的zip+4代码。

在状态512结束时，判决状态514确定是否到达已排序中间客户表的末尾。如果否，功能196跳至中间客户表中的下一个zip+4代码，并返回状态506处理下一条记录。如果状态514确定已到达中间客户表末尾，在电话交换机111中加载客户表106，并建立对zip+4代码的一个索引关键字。功能196在状态520返回到图3的状态200，以结束“最近”处理。

Ⅵ．用于多边形定义的服务区域的客户表创建处理

通常，有两种类型的多边形定义的服务区域。第一种类型是专用或非重叠服务区域，第二种类型是非专用或重叠服务区域。

对于非重叠多边形定义的服务区域，每个经销商具有一个特定的服务区域，例如他们投送一件产品的区域。下例用于说明这一概念。一个用户的位置距离经销商B要比经销商A近，但是如果用户在经销商A的多边形区域内，那么客户表106(图1a)内与用户位置对应的记录中将只有经销商A的电话号码。不过，如果经销商A和经销商B的服务区域是重叠的，客户表106将有一条记录带有经销商A的电话号码和距离，另一条记录带有经销商B的电话号码和距离。因此，客户表创建处理105包括两种多边形定义类型的服务区域。

下面将参考图12a、12b和13，描述用于多边形定义服务区域的客户表创建处理600。处理600是图1a所示的通用处理105的另一种特定形式。多边形定义的服务区域处理600(也称为多边形处理)的许多部分类似于半径定义的服务区域处理170。某些功能有很小的改动。某些功能则完全不同。对于几乎类似的功能，只指出和解释不同点，以避免重复。新的功能则将进行详细描述。

处理600从起始状态602开始，转移到状态604，其中客户以机读形式提供一个关于服务位置的客户服务位置文件109(图1a)，该文件带有的信息和格式如前面的表3所示。客户还可以提供一幅详细的街道地图，其中画出了服务位置的多边形服务区域，并在多边形服务区域内写有服务位置的电话号码。图13的地图说明了一个示范的多边形服务区域640。

处理600转移到状态606，其中使用Group 1和地理数据技术等公司的商用软件，对文件109中的服务位置清单进行地址标准化、zip+4编码和纬度及经度地理编码。表4是添加了纬度和经度的一条标准化记录。另外，要使用商用的GIS系统(例如Equifax National DecisionSystems提供的用于Windows的Infomark)对街道地图上画出多边形服务区域的纬度和经度顶点进行数字化。状态606的数字化处理为多边形的顶点分配纬度和经度坐标，并产生如图12b所示的一个多边形文件607。一个示范的多边形文件607如表6所示，带有如下数据项：

            表6地球码：            6194817777名称：              MyPizza Del Mar顶点数：            5纬度/经度顶点对：   33.0170-117.2910

                32.9503-117.2874

                32.9623-117.2132

                33.0187-117.2084

                33.0170-117.2910

最后一个纬度/经度顶点对必须等于第一对，以使多边形闭合。本例是一个非常简单的多边形。典型的经销商多边形都非常复杂；多边形可能会沿着非线性的街道边界，并且包含上百个顶点。地球码是服务位置的电话号码。多边形文件数据被添加到客户服务位置文件109中对应记录的末尾，产生一条可变长度的记录。

处理600转移到状态608，产生每一纬度为68.9404英里的一个常数，并把邮区阵列文件103(图1a)读入计算机内存。在状态610，处理600从客户服务位置文件109中读取一条记录，并计算服务位置处每一经度的英里数。每一经度的英里数=68.9404*COSINE(纬度)。对于表4内给出的实例，在纬度32.9862处，求得每一经度为57.8297英里。

处理600转移到功能612，产生服务位置触及的一个邮区窗口清单。触及一个邮区窗口意味着至少有部分服务区域在该邮区窗口内或覆盖该窗口。图13说明了表4所示实例的示范邮区窗口。下文将结合图14进一步描述功能612。

处理600转移到功能614，产生一个触及功能612识别出的任何一个邮区窗口的5位邮区代码清单。该邮区清单按升序排列，重复的邮区代码在功能614中被删除。下文将根据图16进一步描述功能614。

处理600转移到功能616，从功能614产生的邮区清单中删除不在状态604中指定的多边形服务区域内的5位邮区代码，并产生最终邮区清单。下文将根据图18进一步描述功能616。

处理600转移到功能618，创建如图12b所示的一个线路索引文件619，该文件由定义多边形的离散纬度和经度点组成。下文将根据图19a和19b进一步描述功能618。

处理600转移到功能620，在由功能616生成的最终邮区清单中检索与邮区代码对应的所有zip+4记录，并确定zip+4是否在多边形服务区域之内。如果是，就向一个原始客户表(未示出)写入一条记录，该记录包括zip+4代码、即时服务位置的客户电话号码、以及zip+4重心到服务位置的距离。下文将根据图20进一步描述功能620。

处理600转移到功能622，确定是否还有客户服务记录需要处理。如果有，对下一条服务位置记录重复状态610到620的循环。如果已经为即时原始客户表处理完所有服务位置记录，处理600前进到状态624。在状态624，处理600对通过功能620写入的原始记录进行分类，按照zip+4代码升序排列，如果同一zip+4代码出现多次，则按距离降序排列。如果多个具有不同客户电话号码的服务区域有重叠，同一个zip+4代码可能会出现多次。

然后处理600转移到状态626，其中在状态624经过排序的客户表被加载到电话网交换机111的计算机上，并建立了对zip+4代码的一个索引关键字。状态626一经完成，客户表创建处理600就在状态628结束。

下面参考图14，描述图12a中的功能612。功能612通过首先计算一个位置的纬度和经度端点产生该位置所触及的一个邮区窗口清单。对于这个功能，纬度和经度均采用绝对值。

处理600从起始状态670开始，转移到状态672，确定服务区域的纬度端点。访问多边形文件607，以便提取多边形顶点的纬度最小值和最大值。

Site_lat_min=polygon_lat_min；

Site_lat_max=polygon_lat_max

对于表6给出的示范服务位置和多边形，其结果如下：

Site_lat_min=32.9503；

Site_lat_max=33.0187。

处理继续在状态674确定服务区域的经度端点。多边形顶点的经度最小值和最大值从多边形文件607中提取。

Site_lon_min=polygon_lon_min；

Site_lon_max=polygon_lon_max

对于表6给出的示范服务位置和多边形，其结果如下：

Site_lon_min=117.2084；

Site_lon_max=117.2910。

状态676和678类似于功能182(图5)的状态258和260。正如图14的定义，功能680(图15)类似于功能262(图6)。功能612返回图12a的状态682。

正如图12a的定义，功能614(图14)类似于功能184(图7)。正如图16的定义，功能752(图17)类似于功能322(图8)。正如图12a的定义，功能616(图18)类似于功能186(图9)。

下面参考图19a和19b，描述图12a中定义的功能618。功能618通过将所有修改后的顶点纬度和经度化为整数值来创建线路索引文件619，从而为线路上每个离散点产生一条记录，该线路通过连接多边形文件607中列出的相邻顶点得到。如下所示，对多边形顶点进行的修改是减去site_lat_min或site_lon_min。

处理600从起始状态830开始，转移到状态832，将变量J初始化为值1。转移到状态834，处理600将通过变量J寻址的一个切线(图19中的“T”表示)阵列元素初始化为零。在状态836，在通过J寻址的纬度阵列(图19中的“LAT”表示)元素中写入通过以下计算得出的值：从多边形文件607(从状态606获得)中通过J寻址的顶点纬度(lat_vertices)中减去site_lat_min(从图14中的功能612获得)，将结果乘以10,000，然后取乘积的整数(INT)部分。转移到状态838，在通过J寻址的经度阵列(图19中的“LON”表示)元素中写入通过以下计算得出的值：从多边形文件607(从状态606获得)中通过J寻址的顶点经度(lon_vertices)中减去site_lon_min(从图14中的功能612获得)，将结果乘以10,000，然后取乘积的整数部分。

在判决状态840，处理600确定是否已处理完多边形文件607中的所有顶点。如表6的范例所示，顶点数可从状态606获得。如果没有处理完，变量J在状态842加一，处理600返回状态834，处理下一个顶点。如果已处理完所有顶点，在状态844置变量J等于值二。

状态846到860用于寻找与一条纬线相切的顶点。状态846到854构成一个循环，对LAT阵列的所有元素排序，以确定是否满足判决状态846或850的条件。如果满足，将通过J寻址的切线阵列元素置为一。如果不满足，在状态854令J加一并返回状态846，以处理下一元素，直至到达LAT阵列的末尾，即检查完所有顶点，判决状态852为真。判决状态846确定阵列LAT中正好在当前元素之前和之后的元素值是否大于当前元素值。换句话说，判决状态846确定一条纬线是否与vertex(J)相切。判决状态850确定阵列LAT中正好在当前元素之前和之后的元素值是否小于当前元素值。换句话说，判决状态850确定一条纬线是否与vertex(J)相切。

当J等于顶点数减一时，处理600转移到状态856，通过856和860进行以下测试：

判决状态856：如果LAT(1)＞LAT(2)且LAT(1)＞LAT(number_vertices-1)，则T(J)=l；

判决状态860：如果LAT(1)＜LAT(2)且LAT(1)＜LAT(number_vertices-1)，则T(J)=1。number_vertices用于代表从状态606获得的顶点数。判决状态856到860用于测试先前的状态846到854的一种特例，以便确定vertex(1)是否与一条纬线相切。如果是，把通过J寻址的切线阵列元素置为一。

在状态862，处理600将变量J置为一。模块864是从图19a到图19b的一个页尾连接符。处理600继续从图19b中的模块864开始，产生由连接多边形顶点的离散纬度点构成的一条伪线路。通过一个X、Y坐标来描述定义该线路的每个点。每个Y坐标或纬度点是离开Y轴上的纬度的万分之一。

判决状态866检查平行的纬线，如果为真，处理600转移到判决状态886，以便确定是否已处理完所有顶点。如果否，J在状态888加一，处理返回状态866，以便检查阵列LAT的下一元素。如果判决状态866确定LAT(J)不等于LAT(J+1)，处理600转移到状态868，令变量K等于LAT(J)的值，并转移到状态870。

状态870用于排除纬度切线顶点。状态870确定K是否等于LAT(J)以及T(J)是否等于一。如果是，处理600转移到判决状态882，以便确定是否应该在状态884令K加一，或者是否K已经达到了“LAT(J+1)-1”的值，而执行判决状态886。如果K在状态884加一，处理600返回判决状态870。

如果判决状态870为否，处理600转移到状态872，以便计算变量“delta_lat”从而得到“LAT(J+1)·LAT(J+1)”。在状态874，计算通过J寻址的阵列LON元素和通过J减一寻址的阵列LON元素值之差作为变量“delta_lon”。转移到状态876，把变量“lat_point”置为等于变量K的值。状态878使用以下等式来计算纬线点的一个经度(变量“lon_point”)：

lon_point=INT((K-LAT(J)/delta_lat)*delta_lon+LON(J))。

处理600转移到状态880，向线路索引文件写入lat_point和lon_point的值，然后返回判决状态882，检查K的值。

在判决状态886，如果J等于顶点数减一，表示已处理完所有顶点，处理600转移到状态890。在状态890，处理600按纬度点升序以及在纬度点内按经度点升序对线路索引文件排序。转移到状态894，处理600使用纬度点作为索引关键字创建多边形线路索引文件619。功能618返回图12a的状态894。

下面参考图20，描述图12a中定义的功能620。功能620读取通过zip_final清单和zip_pointer清单确定的所有zip+4记录，并确定zip+4重心是否在多边形服务区域内。

从起始状态910开始，状态912到918类似于功能188(图10)的状态422到428。然后从状态920开始到状态926，处理600比较zip+4重心的纬度和经度与从功能612(图14)获得的位置经度和纬度的最小值及最大值。换句话说，处理600确定zip+4重心是否在多边形服务区域的纬度和经度端点内。如果不在，处理600在状态928跳至下一条zip+4记录，然后返回状态918，读取zip+4记录。

不过，如果通过状态920到926确定zip+4重心在多边形服务区域的纬度和经度端点内，处理600就转移到功能930。功能930是确定zip+4重心是否在多边形内的最终测试。功能930的“点在多边形内”测试返回一个“inside(之内)”或“outside(之外)”的标志。如果zip+4重心不在多边形内，功能930对“outside”标志置位，处理600转移到状态928，以跳至下一条zip+4记录。不过，如果zip+4重心在多边形之内，功能930对“inside”标志置位，处理600转移到状态932，进行距离计算。状态932类似于功能188(图10)的状态430。状态934到940和928类似于功能188的状态434到442。功能620返回图12a的状态942。

下面参考图2l，描述图20中定义的功能930。功能930确定zip+4重心是否在多边形内。功能930在概念上从zip+4纬度按经度的反方向画一条线，然后计算这条线穿过多边形边界的次数。如果这条线穿过的次数是奇数，zip+4重心就在多边形内，但是穿过次数为偶数表示zip+4重心在多边形之外。

处理600从起始状态960开始，转移到状态962，通过以下步骤计算变量“lat”的值：从zip+4_lat(从Zip+4重心文件100中获得)中减去site_lat_min(从图14中的功能612获得)，将结果乘以10,000，然后取乘积的整数(INT)部分。转移到状态964，处理600通过以下步骤计算变量“lon”的值：从zip+4_lon(从Zip+4重心文件100中获得)中减去site_lon_min(从功能612获得)，将结果乘以10,000，然后取乘积的整数部分。

转移到状态966，处理600把变量“count(计数)”初始化为零值，并转移到状态968，访问线路索引文件619。在状态970，处理600读取线路索引文件619(从图19的功能618获得)，提取变量“lat_point”和“lon_point的值”。通过使用文件ISAM索引，处理600在多边形线路索引文件619中跳至“lat”第一次出现的位置。转移到判决状态972，处理600确定“lat_point”是否大于“lat”。如果“lat point”大于“lat”，则已读取完多边形线路索引文件619中的所有记录。如果否，在判决状态974确定“lon_point”是否小于“lon”。如果“lon_point”小于“lon”，定义从zip+4重心向负无穷画的一条线穿过一个多边形。在状态976,“count”加一，表示存在线路交叉，处理600返回状态970。不过，如果判决状态976为否，处理600返回状态970，读取线路索引文件619的下一条记录。

如果处理600在判决状态972确定“lat_point”大于“lat”，处理600转移到判决状态978，检查“count模2”是否等于零。如果是，存在偶数次线路交叉，“outside”标志就被置位，功能930返回图20的状态980。如果判决状态978为否，即“count模2”不等于零，存在奇数次线路交叉，表示zip+4重心在多边形内。处理600对“inside”标志置位，功能930返回图20的状态982。

Ⅶ．单表系统概述

图1b和图1c所示的双表系统(主控表和客户表)的一种派生物是单表系统1000(图27)。单表系统提供了最快地传送电话呼叫方法。因为它建立在单个表的基础上，所以最容易在通信网中实现。

单表系统的实现并不简单，因为脱线维护至关重要，以便与电话号码变动和客户服务位置变动相同步，以及保持电话号码与每个客户服务位置中间的空间关系。由于每个客户对应一个表，每次电话号码变动必须重新与每个客户的服务位置建立联系。每月全国有几百万个电话号码变动。表所产生的变动次数等于电话号码变动数乘以表的总数。在添加或删除服务位置、以及服务位置的服务区域定义或电话号码变动时，这些变动必须重新与可能主叫电话号码清单建立联系，因此也必须更新每个表。另外，系统支持的用户越多，需要的表就越多，这可能产生巨大的容量要求。

在单表系统中，有两种优选方法产生包含在通信网中的电话号码到服务位置电话号码或ID表。这个表一经产生，单表系统就只需要对一种集中存储区(例如磁盘)进行查找操作，以便确定所要服务位置的电话号码，从而提供了最快速的呼叫传送实施例。

单表系统中创建主叫电话号码到经销商电话号码表的第一种方法是对上述客户表创建处理的一种改进。下文将根据图22进一步描述建立该表所用的文件和处理。

单表系统中创建主叫电话号码到经销商电话号码表的第二种方法使用脱线处理合并双表系统中主控表和客户表的记录。下文将根据图23大致描述该处理。创建主控表清单功能和创建客户表清单功能都参考图24进行描述，通常它们分别指1050和1052，并各自根据图25和26作进一步讨论。

从上述两种表创建方法中的任何一种得到的主叫电话号码到经销商电话号码表在电话网中被用于单表系统。单表系统及其网络配置参考图27进行描述，它总体上指1000。对单表系统所用的硬件组成、表和文件的更详细描述根据图27进行。对单表系统操作流程的描述参考图28进行，它总体上指1160。

Ⅷ．单表系统表创建处理

以下描述解释了两种自动生成和保持可包含在通讯网中的电话号码到服务位置电话号码或ID表的方法。这些创建一个单表系统的方法所用的技术与创建双表系统使用的技术在某些部分类似。

客户表创建特例

要描述的第一种创建主叫电话号码到经销商电话号码表的方法是以上根据双表系统描述的客户表创建处理的一种特例。对这一新处理的描述参考图22进行，它总体上指1002。正如以上根据双表系统进行的描述，处理1002从一个Zip+4重心文件开始。这个Zip+4是美国的优选空间关键字。通过用Zip+4替代lO位电话号码作为我们的空间关键字，产生一个10位电话号码纬度和经度重心文件1010。使用文件1010以及电话阵列文件1016、电话窗口文件1018作为到客户表创建处理1020的输入，最终结果是一个以主叫电话号码到服务位置电话号码表1022形式出现的客户表。客户表创建处理1020类似于客户表创建处理105(图1a，并根据图3和图12a作过进一步描述)，只是正如这里指出的那样，用作处理1020输入的文件名和字段名不同。下面将要描述的其他两种文件创建处理1012和1014也要使用文件1010。

起始电话号码纬度和经度重心文件1010通过以下数据和工具生成：带有地址的一个电话号码主控清单、Zip+4地址标准化和编码软件，例如可从GROUP 1软件公司获得的AccuMail^或CODE-1^，以及纬度和经度编码软件，例如可从地理数据技术公司(GDT)获得的MatchMaker/2000^。用于创建电话号码纬度和经度重心文件的优选处理是如下文描述的两步处理。

从电话号码地址文件开始，步骤一使用GROUP 1的USPS地址标准化AccuMail或CODE-1软件处理文件，对地址进行标准化，并为文件中的每个地址分配一个Zip+4。如果文件生成处理在一台个人计算机或其他小型机上运行，就使用AccuMail软件；或者如果处理在主计算机或其他大型机上执行，就使用CODE-1软件。在步骤二，使用GDT的MatchMaker/2000软件处理经过地址标准化和Zip+4编码得到的文件。对于每条记录，软件首先在GDT的Dynamap/2000^街道地址数据库中寻找该地址。如果找到当前记录的地址，向该记录分配一个街道号码纬度和经度。如果没有找到该地址，为该记录分配一个来自GDT的Zip+4纬度和经度重心文件100(图la)的纬度和经度。

电话阵列文件创建处理1012类似于邮区阵列文件创建处理101(图1a)，只是所得电话阵列文件1016用一个六位(NPANXX)电话号码字段代替了邮区阵列文件103中的5位邮区代码字段。因此，文件1016中有999,999条可能记录，但没有全部使用，因为并不是每个区号的数字组合当前都已被分配。另外，纬度/经度最小值和最大值用于由文件1016中电话号码前六位定义的区域，而不是文件103中的5位邮区代码区域。

电话窗口文件创建处理1014类似于邮区窗口文件创建处理102(图1a)，只是所得电话窗口文件1018用一个六位(NPANXX)电话号码字段代替了邮区窗口文件104中的5位邮区代码字段。脱线合并处理

参考图23，用于创建主叫电话号码到服务位置电话号码表的第二种方法涉及脱线合并来自主控表107和客户表106的记录。主控表107和客户表106根据前面结合双表系统描述的方式生成。如图23所示，主控表107和客户表106通过状态1030和1034，各自按ZIP+4升序独立排序，以分别生成排序后的主控表1032和排序后的客户表1036。这两种排序表1032和1036通过一个匹配处理1040合并，以生成主叫电话号码到服务位置电话号码表1022’。对于主控表中的每条ZIP+4记录，正如下文结合图24对处理1040进行的详细描述，匹配处理1040最好在客户表中寻找匹配的ZIP+4记录。电话号码到电话号码表1022’与原始的客户表106在结构上仍然相似，但是有更多的记录，并用电话号码代替了ZIP+4。

现在参考图24，描述图23中指定的匹配和增补(或合并)处理1040。处理1040从状态1042开始，转移到状态1044，在此初始化主控表和客户表文件结束变量MT_EOF和CT_EOF为零。然后处理1040转移到状态1046，在此读取包含主控表电话号码(MTPHONE)和主控表空间关键字(MTSK)的第一条主控表记录。然后处理1040转移到状态1048，在此读取包含客户表空间关键字(CTSK)和客户表电话号码(CTPHONE)的第一条客户表记录。

然后处理1040调用功能MTLIST_BUILD 1050，创建一个具有当前空间关键字的所有主控表记录内存驻留清单。下文将根据图25更详细地描述功能1050。功能1050一旦完成，处理1040就调用功能CTLIST_BUILD 1052，创建一个具有当前空间关键字的所有客户表记录内存驻留清单。下文将根据图26更详细地描述功能1052。功能1052一旦完成，处理1040就转移到判决状态1054，并比较主控表清单中的第一空间关键字(MTL_LIST(1))和客户表清单中的第一空间关键字(CTL_LIST(1))。这种比较有三种可能的结果：

(1)客户表空间关键字大于主控表空间关键字；

(2)主控表空间关键字大于客户表空间关键字；或者

(3)主控表空间关键字与客户表空间关键字相等。

三种可能结果如下所述：

(1)当判决状态1054确定客户表空间关键字大于主控表空间关键字时，处理1040转移到状态1056。如果主控表文件结束条件MT_EOF等于一，即合并处理已完成，合并处理在状态1060结束。如果主控表文件结束条件MT_EOF不等于一，处理1040调用功能MTLIST_BUILD1050(根据图25有更详细的描述)，更新主控表清单，然后返回判决状态1054。

(2)当判决状态1054确定主控表空间关键字大于客户表空间关键字时，处理1040转移到判决状态1062。如果客户表文件结束条件CT_EOF等于一，即合并处理已完成，合并处理在状态1066结束。如果客户表文件结束条件CT_EOF不等于一，处理1040调用功能CTLIST_BUILD_1052(根据图26有更详细的描述)，更新客户表清单，然后返回判决状态1054。

(3)当判决状态1054确定主控表空间关键字与客户表空间关键字相等时，处理1040执行写电话号码到电话号码记录的功能1068。功能1068向电话到电话表1022’写J乘以K条记录，其中J的值从功能1050(图25)中获得，K的值从功能1052(图26)中获得。功能1068按以下方式进行这一操作：通过在用于主控表清单的一个1=1到J的循环内嵌套一个用于客户表清单的L=1到K的循环，写入每条MTL PHONE(1)和CTL_PHONE(L)记录组合。完成功能1068之后，处理1040转移到前面描述过的功能1050，更新主控表清单。然后处理在1040执行功能1052，更新客户表清单。更新完主控表清单和客户表清单之后，处理1040返回判决状态1054，继续合并处理。

现在参考图25，描述图24指定的主控表创建功能1050。功能1050从状态1080开始，转移到状态1082，将变量J置为一。然后，功能1050转移到状态1084，把当前的主控表记录空间关键字(MTSK)和主控表电话号码(MTPHONE)移动到对应的元素：内存驻留主控表清单第J行的MTL_SK(J)和MTL_PHONE(J)中。

然后，功能1050转移到状态1086，读取包含主控表电话号码(MTPHONE)和主控表空间关键字(MTSK)的下一条主控表记录。之后，功能1050转移到判决状态1088，确定是否满足主控表文件结束的条件。如果满足文件结束条件，功能1050在状态1090把主控表文件结束变量MT_EOF置为一，并在状态1092把控制返回给处理1040的功能1052(图24)。如果判决状态1088确定没有满足文件结束条件，功能1050转移到判决状态1094。在判决状态1094，功能1050比较当前的主控表空间关键字值(MTSK)与主控表清单中的第一空间关键字(MTL_LIST(1))，以确定两个空间关键字是否相等。如果它们不等，功能1050在状态1092把控制返回给处理1040(图24)。如果两个空间关键字相等，功能1050在状态1096令J的值加一，并返回前面描述的状态1084。

现在参考图26，描述图24中指定的客户表清单创建功能1052。功能CTLIST_BUILD 1052对客户表进行的处理与功能1050(图25)对主控表的处理相同。功能1052在状态1102处开始，并转到状态1104，在此，变量K被设置为1。然后功能1052转移到状态1106，把当前的客户表记录空间关键字(CTSK)和客户表电话号码(CTPHONE)移动到对应的元素：内存驻留客户表清单第K行的CTL_SK(K)和CTL_PHONE(K)中。然后，功能1052转移到状态1108，读取包含客户表电话号码(CTPHONE)和客户表空间关键字(CTSK)的下一条客户表记录。

然后，功能1052转移到判决状态1110，确定是否满足客户表文件结束的条件。如果满足文件结束条件，功能1052在状态1112把客户表文件结束变量CT_EOF置为一，并在状态1114把控制返回给处理1040(图24)。如果判决状态1110确定没有满足文件结束条件，功能1052转移到判决状态1116。在判决状态1116，功能1052比较当前的客户表空间关键字值(CTSK)与客户表清单中的第一空间关键字(CTL_LIST(1))，以确定两个空间关键字是否相等。如果它们不等，功能1052在状态1114把控制返回给处理1040(图24)。如果两个空间关键字相等，功能1052在状态1096令K的值加一，并返回前面描述的状态1106。

Ⅸ．用于单表系统的计算机-电话集成(CTI)网络配置

下面参考图27，描述用于单表系统100的一种优选CTI网络配置。网络配置使用根据图22或23描述的表。从主叫电话110发起的一次电话呼叫首先由本地交换服务商(LEC)，例如靠近主叫的Pacific Bell或Southwest Bell的一台交换机进行处理。LEC处的交换机指定一个独立于所用电话类型的自动号码标识(ANI)。主叫ID技术提供了另一种获取主叫号码的方法，但是这一技术目前在可用性方面受到政府管制，在某些情况下被禁用。根据AT&T统计，所有交换机中的98％目前指定和传送一个10位ANI。然后，呼叫、ANI和所拨的号码标识业务(DNIS)号码通过一个国内长途网络服务商，例如AT&T、MCI或Sprint传送给一个长途网络(LDN)终接交换机111。LDN终接交换机111可以与为终接位置服务的LEC处的另一台交换机连接，或者它也可以是直接与一个呼叫处理中心接口点1130相连的交换机，例如一台AT&TMEGACOM 800交换机或AT&T MULTIQuest 900交换机。在这种计算机电话集成网中的优选实施方案是直接连接使用AT&T MEGACOM 800业务的AT&T长途网，该业务使用一台AT&T 4 ESS数字交换机111。

终接交换机111向网络和呼叫中心之间的接口盒1130传送ANI和DNIS。接口盒最好是一个VRU或交互式语音响应单元(IVRU)，例如一个AT&T会话系统，以及提供CTI的网络集线器。另一种实施例使用不带有话音/语音特性的接口盒1130。接口盒1130能够通过以下处理控制呼叫处理：接收来自电话网交换机111的语音信号、ANI和DNIS；向主叫播放录制的话音信息；接收主叫DTMF键盘输入；把主叫话音输入和命令，例如“1”、“2”、“3”、“A”、“B”、“C”、“Yes”和“No”，转换成计算机数据代码；把计算机文本转换为合成语音，并向主叫播放合成语音。接口盒1130还通过一个局域网(LAN)1132上的通信协议，例如ISDN和TCP/IP，与其他电话和计算机网络系统通信，以获取处理呼叫所需的其他信息。接口盒1130可以把主叫连接到一个服务位置电话上，例如服务位置150a处，或者使用高级网络特性，例如AT＆T的传送连接，连接主叫与服务位置。LAN1132使用双线，以提供冗余。

接口盒1130首先与结构化查询语言(SQL)数据库服务器1134通信，以更新、验证和确定主叫提供的电话号码类型。电话号码类型指它是一个美国POTS电话号码还是可能对应一部寻呼机、蜂窝电话或个人通信业务(PCS)电话的非POTS号码，非美国号码则可能是一个加拿大电话号码。主叫提供的电话号码是正常的主叫始发呼叫产生的(ANI或主叫ID)，或主叫提供一个替代电话号码的状态118(图28)产生的。优选的SQL服务器软件提供商是Oracle公司。优选服务器是AT&T 3600UNIX主机。其他实施例也可以使用其他服务器或数据库软件类型。

数据库服务器1134有两个数据库提供更新、验证和对电话号码分类的信息。第一个是Bellcore NPANXX分裂文件。“NPANXX”代表十位电话号码的前六位，对应一个区号和一个电话局。文件1136提供了一个正在进行新区号和局号分裂处理的NPANXX清单。如果主叫提供的NPANXX在该清单中，而且当前日期落在与从文件中提取的分裂有关的日期范围内，就根据分裂文件1136中的数据更新主叫提供的电话号码。之后，比较主叫的NPANXX与Bellcore的V&H坐标文件1138，后者列出了所有合法的NPANXX和NPANXX支持的业务类型。NPANXX分裂文件1136和V&H坐标文件1138都是从Bellcore的本地交换局选路指南(LERG)中提取的。LERG是在北美拨号方案通信网中传送呼叫的所有公共服务商使用的主控数据库。如果主叫提供的NPANXX在V&H文件1138中作为一个美国普通老式电话业务号码(POTS)列出，就返回主叫的时区和夏令时标志。另一方面，如果主叫的NPANXX非法，接口盒1130就请求主叫提供另一个电话号码。如果NPANXX是合法的非美国号码，或专用电话号码，例如“NPA_555”，就将为主叫播放与主叫电话类型有关的预录消息，并请求主叫输入另一个电话号码或连接主叫与异常呼叫处理操作员1146。

如果确定主叫的NPANXX是一个合法的美国POTS号码，接口盒1130就向传送处理器1150(也被称为传送计算机)发送一条包含主叫提供的电话号码和DNIS的进程间通信请求。在一个实施例中，传送处理器1150是一台基于UNIX的计算机，例如AT&T 3600，它可以访问与DNIS对应的电话号码到电话号码表1022。在其他实施例中也可以使用其他计算机。传送处理器1150从客户电话号码到电话号码表中提取与主叫提供的电话号码相关的数据并返回一个状态码，如果成功，还要返回服务位置电话号码或ID的一个清单。如果返回的状态码是一种不成功的类型，接口盒1130则向主叫播放一条预录消息或连接主叫与异常呼叫操作员1146。

如果传送处理器请求成功返回，接口盒1130就向数据库服务器1134发出请求，该服务器对与主叫DNIS联系的客户服务位置表1140执行数据库访问功能，并提取由传送处理器1150返回的关于服务位置ID的记录。表1140是客户服务位置表109(图22)的索引和在线形式。提取的这些记录包含服务位置电话号码、营业日期和小时、名称、地址和微区域方向、时区、夏令时标志等等。然后，接口盒1130确定哪个服务位置可以处理主叫的请求。依客户应用而定，接口盒1130通过录制的话音或合成的文本到语音，向主叫提供服务位置信息和/或直接连接主叫与最近或当前营业的所选服务位置。

如果主叫需要操作员的异常处理，接口盒1130使用一个图象显示器，通过一台CTI专用小交换机(PBX)自动呼叫分配器(ACD)1142和主机系统1144，连接主叫与操作员1146。PBX/ACD 1142，例如AT&T的系统75，向操作员1146提供主叫话音。主机系统最好是一个IBM的3090主计算机。主机系统1144在操作者的视频显示器上提供来自服务器1134的数据库数据。Jacksonville,FL的AT&T AmericanTranstech支持主机系统1144。操作员1146处理该请求，并向一个正在服务的经销商传送连接主叫需要的信息，或通过接口盒1130返回的预录消息终止呼叫。

有两种方式连接主叫与正在服务的经销商。接口盒1130可以产生从接口盒1130到服务位置，例如位置150a的第二个呼叫，并通过接口盒1130连接主叫与服务位置。另外一种方式是，接口盒1130可以使用AT&T提供的高级网络特性“传送连接”，直接向正在服务的经销商传送呼叫。后者是优选的实施方案，因为它降低了通信成本和对接口盒端口的容量要求。

服务位置使用传统电话150a或其他电话呼叫接收装置应答呼叫。然后服务位置就可以处理主叫的请求。

Ⅹ．单表系统实例

下面参考图28(结合图27)，描述呼叫进程处理1160。单表系统1000执行呼叫进程处理1160流程图所示的流程。该处理通过使用单个选路表，向客户的目的服务位置传送主叫的电话呼叫。处理1160使用根据图27描述的单表系统1000的网络配置。

处理1160从主叫使用一部传统电话110拨打一个“800”类型的电话号码。该呼叫最好通过国内通信网向应答呼叫的呼叫处理中心处的一个网络接口盒1130(图27)传送。网络接口盒1130的呼叫译码模块或单元112对网络信息分组114进行译码，该分组包含ANI提供的主叫电话号码和所拨号码，即DNIS号码。

然后，处理1160转移到判决状态116，确定呼叫应用是否提供可选的主叫输入。如果没有，处理1160转移到判决状态1162。但是，如果判决状态116确定呼叫应用提供了可选的主叫输入，处理1160转移到状态118，主叫提供另一个人或公司的电话号码，该号码对应的位置通常不同于ANI对应的位置。这个电话号码也可以是主叫的家庭电话号码，例如当主叫在家门外的一个位置进行呼叫时。新电话号码的输入可以通过主叫使用按键式电话上的DTMF键盘、通过计算机或其他可以产生按键音的设备、或者通过向接口盒1130(图27)传递语音信息来实现。状态118还要根据Bellcore NPANXX分裂文件1136(图27)与合法电话号码文件1138检查主叫提供的电话号码，并在主叫提供的号码非法时提示主叫输入另一个电话号码。

一旦确定输入电话号码非法，或者主叫经过客户指定次数的输入后产生的号码仍然是非法的，处理转移到判决状态1162。在判决状态1162，处理1160确定主叫电话号码或主叫提供的电话号码是否是一个合法的美国POTS号码。如果不是，正如前面根据图1c在状态128所作的描述，处理1160转移到用于不可传送呼叫异常处理的状态128。如果判决状态1162确定主叫提供的电话号码是一个合法的美国POTS号码，处理转移到状态1164，其中主叫提供的电话号码作为与主叫DNIS对应的电话号码到电话号码表1022的索引。

转移到判决状态1166，处理1160确定是否找到主叫的电话号码。如果没有找到，处理1160转移到如上所述、用于不可传送呼叫异常处理的状态128。如果找到主叫提供的电话号码，提取对应的电话号码记录，处理1160转移到判决状态1168，确定提取的记录是否包含一个服务位置电话号码。如果没有服务位置电话号码存在，正如前面根据图1c在状态144所作的描述，处理1160转移到被传送呼叫异常处理状态144。

如果判决状态1168确定存在一个服务位置电话号码，处理1160在状态146提取客户本地服务位置的电话号码，并转移到状态148，拨打所提取的服务位置电话号码。状态148所用的出局呼叫模块或硬件可以是网络终接点接口盒1130(图27)的一个部分。如果判决状态152确定所拨号码占线或没有应答，呼叫就被传送到如上所述的被传送呼叫异常处理状态144。如果呼叫没有遇到占线并且有应答，主叫与服务位置150连接，服务位置处理主叫的请求。

Ⅺ．实时处理系统概述

在应用中，当高呼叫量和事务处理速度不再是问题，不需要链接其他空间关键字编码的数据库，以及/或磁盘存储资源有限时，客户可以选择在呼叫处理期间进行计算，以便实现主叫提供的电话号码所对应的精确位置与具有任意大小或形状定义的服务位置之间的映射。进行实时主叫提供的电话号码与服务位置映射所需要的主要单元和技术已在前面根据双表系统作过描述。在实时处理配置中修改这些技术能进一步提高实时映射处理的效率。以下描述解释的实时处理需要一个主控10位电话号码到纬度和经度重心文件1010(图29)和客户服务位置文件109。客户服务位置的服务区域，即文件109每条记录的一个部分，被描述为具有半径定义服务区域的一个精确纬度和经度服务位置地址，或通过一个纬度和经度顶点集定义的服务区域多边形。

在用于半径和多边形客户表的双表系统客户表创建处理中，系统逐个读取服务区域清单，确定哪些ZIP+4在每个服务区域内，计算从每个ZIP+4到服务位置的距离，为每个包含ZIP+4的位置向文件写入一条记录，并根据ZIP+4及距离降序对文件排序和索引。

下面将参考图29，描述实时处理系统1200(图30)中需要的文件和处理。实时处理模块1220在系统1200(图30)传送处理器集(图30)中的一个上执行，以实时传送一次电话呼叫。除了主控10位电话号码到纬度和经度重心文件1010和客户服务位置文件109之外，实时处理模块1220还要使用客户服务区域阵列文件1214、客户服务区域窗口文件1216和主叫或主叫提供的带有一个DNIS 1218的电话号码。模块1220的输出是一个排序后的服务位置电话号码或ID清单1222。下文将根据图35更详细地描述模块1220。

主控10位电话号码到纬度和经度重心文件1010和客户服务位置文件109前面已根据单表系统作过描述。正如下面的解释，创建客户服务区域阵列文件1214和客户服务区域窗口文件1216使用了客户服务位置文件109中半径和多边形服务区域的纬度/经度端点。

具体来说，客户服务区域窗口文件1216由使用客户服务位置文件109的脱线服务区域窗口文件创建处理1212产生。下文将根据图31更详细地描述处理1212。

客户服务区域阵列文件1214由使用客户服务位置文件109的脱线服务区域文件创建处理1210产生。服务区域文件创建处理1210类似于邮区阵列文件创建处理101(图1a)和电话阵列文件创建处理1012(图22)，只是产生的客户服务区域阵列文件1214用一个客户服务位置ID字段取代了邮区阵列文件103中的5位邮区代码字段或电话阵列文件1016的六位(NPANXX)电话号码。文件1214的字节偏移字段包含到客户服务位置文件109排序后形式(图30，表1140)的偏移，而不是到重心文件100(图1a)或重心文件1010(图22)的偏移。而且，纬度/经度最小值和最大值用于客户服务区域，而不是文件103的5位邮区代码区域或文件1016中前6位电话号码定义的区域。客户服务区域阵列文件1214用于删除这样的服务位置：其纬度和经度服务区域端点不包括主叫提供的电话号码位置的纬度和经度。因为文件1214只包含通过下文描述的处理1212也能生成的一个字节偏移索引和纬度及经度端点，所以不再更详细地描述处理1210。

在实时处理中，系统执行实时“呼叫处理期间”模块1220，该模块创建一个带有电话号码的服务位置清单，其服务区域包括主叫提供的电话号码位置。下文将参考图35更详细地描述这一实时处理1220。实时处理1220通过从主控电话号码到纬度和经度表1010中提取主叫提供的电话号码记录，以便确定与主叫提供的电话号码对应的位置纬度/经度。根据这个纬度和经度以及与DNIS相关的客户服务区域窗口文件1216，实时处理1220在空间上确定可能为主叫位置服务的客户位置清单。下文将参考图35描述这一清单确定步骤(它总体上指1344和1346)，并根据图36作更详细的讨论。

然后，实时处理1220对清单中的每个可能位置进行详细的空间测试，以确定主叫的纬度/经度是否在服务位置的服务区域内。如果在内，系统计算从主叫到该服务位置的距离，并将其添加入服务位置清单。下文将参考图35描述详细的空间测试和距离确定步骤(它总体上指1348)，并根据图37和38作更详细的讨论。处理完所有可能位置之后，根据距离升序存储服务位置清单，并回送给呼叫处理应用任务流，以用于传送电话呼叫。

与双表系统类似，正如双表系统客户表创建处理中的描述，实时处理同时支持多边形和半径服务区域。对于实时处理，半径和多边形“服务区域内”处理是同一个呼叫处理内核系统的一部分，但是每种处理需要各自的底层功能(图38)来确定主叫位置是在服务位置的半径或多边形定义服务区域之内还是之外。

在几种实施例中，实时处理系统是更新最简单的，而且需要的存储量最少。主叫提供的电话号码与客户服务位置的空间关系在呼叫期间确定。带有纬度和经度的电话号码主控表以及每个客户服务位置文件可以独立保存，并驻留在不同的机器上。

Ⅻ．用于实时处理系统的计算机-电话集成网络配置

下面参考图30，描述实时确定系统的网络配置。这种网络配置和呼叫处理逻辑类似于图27用于单表系统的配置，只是由传送处理器1150访问处理逻辑和数据库。为了避免重复，只讨论不同点。在图30中，传送处理器从接口盒1130接收主叫提供的电话号码和DNIS作为输入，并返回一个处理状态码，如果成功，还要返回一个与DNIS对应的服务位置清单，其服务区域包括主叫提供的电话号码位置。

在执行这一功能的时候，传送处理器1150(图30)首先在主控电话号码到纬度和经度表1010中查找主叫提供的电话号码。如果没有找到该电话号码，状态码被置为与“不成功，电话号码不在主控表中”对应的值，而且该信息被返回给接口盒1130。另一方面，如果找到电话号码，就从表1010中提取纬度和经度。

然后，处理器1150通过以下等式把提取的纬度和经度转换成一个lat/lon(纬度和经度)窗口：Lat/Lon窗口=((主叫位置纬度乘以十)的整数部分)乘以10,000再加上((主叫位置经度乘以十)的整数部分)。然后，处理器1150在与主叫DNIS对应的服务区域窗口文件1216中查找这个lat/lon窗口。如果没有找到lat/lon窗口，状态码被置为与“不成功，没有找到lat/lon窗口”对应的值，而且该信息被返回给接口盒1130。如果找到lat/lon窗口，就返回一个可能服务位置ID或电话号码清单。

对于可能清单中的每个服务位置ID或电话号码，处理器1150在与主叫DNIS对应的服务区域阵列文件1214中查找该ID，并提取服务区域的纬度和经度端点以及指示服务位置表109中服务位置记录起点的字节偏移。然后，处理器1150确定与主叫提供的电话号码对应的位置纬度和经度是否处于当前被测试的服务区域纬度和经度端点之内。如果不是，处理器1150转向可能清单中的下一条记录。否则，主叫提供的电话号码的纬度和经度处于当前被测试的服务区域之内，处理器1150就从与主叫DNIS对应的客户服务位置表1140中提取详细的服务区域定义。通过使用软件选择器(例如处理器1150上的一个选择语句或查值表)，从用于多个DNIS和/或客户的一组客户服务位置表中选出与主叫所拨DNIS对应的正确客户服务位置表1140。表1140是客户服务位置表109的索引或在线形式。处理器1150根据与提取的详细记录对应的服务区域类型(即半径或多边形)，进行合适的底层功能调用，以确定主叫提供的电话号码位置是否在当前测试的服务区域内。如果不在，处理器1150转向可能清单中的下一条记录。如果该位置在服务区域内，处理1150计算从主叫位置到服务位置的距离，在“服务区域内”清单中添加该记录，并转向可能清单中的下一条记录。

处理完在可能的清单中的所有记录之后，处理器1150确定“服务区域内”清单是否为空，即不包含任何记录。如果清单为空，就将状态码的值设置成与消息“不成功，服务区域内清单中没有记录”相对应，并向接口盒1130返回该信息。如果“服务区域内”清单包含记录，按距离降序对该清单排序，置状态码的值与“成功”相对应，并向接口盒1130返回该信息，该信息在接口盒中被处理的方式与图27中对单表系统进行的描述相同。

ⅩⅢ．实时处理：创建服务区域窗口文件的脱线处理

图31-34描述了创建客户服务区域窗口文件1216的处理1212。该文件包含一个索引的纬度和经度窗口清单，该清单包括每个纬度和经度窗口和服务位置的组合，其中该位置的服务区可能覆盖该纬度和经度窗口的一条记录。文件1216用于通过查找纬度和经度窗口等于主叫提供的电话号码窗口的记录，迅速确定一个覆盖主叫提供的电话号码位置的可能服务位置清单。客户服务区域阵列文件1214用于删除以下服务位置：其纬度和经度服务区域端点不包含与主叫提供的电话号码对应的纬度和经度位置。

图31是对客户服务区域窗口文件创建处理1212的一般描述。处理1212从起始状态1240开始，转移到状态1242，从客户服务位置文件109中读取一条记录。转移到判决状态1244，处理1212检查文件结束条件。如果文件结束条件是“yes(是)”，即已读取完文件109中的所有记录，处理1212转移到状态1258，完成该处理。如果文件结束条件是“no(否)”，即还没有读取和处理完文件109中的所有记录，处理1212在判决状态1246进行一次测试，以确定刚从文件109中读取的记录是一个半径还是多边形定义服务区域。文件109有一个指示服务区域类型的字段。

如果判决状态1246确定服务区域类型是半径，处理1212转移到状态1248，计算在当前服务位置的纬度处每一经度的英里数。每一纬度是68.9404英里。每一经度的英里数是纬度的函数，并通过下式确定：每一经度的英里数=68.9404*COSINE(纬度)。进行完这一计算之后，处理1212调用功能1250，以确定半径型服务区域的纬度和经度最小值及最大值。下文将根据图32更详细地描述功能1250。

如果判决状态1246确定服务区域类型是多边形，处理1212转向调用功能1252。功能1252确定用于多边形类型服务区域的纬度和经度最小值及最大值。下文将根据图33更详细地描述功能1252。

完成用于半径服务区域的功能1250或多边形服务区域的功能1252之后，处理1212继续执行写服务区域窗口记录功能1254。写服务区域窗口记录功能1254在原始服务窗口文件1256中生成一条记录。下文将根据图34更详细地描述功能1254。完成功能1254之后，处理1212返回状态1242，读取客户服务位置文件109中的下一条记录。

回到判决状态1244，满足文件结束条件之后，处理1212转移到状态1258。在状态1258，根据lat/lon(纬度/经度)窗口和lat/lon窗口内的位置ID按升序对原始服务窗口文件1256进行排序和索引。排序和索引结果被写入客户服务区域窗口文件1216，并且从而处理1212完成。

现在参考图32，描述用于半径类型服务区域的计算纬度和经度最小值及最大值功能1250。功能1250从起始状态1270开始，转移到状态1272，计算当前位置的服务区域纬度最小值和最大值。当前服务区域的最小纬度等于当前位置的纬度减去英里为单位的服务区域半径除以每一纬度的英里数。当前服务区域的最大纬度等于当前位置的纬度加上英里为单位的服务区域半径除以每一纬度的英里数。功能1250转移到状态1274，计算当前位置的服务区域经度最小值和最大值。当前服务区域的最小经度等于当前位置的经度减去英里为单位的服务区域半径除以每一经度的英里数。当前服务区域的最大经度等于当前位置的经度加上英里为单位的服务区域半径除以每一经度的英里数。

之后，功能1250转移到状态1276，创建与服务位置及其服务区域对应的lat/lon窗口的最小和最大纬度分量。最小纬度窗口分量等于十倍服务区域纬度最小值的整数部分，其中纬度用度和度的小数部分表示。最大纬度窗口分量等于十倍服务区域纬度最大值的整数部分，其中纬度用度和度的小数部分表示。功能1250转移到状态1278，创建与服务位置及其服务区域对应的lat/lon窗口的最小和最大经度分量。创建窗口经度端点的程序与创建纬度端点的程序完全一致，只是经度值取代了纬度值。完成状态1278之后，功能1250转移到返回状态1280，返回处理1212的功能1254(图31)。

现在参考图33，描述用于多边形服务区域的计算纬度和经度最小值及最大值功能1252。功能1252从起始状态1290开始，转移到状态1292，确定当前位置的服务区域纬度最小值和最大值。当前服务区域的最小和最大纬度等于当前位置的服务区域最小和最大纬度，后者是从服务位置文件109(图29、31)中用于多边形服务区域的一个多边形文件头中读取的。转移到状态1294，功能1250确定当前位置的服务区域经度最小值和最大值。同样，该信息从文件109的多边形文件头部分获得。

之后，功能1252转移到状态1296，创建与服务位置及其服务区域对应的lat/lon窗口的最小和最大纬度分量。最小纬度窗口分量等于十倍服务区域纬度最小值的整数部分，其中纬度用度和度的小数部分表示。最大纬度窗口分量等于十倍服务区域纬度最大值的整数部分，其中纬度用度和度的小数部分表示。转移到状态1298，功能1250创建与服务位置及其服务区域对应的lat/lon窗口的最小和最大经度分量。创建窗口经度端点的程序与创建纬度端点的程序完全一致，只是经度值取代了纬度值。完成状态1298之后，功能1252转移到返回状态1300，返回处理1212的功能1254(图31)。

现在参考图34，描述生成服务区域文件记录功能1254。功能1254使用功能1250(用于半径服务区域)或功能1252(用于多边形服务区域)生成一个服务区域窗口记录集，并把它们写入原始服务区域窗口文件1256(图31)。功能1254用到内外嵌套的两个循环，内循环从服务区域的最小经度窗口值移动到最大经度窗口值，该最大经度窗口值被嵌套在该外循环内，外循环从服务区域的最小纬度窗口值移动到最大纬度窗口值。

功能1254从起始状态1310开始，转移到状态1312，在此，置变量J的值等于当前服务区域的最小纬度窗口值。功能1254转移到状态1314，在此，置变量K的值等于当前服务区域的最小经度窗口值。转移到状态1316，功能1254通过令J的值与10,000相乘再加上K的值，从而生成一条窗口记录。之后，功能1254转移到状态1318，在原始服务区域窗口文件1256(图31)中写入这条窗口记录。

然后，功能1254转移到判决状态1320，测试并确定K的值是否等于当前位置服务区域的最大经度窗口分量值。如果值不等，功能1254在状态1322令K的值加一，并返回状态1316，生成另一条记录。如果判决状态1320确定值相等，功能1254继续转移到判决状态1324。在判决状态1324，功能1254比较J的值与当前位置服务区域的最大纬度窗口分量值。如果值不等，J的值在状态1326加一，功能1254返回状态1314，以开始一个新的外循环纬度值。如果判决状态1324确定值相等，功能1254转移到返回状态1328，并返回处理1212的状态1242(图31)。

ⅩⅣ．实时处理：创建服务位置清单的“呼叫期间处理”，其服务区域包括主叫提供的电话号码位置

图35-38描述了创建一个服务位置清单的“呼叫期间处理”1220，其服务区域包括主叫提供的电话号码位置。系统1200(图30)执行处理1220流程图所示的处理流程。图35提供了对处理1220的一般描述，该处理先前在图29中介绍过。

现在参考图35，处理1220从起始状态1340开始，转移到状态1342，通过内存访问主叫提供的电话号码、DNIS以及主叫提供的电话号码位置的纬度和经度。纬度和经度通过在主控电话号码到纬度和经度表1010(图29)中查找主叫提供的电话号码获得。转移到状态1344，处理1220使用来自状态1342的纬度和经度，并确定包含主叫提供的电话号码位置的lat/lon(纬度和经度)窗口。该窗口使用下式确定：Lat/Lon窗口=主叫纬度乘以10的整数部分的10,000倍加上主叫经度乘以10的整数部分。例如，在40度的纬度上，lat/lon窗口由长宽约为6.9英里和5.2英里的一个X、Y矩形代表。然后，处理1220动用功能1346，建立初始的可能服务位置清单，其服务区域可能覆盖主叫提供的电话号码的lat/lon窗口。下文将根据图36更详细地描述功能1346。

完成功能1346之后，处理1220继续在功能1348上处理可能服务位置清单中的所有服务位置记录，并确定其服务区域是否覆盖主叫提供的电话号码位置。下文将根据图37更详细地描述功能1348。功能1348一经完成，处理1220继续转移到状态1349，如果K的值为2或更大，就按距离降序对最终服务位置清单排序。K的值在功能1348(图37)中确定，它代表在服务区域包括主叫提供的电话号码位置的最终清单中的最终服务位置数目。如果K的值为零，处理1220产生一个标志，指示没有服务区域包括主叫提供的电话号码位置的位置存在。当然，如果K的值为一，就不需要排序。最后，清单创建处理1220在状态1350结束。

现在参考图36，描述原始服务区域清单功能1346。功能1346从起始状态1351开始，转移到状态1352，打开与主叫DNIS对应的客户服务区域(lat/lon)窗口文件1216，并存储主叫提供的电话号码的lat/lon窗口(来自图35的状态1344)。然后，功能1346转移到状态1353，置K的值为一。转移到状态1354，功能1346跳至打开的客户服务区域窗口文件1216中lat/lon窗口值等于主叫提供的电话号码lat/lon窗口值的第一条记录起点。

功能1346继续转移到状态1355，从客户服务区域(lat/lon)窗口文件1216中读取一条lat/lon窗口记录。转移到判决状态1356，功能1346确定在状态1345读取的记录中，lat/lon窗口值是否等于主叫提供的电话号码的lat/lon窗口值。如果两个值相等，功能1346转移到状态1358，在此，K的值加一。然后，功能1346转移到状态1359，把从客户服务区域(lat/lon)窗口文件1216中读取的当前记录的服务位置ID移入一个“可能服务位置清单”的第K个元素。然后，功能1346返回状态1355，继续从客户服务区域窗口文件1216中读取记录。返回判决状态1356，如果来自客户服务区域窗口记录和主叫提供的电话号码的纬度和经度窗口值不等，功能1346返回处理1220(图35)的状态1357。

现在参考图37，描述主叫位置在服务区域端点内的功能1348。功能1348从起始状态1360开始，转移到状态1362，在此，打开与主叫DNIS对应的客户服务区域阵列文件1214和客户服务位置文件109。客户服务区域阵列文件1214可视为到客户位置文件109的一个专用索引。在状态1362，功能1346生成的可能服务位置清单在内存中以用于功能1348。

然后，功能1348转移到状态1364，在此，置变量J的值等于一，变量K的值等于零。转移到状态1366，功能1348通过可能服务位置清单中位置(J)的ID值索引，从客户服务区域阵列文件1214中读取记录。功能1348从服务区域阵列文件1214中获得到客户服务位置文件109的字节偏移以及服务位置的纬度和经度端点。功能1348转移到判决状态1368及其后的判决状态1370、1372和1374，以确定主叫提供的电话号码纬度或经度是否小于服务位置的服务区域最小纬度或经度，或者大于服务位置的服务区域最大纬度或经度。如果状态1368、1370、1372或1374中的任何一次判决结果为“yes(是)”，主叫位置就在当前服务位置的服务区域“之外”，功能1348转移到状态1388。在状态1388，功能1348令J的值加一，然后返回状态1366，跳至下一个服务位置。

另一方面，如果判决状态1368、1370、1372和1374中的所有判决结果都是“no(否)”，功能1348就转移到状态1376，跳至服务位置文件109中的字节偏移处，读取包含服务位置的服务区域详细定义的服务位置记录。该字节偏移用于在服务位置文件109中定位正确的记录，它是在状态1366读取服务区域阵列文件1214时获得的。

完成状态1376之后，功能1348调用功能1380，以执行“主叫在服务区域内测试”。下文将根据图38更详细地描述功能1380。功能1380一经完成，指示“之内”或“之外”的一个返回标志就被设置。如果返回标志值是之外，功能1348就转移到状态1388，如上所述，J的值加一。如果返回标志值是之内，功能1348就转移到状态1382,K的值加一。转移到状态1384，功能1348把当前的服务位置ID或电话号码(从服务位置文件109获得)和所计算得到的距离移入最终服务位置清单的第K个位置。转移到状态1386，功能1348测试并确定是否已计算完可能清单中的所有位置。如果没有，功能1348转移到状态1388，将J的值加一，然后转移到状态1366。如果判决状态1386确定已计算完可能清单中的所有位置，功能1348就已经建立起所有服务位置的最终清单，其服务区域包括主叫提供的电话号码位置。功能1384就转移到返回状态1390，从那里返回处理1220中的状态1349(图35)。

现在参考图38，描述主叫在服务区域内的测试功能1380。功能1380从起始状态1402开始，转移到状态1404，在此，确定当前服务位置是一个半径还是多边形定义的服务区域。该信息是之前从客户服务位置文件109中提取的。

如果在判决状态1404确定服务区域是半径定义的，功能1380就转移到状态1426，在此，计算从主叫提供的电话号码到服务位置的距离平方。用距离的平方代替距离是为了节省把一个数开平方需要的时间。

之后，功能1380的半径分支(状态1404确定)转移到判决状态1428，以确定当前服务区域是否是半径定义的。由于对于半径分支来说这一点为真，功能1380就转移到判决状态1430，比较状态1426算出的距离平方与服务位置的服务区域半径平方。服务位置的半径从服务位置文件109中获得。如果判决状态1430确定距离平方大于半径平方，功能1380在返回状态1424置返回标志值为“outside(之外)”，并返回功能1348(图37)。但是，如果判决状态1430确定距离平方不大于半径平方，功能1380就在返回状态1432置返回标志值为“inside(之内)”，并返回功能1348(图37)。

返回图38的判决状态1404，如果确定服务区域是多边形定义的，功能1380转移到状态1406。功能1380的多边形分支部分与用于双表系统客户表创建处理的多边形部分的功能930(图21)处理基本相同。在状态1406，功能1380计算用于主叫提供的电话号码的位置的一个整数相对纬度值。主叫提供的电话号码纬度被转换成可以与线路索引文件中的服务区域纬度进行比较的形式，线路索引文件将在下文描述。之后，功能1380转移到状态1408，对主叫提供的电话号码经度进行状态1406对纬度所作的相同转换。在状态1408完成经度转换之后，功能1380转移到状态1410，在此，置变量“count”的值等于零。

转移到状态1412，功能1380得到线路索引文件。线路索引文件由双表系统中多边形服务区域创建处理所用的功能618生成。图19a和19b中详细地描述了功能618。在以上状态1412生成线路索引文件、或读取了存储在客户位置文件109增强版(例如客户位置文件1140(图29所示)中的线路索引文件预建版)之后，功能1380转移到状态1414，从线路索引文件中读取第一条记录。

转移到判决状态1416，功能1380测试从线路索引文件读取的转换后纬度点是否大于主叫提供的电话号码位置的转换后纬度点(来自状态1406)。如果判决状态1416的结果为“no(否)”，功能1380转移到判决状态1418，测试并确定从线路索引文件读取的转换后经度点是否小于主叫提供的电话号码位置的转换后经度点(来自状态1408)。如果判决状态1418的结果为“no(否)”，功能1380返回到状态1414，从线路索引文件中读取下一条记录。如果判决状态1418的结果为“yes(是)”，功能1380转移到状态1420，变量“count(计数)”的值加一，然后返回状态1414。

另一方面，如果判决状态1416的结果为“yes”，功能1380转移到判决状态1422，确定状态1420中列出的变量“count”值是偶数还是奇数。如果结果是“even(偶数)”，功能1380在返回状态1424置返回标志值为“outside”，并返回功能1348的状态1388(图37)。如果图38中判决状态1422的结果是“奇数”(主叫提供的电话号码位置在当前服务区域内)，功能1380转移到状态1426，计算主叫提供的电话号码位置与当前服务位置之间的距离平方。之后，功能1380的多边形分支通过判决状态1428，沿“no”分支达到返回状态1432。在状态1432，功能1380置返回标志值为“inside”，并返回功能1348的状态1382(图37)。

ⅩⅤ．实时处理系统实例

下面参考图39(结合图30)，描述系统级的实时呼叫进程处理1450。实时处理系统1200执行实时呼叫进程处理1450流程图所示的处理流程。该处理通过使用实时判断，向客户的目的服务位置传送主叫的电话呼叫。处理1450使用根据图30描述的实时处理系统1200的网络配置。

在图39中，实时处理1450的开始状态(110到118、1451)类似于单表系统处理1160(图28)中的初始状态(110到118、1162)。另外，实时判断处理1450的最后状态(1464到150)类似于单表系统处理1160中的结束状态(1168到150)。因为单表系统实例中已描述了这些类似状态，所以下文将只描述状态1452到1462。

在图39中的状态1452，处理1450在主控电话号码到纬度和经度表l010中查找用于主叫提供的电话号码位置的纬度和经度。转移到判决状态126，处理1450确定在主控表1010内查找主叫提供的电话号码是否成功。如果没有，正如前面根据图1c在状态128的描述，处理1450转移到用于不可传送呼叫异常处理的状态128。如果判决状态126确定主叫提供的电话号码在主控表1010中，处理1450转移到判决状态1454，确定在状态1452是否提取出一个纬度和经度。如果没有提取出纬度和经度，处理1450转移到如上所述、用于不可传送呼叫异常处理的状态128。如果在状态1452提取出一个纬度和经度，处理1450在信息分组1456中将其提供给处理模块1220。

可以在传送处理器1150(图30)上运行的处理模块1220已根据图29作过大致描述，并且还根据图35到38进行详细描述。总之，处理1220把所提取的与主叫提供的电话号码位置对应的纬度和经度转换成了一个lat/lon窗口关键字。然后，它使用这一关键字从一个DNIS相关客户服务区域窗口文件1216(图29和30，但是图39未示出)中提取一个可能服务位置电话号码或ID清单。处理1220使用这些提取出的服务位置ID，从一个DNIS相关客户服务区域阵列文件1214(图29和30，但是图39未示出)中提取字节偏移以及服务区域纬度和经度的最小值及最大值。对于主叫提供的电话号码纬度和经度落在通过服务位置的最小和最大纬度及经度定义的矩形边界内的每个可能服务位置，处理1220使用字节偏移从DNIS相关服务位置文件109中提取关于该服务位置之服务区域的详细定义。经过索引后的每个文件109将如同若干表1140(图30)中的一个所示。软件选择器根据DNIS从一组服务位置文件109中选择一个。然后，处理1220进行一次精确的“服务区域内”测试，并创建通过距离(从主叫提供的电话号码位置到服务位置)排序的服务位置ID或电话号码的最终清单。最终清单还如图29的清单1222所示。

转移到状态1462，处理1450确定来自状态1460的清单是否包含任何记录。如果该清单为空，即不包含记录，处理1450就转移到用于不可传送呼叫异常处理的状态128，或者如果该清单包括一条或多条记录，处理1450就转移到状态1464。因为图39中的状态1464到150类似于图28中已为处理1160描述过的状态1168到150，所以这里不再重复对处理1450末尾剩余状态的描述。

ⅩⅥ．带有移动电话的实时处理

下面参考图40(结合图30)，描述可支持移动电话的系统级实时呼叫进程处理1500。实时处理系统1200执行实时呼叫进程处理1500流程图所示的处理流程。处理1500通过使用实时判断向客户的目的服务位置传送可能发自一部移动电话的主叫电话呼叫。就本文而言，移动电话指没有时间上固定位置的电话。移动电话可以是任何类型的电话，包括蜂窝电话、个人通信系统(PCS)电话、卫星电话、海事电话和便携式仿真终端，但不局限于这些电话。例如一台计算机，诸如个人数字助理(PDA)或其他便携式计算机，可以配上麦克风和扬声器或头戴式送受话器以及电话仿真软件，例如Microsoft Phone，并通过一个无线调制解调器与电话网连接。处理1500使用根据图30描述的实时处理系统1200的网络配置。

在实时处理系统1200的一个实施例中，电话网按预定时间间隔提供一个主叫电话位置的空间坐标。因此，在任何特定的时刻上，可以获得主叫电话的瞬时位置。当然，由于主叫可能以每小时65英里的速度运动，例如主叫位置迅速变化时，因此瞬时位置可以认为是对主叫电话位置的一个良好估计。

正如前面提到的，本发明提供了一种方法，用于根据包括邮政地理区域、普查地理区域、通信地理区域、专用网格坐标地理区域和传统地理区域在内的任何地理区域定义传送电话呼叫。取决于系统1200所用的地理区域类型，可以使用各种坐标系统。主叫空间坐标可以是诸如邮政zip+4代码之类的单个号码，不过一些其他较小的地理区域也能具有唯一的空间坐标，例如zip+6代码区域、普查街区、或极小的纬度/经度网格、矩形、窗口或方格。另外，主叫空间坐标可以是一个数对，例如纬度和经度或V&H、极角和半径矢量、甚至另一种识别主叫瞬时位置的方式。其他可能的主叫空间坐标系统包括军用坐标和国家平面坐标。

当从电话网中获取移动电话的空间坐标时，与处理1450(图39)相比，处理1500就已经简化了。有几个步骤(状态1451、1452、126和1454)不需要执行，这时也不使用主控表1010。

在图40中，实时处理1500的状态110、112、1451、1452、126、128、1454、1460-1464和144-154类似于实时处理1450(图39)中的对应状态(110、112、1451、1452、126、128、1454、1460-1464和144-154)。因为已在前面实时处理1450实例中描述过这些类似状态，所以下文将只描述状态1502到1510。

在图40中的状态1502，处理1500从呼叫译码硬件模块112中获得一个信息分组。在发明的一个实施例中，该信息分组包含一个主叫电话号码和一个所拨电话号码，而在另一个实施例中，信息分组包含所拨电话号码和一个主叫电话的瞬时空间坐标。还有一个发明的实施例中，该信息分组可以包含所有的三个数据项。转移到判决状态116，处理1500确定呼叫应用是否需要可选的主叫输入。如果不需要，处理1500转移到判决状态1504。但是，如果判决状态116确定主叫应用需要可选的主叫输入，处理1500转移到状态118，在此，主叫提供另一个人或公司的电话号码，该号码对应的位置通常不同于主叫对应的位置。新电话号码的输入可以通过主叫使用例如按键式电话上的DTMF键盘，通过计算机或其他可以产生按键音的设备，或者通过向接口盒1130(图30)传递语音信息来实现。状态118还要针对Bellcore NPANXX分裂文件1136(图30)与合法及移动电话号码文件1138(图30)检查主叫提供的电话号码，并在主叫提供的号码非法时提示主叫输入另一个电话号码。

一旦确定输入的电话号码合法，或者主叫经过客户指定次数的输入后产生的号码仍然非的，处理1500转移到判决状态1504，确定是否从电话网获得了一个主叫空间坐标，以及状态118没有提供可选的主叫输入。如果是，处理1500在实时处理模块1510中继续，在信息分组1506中提供主叫的空间坐标。在系统1200的一个实施例中，主叫空间坐标是一个纬度和经度对。

在一个实施例中，模块1510基本上类似于模块1220，后者已根据图29进行过大致描述，并根据图35到38进行过详细描述。总之，模块1220把主叫空间坐标(例如与主叫电话位置对应的纬度和经度(来自信息分组1502))转换成了一个lat/lon窗口关键字。然后，它使用这一关键字从一个DNIS相关客户服务区域窗口文件1216(图29和30，但是图40未示出)中提取一个或多个可能服务位置电话号码或ID的清单。模块1220使用这些提取出的服务位置ID，从一个DNIS相关客户服务区域阵列文件1214(图29和30，但是图40未示出)中提取字节偏移以及服务区域纬度和经度的最小值及最大值。对于主叫电话的纬度和经度落在通过服务位置的最小和最大纬度及经度定义的矩形边界内的每个可能服务位置，模块1220使用字节偏移从DNIS相关服务位置文件109中提取关于该服务位置之服务区域的详细定义。然后，模块1220进行一次精确的“服务区域内”测试，并创建通过距离(从主叫提供的电话号码位置到服务位置)排序的服务位置ID或电话号码的最终清单。最终清单还如图29的清单1222所示。

在实时处理模块1510的另一个实施例中，使用的是一个主叫空间坐标，而不是纬度和经度。模块1510及图29所示文件要根据使用坐标系统作出修改。

返回图40的状态1504，如果没有从电话网获得主叫空间坐标，或者在状态118接收到可选的主叫输入，处理1500转移到前面所述的判决状态1451。例如，如果主叫从车辆上的一部蜂窝电话发出一次电话呼叫并输入家里的电话号码，以便把比萨饼送到主叫家中，处理1500就会转移到状态1451。在另一个例子中，如果主叫使用一部移动电话预定距离车辆最近位置的比萨饼，以便在比萨饼餐馆用晚餐或取走，处理将带着分组1506的坐标信息，直接从判决状态1504转移到模块1510。

在处理1500的另一个实施例中，正如前面根据图27和30所作的描述，可以不连接主叫与服务位置，而是向主叫提供关于服务位置的信息。这些信息可以包括以下内容：例如服务位置电话号码、营业日期和小时、名称、地址和微区域方向、时区、夏令时标志等等。

ⅩⅦ．其他移动电话实施例

移动电话可用于自动呼叫处理系统的其他实施例。这些实施例可以包括在带有一个可选主控表的双表系统中和带有一个可选客户表的单表系统中使用移动电话。

在双表系统中，一个确定器功能或坐标到空间关键字模块接收与主叫瞬时位置对应的空间坐标。如上所述，空间关键字可以是各种类型的，例如一个zip+4代码。然后使用所确定的空间关键字访问若干客户表中的一个，如上所述，该客户表是根据所拨电话号码选择的。

在一个实施例中，坐标到空间关键字模块可以包括一个主叫空间坐标到窗口代码功能。然后使用窗口代码访问一个可选主控表，该表中的每条记录包括窗口码和一个对应的空间关键字。例如，主叫空间坐标可以是由电话网提供的一个纬度和经度。如果主叫空间坐标是纬度和经度，主叫空间坐标到窗口代码功能用100乘以以度为单位的纬度，取乘积的整数部分(INT)，再用100,000乘以整数部分，然后加上以度为单位的经度与100的乘积。在一个实施例中，结果是一个九位窗口代码。如果系统的其他实施例中提供了其他主叫空间坐标，主叫空间坐标到窗口代码功能要根据坐标类型进行修改。

在一个实施例中，可选主控表通过使用GDT或采用数字化邮区代码边界的邮政局Zip+4纬度和经度重心文件100产生。基本原理是把地球划分成百分之一(0.01°)纬度和经度的矩形，例如，该矩形在40°纬度处的长宽约为0.7英里和0.5英里，然后列出覆盖每个矩形的所有zip+4代码。例如，这种大小的一个矩形可以包含郊区的一个zip+4代码，中等居住密度城市附近的二十个zip+4代码，或是大城市高密度市区的二百个zip+4代码。

可选的主控表通过以下处理生成：从超过28,000,000条记录的Zip+4重心文件100中读取每条记录，并写下包含一个纬度和经度(lat/lon)窗口代码及一个zip+4代码的对应记录。lat/lon窗口代码字段通过以下计算产生：以度为单位的纬度(来自Zip+4重心文件100)乘以100，取乘积的整数部分(INT)，再用100,000乘以整数部分，然后加上以度为单位的经度与100的乘积。

例如，如果输入的zip+4记录是920141909，纬度是北纬32.9862，经度是西经117.2522，输出的可选主控表记录中，lat/lon窗口代码应该是329811725，邮区代码是920141909。向一个初始或临时文件(未示出)写入所有记录之后，根据lat/lon窗口代码值或与zip+4代码对应的关键字对文件排序，并删除重复记录。这样就写入了最终可选主控表，其中每条记录由lat/lon窗口关键字和对应的zip+4代码组成。

可选主控表可以有与某个lat/lon窗口对应的多个zip+4代码存在，它们是可选主控表中具有同一lat/lon窗口(但是zip+4代码不同)的多条记录。可选主控表的这种状态为客户传送电话呼叫提供了灵活性。如上所述的一个lat/lon窗口可以包括一个以上的服务区域(每个区域有自己的服务位置和对应的电话号码)的部分，特别是在某个客户使用重叠服务区域的时候。在系统的一个实施例中，如果一个以上的服务区域和一个lat/lon窗口相对应，系统软件通过几种可能方案中的一种来为服务位置选择一个服务区域和对应的电话号码。例如，一种方案可以按循环的方式来分配电话呼叫，例如从为某个lat/lon窗口服务的位置中选择近来被呼叫次数最少的位置。另一种方案可以使用呼叫业务量信息在为某个lat/lon窗口服务的服务位置之间均衡呼叫量。还有一种方案首先确定哪个呼叫位置在呼叫进行期间营业，然后使用前面的某种方案或其他方案分配呼叫。

在系统的另一个实施例中，通过选择一个zip+4代码来代表lat/lon窗口，进一步处理可选主控表中的每个lat/lon窗口。这种进一步的处理能为可选主控表提供有效性、更快速的呼叫传送以及降低存储要求。对每个lat/lon窗口的进一步表处理涉及几个步骤。首先，例如通过确定连接窗口对角顶点的两条对角线的交点来计算lat/lon窗口的中心。之后，使用用于某个lat/lon窗口的每个zip+4代码的重心(可从Zip+4重心文件获得)，计算从lat/lon窗口中心到每个重心的距离。前面根据图10的状态430描述过这种类型的距离计算。然后选择保留可选主控表中距离最短的zip+4代码，并删除用于同一窗口的其他zip+4代码记录。然后对可选主控表中的每个lat/lon窗口重复这些步骤。当完成这些步骤时，经过进一步处理的可选主控表中对于每个lat/lon窗口只有一条记录，该记录包括窗口中最核心的zip+4代码。

在工作时，具有移动电话能力的双表系统从电话网接收主叫空间坐标，例如纬度和经度。该坐标被转换成如上所述的一个窗口代码。窗口代码用于访问可选主控表，以便从表中获得一个空间关键字，例如zip+4代码。然后根据所拨电话号码，使用空间关键字访问一个客户表106(图1)，以获得一个客户服务位置电话号码或客户服务位置ID。

在单表系统中，使用与图23所示和描述相同的处理来合并上述可选主控表和一个客户表106(图1)。主控表和排序后的主控表使用一个窗口代码字段取代了电话号码字段，从而产生一个窗口代码到客户电话号码表。在工作时，具有移动电话能力的单表系统从电话网接收主叫空间坐标，例如纬度和经度。该坐标被转换成如上所述的一个窗口代码。窗口代码用于访问一个窗口代码到客户电话号码表，以获得一个客户服务位置电话号码或客户服务位置ID。系统根据所拨电话号码选择若干窗口代码到客户电话号码表中的一个。

在一个三表系统中，或与单表系统中的一个辅助表一起使用时，被提取的客户服务位置ID被用于索引第三个表或辅助表，以提供客户服务位置信息，例如前面提到的内容。可以为主叫提供收听所提供的客户服务位置信息或向客户服务位置传送呼叫的选择。

ⅩⅧ．总结

本发明使用电话号码作为到一个表的索引，该表包含一个国家到小地理区域或点的划分，例如邮政业务zip+4代码、纬度和经度等等。这些划分进一步用于访问可能在国内任何地方的若干服务位置中的一个。

本发明的自动电话传送系统能通过在没有任何人为干预的情况下传送拨至单个国内电话号码的绝大部分呼叫来降低成本，并具有为客户提供单个、易记忆、免去长途或普通话费的国内电话号码的市场竞争优势。通过使用与zip+4代码对应的主叫和被叫电话号码所有的十位数字或用于这些号码所在位置的纬度和经度，该系统还能提供地理上非常精确的结果。自动传送系统能为一个公司提供在不同类型的服务位置的服务区域定义之间进行选择的能力。优选地，客户可以把每个位置的服务区域定义为任意大小的半径的一个区域或任意大小和形状的一个多边形。客户可以混用半径和多边形定义，也可以使服务区域重叠或不重叠。

该系统在定义如何选择选择某个客户位置终接呼叫方面具有一定的灵活性。客户能够指定连接在某个位置的任何预定距离(到十分之一英里)半径内的主叫；或连接距离主叫最近的客户服务位置；或连接在某个客户位置的预定多边形内的主叫，其中多边形边长可以是任意长度。多边形区域可以代表一个专用区域，如果区域是非专用的，也可以与其他多边形或其他客户位置的半径区域重叠。另外，如果需要的话，每个客户位置可以具有不同的区域类型、不同的半径或长宽。在非专用多边形或半径类型区域中，灵活性得到加强，这时可以在该区域内的多个位置中进行随机或加权选择。

本发明提供了一种传送呼叫的方法，该呼叫始发于所有公开和未公开的电话号码，包括未列出的号码、第二条未公开的公司线路、移动电话和公共付费电话。本发明还提供了一种方法，通过把用户的呼叫准确地传送到正确的指定特许区域内，能合法地实现与经销商和总经销商之间达成协议的特许区域定义相一致。另外，本发明提供了一种方法，根据包括邮政地理区域、普查地理区域、通信地理区域、专用网格坐标地理区域和所有传统地理区域在内的任何地理区域定义，准确地传送电话呼叫。

本发明提供了一种方法，用于自动传送和处理不满足预置客户协议的用户呼叫。这种“异常处理”过程向一个执行预置异常处理协议的“实际”操作员传送呼叫。本发明还提供了一种方法，用于把不相关的地理信息系统和数据库技术、通信系统和数据库技术、邮政系统和数据库技术、以及计算机技术集成为一种公共应用驱动的结构。另外，本发明提供了一种方法，用于自动和独立地更新客户和主控表，并在呼叫处理期间动态和瞬时地链接这两个表。而且，本发明还提供了一种方法，用于使处理由用户使用用户接口输入的信息的过程自动化，该处理过程自动向用户要求的目的地传送电话呼叫。

双表系统提供了一个可更新并支持多个客户的主控表(电话号码到空间关键字)，其中每个客户表的更新独立于其他客户表和主控表。当客户表包含作为服务位置ID的服务位置电话号码时，就每秒可与一个服务位置连接的呼叫数来说，这种设计能最大限度地提高事务处理容量。

双表系统是基于所拨号码的一种传送内核的实施例，它能有效地确定哪些具有任意大小和形状的在地理上定义的客户服务区域包含主叫或主叫提供的电话号码位置，并确定从主叫位置到每个服务位置的距离和方向。

传送内核的另一种实施例，即单表系统，提供了与双表系统相同的许多特性，另外它还能更快地传送呼叫。因为它只需要一次磁盘查找来确定服务位置的电话号码，单表系统在呼叫传送处理期间是最快的。从网络的角度来说，由于它的只具有一个表的简单性，它最容易在通信网中实施。

传送内核还有一种实施例，即实时处理系统，是最容易更新和需要存储量最小的实施例。主叫或主叫提供的电话号码与客户服务位置之间的空间关系可在呼叫进行时确定。带有纬度和经度的电话号码主控表以及每个客户服务位置文件可以被独立保存，并能驻留在不同的机器上。该系统是流线型的，如果在终接交换机的信息分组中收到了主叫空间坐标，就不需要进行主控表查找。当主叫从一部移动电话发出呼叫时，会出现这种情况。

作为对单表系统的一种改进，即双表系统和实时处理系统，可以增加一个索引的客户服务位置表，以便提供对与服务位置有关的更多信息的访问。它在实时系统中实现时要较为直接一些，因为在呼叫处理期间已经使用到客户服务位置表，很容易使用它再向用户提供附加信息。对于单表系统和双表系统来说，用于容纳被索引的客户服务位置表所用的客户表创建处理基本上与单表系统和双表系统原来所用的处理相同，只不过客户位置ID取代了客户位置电话号码。

尽管上面已给出详细的描述，并指出了发明应用到各种实施例中时的一些基本新特点，但是应当理解在不脱离发明原理的前提下，本领域的技术人员可以对系统的形式和细节作省略、替代和改动。

权利要求书

按照条约第19条的修改

1．在电话网呼叫处理系统中使用的一种识别在空间上包含无线主叫电话瞬时位置的客户服务区域的实时方法，该方法包括：

提供具有任意所要形状和大小的客户服务区域文件，其中每个服务区域通过空间坐标窗口进行地理索引，并且每个服务区域与一个服务位置相关联；

获得与无线主叫电话瞬时位置对应的一个主叫空间坐标；

在客户服务区域文件的空间坐标窗口索引中查找主叫空间坐标，以便产生至少包括一个服务位置的可能清单，这些位置的服务区域可能包含与主叫空间坐标对应的位置；

确定哪些服务区域包括与主叫空间坐标对应的位置；以及

产生一个服务位置清单，其服务区域包含与主叫空间坐标对应的位置。

2．权利要求1定义的方法，其中确定步骤使用主叫电话瞬时位置的空间坐标和所述的可能清单中客户服务区域的空间定义。

3．权利要求1定义的方法，还包括确定从主叫电话的瞬时位置到服务位置的距离。

4．权利要求3定义的方法，还包括对其服务区域包含主叫电话瞬时位置的服务位置清单按照距离降序进行排序。

5．一种用于实时确定在空间上包含移动主叫电话瞬时位置的客户服务区域的电话网呼叫处理系统，该系统包括：

一个客户服务区域文件，该区域具有任意所要的形状和大小，其中每个服务区域通过空间坐标窗口进行地理索引，并且每个服务区域与一个服务位置相关联；

呼叫译码硬件，该呼叫译码硬件能够获得与主叫电话瞬时位置对应的一个主叫空间坐标；

初始服务区域清单功能，该功能能够在客户服务区域文件的空间坐标窗口索引中查找主叫空间坐标，以便产生至少包括一个服务位置的可能清单，这些位置的服务区域可能包含与主叫空间坐标对应的位置；以及

主叫位置在服务区域端点内的功能，该功能能够确定哪些客户服务区域包括与主叫空间坐标对应的位置，并能产生一个服务位置清单，

Claims (30)

1．在电话网呼叫处理系统中使用的一种识别在空间上包含主叫电话瞬时位置的客户服务区域的实时方法，该方法包括：

提供具有任意所要形状和大小的客户服务区域文件，其中每个服务区域通过空间坐标窗口进行地理索引，并且每个服务区域与一个服务位置相关联；

获得与主叫电话瞬时位置对应的一个主叫空间坐标；

在客户服务区域文件的空间坐标窗口索引中查找主叫空间坐标，以便产生至少包括一个服务位置的可能清单，这些位置的服务区域可能包含与主叫空间坐标对应的位置；

确定哪些服务区域包括与主叫空间坐标对应的位置；以及

产生一个服务位置清单，其服务区域包含与主叫空间坐标对应的位置。

2．权利要求1定义的方法，其中确定步骤使用主叫电话瞬时位置的空间坐标和所述的可能清单中客户服务区域的空间定义。

3．权利要求1定义的方法，还包括确定从主叫电话的瞬时位置到服务位置的距离。

4．权利要求3定义的方法，还包括对其服务区域包含主叫电话瞬时位置的服务位置清单按照距离降序进行排序。

5．一种用于实时确定在空间上包含移动主叫电话瞬时位置的客户服务区域的电话网呼叫处理系统，该系统包括：

一个客户服务区域文件，该区域具有任意所要的形状和大小，其中每个服务区域通过空间坐标窗口进行地理索引，并且每个服务区域与一个服务位置相关联；

呼叫译码硬件，该呼叫译码硬件能够获得与主叫电话瞬时位置对应的一个主叫空间坐标；

初始服务区域清单功能，该功能能够在客户服务区域文件的空间坐标窗口索引中查找主叫空间坐标，以便产生至少包括一个服务位置的可能清单，这些位置的服务区域可能包含与主叫空间坐标对应的位置；以及

主叫位置在服务区域端点内的功能，该功能能够确定哪些客户服务区域包括与主叫空间坐标对应的位置，并能产生一个服务位置清单，其服务区域包含与主叫空间坐标对应的位置。

6．权利要求5定义的系统，其中主叫位置在服务区域端点内的功能使用主叫电话瞬时位置的空间坐标和该可能清单中客户服务区域的空间定义。

7．权利要求5定义的系统，还包括用于确定从主叫电话的瞬时位置到服务位置距离的处理。

8．权利要求7定义的系统，还包括用于对其服务区域包含主叫电话瞬时位置的服务位置清单按照距离降序进行排序的处理。

9．一种电话网呼叫处理系统，包括：

一个呼叫译码模块，它能够接收所拨号码以及与移动主叫电话瞬时位置对应的一个主叫空间坐标；

一个实时处理模块，根据所拨号码与主叫空间坐标来提供与所选服务位置对应的客户服务信息，其中如果主叫空间坐标被包含在一个服务区域内时，就提供该服务位置，该服务区域具有客户定义的任意形状和大小的地理配置；以及

一个出局呼叫模块，用于向电话网传送所提供的客户服务信息。

10．权利要求9定义的系统，还包括多个客户服务位置文件。

11．权利要求10定义的系统，其中实时处理模块使用所拨号码来选择与由所拨号码标识的客户对应的一个客户服务位置文件。

12．权利要求10定义的系统，其中客户服务位置文件之一包括多个记录，每个记录包括客户服务位置标识(ID)、电话号码、以及该服务位置的服务区域边界描述。

13．权利要求12定义的系统，其中多边形服务区域的边界描述包括多边形的每个顶点。

14．权利要求12定义的系统，其中半径定义的服务区域包括一个中心点和一个半径。

15．权利要求9定义的系统，其中主叫电话包括一部移动蜂窝电话。

16．权利要求9定义的系统，其中主叫电话包括一部移动个人通信系统电话。

17．权利要求9定义的系统，其中客户服务信息包括允许向所选客户服务位置传送呼叫的传送信息。

18．权利要求9定义的系统，还包括一个语音响应单元，其中该语音响应单元设备向电话网提供与所选客户服务位置对应的客户服务信息。

19．权利要求9定义的系统，其中客户服务信息包括与所选客户服务位置对应的一个标识(ID)。

20．一种用于移动电话网的实时呼叫处理方法，该方法包括：

接收所拨电话号码以及与移动主叫电话瞬时位置对应的一个主叫空间坐标；

根据所拨电话号码与主叫空间坐标来提供与所选服务位置对应的客户服务信息，其中如果主叫空间坐标被包含在一个服务区域内时，就选择对应的服务位置，该服务区域具有客户定义的任意形状和大小的地理配置；以及

向电话网传送所提供的客户服务信息。

21．权利要求20定义的方法，还包括提供多个客户服务位置文件。

22．权利要求21定义的方法，其中提供客户服务信息要使用所拨号码去选择与由所拨号码所标识的客户对应的客户服务位置文件之一。

23．权利要求21定义的方法，其中客户服务位置文件之一包括多个记录，每个记录包括客户服务位置标识(ID)、电话号码、以及该服务位置的服务区域边界描述。

24．权利要求23定义的方法，其中多边形服务区域的边界描述包括多边形的每个顶点。

25．权利要求23定义的方法，其中半径定义的服务区域的边界描述包括一个中心点和一个半径。

26．权利要求20定义的方法，其中主叫电话包括一部蜂窝电话。

27．权利要求20定义的方法，其中主叫电话包括一部个人通信系统电话。

28．权利要求20定义的方法，其中客户服务信息包括允许向所选客户服务位置传送呼叫的传送信息。

29．权利要求20定义的方法，其中由一个语音响应单元来向电话网发送与所选客户服务位置对应的客户服务信息。

30．权利要求20定义的方法，其中客户服务信息包括与所选客户服务位置对应的一个标识(ID)。

Images