将拨号号码与呼叫始发方案关联的制作方法

文档序号:7605893阅读:207来源:国知局
专利名称:将拨号号码与呼叫始发方案关联的制作方法
技术领域
本发明涉及无线电话,并且特别涉及自动判定用于无线电话拨打的呼叫的合适始发方案。
背景技术
在陆线电话系统中,电话呼叫就是一次电话呼叫。如果呼叫接通,它就接通,如果它没有接通,用户就稍后再次呼叫。
而且,陆线电话的网络或服务的供应商并没有尝试为系统进行优化以进一步增加呼叫始发可以接通的概率。
一些设备具有自动重拨功能。如果发送传真机向接收传真机进行呼叫,而接收传真机正忙,那么,发送传真机就以逐渐增长的间隔再次进行尝试呼叫,直到呼叫接通或达到预定的最大尝试次数。尝试访问因特网服务供应商的家庭计算机如果第一次也没有接通,它也会做出类似的重复尝试。在陆线电话系统中不可能有更灵活的方法。电话呼叫就是一次电话呼叫。

发明内容
本发明的申请者注意到在无线电话系统中,不是所有的电话呼叫都是相同的,并且也不是所有的网络都相同。例如,某些网络具有码分多址(“CDMA”)和高级移动电话服务(“AMPS”)系统能力,而其他系统仅具有CDMA系统。另外,与不同的网络相比,一个网络可能或多或少地会返回特定的呼叫始发失败指示,例如REORDER或INTERCEPT。而且,不同的网络在始发失败指示时间周期方面也总是各不相同,该周期是指从呼叫始发的时间到当移动电话从网络接收到始发失败指示时的时间周期。
另一种必须考虑的变量就是呼叫类型。例如,常规的呼叫可能默认在30秒内最多4次重拨,而紧急电话911需要进行不间断的重拨直到呼叫成功连接(或电池耗尽)。
为了优化不同呼叫类型的始发方案,就将呼叫计划与每个这样的呼叫类型关联。呼叫类型仅是一起分组的呼叫字符串的子集,并且与特定的预定呼叫类型关联。预定呼叫类型的实例有语音、紧急、数据、传真、分组、OTASP(空中服务供应)、测试(Markov,回送),以及SMS(短消息服务)。
每个这样的呼叫类型存在一组拨号字符串与之关联。例如,拨号字符串子集{″911″,″*911″,″#911″}可以与紧急呼叫类型关联。换句话说,在该组中的任意拨号字符串可以认为是“紧急”类型,而不在该组中的拨号字符串不认为是“紧急”类。
对于无线电话用户来说可以使用不同的无线服务供应商。这些供应商以不同的价格为无线电话用户提供不同的服务,并且这些服务和价格取决于所拨打的电话号码。这样,无线电话用户可以依据所拨打的电话号码(或至少电话号码的类型)定制一个呼叫始发方案。“呼叫始发方案”是一种有关尝试多少次重拨、使用哪个服务供应商,使用哪种服务模式(例如,码分多址对频分多址)等的判定。
表1示出一种较佳的始发计划表。如图1所示,呼叫始发计划表的每条记录与具有呼叫始发计划的一种呼叫类型和/或拨号字符串关联。呼叫始发计划保留有实施相关联呼叫类型和/或拨号字符串始发处理所需的所有信息。
表2是如表1所示的字段的解释。
表3是始发计划表实例。注意该表是自上而下进行搜索。在当特定的呼叫类型/拨号字符串可以与多个表项匹配的情况下,将把从顶部始发的第一个表项规定为始发计划。
如下所述,始发计划可以使用一个表或一组表来详细说明。在这样的表中。每个表项说明了与特定呼叫类型关联的始发计划变量。或者,始发计划变量可以由脚本来替代(参照图3)。
表1-始发计划表

表2-字段解释

表3-始发计划实例表



图1是根据本发明的方法的流程2是在图1方法中使用的表。
图3是在图1方法中使用的脚本。
图4是示出图1方法中使用类型的一对表。
图5是根据本发明的电话框图。
图6示出在图4中使用的一些类型。
图7示出包括在图1中的呼叫始发方案的一些元素。
图8是根据本发明的失败处理程序框图。
图9示出由图8程序处理的失败的一些原因。
具体实施例方式
图1示出根据本发明用于始发无线电话呼叫的方法(100)的流程图。第一呼叫始发方案至少与第一可能的电话号码关联(102),并且第二呼叫始发方案至少与第二可能的电话号码关联(102)。只要方便,每种方案可以与许多电话号码关联,并且只要方便,可以存在许多种方案。但每个电话号码仅与一种方案关联。表示每种关联的数据存储(104)在无线电话中。
短语“无线电话”在此是广义概念,并且是指能够在无线电话网络上拨打呼叫的任意装置。因而,它并不局限于传统的无线电话,也包括无线传真机、无线计算机诸如此类的装置。
这样,通过在键盘上按下一系列按键,就将电话号码输入给无线电话(106)。该号码预先与一种呼叫始发方案关联。因此,无线电话就确定与刚输入的电话号码预先关联的方案(108)。随后,电话根据关联的方案拨打呼叫(110)。
关联处理(102)可以是直接关联,或它可以分两部分实现。在后者情况中,首先将电话号码集合成类型(112),并且随后为每种类型关联一种呼叫始发方案(114)。在这种情况下,需要至少将第一组多个号码集成在第一类型,第二组多个号码集成为第二类型。随后,第一类型与第一呼叫始发方案关联,第二类型与第二呼叫始发方案关联。如果需要可以采用附加类型。
将电话号码输入到无线电话中,并随后分配类型是可能的。然而,在无线电话内部进行分组(116)并将表示分组的数据载入到电话中(118),通常会更加方便。这允许为多个无线服务供应商制造单一模式的电话。每个服务供应商可以加载最适合其自身目的的数据。
图2是图1方法中使用的表(200)。每行最左边单元格示出各个电话号码。其余的单元格指示了与该电话号码关联的呼叫始发方案的元素。它包括这些内容如如果第一次拨打没有接通,所要进行的默认重拨的次数,是否要强制使用高级移动电话服务(AMPS),如果电话对服务的请求被截断,电话是否要等待服务,等等。如果直接服务被拒绝,呼叫就被“截断”,但会产生该服务不久就可用的指示。这样,截断就与拒绝有所不同,在于在可预见的将来对被拒绝的呼叫将不提供服务。这些元素仅是实例,如表格锯齿状右边缘所示,也可以使用其他的元素。表格的锯齿状底边指示可以使用附加电话号码。所示的号码仅是示例。
图3是图1方法中使用的脚本(300)。除了尝试穷举列出每个可能的电话号码外,脚本(计算机程序)还获得有关电话号码的最高有效位(MSD)或其他信息,并且为其分配类型,或设定呼叫始发方案的元素(如最后行所示)。如果需要,可以将脚本和查找表结合使用。
图4是示出图1方法中使用类型的一对表(400)。第一个表(402)将每个号码与一种类型关联。第二个表(404)将每种类型与一种呼叫始发方案关联。例如,无线服务供应商可以具有空中服务供应(OTASP)号码。这个号码是无线电话的新购买者从无线服务供应商呼叫获得服务的号码。用于这种呼叫的呼叫始发方案(多少次默认重拨、是否强制AMPS等等)通常与用于传统呼叫的方案有所不同。如果OTASP号码是非标准的(NSOTASP),其方案还是不同的。服务供应商可以具有几个OTASP号码,以便允许几个新消费者同时登记。这对于这些号码的每个号码仅与类型“OTASP”关联是很方便的。这对每个电话号码就避免了需要重复与OTASP类型关联的呼叫始发方案的每个元素。
图5是根据本发明的电话(500)的框图。传统的电话(502)通过适配器接收数据(504)。这些数据代表了查找表或电话号码的分组类型。这些数据存储在非易失性存储器(508)中。它们可以包括查找表(510)、分组号码的电话簿(512)或两者都有。
图6示出图4中使用的一些类型(600)。这些类型包括紧急(602)、空中服务供应(OTASP)(604)、非标准空中服务供应(NSOTASP)(606)、语音(608)以及数据(610)。除所示的类型外还可以使用其他类型,或可以使用其他类型代替所示的类型。
图7示出图1中包括的呼叫始发方案的一些元素(700)。这些元素包括如果第一次呼叫没有接通,要进行的默认重拨次数(702),服务的较佳模式(704)、如果服务请求被截断,电话是否要等待服务(706)等等。服务“模式”包括这些内容如所使用的技术(码分多址--CDMA、时分多址--TDMA、高级移动电话服务--AMPS等等)、工作频率(蜂窝--800MHz、个人通信系统-PCS-1900MHz等等)以及类似的因素。
图8是根据本发明的失败处理程序框图(800)。当在拨打电话号码后获得服务失败(802),电话就判定失败的原因,并且调节随后有关该原因始发尝试的至少一种元素。
图9示出由图8程序处理的失败的一些原因(900)。如果呼叫被截断(902),那么,用于数据呼叫的典型呼叫始发方案将在较短的延时之后以相同的模式用于重拨。用于紧急呼叫的典型呼叫始发方案将用于使用不同模式的直接呼叫。然而,如果原因在于衰落的话(904),那么,用于所有呼叫类型的典型方案将暂时延时,并再次尝试。如果原因并不是出自消费者方面(906),那么,在所有的方案中都需要到不同服务供应商的转换。这些方案仅是实例,并且可以使用其他方案。同样,上述失败的原因也仅是示例,并且除这些原因外还可以有其他原因,或可以使用其他原因代替这些原因。
工业应用本发明能在工业上使用,并且无论何时需要将拨打号码与呼叫始发方案关联时,都可以实现和使用本发明。在此所示的设备和方法的彼此独立和分开的各个部分可以都是完全传统的部分,本发明所要求的权利是它们的结合。
虽然,已经对设备和方法的各种模式进行了描述,但本发明的真正精神和范畴并不局限于此,而仅受下述权利要求及其等价物的制约,并且本发明就这样要求。
权利要求
1.一种用于始发无线电话呼叫的方法,其特征在于,所述方法包括(a)关联(102)(1)至少将第一呼叫始发方案与至少第一可能要拨打电话号码关联;和(2)至少将第二呼叫始发方案与至少第二可能要拨打电话号码关联;(b)将代表关联的数据存储在无线电话中(104);(c)在所述无线电话中输入一个电话号码(106);(d)判定与所输入的电话号码关联的呼叫始发方案(108);和(e)根据所关联的呼叫始发方案拨打呼叫(110)。
2.如权利要求1所述的方法,其特征在于,所述数据包括查找表。
3.如权利要求1所述的方法,其特征在于,所述数据包括脚本(122)。
4.如权利要求1所述的方法,其特征在于,所述关联包括(a)分组(112)(1)将至少第一组多个电话号码分成为第一类型;和(2)将至少第二组多个电话号码分成为第二类型;和(b)关联(114)(1)将所述第一呼叫始发方案与所述第一类型关联;并且(2)将所述第二呼叫始发方案与所述第二类型关联。
5.如权利要求4所述的方法,其特征在于,(a)分组在所述无线电话外部发生(116);并且(b)代表分组的数据载入到所述电话中(118)。
6.如权利要求4所述的方法,其特征在于,至少一种类型是下述类型中的至少一种(a)紧急(602);(b)标准空中服务供应(604);(c)非标准空中服务供应(606);(d)语音(608);和(e)数据(610)。
7.如权利要求4所述的方法,其特征在于,所述方法包括在所述无线电话的电话簿(512)中存储已分组的电话号码。
8.如权利要求1所述的方法,其特征在于,每个呼叫始发方案包括至少一种下述元素(a)如果第一次始发尝试失败,要尝试的始发次数(702);(b)服务的较佳模式(704);和(c)如果服务不能立刻可用是否等待服务(706)。
9.如权利要求1所述的方法,其特征在于,用于至少一种呼叫始发方案的所述方法包括(a)判定所失败的始发尝试失败的原因(804);并且(b)用于调整(806)有关所述原因的至少一次后续始发尝试的至少一个元素的装置。
10.如权利要求9所述的方法,其特征在于,至少一种呼叫始发方案的所述原因包括至少一种下述事件(a)截断(902);(b)衰落(904);和(c)非消费者(906)。
11.用于始发无线电话呼叫的设备,其特征在于,所述设备包括(a)用于关联(102)的装置(1)至少将第一呼叫始发方案与至少第一可能要拨打电话号码关联;和(2)至少将第二呼叫始发方案与至少第二可能要拨打电话号码关联;(b)用于将代表关联的数据存储在无线电话中(104)的装置;(c)用于在所述无线电话中输入一个电话号码(106)的装置;(d)用于判定与所输入的电话号码关联的呼叫始发方案(108)的装置;和(e)用于根据所关联的呼叫始发方案拨打呼叫(110)的装置。
12.如权利要求11所述的设备,其特征在于,所述数据包括查找表(120)。
13.如权利要求11所述的设备,其特征在于,所述数据包括脚本(122)。
14.如权利要求11所述的设备,其特征在于,用于所述关联的装置包括(a)用于分组(112)的装置(1)将至少第一组多个电话号码分成为第一类型;和(2)将至少第二组多个电话号码分成为第二类型;和(b)用于关联(114)的装置(1)将所述第一呼叫始发方案与所述第一类型关联;并且(2)将所述第二呼叫始发方案与所述第二类型关联。
15.如权利要求14所述的设备,其特征在于,(a)分组在所述无线电话外部发生(116);并且(b)代表分组的数据载入到所述电话中(118)。
16.如权利要求14所述的设备,其特征在于,至少一种类型是下述类型中的至少一种(a)紧急(602);(b)标准空中服务供应(604);(c)非标准空中服务供应(606);(d)语音(608);和(e)数据(610)。
17.如权利要求14所述的设备,其特征在于,所述设备包括在所述无线电话的电话簿(512)中存储已分组的电话号码。
18.如权利要求11所述的设备,其特征在于,每个呼叫始发方案包括至少一种下述元素(a)如果第一次始发尝试失败,要尝试的始发次数(702);(b)服务的较佳模式(704);和(c)如果服务不能立刻可用是否等待服务(706)。
19.如权利要求11所述的设备,其特征在于,用于至少一种呼叫始发方案的所述设备包括(a)用于判定所失败的始发尝试失败原因(804)的装置;以及(b)调整(806)有关所述原因的至少一次后续始发尝试的至少一个元素。
20.如权利要求19所述的设备,其特征在于,至少一种呼叫始发方案的所述原因包括至少一种下述事件(a)截断(902);(b)衰落(904);和(c)非消费者(906)。
全文摘要
一种用于无线电话的呼叫始发方案(300)列出默认重拨次数以产生较佳的模式(模拟、数字等等)(304),等等。无线电话可以拨打的每个电话与一种方案关联(102),并且代表这种关联(104)的数据存储在电话中。当通过在键盘上按下一系列按键将号码输入电话(106)时,电话判定(108)与该号码关联的方案,并根据该方案拨打呼叫(110)。
文档编号H04M1/2745GK1399848SQ00813900
公开日2003年2月26日 申请日期2000年10月4日 优先权日1999年10月5日
发明者R·库珀 申请人:高通股份有限公司
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1