用于调配服务资源的方法及装置与流程

文档序号:14555821阅读:112来源:国知局
用于调配服务资源的方法及装置与流程

本申请涉及互联网应用技术领域,特别涉及一种用于调配服务资源的方法及装置。



背景技术:

一般来说,对于一些o2o服务(如呼叫打车、配送外卖等),系统侧进行服务资源的调配、建立服务请求方(以下简称“请求方”)与服务提供方(以下简称“提供方”)之间的服务关系,由提供方向请求方提供服务。实际应用中,某些请求方可能会对提供方有一定的需求,例如,希望提供方尽快到达服务地点,或者希望提供方在某个时间范围内完成服务等等,不同的请求方可能会有不同的需求。当服务关系建立后,如果提供方无法满足请求方的需求,有可能会导致请求方取消服务关系,若请求方取消服务关系不够及时,可能会影响系统侧的服务资源调配效率。



技术实现要素:

为了解决上述技术问题,本申请提供了一种用于调配服务资源的方法及装置。

根据本申请实施例的第一方面,提供一种用于调配服务资源的方法,包括:

在接收到服务请求方发送的服务请求后,向所述服务请求方分配服务提供方;

获取服务提供方当前状态信息;

向所述服务请求方输出所述当前状态信息,并询问所述服务请求方是否选用所述服务提供方。

可选的,所述方法还包括:

在获取到所述当前状态信息之后,判断是否满足询问的条件,如果满足询问的条件,则进一步执行向所述服务请求方输出所述当前状态信息,并询问所述服务请求方是否选用所述服务提供方的步骤。

可选的,所述询问的条件通过以下任意一种方式而获取:

从所述服务请求中,获取由服务请求方自定义的条件;

从预先存储的数据中,获取由服务请求方自定义的条件;或者

从预先存储的数据中,获取默认的预设条件。

可选的,所述方法还包括:

若接收到针对所述询问的应答信息,根据所述应答信息执行相应的操作。

可选的,所述方法还包括:

若在超过预设时限之前未接收到所述应答信息,确定选用所述服务提供方。

可选的,所述服务请求包括:

呼叫打车服务的请求。

可选的,所述当前状态信息包括以下一项或多项:

所述服务提供方当前的位置信息;

所述服务提供方从当前位置到达所述服务请求指定起点的路线;

所述服务提供方从当前位置到达所述服务请求指定起点的路线的路况;

所述服务提供方从当前位置到达所述服务请求指定起点的预估时间。

根据本申请实施例的第二方面,提供一种用于调配服务资源的装置,所述装置包括:

调配单元,被配置为在接收到服务请求方发送的服务请求后,向所述服务请求方分配服务提供方;

获取单元,被配置为获取服务提供方当前状态信息;

输出单元,被配置为向所述服务请求方输出所述当前状态信息,并询问所述服务请求方是否选用所述服务提供方。

可选的,所述装置还包括:

控制单元,被配置为在获取到所述当前状态信息之后,判断是否满足询问的条件,如果满足询问的条件,则进一步控制所述输出单元执行向所述服务请求方输出所述当前状态信息,并询问所述服务请求方是否选用所述服务提供方的步骤。

可选的,所述询问的条件通过以下任意一种方式而获取:

从所述服务请求中,获取由服务请求方自定义的条件;

从预先存储的数据中,获取由服务请求方自定义的条件;或者

从预先存储的数据中,获取默认的预设条件。

可选的,所述装置还包括:

执行单元,被配置为在接收到针对所述询问的应答信息时,根据所述应答信息执行相应的操作。

可选的,所述装置还包括:

确定单元,被配置为当在超过预设时限之前未接收到所述应答信息时,确定选用所述服务提供方。

可选的,所述服务请求包括:

呼叫打车服务的请求。

可选的,所述当前状态信息包括以下一项或多项:

所述服务提供方当前的位置信息;

所述服务提供方从当前位置到达所述服务请求指定起点的路线;

所述服务提供方从当前位置到达所述服务请求指定起点的路线的路况;

所述服务提供方从当前位置到达所述服务请求指定起点的预估时间。

根据本申请实施例的第三方面,提供一种计算机存储介质,所述存储介质中存储有程序指令,所述指令包括:

