CN101763604A - 一种信用数据管理方法和业务平台系统 - Google Patents

Abstract

本发明公开了一种信用数据管理方法，用户凭从服务方获得的授权证书进入业务平台系统，业务平台系统根据授权证书对用户进行验证，验证通过后，才允许用户对服务方进行评价。本发明还公开了一种业务平台系统。采用本发明的信用数据管理方法和业务平台系统，在用户对服务方做出评价之前，首先要根据授权证书对用户进行验证，从而避免了针对服务方的不真实评价，提高了信用记录的准确性和可靠性。

Description

一种信用数据管理方法和业务平台系统

技术领域

本发明涉及数据管理技术领域，特别是涉及一种信用数据管理方法和业务平台系统。

背景技术

随着社会分工的日益细化，在人们的日常生活中存在着多种类型的服务需求。在用户通过业务平台系统选择服务方为其提供服务的过程中，由于用户经验不足，对所需服务的标准服务内容和操作流程不熟悉，服务方有可能侵害用户的合法利益。为了避免用户遭受损失，用户在对服务方进行选择之前，参考业务平台系统，根据该业务平台系统中各个服务方的信用记录进行选择。

在目前的信用数据管理方法和业务平台系统中，允许用户对服务方做出评价，但是并不对做出评价的用户的身份进行验证。因此，服务方有可能冒充用户故意为自身做出正面评价，或者，存在竞争关系的服务方有可能冒充用户故意为对方做出负面评价。总之，采用现有的信用数据管理方法和业务平台系统，有可能存在针对服务方的不真实评价，因此降低了信用记录的准确性和可靠性。

发明内容

本发明提供了一种信用数据管理方法，采用该方法可以提高信用记录的准确性。

本发明还提供了一种业务平台系统，采用该系统可以提高信用记录的准确性。

为达到上述目的，本发明的技术方案是这样实现的：

本发明公开了一种信用数据管理方法，包括：

用户选择服务方提供服务；

用户获取服务方对应的授权证书，所述授权证书中的信息包括：评价验证码、业务平台系统信息、服务方名称、服务方编号、服务方联系方式、服务时间和授权证书有效期中的任意一项或任意多项的组合，其中，不同授权证书的评价验证码互不相同；

用户根据业务平台系统信息向业务平台系统输入授权证书中的信息；

业务平台系统根据输入的授权证书中的信息对用户进行验证，如果验证通过，业务平台系统允许该用户进行评价，并保存用户给予的评价；如果验证不通过，业务平台系统不允许该用户进行评价，返回执行用户向业务平台系统输入授权证书信息的步骤；

对累计保存的评价进行数据处理，生成并存储服务方的信用记录；

所述业务平台系统根据输入的授权证书中的信息对用户进行验证包括：

预先在业务平台系统中保存所有授权证书的评价验证码，业务平台系统在自身预先保存的评价验证码中进行检索，判断是否存在与用户输入的评价验证码相同的评价验证码，如果有，业务平台系统对用户验证通过，否则，验证不通过；

或，

预先在业务平台系统中保存所有授权证书的评价验证码和该评价验证码对应的服务方编号，业务平台系统根据自身预先保存的评价验证码和该评价验证码对应的服务方编号，判断用户输入的评价验证码与服务方编号的对应关系是否正确，如果正确，业务平台系统对用户验证通过，否则，验证不通过；

或，

预先在业务平台系统中保存每一个授权证书中的评价验证码和服务方编号K2，业务平台系统在自身保存的授权证书信息中找到用户输入的评价验证码对应的服务方编号K2，业务平台系统的控制平台产生一个随机数A，发送给用户终端，用户终端产生另一个随机数B，用用户输入的服务方编号K1对B和A进行加密得到数据块Token1＝Enc(B‖A，K1)，用户终端将Token1发送给控制平台，控制平台用自身保存的服务方编号K2解密Token1得到B’和A’，比较A’和A，如一致，业务平台系统对用户验证通过，否则，验证不通过；

或，

预先在业务平台系统中保存每一个授权证书中的评价验证码和服务方编号K12，业务平台系统在自身保存的授权证书信息中找到用户输入的评价验证码对应的服务方编号K12，业务平台系统的控制平台产生一个随机数RB，发送给用户终端，用户终端产生另一个随机数RA，用用户输入的服务方编号K11对RA和RB进行加密得到数据块Token1＝Enc(RA‖RB，K11)，用户终端将Token1发送给控制平台，控制平台用自身保存的服务方编号K12解密Token1得到RA’和RB’，比较RB和RB，如不一致，业务平台系统对用户验证不通过，如一致，控制平台产生一个随机数RC，用控制平台保存的服务方编号K12对RA’和RC进行加密得到数据块Token2＝Enc(RA’‖RC，K12)，将Token2发送给用户终端，用户终端用授权证书中的服务方编号K11解密Token2后，比较RA’和RA是否一致，如一致，业务平台系统对此用户验证通过，否则，验证不通过。

所述用户获取服务方对应的授权证书的步骤包括：

