号码注销、绑定、解绑方法以及运营商服务器和应用平台与流程

本发明涉及移动互联网技术领域，特别是一种号码注销、绑定、解绑方法以及运营商服务器和应用平台。

背景技术：

现有的应用出于安全、方便的考虑，需要与手机绑定进行认证或者验证的情况越来越多，各种网上购物、支付、股票、论坛等应用以及线下商铺、水电煤等机构都需要绑定用户手机号码，用户基本上每使用一个新的应用都会和自己的手机绑定以方便进行登录验证等操作。解绑手机的时候，也同样需要根据每个应用的要求进行解绑申请操作。

如果只是对某个应用单独进行解绑操作，工作量还不算大；但是随着绑定的应用数量增多，用户在换号或销号时，解绑就会非常繁琐、痛苦；如果销号不解绑，可能出现在号码重新分配后通知信息发给他人的情况，一方面影响了该号码的新使用者的用户体验，另一方面还会引发安全问题，造成号码原拥有者的损失。

技术实现要素：

本发明的一个目的在于提出一种实现用户销号时解绑应用的方案。

根据本发明的一个方面，提出一种号码注销方法，包括：运营商服务器获取销号请求中的注销号码；向应用平台发出解绑请求，解绑请求中包括注销号码。

可选地，向应用平台发出解绑请求包括：按照各个应用平台的解绑规则，向注销号码能够绑定的全部应用平台分别发送解绑请求。

可选地，还包括：当用户绑定应用平台时，记录与号码绑定的应用平台；向各个应用平台发出解绑请求包括：向与注销号码绑定的应用平台发出解绑请求。

可选地，还包括：获取来自应用平台的解绑结果信息。

可选地，还包括：接收来自用户的账户绑定消息，账户绑定消息中包括应用平台的标识；根据绑定请求向应用平台发送绑定请求，绑定请求中包括用户号码信息。

通过这样的方法，当用户注销号码时，能够向各个平台发出解绑请求，对该号码绑定的各个平台进行账户解绑，从而实现了用户销号时快速、批量的解绑应用，避免在号码重新分配后认证消息发送给他人影响他人使用体验及危害号码原拥有者的账户安全。

根据本发明的一个方面，提出一种号码绑定方法，包括：接收来自用户的账户绑定消息，账户绑定消息中包括应用平台的标识；根据绑定请求向应用平台发送绑定请求，绑定请求中包括用户号码信息。

可选地，账户绑定消息中还包括用户账户标识；绑定请求中还包括用户账户标识，以便应用平台根据用户账户标识将用户号码与已有的用户账户绑定。

通过这样的方法，用户能够通过运营商服务器进行绑定，一方面有利于运营商服务器记录与用户绑定的应用平台，另一方面也方便了用户进行批量绑定，提高了用户体验。

根据本发明的另一个方面，提出一种号码解绑方法，包括：应用平台获取来自运营商服务器的解绑请求中的注销号码；解除注销号码与账号的绑定。

可选地，还包括：应用平台获取解绑请求；判断解绑请求是否来自运营商服务器；获取来自运营商服务器的解绑请求中的注销号码包括：当确定解绑请求来自运营商服务器时，获取解绑请求中的注销号码。

可选地，解除注销号码与账号的绑定包括：若存在与注销号码绑定的账号，则解除注销号码与账号的绑定；若不存在与注销号码绑定的账号，则忽略解绑请求。

可选地，还包括：向运营商服务器反馈解绑结果信息，解绑结果信息包括解绑成功、解绑失败和/或不存在绑定关系。

可选地，还包括：接收来自运营商服务器的解绑请求中的绑定请求，绑定请求中包括用户号码信息；将用户号码信息与账户绑定。

通过这样的方法，应用平台能够根据来自运营商服务器的解绑请求解除注销号码与本平台账号的绑定，从而避免在号码重新分配后仍将消息发送给该号码导致危害号码原拥有者的本平台账户安全。

根据本发明的又一个方面，提出一种运营商服务器，包括：注销号码获取模块，用于获取销号请求中的注销号码；解绑请求发送模块，用于向应用平台发出解绑请求，解绑请求中包括注销号码。

可选地，解绑请求发送模块用于：按照各个应用平台的解绑规则，向注销号码能够绑定的全部应用平台分别发送解绑请求。

可选地，还包括：应用平台记录模块，用于当用户绑定应用平台时，记录与号码绑定的应用平台；解绑请求发送模块用于向与注销号码绑定的应用平台发出解绑请求。

