CN110969269A - 搭乘请求交互 - Google Patents

Abstract

本公开提供了“搭乘请求交互”。诸如运输管理服务的提供商可以管理针对在各个位置之间的许多搭乘者的运输。顾客可以请求在不同位置之间进行运输。所述提供商可以分析针对显著信息，诸如与开始位置和结束位置相对应的信息的请求，并且确定在所述显著信息中是否存在将阻止所述提供商提供所述请求的服务的错误。当所述提供商检测到错误时，所述提供商可以从所述顾客请求附加信息，以纠正所述错误。

Description

搭乘请求交互

技术领域

本公开总体上针对允许搭乘请求交互以便满足请求的***和方法，以及用于搭乘请求和搭乘请求修改的错误纠正过程。

背景技术

人们越来越多地转向各种不同的交通和出行服务，除了常规的公共交通服务，诸如火车和公交车外，还包括共乘和电动自行车。共乘可能涉及为搭乘者分配在一段时间内专用于那些搭乘者的车辆，或为搭乘者分配可能具有同时搭乘的其他乘客的车辆上的座位。虽然单独分配的小汽车可以带来一些好处，但共享小汽车可以降低成本并且提供关于调度的一些确定性。然而，多个同时发生的搭乘者之间共享车辆可能具有各种约束，这是因为搭乘者可能想要关于搭乘时间和到达目的地的时间的一些确定性，使得路线的灵活性可能受到限制。

发明内容

本文描述和建议的方法涉及在指定位置之间提供运输。本文提供了公开内容，其涉及用于以有限的数据传输使用文本和语音请求来请求、修改和确认在指定位置之间的运输安排的方法。所述请求可能涉及将人、动物、包裹或其他物体或乘客从始发地位置运输到目的地位置。所述请求还可以包括时间分量，诸如所请求的出发或到达时间。诸如运输服务的提供商可以利用请求验证过程来评估文本或语音请求，以确定附加信息是否将澄清或以其他方式使得请求能够被提供商确认。可以应用一个或多个文本或语音提取过程来从请求中识别显著信息。在验证了显著信息之后，可以向用户提供确认。用户和提供商之间的不同通信可以进行交换以提供附加信息。

用户可以经由具有有限移动数据能力的用户装置请求运输。例如，用户装置可能不是“智能手机”，但也许仍能够连接到蜂窝网络以进行语音和短消息服务(SMS)通信，只是没有被配置用于互联网数据通信。用户装置可能缺乏下载和安装移动应用程序以在用户装置上执行的能力。用户装置也许能够进行数据通信，但是诸如当用户到国外旅行时或当用户已经超过分配数量的数据通信时，这种通信可能被关闭。因此，本文描述和建议的方法可以涉及例如，通过经由蜂窝语音网络的通信和/或SMS通信的在用户装置上具有减少的或有限的数据负载的运输请求。如本文将描述的，语音网络通信和/或SMS通信可能缺乏与通过数据网络进行的请求相关的某些特性，诸如GPS定位服务和与提供商的聊天功能。因此，可以简化请求、澄清和确认，以减少数据传输，并且还减少在请求运输服务时出现混乱或通信错误的可能性。

提供商可以建立呼叫中心以经由语音通信接收来自用户的请求。呼叫中心可以是自动化的或基本上是自动化的，以接收来自用户的语音命令，分析所述语音命令以获取显著信息，诸如上车位置、搭乘者数量、日期、时间、目的地位置、时间分量等。呼叫中心可以向用户提供提示，诸如“请提供上车位置。”或“您希望什么时间到达目的地？”因此，在各个实施例中，用户可以利用传统的电话服务来调度搭乘，而无需利用移动用户装置，诸如蜂窝电话。这对于没有蜂窝电话的年龄较大或不那么富裕的用户来说可能是有利的。

提供商可以例如基于人口统计信息、先前的请求等来建立预定的下车位置和上车位置。例如，预定的下车位置可以对应于“停车并搭乘”位置，其中公交车服务可以将用户带到市中心或第二预定的下车位置。预定的下车可以具有代码或标签，其可能与来自用户的请求相关联。例如，用户可以请求在“停车和搭乘2”处下车，而不是提供街道地址和/或十字路口。这可以简化针对提供商的文本评估和验证过程。类似地，提供商可以在人口中心内建立预定的上车位置。可以特别地选择这些上车位置，以使用户的步行距离最小化，例如，在设定数量的街区或英里内。此外，在各个实施例中，上车位置也可以具有代码或标签。因此，用户可以请求“从邻区B到停车和搭乘2的搭乘”，而不是请求“从Elm和Spruce的十字路口到Smith和Main的十字路口的搭乘”。代码和/或标签可以简化验证过程并且还简化了针对用户的请求过程，这可以改善用户体验并且激励用户继续服务。

附图说明

参考附图阐述具体实施方式。相同参考标号的使用可指示类似或相同项。各个实施例可以利用除了附图中示出的那些之外的元件和/或部件，并且一些元件和/或部件可能不存在于各个实施例中。附图中的元件和/或部件未必是按比例绘制的。贯穿本公开，取决于上下文，单数和复数术语可以互换使用。

图1示出了示例搭乘请求环境，其中可以实现各个实施例的各方面。

图2A、图2B和图2C示出了可能生成的通知流，其指示搭乘请求、确认和针对附加信息的请求，其中可以实现各个实施例的各方面。

图3A、图3B、图3C、图3D、图3E、图3F、图3G和图3H示出了可能生成的用于请求和修改搭乘的示例通知流，其中可以实现各个实施例的各方面。

图4示出了可以用于实现各个实施例的各方面的示例***。

图5示出了根据各个实施例可以利用的用于接收和验证搭乘请求的示例过程。

图6示出了根据各个实施例可以利用的用于接收和验证搭乘请求的示例过程。

图7示出了根据各个实施例可以利用的用于接收和验证搭乘请求的示例过程。

图8示出了根据各个实施例可以利用的用于确定运输选项的示例过程。

具体实施方式

