CN110743170A - 道具管理方法、装置、设备及存储介质 - Google Patents

Abstract

本申请提供了一种道具管理方法、装置、设备及存储介质；所述方法包括：基于接收到的特权场景注册请求，获取请求方的属性信息；当确定所述属性信息满足特权场景注册条件时，获取所述请求方对应的用户数据；基于所述用户数据确定所述用户的偏好信息，并基于所述偏好信息，确定所述请求方的候选道具信息；向所述请求方发送注册成功的响应消息，所述响应消息中携带有所述候选道具信息。通过本申请，能够根据特权场景中用户的偏好信息提供道具，使得道具投放更有针对性。

Description

道具管理方法、装置、设备及存储介质

技术领域

本申请涉及互联网技术领域，尤其涉及一种道具管理方法、装置、设备及存储介质。

背景技术

随着互联网技术以及智能终端的发展，人们的娱乐方式已经有了翻天覆地的变化。人们可以随时随地地利用智能终端查看新闻、观看视频、听音乐、玩网络游戏等。特别地，在用户玩网络游戏的过程中，可以通过使用一些道具来快速完成游戏任务，或者装饰自己的游戏角色。目前，游戏中使用的道具一般是用户购买、达到一定级别或完成一定任务赢取的，获取方式相对单一，无法提供差异化体验。

发明内容

本申请实施例提供一种道具管理方法、装置及存储介质，能够根据特权场景中用户的偏好信息提供道具，使得道具投放更有针对性。

本申请实施例的技术方案是这样实现的：

本申请实施例提供一种道具管理方法，包括：

基于接收到的特权场景注册请求，获取请求方的属性信息；

当确定所述属性信息满足特权场景注册条件时，获取所述请求方对应的用户数据；

基于所述用户数据确定所述用户的偏好信息，并基于所述偏好信息，确定所述请求方的候选道具信息；

向所述请求方发送注册成功的响应消息，所述响应消息中携带有所述候选道具信息。

本申请实施例提供一种道具管理装置，包括：

第一获取模块，用于基于接收到的特权场景注册请求，获取请求方的属性信息；

第二获取模块，用于当确定所述属性信息满足特权场景注册条件时，获取所述请求方对应的用户数据；

第一确定模块，用于基于所述用户数据确定所述用户的偏好信息，并基于所述偏好信息，确定所述请求方的候选道具信息；

第一发送模块，用于向所述请求方发送注册成功的响应消息，所述响应消息中携带有所述候选道具信息。

本申请实施例提供一种道具管理设备，包括：

存储器，用于存储可执行指令；

处理器，用于执行所述存储器中存储的可执行指令时，实现本申请实施例提供的方法。

本申请实施例提供一种存储介质，存储有可执行指令，用于引起处理器执行时，实现本申请实施例提供的方法。

本申请实施例具有以下有益效果：

在本申请实施例提供的道具管理方法中，在接收到申请成为特权场景的注册请求时，获取请求方的诸如地理位置、经营者姓名、营业执照信息等属性信息，并在确定所述属性信息满足特权场景注册条件时，获取所述请求方对应的用户数据；进而通过用户数据为用户进行画像，以确定用户的偏好信息，并基于所述偏好信息，确定所述请求方的候选道具信息，最后向所述请求方发送携带有候选道具信息的响应消息，如此，向请求方发送的道具信息是基于到达请求方所在地理位置的用户的偏好信息确定的，从而能够更加针对性地提供差异化服务，并给用户带来定制化服务体验。

附图说明

图1为本申请实施例道具管理方法的网络架构示意图；

图2是本申请实施例提供的道具管理服务器200的组成结构示意图；

图3为本申请实施例提供的道具管理方法的一种实现流程示意图；

图4为本申请实施例提供的道具管理方法的再一种实现流程示意图；

图5为本申请实施例提供的道具管理方法的另一种实现流程示意图；

图6为本申请实施例特权道具管理系统的组成结构示意图；

图7为本申请实施例物理场景特权道具的接入阶段实现流程示意图；

图8为本申请实施例用户特权道具体验阶段的实现流程示意图。

具体实施方式

为了使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请作进一步地详细描述，所描述的实施例不应视为对本申请的限制，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。

在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解，“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。

在以下的描述中，所涉及的术语“第一\第二\第三”仅仅是是区别类似的对象，不代表针对对象的特定排序，可以理解地，“第一\第二\第三”在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本申请实施例能够以除了在这里图示或描述的以外的顺序实施。

除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。

对本申请实施例进行进一步详细说明之前，对本申请实施例中涉及的名词和术语进行说明，本申请实施例中涉及的名词和术语适用于如下的解释。

1)道具：可以被用户获取、搜集为的物品。道具有各式各样的功能，可以是对角色有益的功能，如补充生命值；可以是对角色有害的功能，如行动被限制；道具可以是通过完成任务获得，还可以是需要用户购买以获得额外的功能与形象装饰；

2)特权道具：指用户在道具商城购买、或使用一定资源兑换获得的对游戏功能正向加成的物品。本文中特权道具特指位于特权场景而拥有的专属场景道具。道具的出现不是因为购买，而是与用户所在物理(或者虚拟网络空间)场景有关，离开特权场景后道具自动消失。

3)特权场景：人为划分的线下物理场所(或者虚拟网络空间)，用户能够免费体验相对于其它地方更多的权益，包括特权道具等额外增值服务。。

为了更好地理解本申请实施例，首先对相关技术中的道具管理方法及存在的缺点进行说明。

目前，将游戏内道具与物理场景进行关联以进行道具管理的方式主要有以下几种：

第一种方式、按照不同服务区域提供特定道具：如对于某一游戏应用，国内版本和国外版本提供的商城道具不一样，商城道具是本地化运营需求的一种体现。

第二种方式、基于特定场景的游戏权益分发：在特定运营场所，游戏自动解锁特定权益套餐，所有位于该特定场景的用户均被动接受，即使这些权益对用户根本没有吸引力。

上述两种道具管理方式所存在的缺点主要包括：

第一种方式：按服务区域定制商城道具尽管能够满足不同地域个性化需求，但是维度划分简单，无法支撑精细化运营策略和有效的差异化服务；

第二种方式：基于特定场景的游戏权益分发聚焦于特定用户场景，并未实现场景之间的差异化，此外，所有位于特权场景内的用户均被动接受解锁的游戏特权套餐，用户没有选择的权利。

基于此，本申请实施例提供一种道具管理方法，针对特定场景的用户兴趣爱好设计特权道具，吸引更多有相同诉求的用户聚集到特权场景体验业务，不仅能够为用户提供定制化服务体验，并且还能够实现线上线下互动运营。