可选地，还包括：解绑结果获取模块，用于获取来自应用平台的解绑结果信息。

可选地，还包括：绑定消息接收模块，用于接收来自用户的账户绑定消息，账户绑定消息中包括应用平台的标识；绑定消息发送模块，用于根据绑定请求向应用平台发送绑定请求，绑定请求中包括用户号码信息。

这样的服务器在用户注销号码时，能够向各个平台发出解绑请求，对该号码绑定的各个平台进行账户解绑，从而实现了用户销号时快速、批量的解绑应用，避免在号码重新分配后认证消息发送给他人影响他人使用体验及危害号码原拥有者的账户安全。

根据本发明的一个方面，提出一种运营商服务器，包括：绑定消息接收模块，用于接收来自用户的账户绑定消息，账户绑定消息中包括应用平台的标识；绑定消息发送模块，用于根据绑定请求向应用平台发送绑定请求，绑定请求中包括用户号码信息。

可选地，账户绑定消息中还包括用户账户标识；绑定请求中还包括用户账户标识，以便应用平台根据用户账户标识将用户号码与已有的用户账户绑定。

这样的服务器能够供用户通过运营商服务器提供的界面或接口进行绑定，一方面有利于运营商服务器记录与用户绑定的应用平台，另一方面也方便了用户进行批量绑定，提高了用户体验。

根据本发明的再一个方面，提出一种应用平台，包括：解绑号码获取模块，用于获取来自运营商服务器的解绑请求中的注销号码；解绑模块，用于解除注销号码与账号的绑定。

可选地，还包括：解绑请求获取模块，用于获取解绑请求；解绑请求溯源模块，用于判断解绑请求是否来自运营商服务器；解绑号码获取模块用于当确定解绑请求来自运营商服务器时，获取解绑请求中的注销号码。

可选地，解绑模块用于：若存在与注销号码绑定的账号，则解除注销号码与账号的绑定；若不存在与注销号码绑定的账号，则忽略解绑请求。

可选地，还包括：结果反馈模块，用于向运营商服务器反馈解绑结果信息，解绑结果信息包括解绑成功、解绑失败和/或不存在绑定关系。

可选地，还包括：绑定请求接收模块，用于接收来自运营商服务器的解绑请求中的绑定请求，绑定请求中包括用户号码信息；绑定模块，用于将用户号码信息与账户绑定。

这样的应用平台能够根据来自运营商服务器的解绑请求解除注销号码与本平台账号的绑定，从而避免在号码重新分配后仍将消息发送给该号码导致危害号码原拥有者的本平台账户安全。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1为本发明的号码注销方法的一个实施例的流程图。

图2为本发明的号码注销方法的另一个实施例的流程图。

图3为本发明的号码解绑方法的一个实施例的流程图。

图4为本发明的号码解绑方法的另一个实施例的流程图。

图5为本发明的运营商服务器的一个实施例的示意图。

图6为本发明的运营商服务器的另一个实施例的示意图。

图7为本发明的运营商服务器的又一个实施例的示意图。

图8为本发明的应用平台的一个实施例的示意图。

图9为本发明的应用平台的另一个实施例的示意图。

图10为本发明的应用平台的再一个实施例的示意图。

具体实施方式

下面通过附图和实施例，对本发明的技术方案做进一步的详细描述。

本发明的号码注销方法的一个实施例的流程图如图1所示。

在步骤101中，运营商服务器获取销号请求中的注销号码。在一个实施例中，当用户通过柜台或网络系统请求销号时，运营商服务器可以获取注销号码。

在步骤102中，向各个应用平台发出解绑请求，解绑请求中包括注销号码，以便应用平台在接到解绑请求后解除该注销号码与平台内账户的绑定。在一个实施例中，应用平台可以包括网上购物、支付、股票、论坛、商铺、水电煤机构等。

通过这样的方法，当用户注销号码时，能够向各个平台发出解绑请求，对该号码绑定的各个平台进行账户解绑，从而实现了用户销号时快速、批量的解绑应用，避免在号码重新分配后认证消息发送给他人影响他人使用体验及危害号码原拥有者的账户安全。

在一个实施例中，运营商服务器可以向已知的全部支持通过运营商服务器进行解绑的应用平台均发送解绑请求。若应用平台中存在绑定了注销号码的账户，则会执行解绑操作；若该注销号码未在某个应用平台中绑定，则应用平台会解绑失败。