图1示出了示例位置100，其中可以实现各个实施例的各方面。在这个示例中，用户可以使用例如，在客户端计算装置上执行的应用程序，诸如通过蜂窝网络的语音服务，或诸如SMS的文本消息服务来请求从起点102到目的地位置104的运输。在各个实施例的范围内，也可以使用诸如通过替代的消息传递或电话机制来提交请求的各种其他方法。此外，可以接收来自正在运输的或被调度要进行运输的物体或代表所述物体的请求中的至少一些。例如，客户端装置可以用于提交针对物体、包裹或其他可交付物的初始请求，并且随后可以从例如物体，或与该装置相关联的装置或机构接收后续请求。可以使用其他通信，如可能涉及指令、调用、命令和其他数据传输的通信来代替请求。对于本文讨论的各个实施例，除非另有说明，否则“客户端装置”不应被狭义地解释为常规计算装置，并且根据各个实施例，能够接收、传输或处理数据和通信的任何装置或部件可以充当客户端装置。

一些通信可以包括使用单独的蜂窝网络的消息传输。例如，诸如请求的一则消息可以使用第一蜂窝网络进行传输，而诸如确认的第二消息则可以使用第二蜂窝网络进行传输。在一些实例中，第一蜂窝网络和第二蜂窝网络可以是相同的网络或可以是单独的网络。

可以使用能够同时运输一个或多个搭乘者的一个或多个车辆(或其他运输模式)来提供运输。尽管如本文所使用的搭乘者可能通常指人类乘客，但应当理解，在各个实施例中的“搭乘者”也可以指非人类的搭乘者或乘客，如可以包括动物或无生命物体，诸如要交付的包裹。向从出发点至到达点的单个搭乘者提供的搭乘也可能涉及用于相同或不同运输模式的一个或多个车辆，其可以是相同的类型或不同的类型。例如，在图1中，运输服务的顾客可能想要使用服务来获取从指定的起点102或出发点，诸如用户的家到指定的目的地104或到达点，诸如用户的工作地点的运输。可能存在用户可以采用的多种不同的路线106、108、110以到达目的地104。例如，路线106可以包括将用户从起点102直接带到目的地104的运输服务。但是，路线108和路线110可以包括中间站112、114，诸如公交车站(其可以称为停车和搭乘)，其使用户就位以采用第二运输服务以到达目的地104。因此，尽管路线108、110可以向用户指示最终目的地104，但是运输服务可能仅向中间站112、114提供运输，并且使得用户能够为出行的剩余部分选择不同的运输模式和/或提供商。

在各个实施例的范围内，也可以使用各种其他类型的位置或指定位置的方式。可能提供有使用固定路线(诸如火车或公交车)、半固定路线(诸如穿梭巴士)、灵活路线(诸如乘客车辆的共乘)或完全灵活性(诸如电动自行车或小型摩托车)及其他此类选项的运输模式。尽管在一些情况下，更灵活的选项，诸如共乘可以提供最短的行进时间，但与固定路线的选项，诸如地铁或公交车相比，它们的成本也更高。此外，诸如共乘的灵活路线可能会受到交通拥堵或其他问题的影响，所述交通拥堵或其他问题可能会给到达时间等引入额外的不确定性。

顾客或搭乘者可以选择在其行程中的至少一些中采用固定路线运输。例如，由于公交车的相对较低的成本和频繁的可用性，用户可能乘坐公交车离开市中心。这些公交车可以前往一个或多个站点，用户可以从所述一个或多个站点获取接驳运输(如果需要或期望的话)，以完成行程的剩余部分。用户可能希望在公交车的时间安排或初始运输模式方面具有灵活性，诸如能够沿给定路线赶上下一辆可用的公交车。用户可能还希望能够从多个可用路线中进行选择以获取额外的选项。如图1中所示，可能存在许多公交车路线，其沿基本上固定的路线从起点，诸如接近用户的家的公交车站到一个或多个目的地。用户可能愿意采用源于起点102的这些路线中的任何一条，特别是在高峰时间或恶劣天气下。

起点102可以直接提供给运输服务作为开始服务的位置。例如，用户可以提供与起点102相对应的地址或十字路口。此外，如图1中所示，预定的上车位置116、118可以布置在整个位置100中。例如，可以基于人口中心、预期的客流量、过去的上车历史等特别地布置上车位置116、118。因此，用户可以将原点104指定为上车位置116、118中的一个。上车位置116、118可以对应于与位置116、118相关联的代码或标签(诸如“Elm街1”或“邻区2”)或与其相关联，以区分上车位置，并且如下面将描述的，以简化从用户接收的请求的处理和验证。这些标签可以包括在地图或位置资源中包括的元数据。

图2A至图2C示出了用户可以向提供商提供的以请求上车和下车的示例消息流。例如，如果用户无法访问“智能手机”，或针对用户装置的互联网数据服务不起作用，或用户选择不使用数据服务(诸如用户漫游或在国外旅游的情况下)，用户则可以经由文本消息传递服务，诸如SMS来提交搭乘请求。如下面将要描述的，启用这样的请求/验证服务可能使用户无需访问能够提供互联网数据服务的装置即可使用服务并且对于不希望使用互联网数据服务的用户来说也可能很有吸引力。

显示器200可以包括用户提交的请求202。如上所述，请求202采用文本消息通信的形式，诸如SMS。请求202包括可由提供商用来识别请求和/或与请求配合的信息，其在本文中可以称为显著信息。例如，在所示的请求202中，显著信息可以对应于上车位置204、目的地206、搭乘者208的数量、时间210(例如，时间分量)和日期212。如下面将描述的，可以利用一种或多种文本提取服务来解析在请求202中提供的信息，以便验证请求并向用户提供确认。

图2B示出了显示器200和从提供商提供回给用户的确认214。确认214可以基于一个或多个因素，诸如提供足够的信息的用户和/或对应于提供商的一个或多个需求的信息。例如，提供商可以建立确定是否发送确认的一组规则，诸如如果请求未能识别上车位置或时间，则不发送确认。图2C示出了提供商向用户提供的以尝试获取附加信息的返回请求216。返回请求216可以包括提示218和对应于提供商满足用户的请求所需信息的标识符220。由于可以经由SMS以及验证服务传输的数据量有限，因此返回请求216可以包括简化消息或短消息，其寻求快速且直接地识别显著信息。即，返回请求216可以被识别为让用户提供一条或多条信息的提示。可以针对每条显著信息向用户提供不同的返回请求216。另外，由于单个返回请求216可以包括针对多条信息的提示。提供商可以从用户获取信息以使提供商能够发起所请求的运输服务。