下面说明实现本申请实施例的装置的示例性应用，本申请实施例提供的装置可以实施为道具管理服务器。下面，将说明装置实施为道具管理服务器时涵盖服务器的示例性应用。

参见图1，图1为本申请实施例道具管理方法的网络架构示意图，如图1所示，在该网络架构中至少包括用户终端100、道具管理服务器200、网络300、业务服务器400和请求方终端500。为实现支撑一个示例性应用，用户终端100通过网络300连接业务服务器400、业务服务器400通过网络300连接道具管理服务器200。用户终端100和请求方终端500可以是移动电话(手机)、平板电脑、笔记本电脑等具有无线通信能力的移动终端，还可以实施为不便移动的具有计算功能的台式计算机、桌面电脑等。道具管理服务器200和业务服务器400可以是单个的服务器设备实体，还可以是服务器集群，当然也可以是云服务器。在本申请实施例中，道具管理服务器200可以是一个设备实体，还可以是至少两个设备实体，当道具管理服务器200是一个设备实体时，那么该设备实体完成本申请实施例中道具管理服务器需要执行的所有步骤；当道具管理服务器200是由至少两个设备实体时，那么这至少两个设备实体分别执行不同的步骤，例如在一些实施例中，道具管理服务器200可以执行特权服务端和场景管理端功能。网络300可以是广域网或者局域网，又或者是二者的组合，使用无线链路实现数据传输。

用户终端100中可以安装有与业务服务器400对应的业务客户端，例如可以是游戏应用客户端，用户终端100可以通过业务客户端与业务服务器400进行数据通信；当然用户终端100也可以通过网页形式访问业务服务器400。同样地，请求方终端500中可以安装有业务客户端，通过特权场景客户端申请成为特权场景，当前请求方终端500也可以通过网页形式向道具管理服务器200申请成为特权场景，道具管理服务器200在接收到注册请求后，对请求方的资质进行审核，审核通过后再根据请求方现有用户的偏好信息确定候选道具信息返回给请求方终端500，请求方终端500选择目标道具信息并完成支付后，道具管理服务器200建立请求方和道具信息的对应关系。

当处于请求方地理位置的用户终端100登录目标业务后，业务服务器400向道具管理服务器200发送道具查询请求，道具管理服务器200根据终端的特征信息确定该终端所处的特权场景，并确定对应的道具信息，进而发送给业务服务器400，业务服务器400将道具信息发送给用户终端100，以在用户终端100的道具商城中进行展示。

本申请实施例提供的装置可以实施为硬件或者软硬件结合的方式，下面说明本申请实施例提供的装置的各种示例性实施。

根据图2示出的道具管理服务器200的示例性结构，可以预见道具管理服务器200的其他的示例性结构，因此这里所描述的结构不应视为限制，例如可以省略下文所描述的部分组件，或者，增设下文所未记载的组件以适应某些应用的特殊需求。

图2所示的道具管理服务器200包括：至少一个处理器210、存储器240、至少一个网络接口220和用户接口230。道具管理服务器200中的每个组件通过总线系统250耦合在一起。可理解，总线系统250用于实现这些组件之间的连接通信。总线系统250除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图2中将各种总线都标为总线系统250。

用户接口230可以包括显示器、键盘、鼠标、触感板和触摸屏等。

存储器240可以是易失性存储器或非易失性存储器，也可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(ROM，Read Only Memory)。易失性存储器可以是随机存取存储器(RAM，Random Acces s Memory)。本申请实施例描述的存储器240旨在包括任意适合类型的存储器。

本申请实施例中的存储器240能够存储数据以支持道具管理服务器200的操作。这些数据的示例包括：用于在道具管理服务器200上操作的任何计算机程序，如操作系统和应用程序。其中，操作系统包含各种系统程序，例如框架层、核心库层、驱动层等，用于实现各种基础业务以及处理基于硬件的任务。应用程序可以包含各种应用程序。

作为本申请实施例提供的方法采用软件实施的示例，本申请实施例所提供的方法可以直接体现为由处理器210执行的软件模块组合，软件模块可以位于存储介质中，存储介质位于存储器240，处理器210读取存储器240中软件模块包括的可执行指令，结合必要的硬件(例如，包括处理器210以及连接到总线250的其他组件)完成本申请实施例提供的方法。

作为示例，处理器210可以是一种集成电路芯片，具有信号的处理能力，例如通用处理器、数字信号处理器(DSP，Digital Signal Processor)，或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等，其中，通用处理器可以是微处理器或者任何常规的处理器等。

将结合本申请实施例提供的终端的示例性应用和实施，说明本申请实施例提供的道具管理方法。

参见图3，图3为本申请实施例提供的道具管理方法的一种实现流程示意图，应用于图1所示的道具管理服务器，将结合图3示出的步骤进行说明。

步骤S101，基于接收到的特权场景注册请求，获取请求方的属性信息。

这里，当道具管理服务器接收到请求方终端发送的申请成为特权场景的特权场景注册请求时，获取特权场景注册请求中携带的请求方的属性信息。请求方可以是某个网吧的经营管理者，还可以是购物商场中某个店铺的经营者，还可以是整个购物商场的经营者。请求方的属性信息可以包括申请人信息(例如包括申请人的姓名、身份证号)、请求方的地理位置与规模、行业属性、营业执照信息、是否有中心节点等。举例来说，请求方的属性信息可以为：张三、身份证号123XXXXX、陕西省西安市雁塔区XX路XX号、1000平方米、行业属性为网吧、营业执照号为610XXXXX，有中心节点。

步骤S102，当确定所述属性信息满足特权场景注册条件时，获取所述请求对应的用户数据。

这里，特权场景注册条件可以是预先设置好的，在特权场景注册条件中可以限定地理位置不能过于偏远、规模不能太小，还可以对行业属性进行限定，例如行业属性不能够为医疗行业、教育行业等。例如特权场景注册条件可以为陕西省西安市三环以内、规模500平方米以上、行业属性不为医疗、教育行业，并且申请人信息与营业执照信息对应一致。

所述请求方对应的用户数据可以是处于请求方所在地理位置的用户的相关数据，当请求方为网吧时，那么处于所述请求方所在地理位置的用户可以是在该网吧中上网的用户；当请求方为购物商场时，那么处于请求方所在地理位置的用户是指，连接到该购物商场的无线网络的终端对应的用户。

