Classifications

• • G—PHYSICS
  • G01—MEASURING; TESTING
  • G01C—MEASURING DISTANCES, LEVELS OR BEARINGS; SURVEYING; NAVIGATION; GYROSCOPIC INSTRUMENTS; PHOTOGRAMMETRY OR VIDEOGRAMMETRY
  • G01C21/00—Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00
  • G01C21/26—Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00 specially adapted for navigation in a road network
  • G01C21/34—Route searching; Route guidance
  • G01C21/3407—Route searching; Route guidance specially adapted for specific applications
  • G01C21/343—Calculating itineraries
• • G—PHYSICS
  • G01—MEASURING; TESTING
  • G01C—MEASURING DISTANCES, LEVELS OR BEARINGS; SURVEYING; NAVIGATION; GYROSCOPIC INSTRUMENTS; PHOTOGRAMMETRY OR VIDEOGRAMMETRY
  • G01C21/00—Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00
  • G01C21/26—Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00 specially adapted for navigation in a road network
  • G01C21/34—Route searching; Route guidance
  • G01C21/36—Input/output arrangements for on-board computers
  • G01C21/3605—Destination input or retrieval
  • G01C21/362—Destination input or retrieval received from an external device or application, e.g. PDA, mobile phone or calendar application
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q10/00—Administration; Management
  • G06Q10/04—Forecasting or optimisation specially adapted for administrative or management purposes, e.g. linear programming or "cutting stock problem"
  • G06Q10/047—Optimisation of routes or paths, e.g. travelling salesman problem

Definitions

