EP2415240B1 - Adressierungsschema - Google Patents

Adressierungsschema Download PDF

Info

Publication number
EP2415240B1
EP2415240B1 EP10726152.1A EP10726152A EP2415240B1 EP 2415240 B1 EP2415240 B1 EP 2415240B1 EP 10726152 A EP10726152 A EP 10726152A EP 2415240 B1 EP2415240 B1 EP 2415240B1
Authority
EP
European Patent Office
Prior art keywords
web
address
service
private
service providing
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
EP10726152.1A
Other languages
English (en)
French (fr)
Other versions
EP2415240A1 (de
Inventor
Francis James Scahill
Richard Joseph Evenden
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
British Telecommunications PLC
Original Assignee
British Telecommunications PLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by British Telecommunications PLC filed Critical British Telecommunications PLC
Publication of EP2415240A1 publication Critical patent/EP2415240A1/de
Application granted granted Critical
Publication of EP2415240B1 publication Critical patent/EP2415240B1/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/50Address allocation
    • H04L61/5076Update or notification mechanisms, e.g. DynDNS
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/45Network directories; Name-to-address mapping
    • H04L61/4505Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
    • H04L61/4511Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/45Network directories; Name-to-address mapping
    • H04L61/4557Directories for hybrid networks, e.g. including telephone numbers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00Indexing scheme associated with group H04L61/00
    • H04L2101/60Types of network addresses
    • H04L2101/618Details of network addresses
    • H04L2101/65Telephone numbers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/09Mapping addresses
    • H04L61/25Mapping addresses of the same type
    • H04L61/2503Translation of Internet protocol [IP] addresses
    • H04L61/2514Translation of Internet protocol [IP] addresses between local and global IP addresses

Definitions

  • the present invention relates to an addressing scheme for accessing application servers in a communications network and to related aspects.
  • a scheme for addressing the host server of a third party web service running on a mobile communications device from a web browser application In particular, but not exclusively, the addressing scheme enables mobile devices located within private address domain(s) to be contacted by other devices on the same LAN segment.
  • the addressing scheme seeks to enable mobile web-service providing devices located within private address domains to be contacted by other devices located on the same LAN segment regardless of whether or not the two devices are located in the same private IP address domain, providing a working network path can be identified directly or indirectly between the two devices.
  • a device-label such as a telephone number which is associable with an addressed device
  • the server is able to resolve the device-label to a private address via which the addressing device can contacted.
  • the private address is utilised by the web-browser application to seamlessly and transparently obtain a requested web-service from the addressed device using any suitable communications channel, e.g. WiFI, Bluetooth, etc, that provides a working path between the two devices.
  • LAN segment refers here to an area within which a device can use an Address Resolution Protocol request to look up and resolve the local address of other device (regardless of whether or not both devices are located in the same private address domain or in different private address domains).
  • Network address translation (NAT) devices are known to enable reuse of the Internet Protocol (IP) address space by separating private IP address domains from public IP address domains.
  • IP Internet Protocol
  • NAT techniques establish and maintain Transmission Control Protocol/Internet Protocol (TCP/IP) network and/or User Datagram Protocol (UDP) connections traversing NAT gateways.
  • TCP/IP Transmission Control Protocol/Internet Protocol
  • UDP User Datagram Protocol
  • NAT techniques are used for client-to-client networking applications such as Voice-over-IP (“VoIP”) and peer-to-peer applications (for example, file-sharing).
  • VoIP Voice-over-IP
  • peer-to-peer applications for example, file-sharing.
  • NAT enables private IP addresses to be used on home and corporate networks (internal networks) behind routers which present a single public IP address to the public Internet.
  • a networked device located in the private IP address domain behind the NAT gateway/router communicates with a device in the public network, the NAT device changes the source address of any outgoing requests the network device generates to the NAT device's own address.
  • the number of devices participating as servers whose IP addresses are allocated in the private domain behind a NAT device is increasing.
  • the use of applications such as peer-to-peer file sharing (for example, BitTorrentTM or GnutellaTM), interactive applications such as video conferencing, VoIP (for example, Session Initiation Protocol or SIP), as well as electronic gaming is also increasing.
  • the NAT technique works well for devices which function as clients and initiate communications, as the outgoing request enables replies received by the NAT device to be forwarded back to the originating device using an appropriate method, the NAT device has no automatic method for determining from an incoming communication seeking to initiate contact with a server which device located in the private address domain is actually providing that server functionality.
  • Service integration is conventionally implemented either by integrating the third party service in the origin server, or in the web browser itself.
  • the third-party service is integrated from the origin server, a variety of network protocols are available for use to support the service integration, for example, the SOAPTM based WebServices protocol.
  • service integration take places in the web browser, background mechanisms which rely on dynamic ⁇ script> tag loading can be used, for example, an eXtensible MarkUp Language HyperTextTransferProtocol request (XMLHTTPRequest) or a JavaScript Object Notation (JSON) based interface.
  • XMLHTTPRequest eXtensible MarkUp Language HyperTextTransferProtocol request
  • JSON JavaScript Object Notation
  • Known service integration schemes require the address of the hosting web server to be known in advance by the web application author and hard coded into the web content.
  • a webbrowser application running a device runs a web application with the third party content address hardcoded in a particular HyperText Markup Language (HTML) page, providing the browser security policy has been configured to authorise the web application to request content from the address of the third-party content, the requested third party web service accessed via that address will be integrated into the HTML page running in the web browser application on device.
  • HTML HyperText Markup Language
  • Local networked appliances within the home are becoming more prevalent and such appliances are now capable of providing web based interfaces to allow the user to manually configure and control the appliance remotely.
  • the local area network (LAN) device addresses for such domestic appliances are typically allocated dynamically according to the Dynamic Host Configuration Protocol (DHCP) configuration of the LAN router.
  • DHCP Dynamic Host Configuration Protocol
  • a LAN device is a mobile device and only intermittently connected to a LAN, its IP address will not be static and can change on a frequent basis.
  • UpnP Universal Plug And Play
  • BonjourTM etc which use multicast broadcast packets to announce the availability, address of particular devices as well as the type of services these devices offer.
  • These protocols provide address discovery to allow client applications on a LAN to discover the address and name of a dynamically available device in order to connect to it.
  • the URL of the web services provided by the device is included in the service announcements. These URLs can be displayed by the UPnP aware clients and can be passed to a web browser application as the initial address to fetch the HTML content from.
  • Web browser applications such as Internet ExplorerTM and FireFoxTM use the hierarchical Domain Name System (DNS) address lookup scheme to resolve the domain name of a hosted web service to the actual Internet Protocol (IP) address and port to connect to of the server which is hosting the web service.
  • DNS Domain Name System
  • IP Internet Protocol
  • Internet Explorer makes a DNS lookup query for Type A records (hostname) addresses. These requests are first resolved in the DNS cache of the host machine, before being passed to the local DNS server for the LAN (typically hosted in the router) before being referred by the router to the parent DNS server if unresolved. If the hostname is not defined in the DNS cache or local DNS server then the web service will be unreachable.
  • a user may not be able to identify the host name or UPnP name of the device hosting the desired third-party service.
  • a default address for a third-party service may have no association with a device which is apparent to a user.
  • the name may bear no relation to a user's concept of a device name and may also assume that the user has actually configured a unique name for the device and not relied on some default naming convention adopted by the device manufacturer.
  • the LAN device hosting the third-party service is a telephone-type device, as the unique device ID is the phone number associated with the phone device, which a user may be aware of and if not, can usually determine.
  • a web content author can realistically develop a web application which includes a prompt for a user to enter a phone number for a device which is to provide a required third-party web service in order to integrate that web service at the runtime of the web application, providing the phone number entered by the user is capable of being converted into a IP address on the local LAN of the device which is hosting the third-party web-service.
  • DNS-SD The DNS service discovery (DNS-SD - see, for example, http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt for more details), provides a mechanism to find services on a local LAN using DNS.
  • This system uses service (SRV) type records (see Request For Comment (RFC) 2782 available from the Internet Engineering Task Force (IETF) standards body for more information about locating services using DNS and SRV records) in the local DNS database to provide a service to IP address and port lookup mechanism.
  • RRC Request For Comment
  • an application incorporating a third party web-service In order to use DNS-SD, an application incorporating a third party web-service must be aware that the address it has obtained for the third party server hosting that third party web-service is not correct in order to trigger a request to perform a SRV lookup.
  • web browser applications are conventionally configured to automatically assume when accessing a web-service that a given web-service address host name is the correct for that web-service, the application will automatically use the given hostname to perform a lookup on the hostname field in the DNS database, regardless of whether that hostname is accessible or not or whether it is the correct hostname or not for the requested service.
  • existing web browsers do not trigger the DNS-SD SRV lookup procedure.
  • RFC3761 describes a standard mechanism for converting a telephone number into a domain name. Essentially the number is reversed, the digits separated by ".” and postfixed with the .e164.arpa domain. This RFC ensures that unique phone numbers can be converted to unique domain names but then relies on standard DNS to resolve the *.e164.arpa domain to an IP address.
  • Dynamic DNS provides a mechanism for devices to dynamically update the IP address to domain name mapping via a internet resident server. This server ensures that only authorised clients are allowed to change the IP address for a domain.
  • DDNS is typically used for supporting remote access to home networks where the public IP address of the home router is dynamically allocated by the ISP.
  • the DDNS client is responsible for automatically detecting the IP address change and update the DDNS server.
  • the new IP address must then propagate across the internet to other domain name servers in the internet and as such only becomes reliably available after a period of time has passed.
  • the amount of time varies as it depends on the rate at which DNS updates are disseminated across the domain name servers in the internet.
  • TTL TimeToLive
  • DDNS services also allow client to register private IP addresses, however such private IP addresses are only valid if the device requesting the lookup and the server are on the same LAN segment.
  • United States Patent Application US20070214209 describes a DDNS style service in which an addressing database holds additional information relating to a device address. However, US20070214209 does not consider the criteria for providing an IP address for a device located on the same LAN segment as the address querying device. US 20070214209 considers the geographical proximity between the querying device and the device whose address is being queried, however, geographical proximity between two devices does not imply they are on the same LAN segment. For example, two devices may be connected on a 3G wireless communications network and be physically adjacent to each other in the same location despite one device not being connected to a LAN which the other device is connected to.
  • WiFi hotspot routers will enforce wireless client separation by not indicating a route can be established between two devices so that even where two devices are on the same WLAN their presence is not automatically indicated to each other.
  • EP1724976 describes an address resolution device providing seamless communications without being conscious of which address should be used for the communications when an opponent party is assigned both an external address and an internal address, and dynamically accommodates against changes in connection status.
  • a gate keeper has an address table with which global addresses, private addresses and grouping IDs can be registered. During address registration, the gate keeper registers the address of a communication packet into the global addresses, the address assigned to the terminal into the private addresses, and if available, a grouping ID into the grouping IDs. During address notification, the gate keeper consults the address table to notify the caller terminal of the callee terminal private addresses when the callee terminal and the caller terminal have the same grouping ID or when they have the same global address. Otherwise, the gate keeper notifies the caller terminal of the callee terminal global address.
  • an embodiment of the present invention provides a system according to claim 1.
  • an embodiment of the present invention provides a method as set out in claim 6.
  • an embodiment of the present invention provides an addressing server as set out in claim 9.
  • the aspects and embodiments of the invention require a user to know the telephone number of the device they want to connect to in order to access a web-service which requires the participation of that device.
  • the user is not required to provide any additional information such as the UPnP name and/or the DHCP name of the other participating device.
  • the aspects and embodiments of the invention enable a user to be capable of connecting a device they are operating to any device on the same LAN segment as the user's device for which the phone number is known to the user. This advantageously removes the need to know the UPnP device name or hostname of a phone device which a user does not necessarily own.
  • the aspects and embodiments of the invention do not require device addresses for third party services to be hard-coded into applications as the user can be prompted for the telephone number of the relevant host device for that third party service which are resolved to an appropriate IP address. It is also possible for phone numbers to be stored in appropriate database structures on the content server.
  • AJAX Asynchronous JavaScript and XML
  • address resolution does not require any browser specific code such as, for example, Browser Helper Objects (BHOs), plugins, or ActiveX components, in order for the web content to be able to connect to the LAN device.
  • BHOs Browser Helper Objects
  • ActiveX components ActiveX components
  • the aspects and embodiments of the invention seek to provide a way to guarantee that an IP address for a third party web service is valid which enables a device to determine if another device's private IP address is on the same LAN segment.
  • One embodiment of the invention provides simultaneous support for multiple private networking connections.
  • the embodiments of the invention thus seek to mitigate and/or obviate one or more limitations imposed by DDNS.
  • traditional DNS updates take an unpredictable time to disseminate across communications networks to DNS servers and local machine caches. For IP addresses that are updated more frequently than 1 hour then the probability that a DNS update will return an out-of-date error is high. When the device is a mobile device then there is a high probability of in particular the private IP address changing frequently.
  • An addressing scheme enables a wired and/or wireless communications-enabled device to utilise a plurality of connections, for example, to utilise both LAN and WAN connections, to update its address on an address database.
  • a web application which is seeking to obtain content from the wireless communications device queries the authoritative name server on a sufficiently frequent basis, the IP address which will be retrieved from the database in response to such queries should be the correct address.
  • Embodiments of the invention also seeks to address another limitation of the DDNS standard technology in that conventionally if the public IP address of a wireless communications enabled mobile device is exposed for use by geo-location servers in order to determine the location of the mobile phone this may expose information (for example, location information) which the user of the mobile device may wish to remain secret. As the public IP address information is needed to ensure that the mobile is on the same LAN segment as the fixed device, this may be undesirable. To address this, a web server according to an embodiment of the invention enables a private IP address to be exposed whilst the public IP address remains hidden.
  • DDNS DDNS
  • Another limitation of the DDNS standard occurs when a fixed device is connecting to another LAN device using a private IP address as there is a high probability that the private IP address may have been reassigned. In this situation, an out-of-date DNS response would resolve to another valid device on the LAN but not the original intended device for connection to.
  • Embodiments of the invention also seek to obviate and/or mitigate problems associated with using a DDNS update to the local LAN DNS gateway.
  • the DNS gateway retains a record of the presence of the telephone number of the mobile communications device, other devices on the same LAN would be able to discover the telephone numbers and additional information, such as a device identifier, for one or more other devices also connected on the same LAN segment.
  • Embodiments of the invention also seek to obviate and/or mitigate one or more problems which arise when a plurality of devices share a router but are still not able to contact each other, for example, when a wireless client separation regime is operating and/or if multiple layers of NAT must be traversed, by ensuring that the private IP address associated with the telephone number of a device on a private network is only provided to other devices that the device has determined are on that private network.
  • Some embodiments of the invention do not require additional software to be implemented in any fixed device or LAN router and some embodiments are usable with any Javascript enabled web browser on any operating system without modification or the need for any browser specific code.
  • FIG. 1 shows schematically a mobile communications device shown as addressing device #1 which is intermittently connected to a LAN L1.
  • LAN L1 forms part of the access network in a communications system 10 which also comprises an internet 12 and a dynamic addressing server (DAS) 22.
  • DAS 22 is an internet resident server which stores the real-time private IP address of all devices which are intermittently connected to LAN L1.
  • DAS 22 provides a dynamic DNS-like host-name to address look-up mechanism to allow web-based content running in a browser application to be able to securely and reliably determine the IP address of a mobile server device, such as a mobile phone, which is running on the same LAN segment, merely by providing an appropriate device-label (such as a hostname), for example, for a mobile device, the device-label may consists of a mobile phone number.
  • a mobile server device such as a mobile phone
  • the device-label may consists of a mobile phone number.
  • addressing device is also used herein equivalently to a “service addressing device ", a “web-service requesting device” or “service requesting device” and the term “addressed device” is used synonymously with the term “server”, “service-providing device”, a “service offering device” etc.
  • the term device refers to any communications-enabled device, for example, a client terminal capable of attaching to a LAN segment, including mobile devices etc., for example, a mobile telecommunications device, household appliance, television signal receiver-type device, electronic games console, etc., etc.
  • addressing server is also be used herein to refer to DAS 22, as may the terms “domain addressing server”, “dynamic domain addressing server” and “dynamic addressing server”.
  • LAN segment as used herein to an area within which a device can use an Address Resolution Protocol request to look up and resolve the local address of other device (regardless of whether or not both devices are located in the same private address domain or in different private address domains).
  • the two devices therefore be attached to a local area network segment bounded by one-hop routers.
  • LAN segment L1 which may comprise one or more wired and/or wireless LANs). However, the devices may be only intermittently connected to the same LAN segment.
  • device #1 has the private IP address 192.168.0.22, and device #2 18 and device #3 20 have the respective private IP addresses 192.168.0.20 and 192.168.0.21.
  • device #2 has a wireless connection, e.g. a Wi-Fi connection, to the public internet 12.
  • device # 2 comprise a personal computer which is disconnected from LAN L1 when it is switched off or otherwise disconnected and device #3 20 comprises another type of intermittently available device such as a set-top box for example.
  • devices 16, 18, 20 can each comprise any device capable for forming an appropriate communications link to LAN L1, and may be referred to herein by the term “terminal”, “device” and “server” as appropriate.
  • a device capable of being connected to a communications network using a wired and/or wireless connection for example, by using a permanent connection (for example an Asymmetric Digital Subscriber Line (ADSL) - type connection known as a broadband connection) or via a dial-up communications connection and/or WiFi.
  • ADSL Asymmetric Digital Subscriber Line
  • examples of possible devices device16, 18, 20 include any suitably communications-enabled domestic appliances, set-top television boxes, games console, computers (both desk and laptop) which are identifiable via a telephone number as well as telephone-type devices such as mobile telephones etc.
  • router 14 supports the connection of devices to local area network (LAN), and provides an access point to the DAS 22 for the devices 16, 18, 20 connected to the LAN.
  • Router 14 thus acts as a boundary device for the LAN segment L1 by separating the public and private IP address domains.
  • Router 14 is shown with an exemplary address 192.168.0.1 in the private domain and 193.113.x.y in the public domain.
  • client terminals #1 and #2 are capable of running web-browser applications.
  • Such web-browser applications are capable of generating address queries to locate the IP address of a remote host to receive data from that host, for example, data which the host provides as a web-service or data which comprises content required by the respective web-browser application.
  • An address query generated by a web-browser running on a device (16, 18) connected to LAN L1 is forwarded to the DAS 22 via the router 14 over internet 12.
  • the response from the DAS 22 provides an private IP address which enables the web-browser applications running on the respective device16,18 to communicate with the device 20 providing the requested web-service if this device 20 is connected at that point to the same LAN segment as the service-requesting device16,18.
  • router 14 comprises a wireless communications network protocol router, for example a WiFi enabled router and at least one of devices 16, 18, 20 comprises a wireless communications-enabled device.
  • the addressing device 16 shown in Figure 1 is connected to a local area network (LAN) segment L1 via the wireless router 14 and runs a web-browser which at some point needs to query and retrieve a private IP address for another, addressed, communications-enabled service providing device device20 which is also connected to the same LAN segment L1.
  • LAN local area network
  • an addressing system comprising DAS 22 and two associated data stores 24, 26 providing registry services enable a web-service requesting device 18 connected to LAN L1 to locate an addressable IP address for a web-service offering device 20 (functioning here as a service providing device).
  • Data store 24 stores the presence information of all devices connected to LAN L1. Each time a device 16,18,20 connects to LAN L1 it notifies DAS of the private IP address used to address its interface to LAN L1, and the DAS updates data store 24.
  • Data store 26 stores device signature information which associates the private IP address for a particular device present on the LAN (i.e. whose signature is stored in data store 24) with a cookie associated with a particular web-service. In this way, a web-service requesting device is able to locate the current and correct private IP address for a particular interface on a web-service offering device 20.
  • DAS 22 enables a dynamic domain name server (DDNS)-like hostname address for the service providing device 20 to be retrieved from the presence address database DB1 24.
  • the DDNS-like hostname address is provided in response to the service requesting device 16,18 generating an address query which identifies the service providing device 20 device using a device-label, for example, a device hostname or telephone number, or any, even a personalised, device name which has been registered at the DAS as one which is to resolve to a particular device so that it is capable of functioning as a address identifier to perform an IP address look-up operation for the device with which the label is associated. For example, by using an identifier for the service providing device which conforms with the telephone numbering system E.164.
  • DAS 22 enables a web-browser application running on the addressing client terminal 16 to determine the current local private IP address for the addressed client terminal 20. This enables a web-browser application running on client terminal 16 to retrieve content and/or access a requested web-service from the addressed client terminal 20 which is only intermittently connected to LAN L1 in a more reliable way as the returned address will be more likely to be up to date and accurate for the addressed client terminal 20.
  • a telephone number mapping scheme such as the E.164 NUmber Mapping (ENUM) scheme which to map a telephone number to a static internet address using a domain name server
  • ENUM E.164 NUmber Mapping
  • the address database DB#1 24 comprises a plurality of data records, each record having a data structure which enables a look-up operation or other data retrieval operation to be performed using a telephone number field.
  • addressing device 16 generates queries for the IP address of the service-offering terminal 20 which identifies terminal 20 only by its telephone number.
  • DAS 22 receives the address query it processes it to extract the telephone number and performs a look-up (or equivalent data retrieval) operation based on the telephone number as a searchable index element in data store 24.
  • a data structure is located in data store 24 which associates an IP address with the telephone number of the query, the IP address is returned to DAS 22 which then forwards the IP address back to the address-requesting device 16.
  • the addressed device 20 is identifiable either by means of a fixed PSTN type telephone number or it may, alternatively, be identifiable by another mobile telephone number in a preferred embodiment. In either case, as the addressed device 20 is only intermittently connected to the LAN L1 its private IP address is not consistent as the addressed device 20 is capable of being assigned a different private IP address each time it connects to the LAN L1.
  • DAS 22 stores the real-time private IP address allocated to a mobile phone device 20 connected to LAN L1. This private IP address information is updated by a DAS 22 client application running on the device 20 whenever it connects or disconnects from a network. Other web-enabled applications running on other devices such as PCs or other internet communications-enabled devices connected to LAN L1 query the DAS 22 by supplying the mobile phone number for the device 20. The DAS 22 is able to retrieve the current private IP address of the addressed device 20 only if both the requesting device 16 and the addressed device 20 are connected to the same LAN segment and if there is a working network path between the requesting device 16 and the addressed device 20 which may be provided by a different communications protocol from the communications protocol of LAN L1. If there is no working network path which exists between the two terminals, no IP address will be returned to the requesting device.
  • an address requesting device 16 is only provided with the IP address of another device 20 if a working network path exists between the two terminals by verifying that the addressed device 20 and the requesting device 16 are actually on the same LAN segment and that there is a working route between the two terminals which utilises the same LAN prior to responding to the addressing query.
  • Table 1 An exemplary device presence data structure stored in data store 24, for example, a record stored in a database DB1, is shown in Table 1 below: Table 1: Exemplary data record for database DB1.
  • Device ID Active Networks Observed LAN Signature 077771234567 Addr:192.168.0.1
  • Dev1 ⁇ Type:Wifi UPNP: ⁇ udn>
  • SSID Home NBNS: ⁇ computername>
  • Device 3 Addr: 169.254.2.1
  • Dev2 Type: USB UPNP: ⁇ udn> ⁇
  • a presence data structure for storage in data store 24 comprises three main elements shown in columns in table 1 :
  • the first sub-field for LAN presence shows the various named presences of the addressed device on the WiFi network connection, shown for example in Table 1 as Dev1 ⁇ UPNP: ⁇ udn>, NBNS: ⁇ computername>, MAC: ⁇ macaddress> ⁇ .
  • Dev1 is a token device identifier for the address requesting device which is followed by the various named presences of the address requesting device on the LAN.
  • the device 16 presences on the WiFi connection are collectively listed in the data record subfield for "Dev1”.
  • Dev1 has a UPNP presence on the LAN using the address value ⁇ udn> observed by the addressed (service providing) device.
  • Dev1 also has a NetBIOS Naming Service (NBNS) presence on the LAN using the address value ⁇ computernam>.
  • NBNS NetBIOS Naming Service
  • These LAN signatures relate to the addressing (service requesting) devices and are not the signature of the addressed (i.e., the service providing) device 20.
  • Device Dev1, Dev3 and device 3 are all other devices on the LAN which have been observed by the addressed device 20.
  • the signatures accordingly are not the signatures of device 20 rather they include the signatures of the service requesting devices 16 and 18.
  • the NBNS is a central repository which records all name registrations for a device which is well known in the art.
  • NBNS NetBIOS Naming Service
  • Dev1 also has an addressable Media Access Control address ⁇ macaddress>.
  • DAS 22 is configured to maintain and perform data lookup and retrieval operations on presence data store 24 and will store. in data store 24 information when the addressing device 16 reports its presence to DAS 22 to indicate it has received packets from two other devices, indicated in Table 1 for example, as Dev1 which refers to the other device 18 and Dev2 which refers to the other device 20. Device #2 will have a similar data structure recording its presence on the LAN L1.
  • data store 24 records for each device whose presence has been observed by device 20 on LAN L1 to DAS 22 a look-up device identifier value (a telephone number), an address for the addressed device on each network the addressed device is actively connected to, and a name/address which signifies the presence of the device on the part of the LAN that can be observed by the addressing device 16.
  • a data record in presence data store 24 comprises, for example: a mobile phone number which identifies a device to be addresses; a set of one or more private IP addresses on which the device with that mobile telephone number can be contacted; and the corresponding observed device signature values derived from the actual broadcast IP traffic observed on each private network interface corresponding to one of the set of one or more private IP addresses.
  • the presence data store 24 is updated by DAS 22 each time a dynamic addressing client (DAC) 20 connects to a new network.
  • Data store 24 may also be updated if the DAC 20 detects a broadcast packet indicating a device has been removed, for example, if DAC 20 determines a Universal plug aNd Play (UpnP) Bye message or a broadcast packet from the device 16 has not been seen within a particular period of time, for example, if a UpnP notify or NetBiosNamingServer (NBNS) host announcement is not seen at an expected time.
  • UpnP Universal plug aNd Play
  • NBNS NetBiosNamingServer
  • DAS 22 also maintains the data records hosted in a second data store, LAN signature data store 26, shown in Figure 1 as signature database DB2 26.
  • LAN signature data store 26 contains data records which maps a persistent HTTP cookie value to a corresponding LAN signature which is associated with a service-requesting device 16 hosting a web-browser.
  • a LAN signature in data store 26 is determined and set once by the dynamic addressing server 22 during a one-off device pairing step that is performed the first time the two devices 16, 20 initiate communication with each other.
  • the LAN signature data structures in data store 26 associate a set of one or more device signatures with corresponding hypertext transfer protocol (HTTP) cookies known as web cookies, or as defined below in an exemplary embodiment:
  • HTTP hypertext transfer protocol
  • an http cookie can comprise arbitrary data which is generated by a web-server and sent to a web-browser which returns the cookie unchanged to the web-server to introduce a state into an otherwise stateless HTTP transaction, here the cookie may be determined by a script supported and enabled by a web-browser.
  • DAS 22 extracts the cookie from the http header of the request which is associated with the querying device 16. This cookie is used to perform a look-up operation in data store 26 for the LAN signature of the service-requesting device 16.
  • the LAN signature for the service requesting device device is searched for in the observed LAN signature fields of presence data store 24. If a corresponding entry is found in data store 24, the active network address for the called device via which the service requesting device can obtain the requested web-service can be retrieved by DAS 22 and returned to the web-service requesting device 16. In this way, a private IP address can be returned to the requesting device 16 by DAS 22 which can be used by the requesting device 16 to connected directly to the service-offering device 20 over the LAN.
  • a LAN signature is located in data store 22 but no corresponding observable LAN entry is found, it means that a private network route is not available and the DAS 22 reports to the requesting device 16 that no private address can be located for the requested web-service providing device 20.
  • DAS 22 has no returned LAN signature for the requesting device 16 to compare with any of the current observed signatures for the requested device 20 in the presence address data base 24 (DB1).
  • an "initial pairing" process commences as described in more detail hereinbelow which associates a cookie value for the web-browser application running on the web-service requesting device with a LAN signature.
  • a "LAN signature" is derived from the broadcast IP packets observed by the devices on the LAN.
  • broadcast IP protocols include but are not limited to the Dynamic Host Control Protocol (DHCP), the NetBIOS Name Service (NBNS) protocol, the Multicast Dynamic Name Server (MDNS) protocol, the Simple Service Discovery Protocol (SSDP), and the Internet Group Management Protocol (IGMP).
  • DHCP Dynamic Host Control Protocol
  • NBNS NetBIOS Name Service
  • MDNS Multicast Dynamic Name Server
  • SSDP Simple Service Discovery Protocol
  • IGMP Internet Group Management Protocol
  • Each broadcast packet provides information about a particular device on a network.
  • Each broadcast protocol includes specific fields whose values are device specific and time independent. For example in the case of NBNS this includes the computer name of a MS Windows based PC, in SSDP it may include information about the device unique ID, friendly name, device type of a Universal Plug and Play (UPNP) device. In all cases it provides information about the set of MAC addresses of devices that are broadcasting packets to the LAN.
  • the LANB signature of a device is therefore a set of exemplary IP packets for each multicast protocol.
  • Each exemplary packet comprises a captured packet with the time varying fields discarded.
  • an exemplary broadcast NetBIOS Name Service protocol packet comprises a plurality of time independent fields which are used to populate the LAN signature for a device. For example, the MAC address, Host Name and host description fields may be concatenated to augment the uniqueness of the Host Name field.
  • the pseudocode structure of an exemplary NetBIOS packet is shown below:
  • the pseudocode for an exemplary SSDP broadcast packet as shown below includes a MAC address field and also a USN field which contains a UPnP unique device identifier.
  • two signatures exist in DB2 for the two devices 16,18 in which the two device signatures are time independent and independent of the LAN segment that the devices are connected to.
  • the two device signatures are time independent and independent of the LAN segment that the devices are connected to.
  • a LAN signature for a device comprises a set of one or more device signatures for that device which are observable by means of the packets broadcast in one or more protocols to other devices connected using the same protocol to the same LAN. Accordingly, not all the devices signatures will have entries for all broadcast protocols. Where the phone device is connected to multiple LANs then there will be multiple LAN signatures.
  • the stored device signature is based on broadcast packets issued by a device that is known to have a fixed relation to another device. For example, in a home environment a Wi-Fi enabled photo frame may not generate any broadcast packets however it's relationship to that home network is fixed and is deduced due to the photo frame being capable of observing broadcast packets from other fixed devices on the same LAN, e.g. a printer or desktop PC that do issue broadcast packets.
  • One embodiment provides a signature comparison which involves determining whether any of the device signatures observed in a LAN signature match that of the stored device signature associated with a cookie supplied by the requesting device. Once the device signature has been located (based on the cookie value) then the stored device signature broadcast packet field values are compared with the corresponding fields in the observed device signature packet values If a match is found for any of the protocol types then the stored device is determined to be observable by the mobile phone and hence a private network route exists.
  • Observed device 1 a match is found between Observed device 1 and Stored Device1 based on the computer name field within the NBNS reference and observed packets.
  • the broadcast protocol packet fields are known to be reliably unique, for example, a UpnP UUIDs or Ethernet MAC address are each good candidates for uniquely identifying packet fields.
  • a mobile device On connection to a new LAN, a mobile device, for example a smart phone, starts receiving and storing broadcast packets from other devices which are also connected to the LAN. As each broadcast packet is received the device determines if the packet conforms to a protocol which a previously received packet conformed to and whether it was received from the same source IP address and/or MAC address as the previously received packet. If the device locates a previously received a packet conforming to the same communications protocol from the same source, the device discards the new packet. If not, however, the device stores the newly received packet and sends this to DAS 22 in association with the private IP address that the new packet was observed on which enables multiple network interfaces to be differentiated.
  • the DAS 22 processes the received packet information to derive (and where appropriate update) the device signature. In this way, by extracting and storing the values of the communications protocol specific unique fields it is possible to update presence data store 24.
  • the device On disconnection from a LAN the device informs the DAS 22 that the observed signature associated with its previous private IP address of the disconnected network should be removed from database 26 and/or made available for other devices to use. Where a device supports multiple network interfaces the device then disconnects just one of its interface. In this way, for example, when a device disconnects from a WIFI connection, it is possible to notify this event (the WIFI disconnection) over another interface, for example, a 3G wireless cellular communications network connection. Alternatively, if no network connections are available then the device marks all LAN signatures as empty by calling a telephony server which then uses an identifier for the mobile phone to empty all the observed signatures for that mobile number (e.g. the calling line identifier is used if the International Mobile Subscriber Identity (IMSI) or International Mobile station Equipment Identity (IMEI) identifier for the mobile telephone is not sufficient for this purpose).
  • IMSI International Mobile Subscriber Identity
  • IMEI International Mobile station Equipment Identity
  • a device signature must be previously stored in association with the requesting device.
  • a device signature is associated with a cookie stored by the requesting device's browser. However, initially no cookie exists and an association must first be set up to populate the signature data store DB2 26.
  • the population of data store 26 may be performed in a number of ways.
  • Example 2 User manually identifies requesting device
  • the router performs a similar function to that of the addressing client i.e. capturing broadcast packet information from devices on the network and storing the device specific information for later use.
  • the router will maintain a record of any UpnP UUIDs broadcast from a particular device and if an HTTP request is made to the DAS 22 the router modifies this request to add the UpnP UUID.
  • the DNS 22 correlates the stimulated packet with one or more observations reported by any mobile devices in order to determine which of the observed device signatures correspond to the requesting mobile device. This signature can then simply be copied to the stored device signature database.
  • a 3 rd party AJAX application on a fixed machine (for example, a permanently connected device) wishes to connect to a particular telecommunications enabled server, for example, a phone device, then it may or may not query a user for the phone number of the device to connect to (the preferred phone number may already have been stored in the web application's user preferences database). Once it has the phone number then the required address lookup request is generated.
  • the AJAX application then contacts the proprietary addressing server via HTTP to determine the latest private address for the mobile device.
  • the addressing server extracts the cookie supplied in the request and pulls out the stored device signature associated with this browser and then searches to see if the mobile phone with the requested number has reported that it can see a device with a matching signature (i.e., matching the signature of the service requesting device) using the processes describe earlier.
  • the phone should have reported previously if device is visible (and on which interface(s) if multiple interfaces are possible), and where many interfaces are available, the dynamic addressing server 22 selects an interface according to a preference policy, e.g. it may be configured to select a Bluetooth interface instead of a WIFI interface, which indicates a preferred IP address to contact the mobile device on.
  • the addressing web-service HTTP interface is implemented as a XML based web services accessed though an XMLHttpRequest tag in the AJAX application or as a JSON format object accessed through dynamic loading of a ⁇ script> tag.
  • access to the DAS web service requires a user of the mobile device which is seeking access to supply authentication information, for example, a username and/or password which associated with the identity of the requested mobile phone service. Since this request is a standard HTTP request it is clear that HTTPS could be used to ensure end to end encryption of the web service request for additional security.
  • FIG. 4A of the accompanying drawings shows an exemplary address registration sequence diagram in which device D1(18) is connected to LAN segment L1 (see the sequence arrow labelled (1) in Figure 4 ) and device D2 (20) is also connected to LAN segment L1 (see the sequence arrow labelled (2) in Figure 4 ).
  • Devices D1 (18) and D2 (20) periodically issue multicast packets P1...PN on the LAN L1.
  • M1 (16) which connects to LAN segment L1 (arrow (3).
  • M1 (16) notifies the domain addressing serverdomain addressing server DAS 22 of its new interface connection to LAN segement L1 (arrow (4)).
  • the notification informs the NAT traversal device, for example, router 14, on LAN segment L1 of the private IP address IP1 of M1 (16) and enables the DAS 22 to update the LAN segment L1 presence database DB1 with this information (arrow (5)).
  • Mobile device M1 then captures multicast packet P1 via its interface to LAN L1 (I/F L1). This multicast packet P2 originates from D1 (18) (see dash-dot thick arrows labelled 6).
  • mobile device M1 determines that P1 is a new protocol type packet from device D1 (18) (arrow 7).
  • a packet is now sent by M1 (18) to DAS (22) which associates an identifier for mobile device M1 (IDM1) with information identifying LAN L1 (L1 info) (arrow 8).
  • DAS 22 extracts the time independent fields of packet P1 (arrow 9) and creates new observed device signature SIG1 for device D1 on LAN L1 for mobile device M1 (arrow 10).
  • a mobile device M1 is capable of providing a web-service, i.e., acting as a server, to another device (which may or may not be a device connected to the same LAN L1 such as D1 or D2).
  • the other device on the LAN (which may or may not be D1 or D2) is shown as "Other Device” in Figures 4a , b and 5 now runs a web browser application, referred to below as a "WebApp” which loads the web application (arrow 11) with a http request for the address of mobile service providing device M1 which is sent to DAS 22 (arrow 12).
  • DAS 22 does not find a cookie for M1 (arrow 13).
  • DAS 22 dynamically creates a web page containing the pairing user interface using observed sigs for M1 stored in DB1 (arrows 14, 15, 16).
  • Figure 5 of the accompanying drawings shows an address lookup sequence diagram for an exemplary embodiment, and the description below also refers to preliminary steps which are shown in Figure 4A .
  • devices D1 and D2 already connected to LAN L1 (see the arrows labelled (1) and (2) in Figure 4A ).
  • D1 and D2 periodically issue multicast packets P1...PN (unlabelled arrows in Figure 4A ).
  • Mobile device M1 connects to L1 (arrow (3)), the mobile device M1 notifies DA Server of new interface L1 together with its private IP address IP1 (arrow 4) and DB1 (presence data store 24) is updated (arrow 5).
  • the mobile device M1 then captures a multicast packet P1 on its interface with LAN L1 (I/F L1) which originated from device D1 (thick dash-dot arrows labelled (6)).
  • the mobile device M1 determines packet P1 conforms to a new communications protocol type which it has not previously received from device D1 (arrow 7). This triggers the mobile device M1 to notify the DAS 22 by sending a packet to DAS 22 which associates an identifier for the mobile device ID M1 with LAN L1 (arrow 8).
  • DAS 22 then extracts the time independent fields of packet P1 (arrow 9) and creates new observed device signature SIG1 for D1 on L1 for M1 (arrow 10).
  • Figure 5 shows another device connected to LAN L1, which may or may not be device D1 or D2, runs a web-browser application "WebApp" which loads a web application (arrow 11) using an http request for address of M1 which is sent to DAS 22 (arrow 12).
  • WebApp web-browser application
  • DAS 22 extracts browser ID cookie C1 from request (arrow 13).
  • the DAS 22 looks up stored device signature SIG2 stored for cookie value C1 in the device signature data store 26 (DB2) (arrows 14, 15) and DAS 22 then searches the presence data store 24 (DB1) for match between SIG1 and SIG2 (arrow 16). If match found then presence data store DB1 returns interface details for L1 (arrow 17). The DAS 22 then extracts the M1 private IP address on LAN 1 (arrow 18) and returns the private IP address of M1 on LAN L1 to the requesting web-application (arrow 19). This enables the web-browser application to make an HTTP request to mobile communications device M1 (arrow 20).
  • Figure 1 described herein above shows an exemplary embodiment in which a device 16, referred to hereinbelow as an addressing terminal 16, has a wireless (for example, WIFI) connection to a LAN L1 and has been provided with a private internet protocol IP address 192.168.0.22.
  • the private IP address is used within the private IP address domain of the communications network 10 bounded by router 14.
  • the private IP address is used for routing multicast and unicast packets to the device 16.
  • the same or a different private address domain, also bounded by router 14, may be used for communicating with other devices (for example, device 18 which is capable of running a generic web-browser application)which are connected on the same WIFI/LAN segment with private IP address 192.168.0.20.
  • the private network route may be implemented using a universal serial bus (USB) type of connection or a Bluetooth connection, or other suitable connection in an embodiment in which the addressing device 16 comprises a mobile phone type device and the device #2 (18) comprises a personal computer which can also communicate over a separate 3G wireless LAN.
  • USB universal serial bus
  • the addressing device 16 comprises a mobile phone type device
  • the device #2 (18) comprises a personal computer which can also communicate over a separate 3G wireless LAN.
  • a device 20 Also shown in Figure 1 and connected to the same LAN segment via a wired connection is a device 20, referred to hereinbelow as an addressed device 20, with the private IP address 192.168.0.21.
  • the addressed device is the mobile device which updates the DAS 22.
  • Local LAN connections are supported by a wireless enabled router 14 (which also can support wired connections) and which supports one or more private address domains, including a private IP address range within the LAN segment L1.
  • the LAN public address is perceived to be of the form 193.113.x.y in the exemplary embodiment shown in Figure 1 .
  • the router 14 shown in Figure 1 performs NAT and may also act as an access point for wireless connectivity with LAN segment L1.
  • FIG. 2 shows an alternative embodiment implemented a public wireless LAN (WLAN) environment.
  • WLAN public wireless LAN
  • a wireless router 32 provides an access point for devices 16 and 34 on a wireless LAN to access the internet.
  • Device 16 is shown in Figure 1 as addressing device #1 and is able to communicate only an alternative communications protocol, here via a short-range communications protocol (for example, via a USB or Bluetooth connection) with the other device 34, shown as an addressed device #2 in Figure 1 , due to wireless client separation which prevents the two devices 16 and 34 from communicating directly with each other over the WIFI network.
  • a short-range communications protocol for example, via a USB or Bluetooth connection
  • the addressing device 16 is able to register the presence and availability of services provided by the addressed client with the DAS 22 using the alternative peer-to-peer communications protocol, which enables other devices (not shown) connected to the LAN provided by wireless router 32 to be aware that these services are available from device 34 even though they would not be aware of this device via the LAN supported WIFI communications protocol due to the device separation it is imposing.
  • Figure 3 shows a variation of Figure 2 in which the wireless communications protocol providing the main communication protocol between two devices connected to the same communications network is a wireless cellular communications protocol such as 3G.
  • the wireless communications protocol providing the main communication protocol between two devices connected to the same communications network is a wireless cellular communications protocol such as 3G.
  • two devices 18, 44 are connected to a mobile cellular network 40 (shown in Figure 3 as a 3G cellular network). They are also connected to each other via an alternative private network route, using a different communications protocol, for example, as shown in Figure 3 via BluetoothTM or via a USB connection.
  • the DAS 22 receives notifications from a mobile dynamic addressing device (for example, a mobile telecommunications enable device) 16 that it can see a packet say on a Bluetooth connection from device 44. In this case, the DAS determines that device 16 is presence on the same LAN segment as the addressed device which is running a web-browser application.
  • a device (a term used herein synonymously with mobile device or device) which connects to a LAN is able to make its presence known to other devices already connected to the LAN by registering its presence with DAS 22.
  • Devices on the LAN broadcast packets using a range of communications protocols, some of which differ from the communications protocol used by the LAN. When the device first sees these packets it reports them to the DAS 22 which enables the DAS 22 to update its signature and presence records as appropriate for the reported and reported devices.
  • a service offering mobile device reports to the server a list of unique device identifiers that it can see on each of its interfaces.
  • the server uses a unique id supplied by a service requesting device and matches this identifier against the dynamic list of identifiers which the service offering mobile device reported.
  • the server 22 then confirms back to the service requesting device via which interfaces (and thus via which communications protocols) it is able to communicate (if at all) with the service offering mobile device and provides the appropriate IP address for that interface to the requesting device. It may also provide port and/or other information as appropriate.
  • the DAS 22 uses a cookie supplied by a web-browser application running on the service requesting device to determine the list of identifiers associated with the requesting device. If any of these identifiers for the requesting device have been previously reported by the service providing mobile communications device to the DAS 22, then a private network route exists between the two devices and the appropriate IP address is returned. This means that where two devices are not connectable using the same communications protocol on a particular network at a particular time, if at that time they are capable of forming a connection using a different type of communications protocol/network it is still possible for the two devices to communicate and for a web-browser to be automatically configured to use this alternative "private" route between the two devices.
  • the DNS information is thus updated when the CLI of an inbound call indicates the IP address is stable, which enables a mobile client to update the DNS information when a cellular or WIFI data connection becomes unavailable.
  • the embodiments do not rely on the form of the public IP address of the two devices 16, 20 to determine whether the devices are on the same LAN as the mapping between public address and LAN segment only works if there is a single layer of Network Address Traversal between the devices and the DAS 22 and it is common for there to be multiple layers of NAT in practice.
  • the device requesting the connection can be provided with information by the domain addressing server as to which network communications protocol and interfaces should be used to send the connection request to the other device.
  • the embodiment enables, an address requesting device to provide a device-label (for example, a hostname or telephone number) for a device with which it would like to connect to an domain addressing server which is located externally to the LAN segment.
  • the domain addressing server resolves the device-label to identifier a private address for that particular device which indicates the device is present in the same LAN segment and also, the availability of the device, for example, how it may be connected.
  • two devices Whilst two devices are typically in the same private address range in this embodiment, they need not necessarily be in the same private address range providing the private address is locally routable. Moreover, it is not sufficient for the requesting device to know the private address of the service provider, the requesting device needs to be able to connect to this address. Accordingly, the two devices may have different private address ranges provided they are on the same LAN segment, a term used herein to refer to the area within whose boundary two devices can be located and use ARP for each other and receive multicast traffic, for example, a LAN segment may be bounded by a one-hop router. However, the boundary need not be a physical boundary. A router may bridge two physical LAN segments e.g.
  • the fixed Ethernet and WIFI are bridged to form a single bridged LAN, in which case ARP and multicast traffic are routed across both segments.
  • the devices may be connected on multiple interfaces simultaneously where only one of the interfaces is locally routable.
  • a laptop and a mobile may be both connected to a wide-area network (WAN) using a cellular communications link and to each other over Bluetooth PAN.
  • WAN wide-area network
  • the private addresses are from the Bluetooth link since though both devices will be in the same private cellular address range they are not routable using these private cellular addresses.
  • the Bluetooth private address is sent/received from the addressing server via the cellular WAN. All service traffic is then routed over the Bluetooth LAN since this is the address for the service provider that is used.
  • a user-configurable, uniquely-specified, "label” may be used as a device-label instead of a label which conforms to a known addressing scheme provided this has been previously registered at the DAS 22 and uniquely resolves to a particular device.
  • computing platform comprises one or more data processors, where a data “processor” refers to any device or portion of a device that processes electronic data from registers and/or memory to transform that electronic data into other electronic data that is capable of being stored in registers and/or memory.
  • machine-readable medium comprises any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer).
  • machine-readable mediums include, but are not limited to : read only memory (ROM), random access memory (RAM), magnetic disk storage media, optical storage media, flash memory devices, and propagated electrical, optical, acoustical or other suitable digital and/or analogue signals (for example, carrier waves, infrared signals, digital signals, etc).
  • references to the term "computer program” and/or “computer control logic” include as appropriate references to machine code and/or executable code and/or source code which when compiled results in execution on a computing platform of the computer program.
  • a computer program may be provided in an electronically downloadable format or in a format which is stored in the main memory and/or secondary memory of a computing platform and/or data storage means capable of being attached and removed from a computing platform.
  • a computer program is stored in one or more data storage means it comprises a computer program product.
  • Such computer programs when executed, are arranged to enable the computer platform or system to perform as discussed herein.
  • the computer programs when executed, are arranged to enable a processor to implement one or more steps in a method according to an embodiment. Accordingly, such computer programs may represent data controllers of the computer system.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Telephonic Communication Services (AREA)

Claims (9)

  1. Kommunikations-System (10), das eine öffentliche IP-Adressen-Domäne und ein Segment eines lokalen Netzes beinhaltet, das eine private IP-Adressen-Domäne oder mehrere private IP-Adressen-Domänen umfasst, wobei das Kommunikationssystem (10) umfasst:
    in dem Segment eines lokalen Netzes:
    mindestens eine einen Web-Dienst anfordernde adressierende Vorrichtung (16), die sich in einer privaten IP-Adressen-Domäne befindet und mit Unterbrechungen mit einem lokalen Netz des Segments des lokalen Netzes verbindbar ist,
    mindestens eine einen Web-Dienst bereitstellende adressierte Vorrichtung (20), die mit Unterbrechungen mit einem lokalen Netz des Segments des lokalen Netzes verbindbar ist und dazu ausgebildet ist, einen Dienst für eine einen Web-Dienst anfordernde adressierende Vorrichtung (16) oder mehrere einen Web-Dienst anfordernde adressierende Vorrichtungen (16) bereitzustellen, wobei sich die einen Web-Dienst bereitstellende adressierte Vorrichtung in einer anderen privaten IP-Adressen-Domäne befindet,
    mindestens eine Rand-Vorrichtung (14), die am Rand des Segments des lokalen Netzes und der öffentlichen IP-Adressen-Domäne vorgesehen und dazu ausgebildet ist, eine Übersetzung zwischen einer privaten IP-Adresse und einer öffentlichen IP-Adresse bereitzustellen,
    und
    in der öffentlichen IP-Adressen-Domäne:
    einen Adressierungs-Server (22), der dazu ausgebildet ist, Adressanforderungen für eine private IP-Adresse von einer der einen Web-Dienst bereitstellenden adressierten Vorrichtungen (20) zu empfangen, die durch die Rand-Vorrichtung von einer der einen Web-Dienst anfordernden adressierenden Vorrichtungen (16) übermittelt wurden, und einen ersten Datenspeicher (24) zum Speichern von Informationen zur Präsenz von sämtlichen Vorrichtungen, die mit dem Segment des lokalen Netzes verbunden sind,
    wobei der Adressierungs-Server (22) umfasst:
    eine Einrichtung zur Registrierung der Präsenz und der Verfügbarkeit der einen Web-Dienst bereitstellenden adressierten Vorrichtung (20) unter einer privaten IP-Adresse oder mehreren privaten IP-Adressen in der privaten IP-Adressen-Domäne in dem ersten Datenspeicher (24),
    eine Einrichtung zur Verarbeitung der von der einen Web-Dienst anfordernden adressierenden Vorrichtung (16) empfangenen Adressanforderung, um von einer in der Adressanforderung enthaltenen Vorrichtungs-Kennzeichnung und der in dem ersten Datenspeicher (24) gespeicherten Präsenz-Informationen zu ermitteln, ob die einen Web-Dienst bereitstellende adressierte Vorrichtung (20) gegenwärtig unter einer privaten IP-Adresse präsent und verfügbar ist, die durch die einen Web-Dienst anfordernde adressierende Vorrichtung (16) erreichbar ist,
    und
    eine Einrichtung zum Antworten an die einen Web-Dienst anfordernde adressierende Vorrichtung (16) mit der privaten IP-Adresse für die einen Web-Dienst bereitstellende adressierte Vorrichtung (20)
    und
    einen zweiten Datenspeicher (26) zum Speichern von Informationen zur Vorrichtungs-Signatur, welche die private IP-Adresse der einen Web-Dienst bereitstellenden adressierten Vorrichtung (20) mit einem Cookie verknüpfen, das mit dem Web-Dienst verknüpft ist, der durch die einen Web-Dienst anfordernde adressierende Vorrichtung (16) angefordert wird,
    wobei durch Vergleichen einer privaten IP-Adresse der einen Web-Dienst bereitstellenden adressierten Vorrichtung (20) mit den in dem zweiten Datenspeicher (26) gespeicherten Informationen zur Vorrichtungs-Signatur ermittelt wird, dass eine einen Web-Dienst bereitstellende adressierte Vorrichtung (20) in dem lokalen Netz präsent ist, wobei die Signatur der einen Web-Dienst bereitstellenden adressierten Vorrichtung (20) vorher in Zuordnung zu dem mit dem angeforderten Web-Dienst verknüpften Cookie gespeichert wurde.
  2. System nach Anspruch 1, bei dem die Vorrichtungs-Kennzeichnung eine Telefonnummer ist, die mit der einen Web-Dienst bereitstellenden adressierten Vorrichtung (20) verknüpfbar ist.
  3. System nach Anspruch 2, bei dem die Telefonnummer eine E.164-Nummer ist.
  4. System nach Anspruch 1, bei dem die Vorrichtungs-Kennzeichnung ein Hostname ist, der mit der einen Web-Dienst bereitstellenden adressierten Vorrichtung (20) verknüpfbar ist.
  5. System nach einem vorhergehenden Anspruch, bei dem
    die einen Web-Dienst bereitstellende adressierte Vorrichtung (20) ihre Präsenz und ihre Verfügbarkeit innerhalb der privaten Adressen-Domäne sendet,
    mindestens eine weitere in dem Segment eines lokalen Netzes befindliche Vorrichtung umfasst: eine Einrichtung zum Erfassen der Präsenz und der Verfügbarkeit der einen Web-Dienst bereitstellenden adressierten Vorrichtung (20) und eine Einrichtung zum Senden einer Mitteilung an den Adressierungs-Server (22), die mindestens einen Identifikator für die einen Web-Dienst bereitstellende adressierte Vorrichtung (20) und eine private IP-Adresse für die einen Web-Dienst bereitstellende adressierte Vorrichtung (20) beinhaltet, unter der aufgrund der Ermittlung durch die mindestens eine weitere Vorrichtung die einen Web-Dienst bereitstellende adressierte Vorrichtung (20) präsent und verfügbar ist,
    und
    der Adressierungs-Server (22) ferner eine Einrichtung zum Ermitteln der Präsenz und der Verfügbarkeit der einen Web-Dienst bereitstellenden adressierten Vorrichtung (20) unter einer privaten IP-Adresse aus den erfassten und an den Adressierungs-Server (22) übermittelten Informationen umfasst.
  6. Verfahren, das es einer einen Web-Dienst anfordernden adressierenden Vorrichtung (16) ermöglicht, mit einer einen Web-Dienst bereitstellenden adressierten Vorrichtung (20), die sich in dem gleichen Segment eines lokalen Netzes befindet, zu kommunizieren, wobei das Verfahren umfasst:
    eine Webbrowser-Anwendung, die auf der einen Web-Dienst anfordernden adressierenden Vorrichtung (16) läuft, die eine Dienst-Anforderung für den Web-Dienst erzeugt, an der die einen Web-Dienst bereitstellende adressierte Vorrichtung (20) teilnimmt und welche die private IP-Adresse der einen Web-Dienst bereitstellenden adressierten Vorrichtung (20) verlangt,
    Erzeugen einer Adressen-Anforderung für die in der Dienst-Anforderung identifizierte, einen Web-Dienst bereitstellende adressierte Vorrichtung, wobei die Adressen-Anforderung eine Vorrichtungs-Kennzeichnung für die einen Web-Dienst bereitstellende adressierte Vorrichtung (20) beinhaltet,
    Empfangen der Adressen-Anforderung bei einem Adressierungs-Server (22), der einen ersten Datenspeicher (24), der Präsenz-Informationen speichert, und einen zweiten Datenspeicher (26) aufweist, der Informationen zur Vorrichtungs-Signatur speichert,
    Verwenden der aus der Adressen-Anforderung gewonnenen Vorrichtungs-Kennzeichnung zur Ermittlung unter Verwendung von Präsenz-Daten in dem ersten Datenspeicher (24), ob sich die einen Web-Dienst bereitstellende adressierte Vorrichtung (20) gegenwärtig unter einer privaten IP-Adresse befindet, die in dem gleichen Segment des lokalen Netzes wie die einen Web-Dienst anfordernde adressierende Vorrichtung (16) liegt,
    und, wenn dies der Fall ist:
    Versehen der Webbrowser-Anwendung der einen Web-Dienst anfordernden adressierenden Vorrichtung (16) mit der privaten IP-Adresse der einen Web-Dienst bereitstellenden adressierten Vorrichtung (20) in dem Segment des lokalen Netzes,
    wobei durch Vergleichen einer privaten IP-Adresse der einen Web-Dienst bereitstellenden adressierten Vorrichtung (20) mit den in dem ersten Datenspeicher (20) gespeicherten Informationen zur Vorrichtungs-Signatur ermittelt wird, dass sich eine einen Web-Dienst bereitstellende adressierte Vorrichtung (20) in dem Segment des lokalen Netzes befindet, wobei die Informationen zur Vorrichtungs-Signatur die Vorrichtungs-Kennzeichnung beinhalten,
    und
    wobei die Informationen zur Vorrichtungs-Signatur die private IP-Adresse mit einem Cookie verknüpfen, das mit dem Web-Dienst verknüpft ist, der durch die einen Web-Dienst anfordernde adressierende Vorrichtung (16) angefordert wird, wobei die Signatur der einen Web-Dienst bereitstellenden adressierten Vorrichtung (20) vorher in Zuordnung zu dem mit dem angeforderten Web-Dienst verknüpften Cookie in dem zweiten Datenspeicher (26) gespeichert wurde.
  7. Verfahren nach Anspruch 6, bei dem die Vorrichtungs-Kennzeichnung eine Telefonnummer ist.
  8. Verfahren nach Anspruch 7, bei dem die Telefonnummer eine E.164-Nummer ist.
  9. Adressierungs-Server (22), der ausgebildet ist zum Empfangen von Adressen-Anforderungen für eine private IP-Adresse einer einen Web-Dienst bereitstellenden adressierten Vorrichtung (20), die durch eine Rand-Vorrichtung von einer einen Web-Dienst anfordernden adressierenden Vorrichtung (16) übermittelt werden,
    und der
    einen ersten Datenspeicher (24) zum Speichern von Vorrichtungs-Präsenz-Informationen von sämtlichen mit dem Segment des lokalen Netzes verbundenen Vorrichtungen aufweist,
    wobei der Adressierungs-Server (22) umfasst:
    eine Einrichtung zur Registrierung der Präsenz und der Verfügbarkeit der einen Web-Dienst bereitstellenden adressierten Vorrichtung (20) unter einer privaten IP-Adresse oder mehreren private IP-Adressen in der privaten Adressen-Domäne in dem ersten Datenspeicher (24),
    eine Einrichtung zur Verarbeitung der von der einen Web-Dienst anfordernden adressierenden Vorrichtung (16) empfangenen Adressanforderung, um von einer in der Adressanforderung enthaltenen Vorrichtungs-Kennzeichnung und der in dem ersten Datenspeicher (24) gespeicherten Präsenz-Informationen zu ermitteln, ob die einen Web-Dienst bereitstellende adressierte Vorrichtung (20) gegenwärtig unter einer privaten IP-Adresse präsent und verfügbar ist, die durch die einen Web-Dienst anfordernde adressierende Vorrichtung (16) erreichbar ist,
    und
    eine Einrichtung zum Antworten an die einen Web-Dienst anfordernde adressierende Vorrichtung (16) mit der privaten IP-Adresse für die einen Web-Dienst bereitstellende adressierte Vorrichtung (20)
    und
    einen zweiten Datenspeicher (26) zum Speichern von Informationen zur Vorrichtungs-Signatur, welche die private IP-Adresse der einen Web-Dienst bereitstellenden adressierten Vorrichtung (20) mit einem Cookie verknüpfen, das mit dem Web-Dienst verknüpft ist, der durch die einen Web-Dienst anfordernde adressierende Vorrichtung (16) angefordert wird, wobei durch Vergleichen einer privaten IP-Adresse der einen Web-Dienst bereitstellenden adressierten Vorrichtung (20) mit den in dem zweiten Datenspeicher (26) gespeicherten Informationen zur Vorrichtungs-Signatur ermittelt wird, dass eine einen Web-Dienst bereitstellende adressierte Vorrichtung (20) in dem lokalen Netz präsent ist, wobei die Signatur der einen Web-Dienst bereitstellenden adressierten Vorrichtung (20) vorher in Zuordnung zu dem mit dem angeforderten Web-Dienst verknüpften Cookie gespeichert wurde.
EP10726152.1A 2009-03-31 2010-03-30 Adressierungsschema Active EP2415240B1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GBGB0905559.1A GB0905559D0 (en) 2009-03-31 2009-03-31 Addressing scheme
PCT/GB2010/000620 WO2010112839A1 (en) 2009-03-31 2010-03-30 Addressing scheme

Publications (2)

Publication Number Publication Date
EP2415240A1 EP2415240A1 (de) 2012-02-08
EP2415240B1 true EP2415240B1 (de) 2016-09-07

Family

ID=40672048

Family Applications (1)

Application Number Title Priority Date Filing Date
EP10726152.1A Active EP2415240B1 (de) 2009-03-31 2010-03-30 Adressierungsschema

Country Status (4)

Country Link
US (1) US9160706B2 (de)
EP (1) EP2415240B1 (de)
GB (1) GB0905559D0 (de)
WO (1) WO2010112839A1 (de)

Families Citing this family (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB0905559D0 (en) * 2009-03-31 2009-05-13 British Telecomm Addressing scheme
US8427977B2 (en) * 2009-06-23 2013-04-23 CSC Holdings, LLC Wireless network polling and data warehousing
JP5730914B2 (ja) 2010-03-05 2015-06-10 ブラス・モンキー・インコーポレイテッドBrass Monkey,Inc. Webブラウザにおける双方向通信および内容制御のシステムおよび方法
KR101769472B1 (ko) * 2011-02-25 2017-08-18 삼성전자주식회사 네트워크 시스템 및 그 제어방법
EP2681933B1 (de) * 2011-03-03 2017-05-10 Interdigital Patent Holdings, Inc. Verfahren und vorrichtung für den zugriff auf dienste eines entdeckten dienstanbieters
JP5712870B2 (ja) * 2011-08-30 2015-05-07 富士通株式会社 通信方法、通信装置、および通信プログラム
US11863529B2 (en) 2011-09-09 2024-01-02 Kingston Digital, Inc. Private cloud routing server connection mechanism for use in a private communication architecture
US11683292B2 (en) 2011-09-09 2023-06-20 Kingston Digital, Inc. Private cloud routing server connection mechanism for use in a private communication architecture
US10601810B2 (en) * 2011-09-09 2020-03-24 Kingston Digital, Inc. Private cloud routing server connection mechanism for use in a private communication architecture
US20130339546A1 (en) * 2012-06-13 2013-12-19 Cellco Partnership D/B/A Verizon Wireless Device identification
US9479422B2 (en) * 2013-03-15 2016-10-25 Cable Television Laboratories, Inc. mDNS-DNS architecture
US9917905B2 (en) 2013-05-13 2018-03-13 International Business Machines Corporation Location-based domain name system service discovery
CN106878161B (zh) * 2013-05-23 2020-05-01 柏思科技有限公司 用于解析域名系统请求的方法和系统
US9148408B1 (en) 2014-10-06 2015-09-29 Cryptzone North America, Inc. Systems and methods for protecting network devices
US9906497B2 (en) 2014-10-06 2018-02-27 Cryptzone North America, Inc. Multi-tunneling virtual network adapter
US10285058B2 (en) * 2015-01-09 2019-05-07 Comcast Cable Communications, Llc Providing secure Wi-Fi in an open Wi-Fi environment
US10567518B2 (en) * 2015-06-26 2020-02-18 Western Digital Technologies, Inc. Automatic discovery and onboarding of electronic devices
US20180189080A1 (en) * 2015-06-30 2018-07-05 Societal Innovations Ipco Limited System And Method For Reacquiring A Running Service After Restarting A Configurable Platform Instance
US10015239B1 (en) * 2015-08-12 2018-07-03 Evengx, Llc Self-organizing distributed computation grid
US9866519B2 (en) 2015-10-16 2018-01-09 Cryptzone North America, Inc. Name resolving in segmented networks
US10868708B2 (en) 2015-11-02 2020-12-15 Google Llc System and method for handling link loss in a network
US10412048B2 (en) 2016-02-08 2019-09-10 Cryptzone North America, Inc. Protecting network devices by a firewall
US9913143B1 (en) 2016-11-28 2018-03-06 Amazon Technologies, Inc. Auto-provisioning device
US10356102B2 (en) * 2017-02-24 2019-07-16 Verizon Patent And Licensing Inc. Permissions using blockchain
US10826820B2 (en) * 2017-05-09 2020-11-03 Cisco Technology, Inc. Routing network traffic based on DNS
US11546444B2 (en) * 2018-03-22 2023-01-03 Akamai Technologies, Inc. Traffic forwarding and disambiguation by using local proxies and addresses
CN109327542B (zh) * 2018-11-19 2021-10-26 网易(杭州)网络有限公司 游戏业务访问响应方法、请求转发方法、连接方法、装置
US10951518B2 (en) * 2018-12-31 2021-03-16 Schweitzer Engineering Laboratories, Inc. Packet routing architecture using a registry
CN115460174A (zh) * 2022-08-11 2022-12-09 珠海惠威科技有限公司 一种自动分配终端ip静态地址的方法及系统

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100369939B1 (ko) 2000-12-27 2003-01-29 한국전자통신연구원 전화번호를 이용한 아이피브이6 인터넷 주소 자동생성방법 및 획득방법
US6986047B2 (en) * 2001-05-10 2006-01-10 International Business Machines Corporation Method and apparatus for serving content from a semi-trusted server
US6674758B2 (en) 2002-06-06 2004-01-06 Clinton Watson Mechanism for implementing voice over IP telephony behind network firewalls
US7664096B2 (en) * 2003-06-25 2010-02-16 At&T Intellectual Property I, Lp Remote location VOIP roaming behind firewalls
US20050076141A1 (en) 2003-09-19 2005-04-07 Williams Aidan Michael Use of an autoconfigured namespace for automatic protocol proxying
TW200605574A (en) 2004-02-17 2006-02-01 Ginganet Corp Address resolution apparatus, address resolution method and telecommunication system thereof
US7856213B2 (en) * 2004-02-27 2010-12-21 Research In Motion Limited Method, system, and device for specifying selective override of do-not-disturb functionality
SE527871C2 (sv) 2004-03-09 2006-06-27 Ericsson Telefon Ab L M Metod och system för hantering av webbtjänster
US8205012B2 (en) 2004-03-24 2012-06-19 Electronics For Imaging, Inc. Directory server for automatic network information access systems
US20060221893A1 (en) * 2005-04-01 2006-10-05 Nokia Corporation System, network entity, method, mobile device and computer program product for correlating device identifiers in mobile networks
US20070081544A1 (en) * 2005-10-12 2007-04-12 Matsushita Electric Industrial Co., Ltd. Gateway apparatus, server apparatus, and method for address management
US20070101145A1 (en) * 2005-10-31 2007-05-03 Axalto Inc. Framework for obtaining cryptographically signed consent
US20070214209A1 (en) 2006-03-10 2007-09-13 Motorola, Inc. Platform and method for mobile servers
US8095967B2 (en) * 2006-07-27 2012-01-10 White Sky, Inc. Secure web site authentication using web site characteristics, secure user credentials and private browser
JP4569649B2 (ja) 2008-03-19 2010-10-27 ソニー株式会社 情報処理装置、情報再生装置、情報処理方法、情報再生方法、情報処理システムおよびプログラム
CN102859934B (zh) * 2009-03-31 2016-05-11 考持·维 网络可接入计算机服务的接入管理和安全保护系统和方法
GB0905559D0 (en) * 2009-03-31 2009-05-13 British Telecomm Addressing scheme

Also Published As

Publication number Publication date
GB0905559D0 (en) 2009-05-13
EP2415240A1 (de) 2012-02-08
US9160706B2 (en) 2015-10-13
US20120036233A1 (en) 2012-02-09
WO2010112839A1 (en) 2010-10-07

Similar Documents

Publication Publication Date Title
EP2415240B1 (de) Adressierungsschema
TWI581649B (zh) 存取關連於所發現服務提供者服務方法及裝置
CN1930848B (zh) 用于万维网服务处理的方法和系统
US9407567B2 (en) Enabling external access to multiple services on a local server
EP2839622B1 (de) Verfahren, vorrichtung, netzwerkeinheit und computerprogrammprodukt zur bereitstellung einer ip-dienstanwendung
Kafle et al. An ID/locator split architecture for future networks
US6480508B1 (en) Router-based domain name system proxy agent using address translation
US8307093B2 (en) Remote access between UPnP devices
EP2671367B1 (de) Routen von verkehr zu einem mobilen knoten
US7467214B2 (en) Invoking protocol translation in a multicast network
KR101510103B1 (ko) Nat 디바이스로 구성된 네트워크에서의 원격 접속 방법
CN114258667A (zh) 用于获得ip地址的方法和装置
US8145771B2 (en) Name system in communication network, and naming method
US11979369B2 (en) Methods, systems, and computer readable media for providing for optimized service-based interface (SBI) communications by performing network function (NF) fully qualified domain name (FQDN) resolution at NF repository function (NRF)
JP4186733B2 (ja) 通信システム、端末及びアドレス生成方法
US20130117308A1 (en) Apparatus, Method and System for Node Discovering
WO2015139397A1 (zh) 一种nat64资源获取方法及获取/分配装置
EP2077029A1 (de) Identifikation eines subnetzadressbereichs aufgrund von dns-daten
CN107257331B (zh) 用于提供ip服务应用的方法、设备和存储介质
WO2008069504A1 (en) Method for configuring control tunnel and direct tunnel in ipv4 network-based ipv6 service providing system
Herrero et al. Resource Identification and Management
Belimpasakis et al. Home dns: Experiences with seamless remote access to home services
MXPA06002816A (es) Mantenimiento de la alcanzabilidad de una red movil basada en identificadores de nombres temporales

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20110929

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO SE SI SK SM TR

RIN1 Information on inventor provided before grant (corrected)

Inventor name: EVENDEN, RICHARD, JOSEPH

Inventor name: SCAHILL, FRANCIS, JAMES

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20130704

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

INTG Intention to grant announced

Effective date: 20160419

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

AK Designated contracting states

Kind code of ref document: B1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO SE SI SK SM TR

REG Reference to a national code

Ref country code: GB

Ref legal event code: FG4D

REG Reference to a national code

Ref country code: CH

Ref legal event code: EP

REG Reference to a national code

Ref country code: IE

Ref legal event code: FG4D

REG Reference to a national code

Ref country code: AT

Ref legal event code: REF

Ref document number: 827745

Country of ref document: AT

Kind code of ref document: T

Effective date: 20161015

REG Reference to a national code

Ref country code: DE

Ref legal event code: R096

Ref document number: 602010036195

Country of ref document: DE

REG Reference to a national code

Ref country code: LT

Ref legal event code: MG4D

REG Reference to a national code

Ref country code: NL

Ref legal event code: MP

Effective date: 20160907

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: NO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20161207

Ref country code: FI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160907

Ref country code: LT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160907

Ref country code: HR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160907

REG Reference to a national code

Ref country code: AT

Ref legal event code: MK05

Ref document number: 827745

Country of ref document: AT

Kind code of ref document: T

Effective date: 20160907

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: NL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160907

Ref country code: ES

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160907

Ref country code: SE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160907

Ref country code: LV

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160907

Ref country code: GR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20161208

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 8

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: EE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160907

Ref country code: RO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160907

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160907

Ref country code: PL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160907

Ref country code: BE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160907

Ref country code: IS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20170107

Ref country code: CZ

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160907

Ref country code: SM

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160907

Ref country code: BG

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20161207

Ref country code: AT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160907

Ref country code: PT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20170109

REG Reference to a national code

Ref country code: DE

Ref legal event code: R097

Ref document number: 602010036195

Country of ref document: DE

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160907

PLBE No opposition filed within time limit

Free format text: ORIGINAL CODE: 0009261

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: DK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160907

26N No opposition filed

Effective date: 20170608

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160907

REG Reference to a national code

Ref country code: CH

Ref legal event code: PL

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MC

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160907

REG Reference to a national code

Ref country code: IE

Ref legal event code: MM4A

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: LU

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20170330

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: LI

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20170331

Ref country code: IE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20170330

Ref country code: CH

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20170331

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 9

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MT

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20170330

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: HU

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT; INVALID AB INITIO

Effective date: 20100330

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: CY

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20160907

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160907

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: TR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160907

REG Reference to a national code

Ref country code: DE

Ref legal event code: R079

Ref document number: 602010036195

Country of ref document: DE

Free format text: PREVIOUS MAIN CLASS: H04L0029120000

Ipc: H04L0067286900

P01 Opt-out of the competence of the unified patent court (upc) registered

Effective date: 20230623

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: DE

Payment date: 20240220

Year of fee payment: 15

Ref country code: GB

Payment date: 20240221

Year of fee payment: 15

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: FR

Payment date: 20240221

Year of fee payment: 15