Route calculating method, route acquisition method or terminal for same

Abstract

According to one embodiment of the present invention, a method is disclosed for calculating the route of a journey (trip) identified by an origin and a destination using traffic information on a terminal, wherein the method comprises the steps of: receiving updated traffic information relating to a first route, while the terminal or a moving object on which the terminal is mounted is running on the first route; calculating a second route by using the updated traffic information; and transmitting, to a server, an entire route or a partial route of the calculated second route. Here, the calculated second route is compared with the first route, information about a partial route comprising one or more changed segment sequences is transmitted to the server, the segment sequence comprises one or more continuous segments, and the information relating to the partial route can comprise first segment information and final segment information about the segment sequence of the first route that will be substituted by respective segment sequences comprised in the partial route.

Claims

1. A method for calculating a route of a trip identified by an origin and a destination using traffic information received from a server at a terminal, the method comprising: receiving, by the terminal from the server, updated traffic information related to a first route uploaded on the server from a server while the terminal or a vehicle having the terminal mounted therein moves on the first route; calculating, by the terminal, a second route using the updated traffic information; deriving, by the terminal, a partial route information of the calculated second route by comparing the calculated second route with the first route; and transmitting, by the terminal, the partial route information of the calculated second route to the server, wherein the partial route information includes an indicator indicating that the information about the calculated second route relates to a partial route of the calculated second route, wherein the partial route is composed of one or more segment sequences which are changed with respect to the first route, wherein each of the one or more changed segment sequences is composed of one or more consecutive segments, wherein the partial route information includes first segment information and last segment information of each segment sequence of the first route to be replaced by the one or more changed segment sequences included in the partial route, wherein the first segment information indicates index information indicating a first segment of the segment sequence of the first route to be replaced by the one or more changed segment sequences included in the partial route, and wherein the last segment information indicates index information indicating a last segment of the segment sequence of the first route to be replaced by the one or more changed segment sequences included in the partial route.

2. The method according to claim 1, wherein the partial route information includes information about the one or more changed segment sequences.

3. The method according to claim 1, further comprising: receiving, from the server, a performance parameter of a whole route or the partial route of the calculated second route, wherein the performance parameter includes at least one of a speed, a delay, and a travel time for a segment of a road.

4. The method according to claim 1, further comprising: receiving, from the server, information indicating that the updated traffic information related to the first route is created.

5. The method according to claim 1, further comprising: recalculating the second route using the updated traffic information if a traffic flow of the calculated second route is worse than a traffic flow of the first route.

6. The method according to claim 5, further comprising: requesting traffic information for a specific area, in which a recalculation is repeated, if the recalculation is repeated a predetermined number of times (n).

7. A terminal configured to calculate a route of a trip identified by an origin and a destination using traffic information received from a server, the terminal comprising: a transceiver configured to communicate with the server; and a processor configured to calculate the route using the traffic information received from the server, wherein the processor is configured to: receive, from the server, updated traffic information related to a first route uploaded on the server while the terminal or a vehicle having the terminal mounted therein moves on the first route, calculate a second route using the updated traffic information, derive a partial route information of the calculated second route by comparing the calculated second route with the first route, and transmit the partial route information of the calculated second route to the server, wherein the partial route information includes an indicator indicating that the information about the calculated second route relates to a partial route of the calculated second route, wherein the partial route is composed of one or more segment sequences which are changed with respect to the first route, wherein each of the one or more changed segment sequences is composed of one or more consecutive segments, wherein the partial route information includes first segment information and last segment information of each segment sequence of the first route to be replaced by the changed segment sequences included in the partial route, wherein the first segment information indicates index information indicating a first segment of the segment sequence of the first route to be replaced by the one or more changed segment sequences included in the partial route, and wherein the last segment information indicates index information indicating a last segment of the segment sequence of the first route to be replaced by the one or more changed segment sequences included in the partial route.

8. The terminal according to claim 7, wherein the partial route information includes information about the one or more changed segment sequences.

