KR102591310B1 - Method and Server Apparatus for Navigation Service Providing Unusable Route Information Related to Emergency Area - Google Patents

Abstract

Disclosed is a navigation service method and server device that provides information on unusable routes in disaster areas.
According to one aspect of this embodiment, a process of configuring disaster area resources including unusable route information for a disaster area; and receiving travel parameters from a plurality of applications, and transmitting a link for accessing the disaster area resources to an application that has a request to provide unusable route information for a disaster area in the travel parameters, wherein the link The process of transmitting provides a method of transmitting a link that can access the same disaster area resource to applications that have a request to provide unusable route information for the same disaster area.

Description

Navigation service method and server device for providing unusable route information in disaster areas {Method and Server Apparatus for Navigation Service Providing Unusable Route Information Related to Emergency Area}

This embodiment relates to a navigation service method that can provide unusable route information in a disaster area and a server device to which the same is applied.

The content described in this section simply provides background information for this embodiment and does not constitute prior art.

In the past, a navigation terminal was used to detect the current location, that is, the starting point, through connection with a Global Positioning System (GPS), receive input of the destination of the trip from the user, and calculate the route in the terminal itself. However, with the recent spread and improved performance of smartphones, a service method that provides route information, route-related real-time traffic information, and various information from servers that provide traffic and route information using PNDs (Personal Navigation Devices) in mobile communication networks is being utilized. It is becoming.

In particular, while various types of navigation services are provided, the OMA (Open Mobile Alliance) standardization group uses a method of transmitting TPEG (Traffic Protocol Expert Group) information in the DMB (Digital Multimedia Broadcasting) network, where information is provided in the existing broadcast format. Instead, navigation services that deliver real-time traffic information P2P (Peer-to-Peer) through mobile communication networks or wireless IP (Internet Protocol)-based networks are becoming popular, and OMA LOC WG provides navigation services for the above services. The service framework (Navigation Service Framework, NavSe) is being standardized.

The NavSe standard defines a framework for providing users with functions for emergency rescue navigation services along with route and traffic information for vehicle navigation and indoor navigation for mobile communication-based navigation services. In the NavSe standard, route and traffic information for vehicle navigation uses the TPEG standard defined by ISO, which is already widely used in the market, and route information for indoor navigation uses the IndoorGML standard defined by OGC. IndoorGML is a standard for modeling indoor spaces for navigation purposes. The NavSe standard provides standardized routes and traffic information so that users can receive indoor and outdoor navigation services through ISO TPEG and OGC IndoorGML standard technologies.

Embodiments of the present invention, in a mobile communication-based navigation service, when a server provides information about unusable roads in an area where a disaster occurred, a navigation device that calculates the route on its own can efficiently calculate the route excluding unusable roads. The main purpose is to provide a navigation service method and server device to facilitate the provision of updated information when collecting information about additional unusable roads.

According to one aspect of the present embodiment, a method for a server to provide route information about a disaster area to a terminal capable of calculating a route includes: configuring disaster area resources including unusable route information about the disaster area; and receiving travel parameters from a plurality of applications, and transmitting a link for accessing the disaster area resources to an application that has a request to provide unusable route information for a disaster area in the travel parameters, wherein the link The process of transmitting provides a method of transmitting a link that can access the same disaster area resource to applications that have a request to provide unusable route information for the same disaster area.

Embodiments of the method may further include one or more of the following features.

In the process of configuring the disaster area resources, it may be configured to include unusable path information that is currently unusable for the disaster area and unusable path information that is expected to be unusable in the future.

The method includes receiving a subscription request for a notification service related to the disaster area from an application; And when the unusable path information is updated, the process of notifying the updated unusable path information to the application that has received the subscription request for the notification service may be further included.

In the process of configuring the disaster area resources, the process of configuring the disaster area resources to include unusable path information that is expected to be unusable in the future and notifying the application of the updated unusable path information is, If the unusable path actually becomes an unusable path, a notification message containing the id of the expected unusable path information can be transmitted.

In the process of notifying the application of updated unusable route information, if the current location is received from an application approaching the disaster area, the updated route information may be notified to the application.

The method may further include, when all paths in the disaster area have been normalized, sending a notification message notifying that all paths have been normalized to an application subscribing to the notification service.

The process of sending a notification message indicating that all of the above paths have been normalized is,

The server may transmit the notification message and delete resources related to the unusable road information, and the application may receive a notification message indicating that all routes have been normalized and discard the unusable road information.

The subscription request for the notification service may include a subscription resource created by the application setting notification conditions for the notification service.

The process of receiving a subscription request for the notification service may include receiving a subscription request for the notification service including the subscription resource for which a notification condition for receiving only updated unusable road information corresponding to the current location is set. You can.

The method may further include transmitting the location of the disaster area related to the travel parameter to the application when the travel parameter does not include a request to provide route information for the disaster area.

According to one aspect of the present embodiment, it is a server device that provides route information about a disaster area to a terminal capable of calculating a route. It is a server device that provides route information about a disaster area to a terminal capable of calculating a route. The terminal and a communication unit configured to communicate; and a control unit configured to provide traffic information on the route received from the terminal, wherein the control unit configures disaster area resources including unusable route information for the disaster area, and provides travel parameters from a plurality of applications. Receives and transmits a link to access the disaster area resources to an application that has a request to provide unusable route information for a disaster area in the travel parameters, and transmits a link to access the disaster area resource if there is a request to provide unusable route information for the same disaster area. A server device is provided that transmits a link to applications to access the same disaster area resources.

As described above, according to embodiments of the present invention, in an emergency rescue situation such as a disaster, road situation information in a disaster area is provided to a navigation device that can independently calculate a route in a mobile communication-based navigation service. This has the effect of allowing the route to be calculated using this.

Additionally, according to embodiments of the present invention, the resource usage of the service server can be reduced through the creation and use of common resources. By collecting new unusable path information from users, there is an effect of quickly collecting unusable path information and providing it to other users.

In addition, users subscribed to the notification service are immediately notified when new unusable route information occurs, thereby reducing the number of server connections, which has the effect of preventing server connection congestion and stably operating the server.

Figure 1 is a network configuration diagram for explaining the overall NavSe system, which is a navigation system of the present invention.
Figure 2 is a diagram showing the resource structure defined in the NavSe standard.
Figure 3 is a diagram showing the structure of a resource for providing unusable route information for a disaster area according to an embodiment of the present invention.
Figure 4 is a flowchart showing a process in which an application requests and receives unusable path information from a server according to an embodiment of the present invention.
Figure 5 is a flowchart illustrating the operation of an application and a server according to an embodiment of the present invention.
Figure 6 is a flowchart illustrating the operation of an application and a server according to another embodiment of the present invention.
Figure 7 is a block diagram of a terminal and a server configured to implement embodiments of the present invention.
Figure 8 is a diagram showing a computer system according to an embodiment of the present invention.

Hereinafter, some embodiments of the present invention will be described in detail through illustrative drawings. When adding reference numerals to components in each drawing, it should be noted that identical components are given the same reference numerals as much as possible even if they are shown in different drawings. Additionally, in describing the present invention, if it is determined that a detailed description of a related known configuration or function may obscure the gist of the present invention, the detailed description will be omitted.

