MXPA98004677A - Method for providing telecommunication services - Google Patents

Method for providing telecommunication services

Info

Publication number
MXPA98004677A
MXPA98004677A MXPA/A/1998/004677A MX9804677A MXPA98004677A MX PA98004677 A MXPA98004677 A MX PA98004677A MX 9804677 A MX9804677 A MX 9804677A MX PA98004677 A MXPA98004677 A MX PA98004677A
Authority
MX
Mexico
Prior art keywords
service
server
telephone
resource
access
Prior art date
Application number
MXPA/A/1998/004677A
Other languages
Spanish (es)
Inventor
Low Colin
Bouthors Nicolas
Penkler David
Original Assignee
Bouthors Nicolas
Hewlettpackard Company
Low Colin
Penkler David
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Bouthors Nicolas, Hewlettpackard Company, Low Colin, Penkler David filed Critical Bouthors Nicolas
Publication of MXPA98004677A publication Critical patent/MXPA98004677A/en

Links

Abstract

Traditional intelligent network services (IN = Intelligent Network) in a PSTN, use data and service logic that are accessible for use only by the PSTN, although provision may be made for users to change certain service control parameters. The present system has the data and service logic placed on a server (51) accessible via Internet (50). This allows anyone to access useful telephone data such as time-of-day addressing or information of a user's deviation numbers. In this way, a calling party (A) can before placing a call on the PSTN, determine the best number to call when accessing the telephone page (49) of the called party called (D). This telephone page (49) will remain accessible to the PSTN for service provision. In a preferred embodiment, the data and service logic are maintained by the user (B) independently of the PSTN in a user selection server (51), in this case, the PSTN will also access the user's data and service logic about Internet (5

Description

METHOD FOR PROVIDING TELECOMMUNICATIONS SERVICES FIELD OF THE INVENTION The present invention relates to a method for providing Intelligent Network (IN) services in a switched telecommunications system. As used herein, the term "switched telecommunications system" means a system comprising a bearer network with switches for configuring a bearer channel through the network. The term "switched telecommunications system" shall be taken to include not only the existing public and private telephony systems (whether they use analog or ISDN-based telephones), but also broadband (ATM) and other carrier-based networks in switch, which are currently implemented or may arise in the future. For convenience, the term "switched telecommunications system" is sometimes abbreviated here to the telecommunications system. Reference to a "call" in the context of a switched telecommunications system, it will be understood that it means a communication through a bearer channel configured through the carrier network, while references to call configuration, maintenance and reinitialization, will have to be taken mean the processes of configuring, maintaining and reinitializing a bearer channel through the carrier network. Terms such as "call processing" and "call handling" shall be interpreted similarly. The term "communication system" when used herein, shall be understood to have a broader meaning than a switched telecommunications system, and is intended to include datagram-based communication systems, wherein each data packet is independently addressed to through a carrier network without following a predetermined bearer channel. BACKGROUND OF THE INVENTION The telecommunications companies that run Public Switched Telephone Networks (PSTNs) and Public Land Mobile Networks (PLMNs) are in the business of providing communication services and in doing so provide intelligence. inter-built increased in the form of "IN services" such as 800 number services and call forwarding. In contrast, the World Wide Web (WWW), which has seen explosive growth in recent times, is an example of an Internet-based global network that provides complex information services. These two worlds, that of the big communication service companies and that of the WWW information culture with pioneering, highly dynamic spirit, are restless companies, and each one plans to cover the domain previously occupied by the other; In this way, telephony services will be offered on the WWW and information services on the infrastructure of public communications. The present invention proposes technologies for a more synergistic relationship between these two worlds than currently foreseen and in order to place the present invention in context, first a revision of each of these two worlds will be given. Telephone Networks with IN Services The Basic PSTN. The basic service provided by a PSTN (Public Switched Telephone Network) is the interconnection of two telephones (that is, configuring a bearer channel between the telephones) according to a power supply of the telephone number of the called party in the telephone number. the calling party. Figure 1 is a simplified representation of a PSTN providing said service. In particular, equipment in customer facilities, (CPE = Customer Premises Equipment), 10 (such as standard analog telephones, although more recently ISDN terminals) are connected through an access network 11 to switching points (SPs = Switching Points) 12. The SPs 12 form nodes in an exchange network 13 constituted by interconnection trunks 14 and SPs that are controlled by control entities 15 in the SPs. The control performed by the control entities 15 is determined by signaling feeds received from the CPEs and other SPs, and involves call configuration, maintenance and release, to provide the desired bearer channel between the calling CPE and the called CPE. Conceptually, the PSTN can be considered as a carrier network and a control network (signaling), the function of the latter is to carry out call control through the carrier network, ie the configuration control, maintenance and reinitialization of channels carriers through the carrier network; In practice, carrier and signaling networks can use the same physical circuits and even the same logical channels. In this way, when the CPE is a traditional simple telephone, the control signaling between the CPE and its local SP is signaling in band, that is, the signaling is transported in the same channel that is used for voice; this signaling is interpreted and converted into SPs 12, in signaling between SPs, which uses a dedicated common channel signaling network 16 (currently implemented using the SS7 protocol suite). When the CPE is on an ISDN terminal, the signaling is transported on a separate channel directly from the CPE at an end-to-end. Modern SPs use the ISUP (SSDN User Part) protocol SS7 for signaling for inter-central call control 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 of the structuring of said numbers will now be given. Telephone numbers form an international hierarchical addressing scheme based on groups of decimal digits. The upper level of the hierarchy is managed by ITLT-T, which has assigned single-digit numeric codes in most geographical areas (eg "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 in zone 3 France is "33", and within zone 4 the United Kingdom is "44". The administration of the numbering plan within a country is delegated to a national body, such as the Telecommunications Office ("Oftel") in the United Kingdom. The following additional description is based on the UK numbering plan, but the scheme described will be recognized as having broad applicability.
In the United Kingdom, all national numbers are prefixed by a code from 01 to 09 (the prefix "0" is removed in international dialing). The codes currently assigned are "01" for Geographical Area Codes, "02" for Geographic Area Codes Additional, "04" for Mobile Services, "07" for Numbers Personal and "08" for Special Services (free phone, information). Subscriber phone numbers Normal physical line PSTN are assigned from the Geographic Area Codes, and currently only codes with prefix 01 are assigned. The geographical area codes are currently 3 or 4 digits (excluding the front "0") and there are currently 638 geographical areas each with its own code. A full national UK dialing number has two forms: 0 171 634 8700 area code local number (7 digits) 0 1447 456 987 area code local number (6 digits) The first case has prefix "0", a code of area of 3 digits and a local number of 7 digits, and in the second case it has prefix "0", a code of area of 4 digits, and a local number of 6 digits. Greater interpretation of the local number will be carried out within the area exchange, since even a 6-digit address space is too large for a single switch, and for a typical local area, several switches may be required to receive the required number of subscriber lines. This interpretation is opaque and is a matter of the area service provider. In the current PSTN, the geographically and inherently hierarchical interpretation of telephone numbers is reflected by the physical architecture of the network. A number of -jwisgléfono is structured in such a way that it makes it easy to direct a call through the network. In each step, the number prefix provides information regarding the current addressing step, and the suffix (probably in opaque form) provides information regarding the subsequent addressing steps; whenever a switch knows how to parse a prefix and carry out an addressing step, it does not require understanding the suffix content, which is left for subsequent addressing steps. For this reason, the fabric of international and national commutation is also organized hierarchically. Intelligent networks. Returning now to a consideration of the infrastructure of the current telephony network, in addition to basic call handling, an SP can also serve to provide what is called IN services (Intelligence Network); in this case, the SP is called a service switching point (SSP = service switching point). An SSP 25 is arranged to suspend call processing at defined call-points, when particular criteria are met, and to delegate the continuation of call processing to a service control subsystem providing service control function (SCF = service control function) either in the form of a service control point, SCP 17 (see Figure 2) or an Auxiliary 18. Auxiliary 18 is directly associated with an SSP 25 while SCP 17 and SSP 25 communicate with each other by an extended common channel signaling network (CCS) 16 which may include signal transfer points (STP) 19. The SCP 17 may be associated with more than one SSP 25. Both the SCP 17 and the Auxiliary 18 provide an environment of logical execution of service (SLEE = service logic execution environment) 20 in which cases of one or more logical service programs (SLP = service logic programs) 21 can execute. The SLEE 20 and the SLP 21 together provide service control functionality to provide services to the SSP 25. Service logic running in an SCP or Auxiliary will generally use subscriber information stored in a service data function (SDF = service data function) 22 that can be integral with the SCP / Auxiliary or partially or totally separated from there. The service data function (SDF) as the service control function (SCF) is part of the service control subsystem of the PSTN. It can be noted that some or all of the service control function can be built into the PSTN switches themselves. In addition to SCP 17 and Auxiliary 18, the network of Figure 2 includes an intelligent peripheral (IP) 23. The 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 an overview of the network and its services and performs functions such as network verification and control. In operation, when the SSP 25 receives a call, it examines internal trigger conditions and possibly user information (e.g., dialed digits) to evaluate whether the call requires a service that is provided by the service control subsystem.; Verification of trigger conditions can be carried out at several different points in the call processing. When the SSP 25 determines that a service requires messages, the service control subsystem (either SCP 17 or Aux. 18) requests the desired service and sends a logical representation of the call in terms of its connectivity and processing status. call. The service control subsystem then provides the requested service and this may involve either a single interaction between the SSP and the service control subsystem or an interaction session. A typical service is call forwarding, which is a call party service that gives expression to an end-user requirement as simple "If you call me at number X and dial ten times, try calling the number Y". In this case, it is the local SSP to the called end user that triggers its associated SCP (or Auxiliary) to provide this service; Of course, it will be appreciated that the SSP must be primed to know that the service will be provided for a marked X number. The model described above for providing IN services in a PSTN can also be downloaded into Public Land Mobile Networks (PLMNs) such as GSM and other mobile networks. The control signaling in the case of a mobile subscriber is more complex because in addition to all the usual signaling requirements, there is also a need to establish where a call will be directed to a mobile subscriber; however, this is not a very different problem from IN services of a number of called part IN services in the PSTN. In this way, in GSM, the service data function (SDF) is substantially located in a system called a Home Location Register (HLR) and the service control function in a system called a Visitor Location Record (VLR = Visitor Location Register), which is generally associated on a one-to-one basis with each SSP (which in GSM terminology is called a Mobile Switching Center) . Since the subscribers are mobile, the subscriber profile is transported from the HLR to any VLR that turns out to be functionally closer to the mobile subscriber, and hence the VLR operates the service (fixed) using the subscriber profile and interact with the SSP. The HLR and VLR in this way constitute a service control subsystem similar to an SCP or Auxiliary with its associated databases. Of course, it is also possible to provide IN services in private telephony systems, and in this case, the service control function and the service data function in general, are already integrated in a private automatic branch office (PABX = Prívate Automatic Branch Exchange) or provided by a local computer. The service control subsystem, while present, may not be physically different from the PABX in this way.
The general architectural structure previously described for providing IN services has both strengths and weaknesses. Its main strength is that it works and many services have been successfully deployed, such as 800 number services, credit card call, voice mail, and various call waiting and redirection services. However, despite years of normalization, services are still implemented one-on-a-time on proprietary platforms and do not scale well. The approach has been based on large fault-tolerant systems, which provide services for hundreds of thousands or even millions of subscribers and take years to deploy. In addition, since the networks used to support these services also constitute the basic telephony infrastructure, anything connected to these networks must be rigorously reviewed. Additionally, each country and operator tend to have local variations of the so-called norms that make it difficult to supply standard products and thus breaking the dynamics of competition. The World Wide Web In contrast to the deliberately slow progress of the telephony infrastructure, the WWW has grown explosively since its insertion in 1989 to become the primary electronic information distribution service "Switch Reduction for Multiple Lines of the Public Switched Telephony Network "(Switch Reduction For Multiple Lines of the Public Telephone Network) WO 93/25035 Bell Atlantic Network Services 9.12.93 This document describes how a client can use a PC to establish a data link to an ISCP using a modem in order to update service data. "Method and System for controlling the operation of a telephone exchange from a subscriber connection" (Method and system for controlling the operation of a telephone exchange from a superscriber connection) WO / 9423523 Nokia 13.10.94 This document describes how an SCP can be supplied with command macros in a subscriber connection. "Open Advanced Intelligent Network Interface Mediation for Public Switched Telephony Network" (Media ion of Open Advanced Intelligent Network Interface for Public Switched Telephone Network) U.S. Patent. No. 5,438,568 Bellsouth Corporation 1.8.95 A mediation SCP verifies all messages to and from third-party logical service programs running for example in a third-party SCP. "Clients in the Driver's Seat: Intelligent Network Control Point" (Custo ers in Dri er's Seat: Prívate Intelligent Network Control Point) M. Sevcik; R. Lueder (Siemens) 23.4.95 ISS Symposium This document describes a private SCP (PSCP) connected to an SCP network (NSCP) through a TCP / IP connection. The NSCP sends translated INAP messages directly to the PSCP. The PSCP is shown connected as a resource on a private LAN. "Distributed intelligence and data in public and private networks" (Distributed intelligence and data in public and prívate networks) R.P. Swale and D.R. Chesterton BT Technology Journal, 13 (1995) April No. 2 This document discusses first and third part CTI, the latter is called "private IN". A comparison is then made between private and public IN, noting that they are often complementary. Finally, possibilities for interconnection of private and public IN are discussed. The World Wide Web In contrast to the deliberately slow progress of the telephony infrastructure, the WWW has grown explosively since its insertion in 1989 to become the primary electronic information distribution service in terms of dispersion, availability and wealth of information content. Anyone can, for a modest distribution, become an information provider with a global audience in a highly interconnected information architecture. The WWW is a client-server application that runs on the Internet and uses a client-server protocol, which directs only the simplest exchanges between client and server. This protocol is the Hyper Text Transfer Protocol (HTTP) that is optimized for use over TCP / IP networks, such as the Internet.; The HTTP protocol can however also be used in networks that use different stacks of communication protocols. Since the availability of literature concerning WWW has seen the same kind of growth 15 as the WWW itself, detailed descriptions of WWW, HTTP and Internet are not given here. A profile description, however, will be given with attention directed to certain characteristics of relevance to the present invention. The WWW uses the Internet for interconnectivity. The Internet is a system that connects networks on a worldwide basis. The Internet is based on the TCP / IP protocol suite and provides connectivity to networks that also use TCP / IP. For an entity to have a presence on the Internet, it requires both access to a network connected to the Internet and an IP address. IP addresses are structured hierarchically. In general, an entity will be identified at the user level by a name that can be resolved in the corresponding IP address, by the Internet Domain Name System (DNS = Domain Name System). Because DNS or its adaptations are fundamental at least for certain embodiments of the invention described hereinafter, a description of the general form and operation of the DNS is given below. The Domain Name System - The DNS, is a distributed global database, and without its performance, resilience and scale adjustment, much of the Internet would not exist in its current form. The DNS, in response to a client request, is used to associate an Internet host domain name with one or more Registers (RR = Registers ion Records) of different types. The most common are an address register (A) (such as 15.144.8.69) and mail exchanger (MX) records (used to identify a domain host configured to accept e-mail for a domain). The RRs are distributed worldwide through DNS name servers, these servers cooperate to provide the domain name translation service; no simple DNS server contains more than a small part of the global database, but each server knows how to locate the DNS servers that are "closest" to the data that they are. For current purposes, the main characteristics of the DNS of interest are: The host name space is organized as a hierarchy structured as a tree in nodes, with each guest having a corresponding leaf node; each node has a label (except for the root node) and each label starts with an alphabetic character and is followed by a sequence of digits or alphabetic characters. The full name "fully qualified" of a guest in the string of node labels, each separated by a ".", from the leaf node corresponding to the root node of the hierarchy, the latter being represented by a "." in the name. In this way, a host "fred" from Hewlett-Packard Laboratories, in Bristol, England, will have a fully qualified domain name of "fred.hpl.hp.com." (Note that if a guest name does not have a terminal ".", it is interpreted with respect to the current node of the hierarchy for appointment). Each guest has one or more associated Registries (RRs). There is a plurality of DNS servers, each with responsibility for a sub-tree of the namespace. A DNS server will maintain RRs for all sub-tree parts - in the latter case it delegates responsibility for the rest of the sub-tree to one or more additional DNS servers. A DNS server knows the address of any server to which it has its delegated responsibility and also the address of the server that has been given responsibility for the subtree it manages. DNS servers in this way point to each other in a structure that reflects that of a named hierarchy. An application that wants to use DNS does so through an associated "solver" that is from the address of at least one DNS server. When a DNS server is asked by this solver for a RR from a specific host, return either to the requested RR or the address of a DNS server as close to the server that maintains the RR in terms of exceeding the naming hierarchy. In effect, it ascends in the hierarchy of the servers until a server is reached that also has the responsibility for the domain name to be resolved; subsequently, it is lowered in the DNS server hierarchy to the server that has the RR for the domain name to be resolved.
DNS uses a default message format (in fact it is the same for interrogation and response) and uses IP protocols. These characteristics of the DNS can be considered to define a "DNS type" system that always allows for minor variations such as tag syntax, as tags are combined (ordered, separated), message format details, evolutions of IP protocols, etc. . Due to the hierarchical appointed structure, it is - ^ possible delegate responsibility to administer domains (sub-trees) of the namespace recursively. In this way, top-level domains are administered by InterNic (these top-level domains include the familiar domains' com1, 'edu', 'org', 'int', 'net', 'thousand' as well as top-level country domains specified by standard two-letter codes such as 'us', 'uk', 'fr', etc.). At the next level, by way of example, Hewlett-Packard Company is responsible for all the names ending in 'hp.com1 and the British universities are collectively responsible for all the names ending in 'ac.uk'. I descend further, and again by way of example, the administration of the domain "hpl.hp.com" is the responsibility of Hewlett-Packard Laboratories and the administration of the sub-tree (domain) 'newcastle.ac.uk' is the responsibility of the University of Newcastle-upon-Tyne. Figure 3 illustrates the progress of an exemplary interrogation conducted 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 interrogation is presented to the DNS server responsible for the sub-tree "hpl.hp.com". This server does not keep the requested RR and thus responds with the DNS server address "hp.com"; This server is then interrogated and responds with the DNS server address' com ', which in turn responds with the DNS server address'. ' (root) The interrogation then proceeds iteratively until the branch 'uk', until the server 'newcastle.ac.uk' responds with the RR record for the name 'xy' in its sub-tree. This seems extremely inefficient, but DNS servers are designed to build a dynamic cache (high-speed buffer), and is initialized with the addresses of several root servers, so that in practice most iterative interrogations never They are carried out. In this case, the DNS server 'hpl.hp.com' will know the addresses of several root servers, and will probably have the addresses of the 'uk' and 'ac.uk' servers in its cache. The first interrogation to the server 'hpl.hp.com' will return the server address 'ac.uk'. The second interrogation to the server 'ac.uk' will return the address of the server 'newcastle.ac.uk' and the third interrogation will return the RR in question. Any future queries with a prefix 'newcastle.ac.uk' will go directly to the DNS server in Newcastle since that address will be retained in the DNS server cache "hpl.hp.com". In practice, names within a local sub-tree are resolved in a single interrogation, and names outside the local sub-tree are resolved in two or more interrogations. Instead of a solver responsible for carrying out the series of interrogation iterations required to resolve a domain name, the solver may specify its first interrogation to be recursive, in which case the receiving DNS server is responsible for resolving the interrogation (if can not directly return the requested RR, itself will issue a recursive interrogation to a "closer" DNS server, and so on). Also in practice it will be noted that each DNS server will be replicated, that is, it will be organized as a primary and one or more secondary servers. A primary DNS name server is initialized from a database that is maintained in a local system, while a secondary one is initialized when transferring information from a primary. A sub-tree will usually have a primary name server and anything up to ten secondary - the limitations tend to be the time required by the children to update their primary databases. The primary database is the master source of sub-tree information and is maintained by the domain DNS administrator. The secondaries are not simply secondary at rest, but each participates actively in the DNS with dependent servers that point to it instead of the corresponding primary. DNS implementations, such as BIND, are widely available as a standard part of most UNIX systems, and may claim to be among the most robust and widely distributed applications in existence. WWW operation. Now with reference to Figure 4 of the accompanying drawings, Internet access 30 can be by direct connection to a network that itself directly or indirectly connects to the Internet; this structure is represented by the terminal 31 of Figure 4 (this terminal can for example be a Unix workstation or a PC). Having an Internet connection in this way is known to have "access to the network".
Any entity that has access to the Internet network can act as a server on the Internet, provided it has sufficient associated functionality; in Figure 4, entity 32 with file storage 37 acts as a server. Many users of the WWW do not have access to the Internet, but instead access the Internet through an Internet Service Provider (ISP = Internet Service Provider) 33 that has access to the network. In this case, the user terminal 34 is generally "" - Will communicate with ISP 33 about the public telephony system using a modera and using either the serial line interface protocol (SLIP = Serial Line Interface Protocol) or Point-to-Point Protocol (PPP = Point-to-Point Protocol). These protocols allow Internet packages to travel through ordinary telephone lines. Internet access in this way is known as "IP dial-up" access. With this access method, the user terminal 34 is temporarily assigned an IP address during each user session; however, since this IP address may differ between sessions, it is not practical for entity 34 to act as a server. A fundamental piece of WWW is its ability to direct resources of particular information through a Uniform Resource Identifier (URI), which in general will already be a Uniform Resource Locator (URL = Uniform Resource Identifier) that identifies a resource by location, or a Uniform Resource Name (URN = Uniform Resource Yam) that can be resolved 5 in a URL. As an example, a complete or "absolute" URL will include the following elements: schema - this is the access scheme to be used to access the resource of interest; guest - the Internet host domain name or "" ^ SyO IP address; port - the host port for the connection (TCP); absolute trajectory - the absolute path (abs-path) of the resource in the host. 15 In fact, the "port" can be omitted, in which case port 80 is considered. Figure 5 of the accompanying drawings shows an example of a URL network for the Hewlett-Packard product welcome page. In this case, the elements 20 are: schema - http host - ww .hp. com port - omitted (port 80 is considered) absolute path - Products.html The HTTP protocol is based on a request / response paradigm. Again with reference to the Figure 4 of the drawings, given a particular URI that identifies a resource 30 to be accessed, a client establishes a connection with the server 31 corresponding to the element "guest" of the URI and send a request to the server. This application includes an application method, and "Application for URI "(which is generally 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, server 31 then accesses the resource 36 (which is kept here in storage 37) and responds, and this response may include an entity of a type identified by a type Multiple Purpose Internet Mail Extensions (MIME * = Multipurpose Internet Mail Extensions) also included in the answer. The two main application methods are: GST - This method results in retrieving any information (in the form of an entity) identified by Request-URI. It is important to note that if the URI Request refers to a data production process, it is the produced data that is returned as the entity in the response and not the source text of the process.
POST - This method is used to request that the destination server accept the entity circumscribed in the request as a new subordinate of the resource identified by the URI Request. The POST method can be used to annotate existing resources, by providing a message to a bulletin d, to provide data to a data management process (for example, data produced as a result of submitting a form) and to extend a database through a database. add operation. In summary, the GET method can be used to directly retrieve data, or trigger any process that will return an entity (which may already be data or simply an indication of the result of running the process). The POST method is used to record data and specifying this method is also effective to trigger a process on the server, to handle the data sent appropriately. The passing of information to a triggering process to run on a server used either the GET or POST method, is currently done according to an interface called the Common Gateway Interface (CGI = * Common Gateway Interface). The receiver process is often described in a program or macro language (scripting) although this is not essential. Typically, the activated or triggered server macro is used to interconnect as a database to service a query included in a GET request. Another use, already referred to, is to add data associated with a POSf request to a database. Other important factors in the success of WWW is the use of Hyper-Text Markup Language (HTML) to represent the constitution of documents transferred over the WWW, and the availability of powerful graphical Network visualizers, such as Netscape and Mosaic, to interpret these documents in a client terminal to present them to a user. Basically, HTML is used to identify each part of a document, such as a title, or a graphic, and then it depends on the viewer running in the client terminal to decide how to display each part of the document. However, HTML is more than this - it also allows a URI and a request method to be associated with any element of a document (such as a particular word or image) in such a way that when a user points and selects with the button In this element, the resource identified by the URI is accessed according to the specified protocol (scheme) and request method. This structure provides a hyperlink from one document to another. Using these hyperlinks, a user in a client terminal can jump effortlessly from a 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 an author can include a hyperlink to a document created by another, an extremely powerful document cross reference system results, without central bureaucratic control. Hyperlinks are not the only intelligence that can be built in an HTML document. Another powerful feature is the ability to fill in a "Form" document downloaded on the screen and then activate a graphic "entrust" button, in order to make the information supplied pass to a resource (such as a database) ) designed to collect such information. This is achieved by associating the POST request method with the "entrust" button together with the URI of the database resource; activating the "entrust" button results in supplying information that is sent to the identified resource where it is handled properly. Another powerful possibility is the association of program code (usually macros to be interpreted) with elements of particular documents, such as graphic buttons, this code is executed when the button is activated. This opens the possibility for users to download program code from a resource and then run the code. It will be appreciated by persons skilled in the art that HTML is only one of several currently available macro languages (scripting) that provide the previously established functionality and it can be expected that any serious network viewer will have interconstructed support for multiple macro languages. For example, Netscape 2.0 supports HTML 3.0, Java and LiveScrípt (the latter is the Macros Language owned by Netscape). The importance of the role of the graphic network visualizer itself should not be neglected. As well as the ability to support multiple macro languages, a network viewer should provide interstructured support for standard media types and the ability to load and execute programs on the client among other features. These viewers can be seen as operating systems for WWW interaction. WWW and the Telephony Network It is possible to provide a telephony and Internet service between connected terminals, by digitizing voice feed and sending it over the Internet in discrete packages for reassembly at the receiving terminal. This is an example of a communications service on the Internet. On the contrary, it is possible to point out a variety of information services that are provided over the telephony system, such as the Mínitel system widely available in France. However, these intrusions in the traditional territories of others, present no real threat either to the Internet or to the Public Telephony System. Of greater interest are areas of cooperative use of the Internet and the Telephone System. In fact, such an area has existed for some considerable time and has been previously established with reference to Figure 4, ie the use of a modem link over PSTN from a user computer 34 to an Internet service provider 33, in order to obtain IP dial-up access to the Internet. This cooperative use is of a very simple nature, ie the configuration of a carrier channel on the PSTN for subsequently generated Internet traffic; there is no real interaction between the Internet and the PSTN. Another known example of cooperative use of Internet and PSTN is a recently launched service by which an Internet user with a sound card in his terminal computer, can make a voice call to a standard telephone anywhere in the world. This is achieved by transferring digitized voice over the Internet to a service provider near the destination telephone; this service provider then connects to the local PSTN to access the desired telephone and transfers the traffic and voice received on the Internet to the local PSTN "The voice feed of the called telephone is handled in the reverse manner. Key to this service is the ability to identify the local service provider (in terms of telephony charge) to the destination telephone. This structure, while offering the prospect of competition for telecom operators for long distance calls, is again a simple chain of Internet and PSTN. However it can be noted that in this case it is necessary to provide at least a minimum of feedback to the calling party of the Internet in the development or progress of the call configured to the destination telephone on the local PSTN to that telephone; This feedback only needs to be in terms of what has been successful or the call. From the above, it can be seen that the current cooperative use of Internet and telephone systems is at a very simple level. An objective of the present invention is to overcome certain disadvantages of the present implementation of XN services in telephony and other telecommunications systems.
SUMMARY OF THE INVENTION According to one aspect of the present invention, there is provided a method for providing services to users of a switched telecommunications system, which includes a service control subsystem that communicates through a signaling system with switches of carrier channel, the service control subsystem provides an environment for execution of service logic, wherein logical service programs for configuration control of Carrier channels through the communication system, are run in response to reception by the service control subsystem of corresponding service requests, the method includes the steps of: (a) - providing at least one server connected to a network of computers with a plurality of service resource items, each associated with a respective predetermined code, the computer network is accessible to a substantial proportion of the users of the telecommunications system, but logically distinct from that system and the resource items of service related to the configuration control for bearer channels through the telecommunications system, (b) - when the service control subsystem receives a service request including a predetermined code, run the logical service program and access the server appropriate to use the service resource item Corresponding to the predetermined code included in the request, in the course of supply of service by the logical service program concerning the bearer channel configured through the telecommunications system; Y (c) - allow reading access from the user terminals on the computer network at least to the server as a minimum, thereby allowing service resource items held there to be accessed from the user terminals and from there use regarding configuring a carrier channel through the telecommunications system. Preferably, the service resource items are accessed by the service control subsystem on an independent path of the signaling system. In one mode, the computer network is a publicly accessible computer network, and the server is at least accessed from the user terminals and service control subsystem through the computer network. In another modality, the computer network is a publicly accessible network, and the server is at least part of the service control subsystem of the telecommunications system and is accessible to user terminals through the publicly accessible network. Preferably, the method includes the additional step of: (d) - accessing from a user terminal, over the computer network, a service resource item associated with a service or called intended party, and using the resource item to control the configuration of a communication through the telecommunications system to that part or service. A service resource item can be accessed from a user terminal in stage (d) before initiating communication through the telecommunications system, the result of using the service resource item is used to automatically initiate a communication through of the telecommunications system. Alternatively or additionally, after initiation of a communication through the telecommunications system, the return of a busy indication is operative to cause the service resource item accèsado of the user terminal in stage (d), is used in determining additional processing for call configuration. The service controller system may access the appropriate service resource item in step (b), either over the computer network or through a separate communication path. Selling, the service resource items are located on the computer network using corresponding XRIs, the service resource item is accessed from the user terminal in stage (d) using the corresponding URI. The service control subsystem can also access the service resource items over the computer network, using the corresponding URls, in which case stage (b) will include the sub-step of translating the default code included in a service request in the URI of the service resources item. Access to the resource sites from the user terminals can be done by starting with the corresponding predetermined codes, in which case step (d) will also include the sub-step of translating the related predetermined code into the URI of the associated service resource .m. This sub-step of translating the default code into the ÜRI of the associated service resource item can be done by one of the following methods: a direct mapping where the predetermined code corresponds substantially to the URI; - manipulate the predetermined code according to a predetermined function; look for a locally maintained association table that associates with the default codes and URIs; search in an association table the default codes and URIs, the association table is maintained at least in a database server connected to the computer network. A preferred method to perform the translation sub-step is to search in a distributed database system of the DNS type, where the URIs are kept in registers associated with respective names, here referred to as domain names, whereby the registers can recuperate; These domains are such that they can be derived, at least partially, by analyzing syntactically at least a substantial portion of the predetermined code, thereby allowing the name of the domain corresponding to a predetermined code to be derived given the latter, the subsequently derived domain name is used. to retrieve the URI of the required service resource item from the database system.
As an alternative to maintain the service resource items in servers for access using URIs, the server as a minimum can be part of a distributed database system of DNS type, with the service resource items that are kept in associated registers with the respective domain names by which records can be retrieved. In this case, the service resource item is accessed from the user terminal in step (d) using the corresponding domain name. Of course, the service control subsystem can also access the service resource items on the computer network, using the corresponding domain names and in this case, stage (b) preferably includes the sub-step of parsing at least a substantial portion of the predetermined code included in a service request at least in a portion of the domain name of the required service resource item. Again, access to the service resource item from the user terminal in step (d) may also be performed starting from the predetermined code which is then analyzed syntactically to form the appropriate domain name. The telecommunications system can be a telephony system, with each predetermined code being one of the following, ie the telephone number of the calling party, the telephone number of the called party and a numerical power supply by the party call. Regarding the nature of the service resources, these can be of the following type: - service logic intended to be executed by the corresponding server, when it is accessed with the result that this execution is returned to the access entity; downloadable service data that when accessed is intended to be downloaded to the access entity; downloadable service logic that when accessing is intended to be downloaded to the access entity for execution. Preferably, when the URIs are referred to below, these URIs are URLs and / or ÜRNs. In addition, the servers referred to preferably are HTTP servers, It will be understood that reference in the above to the computer network being logically different from the telecommunications system, will not be taken that implies that there is physically separation of the two - without a doubt, there will often be joint use of the same physical infrastructure. Furthermore, not only can the bearer channels configured in the telecommunications system share the same transmission medium as the computer network, but that bearer channel can act as a conduit for traffic through the computer network. Regarding the computer network that is generally accessible to users of the telecommunications system, this does not mean that all users of the telecommunications system have such access or can achieve such access; on the contrary, it will be understood that it represents that a significant portion of these users have or can obtain access to the computer network. The intention is to exclude networks of computers that are dedicated to the administration or verification of the carrier network and are effectively part of the telecommunications system itself. By way of example, in a preferred embodiment of the invention, the computer network generally accessible to users of the telecommunications system, but logically distinct from it, is the Internet and the telecommunications system is a public telephone system. BRIEF DESCRIPTION DB THE DRAWINGS Modalities of the present invention will now be described by way of non-limiting example, with reference to the accompanying diagrammatic drawings in which: Figure 1 is a simplified diagram of a standard PSTN; .Figure 2 is a simplified diagram of a known PSTN with IN service capability; is a diagram that illustrates the host domain name resolution by Internet DNS; is a diagram that illustrates how the World Wide Web works; is a diagram that illustrates the format of a standard URL; is a diagram of a first embodiment of the invention, wherein service resource items are maintained on HTTP servers accessible both by the service contprol subsystem of a PSTN as per Network users; is a diagram illustrating the processing of a service request by SCP of Figure 6; is a diagram that illustrates the format of a resource code used by SCP of Figure 6 when an item of service resources is accessed; is a diagram that illustrates the process of accessing a service resource in the case where the service code does not include an RRI part; 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 URI derivation of a service resource by parsing a power phone number; Figure 12A is a diagram illustrating a namespace (the "telname space") made up of domain names derived by parsing a predetermined set of telephone numbers .Figure 12B is a diagram illustrating the incorporation of the telname space without fragmentation in the DNS; Figure 12C is a diagram that illustrates the incorporation of the telname space in a fragmented way DNS; Figure 13 is a diagram illustrating the total operation of the mode of Figure 6 by providing an operation number service outside its service area, in response to a telephone number dialed on a standard telephone; Figure 14 is a diagram illustrating the total operation of the mode of Figure 6, when used by a user of the network in configure a call through a telephone interface integrated in the terminal of the user's network; FIG. 15 is a diagram illustrating the total operation of that mode of the invention wherein an interface is provided between the PSTN and the Internet for telephone traffic; Figure 16 is a diagram illustrating the total operation of a further embodiment of the invention, wherein a gateway is provided for call configuration between the Internet and PSTN; FIG. 17 is a diagram illustrating the total operation of a still further embodiment of the invention wherein a free telephone service is implemented for users of the Network; and Figure 18 is a diagram similar to Figure 6 illustrating providing a distributed processing environment for interconnecting elements of the service control subsystem of the PSTN. BEST MODE FOR CARRYING OUT THE INVENTION Figure 6 illustrates a structure for providing services in a PSTN, conventionally comprising an inter-core network 13 (including trunks and switches) at least some of which are SaPs 41 with associated IPs), an access network 11 connecting equipment of client facilities (illustrated here as telephones 40) to network 13, and a service control subsystem 42 that includes at least one SCP to provide services to SSPs 41 upon request. It will be appreciated that the representation of Figure 6 of a PSTN is highly diagrammatic. SCP 43 can operate in a conventional manner by responding to service requests from SSPs 41 to run specific service logic on particular data, according to the information contained in the service request, and to send back to the requesting SSP, appropriate instructions for Make call settings. A service request is generated by the SSP in response to predetermined trigger conditions that are met at a trigger check point, with one or more checkpoints in the course of handling a call, (it may be noted that when conditions The SSP has been downloaded to the SSP from the SCP, so it can be said that the SSP responds to a request for information by the SCP when the SCP is contacted, once the trigger conditions are met - however, in this specification, this Initial communication from the SSP to the SCP will be referred to as a "service request").
SCP 43 is also provided with a network access interface 44 to the Internet 50, in order to use certain service resource items 49 (also referred to below simply as "service resources") during the course of at least certain processing. service requests from the SSPs 41. These service resources 49 are maintained as WWW pages on HTTP servers 51 (more particularly in the resource and service databases 52 of these servers 51). The WWW pages that contain these service resources are referred to below as "phone" pages. The servers 51 are connected to the Internet and the telephone pages are read accessible using respective URLs or URNs (for convenience, the most general term URI will be used below to mean the internet resolution indicator of the location of a telephony page. ). The service resources may be service logic or service damage and may be used by a service logic program of another standard form running in SCP, by accessing the telephone page of the required resource using an appropriate URI. In certain cases, service resources 49 can provide substantially all of the data and service control associated with a particular service. In this case, the logical service program running in SCP 43 is a skeleton, specifically exemplified by receiving a service request and then serving to access service resources and return the results of this access to the entity that made the request. service request. In fact, in accordance with this approach, the SCP can be implemented simply as a platform to search for and execute telephone page service logic and will not require having complex administration and delivery systems for this logic as required by standard SCP platforms; SCPs can then become more ubiquitous, possibly associated with all SSPs, Figure 7 is a flow diagram illustrating the progress of events in the case where SCP 43 handles a service request when accessing a page-phone service resource. Upon receiving a service request in an INAP message (step 100), SCP 43 decodes the TCAP / INAP message structure in standard form (steps 101 and 102) well understood by persons skilled in the art. Next, SCP 43 instantiates a logical service program, SLP, to handle the request (step 103). This SLP is then responsible for searching the URL of the required service resources, as determined from information that is contained in the service request (steps 104, 105). For example, if the service request refers to a called party service, then the required resource will be indicated by the dialed number and the latter will be used to derive the URL of the resource. Once the URL of the desired service resource has been evaluated, a resource request (e.g. in the form of an HTTP request message) is sent over the Internet to the corresponding server that maintains the desired service resource (step 106); a correlation ID is also passed with the resource request, to allow a response from the latter to be linked to the appropriate SLP instance. A synchronizer is also started (step 107). If a response is received from the accessed resource before a time interval expires (tested in step 108). then the response, which is usually in the form of a destination number, is supplied to the appropriate SLP, as identified using the correlation ID that is passed with the response (step 109). An INAP / TCAP response message is then prepared and sent to the entity making the original service request (steps 110 and 111) after which the SLP instance is terminated (113). If in step 108, a time interval occurs, before a response is received, then a predefined response value (usually a predefined destination number) can be searched in the customer record and placed in an INAP / TCAP message and sent back to the requesting entity (steps 114 to 116). The SLP instance is then terminated (113). Locate and Access Services Resources The functionality associated with accessing a phone page resource is represented schematically in Figure 6 by resource access block 46. Block 46 includes a block for URI determination 47, to determine URI of the telephone page containing the desired resource, based on the parameters that are passed through to block 46. Using the URI returned by block 47, the block for accessing resources 46 then accesses the page of telephone of the required service resource 49 on the Internet through channel 44. Resource Codes - It is possible that more than one service resource is associated with a particular telephone number; in this case, resource access block 46 will require to know additional information (such as current point-in-call) to allow the appropriate service resource to be identified. If the service resources associated with a number are located on different telephone pages, then additional information is also passed to the URI determination block 47, to allow the URI of the appropriate telephone page to return. It is also possible that all service resources associated with a number are located on the same telephone page. In this case, the resource access block 46 uses the additional information to pass a resource identification parameter with its request for access to the telephone page of interest; then it depends on the functionality associated with the phone page that accesses the correct service resource. In this way, each service resource can be considered as identified by a respective resource code 54 (see Figure 8), consisting of a first part ÜI ("URI Identifier") used to identify the URI in which the resource is located on the Internet, and a second part RRI ("Relative Resource Identifier") used to identify the resource among multiple resources in the same URI. Resource Access - When only one service resource 49 is located on a telephone page 58 identified by a unique URI, then the resource code 54 simply comprises the UI, generally either a single telephone number or a telephone number plus a foot parameter (see Figure 9). In this case, accessing a resource simply involves mapping the entire resource code 54 into the corresponding URI (process 55) and then sending an application 57 to the corresponding telephone page 58, the latter in itself constituting the desired service resource 49. The result of accessing resource 49 is then returned in response message 59. In contrast, when multiple service resources 49 are located on the same telephone page 58 (Figure 10), resource code 54 comprises both an Ul as RRI, the Ul is usually a telephone number and the RRI is a foot or other parameter to distinguish between co-located resources. In this case, accessing a resource involves removing the Ul part of resource code 54 in the Corresponding URI (process 55) and then send a request 57 to the corresponding phone page (process 56), the request includes the RRI of the appeal code. The telephone page 58 includes 64 functionality to access the required resource, based on the RRI in the request message. The result of accessing the required resource 49 is then returned in response message 59. An alternative to the method in Figure 10 of recessing a service resource that is co-located with other resources on a telephone page would be to recover all the page through the Internet, simply by using the URI derived from the Ul part of the resource code, and then extracting the desired resource based on the RRI.
Determination of URI from the Resource Code - The implementation of the URI 47 determination block that carries out the process 55, will be considered below. Block 47 can be implemented in a variety of ways, four of which are described below: Direct Power It would be possible, although not necessarily convenient, to provide that the called party will directly feed the required URI. The calling party in this manner can feed the guest id component of the required URI (either in the form of a host domain name or host IP address) plus the path component of the URI. For example, in the case where the telephone page of a called party is to be accessed, the calling party can power the URI of the calling party and, without a doubt, this power can replace the normal power of a telephone number. A forward feeding string (for example "999") can be used to identify feeding as a URI With regard to the means of feeding, when a user only has a standard 12-key telephone, the feeding of host domain names and other URI elements that require alpha characters will need to be done using one of the standard techniques for alpha feeding, starting from a keypad (these techniques are already used, for example allowing a calling party to "spell" the name of the called party). It would also be possible to provide users with a complete alphanumeric keypad to facilitate URI feeding. Computing Accessing service resources on the Internet can be restricted to a set of dialed numbers from which it was possible to calculate a corresponding URI; in this case, this computation would be the responsibility of block 47. Association Search Table Probably the simplest implementation for block 47 is an association table (either in memory or kept in a base disk storage). data 48 (which associates a URI with the UI part of each resource code.) A potential problem with this approach is that a service resource may be required for a called party number on the world side, which involves a scheme of rigorous updating between PSTN operators worldwide in order to keep the association table updated (it should be noted that the same implication does not necessarily apply with regard to dialing the called party number as required to trigger a service request, since the number can be arranged to be one of a group of numbers all that trigger or activate an appropriate service request in a manner similar to 800 numbers). po DNS An alternate search solution is to employ a hierarchically structured distributed database system, similar to (or even part of) the Internet Domain Name System (DNS), in order to resolve the Ul part of a code. recourse to a corresponding URI. This approach, which will be described in more detail below, typically involves databases that are maintained by each PSTN operator by their numbers with which URIs are associated. These databases will be accessible to all PSTNs through a network such as Internet with resolution requests pointed to the appropriate database in a similar way to the Domain Name System. In this case, block 47 is constituted by an appropriate resolution program arranged to request Ul resolution over the Internet through interface 44.
Before describing a DNS-like search implementation for the URI determination block 47, additional general comments are appropriate. In any method that is used to determine URI, certain simplifications are possible if limited restrictions are imposed on the allowed URIs. In particular, it is not necessary to determine all the components of a URI in the following cases: (i) A part of the URI path component can be made standard for all service resources, this standard part is simply added to block 47 once the rest of the ÜRIs have been determined.
For example, when a service number outside the domestic area is to be searched, it can always be a convention to keep it in a file of "operation outside of its service area" (roam) in a subdirectory "tel" of the directory of a subscriber in a particular server. In this case, the host component URI and the unique subscriber part of the path component are first determined and then the remaining path part is added "/ tel / roam" (ii) The path component URI can be arranged to be the same as a predetermined part of the resource code, block 47 only requires determining the guest component and then adding the path. For example, it may be agreed that a trajectory must always end with the telephone number of interest, or sufficient of the completion digits so that it has a high probability of being unique in the host machine. The path can also include standard components that are added by block 47. (iii) Blocks of telephone numbers can have their corresponding service resources located on the same host server, so that it is only necessary to use a part of the number of telephone to determine the host component of the URI; in this case, the path component can conveniently include all or part of each telephone number. This situation implies a strict degree of control by the telephone operators and does not offer the telephone user the freedom to choose the host server in which the user places his telephone call. Another general point worth noting is that any way in which the URI is determined, the host component of the URI can be provided either in the form of a host domain name or a hyper-guest address. When the host is identified by a domain name, then an additional resolution of the host name URI to the IP address will subsequently be carried out in standard form by the interface 44 using the Internet Domain Name System. Eta additional resolution can be avoided if the guest identity is provided directly as an IP address. When a database search is used to provide the URI translation number, this database may be independent of, or be combined with, a customer database containing other information related to the client. Factors affecting this selection include, on the one hand, the possible convenience of having widely available number-to-URI translation information and on the other hand the possible convenience of restricting access to other information related to client. DNS Type PRI Search A DNS type search implementation for the URI determination block 47 will now be described in some detail for the case where the Ul part of the resource code, is a telephone number where there are no restrictions on the URI, thus requiring that both the complete host components and the URI path be returned by the search. A key part of the total process is the formation of the equivalent in a host domain name from the telephone number of interest; this equivalent of domain name is then resolved in corresponding URI by a search mechanism that, in the present example it is identical to that used by the DNS (without a doubt, the search mechanism can be incorporated in the DNS although it can also be implemented independently). The nature of the DNS has already been described above with reference to Figure 3, when the term "DNS type" system was also introduced. For convenience, below a DNS-type system organized to provide a telephone number to the URI translation facility, will be referred to as a "Duris" system (representing a "DNS Type URI Server" system). The basic principles that surround the operation of a Duris system are: any telephone number can be converted into a host domain name (the namespace containing these host domain names for the telephone numbers of interest, is referred to below as the "telname space"); and for every host domain name in the host domain space, there is a record that is maintained by the Durís system that contains the corresponding URI. In this way, a power telephone number forming, in the present case, the Ul part of a resource code 54 (see Figure 11), is first parsed to form a host domain name (step 120) and then passed to the Duris system (illustrated in Figure 11, which is provided by the DNS itself) to retrieve the RR with the corresponding URI (step 121). Continuing from the search for tjRI, if the returned URI has its guest component as a domain name, the DNS is then used to derive the address of Guest IP (step 122); this step is of course not required if the guest component is stored as an IP address in the RR. The URI is then used to make a resource request to the appropriate server, by passing any RRI part of the resource code 54 (step 123). There are a number of possibilities at the top level as to how a Duris system can be implemented: (a) Independent of the DNS. In this option, the telname space constitutes the entire namespace to be managed with the root of the telname space that is the root of the namespace "." (See Figure 12A, where the telname space is shaded). In this case, the Duris system is independent of the DNS itself. The Duris system can of course use the same basic infrastructure as the DNS (that is, the Internet) or a completely separate network. When the telname space comprises all the domain names that correspond to all public telephone numbers worldwide, the parsing of a complete international telephone number would give a fully qualified domain name. Of course, the telname space can be a much smaller set of names, such as those derived from the Internet extension numbers within a company that has global operations. (b) The Telname Space Not Fragmented within the DNS. In this option, the telname space is a domain of a DNS name space and the Duris system is provided by the DNS itself. In this way, when the telname space includes all domain names derived from public telephone numbers throughout the world, the telname space can be placed within the ITU domain, in a special subdomain "tel", the root of the telname space is "tel.itu.int." (see Figure 12Í3 where again, the shaded area represents the telname space.) The responsibility to administer the domain "tel.itu.int." would then be in the ITU. example, to form a fully qualified domain name from a power phone number, after the number has been syntactically analyzed to form the part of the domain name corresponding to the structuring within the telname space, it is added to the queue "tel. itu, int." The fully qualified domain name is then applied to DNS, and the corresponding RR record, which contains the required URI, is retrieved.As an additional example, the space Telna e can be a whole name derived from internal extension numbers within Hewlett-Packard, in which case the root of the telname space would be "tel.hp.com." and Hewlett-Packard would be fully responsible for managing this domain. (c) Telname Space Fragmented in DNS. In this option, the telname space is divided among multiple domains of the DNS name space and the Duris system is provided by the DNS itself. Thus, when the telname space comprises all domain names derived from public telephone numbers throughout the world, the telname space can be divided between respective subdomains "t ^ l" of each country domain; in this way, as illustrated in Figure 12C, the part of the telname space corresponding to French telephone numbers would have a root of "tel.fr." and the part of the telname space corresponding to the UK telephone numbers will have a root of "tel, u." . The responsibility of managing each subdomain "tel" would then be found within each country. With this last example, to form a fully qualified domain name from a phone number fedmV. , the part, of the telephone number that follows the country code is analyzed syntactically to form the part of the domain name within the country subdomain "tel" and then the appropriate guest domain name queue is added for the country referred. In this way, for a French telephone number, the. Country code "3.3," is derived from the pre-parsed number and used to add one. "tel.fr." queue. The appropriate queue for each country can be stored in a local lookup table. As an additional example, two commercial organizations (company X and company Y) with respective DNS domains of "xco.com." and "yco.com." they can agree to operate a Du is system with a telñame space divided between "tel.xco.com." and "tel.yco.com." In this case, any power of company phone number Y of company X is syntactically parsed to a fully qualified domain name ending "tel.yco.com," and vice versa. Now consideration will be given to syntactic analysis of a telephone number in a domain name - in other words, where to insert the characters "." in the number to provide the structuring of a domain name. Of course, as already explained, telephone numbers are structured hierarchically according to the numbering plan of each country. In this way one approach would be to follow this structuring of numbering plan by dividing a telephone number to form a name. domain. As an example, the telephone number "4414474569S7" which is a UK number (code "pasta" 44"with a four-digit area code (" 1447") and a six-digit local number (" 456987") can be divided to form a domain name of 456987.1447.44 (note that reversal of the order of the label caused by the fact that the DNS tags are arranged with the least meaning first.) If the space telname is a subdomain of DNS with a placement as illustrated in the Figure 12B, the fully qualified domain name derived from the telephone number would be: 456987.1447.44.tel, itu. int.
However, there is inherent difficulty in trying to adjust the hierarchy of the numbering plan when paging a telephone number in a guest name. First, in order to correctly analyze an international number correctly, it would be necessary for each entity with the task in this operation to know the structuring of the numerical plan for each country and when, as in the case of the United Kingdom, the area codes can be different length., e3. The required knowledge may need to take the form of a search table. While this is not a tare ^. Complicated computing is a major administrative hassle since it means that each country will require to inform all others regarding its numbering plan and any updates. The second problem ^ is that a local number of six or seven digits is a very large domain; It would be preferable to create subdamas because of performance and scaling but there is no obvious way to do this. These problems can be overcome by giving up the restriction that the parsing of the telephone number in a domain name must correspond to the structuring of national numbering plans. In fact, there is no reason, strong to follow said scheme, since, ICLS, DNS servers know nothing about the meaning of namespace. Therefore, it is possible to syntactically analyze telephone numbers using a deterministic algorithm, taking, for example, 4 digits at a time, to limit the size of each subdomain and making it possible to "insert the points", without knowing the referred numbering plan. . Provided that the domains and DNS zones served by the DNS servers are created correctly,. It will not work. For international numbers, it would still seem appropriate to separate the country codes and in this way a syntactic analysis scheme, hybrid would be to analyze the initial part of a number marked according to known country codes and then use a deterministic scheme (for example 3.7 or 4.6 or 3.3.4) to separate the digits. or of course, if a fragmented telname space is used as illustrated in Figure UC, then the country code is used to look up the guest name queue and is the only national part of the number that is analyzed syntactically. Finally, regarding the details of how a DNS server can be configured to maintain the RR records with the URIs, reference can be made, for example, to "DNS and BIND", Paul Albitz and Criket Liu, by O'Reilly & Associates, 1992, which describes how to configure a DNS server using the Unix-BIND implementation. The typical RR records is for example text. It should be noted that in theory, DNS tags should not start with a digit. If this convention is retained, of course it is a trivial exercise when a phone number is syntactically analyzed to insert a standard character as the first character of each label. In this way, a 4-digit label of 2826 would become "t2826" where "t" is used as the standard starting character. It will be appreciated to eat with the domain names ^ when a phone number fed is not the complete number (for example, a local call does not require any area code or international code) is parsed in a domain name in the local domain . The previous discussion of the implementation. of Duris system has been in terms of translating a phone number into a URI, when the phone number forms everything, the Ul of a resource code and the Duris system returns a full URI. It will be appreciated that the described Duris implementation can be easily adapted to adjust the various modifications discussed above regarding the shape of the Ul and what parts of the URI need to be searched. For example, when there are a number of different service resources associated with a subscriber, each in. your own file and the required source is identified by a footer of the resource code, then the power phone number will be used to search the whole URI but the host component and that part of the path component to the relevant subdirectory , the foot part of the Ul is then added to identify the required resource file. For small local Duris implementations, it may be possible to have only one server; the implementation will nevertheless be considered as a DNS type provided that other relevant characteristics are present. Nau leza de Segovia scubagoes Turning now to a consideration of service resources 49, as these service resources can be provided on servers 51, it will be described more fully below but in the manner of the present example, the service resource (s) associated with a particular PSTN user (individual or organization, whether a calling or calling party) can be placed on a server 51 over the Internet from a user terminal 53 on one or more WWW pages. Consider the simple case where the service resource is a service data item, such as a telephone number (for example, an alternate number to try if the user's phone corresponding to the number dialed by the calling party, is busy ). This diversion number may be the only service resource of a user's phone page. The URI telephone page can be a URL, with a scheme configured to HTTP, in which case the GET method can be used to retrieve deviation numbers. This structure is suitable if the telephone page will only be used for functional recovery of the deviation number. However, if the deviation number will have to be presented visually in the user terminal 53, then it may be convenient to accompany the number with explanation material (this will often not be necessary, since the deviation number can be arranged to return in an existing exhibited page that already provides context information), However, when the telephone page does not include explanation material as well as the deviation number, an entity that only wishes to make functional use of the telephone page, can be arranged to recover the phone page, and then extract the deviation number (this will of course require a standard way of identifying the information that is extracted from the phone page).
An alternate and preferred structure for providing both vizual and functional access to a resource that requires explanatory material to see is to employ an object-oriented approach to resource design. In this case, the resource object would have two different access methods associated with it, one for purely functional use of the resource and the other that allows to see associated explanation material. Then it would be up to the access entity to access the resource object using the appropriate object method. An alternate and preferred structure to provide both functional access and observation would be to provide separate resources appropriately configured for each use, each resource has its own resource code (generally both of these resources will be placed on the same telephone page and in this case the Ul part of each resource code will be the same). Recovering a phone page to be used by a human user will generally not be as critical in time as recovering for operational use of a PSTN. In this way, while for human use the scheme specified in the URL of a service resource may be HTTP, it may be advantageous for operational use to define a special "telephone" scheme (access protocol) that would result in the server 51 will use an optimized access routine to access the required resource (deviation number, in the current example) and respond to the access entity in the minimum possible time. Apart from the data items, other possible types of service resources include service logic to execute on site (on the server) with the result of this execution being returned to the entity accessing the resource; service logic that is downloaded from the server to the access entity to run in that entity; and registration resource to record information that is passed through by the access entity (or simply to record the fact that it has been accessed). It will be appreciated that the registration resource is really just a particular case of an on-site executable service logic. By way of example, a service resource constituted by the execution-in-place service logic can be arranged to implement day-of-day addressing, the result of executing the service logic is that the telephone number to which a call must be addressed, take into account the time of day at the site of the called party. An example of a service resource constituted with a downloadable service logic is the service logic to control option interrogation of the calling party, using the facilities that are provided by an IP. With respect to the registration resource, this can be used to record the number of calls directed to a particular number. When each resource has its own phone page, and the resource is currently only in its non-embellished functional form, then the HTTP scheme can be used for access using the GET method for both the downloadable service logic and the execution service logic. envision, and the POST method for the registration resource. If it is desired to provide an explanation material with each service resource, then any of the solutions discussed above with respect to the data items may be used. When more than one service resource is to be associated with a number, then each resource can be placed on a respective telephone page with its own URI. However, the preferred approach is to place all these service resources on the same page and use the RRI part of the corresponding resource codes, to allow access to the appropriate resource. The accessed resource is then treated according to its form (it is executed if the service logic executes-on-site, it is returned if it is logic or downloadable service data). In this way, if both a service data resource with deviation number and an execution-in-place service logic resource are placed on the same phone page in the day-of-day, the resource code of the deviation number may have an RRI of "1" while the resource code of the time-of-day may have an RRI value of "2". When options of the calling / calling party are to be included in the service resource for presentation of said part, then as already indicated, this can be conveniently done by constituting the service resource as a downloadable service logic with the selected option that possibly initiates request for a tracking service resource. It will be appreciated that a service resource will often be of a complex type, combining service data and / or downloadable service logic and / or run-in-service service logic. A particularly powerful combination is the combination of two types of service logic, where the downloadable service logic is designed to interact with the run-in-service service logic.; using this structure, the user can be presented with complex client-server applications. Exemplary Use of Service Resources Figure 13 illustrates the operation of a service that uses a resource on a server 51. This service is equivalent to a service of "personal number" by which a user can access through a single number without change, even when moving between phones that have different real numbers. To achieve this, the user requiring this service (user B in the present example) is assigned a unique personal number (here referred to as the "Webtel" number of B) from a set of numbers, all of which have the same the same number string, forward or input, to allow an SSP to easily identify a number marked as a Webtel number. User B has a service resource 49 on a dedicated telephone page on the HTTP server 51, this telephone page is located at a URL here identified as "URL (telephone page B)". The telephone page of B when accessed, returns the service number outside the current domestic area ("B-telNb") where B can be reached. In the simplest case, the telephone page B is just a single number that can be modified by B (for example from a terminal 53) as B moves to a different telephone. Phone page B is more likely to be a run-in-service service logic providing addressing with the time of day.
In the present example, the association between the number Webtel B and the URL of the telephone page B is stored in an association table accessible to SCP 43. When a user A seeks to contact user B by dialing the Webtel number of B, the telephone 40 used by A passes a request for configuration of call to SSP 41 (it should be noted that in Figure 13, the carrier paths through the telephony network are illustrated by the thickest lines 60, the other lines more heavy indicate signaling flows). SSP 41 detects the number dialed as a Webtel number and sends a service request to SCP 43, together with the Webtel number B. SCP 43 upon receiving this service request initiates a logical service program to control the translation of the Webtel B number in a service number outside the current domestic area for B; in fact, in this case, this program simply requests the resource access block 46 that accesses the service resource identified by the Webtel number of B, (that is, the telephone page of B 49) and returns the result of this access. For this purpose, block 46 first translates the number Webtel B to the URL of the telephone page B and then uses this URL to access the telephone page B over the Internet (for example, using the "telephone" scheme already referred to by the method corresponding to the HTTP GET method). This results in the service number outside the current domestic area B B-telNb being passed back to block 46 and in due course this number is returned to SSP 41, which then initiates termination of the call setup to the telephone 40 corresponding to B-telNb. The example in Figure 13 is related to a called party service; Of course, it will be appreciated that the principle of accessing service resources on the Internet can be applied to all types of service, including both calling and called party services and hybrids. In this way, standard 800 service numbers can be implemented with the dialed number 800, which results in access to a phone page resource that is constituted by the run-in-service service logic that returns the most appropriate number to control call forwarding. It will be appreciated that although in the example of Figure 13, the service request from the SCP is triggered by an input number string of a dialed number, a service request may be triggered with a variety of triggers including part number that call, called party name, or some user power, these triggers are possibly qualified by progress in the call setup (eg qualified call party number by a busy state or by call or ring for more than one time). With respect to the registration service resource mentioned above, a possible application for this resource is by telephone vote. In this case, dialing the voting number causes the SCP to pick up the call to pass a service request to SCP 43, which then contacts the appropriate registration resource on the Internet to record a vote after which the call is terminated. To minimize bottlenecks, a registration resource can be provided in a different URL for each SCP, being a simple matter to collect and collect votes of all these registration resources on the Internet. If the SCP with Internet access is provided throughout the SCP, then the risk of congestion is greatly reduced. As already noted, a user phone page can maintain multiple service resources, in which case the access request from the access SCP requires to contain an RRI that identifies the required resource. In the case where an SCP is going to provide both a traditional IN service to some users and an equivalent service using a service resource accessed over the Internet from other users, then it may be required to provide a search table in the SCP to ensure that a service request is handled properly; This search table can be conveniently combined with the customer record database. Once a user, such as user E has configured one or more telephone pages specifying their desired service resources (particularly the service logic defining custom services), it is clearly logical that user B wants any PSTN operator to interest to use, to access and use these service resources. This is possible if the Webtel-a-URI databases are available to all operators. In this way, multiple operators can configure to access the telephone page (s) B. If an operator declines to use the telephone B pages, it can obviously choose not to use that operator (at least when that operator provides a long carrier service). distance subject to user selection). Therefore the possibility arises that the supply of services S to send a prize to operators but that provision of the use of telephone page by an operator will become a necessary basic characteristic of the PSTN operation. Supply and update of service resources.
Next, consideration will be given as to how service resources 49 are supplied to servers 51 and subsequently updated. As far as provisioning is concerned, two basic actions are required: first, the service resources must be placed on a server 51 and secondly, the URI of the service resources must be notified to the PSTN operator together with the trigger conditions (number plus any other condition such as point in call) requesting access to the resource; if multiple resources are provided in the same URI, then the RRI values required to retrieve the appropriate resource for a particular trigger condition must also be reported. This notification process will be referred to below as "registering the service resources with the PSTN operator, the registration is of course necessary to allow the association tables used by SCP 43 to be configured and for the trigger conditions to be established in the SCPs 43. For certain services, such as the one described above with reference to Figure 13, it is not the user who supplies the trip number (the Worldtel number in the example of Figure 13), On the contrary, the PSTN operator assigns an appropriate number to the user as part of the registration process.
As for the process of placing a service resource on a server 51, how this is carried out will depend on the attitude of the PSTN operator to the possible effects of these service resources on operation of the PSTN. When the service resource simply returns a data item to an access entity, then an operator may not be too involved or concerned about possible errors (accidental or deliberate) when deploying the service resource. However, the operator will probably be much more involved in the proper operation of any service logic that can be returned by a resource; No doubt, an operator may not allow this service resource. Considering for the moment that an operator has no concerns regarding the nature or implementation of service resources, then how a resource is placed on a server 51 will depend substantially on the nature of the server involved. For example, if a user has a computer with Internet access to the Internet and this computer is used as the server 51, then the user can simply upload a desired resource to the server as a WWW phone page for external access. A similar situation arises if the server is an organization server to which the user has access over an internal LAN. In both of these latter cases, loading the resource as a WWW phone page itself does not require Internet access. However, if the server 51 is one running through an external Internet service provider, then a user may arrange to download the required service resource in the network site space assigned to the user on the server; this may not involve Internet access. A special case of this last scenario is when the PSTN operator provides a special server for user telephone pages that contain service resources. Except when a user's own computer acts as a server 51, placing a service resource on a server will generally involve releasing one or more levels of password protection. Regarding the origin of the service resources loaded by a user in the server 51, this can be generated by the user or particularly when the resource includes service logic, it can be provided by a third party (including the PSTN operator). If the PSTN operator wishes to have control over the service resources 49 to avoid any adverse effects on the PSTN operation, two approaches are possible. First, the operator may require that any resource (or possibly a particular subset) have to be subject to a verification process before use, then appropriate measures are taken to avoid subsequent alteration of the resource by the user (except possibly for items of particular data); in this regard, the operator may require that the resource be placed on a server under operator control and to which the user does not have write access (possibly except for altering particular data items as indicated above). A second, more attractive approach to minimize adverse effects by service resources 49 is for the operator to provide standard service resources to which a user can add the user's own data (and possibly perform limited functional selections in case the resource includes service logic); the resource adjusted to the measure will then be loaded into a server 51 controlled by --the operator. This process can be conveniently implemented for a particular resource using a "HTML" form, which a user can download over WWW from the operator controlled server. After completing the form and activating a graphic "entrust" button of the form, the information provided will be "sent" in the mail back to the server, where the information will be used to produce a custom-made service resource subsequently placed on the server for Internet access. An advantage of this approach is that the registration of the service resource with the operator takes place simultaneously. (It can be noted that if the registration requires to be performed as a separate act of a service resource loaded on a server, then using an HTML form is a very convenient way to implement the registration process). From the above, it can be seen that while the supply process does not necessarily require information to be passed on the Internet, in many cases, this will be the best solution, particularly if an HTML form exchanged over WWW can be used to produce a service resource. adjusted to measure. It should be noted that producing custom-made service resources using an HTML form is not limited to cases where the PSTN operator controls the server. Regarding updating service resources, there is probably a need to update certain data items on a substantially frequent basis (for example, an operation number outside the service area). When the PSTN operator does not place any control on the service resources 49, then the update is relatively simple matter, only requiring written access to the server in question (as already indicated, this will generally involve one or more levels of protection with key) . However, when the PSTN operator exercises control over the service resources, for example by only allowing adjustments to the measurement of standard service resources, these tailored resources are loaded into servers controlled by the operator, (then the access of Writing to the service resource can be strictly controlled Again, an HTML form can be conveniently used as the means to modify a data item in such cases, to the operator, this has the benefit of limiting possible modifications while for the user , a formal interface will provide a simple route to modify the resource.For more complex updates, it may be necessary to go through a process similar to that required for initial supply, particularly when the service resources are maintained in a server 51 controlled by the PSTN operator, the updating of resources in general will involve communication on the Internet. Network User Interaction Next, consideration will be given to other possible uses of the service resources that are maintained in the telephone pages on servers 51. For example, if the telephone page D of the user contains a deviation number, then provided that this telephone page is accessible to reading over the Internet from terminal A of user 53, user A may use a graphical network viewer that runs in terminal 53, to view telephone page B and discover the number of deviation B. As previously discussed, the deviation number can be passed to user A to display in an existing visual context giving meaning to the number, or it can be passed to user A with accompanying explanation text. A more useful example is an operation number service outside the current service area for user B. Suppose that telephone page B 49 on server 51 (see Figure 14) is operational when accessed to return an operation number outside the current service area, where B can be reached. Also suppose that user B has a Web site with several pages of the network written in HTML, and each page contains a graphic "phone" button, which when activated uses the GET method to access the telephone page B through its URL. Now, if user A goes through (arrow 66) the site of network B in WWW of terminal A of user 53, decides that he would like to call user B to discuss some aspects of interest, user A simply activates the button telephone 65 on the page currently viewed from B. This causes telephone page B to be accessed using the HTTP request "GET URL (telephone page B)" - see arrow 67. The current B-to-call number is then determined and it passes to terminal A of user 53 (see arrow 68) where it is displayed. An explanatory text regarding the number will usually also be displayed; for example the text "please call me at the following number:" can be displayed, this text is provided either by the associated HTML macro on the phone button or from the phone page when the current number is returned. In fact, it would probably be more helpful to provide user A not only when the current number to reach user B also with all the numbers where B could be reached along with the times when B would more likely be in each number. Since this extra information will likely be subject to frequent change, the only sensible way to provide the information is from the telephone page. In this way, the telephone page B not only provides the current number to reach B, but also a text that includes numbers and times subject to changes; Of course, creating macros on phone page B is done in a way that ensures that variable data only needs to be altered in a site. In a further example, the telephone page B may include downloadable service logic to run in the user terminal A. This is useful where selections are presented to a user, each selection produces a follow-up action such as searching for an additional phone page. For example, the first telephone page accessed may be a family telephone page, giving the general telephone number for a family but also giving the user the possibility to select additional telephone information in each family member, such as number dependent on the time of day; In this case, each family member has their own follow-up phone page. In the previous scenarios, user A has been presented with a number to call on the PSTN. User A can now pick up his standard phone and dial the given number. In fact, a complication does arise. A only has access to the Internet through a SLIP / PPP connection over an ordinary line, non-ISDN, PSTN, since in this case the telephone line A is already linked to making Internet access when the gateway 90 seeks to configure a call to telephone A; with an ISDN connection, since there are two available channels, this problem does not arise, one way to overcome this problem would be to make the user terminal A 53 after obtaining the number to call from the telephone page B, automatically suspend its session of Internet by storing any required status information (for example the WWW URL that is accessed) and then terminates its SLIP / PPP connection, in order to free up the telephone line. A may then be telephone B. At the end of this call, A may resume the suspended session from the Internet, using the stored state information to return to the point where A left to call B. An alternative approach is to operate a scheme of modulation with convenient multipathing in the telephone line to A, allowing voice and data to be simultaneously transported. A number of these schemes already exist. The PSTN would then require separating the combined data and voice streams coming from A at some point and passing each to its appropriate destination (Internet data is sent to the ISP providing the SLIP / PPP connection for user A and the stream of voice that is passed to B); Of course, data traffic and voice in the reverse direction would also require combining at some point to send over the last section to terminal A. Instead of A manually dialing B using a standard telephone, another possibility is that user terminal A be provided with the functionality that allows A to make a call on the PSTN from its terminal; this functionality in general comprises a physical equipment interface 70 (Figure 14) to a telephone line and telephone driver software 71, to control the interface 70 in response to power of the application software, such as the network viewer 73. A You can request your phone software and provide the required or preferred number. You only need to "choose" on the screen the number that is returned to the phone page B and then pass it to the phone software A. No doubtprovided that the user B knew the software interface to the software 71 that provides the dialing functionality in the terminal of A, it would be possible for the telephone page B to return the terminal program code A to automatically dial the number B, when To confirm that you want to proceed with the call settings. As an alternative to placing a voice call, if terminal A is equipped with a convenient modem and control software, A can instead choose to send a fax or data to B through the PSTN, either to the ordinary number B or to one specified on telephone page B as the number to be used for these transmissions. Of course, directing a call from terminal A on the PSTN may be subject to the problem already discussed in conflict to use the telephone line where it is not an ISDN line and A obtains access to the Internet through a SLIP / PPP connection.
Regardless of how the call is configured, if the telephone B corresponding to the number attempted by A is busy, there are a number of possibilities. In this way, if B has a telephone page that specifies a deviation number and B has registered this service resource with PSTN, then the deviation number must be automatically attempted by the PSTN. However, if the diversion number resource has not been registered with the PSTN, it will be returned to a busy signal to A. When A has placed the call through a standard telephone, A must now decide how to proceed and A can choose either to cede or re-reference phone page B to look up the deviation number and redial using this number. If A directs the original call using its terminal 53, then the latter can be programmed to detect the return of a busy signal and then automatically look up the diversion number B and redial using this number. This functionality can be included in the service logic downloaded from phone page B and run in terminal A. If A had to end his Internet session in order to free up the telephone line for voice use, then re reference again telephone page B is required to initiate a new Internet session (in fact, this inconvenience can be avoided if the diversion number B is passed to terminal A at the time the original number to be marked for B is supplied) . The service resources accessed on telephone page B when telephone B is busy, of course can be more complex than just a deviation number. In particular, user A can be presented with a range of options, including for example, voicemail number or fax B, the selection of an option potentially initiates the operation of an appropriate access software. Another possible option would be for A to leave B a callback message, using a downloaded form from the B phone page when this option is chosen; the complete form would be sent by mail back to server 51 and would be registered for B to verify in due course. Of course, it may arise that user A wishes to access telephone page B to find, for example, the operation number outside the current service area of B, but user A does not know the URI of the site of network B and only has the number Webtel B. A can only dial B through the PSTN, in which case the translation of the number Webtel B to the service number outside the service area would be carried out automatically (considering that B is still registered for this service); however, A may not want to call B directly, but only write down his or her operation number outside of the current service area. In order to solve the problem of A, the Webtel-to-URl association tables previously described, preferably are made accessible on the Internet at a known address. (For example in a known network site). All A needs now to do is access this web site by passing the Webtel number of B; the URI of the telephone page B will then be returned to A which can then be used to access the telephone page of B. This process can of course be made automatic from the point where A sends the Webtel number of B to the network site of the association table. In the scenario of Figure 14, the access from A to the PSTN was through a standard telephone interface, even though the current form of A's phone differs from the standard when it is integrated into the terminal. A 53. Figure 15 illustrates a situation where A, after being supplied with the operation number outside the current service area of B as in the case of Figure 14, calls B by a route that starts over the Internet and then pass through a user network interface 80 in the PSTN. The interface 80 is arranged to convert between the ISDN type telephone signaling in the PSTN and corresponding signaling indications that are transported over the Internet in IP packets.; furthermore, interface 80 transfers voice data from packets 1P to trunk 60 and vice versa. In this way, when initiating a call to B, the Internet telephone software 81 in terminal A sends signaling of initiation of call on Internet to the interphase 80, the address of which is already known by terminal A. In interface 80, the signaling is converted to ISDN type signaling and passed to SSP 41. The call configuration then proceeds in the normal way and the return signaling is transferred back through interface 80, over the Internet, to the software 81 in terminal A. This software passes call setup advance information to the WWW 73 display to display in A. When the call is established, A can talk to B through his telephone and A's voice feed first it is digitized in the physical equipment interface of telephone 83 and then inserted in software IP packets 81 to travel through Internet to interface 80 (see arrow 84); B's voice traffic follows the reverse path. IN service can be provided to this call by SCP in response to a service request from an SSP 41. In this way, if B's phone is busy and B is registered for call diversion, SCP 43 upon receiving a service request will access the appropriate phone page of B for call diversion and retrieve the deviation number. If SSP 41 is not set to initiate a service request when the telephone B is busy, the busy indication is returned to terminal D where it can be handled in the manner already described with reference to Figure 14. In fact, the interface 80 may be provided with functionality similar to an SSP, to adjust trigger conditions and generate a service request to SCP 43 when these conditions are satisfied. Gateway for third-party call configuration Figure 16 illustrates an additional structure by which A can call B after receiving the operation number outside the current service area of B. In this case, a call configuration gateway of third part 90 is provided which interconnects with both Internet 50 and SSP 41. Conveniently, gate 90 may be co-located with SCP 43 (although this is not essential). Gate 90 has the ability to send SSP 41 to configure a call between specified telephones. Thus, when A wishes to call B, a third party call setup request is sent from terminal A over the Internet to gate 90 (see arrow 91). This configuration request includes the telephone number A and the number of operation outside the current service area of B. Gate 90 first attempts to configure the call to telephone A (what will happen in general) and subsequently to configure the call to the identified telephone of B. Once the call is configured, A and B communicate in standard form through PSTN. If B's phone is busy, then any of the previously described scenarios may arise. The gate 90 can also be arranged to make service requests to SCP 43, when predetermined firing conditions are satisfied. In this way, the gate 90 can be adjusted to pick up the busy condition on the telephone B and initiate a service request to SCP 43 for a diversion number. However, passing the busy indication back to terminal A through gate 90 is preferred due to the flexibility that A gives for greater action. As has already been discussed generally in relation to Figure 14, a complication arises if A only has access to the Internet by SLIP / PPP connection over an ordinary line, not ISDN, of PSTN, since in this case, telephone line A is already linked with Internet access, when gateway 90 seeks to configure a call to telephone A. The solutions discussed with respect to Figure 14 (termination of the Internet session; To add voice and Internet data on the same phone line, you can also use it here. An alternate approach for both the scenarios of Figure 14 and Figure 16 is possible if the user terminal can handle a voice call as a digitized voice that is passed over the Internet. In this case, the voice call can be placed through an interface 80 of the form of Figure 15 and the voice traffic and the Internet communication with the telephone page B and / or gate 90 both are transported in packets of Internet that are passed over the SLIP / PPP connection to / from terminal A 53 but as logically different flows that are passed to separate applications that run on terminal 53. It can be noted that the third party call setup request made by the terminal A to gate 90, it can also be arranged by the service logic that is maintained on telephone page B and executed by server 51 (this structure will of course require that telephone number A be passed to the service logic of the telephone page B and this can be arranged to occur either automatically or through a form presented to user A in terminal A and then sent back to the server by mail 51). It can also be noted that interface 80 of Figure 15 and gate 90 of Figure 16 provide examples of service requests that are passed to the service control subsystem by entities other than SSPs 41. "Free telephone" services (free phone) ) based on WWW (number 800) It is possible to implement a service type of "800 number" or "free phone" using a combination of WWW and PSTN. As will be seen from the following description of this service with reference to Figure 17, a WWW / PSTN implementation does not necessarily rely on either transferring call charges from the calling party to the called party or using a special number " 800", two characteristics of standard" free phone "schemes. WWW / PSTN implementations however present the most general characteristic of placing a questioning party and the party to whom the interrogation is directed, in telephone contact in charge of this last part. In the structure of Figure 17, a user D such as a large department store has a site in the network on a server 51; for reasons of simplicity, the server will be considered to be under the control of user D who has direct computer access to the server on line 125. The D network site, for example, can contain many catalog-type network pages that illustrate items offered for sale by D, In addition, D has a free telephone page 124 to handle interrogations addressed on a free telephone basis; the URL of this page is associated with a graphic "free phone" button 122 placed on each of the catalog pages of the web site. Suppose that user A in terminal 53 is going through the network site of D, looking at the catalog pages (arrow 121). If A sees an article of interest and wishes to interrogate D regarding this article, then A may activate in terminal 53, the free graphic telephone button 122 associated with the catalog page involved. This activation causes the code embedded in the catalog page that is currently loaded in terminal D, to prompt the user to provide their telephone number and optionally their name, after which an HTTP request is sent to the telephone page free of D using the method í > OST and attaching the data provided (arrow 123). The free telephone page of D upon receiving this request executes the service logic to provide a new interrogation (including the name and telephone number of A) in an interrogation waiting list 127 that is maintained in an interrogation control system 126. In the present example, the interrogation control system is connected to the server 51 by line 125, external to the Internet; however, it would also be possible to have the server 51 communicate with the interrogation control system via the Internet and without a doubt this may be the most practical structure where the D network site is in an ISP server instead of a server controlled by D. In fact, the code that runs in the terminal of A when activating the graphic button of free telephone 122 can be arranged so that it directly sends the interrogation request to the system of control of interrogation on Internet instead of passing it back through the server 51. The interrogation control system 126 administers interrogations that are passed to it to ensure that they are resolved or attended in an orderly manner. The system 126, upon receiving a new interrogation, preferably estimates approximately how long it will take before the question is answered, this estimate is based on the number of interrogations that are currently on the waiting list and the average time it takes to manage an interrogation This estimated waiting time is passed back through the server 51 to the user A in response to the POST request message. The interrogation control system 126 searches after the distribution of interrogations to a number of agents each of which is it equips with a telephone 40 and a display 129. The interrogation A will be dealt with as soon as it reaches the head of the waiting list 127 and there is a detected agent available to handle the interrogation (in this way, for example the system can be arranged to detect when an agent's phone hangs up). When these conditions are met, a configuration and distribution control unit 125 takes interrogation D and presents the name and telephone number of D in the exhibitor 129 of the available agent (for clarity here referred to as agent D); if user D maintains a database of credit rating data and past clients of D, then unit 128 will also search and display all this additional information that is known about A. At the same time, unit 128 requests of third party call configuration (arrow 130) on the Internet to gate 90 asking that a call be configured between the telephone of the available agent D and the telephone of user A, both telephones are identified by their respective numbers. If both D and A pick up the phone, then the interrogation proceeds, the cost of the call is paid by D, since it is D who originates the call in the PSTN. If for any reason the call is incomplete (for example, it is not answered by A) for a predetermined period of time, then the unit 128 can be arranged to automatically pass to the next interrogation at the head of the waiting list 127. Of course, it will be possible to prevent the unit 128 from requesting the call configuration through the gate 90 and either that the agent D manually dial the number of A or that the unit 126 starts automating for the telephone D (the agent D has for example a telephone integrated to computer similar to that of A in Figure 14). The advantage of these approaches is that the existing PSTN can be used without adaptation and without any service installation to implement the free telephone service based on WWW. As discussed in relation to Figures 11 and 13, a complication arises when directing a call to A, yes A only has access to the Internet through a SLIP / PPP connection over a PSTN line, ordinary, not ISDN, since in this case, Telephone line A is already linked with Internet access, when user D tries to set up a call on the telephone of A. The solutions discussed with respect to Figures 11 and 13 can also be used here (termination of the Internet session; collect Internet and voice data on the same telephone line, and direct the call over the Internet to the terminal of A). With regard to the solution based on termination of the Internet session, this termination may be delayed until question D was about to be addressed; however, to do this, it would be necessary to provide feedback from the control system 126 over the Internet to the terminal A 53 and to associate this realization with code to carry Internet session termination. One way to achieve this would be to have the response message sent by the server 51 in response to the original POST request message from A, include a correlation code, any subsequent feedback from the system 126 passed A would also include this code (server A has also passed the code to the control system 126) thereby allowing terminal A to correctly identify this feedback. In fact, the same mechanism can be used to provide user A with updates that so much more than user A would probably have to wait to be called back, mechanism is usable regardless of whether or not there is a conflict problem to use the telephone line From d.
Whether user A only has a telephone 40 and there is no terminal 53, it is still possible to use the basic structure of Figure 17 to provide a free telephone service for user A without resorting to the complexity of charge transfer of call. More particularly, A would dial a special number for user D's toll-free service (typically an 800 number) and SCP 41 would recognize this special number in standard form and would make a service request to SCP 43 including both this special number and the number A. SCP 43 then evaluate ^ the free phone page URL of D, by making a translation of numbers -a- URL and accessing the free phone page D using a HTTP request of POST method similar to the request 123. A Once this request has been registered as an interrogation by the free telephone page D 124, the latter may send a reply to SCP 43 requesting that it reproduce an announcement such as "be registered without interrogation by free telephone, please hang up and be will contact briefly. " This ad can be played back to A by an IP in standard form. I would then hang up and be ready to receive a call from D. A significant advantage of the previous free phone schemes using WWW, is that user D does not incur charges to use the PSTN during periods when a question is put on the waiting list, waiting to be handled. Variants Of course, there are many possible variants to the structures described above and a number of variants is described below. Distributed processing environments. As illustrated in Figure 18, SCP 43 can access the HTPP 51 servers through a distributed processing environment (DPE = distributed processing envirsnment) 98, at least logically separated from the Internet, preferably in this case the servers 51 are controlled by the PSTN operators and are thus restricted in number. Server service resources of the DNS type. In the previous examples, the service resource items have been placed on the server 51 connected to the Internet and the desired service resources have then been accessed on the Internet by the PSTN service control sub-system, and / or by users Internet, through the use of a URI derived from a resource code that identifies the desired service resource item. In a preferred structure for deriving the URI from a resource code in the form of a telephone number, all or part of the related telephone number was analyzed syntactically in the form of a domain name and then resolved in a URI using a system of Distributed database of the DNS type that can undoubtedly be integrated into the DNS itself (see Figures 11 and 12 and related description). In fact, it would be possible to direct the service resource items directly in registers that are maintained by a distributed database system of the DNS type, so that instead of the telephone number it is analyzed syntactically that it resolves to a URI , which is then used to access the required resource, the syntactically analyzed telephone number is directly resolved to the required service resource item. The mechanism used in this process is exactly as it was already described to solve a syntactically analyzed phone number in a URI. The distributed DNS database system used for this would preferably be one accessible via the Internet or the DNS itself in order to provide access to service resource items for Internet users, as well as for the service control subsystem of the PSTN (in the same way as described above with reference to Figure 18, the DNS-type servers that maintain the service resource items may be accessible to the service control sub-system by a network different from the Internet). While the placement of service resource items in the RRs that are maintained on servers of the DNS type may not be convenient for all types of service resource items, it is convenient for items such as telephone numbers that do not change f. In this way, a convenient use is to provide number portability; in this case, a dialed personal number triggers a search in the DNS type system with all or part of the personal number that was syntactically analyzed first and then applied to the DNS type system to return voice and current number for call routing. All the dialed numbers can be treated as personal numbers or simply a subset of these numbers, this subset includes numbers that are easily identifiable as personal numbers, for example by local search in an SSP or the presence of a digital front letter pr -d finished. The general concept of syntactic analysis of a telephone number (or similar number) totally or partially to form a domain name for resolution in a distributed database system of type DNS, can be used to retrieve other information items in addition to URIs and service resource items. Mechanisms of réa, liraentación. When discussing the structure of the free telephone in WWW base of Figure 17, it was mentioned that user A can be supplied with feedback in equal length of the waiting time before A will be called again. This is an example of using the Internet to provide a feedback path for a potential or current telephone user. Another example is provided with reference to Figure 16, wherein the call back configuration progress is reported by the call configuration gateway to the user's terminal A. In fact, in general when it is known that a user is using a terminal actively on the Internet, the opportunity arises to provide the user with feedback regarding the progress of the configuration of the call through the telephone system. In order to do this, of course it is necessary to make sure that the feedback is passed to the appropriate application running in terminal A and this will generally require that the application has made the appropriate link information available. Like the advance information in the call configuration, other information can be fed back, for example, during a call waiting period. In this way, for example, a special server can be provided on the Internet, having cut-outs of multimedia or even video that can be sent out to user A during a call waiting period. In the structures described, the servers 51 have maintained service and resource items primarily involved with the call configuration control. It can be noted that in a somewhat different application, the internet servers can be structured to be arranged to maintain data that can be accessed from the telephone system, in response to a user initiated telephone request and returned to this telephone user. This service will be provided for example in response to an SSP that triggers a service request on a particular telephone number that is powered, the service request signals an SCP that causes a smart peripheral to access a particular Internet server (not necessarily an HTPP server) and retrieve the required data for return to the calling party. The intelligent peripheral may include a text-to-speech converter to reproduce the data vocally to the user. An additional feedback process is also worth noting, in this case regarding service resource items themselves. As an example, a G telephone user can subscribe to a service by which calls that are passed through G's telephone are to be separated by a minimum of X minutes, X is adjustable by the user. To implement this G service, it has a telephone page on a server 51 that includes a "busy" status indication. Upon successful completion of a successful call to G, the local SSP of G triggers the sending of a message by the associated SCP over the Internet to the telephone page of G. This message causes the busy indication of G to be adjusted to indicate that G is occupied; the message also starts a synchronizer that ends after a period X and causes the busy state indication to be reset. An attempt to call Q will already be rejected in G's SSP because the G line is genuinely busy or will trigger the SSP to interrogate through the SCP, if the busy status indication of the G phone page is set. If the busy status indication is set (which will be during period X after the successful completion of a call), the call attempt is rejected, whereas if the busy status indication is in its reaction condition, the call attempt is let it proceed. By placing the mechanism for busy status indication on the telephone page of G, it is possible to arrange that G be able to easily change the value of X. More general variants. While the sub-system for service control of the PSTN has been incorporated as an SCP of the above examples, it will be appreciated that the functionality of the service control sub-system may be provided as part of an SSP or an associated attendant. In addition, the triggering of service requests can be performed by equipment other than SSPs, for example by interception crates inserted in the SS7 signaling links. It will be appreciated that the term "Internet" will be understood to include not only the current specification of the PSP / IP protocols used for the Internet and the current addressing scheme, but also evolutions of these characteristics as may be required to deal with isochronous means. In addition, references to WWW and the HTPP protocol will also be understood to cover their developed databases. The present invention can also be applied to telephony systems other than just PSTNs, for example to PLMNs and other mobile networks and to private systems using PABXs. In the latter case, a LAN or computer network throughout the university city (ca pus) that generally serves the same internal users as the PABX, will take the Internet role in the described modalities. In addition, the present invention has application when any switched telecommunication system (eg, a broadband ATM system) requires service control and a computer network can be used to supply service resources to the service control sub-system of the telecommunication system. telecommunications -

Claims (1)

  1. CLAIMS l. - n method for providing services to users of a public switched telecommunications system, which includes a service control sub-system that communicates through a signaling system with bearer channel switches, the service control subsystem provides an environment for execution of service logic, where logical service programs for controlling carrier channel configuration through the telecommunications system are run in response to reception by the service control sub-system of corresponding service requests, the method is characterized because it includes the steps of: (a) providing at least one server connected to a computer network, with a plurality of service resource items that are each associated with a respective predetermined code, the computer network is accessible to a portion substantial of the users of the telecommunications system but logically other than that system, and the service resource items relating to configuration control for bearer channels through the telecommunications system; (b) when the service control subsystem receives a service request including a predetermined code, run the corresponding logical service program and access the appropriate server at a minimum to use the service resource item corresponding to the predetermined code included in the request , in the course of service provision by the logical service program relating to the configuration of the carrier channel through the telecommunications system; and (c) allow reading access of user terminals over the computer network to at least one server, thereby allowing the service resource items to be maintained there, accessed from the user terminals and before that be used regarding configuring a carrier channel through the telecommunications system. 2. - A method according to claim 1, characterized in that the service resource items are accessed by the service control sub-system on an independent path of the signaling system. 3. A method according to claim 2, characterized in that the computer network is a publicly accessible computer network, the server is at least accessed from the user terminals and the service control sub-system through the Computer network. 4. - A method according to claim 1 or 2, characterized in that the computer network is a publicly accessible network, the server is at least part of the service control sub-system of the telecommunications system and access to the user terminals through the publicly accessible network. 5. - A method according to any of claims 1 to 4, characterized in that the method includes the additional step of: (d) access from the user terminal, in the computer network, a service resource item associated with a service or part called intended with which it is desired to communicate about the communication system and use the item of resources to control configuration of a communication through a telecommunications system. 6. A method according to claim 5, characterized in that the service resource item is accessed from the user terminal in stage (d) before initiating communications through the telecommunications system, the result of using the item of service resources is used to automatically initiate a communication through the telecommunications system. 7. - A method according to claim 5, characterized in that after the start of communication through the telecommunications system, the return of a busy indication is operative to cause the item of service resources accessed from the user terminal in stage (d), be used in determining further call configuration processing. 8. - A method according to claim 5, characterized in that the service resource items are located on the computer network using the corresponding DRIs, the service resource item is accessed from the user terminal in the stage (d) ) using the corresponding URI. 9. - A method according to claim 8, characterized by the service control sub-system also access the service resource items on the computer network using the corresponding URIs stage (d) including the sub-stage of producing a pre-determined code included in a service request in the URI of the required service item. 10. - A method according to claim 8, characterized in that access to the service resource item from the user terminal in step (d) is effected by the sub-steps of accessing the predetermined code in the user terminal, translate this code into the URI of the associated service resource item, and then access that service resource item over the computer network using the URI. 11. A method according to claim 9 or 10, characterized in that the sub-step of translating the pre-determined code in the URI of the associated service resource item is carried out by one of the following methods: a direct mapping, where the pre-determined code corresponds substantially to the URI. ; manipulate the default code according to a predetermined function; search in an association table that is maintained locally, which associates the default codes and the URIs; Searching in an association table, which associates the default codes and URIs, the association table is maintained at least on a database server connected to the computer network. 12. - A method according to claim 9 or 10, characterized in that the sub-step of translating the pre-determined code into the URI of the associated service resource item is performed by searching in a distributed database system of the DNS type, where the URIs are kept in registers associated with respective names, here referred to as domain names by which records can be retrieved, at least a substantial portion of the predetermined code is parsed at least in part from a corresponding number of domain and this domain number when completed, is used to retrieve the URI of the required service resource item from the database system. 1 - A method according to any of claims 8 to 12, characterized in that at least two items of service resources are located in the same URI, the default codes of these service resource items include relative identifier values of respective resources (RRI), which are used in the server that maintains the service resource items to identify the required resource item among the service resource items in the same ÜRI. 14. - A method according to claim 5, characterized in that at least one server is part of a distributed database system of the DNS type, and the service resource sites are maintained in registers associated with respective names, referred to herein. as domain names, by which records can be retrieved, the service resource item is accessed from the user terminal in step (d) using the corresponding domain name. 15. - A method according to claim 14, characterized in that the service control sub-system also accesses the service resource items on the computer network, using the corresponding domain name, stage (b) includes the syntactic parsing sub-step of at least a substantial portion of the predetermined code included in a service request in at least a part of the domain name of the required service resource item. 16. A method according to claim 14, characterized in that access to the service resource item from the user terminal in step (d) is performed by accessing a predetermined code in the user terminal, parsing at least a substantial portion of this code at least part of the domain name of the associated service resource item, and then access that service resource item over the computer network using the domain name. 17. - A method according to any of the preceding claims, characterized in that the telecommunications system is a public telephone system, each predetermined code is one of the following; - the telephone number of the calling party; - the telephone number of the called party; - a numerical feeding by the calling party. 18. - A method according to any of the preceding claims, characterized in that at least one of the service resource items is service logic that is executed by the corresponding server when it is accessed, with the result that this execution is returned to the Access entity to use in call configuration control. 19. - A method according to any of the preceding claims, characterized in that at least one of the service resource items are downloadable service data that when downloaded are downloaded to the access entity for use in call configuration control, 20. - A method according to any of the preceding claims, characterized in that at least one item of service resources is downloadable service logic that upon accessing is downloaded to the access entity to execute the call configuration control. 21. A method according to any of the preceding claims, characterized in that the computer network is Internet. 22. - A method according to any of claims 12, 14, 15 or 16, characterized in that the computer network is Internet and the distributed database system of the DNS type is provided by the Internet DNS. 2 . - A method according to any of the preceding claims, characterized in that the telecommunications network is a PSTN. 24, - A method according to any of the preceding claims, characterized in that the URIs are URLs and / or URNs, and the server is at least an HTTP server. 25. A method for providing services to users of a public switched telecommunications system, which includes a service control sub-system, the service control subsystem provides an environment for execution of service logic, wherein logical programs of service is run in response to reception by the service control sub-system of corresponding service requests, the method is characterized because it includes the stages of. (a) providing a server with a plurality of service resource items each associated with a respective predetermined code, the server is located remote from the service logic execution environment but is accessible therefrom; and (b) when the service control sub-system receives a service request includes a predetermined code, runs the corresponding service logic program and accesses the server to use, in the course of service control by the service logic program , the service resource item corresponding to the default code that is included in the request; the service resource items are located from the service control sub-system using URIs, and step (d) includes the sub-step of translating the predetermined code included in the service request into the URI associated with the item of required service resource and use that URI to access the Service Resource Item. 26. A method according to claim 25, characterized in that the server is connected to a computer network, which is accessible to a substantial proportion of the users of the telecommunications system, but logically different from that. System, the method includes the additional step of accessing a user terminal, over the computer network, a service resource item using its associated URI, and using the resource item in configuring a carrier channel in the telecommunications system. 27. - A method according to claim 25, characterized in that the server is connected to a computer network, which is accessible to a substantial proportion of the users of the telecommunications system, but logically distinct from that system, the method includes the further step of using a user terminal to supply the server, over the computer network, with a service resource item in a corresponding URI. 28. - A method according to any of claims 25 to 27, characterized in that the server is an HTTP server. 29. - A method according to claim 25, characterized in that the computer network is Internet. SUMMARY OF THE INVENTION Traditional intelligent network services (IN = Intelligertt Network) in a PSTN, use data and service logic that are accessible for use only by the PSTN, although provision can be made for users to change certain control parameters of the services. The present system has the data and service logic placed on a server (51) accessible via Internet (50). This allows anyone to access useful telephone data such as time-of-day addressing or information of a user's deviation numbers. In this way, a calling party (A) can before placing a call on the PSTN, determine the best number to call when accessing the telephone page (49) of the called party called (D). This telephone page (49) will remain accessible to the PSTN for service provision. In a preferred embodiment, the data and service logic are maintained by the user (B) independently of the PSTN in a user selection server (51); in this case, the PSTN will also forward the user's data and service logic over the Internet (50), RS / 6 ?? + C¡rp / a 7 / PCT-051
MXPA/A/1998/004677A 1995-12-11 1998-06-11 Method for providing telecommunication services MXPA98004677A (en)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
GB9525190.6 1995-12-11
DE95410148.1 1995-12-22
GB9603589.4 1996-02-20

Publications (1)

Publication Number Publication Date
MXPA98004677A true MXPA98004677A (en) 2000-01-01

Family

ID=

Similar Documents

Publication Publication Date Title
EP1059814B1 (en) Method of providing telecommunication services
EP0867093B1 (en) Method of accessing service resource items that are for use in a telecommunications system
EP0867094B1 (en) Method of providing telecommunications services
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
AU719651B2 (en) Method of accessing a target entity over a communications network
MXPA98004677A (en) Method for providing telecommunication services
MXPA98004675A (en) Method to access an objective entity in a communication network
MXPA98004678A (en) Method for providing telecommunication services