9. The terminal according to claim 7, wherein the processor receives, from the server, a performance parameter of a whole route or the partial route of the calculated second route and the performance parameter includes at least one of a speed, a delay, and a travel time for a segment of a road.

10. The terminal according to claim 7, wherein the processor receives, from the server, information indicating that the updated traffic information related to the first route is created.

11. The terminal according to claim 7, wherein the processor recalculates the second route using the updated traffic information if a traffic flow of the calculated second route is worse than a traffic flow of the first route.

12. The terminal according to claim 11, wherein the processor requests traffic information for a specific area, in which a recalculation is repeated, if the recalculation is repeated a predetermined number of times (n).

Description

DESCRIPTION OF DRAWINGS

(1) The accompanying drawings, which are included to provide a further understanding of the invention and are incorporated in and constitute a part of this application, illustrate embodiment(s) of the invention and together with the description serve to explain the principle of the invention. In the drawings:

(2) FIG. 1 is a diagram showing classification of a navigation device.

(3) FIG. 2 is a flowchart showing operation of a lightweight ND in a conventional DynNav system.

(4) FIG. 3 is a flowchart showing operation of a smart ND in a conventional DynNav system.

(5) FIG. 4 is a diagram showing problems of the related art.

(6) FIG. 5 is a diagram showing a network configuration illustrating an IP based DynNav system which is a navigation system of the present invention.

(7) FIG. 6 is a diagram showing a hierarchical structure of a TPEG.

(8) FIG. 7 is a flowchart of operation according to one embodiment of the present invention.

(9) FIG. 8 is a diagram showing an example of the embodiment related to FIG. 7.

(10) FIG. 9 is a flowchart of operation according to one embodiment of the present invention.

(11) FIG. 10 is a diagram showing detailed operation according to one embodiment of the present invention.

(12) FIG. 11 is a block diagram showing a device in which the embodiments of the present invention may be implemented.

BEST MODE

(13) Reference will now be made in detail to the preferred embodiments of the present invention with reference to the accompanying drawings. The detailed description, which will be given below with reference to the accompanying drawings, is intended to explain exemplary embodiments of the present invention, rather than to show the only embodiments that can be implemented according to the invention. The following detailed description includes specific details in order to provide a thorough understanding of the present invention. However, it will be apparent to those skilled in the art that the present invention may be practiced without such specific details.

(14) In some instances, known structures and devices are omitted or are shown in block diagram form, focusing on important features of the structures and devices, so as not to obscure the concept of the invention. The same reference numbers will be used throughout this specification to refer to the same or like parts.

(15) Terms used herein will be defined as follows.

(16) Application

(17) An application is an implementation of a well-defined but not standardized set of functions that perform work on behalf of a user. The application may include software and/or hardware elements and associated user interfaces.

(18) Server

(19) In general, a server is an entity that provides resources to clients in response to requests in the technical field of the present invention.

(20) Client

(21) In general, a client is a device, user agent, or other entity that acts as a receiver of a service in the technical field of the present invention.

(22) DynNav Application

(23) A DynNav application is an entity that is in charge of interacting with a DynNav server to get optimal route(s), real-time and forecasted traffic information, and complementary data. Therefore, the DynNav application is loaded in a terminal such as a smartphone, a mobile phone, an ND, etc. Accordingly, the term DynNav application is interchangeably used with terminal. In this aspect, the DynNav application is a kind of client.

(24) DynNav Server

(25) A DynNav is an entity that is in charge of providing optimal route(s), real-time and forecasted traffic information, and complementary data to the application. In this aspect, the DynNav server is a kind of server.

(26) Lightweight ND

(27) A lightweight ND is a navigation device that does not have a route calculation function, requests a calculated route to a server, and receives information about the calculated route from the server. The lightweight ND accesses the server for route estimation functionalities and for retrieving roads shape representation, if not available in a local map database.

(28) Location URI

(29) A location Uniform Resource Identifier (URI) is a URI that enables the current location of a device to be obtained from a particular location server using a particular dereferencing protocol.

