METHOD AND DEVICE FOR THE TIME PLANNING OF AUTONOMOUS VEHICLES

Abstract

Methods and apparatus for scheduling autonomous vehicles are disclosed herein. An example method includes receiving at a first processor a first request for a vehicle to travel to a location. The first request is to be transmitted from a second processor to the first processor. The example method includes calculating a time of arrival of the vehicle based on the first request. The example includes comparing the first requirement to a second requirement for the vehicle based on the time of arrival. The example method includes scheduling the first request based on the comparison and directing the vehicle to the location based on the scheduling.

Description

AREA OF REVELATION

[0001] This disclosure generally concerns autonomous vehicles and, in particular, the scheduling of autonomous vehicles. GENERAL STATE OF THE ART

[0002] A user of an autonomous vehicle typically requires the vehicle to arrive at a location to pick them up and transport them to one or more destinations. The use of the autonomous vehicle is often linked to its availability relative to the scheduling requirements placed on it by other users. SUMMARY

[0003] An exemplary method disclosed herein involves receiving an initial request for a vehicle to travel to a location at a first processor. The initial request is then transmitted from a second processor to the first processor. The exemplary method includes calculating the vehicle's arrival time based on the initial request. It also includes comparing the initial request with a second request for the vehicle based on the arrival time, scheduling the initial request based on the comparison, and directing the vehicle to the location based on the scheduled time.

[0004] Another exemplary method disclosed herein involves receiving initial calendar event data via a first processor. The initial calendar event data is to be transferred from a second processor to the first processor. The exemplary method includes determining whether the initial calendar event data contains a requirement for a vehicle. If the initial calendar event data does not contain the requirement, the exemplary method includes analyzing the initial calendar event data and the second calendar event data and generating a predicted requirement for the vehicle based on the analysis. The predicted requirement is to be associated with the initial calendar event data. The exemplary method includes scheduling the predicted requirement.

[0005] An exemplary system disclosed herein includes a request receiver to receive a first request for a vehicle to travel to a first location from a first processor and a second request for the vehicle to travel to a second location from a second processor. The exemplary system includes an analyzer to determine a first arrival time of the vehicle at the first location based on the first request and a second arrival time of the vehicle at the second location based on the second request. The analyzer is to compare the first and second arrival times and identify one or more rules associated with the first or second request. Based on the comparison and identification of the one or more rules, the analyzer is to schedule at least one of the first or second requests.In the example system, at least one of the request receivers or analyzers should be implemented via a third processor. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] Fig. Figure 1 illustrates an exemplary system comprising an exemplary vehicle and exemplary mobile devices for interacting with a control system of the exemplary vehicle according to the teachings disclosed herein.

[0007] Fig. Figure 2 illustrates a first exemplary screen of an exemplary graphical user interface, which corresponds to the exemplary mobile devices from Fig. 1 is assigned.

[0008] Fig. Figure 3 illustrates a second exemplary screen of an exemplary graphical user interface, which corresponds to the exemplary mobile devices from Fig. 1 is assigned.

[0009] Fig. Figure 4 illustrates a third exemplary screen of an exemplary graphical user interface, which corresponds to the exemplary mobile devices from Fig. 1 is assigned.

[0010] Fig. Figure 5 illustrates a fourth exemplary screen of an exemplary graphical user interface, which corresponds to the exemplary mobile devices from Fig. 1 is assigned.

[0011] Fig. Figure 6 is a block diagram of an exemplary control system for use with the exemplary vehicle from Fig. 1.

[0012] Fig. Figure 7 is a flowchart of a first procedure that can be performed to build the exemplary system of Fig. 1 to implement.

[0013] Fig. Figure 8 is a flowchart of a second procedure that can be performed to build the exemplary system of Fig. 1 to implement.

[0014] Fig. Figure 9 is a diagram of an exemplary processor platform that can be used to demonstrate the exemplary procedures from Fig. 7 and Fig. 8 and / or, more generally, the exemplary system consisting of Fig. 1 to implement.

[0015] The figures are not shown to scale. Furthermore, whenever possible, the same reference symbols are used across the drawing(s) and the accompanying written description to denote identical or similar parts. DETAILED DESCRIPTION

[0016] As the use of autonomous vehicles becomes more widespread, they can serve as a primary vehicle for, for example, a family or a group of individuals, such as employees in a company. An individual wishing to use an autonomous vehicle (hereinafter referred to generally as "the vehicle") as a form of transportation may need to make multiple trips throughout the day. Whether or not the individual is able to use the autonomous vehicle for one or more trips depends on the vehicle's availability. Multiple users wishing to use the vehicle for one or more trips on the same day place scheduling demands on the vehicle.

[0017] To request the vehicle, a user can access an application associated with the autonomous vehicle, which allows for scheduling the vehicle via a user device (e.g., a smartphone, a PC). However, requesting the vehicle for every trip, including regularly made trips, using a dedicated user application may not be efficient. Furthermore, users within the same family or group of colleagues may use one or more shared calendar applications (e.g., Google Calendar) to coordinate their schedules. ® Calendar, Yahoo! ® Calendar, Outlook ® ) Sharing calendars. Reconciling the vehicle's schedule using a dedicated user application with events scheduled via a calendar application can be difficult, for example, due to different users accessing the calendar application.

[0018] Exemplary systems and methods disclosed herein involve scheduling an autonomous vehicle using calendar applications, such that when a user enters an event into the calendar application, the user can request the vehicle using the calendar application. When the user creates a new event via the calendar application, the user is automatically given the option to request the vehicle within the same calendar application. The examples disclosed herein also allow a user to view the vehicle's schedule to determine when the vehicle is available for one or more trips. The disclosed examples also provide for user input, such as preferences regarding the vehicle's pickup location and arrival time, without requiring the user to access a separate application.

[0019] When a user enters a new calendar event, the disclosed examples automatically evaluate the new event against previously scheduled calendar events and identify scheduling conflicts relative to vehicle availability. The disclosed examples automatically analyze the new calendar event against previously entered calendar events to identify vehicle locations, calculate travel times between destinations, and determine whether the vehicle is available for the newly scheduled event. The disclosed examples provide for resolving scheduling conflicts based on user input and / or priority rules.The disclosed examples also optimize vehicle use by providing for carpooling or combining multiple trips for different users through shared vehicle use based on, for example, overlapping routes.

[0020] The examples disclosed herein also predict vehicle usage based on an analysis of past vehicle usage data, including, for example, patterns relating to calendar events and a user's vehicle scheduling requirements. With regard to the predictive analysis, the disclosed examples automatically request the vehicle in connection with a calendar event associated with a known location and / or route. The user can then confirm the predicted vehicle request.

[0021] An exemplary system 100 for scheduling an autonomous vehicle102 is in Fig. 1 illustrates. The example vehicle 102 includes a first processor 104 The first processor 104 It controls and / or provides infotainment services, such as music and navigation to a destination using Global Positioning Satellite (GPS) information. In the example system... 100 out of Fig. 1 stands for the first processor 104 of the vehicle 102 in wireless communication with a first mobile device 106 , a second mobile device 108 and a third mobile device 110 , as indicated by a respective first, second and third arrow 112 , 114 , 116 in Fig. 1 is shown. Although three mobile devices 106 , 108 , 110 in Fig. As illustrated in 1, the first processor 104 of the vehicle 102in communication with additional or fewer mobile devices. The first, second, and third mobile devices 106 , 108 , 110 For example, users of the vehicle 102 belong. The first, second, and third mobile device 106 , 108 , 110 of the exemplary system 100 These can be smartphones, tablets, or other devices with a wireless communication capability. Each of the first, second, and third mobile devices 106 , 108 , 110 includes a second processor 118 .

[0022] The respective users of the mobile devices 106 , 108 , 110 can the vehicle 102 as a form of transportation to reach a destination. For example, a first user of the first mobile device might 106 want the vehicle102 picks up the first user from a first location and takes the user to a second location at a first time (e.g., 9 a.m.). A second user of the second mobile device 108 may want the vehicle 102 picks up the second user from a third location and drives the second user to a fourth location at a second time (e.g., 9:30 a.m.). A third user of the third mobile device may want the vehicle to 102 picks up the third user from a fifth location and drives the third user to a sixth location at a third time (e.g. 3 p.m.).

[0023] In the exemplary system 100 sees the wireless communication between the first, second and third mobile devices. 106 , 108 , 110 and the first processor 104 of the vehicle 102 the scheduling of the requirements for the vehicle 102before. The second processor 118 Each of the first, second, and third mobile devices includes a user application. 120 , which are used by the users of each of the first, second and third mobile devices 106 , 108 , 110 It may have been installed. The respective users of the first, second, and third mobile devices 106 , 108 , 110 interact with the user application 120 via a respective graphical user interface (GUI) 122 . The one on each of the first, second and third mobile devices 106 , 108 , 110 installed user application 120 It allows the first, second, and third users to access information regarding vehicle requirements. 102 from the first processor 104 of the vehicle 102 to receive and send information to it.