图3A至图3H示出了根据各个实施例的可以提供的以显示给用户、搭乘者或其他这样的实体的示例消息流。用户可以提供针对搭乘的请求，从提供商接收指示所述请求无效的提示，向提供商提供附加信息，从提供商接收确认，从提供商请求改变，并且接收指示所请求的改变的第二确认。

图3A包括用户提交的请求300。请求300可以对应于针对在特定日期的特定时间在两个位置之间的搭乘的请求。所述请求是针对“3点从Smith街和第34大街到Main的搭乘“。请求300中的多条信息中的一条或多条可以被提供商视为显著信息，诸如上车位置302、目的地304和时间306。当与图2A中的请求相比时，几条信息可以被认为是丢失了或不完整的。例如，没有关于搭乘者数量的指示。另外，“3点”没有指示搭乘将发生在上午3点还是下午3点。此外，用于上车位置302和/或目的地304的十字路口可能是不正确和/或不完整的。例如，没有与“Main”交叉的街道，这可能会被提供商标记为无效。然而，在将提示提供回用户之前，可以利用本文所述的验证服务的一个或多个特征以确定位置。例如，如果在“Main”上仅存在一个预定的下车位置，提供商则可以接受这样的目的地304。这样，由用户提交的请求300可以被提供商视为不完整的，并且因此，提供商可能不会提供确认。

图3B示出了返回请求308，其提示用户提供附加信息以完成请求300。应当理解，返回请求308仅作为示例，并且提供商可以基于由提供商建立的用于确定是否接收到有效请求的一个或多个规则来请求更多条或更少条的附加信息。返回请求308包括“请提供有效的下车位置、时间和日期。”然而，应当理解，用户可以提供单独的返回请求308以接收目的地位置304、时间306和日期310。即，提供商可以传输第一返回请求308，等待响应，验证该响应并且随后传输后续的返回请求308，直到获取足够的显著信息以验证来自用户的请求。

如上所述，请求300和返回请求308是经由SMS传输的，并且因此，所提供的信息和/或请求的简单性对于提供改善的用户体验来说可能是重要的。例如，用户可能接收到返回请求308并且不知道为什么需要附加信息。相应地，图3C中的返回请求312向用户提供额外的指导，以简化获取足够信息来验证请求300的过程。返回请求312包括通过指示需要十字路口而针对目的地位置304的指导。另外，针对时间306的指导指示应指定上午还是下午。最后，针对日期的指导310请求针对搭乘的日期。应当理解，可以提供其他类型的指导或请求，并且返回请求312仅作为示例。例如，如图3D中所示，提供商可以将返回请求314传输到用户，所述返回请求314包括模板316，其指示应如何布置/组织给提供商的信息。模板316可以包括所请求的组成部分的顺序、时间格式、日期格式等。因此，可以快速检查和验证来自用户的与该格式相对应的响应。如下面将描述的，利用针对请求的模板对于提取信息来说可能是有益的。然而，在各个实施例中，用户可能难以记住模板，并且因此，可以利用不同的文本评估和提取方法。

图3E示出了从用户返回到提供商的提示响应318。用户已纠正了所标识的错误，并且以所请求的格式返回了响应。然而，应当理解，在其他实施例中，用户可以提供提示响应318作为带有一些附加信息的初始请求300的重复，作为对返回请求308的直接响应，或采用启用请求300的验证的任何其他格式。在接收到提示响应318之后，提供商可以分析新信息，将新信息与从原始请求300获取的信息相关联，并且验证是否做出了有效请求。

图3F示出了在确定用户的请求是有效的之后，从提供商给用户的确认320。确认320向用户重复显著信息以使用户能够进一步验证请求已被提供商理解和处理。然而，应当理解，确认320可以不将所有信息中继回用户。确认320还可包括修改指令322，以使用户能够改变或更新他们的请求。修改指令322可以包括密钥或代码以响应于提供商，以便开始更新请求300的过程。应当理解，附加信息，诸如数字代码可以与修改指令322一起提供，以使提供商能够识别预订和/或要将消息发送到的不同的号码。即使在接收到确认之后，用户仍具有修改或取消其请求的功能。

图3G示出了从用户传输到提供商的修改请求324的示例。用户可能已经通过包括代码(在这个实施例中为“M”)并随后提供关于期望修改的信息来遵循修改指令322。例如，用户已经请求改变上车时间。图3H示出了从提供商传输到用户的修改确认326的示例。如图所示，提供商与用户确认新时间，并且进一步提供修改指令322以启用来自用户的进一步的修改，以便调节或调整其请求。

提供商还可以向用户提供其他通信，并且还可以请求附加信息。例如，在向用户提供确认后，提供商可以请求用户的照片以帮助驾驶员识别用户。另外，提供商可以向用户提供更新，诸如指示驾驶员可能迟到或指定车辆的品牌或型号。这样，虽然可以使用关于更新信息和确认的通信，但是可以实践在用户和提供商之间的不同通信交换以改善用户体验。

图4示出了示例***400，其可以用于管理从各种类型的计算装置402上的一个或多个用户接收的搭乘请求。如上所述，可以经由低数据的通信协议或无数据的通信协议，诸如蜂窝语音网络和SMS来传输搭乘请求。可以通过至少一个网络404提交请求以由服务提供商环境408的接口层406接收。计算装置可以是已知的或用于提交电子请求的任何适当的装置，如可以包括台式计算机、笔记本计算机、智能手机、平板计算机和可穿戴计算机及其他此类选项。此外，计算装置可以是没有互联网数据功能的非智能手机或旧式手机。网络可以包括用于传输请求的任何适当的网络，如可以包括使用有线或无线连接，诸如互联网、蜂窝数据连接、Wi-Fi连接、局域网连接(LAN)等的公共网络和专用网络的任何选择或组合。服务提供商环境可以包括已知的或用于接收和处理电子请求的任何资源，如可以包括各种计算机服务器、数据服务器和网络基础设施，如本文其他地方所讨论的。接口层可以包括接口(诸如应用程序编程接口)、路由器、负载平衡器以及用于接收和路由请求或其他接收到服务提供商环境的通信的部件。