通过这样的方法，能够对任何一个注销号码均进行全部平台的解绑申请，一方面无需获知该注销号码曾经绑定过哪些平台，对系统能力的要求较低；另一方面能够防止漏解绑，保证解绑效果达到最优。

在一个实施例中，各个应用平台可以与运营商服务器约定解绑协议，运营商服务器以约定好的消息格式向应用平台发送解绑请求。各个应用平台与运营商服务器约定的协议可以相同，也可以不同。运营商服务器根据与各个应用平台约定的协议分别向对应的应用平台发送解绑请求。通过这样的方法，能够保证解绑请求被各个应用平台解析，确保注销号码能够被成功解绑；同时，可以充分考虑各个应用平台的不同情况，允许与各个应用平台间存在个性化交互。

本发明的号码注销方法的另一个实施例的流程图如图2所示。

在步骤201中，当用户绑定应用平台时，记录与号码绑定的应用平台。当用户注销号码时，执行步骤202。

在步骤202中，运营商服务器获取销号请求中的注销号码。

在步骤203中，向与注销号码绑定的各个应用平台发出解绑请求，解绑请求中包括注销号码，以便应用平台在接到解绑请求后解除该注销号码与平台内账户的绑定。

通过这样的方法，能够在用户绑定应用平台时记录与号码相绑定的平台，当注销时，能够确定与注销号码绑定的各个应用平台，从而有针对性的发送解绑请求，降低了运营商服务器解绑请求发送的负担、网络消息承载的负担，也避免影响各个应用平台的稳定。

在一个实施例中，运营商服务器可以向用户提供绑定功能界面或接口，供用户选择要绑定的应用平台。在一个实施例中，用户可以批量选择应用平台进行绑定。当用户选择需要绑定的应用平台时，运营商服务器接收来自用户的账户绑定消息，账户绑定消息中包括应用平台的标识；运营商服务器根据绑定请求向应用平台发送绑定请求，绑定请求中包括用户号码信息。在一个实施例中，运营商服务器可以记录用户选择的需要绑定的应用平台，以便在号码注销时批量解绑。

通过这样的方法，用户能够通过运营商服务器进行绑定，一方面有利于运营商服务器记录与用户绑定的应用平台，另一方面也方便了用户进行批量绑定，提高了用户体验。

在一个实施例中，用户的账户绑定消息中还包括用户在各个应用平台的账户标识，绑定请求中包括用户号码信息和账户标识，应用平台将用户号码与对应的账户绑定，从而实现了用户号码与已有账户的绑定。

在一个实施例中，当向应用平台发出解绑请求后，还可以从应用平台获得解绑结果信息。解绑结果信息可以包括解绑成功、解绑失败、解绑失败的原因等。运营商服务器可以向解绑失败的应用平台重新发送解绑请求，以避免网络、应用平台暂时异常导致的解绑失败，运营商服务器还可以记录解绑失败的应用平台，以便维护人员进行检查或手动解绑等。

通过这样的方法，能够掌握注销号码在各个应用平台的解绑结果以便实施相应的策略，提高了解绑的可靠性，进一步提高用户体验。

本发明还提出一种号码绑定方法，在一个实施例中，运营商服务器可以向用户提供绑定功能界面或接口，供用户选择要绑定的应用平台。在一个实施例中，用户可以批量选择应用平台进行绑定。当用户选择需要绑定的应用平台时，运营商服务器接收来自用户的账户绑定消息，账户绑定消息中包括应用平台的标识；运营商服务器根据绑定请求向应用平台发送绑定请求，绑定请求中包括用户号码信息。在一个实施例中，运营商服务器可以记录用户选择的需要绑定的应用平台，以便在号码注销时批量解绑。

通过这样的方法，用户能够通过运营商服务器进行绑定，一方面有利于运营商服务器记录与用户绑定的应用平台，另一方面也方便了用户进行批量绑定，提高了用户体验。

在一个实施例中，用户的账户绑定消息中还包括用户在各个应用平台的账户标识，绑定请求中包括用户号码信息和账户标识，应用平台将用户号码与对应的账户绑定，从而实现了用户号码与已有账户的绑定。

本发明的号码解绑方法的一个实施例的流程图如图3所示。

在步骤301中，应用平台获取来自运营商服务器的解绑请求中的注销号码。在一个实施例中，应用平台可以在收到解绑请求后根据与运营商服务器的约定查询对应字段，得到注销号码。