Additionally, when describing the components of the present invention, terms such as first, second, A, B, (a), and (b) may be used. These terms are only used to distinguish the component from other components, and the nature, sequence, or order of the component is not limited by the term. Throughout the specification, when a part is said to 'include' or 'have' a certain component, this means that it does not exclude other components but may further include other components, unless specifically stated to the contrary. . In addition, ‘…’ stated in the specification. Terms such as 'unit' and 'module' refer to a unit that processes at least one function or operation, and may be implemented as hardware, software, or a combination of hardware and software.

The detailed description set forth below in conjunction with the accompanying drawings is intended to illustrate exemplary embodiments of the invention and is not intended to represent the only embodiments in which the invention may be practiced.

Reference is made to the OMA-TS-REST_NetAPI_NavSe-V1.0, and OMA-ER-NavSe-V1.0 standard documents, accessible at “http://member.openmobilealliance.org/ftp/Public_documents/LOC/Permanent_documents/” at the time of filing. It is incorporated herein by reference and is fully incorporated into this disclosure as if fully set forth herein.

Hereinafter, terms used in this specification are defined.

In this specification, an application refers to the implementation of a set of well-defined but non-standardized functions that perform tasks on behalf of a user. An application may consist of software and/or hardware components and an associated user interface.

Generally, in the technical field to which the present invention pertains, a server corresponds to an entity that provides resources to clients in response to requests.

Generally, in the technical field to which the present invention pertains, a client corresponds to a device, user agent, or other entity that operates as a recipient of a service.

In this specification, the NavSe Application corresponds to the entity responsible for interacting with the server to obtain route information, real-time and expected future traffic information. Accordingly, the NavSe application is mounted on terminals including smartphones, mobile phones, navigation devices, etc. Accordingly, in this specification, the NavSe application may be referred to interchangeably with the terminal and NavSe client (NavSe Client). In this respect, the NavSe application corresponds to a type of client.

In this specification, the NavSe Server corresponds to an entity responsible for providing route information, real-time and expected future traffic information to the NavSe application. In this respect, the NavSe server corresponds to a type of server.

In this specification, a location URI corresponds to a URI that allows the current location of a device to be obtained from a specific location server using a location acquisition protocol.

In this specification, a navigation device (ND) corresponds to an entity that assists the driver by showing the correct route to reach the final destination using GNSS (Global Navigation Satellite System) services. This entity can process real-time and predicted traffic information and dynamically estimate the optimal route based on user preferences.

In this specification, Lightweight ND (Lightweight ND) refers to a navigation device that has no capabilities for route calculation, and that requests and receives calculated routes from a server, for route prediction functions if a local map database is not available, and This corresponds to a navigation device that accesses a server to retrieve road shape representations.

In this specification, Smart ND corresponds to a navigation device that can calculate route(s) using a road network database available on the device itself.

As used herein, a Point Of Interest (POI) describes information about locations such as a name, category, unique identifier, or city address.

In this specification, as a unit for dividing roads, on general roads, the continuous road between intersections is called a segment, and on highways, the road is divided according to the policy of each highway and is defined as a segment. Traffic congestion or transit time can be determined on a segment-by-segment basis. In this specification, segments are used interchangeably with road sections.

In this specification, a segment sequence refers to a set of one or more consecutive segments. If necessary, a segment sequence consisting of one segment is also possible. Additionally, for example, in a segment sequence consisting of two or more segments, the end point of the first segment is the same as the start point of the second segment.

In this specification, a polyline corresponds to a continuous line used in graphics computing consisting of one or more line segments, defined by specifying the end points of each segment.

In this specification, route information corresponds to coordinate information of a set of segments and auxiliary data from a defined origin to a destination.

In this specification, traffic information corresponds to information consisting of traffic events and network performance parameters related to an area or route. Additionally, the traffic information may include current or future traffic information.

As used herein, Traffic Events are events related to an area or route imposed or planned by a road network operator (i.e. road works causing road closures) or events occurring outside the control of the network operator. (i.e., it corresponds to information about accidents).

In this specification, a network performance parameter corresponds to information about the performance or traffic flow (i.e., speed, delay, and time required) of each segment existing in an area or path.

In this specification, route information in full format refers to a form of route information that includes all segments from the origin to the destination. Unless otherwise stated, route information refers to the entire route.

In this specification, route information (Route Information in Summarized Format) refers to a form of route information that includes only segments selected for information summary among all segments from the origin to the destination.

In this specification, unusable route information corresponds to information about blocked or destroyed routes in areas where disasters such as fire, earthquake, flood, etc. occur.

In this embodiment, the navigation device refers to a device that can perform a route guidance function, and the navigation device is a portable or portable object such as a smartphone, mobile phone, mobile device, laptop, tablet PC, or smart pad. Includes all attachable electronic devices. Hereinafter, the navigation device may be referred to as a navigation device, Navigation Device, or ND.

NavSe, which is currently being standardized by OMA LOC WG, belongs to the form of delivering IP-based traffic information to navigation devices, and more specifically, belongs to the category of delivering IP-based traffic information in the form of P2P. In NavSe, navigation devices are divided into two types as follows. .

1. Smart ND (Smart ND, 122): A device that can calculate its own route and only requests real-time traffic information without receiving route information through the server.

2. Lightweight ND (121): A device that is unable to calculate the route on its own and requests all real-time traffic information, including route information, from the server.

In the NavSe standard, a smart ND (Navigation Device) calculates the driving route on its own based on traffic information provided by the NavSe server and provides it to the user. When a disaster (fire, flood, earthquake, quarantine, etc.) occurs in a specific area, traffic on some roads may be restricted, and roads on which traffic is proposed may continue to occur due to the disaster. In this situation, Smart ND can be used on roads where traffic is restricted. Because there is no information, a normal route cannot be provided to the user. When a disaster occurs, if the NavSe server provides Smart ND with unusable route information in a specific area where a disaster (fire, flood, earthquake, quarantine due to infectious disease, etc.) occurred, Smart ND provides unusable route information. Through route information, you can provide users with appropriate routes excluding unusable routes.

Hereinafter, in order for Smart ND to provide users with a route that takes into account unusable route information in the disaster area, Smart ND's NavSe application sends the NavSe server the unusable route information related to the disaster area or traffic related to the route estimated by the NavSe application. Describes the process for requesting and receiving information. Hereinafter, for explanation purposes, NavSe application and NavSe server may simply be referred to as application and server.

Figure 1 is a network configuration diagram for explaining the overall NavSe system, which is a navigation system of the present invention.

As shown in Figure 1, the navigation system of the present invention includes a navigation device capable of accessing a mobile communication network, a mobile communication network for wireless transmission and reception, a traffic information collection device to provide traffic information, and a traffic information and route providing server (NavSe Server). may include.

In this embodiment, the terminal can be connected to an IP network such as a mobile communication network or Wi-Fi as shown in the drawing, and is equipped with a navigation application for route guidance, and the application connects to a server to provide real-time traffic information. You can receive it and guide the route. Here, real-time traffic information refers to optimal route information calculated by the NavSe server and delivered to the terminal, real-time and predicted traffic information, and additional information related to traffic such as POI and weather.