服务方从业务平台系统处获取其对应的授权证书，并由该服务方将该授权证书授予所述用户；

或者，

服务方向业务平台系统发送包括用户联系方式的授予授权证书通知，业务平台系统根据用户联系方式直接向用户发放授权证书。

所述业务平台系统接收到所述授予授权证书通知后，进一步保存该授权证书的信息与对应的用户联系方式；

所述用户进一步向业务平台系统输入自身获得授权证书的联系方式；

所述业务平台系统根据输入的授权证书中的信息对用户进行验证，进一步包括：业务平台系统根据自身保存的授权证书的信息与对应的用户联系方式，判断用户输入的授权证书的信息与该用户的联系方式的对应关系是否正确，如果正确，业务平台系统对用户验证通过，否则，验证不通过。

所述返回执行用户向业务平台系统输入授权证书信息的步骤之前，进一步包括：

业务平台系统记录该用户的因特网协议IP地址和/或浏览器记录标记Cookie和/或用户联系方式，对该IP地址和/或Cookie和/或用户联系方式的验证不通过的次数进行统计和记录，如果验证不通过的次数达到指定次数，则业务平台系统生成一个附加识别码，要求用户输入附加识别码，并对用户输入的附加识别码进行验证，如果用户输入的附加识别码错误，不允许该用户进行评价，如果用户输入的附加识别码正确，返回执行用户向业务平台系统输入授权证书信息的步骤；

和/或，

所述保存用户给予的评价之后，进一步包括：

预先规定设定时间内同一IP地址和/或用户联系方式的最大评价次数，记录进行评价的用户的IP地址和/或用户联系方式以及该IP地址和/或用户联系方式累计的评价次数，如果在设定时间内同一IP地址和/或用户联系方式的用户的评价次数达到最大评价次数，则拒绝该IP地址和/或用户联系方式的用户继续评价。

所述用户对服务方进行评价包括：

按照推荐度将评价划分为若干个不同的评价级别，用户根据自己对该服务方的推荐度选择对应的评价级别；

所述对累计保存的评价进行数据处理包括：

对用户做出的评价级别进行直接累积作为信用记录；

或，将用户做出的评价级别转化成信用积分作为信用记录。

所述评价级别包括：1星、2星、3星、4星和5星，其中1星表示强烈不推荐，2星表示不推荐，3星表示不置可否，4星表示推荐，5星表示强烈推荐；则，所述对累计保存的评价进行数据处理包括：如果评价大于3星，为被评价的服务方增加1分信用积分；如果评价为3星，不改变被评价的服务方的信用积分；如果评价为2星，为被评价的服务方减少10分信用积分；如果评价为1星，为被评价的服务方减少50分信用积分；每16分信用积分采用1颗心形图案表示，每64分信用积分采用1个钻石图案表示，每256分信用积分采用1个皇冠图案表示，每1024个信用积分采用1个金冠图案表示；

和/或，

所述对累计保存的评价进行数据处理包括：

限制服务方在指定时间内增加的信用积分的数量。

本发明还公开了一种业务平台系统，包括：

控制平台，用于与用户终端交互，根据信用数据库中保存的授权证书中的信息和用户输入的授权证书中的信息对用户进行验证，如果验证通过，控制用户终端允许用户对服务方进行评价，如果验证不通过，控制用户终端不允许用户进行评价。

信用数据库，用于保存对用户进行验证所需的授权证书中的信息，所述授权证书中的信息包括：评价验证码、业务平台系统信息、服务方名称、服务方编号、服务方联系方式、服务时间和授权证书有效期中的任意一项或任意多项的组合，不同授权证书的评价验证码互不相同；还用于接收并保存来自用户终端的评价，对累计保存的评价进行数据处理，生成、存储并向用户终端显示服务方的信用记录。

所述控制平台，进一步用于在信用数据库预先保存的评价验证码中进行检索，判断是否存在与用户输入的评价验证码相同的评价验证码，如果有，对用户验证通过，否则，验证不通过；

或，

所述控制平台，进一步用于根据信用数据库预先保存的评价验证码和该评价验证码对应的服务方编号，判断用户输入的评价验证码与服务方编号的对应关系是否正确，如果正确，对用户验证通过，否则，验证不通过；

或，

所述控制平台，进一步用于从用户终端获得用户输入的评价验证码，在信用数据库保存的授权证书信息中找到用户输入的评价验证码对应的服务方编号K12，产生一个随机数RB并发送给用户终端，接收来自用户终端的数据块Token1＝Enc(RA‖RB，K11)并用K12进行解密，得到RB’，比较RB’和RB，如一致，则对用户验证通过，如不一致，则验证不通过；

或，所述控制平台，进一步用于从用户终端获得用户输入的评价验证码，在信用数据库保存的授权证书信息中找到用户输入的评价验证码对应的服务方编号K12，产生一个随机数RB并发送给用户终端，接收来自用户终端的数据块Token1＝Enc(RA‖RB，K11)并用K12进行解密，得到RB’，比较RB’和RB，如一致，则对用户验证通过，如不一致，则验证不通过；产生一个随机数RC，用业务平台系统保存的服务方编号K12对RA’和RC进行加密得到数据块Token2＝Enc(RA’‖RC，K12)，将Token2发送给用户终端。

