CN108737975B - 通信控制方法 - Google Patents

Abstract

本发明公开一种通信控制方法，该方法针对相应账号设置最新的UserLabel，通过该最新的UserLabel，对消息的目的UserLabel进行过滤，以便对消息的发送或处理进行控制，从而避免将要发生给一个账号的老用户的消息发送给该账号的新用户。本发明还提供一种UserLabel指配方法，按照该方法，能保证先后指配给一个账号的UserLabel互不相同，并使得指配的UserLabel占用较少的存储和承载资源。

Description

通信控制方法

技术领域

本发明涉及通信控制，更确切地说涉及基于用户标签的通信控制方法。

背景技术

在电信网通信领域中，存在这样一种现象，用户A因为某种原因，放弃了正在使用的老手机号码，并申请了新手机号码。而用户A的老手机号码又被用户B注册使用。这种情况下，用户B就有可能接到用户A的好友发送过来的短消息，从而，对用户B造成骚扰，并泄漏用户A以及用户A的朋友的隐私信息，给用户A以及用户A的朋友带来安全隐患。例如，经常有人反应，其手机常常接到上一个使用当前手机号码的用户的朋友或业务相关人员打来的电话，或发来的短信。

在互联网通信领域中，大多数应用，例如，微信，陌陌，163邮箱，还没有提供注销老账号，并允许其他用户注册已经被注销的老账号的情况。但这会带来这样的问题，一个用户被长期骚扰后，放弃自己已用的账号，重新申请注册新的账号。这种情况下，会导致账号占用越来越多，这样，除了增加系统负担外，还会导致新注册的账号越来越长。正是考虑到这种原因，有人在考虑提供用户修改账号业务，允许一个用户修改自己的账号，并将该用户的老账号释放掉，以允许其他用户注册使用。或者是，允许一个用户注销自己的账号，并使他人能够注册使用被注销的账号。

允许一个被注销掉的互联网账号被其他用户注册接着使用，通常也会存在“电话号码注销后又被注册使用”的问题。

还例如，客户办理银行卡或信用卡时，登记了手机号码，因为某种原因，客户更换了手机号码，而在银行登记的电话号码却忘记更改，而该客户原来的手机号码又被其他用户注册使用。这种情况下，当银行因为某种原因，要通过短消息给所述客户发送信息时，就会将该信息发送给所述的其他手机用户。各种五花八门的会员卡，也存在类似情况。

还例如，一个互联网账号，例如网易邮箱地址，被用户A放弃后，如果允许用户B注册使用这个被放弃的邮箱地址，那么，用户B就有可能接收到用户A的好友发送过来的邮件。

还例如，用户A用手机号码注册了或者绑定了网易账号或微信账号或支付宝账号，或其它网上支付账号，或12306火车票订票系统账号。当用户A忘记了在某个服务商那里注册的账号，例如微信账号，的登陆密码时，通过输入手机号码，可以重新设置登陆密码。例如，用户登入微信失败之后，可以通过手机找回密码：输入手机号码，微信客户端将手机号码发送给微信服务器，对应的服务器按照该手机号码，产生一个用于身份验证的验证码，将该验证码发送给用户，用户利用手机接收的验证码进行登陆或者修改登陆密码。例如，用户将手机接收的验证码发送给所述服务器，服务器验证通过后，允许用户登陆并修改登陆密码。

特别地，有些互联网账户可以直接使用手机号码进行登陆，并在不知道密码时，直接通过绑定的手机号码，获取服务器产生的验证码，通过该验证码，来重新设置密码

上面的事实，已经是将用户手机号码作为用户身份的一种凭证。这在很大程度上，方便了用户使用，也方便了服务商的业务运营，降低了运营成本。

但是，以上的便利埋下了安全隐患。当用户A因为某种原因，而更换了手机号码，例如在北京上学，毕业后到上海工作，这时，用户A使用的这个老号码就被释放出来，后面的用户B在注册到用户A注销的老号码后，按照上述的便利业务流程，就可以用该老号码登陆用户A的相应账号或支付系统，除非用户A在注销了老号码的同时，立即注销或解除了所有的与老号码有关的绑定业务，例如，解除老号码与微信账号的绑定，解除老号码与支付宝账号的绑定，解除老号码与订票系统账号的绑定，等等。这对用户A来说，是一件烦心的事！而且常常因为百密一疏，而漏掉某个账号的解绑操作，从而给用户A带来安全风险。

发明内容

有鉴于此，本发明公开一种通信控制方法，至少能使上述问题得到部分解决。该方法通过针对相应账号保存最新的UserLabel，对于接收的，或创建的，或待创建的，具有目的账号和目的UserLabel的消息，使得通过比较目的账号的最新UserLabel与目的UserLabel，可以判断消息的目的账号是否有效，从而避免了对收信方的骚扰，并保护了消息发送方，以及所述账号的老用户的隐私。所述方法包括：

a、获取所述消息的目的账号的最新的UserLabel；

b、比较所述最新的UserLabel与消息的目的UserLabel，如果二者一致，则执行步骤c：按照正常流程处理；否则，执行步骤d：按照异常流程处理。

可选地，所述消息是接收的消息，所述步骤d进一步是：向消息发送方回复所述最新的 UserLabel。

可选地，所述消息是接收的消息，所述步骤d进一步是如下两种处理方式中任意一种：

所述方式一是：向消息发送方回复所述最新的UserLabel，判断所述目的UserLabel是否为特殊值，如果是，则执行步骤c；

所述方式二是：判断所述目的UserLabel是否为特殊值，如果是，则执行步骤c，以及向消息发送方回复所述最新的UserLabel；否则，向消息发送方回复所述最新的UserLabel。

可选地，所述消息是接收的消息，所述步骤d进一步是：判断所述目的UserLabel是否为特殊值，如果是，则执行操作1和操作2两项操作中至少一项操作；

所述操作1是：向消息发送方回复所述最新的UserLabel；

所述操作2是：执行步骤c。

可选地，所述账号是手机号码，所述消息是短消息服务中心(SMSC，Short MassageService Center)接收的，包含有要发送出去的短消息；

所述步骤c进一步是：根据所述目的号码，向相应归属位置寄存器(HLR，HomeLocation Register)发送路由查询请求；接收HLR返回的所述目的号码对应的路由信息，按照所述路由信息，执行短消息发送操作。

可选地，所述账号是手机号码，所述消息是SMSC接收的，包含有要发送出去的短消息；所述针对相应账号保存最新的UserLabel是在HLR一侧实施的；

所述步骤a进一步是：根据所述目的号码，向相应HLR发送路由查询请求；接收HLR返回的所述目的号码对应的路由信息和最新的UserLabel；

所述步骤c进一步是：按照所述路由信息，执行短消息发送操作。

可选地，所述账号是手机号码，所述消息是HLR接收的路由查询消息；所述针对相应账号保存最新的UserLabel是在HLR一侧实施的；

所述步骤a进一步是：根据所述目的号码，获取对应的路由信息和最新的UserLabel；

所述步骤c进一步是：向消息发送方返回获取的所述目的号码对应的路由信息。

可选地，所述步骤d进一步是如下三种处理方式中任意一种：

所述方式一是：向消息发送方回复所述最新的UserLabel；

所述方式二是：判断所述目的UserLabel是否为特殊值，如果是，则向消息发送方返回获取的所述目的号码对应的路由信息和所述最新的UserLabel，否则，向消息发送方回复所述最新的UserLabel；

所述方式三是：判断所述目的UserLabel是否为特殊值，如果是，则向消息发送方回复所述最新的UserLabel或者执行步骤c或者向消息发送方返回获取的所述目的号码对应的路由信息和所述最新的UserLabel。

可选地，所述账号是手机号码，所述消息包含有扩展短消息实体(ESME，ExternalShort Message Entity)要发送出去的短消息；所述针对相应账号保存最新的UserLabel是：设置 UserLabel存储模块，在该UserLabel存储模块中，根据相应手机号码保存对应的UserLabel；

所述步骤a进一步是：根据所述目的号码，从所述UserLabel存储模块中获取最新的 UserLabel；

所述步骤c进一步是：执行短消息发送操作。

本发明还提供一种UserLabel指配方法，按照该方法，能保证先后指配给一个账号的 UserLabel互不相同，并使得指配的UserLabel占用较少的存储和承载资源。按照该方法，设置注销账号表，用于保存各个被注销账号对应的UserLabel，该方法包括：

a、判断待注册账号是否在注销账号表中，如果在，则执行步骤b；否则执行步骤c；

所述步骤b是：将待注册账号的现有UserLabel加1，得到新的UserLabel，将新的UserLabel作为待注册账号的UserLabel；

所述步骤c是：将待注册账号的UserLabel设置为1。

上述实施例提供的技术方案中，由于针对相应账号指配了最新的UserLabel，使得能够按照消息的目的UserLabel来对消息进行不同的处理或响应，从而能够避免“本来要发送给一个账号的老用户的消息被误发给该账号的新用户”的问题，防止了新用户被骚扰，并有效保护所述老用户及其好友的隐私，提高了电信网和互联网通信的整体安全性。

附图说明

图1所示，为本发明总体实施方式流程图。

图2、3、4、5所示，分别为本发明具体实施例一、二、三、四流程图。