Figure 2 is a diagram showing the resource structure defined in the NavSe standard.

Figure 3 is a diagram showing the structure of a resource for providing unusable route information for a disaster area according to an embodiment of the present invention.

In the NavSe standard, when an application requests a route or creates traffic information for the route, the NavSe server creates new resources and provides services according to each request of the NavSe application, as shown in FIG. 2. In other words, the NavSe resource structure shown in FIG. 2 is newly created for each request and the service is provided. Meanwhile, unusable route information for disaster areas corresponds to information provided equally to multiple users. Therefore, in this embodiment, for a disaster area, as shown in FIG. 3, only a single resource can be created and commonly provided to multiple users located in or passing through the disaster area.

Specifically, in NavSe, when a user creates a Trip resource by default, resources are configured below to provide different services for each request. Emergency Area resources are created independently by the server, regardless of the Trip resource, and provide the same service. Provide links to the same Emergency Area resources to users needing information. By providing information to multiple users with a single resource, resources wasted while generating the same information for each user on the server can be reduced. Users provided with the link can access Emergency Area resources and receive information on unusable routes in the disaster area.

Additionally, as necessary, users can subscribe to the Emergency Area resource to receive updated unusable route information, or upload the corresponding road information to the New Unusable Route resource when a new unusable road occurs in addition to the unusable route information in the provided Emergency Area. can do. When new unusable route information occurs in the New Unusable Route resource, the server updates the unusable route information in the Emergency Area resource. Additionally, the server can transmit a Notification to provide new unusable path information to notify other users who have subscribed to receiving updated unusable path information. By allowing users to update unusable path information, the server can quickly obtain additional unusable path information.

That is, according to this embodiment, the server can quickly collect newly unusable road information, quickly update unusable route information through this, and also quickly update unusable route information to other users subscribed to the notification service. Information can be provided.

Hereinafter, resources proposed for implementing the present invention will be briefly described. Other resources for implementing the present invention are defined in the NavSe standard and are therefore omitted in this specification.

1) Trip Structure: The first terminal acquires information such as departure point and destination as information transmitted from the user to set a route, and then transmits the information to the server. Requests for unusable route information or information about disaster areas may be included.

Element Type Optional Description originWGS84 Location_Point Choice Location information of the origin for route information and related traffic information requested from the server (Location_Point structure is defined in tpeg-locML [TTI LOG]. One element among originWGS84 or originAddress MUST be specified when Trip resource is created. This element is mandatory when the Trip resource is read by the client. This field can be used to indicate the assumed current position of the client, enabling route information updating procedure on the server.)
If the value of the unusableRoute parameter is True and the value of originWGS84 and the value of destinationWGS84 are the same, it indicates that the application requested unusable route information in the area containing the point specified by originWGS84. If the value of the unusableRoute parameter is True, but the value of originWGS84 and destinationWGS84 are different, it indicates that the application has requested unusable route information for a specific area along the route. originAddress Civic_Address Choice Location information of the origin expressed in the form of IETF Civic Address [RFC5139] (One element among originWGS84 or originAddress MUST be specified when Trip resource is created.) If the value of the unusableRoute parameter is True and the value of originAddress and the value of destinationAddress are the same, Indicates that the application requested unusable path information in the area containing the point specified by originAddress. If the value of the unusableRoute parameter is True, but the value of originAddress and destinationAddress are different, it indicates that the application requested unusable route information for a specific area on the route. destinationWGS84 Location_Point Choice Location information of the destination for route information and related traffic information requested from the server (Location Point structure is defined in tpeg-locML [TTI LOC]. In case that Trip resource is created for an emergency, this field may not be specified, otherwise one element among destinationWGS84 or destinationAddress MUST be specified when Trip resource is created. This structure is mandatory when the Trip resource is read by the client.) If the value of the unusableRoute parameter is True and the value of destinationWGS84 and the value of originWGS84 are the same, the application Indicates that unavailable route information for the area containing the point specified by this originWGS84 has been requested. If the value of the unusableRoute parameter is True, but the value of destinationWGS84 and originWGS84 are different, it indicates that the application requested unusable route information for a specific area along the route. destinationAddress Civic_Address Choice Location information of the destination expressed in the form of IETF Civic Address [RFC5139] (In case that Trip resource is created for an emergency, this field may not be specified, otherwise one element among destinationWGS84 or destinationAddress MUST be specified when Trip resource is created. This structure may be provided by the server in case the user defines a destination using destinationWGS84 structures.) If the value of the unusableRoute parameter is True and the value of destinationAddress is the same as the value of originAddress, the application will not operate in the region containing the point specified by originAddress. Indicates that unavailable route information was requested. If the value of the unusableRoute parameter is True, but the value of destinationAddress and originAddress are different, it indicates that the application requested unusable route information for a specific area along the route. waypoints Location_Point [0… unbounded] Yes Location information of waypoints (Location_Point structure is defined in tpeg-locML [TTI LOC].) startingTime xsd:dateTime Yes Start time of your planned trip. If it does not exist, the current time is used. endingTime xsd:dateTime Yes The planned trip end time, provided by the server based on route estimation tollRoad xsd:boolean Yes Checks whether toll roads should be included in the route estimate; if the value is true or does not exist, toll roads are allowed. vehicleType xsd:string Yes Type of vehicle requesting route information (This field SHALL be encoded according to the list of values defined in table RTM01 provided in [TTI RTM]) calculateRoute TripQueryType[1… 2] Yes For a defined trip, whether the server should propose a set of routes along with relevant traffic events and performance parameters, or alternative routes in case of congestion (If this parameter is set to NoAction or absent, the route will be estimated) by the N.D.) requestedEventsCategories xsd:string [0… unbounded] Yes Categories of traffic information related to defined trips (This field shall be encoded according to the list of values defined in the rtm00 table available in [TTI RTM]. If this field is not present, the server MUST provide traffic information for all defined categories (including network performance parameters).) unusableRoute xsd:boolean Yes Indicates whether the application requested unusable route information in a specific area. If the value of this parameter is True, it indicates that the application requested unusable route information for a specific area. If the server provides this parameter, it indicates that there may be a disaster area on the route where the application will drive. Location information on disaster areas is provided through disasterArea. disaster area Location Container[0… unbounded] Yes When the server includes an unusableRoute, it provides location information of the disaster area. link common:Link [0… unbounded] Yes Link to a reference route resource (Attribute "rel" must be set to "Route" or "unusableRoute".) resourceURL xsd:anyURI Yes Self-referring URL. (The resourceURL SHALL NOT be included in POST requests by the client, but MUST be included in POST requests representing notifications by the server to the client, when a complete representation 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 PUT requests.)

2) Emergency Area Structure: Defined to provide an unusable path provided from the server to the terminal. Unlike existing resource structures, this resource is configured and exists solely on the server.