所述控制平台，进一步用于将服务方对应的授权证书发放给服务方，以便该服务方向用户提供授权证书；或者，进一步用于接收服务方发来的用户的联系方式，根据用户的联系方式直接向用户发放服务方对应的授权证书。

所述信用数据库，进一步用于记录用户的因特网协议IP地址和/或浏览器记录标记Cookie和/或用户联系方式，对该IP地址和/或Cookie和/或用户联系方式的验证不通过的次数进行统计和记录；

所述控制平台，进一步用于读取信用数据库中的IP地址和/或Cookie和/或用户联系方式的验证不通过的次数，判断是否达到指定次数，如果达到指定次数，生成附加识别码，要求用户输入附加识别码并对用户输入的附加识别码进行验证，如果用户输入的附加识别码错误，控制用户终端不允许该用户进行评价；

和/或，

所述信用数据库，进一步用于记录进行评价的用户的IP地址和/或用户联系方式以及该IP地址和/或用户联系方式累计的评价次数；

所述控制平台，进一步用于读取信用数据库中的IP地址和/或用户联系方式累计的评价次数，判断在设定时间内同一IP地址和/或用户联系方式的用户的评价次数是否达到最大评价次数，如果是，控制用户终端拒绝该IP地址和/或用户联系方式的用户继续评价。

根据以上发明内容可见，在本发明的信用数据管理方法和业务平台系统中，用户凭从服务方获得的授权证书进入业务平台系统，业务平台系统根据授权证书对用户进行验证，验证通过后，才允许用户对服务方进行评价，因此避免了针对服务方的不真实评价，提高了信用记录的准确性和可靠性。

附图说明

图1为本发明实施例的信用数据管理方法的流程图；

图2为本发明实施例的业务平台系统的结构示意图。

具体实施方式

为了使本发明的目的、技术方案和优点更加清楚，下面结合附图和具体实施例对本发明进行详细描述。

本发明的主要思想是，服务方为用户授予授权证书，用户凭授权证书进入业务平台系统，对服务方进行评价。

图1为本发明实施例的信用数据管理方法的流程图。如图1所示，本发明实施例的信用数据管理方法包括如下步骤。

步骤101：用户选择服务方提供服务。

步骤102：用户获取服务方对应的授权证书。

该授权证书中的信息至少包括评价验证码和业务平台系统信息，还可以包括如下信息中的一种或几种：服务方名称、服务方编号、服务方联系方式、服务时间、授权证书有效期等。其中，不同授权证书中的评价验证码互不相同。上述业务平台系统信息用于向用户告知进入业务平台系统的路径和方法，因此业务平台系统信息包括的内容只要能够指引用户准确地进入业务平台系统即可，具体可以包括如下信息中的一种或几种：业务平台系统的名称、网站地址、简介、使用说明等。

在步骤102中，用户能够通过多种方式获取服务方对应的授权证书，比如，

方式一、由服务方向用户提供授权证书；

在该方式一中，首先，业务平台系统将服务方对应的授权证书直接发放给服务方，再由服务方将其对应的授权证书发放给用户。

方式二、由业务平台系统直接向用户提供授权证书；

服务方向业务平台系统发送包括用户联系方式的授予授权证书通知，业务平台系统根据用户联系方式直接向用户发送授权证书，以便于使得用户获取了授权证书。

例如，服务方在完成服务后向业务平台中输入接收服务的用户的手机号码，业务平台系统向该手机号码发送手机短信，将授权证书的信息直接发送给了用户。

当用户通过方式二获取授权证书时，授权证书是直接从业务平台系统处发放到用户手中，而没有经过服务方，因此，服务方就无法直接得到用于对其进行评价的授权证书的信息，从而能够避免服务方恶意获取授权证书，利用授权证书自己给自己好评的情况发生。

服务方所提供的授权证书中服务方名称、服务方编号、服务方联系方式与该服务方实际的信息一致。

步骤103：用户根据业务平台系统信息，向业务平台系统输入授权证书信息。

步骤104：业务平台系统根据输入的授权证书中的信息对用户进行验证，如果验证通过，业务平台系统允许该用户进行评价，继续执行步骤105；如果验证不通过，业务平台系统不允许该用户进行评价，返回执行步骤103，用户重新向业务平台系统输入授权证书信息。

在步骤104中，业务平台系统可以采用多种方法对用户输入的授权证书信息进行验证，以下仅举出三个实施例来说明验证的具体过程。在实际应用中，还可以采用这三个实施例以外的其它验证方法，并且根据验证方法调整授权证书中包括的信息的具体内容。

