WO2002075560A2

WO2002075560A2 - Methods for managing location based web services

Info

Publication number: WO2002075560A2
Application number: PCT/DE2001/004863
Authority: WO
Inventors: Thomas Schneider
Original assignee: Thomas Schneider
Priority date: 2000-12-20
Filing date: 2001-12-14
Publication date: 2002-09-26
Also published as: WO2002075560A3

Abstract

Up to now, location based services (LBS) in telecommunications network environments are available while only being narrowly linked to the underlying network technology or access technology. This contrasts with the supply of internet applications and the demand for LBS by clients and third parties. The novel methods, also under security & billing aspects, should cover the need of even the operators and accelerate the economical implementation of LBS for networks of the next generation. The invention relates to LBS that, by using XML protocols, permit registration on servers and logging off. These servers can be part of a public key infrastructure, whereby the management of the locations, which are specified at least geographically by degree of latitude and degree of longitude, of the availability of web services occurs as an extension of public key management methods. According to the novel methods, LBS should be able to be used by clients in transit, for example, in vehicles but also in a virtual home environment in a manner that is independent of networks, platforms and programming languages.

Description

Description:

Procedure for the management of location-dependent web services

The invention relates to methods according to the preamble of claim 1. A large number of documents are offered via Internet Protocol (IP). Search engines enable the interactive registration, finding and use of such services, both from stationary and non-stationary clients.

When using non-stationary clients, for example mobile radio devices, the focus is on the use of location-dependent services, which can also be applications and include navigation or multimedia offers. To the best of my knowledge, there are no procedures that enable location-based services to be registered, found, used and logged out at the application level.

It is known to manage location-dependent services interactively or in a batch mode in a telecommunications environment. For example, US6104931 shows a system and a method for registering "location applications" (LA) in at least one "mobile location center" (MLC), which assigns a "location application identifier number" (LAIN) to identify the LA discloses a method for describing services in a web environment. For example, Erik Christensen (Microsoft), Francisco Curbera (IBM), Greg Meredith (Microsoft) and Sanjiva Weerawarana (IBM) in "Web Services Description Language (WSDL) 1.0", http://www.uddi.org, 09/25/2000, a procedure on any. Operationally describe web services. William Nagy, Francisco Curbera and Sanjiva Weerawarana (all IBM) describe in turn in "Advertisement and Discovery of Services (ADS)", http://www.alphaworks.ibm.com, 22.09.2000, a method for the non-operational description of any web services. This method provides for the registration of web services especially for WSDL servers to be set up, by means of which web services can be found and used by any clients or servers. In addition, the result of a working group "spatial location" is the "internet engineering task Force (IETF) ", httn: //www.ietf.org, 07-2000. To identify a place by its longitude and latitude and possibly height. Finally, it is known that for the management of public keys as part of an X .509 Public Key Infrastructure (PKI) decentralized directories can be used, where public keys are the public keys of asymmetric encryption methods, as in for example the RSA method in the now free US4405829. A method is also known, as described in "XML Key Management Specification (XKMS), Draft Version 1.0", http://www.verisign.com/develoDer/xml/, November 27, 2000 by VeriSign, Microsoft and webMethods ^' for the management of public keys using said WSDL. XKMS includes "XML Key Information Service Specification (X-KISS)" and "XML Key Registration Service Specification (X-KRSS)" for the definition of secure web services that help find and Use or register and unsubscribe from web services with the aim of digital signing and encryption. This is done using open standards such as "XML-SIG" from the World Wide Web Consortium, http://www.w3c.org. and said IETF worked, the declared goal of XKMS is the compatibility with, for example, said PKI, the free expandability and the creation of a non-proprietary solution for using PKI also on mobile devices. The object of this invention is now to create methods for the management of location-dependent web services according to the preamble of claim 1.

This object is achieved by the features specified in the characterizing part of the patent claims.

This creates a method in extension of said X-KRSS, which allows the registration and deregistration of location-dependent web services, and a method in extension of said X-KISS, which enables the location and use of location-dependent web services. Like said XKMS, these methods are designed with the property of being able to use standardized security methods, even on mobile devices. The function of a billing procedure is thereby also fulfilled.

