本发明公开了一种彩信业务开销户方法和系统，通过对销户的业务流程进行优化，不再简单的直接清除用户数据，而是建立了一个缓冲机制，以减弱某些恶意破坏行为的影响，增强对用户误操作的保护，提升用户对彩信业务的满意度和用户体验。本发明进一步还采用定时清除机制，确保在设定的时间内的重开户请求的用户数据恢复，并实现用户数据的定期清理。本发明适用于彩信中心自服务和彩信相册等彩信业务的开销户处理流程。
1.一种彩信业务开销户方法，其特征在于，包括以下处理过程：
彩信业务系统接收开销户业务请求，所述开销户业务请求至少包括：用户号码和开销户业务类型；
当所述业务请求中的业务类型为开户时，在数据库中增加所述用户号码的彩信业务信息，并设置所述用户号码的业务状态为正常；
当所述业务请求中的业务类型为销户时，在数据库中保留所述用户号码的彩信业务信息，暂停所述用户号码的彩信服务，并设置所述用户号码的业务状态为待删除；
检测在设定的时间内彩信业务系统收到的所述用户号码的开销户请求情况；
如果收到所述用户号码的开销户业务请求，且其业务类型为重开户时，恢复所述用户号码的彩信服务，并将所述用户号码的业务状态由待删除更新为正常；
如果没有收到所述用户号码的开销户业务请求时，在数据库中清除所述用户号码的彩信业务信息。
2.根据权利要求1所述的彩信业务开销户方法，其特征在于，在设置所述用户号码的业务状态为待删除之后还包括以下处理过程：如果收到所述用户号码的开销户业务请求，且其业务类型为销户时，在数据库中清除所述用户号码的彩信业务信息，或者忽略该业务请求不进行处理；
如果收到所述用户号码的开销户业务请求，且其业务类型为开户时，忽略该业务请求不进行处理或者恢复所述用户号码的彩信服务，并将所述用户号码的业务状态由待删除更新为正常。
3.根据权利要求1或2所述的彩信业务开销户方法，其特征在于，所述彩信业务系统接收开销户请求之后，还包括以下处理过程：对开销户请求中的用户号码进行鉴权处理，如果鉴权通过则对所述开销户请求进行处理，否则将所述开销户请求直接丢弃不进行处理。
4.根据权利要求1或2所述的彩信业务开销户方法，其特征在于，所述彩信业务系统接收开销户请求具体为：所述彩信业务系统接收客户端或者业务运营支撑系统发送的开销户请求。
5.根据权利要求4所述的彩信业务开销户方法，其特征在于，在设置用户号码的业务状态之后，还包括以下处理过程：彩信业务系统向发出开销户请求的客户端或者业务运营支撑系统返回开销户响应。
6.一种彩信业务开销户系统，其特征在于，包括：业务处理模块、数据库代理模块和数据库；
所述业务处理模块用于接收开销户业务请求，所述开销户业务请求至少包括：用户号码和开销户业务类型；还用于将所述开销户业务请求转发给所述数据库代理模块；
所述数据库用于存储用户号码的彩信业务数据，所述用户号码的彩信业务数据包括：
用户号码、以及该用户号码对应的彩信业务信息和业务状态；
所述数据库代理模块用于根据所述业务请求中的业务类型对所述数据库中的彩信业务数据进行操作；当所述业务请求中的业务类型为开户时，用于在数据库中增加所述用户号码的彩信业务信息，并设置所述用户号码的业务状态为正常；当所述业务请求中的业务类型为销户时，用于在数据库中保留所述用户号码的彩信业务信息，暂停所述用户号码的彩信服务，并设置所述用户号码的业务状态为待删除；
所述数据库代理模块还用于在所述用户号码的业务状态设置为待删除之后，监测在设定的时间内收到的开销户业务请求；当收到所述用户号码的开销户业务请求，且其业务类型为重开户时，恢复所述用户号码的彩信服务，并将所述用户号码的业务状态由待删除更新为正常；当没有收到所述用户号码的开销户请求时，在数据库中清除所述用户号码的彩信业务信息。
7.根据权利要求6所述的彩信业务开销户系统，其特征在于，所述数据库代理模块监测在设定的时间内收到的开销户业务请求的时候；如果收到所述用户号码的开销户业务请求，且其业务类型为销户时，在数据库中清除所述用户号码的彩信业务信息，或者忽略该业务请求不进行处理；如果收到所述用户号码的开销户业务请求，且其业务类型为开户时，忽略该业务请求不进行处理，或者恢复所述用户号码的彩信服务，并将所述用户号码的业务状态由待删除更新为正常。
8.根据权利要求6或7所述的彩信业务开销户系统，其特征在于，所述业务处理模块还用于在接收开销户业务请求之后，对所述业务请求中的用户号码进行鉴权处理。
9.根据权利要求6或7所述的彩信业务开销户系统，其特征在于，所述业务处理模块用于接收开销户业务请求具体为：所述业务处理模块用于从客户端或者业务运营支撑系统接收开销户业务请求。
10.根据权利要求9所述的彩信业务开销户系统，其特征在于，所述数据库代理模块还用于返回开销户响应到所述业务处理模块；所述业务处理模块还用于将所述开销户响应返回到所述客户端或者业务运营支撑系统。
一种彩信业务开销户方法和系统
技术领域
[0001] 本发明涉及MMS业务（Multimedia Messaging Service多媒体消息业务）的通信领域，尤其涉及彩信中心自服务、彩信相册的开销户方法及系统。
背景技术
[0002] MMS业务是一种能够在手机和手机之间以及手机和Email服务器等其他应用之间传送多媒体内容的消息服务。MMS业务按照用户归属的运营商及所在的区域进行划分，由用户归属的MMSC（彩信中心）为用户提供MMS业务。MMSC自服务可以给用户提供：个性化、黑白名单、主题词过滤和消息大小等方面的设置，以便MMSC能够根据用户的需求和实际情况给用户发送彩信消息。当彩信消息的接收方用户因为各种原因无法正常获取到彩信消息后，MMSC可以将该消息转发给彩信相册系统。彩信相册负责对彩信进行保存，并提醒用户通过一定途径到彩信相册查看该彩信消息。MMSC自服务和彩信相册对用户获取彩信消息的成功率，提升彩信业务服务质量有很大的帮助。
[0003] 用户开销户流程是彩信中心自服务和彩信相册的基础流程。现有的开销户流程中，通常系统在收到销户消息后，会直接清除掉用户的相关数据。如果用户的销户行为是误操作，或用户销户后因其他原因有取消销户的意愿，也无法对数据进行恢复。
发明内容
[0004] 本发明提供了一种彩信业务开销户方法和系统，解决了在一定条件下，彩信系统收到销户消息后，就立即删除用户数据，而无法恢复销户后的用户数据的技术问题。
[0005] 本发明提出的彩信业务开销户方法，包括以下处理过程：
[0006] 彩信业务系统接收开销户业务请求，所述开销户业务请求至少包括：用户号码和开销户业务类型；
[0007] 当所述业务请求中的业务类型为开户时，在数据库中增加所述用户号码的彩信业务信息，并设置所述用户号码的业务状态为正常；
[0008] 当所述业务请求中的业务类型为销户时，在数据库中保留所述用户号码的彩信业务信息，暂停所述用户号码的彩信服务，并设置所述用户号码的业务状态为待删除。
[0009] 优选的，在设置所述用户号码的业务状态为待删除之后还包括以下处理过程：
[0010] 监测在设定的时间内彩信业务系统收到的所述用户号码的开销户请求情况；
[0011] 如果收到所述用户号码的开销户业务请求，且其业务类型为重开户时，恢复所述用户号码的彩信服务，并将所述用户号码的业务状态由待删除更新为正常；
[0012] 如果没有收到所述用户号码的开销户业务请求时，在数据库中清除所述用户号码的彩信业务信息。
[0013] 进一步的，如果收到所述用户号码的开销户业务请求，且其业务类型为销户时，在数据库中清除所述用户号码的彩信业务信息，或者忽略该业务请求不进行处理；
[0014] 如果收到所述用户号码的开销户业务请求，且其业务类型为开户时，忽略该业务请求不进行处理或者恢复所述用户号码的彩信服务，并将所述用户号码的业务状态由待删除更新为正常。
[0015] 在一种实施方式中，所述彩信业务系统接收开销户请求之后，还包括以下处理过程：对开销户请求中的用户号码进行鉴权处理，如果鉴权通过则对所述开销户请求进行处理，否则将所述开销户请求直接丢弃不进行处理。
[0016] 优选的，所述彩信业务系统接收开销户请求具体为：所述彩信业务系统接收客户端或者业务运营支撑系统发送的开销户请求。在设置用户号码的业务状态之后，还包括以下处理过程：彩信业务系统向发出开销户请求的客户端或者业务运营支撑系统返回开销户响应。
[0017] 本发明提出的彩信业务开销户系统，包括：业务处理模块、数据库代理模块和数据库；所述业务处理模块用于接收开销户业务请求，所述开销户业务请求至少包括：用户号码和开销户业务类型；还用于将所述开销户业务请求转发给所述数据库代理模块；所述数据库用于存储用户号码的彩信业务数据，所述用户号码的彩信业务数据包括：用户号码、以及该用户号码对应的彩信业务信息和业务状态；所述数据库代理模块用于根据所述业务请求中的业务类型对所述数据库中的彩信业务数据进行操作；当所述业务请求中的业务类型为开户时，用于在数据库中增加所述用户号码的彩信业务信息，并设置所述用户号码的业务状态为正常；当所述业务请求中的业务类型为销户时，用于在数据库中保留所述用户号码的彩信业务信息，暂停所述用户号码的彩信服务，并设置所述用户号码的业务状态为待删除。
[0018] 优选的，所述数据库代理模块还用于在所述用户号码的业务状态设置为待删除之后，监测在设定的时间内收到的开销户业务请求；当收到所述用户号码的开销户业务请求，且其业务类型为重开户时，恢复所述用户号码的彩信服务，并将所述用户号码的业务状态由待删除更新为正常；当没有收到所述用户号码的开销户请求时，在数据库中清除所述用户号码的彩信业务信息。
[0019] 进一步的，如果收到所述用户号码的开销户业务请求，且其业务类型为销户时，在数据库中清除所述用户号码的彩信业务信息，或者忽略该业务请求不进行处理；如果收到所述用户号码的开销户业务请求，且其业务类型为开户时，忽略该业务请求不进行处理，或者恢复所述用户号码的彩信服务，并将所述用户号码的业务状态由待删除更新为正常。
[0020] 在一种实施方式中，所述业务处理模块还用于在接收开销户业务请求之后，对所述业务请求中的用户号码进行鉴权处理。
[0021] 优选的，所述业务处理模块用于接收开销户业务请求具体为：所述业务处理模块用于从客户端或者业务运营支撑系统接收开销户业务请求。所述数据库代理模块还用于返回开销户响应到所述业务处理模块；所述业务处理模块还用于将所述开销户响应返回到所述客户端或者业务运营支撑系统。
[0022] 采用本发明的彩信业务开销户方法和系统，通过对销户的业务流程进行优化，不再简单的直接清除用户数据，而是建立了一个缓冲机制，以减弱某些恶意破坏行为的影响，增强对用户误操作的保护，提升用户对彩信业务的满意度和用户体验。本发明进一步还采用定时清除机制，确保在设定的时间内的重开户请求的用户数据恢复，并实现用户数据的定期清理。
附图说明
[0023] 图1是本发明实施例一的彩信业务开销户方法流程图；
[0024] 图2是本发明实施例二的彩信业务开销户系统框图；
[0025] 图3是本发明实施例三的重开户处理流程图；
[0026] 图4是本发明实施例四的清除用户数据的处理流程图。
具体实施方式
[0027] 下面通过实施例并结合附图，对本发明的技术方案进行详细说明。
[0028] 实施例一
[0029] 如图1所示的开销户方法实施例的流程图，具体处理包括：
[0030] S101：彩信业务系统收到开户请求；
[0031] S102：系统在数据库中增加此用户的信息，其中用户状态设为“正常”；
[0032] S103：系统返回开户成功响应；
[0033] S104：彩信业务系统收到销户请求；
[0034] S105：系统更新该用户在数据库中的状态为“待删除”，此时该用户被锁定，系统不再给该用户提供服务；
[0035] S106：系统返回销户成功响应；
[0036] S107：如果在设定的时间内，系统收到重新开户请求，则转至S108。如果在设定的时间内，没有收到重新开户请求，则转至S110；
[0037] S108：系统将该用户在数据库中的状态更新为“正常”，此时系统可以重新给该用户提供服务；
[0038] S109：系统返回重新开户成功响应，转至S111；
[0039] S110：系统清除该用户在数据库中的相关信息；
[0040] S111：流程结束。
[0041] 上述步骤S101、S102、S104、S105为基本处理步骤。步骤S107、S108、S110为销户之后在设定时间内的重开户处理流程和用户数据清理流程，为可选处理步骤。步骤S103、S106和S109为响应处理过程，也是本发明的可选处理步骤。
[0042] 需要特别说明的是，在步骤S107中，如果在设定的时间内，系统没有收到重新开户请求的处理方式可以非常灵活。首先，确保在设定时间内没有收到任何请求时，必须转至S110。然后再判断如果收到的是销户请求，则选择转至S110或者忽略该请求不进行处理；如果收到的是开户请求，则选择转至S108或者忽略该请求不进行处理；如果收到的是其他非法请求，则忽略该请求不进行处理。上述几种情况不在图1中进行表示，图1的流程并不限定上述的处理方式。
[0043] 实施例二
[0044] 如图2所示的开销户系统，包括三个基本模块：业务处理模块、数据库代理模块和数据库。
[0045] 业务处理模块，接收开销户业务请求，该开销户业务请求包括用户号码和开销户业务类型等；业务处理模块还将开销户业务请求转发给数据库代理模块。
[0046] 数据库，存储用户号码的彩信业务数据，用户号码的彩信业务数据包括：用户号码、以及该用户号码对应的彩信业务信息和业务状态等；
[0047] 数据库代理模块，根据所述业务请求中的业务类型对数据库中的彩信业务数据进行操作；当业务请求中的业务类型为开户时，在数据库中增加该用户号码的彩信业务信息，并设置该用户号码的业务状态为正常；当业务请求中的业务类型为销户时，在数据库中保留该用户号码的彩信业务信息，暂停该用户号码的彩信服务，并设置该用户号码的业务状态为待删除。然后，数据库代理模块监测在设定的时间内收到的开销户业务请求；当收到该用户号码的重开户请求时，恢复该用户号码的彩信服务，并将该用户号码的业务状态由待删除更新为正常；当没有收到该用户号码的开销户请求时，在数据库中清除该用户号码的彩信业务信息。
[0048] 当收到该用户号码的开销户业务请求，且其业务类型为销户时，在数据库中清除该用户号码的彩信业务信息，或者忽略该业务请求不进行处理；当收到该用户号码的开销户业务请求，且其业务类型为开户时，忽略该业务请求不进行处理，或者恢复该用户号码的彩信服务，并将该用户号码的业务状态由待删除更新为正常。
[0049] 此外，业务处理模块所接收的开销户请求可以来自客户端或者业务运营支撑系统。该客户端用于用户和管理员进行开销户请求的提交操作。用户可以通过客户端对自己的手机号码进行开户和销户。管理员也可以通过客户端完成对本网络用户手机号码的开销户操作。数据库代理模块还可以返回开销户响应到业务处理模块；业务处理模块将开销户响应返回到客户端或者业务运营支撑系统。
[0050] 下面再通过在规定时间内收到重开户请求和未收到重开户请求的具体实施例进行详细说明。
[0051] 实施例三
[0052] 图3是本发明提供的开销户方法中规定时间内重新开户情况的优选处理方案流程，具体包括以下步骤：
[0053] S201：客户端或BOSS（业务运营支撑系统）发送开户请求给业务处理模块；
[0054] S202：业务处理模块收到开户请求后，对开户的号码进行鉴权，判断是否是本网运营商的用户号码。鉴权通过后，将开户请求转发给数据库代理模块；
[0055] S203：数据库代理模块在数据库中查找该号码。如果数据库没有该号码，则将该用户号码的信息插入数据库中，将用户状态设为“正常”；
[0056] S204：数据库代理模块向业务处理模块发送开户响应；
[0057] S205：业务处理模块收到开户响应后，返回响应给客户端或BOSS，开户流程结束；
[0058] S206：客户端或BOSS发送销户请求给业务处理模块；
[0059] S207：业务处理模块收到销户请求后，对需要销户的号码进行鉴权，判断是否是本网运营商的用户号码。鉴权通过后，将销户请求转发给数据库代理模块；
[0060] S208：数据库代理模块将该用户在数据库中的状态更新为“待删除”，此时该用户被锁定，系统不再给该用户提供服务；
[0061] S209：数据库代理模块向业务处理模块发送销户响应；
[0062] S210：业务处理模块收到销户响应后，返回响应给客户端或BOSS；
[0063] S211：客户端或BOSS发送重新开户请求给业务处理模块；
[0064] S212：业务处理模块收到重开户请求后，对开户的号码进行鉴权，判断是否是本网运营商的用户号码。鉴权通过后，将开户请求转发给数据库代理模块；
[0065] S213：数据库代理模块将该用户在数据库中的状态更新为“正常”，此时系统可以重新给该用户提供服务；
[0066] S214：数据库代理模块向业务处理模块发送重开户响应；
[0067] S215：业务处理模块收到重开户响应后，返回响应给客户端或BOSS，流程结束。
[0068] 上述流程中，S201开户请求消息，S206销户请求消息和S211重开户请求消息采用相同的接口结构，其中包括用户号码、开销户类型等字段。开销户类型有开户、销户、重开户三种。业务处理模块和数据库代理模块根据开销户类型的不同，采取相应的处理流程。
[0069] 实施例四
[0070] 图4是本发明提供的开销户方法中规定时间内未重新开户情况的优选处理方案流程，具体包括以下步骤：
[0071] S301～S310对应图3中的S201～S210，不再赘述。
[0072] S311：在设定的时间内，数据库代理模块未收到业务处理模块的重新开户请求。数据库代理模块在定时扫描时发现该用户的“待删除”状态已经超过设定的时间，清除该用户在数据库的相关信息，流程结束。
[0073] 此处，S311步骤中对于在设定时间内收到销户请求或开户请求可以进行灵活的处理，例如可以采用上述实施例一、实施例二的处理方式。
[0074] 以上所述实施例，仅为本发明的较佳实例而已，并非用于限定本发明的保护范围，凡在本发明的精神和原则之内所作的任何修改、等同替换或改进等，均应包含在本发明的保护范围之内。