用户数据可以包括用户的画像数据，还可以包括用户的历史行为数据。用户的画像数据可以是对用户大量的历史数据通过大数据分析得到的，画像数据可以包括用户的基本信息，例如可以包括用户的年龄、性别，还可以包括用户的偏好数据、生活习惯数据等；用户的历史行为数据可以包括用户在游戏过程中产生的游戏数据。

由于用户数据一般情况下是存储在业务服务器中的，因此获取用户数据在实现时，可以是道具管理服务器从业务服务器中获取的。

步骤S103，基于所述用户数据确定所述用户的偏好信息，并基于所述偏好信息，确定所述请求方的候选道具信息。

这里，通过对用户数据进行分析，从而确定出处于请求方所在地理位置的用户的偏好信息，其中，用户的偏好信息至少可以包括用户在游戏过程中习惯使用的角色、技能等。

在道具管理服务器中，存储有完整的场景特征信息库，以对用户所在物理场景进行判断，向业务服务端反馈场景适用的特权道具，因此在确定出用户的偏好信息后，可以进一步根据场景特征信息库确定偏好信息对应的候选道具信息。

候选道具信息可以包括可以选择的道具，道具的使用方式、道具的作用以及购买价格等等。

步骤S104，向所述请求方发送注册成功的响应消息，所述响应消息中携带有所述候选道具信息。

这里，在确定出候选道具信息后，道具管理服务器向请求方返回注册成功的响应消息，以通知请求方选择想要购买的道具。

在本申请实施例提供的道具管理方法中，在接收到申请成为特权场景的注册请求时，获取请求方的诸如地理位置、经营者姓名、营业执照信息等属性信息，并在确定所述属性信息满足特权场景注册条件时，获取到达所述请求方所在地理位置的用户数据；进而通过用户数据为用户进行画像，以确定用户的偏好信息，并基于所述偏好信息，确定所述请求方的候选道具信息，最后向所述请求方发送携带有候选道具信息的响应消息，如此，向请求方发送的道具信息是基于到达请求方所在地理位置的用户的偏好信息确定的，从而能够更加针对性地提供差异化服务，并给用户带来定制化服务体验。

在一些实施例中，如图4所示，在步骤S104之后，还可以执行以下步骤：

步骤S105，接收请求方发送的目标道具信息。

这里，请求方在接收到道具管理服务器发送的候选道具信息之后，可以根据候选道具信息中的各个道具的作用、价格等选择目标道具信息，并将选择好的目标道具信息发送至道具管理服务器。

步骤S106，基于所述属性信息和目标道具信息，对所述请求方进行资格审核，得到审核结果。

这里，由于候选道具信息是根据用户的偏好信息确定出来的，那么在请求方选择出目标道具信息之后，还需要道具管理服务器进一步根据请求方的属性信息，对请求方进行资格审核，以确定请求方是否满足目标道具信息的使用条件。其中，当根据请求方的属性信息，确定请求方满足目标道具信息的使用条件时，得到审核通过的审核结果，此时表明请求方具有所述目标道具信息的使用资格，进入步骤S107；当根据请求方的属性信息，确定请求方不满足目标道具信息的使用条件时，得到审核未通过的审核结果，此时表明请求方不具有所述目标道具信息的使用资格，那么道具管理服务器会向请求方返回目标道具信息选择无效的通知消息。

步骤S107，当所述审核结果表明所述请求方具有所述目标道具信息的使用资格时，向所述请求方发送支付信息。

这里，所述支付信息至少包括支付金额，其中支付金额是根据目标道具信息中的购买价格确定的，例如，目标道具信息中包括三件道具，购买价格分别为100元、50元和70元，那么支付金额即为100+50+70＝220元。请求方在接收到支付信息后，可以进行在线支付，以完成特权道具的申请过程。

步骤S108，当接收到支付成功的通知消息时，建立所述请求方和所述目标道具信息的对应关系。

这里，当道具管理服务器接收到支付成功的通知消息时，表明请求方已完成支付，此时可以将目标道具信息与请求方建立配置关系，目标道具信息一旦配置生效，当用户处于请求方所在地理位置时登录道具商城即可免费体验到该请求方对应的特权道具。

由于通过上述的步骤S101至步骤S108，已经完成了请求方的道具授权的过程，那么当用户通过位于请求方所在地理位置的终端机器登录目标业务时，可以通过下述的步骤S21至步骤S26实现特权道具的使用体验过程，以下结合各个步骤进行说明。

步骤S21，在用户通过终端登录目标业务时，业务服务器向道具管理服务器发送道具查询请求。

这里，当用户通过终端中的业务客户端登录目标业务时，场景客户端可以采集终端的特征信息，并且通过业务客户端将终端的特征信息发送至业务服务器。业务服务器在接收到终端的特征信息后，向道具管理服务器发送道具查询请求，以获取终端能够使用的道具，此时道具查询请求中携带有终端的特征信息。在本申请实施例中，终端的特征信息可以包括：终端标识(例如可以是终端的IP地址)，终端所在的网络拓扑结构，在一些实施例中还可以还包括终端的硬件配置信息、软件配置信息等。

在一些实施例中，当用户通过终端中的业务客户端登录目标业务时，业务服务器可以直接向道具管理服务器发送道具查询请求，此时道具查询请求中携带有终端标识。

步骤S22，道具管理服务器接收业务服务器发送的道具查询请求。

步骤S23，道具管理服务器基于所述道具查询请求，获取已登录所述业务服务器的终端的特征信息。

这里，当道具查询请求中携带有终端的特征信息时，步骤S23在实现时，通过解析道具查询请求即可获取到终端的特征信息；当道具查询请求中仅携带有终端标识，而未携带有终端的特征信息时，道具管理服务器可以通过终端标识获取场景网关发送的终端的特征信息。

步骤S24，道具管理服务器基于所述特征信息确定所述终端所处的特权场景，并获取所述特权场景对应的道具信息。

这里，在本申请实施例中，道具管理服务器根据完成的场景特征信息库对终端所在的物理场景进行判断，以确定终端所处的特权场景，当道具管理服务器确定出终端所处的特权场景后，进一步获取该特权场景对应的道具信息。

举例来说，根据终端的特征信息，确定终端所处的为网吧A这一特权场景，那么道具管理服务器可以根据预先建立好的请求方与道具信息的对应关系，确定出网吧A对应的道具信息。

步骤S25，道具管理服务器将所述道具信息发送给所述业务服务器。

步骤S26，业务服务器将道具信息发送给终端机器，以在终端机器上显示道具信息。