(30) Navigation Device (ND)

(31) An ND is an entity that assists a driver, showing a correct route using a Global Navigation Satellite System (GNSS) service to reach a final destination. This entity may process real-time and predicted traffic information and dynamically estimates the optimal route, according to user preferences.

(32) Point of Interest (POI)

(33) A POI describes information about locations such as name, category, unique identifier, or civic address.

(34) Segment

(35) A segment is a unit into which a road is divided. For a general road, a road running between intersections is a segment, whereas for a highway, a road is divided into segments according to a policy for the highway. Traffic congestion or a passing time may be determined on a segment basis. In the specification, the term segment is interchangeably used with a road section.

(36) Segment Sequence

(37) A set consisting of one or more consecutive segments. If necessary, the segment sequence consisting of one segment is available. Also, an end point of the first segment of the segment sequence consisting of two or more segments is equal to a start point of the second segment of the segment sequence.

(38) Polyline

(39) A polyline is a continuous line used in graphic computing composed of one or more line segments, defined by specifying the endpoints of each segment.

(40) Route Information

(41) Route information is information about segment end points and complementary data from a defined origin and a destination.

(42) Smart ND

(43) A smart ND is a navigation device that is able to calculate a route(s), using a road network database available on the device itself.

(44) Traffic Information

(45) Traffic information is information including traffic events and network performance parameters related to an area or a route. Further, the traffic information may include current or upcoming, that is, future traffic information.

(46) Traffic Event

(47) A traffic event is information about events related to an area or a route that are either imposed or planned by a road network operator (i.e., road works leading to lane closures) or events that occur outside the control of the road network operator (i.e., accidents).

(48) Network Performance Parameter

(49) A network performance parameter is information regarding the performance (i.e., speed, delay, and travel time) of road segments related to an area or a route).

(50) Route Information in Full Format

(51) Route information in a full format is a type of route information including information about all segments from a origin to a destination. Unless specified otherwise, route information is about a whole route.

(52) Route Information in Summarized Format

(53) Route information in a summarized format is a kind of route information including only information about segments selected for a summary of information from among all segments of a route between an origin and a destination (how segments are to be selected is beyond the scope of the present invention).

(54) The present invention relates to a navigation system, method, and apparatus for reflecting real-time traffic information, and more particularly, to a navigation system, method, and apparatus for allowing a traffic information providing server to transmit real-time traffic information to an ND using a minimal communication bandwidth, when the ND is able to calculate a route on its own and has a modem connectable to a mobile communication network in a system for providing real-time traffic information. The present invention relates to a navigation system, method, and apparatus for allowing a traffic information providing server to transmit information about an optimal route and real-time traffic information to an ND even though the ND is not able to calculate a route on its own but is connectable to a mobile communication network. Along with the recent proliferation of smartphones, a navigation service of providing a travel route to a mobile communication terminal in a manner other than using a conventional Digital Multimedia Broadcasting (DMB) network is becoming popular. The OMA LOC WG calls this service Dynamic Navigation Enabler (DynNav).

(55) In the specification, an ND refers to a device that can execute a route guidance function. The ND is any electronic device that can be carried, like a smartphone, a mobile phone, a mobile device, a laptop computer, a tablet PC, a smart pad, etc. or that can be attached to a portable object.

(56) FIG. 5 illustrates a network configuration referred to for describing an Internet Protocol (IP)-based DynNav system being a navigation system according to the present invention. As illustrated in FIG. 5, the navigation system according to the present invention may include an ND that may be connected to a mobile communication network, a mobile communication network for wireless transmission and reception, a traffic information collector and a traffic information and route information providing server (i.e. a DynNav server), which provide traffic information, and a location server for generating and providing assistance data to locate an ND.

(57) For simplicity of description, the traffic information and route information providing server or the DynNav server is referred to shortly as the server. The navigation device is referred to shortly as the ND. According to the capability of an ND, the ND is referred to as the smart ND or lightweight ND.