第一种验证方法的具体实施例仅通过验证评价验证码的正确性完成对用户的验证。在本实施例中，授权证书信息包括：评价验证码。预先在业务平台系统中保存所有授权证书的评价验证码，用户向业务平台系统中输入授权证书信息后，业务平台系统在自身预先保存的评价验证码中进行检索，判断是否存在与用户输入的评价验证码相同的评价验证码，如果有，业务平台系统对用户验证通过，否则，验证不通过。

第二种验证方法的具体实施例通过验证评价验证码和服务方编号的对应关系完成对用户的验证。在本实施例中，授权证书信息包括：评价验证码和服务方编号。预先在业务平台系统中保存所有授权证书的评价验证码和该评价验证码对应的服务方编号，用户向业务平台系统中输入授权证书信息后，业务平台系统根据自身预先保存的评价验证码和该评价验证码对应的服务方编号，判断用户输入的评价验证码与服务方编号的对应关系是否正确，如果正确，业务平台系统对用户验证通过，否则，验证不通过。

第三种验证方法的具体实施例通过对授权证书信息进行运算完成对用户的验证。存在多种运算方法完成验证，本实施例仅举出其中一种运算方法作为例子，在本实施例中，授权证书中的信息包括：评价验证码和服务方编号，根据运算方法的不同，可以调整授权证书信息包括的具体内容。预先在业务平台系统中保存每一个授权证书中的评价验证码和服务方编号。对于一个授权证书，将用户输入的授权证书中的服务方编号记为K11，将预先保存在业务平台系统中的该授权证书的服务方编号记为K12。用户通过用户终端进入该业务平台系统，向用户终端输入授权证书中的评价验证码和服务方编号K11，业务平台系统在自身保存的授权证书信息中找到该评价验证码对应的服务方编号K12，业务平台系统产生一个随机数RB，发送给用户终端；用户终端产生另一个随机数RA，用授权证书中的服务方编号K11对RA和RB进行加密得到数据块Token1＝Enc(RA‖RB，K11)，用户终端将Token1发送给业务平台系统；业务平台系统用自身保存的服务方编号K12解密Token1得到RA’和RB’，比较RB’和RB，如一致，则业务平台系统对用户终端验证通过；如不一致，则业务平台系统对用户终端验证不通过。至此，完成了业务平台系统对用户终端的单向验证过程。对于安全性要求不高的情况，采用单向验证即可，因此如果业务平台系统对用户终端验证通过，则可判定业务平台系统对用户验证通过；如果业务平台系统对用户终端验证不通过，则可判定业务平台系统对用户验证不通过。

对于安全性要求较高的情况，为了防止仿冒业务平台系统的情况，可以采取用户终端与业务平台系统双向验证。如果采用双向验证，在完成上述业务平台系统对用户终端的单向验证的基础上，还需要完成用户终端对业务平台系统的验证。具体方法是：在业务平台系统对用户终端验证通过之后，继续由业务平台系统产生一个随机数RC，用业务平台系统保存的服务方编号K12对RA’和RC进行加密得到数据块Token2＝Enc(RA’‖RC，K12)，将Token2发送给用户终端；用户终端用授权证书中的服务方编号K11解密Token2后，比较RA’和RA是否一致，如一致，则用户终端对控制平台的验证通过，用户终端与控制平台之间的双向验证通过，因而业务平台系统对此用户验证通过，如不一致，则用户终端对控制平台的验证不通过，用户终端与控制平台之间的双向验证不通过，因而业务平台系统对此用户验证不通过。

在上述三个验证方法的实施例中，以授权证书信息中的评价验证码和服务方编号为例来说明验证的具体过程，在实际应用中，还可以采用授权证书信息中的其它内容替代评价验证码和/或服务方编号进行验证，在此不再赘述。并且，还可以采用这三个实施例以外的其它验证方法，根据采用的验证方法的实际需要调整授权证书中包括的信息的具体内容。

进一步的，在步骤102的方式二中，业务平台系统还可以保存该授权证书的信息与对应的用户联系方式，相应地，在步骤103中，为了进一步增加安全性，用户可以进一步向业务平台系统输入自身获得授权证书的联系方式。例如，用户将自己收到包含授权证书信息的短信的手机号码输入业务平台系统。

相应地，在步骤104中，业务平台系统对用户进行验证的具体方法还可以进一步包括：业务平台系统根据自身保存的授权证书的信息与对应的用户联系方式，判断用户输入的授权证书的信息与该用户的联系方式的对应关系是否正确，例如判断用户输入的授权证书信息与该用户的手机号码的对应关系是否正确，如果正确，业务平台系统对用户验证通过，否则，验证不通过。

