[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

WO2014168428A1 - 복수의 경유지를 포함한 최적 경로 전달 방법 및 이를 위한 장치 - Google Patents

복수의 경유지를 포함한 최적 경로 전달 방법 및 이를 위한 장치 Download PDF

Info

Publication number
WO2014168428A1
WO2014168428A1 PCT/KR2014/003105 KR2014003105W WO2014168428A1 WO 2014168428 A1 WO2014168428 A1 WO 2014168428A1 KR 2014003105 W KR2014003105 W KR 2014003105W WO 2014168428 A1 WO2014168428 A1 WO 2014168428A1
Authority
WO
WIPO (PCT)
Prior art keywords
route
information
subpath
server
waypoints
Prior art date
Application number
PCT/KR2014/003105
Other languages
English (en)
French (fr)
Inventor
최재혁
안홍범
Original Assignee
엘지전자 주식회사
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 엘지전자 주식회사 filed Critical 엘지전자 주식회사
Priority to CN201480020683.5A priority Critical patent/CN105144262B/zh
Priority to JP2015562942A priority patent/JP6140312B2/ja
Priority to US14/782,399 priority patent/US9749930B2/en
Publication of WO2014168428A1 publication Critical patent/WO2014168428A1/ko

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W40/00—Communication routing or communication path finding
    • H04W40/02—Communication route or path selection, e.g. power-based or shortest path routing
    • H04W40/04—Communication route or path selection, e.g. power-based or shortest path routing based on wireless node resources
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/09—Arrangements for giving variable traffic instructions
    • G08G1/0962—Arrangements for giving variable traffic instructions having an indicator mounted inside the vehicle, e.g. giving voice messages
    • G08G1/0968—Systems involving transmission of navigation instructions to the vehicle
    • G08G1/096805—Systems involving transmission of navigation instructions to the vehicle where the transmitted instructions are used to compute a route
    • G08G1/096811—Systems involving transmission of navigation instructions to the vehicle where the transmitted instructions are used to compute a route where the route is computed offboard
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/09—Arrangements for giving variable traffic instructions
    • G08G1/0962—Arrangements for giving variable traffic instructions having an indicator mounted inside the vehicle, e.g. giving voice messages
    • G08G1/0968—Systems involving transmission of navigation instructions to the vehicle
    • G08G1/096833—Systems involving transmission of navigation instructions to the vehicle where different aspects are considered when computing the route
    • G08G1/096838—Systems involving transmission of navigation instructions to the vehicle where different aspects are considered when computing the route where the user preferences are taken into account or the user selects one route out of a plurality
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W40/00—Communication routing or communication path finding
    • H04W40/34—Modification of an existing route
    • H04W40/38—Modification of an existing route adapting due to varying relative distances between nodes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/08—Mobility data transfer
    • H04W8/085—Mobility data transfer involving hierarchical organized mobility servers, e.g. hierarchical mobile IP [HMIP]

Definitions

  • Optimal route transmission method including a plurality of waypoints and device therefor [Technical Field]
  • the present invention relates to a method for transmitting a route and an apparatus therefor, and more particularly, to a method for transmitting a route including a plurality of waypoints and an apparatus for the same.
  • a navigation terminal detects a current position, that is, a starting point through a connection with a Global Positioning System (GPS), and receives a destination of a travel from a user to calculate a route in the terminal itself.
  • GPS Global Positioning System
  • service methods that provide route information, route-related real-time traffic information and various information from servers that provide traffic information and route information using PNDs (Personal Navigation Devices) in mobile networks are being utilized. have.
  • the 0MA (0pen Mobile Alliance) standardization organization delivers TPEGCTraffic Protocol Expert Group (TPEGCTraffic Protocol Expert Group) information in a digital multimedia broadcasting (DMB) network in which information is provided in an existing broadcasting format.
  • DMB digital multimedia broadcasting
  • Dynamic Navigation Enabler which delivers real-time traffic information to peer-to-peer (P2P)
  • IP IP
  • the standard considers two types of navigation terminals and services of smartphones. ⁇
  • the first method is to perform a complicated route calculation in a navigation application installed in a smartphone, but in a server providing traffic information and route information, and deliver the corresponding route to the smartphone.
  • the second is to improve the performance of the smart phone when the route calculation is performed by the application itself mounted on the smartphone or when the navigation terminal equipped with a mobile modem performs the route calculation. If the terminal registers the calculated route to the server without transmitting it, only real-time traffic information related to the route is registered. It is a form that can be customized from the server in the IP-based P2P rather than the existing broadcast form.
  • Fig. 1 shows the division of a navigation device.
  • the navigation device additionally transmits TPEG-based traffic information transmitted through a broadcasting network such as DMB (110), additionally transmits traffic information based on IP such as a mobile communication network or Wi-Fi (120), and other communications. It can be classified into a standalone form 130 that generates and provides route information by tracking the location of the vehicle through GPS and connection without a medium connection.
  • DynNav which is currently being standardized by OMA LOC WG, belongs to the form of transmitting IP-based traffic information in the above classification (120), and more specifically, belongs to the category of delivering in P2P form, and in DynNav, a navigation device is provided.
  • IP-based traffic information in the above classification (120)
  • DynNav a navigation device is provided.
  • Smart NEKSmart ND, 122) A device that can calculate the route by itself and requests only real-time traffic information without receiving route information through the DynNav server.
  • Lightweight MXLightweight ND, 121) It is impossible to calculate the route by itself, so the device requests all real-time traffic information including route information through DynNav server.
  • Trip Structure As the first terminal, the first terminal acquires information such as origin and destination from the user and transfers the information to the server.
  • the trip structure consists of subsets corresponding to multiple path structures.
  • Route Structure The route structure is represented by several segments in such a way that the entire route is calculated through the trip structure.
  • Segment Structure It is a structure that expresses each segment and can define not only the length of each segment but also the real-time traffic situation corresponding to the segment based on the expression of (TPEG).
  • Subscription List Structure Displays a list of subscript ions. Table 4 included in POST requests by the client, but MUST be included in POST requests representing notifications by the server to the client, when a com lete
  • the resourceURL MUST be also included in responses to any HTTP method that returns an entity body, and in I I PUT requests.
  • Lightweight ND does not support route calculation because its capacity does not support route calculation, so it must request route information from server and receive route information from server.
  • Typical functions are as follows.
  • a user of an application defines travel parameters and the application sends the parameters to a server: the server uses a set of sets based on the received parameters using relevant traffic information. Compute suggested routes. The server responds to the application with a created "trip" resource containing the path identifiers of the suggested routes.
  • the application accesses the set of paths in a summarized format. This step is repeated for all routes suggested by the server. However, if the length and complexity of the trip is limited or network quality is inadequate, full format path information may be used at this stage. The application may request this if the shape information (WGS84 coordinate polyline) for the proposed paths is not available in the navigation device.
  • the user selects one path from the proposed set, and the application accesses full format information about the path selected by the user.
  • the application may request this if shape information (WGS84 coordinate polyline) for the proposed paths is not available in the navigation device. If in step 2 the full format path is obtained, this step is not necessary.
  • the server responds with the selected route information together with the relevant traffic information.
  • the application accesses traffic events related to the route using links to the provided traffic event resources. Access to the traffic events may be restricted to categories selected by the user.
  • the application removes unnecessary paths previously proposed by the server but not selected by the user.
  • the application requests the server to create a subscript ion in the notification service for the trip (path (s)).
  • the application is notified by the server about the following events:
  • the server recognizes that the current location does not belong to the route being used and calculates a new route using the new origin. The server responds with the identifier of the new route and deletes the old route (and identifier). If the modified origin parameter belongs to the previous route, the server uses this information to delete the segment already traveled from the route.
  • step 7 is a case in which the vehicle has detoured or departed from the route and the vehicle has moved a certain distance from a previously reported point and / or the segment where the vehicle has requested the server to upload its current location Occurs when entering.
  • the server delivers a notification resource to the application using links to modified resources, including trips and routes, including the updated traffic information (traffic events and performance parameters).
  • the application accesses the new proposed route along with performance parameters and traffic events. Since the application has subscribed to the notification service for the trip resource, the subscription will cover the new proposal path.
  • the application accesses update information for the route being used, new related traffic events and the proposed alternative route, and since the subscription of the notification service includes all routes associated with the trip. And the notification extends to the proposed alternative route. If the location of the third party is changed, the application accesses the location of the changed third party and / or the updated route resource as a destination.
  • a user often needs to request a route including one or more waypoints.
  • a route including one or more waypoints For example, in order to improve the user satisfaction / experience of more various service provisions for the navigation service, a path including one or more maintenance is requested, and a method of providing the service on the server side is considered. For example, a user may have to visit several geographic locations within a certain time so that multiple waypoints can be entered when requesting a route.
  • the present invention aims to propose a method for solving a problem occurring in the form of a service providing a route including one or more waypoints mentioned above.
  • the technical problems to be achieved in the present invention are not limited to the above technical problems, and other technical problems not mentioned will be clearly understood by those skilled in the art from the following description. could be.
  • a method for receiving a route of a trip including a plurality of waypoints calculated by a server wherein the method is performed by a terminal and includes the plurality of waypoints.
  • Sending a request for a route for a trip to a server wherein the request includes an indicator indicating the request for a route including the plurality of waypoints and the plurality of waypoints, and a trip including the plurality of waypoints
  • Receiving information on the proposed route of the server the method comprises the proposal route of the trip is composed of a plurality of sub-paths, the information on the proposed route is a number of proposal route of the trip If the information includes information indicating that the subpath is configured and a link to the first subpath of the subpath, Receiving information about the first subpath via a link to the second subpath, wherein the information on the first subpath indicates whether a second subpath following the first subpath exists; It may include a link to.
  • the method may further comprise receiving information for the Nth subpath via a link to an N (N> 2) th subpath.
  • the information on the N-th subpath includes an indicator indicating whether an N + 1th subpath exists and a link to the N + 1th subpath, wherein the N + 1
  • the link to the N th subpath may be included in the information on the N th subpath when the N + 1 th subpath exists.
  • the request includes a route condition consisting of at least one of a maximum allowable travel time of the route, a priority for each of the plurality of waypoints, or a time to stay at each of the plurality of waypoints; May be calculated based on the path condition.
  • a route condition consisting of at least one of a maximum allowable travel time of the route, a priority for each of the plurality of waypoints, or a time to stay at each of the plurality of waypoints; May be calculated based on the path condition.
  • a route condition consisting of at least one of a maximum allowable travel time of the route, a priority for each of the plurality of waypoints, or a time to stay at each of the plurality of waypoints; May be calculated based on the path condition.
  • the time required for the operation of the specific proposal route calculated by the server exceeds the maximum allowable traveling time
  • at least one of the plurality of waypoints is determined according to the priority of the specific proposal route. May be excluded.
  • the proposed route may be divided into a plurality of sub-paths based on a travel time reference or a travel distance reference.
  • each of the plurality of sub-paths may be based on road traffic information at different points in time.
  • each of the plurality of subpaths may be received with a time difference.
  • a method for providing a terminal with a route of a trip including a plurality of waypoints calculated by a server wherein the method is performed by a server and the plurality of waypoints.
  • Receiving a request for a route for a trip from the terminal wherein the request includes information indicating a request for a route including the plurality of waypoints and the plurality of waypoints; a trip including the plurality of waypoints Calculating a suggested route of the; And transmitting information on the proposed route to the terminal, wherein the proposed route of the trip is composed of a plurality of sub-paths, and the information on the proposed route includes several sub-paths of the proposed route of the trip.
  • the terminal is configured to receive information about the first sub-path through the link to the first sub-path, the first sub-path
  • the information about may include an indicator indicating whether a second subpath following the first subpath exists and a link to the second subpath.
  • information on the Nth subpath may be provided to the terminal through a link for an N (N> 2) th subpath.
  • the information on the N-th subpath includes an indicator indicating whether an N + 1th subpath exists and a link to the N + 1th subpath, wherein the N + 1
  • the link to the N th subpath may be included in the information on the N th subpath when the N + 1 th subpath exists.
  • the request includes a route condition consisting of at least one of a maximum allowable travel time of the route, a priority for each of the plurality of waypoints, or a time to stay at each of the plurality of waypoints, and the proposed route. May be calculated based on the path condition.
  • At least one of the plurality of waypoints is determined according to the priority of the specific proposal route. May be excluded.
  • the proposed route may be divided into a plurality of sub-paths based on the travel time or the travel distance.
  • each of the plurality of sub-paths may be based on road traffic information of different views.
  • each of the plurality of subpaths may be provided with a time difference.
  • a terminal configured to receive a trip route including a plurality of waypoints calculated by a server according to an embodiment of the present invention, comprising: a transceiver configured to communicate with a server; And a processor configured to obtain update information about the route based on the information received from the server, wherein the processor transmits a request for a route for a trip including the plurality of waypoints to a server, and the request.
  • Is configured to receive information indicating a request for a route including the plurality of waypoints and the plurality of waypoints, and to receive information about a proposed route of the trip including the plurality of waypoints from the server.
  • the processor may provide a link to the first sub-path.
  • Information for the second sub-path may include a link to the indicator and the second sub-channel to indicate whether the second sub-path following the first sub-path exists.
  • a server configured to provide a terminal with a route of a trip including a plurality of waypoints calculated by a server, according to an embodiment of the present invention, comprising: a transceiver configured to communicate with a terminal; And the warning based on the information received from the terminal.
  • a processor configured to generate update information for the road, wherein the processor receives a request for a route for a trip including the plurality of waypoints from the terminal, wherein the request indicates a route request for the route including the plurality of waypoints; Information and the plurality of waypoint information; Information about the proposed route including the plurality of waypoints is transmitted to the terminal, and the proposed route of the trip is composed of a plurality of sub-paths.
  • the terminal includes information indicating that a plurality of sub-paths and a link to the first sub-path of the sub-path is configured to receive information on the first sub-path through the link to the first sub-path
  • the information on the first subpath may include an indicator indicating whether a second subpath following the first subpath exists and a link to the second subpath.
  • unnecessary data transmission and transmission that may occur between the navigation device (or application) and the server may be reduced, thereby reducing service quality and / or user's service quality (QoE). It can increase.
  • 1 shows a division for a navigation device.
  • FIG. 2 is a flowchart illustrating the operation of a lightweight MXLight weight ND) in the conventional DynNav system.
  • FIG. 3 is a network configuration diagram illustrating an overall IP-based DynNav system, which is a navigation system of the present invention. 4 shows the worm structure of TPEG.
  • FIG. 5 illustrates a route including a plurality of waypoints according to an embodiment of the present invention.
  • FIG. 6 illustrates a route including a plurality of waypoints in consideration of the time spent at each waypoint according to an embodiment of the present invention.
  • FIG. 7 illustrates an example of a method of providing split waypoint information according to an embodiment of the present invention.
  • FIG. 9 shows a block diagram of an apparatus in which embodiments of the present invention can be implemented.
  • Application herein refers to the implementation of a well-defined but not standardized set of functions for performing tasks on behalf of a user.
  • the application may consist of software and / or hardware elements and associated user interfaces.It may consist of software. and / or hardware elements and associated user interfaces. [79] Server
  • a server corresponds to an entity that provides resources to clients in response to requests (An entity that provides resources to Clients in response to requests.).
  • a client corresponds to a device, user agent, or other entity operating as a receiver of a service (A device, user agent, or other entity that acts as the receiver of a service). .)
  • DynNav corresponds to an entity that is responsible for interacting with the DynNav server to obtain optimal route (s), real-time and future traffic information and auxiliary data. of interacting with a DynNav Server to get optimal route (s), real-time and forecasted traffic information and complimentary data.
  • the DynNav application is mounted on a terminal including a smartphone, a mobile phone, a navigation device, and the like, and accordingly, the DynNav application may be referred to interchangeably with the terminal.
  • the DynNav application is a kind of client.
  • the DynNav application is referred to as a source terminal, a destination terminal, or simply a "terminal".
  • the source terminal refers to a terminal requesting a destination terminal location-based path setting service
  • the target terminal refers to an entity that is a destination in the corresponding service.
  • the DynNav server corresponds to an entity that is responsible for providing the route (s), real-time and future traffic information and auxiliary data that are expected to the application (An entity that is in charge). of providing to the application optimal route (s), real-time and forecasted traffic information, and complimentary data.).
  • the DynNav server corresponds to a type of the server.
  • the DynNav server is referred to as "traffic information server” or simply "server”.
  • Location URI Location URI (Location UI)
  • a location URI corresponds to a URI that enables a device to obtain a current location of a device from a specific location server using a protocol for obtaining a location (A URI that enables the current location of a device to be obtained from a particular location server using a particular dereferencing protocol.).
  • a navigation device corresponds to an entity that assists a driver to show a correct path to reach a final destination using a global navigation satellite system (GNSS) service.
  • GNSS global navigation satellite system
  • This entity can process real-time and predicted traffic information according to user preferences and dynamically estimate the optimal route (An entity that, using GNSS service, assists the driver showing correct route to reach the final destination.
  • This entity may process real—time and predicted traffic information and dynamically estimates the optimal route, according to user preferences.)
  • the light weight ND means a navigation device that does not have a function for calculating a route and requests and receives a calculated route from a server, and if the local map database is not available, And a navigation device that accesses to a server for route estimation functionalities and for retreiving roads shape representation, if not available in a local map database.
  • a smart ND corresponds to a navigation device that can calculate a route (s) using a road network database available on the device itself (A navigation device that is able to calculate the route (s). , using a roads network database available on the device itself.
  • Point Of Interest describe information about locations such as name, category, unique identifier or city address (POI describes information about locations such as name, category, unique identifier, or civic address.).
  • segments are defined by segmenting roads according to the policy of each highway.
  • traffic congestion or passing time may be determined.
  • segments are used interchangeably with road segments.
  • [100] refers to a collection of one or more consecutive segments. If necessary, a segment sequence consisting of one segment is also possible. Also, for example, a segment sequence consisting of two or more segments has the end point of the first segment equal to the start point of the second segment.
  • a polyline corresponds to a continuous line used in graphic computing composed of one or defined by specifying end points of each segment. more line segments, defined by specifying the endpoints of each segment).
  • the route information corresponds to information of coordinates of segment end points and complimentary data from the defined origin and the destination.
  • traffic information corresponds to information consisting of traffic events and network performance parameters related to an area or a route.
  • the traffic information may include current or future traffic information, that is, future traffic information.
  • a traffic event includes events related to an area or route imposed or planned by a road network operator (that is, road constructions causing road closure) or events occurring outside the control of the network operator ( Information regarding event s related to an area or a route that are either imposed or planned by the road network operator (ie road works leading to lane closures) or event s that occur outside the control of the network operator (ie accidents)).
  • the network performance parameter corresponds to information regarding performance or traffic flow (ie, speed, delay, and time required) of each segment existing in an area or a path (Information regarding the performances (ie speed, delay and travel time) of road segments related to an area or a route.).
  • a type of route information including all segments from a source to a destination. Unless otherwise stated, the path information means the entire path.
  • [114] refers to a form of route information including only segments selected for the summary of information among all segments from the source to the destination (the manner of selection is not covered in the present invention).
  • a navigation service providing a mobile route to a mobile communication terminal has been widely used, away from the format using the conventional DMB broadcasting network, and 0MA L0C WG provides the above services with DynNav (Dynamic Navigation). This is called.
  • DynNav Dynamic Navigation
  • the navigation device refers to a device capable of performing a route guidance function
  • the navigation device is portable or portable such as a smart phone mobile phone, a mobile device, a ramtop, a tablet PC, a smart pad, and the like. It includes all electronic devices that can be attached to possible objects.
  • FIG. 3 is a network configuration diagram illustrating an overall IP-based DynNav system, which is a navigation system of the present invention.
  • the navigation system includes a navigation device (ND) capable of accessing a mobile communication network, a mobile communication network for wireless transmission and reception, a traffic information collecting device and a traffic information and route information providing server (DynNav Server), and a navigation device to provide traffic information. It may include a location server for generating and forwarding assistance data (Assistance Data) for obtaining the location of the device.
  • ND navigation device
  • DynNav Server traffic information and route information providing server
  • the traffic information providing server or the DynNav server is referred to as “server”, and the navigation apparatus is "terminal” ND “or” Smart ND “or” depending on the capability of each terminal. Lightweight ND ".
  • the terminal (which can be divided into two terminal types as mentioned above) can be connected to an IP network such as a mobile communication network or Wi-Fi as shown in the figure, and for route guidance.
  • the navigation application includes a navigation application, and the application can connect to a server to receive route guidance data and real-time traffic information to guide the route.
  • the terminal capable of calculating the route itself may selectively receive only real-time traffic information without receiving route guidance data from the server.
  • the real-time traffic information means additional information related to traffic such as optimal route information, real-time and predicted traffic information, POKPoint of Interest, and weather calculated by the DynNav server and delivered to the terminal.
  • navigation applications, terminals or users are collectively referred to as terminals to eliminate duplication of expression. Therefore, in the present specification, “terminal”, “ND”, “Smart ND”, “Lightweight ND”, “navigation application” user “and terms equivalent thereto may be referred to as” terminal ".
  • TPEG refers to a standard protocol for transmitting traffic and travel information through a digital broadcasting network.
  • the hierarchical structure of the TPEG extends from the network layer (third layer) to the application layer (seventh layer) of the IS0 / 0SI Layer model.
  • the network layer defines TPEG frame synchronization and routing.In the packetization layer of the 4th, 5th, 6th layer, the components of each application are merged into one stream, and each message specification corresponds to the 7th layer, which is the application layer. do.
  • DynNav the TPEG
  • the real-time traffic information can be provided to the terminal according to the real-time traffic information expression method of, a separate expression method can be used.
  • a user when a user requests a route from a server, information such as a start point, a destination, a stopover, and a start time may be provided.
  • the server may configure and deliver an optimized route to be provided to the user based on information such as a start point, a destination, a waypoint, a start time, and a real-time or predicted road traffic information requested by the user.
  • the user In this case, the user must provide a starting point and a destination to the server.
  • the method when a user requests a route from the server, the method includes requesting an optimal route passing through the waypoints, including one or more multiple waypoints.
  • the server considers the real-time or predicted road traffic information, and generates an order of passing through each waypoint and an optimum path through the waypoint.
  • the server selects a route considering one of several waypoints as a destination.
  • An example of such a route request / provision could be a courier delivery or a salesman who must visit multiple branches.
  • the shortest route through several stops may not necessarily be optimized. Therefore, there is a need for a method of providing an optimal route through various traffic conditions depending on road traffic conditions. In this case, the order of crossing multiple stops may change depending on road traffic conditions. In addition, road traffic conditions change over time, so consideration should be given to providing an efficient route accordingly.
  • the present invention proposes a method in which a user requests a route passing through one or more waypoints, and the server provides an optimal route. It also considers ways to reduce the need to update route and traffic information as traffic conditions change.
  • a method for providing a user with an optimal route through more than one waypoint is provided by a user requesting a route from the server and the server providing a route to the user. There are steps to provide.
  • the present invention does not cover how the server calculates the optimal path according to the user's request.
  • the method of calculating the optimal path may be implemented through various existing algorithms.
  • the request when a user requests a route from a server, the request includes a basic information necessary for constructing the route (see Table 1). At this point, the origin (originWGS84 or originAddress) and destination (destinationWGS84 or destinationAddress) must be included.
  • a condition for a user to request an optimal route through various waypoints to the server is as follows. .
  • [133] includes routeForMult ipleWaypoints to request the best route across multiple waypoints when requesting routes
  • the "routeForMult ipleWaypoints" parameter is defined as a sub-parameter of the Trip parameter used when a user requests a route from the server.
  • the server calculates an optimal route in consideration of a starting point, a destination (when a destination is included), a waypoint and a traffic condition of a road. At this time, the order of reaching the waypoints may vary depending on the optimal route, and when no destination is included, one of the plurality of waypoints is considered as the final destination in consideration of the optimal route.
  • the user can express multiple waypoints by using the "waypoints" sub-parameter of the Trip parameter (see Table 1), but depending on the implementation, multiple "destination” (dest inat ionWGS84 or destinationAddress). It can also be expressed through).
  • the user may request a route by adding a time condition and a priority condition of waypoints.
  • the time condition is a method of designating a total route driving time when a user requests a route.
  • the parameters related to route travel time are as follows.
  • the server should provide a route that can pass all waypoints during the designated traveling time. At this time, if the user does not specify the path starting time, the current time can be considered as the path starting time.
  • the route driving time may be a criterion for determining whether to calculate and provide a new alternative route. If the traffic condition of the provided route worsens and the route travel time is increased, but if the route travel time does not exceed the route travel time above, continue to the corresponding route, and if the increased travel time exceeds the route travel time due to the bad traffic situation, The server may calculate and provide a new route to the user that does not exceed the route travel time. In addition, the user may set a waypoint priority condition along with a time condition when requesting a route. Parameters related to waypoint priority conditions are as follows.
  • the server calculates an optimal path meeting the specified condition and provides the path. If all of the waypoints requested by the user can pass within a specified time condition, the server does not consider the condition for maintaining priority when creating an optimal path. However, if a plurality of waypoints requested by the user cannot pass all within a specified time condition, the server creates an optimal route by considering the high priority waypoints based on the waypoint priority conditions, and creates an optimal route. The optimal route can be created without including the low priority waypoints in the optimal route.
  • a server provides a path to a user. The first is to provide the whole path at once and the second is to divide the path as before.
  • the first method is the same as before.
  • the server When a user requests a route from the server, the server provides the calculated entire route from the optimal starting point to the destination at once. Also, when the traffic information on the route is changed or an alternate route occurs during the route, the user is notified as before.
  • the probability of a change or an alternate route of traffic information may be high and frequent.
  • the parcel delivery shown above as an example
  • change information may be frequently generated because of a long moving distance or a driving time due to a business characteristic. Therefore, the first proposed method is likely to require the server to frequently provide the changed information back to the user, and consumes a lot of network resources.
  • the second method proposed for this problem is to provide the whole path divided into partial paths.
  • the server divides the route on a predetermined basis and delivers the route to the user.
  • the criteria that can be considered here are as follows.
  • FIG. 5 illustrates a route including a plurality of waypoints according to an embodiment of the present invention.
  • the user requests a route passing from A to B via H, and the server calculates an optimal route as follows. If the server delivers the route step by step based on the waypoint considering the driving distance and the reference driving distance is 10km, the server delivers the route to the user in the following steps.
  • the path corresponding to each step is referred to as a divided path.
  • FIG. 5 (b) shows that even if the server calculates a different route even if it passes through the same starting point and waypoint, the providing method may be different.
  • FIG. 5 (c) shows a route including a plurality of waypoints based on the travel time.
  • the user requested a route from A to B via F, and the server calculated the optimal route as shown in Fig. 5 (c). If the server delivers the route in stages based on the waypoint considering the driving time and the reference driving time is 1 hour, the server transmits the route to the user in the following steps.
  • the reference driving time is 1 hour, but since the driving time of the route passing through each waypoint is not exactly divided into 1 hour, it is divided into a distance having an approximate value before and after 1 hour.
  • the server may divide the calculated optimal path according to a criterion and provide the divided path to the user.
  • two types of methods may be considered.
  • the first method is a method in which the server provides a divided path to the user at a time
  • the second method is a method in which the server provides a path of the next step after one path is completed to the user.
  • a server provides a split path to a user at a time. After the server calculates an optimal path and splits the optimal path according to a user's request, the server may receive a split path from the user. Addresses can be provided. For example, if the optimal path consists of five divided paths, the server may provide the user with five addresses capable of receiving the five divided paths from the beginning. Users who have been provided with five addresses can access each address at the same time and receive each split path at once, or they can be provided by accessing an address that can receive the next split path before one split path is completed. have.
  • the server provides a split path of the next step after the split path is completed to the user. After the server calculates an optimal path and splits the optimal path according to a user's request, , One split warning to the user You can provide the next split path before the end of the furnace.
  • the server may first provide the user with the first split path. When providing the first split path, the server may deliver an indicator indicating that there is an additional split path along with the split path. The user can confirm that there are more splitting paths through the indicator. The user may request and receive the second divided path during the first divided path. Even when the second split path is provided, the server may deliver an indicator indicating that there are more split paths to the user. In this way the user can be provided with a subsequent split path.
  • the server may inform the user that the end of the optimal path includes an indicator indicating that there is no path to be provided anymore.
  • the first parameter is a parameter that indicates how many paths the server provides to the user when providing the optimal path in several parts (representing the divided path as "Subroute" when the divided optimal path is provided and divided). to be.
  • the server when the server provides the first trip (Trip) information to the user (terminal), the server should provide information on the first divided route. This may be provided as the following parameter.
  • the second parameter is a parameter that provides an indicator that there is an additional path in addition to the current user's path and a link to receive the path.
  • the second parameter may be provided when providing the route information for the defined trip to the user after the trip is defined.
  • the starting point and the destination of each divided route are the waypoints.
  • the start and destination of a divided route do not necessarily have to be waypoints.
  • the starting point and destination of the divided path can be any location pointed to by the server rather than a waypoint.
  • a method of reducing traffic and route information updates will be described. If a user has a stopover while driving, he / she may arrive at the stop and leave again after another day. For example, in the case of a courier service or a salesman, the user arrives at the waypoint and starts again after seeing the work. However, since the existing navigation service does not consider the time spent on arrival at the waypoint, there is no movement of the route during the time actually spent at the waypoint, so the road traffic information used in calculating the optimal route is It may be different from that. That is, since the traffic information change associated with the route of the user may occur during the time spent at the waypoint, the optimal route calculation may not be optimized in practice. This problem is described again with reference to FIG. 6 as follows.
  • FIG. 6 illustrates an optimal route reflecting time spent at each waypoint according to an embodiment of the present invention.
  • a route passing through waypoints B, C, D, E, and F is shown as a starting point, and the travel time between each waypoint and the time of stay at each waypoint are shown.
  • the total driving time is 239 minutes, and considering the time spent at the stop, the total driving time is 309 minutes, a difference of 70 minutes.
  • the server calculates the route if the driving route is long, the road traffic information to be applied to the route calculation differs depending on the frequency of updating the road traffic information. Can lose.
  • the server calculates the route the real-time road traffic information and the predicted road traffic information may be applied according to the driving time according to the length of the route.
  • the server For example, if the server generates the prediction road traffic information by the hour, and the driving time of the requested route is 2 hours or more, the real time traffic information is applied to the route to be moved for the first hour, and then 1 hour thereafter.
  • the route can be calculated by applying the predicted traffic information to the route to be moved. Therefore, it is difficult to apply the appropriate real-time and predicted road traffic information according to the above example because it is impossible to calculate the exact total driving time without considering the time spent at the waypoint as in the example above. In particular, when the distance, time and waypoints are large, these errors increase, thereby increasing the number of notifications of change of road traffic information.
  • an embodiment of the present invention allows the server to provide a dwell time at each waypoint when a user requests the server for an optimal route through multiple waypoints.
  • the proposed parameters are as follows.
  • the server can accurately estimate the travel time when calculating the optimum route, and can calculate the route by applying the real-time road traffic information and the predicted road traffic information better, and eventually change the road traffic information. It is possible to reduce the number of notifications of (Update).
  • the user may transmit various waypoint information to the server while the user requests an optimal route through the waypoints. Stopovers The information may be conveyed without considering the order of passage.
  • the server considers a plurality of waypoints as the optimal route based on current and predicted road traffic information, and delivers the order of passing through multiple waypoints to the user.
  • a user may request an optimal route through a plurality of waypoints while delivering a plurality of waypoint information to the server. At this time, the waypoint information is transmitted without considering the order of passing through the waypoint.
  • the server receiving the request may determine the order of passing through the plurality of waypoints by calculating an optimal route passing through the plurality of waypoints in consideration of current and predicted road traffic information.
  • the server delivers order information passing through waypoints to the user based on the result calculated in (2).
  • the user who receives the order information passing through the waypoints requests the server for route information or road traffic information to reach each waypoint according to the order information.
  • (Request for transit information of smart ND, request for route information of lightweight ND) For example, if a stopover order is received as shown in the table of FIG. 7 (3), the user may initially have a route from origin to point A ( Or traffic information). You can then request a route from point A to point D. In this way, the user can request and receive a route to point E. In this way, the way of requesting and receiving routes is the same as that of the existing DynNav service.
  • the server when a user requests a route through several waypoints, the server specifies and orders an order of passing through each waypoint. Based on this, the user requests and receives the route from one waypoint to the next waypoint to the server.
  • FIG. 2 relates to a scenario in which a DynNav application (hereinafter, referred to as a terminal) requests delivery of route information to a DynNav server (hereinafter, referred to as a server).
  • the main functions of this scenario are (1) delivery of the summary path and / or the full path, (2) subscription of the notification service, (3) reporting of the current location by the terminal, and (4) (a) the proposed path.
  • the user of the terminal defines a trip based on a departure point, a destination and other preferences, and these parameters are immediately transmitted by the terminal to the server.
  • the destination is defined using the third party's ID, in which case the server can obtain the third party's location via an external location application (server) and use the third party's location as the destination.
  • the server will respond with a set of routes that match the travel parameters taking into account real time and predicted road traffic information. For bandwidth optimization, paths are available on the server in two different formats, summary and total.
  • the terminal accesses the summary path: With this information the user of the terminal can select one path from the proposed set to be used for navigation.
  • the route to be delivered to the third party can be selected from the proposed routes.
  • the terminal may request the entire path for the selected path and delete the unused paths. Due to the limited length, the complexity of the trip and the network capabilities, the proposed routes can be encoded into the full route right from the start; In this case, the server does not need to encode the summary path. If this data is not available for the terminal in the road database, the terminal may request information from the server about the segment shape of the routes (WGS84 coordinate polygon).
  • the terminal updates traffic information (performance parameters and traffic events) for the route to be used for receiving an alternative route proposal when there is congestion along the route, and a third party ID is used as a destination. If your location changes, you can subscribe to notification services to receive updated information (updated destinations, additional segments or alternative routes).
  • the terminal will update its current location on the server after the vehicle (on which the terminal is mounted) has driven a certain distance. Using this information, the server will delete segments that have already traveled from the route to use (if not previously deleted by the terminal) and delete routes that are no longer compatible with the current location.
  • the user can bypass the usage path.
  • the terminal can upload its updated current location
  • the server Recognizing that the current location of the terminal is not compatible with the usage path the new path estimation may be performed based on the updated location information.
  • a new route identifier may be sent to the terminal in the current location update procedure (notification procedure for the new route is therefore not necessary).
  • the notification service will be automatically extended to the new proposal path (s).
  • the server informs the terminal of the updated traffic information on the usage route and the proposal of an alternative route, and the terminal can access known resources.
  • the server will automatically provide a notification service for the new proposal route if it is not deleted.
  • the server may notify the terminal of the updated information.
  • the types of updated information are (1) updated destinations (2) additional segments, (3) alternative routes.
  • the server may notify the updated information only when the terminal is near the destination according to the type of updated information.
  • the server may divide the predicted route (computed route) into several sub-paths in order to efficiently manage and update the route information. have. In this case, since the server can provide the sub paths sequentially, the terminal can retrieve the sub paths to be used sequentially.
  • the user can create a trip consisting of parameters related to the desired trip, namely, origin, destination and waypoint (s).
  • an indicator (routeForMultipleWaypoints) must be added to indicate requesting a route including the waypoint, in which case at least two waypoints Information should be added.
  • the user may further add a constraint on the requesting path. For example, the user may add a maximum time (TraveledTravellingTime) allowed for the route. For example, if a user is allowed up to four hours (240 minutes) to stop all the waypoints A through E from the point of origin (usually the current user's location), the user may add up to four hours as a condition of the route request. have.
  • the priority refers to the priority of each waypoint, which is input by the terminal and may be removed from the waypoint having a lower priority.
  • the user may set the time to stay at each waypoint at the route request, which must be taken into account when calculating the route by the server.
  • the server may divide the proposal route into a plurality of subroutes.
  • the server may inform the user how many partial paths the proposed path includes.
  • a reference path resource for the first partial path of the proposed path may be provided to the user.
  • the user may select one of the proposed plurality of summary paths and request or access the full path to it.
  • a user requests a server for a path including a plurality of waypoints, and the server provides the path as a plurality of divided paths
  • the user or terminal may access the divided path information instead of the entire path. .
  • the user In receiving the segmentation path, the user receives information about the first segmentation path from the server, a branch indicating whether there is a subsequent segmentation path, and if there is a subsequent segmentation path thereafter (ie, Second, path information including information on a reference (link) to the split path may be received.
  • step 3 is followed by a subsequent split path before the user arrives at the destination of the ongoing split path. It can be repeated to access the furnace. In addition, the process 3 may be repeated until it is indicated that there are no more splitting paths.
  • the terminal 810 may be referred to as a user, a user terminal, or an application in the user terminal
  • the server 820 may be referred to as one of a server, a server device, or an application in the server device, and the like.
  • the scope of the invention is not limited.
  • the terminal may request a route including a plurality of waypoints to the server (S81).
  • the request must include a starting point and a plurality of waypoints, the destination need not necessarily be specified. If a destination is not specified, one of the plurality of waypoints may be designated as a destination.
  • the request for indicating a route including the plurality of waypoints should be included in the request, and in this case, two or more waypoints should be included in the request.
  • the terminal may add an additional constraint when transmitting the request. For example, a maximum time for driving the route may be set. In this regard, priorities may be set for each waypoint. If the estimated time required to operate the route calculated by the server exceeds the set maximum time, at least one waypoint may be deleted according to the priority in the calculated route.
  • a time for staying at each waypoint may be set.
  • the time to stay at each waypoint is more likely to stay for a specific time at each waypoint and may require updating of current / predictive road traffic information by the specific time. It may be necessary to establish a more accurate path prediction.
  • the server may calculate a proposal path according to the request in S81 and transmit a voice answer including information on the proposal path to the terminal (S82).
  • At least one of the parameters described in Table 7, Table 8 and Table 12 is input when the terminal (or user) requests a route for a trip including a plurality of waypoints.
  • the server may calculate a proposal path based on the input parameter.
  • the answer may include information indicating how many divided paths the proposed path is divided into, and a reference link to the first divided path.
  • the terminal may request the first split path by accessing the reference link (S83).
  • the terminal may acquire information including the first split path from the server (S84).
  • the information may include reference links (if there is a second split path) for the first split path and the second split path.
  • the terminal may obtain a reference link for a specific split path and subsequent split paths from the server through a reference link. This may be repeated until there are no further split paths.
  • the plurality of divided paths may be sequentially transmitted and received at predetermined time intervals. Accordingly, the current / prediction road traffic information used to calculate each divided route may be road traffic information at different times, that is, the current / prediction road traffic information may be updated information at different times.
  • the terminal 910 may include a transceiver 911 configured to communicate with the server 920; and a processor 912 configured to obtain update information about the path based on information received from the server.
  • the server 920 includes a transceiver 921 configured to communicate with the terminal; And a processor 922 configured to generate update information about the path based on the information received from the terminal.
  • the terminal 910 is a lightweight ND, and the terminal includes a plurality of waypoints calculated by the server. It is configured to receive the path of.
  • the starting point of the route is the location of the terminal, and the destination is designated separately or determined as one of a plurality of waypoints.
  • the processor 912 may be configured to send a request for a route for a trip including the plurality of waypoints to a server.
  • the request may include information indicating requesting a route including the plurality of waypoints and the plurality of waypoint information.
  • the processor 912 is configured to perform the plurality of operations.
  • the server may be configured to receive information about the proposed route of the trip including a stopover from the server.
  • the proposed route of the trip is composed of a plurality of sub-paths so that the information on the proposed route indicates that the proposed route of the trip is composed of several sub-paths and the first sub-path of the sub-paths.
  • the processor 912 may be configured to receive information about the first subpath via a link to the first subpath.
  • the information on the first subpath may include an indicator indicating whether a second subpath following the first subpath exists and a link to the second subpath.
  • the processor 912 may be configured to receive information on the Nth subpath through a link to an N (N is an integer greater than or equal to 2) subpath.
  • the information on the N-th subpath may include an indicator indicating whether an N + 1th subpath exists and a link to the N + 1th subpath, and the N + 1th The link to the subpath may be included in the information on the Nth subpath when the N + 1th subpath exists.
  • the processor 912 may be configured to include a route condition in the request comprising at least one of a maximum allowable travel time of the route, a priority for each of the plurality of waypoints, or a time to stay at each of the plurality of waypoints. Can be.
  • the maximum allowable travel time and priority for each of the plurality of waypoints may be included at the same time.
  • At least one of the plurality of waypoints may be excluded according to the priority in the specific proposal route when the operation time of the specific proposal route calculated by the server exceeds the maximum allowable operation time.
  • the suggested route may be divided into a plurality of sub routes on the basis of a travel time requirement or a travel distance basis.
  • Each of the plurality of sub-paths may be calculated based on road traffic information at different points in time.
  • the processor 912 may be configured to receive each of the plurality of subpaths with a time difference.
  • the terminal requests the server for route information for visiting the plurality of waypoints, and in this case, the traveling distance or the traveling time of the route may be significantly large. . If a long path is provided and used as is, then managing and updating the path information is inefficient and may use more resources.
  • the server may divide the long path into several short paths (that is, sub or split paths) and provide short paths sequentially to efficiently manage and update the path information. Since each sub-path is provided to the terminal sequentially, the server may internally update route information not yet provided to the terminal according to changing traffic conditions. Thus, consumption of network resources will enjoy.
  • the server After the server calculates or predicts a route associated with the requested trip, if the travel distance or travel time of the route exceeds a certain threshold, the server transfers the predicted route to several sub routes. Can be divided. When the server generates sub routes, the original (total) route may be divided based on travel distance (eg every 20 km) or travel time (eg every 2 hours).
  • the server may provide the first sub route information to the terminal through the travel related information.
  • the terminal can then access the first subpath information.
  • the link of the second subpath is included in the first subpath information.
  • the terminal may access the second subpath information including the link of the third subpath. The terminal may repeat this procedure until it is indicated that an additional subpath no longer exists to access a subsequent subpath (that is, when the "additionalSubroute" parameter in the Route resource has a false value).
  • the present invention proposes a method for requesting and providing a route through several waypoints without a user specifying a destination, and also a notification of a change in alternative route and traffic information through the way of providing a route and providing time remaining at the waypoint.
  • the use of the network resources of the terminal can be reduced by reducing the number of notifications of alteration of alternate routes and traffic information.
  • the terminal or the server may perform a combination of one or two or more of the embodiments described above, it may be performed by combining or combining some of the embodiment (s).
  • Embodiments of the present invention are applicable to a navigation device or a server.

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Radar, Positioning & Navigation (AREA)
  • Remote Sensing (AREA)
  • General Physics & Mathematics (AREA)
  • Mathematical Physics (AREA)
  • Databases & Information Systems (AREA)
  • Navigation (AREA)
  • Traffic Control Systems (AREA)

Abstract

본 발명의 일 실시예에 따른 서버에 의해 계산된 복수의 경유지를 포함한 여행(trip)의 경로를 수신하기 위한 방법으로서, 상기 방법은 단말에 의해 수행되고, 상기 복수의 경유지를 포함한 여행에 대한 경로의 요청을 서버로 전송하는 단계, 상기 요청은 상기 복수의 경유지를 포함한 경로를 요청함을 나타내는 지시자 및 상기 복수의 경유지 정보를 포함하고, 상기 복수의 경유지를 포함한 여행의 제안 경로에 대한 정보를 상기 서버로부터 수신하는 단계를 포함하고, 상기 방법은 상기 여행의 제안 경로가 복수의 서브 경로로 구성되어, 상기 제안 경로에 대한 정보가 상기 여행의 제안 경로가 몇 개의 서브 경로로 구성되었음을 지시하는 정보 및 상기 서브 경로 중 첫번째 서브 경로에 대한 링크를 포함하면, 상기 첫번째 서브 경로에 대한 링크를 통해 상기 첫번째 서브 경로에 대한 정보를 수신하는 단계를 포함하고, 상기 첫번째 서브 경로에 대한 정보는 상기 첫번째 서브 경로에 후속하는 두번째 서브 경로가 존재하는지 여부를 지시하는 지시자 및 상기 두번째 서브 경로에 대한 링크를 포함할 수 있다.

Description

【명세서】
【발명의 명칭】
복수의 경유지를 포함한 최적 경로 전달 방법 및 이를 위한 장치 【기술분야】
[1] 본 발명은 경로를 전달하는 방법 및 이를 위한 장치에 관한 것으로, 좀 더 상세하게는 복수의 경유지를 포함한 경로를 전달하기 위한 방법 및 이를 위 한 장치에 관한 것이다.
【배경기술】
[2] 종래에는 내비게이션 (navigation) 단말이 GPS(Global Positioning System)와의 연결을 통해 현재 위치, 즉 출발지를 검출하고 사용자로부터 여행 의 목적지를 입력 받아 단말기 자체에서 경로를 계산하는 방식이 이용되었다. 그러나 최근 스마트폰의 보급과 성능 향상으로 이동통신망에서 PNDs(Personal Navigation Devices)를 이용해 교통 정보 및 경로 정보를 제공하는 서버로부터 경로 정보, 경로 관련 실시간 교통 정보 및 다양한 정보를 제공하는 서비스 방 식이 활용되고 있다.
[3] 특히, 다양한 형태의 내비게이션 서비스가 제공되는 가운데， 0MA(0pen Mobile Alliance) 표준화 단체에서는 기존의 방송형태로 정보가 제공되는 DMB(Digital Multimedia Broadcasting) 망에서 TPEGCTraffic Protocol Expert Group) 정보를 전달하는 방식이 아닌， 이동통신망이나 무선망의 IPUnternet Protocol) 기반 네트워크를 통해서 실시간 교통 정보를 P2P(Peer— to-Peer)로 전 달하는 다이내믹 내비게이션 인에이블러 (Dynamic Navigation Enabler, DynNav) 를 표준화하고 있다. 해당 표준에서는 스마트폰의 내비게이션 단말과 서비스의 형태를 크게 두 가지로 보고 있다. ―
[4] 첫 번째는 복잡한 경로 계산을 스마트폰에 탑재된 내비게이션 애플리케 이션에서 수행하지 않고， 교통 정보 및 경로 정보를 제공하는 서버에서 수행하 고 해당 경로를 상기 스마트폰에 전달하는 형태이다. 두 번째는 스마트폰의 성 능 향상으로 경로 계산을 스마트폰에 탑재된 애플리케이션 자체에서 수행하는 경우 또는 이동통신 모뎀을 장착한 내비게이션 단말기가 경로 계산을 하는 경우 로서 경로 정보를 교통 정보를 제공하는 서버가 전달하지 않고, 상기 단말이 계 산한 경로를 상기 서버에 등록하면 상기 경로와 관련된 실시간 교통 정보만을 기존의 방송의 형태가 아닌 IP 기반의 P2P로 상기 서버로부터 맞춤형으로 제공 받을 수 있는 형태이다.
[5] 도 1 은 내비게이션 장치에 대한 구분을 나타내고 있다. 내비게이션 장 치는 DMB와 같은 방송망을 통해 전달되는 TPEG기반의 교통 정보를 추가적으로 전달하는 형태 (110)， 이동통신망 또는 Wi-Fi 와 같이 IP 기반으로 교통 정보를 추가적으로 전달하는 형태 (120)， 그리고 다른 통신 매체와 연결 없이 GPS와 연 결을 통해 차량의 위치를 추적하여 경로 정보를 생성 및 제공하는 스탠드얼론 (Standalone) 형태 (130)로 구분할 수 있다.
[6] 또한， OMA LOC WG에서 현재 표준화 중인 DynNav는 위의 구분에서 IP기 반의 교통 정보를 전달하는 형태 (120)에 속하며, 좀더 상세하게는 P2P 형태로 전달하는 구분에 속하며, DynNav에서는 내비게이션 장치를 아래와 같이 2 가지 로 구분하고 있다.
[7] 1. 스마트 NEKSmart ND, 122)： 스스로 경로 계산이 가능하여 , DynNav서 버를 통해서 경로 정보를 수신하지 않고， 실시간 교통 정보만을 요청하는 장치 [8] 2. 경량 MXLightweight ND, 121)： 스스로 경로 계산이 불가능하여， DynNav서버를 통해 경로 정보를 포함한 모든 실시간 교통 정보를 요청하는 장 치
[9] 종래의 DynNav 시스템에서는 해당 교통 정보를 요청하고 전달하는 과정 을 RESTful 기반으로 전달하기 때문에， 다음과 같은 경로 정보 형식을 사용하고, 각 정보 형식은 XSD(XML Schema Definition)으로 정의가 가능하다.
[10] 1) Trip Structure (트립 구조): 최초 단말이 사용자로부터 경로 설정을 위한 전달된 정보로써 기본적으로 출발지와 목적지와 같은 정보를 획득한 후 해 당 정보를 서버에 전달한다. 트립 구조는 다수의 경로 구조에 해당하는 부분 집 합으로 이루어진다.
[11] 【표 1】
Figure imgf000004_0001
Figure imgf000005_0001
Figure imgf000006_0001
Figure imgf000007_0001
2) Route Structure (경로 구조): 트립 구조를 통해 계산된 전체 경로를 하는 방식으로 경로 구조는 여러 개의 세그먼트로 표현된다.
【표 2】
Figure imgf000007_0002
Figure imgf000008_0001
Figure imgf000009_0001
[14] 3) Segment Structure: 각 세그먼트를 표현하는 구조체로 각 세그먼트의 길이 뿐만 아니라 해당 세그먼트에 해당되는 실시간 교통 상황을 (TPEG)의 표현 기반으로 정의할 수 있다.
[15] 【표 3】
Figure imgf000009_0002
Figure imgf000010_0001
Figure imgf000011_0002
4) Subscription List Structure ： 가입 (subscript ion)의 리스트를 나타
Figure imgf000011_0001
【표 4】
Figure imgf000011_0003
included in POST requests by the client, but MUST be included in POST requests representing notifications by the server to the client, when a com lete
represent at ion of the resource is embedded in the notification. The resourceURL MUST be also included in responses to any HTTP method that returns an entity body, and in I I PUT requests . )
[18] 5) Subscription structure: 가입
[19] 【표 5】
Figure imgf000012_0001
Figure imgf000013_0001
[20] 도 2 는 종래 DynNav 시스템에서 경량 ND Lightweight ND)의 동작을 도 시한 흐름도이다. 경량 ND 는 자체의 성능 (Capability)이 경로 계산을 지원하지 않기 때문에, 서버로 경로 정보를 요청하고 서버로부터 경로 정보를 수신해야 한다. 대표적인 기능은 다음과 같다.
[21] - 경량 ND가 서버의 경로 계산을 위한 여행 (Trip) 정보를 서버로 전달 [22] - 경량 ND 가 서버에 의해 계산된 경로 (추천 경로 포함)의 세트 (set)를 서버로부터 수신
[23] - 경량 ND 가 서버로부터 실시간 교통 정보 통보 (Notification) 서비스 를 수신하기 위해 서비스 가입 (Subscript ion)
[24] 도 2에 도시된 흐름도의 대략적인 내용은 다음과 같다.
[25] 1. 애플리케이션의 사용자는 여행 파라미터 (journey parameter)들을 정 의하고 상기 애플리케이션은 상기 파라미터들을 서버로 전송한다: 상기 서버는 관련 교통 (traffic) 정보를 이용하여 수신된 파라미터에 기반하여 일 세트의 제 안 경로들을 계산한다. 상기 서버는 상기 애플리케이션에 상기 제안 경로들의 경로 식별자들을 포함한 생성된 "트립 (trip)" 리소스로 응답한다.
[26] 2. 상기 애플리케이션은 요약된 포맷 (summarized format)의 상기 일 세 트의 경로들에 액세스한다. 이 단계는 상기 서버에 의해 제안된 모든 경로들에 대해 반복된다. 그러나, 만약 상기 트립의 길이 및 복잡도가 제한되거나 네트워 크 품질이 부적절하면， 전체 포맷 (full format) 경로 정보가 이 단계에서 사용 될 수 있다. 상기 애플리케이션은 상기 제안된 경로들에 대한 쉐이프 (shape) 정 보 (WGS84 좌표 폴리라인)가 내비게이션 장치에서 이용가능하지 않은 경우 이를 요청할 수 있다.
[27] 3. 상기 사용자는 상기 제안된 세트 중에서 하나의 경로를 선택하고， 상 기 애플리케이션은 상기 사용자가 선택한 경로에 대한 전체 포맷 정보에 액세스 한다. 상기 애플리케이션은 상기 제안된 경로들에 대한 쉐이프 (shape) 정보 (WGS84 좌표 폴리라인)가 내비게이션 장치에서 이용가능하지 않은 경우 이를 요 청할 수 있다. 만약 단계 2 에서， 상기 전체 포맷 경로가 획득되면， 이 단계는 필요하지 않다. 상기 서버는 상기 선택된 경로 정보를 관련 교통 정보와 함께 응답한다. [28] 4. 상기 애플리케이션은 제공된 교통 이벤트 리소스들에 대한 링크들을 사용하여 상기 경로와 관련된 교통 이벤트들에 액세스한다. 상기 교통 이벤트들 에 대한 액세스는 상기 사용자에 의해 선택된 카테고리들에 제한될 수 있다.
[29] 5. 상기 애플리케이션은 상기 서버에 의해 이전에 제안되었으나 상기 사 용자에 의해 선택되지 않은 불필요한 경로들을 제거한다.
[30] 6. 상기 애플리케이션은 상기 트립 (경로 (들) )에 대한 통지 서비스에 가 입 (subscript ion)을 생성하도록 상기 서버에 요청한다. 상기 애플리케이션은 다 음의 이벤트들에 대해 상기 서버에 의해 통지된다:
[31] a. 상기 트립에 관련된 모든 경로들에 대한 퍼포먼스 파라미터들 업데이 트 및 새로운 트래픽 이벤트들 (선택된 카테고리들에 대한)
[32] b. 사용할 경로들에 따른 교통 문제로 인한 대안 경로들의 제안
[33] c 상기 트립의 목적지가 제 3자의 위치이고 상기 제 3자의 위치가 변경 된 경우， 갱신된 목적지 및 /또는 상기 제 3자로의 경로. 이 정보의 통지를 가능 하게 하기 위해 상기 애플리케이션은 상기 통지의 가입에서 상기 서버에 의한 상기 제 3자의 위치의 추적 절차를 요청해야함
[34] 7. (상기 애플리케이션이 탑재된) 차량이 사용하고 있는 경로를 벗어나 거나 우회하는 경우; 상기 애플리케이션은 트립 리소스의 출발지 파라미터를 수 정한다. 상기 서버는 현재 위치가사용하고 있는 상기 경로에 속하지 않다고 인 식하고 새로운 출발지를 이용하여 새로운 경로를 계산한다. 상기 서버는 상기 새로운 경로의 식별자로 웅답하고， 이전의 경로 (및 식별자)를 삭제한다. 상기 수정된 출발지 파라미터가 상기 이전의 경로에 속하는 경우， 상기 서버는 상기 경로로부터 이미 운행된 세그먼트를 삭제하기 위해 이 정보를 사용한다.
[35] - 상기 단계 7 은 상기 차량이 우회하거나 경로를 벗어난 경우 그리고 상기 차량이 이전에 보고된 지점으로부터 특정 거리만큼 이동한 경우 그리고 /또 는 상기 차량이 상기 서버가 현재 위치를 업로드하라고 요청한 세그먼트에 진입 한 경우에 발생한다.
[36] 8. 상기 서버는 상기 갱신된 트래픽 정보 (트래픽 이벤트들 및 퍼포먼스 파라미터들)를 포함한 트립 및 경로를 포함한, 변경된 리소스들에 대한 링크들 을 이용하여 상기 애플리케이션으로 통지 리소스를 전달한다. [37] 8. 상기 애플리케이션은 퍼포먼스 파라미터들 및 교통 이벤트들과 함께 상기 새로운 제안 경로에 액세스한다. 상기 애플리케이션이 상기 트립 리소스에 대한 통지 서비스에 가입했기 때문에， 상기 가입은 상기 새로운 제안 경로를 커 버할 것이다.
[38] 9. 상기 제안된 경로들 상의 트래픽 이벤트들, 심각한 정체 및 /또는 상 기 제 3자의 위치 변경이 상기 서버에 의해 검출되면， 상기 서버는 갱신된 정보 의 URLCUniform Resource Locator)를 사용하여 통지한다.
[39] 10. 상기 애플리케이션은 사용하고 있는 상기 경로에 대한 갱신 정보， 새로운 관련된 교통 이벤트들 및 상기 제안된 대안 경로에 액세스하고， 상기 통 지 서비스의 가입이 상기 트립과 관련된 모든 경로들을 포함하기 때문에， 상기 통지는 상기 제안된 대안 경로에 까지 확장된다. 상기 제 3 자의 위치가 변경된 경우， 상기 애플리케이션은 목적지로서 상기 변경된 제 3 자의 위치 및 /또는 상 기 갱신된 경로 리소스에 액세스한다.
[40] 한편， 이러한 경량 ND 서비스에서， 사용자가 하나 이상의 경유지를 포함 하는 경로를 요청할 필요가 종종 발생한다. 예컨대, 내비게이션 서비스에 대한 좀더 다양한 서비스 제공 사용자 만족도 /경험 향상 등을 위해 하나 이상의 경 유지를 포함한 경로가 요청되고 이를 서버 측에서 제공하는 방안이 고려된다. 예컨대， 사용자가 일정 시간 내에 여러 지리적 장소를 방문해야 해서 경로 요청 시에 여러 경유지를 입력할 수 있다.
[41] 아울러， 이러한 하나 이상의 경유지를 포함하는 경로를 요청 또는 제공 하는 방안은 상기 경로의 경유지가 하나 이상이므로, 몇 가지 중요하게 고려할 사항이 있다. 본 명세서에서는 이러한 하나 이상의 경유지를 포함한 경로흩 제 공하는 방안과 그에 수반되는 몇 가지 문제를 해결하기 위한 구체적인 방안을 제안하고자 한다.
【발명의 상세한 설명】
【기술적 과제】
[42] 본 발명에서는 위에서 언급한 하나 이상의 경유지를 포함한 경로를 제공 하는 서비스의 형태에서 발생하는 문제점을 해소하기 위한 방식을 제안하는 것 을 주요 목적으로 한다. [43] 본 발명에서 이루고자 하는 기술적 과제들은 상기 기술적 과제로 제한되 지 않으며， 언급하지 않은 또 다른 기술적 과제들은 아래의 기재로부터 본 발명 이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.
【기술적 해결방법】
[44] 본 발명의 일 실시예에 따른 서버에 의해 계산된 복수의 경유지를 포함 한 여행 (trip)의 경로를 수신하기 위한 방법으로서， 상기 방법은 단말에 의해 수행되고， 상기 복수의 경유지를 포함한 여행에 대한 경로의 요청을 서버로 전 송하는 단계 - 상기 요청은 상기 복수의 경유지를 포함한 경로를 요청함을 나타 내는 지시자 및 상기 복수의 경유지 정보를 포함함-， 및 상기 복수의 경유지를 포함한 여행의 제안 경로에 대한 정보를 상기 서버로부터 수신하는 단계를 포함 하고, 상기 방법은 상기 여행의 제안 경로가 복수의 서브 경로로 구성되어， 상 기 제안 경로에 대한 정보가 상기 여행의 제안 경로가 몇 개의 서브 경로로 구 성되었음을 지시하는 정보 및 상기 서브 경로 중 첫번째 서브 경로에 대한 링크 를 포함하면， 상기 첫번째 서브 경로에 대한 링크를 통해 상기 첫번째 서브 경 로에 대한 정보를 수신하는 단계를 포함하고， 상기 첫번째 서브 경로에 대한 정 보는 상기 첫번째 서브 경로에 후속하는 두번째 서브 경로가 존재하는지 여부를 지시하는 지시자 및 상기 두번째 서브 경로에 대한 링크를 포함할 수 있다.
[45] 바람직하게는, 상기 방법은 N(N>2)번째 서브 경로에 대한 링크를 통해 상기 N번째 서브 경로에 대한 정보를 수신하는 단계를 더 포함할 수 있다ᅳ
[46] 바람직하게는， 상기 N번째 서브 경로에 대한 정보는 N+1번째 서브 경로 가 존재하는지 여부를 지시하는 지시자 및 상기 N+1 번째 서브 경로에 대한 링 크를 포함하고， 상기 N+1 번째 서브 경로에 대한 링크는 상기 N+1 번째 서브 경 로가 존재하는 경우에 상기 N번째 서브 경로에 대한 정보에 포함될 수 있다.
[47] 바람직하게는， 상기 요청은 상기 경로의 최대 허용 운행 시간， 상기 복 수의 경유지 각각에 대한 우선순위 또는 상기 복수의 경유지 각각에서 머무를 시간 중 적어도 하나로 구성된 경로 조건을 포함하고， 상기 제안 경로는 상기 경로 조건에 기반하여 계산될 수 있다. [48] 바람직하게는， 상기 서버에 의해 계산된 특정 제안 경로의 운행 소요 시 간이 상기 최대 허용 운행 시간을 초과하는 경우, 상기 특정 제안 경로에서 상 기 우선순위에 따라상기 복수의 경유지 중 적어도 하나가 제외될 수 있다.
[49] 바람직하게는， 상기 제안 경로는 운행 소요 시간 기준 또는 운행 거리 기준으로 복수의 서브 경로로 분할될 수 있다.
[50] 바람직하게는， 상기 복수의 서브 경로 각각은 서로 다른 시점의 도로 교 통 정보에 기반할 수 있다.
[51] 바람직하게는， 상기 복수의 서브 경로 각각은 시간 차이를 두고 수신될 수 있다.
[52] 본 발명의 일 실시예에 따른 서버에 의해 계산된 복수의 경유지를 포함 한 여행 (trip)의 경로를 단말에게 제공하기 위한 방법으로서， 상기 방법은 서버 에 의해 수행되고， 상기 복수의 경유지를 포함한 여행에 대한 경로의 요청을 상 기 단말로부터 수신하는 단계 - 상기 요청은 상기 복수의 경유지를 포함한 경로 를 요청함을 나타내는 정보 및 상기 복수의 경유지 정보를 포함함 - 상기 복수 의 경유지를 포함한 여행의 제안 경로를 계산하는 단계; 및 상기 제안 경로에 대한 정보를 상기 단말로 전송하는 단계를 포함하고, 상기 여행의 제안 경로가 복수의 서브 경로로 구성되어， 상기 제안 경로에 대한 정보가 상기 여행의 제안 경로가 몇 개의 서브 경로로 구성되었음을 지시하는 정보 및 상기 서브 경로 중 첫번째 서브 경로에 대한 링크를 포함하면， 상기 단말은 상기 첫번째 서브 경로 에 대한 링크를 통해 상기 첫번째 서브 경로에 대한 정보를 수신하도록 구성되 며， 상기 첫번째 서브 경로에 대한 정보는 상기 첫번째 서브 경로에 후속하는 두번째 서브 경로가 존재하는지 여부를 지시하는 지시자 및 상기 두번째 서브 경로에 대한 링크를 포함할 수 있다.
[53] 바람직하게는， N(N>2)번째 서브 경로에 대한 링크를 통해 상기 N 번째 서브 경로에 대한 정보가 상기 단말로 제공될 수 있다.
[54] 바람직하게는, 상기 N번째 서브 경로에 대한 정보는 N+1번째 서브 경로 가 존재하는지 여부를 지시하는 지시자 및 상기 N+1 번째 서브 경로에 대한 링 크를 포함하고， 상기 N+1 번째 서브 경로에 대한 링크는 상기 N+1 번째 서브 경 로가 존재하는 경우에 상기 N번째 서브 경로에 대한 정보에 포함될 수 있다. [55] 바람직하게는， 상기 요청은 상기 경로의 최대 허용 운행 시간, 상기 복 수의 경유지 각각에 대한 우선순위 또는 상기 복수의 경유지 각각에서 머무를 시간 중 적어도 하나로 구성된 경로 조건을 포함하고, 상기 제안 경로는 상기 경로 조건에 기반하여 계산될 수 있다.
[56] 바람직하게는， 상기 서버에 의해 계산된 특정 제안 경로의 운행 소요 시 간이 상기 최대 허용 운행 시간을 초과하는 경우, 상기 특정 제안 경로에서 상 기 우선순위에 따라 상기 복수의 경유지 중 적어도 하나가 제외될 수 있다.
[57] 바람직하게는， 상기 제안 경로는 운행 소요 시간 기준 또는 운행 거리 기준으로 복수의 서브 경로로 분할될 수 있다.
[58] 바람직하게는， 상기 복수의 서브 경로 각각은 서로 다른 시점의 도로 교 통 정보에 기반할 수 있다.
[59] 바람직하게는， 상기 복수의 서브 경로 각각은 시간 차이를 두고 제공될 수 있다.
[60] 본 발명의 일 실시예에 따른 서버에 의해 계산된 복수의 경유지를 포함 한 여행 (trip)의 경로를 수신하도록 구성된 단말로서， 서버와 통신하도록 구성 된 송수신기; 및 상기 서버로부터 수신되는 정보에 기반하여 상기 경로에 대한 갱신 정보를 획득하도특 구성된 프로세서를 포함하고, 상기 프로세서는 상기 복 수의 경유지를 포함한 여행에 대한 경로의 요청을 서버로 전송하고， 상기 요청 은 상기 복수의 경유지를 포함한 경로를 요청함을 나타내는 정보 및 상기 복수 의 경유지 정보를 포함하고, 상기 복수의 경유지를 포함한 여행의 제안 경로에 대한 정보를 상기 서버로부터 수신하도톡 구성되며， 상기 여행의 제안 경로에 대한 정보가 상기 여행의 제안 경로가 몇 개의 서브 경로로 구성되었음을 지시 하는 정보 및 상기 서브 경로 중 첫번째 서브 경로에 대한 링크를 포함하면， 상 기 프로세서는 상기 첫번째 서브 경로에 대한 링크를 통해 상기 첫번째 서브 경 로에 대한 정보를 수신하도록 구성되고， 상기 첫번째 서브 경로에 대한 정보는 상기 첫번째 서브 경로에 후속하는 두번째 서브 경로가 존재하는지 여부를 지시 하는 지시자 및 상기 두번째 서브 경로에 대한 링크를 포함할 수 있다.
[61] 본 발명의 일 실시예에 따른 서버에 의해 계산된 복수의 경유지를 포함 한 여행 (trip)의 경로를 단말에게 제공하도록 구성된 서버로서, 단말과 통신하 도록 구성된 송수신기; 및 상기 단말로부터 수신되는 정보에 기반하여 상기 경 로에 대한 갱신 정보를 생성하도록 구성된 프로세서를포함하고， 상기 프로세서 는 상기 복수의 경유지를 포함한 여행에 대한 경로의 요청을 상기 단말로부터 수신하고， 상기 요청은 상기 복수의 경유지를 포함한 경로를 요청함을 나타내는 정보 및 상기 복수의 경유지 정보를 포함하고 ; 상기 복수의 경유지를 포함한 여 행의 제안 경로에 대한 정보를 상기 단말로 전송하도록 구성되고， 상기 여행의 제안 경로가 복수의 서브 경로로 구성되어, 상기 제안 경로에 대한 정보가 상기 여행의 제안 경로가 몇 개의 서브 경로로 구성되었음을 지시하는 정보 및 상기 서브 경로 중 첫번째 서브 경로에 대한 링크를 포함하면 상기 단말은 상기 첫 번째 서브 경로에 대한 링크를 통해 상기 첫번째 서브 경로에 대한 정보를 수신 하도록 구성되며, 상기 첫번째 서브 경로에 대한 정보는 상기 첫번째 서브 경로 에 후속하는 두번째 서브 경로가 존재하는지 여부를 지시하는 지시자 및 상기 두번째 서브 경로에 대한 링크를 포함할 수 있다.
[62] 상기 기술적 해결방법들은 본 발명의 실시예들 중 일부에 불과하며， 본 원 발명의 기술적 특징들이 반영된 다양한 실시예들이 당해 기술분야의 통상적 인 지식을 가진 자에 의해 이하 상술할 본 발명의 상세한 설명을 기반으로 도출 되고 이해될 수 있다.
【유리한 효과】
[63] 본 발명의 실시예에 따르면 내비게이션 장치 (또는 애플리케이션)와 서버 간에 발생할 수 있는 불필요한 데이터 전송 및 전달을 줄이고， 이를 통해 서비 스 품질 및 /또는 사용자의 서비스 경험 (QoE: Quality of Experience)을 높일 수 있다.
【도면의 간단한 설명】
[64] 본 발명에 관한 이해를 돕기 위해 상세한 설명의 일부로 포함되는 첨부 도면은 본 발명에 대한 실시예를 제공하고, 상세한 설명과 함께 본 발명의 기술 적 사상을 설명한다.
[65] 도 1은 내비게이션 장치에 대한 구분을 나타낸다.
[66] 도 2 는 종래 DynNav 시스템에서 경량 MXLight weight ND)의 동작을 도 시한 흐름도이다.
[67] 도 3는 본 발명의 내비게이션 시스템인 IP기반의 DynNav시스템 전반을 설명하기 위한 네트워크 구성도이다. [68] 도 4는 TPEG의 계충 구조를 나타낸다.
[69] 도 5 는 본 발명의 일 실시예에 따른 복수의 경유지를 포함한 경로를 예 시한다.
[70] 도 6 은 본 발명의 일 실시예에 따른 각각의 경유지에서 머무르는 시간 을 고려한 복수의 경유지를 포함한 경로를 예시한다.
[71] 도 7 은 본 발명의 일 실시예에 따른 분할 경유지 정보 제공 방안에 대 한 예시이다.
[72] 도 8은 본 발명의 일 실시예에 따른 동작을 예시한다.
[73] 도 9 는 본 발명의 실시예들이 구현될 수 있는 장치의 블록도를 나타낸 다.
【발명의 실시를 위한 형태】
[74] 이하, 본 발명에 따른 바람직한 실시 형태를 첨부된 도면을 참조하여 상 세하게 설명한다. 첨부된 도면과 함께 이하에 개시될 상세한 설명은 본 발명의 예시적인 실시형태를 설명하고자 하는 것이며， 본 발명이 실시될 수 있는 유일 한 실시형태를 나타내고자 하는 것이 아니다. 이하의 상세한 설명은 본 발명의 완전한 이해를 제공하기 위해서 구체적 세부사항을 포함한다. 그러나， 당업자는 본 발명이 이러한 구체적 세부사항 없이도 실시될 수 있음을 안다.
[75] 몇몇 경우, 본 발명의 개념이 모호해지는 것을 피하기 위하여 공지의 구 조 및 장치는 생략되거나， 각 구조 및 장치의 핵심기능을 중심으로 한 블록도 형식으로 도시될 수 있다. 또한, 본 명세서 전체에서 동일한 구성요소에 대해서 는 동일한 도면 부호를 사용하여 설명한다.
[76] 한편， 본 명세서에서 사용되는 용어에 대하여 정의하고자 한다.
[77] 애플리케이션 (Application)
[78] 본 명세서에서 애플리케이션은 사용자 대신에 업무를 수행하는 잘—정의 되었으나 표준화되지 않은 기능들의 세트의 구현을 의미한다. 상기 애플리케이 션은 소프트웨어 및 /또는 하드웨어 요소들 그리고 연관된 사용자 인터페이스들 로 이루어질 수 있다 (An implement at ion of a well— defined but not standardized set of functions that performs work on behalf of the user . It may consist of software and/ or hardware elements and associated user interfaces . ) . [79] 서버 (Server)
[80] 일반적으로 본 발명이 속하는 기술 분야에서, 서버는 요청들에 웅답하여 클라이언트들에게 자원들을 제공하는 엔티티에 해당한다 (An entity that provides resources to Clients in response to requests. ) .
[81] 클라이언트 (Client)
[82] 일반적으로 본 발명이 속하는 기술 분야에서, 클라이언트는 서비스의 수 신자로서 동작하는 디바이스， 사용자 에이전트 또는 다른 엔티티에 해당한다 (A device, user agent , or other entity that acts as the receiver of a service. )
[83] DynNav애플리케이션 (DynNav Application)
[84] 본 명세서에서 DynNav는 최적의 경로 (들) , 실 -시간 및 미래에 예상되는 교통 정보 및 보조 데이터를 얻기 위해 DynNav 서버와 상호작용할 책임을 지닌 엔티티에 해당한다 (An entity that is in charge of interacting with a DynNav Server to get optimal route(s) , real-time and forecasted traffic information and complimentary data.). 따라서， 상기 DynNav 애플리케이션은 스마트폰, 모바일 폰， 네이게이션 디바이스 등을 포함하는 단말에 탑재되며， 이 에 따라 본 명세서에서 상기 DynNav 애플리케이션은 단말과 상호교환 가능하게 지칭될 수 있다. 이러한 측면에서， 상기 DynNav 애플리케이션은 클라이언트의 일종에 해당한다. 본 발명에서는 DynNav 애플리케이션을 소스 단말 또는 목적 단말, 혹은 그냥 "단말" 이라고 명칭 한다. 소스 단말은 목적 단말 위치 기반 경로 설정 서비스를 요청하는 단말을 목적 단말은 해당 서비스에서 목적지가 되 는 개체를 의미한다.
[85] DynNav서버 (DynNav Server)
[86] 본 명세서에서 DynNav서버는 상기 애플리케이션에 최적의 경로 (들) , 실 -시간 및 미래에 예상되는 교통 정보 및 보조 데이터를 제공할 책임을 지닌 엔 티티에 해당한다 (An entity that is in charge of providing to the application optimal route(s) , real-time and forecasted traffic information, and complimentary data.). 이러한 측면에서， 상기 DynNav 서버는 상기 서버의 일종에 해당한다. 본 발명에서는 상기 DynNav서버를 "교통 정보 서버" 또는 단순히 "서버" 로 지칭한다. [87] 위치 URI (Location U I)
[88] 본 명세서에서, 위치 URI 는 위치를 획득하는 프로토콜을 이용하여 디바 이스의 현재 위치가 특정 위치 서버로부터 획득되도록 하는 URI 에 해당한다 (A URI that enables the current location of a device to be obtained from a particular location server using a particular dereferencing protocol.).
[89] 내비게이션 디바이스 (Navigation Device (ND))
[90] 본 명세서에서， 내비게이션 디바이스는 GNSS(Global Navigation Satellite System) 서비스를 이용하여 최종 목적지에 도달하기 위해 올바른 경 로를 보여주는 운전자를 보조하는 엔티티에 해당한다. 이 엔티티는 사용자 선호 도에 따라 실 -시간 및 예측된 교통 정보를 처리하고 최적의 경로를 동적으로 추 정할 수 있다 (An entity that , using GNSS service, assists the driver showing correct route to reach the final destination. This entity may process real—time and predicted traffic information and dynamically estimates the optimal route, according to user preferences . )
[91] 경량 MXLightweight: ND)
[92] 본 명세서에서, 경량 ND 는 경로 계산을 위한 기능이 없으며, 서버로부 터 계산된 경로를 요청 및 수신하는 내비게이션 디바이스를 의미하며， 로컬 맵 데이터베이스가 이용 가능하지 않으면, 경로 예측 기능들을 위해 그리고 도로 모양 (shape) 표현을 검색하기 위해 서버에 액세스하는 내비게이션 디바이스에 해당한다 (A navigation device that accesses to a server for route estimation functionalities and for retreiving roads shape representation, if not available in a local map database) .
[93] 스마트 ND(Smart ND)
[94] 본 명세서에서， 스마트 ND는 디바이스 자체에서 이용 가능한 도로 네트 워크 데이터베이스를 이용하여， 경로 (들)를 계산할 수 있는 내비게이션 디바이 스에 해당한다 (A navigation device that is able to calculate the route(s) , using a roads network database available on the device itself. ) .
[95] 관심 포인트 (Point Of Interest; POD [96] 본 명세서에서, 관심 포인트는 이름, 카테고리, 고유 식별자 또는 시내 주소와 같은 위치들에 관한 정보를 설명한다 (POI describes information about locations such as name, category, unique identifier, or civic address. ) .
[97] 세그먼트 (Segment)
[98] 도로를 구분하는 단위로 일반 도로에서는 교차로와 교차로 사이의 연속 된 도로를 세그먼트라 하고, 고속도로에서는 각 고속도로의 정책에 따라 도로를 나누어 세그먼트라고 정의된다. 이러한 세그먼트 단위로 교통의 정체나 통과 시 간 등이 결정될 수 있다. 본 명세서에서는 세그먼트를 도로 구간과 상호호환 가 능하게 사용한다.
[99] 세그먼트 시퀀스 (Segment Sequence)
[100] 하나 이상의 연속된 세그먼트들의 집합을 지칭한다. 필요에 따라， 하나 의 세그먼트로 구성된 세그먼트 시퀀스도 가능하다. 또한， 예컨대 둘 이상의 세 그먼트들로 구성된 세그먼트 시퀀스는 첫 번째 세그먼트의 종료 포인트가 두 번 째 세그먼트의 시작 포인트와 동일하다.
[101] 폴리라인 (Polyline)
[102] 본 명세서에서 폴리라인은 각 세그먼트의 끝 지점들을 특정함으로써 정 의된， 하나 이상의 선 세그먼트들로 구성된 그래픽 컴퓨팅에 사용되는 연속 선 에 해당한다 (A continuous line used in graphic computing composed of one or more line segments , defined by specifying the endpoints of each segment).
[103] 경로 정보 (Route Information)
[104] 본 명세서에서， 경로 정보는 정의된 출발지에서 목적지까지의 세그먼트 의 집합 및 보조 데이터의 좌표들 정보에 해당한다 (Information which coordinates of segment end points and complimentary data from the defined origin and the destination) .
[105] 교통 정보 (Traffic Information)
[106] 본 명세서에서, 교통 정보는 영역 또는 경로와 관련된 교통 이벤트들 및 네트워크 퍼포먼스 파라미터들로 구성된 정보쎄 해당한다 (Information which consists of traffic events and network performance parameters related to an area or a route.). 또한， 상기 교통 정보는 현재 또는 앞으로 발생할， 즉 미래의 교통 정보를 포함할 수 있다. [107] 교통 이벤트 (Traffic Event)
[108] 본 명세서에서， 교통 이벤트는 도로 네트워크 운영자에 의해 부과되거나 계획된 영역 또는 경로에 관련된 이벤트들 (즉， 도로 폐쇄를 유발하는 도로 공사 들) 또는 상기 네트워크 운영자의 제어 외적으로 발생하는 이벤트들 (즉, 사고 들)에 관한 정보에 해당한다 (Information regarding event s related to an area or a route that are either imposed or planned by the road network operator (i.e. road works leading to lane closures) or event s that occur outside the control of the network operator (i.e. accidents)) .
[109] 네트워크 퍼포먼스 파라미터 (Network Performance Parameter)
[110] 본 명세서에서， 네트워크 퍼포먼스 파라미터는 영역 또는 경로에 존재하 는 각 세그먼트들의 퍼포먼스 또는 교통 흐름 (즉， 속도， 지연 및 소요 시간)에 관한 정보에 해당한다 (Information regarding the performances (i.e. speed , delay and travel time) of road segments related to an area or a route. ) .
[Ill] 전체 경로 정보 (Route Information in Full Format)
[112] 출발지에서 목적지까지의 모든 세그먼트를 포함하는 경로 정보의 한 형 태를 의미한다. 별도의 언급이 없는 경우 경로 정보는 전체 경로를 의미한다.
[113] 요약 경로 정보 (Route Information in Summarized Format )
[114] 출발지에서 목적지까지의 모든 세그먼트 중 정보의 요약을 위해 선택된 세그먼트 (선택하는 방식은 본 발명에서 다루지 않는다)만을 포함하는 경로 정 보의 한 형태를 의미한다.
[115] 최근 스마트폰의 활발한 보급과 더불어 기존의 DMB 방송망을 이용하던 형식에서 벗어나 이동통신 단말기로 이동 경로를 제공하는 내비게이션 서비스가 보편화되고 있으며， 0MA L0C WG 에서는 위와 같은 서비스를 DynNav(Dynamic Navigation)이라 칭한다.
[116] 본 명세서에서 내비게이션 장치라 함은 경로 안내 기능을 수행할 수 있 는 장치를 지칭하며, 상기 내비게이션 장치는 스마트폰 모바일폰， 모바일 디바 이스， 램톱， 태블릿 PC, 스마트패드 등 휴대 가능하거나 휴대 가능한 물체에 부 착 가능한 모든 전자적 장치를 포함한다.
[117] 도 3은 본 발명의 내비게이션 시스템인 IP기반의 DynNav 시스템 전반을 설명하기 위한 네트워크 구성도이다. 도 3 에 도시한 바와 같이， 본 발명의 내 비게이션 시스템은 이동통신망 접속이 가능한 내비게이션 장치 (Navigation Device, ND), 무선 송수신을 위한 이동통신망, 교통 정보를 제공하기 위해 교통 정보 수집 장치 및 교통 정보 및 경로 정보 제공 서버 (DynNav Server) 및 내비 게이션 장치의 위치 획득을 위한 보조 데이터 (Assistance Data)를 생성하고 전 달하는 위치서버를 포함할 수 있다.
[118] 표현의 간략함을 위해서, 본 명세서에서 교통 정보 제공 서버 또는 DynNav서버는 "서버 "로 표현하고， 내비게이션 장치는 "단말 "ND" 또는 각 단 말의 능력에 따른 "Smart ND"나 "Lightweight ND"라고 표현한다.
[119] 본 발명에서 단말 (위의 언급한 바와 같이 2 개의 단말 형태로 구분 가능 함)은 도면에 도시한 것과 같이 이동통신망 또는 Wi-Fi 등의 IP 망과 연결이 가 능하며， 경로 안내를 위한 내비게이션 애플리케이션을 구비하고 있으며， 해당 애플리케이션은 서버에 접속하여 경로 안내 데이터와 실시간 교통 정보를 수신 하여 경로를 안내할 수 있다. 한편， 도면에 별도로 도시 하지는 않았으나 경로 계산이 자체적으로 가능한 단말은 서버로부터 경로 안내 데이터를 수신하지 않 고， 실시간 교통 정보만을 선택적으로 수신할 수 있다.
[120] 여기에서 실시간 교통 정보라 함은 DynNav서버에서 계산되어 단말에 전 달되는 최적의 경로 정보， 실시간 및 예측 교통 정보, POKPoint of Interest) 와 날씨와 같은 교통과 연관된 부가 정보를 의미한다. 또한， 표현의 중복을 제 거하기 위해 내비게이션 애플리케이션， 단말 또는 사용자를 통합하여 단말이라 고 표현한다. 따라서， 본 명세서에서 "단말 "， "ND" , "Smart ND" , "Lightweight ND," "내비게이션 애플리케이션 "사용자" 그리고 이들과 동등한 개념의 용 어 등은 모두 "단말"로 지칭될 수 있다.
[121] 위에서 언급한 실시간 교통 정보는 ISO 표준화 단체에서 추진되고 있는 TPEGCTransport Protocol Experts Group)을 통해서 표현될 수 있다. 여기서 TPEG 이란 디지털방송망을 통해 교통 및 여행정보를 전송하는 표준 프로토콜을 의미한다. 도 4에 표현된 것과 같이 TPEG의 계층 구조는 IS0/0SI Layer 모델의 네트워크 계층 (제 3 계층)부터 애플리케이션 계층 (제 7 계층)에 대웅한다. 네트 워크 계층은 TPEG프레임 동기 및 라우팅을 정의하며， 제 4，5,6 계층의 패킷화 계층에서는 각 애플리케이션의 컴포넌트들이 하나의 스트림으로 병합되고， 각각 의 메시지 규격은 응용계층인 제 7 계층에 해당한다. DynNav 에서는 상기 TPEG 의 실시간 교통 정보 표현 방식을 따라 실시간 교통 정보를 단말에게 제공 될 수 있으며， 별도의 표현 방식을 사용할 수 있다.
[122] 일반적으로 사용자가 서버에게 경로를 요청할 때， 시작지, 목적지， 경유 지， 시작 시간 등의 정보를 제공할 수 있다. 상기 서버는 사용자가 요청한 시작 지， 목적지， 경유지, 시작 시간 등의 정보 및 실시간 또는 예측 도로 교통 정보 를 기반으로 사용자에게 제공할 최적화된 경로를 구성하여 전달할 수 있다. 이 경우， 사용자는 시작지 및 목적지를 반드시 상기 서버에게 제공해야 한다.
[123] 본 발명에서 제안하는 방법은, 사용자가 상기 서버에게 경로를 요청할 때， 하나 이상의 여러 경유지를 포함하여， 이 경유지들을 지나는 최적의 경로를 요청하는 방식이다. 이 때， 상기 서버는 실시간 또는 예측한 도로 교통 정보를 고려하여 각각의 경유지를 지나는 순서와 해당 경유지를 지나는 최적 경로를 생 성한다. 이 때， 만약 사용자가 특정 목적지를 선택하지 않았다면， 상기 서버는 여러 경유지 중 하나를 목적지로 고려하여 경로를 선택한다. 이와 같은 경로 요 청 /제공의 예로, 복수의 지점을 방문해야 하는 택배 배송이나 세일즈맨을 생각 할 수 있다. 또한 이러한 예에서 여러 경유지를 지나야 하지만 반드시 최종 목 적지를 지정하여 경로를 요청할 필요는 없다. 이와 같은 예의 경우, 기존의 방 식 (경로 요청 시 반드시 시작지와 목적지 지정)으로는 경로를 제공하기 힘들다.
[124] 한편， 도로의 교통 상황으로 인해 여러 경유지를 지나는 최단 경로가 반 드시 최적화된 경로가 아닐 수 있다. 그러므로 도로 교통 상황에 따라 여러 경 유지를 지나는 최적의 경로를 제공하는 방식이 필요하다. 이 경우 여러 경유지 를 지나는 순서는 도로 교통 상황에 따라 바뀔 수 있다. 또한 도로의 교통 상황 은 시간에 따라 바뀌기 때문에， 이에 맞춰 효율적으로 경로를 제공하는 방식도 고려되어야 한다.
[125] 본 발명은 사용자가 하나 이상의 경유지를 지나는 경로를 요청하고, 서 버가 최적의 경로를 제공하는 하는 방식을 제안한다. 또한 교통 상황의 변화에 따라 경로 및 교통 정보를 업데이트 해야 하는 상황에서 이를 감소 시키기 위한 방법도 고려한다 .
[126] 제 1 예. 하나 이상의 경유지를 포함한 경로 요청 및 제공
[127] 사용자에게 둘 이상의 경유지를 지나는 최적 경로를 제공하는 방법은 사 용자가 상기 서버에게 경로를 요청하는 단계와 상기 서버가 사용자에게 경로를 제공하는 단계가 있다. 본 발명에서는 상기 서버가 사용자의 요청에 따라 최적 경로를 계산하는 방법은 다루지 않는다. 최적 경로를 계산하는 방법은 기존의 다양한 알고리즘을 통해 구현될 수 있다.
[128] 1-1. 경로 요청
[129] 종래의 DynNav 에서 사용자가 서버에게 경로를 요청할 때는 경로를 구성 하는데 필요한 기본적인 정보를 포함하여 요청한다 (표 1 참조). 이 때， 시작지 (originWGS84 또는 originAddress)와 목적지 (destinationWGS84 또는 destinationAddress)는 반드시 포함되어야 한다.
[130] 사용자가 상기 서버에게 여러 경유지를 지나는 최적의 경로를 요청하기 위한 조건은 아래와 같다. .
[131] - 경로 요청 시, 둘 또는 그 이상의 경유지를 포함
[132] - 경로 요청 시， 목적지 정보 포함 또는 포함하지 않음 (목적지 정보가 포함되지 않은 경우， 요청한 다수의 경유지 중 한 곳이 목적지로 고려되어 경로 생성됨)
[133] - 경로 요청 시， 복수의 경유지를 지나는 최적의 경로를 요청하는 지시 자 (routeForMult ipleWaypoints)를 포함
[134] 상기 복수의 경유지를 지나는 최적 경로를 요청하는 지시자는 아래에 상 세하게 나타냈다. "routeForMult ipleWaypoints" 파라미터는 사용자가 상기 서 버에게 경로를 요청할 때 사용하는 Trip 파라미터의 하위 파라미터로 정의된다.
[135] 【표 6】
Figure imgf000028_0001
[136] 사용자로부터 경로를 요청 받은 상기 서버는
" r out eForMu 1 i t 1 eWaypo i nt s " 파라미터를 확인하여， 사용자가 복수의 경유지 를 지나는 경로를 요청함을 확인할 수 있다. 상기 서버는 시작지， 목적지 (목적 지가 포함되어 있는 경우)， 경유지 및 도로의 교통 상황을 고려하여 최적의 경 로를 계산한다. 이 때， 경유지에 도달하는 순서는 최적 경로에 따라 달라질 수 있고, 목적지가 포함되어 있지 않은 경우, 최적 경로를 고려하여 다수의 경유지 중 하나가 최종 목적지로 고려된다.
[137] 사용자가 복수의 경유지를 표현하는 방식은 Trip 파라미터의 하위 파라 미터인 "waypoints" 를 이용하여 표현할 수 있지만 (표 1 참조)， 구현에 따라 서는 복수의 "destination" (dest inat ionWGS84 또는 destinationAddress)을 통 해서도 나타낼 수도 있다.
[138] 또한 사용자는 경로 요청 시 , 시간 조건 및 경유지의 우선 순위 조건을 추가하여 경로를 요청할 수 있다. 첫 번째로 시간 조건은 사용자가 경로 요청 시， 총 경로 주행 시간을 지정하는 방식이다. 경로 주행 시간에 관한 파라미터 는 아래와 같다.
[139] 【표 7】
Figure imgf000029_0001
[140] 사용자가 경로 주행 시간을 지정한 경우, 서버는 상기 지정된 주행 시간 동안 모든 경유지를 지날 수 있는 경로를 제공해야 한다. 이 때, 사용자가 경로 시작 시간 (starting Time)을 지정하지 않은 경우, 현재 시간을 경로 시작 시간 으로 고려할 수 있다.
[141] 상기 경로 주행 시간은 신규 대체 경로를 계산하고 제공해야 할지를 판 단하는 기준이 될 수 있다. 만약 제공한 경로의 교통 상황이 나빠져 경로 주행 시간이 늘어 났으나， 위의 경로 주행 시간을 넘지 않는다면 해당 경로로 계속 진행하고， 만약 나빠진 교통 상황으로 인해 늘어난 주행 시간이 경로 주행 시간 을 넘는다면, 상기 서버는 경로 주행 시간을 넘지 않는 신규 경로를 계산하고 사용자에게 제공할 수 있다. [142] 또한, 사용자는 경로 요청 시 시간 조건과 함께 경유지 우선 순위 조건 을 설정할 수 있다. 경유지 우선 순위 조건에 관한 파라미터는 다음과 같다.
[143] 【표 8】
Figure imgf000030_0001
의 시간 조건 및 우선 순위 조건을 포함한 경우， 상기 서버는 지정한 조건에 맞 는 최적 경로를 산출하고 경로를 제공한다. 사용자가 요청한 복수의 경유지를 지정한 시간 조건 내에 모두 지날 수 있다면, 상기 서버는 최적 경로 생성시 경 유지 우선 순위 조건을 고려하지 않는다. 하지만， 사용자가 요청한 복수의 경유 지를 지정한 시간 조건 내에 모두 지날 수 없다면， 상기 서버는 경유지 우선 순 위 조건을 기반으로 우선 순위가 높은 경유지를 우선적으로 고려하여 최적 경로 를 생성하고, 시간 조건에 맞추기 위해 우선 순위가 낮은 경유지를 최적 경로에 서 포함하지 않고 최적 경로를 생성할 수 있다.
[145] 1-2. 경로 제공
[146] 서버가 사용자에게 경로를 제공하는 방식은 두 가지로 나눌 수 있다. 첫 번째는 기존과 같이 한 번에 전체 경로를 제공하는 방식과 두 번째는 경로를 나 누어 제공하는 방식이다.
[147] 첫 번째 방식은 기존과 동일하다. 사용자가 상기 서버에게 경로를 요청 하면 상기 서버는 계산된 최적의 출발지부터 목적지까지의 전체 경로를 한번에 제공한다. 또한， 경로 진행 중 경로상의 교통 정보의 변경 또는 대체 경로 발 생 시 기존과 같이 통지하여 사용자에게 정보를 전달한다.
[148] 경로가 길어지거나 주행시간이 길어지면 교통 정보의 변경 내지는 대체 경로가 발생할 확률이 높고 빈번할 수 있다. 특히나 위에서 예시로 제시한 택배 배송이나 세일즈맨의 경우， 업무 특성상 이동거리나 주행시간이 길기 때문에， 이러한 변경 정보의 발생이 잦을 수 있다. 그렇기 때문에 첫 번째 제시한 방식 은 상기 서버가 사용자에게 변경된 정보를 빈번히 다시 제공해야 할 가능성이 높고 그만큼 네트워크 자원을 많이 사용하게 된다. 이러한 문제를 위해 새롭게 제안하는 두 번째 방식은 전체 경로를 부분 경로로 나누어 제공하는 방식이다.
[149] 전체 경로가 길거나 주행 시간이 긴 경우, 상기 서버는 일정 기준으로 경로를 나누어 사용자에게 전달한다. 여기서 고려할 수 있는 기준은 아래와 같 다.
[150] - 주행 거리를 고려한 경유지 기준
[151] (예를 들어， 10km 동안 이동할 수 있는 경유지 단위)
[152] - 주행 시간을 고려한 경유지 기준
[153] (예를 들어, 1시간 동안 이동할 수 있는 경유지 단위)
[154] 도 5 는 본 발명의 일 실시예에 따른 복수의 경유지를 포함한 경로를 예 시한다. 도 5(a)에서 사용자는 A를 시작지로 B 내지 H 까지의 경유지를 지나는 경로를 요청하였고 서버는 아래와 같은 최적 경로를 계산하였다. 만약 상기 서 버가 주행 거리를 고려한 경유지 기준으로 경로를 단계적으로 전달하고 그 기준 주행거리가 10km 라고 하면 아래 경로에 대해 상기 서버는 아래와 같은 단계로 사용자에게 경로를 전달한다. 각 단계에 해당하는 경로를 분할 (된) 경로로 지칭 하도록 한다.
[155] - 1단계 경로: A ~ C (12km)
- 2단계 경로: C ~ E (12km)
- 3단계 경로: E ~ H (15km)
[156] 같은 시작지와 경유지를 지나더라도 상기 서버가 다른 경로를 계산했다 면 제공하는 방식은 다를 수 있음을 도 5(b)에 나타내었다.
[157] - 1단계 경로: A ~ G (18km)
- 2단계 경로: G ~ F (10km)
- 3단계 경로: F ~ C (13km)
[158] 위의 도 5(a) 및 5(b)와 같이 같은 시작지와 경유지라 하더라도 다른 최 적 경로가 사용자에게 제공될 수 있다. 또한， 위의 예제에서 기준 주행거리가 10km 이지만 각 경유지를 지나는 경로가 10km 로 정확히 나뉘지 않기 때문에 10km 전후의 근사치 값을 갖는 거리로 나뉘게 된다.
[159] 도 5(c)에서는 주행시간을 기준으로 하는 복수의 경유지를 포함한 경로 를 도시한다. 사용자는 A 를 시작지로 B 부터 F 까지의 경유지를 지나는 경로를 요청하였고 서버는 도 5(c)와 같은 최적 경로를 계산하였다. 만약 서버가 주행 시간을 고려한 경유지 기준으로 경로를 단계적으로 전달하고 그 기준 주행 시간 이 1 시간이라고 하면 아래 경로에 대해 상기 서버는 아래와 같은 단계로 사용 자에게 경로를 전달한다.
[160] - 1단계 경로: A ~ C (1시간 20분)
- 2단계 경로: C ~ E (1시간 17분)
- 3단계 경로: E ~ F (1시간 22분)
[161] 위의 예제에서 기준 주행시간이 1 시간이지만 각 경유지를 지나는 경로 의 주행시간이 1 시간으로 정확히 나뉘지 않기 때문에 1 시간 전후의 근사치 값 을 갖는 거리로 나뉘게 된다.
[162] 위와 같이 서버는 계산한 최적 경로를 기준에 따라 분할하고 사용자에게 분할된 경로를 제공할 수 있다. 이 때， 제공하는 방식은 두 가지 방식을 고려할 수 있다. 첫 번째 방식은 상기 서버가사용자에게 분할된 경로를 한번에 제공하 는 방식이고， 두 번째 방식은 상기 서버가 사용자에게 하나의 경로가 끝나면 다 음 단계의 경로를 제공하는 방식이다.
[163] 첫 번째 방식은 서버가사용자에게 분할 경로를 한번에 제공하는 방식으 로, 상기 서버가 사용자의 요청에 따라 최적의 경로 계산 및 상기 최적 경로를 분할한 후， 사용자에게 분할 경로를 제공 받을 수 있는 주소들을 제공할 수 있 다. 예를 들어， 최적 경로가 5 개의 분할 경로로 이루어져 있다면， 서버는 상기 5 개의 분할 경로를 제공받을 수 있는 주소 5 개를 처음부터 사용자에게 제공할 수 있다. 5 개의 주소를 제공받은 사용자는 동시에 각 주소에 접속하여 각 분할 경로를 한 번에 수신하거나, 또는 한 분할 경로가 완료되기 전에 그 다음 분할 경로를 제공받을 수 있는 주소에 접속하여 경로를 제공받을 수 있다.
[164] 두 번째 방식은 상기 서버가 사용자에게 하나의 분할 경로가 끝나면 다 음 단계의 분할 경로를 제공하는 방식으로, 상기 서버가 사용자의 요청에 따라 최적의 경로 계산 및 상기 최적 경로를 분할한 후， 사용자에게 하나의 분할 경 로가 끝나기 전에 그 다음 분할 경로를 제공할 수 있다. 만약 최적 경로가 5 개 의 분할 경로로 나뉘었다면, 우선 상기 서버는 사용자에게 첫번째 분할 경로를 제공할 수 있다. 상기 첫번째 분할 경로를 제공할 때, 상기 서버는 상기 사용자 에게 상기 분할 경로와 함께 추가 분할 경로가 더 있음을 알리는 지시자를 같이 전달할 수 있다. 사용자는 상기 지시자를 통해 추가 분할 경로가 더 존재함을 확인할 수 있다. 사용자는 첫번째 분할 경로 진행 중 두번째 분할 경로를 요청 하여 수신할 수 있다. 상기 두번째 분할 경로 제공 시에도， 상기 서버는 사용자 에게 추가 분할 경로가 더 있음을 알리는 지시자를 함께 전달할 수 있다. 이러 한 방식으로 사용자는 그 이후의 분할 경로를 제공받을 수 있다. 사용자가 상기 최적 경로의 마지막 분할 경로를 제공받을 때는 상기 서버는 더 이상 제공받을 경로가 없음을 알리는 지시자를 포함하여 사용자에게 최적 경로의 마지막임을 알릴 수 있다.
[165] 위에서 제안한 경로를 제공하는 방법을 위해 필요한 추가 파라미터는 아 래와 같다.
[166] 첫 번째 파라미터는 최적 경로를 여러 개로 나누어 제공할 때 서버가 사용자에게 경로를 몇 개로 나누어 제공하는지 (계산된 최적 경로를 분할하여 제 공할 때 분할 경로를 "Subroute" 로 표현)를 나타내는 파라미터이다.
[167] 【표 9】
Figure imgf000033_0001
[168] 이에 따라, 서버가 최초 여행 (Trip) 정보를 사용자 (단말)에게 제공할 때 최초 분할 경로에 대한 정보를 제공해야 한다. 이는 다음의 파라미터로 제공될 수 있다.
[169] 【표 10】
Figure imgf000034_0001
[170] 두 번째 파라미터는 현재 사용자가 진행하는 경로 외에 이후 추가 경로 가 있음을 알리는 지시자와 해당 경로를 받을 수 있는 링크 (Link)를 제공하는 파라미터이다. 상기 두 번째 파라미터는 여행 (Trip)이 정의되고 난 후， 상기 정 의된 여행에 대한 경로 (Route) 정보를 상기 사용자에게 제공할 때 제공될 수 있 다. [171] 【표 11】
Figure imgf000035_0001
Figure imgf000036_0001
[172] 위의 설명에서 최적 경로를 복수의 분할 경로로 나눌 때, 나누어진 각각 의 경로 (Subroute)의 시작지와 목적지가 경유지임을 가정으로 하고 설명하였다. 하지만 나누어진 경로의 시작지와 목적지가 반드시 경유지일 필요는 없다. 개발 하는 방법에 따라 나누어진 경로의 시작지와 목적지는 경유지가 아닌 서버가 지 정하는 임의의 위치가 될 수 있다.
[173] 제 2 예. 교통 및 경로 정보 업데이트 횟수 감소 방안
[174] 본 발명의 또다른 실시예에 따라 교통 및 경로 정보 업데이트를 감소시 킬 수 있는 방안을 설명하도록 한다. 사용자가 주행 중 경유지가 있을 경우， 경 유지에 도착해 다른 일올 한 후 다시 출발하는 경우가 있다. 예를 들어 택배 배 송이나 세일즈맨의 경우 사용자는 경유지에 도착하여 업무를 본 후 다시 출발 하게 된다. 하지만 기존 내비게이션 서비스는 경유지에 도착해서 소비하는 시간 에 대한 고려가 없기 때문에， 실제로 경유지에서 소비하는 시간 동안은 상기 경 로에 대한 이동이 없고 그에 따라 최적 경로 계산시에 사용된 도로 교통 정보가 실제 이동시의 그것과 다를 수 있다. 즉, 상기 경유지에서 소비하는 시간 동안 사용자의 경로와 연관된 교통 정보 변경이 발생할 수 있으므로， 최적 경로 계산 이 실제로는 최적화되지 않을 수 있다. 이러한 문제점을 도 6 을 통해 다시 설 명하면 다음과 같다.
[175] 도 6은 본 발명의 일 실시예에 따른 각 경유지에서의 소비 시간을 반영 한 최적 경로를 도시한다. 도 6 에서 A를 시작 지점으로 경유지 B, C, D, E, F 를 지나는 경로를 나타내고， 각 경유지 사이의 주행 시간과 각 경유지에서 머무 르는 시간을 나타내었다. 기존의 내비게이션 서비스에서는 총 주행시간은 239 분이고， 경유지에서 머문 시간을 고려한다면 총 주행시간은 309분으로 70분의 차이가 발생한다. 서버가 경로를 계산 할 때， 주행 경로가 길다면 도로 교통 정 보를 업데이트 하는 주기에 따라서 경로 계산에 적용할 도로 교통 정보가 달라 질 수 있다. 상기 서버가 경로를 계산 할 때, 경로의 길이에 따른 주행 시간에 따라 실시간 도로 교통 정보와 예측 도로 교통 정보를 적용할 수 있다. 예를 들 어， 상기 서버가 한 시간 단위로 예측 도로 교통 정보를 생성하고 요청받은 경 로의 주행 시간이 2 시간 이상인 경우, 처음 한 시간 동안 이동할 경로에는 실 시간 교통 정보를 적용하고， 그 이후 1 시간 동안 이동할 경로에는 예측 교통 정보를 적용하여 경로를 계산할 수 있다. 그렇기 때문에 위의 예제처럼 경유지 에서 머문 시간을 고려하지 않는다면 정확한 총 주행 시간을 계산 할 수 없기 때문에 거기에 맞는 적절한 실시간 및 예측 도로 교통 정보를 적용하기 힘들다. 특히나 주행 거리， 시간 및 경유지가 많은 경우 이러한 오차는 커지고 그로 인 해 도로 교통 정보의 변경 통지의 횟수가 늘어나게 된다.
[176] 그렇기 때문에 본 발명의 일 실시예는, 사용자가 상기 서버에 여러 경유 지를 지나는 최적 경로를 요청할 때, 각 경유지에서의 머무는 시간을 제공하도 록 한다. 제안하는 파라미터는 아래와 같다.
[177] 【표 12】
Figure imgf000037_0001
[178] 이를 통해， 상기 서버는 최적 경로 계산시 기존보다 정확한 주행 시간 예측이 가능하고， 또한 실시간 도로 교통 정보와 예측 도로 교통 정보를 더 잘 적용하여 경로 계산할 수 있고， 결국 이를 통해 도로 교통 정보 변경 (업데이트) 을 알리는 횟수의 감소가 가능하다.
[179] 제 3 예. 경유지 순서 전달 기반 경로 전달 방안
[180] 본 발명의 또 다른 일 실시예에 따라， 사용자에게 복수의 경유지를 지나 는 최적 경로 제공하는 다른 방식을 제안한다.
[181] 사용자는 서버에게 여러 경유지를 지나는 최적 경로를 요청하면서 사용 자가 지날 여러 경유지 정보를 상기 서버에게 전달할 수 있다. 이 때， 경유지들 의 정보는 경유지를 지나는 순서를 고려하지 않은 채 전달될 수 있다. 상기 서 버는 현재 및 예측 도로 교통 정보를 기반으로 복수의 경유지를 최적 경로로 고 려하고 , 사용자에게는복수의 경유지를 지나는 순서를 전달한다 .
[182] 자세한 절차는 도 7을 참조하여 설명하도록 한다.
[183] (1) 사용자는 상기 서버에게 복수의 경유지 정보를 전달하면서 복수의 경유지를 지나는 최적 경로를 요청할 수 있다. 이 때， 상기 경유지 정보는 경유 지를 지나는 순서를 고려하지 않은채 전달된다.
[184] (2) 요청을 받는 상기 서버는 현재 및 예측 도로 교통 정보를 고려하여, 복수의 경유지를 지나는 최적 경로를 계산하여 복수의 경유지를 어떤 순서로 지 날지를 결정할 수 있다.
[185] (3) 상기 서버는 상기 (2)에서 계산한 결과를 기반으로 사용자에게 경유 지들을 통과하는 순서 정보를 전달한다.
[186] 위와 같이 경유지들을 통과하는 순서 정보를 수신한 사용자는 상기 순서 정보에 따라 상기 서버에게 각각의 경유지까지 도달하기 위한 경로 정보 또는 도로 교통 정보를 요청한다. (스마트 ND의 경유 교통 정보 요청， 경량 ND의 경 유 경로 정보 요청) 예를 들어, 도 7(3)의 표처럼 경유지 순서를 받았다면 사용 자는 처음에는 시작점 (Origin)부터 A지점으로 가는 경로 (또는 교통 정보)를 요 청할 수 있다. 그 다음으로 A지점부터 D지점으로 가는 경로를 요청할 수 있다. 이와 같은 방식으로 사용자는 E 지점까지의 경로를 요청하여 수신할 수 있다. 이와 같이 경로를 요청하고 받는 방식은 기존 DynNav 서비스에서 하는 방식과 동일하다.
[187] 본 실시예를 간략히 요약하면 사용자가 여러 경유지를 지나는 경로를 요 청하면 상기 서버는 각각의 경유지를 통과하는 순서를 지정하여 알려준다. 이를 기반으로 사용자는 한 경유지에서 다음 경유지를 가는 경로를 상기 서버에게 요 청， 전달 받는다.
[188] 본 발명의 실시예를 도 2를 참조하여 다시 설명하도록 한다.
[189] 도 2 의 동작은 DynNav 애플리케이션 (이하， 단말)이 DynNav 서버 (이하， 서버)에 경로 정보를 전달할 것을 요청하는 시나리오에 관한 것이다. 이 시나리 오의 주된 기능은 (1) 요약 경로 및 /또는 전체 경로의 전달, (2) 통지 서비스의 가입， (3) 상기 단말에 의한 현재 위치의 보고， (4) (a) 제안된 경로 상의 심각 한 정체 (b) 사용할 경로로부터 우회， (c) 목적지가 제 3자이고 상기 제 3자의 위치가 변경되는 경우의 경로 재 -계산이다.
[190] 상기 단말의 사용자는 출발지와 목적지 그리고 다른 선호 사항들에 기반 하여 여행을 정의하고， 이러한 파라미터들은 즉시 상기 단말에 의해 상기 서버 로 전송된다. 상기 목적지는 상기 제 3자의 ID를 사용하여 정의되고， 이 경우 상기 서버는 외부 위치 애플리케이션 (서버)를 통해 상기 제 3 자의 위치를 획득 할 수 있고， 상기 제 3자의 위치를 목적지로서 사용할 수 있다. 상기 서버는 실 시간 및 예측 도로 교통 정보를 고려하여 여행 파라미터들과 매칭하는 일 세트 의 경로들로 응답할 것이다. 대역폭 최적화를 위해, 경로들은 두 개의 다른 포 맷들, 즉 요약 및 전체로 상기 서버에서 이용 가능하다. 상기 단말은 요약 경로 에 액세스하고: 이 정보를 이용하여 상기 단말의 사용자는 내비게이션을 위해 사용될 제안된 세트 중에서 일 경로를 선택할 수 있다. 상기 제 3 자로 전달될 경로를 상기 제안된 경로들에서 선택할 수 있다. 상기 단말은 선택된 경로에 대 한 전체 경로를 요청할 수 있고 사용되지 않는 경로들을 삭제할 수도 있다. 제 한된 길이， 여행의 복잡도 및 네트워크 성능들로 인해， 제안된 경로들은 시작시 부터 바로 전체 경로로 인코딩될 수 있고; 이 경우 상기 서버는 요약 경로를 인 코딩할 필요가 없다. 만약 이 데이터가 도로 데이터베이스에서 상기 단말에 대 해 이용 가능하지 않으면 상기 단말은 경로들의 세그먼트 모양 (WGS84좌표 다각 형)에 대한 정보를 서버로부터 요청할 수 있다.
[191] 상기 단말은 사용할 경로에 대한 교통 정보 업데이트 (퍼포먼스 파라미 터 및 교통 이벤트)ᅳ 경로를 따라 정체가 있는 경우 대안 경로 제안을 수신하기 위한, 그리고 제 3자의 ID가 목적지로 사용되고 상기 제 3자의 위치가 변경되 는 경우 갱신된 정보 (갱신된 목적지， 추가 세그먼트 또는 대안 경로)를 수신하 기 위한 통지 서비스들에 가입할 수 있다. 상기 단말은 (상기 단말이 탑재된) 차량이 특정 거리를 운전한 이후에 상기 서버 상에 자신의 현재 위치를 업데이 트할 것이다. 이 정보를 이용하여， 상기 서버는 사용할 경로로부터 이미 여행된 세그먼트들을 삭제하고 (만약 상기 단말에 의해 이전에 삭제되지 않았다면) 현 재 위치와 더 이상 호환될 수 없는 경로들을 삭제할 것이다.
[192] 그 후에， 사용자는 사용 경로로부터 우회할 수 있다. 이러한 조건하에서, 상기 단말은 자신의 업데이트된 현재 위치를 업로드할 수 있고， 상기 서버는 상 기 단말의 현재 위치가사용 경로와 호환되지 않음을 인식하고 업데이트된 위치 정보에 기반하여 새 경로 추정을 진행할 수 있다. 새로운 경로 식별자가 현재 위치 업데이트 절차에서 상기 단말로 전송될 수 있다 (상기 새로운 경로에 대한 통지 절차는 따라서 필요하지 않음). 안전상의 이유로 사용자와의 상호작용을 최소화하기 위해, 상기 통지 서비스는 새로운 제안 경로 (들)로 자동으로 확장될 것이다.
[193] 제공된 경로 상의 교통 정체로 인해， 상기 서버는 상기 단말에게 사용 경로에 대한 업데이트 교통 정보 및 대안 경로의 제안을 알리고, 상기 단말은 알려진 리소스들에 액세스할 수 있다. 상기 서버는 만약 삭제되지 않았다면 새 로운 제안 경로를 위한 통지 서비스를 자동으로 제공할 것이다.
[194] 제 3자의 ID가 목적지로 사용되는 경우, 목적지는 상기 제 3자가 이동 할 수 있기 때문에 변경될 수 있다. 이 경우， 상기 서버는 상기 단말에게 업데 이트된 정보를 통지할 수 있다. 상기 업데이트된 정보의 유형들은 (1) 업데이트 된 목적지 (2) 추가 세그먼트， (3) 대안 경로 이다. 상호작용의 횟수를 줄이기 위해， 상기 서버는 업데이트된 정보의 유형에 따라 상기 단말이 목적지 근처에 있을 경우에만 상기 업데이트된 정보를 통지할 수 있다.
[195] 상기 단말이 복수의 경유지를 방문하기 위해 경로를 요청하는 경우， 상 기 서버는 경로 정보를 효율적으로 관리하고 업데이트하기 위해 예측된 경로 (계 산된 경로)를 몇몇의 서브 경로들로 나눌 수 있다. 이 경우， 상기 서버는 상기 서브 경로들을 순차적으로 제공할 수 있기 때문에 상기 단말은 순차적으로 사 용할 서브 경로들을 획득 (retrieve)할 수 있다.
[196] 본 발명의 일 실시예에 따른 복수의 경유지를 포함한 경로가 요청되고 그에 대한 최적 경로가 제공되는 시나리오의 경우， 도 2 의 과정 중에서 1 과 3 의 과정에서 추가 또는 변경 사항이 있다.
[197] 1. 사용자 (단말)는 자신이 원하는 여행에 관한 파라미터들, 즉 출발지, 목적지 및 경유지 (들) 등으로 구성된 여행 (trip)을 생성할 수 있다. 또한， 상기 경유지 (들)를 포함한 여행에 대한 경로를 요청하기 위해서, 상기 경유지를 포함 한 경로를 요청함을 지시하는 지시자 (routeForMultipleWaypoints)가 추가되어야 하며， 이 경우 적어도 둘 이상의 경유지 (waypoints)에 대한 정보가 추가되어야 한다. [198] 또한, 사용자는 요청하는 경로에 대한 제약 조건을 더 부가할 수 있다. 예컨대, 사용자 자신이 상기 경로를 이동하는데 허용되는 최대 시간 (requestedTravellingTime)을 추가할 수 있다. 예컨대， 사용자가 출발지 (보통， 현재 사용자의 위치)에서부터 A 내지 E 의 경유지를 모두 들르는데 최대 4 시간 (240 분)이 허용되는 경우， 사용자는 경로 요청시에 상기 4 시간을 조건으로 부 가할 수 있다.
[199] 그리고， 만약 현재 /예측 도로 교통 정보에 기반하여 모든 경유지들을 들 르는데 상기 최대 시간을 초과하는 예측 경로만이 존재하는 경우， 우선 순위에 따라 모든 경유지들 중 적어도 하나가 상기 예측 경로에서 제거될 수 있다. 상 기 우선 순위는 각 경유지에 대한 우선 순위를 지칭하며 이는 단말에 의해 입 력되며 낮은 우선 순위를 갖는 경유지부터 제거될 수 있다.
[200] 또한， 사용자는 각 경유지에 머무를 시간을 상기 경로 요청시에 설정할 수 있으며， 이는 반드시 상기 서버에 의해 경로 계산시에 고려되어야 한다.
[201] 이에， 상기 서버는 사용자에 의해 복수의 경유지를 포함한 경로를 요청 받은 경우에 제안 경로를 복수의 부분 경로 (subroute)들로 나눌 수 있다. 이렇 게 복수의 부분 경로를 제공하고자 결정한 경우에 상기 서버는 상기 사용자로 제안 경로가 몇 개의 부분 경로들로 이루어져있는지를 알려줄 수 있다. 또한， 상기 제안 경로의 첫번째 부분 경로에 대한 참조 경로 리소스를 사용자로 제공 할 수 있다.
[202] 3. 사용자는 제안된 복수의 요약 경로 중 하나를 선택하고, 이에 대한 전체 경로를 요청 또는 액세스할 수 있다. 사용자가 복수의 경유지들을 포함한 경로를 서버에게 요청하고， 상기 서버가 상기 경로를 복수의 분할 경로들로 제 공하는 경우, 상기 사용자 또는 단말은 상기 전체 경로 대신 상기 분할 경로 정 보에 액세스할 수 있다.
[203] 상기 분할 경로를 수신함에 있어서, 상기 사용자는 상기 서버로부터 첫 번째 분할 경로에 대한 정보와， 후속하는 분할 경로가 있는지 여부를 지시하는 지사지 그리고 만약 후속하는 분할 경로가 있다면 그 이후 (즉， 두번째) 분할 경 로에 대한 참조 (링크)에 대한 정보를 포함하는 경로 정보를 수신할 수 있다.
[204] 상기 분할 경로 (들)이 상기 서버에 의해 제공되는 경우, 3 번 과정은 상 기 사용자가 진행 중인 분할 경로의 목적지에 도착하기 전에 후속하는 분할 경 로에 액세스하기 위해 반복될 수 있다. 또한, 상기 3 번 과정은 더 이상 추가 분할 경로가 있지 않다고 지시될 때까지 반복될 수 있다.
[205] 도 8은 본 발명의 일 실시예에 따른 동작을 도시한다.
[206] 단말 (810)은 사용자, 사용자 단말, 또는 사용자 단말 내 애플리케이션 중 하나로 지칭될 수 있으며， 서버 (820)는 서버， 서버 장치 또는 서버 장치 내 애플리케이션 등 중 하나로 지칭될 수 있으며, 특정 명칭에 본 발명의 범위가 제한되지 않는다.
[207] 상기 단말은 상기 서버로 복수의 경유지를 포함한 경로를 요청할 수 있 다 (S81). 상기 요청은 출발지 및 복수의 경유지를 포함해야 하고， 목적지는 반 드시 지정될 필요는 없다. 목적지가 지정되지 않은 경우， 상기 복수의 경유지 중 하나가 목적지로 지정될 수 있다. 또한, 상기 복수의 경유지를 포함한 경로 를 요청하는 경우에 , 상기 요청에 상기 복수의 경유지를 포함한 경로를 요청함 을 알리는 지시자가 포함되어야 하고， 이 경우 둘 이상의 경유지가 상기 요청에 포함되어야 한다.
[208] 또한， 상기 단말은 상기 요청을 전송할 시에， 추가적인 제약 조건을 부 가할 수 있다. 예를 들어， 상기 경로를 운행하는데 소요될 최대 시간이 설정될 수 있다. 이와 관련하여， 각 경유지에 대해 우선순위가 설정될 수 있다. 만약 상기 서버가 계산한 경로를 운행하는데 필요한 예측 소요 시간이 상기 설정된 최대 시간을 초과하는 경우， 상기 계산한 경로에서 상기 우선순위에 따라 적어 도 하나의 경유지가삭제될 수 있다.
[209] 또한， 각각의 경유지에서 머무를 시간이 설정될 수 있다. 일반적으로, 복수의 경유지를 포함한 경로를 요청한 경우， 각 경유지에서 특정 시간 동안 머 무를 가능성이 높고 또한 상기 특정 시간에 의해 현재 /예측 도로 교통 정보의 업데이트가 필요할 수 있으므로， 상기 각각의 경유지에서 머무를 시간을 설정하 는 것이 좀더 정확한 경로 예측을 위해 필요할 수 있다.
[210] 이에， 상기 서버는 S81 에서의 요청에 따라 제안 경로를 계산하고 상기 제안 경로에 대한 정보를 포함한 웅답을 상기 단말로 전송할 수 있다 (S82).
[211] 앞서 표 7, 표 8 및 표 12 에서 설명된 파라미터 중 적어도 하나가 상기 단말 (또는 사용자)이 복수의 경유지를 포함한 여행의 경로를 요청할 시에 입력 될 수 있으며， 서버는 상기 입력된 파라미터에 기초하여 제안 경로를 계산할 수 있다.
[212] 상기 웅답은 상기 제안 경로가 몇 개의 분할 경로로 분할되었는지를 나 타내는 정보와 첫번째 분할 경로에 대한 참조 링크를 포함할 수 있다. 상기 단 말은 상기 참조 링크에 접속하여 상기 첫번째 분할 경로를 요청할 수 있다 (S83).
[213] 상기 단말은 상기 서버로부터 상기 첫번째 분할 경로를 포함한 정보를 획득할 수 있다 (S84). 상기 정보는 상기 첫번째 분할 경로 및 두번째 분할 경로 에 대한 참조 링크 (만약， 두 번째 분할 경로가 있는 경우)를 포함할 수 있다.
[214] 후속하는 분할 경로가 있는 경우， 상기 단말은 참조 링크를 통해 상기 서버로부터 특정 분할 경로 및 그 이후의 분할 경로에 대한 참조 링크를 획득할 수 있다. 이는 더 이상 후속하는 분할 경로가 없을 때까지 반복될 수 있다.
[215] 이처럼 복수의 분할 경로는 일정 시간 간격으로 순차적으로 송수신될 수 있다. 이에 따라 각 분할 경로를 계산하는데 사용된 현재 /예측 도로 교통 정보 는 서로 다른 시간의 도로 교통 정보이며， 즉 상기 현재 /예측 도로 교통 정보는 서로 다른 시간에 업데이트된 정보일 수 있다.
[216] 도 9 는 본 발명의 실시예들을 구현하도록 구성된 단말과 서버의 블록도 를 나타낸다. 상기 단말 (910)은 상기 서버 (920)와 통신하도톡 구성된 송수신기 (911)； 및 상기 서버로부터 수신되는 정보에 기반하여 상기 경로에 대한 갱신 정보를 획득하도록 구성된 프로세서 (912)를 포함할 수 있다. 상기 서버 (920)는 상기 단말과 통신하도록 구성된 송수신기 (921); 및 상기 단말로부터 수신된 정 보에 기반하여 상기 경로에 대한 갱신 정보를 생성하도록 구성된 프로세서 (922) 를 포함할 수 있다.
[217] 도 9 와 관련하여 설명될 본 발명의 일 실시예는 상기 단말 (910)이 경량 ND 인 경우의 실시예이고， 상기 단말은 서버에 의해 계산된 복수의 경유지를 포 함한 여행 (trip)의 경로를 수신하도록 구성된다. 이 실시예에서 경로의 출발지 는 상기 단말의 위치이고， 상기 목적지는 별도로 지정되거나 복수의 경유지들 중 하나로 결정된다. 이 실시예에서， 상기 프로세서 (912)는 상기 복수의 경유지 를 포함한 여행에 대한 경로의 요청을 서버로 전송하도록 구성될 수 있다. 상기 요청은 상기 복수의 경유지를 포함한 경로를 요청함을 나타내는 정보 및 상기 복수의 경유지 정보를 포함할 수 있다. 또한， 상기 프로세서 (912)는 상기 복수 의 경유지를 포함한 여행의 제안 경로에 대한 정보를 상기 서버로부터 수신하도 록 구성될 수 있다.
[218] 상기 여행의 제안 경로가 복수의 서브 경로로 구성되어 상기 제안 경로 에 대한 정보가 상기 여행의 제안 경로가 몇 개의 서브 경로로 구성되었음을 지 시하는 정보 및 상기 서브 경로 중 첫번째 서브 경로에 대한 링크를 포함하면， 상기 프로세서 (912)는 상기 첫번째 서브 경로에 대한 링크를 통해 상기 첫번째 서브 경로에 대한 정보를 수신하도록 구성될 수 있다. 또한， 상기 첫번째 서브 경로에 대한 정보는 상기 첫번째 서브 경로에 후속하는 두번째 서브 경로가 존 재하는지 여부를 지시하는 지시자 및 상기 두번째 서브 경로에 대한 링크를 포 함할 수 있다.
[219] 상기 프로세서 (912)는 N(N은 2이상의 정수)번째 서브 경로에 대한 링크 를 통해 상기 N번째 서브 경로에 대한 정보를 수신하도록 구성될 수 있다.
[220] 또한， 상기 N 번째 서브 경로에 대한 정보는 N+1 번째 서브 경로가 존재 하는지 여부를 지시하는 지시자 및 상기 N+1 번째 서브 경로에 대한 링크를 포 함할 수 있으며, 상기 N+1번째 서브 경로에 대한 링크는 상기 N+1번째 서브 경 로가 존재하는 경우에 상기 N번째 서브 경로에 대한 정보에 포함될 수 있다.
[221] 상기 프로세서 (912)는 상기 요청에 상기 경로의 최대 허용 운행 시간, 상기 복수의 경유지 각각에 대한 우선순위 또는 상기 복수의 경유지 각각에서 머무를 시간 중 적어도 하나로 구성된 경로 조건을 포함시키도록 구성될 수 있 다. 바람직하게는， 상기 최대 허용 운행 시간과 상기 복수의 경유지 각각에 대 한 우선순위는 동시에 포함될 수 있다. 상기 서버에 의해 계산된 특정 제안 경 로의 운행 소요 시간이 상기 최대 허용 운행 시간을 초과하는 경우 상기 특정 제안 경로에서 상기 우선순위에 따라 상기 복수의 경유지 중 적어도 하나가 제 외될 수 있다.
[222] 상기 제안 경로는 운행 소요 시간 기준 또는 운행 거리 기준으로 복수의 서브 경로로 분할될 수 있다. 상기 복수의 서브 경로 각각은 서로 다른 시점의 도로 교통 정보에 기반하여 계산될 수 있다. 아울러 , 상기 프로세서 (912)는 상 기 복수의 서브 경로 각각을 시간 차이를 두고 수신하도록 구성될 수 있다.
[223] 상기 서버의 프로세서 (922)와 관련된 내용은 앞서 설명한 실시예들 중 적어도 하나를 참조하도록 한다. [224] 본 발명의 실시예 (들)에 따른 방안은， 단말이 서버에게 복수의 경유지들 을 방문하기 위한 경로 정보를 요청하며, 이 경우 상기 경로의 운행 거리 또는 운행 시간이 현저하게 클 수 있다. 만약 긴 경로가 제공되고 그대로 사용된다면, 상기 경로 정보를 관리하고 업데이트하는 것이 비효율적이고 더 많은 리소스들 을 사용할 수도 있다. 이러한 경우， 상기 서버는 상기 긴 경로를 몇몇 짧은 경 로들 (즉， 서브 또는 분할 경로)로 나누고 짧은 경로들을 순차적으로 제공하여 상기 경로 정보의 관리 및 업데이트를 효율적으로 할 수 있다. 각각의 서브 경 로는 상기 단말에게 순차적으로 제공되므로, 변하는 교통 조건에 따라 상기 서 버는 아직 상기 단말에게 제공되지 않은 경로 정보를 내부적으로 업데이트할 수 있다. 따라서, 네트워크 자원의 소비가 즐어들 것이다.
[225] 상기 서버가 요청된 여행과 관련된 경로를 계산 또는 예측한 이후에， 만 약 상기 경로의 운행 거리 또는 운행 시간이 특정 임계치를 넘어서면， 상기 서 버는 상기 예측된 경로를 몇몇 서브 경로들로 나눌 수 있다. 상기 서버가 서브 경로들을 생성할 때, 원래의 (전체) 경로는 운행 거리 (예컨대， 20km마다) 또는 운행 시간 (예컨대， 2시간 마다)에 기반하여 나뉠 수 있다.
[226] 상기 서브 경로들이 생성된 후에， 상기 서버는 여행과 관련된 정보를 통 해 상기 단말로 첫번째 서브 경로 정보를 제공할 수 있다. 그리고나서， 상기 단 말은 상기 첫번째 서브 경로 정보에 액세스할 수 있다. 상기 첫번째 서브 경로 정보에， 두번째 서브 경로의 링크가 포함된다. 상기 첫번째 서브 경로의 목적지 에 도착하기 전에， 상기 단말은 세번째 서브 경로의 링크를 포함한 상기 두번째 서브 경로 정보에 액세스할 수 있다. 상기 단말은 후속하는 서브 경로에 액세스 하기 위해 이 절차를 추가적인 서브 경로가 더 이상 존재하지 않음이 지시될 때 (즉， Route 리소스 내 "additionalSubroute" 파라미터가 false 값을 가질때) 까 지 반복할 수 있다.
[227] 본 발명은 사용자가 목적지를 지정하지 않고 여러 경유지를 지나는 경로 의 요청 및 제공하는 방법을 제안하고， 또한 경로 제공 방법 및 경유지에서 머 무른 시간 제공을 통해 대체 경로 및 교통정보 변경에 대한 통지 횟수를 줄일 수 있는 방법을 제안하였다. [228] 본 발명에서 제안한 방법을 통해 다양한 내비게이션 서비스 제공이 가능 하게 된다. 또한， 대체 경로 및 교통정보 변경의 통지 횟수를 줄이는 방법을 통 해 단말의 네트워크 자원 사용을 감소 시킬 수 있다.
[229] 한편， 상기 단말 또는 상기 서버는 앞서 설명한 실시예들 중 하나 또는 둘 이상의 실시예들의 조합을 수행할 수 있고, 실시예 (들) 중 일부를 조합 또는 결합하여 수행할 수 있다.
[230] 상술한 바와 같이 개시된 본 발명의 바람직한 실시예들에 대한 상세한 설명은 당업자가 본 발명을 구현하고 실시할 수 있도록 제공되었다. 상기에서는 본 발명의 바람직한 실시예들을 참조하여 설명하였지만, 해당 기술 분야의 숙련 된 당업자는 하기의 특허 청구의 범위에 기재된 본 발명을 다양하게 수정 및 변 경시킬 수 있음을 이해할 수 있을 것이다. 따라서， 본 발명은 여기에 나타난 실 시형태들에 제한되려는 것이 아니라, 여기서 개시된 원리들 및 신규한 특징들과 일치하는 최광의 범위를 부여하려는 것이다.
【산업상 이용가능성】
[231] 본 발명의 실시예들은 내비게이션 장치 또는 서버에 적용가능하다.