这里，业务服务器在接收到道具信息后，可以根据用户登录目标业务的用户标识，获取用户在该目标业务中的历史数据，进而可以根据历史数据，确定将道具信息发送给终端时的显示方式。进一步地，历史数据中可以包括该用户已有的道具、该用户的级别以及该用户使用较多的角色等，当根据历史数据确定将道具信息发送给终端时的显示方式时，可以是优先显示用户没有的道具，或者优先显示用户使用最多的角色对应的道具等等。

在一些实施例中，在步骤S25将所述道具信息发送给所述业务服务器之前，还可以通过以下步骤确定特权场景以及特权场景对应的道具信息是否有效：

步骤S211，获取所述特权场景的活跃度信息。

在本申请实施例中，活跃度信息为能够反映在特权场景下目标业务用户的活跃度的信息，例如可以包括日活跃用户数、用户在线时长等等。

步骤S212，基于所述活跃度信息，确定所述特权场景符合预设的有效条件时，获取所述道具信息的失效时间。

这里，基于特权场景的活跃度信息能够确定在特权场景下目标业务用户的活跃度是否满足道具授权的条件，从而确定特权场景是否符合有效条件；当基于活跃度信息确定特权场景符合预设的有效条件时，进一步获取道具信息的失效时间；在一些实施例中，当基于特权场景的活跃度信息确定特权场景不符合预设的有效条件时，向业务服务器返回道具资格不满足的响应消息。

步骤S213，根据当前时间和所述失效时间，确定所述道具信息是否过期。

这里，步骤S213在实现时，确定道具信息是否过期也即判断当前时间是否在失效时间之前，如果当前时间在失效时间之前，说明道具信息未过期，此时进入步骤S25，将所述道具信息发送给所述业务服务器；如果当前时间在失效时间之后，说明道具信息已过期，此时向业务服务器返回道具已过期的响应消息。

举例来说，若失效时间为2019年10月31日，当前时间为2019年10月23日，由于当前时间在失效时间之前，此时说明道具信息未过期，进入步骤S25；若失效时间为2019年10月31日，当前时间为2019年11月3日，由于当前时间在失效时间之后，此时说明道具信息已过期，此时向业务服务器返回道具已过期的响应消息。

在一些实施例中，可以在道具失效之前，通过下述步骤提醒道具的购买方，也即上述实施例中的请求方进行续费，以保证玩家能够正常使用道具：

步骤S31，根据所述失效时间和当前时间确定所述道具信息对应的剩余使用时长。

这里，步骤S31在实现时，通过失效时间和当前时间的差值确定道具信息对应的剩余使用时长。举例来说，失效时间为2019年10月31日，当前时间为2019年10月23日，那么剩余使用时长8天。

步骤S32，判断所述剩余使用时长是否小于时长阈值。

这里，当剩余使用时长小于时长阈值时，说明临近失效时间，此时进入步骤S33，当剩余使用时长不小于时长阈值时，说明离失效时间还有较长时间，此时不执行提醒操作。

假设时长阈值为3天，由于当前的剩余使用时长还有8天，剩余使用时长大于时长阈值，此时不执行提醒操作，而当在2019年10月29日时，剩余使用时长为2天，小于时长阈值3天，此时会进入步骤S33，以提醒请求方缴费。

在一些实施例中，步骤S31和步骤S32可以是定期执行的，例如可以是每24小时执行一次。

步骤S33，当所述剩余使用时长小于时长阈值时，向所述道具信息对应的请求方发送缴费提醒消息。

这里，所述缴费提醒消息中携带有所述剩余使用时长和缴费金额。

步骤S34，判断是否在失效时间之前接收到缴费成功消息。

这里，如果在失效时间之前接收到缴费成功消息，那么进入步骤S36，更新道具信息的失效时间；如果在失效时间之前没收到缴费成功消息，那么进入步骤S35撤销请求方的使用权限。

步骤S35，道具管理服务器删除所述道具信息和请求方之间的对应关系，以撤销所述请求方的道具使用权限。

这里，如果达到失效时间仍未接收到请求方的缴费成功消息，说明请求方没有续费，此时需要撤销请求方对道具的使用权限，在实际应用过程中，可以通过删除道具信息和请求方之间的对应关系实现。

步骤S36，道具管理服务器更新所述道具信息的失效时间。

这里，如果在达到失效时间之前接收到请求方的缴费成功消息，说明请求方已经续费，此时保持请求方对道具的使用权限，并根据缴费成功消息更新道具信息的失效时间。

在本申请实施例中，道具管理服务器在向请求方发送缴费提醒消息时，可以提供缴费选项，不同的缴费选项对应有不同的缴费金额和续期时长，例如，40元对应续期时长为3个月，100元对应续期时长为6个月，180元对应续期时长为12个月。道具信息对应的请求方可以选择缴费选项，例如可以选择100元，那么当道具管理服务器接收到缴费100元的缴费成功消息时，会将失效时间延长6个月，假设原始的失效时间为2019年10月31日，延长6个月之后，更新后的失效时间为2020年4月30日。

在一些实施例中，道具管理服务器还可以通过下述的步骤S41至步骤S43定期或者不定期获取特权场景中各个终端的道具激活频次信息和网络路由信息，以确定特权场景中终端是否符合预设的安全策略，及时剔除或者收回存在安全风险的终端的道具使用权限。

步骤41，获取所述特权场景中各个终端的道具激活频次信息和网络路由信息。

这里，终端道具激活频次信息也即终端请求使用道具的频次，例如可以是3天激活10次，在一些实施例中，终端道具激活频次信息还包括在同一个终端上单位时间内有多少个用户激活、同时在线用户次数等。终端的网络路由信息可以是网络路由跳数、时延、终端和场景管理端是否位于同一局域网内等信息。

步骤42，基于各个终端的道具激活频次信息和网络路由信息确定目标终端。

这里，所述目标终端为道具激活频次信息和网络路由信息不符合安全策略的终端，也即目标终端为存在安全隐患的终端。

步骤43，当检测到已登录所述业务服务器的终端为目标终端时，向所述业务服务器返回无可使用道具的响应消息。

这里，由于目标终端为存在安全隐患的终端，那么当检测到利用目标终端登录业务服务器时，此时道具管理服务器向业务服务器返回无可使用道具的响应消息，并提示可更换终端进行登录，以获取道具，从而避免场景外用户通过恶意终端非法占有特权道具权利，损害请求方和业务利益。

基于前述的实施例，本申请实施例再提供一种道具管理方法，应用于图1所示的网络架构，图5为本申请实施例道具管理方法的再一种实现流程示意图，如图5所示，所述方法包括：

