CN109740843A - 用车匹配方法、装置及设备 - Google Patents
用车匹配方法、装置及设备 Download PDFInfo
- Publication number
- CN109740843A CN109740843A CN201811434989.1A CN201811434989A CN109740843A CN 109740843 A CN109740843 A CN 109740843A CN 201811434989 A CN201811434989 A CN 201811434989A CN 109740843 A CN109740843 A CN 109740843A
- Authority
- CN
- China
- Prior art keywords
- driver
- information
- user
- sub
- service
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Landscapes
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
本申请实施例提供一种用车匹配方法、装置及设备。该方法通过获取用户的用车需求信息并发送所述用车需求信息至至少一个司机端。获取所述至少一个司机端各自发送的司机服务信息；其中，每个司机端发送的司机服务信息由其对应司机基于所述用车需求信息提供的。根据所述用车需求信息分别与所述至少一个司机的司机服务信息的第一匹配程度，确定满足匹配要求的至少一个中标司机。基于所述用车需求信息及所述至少一个中标司机各自对应的司机服务信息，针对每一个中标司机生成相应的用车订单。本申请用于提高企业用户用车需求匹配效率，降低企业用车成本。
Description
技术领域
本发明属于互联网技术领域，具体地说，涉及一种用车匹配方法、一种用车匹配装置及一种用车匹配设备。
背景技术
现有技术中，企业存在用车需求时，会发起企业用车招标。然后物流公司根据企业的招标需求参与投标，企业需要通过长时间的审查和筛选确定与用车需求匹配的物流公司，完成招投标。
但上述过程需要耗费企业大量人力和时间成本，用车需求匹配效率相对较低。
发明内容
有鉴于此，本发明提供了一种用车匹配方法、装置及设备，用于提高企业用户用车需求匹配效率，降低企业用车成本。
为了解决上述技术问题，本发明提供了一种用车匹配方法，包括：
获取用户的用车需求信息；
发送所述用车需求信息至至少一个司机端；
获取所述至少一个司机端各自发送的司机服务信息；其中，每个司机端发送的司机服务信息由其对应司机基于所述用车需求信息提供的；
根据所述用车需求信息分别与所述至少一个司机的司机服务信息的第一匹配程度，确定满足匹配要求的至少一个中标司机；
基于所述用车需求信息及所述至少一个中标司机各自对应的司机服务信息，针对每一个中标司机生成相应的用车订单。
优选地，所述根据所述用车需求信息分别与所述至少一个司机的司机服务信息的第一匹配程度，确定满足匹配要求的至少一个中标司机包括：
确定所述用车需求信息分别与所述至少一个司机的司机服务信息的第一匹配程度；
基于所述第一匹配程度，确定所述用车需求信息分别与所述至少一个司机的第二匹配程度；
根据所述用车需求信息分别与所述至少一个司机各自对应的第二匹配程度，确定所述至少一个司机中满足中标阈值的至少一个中标司机。
优选地，所述用车需求信息包括分别对应至少一个运力参数的用车需求子信息；
所述司机服务信息包括分别对应所述至少一个运力参数的司机服务子信息；
所述确定所述用车需求信息分别与所述至少一个司机的司机服务信息的第一匹配程度包括：
针对每一个司机，分别确定对应同一个运力参数的所述用车需求子信息与所述司机服务子信息的第一匹配程度。
优选地，所述基于所述第一匹配程度，确定所述用车需求信息分别与所述至少一个司机的第二匹配程度包括：
确定每一个运力参数的权重值；
针对每一个司机，基于每一个运力参数各自对应的第一匹配程度及权重值，计算所述用车需求信息分别与所述每一个司机的第二匹配程度。
优选地，所述至少一个运力参数包括服务天数、价格情况、运输情况、搬运情况及服务时长；
对应所述服务天数的用车需求子信息包括用车天数及对应所述服务天数的司机服务子信息包括供车天数；
对应所述价格情况的用车需求子信息包括用户接计价及对应所述价格情况的司机服务子信息包括服务价格；
对应所述运输情况的用车需求子信息包括运输里程及对应所述运输情况的司机服务子信息包括最远服务里程；
对应所述搬运情况的用车需求子信息包括需要搬运程度及对应所述搬运情况的司机服务子信息包括可提供搬运程度；
对应所述服务时长的用车需求子信息包括单次运输所需时长及对应所述服务时长的司机服务子信息包括单次运输最大服务时长。
优选地，所述针对每一个司机，分别确定对应同一个运力参数的所述用车需求子信息与所述司机服务子信息的第一匹配程度包括：
针对每一个司机，确定对应所述服务天数的所述用车天数与所述供车天数的第一匹配程度；
确定对应所述价格情况的所述用户计价与所述服务价格的第一匹配程度；
确定对应所述运输情况的所述运输路程与所述最远服务路程的第一匹配程度；
确定对应所述搬运情况的所述需要搬运程度与所述可提供搬运程度的第一匹配程度；
确定对应所述服务时长的所述单次运输所需时长与所述单次运输最大服务时长的第一匹配程度。
优选地，所述针对每一个司机，基于每一个运力参数各自对应的第一匹配程度及权重值，计算所述用车需求信息分别与所述每一个司机的第二匹配程度包括：
针对所述每一个司机，分别计算每一个运力参数各自对应的第一匹配程度与权重值的乘积，计算获得每一个运力参数分别对应的子匹配值；
针对所述每一个司机，将所述每一个运力参数分别对应的子匹配值求和，分别获得所述每一个司机对应的第二匹配程度。
优选地，还包括：
分别获取用户的用户属性信息及所述至少一个司机端的司机属性信息。
优选地，根据所述用车需求信息分别与所述至少一个司机的司机服务信息的第一匹配程度，确定满足匹配要求的至少一个中标司机包括：
根据所述用车需求信息分别与所述至少一个司机的司机服务信息的第一匹配程度及所述司机属性信息与所述用户属性信息的第三匹配程度，确定满足匹配要求的至少一个中标司机。
优选地，所述用车需求信息包括用户计价子信息；
所述发送所述用车需求信息至至少一个司机端包括：
确定所述用户计价子信息对应的计价模式；
按照所述计价模式发送所述用户计价子信息至所述至少一个司机端，其中，所述用户计价模式包括司机报价、用户一口价、用户按票计价、按重量计价、按件计价。
优选地，所述司机服务信息包括服务价格子信息；
所述获取所述至少一个司机端各自发送的司机服务信息包括：
获取所述至少一个司机端各自发送的服务价格子信息；其中，所述每个司机端发送的服务价格子信息由其对应司机基于所述用户计价模式及所述用户计价子信息提供的。
优选地，所述用户计价模式为司机报价；所述用户计价子信息为所述用户提供的最低报价信息；
至少一个司机端各自发送的服务价格子信息具体按照以下步骤生成：
所述每个司机在各自的司机端基于所述用户的最低报价信息提供相应的司机报价信息；
根据预设抽佣比例、溢价比例及所述司机报价信息，生成所述每个司机端各自对应的服务价格子信息。
优选地，所述用户计价模式为用户一口价；所述用户计价子信息为所述用户提供的用户一口价信息；
至少一个司机端各自发送的服务价格子信息具体按照以下步骤生成：
根据预设抽佣比例、溢价比例及所述用户一口价信息，生成司机一口价信息；
所述每个司机在各自的司机端基于所述司机一口价信息提供是否接受所述司机一口价信息的服务价格子信息。
优选地，所述用户计价模式为用户按票计价；所述用户计价子信息为所述用户提供的每票最低价格信息；
至少一个司机端各自发送的服务价格子信息具体按照以下步骤生成：
所述每个司机在各自的司机端基于所述每票最低价格信息提供相应的每票服务价格信息；
根据预设抽佣比例、溢价比例及所述每票服务价格信息，生成所述每个司机端各自对应的服务价格子信息。
优选地，所述用户计价模式为按重量计价；所述用户计价子信息为所述用户提供的每吨最低价格信息；
至少一个司机端各自发送的服务价格子信息具体按照以下步骤生成：
所述每个司机在各自的司机端基于所述每吨最低价格信息提供相应的每吨服务价格信息；
根据预设抽佣比例、溢价比例及所述每吨服务价格信息，生成所述每个司机端各自对应的服务价格子信息。
优选地，所述用户计价模式为按件计价；所述用户计价子信息为所述用户提供的每件最低价格信息；
至少一个司机端各自发送的服务价格子信息具体按照以下步骤生成：
所述每个司机在各自的司机端基于所述每件最低价格信息提供相应的每件服务价格信息；
根据预设抽佣比例、溢价比例及所述每件服务价格信息，生成所述每个司机端各自对应的服务价格子信息。
本申请提供了一种用车匹配装置，包括：
第一获取模块，用于获取用户的用车需求信息；
第一发送模块，用于发送所述用车需求信息至至少一个司机端；
第二获取模块，用于获取所述至少一个司机端各自发送的司机服务信息；其中，每个司机端发送的司机服务信息由其对应司机基于所述用车需求信息提供的；
匹配模块，用于根据所述用车需求信息分别与所述至少一个司机的司机服务信息的第一匹配程度，确定满足匹配要求的至少一个中标司机；
订单生成模块，用于基于所述用车需求信息及所述至少一个中标司机各自对应的司机服务信息，针对每一个中标司机生成相应的用车订单。
本申请还提供了一种用车匹配设备，包括处理组件和存储组件；所述存储组件存储一条或多条计算机程序指令；所述处理组件用于调用并执行所述一条或多条计算机程序指令以实现：
获取用户的用车需求信息；
发送所述用车需求信息至至少一个司机端；
获取所述至少一个司机端各自发送的司机服务信息；其中，每个司机端发送的司机服务信息由其对应司机基于所述用车需求信息提供的；
根据所述用车需求信息分别与所述至少一个司机的司机服务信息的第一匹配程度，确定满足匹配要求的至少一个中标司机；
基于所述用车需求信息及所述至少一个中标司机各自对应的司机服务信息，针对每一个中标司机生成相应的用车订单。
与现有技术相比，本发明可以获得包括以下技术效果：
本发明提供了一种用车匹配方法、装置及设备，该方法通过获取用户的用车需求信息并发送所述用车需求信息至至少一个司机端。获取所述至少一个司机端各自发送的司机服务信息；其中，每个司机端发送的司机服务信息由其对应司机基于所述用车需求信息提供的。根据所述用车需求信息分别与所述至少一个司机的司机服务信息的第一匹配程度，确定满足匹配要求的至少一个中标司机。基于所述用车需求信息及所述至少一个中标司机各自对应的司机服务信息，针对每一个中标司机生成相应的用车订单。从而实现企业用户的自动招标，可大大提高企业用户用车需求匹配效率，降低企业用车成本。
附图说明
此处所说明的附图用来提供对本发明的进一步理解，构成本发明的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：
图1是本申请实施例的一种用车匹配方法的一个实施例的流程图；
图2是本申请实施例的一种用车匹配方法的又一个实施例的流程图；
图3是本申请实施例的一种用车匹配方法的另一个实施例的流程图；
图4是本申请实施例的一种用车匹配装置的一个实施例的结构示意图；
图5是本申请实施例的一种用车匹配装置的又一个实施例的结构示意图；
图6是本申请实施例的一种用车匹配装置的另一个实施例的结构示意图；
图7是本申请实施例的一种用车匹配设备的一个实施例的结构示意图。
具体实施方式
以下将配合附图及实施例来详细说明本发明的实施方式，藉此对本发明如何应用技术手段来解决技术问题并达成技术功效的实现过程能充分理解并据以实施。
本申请实施例不仅适用于企业用户的用车匹配，还可使用于个人用户的用车匹配，在此不做具体限定。
下面将结合附图对本发明技术方案进行详细描述。
图1是本申请实施例的一种用车匹配方法的一个实施例的流程图。该方法可以包括：
S101：获取用户的用车需求信息。
本申请实施实例中涉及到用户端、司机端和服务端构成的系统框架。
本申请实施例通过用户端获取用户的用车需求信息。用户端可以是针对每个企业用户开发的应用程序，用户通过安装在手机或电脑端的应用程序输入相应的用车需求信息，生成用车标书选择发布用车标书。用车需求信息可以包括运输车型、配送地区、配送时间、搬运说明、培训说明、计价方式等。
S102：发送所述用车需求信息至至少一个司机端。
用车标书发布过程实际是由用户端将包含用户的用车需求信息的用车标书发送至服务端，服务端则将用户的用车标书发送至至少一个司机端。
实际应用中，服务端可以不经过筛选将该用车标书推送至每个司机端或按通过分析用户的用车标书，照一定条件筛选出符合条件的至少一个司机端，将用户的用车标书推送给符合条件的至少一个司机。例如，用户的用车标书中会包括配送地区的限定，则服务端仅会将标书发送至配送地区所在的司机。或者用户的用车标书中会限定使用车型，例如仅限于大型厢货车型，则会将该用车标书发送至可以提供大型厢货车的司机对应的司机端。当然，可以理解的是，为了进一步提高用车匹配效率，服务端可以基于多个条件(例如，地域、技能、车型等)对司机进行一个初步筛选，将用户的用车标书推送至符合初步筛选条件的司机对应的司机端。
可以理解的是，为了进一步提高用车匹配效率，服务端还可以基于用车标书中的用车需求信息评估该用车标书的级别，如果该用车标书评价为优，则会将该用车标书优先推送给信用评级较高的司机，如果该用车标书评价较差，则将该用车标书优先推送给单量较少的司机。
S103：获取所述至少一个司机端各自发送的司机服务信息。
其中，每个司机端发送的司机服务信息由其对应司机基于所述用车需求信息提供的。
接收到服务端推送的包含用户用车需求的用车标书的每个司机端，通过语音、震动、铃声、消息推送等任意方式提示相应的司机查看该用车标书，司机基于用车标书确定是否进行投标。当用户想要进行投标时，则通过司机端基于用车标书中的用车需求信息，输入司机的司机服务信息，并发送至服务端，司机的司机服务信息可以是针对用户用车需求信息一一对应输入的，也可以是司机在司机端设置了默认的司机服务信息，当司机确认进行投标时，司机端可根据司机初始设置的默认司机服务信息自动生成。当然，当司机端基于该用车需求信息自动生成司机服务信息后，司机还可以根据自身情况对自动生成的司机服务信息进行修改，具体在此不进行具体限定。最后，每个司机端可以将对应司机确认的司机服务信息发送至服务端。
S104：根据所述用车需求信息分别与所述至少一个司机的司机服务信息的第一匹配程度，确定满足匹配要求的至少一个中标司机。
服务端将获取的用户的用车需求分别与每个司机对应的司机服务信息进行匹配，获得所述用车需求信息分别与所述至少一个司机的司机服务信息的第一匹配程度。基于该第一匹配程度，进一步确定每个司机与所述用车匹配需求的匹配程度，从而确定满足匹配需求的至少一个中标司机。
实际应用中，用户的用车需求信息可能仅需要10个司机即可满足用户的用车需求，但实际确定每个司机与所述用车匹配需求的匹配程度后，可以设定匹配阈值，大于该匹配阈值的司机即为满足匹配需求的司机；当然还可以根据匹配程度的大小顺序依次选择出用户所需的司机人数，作为中标司机，例如按照匹配程度的大小顺序，选择前10个司机为中标司机。当通过设定匹配阈值确定的满足匹配需求的司机的数量可能远远超过实际用户需要的司机数量，进一步地，还可以根据司机的信用度、历史接单量等从满足匹配需求的司机中选取用户需求数量的中标司机。
S105：基于所述用车需求信息及所述至少一个中标司机各自对应的司机服务信息，针对每一个中标司机生成相应的用车订单。
可选地，基于用车需求信息生成的用车标书，针对每一个中标司机生成相应的用车订单。用车订单中包含服务地点(服务起点及服务终点)、服务里程、服务价格、服务时间、服务车型、是否培训、是否返仓、是否搬运等要求，每一个中标司机根据各自的用车订单提供相应的运输服务。
例如，用车需求信息中要求服务天数为15天(下个月1号-15号)，每天需要10辆车提供运输服务。通过匹配已确定10个中标司机，根据每个中标司机的服务时间，针对每一个中标司机从下个月1号-15号连续生成15个用车订单。每个中标司机根据相应用车订单的服务时间到指定的服务地点，提供运输服务。如果需要额外的搬运服务，培训需求等则在相应的用车订单中注明需要搬运、培训等。可以理解的是，用车订单根据实际的服务时间及中标司机的司机服务信息确定，例如，用户在每个月的工作日内，每天需要10辆车提供运输服务，每趟运输时间为两个小时，确定的中标司机为5个。则针对每个中标司机，分别在每个工作日生成分不同时段两个用车订单，完成用户要求的运输任务。
上述仅为示例性描述，具体可根据实际匹配情况及用车需求信息，针对每个中标司机生成各自的用车订单，在此不做具体限定。
本申请实施实例中，通过获取用户的用车需求信息并发送所述用车需求信息至至少一个司机端。获取所述至少一个司机端各自发送的司机服务信息；根据所述用车需求信息分别与所述至少一个司机的司机服务信息的第一匹配程度，确定满足匹配要求的至少一个中标司机。基于所述用车需求信息及所述至少一个中标司机各自对应的司机服务信息，针对每一个中标司机生成相应的用车订单。从而实现企业用户的自动招标，可大大提高企业用户用车需求匹配效率，降低企业用车成本。
图2是本申请实施例的一种用车匹配方法的又一个实施例的流程图。该方法可以包括：
S201：获取用户的用车需求信息。
S202：发送所述用车需求信息至至少一个司机端。
S203：获取所述至少一个司机端各自发送的司机服务信息。
其中，每个司机端发送的司机服务信息由其对应司机基于所述用车需求信息提供的。
S204：确定所述用车需求信息分别与所述至少一个司机的司机服务信息的第一匹配程度。
实际应用中，为了匹配获得更适合的中标司机，服务端通过运力参数分别将用户的用车需求子参数的标签化及司机的司机服务子信息的标签化。用户的用车需求信息可以包括至少一个用车需求子信息，司机的司机服务信息可以包括司机服务子信息。本申请实施实例中将运力参数作为标签，使每一个用车需求子信息对应一个运力参数，且每一个司机服务子信息也同样对应一个运力参数。可选地，在某些实施例中，所述用车需求信息可以包括分别对应至少一个运力参数的用车需求子信息。所述司机服务信息包括分别对应所述至少一个运力参数的司机服务子信息。
所述确定所述用车需求信息分别与所述至少一个司机的司机服务信息的第一匹配程度可以包括：
针对每一个司机，分别确定对应同一个运力参数的所述用车需求子信息与所述司机服务子信息的第一匹配程度。
通过将用车需求信息与司机服务信息标签化，分别将对应同一个运力参数的用车需求子信息与司机服务子信息进行匹配，并将匹配结果作为对应的运力参数的第一匹配程度。
例如，分别将用车需求信息及司机服务信息标签化后对应3个运力参数，则通过上述匹配过程，可得到每一个司机端的司机提供的司机服务信息与用户的用车需求信息分别基于该3个运力参数匹配各自对应的第一匹配程度。
S205：基于所述第一匹配程度，确定所述用车需求信息分别与所述至少一个司机的第二匹配程度。
为了进一步获得用车需求信息分别与每一个司机的匹配程度，可选地，在某些实施例中，所述基于所述第一匹配程度，确定所述用车需求信息分别与所述至少一个司机的第二匹配程度可以包括：
确定每一个运力参数的权重值；
针对每一个司机，基于每一个运力参数各自对应的第一匹配程度及权重值，计算所述用车需求信息分别与所述每一个司机的第二匹配程度。
实际应用中，可根据实际匹配需求对每一个运力参数设定不同的权重值，例如，分别将用车需求信息及司机服务信息标签化后对应3个运力参数,第一个运力参数的权重值为D1，第二个运力参数的权重值为D2，第三个运力参数的权重值为D3，其中，D1+D2+D3＝1。如果标签化后对应有N个运力参数时，则每个运力参数的权重值相加仍满足，D1+D2+D3+……+DN＝1。实际应用中，根据用户的用车需求信息包含的用车需求子信息个数，确定标签个数即运力参数个数。实际应用中，每一个用车需求子信息对应一个运力参数，因此，当用车需求子信息越多时，对应的运力参数就越多。根据每个用车需求子信息的重要程度，对每个运力参数的权重值进行赋值。可选地，每个运力参数的权重值可以是固定值，例如，对特定的运力参数设定固定的权重值，当该用户没有输入对应任一运力参数的用车需求子信息没有时，该运力参数的第一匹配程度可以计为零计算。当然可以理解的是，由于每个用户的运力参数包含的数量不同，因此，可以在对每个用户的用车需求信息标签化后。对得到的至少一个运力参数的权重值进行随机赋值或按照预设规则赋值，使得该至少一个运力参数的权重值符合D1+D2+D3+……+DN＝1的规则。
可选的，在某些实施例中，所述至少一个运力参数可以包括服务天数、价格情况、运输情况、搬运情况及服务时长；
对应所述服务天数的用车需求子信息包括用车天数及对应所述服务天数的司机服务子信息包括供车天数。
对应所述价格情况的用车需求子信息包括用户计价及对应所述价格情况的司机服务子信息包括服务价格。
对应所述运输情况的用车需求子信息包括运输里程及对应所述运输情况的司机服务子信息包括最远服务里程。
对应所述搬运情况的用车需求子信息包括需要搬运程度及对应所述搬运情况的司机服务子信息包括可提供搬运程度。
对应所述服务时长的用车需求子信息包括单次运输所需时长及对应所述服务时长的司机服务子信息包括单次运输最大服务时长。
实际应用中，运力参数包括但不限于上述内容，可根据实际需求进行增加，以满足用户的用车匹配需求。
在确定每一个运力参数的权重值后，针对每一个司机，基于每一个运力参数对应的第一匹配程度值与其对应的权重值计算每个司机的第二匹配程度。
S206：根据所述用车需求信息分别与所述至少一个司机各自对应的第二匹配程度，确定所述至少一个司机中满足中标阈值的至少一个中标司机。
实际该中标阈值可根据实际情况进行设定，例如，实际需求司机数量为固定的，将司机数量作为中标阈值。例如实际需求司机数量为100人，则将100人作为中标阈值，将基于每个司机的第二匹配程度按照从大到小的顺序排列选择前100名司机作为中标司机。如果不限定具体所需司机数量，则可确定第二匹配阈值为中标阈值，仅当司机的第二匹配程度大于或不小于该第二匹配阈值时，确定该司机为中标司机。
中标阈值可根据实际匹配情况进行灵活设定，工作人员可在服务端设定多种类型的中标阈值供用户选择，或用户根据自己的需求进行设定在此不做具体限定。
S207：基于所述用车需求信息及至少一个中标司机各自对应的司机服务信息，针对每一个中标司机生成相应的用车订单。
可选地，在某些实施例中，所述针对每一个司机，分别确定对应同一个运力参数的所述用车需求子信息与所述司机服务子信息的第一匹配程度包括：
针对每一个司机，确定对应所述服务天数的所述用车天数与所述供车天数的第一匹配程度；
确定对应所述价格情况的所述用户计价与所述服务价格的第一匹配程度；
确定对应所述运输情况的所述运输路程与所述最远服务路程的第一匹配程度；
确定对应所述搬运情况的所述需要搬运程度与所述可提供搬运程度的第一匹配程度；
确定对应所述服务时长的所述单次运输所需时长与所述单次运输最大服务时长的第一匹配程度。
可选地，在某些实施例中，所述针对每一个司机，基于每一个运力参数各自对应的第一匹配程度及权重值，计算所述用车需求信息分别与所述每一个司机的第二匹配程度包括：
针对所述每一个司机，分别计算每一个运力参数各自对应的第一匹配程度与权重值的乘积，计算获得每一个运力参数分别对应的子匹配值；
针对所述每一个司机，将所述每一个运力参数分别对应的子匹配值求和，分别获得所述每一个司机对应的第二匹配程度。
所述任一司机的第二匹配程度具体可以按照下述方式计算获得：
例如，至少一个运力参数可以包括服务天数、价格情况、运输情况、搬运情况及服务时长。将用车天数与该任一司机的供车天数进行匹配得到服务天数对应的第一匹配程度A1i；将用户计价与该任一司机的服务价格匹配得到价格情况对应的第一匹配程度A2i；将运输里程与该任一司机的最远服务里程匹配得到运输情况对应的第一匹配程度A3i；将需要搬运程度与该任一司机的可提供搬运程度进行匹配得到搬运情况对应的第一匹配程度A4i；将单次运输所需时长与该任一司机的单次运输最大服务时长进行匹配得到服务时长对应的第一匹配程度A5i。
其中，服务天数、价格情况、运输情况、搬运情况及服务时长各自对应的权重值依次为D1、D2、D3、D4、D5。
该任一司机的第二匹配程度可表示为：Pi＝A1i*D1+A2i*D2+A3i*D3+A4i*D4+A5i*D5，其中，0≤i≤M，M表示参与投标的司机数量。
可选地，为了便于用户进行定价结算，在用户输入用车需求信息时，可以在用户端中首先确定用户计价子信息的计价模式，并在匹配成功中标司机后，按照选择的计价模式对每一个中标司机进行定价结算。实际应用中，服务端预先设定了多种计价模式供用户选择，可选地，在某些实施例中，所述用车需求信息可以包括用户计价子信息；
所述发送所述用车需求信息至至少一个司机端包括：
确定所述用户计价子信息对应的计价模式；
按照所述计价模式发送所述用户计价子信息至所述至少一个司机端，其中，所述用户计价模式包括司机报价、用户一口价、用户按票计价、按重量计价、按件计价。
其中，司机报价模式即为，用户首先输入一个心理价位作为用户计价子信息，司机端的司机基于用户提供的心理价位，进行报价，司机报价可以高于该心理价位，也可低于该心理价位，具体地司机可根据自己实际情况进行报价，生成服务价格。在匹配过程中，将司机报价与用户的心理价位进行匹配，越接近该心理价位时，该价格情况对应的第一匹配程度越高。
用户一口价模式，即为司机不需要进行报价，用户选择一口价模式后，用户给出服务价位作为用户计价子信息，司机可基于司机端接收到的用户提供的服务价位选择是否接受该服务价位，如果不接受该服务价位，则认为该司机自动退出竞标；如果接受，则继续进行竞标。
用户按票计价模式，即为当该订单可能包含多项服务，例如需要提供额外的搬运、返仓等服务需求，为了便于计价，可选择按票计价，即用户提供司机完成所有的服务项目的总价位作为用户计价子信息，包括运输服务、搬运服务、返仓服务等的服务价位。
按重量计价模式及按件计价模式可根据运输货物的不同进行选择，如果用户需要运输的例如是运输煤炭、水果、蔬菜等可按照重量进行计价，即用户提供运输一吨货物的价格作为用户计价子信息；当用户需要运输的例如是电子设备、器械、家具、鲜花等，用户可选择案件计价模式，即用户提供运输一件货物的价格作为用户计价子信息。
可选地，在某些实施例中，所述司机服务信息可以包括服务价格子信息；
所述获取所述至少一个司机端各自发送的司机服务信息包括：
获取所述至少一个司机端各自发送的服务价格子信息；其中，所述每个司机端发送的服务价格子信息由其对应司机基于所述用户计价模式及所述用户计价子信息提供的。
实际用户提供的用户计价子信息，与司机端接收到用户计价子信息之间会存在一定的差异，其中，司机端接收到的用户计价子信息是基于用户提供的计价价位再加上预设抽佣比例显示的。即用户提供的计价价位减去服务平台的抽佣费，例如服务平台按照10％收取抽佣费，则司机端显示的用户报价为(1-10％)*服务价位。
可选地，在某些实施实例中，所述用户计价模式为司机报价；所述用户计价子信息为所述用户提供的最低报价信息；
至少一个司机端各自发送的服务价格子信息具体按照以下步骤生成：
所述每个司机在各自的司机端基于所述用户的最低报价信息提供相应的司机报价信息；
根据预设抽佣比例、溢价比例及所述司机报价信息，生成所述每个司机端各自对应的服务价格子信息。
同样地，服务平台还需要收取司机的抽佣费，当用户与司机的供求关系紧张时，还会存在一定的溢价，供求比例不同对应不同的溢价比例。例如节假日，非工作日，司机数量少，此时供求关系紧张则溢价比例会相应提高。
因此，司机提供的服务价格子信息＝司机报价信息*溢价比例*(1-抽佣比例)。
可选的，在某些实施实例中，所述用户计价模式为用户一口价；所述用户计价子信息为所述用户提供的用户一口价信息。
至少一个司机端各自发送的服务价格子信息具体按照以下步骤生成：
根据预设抽佣比例、溢价比例及所述用户一口价信息，生成司机一口价信息；
所述每个司机在各自的司机端基于所述司机一口价信息提供是否接受所述司机一口价信息的服务价格子信息。
可选地，用户一口价计价模式下的司机服务价格为，司机一口价信息＝用户一口价信息*溢价比例*(1-抽佣比例)。
可选地，在某些实施例中，所述用户计价模式为用户按票计价；所述用户计价子信息为所述用户提供的每票最低价格信息；
至少一个司机端各自发送的服务价格子信息具体按照以下步骤生成：
所述每个司机在各自的司机端基于所述每票最低价格信息提供相应的每票服务价格信息；
根据预设抽佣比例、溢价比例及所述每票服务价格信息，生成所述每个司机端各自对应的服务价格子信息。
可选地，按票计价模式下的司机服务价格＝票数*每票服务价格信息*溢价比例*(1-抽佣比例)。
可选地，在某些实施实例中，所述用户计价模式为按重量计价；所述用户计价子信息为所述用户提供的每吨最低价格信息；
至少一个司机端各自发送的服务价格子信息具体按照以下步骤生成：
所述每个司机在各自的司机端基于所述每吨最低价格信息提供相应的每吨服务价格信息；
根据预设抽佣比例、溢价比例及所述每吨服务价格信息，生成所述每个司机端各自对应的服务价格子信息。
可选地，按重量计价模式下的司机服务价格＝吨数*每吨服务价格信息*溢价比例*(1-抽佣比例)。
可选地，在某些实施例中，所述用户计价模式为按件计价；所述用户计价子信息为所述用户提供的每件最低价格信息；
至少一个司机端各自发送的服务价格子信息具体按照以下步骤生成：
所述每个司机在各自的司机端基于所述每件最低价格信息提供相应的每件服务价格信息；
根据预设抽佣比例、溢价比例及所述每件服务价格信息，生成所述每个司机端各自对应的服务价格子信息。
可选地，按件计价模式下的司机服务价格＝件数*每件服务价格信息*溢价比例*(1-抽佣比例)。
可以理解的是，用户选择按票计价模式、按件计价模式或按重量计价模式时，可以是一口价即按照用户提供价位，不允许司机还价，司机接受即可继续参与竞标，不接受就默认放弃竞标。也可以是司机报价，司机根据用车需求信息输入司机报价价位，将司机报价与用户的心理价位进行匹配，得到价格情况对应的第一匹配程度。具体可根据实际情况进行设定，在此不做具体限定。
可以理解的是，上述仅示意性提供了多种计价模式，实际可根据用户运输需求提供更加丰富的计价模式，在此不做具体限定。
本申请实施实例中，通过将用户的用车需求信息及司机的司机服务信息标签化，将分别对应相同标签(即运力参数)的用车需求子信息及司机服务子信息进行匹配，获得的对应每一个运力参数的第一匹配程度。针对每一个司机，根据其对应运力参数的第一匹配程度及每个运力参数的权重值计算每个司机与用车需求信息的第二匹配程度，通过设定中标阈值，基于每个司机对应的第二匹配程度筛选出满足匹配条件的中标司机。
另外，本申请实施实例中还提供了丰富的定价模式供用户选择，基于不同的定价模式实现高效的定价结算，能够自动平衡用户与司机的利益的同时，还可分别结算用户与司机的平台抽佣费用，实现高效的定价结算。
图3是本申请实施例的一种用车匹配方法的另一个实施例的流程图；该方法可以包括：
S301：获取用户的用车需求信息。
S302：发送所述用车需求信息至至少一个司机端。
S303：获取所述至少一个司机端各自发送的司机服务信息；其中，每个司机端发送的司机服务信息由其对应司机基于所述用车需求信息提供的。
S304：分别获取用户的用户属性信息及所述至少一个司机端的司机属性信息。
可选地，用户属性信息可以包括分别对应至少一个属性参数的用户属性子信息，该用户属性子信息分别可以包括历史下单量、用户画像、用户信用维度等。
司机属性信息包括分别对应至少一个属性参数的司机属性子信息，该司机属性子信息可以包括历史接单量、司机画像、司机信用维度等。
可选地，历史下单量及历史接单量可选择近一个月内，15天或三个月等作为匹配条件，具体可根据实际情况进行设定。
用户画像用于描述用户的自有运力情况，可以分为新用户、自有运力用户，偶尔需补充运力、自有运力用户，经常需补充运力、无运力用户。
司机画像用于描述司机的接单情况，可以分为新司机、兼职司机，偶尔接单、兼职司机，经常接单、全职司机。
用户信用维度及司机信用维度可以分为初始信用度(新用户及新司机)、信用极好、信用好、信用中、信用差、信用极差等。
在每个用车订单完成后，用户可以通过用户端给服务司机进行评价，同样地司机也可以通过司机端给用户进行评价，评价越高相应的信用维度就越高，反之信用维度就越低。
S305：根据用车需求信息分别与至少一个司机的司机服务信息的第一匹配程度及司机属性信息与用户属性信息的第三匹配程度，确定满足匹配要求的至少一个中标司机。
可选地，为了进一步提高匹配获得更适合的中标司机，还可以分别获取用户的用户属性信息及司机端的司机属性信息进行匹配，并通过将用户属性信息及司机属性信息标签化进行匹配获得，用户属性信息与司机属性信息的第三匹配程度。
可选地，在某些实施实例中，所述确定所述用车需求信息分别与所述至少一个司机的司机服务信息的第一匹配程度及司机属性信息与用户属性信息的第三匹配程度可以包括：
针对每一个司机，分别确定对应同一个运力参数的所述用车需求子信息与所述司机服务子信息的第一匹配程度；
针对每一个司机，分别确定对应同一个属性参数的所述用户属性子信息与所述司机属性子信息的第三匹配程度；
确定每一个运力参数的权重值；
针对每一个司机，基于每一个运力参数各自对应的第一匹配程度及权重值，计算所述用车需求信息分别与所述每一个司机的第二匹配程度；
确定每一个属性参数的权重值，基于每一个属性参数各自对应的第三匹配程度及权重值，计算所述用户属性信息分别与所述每一个司机的司机属性信息的第四匹配程度；
根据所述用车需求信息分别与所述至少一个司机各自对应的第二匹配程度及用户属性信息分别与所述每一个司机的司机属性信息的第四匹配程度，确定所述至少一个司机中满足中标阈值的至少一个中标司机属性参数。
可选地，每一个属性参数各自对应的权重值满足相加为1，其中第四程度计算方法与第二程度计算方法相似，在此不再赘述。
其中，用户属性参数与每一个司机的司机属性参数的第四匹配程度后，可以直接与用车需求信息分别与所述至少一个司机各自对应的第二匹配程度相加，也可以确定用车需求信息权重值与用户属性参数权重值，计算用户分别与每一个司机的第五匹配程度。其中，第五匹配程度＝第四匹配程度*用户属性参数权重值+第二匹配程度*用车需求信息权重值，其中，用户属性参数权重值+用车需求信息权重值＝1。
S306：基于所述用车需求信息及至少一个中标司机各自对应的司机服务信息，针对每一个中标司机生成相应的用车订单。
本申请实施例中，通过将用户属性参数及司机属性参数进行匹配，可以将信用维度高、接单量多的优质司机优先匹配给优质客户，从而可以同时提高司机和用户的满意度的同时，大大减少用户的招标时间，提高用户的选择司机的效率，进一步降低了企业成本。
图4是本申请实施例的一种用车匹配装置的一个实施例的结构示意图。该装置可以包括：
第一获取模块401，用于获取用户的用车需求信息。
本申请实施实例中涉及到用户端、司机端和服务端构成的系统框架。
本申请实施例通过用户端获取用户的用车需求信息。用户端可以是针对每个企业用户开发的应用程序，用户通过安装在手机或电脑端的应用程序输入相应的用车需求信息，生成用车标书选择发布用车标书。用车需求信息可以包括运输车型、配送地区、配送时间、搬运说明、培训说明、计价方式等。
第一发送模块402，用于发送所述用车需求信息至至少一个司机端。
用车标书发布过程实际是由用户端将包含用户的用车需求信息的用车标书发送至服务端，服务端则将用户的用车标书发送至至少一个司机端。
实际应用中，服务端可以不经过筛选将该用车标书推送至每个司机端或按通过分析用户的用车标书，照一定条件筛选出符合条件的至少一个司机端，将用户的用车标书推送给符合条件的至少一个司机。例如，用户的用车标书中会包括配送地区的限定，则服务端仅会将标书发送至配送地区所在的司机。或者用户的用车标书中会限定使用车型，例如仅限于大型厢货车型，则会将该用车标书发送至可以提供大型厢货车的司机对应的司机端。当然，可以理解的是，为了进一步提高用车匹配效率，服务端可以基于多个条件(例如，地域、技能、车型等)对司机进行一个初步筛选，将用户的用车标书推送至符合初步筛选条件的司机对应的司机端。
可以理解的是，为了进一步提高用车匹配效率，服务端还可以基于用车标书中的用车需求信息评估该用车标书的级别，如果该用车标书评价为优，则会将该用车标书优先推送给信用评级较高的司机，如果该用车标书评价较差，则将该用车标书优先推送给单量较少的司机。
第二获取模块403，用于获取所述至少一个司机端各自发送的司机服务信息。
其中，每个司机端发送的司机服务信息由其对应司机基于所述用车需求信息提供的。
接收到服务端推送的包含用户用车需求的用车标书的每个司机端，通过语音、震动、铃声、消息推送等任意方式提示相应的司机查看该用车标书，司机基于用车标书确定是否进行投标。当用户想要进行投标时，则通过司机端基于用车标书中的用车需求信息，输入司机的司机服务信息，并发送至服务端，司机的司机服务信息可以是针对用户用车需求信息一一对应输入的，也可以是司机在司机端设置了默认的司机服务信息，当司机确认进行投标时，司机端可根据司机初始设置的默认司机服务信息自动生成。当然，当司机端基于该用车需求信息自动生成司机服务信息后，司机还可以根据自身情况对自动生成的司机服务信息进行修改，具体在此不进行具体限定。最后，每个司机端可以将对应司机确认的司机服务信息发送至服务端。
匹配模块404，用于根据所述用车需求信息分别与所述至少一个司机的司机服务信息的第一匹配程度，确定满足匹配要求的至少一个中标司机。
服务端将获取的用户的用车需求分别与每个司机对应的司机服务信息进行匹配，获得所述用车需求信息分别与所述至少一个司机的司机服务信息的第一匹配程度。基于该第一匹配程度，进一步确定每个司机与所述用车匹配需求的匹配程度，从而确定满足匹配需求的至少一个中标司机。
实际应用中，用户的用车需求信息可能仅需要10个司机即可满足用户的用车需求，但实际确定每个司机与所述用车匹配需求的匹配程度后，可以设定匹配阈值，大于该匹配阈值的司机即为满足匹配需求的司机；当然还可以根据匹配程度的大小顺序依次选择出用户所需的司机人数，作为中标司机，例如按照匹配程度的大小顺序，选择前10个司机为中标司机。当通过设定匹配阈值确定的满足匹配需求的司机的数量可能远远超过实际用户需要的司机数量，进一步地，还可以根据司机的信用度、历史接单量等从满足匹配需求的司机中选取用户需求数量的中标司机。
订单生成模块405，用于基于所述用车需求信息及所述至少一个中标司机各自对应的司机服务信息，针对每一个中标司机生成相应的用车订单。
可选地，基于用车需求信息生成的用车标书，针对每一个中标司机生成相应的用车订单。用车订单中包含服务地点(服务起点及服务终点)、服务里程、服务价格、服务时间、服务车型、是否培训、是否返仓、是否搬运等要求，每一个中标司机根据各自的用车订单提供相应的运输服务。
例如，用车需求信息中要求服务天数为15天(下个月1号-15号)，每天需要10辆车提供运输服务。通过匹配已确定10个中标司机，根据每个中标司机的服务时间，针对每一个中标司机从下个月1号-15号连续生成15个用车订单。每个中标司机根据相应用车订单的服务时间到指定的服务地点，提供运输服务。如果需要额外的搬运服务，培训需求等则在相应的用车订单中注明需要搬运、培训等。可以理解的是，用车订单根据实际的服务时间及中标司机的司机服务信息确定，例如，用户在每个月的工作日内，每天需要10辆车提供运输服务，每趟运输时间为两个小时，确定的中标司机为5个。则针对每个中标司机，分别在每个工作日生成分不同时段两个用车订单，完成用户要求的运输任务。
上述仅为示例性描述，具体可根据实际匹配情况及用车需求信息，针对每个中标司机生成各自的用车订单，在此不做具体限定。
本申请实施实例中，通过获取用户的用车需求信息并发送所述用车需求信息至至少一个司机端。获取所述至少一个司机端各自发送的司机服务信息；根据所述用车需求信息分别与所述至少一个司机的司机服务信息的第一匹配程度，确定满足匹配要求的至少一个中标司机。基于所述用车需求信息及所述至少一个中标司机各自对应的司机服务信息，针对每一个中标司机生成相应的用车订单。从而实现企业用户的自动招标，可大大提高企业用户用车需求匹配效率，降低企业用车成本。
图5是本申请实施例的一种用车匹配装置的又一个实施例的结构示意图；该装置可以包括：
第一获取模块501，用于获取用户的用车需求信息。
第一发送模块502，用于发送所述用车需求信息至至少一个司机端。
第二获取模块503，用于获取所述至少一个司机端各自发送的司机服务信息。
其中，每个司机端发送的司机服务信息由其对应司机基于所述用车需求信息提供的。
匹配模块504，用于根据所述用车需求信息分别与所述至少一个司机的司机服务信息的第一匹配程度，确定满足匹配要求的至少一个中标司机。
实际应用中，为了匹配获得更适合的中标司机，服务端通过运力参数分别将用户的用车需求子参数的标签化及司机的司机服务子信息的标签化。用户的用车需求信息可以包括至少一个用车需求子信息，司机的司机服务信息可以包括司机服务子信息。本申请实施实例中将运力参数作为标签，使每一个用车需求子信息对应一个运力参数，且每一个司机服务子信息也同样对应一个运力参数。可选地，在某些实施例中，所述用车需求信息可以包括分别对应至少一个运力参数的用车需求子信息。所述司机服务信息包括分别对应所述至少一个运力参数的司机服务子信息。
所述匹配模块504可以包括:
第一匹配程度确定单元511，用于确定所述用车需求信息分别与所述至少一个司机的司机服务信息的第一匹配程度。
所述第一匹配程度确定单元511具体可以用于：
针对每一个司机，分别确定对应同一个运力参数的所述用车需求子信息与所述司机服务子信息的第一匹配程度。
通过将用车需求信息与司机服务信息标签化，分别将对应同一个运力参数的用车需求子信息与司机服务子信息进行匹配，并将匹配结果作为对应的运力参数的第一匹配程度。
例如，分别将用车需求信息及司机服务信息标签化后对应3个运力参数，则通过上述匹配过程，可得到每一个司机端的司机提供的司机服务信息与用户的用车需求信息分别基于该3个运力参数匹配各自对应的第一匹配程度。
第二匹配程度确定单元512，用于基于所述第一匹配程度，确定所述用车需求信息分别与所述至少一个司机的第二匹配程度。
为了进一步获得用车需求信息分别与每一个司机的匹配程度，可选地，在某些实施例中，第二匹配程度确定单元512具体可以用于：
确定每一个运力参数的权重值；
针对每一个司机，基于每一个运力参数各自对应的第一匹配程度及权重值，计算所述用车需求信息分别与所述每一个司机的第二匹配程度。
实际应用中，可根据实际匹配需求对每一个运力参数设定不同的权重值，例如，分别将用车需求信息及司机服务信息标签化后对应3个运力参数,第一个运力参数的权重值为D1，第二个运力参数的权重值为D2，第三个运力参数的权重值为D3，其中，D1+D2+D3＝1。如果标签化后对应有N个运力参数时，则每个运力参数的权重值相加仍满足，D1+D2+D3+……+DN＝1。实际应用中，根据用户的用车需求信息包含的用车需求子信息个数，确定标签个数即运力参数个数。实际应用中，每一个用车需求子信息对应一个运力参数，因此，当用车需求子信息越多时，对应的运力参数就越多。根据每个用车需求子信息的重要程度，对每个运力参数的权重值进行赋值。可选地，每个运力参数的权重值可以是固定值，例如，对特定的运力参数设定固定的权重值，当该用户没有输入对应任一运力参数的用车需求子信息没有时，该运力参数的第一匹配程度可以计为零计算。当然可以理解的是，由于每个用户的运力参数包含的数量不同，因此，可以在对每个用户的用车需求信息标签化后。对得到的至少一个运力参数的权重值进行随机赋值或按照预设规则赋值，使得该至少一个运力参数的权重值符合D1+D2+D3+……+DN＝1的规则。
可选的，在某些实施例中，所述至少一个运力参数可以包括服务天数、价格情况、运输情况、搬运情况及服务时长；
对应所述服务天数的用车需求子信息包括用车天数及对应所述服务天数的司机服务子信息包括供车天数。
对应所述价格情况的用车需求子信息包括用户计价及对应所述价格情况的司机服务子信息包括服务价格。
对应所述运输情况的用车需求子信息包括运输里程及对应所述运输情况的司机服务子信息包括最远服务里程。
对应所述搬运情况的用车需求子信息包括需要搬运程度及对应所述搬运情况的司机服务子信息包括可提供搬运程度。
对应所述服务时长的用车需求子信息包括单次运输所需时长及对应所述服务时长的司机服务子信息包括单次运输最大服务时长。
实际应用中，运力参数包括但不限于上述内容，可根据实际需求进行增加，以满足用户的用车匹配需求。
在确定每一个运力参数的权重值后，针对每一个司机，基于每一个运力参数对应的第一匹配程度值与其对应的权重值计算每个司机的第二匹配程度。
中标司机确定单元513，用于根据所述用车需求信息分别与所述至少一个司机各自对应的第二匹配程度，确定所述至少一个司机中满足中标阈值的至少一个中标司机。
实际该中标阈值可根据实际情况进行设定，例如，实际需求司机数量为固定的，将司机数量作为中标阈值。例如实际需求司机数量为100人，则将100人作为中标阈值，将基于每个司机的第二匹配程度按照从大到小的顺序排列选择前100名司机作为中标司机。如果不限定具体所需司机数量，则可确定第二匹配阈值为中标阈值，仅当司机的第二匹配程度大于或不小于该第二匹配阈值时，确定该司机为中标司机。
中标阈值可根据实际匹配情况进行灵活设定，工作人员可在服务端设定多种类型的中标阈值供用户选择，或用户根据自己的需求进行设定在此不做具体限定。
订单生成模块505，用于基于所述用车需求信息及至少一个中标司机各自对应的司机服务信息，针对每一个中标司机生成相应的用车订单。
可选地，在某些实施例中，所述针对每一个司机，分别确定对应同一个运力参数的所述用车需求子信息与所述司机服务子信息的第一匹配程度具体可以用于：
针对每一个司机，确定对应所述服务天数的所述用车天数与所述供车天数的第一匹配程度；
确定对应所述价格情况的所述用户计价与所述服务价格的第一匹配程度；
确定对应所述运输情况的所述运输路程与所述最远服务路程的第一匹配程度；
确定对应所述搬运情况的所述需要搬运程度与所述可提供搬运程度的第一匹配程度；
确定对应所述服务时长的所述单次运输所需时长与所述单次运输最大服务时长的第一匹配程度。
可选地，在某些实施例中，所述针对每一个司机，基于每一个运力参数各自对应的第一匹配程度及权重值，计算所述用车需求信息分别与所述每一个司机的第二匹配程度具体可以用于：
针对所述每一个司机，分别计算每一个运力参数各自对应的第一匹配程度与权重值的乘积，计算获得每一个运力参数分别对应的子匹配值；
针对所述每一个司机，将所述每一个运力参数分别对应的子匹配值求和，分别获得所述每一个司机对应的第二匹配程度。
所述任一司机的第二匹配程度具体可以按照下述方式计算获得：
例如，至少一个运力参数可以包括服务天数、价格情况、运输情况、搬运情况及服务时长。将用车天数与该任一司机的供车天数进行匹配得到服务天数对应的第一匹配程度A1i；将用户计价与该任一司机的服务价格匹配得到价格情况对应的第一匹配程度A2i；将运输里程与该任一司机的最远服务里程匹配得到运输情况对应的第一匹配程度A3i；将需要搬运程度与该任一司机的可提供搬运程度进行匹配得到搬运情况对应的第一匹配程度A4i；将单次运输所需时长与该任一司机的单次运输最大服务时长进行匹配得到服务时长对应的第一匹配程度A5i。
其中，服务天数、价格情况、运输情况、搬运情况及服务时长各自对应的权重值依次为D1、D2、D3、D4、D5。
该任一司机的第二匹配程度可表示为：Pi＝A1i*D1+A2i*D2+A3i*D3+A4i*D4+A5i*D5，其中，0≤i≤M，M表示参与投标的司机数量。
可选地，为了便于用户进行定价结算，在用户输入用车需求信息时，可以在用户端中首先确定用户计价子信息的计价模式，并在匹配成功中标司机后，按照选择的计价模式对每一个中标司机进行定价结算。实际应用中，服务端预先设定了多种计价模式供用户选择，可选地，在某些实施例中，所述用车需求信息可以包括用户计价子信息；
第一发送模块502具体可以用于：
确定所述用户计价子信息对应的计价模式；
按照所述计价模式发送所述用户计价子信息至所述至少一个司机端，其中，所述用户计价模式包括司机报价、用户一口价、用户按票计价、按重量计价、按件计价。
其中，司机报价模式即为，用户首先输入一个心理价位作为用户计价子信息，司机端的司机基于用户提供的心理价位，进行报价，司机报价可以高于该心理价位，也可低于该心理价位，具体地司机可根据自己实际情况进行报价，生成服务价格。在匹配过程中，将司机报价与用户的心理价位进行匹配，越接近该心理价位时，该价格情况对应的第一匹配程度越高。
用户一口价模式，即为司机不需要进行报价，用户选择一口价模式后，用户给出服务价位作为用户计价子信息，司机可基于司机端接收到的用户提供的服务价位选择是否接受该服务价位，如果不接受该服务价位，则认为该司机自动退出竞标；如果接受，则继续进行竞标。
用户按票计价模式，即为当该订单可能包含多项服务，例如需要提供额外的搬运、返仓等服务需求，为了便于计价，可选择按票计价，即用户提供司机完成所有的服务项目的总价位作为用户计价子信息，包括运输服务、搬运服务、返仓服务等的服务价位。
按重量计价模式及按件计价模式可根据运输货物的不同进行选择，如果用户需要运输的例如是运输煤炭、水果、蔬菜等可按照重量进行计价，即用户提供运输一吨货物的价格作为用户计价子信息；当用户需要运输的例如是电子设备、器械、家具、鲜花等，用户可选择案件计价模式，即用户提供运输一件货物的价格作为用户计价子信息。
可选地，在某些实施例中，所述司机服务信息可以包括服务价格子信息；
所述第二获取模块503具体可以用于：
获取所述至少一个司机端各自发送的服务价格子信息。
其中，所述每个司机端发送的服务价格子信息由其对应司机基于所述用户计价模式及所述用户计价子信息提供的。
实际用户提供的用户计价子信息，与司机端接收到用户计价子信息之间会存在一定的差异，其中，司机端接收到的用户计价子信息是基于用户提供的计价价位再加上预设抽佣比例显示的。即用户提供的计价价位减去服务平台的抽佣费，例如服务平台按照10％收取抽佣费，则司机端显示的用户报价为(1-10％)*服务价位。
可选地，在某些实施实例中，所述用户计价模式为司机报价；所述用户计价子信息为所述用户提供的最低报价信息；
至少一个司机端各自发送的服务价格子信息具体按照以下步骤生成：
所述每个司机在各自的司机端基于所述用户的最低报价信息提供相应的司机报价信息；
根据预设抽佣比例、溢价比例及所述司机报价信息，生成所述每个司机端各自对应的服务价格子信息。
可以理解的是，服务平台还需要收取司机的抽佣费，当用户与司机的供求关系紧张时，还会存在一定的溢价，供求比例不同对应不同的溢价比例。例如节假日，非工作日，司机数量少，此时供求关系紧张则溢价比例会相应提高。
因此，司机提供的服务价格子信息＝司机报价信息*溢价比例*(1-抽佣比例)。
可选的，在某些实施实例中，所述用户计价模式为用户一口价；所述用户计价子信息为所述用户提供的用户一口价信息。
至少一个司机端各自发送的服务价格子信息具体按照以下步骤生成：
根据预设抽佣比例、溢价比例及所述用户一口价信息，生成司机一口价信息；
所述每个司机在各自的司机端基于所述司机一口价信息提供是否接受所述司机一口价信息的服务价格子信息。
可选地，用户一口价计价模式下的司机服务价格为，司机一口价信息＝用户一口价信息*溢价比例*(1-抽佣比例)。
可选地，在某些实施例中，所述用户计价模式为用户按票计价；所述用户计价子信息为所述用户提供的每票最低价格信息；
至少一个司机端各自发送的服务价格子信息具体按照以下步骤生成：
所述每个司机在各自的司机端基于所述每票最低价格信息提供相应的每票服务价格信息；
根据预设抽佣比例、溢价比例及所述每票服务价格信息，生成所述每个司机端各自对应的服务价格子信息。
可选地，按票计价模式下的司机服务价格＝票数*每票服务价格信息*溢价比例*(1-抽佣比例)。
可选地，在某些实施实例中，所述用户计价模式为按重量计价；所述用户计价子信息为所述用户提供的每吨最低价格信息；
至少一个司机端各自发送的服务价格子信息具体按照以下步骤生成：
所述每个司机在各自的司机端基于所述每吨最低价格信息提供相应的每吨服务价格信息；
根据预设抽佣比例、溢价比例及所述每吨服务价格信息，生成所述每个司机端各自对应的服务价格子信息。
可选地，按重量计价模式下的司机服务价格＝吨数*每吨服务价格信息*溢价比例*(1-抽佣比例)。
可选地，在某些实施例中，所述用户计价模式为按件计价；所述用户计价子信息为所述用户提供的每件最低价格信息；
至少一个司机端各自发送的服务价格子信息具体按照以下步骤生成：
所述每个司机在各自的司机端基于所述每件最低价格信息提供相应的每件服务价格信息；
根据预设抽佣比例、溢价比例及所述每件服务价格信息，生成所述每个司机端各自对应的服务价格子信息。
可选地，按件计价模式下的司机服务价格＝件数*每件服务价格信息*溢价比例*(1-抽佣比例)。
可以理解的是，用户选择按票计价模式、按件计价模式或按重量计价模式时，可以是一口价即按照用户提供价位，不允许司机还价，司机接受即可继续参与竞标，不接受就默认放弃竞标。也可以是司机报价，司机根据用车需求信息输入司机报价价位，将司机报价与用户的心理价位进行匹配，得到价格情况对应的第一匹配程度。具体可根据实际情况进行设定，在此不做具体限定。
可以理解的是，上述仅示意性提供了多种计价模式，实际可根据用户运输需求提供更加丰富的计价模式，在此不做具体限定。
本申请实施实例中，通过将用户的用车需求信息及司机的司机服务信息标签化，将分别对应相同标签(即运力参数)的用车需求子信息及司机服务子信息进行匹配，获得的对应每一个运力参数的第一匹配程度。针对每一个司机，根据其对应运力参数的第一匹配程度及每个运力参数的权重值计算每个司机与用车需求信息的第二匹配程度，通过设定中标阈值，基于每个司机对应的第二匹配程度筛选出满足匹配条件的中标司机。
另外，本申请实施实例中还提供了丰富的定价模式供用户选择，基于不同的定价模式实现高效的定价结算，能够自动平衡用户与司机的利益的同时，还可分别结算用户与司机的平台抽佣费用，实现高效的定价结算。
图3是本申请实施例的一种用车匹配方法的另一个实施例的流程图；该方法可以包括：
第一获取模块601，用于获取用户的用车需求信息。
第一发送模块602，用于发送所述用车需求信息至至少一个司机端。
第二获取模块603，用于获取所述至少一个司机端各自发送的司机服务信息。
其中，每个司机端发送的司机服务信息由其对应司机基于所述用车需求信息提供的。
第三获取模块604，用于分别获取用户的用户属性信息及所述至少一个司机端的司机属性信息。
可选地，用户属性信息可以包括分别对应至少一个属性参数的用户属性子信息，该用户属性子信息分别可以包括历史下单量、用户画像、用户信用维度等。
司机属性信息包括分别对应至少一个属性参数的司机属性子信息，该司机属性子信息可以包括历史接单量、司机画像、司机信用维度等。
可选地，历史下单量及历史接单量可选择近一个月内，15天或三个月等作为匹配条件，具体可根据实际情况进行设定。
用户画像用于描述用户的自有运力情况，可以分为新用户、自有运力用户，偶尔需补充运力、自有运力用户，经常需补充运力、无运力用户。
司机画像用于描述司机的接单情况，可以分为新司机、兼职司机，偶尔接单、兼职司机，经常接单、全职司机。
用户信用维度及司机信用维度可以分为初始信用度(新用户及新司机)、信用极好、信用好、信用中、信用差、信用极差等。
在每个用车订单完成后，用户可以通过用户端给服务司机进行评价，同样地司机也可以通过司机端给用户进行评价，评价越高相应的信用维度就越高，反之信用维度就越低。
匹配模块605，用于根据用车需求信息分别与至少一个司机的司机服务信息的第一匹配程度及司机属性信息与用户属性信息的第三匹配程度，确定满足匹配要求的至少一个中标司机。
可选地，为了进一步提高匹配获得更适合的中标司机，还可以分别获取用户的用户属性信息及司机端的司机属性信息进行匹配，并通过将用户属性信息及司机属性信息标签化进行匹配获得，用户属性信息与司机属性信息的第三匹配程度。
可选地，在某些实施实例中，所述匹配模块605具体可以用于：
针对每一个司机，分别确定对应同一个运力参数的所述用车需求子信息与所述司机服务子信息的第一匹配程度；
针对每一个司机，分别确定对应同一个属性参数的所述用户属性子信息与所述司机属性子信息的第三匹配程度；
确定每一个运力参数的权重值；
针对每一个司机，基于每一个运力参数各自对应的第一匹配程度及权重值，计算所述用车需求信息分别与所述每一个司机的第二匹配程度；
确定每一个属性参数的权重值，基于每一个属性参数各自对应的第三匹配程度及权重值，计算所述用户属性信息分别与所述每一个司机的司机属性信息的第四匹配程度；
根据所述用车需求信息分别与所述至少一个司机各自对应的第二匹配程度及用户属性信息分别与所述每一个司机的司机属性信息的第四匹配程度，确定所述至少一个司机中满足中标阈值的至少一个中标司机属性参数。
可选地，每一个属性参数各自对应的权重值满足相加为1，其中第四程度计算方法与第二程度计算方法相似，在此不再赘述。
其中，用户属性参数与每一个司机的司机属性参数的第四匹配程度后，可以直接与用车需求信息分别与所述至少一个司机各自对应的第二匹配程度相加，也可以确定用车需求信息权重值与用户属性参数权重值，计算用户分别与每一个司机的第五匹配程度。其中，第五匹配程度＝第四匹配程度*用户属性参数权重值+第二匹配程度*用车需求信息权重值，其中，用户属性参数权重值+用车需求信息权重值＝1。
订单生成模块606，用于基于所述用车需求信息及至少一个中标司机各自对应的司机服务信息，针对每一个中标司机生成相应的用车订单。
本申请实施例中，通过将用户属性参数及司机属性参数进行匹配，可以将信用维度高、接单量多的优质司机优先匹配给优质客户，从而可以同时提高司机和用户的满意度的同时，大大减少用户的招标时间，提高用户的选择司机的效率，进一步降低了企业成本。
图7为本申请实施例提供的一种用车匹配设备的一个实施例的结构示意图。该用车匹配设备可以包括处理组件701和存储组件702；所述存储组件702存储一条或多条计算机程序指令。
所述处理组件701用于调用并执行所述一条或多条计算机程序指令以实现：
获取用户的用车需求信息；发送所述用车需求信息至至少一个司机端；获取所述至少一个司机端各自发送的司机服务信息；其中，每个司机端发送的司机服务信息由其对应司机基于所述用车需求信息提供的；根据所述用车需求信息分别与所述至少一个司机的司机服务信息的第一匹配程度，确定满足匹配要求的至少一个中标司机；基于所述用车需求信息及所述至少一个中标司机各自对应的司机服务信息，针对每一个中标司机生成相应的用车订单。
可选地，该处理组件701还用于执行前述各方法步骤中的全部或部分步骤。
其中，该处理组件701可以包括一个或多个处理器来执行计算机指令。当然处理组件701也可以为一个或多个应用专用集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理设备(DSPD)、可编程逻辑器件(PLD)、现场可编程门阵列(FPGA)、控制器、微控制器、微处理器或其他电子元件实现，用于执行上述方法。
该存储组件702可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。
当然，电子设备还可以包括其他部件，例如输入/输出接口、通信组件等。输入/输出接口为处理组件和外围接口模块之间提供接口，上述外围接口模块可以是输出设备、输入设备等。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
如在说明书及权利要求当中使用了某些词汇来指称特定组件。本领域技术人员应可理解，硬件制造商可能会用不同名词来称呼同一个组件。本说明书及权利要求并不以名称的差异来作为区分组件的方式，而是以组件在功能上的差异来作为区分的准则。如在通篇说明书及权利要求当中所提及的“包含”为一开放式用语，故应解释成“包含但不限定于”。“大致”是指在可接收的误差范围内，本领域技术人员能够在一定误差范围内解决技术问题，基本达到技术效果。此外，“耦接”一词在此包含任何直接及间接的电性耦接手段。因此，若文中描述一第一装置耦接于一第二装置，则代表第一装置可直接电性耦接于第二装置，或通过其他装置或耦接手段间接地电性耦接至第二装置。说明书后续描述为实施本发明的较佳实施方式，然描述乃以说明本发明的一般原则为目的，并非用以限定本发明的范围。本发明的保护范围当视所附权利要求所界定者为准。
还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的商品或者系统不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种商品或者系统所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括要素的商品或者系统中还存在另外的相同要素
上述说明示出并描述了本发明的若干优选实施例，但如前，应当理解本发明并非局限于本文所披露的形式，不应看作是对其他实施例的排除，而可用于各种其他组合、修改和环境，并能够在本文申请构想范围内，通过上述教导或相关领域的技术或知识进行改动。而本领域人员所进行的改动和变化不脱离本发明的精神和范围，则都应在本发明所附权利要求的保护范围内。
Claims (18)
1.一种用车匹配方法，其特征在于，包括：
获取用户的用车需求信息；
发送所述用车需求信息至至少一个司机端；
获取所述至少一个司机端各自发送的司机服务信息；其中，每个司机端发送的司机服务信息由其对应司机基于所述用车需求信息提供的；
根据所述用车需求信息分别与所述至少一个司机的司机服务信息的第一匹配程度，确定满足匹配要求的至少一个中标司机；
基于所述用车需求信息及所述至少一个中标司机各自对应的司机服务信息，针对每一个中标司机生成相应的用车订单。
2.根据权利要求1所述的方法，其特征在于，所述根据所述用车需求信息分别与所述至少一个司机的司机服务信息的第一匹配程度，确定满足匹配要求的至少一个中标司机包括：
确定所述用车需求信息分别与所述至少一个司机的司机服务信息的第一匹配程度；
基于所述第一匹配程度，确定所述用车需求信息分别与所述至少一个司机的第二匹配程度；
根据所述用车需求信息分别与所述至少一个司机各自对应的第二匹配程度，确定所述至少一个司机中满足中标阈值的至少一个中标司机。
3.根据权利要求2所述的方法，其特征在于，所述用车需求信息包括分别对应至少一个运力参数的用车需求子信息；
所述司机服务信息包括分别对应所述至少一个运力参数的司机服务子信息；
所述确定所述用车需求信息分别与所述至少一个司机的司机服务信息的第一匹配程度包括：
针对每一个司机，分别确定对应同一个运力参数的所述用车需求子信息与所述司机服务子信息的第一匹配程度。
4.根据权利要求3所述的方法，其特征在于，所述基于所述第一匹配程度，确定所述用车需求信息分别与所述至少一个司机的第二匹配程度包括：
确定每一个运力参数的权重值；
针对每一个司机，基于每一个运力参数各自对应的第一匹配程度及权重值，计算所述用车需求信息分别与所述每一个司机的第二匹配程度。
5.根据权利要求4所述的方法，其特征在于，所述至少一个运力参数包括服务天数、价格情况、运输情况、搬运情况及服务时长；
对应所述服务天数的用车需求子信息包括用车天数及对应所述服务天数的司机服务子信息包括供车天数；
对应所述价格情况的用车需求子信息包括用户计价及对应所述价格情况的司机服务子信息包括服务价格；
对应所述运输情况的用车需求子信息包括运输路程及对应所述运输情况的司机服务子信息包括最远服务路程；
对应所述搬运情况的用车需求子信息包括需要搬运程度及对应所述搬运情况的司机服务子信息包括可提供搬运程度；
对应所述服务时长的用车需求子信息包括单次运输所需时长及对应所述服务时长的司机服务子信息包括单次运输最大服务时长。
6.根据权利要求5所述的方法，其特征在于，所述针对每一个司机，分别确定对应同一个运力参数的所述用车需求子信息与所述司机服务子信息的第一匹配程度包括：
针对每一个司机，确定对应所述服务天数的所述用车天数与所述供车天数的第一匹配程度；
确定对应所述价格情况的所述用户计价与所述服务价格的第一匹配程度；
确定对应所述运输情况的所述运输里程与所述最远服务里程的第一匹配程度；
确定对应所述搬运情况的所述需要搬运程度与所述可提供搬运程度的第一匹配程度；
确定对应所述服务时长的所述单次运输所需时长与所述单次运输最大服务时长的第一匹配程度。
7.根据权利要求6所述的方法，其特征在于，所述针对每一个司机，基于每一个运力参数各自对应的第一匹配程度及权重值，计算所述用车需求信息分别与所述每一个司机的第二匹配程度包括：
针对所述每一个司机，分别计算每一个运力参数各自对应的第一匹配程度与权重值的乘积，计算获得每一个运力参数分别对应的子匹配值；
针对所述每一个司机，将所述每一个运力参数分别对应的子匹配值求和，分别获得所述每一个司机对应的第二匹配程度。
8.根据权利要求1所述的方法，其特征在于，还包括：
分别获取用户的用户属性信息及所述至少一个司机端的司机属性信息。
9.根据权利要求8所述的方法，其特征在于，根据所述用车需求信息分别与所述至少一个司机的司机服务信息的第一匹配程度，确定满足匹配要求的至少一个中标司机包括：
根据所述用车需求信息分别与所述至少一个司机的司机服务信息的第一匹配程度及所述司机属性信息与所述用户属性信息的第三匹配程度，确定满足匹配要求的至少一个中标司机。
10.根据权利要求1所述的方法，其特征在于，所述用车需求信息包括用户计价子信息；
所述发送所述用车需求信息至至少一个司机端包括：
确定所述用户计价子信息对应的计价模式；
按照所述计价模式发送所述用户计价子信息至所述至少一个司机端，其中，所述用户计价模式包括司机报价、用户一口价、用户按票计价、按重量计价、按件计价。
11.根据权利要求10所述的方法，其特征在于，所述司机服务信息包括服务价格子信息；
所述获取所述至少一个司机端各自发送的司机服务信息包括：
获取所述至少一个司机端各自发送的服务价格子信息；其中，所述每个司机端发送的服务价格子信息由其对应司机基于所述用户计价模式及所述用户计价子信息提供的。
12.根据权利要求11所述的方法，其特征在于，所述用户计价模式为司机报价；所述用户计价子信息为所述用户提供的最低报价信息；
至少一个司机端各自发送的服务价格子信息具体按照以下步骤生成：
所述每个司机在各自的司机端基于所述用户的最低报价信息提供相应的司机报价信息；
根据预设抽佣比例、溢价比例及所述司机报价信息，生成所述每个司机端各自对应的服务价格子信息。
13.根据权利要求11所述的方法，其特征在于，所述用户计价模式为用户一口价；所述用户计价子信息为所述用户提供的用户一口价信息；
至少一个司机端各自发送的服务价格子信息具体按照以下步骤生成：
根据预设抽佣比例、溢价比例及所述用户一口价信息，生成司机一口价信息；
所述每个司机在各自的司机端基于所述司机一口价信息提供是否接受所述司机一口价信息的服务价格子信息。
14.根据权利要求11所述的方法，其特征在于，所述用户计价模式为用户按票计价；所述用户计价子信息为所述用户提供的每票最低价格信息；
至少一个司机端各自发送的服务价格子信息具体按照以下步骤生成：
所述每个司机在各自的司机端基于所述每票最低价格信息提供相应的每票服务价格信息；
根据预设抽佣比例、溢价比例及所述每票服务价格信息，生成所述每个司机端各自对应的服务价格子信息。
15.根据权利要求11所述的方法，其特征在于，所述用户计价模式为按重量计价；所述用户计价子信息为所述用户提供的每吨最低价格信息；
至少一个司机端各自发送的服务价格子信息具体按照以下步骤生成：
所述每个司机在各自的司机端基于所述每吨最低价格信息提供相应的每吨服务价格信息；
根据预设抽佣比例、溢价比例及所述每吨服务价格信息，生成所述每个司机端各自对应的服务价格子信息。
16.根据权利要求11所述的方法，其特征在于，所述用户计价模式为按件计价；所述用户计价子信息为所述用户提供的每件最低价格信息；
至少一个司机端各自发送的服务价格子信息具体按照以下步骤生成：
所述每个司机在各自的司机端基于所述每件最低价格信息提供相应的每件服务价格信息；
根据预设抽佣比例、溢价比例及所述每件服务价格信息，生成所述每个司机端各自对应的服务价格子信息。
17.一种用车匹配装置，其特征在于，包括：
第一获取模块，用于获取用户的用车需求信息；
第一发送模块，用于发送所述用车需求信息至至少一个司机端；
第二获取模块，用于获取所述至少一个司机端各自发送的司机服务信息；其中，每个司机端发送的司机服务信息由其对应司机基于所述用车需求信息提供的；
匹配模块，用于根据所述用车需求信息分别与所述至少一个司机的司机服务信息的第一匹配程度，确定满足匹配要求的至少一个中标司机；
订单生成模块，用于基于所述用车需求信息及所述至少一个中标司机各自对应的司机服务信息，针对每一个中标司机生成相应的用车订单。
18.一种用车匹配设备，其特征在于，包括处理组件和存储组件；所述存储组件存储一条或多条计算机程序指令；所述处理组件用于调用并执行所述一条或多条计算机程序指令以实现：
获取用户的用车需求信息；
发送所述用车需求信息至至少一个司机端；
获取所述至少一个司机端各自发送的司机服务信息；其中，每个司机端发送的司机服务信息由其对应司机基于所述用车需求信息提供的；
根据所述用车需求信息分别与所述至少一个司机的司机服务信息的第一匹配程度，确定满足匹配要求的至少一个中标司机；
基于所述用车需求信息及所述至少一个中标司机各自对应的司机服务信息，针对每一个中标司机生成相应的用车订单。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811434989.1A CN109740843A (zh) | 2018-11-28 | 2018-11-28 | 用车匹配方法、装置及设备 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811434989.1A CN109740843A (zh) | 2018-11-28 | 2018-11-28 | 用车匹配方法、装置及设备 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN109740843A true CN109740843A (zh) | 2019-05-10 |
Family
ID=66359094
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201811434989.1A Pending CN109740843A (zh) | 2018-11-28 | 2018-11-28 | 用车匹配方法、装置及设备 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN109740843A (zh) |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110334980A (zh) * | 2019-05-27 | 2019-10-15 | 天津五八到家科技有限公司 | 拉货订单的工具推荐方法、装置、设备及存储介质 |
| CN110363611A (zh) * | 2019-05-27 | 2019-10-22 | 天津五八到家科技有限公司 | 网约车用户匹配方法、装置、服务器及存储介质 |
| CN110414701A (zh) * | 2019-06-24 | 2019-11-05 | 天津五八到家科技有限公司 | 车辆预订和订单分配方法、设备、系统及存储介质 |
| CN111383046A (zh) * | 2019-12-26 | 2020-07-07 | 武汉物易云通网络科技有限公司 | 一种节约成本快速叫车的运输方案制定方法 |
| CN112418780A (zh) * | 2020-11-02 | 2021-02-26 | 五八到家有限公司 | 家政信息提供方法、服务器和存储介质 |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106022693A (zh) * | 2016-05-27 | 2016-10-12 | 成都嗒嗒创客信息科技有限公司 | 一种货源车源动态智能匹配的实现方法 |
| CN107274133A (zh) * | 2017-06-19 | 2017-10-20 | 上海德启信息科技有限公司 | 一种物流抢单确认中标的方法及物流客服端 |
| CN108122084A (zh) * | 2016-11-28 | 2018-06-05 | 浙江巴巴五网络科技有限公司 | 一种新型物流平台系统 |
-
2018
- 2018-11-28 CN CN201811434989.1A patent/CN109740843A/zh active Pending
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106022693A (zh) * | 2016-05-27 | 2016-10-12 | 成都嗒嗒创客信息科技有限公司 | 一种货源车源动态智能匹配的实现方法 |
| CN108122084A (zh) * | 2016-11-28 | 2018-06-05 | 浙江巴巴五网络科技有限公司 | 一种新型物流平台系统 |
| CN107274133A (zh) * | 2017-06-19 | 2017-10-20 | 上海德启信息科技有限公司 | 一种物流抢单确认中标的方法及物流客服端 |
Cited By (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110334980A (zh) * | 2019-05-27 | 2019-10-15 | 天津五八到家科技有限公司 | 拉货订单的工具推荐方法、装置、设备及存储介质 |
| CN110363611A (zh) * | 2019-05-27 | 2019-10-22 | 天津五八到家科技有限公司 | 网约车用户匹配方法、装置、服务器及存储介质 |
| CN110363611B (zh) * | 2019-05-27 | 2021-08-24 | 天津五八到家科技有限公司 | 网约车用户匹配方法、装置、服务器及存储介质 |
| CN110414701A (zh) * | 2019-06-24 | 2019-11-05 | 天津五八到家科技有限公司 | 车辆预订和订单分配方法、设备、系统及存储介质 |
| CN111383046A (zh) * | 2019-12-26 | 2020-07-07 | 武汉物易云通网络科技有限公司 | 一种节约成本快速叫车的运输方案制定方法 |
| CN111383046B (zh) * | 2019-12-26 | 2024-02-02 | 武汉物易云通网络科技有限公司 | 一种节约成本快速叫车的运输方案制定方法 |
| CN112418780A (zh) * | 2020-11-02 | 2021-02-26 | 五八到家有限公司 | 家政信息提供方法、服务器和存储介质 |
| CN112418780B (zh) * | 2020-11-02 | 2024-05-10 | 五八到家有限公司 | 家政信息提供方法、服务器和存储介质 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109740843A (zh) | 用车匹配方法、装置及设备 | |
| Askalidis et al. | The value of online customer reviews | |
| US10839463B1 (en) | Multiple product quoting | |
| Hendel et al. | The role of leasing under adverse selection | |
| Barroso et al. | Product proliferation strategies and firm performance: The moderating role of product space complexity | |
| Jung et al. | The role of ICT in Korea’s economic growth: Productivity changes across industries since the 1990s | |
| Greene | Export potential for US advanced technology goods to India using a gravity model approach | |
| CN110348963B (zh) | 一种用于交易平台实现多元商品智能交易推荐的方法和系统 | |
| Heydari et al. | Value Added Production in the Company's Electrical Panel Builders West Based on Michael Porter's Value Chain | |
| Maune | Competitive intelligence as an enabler for firm competitiveness: An overview | |
| Smolny | Dynamic factor demand in a rationing context: theory and estimation of a macroeconomic disequilibrium model for the Federal Republic of Germany | |
| CN102129631B (zh) | Spu属性聚合的方法、设备和系统 | |
| CN109300018A (zh) | 一种车辆智能推荐方法、装置、设备及存储介质 | |
| Chen et al. | Optimal inventory control policy for periodic‐review inventory systems with inventory‐level‐dependent demand | |
| Nguyen et al. | Optimal licensing policy under vertical product differentiation | |
| Sokolova et al. | Development of conceptual provisions to effectively manage the activities of a multimodal transport operator | |
| Naumov | Definition of the optimal strategies of transportation market participators | |
| CN110992056B (zh) | 对象的等级服务方法、装置、电子设备及存储介质 | |
| Dong et al. | Profit taxation and the optimal privatisation of state holding corporations | |
| Bauer et al. | Corporate income tax challenges arising from digitalised business models | |
| CN112053087B (zh) | 投诉工单的处理方法、装置、设备及存储介质 | |
| CN107730166A (zh) | 基于无人派送车的快件派送排班方法、装置和存储介质 | |
| Conlin et al. | Strategic delegation and delay in negotiations over the bargaining agenda | |
| Zambroni de Souza et al. | Emerging smart microgrid power systems: Philosophical reflections | |
| Havyatt | The Components of Efficiency |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20190510 |
|
| RJ01 | Rejection of invention patent application after publication |