Claims

【청구의 범위】
【청구항 1]
서버에 의해 계산된 복수의 경유지를 포함한 여행 (trip)의 경로를 수신 하기 위한 방법으로서， 상기 방법은 단말에 의해 수행되고，
상기 복수의 경유지를 포함한 여행에 대한 경로의 요청을 서버로 전송 하는 단계， 상기 요청은 상기 복수의 경유지를 포함한 경로를 요청함을 나타내 는 지시자 및 상기 복수의 경유지 정보를 포함하고;
상기 복수의 경유지를 포함한 여행의 제안 경로에 대한 정보를 상기 서 버로부터 수신하는 단계를 포함하고 상기 방법은:
상기 여행의 제안 경로가 복수의 서브 경로로 구성되어, 상기 제안 경 로에 대한 정보가 상기 여행의 제안 경로가 몇 개의 서브 경로로 구성되었음 을 지시하는 정보 및 상기 서브 경로 중 첫번째 서브 경로에 대한 링크를 포 함하면， 상기 첫번째 서브 경로에 대한 링크를 통해 상기 첫번째 서브 경로에 대한 정보를 수신하는 단계를 포함하고，
상기 첫번째 서브 경로에 대한 정보는 상기 첫번째 서브 경로에 후속하 는 두번째 서브 경로가.존재하는지 여부를 지시하는 지시자 및 상기 두번째 서 브 경로에 대한 링크를 포함하는 것을 특징으로 하는, 경로 수신 방법.
【청구항 2]
제 1항에 있어서, 상기 방법은:
N(N>2)번째 서브 경로에 대한 링크를 통해 상기 N 번째 서브 경로에 대 한 정보를 수신하는 단계를 더 포함하는 것을 특징으로 하는， 경로 수신 방법.
【청구항 3】
제 2항에 있어서， 상기 N번째 서브 경로에 대한 정보는 N+1 번째 서브 경로가 존재하는지 여부를 지시하는 지시자 및 상기 N+1 번째 서브 경로에 대 한 링크를 포함하고,
상기 N+1 번째 서브 경로에 대한 링크는 상기 N+1 번째 서브 경로가 존 재하는 경우에 상기 N 번째 서브 경로에 대한 정보에 포함되는 것을 특징으로 하는, 경로 수신 방법.
【청구항 4】 제 1 항에 있어서， 상기 요청은 상기 경로의 최대 허용 운행 시간, 상기 복수의 경유지 각각에 대한 우선순위 또는 상기 복수의 경유지 각각에서 머무를 시간 중 적어도 하나로 구성된 경로 조건을 포함하고，
상기 제안 경로는 상기 경로 조건에 기반하여 계산되는 것을 특징으로 하는， 경로 수신 방법.
【청구항 5】
제 4 항에 있어서, 상기 서버에 의해 계산된 특정 제안 경로의 운행 소 요 시간이 상기 최대 허용 운행 시간을 초과하는 경우, 상기 특정 제안 경로에 서 상기 우선순위에 따라 상기 복수의 경유지 중 적어도 하나가 제외되는 것을 특징으로 하는ᅳ 경로 수신 방법.
【청구항 6】
제 1 항에 있어서, 상기 제안 경로는 운행 소요 시간 기준 또는 운행 거 리 기준으로 복수의 서브 경로로 분할되는 것을 특징으로 하는， 경로 수신 방 법.
【청구항 71
제 1 항에 있어서， 상기 복수의 서브 경로 각각은 서로 다른 시점의 도 로 교통 정보에 기반하는 것을 특징으로 하는， 경로 수신 방법 .
【청구항 8]
제 1 항에 있어서, 상기 복수의 서브 경로 각각은 시간 차이를 두고 수 신되는 것을 특징으로 하는, 경로 수신 방법.
【청구항 9]
서버에 의해 계산된 복수의 경유지를 포함한 여행 (trip)의 경로를 단말 에게 제공하기 위한 방법으로서, 상기 방법은 서버에 의해 수행되고,
상기 복수의 경유지를 포함한 여행에 대한 경로의 요청을 상기 단말로 부터 수신하는 단계, 상기 요청은 상기 복수의 경유지를 포함한 경로를 요청함 을 나타내는 정보 및 상기 복수의 경유지 정보를 포함하고;
상기 복수의 경유지를 포함한 여행의 제안 경로를 계산하는 단계; 및 상기 제안 경로에 대한 정보를 상기 단말로 전송하는 단계를 포함하고， 상기 여행의 제안 경로가 복수의 서브 경로로 구성되어, 상기 제안 경 로에 대한 정보가 상기 여행의 제안 경로가 몇 개의 서브 경로로 구성되었음을 지시하는 정보 및 상기 서브 경로 중 첫번째 서브 경로에 대한 링크를 포함하 면， 상기 단말은 상기 첫번째 서브 경로에 대한 링크를 통해 상기 첫번째 서브 경로에 대한 정보를 수신하도록 구성되며,
상기 첫번째 서브 경로에 대한 정보는 상기 첫번째 서브 경로에 후속하 는 두번째 서브 경로가 존재하는지 여부를 지시하는 지시자 및 상기 두번째 서 브 경로에 대한 링크를 포함하는 것을 특징으로 하는， 경로 제공 방법.
【청구항 10】
제 9항에 있어서 ,
N(N>2)번째 서브 경로에 대한 링크를 통해 상기 N 번째 서브 경로에 대 한 정보가 상기 단말로 제공되는 것을 특징으로 하는, 경로 제공 방법.
【청구항 111
제 10항에 있어서 , 상기 N번째 서브 경로에 대한 정보는 N+1번째 서브 경로가 존재하는지 여부를 지시하는 지시자 및 상기 N+1 번째 서브 경로에 대 한 링크를 포함하고，
상기 N+1 번째 서브 경로에 대한 링크는 상기 N+1 번째 서브 경로가 존 재하는 경우에 상기 N 번째 서브 경로에 대한 정보에 포함되는 것을 특징으로 하는 경로 제공 방법.
【청구항 12】
제 9 항에 있어서， 상기 요청은 상기 경로의 최대 허용 운행 시간， 상기 복수의 경유지 각각에 대한 우선순위 또는 상기 복수의 경유지 각각에서 머무를 시간 중 적어도 하나로 구성된 경로 조건을 포함하고
상기 제안 경로는 상기 경로 조건에 기반하여 계산되는 것을 특징으로 하는, 경로 제공 방법.
【청구항 13]
제 12 항에 있어서， 상기 서버에 의해 계산된 특정 제안 경로의 운행 소 요 시간이 상기 최대 허용 운행 시간을 초과하는 경우, 상기 특정 제안 경로에 서 상기 우선순위에 따라 상기 복수의 경유지 중 적어도 하나가 제외되는 것을 특징으로 하는， 경로 제공 방법.
【청구항 14] 제 9 항에 있어서， 상기 제안 경로는 운행 소요 시간 기준 또는 운행 거 리 기준으로 복수의 서브 경로로 분할되는 것을 특징으로 하는, 경로 제공 방법.
【청구항 15】
제 9 항에 있어서， 상기 복수의 서브 경로 각각은 서로 다른 시점의 도 로 교통 정보에 기반하는 것을 특징으로 하는， 경로 제공 방법 .
【청구항 16】
제 9 항에 있어서， 상기 복수의 서브 경로 각각은 시간 차이를 두고 제 공되는 것을 특징으로 하는， 경로 제공 방법.
【청구항 17】
서버에 의해 계산된 복수의 경유지를 포함한 여행 (trip)의 경로를 수신 하도록 구성된 단말로서 ,
서버와 통신하도록 구성된 송수신기; 및
상기 서버로부터 수신되는 정보에 기반하여 상기 경로에 대한 갱신 정 보를 획득하도록 구성된 프¾세서를 포함하고，
상기 프로세서는:
상기 복수의 경유지를 포함한 여행에 대한 경로의 요청을 서버로 전송 하고 상기 요청은 상기 복수의 경유지를 포함한 경로를 요청함을 나타내는 정 보 및 상기 복수의 경유지 정보를 포함하고; 상기 복수의 경유지를 포함한 여 행의 제안 경로에 대한 정보를 상기 서버로부터 수신하도록 구성되며,
상기 여행의 제안 경로에 대한 정보가 상기 여행의 제안 경로가 몇 개 의 서브 경로로 구성되었음을 지시하는 정보 및 상기 서브 경로 중 첫번째 서 브 경로에 대한 링크를 포함하면， 상기 프로세서는 상기 첫번째 서브 경로에 대한 링크를 통해 상기 첫번째 서브 경로에 대한 정보를 수신하도록 구성되고， 상기 첫번째 서브 경로에 대한 정보는 상기 첫번째 서브 경로에 후속하 는 두번째 서브 경로가 존재하는지 여부를 지시하는 지시자 및 상기 두번째 서 브 경로에 대한 링크를 포함하는 것을 특징으로 하는, 단말.
【청구항 18]
서버에 의해 계산된 복수의 경유지를 포함한 여행 (trip)의 경로를 단말 에게 제공하도록 구성된 서버로서，
단말과 통신하도록 구성된 송수신기; 및 상기 단말로부터 수신되는 정보에 기반하여 상기 경로에 대한 갱신 정 보를 생성하도록 구성된 프로세서를 포함하고 ,
상기 프로세서는:
상기 복수의 경유지를 포함한 여행에 대한 경로의 요청을 상기 단말로 부터 수신하고， 상기 요청은 상기 복수의 경유지를 포함한 경로를 요청함을 나 타내는 정보 및 상기 복수의 경유지 정보를 포함하고; 상기 복수의 경유지를 포함한 여행의 제안 경로에 대한 정보를 상기 단말로 전송하도록 구성되고， 상기 여행의 제안 경로가 복수의 서브 경로로 구성되어, 상기 제안 경 로에 대한 정보가 상기 여행의 제안 경로가 몇 개의 서브 경로로 구성되었음을 지시하는 정보 및 상기 서브 경로 중 첫번째 서브 경로에 대한 링크를 포함하 면， 상기 단말은 상기 첫번째 서브 경로에 대한 링크를 통해 상기 첫번째 서브 경로에 대한 정보를 수신하도록 구성되며,
상기 첫번째 서브 경로에 대한 정보는 상기 첫번째 서브 경로에 후속하 는 두번째 서브 경로가 존재하는지 여부를 지시하는 지시자 및 상기 두번째 서 브 경로에 대한 링크를 포함하는 것을 특징으로 하는， 서버.
PCT/KR2014/003105 2013-04-11 2014-04-10 복수의 경유지를 포함한 최적 경로 전달 방법 및 이를 위한 장치 WO2014168428A1 (ko)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CN201480020683.5A CN105144262B (zh) 2013-04-11 2014-04-10 用于传送包括多个经过地点的最优路径的方法和装置
JP2015562942A JP6140312B2 (ja) 2013-04-11 2014-04-10 複数の経由地を含む最適経路伝達方法及びこのための装置
US14/782,399 US9749930B2 (en) 2013-04-11 2014-04-10 Method for delivering optimum path including plurality of passage places and apparatus therefor