在步骤302中，解除注销号码与账号的绑定。在一个实施例中，可以遍历查询与该注销号码绑定的本应用平台所有账户，解除注销号码与任何本平台账号的绑定关系。

通过这样的方法，应用平台能够根据来自运营商服务器的解绑请求解除注销号码与本平台账号的绑定，从而避免在号码重新分配后仍将消息发送给该号码导致危害号码原拥有者的本平台账户安全。

在一个实施例中，可以在接到解绑请求后进行格式、协议匹配，若解绑请求符合与运营商协商的格式、协议，则判断该请求为来自运营商服务器的解绑请求；或者可以对解绑请求进行源地址判断，若源地址为运营商服务器，则判断该请求为来自运营商服务器的解绑请求。通过这样的方法，能够区分来自账户拥有者的解绑请求和运营商服务器的解绑请求。由于来自个人的解绑请求往往需要通过认证消息、密码等手段进行验证，以避免他人恶意解绑、修改他人绑定号码，而来自运营商服务器的解绑请求具有更高的可信性，可以无需验证直接解绑。通过区分来自个人和运营商服务器的解绑请求能够采用不同的流程有针对性的对待，提高解绑的可行性和执行效率。

在另一个实施例中，应用平台可以向运营商服务器开放专门的端口，用于接收来自运营商服务器的解绑请求。通过这样的方法，能够防止将来自其他应用、用户的解绑请求判断为来自运营商服务器的解绑请求，防止了他人利用解绑请求恶意解绑、修改用户绑定的号码，提高用户账户的安全性。

由于运营商服务器并不一定明确注销号码曾经与哪些应用平台账号绑定，因此运营商服务器可能会向全部支持通过运营商服务器进行解绑的应用平台均发送解绑请求。本发明的号码解绑方法的另一个实施例的流程图如图4所示。

在步骤401中，应用平台获取来自运营商服务器的解绑请求中的注销号码。

在步骤402中，应用平台判断本平台内是否存在与注销号码绑定的账号。若不存在与注销号码绑定的账号，则执行步骤403；若存在与注销号码绑定的账号，则执行步骤404。

在步骤403中，忽略解绑请求。

在步骤404中，解除应用平台内账号与注销号码的绑定关系，确保应用平台内不存在与注销号码绑定的账号。

通过这样的方法，能够以更严密的判断逻辑避免由于不存在与注销号码绑定的账号导致的系统错误、逻辑混乱等，保证应用平台的稳定。

在一个实施例中，应用平台还能够将解绑结果信息反馈给运营商服务器。解绑结果信息包括解绑成功、解绑失败、失败原因、不存在绑定关系等。

通过这样的方法，能够方便运营商服务器掌握注销号码在各个应用平台的解绑结果以便实施相应的策略，提高了解绑的可靠性，进一步提高用户体验。

在一个实施例中，应用平台还能够接收来自运营商服务器的绑定请求，绑定请求中包括用户号码信息和用户账户信息，应用平台将用户号码信息与用户账户绑定。通过这样的方法，能够实现将用户号码信息与已有用户账户绑定，便于用户通过运营商服务器进行批量绑定。

在一个实施例中，当绑定请求中不包括用户账户信息时，应用平台可以新建账户，并将新建的账户与用户号码绑定。通过这样的方法，能够在增加应用平台用户量的同时，提高用户体验。

本发明的运营商服务器的一个实施例的示意图如图5所示。其中，注销号码获取模块501能够获取销号请求中的注销号码。在一个实施例中，当用户通过柜台或网络系统请求销号时，运营商服务器可以获取注销号码。解绑请求发送模块502能够向各个应用平台发出解绑请求，解绑请求中包括注销号码，以便应用平台在接到解绑请求后解除该注销号码与平台内账户的绑定。在一个实施例中，应用平台可以包括网上购物、支付、股票、论坛、商铺、水电煤机构等。

这样的服务器在用户注销号码时，能够向各个平台发出解绑请求，对该号码绑定的各个平台进行账户解绑，从而实现了用户销号时快速、批量的解绑应用，避免在号码重新分配后认证消息发送给他人影响他人使用体验及危害号码原拥有者的账户安全。

在一个实施例中，解绑请求发送模块502可以向已知的全部支持通过运营商服务器进行解绑的应用平台均发送解绑请求。若应用平台中存在绑定了注销号码的账户，则会执行解绑操作；若该注销号码未在某个应用平台中绑定，则应用平台会解绑失败。

