CN113869866A - 请求处理方法、装置、设备及存储介质 - Google Patents

Abstract

本申请公开了一种请求处理方法、装置、设备及存储介质，属于计算机技术领域。所述方法包括：接收第一帐号的信息服务请求；获取与目标位置信息匹配的第二帐号集合；获取各个第二帐号对应的历史服务信息；根据历史服务信息和第二服务需求信息，从第二帐号集合中确定与第一帐号匹配的目标帐号；向目标帐号对应的客户端发送信息服务请求，以获取与信息服务请求对应的反馈信息。本申请实施例提供的技术方案，能够充分结合服务请求中的需求信息以及第二帐号的服务信息，为第一帐号分配位置匹配且服务质量较好的第二帐号进行服务，提升服务请求处理的质量和速度，综合提升了请求处理效率。

Description

请求处理方法、装置、设备及存储介质

技术领域

本申请涉及计算机技术领域，特别涉及一种请求处理方法、装置、设备及存储介质。

背景技术

随着互联网技术的发展，越来越多的用户选择在互联网平台上发起服务请求。用户在互联网平台上发起服务请求后时，互联网平台可为其分配相应的服务帐号指向的服务人员处理该服务请求。

相关技术中，用户发起服务请求后，互联网平台会随机为用户帐号分配相应的服务帐号处理该用户的请求。比如，将用户请求随机分配给登录有服务人员帐号的客户端，以使该服务帐号指向的服务人员对用户请求进行反馈。然而，实际应用中，用户的服务请求是多样的，随机分配的方式效率低下，无法及时有效地响应用户需求并分配合适的资源信息。

发明内容

本申请实施例提供了一种请求处理方法、装置、设备及存储介质，能够。

根据本申请实施例的一个方面，提供了一种请求处理方法，所述方法包括：

接收第一帐号的信息服务请求，所述信息服务请求包括第一服务需求信息和第二服务需求信息，所述第一服务需求信息包括目标位置信息；

获取与所述目标位置信息匹配的第二帐号集合，所述第二帐号集合中各个第二帐号对应的服务位置与所述目标位置信息指示的目标位置相对应；

获取所述各个第二帐号对应的历史服务信息；

根据所述历史服务信息和所述第二服务需求信息，从所述第二帐号集合中确定与所述第一帐号匹配的目标帐号，所述目标帐号对应的历史服务信息与所述第二服务需求信息相匹配；

向所述目标帐号对应的客户端发送所述信息服务请求，以获取与所述信息服务请求对应的反馈信息。

根据本申请实施例的一个方面，提供了一种请求处理装置，所述装置包括：

请求接收模块，用于接收第一帐号的信息服务请求，所述信息服务请求包括第一服务需求信息和第二服务需求信息，所述第一服务需求信息包括目标位置信息；

帐号获取模块，用于获取与所述目标位置信息匹配的第二帐号集合，所述第二帐号集合中各个第二帐号对应的服务位置与所述目标位置信息指示的目标位置相对应；

历史信息获取模块，用于获取所述各个第二帐号对应的历史服务信息；

目标帐号确定模块，用于根据所述历史服务信息和所述第二服务需求信息，从所述第二帐号集合中确定与所述第一帐号匹配的目标帐号，所述目标帐号对应的历史服务信息与所述第二服务需求信息相匹配；

请求分配模块，用于向所述目标帐号对应的客户端发送所述信息服务请求，以获取与所述信息服务请求对应的反馈信息。

根据本申请实施例的一个方面，提供了一种计算机设备，包括至少一个处理器，以及与所述至少一个处理器通信连接的存储器；其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述至少一个处理器通过执行所述存储器存储的指令实现上述请求处理方法。

根据本申请实施例的一个方面，提供了一种计算机可读存储介质，所述存储介质中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或指令集由处理器加载并执行以实现上述请求处理方法。

本申请实施例提供的技术方案可以带来如下有益效果：

通过对接收到的第一帐号的信息服务请求进行解析，得到其中携带的第一服务需求信息和第二服务需求信息，通过筛选服务位置与第一服务需求信息中的目标位置信息相匹配的第二帐号，得到第二帐号集合并从中找到历史服务信息与第二服务需求信息匹配的目标帐号，最终将该服务请求分配给目标帐号进而获得相应的反馈信息，能够充分结合服务请求中的需求信息以及第二帐号的服务信息，为第一帐号分配位置匹配且服务质量较好的第二帐号进行服务，提升服务请求处理的质量和速度，综合提升了请求处理效率。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请一个实施例提供的应用程序运行环境的示意图；

图2是本申请一个实施例提供的请求处理方法的流程图；

图3(a)示例性示出了一种注册帐号的页面示意图；

图3(b)示例性示出了填写服务需求信息的页面示意图；

图4至图9分别是本申请实施例提供的请求处理方法的流程图；

图10是本申请一个实施例提供的请求处理装置的框图；

图11是本申请一个实施例提供的计算机设备的结构框图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。

请参考图1，其示出了本申请一个实施例提供的应用程序运行环境的示意图。该应用程序运行环境可以包括：终端10和服务器20。

终端10可以是诸如手机、平板电脑、游戏主机、电子书阅读器、多媒体播放设备、可穿戴设备、PC(Personal Computer，个人计算机)等电子设备。终端10中可以安装应用程序的客户端。

在本申请实施例中，上述应用程序可以是能够提供生活服务的应用程序。典型地，该应用程序为招聘类应用程序。当然，除了招聘类应用程序之外，其它类型的应用程序中也可以提供生活服务。例如，置业类应用程序、购物类应用程序、社交类应用程序、互动娱乐类应用程序、浏览器应用程序、客服类应用程序等，本申请实施例对此不作限定。另外，对于不同的应用程序来说，其提供的生活服务也会有所不同，且相应的功能也会有所不同，这都可以根据实际需求预先进行配置，本申请实施例对此不作限定。可选地，终端10中运行有上述应用程序的客户端。在一些实施例中，上述生活服务包括招聘信息分享服务，用于向用户提供工作信息。

服务器20用于为终端10中的应用程序的客户端提供后台服务。可选地，服务器20同时为多个终端10中的应用程序提供后台服务。