步骤S501，请求方申请成为特权场景，并向道具管理服务器发送特权场景注册请求。

这里，步骤S501在实现时，实际上是请求方终端向道具管理服务器发送特权场景注册请求。请求方终端也即请求方所使用的终端，可以是移动手机、平板电脑等便携式终端，还可以是台式计算机、桌面电脑等不便移动的终端。

请求方发送的特权场景注册请求中可以携带有请求方的属性信息，在一些实施例中，还可以是请求方仅发送特权场景注册请求，然后道具管理服务器向请求方返回注册所需要的信息提示，以便请求方根据提示补充完整的信息。

步骤S502，道具管理服务器基于接收到注册请求，获取请求方的属性信息。

这里，请求方的属性信息可以包括申请人信息(例如包括申请人的姓名、身份证号)、请求方的地理位置与规模、行业属性、营业执照信息、是否有中心节点等。

步骤S503，道具管理服务器基于请求方的属性信息确定请求方是否满足特权场景注册条件。

这里，特权场景注册条件可以是预先设置好的，在特权场景注册条件中可以限定地理位置不能过于偏远、规模不能太小，还可以对行业属性进行限定，例如行业属性不能够为医疗行业、教育行业等。当基于属性信息确定请求方满足特权场景注册条件时，进入步骤S504；当确定请求方不满足特权场景注册条件时，进入步骤S507，并结束流程。

步骤S504，当确定所述属性信息满足特权场景注册条件时，道具管理服务器获取处于所述请求方的用户数据。

这里，在本申请实施例中请求方的用户数据可以是处于所述请求方所在地理位置的用户，进一步地是指所使用的终端与请求方的中心节点建立有通信连接的用户。当请求方为网吧B，请求方的中心节点为网管服务器时，处于所述请求方所在地理位置的用户是指在该网吧中利用与网管服务器建立有通信连接的终端上网的用户；当请求方的中心节点为无线路由器时，处于所述请求方所在地理位置的用户是指连接到该无线路由器的终端对应的用户。用户数据可以包括用户的画像数据，还可以包括用户的历史行为数据。

步骤S505，道具管理服务器基于所述用户数据确定所述用户的偏好信息，并基于所述偏好信息，确定所述请求方的候选道具信息。

这里，通过对用户数据进行分析，从而确定出处于请求方所在地理位置的用户的偏好信息，其中，用户的偏好信息至少可以包括用户在游戏过程中习惯使用的角色、技能等。在确定出用户的偏好信息之后，道具管理服务器可以根据自身存储的场景特征信息库确定偏好信息对应的候选道具信息。

步骤S506，道具管理服务器向所述请求方发送注册成功的响应消息。

这里，所述响应消息中携带有所述候选道具信息。

步骤S507，道具管理服务器向所述请求方发送注册失败的响应消息。

这里，在所述响应消息中还可以携带有注册失败的原因，例如可以是请求方的行业属性不满足注册条件等。

步骤S508，请求方接收到注册成功的响应消息后，基于候选道具信息确定目标道具信息。

这里，请求方终端在接收到注册成功的响应消息后，会在请求方终端上显示候选道具信息，并提示请求方选择目标道具信息。而此时请求方可以从候选道具信息中选择一部分作为目标道具信息，当然请求方可以将全部候选道具信息作为目标道具信息。

步骤S509，请求方将目标道具信息发送给道具管理服务器。

步骤S510，道具管理服务器接收到请求方发送的目标道具信息后，基于请求方的属性信息和目标道具信息，对所述请求方进行资格审核，得到审核结果。

这里，由于候选道具信息是根据用户的偏好信息确定出来的，那么在请求方选择出目标道具信息之后，还需要道具管理服务器进一步根据请求方的属性信息，对请求方进行资格审核，以确定请求方是否满足目标道具信息的使用条件。其中，当根据请求方的属性信息，确定请求方满足目标道具信息的使用条件时，得到审核通过的审核结果；当根据请求方的属性信息，确定请求方不满足目标道具信息的使用条件时，得到审核未通过的审核结果，此时表明请求方不具有所述目标道具信息的使用资格，那么道具管理服务器会向请求方返回目标道具信息选择无效的通知消息。

步骤S511，道具管理服务器确定审核结果是否为审核通过。

这里，当审核结果为审核通过时，表明请求方具有所述目标道具信息的使用资格，进入步骤S512；当审核结果为审核未通过时，表明请求方不具有所述目标道具信息的使用资格，此时道具管理服务器向业务服务器返回重新选择目标道具信息的提示信息。

步骤S512，当所述审核结果表明所述请求方具有所述目标道具信息的使用资格时，道具管理服务器向所述请求方发送支付信息。

这里，支付信息是基于所选择的的目标道具的使用时长和对应的购买价格所确定的。

在一些实施例中，还可以是在步骤S505中，不仅仅基于用户的偏好信息，还基于请求方的属性信息，确定请求方的候选道具信息，这样，在步骤S506中，道具管理服务器向请求方发送的注册成功消息中携带的全部是具有使用资格的候选道具信息，那么在步骤S509之后，就可以省略步骤S510和步骤S511而是直接执行步骤S512。

步骤S513，请求方基于接收到的支付信息进行在线支付。

步骤S514，当道具管理服务器接收到支付成功的通知消息时，建立所述请求方和所述目标道具信息的对应关系。

这里，在请求方完成在线支付过程之后，第三方支付服务器(在图1中未示出)会向道具管理服务器发送支付成功的通知消息，道具管理服务器接收到支付成功的通知消息时，建立请求方和目标道具信息的对应关系，以完成为请求方配置目标道具的过程。

步骤S515，用户通过终端登录目标业务。

这里，步骤S515在实现时，用户使用终端中的目标业务客户端登录目标业务，此时目标业务客户端与业务服务器进行信息交互，以完成登录。

步骤S516，业务服务器向道具管理服务器发送道具查询请求。

这里，道具查询请求中至少包括终端标识，在一些实施例中，道具查询请求中还可以携带有终端的特征信息。

步骤S517，道具管理服务器基于所述道具查询请求，获取已登录所述业务服务器的终端的特征信息。

这里，步骤S517在实现时，可以是从道具查询请求中解析得到终端的特征信息，还可以是根据终端标识，从场景网关获取终端的特征信息，在本申请实施例中不进行限定。

步骤S518，道具管理服务器基于所述特征信息确定所述终端所处的特权场景，并获取所述特权场景对应的道具信息。