Element Type Optional Description areaDesc Location Container No Indicates the area where unusable road information is provided. It is encoded according to Location Container structure as defined in tpeg-locML. unusableRoute unusableSegment[0… unbounded] Yes Indicates unusable roads within the area specified in areaDesc. If all roads in a specific area within the area specified in areaDesc are unusable roads, it can be expressed as unusableArea instead of unusableRoute. expectedUnusableRoute expectedRoute[0… unbounded] Yes Indicates roads that are currently passable within the area specified in areaDesc, but are expected to become unusable in the future due to a disaster. unusableArea Location Container[0… unbounded] Yes Indicates an area with unusable roads. If all roads in a specific area within the area specified in areaDesc are unusable roads, unusable road information is expressed as unusableArea instead of unusableRoute. The maximum size of the area expressed as unusableArea is the same as areaDesc (if unusableArea and areaDesc are the same, it indicates that all roads in the disaster area are unusable). expectedUnusableArea expectedArea[0… unbounded] Yes It represents an area that is currently passable within the area specified in areaDesc, but is expected to become unusable in the future due to a disaster. resourceURL xsd:anyURI Yes Self-referring URL. The resourceURL SHALL NOT be included in POST requests by the client, but MUST be included in POST requests representing notifications by the server to the client, when a complete representation 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 PUT requests.

The server expresses the entire disaster area through the areaDesc parameter and provides unusable route information to the application through unusableRoute or unusableArea. unusableArea reduces the amount of data provided to the application by expressing the area containing each path rather than providing information on each path individually when all paths in a specific area are unusable paths, and all paths in the disaster area are unusable. It makes it easy to express the case of an unusable path (this applies to cases where the value of areaDesc and the value of unusableArea are the same). In this embodiment, the unusableSegment representing the actual unusable road in the emergencyArea resource is shown in [Table 3] below. In emegencyArea, 0 or more unusableSegments below can be included to represent unusable roads in a specific area (disaster area).

Element Type Optional Description originPoint Location_Point No This field represents the origin of the unusable segment encoded according to Location_Point structure as defined in tpeg-locML [TTI LOG]. endpoint Location_Point No This field represents the end of the unusable segment encoded according to Location_Point structure as defined in tpeg-locML [TTI LOG]. midwayPoint Location_Point [0… unbounded] Yes This field is used to identify unambiguously the target road segment.It is encoded according Location_Point structure as defined in tpeg-locML [TTI LOG]. linkName xsd:string Yes Name of the road or street, which the segment belongs to.

expectedUnusableRoute and expectedUnusableArea represent routes that are currently usable but are expected to be unusable in the future due to a disaster. The application considers expectedUnusableRoute and expectedUnusableArea when calculating the route (for example, if it passes directly through the path specified by expectedUnusableRoute and expectedUnusableArea, it uses the route; if it passes through the specified path late, it does not use it), and updates the route in the application in the future. facilitates. In this embodiment, the expectedRoute representing roads that will be unavailable in the emergencyArea resource in the future is shown in [Table 4] below. In emegencyArea, 0 or more expectedRoutes below may be included to represent roads that will be unusable in the future.

Element Type Optional Description id xsd:string No ID of the expected unusable road information provided expectedRoute unusableSegment[1… unbounded] No Indicates expected unusable road information.

In this embodiment, the expectedArea representing the future unusable area in the emergencyArea resource is shown in [Table 5] below. In emegencyArea, 0 or more expectedArea below may be included to represent areas that will be unavailable in the future.

Element Type Optional Description id xsd:string No ID of the predicted unusable road information area provided expectedArea Location Container No Indicates local information including roads that are expected to be unusable.

Additionally, if there is new unusable route information in addition to the previously provided unusable route information, the application creates a newUnusableRoute resource on the server and provides the newly generated unusable route information to the server. newUnusableRoute resources are shown in [Table 6] below.

Element Type Optional Description newUnusableRoute unusableSegment[0… unbounded] Yes Displays newly updated unusable road information. This parameter is used when the application provides new unusable road information to the server.

3) Subscription Structure: Through Subscription, the application can be set to automatically receive notification from the server when there is new unusable route information in the disaster area. ND's application according to an embodiment of the present invention provides a notification service for update information. By subscribing, you can receive notification messages whenever unusable road information is updated. At this time, when the application monitors unusable road information through the web, etc., it can immediately receive continuously updated unusable road information.

However, for users who receive a route through an application, updating unusable road information may not be necessary immediately if they are far away from the disaster area during the route, and continuously updated unusable road information may not be needed immediately. Network resources can be used to receive continuously updated unavailable road information in situations where it is not needed. The present invention proposes a method to solve this problem.

The application may access the resources of the server device where the unusable road information is stored, receive the unusable road information, and then transmit a subscription request for a notification service to receive updated unusable road information.

At this time, when the application creates a subscription resource to transmit a subscription request for the notification service, it can set its desired notification conditions. For this purpose, the parameters added to the subscription resource are as listed in Table 7.

Element Type Optional Description callbackReference common:CallbackReference No Client's Notification endpoint and parameters. link common:Link [1… unbounded] No References to resources subscribed by the application. Attribute "rel" indicates the type of resource subscribed. It may assume the following values:· "Trip": in order to get notified about:
o new traffic events and performance parameters related to the set of routes defined for the trip
o new alternative route proposals
· “Area”: in order to be notified of new traffic events and performance parameters updates
· "UnusableRoute": To be notified of updated unusable road information in a specific area
Attribute "href" specifies the URL of subscribed resource. Subscribed resource's type must be the same of that specified in "rel" attribute.
Note: notified information for an existing route are:
a) new traffic events provided with links included in the route resource itself;
b) performance parameters available in updated performanceParameter filed of segment structures. trackingProc xsd:boolean Yes If present and set to True, the application communicates to the server user's availability to provide position information through an external location application. deviceLocationURI xsd:anyURI Yes This parameter is used by the server for accessing Navigation Device position information. allUpdates xsd:boolean Yes If ND is provided with unusable road information in a disaster area and subscribes to the notification service to receive update information, if the value of this parameter is TRUE, all update information can be notified to ND. (In order for ND to receive all updated information on disaster area unusable road information, this parameter must be included.) In other cases, this parameter may be omitted. currentPos Location_Point Yes ND is provided with unusable road information in disaster areas and subscribes to the notification service to receive update information. If the value of the allUpdates parameter is not TRUE (FALSE), ND provides the current location information in this parameter. can be provided. resourceURL xsd:anyURI Yes Self-referring URL. The resourceURL SHALL NOT be included in POST requests by the client, but MUST be included in POST requests representing notifications by the server to the client, when a complete representation 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 PUT requests.

When an application creates a subscription resource to subscribe to a notification service for updates, if it wants to receive all update information, it can create a subscription resource that sets a notification condition including the allUpdates parameter with a TRUE value and send a subscription request. If the allUpdates parameter is confirmed to have a TRUE value in the notification condition included in the application's subscription request, the server device determines that the application wishes to receive all updated unusable road information, and sends updated information to the application. A notification message containing all unusable road information can be sent.

Additionally, if the application wants to receive updates on unusable road information in a disaster area only when necessary, it can send a subscription request by creating a subscription resource that does not include the allUpdate parameter or sets the notification condition to a FALSE value.

At this time, the application may include its current location information in the currentPOS parameter. At this time, when the application arrives near the disaster area, it can update the location information of the currentPOS parameter with its current location information.

At this time, the server device can check the current location of the ND through the location information of the currentPOS and determine whether the ND has arrived near the disaster area and needs update information. If the ND is near the disaster area, the server device can send the ND a notification message containing updated unusable road information near the disaster area.