[0024] To illustrate, the user application 120 with regard to the first mobile device 106 discussed, whereby it is understood that the user application 120 , which is on the second mobile device 108 and the third mobile device 110 The installed version is essentially the same. The user application 120 includes a calendar 124 In some examples, the calendar 124 another, on the first mobile device 106 assigned to installed user applications, such as a third-party calendar application (e.g., Google). ® Calendar, Yahoo! ® Calendar, Outlook ® The calendar 124 enables the first user of the first mobile device 106 via the GUI 122 the first mobile device 106to enter a calendar event, such as an upcoming appointment. The first user can enter the name of the event (e.g., doctor's appointment), the start and end times, and a location. When the first user enters the calendar event information, they can also select the vehicle. 102 for the event via the calendar 124 the user application 120 Request. This means the first user doesn't need to use separate applications to create a calendar event and request the vehicle. 102 access.

[0025] The user application 120 includes a location selection device 126 After receiving user input, the first user will enter the vehicle. 102 for the event, requests the location selection facility 126 the first user, a pickup location or a position at the event location where the vehicle102 To select the first user to be picked up. After entering the event location into the calendar. 124 the user application 120 The location selection device shows 126 For example, a map of the event location via the GUI. 122 the first mobile device 106 the first user can use the location selection device 126 select a position at the location where the first user was passed by the vehicle 102 to be picked up. The first user can, for example, drag a pin on the folder or click on it to select the pickup location, such as the front door of a building or a nearby street intersection.

[0026] The user application 120 includes a rule creator 128 The rule creator 128allows the first user to enter one or more rules regarding the prioritization of calendar events, which are then passed on to the second user via the second mobile device. 108 and / or the third user via the third mobile device 110 The rules were entered. The first user enters the rules via the GUI. 122 For example, the first user can enter a rule stipulating that, in case of scheduling conflicts, calendar events entered by the first user should take priority over calendar events created by the second and / or third user. Thus, the rule creator enables 128 the creation of default rules regarding users who access calendar events via the user application 120 on the first, second and third mobile device 106 , 108 , 110create. In some examples, one is created via the rule creator. 128 The created rule also applies to one or more vehicle settings. 102 related. For example, the first user can create a rule that if the vehicle 102 determined that the outside temperature is below a predetermined temperature limit, the vehicle 102 the heating in the vehicle 102 should switch on automatically when the vehicle 102 The first user is picked up. In other examples, the first user creates one or more rules when they create a new calendar event via the calendar. 124 created, as will be revealed below.

[0027] The user application 120 includes a database 130 , to save user input. The user application 120 It also includes a communicator. 132 The communicator 132transfers the data in the database 130 stored data, such as the start and end time of the calendar event, the event location, the request for the vehicle 102 , the selected pickup location, etc., to the first processor 104 of the vehicle 102 .

[0028] The data transmitted by the communicator 132 the user application of the first mobile device 106 to the first processor 104 of the vehicle 102 Transfers are handled by a scheduler 134 processed. In some examples, the first processor receives 104 Data, calendar events and vehicle requirements from the second mobile device 108 and / or the third mobile device 110 include the scheduler 134 determines whether the vehicle 102is available for the requirements associated with the calendar events originating from the first, second and / or third mobile device 106 , 108 , 110 were received. In order to determine if the vehicle 102 The scheduler takes into account whether a specific vehicle requirement is available. 134 For example, previously scheduled calendar events, the vehicle's location. 102 and the priority rules that are defined by the rule creator 128 the user application 120 were created. The scheduler 134 communicates with the first, second and third mobile device 106 , 108 , 110 , in order to use the vehicle 102 to confirm or the users of the mobile devices 106 , 108 , 110 to draw attention to conflicts in scheduling. The scheduler 134plans vehicle requirements based on an analysis of, for example, calendar event data, previously scheduled events, and vehicle usage patterns identified in the calendar event data.

[0029] Fig. Figure 2 illustrates a first example screen 200 the exemplary GUI 122 the first mobile device 106 out of Fig. 1. To enter a calendar event and to request an autonomous vehicle for the event, such as the vehicle 102 out of Fig. 1. Although the first exemplary screen 200 in Fig. 2 in conjunction with the first mobile device 106 The first example screen is shown. 200 via the GUIs 122 displayed are those of the second mobile device 108 and / or the third mobile device 110 out of Fig. are assigned to 1.

[0030] The first exemplary screen 200 sees user input related to a calendar event 202 before. The first user of the first mobile device 106 can the calendar event 202 enter by making an input using the first mobile device 106 is provided, for example, via typing or audio. The first user can, for example, name the calendar event. 202 Enter something like "doctor's appointment". The first example screen 200 It also includes event time fields. 204 , the start and end date and time for the calendar event 202 include the event time fields 204 They may include text fields and / or drop-down menus for entering the start and end date(s) and time of the event. The first example screen 200 It also includes an event location field. 206, to receive user input regarding the location of the calendar event 202 to receive.

[0031] As revealed above, the first user of the first mobile device wants to 106 the autonomous vehicle 102 out of Fig. 1. Use to find the location of the calendar event. 202 to reach or the location of the calendar event 202 to exit. In some examples, the first user provides user input to exit the vehicle. 102 via a vehicle request field 208 of the first exemplary screen 200 to request. The vehicle request field 208 It may, for example, include a checkbox or other selection tool that allows the first user to select the vehicle. 102 in connection with the calendar event 202 to request.

[0032] The first exemplary screen 200includes an arrival buffer zone 210 The first user enters a time span into the arrival buffer field. 210 one to indicate how far in advance of the start time and / or end time the first user will access the vehicle 102 The arrival buffer field is used to transport the first user to the event location and / or pick up the first user from the event location. 210 For example, it may include a text field or a drop-down menu that allows the first user to provide an input indicating how much time in advance of the start and / or end time the first user will pick up the vehicle. 102 want to let it arrive. In some examples, the arrival buffer field is 210 about the first example screen 200 selectively displayed when the first user enters the vehicle 102 via the vehicle request field 208 requests. In some examples, the arrival buffer field includes210 also two or more fields for receiving vehicle buffer times for the vehicle's arrival 102 , to direct the first user to the location of the calendar event 202 to drive, and for the arrival of the vehicle 102 , to get the first user from the location of the calendar event 202 to pick up.

[0033] The first exemplary screen 200 includes a vehicle arrival time field 212 As will be revealed below, the scheduler calculates 134 of the first processor 104 of the vehicle 102 based on the location of the calendar event 202 , the start and end date and time of the calendar event 202 , the requirement for the vehicle 102 and the arrival buffer time(s) the arrival time for the vehicle 102 at (1) a starting location of the first user, in order to direct the first user to the location of the calendar event 202to travel, and / or (2) the location of the calendar event 202 , to get the first user from the location of the calendar event 202 to be picked up. The vehicle arrival time field 212 displays the vehicle's arrival time 102 at the user's starting location and / or at the location of the calendar event.

[0034] The vehicle arrival time field 212 The vehicle's arrival time will be automatically calculated. 102 based on data from the scheduler 134 to be received, completed as will be revealed below. If the scheduler 134 determined that the vehicle 102 for the calendar event 202 The scheduler sends when it is available. 134 Arrival time data to the user application 120 , which are used to determine the vehicle arrival time field 212 to fill out. If the scheduler 134 in some examples determined that the vehicle 102for the calendar event 202 If it is not available, the scheduler indicates 134 the user application 120 on, the vehicle arrival time field 212 with an indication that the vehicle 102 is not available to fill in. The vehicle arrival time field 212 It may, for example, include indicators such as an "X" or "N / A" to inform the first user that the vehicle 102 is not available. In other examples, the scheduler determines 134 that the vehicle 102 is not available at the requested time, but is available at another time. In some examples, the scheduler indicates 134 the user application 120 on, the vehicle arrival time field 212 to fill in with an arrival time and to mark the arrival time (e.g. in italics, in bold, etc.) to indicate that the arrival time is a suggested alternative time.

[0035] The first exemplary screen 200 the user application 120 It also includes one or more menus that allow the first user to make additional settings regarding the vehicle requirement for the calendar event. 202 to define and / or view. The menus are available to the rule creator. 128 the user application 120 assigned and provide for the creation and / or viewing of event- or user-specific rules.

[0036] The first exemplary screen 200 includes a ride-sharing settings menu 214 The ride-sharing settings menu 214 allows the first user to activate ride-sharing opportunities, so that the vehicle 102 one or more trips before and / or after the first user's trip to the location of the calendar event 202 or picking up the first user from the location of the calendar event202 can undertake.

[0037] The first exemplary screen 200 includes a priority rule menu 216 As above regarding the rule creator 128 the user application 120 out of Fig. 1 reveals, the user application looks 120 the creation of rules regarding how calendar events created by the first, second and / or third user are handled by the scheduler 134 For example, it can be used to handle scheduling conflicts. The priority rule menu 216 of the first exemplary screen 200 It also allows the first user to create an event-specific rule for the calendar event. 202 to create. The first user can, for example, create a rule that the calendar event 202It should be considered a priority event over other conflicting calendar events.

[0038] The first exemplary screen 200 It also includes a vehicle settings menu. 218 As above regarding the rule creator 128 the user application 120 out of Fig. 1 reveals, the user application looks 120 the creation of rules regarding vehicle settings 102 for calendar events 202 before, which were created by the first, second and / or third user. The vehicle settings menu 218 allows the first user to configure one or more settings for the vehicle 102 to specify if the vehicle 102 picks up the first user to bring the first user to the calendar event 202 to bring, or the first user of the calendar event 202It retrieves the data and thus provides event-specific vehicle settings. For example, the first user can create a vehicle setting that the heating in the vehicle... 102 It should be in operation when the vehicle 102 arrives to be the first user from the location of the calendar event. 202 to pick up. Other examples of vehicle settings include radio station presets, which door is for the first user to enter the vehicle. 102 to be unlocked, etc.

[0039] The first exemplary screen 200 It also includes a pickup position field. 220 The pickup position field 220 allows the user to select a position on a map where the first user will pass through the vehicle 102 at the starting location of the first user and / or at the location of the calendar event 202to be picked up. As will be revealed below, in some examples, after selecting the pickup position field, 220 a new screen via the GUI 122 the first mobile device 106 This screen is displayed to allow the first user to provide one or more user inputs regarding pickup locations at the sites via a map. The first example screen 200 It also includes a confirmation button. 222 to select for the first user to access the calendar event 202 to save, and a cancel button 224 , to the calendar event 202 to discard. When saving the calendar event. 202 The first user confirms the (e.g., suggested) arrival time, with which the vehicle arrival time field is entered. 212was automatically filled in, and thus confirms the vehicle request (or the rejection of the vehicle request if the vehicle 102 is not available).

[0040] Fig. Figure 3 illustrates a second example screen 300 the exemplary GUI 122 , the first mobile device 106 out of Fig. 1 is assigned to define or view one or more vehicle settings. 102 The second example screen 300 out of Fig. 3 can be selected after choosing, for example, the ride-sharing settings menu. 214 , of the priority rule menu 216 and / or the vehicle settings menu 218 can be viewed. The second example screen 300 may have additional or fewer menus than in Fig. 3 illustrates this. Although the second example screen 300 in Fig. 3 in conjunction with the first mobile device 106 As shown, the second example screen 300 via the GUIs 122 displayed are those of the second mobile device 108 and / or the third mobile device 110 out of Fig. are assigned to 1. Although the second example screen 300 in Fig. 3 as another screen relative to the first example screen 200 out of Fig. As illustrated in point 2, the second example screen will be shown. 300 In some examples, also via the GUI 122 with the first exemplary screen 200 displayed (e.g. as a pop-up window, an overlay screen and / or as part of the first sample screen) 200 ).

[0041] The second example screen 300 will be in conjunction with the rule creator 128 the user application 120displayed. The rule creator 128 It allows the creation of rules on a user-based or event-based basis. The second example screen 300 includes a rule definition field 301 , which allows the first user to see whether one or more settings are displayed on the second example screen 300 is / are defined, should be applied to all events created by the first user (e.g., default rule(s)) or only to the calendar event 202 are supposed to apply.

