一种残膜回收机防缠绕挑膜装置的制 一种秧草收获机用电力驱动行走机构

信息推荐的方法、装置、电子设备及存储介质与流程

2022-05-26 20:09:05 来源:中国专利 TAG:
1.本公开涉及计算机
技术领域
:,具体涉及智能交通、大数据技术等
技术领域
:。
背景技术
::2.通常,在用户使用应用程序约车时,可能存在约车困难、等待乘车的时间较长等问题,例如,用户在上下班等高峰期、异常天气条件下经常较难叫到车。因此,选择合适的约车时间对保证约车成功率尤为重要。3.目前,约车操作均为用户来主动发起,约车时间也由用户来决定,用户启动约车服务后,约车平台或者约车应用程序便直接进行呼叫车辆的操作。技术实现要素:4.本公开提供了一种信息推荐的方法、装置、电子设备及存储介质。5.根据本公开的一方面,提供了一种信息推荐的方法,包括:6.获取用户的历史约车数据和所述用户当前所在地点的实时约车数据;7.根据所述历史约车数据和所述实时约车数据,预测所述用户从出发地点到目的地点的推荐发单时间;8.向所述用户提供所述推荐发单时间。9.根据本公开的另一方面,提供了一种信息推荐的装置,包括:10.获取单元,用于获取用户的历史约车数据和所述用户当前所在地点的实时约车数据;11.预测单元,用于根据所述历史约车数据和所述实时约车数据,预测所述用户从出发地点到目的地点的推荐发单时间;12.推荐单元,用于向所述用户提供所述推荐发单时间。13.根据本公开的再一方面,提供了一种电子设备,包括:14.至少一个处理器;以及15.与所述至少一个处理器通信连接的存储器;其中,16.所述存储器存储有可被所述至少一个处理器执行的指令,所述指令被所述至少一个处理器执行,以使所述至少一个处理器能够执行如上所述的方面和任一可能的实现方式的方法。17.根据本公开的又一方面,提供了一种存储有计算机指令的非瞬时计算机可读存储介质,所述计算机指令用于使所述计算机执行如上所述的方面和任一可能的实现方式的方法。18.根据本公开的又一方面,提供了一种计算机程序产品,包括计算机程序,所述计算机程序在被处理器执行时实现如上所述的方面和任一可能的实现方式的方法。19.应当理解,本部分所描述的内容并非旨在标识本公开的实施例的关键或重要特征,也不用于限制本公开的范围。本公开的其它特征将通过以下的说明书而变得容易理解。附图说明20.附图用于更好地理解本方案,不构成对本公开的限定。其中:21.图1是根据本公开第一实施例的示意图;22.图2是根据本公开第二实施例的示意图;23.图3是根据本公开第三实施例的示意图;24.图4是用来实现本公开实施例的信息推荐的方法的电子设备的框图。具体实施方式25.以下结合附图对本公开的示范性实施例做出说明,其中包括本公开实施例的各种细节以助于理解,应当将它们认为仅仅是示范性的。因此,本领域普通技术人员应当认识到,可以对这里描述的实施例做出各种改变和修改,而不会背离本公开的范围和精神。同样,为了清楚和简明,以下的描述中省略了对公知功能和结构的描述。26.显然,所描述的实施例是本公开一部分实施例,而不是全部的实施例。基于本公开中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的全部其他实施例,都属于本公开保护的范围。27.需要说明的是,本公开实施例中所涉及的终端设备可以包括但不限于手机、个人数字助理(personaldigitalassistant,pda)、无线手持设备、平板电脑(tabletcomputer)等智能设备;显示设备可以包括但不限于个人电脑、电视等具有显示功能的设备。28.另外,本文中术语“和/或”,仅仅是一种描述关联对象的关联关系,表示可以存在三种关系,例如,a和/或b,可以表示:单独存在a,同时存在a和b,单独存在b这三种情况。另外,本文中字符“/”,一般表示前后关联对象是一种“或”的关系。29.通常,在用户使用应用程序约车时,往往可能存在着约车困难、等待乘车的时间较长等问题,例如,用户在上下班等高峰期、异常天气条件下经常较难约到车或者约的车后等待乘车的时间较长。而且,在用户约车过程中,无论是用户在道路边等待接驾时间过长的情况,或是司机等待乘客用户时间较长的情况,都会给司乘双方带来不良体验。因此,选择合适的约车时间尤为重要。30.目前,约车操作均为用户来主动发起,约车时间也由用户来决定,用户启动约车服务后,约车平台或者约车应用程序便直接进行呼叫车辆的操作,约车平台或者约车应用程序没有对约车时机进行相关的建议或提示。31.因此,亟需提供一种信息推荐的方法,能够实现为用户提供基于约车时机的建议或提示,从而减少用户等待时间,提升约车服务应用的智能化和可靠性。32.图1是根据本公开第一实施例的示意图,如图1所示。33.101、获取用户的历史约车数据和所述用户当前所在地点的实时约车数据。34.102、根据所述历史约车数据和所述实时约车数据,预测所述用户从出发地点到目的地点的推荐发单时间。35.103、向所述用户提供所述推荐发单时间。36.至此,还可以根据向所述用户提供所述推荐发单时间,向用户提供与所述推荐发单时间对应的约车提示信息。37.需要说明的是,用户可以包括使用约车客户端的乘客。约车,即叫车或者打车,约车可以包括即时约车和预定时间约车,即预约叫车。38.需要说明的是,用户的历史约车数据可以包括但不限于用户的约车偏好信息、用户出行路线信息、以及历史发单时间。39.需要说明的是,实时约车数据可以包括但不限于用户的出发地点当前的可接单车辆数量、约车人数、车辆与用户的出发地点之间距离。40.需要说明的是,发单时间可以是指用户基于约车客户端发出订单的时间。41.需要说明的是,101~103的执行主体的部分或全部可以为位于本地终端的应用,或者还可以为设置在位于本地终端的应用中的插件或软件开发工具包(softwaredevelopmentkit,sdk)等功能单元,或者还可以为位于网络侧服务器中的处理引擎,或者还可以为位于网络侧的分布式系统,例如,网络侧的约车平台中的处理引擎或者分布式系统等,本实施例对此不进行特别限定。42.可以理解的是,所述应用可以是安装在本地终端上的本地程序(nativeapp),或者还可以是本地终端上的浏览器的一个网页程序(webapp),本实施例对此不进行限定。43.这样,通过获取用户的历史约车数据和所述用户当前所在地点的实时约车数据,进而可以根据所述历史约车数据和所述实时约车数据,预测所述用户从出发地点到目的地点的推荐发单时间,使得能够向所述用户提供所述推荐发单时间,由于利用了用户的历史约车数据和用户当前所在地点的实时约车数据,分析预测得到适合该用户从出发地点到目的地点的推荐发单时间,可以减少用户的乘车等待时间,实现了向用户的推荐更加合理有效地约车时间,从而提升了约车应用服务可靠性。44.可选地,在本实施例的一个可能的实现方式中,在102之前,可以进一步地获取所述用户所提供的约车查询信息,进而可以根据所述用户所提供的约车查询信息,确定所述出发地点和所述目的地点。45.在该实现方式中,所述用户所提供的约车查询信息可以包括用户所输入的出发地点和目的地点、以及用户所触发的发单操作信息。46.在该实现方式的一个具体实现过程中,在用户已有约车行为的情况下,可以获取到用户的约车查询信息,再根据用户所提供的约车查询信息,可以获得用户所查询的出发地点和目的地点。47.在该具体实现过程中,若用户确认约车时,还可以获取到用户所触发的发单操作信息。该发单操作信息可以包括发单指令和发单时间。该发单时间可以为即时发单时间。48.这样,在用户进行约车查询时,可以获取到输入要查询的出发地点和目的地点等约车查询信息,通过用户所提供的约车查询信息,可以直接确定该约车查询信息中的出发地点和目的地点。由此,在用户已有约车行为的情况下,可以基于所确定的出发地点和目的地点,预测该用户从出发地点到目的地点的推荐发单时间,从而提升了预测的推荐发单时间的针对性和准确性。49.可选地,在本实施例的一个可能的实现方式中,在102之前,还可以进一步地根据所述历史约车数据,获得所述用户的约车偏好信息,进而可以根据所述用户的约车偏好信息,预测所述出发地点和所述目的地点。50.在该实现方式中,用户的约车偏好信息可以包括历史出发地点和目的地点、用户选择的车辆类型、以及用户选择的消费价格范围等。51.在该实现方式的一个具体实现过程中,在用户未有约车行为的情况下,可以根据所述历史约车数据,获得所述用户的约车偏好信息,再根据所获得的所述用户的约车偏好信息,获得所述用户的历史出发地点和目的地点,以预测所述用户在预定时间的约车行为对应的出发地点和目的地点。52.在该具体实现过程中,在预定时间的约车行为可包括预定约车行为、上下班通勤约车行为,以及多交通工具组合出行方式中的约车行为。53.这样,可以通过根据基于历史约车数据所获得的用户的约车偏好信息,预测用户在预定时间的约车行为对应的出发地点和目的地点。由此,在用户未有约车行为的情况下,可以基于所预测的出发地点和目的地点,预测该用户从出发地点到目的地点的推荐发单时间,从而提升了预测的推荐发单时间的针对性和准确性。54.可选地,在本实施例的一个可能的实现方式中,在102中,具体可以根据所述用户当前所在地点和所述出发地点,确定从所述用户当前所在地点到达所述出发地点的预计上车时间,进而可以根据所述历史约车数据和所述实时约车数据,确定所述用户立即发单到车辆到达所述出发地点的预计等待时间,使得能够根据所述预计上车时间和所述预计等待时间,预测所述用户从出发地点到目的地点的推荐发单时间。55.在该实现方式中,该预计上车时间可以是表征从所述用户当前所在地点到达所述出发地点的预计上车时间点,或者可以是表征从所述用户当前所在地点到达所述出发地点的预计上车时间间隔,即预计上车所需时长。56.该预计等待时间可以是表征用户立即发单到车辆到达所述出发地点的预计等待时间点,或者可以是表征用户立即发单到车辆到达所述出发地点的预计等待时间间隔,即预计等待时长。57.具体地,该预计等待时间可以是根据用户立即发单到司机接单的时间和司机接单到车辆到达所述出发地点的时间所确定的。58.在该实现方式的一个具体实现过程中,在用户已有约车行为的情况下,可以根据所述用户所提供的约车查询信息,获取所述用户的即时发单时间,以及可以根据所述即时发单时间、所述预计上车时间和所述预计等待时间,获得用户从出发地点到目的地点的推荐发单时间。59.该具体实现过程一种情况,若所述预计上车时间大于所述预计等待时间,则可以进一步地根据所述即时发单时间、所述预计上车时间和所述预计等待时间之间的时间间隔,获得用户从出发地点到目的地点的推荐发单时间。60.在该具体实现过程中,该即时发单时间可以是表征即时发单时间点。该推荐发单时间可以是表征推荐发单时间点,或者可以是表征推荐发单时间间隔。61.该具体实现过程另一种情况,若根据预计上车时间与预计等待时间之间的时间间隔,获得用户从出发地点到目的地点的所述推荐发单时间,则所获得的用户从出发地点到目的地点的推荐发单时间可以是表征推荐发单时间间隔。62.该具体实现过程另一种情况,若根据即时发单时间、预计上车时间与预计等待时间之间的时间间隔,获得用户从出发地点到目的地点的所述推荐发单时间,则所获得的用户从出发地点到目的地点的推荐发单时间可以是表征推荐发单时间点。63.该具体实现过程再一种情况,在实际应用场景中,在用户已有约车行为下,若所述预计上车时间小于所述预计等待时间,这时实际上是已发单成功,即司机已接单,因此,可以根据预计上车时间与预计等待时间之间的时间间隔,确定向用户提供的推荐出门时间。64.该具体实现过程再一种情况,若根据所述用户当前所在地点和所述出发地点,无法确定出从所述用户当前所在地点到达所述出发地点的预计上车时间,则可以向所述用户提供所述预计等待时间,以便于用户根据所述预计等待时间和当前自身的需求情况自行确定出发时间或约车时间。65.这样,可以通过基于用户所提供的约车查询信息所获得的即时发单时间、所述预计上车时间和所述预计等待时间,可以获得所述用户从出发地点到目的地点的推荐发单时间,可以在用户已有约车行为的情况下,更加准确有效到地分析预测出适合该用户的推荐发单时间,减少用户的乘车等待时间,进一步地提升推荐信息的准确性和有效性,从而进一步地提升了约车应用服务的智能化和可靠性。66.在该实现方式的另一个具体实现过程中,在用户未有约车行为的情况下,可以根据所述历史约车数据,获取所述用户的历史发单时间,以及可以根据所述历史发单时间、所述预计上车时间和所述预计等待时间,获得所述用户从出发地点到目的地点的推荐发单时间。67.在该具体实现过程中,该历史发单时间可以是历史发单时间点。该推荐发单时间可以是推荐发单时间点。68.该具体实现过程一种情况,若所述预计上车时间小于所述预计等待时间,则可以进一步地根据所述历史发单时间点、所述预计上车时间和所述预计等待时间之间的时间间隔,获得用户从出发地点到目的地点的推荐发单时间。69.可以理解的是,在用户未有约车行为的情况下,预测用户在预定时间的约车行为,即发单,所述预计上车时间大于所述预计等待时间可以表征在预定时间进行发单可以立即约到车辆,因此,可以不为用户提供推荐发单时间。70.这样,可以通过基于历史约车数据所获得的历史发单时间、所述预计上车时间和所述预计等待时间,可以获得所述用户从出发地点到目的地点的推荐发单时间,可以在用户未有约车行为的情况下,更加准确有效到地分析预测出适合该用户的推荐发单时间,减少用户的乘车等待时间,进一步地提升推荐信息的准确性和有效性,从而进一步地提升了约车应用服务的智能化和可靠性。71.在该实现方式的再一个具体实现过程中,可以具体根据用户的移动终端设备的定位信息,确定用户当前所在地点。72.具体地,可以根据用户的移动终端设备的定位信息,确定用户当前所在地点。73.例如,可以根据用户的移动终端设备的全球导航卫星系统(globalnavigationsatellitesystem,gnss)定位信息和/移动定位信息,确定用户当前所在地点。74.这样,可以通过基于用户当前所在地点和出发地点所确定的预计上车时间,以及基于历史约车数据和实时约车数据所确定的预计等待时间,预测用户从出发地点到目的地点的推荐发单时间,可以更加准确的预测出适合该用户的推荐发单时间,进一步地提升推荐信息的准确性和有效性,从而进一步地提升了约车应用服务的智能化和可靠性。75.需要说明的是,可以将前述实现方式中所提供的确定出发地点和目的地点的多种具体实现过程,与本实现方式中所提供的预测用户从出发地点到目的地点的推荐发单时间的多种具体实现过程相结合,来实现本实施例的信息推荐的方法。详细的描述可以参见前述实现方式中的相关内容,此处不再赘述。76.可选地,在本实施例的一个可能的实现方式中,在103中,还可以进一步地在向所述用户提供所述推荐发单时间的同时,可以根据向所述用户提供所述推荐发单时间,向用户提供与所述推荐发单时间对应的约车提示信息。77.需要说明的是,可以将前述实现方式中所提供的预测用户从出发地点到目的地点的推荐发单时间的多种具体实现过程,与本实现方式中所提供的向用户提供与推荐发单时间对应的约车提示信息的方式相结合,来实现本实施例的信息推荐的方法。详细的描述可以参见前述实现方式中的相关内容,此处不再赘述。78.本实施例中,通过获取用户的历史约车数据和所述用户当前所在地点的实时约车数据,进而可以根据所述历史约车数据和所述实时约车数据,预测所述用户从出发地点到目的地点的推荐发单时间,使得能够向所述用户提供所述推荐发单时间,由于利用了用户的历史约车数据和用户当前所在地点的实时约车数据,分析预测得到适合该用户从出发地点到目的地点的推荐发单时间,可以减少用户的乘车等待时间,实现了向用户的推荐更加合理有效地约车时间,从而提升了约车应用服务可靠性。79.另外,采用本实施例所提供的技术方案,在用户进行约车查询时,可以获取到输入要查询的出发地点和目的地点等约车查询信息,通过用户所提供的约车查询信息,可以直接确定该约车查询信息中的出发地点和目的地点。由此,在用户已有约车行为的情况下,可以基于所确定的出发地点和目的地点,预测该用户从出发地点到目的地点的推荐发单时间,从而提升了预测的推荐发单时间的针对性和准确性。80.另外,采用本实施例所提供的技术方案,还可以通过根据基于历史约车数据所获得的用户的约车偏好信息,预测用户在预定时间的约车行为对应的出发地点和目的地点。由此,在用户未有约车行为的情况下,可以基于所预测的出发地点和目的地点,预测该用户从出发地点到目的地点的推荐发单时间,从而提升了预测的推荐发单时间的针对性和准确性。81.另外,采用本实施例所提供的技术方案,还可以通过基于用户所提供的约车查询信息所获得的即时发单时间、所述预计上车时间和所述预计等待时间,可以获得所述用户从出发地点到目的地点的推荐发单时间,可以在用户已有约车行为的情况下,更加准确有效到地分析预测出适合该用户的推荐发单时间,减少用户的乘车等待时间,进一步地提升推荐信息的准确性和有效性,从而进一步地提升了约车应用服务的智能化和可靠性。82.而且,还可以通过基于历史约车数据所获得的历史发单时间、所述预计上车时间和所述预计等待时间,可以获得所述用户从出发地点到目的地点的推荐发单时间,可以在用户未有约车行为的情况下,更加准确有效到地分析预测出适合该用户的推荐发单时间,减少用户的乘车等待时间,进一步地提升推荐信息的准确性和有效性,从而进一步地提升了约车应用服务的智能化和可靠性。83.另外,采用本实施例所提供的技术方案,可以通过基于用户当前所在地点和出发地点所确定的预计上车时间,以及基于历史约车数据和实时约车数据所确定的预计等待时间,预测用户从出发地点到目的地点的推荐发单时间,可以更加准确的预测出适合该用户的推荐发单时间,进一步地提升推荐信息的准确性和有效性,从而进一步地提升了约车应用服务的智能化和可靠性。84.另外,采用本实施例所提供的技术方案,可以通过基于用户的历史行为等信息预测用户未来行为,可以自动为用户提供有效建议信息,从而提升了用户对约车应用服务的智能化感知,优化用户使用体验。85.图2是根据本公开第二实施例的示意图,如图2所示。86.201、获取用户的历史约车数据。87.这里,用户的历史约车数据可以包括但不限于用户的约车偏好信息、用户出行路线信息、以及历史发单时间,即历史叫车时间。88.202、识别用户当前所在地点。89.具体地,可以根据用户的移动终端的定位信息,识别用户当前所在地点,以确定该用户当前是否到达出发地点。90.例如,通过用户的移动终端的gnss定位信息,例如gps定位信息,和/或移动定位信息,可以识别出用户当前所在地点为建筑物内部,如住宅楼,写字楼、商场、地铁/公交等交通枢纽等内部。91.203、获取用户当前所在地点的实时约车数据。92.具体地,实时约车数据可以包括但不限于用户的出发地点当前的可接单车辆数量、约车人数、车辆与用户的出发地点之间距离。93.204、确定用户的出发地点和目的地点。94.在本实施例中,在用户已有约车行为的情况下,可以获取用户所提供的约车查询信息,进而可以根据所述用户所提供的约车查询信息,确定所述出发地点和所述目的地点。95.在用户未有约车行为的情况下,可以根据所述历史约车数据,获得所述用户的约车偏好信息,进而可以根据所述用户的约车偏好信息,预测出发地点和目的地点。96.205、根据用户当前所在地点和出发地点,确定从用户当前所在地点到达出发地点的预计上车时间。97.206、根据历史约车数据和实时约车数据,确定用户立即发单到车辆到达出发地点的预计等待时间。98.至此,确定了预计上车时间和预计等待时间后,可以根据用户不同的约车行为情况,来确定用户从出发地点到目的地点的推荐发单时间,以向用户提供推荐发单时间对应的推荐信息。99.在本实施例中,在用户已有约车行为的情况下,可以执行207,以获得用户从出发地点到目的地点的推荐发单时间。100.具体地,在用户未有约车行为的情况下,可以执行208,以获得用户从出发地点到目的地点的推荐发单时间。101.207、根据用户所提供的约车查询信息,获取用户的即时发单时间,以根据即时发单时间、预计上车时间和预计等待时间,获得用户从出发地点到目的地点的推荐发单时间。102.具体地,若推荐发单时间是表征时间点,例如,9点,则可以根据即时发单时间、预计上车时间和预计等待时间,获得用户从出发地点到目的地点的推荐发单时间。103.可选地,若推荐发单时间是表征推荐发单时间间隔,即一段时长,例如,5分钟,则可以根据如下公式1计算推荐发单时间tx:104.tx=t1-t2ꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀ(1)105.其中,t1可以是预计上车时间,t2可以是预计等待时间,t1>t2。106.可以理解的是,在实际应用场景中,在用户已有约车行为下,若预计上车时间小于预计等待时间,这时实际上是已发单成功,即司机接单,因此,可以根据预计上车时间与预计等待时间之间的时间间隔,确定向用户提供的推荐出门时间。107.208、根据历史约车数据,获取用户的历史发单时间,以根据历史发单时间、预计上车时间和预计等待时间,获得用户从出发地点到目的地点的推荐发单时间。108.具体地,这里的推荐发单时间可以是表征时间点。可以根据如下公式2计算推荐发单时间tx:109.tx=t0-t1-t2ꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀ(2)110.其中,t0可以是历史发单时间,即预计出发时间,t1可以是预计上车时间,t2可以是预计等待时间,t1<t2。111.可以理解的是,在用户未有约车行为的情况下,预测用户在预定时间的约车行为,即发单,所述预计上车时间大于所述预计等待时间可以表征在预定时间进行发单可以立即约到车辆,因此,可以不为用户提供推荐发单时间。112.209、向用户提供推荐发单时间和推荐发单时间对应的推荐信息。113.在本实施例中,可以根据推荐发单时间,向用户提供推荐发单时间对应的推荐信息。114.可选地,还可以根据推荐发单时间和业务场景,确定向用户提供推荐发单时间和业务场景对应的推荐信息,并将该推荐信息发送至用户。115.具体地,推荐信息可以包括约车提示信息。推荐发单时间可以包括发单时间和推荐出门时间中的至少一个。116.例如,在用户已有约车行为的情况下,且所述预计上车时间大于所述预计等待时间,获得了用户从出发地点到目的地点的推荐发单时间之后,可以根据该推荐发单时间,向用户提供该推荐发单时间对应的约车提示信息:当前接驾速度较快,可能会导致司机较长时间等待,建议您出门后tx分钟再叫车。117.再例如,在用户已有约车行为的情况下,且预计上车时间小于预计等待时间,这时可以是已发单成功,即有司机接单,因此,获得的是用户从出发地点到目的地点的推荐出发时间。然后,可以根据该推荐出发时间,向用户提供该推荐出发时间对应的约车提示信息:当前您距离上车点较近,为了避免您较长时间等待,可在tx分钟再出发前往上车点。118.再例如,在用户未有约车行为的情况下,且所述预计上车时间小于所述预计等待时间,获得了用户从出发地点到目的地点的推荐发单时间之后,可以根据该推荐发单时间,向用户提供该推荐发单时间对应的约车提示信息:目前约车等待时间较长,根据您的预约/以往的发单时间,您现在,即在tx时间,可以开始约车了。119.可以理解的是,本实施例的信息推荐方法可以应用场景可以包括地图约车平台、其他约车平台以及约车应用程序等约车应用服务。120.采用本实施例所提供的技术方案,通过获取用户的历史约车数据和所述用户当前所在地点的实时约车数据,进而可以根据所述历史约车数据和所述实时约车数据,预测所述用户从出发地点到目的地点的推荐发单时间,使得能够向所述用户提供所述推荐发单时间,由于利用了用户的历史约车数据和用户当前所在地点的实时约车数据,分析预测得到适合该用户从出发地点到目的地点的推荐发单时间,可以减少用户的乘车等待时间,实现了向用户的推荐更加合理有效地约车时间,从而提升了约车应用服务可靠性。121.而且,通过基于用户的历史行为等信息预测用户未来行为,可以自动为用户提供有效建议信息,从而提升了用户对约车应用服务的智能化感知。122.需要说明的是,对于前述的各方法实施例,为了简单描述,故将其都表述为一系列的动作组合,但是本领域技术人员应该知悉,本公开并不受所描述的动作顺序的限制,因为依据本公开,某些步骤可以采用其他顺序或者同时进行。其次,本领域技术人员也应该知悉,说明书中所描述的实施例均属于优选实施例,所涉及的动作和模块并不一定是本公开所必须的。123.在上述实施例中,对各个实施例的描述都各有侧重,某个实施例中没有详述的部分,可以参见其他实施例的相关描述。124.图3是根据本公开第三实施例的示意图,如图3所示。本实施例的信息推荐的装置300可以包括获取单元301、预测单元302、和推荐单元303。其中,获取单元301,用于获取用户的历史约车数据和所述用户当前所在地点的实时约车数据;预测单元302,用于根据所述历史约车数据和所述实时约车数据,预测所述用户从出发地点到目的地点的推荐发单时间;推荐单元303,用于向所述用户提供所述推荐发单时间。125.需要说明的是,本实施例的信息推荐的装置的部分或全部可以为位于本地终端的应用,或者还可以为设置在位于本地终端的应用中的插件或软件开发工具包(softwaredevelopmentkit,sdk)等功能单元,或者还可以为位于网络侧服务器中的处理引擎,或者还可以为位于网络侧的分布式系统,例如,网络侧的约车平台中的处理引擎或者分布式系统等,本实施例对此不进行特别限定。126.可以理解的是,所述应用可以是安装在本地终端上的本地程序(nativeapp),或者还可以是本地终端上的浏览器的一个网页程序(webapp),本实施例对此不进行限定。127.可选地,在本实施例的一个可能的实现方式中,所述预测单元302,还可以用于获取所述用户所提供的约车查询信息,根据所述用户所提供的约车查询信息,确定所述出发地点和所述目的地点。128.可选地,在本实施例的一个可能的实现方式中,所述预测单元302,还可以用于根据所述历史约车数据,获得所述用户的约车偏好信息,根据所述用户的约车偏好信息,预测所述出发地点和所述目的地点。129.可选地,在本实施例的一个可能的实现方式中,所述预测单元302,可以具体用于根据所述用户当前所在地点和所述出发地点,确定从所述用户当前所在地点到达所述出发地点的预计上车时间,根据所述历史约车数据和所述实时约车数据,确定所述用户立即发单到车辆到达所述出发地点的预计等待时间,以及,根据所述预计上车时间和所述预计等待时间,预测所述用户从出发地点到目的地点的推荐发单时间。130.可选地,在本实施例的一个可能的实现方式中,所述预测单元,具体可以用于根据所述用户所提供的约车查询信息,获取所述用户的即时发单时间,以及根据所述即时发单时间、所述预计上车时间和所述预计等待时间,获得用户从出发地点到目的地点的推荐发单时间。131.或者,所述预测单元302,具体可以用于根据所述历史约车数据,获取所述用户的历史发单时间,以及根据所述历史发单时间、所述预计上车时间和所述预计等待时间,获得所述用户从出发地点到目的地点的推荐发单时间。132.本实施例中,通过获取单元获取用户的历史约车数据和所述用户当前所在地点的实时约车数据,进而可以由确定单元根据所述历史约车数据和所述实时约车数据,预测所述用户从出发地点到目的地点的推荐发单时间,使得校验单元能够向所述用户提供所述推荐发单时间,由于利用了用户的历史约车数据和用户当前所在地点的实时约车数据,分析预测得到适合该用户从出发地点到目的地点的推荐发单时间,可以减少用户的乘车等待时间,实现了向用户的推荐更加合理有效地约车时间,从而提升了约车应用服务的可靠性。133.另外,采用本实施例所提供的技术方案,在用户进行约车查询时,可以获取到输入要查询的出发地点和目的地点等约车查询信息,通过用户所提供的约车查询信息,可以直接确定该约车查询信息中的出发地点和目的地点。由此,在用户已有约车行为的情况下,可以基于所确定的出发地点和目的地点,预测该用户从出发地点到目的地点的推荐发单时间,从而提升了预测的推荐发单时间的针对性和准确性。134.另外,采用本实施例所提供的技术方案,还可以通过根据基于历史约车数据所获得的用户的约车偏好信息,预测用户在预定时间的约车行为对应的出发地点和目的地点。由此,在用户未有约车行为的情况下,可以基于所预测的出发地点和目的地点,预测该用户从出发地点到目的地点的推荐发单时间,从而提升了预测的推荐发单时间的针对性和准确性。135.另外,采用本实施例所提供的技术方案,还可以通过基于用户所提供的约车查询信息所获得的即时发单时间、所述预计上车时间和所述预计等待时间,可以获得所述用户从出发地点到目的地点的推荐发单时间,可以在用户已有约车行为的情况下,更加准确有效到地分析预测出适合该用户的推荐发单时间,减少用户的乘车等待时间,进一步地提升推荐信息的准确性和有效性,从而进一步地提升了约车应用服务的智能化和可靠性。136.而且,还可以通过基于历史约车数据所获得的历史发单时间、所述预计上车时间和所述预计等待时间,可以获得所述用户从出发地点到目的地点的推荐发单时间,可以在用户未有约车行为的情况下,更加准确有效到地分析预测出适合该用户的推荐发单时间,减少用户的乘车等待时间,进一步地提升推荐信息的准确性和有效性,从而进一步地提升了约车应用服务的智能化和可靠性。137.另外,采用本实施例所提供的技术方案,可以通过基于用户当前所在地点和出发地点所确定的预计上车时间,以及基于历史约车数据和实时约车数据所确定的预计等待时间,预测用户从出发地点到目的地点的推荐发单时间,可以更加准确的预测出适合该用户的推荐发单时间,进一步地提升推荐信息的准确性和有效性,从而进一步地提升了约车应用服务的智能化和可靠性。138.另外,采用本实施例所提供的技术方案,可以通过基于用户的历史行为等信息预测用户未来行为,可以自动为用户提供有效建议信息,从而提升了用户对约车应用服务的智能化感知,优化用户使用体验。139.本公开的技术方案中,所涉及的用户个人信息,例如,用户的约车信息、实时位置等的收集、存储、使用、加工、传输、提供和公开等处理,均符合相关法律法规的规定,且不违背公序良俗。140.根据本公开的实施例,本公开还提供了一种电子设备、一种可读存储介质和一种计算机程序产品。141.图4示出了可以用来实施本公开的实施例的示例电子设备400的示意性框图。电子设备旨在表示各种形式的数字计算机,诸如,膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置,诸如,个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例,并且不意在限制本文中描述的和/或者要求的本公开的实现。142.如图4所示,电子设备400包括计算单元401,其可以根据存储在只读存储器(rom)402中的计算机程序或者从存储单元408加载到随机访问存储器(ram)403中的计算机程序,来执行各种适当的动作和处理。在ram403中,还可存储电子设备400操作所需的各种程序和数据。计算单元401、rom402以及ram403通过总线404彼此相连。输入/输出(i/o)接口405也连接至总线404。143.电子设备400中的多个部件连接至i/o接口405,包括:输入单元406,例如键盘、鼠标等;输出单元407,例如各种类型的显示器、扬声器等;存储单元408,例如磁盘、光盘等;以及通信单元409,例如网卡、调制解调器、无线通信收发机等。通信单元409允许电子设备400通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。144.计算单元401可以是各种具有处理和计算能力的通用和/或专用处理组件。计算单元401的一些示例包括但不限于中央处理单元(cpu)、图形处理单元(gpu)、各种专用的人工智能(ai)计算芯片、各种运行机器学习模型算法的计算单元、数字信号处理器(dsp)、以及任何适当的处理器、控制器、微控制器等。计算单元401执行上文所描述的各个方法和处理,例如信息推荐的方法。例如,在一些实施例中,信息推荐的方法可被实现为计算机软件程序,其被有形地包含于机器可读介质,例如存储单元408。在一些实施例中,计算机程序的部分或者全部可以经由rom402和/或通信单元409而被载入和/或安装到电子设备400上。当计算机程序加载到ram403并由计算单元401执行时,可以执行上文描述的信息推荐的方法的一个或多个步骤。备选地,在其他实施例中,计算单元401可以通过其他任何适当的方式(例如,借助于固件)而被配置为执行信息推荐的方法。145.本文中以上描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、场可编程门阵列(fpga)、专用集成电路(asic)、专用标准产品(assp)、芯片上系统的系统(soc)、复杂可编程逻辑设备(cpld)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括:实施在一个或者多个计算机程序中,该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释,该可编程处理器可以是专用或者通用可编程处理器,可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令,并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。146.用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器,使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行,作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。147.在本公开的上下文中,机器可读介质可以是有形的介质,其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备,或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦除可编程只读存储器(eprom或快闪存储器)、光纤、便捷式紧凑盘只读存储器(cd-rom)、光学储存设备、磁储存设备、或上述内容的任何合适组合。148.为了提供与用户的交互,可以在计算机上实施此处描述的系统和技术,该计算机具有:用于向用户显示信息的显示装置(例如,crt(阴极射线管)或者lcd(液晶显示器)监视器);以及键盘和指向装置(例如,鼠标或者轨迹球),用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互;例如,提供给用户的反馈可以是任何形式的传感反馈(例如,视觉反馈、听觉反馈、或者触觉反馈);并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。149.可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如,作为数据服务器)、或者包括中间件部件的计算系统(例如,应用服务器)、或者包括前端部件的计算系统(例如,具有图形用户界面或者网络浏览器的用户计算机,用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如,通信网络)来将系统的部件相互连接。通信网络的示例包括:局域网(lan)、广域网(wan)和互联网。150.计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。服务器可以是云服务器,也可以为分布式系统的服务器,或者是结合了区块链的服务器。151.应该理解,可以使用上面所示的各种形式的流程,重新排序、增加或删除步骤。例如,本发公开中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行,只要能够实现本公开公开的技术方案所期望的结果,本文在此不进行限制。152.上述具体实施方式,并不构成对本公开保护范围的限制。本领域技术人员应该明白的是,根据设计要求和其他因素,可以进行各种修改、组合、子组合和替代。任何在本公开的精神和原则之内所作的修改、等同替换和改进等,均应包含在本公开保护范围之内。当前第1页12当前第1页12
再多了解一些

本文用于企业家、创业者技术爱好者查询,结果仅供参考。

发表评论 共有条评论
用户名: 密码:
验证码: 匿名发表

相关文献