图6、7所示，分别为本发明验证码发放控制方法一、二流程图。

图8、9、10所示，分别为捆绑关系建立方法一、二、三流程图。

缩写词

ESME：(External Short Message Entity，扩展短消息实体)

HLR：(Home Location Register，归属位置寄存器)；

MSC：(Mobile Switching Center，移动交换中心)

MSRN：(Mobile Station Roaming Number，漫游号码)

SMSC：(Short Massage Service Center，短消息服务中心)

UUS：(User-to-User Signalling，用户到用户信令)

VLR：(Visitor Location Register，拜访位置寄存器)

具体实施方式

为使本发明目的、技术方案和优点更加清楚明白，下面结合实施例，从多个方面进行详细说明。

为了阻止要发生给一个账号的老用户的消息被发送给该账号的新用户，本发明提出为用户指配标签，称为用户标签(UserLabel)，用以区分先后注册使用同一个账号的不同用户。

为一个用户指配的UserLabel也称为该用户对应账号的UserLabel，或对应账户的UserLabel。

为用户指配UserLabel的操作，可以在用户注册账号时进行；也可以是在已注册用户请求变更UserLabel时进行，例如，家庭成员之间电话号码转让使用时，对应用户可以请求变更UserLabel。

下面以{为用户指配UserLabel的操作，在用户注册账号时进行}为例，但不用于限定。

例如，在用户注册账号时，获取系统当前时间值，将该时间值作为指配给该用户的UserLabel。

还例如，在用户注册账号时，获取系统当前日期，将该日期值作为指配给该用户的UserLabel。这种情况下，当一个账号被一个用户注销时，该账号在第二天以后才被允许其他用户注册使用。

还例如，预先设置一个流水号生成器，在用户注册账号时，用该流水号生成器产生的流水号作为指配给该用户的UserLabel。例如，设置一个全局变量，起始值为0，每次需要为一个用户或待注册账号产生UserLabel时，将该全局变量加1，将该全局变量的新值作为指配给该用户或待注册账号的UserLabel值。

还例如，为了更好地反映每一个账号被使用的情况，针对每一个账号设置一个流水号生成器。下面以所述流水号生成器是一个递增的自然数为例，但不用于限定。

注册服务器一侧，保存相应注册账号对应的UserLabel，参见如表1-A所示的注册账号表，以及相应被注销账号对应的UserLabel，参见如表1-B所示的注销账号表。

表1-A

在表1-A中保存当前正在使用的账号及其对应的UserLabel。

表1-B

账号	UserLabel
		账号11	1
账号12	1
		账号13	2

在表1-B中保存曾经被使用的，现在处于注销状态的账号及其对应的UserLabel。

当一个账号还没有被任何用户使用过时，该账号的UserLabel默认为0或空值null。

注册服务器在用户注册账号时，判断待注册账号是否被使用过，如果没有，则给赋予该账号的UserLabel的值为1。如果一个账号已经被使用过，则在前一个用户使用该账号时所指配的UserLabel，即前一个用户的UserLabel基础上增加1，得到一个新的UserLabel，将新UserLabel作为当前注册用户的UserLabel。也即，一个账号每被使用一次，就将其对应的UserLabel值增加1。这样，就保证了，不同的用户在先后使用同一个账号时，所指配的UserLabel不同。

例如，用户注册账号时，注册服务器首先检查如表1-A所示的注册账号表，判断待注册账号是否是已使用账号，如果是，则无法注册。如果待注册账号不是已使用账号，则进一步检查如表1-B所示的注销账号表，判断该账号是否是被其他用户使用过，如果不是，则允许注册，并将该账号的UserLabel设置为1，在如表1-A所示的注册账号表中登记该账号和对应的UserLabel值1。如果检查发现该账号是被其他用户使用过，即从如表1-B所示的注销账号表查找到待注册账号，则将对应记录的Label值增加1，将得到的新UserLabel作为待注册账号的UserLabel，在如表1-A所示的注册账号表中登记该账号和对应的新UserLabel值，并从如表1-B所示的注销账号表中，将该账号对应的记录删除。

当用户关闭或注销一个账号时，注册服务器一侧将该账号在如表1-A所示的注册账号表中对应的记录删除，并将删除的记录添加到如表1-B所示的注销账号表中。

实际当中，可以将如表1-A所示的注册账号表和如表1-B所示的注销账号表合成为一个如表1-C所示的账号最新标签表。

表1-C

账号	UserLabel	Status
			账号1	1	1
账号2	2	1
			账号3	1	1
账号4	3	1
			账号11	1	0
账号12	1	0
			账号13	2	0

在表1-C中保存当前正在使用的账号及其对应的UserLabel，其Status值为1，表示该账号正被用户占用；以及曾经被使用的，现在处于注销状态的账号及其对应的UserLabel，其Status值为0，表示该账号已被用户关闭或注销，可以被其他用户注册使用。

例如，用户注册账号时，注册服务器首先检查如表1-C所示的账号最新标签表，查找待注册账号对应的记录，如果没有查找到，说明该账号尚未被使用过，则允许注册，并将该账号的UserLabel设置为1，在如表1-C所示的账号最新标签表中登记该账号和对应的UserLabel值1，对应的Status值为1。如果在如表1-C所示的账号最新标签表中查找到待注册账号对应的记录，则进一步判断Status值是否0时，如果不是，则说明该账号正被其他用户占用，禁止注册；如果所述对应的Status值为0，则说明该账号被用过，又被注销，则允许注册，并在该表中，将该账号的UserLabel值增加1，作为该账号的新UserLabel，并将对应记录的Status值设置为1，表示为正在占用。

当用户注销一个账号时，在注册服务器侧，只需要将如表1-C所示的账号最新标签表中，该账号对应的记录的Status值设置为0即可。

上述在用户注册时，除了检查用户输入的账号是否是现有账号，还要检查用户输入的账号是否是被先前用户注销的账号。如果系统发现用户输入的账号是现有账号，则告知用户，账号已经存在，请重新选择账号。如果用户输入的账号，不是现有账号，则检查该账号是否是被注销的账号，如果不是，则给用户输入的账号赋予UserLabel值1。如果检查发现用户输入的账号是被注销的账号，则将该账号对应的UserLabel值增加1，作为该账号的新UserLabel，也即，作为新注册用户的UserLabel。

在用户注销一个账号时，在注册服务器一侧，还保存被用户注销的账号及其最后被指配的UserLabel。

这样，通过以上的账号注册和注销管理方法，也能保证先后注册同一个账号的用户具有不同的UserLabel。

特别地，实际当中，上述通过流水号生成器产生一个账号的UserLabel的方案，可以减少UserLabel的占用空间。例如，用一个字节表示UserLabel，那么，对于一个账号来说，从1到255就可以标识255个不同的用户。通常，在一定时间内，例如100年内，一个账号被注销后又被注册的次数是有限的，因此，采用上面所说方案来指配一个账号的UserLabel，可以节约消息承载，以及内存的占用。

按照上述用户注册账号或注销账号业务办理方法，在用户注册一个账号时，系统为该用户指配了一个不同的UserLabel，或为该账号指配了一个新的UserLabel。

对于接收的，或要发送的消息，先执行UserLabel验证:判断消息的目的UserLabel是否与消息的目的账号的最新UserLabel一致；然后根据验证结果决定消息的处理方式：例如，如果二者一致，则按照正常流程处理，否则，按照异常流程处理。

所述要发送的消息可以是要转发的消息，还可以是自己创建的，或待自己创建的消息。

实际当中，一个消息可以是接收的，也可以是要发送的，也可以既是接收的，又是要发送的消息。例如，客户端创建消息要发送给服务器，该消息是要发送的消息，服务器收到所述消息后，该消息对于服务器来说，是接收的消息。如果服务器还有将该消息发送给其它的客户端，则该消息对于该服务器来说既是接收的，又是要发送的消息。

基于上述思想，本发明提出一种通信控制方法，该方法预先根据相应账号，对应保存最新的UserLabel，参见如表1-D所示的账号-UserLabel表：

表1-D

账号	UserLabel
		账号1	UserLabel1
账号2	UserLabel2
		账号3	UserLabel3

在该表中，根据一个账号，保存了该账号最新的UserLabel，这样，按照该表，根据一个账号，能够获取对应保存的最新UserLabel。

对于接收的，或要发送的消息，该方法执行如下流程：

步骤11、获取消息的目的账号的最新的UserLabel。

步骤12、执行UserLabel验证：比较所述最新的UserLabel与消息的目的UserLabel；如果二者一致，则执行步骤13：按照正常流程处理；否则，执行步骤14：按照异常流程处理。

参见如图1所示，为本发明总体实施方式流程图。

所述的“根据相应账号对应保存最新的UserLabel”可以是在消息发送方一侧实施，或者，设置UserLabel存储模块，在该UserLabel存储模块中，根据相应账号保存对应的UserLabel。

所述UserLabel存储模块可以是一个设备，例如一台服务器，中的一个存储装置。

所述UserLabel存储模块也可以是一个集群设备，或是一个存储网络，面向外部提供 UserLabel查询业务。

所述UserLabel存储模块接收携带了目标账号的查询指令，根据指令中携带的目标账号，查找对应的UserLabel，将查询结果回复给查询请求者