Further refinements of the invention can be found in the following description and the subclaims. Embodiments of the invention are shown below in the accompanying drawings and are explained in more detail below.

1 shows: Registration of a web service

Fig. 2: Unsubscribing from a web service Fig. 3: Finding a web service

Please refer to "Appendix C Immediate Binding" of said XKMS 1.0 when it comes to expressing X-KISS or X-KRSS messages without reference to the SOAP protocol or an equivalent. This optional embodiment is considered to be completely equivalent to XKMS and thus considered to this invention.

The following sources are listed here for definitions:

D. Box, D. Ehnebuske, G. Kakivaya, A. Layman, N. Mendelsohn, H. Frystyk Nielsen. S. Thatte, D. Winer, "Simple Object Access Protocol (SOAP) 1.1", W3C Note, May 8, 2000, http: // www. 3.org/TR/SOA P D. Eastlake, JR, D. Solo, Bartel, M., Boyer, J., Fox, B., E. Simon, "XML Signature

Syntax and Processing "[XML-SIG], W3C, http://www.w3.org/TR/xmldsig-core/ HS Thompson, D. Beech, M. Maloney, N. Mendelsohn," XML Schema Part 1: Structures ", W3C Working Draft, 09/22/2000, http://www.w3.org/TR/xmlschema-l/ PV Biron, A.Malhotra, "XML Schema Part 2: Datatypes", W3C Working Draft, 09/22/2000, http://www.w3.org/TR/xmlschema-2/

In the following definitions, URIs and other elements, highlighted in bold, are given by way of example or - if irrelevant here - are indicated with "...".

Preliminary following XML schema is listed here by way of example for the definition of location data it ^'extends the XML-SIG, which is expandable, and a specific XKMS- Definition: <sc ema targetNa espace = '' http: /Λv-vvw.VW-trustcerιter.conι/xmI/schema/XKMS.sdl/LocatioπInfo.xsd "xmlns =""http: // w. w3.org 1999 / XMLSchema"><import namespace— 'http://www.w3.Org/2000/09/xmldsig# "schemaLocation =''http: //www.w3.org/TR 2000 / CR-xmldsig-core-20001031 / xrπldsig- core-schema.xsd "/><element name =" Location ">

According to X-KRSS, the administrator 1 of the server 2 shown in FIG. 1 who wants to offer a web service sends a request 3 to the server 4 for registration, here the WSDL parameters:

<? xml version = "1.0"?> <soap: Envelope xmlns: soap = "http://schemas.xmlsoap.org/soap/envelope/" xmlns'.soapenc = "http: // schemas. xmlsoap.org/ soap / encoding / "xmlns: xsi =" http: // www. w3.org/1999/XMLSchema-instance "xmlns: xsd =" http: // www. w3.org/1999/XMLSchema "xmlns: ds =" http://www.w3.org/2000/09/xmldsig# "> <soap: Body>

<AssertionStatus> Valid </ AssertionStatus>

<KeyrD> http: // w v .ServiceCenter.com / ebServicel.sdl </KeyDD> <ds: KeyInfo> <Location> <Latitude> 52.533 </Latitude>

<ds: RSAKeyValue> <ds: modulus> ... </ ds: modulus>

<ds: Exponent> ... </ ds: Exponent> </ ds: RSAKeyValue> </ ds: KeyValue>. <ds: KeyName> WebServiceName </ ds: KeyName> <ds: KevInfo>

</Template> <Authentication>

</ ProofOfPossession>

<Authentication> ■ ^■

<string> KeyName <string> <string> KeyValue </string>

<string RetrievalMethod </ strϊng></Respond></Register></ soap: Body></ soap: Envelope> The following applies here: WebServicel.sdl is the WSDL-compliant file on server 2, which currently describes the web service currently offered there, PASS is a passphrase chosen by administrator 1 in accordance with XML-SIG. The digital signature is used to identify the web service; latitude and longitude are examples of elements of the signature in Berlin.

The location data, here latitude and longitude, are assumed to be known to the administrator 1 and identify the location for which the web service is to be offered and which does not have to be identical to the location in which the server is located.

Response 5 is listed here: •