这样的服务器能够对任何一个注销号码均进行全部平台的解绑申请，一方面无需获知该注销号码曾经绑定过哪些平台，对系统能力的要求较低；另一方面能够防止漏解绑，保证解绑效果达到最优。

在一个实施例中，各个应用平台可以与运营商服务器约定解绑协议，运营商服务器以约定好的消息格式向应用平台发送解绑请求。各个应用平台与运营商服务器约定的协议可以相同，也可以不同。运营商服务器根据与各个应用平台约定的协议分别向对应的应用平台发送解绑请求。这样的服务器能够保证解绑请求被各个应用平台解析，确保注销号码能够被成功解绑；同时，可以充分考虑各个应用平台的不同情况，允许与各个应用平台间存在个性化交互。

本发明的运营商服务器的另一个实施例的示意图如图6所示。其中，应用平台记录模块603能够在用户绑定应用平台时，记录与号码绑定的应用平台。当用户注销号码时，注销号码获取模块601能够获取销号请求中的注销号码。解绑请求发送模块602能够向与注销号码绑定的各个应用平台发出解绑请求，解绑请求中包括注销号码，以便应用平台在接到解绑请求后解除该注销号码与平台内账户的绑定。

这样的服务器能够在用户绑定应用平台时记录与号码相绑定的平台，当注销时，能够确定与注销号码绑定的各个应用平台，从而有针对性的发送解绑请求，降低了运营商服务器解绑请求发送的负担、网络消息承载的负担，也避免影响各个应用平台的稳定。

在一个实施例中，本发明的运营商服务器还包括绑定消息接收模块和绑定消息发送模块。运营商服务器可以向用户提供绑定功能界面或接口，供用户选择要绑定的应用平台。绑定消息接收模块能够接收来自用户的账户绑定消息，账户绑定消息中包括应用平台的标识；绑定消息发送模块能够根据绑定请求向应用平台发送绑定请求，绑定请求中包括用户号码信息。在一个实施例中，应用平台记录模块可以记录用户选择的需要绑定的应用平台，以便在号码注销时批量解绑。

这样的服务器能够供用户通过运营商服务器提供的界面或接口进行绑定，一方面有利于运营商服务器记录与用户绑定的应用平台，另一方面也方便了用户进行批量绑定，提高了用户体验。

在一个实施例中，用户的账户绑定消息中还包括用户在各个应用平台的账户标识，绑定请求中包括用户号码信息和账户标识，应用平台将用户号码与对应的账户绑定，从而实现了用户号码与已有账户的绑定。

本发明的运营商服务器的又一个实施例的示意图如图7所示。其中，注销号码获取模块701和解绑请求发送模块702的结构和功能与图5、6的实施例中相似。运营商服务器还包括解绑结果获取模块703，能够在解绑请求发送模块702向应用平台发出解绑请求后，从应用平台获得解绑结果信息。解绑结果信息可以包括解绑成功、解绑失败、解绑失败的原因等。运营商服务器可以向解绑失败的应用平台重新发送解绑请求，以避免网络、应用平台暂时异常导致的解绑失败，运营商服务器还可以记录解绑失败的应用平台，以便维护人员进行检查或手动解绑等。

这样的服务器能够掌握注销号码在各个应用平台的解绑结果以便实施相应的策略，提高了解绑的可靠性，进一步提高用户体验。

在一个实施例中，运营商服务器可以向用户提供绑定功能界面或接口，供用户选择要绑定的应用平台。

运营商服务器可以包括绑定消息接收模块和和绑定消息发送模块，其中，绑定消息接收模块能够接收来自用户的账户绑定消息，账户绑定消息中包括应用平台的标识；绑定消息发送模块能够根据绑定请求向应用平台发送绑定请求，绑定请求中包括用户号码信息。在一个实施例中，应用平台记录模块可以记录用户选择的需要绑定的应用平台，以便在号码注销时批量解绑。

这样的服务器能够供用户通过运营商服务器提供的界面或接口进行绑定，一方面有利于运营商服务器记录与用户绑定的应用平台，另一方面也方便了用户进行批量绑定，提高了用户体验。

在一个实施例中，用户的账户绑定消息中还包括用户在各个应用平台的账户标识，绑定请求中包括用户号码信息和账户标识，应用平台将用户号码与对应的账户绑定，从而实现了用户号码与已有账户的绑定。