从用户装置402传输到服务提供商环境408的请求可以被路由到请求服务器410。请求服务器410可以将请求转换成适当的格式，诸如将语音请求转录成书面请求或将SMS消息转换成文本字符串以用于以后的处理。请求服务器410可以利用自动语音识别(ASR)、自然语言理解(NLU)、上下文解释器、自然语言生成器等来将听觉请求转换成可以在服务提供商环境内处理的文本请求。此外，在各个实施例中，请求服务器410可以与请求处理器412通信。请求处理器412经由请求服务器410接收如上所述可能已经被转换或变换成不同格式的请求，并且从请求中提取显著信息。例如，请求处理器412可以使用光学字符识别(OCR)来从请求中提取某些单词或数字。即，在各个实施例中，请求处理器412包括文本辨认和识别过程以识别在文本字符串内的显著信息以进行提取和使用。辨认和识别过程可以利用多种技术，诸如解析单词或短语、截断单词以及识别消息的相关部分以用于以后的分析和验证。

数据存储器414可由请求处理器412访问。如上所述，数据存储器414可以包括模板，以便从请求中提取和识别显著信息。例如，请求可以由请求处理器412通过就单词相对于来自数据存储器414的模板的位置来评估单词而进行处理，结果是，由于在模板上的位置中识别出了单词或数字，单词或数字可以被提取和识别为一条或多条显著信息，诸如上车位置或时间。此外，在各个实施例中，数据存储器414可以包括由一个或多个代码或标签标识的位置列表。例如，数据存储器414可以包括用于“邻区2”的标签，其对应于地址。因此，如果请求包括标签“邻区2”，请求处理器412则将标签与相应的地址相关联以识别上车位置或下车位置。应当理解，用于促进数据的处理和验证的其他各条信息可以被包括在数据存储器414中，如下面将进一步详细描述的。

在提取显著信息之后，请求处理器412可以与所示的请求验证器416通信以评估显著信息，以确定是否已将有效请求供应给提供商。请求验证器416可以访问数据存储器414以获取一条或多条信息，诸如上述模板、一组规则等，以确定请求是否有效。例如，在各个实施例中，请求验证器416可以确定位置是否包括地址、有效十字路口或预定代码。此外，请求验证器416可以确定时间是否包括上午或下午指示符以及是否已输入有效日期。

请求验证器416与通信地联接到路线数据库420的路线管理器418通信。路线管理器418可以评估城市中心内的各个位置或用户的位置，以在给定来自用户的一个或多个偏好的情况下，确定可接受的路线是否是可用的。例如，请求可以指示用户期望换乘去公园和搭乘位置，以便随后在市区办公室位置下车。路线管理器418可以访问路线数据库420以确定停车和搭乘是否提供了公交车以将用户带到市区办公室位置。如果否，路线管理器418则可以将信息传达给请求验证器416，其随后可以经由确认模块422将响应返回给用户。确认模块422可以例如经由接口层406将信息中继回用户。如上所述，确认模块422可以向用户提供指示请求已被成功接收并且有效的消息，或当指示请求无效时，确认模块422可以从用户请求附加信息。

请求服务器410可以进一步与有权访问用户数据库426的账户管理器424通信。用户数据库426可以存储关于用户的信息，诸如支付信息、人口统计信息、喜欢的位置等。账户管理器424可以在接收到请求时评估用户的账户是否有效或具有良好信誉，并且进一步沿不同的位置跟踪请求，例如，在上车和下车时，以随后向用户收取使用服务的费用。因此，服务提供商环境408可以向车队428提供与用户请求有关的信息，车队然后可以根据从请求中接收到的指令来使用户上车和/或下车。

服务提供商环境408可以被配置或适配为确定针对用户的运输请求。运输请求指定选自起点、目的地或时间分量的显著信息。这些个别元素中的任一个或其组合可以进行错误分析。服务提供商环境408可以解析运输请求并且确定运输请求是否包括错误。通常，错误将包括任何差异或缺少显著信息，这会阻止运输请求的完成。如上所述，比较和验证功能可以存在于请求验证器416中。

服务提供商环境408可以进一步被配置为将请求传输到用户以纠正运输请求。请求可以标识出产生错误的显著信息的一部分。如果接收到纠正的信息，服务提供商环境408的请求验证器416则可以基于从用户接收的纠正的显著信息来确定是否纠正了错误。在一个示例中，可以请求用户纠正产生错误的地址。向用户提供的信息可以标识出导致错误的显著信息的特定部分。如果纠正的显著信息解决了错误，服务提供商环境408则可以将确认传输到用户。

图5示出了用于接收和确认搭乘请求的示例过程500。应当理解，对于本文讨论的这个过程和其他过程而言，除非另有说明，否则在各个实施例的范围内可能存在有以类似的或替代的步骤或并行地执行的额外的、更少的或替代的步骤。接收到针对行程的请求(502)。行程可能是从用户的家到最终目的地。然而，在其他实施例中，行程可以表示全程的一部分，例如，至中间位置，在中间位置处，可以利用不同的运输方式以到达用户的最终目的地。所述过程还可以包括从请求中提取显著信息(504)。例如，搭乘提供商可以利用一种或多种听觉或文本处理技术来利用服务提供商环境408从请求中提取信息，以便提取显著信息，其可以对应于上车位置、下车位置、时间、日期、搭乘者的数量等。接下来，可以分析提取信息以确定其是否是有效请求(506)。例如，有效的请求可以对应于提供了足够的信息以启用行程。如本文所使用的，足够可以指代使得服务提供商能够向用户提供请求的行程的信息的阈值水平。例如，充足性可以对应于例如当时间在固定时间表上时，提供上车位置和下车位置。另外，充分性可以对应于提供上车位置、下车位置、时间和日期。此外，充分请求的组成部分可以与为上车位置和下车位置提供有效的街道地址或十字路口有关。应当理解，提供商可以特别地确定什么构成足够，并且可以利用一种或多种其他技术，诸如机器学习或数据存储应用程序，以使由用户提供的信息与提供商关联或以其他方式联系起来。

提供商可以分析请求是否有效(508)。例如，没有提供足够的显著信息或提供了不正确的显著信息的请求可以被认为是无效的，并且提供商可以将消息传输到请求附加信息的用户(510)。不正确或错误的信息可能与运输请求中被确定为完成运输请求所必需的任何部分有关。例如，由于服务提供商确定指定的目的地位置不可解析(例如，无法根据映射信息确定)，因此目的地位置中的错误数字可能导致识别出错误目的地。