可选地，终端10和服务器20之间可通过网络30进行互相通信。终端10以及服务器20可以通过有线或无线通信方式进行直接或间接地连接，本申请在此不做限制。

请参考图2，其示出了本申请一个实施例提供的请求处理方法的流程图。该方法可应用于计算机设备中，所述计算机设备是指具备数据计算和处理能力的电子设备，如各步骤的执行主体可以是图1所示的应用程序运行环境中的服务器20。该方法可以包括以下几个步骤(210～250)。

步骤210，接收第一帐号的信息服务请求。

上述第一帐号可以是使用相关应用服务的用户所持有的电子帐号。比如，在求职类应用中，上述用户可以是具有求职需求的用户，例如蓝领找工作者。

上述信息服务请求是指用户执行预设操作触发的用于请求信息服务的请求。可选地，上述信息服务请求可以是新用户执行注册操作触发的请求，也可以是用户在***可检测的第三方应用上执行预设操作发起的请求，比如，预设操作为填写表单操作、注册操作，本申请实施例对此不作限定。

信息服务请求包括第一服务需求信息和第二服务需求信息，第一服务需求信息包括目标位置信息。第一服务需求信息和第二服务需求信息中包括不同类型的服务需求信息，可根据实际情况将服务需求信息划分为第一服务需求信息和第二服务需求信息。

在一种可能的实施方式中，服务需求信息包括个人信息。在一些应用场景中，个人信息由用户在应用注册时填写，或者在后期使用过程中修改。

在一种可能的实施方式中，服务需求信息包括目标位置信息。上述目标位置信息为用户设置的位置信息。可选地，目标位置信息可以被划分至第一服务需求信息中，也可以被划分至第二服务需求信息中。在一种可能的实施方式中，第一服务需求信息包括目标位置信息。可选地，上述目标位置信息用于表征用户设定的服务区域。比如，在求职类应用中，用户可以设定意向工作区域，或者设置服务人员的服务区域，进而得到目标位置信息。比如，在应用中填写是否期望寻找本地服务人员，即可将目标位置信息设置为用户所在地区。可选地，上述目标位置信息用于表征用户所在位置，具体可通过如下两种方式获取上述目标位置信息。第1种是用户输入方式，即在注册或输入当前需求时，用户输入自己当前的位置(例如：城市)；第2种是***自动获取，可以是用户在注册/输入当前需求时，***自动获取其位置，也可以是在注册/输入当前需求时，提示用户去定位当前位置或直接获取用户的当前位置。

在一种可能的实施方式中，服务需求信息还包括服务者特征。上述服务者特征可以被划分至第一服务需求信息中，也可以被划分至第二服务需求信息中。在一种可能的实施方式中，第二服务需求信息包括服务者特征。可选地，上述服务者特征是指用户基于自身需求设定的服务者的性格特征，表征用户期望分配的第二帐号对应的使用者性格。例如，求职类应用中用户期望的经纪人性格。上述性格特征具有多个性格类别，可通过具体的算法或者信息确定，本申请实施例对此不作限定。

在一种可能的实施方式中，服务需求信息还包括资源需求信息。上述资源需求信息是指第一帐号指向的客户端所需资源的相关信息。可选地，资源需求信息可以被划分至第一服务需求信息中，也可以被划分至第二服务需求信息中。在一种可能的实施方式中，第二服务需求信息包括资源需求信息。

在一种可能的实施方式中，上述资源需求信息包括资源获取时限信息和请求资源类型信息。

可选地，上述资源获取时限信息用于表征第一帐号获取资源的时间期限。例如，在求职类应用中，第一帐号指向的用户可通过对“是否希望尽快找到工作”的选项进行选择，进而设置上述资源获取时限信息。

可选地，资源需求信息还包括响应时限信息。上述响应时限信息还可表征第一帐号对第二帐号响应时间的时间期限，即需求响应时间。示意性的，在求职类应用中，需求响应时间代表用户对于经纪人的反馈时间是否有要求，例如，用户希望能够尽快有人和他进行联系，“需求响应时间”的取值可以是：快、一般(对于响应时间)，也可以：是、否(对于是否希望尽快找到工作)。

可选地，上述请求资源类型信息用于表征第一帐号所需资源的类型。示意性的，在求职类应用中，上述请求资源类型信息包括但不限于用户意向工作的薪资信息、工作种类信息、企业类型信息、工作稳定程度信息。可选地，用户可以填写找工作目标，例如“养家糊口、打发时间、自我实现”等目标，***可以根据预设的映射规则，确定每种目标对应的薪资信息、工作种类信息、企业类型信息、工作稳定程度信息，进而进行资源分配，能够量化用户的需求信息，便于后续匹配。

可选地，企业类型可以包括：服务业、新能源(生产制造)、化工(生产制造)、汽车整车/配件(生产制造)、电子厂(生产制造组装)、供应链/物流、教育培训、房地产/建筑、医疗健康等，本申请实施例对此不作限定。

在一个示例中，如图3(a)所示，其示例性示出了一种注册帐号的页面示意图。在用户注册第一帐号时，要求用户填写个人信息(包括，是否希望本城市寻找经纪人-是、否；期望经纪人性格-大气硬朗型、温柔亲和型、强势有为型；找工作目标-养家糊口、打发时间、自我实现)。用户可以点击个人偏好设置栏301中的展开控件302补充填写服务需求信息。用户对展开控件302进行相应操作后，页面跳转，跳转后的页面图3(b)所示。图3(b)示例性示出了填写服务需求信息的页面示意图。在图3(b)中，用户可以设置上述目标位置信息。例如，对于“您是否介意经纪人非本城市”的问题，用户可以选择介意选项303，表示将目标位置信息设置为本城市，用户也可以选择不介意选项304，表示将目标位置信息设置为不限区域。此外，用户也可以选择经纪人性格选项305，还可以选择工作倾向选项306，还可以通过个性化需求设置框306进行进一步的设置，完善服务需求信息。需要说明的是，本申请实施例对服务需求信息的内容不作限定。

步骤220，获取与目标位置信息匹配的第二帐号集合。

第二帐号集合中各个第二帐号对应的服务位置与目标位置信息指示的目标位置相对应。