这里，道具管理服务器根据终端的特征信息确定终端所处的特权场景，并根据特权场景进一步确定对应的道具信息。在一些实施例中，道具管理服务器基于特征信息确定终端不处于特权场景中时，那么道具管理服务器向业务服务器返回无免费道具可使用的响应消息。

步骤S519，道具管理服务器将所述道具信息发送给所述业务服务器。

这里，业务服务器在接收到道具管理服务器发送的道具信息后，可以将道具信息发送至终端，以向用户展示。

在一些实施例中，在道具管理服务器将道具信息发送给业务服务器之前，道具管理服务器还可以对特权场景的有效性、道具信息是否过期等进行审核，并在特权场景有效且道具信息未过期时，再将道具信息发送至业务服务器，对特权场景的有效性及道具信息的有效性的审核过程可参照步骤S211至步骤S213的实现过程。

步骤S520，业务服务器获取登录所述终端的用户的历史数据。

这里，为了更有针对性地向不同用户展示不同的道具信息，业务服务器在将道具信息发送给终端之前，基于用户的历史数据确定道具信息的展示方式。

步骤S521，业务服务器根据所述历史数据确定道具信息的展示方式。

这里，历史数据中可以包括该用户已有的道具、该用户的级别以及该用户使用较多的角色等，那么步骤S521在实现时，可以是优先显示用户没有的道具，或者优先显示用户使用最多的角色对应的道具等等。

步骤S522，业务服务器依据所述展示方式将所述道具信息发送给终端。

这里，终端在接收到道具信息后，依照该展示方式在自身的显示装置中显示道具信息，并且终端基于用户的选择操作，使用选中的道具。

在本申请实施例提供的道具管理方法中，在接收到申请成为特权场景的注册请求时，获取请求方的诸如地理位置、经营者姓名、营业执照信息等属性信息，并在确定所述属性信息满足特权场景注册条件时，获取到达所述请求方所在地理位置的用户数据；进而通过用户数据为用户进行画像，以确定用户的偏好信息，并基于所述偏好信息，确定所述请求方的候选道具信息，最后向所述请求方发送携带有候选道具信息的响应消息，如此，向请求方发送的道具信息是基于到达请求方所在地理位置的用户的偏好信息确定的，从而能够更加针对性地提供差异化服务，并给用户带来定制化服务体验。

另外在本申请实施例中，用户登录目标业务时，道具管理服务器根据终端的特征信息，确定出终端所处的特权场景，并进一步确定该特权场景对应的道具信息，而业务服务器在将道具信息发送给终端时，还对根据用户的历史数据对道具信息的展示方式进行最优匹配，保证有针对性地为用户展示道具信息，便于用户选择合适的道具，提高用户的使用体验。

下面，将说明本申请实施例在一个实际的应用场景中的示例性应用。

在本申请实施例中，基于场景的特权道具在传统的道具运营之外提供一种新的道具管理方法：通过为特定物理场景的用户进行画像，根据用户的背景信息和兴趣爱好提供符合其口味的场景专属道具。图6为本申请实施例特权道具管理系统的组成结构示意图，如图6所示，在所述管理系统中包括：终端机器601、场景网关602、场景管理端603、特权服务端604和业务服务端605，其中：

终端机器601，包括业务客户端6011和场景客户端6012，用户登录业务客户端6011体验服务，如英雄联盟；场景客户端6012采集场景特征信息以提供判断终端机器是否位于特权场景的数据依据，场景客户端6012与场景网关602保持定时心跳并接受其管控。场景客户端6012根据终端机器的类型而有不同的实现方式，例如当终端机器为个人计算机(PC，Personal Computer)时，场景客户端6012可以为独立于业务客户端6011的应用程序，当终端机器为移动手机、平板电脑时，场景客户端6012可以是集成与业务客户端6011的软件工具开发包(SDK，Software Development Kit)。

场景网关602：一般部署在该物理场景的中央服务器(如实体网吧的网管服务器)或者关键节点机器上。与同一网络拓扑结构下的其它终端机器通过心跳联系，实时更新该场景下各终端机器的活跃状态并接受场景管理端603的远程控制，场景网关602采用多种安全策略监控各终端机器的行为，包括同一局域网IP地址上终端设备活跃频率、网络路由跳数、代理和VPN等。

场景管理端603：接收场景网关602的数据上报并监控全网场景网关602的活动，并根据预定安全策略剔除行为异常的场景网关节点。

举例来说，当一个场景网关节点被两个不同的特权场景占用，此时认为该场景网关节点存在异常，在剔除行为异常的场景网关节点时的实现方式包括：

一、将该场景网关节点分配给先占用的特权场景；

二、将该场景网关节点分配给后占用的特权场景；

三、直接将该场景网关节点剔除，也即将该场景网关节点不分配给后占用的特权场景也不分配给先占用的特权场景。

特权服务端604：是特权道具的最终裁决中心，依托完整的场景特征信息库对用户所在物理场景进行判断，向业务服务端605反馈场景适用的特权道具，并对已失效的特权道具进行撤销与回收。

此外，特权服务端604还可以采用离线方式对场景特征信息库迭代更新，进一步地，可以是特权服务端604在判断出现异常情况时，采用离线方式对场景特征信息库进行迭代更新。

业务服务端605：通过业务客户端6011与用户交互，处理用户登录和操作事件，根据所在物理场景激活特权道具。

在一些实施例中，场景管理端603和特权服务端604可以部署在同一个服务器实体中，但是一般情况下，基于服务隔离的原因，将场景管理端603和特权服务端604分别部署在不同的服务器实体中。

基于场景的特权道具管理方法的实施包括2个阶段：物理场景特权道具的接入阶段和用户特权道具体验阶段。以下结合图7和图8对这两个不同的阶段分别进行相关说明。

图7为本申请实施例物理场景特权道具的接入阶段实现流程示意图，如图7所示，所述流程包括：

步骤S701，物理场景商家向场景管理端注册申请成为特权场景。

其中，物理场景商家在申请注册时，需要提供的资料包括申请人信息、商家的地理位置与规模、行业属性，是否有中心节点等。

步骤S702，场景管理端对物理场景商家进行特权场景审核，判断是否审核通过。

这里，当对物理场景商家的审核通过后，在中心节点部署场景网关，与中心节点同网络拓扑下的终端机器部署场景客户端。完成环境部署后进入步骤S703；当对物理场景商家的审核未通过时，结束流程。

步骤S703，接入方在场景管理平台(场景管理端)申请场景特权道具。

步骤S704，场景管理端对接入方选择的套餐进行资格审核。

这里，当对选择的套餐进行资格审核通过时，进入步骤S705，向物理场景商家发送支付信息，并在支付成功后激活业务限定套餐；当对选择的套餐进行资格审核不通过时，结束流程。