在接收到服务请求方发送的服务请求后,向所述服务请求方分配服务提供方;

获取服务提供方当前状态信息;

向所述服务请求方输出所述当前状态信息,并询问所述服务请求方是否选用所述服务提供方。

本申请的实施例提供的技术方案可以包括以下有益效果:

本申请的实施例提供的用于调配服务资源的方法和装置,在接收到服务请求方发送的服务请求后,向服务请求方分配服务提供方,获取服务提供方当前状态信息,向服务请求方输出该当前状态信息,并询问服务请求方是否选用该服务提供方。从而在服务提供方无法满足服务请求方的需求时,使服务请求方能够及时取消服务关系,提高了系统侧的服务资源调配效率。

应当理解的是,以上的一般描述和后文的细节描述仅是示例性和解释性的,并不能限制本申请。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分,示出了符合本申请的实施例,并与说明书一起用于解释本申请的原理。

图1是本申请根据一示例性实施例示出的一种用于调配服务资源的场景示意图;

图2是本申请根据一示例性实施例示出的一种用于调配服务资源的方法的流程图;

图3是本申请根据一示例性实施例示出的另一种用于调配服务资源的场景示意图;

图4是本申请根据一示例性实施例示出的另一种用于调配服务资源的方法的流程图;

图5是本申请根据一示例性实施例示出的一种用于调配服务资源的装置框图。

具体实施方式

这里将详细地对示例性实施例进行说明,其示例表示在附图中。下面的描述涉及附图时,除非另有表示,不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反,它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请使用的术语是仅仅出于描述特定实施例的目的,而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式,除非上下文清楚地表示其他含义。还应当理解,本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解,尽管在本申请可能采用术语第一、第二、第三等来描述各种信息,但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如,在不脱离本申请范围的情况下,第一信息也可以被称为第二信息,类似地,第二信息也可以被称为第一信息。取决于语境,如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

如图1所示,是根据一示例性实施例示出的一种用于调配服务资源的场景示意图:在图1示出的场景中,终端设备101为服务请求方(简称“请求方”)的移动终端,终端设备102为服务提供方(简称“提供方”)的移动终端。终端设备101可以通过网络向服务端103发送服务请求,服务端103根据该服务请求进行服务资源的调配,例如,可以将终端设备102对应的提供方与终端设备101对应的请求方建立服务关系。同时,服务端103还可以获取提供方当前状态信息,并向终端设备101对应的请求方输出该当前状态信息,并询问是否选用该提供方。请求方可以根据该当前状态信息选择终止选用提供方,并由终端设备101向服务端103发送取消服务关系的应答信息,服务端103根据该应答信息,取消终端设备102对应的提供方与终端设备101对应的请求方之间的服务关系。

下面结合具体实施例对本申请进行详细说明。

如图2所示,图2是根据一示例性实施例示出的一种用于调配服务资源的方法的流程图,该方法可以应用于服务端中。在本实施例中,为了便于理解,结合能够安装应用程序的终端设备来举例说明。本领域技术人员可以理解,该终端设备可以包括但不限于诸如智能手机的移动终端设备、智能穿戴式设备、平板电脑、个人数字助理等等。该方法包括以下步骤:

在步骤201中,在接收到服务请求方发送的服务请求后,向服务请求方分配服务提供方。

在本实施例中,所涉及的服务可以是一些o2o服务,如呼叫打车的服务,或者配送外卖的服务等,本申请对涉及的服务的具体形式或类型方面不限定。因此,服务请求可以包括呼叫打车服务的请求,也可以包括呼叫外卖的请求。服务请求方可以是请求获取服务的用户,例如,在呼叫打车的服务中,服务请求方可以是乘车的乘客,在配送外卖的服务中,服务请求方可以是点外卖的顾客。服务提供方可以是提供服务的用户,例如,在呼叫打车的服务中,服务提供方可以是提供乘车服务的司机,在配送外卖的服务中,服务提供方可以是配送外卖的配送员。

在本实施例中,服务请求可以是一种订单形式的请求,例如,服务请求可以是打车的订单,或者叫外卖的订单等。订单中可以包括请求服务的具体信息,例如,订单中可以包括服务的起点和终点,服务的附加要求等等。当服务端接收到服务请求方发送的服务请求后,会进行服务资源的调配,以向该服务请求方分配服务提供方,从而使该服务提供方向服务请求方提供相应的服务。