• This invention relates to including trip plan data in an electronic calendar, in particular, but not exclusively, so that alerts regarding the trip may be provided to a user's mobile device.
• the trip plan data generated by a trip planning system may include a walking leg from a start location to an initial public transport station or stop (stations and stops hereinafter collectively called "stations").
• the trip plan data may also include one or more transit legs via public transport to a final public transport station, and a further walking leg from the final public transport station to the target destination.
• the journey may involve the use of more than one transport route, for example different train lines, bus routes or ferries and may involve one or more transfers from one vehicle to another, which may involve walking to accomplish a transfer.
• An example of a trip planning service is Google Transit, available online at
• At least part of a generated trip plan is included in one or more calendar entries stored in a user's electronic calendar.
• one or more calendar entries are created, each calendar entry including one or more steps of the trip plan.
• Time data for said one or more of the calendar entries corresponds to time data associated with one or more steps of the trip plan.
• the calendar provides one or more alerts to remind the user when a step of the trip plan should be carried out.
• one or more of the calendar entries created for said trip plan are updated responsive to "real time" transit information received from one or more transit information systems.
• Figure l is a schematic block diagram of system configured in accordance with an exemplary implementation
• Figure 2 is a flow diagram illustrating a computer- implemented method in accordance with an exemplary implementation
• Figure 3 illustrates an exemplary content page displayed by a user client during a communication session.
• Systems according to embodiments of the present invention are operable to generate one or more public transportation trip plans in response to a user request, and to include generated trip plan data in the user's electronic calendar.
• the calendar may be stored online and synchronised with the user's mobile device, so as to provide the user with offline access to the stored trip plan.
• the user may be provided with alerts regarding the trip via the calendar system. For example, an alert may be provided to remind the user 3 minutes before it is time to leave the start location and/or 3 minutes before the user should get off a train or other public transport mode.
• one or more alerts including trip information may be provided to the user during the trip.
• the user may be provided with an alert including information on a train to take and the platform to go to when the user arrives at a station.
• Systems according to embodiments of the present invention receive real-time transit information relating to the expected arrival/ departure times of trains, buses or other public transport from one or more transit information systems of one or more transit providers. If the received information indicates that details of a trip plan stored in a user's calendar have changed, the stored trip plan is updated. For example, if a train is delayed, the system automatically updates the user's calendar. If the delay has consequences for a trip (e.g: if the user would miss a transfer), the system may automatically update the user's calendar with a new trip plan.
• Figure l is a schematic block diagram of a system configured in accordance with an embodiment of the present invention.
• the system includes a client 1, which
• the trip planning system 2 includes a trip planning module 4 configured to receive a user request and in response to generate a number of different trip plan suggestions, each of which include instructions to reach a user-selected target destination.
• the trip planning system 2 includes a trip diarising module 5, which is configured to interact with a calendar system 6 to include a user-selected trip plan in the user's electronic calendar 7.
• the trip planning system 2 receives real-time transit information data 8 provided by one or more transit information systems (not shown) of one or more public transport providers.
• the trip planning system 2 has a calendar update module 9, which identifies from received transit information whether a trip plan stored in a user's calendar should be updated, and causes the stored trip plan to be updated if necessary.
• Figure 1 for simplicity illustrates operation of the system in relation to a single user client, the skilled reader will appreciate that many other clients 1 may also be in communication with the trip planning system 2 via the network 3.
• the system of Figure 1 can cater for requests from many different users, who may request trip planning queries and may choose to add the query results to their respective electronic calendars stored in calendar system 6 as described herein.
• Each client l may be any type of device which is configured for computing, such as a smartphone or other mobile communications device, a personal computer, laptop, a PDA, a navigation system located in a vehicle, a handheld GPS system, and so on.
• the client l includes a browser (or other similar application) that allows the user to interface and communicate with the trip planning system 2 and calendar system 6 via one or more web serving systems (not shown).
• Web serving systems and the interaction between web serving system and browser is well known per se to those skilled in the art and will not be described in detail here.
• a web serving system delivers content such as HTML (hypertext markup language), images, scripting language (e.g: JavaScript, Jscript, Visual Basic Script) and other elements that can be used by the browser on the client l.
• a web serving system may include one or more severs operating under a load balancing scheme, with each server (or
• the network 3 may comprise any suitable network such as the Internet or other WAN, a wireless telecommunications network or LAN, which may be wired or wireless, or a local area network (e.g: intranet), or a combination of networks.
• the components of the overall system of Figure 1 e.g: trip planning system 2 and calendar system 6) may each comprise a single server or a plurality of servers which operate together. As shown, the systems 2, 6 include a number of processing modules. It will be appreciated that the term "module” refers to computer logic utilised to provide specified functionality. Thus, a module can be implemented in hardware, firmware and/or software controlling a processor.
• the modules are program files stored on a storage device, loaded into memory and executed by a processor, or can be provided from computer program products, for example computer executable instructions, that are stored in a tangible computer-readable storage medium such as RAM, hard disk, or optical or magnetic media.
• a tangible computer-readable storage medium such as RAM, hard disk, or optical or magnetic media.
• FIG. 2 illustrates process steps in an exemplary interaction involving the client 1, the trip planning system 2 and the calendar system 6.
• trip planning module 4 generates 210 one or more trip plans for one or more trips to a target destination.
• Trip diarising module 5 causes a generated trip plan to be transmitted to the calendar system 6 and to be included 220 in an electronic calendar of calendar system 6.
• Trip planning system 2 receives 230 transit information from the transit information system 8, which is monitored by the calendar update module 9 to determine whether a trip plan which has been stored in a user's calendar should be updated. If the information received from the transit information system indicates that details of a previously stored trip plan should be changed, the calendar update module causes the trip plan to be updated accordingly. That is, the calendar update module causes a trip plan included in the electronic calendar to be updated responsive to the received
• the calendar system 6 of Figure 1 comprises a time-management web application, e.g: Google Calendar or other online calendar system.
• a time-management web application e.g: Google Calendar or other online calendar system.
• the calendar system 6 stores calendar data in the form of calendar events, each event including time data for the event (e.g: start time/date, end time/date) and description data for the event.
• the description data may include the name of the event and a location for the event.
• some calendar events may also include an image for the event, e.g: a photograph or map showing a location for the event and/ or other content.
• the system 6 may be configured to synchronise a user's electronic calendar with a local calendar application running locally on the client 1 and/or other device(s) of the user, using synchronisation techniques which are well known to those skilled in the art.
• the calendar system 6 and/or the local calendar may be configured to provide alerts in the form of reminders to the user by email, SMS, or to cause alerts to appear on the display of a device of the user, e.g: via push notifications. Alerts may be provided in advance of or at the time of calendar events stored in the electronic calendar, and may include some or all of the data stored for the calendar event.
• the calendar system may comprise an online calendar system which synchronises with a local calendar as described above, in alternative embodiments the calendar system may comprise a calendar application running locally on the client 1, or on another device of the user. It will be appreciated that the calendar system 6 may comprise a proprietary electronic calendar such as Mozilla Sunbird, Windows Live Calendar, Google Calendar or Microsoft Outlook, or alternatively may comprise one or more bespoke modules configured for time/date functionality.
• the trip planning module 4 of trip planning system 2 generates one or more trip plans in response to a user query, each trip plan comprising step-by-step instructions for a route from a start location to a target destination by way of public transportation.
• the user query specifies the target destination and also a time/date that the user wishes to arrive or leave.
• the start location for the trip plan may also be specified by the user, or may alternatively be obtained based on location information for the user provided by GPS and/or other location detection schemes.
• the instructions generated by the trip planning module 4 comprise navigation directions from the start location to the target destination and may be referred to as "transit directions".
• the trip planning module 4 causes the generated transit directions to be displayed to the user at the client 1.
• the trip planning module 4 may be implemented using known technology.
• the trip planning module 4 may include modules as described in US patent application publication no.: US2011/0112759, filed 1 April 2010 with title "Transit Routing System for Public Transportation Trip Planning".
• the trip planning module 4 may generate a number of different trip plan suggestions in response to a particular user query, for example using techniques described in US2011/0112759.
• Each trip plan generated by the trip planning module 4 may comprise one or more trip legs, each leg comprising one or more steps.
• a trip plan may include a walking leg from a start location to an initial public transport station, a transit leg from the initial public transport station to a final public transport station, and a further walking leg from the final public transport station to the target destination.
• the transit leg may include one or more transit stages, each transit stage including a number of transit direction steps.
• the transit direction steps may include a step of boarding a train (or other transport mode) at a boarding time, and a step of getting off the train (or other transport mode) at an arrival time.
• the transit leg may further comprise one or more transfer steps from one transit stage to another, which may involve walking to accomplish the transfer.
• the transit leg also includes further information relating to the user's journey via public transportation.
• the transit leg may include information relating to the stops that the user will pass, the number of stops, and/or information about the vehicle or vehicles involved with the transit leg (e.g: wi-fi, food, coffee, smoking/non-smoking, first class, relevant URLs).
• the walking leg from the start location to the initial public transport station comprises a time to start the journey, and, optionally, directions steps to the station.
• the walking leg from the final public transport station to the target destination may include an arrival time, and a number of directions steps.
• the trip diarising module 5 of trip planning system 2 is configured to cause data generated by the trip planning module 4 to be sent from the trip planning system 2 to the calendar system 6 and to be included in the user's electronic calendar.
• the calendar update module 9 receives data feeds 8 provided by one or more transit providers, e.g: for example relating to live expected departure times for trains, buses or other public transportation. Such "real time" data feeds are well known per se to those skilled in the art, and are currently available from a number of different public transport providers.
• the calendar update module 9 monitors the incoming real-time data and determines whether trip data which has been included in a user's calendar needs to be updated, e.g: in view of delays and other changes to expected
• the calendar update module 9 may instruct the trip planning module 4 to generate a completely new trip plan to replace the trip plan stored in the user's calendar.
• the calendar update module 9 then updates the user's calendar accordingly.
• the trip planning system 2 may include a local trip plan database 10 to store a record of active trip plans which are included in one or more electronic calendars of one or more users.
• the calendar update module 9 may compare incoming real-time data with the active trip plans stored in the local trip plan database 10 to determine when an update to a diarised trip plan is required. If an update is required, the calendar update module 9 causes the relevant calendar to be updated accordingly.
• the trip planning system 2 is configured so that users may opt out of data collection in the trip plan database 10 if they wish.
• Figure 3 illustrates an exemplary content page delivered by the trip planning system 2 and displayed by the client 1 during a communication session.
• the page includes a text field 310 in which the user can enter a start location and a text field 320 in which the user can enter a target destination.
• the page also provides a drop down box 330 and a field 340 whereby the user can select the time that they would like to leave the start destination or arrive at the target destination.
• a field (not shown) to enter a date may also be provided.
• the user fills out the text fields 310, 320 to request transit directions from Lucasstrasse 79, Zurich, Switzerland to Hafnerstrasse 9, Zurich, Switzerland.
• the user uses the drop down box 330 and the field 340 to indicate that they would like to leave at 21:43.
• the user query is sent from the client 1 to the trip planning system 2.
• the trip planning module 4 In response to the user query, the trip planning module 4 generates 210 three trip plan suggestions 350, 360, 370.
• the first trip plan suggestion 350 includes a walking leg from the start location to an initial public transport station, Zurich Bahnofstrasse/HB.
• the walking leg includes the step 352 "Walk to Zurich Vietnamesestrasse/HB" at a start time of 21:46.
• the trip plan 350 also includes a transit leg from the initial public transport station to a final public transport station, Zurich, Sihlquai/HB.
• the transit leg includes the step 354 of taking Tram 13 towards Zurich at 21:48. This step also includes information relating to the number of stops the user will pass during the tram journey. In some implementations, information relating to the names of the stops may also be provided.
• the trip plan 350 also includes a step 356 of getting off the Tram at 21:53.
• the other trip plan suggestions 360, 370 provide alternative options for travelling to the start location to the target destination via public transport, e.g: leaving at a different time and/or taking a different tram.
• the trip plans of Figure 3 are exemplary and that many variations are possible.
• the transit leg may include a plurality of transit stages, each comprising one or more steps. In some cases the transit leg may also include one or more transfer steps from one transit stage to another, as described above.
• the layout of the trip steps shown in Figure 3 gives a preview of the calendar events which will be added to the user's calendar for each trip plan.
• the trip plan 350 generated by the trip planning module 4 also includes a walking step to the target destination, although this is not displayed to the user in the example of Figure 3.
• time data generated for a step of a trip plan may also include date information for that step, and that in some cases, different steps could occur on different dates.
• the user is provided with the option to select one of the generated trip plan suggestions 350, 360, 370 for inclusion in his/her electronic calendar, by selecting the "add this trip to calendar" button 382, 384, 386 for the chosen trip plan.
• the selected trip plan is added to the user's calendar.
• the user may be asked to provide login details prior to generation of the trip plan suggestions 350, 360, 370, or alternatively, after selecting "add this trip to calendar".
• the calendar system 6 is configured to provide users with the option to either permit or prevent the trip planning system from adding data to the user's calendar.
• including a trip plan in a user's calendar comprises creating a plurality of calendar events in the user's calendar, each calendar event including one or more steps of the trip plan. For example, if the user opts to add the trip plan 350 in his calendar by selecting the appropriate button 380, the trip diarising module 5 causes three events to be created in the user's calendar corresponding to the walking step 352, the transit step 354 and the "get off now" step 356 respectively. Thus, the layout of the trip steps shown in Figure 3 gives a preview of the calendar events which will be added to the user's calendar.
• the first calendar event corresponding to the walking step 352 is created at the start time of the walking step 352, ie at 21:46.
• the second calendar event corresponding to transit step 352, is created at the time that the tram departs, ie: at 21:48.
• the third calendar event corresponding to the "get off now" step 356, is created at the time that the user should leave the train, ie: at 21:53. It will be appreciated that the time data for each calendar event may also include date data for the corresponding step.
• the trip diarising module 5 includes information relating to trip steps in corresponding calendar events. For example, walking directions on how to get to the initial public transport station may be included in the first calendar event (ie: in the event corresponding to the walking step).
• the trip diarising module 5 also includes information in the second calendar event (ie: the event corresponding to the transit step), for example the names of the stops that the user is going to pass, information on how many stops, and information about the vehicle the user is on (wi-fi, food, coffee, smoking, first class, relevant URLs).
• Walking directions on how to get to the final public transport station may be included in the third calendar event (ie: in the event corresponding to the "get off now" step 356.
• the trip diarising module may query the local trip plan database to determine whether other associated users (e.g: friends) have planned a trip which overlaps with the user's planned trip.
• the names of any such identified users may be included in the calendar events created for the corresponding trip steps.
• transit steps may include the names of friends who are on the same tram or train.
• the user's calendar may be synchronised with a local calendar application running locally on the client l and/or other device(s) of the user using synchronisation techniques which are well known to those skilled in the art.
• the calendar events created for the trip plan may be pushed to the user's device(s) and thus made available to the user offline.
• the trip diarising module 5 is configured to set up alerts for some or all of the calendar events created for the selected trip plan. For example, an alert may be set up for the first calendar event such that the user receives an alert three minutes before it is time to leave the start location. An alert may be set up for the third calendar event so that the user receives an alert 3 minutes before the user should get off the tram.
• the alerts may include data stored in the corresponding calendar event.
• the alert which reminds the user to leave the start location may include directions to the initial public transport station.
• the alert which reminds the user to get off the tram may include directions from the final public transport station to the target destination.
• the calendar system 6 may cause the alerts to be provided by email, SMS, or to appear on the display of a device of the user, e.g: by way of a calendar pop-up.
• a selector 390 may be provided to allow the user to select whether to receive the alerts by text message, calendar pop-up, or whether to opt out of alerts.
• the trip planning system may receive location data for the user's device from a location tracking service, and provide the user with alerts based on his or her location. In this way, for example, an alert may be provided when the user arrives at the initial public transport station.
• This alert may include data stored in the second calendar event (ie: data relating to the public transit leg of the trip).
• the alert may include information such as the tram or platform to find.
• calendar events may relate to a single step of a trip plan, or to more than one step of the trip plan.
• calendar events may be created for certain steps or legs of the trip plan according to predetermined rules for creating calendar events, stored for example at trip planning system 2. These rules may prescribe that calendar events are created for certain steps or legs, and optionally not for others, and that certain information is included in calendar events, e.g: in accordance with the examples described above. In some implementations, rules may prescribe that a calendar event is created for an initial walking step, for each of one or more transit steps, and for the "get off now" step.
• a single calendar event could be created for the transit leg, including all transit steps.
• rules may prescribe that a calendar event is created for a walking step from the final public transport station to the target destination, and that walking directions are included in this step.
• the stored rules for creating calendar events may also include rules for setting up alerts relating to the calendar events.
• the alerts may prescribe that an alert should be provided a predetermined time (e.g: 3 minutes) before the first leg of a trip plan starts and/or that an alert should be provided at a predetermined time (e.g: 3 minutes) before the user should get off a train, tram or other public transportation mode.
• rules for creating calendar events may be chosen such that helpful reminders are provided to the user at appropriate times before and during the planned trip.
• calendar update module 9 compares real-time transit information provided by transit providers with a record of diarised trip plans stored in local trip plan database 10 to determine if an update to a diarised trip plan is required. For example, if received transit information indicates that a train, tram or other public transport vehicle is delayed and that this delay affects a diarised trip plan, one or more of the corresponding calendar events for the trip plan may be updated to reflect the change. For example, in relation to the trip plan suggestion 350, if the calendar update module 9 receives transit information indicating that tram 13 scheduled to arrive at 21:48 has been delayed until 21:53, time data for the calendar event created for the corresponding transit step 352 is updated to reflect the new expected tram arrival time.
• the calendar update module 9 may be configured to determine if a delay has consequences for the trip (e.g: if the user would miss a transfer). In this case, the calendar update module 9 may cause the trip planning module 4 to generate a new trip plan to replace the trip plan stored in the user's calendar, and may cause the calendar update module 9 to update the user's calendar accordingly. If enabled by the user, the calendar update module 9 may receive location data for the user's device from a location tracking service (e.g: Google latitude) and may update the trip plan stored in a user's calendar based on the location information.
• a location tracking service e.g: Google latitude
• calendar update module 9 may cause the trip planning module to generate a new trip plan from the user's location and update the user's calendar accordingly.
• the trip planning system may include the entire results of a trip planning query to the user, with the option to add the trip to the calendar.
• the client may include an application (e.g: a mobile app) configured to communicate with the trip planning system via an application programming interface (API).
• an API may also be employed in web-based implementations as well as in app-based implementations.
• Figure 1 shows a client 1 in communication with a trip planning system 2
• the client may comprise a mobile device which includes an application configured to generate one or more trips plans for one or more trips to a target destination and/or to cause a generated trip plan to be included in the user's electronic calendar or on a local calendar running on the mobile device.
• the application may be configured to provide reminders to the user via push technology or alerts triggered by background processes.
• functions performed by a single system component may instead be performed by multiple components, and functions performed by multiple components may instead performed by a single component.
• Certain aspects of the present invention include process steps and instructions described herein in the form of an algorithm. It should be understood that the process steps, instructions, of the present invention as described and claimed, are executed by computer hardware operating under program control, and not mental steps performed by a human. Similarly, all of the types of data described and claimed are stored in a computer readable storage medium operated by a computer system, and are not simply disembodied abstract ideas.
• the present invention also relates to an apparatus for performing the operations herein.
• This apparatus may be specially constructed for the required purposes, or it may comprise a general-purpose computer selectively activated or reconfigured by a computer program stored on a computer readable medium that can be executed by the computer.
• a computer program are stored in a computer readable storage medium, such as, but is not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, application specific integrated circuits (ASICs), or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus.
• the computers referred to in the specification may include a single processor or may be architectures employing multiple processor designs for increased computing capability.
• the algorithms and operations presented herein can be executed by any type or brand computer or other apparatus.
• Various general-purpose systems may also be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method steps. The required structure for a variety of these systems will be apparent to those of skill in the art, along with equivalent variations.
• the present invention is not described with reference to any particular programming language. It is appreciated that a variety of programming languages may be used to implement the teachings of the present invention as described herein.

Landscapes

• Engineering & Computer Science (AREA)
• Remote Sensing (AREA)
• Radar, Positioning & Navigation (AREA)
• Business, Economics & Management (AREA)
• Human Resources & Organizations (AREA)
• General Physics & Mathematics (AREA)
• Physics & Mathematics (AREA)
• Automation & Control Theory (AREA)
• Economics (AREA)
• Strategic Management (AREA)
• Quality & Reliability (AREA)
• Tourism & Hospitality (AREA)
• Operations Research (AREA)
• General Business, Economics & Management (AREA)
• Marketing (AREA)
• Theoretical Computer Science (AREA)
• Entrepreneurship & Innovation (AREA)
• Game Theory and Decision Science (AREA)
• Development Economics (AREA)
• Navigation (AREA)
• Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Priority Applications (1)

Applications Claiming Priority (1)

Publications (1)

Family

ID=49948354

Family Applications (1)

Country Status (1)

Cited By (4)

Citations (4)

• 2012
  • 2012-07-19 WO PCT/IB2012/053696 patent/WO2014013295A1/fr not_active Ceased

Patent Citations (4)

Similar Documents

Legal Events