(58) In the present invention, a terminal (two terminal types are available, as described before) may be connected to a mobile communication network or an IP network such as a Wireless Fidelity (Wi-Fi) network as illustrated in FIG. 6. A corresponding application may access the server, receive route guidance data and real-time traffic information, and thus provide route guidance. While not shown, a terminal capable of calculating a route on its own may selectively receive only real-time traffic information without receiving route guidance data from the server.

(59) The real-time traffic information refers to optimal route information calculated and transmitted to the terminal by the server, real-time and forecasted traffic information, and additional information related to traffic, such as POI and weather. To avoid representational redundancy, a navigation application or a terminal is collectively referred to as a terminal. Accordingly, the terms terminal, smart ND, lightweight ND, and navigation application may be referred to uniformly as terminal.

(60) The afore-mentioned real-time traffic information may be represented in Transport Protocol Experts Group (TPEG) under consideration in the ISO standardization organization. TPEG is a standard protocol used to transmit traffic information and travel information over a digital broadcasting network. As illustrated in FIG. 6, a TPEG layer stack corresponds to the network layer (Layer 3; L3) to application layer (Layer 7; L7) of the ISO/OSI layer model. The network layer defines TPEG frame synchronization and routing. The packetization layer of Layers 4, 5, 6 (L4, L5, and L6) combines components of applications into one stream. Each message format corresponds to the application layer, L7. In DynNav, real-time traffic information may be provided to a terminal in a real-time traffic information representation scheme of TPEG or any other representation scheme.

(61) FIG. 7 is a flowchart of operation according to one embodiment of the present invention. A terminal of FIG. 7 is a smart ND. The smart ND may receive traffic information from a server before calculating a route. The terminal first acquires trip structure information such as an origin and a destination from a navigation user and transmits the trip structure information to the server to receive traffic information of a route before calculating the route. The flowchart of FIG. 7 will now be described in detail.

(62) The terminal may deliver navigation request values necessary to start a navigation service of the user (an origin, a destination, etc.) to the server to request traffic information between the origin and the destination before route search or calculation (S701). The server may receive the request and provide restrictive traffic information between the origin and the destination requested by the terminal (S702). The traffic information includes the above-defined traffic events and (network) performance parameters and enables the smart ND to avoid a traffic congestion segment of road or a segment of road, in which an event causing traffic congestion, such as accidents or road constructions, occurs, upon route calculation. In addition, the traffic information may be referred to as traffic detour information in the present specification. For reference, since the performance parameters correspond to traffic flow information (e.g., an average speed and passage time of a segment of road, etc.) of all segments of road and the traffic events correspond to information on accidents occurring in a segment of road or events such as construction, the traffic events requires less data than the performance parameters.

(63) The terminal may calculate a route (hereinafter, referred to as a first route or reference route) based on the traffic information received from the server and then deliver information about the first route to the server in order to receive real-time traffic information (S703). The server may register the information about the first route and add and deliver the real-time traffic information of the first route to the terminal (S704). Through this process, the terminal can acquire a travel time from the origin (or the current point) to the destination of the first route.

(64) The navigation service starts through the first route (S705). The navigation service starts through the route coincident with the route registered with the server.

(65) When the server detects change in traffic flow of the registered first route, the following steps are performed and, otherwise, the navigation service is continuously performed.

(66) The server may describe information about change in traffic flow of the first route, that is, traffic information, and deliver the information to the terminal (S707). The terminal may recalculate the route based on the real-time traffic information (S708). The terminal may determine whether the recalculated route (hereinafter, referred to as a second route) is partially modified (S709). If the second route is partially modified, the process progresses to S710 and, otherwise, the process progresses to S711.

(67) If the second route is partially modified from the first route, the terminal may deliver information about a modified part of the second route (hereinafter, referred to as a partial route) to the server (S710). That is, the terminal may compare the first route with the second route and deliver only a part modified from the first route to the server. In the related art, the terminal transmits the whole newly calculated route (that is, the second route) to the server. However, this leads to unnecessary resource waste. According to one embodiment of the present invention, it is possible to improve resource efficiency by transmitting only the partial route of a new route to the server.