然而，如果确定请求有效，提供商则可以将确认消息传输到用户(512)。以这种方式，简化的搭乘请求(例如使用SMS或语音服务的)可以由搭乘提供商分析和满足，其中用户未在其用户装置上使用互联网数据服务。

图6示出了用于分析来自用户的搭乘请求的示例过程600。接收到来自用户的请求(602)，例如针对从第一位置到第二位置的搭乘。在各个实施例中，可以经由使用有限的互联网数据服务或不使用互联网数据服务的SMS或语音通信来传输请求。因为可以以各种低数据的格式或无数据的格式传输请求，所以过程可以进一步包括将请求转换成可操作格式(604)，例如，转换成文本字符串。如上所述，在各个实施例中，可以通过语音通信来传输请求，并且可以利用语音识别服务来将语音请求转换成文本格式，可以由搭乘提供商进一步分析文本格式。

可以分析请求以获取显著信息(606)。例如，可以利用一种或多种信息分析和提取技术来处理转换的请求，以便识别可以由提供商预先确定的显著信息。显著信息可以由其在请求中的位置来识别，例如，对应于模板。当分析信息时可以建立一个或多个规则，以产生某些信息对应于显著信息的置信度。例如，可以分析像“从点B到点A的搭乘”这样的短语，以使得在“到”之后的位置可能是目的地，并且在“从”之后的位置可能是起点。此外，在各个实施例中，可以利用指示某些显著信息的其他信息，诸如与“上午”或“下午”相关联的数字，以指示时间。这种分析可以使提供商能够提取显著信息以准备所请求的搭乘。

在获取显著信息之后，过程可以确定是否存在与显著信息相关联的错误(608)。例如，错误可能对应于提供商无法识别的地址。另外，错误可能对应于未指定的时间、未指定的日期、无法理解的请求、未指定的上车位置或下车位置或可能导致难以或不太可能按请求完成搭乘的任何其他错误。如果没有错误，提供商则可以将确认传输到用户(616)，确认可以包括关于调度的搭乘的信息。

可能检测到错误，并且过程可以确定错误对应于哪条显著信息(610)。例如，当指定十字路口时，错误可能与没有提供地址或相关联的交叉街道的上车位置相关联。通过确定特定错误，可以利用用户最初用来传输请求的低数据的传输服务或无数据的传输服务来将未来的纠正措施传输到用户。例如，过程可以包括将请求传输到用户以提供更新(612)。请求对于要更新或纠正的一条特定显著信息来说可能是有教益的。此外，请求可以包括模板以向用户说明如何格式化他们的响应。接下来，接收到更新或纠正的搭乘请求(614)。更新或纠正的搭乘请求可以包括完整的搭乘请求、搭乘请求的一部分或对所请求的显著信息的更新。然后，可以处理更新或纠正的搭乘请求以评估是否有进一步的错误，直到可以传输确认为止。

图7示出了用于接收对确认的搭乘请求的修改的示例过程700。在这个示例中，接收到来自用户的搭乘请求(702)。如上所述，在各个实施例中，可以从很少使用互联网数据服务或不使用互联网数据服务的用户装置传输搭乘请求。在接收到请求之后，分析请求的有效性并且确定其是有效的(704)。例如，可以从请求中提取多条不同的显著信息，并且将其与已知的信息，诸如数据库中的信息关联起来。显著信息可以包括上车位置、下车位置、时间、日期、搭乘者的数量等。当请求有效时，向用户提供确认(706)。确认可以伴随有修改请求的选项(708)。例如，确认可以包括向用户提供代码等以修改先前请求的指令。这样的修改可以与由用户先前提供的任何显著信息有关。

过程确定是否接收到修改请求(710)。如果否，维持原始请求并且对原始请求起作用(712)。然而，如果例如经由接收由搭乘提供商提供的代码或其他指令而接收到修改请求，则可以分析修改的请求(714)。例如，如上所述，可以将修改的请求与原始请求进行比较以识别正在改变的一条或多条显著信息。如上所述，可以评估修改的请求的有效性(716)，以确定改变是否能使搭乘继续。例如，无效的改变可能指定了过去的时间。如果请求无效，则可以请求附加信息(718)。如果请求有效，则可以提供更新的确认(720)。以这种方式，用户具有更新并且改变其请求的选项。

图8示出了用于确定运输选项的过程800。在这个示例中，接收到对应于运输请求的第一消息(802)。例如，第一消息可以是SMS通信，其包括指示针对第一位置和第二位置之间的行程的请求的文本信息。如上所述，运输请求可以包括一条或多条信息，诸如上车位置、下车位置、搭乘者的数量、一天中的时间、日期等。可以分析第一消息以获取至少最小量的信息(804)。例如，最小量的信息可以对应于使得能够选择和完成运输请求的一条或多条信息。最小量的信息可以对应于上车位置、下车位置和时间。然而，在其他实施例中，更多条或更少条的信息可能足以提供最小量的信息。例如，上车位置可以是中间位置，在中间位置处，连续轮值的车辆车队可用于按需接受搭乘者。因此，可能不需要时间来提供足够的信息以满足运输请求。应当理解，可以利用各种语音或文本处理***来分析第一消息。例如，可以利用文本识别和提取来比较第一消息的各个部分，以确定是否存在最小量的信息(806)。

如果存在最小量的信息，则确定运输选项(812)。然而，如果不存在最小量的信息，则可以传输请求澄清至少一条信息以满足最小量的第二消息。如上所述，至少一条信息可以对应于上车位置、下车位置、时间等。接收到澄清至少一条信息的第三消息(810)。例如，如果第二消息指示需要下车位置，第三消息则可以提供下车位置以澄清至少一条信息。在接收到澄清信息之后，可以确定运输选项(812)。传输第四消息，其提供了关于确定的运输选项的信息(814)。如上所述，第四消息可以是确认消息。以这种方式，消息传递服务可以用于提交运输请求。

在上述公开中，已参考了附图，所述附图构成本公开的一部分并且示出其中可以实践本公开的具体实现方式。应当理解，在不脱离本公开的范围的情况下可以利用其他实现方式且可以进行结构改变。在说明书中对“一个实施例”、“一实施例”、“一个示例实施例”等的参考表示所描述的实施例可以包括特定特征、结构或特性，但每个实施例可能不一定包括所述特定特征、结构或特性。此外，这样的短语不一定指相同的实施例。而且，当结合一个实施例描述特定特征、结构或特性时，无论是否进行明确描述，本领域的技术人员仍将认识结合其他实施例实现的这种特征、结构或特性。