[0042] The second example screen 300 includes a carpooling settings field 302 , which is the carpooling settings menu 214 out of Fig. 2 is assigned. The carpooling settings field 302 allows the first user to choose whether or not to include the calendar event 202with other calendar events (e.g., calendar events entered by the first, second, or third user via the respective user application) 120 were entered) in relation to the use of the vehicle 102 This can be summarized. In some examples, the carpooling settings field is... 302 Selected by default to enable ride-sharing. As will be revealed below, when the scheduler 134 of the vehicle 102 out of Fig. 1 stipulates that carpooling options are used to summarize calendar events. 202 regarding the use of the vehicle 102 are available, a ride-sharing details field 304 of the exemplary second screen 300 based on user application 120 from the scheduler 134 The received data was automatically filled in. The ride-sharing details field 304For example, it contains information regarding other journeys the vehicle has made. 102 before and / or after the calendar event 202 can undertake. Thus, in some examples, the carpooling details field represents 304 additional details regarding the vehicle's arrival time 102 ready, which is through the scheduler 134 proposed and via the vehicle arrival time field 212 of the first exemplary screen 200 out of Fig. 2 is displayed.

[0043] The second example screen 300 includes an event priority selection device 306 , which are in the priority rule menu 216 out of Fig. 2 is assigned. The event priority selection device 306 allows the first user to access the calendar event 202 to assign a priority level to determine how the calendar event 202This is addressed with regard to other calendar events and potential scheduling conflicts. For example, if the calendar event 202 via the event priority selection device 306 A high priority is assigned to the calendar event 202 It takes precedence over another event scheduled for the same time, if the scheduler determines it 134 The planner evaluates the calendar event. If, for example, a medium or low event priority is assigned to the event, it identifies the event as being of medium or low priority. 134 out of Fig. 1 the calendar event 202 as an event that can be rescheduled or canceled if there is a scheduling conflict with another event. In some examples, the event priority selection feature includes 306 A text field for the first user to enter event-specific priority rules.

[0044] The second example screen 300 includes a vehicle settings selection device 308 , which are in the vehicle settings menu 218 out of Fig. 2 is assigned. The vehicle settings selection device 308 includes one or more vehicle settings for selection by the first user, such as a radio station preferred by the first user, the vehicle 102 reproduces when the vehicle 102 for the first user, and / or a temperature setting of the vehicle 102 (e.g. the vehicle) 102 instruct the heating to already be switched on when the vehicle 102 (arrives for the first user). The second example screen 300 It also includes a confirmation button. 310 for the first user to select, to save the settings, and a cancel button. 312, to discard the settings. In some examples, the first user confirms by selecting the confirmation button. 310 the carpooling details provided by the scheduler 134 via the carpooling details field 304 be proposed.

[0045] Fig. Figure 4 illustrates a third example screen 400 the exemplary GUI 122 , the first mobile device 106 out of Fig. 1 is assigned to select a pickup position at a location by the vehicle 102 The third example screen 400 is the local selection facility 126 the user application 120 out of Fig. 1 and in particular the pickup position field 220 of the first exemplary screen 200 out of Fig. 2 assigned. Although the third example screen 400 in Fig. 3 in conjunction with the first mobile device 106 As shown, the third example screen 400 via the GUIs 122 displayed are those of the second mobile device 108 and / or the third mobile device 110 out of Fig. are assigned to 1. Although the third example screen 400 in Fig. 4 as a different screen relative to the first example screen 200 out of Fig. 2 and the second example screen 300 out of Fig. As illustrated in section 3, the third example screen will be shown. 400 In some examples, also via the GUI 122 with the first exemplary screen 200 or the second example screen 300 displayed (e.g. as a pop-up window, an overlay screen and / or as part of the first or second example screen) 200 , 300 ).

[0046] As in Fig. As shown in section 4, the third example screen includes... 400 a card 402 In some examples, the map 402 A map of the first user's starting location. The first user's starting location can be their current location, determined using, for example, the GPS of the first mobile device. 106 was determined. In other examples, the scheduler determines 134 of the first processor 104 automatically determines the starting location of the first user based on previous calendar events and assigns the user application 120 on, the card 402 based on the determination to display. In other examples, the map is 402 a map of the location of the calendar event 202 based on the data that went into the location field 206 of the first exemplary screen 200 through the scheduler 134were entered and processed.

[0047] The map 402 of the third exemplary screen 400 includes a position selection device 404 The position selection device 404 This could be, for example, a pin or another graphic representation. The first user interacts with the map. 402 , by selectively selecting the position selection device 404 to the position on the map 402 moved (e.g. by dragging across the touchscreen) where the first user moved the vehicle 102 wants to let them arrive. The first user can, for example, use the position selection setup. 404 to the front of one on the card 402 move the vehicle to the building shown. 102 to instruct the user to arrive at the front of the building. As another example, the first user can use the position selection device. 404move to a street intersection near the building to park the vehicle 102 to instruct them to arrive at the intersection rather than the building. The third example screen 400 includes a confirmation button 406 for selection by the first user to confirm the pickup position, which is determined by the position of the position selection device. 404 on the map 402 is displayed, and a cancel button 408 , in order to reject the changes.

[0048] After the first user selects the position selection device 404 via the third example screen 400 out of Fig. In some examples, the first user is saved to the first example screen after saving to 4. 200 out of Fig. 2 returned. The first user can press the confirmation button. 222 of the first exemplary screen 200select to choose the calendar event 202 and associated setting parameters, including those set by the scheduler 134 proposed arrival time of the vehicle 102 , in the calendar 124 the user application 120 out of Fig. 1 to save. In some examples, the calendar event 202 with other users (e.g. the second user of the second mobile device) 108 and / or the third user of the third mobile device 110 ), who also has a place on the calendar 124 accesses / shared.

[0049] Fig. Figure 5 illustrates a fourth example screen 500 the exemplary GUI 122 , the first mobile device 106 out of Fig. 1 is assigned to view calendar events entered by the first, second and / or third user via the respective user application. 120the first, second or third mobile device 106 , 108 , 110 were created. Although the fourth example screen 500 in Fig. 5 in conjunction with the first mobile device 106 As shown, the fourth example screen 500 via the GUIs 122 displayed are those of the second mobile device 108 and / or the third mobile device 110 out of Fig. are assigned to 1.

[0050] In some examples, the first user can control the vehicle's scheduling. 102 want to look at it before he sees the vehicle 102 via the user application 120 requests. If the start and / or end time of the calendar event 202 Being flexible, the first user might, for example, want to view the calendar events that were entered by the second and / or third user via the user application.120 They were scheduled to see when the vehicle would arrive. 102 is available, and / or to schedule a calendar event in conjunction with a previously scheduled event in order to ride along with the user of the previously scheduled event. As in Fig. As illustrated in section 5, the fourth example screen shows 500 one or more calendar events that are entered by users of, for example, the first, second and / or third mobile device 106 , 108 , 110 about the calendar 124 the user application 120 , which are on each of the mobile devices 106 , 108 , 110 is installed, were entered as essentially above in connection with the example screens 200 , 300 , 400 out of Fig. 2– Fig. 4 is revealed. The fourth example screen 500For example, the calendar event shows 202 on, which is shown on the first exemplary screen 200 out of Fig. 2 by the first user of the first mobile device 106 was created. The fourth example screen 500 This also shows a second calendar event. 502 , a third calendar event 504 and a fourth calendar event 506 on, which are used by the users of the first, second and / or third mobile device 106 , 108 , 110 were created. The fourth example screen 500 out of Fig. Option 5 can display additional or fewer calendar events.

[0051] In some examples, two or more of the calendar events are used. 202 , 502 , 504 , 506 via the fourth example screen 500 as a single, combined event 508displayed, indicating that the events are ride-sharing events related to the use of the vehicle. 102 are. In the example from Fig. 5 is the third calendar event 504 and the fourth calendar event 506 Ride-sharing events that comprise the aggregated event 508 form. The vehicle 102 will, for example, pick up the user who attended the third calendar event 504 is assigned, and then the user who is assigned to the fourth calendar event 506 is assigned as part of a single journey for the vehicle 102 pick up (e.g., the user assigned to the third calendar event is in the vehicle) 102 , if the vehicle 102 picks up the user who is attending the fourth calendar event 506 (is assigned). The carpooling calendar events 504 , 506 can be visually distinguished from the other calendar events202 , 502 via the fourth example screen 500 They can be distinguished by means of color coding and / or other graphical distinctions (e.g., graphic symbols, shading, etc.). In some examples, the fourth sample screen includes 500 one or more ride-sharing time markers 510 , which indicate that certain times are reserved for ride-sharing events. In examples where the first user schedules the vehicle 102 looks at the vehicle 102 requests, informs the carpool time marker(s) 510 informs the first user whether a calendar event scheduled during a predefined time will be combined with other calendar events for carpooling purposes.

[0052] Fig. 2– Fig. Figure 5 illustrates sample calendar screens.124 and the site selection facility 126 the user application 120 to create a calendar event 202 , 502 , 504 , 506 and to request the vehicle 102 for the calendar event 202 , 502 , 504 , 506 As shown in the fourth example screen 500 out of Fig. As illustrated in point 5, any user of the first, second, and third mobile device can 106 , 108 , 110 Calendar events 202 , 502 , 504 , 506 about the mobile devices 106 , 108 , 110 installed user application 120 create. When creating calendar events, each user can select the vehicle. 102 for the events. However, conflicts can arise in scheduling based on calendar events and vehicle availability.102 arise. The scheduler 134 of the first processor 104 of the vehicle 102 manages the requirements for the vehicle 102 with regard to the calendar events 202 , 502 , 504 , 506 .

[0053] Fig. Figure 6 is a block diagram of the example scheduler 134 out of Fig. 1. The scheduler 134 includes a request recipient 600 The recipient of the request 600 receives calendar events via the user application 120 the first, second and / or third mobile device 106 , 108 , 110 were created, and transfers them to the scheduler. 134 via the communicator 132 the user application 120 For example, if the first, second and / or third user of the mobile devices 106 , 108 , 110a new calendar event via the user application 120 enter (e.g., calendar events) 202 , 502 , 504 , 506 out of Fig. 2– Fig. 5), the communicator sends 132 the user application 120 the calendar event data (e.g. in conjunction with the event time fields) 204 , the local field 206 , the vehicle requirements field 208 , the arrival buffer zone 210 , the position selection device 404 etc. Fig. 2 and Fig. 3 received data) to the first processor 104 of the vehicle 102 The recipient of the request 600 determines whether the calendar event data represents a requirement for the vehicle 102 in connection with the event. In some examples, the request receiver receives 600Updated calendar event data for a previously scheduled calendar event initiated by a user of the user application. 120 was modified, for example to meet a requirement for the vehicle 102 to include.