上述第二帐号可以是为第一帐号提供相应服务的帐号。在一些应用场景中，上述第二帐号是一个智能机器人，用于为用户提供自助服务，也可以是应用中提供服务的用户所持有的电子帐号。例如，求职类应用中的经纪人所持有的帐号为第二帐号。

上述服务位置可以是第二帐号对应的地理位置，或者第二帐号对应的实体服务位置。例如，求职类应用中经纪人帐号对应的门店位置。

在分配规则中，将第二帐号对应的服务位置与目标位置信息进行匹配，确定出与目标位置信息匹配的服务位置，然后将匹配到的服务位置对应的第二帐号进行汇总，得到上述第二帐号集合。

在示例性实施例中，如图4所示，上述步骤220的实施过程包括如下步骤(221～222)。

步骤221，确定与目标位置信息对应的目标服务区域。

可选地，通过目标位置信息判断第一帐号选择期望寻找的第二帐号对应的服务区域，即上述目标服务区域。在一个示例中，目标服务区域为第二帐号当前所在城市。

步骤222，若目标服务区域内存在至少一个服务位置，则基于至少一个服务位置，生成第二帐号集合。

判断目标服务区域之后，判断目标服务区域是否有服务位置，例如经纪人门店。在一个示例中，若用户选择的目标服务区域不是第一帐号所在城市，则可选择全国区域内的第二帐号。

在一种可能的实施方式中，上述目标服务区域为第一帐号的当前登录位置的所在区域。相应的，如图5所示，上述步骤222的实施过程包括如下步骤(222A～222B)。

步骤222A，若目标服务区域内存在至少一个服务位置，则从至少一个服务位置中，确定与当前登录位置对应的目标服务位置。

上述步骤中确定目标服务区域之后，还可以对目标服务区域进行如下判断：

若目标服务区域存在服务位置，则获取与第一帐号的当前登录位置距离最近的服务位置，即上述目标服务位置。

步骤222B，将目标服务位置对应的至少一个第二帐号作为第二帐号集合。

若目标服务区域内不存在服务位置，则将第一帐号纳入默认服务区域中，并推送信息给第一帐号：由于当前服务区域有限，未分配到目标服务区域内的第二帐号，目前服务的第二帐号为xx帐号，若有异议可进行更换。并推送信息给第二帐号：目标服务区域是xxx区域，由于服务区域暂未涉及，第一帐号可能产生地域性需求，请注意处理。

步骤230，获取各个第二帐号对应的历史服务信息。

在一种可能的实施方式中，在后台或数据库中，上述第二帐号对应的历史服务信息包括但不限于第二帐号对应的帐号使用者特征、响应行为信息、资源使用数据以及请求处理数据。

在一种可能的实施方式中，历史服务信息包括帐号使用者特征。可选地，上述帐号使用者特征的确定过程包括：获取各个第二帐号对应的帐号使用者信息，帐号使用者信息包括性格标签、消息语料和操作行为日志中的至少一种；基于帐号使用者信息，确定各个第二帐号对应的帐号使用者特征。上述性格标签可以是帐号使用者自行添加的性格标签，上述消息语料可以是帐号使用者的历史聊天消息记录，上述操作行为日志也可以是帐号使用者在应用中的操作记录。可选地，可通过对帐号使用者信息进行用户画像建模，得到第二帐号对应的帐号使用者特征。

示例性的，在求职类应用中，在每个经纪人首次被分配来处理用户的服务需求之前，***向经纪人发送问卷调查；经纪人基于自身实际情况填写并提交，得到经纪人的问卷调查结果，通过计算得到如下16种人格因素的得分：乐群性(A)、聪慧性(B)、稳定性(C)、恃强性(E)、兴奋性(F)、有恒性(G)、敢为性(H)、敏感性(I)、怀疑性(L)、幻想性(M)、世故性(N)、忧虑性(O)、实验性(Q1)、独立性(Q2)、自律性(Q3)、紧张性(Q4)；基于上述16种人格因素的得分进行二阶因素分析，分别计算经纪人在适应性、外向性、安详机警性与果敢性四种性格类型的得分值；将得分值最高的性格类型作为经纪人的性格类型。适应性对应类型为友善型，求得分数即代表“适应”之强弱，高分者生活适应顺利，通常感觉心满意足；外向性对应类型为外向型，所得分数即代表安详机警性，高分者外倾，通常善于交际，开朗，不拘小节；安详机警性对应类型为机警型，所得分数即代表安详机警性，高分者安详警觉，果断刚毅，进取精神；果敢性对应类型为果敢型，高分者独立、果敢、锋芒毕露，有气魄，常常自动寻找可以施展所长的环境或机会。

可选地，通过响应行为信息表征第二帐号的响应速度。可选地，上述响应行为信息包括响应时间间隔，上述响应时间间隔可以是第二帐号的平均响应时间间隔。可选地，上述响应行为信息包括响应总时长，上述响应总时长是指第二帐号处理信息服务请求对应的响应时间间隔的总和。示意性的，在求职类应用中，表征反馈时间属性的响应行为信息包括但不限于经纪人对于需求的响应时间、反馈时间、响应速度、反馈速度等数据。可选地，反馈时间属性有2种取值方式，可以是按照不同范围分为“优、良、中、差”，也可以以分钟为单位，直接统计第二帐号对于所有需求的平均响应时间、或平均反馈时间。示意性的，在求职类应用中，上述响应时间间隔可以是从***检测到用户发起信息服务请求，到经纪人通过打电话、发短信、发社交软件消息、写聊天记录其中之一的方式联系到用户为止的时间间隔。可选地，响应时间间隔在平均10分钟内(包括10分钟)则评定为：好；平均10到30分钟(包括30分钟)则评定为：良；平均30到60分钟(包括60分钟)则评定为中；超过60分钟则评定为差。其中，对于新接入***的第二帐号的前20个需求不会计入统计，新接入***的第二帐号对应的响应时间属性均按照优计算，从第21个需求分配开始进入正常计算流程。

