专利名称：用于把ivr应用程序下载到设备、执行它并上传用户的响应的方法和系统的制作方法
技术领域：
本发明涉及一种通信方法和系统。
向电话系统的用户提供交互式语音应答应用程序(application)是已知的。这种交互式语音应答(IVR)应用程序被例如呼叫中心用作一种从呼叫者获得信息和/或把呼叫路由到正确的人的方法。
早期语音应答单元(VRU)提供了专用IVR功能(通过电话键盘的按键按压进行的基本菜单交互和选项选择)，但是与运营商的其他系统相分离。由于集成系统的出现，VRU被逐渐停止采用。为IVR开发了标记语言，以使应用程序的开发更简单并且实现功能的分布，例如，来自朗讯公司的用于电话交互的PML(AT&T PhoneWeb)，VoxML，即摩托罗拉公司的面向语音的标记语言，以及VoiceXML，它们使语音标记与万维网的发展相一致。
VoiceXML以标准化的标记语言(XML)来描述IVR应用程序，并且利用了面向web的内容和基于web的架构(分布、内容创建、可剪裁性、转码、可伸缩性)的优点。VoiceXML对IVR程序员屏蔽了电话API、TTS(文本到语音)和ASR(自动语音识别)技术。标准IVR架构VoiceXML IVR系统的主要部件在
图1中被示出。用户通过电话100或PSTN终端经由公共交换电话网(PSTN)102、通过电话网关106连接到VoiceXML解释器104。VoiceXML解释器104基于由VoiceXML应用服务器108所提供的VoiceXML脚本的指令来引导与呼叫者的呼叫交互。解释器104天然地理解按键音(DTMF)输入，并且可以管理预先记录的音频提示或文件。为了增强功能，解释器104还可以调用诸如TTS(文本到语音)110和ASR(自动语音识别)112之类的语音技术。VoiceXML解释器104通过web协议(HTTP)114与本地或远程VoiceXML应用服务器108通信。VoiceXML应用服务器108传送应用程序，包括VoiceXML文本页和二进制音频文件。应用服务器108接收语音、按键音和来自解释器104的记录的输入。VoiceXML应用服务器108可以查询企业中间件和数据库系统116来向用户动态地驱动VoiceXML。
部件的分布使得后端应用程序驻留在因特网上的“别处”对于VoiceXML IVR架构而言是常见的。这些后端应用程序处理特定应用的知识和约束，例如用于信用卡支付的金融系统、航线飞行时间表和可用性、剧院检票等。因此，对以VoiceXML来编程前端用户接口屏蔽了领域知识。
经常有这样的情况，即在PSTN上存在前端VoiceXML解释器，其通过因特网(例如经由基于IP的安全http，即https)与供应商组织的后端VoiceXML服务器相连。在任何一个时刻，前端解释器将具有足够的IVR数据页(即VoiceXML)来支持与一个给定呼叫者(或多个呼叫者)的下一组交互。按照需要，解释器可以被编程以调用号码检查例程、TTS模块、语音识别模块，或者甚至把呼叫者转接给人工操作员。此外，解释器可以向VoiceXML服务器请求更多页，该服务器将实时产生这些页，从而必要时与后端应用服务器交换信息。
存在由用于电话用户的IVR所支持的增长数量的自动业务。这些例如包括谈论黄页和其他搜索业务，语音消息传送，气象报告，银行业务，旅行新闻，火车或运输时间表，飞行信息和预订，呼叫中心(客户帮助热线等)，足球比分，聊天热线，音乐下载，铃声下载，游戏，设置告警/报警呼叫，设置呼叫改向。所有这些应用通过服务器访问数据库并调用所需的数据和消息来实时地运行。在世界的某些地区，对这些业务的访问是较穷的人得不到的，因为对使用电话的计费是基于呼叫的长度这一事实，该长度对于IVR应用程序的用户而言可能相对较长。呼叫的费用对许多人而言是力所不及的。
因此，本发明的目的是对已知技术进行改进。
根据本发明的第一方面，提供一种通信方法，该通信方法包括把交互式语音应答应用程序下载到设备，接收执行交互式语音应答应用程序的用户命令，响应于该命令而执行交互式语音应答应用程序，创建包括用户对该交互式语音应答应用程序的响应的文件，以及上传该文件。
根据本发明的第二方面，提供一种通信系统，该通信系统包括网关和用于与该网关通信的设备，该网关用于把交互式语音应答应用程序下载到设备，以及该设备用于接收执行交互式语音应答应用程序的用户命令，用于响应于该命令而执行交互式语音应答应用程序，用于创建包括用户对该交互式语音应答应用程序的响应的文件，以及用于把该文件上传到该网关。
由于本发明，有可能提供一种允许用户访问交互式语音应答应用程序而不招致昂贵的通话费、但同时可以获得在交互式语音应答应用系统内固有的优点的通信方法和系统。
IVR业务的方案对于不能负担得起在线电话使用的费用的人们来说将非常有用。PSTN用户也对离网访问这些业务感兴趣。
本发明提供一种实现在低级终端上使用IVR应用程序的方法。IVR应用程序可以涉及过长且昂贵的电话呼叫，以便获得正确的信息或者进行期望的事务。通过用合适的标记语言来格式化这种IVR应用程序，用户可以在他们空闲时离线使用并采用这种业务，从而发展对为电话用户所提供的宽范围的现有业务的异步访问。于是，在下一次连接(docking)机会，所完成的会话可以被中继给原始业务供应商以便完成该事务。与业务的交互可以被执行为一系列的阶段，其中错误或成功事务的最终确认被返回给用户。
优选地，该设备是数据卡或便携式手机(handset)。该交互式语音应答应用程序被下载到用户的手机上，或者被下载到供手机中使用的数据卡上，并且用户可以离线执行该交互式语音应答应用程序，而不必招致任何通话费。
有利地，该交互式语音应答应用程序包括数据库元件。当用户离线时，该交互式语音应答应用程序将不可以访问通常的后端业务和数据库，所述后端业务和数据库在对交互式语音应答应用程序的电话访问期间通常将是可用的。因此，在由用户下载的交互式语音应答应用程序内提供数据库元件是有利的，该数据库元件在其内部包括在对其进行离线访问时由交互式语音应答应用程序将需要的功能和数据。
在优选实施例中，执行交互式语音应答应用程序的步骤包括错误检查和纠正。在对交互式语音应答应用程序的电话访问期间，存在用于对用户的响应进行错误检查的协议。例如，如果交互式语音应答应用程序要求从1到3的输入，而用户按下了电话上的按键4，那么产生错误消息，并且交互式语音应答应用程序的流程必须改变以考虑该错误。当交互式语音应答应用程序由用户在将其下载到他们的设备之后离线访问时，正常的错误协议不是可用的。这会导致用户离线出错的情况，因此期望的是在用户正在执行交互式语音应答应用程序时在设备上提供某种级别的错误检查和纠正。
有利地，该通信方法还包括在上传文件后处理文件的步骤。处理文件的步骤包括错误检查和纠正。一旦包含用户对交互式语音应答应用程序的响应的文件被上传，网关就处理该文件。这允许网关检查上传的文件中的错误，并且如有可能就纠正该错误。如果网关检测到它不能纠正的错误，那么错误检查包括创建交互式语音应答子应用程序以用于下载到设备。这具有的优点在于，当检测到错误时，不是再次重新开始整个过程，而是网关将创建一个只与该错误相关的子应用程序以用于返回给用户。
优选地，该通信方法还包括把交互式语音应答子应用程序下载到设备，接收执行交互式语音应答子应用程序的用户命令，响应于该命令而执行交互式语音应答子应用程序，创建包括用户对该交互式语音应答子应用程序的响应的第二文件，以及上传该第二文件。
现在将参考附图仅通过例子来描述本发明的实施例，其中图1是现有技术的系统的示意图，图2是通信系统的第一实施例的示意图，图3是通信系统的第二实施例的示意图，图4是通信系统的第三实施例的示意图，以及图5是通信系统的第四实施例的示意图。
上面详细描述了作为现有技术的系统的图1。
所提出的供本申请的通信系统使用的基础结构集中在对于生活条件差的人们而言内容的存储转发供应以及以异步方式的个人通信。用户已经断开移动手机来与在数据卡上存储的语音消息或交互式音频程序进行交互。这些数据卡可以周期性地与具有因特网访问的计算机连接，以刷新数据内容，下载和上传新的消息、交互式程序、或者所存储的对该程序的响应。
下载到由给定的用户(或用户组)使用的便携式设备的存储器的内容程序的选择是由每个用户的用户简档确定的，并且最初是由用户人口统计状况(demographics)、他们的兴趣和他们的选择加入/选择退出(opt-in/opt-out)异常确定的。使用因特网在内容供应商和基础结构的分发中心之间分发内容。使用在分发中心和区域内容中心之间的因特网连接来传送用户之间的语音消息。
使用语音交互式媒体格式(VIMF)来描述交互式程序。VIMF是XML标记语言族中的一种，并且具有与VoiceXML和较早的IVR语言(VoxML、PML)相同的许多结构。VIMF描述了对象如何在客户端手机上在视觉和听觉上呈现。VIMF程序提供音频提示，它们捕获用于控制导航分支的按键按压以及响应于程序中的问题的用户响应(按键按压和语音记录)。
这些“VIMF程序响应”也以定义的格式被存储在手机中的用户数据卡上，键控原始交互式程序中的对象。用户可以重放该程序来检查他们的响应，并在手机上进行改变或者纠正。在该数据卡的下一次因特网连接时，这些响应被随后返回给内容程序供应商或者他们的代理商，例如业务呼叫中心。
通过使用来源于VoiceXML(用于IVR的普及的标记语言)的标记语言，VoiceXML应用程序可以容易地被VIMF模拟或转码成VIMF。较早的IVR语言(例如VoxML)也可以类似地被转码。在IVR架构和标记语言允许的情况下，存在利用不同机制来使用户能够获得对现有IVR应用程序和业务的访问的许多机会。
不同的方法是必要的，这取决于PSTN业务的级别和与低级设备交互的网关的集成、以及适宜PSTN和业务系统的访问的程度。
第一种方法在图2中被示出，它是使用从网关200的自动呼出机制，该网关通过PSTN 202访问IVR应用程序。该网关应用程序必须模拟正常的PSTN用户；从而产生按键音并以IVR应用程序所期望的速度传送所存储的语音片段。(基本上这里存在两个彼此交谈的IVR应用程序，其中网关200带头)。
图2的系统包括用于与网关200通信的设备204，该网关200把交互式语音应答应用程序206下载到设备204。该设备204在离线时响应于用户命令而执行交互式语音应答应用程序206，并且创建包括用户对交互式语音应答应用程序206的响应的文件208。当用户下一次连接到网关200时，文件208被上传到网关200。网关200经由PSTN 202与IVR前端210通信，该IVR前端210再被连接到IVR服务器212。
这种配置的优点在于，不需要对IVR应用程序进行任何改变，并且PSTN和IVR业务供应商对最终用户进行处理，好象它们是正常的PSTN用户一样。缺点在于该解决方案例如相对于用户错误不大鲁棒(robust)，并且可能较慢。另外，实现在PSTN用户和域后端系统之间密切对话的更复杂IVR应用程序更难以模拟。
第二种方法在图3中被示出，它是实现一种将网关200基于IP连接到PSTN 202、再直接连接到为IVR前端应用程序服务的基础PSTN路由器的机制。该方法的一个优点在于，在网关200和前端路由器210之间的交互是数据，并且因此远远快于语音或DTMF(按键音)。此外，对话更鲁棒，其是无呼叫遗漏的分组交换，并且因此更适合于机对机的交互。它避免了从网关200到PSTN 202的PSTN呼叫成本，并且提供了从网关200到PSTN用户可用的许多IVR应用程序的一个接入点。
第三种方法在图4中被示出，它是使用接管IVR前端的网关200并处理为IVR前端服务的各种VoiceXML服务器212。本质上，这里业务供应商和他们的IVR应用程序作者合作产生可以由用户异步运行的应用程序的“面向批处理”的第二VIMF应用版本。该系统具有多个优点，包括正在提供网关200的组织直接与供应商公司交涉并且不涉及PSTN的事实。业务供应商被给予早访问新的较穷的市场部分的特权。
第四种方法在图5中被示出，它是提供一种直接与供应商公司的后端应用程序214连接的IP网关200。该方法的优点在于，VoiceXML被完全地绕过并且应用程序作为VIMF为用户呈现，以及数据事务是以由每个供应商所需要的文件格式。该方法的缺点是需要对复杂且敏感的或者安全的后端系统进行深度访问。
适用于所有四种可能的方法的另外的优点在于，将较穷的用户包括在PSTN用户可用的业务范围中，对于IVR业务供应商来说具有大大增加的潜在市场，并且与IVR业务的异步交互向用户提供了对再访问并修正选项和他们的响应的较大控制。
需要另外的机制来桥接在异步VIMF应用程序和异步IVR应用程序之间的划分，包括重新制定IVR应用程序以便以批处理方式有效地操作，支持在基础结构中的会话管理，以实现对于基于PSTN的供应商是透明的阶段化交互和IVR响应的捕获以及以结构化方式标记成VIMF以便支持对失败事务的纠正和重新提交。
如上面所解释的，存在选择的范围来将IVR应用程序带到不能负担得起招致在经由PSTN访问IVR时固有的通话费的离线用户的世界。所述机会在IVR应用程序传送链中利害关系者需要的集成水平(商业协定)方面不同。最低的集成水平包括“代理”，其可以模拟人类PSTN用户来代表较穷的用户与基于PSTN的IVR系统进行同步交换。第二个建议包括直接到在支持IVR前端的“另一侧”的PSTN中的数据连接，使用了VoiceXML来与各种IVR应用程序供应商通过PSTN路由机制进行交互。第三个建议包括在网关和每个IVR业务供应商之间单独地建立专用的数据交互，在业务供应商的控制下使用直接到VoiceXML服务器上(或类似的服务器)的连接。第四个建议需要高度的集成并且与业务供应商协同工作。网关将把“本地”事务传送到业务供应商的各种事务处理后端应用程序(业务供应商可以可选地决定以VIMF提供业务)。
向较穷的用户提供基于PSTN的IVR应用程序的选择范围包括可能使用代理。该代理可以是一个可信的人，其被雇用以取得如在用户的VIMF程序响应中所定义的用户需求并且执行IVR电话呼叫，从而报告任何问题或成功完成返回给用户。该人类助理实际上充当IVR抄写者。可选择地，该代理可以是由网关运行的自动呼出机构(例如“机器人”呼叫者)。
对于充当代理的人来说，该过程如下该代理必须向用户引出感兴趣的IVR应用程序的知识(该过程稍后进行描述)，建立可以离线从用户引出所需输入的VIMF程序(Prog1)，代理商将Prog1分发给较穷的用户，该代理商整理对Prog1的VIMF程序响应，该代理回放该响应，并且转录它们(用于导航和查询响应的按键按压将由VIMF应用程序记录为按压的按键，即在定义的“VIMF程序响应”格式中的“4”，用VIMF程序Prog1中的引出对象来标记)，该代理唤起IVR业务，并且将用户与应用程序的交互复制给IVR并记录所有反馈，以及为原始用户准备VIMF格式的程序响应。
使用人类代理的优点是，人可以容易地处理电话呼叫的不测事件，并且在具有IVR的电话呼叫期间可能的提示/响应。(例如，每周的电影院时间和电影改变)。明显的缺点是转录用户与每个应用程序的交互以及把这些通过电话重复给IVR所需的时间和成本。它可能是一项非常单调的工作，并且人们易于出错。另一方面，这可以提供新的就业。
对于充当代理的自动系统来说，必须遵循类似的过程引出IVR应用程序的知识，从而密切注意IVR提示和响应窗口的定时并运用所有可能的选项/路径(该过程稍后进行描述)，建立VIMF程序来异步地向用户提供业务(Prog1)，代理商如前所述分发Prog1，该代理商整理对Prog1的响应，该“机器人”代理从VIMF程序响应文件中提取用户响应，使得它们与在IVR交互期间要填充的输入数据时间间隙一致，该代理唤起IVR业务，并且在适当的时间以适当的延迟来重放用户的响应以导航和响应IVR查询(发送适当的DTMF音来代替最终用户的按键按压，在IVR中需要的地方播放由Prog1捕获的来自用户的原始语音，并且使用关于提示和定时的知识来同步响应的呈现)，并且记录所有的IVR反馈，以及准备VIMF格式的程序响应文件以发送回给原始用户。
使用自动代理的优点主要是可靠、精确、耐久，并且自动的代理不会感到无聊，如果需要的话可以整夜工作而不出错。主要的缺点是自动代理不能处理没有在其中预先编程的异常。
为了使自动代理能够处理对IVR的呼出，它需要具有将由IVR需要的交互序列的完整知识，以便输入用户所选的选项(按键按压/DTMF)和所作的响应(按键按压或语音)。特别地，这意味着具有来自IVR的提示的定时的信息，以及关于为了完成用户事务而将经历的交互的分支的响应(按键按压和语音)的定时约束。它也意味着知道IVR应用程序的有效用户输入的允许范围或集合。
建立IVR的模型可以通过在所有给定的接合点试验所有的IVR选项、识别每个选项随后的影响等等、直到穷尽所有的分支来进行。类似地，还将有可能找出用于回答语音输入的提示的最大(和最小)语音持续时间。这种信息将用于构造具有内置的范围和定时约束的VIMF程序，并且对于由自动代理稍后使用IVR是必需的。实际上，代理已经通过运用IVR应用程序而得到了“训练”。
如果经由PSTN到各个应用供应商的数据连接被使用，那么如较早所述，VoiceXML的使用对应用开发者和应用供应商隐藏了导航IVR所需的文本到语音以及任何自动的语音识别技术。只有与应用供应商有关的数据需要返回给他们，例如，“用户希望看今晚放映的四部电影中的什么电影？他们需要多少票并且是哪一类型的？他们将如何付费？”。VIMF应用程序可以获得来自用户的各种响应，这些响应被需要以建立适合于作为用户数据项传送到后端VoiveXML服务器的响应文件。给定在PSTN处必需协议的知识、以及基于VoiceXML的数据格式的知识和VoiveXML服务器所需的协议，有可能通过PSTN路由数据事务并且直接路由到所选的业务供应商。
例如，HTTP(或安全HTTPS)可以是合适的传输协议。实际上，与每个业务供应商建立协作以设计他们的IVR应用程序的批量版本。这可能对于编程而言是简单的，假定许多业务供应商已经为他们的客户提供了可选进入点，即经由连接到他们的后端域系统的在线因特网网页预订系统以及IVR电话访问。
该水平的集成需要在PSTN处的内部协议的知识以及业务供应商所使用的协议和数据格式(这些数据格式可以是基于VoiceXML的，或许使用HTTP作为传输协议)。与PSTN的该水平的集成可能是难以实现的，除非存在商业利益(即可能的收入)。获得来自业务供应商的数据格式(基本上是VoiceXML源代码)可能不是问题，因为如果更多的用户能够访问他们的业务，他们一定会获益。
一个到供应商的可选数据连接是经由VoiceXML。上面的改进是对与每个IVR业务供应商的因特网连接直接独立地工作，从而完全省略了PSTN。在这种方法中，使用业务的VoiceXML(源)描述以便产生相应的VIMF程序。VIMF程序照常被使用(如上面所限定的)，并且响应被传递回到适当的网关。该网关接着使用合适的数据格式(例如VoiceXML)和协议(例如HTTP)把该响应传递给VoiceXML服务器。任何来自VoiceXML服务器的打算供用户使用的响应将返回到网关，并且可以容易地被转换成“VIMF程序响应”以用于转发给用户。
可选择地，到供应商的数据连接可以使用本地数据格式。进一步扩展在上一段中的建议，网关有可能与以高水平的集成的IVR业务供应商、与来自网关或来自创建了对于用户而言最佳的VIMF程序的IVR业务供应商的应用程序开发者互操作。不存在中间IVR语言。当使用该程序时，所得到的事务被直接馈送到业务供应商的网络中进行处理。对于客户的任何响应都作为VIMF程序响应而产生。
上面描述的数据发送方法的缺点在于，每个将被提供的新IVR业务是一个定制的设计任务，其将需要来自网关的编程资源。该最佳解决方案将需要IVR应用程序的最小的重新设计(例如自动VIMF程序生成器，给定VoiceXML源代码的话)以及新接口和网关的最小设计。
在上面概述的所有方法中，问题仍然是在同步交互和对话(例如以VoiceXML描述的)与异步交互(如以VIMF所捕获)之间的映射。关键问题之一是在IVR会话期间的错误处理和错误恢复。同步交互的主要优点是能够快速地检测到错误并且立即用最终用户或客户来纠正他们。这在异步VIMF程序中未必是可能的，尤其是对于只在应用服务器已经对另一后端系统作了呼出时识别的错误(即信用卡检查)。然而，一些输入输出有效性检查可以以VIMF来编程，例如以检查有效键入的数字输入或者用户输入的数字落在预定的范围内，或者用户对问题口头回答的记录持续时间落在预期的持续时间的范围内。
设备到IVR的网关可以支持错误纠正的一种方式是通过记录错误报告(例如“抱歉，卡号是不正确的”)并以使用户能够理解和纠正错误的形式将错误报告提供回给用户(这些报告必须是口头的，因此如果IVR不提供语音，那么可以由VIMF程序生成器使用文本到语音)。
可以通过向用户提供他们所作的响应来帮助用户进行错误纠正，网关或代理商已经向被IVR检测为错误的原始VIMF Prog1添加了那些用户响应的额外标记。(用户可以在他们的手机上重放VIMF交互式程序，从而检查他们先前对该程序所作的响应并改变它们，一直到他们的数据卡被提供以用于连接到因特网接入点的时刻)。来自用户的对这些VIMF“错误”报告的随后的纠正响应接着可以被插回到响应的序列中。网关将在与业务供应商的第二同步IVR交互中再次使用这些用户响应。(多阶段的错误报告、错误纠正、IVR重新提交会话可能是必须的，并且由系统支持)。
一旦完成了成功的IVR会话，来自IVR系统的确认可以被添加到所存储的用户VIMF程序响应文件。这随后可以通过网关或者代理被返回给用户。用户随后将接收到他们的事务的最终记录(如果希望的话可以重放)以及来自IVR业务供应商的确认。
将帮助使用IVR应用程序的另一个建议(批处理方式)是，IVR业务的供应商重新制定他们的接口，使得即使存在错误他们也允许交互序列继续进行而不是阻塞任何进一步的前进。例如，如果与业务的一个完整事务需要在三种场合的无约束输入(即不能在VIMF内进行范围检查，并且因此不将在手机上进行检查)，并且用户在第一字段中发生了错误，IVR系统可以提供错误注释并且中止该事务。用户将不知道在其他第二和第三输入字段中的响应是否是正确的，直到他的/她的响应被重新提交(假设在第二次尝试中第一字段是正确的)。该情景突出了IVR系统通常被设计用于同步交互。如果IVR业务供应商到事务结束自始至终都允许错误(尽可能)，该标准IVR方法可以容易地被补救。以这种方式，当用户接收到从业务供应商返回的第一次错误响应时，用户将知道在第一次事务过程中他们的大多数错误-有希望的是当他们提交他们的第一次重试时他们将使所有的输入正确。
可以桥接在异步和同步系统之间的划分的另一种方式是通过在网关(或者作为代理的另一元件)处使用会话管理器。该会话管理器可以用于帮助使用户容易地通过完成与业务供应商的一个事务所需的多个阶段的交互。该会话管理器可以负责维护对来自IVR的提示的正确的用户响应，直到用户重试时提供了纠正的响应，在整个会话太大以至于不能存储在用户手机上的情况下，建立构成与IVR的完整事务的响应的会话，如果用户对于特定的业务有重复的问题，那么在传送给用户的VIMF程序中插入提示或帮助，以及逐步升级错误恢复策略，例如逐步回扫IVR步骤，直到用户提供有效的输入。
存在宽范围的在线IVR应用，其可以通过为阶段化手机访问或批处理方式使用(例如用于航线上的移动用户的PDA)所提出的机制来呈现。显然，一些IVR应用，比如其中只需要选择地区的气象呼叫热线更可预测并且需要更少的后端呼叫，所以比其它更复杂的IVR应用(比如航线的自动票务预订系统)更易于以批量/离线方式来复制。虽然主要的直接目的是为贫穷人士提供访问范围增长的电话业务的途径，但是在一些情况下较富有的用户群对业务的离网使用可能也是引人注目的。
权利要求
1.一种通信方法，包括把交互式语音应答应用程序(206)下载到设备(204)上，接收执行交互式语音应答应用程序(206)的用户命令，响应于该命令而执行交互式语音应答应用程序(206)，创建包括用户对交互式语音应答应用程序(206)的响应的文件(208)，以及上传该文件。
2.根据权利要求1的方法，其中该设备是数据卡。
3.根据权利要求1的方法，其中该设备是便携式手机。
4.根据权利要求1、2或3的方法，其中该交互式语音应答应用程序包括数据库元件。
5.根据任何一项前述权利要求的方法，其中执行交互式语音应答应用程序的步骤包括错误检查和纠正。
6.根据任何一项前述权利要求的方法，还包括在上传文件后处理该文件。
7.根据权利要求6的方法，其中处理文件的步骤包括错误检查和纠正。
8.根据权利要求7的方法，其中错误检查包括创建交互式语音应答子应用程序以用于下载到设备。
9.根据权利要求8的方法，还包括把所述交互式语音应答子应用程序下载到设备上，接收执行交互式语音应答子应用程序的用户命令，响应于该命令而执行交互式语音应答子应用程序，创建包括用户对该交互式语音应答子应用程序的响应的第二文件，以及上传该第二文件。
10.一种通信系统，包括网关(200)和用于与该网关(200)通信的设备(204)，该网关(200)用于把交互式语音应答应用程序(206)下载到设备(204)上，该设备(204)用于接收执行交互式语音应答应用程序(206)的用户命令，用于响应于该命令而执行交互式语音应答应用程序(206)，用于创建包括用户对交互式语音应答应用程序(206)的响应的文件(208)，以及用于上传该文件(208)到网关(200)。
11.根据权利要求10的系统，其中该设备是数据卡。
12.根据权利要求10的系统，其中该设备是便携式手机。
13.根据权利要求10、11或12的系统，其中该交互式语音应答应用程序包括数据库元件。
14.根据权利要求10到13中任何一项的系统，其中该设备在执行交互式语音应答应用程序时还被配置成执行错误检查和纠正。
15.根据权利要求10到14中任何一项的系统，其中该网关还被配置成在文件的上传之后处理该文件。
16.根据权利要求15的系统，其中该网关在处理文件时还被配置成执行错误检查和纠正。
17.根据权利要求16的系统，其中该网关在执行错误检查时创建交互式语音应答子应用程序以用于下载到设备。
18.根据权利要求17的系统，其中该网关还被配置成把该交互式语音应答子应用程序下载到设备上，以及该设备还被配置成接收执行交互式语音应答子应用程序的用户命令，响应于该命令而执行交互式语音应答子应用程序，以及创建包括用户对交互式语音应答子应用程序的响应的第二文件，以及上传该第二文件。
全文摘要
一种通信方法包括把交互式语音应答应用程序下载到设备上，接收执行交互式语音应答应用程序的用户命令，响应于该命令而执行交互式语音应答应用程序，创建包括用户对该交互式语音应答应用程序的响应的文件，以及上传该文件。
文档编号H04M1/725GK1985503SQ200580024055
公开日2007年6月20日 申请日期2005年7月15日 优先权日2004年7月16日
发明者P·J·兰金, D·A·贝尔 申请人:皇家飞利浦电子股份有限公司