[0054] The vehicle requirements and the related calendar event data provided by the request recipient 600 received, are stored in a database 602 saved. The database 602 Stores vehicle requests and related calendar event data for requests made via the user application. 120 the first, the second and the third mobile device 106 , 108 , 110 be received. The database 602 It also stores data, such as predefined priority rules, which are entered by the first, second and / or third user via the user application. 120to be entered. The database 602 It also stores user preferences regarding vehicle settings, such as heating settings or radio station presets. Thus, the database stores... 602 Data processed by the scheduler 134 from the users of the vehicle 102 be received.

[0055] The database 602 It also includes a vehicle calendar. 603 The vehicle calendar 603 stores vehicle requirements for the vehicle 102 , in order to plan the timeline for the vehicle 102 to create. The one in the vehicle calendar 603 stored data regarding the vehicle's scheduling 102 can be done, for example, via the fourth example screen 500 the user application 120 can be viewed, which displays the calendar events entered by the users of the first, second, and third mobile devices.106 , 108 , 110 were created.

[0056] The scheduler 134 includes a conflict analyzer 604 After receiving a new vehicle request, the conflict analyzer analyzes 604 The calendar data associated with the new vehicle request is retrieved and compared with previously stored calendar data. The conflict analyzer... 604 determines whether there is a conflict between the new vehicle requirement and previously planned vehicle requirements that are in the database 602 and the vehicle calendar 603 are stored, exists. The conflict analyzer 604For example, it compares the calendar event data, such as the start and end time and location, assigned to the new vehicle request with calendar event data assigned to previously scheduled vehicle requests for the same day. In some examples, the conflict analyzer compares 604 the new vehicle requirement data with time-planned requirements within a threshold time period before and / or after the start or end time of the calendar event for the new vehicle requirement.

[0057] The conflict analyzer 604 Determines whether there are direct conflicts between the new vehicle request and previously scheduled vehicle requests, such as a vehicle request scheduled for the same day and time as the new vehicle request. In other examples, the conflict analyzer determines604 A direct conflict exists if one or more previously scheduled vehicle requests overlap with the start and / or end time of the new vehicle request. When determining whether a direct conflict exists between the new vehicle request and the previously scheduled vehicle request(s), the conflict analyzer considers the following: 604 to the rules that are set by the rule creator 128 the user application 120 were created, including the standard rules and / or the calendar event-specific rules (which are created, for example, via the priority rule menu). 216 of the first and second example screens 200 , 300 out of Fig. 2 and Fig. 3 were created). For example, if the calendar event associated with the new vehicle request is marked as a high-priority event, or if the user who created the calendar event for the new vehicle request is assigned to a default rule that prioritizes the calendar event over other calendar events, then other previously scheduled events for the same time as the new vehicle request may be identified as conflicting with the new vehicle request.

[0058] If the conflict analyzer 604 If it is determined that a direct conflict exists between the new vehicle requirement and one or more previously scheduled events, the conflict analyzer communicates 604 with a requirements confirmation device 606 the scheduler 134 , to the request confirmation facility 606to inform about the conflict. The requirements confirmation facility 606 Generates one or more conflict alerts to be transmitted to the mobile device of the user who created the new vehicle request and / or to the mobile device(s) of the user(s) who created the previously scheduled vehicle requests. For example, if the new vehicle request made by the first user via the first mobile device 106 was created, is in direct conflict with a previously planned vehicle request made by the second user via the second mobile device 108 Once created, the request confirmation facility sends 606 a warning message to the user application 120 the first mobile device 106 The vehicle request was rejected. In response to the warning message, the user application fills in the information. 120the vehicle arrival time field 212 with an indication that the vehicle 102 is not available (e.g. via an "X" in the vehicle arrival time field). 212 ).

[0059] As revealed above, in some examples the new vehicle requirement that is made by the first user via the first mobile device 106 The request, which was created, is assigned to a high-priority event. In such examples, the request acknowledgment facility transmits the request. 606 a warning message to the second mobile device 108 , to inform the second user that there is now a conflict with the second user's previously scheduled vehicle request. The user application 120 the second mobile device 108 For example, the vehicle arrival time field can 212 Update for the previously scheduled vehicle request (e.g., based on a scheduler).134 (received vehicle arrival time) and generate a message for the second user to view. In other examples, the request acknowledgment device sends 606 Warning messages to the first mobile device 106 and the second mobile device 108 , if the vehicle arrival time field 212 The scheduler updates for each request to match both requests. 134 to accommodate the received data.

[0060] The scheduler 134 It also analyzes the calendar event data to determine if there are any indirect conflicts with (a) previously scheduled vehicle request(s) or scheduling conflicts that are not caused by an overlap of event times, but which affect the vehicle 102This could still prevent the vehicle from fulfilling the new vehicle requirement or a previously scheduled vehicle requirement. For example, even if a new vehicle requirement cannot overlap with a previously scheduled vehicle requirement, the vehicle may still be unable to meet the new requirement. 102 not be able to determine the location of the calendar event that triggers the new vehicle request at the requested time with regard to the vehicle's location. 102 The assigned vehicle is to be achieved if it fulfills a previously scheduled vehicle request that precedes the new vehicle request. When determining whether any indirect conflicts exist, the scheduler determines 134 a route of the vehicle 102 , to reach the location of the calendar event, and travel times of the vehicle 102 , in order to reach the place.

[0061] The scheduler 134 includes a journey planner 608 The journey planner608 analyzes the calendar event data and calculates an arrival time for the vehicle. 102 to reach a location assigned to the new vehicle request (e.g., a designated location, such as a starting point or the calendar event location). In some examples, the trip planner calculates 608 the arrival time for the vehicle 102 to reach the user's location, to pick up the user and drive them to the location of the calendar event. In other examples, the trip planner calculates 608 the arrival time for the vehicle 102 , to reach the location of the calendar event, to pick up the user from the calendar event. The journey planner 608 also provides a map of the location (e.g., the map) 402 of the third exemplary screen 500 ) for display via the GUIs 122 the mobile devices 106 , 108 , 110and to select the pickup location on site (e.g. via the location selection device). 404 of the third exemplary screen 500 to enable.

[0062] When calculating the vehicle's arrival time 102 The journey planner generates 608 one or more routes of the vehicle 102 , in order to reach the intended location. The route planner 608 receives vehicle location data from the vehicle position sensor 610 the scheduler 134 After receiving a new vehicle request via the request recipient 600 The vehicle position sensor determines 610 a current location of the vehicle 102 or an expected location of the vehicle 102 at a time preceding a calendar event to which the new vehicle request is assigned. The vehicle position sensor 610 determines the current or expected location of the vehicle 102using, for example, GPS information or location data for a previously scheduled calendar event that precedes the calendar event for the new vehicle request (e.g., in the database). 602 (stored location data).

[0063] The journey planner 608 determines one or more routes of the vehicle 102 , to determine the location of the new vehicle request based on the current or expected location of the vehicle 102 , which is determined by the vehicle position sensor 610 is determined to reach. The journey planner 608 For example, it uses GPS information and navigation tools (e.g., mapping applications installed in the vehicle). 102 as part of the infotainment services) and / or from the vehicle 102 Previously taken routes that are in the database 602 are stored to determine the vehicle's route(s). 102 from the current or expected location of the vehicle102 to determine the location of the new vehicle request. In some examples, the route planner selects 608 a route from two or more available routes based, for example, on the shortest distance, traffic congestion, construction sites, etc.).

[0064] The journey planner 608 calculates the estimated travel time for the vehicle 102 To reach the intended location, the trip planner uses the selected route to determine an arrival time for the vehicle at that location (e.g., the pick-up point). 608 the estimated travel time of the vehicle, based on the scheduled start and / or end time of the calendar event assigned to the new vehicle request. 102 , the arrival buffer time for the arrival of the vehicle 102before the scheduled start and / or end time (e.g., as input by the user via the arrival buffer time field) 210 of the first exemplary screen 200 ) and any other additional preparation time or time required to implement one or more vehicle settings (e.g., time the vehicle 102 (based on the vehicle settings entered by the user for heating). The first user can, for example, request that the vehicle 102 at a calendar event 202 , which ends at 11:00 AM, with a five-minute arrival buffer, and that the vehicle has heating 102 an interior of the vehicle 102 heated to 72 degrees. The journey planner 608 estimates that the vehicle 102It will take 30 minutes to reach the destination. Based on the scheduled event time, the estimated travel time, the arrival buffer time, and the additional preparation time (e.g., to warm up the vehicle), the trip planner determines 608 that the vehicle 102 will arrive at 10:55 am to adhere to the arrival buffer time, and should depart for the location at 10:20 am to allow for travel time and preparation time to warm up the vehicle.

[0065] The conflict analyzer 604 analyzes the vehicle's arrival time 102 at the location for the new vehicle request, taking into account previously scheduled vehicle requests that precede or follow the new vehicle request. If there are no conflicts between the vehicle's arrival time 102The requirement confirmation facility transmits the information to the location where the new vehicle requirement and the previously planned requirements exist. 606 the arrival time to the user application 120 The user application 120 fills the vehicle arrival time field 212 with the arrival time. The first user can confirm the vehicle request with the arrival time via the confirmation buttons. 222 , 310 of the first or the second example screen 200 , 300 out of Fig. 2 and Fig. 3. Confirm or accept.

[0066] If the conflict analyzer 604 determined that the vehicle 102will not be able to arrive at the designated location at the latest by the scheduled start time, end time or arrival buffer time for the calendar event (or within a predetermined threshold of the start time, end time or arrival buffer time) due, for example, to the estimated travel time of the vehicle. 102 In order to reach the place, to arrive, the conflict analyzer identifies 604 The new vehicle requirement is considered a conflict with one or more previously planned events. The conflict analyzer 604 communicates with the request confirmation facility 606 the scheduler 134 , to the request confirmation facility 606 to inform about the conflict. The requirements confirmation facility 606 transmits a conflict warning message to the user application 120the mobile device of the user who created the new vehicle request, and / or the mobile device(s) of the user(s) who created the previously scheduled vehicle request(s).

[0067] In some examples, the conflict analyzer identifies 604 The new vehicle requirement presents a conflict if the vehicle 102 will not be able to meet an arrival time for a vehicle request that follows the new vehicle request. The conflict analyzer 604 For example, it compares an expected location of the vehicle. 102 , if the vehicle 102 The new vehicle requirement should meet the location and planned arrival time of the previously scheduled event. In some examples, the vehicle 102being unable to arrive at the location of the previously planned event on time due to, for example, the vehicle requirement necessitating that the vehicle 102 to a location that determines the estimated travel time for the vehicle 102 to reach the location of the previously planned calendar event (such as through the journey planner). 608 calculated). In such examples, the conflict analyzer identifies 604 The new vehicle requirement is seen as a conflict due to its impact on the previously planned vehicle requirement.