在用户使用应用A，经纪人使用应用B的场景下，用户在应用A发起需求或注册个人信息，需求发送到后台或服务器，后台或服务器进行分配规则的判断，发给目标经纪人，经纪人通过应用B接收服务器的信息，并响应需求并反馈信息。后台可以通过对应用B的监控，获取到经纪人对于不同需求的响应时间间隔。其中，具体的响应需求的方式，可以是通过应用B的聊天功能与使用应用A的用户进行联系；响应时间间隔可以用以下公式计算：响应时间间隔＝经纪人响应需求的时间-***将需求分配给经纪人的时间。

对于上述打电话的场景，获取历史服务信息的方式如下：第一种，***通过手机通讯录授权(可以是***自动获取用户的手机的通讯录授权信息，也可以是***向用户的手机发送授权请求，用户同意后，获取手机的通讯录授权信息)，获取手机的通话记录以及通讯录，从而基于经纪人打电话开始时间、打电话对象以及打电话时长判断经纪人的电话联系情况；另一种是如果经纪人通过应用的虚拟拨号功能，***可以进行语音记录监听以及通话记录以及通话内容，从而获取到经纪人收到需求的处理状态以及处理反馈情况。可选地，录音反馈需要人工判断，录音转化为文字后进行敏感词检验，发现敏感词推给客服，客服判定是否有服务问题，若有则进行后续处罚。

对于上述发短信的场景，获取历史服务信息的方式如下：发短信场景的监控需要***预先通过手机短信授权，获取短信信息，获取经纪人短信发送记录以及发送内容。

对于上述发社交软件消息的场景，获取历史服务信息的方式如下：发社交软件消息场景的监控为：基于社交软件的聊天记录数据与当前应用的后台***打通后，定期从社交软件拉取经纪人的聊天记录以及聊天时间。

对于上述写聊天记录的场景，获取历史服务信息的方式如下：***提供用于录入聊天内容备注的后台接口，以便于帐号使用者填写并提交聊天记录以及聊天内容，经纪人在填写回访内容后会自动将该用户的本次需求标记为已经回访。

在一种可能的实施方式中，上述资源使用数据用于表征第二帐号的服务能力属性。可选地，服务能力属性有3个子属性，即(1)用户薪资能力、(2)企业类型或工种类型、(3)用户稳定性。

上述用户薪资能力是指由第二帐号服务的历史第一帐号的薪资水平的分析结果，具体可以通过数值表示，例如平均工资对应的数值。示例性的，在求职类应用中，定期(每隔3个月/每隔6个月/每隔1年)统计第二帐号指向的经纪人已经服务的所有用户(即完成的所有需求所涉及的用户)的平均月薪，仅统计在职用户，因为用户离职状态下没有薪资，会影响对于平均薪资统计分析的准确性。可选地，有2种方式：第1种方式：对每个用户，统计其在职期间的平均月薪，然后再对所有用户的平均月薪，进行第二次平均；第2种方式：对于每个用户，获取在当前时间点(统计的时间点)的上一个月(完整工作的月份)的薪资，然后再对所有用户的月薪进行平均。

上述企业类型或工种类型是指第二帐号对应的帐号使用者擅长的或者具有工作机会的企业类型或工种类型。示例性的，在求职类应用中，跟踪第二帐号对应的经纪人已经服务的所有用户(即经纪人完成的所有需求所涉及的用户)，统计其所在的企业类型或工种类型，最终的统计结果可以是2种：1、经纪人对于不同的企业类型或工种类型所服务过的用户数量；2、上述数量排序后的前3位，即经纪人最熟悉的企业类型或工种类型。

上述用户稳定性是指第二帐号服务的历史第一帐号的资源使用稳定性。示例性的，在求职类应用中，上述用户稳定性可以从3个角度体现，离职率、在职天数、或在职月数。定期(每隔3个月/每隔6个月/每隔1年)跟踪第二帐号对应的经纪人已经服务的所有用户(即经纪人完成的所有需求所涉及的用户)，统计平均值。一是通过在职天数判断用户稳定性，可以根据该员工的打卡记录判断，如果某天有有效的上下班打卡记录，认为其当天在职。二是通过在职月数/离职率判断用户稳定性。可选地，有3种方法：1、可以通过薪资记录的方式判断，即如果3月后的企业的当月薪资记录没该员工的记录，可以认为其离职，否则，其在职；2、可以通过该员工的打卡记录，如果当月的打卡次数超过某阈值，认为其当月在职，因为离职后企业会收回工卡或者从***中清除该员工的记录；3、也可以让企业直接给出该批员工的离职率，判断员工的离职率。

可选地，当前工作状态表示第二帐号当前是否有未处理完的需求，可以是工作中或者空闲中。

步骤240，根据历史服务信息和第二服务需求信息，从第二帐号集合中确定与第一帐号匹配的目标帐号。

目标帐号对应的历史服务信息与第二服务需求信息相匹配。

在示例性实施例中，历史服务信息包括响应行为信息，可根据响应行为信息进行匹配。如图4所示，上述步骤240的实施过程包括如下步骤(241～242)。

步骤241，将第二帐号集合中响应行为信息符合响应行为条件的第二帐号确定为候选第二帐号。

上述响应行为信息包括响应时间间隔等级，例如优、良、中。上述符合响应行为条件的情形可以是响应时间间隔等级为预设等级，或者响应时间间隔处于预设时间间隔区间，本申请实施例对此不作限定。

步骤242，基于第二服务需求信息和候选第二帐号对应的历史服务信息，从候选第二帐号中确定与第一帐号匹配的目标帐号。

在示例性实施例中，第二服务需求信息还包括服务者特征，可结合服务者特征进行匹配。如图5所示，上述步骤242可由步骤(242A)替换实现。

步骤242A，基于服务者特征与候选第二帐号对应的历史服务信息，从候选第二帐号中确定与第一帐号匹配的目标帐号。

在一种可能的实施方式中，历史服务信息包括帐号使用者特征。可选地，当一些第二帐号的响应时间间隔等级一致时，可将候选第二帐号对应的帐号使用者特征与服务者特征进行对比，得到与服务者特征匹配的帐号使用者特征对应的第二帐号，并作为目标帐号。

在示例性实施例中，历史服务信息包括帐号使用者特征。相应的，如图6所示，上述步骤242A的实施过程包括如下步骤(242A1～242A2)。