Applications Claiming Priority (14)

Application Number Priority Date Filing Date Title
US201361810733P 2013-04-11 2013-04-11
US61/810,733 2013-04-11
US201361825524P 2013-05-21 2013-05-21
US61/825,524 2013-05-21
US201361827668P 2013-05-27 2013-05-27
US61/827,668 2013-05-27
US201361897816P 2013-10-30 2013-10-30
US61/897,816 2013-10-30
US201361902272P 2013-11-10 2013-11-10
US61/902,272 2013-11-10
US201461941469P 2014-02-18 2014-02-18
US61/941,469 2014-02-18
US201461969249P 2014-03-23 2014-03-23
US61/969,249 2014-03-23

Publications (1)

Publication Number Publication Date
WO2014168428A1 true WO2014168428A1 (ko) 2014-10-16

Family

ID=51689768

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2014/003105 WO2014168428A1 (ko) 2013-04-11 2014-04-10 복수의 경유지를 포함한 최적 경로 전달 방법 및 이를 위한 장치

Country Status (4)

Country Link
US (1) US9749930B2 (ko)
JP (1) JP6140312B2 (ko)
CN (1) CN105144262B (ko)
WO (1) WO2014168428A1 (ko)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111600965A (zh) * 2020-06-05 2020-08-28 支付宝(杭州)信息技术有限公司 区块链中的共识方法和系统

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9696175B2 (en) * 2015-10-16 2017-07-04 GM Global Technology Operations LLC Centrally managed waypoints established, communicated and presented via vehicle telematics/infotainment infrastructure
CN106251621A (zh) * 2016-09-28 2016-12-21 山东华旗新能源科技有限公司 智慧交通管理系统及方法
CN107869995A (zh) * 2016-09-28 2018-04-03 阿里巴巴集团控股有限公司 一种路径时长的生成方法、系统及移动终端
WO2018131814A1 (ko) * 2017-01-11 2018-07-19 주식회사 투엔 빅 데이터 분석을 통한 배송인 추천방법
US20180252545A1 (en) * 2017-03-01 2018-09-06 Delphi Technologies, Inc. Destination-less travel system for an automated-vehicle
CN109922483B (zh) 2017-12-12 2020-12-15 华为技术有限公司 一种无线资源的调整方法及相关设备
CN108985506A (zh) * 2018-07-03 2018-12-11 蔚来汽车有限公司 行车路径推荐方法、预测方法、获取方法及其装置
US10740716B1 (en) 2019-08-27 2020-08-11 I Transport, Llc Methods and systems for coordinating physical transport of an object utilizing artificial intelligence
CN112362071B (zh) * 2020-11-10 2023-02-03 中国平安人寿保险股份有限公司 多目的地路线规划方法、装置及存储介质
DE102021133435A1 (de) * 2021-12-16 2023-06-22 Joynext Gmbh Austausch von Daten zwischen einer Navigationseinrichtung und einer Datenwolke zu einer Route

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20060064711A (ko) * 2004-12-09 2006-06-14 엘지전자 주식회사 복수 경유지를 탐색하는 네비게이션 시스템
KR20070099727A (ko) * 2006-04-05 2007-10-10 주식회사 현대오토넷 네비게이션 시스템의 다중 경로 탐색 및 안내방법
KR20080096274A (ko) * 2007-04-27 2008-10-30 팅크웨어(주) 네비게이션 시스템 및 네비게이션 경로 설정 방법
JP2011242363A (ja) * 2010-05-21 2011-12-01 Alpine Electronics Inc ナビゲーション装置およびその目的地設定方法
JP2012242370A (ja) * 2011-05-24 2012-12-10 Navitime Japan Co Ltd ナビゲーションシステム、端末装置、ナビゲーションサーバ、ナビゲーション装置、ナビゲーション方法、および、プログラム

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4441962B2 (ja) 1999-11-18 2010-03-31 株式会社エクォス・リサーチ 案内システム
JP3929305B2 (ja) * 2001-12-25 2007-06-13 トヨタ自動車株式会社 経路送信方法、センターおよび経路案内装置
JP2005233628A (ja) * 2004-02-17 2005-09-02 Kenwood Corp 案内経路探索装置、ナビゲーション装置および案内経路の探索方法
JP4645203B2 (ja) * 2005-01-19 2011-03-09 株式会社ケンウッド 案内経路生成装置および案内経路生成方法
US20070129886A1 (en) * 2005-12-06 2007-06-07 Toms Mona L Method for traffic-only access using integrated satellite radio data and navigation system
JP4742908B2 (ja) * 2006-02-24 2011-08-10 株式会社デンソー 経路設定装置、ナビゲーション装置、及びプログラム
GB2443472A (en) * 2006-10-30 2008-05-07 Cotares Ltd Method of generating routes
US8255158B2 (en) * 2007-03-23 2012-08-28 Verizon Patent And Licensing Inc. Travel route adjustment
KR101633889B1 (ko) 2009-02-18 2016-06-28 삼성전자주식회사 격자지도를 이용한 경로 생성 장치 및 방법
US9683854B2 (en) * 2009-07-19 2017-06-20 Aaron T. Emigh Pricing by historical comparison
JP5355718B2 (ja) * 2010-01-19 2013-11-27 三菱電機株式会社 地図データ作成装置、ナビゲーション装置およびこれらを用いた地図処理システム
JP2011069827A (ja) * 2010-10-15 2011-04-07 Aisin Aw Co Ltd ナビゲーション装置
US8706416B2 (en) * 2012-04-03 2014-04-22 Ford Global Technologies, Llc System and method for determining a vehicle route

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20060064711A (ko) * 2004-12-09 2006-06-14 엘지전자 주식회사 복수 경유지를 탐색하는 네비게이션 시스템
KR20070099727A (ko) * 2006-04-05 2007-10-10 주식회사 현대오토넷 네비게이션 시스템의 다중 경로 탐색 및 안내방법
KR20080096274A (ko) * 2007-04-27 2008-10-30 팅크웨어(주) 네비게이션 시스템 및 네비게이션 경로 설정 방법
JP2011242363A (ja) * 2010-05-21 2011-12-01 Alpine Electronics Inc ナビゲーション装置およびその目的地設定方法
JP2012242370A (ja) * 2011-05-24 2012-12-10 Navitime Japan Co Ltd ナビゲーションシステム、端末装置、ナビゲーションサーバ、ナビゲーション装置、ナビゲーション方法、および、プログラム

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111600965A (zh) * 2020-06-05 2020-08-28 支付宝(杭州)信息技术有限公司 区块链中的共识方法和系统
CN111600965B (zh) * 2020-06-05 2023-10-27 支付宝(杭州)信息技术有限公司 区块链中的共识方法和系统