[0068] In other examples, the conflict analyzer identifies 604One or more previously scheduled events that precede and / or follow the new vehicle request constitute a conflict. For example, the calendar event associated with the new vehicle request may have a high event priority. If the vehicle 102 is unable to determine the arrival time for the new vehicle request due to, for example, the estimated travel time from the location associated with the previously scheduled calendar event (such as through the trip planner). 608 The conflict analyzer identifies the requirements to be met (calculated). 604 The previously planned vehicle request presents a conflict with regard to the priority assigned to the new vehicle request.

[0069] As revealed above, the conflict analyzer shares 604in examples where a conflict between the new vehicle requirement and one or more previously scheduled vehicle requirements causes the requirement confirmation device to conflict 606 with. The request confirmation facility 606 transmits a conflict warning message to the user application 120 , which is assigned to the mobile device(s) of the user who created the new vehicle request and / or the user(s) who created the previously scheduled vehicle request(s). Based on the warning message from the request confirmation device. 606 The user application fills 120 the vehicle arrival time field 212 of the first exemplary screen 200 out of Fig. 2 for example the GUI 122 , where the new vehicle request was generated, with a display indicating that the vehicle 102is not available. In some examples, the request acknowledgment facility sends 606 The user is given a customized arrival time for the vehicle 102 based on a future time when the vehicle 102 is available, as through the scheduler 134 with regard to the scheduling of vehicles, which is shown in the vehicle calendar 603 is stored, and the analysis performed by the conflict analyzer 604 , the journey planner 608 and the vehicle position sensor 610 The process is carried out, and is determined. In such examples, the user application fills in the data. 120 the vehicle arrival time field 212 of the first exemplary screen 200 with a suggested or alternative time.

[0070] After seeing the advertisement that the vehicle 102If the vehicle request(s) is unavailable or the suggested alternative time is not available, the user(s) can resolve the conflict by, for example, rescheduling the calendar event(s) associated with the vehicle request(s) to a different day and / or time, or by accepting the suggested alternative time. After receiving the revised calendar event data and the vehicle request(s), which the user submits via their mobile devices, the vehicle request(s) will be processed. 106 , 108 , 110 was modified, via the request recipient 600 , determined by the scheduler 134 , whether there are any conflicts with the newly planned vehicle requirements (e.g., based on the arrival times provided by the journey planner) 608 (calculated using the revised calendar event data).

[0071] In some examples, the scheduler suggests 134shared use of the vehicle 102 for two or more calendar events to resolve the conflict between vehicle requirements. The scheduler 134 The scheduler can also suggest ride-sharing opportunities or combine two or more calendar events with associated vehicle requirements, provided there is no conflict between the vehicle requirements. 134 For example, it can identify opportunities for carpooling to improve the efficiency of vehicle use. 102 to maximize efficiency and / or to protect the environment. In some examples, the scheduler indicates 134 certain time slots are restricted to carpooling opportunities (e.g., time slots preset by the user), such as weekdays from 3 pm to 6 pm.

[0072] To identify carpooling opportunities, the carpooling analyzer analyzes 612the scheduler 134 The calendar event data (e.g., location, start and / or end time) associated with the new calendar event and previously scheduled events is used to determine whether any of the vehicle requests can be combined into a single ride. If two or more vehicle requests can be combined, the ride analyzer will communicate this. 612 with the request confirmation facility 606 , in order to make a ride-sharing suggestion to users who have specified the vehicle requirements, which can be summarized via the mobile devices 106 , 108 , 110 have created. In some examples, the ride-sharing suggestion is made via the ride-sharing details field. 304 of the second example screen 300 out of Fig. 3 of the respective GUIs 122 displayed on the mobile devices.

[0073] The vehicle position sensor 610 For example, it can determine that a calendar event location for a previously scheduled vehicle request, which precedes the new vehicle request, is close to a calendar event location for the new vehicle request, and / or that the route to each location overlaps at least partially. In such examples, the ride-sharing analyzer identifies 612 The previously planned vehicle request and the new vehicle request as a potential ride-sharing opportunity. Based on the routes and travel times generated by the trip planner. 608 The carpooling analyzer determines which vehicles are intended for the new vehicle request and the previously planned vehicle request. 612 a route for the vehicle 102To reach the respective location of the previously planned vehicle request and the new vehicle request as a single trip with several stages. The ride-sharing analyzer 612 It also calculates an arrival time at each location based on the route. In some examples, the arrival times for each location match the originally requested arrival times for each vehicle request. In other examples, the rideshare analyzer suggests 612 a new arrival time for one or more of the events is provided if the new arrival time is within a threshold timeframe of the originally requested arrival time for the vehicle (e.g., within half an hour of the originally requested arrival time).

[0074] Referring to the first user of the first mobile device 106 and the second user of the second mobile device 108For example, the rideshare analyzer 612 suggest, for example, picking up the first and second users from a starting location and driving them to their respective locations, or picking up the first or second user from a first location and picking up the other user from a second location, while the user picked up from the first location is still in the vehicle. 102 The request confirmation facility is located there. 606 transmits the proposed ride-sharing opportunity, including the proposed arrival times for each leg of the journey, to the user application. 120 the first and second mobile device 106 , 108 to display via the ride-sharing details field 304 of the second example screen 300 out of Fig. 3. If the first and / or second user accepts the proposed ride (e.g., via respective confirmation buttons). 310 The calendar events associated with each vehicle request are automatically aggregated into a single event via the user application. 120 the mobile devices 106 , 108 , 110 displayed (e.g. the summarized event) 508 of the fourth exemplary screen 500 out of Fig. 5).

[0075] Thus, the scheduler sees 134 an automatic evaluation and adjustment of vehicle requirements based on the vehicle's time schedule 102 before. If the scheduler 134 If one or more conflicts are identified, the scheduler warns 134 the user application 120 regarding the conflict, and in some examples it matches the arrival times and / or the routes of the vehicle.102 selectively to accommodate multiple vehicle requests (e.g., by suggesting ride-sharing opportunities). The scheduler 134 It provides dynamic management of vehicle requirements through automatic scheduling of requirements, without requiring users to access a separate user application for the vehicle or to manually schedule the vehicle. 102 have to manage.

[0076] If there are no conflicts between the new vehicle request and the previously planned requirements, and / or if the conflicts are resolved (e.g., through rescheduling, accepting an adjusted arrival time, or accepting a ride-sharing opportunity), and the user(s) have confirmed the vehicle's arrival time. 102 accept (e.g. via the confirmation buttons) 222 , 310 of the first and second example screens 200 , 300 out of Fig. 2 and Fig. 3) adds the request confirmation device 606 the new vehicle requirement to the vehicle calendar 603 the database 602 to. After the new vehicle request is added to the vehicle calendar 603 The added scheduler directs 134 the vehicle 102 to fulfill the requirement at the planned time.

[0077] The scheduler 134 includes vehicle control 614 , to the vehicle 102 to guide one or more requirements based on the vehicle's time schedule as shown in the vehicle calendar 603 is stored, to fulfill. The vehicle control 614 monitors the vehicle calendar 603 The vehicle control system 614 guides the vehicle 102 with regard to parameters of a vehicle request, when the vehicle request is ready to be fulfilled by issuing one or more instructions to the vehicle102 be sent. The vehicle control 614 For example, the vehicle directs 102 along the route to determine the location of the calendar event associated with the vehicle request and the pickup position at that location (e.g., by the user via the position selection device). 404 of the second example screen 400 out of Fig. 4 selected) to achieve the vehicle control 614 The vehicle also indicates 102 on, the vehicle settings input by the user, for example regarding vehicle heating. 102 to implement this. Thus, the vehicle control system indicates 614 the vehicle 102 with regard to the execution of the vehicle requirement.

[0078] Data that meets the vehicle requirements, which are processed by the vehicle 102 The data assigned to the execution process, such as locations and routes, are stored in the database. 602 saved. The scheduler134 includes a tracking device for previous journeys 616 to analyze vehicle request data and calendar event data and identify patterns in the data. The tracking device for previous trips. 616 can include user-specific vehicle usage patterns, such as requirements for the vehicle 102 for a calendar event that occurs weekly at the same time. The tracking device for previous trips. 616 Identifies patterns regarding the user's preferred arrival buffer time for the vehicle 102 The tracking system for previous journeys 616 It also identifies patterns related to the vehicle 102 Routes taken. The tracking system for previous trips. 616 For example, it identifies that the vehicle 102 travels the same route to a location twice a week.

[0079] In addition to managing requests made by the first, second and / or third user of the first, second and third mobile device 106 , 108 , 110 will be generated, says the scheduler 134 Vehicle requirements based on the tracking device for previous journeys 616 The analysis of vehicle usage and calendar event data was conducted beforehand. The scheduler 134 includes a prediction device 618 If the first user creates a new calendar event as an example, which is then requested by the recipient... 600 The prediction device identifies the received device. 618 based on the tracking device for previous journeys 616 The data analysis performed showed that the new calendar event is assigned to a location to which the vehicle 102previously driven. After receiving the calendar event, the trip planner can 608 also automatically calculates a route to the location of the calendar event based on current or expected vehicle location data provided by the position sensor. 610 were determined to identify whether the vehicle 102 the route previously driven.

[0080] If the prediction device 618 determined that the vehicle 102 previously travelled to the location of the new calendar event and / or the route planner 608 has taken a specific route, says the forecasting facility 618 prior to the first user using the vehicle 102 will be needed for the calendar event. The forecasting tool 618 communicates with the request confirmation facility 606 , to prompt the user application 120 the first mobile device 106to send to ask the first user if the first user will use the vehicle 102 for the calendar event. In some examples, the request includes instructing the user application. 120 , the vehicle requirements field 208 to preselect automatically. In other examples, the prompt directs the user application. 120 a new window (e.g., a pop-up window above the first example screen) 200 out of Fig. 2) to display, asking the first user if they want to see the vehicle 102 would like to request. In some examples, the request directs the user application. 120 on, the arrival buffer zone 210 based on the patterns in the arrival buffer time input by the first user, as determined by the tracking device for previous trips 616 The data was analyzed and automatically filled in. In some examples, the prediction device directs the user to...618 the request confirmation facility 606 to send the request when the conflict analyzer 604 determined that there will be no conflicts with a vehicle request for the new calendar event.