Accordingly, the server device and method according to an embodiment of the present invention can provide updated unusable road information only at the time or location required by the ND. Through this, server devices and NDs can reduce waste of resources.

4) Notification Structure: The server notifies through Notification that there is newly updated unusable path information and provides a link to receive the updated unusable path information.

Element Type Optional Description link common:Link [1… unbounded] No Link to updated resources. Attribute "rel" attribute indicates type of resource updated and may assume "Trip", "Route", "Event", "Area" and "UnusableRoute" values. expectedInfoUpdate xsd:string Yes Contains the ID of the provided expectedUnusableRoute or expectedUnusableArea. Notifies that the route or area of expectedUnusableRoute or expectedUnusableArea indicated by the ID included in this parameter is currently an unusable road. noUnusableRoute xsd:boolean Yes This can indicate that all unusable roads in the disaster area have become roads that can be used normally. At this time, the value of this parameter may have the value TRUE.

Through EmergencyArea, the server provides the application with information (expectedUnusableRoute, expectedUnusableArea) on roads that are currently usable but are expected to become unusable in the future. If a road that is expected to be unusable in the future actually becomes unusable, the server must deliver a notification including a link to the application so that the application receives updated unusable route information. In this case, you can notify that the already provided expected unusable path information has actually become unusable by including the ID of the expectedUnusableRoute or expectedUnusableArea already provided in the notification delivered to the application. When unusable path information is updated, the number of times a user connects to the server to receive updated unusable path information can be reduced, and as a result, ND can quickly create a new path while preventing a surge in server connections in an emergency disaster situation. Calculate and provide it to the user. In addition, the server creates resources to provide unusable road information in disaster areas, and the application connects to a single resource created by the server to receive unusable road information and receive updated unusable road information. A subscription request for a notification service may be sent. The services that use unusable road information are different for each application, and the period for using the information may be different.

In relation to this, the prior art may have the following three problems.

1. When an unusable road in a disaster area becomes a normal road, the server can send a notification message to all NDs who have subscribed to the updated unusable road information notification service. At this time, all NDs that have received the notification message can access the resources provided by the server and confirm that the unusable road has become a normal road. However, because the subscribed NDs connect to the NavSe server at the same time, problems may occur with the NavSe server due to multiple simultaneous connections.

2. ND, which confirms that an unusable road has become a normal road, can cancel its subscription to the notification service. However, NDs that have previously terminated the notification service may not cancel their notification service subscription because they are not connected to the NavSe server even if they receive a notification message. Because the notification service subscription has not been canceled, the server continues to have unusable road information resources. As a result, a problem may arise where the server continues to retain unused resources.

3. ND, which holds unusable road information, can provide users with a new route by reflecting this in the route when all roads return to normal. However, network problems may occur in disaster areas, etc., and ultimately, ND, which cannot obtain normal road information due to network problems, may continue to provide route information based on unusable road information.

In order to solve the problems described above, the method according to an embodiment of the present invention allows the server to notify the application that all roads in the disaster area have become normal roads through a notification message.

At this time, when all roads in the disaster area become normal roads, the server can notify all applications subscribing to the notification service that all roads in the disaster area have become normal through a notification message.

At this time, when all unusable roads within the disaster area become roads that can be used normally, the server can send a notification message including the 'noUnusableRoute' parameter to all applications subscribing to the notification service.

At this time, all applications that have received the notification message can discard all unusable road information, recognize all roads as normal roads, and provide routes to the user. At this time, the server may delete all resources related to unusable road information.

Through the method according to an embodiment of the present invention, it is possible to prevent multiple applications from accessing the server simultaneously when providing a notification service, and route information is provided so that the application can quickly notify that an unusable road has become a normal road. It can be updated. Additionally, it can prevent the server from maintaining unnecessary resources.

Figure 4 is a flowchart illustrating a process in which an application requests and receives unusable path information from a server according to an embodiment of the present invention. Below, with reference to FIG. 4, a process in which the server provides unusable route information for a disaster area to an application will be described.

1. The user sets Journey parameters to request unusable route information for a specific area (disaster area).

2. The application sends a request to the server to receive link information that can access unusable path information.

3. The server responds to the application with link information that can access unusable path information.

4. The application requests unusable path information from the server using the provided link.

5. The server provides unusable route information for a specific area (disaster area) requested by the application.

6. The application subscribes to the notification service to receive updated unusable path information.

7. When the unusable path information is updated, the server sends a notification message notifying that it has been updated to the application that has subscribed to the notification service.

8. The application requests updated unusable path information. If the ID of the predicted unusable path information is notified in the previous step 7, this step 8 and the next step 9 can be omitted.

9. The server provides updated unusable path information.

10. While using the navigation service, the user detects that there is a new unusable road that did not exist before.

11. The application transmits new unusable path information to the server.

12. The server uses the received unusable path information to update the unusable path information in a specific area and delivers an update notification message to other applications that have subscribed to the unusable path information notification service.

Unusable route information may continuously change due to changes in real-time road conditions due to disasters. Therefore, a method is needed to efficiently provide continuously updated unusable path information to applications. In this embodiment, there may be three cases where a user requests information through the NavSe application regarding unusable route information as follows.

(a) If a disaster (fire, collapse) occurs in an indoor area such as a building or underground, or a narrow outdoor area, and unusable route information is requested to calculate an escape route, ND provides the user with an indoor navigation service or disaster relief service. It provides outdoor navigation services for local areas and also provides unusable route information for specific areas.

(b) If a user using a general navigation service recognizes that there is a disaster area on the route to his or her destination and requests information on an unusable route in the disaster area, ND provides the user with an outdoor navigation service. It also provides unusable route information in disaster areas located along the route.

(c) If a user using a general navigation service does not recognize that there is a disaster area on the route to his or her destination and requests only general information, ND similarly provides the user with an outdoor navigation service and provides information on disaster areas located on the route. Information on routes that cannot be used in disaster areas is also provided, and in this case, the process of informing the user that there is a disaster area on the route is preceded.

Below, for each case, a process in which an application requests and receives unusable route information for a disaster area from a server will be described. Referring to the drawings, a process in which the application and the server configures resources will be explained.

In case (a), when a disaster occurs in a limited space such as an indoor space such as a building or basement, or a narrow outdoor area, a method is used when the user requests unusable route information to calculate a route for movement such as escape. am.

The NavSe application can provide services for navigation terminals, and since it can provide services through the web even if it is not a navigation terminal through web access, it can also be used as a service to check information on unusable routes in the current disaster area. there is. For example, in order to efficiently carry out rescue activities in a fire department, a use case is possible where information on unusable routes for fires or burned buildings is checked through the web and instructions are given for the movement and deployment of rescue personnel. Additionally, if a disaster such as a fire occurs indoors, such as in a building, it may be difficult for the service provider to check unusable route information. In this case, a rescue worker enters the room and provides the unusable route information to the NavSe server using the NavSe application, or a situation room that contacted the rescue worker in another way provides the unusable route information to the NavSe server via the web. As an example of providing unusable route information to users, it is also possible to check unusable route information through CCTV in the building's situation room/management room and provide it to the NavSe server through the web, etc.