进一步地，为了防止利用运算软件生成字符串来猜测授权证书信息，以进行不真实评价的情况，如果某个用户输入的授权证书信息验证不通过，在返回执行步骤103之前，业务平台系统记录该用户的因特网协议(IP)地址和/或浏览器记录标记(Cookie)和/或用户联系方式，并对该IP地址和/或Cookie和/或用户联系方式的验证不通过的次数进行统计和记录，如果验证不通过的次数达到指定次数，则业务平台系统生成一个附加识别码，要求用户输入附加识别码，并对用户输入的附加识别码进行验证，如果用户输入的附加识别码错误，不允许该用户进行评价，如果用户输入的附加识别码正确，返回执行步骤103。在统计该IP地址和/或Cookie和/或用户联系方式的验证不通过的次数时，可以统计该IP地址和/或Cookie和/或用户联系方式的连续的验证不通过的次数，也可以统计在一个指定时间内累积的验证不通过的次数。并且，上述附加识别码可以随机生成，也可以根据预设的附加识别码算法生成。例如，当某一Cookie的用户连续5次验证不通过时，业务平台系统随机生成附加识别码，提示用户输入附加识别码。

步骤105：用户对服务方进行评价，业务平台系统保存用户给予的评价。

在步骤105中，用户对服务方的评价可以采用多种方式。一种较佳的实施方式是，采用如下方法进行评价：

以用户对该服务方的推荐度进行评价，即，考察如果有其它用户需要此项服务时，接受过此项服务的用户向有需求的用户推荐为自己提供过服务的服务方的推荐程度，可以按照推荐程度将评价划分为若干个不同的级别，用户根据自己对该服务方的推荐度选择对应的评价级别。例如，一共用五颗星来表示评价级别，其中1星至5星分别对应强烈不推荐、不推荐、不置可否、推荐和强烈推荐五个级别，如果用户对于提供服务的服务方感到非常满意，即可在评价中给予5星，表示强烈推荐。采用这种评价方式，与现有的简单采用好评、中评或差评的评价方式相比，更能真实准确的表达出用户对服务方的满意程度。

进一步地，在步骤105中，预先对设定时间内同一IP地址和/或用户联系方式的最大评价次数进行规定，每次用户对服务方进行评价之后，对该用户的IP地址和/或用户联系方式以及该IP地址和/或用户联系方式累计的评价次数进行记录，如果在设定时间内同一IP地址和/或用户联系方式的评价次数达到最大评价次数，则拒绝该IP地址的用户继续评价。

通过步骤102至步骤105，用户需凭服务方授予的授权证书对服务方进行评价，因而避免了现有的信用数据管理方法中不真实评价的现象。

步骤106：在每一次用户做出评价之后，对累计保存的评价进行数据处理，生成并存储服务方的信用记录。

在此步骤中，对累计保存的评价进行数据处理可以采用多种方式，可以对用户的评价级别进行直接累积作为信用记录，也可以将用户每次给予的评价级别转化成信用积分作为信用记录，仍以上述以星级表示评价级别为例，一种较佳的实施方式是：对于用户的某一次评价，如果评价大于3星，则为被评价的服务方增加1分信用积分；如果评价为3星，则不改变被评价的服务方的信用积分；如果评价为2星，则为被评价的服务方减少10分信用积分；如果评价为1星，则为被评价的服务方减少50分信用积分；并且，为了防止服务方采用不正当手段为自己增加信用积分，限制服务方在指定时间内增加的信用积分的数量，例如，每个服务方每日最多增加2分信用积分。并且，还可以采用其它信用标识对信用积分进行直观表示，例如，每16分信用积分采用1颗心形图案表示，每64分信用积分采用1个钻石图案表示，每256分信用积分采用1个皇冠图案表示，每1024个信用积分采用1个金冠图案表示。

对于每一次服务方为用户提供服务的过程，都经过上述步骤101至步骤106，用户在业务平台系统中对服务方给出评价，业务平台系统在每一次用户做出评价之后根据累计的评价更新服务方信用记录。在用户选择服务方之前，用户首先查看业务平台系统中的信用记录，在步骤101中，用户根据业务平台系统保存的服务方的信用记录选择服务方。

以上介绍了本发明实施例的信用数据管理方法，接下来对该方法中的业务平台系统进行说明。用户通过用户终端输入授权证书信息和评价，用户终端与业务平台系统进行交互。

图2为本发明实施例的业务平台系统的结构示意图。参见图2，本发明实施例的业务平台系统至少包括：控制平台201和信用数据库202。

控制平台201，用于与用户终端交互，根据用户输入的授权证书信息对用户进行验证，如果验证通过，控制用户终端允许用户对服务方进行评价，如果验证不通过，控制用户终端不允许用户进行评价。

信用数据库202，用于保存对用户进行验证所需的授权证书中的信息，所述授权证书中的信息包括：评价验证码、业务平台系统信息、服务方名称、服务方编号、服务方联系方式、服务时间和授权证书有效期中的任意一项或任意多项的组合，不同授权证书的评价验证码互不相同；还用于接收并保存来自用户终端的评价，对累计保存的评价进行数据处理，生成、存储并向用户终端显示服务方的信用记录。

在一种实施方式中，

所述控制平台，进一步用于在信用数据库预先保存的评价验证码中进行检索，判断是否存在与用户输入的评价验证码相同的评价验证码，如果有，对用户验证通过，否则，验证不通过；

或，