较佳地，所述的“根据相应账号对应保存最新的UserLabel”是在消息接收方一侧实施。例如，在互联网账号服务器中，在该账号对应的账户里直接保存指配给该账号的最新UserLabel。还例如，对于电信网来说，根据手机号码保存该手机号码最新的UserLabel，是在移动通信网络中相应号码归属的HLR中实施。

一、所述消息是接收的，携带了目的账号和目的UserLabel的消息

例如，源服务器接收自客户端的，携带了目的账号和目的UserLabel的消息。

还例如，目的服务器接收来自源服务器的，携带了目的账号和目的UserLabel的消息。

例如，用户A给用户B发送消息，消息中携带的目的账号是用户B的账号，目的UserLabel 是用户B的UserLabel。

用户A的客户端将所述消息发送给接入的服务器，即源服务器；所述源服务器收到所述消息后，获取所述消息的目的账号的最新的UserLabel，与消息的目的UserLabel比较；如果二者一致，则按照正常流程处理；否则，按照异常流程处理。这里，所述按正常流程处理可以是：将所述消息发送给用户B对应的目的服务器；所述按照异常流程处理是：丢弃该消息，或向用户A的客户端回复表示“UserLabel已更新”的异常报告。

或者，用户A的客户端将所述消息发送给接入的服务器，即源服务器；所述源服务器按照消息的目的账号，将所述消息发送给用户B对应的目的服务器；所述目的服务器收到所述消息后，获取所述消息的目的账号的最新的UserLabel，与消息的目的UserLabel比较；如果二者一致，则按照正常流程处理；否则，按照异常流程处理。这里，所述按正常流程处理是：将所述消息发送给B的客户端；所述按照异常流程处理是：丢弃该消息，或向所述源服务器回复表示“UserLabel已更新”或“该账号已经更换用户”的异常报告。

还例如，所述消息接收方是B的客户端，对于接收的携带了目的账号和目的UserLabel 的消息，在步骤11中，B的客户端获取本地保存的B的UserLabel，作为所述消息的目的账号的最新的UserLabel。在步骤12中，B的客户端比较所述最新的UserLabel与消息的目的 UserLabel；如果二者一致，则按照正常流程处理，例如，提示用户收到消息，并将消息保存在本地供用户查看；否则，按照异常流程处理，例如，直接删除该消息。

实际当中，消息发送方通常保存了发送方用户的相应好友的通讯录，该通讯录中登记了相应好友的账号。在现有通讯录基础上，进一步保存相应好友的UserLabel。这样，用户在给相应好友发送消息时，直接从通讯录中获取对应好友的账号和UserLabel，将该账号和 UserLabel作为消息的目的账号和目的UserLabel。

例如，消息发送方是用户客户端。这种情况下，可以在客户端一侧，根据好友账号，保存对应的UserLabel。例如在客户端通讯录中不只保存相应好友的名字和账号信息，还保存相应好友的UserLabel，以用于填写消息的目的UserLabel。

还例如，消息发送方是相应用户客户端接入的网络侧设备。在这种情况下，所述网络侧设备可以在该用户的账户数据中，保存其相应好友被指配的UserLabel，以用于填写消息的目的UserLabel。

用户在获取一个好友的账号时，或者在查询一个好友的信息时，或者在添加一个好友时，可以同时获取该好友的最新UserLabel，然后将该好友的账号和最新UserLabel保存到自己的通讯录中。

一个用户在成功注册一个账号后，注册服务器可以将指配给其的UserLabel返回给该用户，这样，该用户就能够知道与自己账号匹配的UserLabel。这样，用户在将自己的账号告知朋友时，可以同时告知对方自己的UserLabel。

现有社交场景，人们交换通信账号(电信网的电话号码，或互联网的通信APP账号，例如陌陌号，QQ号码)时，只提供相应的账号信息。如果让用户之间记忆对方的UserLabel，或者增加交换的社交信息元素，则会影响用户体验。

较佳地，网络侧设置UserLabel存储模块，提供UserLabel查询服务，在该UserLabel 存储模块中，根据相应账号保存对应的UserLabel。这样，用户在将一个好友的账号加入通讯录时，客户端向网络侧发送UserLabel查询请求，请求中携带所述账号。

所述UserLabel存储模块收到所述查询请求后，根据所述账号查询对应的UserLabel，将查询结果回复给所述客户端；客户端将返回的UserLabel和所述账号保存在通讯录中。

或者，客户端接入的服务器向所述UserLabel存储模块发送查询请求，请求中携带目标账号；所述UserLabel存储模块收到所述查询请求后，根据所述账号查询对应的UserLabel，将查询结果回复给查询请求者，查询请求者将得到的UserLabel和所述账号保存在相应通讯录中，并通知相应客户端更新通讯录。

对于互联网账号服务器来说，通常由该服务器来实施所述UserLabel存储模块。

例如，在陌陌客户端，根据陌陌号码查询目的陌陌用户时，服务器根据所述陌陌号，查询所述最新的UserLabel，在回复给查询请求者的信息中可以包括该陌陌号码对应的UserLabel信息。这样，在所述陌陌客户端，就可以执行在通讯录中保存所述陌陌号和对应的UserLabel信息的操作。

实际当中，上述在现有通讯录基础上，进一步保存相应好友的UserLabel的操作，可以在网络侧来实现。例如，现有技术中，在一个账号归属的服务器中，对应该账号的账户信息里，包括用户的好友列表，在好友列表中保存相应好友的名字和账号。按照本发明，扩展现有的好友列表，增加UserLabel字段，用于登记相应好友的UserLabel。

这样，上述在根据一个好友的账号，查询该好友的UserLabel时，直接将所述UserLabel 存储模块返回的查询结果保存在网络侧的用户账户中。

这种情况下，用户在从客户端给一个通讯录好友发送信息时，从客户端发送到服务器的消息里，可以和现有技术一样，不必包括对应好友的UserLabel。服务器侧在收到该消息后，根据消息中携带的目的账号，从用户的好友列表中获取对应的UserLabel，将该UserLabel 添加到该消息中，作为消息的目的UserLabel，而后将所述消息发送给接收方。

本发明中，通过给每个账号指配UserLabel，并在发送的消息时，在消息中携带目的 UserLabel，使得通过比较消息中携带的目的UserLabel与针对消息的目的账号保存的UserLabel，可以判断消息的目的账号是否有效，从而避免了对收信方的骚扰，并保护了消息发送方，以及所述账号的老用户的隐私。

所述的UserLabel存储模块可以独立设置。为了节约网络建设和运营成本，提高业务处理效率，也可以直接在所述的消息接收方实现UserLabel存储模块。

例如：

所述步骤14进一步是步骤14B：向消息的发送方回复保存的所述目的账号最新的UserLabel。这样，通过该异常处理流程，消息发送方可以达到查询一个账号的UserLabel的目的。

以{约定有效的UserLabel值都大于0}为例，消息发送方可以将消息的目的UserLabel 设置为特殊值0，这样，就会触发步骤14的执行，也即触发步骤14B的执行。

当然，所述步骤14B中，在向消息的发送方回复保存的所述目的账号最新的UserLabel 之前，还进一步判断消息中所携带的目的UserLabel是否为特殊值0，如果是，才执行向消息的发送方回复保存的所述目的账号最新的UserLabel的操作。

按照步骤14B提供的方案，要查询一个账号当前的UserLabel，只需要发送一条消息，在该消息中将该账号作为目的账号，并将消息的目的UserLabel设置为特殊值0，这样，就可以完成关于该账号最新的UserLabel的查询操作。

在所述步骤14B中，进一步判断消息中所携带的目的UserLabel是否为特殊值0，如果是，则继续执行所述的“按照正常流程处理”的相应操作。

所述步骤14B也可以是：判断消息中所携带的目的UserLabel是否为特殊值0，如果是，则按照正常流程处理并向消息的发送方回复保存的所述目的账号最新的UserLabel，否则，向消息的发送方回复保存的所述目的账号最新的UserLabel。

当然，所述步骤14也可以进一步是步骤14C：判断消息中所携带的目的UserLabel是否为特殊值0，如果是，则执行步骤13。这种情况适合于发送方不担心接收方是否更换了用户的情况。例如，发送方从一用户名片或某广告宣传页面得到接收方手机号码，根据该手机号码向接收方发送短信或拨打电话的情况。

所述步骤14进一步是步骤14D：向消息的发送方回复保存的所述目的账号的UserLabel；判断消息中所携带的目的UserLabel是否为特殊值0，如果是，则执行步骤13。

或者，所述步骤14进一步是步骤14E：判断消息中所携带的目的UserLabel是否为特殊值0，如果是，则向消息的发送方回复保存的所述目的账号的UserLabel，然后执行步骤13。

按照步骤14D或步骤14E提供的方案，消息发送方在发送消息时，通过将消息的目的 UserLabel设置为特殊值0，能够同时完成关于目的账号最新的UserLabel的查询操作和相应消息的正常发送操作，不需要额外建设UserLabel存储模块，减少了网络建设费用，并且提高了业务处理效率。

需要说明的是，在步骤14C或步骤14D或步骤14E中，在执行步骤13之前，还可以将消息的目的UserLabel更新为保存的所述目的账号最新的UserLabel。