Users of the application define travel parameters for origin, destination, indicators requesting unusable route information related to disaster areas, and other preferences. At this time, the indicator of the travel parameter indicates that the application is requesting unusable route information, and if the origin and destination are the same, it indicates that the application is requesting unusable route information related to the disaster area including the locations of the origin and destination ( case (a)). If the origin and destination of the travel parameters are different, it indicates that unusable route information for a specific area that exists on the route from the origin to the destination is requested (in case (b)).

When the application uploads travel parameters to the server, the application accesses the unavailable route information through a link provided by the server. Since unusable route information is common information for users who want to obtain unusable route information in disaster areas, the server creates one disaster area resource to provide route information, and users can use it to reduce the number of resources on the server. Provides a link to commonly unavailable route information. At this time, the server may provide information about an unusable path that is expected to be currently available but not expected to be available in the future.

After the application accesses unavailable path information, it automatically subscribes to the notification service without user interaction. When a new unusable path occurs in the disaster area, a notification message is triggered from the server to the application. Applications can access updated traffic information.

When the predicted unusable path already provided by the server becomes an actual unusable path, the server triggers a notification message containing the id of the predicted unusable path information to the application. After the application receives the notification message, the application updates the unavailable path information internally using the provided predicted unavailable path information. A notification message containing the predicted unavailable path information and the id of the unavailable path information is used to reduce the number of applications accessing the server.

The application receives information about new unusable path information from the ND user. The server updates unusable path information using unusable path information uploaded from the application.

Figure 5 is a flowchart showing the operation of an application and a server according to an embodiment of the present invention. Through the same process as the flowchart shown in FIG. 5, the server can provide the application with unusable route information for a specific disaster area.

1. The user of the application defines journey parameters and the application uses the travel parameters to post a travel description to request unusable route information related to the disaster area specified by the user. The server responds with a generated "trip" resource containing a link to access out-of-service route information related to the disaster area.

2. The application accesses unusable path information.

3. The application subscribes to the notification service for updated unusable path information.

At this time, the application can set notification conditions for the notification service and send a subscription request including the generated subscription resource to the server.

At this time, the server may receive a subscription request for a notification service that includes a subscription resource for which a notification condition is set for the application to receive only updated unusable road information corresponding to the current location.

At this time, when the application creates a subscription resource to subscribe to the notification service for updates, if it wants to receive all update information, it creates a subscription resource that sets notification conditions including the allUpdates parameter with a TRUE value. A subscription request can be sent.

Additionally, if the application wants to receive updates on unusable road information in a disaster area only when necessary, it can send a subscription request by creating a subscription resource that does not include the allUpdate parameter or sets the notification condition to a FALSE value.

At this time, the application may include its current location information in the currentPOS parameter. At this time, when the application arrives near the disaster area, it can update the location information of the currentPOS parameter with its current location information.

4. When the unusable path information is updated or the predicted unusable path becomes an actual unusable path, the server notifies the application.

At this time, if the allUpdates parameter in the notification condition included in the application's subscription request is confirmed to have a TRUE value, the server determines that the application wishes to receive all updated unusable road information and sends all updated information to the application. A notification message containing unusable road information can be transmitted.

At this time, the server can check the current location of the ND through the location information of currentPOS and determine whether update information is needed as the application has arrived near the disaster area. If the application is near a disaster area, the server may send the application a notification message containing updated unusable road information near the disaster area.

5. The application accesses updated route information.

6. When the ND user detects a new unusable path, the user uploads the new unusable path information to the server through the application. The server updates unusable path information.

In case (b), when the user is trying to proceed with a route through a general navigation service, but recognizes that there is a disaster area on the route, and the NavSe application requests traffic information from the NavSe server, the route is unusable in the disaster area. This is a method of requesting information together.

Users of the application define travel parameters (origin, destination, and road characteristics, etc.), and these parameters are uploaded to the server through the application. Smart ND estimates one or more geographic areas relevant to a defined trip and accesses traffic information (events and performance parameters) reported from the server for the selected area. The application uses traffic information, and ND suggests to the user a set of routes for a defined trip to avoid congested road sections, and from the proposed routes, the user selects a reference route.

The application uploads the selected route to a server accessed with traffic information (real-time and predicted performance parameters). Additionally, for real-time optimal route estimation, the application subscribes to a travel-related notification service to receive updated traffic information (performance parameters and traffic events for selected categories) related to the route in use.

If the application requests unusable route information in a disaster area when defining and uploading travel parameters, the server responds with an additional link to access the unusable route information. Since unusable path information is common information for users who want to obtain unusable path information in disaster areas, the server creates a disaster area resource to provide unusable path information and uses it to reduce the number of resources on the server. A link is commonly provided to users who wish to access unavailable route information. The application accesses the unusable route information, and the ND can calculate a set of routes based on the unusable route information for the defined trip.

If the application did not request unusable route information in the disaster area when defining and uploading the travel parameters, and unusable route information exists in the disaster area related to the travel parameters, the server provides additional links and links to access the unusable route information. Respond with disaster area information. Applications can access dead path information for route calculations. Additionally, for real-time optimal route estimation, subscription to a notification service for updated unusable route information is required.

Since the unusable route information for the disaster area may be updated frequently, to reduce the number of notifications received from the server, the application subscribes to the notification service when the ND arrives near the disaster area. When the ND arrives near the disaster area, the application uploads the ND's current location to the server. The server responds to the application with a link to access the latest dead path information. The application accesses the unavailable path information and subscribes to a notification service for updated unavailable path information.

If an accident and/or severe congestion and/or a new unusable route occurs around the current route, a notification message is triggered from the server to the application. The application uses the notification message to access updated traffic information and/or updated unavailable route information available for the route, and the ND estimates an alternative route and requests relevant traffic information from the server.

If the new route is less congested than the old route, the old route is deleted by ND because ND is no longer interested in servicing notifications for that resource. In case the performance of the proposed alternative route is poor, ND can explore a less congested route before deleting the old route. ND iteratively estimates a set of alternative routes and uploads them to the server. Applications can choose to upload partial paths for bandwidth optimization.

The application periodically reports its current location to the server based on the distance traveled. Using the updated location information, the server can delete segments that have already been passed by the vehicle from the route representation. In the next step, if the vehicle deviates from the planned route, ND estimates a new route, which is uploaded to the server to access new traffic information. The new route replaces the old route, and the notification service contains the new resource.

Additionally, when all paths in a disaster area are normalized, the server can send a notification message notifying that all paths have been normalized to applications subscribing to the notification service.

At this time, the server sends a notification message to the application and deletes resources related to the unusable road information, and the application receives a notification message indicating that all routes have been normalized and discards the unusable road information.

At this time, the server can create a notification message with the ‘noUnusableRoute’ parameter set to TRUE and send it to the application to notify that all routes have been normalized.

Figure 6 is a flowchart showing the operation of an application and a server according to another embodiment of the present invention. Through the same process as the flowchart shown in FIG. 6, the server can provide the application with unusable route information about possible disaster areas along the route related to travel.

