Travel invitation method and system

Abstract

One or more embodiments of the present application provide a system for itinerary invitation, comprising: a server side comprising a computer readable storage medium having an executable instruction, a processor communicating with the computer readable storage medium, and a server side comprising a server side, wherein the executable instruction can be configured to, when executed, enable the processor to: obtain a travel invitation of a first client for a second client, the travel invitation including first client identification information and a location sharing request; and sending the travel invitation to the second client.

Description

[0001] This application is a divisional application of an invention patent application filed by Ford Global Technologies Corporation, entitled “Method and System for Trip Invitation,” with application number 201910139076.5 and filing date February 25, 2019. Technical Field

[0002] The present application relates to a method and system for vehicle trip invitation / invitation, and in particular to a method and system for convenient point-to-point trip invitation. Background Art

[0003] With the development of technology, people are finding it easier to choose travel services. Various ride-hailing platforms are widely used, and shared vehicle services such as carpooling and ride-sharing are also widely accepted.

[0004] Currently, platforms that provide travel services can provide great convenience. Generally, users place demand orders, and the platform receives the demand orders and dispatches the orders in various ways to complete the transaction. One or more users can also complete carpooling transactions through the platform. For example, patent application CN107169815A, "A Method and Apparatus for Carpooling among Acquaintances," discloses a method and apparatus for carpooling among acquaintances, including: upon receiving the destination address and starting address information provided by the user, displaying the address book contact window on the current user's device; upon receiving at least one contact identifier selected by the user, sending a carpooling request to the server, the carpooling request including: the destination address of the current user's device, the starting address of the current user's device, at least one contact identifier, and / or the departure time.

[0005] However, the platforms provided in the existing technology are difficult to meet the needs of car owners to actively, quickly and directly invite others to share pick-up addresses and plan routes. Summary of the Invention

[0006] The above advantages and other advantages and features of the present application will become apparent from the following detailed description read alone or in conjunction with the accompanying drawings.

[0007] According to one aspect of the present application, a system for trip invitation is provided. The system can include a server end comprising a computer readable storage medium having executable instructions, a processor in communication with the computer readable storage medium, the executable instructions being configurable to cause the processor to perform the following steps when executed: obtaining a trip invitation from a first client to a second client, the trip invitation comprising first client identification information and a request for sharing of a geographic location of the second client; and sending the trip invitation to the second client. Unlike general ride-hailing software or trip sharing platforms, which require both parties to use the same software / application and communicate and operate through the specific software, the present application does not require the driver and passenger to use the same software platform and can successfully complete positioning and pick-up. In addition, unlike real-time location sharing in general software, the present application does not require both parties to use a location sharing software and can conveniently communicate information between the driver and the passenger.

[0008] In one embodiment, the request for sharing of the geographic location comprises a link to a map of the server end.

[0009] In another embodiment, the link is an HTML link.

[0010] In yet another embodiment, the steps further comprise, in response to the second client accepting the trip invitation, synchronizing the geographic location of the second client to the map of the server end and further sending to the first client.

[0011] In yet another embodiment, the steps further comprise, in response to the second client accepting the trip invitation, receiving the geographic location of the second client and sending the geographic location of the second client to the first client.

[0012] In yet another embodiment, the steps further comprise planning a travel path based on the geographic location of the second client.

[0013] In yet another embodiment, the step of planning a travel path based on the geographic location of the second client is performed at the first client.

[0014] In yet another embodiment, the steps comprise sending a rejection reminder to the first client when the second client rejects the invitation.

[0015] In yet another embodiment, the steps comprise displaying trip invitation options associated with contacts in a phonebook of the first client.

[0016] In yet another embodiment, the steps comprise displaying trip invitation options associated with contacts of the first client in a call interface of the first client.

[0017] In another embodiment, the steps include displaying a trip invitation option on a map interface of a first application on a first client, and synchronizing address book contacts to the first application in response to receiving user authorization and sending a trip invitation to a specific contact on a map interface of the first application.

[0018] In another embodiment, the steps include not synchronizing the address book contacts to the first application in response to receiving the user's rejection of authorization for address book synchronization, and sending the travel invitation to the specific contact by the user inputting the contact number.

[0019] In yet another embodiment, the step includes receiving input from the second client to receive the second client's new ride location.

[0020] In another embodiment, the step includes receiving input from the second client and issuing a query option to the second client on whether to relocate the second client's boarding position, and when the second client confirms the relocation, receiving the second client's new boarding position.

[0021] In another embodiment, the steps include presenting the updated ride location to the first client and asking the first client whether to accept the updated ride location, and when the first client confirms, determining the new ride location as the target location.

[0022] In yet another embodiment, the step includes receiving input from the first client to accept the first client's suggested new pick-up location.

[0023] In another embodiment, the step includes receiving input from the first client and sending a query option to the first client whether to suggest a new pick-up location, and when the first client confirms that it wants to suggest a new pick-up location, locating the new pick-up location of the first client.

[0024] In another embodiment, the steps include presenting the new pick-up location to the second client and asking the second client whether to accept the new pick-up location, and when the second client confirms, the processor is configured to determine the new pick-up location as the target location.

[0025] In yet another embodiment, the step includes further planning a driving path according to the target location.

[0026] In yet another embodiment, the step of further planning a driving route according to the target location is completed on the first client.

[0027] In another embodiment, wherein the first client is a vehicle personnel client, the step includes synchronizing the electronic map displayed by the vehicle personnel client with the server-side map in real time.

[0028] In another embodiment, the geographic location sharing request for the second client is a geographic location sharing request, and the steps include sharing the geographic locations of the first client and the second client with each other in response to the second client accepting the travel invitation.

[0029] In yet another embodiment, the steps include sending the geographic location and destination of the second client to the first client in response to the second client accepting the travel invitation.

[0030] In yet another embodiment, the steps include receiving a geographic location and a destination sent by the second client in response to the second client accepting the trip invitation, and planning a route based on the geographic location and the destination.

[0031] According to another aspect of the present application, a system for trip invitations is provided. The system may include: a first client including a computer-readable storage medium having executable instructions; and a processor in communication with the computer-readable storage medium, wherein the executable instructions are configured to, when executed, cause the processor to perform the following steps: obtaining user input to send a trip invitation to a second client, the trip invitation including identification information of the first client and a request to share a geographic location with the second client; sending the trip invitation to the second client in the form of a short message; and, in response to the second client accepting the trip invitation, receiving the geographic location sent by the second client.

[0032] In one embodiment, the geographic location sharing request includes an HTML link.

[0033] In another embodiment, the step includes receiving, by the first client, a geographical location sent from the second client in the form of a short message or other instant messaging form.

[0034] In another embodiment, the steps include further interpreting the geographic location and marking the geographic location on a map interface of the first client and performing route planning.

[0035] According to another aspect of the present application, a device for making a trip invitation is provided. The device may include a computer-readable storage medium having executable instructions, and a processor in communication with the computer-readable storage medium. The executable instructions, when executed, may cause the processor to perform the following steps: obtaining user input, and sending a trip invitation to a specific contact based on the user selecting the specific contact, the trip invitation including user identification information and a request to share a location for the specific contact.

[0036] In one embodiment, the geographic location sharing request includes a link to a server-side map.

[0037] In another embodiment, when the device is using an offline map, the geographic location sharing request includes a text request, and the geographic location feedback includes at least one of an image and latitude and longitude data.

[0038] In another embodiment, the step includes sending the trip invitation via a short message. In other examples, the trip invitation can be sent in any suitable instant messaging manner.

[0039] In yet another embodiment, the steps include displaying travel invitation options associated with contacts of the device.

[0040] In yet another embodiment, the steps include displaying a travel invitation option associated with a specific contact in a call interface.

[0041] In another embodiment, the steps include displaying a trip invitation option on a map interface of the first application, and synchronizing address book contacts to the first application in response to receiving user authorization and sending a trip invitation for a specific contact on the map interface of the first application.

[0042] In another embodiment, the steps include receiving the user's authorization to reject the synchronization of the address book and not synchronizing the address book contacts to the first application, and sending the travel invitation to the specific contact by the user inputting the contact number.

[0043] In yet another embodiment, the device is a portable mobile terminal or a vehicle-mounted computer terminal.

[0044] In yet another embodiment, the trip invitation is a ride invitation or a pick-up request for the second client.

[0045] In yet another embodiment, the steps include displaying a quick call option on the first application map interface.

[0046] In yet another embodiment, the steps include receiving photos sent by a specific contact and displaying them on a map interface of the device.

[0047] In another embodiment, the photo includes a street view photo of the location of the specific contact, and the street view photo is displayed in the form of a floating window on the map interface.