[0081] In other examples, the forecasting device says 618 based on the tracking device for previous journeys 616 The analysis performed beforehand indicated that the first user would create a calendar event that included a vehicle request. The tracking feature for previous trips 616 For example, it can determine that the first user is planning an event for the third Tuesday of each month at a specific location. The prediction feature 618 The prediction feature can predict that the first user will schedule an event for the third Tuesday of the next month at that location. 618can the request confirmation facility 606 guide, a prompt to the user application 120 to send, automatically generate the calendar entries for the third Tuesday of each month for the location, and a request for the vehicle 102 to include.

[0082] When the first user confirms that the vehicle 102 The application should be requested for the calendar event, and / or when the first user confirms the automatically generated calendar events, the user application will request 120 the user is informed of the pickup position at that location (e.g. via the position selection device). 404 of the fourth exemplary screen 500 ) to select. The scheduler 134 The vehicle calendar also plans the requirements in terms of timing. 603 , as substantially disclosed above. Thus, the scheduler manages 134user-generated requirements and also states user needs for the vehicle 102 based on an analysis of previous data to automatically generate vehicle requirements.

[0083] While in Fig. 1– Fig. 6. An exemplary way to implement the exemplary system 100 As illustrated, one or more of the elements, processes and / or one or more of the devices that are in Fig. 1– Fig. The six illustrated elements can be combined, subdivided, rearranged, omitted, eliminated, and / or implemented differently. Furthermore, the exemplary first processor can be... 104 , the first mobile device 106 , the second mobile device 108 , the third mobile device 110 , the second processor 118 each of the first, second and third mobile devices 106 , 108 , 110 , the user application120 (including the calendar) 124 , the location selection facility 126 , of the rule creator 128 , the database 130 , of the communicator 132 ) and the scheduler 134 (including the request recipient) 600 , the database 602 , of the vehicle calendar 603 , of the conflict analyzer 604 , the request confirmation facility 606 , of the journey planner 608 , of the vehicle position sensor 610 , of the rideshare analyzer 612 , the vehicle control 614 , the tracking device for previous journeys 616 and the forecasting device 618 ) and / or more generally, the exemplary system 100 It can be implemented through hardware, software, firmware, and / or any combination of hardware, software, and / or firmware. Thus, the first exemplary processor 104, the first mobile device 106 , the second mobile device 108 , the third mobile device 110 , the second processor 118 each of the first, second and third mobile devices 106 , 108 , 110 , the user application 120 (including the calendar) 124 , the location selection facility 126 , of the rule creator 128 , the database 130 , of the communicator 132 ) and the scheduler 134 (including the request recipient) 600 , the database 602 , of the vehicle calendar 603 , of the conflict analyzer 604 , the request confirmation facility 606 , of the journey planner 608 , of the vehicle position sensor 610 , of the rideshare analyzer 612 , the vehicle control 614 , the tracking device for previous journeys 616and the forecasting device 618 ) and / or more generally, the exemplary system 100 The device or system may be implemented by one or more analog or digital circuits, logic circuits, programmable processors, application-specific integrated circuits (ASICs), programmable logic devices (PLDs), and / or field-programmable logic devices (FPLDs). If each of the device or system claims of this patent is interpreted to cover a purely software and / or firmware implementation, the exemplary first processor is / are hereby defined. 104 , the first mobile device 106 , the second mobile device 108 , the third mobile device 110 , the second processor 118 each of the first, second and third mobile devices 106 , 108 , 110 , the user application 120 (including the calendar) 124, the location selection facility 126 , of the rule creator 128 , the database 130 , of the communicator 132 ) and the scheduler 134 (including the request recipient) 600 , the database 602 , of the vehicle calendar 603 , of the conflict analyzer 604 , the request confirmation facility 606 , of the journey planner 608 , of the vehicle position sensor 610 , of the rideshare analyzer 612 , the vehicle control 614 , the tracking device for previous journeys 616 and the forecasting device 618 ) and / or more generally, the exemplary system 100explicitly defined as including a tangible, computer-readable storage device or storage medium, such as a memory card, a Digital Versatile Disc (DVD), a Compact Disc (CD), a Blu-ray Disc, etc., which stores the software and / or firmware. Furthermore, the exemplary system may 100 out of Fig. 1– Fig. 6. include one or more elements, processes and / or devices in addition to or instead of those which are described in Fig. 1– Fig. 6 are illustrated, and / or it may include more than one of any or all of the illustrated elements, processes and devices.

[0084] Fig. Figure 7 illustrates a flowchart that demonstrates an exemplary procedure. 700This illustrates a possible implementation for automatically scheduling an autonomous vehicle via a calendar user application and the vehicle's scheduling manager. The exemplary procedure 700 can be done using the scheduler 134 of the vehicle 102 and the user application 120 the respective mobile device 106 , 108 , 110 out of Fig. 1– Fig. 6. The exemplary procedure 700 begins by determining whether a calendar event has been received (block 702 A calendar event can be created by a user via the calendar. 124 the user application 120 the first, second or third mobile device 106 , 108 , 110 created and attached to the first processor 104 of the vehicle 102 via the communicator 132 the user application 120 out of Fig. 1– Fig. 5. The user creates the calendar event via the first, second, third, and fourth example screens. 200 , 300 , 400 , 500 out of Fig. 2– Fig. 5, by entering data, for example, into the event time fields 204 and the local field 206 The recipient of the request can determine whether a calendar event has been received. 600 the scheduler 134 out of Fig. 1 and Fig. 6 will be carried out.