(68) The method for representing information about the partial route will now be described in detail.

(69) If the second route is not partially modified from the first route, the terminal may deliver the whole second route to the server (S711). That is, if the second route does not completely overlap the first route, the terminal may transmit the second route to the server without change.

(70) Additionally, in the present invention, when the partial route and the reference route (the first route) coexist, if the reference route is no longer used (e.g., because the traffic condition of the reference route is bad), the terminal deletes the route, When the route except for the partial route is deleted, the reference route is deleted using the reference route corresponding to the partial route and a first segment, a last segment and the number of segments, all of which are information about the partial route, such that the traffic information is continuously tracked.

(71) FIG. 8 is a diagram showing an example of the embodiment related to FIG. 7. In S710, the terminal may provide the partial route to the server instead of the whole route in a special case. A method for providing the partial route is referred to as a partial route encoding method in the present specification. The partial route encoding method may be used to efficiently access traffic information related to a set of routes sharing common segments.

(72) As shown in FIG. 8, a solid line denotes a reference route (e.g., corresponding to the first route in the embodiment of FIG. 7) and a dotted line denotes a partially modified route (e.g., corresponding to the second route in the embodiment of FIG. 7). In the present specification, the partially modified route is referred to as a partial route.

(73) As route information, the terminal can choose to provide only a sequence of segments that is partially modified from the reference route previously uploaded to the server. In FIG. 8, the segments of the sequences 4 to 5, 11 to 13 and 24 to 28 denoted by the dotted line are partially modified from the reference route. The set of the consecutive segments of the sequences 4 to 5, 11 to 14 and 24 to 28 are respectively referred to as first to third segment sequences and the partial route composed of the first to third segment sequences may be transmitted to the server. These segment sequences may be included in a partial route description and the partial route description may be defined in a route structure. In this case, information about the partial route for merging the partial route with the reference route is provided as follows.

(74) First segmentIndicates index information indicating a first segment of the segment sequence of the reference route to be replaced by the segment sequence of the partial route, with respect to each segment sequence of the partial route (4, 11 and 24 in the embodiment of FIG. 8).

(75) Last segmentIndicates index information indicating a last segment of the segment sequence of the reference route to be replaced by the segment sequence of the partial route, with respect to each segment sequence of the partial route (6, 15 and 27 in the embodiment of FIG. 8).

(76) Number of segmentsIndicates information about the number of segments configuring each segment sequence (2, 4 and 5 in the embodiment of FIG. 8).

(77) The information about the first segment, the last segment and the number of segments may be included in the route structure or the segment structure corresponding to Table 2 or Table 3. Since the information about the first segment, the last segment and the number of segments is related to the partial route, if the above-described information is included, an indicator indicating that the information about the segment is related to the partial route may be included in the route structure or the segment structure.

(78) FIG. 9 is a flowchart of operation according to one embodiment of the present invention. An environment to which the embodiment of FIG. 9 applies is equal to that of FIG. 7 and FIG. 9 partially overlaps FIG. 7.

(79) A navigation service starts via a first route (S901). The navigation service starts through a route coincident with a route registered with the server.

(80) If the server detects change in traffic flow of the registered first route, the following steps are performed and, otherwise, the navigation service may be continuously provided (S902).

(81) The server may describe information about change in traffic flow, that is, traffic information, to the terminal. The terminal may calculate the route based on real-time traffic information and register the recalculated route (hereinafter, referred to as a second route) with the server (S903). When the second route is delivered, the terminal may use the partial route encoding method. Refer to the description of FIGS. 7 to 8.

(82) The server may transmit the traffic information of the route registered in S903 to the terminal (S904). The terminal may determine whether the traffic flow of the registered route is better than that of the reference route (S905). If the traffic flow of the registered route is better than that of the reference route, the terminal may continuously perform the navigation service. However, if the traffic flow of the registered route is worse than that of the reference route, the following steps are performed. For example, the traffic flow may be determined based on a travel time from an origin (or a current point) to a destination via one route.