按照本发明通信控制方法，可以有效避免将要发送给一个账号的老用户的消息发送给该账号的新用户的问题。

二、所述消息是创建的携带了目的账号和目的UserLabel的消息，或待创建的要携带目的账号和具有目的UserLabel的消息

客户A在银行开户时，一般被要求登记客户A的手机号码，或者，某商场在客户A办理会员卡时，要求客户A登记手机号码或email地址。在某种情况下，银行或商场需要向客户A发送信息，例如，需要发送优惠促销广告。如果客户A因为某种原因，更换了手机号码，而其原来手机号码又被其他用户例如用户B注册使用，这种情况下，如果客户A没有及时更新在银行或商场登记的电话号码，那么，本来要发送给客户A的信息，就被发送给用户B了，从而对后者造成骚扰。

按照本发明技术方案，相应客户在登记手机号码时，还登记该手机号码的UserLabel。

相应服务器在要给相应客户发送相关消息时，可以先创建该消息，该消息携带了目的账号，消息的目的UserLabel为所述客户先前登记的UserLabel。然后获取该消息的目的账号的最新的UserLabel，比较所述最新的UserLabel与消息的目的UserLabel；如果二者一致，则按照正常流程处理，例如，按照消息的目的账号将所述消息发送给相应客户；否则，按照异常流程处理，例如，丢弃该消息，或者删除所述客户登记的手机号码。

还例如，按照本发明技术方案，相应服务器在要给相应客户发送相关消息时，可以先获取该消息要携带的目的账号的最新的UserLabel，与消息的目的UserLabel即客户先前登记的UserLabel进行比较；如果二者一致，则按照正常流程处理，例如，创建所述消息，消息的目的账号为客户先前登记的账号，按照该消息的目的账号将所述消息发送给相应客户；否则，按照异常流程处理，例如，结束，或者删除所述客户登记的通信账号。

特别地，用户常常会将一个互联网账号绑定到一个手机号码，例如，将手机号码与微信账号绑定，或者将手机号码与支付宝账号绑定，当用户忘记相应互联网账号的登陆密码时，可以通过提供先前登记的手机号码给相应服务器，由该服务器产生一个验证码，并将该验证码发送给该用户，这样，该用户就可以通过接收的该验证码，来登陆相应的互联网账户，或者重设该互联网账户的登陆密码。

前面说过，这样做，给用户和互联网运营商都提供了极大的便利。但这暗藏风险，用户在更换了手机号码时，其老号码又被新用户注册使用，这种情况下，就会产生安全风险。

例如，在微信提供手机直接登陆微信功能，即，将手机号码本身也作为一个互联网账号来对待。这样，一个用户就可以根据在电信运营商办理的手机号码去尝试登陆微信，如果不知道密码，就可以通过输入手机号码获取验证码的方式重设密码。这样，该电话号码的前一个用户的隐私信息就会泄漏。虽然，用户可以在更换手机号码时，通过更新相应互联网账号所绑定的手机号码以避免这个问题，但这毕竟不是万全之策。因为，用户常常会根据手机号码登陆或绑定很多互联网账号，更新系列的绑定关系不仅仅繁琐，更重要的是，用户很难一时弄清楚自己绑定了多少互联网账号。

为了避免这个问题，可以牺牲一定的便利性，禁止手机号码作为互联网账号，即，禁止根据手机号码登陆互联网账户。但这只是一种弱化问题的手段，仍然还存在这样的风险，例如，后来注册使用老号码的新电信用户通过尝试方式或其他手段获知该号码绑定的非手机号码形式的互联网账号，例如微信号、email地址，等等，通过输入手机号码获取验证码来重设该互联网账户的登陆密码，从而进入相应的互联网账户。

对此，本发明提出，在互联网服务器侧，在需要将一个互联网账号绑定相应手机号码时，还登记该手机号码的UserLabel。

这样，在用户忘记密码，需要通过输入手机号码获取验证码来重设登陆密码时，互联网服务器先根据该手机号码获取当前最新的UserLabel，与对应该手机号码登记的UserLabel 比较，如果二者一致，才产生验证码，并根据该手机号码发送验证码。否则，结束流程。

这样，就可以避免手机号码更换后，其他用户通过注册所述的老手机号码来登陆该老号码绑定的老用户的微信或支付宝的情况发生。

由上可知，按照所述通信控制方法技术思想，还可以对现有的移动通信网络进行改造，从而避免将要发送给一个手机号码的老用户的消息发送给了该手机号码的新用户。在这种应用场景中，所述账号是手机号码。

例如，所述针对相应账号对应保存最新的UserLabel是：设置UserLabel存储模块，在该UserLabel存储模块中，根据相应手机号码保存对应的UserLabel。

所述的{设置UserLabel存储模块，在该UserLabel存储模块中，根据相应手机号码保存对应的UserLabel}也可以是在HLR一侧根据相应手机号码保存对应的UserLabel，例如在用户的签约数据中增加UserLabel项，用于保存该用户被最新指配的UserLabel值。

移动通信运营商可以在用户办理手机号码业务时，将系统当前时间作为用户或用户所选手机号码对应的UserLabel，并将该手机号码与该UserLabel的对应关系保存在UserLabel 存储模块中或者是保存在HLR中。

参见如图2所示，为本发明具体实施例一流程图，在该图中包括如下步骤：

步骤100、SMSC接收短消息，所述短消息中携带了目的号码和目的UserLabel。

步骤101、所述SMSC根据所述短消息中携带的目的号码获取最新的UserLabel。

步骤102、所述SMSC比较所述目的UserLabel与所述最新的UserLabel，如果二者一致，则执行步骤103：按照正常流程处理；否则，执行步骤104：按照异常流程处理。

所述针对相应账号保存最新的UserLabel是：设置UserLabel存储模块，在该UserLabel 存储模块中，根据相应手机号码保存对应的UserLabel。

相应地，所述步骤101是步骤101B：根据所述短消息中携带的目的号码，向设置的UserLabel存储模块发送查询请求，所述UserLabel存储模块获取所述目的号码对应的UserLabel，将查询结果回复给SMSC。

相应地，所述步骤103进一步是步骤103B：所述SMSC根据所述目的号码，向HLR发送路由查询请求，并根据HLR返回的路由信息，向该目的号码拜访的MSC/VLR发送相应的短消息。这里，为了和现有网络兼容，在向该目的号码拜访的MSC/VLR发送相应的短消息时，也可以不携带所述目的UserLabel。当然，也可以通过短消息内容部分来携带所述目的UserLabel。由于兼容性考虑是一种常见技术手段，因此，后续不再于类似场景进行补充说明。

相应地，所述步骤104进一步是步骤104B：丢弃该短消息。

所述HLR返回的路由信息中含有相应目的号码对应的移动台的漫游号码(MSRN)。

单独设置UserLabel存储模块必然增加运营商运营成本，并且，这也不是一种高效的业务处理方式。

较佳地，所述针对相应账号保存最新的UserLabel是：在HLR一侧根据相应手机号码保存对应的UserLabel。

相应地，所述步骤101是：根据所述目的号码，向HLR发送路由查询请求，从HLR返回的查询回复中得到所述目的号码对应的UserLabel。这里，HLR在收到所述路由查询请求后，获取所述目的号码对应的路由信息和UserLabel，将该路由信息和UserLabel回复给所述SMSC。

相应地，所述步骤103进一步是：所述SMSC根据HLR返回的路由信息，向相应的MSC/VLR 发送所述短消息。

相应地，所述步骤104进一步是：丢弃该短消息。

例如:

所述针对相应账号保存最新的UserLabel是：在HLR一侧根据相应手机号码保存对应的 UserLabel，所述消息接收方是SMSC。

所述步骤11是根据短消息的目的号码，向相应HLR发送路由查询请求；接收HLR返回的所述目的号码对应的路由信息和最新的UserLabel。所述HLR收到所述查询请求后，获取所述目的号码对应的路由信息和最新的UserLabel，将查询结果回复给查询请求者。

参见如图3所示，为本发明具体实施例二流程图，在该图中包括如下步骤：

步骤200、SMSC接收短消息，所述短消息中携带了目的号码和目的UserLabel。

步骤201、所述SMSC根据所述短消息的目的号码，向HLR发送路由查询请求。

步骤202、HLR收到所述查询请求后，获取保存的所述目的号码对应的路由信息和UserLabel，将查询结果回复给所述SMSC。

步骤203、所述SMSC收到所述查询回复后，比较该查询回复中UserLabel与所述短消息的目的UserLabel，如果二者一致，则执行步骤205：按正常流程处理；否则，执行步骤206：按异常流程处理。

实际当中，SMSC还可以通过异常处理流程，向短消息发送方回复所述目的号码的最新的 UserLabel。

例如，所述步骤104进一步是步骤104B：所述SMSC向短消息发送方回复异常报告，在该报告中携带所获取的所述目的号码的最新的UserLabel。这样，所述短消息发送方要获取一个手机号码的最新UserLabel值时，可以通过发送一条短消息，将该手机号码作为短消息的目的号码，并将携带的目的UserLabel设置为特殊值0，这样，就可以通过消息接收方一侧返回的异常报告来获取该手机号码的最新UserLabel值。