步骤S705，场景管理端向物理场景商家发送支付信息，并在支付成功后激活业务限定套餐。

这里，物理场景商家在接收到支付信息后，进行在线支付，在支付成功后，场景管理端会接收到支付成功消息，此时场景管理端激活该物理场景商家的业务限定套餐。在激活业务限定套餐之后，套餐中的特权道具也即配置生效。

步骤S706，场景管理端发布/更新业务套餐，并同步信息给特权服务端。

这里，在激活业务限定套餐之后，场景管理端可以将业务限定套餐发布或更新，那么当用户在特权场景内使用业务客户端登录道具商城时，即可体验由物理场景商家冠名的特权道具了。

步骤S707，场景管理端对发布的业务套餐进行套餐资格检查，以确定业务套餐是否到期。

这里，当确定业务套餐未过期时，进入步骤S708响应商场的特权请求，当确定业务套餐过期时，进入步骤S709，判断是否续费。

步骤S708，特权服务端响应目标业务用户登录时的特权请求。

步骤S709，场景管理端判断是否续费当前套餐。

这里，当特权道具失效前会通知物理场景商家续费，若未完成续费操作，则进入步骤S710立即回收道具商城内的特权道具；当续费完成，那么继续在道具商城发布该业务套餐，并将套餐失效时间等同步给特权服务端。

步骤S710，回收业务限定套餐。

图8为本申请实施例用户特权道具体验阶段的实现流程示意图，如图8所示，所述流程包括：

步骤S801，用户登录目标业务。

这里，用户通过终端机器上的业务客户端登录目标业务。

步骤S802，特权服务端判断用户登录目标业务所使用的终端机器是否在特权场景。

这里，在用户利用终端机器登录目标业务的过程中，场景客户端实时提取终端机器的特征信息，通过两种方式上报给特权服务端，一种是直接通过外部网络；另一种是通过内部局域网向场景网关上报，然后场景网关将特征信息转发给场景服务器并最终上报给特权服务器，通过特征信息判断用户(也即终端机器)是否位于特权场景，当确定终端机器在特权场景时，特权服务端向业务服务端返回特权道具，此时进入步骤S803；当不在特权场景时，结束流程。

步骤S803，特权服务端提取特权场景定制的专属套餐。

这里，特权服务端在提取出特权场景定制的专属套餐后，将专属套餐返回给业务服务端。

步骤S804，业务服务端判断是否展示专属道具。

这里，如果需要展示专属道具，进入步骤S805；如果不需要展示专属道具，结束流程。

步骤S805，道具商城激活并展示专属道具。

这里，道具商城激活并展示专属道具时，还可以根据用户已拥有的道具信息、用户的兴趣爱好，确定出专属道具的展示策略，例如可以优先展示用户没有的道具，还可以优先展示与用户使用习惯接近的道具等。

步骤S806，用户选择专属道具并免费使用。

这里，当用户所使用的终端机器在特权场景中时，即可免费使用专属道具，而无需购买。

步骤S807，特权服务端检查道具是否依然生效。

这里，如果道具已过期，进入步骤S808；如果道具依然有效，进入步骤S809。

步骤S808，特权服务端收回/屏蔽专属道具。

这里，特权服务端收回/屏蔽专属道具，可以是在道具商城中不再显示该专属道具，还可以是在道具商城中显示该专属道具，但是用户点击“免费使用”时，提示道具已失效。

特权服务端收回/屏蔽专属道具后，可以提示物理场景商家进行续费。

步骤S809，用户体验专属道具。

这里，如果专属道具依然有效，那么用户点击免费使用后，即可体验专属道具。

基于场景的特权道具实现系统让用户的体验流程非常简单明确，几乎不需要额外的操作：用户在终端机器上启动业务客户端，进入道具商城找到由物理场景商家冠名的特权道具，点击“免费使用”即可激活，当然用户也可以选择忽略。

用户登录过程中，道具管理系统执行以下操作来保障场景特权体验的稳定、顺畅和安全。首先，场景管理端会实时提取终端机器特征信息，通过特征信息判断用户是否位于特权场景，并关联到具体的场景实体，以确定场景实体是否有效；然后，特权服务端检查场景实体的特权道具配置，选择最优匹配返回并展示在道具商城；最后，业务服务端触发特权服务端定期确认特权道具是否依然生效，若套餐失效则撤回特权道具，并回收游戏权益。

在特权体验过程中，场景客户端监控并检测终端机器是否存在异常行为，如场景客户端会不定期采集终端特征信息，包括特权激活频次和网路相关的信息，并将检测结果上报场景管理器，场景管理器综合多维度信息完成安全策略的调整。

在本申请实施例提供的道具管理方法中，将业务线上运营和线下活动有机结合起来，针对不同场景实现可定制的精细化运营，提升效率。并且通过授权特权场景对道具冠名的方式提升了物理场景的感知能力和参与积极性，能够聚集更多人气，从而进一步提升业务活跃度。

下面继续说明本申请实施例提供的道具管理装置80的实施为软件模块的示例性结构，在一些实施例中，如图2所示，存储在存储器240的道具管理装置80中的软件模块可以包括：

第一获取模块81，用于基于接收到的申请成为特权场景的注册请求，获取请求方的属性信息；

第二获取模块82，用于当确定所述属性信息满足特权场景注册条件时，获取所述请求方对应的用户数据；

第一确定模块83，用于基于所述用户数据确定所述用户的偏好信息，并基于所述偏好信息，确定所述请求方的候选道具信息；

第一发送模块84，用于向所述请求方发送注册成功的响应消息，所述响应消息中携带有所述候选道具信息。

在一些实施例中，所述装置还包括：

第一接收模块，用于接收请求方发送的目标道具信息；

审核模块，用于基于所述属性信息和目标道具信息，对所述请求方进行资格审核，得到审核结果；

第二发送模块，用于当所述审核结果表明所述请求方具有所述目标道具信息的使用资格时，向所述请求方发送支付信息；

关系建立模块，用于当接收到支付成功的通知消息时，建立所述请求方和所述目标道具信息的对应关系。

在一些实施例中，所述装置还包括：

第二接收模块，用于接收业务服务器发送的道具查询请求；

第三获取模块，用于基于所述道具查询请求，获取已登录所述业务服务器的终端的特征信息；

第四获取模块，用于基于所述特征信息确定所述终端所处的特权场景，并获取所述特权场景对应的道具信息；

第三发送模块，用于将所述道具信息发送给所述业务服务器。