本发明的应用平台的一个实施例的示意图如图8所示。其中，解绑号码获取模块801能够获取来自运营商服务器的解绑请求中的注销号码。在一个实施例中，应用平台可以在收到解绑请求后根据与运营商服务器的约定查询对应字段，得到注销号码。解绑模块802能够解除注销号码与账号的绑定。在一个实施例中，可以遍历查询与该注销号码绑定的本应用平台所有账户，解除注销号码与任何本平台账号的绑定关系。

这样的应用平台能够根据来自运营商服务器的解绑请求解除注销号码与本平台账号的绑定，从而避免在号码重新分配后仍将消息发送给该号码导致危害号码原拥有者的本平台账户安全。

本发明的应用平台的另一个实施例的示意图如图9所示。其中，解绑号码获取模块901和解绑模块902的结构和功能与图8的实施例中相似。应用平台还包括解绑请求获取模块903和解绑请求溯源模块904。其中，解绑请求获取模块903能够接收解绑请求，解绑请求可以来自用户，也可以来自运营商服务器。解绑请求溯源模块904能够进行溯源，区分来自账户拥有者的解绑请求和运营商服务器的解绑请求。在一个实施例中，溯源可以通过格式、协议匹配来实现，若解绑请求符合与运营商协商的格式、协议，则判断该请求为来自运营商服务器的解绑请求。在另一个实施例中，溯源可以通过对解绑请求进行源地址判断来实现，若源地址为运营商服务器，则判断该请求为来自运营商服务器的解绑请求，从而能够区分来自账户拥有者的解绑请求和运营商服务器的解绑请求。

由于来自个人的解绑请求往往需要通过认证消息、密码等手段进行验证，以避免他人恶意解绑、修改他人绑定号码，而来自运营商服务器的解绑请求具有更高的可信性，可以无需验证直接解绑。这样的应用平台能够区分来自个人和运营商服务器的解绑请求，从而能够采用不同的流程有针对性的对待，提高解绑的安全性、可行性和执行效率。

在另一个实施例中，应用平台可以向运营商服务器开放专门的端口，用于接收来自运营商服务器的解绑请求。这样的应用平台能够防止将来自其他应用、用户的解绑请求判断为来自运营商服务器的解绑请求，防止了他人利用解绑请求恶意解绑、修改用户绑定的号码，提高用户账户的安全性。

在一个实施例中，由于运营商服务器并不一定明确注销号码曾经与哪些应用平台账号绑定，因此运营商服务器可能会向全部支持通过运营商服务器进行解绑的应用平台均发送解绑请求。解绑号码获取模块801在获取来自运营商服务器的解绑请求中的注销号码后，解绑模块802能够判断本平台内是否存在与注销号码绑定的账号。若不存在与注销号码绑定的账号，则忽略解绑请求；若存在与注销号码绑定的账号，则解除应用平台内账号与注销号码的绑定关系，确保应用平台内不存在与注销号码绑定的账号。

这样的应用平台能够以更严密的判断逻辑避免由于不存在与注销号码绑定的账号导致的系统错误、逻辑混乱等，保证应用平台的稳定。

在一个实施例中，应用平台还可以包括绑定请求接收模块和绑定模块。其中，绑定请求接收模块能够接收来自运营商服务器的绑定请求，绑定请求中包括用户号码信息和用户账户信息，绑定模块能够将用户号码信息与用户账户绑定。这样的应用平台能够实现将用户号码信息与已有用户账户绑定，便于用户通过运营商服务器进行批量绑定。

在一个实施例中，当绑定请求中不包括用户账户信息时，应用平台可以新建账户，并将新建的账户与用户号码绑定。这样的应用平台能够在增加平台用户量的同时，提高用户体验。

本发明的应用平台的再一个实施例的示意图如图10所示。其中，解绑号码获取模块1001和解绑模块1002的结构和功能与图8、9的实施例中相似。应用平台还包括结果反馈模块1003，能够将解绑结果信息反馈给运营商服务器。解绑结果信息包括解绑成功、解绑失败、失败原因、不存在绑定关系等。

这样的应用平台能够方便运营商服务器掌握注销号码在各个应用平台的解绑结果以便实施相应的策略，提高了解绑的可靠性，进一步提高用户体验。

最后应当说明的是：以上实施例仅用以说明本发明的技术方案而非对其限制；尽管参照较佳实施例对本发明进行了详细的说明，所属领域的普通技术人员应当理解：依然可以对本发明的具体实施方式进行修改或者对部分技术特征进行等同替换；而不脱离本发明技术方案的精神，其均应涵盖在本发明请求保护的技术方案范围当中。