步骤242A1，基于服务者特征与候选第二帐号对应的帐号使用者特征，确定使用者特征匹配度。

上述使用者特征匹配度用于表征第一帐号设置的服务者特征与候选第二帐号对应的帐号使用者特征之间的相似度，并且使用者特征匹配度与相似度呈正相关。可选地，若服务者特征与候选第二帐号对应的帐号使用者特征匹配，则将特征匹配度记为1，不匹配则记为0。可选地，使用者特征匹配度也可以是连续的数值，本申请实施例对此不作限定。

步骤242A2，基于使用者特征匹配度，从候选第二帐号中确定目标帐号。

按照使用者特征匹配度，对候选第二帐号进行降序排列。可选地，将降序排列之后的首个候选第二帐号作为上述目标帐号。

在一种可能的实施方式中，上述历史服务信息还包括资源使用数据和请求处理数据。上述资源使用数据是指第二帐号对应的资源信息被第一帐号指向的用户使用所产生的数据。上述请求处理数据是指第二帐号处理请求的数据，例如处理请求的数量。

相应的，如图7所示，上述步骤242A2可由如下步骤(242A3～242A6)替换实施。

步骤242A3，基于资源使用数据，确定候选第二帐号对应的资源稳定度。

资源使用数据包括上述第二帐号对应的帐号资源被其他帐号使用的使用时间，上述使用时间与上述资源稳定度之间呈正相关，使用时间越长，上述资源稳定度越高。在具体的应用场景中，上述第二帐号中的帐号资源为招聘信息对应的工作资源，第一帐号对应的用户接收第二帐号提供的工作资源，从事上述工作对应的工作的时间可理解为上述使用时间，可按照一定的映射关系，确定上述资源稳定度，本申请实施例对此不作限定。

在一个示例中，上述资源稳定度通过具体的资源使用数据确定，例如资源稳定度为经纪人擅长企业稳定度系数，高于或等于平均数将资源稳定度记为1，否则记为0.5。资源稳定度还可以是经纪人擅长工种类型/企业类型(与请求资源类型一致为1，不一致为0)”或“经纪人服务用户薪资水平(高于或等于平均数为1，低于平均数为0.5)”，本申请实施例对此不作限定。

步骤242A4，基于请求处理数据，确定候选第二帐号对应的请求处理指标。

请求处理指标用于表征候选第二帐号对应的请求处理量。

可选地，上述请求处理数据包括第二帐号处理资源配置请求的请求处理量。可选地，上述请求处理量与上述请求处理指标呈正相关，上述请求处理量越多，说明第二帐号的处理压力越大，请求处理指标越高，帐号空闲度越低。因此，可通过请求处理数据确定候选第二帐号对应的请求处理指标。

上述请求处理指标可以是第二帐号今日已分配需求数系数，若第二帐号今日已分配信息服务请求的数量高于或等于平均数则将请求处理指标记为0.5，否则记为1。

步骤242A5，基于预设的第一权重、第二权重和第三权重，对使用者特征匹配度、资源稳定度以及请求处理指标进行加权求和，得到候选第二帐号对应的服务行为分。

预设的第一权重、第二权重和第三权重，分别对应于使用者特征匹配度、资源稳定度以及请求处理指标的权重。可选地，预设的第一权重、第二权重和第三权重的总和为1。

可选地，预设的第一权重、第二权重和第三权重分别为0.3、0.3、0.4。上述服务行为分等于使用者特征匹配度*0.3+资源稳定度*0.3+请求处理指标*0.4。

步骤242A6，根据服务行为分，从候选第二帐号中确定目标帐号。

将服务行为分高的第二帐号进行优先分配；若出现多个服务行为分相同的第二帐号，则优先分配给接入***时间较晚或处理的信息服务请求较少的第二帐号，若依旧存在相同的则平均分配。

步骤250，向目标帐号对应的客户端发送信息服务请求，以获取与信息服务请求对应的反馈信息。

在一种可能的实施方式中，将上述信息服务请求对应的服务需求信息以需求列表的形式发送至目标帐号。上述需求列表是指用户在***中操作后产生的信息，通过列表的方式推送至目标帐号对应的客户端。可选地，上述目标帐号为经纪人所持有的电子帐号，通过将带有用户需求的需求列表推送至目标帐号对应的客户端，以提醒对应的经纪人处理相关任务，生成相应的反馈信息。

可选地，建立目标帐号对应的客户端与第一帐号对应的客户端之间的通信连接，以使目标帐号对应的客户端发送反馈信息至第一帐号对应的客户端，例如招聘信息。

综上所述，本申请实施例提供的技术方案，通过对接收到的第一帐号的信息服务请求进行解析，得到其中携带的第一服务需求信息和第二服务需求信息，通过筛选服务位置与第一服务需求信息中的目标位置信息相匹配的第二帐号，得到第二帐号集合并从中找到历史服务信息与第二服务需求信息匹配的目标帐号，最终将该服务请求分配给目标帐号进而获得相应的反馈信息，能够充分结合服务请求中的需求信息以及第二帐号的服务信息，为第一帐号分配位置匹配且服务质量较好的第二帐号进行服务，提升服务请求处理的质量和速度，综合提升了请求处理效率。

请参考图8，其示出了本申请一个实施例提供的请求处理方法的流程图。该方法可应用于计算机设备中，所述计算机设备是指具备数据计算和处理能力的电子设备，如各步骤的执行主体可以是图1所示的应用程序运行环境中的服务器20。该方法可以包括以下几个步骤(801～809)。

步骤801，接收第一帐号的信息服务请求。

信息服务请求包括第一服务需求信息和第二服务需求信息，第一服务需求信息包括目标位置信息。

步骤802，获取与目标位置信息匹配的第二帐号集合。

步骤803，获取各个第二帐号对应的历史服务信息。

步骤804，获取各个第二帐号对应的资源信息。

上述资源信息可以是为第一帐号提供服务所需的资源信息，也可以是第一帐号请求的资源信息。可选地，上述资源信息包括招聘资源信息。在一些实施例中，各个第二帐号可以有不同的资源信息，也可以有相同的资源信息。

步骤805，确定与资源需求信息匹配的目标资源信息。