Also Published As

Publication number Publication date
CN105144262A (zh) 2015-12-09
US9749930B2 (en) 2017-08-29
JP2016512604A (ja) 2016-04-28
CN105144262B (zh) 2017-12-19
US20160044571A1 (en) 2016-02-11
JP6140312B2 (ja) 2017-05-31

Similar Documents

Publication Publication Date Title
WO2014168428A1 (ko) 복수의 경유지를 포함한 최적 경로 전달 방법 및 이를 위한 장치
JP7459276B2 (ja) ナビゲーション方法および装置
JP6105747B2 (ja) 経路計算方法、経路獲得方法またはこのための装置
US9903721B2 (en) Method for transferring route and device therefor
US8897806B2 (en) Dynamic data publication and dissemination
US9576481B2 (en) Method and system for intelligent traffic jam detection
US9494431B2 (en) Method for acquiring or providing update information for route to third party and apparatus for same
JP2008198204A (ja) 走行ルートの走行時間を算出する方法および装置
US9983017B2 (en) Route calculating method, route acquisition method or terminal for same
KR20160125457A (ko) 트래픽 혼잡 경고를 제공하기 위한 방법들 및 시스템들
US9638541B2 (en) Method for calculating paths, method for obtaining paths as well as terminal for same
KR20140041124A (ko) 도착예정정보 자동 통보 장치 및 방법
US11511771B2 (en) Enhanced navigation and ride hailing
US11706643B2 (en) Route connectivity optimization mapping
KR20190000066A (ko) 사용자 위치 기반 여행지 이동 경로 정보 제공 서버 및 그 방법
Xin et al. Hybrid Navigation System That Combines Cloud and On-Board Computing
KR102591310B1 (ko) 재난 지역의 사용불가 경로 정보를 제공하는 네비게이션 서비스 방법 및 서버장치
KR20180138114A (ko) 재난 지역의 사용불가 경로 정보를 제공하는 네비게이션 서비스 방법 및 서버장치
JP2002015400A (ja) 移動体運行状況取得システム、移動体運行状況取得方法、および、記録媒体

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 201480020683.5

Country of ref document: CN

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 14783457

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2015562942

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 14782399

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 14783457

Country of ref document: EP

Kind code of ref document: A1