电话号码表的清理方法及系统的制作方法

文档序号:7570262阅读:211来源:国知局
专利名称:电话号码表的清理方法及系统的制作方法
技术领域
本发明涉及在电话购物之类客户表等的电话号码清理系统,通过诸如个人计算机那样的设备的电话号码表中删去那些无效的电话号码。
在许多利用电话进行的商务中,客户的电话号码表具有相当重要的信息,必需经常加以维护,从中删去那些已经无用的电话号码,以保证所含信息的有效性。这类表中的客户信息本来就是容易变动的信息。即,客户的电话号码可能由于停止使用所登记的电话号码、改为其他电话号码而发生了变动,也可能因为原登记的是一个错误的号码而无效。这样的无效电话号码必需从表中删掉或者用正确的或新的电话号码代替。
历来,客户表的维护是根据通过一定商业事务按照电话号码表给各个客户打电话来实现的。也就是说,通过检验各客户的响应来删除或更新无效的电话号码。
这种传统的与商务活动配合进行的删除和更新电话号码表中的电话号码的清理方法当然可能在一些商务中造成明显的浪费和不合理。也就是说,由于不可避免地要给那些具有应该从表中删去的无效电话号码的客户打电话,就可能造成额外的开支,或者打扰那些不是客户的人们。另一方面,对于那些已经迁到其他地址的客户来说,可能会出现多余地既向旧电话号码又向新电话号码打电话的情况,浪费了时间和开支。
本发明的目的是提供一种清理电话号码表的方法和系统,可以用个人计算机之类自动有效地执行删除无效电话号码而不需要打那些实际的商务电话。
本发明利用与现有的公众电话网结为一体的ISDN所提供的先进的承载业务准确、快速地处理电话号码表的更新。也就是说,本发明所提出的采用诸如个人计算机那样设备的电话号码表的清理方法和系统包括(1)将系统作为一个主叫终端接至一个处理在ITU-T建议Q931中规定的电路交换呼叫控制过程的ISDN。
(2)从需清理的电话号码表中相继检索出一个电话号码作为一个被叫方号码,向网发送一个在“承载能力”信息元中包括一个不受限制或受限制的数字信息的SETUP(建立)消息。
(3)当网接受SETUP消息而发送一个“告警”或“连接”消息时,系统立即向网发送一个“拆线”消息,执行拆线和释放序列,从而确定在SETUP消息中的被叫方号码有效。
(4)当网不接受所发出的SETUP消息而发送一个“拆线”消息时,系统立即执行拆线和释放序列,得到一个在网发送的“拆线”消息的原因信息单元中的原因显示,从而根据这个原因显示确定在SETUP消息中的被叫方号码有效或无效。
(5)产生一个新电话号码表,分别列出确定为有效的电话号码和确定为无效的电话号码。
本发明所提出的清理系统可以包括一个附加的基元,其作用是在网所发送的原因包括“号码改变”的情况下得到一个填在附于原因的诊断信息段中的新电话号码,用所得到的新电话号码代替SETUP消息中的号码,从而产生一个经修正的表。此外,可能较为合适的是根据原因内容推迟确定每个电话号码是有效或无效,而将这些待决电话号码列入待决电话号码表。这样就可以在以后通过检查这些待决号码更为恰当地清理电话号码表。
在本说明书的附图中