本文公开的***、设备、装置和方法的实现方式可以包括或利用专用或通用计算机，其包括计算机硬件，诸如本文所讨论的一个或多个处理器和***存储器。本公开的范围内的实现方式还可以包括用于携载或存储计算机可执行指令和/或数据结构的物理和其他计算机可读介质。此类计算机可读介质可以是能够由通用或专用计算机***存取的任何可用介质。存储计算机可执行指令的计算机可读介质为计算机存储介质(装置)。承载计算机可执行指令的计算机可读介质为传输介质。因此，通过举例但非限制地，本公开的实现方式可包括至少两种明显不同种类的计算机可读介质：计算机存储介质(装置)和传输装置。

计算机存储介质(装置)包括RAM、ROM、EEPROM、CD-ROM、固态驱动器(“SSD”)(例如，基于RAM)、闪速存储器、相变存储器(“PCM”)、其他类型的存储器、其他光盘存储装置、磁盘存储装置或其他磁性存储装置或可用于存储期望的程序代码手段并且可以由通用或专用计算机访问的任何其他介质，所述程序代码手段呈计算机可执行指令或数据结构的形式。

本文公开的装置、***和方法的实现方式可以通过计算机网络进行通信。“网络”被定义为使得电子数据能够在计算机***和/或模块和/或其他电子装置之间传输的一条或多条数据链路。当信息通过网络或另一通信连接(硬连线、无线或者硬连线或无线的组合)传输或提供给计算机时，计算机正确地将所述连接视为传输介质。传输介质可以包括可用于以计算机可执行指令或数据结构的形式承载所需程序代码手段并且可由通用或专用计算机访问的网络和/或数据链路。上述组合也应当包括在计算机可读介质的范围内。

例如，计算机可执行指令包括在处理器上执行时使得通用计算机、专用计算机或专用处理装置执行特定功能或功能组的指令和数据。例如，计算机可执行指令可以是二进制代码、中间格式指令诸如汇编语言、或者甚至是源代码。尽管用结构特征和/或方法动作专用的语言描述了主题，但应当理解的是，所附权利要求书中限定的主题不必限于上述特征或动作。而是，所描述的特征和动作被公开为实现权利要求的示例性形式。

本领域技术人员将理解的是，本公开可以通过许多类型的计算机***配置在网络计算环境中实践，所述计算机***配置包括内置式车辆计算机、个人计算机、台式计算机、膝上型计算机、消息处理器、手持装置、多处理器***、基于微处理器或可编程的消费电子产品、网络PC、小型计算机、大型计算机、移动电话、PDA、平板电脑、寻呼机、路由器、交换机、各种存储装置等。本公开还可以在本地和远程计算机***两者都执行任务的分布式***环境中实践，所述本地和远程计算机***通过网络链接(通过硬连线数据链路、无线数据链路或通过硬连线和无线数据链路的任何组合)。在分布式***环境中，程序模块可以位于本地存储器存储装置和远程存储器存储装置两者中。

此外，在适当的情况下，本文描述的功能可以在硬件、软件、固件、数字部件或模拟部件中的一个或多个中执行。例如，一个或多个专用集成电路(ASIC)可以被编程以执行本文所描述的***和过程中的一个或多个。贯穿说明书和权利要求使用的某些术语指代特定***部件。如本领域技术人员应当了解，可以通过不同的名称来引用部件。本文档无意区分名称不同但功能相同的部件。

应当注意，上面讨论的传感器实施例可以包括计算机硬件、软件、固件或其任何组合，以执行其功能中的至少一部分。例如，图中公开的任何部件可以包括计算机代码，其被配置成在一个或多个处理器中执行并且可以包括由计算机代码控制的硬件逻辑/电路。这些示例性装置在本文中出于说明的目的提供而无意进行限制。如相关领域的技术人员将了解的，本公开的实施例可以在其他类型的装置中实现。

本公开的至少一些实施例涉及包括存储在任何计算机可用介质上的这种逻辑(例如，呈软件的形式)的计算机程序产品。当在一个或多个数据处理装置中执行时，这种软件致使装置如本文所描述进行操作。

尽管上面已描述了本公开的各个实施例，但是应当理解，其都是仅以示例的方式呈现的，而不是用于限制。对于相关领域的技术人员来说显而易见的是，在不脱离本公开的精神和范围的情况下，可以在其中进行形式和细节上的各种改变。因此，本公开的广度和范围不应受上述示例性实施例中的任一个的限制，而应仅根据下列权利要求及其等同物来限定。已经出于说明和描述的目的呈现了前面的描述。其不旨在是穷举的或将本公开限制于所公开的精确形式。鉴于上述教导，许多修改和变化都是可能的。此外，应当注意，任何或所有上述替代实现方式可以按期望的任何组合使用，以形成本公开的额外的混合实现方式。例如，相对于特定装置或部件描述的任何功能可通过另一个装置或部件来执行。进一步，虽然已经描述了特定装置特性，但是本公开的实施例可涉及许多其他装置特性。进一步，尽管已经用结构特征和/或方法动作特定的语言描述了实施例，但是应当理解，本公开不必限于所描述的具体特征或动作。相反，具体特征和动作被公开为实现实施例的说明性形式。除非另外特别说明，或者在所用的上下文中另外理解，否则诸如“能够”、“可以”、“可能”或“可”等条件语言通常意图表示，尽管其他实施例可能不包括，但某些实施例可包括某些特征、元件和/或步骤。因此，此类条件语言通常不旨在暗示特征、元件和/或步骤无论如何都是一个或多个实施例所需要的。

根据本发明，一种计算机实现的方法包括：接收针对用户的运输请求，所述运输请求至少指定起点、目的地和时间分量；分析针对显著信息的所述运输请求，所述显著信息对应于所述起点、目的地和时间分量中的至少一者；确定所述运输请求包括错误，所述错误阻止所述运输请求的完成；将请求传输到所述用户以更新包括所述错误的所述显著信息，其中所述请求标识出包括所述错误的特殊显著信息；接收包括更新的显著信息的更新的运输请求；验证纠正了所述错误；以及向所述用户提供确认。