[0048] According to another aspect of the present application, a system for trip invitations is provided. The system may include: a server comprising a computer-readable storage medium having executable instructions, and a processor in communication with the computer-readable storage medium. The executable instructions, when executed, may cause the processor to: obtain a trip invitation from a first client to a second client, the trip invitation including identification information of the first client and a pickup request for the second client; and send the trip invitation to the second client, where the first client is a passenger and the second client is a vehicle passenger.

[0049] In one embodiment, the trip invitation further includes a link to a server-side map.

[0050] In another embodiment, the travel invitation further includes the geographic location of the first client.

[0051] In yet another embodiment, the steps include synchronizing the geographic location of the first client to a server-side map and further sending the map to the first client in response to the second client accepting the trip invitation.

[0052] In yet another embodiment, the steps include receiving the geographic location of the first client and sending the geographic location of the first client to the second client in response to the second client accepting the trip invitation.

[0053] In yet another embodiment, the step includes planning a driving route based on the geographic location of the first client.

[0054] 在又一个实施例中,其中步骤包括将第一客户端的地理位置设为目标位置而规划行驶路径。

[0055] In yet another embodiment, the step includes when the second client rejects the invitation, the processor is configured to send a rejection reminder to the first client.

[0056] In yet another embodiment, the step includes displaying a travel invitation option associated with a contact in the address book on the first client.

[0057] In yet another embodiment, the step includes displaying a travel invitation option associated with a contact of the first client on the call interface.

[0058] According to another aspect of the present invention, a method for scheduling a trip is provided. The method may include: sending a trip invitation via a first client to a second client, wherein the trip invitation includes a request for sharing a geographic location of the second client; receiving feedback from the second client via the first client, wherein when the second client accepts the trip invitation, the second client sends its geographic location to the first client.

[0059] In one embodiment, the geographic location sharing request includes a link to an electronic map, and the geographic location of the second client is sent to the first client in the form of a mark on the map.

[0060] In another embodiment, the geographic location sharing request includes a text request, and the geographic location feedback includes at least one of a picture and latitude and longitude data.

[0061] In another embodiment, the geographic location sharing request includes a link to a server electronic map, and the geographic location feedback is synchronized to the server network in the form of a marker on the map and further sent to the first client. In another embodiment, when the second client rejects the trip invitation, a rejection message is sent to the first client.

[0062] According to another aspect of the present application, a device including a navigation application is provided. The device including the navigation application may include: a computer-readable storage medium having executable instructions, and a processor in communication with the computer-readable storage medium. The executable instructions, when executed, may be configured to cause the processor to perform the following steps: obtaining user input in a navigation interface, and sending a travel invitation to a specific contact in response to the user selecting the specific contact. The travel invitation may include the user's identification information and a request to share the location of the specific contact.

[0063] In one embodiment, the geographic location sharing request includes a link to a server-side map, and the travel invitation can be sent via a short message or other instant messaging method.

[0064] In another embodiment, the steps may include displaying a trip invitation option on the navigation interface, and synchronizing the address book contacts to the navigation application in response to receiving user authorization and sending the trip invitation to the specific contact on the navigation interface.

[0065] In another embodiment, the steps include not synchronizing the address book contacts to the navigation application in response to receiving the user's rejection of authorization for address book synchronization, and sending a trip invitation for the specific contact by the user inputting the contact number.

[0066] In yet another embodiment, the steps further include displaying a quick call option on a navigation interface of the navigation application.

[0067] In yet another embodiment, the step further includes receiving a photo sent by a specific contact and displaying the photo on the navigation interface.

[0068] In yet another embodiment, the steps further include receiving the specific contact's geographic location and planning a route in response to the specific contact accepting the trip invitation. In other embodiments, the steps further include receiving the specific contact's geographic location and a destination in response to the specific contact accepting the trip invitation, and planning a route based on the specific contact's geographic location and the destination. BRIEF DESCRIPTION OF THE DRAWINGS

[0069] For a more complete understanding of the embodiments of the present application, reference should be made to the embodiments illustrated in more detail in the accompanying drawings and described below by way of example, in which: Figure 1 An example of interaction with a vehicle trip invitation system in one embodiment is shown; Figure 2 An example block topology diagram of a vehicle computer system (VCS) for a vehicle is shown; Figure 3 An embodiment is shown that can be used Figure 1 An exemplary method flow chart of a vehicle trip invitation system is shown; Figure 4 A schematic diagram of a trip invitation interface of a first client in one embodiment is shown; Figure 5 A schematic diagram of a travel invitation interface of a first client in another embodiment is shown; Figures 6A-6B A schematic diagram of a travel invitation interface of a first client in another embodiment is shown; Figure 7 A schematic diagram of an interface showing a failure in sending a travel invitation from a first client in an embodiment is shown; Figure 8 A schematic diagram of an interface in which a first client waits for feedback from a second client in an embodiment is shown; Figure 9 A schematic diagram of a travel invitation interface received by a second client in one embodiment is shown; Figure 10A A schematic diagram of an interface for a second client to accept a travel invitation in one embodiment is shown; Figure 10B A schematic diagram showing an interface for a second client to accept a travel invitation and interact with a first client in another embodiment is shown; Figure 11 A schematic diagram of an interface showing a failure in sending the second client location in an embodiment is shown; Figure 12 A schematic diagram of an interface showing a first client receiving a location in an embodiment is shown; Figure 13 A schematic diagram of an interface for planning a route after a first client receives a location in an embodiment is shown; Figure 14 FIG. 1 shows a first client and a second client interface schematic diagram of a path update in an embodiment; Figure 15 FIG. 2 shows a first client and a second client interface schematic diagram of a trip invitation completion in an embodiment. DETAILED DESCRIPTION

[0070] For the sake of brevity, the disclosure will not be burdened with a description of all possible specific embodiments and configurations that can be implemented. Those skilled in the art will appreciate that many other configurations are possible, and that the specific embodiments and configurations described herein are only examples of possible implementations.

[0071] Detailed embodiments of the application are disclosed herein; however, it is to be understood that the disclosed embodiments are merely examples of the present application, which can be embodied in various alternatives. The Figures are not necessarily drawn to scale; some features can be exaggerated or minimized for the sake of clarity and presentation. Therefore, the specific structural and functional details disclosed herein are not to be interpreted as limiting, but merely as a representative basis for teaching one skilled in the art to variously employ the present application.

[0072] As mentioned in the background section, with the development of technology, the current travel service providing platform can provide more convenience for users. Generally, the operation is that the user issues a demand order, the platform receives the demand order and assigns the order in various ways to complete the transaction. One or more users can also complete a carpooling transaction through the platform and share the cost of using the car, saving costs. However, the inventors of the present application realize that the above various platforms are based on completing transactions and cannot provide the convenience of picking up and dropping off acquaintances for the driver. In addition, the use of the above platform requires both the driver and the passenger to use the platform, and cannot provide convenience between users who do not install the same application. In some cases, when the driver needs to pick up an elderly person such as a parent, grandparent, etc., the passenger who needs to be picked up may not be familiar with the use of the new application and do not know how to clearly express the location. The driver needs to communicate the location multiple times by phone, which is very inconvenient and not conducive to traffic safety. Based on one or more problems in the prior art, the inventors of the present application provide a trip invitation device, system and method in one or more embodiments, which is believed to solve one or more problems in the prior art. The trip invitation can refer to a trip invitation, a pick-up invitation, a request to pick up or an invitation initiated by one party to a specific other party.

[0073] One or more embodiments of the present application will be described below with reference to the accompanying drawings. The flowcharts illustrate the processes performed by the system. It is understood that the execution of the flowcharts does not need to be in order, and one or more steps may be omitted, one or more steps may be added, and the steps may be performed in order or in reverse order, and in some embodiments, one or more steps may be performed simultaneously.

[0074] The following embodiments may involve "first client", "second client", "car owner" and "passenger". In one or more embodiments, they are used to illustrate the interaction between the two parties of the trip invitation. In some cases, the roles can be exchanged without departing from the spirit of this application.

[0075] The vehicles involved in the following embodiments may include various types of passenger vehicles (such as crossover utility vehicles (CUVs), sport utility vehicles (SUVs)), buses, trucks, recreational vehicles (RVs), boats, airplanes or other mobile machines for transporting people or goods, as well as combinations thereof.

[0076] The positioning technologies involved in this application may include but are not limited to GPS (Global Positioning System), global satellite navigation system, wireless fidelity positioning system, compass navigation system and other positioning technologies and combinations thereof.