<? xml version = "1.0"?> <soap: Envelope xmlns: soap = "http://schemas.xmlsoap.org/soap/envelope/" xmlns: soapenc = "http.7 / schemas.xmlsoap.org / soap / encoding "xmlns: xsi =" http://www.w3.org/1999/XMLSchema-instance "xmlns: xsd =" http://www.w3.org/1999/XMLSchema "xmlns: ds =" http: //www.w3.org/2000/09/xmldsig # ">

<soap: Body><RegisterResult xπύns = "http://www.VW-trustcenter.org/xml/schema/XKMS.sdl/lΛcationInfo.xsd ^, '><Result> Success </Result><Answer soapenc: arrayType = "KeyBinding [l]">

<AssertionStatus> Valid </ AssertionStatus>

<KeyID> http://www.ServiceCenter.com/WebServicel.sdl </ KeyE)> <ds: KeyInfo> <Location>

<ds: modulus> ... <ds: modulus><ds:exponent> ... </ ds: exponent></ ds: RSAKeyValue></ ds: KeyValue> _! <ds: KeyName> http://www.ServiceCenter.com/WebServicel .sdl WebServicelName </ ds: KeyName>

<ds: KeyInfo> <ValidityInterval>

</KeyBinding> </Answer> <Private /> '</RegisterResult> </ soap: Body>. '

</ Soap: Envelope>

In the example, this response is identical to response 10 in FIG. 2, provided server 9 has successfully logged off.

The administrator 6 of the server 7 shown in FIG. 2, who wants to unsubscribe from a web service, sends a request 8 to the server 9 according to X-KRSS, the WSDL parameters differ from request 3 only in one line: <AssertionStatus> Invalid <AssertionStatus> 3 shows schematically the request 11 from a client 12, triggered by a human 13, to a server 14 according to X-KISS. People are looking for one or more web services suitable for a specific location, here in Berlin as an example. The location data is assumed to be known to humans 13, provided that the location data can be implemented, for example, as follows: Client 12 is equipped with a GPS unit which determines its current location via satellite location. Another possibility from any number is the use of a further web service analogous to FIG. 3, the chent 12 being a mobile radio device and digitally identifying itself as in request 11 and its current location in a response from the server of its mobile radio network operator for subsequent transmission in Request 11 gets notified. As a form of one-way communication, WSDL also allows a client to be notified by a server; the client therefore does not need to send out permanent requests, but it is sufficient to use subscribe and publish to automate the process of requesting web services. At this point, reference is made to the explanations on WSDL and future extensions of XKMS. The request parameters can for example look like this:

<? xml version = "1.0"?>

<soap: Envelope xmlns: soap = "http://schemas.xmlsoap.org soap / envelope /" xmlns: soapenc = "http://schemas.xmlsoap.org soap / encoding /" xmlns: xsi = "http: / / www.w3.org/1999/XMLSchema-instance "xmlns: xsd =" http://www.w3.org 1999 / XMLSchema "xmlns: ds =" http://www.w3.org 2000/09 / xιnldsig # "> <soap: Body>

<i.ocate xιnlns = ^M http://www.VW-trastcenter.com/xml/schema/XKMS.sdl LocationInfo.xsd ''><query><ds:KeyInfo><Location>

</ ds: KeyInfo> </query>

<Respond> KeyName </Respond> <Respond> KeyValue </Respond> </Locate>

</ soap: Body> </ soap: Envelope>

It is assumed here that the response in the KeyName also contains the KeylD; the so-called policy of the server 4 and 14, as can be seen in response 5, was set up accordingly.

The parameters of Response 15 are listed here as an example: <? Xml version = "1.0"?>

<soap: Envelope mlns: soap = "http ^ / schemas.xmlsoap.org / soap / envelope" xmlns: soapenc = "http://schemas.xmlsoap.org/soap/encoding" xmlns: xsi = "http: // www.w3.org 1999 / XMLSchema-instance "xmlns: xsd =" http://www.w3.org/1999/XMLSchema "xmlns: ds =" http://www.w3.org/2000/09/xmldsig # "><soap:Body><LocateResult xmlns =" http://www.VW-trustcenter.org/xml/schema/XKMS.sdl/LocationInfo.xsd "><Result> Success </Result> <Answer><ds:KeyInfo>