例如,在呼叫打车的服务中,当服务端接收到乘客方发送的打车订单后,会将该订单分配给司机方,使该司机方向上述乘客方提供相应的乘车服务。又例如,在配送外卖的服务中,当服务端接收到订购外卖的顾客发送的外卖订单后,会将该订单分配给配送员,使该配送员为上述顾客提供配送外卖的服务。

在步骤202中,获取服务提供方当前状态信息。

在本实施例中,服务端可以获取服务提供方当前状态信息,该当前状态信息能够反映服务提供方当前的状态。例如,在呼叫打车的服务中,该当前状态信息可以包括以下一项或多项:司机当前的位置信息;司机从当前位置到达订单指定起点的路线;司机从当前位置到达订单指定起点的路线的路况;司机从当前位置到达订单指定起点的预估时间,等等。该当前状态信息还可以包括司机的性别,年龄范围,历史评分等等信息。可以理解,该当前状态信息可以是任意能够反映服务提供方当前状态的信息,本申请对此方面不限定。

在本实施例中,可以通过实时获取司机当前的定位信息,从而获取司机的位置信息。可以通过司机当前的位置信息以及订单指定起点的位置信息,结合地图中的道路信息,确定到达订单指定起点的路线,该路线可以有一条或多条,并可以根据实时获取的司机的位置信息,调整更换该路线。还可以从地图中获取司机到达订单指定起点的路线的路况信息,并且,可以根据当前路况信息、司机的车速以及具体路线等,估测司机到达订单指定起点的预估时间。可以理解,本领域中已知的以及将来可能出现的任何其他估测司机到达订单指定起点的预估时间的方法都可以应用于本公开,本公开对其具体的估测方式不限定。

又例如,在配送外卖的服务中,该当前状态信息可以包括以下一项或多项:配送员当前的位置信息;配送员从当前位置到达订单指定商铺的路线;配送员从当前位置到达订单指定配送员的路线的路况;配送员从当前位置到达订单指定商铺的预估时间;从订单指定商铺到送货地点的路线;从订单指定商铺到送货地点的路线的路况;从订单指定商铺到送货地点的预估时间,等等。在配送外卖的服务中,当前状态信息的获取方式可以参照呼叫打车服务的例子中当前状态信息的获取方式,在此不再赘述。

在步骤203中,向上述服务请求方输出该当前状态信息,并询问服务请求方是否选用上述服务提供方。

在本实施例中,如图3所示,界面301为信息输出界面,该界面中显示有上述当前状态信息,服务请求方用户可以参照输出的上述当前状态信息决定是否选用上述服务提供方。如果不选用该服务提供方,则可以点击相应的按钮,以向服务端请求解除服务关系。

在本实施例中,若接收到针对该询问的应答信息,根据该应答信息执行相应的操作。例如,如果该询问的应答信息指示选用该服务提供方,则可以继续执行和该服务提供方提供的服务相关的操作。如果该询问的应答信息指示不选用该服务提供方,则可以执行取消上述服务请求方与服务提供方的服务关系的操作,或者,也可以在取消上述服务关系之后,重新为上述服务请求方分配新的服务资源。

对于本实施例,一种具体的应用场景可以为,用户使用打车软件打车,生成相应的订单。订单发出后,服务端为用户分配司机a,由司机a去该订单的指定接驾地点接驾。并且,服务端可以获取司机a当前的位置信息,到达该接驾地点的路线,该路线的路况以及司机a到达接驾地点的预估时间等信息。服务端可以将这些获取到的信息发给用户,并询问用户是否继续选用司机a。如果用户觉得司机a不能在理想的时间段内到达接驾地点,则可以回复一个拒绝继续服务的应答信息,服务端接收到该应答信息后,可以取消该订单。

本实施例并不限于上述的应用场景,还可以应用到其他场景中。本申请的上述实施例提供的用于调配服务资源的方法,在接收到服务请求方发送的服务请求后,向服务请求方分配服务提供方,获取服务提供方当前状态信息,向服务请求方输出该当前状态信息,并询问服务请求方是否选用该服务提供方。从而在服务提供方无法满足服务请求方的需求时,使服务请求方能够及时取消服务关系,提高了系统侧的服务资源调配效率。