根据一个实施例，上述发明的特征还在于，从所述用户接收修改的运输请求；通过识别与所述运输请求中的所述显著信息不同的修改的显著信息来分析所述修改的运输请求；验证所述修改的显著信息不包含错误；以及向所述用户提供更新的确认。

根据一个实施例，上述发明的特征还在于，向对应于所述请求的所述用户提供模板以更新所述显著信息，所述模板与用于提交更新的显著信息的格式相对应。

根据一个实施例，上述发明的特征还在于，使用自然语言处理、自动语音识别或光学字符识别中的至少一者将所述运输请求转换成可操作的格式。

根据一个实施例，通过蜂窝语音网络或短消息服务来传输运输请求。

根据一个实施例，上述发明的特征还在于，向所述用户提供更新的通信，所述更新的通信包括估计的到达时间，识别运输模式的特性或针对附加信息的请求中的至少一者。

根据本发明，一种计算机实现的方法，包括：从电信装置通过电信信道接收第一消息，所述消息包括运输请求，其对应于在指定时间的在第一位置和第二位置之间的行程；分析所述消息的内容，以确定用于所述行程的至少最小量的信息是否可根据所述请求进行确定；响应于确定不可根据所述请求确定最小量的信息，将第二消息发送到所述电信装置，所述第二消息请求澄清用于所述行程的需要正确确定以满足所述最小量的至少一条信息；从所述电信装置接收澄清所述至少一条信息的第三消息；确定用于提供所述运输请求的运输选项；以及将第四消息传输到所述电信装置，所述第四消息包括用于所述确定的运输选项的信息。

根据一个实施例，上述发明的特征还在于，向所述电信装置提供具有所述第二消息的模板，所述模板指定呈现至少一条信息所用的格式。

根据一个实施例，上述发明的特征还在于，从所述电信装置接收第五消息，所述第五消息包括更新请求，所述更新请求对应于从所述第一位置到所述第二位置的所述行程的变化；分析所述第五消息的内容，以确定用于所述行程的至少最小量的信息是否可根据所述请求进行确定以及是否与至少一条信息不同；以及响应于确定最小量的信息可根据所述请求进行确定并且至少一条信息是不同的，确定用于提供所述更新请求的更新运输选项。

根据一个实施例，所述最小量的信息对应于上车位置、下车位置、时间或日期中的至少一者。

根据一个实施例，所述第一消息、所述第二消息、所述第三消息和所述第四消息采用短消息服务的形式。

根据一个实施例，上述发明的特征还在于，向所述电信装置提供具有所述第四消息的代码，所述代码对应于改变所述运输选项的请求。

根据一个实施例，上述发明的特征还在于，向所述电信装置提供第五消息，所述第五消息包括估计的到达时间或识别所述运输选项的特性中的至少一者。

根据一个实施例，上述发明的特征还在于，将第五消息传输到所述电信装置，所述第五消息包括在所述第一位置或所述第二位置中的至少一者的预定距离内的第三位置，所述第三位置对应于所述行程的起始位置或结束位置中的一者。

根据一个实施例，上述发明的特征还在于，将第五消息传输到所述电信装置，所述第五消息包括第二运输选项；以及从所述电信装置接收第六消息，所述第六消息包括选择所述运输选项或所述第二运输选项中的一者的决定。

根据本发明，一种计算机实现的方法包括：接收独立于互联网数据通信通过蜂窝网络传输的对应于运输请求的文本消息通信；确定所述运输请求提供预定的最小量的信息以使得能够完成所述运输请求；以及经由第二文本消息通信确认独立于互联网数据通信通过第二蜂窝网络传输的所述运输请求。

根据一个实施例，所述第一蜂窝网络和所述第二蜂窝网络是相同的。

根据一个实施例，上述发明的特征还在于，确定所述运输请求未提供所述预定的最小量的信息；以及将第三文本消息传输到所述第一消息的发送者，所述第三文本消息是针对至少一条信息的请求以使得能够完成所述运输请求。

根据一个实施例，上述发明的特征还在于，向所述第一消息的发送者提供第三消息，所述第三消息包括估计的到达时间或识别所述运输请求的运输选项的特性中的一者。

根据一个实施例，所述预定的最小量的信息对应于上车位置、下车位置、时间或日期中的至少一者。

根据本发明，一种方法包括：确定针对用户的运输请求，所述运输请求指定选自起点、目的地或时间分量的显著信息；确定所述运输请求包括错误，所述错误阻止所述运输请求的完成；将请求传输到所述用户以纠正所述运输请求，所述请求标识出产生所述错误的所述显著信息的一部分；基于从所述用户接收的纠正的显著信息来确定纠正了所述错误；以及向所述用户提供确认。

根据一个实施例，上述发明的特征还在于，确定与所述运输请求中的所述显著信息不同的修改的显著信息；验证所述修改的显著信息不包含错误；以及向所述用户提供更新的确认。

根据一个实施例，上述发明的特征还在于，向对应于所述请求的所述用户提供模板以更新所述显著信息的所述部分，所述模板与用于提交所述显著信息的所述部分的格式相对应。

根据一个实施例，上述发明的特征还在于，使用自然语言处理、自动语音识别、光学字符识别、其组合和排列中的任一种将所述运输请求转换成可操作的格式。

根据一个实施例，通过蜂窝语音网络或短消息服务来传输运输请求。

根据一个实施例，上述发明的特征还在于，向所述用户提供更新的通信，所述更新的通信包括估计的到达时间，识别运输模式的特性或针对附加信息的请求。

根据本发明，一种方法包括：从电信装置通过电信信道接收第一消息，所述第一消息包括运输请求，其对应于在指定时间的在第一位置和第二位置之间的行程；确定用于所述行程的最小量的信息是否可根据所述运输请求进行确定；当不可根据所述请求确定所述最小量的信息时，将第二消息发送到所述电信装置，所述第二消息请求澄清用于所述行程的所述信息的一部分；从所述电信装置接收澄清所述信息的所述部分的第三消息；确定用于提供所述运输请求的运输选项；以及将第四消息传输到所述电信装置，所述第四消息包括用于所述确定的运输选项的信息。

根据一个实施例，上述发明的特征还在于，向所述电信装置提供具有所述第二消息的模板，所述模板指定呈现所述信息的所述部分的格式。