上述目标资源信息是与资源需求信息匹配的资源信息。例如，某一个招聘资源信息中工作类型、薪资与资源需求信息均吻合，则可将该招聘资源信息确定为目标资源信息。

步骤806，将与目标资源信息对应的至少一个第二帐号确定为候选第二帐号。

将对目标资源信息有调用权限的至少一个第二帐号确定为候选第二帐号。

步骤807，基于第二服务需求信息和候选第二帐号对应的历史服务信息，从候选第二帐号中确定与第一帐号匹配的目标帐号。

可选地，上述步骤240的实施过程包括步骤(804～807)。

在一种可能的实施方式中，上述资源需求信息包括资源获取时限信息和请求资源类型信息。相应的，如图9所示，上述步骤805可由如下步骤805a替换实现。

步骤805a，确定与资源获取时限信息和请求资源类型信息均匹配的目标资源信息。

对于上述资源获取时限信息和请求资源类型信息的解释在上文实施例中已经进行过相应解释，这里不再赘述。

上述步骤805a中，目标资源信息需要同时满足资源获取时限信息和请求资源类型信息的要求。

相应的，如图9所示，上述步骤806之前，还可包括如下步骤809。

步骤809，确定各个第二帐号对应的响应时间数据。

相应的，如图9所示，上述步骤806可由如下步骤806a替换实现。

步骤806a，将响应时间数据符合预设响应时间条件且与目标资源信息对应的至少一个第二帐号，确定为候选第二帐号。

步骤808，向目标帐号对应的客户端发送信息服务请求，以获取与信息服务请求对应的反馈信息。

综上所述，本申请实施例提供的技术方案，通过对接收到的第一帐号的信息服务请求进行解析，得到其中携带的第一服务需求信息和第二服务需求信息，通过筛选服务位置与第一服务需求信息中的目标位置信息相匹配的第二帐号，得到第二帐号集合并从中找到历史服务信息与第二服务需求信息匹配的目标帐号，最终将该服务请求分配给目标帐号进而获得相应的反馈信息，能够充分结合服务请求中的需求信息以及第二帐号的服务信息，为第一帐号分配位置匹配且服务质量较好的第二帐号进行服务，提升服务请求处理的质量和速度，综合提升了请求处理效率。

下述为本申请装置实施例，可用于执行本申请方法实施例。对于本申请装置实施例中未披露的细节，请参照本申请方法实施例。

请参考图10，其示出了本申请一个实施例提供的请求处理装置的框图。该装置具有实现上述请求处理方法的功能，所述功能可以由硬件实现，也可以由硬件执行相应的软件实现。该装置可以是计算机设备，也可以设置在计算机设备中。该装置1000可以包括：请求接收模块1010、帐号获取模块1020、历史信息获取模块1030、目标帐号确定模块1040、请求分配模块1050。

请求接收模块1010，用于接收第一帐号的信息服务请求，所述信息服务请求包括第一服务需求信息和第二服务需求信息，所述第一服务需求信息包括目标位置信息；

帐号获取模块1020，用于获取与所述目标位置信息匹配的第二帐号集合，所述第二帐号集合中各个第二帐号对应的服务位置与所述目标位置信息指示的目标位置相对应；

历史信息获取模块1030，用于获取所述各个第二帐号对应的历史服务信息；

目标帐号确定模块1040，用于根据所述历史服务信息和所述第二服务需求信息，从所述第二帐号集合中确定与所述第一帐号匹配的目标帐号，所述目标帐号对应的历史服务信息与所述第二服务需求信息相匹配；

请求分配模块1050，用于向所述目标帐号对应的客户端发送所述信息服务请求，以获取与所述信息服务请求对应的反馈信息。

在示例性实施例中，所述第二服务需求信息包括资源需求信息，所述目标帐号确定模块1040，包括：

资源获取单元，用于获取所述各个第二帐号对应的资源信息；

资源确定单元，用于确定与所述资源需求信息匹配的目标资源信息；

候选帐号确定单元，用于将与所述目标资源信息对应的至少一个第二帐号确定为候选第二帐号；

目标帐号确定单元，用于基于所述第二服务需求信息和所述候选第二帐号对应的历史服务信息，从所述候选第二帐号中确定与所述第一帐号匹配的目标帐号。

在示例性实施例中，所述资源需求信息包括资源获取时限信息和请求资源类型信息，所述资源确定单元，还用于：

确定与所述资源获取时限信息和所述请求资源类型信息均匹配的目标资源信息；

所述历史信息获取模块1030，包括：

确定所述各个第二帐号对应的响应时间数据；

所述候选帐号确定单元，用于：

将响应时间数据符合预设响应时间条件且与所述目标资源信息对应的至少一个第二帐号，确定为所述候选第二帐号。

在示例性实施例中，所述历史服务信息包括响应行为信息，所述候选帐号确定单元还用于：

将所述第二帐号集合中所述响应行为信息符合响应行为条件的第二帐号确定为候选第二帐号；

所述目标帐号确定单元，还用于基于所述第二服务需求信息和所述候选第二帐号对应的历史服务信息，从所述候选第二帐号中确定与所述第一帐号匹配的目标帐号。

在示例性实施例中，所述第二服务需求信息还包括服务者特征，所述目标帐号确定单元，具体用于：

基于所述服务者特征与所述候选第二帐号对应的历史服务信息，从所述候选第二帐号中确定与所述第一帐号匹配的目标帐号。

在示例性实施例中，所述历史服务信息包括帐号使用者特征，所述目标帐号确定单元，包括：特征匹配子单元以及目标帐号确定子单元。

特征匹配子单元，用于基于所述服务者特征与所述候选第二帐号对应的帐号使用者特征，确定使用者特征匹配度；

目标帐号确定子单元，用于基于所述使用者特征匹配度，从所述候选第二帐号中确定所述目标帐号。

在示例性实施例中，所述历史服务信息还包括资源使用数据和请求处理数据，所述目标帐号确定单元，还包括：稳定度确定子单元、请求处理指标确定子单元以及服务行为分计算子单元。

稳定度确定子单元，用于基于所述资源使用数据，确定所述候选第二帐号对应的资源稳定度；