1. The user of the application defines travel parameters and the application posts a travel description using the travel parameters. The server responds to the application with a generated “trip” resource including a trip ID and defined parameters. The application specifies that the route estimation function is not requested. When an application requests an unavailable path, the application specifies that unavailable path information is requested. If unusable route information for the disaster area associated with the travel parameter exists, and the application does not specify that unusable path information is requested, the server responds by specifying that unusable path information related to the travel parameter exists along with the disaster area. . In this process, when the application creates trip information in step 1, it includes the unusableRoute parameter to indicate that there is a disaster area on the route and that it wants to receive unusable route information from the disaster area. The server provides the application with a link to receive unusable route information in the disaster area.

2. The application posts an area description requesting traffic information related to the trip (in this case, the Area structure is identified by the coordinates of the origin and destination). The server may select a category for traffic events for an area related to the described trip and respond with traffic information including the selected category. In case of severe congestion, it can respond with performance parameters for the area around the origin.

3. The application requests traffic events from the server and reads the traffic information reported from the server. This information, along with the performance parameters obtained in step 2, is used by ND to estimate a set of routes that avoid critical route segments (affected by accidents, construction, or congestion). If the application or server specified parameters for unavailable path information in step 1, the application reads the unavailable path information using the reported link. In step 3, road information of the route to be taken is collected from the NavSe server. At this time, the NavSe application also receives unusable route information in the disaster area using the link received in step 1.

4. The application uploads the expected route (selected by the user from the set proposed by ND) to the server. The server responds with a 'route' resource containing performance parameters and links to traffic events.

5. The application subscribes to the notification service for the selected area (step 2) and the uploaded path (step 4). If the ND arrives near the disaster area while the ND is using unusable route information, the application modifies the source parameter of the trip resource and reads the latest unusable route information using the reported link. And the application subscribes to the notification service for unavailable path information. The application is notified of performance parameters and traffic events related to the selected region and route uploaded for the trip. The application subscribes to a notification service for unusable route information when the ND arrives near the disaster area. The application is notified of updated unavailable path information.

6. The application periodically updates the current location and transmits it to the server to modify the existing parameters of the trip resource. This task is triggered whenever the vehicle has driven a certain distance from the previous reporting location. The server uses this information to delete segments that have already been driven from the route information. If the application has acquired the location information of the disaster area through the Emergency Area resource connected to the link in step 1, the current location information of the application is transmitted to the server when the user's current location approaches the disaster area. The server that receives the application's location information provides a link to receive the current Emergency Area resources, and the application receives new unusable path information through the link, and provides a notification service to receive updated unusable path information. Join .

That is, in step 5, the application subscribes to only the general notification service, and subscribes to the notification service to receive unusable route information that is updated only when arriving near or within the disaster area.

Through this method, the server and application do not continuously provide updated information every time unusable path information occurs in a disaster area, but provide unusable path information that is up-to-date or updated only when it reaches the disaster area, allowing the server and application to Operation between applications can be reduced.

7. If the server detects traffic events and/or severe congestion and/or new unusable route information around the proposed route, the server notifies the application.

8. The application accesses updated traffic information (selected traffic events and performance parameters) related to the route or updated unavailable route information.

The server provides updated traffic information about the current route and/or updated unavailable route information to the application through the specified link. And when the road information is updated, the server notifies the application that there is updated information, as in step 7, and the application receives updated information from the server, as in step 8.

9. ND decides to recalculate the new route under the following conditions.

a) When the application collects updated traffic information in step 8

b) When ND detects that the vehicle has veered away from the defined path.

c) When the application receives updated unusable path information and receives that the current path is affected by the updated unusable path information.

Depending on whether to keep the previous information determined by the application valid, the application uploads the newly calculated route to the server by putting to the existing route or POSTing to the route factory resource through a modification or creation operation. The server responds with a "root" resource containing performance parameters. This step can be performed iteratively until the recalculated path is better than the previous path. However, to avoid loops, the application can define a new region description to obtain traffic information for regions where repeated queries occur, similar to those described in steps 2 and 3.

10. The application deletes previous routes from the proposed route set if they are no longer used. If the performance of the newly calculated route is worse than the route in use, the application deletes the newly calculated route from the set of proposed routes. The application deletes (DELETE) the subscription to the notification service in the old path (if, through a modification operation, the new path replaces the old one, the DELETE operation in step 9 is not necessary).

In case (c), the user is not aware that there is a disaster area in the route he is taking and uses a general navigation service.

In step 1 of the basic Smart ND procedure, the NavSe application creates a Trip resource on the NavSe server. If the application did not request unusable route information in the disaster area when defining and uploading the travel parameters, and unusable route information exists in the disaster area related to the travel parameters, the server provides additional links and links to access the unusable route information. Respond with disaster area information. Applications can access dead path information for route calculations. The NavSe server notifies the NavSe application that there may be a disaster area on the route to be driven by including the unusableRoute parameter, and provides location information of the area where the disaster occurred through the disasterArea parameter. It also provides a link to receive unusable path information through the link parameter.

The area where a disaster occurred is confirmed through disasterArea, and the NavSe application calculates a route by avoiding the disaster area, or receives unusable route information through a link and uses it to calculate and provide a route. The case where unusable route information is received through the subsequent link and the route is calculated using this is the same as case (b).

Figure 7 is a block diagram of a terminal and a server configured to implement embodiments of the present invention. Each component shown in FIG. 7 may be implemented as a hardware chip, or may be implemented as software so that a microprocessor executes the functions of the software corresponding to each component.

The terminal 710 may include a communication unit 711 configured to communicate with the server 720 and a control unit 712 configured to calculate a route through traffic information received from the server 720. The server 720 may include a communication unit 721 configured to communicate with the terminal 710 and a control unit 722 configured to collect and process traffic information based on travel-related parameters such as departure and destination information received from the terminal. You can.

One embodiment of the present invention to be described in relation to FIG. 7 is an embodiment in which the terminal 710 is a smart ND. In this embodiment, the control unit 722 configures resources containing route information about the disaster area, receives travel parameters from multiple applications, and provides route information about the disaster area based on the travel parameters. By determining the terminal 710, a link that can access the resource can be transmitted, and a link that can access the same resource can be transmitted to the terminal 710, which is provided with route information for the same disaster area. At this time, the resources may include unusable path information that is currently unusable for the disaster area and unusable path information that is expected to be unusable in the future.

In addition, the control unit 722 receives a subscription to a notification service related to a disaster area from the terminal 710, and when the route information is updated, the control unit 722 sends the updated route information to the terminal 710 that has subscribed to the notification service. You can notify.

In addition, when the expected unusable path information becomes an actual unusable path, the control unit 722 efficiently provides updated information to the terminal 710 by transmitting a notification message including the ID of the expected unusable path information. It can be transmitted to, and the connection to the server 720 can be prevented from being overloaded.

Additionally, the control unit 722 may receive the current location from the terminal 710 and notify the terminal 710 of updated route information when approaching an area where a disaster occurs.

Additionally, if the travel parameters do not include a request for route information about the disaster area, the control unit 722 may transmit the location of the disaster area related to the travel parameter to the terminal 710.

Additionally, when all paths in a disaster area have been normalized, the control unit 722 can transmit a notification message notifying that all paths have been normalized to the terminal 710 subscribing to the notification service.