图1示出了作为本发明的一个实施例的电话号码表清理系统硬件配置的方框图;以及图2为示出图1所示系统的清理过程主要部分的流程图。
本发明的一个实施例的系统配置情况如图1所示。典型地由一台个人计算机1用作一个ISDN终端。个人计算机1包括CPU2、存储器3、硬盘驱动器4、软盘驱动器5、显示器6、键盘7、ISDN通信板8等。个人计算机1通过ISDN通信板8和数字信号单元(DSU)10接到ISDN上。如所周知,ISDN与公众电话网相互连接成一个整体。
需清理的电话号码表以准备清理的预定格式存储在一个软盘上。清理时,这个软盘插入软盘驱动器5。通过用键盘7输入需清理的电话号码表的文件名,计算机1发出清理命令。CPU2检索出与所输入的文件名相应的电话号码表,存入存储器3。然后,启动如图2所示流程图的清理过程。
首先,按照预定顺序从电话号码表中检取一个电话号码,启动处理一个建立序列(步骤100至200)。在建立序列中,首先将从表中检取的电话号码定义为一个被叫方号码,然后产生一个将不受限制的数字信息指定为承载能力的SETUP消息,发送给网(步骤201)。建立序列200按照在ITU-T建议Q.931中详细规定的电路交换呼叫控制过程进行处理。电路交换呼叫控制过程的详细说明在本说明书中将予省略,因为有大量的参考文献可资参考。这个过程的典型序列的处理如下。
从主叫终端接收到SETUP消息后,网向主叫终端发送一个CALLPROCEDING(呼叫进行)消息,报告所选的B信道;还向被叫终端发送SETUP消息。通过这个过程,指定对被叫终端要求的各种能力。被叫终端方检查这些能力,确定哪个被叫终端符合所要求的能力。确定符合这些能力的被叫终端向网发回一个ALERTING(告警)消息(被叫终端指示告警)。ALERTING消息从网发至主叫终端。当被叫终端响应摘机时,从被叫终端经网向主叫终端发送一个CONNECT(连接)消息。然后从主叫终向网发送一个CONNECT ACKNOWLEDGE(连接确认)消息,再由网向被叫终端发送,以响应CONNECT消息。按照上述序列,接受SETUP消息,连接两个终端。
在有些情况下,由于种种原因主叫终端请求的呼叫可能未被接受。对于这些情况,网向主叫终端发送一个DISCONNECT(拆线)消息,执行清除序列。呼叫没有接受的原因以原因编号的形式向主叫终端报告。原因编号列在网发给主叫终端的DISCONNECT消息所附的原因信息单元内。
在ITU-T建议Q931中,附于DISCONNECT消息的原因显示的类别和编号定义如下。1.普通类原因NO.1未分配(未指定)号码这个原因表示不能接到被叫方,因为虽然这个被叫方号码是处于有效格式,但当前尚未分配(指定)。
原因2无至所规定的转换网的路由这个原因表示发送这个原因的设备已经接收到通过一个它不认识的特定转接网传送呼叫的请求。发送这个原因的设备不认识这个转接网,因为这个转换网不存在,或者虽然存在但不为发送这个原因的设备服务。
原因3无至终接台的路由这个原因表示不能接到被叫方,因为传送呼叫的网并不为所要求的终接台服务。
原因6信道不允许这个原因表示作为信道选择结果的所选信道对于主叫方来说不是允许信道。
原因7呼叫告知,正在已建立信道由传送这个原因表示已向用户告知呼入,但这呼入正接一个已经为这个到用户的类似呼叫(例如,分组模式X.25虚拟呼叫)的信道上。
原因16;普通呼叫清除这个原因表示呼叫由于所涉及的用户的一方已请求消除呼叫而正在清除。在一般情况下,这个原因的源不是网。
原因17用户忙这个原因表示因为已处在用户忙状态,被叫方不能接受另一个呼叫。在这种情况下,指出用户设备与呼叫是一致的。
原因18无用户响应这个原因表示被叫方在预定时间间隔内(建议中规定的定时器T303或T310的定时时间)没有用告警或连接指示进行响应呼叫建立消息。
原因19无用户应答(用户告警)这个原因表示已向被叫方告警,但在预定时间间隔内被叫方没有用连接指示进行响应。这个原因不必由JT-Q931程序产生,但可由网内定时器产生。
原因20订户不在这个原因表示移动台已用信令程序通过无线接口注销,或者不能与移动台建立无线通信(由于干扰、不在覆盖范围之内、关机等原因)。
原因21呼叫拒绝这个原因表示发送这原因的设备不愿意接受这个呼叫,虽然它并不忙也不与呼叫矛盾而可以接受呼叫、原因22号码改变当主叫方提供的被叫方号码不再使用时,向主叫方返回这个原因。新的被叫方号码可以按需要选列在诊断信息段内。
原因26无条件用户清除这个原因表示已不向用户告知呼入。
原因27终接台失常这个原因表示由于用户所指出的终接台接口工作不正常而不能接到这个终接局。“工作不正常”表示不能向这远端方传送信令消息,例如由于在这远端方物理层或数据链路层发生故障,或者用户设备脱离线路。
原因28无效号码格式(地址不完全)这个原因表示因为被叫方号码不是用有效格式列出或者不完全而不能接到被叫方。
原因29性能拒绝当网不能提供用户所请求的性能时,返回这个原因。
原因30响应STATUS ENQUIRY(状态查询)这个原因在产生STATUS消息是由于先前接收了STATUSENQUIRY消息时包含在STATUS消息内。
原因31普通,未规定这个原因用来报告一个在普通类无其他原因可归的普通拆线事件。2.资源不可得类原因34无电路/信道可得这个原因表示无现时可用来处理呼叫的合适电路/信道。
原因38网失常这个原因表示网工作不正常,并且这种情况看来要延续比较长的时间,也就是说,立即再进行呼叫看来不会成功。
原因41暂时故障这个原因表示网工作不正常,但这种情况看来不会延续多长时间,也就是说,用户可以几乎立即再试呼一次。
原因42交换设备拥塞这个原因表示产生这个原因的交换设备正处于业务高峰期间。
原因43接入信息丢弃这个原因表示网不能象所请求的那样向远端用户传送接入信息,如在诊断信息段中所指出的用户对用户的信息、低层一致性、高层一致性或子地址。应注意的是丢弃的接入信息的具体类型按需要可以选列在诊断信息段内。
原因44请求的电路/信道不可得这个原因表示接口的另一侧不能提供请求实体所指示的电路或信道。
原因47资源不可得,未规定这个原因用来报告一个在网拥塞类无其他原因可归的网拥塞的拆线事件。3.业务或选项不可得类原因49QOS不可得这个原因表示不能提供所请求的如在建议X.213中所定义的QOS(例如不能支持吞吐量或转接延迟)。
原因50所请求的性能未预订这个原因表示所请求的附加业务由于用户还没有完成允许使用的必要手续,因此网不予提供。
原因57承载能力未授权这个原因表示用户虽已请求由产生这个原因的设备提供这承载能力,但尚未授权使用。
原因58承载能力现时不可得这个原因表示用户虽已请求由产生这个原因的设备提供这承载能力,但此时不能得到。
原因63业务或选项不可得,未规定这个原因用来报告一个在业务或选项不可得类无其他原因可归的业务或选项不可得的拆线事件。4.业务不能实现类原因65承载能力不能实现这个原因表示发送这个原因的设备不支持所请求的承载能力。
原因66信道类型不能实现这个原因表示发送这个原因的设备不支持所请求的信道类型。
原因69所请求的性能不能实现这个原因表示发送个原因的设备不支持所请求的附加业务。
原因70仅受限制的数字信息承载能力可得这个原因表示一个设备已经请求不受限制的承载业务,但发送这个原因的设备仅支持所请求的承载能力的受限制形态。
原因79业务或选项不能实现,未规定这个原因用来报告一个在业务或选项不能实现类无其他原因可归的业务或选项不能实现的拆线事件。5.无效消息类原因81无效呼叫参考值这个原因表示发送这个原因的设备接收到一个带有不是在用户-网接口上现行使用的呼叫参考值的消息。
原因82无效信道编号这个原因表示发送这个原因的设备接收到一个需要为呼叫使用不在这个接口激活的信道的请求。例如,如果一个用户预订的是编号为1至12的信道,而用户设备或网希望使用信道13至23,于是就会发生这种情况。
原因83有一个挂起呼叫,但这个呼叫身份非在用这个原因表示已试用一个呼叫身份进行呼叫恢复,但这个呼叫身份不同于任何当时挂起呼叫在用的。
原因84挂起呼叫身份在用这个原因表示网接收到含有一个呼叫身份(包括无效呼叫身份)的呼叫挂起请求,但这个呼叫身份已为在呼叫可加以恢复的接口领域内一个挂起呼使用。
原因85无呼叫挂起这个原因表示网接收到一个所含呼叫身份信息单元并不指示在呼叫可加以恢复的接口领域内任何挂起呼叫的呼叫恢复请求。
原因86具有请求呼叫身份的呼叫已清除这个原因表示网接收到一个所含呼叫身份信息单元指示一个在挂起期间已(由网超时或由远端用户)清除的挂起呼叫的呼叫恢复请求。
原因87参见附加业务规范。
原因88不一致终接台这个原因表示发送这个原因的设备接收到一个请求,要求建立一个具有它不能提供的低层一致性、高层一致性或其他一致性属性(如数据率)的呼叫。
原因91无效转接网选择这原因表示接收到的转接网标识由于分别定义因此具有不正确的格式。
原因95无效消息,未规定这个原因用来报告一个在无效消息类无其他原因可归的无效消息的拆线事件。6.协议错误(例如未知消息)类原因96强制信息单元遗失这个原因表示发送这个原因的设备接收到一个消息,它遗失了在能处理这消息前消息中必需存在的信息单元(强制信息单元)。
原因97消息类型不存在或不能执行这个原因表示发送这个原因的设备接收到一个具有它不证识的消息类型的消息,这个消息或者是一个没有定义的消息,或者是一个虽有定义但发送这个原因的设备不能执行的消息。
原因98消息与呼叫状态不一致或消息类型不存在这个原因表示发送这个原因的设备接收到一个消息,使过程不指示这是在这个呼叫状态允许接收的消息,或者接收到一个STATUS消息,指示不一致的呼叫状态。
原因99信息单元不存在这个原因表示发送这个原因的设备接收到一个具有不认识的信息单元的消息,因为这(些)信息单元没有定义,或者有定义但发送这个原因的设备不能实现。然而,这消息中不需要有这信息单元,以使发送这个原因的设备处理这消息。
原因100无效信息单元内容这个原因表示发送这个原因的设备接收到一个它已加以执行的单元,然而这信息单元中的一个或几个信息段以发送这个原因的设备还不能执行的方式编码。
原因101消息与呼叫状态不一致这个原因表示接收到一个与呼叫状态不一致的消息。
原因102定时期满恢复这个原因表示已启动了一个直至与第三层规范的错误处理过程配合的定时器的定时期满为上的过程。
原因111协议错误,未规定这个原因用来报告一个在协议错误类无其他原因可归的协议错误的拆线事件。7.互通类原因127互通,未规定这个原因表示已有一个网互通,但这个网不提供它所采取的行动的原因。因此不能断定所发送的消息的精确原因。
下面对清理过程控制的流程进行说明。如图2这个流程图所示,在本发明的清理过程中,当网在建立序列200接收到一个包含一个由主叫方发送的SETUP消息的呼叫而发回一个ALERTING或CONNECT消息时,处理从步骤202或203进至步骤301、302、303。然后,主叫方立即向网发送一个DISCONNECT消息,执行清除序列,而在SETUP消息中的电话号码确定为有效,列入一个有效电话号码表。通过上面这些步骤,完成了对一个电话号码的确认。
当网在建立序列200由于由主叫方发送的SETUP消息没有接受而发送一个DISCONNECT消息时,处理从步骤204进至步骤401、402。主叫方立即执行清除序列,提取附于由网发送的DISCONNECT消息的信息单元的原因编号。按照原因,在SETUP消息中的电话号码确定为有效、无效或待决号码。(a)有效电话号码如果在步骤402提取的原因编号符合下列之一,在SETUP消息中的电话号码就确定为有效,列入有效电话号码表(步骤403至404)。原因3无至终接台的路由原因7呼叫告知,正在已建立信道传送原因16普通呼叫清除原因17用户忙原因18无用户响应原因19无用户应答原因20订户不在原因21呼叫拒绝原因27终接台失常原因49QOS不可得原因50所请求的性能未预订原因57承载能力未授权原因58承载能力现时不可得原因63业务或选项不可得,未规定原因65承载能力不能实现原因66信道类型不能实现原因69所请求的性能不能实现原因70仅受限制的数字信息承载能力可得原因79业务或选项不能实现,未规定原因88不一致终接局(b)号码改变当在步骤402提取的原因编号与原因22(号码改变)一致时,提取在原因的诊断信息段中所含的新电话号码,列入有效电话号码表(步骤403、405、406)。(c)无效电话号码如果在步骤402提取的原因编号符合下列之一,在SETUP消息中的电话号码就确定为无效,列入无效电话号码表(步骤403、405、407、408)。原因1未分配号码原因2无至所规定的转接网的路由原因6信道不允许(d)推迟确定如果在步骤402取的原因编号不符合在步骤403、405、407中所列举的任何原因编号,则在SETUP消息中的电话号码既不确定为有效,也不确定为无效,列入待决电话号码表(步骤403、405、407、409)。
如果通过以上步骤完成了对一个电话号码的审核,则执行步骤501,确定是否在需清理的电话号码表中所列的所有电话号码都已得到检查。如果还没有,则过程返回到步骤100,通过上述程序审核下一个电话号码。如果表中所列的所有电话号码都已得到检查,则执行步骤502,输出具有预定格式的修正后表。
下面对实际操作情况进行说明。需按本发明加以清理的电话号码表通常包括一个用于电话购物这类的客户表中的电话号码表。在今天的日本,在这种表内所列的大多数电话号码是那些模拟电话网用户的号码。然而,近来,ISDN(INS64)的用户逐渐增多。在通过以上处理清理目前状态的电话号码表的情况下,在本发明的清理系统和ISDN站(网)之间将进行以下通信。(A)被叫方号码是一个模拟电话网有效用户号码这种情况的电话号码看来是占大多数。本发明的系统发送一个含有指定为承载能力的不受限制的数字信息的SETUP消息,因此网发回一个含有原因3(无至终接台的路由)的DISCONNECT消息。于是,清理系统将这电话号码列入有效电话号码表。应该注意的是,在检查和确定一个号码的有效性期间绝不向具有这个电话号码的被叫方告警。也就是说,从具有需检查号码的被叫方来看,被叫方将始终不会受到不得不响应的无用呼叫的打扰。(B)被叫方号码已经改变在这种情况下,无论这用户号码是模拟电话网的还是ISDN的,网都发回一个含有原因22(号码改变)的DISCONNECT消息。清理系统接收到这个消息后,提取在原因的诊断信息段内所含的一个新的电话号码,列入有效电话号码表。(C)被叫方号码目前不在使用在这种情况下,无论这用户号码是模拟电话网的还是ISDN的,网都发回一个含有原因1(未分配号码)的DISCONNECT消息。清理系统接收到这个消息后,将被叫方号码列入无效电话号码表。(D)被叫方号码是一个ISDN有效用户号码在这种情况下,双方之间的通信模式取决于被叫方设施性能状况。被叫终端(被叫方)由本清理系统发送的CALLING(呼叫进行)消息告警。如果被叫方响应告警,则处理图2这流程图中的步骤301。清理系统启动一个清除序列,将被叫方号码列入有效电话号码表。在从网发回的是一个DISCONNECT消息的情况下,如果在这个DISCONNECT消息中的原因编号与7、16、17、18、19、20、21、27、49、50、57、58、63、65、66、70、79之一相符,就将被叫方号码列入有效电话号码表;而如果原因编号是2或6,则将被叫方号码列入失效电话号码表。如果DISCONNECT消息中的原因编号与上列原因编号任何一个都不相符,则将被叫主号码列入待决电话号码表。
应该注意的是,按照原因编号将被叫方号码分为“有效”、“无效”、“待决”三种的分类方式,在这优选实施例中所述的可能并非最佳。或许根据在用户对ISDN的使用方式和网对用户的响应这些方面更精确细致的调查将某些原因归入“有效”或“无效”比归入“待决”更为合适。本发明并不限制所提出的清理系统进行这样的灵活可变的操作。
如上面详细说明的那样,按照本发明可以自动、高效地删除无效电话号码,而不必按需要加以清理的电话号码表处理任何实际商业活动(如与客户进行一定商务往来)。也就是说,可以避免诸如与那些需要从表上删除的无效客户进行一定商业活动或打扰并不是客户的无关人员之类的浪费或不方便的情况。
本发明的一大优点是,对于那些接到模拟电话网上具有有效电话号码的电话机(这应该是极大多数),确认有效性并不需要对这些电话机进行告警。因此,从具有需检查的号码的被叫方来看,被叫方再也不用为不得不去接一个无用的电话而烦恼了。此外,不再要将在一个需清理的电话号码表中所包含的迅速普及的ISON用户与传统的模拟电话网用户分开,从而使电话号码表得到迅速的清理。
虽然本发明结合典型的实施例作了说明,但熟悉本技术领域的人们显然理解其中可以进行上述和其他的种种改动、增删,而并不背离本发明的精神和范围。因此,可以理解本发明并不局限于以上所提出的具体实施例,而是包括了根据在所附权利要求中提出的特征在所包括的范围内能够实现的所有可能实施方式及等效方式。
权利要求
1.一种包括一个诸如个人计算机之类的计算机的电话号码表清理系统,所述系统包括如下部件作为一个主叫方与一个处理在ITU-T建议Q931中所规定的电路交换呼叫控制过程的ISDN连接;从一个需清理的电话号码表中依次提取一个电话号码作为一个被叫方号码,向网发送一个在承载能力信息单元中包含一个不受限制或受限制的数字信息的SETUP消息;当网接受所发送的SETUP消息而转发一个ALERTING或CONNECT消息时,立即向网发送一个DISCONNCET消息,执行一个清除序列,确定在SETUP消息中的被叫方号码为有效电话号码;当网不接受所发送的SETUP消息而转发一个DISCONNECT消息时,立即执行一个清除序列,从来自网的DISCONNECT消息中的一个信息单元取得一个原因,按照这个原因确定在SETUP消息中的被叫方号码为有效电话号码或无效电话号码;以及产生一个分开列出确定为有效的电话号码和确定为无效的电话号码的新的电话号码表。
2.如在权利要求1中所提出的电话号码表清理系统,其中,在网发回含有“号码改变”的原因的情况下,所述系统提取一个在附于该原因的诊断信息段中的新电话号码,产生一个在SETUP消息中的电话号码由所提取的新电话号码代替的新电话号码表。
3.如在权利要求1中所提出的电话号码表清理系统,所述系统推迟确定电话号码为有效或无效,而将电话号码列入一个待决电话号码表。
4.如在权利要求1中所提出的电话号码表清理系统,所述系统指定所述受限制的数字信息为所述SETUP消息中的承载能力。
5.清理电话号码表的方法,其中所述电话号码按照如在权利要求1中所提出的清理系统进行清理和更新。
全文摘要
本发明所提出的清理系统从电话号码表中依次提取一个电话号码作为被叫方号码,向网发送一个承载能力为不受限制的数字信息的SETUP消息。在从网发回一个ALERTING或CONNCET消息的情况下,系统立即向网发送一个DISCONNECT消息,执行一个清除序列,确定这个电话号码有效。在呼叫没有接受、从网发回一个DISCONNCET消息的情况下,系统也立即执行一个清除序列,但按照网所发送的原因内容确定这个电话号码应该看作一个有效电话号码还是一个无效电话号码。
文档编号H04M3/42GK1157074SQ96190683
公开日1997年8月13日 申请日期1996年6月25日 优先权日1995年6月26日
发明者内海胜统 申请人:株式会社金泰克
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1