EP0876733A1 - Procede d'acces a une entite cible sur un reseau de telecommunications - Google Patents

Procede d'acces a une entite cible sur un reseau de telecommunications

Info

Publication number
EP0876733A1
EP0876733A1 EP96941768A EP96941768A EP0876733A1 EP 0876733 A1 EP0876733 A1 EP 0876733A1 EP 96941768 A EP96941768 A EP 96941768A EP 96941768 A EP96941768 A EP 96941768A EP 0876733 A1 EP0876733 A1 EP 0876733A1
Authority
EP
European Patent Office
Prior art keywords
die
dns
service
resource
internet
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.)
Withdrawn
Application number
EP96941768A
Other languages
German (de)
English (en)
Inventor
Colin Low
Andrew Franklin Seaborne
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.)
HP Inc
Original Assignee
Hewlett Packard Co
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
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=10789104&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=EP0876733(A1) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Application filed by Hewlett Packard Co filed Critical Hewlett Packard Co
Priority to EP02000568A priority Critical patent/EP1207704B1/fr
Priority to EP02000567A priority patent/EP1207703B1/fr
Publication of EP0876733A1 publication Critical patent/EP0876733A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/4228—Systems providing special services or facilities to subscribers in networks
    • H04M3/42306—Number translation services, e.g. premium-rate, freephone or vanity number services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
    • H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4535—Network directories; Name-to-address mapping using an address exchange platform which sets up a session between two nodes, e.g. rendezvous servers, session initiation protocols [SIP] registrars or H.323 gatekeepers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4552—Lookup mechanisms between a plurality of directories; Synchronisation of directories, e.g. metadirectories
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4557—Directories for hybrid networks, e.g. including telephone numbers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/54—Arrangements for diverting calls for one subscriber to another predetermined subscriber
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M7/00—Arrangements for interconnection between switching centres
    • H04M7/006—Networks other than PSTN/ISDN providing telephone service, e.g. Voice over Internet Protocol (VoIP), including next generation networks with a packet-switched transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q3/00—Selecting arrangements
    • H04Q3/0016—Arrangements providing connection between exchanges
    • H04Q3/0029—Provisions for intelligent networking
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q3/00—Selecting arrangements
    • H04Q3/0016—Arrangements providing connection between exchanges
    • H04Q3/0029—Provisions for intelligent networking
    • H04Q3/0037—Provisions for intelligent networking involving call modelling techniques, e.g. modifications to the basic call state model [BCSM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q3/00—Selecting arrangements
    • H04Q3/0016—Arrangements providing connection between exchanges
    • H04Q3/0029—Provisions for intelligent networking
    • H04Q3/0045—Provisions for intelligent networking involving hybrid, i.e. a mixture of public and private, or multi-vendor systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M7/00—Arrangements for interconnection between switching centres
    • H04M7/12—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13093—Personal computer, PC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13097—Numbering, addressing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13103—Memory
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13106—Microprocessor, CPU
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13175—Graphical user interface [GUI], WWW interface, visual indication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13176—Common channel signaling, CCS7
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13196—Connection circuit/link/trunk/junction, bridge, router, gateway
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13204—Protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13209—ISDN
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13345—Intelligent networks, SCP
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13389—LAN, internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13517—SLEE - service logic execution
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13526—Indexing scheme relating to selecting arrangements in general and for multiplex systems resource management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13527—Indexing scheme relating to selecting arrangements in general and for multiplex systems protocols - X.25, TCAP etc.
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13534—Internet - WWW, HTML, browsers etc.
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13546—Intelligent Peripheral

Definitions

  • the present invention relates to a method of accessing a target entity over a cornmunications network.
  • the present invention finds particular application to the provision of IN (Intelligent Network) services in a switched telecommunications system.
  • IN Intelligent Network
  • switched telecommunication system means a system comprising a bearer network with switches for setting up a bearer channel through the network.
  • switched telecommunication system is to be taken to include not only the existing public and private telephone systems (whether using analogue phones or ISDN-based), but also broadband (ATM) and other switch-based bearer networks that are currently being implemented or may emerge in the future.
  • ATM broadband
  • switched telecommunication system is sometimes shortened herein to telecommunication system.
  • references to a "call” in the context of a switched telecommunication system is to be understood as meaning a communication through a bearer channel set up across the bearer network, whilst references to call setup, maintenance and takedown are to be taken to mean the processes of setting up, maintaining and taking down a bearer channel through the bearer network. Terms such as “call processing” and “call handling” are to be similarly interpreted.
  • communication system when used herein should be understood as having a broader meaning than switched telecommunication system, and is intended to include datagram-based communication systems where each data packet is independently routed through a bearer network without following a predetermined bearer channel.
  • PSTNs Public Switched Telephone Networks
  • PLMNs Public Land Mobile Networks
  • ITN services 800 number services and call forwarding.
  • WWW World Wide Web
  • the present invention proposes technologies for a more synergetic relationship between these two worlds than is currently envisaged and in order to place the present invention in context, a review will first be given of each of these two worlds.
  • the Basic PSTN The basic service provided by a PSTN (Public Switched Telephone Network) is the interconnection of two telephones (that is, setting up a bearer channel between the telephones) according to a called-party telephone number input at the calling-party telephone.
  • Figure 1 is a simplified representation of a PSTN providing such a service.
  • customer premises equipment, CPE, 10 such as standard analogue telephones, but also more recently ISDN terminals
  • the SPs 12 form nodes in an inter- exchange network 13 made up of interconnecting trunks 14 and SPs that are controlled by control entities 15 in the SPs.
  • the control effected by the control entities 15 is determined by signalling inputs received from the CPEs and other SPs, and involves call setup, maintenance and clearance to provide the desired bearer channel between calling CPE and called CPE.
  • the PSTN may be thought of as a bearer - network and a control (signalling) network, the function of the latter being to effect call control through the bearer network, namely the control of setup, maintenance and take down of bearer channels through the bearer network; in practice, the bearer and signalling networks may use the same physical circuits and even the same logical channels.
  • control signalling between the CPE and its local SP is in-band signalling, that is, the signalling is carried on the same channel as used for voice; this signalling is interpreted and converted at the SPs 12 into signalling between SPs that uses a dedicated common-channel signalling network 16 (implemented nowadays using the SS7 protocol suite).
  • the CPE is an ISDN terminal
  • signalling is carried in a separate channel directly from the CPE on an end- to-end.
  • Modern SPs use the ISUP (ISDN User Part) SS7 protocol for inter-exchange call control signalling whether the CPE is a standard telephone or an ISDN terminal.
  • Telephone Numbering Plans As certain aspects of the present invention are influenced by the structuring of telephone numbers, a brief description will now be given of the structuring of such numbers.
  • Telephone numbers form an international, hierarchical addressing scheme based on groups of decimal digits.
  • the top level of the hierarchy is administered by the ITU-T, which has allocated single-digit numeric codes to the major geographic zones (for example "1 " for North America, "2" for Africa, “3” for Europe, “4" for Europe, "5" for South America and Cuba, etc.). Within each zone countries are assigned 2 or 3 digit codes, so that within zone 3 France is "33", and within zone 4 the UK is "44".
  • the first case has the '0' prefix, a 3 digit area code and a 7 digit local number
  • die second case has the '0' prefix, a 4 digit area code, and a 6 digit local number. Further interpretation of the local number will take place within the area exchange, as even a 6 digit address space is too large for a single switch, and for a typical local area several switches may be needed to host the required number of subscriber lines. This interpretation is opaque and is a matter for the area service provider.
  • an SP may also serve to provide what are called IN (Intelligent Network) services; in this case the SP is termed a service switching point, SSP.
  • An SSP 25 is arranged to suspend call processing at defined points-in-call upon particular criteria being met, and to delegate the continuation of call processing to a service control subsystem providing a service " control function (SCF) either in the form of a service control point, SCP 17 (see Figure 2) or an Adjunct 18.
  • SCF service "control function
  • the Adjunct 18 is directly associated with an SSP 25 whilst the SCP 17 and SSP 25 communicate with each other via an extended common channel signalling (CCS) network 16 that may include signal transfer points (STP) 19.
  • CCS common channel signalling
  • STP signal transfer points
  • the SCP 17 may be associated with more than one SSP 25.
  • Both the SCP 17 and Adjunct 18 provide a service logic execution environment (SLEE) 20 in which instances of one or more service logic programs (SLP) 21 can execute.
  • SLP service logic programs
  • the SLEE 20 and SLP 21 togeu er provide service control functionality for providing services to the SSP 25.
  • Service logic running in an SCP or Adjunct will generally make use of subscriber information stored in a service data function (SDF) 22 that may be integral with the SCP/ Adjunct or partially or wholly separate therefrom.
  • SDF service data function
  • SCF service control function
  • the Figure 2 network includes an intelligent peripheral (IP) 23.
  • IP 23 provides resources to the SSP 25 such as voice announcements and DTMF digit collection capabilities.
  • the network will also include an operation system (not shown) that has a general view of the network and its services and performs functions such as network monitoring and control.
  • the SSP 25 when it receives a call, it examines internal trigger conditions and, possibly, user information (eg dialled digits) to ascertain if the call requires a service to be provided by the service control subsystem 17, 18; the checking of trigger conditions may be carried out at several different points in call processing.
  • the SSP 25 determines that a service is required it messages the service control subsystem (either SCP 17 or Adjunct 18) requesting the desired service and sending it a logic representation of the call in terms of its connectivity and call processing status.
  • the service control subsystem then provides the requested service and this may involve either a single interaction between the SSP and service control subsystem or a session of interactions.
  • a typical service is call forwarding which is a called-party service giving expression to an end-user requirement as simple as "if you call me on number X and it rings ten times, try calling number Y" .
  • it is the SSP local to the called end-user that triggers its associated SCP (or Adjunct) to provide this service; it will, of course, be appreciated that the SSP must be primed to know that the service is to be provided for a called number X.
  • PLMNs Public Land Mobile Networks
  • GSM Global System for Mobile communications
  • Control signalling in the case of a mobile subscriber is more complex because in addition to all the usual signalling requirements, there is also a need to establish where a call to a mobile subscriber should be routed; however, this is not a very different problem from a number of called-party IN services in the PSTN.
  • the service data function is largely located in a system named a Home Location Register (HLR) and the service control function in a system named a Visitor Location Register (VLR) that is generally associated on a one-to-one basis with each SSP (which in GSM terminology is called a Mobile Switching Centre, MSC).
  • HLR Home Location Register
  • VLR Visitor Location Register
  • the HLR and VLR thus constitute a service control subsystem similar to an SCP or Adjunct with their associated databases.
  • the service control function and service data function are generally either integrated into a PABX (Private Automatic Branch Exchange) or provided by a local computer.
  • PABX Primary Automatic Branch Exchange
  • the service control subsystem whilst present, may thus not be a physically distinct from the PABX.
  • the WWW is a client-server application running over the Internet and using a client- server protocol which mandates only the simplest of exchanges between client and server.
  • This protocol is HTTP (Hyper Text Transfer Protocol) which is optimised for use over TCP/IP networks such as the Internet; the HTTP protocol can, however, also be used over networks using different communication protocol stacks.
  • the WWW uses the Internet for interconnectivity.
  • Internet is a system diat connects together networks on a worldwide basis.
  • Internet is based on the TCP/IP protocol suite and provides connectivity to networks that also use TCP/IP.
  • IP addresses are hierarchically structured. Generally an entity will be identified at the user level by a name that can be resolved into the corresponding IP address by the Domain Name System (DNS) of the Internet.
  • DNS Domain Name System
  • the Domain Name System is a global, distributed, database, and without its performance, resilience and scalability much of the Internet would not exist in its current form.
  • the DNS in response to a client request, serves to associate an Internet host domain name with one or more Registration Records (RR) of differing types, the most common being an address (A) record (such as 15.144.8.69) and mail exchanger (MX) records (used to identify a domain host configured to accept electronic mail for a domain).
  • A address
  • MX mail exchanger
  • the RRs are distributed across DNS name servers world-wide, these servers cooperating to provide the domain name translation service; no single DNS server contains more than a small part of the global database, but each server knows how to locate DNS servers which are "closer" to the data dian it is.
  • the main characteristics of the DNS of interest are:
  • the host name space is organised as a tree-structured hierarchy of nodes with each host having a corresponding leaf node; each node has a label (except the root node) and each label begins wi an alphabetic character and is followed by a sequence of alphabetic characters or digits.
  • the full, or "fully qualified" name of a host is the string of node labels, each separated by a ". ", from the corresponding leaf node to the root node of the hierarchy, this latter being represented by a terminating ".” in the name.
  • DNS servers each with responsibility for a subtree of the name space.
  • a DNS server will hold RRs for all or part of its subtree - in the latter case it delegates responsibility for the remainder of die subtree to one or more further DNS servers.
  • a DNS server knows e address of any server to which it has delegated responsibility and also the address of the server which has given it the responsibility for the subtree it manages. The DNS servers thus point to each other in a stmcturing reflecting that of the naming hierarchy.
  • An application wishing to make use of the DNS does so through an associated "resolver" that knows the address of at least one DNS server.
  • a DNS server When a DNS server is asked by this resolver for an RR of a specified host, it will return either the requested RR or the address of a DNS server closer to the server holding the RR in terms of traversal of the naming hierarchy.
  • the hierarchy of the servers is ascended until a server is reached that also has responsibility for the domain name to be resolved; thereafter, the DNS server hierarchy is descended down to the server holding the RR for the domain name to be resolved.
  • the DNS uses a predetermined message format (in fact, it is the same for query and response) and uses the IP protocols.
  • DNS-type a "DNS-type" system always allowing for minor variations such as in label syntax, how the labels are combined (ordering, separators), the message format ietails, evolutions of me IP protocols etc.
  • top-level domains are administered by InterNic (these top-level domains include me familiar 'com' , 'edu' , 'org' , 'int', 'net', 'mil' domains as well as top-level country domains specified by standard two-letter codes such as 'us' , 'uk', 'fr' etc.).
  • Hewlett-Packard Company is responsible for all names ending in 'hp.com' and British Universities are collectively responsible for all names ending in 'ac.uk'.
  • FIG. 3 illustrates me progress of an example query made from within Hewlett-Packard Laboratories.
  • the host domain name to be resolved is 'xy.newcastle.ac.uk', a hypothetical machine at the University of Newcastle, United Kingdom.
  • the query is presented to the DNS server responsible for the "hpl.hp.com" subtree.
  • This server does not hold the requested RR and so responds with the address of the "hp.com” DNS server; this server is then queried and responds with the address of the 'com' DNS server which in turn responds with the address of the ' . ' (root) DNS server. The query then proceeds iteratively down the 'uk' branch until the 'newcastle.ac.uk' server responds with the RR record for the name 'xy' in its subtree.
  • DNS servers are designed to build a dynamic cache, and are initialised with the addresses of several root servers, so in practice most of the iterative queries never take place.
  • me 'hpl.hp.com' DNS server will know the addresses of several root servers, and will likely have the addresses of 'uk' and 'ac.uk' servers in its cache.
  • the first query to the 'hpl.hp.com' server will return the address of the 'ac.uk' server.
  • the second query to the 'ac.uk' server will return the address of the 'newcastle.ac.uk' server, and the third query will return the RR in question.
  • the resolver may specify its first query to be recursive in which case the receiving DNS server * responsible for resolving the query (if it cannot directly return the requested RR, it will itself issue a recursive query to a 'closer' DNS server, and so on).
  • each DNS server will be replicated, that is, organised as a primary and one or more secondaries.
  • a primary DNS nameserver initialises itself from a database maintained on a local file system, while a secondary initialises itself by transferring information from a primary.
  • a subtree will normally - have one primary nameserver and anything up to ten secondaries - the limitation tends to be the time required by the secondaries to update their databases from the primary.
  • the primary database is the master source of subtree information and is maintained by the domain DNS administrator.
  • the secondaries are not simply standby secondaries but each actively participates in the DNS with dependent servers that point to it rather than to the corresponding primary.
  • DNS implementations such as BIND, are widely available as a standard part of most UNIX systems, and can claim to be among the most robust and widely used distributed applications in existence.
  • access to the Internet 30 may be by direct connection to a network that is itself directly or indirectly connected to the Internet; such an arrangement is represented by terminal 31 in Figure 4 (this terminal may, for example, be a Unix workstation or a PC). Having a connection to me Internet of this form is known as having 'network access'. Any entity that has network access to the Internet may act as a server on the Internet provided it has sufficient associated functionality; in Figure 4, entity 32 with file store 37 acts as a server.
  • ISP Internet service provider
  • the user terminal 34 will generally communicate with the ISP 33 over the public telephone system using a modem and employing either SLIP (Serial Line Interface Protocol) or PPP (Point-to-Point Protocol). These protocols allow Internet packets to traverse ordinary telephone lines. Access to me Internet of this form is known as "dialup IP" access. Wim ⁇ is access method, the user terminal 34 is temporarily allocated an IP address during each user session; however, since this IP address may differ between sessions, it is not practical for the entity 34 to act as a server. - A cornerstone of the WWW is its ability to address particular information resources by means of an Uniform Resource Identifier (URI) that will generally be either a
  • URL Uniform Resource Locator
  • a full or "absolute" URL will comprise the following elements: scheme - this is the access scheme to be used to access the resource of interest; host - the Internet host domain name or IP address; port - the host port for the (TCP) connection; abs-path - the absolute path of the resource on the host.
  • the 'port' may be omitted in which case port 80 is assumed.
  • FIG. 5 of the accompanying drawings shows an example URL for the Hewlett- Packard products welcome page.
  • the elements are: scheme - http host - www.hp.com port - omitted (port 80 assumed) abs-path - Products.html
  • the HTTP protocol is based on a request/response paradigm.
  • a client establishes a connection with the server 31 corresponding to the "host" element of the URI and sends a request to the server.
  • This request includes a request method, and the "Request-URI” (which is generally just the absolute path of the resource on the server as identified by the "abs-path” element of the URI); the request may include additional data elements.
  • the server 31 accesses me resource 36 (here held on storage 37) and responds and this response may include an entity of a type identified by a MIME (Multipurpose Internet Mail Extensions) type also included in the response.
  • MIME Multipurpose Internet Mail Extensions
  • the two main request methods are:
  • Request-URI refers to a data-producing process
  • the produced data which is returned as the entity in the response and not the source text of me process.
  • POST - This method is used to request that me destination server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI.
  • the POST method can be used for annotation of existing resources, providing a message to a bulletin board, providing data to a data-handling process (for example, data produced as me result of submitting a form), and extending a database through an append operation.
  • the GET method can be used to directly retrieve data, or to trigger any process that will return an entity (which may either be data or a simply an indication of the result of running the process).
  • the POST method is used for registering data and specifying this method is also effective to trigger a process in the server to handle the posted data appropriately.
  • CGI Common Gateway Interface
  • HTML HyperText Markup Language
  • HTML is used to identify each part of a document, such as a title, or a graphic, and it is then up to the browser running in the client terminal to decide how to display each document part.
  • HTML is more than this - it also enables a URI and a request method to be associated with any element of a document (such as a particular word or an image) so that when a user points to and clicks on that element.
  • the resource identified by the URI is accessed according to the scheme (protocol) and request method specified.
  • This arrangement provides a hyperlink from one document to another. Using such hyperlinks, a user at a client terminal can skip effortlessly from one document downloaded from a server on one side of the world, to another document located on a server on the other side of the world. Since a document created by one author may include a hyperlink to a document created by another, an extremely powerful document cross-referring system results with no central bureaucratic control.
  • Hyperlinks are not the only intelligence that can be built into an HTML document. Another powerful feature is the ability to fill in a downloaded "Form" document on screen and then activate a 'commit' graphical button in order to have the entered information passed to a resource (such as a database) designed to collect such information. This is achieved by associating me POST request method with the 'commit' button together with the URI of the database resource; activating the 'commit' button results in the entered information being posted to the identified resource where it is appropriately handled.
  • a resource such as a database
  • HTML is only one of several currently available scripting languages delivering the functionality outlined above and it may be expected that any serious Web browser will have built-in support for multiple scripting languages.
  • Netscape 2.0 supports HTML 3.0, Java and LiveScript (the latter being Netscape proprietary scripting Language).
  • a Web browser should provide built-in support for standard media types, and the ability to load and execute programs in the client, amongst other features. These browsers may be viewed as operating systems for WWW interaction.
  • Another known example of the cooperative use of the Internet and PSTN is a recently launched service by which an Internet user with a sound card in his/her terminal computer can make a voice call to a standard telephone anywhere in the world. This is achieved by transferring digitised voice over the Internet to a service provider near the destination telephone; this service provider then connects into the local PSTN to access the desired phone and transfers across into die local PSTN me voice traffic received over the Internet. Voice input from me called telephone is handled in the reverse manner. Key to this service is the ability to identify the service provider local (in telephony charging terms) to the destination phone. This arrangement, whilst offering the prospect of competition for the telecom operators for long distance calls, is again a simple chaining together of the Internet and PSTN.
  • a method of accessing a target entity over a communications network comprising the steps of:
  • step ( b) supplying a number string indicative of a target entity and forming the related domain name by said process including parsing at least a substantial part of the number string into at least a part of a domain name; (c) - applying the domain name formed in step (b) to the DNS-type distributed database system to retrieve the communication data held in the corresponding record; and
  • step (d) using the communication data retrieved in step (c) in accessing the target entity.
  • the communications network is a telephone network and the target en t ity is a called party.
  • the number string may comprise a dialed number and the retrieved communication data may be a current telephone number for the t arget - party.
  • die retrieved communication data may be a URI indicative of the location on a computer network of a current telephone number for the target party, said URI being thereafter used to retrieve this current telephone number for use in accessing the target party.
  • the communications network is a computer network and the target entity is a resource item held at a corresponding URI on that network.
  • the number string may comprise a telephone number for the target party and the retrieved communication data may be me URI of the target resource item.
  • This target resource item is, for example, a current telephone number of a target party it is wished to call, said number string being a personal telephone number for that target party.
  • the resource item may be: downloadable data which upon being accessed is intended to be downloaded to me accessing entity; — downloadable service logic which upon being accessed is intended to be downloaded to the accessing entity for execution thereby, service logic intended to be executed in place upon being accessed wid the result of mis execution being returned to the accessing entity;
  • diis can be done by dividing said substantial portion into label segments according to a division scheme which is the same for all number strings.
  • the parsing of this number preferably involves forming a label segment of the country code component of die international telephone number and men forming further label segments from die remainder of the international telephone number according to a division scheme the same for all such numbers.
  • the forming of the further label segments from the remainder of the international telephone number can be effected according to a division scheme that is dependent on die identity of said country code component.
  • the DNS-type distributed database system is adapted to handle a set of domain names diat make up a name space herein referred to as the "telname space".
  • the root of the telname space is the root of the overall name space handled by die DNS-type distributed database system.
  • the DNS-type distributed database system is provided by the DNS of die Internet and in diis case the telname space may be provided by one or more subdomains of die DNS.
  • die telname space may form a "tei" subdomain in the domain .itu.int. of me DNS; alternatively, the telname space may be provided by respective subdomains in at least some of the country domains of the DNS.
  • telname space is a subdomain of a larger name space
  • a predetermined part of the number string may be used to look up a domain name tail corresponding to me root of me telname space in the larger name space.
  • This domain name tail is men added to the domain name part derived by said parsing of at least a substantial portion of die number string.
  • the country code component can be used to look up me domain name tail corresponding to me appropriate subdomain.
  • Figure 1 is a simplified diagram of a standard PSTN
  • Figure 2 is a simplified diagram of a known PSTN w h IN service capability
  • Figure 3 is a diagram illustrating host domain name resolution by the DNS of me Internet;
  • Figure 4 is a diagram illustrating die functioning of the World Wide Web;
  • Figure 5 is a diagram illustrating the format of a standard URL
  • ' is a diagram of a first arrangement in which service resource items are held on HTTP servers accessible both by me service control subsystem of a PSTN and by Web users
  • Figure 7 is a diagram illustrating me processing of a service request by the SCP of Figure 6;
  • Figure 8 is a diagram illustrating the format of a resource code used by the
  • Figure 6 SCP when accessing a service resource item; .
  • Figure 9 is a diagram illustrating the process of accessing a service resource in die case where me service code does not include an RRI part; .
  • Figure 10 is a diagram illustrating the process of accessing a service resource in the case where the service code includes an RRI part;
  • Figure 11 is a diagram illustrating the derivation of the URI of a service resource by parsing an input telephone number in accordance with the present invetion; .
  • Figure 12 A is a diagram depicting a name space (the "telname space") constituted by the domain names derived by a parsing of a predetermined set of telephone numbers; .
  • Figure 12B is a diagram depicting the incorporation of die telname space wimout fragmentation into the DNS;
  • Figure 12C is a diagram depicting the incorporation of die telname space in fragmented form into the DNS; .
  • Figure 13 is a diagram illustrating the overall operation of the Figure 6 arrangement in providing
  • Figure 16 is a diagram illustrating the overall operation of an arrangement in which a call setup gateway is provided between me Internet and the PSTN;
  • Figure 17 is a diagram illustrating the overall operation of an arrangement in which a freephone service is implemented for Web users;
  • Figure 18 is a diagram similar to Figure 6 illustrating the provision of a distributed processing environment for interconnecting elements of the service control subsystem of the PSTN.
  • Figure 6 illustrates an arrangement for me provision of services in a PSTN conventionally comprising an inter-exchange network 13 (including trunks and switches at least some of which are SSPs 41 wi associated LPs), an access network 11 connecting customer permise equipment (here shown as telephones 40) to the network 13, and a service control subsystem 42 including at least one SCP for providing services to die SSPs 41 upon request.
  • an inter-exchange network 13 including trunks and switches at least some of which are SSPs 41 wi associated LPs
  • an access network 11 connecting customer permise equipment (here shown as telephones 40) to the network 13, and a service control subsystem 42 including at least one SCP for providing services to die SSPs 41 upon request.
  • the SCP 43 may operate in a conventional manner responding to service requests from SSPs 41 to run specific service logic on particular data according to information contained in the service request, and to send back to the requesting SSP appropriate instructions for effecting call set up.
  • a service request is generated by e SSP in response to predetermined trigger conditions being met at a trigger check point, mere being one or more such check points in the course of handling a call (it may be noted that where die trigger conditions have been downloaded to die SSP from die SCP men it could be said that die SSP is responding to an information request by the SCP when contacting die SCP upon die trigger conditions being met - however, in the present specification, iis initial communication from the SSP to the SCP will be referred to as a "service request").
  • the SCP 43 is also provided with a network access interface 44 to the Internet 50 in order to make use of certain service resource items 49 (also referred to below simply as "service resources") during the course of processing at least certain service requests from die SSPs 41.
  • service resources 49 are held as WWW pages on HTTP servers 51 (more particularly, on service resource databases 52 of these servers 51).
  • the WWW pages containing these service resources are referred to below as "phone- pages.
  • the servers 51 are connected to the Internet and the phone pages are read accessible using respective URLs or URNs (for convenience, the more general term URI will be used hereinafter to mean the Internet-resolvable indicator of the location of a phone page).
  • the service resources may be service logic or service data and may be used by an otherwise standard service logic program running on the SCP, by accessing the phone page of the required resource using the appropriate URI.
  • the service resources 49 may provide substantially all of the service control and data associated with a particular service.
  • the service logic program running in the SCP 43 is of skeleton form, being instantiated on receipt of a service request and then serving to initiate service resources access and to return the results of this access to the entity that made the service request.
  • the SCP could be implemented simply as a platform for fetching and executing phone-page service logic and would not need to have the complex provisioning and management systems for such logic as is required by standard SCP platforms; SCPs could then become more ubiquitous, possibly being associated with every SSP.
  • FIG 7 is a flow chart illustrating the progress of events in the case where the SCP 43 handles a service request by accessing a phone-page service resource.
  • SCP 43 Upon receipt of a service request in an INAP message (step 100), SCP 43 decodes the TCAP/INAP message structure in standard manner (steps 101 and 102) well understood by persons sk i lled in the art.
  • SCP 43 instantiates a service logic program, SLP, to handle the request (step 103). This SLP is then responsible for looking up the URL of the requ i red service resource as determined from information contained in the service request (steps 104, 105).
  • a resource request (for example, in the form of an HTTP request message ) is sent over the Internet to the corresponding server holding me desired service resource (step 106); a correlation ID is also passed witii die resource request to enable a response from the latter to be linked with die appropriate SLP instance.
  • a timer is also started (step 107).
  • dien me response which is usually in the form of a destination number, is supplied to the appropriate SLP as identified using me correlation ID passed widi die response (step 109).
  • An INAP/TCAP response message is then prepared and sent to the entity that made the original service request (steps 110 and 111) after which me SLP instance is terminated (113).
  • a default response value (generally a default destination number) may be looked up in me customer record and put in an INAP/TCAP message and sent back to me requesting entity (steps 114 to 116). The SLP instance is then terminated (113).
  • Block 46 includes URI determination block 47 for determining the URI of the phone page containing me desired resource on the basis of parameters passed to block 46. Using the URI returned by block 47, die resource access block 46 then accesses die phone page of me required service resource 49 over the Internet through interface 44.
  • each service resource can be considered as being identified by a respective resource code 54 (see Figure 8) made up of a first part UI ("URI Identifier”) used to identify the URI at which the resource is located on the Internet, and a second part RRI (“Relative Resource Identifier”) used to identify the resource amongst plural resources at the same URI.
  • UI URI Identifier
  • RRI Relative Resource Identifier
  • Resource Access Where only one service resource 49 is located on a phone page 58 identif i ed by a unique URI, then the resource code 54 simply comprises the UI , generally either a telephone number alone or a telephone number plus a pic parame t er ( see Figure 9). In this case, accessing a resource simply involves mapping the whole resource code 54 into the corresponding URI (process 55) and then sending a request
  • the resource code 54 comprises both a UI and RRI, the UI generally being a telephone number and the RRI a pic or other parameter for distinguishing between the co-located resources.
  • accessing a resource involves mapping the UI part of the resource code 54 into the corresponding URI ( process 55) and then sending a request 57 to the corresponding phone page (process 56), the request i ncluding the RRI of the resource code.
  • the phone page 58 includes functionality 64 for accessing the required resource on the basis of the RRI in the request message. The result of accessing the required resource 49 is then returned in response message 59.
  • Block 47 may be implemented in a variety of ways, four of which are described below:
  • the calling party may thus input the host id component of the URI required (ehher in the form of a host domain name or host IP address) plus die path component of die URI.
  • the calling party may input the URI of the called party and, indeed, diis input may substitute for me normal input of a telephone number.
  • a leading input string (for example "999") may be used to identify die input as an URI.
  • die input means where a user only has a standard 12 key telephone, input of host domain names and other URI elements requiring alpha characters, will need to be done using one of the standard techniques for alpha input from a phonepad (such techniques are already used, for example, to enable a calling party to "spell" out the name of the called party). It would also be possible to provide users wi i a full alphanumeric keypad to facilitate URI input.
  • Computation Service resource access over the Internet could be restricted to a set of dialled numbers from which it was possible to compute a corresponding URI; in diis case, diis computation would be die responsibility of block 47.
  • a service resource may be required for a called party number on me odier side of me world which implies a rigorous update regime between PSTN operators worldwide in order to keep die association table up-to-date. (Note diat me same implication is not necessarily applicable in respect of marking the called-party number as one required to trigger a service request, since the number may be arranged to be one of a group of numbers all triggering an appropriate service request, in a manner similar to 800 numbers).
  • DNS -Type Lookup An alternative lookup solution is to use a hierarchically-structured distributed database system, similar to (or even part of) the Domain Name System (DNS) of the Internet, in order to resolve the UI part of a resource code to a corresponding URI.
  • DNS Domain Name System
  • This approach would typically involve databases maintained by each PSTN operator for its numbers widi which URIs are associated. These databases would be accessible by all PSTNs dirough a network such as die Internet widi resolution requests being pointed to die appropriate database in a manner similar to me Domain Name System.
  • the block 47 is constituted by an appropriate resolution program arranged to request UI resolution over die Internet through interface 44.
  • a part of the URI pad component can be made standard for all service resources, this standard part being simply added by the block 47 once the rest of the URI has been determined. For example, where a roaming number is to be looked up, it may by convention always be held in a file "roam" in a subdirectory "tei" of a subscriber's directory on a particular server. In this case die URI host component and die subscriber-unique part of the path component are first determined and men the remaining path part "/tel/roam" is added, (ii)
  • the URI patii component can be arranged to be die same as a predetermined part of me resource code, me block 47 needing only to determine die host component and men add me path. For example, it may be agreed that me path must always end wid the telephone number concerned, or sufficient of die terminating digits to have a high probability of uniqueness on the host machine.
  • the patii may also include standard components to be added by block 47.
  • Blocks of telephone numbers may have tiieir corresponding service resources located on the same host server so that it is only necessary to use a part of the telephone number to determine die host component of the URI; in dus case, die path component can conveniendy include all or part of each telephone number. This situation implies a tight degree of control by d e telephone operators and does not offer die telephone user die freedom to choose the host server on which user places their phone page.
  • me host component of the URI may be provided eitiier in the form of a host domain name or a host IP address.
  • a further resolution of URI host name to IP address will subsequendy be carried out in standard manner by interface 44 using the Domain Name System of die Internet. This further resolution can be avoided if d e host identity is directly provided as an IP address.
  • diis database may be independent of, or combined with, a customer database containing odier customer-related information.
  • Factors affec diis choice include, on die one hand, die possible desirability of having die nui. cr-to-URI translation information widely available, and on the odier hand, me possible desirability of restricting access to other customer-related information.
  • DNS-Tvoe URI Lookup A DNS-type lookup implementation for die URI determination block 47 will now be described in some detail for me case where the UI part of the resource code is a telephone number and diere are no constraints on the URI, ⁇ ereby requiring both die full host and padi components of the URI to be returned by die lookup.
  • a key part of the overall process is die formation of die equivalent of a host domain name from the telephone number of interest; diis domain-name equivalent is then resolved into a corresponding URI by a lookup mechanism which in me present example is identical to tiiat employed by die DNS (indeed, die lookup mechanism may be inco ⁇ orated into e DNS though it can also be independently implemented).
  • telname space the name space containing such host domain names for the ?lephone numbers of interest is referred to below as die "telname space"
  • an input telephone number forming, in me present case, die UI part of a resource code 54 is first parsed to form a domain name (step 120) and dien passed to die Duris system (illustrated in Figure 11 as formed by die DNS itself) to retrieve die RR with the corresponding URI (step 121). Following on from the URI lookup, if d e URI returned has its host component as a domain name, die DNS is next used to derive the host IP address (step 122); diis step is, of course not needed if die host component is stored as an IP address in the RR. The URI is dien used to make a resource request to the appropriate server, passing any RRI part of die resource code 54 (step 123). - There are a number of possibilities at the top level as to how a Duris system could be implemented:
  • the telname space constitutes me entire name space to be managed widi die root of the telname space being die " . " name space root (see Figure 12A where me telname space is shown hatched).
  • die Duris system is independent of die DNS itself.
  • the Duris system could, of course, use die same basic infrastructure as die DNS (that is, the Internet) or an entirely separate network.
  • die telname space comprises all the domain names corresponding to all public telephone numbers worldwide, parsing a full international telephone number would give a fully qualified domain name.
  • me telname space could be a much smaller set of names such as tiiose derived from internal extension numbers within a company having worldwide operations.
  • telname space is a domain of the DNS name space and die Duris system is provided by die
  • telname space comprises all domain names derived from public telephone numbers worldwide
  • die telname space could be placed within die domain of die ITU, in a special subdomain “tei", e root of the telname space men being "tel.itu.int. " (see Figure 12B where again, me hatched area represents the telname space).
  • Theoireity for administering the domain "tel.itu.int. " would dien lie widi die ITU. Widi diis latter example, to form a fully qualified domain name from an input telephone number, after the number has been parsed to form the part of the domain name corresponding to die structuring witi ⁇ n die telname space, the tail "tel.itu.int. " is added.
  • the fully qualified domain name is men applied to me DNS and me corresponding
  • die telname space could be all name derived from internal extension numbers within Hewlett-Packard in which case die root of me telname space would be "tel.hp.com. " and Hewlett-Packard would be entirely responsible for managing this domain.
  • die telname space is split between multiple domains of die DNS name space and d e Duris system is provided by die DNS itself.
  • die telname space comprises all domain names derived from public telephone numbers worldwide
  • die telname space could be split between respective "tei" subdomains of each country domain; dius, as illustrated in Figure 12C, die part of die telname space corresponding to French telephone numbers would have a root of "tel.fr. " and die part of die telname space corresponding to UK telephone numbers would have a root of "tel.uk.”.
  • the Spotifyity for administering each "tei" subdomain would dien lie widi each country.
  • Widi di to form a fully qualified domain name from an input telephone number
  • the part of the telephone number following me country code is parsed to form die part of the domain name within a country 'tei' subdomain and dien a host domain name tail is added appropriate for the country concerned.
  • me "33" country code is stripped from the number prior to parsing and used to add a tail of "tel.fr. " .
  • the tail appropriate to each country can be stored in a local lookup table.
  • two commercial organisations (X company and Y company) with respective DNS domains of "xco.com. " and "yco.com.
  • the telephone number "441447456987” which is a UK number (country code “44") with a four digit area code ("1447”) and six digit local number (“456987”) could be divided to form a domain name of 456987.1447.44 (note mat the reversal of label order occassioned by the fact that me DNS labels are arranged least significant first). If die telname space is a subdomain of die DNS widi a placement as illustrated in Figure 12B, the fully qualified domain name derived from die telephone number would be: 456987.1447.44.tel.itu.int.
  • DNS and BIND Paul Albitz and Criket Liu, O'Reilly & Associates, 1992 which describes how to set up a DNS server using the Unix BIND implementation.
  • the type of die RR records is, for example, text.
  • diat DNS labels should not in tiieory start with a digit. If dus convention is retained, dien it is of course a trivial exercise when parsing a telephone number to insert a standard character as the first character of each label. Thus, a 4 digit label of 2826 would become “t2826" where "t" is used as die standard starting character.
  • Duris system implementation has been in terms of translating a telephone number into an URI where the telephone number forms the full UI of a resource code and die Duris system returns a fujl URI. It will be appreciated diat the described Duris implementation can be readily adapted to accommodate die various modification discussed above regarding me form of the UI and what parts of die URI need to be looked up.
  • die service resource or resources associated widi a particular PSTN user (individual or organisation, whether a calling or called party) can be placed on a server 51 over die Internet from a user te ⁇ ninal 53 in one or more WWW pages.
  • the service resource is a service data item such as a telephone number (for example, an alternative number to be tried if die user's telephone corresponding to the number dialled by a calling party is busy).
  • This diversion number could be made die sole service resource of a phone page of the user.
  • the phone page URI could be a URL widi scheme set to HTTP in which case die GET mediod could be used to retrieve the diversion number.
  • die GET mediod could be used to retrieve the diversion number.
  • the diversion number is to be visually presented at a user terminal 53, dien it may be desirable to accompany the number with explanatory material (this will often not be necessary as the diversion number can be arranged to be returned into an existing displayed page diat already provides context information).
  • explanatory material an entity only wishing to make functional use of die phone page, could be arranged to retrieve the phone page and dien extract die diversion number (this would, of course, require a standard way of identifying die information to be extracted from die phone page).
  • An alternative and preferred arrangement for providing for both viewing and functional access to a resource requiring explanatory material for viewing is to use an object- oriented approach to resource design.
  • die resource object would have two different access metiiods associated widi it, one for purely functional use of the resource and the other enabling viewing of associated explanatory material. It would then be up to the accessing entity to access the resource object using the appropriate object method.
  • Yet another arrangement for providing for both viewing and functional use of the diversion number would be to provide separate resources appropriately configured for each use, each resource having its own resource code (generally, both such resources would be placed on the same phone page and in this case the UI part of each resource code would be the same).
  • Retrieval of a phone page for use by a human user will generally not be as time critical as retrieval for operational use by a PSTN.
  • the scheme specif i ed in the URL of a service resource could be HTTP
  • service resource examples include service logic for execution in place (at the server) with the result of this execution being returned to the entity accessing the resource; service logic downloadable from the server to the accessing entity for execution at that entity; and a logging resource for logging information passed to it by the accessing entity (or simply for logging the fac t t hat is has been accessed ) . It will be appreciated that the logging resource is really just a particular case of service logic executable in place.
  • a service resource constituted by execute-in-place service logic can be arranged to implement time-of-day routing, the result of executing the service logic being the telephone number to which a call should be routed taking account of the time of day at the called party's location.
  • An example of a service resource cons t ituted by downloadable service logic is service logic for controlling calling-party option interrogation using the facilities provided by an IP. As regards the logging resource, this can be used for recording the number of calls placed to a particular number.
  • each resource has its own phone page and die resource is present only in its unembellished functional form
  • the HTTP scheme can be employed for access using the GET method for both the downloadable service logic and the execution-in- place service logic, and me POST method for the logging resource. If it is desired to provide an explanatory material widi each service resource, dien any of the solutions discussed above in relation to data items, can be used.
  • each such resource can be placed on a respective phone page with its own URI.
  • die preferred approach is to place all such service resources on the same page and use the RRI part of the corresponding resource codes to enable access to die appropriate resource.
  • the accessed resource is then treated according to its form (executed if execute-in-place service logic, returned if downloadable service data or logic).
  • the diversion-number resource code might have an RRI of " 1 " whilst the time-of day resource code might have an RRI value of "2".
  • a service resource will often be of a complex type, combining service data and/or ⁇ ownloadable service l ⁇ £ and'or execute in place service logic.
  • a particularly powerful combination is die cc ination of the two types of service logic where the downloadable service logic is ..esigned to interact with execute-in-place service logic; using this arrangement, the user can be presented with complex client-server type applications.
  • Example Usage of Service Resource Figure 13 illustrates die operation of a service making use of a resource on a server 51.
  • This service is equivalent to a "personal number" service by which a user can be accessed tiirough a single, unchanging number even when moving between telephones having different real numbers.
  • die user requiring this service (user B in the current example) is allotted a unique personal number (here referred to as die "Webtel" number of B) from a set of numbers all of which have the same leading number string to enable an SSP to readily identify a dialled number as a Webtel number.
  • B has a service resource 49 on a dedicated phone page on HTTP server 51, diis phone page being located at a URL here identified as "URL (B phone page)" .
  • B's phone page when accessed returns die current roaming number (" B-telNb") where B can be reached.
  • B-telNb die current roaming number
  • B's phone page is just a single number that can be modified by B (for example, from a terminal 53) as B moves to a different phone. More likely is that B's phone page is an execute-in-place service logic providing time of day routing.
  • association between B's Webtel number and die URL of B's phone page is stored in an association table accessible to SCP 43.
  • die telephone 40 being used by A passes a call set up request to SSP 41 (note diat in Figure 13 the bearer paths tiirough die telephony network are shown by die diicker lines 60, e odier heavy lines indicating signalling flows).
  • SSP 41 detects die dialled number as a Webtel number and sends a service request to SCP 43 together widi B's Webtel number.
  • SCP 43 on receiving this service request initiates a service logic program for controlling translation of B's Webtel number into a current roaming number for B; in fact, in the present case, this program simply requests the resource access block 46 to access the service resource identified by B's Webtel number, (that is, B's phone page 49) and return die result of this access.
  • block 46 first translates B's Webtel number into the URL of B's phone page and dien uses diis URL to access B's phone page over the Internet (for example, using die 'phone' scheme already referred to with a method corresponding to die HTTP GET mediod). This results in B's current roaming number B-telNb being passed back to block 46 and in due course diis number is returned to die SSP 41 which dien initiates completion of call set up to die telephone 40 corresponding to B-telNb.
  • a service request may be triggered by a variety of triggers including calling-party number, called-party number, or some other user input, such triggers being possibly qualified by call setup progress (for example, called-party number qualified by a busy status or by ringing for more than a certain time).
  • a logging resource could be provided at a different URL for each SCP, it being a simple matter to collect and collate voting from all mese logging resources over the Internet. ⁇ f an SCP widi Internet access is provided at every SSP, then die risk of congestion : greatly reduced.
  • a user's phone page may hold multiple service resources in which case the access request from the accessing SCP needs to contain an appropriate RRI identifying the required resource.
  • a lookup table may need to be provided in the SCP to ensure diat a service request is appropriately handled; such a lookup table can conveniently be combined with me customer record database.
  • a user such as user B
  • This is possible if die Webtel-to-URI databases are available to all operators. Thus multiple operators could be set to access B's phone page or pages.
  • B can obviously chose not to use diat operator (at least where diat operator provides a long haul carrier service subject to user selection). The possibility therefore arises that service provision will cease to command a premium from operators, but that the provision of phone-page utilisation by an operator will become a necessary basic feature of PSTN operation.
  • the service resource must be placed on a server 51 and, secondly, die URI of die service resource must be notified to die PSTN operator along wid die trigger conditions (number plus any other condition such as point in call) calling for access to the resource; if multiple resources are provided at die same URI, then die RRI values needed to retrieve the appropriate resource for a particular trigger condition, must also be notified.
  • This notification process will be referred to hereinafter as 'registering' the service resource with die PSTN operator; registration is, of course, necessary to enable the association tables used by SCP 43 to be set up and for trigger conditions to be set in SSPs 43.
  • die process of placing a service resource on a server 51 how this is carried out will depend on the attitude of die PSTN operator to the possible effects of such service resources on operation of the PSTN.
  • die service resource simply returns a data item to an accessing entity
  • dien an operator may not be too concerned about possible errors (accidental or deliberate) in implementing die service resource.
  • die operator will probably be much more concerned about die proper operation of any service logic that may be returned by a resource; indeed, an operator may not permit such a service resource.
  • dien how a resource is placed on a server 51 will largely depend on die nature of the server concerned. For example, if a user has a computer with network access to die Internet and diis computer is used as server 51, dien die user can simply load a desired resource onto the server as a WWW phone page for external access. A similar situation arises if the server is an organisation server to which the server has access over an internal LAN. In both these latter cases, loading die resource as a WWW phone page does not itself require Internet access.
  • the server 51 is one run by an external Internet service provider, dien a user can arrange to download die required service resource into die user's allocated Web site space on die server; diis may or may not involve Internet access.
  • e PSTN operator provides a special server for user phone pages containing service resources.
  • placing a service resource on a server will generally involve clearing one or more levels of password protection.
  • die origin of die service resource loaded by a user onto server 51 diis may be generated by the user or, particularly where die resource includes service logic, may be provided by a third party (including die PSTN operator).
  • the PSTN operator wishes to have control over die service resources 49 to avoid any adverse effects on operation of the PSTN, two approaches are possible. Firstly, die operator could require diat every resource (or, possibly, a particular subset) had to be subject to a verification process before use, appropriate measures then being taken to avoid subsequent alteration of die resource by the user (except, possibly, for particular data items); in this respect, die operator could require that die resource be placed on a server under the operator's control and to which die user had no write access (except possibly for altering particular data items, as indicated above).
  • a second, more attractive, approach to minimising adverse effects by die service resources 49 is for the operator to provide standard service resources to which a user could add die user's own data (and possibly make limited functional selections in case where die resource included service logic); die customised resource would dien be loaded onto a server 51 controlled by die operator.
  • This process can be convenientiy implemented for a particular resource using an HTML "form" which a user could download over die WWW from the operator-controlled server.
  • HTML "form" which a user could download over die WWW from the operator-controlled server.
  • An advantage of this approach is diat registration of die service resource with the operator is simultaneaously effected. (It may be noted diat if registration needs to be done as a separate act from having a service resource loaded on a server, dien using an HTML form is a very convenient way to implement me registration process).
  • resource update will generally involve communication over die Internet.
  • Web User Interaction Consideration will next be given to odier possible uses of the service resources held in phone pages on me servers 51. For example, if user B's phone page contains a diversion number, then provided diis phone page is read-accessible over die Internet from user A's terminal 53, user A can use a graphical Web browser running on terminal 53 to view B's phone page and discover B's diversion number. As earlier discussed, die diversion number may be passed to user A for display in an existing visual context giving meaning to the number, or may be passed to user A widi accompanying explanatory text.
  • a more useful example is a current roaming number service for user B.
  • B's phone page 49 on server 51 (see Figure 14) is operative when accessed to return a current roaming number where B can be reached.
  • user B has a Web site wid several Web pages written in HTML and each page contains a graphical 'phone' button which when activated uses die GET mediod to access B's phone page by its URL.
  • user A whilst browsing (arrow 66) B's Web site over me WWW from user A's terminal 53, decides diat he would like to call user B to discuss some item of interest, user A simply activates the phone button 65 on die currently viewed page of B. This causes B's phone page to be accessed using the HTTP request "GET URL (B Phone Page)" - see arrow 67.
  • B's current number to be called is dien determined and passed to user A's terminal 53 (see arrow 68) where it is displayed.
  • An explanatory text concerning the number will generally also be displayed; for example die text "Please call me at the following number: " could be displayed, diis text being provided eitiier by die HTML script associated with die phone button, or from the phone page when re rning the current number.
  • die text "Please call me at the following number: " could be displayed, diis text being provided eitiier by die HTML script associated with die phone button, or from the phone page when re rning the current number.
  • it would probably be more helpful to provide user A not only widi die current number for reaching user B, but also with all numbers where B could be reached together widi die times when B was most likely to be at each number. Since this extra information is likely to be subject to frequent change, die only sensible way to provide the information is from the phone page.
  • B's phone page not only provides the current number for reaching B, but
  • B's phone page might include downloadable service logic for execution at user A's terminal. This is useful where choices are to be presented to a user, each choice producing a follow-up action such as fetching a further phone page.
  • the first-accessed phone page may be a family phone page giving die general telephone number for a family but also giving me user die possibility of selecting further phone information on each family member, such as a time-of-day dependent number; in diis case, each family member has their own follow-up phone page.
  • One way of overcoming diis problem would be to have user A's terminal 53, after obtaining die number to call from B's phone page, automatically suspend its Internet session by storing any required state information (for example, current WWW URL being accessed) and dien terminate its SLIP/PPP connection to thereby free up the telephone line.
  • A can men telephone B.
  • A can resume the suspended Internet session, using the stored state information to return to the point where A left off to call B.
  • An alternative approach is to operate a suitable multiplexing modulation scheme on die telephone line to A allowing voice and data to be simultaneously carried. A number of such schemes already exist.
  • the PSTN would dien need to separate die combined data and voice streams coming from A at some point and pass each to its appropriate destination (die Internet data being forwarded to die ISP providing the SLIP/PPP connection for user A and die voice stream being passed to B); of course, data and voice traffic in the reverse direction would also need combining at some point for sending over the last leg to A's te ⁇ ninal.
  • Ratiier than A manually dialling B using a standard telephone, anotiier possibility is tiiat user A's terminal is provided widi functionality enabling A to make a call over die PSTN from his terminal; diis functionality generally comprises a hardware interface 70 ( Figure 14) to a telephone line and phone driver software 71 for driving the interface 70 in response to input from application software such as die Web browser 73.
  • A could call up his phone software and enter die required number or, preferably, A need only "select" on screen the number returned from B's phone page and dien pass it into A's phone software.
  • B's phone page may return to A's terminal program code for automatically dialling B's number upon A confirming mat he wishes to proceed with call placement.
  • A's terminal is equiped widi a suitable modem and controlling software.
  • A could, instead, elect to send a fax or data to B drrough die PSTN eitiier to B's ordinary number or to one specified in B's phone page as die number to be used for such transmissions.
  • placing a call from A's terminal over the PSTN may be subject to the problem already discussed of conflict for use of the telephone line where tins is not an ISDN line and A gains Internet access via a SLIP/PPP connection.
  • die latter can be programmed to detect die return of a busy signal and then automatically look up B's diversion number and redial using diis number. This functionality can be included in service logic downloaded from B's phone page and run on A's terminal.
  • the service resource accessed on B's phone page upon B's telephone being busy may, of course, be more complex than just a diversion number.
  • user A may be presented with a range of options including, for example, B's fax or voice mailbox number, the selection of an option potentially initiating die ⁇ inning of appropriate accessing software.
  • Another possible option would be for A to leave B a call back message using a form downloaded from B's phone page upon this option being chosen; die completed form would be posted back to server 51 and logged for B to check in due course.
  • FIG 14 illustrates a situation where A, after being supplied widi B's current roaming number as in the Figure 14 case, calls B via a route that starts out over the Internet and then passes through a user network interface 80 into the PSTN.
  • Interface 80 is arranged to convert between ISDN-type telephone signalling on die PSTN and corresponding signalling indications carried across the Internet in IP packets; in addition, interface 80 transfers voice data from IP packets onto trunk 60 and vice versa.
  • Internet phone software 81 in A's terminal sends call initiation signalling over the Internet to interface 80, die address of which is already known to A's terminal.
  • the signalling is converted into ISDN- type signalling and passed to SSP 41.
  • Call set up dien proceeds in the normal way and return signalling is transferred back tiirough interface 80, over die Internet, to die software 81 in A's terminal.
  • This software passes call semp progress information to the WWW browser 73 for display to A.
  • A can talk to B through his telephone and A's voice input is first digitised in phone hardware interface 83 and then inserted into IP packets by software 81 to traverse the Internet to interface 80 (see arrow 84); voice traffic from B follows the reverse path.
  • IN services can be provided to this call by SCP in response to a service request from an SSP 41.
  • SCP 43 on receiving a service request will access B's appropriate phone page for call diversion and retrieve the diversion number. If SSP 41 is not set to initiate a service request on B's telephone being busy, die busy indication is returned to A's terminal where it can be handled in the manner already described widi reference to Figure 14.
  • interface 80 can be provided widi functionality similar to an SSP to set trigger conditions and generate a service request to SCP 43 on these conditions being satisfied.
  • Third-Partv Call Semp Gateway Figure 16 illustrates a further arrangement by which A can call B after receiving B's current roaming number.
  • a third-party call set-up gateway 90 is provided diat interfaces both with die Internet 50 and widi an SSP 41.
  • gateway 90 can be co-located with SCP 43 (though this is not essential).
  • Gateway 90 has the capability of commanding SSP 41 to set up a call between specified telephones.
  • a third-party call semp request is sent from A's terminal over the Internet to the gateway 90 (see arrow 91).
  • This semp request includes A's telephone number and B's current roaming number.
  • Gateway 90 first attempts to semp the call to A's telephone (which should generally succeed) and tiiereafter to set up the call to B's identified telephone. Once the call is semp, A and B communicate in standard manner across the PSTN. If B's phone had been busy, dien any of die previously described scenarios may ensue.
  • Gateway 90 can also be arranged to make service requests to SCP 43 upon predetermined trigger conditions being satisfied.
  • gateway 90 might be set to pick up the busy condition on B's telephone and initiate a service request to SCP 43 for a diversion number.
  • passing die busy indication back to A's terminal via gateway 90 is preferred because of die flexibility it gives A regarding further action.
  • Internet communication with the B's phone page and/or gateway 90 are both carried in Internet packets passed over die SLIP/PPP connection to/from A's terminal 53 but as logically distinct flows passed to separate applications running on terminal 53.
  • gateway 90 could equally have been made by service logic held in B's phone page and executed by server 51 (such an arrangement would, of course, require A's telephone number to be passed to B's phone-page service logic and this could be arranged to occur either automatically or through a form presented to user A at terminal A and dien posted back to server 51).
  • interface 80 of Figure 15 and die gateway 90 of Figure 16 provide examples of service requests being passed to die service control subsystem by entities other than SSPs 41.
  • a WWW/PSTN implementation does not necessarily rely either on transferring call charges from the calling to called party or on die use of a special "800" number, two characteristics of standard "Freephone” schemes.
  • the WWW/PSTN implementations do, however, possess the more general characteristic of placing an enquiring party and die party to whom the enquiry is directed, in telephone contact at die expense of die latter party.
  • a user D such as a large department store has a website on a server 51 ; for the sake of simplicity, it will be assumed diat the server is under d e control of user D who has direct computer access to the server over line 125.
  • D's Website may, for example, contain many catalogue-like Web pages illustrating goods offered for sale by D.
  • D has a freephone page 124 for handling enquiries placed on a freephone basis; die URL of diis page is associated with a "freephone" graphical button 122 placed on each of die Website catalogue pages.
  • the enquiry control system is connected to die server 51 via line 125, externally of the Internet; however, it would also be possible to have server 51 communicate with the enquiry control system through the Internet and, indeed, diis may be die most practical arrangement where D's Website is on an ISP server rather tiian on a server controlled by D.
  • the code run in A's terminal upon activation of the freephone graphical button 122 could be arranged to directly forward die enquiry request to the enquiry control system over the Internet rather than passing it back through the server 51.
  • the enquiry control system 126 manages enquiries passed to it to ensure diat tiiey are dealt widi in an ordered manner.
  • the system 126 on receiving a new enquiry preferably estimates approximately how long it will be before the enquiry is dealt widi, this estimation being based on die number of currently queued enquiries and die average time taken to handle an enquiry. This estimation of waiting time is passed back via server 51 to user A in the response to the POST request message.
  • the enquiry control system 126 looks after the distribution of enquiries to a number of agents each of which is equipped widi a telephone 40 and a display 129.
  • A's enquiry will be dealt with as soon as it reaches die head of the queue 127 and tiiere is an agent detected as available to handle die enquiry (thus, for example, the system may be arranged to detect when an agent's telephone goes on hook).
  • a distribution and semp control unit 128 takes A's enquiry and displays A's name and telephone number on die display 129 of die available agent (for clarity, herein referenced as agent D'); if user D keeps a database on D's past customers or credit rating data, dien unit 128 will also look for and display any such further information known about A.
  • unit 128 makes a tiiird-party call semp request (arrow 130) over die Internet to gateway 90 asking for a call to be set up between the telephone of die available agent D' and die telephone of user A, botii telephones being identified by dieir respective numbers. If both D' and A pick up the call, the enquiry then proceeds, die cost of the call being paid for by D as it is D that originated the call over die PSTN. If, for whatever reason, die call remains incomplete (for example, unanswered by A) for a predetermined timeout period, dien unit 128 can be arranged to automatically pass on to the next enquiry at the head of the queue 127.
  • the lattter could send a response to SCP 43 asking it to play an announcement such as "Your freephone enquiry has been registered; please hang up and you will be contacted shortly". This announcement could be played to A by an IP in standard manner. A would dien hang up and be ready to receive a call from D.
  • a significant advantage of die above freephone schemes using WWW is that user D is not running up charges for use of the PSTN during periods when an enquiry is enqueued, waiting to be handled.
  • the SCP 43 may access die HTTP servers 51 through a distributed processing environment, DPE 98, at least logically separate from the Internet.
  • DPE 98 distributed processing environment
  • the servers 51 are controlled by PSTN operators and are thus restricted in number.
  • a dialled personal number triggers a lookup in the DNS-type system with all or part of the personal number being first parsed and then applied to the DNS type system to return a current number for call routing.
  • All dialled numbers could be treated as personal numbers or simply a subset of such numbers, this subset comprising numbers that are readily identifiable as personal numbers by, for example, local lookup at an SSP or the presence of a predetermined leading digit string.
  • the general concept of parsing a telephone number (or similar number) in whole or in part to form a domain name for resolution in a DNS-type distributed database system can be used for the retrieval of other items of information besides URIs and service resource items.
  • the servers 51 have held service resource items concerned primarily with call semp control. It may be noted that in a somewhat different application, Internet servers could be arranged to hold data that could be accessed from the telephone system in response to a user-initiated telephone request and returned to that telephone user. Such a service would be provided, for example, in response to an SSP triggering a service request upon a particular telephone number being input, the service request prompting an SCP to cause an intelligent peripheral to access a particular Internet server (not necessarily an HTTP server) and retrieve the required data for return to the calling party.
  • the intelligent peripheral may include a text-to- voice converter for replaying die data vocally to die user.
  • a telephone user G may subscribe to a service by which calls passed tiirough to G's telephone are to be separated by a minimum of X minutes, X being user settable.
  • G has a phone page on a server 51 that includes a "busy" stams indication.
  • G's local SSP Upon termination of a successful call to G, G's local SSP triggers the sending of a message by die associated SCP over the Internet to G's phone page. This message causes G's busy indication to be set to indicate that G is busy; die message also starts a timer which times out after a period X and causes the busy stams indication to be reset.
  • a call attempt to G will either be rejected at G's SSP because G's line is genuinely busy or will trigger die SSP to enquire via die SCP whether G's phone-page busy stams indication is set. If the busy stams indication is set (which it will be during the period X following termination of a successful call) die call attempt is rejected whereas if die busy stams indication is in its reset condition, the call attempt is allowed to proceed.
  • the busy stams indication mechanism By placing the busy stams indication mechanism on G's phone page, it is possible to arrange for G to be able to easily change the value of X. More General Variants.
  • the service control subsystem of the PSTN has been embodied as an SCP in die foregoing examples, it will be appreciated d i at d i e functionality of the service control subsystem could be provided as part of an SSP or in an associated adjunct.
  • the triggering of service requests can be effected by equipment od i er than SSPs, for example by intercept boxes inserted in the SS7 signalling links.
  • d i at the term "Internet” is to be understood to include not only d i e current specif i cation of die TCP/IP protocols used for the Internet and d i e current addressing scheme, but also evolutions of tiiese features such as may be needed to deal with isochronous media.
  • references to the WWW and the HTTP protocol should equally be understood to encompass tiieir evolved descendants.
  • the present invention can also be applied to telephone systems other than just PSTNs, for example to PLMNs and other mobile networks, and to private systems using PABXs.
  • a LAN or campus- wide computer network serving generally d i e same in t ernal users as the PABX, will take the role of the In t ernet in the described embodiments.
  • the present invention has application where any switched telecommunication system (for example, a broadband ATM system) requires service control and a compu t er network can be used for die delivery of service resources t o d i e service con t rol subsystem of the telecommunication system.
  • switched telecommunication system for example, a broadband ATM system
  • compu t er network can be used for die delivery of service resources t o d i e service con t rol subsystem of the telecommunication 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)
  • Mobile Radio Communication Systems (AREA)
  • Application Of Or Painting With Fluid Materials (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Telephone Function (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

Un procédé d'accès à une entité cible sur un réseau de télécommunications utilise un système de base de données répartie similaire au SND d'Internet, le SND pouvant lui-même servir de base de données répartie requise. La base de données répartie garde en mémoire des enregistrements qui sont individuellement associés à un nom de domaine correspondant et des données de communication de maintien utilisés pour accéder à une entité cible. Chacun de ces noms de domaines est relié à une suite de numéros respective d'où il peut être extrait au moyen d'un procédé consistant à analyser au moins une partie substantielle de la suite de numéros dans au moins une partie dudit nom de domaine. Lors de l'entrée d'une suite de numéros indiquant une entité cible, le nom du domaine associé est formé au moyen de l'analyse du numéro (étape 120) puis le nom du domaine est ensuite utilisé pour récupérer les données de communications correspondantes dans le système de base de données répartie du type SND (étape 121). Les données sont ensuite utilisées pour accéder à l'entité cible. Dans une forme de réalisation le réseau de télécommunications est un réseau téléphonique et l'entité cible est un appelé; dans ce cas la suite de données comprend un numéro appelé et les données de communications récupérées sont un IRU (identificateur de ressource uniforme) indiquant la position sur Internet d'un numéro de téléphone valide pour le correspondant cible, le IRU étant utilisé lorsqu'il est retrouvé pour accéder au numéro de téléphone valide sur Internet (étape 123) afin d'établir une communication avec le correspondant cible.
EP96941768A 1996-02-20 1996-12-11 Procede d'acces a une entite cible sur un reseau de telecommunications Withdrawn EP0876733A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP02000568A EP1207704B1 (fr) 1996-02-20 1996-12-11 Determination basée sur DNS d'un numéro de téléphone pour contacter une destination
EP02000567A EP1207703B1 (fr) 1996-02-20 1996-12-11 Acces à des données de communication

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
GBGB9603590.2A GB9603590D0 (en) 1996-02-20 1996-02-20 Method of accessing a target entity over a communciations network
GB9603590 1996-02-20
PCT/GB1996/003054 WO1997031490A2 (fr) 1996-02-20 1996-12-11 Procede d'acces a une entite cible sur un reseau de telecommunications

Related Child Applications (2)

Application Number Title Priority Date Filing Date
EP02000568A Division EP1207704B1 (fr) 1996-02-20 1996-12-11 Determination basée sur DNS d'un numéro de téléphone pour contacter une destination
EP02000567A Division EP1207703B1 (fr) 1996-02-20 1996-12-11 Acces à des données de communication

Publications (1)

Publication Number Publication Date
EP0876733A1 true EP0876733A1 (fr) 1998-11-11

Family

ID=10789104

Family Applications (3)

Application Number Title Priority Date Filing Date
EP02000568A Expired - Lifetime EP1207704B1 (fr) 1996-02-20 1996-12-11 Determination basée sur DNS d'un numéro de téléphone pour contacter une destination
EP02000567A Expired - Lifetime EP1207703B1 (fr) 1996-02-20 1996-12-11 Acces à des données de communication
EP96941768A Withdrawn EP0876733A1 (fr) 1996-02-20 1996-12-11 Procede d'acces a une entite cible sur un reseau de telecommunications

Family Applications Before (2)

Application Number Title Priority Date Filing Date
EP02000568A Expired - Lifetime EP1207704B1 (fr) 1996-02-20 1996-12-11 Determination basée sur DNS d'un numéro de téléphone pour contacter une destination
EP02000567A Expired - Lifetime EP1207703B1 (fr) 1996-02-20 1996-12-11 Acces à des données de communication

Country Status (10)

Country Link
EP (3) EP1207704B1 (fr)
JP (2) JP4159603B2 (fr)
CN (1) CN1209249A (fr)
AU (1) AU719651C (fr)
CA (1) CA2239495A1 (fr)
DE (2) DE69632495T2 (fr)
GB (1) GB9603590D0 (fr)
NO (1) NO325606B1 (fr)
NZ (1) NZ323991A (fr)
WO (1) WO1997031490A2 (fr)

Families Citing this family (43)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3084681B2 (ja) * 1996-12-06 2000-09-04 財団法人流通システム開発センタ− 統合情報通信システム
US5974453A (en) * 1997-10-08 1999-10-26 Intel Corporation Method and apparatus for translating a static identifier including a telephone number into a dynamically assigned network address
DE19747583B4 (de) * 1997-10-28 2006-04-20 Telefonaktiebolaget Lm Ericsson (Publ) Kommunikationssystem und Verfahren
WO1999028979A2 (fr) * 1997-12-02 1999-06-10 Alcatel Usa Sourcing, L.P. Systeme de telephone numerique
WO1999029083A1 (fr) * 1997-12-02 1999-06-10 Alcatel Usa Sourcing, L.P. Procede et appareil pour noms de domaines dynamiques
GB2338875B (en) * 1997-12-05 2000-08-30 Distrib Syst Res Inst Integrated information communication system
US6215784B1 (en) * 1997-12-24 2001-04-10 Nortel Networks Limited Method and system for voice call completion using information retrieved from an open application on a computing machine
IL125432A (en) 1998-01-30 2010-11-30 Easynet Access Inc Personalized internet interaction
IL123129A (en) 1998-01-30 2010-12-30 Aviv Refuah Www addressing
AU3502999A (en) * 1998-06-12 1999-12-23 Alcatel Programmable telecommunications interface
GB9815585D0 (en) * 1998-07-18 1998-09-16 Fitton Stuart J Computer network addressing system
WO2000059237A1 (fr) * 1999-03-26 2000-10-05 Nortel Networks Limited Noeud de commande avec réseau intelligent
US6963928B1 (en) 1999-05-27 2005-11-08 Bagley David T Systems and methods for communicating across various communication applications using single address strings
AR028995A1 (es) * 1999-05-27 2003-06-04 Internet Man Systems Sistema y metodo para comunicaciones a traves de al menos un medio de comunicacion, sistema y metodo para generar una direccion valida de internet para una aplicacion de comunicacion de internet, metodo para convertir una cadena de direccionamiento en un formato de direccion de internet predetermina
CN1244061C (zh) * 1999-07-09 2006-03-01 马克·J·哈里斯 在网络上通信的方法和设备
NL1012721C2 (nl) * 1999-07-28 2001-01-30 Benno Henricus Nicolaas Hijl Inrichting voor registratie, adressering, structurering en het vinden van entiteiten en gegevens, gebaseerd op identificatiecodes.
WO2001029001A2 (fr) * 1999-10-15 2001-04-26 Nametree, Inc. Recherche du nom de domaine
SE517354C2 (sv) * 1999-12-01 2002-05-28 Ericsson Telefon Ab L M System och ett förfarande för privat telekommunikationsnät
SE517319C2 (sv) * 1999-12-01 2002-05-28 Ericsson Telefon Ab L M System och anordning i privata telekommunikationssystem där IP-nät används för signalering rörande förfrågnings- och svarsmeddelanden
US8400946B2 (en) * 2000-01-19 2013-03-19 Sony Corporation System and method for sharing common location-related information between communication devices
US9781257B2 (en) 2000-01-19 2017-10-03 Sony Mobile Communications Ab Technique for obtaining caller-originated alert signals in IP-based communication sessions
US8548010B2 (en) 2000-01-19 2013-10-01 Sony Corporation Method and apparatus for event-based synchronization of information between communication devices
US6826403B1 (en) 2000-09-12 2004-11-30 Phonepages Of Sweden Ab Method and system for identifying a user
DE10053717B4 (de) * 2000-10-28 2004-05-19 Web.De Ag Verfahren und Vorrichtung zum Aufbau einer Telefonverbindung über eine Internet-Telefonieanwendung
US7027582B2 (en) * 2001-07-06 2006-04-11 Telefonaktiebolaget L M Ericsson (Publ) Method and apparatus for resolving an entity identifier into an internet address using a domain name system (DNS) server and an entity identifier portability database
US20030074461A1 (en) * 2001-10-09 2003-04-17 I-Dns.Net International Pte. Ltd. Method of mapping names or identifiers to telecommunications network resource locations
US11341497B2 (en) * 2001-10-24 2022-05-24 Oleg Serebrennikov Method for performing transactional communication using a universal transaction account identifier assigned to a customer
WO2003060712A2 (fr) * 2002-01-15 2003-07-24 Idetic, Inc. Procede et systeme permettant d'acceder a des ressources partagees au moyen de bases d'informations de gestion configurables
US7161933B2 (en) * 2002-09-24 2007-01-09 Intel Corporation Optimistic caching for address translations
FI20030797A0 (fi) * 2003-05-27 2003-05-27 Nokia Corp Tietokannan suorituskyvyn parantaminen nimipalvelinjärjestelmässä
US7454569B2 (en) * 2003-06-25 2008-11-18 Commvault Systems, Inc. Hierarchical system and method for performing storage operations in a computer network
WO2005069581A1 (fr) * 2003-12-19 2005-07-28 France Telecom Procede et dispositif d'emission de requetes vers un serveur de noms de domaine depuis une machine requerante
CN100359874C (zh) * 2004-01-12 2008-01-02 华为技术有限公司 接收方所在的多媒体业务中心获取私网地址的方法
CN1314239C (zh) * 2004-03-31 2007-05-02 中国科学院计算技术研究所 一种移动自组织网络中域名系统的实现方法
CN1878164A (zh) * 2005-06-08 2006-12-13 华为技术有限公司 E.164号码域名存储和查询方法
US20070091878A1 (en) * 2005-09-30 2007-04-26 Marian Croak Method and apparatus for providing endpoint and access independent virtual numbers
WO2007132108A2 (fr) * 2006-05-15 2007-11-22 France Telecom Procede de routage pour numeros non standard dans un mecanisme de routage pour numeros standard
US8879545B2 (en) 2007-12-31 2014-11-04 At&T Intelletual Property I, L.P. Methods and apparatus to route a communication session directly to a voicemail mailbox
CN102017589B (zh) * 2008-02-22 2014-06-11 塞奇康奈科斯有限公司 在pstn上的个人数据端口以及具有虚拟房间和对象的在线家庭
JP5753999B2 (ja) 2013-09-12 2015-07-22 メタフロンティア合同会社 端末装置、データ処理プログラム、及びデータ管理システム
CN103905581A (zh) * 2014-02-26 2014-07-02 曾宪钊 基于行为差异性的dns高速解析方案和配套的抗流量类攻击安全方案
US10673681B2 (en) * 2017-03-15 2020-06-02 Charles Lap San Chan System and method for enabling cross-domain communication over network
CN109787907A (zh) * 2017-11-14 2019-05-21 北京星河星云信息技术有限公司 一种云智能dns调度系统及其用户接入和域名解析方法

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2173304C (fr) * 1995-04-21 2003-04-29 Anthony J. Dezonno Methode et systeme pour etablir des communications vocales via un reseau informatique

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO9731490A3 *

Also Published As

Publication number Publication date
AU719651C (en) 2007-09-06
WO1997031490A2 (fr) 1997-08-28
EP1207703A2 (fr) 2002-05-22
GB9603590D0 (en) 1996-04-17
WO1997031490A3 (fr) 1997-11-13
EP1207704B1 (fr) 2004-05-12
CN1209249A (zh) 1999-02-24
DE69632495T2 (de) 2005-05-12
NO982513D0 (no) 1998-06-02
NZ323991A (en) 1999-06-29
AU1104597A (en) 1997-09-10
JP2004194330A (ja) 2004-07-08
JP3867079B2 (ja) 2007-01-10
EP1207704A3 (fr) 2002-09-18
NO982513L (no) 1998-08-05
NO325606B1 (no) 2008-06-23
EP1207703B1 (fr) 2004-08-18
DE69633205T2 (de) 2005-07-14
EP1207704A2 (fr) 2002-05-22
DE69633205D1 (de) 2004-09-23
AU719651B2 (en) 2000-05-11
JP2000504917A (ja) 2000-04-18
DE69632495D1 (de) 2004-06-17
JP4159603B2 (ja) 2008-10-01
EP1207703A3 (fr) 2002-09-18
CA2239495A1 (fr) 1997-08-28

Similar Documents

Publication Publication Date Title
AU719651C (en) Method of accessing a target entity over a communications network
US8938062B2 (en) Method for accessing service resource items that are for use in a telecommunications system
US6131095A (en) Method of accessing a target entity over a communications network
EP0867091B1 (fr) Passerelle d'etablissement de communication pour systeme de telecommunications
EP0867092B1 (fr) Procede pour fournir des services de telecommunications
EP0867093B1 (fr) Procede pour acceder a des elements de ressources de services prevus pour etre utilises dans un systeme de telecommunication

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: 19980522

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE CH DE DK ES FI FR GB IT LI NL SE

17Q First examination report despatched

Effective date: 19991118

GRAG Despatch of communication of intention to grant

Free format text: ORIGINAL CODE: EPIDOS AGRA

GRAG Despatch of communication of intention to grant

Free format text: ORIGINAL CODE: EPIDOS AGRA

GRAH Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOS IGRA

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: HEWLETT-PACKARD COMPANY, A DELAWARE CORPORATION

GRAH Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOS IGRA

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

Free format text: STATUS: THE APPLICATION HAS BEEN WITHDRAWN

18W Application withdrawn

Withdrawal date: 20020617