图4是根据一示例性实施例示出的另一种用于调配服务资源的方法的流程图,该实施例详细描述了判断是否满足询问的条件的过程,该方法可以应用于服务端中。该方法可以包括以下步骤:

在步骤401中,在接收到服务请求方发送的服务请求后,向服务请求方分配服务提供方。

在步骤402中,获取服务提供方当前状态信息。

在步骤403中,判断是否满足询问的条件。

在步骤404中,如果满足询问的条件,向上述服务请求方输出所述当前状态信息,并询问上述服务请求方是否选用该服务提供方。

在本实施例的一种实现方式中,可以向服务请求方提供一个自定义条件输入接口,服务请求方可以通过该接口输入自定义条件。这些自定义的条件包含在服务请求中,被发送给服务端。服务端可以从服务请求中获取由服务请求方自定义的条件,作为询问的条件。例如,在呼叫打车的服务中,乘客在输入行程信息时,还可以通过自定义条件输入接口输入一些自定义条件,如,希望司机到达接驾地点的时间范围等。

在本实施例的另一种实现方式中,可以预先向服务请求方提供一个自定义条件设置界面,服务请求方可以通过该设置界面设置自定义条件。并将这些自定义的条件上传给服务端,以和服务请求方的标识信息(如账号等)存储在服务端中。服务端可以从预先存储的数据中,获取由服务请求方自定义的条件,作为询问的条件。例如,在呼叫打车的服务中,乘客可以在个人设置中打开自定义条件设置界面,通过该设置界面设置一些自定义条件,如,能够接受的等待接驾的时间长度范围等。

在本实施例的又一种实现方式中,还可以预先设定一个或多个默认的条件,将该条件存储在服务端中。服务端可以从预先存储的数据中,获取默认的预设条件,作为询问的条件。例如,在呼叫打车的服务中,可以预先设定乘客能够接受的等待接驾的时间长度范围,作为默认条件,并存储在服务端中。

可以理解,还可以通过其它任意合理的方式获取询问的条件,本申请对此方面不限定。

在本实施例中,可以根据能够反映服务提供方当前状态信息,判断是否满足询问的条件。例如,可以直接根据当前状态信息,判断是否满足询问的条件,也可以根据当前的状态信息进行预估,获取预估结果后,根据预估结果判断是否满足询问的条件。

例如,在呼叫打车的服务中,如果询问的条件为司机的平均历史评分在4.5星以上,当前的状态信息包括司机的平均历史评分,因此,可以直接根据状态信息判断是否满足询问的条件。如果询问的条件为能够接受的等待接驾的时间长度范围为0~5分钟,因此,可以根据状态信息预估司机到达接驾地点的时间作为预估结果,根据该预估结果判断是否满足询问的条件。

在步骤405中,若接收到针对该询问的应答信息,根据该应答信息执行相应的操作。

在步骤406中,若在超过预设时限之前未接收到上述应答信息,确定选用该服务提供方。

在本实施例中,如果在超过预设时限之前未接收到应答信息,则确定选用该服务提供方。其中,预设时限可以系统默认的时限,也可以是用户预先设置的时限,并且,该预设时限可以是任意合理的时间长度,本申请对预设时限的具体设置以及具体时间长度方面不限定。

需要说明的是,对于与图4实施例中相同的步骤,在上述图2实施例中不再进行赘述,相关内容可参见图2实施例。

本申请的上述实施例提供的用于调配服务资源的方法,在接收到服务请求方发送的服务请求后,向服务请求方分配服务提供方,获取服务提供方当前状态信息,并判断是否满足询问的条件。如果满足询问的条件,向服务请求方输出上述当前状态信息,并询问服务请求方是否选用上述服务提供方,若接收到针对该询问的应答信息,根据该应答信息执行相应的操作。若在超过预设时限之前未接收到上述应答信息,确定选用该服务提供方。从而进一步在服务提供方无法满足服务请求方的需求时,使服务请求方能够及时取消服务关系,有助于提高了系统侧的服务资源调配效率。