At this time, the control unit 722 transmits a notification message and deletes resources related to the unusable road information, and the terminal 710 receives a notification message indicating that all routes have been normalized and discards the unusable road information. can do.

At this time, the subscription request for the notification service may include a subscription resource created by the terminal 710 setting notification conditions for the notification service.

At this time, the control unit 722 may receive a subscription request for a notification service including a subscription resource for which a notification condition is set for the terminal 710 to receive only updated unusable road information corresponding to the current location.

4 to 6 depict processes as being sequentially executed, but this is merely an illustrative explanation of the technical idea of an embodiment of the present invention. In other words, a person of ordinary skill in the technical field to which an embodiment of the present invention pertains may change and execute the sequence shown in FIGS. 4 to 6 or perform any of the processes without departing from the essential characteristics of an embodiment of the present invention. Since various modifications and variations can be applied by executing one or more processes in parallel, FIGS. 4 to 6 are not limited to the time series order.

Meanwhile, each step of the flowchart shown in FIGS. 4 to 6 can be implemented as computer-readable code on a computer-readable recording medium. Computer-readable recording media include all types of recording devices that store data that can be read by a computer system. That is, computer-readable recording media include storage media such as magnetic storage media (eg, ROM, floppy disk, hard disk, etc.) and optical read media (eg, CD-ROM, DVD, etc.). Additionally, computer-readable recording media can be distributed across networked computer systems so that computer-readable code can be stored and executed in a distributed manner.

Figure 8 is a diagram showing a computer system according to an embodiment of the present invention.

Referring to FIG. 8, the terminal 710 and server 720 according to an embodiment of the present invention may be implemented in a computer system 1100 such as a computer-readable recording medium. As shown in FIG. 8, the computer system 1100 includes one or more processors 1110, a memory 1130, a user interface input device 1140, and a user interface output device 1150 that communicate with each other through a bus 1120. and storage 1160. Additionally, the computer system 1100 may further include a network interface 1170 connected to the network 1180. The processor 1110 may be a central processing unit or a semiconductor device that executes processing instructions stored in the memory 1130 or storage 1160. Memory 1130 and storage 1160 may be various types of volatile or non-volatile storage media. For example, memory may include ROM 1131 or RAM 1132.

The above description is merely an illustrative explanation of the technical idea of the present embodiment, and those skilled in the art will be able to make various modifications and variations without departing from the essential characteristics of the present embodiment. Accordingly, the present embodiments are not intended to limit the technical idea of the present embodiment, but rather to explain it, and the scope of the technical idea of the present embodiment is not limited by these examples. The scope of protection of this embodiment should be interpreted in accordance with the claims below, and all technical ideas within the equivalent scope should be interpreted as being included in the scope of rights of this embodiment.

710: Terminal 711: Communication Department
712: Control unit 720: Server
721: Communication unit 722: Control unit
1100: computer system 1110: processor
1120: Bus 1130: Memory
1131: Romans 1132: Ram
1140: User interface input device
1150: User interface output device
1160: Storage 1170: Network Interface
1180: network

Claims (20)

In a method for a server to provide route information about a disaster area to a terminal capable of calculating a route,
The process of constructing disaster area resources containing unusable route information for the disaster area; and
A process of receiving travel parameters from a plurality of applications and transmitting a link to access the disaster area resources to an application that has a request to provide unusable route information for a disaster area in the travel parameters.
Including,
The process of sending the link is:
Send a link to access the same disaster area resources to applications that request provision of unusable route information for the same disaster area,
The process of configuring disaster area resources is,
Configured to include unusable path information that is expected to be unusable in the future,
The terminal provides the unusable path information to the disaster area resources so that other terminals can use it,
The process of notifying the application of updated unusable route information is,
If the expected unusable path becomes an actual unusable path, the disaster area resource transmits a notification message including the ID of the expected unusable path information,
After the terminal receives the notification message, the terminal updates its unusable path information from the disaster area resource using the ID of the expected unusable path information. delete According to clause 1,
A process of receiving a subscription request for a notification service related to the disaster area from an application; and
When the unusable path information is updated, the process of notifying the updated unusable path information to the application that received the subscription request for the notification service.
A method further comprising: delete According to clause 3,
The process of notifying the application of updated unusable route information is,
When receiving the current location from an application approaching the disaster area, the method is characterized in that notifying the application of the updated route information. According to clause 3,
When all paths in the disaster area are normalized, a process of sending a notification message notifying that all paths have been normalized to the application subscribing to the notification service.
A method further comprising: According to clause 6,
The process of sending a notification message indicating that all of the above paths have been normalized is,
The server sends the notification message and deletes resources related to the unusable road information,
The method, characterized in that the application receives a notification message indicating that all routes have been normalized and discards the unusable road information. According to clause 3,
The subscription request for the notification service includes a subscription resource created by the application setting notification conditions for the notification service. According to clause 8,
The process of receiving a subscription request for the notification service is,
A method, characterized in that the application receives a subscription request for the notification service including the subscription resource with a notification condition set to receive only updated unusable road information corresponding to the current location. According to clause 1,
If the travel parameters do not include a request to provide route information for the disaster area, transmitting the location of the disaster area related to the travel parameters to the application.
A method further comprising: A server device that provides route information about a disaster area to a terminal capable of route calculation,
a communication unit configured to communicate with a terminal; and
A control unit configured to provide traffic information about the route received from the terminal,
The control unit,
Construct disaster area resources that include unusable route information for the disaster area;
Receiving travel parameters from a plurality of applications, and transmitting a link for accessing the disaster area resources to an application that has a request to provide unusable route information for a disaster area in the travel parameters,
Send a link to access the same disaster area resources to applications that request provision of unusable route information for the same disaster area,
The disaster area resources include unusable route information that is expected to be unusable in the future,
The terminal provides the unusable path information to the disaster area resources so that other terminals can use it,
When the expected unusable path becomes an actual unusable path, the control unit transmits a notification message including the ID of the expected unusable path information from the disaster area resource,
After receiving the notification message, the terminal updates its unusable path information from the disaster area resource using the ID of the expected unusable path information. delete According to clause 11,
The control unit receives a subscription request for a notification service related to the disaster area from an application, and when the unusable path information is updated, it sends the updated unusable path information to the application that received the subscription request for the notification service. A server device characterized in that it notifies. delete According to clause 13,
The server device is characterized in that, when the control unit receives the current location from an application approaching the disaster area, it notifies the application of the updated route information. According to clause 13,
The control unit, when all paths in the disaster area are normalized, transmits a notification message notifying that all paths have been normalized to an application subscribing to the notification service. According to clause 16,
The control unit transmits the notification message and deletes resources related to the unusable road information,
The server device is characterized in that the application receives a notification message indicating that all routes have been normalized and discards the unusable road information. According to clause 13,
A server device, characterized in that the subscription request for the notification service includes a subscription resource created by the application setting notification conditions for the notification service. According to clause 18,
The control unit is a server device, characterized in that it receives a subscription request for the notification service including the subscription resource for which a notification condition is set for the application to receive only updated unusable road information corresponding to the current location. According to clause 11,
The control unit, if the travel parameter does not include a request to provide route information for the disaster area, transmits the location of the disaster area related to the travel parameter to the application.