发明创造名称：用于处理预约订单的方法及设备
外观设计名称：
决定号：199334
决定日：2019-12-10
委内编号：1F271355
优先权日：
申请（专利）号：201510065334.1
申请日：2015-02-06
复审请求人：北京嘀嘀无限科技发展有限公司
无效请求人：
授权公告日：
审定公告日：
专利权人：
主审员：丁文勍
合议组组长：庄湧
参审员：王芳
国际分类号：G06Q10/02,G06Q10/04
外观设计分类号：
法律依据：专利法第22条第3款
决定要点
：如果权利要求请求保护的技术方案与作为最接近现有技术的对比文件相比存在区别技术特征，而该区别特征属于本领域的公知常识，则权利要求请求保护的技术方案相对于上述对比文件与本领域的公知常识的结合是显而易见的，该权利要求不具备创造性。
全文：
本复审请求涉及申请号为201510065334.1，名称为“用于处理预约订单的方法及设备”的发明专利申请（下称本申请）。本申请的申请人为北京嘀嘀无限科技发展有限公司，申请日为2015年02月06日，公开日为2015年05月06日。
经实质审查，国家知识产权局实质审查部门于2018年09月29日发出驳回决定，以权利要求1-18不具备专利法第22条第3款规定的创造性为由驳回了本申请，具体理由是：1、权利要求1与对比文件1（CN 104167093 A，公开日为2014年11月26日）的区别在于：由司机请求始发时段和始发区域，并根据该信息确定预约订单。该区别属于本领域的公知常识。2、权利要求2-6的附加技术特征或者被对比文件1公开，或者属于本领域的公知常识。3、权利要求7与对比文件1的区别在于：确定所述始发时间所处于的始发时段，并且确定所述始发地点所位于的始发区域；将所述始发时段和所述始发区域也存储在预约订单列表中，由司机请求预约订单的始发时段和始发区域，并根据该信息确定关联的预约订单；将相关信息存储在预约订单列表之前根据第一时间差和预定阈值向始发区域的司机发送订单。该区别属于本领域的公知常识。4、权利要求8-9的附加技术特征均属于本领域的公知常识。5、权利要求10-15是与方法权利要求1-6相对应的产品权利要求，权利要求16-18是与方法权利要求7-9相对应的产品权利要求。因此，权利要求1-18不具备创造性。
驳回决定所依据的文本为：申请日2015年02月06日提交的说明书第1-13页、说明书附图第1-5页、说明书摘要及摘要附图；2018年07月02日提交的权利要求第1-18项。
驳回决定所针对的权利要求书内容如下：
“1. 一种用于处理预约订单的方法，包括：
获取由司机请求的预约订单的始发时段和始发区域；
获取与所述始发时段和所述始发区域关联的预约订单；以及
向所述司机发送所述预约订单；
其中所述获取与所述始发时段和所述始发区域关联的预约订单包括：获取由乘客发布的预约订单的始发时间处于所述始发时段内、并且所述乘客发布的预约订单的始发地点位于所述始发区域内的预约订单；
其中所述向所述司机发送所述预约订单包括：在从所述乘客发布所述预约订单的时间至所述始发时间的第一时间差小于预定阈值的情况下，将所述预约订单作为实时订单向所述始发区域的司机进行发送。
2. 根据权利要求1所述的方法，在获取由司机请求的预约订单的始发时段和始发区域之前，还包括：
向所述司机提供预定的始发时段列表，以便所述司机从所述始发时段列表中选择所述始发时段；和/或
向所述司机提供预定的始发区域列表，以便所述司机从所述始发区域列表中选择所述始发区域。
3. 根据权利要求2所述的方法，其中所述司机通过其移动终端从所述始发时段列表中选择所述始发时段和/或从所述始发区域列表中选择所述始发区域。
4. 根据权利要求1所述的方法，其中获取其中始发时间处于所述始发时段内、并且始发地点位于所述始发区域内的预约订单包括：
将所述始发时段和所述始发区域在预定的预约订单列表中进行检索，以便获得预约订单，其中所获得的预约订单的始发时间处于所述始发时段内、并且始发地点位于所述始发区域内。
5. 根据权利要求4所述的方法，其中向所述司机发送所述预约订单包括：
向所述司机发送所获得的预约订单的始发时间和始发地点。
6. 根据权利要求1至5中任一项所述的方法，其中在向所述司机发送所述预约订单之后，还包括：
接收所述司机对所述预约订单的选择；以及
向所述司机发送所述预约订单的联系信息。
7. 一种用于处理预约订单的方法，包括：
获取由乘客发布的预约订单的始发时间和始发地点；
确定所述始发时间所处于的始发时段，并且确定所述始发地点所位于的始发区域；以及
将所述始发时间、所述始发时段、所述始发地点和所述始发区域存储在预约订单列表中，以便根据司机请求的预约订单的始发时段和始发区域，发送与所述司机请求的预约订单的始发时段和所述始发区域关联的预约订单；
其中在将所述始发时间、所述始发时段、所述始发地点和所述始发区域存储在所述预约订单列表之前，还包括：
确定从所述乘客发布所述预约订单的时间至所述始发时间的第一时间差；以及
在所述第一时间差小于预定阈值的情况下，将所述预约订单作为实时订单向所述始发区域的司机进行发送。
8. 根据权利要求7所述的方法，其中所述确定的始发时段属于预定的始发时段列表，并且所述确定的始发区域属于预定的始发区域列表。
9. 根据权利要求7或8所述的方法，在将所述预约订单的所述始发时间、所述始发时段、所述始发地点和所述始发区域存储在所述预约订单列表之后，还包括：
确定从将所述始发时间、所述始发时段、所述始发地点和所述始发区域存储在所述预约订单列表的时间至所述始发时间的第二时间差；
每隔预定时间间隔，确定从当前时间至所述始发时间的第三时间差；以及
在所述第三时间差与所述第二时间差的比例小于预定阈值的情况下，向执行所述预约订单的司机提供更高的优先级。
10. 一种用于处理预约订单的设备，包括：
第一获取装置，用于获取由司机请求的预约订单的始发时段和始发区域；
第二获取装置，用于获取与所述始发时段和所述始发区域关联的预约订单；以及
第一发送装置，用于向所述司机发送所述预约订单；
其中所述第二获取装置包括：获取单元，用于获取由乘客发布的预约订单的始发时间处于所述始发时段内、并且所述乘客发布的预约订单的始发地点位于所述始发区域内的预约订单；
其中所述向所述司机发送所述预约订单包括：在从所述乘客发布所述预约订单的时间至所述始发时间的第一时间差小于预定阈值的情况下，将所述预约订单作为实时订单向所述始发区域的司机进行发送。
11. 根据权利要求10所述的设备，还包括：
第一提供装置，用于向所述司机提供预定的始发时段列表，以便所述司机从所述始发时段列表中选择所述始发时段；和/或
第二提供装置，用于向所述司机提供预定的始发区域列表，以便所述司机从所述始发区域列表中选择所述始发区域。
12. 根据权利要求11所述的设备，其中所述司机通过其移动终端从所述始发时段列表中选择所述始发时段和/或从所述始发区域列表中选择所述始发区域。
13. 根据权利要求10所述的设备，其中所述获取单元包括：
检索子单元，用于将所述始发时段和所述始发区域在预定的预约订单列表中进行检索，以便获得预约订单，其中所获得的预约订单的始发时间处于所述始发时段内、并且始发地点位于所述始发区域内。
14. 根据权利要求13所述的设备，其中所述第一发送装置包括：
发送单元，用于向所述司机发送所获得的预约订单的始发时间和始发地点。
15. 根据权利要求10至14中任一项所述的设备，还包括：
接收装置，用于接收所述司机对所述预约订单的选择；以及
第二发送装置，用于向所述司机发送所述预约订单的联系信息。
16. 一种用于处理预约订单的设备，包括：
第三获取装置，用于获取由乘客发布的预约订单的始发时间和始发地点；
第一确定装置，用于确定所述始发时间所处于的始发时段，并且确定所述始发地点所位于的始发区域；
存储装置，用于将所述始发时间、所述始发时段、所述始发地点和所述始发区域存储在预约订单列表中，以便根据司机请求的预约订单的始发时段和始发区域，发送与所述司机请求的预约订单的始发时段和所述始发区域关联的预约订单；
第二确定装置，用于确定从所述乘客发布所述预约订单的时间至所述始发时间的第一时间差；以及
第三发送装置，用于在所述第一时间差小于预定阈值的情况下，将所述预约订单作为实时订单向所述始发区域的司机进行发送。
17. 根据权利要求16所述的设备，其中所述确定的始发时段属于预定的始发时段列表，并且所述确定的始发区域属于预定的始发区域列表。
18. 根据权利要求16或17所述的设备，还包括：
第三确定装置，用于确定从将所述始发时间、所述始发时段、所述始发地点和所述始发区域存储在所述预约订单列表的时间至所述始发时间的第二时间差；
第四确定装置，用于每隔预定时间间隔，确定从当前时间至所述始发时间的第三时间差；以及
第三提供装置，用于在所述第三时间差与所述第二时间差的比例小于预定阈值的情况下，向执行所述预约订单的司机提供更高的优先级。”
申请人（下称复审请求人）对上述驳回决定不服，于2019年01月14日向国家知识产权局提出了复审请求，同时提交了权利要求书的全文修改替换页，其中修改了独立权利要求1、7、10、16。复审请求人认为：本申请权利要求1所要解决的技术问题为“如何将乘客发布的预约订单提前派发给预期服务时间和位置符合该预约订单需求的司机”，而对比文件1中并不存在为乘客的“预约订单”提供乘车服务的需求；对比文件1中，是在司机出班和收班时，实时为司机匹配顺路订单(顺风车订单)，此时是基于司机上班或回家时的实时时间和位置为司机匹配乘客的实时订单，在此过程中，需要针对候选的出租车的实时服务时间和位置，来进行实时计算和比较。而本申请权利要求1中，需要预先收集各司机请求的始发时段和始发区域，在获取到乘客的预约订单后，可以直接基于预约订单的出发时间匹配对应的始发时段和始发区域符合需求的司机，在订单派发效率上要高很多。因此，本申请具备创造性。
复审请求时修改的权利要求1、7、10、16内容如下：
“1. 一种用于处理预约订单的方法，包括：
获取由司机请求的预约订单的始发时段和始发区域；
获取与所述始发时段和所述始发区域关联的预约订单；其中，所述预约订单的订单发布时间与乘客发布的订单的始发时间之间的第一时间差大于或等于预定阈值；以及
向所述司机发送所述预约订单；
其中所述获取与所述始发时段和所述始发区域关联的预约订单包括：获取由乘客发布的预约订单的始发时间处于所述始发时段内、并且所述乘客发布的预约订单的始发地点位于所述始发区域内的预约订单。”
“7. 一种用于处理预约订单的方法，包括：
获取由乘客发布的预约订单的始发时间和始发地点；
确定所述始发时间所处于的始发时段，并且确定所述始发地点所位于的始发区域；以及
将所述始发时间、所述始发时段、所述始发地点和所述始发区域存储在预约订单列表中，以便根据司机请求的预约订单的始发时段和始发区域，发送与所述司机请求的预约订单的始发时段和所述始发区域关联的预约订单；
其中，所述预约订单的订单发布时间与乘客发布的订单的始发时间之间的第一时间差大于或等于预定阈值。”
“10. 一种用于处理预约订单的设备，包括：
第一获取装置，用于获取由司机请求的预约订单的始发时段和始发区域；
第二获取装置，用于获取与所述始发时段和所述始发区域关联的预约订单；以及
第一发送装置，用于向所述司机发送所述预约订单；
其中所述第二获取装置包括：获取单元，用于获取由乘客发布的预约订单的始发时间处于所述始发时段内、并且所述乘客发布的预约订单的始发地点位于所述始发区域内的预约订单；其中，所述预约订单的订单发布时间与乘客发布的订单的始发时间之间的第一时间差大于或等于预定阈值。”
“16. 一种用于处理预约订单的设备，包括：
第三获取装置，用于获取由乘客发布的预约订单的始发时间和始发地点；
第一确定装置，用于确定所述始发时间所处于的始发时段，并且确定所述始发地点所位于的始发区域；
存储装置，用于将所述始发时间、所述始发时段、所述始发地点和所述始发区域存储在预约订单列表中，以便根据司机请求的预约订单的始发时段和始发区域，发送与所述司机请求的预约订单的始发时段和所述始发区域关联的预约订单；其中，所述预约订单的订单发布时间与乘客发布的订单的始发时间之间的第一时间差大于或等于预定阈值。”
经形式审查合格，国家知识产权局于2019年02月11日依法受理了该复审请求，并将其转送至实质审查部门进行前置审查。
实质审查部门在前置审查意见书中坚持驳回决定。
随后，国家知识产权局成立合议组对本案进行审理。
合议组于2019年08月08日向复审请求人发出复审通知书，指出：权利要求1-18相对于对比文件1和本领域的惯用手段的结合不具备专利法第22条第3款规定的创造性。对于复审请求人的复审请求意见，合议组认为：首先，对比文件1所公开的顺风车运营方法根据司机的出班/收班时间、出班/收班位置，确定在时间上和空间上都贴近司机需求的订单，其中的出班/收班时间、出班/收班位置都是预先作为出租车信息存储在服务器中，在对比文件1的说明书第[0047]-[0055]段也明确记载了，根据出租车的出班时间、出班位置确定相匹配的叫车订单，并非复审请求人所说的“司机上班或回家时的实时时间和位置”。其次，对比文件1已经公开了将与出班时间和出班位置处于相近时间和相邻位置的预约订单确定为顺风车订单，在此基础上，本领域技术人员容易想到将对比文件1中的叫车订单和出租车的出班信息中的时间和位置分别关联到预设的时间段和区域，从而提高订单匹配的效率。
复审请求人于2019年08月26日提交了意见陈述书，同时提交了权利要求书的全文修改替换页，具体修改包括：将权利要求2和11分别上升为独立权利要求，删除原权利要求1和10，并对独立权利要求7、16做了相应修改；对各个权利要求的编号和引用关系做了适应性修改。复审请求人认为：首先，对比文件1中的顺风车订单与本申请权利要求1中的预约订单在实质上是两种不同类型的订单，针对两种不同类型的订单的处理机制、派发原则和所达到的派发效果均不同，不管是从应用场景、技术问题、技术效果、还是实现过程上，两者之间不存在任何技术关联。对比文件1中没有给出任何直接的描述或者给出任何暗示性的描述，表明顺风车订单为预约订单，相反，对比文件1中明确记载了是针对实时订单的顺风车服务，在此基础上，对比文件1针对实时订单的计算、比较和派发方式，与本申请权利要求1针对预约订单的比较和派发方式完全不同。其次，选择列表虽然为常规技术手段，但在本申请中提供的始发时段列表和/或始发区域列表，其用途是为了供司机进行手段选择，而并非是对比文件1中表格仅是记载单纯的时间和位置等信息，以进行自动的订单匹配，而且对比文件1中列表中记载的信息，也仅是用于记载通过司机上班位置等大数据分析得到的信息，以及单纯的统计顺风车订单得出的信息，其对于司机来讲并不能起到可供选择的目的，因此，在所记载内容不同、所记载内容的来源不同、所起到的作用和目的不同，并且本申请中可以达到的明显的技术效果的情况下，并不能仅以使用到了常规特征，而认为其属于公知常识。因此，本申请具备创造性。
在上述程序的基础上，合议组认为本案事实已经清楚，可以作出审查决定。
二、决定的理由
审查文本的认定
复审请求人在答复复审通知书时提交了权利要求书的全文修改替换页。经审查，所做修改符合专利法实施细则第61条第1款和专利法第33条的规定。本复审请求审查决定所依据的审查文本为：申请日2015年02月06日提交的说明书第1-13页、说明书附图第1-5页、说明书摘要及摘要附图；2019年08月26日提交的权利要求第1-16项。
关于专利法第22条第3款
专利法第22条第3款规定：创造性，是指与现有技术相比，该发明具有突出的实质性特点和显著的进步，该实用新型具有实质性特点和进步。
如果权利要求请求保护的技术方案与作为最接近现有技术的对比文件相比存在区别技术特征，而该区别特征属于本领域的公知常识，则权利要求请求保护的技术方案相对于上述对比文件与本领域的公知常识的结合是显而易见的，该权利要求不具备创造性。
本复审请求审查决定所引用的对比文件与驳回决定和复审通知书所引用的对比文件相同，即：
对比文件1：CN 104167093 A，公开日为：2014年11月26日。
2.1、关于权利要求1-5的创造性
权利要求1请求保护一种用于处理预约订单的方法。对比文件1公开了一种基于司机住址信息的顺风车运营方法，其中包括（参见说明书第[0042]-[0081]段，图1）：顺风车判定模块根据叫车订单集合中各叫车订单信息和出租车信息集合中各出租车信息，来计算各叫车订单相对于各出租车是否属于顺风车订单；其中叫车订单信息包括订单编号、起点位置、终点位置、出发时间；出租车信息包括司机编号、当前位置、出班位置或收班位置、出班时间或收班时间；运营推送模块将顺风车判定模块计算出的顺风车订单推送给相应的出租车，在播单信息中会提示司机当前推送的订单为顺风车订单（相当于向所述司机发送所述预约订单）；
其中出班顺风车判定规则包括：如果叫车订单Q的出发时间T（相当于乘客发布的预约订单的始发时间）减去出租车C的出班时间Tout的绝对值小于或等于给定出班时间阈值TYout，则认为叫车订单Q满足条件1（即判断T是否处于Tout±TYout这一时间段内，该Tout±TYout相当于始发时段）；根据叫车订单Q的起点位置（相当于乘客发布的预约订单的始发地点）和出租车C的出班位置计算出两者之间的距离为Dout，根据订单Q的起点位置、终点位置计算出订单Q的订单距离为D，若Dout小于或等于给定出班距离阈值DYout（即判断起点位置是否处于与出班位置的距离在DYout以内的区域内，该区域即相当于始发区域），或者订单距离D大于或等于给定出班距离倍数阈值Kout乘以给定出班距离阈值DYout，则认为叫车订单Q满足条件2；若条件1和条件2同时满足，则叫车订单Q相对于出租车C属于出班顺风车订单（相当于获取与所述始发时段和所述始发区域关联的预约订单；所述获取与所述始发时段和所述始发区域关联的预约订单包括：获取由乘客发布的预约订单的始发时间处于所述始发时段内、并且所述乘客发布的预约订单的始发地点位于所述始发区域内的预约订单）。
权利要求1与对比文件1的区别技术特征在于：（1）获取由司机请求的预约订单的始发时段和始发区域；所述预约订单的订单发布时间与乘客发布的订单的始发时间之间的第一时间差大于或等于预定阈值；（2）在获取由司机请求的预约订单的始发时段和始发区域之前，还包括：向所述司机提供预定的始发时段列表，以便所述司机从所述始发时段列表中选择所述始发时段；和/或向所述司机提供预定的始发区域列表，以便所述司机从所述始发区域列表中选择所述始发区域。
基于上述区别技术特征，本申请权利要求1实际解决的问题是如何提高订单派发的效率以及如何为司机提供预约订单的选择。
对于区别技术特征（1），首先，对比文件1已经公开了将始发时间和始发地点分别与司机的出班时间和出班位置相关联的订单确定为顺风车订单，虽然对比文件1没有公开该始发时段和始发区域是由司机请求的，但是该始发时段和始发区域是根据司机的出班需求而确定的，而对于该出班需求是由希望提供预约订单接单的司机处获取，亦或从其他管理方等获取，这些均是根据常规业务管理方式而采用的惯用手段；其次，根据用户的用车需求提供实时派单或者预约服务在出租车行业都是常规的服务方式，因此，仅针对订单发布时间与订单的始发时间相距较大的预约订单执行基于始发时段和始发区域的订单派发，这对本领域技术人员来说是容易想到的。
对于区别技术特征（2），为用户提供包括多个可选项的列表进行选择，这属于常用的人机交互方式，因此，以列表形式将多个可供选择的始发时段和始发区域提供给司机进行选择，这属于本领域的公知常识。
因此，权利要求1相对于对比文件1和本领域的公知常识的结合不具有突出的实质性特点，不具备专利法第22条第3款规定的创造性。
权利要求2引用权利要求1。司机使用常见的移动终端进行约单或接单操作，这属于本领域的公知常识。因此，当其引用的权利要求不具备创造性时，权利要求2也不具备专利法第22条第3款规定的创造性。
权利要求3引用权利要求1，权利要求4引用权利要求3。对比文件1公开了（参见同上）：顺风车判定模块根据叫车订单集合中各叫车订单信息和出租车信息集合中各出租车信息，来计算各叫车订单相对于各出租车是否属于顺风车订单；出班顺风车判定规则包括：如果叫车订单Q的出发时间T减去出租车C的出班时间Tout的绝对值小于或等于给定出班时间阈值TYout，则认为叫车订单Q满足条件1（即判断T是否处于Tout±TYout这一时间段内，该Tout±TYout相当于始发时段）；根据叫车订单Q的起点位置和出租车C的出班位置计算出两者之间的距离为Dout，根据订单Q的起点位置、终点位置计算出订单Q的订单距离为D，若Dout小于或等于给定出班距离阈值DYout，或者订单距离D大于或等于给定出班距离倍数阈值Kout乘以给定出班距离阈值DYout，则认为叫车订单Q满足条件2；若条件1和条件2同时满足，则叫车订单Q相对于出租车C属于出班顺风车订单（相当于将所述始发时段和所述始发区域在预定的预约订单列表中进行检索，以便获得预约订单，其中所获得的预约订单的始发时间处于所述始发时段内、并且始发地点位于所述始发区域内）；运营推送模块将顺风车判定模块计算出的顺风车订单推送给相应的出租车，其中叫车订单信息包括订单编号、起点位置、终点位置、出发时间（相当于向所述司机发送所述预约订单包括向所述司机发送所获得的预约订单的始发时间和始发地点）。因此，当其引用的权利要求不具备创造性时，权利要求3-4也不具备专利法第22条第3款规定的创造性。
权利要求5引用权利要求1-4任一项。对比文件1公开了（参见同上）：所述运营推送模块将顺风车订单对应的乘客手机号推送给出租车，以便该出租车与乘客联系（相当于向所述司机发送所述预约订单的联系信息）。同时，接收司机发送的对预约订单的选择以确认相应订单以完成预约，这属于本领域的惯用手段。因此，当其引用的权利要求不具备创造性时，权利要求5也不具备专利法第22条第3款规定的创造性。
2.2、关于权利要求6-8的创造性
权利要求6请求保护一种用于处理预约订单的方法。对比文件1公开了一种基于司机住址信息的顺风车运营方法，其中包括（参见说明书第[0042]-[0081]段，图1）：顺风车判定模块根据叫车订单集合中各叫车订单信息和出租车信息集合中各出租车信息，来计算各叫车订单相对于各出租车是否属于顺风车订单；其中叫车订单信息包括订单编号、起点位置、终点位置、出发时间（相当于获取由乘客发布的预约订单的始发时间和始发地点）；出租车信息包括司机编号、当前位置、出班位置或收班位置、出班时间或收班时间；其中，出班顺风车判定规则包括：如果叫车订单Q的出发时间T（相当于乘客发布的预约订单的始发时间）减去出租车C的出班时间Tout的绝对值小于或等于给定出班时间阈值TYout，则认为叫车订单Q满足条件1（即判断Tout是否处于T±TYout这一时间段内，该T±TYout相当于所述始发时间所处于的始发时段）；根据叫车订单Q的起点位置（相当于乘客发布的预约订单的始发地点）和出租车C的出班位置计算出两者之间的距离为Dout，根据订单Q的起点位置、终点位置计算出订单Q的订单距离为D，若Dout小于或等于给定出班距离阈值DYout（即判断出班位置是否处于与起点位置的距离在DYout以内的区域内，该区域即相当于所述始发地点所位于的始发区域），或者订单距离D大于或等于给定出班距离倍数阈值Kout乘以给定出班距离阈值DYout，则认为叫车订单Q满足条件2；若条件1和条件2同时满足，则叫车订单Q相对于出租车C属于出班顺风车订单；运营推送模块将顺风车判定模块计算出的顺风车订单推送给相应的出租车，在播单信息中会提示司机当前推送的订单为顺风车订单（相当于根据始发时段和始发区域，发送与始发时段和所述始发区域关联的预约订单）。在叫车软件的服务器端或呼叫中心的服务器端，都存储有大量的从乘客那里收集的叫车订单。一般，从乘客那里收集的叫车订单格式如下（相当于将所述始发时间、所述始发地点存储在预约订单列表中）：
订单编号
乘客手机号
出发地
出发时间
出发地经纬度信息
140002
13300000001
中关村大街10号
2014/2/206:00
xxxxxx
140012
13300000002
中关村大街20号
2014/2/2018:00
xxxxxx
权利要求6与对比文件1的区别技术特征在于：（1）确定始发时段和始发区域，并将所述始发时段和所述始发区域也存储在预约订单列表中；根据司机请求的预约订单的始发时段和始发区域，发送与所述司机请求的预约订单的始发时段和所述始发区域关联的预约订单；其中，所述预约订单的订单发布时间与乘客发布的订单的始发时间之间的第一时间差大于或等于预定阈值。（2）司机请求的预约订单的始发时段和始发区域通过以下确定：向所述司机提供预定的始发时段列表，以便所述司机从所述始发时段列表中选择所述始发时段；和/或向所述司机提供预定的始发区域列表，以便所述司机从所述始发区域列表中选择所述始发区域。
基于上述区别技术特征，本申请权利要求6实际解决的问题是如何提高订单派发的效率以及如何为司机提供预约订单的选择。
对于区别技术特征（1），首先，虽然对比文件1没有公开将乘客所发布的始发时间和始发地点所对应的始发时段和始发区域存储在预约订单列表中、并根据司机所请求的始发时段和始发区域确定预约订单，但是对比文件1已经公开了将与出班时间和出班位置处于相近时间和相邻位置的预约订单确定为顺风车订单，在此基础上，本领域技术人员容易想到将对比文件1中的叫车订单和出租车的出班信息中的时间和位置分别关联到预设的时间段和区域，从而提高订单匹配的效率。进而，将乘客预约的始发时间和始发位置所对应的始发时间段和始发区域相应的存储在预约订单列表中以供之后进行订单匹配时使用，这属于本领域的惯用手段；同时，基于司机的请求提供符合其出班需求的预约订单，这是根据常规业务管理方式而采用的惯用手段。
其次，根据用户的用车需求提供实时派单或者预约服务在出租车行业都是常规的服务方式，因此，仅针对订单发布时间与订单的始发时间相距较大的预约订单执行基于始发时段和始发区域的订单派发，这对本领域技术人员来说是容易想到的。
对于区别技术特征（2），为用户提供包括多个可选项的列表进行选择，这属于常用的人机交互方式，因此，以列表形式将多个可供选择的始发时段和始发区域提供给司机进行选择，这属于本领域的公知常识。
因此，权利要求6相对于对比文件1和本领域的公知常识的结合不具有突出的实质性特点，不具备专利法第22条第3款规定的创造性。
权利要求7引用权利要求6。根据始发时段列表和始发区域列表确定预约订单的始发时间和始发地点所关联的始发时段和始发区域，从而提高与司机所请求的预约订单的始发时段和始发区域进行匹配的效率，这对本领域技术人员来说是容易想到的。因此，当其引用的权利要求不具备创造性时，权利要求7也不具备专利法第22条第3款规定的创造性。
权利要求8引用权利要求6或7。为了及时响应乘客的预约要求，随着订单的始发时间的临近而采取相应措施来提高订单派送的成功率，这属于预约服务中的常规手段。因此，当其引用的权利要求不具备创造性时，权利要求8也不具备专利法第22条第3款规定的创造性。
2.3、关于权利要求9-16的创造性
权利要求9-13为对应于方法权利要求1-5的产品权利要求，其技术特征一一对应。因此，根据评述权利要求1-5的理由，权利要求9-13也不具备专利法第22条第3款规定的创造性。
权利要求14-16为对应于方法权利要求6-8的产品权利要求，其技术特征一一对应。因此，根据评述权利要求6-8的理由，权利要求14-16也不具备专利法第22条第3款规定的创造性。
对复审请求人相关意见的评述
对于复审请求人答复复审通知书时所陈述的意见，合议组认为：
首先，对比文件1的说明书中记载的出班顺风车判定规则中，根据叫车订单的出发时间和出租车的出班时间确定是否满足条件1、根据叫车订单起点位置和出租车的出班位置确定是否满足条件2，当条件1和条件2同时满足，则判定该叫车订单相对于该出租车属于出班顺风车订单。上述出租车的出班位置明显为区别于出租车的当前位置的位置信息，并且根据常识，该出班位置和出班时间均为预先确定、而非实时信息，也就是说，对比文件1的应用场景同样是根据司机请求的始发时间和始发地点，来将时间和位置符合该请求的乘客所发布的订单派发给司机。同时，对于对比文件1是否公开了顺风车订单为预约订单，对比文件1中关于出班顺风车派单实施方式中记载了具体的叫车订单：
订单编号
乘客手机号
出发地
出发时间
出发地经纬度信息
140002
13300000001
中关村大街10号
2014/2/206:00
xxxxxx
140012
13300000002
中关村大街20号
2014/2/2018:00
xxxxxx
可见，上述两个订单的出发时间间隔了12个小时，相对于“2014/2/206:00”的订单，该“2014/2/2018:00”显然属于预约订单，同时，对比文件1中关于以起点位置、终点位置、出发时间（而非实时位置、实时时间）作为叫车订单的信息，也即有用户在生成订单时提供其起点位置和终点位置以及所需要的出发时间，换句话说，由用户“预约”该顺风车服务，由此可见，对比文件1中公开了根据“预约订单”的信息和司机的请求进行派单服务，其中的出班顺风车订单即为将订单信息和司机预约请求的始发时间和始发地点进行匹配所派发的预约订单。
其次，为用户提供包括多个可选项的列表进行选择，这属于常用的人机交互方式；当为司机提供符合条件的候选订单时，采用上述常用的人机交互方式，以列表形式将多个可供选择的始发时段和始发区域提供给司机进行选择，这属于本领域的公知常识。
综上，对于复审请求人的意见，合议组不予支持。
三、决定
维持国家知识产权局于2018年09月29日对本申请作出的驳回决定。
如对本复审请求审查决定不服，根据专利法第41条第2款的规定，复审请求人可以自收到本决定之日起三个月内向北京知识产权法院起诉。
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