在一些实施例中，所述装置还包括：

第五获取模块，用于获取所述特权场景的活跃度信息；

第二确定模块，用于基于所述活跃度信息，确定所述特权场景符合预设的有效条件时，获取所述道具信息的失效时间；

第三确定模块，用于根据当前时间和所述失效时间，确定所述道具信息是否过期，其中，当所述道具信息未过期时，将所述道具信息发送给所述业务服务器。

在一些实施例中，所述装置还包括：

第四确定模块，用于根据所述失效时间和当前时间确定所述道具信息对应的剩余使用时长；

第四发送模块，用于当所述剩余使用时长小于时长阈值时，向所述道具信息对应的请求方发送缴费提醒消息，所述缴费提醒消息中携带有所述剩余使用时长和缴费金额。

在一些实施例中，所述装置还包括：

删除模块，用于当达到所述失效时间未接收到所述请求方的缴费成功消息时，删除所述道具信息和请求方之间的对应关系，以撤销所述请求方的道具使用权限。

在一些实施例中，所述装置还包括：

第六获取模块，用于获取所述特权场景中各个终端的道具激活频次信息和网络路由信息；

第五确定模块，用于基于各个终端的道具激活频次信息和网络路由信息确定目标终端，其中，所述目标终端为道具激活频次信息和网络路由信息不符合安全策略的终端；

第五发送模块，用于当检测到已登录所述业务服务器的终端为目标终端时，向所述业务服务器发送无免费道具可使用的响应消息。

本申请实施例提供一种存储有可执行指令的存储介质，其中存储有可执行指令，当可执行指令被处理器执行时，将引起处理器执行本申请实施例提供的方法，例如，如图3、图4、图5、图7和图8示出的方法。

在一些实施例中，存储介质可以是FRAM、ROM、PROM、EPROM、EE PROM、闪存、磁表面存储器、光盘、或CD-ROM等存储器；也可以是包括上述存储器之一或任意组合的各种设备。

在一些实施例中，可执行指令可以采用程序、软件、软件模块、脚本或代码的形式，按任意形式的编程语言(包括编译或解释语言，或者声明性或过程性语言)来编写，并且其可按任意形式部署，包括被部署为独立的程序或者被部署为模块、组件、子例程或者适合在计算环境中使用的其它单元。

作为示例，可执行指令可以但不一定对应于文件系统中的文件，可以可被存储在保存其它程序或数据的文件的一部分，例如，存储在超文本标记语言(H TML，Hyper TextMarkup Language)文档中的一个或多个脚本中，存储在专用于所讨论的程序的单个文件中，或者，存储在多个协同文件(例如，存储一个或多个模块、子程序或代码部分的文件)中。

作为示例，可执行指令可被部署为在一个计算设备上执行，或者在位于一个地点的多个计算设备上执行，又或者，在分布在多个地点且通过通信网络互连的多个计算设备上执行。

以上所述，仅为本申请的实施例而已，并非用于限定本申请的保护范围。凡在本申请的精神和范围之内所作的任何修改、等同替换和改进等，均包含在本申请的保护范围之内。

Claims (10)

1.一种道具管理方法，其特征在于，包括：

基于接收到的特权场景注册请求，获取请求方的属性信息；

当确定所述属性信息满足特权场景注册条件时，获取所述请求方对应的用户数据；

基于所述用户数据确定所述用户的偏好信息，并基于所述偏好信息，确定所述请求方的候选道具信息；

向所述请求方发送注册成功的响应消息，所述响应消息中携带有所述候选道具信息。

2.根据权利要求1中所述的方法，其特征在于，所述方法还包括：

接收请求方发送的目标道具信息；

基于所述属性信息和目标道具信息，对所述请求方进行资格审核，得到审核结果；

当所述审核结果表明所述请求方具有所述目标道具信息的使用资格时，向所述请求方发送支付信息；

当接收到支付成功的通知消息时，建立所述请求方和所述目标道具信息的对应关系。

3.根据权利要求1或2中所述的方法，其特征在于，所述方法还包括：

接收业务服务器发送的道具查询请求；

基于所述道具查询请求，获取已登录所述业务服务器的终端的特征信息；

基于所述特征信息确定所述终端所处的特权场景，并获取所述特权场景对应的道具信息；

将所述道具信息发送给所述业务服务器。

4.根据权利要求3中所述的方法，其特征在于，所述方法还包括：

获取所述特权场景的活跃度信息；

基于所述活跃度信息，确定所述特权场景符合预设的有效条件时，获取所述道具信息的失效时间；

根据当前时间和所述失效时间，确定所述道具信息是否过期，其中，当所述道具信息未过期时，将所述道具信息发送给所述业务服务器。

5.根据权利要求4中所述的方法，其特征在于，所述方法还包括：

根据所述失效时间和当前时间确定所述道具信息对应的剩余使用时长；

当所述剩余使用时长小于时长阈值时，向所述道具信息对应的请求方发送缴费提醒消息，所述缴费提醒消息中携带有所述剩余使用时长和缴费金额。

6.根据权利要求5中所述的方法，其特征在于，所述方法还包括：

当达到所述失效时间未接收到所述请求方的缴费成功消息时，删除所述道具信息和请求方之间的对应关系，以撤销所述请求方的道具使用权限。

7.根据权利要求4至6中任一项所述的方法，其特征在于，所述方法还包括：

获取所述特权场景中各个终端的道具激活频次信息和网络路由信息；

基于各个终端的道具激活频次信息和网络路由信息确定目标终端，其中，所述目标终端为道具激活频次信息和网络路由信息不符合安全策略的终端；

当检测到已登录所述业务服务器的终端为目标终端时，向所述业务服务器发送无免费道具可使用的响应消息。

8.一种道具管理装置，其特征在于，包括：

第一获取模块，用于基于接收到特权场景注册请求，获取请求方的属性信息；

第二获取模块，用于当确定所述属性信息满足特权场景注册条件时，获取所述请求方对应的用户数据；

第一确定模块，用于基于所述用户数据确定所述用户的偏好信息，并基于所述偏好信息，确定所述请求方的候选道具信息；

第一发送模块，用于向所述请求方发送注册成功的响应消息，所述响应消息中携带有所述候选道具信息。

9.一种道具管理设备，其特征在于，包括：

存储器，用于存储可执行指令；

处理器，用于执行所述存储器中存储的可执行指令时，实现权利要求1至7任一项所述的方法。

10.一种存储介质，其特征在于，存储有可执行指令，用于引起处理器执行时，实现权利要求1至7任一项所述的方法。

Images