请求处理指标确定子单元，用于基于所述请求处理数据，确定所述候选第二帐号对应的请求处理指标，所述请求处理指标用于表征所述候选第二帐号对应的请求处理量；

服务行为分计算子单元，用于基于预设的第一权重、第二权重和第三权重，对所述使用者特征匹配度、所述资源稳定度以及所述请求处理指标进行加权求和，得到所述候选第二帐号对应的服务行为分；

所述目标帐号确定子单元，还用于根据所述服务行为分，从所述候选第二帐号中确定所述目标帐号。

在示例性实施例中，所述历史服务信息包括帐号使用者特征，所述历史信息获取模块1030，包括：使用者信息获取单元、使用者特征确定单元。

使用者信息获取单元，用于获取所述各个第二帐号对应的帐号使用者信息，所述帐号使用者信息包括性格标签、消息语料和操作行为日志中的至少一种。

使用者特征确定单元，用于基于所述帐号使用者信息，确定所述各个第二帐号对应的帐号使用者特征。

在示例性实施例中，所述帐号获取模块1020，包括：区域确定单元和区域帐号确定单元。

区域确定单元，用于确定与所述目标位置信息对应的目标服务区域。

区域帐号确定单元，用于若所述目标服务区域内存在至少一个服务位置，则基于所述至少一个服务位置，生成所述第二帐号集合。

在示例性实施例中，所述目标服务区域为所述第一帐号的当前登录位置的所在区域，所述区域帐号确定单元，包括：服务位置确定子单元和服务帐号确定子单元。

服务位置确定子单元，用于若所述目标服务区域内存在至少一个服务位置，则从所述至少一个服务位置中，确定与所述当前登录位置对应的目标服务位置。

服务帐号确定子单元，用于将所述目标服务位置对应的至少一个第二帐号作为所述第二帐号集合。

综上所述，本申请实施例提供的技术方案，通过对接收到的第一帐号的信息服务请求进行解析，得到其中携带的第一服务需求信息和第二服务需求信息，通过筛选服务位置与第一服务需求信息中的目标位置信息相匹配的第二帐号，得到第二帐号集合并从中找到历史服务信息与第二服务需求信息匹配的目标帐号，最终将该服务请求分配给目标帐号进而获得相应的反馈信息，能够充分结合服务请求中的需求信息以及第二帐号的服务信息，为第一帐号分配位置匹配且服务质量较好的第二帐号进行服务，提升服务请求处理的质量和速度，综合提升了请求处理效率。

需要说明的是，上述实施例提供的装置，在实现其功能时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将设备的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的装置与方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。

请参考图11，图11示出了本申请一个实施例提供的计算机设备的结构框图，上述设备包括至少一个处理器，以及与至少一个处理器通信连接的存储器；其中，存储器存储有可被至少一个处理器执行的指令，至少一个处理器通过执行存储器存储的指令实现上述请求处理方法，上述设备可以参与构成或包含本申请实施例所提供的装置或***。

如图11所示，设备100可以包括一个或多个(图中采用102a、102b，……，102n来示出)处理器102(处理器102可以包括但不限于微处理器MCU或可编程逻辑器件FPGA等的处理装置)、用于存储数据的存储器104、以及用于通信功能的传输装置106。除此以外，还可以包括：显示器、输入/输出接口(I/O接口)、通用串行总线(USB)端口(可以作为I/O接口的端口中的一个端口被包括)、网络接口、电源和/或相机。本领域普通技术人员可以理解，图11所示的结构仅为示意，其并不对上述电子装置的结构造成限定。例如，设备100还可包括比图11中所示更多或者更少的组件，或者具有与图11所示不同的配置。

应当注意到的是上述一个或多个处理器102和/或其他数据处理电路在本文中通常可以被称为“数据处理电路”。该数据处理电路可以全部或部分的体现为软件、硬件、固件或其他任意组合。此外，数据处理电路可为单个独立的处理模块，或全部或部分的结合到设备100(或移动设备)中的其他元件中的任意一个内。如本申请实施例中所涉及到的，该数据处理电路作为一种处理器控制(例如与接口连接的可变电阻终端路径的选择)。

存储器104可用于存储应用软件的软件程序以及模块，如本申请实施例中上述的方法对应的程序指令/数据存储装置，处理器102通过运行存储在存储器104内的软件程序以及模块，从而执行各种功能应用以及数据处理，即实现上述的一种语料处理模型训练方法。存储器104可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器104可进一步包括相对于处理器102远程设置的存储器，这些远程存储器可以通过网络连接至设备100。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

传输装置106用于经由一个网络接收或者发送数据。上述的网络具体实例可包括设备100的通信供应商提供的无线网络。在一个实例中，传输装置106包括一个网络适配器(NetworkInterfaceController，NIC)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，传输装置106可以为射频(RadioFrequency，RF)模块，其用于通过无线方式与互联网进行通讯。

显示器可以例如触摸屏式的液晶显示器(LCD)，该液晶显示器可使得用户能够与设备100(或移动设备)的用户界面进行交互。

在示例性实施例中，提供了一种计算机可读存储介质，所述存储介质中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或指令集由处理器加载并执行以实现上述请求处理方法。

应当理解的是，在本文中提及的“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。另外，本文中描述的步骤编号，仅示例性示出了步骤间的一种可能的执行先后顺序，在一些其它实施例中，上述步骤也可以不按照编号顺序来执行，如两个不同编号的步骤同时执行，或者两个不同编号的步骤按照与图示相反的顺序执行，本申请实施例对此不作限定。

以上所述仅为本申请的示例性实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (13)

1.一种请求处理方法，其特征在于，所述方法包括：

接收第一帐号的信息服务请求，所述信息服务请求包括第一服务需求信息和第二服务需求信息，所述第一服务需求信息包括目标位置信息；

获取与所述目标位置信息匹配的第二帐号集合，所述第二帐号集合中各个第二帐号对应的服务位置与所述目标位置信息指示的目标位置相对应；

获取所述各个第二帐号对应的历史服务信息；

根据所述历史服务信息和所述第二服务需求信息，从所述第二帐号集合中确定与所述第一帐号匹配的目标帐号，所述目标帐号对应的历史服务信息与所述第二服务需求信息相匹配；