所述控制平台，进一步用于根据信用数据库预先保存的评价验证码和该评价验证码对应的服务方编号，判断用户输入的评价验证码与服务方编号的对应关系是否正确，如果正确，对用户验证通过，否则，验证不通过。

在另一实施方式中，以上述第三种验证方法的具体实施例为例，进一步地，信用数据库202，用于预先保存对用户进行验证所需的授权证书信息，如：评价验证码和服务方编号K12。对于单向验证的情况，控制平台201进一步地，用于从用户终端获得用户输入的评价验证码，在信用数据库202保存的授权证书信息中找到用户输入的评价验证码对应的服务方编号K12，产生一个随机数RB并发送给用户终端，接收来自用户终端的数据块Token1＝Enc(RA‖RB，K11)并用K12进行解密，得到RB’，比较RB’和RB，如一致，则对用户验证通过；如不一致，则验证不通过。对于双向验证的情况，控制平台201在上述单向验证的功能的基础上，进一步地用于产生一个随机数RC，用业务平台系统保存的服务方编号K12对RA’和RC进行加密得到数据块Token2＝Enc(RA’‖RC，K12)，将Token2发送给用户终端。

在又一种实施方式中，

所述控制平台，进一步用于将服务方对应的授权证书发放给服务方，以便该服务方向用户提供授权证书；

或者，

所述控制平台，进一步用于接收服务方发来的用户的联系方式，根据用户的联系方式直接向用户发放服务方对应的授权证书，则此种情况下，控制平台还可以进一步用于接收用户输入的联系方式，根据信用数据库中保存的授权证书的信息与对应的用户联系方式，判断用户输入的授权证书的信息与该用户的联系方式的对应关系是否正确，如果正确，业务平台系统对用户验证通过，否则，验证不通过。相应地，信用数据库进一步用于保存控制平台发送给用户的授权证书的信息与对应的用户联系方式。

进一步地，信用数据库还用于记录用户的因特网协议IP地址和/或浏览器记录标记Cookie和/或用户联系方式，对该IP地址和/或Cookie和/或用户联系方式的验证不通过的次数进行统计和记录。并且，控制平台还用于读取信用数据库中的IP地址和/或Cookie和/或用户联系方式的验证不通过的次数，判断是否达到指定次数，如果达到指定次数，生成附加识别码，要求用户输入附加识别码并对用户输入的附加识别码进行验证，如果用户输入的附加识别码错误，控制用户终端不允许该用户进行评价。

并且，信用数据库进一步用于记录进行评价的用户的IP地址和/或用户联系方式以及该IP地址和/或用户联系方式累计的评价次数。并且控制平台进一步用于读取信用数据库中的IP地址和/或用户联系方式累计的评价次数，判断在设定时间内同一IP地址和/或用户联系方式的用户的评价次数是否达到最大评价次数，如果是，控制用户终端拒绝该IP地址和/或用户联系方式的用户继续评价。

以上所述的信用数据管理方法和业务平台系统可以应用于多个领域，任何需要用户对服务方的信用给出评价的情况均可使用。

采用上述信用数据管理方法和业务平台系统的一种较佳实施方式是：上述用户是手机用户，上述服务方是移动基站，手机用户采用手机作为用户终端，授权证书采用手机短信或彩信，移动基站向手机用户下发包含授权证书信息的手机短信或彩信，手机用户凭该短信或彩信对移动基站做出评价，从而采用该信用数据管理方法和业务平台系统可以直观有效的了解各个移动基站的工作状态。

采用上述信用数据管理方法和业务平台系统的另一种较佳实施方式是：上述用户是房产客户，上述服务方是房产经纪人，上述业务平台系统是一种淘房网站，房产客户采用计算机作为用户终端进入淘房网站，授权证书可以采用含有授权证书信息的卡片，例如淘房卡，在完成服务后，房产经纪人将淘房卡交给房产客户，房产客户凭淘房卡登陆淘房网站，通过淘房网站对房产经纪人做出评价，因而，其它的房产客户在登陆淘房网站之后，在选择房产经纪人时，可以先了解房产经纪人的信用记录再做出选择，从而避免了房产客户受到欺诈，促进房产经纪人提高服务质量。

根据以上具体实施方式可见，采用本发明提出的信用数据管理方法和业务平台系统，用户从服务方获得授权证书，凭授权证书进入业务平台系统，业务平台系统根据授权证书对用户进行验证，验证通过后，用户对服务方进行评价，当其它用户需要选择服务方为其提供服务时，可以首先进入业务平台系统查看服务方的信用记录，再根据信用记录选择信用良好的服务方为其提供服务。因为用户对服务方做出评价之前，业务平台系统首先要根据授权证书对用户进行验证，因此避免了针对服务方的不真实评价，提高了信用记录的准确性和可靠性。

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

Claims (11)

1.一种信用数据管理方法，其特征在于，包括：

用户选择服务方提供服务；

用户获取服务方对应的授权证书，所述授权证书中的信息包括：评价验证码、业务平台系统信息、服务方名称、服务方编号、服务方联系方式、服务时间和授权证书有效期中的任意一项或任意多项的组合，其中，不同授权证书的评价验证码互不相同；