[0077] Figure 1An example of client interaction within a trip request system 100 in accordance with one or more embodiments is shown. As shown, in one embodiment, a system 100 for trip requesting is provided. System 100 may include a server 102, a first client 104 in communication with server 102. First client 104 may include, for example, a mobile phone 104A or a vehicle computer system / headset 104B, and a second client 106 in communication with server 102. Server 102 may conventionally include a computer-readable storage medium and a processor to store data instructions and process data. It should be understood that a "server" or "server" referred to herein or elsewhere may refer to a device that provides computer services, a physical or virtual computer that responds to service requests and performs processing. This may include a physical device or a cloud server that performs computations on a cloud platform. Cloud platforms may include private, public, hybrid, community, industry, or intermediate clouds. The server or server referred to herein is not specific and may be a combination of one or more of the above, as long as it can provide the required communication, storage, and computing services. The first client 104 and the second client 106 can be any form of mobile device, roaming device, etc. In one embodiment, the first client 104 can be the vehicle owner or driver or a passenger on one side of the vehicle (in some embodiments, they can be collectively referred to as the vehicle passenger side), and the second client 106 can be the passenger side. The vehicle passenger side can specifically include various forms of terminals, such as mobile phones, vehicle computer systems (VCS) (for example, the following reference Figure 2 VCS 1) described in the vehicle navigation device (such as the following reference Figure 2 The vehicle navigation device 60 or the personal navigation device 54 described above, etc. The passenger terminal 106 may also include a portable device such as a mobile phone.

[0078] Continue to refer Figure 1As indicated by the information flow of arrow 108, server 102 can obtain a trip invitation from a first client 104 (e.g., 104A shown in the figure, although it is understood that 104B or other first clients 104 can also initiate trip invitations) via the network. Unlike typical trip-sharing software platforms, the trip invitation sent by first client 104 is directed to or targeted at a specific second client 106, rather than publishing a trip or route on a platform that is visible to and open to all. Second client 106, or the passenger, can receive the trip invitation via a mobile device such as a mobile phone. As indicated by the information flow of arrow 110, server 102 can further send the trip invitation to second client 106 via an instant messaging method such as a short message. When second client 106 accepts the trip invitation, its geographic location, as indicated by arrow 112, is synchronized with server 102. Furthermore, as shown by arrow 114, the first client 104 may receive synchronization information of a map indicating the geographic location of the second client 106 from the server 102, thereby determining the location of the second client 106 and subsequently planning a route. Figure 1 The diagram schematically illustrates the vehicle computer 104B receiving the geographic location. Those skilled in the art will appreciate that a mobile phone 104A or other device used by the vehicle occupant could also be used to receive the geographic location and perform navigation. Alternatively, in some cases, the first client 104A and the vehicle computer 104B could be interconnected in any feasible manner, allowing either to receive the geographic location of the second client 106 and perform route planning and navigation. Route planning can be performed on the server 102 or the first client 104. Of course, the server 102 or the first client 104 may include memory, instructions, and a processor to perform route calculation and optimization.

[0079] Furthermore, those skilled in the art will appreciate that, in one or more embodiments, the first client and / or the second client, whether on a mobile phone or on a vehicle, may be installed with a navigation application. This navigation application may be a standalone application or include navigation functionality embedded within another application, and this is not specifically limited herein. Here and elsewhere, the terms "map interface" or "navigation interface" may be used interchangeably to refer to a map page that provides route guidance to a user.

[0080] exist Figure 1In the illustrated embodiment, the first client 104 and the second client 106 complete the sending of the itinerary invitation, the confirmation of the geographical position via the server 102, wherein the itinerary invitation can include a link or a web address pointing to a server-side map, the object pointed by the link or the web address being visible to both the first client 104 and the second client 106. Of course, in other embodiments, the object pointed by the link or the web address can be visible only to the first client 104. In one or more embodiments, the first client 104 can enter an online or offline electronic map, the electronic map being synchronized in real time or selectively with the server-side 102 map. The term "sending" here or elsewhere can be interpreted broadly to include the propagation of a message over an appropriate network, and in one or more embodiments, the sending includes synchronization. Furthermore, the server-side map can refer to an electronic map stored in an appropriate manner on the server device as mentioned above. In this embodiment, the subsequent calculation of the path can be done by the first client 104 itself or by the server 102.

[0081] In some embodiments, the interaction of the first client 104 and the second client 106 can be done directly via the network. For example, the first client 104 can send an itinerary invitation including a web link to the second client 106, and the first client 104 can also enter the web link and view the acceptance status of the second client 106 in real time and share the real-time position with it. In other words, the mutual positioning and the sharing of the position can be done via a network electronic map, and of course in this implementation, the background of the electronic map associated with the web link needs to provide a relevant permission allocation and management unit to ensure that the first client 104 and the second client 106 can have appropriate mutual visibility permissions without affecting the use of others.

[0082] Although the above embodiment shows that the first client 104 and the second client 106 interact through the server 102, confirming their locations and interacting with each other via a map stored on the server 102, in another embodiment, as indicated by dashed line 116, the first client 104 and the second client 106 can interact more directly without using a server-side map. In this embodiment, the trip invitation system 100 may also include the first client 104 and the second client 106. The first client 104 may similarly include a computer-readable storage medium containing executable instructions and a processor in communication with the computer-readable storage medium. The executable instructions, when executed, may cause the processor to: obtain user input from the first client 104 and initiate a trip invitation to the second client 106. The trip invitation includes the first client's identification information and a request to share the second client 106's geographic location. The request may be in the form of text, a link, or any other suitable format. The geographic location sharing request is a request for the second client 106 to provide its geographic location in a suitable manner. In one or more embodiments, a "geolocation sharing request" may refer to a request from one party, such as a first client 104, to another party, such as a second client 106, to share its geographic location with the second client 106. During this process, the first client 104 may not disclose or share its own geographic location with the second client 106. In other embodiments, a "geolocation sharing request" may be a "geolocation sharing request." A "geolocation sharing request" may include substantially simultaneously sharing the first client 104's own geographic location while requesting the second client 106 to share its location. This allows the first client 104 and the second client 106 to see each other's locations after location sharing and further understand real-time location changes. In this embodiment, the travel invitation may be sent to the second client 106 in any suitable form, such as a short message, WeChat message, or instant messaging app message installed on a mobile terminal. The short message may include the inviter's mobile phone number and a query for consent to location sharing. As indicated by the bidirectional arrow 116, the second client 106 may then directly feedback or send the geographic location back to the first client 104.

[0083] In one or more embodiments, the feedback of geographic location can include multiple methods. In addition to marking the geographic location through a network link as mentioned in the above embodiment, other feasible methods can also be included. As mentioned above, the positioning technology of the first client 104 and the second client 106 can include but is not limited to GPS, i.e., the global positioning system, the global satellite navigation system, the wireless fidelity positioning system, the compass navigation system and other positioning technologies and combinations thereof. In one embodiment, the second client 106 can identify its own geographic location (just as its geographic location can be identified through a portable mobile device in the prior art, the specific principles of which will not be repeated here), and send the geographic location in the form of a data short message to the first client 104 in the form of a longitude and latitude or other location representation method. The first client 104 accordingly includes a processor configured to interpret the received data information as a geographic location and mark the geographic location on the map interface of the first client 104.

[0084] In some other embodiments, the second client 106 also uses its included hardware and software devices to send a photo of an identifiable location to the first client 104. For example, in one scenario, the second client 106 can take or select a photo of a nearby landmark building or environment through the Internet, so that the first client 104 can compare and match the photo with the real-life map scene and further identify the location of the second client 106, or identify the location of the landmark building in other ways. In other embodiments, the location of the second client 106 can be further located by identifying signals from Bluetooth, short-range communication devices, etc. The above are only a few possible implementations, and those skilled in the art can envision many variations, as long as the sharing of geographic location can be achieved. Such direct interaction embodiments are beneficial for application scenarios with poor network coverage, especially when there is no 4G or 5G network coverage or the network conditions are poor. As such, the application of this solution does not require the second client 106 to have installed specific software corresponding to the first client 104, nor does it require the second client 106 to be able to open a network link and locate the geographic location on the server map as in the above embodiments. Furthermore, when the first client 104 uses an offline map, the first client 104 does not synchronize the map with the server 102. Therefore, direct information exchange between the first client 104 and the second client 106 facilitates the implementation of the above solution. The subsequent path calculation for the first client 104 can be completed on the mobile phone or vehicle computer.

[0085] Furthermore, those skilled in the art will appreciate that, in one or more embodiments, the trip invitation issued by the first client 104 may further include a request for the second client 106 to share its geographic location and destination. When the second client 106 accepts the trip invitation, in addition to transmitting the second client 106's current geographic location / pickup location / ride location to the first client 104, the second client 106's desired destination may also be transmitted to the first client 104. The second client 106's destination may be transmitted simultaneously with the second client 106's current geographic location / pickup location / ride location, or may be transmitted in separate steps. For example, in one embodiment, the second client 106's current geographic location and destination are displayed as a route on the map interface / navigation interface of the first client 104. The first client 104 may set the second client 106's geographic location as a waypoint and the second client 106's destination as the travel destination. In another embodiment, the first client 104 may also use both the second client 106's geographic location and destination as waypoints for navigation.

[0086] The following will refer to Figure 2 This article introduces the vehicle computer system (VCS) as an example, as well as examples of its interaction with nomadic devices, mobile devices, networks, etc.

[0087] refer to Figure 2 , illustrates an example block topology diagram of a vehicle-based computer system (VCS) 1 for a vehicle 31. This vehicle-based computer system 1 may be, for example, the SYNC system manufactured by Ford Motor Company, or any other infotainment system developed by any other company. It will be appreciated that a vehicle equipped with a vehicle-based computer system such as the SYNC system or any other infotainment system may include a visual front-end interface 4 located within the vehicle. A user may also interact with this interface (if present) via, for example, a touchscreen. In another illustrative embodiment, interaction occurs through button presses, spoken dialogue, and speech synthesis. Voice interaction in one or more embodiments of the present application may be accomplished via the aforementioned vehicle-based computer system VCS or a cloud-based computer system.

[0088] exist Figure 2 In the illustrative embodiment 1 shown in FIG, a processor 3 controls at least a portion of the operation of the onboard computer system. The processor, located in the vehicle, allows for onboard processing of instructions and programs. Furthermore, processor 3 is connected to non-persistent memory 5 and persistent memory 7. In this illustrative embodiment, the non-persistent memory is random access memory (RAM) and the persistent memory is a hard disk drive (HDD) or flash memory.

[0089] The processor is also provided with a number of different inputs that allow the user to interact with the processor. In this illustrative embodiment, a microphone 29, an auxiliary input 25 (for input 33), a USB input 23, a GPS input 24, and a Bluetooth input 15 are provided. An input selector 51 is also provided to allow the user to switch between the various inputs. Input to the microphone and auxiliary connector is converted from analog to digital by a converter 27 before being passed to the processor. Although not shown, various vehicle components and auxiliary components that communicate with the VCS may use a vehicle network (such as, but not limited to, a CAN bus) to transmit data to and receive data from the VCS (or its components).

[0090] A vehicle computing system may include a microprocessor or central processing unit (CPU) that communicates with various types of computer-readable storage devices or media. The computer-readable storage devices or media may include volatile and non-volatile memory such as read-only memory (ROM), random access memory (RAM), and keep-alive memory (KAM). The computer-readable storage devices or media may be implemented using any number of known memory devices, such as programmable read-only memory (PROM), EPROM (electrically programmable read-only memory), EEPROM (electrically erasable programmable read-only memory), flash memory, or any other electronic, magnetic, optical, or combination storage device capable of storing data.

[0091] Outputs to the system may include, but are not limited to, a visual display 4 and a speaker 13 or stereo system output. The speaker is connected to an amplifier 11 and receives its signal from the processor 3 via a digital-to-analog converter 9. Outputs may also be made to a remote Bluetooth device (e.g., PND 54) or a USB device (e.g., vehicle navigation device 60) along bidirectional data streams shown at 19 and 21, respectively.

[0092] In one illustrative embodiment, the system 1 communicates 17 with a user's nomadic device 53 (e.g., a cell phone, smartphone, PDA, etc.) using a Bluetooth transceiver 15. The nomadic device 53 can then be used to communicate 59 with a network 61 outside the vehicle 31, for example, by communicating 55 with a base station 57. In some embodiments, the base station 57 can be a WiFi access point.

[0093] Signal 14 represents an exemplary communication between the nomadic device and the Bluetooth transceiver.

[0094] Pairing of the nomadic device 53 and the Bluetooth transceiver 15 may be instructed via a button 52 or similar input, thereby instructing the CPU that the onboard Bluetooth transceiver will pair with the Bluetooth transceiver in the nomadic device.

[0095] Data can be transferred between the CPU 3 and the network 61 using, for example, a data plan, data over voice, or dual-tone multi-frequency (DTMF) tones associated with the nomadic device 53. Alternatively, it may be desirable to include an onboard modem 63 having an antenna 18 to transfer 16 data between the CPU 3 and the network 61 via the voice band. The nomadic device 53 can then be used to communicate 59 with the network 61 outside of the vehicle 31, for example, by communicating 55 with a base station 57. In some embodiments, the modem 63 can establish communication 20 with the base station for communicating with the network 61. As a non-limiting example, the modem 63 can be a USB cellular modem and the communication 20 can be cellular communication.

[0096] In one illustrative embodiment, the processor may be provided with an operating system including an application programming interface (API) for communicating with modem application software. The modem application software may access a module or firmware embedded in the Bluetooth transceiver to complete wireless communication with a remote Bluetooth transceiver (e.g., found in a nomadic device). Bluetooth is a subset of the IEEE 802 PAN (Personal Area Network) protocol. IEEE 802 LAN (Local Area Network) protocols include WiFi and have considerable cross-functionality with IEEE 802 PAN. Both are suitable for wireless communication within a vehicle. Another communication method that may be used in this field is free-space optical communication (such as IrDA) and non-standardized consumer IR protocols.

[0097] In another embodiment, the nomadic device 53 includes a modem for voice-band or broadband data communications. In the data-over-voice embodiment, a technique known as frequency division multiplexing can be implemented when the nomadic device's owner speaks into the device while data is being transmitted. At other times, when the owner is not using the device, data transmission can use the entire bandwidth (300 Hz to 3.4 kHz in one example).

[0098] If the user has a data plan associated with the nomadic device, the data plan may allow for broadband transmission and the system may use the wider bandwidth (speeding up data transmission). In another embodiment, the nomadic device 53 is replaced by a cellular communication device (not shown) installed in the vehicle 31. In another embodiment, the nomadic device 53 may be a wireless local area network (LAN) device capable of communicating over, for example (but not limited to), an 802.11 network (e.g., WiFi) or a WiMax network.

[0099] While frequency division multiplexing (FDM) was common for analog cellular communications between vehicles and the internet and is still used, it has largely been replaced by a mix of code domain multiple access (CDMA), time domain multiple access (TDMA), and spatial domain multiple access (SDMA) for digital cellular communications. These are all ITU MT-3000 (3G) compatible standards and offer data rates of up to 2 Mbps for stationary or walking users and up to 385 kbps for users in a moving vehicle. 3G standards are now being replaced by Advanced MT (4G), which offers data rates of 10 Mbps for users in a vehicle and 1 gbs for stationary users. The 5G communication standard, currently being phased in, will significantly increase data transmission speeds and network capacity compared to 4G. References to communication methods herein or elsewhere should be understood to include, but are not limited to, communications under the aforementioned standards, such as 3G, 4G, and 5G. If a user has a data plan associated with their mobile device, the data plan may allow for broadband transmission, and the system can utilize a much wider bandwidth (accelerating data transfer). In another embodiment, the nomadic device 53 is replaced by a cellular communication device (not shown) mounted to the vehicle 31. In another embodiment, the ND 53 may be a wireless local area network (LAN) device capable of communicating over, for example, but not limited to, an 802.11g network (i.e., WiFi) or a WiMax network.

[0100] In one embodiment, incoming data may be transmitted via data-over-voice or a data plan through the nomadic device, through the onboard Bluetooth transceiver, and into the vehicle's internal processor 3. For example, in the case of certain temporary data, the data may be stored on a HDD or other storage medium 7 until the data is no longer needed.

[0101] Additional sources that can interface with the vehicle include a personal navigation device 54 having, for example, a USB connection 56 and / or antenna 58, a vehicle navigation device 60 having a USB 62 or other connection, an onboard GPS device 24, or a remote navigation system (not shown) connected to a network 61. USB is one of a class of serial networking protocols. IEEE 1394 (FireWire™ (Apple), I.LINK™ (Sony), and Lynx™ (Texas Instruments)), EIA (Electronic Industries Association) serial protocols, IEEE 1284 (Parallel Port), SDIF (Sony / Philips Digital Interconnect Format), and USB-IF (USB Implementers Forum) form the backbone of device-to-device serial standards. Most protocols can be implemented for either electrical or optical communication.

[0102] Additionally, the CPU may communicate with various other auxiliary devices 65. These devices may be connected via wireless connections 67 or wired connections 69. Auxiliary devices 65 may include, but are not limited to, personal media players, wireless healthcare devices, portable computers, mobile devices, key fobs, and the like.

[0103] Additionally or alternatively, the CPU may be connected to a vehicle-based wireless router 73 using, for example, a WiFi (IEEE 803.11) transceiver 71. This may allow the CPU to connect to a remote network while in range of the local router 73.

[0104] In one or more embodiments, the roaming device 53, personal navigation device 54, in-vehicle navigation device 60, and in-vehicle computer system may be installed with or invoke application software in one or more embodiments of the present application, thereby providing the travel invitation functionality in one or more embodiments of the present application. The in-vehicle computer system or other form of personal mobile terminal may be connected to the network 61 and communicate with the server to synchronize maps in real time. Of course, in one or more embodiments, the in-vehicle computer system or other form of personal mobile terminal may be equipped with offline maps and may utilize the offline maps and its own computing capabilities to achieve positioning. In one or more embodiments, one or more of the in-vehicle device terminals, such as the in-vehicle navigation device 60 and the in-vehicle computer system, may be simply referred to as a vehicle computer. In one or more embodiments, the personal navigation device may also be equipped with the first application software and connected to the vehicle computer via a wired or wireless connection (e.g., Bluetooth).

[0105] In addition to having example programs executed by a vehicle computing system located within the vehicle, in certain embodiments, the example programs may be executed by a computing system in communication with the vehicle computing system. Such a system may include, but is not limited to, a wireless device (such as, but not limited to, a mobile phone) or a remote computing system connected via a wireless device, such as, but not limited to, a server, cloud, cloud server, cloud platform, etc., as mentioned above. In certain embodiments, specific components may execute specific portions of the program depending on the specific implementation of the system. By way of example and not limitation, if the program includes steps for sending or receiving information with a paired wireless device, the wireless device may not execute the program because the wireless device cannot send or receive information with itself. In all solutions, it is envisioned that at least the VCS located within the vehicle itself can execute the example programs.

[0106] In one or more examples, the vehicle VCS and / or the user's nomadic device may be referred to as a "client". The term "client" is primarily used in one or more embodiments of the present application to describe a communication tool suitable for initiating ride invitations, receiving ride invitations, initiating pick-up invitations, and receiving pick-up invitations. The terms "first client" and "second client" are primarily used to describe the interaction process between the two parties in the embodiments. In other embodiments, the roles of the "first client" and "second client" may be interchangeable. The terms "trip invitation" and "ride invitation" may be used interchangeably or alternatively herein to indicate an invitation to a ride sent or initiated by one party to the other party. In some embodiments, a trip invitation may also represent an invitation to a ride, or a request to a ride.

[0107] Figure 3 Shows the available Figure 1 The flow chart of the exemplary method 200 for interaction between clients in the itinerary invitation system is shown. Figure 3 As mentioned above, the first client 104 can be a variety of mobile terminals. For example, it can be a portable mobile device 104A, or a computer system embedded in a vehicle, or a subsequently installed in-vehicle mobile terminal 104B (such as the aforementioned VCS, in-vehicle navigation system, etc.). The mobile terminal 104A can access the trip invitation function through an installed first application (such as, but not limited to, "FordPass"). When the first application is installed on a user's phone, the user can access the first application and find the function entry 202. In one embodiment, upon opening the first application, a search page with a map background is displayed, and a call-to-action button is provided at an appropriate location on the page. The user can access the trip invitation function in the search box or through the call-to-action button. The "button" mentioned above and elsewhere does not specifically refer to a physical button, and those skilled in the art will understand its nature. For example, it can be a virtual, actionable option displayed on a monitor / display. It is understood that the virtual option can be implemented in a suitable manner. For example, the various forms of mobile terminals mentioned above may include software or applications, or instructions stored in storage media. When these instructions are executed, one or more processors may display the above predetermined virtual options on the corresponding interface of the relevant mobile terminal. Then the user may choose whether to synchronize the mobile phone address book with the first application in step 204. If the user chooses to authorize the synchronization of the address book in step 204, then in this step 206, the trip invitation can be initiated in the current application interface by entering the passenger's mobile phone number, entering the passenger's name, etc. User input can be performed in a variety of ways, such as but not limited to voice input, manual text input, etc. If the user chooses to refuse to authorize the synchronization of the address book, the user can still make contact by entering the mobile phone number.

[0108] In one embodiment, if a user initiates a trip invitation or a ride invitation via the vehicle-mounted mobile terminal 104B, the function module can be accessed in a variety of ways. In one embodiment, the vehicle-mounted mobile terminal 104B can be similarly installed with the above-mentioned first application, such as but not limited to Fordpass, and access the invitation function in a similar manner as described above. In other embodiments, for example, Figure 3 As shown, in one scenario, a trip invitation function can also be accessed via a call-to-action button located on the map entry 208 of the navigation interface, as further described below with reference to the accompanying figures. In this scenario, the user may also be asked whether to authorize synchronization of the address book with the active application. If authorization for address book synchronization is selected in step 210, a trip invitation can be initiated by entering the passenger's phone number, name, or other methods within the current map interface, similar to the embodiments described above. If the user chooses to decline authorization for address book synchronization, the user can still contact the passenger by entering their phone number. As described above, phone number input can still be performed via voice or manual input, providing additional convenience for the user. For example, the user can initiate a trip invitation via voice within the interface, triggering the sending of a message using predefined phrases, etc., to access the corresponding trip invitation function. Accessing the trip invitation function within the map interface provides convenience for vehicle drivers, as passengers in the vehicle can initiate a contact and locate the desired pickup location directly within the map interface without exiting the current map interface.

[0109] In one embodiment, the user can connect a portable mobile device such as 104A or other mobile devices to the vehicle computer 104B through any suitable means such as wired or wireless, so as to map some applications on the user's portable mobile device to the display module of the vehicle computer 104B. When entering the trip invitation function, the user can also enter the function in the address book entrance 212. In one embodiment, in the following attached Figure 5 The system displays an invite option button or option associated with a first client's address book contact (e.g., but not limited to, a contact details interface, a car Bluetooth address book interface, etc.). This option can be set adjacent to the contact, with each address book contact corresponding to an invite option, making it easy for the user to operate, just like making a phone call.

[0110] The sending of an invitation can be triggered by selecting a contact in the address book and clicking the invite option. Those skilled in the art will understand that clicking the invite option is just an example, and the invite option can also be activated in other suitable ways, such as by voice or gesture. In another example, the user can also enter this function at the call interface entrance 214, and the mobile device 104A or the car machine 104B may include an invite option associated with the contacts of the first client under the call interface. The so-called call interface, as an example, may refer to the interface where a call is in progress. Usually, this interface has options such as hang up, hold, etc., and adding an invite option button here further facilitates the user to send an invitation. Of course, those skilled in the art will understand that the call interface may include various forms, such as but not limited to a car Bluetooth phone, a mobile phone call interface, a current call interface, a history call interface, etc.

[0111] In one scenario, a passenger calls the driver / vehicle personnel and asks them to pick them up at location X. In typical scenarios without the present embodiments, the driver often needs to expend considerable effort to communicate again after the call to determine the precise location. Changes in traffic conditions or the passenger's location can make the pick-up process even more laborious. However, with the present embodiments, the driver can conveniently send a trip invitation by clicking (or triggering by other suitable methods as described above) an invite option button on the call page with a specific contact. This further eliminates the need for communication by determining the location. Of course, when accessing a trip invitation through the address book or call interface, there's no need to inquire about authorization to synchronize the address book, as the address book is already in the address book. Those skilled in the art will appreciate that the aforementioned vehicle-mounted access can also be implemented on the user's portable mobile device 104A. In different embodiments, one or more of the aforementioned methods for accessing the trip function or ride function can be used separately or in combination, and more or fewer function access points can be provided as needed.

[0112] Continue to refer Figure 3In one embodiment, when the first client 104 (104A or 104B) is a vehicle occupant, and when the vehicle occupant (including the vehicle owner / driver / user, etc.) enters a relevant function portal, such as portals 202, 208, 212, or 214, through the first client 104 (104A or 104B), a trip invitation or ride invitation may be further initiated at step 216. The trip invitation information is then sent to the second client 106, typically a mobile phone. Of course, those skilled in the art will appreciate that there is no specific limitation on the second client 106, and it may be a mobile terminal in the form of a mobile phone, wearable device, or the like. In one embodiment, the trip invitation is sent via a short message. The short message includes an HTML link to an electronic map. Of course, those skilled in the art can envision any suitable variation, as long as the link to the map is included or provided. In other embodiments, the trip invitation may be sent via WeChat, Weibo, QQ, or other common instant messaging apps. In some embodiments, the first client 104 also receives a notification indicating whether the trip invitation was successfully sent.

[0113] At step 218, the user of the second client 106 can click the HTML / H5 link or otherwise access a corresponding predetermined URL to enter the web view. The HTML link can point to a server-side online map, which can reflect the geographic location of the second client 106. It is envisioned that in some embodiments, the vehicle computer can be equipped with a map (for example, the vehicle computer can operate as a small server), and the link can point to the vehicle computer map, so that the second client 106 can directly feedback its geographic location to the vehicle computer map.

[0114] At step 220, after the user of the second client 106 clicks the link, a prompt interface appears, allowing the user to choose whether to authorize synchronization of their current location information to a map (such as, but not limited to, the server-side map described above). At step 222, the user of the second client 106 can reconfirm their location and confirm its transmission to the first client 104. At step 224, upon receiving the location confirmation, the first client 104 can update its current route plan, selecting the location as either the destination or a transit point. Of course, if the user of the second client 106 does not require the ride / trip service, they can also choose to decline the trip invitation. In one or more embodiments, if the second client 106 declines the trip invitation or does not accept the invitation within a predetermined time, the first client 104 may receive a corresponding reminder. In the case of a trip invitation containing a link, the link may also be pre-set with a predetermined activation time period. This means that if the second client 106 does not accept the invitation for more than, for example, three minutes, the link will expire. Those skilled in the art will be able to select appropriate reminder methods and link expiration times based on actual needs.

[0115] At step 226, in one embodiment, the user of the second client 106 may also provide input to request or set a new desired boarding location for the second client. For example, a passenger of the second client 106 may wish to find a more convenient boarding point based on their circumstances, and may therefore update or confirm a new boarding location by, for example, dragging a marker on the map. In this embodiment, a query may be sent to the second client 106 regarding whether it wishes / desires / expects to relocate its boarding location. This query can prevent erroneous operation or triggering of the second client 106. If the second client 106 confirms its desire / desire / expects to relocate, the updated passenger location of the second client 106 is relocated, and the new boarding location of the second passenger client 106 is further transmitted to the first client 104. Of course, it is understood that the first client 104 may or may not accept the new boarding location proposed / sent by the second client 106. The method may further include presenting the updated new ride location to the first client 104 and asking the first client 104 whether to accept the new ride location. When the first client 104 confirms, the first client 104 determines the new ride location as the target location or a new waypoint.

[0116] At step 228, in one embodiment, the first client 104 can also issue an updated pick-up location suggestion, for example, based on traffic conditions, ease of parking, and other real-time conditions and situations, the first client 104 can request the second client 106 to move to a more suitable pick-up location. The method can further include receiving an input from the first client 104 to relocate the new pick-up location of the first client 104. In one embodiment, the method includes receiving an input from the first client 104 to issue a query option to the first client 104 whether to relocate the new pick-up location of the first client 104, the query option can avoid the situation of user's false triggering or false operation. When the first client 104 confirms the relocation, the new pick-up location of the first client 104 is relocated. It can be understood that the method can further include a step of displaying the new pick-up location to the second client 106 and querying the second client 106 whether to accept the new pick-up location, when the second client 106 confirms, the new pick-up location is determined as the target location or the way point.

[0117] At step 230, as described above, the first client 104 can further update the planning of the path according to the received new pick-up location, it can be understood that in this embodiment, the second client 106 can observe the position of the first client 104, the state of the journey, the estimated arrival time, and the like in real time.

[0118] At step 232, the first client 104 can reach the second client 106 (passenger), at this time, the first client 104 can follow the navigation to perform the subsequent journey, and the method of the journey invitation has been completed so far.

[0119] The above is a brief description of the steps of the exemplary method in one embodiment, it can be understood that in other embodiments, one or more steps can be omitted, changed, added to form new embodiments without departing from the spirit of the present application. The operation interface of the first client 104 and / or the second client 106 in one or more exemplary steps described above will be shown below in combination with the drawings.

[0120] Figure 4 An interface example of the journey / pick-up invitation sending of the first client 104A in one embodiment is shown. The interface can correspond to the interface shown in FIG. 2A, for example, and the interface can be displayed on the first client 104A when the first client 104A sends the journey / pick-up invitation to the second client 106A. Figure 3Steps 202, 204, 206, and 216 of the exemplary method 200 are described. As described above, the first client 104A can be the vehicle owner's portable mobile device, and the first client 104A can be installed with the first application in the above-described embodiment, such as Fordpass. By activating the Fordpass function, a map interface can be accessed through one or more steps. In the example shown, opening the first application brings up a search page with a map background, and a call-to-action button 302 is located in the lower left corner or other suitable location. Clicking or activating button 302 by other suitable means brings up a ride invitation sending page 304. As shown in page 304, the user can enter a mobile phone number to contact a specific user. Although interface 304 indicates contacting via "Send SMS," those skilled in the art can contact the second client 106 via any suitable method, such as WeChat, QQ, Weibo, or other commonly used applications. SMS is, of course, a more popular and widely available communication method. As prompted by interface 306, when the user starts to enter the input box to edit, he or she may receive a reminder whether to synchronize the address book, which corresponds to step 204 in method 200, where the user can choose to agree or disagree to the authorization of the address book. If the user selects "I agree", the mobile phone address book can be synchronized with the current application, so that as shown in 308, the name and contact number information of the contact person will be displayed in the input box for subsequent trip invitations, and the ride invitation can also be edited and sent by voice in subsequent interactions. If the user does not agree to synchronize the address book, subsequent operations can still be performed, and the user needs to enter the mobile phone number of the passenger manually or by voice. In some embodiments, if the user has agreed to synchronize the address book in advance, step 306 can be skipped and the address book can be called directly.

[0121] Figure 5 An example of an interface for sending a ride invitation by the first client 104B in one embodiment is shown. Figure 3 Steps 208, 212, 214, and 216 of the exemplary method described above. The first client 104B may be an in-vehicle computer system, which may be referred to as a vehicle computer. It may also be installed with the first application in the above embodiment, such as Fordpass. By opening the Fordpass function, the map interface or the trip invitation interface may be accessed in a similar manner. Please refer to the above for Figure 4 In another embodiment, the first client 104B may also have a built-in offline map or a map application synchronized with the server, and may enter the invitation sending interface through a function call button embedded in the map interface.

[0122] exist Figure 5In the example shown, by opening the car machine 104B, the map application interface can be entered, and the behavior calling button 402 is arranged at the lower left corner or other suitable position. By clicking the button 402, the sending page 404 of the ride invitation can be entered. As shown in the page 404, the user can input the mobile phone number to contact a specific user. Although the interface 304 shows that the contact is made by the "send message" mode, those skilled in the art can contact the second client 106 by any suitable mode, for example, by the instant messaging software commonly used by users such as WeChat, QQ, Weibo, etc. Of course, the SMS mode is a more popular and widely network-covered communication mode. As prompted by the interface 406, when the user starts to edit the input box, a prompt of whether to synchronize the address book can be received, which corresponds to step 210 in the method 200. The user can select whether to agree or disagree with the authorization of the address book. If the user selects "I agree", the phone address book can be synchronized with the current application, so that the name and contact number information of the contact person is displayed in the input box of the subsequent ride invitation sending as shown in 408. In subsequent interactions, the ride invitation can also be edited and sent by voice. If the user disagrees to synchronize the address book, the subsequent operation can still be performed, and the user needs to manually or by voice input the mobile phone number of the ride person.

[0123] Figure 6A And 6B The interfaces corresponding to steps 212 and 214 of the method 200 are shown. In one or more embodiments, the ride invitation function entry interface can be entered through the address book or when the phone dialing interface is entered. As shown in Figure 6A As shown, the user can enter the relevant ride invitation sending function through the behavior calling button 502 (or the ride invitation option) under the address book interface. Figure 6B As shown, the behavior calling button 602 in the page of the call with a specific user can also enter the relevant invitation sending function. It can be understood that the behavior calling buttons 302, 402, 502, and 602 can be arranged at any suitable position of the page for the convenience of the user, and can also be presented in any suitable form. For example, the ride invitation option / function entry can be added to the recent call, dialing page, address book page, history call, etc. The embodiments shown provide the sending of the invitation by the short message, and as described in other positions of the present application, the sending of the message can also be completed by other suitable social software, etc.

[0124] Figure 7A failure notification is displayed to the initiator, or user, of first client 104 when the first client 104 fails to send a message. In some cases, a contact may not be successfully contacted due to various reasons, such as network issues or an incorrect number. In these cases, the driver will be notified of the failure. This notification can be in text or voice format. The notification can include a dismiss button or a graphical acknowledgement button to allow the user to acknowledge the failure and decide to initiate a new round of invitations.

[0125] Figure 8 An example of the page displayed after the first client 104 successfully sends a trip invitation, for example, via a short message. As shown, after the first client 104 successfully sends the trip invitation, clicking the call to action button 702 for the trip invitation again will display a reminder, such as at position 704, indicating that the text message has been sent and that the user is waiting for the passenger to provide feedback on the pick-up location. Of course, those skilled in the art will appreciate that other suitable reminders are possible, such as a successful message send. The first client 104 may also provide other options, such as canceling the trip or contacting the passenger. A progress bar may also be displayed, indicating, for example, the current stage of initiating the trip or the stage of waiting for feedback. Other suitable reminders for the first client 104 may also be provided, such as real-time notifications of non-response from the second client 106, link failure after three minutes, or trip initiation failure. These reminders may also provide the user of the first client 104 with convenient options such as making a phone call or resending the invitation.

[0126] Figure 9 An embodiment of the information received by the second client 106 is shown. Figure 9In the illustrated embodiment, after the first client 104 successfully sends the message, the second client 106 can receive an itinerary invitation including the first client's contact's number or name, a simple invitation content, and an HTML link pointing to a URL, which can point to an electronic map. In one embodiment, the link points to a map stored in the server, and in another embodiment, the link points to a map stored in the car machine. Of course, as mentioned in the above embodiments, in other embodiments, other ways of message alerting can be used, such as sending the invitation through other instant messaging software instead of through short messages. In other embodiments, the first client 104 can send a request to the second client 106 to request the second client to share its location, and the request can be in text or voice or other suitable forms instead of in the form of a link. The second client 106 can send photos, data, network connection, etc. to the first client 104 by taking pictures, recording videos, sending location coordinates, etc., and the location of the second client 106 can be calculated by the first client 104 or the server 102. The example of sending information directly to the first client 104 is beneficial when the first client 104 is using an offline map or when the network condition is not good.

[0127] Figure 10A An interface entered by the second client 106 when the second client 106 receives the message shown above and agrees to share the location or authorizes the sharing of the location is shown in one embodiment. Figure 9 An interface entered by the second client 106 when the second client 106 receives the message shown above and agrees to share the location or authorizes the sharing of the location is shown in one embodiment. Figure 9After clicking the link displayed in the second client 106 , a query is displayed asking whether to authorize location sharing. Upon confirmation by the second client 106, the user is directed to the server-side map, where their location is synchronously displayed. The server-side map can represent an electronic map stored on any suitable server. In one embodiment, the actual location of the second client 106 can be relocated by touching the screen of the second client 106 or by voice input. Alternatively, the user can drag an icon or move the underlying map to locate the second client 106. After another query confirming that the second client 106 wishes to send its location to the first client 104, the location of the second client 106 displayed on the server-side map is sent to the first client 104. In embodiments where the first client 104 invites the second client 106 to share its location unilaterally, the location of the first client 104 may not be visible to the second client 106. In this embodiment, however, the invitation from the first client 104 is an invitation to share location. Therefore, once the second client 106 agrees to location sharing, the second client 106 can view the vehicle location of the inviter / trip invitation sender from the moment they enter the map interface. After the second client 106 determines the location, it may send the location to the first client 104 .

[0128] Figure 10B Another embodiment is shown, wherein when the second client 106 receives Figure 9 Schematic diagram of the interaction between the second client 106 and the first client 104B when the second client 106 agrees to share the location or authorizes sharing the location by clicking the message displayed. Figure 9 After clicking the link shown in the figure, you can enter the inquiry of whether to authorize location sharing, and after the second client 106 confirms it, you will enter the electronic map interface. As mentioned above and elsewhere in this article, the electronic map can be a map stored in the server, or a map stored in other suitable forms. Figure 10AThe difference between the embodiment and the embodiment shown in FIG. 8 is that in this embodiment, the photographing option 802 is also provided in the second client 106, which can further help the second client 106 to take a street view photo, thereby assisting the first client 104B to locate the position of the second client 106. When the user selects to use the photographing option 802, the street view photo 804 can be sent to the first client 104B, which will be displayed as a small floating window in the current interface of the first client 104B, and the current interface of the second client 106 can also display the received street view photo 804'. Preferably, the street view photo 804' can be displayed in the form of a floating window at a position of the interface that does not hinder navigation. In one embodiment, the street view photo of the position of the second client 106 can be first sent to the server via the photographing option 802, and then sent to the first client 104B via the server.

[0129] Further referring to Figure 10B In the embodiment shown in the figure, in order to further facilitate the communication between the users, a telephone dialing shortcut 806 can be provided in the current page of the first client 104B, so as to facilitate the user of the first client 104B to directly contact the user of the second client 106. It can be understood that the photographing option 802 and the telephone dialing shortcut 806 described above can be located at any suitable position of the interface. Although the above is exemplified by taking the first client 104B as an example, it can be envisaged that the above-mentioned scheme can be applied to any form of first client 104 or second client 106. In some embodiments, in the vehicle user end initiated ride invitation, the activation of the photographing option can also call the vehicle-mounted camera to obtain the desired pickup point photo. The pickup point photo can be sent to the passenger end in a suitable manner, so as to facilitate the passenger to find the position of the vehicle more quickly. It can also be envisaged that the pickup point photo can be independently applied, or combined with the map to assist the passenger to find the position of the vehicle.

[0130] Figure 11 An example of a failed position sending of the second client 106 is shown, when the position is failed to be successfully sent to the first client 104 due to network or other reasons, a position sending failure reminder will be received Figure 11 In other embodiments, at this time, a step of sharing the position data in the form of submitted data or code can be added, for example, a question of "whether to send the latitude and longitude data to XXXX by short message" can be asked, if the user agrees, the position information of the second client 106 can be submitted in the form of a short message, and the first client 104 can calculate the position of the second client 106 by itself. In another case, a question of "whether to send the surrounding environment picture / video to XXXX by APP" can be asked, so that the first client 104 can determine the position of the second client 106 by receiving the video or picture and comparing by the real scene. The above Figure 10B The example mentioned the use of the photo option to assist the first client 104 in identifying the location, and in this embodiment, photos, videos, longitude and latitude data, etc. can also be independently provided to the first client 104 alone or in a combination of one or more to facilitate the first client 104 to locate the location of the second client 106. There are also some social software on the market that allow interaction using wireless networks or Bluetooth. One or more embodiments of the present application can also be applied to such software to gain advantages. For example, in the case of poor network, the user can be asked whether to locate via Bluetooth, and / or transmit the geographic location via Bluetooth. Only a few possible embodiments are discussed here, and those skilled in the art should understand that the way of sharing geographic location is not limited to this.

[0131] Figure 12 The schematic interface diagram of the first client 104B and the second client 106 after the second client 106 successfully shares its location in one embodiment is shown. In this embodiment, as shown, the first client 104B receives a notification stating "Passenger location received." If the user of the first client 104B clicks the trip invitation button, a message stating "Trip status: Location received," "Please plan your trip," "Pick up passenger," or similar notifications will be displayed, updating the user of the first client 104B on the progress of the trip invitation. The system / first client 104B can also provide feedback on the current stage of the trip invitation process using a progress bar or other appropriate form. The first client 104B or driver can choose to set the passenger's location as a destination or a waypoint to complete navigation settings. The first client 104B can also cancel the trip or contact the passenger. Tabs for contacting the passenger and canceling the trip can be provided on the current interface of the first client 104B, and a speed dial option can be configured to allow the user of the first client 104B to quickly contact specific contacts. In one embodiment, while the first client 104B is operating, the system can display a reminder on the second client 106 for the driver to confirm the route, so that the second client 106 can also understand the status and location of the first client 104B in real time. Although the above discussion specifically uses the first client 104B as an example, it is understood that 104A or other suitable client terminals can also implement similar settings.

[0132] Figure 13In one embodiment, the interface of the first client 104 and the second client 106 is shown when the first client 104 selects the location of the second client 106 as a waypoint or destination. When the first client 104 selects the location of the second client 106 as a waypoint or destination, the first client 104 can navigate within the current navigation interface, and navigation information and real-time location changes are reflected to the second client 106, allowing the second client 106 to understand the location of the first client 104 in real time. As described above, in one or more embodiments, the trip invitation issued by the first client 104 may further include a request for the second client 106 to share its geographic location and the second client 106's desired destination. The first client 104 may set the second client 106's geographic location as a waypoint and the second client 106's desired destination as the travel destination. Similarly, the first client 104 may also use both the second client 106's geographic location and destination as waypoints for navigation, depending on the needs of the trip, while setting the first client 104's desired destination as the final destination.

[0133] Figure 14 In one embodiment, an embodiment of the ride location update initiated by the second client 106 is shown. Figure 3 In the described step 226, the second client 106 can update the location / provide a new ride location by dragging the mark on the map, or can initiate the location update by clicking on the location in the page, or adjust the new ride location by moving the underlying map. Here, as shown in the figure, a call to action button / option "Update Location" 902 can be provided, and the second client 106 can be given a confirmation or cancellation option to relocate the ride location of the second client 106. The inquiry step can avoid erroneous operations of the second client 106. When the second client 106 confirms the relocation, the updated passenger position of the second client 106 can be relocated, and the updated ride location can be further sent to the first client 104. At this time, Figure 14 As shown, the first client 104 receives a notification that the passenger has updated their location. When displaying the notification to the first client 104, the client 104 may be asked whether to accept the updated boarding location. If the first client 104 confirms the update, the new boarding location may be determined as the target location or a new waypoint. If the first client 104 does not confirm the new boarding location, the second client will also receive a rejection notification.

[0134] It is understandable that, although not displayed, the first client 104 can also choose to adjust the pick-up location. When the first client 104 user or the driver determines that a more suitable pick-up address needs to be agreed upon, or when parking is not possible at a specific location due to traffic regulations, etc., the first client 104 can update the location through similar operations, and the second client 106 can also see the first client's location suggestions and real-time movements in real time, providing an effective solution for more convenient rides.

[0135] Figure 15 An embodiment is shown in which the trip is completed. After picking up the passenger, the first client 104B can complete the trip according to the navigation. Similarly, the second client 106, which is the passenger terminal, can also click to complete the trip. The user can choose an appropriate method to exit the interface.

[0136] One or more of the above embodiments involve a vehicle owner picking up a specific contact. It is understood that a vehicle owner may also pick up two or more specific contacts during a trip. The vehicle owner may initiate trip invitations to the two or more contacts, set the geographic locations shared by the two or more contacts as waypoints and / or destinations, and complete the trip planning.

[0137] While one or more of the above embodiments discuss the example of inviting a ride, it is understood that a specific user in need of a ride can also initiate a request, such as a request to pick someone up. In other words, the first client can be the passenger, and the second client can be the vehicle owner or driver. As described in the above example, on a user's phone with a first application (e.g., FordPass) installed, an invite option button can be embedded in any contact card. For example, for an SMS contact, both "Ride Invite" and "Invite for Pickup" options / call-to-action buttons can be inserted into the contact card. Clicking the "Invite for Pickup" button sends a message to the specific contact via the network or server. Similarly, if the contact is a WeChat contact, both "Ride Invite" and "Invite for Pickup" options can be inserted. Clicking either option sends a WeChat message to the contact via the cloud. The WeChat message can also include similar inviter identification information and a link. Clicking the link and accepting the invitation sends feedback to the first client via the server. In the example of inviting a pick-up, once the invitation is sent, the vehicle owner or driver can choose to accept or not, and can also complete the location and pick-up process on the map page. Of course, the party who needs to be picked up can also contact the car owner by phone so that the car owner can initiate an invitation and plan a suitable route according to the process described in the above embodiment. When the initiator is a passenger who needs a ride, in one embodiment, after entering the "Invite to Pick Me Up" or similar function as in the above example, the sending of a request message can be triggered. The request message can directly include a message of the geographic location of the initiator, that is, the passenger, so as to complete the communication more efficiently. The geographic location message can include the link as described above, which can be interpreted as a geographic location code, picture, short video, etc., one or more of which can be used alone or in combination to provide more convenient location confirmation.

[0138] While the above embodiments primarily focus on mobile phone address book contacts, it is understood that other forms of contacts, such as instant messaging apps like QQ and WeChat, can also benefit from the present invention. In one embodiment, if both parties are WeChat contacts, trip invitations can be sent within the WeChat interface. The specific implementation can be similar to the above-described implementation. By providing a call-to-action button for trip invitations, a first client, such as the inviter, can send a trip invitation to a second client, such as the invitee. This invitation can include a link to a server-side map, allowing the first client (the inviter) to easily locate the invitee's location via the server-side map. Unlike the real-time location sharing feature provided in WeChat, this type of trip invitation does not require the inviter, or the first client (the car owner), to exit the current app or map interface to view WeChat's real-time location sharing. This eliminates the need for drivers to be distracted and does not interfere with current navigation applications, making the task of picking up passengers very convenient. Other social apps can also benefit from the embodiments provided by this application. In today's world of complex social apps and contacts, the inventors of this application, considering the practical needs of car owners, drivers, and passengers, have provided a pick-up and ride service that can be completed without requiring the use of the same software platform. Even such more personalized needs cannot be met using commercial transaction software platforms such as Uber and Didi, so one or more embodiments provide solutions and meet the needs of pick-up and drop-off services between specific entities, especially in non-commercial transaction situations.

[0139] Although exemplary embodiments have been described above, these embodiments are not intended to describe all possible forms of the present invention. More specifically, the words used in the specification are descriptive rather than restrictive, and it should be understood that various changes may be made without departing from the spirit and scope of the present invention. In addition, the features of the various embodiments implemented may be combined to form further embodiments of the present invention. Those skilled in the art may make various changes, modifications, and variations to these specific embodiments without departing from the spirit and scope defined by the claims of the present application.

[0140] Certain combinations and subcombinations regarded as novel and non-obvious are particularly pointed out in the claims. These claims may refer to "an" element or "a first" element or similar features. Such claims should be understood to include one or more such elements, neither requiring nor excluding two or more such elements. Other combinations and subcombinations of the described features, functions, elements, and / or properties may be claimed by amendment of the present claims or by presentation in this or a related application. Such claims, whether broader, narrower, equivalent, or different than the original claims, should be deemed included within the subject matter of the present application.

Claims

1. A device for making a travel appointment, comprising: A computer-readable storage medium having executable instructions, and a processor in communication with the computer-readable storage medium, the executable instructions being configured to, when executed, cause the processor to perform the following steps: Obtain user input, and send a travel invitation to a specific contact based on the user selecting the specific contact, wherein the travel invitation includes user identification information and a geographic location sharing request for the specific contact. 2 . The apparatus of claim 1 , wherein the geographic location sharing request comprises a link to a server-side map. 3 . The device of claim 1 , wherein when the device is using an offline map, the geographic location sharing request comprises a text request, and the geographic location feedback comprises at least one of an image and latitude and longitude data.

4. The device according to claim 1, wherein the travel invitation is sent in the form of a short message or other instant messaging.

5. The device of claim 1, wherein the step comprises displaying travel invitation options associated with contacts of the device. 6 . The apparatus of claim 1 , wherein the step comprises displaying a travel invitation option associated with the specific contact in a call interface.

7. The apparatus of claim 1, wherein the step comprises displaying a trip invitation option on a map interface of a first application, and synchronizing address book contacts to the first application in response to receiving user authorization and sending the trip invitation for the specific contact on a map interface of the first application.

8. The apparatus of claim 7, wherein the step comprises not synchronizing the address book contacts to the first application in response to receiving a user's rejection of authorization for address book synchronization, and sending the travel invitation for the specific contact by the user inputting a contact number.

9. The apparatus of claim 7, wherein the step further comprises displaying a quick call option on the first application map interface.

10. The device of claim 1, wherein the step comprises receiving a photo sent by the specific contact and displaying the photo on a map interface of the device.

11. The device according to claim 10, wherein the photo comprises a street view photo of the location of the specific contact, and the street view photo is displayed in the form of a floating window on the map interface.

12. The device according to claim 1, wherein the device is a portable mobile terminal for vehicle personnel or a vehicle-mounted computer terminal. 13 . The apparatus of claim 1 , wherein the step comprises receiving a geographic location of the specific contact in response to the specific contact accepting the travel invitation, and planning a route based on the geographic location. The device according to claim 1 , wherein the trip invitation is a ride invitation or a pick-up request for the specific contact.

15. A method for making a travel invitation, comprising: Sending a trip invitation to a second client through the first client, wherein the trip invitation includes a geographic location sharing request for the second client; Feedback from the second client is received through the first client, wherein when the second client accepts the travel invitation, the second client sends its geographic location to the first client. 16 . The method of claim 15 , wherein the geographic location sharing request comprises a link to an electronic map, and the method comprises sending the geographic location of the second client to the first client in the form of a mark on the map. 17 . The method of claim 15 , wherein the geographic location sharing request comprises a text request, and the geographic location feedback comprises at least one of a picture and latitude and longitude data.

18. The method of claim 15, wherein the geographic location sharing request includes a link to a server electronic map, and the method includes synchronizing the geographic location to the server in the form of a mark on the map, and further sending the geographic location to the first client.

19. A device including a navigation application, comprising: A computer-readable storage medium having executable instructions, and a processor in communication with the computer-readable storage medium, wherein the executable instructions are configured to cause the processor to perform the following steps when executed: The user input in the navigation interface is obtained, and a travel invitation is sent to the specific contact according to the user selecting the specific contact, wherein the travel invitation includes user identification information and a geographic location sharing request for the specific contact. 20 . The device of claim 19 , wherein the geographic location sharing request comprises a link to a server-side map, and the travel invitation is sent via a short message or other instant messaging method.

21. The device of claim 19, wherein the step comprises displaying a trip invitation option on the navigation interface, and synchronizing address book contacts to the navigation application in response to receiving user authorization and sending the trip invitation for the specific contact on the navigation interface.

22. The device of claim 19, wherein the step comprises not synchronizing the address book contacts to the navigation application in response to receiving a user's rejection of authorization for address book synchronization, and sending the trip invitation for the specific contact by the user inputting a contact number.

23. The device of claim 19, wherein the step comprises displaying a quick call option on the navigation interface of the navigation application.

24. The device of claim 19, wherein the step comprises receiving a photo sent by the specific contact and displaying the photo on the navigation interface.

Images