特别地，SMSC在判断短消息的目的UserLabel为0时，还可以继续执行步骤103。这样，就可以将“查询一个手机号码的最新UserLabel”，与“根据该手机号码和最新的UserLabel 发送消息”等，这两个操作合成为一个，从而提高业务处理效率。

例如，所述步骤104进一步是步骤104C：所述SMSC向短消息发送方回复异常报告，在该报告中携带所获取的所述目的号码的最新的UserLabel；判断所述短消息的目的UserLabel 是否为0，如果是，则执行步骤103。

或者，所述步骤104进一步是步骤104D：所述SMSC判断所述短消息的目的UserLabel 是否为0，如果是，则向短消息发送方回复异常报告，在该报告中携带所获取的所述目的号码的最新的UserLabel，然后执行步骤103。

也可以将本发明对通信的控制后移到HLR侧来实现。

例如:

所述针对相应账号对应保存最新的UserLabel是：在HLR一侧根据相应手机号码保存对应的UserLabel，所述消息接收方是HLR。

参见如图4所示，为本发明具体实施例三流程图，在该图中包括如下步骤：

步骤301、HLR接收路由查询消息，所述消息中携带了目的号码和目的UserLabel。

步骤302、所述HLR根据所述消息中携带的目的号码获取相应的路由信息和最新的UserLabel，与消息中携带的目的UserLabel比较，如果二者一致，则执行步骤303：按照正常流程处理；否则，执行步骤304：按照异常流程处理。

这样，一个SMSC在根据短消息的目的号码向相应HLR发送路由查询消息时，在该消息中携带短消息的目的UserLabel，这样，所述HLR就可以根据保存的目的号码的最新UserLabel 来对短消息的发送进行控制。

例如，所述步骤303是：向SMSC返回所述路由信息。所述步骤304是：向SMSC返回异常报告，告知SMSC，所述短消息的目的号码的最新UserLabel已经变化。

当然，也可以将对通信的控制后移到MSC/VLR侧来实现。这种情况下，如果不改变现有消息的信元，则可以通过短消息内容部分携带所述短消息的目的UserLabel。

例如:

所述针对相应账号保存最新的UserLabel是：在HLR一侧根据相应手机号码保存对应的 UserLabel，MSC/VLR在手机用户位置更新时，还从HLR中获取该用户的最新UserLabel。

所述消息接收方是MSC/VLR。

参见如图5所示，为本发明具体实施例四流程图，在该图中包括如下步骤：

步骤401、SMSC根据短消息的目的号码向HLR发送路由查询消息，根据HLR回复的路由查询消息，将该短消息发送给MSC/VLR，所述短消息中携带了目的UserLabel。

步骤402、所述MSC/VLR收到所述短消息后，获取所述目的号码对应的最新UserLabel，与所述目的UserLabel比较，如果二者一致，则执行步骤403：按照正常流程处理；否则，执行步骤404：按照异常流程处理。

这样，一个SMSC在根据HLR返回的路由信息向相应的MSC/VLR发送短消息时，在该消息中携带目的UserLabel，这样，所述MSC/VLR就可以根据保存的所述目的号码对应的最新 UserLabel来对短消息的发送进行控制。

例如，所述步骤403是：按照正常流程，将所述短消息发送给用户手机终端。所述步骤 304是：向SMSC返回异常报告，告知SMSC，所述短消息的目的号码的最新UserLabel已经发生变化。

实际当中，一个账号被注销后，立即在所述UserLabel存储模块中将该账号对应的UserLabel更新为最新值，以便后续用户注册使用该账号。这样有一个好处，就是，当一个老用户注销了某个账号后，即使还没有新用户注册使用该账号，那么，按照上述本发明提供的技术方案，也不会再执行给该号码的老用户发送消息这样的无意义操作了。

按照本发明提供的通信控制方法技术方案，特别地，基于上述相关实施例提供的对于短消息发送的控制方法的技术方案，本发明首先提出一种新的手机号码与相应互联网账号的捆绑关系，基于该新的捆绑关系，本发明提出新的验证码发放控制流程，即一种新的验证码发放控制方法；基于该新的捆绑关系，本发明还提出一种新的绑定关系建立方法。通过实施这两种新方法提供的技术方案，可以有效解决“微信捆绑手机号码”或“支付宝捆绑手机号码”，等等，目前广泛应用的“互联网账号捆绑手机号码”现有方案所存在的安全隐患问题。

本发明提供的手机号码与相应互联网账号的捆绑关系是：在原来仅根据互联网账号保存手机号码这一捆绑关系的基础上，增加UserLabel要素，即根据互联网账号保存捆绑的手机号码和对应的UserLabel。参见如表2 所示的绑定关系表。

表2

互联网账号	手机号码	UserLabel
			互联网账号1	手机号码1	UserLabel1
互联网账号2	手机号码2	UserLabel2
			互联网账号3	手机号码3	UserLabel3
互联网账号4	手机号码4	UserLabel4
			互联网账号5	手机号码5	UserLabel5
互联网账号6	手机号码6	UserLabel6
			互联网账号7	手机号码7	UserLabel7

按照该表，根据一个互联网账号，可以获取对应绑定的手机号码及其UserLabel。同样，根据一个手机号码，可以获取绑定的互联网账号，以及执行绑定时，该手机号码的UserLabel。

作为一种特例，如果互联网账号与相应手机号码之间存在隐式的对应关系，例如，对于每一条捆绑关系记录，都可以从互联网账号本身得到对应绑定的手机号码，例如，互联网账号133XXXXXXXX @163.com与手机号码133XXXXXXXX ，这时，可以将所述捆绑关系中手机号码字段省去。参见如表2 -A所示的绑定关系表。

表2 -A

互联网账号	UserLabel
		133XXXXXXXX @163.com	UserLabel1
138XXXXXXXX @163.com	UserLabel2
		135XXXXXXXX @163.com	UserLabel3

按照该表，可以从绑定关系记录中所述互联网账号得到对应捆绑的手机号码。例如，通过手机号码注册微信，或通过手机号码注册163信箱，这时，可以将该手机号码作为登陆账号来登陆微信或163信箱。

后面以如表2 所示的绑定关系表为例进行说明，但不用于限定。

在需要根据一个手机号码发送短消息时，先执行UserLabel验证操作：比较捆绑关系记录中该手机号码对应的UserLabel与该手机号码的最新UserLabel，如果二者一致，则验证通过，这时，才执行短消息创建或短消息发送流程；如果二者不一致，则不再创建或发送相应的短消息。这样，可以有效阻止要发送给一个手机号码的老用户的短消息被发送给该手机号码的新用户。这样，就可以有效解决银行服务器在给相应账号捆绑的手机号码发送短消息时，因为该手机号码被老用户注销而被新用户注册使用的情况下，而将该短消息发送给了所述的新用户。

正是基于这种思想，本发明还提出如下两种验证码发放控制方法，这两种方法都预先建立了相应互联网账号与对应手机号码的捆绑关系，在相应捆绑关系记录中，登记了对应手机号码的最新UserLabel。参见如表2 所示的绑定关系表或如表2 -A所示的绑定关系表。

服务器在触发了验证码发放流程时，执行“按照本发明提供的验证码发放控制方法实施”的验证码发放流程，可以避免将要发送给一个手机号码的老用户的验证码发送给了该手机号码的新用户的情况。

触发服务器启动验证码发放流程的方式有很多。

例如，用户登陆一个互联网账户时，忘记密码，直接请求服务器按照事先捆绑的手机号码发送验证码，服务器收到该请求后，即可触发验证码发放流程。这里，所述请求中携带相应互联网账号，服务器根据该账号确定相应捆绑关系记录；或者，所述请求中携带用户输入的手机号码，服务器根据该手机号码确定相应捆绑关系记录。

还例如，为了增强安全性，或者为了减少服务器被骚扰的情况，客户端还要求用户输入手机号码，在向服务器请求发送验证码时，还携带用户输入的手机号码。服务器收到该请求后，判断该手机号码是否是对应账号捆绑的手机号码，如果不是，则结束流程；否则，才触发验证码发放流程。这里，所述请求中携带相应互联网账号，服务器根据该账号确定相应捆绑关系记录。

还例如，在从互联网账号能够导出捆绑的手机号码的情况下，客户端在请求服务器发送验证码时，可以只提供手机号码。这种情况下，服务器可以直接根据该手机号码确定对应的捆绑关系，并在确定了捆绑关系记录后，触发验证码发放流程。

特别地，无论是否能够从互联网账号导出捆绑的手机号码，客户端都可以只要求用户提供手机号码，并获取用户输入的手机号码后，向服务器请求发送验证码，在请求中携带该手机号码。相应服务器收到该请求后，根据该手机号码确定对应的捆绑关系记录，并在找到相应捆绑关系记录后触发验证码发放流程。

在无法从互联网账号导出捆绑的手机号码的情况下，较佳地，客户端在向服务器请求发送验证码时，让用户输入相应互联网账号和对应的手机号码，在向服务器发送相应请求时，携带用户输入的相应互联网账号和对应的手机号码，服务器收到该请求后，直接根据所述互联网账号和对应的手机号码来确定捆绑关系记录，并在找到了匹配的记录后，才触发验证码发放流程。

验证码发放控制方法一