用户根据业务平台系统信息向业务平台系统输入授权证书中的信息；

业务平台系统根据输入的授权证书中的信息对用户进行验证，如果验证通过，业务平台系统允许该用户进行评价，并保存用户给予的评价；如果验证不通过，业务平台系统不允许该用户进行评价，返回执行用户向业务平台系统输入授权证书信息的步骤；

对累计保存的评价进行数据处理，生成并存储服务方的信用记录；

2.根据权利要求1所述的方法，其特征在于，所述业务平台系统根据输入的授权证书中的信息对用户进行验证包括：

预先在业务平台系统中保存所有授权证书的评价验证码，业务平台系统在自身预先保存的评价验证码中进行检索，判断是否存在与用户输入的评价验证码相同的评价验证码，如果有，业务平台系统对用户验证通过，否则，验证不通过；

或，

预先在业务平台系统中保存所有授权证书的评价验证码和该评价验证码对应的服务方编号，业务平台系统根据自身预先保存的评价验证码和该评价验证码对应的服务方编号，判断用户输入的评价验证码与服务方编号的对应关系是否正确，如果正确，业务平台系统对用户验证通过，否则，验证不通过；

或，

预先在业务平台系统中保存每一个授权证书中的评价验证码和服务方编号K2，业务平台系统在自身保存的授权证书信息中找到用户输入的评价验证码对应的服务方编号K2，业务平台系统的控制平台产生一个随机数A，发送给用户终端，用户终端产生另一个随机数B，用用户输入的服务方编号K1对B和A进行加密得到数据块Token1＝Enc(B‖A，K1)，用户终端将Token1发送给控制平台，控制平台用自身保存的服务方编号K2解密Token1得到B’和A’，比较A’和A，如一致，业务平台系统对用户验证通过，否则，验证不通过；

或，

预先在业务平台系统中保存每一个授权证书中的评价验证码和服务方编号K12，业务平台系统在自身保存的授权证书信息中找到用户输入的评价验证码对应的服务方编号K12，业务平台系统的控制平台产生一个随机数RB，发送给用户终端，用户终端产生另一个随机数RA，用用户输入的服务方编号K11对RA和RB进行加密得到数据块Token1＝Enc(RA‖RB，K11)，用户终端将Token1发送给控制平台，控制平台用自身保存的服务方编号K12解密Token1得到RA’和RB’，比较RB和RB，如不一致，业务平台系统对用户验证不通过，如一致，控制平台产生一个随机数RC，用控制平台保存的服务方编号K12对RA’和RC进行加密得到数据块Token2＝Enc(RA’‖RC，K12)，将Token2发送给用户终端，用户终端用授权证书中的服务方编号K11解密Token2后，比较RA’和RA是否一致，如一致，业务平台系统对此用户验证通过，否则，验证不通过。

3.根据权利要求1所述的方法，其特征在于，所述用户获取服务方对应的授权证书的步骤包括：

服务方从业务平台系统处获取其对应的授权证书，并由该服务方将该授权证书授予所述用户；

或者，

服务方向业务平台系统发送包括用户联系方式的授予授权证书通知，业务平台系统根据用户联系方式直接向用户发放授权证书。

4.根据权利要求3所述的方法，其特征在于，所述业务平台系统接收到所述授予授权证书通知后，进一步保存该授权证书的信息与对应的用户联系方式；

所述用户进一步向业务平台系统输入自身获得授权证书的联系方式；

所述业务平台系统根据输入的授权证书中的信息对用户进行验证，进一步包括：业务平台系统根据自身保存的授权证书的信息与对应的用户联系方式，判断用户输入的授权证书的信息与该用户的联系方式的对应关系是否正确，如果正确，业务平台系统对用户验证通过，否则，验证不通过。

5.根据权利要求1、2或3所述的信用数据管理方法，其特征在于，所述返回执行用户向业务平台系统输入授权证书信息的步骤之前，进一步包括：

业务平台系统记录该用户的因特网协议IP地址和/或浏览器记录标记Cookie和/或用户联系方式，对该IP地址和/或Cookie和/或用户联系方式的验证不通过的次数进行统计和记录，如果验证不通过的次数达到指定次数，则业务平台系统生成一个附加识别码，要求用户输入附加识别码，并对用户输入的附加识别码进行验证，如果用户输入的附加识别码错误，不允许该用户进行评价，如果用户输入的附加识别码正确，返回执行用户向业务平台系统输入授权证书信息的步骤；

和/或，

所述保存用户给予的评价之后，进一步包括：

预先规定设定时间内同一IP地址和/或用户联系方式的最大评价次数，记录进行评价的用户的IP地址和/或用户联系方式以及该IP地址和/或用户联系方式累计的评价次数，如果在设定时间内同一IP地址和/或用户联系方式的用户的评价次数达到最大评价次数，则拒绝该IP地址和/或用户联系方式的用户继续评价。

6.根据权利要求1、2或3所述的信用数据管理方法，其特征在于，

