CN110766505A - 识别紧急订单请求的系统和方法 - Google Patents

识别紧急订单请求的系统和方法 Download PDF

Info

Publication number
CN110766505A
CN110766505A CN201811334228.9A CN201811334228A CN110766505A CN 110766505 A CN110766505 A CN 110766505A CN 201811334228 A CN201811334228 A CN 201811334228A CN 110766505 A CN110766505 A CN 110766505A
Authority
CN
China
Prior art keywords
order
service
order request
request
point
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
Application number
CN201811334228.9A
Other languages
English (en)
Inventor
李海波
仇辉
江梦华
秦宇皓
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Didi Infinity Technology and Development Co Ltd
Original Assignee
Beijing Didi Infinity Technology and Development Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Beijing Didi Infinity Technology and Development Co Ltd filed Critical Beijing Didi Infinity Technology and Development Co Ltd
Priority to CN201811334228.9A priority Critical patent/CN110766505A/zh
Priority to PCT/CN2018/115138 priority patent/WO2020093420A1/en
Publication of CN110766505A publication Critical patent/CN110766505A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G06Q30/0633—Lists, e.g. purchase orders, compilation or processing
    • G06Q30/0635—Processing of requisition or of purchase orders
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/40—Business processes related to the transportation industry

Landscapes

  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Marketing (AREA)
  • General Physics & Mathematics (AREA)
  • Economics (AREA)
  • Engineering & Computer Science (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Development Economics (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Human Resources & Organizations (AREA)
  • Primary Health Care (AREA)
  • Tourism & Hospitality (AREA)
  • Traffic Control Systems (AREA)

Abstract

本申请提供了识别紧急订单请求的系统和方法。所述方法包括：接收来自服务请求者终端的订单请求，所述订单请求的特征至少包括上车点、上车时间和下车点中的一种；通过处理所述订单请求的特征，确定所述订单请求是否为紧急订单请求；响应于所述订单请求为紧急订单请求：将所述订单请求优先分配给一个服务请求者以形成订单；动态调整所述订单的服务费用以及向所述服务请求者终端传递信号，所述信号激发所述服务请求者终端显示包括所述调整的服务费用的订单。所述识别紧急订单的系统和方法能够有效地识别出用户紧急需求的订单，可以针对性地提供服务以提升用户的服务体验。

Description

识别紧急订单请求的系统和方法
技术领域
本申请涉及用于基于机器学习识别模型预测紧急订单请求的人工智能系统和方法。
背景技术
随着互联网技术的发展，线上到线下服务(例如，网约车服务)越来越流行。通过在线服务平台，用户可以通过安装在其移动设备(例如，智能电话)中的应用程序请求线上到线下服务。以网约车服务为例，在线服务平台可以在收到包括上车点和下车点的订单请求后安排服务车辆。在某些情况下，比如用户需要去办理紧急或急迫的事，用户可能希望尽快获得所请求的服务，以便处理一些紧急事项或重要事项(例如去看医生或乘飞机)。类似的紧急订单请求反映了用户急迫的打车需求，如果按照传统的派单模式，可能会造成用户无法及时办理紧急的事项，严重影响了用户打车体验。因此为了能够有效地为具有急迫打车需求的用户提供服务，有必要提供一种能够准确识别紧急订单请求的系统和方法，以便提升用户的打车体验。
发明内容
针对具有急迫服务需求的用户的订单请求，本发明提供了一种能够有效识别出紧急订单请求的系统和方法，可以针对性地为这类用户提供服务，比如优先派单，以提升用户的服务体验。
为达到上述发明目的，本发明提供的技术方案如下：
在本发明的第一方面，提供了一种能够有效识别出紧急订单请求的方法，所述方法包括：接收来自服务请求者终端的订单请求，所述订单请求的特征至少包括上车点、上车时间和下车点中的一种；通过处理所述订单请求的特征，确定所述订单请求是否为紧急订单请求；响应于所述订单请求为紧急订单请求：将所述订单请求优先分配给一个服务提供者以形成订单；动态调整所述订单的服务费用以及向所述服务请求者终端传递信号，所述信号激发所述服务请求者终端显示包括所述调整的服务费用的订单。
在本发明中，所述信号可以进一步激发所述服务请求者终端显示选择信息，以供所述服务请求者选择是否接受所述订单。
在本发明中，可以选择具有最短预估到达时间的可用的服务提供者作为目标服务者，所述最短预估到达时间是指从所述服务提供者的当前位置到所述上车点的最短时间。
在本发明中，可以延迟分配与所述订单请求一起排队的其他订单请求。
在本发明中，通过训练的识别模型来处理所述订单请求的特征，其中所述训练的识别模型利用训练数据训练初始机器学习模型获得，所述训练数据包括多个标记的历史订单。
在本发明中，可以获得与每一标记的历史订单相关联的一个或多个特征；利用所述一个或多个特征训练所述初始机器学习模型以及通过最小化所述模型的目标函数以更新所述模型的一个或多个参数，其中所述目标函数包括损失函数。
在本发明中，所述一个或多个特征至少包括订单时间、上车时间、上车点、下车点、用户画像、出行方式、天气状况、候车时间以及下车点所属的感兴趣点的类型中的一种。
在本发明中，所述用户画像包括一类或多类服务请求者的出行习惯。
在本发明中，所述订单还包括规划路线，所述规划路线为从上车点到下车点的最短预估到达时间对应的路线。
在本发明的第二方面，提供了一种用于识别紧急订单请求的装置，所述装置包括处理器，所述处理器用于执行上述识别紧急订单请求的方法。
在本发明的第三方面，提供了一种计算机可读存储介质，所述存储介质存储计算机指令，当计算机读取存储介质中的计算机指令后，计算机运行上述识别紧急订单请求的方法。
在本发明的第四方面，提供了一种用于识别紧急订单请求的系统。所述系统包括用于存储指令的存储设备以及与所述存储设备进行通信的处理器。当所述处理器执行所述指令时，所述处理器触发所述系统执行：接收来自服务请求者终端的订单请求，所述订单请求的特征至少包括上车点、上车时间和下车点中的一种；通过处理所述订单请求的特征，确定所述订单请求是否为紧急订单请求；响应于所述订单请求为紧急订单请求：将所述订单请求优先分配给一个服务提供者以形成订单；动态调整所述订单的服务费用以及向所述服务请求者终端传递信号，所述信号激发所述服务请求者终端显示包括所述调整的服务费用的订单。
在本系统中，所述信号可以进一步激发所述服务请求者终端显示选择信息，以供所述服务请求者选择是否接受所述订单。
在本系统中，可以选择具有最短预估到达时间的可用的服务提供者作为目标服务者，所述最短预估到达时间是指从所述服务提供者的当前位置到所述上车点的最短时间。
在本系统中，可以延迟分配与所述订单请求一起排队的其他订单请求。
在本系统中，通过训练的识别模型来处理所述订单请求的特征，其中所述训练的识别模型利用训练数据训练初始机器学习模型获得，所述训练数据包括多个标记的历史订单。
在本系统中，可以获得与每一标记的历史订单相关联的一个或多个特征；利用所述一个或多个特征训练所述初始机器学习模型以及通过最小化所述模型的目标函数以更新所述模型的一个或多个参数，其中所述目标函数包括损失函数。
在本系统中，所述一个或多个特征至少包括订单时间、上车时间、上车点、下车点、用户画像、出行方式、天气状况、候车时间以及下车点所属的感兴趣点的类型中的一种。
在本系统中，所述用户画像包括一类或多类服务请求者的出行习惯。
在本系统中，所述订单还包括规划路线，所述规划路线为从上车点到下车点的最短预估到达时间对应的路线。
在本发明的第五方面，提供了另一种用于识别紧急订单请求的系统。所述系统包括采集模块、模型确定模块、订单识别模块、订单分配模块、费用确定模块和传输模块，其中，所述采集模块用于接收来自服务请求者终端的订单请求，所述订单请求的特征至少包括上车点、上车时间和下车点中的一种；所述订单识别模块用于处理所述订单请求的特征，确定所述订单请求是否为紧急订单请求；响应于所述订单请求为紧急订单请求：所述订单分配模块用于将所述订单请求优先分配给一个服务提供者以形成订单；所述费用确定模块用于动态调整所述订单的服务费用以及所述传输模块用于向所述服务请求者终端传递信号，所述信号激发所述服务请求者终端显示包括所述调整的服务费用的订单。
在本发明中，所述系统还包括模型确定模块，所述模型确定模块用于利用所述训练数据训练初始机器学习模型，所述训练数据包括多个标记的历史订单。
本发明的有益效果表现如下：
利用机器学习模型能够有效地识别出紧急订单请求，可以针对性地为具有急迫服务需求的用户提供服务，提升了用户的服务体验。
附图说明
本申请将结合示例性实施例进一步描述。所述示例性实施例可以结合附图进行详细描述。所述附图并非按比例绘制。所述实施例是非限制性的示例性实施例，其中在附图的多个视图中相同的附图标记表示相同的结构，其中：
图1是根据本申请的一些实施例所示的线上到线下(O2O)服务系统的示意图；
图2是根据本申请一些实施例所示的计算设备的组件的示意图；
图3是根据本申请的一些实施例所示的移动设备的示例性硬件和/或软件组件的示意图；
图4是根据本申请的一些实施例所示的处理设备的示意图；
图5是根据本申请的一些实施例所示的用于识别紧急订单请求的示例性过程的流程图；
图6是根据本申请的一些实施例所示的用于训练机器学习识别模型的示例性过程的流程图；
图7A和7B是根据本申请的一些实施例所示的示例性机器学习识别模型的示意图；以及
图8是根据本申请的一些实施例所示的呈现服务请求的示例性用户界面的示意图。
具体实施方式
为了更清楚地说明本申请的实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单的介绍。显而易见地，下面描述中的附图仅仅是本申请的一些示例或实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图将本申请应用于其他类似情景。应当理解，给出这些示例性实施例仅仅是为了使相关领域的技术人员能够更好地理解进而实现本申请，而并非以任何方式限制本申请的范围。除非从语言环境中显而易见或另做说明，图中相同标号代表相同结构或操作。
如本申请和权利要求书中所示，除非上下文明确提示例外情形，“一”、“一个”、“一种”和/或“该”等词并非特指单数，也可包括复数。一般说来，术语“包括”与“包含”仅提示包括已明确标识的步骤和元素，而这些步骤和元素不构成一个排它性的罗列，方法或者设备也可能包含其他的步骤或元素。
根据本申请的一些实施例，系统中的一些模块指的是各种方式的模块。然而，任何数量的不同模块都可以被使用，并在客户终端和/或服务器上运行。这些模块旨在是说明性的，而不旨在限制本申请的范围。不同的模块可以用于系统以及方法的不同方面。
根据本申请的一些实施例，使用流程图来说明通过系统所执行的操作。应当理解的是，前面或下面操作不一定按照顺序来精确地执行。相反，可以按照倒序或同时处理各种步骤。同时，也可以将其他操作添加到这些过程中，或从这些过程移除某一步或数步操作。虽然本申请的系统和方法的描述主要关于分配交通运输服务请求，应该理解的是，这只是一个示例性的实施例。本申请的实施例可以应用于任何其他类型的线上到线下服务，比如交通服务系统、餐饮服务系统、家政服务系统、医药服务系统等中的一种或多种。以下描述以交通服务系统为例。所述交通服务系统的车辆可以包括出租车、私家车、顺风车、公交车、列车、子弹列车、高铁、地铁、船舶、飞机、飞船、热气球、无人驾驶车辆或类似或其任意组合。所述交通服务系统也可以包括应用管理和/或分配的任一服务系统，例如，传送和/或接收快递的系统。本申请所描述的系统和方法的应用场景可以包括网页、浏览器插件、客户端、定制系统、企业内部分析系统、人工智能机器人等或上述举例的任意组合。
本申请中的术语“乘客”，“请求者”，“服务请求者”和“客户”可互换使用，以指代请求订单服务的个人，实体或工具。同样地，本申请中的术语“司机”和“服务提供者”可互换使用，以指代提供订单请求服务的个人，实体或工具。
在本申请中使用的定位技术可以包括全球定位系统(GPS)、全球卫星导航系统(GLONASS)、北斗导航系统(COMPASS)、伽利略定位系统、准天顶卫星系统(QZSS)、无线保真(WiFi)定位技术或类似物或其任意组合。
图1是根据本申请的一些实施例所示的线上到线下(O2O)服务系统的示意图。所述O2O服务系统100可以是用于数据和/或信息处理的平台，例如，处理来自服务请求者的订单请求。在一些实施例中，所述O2O服务系统100可以包括用于处理订单请求的人工智能(AI)系统，例如，识别实时订单请求是否是紧急订单请求。在一些实施例中，该服务可以是交通运输服务，例如叫车服务，司机代驾服务，租车服务，拼车服务等。在一些实施例中，该服务可以是任何在线服务，例如订餐，购物等或其任何组合。
所述O2O服务系统100可以包括信息交换端口系统，其包括第一信息交换端口101和第二信息交换端口102、服务器110、存储设备120、请求者终端130、提供者终端140。所述服务器110包括处理设备112。在一些实施例中，所述O2O服务系统100可以分别通过第一信息交换端口101和第二信息交换端口102与一个或多个服务请求者或一个或多个服务提供者通信。例如，所述服务器110可以通过第一信息交换端口101从服务请求者终端接收与订单请求有关的信息和/或数据。又例如，所述服务器110可以通过第二信息交换端口102从服务提供者终端访问信息和/或数据。又例如，所述服务器110可以通过信息交换端口系统将信息和/或数据发送到服务请求者终端或服务提供者终端。在一些实施例中，所述信息交换端口系统，比如，第一信息交换端口101和第二信息交换端口102，可以集成到单个设备上，也可以是不同设备的单独部分。例如，所述第一信息交换端口101集成到请求者终端130上，所述第二信息交换端口102集成到提供者终端140上。
在一些实施例中，所述服务器110可以是单个服务器或服务器组。服务器组可以是集中式或分布式的(例如，服务器110可以是分布式系统)。在一些实施例中，所述服务器110可以实施在云端平台上。仅作为示例，所述云平台可以包括私有云、公共云、混合云、小区云、分布云、跨云、多云等或上述举例的任意组合。在一些实施例中，所述服务器110也可以在图2中所描述的包含了一个或者多个组件的计算设备上执行。
在一些实施例中，所述服务器110进一步包括处理设备112。所述处理设备112可以处理与订单请求相关联的信息和/或数据，以进一步执行在本申请中描述的一个或者多个功能。例如，所述处理设备112可以通过第一信息交换端口101从服务请求者终端获得订单请求，并通过处理订单请求的特征来确定订单请求是否是紧急订单请求。又例如，如果订单请求被识别为紧急订单请求，所述处理设备112可以将该订单请求优先分配给服务提供者。在一些实施例中，所述处理设备112可以包括一个或多个处理器(例如，单芯片处理器或多芯片处理器)。仅作为示例，所述处理设备112可以包括中央处理单元(CPU)、特定应用集成电路(ASIC)、特定应用指令集处理器(ASIP)、图形处理单元(GPU)、物理处理单元(PPU)、数字信号处理器(DSP)、现场可程序门阵列(FPGA)、可程序逻辑设备(PLD)、控制器、微控制器单元、精简指令集计算机(RISC)、微处理器等，或其任意组合。
所述存储设备120可以存储数据和/或指令。在一些实施例中，所述存储设备120用来存储从请求者终端130和/或提供者终端140获得/取得的数据。在一些实施例中，所述存储设备120可以存储供服务器110执行或使用的数据和/或指令，以实施本申请中描述的示例性方法和/或过程。在一些实施例中，所述存储设备120可以包括大容量存储器、可移动存储器、挥发性读写内存、只读存储器(ROM)等或其任意组合。示例性的可移动存储器可以包括快闪驱动器、软盘、光盘、记忆卡、压缩碟、磁带等。示例性的挥发性只读存储器可以包括随机存取内存(RAM)。示例性的随机存取内存可以包括动态随机存取内存(DRAM)、双倍速率同步动态随机存取内存(DDR SDRAM)、静态随机存取内存(SRAM)、闸流体随机存取内存(T-RAM)和零电容随机存取内存(Z-RAM)等。示例性的只读存储器可以包括掩蔽型只读存储器(MROM)、可程序只读存储器(PROM)、可清除可程序只读存储器(EPROM)、电子可抹除可程序只读存储器(EEPROM)、压缩盘只读存储器(CD-ROM)和数字通用磁盘只读存储器等。在一些实施例中，所述存储设备120可以实施在云端平台上。仅作为示例，所述云端平台可以包括私有云、公用云、混合云、小区云、分布式云、内部云、多层云等或其任意组合。
在一些实施例中，所述存储设备120可以连接到服务器110或与服务器110通信。例如，服务器110可以通过网络访问存储在存储设备120中的信息和/或数据。在一些实施例中，所述存储设备120还可以是服务器110的一部分。
在一些实施例中，服务请求者可以是请求者终端130的用户。在一些实施例中，请求者终端130的用户也可以为除该请求者之外的其他人。例如，请求者终端130的用户A可以通过请求者终端130为用户B发送服务请求，或从服务器110处接收服务和/或信息或指令。在一些实施例中，服务提供者可以是提供者终端140的用户。在一些实施例中，提供者终端130的用户可以为除该提供者之外的其他人。例如，提供者终端140的用户C可以使用提供者终端140来接收用户D的订单请求，和/或来自服务器110的信息或指令。在本申请中，“请求者”和“请求者终端”可以互换使用，“用户”和“用户终端”可以互换使用，“提供者”和“提供者终端”可以互换使用。对于交通服务来说，请求者可以是乘客，提供者可以是司机。
在一些实施例中，所述请求者终端130可以包括移动设备130-1、平板计算机130-2、膝上型计算机130-3、车载内置装置130-4等或其任意组合。在一些实施例中，移动设备130-1可以包括智能家居装置、可穿戴装置、智能移动装置、虚拟现实装置、增强现实装置或类似物或其任意组合。在一些实施例中，智能家居装置可以包括智能照明设备、智能电器的控制设备、智能监控设备、智能电视、智能摄像机、对讲机等或其任意组合。在一些实施例中，可穿戴装置可以包括智能手环、智能鞋袜、智能眼镜、智能头盔、智能手表、智能衣物、智能背包、智能配饰等或其任意组合。在一些实施例中，智能移动装置可以包括移动电话、个人数字助理、游戏设备、导航装置、POS机、膝上型计算机、台式计算机等或其任意组合。在一些实施例中，虚拟现实装置和/或增强现实装置可以包括虚拟现实头盔、虚拟现实眼镜、虚拟现实眼罩、增强现实头盔、增强现实眼镜、增强现实眼罩等或其任意组合。例如，该虚拟现实装置和/或增强现实装置可以包括GoogleTMGlass、Oculus Rift、HoloLens或Gear VR等。在一些实施例中，车载内置装置可以包括车载计算机或车载电视等。在一些实施例中，请求者终端130可以是具备定位技术(例如，GPS)的设备，用于定位请求者和/或请求者终端130的位置。
在一些实施例中，所述提供者终端140可以是与请求者终端130类似或相同的设备。在一些实施例中，提供者终端140可以是具备定位技术的装置，以定位提供者终端140的使用者(例如，服务提供者)和/或提供者终端140的位置。在一些实施例中，请求者终端130和/或提供者终端140可以与一个或多个其他定位设备通信以确定请求者和/或请求者终端130，提供者和/或提供者终端140的位置。在一些实施例中，请求者终端130和/或提供者终端140可以向服务器110发送定位信息。在一些实施例中，请求者终端130和/或提供者终端140可以显示与订单请求相关的信息(例如，上车点、下车点、路线)。
在一些实施例中，每一服务提供者可以对应于车辆150。所述车辆150可以携带乘客并前往目的地。每一车辆可以对应一种类型的服务(例如，出租车呼叫服务、代驾服务、快车服务、拼车服务、公交车服务、司机代驾服务或接送服务)。
定位系统160可以确定与对象或目标相关联的信息，例如，一个或多个服务请求者、一个或多个服务提供者、一个或多个车辆的相关信息。在一些实施例中，所述定位系统160可以是全球定位系统(GPS)，全球导航卫星系统(GLONASS)、罗盘导航系统(COMPASS)、北斗导航卫星系统、伽利略定位系统、准天顶卫星系统(QZSS)等。所述确定的信息可包括目标对象的位置、高度、速度或加速度或当前时间。所述定位系统160可以包括一个或多个卫星，例如卫星160-1、卫星160-2和卫星160-3。所述卫星160-1至160-3可以独立地或共同地确定上述所述信息。所述定位系统160可以通过无线连接将上述信息发送到请求者终端130，提供者终端140或车辆150。在一些实施例中，定位系统170可以直接将信息发送到服务器110。
网络170-1至170-3可以用于交换信息和/或数据。在一些实施例中，所述O2O服务系统100中的一个或多个组件(例如，服务器110和/或存储设备120)可以通过网络170-1至170-3向/从请求者终端130发送和/或接收信息和/或数据和/或提供者终端140。例如，服务器110可以通过网络170-1获得与服务请求有关的数据。又例如，服务器110可以通过网络170-2获得服务提供者的可用状态。在一些实施例中，网络170-1至170-3可以是任何类型的有线或无线网络，或其组合。仅作为示例，网络170可以包括缆线网络、有线网络、光纤网络、远程通信网络、内部网络、互联网、局域网络(LAN)、广域网路(WAN)、无线局域网络(WLAN)、城域网(MAN)、公共开关电话网络(PSTN)、蓝牙网络、无线个域网、近场通讯(NFC)网络、全球行动通讯系统(GSM)网络、码分多址(CDMA)网络、时分多址(TDMA)网络、通用分组无线服务(GPRS)网络、增强数据速率GSM演进(EDGE)网络、宽带码分多址接入(WCDMA)网络、高速下行分组接入(HSDPA)网络、长期演进(LTE)网络、用户数据报协议(UDP)网络、传输控制协议/互联网协议(TCP/IP)网络、短讯息服务(SMS)网络、无线应用协议(WAP)网络、超宽带(UWB)网络、红外线等中的一种，或类似或其任意组合。
图2是根据本申请一些实施例所示的计算设备的组件的示意图。根据本申请的一些实施例，所述服务器110、存储设备120、请求者终端130和/或提供者终端140可以实施在计算设备200上。本实施例中的特定系统利用功能框图表示包含用户界面的硬件平台。这种计算机可以是通用计算机，也可以是有特定功能的计算机。这两种类型的计算机都可以被配置用于实现本申请的一些实施例中的任一特定系统。所述计算设备200可以被配置用于实现执行本申请中公开的一个或多个功能的任何组件。例如，所述计算设备200可实施如本申请所描述的线上到线下服务系统100的任何组件。在图1和图2中，仅示意出了一台类似的计算设备。对于普通技术人员可以理解，与所述的请求服务相关的计算机功能可以在多个类似的平台上以分布式方式实现，以分散处理负荷。
所述计算设备200可以包括与网络相连接并促进数据通讯的通讯(COM)端口250。所述计算设备200还包括处理器(处理器220),可以以一个或多个处理器(逻辑电路)的形式执行程序指令。例如，所述处理器可以包括接口电路和处理电路。所述接口电路用于从总线210接收电信号，其中电信号可以编码成用于处理电路处理的结构数据和/或指令。所述处理电路可以进行逻辑计算，然后判断结论、结果，并将其计算结果编码为电信号。然后所述接口电路可以通过总线210发送处理电路发出的电信号。
典型的计算设备包括内部通信总线210、程序内存和不同形式的数据存储器，例如，磁盘270、和只读存储器(ROM)230或随机存取内存(RAM)240，所述计算设备可以处理和/或传输多种数据文件。典型的计算设备还可以包括能够被处理器220执行的程序指令，所述程序指令储存于ROM 230、RAM 240和/或其他形式的非暂时性存储介质中。本申请公开的方法和/或过程都可以作为程序指令来实施。典型的计算设备200还包括输入/输出(I/O)组件260，所述I/O组件260可用于计算机和其他元件的输入/输出。所述计算设备200可以通过网络通讯接收程序和数据。
作为示例，图2仅示出了一个CPU和/或处理器用于说明。多个CPU和/或处理器也可以被采用，因此，如本申请所述的由单个CPU和/或处理器执行的操作和/或方法的步骤也可以由多个CPU和/或处理器共同或单独执行。例如，在本申请中，如果所述计算设备200的中央处理单元CPU和/或处理器执行步骤A和步骤B，应当理解的是，步骤A和步骤B也可以由所述计算设备200的两个不同的中央处理单元和/或处理器共同或单独执行(例如，第一处理器执行步骤A，第二处理器执行步骤B，或者第一处理器和第二处理器共同执行步骤A和B)。
图3是根据本申请的一些实施例所示的移动终端的硬件和/或软件组件示意图。如图3所示，所述移动设备300包括通信模块310、显示器320、图形处理器(GPU)330、中央处理器(CPU)340、输入/输出350、内存360、存储器390。所述CPU 340可以包括类似于处理器220的接口电路以及处理电路。在一些实施例中，任何其他合适的组件，包括但不限于系统总线或控制器(未示)，亦可包括于移动设备300内。在一些实施例中，移动操作系统370(如，iOSTM，AndroidTM，Windows PhoneTM)和应用程序380可以从所述存储器390加载到内存360中便于CPU 340执行。所述应用程序380包括用于将与服务请求或其他信息发送到服务器110的浏览器或任何其他合适的移动应用程序。用户交互信息可以通过输入/输出350完成，并通过网络提供给处理设备112和/或系统100的其他组件。
为了实现不同的模块、单元以及上述其他功能，计算机硬件平台可以被用作一个或多个组件的硬件平台(例如，图1所示的服务器110的组件)。由于所述计算机的硬件组件、操作系统和程序语言是常见的，所以可假设本领域技术人员能够知晓这些技术，并且能够根据本申请所述的技术提供用于订单识别的信息。带有用户界面的计算机可以是个人计算机(PC)，或其他类型的工作站或终端设备。经适当编程后，可以将带有用户界面的计算机作为服务器。应当知道的是，可以认为本领域技术人员知晓，诸如结构、程序，或这类计算设备的一般操作。因此，上述附图并未描述其他的解释。
图4是根据本申请的一些实施例所示的处理设备的示意图。所述处理设备112包括采集模块410、模型确定模块420、订单识别模块430、订单分配模块440、费用确定模块450和传输模块460。这些模块可以是处理设备112的至少一部分的硬件电路。这些模块也可以作为应用程序或由处理设备112读取或执行的指令实现。此外，这些模块可以是硬件电路和应用/指令的任何组合。例如，当处理设备执行应用程序/指令时，这些模块可以是处理设备112的一部分。
所述采集模块410可以通过信息交换端口(例如，第一信息交换端口101)从请求者终端130接收用户请求。所述订单请求可以包括实时订单或预约订单。所述采集模块410可以提取所述订单请求的特征，以及将所述提取的特征传递给订单识别模块430用于识别所述订单请求是否为紧急订单请求。所述订单请求的特征可以至少包括上车点、上车时间和下车点中的一种。所述紧急订单请求可以是指暗示或指示用户具有急迫服务需求(比如，打车服务)的订单请求。在一些实施例中，所述紧急订单请求可以是指要求到某一目的地具有特定截止时间的订单请求。在一些实施例中，所述紧急订单请求可以是指与请求者的某些重要事项相关的订单请求。例如，为了尽可能快地就医，病人可以发送从家到医院的打车服务请求，所述打车服务请求可视为紧急订单请求。该服务请求暗示了服务请求者具有急迫的打车需求。
所述采集模块410可以用于获取多个历史订单。所述多个历史订单可以包括第一部分标记的紧急订单和第二部分标记的非紧急订单。其中，紧急订单可以标记为“1”，非紧急订单可以标记为“0”。所述历史订单可以包括过去某一时间段的订单，比如三天、一周、一个月、半年或一年等。所述采集模块410可以进一步提取所述历史订单的特征。在一些实施例中，所述历史订单的特征可以包括但不限于订单请求时间、上车时间、上车点、下车点、下车点所属的感兴趣点(POI)类型、用户画像、出行方式、天气状况、候车时间等。
所述模型确定模块420可以从所述采集模块410获得所述提取的历史订单的特征，并利用所述提取的历史订单的特征训练初始的机器学习识别模型(即，待训练的机器学习模型)。根据不同的训练目标可以预设相应的机器学习模型。例如，所述机器学习模型可以是基于分类的模型，也可以是基于回归的模型。优选地，所述模型为基于分类的模型。对于初始的机器学习识别模型来说，模型的参数可以基于所述提取的历史订单的特征进行训练或优化。典型的机器学习识别模型可以包括Xgboost(Extreme Gradient Boosting)模型、决策树模型、GBDT(Gradient Boosted Decision Tree)模型、神经网络模型等。在一些实施例中，所述机器学习识别模型为Xgboost模型。所述Xgboost模型包括一个或多棵树。每一棵树包括多个节点，比如根节点和叶节点。
在训练过程中，所述模型确定模块420可以基于所述提取的历史订单的特征生成一棵或多棵树(例如，图7A或图7B所示)。对于每一棵树来说，所述模型确定模块420首先确定一个根节点，所述根节点对应于第一特征(例如，图7A所示的根节点711或图7B所示的根节点721)。所述模型确定模块420可以基于不同的特征分裂所述根节点以形成多个叶节点(例如，叶节点712-1和712-2)。所述模型确定模块420可以进一步分裂所述叶节点以形成完整的树。所述模型确定模块420可以通过最小化目标函数来更新所述初始机器学习识别模型的参数。对于Xgboost模型来说，所述参数可以包括每棵树的结构和/或每个叶节点的权重值等。在一些实施例中，所述目标函数包括损失函数项和正则化项，如等式(1)所示。所述模型确定模块420可以通过加项训练的方法来最小化所述目标函数。关于训练所述识别模型的细节可以参考本申请中的其他部分，例如图6、图7A和图7B的描述。
所述订单识别模块430可以确定一个订单请求是否为紧急订单请求。具体地，所述订单识别模型430可以通过处理所述订单请求的特征来判断所述订单请求是否为紧急订单请求。所述订单识别模块430可以提取与所述订单请求相关的特征，比如上车时间、上车点或下车点等，并将所述特征输入到训练好的识别模型。所述识别模型可以预测该订单请求为紧急订单请求的概率。所述订单识别模块430可以根据所述预测的概率进一步判断所述订单请求是否为紧急订单请求。例如，如果所述预测的概率大于等于预设的阈值(比如，0.5、0.6、0.7、0.8、0.9等)，所述订单识别模块430可以将所述订单请求识别为紧急订单请求。相反地，所述订单请求被识别为非紧急订单请求。
在一些实施例中，如果所述订单请求被识别为紧急订单请求，所述订单分配模块440可以将所述订单请求优先分配给一个服务提供者以形成订单(即，将所述订单请求与服务提供者配对)。相比于非紧急订单请求，所述紧急订单请求被优先分配给服务提供者。例如，假设非紧急订单请求和紧急订单请求同时在排队等候服务器110分配服务提供者，所述订单分配模块440可以优先分配所述紧急订单请求，延迟分配同队列的非紧急订单请求。又例如，假设有多个紧急订单在排队，所述订单分配模块440可以将所述多个紧急订单请求插队分配，并按照对应的预测概率对所述紧急订单请求排序，按照排队序列分配所述紧急订单请求。在一些实施例中，所述生成的订单还包括规划路线，所述规划路线为从上车点到下车点的最短预估到达时间(ETA)的路线。
在一些实施例中，如果所述订单请求被识别为紧急订单请求，所述费用确定模块450可以动态调整订单的服务费用。在一些实施例中，所述服务费用也可以不调整。在一些实施例中，相比于具有相同上车点和下车点的非紧急订单，所述费用确定模块450可以将紧急订单的服务费用调高。在一些实施例中，只有当其他非紧急订单被延迟派单时，所述费用确定模块450才将紧急订单的服务费用调高。在一些实施例中，服务费用的上涨取决于紧急订单请求的预测概率。
所述传输模块460可以通过所述信息交换端口系统(例如，第一信号交换端口101)给所述服务请求者终端(例如，请求者终端130)传递信号，所述信号可以激发所述服务请求者终端显示包括所述调整的服务费用的订单。例如，所述订单可以显示在请求者终端130用户界面上(例如，图8所示的用户界面800)。在一些实施例中，所述信号可以激发所述请求者终端130显示选择信息以供请求者确认该订单为紧急请求订单是否准确。在一些实施例中，所述信号可以激发所述服务请求者终端显示选择信息以供所述服务请求者选择是否接受所述订单。在一些实施例中，所述信号可以激发所述服务请求者终端显示选择信息以供所述请求者选择是否接受该订单的动态价格模式。可以理解的是，所述订单和/或选择信息可以通过各种方式显示，比如，短信、音频、视频、图像等。所述请求者也可以通过各种方式来确认所述订单和/或选择信息，比如，短信、音频、视频、图像等。
在一些实施例中，所述传输模块460可以基于任意适用的通信协议传输所述信号。典型的通信协议可以包括但不限于超文本传输协议(HTTP)、地址分别协议(ARP)、动态主机配置协议(DHCP)、文件传送协议(FTP)等。应当知道的是所述信号可以是有线信号也可以是无线信号。
图5是根据本申请的一些实施例所示的用于识别紧急订单请求的示例性过程的流程图。在一些实施例中，所述O2O服务系统100可以实施如图5所示的过程500。例如，所述过程500可以以指令的形式存储在存储设备120和/或存储器(例如，ROM 230，RAM 240或存储器390)中，并且由服务器110(例如，处理设备112或者处理器220)调用和/或执行。
在步骤502中，处理器(例如，处理设备112中的采集模块410)可以从服务请求者终端(例如，请求者终端130)接收订单请求。所述订单请求可以包括实时订单请求或预约订单请求。例如，所述实时订单请求可以是要求服务提供者立即或在合理地接近请求时间的特定时间段内(例如，1分钟、2分钟、3分钟等)执行服务的请求。预约订单请求可以是要求服务提供者在指定时间(例如，一小时后的某个时刻)内执行服务的请求。
在一些实施例中，服务请求者通过安装在请求者终端130中的应用程序发送用于交通服务的订单请求，处理器可以通过与请求者终端130通信的第一信息交换端口101接收该订单请求。所述订单请求包括一个或多个特征，比如，上车点、上车时间和/或下车点。采集模块410可以提取所述一个或多个特征，并将所述一个或多个特征发送到订单识别模块430以识别订单请求是否是紧急订单请求。所述紧急订单请求可以是指暗示或指示用户具有急迫服务需求(比如，打车服务)的订单请求。在一些实施例中，所述紧急订单请求可以是指要求到某一目的地具有特定截止时间的订单请求。在一些实施例中，所述紧急订单请求可以是指与请求者的某些重要事项相关的订单请求。例如，为了尽可能快地就医，病人可以发送从家到医院的打车服务请求，所述打车服务请求可视为紧急订单请求。该服务请求暗示了服务请求者具有急迫的打车需求。
在一些实施例中，安装在请求者终端130上的应用程序可以用来检测用户输入。在一些实施例中，所述订单请求可以是未发送的部分输入请求或未发送的完整请求。这种尚未发送的订单请求也可以触发如本申请中所示的过程(例如，图5中所示的过程500)。
在步骤504中，处理器(例如，处理设备112中的订单识别模块430)可以确定所述订单请求是否是紧急订单请求。更具体地，处理器可以通过训练好的识别模型处理所接收的订单请求的特征来确定订单请求是否是紧急请求。
在一些实施例中，处理器可以提取所述订单请求的一个或多个特征，并将所述提取的特征输入到训练好的识别模型中。所述识别模型可以预测该订单请求为紧急订单请求的概率。所述订单识别模块430可以根据所述预测的概率进一步判断所述订单请求是否为紧急订单请求。例如，如果所述预测的概率大于等于预设的阈值(比如，0.5、0.6、0.7、0.8、0.9等)，所述订单识别模块430可以将所述订单请求识别为紧急订单请求。相反地，所述订单请求被识别为非紧急订单请求。在一些实施例中，所述预设的阈值可以根据不同的场景和不同的目标来调整。例如，如果处理器检测到下车点是服务请求者(例如，工作场所)的经常访问的地方，则可以将预设的阈值调高。又例如，如果处理器检测到下车点是服务请求者不经常访问的地方，则可以将预定阈值调低。对于本领域技术人员可知，所述预设的阈值可以是变化的，并且这些变化均应在本申请的保护范围内。
所述训练好的模型可以利用训练数据训练初始机器学习识别模型生成。所述训练数据包括多个标记的历史订单。所述多个标记的历史订单包括第一部分标记的紧急订单和第二部分标记的非紧急订单。在一些实施例中，所述紧急订单和非紧急订单可分别用二进制值标记。例如，紧急订单可以标记为“1”，非紧急订单可以标记为“0”。
在一些实施例中，所述机器学习识别模型可以包括Xgboost(Extreme GradientBoosting)模型、决策树模型、GBDT(Gradient Boosted Decision Tree)模型、神经网络模型等。可选地，所述机器学习模型可以是包括一棵或多棵树的Xgboost模型(例如，图7A或图7B中所示的树)。处理器可以基于与多个历史订单相关联的一个或多个特征来训练一棵或多棵树。每棵树可以包括一个或多个节点，例如根节点或叶节点。在训练过程中，处理器可以通过最小化目标函数来更新模型的一个或多个参数。所述目标函数可以基于损失函数项和/或正则化项来构造。在一些实施例中，所述一个或多个参数可以包括每棵树的结构、每个叶节点的权重值等。当目标函数最小化时，更新的一个或多个参数对于识别模型可能是最佳的。直到目标函数最小化后，训练过程可以结束。关于如何训练识别模型的细节可以参考本申请的其他地方(例如，图6或图7A-7B及其描述)。
在步骤506中，如果订单请求被确定为紧急订单请求，处理器(例如，订单分配模块440)可以将所述订单请求优先分配给服务提供者以形成订单(即，将所述订单请求与服务提供者配对)。相比于非紧急订单请求，所述紧急订单请求被优先分配给服务提供者。例如，假设非紧急订单请求和紧急订单请求同时在排队等候服务器110分配服务提供者，所述订单分配模块440可以优先分配所述紧急订单请求，延迟分配同队列的非紧急订单请求。又例如，假设有多个紧急订单在排队，所述订单分配模块440可以将所述多个紧急订单请求插队分配，并按照对应的预测概率对所述紧急订单请求排序，按照排队序列分配所述紧急订单请求。
在一些实施例中，处理器(例如，订单分配模块440)可以将紧急订单请求分配给目标服务提供者。更具体地，处理器可以搜索在第一距离阈值内能够提供交通服务的一个或多个服务提供者。所述第一距离阈值可以是任意预设距离，例如，3千米、4千米、5千米等。在优选实施例中，所述第一距离阈值为3千米。处理器可以获得从每个可用服务提供者的当前位置到达上车点的预估到达时间(ETA)。处理器可以选择具有最短ETA的可用服务提供者作为目标服务提供者。在一些实施例中，如果在第一距离阈值内没有可用的服务提供者，则处理器可以动态地将第一距离阈值调整到第二距离阈值。所述第二距离阈值大于第一距离阈值。处理器可以在第二距离阈值内选择目标服务提供者。在一些实施例中，处理器可以根据不同的情景动态调整所述距离阈值，例如，雨天、高峰时段(例如，上午7：00至9：30，或下午5：00至7：00)。
在一些实施例中，所述生成的订单还包括规划路线，所述规划路线为从上车点到下车点的最短ETA的路线。处理器可以规划从上车点到下车点的一条或多条路线，并获得与一条或多条路线相对应的ETA。处理器可以指定具有最短ETA的路线作为显示的路线。
在步骤508中，如果所述订单请求被识别为紧急订单请求，处理器(例如，处理设备112中的费用确定模块450)可以动态地调整订单的服务费用。在一些实施例中，所述服务费用也可以不调整。在一些实施例中，相比于具有相同上车点和下车点的非紧急订单，所述费用确定模块450可以将紧急订单的服务费用调高。在一些实施例中，只有当其他非紧急订单被延迟派单时，所述费用确定模块450才将紧急订单的服务费用调高。在一些实施例中，服务费用的上涨取决于紧急订单请求的预测概率。例如，假设设定的预设阈值是0.5，则大于等于0.5且小于0.75的预测概率可以被分类为“低紧急”级别，大于或等于0.75且小于0.90的预测概率可以被分类为“中紧急”级别，大于或等于0.90的预测概率可以被分类为“高紧急”级别。在一些实施例中，对应于“低紧急”级别的订单的服务费用可能上涨30％，对应于“中紧急”级别的订单的服务费用可能上涨40％，对应于“高紧急”级别的订单的服务费用可能上涨50％。应当知晓的是，所述分类的紧急级别可能反映了所述订单请求为紧急订单请求的可能性，但不一定为绝对的紧急。另外，服务费用的紧急级别和费用调整规则可以是各种各样的，并且这种变化均应在本申请的保护范围内。
在步骤510中，处理器(例如，所述处理设备112中的传输模块460)可以通过信息交换端口系统(例如，第一信号交换端口101)给所述服务请求者终端(例如，请求者终端130)传递信号，所述信号可以激发所述服务请求者终端显示包括所述调整的服务费用的订单。例如，所述订单可以显示在请求者终端130用户界面上(例如，图8所示的用户界面800)。在一些实施例中，所述信号可以激发所述请求者终端130显示选择信息以供请求者确认该订单为紧急请求订单是否准确。如果服务请求者确认该订单请求不是紧急请求订单，处理器则对所述订单请求执行正常分配，而非优先分配。如果服务请求者确认该订单请求是紧急请求订单，处理器则优先分配所述订单请求和/或相应调整所述订单费用。
在一些实施例中，所述信号可以激发所述服务请求者终端显示选择信息以供所述服务请求者选择是否接受所述订单。例如，如图8所示，所述信号可以激发所述请求者终端130以用户界面上的弹出框的形式(例如，弹出框802)显示选择信息。仅用作示例，显示的选择信息是“是否接受动态价格模式？”。动态价格模式意味着处理器可以动态调整订单请求的服务费用。如果服务请求者接受此模式，他/她可以通过按下“接受”按钮804来确认所述选择信息。如果服务请求者不接受此模式，他/她可以通过按下“不接受”按钮806来拒绝所述选择信息。可以理解的是，所述订单和/或选择信息可以通过各种方式显示，比如，短信、音频、视频、图像等。所述请求者也可以通过各种方式来确认所述订单和/或选择信息，比如，短信、音频、视频、图像等。
在一些实施例中，处理器在收到服务请求者的答复后，处理器还可以通过信息交换端口系统(例如，第二信息交换端口102)将答复信息发送给服务提供者，然后服务提供者可以通过提供者终端140操作所述订单。例如，服务提供者可以通过电话呼叫，消息或叫车服务应用中的对话框向服务请求者发送关于订单的信息。
在一些实施例中，处理器可以基于任意适用的通信协议传输所述信号。典型的通信协议可以包括但不限于超文本传输协议(HTTP)、地址分别协议(ARP)、动态主机配置协议(DHCP)、文件传送协议(FTP)等。应当知道的是所述信号可以是有线信号也可以是无线信号。
应当知道的是，以上关于过程500的描述仅出于说明性目的，并不旨在限制本申请的范围。对于本领域的普通技术人员来说，可以根据本申请的描述，做出各种各样的修正和改变。例如，步骤506和步骤508可以集成到单个步骤中。又例如，可以省略步骤508，处理器可以不发送关于紧急订单请求的服务费用的动态调整的选择信息。然而，这些变化与修改仍应在本申请的保护范围内。
图6是根据本申请的一些实施例所示的用于训练机器学习识别模型的示例性过程的流程图。例如，过程600可以以指令的形式存储在存储设备120和/或存储器(例如，ROM230，RAM 240或存储器390)中，并且由服务器110(例如，处理设备112或处理器220)调用和/或执行。
在602中，处理器(例如，处理设备112中的采集模块410)可以获得与每个标记的历史订单相关联的一个或多个特征。所述历史订单可以包括第一部分标记的紧急订单和第二部分标记的非紧急订单。其中，紧急订单可以标记为“1”，非紧急订单可以标记为“0”。所述历史订单可以包括过去某一时间段的订单，比如三天、一周、一个月、半年或一年等。处理器可以进一步提取每一历史订单的特征。在一些实施例中，所述历史订单的特征可以包括但不限于订单请求时间、上车时间、上车点、下车点、下车点所属的感兴趣点(POI)类型、用户画像、出行方式、天气状况、候车时间等。
所述订单请求时间可以被划分到某一时间段内，例如，高峰时段或非高峰时间。典型的POI类型可以包括美食、商场、酒店、交通服务、金融服务、医疗机构、风景区、企事业单位等。所述POI类型可以基于聚类算法(例如，K均值)获得。例如，某一区域(例如，城市或城镇)可以被划分成多个单位网格。每个单元网格的尺寸和/或形状可以预设。例如，每个单元网格的尺寸可以是500平方米，每个单元网格的形状可以是正六边形。在一些实施例中，处理器可以利用聚类算法(例如，K均值)来合并一些单元网格以形成子区域。处理器可以基于所述子区域内的相同或相似POI的数量来确定子区域的POI类型。例如，假设子区域A总共包括了100个POI，如果其中的90个POI与医疗机构相关，则子区域A的POI类型可以被指定为医疗机构。每个子区域可以对应于一种类型的POI。下车点所属的POI类型可以对应于包括下车点的子区域的POI类型。在一些实施例中，处理器也可以利用第三方数据库确定下车点所属的POI类型。处理器可以通过类似于频率-逆文档频率(TF-IDF)的技术来查询所述第三方数据库以确定所述下车点的POI类型。所述第三方数据库可以结合所述订单请求的特征来提供一些信息，利用这些信息可以帮助系统确定紧急订单请求。例如，这些信息可以暗示或指示在某一POI处将要发生的事件(比如，运动会或音乐会)。当订单请求的目的地与所述POI一致，又或者上车时间与所述事件的发生时间相近或相同，那么可以认为所述请求者可能会发出去所述事件发生地的请求。在特定实施例中，基于上车时间和事件发生时间的时间间隔以及上车点和目的地之间的距离也可以指示所述订单请求为紧急订单请求。
用户画像可以包括关于用户偏好的信息，例如，消费习惯，时间偏好，位置偏好等。在一些实施例中，用户画像可以包括一类或多类服务请求者的出行习惯。所述一类或多类服务请求者可以是指具有一个或多个兴趣爱好或偏好的人群。所述出行习惯可以包括高频路线(例如，通勤路线)，高频订单时间(例如，通勤时间)，高频出行方式等。典型的出行方式可以包括快车模式、专车模式、拼车模式、豪华车模式，商务车模式等。天气状况可能包括晴天，雨天，雪天，风天，雾天等。候车时间是指从订单的请求时间到订单的上车时间的时间段。在一些实施例中，候车时间可以包括一个或多个时间间隔，例如，30秒，50秒，1分钟，2分钟，3分钟等。应当知道的是，所利用的特征越多，模型训练效果可能就越好。
在步骤604中，处理器(例如，处理设备112中的模型确定模块420)可以利用所述一个或多个特征来训练初始机器学习识别模型。在一些实施例中，模型确定模块420可以从采集模块410获得所述一个或多个特征用于训练。根据不同的训练目标可以预设相应的初始机器学习识别模型。例如，所述机器学习模型可以是基于分类的模型，也可以是基于回归的模型。优选地，所述模型为基于分类的模型。对于初始的机器学习识别模型来说，模型的参数可以基于所述提取的历史订单的特征进行训练或优化。典型的机器学习识别模型可以包括Xgboost(Extreme Gradient Boosting)模型、决策树模型、GBDT(Gradient BoostedDecision Tree)模型、神经网络模型等。在一些实施例中，所述机器学习识别模型为Xgboost模型。所述Xgboost模型包括一个或多棵树。每一棵树包括多个节点，比如根节点和叶节点。
在一些实施例中，处理器可以基于第一采样率(例如，0.7、0.8、0.9)从多个标记的历史订单中随机地采样一部分历史订单作为训练集。对于训练集的训练样本，处理器可以基于第二采样率(例如，0.7、0.8、0.9)从所获得的一个或多个特征中随机地采样一部分特征。所述采样的一部分特征可以被指定为模型的训练输入。所述第一采样率和第二采样率可以根据经验值预设。应该理解，第一采样率和第二采样率可以是不同的。
在一些实施例中，处理器可以预设树的数量和/或每棵树的最大深度。例如，树的数量可以设置为100，每棵树的最大深度可以设置为6。树的深度可以是指从根节点到叶节点的节点数。例如，图7A中所示的树710的最大深度是3。
在训练中，可以基于所述提取的历史订单的特征生成一棵或多棵树(例如，图7A或图7B所示)。对于每一棵树来说，所述模型确定模块420首先确定一个根节点，所述根节点对应于第一特征(例如，图7A所示的根节点711或图7B所示的根节点721)。处理器可以通过比较每个特征的信息增益或基尼指数来确定根节点的相应特征。例如，具有最大信息增益的特征可以被指定为根节点。又例如，酷游最小基尼指数的特征可以被指定为根节点。处理器可以基于不同的特征分裂所述根节点以形成多个叶节点(例如，叶节点712-1和712-2)。处理器可以进一步分裂所述叶节点以形成完整的树。应当知道的是，每个节点可以包括一个或多个满足相应分裂规则的历史订单。分裂规则与特征相关。例如，根节点711的分裂规则是下车点的POI类型是医疗机构还是商场。下车点为医疗机构的历史订单可归类到叶节点712-1，下车点为商场的历史订单可归类到叶节点712-2。关于树的更多细节可以在本申请的其他地方找到(例如，图7A和7B，以及其描述)。
在步骤606中，处理器可以通过最小化所述模型的目标函数以更新所述模型的一个或多个参数，其中所述目标函数包括损失函数。对于Xgboost模型，所述参数可以包括每个树的结构，以及每个叶节点的权重值。处理器可以通过加项训练的方法来最小化所述目标函数。具体地，假设有n轮训练(例如，n≥1)，在第一轮训练，处理器可以生成第一棵树。在第二轮训练，处理器可以基于第一棵树和目标函数的最小化生成第二棵树。类似地，在第n轮，处理器可以基于第(n-1)棵树和目标函数的最小化生成第n棵树。所述训练好的识别模型由生成的n棵树构成。处理器可以通过使用训练好的识别模型进一步预测订单请求是否是紧急订单请求。
在一些实施例中，所述目标函数可包括损失函数项和正则化项。例如，所述目标函数如等式(1)所示：
Obj(θ)＝L(θ)+∈(θ) (1)，
其中，Obj(θ)表示目标函数，L(θ)表示损失函数项，∈(θ)表示正则化项。损失函数可以衡量模型与训练数据的匹配程度，正则化项可以衡量模型/树的复杂程度。
在一些实施例中，所述损失函数可以由交叉熵定义。例如，损失函数Obj(θ)如等式(2)所示：
Figure BDA0001860781250000331
其中，m表示训练样本(或历史订单)的数量，θ表示模型的参数，yi表示每个训练样本的标记值(例如，0或1)，y′i表示每个训练样本的预测值(在此也称为预测概率)。对于等式(2)，可以定义0×log0＝0。
在一些实施例中，正则化项∈(θ)可以通过等式(3)定义，如：
其中，γ和λ分别表示预设的超参数，ωi表示叶节点的权重值，T表示树的数量。
应当知道的是，以上关于上述描述仅出于说明性目的，并不旨在限制本申请的范围。对于本领域的普通技术人员来说，可以根据本申请的描述，做出各种各样的修正和改变。例如，过程600还可以包括利用测试集测试训练好的识别模型的稳健性的步骤，测试集可以包括多个标记的历史订单。然而，这些变化与修改仍然在本申请的保护范围内。
图7A和7B是根据本申请的一些实施例所示的示例性机器学习识别模型的示意图。处理器(例如，模型确定模块420)可以生成一棵或多棵树，如图7A和图7B所示。所述一棵或多棵树可以构造所述识别模型，所述识别模型可以通过处理与订单请求相关联的一个或多个特征来确定订单请求是否是紧急订单请求。
如图7A所示，节点711可以是与第一特征相关的根节点(例如，下车点的POI类型)。处理器可以将根节点711分裂成多个叶节点(例如，叶节点712-1和叶节点712-2)。基于与第一特征相关的分裂规则可以确定所述多个叶节点中的每一叶节点。例如，可以基于下车点的POI类型是医疗机构的分裂规则来获得叶节点712-1。换句话说，表征下车点的POI类型是医疗机构的训练样本(例如，历史订单)可以被处理到叶节点712-1。类似地，可以基于下车点的POI类型是商场的分裂规则来获得叶节点712-2。在一些实施例中，所述多个叶节点(例如，叶节点712-1和712-2)的每一叶节点与一个特征相关。例如，叶节点712-1与路线类型相关，而叶节点712-2与订单时间相关。基于与对应特征相关的分裂规则，每个叶节点可以进一步分裂成多个次级叶节点。例如，叶节点712-1可以基于与路线类型相关的分裂规则(例如，训练样本的路线类型是高频路线或低频路线)被分成叶节点713-1和叶节点713-2。叶节点712-2可以基于与订单时间相关的分裂规则(例如，训练样本的订单时间是高峰时段还是非高峰时段)被分成叶节点713-3和叶节点713-4。类似于树710，可以通过根节点721的分裂以生成树720。例如，可以基于与根节点721的特征相关的分裂规则(例如，下车点的POI类型)将根节点721分裂成叶节点722-1、722-2和722-3。在一些实施例中，处理器可以生成包括多个树的树集合。可选地，所述树集合包括100棵树。这100棵树可以构建所述识别模型，以用于预测输入订单是否是紧急订单。在一些实施例中，订单识别模块430可以调用所述训练好的识别模型来处理所接收的订单请求。
上文已对基本概念做了描述，显然，对于阅读此申请后的本领域的普通技术人员而言，上述申请披露仅作为示例，并不构成对本申请的限制。虽然此处并未明确说明，但本领域的普通技术人员可以进行各种变更、改进和修改。诸如此类修改、改进和修正在本申请中被建议，所以该类修改、改进、修正仍属于本申请示范实施例的精神和范围。
同时，本申请使用了特定词语来描述本申请的实施例。例如，术语“一个实施例”、“一实施例”及“一些实施例”意指与本申请的至少一个实施例相关的某一特征、结构或特性。因此，应当强调并注意的是，本说明书中在不同位置两次或多次提及的“一实施例”或“一个实施例”或“一替代性实施例”并不一定系指同一实施例。此外，本申请的一个或多个实施例中的某些特征、结构或特性可以进行适当的组合。
此外，本领域的普通技术人员可以理解，本申请的各方面可以通过若干具有可专利性的种类或情况进行说明和描述，包括任何新的和有用的制程、机器、产品或物质的组合，或对其任何新的和有用的改进。相应地，本申请的各个方面可以完全由硬件实施、可以完全由软件(包括韧体、常驻软件、微代码等)实施、也可以由硬件和软件组合实施，上述硬件或软件均可以被称为“模块”、“单元”、“组件”、“装置”或“系统”。此外，本申请的各方面可以呈现为位于一个或多个计算机可读介质中的计算机产品，该产品具有计算机可读程序编码。
计算机可读信号介质可以包括一个含有计算机程序编码的传播数据讯号，例如在基带上或作为载波的一部分。此类传播讯号可以有多种形式，包括电磁形式、光形式等或任何合适的组合形式。计算机可读信号介质可以为除计算机可读储存介质之外的任何计算机可读介质，该介质可以通过连接至一个指令执行系统、设备或装置以实现通讯、传播或传输供使用的程序。位于计算机可读信号介质上的程序编码可以通过任何合适的媒体进行传播，包括无线电、缆线、光纤电缆、RF、或类似媒体、或任何上述媒体的合适组合。
本申请各方面操作所需的计算机程序码可以用一种或多种程序语言的任意组合编写，包括面向对象程序设计，如Java、Scala、Smalltalk、Eiffel、JADE、Emerald、C++、C#、VB。ET，Python或类似的常规程序编程语言，如"C"编程语言，Visual Basic，Fortran 2003，Perl，COBOL 2002，PHP，ABAP，动态编程语言如Python，Ruby和Groovy或其它编程语言。程序代码可以完全在用户计算机上运行、或作为独立的软件包在用户计算机上运行、或部分在用户计算机上运行部分在远程计算机上运行、或完全在远程计算机或服务器上运行。在后种情况下，远程计算器可以通过任何网络形式与用户计算器连接，例如，局域网络(LAN)或广域网(WAN)，或连接至外部计算器(例如通过因特网)，或在云端计算环境中，或作为服务使用如软件即服务(SaaS)。
然而，这些修正和改变仍然在本申请的保护范围之内。此外，处理元素或者序列的列举顺序、数字、字母或者其他名称的使用不是用于限制要求的过程和方法的。尽管上述披露中通过各种示例讨论了一些目前认为有用的发明实施例，但应当理解的是，此类细节仅起说明的目的，附加的申请专利范围并不仅限于披露的实施例，相反，申请专利范围旨在覆盖所有符合本申请实施例精神和范围的修正和等价组合。例如，虽然以上所述的各种组件可以通过安装于硬件装置中实施，但也可以只通过软件的解决方案实施，例如在现有的服务器或移动设备上的装置。
同理，应当注意的是，为了简化本申请揭示的表述，从而帮助对一个或多个发明实施例的理解，前文对本申请实施例的描述中，有时会将多种特征归并至一个实施例、附图或对其的描述中。然而，此揭示方法并不意味着本申请所需的特征比申请专利范围中涉及的特征多。实际上，申请专利范围的特征要少于上述披露的单个实施例的全部特征。

Claims (21)

1.一种用于识别紧急订单请求的方法，其特征在于，所述方法包括：
接收来自服务请求者终端的订单请求，所述订单请求的特征至少包括上车点、上车时间和下车点中的一种；
通过处理所述订单请求的特征，确定所述订单请求是否为紧急订单请求；
响应于所述订单请求为紧急订单请求：
将所述订单请求优先分配给一个服务提供者以形成订单；
调整所述订单的服务费用；以及
向所述服务请求者终端传递信号，所述信号激发所述服务请求者终端显示包括所述调整的服务费用的订单。
2.如权利要求1所述的方法，其特征在于，所述信号进一步激发所述服务请求者终端显示选择信息，以供所述服务请求者选择是否接受所述订单。
3.如权利要求1所述的方法，其特征在于，将所述订单请求优先分配给一个服务提供者以形成订单包括：
选择具有最短预估到达时间的可用的服务提供者作为目标服务者，所述最短预估到达时间是指从所述服务提供者的当前位置到所述上车点的最短时间。
4.如权利要求1所述的方法，其特征在于，将所述订单请求优先分配给一个服务提供者以形成订单包括：
延迟分配与所述订单请求一起排队的其他订单请求。
5.如权利要求1所述的方法，其特征在于，所述处理订单请求的特征包括：
通过训练的识别模型来处理所述订单请求的特征，其中所述训练的识别模型利用训练数据训练初始机器学习模型获得，所述训练数据包括多个标记的历史订单。
6.如权利要求5所述的方法，其特征在于，所述利用训练数据训练初始机器学习模型包括：
获得与每一标记的历史订单相关联的一个或多个特征；
利用所述一个或多个特征训练所述初始机器学习模型；以及
通过最小化所述模型的目标函数以更新所述模型的一个或多个参数，其中所述目标函数包括损失函数。
7.如权利要求6所述的方法，其特征在于，所述一个或多个特征至少包括订单时间、上车时间、上车点、下车点、用户画像、出行方式、天气状况、候车时间以及下车点所属的感兴趣点的类型中的一种。
8.如权利要求7所述的方法，其特征在于，所述用户画像包括一类或多类服务请求者的出行习惯。
9.如权利要求1所述的方法，其特征在于，所述订单还包括规划路线，所述规划路线为从上车点到下车点的最短预估到达时间对应的路线。
10.一种用于识别紧急订单请求的装置，其特征在于，包括至少一个处理器以及存储介质；
所述存储介质用于存储计算机指令；
所述至少一个处理器用于执行所述计算机指令以实现如权利要求1-9中任意一项所述的方法。
11.一种计算机可读存储介质，其特征在于所述存储介质存储计算机指令，当计算机读取存储介质中的计算机指令后，计算机运行如权利要求1-9中任意一项所述的方法。
12.一种用于识别紧急订单请求的系统，其特征在于，所述系统包括采集模块、模型确定模块、订单识别模块、订单分配模块、费用确定模块和传输模块，其中，
所述采集模块用于接收来自服务请求者终端的订单请求，所述订单请求的特征至少包括上车点、上车时间和下车点中的一种；
所述订单识别模块用于处理所述订单请求的特征，确定所述订单请求是否为紧急订单请求；
响应于所述订单请求为紧急订单请求：
所述订单分配模块用于将所述订单请求优先分配给一个服务提供者以形成订单；
所述费用确定模块用于动态调整所述订单的服务费用；以及
所述传输模块用于向所述服务请求者终端传递信号，所述信号激发所述服务请求者终端显示包括所述调整的服务费用的订单。
13.如权利要求12所述的系统，其特征在于，所述信号进一步激发所述服务请求者终端显示选择信息，以供所述服务请求者选择是否接受所述订单。
14.如权利要求12所述的系统，其特征在于，所述订单分配模块进一步用于：
选择具有最短预估到达时间的可用的服务提供者作为目标服务者，所述最短预估到达时间是指从所述服务提供者的当前位置到所述上车点的最短时间。
15.如权利要求12所述的系统，其特征在于，所述订单分配模块进一步用于：
延迟分配与所述订单请求一起排队的其他订单请求。
16.如权利要求12所述的系统，其特征在于，所述订单识别模块进一步用于：
通过训练的识别模型来处理所述订单请求的特征，其中所述训练的识别模型利用训练数据训练初始机器学习模型获得，所述训练数据包括多个标记的历史订单。
17.如权利要求12-16任意一项所述的系统，其特征在于，所述系统还包括模型确定模块，所述模型确定模块用于利用所述训练数据训练初始机器学习模型。
18.如权利要求17所述的系统，其特征在于，所述模型确定模块进一步用于：
获得与每一标记的历史订单相关联的一个或多个特征；
利用所述一个或多个特征训练所述初始机器学习模型；以及
通过最小化所述模型的目标函数以更新所述模型的一个或多个参数，其中所述目标函数包括损失函数。
19.如权利要求18所述的系统，其特征在于，所述一个或多个特征至少包括订单时间、上车时间、上车点、下车点、用户画像、出行方式、天气状况、候车时间以及下车点所属的感兴趣点的类型中的一种。
20.如权利要求19所述的系统，其特征在于，所述用户画像包括一类或多类服务请求者的出行习惯。
21.如权利要求12所述的系统，其特征在于，所述订单还包括规划路线，所述规划路线为从上车点到下车点的最短预估到达时间对应的路线。
CN201811334228.9A 2018-11-09 2018-11-09 识别紧急订单请求的系统和方法 Pending CN110766505A (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN201811334228.9A CN110766505A (zh) 2018-11-09 2018-11-09 识别紧急订单请求的系统和方法
PCT/CN2018/115138 WO2020093420A1 (en) 2018-11-09 2018-11-13 Systems and methods for emergency order request identification

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201811334228.9A CN110766505A (zh) 2018-11-09 2018-11-09 识别紧急订单请求的系统和方法

Publications (1)

Publication Number Publication Date
CN110766505A true CN110766505A (zh) 2020-02-07

Family

ID=69328539

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201811334228.9A Pending CN110766505A (zh) 2018-11-09 2018-11-09 识别紧急订单请求的系统和方法

Country Status (2)

Country Link
CN (1) CN110766505A (zh)
WO (1) WO2020093420A1 (zh)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109064271A (zh) * 2018-07-23 2018-12-21 温州大学 一种车辆出租订单智能控制的方法
CN111652511A (zh) * 2020-06-04 2020-09-11 桂林电子科技大学 一种基于区块链技术的网约车管理系统及方法
CN111861200A (zh) * 2020-07-17 2020-10-30 北京嘀嘀无限科技发展有限公司 一种服务订单分配方法、装置、电子设备及可读存储介质
CN112270531A (zh) * 2020-10-30 2021-01-26 重庆紫光华山智安科技有限公司 事项通知方法、装置、服务器及存储介质
CN112801495A (zh) * 2021-01-22 2021-05-14 长沙市到家悠享家政服务有限公司 家政服务派单方法及服务端设备
CN115081990A (zh) * 2022-07-07 2022-09-20 佛山技研智联科技有限公司 基于云平台的急单排程管理方法、装置以及设备
CN116779124A (zh) * 2023-08-11 2023-09-19 四川省医学科学院·四川省人民医院 一种基于关联规则的手术调度方法和系统

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113935612B (zh) * 2021-10-09 2022-05-10 福州大学 一种面向钢铁产业的紧急订单物流调度方法
CN114442579A (zh) * 2022-02-07 2022-05-06 孙霖 一种基于物联网的数控机床远程监控系统
CN115525841B (zh) * 2022-10-14 2024-02-02 高德软件有限公司 兴趣点信息的获取方法、电子设备及存储介质

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103971507A (zh) * 2013-01-30 2014-08-06 国民技术股份有限公司 一种召车方法、召车平台及系统
CN104537502A (zh) * 2015-01-15 2015-04-22 北京嘀嘀无限科技发展有限公司 处理订单的方法和设备
CN105956908A (zh) * 2016-05-13 2016-09-21 深圳市永兴元科技有限公司 订单分配方法及系统
CN106204220A (zh) * 2016-07-13 2016-12-07 深圳市拓源天创实业发展有限公司 一种订单自动分配方法及系统
CN107122836A (zh) * 2017-04-14 2017-09-01 上海雷腾软件股份有限公司 一种用于车辆派单的方法及设备
CN108009841A (zh) * 2017-03-29 2018-05-08 北京嘀嘀无限科技发展有限公司 网约车服务请求处理方法、装置和服务器

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103198653B (zh) * 2013-04-23 2016-12-28 杭州九树网络科技有限公司 智能招车系统及应用方法
CN105761482B (zh) * 2016-05-10 2018-06-26 北京交通大学 基于公平性的出租车实时预约方法及系统
CN106447074A (zh) * 2016-12-30 2017-02-22 北京东方车云信息技术有限公司 一种将订单信息推送给司机客户端的方法、装置及系统

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103971507A (zh) * 2013-01-30 2014-08-06 国民技术股份有限公司 一种召车方法、召车平台及系统
CN104537502A (zh) * 2015-01-15 2015-04-22 北京嘀嘀无限科技发展有限公司 处理订单的方法和设备
CN105956908A (zh) * 2016-05-13 2016-09-21 深圳市永兴元科技有限公司 订单分配方法及系统
CN106204220A (zh) * 2016-07-13 2016-12-07 深圳市拓源天创实业发展有限公司 一种订单自动分配方法及系统
CN108009841A (zh) * 2017-03-29 2018-05-08 北京嘀嘀无限科技发展有限公司 网约车服务请求处理方法、装置和服务器
CN107122836A (zh) * 2017-04-14 2017-09-01 上海雷腾软件股份有限公司 一种用于车辆派单的方法及设备

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109064271A (zh) * 2018-07-23 2018-12-21 温州大学 一种车辆出租订单智能控制的方法
CN111652511A (zh) * 2020-06-04 2020-09-11 桂林电子科技大学 一种基于区块链技术的网约车管理系统及方法
CN111652511B (zh) * 2020-06-04 2023-08-11 桂林电子科技大学 一种基于区块链技术的网约车管理系统及方法
CN111861200A (zh) * 2020-07-17 2020-10-30 北京嘀嘀无限科技发展有限公司 一种服务订单分配方法、装置、电子设备及可读存储介质
CN112270531A (zh) * 2020-10-30 2021-01-26 重庆紫光华山智安科技有限公司 事项通知方法、装置、服务器及存储介质
CN112270531B (zh) * 2020-10-30 2023-12-29 重庆紫光华山智安科技有限公司 事项通知方法、装置、服务器及存储介质
CN112801495A (zh) * 2021-01-22 2021-05-14 长沙市到家悠享家政服务有限公司 家政服务派单方法及服务端设备
CN112801495B (zh) * 2021-01-22 2024-04-26 长沙市到家悠享家政服务有限公司 家政服务派单方法及服务端设备
CN115081990A (zh) * 2022-07-07 2022-09-20 佛山技研智联科技有限公司 基于云平台的急单排程管理方法、装置以及设备
CN116779124A (zh) * 2023-08-11 2023-09-19 四川省医学科学院·四川省人民医院 一种基于关联规则的手术调度方法和系统
CN116779124B (zh) * 2023-08-11 2023-10-20 四川省医学科学院·四川省人民医院 一种基于关联规则的手术调度方法和系统

Also Published As

Publication number Publication date
WO2020093420A1 (en) 2020-05-14

Similar Documents

Publication Publication Date Title
CN110766505A (zh) 识别紧急订单请求的系统和方法
CN109478275B (zh) 分配服务请求的系统和方法
JP6925479B2 (ja) 共有可能な注文を割り当てるためのシステムおよび方法
CN109313846B (zh) 用于推荐上车点的系统和方法
CN108701279B (zh) 用于确定未来运输服务时间点的预测分布的系统和方法
CN110462655B (zh) 运力调度系统和方法
JP6538196B2 (ja) サービスの要求を分配するシステム及び方法
CN110832284B (zh) 用于目的地预测的系统和方法
CN108713326B (zh) 分配按需服务请求的系统及方法
WO2020029164A1 (en) Systems and methods for allocating orders
US20180012153A1 (en) Order allocation system and method
US20170169366A1 (en) Systems and Methods for Adjusting Ride-Sharing Schedules and Routes
CN109429520B (zh) 用于检查作弊服务订单的方法、系统、设备及可读介质
US20200226708A1 (en) Systems and methods for identifying incorrect order request
US20200300650A1 (en) Systems and methods for determining an estimated time of arrival for online to offline services
CN110839346A (zh) 用于分配服务请求的系统和方法
CN109791731B (zh) 一种预估到达时间的方法和系统
CN111862585A (zh) 用于交通预测的系统和方法
CN112236787A (zh) 用于生成个性化目的地推荐的系统和方法
CN111882112B (zh) 一种预测到达时间的方法和系统
CN110782648A (zh) 确定预计到达时间的系统和方法
CN111260092A (zh) 用于预测对象到达时间的系统和方法
CN111201421A (zh) 用于确定在线上到线下服务中的最优运输服务类型的系统和方法
CN110998615A (zh) 用于确定服务请求费用的系统和方法
US20210042873A1 (en) Systems and methods for distributing a request

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: 20200207

RJ01 Rejection of invention patent application after publication