根据一个实施例，上述发明的特征还在于，从所述电信装置接收第五消息，所述第五消息包括更新请求，所述更新请求对应于从所述第一位置到所述第二位置的所述行程的变化；分析所述第五消息的内容，以确定用于所述行程的最小量的信息是否可根据所述更新请求进行确定；以及确定用于提供所述更新请求的更新运输选项。

根据一个实施例，所述最小量的信息对应于上车位置、下车位置、时间或日期。

根据一个实施例，所述第一消息、所述第二消息、所述第三消息和所述第四消息是短消息服务消息。

根据一个实施例，上述发明的特征还在于，向所述电信装置提供具有所述第四消息的代码，所述代码对应于改变所述运输选项的请求。

根据一个实施例，上述发明的特征还在于，向所述电信装置提供第五消息，所述第五消息包括估计的到达时间或识别所述运输选项的特性中的至少一者。

根据一个实施例，上述发明的特征还在于，将第五消息传输到所述电信装置，所述第五消息包括在所述第一位置或所述第二位置的预定距离内的第三位置，所述第三位置对应于所述行程的起始位置或结束位置中的一者。

根据一个实施例，上述发明的特征还在于，将第五消息传输到所述电信装置，所述第五消息包括第二运输选项；以及从所述电信装置接收第六消息，所述第六消息包括选择所述运输选项或所述第二运输选项中的一者的决定。

根据本发明，提供了一种***，其具有：处理器；以及用于存储指令的存储器，所述处理器执行存储在存储器中的所述指令以：确定针对用户的运输请求，所述运输请求指定选自起点、目的地或时间分量的显著信息；确定所述运输请求包括错误，所述错误阻止所述运输请求的完成；将请求传输到所述用户以纠正所述运输请求，所述请求标识出产生所述错误的所述显著信息的一部分；基于从所述用户接收的纠正的显著信息来确定纠正了所述错误；以及向所述用户提供确认。

根据一个实施例，所述处理器被配置为确定与所述纠正的显著信息不同的修改的显著信息；验证所述修改的显著信息不包含错误；以及向所述用户提供更新的确认。

根据一个实施例，所述处理器被配置为独立于互联网数据通信通过第一蜂窝网络传输所述请求，所述请求为文本消息；以及独立于互联网数据通信通过第二蜂窝网络传输所述确认，其中所述第一蜂窝网络和所述第二蜂窝网络是相同的。

根据一个实施例，所述处理器被配置为将消息传输到所述用户，所述消息包括估计的到达时间或识别所述运输请求的运输选项的特性。

根据一个实施例，所述处理器被配置为向对应于所述请求的所述用户提供模板以更新所述显著信息的所述部分，所述模板与用于提交所述显著信息的所述部分的格式相对应。

根据一个实施例，所述处理器被配置为向所述用户提供更新的通信，所述更新的通信包括针对附加信息的请求。

Claims (15)

1.一种方法，其包括：

确定针对用户的运输请求，所述运输请求指定选自起点、目的地或时间分量的显著信息；

确定所述运输请求包括错误，所述错误阻止所述运输请求的完成；

将请求传输到所述用户以纠正所述运输请求，所述请求标识出产生所述错误的所述显著信息的一部分；

基于从所述用户接收的纠正的显著信息来确定纠正了所述错误；以及

向所述用户提供确认。

2.如权利要求1所述的方法，其还包括：

确定与所述运输请求中的所述显著信息不同的修改的显著信息；

验证所述修改的显著信息不包含错误；以及

向所述用户提供更新的确认。

3.如权利要求1所述的方法，其还包括向对应于所述请求的所述用户提供模板以更新所述显著信息的所述部分，所述模板与用于提交所述显著信息的所述部分的格式相对应。

4.如权利要求1所述的方法，其还包括使用自然语言处理、自动语音识别、光学字符识别、其组合和排列中的任一种将所述运输请求转换成可操作的格式。

5.如权利要求1所述的方法，其中通过蜂窝语音网络或短消息服务来传输运输请求。

6.如权利要求1所述的方法，其还包括向所述用户提供更新的通信，所述更新的通信包括估计的到达时间，识别运输模式的特性或针对附加信息的请求。

7.一种方法，其包括：

从电信装置通过电信信道接收包括运输请求的第一消息，所述运输请求对应于在指定时间的在第一位置和第二位置之间的行程；

确定用于所述行程的最小量的信息是否可根据所述运输请求进行确定；

当不可根据所述请求确定所述最小量的信息时，将第二消息发送到所述电信装置，所述第二消息请求澄清用于所述行程的所述信息的一部分；

从所述电信装置接收澄清所述信息的所述部分的第三消息；

确定用于提供所述运输请求的运输选项；以及

将第四消息传输到所述电信装置，所述第四消息包括用于所述确定的运输选项的信息。

8.如权利要求7所述的方法，其还包括向所述电信装置提供具有所述第二消息的模板，所述模板指定呈现所述信息的所述部分所用的格式。

9.如权利要求7所述的方法，其还包括从所述电信装置接收第五消息，所述第五消息包括更新请求，所述更新请求对应于从所述第一位置到所述第二位置的所述行程的变化；

分析所述第五消息的内容，以确定用于所述行程的最小量的信息是否可根据所述更新请求进行确定；以及

确定用于提供所述更新请求的更新运输选项。

10.如权利要求7所述的方法，其中所述最小量的信息对应于上车位置、下车位置、时间或日期。

11.如权利要求7所述的方法，其中所述第一消息、所述第二消息、所述第三消息和所述第四消息是短消息服务消息。

12.如权利要求7所述的方法，其还包括向所述电信装置提供具有所述第四消息的代码，所述代码对应于改变所述运输选项的请求。

13.如权利要求7所述的方法，其还包括向所述电信装置提供第五消息，所述第五消息包括估计的到达时间或识别所述运输选项的特性中的至少一者。

14.如权利要求7所述的方法，其还包括将第五消息传输到所述电信装置，所述第五消息包括在所述第一位置或所述第二位置的预定距离内的第三位置，所述第三位置对应于所述行程的起始位置或结束位置中的一者。

15.如权利要求7所述的方法，其还包括：

将第五消息传输到所述电信装置，所述第五消息包括第二运输选项；以及

从所述电信装置接收第六消息，所述第六消息包括选择所述运输选项或所述第二运输选项中的一者的决定。

Images