所述用户对服务方进行评价包括：

按照推荐度将评价划分为若干个不同的评价级别，用户根据自己对该服务方的推荐度选择对应的评价级别；

所述对累计保存的评价进行数据处理包括：

对用户做出的评价级别进行直接累积作为信用记录；

或，将用户做出的评价级别转化成信用积分作为信用记录。

7.根据权利要求6所述的信用数据管理方法，其特征在于，

所述评价级别包括：1星、2星、3星、4星和5星，其中1星表示强烈不推荐，2星表示不推荐，3星表示不置可否，4星表示推荐，5星表示强烈推荐；则，所述对累计保存的评价进行数据处理包括：如果评价大于3星，为被评价的服务方增加1分信用积分；如果评价为3星，不改变被评价的服务方的信用积分；如果评价为2星，为被评价的服务方减少10分信用积分；如果评价为1星，为被评价的服务方减少50分信用积分；每16分信用积分采用1颗心形图案表示，每64分信用积分采用1个钻石图案表示，每256分信用积分采用1个皇冠图案表示，每1024个信用积分采用1个金冠图案表示；

和/或，

所述对累计保存的评价进行数据处理包括：

限制服务方在指定时间内增加的信用积分的数量。

8.一种业务平台系统，其特征在于，包括：

控制平台，用于与用户终端交互，根据信用数据库中保存的授权证书中的信息和用户输入的授权证书中的信息对用户进行验证，如果验证通过，控制用户终端允许用户对服务方进行评价，如果验证不通过，控制用户终端不允许用户进行评价。

信用数据库，用于保存对用户进行验证所需的授权证书中的信息，所述授权证书中的信息包括：评价验证码、业务平台系统信息、服务方名称、服务方编号、服务方联系方式、服务时间和授权证书有效期中的任意一项或任意多项的组合，不同授权证书的评价验证码互不相同；还用于接收并保存来自用户终端的评价，对累计保存的评价进行数据处理，生成、存储并向用户终端显示服务方的信用记录。

9.根据权利要求8所述的业务平台系统，其特征在于，

所述控制平台，进一步用于在信用数据库预先保存的评价验证码中进行检索，判断是否存在与用户输入的评价验证码相同的评价验证码，如果有，对用户验证通过，否则，验证不通过；

或，

所述控制平台，进一步用于根据信用数据库预先保存的评价验证码和该评价验证码对应的服务方编号，判断用户输入的评价验证码与服务方编号的对应关系是否正确，如果正确，对用户验证通过，否则，验证不通过；

或，

所述控制平台，进一步用于从用户终端获得用户输入的评价验证码，在信用数据库保存的授权证书信息中找到用户输入的评价验证码对应的服务方编号K12，产生一个随机数RB并发送给用户终端，接收来自用户终端的数据块Token1＝Enc(RA‖RB，K11)并用K12进行解密，得到RB’，比较RB’和RB，如一致，则对用户验证通过，如不一致，则验证不通过；

或，所述控制平台，进一步用于从用户终端获得用户输入的评价验证码，在信用数据库保存的授权证书信息中找到用户输入的评价验证码对应的服务方编号K12，产生一个随机数RB并发送给用户终端，接收来自用户终端的数据块Token1＝Enc(RA‖RB，K11)并用K12进行解密，得到RB’，比较RB’和RB，如一致，则对用户验证通过，如不一致，则验证不通过；产生一个随机数RC，用业务平台系统保存的服务方编号K12对RA’和RC进行加密得到数据块Token2＝Enc(RA’‖RC，K12)，将Token2发送给用户终端。

10.根据权利要求9所述的业务平台系统，其特征在于，

所述控制平台，进一步用于将服务方对应的授权证书发放给服务方，以便该服务方向用户提供授权证书；或者，进一步用于接收服务方发来的用户的联系方式，根据用户的联系方式直接向用户发放服务方对应的授权证书。

11.根据权利要求8、9或10所述的业务平台系统，其特征在于，

所述信用数据库，进一步用于记录用户的因特网协议IP地址和/或浏览器记录标记Cookie和/或用户联系方式，对该IP地址和/或Cookie和/或用户联系方式的验证不通过的次数进行统计和记录；

所述控制平台，进一步用于读取信用数据库中的IP地址和/或Cookie和/或用户联系方式的验证不通过的次数，判断是否达到指定次数，如果达到指定次数，生成附加识别码，要求用户输入附加识别码并对用户输入的附加识别码进行验证，如果用户输入的附加识别码错误，控制用户终端不允许该用户进行评价；

和/或，

所述信用数据库，进一步用于记录进行评价的用户的IP地址和/或用户联系方式以及该IP地址和/或用户联系方式累计的评价次数；

所述控制平台，进一步用于读取信用数据库中的IP地址和/或用户联系方式累计的评价次数，判断在设定时间内同一IP地址和/或用户联系方式的用户的评价次数是否达到最大评价次数，如果是，控制用户终端拒绝该IP地址和/或用户联系方式的用户继续评价。

Images