该方法是基于所述UserLabel验证操作在ESME侧进行的。参见如图6所示，为本发明验证码发放控制方法一流程图，在该图中包括如下步骤：

步骤31、服务器获取相应捆绑关系记录中手机号码的最新UserLabel。

步骤32、所述服务器比较所述最新的UserLabel与所述绑定关系记录中的UserLabel，如果二者一致，则执行步骤33：产生验证码，按照所述手机号码，通过短消息发送产生的验证码；否则，结束流程。

在步骤32中，如果二者不一致，说明所述手机号码已经更换了用户，这时，可以解除该手机号码对应的绑定关系。

可以设置UserLabel存储模块，在所述UserLabel存储模块中，根据相应手机号码保存对应的UserLabel，使得SMSC或ESME能够根据一个手机号码查询到对应的UserLabel。这样，所述步骤31进一步是：根据所述手机号码，从设置的UserLabel存储模块中获取最新的 UserLabel。

UserLabel存储模块存放的是移动通信网络的用户数据，直接开放给ESME访问，会增加互联网业务运营商与电信网业务运营商之间的接口，不利于管理。因此，实际当中，建议选择验证码发放控制方法二。

验证码发放控制方法二

该方法是基于所述UserLabel验证操作在包括了SMSC的移动通信网络侧进行的。参见如图7所示，为本发明验证码发放控制方法二流程图，在该图中包括如下步骤：

步骤51、服务器产生验证码。

步骤52、所述服务器根据相应捆绑关系记录中手机号码和UserLabel，发送所产生的验证码。

以{步骤52是：所述服务器根据相应捆绑关系记录中手机号码，通过短消息发送该验证码，在所述短消息中携带所述绑定关系记录中的UserLabel作为目的UserLabel}为例。

当所述得到的绑定关系记录中的UserLabel与所述手机号码的最新UserLabel一致时，该短消息能够透过移动通信网络，传送给相应的手机终端，否则，该短消息将被滤掉。

例如，相应的SMSC收到所述服务器发送的短消息后，根据短消息的目的号码，从设置的 UserLabel存储模块查询对应的UserLabel，与所述短消息中携带的目的UserLabel进行比较，如果二者一致，则按照正常流程处理；否则，按照异常流程处理。例如，所述按正常流程处理是：按照所述短消息的目的号码，向相应的HLR发送路由查询请求，以及前面所述的后续处理流程；所述按照异常流程处理是：结束短消息发送流程，丢弃该短消息。

通过设置UserLabel存储模块，在所述UserLabel存储模块中，根据相应手机号码保存对应的UserLabel，使得SMSC或ESME能够根据一个手机号码查询到对应的UserLabel。

移动通信运营商在用户注册手机号码时，可以将系统当前时间作为该手机号码最新的 UserLabel，并将该手机号码与该UserLabel的对应关系保存在UserLabel存储模块中。

单独设置UserLabel存储模块会增加网络建设和运营成本，因此，较佳地，直接在所述手机号码归属的HLR中，根据该手机号码保存对应的UserLabel。这样，相应HLR除了提供路由查询功能外，还提供UserLabel查询功能。

例如：相应的SMSC收到所述服务器发送的短消息后，按照所述短消息的目的号码，向相应的HLR发送路由查询请求，所述HLR收到该查询请求后，查询所述目的号码对应的路由信息和最新的UserLabel，将查询结果回复给所述SMSC，所述SMSC收到该查询结果后，比较所述最新的UserLabel与所述短消息的目的UserLabel，如果二者一致，则按照正常流程处理；否则，按照异常流程处理。例如，所述按正常流程处理是：按照HLR返回的路由信息将所述短消息发送给相应的MSC/VLR；所述按照异常流程处理是：结束短消息发送流程，丢弃该短消息。

由上可知，当所述电话号码最新的UserLabel与短消息中携带的UserLabel一致时，能够通过移动通信网络，将所述短消息发送给对应的手机终端；如果二者不一致，则所述短消息将在移动通信网络中被丢弃，从而无法到达相应手机号码当前的移动终端。这样，就保护了相应手机号码的老用户的互联网账号的安全。

所述SMSC按照异常流程处理可以是：向所述服务器一侧发送表示“相应手机号码的 UserLabel已经更新”的异常报告。

特别地，所述服务器在收到SMSC回复的消息后，如果判断绑定的手机号码的UserLabel 已经更新，则可以解除该手机号码与相应互联网账号的绑定关系。例如，所述服务器收到表示“相应手机号码的UserLabel已经更新”的异常报告后，解除该手机号码与相应互联网账号的绑定关系。

还例如：相应的SMSC收到所述服务器发送的短消息后，按照所述短消息的目的号码，向相应的HLR发送路由查询请求，请求中还携带所述短消息的目的UserLabel，所述HLR收到该查询请求后，查询所述目的号码对应的路由信息和最新的UserLabel，比较所述最新的 UserLabel与所述短消息的目的UserLabel，如果二者一致，则按照正常流程处理；否则，按照异常流程处理。例如，所述按正常流程处理是：将包括对应路由信息的查询结果回复给所述SMSC，这样，所述SMSC就可以按照HLR返回的路由信息将所述短消息发送给相应的MSC/VLR。所述按照异常流程处理是：向所述SMSC回复表示“所述目的号码对应的用户已经变化”的回复消息。

本发明还提供几种手机号码与相应互联网账号的捆绑关系建立方法：

手机号码与相应互联网账号的捆绑关系建立方法一

按照该方法建立所述捆绑关系时，服务器从客户端获取对应的UserLabel。

如图8所示，为捆绑关系建立方法一流程图，在该图中包括如下步骤：

步骤71、服务器接收当前互联网账号要绑定的手机号码和对应的UserLabel。

例如，客户端在用户执行绑定操作时，提示用户输入要绑定的手机号码和对应的UserLabel；客户端将要绑定的手机号码和对应的UserLabel发送给服务器。

步骤79、所述服务器根据当前互联网账号，在如表2 所示的绑定关系表中保存所述手机号码与所述UserLabel。例如，所述服务器将所述手机号码和UserLabel保存在所述互联网账号对应的账户记录中。

为了避免用户输错要绑定的手机号码和UserLabel，较佳地，在步骤79之前还包括手机号码和UserLabel初验子流程。这种情况下，服务器在初验通过时，才执行步骤79。服务器在初验失败时，结束流程。

例如，设置UserLabel存储模块，在该UserLabel存储模块中，根据相应手机号码保存对应的UserLabel。

所述初验子流程可以包括如下步骤：

步骤V11、所述服务器根据所述手机号码，从设置的UserLabel存储模块中获取最新的 UserLabel。

步骤V12、所述服务器比较所述最新的UserLabel与在步骤71中接收的UserLabel，如果二者一致，则执行步骤V13；否则，初验失败。

步骤V13、所述服务器产生验证码，根据所述手机号码，通过短消息发送该验证码。

步骤V14、所述服务器接收来自客户端返回的验证码，与在步骤V13中产生的验证码进行比较，如果二者一致，则初验通过；如果二者不一致，则初验失败。

还例如，所述初验子流程包括如下步骤：

步骤V21、所述服务器产生验证码，根据所述手机号码，通过短消息发送该验证码和所述UserLabel。

步骤V22、所述服务器接收来自客户端返回的验证码，与在步骤V21中产生的验证码进行比较，如果二者一致，则初验通过；如果二者不一致，则初验失败。

需要说明的是，本发明中所述的通过短消息携带所述UserLabel，可以通过短消息内容部分来携带，也可以是通过扩展消息信元的方式来携带。后面不再重述。

前面提到，按照本发明提出的通信控制方法，可以根据一个电话号码的最新UserLabel 对短消息的发送进行控制，这样，只有当所述短消息的目的号码和其携带的UserLabel都正确无误时，才能通过移动通信网络，将所述短消息发送给相应的手机终端。

例如，在HLR一侧根据相应手机号码保存对应的UserLabel，在步骤V21之后，在移动通信网络侧执行以下子流程，在该子流程中，包括如下步骤：

步骤T11、相应的SMSC收到所述短消息后，根据短消息的目的号码，向对应的HLR发送路由查询消息。

步骤T12、所述HLR收到所述路由查询消息后，获取所述目的号码对应的路由信息和最新的UserLabel，发送给所述SMSC。

步骤T13、所述SMSC比较所述最新的UserLabel与所述短消息携带的UserLabel是否一致，如果一致，则按照正常流程处理；否则，按照异常流程处理。

所述按正常流程处理是:所述SMSC按照回复的路由信息，向对应的MSC/VLR发送所述短消息，由所述MSC/VLR将所述短消息发送给用户手机终端。

所述按异常流程处理可以是：向所述服务器一侧返回表示“UserLabel异常”的回复消息，所述服务器收到该消息后，得知初验失败，即要绑定的手机号码和UserLabel无效，于是，放弃绑定操作。

还例如，设置UserLabel存储模块，在该UserLabel存储模块中，根据相应手机号码保存对应的UserLabel。在步骤V21之后，在移动通信网络侧执行如下子流程，在该子流程中，包括如下步骤：

步骤T21、相应的SMSC收到所述短消息后，根据短消息的目的号码，从设置的UserLabel 存储模块中获取该目的号码最新的UserLabel。