(83) The terminal may delete the route registered with the server (S906). The server needs not manage the route which is not used by the terminal.

(84) If the process of S903 to S906 is repeated (the process goes into a loop), the following steps are performed. The number of times of repetition may be restricted to an integer of 1 or more according to the embodiment of the present invention and the integer does not limit the range of the present invention.

(85) The terminal may determine whether the process of S903 to S906 is repeated n times or more (S907). For determination, the terminal may increase a counter value by 1 in S906 and compare the counter value with n. If the process of S903 to S906 is repeated, the number of times of repetition may be restricted in S907 to prevent the embodiment of the present invention from going to an infinite loop. The terminal separately requests traffic information of a part, in which the process of S903 to S906 is repeated (S908). The repeated part may be represented by a segment sequence and the number of repeated parts may be one or more.

(86) The terminal may receive traffic information of the repeated part from the server and calculate and register an optimal route of the repeated part with the server (S909).

(87) In the embodiment of FIG. 9, when the route is recalculated using the traffic information, if a route having a traffic flow state worse than an existing route is repeatedly acquired, the process of the embodiment may exit the loop.

(88) FIG. 10 is a diagram showing detailed operation according to one embodiment of the present invention shown in FIGS. 7 to 9. An application 1010 corresponds to a DynNav application as described above and may be referred to as a terminal. Accordingly, in the description of FIG. 10, the application is referred to as the terminal. In addition, a server 1020 corresponds to a DynNav server as described above.

(89) 1. POST: Create Trip Description

(90) The terminal 1010 may create a trip description via trip parameters defined by a user of the terminal, that is, an origin, a destination or other information, using a POST command. In response thereto, the server 1020 may create a trip corresponding to the trip description and transmit an identifier thereof and defined parameters to the terminal.

(91) 2. POST: Create Area Description

(92) The terminal may create an area description using a POST command in order to request traffic information related to the trip identified by the origin and destination of the trip. For bandwidth and operation optimization, the server may provide two types of traffic information as a response.

(93) a) performance parameters in the vicinity of the origin if severe congestion occurs in the vicinity of the origin; that is, in the present specification, the (network) performance parameter means information about performance or traffic flow (that is, speed, delay and travel time) of the segment indicating an area or route, the server transmits performance parameters of an area or on a route within a predetermined radius from the origin as a response in 2. POST: create area description, and these performance parameters may be provided by the server if a congestion having a predetermined level or more occurs in the area or on the route within the predetermined radius.

(94) b) Traffic events of the area related to the trip.

(95) 3. GET: Request the Traffic Information

(96) The terminal may read the traffic information provided by the server using a GET command. This traffic information may be used by the terminal to estimate or calculate the route of the above-defined trip while avoiding critical segments of road (influenced by accidents, construction or road congestions).

(97) 4. POST: Create a Route Calculated by Application

(98) The terminal may upload the estimated route (selected from the routes calculated by the terminal) to the server using a POST command. The server may reply with a representation of route resource including the performance parameters and links to traffic events.

(99) 5. POST: Subscription to the Trip

(100) The terminal may subscribe to the notification service for the area selected in step 2 and for the defined trip in step 3 using a POST command. The terminal will be notified of new information about performance parameters and traffic events related to the selected area and to all the routes uploaded for the trip.

(101) 6. PUT: Update the Trip Parameter

(102) The terminal may periodically update the current position thereof using a PUT command in order to modify the origin parameter of the trip resource. This operation is triggered when the vehicle having the terminal mounted therein drives a certain distance from the previous reporting position, and the server may utilize this information to delete the already travelled segments from the route(s) information.

(103) 7. POST: Notification Under CallBackNotifURL

(104) When traffic events and/or severe congestions along the proposed routes are detected by the server, the server notifies the terminal of the updated traffic information of the current route using a POST command on the address or URL (CallBackNotifURL) of the terminal.