应当注意,尽管在附图中以特定顺序描述了本申请方法的操作,但是,这并非要求或者暗示必须按照该特定顺序来执行这些操作,或是必须执行全部所示的操作才能实现期望的结果。相反,流程图中描绘的步骤可以改变执行顺序。附加地或备选地,可以省略某些步骤,将多个步骤合并为一个步骤执行,和/或将一个步骤分解为多个步骤执行。

与前述用于调配服务资源的方法实施例相对应,本申请还提供了用于调配服务资源的装置的实施例。

如图5所示,图5是本申请根据一示例性实施例示出的一种用于调配服务资源的装置框图,该装置可以包括:调配单元501,获取单元502,输出单元503以及执行单元504。

其中,调配单元501,被配置为在接收到服务请求方发送的服务请求后,向服务请求方分配服务提供方。

获取单元502,被配置为获取服务提供方当前状态信息。

输出单元503,被配置为向服务请求方输出上述当前状态信息,并询问服务请求方是否选用该服务提供方。

在另一些可选实施方式中,该装置还可以包括:控制单元(图5中未示出)。

其中,控制单元,被配置为在获取到当前状态信息之后,判断是否满足询问的条件,如果满足询问的条件,则进一步控制输出单元503执行向服务请求方输出上述当前状态信息,并询问该服务请求方是否选用上述服务提供方的步骤。

在另一些可选实施方式中,询问的条件可以通过以下任意一种方式而获取:

从服务请求中,获取由服务请求方自定义的条件;

从预先存储的数据中,获取由服务请求方自定义的条件;或者

从预先存储的数据中,获取默认的预设条件。

在另一些可选实施方式中,该装置还可以包括:执行单元(图5中未示出)。

其中,执行单元,被配置为在接收到针对该询问的应答信息时,根据该应答信息执行相应的操作。

在另一些可选实施方式中,该装置还可以包括:确定单元(图5中未示出)。

其中,确定单元,被配置为当在超过预设时限之前未接收到应答信息时,确定选用服务提供方。

在另一些可选实施方式中,服务请求可以包括:呼叫打车服务的请求。

在另一些可选实施方式中,当前状态信息可以包括以下一项或多项:服务提供方当前的位置信息;服务提供方从当前位置到达服务请求指定起点的路线;服务提供方从当前位置到达服务请求指定起点的路线的路况;服务提供方从当前位置到达服务请求指定起点的预估时间。

对于装置实施例而言,由于其基本对应于方法实施例,所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的,其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下,即可以理解并实施。

应当理解,上述装置可以预先设置在服务端中,也可以通过下载等方式而加载到服务端中。上述装置中的相应单元可以与服务端中的单元相互配合以实现用于调配服务资源的方案。

本申请实施例可采用在一个或多个其中包含有程序代码的存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。

相应的,本申请实施例还提供一种计算机存储介质,该存储介质中存储有程序指令,该指令包括:

在接收到服务请求方发送的服务请求后,向所述服务请求方分配服务提供方;

获取服务提供方当前状态信息;

向所述服务请求方输出所述当前状态信息,并询问所述服务请求方是否选用所述服务提供方。

描述于本申请实施例中所涉及到的单元模块可以通过软件的方式实现,也可以通过硬件的方式来实现。所描述的单元模块也可以设置在处理器中,例如,可以描述为:一种处理器包括调配单元,获取单元,输出单元以及执行单元。其中,这些单元模块的名称在某种情况下并不构成对该单元模块本身的限定,例如,获取单元还可以被描述为“用于获取服务提供方当前状态信息的单元”。

作为另一方面,本申请还提供了一种计算机可读存储介质,该计算机可读存储介质可以是上述实施例中所述装置中所包含的计算机可读存储介质;也可以是单独存在,未装配入终端或服务器中的计算机可读存储介质。该计算机可读存储介质存储有一个或者一个以上程序,该程序被一个或者一个以上的处理器用来执行描述于本申请的用于调配服务资源的方法。

计算机可用存储介质包括永久性和非永久性、可移动和非可移动媒体,可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括但不限于:相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带,磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。

本领域技术人员在考虑说明书及实践这里公开的发明后,将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化,这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的,本申请的真正范围和精神由下面的权利要求指出。

应当理解的是,本申请并不局限于上面已经描述并在附图中示出的精确结构,并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求来限制。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1