步骤T22、所述SMSC比较所述最新的UserLabel与所述短消息携带的UserLabel是否一致，如果一致，则按照正常流程处理；否则，按照异常流程处理。

所述按正常流程处理是:所述SMSC根据短消息的目的号码，向相应的HLR发送路由查询消息；所述HLR收到所述路由查询消息后，获取所述目的号码对应的路由信息发送给所述 SMSC；所述SMSC按照该HLR回复的路由信息，向对应的MSC/VLR发送所述短消息，由所述MSC/VLR将所述短消息发送给用户手机终端。

上面所述移动终端收到所述验证码后，相应的用户即可将该验证码输入到相应的账户客户端。所述客户端获取用户输入的所述验证码后，向服务器侧发送该验证码。

所述按异常流程处理可以是：向所述服务器一侧返回表示“UserLabel异常”的回复消息，所述服务器收到该消息后，得知验证失败，即要绑定的手机号码和UserLabel无效，于是，放弃绑定操作。

在执行绑定操作时，还让用户输入对应手机号码的UserLabel的做法，会大大降低用户的体验。因此，较佳地，由服务器一侧来获取相应手机号码的UserLabel。

服务器一侧可以通过发送UserLabel查询指令来获取当前要绑定手机号码的UserLabel。

例如，设置UserLabel存储模块，在该UserLabel存储模块中，根据相应手机号码保存对应的UserLabel。通过向该UserLabel存储模块发送携带目标电话号码的UserLabel查询请求，来获取对应的UserLabel。所述UserLabel存储模块收到该查询请求后，根据携带的目标电话号码，获取对应的UserLabel，将查询结果回复给查询请求者。

所述的发送UserLabel查询指令也可以是发送特殊短消息，通过通信网络侧回复的异常报告来获取当前要绑定手机号码的UserLabel。

手机号码与相应互联网账号的捆绑关系建立方法二

按照该方法建立所述捆绑关系时，服务器直接从移动通信网络侧获取当前要绑定手机号码的UserLabel。

如图9所示，为捆绑关系建立方法二流程图，在该图中包括如下步骤：

步骤81、服务器接收当前互联网账号要绑定的手机号码。

步骤82、所述服务器从设置的UserLabel存储模块中获取所述手机号码最新的UserLabel。

步骤89、所述服务器根据当前互联网账号，在如表2 所示的绑定关系表中保存所述手机号码与所述最新的UserLabel。

为了避免用户输错要绑定的手机号码，较佳地，在步骤89之前还包括手机号码初验子流程。这种情况下，服务器在初验通过时，才执行步骤89。服务器在初验失败时，结束流程。

所述初验子流程包括如下步骤：

步骤V31、所述服务器产生验证码，根据所述手机号码，通过短消息，发送该验证码。

步骤V32、所述服务器接收来自客户端返回的验证码，与在步骤V31中产生的验证码进行比较，如果二者一致，则初验通过；如果二者不一致，则初验失败。

所述移动终端收到所述验证码后，相应的用户即可将该验证码输入到相应的账户客户端。所述客户端获取用户输入的所述验证码后，向服务器侧发送该验证码。服务器收到该验证码后，与之前产生的所述验证码进行比较，如果二者一致，则初验通过，完成绑定操作，例如，按照相应互联网账号，在如表2 所示的绑定关系表中保存所述手机号码与UserLabel；否则，初验失败，放弃绑定操作。

在步骤82中，“所述服务器直接从设置的UserLabel存储模块中获取所述手机号码最新的UserLabel”这种做法会增加移动通信业务运营商与互联网业务运营商之间的业务接口，不利于运营管理。

较佳地，所述服务器利用发送特殊送短消息机制，从移动通信网络侧获取相应手机号码的最新UserLabel。这样，相应的SMSC通过异常报告，向所述服务器返回对应短消息的目的号码的最新UserLabel。这种情况下，所述服务器就可以通过发送异常短消息来获取要绑定手机号码的最新UserLabel。参见本发明通信控制方法的相关实施例，这里不再转摘。

手机号码与相应互联网账号的捆绑关系建立方法三

按照该方法建立所述捆绑关系时，服务器直接从移动通信网络侧获取当前要绑定手机号码的UserLabel。

如图10所示，为捆绑关系建立方法三流程图，在该图中包括如下步骤：

步骤91、服务器接收当前互联网账号要绑定的手机号码。

步骤92、所述服务器产生验证码，根据所述手机号码，发送短消息，在该短消息中携带该验证码，以及目的UserLabel值0。

步骤98、所述服务器接收SMSC返回的所述手机号码的最新UserLabel；接收来自客户端返回的验证码，与在步骤92中产生的验证码进行比较，如果二者不一致，则结束流程；如果二者一致，则执行步骤99。

步骤99、所述服务器根据当前互联网账号，在如表2 所示的绑定关系表中保存所述手机号码与所述最新UserLabel。

前面提到，按照本发明提出的通信控制方法，可以根据一个电话号码的最新UserLabel 对短消息的发送进行控制，这样，当所述短消息的目的号码和其携带的UserLabel都正确无误时，能顺利通过移动通信网络，将所述短消息发送给相应的手机终端。这种情况下，通过将短消息的目的UserLabel设置为特殊值0，从而触发相应的异常处理流程，通过该异常处理流程，可以获取该短消息目的号码的最新UserLabel，并且，还能实现将所述短消息发送给相应的手机终端的目的。从而减少网络建设开支，并能提高业务运行效率。

例如，在步骤92之后，在移动通信网络侧执行以下子流程，在该子流程中，包括如下步骤：

步骤T31、相应的SMSC收到所述短消息后，根据该短消息的目的号码，向对应的HLR发送路由查询消息。

步骤T32、所述HLR收到所述路由查询消息后，获取所述目的号码对应的路由信息和最新的UserLabel，发送给所述SMSC。

步骤T33、所述SMSC比较所述最新的UserLabel与所述短消息携带的UserLabel是否一致，如果一致，则执行步骤T34：按照正常流程处理；否则，执行步骤T35：按照异常流程处理。

所述步骤T34是:所述SMSC按照回复的路由信息，向对应的MSC/VLR发送所述短消息，由所述MSC/VLR将所述短消息发送给用户手机终端。

所述步骤T35可以是：向所述服务器一侧返回表示“UserLabel异常”的回复消息，该消息中还携带了所述目的号码的最新UserLabel；所述SMSC还进一步判断所述目的UserLabel 是否为0，如果是，则接着执行步骤T34。

所述步骤T35可以是：判断所述目的UserLabel是否为0，如果是，则向所述服务器一侧返回表示“UserLabel异常”的回复消息，该消息中还携带了所述目的号码的最新UserLabel，然后接着执行步骤T34；否则，即所述目的UserLabel不为0，则向所述服务器一侧返回表示“UserLabel异常”的回复消息，该消息中还可以携带所述目的号码的最新UserLabel。

还例如，在步骤92之后，在移动通信网络侧也可以是执行如下子流程，在该子流程中，包括如下步骤：

步骤T41、相应的SMSC收到所述短消息后，根据短消息的目的号码，从设置的UserLabel 存储模块中获取该目的号码最新的UserLabel。

步骤T42、所述SMSC比较所述最新的UserLabel与所述短消息携带的UserLabel是否一致，如果一致，则执行步骤T43：按照正常流程处理；否则，执行步骤T44：按照异常流程处理。

所述步骤T43是:所述SMSC根据短消息的目的号码，向相应的HLR发送路由查询消息；所述HLR收到所述路由查询消息后，获取所述目的号码对应的路由信息发送给所述SMSC；所述SMSC按照该HLR回复的路由信息，向对应的MSC/VLR发送所述短消息，由所述MSC/VLR将所述短消息发送给用户手机终端。

所述步骤T44可以是：向所述服务器一侧返回表示“UserLabel异常”的回复消息，该消息中还携带了所述目的号码的最新UserLabel；所述SMSC还进一步判断所述目的UserLabel 是否为0，如果是，则接着执行步骤T43。

所述步骤T44可以是：判断所述目的UserLabel是否为0，如果是，则向所述服务器一侧返回表示“UserLabel异常”的回复消息，该消息中还携带了所述目的号码的最新UserLabel，然后再接着执行步骤T43；否则，即所述目的UserLabel不为0，则向所述服务器一侧返回表示“UserLabel异常”的回复消息，该消息中还可以携带所述目的号码的最新UserLabel。

按照本发明提供的相应方法，在用户手机号码被注销后，即使他人注册使用该手机号码，也会因为后面用户被指配了新的UserLabel，即在移动通信网络中，该手机号码对应的 UserLabel发生了变化，从而阻断了后面用户通过注册的手机号码获取关于前面老用户根据该手机号码绑定的互联网账号的验证码，从而保证了老用户的互联网账户的安全，也免去了老用户针对各个互联网账号，逐一解绑所注销的手机号码的麻烦。

本发明中，所述的发送短消息时，在消息中携带目的UserLabel，可以是通过利用闲置信元或扩展信元，或增加信元的方式来携带所述的UserLabel，也可以是通过短消息内容来携带所述的UserLabel。

例如，互联网服务器在向相应的SMSC发送短消息时，所述SMSC在向相应的HLR发送路由查询消息时，以及，所述SMSC在根据从相应HLR返回的路由信息，来向相应的MSC/VLR发送短消息时，都可以通过利用闲置信元或扩展信元，或增加信元的方式来携带所述的UserLabel。