(105) 8. GET: Request the Traffic Info Based on the Notification.

(106) The terminal may access the updated traffic information (the traffic events and the performance parameters) related to the route using a GET command.

(107) 9. PUT/POST: Modify/Create Calculated Route

(108) The terminal may decide to recalculate a new route under the following conditions.

(109) a) The terminal receives the updated traffic information in step 8.

(110) b) The terminal detects that the vehicle is deviating and diverting from the defined route.

(111) The terminal may upload the newly calculated route to the server using a PUT command for an existing route or a POST command for a newly registered route, depending on whether or not the terminal wishes to maintain validity of the previous route. The server may reply with a representation of the route resource which contains performance parameters.

(112) This step may be repeated several times until the performance of the recalculated route, that is travel time, is better than the previous routes. However, in order to avoid going into a loop, the terminal may define a new area description to acquire traffic information in an area where repetition occurs with operations similar to those described in steps 2 and 3.

(113) For bandwidth optimization, the terminal can choose to use a partial route schema, uploading the changed segments with respect to an already defined reference route.

(114) 10. DELETE: Response the Previous Route Resource

(115) The terminal may delete the previous routes no longer in use from the set of proposed routes using a DETETE command. The terminal may delete the newly calculated route from the set of proposed routes if the performance of the new route is worse than that of the previous route. The terminal may unsubscribe from the notification service for the previous routes using a DELETE command (if the new route has replaced the old route using a modify operation in step 9, the delete operation is not needed).

(116) If the delete operation is executed on a route that is referenced in resources described with partial route information, the server has to keep the resources description consistent (that is, complete route description should be partially provided for route previously encoded).

(117) FIG. 11 is a block diagram showing a device in which the embodiments of the present invention may be implemented. The terminal 1110 may include a transceiver 1111 configured to communicate with the server 1120 and a processor 1112 configured to calculate the route via the traffic information received from the server. The server 1120 may include a transceiver 1121 configured to communicate with the terminal and a processor 1122 configured to calculate the route based on parameters related to a trip, such as an origin and a destination, which are received from the terminal, or collect and process the traffic information.

(118) In the embodiment of the present invention described with reference to FIG. 11, the terminal 1110 is a smart ND. In this embodiment, the processor 1112 receives updated traffic information related to the first route while the terminal or a vehicle having the terminal mounted therein moves on the first route, calculates the second route using the updated traffic information and transmits the whole route or partial route of the calculated second route to the server.

(119) The processor is configured to compare the calculated second route with the first route and to transmit information about the partial route composed of one or more modified segment sequences to the server. The segment sequence is composed of one or more consecutive segments and the information about the partial route may include first segment information and last segment information of the segment sequence of the first route to be replaced by each segment sequence included in the partial route.

(120) The information about the partial route may include the one or more segment sequences.

(121) In addition, the process is configured to receive the performance parameters of the whole or partial route of the second route from the server and the performance parameters may include at least one of a speed, delay and a travel time for a segment of road.

(122) The information about the partial route may include an indicator indicating that the above information is related to the partial route.

(123) The processor may be configured to receive, from the server, information indicating that the updated traffic information related to the first route has been created.

(124) In addition, the processor may be configured to recalculate the second route using the updated traffic information if the traffic flow of the calculated second route is worse than that of the first route. If recalculation is performed a predetermined number of times (n), the processor may be configured to request the traffic information of a specific area in which recalculation is repeated.

(125) The detailed description of the exemplary embodiments of the present invention has been given to enable those skilled in the art to implement and practice the invention. Although the invention has been described with reference to the exemplary embodiments, those skilled in the art will appreciate that various modifications and variations can be made in the present invention without departing from the spirit or scope of the invention described in the appended claims. Accordingly, the invention should not be limited to the specific embodiments described herein, but should be accorded the broadest scope consistent with the principles and novel features disclosed herein.

INDUSTRIAL APPLICABILITY

(126) The embodiments of the present invention are applicable to a navigation device or server.