向所述目标帐号对应的客户端发送所述信息服务请求，以获取与所述信息服务请求对应的反馈信息。

2.根据权利要求1所述的方法，其特征在于，所述第二服务需求信息包括资源需求信息，所述根据所述历史服务信息和所述第二服务需求信息，从所述第二帐号集合中确定与所述第一帐号匹配的目标帐号，包括：

获取所述各个第二帐号对应的资源信息；

确定与所述资源需求信息匹配的目标资源信息；

将与所述目标资源信息对应的至少一个第二帐号确定为候选第二帐号；

基于所述第二服务需求信息和所述候选第二帐号对应的历史服务信息，从所述候选第二帐号中确定与所述第一帐号匹配的目标帐号。

3.根据权利要求2所述的方法，其特征在于，所述资源需求信息包括资源获取时限信息和请求资源类型信息，所述确定与所述资源需求信息匹配的目标资源信息，包括：

确定与所述资源获取时限信息和所述请求资源类型信息均匹配的目标资源信息；

所述将与所述目标资源信息对应的至少一个第二帐号确定为候选第二帐号之前，还包括：

确定所述各个第二帐号对应的响应时间数据；

所述将与所述目标资源信息对应的至少一个第二帐号确定为候选第二帐号，包括：

将响应时间数据符合预设响应时间条件且与所述目标资源信息对应的至少一个第二帐号，确定为所述候选第二帐号。

4.根据权利要求1所述的方法，其特征在于，所述历史服务信息包括响应行为信息，所述根据所述历史服务信息和所述第二服务需求信息，从所述第二帐号集合中确定与所述第一帐号匹配的目标帐号，包括：

将所述第二帐号集合中所述响应行为信息符合响应行为条件的第二帐号确定为候选第二帐号；

基于所述第二服务需求信息和所述候选第二帐号对应的历史服务信息，从所述候选第二帐号中确定与所述第一帐号匹配的目标帐号。

5.根据权利要求2至4任一项所述的方法，其特征在于，所述第二服务需求信息还包括服务者特征，所述基于所述第二服务需求信息和所述候选第二帐号对应的历史服务信息，从所述候选第二帐号中确定与所述第一帐号匹配的目标帐号，包括：

基于所述服务者特征与所述候选第二帐号对应的历史服务信息，从所述候选第二帐号中确定与所述第一帐号匹配的目标帐号。

6.根据权利要求5所述的方法，其特征在于，所述历史服务信息包括帐号使用者特征，所述基于所述服务者特征与所述候选第二帐号对应的历史服务信息，从所述候选第二帐号中确定与所述第一帐号匹配的目标帐号，包括：

基于所述服务者特征与所述候选第二帐号对应的帐号使用者特征，确定使用者特征匹配度；

基于所述使用者特征匹配度，从所述候选第二帐号中确定所述目标帐号。

7.根据权利要求6所述的方法，其特征在于，所述历史服务信息还包括资源使用数据和请求处理数据，所述基于所述服务者特征与所述候选第二帐号对应的历史服务信息，从所述候选第二帐号中确定与所述第一帐号匹配的目标帐号，还包括：

基于所述资源使用数据，确定所述候选第二帐号对应的资源稳定度；

基于所述请求处理数据，确定所述候选第二帐号对应的请求处理指标，所述请求处理指标用于表征所述候选第二帐号对应的请求处理量；

基于预设的第一权重、第二权重和第三权重，对所述使用者特征匹配度、所述资源稳定度以及所述请求处理指标进行加权求和，得到所述候选第二帐号对应的服务行为分；

根据所述服务行为分，从所述候选第二帐号中确定所述目标帐号。

8.根据权利要求5所述的方法，其特征在于，所述历史服务信息包括帐号使用者特征，所述获取所述各个第二帐号对应的历史服务信息，包括：

获取所述各个第二帐号对应的帐号使用者信息，所述帐号使用者信息包括性格标签、消息语料和操作行为日志中的至少一种；

基于所述帐号使用者信息，确定所述各个第二帐号对应的帐号使用者特征。

9.根据权利要求1所述的方法，其特征在于，所述获取与所述目标位置信息匹配的第二帐号集合，包括：

确定与所述目标位置信息对应的目标服务区域；

若所述目标服务区域内存在至少一个服务位置，则基于所述至少一个服务位置，生成所述第二帐号集合。

10.根据权利要求9所述的方法，其特征在于，所述目标服务区域为所述第一帐号的当前登录位置的所在区域，所述若所述目标服务区域内存在至少一个服务位置，则基于所述至少一个服务位置，生成所述第二帐号集合，包括：

若所述目标服务区域内存在至少一个服务位置，则从所述至少一个服务位置中，确定与所述当前登录位置对应的目标服务位置；

将所述目标服务位置对应的至少一个第二帐号作为所述第二帐号集合。

11.一种请求处理装置，其特征在于，所述装置包括：

请求接收模块，用于接收第一帐号的信息服务请求，所述信息服务请求包括第一服务需求信息和第二服务需求信息，所述第一服务需求信息包括目标位置信息；

帐号获取模块，用于获取与所述目标位置信息匹配的第二帐号集合，所述第二帐号集合中各个第二帐号对应的服务位置与所述目标位置信息指示的目标位置相对应；

历史信息获取模块，用于获取所述各个第二帐号对应的历史服务信息；

目标帐号确定模块，用于根据所述历史服务信息和所述第二服务需求信息，从所述第二帐号集合中确定与所述第一帐号匹配的目标帐号，所述目标帐号对应的历史服务信息与所述第二服务需求信息相匹配；

请求分配模块，用于向所述目标帐号对应的客户端发送所述信息服务请求，以获取与所述信息服务请求对应的反馈信息。

12.一种计算机设备，其特征在于，包括处理器和存储器，所述存储器中存储有至少一条指令或至少一段程序，所述至少一条指令或所述至少一段程序由所述处理器加载并执行以实现如权利要求1至10中任一项所述的请求处理方法。

13.一种计算机可读存储介质，所述存储介质中存储有至少一条指令或至少一段程序，所述至少一条指令或所述至少一段程序由处理器加载并执行以实现如权利要求1至10任一项所述的请求处理方法。

Images