特别地，互联网服务器在向相应的SMSC发送短消息时，或者所述SMSC在根据从相应HLR 返回的路由信息，来向相应的MSC/VLR发送短消息时，还可以通过短消息内容部分来携带所述的UserLabel。

在用户发信时，消息的目的地址除了按照现有技术携带用户的账号外，还携带该账号当前的UserLabel，即目的UserLabel。目的服务器在收到消息后，根据目的账号查找现有账号表，在查找到对应的现有账号记录后，比较消息携带的UserLabel是否是现有账号对应的 UserLabel，如果是，则按照正常流程处理，否则，按照异常流程处理。

所述按正常流程处理是：目的服务器将收到的消息投放到目的账户的邮箱或信箱，或在目的用户在线时，直接发送给用户客户端。

对于异常消息，可以向发信者一侧回复“目的账号已被注销”或者“目的账号已被新用户使用”的警示消息。这样，就能使新使用该账号的用户免受骚扰，同时避免了原来使用该账号的老用户，及其好友隐私的泄漏。特别地，发信者一侧客户端或服务器在收到所述警示信息消息后，还可以将相应好友记录中对应的账号信息删除，或直接删除该好友记录。

如果用户在发送消息时，只知道目的账号，不知道对应的UserLabel(例如，用户从一张名片上只得到手机号码，而不知道对应的UserLabel)，那么，该用户可以先获取该目的账号对应的UserLabel。

例如，所述用户先向目的账号对应的注册服务器发送UserLabel查询消息，或者账户查询信息，消息中携带所述目的账号，所述注册服务器收到所述查询消息后，根据所述目的账号查询对应账户记录，获取对应的UserLabel，向所述用户返回查询结果，结果中携带所述 UserLabel。所述用户收到该查询结果后，根据所述目的账号，将对应的UserLabel保存在通讯录中。

特别地，在用户首次根据一个目的账号发送消息时，可以在消息中携带目的账号和 UserLabel特殊值0。目的服务器在收到消息后，根据目的账号查找现有账号表，在查找到对应的现有账号记录后，如果发现所述消息中携带的目的UserLabel为0时，还可以进一步将所述目的账号最新的UserLabel回复给所述用户。所述用户在收到所述回复消息后，根据所述目的账号，保存对应的UserLabel。这样，在下一次根据所述目的账号发送消息时，就可以在消息中携带对应的目的UserLabel。

例如，目的服务器在收到所述消息后，获取目的账号最新的UserLabel，与消息携带的 UserLabel比较，如果二者一致，则按照正常流程处理。如果发现消息携带的UserLabel并不是现有账号最新的UserLabel，则进一步判断消息携带的UserLabel是否为0，如果是，则将继续按照正常流程处理，否则，才按异常流程处理。

所述目的服务器在发现所述消息中携带的目的UserLabel为0时，将所述目的账号最新的UserLabel回复给所述消息发送方。所述消息发送方在收到所述回复消息后，根据所述目的账号，保存所述最新的UserLabel。这样，在下一次根据所述目的账号发送消息时，就可以在消息中携带对应的目的UserLabel。

较佳地，在任何情况下，目的服务器都可以在异常处理流程中将所述目的账号最新的 UserLabel回复给相应的消息发送方。

上述在根据目的账号和目的UserLabel发送消息时，还可以在消息中携带源账号和源 UserLabel。这样，消息接收端收到所述消息后，还可以根据消息源账号查找自己保存的通讯录，判断消息中携带的源UserLabel是否和该源账号对应的UserLabel一致，如果不一致，则判断消息源账号异常，这种情况下，消息接收方一侧的服务器或客户端也可以给目的用户发出警示信息，从而帮助目的用户避免损失。

对于本发明中提到的ESME、HLR、MSC、SMSC、VLR等等网络实体以及MSRN等等，更多详细描述，可以参阅3GPP(3GPartnership Project：3G伙伴计划)的相关技术规范文档。

本发明各处所提到的通过短消息发送验证码或其它信息，例如，通过短消息发送验证码的场景，实际当中，也可以是采用其它手段来进行。例如，通过用户到用户消息UUS方式来进行发送。关于UUS，可参见电信规范ITU-T I.257.1用户至用户信令(UUS)，这里不再赘述。

本领域技术人员参照本发明实施例，可以对电信网语音呼叫流程进行修改，以及对电信网用户到用户的短消息流程进行修改。本发明不再面面俱到的进行阐述。

以上仅为本发明的较佳实施例，并非用于限定本发明的保护范围。凡在本发明的精神和原则之类，所作的任何修改、改进、等同替换等均应包含在本发明的保护范围之内。

Claims (5)

1.一种通信控制方法，该方法针对相应账号保存最新的用户标签UserLabel，所述最新的UserLabel通过如下几种方式之一产生：

方式一、在用户注册账号时，获取系统当前时间值或日期值，将该时间值或日期值作为指配给该用户的UserLabel，用以区分先后注册使用同一个账号的不同用户；

方式二、预先设置一个流水号生成器，在用户注册账号时，用该流水号生成器产生的流水号作为指配给该用户的UserLabel，用以区分先后注册使用同一个账号的不同用户；

方式三、针对每一个账号设置一个流水号生成器，以便更好地反映每一个账号被使用的情况，并能减少UserLabel的占用空间；相应地，在用户注册账号时，用该账号对应的流水号生成器产生的流水号作为指配给该用户的UserLabel，用以区分先后注册使用同一个账号的不同用户，也即，注册服务器在用户注册账号时，判断待注册账号是否被使用过，如果没有，则赋予该账号的UserLabel的值为1；如果该账号已经被使用过，则在前一个用户使用该账号时所指配的UserLabel的基础上增加1，得到一个新的UserLabel，将新UserLabel作为当前注册用户的UserLabel；

其特征在于，对于接收的具有目的账号和目的UserLabel的消息，该方法包括以下步骤：

a、获取所述消息的目的账号的最新的UserLabel；

b、比较所述最新的UserLabel与消息的目的UserLabel，如果二者一致，则执行步骤c：按照正常流程处理；否则，执行步骤d：按照异常流程处理；

所述步骤d进一步是步骤d1或步骤d2或步骤d3；

所述步骤d1是：向消息发送方回复所述最新的UserLabel，判断所述目的UserLabel是否为特殊值，如果是，则执行步骤c；

所述步骤d2是：判断所述目的UserLabel是否为特殊值，如果是，则执行步骤c，以及向消息发送方回复所述最新的UserLabel；否则，向消息发送方回复所述最新的UserLabel；

所述步骤d3是：判断所述目的UserLabel是否为特殊值，如果是，则执行如下三种操作中任意一种操作；

所述操作1是：执行步骤c；

所述操作2是：向消息发送方回复所述最新的UserLabel；

所述操作3是：执行步骤c并向消息发送方回复所述最新的UserLabel。

2.根据权利要求1所述的方法，其特征在于，所述账号是手机号码，所述消息是短消息服务中心(SMSC，Short Massage Service Center)接收的，包含有要发送出去的短消息；

所述步骤c进一步是：根据目的号码，向相应归属位置寄存器(HLR，Home LocationRegister)发送路由查询请求；接收HLR返回的所述目的号码对应的路由信息，按照所述路由信息，执行短消息发送操作。

3.根据权利要求1所述的方法，其特征在于，所述账号是手机号码，所述消息是SMSC接收的，包含有要发送出去的短消息；所述针对相应账号保存最新的UserLabel是在HLR一侧实施的；

所述步骤a进一步是：根据目的号码，向相应HLR发送路由查询请求；接收HLR返回的所述目的号码对应的路由信息和最新的UserLabel；

所述步骤c进一步是：按照所述路由信息，执行短消息发送操作。

4.根据权利要求1所述的方法，其特征在于，所述账号是手机号码，所述消息是HLR接收的路由查询消息；所述针对相应账号保存最新的UserLabel是在HLR一侧实施的；

所述步骤a进一步是：根据目的号码，获取对应的路由信息和最新的UserLabel；

所述步骤c进一步是：向消息发送方返回获取的所述路由信息；

所述步骤d1或步骤d2进一步是：判断所述目的UserLabel是否为特殊值，如果是，则向消息发送方回复所述最新的UserLabel和获取的所述路由信息；否则，向消息发送方回复所述最新的UserLabel；

所述步骤d3进一步是：判断所述目的UserLabel是否为特殊值，如果是，则执行如下三种操作中任意一种操作；

所述操作1是：向消息发送方回复获取的所述路由信息；

所述操作2是：向消息发送方回复所述最新的UserLabel；

所述操作3是：向消息发送方回复所述最新的UserLabel和获取的所述路由信息。

5.一种用户标签UserLabel指配方法，其特征在于，设置注销账号表，用于保存各个被注销账号对应的UserLabel，该方法包括以下步骤：

a、判断待注册账号是否在注销账号表中，如果在，则执行步骤b；否则执行步骤c；

所述步骤b是：将待注册账号的现有UserLabel加1，得到新的UserLabel，将新的UserLabel作为待注册账号的UserLabel；

所述步骤c是：将待注册账号的UserLabel设置为1。

Images