[0085] If a calendar event has been received, the exemplary procedure includes 700 Determining whether the calendar event constitutes a requirement for the use of an autonomous vehicle (e.g., the vehicle) 102 ) in connection with the event includes (block 704 A user can control the vehicle via the GUI. 122 one of the mobile devices106 , 108 , 110 , such as the vehicle requirements field 208 of the first exemplary screen 200 out of Fig. 2. Request. The recipient of the request 600 out of Fig. 6 can determine whether the calendar event includes a request for the use of a vehicle. The data received from the calendar event (e.g., location) can be stored in the database. 602 be saved.

[0086] If the calendar event does not include a requirement for the vehicle, the exemplary procedure includes 700 Determining whether the location assigned to the vehicle request is a location to which the vehicle has previously traveled (Block 706 The journey planner 608 the scheduler 134 For example, it can contain data that is stored in the database. 602Stored data is searched for previous vehicle requests to determine if the vehicle has driven to the location of the calendar event.

[0087] If it is determined that the vehicle has previously visited the location, but the calendar event does not involve a requirement for the vehicle, the exemplary procedure includes 700 the automatic sending of a vehicle request to the user application of the mobile device where the calendar event was created (block 708 In some examples, the request acknowledgment facility sends 606 a request to the user application 120 , which instructs the user application to automatically enter the vehicle request field 208 of the first exemplary screen 200 out of Fig. 2. Select based on the determination that the vehicle was previously used to reach the location of the calendar event. In other examples, the user application shows 120 A pop-up window appears, asking the user if they would like to request the vehicle for the event.

[0088] The exemplary procedure 700 includes a determination of whether the user has confirmed that the vehicle should be requested for the calendar event via the user application (block 710 The user can, for example, request a vehicle for the calendar event via the user application. 120 confirm by clicking the confirmation button 222 of the first exemplary screen 200 is selected, whereby the vehicle requirement field 208 is selected. If the user does not confirm the request (e.g., the user deactivates the vehicle request field). 208), determines the exemplary procedure 700 , that the user does not want to request a vehicle for the calendar event, and the exemplary procedure 700 ends, with monitoring for the receipt of calendar events and / or vehicle requests continuing (Block 724 ).

[0089] If the user confirms that the vehicle should be requested for the calendar event, or if the calendar event includes a vehicle request input from the user at the time the calendar event is created (e.g., block). 704 ), follows the exemplary procedure 700 continuing with the receipt of the user's pickup position at the location (block) 712 ). The user of the user application 120 For example, selects a pick-up location at the vehicle request location via the location selection device. 126 the user application 120 out, which is a card 402and the position selection device 404 of the second example screen 300 out of Fig. It can include 3.

[0090] The exemplary procedure 700 This includes determining the vehicle's arrival time at the location based on calendar event data, such as the vehicle request location, the requested arrival time (e.g., start time, end time, and / or arrival buffer time), and / or other user input, such as vehicle settings associated with the vehicle request (block 714 The journey planner 608 For example, it determines a route for the vehicle to reach the location based on calendar event data and a current or expected location of the vehicle (e.g., based on location data from the vehicle position sensor). 610 The journey planner 608 The journey planner estimates travel time based on the route. 608determines the arrival time based on the event time, travel time, arrival buffer time as requested by the user, and / or any additional time required to implement the vehicle settings (e.g., to heat the vehicle as requested by the user).

[0091] The exemplary procedure 700 includes transmitting the arrival time to the user application (block 716 The Request Confirmation Facility 606 For example, it transmits the arrival time to the user application. 120 to display via the vehicle arrival time field 212 The exemplary procedure 700 includes a determination of whether the user has confirmed or accepted the vehicle's arrival time (Block 718 The user can, for example, confirm the vehicle's arrival time using the confirmation buttons. 222 , 310of the first and second example screens 200 , 300 out of Fig. 2 and Fig. 3. Accept to save the calendar event with the vehicle request at the arrival time. If the user does not accept the arrival time, the exemplary procedure determines 700 , that the user no longer wishes to request the vehicle due and the exemplary procedure 700 ends, with continued monitoring of the calendar ending (block 724 ).

[0092] If the user confirms the vehicle's arrival time, the exemplary procedure includes 700 Adding the vehicle request to a calendar for the vehicle (block 720 The vehicle request can, for example, be linked to the vehicle calendar. 603 the scheduler 134Data regarding arrival time, location, route, user requirements, etc., are added to the vehicle request. The exemplary procedure 700 This includes directing the vehicle to fulfill the requirement at the scheduled time (Block 722 ). The vehicle control system 614 the scheduler 134 For example, it can send one or more instructions or commands to the vehicle to guide it to arrive at the location at the planned time. The exemplary procedure 700 ends with the continued monitoring of calendar events, for example via the user application. 120 created and through the scheduler 134 of the vehicle (block 724 ).

[0093] The exemplary procedure 700The procedure also includes the prediction of vehicle requirements. If a calendar event, as disclosed above, does not involve a vehicle requirement, the exemplary procedure includes... 700 Determining whether a request should be generated based on whether the vehicle previously traveled to a location associated with the calendar event (e.g., blocks). 704 – 710 The exemplary procedure 700 It can also be used as part of a predictive analysis of vehicle usage data to determine whether a vehicle request should be generated if no calendar event has been received.

[0094] If, for example, the vehicle's scheduler has not received a calendar event (e.g., in the case of a block) 702 ), includes the exemplary procedure 700Analyzing past vehicle usage data to determine whether the vehicle is likely to be used for a future, but not yet scheduled, calendar event (Block 726 As revealed above, the tracking device analyzes previous journeys. 616 the scheduler 134 Data on previous vehicle requests to identify patterns in vehicle usage. The tracking device for previous trips. 616 For example, it determines that the user schedules a calendar event at a specific location once a month and requests a vehicle in connection with the calendar event.

[0095] Based on the analysis of previous usage data, the exemplary procedure includes 700 Predicting whether or not an upcoming calendar event exists (Block 728 If the tracking device for previous journeys616 For example, if one or more patterns are identified relating to user-created calendar events for a location, the prediction feature can 618 the scheduler 134 Predict that the user will create a new calendar event for the location and request the vehicle in connection with that calendar event. If a future calendar event is predicted, the exemplary procedure includes... 700 Sending a vehicle request to the user application (block 708 In some examples, the vehicle request prompt is a request to automatically generate a future calendar event via the user application, which includes the vehicle request based on the prediction of that future calendar event. The exemplary procedure 700continues with determining whether the user confirms the predictively generated vehicle request (Block 710 ).

[0096] Predicting future calendar events and vehicle requirements is possible because the vehicle's scheduler receives, processes, and stores calendar event and vehicle requirement data. For example, if it is determined that a calendar event does not involve a vehicle requirement and that the calendar event is not associated with a location the vehicle previously visited (e.g., blocks), the system can predict future calendar events and vehicle requirements. 704 , 706 ), determines the exemplary procedure 700 that the user does not want to request a vehicle for the calendar event. In such examples, the exemplary procedure can be used. 700 continue with the analysis of previous vehicle usage data (Block 726), to predict whether other future calendar events exist for which the user can request the vehicle, and to provide prompts for the automatic generation of such requests. Thus, the exemplary procedure looks like this: 700 It offers intelligent, efficient scheduling of vehicle requirements, which can minimize the need for user input of calendar events via predictive analysis.

[0097] The exemplary procedure 700 out of Fig. Section 7 provides for the scheduling of vehicle use via a vehicle request submitted through a user application (e.g., the user application). 120 out of Fig. 1– Fig. 5) created and managed by a scheduling manager (e.g., the scheduler) 134 out of Fig. 1 and Fig. 6) is processed. In some examples, two or more components access the user application to process calendar events via respective user devices, such as mobile devices. 106 , 108 , 110 Multiple requests for the vehicle, in conjunction with calendar events created by each user, can lead to scheduling conflicts regarding vehicle availability.

[0098] Fig. Figure 8 illustrates a flowchart of an example procedure. 800 , which can be implemented to address conflicts in vehicle scheduling. The exemplary procedure 800 can be done using the scheduler 134 of the vehicle 102 and the user application 120 the respective mobile device 106 , 108 , 110 out of Fig. 1– Fig. 6 must be implemented.

[0099] The exemplary procedure 800 includes receiving a calendar event that contains a request for the vehicle (block 802 The calendar event can be managed through the scheduler. 134 of the vehicle 102 be received, as essentially above in conjunction with Fig. 1– Fig. 7 is disclosed. After receiving the calendar event with the new vehicle requirement, the exemplary procedure includes 800 Determining whether one or more requirements for the vehicle were planned in advance (Block 804 The conflict analyzer 604 the scheduler 134 can, for example, be based on data from the vehicle calendar 603 The stored data determines whether other previously scheduled vehicle requirements exist. If no previously scheduled events exist, the exemplary procedure includes... 800the scheduling of the new vehicle requirement, as essentially described above in conjunction with Fig. 1– Fig. 7 is revealed (Block 822 ).

[0100] If one or more events are planned in advance, the exemplary procedure includes 800 Analyzing the new vehicle requirement in relation to the previously planned vehicle requirements (Block 806 Based on the calendar event data associated with the new vehicle request, the trip planner can 608 For example, determining a route to reach the location of the calendar event and estimating an arrival time. The conflict analyzer 604 The conflict analyzer can compare the arrival time for the new vehicle request with arrival times calculated for a previously scheduled vehicle request. 604can analyze data such as location, start and end time, arrival buffer times, priority rules assigned to calendar events associated with vehicle requirements, etc., which are associated with the new vehicle requirement and the previously scheduled vehicle requirements, to determine if there are conflicts between the new vehicle requirements.

[0101] The exemplary procedure 800 includes a determination of whether one or more conflicts exist between the new vehicle request and the previously scheduled vehicle request(s) that would prevent the vehicle from completing each request (block 808 The conflict analyzer 604For example, it can determine that the vehicle will not be able to arrive at the scheduled arrival time for a previously planned vehicle request if the vehicle fulfills the new vehicle request before the previously planned one. In such examples, the conflict analyzer identifies 604 a conflict between the requirements. If no conflicts between the vehicle requirements were identified, the exemplary procedure includes 800 the scheduling of the new vehicle requirement, as essentially described above in conjunction with Fig. 1– Fig. 7 is revealed (Block 822 ).

[0102] If one or more conflicts between the vehicle requirements have been identified, the exemplary procedure includes 800 Evaluating one or more rules or options to resolve the conflict(s). The exemplary procedure. 800This includes evaluating priority rules assigned to one or more of the calendar events associated with the vehicle requirements (block 810 The calendar event associated with the new vehicle request can, for example, be assigned a high priority level by the user who accessed the calendar event via the user application. 120 created. The conflict analyzer 604 determines a way to reschedule vehicle requirements based on the priority rules assigned to the requirement(s).

[0103] The exemplary procedure 800 This includes adjusting the arrival times of the new vehicle requirement and the requirement(s) that conflict with the new vehicle requirement(s) (Block 812 The conflict analyzer 604 , the journey planner 608 , the vehicle position sensor 610For example, they can determine whether the vehicle is available to fulfill the new vehicle request and / or the previously planned requirements at times other than those requested. The trip planner 608 can determine adjusted arrival times of the vehicle at the locations assigned to the requirements, based on the alternative availability of the vehicle.

[0104] The exemplary procedure 800 also includes a carpooling suggestion (block 814 In some examples, the ride-sharing analyzer identifies 612 one or more common properties or overlaps between the locations, the routes to the locations, the start and end times of the conflicting calendar events, etc. In such examples, the ride-sharing analyzer determines 612A common route for the locations, ensuring the vehicle meets the requirements during a multi-stage trip. The ride-sharing analyzer 612 can develop a carpooling proposal based on the determination that the requirements can be summarized.

[0105] With regard to identifying the conflict(s) between vehicle requirements and evaluating priority rules, adjusting arrival times and determining a carpooling proposal, the exemplary procedure proceeds 800 proceeding with sending a conflict resolution request to the user application (Block 816 In some examples, the request acknowledgment facility sends 606 a request to the user application 120The user(s) who created the conflicting requests will receive a warning message regarding the scheduling conflict between the requests. The request acknowledgment facility 606 The user application can also send adjusted arrival times or carpooling suggestions. 120 to display via the vehicle arrival time field 212 and / or the carpooling details field 304 of the first and second example screens 200 , 300 out of Fig. 2 and Fig. 3. Send. In some examples, the request acknowledgment facility sends. 606 The warning message to adjust arrival times or to suggest a ride-sharing opportunity is based on the identification of priority rules that are assigned to calendar events for vehicle requirements.

[0106] The user application associated with the user devices used to generate the vehicle request displays the conflict resolution prompt(s) to warn the user(s) about conflicts between vehicle requests, changes to vehicle arrival times, ride-sharing options, etc. In response, users can provide input to the user application to accept or reject the conflict resolution prompt. For example, a user can reject a change to the vehicle arrival time by canceling the calendar event using the cancel button. 224 of the first exemplary screen 200 out of Fig. 2 rejects.

[0107] The exemplary procedure 800 This includes determining whether the user(s) has / have accepted the proposed changes to the vehicle requirement(s). The exemplary procedure 800includes a determination of whether two or more of the calendar events associated with the conflicting vehicle requirements have become ride-sharing events (Block 818 If the events have become carpooling events, the exemplary procedure plans 800 The vehicle requirements (block) are time-bound 822 The rideshare analyzer 612 For example, the requirements in the vehicle calendar can be 603 Store as a single, aggregated request or event with the shared route information.

[0108] If the calendar events associated with the conflicting vehicle requirements do not become ride-sharing events, the exemplary procedure includes 800 a determination as to whether one or more of the calendar events and / or vehicle requirements have been rescheduled (Block 820For example, if the user who created the new vehicle requirements accepts the adjusted arrival times for the vehicle, the exemplary procedure proceeds 800 continue with the scheduling of the new vehicle request to the adjusted arrival time (Block 822 As another example, the user can reschedule the calendar event for a different time or day. In such cases, the vehicle request can be rescheduled based on the modified calendar event data.

[0109] If one or more of the conflicting vehicle requirements are not rescheduled or combined into a single ride-sharing event, the exemplary procedure includes 800 rejecting one or more of the vehicle requirements (block 824The new vehicle request may, for example, conflict with a previously scheduled event that has been assigned a high priority, indicating that the event cannot be rescheduled. If the user assigned to the new vehicle request does not agree to reschedule the request, the new vehicle request will be rejected. The request confirmation facility 606 can send a warning message to the user application 120 send, whereby the user application 120 is instructed to automatically enter the vehicle arrival time field. 212 of the first exemplary screen 200 to be completed with a message indicating that the vehicle is unavailable. The exemplary procedure 800ends with monitoring for calendar events with new vehicle requirements and / or modifications to the calendar event data and / or vehicle requirements in order to dynamically identify and respond to scheduling conflicts (Block 826 ).

[0110] The flowcharts from Fig. 7– Fig. 8 represent exemplary procedures that can be used to implement the exemplary system 100 out of Fig. 1– Fig. 6. In these examples, the procedures can be implemented using machine-readable instructions that describe a program for execution by a processor, such as the processor. 912 , include, which is in the exemplary processor platform 900 is shown below in connection with Fig. 9 is discussed. The program can be executed in software stored on a tangible, computer-readable storage medium, such as a CD-ROM, a floppy disk, a hard disk, a Digital Versatile Disc (DVD), a Blu-ray Disc, or memory accessible to the processor. 912 The entire program and / or parts thereof are assigned to the processor; however, they can alternatively be executed by a device other than the processor. 912 is, and / or be executed in firmware or dedicated hardware. Although the example program with respect to the in Fig. 7– Fig. As described in the 8 illustrated flowcharts, many other methods for implementing the exemplary system can also be used as alternatives. 100 can be used. For example, the order in which the blocks are executed can be changed and / or some of the described blocks can be modified, removed or combined.

[0111] As mentioned above, the exemplary processes can be derived from Fig. 7– Fig. 8. are implemented using coded instructions (e.g., computer-readable and / or machine-readable instructions) stored on a tangible, computer-readable storage medium, such as a hard disk drive, flash memory, read-only memory (ROM), compact disc (CD), digital versatile disc (DVD), buffer memory, random-access memory (RAM), and / or any other storage device or disk on which information is stored for any duration (e.g., for extended periods, permanently, for short periods, for temporary buffering, and / or for intermediate storage of information). As used herein, the term tangible, computer-readable storage medium is expressly defined to include any type of computer-readable storage device and / or disk and excludes the propagation of signals and transmission media.As used herein, “tangible computer-readable storage medium” and “tangible machine-readable storage medium” are used synonymously. Additionally or alternatively, the exemplary processes from [reference to be added] may be used. Fig. 7– Fig. 8. are implemented using coded instructions (e.g., computer- and / or machine-readable instructions) stored on a non-volatile computer- and / or machine-readable medium, such as a hard disk drive, flash memory, read-only memory, compact disk, digital versatile disk, buffer memory, random-access memory, and / or any other storage device or disk on which information is stored for any duration (e.g., for extended periods, permanently, for short periods, for temporary buffering, and / or for intermediate storage of information). As used herein, the term non-volatile computer-readable medium is expressly defined to include any type of computer-readable storage device and / or disk and excludes signal propagation and transmission media.As used herein, the term “at least / at least”, when used as a transitional term in the introduction of a patent claim, is open in the same way as the term “comprehensive”.

[0112] Fig. Figure 9 is a block diagram of an example processor platform 900 , which is capable of executing instructions to carry out the procedures from Fig. 7– Fig. 8 and the exemplary system 100 out of Fig. 1– Fig. 6 to implement. The processor platform 900 This could be, for example, a server, a personal computer, a mobile device (e.g., a mobile phone, a smartphone, a tablet, such as an iPad). TM ), a personal digital assistant (PDA), an internet application, or any other type of computing device.

[0113] The processor platform 900 The illustrated example includes a processor 912one. The processor 912 The illustrated example is hardware. For example, the processor 912 implemented by one or more integrated circuits, logic circuits, microprocessors or controllers from any desired family or manufacturer.

[0114] The processor 912 The illustrated example includes a local memory 913 (e.g., a cache). The processor 912 The illustrated example is above a bus 918 in communication with main memory, including volatile memory 914 and a non-volatile memory 916 The volatile memory 914This can be implemented by a read / write memory (Synchronous Dynamic Random Access Memory – SDRAM), a dynamic random access memory (DRAM), a RAMBUS dynamic random access memory (RDRAM), and / or any other type of random access memory device. The non-volatile memory 916 This can be implemented using flash memory and / or any other desired type of storage device. Access to main memory 914 , 916 is controlled by a memory controller.

[0115] The processor platform 900 The illustrated example also includes an interface circuit. 920 one. The interface circuit 920can be implemented using any type of interface standard, such as an Ethernet interface, a Universal Serial Bus (USB) and / or a PCI Express interface.

[0116] In the illustrated example, one or more input devices are used. 922 with the interface circuit 920 connected. The input device(s) 922 enables a user to send data and instructions to the processor. 912 to be entered. The input device(s) can be implemented, for example, by an audio sensor, a microphone, a camera (still image or video), a keyboard, a button, a mouse, a touchscreen, a trackpad, a trackball, Isopoint and / or a speech recognition system.

[0117] One or more output devices 924 are also connected to the interface circuit 920connected to the illustrated example. The output devices 924 These can be implemented, for example, by display devices (e.g., a light-emitting diode (LED), an organic light-emitting diode (OLED), a liquid crystal display, a cathode ray tube display (CRT), a touchscreen, a tactile output device, a printer, and / or a loudspeaker). The interface circuit 920 The illustrated example therefore typically includes a graphics driver card, a graphics driver chip, or a graphics driver processor.

[0118] The interface circuit 920 The illustrated example also includes a communication device, such as a transmitter, a receiver, a transceiver, a modem and / or a network interface card, to enable the exchange of data with external machines (e.g., computing devices of any kind) via a network. 926(e.g., an Ethernet connection, a Digital Subscriber Line (DSL), a telephone line, a coaxial cable, a mobile phone system, etc.) to simplify.

[0119] The processor platform 900 The illustrated example also includes one or more mass storage devices. 928 for storing software and / or data. Examples of such mass storage devices. 928 This includes floppy disk drives, hard disk drives, compact disk drives, Blu-ray disk drives, RAID systems and Digital Versatile Disk (DVD) drives.

[0120] Coded instructions 932 out of Fig. 9 can be stored in the mass storage device 928 , in the volatile memory 914 , in the non-volatile memory 916 and / or be stored on a removable, tangible, computer-readable storage medium, such as a CD or DVD.

[0121] The foregoing will make it clear that the systems, methods, and devices disclosed above provide for the efficient scheduling of calendar events and requests for the use of an autonomous vehicle in conjunction with those calendar events, using a single user application installed on the user's device, such as a smartphone. The disclosed examples eliminate the need for the user to access different applications or interfaces for scheduling calendar events and requesting the vehicle. Instead, the disclosed examples provide for the integration of vehicle requests with familiar calendar-based user applications.The revealed examples also predict future calendar events and vehicle requirements based on previous data analyses and automatically schedule the events via the user application to provide efficient and intelligent calendar management.

[0122] The disclosed examples also manage scheduling requests made to the vehicle by users requesting it for various calendar events. Vehicle requests generated at the respective user devices are transmitted to a central scheduler associated with the vehicle. The scheduler evaluates the requests and the associated calendar event data, identifies conflicts, determines options for rescheduling, and provides feedback to users via the user application regarding the vehicle's availability in response to the requests. The scheduler automatically calculates travel times and determines arrival times for the vehicle based on factors such as location, route, arrival buffer times, user requests, and so on.Furthermore, the disclosed examples promote efficient vehicle use by identifying opportunities for ride-sharing between users.

[0123] Although certain exemplary processes, devices, and products are disclosed in the present document, the scope of this patent is not limited to these. On the contrary, this patent covers all processes, devices, and products that fall within the scope of the claims of this patent.

Claims

[1] Procedure, encompassing: Receiving an initial request for a vehicle to travel to a location at a first processor, wherein the initial request to the first processor is to be transferred by a second processor; Calculating the vehicle's arrival time based on the first request; Comparing the first requirement with a second requirement for the vehicle based on the arrival time; Scheduling the first requirement based on the comparison; and Guiding the vehicle to the location based on the time schedule. [2] Method according to claim 1, further comprising: determining a route of the vehicle to the location and calculating the arrival time based on the route. [3] Method according to claim 2, wherein the calculation of the arrival time is further based on an arrival buffer time, wherein the arrival buffer time is to be transferred from the second processor to the first processor. [4] Method according to claim 1, further comprising: Determining an initial route for the vehicle to the location; Determine an overlap between the first route and a second route of the vehicle that is assigned to the second request; and Summarize the first requirement and the second requirement based on the overlap. [5] Method according to claim 1 or 2, further comprising: Identifying a conflict between the first requirement and the second requirement; and Adjusting the vehicle's arrival time for the first request or a vehicle's arrival time for the second request based on the conflict. [6] Method according to claim 1 or 2, further comprising: identifying a map of the location and transferring the map from the first processor to the second processor, wherein the map is displayed via an interface assigned to the first processor. [7] Method according to claim 1, wherein the first requirement includes a vehicle setting and further comprising: determining the arrival time based on a time to implement the vehicle setting. [8] Procedures, comprehensive: Receiving initial calendar event data via a first processor, wherein the calendar event data is to be transferred to the first processor by a second processor; Determine whether the first calendar event data includes a request for a vehicle; Analyze the first calendar event data and the second calendar event data if the first calendar data does not include the request; Generating a predicted requirement for the vehicle based on the analysis, whereby the predicted requirement is to be mapped to the first calendar event data; and Scheduling the predicted requirement. [9] Method according to claim 8, further comprising: identifying whether the first calendar event data includes a route or location associated with the second calendar event data and generating the predicted request based on the identification. [10] Method according to claim 8 or 9, further comprising: predictions of third calendar event dates based on either the first calendar event dates or the second calendar event dates or both. [11] Method according to claim 8, further comprising: Predictions of an arrival buffer time for the predicted demand based on the first calendar event data and the second calendar event data; and Calculating an arrival time for the vehicle based on the first calendar event data and the predicted arrival buffer time. [12] Method according to claim 8, further comprising: Transmitting the predicted request to the second processor for display via an interface assigned to the second processor; and Scheduling the predicted requirement based on user input received via the interface. [13] Device comprising: a request receiver to receive a first request for a vehicle to travel to a first location from a first processor and a second request for the vehicle to travel to a second location from a second processor; and an analyzer for: Determining a first arrival time of the vehicle at the first location based on the first requirement and a second arrival time of the vehicle at the second location based on the second requirement; Performing a comparison of the first arrival time and the second arrival time; Identifying one or more rules that are assigned to the first requirement or the second requirement; and scheduling of at least one of the first requirement or the second requirement based on the comparison and identification of one or more rules, wherein at least one of the request receiver or analyzer is implemented via a third processor. [14] Device according to claim 13, wherein the one or more rules are a respective priority level which is assigned to the first requirement or the second requirement. [15] Device according to claim 13, which further includes a prediction device for predicting a third requirement for the vehicle based on the first requirement and the second requirement.