<ds: KeyValuexds: RSAKeyValue> <ds: Modulus> ... </ ds: Modulusxds: Exponent> ... </ ds: Exponent>

</ ds: RSAKeyValue> </ ds: KeyValue>

<ds: KeyName> http://www.ServiceCenter.com/WebServicel.sdl WebServicelName </ ds: KeyName> <ds: Key o> <ds: KeyInfo>

<Ds: KeyValuexds: RSAKeyValue>

<ds: Modulus> ... </ ds: Modulusxds: Exponent> ... </ ds: Exponent> </ ds: RSAKeyValue>

</ ds: KeyValue> N <ds: KeyName> http: /www.ServiceCenter.com/WebService2.sdl WebService2Name <ds: KeyName> </ ds: Keylnfo> </Answer> </LocateResult> </ soap: Body> </ soap: Envelope>

Two keylnfos are listed in the exemplary response 15; For each key information, the client 12 hereby receives a key name, which contains a URL. In this example, this means that for the location specified in <Location> in the request 11 at the time this request arrives at the server 14, two - not yet logged off and from Web services valid for security are registered. The selection from the web services can be made automatically by the client 12 or by the person 13; one criterion here can be, for example, a further value of the KeyName; a price for using the web service may be set forth therein. The subsequent one

Evaluation of the WSDL-compliant file stored under the URI, i.e. the use of the web service is standard and can be refined, for example, using the ADS method described at the beginning.

Claims

Patent claims

1. Method for managing location-dependent web services, whereby - web services are self-contained, modular documents or software-

are applications that can be described, registered, logged out and found and used over a network in general, over the web in particular,

Places depending on which web services are available are geographically specified by their latitude and longitude, characterized in that a) the operational availability of the web services on a server (2) for a client or server (12) thanks to a descriptive file is specified on the server (2) in a uniform format, b) this file can be accessed on the server (2) via at least one Internet standard such as HTTP, c) the file can also be evaluated from mobile clients (12), d) the web service is called up after the file has been evaluated, e) only open, expandable and free standards of the XML family are available

Description of the web services are used and thus independence from platforms, operating systems, programming languages and telecommunications infrastructures is given, f) location-dependent lists of servers (2) are kept available on a server (4), g) only servers (2) access its web services at any time Server (4) can log off.

2. Method according to 1, characterized in that the management of the data describing the locations is carried out as an extension of Public

Key management process takes place, whereby h) the distribution or registration of the public key or keys of the server (2) takes place together with the location data on a server (4), i) at the same time location data and public key for server (2 ) are stored when logging in to a web service and, if necessary, deleted when logging out of a web service, j) mobile clients (12) can use asymmetric encryption and digital signing to identify and subsequently bill for web services used.

3. Method according to 1 or 2, characterized in that

In addition to latitude and longitude, locations are defined by other attributes such as height, radius around the point determined by longitude and latitude at which they should be usable.

. Method according to 1, 2 or 3, characterized in that the location data of a mobile client (12) via a web service, registered on a server

(4), can be queried by any clients or servers, if necessary via digital identification.

5. Procedure for the management of location-dependent web services, whereby - web services are self-contained, modular documents or software-

Applications that describe, register, log out and can be found and used over a network in general, over the web in particular, - locations depending on which web services are available, geographically through their latitude and longitude, optionally through other attributes like height,

Radius around the point determined by longitude and latitude at which they should be usable are specified, characterized in that k) a server (4) is part of a public key infrastructure (PKI),

1) this server (4) has at least one Internet standard such as

HTTP is available as a transport protocol, m) a client or server (12) can be authenticated and authorized by server (4) using a request/response protocol via this transport protocol to use a web service of a server (2), n) as part of this Request / response protocol information relating to a location, depending on which at least one web service of the server (2) can be used, can be exchanged, o) this request / response protocol is described in an open, expandable markup language, for example XML.

6. Computer program that can be loaded into a computer so that the computer programmed in this way is able or suitable to carry out a method according to one of claims 1 to 6 as a client or server.

7. The method according to one of claims 1 to 6, characterized in that the current location of the client or server (12) is known to it, for example thanks to a GPS receiver connected to it.